Linux doesn not boot from u-boot on ML403

Hi All,

     I run Linux 2.6.21 (by Grant) on my Avnet Virtex-4 evaluation board
(ML403 like). When I load zIinux.elf
via jtag to the board it runs properly:

loaded at:     00400000 004F9138                                                                                                  
board data at: 004F7120 004F7138                                                                                                  
relocated to:  004040B4 004040CC                                                                                                  
zimage at:     00404E59 004F6EE6                                                                                                  
avail ram:     004FA000 01FFFFFF                                                                                                                                                                                                                                     
Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp 
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...done.                                                                                                       
Now booting the kernel                                                                                                             
[0.000000] Linux version 2.6.21-rc6 (root@pc5215) (gcc version 4.0.2) #11
Tue Aug 7 13:46:19 EST 2007                 
[0.000000] Xilinx ML403 Reference System (Virtex-4 FX)                                                                         
.
.
.
.
It goes to the successful end.

I have build u-boot 1.2.0 with uart lite and temac support.

When I am trying to run uImage (build out of zImage) it does not run.

The steps I do are as following:

1. I build uImage withing the kernel tree (make uImage)
2. I load via jtag the u-boot 1.2.0

XMD% dow u-boot.elf
        section, .text: 0x00800000-0x0081513c
        section, .resetvec: 0x0081513c-0x00815140
        section, .rodata: 0x00815140-0x00817ce0
        section, .reloc: 0x00817d00-0x00818674
        section, .data: 0x00818674-0x00818b08
        section, .data.rel: 0x00818b08-0x00818b34
        section, .data.rel.local: 0x00818b34-0x00818f6c
        section, .u_boot_cmd: 0x00818f6c-0x008191dc
        section, .bss: 0x00819200-0x0081dd04

3. I transfer uImage to the RAM memory of my Avnet board:
TFTP from server 129.129.144.113; our IP address is 129.129.144.157                                                               
Filename 'uImage'.                                                                                                                 
Load address: 0x1000000                                                                                                           
Loading: #################################################################                                                                 
#################################################################                                                                 
################################################################                                                         
done                                                                                                                              
Bytes transferred = 991438 (f20ce hex)                                                                                            

4. I am trying to start the kernel

=> bootm 0x1000000
                                                                                                                                                                                                                                          
## Booting image at 01000000 ...                                                                                                     
Image Name:   Linux-2.6.21-rc6                                                                                                    
Image Type:   PowerPC Linux Kernel Image (gzip compressed)                                                                        
Data Size:    991375 Bytes = 968.1 kB                                                                                             
Load Address: 00000000                                                                                                            
Entry Point:  00000000                                                                                                            
Verifying Checksum ... OK                                                                                                         
Uncompressing Kernel Image ... OK                                                                                              


After all system hangs

I have tried to change the Load Address and Entry Point to 0x400000 (mkimage
-a 0x400000 -e 0x400000)
but the system hangs like in the first case.

my bootargs are:
console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp 
ip=::::virtex4-mirek:eth0:dhcp panic=1

Those bootargs where tested with zImage.elf and seem to be fine.

Does somebody has some suggestion?

Thank you in advance for any hint on that.

Mirek

-- 
View this message in context: http://www.nabble.com/Linux-doesn-not-boot-from-u-boot-on-ML403-tf4335322.html#a12347049
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

On 8/27/07, Mirek23 [off-list ref] wrote:

4. I am trying to start the kernel

=> bootm 0x1000000

## Booting image at 01000000 ...
Image Name:   Linux-2.6.21-rc6
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:    991375 Bytes = 968.1 kB
Load Address: 00000000
Entry Point:  00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Have you looked in __log_buf for kernel messages?
What does your u-boot env look like?
Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi Grant,

	Thank you for your response.

My u-boot bootargs is set to:
console=ttyUL0,9600 root=/dev/nfs rw nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp  ip=::::virtex4-mirek:eth0:dhcp panic=1

where I can find __log_buf for kernel messages?



Best Regards

Mirek



On Mon, 27 Aug 2007, Grant Likely wrote:

On 8/27/07, Mirek23 [off-list ref] wrote:

quoted

4. I am trying to start the kernel

=> bootm 0x1000000

## Booting image at 01000000 ...
Image Name:   Linux-2.6.21-rc6
Image Type:   PowerPC Linux Kernel Image (gzip compressed)
Data Size:    991375 Bytes = 968.1 kB
Load Address: 00000000
Entry Point:  00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Have you looked in __log_buf for kernel messages?
What does your u-boot env look like?
Do you have 'console=ttyUL0' or 'console=ttyS0' in the kernel command line?

Cheers,
g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/27/07, Miroslaw Dach [off-list ref] wrote:

Hi Grant,

        Thank you for your response.

My u-boot bootargs is set to:
console=ttyUL0,9600 root=/dev/nfs rw nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp  ip=::::virtex4-mirek:eth0:dhcp panic=1

Drop the ',9600'.  It's irrelevant for uartlite.

where I can find __log_buf for kernel messages?

Search for __log_buf in System.map (in the kernel source tree).  Use a
debugger to look at the memory.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

I have done additional test with my u-boot and linux kernel.

I have downloaded u-boot(.elf) and zImage.elf via jtag to SDRAM:

The SDRAM has 32 MB: 
Address Map for Processor ppc405_0
  (0x00000000-0x01ffffff) DDR_SDRAM_1   plb

The steps I have doe are as following:

1. XMD% dow -data zImage.elf 0xe00000
2. XMD% dow u-boot.elf
        section, .text: 0x00800000-0x0081513c
        section, .resetvec: 0x0081513c-0x00815140
        section, .rodata: 0x00815140-0x00817ce0
        section, .reloc: 0x00817d00-0x00818674
        section, .data: 0x00818674-0x00818b08
        section, .data.rel: 0x00818b08-0x00818b34
        section, .data.rel.local: 0x00818b34-0x00818f6c
        section, .u_boot_cmd: 0x00818f6c-0x008191dc
        section, .bss: 0x00819200-0x0081dd04
Downloaded Program u-boot.elf
Setting PC with program start addr = 0x00800100
PC reset to 0x00800100, Clearing MSR Register

3. XMD% run

------------------------------------------------------------------
                output on the serial port
------------------------------------------------------------------
 
