Adding support for the Intel SS4000-E NAS aka the EM-7210

[Tom Judge]

Hi,

I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I
have copied all of the files for the EP80219 as this seems to be what
the board is based on, and modified the interrupt assignment code.  See
the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch

I am also having trouble with loading the kernel at the default
location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila)
as RedBoot reports that there is no memory at the load address.

Currently when I try to load this kernel at the phys address using
reboot and try to run the kernel I get nothing outputed on the console.
I used the phys address from the addresses that the linux kernel is
loaded into out of flash. (see output below)

Could someone please give me some hints on what I am doing wrong and
need to change?  The board is currently supported by the Linux kernel
(as the em7210.c) so I was hoping that adding support to FreeBSD would
not be difficult.

More information about the system can be found here:
http://em7210.kwaak.net/

Thanks in advance for any help,

Tom


> $ sudo cu -l cuau0 -s 115200
Password:
Connected
+No network interfaces found

EM-7210 ver.T04 2005-12-12 (For ver.AA)
== Executing boot script in 1.000 seconds - enter ^C to abort
^C
RedBoot> ^C
RedBoot> fis load rammode
RedBoot> go
+Ethernet eth0: MAC address 00:0e:0c:b6:bf:1a
IP: 10.9.9.1/255.255.255.0, Gateway: 10.9.9.1
Default server: 10.9.9.10, DNS server IP: 0.0.0.0

EM-7210 (RAM mode) 2005-12-22
== Executing boot script in 1.000 seconds - enter ^C to abort
^C
RedBoot> ^C
RedBoot> fis list
Name              FLASH addr  Mem addr    Length      Entry point
RedBoot           0xF0000000  0xF0000000  0x00040000  0x00000000
RedBoot config    0xF1FC0000  0xF1FC0000  0x00001000  0x00000000
FIS directory     0xF1FE0000  0xF1FE0000  0x00020000  0x00000000
rammode           0xF0060000  0x00200000  0x00040000  0x00200000
log               0xF0040000  0xF0040000  0x00020000  0x00000000
naskey            0xF00A0000  0xF00A0000  0x00020000  0x01008000
zImage            0xF00C0000  0x01008000  0x00200000  0x01008000
ramdisk.gz        0xF02C0000  0x01800000  0x00400000  0x01800000
vendor            0xF06C0000  0xF06C0000  0x01880000  0x01800000
wmdata            0xF1F40000  0xF1F40000  0x00080000  0x01800000
RedBoot>


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

[Rui Paulo-2]

On 21 Sep 2009, at 17:02, Tom Judge wrote:

> Hi,
>
> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I
> have copied all of the files for the EP80219 as this seems to be what
> the board is based on, and modified the interrupt assignment code.  
> See
> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch
>
> I am also having trouble with loading the kernel at the default
> location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila 
> )
> as RedBoot reports that there is no memory at the load address.
> Currently when I try to load this kernel at the phys address using
> reboot and try to run the kernel I get nothing outputed on the  
> console.
> I used the phys address from the addresses that the linux kernel is
> loaded into out of flash. (see output below)
>
> Could someone please give me some hints on what I am doing wrong and
> need to change?  The board is currently supported by the Linux kernel
> (as the em7210.c) so I was hoping that adding support to FreeBSD would
> not be difficult.

Are you sure 0x200000 is the correct load address?

--
Rui Paulo



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

[Tom Judge]

Rui Paulo wrote:

> On 21 Sep 2009, at 17:02, Tom Judge wrote:
>
>> Hi,
>>
>> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I
>> have copied all of the files for the EP80219 as this seems to be what
>> the board is based on, and modified the interrupt assignment code.  See
>> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch
>>
>> I am also having trouble with loading the kernel at the default
>> location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila)
>> as RedBoot reports that there is no memory at the load address.
>> Currently when I try to load this kernel at the phys address using
>> reboot and try to run the kernel I get nothing outputed on the console.
>> I used the phys address from the addresses that the linux kernel is
>> loaded into out of flash. (see output below)
>>
>> Could someone please give me some hints on what I am doing wrong and
>> need to change?  The board is currently supported by the Linux kernel
>> (as the em7210.c) so I was hoping that adding support to FreeBSD would
>> not be difficult.
>
> Are you sure 0x200000 is the correct load address?
>
> --
> Rui Paulo
>
>
>

