Help debugging: Fatal kernel mode data abort: 'External Linefetch Abort (P)'

[Tom Judge]

Hi,

I am working on getting FreeBSD to boot on a new ARM based board, and am hitting this issue any time I load a driver for the PCI based devices on the board.

My current code can be found here:

http://www.tomjudge.com/tmp/em7210.patch

Here is the back trace of the problem (which i can repeat with em and ohci drivers):



RedBoot> load -b 0x01008000 kernel
Using default protocol (TFTP)
Address offset = 0x40000000
Entry point: 0x01008100, address range: 0x01008000-0x01349e28
RedBoot> go
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #12: Sat Sep 26 05:00:06 UTC 2009
    root@...:/data/arm_build/arm/usr/src/sys/EM-7210
CPU: i80219 400MHz step A-0 (XScale core)
  DC enabled IC enabled WB enabled LABT branch prediction enabled
  32KB/32B 32-way Instruction cache
  32KB/32B 32-way write-back-locking Data cache
real memory  = 536870912 (512 MB)
avail memory = 503738368 (480 MB)
iq0: <Intel 80321> on motherboard
obio0 on iq0
uart0: <16550 or compatible> on obio0
uart0: [FILTER]
uart0: console (115200,n,8,1)
itimer0: <i80321 timer> on iq0
iopwdog0: <i80321 Watchdog, must be tickled every 7 seconds> on iq0
pcib0: <i80321 PCI bus> on iq0
pci0: <PCI bus> on pcib0
No mapping for 0/5/0/
No mapping for 0/5/1/
No mapping for 0/5/2/
pci0: <network, ethernet> at device 1.0 (no driver attached)
pci0: <network, ethernet> at device 2.0 (no driver attached)
atapci0: <Intel 31244 SATA150 controller> mem 0x80000-0x80fff irq 27 at device 3.0 on pci0
atapci0: [ITHREAD]
ata2: <ATA channel 0> on atapci0
Fatal kernel mode data abort: 'External Linefetch Abort (P)'
trapframe: 0xc00faaf0
FSR=00000406, FAR=Invalid,  spsr=600000d3
r0 =c13e2c00, r1 =cd5bc000, r2 =00000004, r3 =c13e2d7c
r4 =c13e2c00, r5 =cd5bc000, r6 =c1298290, r7 =c1388800
r8 =ffffffff, r9 =00000009, r10=c13d8c00, r11=c00fab58
r12=c00fab24, ssp=c00fab3c, slr=c102389c, pc =c1023898