U-Boot 1.2.0 (Aug 28 2007 - 11:56:19)


U-Boot: checkboard
DRAM:  U-Boot: initdram
32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0 
=> 

U-Boot 1.2.0 (Aug 27 2007 - 14:23:15)


U-Boot: checkboard
DRAM:  U-Boot: initdram
32 MB
Using default environment

In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0 
=> bootelf 0xe00000
Loading .text @ 0x00400000 (14028 bytes)
Loading .data @ 0x00404000 (995328 bytes)
Clearing .bss @ 0x004f7000 (8504 bytes)
## Starting application at 0x00400000 ...

loaded at:     00400000 004F9138
board data at: 004F7120 004F7138
relocated to:  004040B4 004040CC
zimage at:     00404E59 004F6EE8
avail ram:     004FA000 01FFFFFF

Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw 
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp  
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...


After that system just hangs.

I do not understand why it is possible to run zImage.elf straight from jtag
but it hangs when started from u-boot.

Is it any fundamental problem with running Linux from u-boot on ML403 
(Virtex-4) boards?

Best Regards

Mirek

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...


After that system just hangs.

I do not understand why it is possible to run zImage.elf straight from jtag
but it hangs when started from u-boot.

Is it any fundamental problem with running Linux from u-boot on ML403
(Virtex-4) boards?

No there isn't.  It should work.  Most likely the kernel did not hang
immediately, but rather the console is not setup correctly.  You need
to halt the processor after the hang and look at __log_buf in memory
(Find the address in System.map).

Cheers,
g.

Best Regards

Mirek

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi Grant,

	Thanks for your answer.
I have found in the System.map :
c020f0c4 b __log_buf

Is the address c020f0c4 relative to the .data segment?

I understand that when the system hangs I should type in the XMD window 
stop.

Is there anyway to examine the memory from the XMD window? or should I 
reload the u-boot and examine the memory from u-boot?

Best Regards

Mirek



On Tue, 28 Aug 2007, Grant Likely wrote:

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

quoted

Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...


After that system just hangs.

I do not understand why it is possible to run zImage.elf straight from jtag
but it hangs when started from u-boot.

Is it any fundamental problem with running Linux from u-boot on ML403
(Virtex-4) boards?

No there isn't.  It should work.  Most likely the kernel did not hang
immediately, but rather the console is not setup correctly.  You need
to halt the processor after the hang and look at __log_buf in memory
(Find the address in System.map).

Cheers,
g.

quoted

Best Regards

Mirek

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

Hi Grant,

        Thanks for your answer.
I have found in the System.map :
c020f0c4 b __log_buf

Is the address c020f0c4 relative to the .data segment?

0xc0000000 are virtual kernel addresses; not physical addresses.  If
the MMU is still on, then you need to use the virtual address to
examine memory.  If the MMU is off (such as after reloading u-boot),
then you need to change 0xCxxxxxxx to 0x0xxxxxxxx.

I understand that when the system hangs I should type in the XMD window
stop.

Is there anyway to examine the memory from the XMD window? or should I
reload the u-boot and examine the memory from u-boot?

I don't know; I've never used XMD.  Read the XMD documentation.  You
can do it from u-boot too.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi Grant,

	I have did as you suggested:

1. I have started u-boot
2. I have loaded zImage.elf to the memory 0xf00000
3. I have typed: bootelf 0xf00000

Linux has hanged during uncompressing

4. I have stopped the system and reloaded u-boot to examine __log_buf
   ( address 0x20f0c4)

Unfortunately all the bytes were set just to zero.

5. I have stopped the system
6. I have downloaded via jtag the zImage.elf and started it
   the system has started properly
7. I have stopped the system and reloaded u-boot to examine the memory
8. I have typed: md 0x20f0c4 100 and it showed me the buffer:

0020f0c4: 3c353e5b 20202020 302e3030 30303030    <5>[    0.000000
0020f0d4: 5d204c69 6e757820 76657273 696f6e20    ] Linux version 
0020f0e4: 322e362e 32312d72 63362028 726f6f74    2.6.21-rc6 (root
0020f0f4: 40706335 32313529 20286763 63207665    @pc5215) (gcc ve
0020f104: 7273696f 6e20342e 302e3229 20233136    rsion 4.0.2) #16
0020f114: 204d6f6e 20417567 20323720 31323a33     Mon Aug 27 12:3
0020f124: 373a3038 20434553 54203230 30370a3c    7:08 CEST 2007.<
0020f134: 363e5b20 20202030 2e303030 3030305d    6>[    0.000000]
0020f144: 2058696c 696e7820 4d4c3430 33205265     Xilinx ML403 Re
0020f154: 66657265 6e636520 53797374 656d2028    ference System (
0020f164: 56697274 65782d34 20465829 0a3c373e    Virtex-4 FX).<7>
0020f174: 5b202020 20302e30 30303030 305d2045    [    0.000000] E
0020f184: 6e746572 696e6720 6164645f 61637469    ntering add_acti
0020f194: 76655f72 616e6765 28302c20 302c2038    ve_range(0, 0, 8
0020f1a4: 31393129 20302065 6e747269 6573206f    191) 0 entries o
0020f1b4: 66203235 36207573 65640a3c 343e5b20    f 256 used.<4>[ 
0020f1c4: 20202030 2e303030 3030305d 205a6f6e       0.000000] Zon
0020f1d4: 65205046 4e207261 6e676573 3a0a3c34    e PFN ranges:.<4

So it seams to be that the address points to the __log_buf (I hope).

Does it mean that when I try to start zImage kernel from u-boot 
it hangs during uncompressing the image and it does even start booting?

Best Regards

Mirek  


On Tue, 28 Aug 2007, Grant Likely wrote:

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

quoted

Hi Grant,

        Thanks for your answer.
I have found in the System.map :
c020f0c4 b __log_buf

Is the address c020f0c4 relative to the .data segment?

0xc0000000 are virtual kernel addresses; not physical addresses.  If
the MMU is still on, then you need to use the virtual address to
examine memory.  If the MMU is off (such as after reloading u-boot),
then you need to change 0xCxxxxxxx to 0x0xxxxxxxx.

quoted

I understand that when the system hangs I should type in the XMD window
stop.

Is there anyway to examine the memory from the XMD window? or should I
reload the u-boot and examine the memory from u-boot?