Hi Rui,

First I would like to say thanks for replying, this is my first
experiment with trying to get freebsd to work on another platform so
please treat me a newbe to all this (thanks).

Looking that where the linux kernel is loaded it seems the load address
is 0x01008000.

However it seems like it could be loaded at 0x200000, as there is a
second copy of redboot on the unit, that supports the NIC, that is
loaded add this address.

See this here for the details of what get loaded where on the unit:
http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install

Tom

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

[Stanislav Sedov-3]

On Fri, 25 Sep 2009 13:07:54 +0000
Tom Judge <tom@...> mentioned:

> Rui Paulo wrote:
> > On 21 Sep 2009, at 17:02, Tom Judge wrote:
> >
> >> Hi,
> >>
> >> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I
> >> have copied all of the files for the EP80219 as this seems to be what
> >> the board is based on, and modified the interrupt assignment code.  See
> >> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch
> >>
> >> I am also having trouble with loading the kernel at the default
> >> location, (instructions from here: http://wiki.freebsd.org/FreeBSDAvila)
> >> as RedBoot reports that there is no memory at the load address.
> >> Currently when I try to load this kernel at the phys address using
> >> reboot and try to run the kernel I get nothing outputed on the console.
> >> I used the phys address from the addresses that the linux kernel is
> >> loaded into out of flash. (see output below)
> >>
> >> Could someone please give me some hints on what I am doing wrong and
> >> need to change?  The board is currently supported by the Linux kernel
> >> (as the em7210.c) so I was hoping that adding support to FreeBSD would
> >> not be difficult.
> >
> > Are you sure 0x200000 is the correct load address?
> >
> > --
> > Rui Paulo
> >
> >
> >
> Hi Rui,
>
> First I would like to say thanks for replying, this is my first
> experiment with trying to get freebsd to work on another platform so
> please treat me a newbe to all this (thanks).
>
> Looking that where the linux kernel is loaded it seems the load address
> is 0x01008000.
>
> However it seems like it could be loaded at 0x200000, as there is a
> second copy of redboot on the unit, that supports the NIC, that is
> loaded add this address.
>
> See this here for the details of what get loaded where on the unit:
> http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install

The default load address of the AVILA FreeBSD kernel is 10200000 so
it expects to be loaded here.  As I see from your patch you changed
it to be 0x01008000 instead.  So you should probably either load the
kernel to this address, or change the corresponding KERNPHYSADDR
parameter to 0x200000.

Does this board has JTAG port available?  It will make the debugging
much easier.

--
Stanislav Sedov
ST4096-RIPE

[Stanislav Sedov-3]

On Mon, 21 Sep 2009 16:02:32 +0000
Tom Judge <tom@...> mentioned:

> Hi,
>
> I am trying to add support for the Intel SS4000-E/EM7210 to FreeBSD, I
> have copied all of the files for the EP80219 as this seems to be what
> the board is based on, and modified the interrupt assignment code.  See
> the patch agains sys/arm here: http://www.tomjudge.com/tmp/em-7210-patch
>

Hi, Tom!

It's great to hear you're working on this project!  It's hard to say what's
wrong with your setup, but here're some things I noteced.

First, KERNVIRTADDR appears to be incorrect in your setup as you're trying to map
the kernel very low (0x01008000).  In this case very low amount of virtual
address space will be left for user-level applications.  Try to map it to
some address above 0xc0000000, e.g. to 0xc1008000.

I also do not quite understand why you're using address 0xa0100000 for the
first helper page mapping?  What is the layout of memory on your board?
Is anything useable is mapped here?

Good luck!

--
Stanislav Sedov
ST4096-RIPE

[Tom Judge]

Stanislav Sedov wrote:

> On Fri, 25 Sep 2009 13:07:54 +0000
> Tom Judge <tom@...> mentioned:
>
>  
>> Rui Paulo wrote:
>>    
>>> On 21 Sep 2009, at 17:02, Tom Judge wrote:
>>>
>>> <SNIP>
>>> Are you sure 0x200000 is the correct load address?
>>>
>>> --
>>> Rui Paulo
>>>
>>>
>>>
>>>      
>> Hi Rui,
>>
>> First I would like to say thanks for replying, this is my first
>> experiment with trying to get freebsd to work on another platform so
>> please treat me a newbe to all this (thanks).
>>
>> Looking that where the linux kernel is loaded it seems the load address
>> is 0x01008000.
>>
>> However it seems like it could be loaded at 0x200000, as there is a
>> second copy of redboot on the unit, that supports the NIC, that is
>> loaded add this address.
>>
>> See this here for the details of what get loaded where on the unit:
>> http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install
>>    
>
> The default load address of the AVILA FreeBSD kernel is 10200000 so
> it expects to be loaded here.  As I see from your patch you changed
> it to be 0x01008000 instead.  So you should probably either load the
> kernel to this address, or change the corresponding KERNPHYSADDR
> parameter to 0x200000.
>
>  

When I had KERNPHYSADDR and KERNVIRTADDR set to 0x01008000 I was unable
to make any progress on getting the system to boot.  Last night I was
working on the patch again, and started by using the std.aliva file as a
base for my std.em7210 rather than std.ep80219.  However I have not yet
had a chance to test this as I was working my way though making user the
devmap matched the devmap used by the linux kernel.

I have also been looking at alvia_machdep.c + eq80219_machdep.c and
comparing it to the em7210_machdep.c to remove magic numbers and replace
them with macros/defines as used in the aliva board.

Here is my current work: http://www.tomjudge.com/tmp/patch-em7210-round2

> Does this board has JTAG port available?  It will make the debugging
> much easier.
>
>  
Yes there is a jtag port on the board, it seems to be a standard 20 pin
ARM header on the board (see image here:
http://www.kwaak.net/fotos/fotos-nas/slide_14.html).

Can anyone recommend a reasonably priced jtag cable? Preferable that
would work on FreeBSD.


Thanks


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

[Stanislav Sedov-3]

On Fri, 25 Sep 2009 13:54:05 +0000
Tom Judge <tom@...> mentioned:

> Stanislav Sedov wrote:
> > On Fri, 25 Sep 2009 13:07:54 +0000
> > Tom Judge <tom@...> mentioned:
> >
> >  
> >> Rui Paulo wrote:
> >>    
> >>> On 21 Sep 2009, at 17:02, Tom Judge wrote:
> >>>
> >>> <SNIP>
> >>> Are you sure 0x200000 is the correct load address?
> >>>
> >>> --
> >>> Rui Paulo
> >>>
> >>>
> >>>
> >>>      
> >> Hi Rui,
> >>
> >> First I would like to say thanks for replying, this is my first
> >> experiment with trying to get freebsd to work on another platform so
> >> please treat me a newbe to all this (thanks).
> >>
> >> Looking that where the linux kernel is loaded it seems the load address
> >> is 0x01008000.
> >>
> >> However it seems like it could be loaded at 0x200000, as there is a
> >> second copy of redboot on the unit, that supports the NIC, that is
> >> loaded add this address.
> >>
> >> See this here for the details of what get loaded where on the unit:
> >> http://www.tomjudge.com/index.php/SS4000-E/FreeBSD_Install
> >>    
> >
> > The default load address of the AVILA FreeBSD kernel is 10200000 so
> > it expects to be loaded here.  As I see from your patch you changed
> > it to be 0x01008000 instead.  So you should probably either load the
> > kernel to this address, or change the corresponding KERNPHYSADDR
> > parameter to 0x200000.
> >
> >  
>
> When I had KERNPHYSADDR and KERNVIRTADDR set to 0x01008000 I was unable
> to make any progress on getting the system to boot.  Last night I was
> working on the patch again, and started by using the std.aliva file as a
> base for my std.em7210 rather than std.ep80219.  However I have not yet
> had a chance to test this as I was working my way though making user the
> devmap matched the devmap used by the linux kernel.
>
> I have also been looking at alvia_machdep.c + eq80219_machdep.c and
> comparing it to the em7210_machdep.c to remove magic numbers and replace
> them with macros/defines as used in the aliva board.
>
> Here is my current work: http://www.tomjudge.com/tmp/patch-em7210-round2

This looks better, but you're still using weird addresses
for phys_avail and dump_avail ARM_USE_SMALL_ALLOC case.  I don't know
the memory layout of this board, but using addresses starting from
0xa0000000 for page mappings looks really wrong to me.

BTW, I noticed you're using 0x0 address for the start address of the
physical memory?  Is it correct?  Usualy, this address is the CPU start
address and thus boot ROM gets mapped here so CPU can start executing
ROM code upon boot.  But your board may use different layout so you'd
need to check this.

>
> > Does this board has JTAG port available?  It will make the debugging
> > much easier.
> >
> >  
> Yes there is a jtag port on the board, it seems to be a standard 20 pin
> ARM header on the board (see image here:
> http://www.kwaak.net/fotos/fotos-nas/slide_14.html).
>
> Can anyone recommend a reasonably priced jtag cable? Preferable that
> would work on FreeBSD.
>

The choice of JTAG depends on the software that will be used.  For me,
OpenOCD works well.  I can recommend the FTDI based cables as they're
really fast and well supported (OpenMoko, for example, distributes one
of them; they're usually Jtagkey clones).  Simple Wiggler-like cables
are much clower and less reliable, but is very cheap and can be made
easily at home if not availble in shops (as it's merealy a pin-to-pin
conversion from JTAG to IEEE1284).  They requre the parallel LPT port to
be present, though.

--
Stanislav Sedov
ST4096-RIPE

[Tom Judge]

<<SNIP -- Previous message removed as I now have a booting (ish) kernel>>

Hi,

Stanislav, Rue first thanks for your help with this.

I have since relised the errors in my ways and now have a booting kernel
that I can load at 0x01008000.  It seems the first mistake that I made
was to use the ep80219 as the base for my port. I should have read the
linux notes more carefully as it states that they can boot the iq31244
kernel on this board.

I have since then migrated the code to use the iq31244 as the base, and
have a kernel that kind of boots.

Fist thing I have noticed is I get this error while booting:
pmap_bootstrap: WARNING! wrong cache mode for L2 pte @ 0xc1003c00

I don't really know how to fix this so some pointers would be welcome.

The next problem is that I get the following error when either em or ata
are compiled into my kernel:

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

If I remove both ata and em from the kernel then the kernel gets to
trying to mount the rootfs and fails because it wants to mount an NFS
root from em0.

Bellow is a full backtrace for the em crash and a backtrace for the ata
crash can be found here:

http://www.tomjudge.com/index.php/SS4000-E/Notes

And my current code can be found as a patch here:
http://www.tomjudge.com/tmp/em7210.patch


Thanks in advance for the help

Tom


RedBoot> load -b 0x01008000 kernel
Using default protocol (TFTP)
Address offset = 0x40000000
Entry point: 0x01008100, address range: 0x01008000-0x01337274
RedBoot> go
pmap_bootstrap: WARNING! wrong cache mode for L2 pte @ 0xc1003c00
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 #14: Sat Sep 26 05:30:30 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
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
Fatal kernel mode data abort: 'External Linefetch Abort (P)'
trapframe: 0xc00faae4
FSR=00000406, FAR=Invalid,  spsr=200000d3
r0 =c13e3c00, r1 =cd5b9000, r2 =00000010, r3 =0000000a
r4 =c317e008, r5 =cd5b9000, r6 =c13e3c00, r7 =c128d4fc
r8 =c317e008, r9 =c1397280, r10=c317e000, r11=c00fab54
r12=c00fab58, ssp=c00fab30, slr=c1022a88, pc =c1022a84

[thread pid 0 tid 100000 ]
Stopped at      e1000_init_script_state_82541+0x24c:    blx     r7
db> bt
Tracing pid 0 tid 100000 td 0xc133b240
db_trace_thread() at db_trace_thread+0xc
scp=0xc1291910 rlv=0xc100d0f0 (db_command_init+0x2a8)
        rsp=0xc00fa7e0 rfp=0xc00fa7fc
        r10=0x00000001 r9=0xc1340d94
        r8=0xc13385c4 r7=0x00000062 r6=0x00000002 r5=0x00000010
        r4=0xc133b240
db_command_init() at db_command_init+0x1d0
scp=0xc100d018 rlv=0xc100cba0 (db_skip_to_eol+0x49c)
        rsp=0xc00fa800 rfp=0xc00fa8a4
        r5=0x00000000 r4=0xc13188d0
db_skip_to_eol() at db_skip_to_eol+0x1d0
scp=0xc100c8d4 rlv=0xc100cd0c (db_command_loop+0x60)
        rsp=0xc00fa8a8 rfp=0xc00fa8b4
        r10=0x00000000 r8=0x00000406
        r7=0xc00faae4 r6=0xc1340d90 r5=0x600000d3 r4=0xc00fa8c0
db_command_loop() at db_command_loop+0xc
scp=0xc100ccb8 rlv=0xc100f050 (X_db_sym_numargs+0xf4)
        rsp=0xc00fa8b8 rfp=0xc00fa9d4
X_db_sym_numargs() at X_db_sym_numargs+0x14
scp=0xc100ef70 rlv=0xc10fc0c4 (kdb_trap+0xa4)
        rsp=0xc00fa9d8 rfp=0xc00faa00
        r4=0x000000c0
kdb_trap() at kdb_trap+0xc
scp=0xc10fc02c rlv=0xc12a1dc4 (badaddr_read+0x280)
        rsp=0xc00faa04 rfp=0xc00faa20
        r10=0x00000000 r9=0xc1397280
        r8=0xc00faae4 r7=0x00000406 r6=0x00000000 r5=0x00000406
        r4=0xc00faae4
badaddr_read() at badaddr_read+0xfc
scp=0xc12a1c40 rlv=0xc12a225c (prefetch_abort_handler+0x440)
        rsp=0xc00faa24 rfp=0xc00faa44
        r6=0xc133b240 r5=0xc00faef8
        r4=0xc00faae4
prefetch_abort_handler() at prefetch_abort_handler+0x378
scp=0xc12a2194 rlv=0xc12a2428 (data_abort_handler+0x110)
        rsp=0xc00faa48 rfp=0xc00faae0
        r7=0xc133b240 r6=0xc13e3c00
        r5=0xc00faef8 r4=0xc133af78
data_abort_handler() at data_abort_handler+0xc
scp=0xc12a2324 rlv=0xc129334c (address_exception_entry+0x50)
        rsp=0xc00faae4 rfp=0xc00fab54
        r10=0xc317e000 r9=0xc1397280
        r8=0xc317e008 r7=0xc128d4fc r6=0xc13e3c00 r5=0xffff1004
        r4=0xc317e008
e1000_init_script_state_82541() at e1000_init_script_state_82541+0x20c
scp=0xc1022a44 rlv=0xc10319d0 (e1000_init_nvm_params+0x24)
        rsp=0xc00fab58 rfp=0xc00fab64
        r7=0xc0000002 r6=0x00000001
        r5=0xc317e008 r4=0x00000000
e1000_init_nvm_params() at e1000_init_nvm_params+0xc
scp=0xc10319b8 rlv=0xc1032914 (e1000_setup_init_funcs+0x150)
        rsp=0xc00fab68 rfp=0xc00fab80
e1000_setup_init_funcs() at e1000_setup_init_funcs+0xc
scp=0xc10327d0 rlv=0xc101d8e0 (db_write_cmd+0xa85c)
        rsp=0xc00fab84 rfp=0xc00fac0c
        r6=0x0000443c r5=0xc1397280
        r4=0x00004400
db_write_cmd() at db_write_cmd+0x9ee8
scp=0xc101cf6c rlv=0xc10f6d1c (device_attach+0x2c8)
        rsp=0xc00fac10 rfp=0xc00fac4c
        r10=0xc1397280 r9=0x00000009
        r8=0xffffffff r7=0xc10f53c4 r6=0xc13972cc r5=0x80000000
        r4=0xc1397300
device_attach() at device_attach+0xc
scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34)
        rsp=0xc00fac50 rfp=0xc00fac60
        r10=0xc1397300 r8=0xffffffff
        r7=0xc10f53c4 r6=0x00000000 r5=0x00000000 r4=0xc1397280
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20)
        rsp=0xc00fac64 rfp=0xc00fac74
        r4=0xc1397280
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc10f80f0 rlv=0xc105c318 (pci_add_children+0x240)
        rsp=0xc00fac78 rfp=0xc00fac98
        r4=0xc1397300
pci_add_children() at pci_add_children+0x154
scp=0xc105c22c rlv=0xc10f6d1c (device_attach+0x2c8)
        rsp=0xc00fac9c rfp=0xc00facd8
        r6=0xc139734c r5=0x80000000
        r4=0xc13da400
device_attach() at device_attach+0xc
scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34)
        rsp=0xc00facdc rfp=0xc00facec
        r10=0xc13da400 r8=0xffffffff
        r7=0x00000000 r6=0xc13da400 r5=0xc13b6318 r4=0xc1397300
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20)
        rsp=0xc00facf0 rfp=0xc00fad00
        r4=0xc1397300
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc10f80f0 rlv=0xc12a7824 (i80321_sdram_bounds+0x860)
        rsp=0xc00fad04 rfp=0xc00fad20
        r4=0xc13b6360