[thread pid 0 tid 100000 ]
Stopped at      ata_ahci_chipinit+0x4d68:       ldr     r15, [r3, #0x024]
db> bt
Tracing pid 0 tid 100000 td 0xc134dca0
db_trace_thread() at db_trace_thread+0xc
scp=0xc129c68c rlv=0xc100d0f0 (db_command_init+0x2a8)
        rsp=0xc00fa7ec rfp=0xc00fa808
        r10=0x00000001 r9=0xc13537f4
        r8=0xc134b0c4 r7=0x00000062 r6=0x00000002 r5=0x00000010
        r4=0xc134dca0
db_command_init() at db_command_init+0x1d0
scp=0xc100d018 rlv=0xc100cba0 (db_skip_to_eol+0x49c)
        rsp=0xc00fa80c rfp=0xc00fa8b0
        r5=0x00000000 r4=0xc1327938
db_skip_to_eol() at db_skip_to_eol+0x1d0
scp=0xc100c8d4 rlv=0xc100cd0c (db_command_loop+0x60)
        rsp=0xc00fa8b4 rfp=0xc00fa8c0
        r10=0x00000000 r8=0x00000406
        r7=0xc00faaf0 r6=0xc13537f0 r5=0x600000d3 r4=0xc00fa8cc
db_command_loop() at db_command_loop+0xc
scp=0xc100ccb8 rlv=0xc100f050 (X_db_sym_numargs+0xf4)
        rsp=0xc00fa8c4 rfp=0xc00fa9e0
X_db_sym_numargs() at X_db_sym_numargs+0x14
scp=0xc100ef70 rlv=0xc1106e40 (kdb_trap+0xa4)
        rsp=0xc00fa9e4 rfp=0xc00faa0c
        r4=0x000000c0
kdb_trap() at kdb_trap+0xc
scp=0xc1106da8 rlv=0xc12acb44 (badaddr_read+0x280)
        rsp=0xc00faa10 rfp=0xc00faa2c
        r10=0x00000000 r9=0x00000009
        r8=0xc00faaf0 r7=0x00000406 r6=0x00000000 r5=0x00000406
        r4=0xc00faaf0
badaddr_read() at badaddr_read+0xfc
scp=0xc12ac9c0 rlv=0xc12acfdc (prefetch_abort_handler+0x440)
        rsp=0xc00faa30 rfp=0xc00faa50
        r6=0xc134dca0 r5=0xc00faef8
        r4=0xc00faaf0
prefetch_abort_handler() at prefetch_abort_handler+0x378
scp=0xc12acf14 rlv=0xc12ad1a8 (data_abort_handler+0x110)
        rsp=0xc00faa54 rfp=0xc00faaec
        r7=0xc134dca0 r6=0xc1298290
        r5=0xc00faef8 r4=0xc134d9d8
data_abort_handler() at data_abort_handler+0xc
scp=0xc12ad0a4 rlv=0xc129e0c8 (address_exception_entry+0x50)
        rsp=0xc00faaf0 rfp=0xc00fab58
        r10=0xc13d8c00 r9=0x00000009
        r8=0xffffffff r7=0xc1388800 r6=0xc1298290 r5=0xffff1004
        r4=0xc13e2c00
ata_ahci_chipinit() at ata_ahci_chipinit+0x4c44
scp=0xc1023774 rlv=0xc101b664 (ata_mode2idx+0x464)
        rsp=0xc00fab5c rfp=0xc00fab78
        r7=0xc1391900 r6=0xc13d8c00
        r5=0xc1388800 r4=0xc13a01b0
ata_mode2idx() at ata_mode2idx+0x3ec
scp=0xc101b5ec rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fab7c rfp=0xc00fabb8
        r7=0xc1100140 r6=0xc13d8c4c
        r5=0x80000000 r4=0xc1383080
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00fabbc rfp=0xc00fabcc
        r10=0xc1383080 r8=0xffffffff
        r7=0xc1100140 r6=0xc1383080 r5=0xc1391900 r4=0xc13d8c00
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20)
        rsp=0xc00fabd0 rfp=0xc00fabe0
        r4=0xc13d8c00
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc1102e6c rlv=0xc101d11c (ata_pci_attach+0x2a4)
        rsp=0xc00fabe4 rfp=0xc00fac0c
        r4=0x00000004
ata_pci_attach() at ata_pci_attach+0xc
scp=0xc101ce84 rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fac10 rfp=0xc00fac4c
        r7=0xc1100140 r6=0xc13830cc
        r5=0x80000000 r4=0xc1383200
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00fac50 rfp=0xc00fac60
        r10=0xc1383200 r8=0xffffffff
        r7=0xc1100140 r6=0x00000000 r5=0x00000000 r4=0xc1383080
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20)
        rsp=0xc00fac64 rfp=0xc00fac74
        r4=0xc1383080
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc1102e6c rlv=0xc1067094 (pci_add_children+0x240)
        rsp=0xc00fac78 rfp=0xc00fac98
        r4=0xc1383200
pci_add_children() at pci_add_children+0x154
scp=0xc1066fa8 rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fac9c rfp=0xc00facd8
        r6=0xc138324c r5=0x80000000
        r4=0xc13d9300
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00facdc rfp=0xc00facec
        r10=0xc13d9300 r8=0xffffffff
        r7=0x00000000 r6=0xc13d9300 r5=0xc13bec18 r4=0xc1383200
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20)
        rsp=0xc00facf0 rfp=0xc00fad00
        r4=0xc1383200
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc1102e6c rlv=0xc12b25a4 (i80321_sdram_bounds+0x860)
        rsp=0xc00fad04 rfp=0xc00fad20
        r4=0xc13bec60
i80321_sdram_bounds() at i80321_sdram_bounds+0x6f4
scp=0xc12b2438 rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fad24 rfp=0xc00fad60
        r7=0xc1100140 r6=0xc13d934c
        r5=0x80000000 r4=0xc13d9580
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00fad64 rfp=0xc00fad74
        r10=0xc13d9580 r8=0xc13d9580
        r7=0x40000004 r6=0xc13e2c00 r5=0x00000000 r4=0xc13d9300
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20)
        rsp=0xc00fad78 rfp=0xc00fad88
        r4=0xc13d9300
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc1102e6c rlv=0xc12b31e0 (iq80321_attach+0x370)
        rsp=0xc00fad8c rfp=0xc00fadb8
        r4=0xc12eeca8