I don't know; I've never used XMD.  Read the XMD documentation.  You
can do it from u-boot too.

g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

8. I have typed: md 0x20f0c4 100 and it showed me the buffer:

0020f0c4: 3c353e5b 20202020 302e3030 30303030    <5>[    0.000000
0020f0d4: 5d204c69 6e757820 76657273 696f6e20    ] Linux version
0020f0e4: 322e362e 32312d72 63362028 726f6f74    2.6.21-rc6 (root
0020f0f4: 40706335 32313529 20286763 63207665    @pc5215) (gcc ve
0020f104: 7273696f 6e20342e 302e3229 20233136    rsion 4.0.2) #16
0020f114: 204d6f6e 20417567 20323720 31323a33     Mon Aug 27 12:3
0020f124: 373a3038 20434553 54203230 30370a3c    7:08 CEST 2007.<
0020f134: 363e5b20 20202030 2e303030 3030305d    6>[    0.000000]
0020f144: 2058696c 696e7820 4d4c3430 33205265     Xilinx ML403 Re
0020f154: 66657265 6e636520 53797374 656d2028    ference System (
0020f164: 56697274 65782d34 20465829 0a3c373e    Virtex-4 FX).<7>
0020f174: 5b202020 20302e30 30303030 305d2045    [    0.000000] E
0020f184: 6e746572 696e6720 6164645f 61637469    ntering add_acti
0020f194: 76655f72 616e6765 28302c20 302c2038    ve_range(0, 0, 8
0020f1a4: 31393129 20302065 6e747269 6573206f    191) 0 entries o
0020f1b4: 66203235 36207573 65640a3c 343e5b20    f 256 used.<4>[
0020f1c4: 20202030 2e303030 3030305d 205a6f6e       0.000000] Zon
0020f1d4: 65205046 4e207261 6e676573 3a0a3c34    e PFN ranges:.<4

So it seams to be that the address points to the __log_buf (I hope).

Does it mean that when I try to start zImage kernel from u-boot
it hangs during uncompressing the image and it does even start booting?

Think about what you're looking at.  That buffer is ASCII text.  Does
it look like the entire buffer is displayed, or does it look like
there is more?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

This buffer refers to the kernel which I boot straight from jtag but not 
u-boot.

Below I attach whole buffer printout:

=> 0x20f0c4 200
0020f0c4: 3c353e5b 20202020 302e3030 30303030    <5>[    0.000000
0020f0d4: 5d204c69 6e757820 76657273 696f6e20    ] Linux version 
0020f0e4: 322e362e 32312d72 63362028 726f6f74    2.6.21-rc6 (root
0020f0f4: 40706335 32313529 20286763 63207665    @pc5215) (gcc ve
0020f104: 7273696f 6e20342e 302e3229 20233136    rsion 4.0.2) #16
0020f114: 204d6f6e 20417567 20323720 31323a33     Mon Aug 27 12:3
0020f124: 373a3038 20434553 54203230 30370a3c    7:08 CEST 2007.<
0020f134: 363e5b20 20202030 2e303030 3030305d    6>[    0.000000]
0020f144: 2058696c 696e7820 4d4c3430 33205265     Xilinx ML403 Re
0020f154: 66657265 6e636520 53797374 656d2028    ference System (
0020f164: 56697274 65782d34 20465829 0a3c373e    Virtex-4 FX).<7>
0020f174: 5b202020 20302e30 30303030 305d2045    [    0.000000] E
0020f184: 6e746572 696e6720 6164645f 61637469    ntering add_acti
0020f194: 76655f72 616e6765 28302c20 302c2038    ve_range(0, 0, 8
0020f1a4: 31393129 20302065 6e747269 6573206f    191) 0 entries o
0020f1b4: 66203235 36207573 65640a3c 343e5b20    f 256 used.<4>[ 
0020f1c4: 20202030 2e303030 3030305d 205a6f6e       0.000000] Zon
0020f1d4: 65205046 4e207261 6e676573 3a0a3c34    e PFN ranges:.<4
0020f1e4: 3e5b2020 2020302e 30303030 30305d20    >[    0.000000] 
0020f1f4: 2020444d 41202020 20202020 20202020      DMA 
0020f204: 20203020 2d3e2020 20202038 3139310a      0 ->     8191.
0020f214: 3c343e5b 20202020 302e3030 30303030    <4>[    0.000000
0020f224: 5d202020 4e6f726d 616c2020 20202020    ]   Normal      
0020f234: 20383139 31202d3e 20202020 20383139     8191 ->     819
0020f244: 310a3c34 3e5b2020 2020302e 30303030    1.<4>[    0.0000
0020f254: 30305d20 6561726c 795f6e6f 64655f6d    00] early_node_m
0020f264: 61705b31 5d206163 74697665 2050464e    ap[1] active PFN
0020f274: 2072616e 6765730a 3c343e5b 20202020     ranges.<4>[    
0020f284: 302e3030 30303030 5d202020 2020303a    0.000000]     0:
0020f294: 20202020 20202020 30202d3e 20202020            0 ->    
0020f2a4: 20383139 310a3c37 3e5b2020 2020302e     8191.<7>[    0.
0020f2b4: 30303030 30305d20 4f6e206e 6f646520    000000] On node 
0020f2c4: 3020746f 74616c70 61676573 3a203831    0 totalpages: 81
0020f2d4: 39310a3c 373e5b20 20202030 2e303030    91.<7>[    0.000
0020f2e4: 3030305d 20202044 4d41207a 6f6e653a    000]   DMA zone:
0020f2f4: 20363320 70616765 73207573 65642066     63 pages used f
0020f304: 6f72206d 656d6d61 700a3c37 3e5b2020    or memmap.<7>[  
0020f314: 2020302e 30303030 30305d20 2020444d      0.000000]   DM
0020f324: 41207a6f 6e653a20 30207061 67657320    A zone: 0 pages 
0020f334: 72657365 72766564 0a3c373e 5b202020    reserved.<7>[   
0020f344: 20302e30 30303030 305d2020 20444d41     0.000000]   DMA
0020f354: 207a6f6e 653a2038 31323820 70616765     zone: 8128 page
0020f364: 732c204c 49464f20 62617463 683a300a    s, LIFO batch:0.
0020f374: 3c373e5b 20202020 302e3030 30303030    <7>[    0.000000
0020f384: 5d202020 4e6f726d 616c207a 6f6e653a    ]   Normal zone:
0020f394: 20302070 61676573 20757365 6420666f     0 pages used fo
0020f3a4: 72206d65 6d6d6170 0a3c343e 5b202020    r memmap.<4>[   
0020f3b4: 20302e30 30303030 305d2042 75696c74     0.000000] Built
0020f3c4: 2031207a 6f6e656c 69737473 2e202054     1 zonelists.  T
0020f3d4: 6f74616c 20706167 65733a20 38313238    otal pages: 8128
0020f3e4: 0a3c353e 5b202020 20302e30 30303030    .<5>[    0.00000
0020f3f4: 305d204b 65726e65 6c20636f 6d6d616e    0] Kernel comman
0020f404: 64206c69 6e653a20 636f6e73 6f6c653d    d line: console=
0020f414: 74747955 4c302c39 36303020 726f6f74    ttyUL0,9600 root
0020f424: 3d2f6465 762f6e66 73207277 206e6673    =/dev/nfs rw nfs
0020f434: 726f6f74 3d313239 2e313239 2e313434    root=129.129.144
0020f444: 2e313133 3a2f6f70 742f656c 646b3431    .113:/opt/eldk41
0020f454: 2f707063 5f347878 2c746370 20206970    /ppc_4xx,tcp  ip
0020f464: 3d3a3a3a 3a766972 74657834 2d6d6972    =::::virtex4-mir
0020f474: 656b3a65 7468303a 64686370 2070616e    ek:eth0:dhcp pan
0020f484: 69633d31 0a3c363e 5b202020 20302e30    ic=1.<6>[    0.0
0020f494: 30303030 305d2058 696c696e 7820494e    00000] Xilinx IN
0020f4a4: 54432023 30206174 20307834 31323030    TC #0 at 0x41200
0020f4b4: 30303020 6d617070 65642074 6f203078    000 mapped to 0x
0020f4c4: 46444646 46303030 0a3c343e 5b202020    FDFFF000.<4>[   
0020f4d4: 20302e30 30303030 305d2050 49442068     0.000000] PID h
0020f4e4: 61736820 7461626c 6520656e 74726965    ash table entrie
0020f4f4: 733a2031 32382028 6f726465 723a2037    s: 128 (order: 7
0020f504: 2c203531 32206279 74657329 0a3c343e    , 512 bytes).<4>
0020f514: 5b202020 20302e30 30303237 385d2043    [    0.000278] C
0020f524: 6f6e736f 6c653a20 636f6c6f 75722064    onsole: colour d
0020f534: 756d6d79 20646576 69636520 38307832    ummy device 80x2
0020f544: 350a3c34 3e5b2020 2020302e 30303036    5.<4>[    0.0006
0020f554: 30335d20 44656e74 72792063 61636865    03] Dentry cache
0020f564: 20686173 68207461 626c6520 656e7472     hash table entr
0020f574: 6965733a 20343039 3620286f 72646572    ies: 4096 (order
0020f584: 3a20322c 20313633 38342062 79746573    : 2, 16384 bytes
0020f594: 290a3c34 3e5b2020 2020302e 30303131    ).<4>[    0.0011
0020f5a4: 37315d20 496e6f64 652d6361 63686520    71] Inode-cache 
0020f5b4: 68617368 20746162 6c652065 6e747269    hash table entri
0020f5c4: 65733a20 32303438 20286f72 6465723a    es: 2048 (order:
0020f5d4: 20312c20 38313932 20627974 6573290a     1, 8192 bytes).
0020f5e4: 3c343e5b 20202020 302e3031 30393034    <4>[    0.010904
0020f5f4: 5d204d65 6d6f7279 3a203330 3238386b    ] Memory: 30288k
0020f604: 20617661 696c6162 6c652028 31353638     available (1568
0020f614: 6b206b65 726e656c 20636f64 652c2035    k kernel code, 5
0020f624: 31326b20 64617461 2c203936 6b20696e    12k data, 96k in
0020f634: 69742c20 306b2068 6967686d 656d290a    it, 0k highmem).
0020f644: 3c373e5b 20202020 302e3031 32363435    <7>[    0.012645
0020f654: 5d204361 6c696272 6174696e 67206465    ] Calibrating de
0020f664: 6c617920 6c6f6f70 2e2e2e20 39392e35    lay loop... 99.5
0020f674: 3820426f 676f4d49 50532028 6c706a3d    8 BogoMIPS (lpj=
0020f684: 31393931 3638290a 3c343e5b 20202020    199168).<4>[    
0020f694: 302e3039 37303031 5d204d6f 756e742d    0.097001] Mount-
0020f6a4: 63616368 65206861 73682074 61626c65    cache hash table
0020f6b4: 20656e74 72696573 3a203531 320a3c36     entries: 512.<6
0020f6c4: 3e5b2020 2020302e 31303230 32365d20    >[    0.102026] 
0020f6d4: 4e45543a 20526567 69737465 72656420    NET: Registered 
0020f6e4: 70726f74 6f636f6c 2066616d 696c7920    protocol family 
0020f6f4: 31360a3c 363e5b20 20202030 2e313233    16.<6>[    0.123
0020f704: 3532335d 204e4554 3a205265 67697374    523] NET: Regist
0020f714: 65726564 2070726f 746f636f 6c206661    ered protocol fa
0020f724: 6d696c79 20320a3c 343e5b20 20202030    mily 2.<4>[    0
0020f734: 2e313630 3438315d 20495020 726f7574    .160481] IP rout
0020f744: 65206361 63686520 68617368 20746162    e cache hash tab
0020f754: 6c652065 6e747269 65733a20 31303234    le entries: 1024
0020f764: 20286f72 6465723a 20302c20 34303936     (order: 0, 4096
0020f774: 20627974 6573290a 3c343e5b 20202020     bytes).<4>[    
0020f784: 302e3136 31323734 5d205443 50206573    0.161274] TCP es
0020f794: 7461626c 69736865 64206861 73682074    tablished hash t
0020f7a4: 61626c65 20656e74 72696573 3a203130    able entries: 10
0020f7b4: 32342028 6f726465 723a2031 2c203831    24 (order: 1, 81
0020f7c4: 39322062 79746573 290a3c34 3e5b2020    92 bytes).<4>[  
0020f7d4: 2020302e 31363135 39355d20 54435020      0.161595] TCP 
0020f7e4: 62696e64 20686173 68207461 626c6520    bind hash table 
0020f7f4: 656e7472 6965733a 20313032 3420286f    entries: 1024 (o
0020f804: 72646572 3a20302c 20343039 36206279    rder: 0, 4096 by
0020f814: 74657329 0a3c363e 5b202020 20302e31    tes).<6>[    0.1
0020f824: 36313831 385d2054 43503a20 48617368    61818] TCP: Hash
0020f834: 20746162 6c657320 636f6e66 69677572     tables configur
0020f844: 65642028 65737461 626c6973 68656420    ed (established 
0020f854: 31303234 2062696e 64203130 3234290a    1024 bind 1024).
0020f864: 3c363e5b 20202020 302e3136 31383938    <6>[    0.161898
0020f874: 5d205443 50207265 6e6f2072 65676973    ] TCP reno regis
0020f884: 74657265 640a3c36 3e5b2020 2020302e    tered.<6>[    0.
0020f894: 31373934 37385d20 696f2073 63686564    179478] io sched
0020f8a4: 756c6572 206e6f6f 70207265 67697374    uler noop regist
0020f8b4: 65726564 0a3c363e 5b202020 20302e31    ered.<6>[    0.1
=> 
0020f8c4: 37393536 315d2069 6f207363 68656475    79561] io schedu
0020f8d4: 6c657220 616e7469 63697061 746f7279    ler anticipatory
0020f8e4: 20726567 69737465 72656420 28646566     registered (def
0020f8f4: 61756c74 290a3c36 3e5b2020 2020302e    ault).<6>[    0.
0020f904: 31373936 33375d20 696f2073 63686564    179637] io sched
0020f914: 756c6572 20646561 646c696e 65207265    uler deadline re
0020f924: 67697374 65726564 0a3c363e 5b202020    gistered.<6>[   
0020f934: 20302e31 37393932 305d2069 6f207363     0.179920] io sc
0020f944: 68656475 6c657220 63667120 72656769    heduler cfq regi
0020f954: 73746572 65640a3c 363e5b20 20202031    stered.<6>[    1
0020f964: 2e303034 3633395d 20756172 746c6974    .004639] uartlit
0020f974: 652e303a 20747479 554c3020 6174204d    e.0: ttyUL0 at M
0020f984: 4d494f20 30783430 36303030 30332028    MIO 0x40600003 (
0020f994: 69727120 3d203229 20697320 61207561    irq = 2) is a ua
0020f9a4: 72746c69 74650a3c 343e5b20 20202032    rtlite.<4>[    2
0020f9b4: 2e393031 3633335d 2052414d 4449534b    .901633] RAMDISK
0020f9c4: 20647269 76657220 696e6974 69616c69     driver initiali
0020f9d4: 7a65643a 20312052 414d2064 69736b73    zed: 1 RAM disks
0020f9e4: 206f6620 38313932 4b207369 7a652031     of 8192K size 1
0020f9f4: 30323420 626c6f63 6b73697a 650a3c36    024 blocksize.<6
0020fa04: 3e5b2020 2020322e 39393232 37395d20    >[    2.992279] 
0020fa14: 74756e3a 20556e69 76657273 616c2054    tun: Universal T
0020fa24: 554e2f54 41502064 65766963 65206472    UN/TAP device dr
0020fa34: 69766572 2c20312e 360a3c36 3e5b2020    iver, 1.6.<6>[  
0020fa44: 2020332e 30353239 36315d20 74756e3a      3.052961] tun:
0020fa54: 20284329 20313939 392d3230 3034204d     (C) 1999-2004 M
0020fa64: 6178204b 7261736e 79616e73 6b79203c    ax Krasnyansky <
0020fa74: 6d61786b 40717561 6c636f6d 6d2e636f    maxk@qualcomm.co
0020fa84: 6d3e0a3c 363e5b20 20202033 2e313238    m>.<6>[    3.128
0020fa94: 3733335d 20585465 6d61633a 20757369    733] XTemac: usi
0020faa4: 6e672046 49464f20 64697265 63742069    ng FIFO direct i
0020fab4: 6e746572 72757074 20647269 76656e20    nterrupt driven 
0020fac4: 6d6f6465 2e0a3c36 3e5b2020 2020332e    mode..<6>[    3.
0020fad4: 31393639 33355d20 65746825 643a2058    196935] eth%d: X
0020fae4: 54656d61 633a2050 48592064 65746563    Temac: PHY detec
0020faf4: 74656420 61742061 64647265 73732033    ted at address 3
0020fb04: 2e0a3c36 3e5b2020 2020332e 32353931    ..<6>[    3.2591
0020fb14: 35385d20 65746830 3a205869 6c696e78    58] eth0: Xilinx
0020fb24: 2054454d 41432023 30206174 20307838     TEMAC #0 at 0x8
0020fb34: 31323030 30303020 6d617070 65642074    1200000 mapped t
0020fb44: 6f203078 43323032 30303030 2c206972    o 0xC2020000, ir
0020fb54: 713d300a 3c363e5b 20202020 332e3334    q=0.<6>[    3.34
0020fb64: 32383037 5d206574 68303a20 5854656d    2807] eth0: XTem
0020fb74: 61632069 6420312e 30662c20 626c6f63    ac id 1.0f, bloc
0020fb84: 6b206964 20352c20 74797065 20380a3c    k id 5, type 8.<
0020fb94: 363e5b20 20202033 2e343033 3233385d    6>[    3.403238]
0020fba4: 206d6963 653a2050 532f3220 6d6f7573     mice: PS/2 mous
0020fbb4: 65206465 76696365 20636f6d 6d6f6e20    e device common 
0020fbc4: 666f7220 616c6c20 6d696365 0a3c363e    for all mice.<6>
0020fbd4: 5b202020 20332e34 36353937 385d2054    [    3.465978] T
0020fbe4: 43502063 75626963 20726567 69737465    CP cubic registe
0020fbf4: 7265640a 3c363e5b 20202020 332e3530    red.<6>[    3.50
0020fc04: 34383134 5d204e45 543a2052 65676973    4814] NET: Regis
0020fc14: 74657265 64207072 6f746f63 6f6c2066    tered protocol f
0020fc24: 616d696c 7920310a 3c363e5b 20202020    amily 1.<6>[    
0020fc34: 332e3535 37303939 5d204e45 543a2052    3.557099] NET: R
0020fc44: 65676973 74657265 64207072 6f746f63    egistered protoc
0020fc54: 6f6c2066 616d696c 79203137 0a3c363e    ol family 17.<6>
0020fc64: 5b202020 20342e31 31333537 345d2065    [    4.113574] e
0020fc74: 7468303a 20585465 6d61633a 204f7074    th0: XTemac: Opt
0020fc84: 696f6e73 3a203078 62386632 0a3c363e    ions: 0xb8f2.<6>
0020fc94: 5b202020 20382e31 34353433 305d2065    [    8.145430] e
0020fca4: 7468303a 20585465 6d61633a 20576520    th0: XTemac: We 
0020fcb4: 72656e65 676f7469 61746564 20746865    renegotiated the
0020fcc4: 20737065 65642074 6f3a2031 30300a3c     speed to: 100.<
0020fcd4: 363e5b20 20202038 2e323132 3134375d    6>[    8.212147]
0020fce4: 20657468 303a2058 54656d61 633a2073     eth0: XTemac: s
0020fcf4: 70656564 20736574 20746f20 3130304d    peed set to 100M
0020fd04: 622f730a 3c353e5b 20202020 392e3237    b/s.<5>[    9.27
0020fd14: 36303637 5d205365 6e64696e 67204448    6067] Sending DH
0020fd24: 43502072 65717565 73747320 2e2c204f    CP requests ., O
0020fd34: 4b0a3c34 3e5b2020 2020392e 38343830    K.<4>[    9.8480
0020fd44: 38355d20 49502d43 6f6e6669 673a2047    85] IP-Config: G
0020fd54: 6f742044 48435020 616e7377 65722066    ot DHCP answer f
0020fd64: 726f6d20 3235352e 3235352e 3235352e    rom 255.255.255.
0020fd74: 3235352c 206d7920 61646472 65737320    255, my address 
0020fd84: 69732031 32392e31 32392e31 34342e38    is 129.129.144.8
0020fd94: 320a3c34 3e5b2020 2020392e 39343831    2.<4>[    9.9481
0020fda4: 33385d20 49502d43 6f6e6669 673a2043    38] IP-Config: C
0020fdb4: 6f6d706c 6574653a 0a3c343e 5b202020    omplete:.<4>[   
0020fdc4: 20392e39 38343732 395d2020 20202020     9.984729]      
0020fdd4: 20646576 6963653d 65746830 2c206164     device=eth0, ad
0020fde4: 64723d31 32392e31 32392e31 34342e38    dr=129.129.144.8
0020fdf4: 322c206d 61736b3d 3235352e 3235352e    2, mask=255.255.
0020fe04: 3235352e 302c2067 773d3132 392e3132    255.0, gw=129.12
0020fe14: 392e3134 342e312c 0a3c343e 5b202020    9.144.1,.<4>[   
0020fe24: 31302e30 38313736 395d2020 20202020    10.081769]      
0020fe34: 686f7374 3d766972 74657834 2d6d6972    host=virtex4-mir
0020fe44: 656b2c20 646f6d61 696e3d70 73692e63    ek, domain=psi.c
0020fe54: 682c206e 69732d64 6f6d6169 6e3d286e    h, nis-domain=(n
0020fe64: 6f6e6529 2c0a3c34 3e5b2020 2031302e    one),.<4>[   10.
0020fe74: 31363031 32385d20 20202020 20626f6f    160128]      boo
0020fe84: 74736572 7665723d 3235352e 3235352e    tserver=255.255.
0020fe94: 3235352e 3235352c 20726f6f 74736572    255.255, rootser
0020fea4: 7665723d 3132392e 3132392e 3134342e    ver=129.129.144.
0020feb4: 3131332c 20726f6f 74706174 683d0a3c    113, rootpath=.<
0020fec4: 353e5b20 20203130 2e323535 3737355d    5>[   10.255775]
0020fed4: 204c6f6f 6b696e67 20757020 706f7274     Looking up port
0020fee4: 206f6620 52504320 31303030 30332f32     of RPC 100003/2
0020fef4: 206f6e20 3132392e 3132392e 3134342e     on 129.129.144.
0020ff04: 3131330a 3c353e5b 20202031 302e3332    113.<5>[   10.32
0020ff14: 39383830 5d204c6f 6f6b696e 67207570    9880] Looking up
0020ff24: 20706f72 74206f66 20525043 20313030     port of RPC 100
0020ff34: 3030352f 31206f6e 20313239 2e313239    005/1 on 129.129
0020ff44: 2e313434 2e313133 0a3c343e 5b202020    .144.113.<4>[   
0020ff54: 31302e34 31323935 325d2056 46533a20    10.412952] VFS: 
0020ff64: 4d6f756e 74656420 726f6f74 20286e66    Mounted root (nf
0020ff74: 73206669 6c657379 7374656d 292e0a3c    s filesystem)..<
0020ff84: 343e5b20 20203130 2e343638 3134395d    4>[   10.468149]
0020ff94: 20467265 65696e67 20756e75 73656420     Freeing unused 
0020ffa4: 6b65726e 656c206d 656d6f72 793a2039    kernel memory: 9
0020ffb4: 366b2069 6e69740a 00000000 00000000    6k init.........
0020ffc4: 00000000 00000000 00000000 00000000    ................
0020ffd4: 00000000 00000000 00000000 00000000    ................
0020ffe4: 00000000 00000000 00000000 00000000    ................