i80321_sdram_bounds() at i80321_sdram_bounds+0x6f4
scp=0xc12a76b8 rlv=0xc10f6d1c (device_attach+0x2c8)
        rsp=0xc00fad24 rfp=0xc00fad60
        r7=0xc10f53c4 r6=0xc13da44c
        r5=0x80000000 r4=0xc13da680
device_attach() at device_attach+0xc
scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34)
        rsp=0xc00fad64 rfp=0xc00fad74
        r10=0xc13da680 r8=0xc13da680
        r7=0x40000004 r6=0xc13e3c00 r5=0x00000000 r4=0xc13da400
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20)
        rsp=0xc00fad78 rfp=0xc00fad88
        r4=0xc13da400
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc10f80f0 rlv=0xc12a8460 (iq80321_attach+0x370)
        rsp=0xc00fad8c rfp=0xc00fadb8
        r4=0xc12de3c8
iq80321_attach() at iq80321_attach+0xc
scp=0xc12a80fc rlv=0xc10f6d1c (device_attach+0x2c8)
        rsp=0xc00fadbc rfp=0xc00fadf8
        r8=0xffffffff r7=0xc10f53c4
        r6=0xc13da6cc r5=0x80000000 r4=0xc13da700
device_attach() at device_attach+0xc
scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34)
        rsp=0xc00fadfc rfp=0xc00fae0c
        r10=0xc13da700 r8=0xffffffff
        r7=0xc10f53c4 r6=0xc13da74c r5=0x80000000 r4=0xc13da680
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc10f80b8 rlv=0xc10f8104 (bus_generic_attach+0x20)
        rsp=0xc00fae10 rfp=0xc00fae20
        r4=0xc13da680