iq80321_attach() at iq80321_attach+0xc
scp=0xc12b2e7c rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fadbc rfp=0xc00fadf8
        r8=0xffffffff r7=0xc1100140
        r6=0xc13d95cc r5=0x80000000 r4=0xc13d9680
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00fadfc rfp=0xc00fae0c
        r10=0xc13d9680 r8=0xffffffff
        r7=0xc1100140 r6=0xc13d96cc r5=0x80000000 r4=0xc13d9580
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1102e80 (bus_generic_attach+0x20)
        rsp=0xc00fae10 rfp=0xc00fae20
        r4=0xc13d9580
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc1102e6c rlv=0xc12a0fec (minidumpsys+0xaf4)
        rsp=0xc00fae24 rfp=0xc00fae34
        r4=0xc13d9680
minidumpsys() at minidumpsys+0xae4
scp=0xc12a0fdc rlv=0xc1101a98 (device_attach+0x2c8)
        rsp=0xc00fae38 rfp=0xc00fae74
        r4=0xc12c30b8
device_attach() at device_attach+0xc
scp=0xc11017dc rlv=0xc1102e5c (device_probe_and_attach+0x34)
        rsp=0xc00fae78 rfp=0xc00fae88
        r10=0x0000000a r8=0x00000000
        r7=0xa10081a4 r6=0xc13d9b80 r5=0xc1347e7c r4=0xc13d9680
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc1102e34 rlv=0xc1103140 (bus_generic_new_pass+0xe4)
        rsp=0xc00fae8c rfp=0xc00faea4
        r4=0xc13d9680
bus_generic_new_pass() at bus_generic_new_pass+0xc
scp=0xc1103068 rlv=0xc10ff13c (bus_set_pass+0x98)
        rsp=0xc00faea8 rfp=0xc00faec0
        r6=0x7fffffff r5=0xc13d9b80
        r4=0xc13f16c0
bus_set_pass() at bus_set_pass+0xc
scp=0xc10ff0b0 rlv=0xc10ff184 (root_bus_configure+0x14)
        rsp=0xc00faec4 rfp=0xc00faed0
        r6=0x00000006 r5=0xa10081b0
        r4=0xc12f0cb4
root_bus_configure() at root_bus_configure+0xc
scp=0xc10ff17c rlv=0xc129708c (xdr_sizeof+0x1d0)
        rsp=0xc00faed4 rfp=0xc00faee0
xdr_sizeof() at xdr_sizeof+0x1cc
scp=0xc1297088 rlv=0xc108e39c (mi_startup+0xdc)
        rsp=0xc00faee4 rfp=0xc00faef4
mi_startup() at mi_startup+0xc
scp=0xc108e2cc rlv=0xc1008248 (btext+0x148)
        rsp=0xc00faef8 rfp=0x00000000
        r4=0xa1008288


Thanks

Tom

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Olivier Houchard-3]

On Mon, Sep 28, 2009 at 06:55:38PM +0000, Tom Judge wrote:

> Hi,
>
> I am working on getting FreeBSD to boot on a new ARM based board, and am
> hitting this issue any time I load a driver for the PCI based devices on
> the board.
>
> My current code can be found here:
>
> http://www.tomjudge.com/tmp/em7210.patch
>

Hi Tom,

My guess is, you should include std.i80219 instead of std.i80321 in std.em7210.
If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to
check if the board is host or not will be used, and will wrongly assume
it is not, and thus won't map the PCI mem correctly.

Regards,

Olivier
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Tom Judge]

Olivier Houchard wrote:

> On Mon, Sep 28, 2009 at 06:55:38PM +0000, Tom Judge wrote:
>  
>> Hi,
>>
>> I am working on getting FreeBSD to boot on a new ARM based board, and am
>> hitting this issue any time I load a driver for the PCI based devices on
>> the board.
>>
>> My current code can be found here:
>>
>> http://www.tomjudge.com/tmp/em7210.patch
>>
>>    
>
> Hi Tom,
>
> My guess is, you should include std.i80219 instead of std.i80321 in std.em7210.
> If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to
> check if the board is host or not will be used, and will wrongly assume
> it is not, and thus won't map the PCI mem correctly.
>
>  