That is a whole buffer

Mirek

On Tue, 28 Aug 2007, Grant Likely wrote:

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

quoted

8. I have typed: md 0x20f0c4 100 and it showed me the buffer:

0020f0c4: 3c353e5b 20202020 302e3030 30303030    <5>[    0.000000
0020f0d4: 5d204c69 6e757820 76657273 696f6e20    ] Linux version
0020f0e4: 322e362e 32312d72 63362028 726f6f74    2.6.21-rc6 (root
0020f0f4: 40706335 32313529 20286763 63207665    @pc5215) (gcc ve
0020f104: 7273696f 6e20342e 302e3229 20233136    rsion 4.0.2) #16
0020f114: 204d6f6e 20417567 20323720 31323a33     Mon Aug 27 12:3
0020f124: 373a3038 20434553 54203230 30370a3c    7:08 CEST 2007.<
0020f134: 363e5b20 20202030 2e303030 3030305d    6>[    0.000000]
0020f144: 2058696c 696e7820 4d4c3430 33205265     Xilinx ML403 Re
0020f154: 66657265 6e636520 53797374 656d2028    ference System (
0020f164: 56697274 65782d34 20465829 0a3c373e    Virtex-4 FX).<7>
0020f174: 5b202020 20302e30 30303030 305d2045    [    0.000000] E
0020f184: 6e746572 696e6720 6164645f 61637469    ntering add_acti
0020f194: 76655f72 616e6765 28302c20 302c2038    ve_range(0, 0, 8
0020f1a4: 31393129 20302065 6e747269 6573206f    191) 0 entries o
0020f1b4: 66203235 36207573 65640a3c 343e5b20    f 256 used.<4>[
0020f1c4: 20202030 2e303030 3030305d 205a6f6e       0.000000] Zon
0020f1d4: 65205046 4e207261 6e676573 3a0a3c34    e PFN ranges:.<4

