Re: FirePower (was Re: TODO list for ofppc)

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

root%garbled.net@localhost wrote:

> On my machines, there is another field in there.  I'm assuming it's some kind
> of parent field.  Thats why I have the +1.  We may end up just needing a
> model-based quirk table or something.

Sure.

> And this is where it all goes wrong.
> 
> 00000000 00000000 00000000 80800800 00000800
> 00000800 00000000 00000000 80801000 00000800
> 00001000 00000000 00000000 80802000 00000800
> 00001800 00000000 00000000 80804000 00000800
> 00002000 00000000 00000000 80808000 00000800
> 01000000 00000000 00000000 80000000 00010000
> 01000000 00000000 00010000 80100000 3e800000
> 02000000 00000000 00000000 c0000000 3e000000
> 
> Its not picking up the sizes correctly:
> 
> > addr=0x80000000 size=0x2100000 type=1
> 
> That should have been from 80000000 with a size of somewhere in the 3e900000
> area.  It's not clear to me where it got 0x2100000 from.  Possibly more
> off-by-one errors.

This is because acells=3 and scells=2 but an offset of
a size cell is 4, not 5 (acells+scells), which is used in find_ranges():
---
                                DPRINTF("FOUND PCI RANGE\n");
                                regions[*cur].size =
                                    map[i*reclen + acells + scells];
---

I've adjusted scells to 1, but a kernel gets another panic
on extent region:
---
ofwpci0 at mainbus0
found a map reclen=5 cur=0 len=60
FOUND PCI RANGE
FOUND PCI RANGE
FOUND PCI RANGE
returning with CUR=3
cur == 3
addr=0x80000000 size=0x10000 type=1
addr=0x81000000 size=0x3e800000 type=1
addr=0xc0000000 size=0x3c000000 type=2
range==0
i==0
range==1
i==1
RANGE iomem=1 FOUND
addr=0x80000000 size=0x3f800000 type=1
HOLES FOUND
addr=0x80010000 size=0xfeffff type=-1
extent_alloc_region: extent `ofwpci io-space' (0x0 - 0x3f7fffff)
extent_alloc_region: start 0x80010000, end 0x80fffffe
panic: extent_alloc_region: region lies outside extent
Stopped in pid 0.1 (system) at  netbsd:cpu_Debugger+0x10:       lwz     r0, r1, 
0x14
---

> Even then however, I wonder why it took a data access exception there.  I
> wonder what it was attempting to do.

I'll try to track where it fails in this weekend.

> > Unhandled pic node type node=7e5ac40
> 
> Here, it is searching for things marked interrupt-controller, and then trying
> to guess what kind of interrupt controller it is.  It failed.  I'll need the
> .properties of whatever node has that marking to try and point it at the right
> thing.

There is "interrupt-controller" in /pci/isa node:
---
ok dev /pci ls
7ec1f40 ethernet@4
7ebbbe8 scsi@2
7eb3d44 svideo@8
7e5a580 isa@1
ok dev /pci/isa
ok ls
7ec7474 sound@i830
7e66d3c abort-sw
7e61a74 8042@i60
7e5fac4 floppy@i3f0
7e5f4e4 parallel@i3bc
7e5dfb0 serial@i2f8
7e5ca7c serial@i3f8
7e5c470 nvram@i74
7e5b4f0 rtc@i74
7e5b070 timer@i40
7e5ac40 interrupt-controller@i20
7e5ab1c dma-controller@i00
ok dev interrupt-controller
ok .properties
other-bus-reg            07 e2 2e e0 bf ff ff f0 00 00 00 01 
aix-chip-id              244d0081 
aix-id&type              41 d0 00 00 00 08 00 01 
reg                      00000001 00000020 00000002 
                         00000001 000000a0 00000002 
                         00000001 000004d0 00000002 
interrupts               00000002 
                         0000000d 
compatible               pnpPNP,0
device_type              interrupt-controller
name                     interrupt-controller
ok 
---
Izumi Tsutsui