Hi Olivier,

I have switched out the std file and am now using std.i80219 but am
still having issues.

I think the problems are the pci memory mappings in the controller devices.

On linux em0 gets mapped as  follows:

cd 0000\:00\:01.0/
# ls
class             device            local_cpus        subsystem_device
config            driver            resource          subsystem_vendor
detach_state      irq               rom               vendor
# cat resource
0x0000000080000000 0x000000008001ffff 0x0000000000000200
0x0000000080020000 0x000000008003ffff 0x0000000000000200
0x00000000fe000000 0x00000000fe00003f 0x0000000000000101
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000080040000 0x000000008005ffff 0x0000000000007200
#



Where as on FreeBSD I am seeing this:
em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device 1.0
on pci0

Seems that I am missing the 0x800 off the front of the PCI memory mappings.

I have confirmed this with the ata driver also and see the same issues.

Where should I be looking to fix this?

Thanks

Tom

 
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Tom Judge]

Tom Judge wrote:

> Olivier Houchard wrote:
>> On Mon, Sep 28, 2009 at 06:55:38PM +0000, Tom Judge wrote:
>>  
>>> Hi,
>>>
>>> I am working on getting FreeBSD to boot on a new ARM based board,
>>> and am hitting this issue any time I load a driver for the PCI based
>>> devices on the board.
>>>
>>> My current code can be found here:
>>>
>>> http://www.tomjudge.com/tmp/em7210.patch
>>>
>>>    
>>
>> Hi Tom,
>>
>> My guess is, you should include std.i80219 instead of std.i80321 in
>> std.em7210.
>> If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to
>> check if the board is host or not will be used, and will wrongly
>> assume it is not, and thus won't map the PCI mem correctly.
>>
>>  
> Hi Olivier,
>
> I have switched out the std file and am now using std.i80219 but am
> still having issues.
>
> I think the problems are the pci memory mappings in the controller
> devices.
>
> On linux em0 gets mapped as  follows:
>
> cd 0000\:00\:01.0/
> # ls
> class             device            local_cpus        subsystem_device
> config            driver            resource          subsystem_vendor
> detach_state      irq               rom               vendor
> # cat resource
> 0x0000000080000000 0x000000008001ffff 0x0000000000000200
> 0x0000000080020000 0x000000008003ffff 0x0000000000000200
> 0x00000000fe000000 0x00000000fe00003f 0x0000000000000101
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000080040000 0x000000008005ffff 0x0000000000007200
> #
>
>
>
> Where as on FreeBSD I am seeing this:
> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device
> 1.0 on pci0
>
> Seems that I am missing the 0x800 off the front of the PCI memory
> mappings.
>
> I have confirmed this with the ata driver also and see the same issues.
>
> Where should I be looking to fix this?
>

Forgot to include the output from VERBOSE_INIT_ARM

iq0: <Intel 80321> on motherboard
i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000
i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000
i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020
i80321: BANK0 = 0x10000000 BANK1 = 0x10000000
i80321: Reserve space for private devices (Inbound Window 1)
 hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000
 i80321: RAM access (Inbound Window 2)
  hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000
  obio0 on iq0
  uart0: <16550 or compatible> on obio0

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Olivier Houchard-6]

On Tue, Sep 29, 2009 at 02:05:14AM +0000, Tom Judge wrote:

> Olivier Houchard wrote:
> >On Mon, Sep 28, 2009 at 06:55:38PM +0000, Tom Judge wrote:
> >  
> >>Hi,
> >>
> >>I am working on getting FreeBSD to boot on a new ARM based board, and am
> >>hitting this issue any time I load a driver for the PCI based devices on
> >>the board.
> >>
> >>My current code can be found here:
> >>
> >>http://www.tomjudge.com/tmp/em7210.patch
> >>
> >>    
> >
> >Hi Tom,
> >
> >My guess is, you should include std.i80219 instead of std.i80321 in
> >std.em7210.
> >If you do not, CPU_XSCALE_80219 won't be defined, and the 80321 code to
> >check if the board is host or not will be used, and will wrongly assume
> >it is not, and thus won't map the PCI mem correctly.
> >
> >  
> Hi Olivier,
>
> I have switched out the std file and am now using std.i80219 but am
> still having issues.
>
> I think the problems are the pci memory mappings in the controller devices.
>
> On linux em0 gets mapped as  follows:
>
> cd 0000\:00\:01.0/
> # ls
> class             device            local_cpus        subsystem_device
> config            driver            resource          subsystem_vendor
> detach_state      irq               rom               vendor
> # cat resource
> 0x0000000080000000 0x000000008001ffff 0x0000000000000200
> 0x0000000080020000 0x000000008003ffff 0x0000000000000200
> 0x00000000fe000000 0x00000000fe00003f 0x0000000000000101
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000000000000 0x0000000000000000 0x0000000000000000
> 0x0000000080040000 0x000000008005ffff 0x0000000000007200
> #
>
>
>
> Where as on FreeBSD I am seeing this:
> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device 1.0
> on pci0
>
> Seems that I am missing the 0x800 off the front of the PCI memory mappings.
>