So it seams to be that the address points to the __log_buf (I hope).

Does it mean that when I try to start zImage kernel from u-boot
it hangs during uncompressing the image and it does even start booting?

Think about what you're looking at.  That buffer is ASCII text.  Does
it look like the entire buffer is displayed, or does it look like
there is more?

g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

This buffer refers to the kernel which I boot straight from jtag but not
u-boot.

/me remembers something....

How big is your kernel image?  Seems to me I've had problems with
kernel images that were too large not being uncompressed properly.
Can you hook up GDB and debug u-boot?  Find out where it is hanging?

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi Grant,

	My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?

I have examined the file in u-boot which does the bootelf:
cat common/cmd_elf.c:

int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
:
:
:
:
        addr = load_elf_image (addr);

        printf ("## Starting application at 0x%08lx ...\n", addr);

        /*
         * QNX images require the data cache is disabled.
         * Data cache is already flushed, so just turn it off.
         */
        if (dcache_status ())
                dcache_disable ();
     
        /*
         * pass address parameter as argv[0] (aka command name),
         * and all remaining args
         */
        rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);
:
:
}

and I have determined that the system hangs just after the command:
rc = ((ulong (*)(int, char *[])) addr) (--argc, &argv[1]);

This command starts executing the linux image from the location:
0x00400000 