bus_generic_attach() at bus_generic_attach+0xc
scp=0xc10f80f0 rlv=0xc1296270 (minidumpsys+0xaf4)
        rsp=0xc00fae24 rfp=0xc00fae34
        r4=0xc13da700
minidumpsys() at minidumpsys+0xae4
scp=0xc1296260 rlv=0xc10f6d1c (device_attach+0x2c8)
        rsp=0xc00fae38 rfp=0xc00fae74
        r4=0xc12d1318
device_attach() at device_attach+0xc
scp=0xc10f6a60 rlv=0xc10f80e0 (device_probe_and_attach+0x34)
        rsp=0xc00fae78 rfp=0xc00fae88
        r10=0x0000000a r8=0x00000000
        r7=0xa10081a4 r6=0xc13dab80 r5=0xc1335374 r4=0xc13da700
device_probe_and_attach() at device_probe_and_attach+0xc
scp=0xc10f80b8 rlv=0xc10f83c4 (bus_generic_new_pass+0xe4)
        rsp=0xc00fae8c rfp=0xc00faea4
        r4=0xc13da700
bus_generic_new_pass() at bus_generic_new_pass+0xc
scp=0xc10f82ec rlv=0xc10f43c0 (bus_set_pass+0x98)
        rsp=0xc00faea8 rfp=0xc00faec0
        r6=0x7fffffff r5=0xc13dab80
        r4=0xc13f1a80
bus_set_pass() at bus_set_pass+0xc
scp=0xc10f4334 rlv=0xc10f4408 (root_bus_configure+0x14)
        rsp=0xc00faec4 rfp=0xc00faed0
        r6=0x00000006 r5=0xa10081b0
        r4=0xc12e0358
root_bus_configure() at root_bus_configure+0xc
scp=0xc10f4400 rlv=0xc128c310 (xdr_sizeof+0x1d0)
        rsp=0xc00faed4 rfp=0xc00faee0
xdr_sizeof() at xdr_sizeof+0x1cc
scp=0xc128c30c rlv=0xc1083620 (mi_startup+0xdc)
        rsp=0xc00faee4 rfp=0xc00faef4
mi_startup() at mi_startup+0xc
scp=0xc1083550 rlv=0xc1008248 (btext+0x148)
        rsp=0xc00faef8 rfp=0x00000000
        r4=0xa1008288
db>





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