Ok I'm a bit confused about this code, it's been too long since I haven't
read it :)
Could you try the attached patch ?

Thanks !

If it doesn't help, you can print adapter->osdep.mem_bus_space_handle in
if_em.c to make sure it is the same as in linux.

Regards,

Olivier

Index: arm/xscale/i80321/i80321_pci.c
===================================================================
--- arm/xscale/i80321/i80321_pci.c (revision 196158)
+++ arm/xscale/i80321/i80321_pci.c (working copy)
@@ -92,8 +92,7 @@
  sc->sc_busno = busno;
  sc->sc_pciio = &i80321_softc->sc_pci_iot;
  sc->sc_pcimem = &i80321_softc->sc_pci_memt;
- sc->sc_mem = i80321_softc->sc_owin[0].owin_xlate_lo +
-    VERDE_OUT_XLATE_MEM_WIN_SIZE;
+ sc->sc_mem = i80321_softc->sc_owin[0].owin_xlate_lo;
 
  sc->sc_io = i80321_softc->sc_iow_vaddr;
  /* Initialize memory and i/o rmans. */

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Tom Judge]

Olivier Houchard wrote:

> On Tue, Sep 29, 2009 at 02:05:14AM +0000, Tom Judge wrote:
>  
>> Hi Olivier,
>>
>> I have switched out the std file and am now using std.i80219 but am
>> still having issues.
>>
>> I think the problems are the pci memory mappings in the controller devices.
>>
>> On linux em0 gets mapped as  follows:
>>
>> cd 0000\:00\:01.0/
>> # ls
>> class             device            local_cpus        subsystem_device
>> config            driver            resource          subsystem_vendor
>> detach_state      irq               rom               vendor
>> # cat resource
>> 0x0000000080000000 0x000000008001ffff 0x0000000000000200
>> 0x0000000080020000 0x000000008003ffff 0x0000000000000200
>> 0x00000000fe000000 0x00000000fe00003f 0x0000000000000101
>> 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> 0x0000000000000000 0x0000000000000000 0x0000000000000000
>> 0x0000000080040000 0x000000008005ffff 0x0000000000007200
>> #
>>
>>
>>
>> Where as on FreeBSD I am seeing this:
>> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
>> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 29 at device 1.0
>> on pci0
>>
>> Seems that I am missing the 0x800 off the front of the PCI memory mappings.
>>
>>    
>
> Ok I'm a bit confused about this code, it's been too long since I haven't
> read it :)
> Could you try the attached patch ?
>
> Thanks !
>
> If it doesn't help, you can print adapter->osdep.mem_bus_space_handle in
> if_em.c to make sure it is the same as in linux.
>
>  

Hi Olivier,

I have tried the patch and here are the boot results:


i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000
i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000
i80219: I/O Processor, acting as PCI host
i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020
i80321: BANK0 = 0x10000000 BANK1 = 0x10000000
i80321: Reserve space for private devices (Inbound Window 1)
 hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000
i80321: RAM access (Inbound Window 2)
 hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000