On the console it is printed the following stuff:
loaded at:     00400000 004F3138
board data at: 004F1120 004F1138
relocated to:  004040B4 004040CC
zimage at:     00404E59 004F003D
avail ram:     004F4000 01FFFFFF

Linux/PPC load: console=ttyUL0,9600 root=/dev/nfs rw 
nfsroot=129.117.144.113:/opt/eldk41/ppc_4xx,tcp  
ip=::::virtex4-mirek:eth0:dhcp panic=1
Uncompressing Linux...

It seems to be that it is the Linux kernel which does the uncompression 
and it hangs. The question remain why?


Maybe it is not enough space in RAM or the address in RAM where the
uncompression is done is wrong.

When I load the u-boot to ram via jtag it is placed under the address:
0x800000 as follows:

        section, .text: 0x00800000-0x0081513c
        section, .resetvec: 0x0081513c-0x00815140
        section, .rodata: 0x00815140-0x00817ce0
        section, .reloc: 0x00817d00-0x00818674
        section, .data: 0x00818674-0x00818b08
        section, .data.rel: 0x00818b08-0x00818b34
        section, .data.rel.local: 0x00818b34-0x00818f6c
        section, .u_boot_cmd: 0x00818f6c-0x008191dc
        section, .bss: 0x00819200-0x0081dd04

Than I load the zImage.elf via tftp to the memory location
0xf00000.

When I issue the command bootelf 0xf00000  the zImage.elf is placed in the 
memory:

0x400000 as follows:

        section, .text: 0x00400000-0x004036cc
        section, .data: 0x00404000-0x004f7000
        section, .bss: 0x004f7000-0x004f9138

After that uncompression of zImage.elf starts. I am just wandering which 
memory location is involved for that?

My evaluation board has 32 MB of SDRAM address range:
  (0x00000000-0x01ffffff) DDR_SDRAM_1   plb  


Any Idea?

Best Regards

Mirek







On Tue, 28 Aug 2007, Grant Likely wrote:

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

quoted

This buffer refers to the kernel which I boot straight from jtag but not
u-boot.

/me remembers something....

How big is your kernel image?  Seems to me I've had problems with
kernel images that were too large not being uncompressed properly.
Can you hook up GDB and debug u-boot?  Find out where it is hanging?

g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/29/07, Miroslaw Dach [off-list ref] wrote:

Hi Grant,

        My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?

Ah-HA!  You're using the wrong type of kernel image.  When booting
from u-boot, you should be using a 'uImage', not a 'zImage.elf'.
(generated with 'make uImage' in the kernel tree).  An you should use
the 'bootm' command to boot the kernel.

With bootm, u-boot can pass parameters to the kernel and it is u-boot
that does the uncompression (instead of the zImage wrapper).

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Hi Grant,

	Yes you are right that I should use uImage instead of zImage.elf

I have tried first bootm and uImage but it also hanged during 
uncompression so next I have tried bootelf zImage.elf to see how this 
works because I was able to run zImage.elf straight from EDK via jtag.

Cheers

Mirek
  

On Wed, 29 Aug 2007, Grant Likely wrote:

On 8/29/07, Miroslaw Dach [off-list ref] wrote:

quoted

Hi Grant,

        My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?

Ah-HA!  You're using the wrong type of kernel image.  When booting
from u-boot, you should be using a 'uImage', not a 'zImage.elf'.
(generated with 'make uImage' in the kernel tree).  An you should use
the 'bootm' command to boot the kernel.

With bootm, u-boot can pass parameters to the kernel and it is u-boot
that does the uncompression (instead of the zImage wrapper).

Cheers,
g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

I have done further investigation with bootelf and zImage.elf (from
u-boot) and it seems to be that the system fails during image
uncompression: The last command executed is: r = zlib_inflate(&s,
Z_FINISH); /* file: ./arch/ppc/boot/common/misc-common.c */