obio0 on iq0
uart0: <16550 or compatible> on obio0
uart0: [FILTER]
uart0: console (115200,n,8,1)
itimer0: <i80321 timer> on iq0
iopwdog0: <i80321 Watchdog, must be tickled every 7 seconds> on iq0
pcib0: <i80321 PCI bus> on iq0
pci0: <PCI bus> on pcib0
Device 1 routed to irq 27
Device 2 routed to irq 30
Device 3 routed to irq 29
Device 5 routed to irq 30
Device 5 routed to irq 29
Device 5 routed to irq 27
em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 27 at device 1.0
on pci0
em0: Start: 0x00000000
em0: End: 0x0001FFFF
em0: Size: 0x00020000
Fatal kernel mode data abort: 'External Linefetch Abort (P)'
trapframe: 0xc00faad0
FSR=00000406, FAR=Invalid,  spsr=200000d3
r0 =c00d0400, r1 =cd5bf000, r2 =00000010, r3 =0000000a
r4 =c317e008, r5 =cd5bf000, r6 =c00d0400, r7 =c130212c
r8 =c317e008, r9 =c0071180, r10=c317e000, r11=c00fab40
r12=c00fab44, ssp=c00fab1c, slr=c106a96c, pc =c106a968

[thread pid 0 tid 100000 ]
Stopped at      e1000_init_script_state_82541+0x24c:    blx     r7
db>



As you can see I added some debug to if_em.c as such:

Index: sys/dev/e1000/if_em.c
===================================================================
--- sys/dev/e1000/if_em.c    (revision 197472)
+++ sys/dev/e1000/if_em.c    (working copy)
@@ -2770,6 +2770,9 @@
         rman_get_bustag(adapter->memory);
     adapter->osdep.mem_bus_space_handle =
         rman_get_bushandle(adapter->memory);
+    device_printf(dev,"Start: 0x%08lX\n", rman_get_start(adapter->memory));
+    device_printf(dev,"End: 0x%08lX\n", rman_get_end(adapter->memory));
+    device_printf(dev,"Size: 0x%08lX\n", rman_get_size(adapter->memory));
     adapter->hw.hw_addr = (u8 *)&adapter->osdep.mem_bus_space_handle;
 
     /* Only older adapters use IO mapping */


But the memory mapping seems to be missing the most significant 0x8.

Thanks

Tom
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Mark Tinguely]

I don't know anything about the code other than what I read today ...

It appears from you boot traces the owin[0].owin_xlate_[lo | hi] values
should be fine in iq80321.c - an "VERBOSE_INIT_ARM" would confirm it.

You might want to test if the "sc" pointer in iq80321.c has the same value
as the global "i80321_softc" pointer. You can add those print statements
to an "VERBOSE_INIT_ARM". It will tell you if something changed the global
pointer or if something overwrote the owin values in the structure.

If global pointer or owin was changed before the pci attach code, you
can put the appropriate test into the earlier (obio, uart, itimer, iopwdtimer)
attach. None of these attaches use the global "i80321_softc" pointer.

--Mark.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Tom Judge]

Mark Tinguely wrote:

> I don't know anything about the code other than what I read today ...
>
> It appears from you boot traces the owin[0].owin_xlate_[lo | hi] values
> should be fine in iq80321.c - an "VERBOSE_INIT_ARM" would confirm it.
>
> You might want to test if the "sc" pointer in iq80321.c has the same value
> as the global "i80321_softc" pointer. You can add those print statements
> to an "VERBOSE_INIT_ARM". It will tell you if something changed the global
> pointer or if something overwrote the owin values in the structure.
>
> If global pointer or owin was changed before the pci attach code, you
> can put the appropriate test into the earlier (obio, uart, itimer, iopwdtimer)
> attach. None of these attaches use the global "i80321_softc" pointer.
>
> --Mark.
>  

Hi Mark,

Here is the log of a verbose_init_arm with added debug for
owin[0].owin_xlate_[lo|hi]:

RedBoot> go
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #30: Tue Sep 29 19:02:49 UTC 2009
    root@...:/data/arm_build/arm/usr/src/sys/EM-7210
CPU: i80219 400MHz step A-0 (XScale core)
  DC enabled IC enabled WB enabled LABT branch prediction enabled
  32KB/32B 32-way Instruction cache
  32KB/32B 32-way write-back-locking Data cache
real memory  = 536870912 (512 MB)
avail memory = 503738368 (480 MB)
iq0: <Intel 80321> on motherboard
i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000
i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000
i80219: I/O Processor, acting as PCI host
i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020
i80321: BANK0 = 0x10000000 BANK1 = 0x10000000
i80321: Reserve space for private devices (Inbound Window 1)
 hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000
i80321: RAM access (Inbound Window 2)
 hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000
i80321: Reserve space for private devices (Outbound Window 1)
 xlate_hi:0x00000000 xlate_lo:0x80000000