zlib_inflate function code is in ./lib/zlib_inflate/inflate.c


Mirek



On Tue, 28 Aug 2007, Grant Likely wrote:

On 8/28/07, Miroslaw Dach [off-list ref] wrote:

quoted

This buffer refers to the kernel which I boot straight from jtag but not
u-boot.

/me remembers something....

How big is your kernel image?  Seems to me I've had problems with
kernel images that were too large not being uncompressed properly.
Can you hook up GDB and debug u-boot?  Find out where it is hanging?

g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

Hi All,

	I have modified the linux kernel to have it smaller than I have 
tried once again with bootm and uImage. The result is as shown below:

1. First I have downloaded u-boot via jtag:

XMD% dow u-boot.elf
        section, .text: 0x01300000-0x0131513c
        section, .resetvec: 0x0131513c-0x01315140
        section, .rodata: 0x01315140-0x01317d10
        section, .reloc: 0x01317e00-0x0131877c
        section, .data: 0x0131877c-0x01318c40
        section, .data.rel: 0x01318c40-0x01318c6c
        section, .data.rel.local: 0x01318c6c-0x013190a4
        section, .u_boot_cmd: 0x013190a4-0x01319314
        section, .bss: 0x01319400-0x0131df04
Downloaded Program u-boot13Debug.elf
Setting PC with program start addr = 0x01300100
PC reset to 0x01300100, Clearing MSR Register
XMD% run

2. The u-boot has started properly
3. Than I have loaded via tftp the uImage

=> tftp 0xf00000 uImage
TFTP from server 129.117.144.113; our IP address is 129.117.144.157
Filename 'uImage'.
Load address: 0xf00000
Loading: #################################################################
#################################################################
##############################################################
done
Bytes transferred = 981900 (efb8c hex)
=> bootm 0xf00000
## Booting image at 00f00000 ...
Image Name:  Linux-2.6.21-rc6
Image Type:  PowerPC Linux Kernel Image (gzip compressed)
Data Size:  981836 Bytes = 958.8 kB
Load Address: 00400000
Entry Point:  00400000
   Uncompressing Kernel Image ... OK
Bad trap at PC: c0002218, SR: 21030, vector=1100
NIP: C0002218 XER: 00000000 LR: 00400018 REGS: 01fc0578 TRAP: 1100 DAR:  01FF71AC
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11

GPR00: C0002218 01FC0668 B022C01B C00003C0 C0000000 00000000 007FFF00 007FFF7C
GPR08: C1FD9AC0 01FC0C0C 0000AE58 01FFEEC4 01FBFCA0 FFFFFFFF 02000E00 00000001
GPR16: 007FFF7C 00400000 00800000 FFFFFFFF 007FFF00 01FFA104 00000000 01FC0760
GPR24: 00000002 007FFE80 00000001 007FFF7C 007FFF00 00000000 00000000 007FFE80 
Call backtrace:
Exception in kernel pc c0002218 signal 0

4. I have stopped the system and I have reloaded u-boot to see what is in 
the RAM memory:

My __log_buf (of uImage)  is under the address :

c02070c4 b __log_buf

So I have dumped the data from this memory location:

=> md 0x2070c4 100
002070c4: 20257320 69732043 6f727235 70746564 %s is Corr5pted
002070d4: 20615400 25720000 7265646d 72654154 aT.%r..redmreAT
002070e4: 00000000 6b65322a 656c0004 67617465 ....ke2*el..gate
002070f4: 64000000 72614000 6d727400 6a652232 d...ra@.mrt.je"2
00207104: 61000000 62697264 00000000 2f655463 a...bird..../eTc
00207114: 2f497060 6b652465 322f7256 5f7052c5 /Ip`ke$e2/rV_pR.
00207124: 746f7100 676c2a62 616c0000 6e6f7748 toq.gl*bal..nowH
00207134: 65726500 73693465 00000200 27657462 ere.si4e....'etb
00207144: 2f697070 6f752065 322eaa50 5f73436f /ippou e2..P_sCo
00207154: 70655100 2f657022 2f697062 6f757441 peQ./ep"/ipboutA
00207164: 32277274 5b722121 6c6d7380 2f657413 2'rt[r!!lms./et.
00207174: 2f697872 6f357060 322f3264 5f647364 /ixro5p`2/2d_dsd
00207184: 69656c64 00000000 30782520 32780000 ield....0x% 2x..
00207194: 64656640 756c2400 2f653422 2f697070 def@ul$./e4"/ipp
002071a4: 6f757445 322f7274 5f746162 6c654300 outE2/rt_tableC.
002071b4: 10099124 100ae0d4 100aa0e8 100b1838 ...$...........8
002071c4: 100aa3e4 00000000 00000000 00000000 ................
002071d4: 100a6070 100ae0f8 100aa0ec 100ae100 ..`p............

I do not understand what is going on with my kernel image.

When I try to start zImage.elf with bootelf command the system hangs during 
uncompressing.
When I try to start uImage with bootm command the image is uncompressed 
but it does not start properly.

Any idea

Best Regards

Mirek






On Wed, 29 Aug 2007, Grant Likely wrote:

On 8/29/07, Miroslaw Dach [off-list ref] wrote:

quoted

Hi Grant,

        My zImage.elf has 1.1 MB and uImage 968 KB.
Could you tell me please how to hook up GDB to debug u-boot?

Ah-HA!  You're using the wrong type of kernel image.  When booting
from u-boot, you should be using a 'uImage', not a 'zImage.elf'.
(generated with 'make uImage' in the kernel tree).  An you should use
the 'bootm' command to boot the kernel.

With bootm, u-boot can pass parameters to the kernel and it is u-boot
that does the uncompression (instead of the zImage wrapper).

Cheers,
g.

-- 
=============================================================================
          Miroslaw Dach (Miroslaw.Dach@psi.ch) - SLS/Controls Group 
                PSI - Paul Scherrer Institut CH-5232 Villigen
=============================================================================

On 8/30/07, Miroslaw Dach [off-list ref] wrote:

When I try to start zImage.elf with bootelf command the system hangs during
uncompressing.
When I try to start uImage with bootm command the image is uncompressed
but it does not start properly.

Ugh, I'm stumped.  Sorry.  I'd spend some more quality time with your
debugger to trace the exact boot path.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195