obio0 on iq0
uart0: <16550 or compatible> on obio0
uart0: [FILTER]
uart0: console (115200,n,8,1)
itimer0: <i80321 timer> on iq0
iopwdog0: <i80321 Watchdog, must be tickled every 7 seconds> on iq0
pcib0: <i80321 PCI bus> on iq0
pci0: <PCI bus> on pcib0
Device 1 routed to irq 27
Device 2 routed to irq 30
Device 3 routed to irq 29
Device 5 routed to irq 30
Device 5 routed to irq 29
Device 5 routed to irq 27
em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 27 at device 1.0
on pci0
em0: Start: 0x00000000
em0: End: 0x0001FFFF
em0: Size: 0x00020000
Fatal kernel mode data abort: 'External Linefetch Abort (P)'
trapframe: 0xc00faae0
FSR=00000406, FAR=Invalid,  spsr=200000d3
r0 =c00d0400, r1 =cd5bf000, r2 =00000010, r3 =0000000a
r4 =c317e008, r5 =cd5bf000, r6 =c00d0400, r7 =c1302070
r8 =c317e008, r9 =c0071180, r10=c317e000, r11=c00fab50
r12=c00fab54, ssp=c00fab2c, slr=c106a96c, pc =c106a968

[thread pid 0 tid 100000 ]
Stopped at      e1000_init_script_state_82541+0x24c:    blx     r7
db>


The only places i can see owin used is in i80321.c and iq80312.c and
they only written to in i80312.c if the controller is a slave not a host:

        if (!sc->sc_is_host) {
                sc->sc_owin[0].owin_xlate_lo = sc->sc_iwin[1].iwin_base_lo;
                sc->sc_owin[0].owin_xlate_hi = sc->sc_iwin[1].iwin_base_hi;
        }


I will see if I can compare the global softc with the ones returned by
the get function.

Thanks

Tom

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Olivier Houchard-3]

> Hi Olivier,
>
> I have tried the patch and here are the boot results:
>
>
> i80321: BAR0 = 20000004.00000000 BAR1 = 40000004.00000000
> i80219: BAR0 = 20000000.00000000 BAR1 = 40000000.00000000
> i80219: I/O Processor, acting as PCI host
> i80321: SBDR = 0xa0000000 SBR0 = 0x00000018 SBR1 = 0x00000020
> i80321: BANK0 = 0x10000000 BANK1 = 0x10000000
> i80321: Reserve space for private devices (Inbound Window 1)
> hi:0x00000000 lo:0x8000000c xlate:0x80000000 size:0x04000000
> i80321: RAM access (Inbound Window 2)
> hi:0x00000000 lo:0xa000000c xlate:0xa0000000 size:0x20000000
> obio0 on iq0
> uart0: <16550 or compatible> on obio0
> uart0: [FILTER]
> uart0: console (115200,n,8,1)
> itimer0: <i80321 timer> on iq0
> iopwdog0: <i80321 Watchdog, must be tickled every 7 seconds> on iq0
> pcib0: <i80321 PCI bus> on iq0
> pci0: <PCI bus> on pcib0
> Device 1 routed to irq 27
> Device 2 routed to irq 30
> Device 3 routed to irq 29
> Device 5 routed to irq 30
> Device 5 routed to irq 29
> Device 5 routed to irq 27
> em0: <Intel(R) PRO/1000 Network Connection 6.9.14> port
> 0xfe400000-0xfe40003f mem 0-0x1ffff,0x20000-0x3ffff irq 27 at device 1.0
> on pci0
> em0: Start: 0x00000000
> em0: End: 0x0001FFFF
> em0: Size: 0x00020000
> Fatal kernel mode data abort: 'External Linefetch Abort (P)'
> trapframe: 0xc00faad0
> FSR=00000406, FAR=Invalid,  spsr=200000d3
> r0 =c00d0400, r1 =cd5bf000, r2 =00000010, r3 =0000000a
> r4 =c317e008, r5 =cd5bf000, r6 =c00d0400, r7 =c130212c
> r8 =c317e008, r9 =c0071180, r10=c317e000, r11=c00fab40
> r12=c00fab44, ssp=c00fab1c, slr=c106a96c, pc =c106a968
>
> [thread pid 0 tid 100000 ]
> Stopped at      e1000_init_script_state_82541+0x24c:    blx     r7
> db>
>
>
>
> As you can see I added some debug to if_em.c as such:
>
> Index: sys/dev/e1000/if_em.c
> ===================================================================
> --- sys/dev/e1000/if_em.c    (revision 197472)
> +++ sys/dev/e1000/if_em.c    (working copy)
> @@ -2770,6 +2770,9 @@
>         rman_get_bustag(adapter->memory);
>     adapter->osdep.mem_bus_space_handle =
>         rman_get_bushandle(adapter->memory);
> +    device_printf(dev,"Start: 0x%08lX\n", rman_get_start(adapter->memory));
> +    device_printf(dev,"End: 0x%08lX\n", rman_get_end(adapter->memory));
> +    device_printf(dev,"Size: 0x%08lX\n", rman_get_size(adapter->memory));
>     adapter->hw.hw_addr = (u8 *)&adapter->osdep.mem_bus_space_handle;
>
>     /* Only older adapters use IO mapping */
>
>
> But the memory mapping seems to be missing the most significant 0x8.
>

I fail to see how it happens.
Could you printf the value of sc->sc_mem once set in i80321_pci_attach(),
and if it appears to be 0, the value of i80321_softc->sc_owin[0].owin_xlate_lo
at the different points it can be set ?

Thanks a lot,

Olivier
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Tom Judge]

Olivier Houchard wrote:

>> Hi Olivier,
>>
>> I have tried the patch and here are the boot results:
>>
>> <SNIP>
>>    
>
> I fail to see how it happens.
> Could you printf the value of sc->sc_mem once set in i80321_pci_attach(),
> and if it appears to be 0, the value of i80321_softc->sc_owin[0].owin_xlate_lo
> at the different points it can be set ?
>
> Thanks a lot,
>
> Olivier
>  

Hi Olivier,

I have been working though this with Mark Tinguely and we came up with
this patch that makes it work.  Not sure on its correctness but it works.

Tom



Index: i80321_pci.c
===================================================================
--- i80321_pci.c (revision 197735)
+++ i80321_pci.c (working copy)
@@ -92,8 +92,7 @@
  sc->sc_busno = busno;
  sc->sc_pciio = &i80321_softc->sc_pci_iot;
  sc->sc_pcimem = &i80321_softc->sc_pci_memt;
- sc->sc_mem = i80321_softc->sc_owin[0].owin_xlate_lo +
-    VERDE_OUT_XLATE_MEM_WIN_SIZE;
+ sc->sc_mem = i80321_softc->sc_owin[0].owin_xlate_lo;
 
  sc->sc_io = i80321_softc->sc_iow_vaddr;
  /* Initialize memory and i/o rmans. */
@@ -110,7 +109,8 @@
  sc->sc_mem_rman.rm_descr = "I80321 PCI Memory";
  if (rman_init(&sc->sc_mem_rman) != 0 ||
     rman_manage_region(&sc->sc_mem_rman,
-    0, VERDE_OUT_XLATE_MEM_WIN_SIZE) != 0) {
+    VERDE_OUT_XLATE_MEM_WIN0_BASE,
+ VERDE_OUT_XLATE_MEM_WIN0_BASE + VERDE_OUT_XLATE_MEM_WIN_SIZE) != 0) {
  panic("i80321_pci_probe: failed to set up memory rman");
  }
  sc->sc_irq_rman.rm_type = RMAN_ARRAY;
@@ -297,6 +297,9 @@
     sc->sc_mem;
  start &= (0x1000000 - 1);
  end &= (0x1000000 - 1);
+ start += 0x80000000;
+ end += 0x80000000;
+ device_printf(child, "SYS_RES_MEMORY: start: 0x%08lX end: 0x%08lX\n",start,end);
  break;
  case SYS_RES_IOPORT:
  rm = &sc->sc_io_rman;
@@ -312,12 +315,15 @@
  }
 
  rv = rman_reserve_resource(rm, start, end, count, flags, child);
+ device_printf(child, "RMAN_RESERVE_RESOURCE: start: 0x%08lX end: 0x%08lX\n",
+ rman_get_start(rv),
+ rman_get_end(rv));
  if (rv == NULL)
  return (NULL);
  rman_set_rid(rv, *rid);
  if (type != SYS_RES_IRQ) {
  if (type == SYS_RES_MEMORY)
- bh += (rman_get_start(rv));
+ bh = (rman_get_start(rv));
  rman_set_bustag(rv, bt);
  rman_set_bushandle(rv, bh);
  if (flags & RF_ACTIVE) {

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."