[U-Boot] Trouble "booting using board info"

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

Hello,

I'm trying to load Linux from U-Boot. I'm pretty new at this so there 
may be some obvious things wrong with what I'm doing.
I am using ELDK 4.2 and U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 
cpu) and the linux kernel sources obtained from instructions at 
"http://www.denx.de/wiki/view/DULG/LinuxConfiguration#Section_6.1.".

Below is my output as it currently stands (with lots of debug output):


U-Boot 2009.03-svn8591 (Jun 24 2009 - 10:24:20)

CPU:   MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
        8 kB I-Cache 8 kB D-Cache FEC present
clock 100000000Hz != 300000Hz
Board: EP88xC 1.1  CPLD revision 2
DRAM:  64 MB
Top of RAM usable for U-Boot at: 04000000
Reserving 187k for U-Boot at: 03fd1000
Reserving 384k for malloc() at: 03f71000
Reserving 60 Bytes for Board Info at: 03f70fc4
Reserving 56 Bytes for Global Data at: 03f70f8c
Stack Pointer at: 03f70f68
New Stack Pointer is: 03f70f68
Now running in RAM - U-Boot at: 03fd1000
FLASH: flash detect cfi
fwc addr fc000000 cmd f0 f0 8bit x 8 bit
fwc addr fc000000 cmd ff ff 8bit x 8 bit
fwc addr fc000055 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr fc000010 is= 30 51
fwc addr fc000555 cmd 98 98 8bit x 8 bit
is= cmd 51(Q) addr fc000010 is= 30 51
fwc addr fc000000 cmd f0 f0f0 16bit x 8 bit
fwc addr fc000000 cmd ff ffff 16bit x 8 bit
fwc addr fc0000aa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr fc000020 is= 3234 5151
fwc addr fc000aaa cmd 98 9898 16bit x 8 bit
is= cmd 51(Q) addr fc000020 is= 3234 5151
fwc addr fc000000 cmd f0 00f0 16bit x 16 bit
fwc addr fc000000 cmd ff 00ff 16bit x 16 bit
fwc addr fc0000aa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr fc000020 is= 3234 0051
fwc addr fc000aaa cmd 98 0098 16bit x 16 bit
is= cmd 51(Q) addr fc000020 is= 3234 0051
fwc addr fc000000 cmd f0 f0f0f0f0 32bit x 8 bit
fwc addr fc000000 cmd ff ffffffff 32bit x 8 bit
fwc addr fc000154 cmd 98 98989898 32bit x 8 bit
is= cmd 51(Q) addr fc000040 is= 00510051 51515151
fwc addr fc001554 cmd 98 98989898 32bit x 8 bit
is= cmd 51(Q) addr fc000040 is= 00510051 51515151
fwc addr fc000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr fc000000 cmd ff 00ff00ff 32bit x 16 bit
fwc addr fc000154 cmd 98 00980098 32bit x 16 bit
is= cmd 51(Q) addr fc000040 is= 00510051 00510051
is= cmd 52(R) addr fc000044 is= 00520052 00520052
is= cmd 59(Y) addr fc000048 is= 00590059 00590059
device interface is 2
found port 4 chip 2 port 32 bits chip 16 bits
00 : 51 52 59 02 00 40 00 00 00 00 00 27 36 00 00 07  QRY.. at .....'6...
10 : 07 0a 00 03 05 04 00 18 02 00 05 00 01 7f 00 00  ................
20 : 02 00 00 00 00 00 00 00 00 00 00 00 00 12 cc 27  ...............'
fwc addr fc000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr fc001554 cmd aa 00aa00aa 32bit x 16 bit
fwc addr fc000aa8 cmd 55 00550055 32bit x 16 bit
fwc addr fc001554 cmd 90 00900090 32bit x 16 bit
fwc addr fc000000 cmd f0 00f000f0 32bit x 16 bit
fwc addr fc000154 cmd 98 00980098 32bit x 16 bit
manufacturer is 2
manufacturer id is 0x1
device id is 0x227e
device id2 is 0x0
cfi version is 0x3133
size_ratio 2 port 32 bits chip 16 bits
found 1 erase regions
erase region 0: 0x0200007f
erase_region_count = 128 erase_region_size = 131072
fwc addr fc000000 cmd f0 00f000f0 32bit x 16 bit
flash_protect ON: from 0xFC000000 to 0xFC028FFF
protect on 0
flash_protect ON: from 0xFC040000 to 0xFC07FFFF
protect on 1
32 MB
env_relocate[233] offset = 0x7fd1000
env_relocate[254] malloced ENV at 03f71008
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
U-Boot relocated to 03fd1000
Net:   FEC ETHERNET, FEC2 ETHERNET
### main_loop entered: bootdelay=2

### main_loop: bootcmd="bootm fc080000"
Hit any key to stop autoboot:  0
## Current stack ends at 0x03f70d50
*  kernel: cmdline image address = 0xfc080000
Wrong Image Format for bootm command
ERROR: can't get kernel image!
=> setenv ipaddr 10.0.54.150
=> setenv serverip 10.0.54.129
=> setenv ethaddr 00-e0-86-0c-84-fd
eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd)
Setting new HW address on FEC ETHERNET
New Address is             00:E0:86:0C:84:FD
eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd)
Setting new HW address on FEC ETHERNET
New Address is             00:E0:86:0C:84:FD
=> tftp 400000 ep88x_uimage
Trying FEC ETHERNET
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_uimage'.
Load address: 0x400000
Loading: #################################################################
          ########
done
Bytes transferred = 1057401 (102279 hex)
=> bootm 400000
## Current stack ends at 0x03f70d60
*  kernel: cmdline image address = 0x00400000
## Booting kernel from Legacy Image at 00400000 ...
    Image Name:   Linux-2.6.30-rc2-01402-gd4e2f68
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    1057337 Bytes =  1 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    kernel data at 0x00400040, len = 0x00102239 (1057337)
## No init Ramdisk
    ramdisk start = 0x00000000, ramdisk end = 0x00000000
    Uncompressing Kernel Image ... OK
    kernel loaded at 0x00000000, end = 0x0022421c
## cmdline at 0x007fff00 ... 0x007fff36
## kernel board info at 0x007ffec0
bd address  = 0x03F70FC4
memstart    = 0x00000000
memsize     = 0x00000000
flashstart  = 0xFC000000
flashsize   = 0x02000000
flashoffset = 0x00029000
sramstart   = 0x00000000
sramsize    = 0x00000000
immr_base   = 0xF0000000
bootflags   = 0x00000001
intfreq     =    100 MHz
busfreq     =     50 MHz
ethaddr     = 00:E0:86:0C:84:FD
IP addr     = 10.0.54.150
baudrate    =   9600 bps
## initrd_high = 0xffffffff, copy_to_ram = 1
    ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
## Transferring control to Linux (at address 00000000) ...
    Booting using board info...


Nothing happens after this. I know I still have to make a ramdisk image 
to use as the root filesystem. My questions for now are:

1. Should I be getting any more console output given what I have so far? 
Or is something wrong?

2. I am concerned that "memsize = 0x00000000", is this normal?

3. I tried creating and using a FDT using instructions on 
"http://www.denx.de/wiki/view/DULG/LinuxFDTBlob", loading it at 
0x00650000 and using "bootm 400000 - 650000", but the resulting output 
was pretty much identical. Is that normal?

4. Anything else in that output looks funky?

I looked at 
"http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019548.html" 
and 
"http://ozlabs.org/pipermail/linuxppc-embedded/2007-August/027742.html" 
but they don't follow up on the solutions so I don't know if those 
issues have been resolved.

Any suggestions are appreciated. Thanks!

Mikhail Zaturenskiy

[U-Boot] Trouble "booting using board info"

[Detlev Zundel]

Hi Mikhail,

> I'm trying to load Linux from U-Boot. I'm pretty new at this so there 
> may be some obvious things wrong with what I'm doing.
> I am using ELDK 4.2 and U-Boot 2009.03 on an EP88xC rev1.1 board (MPC885 
> cpu) and the linux kernel sources obtained from instructions at 
> "http://www.denx.de/wiki/view/DULG/LinuxConfiguration#Section_6.1.".
>
> Below is my output as it currently stands (with lots of debug output):

Please disable unneccessary debug output the next time - this makes it
hard to see the salient things - thanks.

>
>
> U-Boot 2009.03-svn8591 (Jun 24 2009 - 10:24:20)
>
> CPU:   MPC885ZPnn at 100 MHz [40.0...133.0 MHz]

[...]

> => setenv ethaddr 00-e0-86-0c-84-fd
> eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd)

Wow, our parser groks '-' as delimiters?  Didn't know that ;)

> Setting new HW address on FEC ETHERNET
> New Address is             00:E0:86:0C:84:FD
> eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd)
> Setting new HW address on FEC ETHERNET
> New Address is             00:E0:86:0C:84:FD
> => tftp 400000 ep88x_uimage
> Trying FEC ETHERNET
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_uimage'.
> Load address: 0x400000
> Loading: #################################################################
>           ########
> done
> Bytes transferred = 1057401 (102279 hex)
> => bootm 400000
> ## Current stack ends at 0x03f70d60
> *  kernel: cmdline image address = 0x00400000
> ## Booting kernel from Legacy Image at 00400000 ...
>     Image Name:   Linux-2.6.30-rc2-01402-gd4e2f68
>     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>     Data Size:    1057337 Bytes =  1 MB
>     Load Address: 00000000
>     Entry Point:  00000000
>     Verifying Checksum ... OK
>     kernel data at 0x00400040, len = 0x00102239 (1057337)

Ok, 2.6.30 so you definitely need a fdt for the kernel.  Either pass it
through U-Boot or use a cuImage wrapper in the Linux kernel.

> ## No init Ramdisk
>     ramdisk start = 0x00000000, ramdisk end = 0x00000000
>     Uncompressing Kernel Image ... OK
>     kernel loaded at 0x00000000, end = 0x0022421c
> ## cmdline at 0x007fff00 ... 0x007fff36
> ## kernel board info at 0x007ffec0
> bd address  = 0x03F70FC4
> memstart    = 0x00000000
> memsize     = 0x00000000
> flashstart  = 0xFC000000
> flashsize   = 0x02000000
> flashoffset = 0x00029000
> sramstart   = 0x00000000
> sramsize    = 0x00000000
> immr_base   = 0xF0000000
> bootflags   = 0x00000001
> intfreq     =    100 MHz
> busfreq     =     50 MHz
> ethaddr     = 00:E0:86:0C:84:FD
> IP addr     = 10.0.54.150
> baudrate    =   9600 bps
> ## initrd_high = 0xffffffff, copy_to_ram = 1
>     ramdisk load start = 0x00000000, ramdisk load end = 0x00000000
> ## Transferring control to Linux (at address 00000000) ...
>     Booting using board info...
>
>
> Nothing happens after this. I know I still have to make a ramdisk image 
> to use as the root filesystem. My questions for now are:
>
> 1. Should I be getting any more console output given what I have so far? 
> Or is something wrong?

You should see more output indeed - the missing rootfilesystem stops the
process only after all of the kernel is initialized.

> 2. I am concerned that "memsize = 0x00000000", is this normal?

Actually it looks suspicious - although I just checked on a tqm5200 and
its zero there as well - so I'd postpone debugging this.

> 3. I tried creating and using a FDT using instructions on 
> "http://www.denx.de/wiki/view/DULG/LinuxFDTBlob", loading it at 
> 0x00650000 and using "bootm 400000 - 650000", but the resulting output 
> was pretty much identical. Is that normal?

Judiging from include/configs/EP88x.h you do not have FDT support
enabled in your U-Boot at all (-> CONFIG_OF_LIBFDT).  That the output
stays the same also hints in this direction, as otherwise you'll see
something like this:

## Flattened Device Tree blob at 00600000
   Booting using the fdt blob at 0x600000
   Uncompressing Kernel Image ... OK

So with your current U-Boot you would need to use the Linux wrappers.  I
would suggest that you update the configuration to include this.

As I perceive it, your biggest task however will be to come up with a
correct FDT for Linux.  This is out of scope of this ML and better
carried to the linuxppc ML.

Cheers
  Detlev

-- 
Q:  What does FAQ stand for?
A:  We are Frequently Asked this Question, and we have no idea.
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] "Bad Data CRC" after ramdisk size increase

[Mikhail Zaturenskiy]

Hi Rahanesh,

Rahanesh wrote:
> Hello Mikhail Zaturenskiy,
> 
> I am also trying to load Linux from uboot.  When i try to boot Linux 
> from uboot it stops at Verifying Checksum and stops there. What might be 
> the reasson for this?
> 
> This is my output.
> 
> U-Boot 1.1.2 (Jun 10 2008 - 18:55:13)
> 
> Board: MIPS CPU Speed 200 MHz
> DRAM:  16 MB
> sflash.c:266:DF_F_DataflashProbe: Entered
> sflash.c:269:DF_F_DataflashProbe: flash type is 0x1
> sflash.c:270:DF_F_DataflashProbe: num pages 32768
> DataFlash:Nb pages:  32768
> Page Size:    256
> Size= 8388608 bytes
> Logical address: 0xAD000000
> Nb Erase Blocks:    128
> Erase Block Size:  65536
> Area 0:    AD000000 to AD003FFF
> Area 1:    AD004000 to AD03FFFF
> Area 2:    AD040000 to AD30BFFF
> Area 3:    AD30C000 to AD7FFFFF
> crc matched
> In:    serial
> Out:   serial
> Err:   serial
> Net:    Eth.
> 
> Type "run flash_nfs" to mount root filesystem over NFS
> 
> Hit any key to stop autoboot:  \b\b\b 0
> ### JFFS2 loading '/boot/uImage' to 0x80800000
> Scanning JFFS2 FS:   \b\b.  \b\b..............................\b\b- \b\b done.
> ### JFFS2 load complete: 3249008 bytes loaded to 0x80800000
> ## Booting image at 80800000 ...
>   Image Name:   Linux Kernel Image with ramdisk.
>   Created:      2009-06-22   4:37:12 UTC
>   Image Type:   MIPS Linux Kernel Image (gzip compressed)
>   Data Size:    3248944 Bytes =  3.1 MB
>   Load Address: 80100000
>   Entry Point:  80578000
>   Verifying Checksum ... Bad Data CRC
> 
> UBOOT>
> 
> 
> I Had a working Linux image initially. When i increased the size of 
> Ramdisk and built a new image (Linux + Ramdisk) it fails at checksum.
> Please throw some light on this...
> 
> 
> Thanks
> Rahanesh
> 
> 


As I am not an expert in your board configuration, it may be a good idea 
  next time to include "u-boot at lists.denx.de" in the CC of your 
response, or just posting a new question altogether, so that somebody 
else in the mailing list has a chance to help you.

Now, the issue might be that your new image was not properly burned into 
flash or maybe something got corrupted when you were combining the 
kernel and ramdisk.

You could try re-burning your image into flash and try booting again.
If that doesn't work, you could also try changing your ramdisk size back 
to what it was, build the kernel+ramdisk image again and see if you can 
get it working with your previous configuration. If that works then 
you'll narrow the issue down to being a problem with the ramdisk size 
increase. If it doesn't work, than there some other factor involved 
thats messing this up.

Sorry I can't provide more insight, I still have a lot to learn about 
all this :)

Maybe somebody else has any better suggestions?

Mike Z.

[U-Boot] "Bad Data CRC" after ramdisk size increase

[Detlev Zundel]

Hi Rhanesh,

>> I am also trying to load Linux from uboot.  When i try to boot Linux 
>> from uboot it stops at Verifying Checksum and stops there. What might be 
>> the reasson for this?
>> 
>> This is my output.
>> 
>> U-Boot 1.1.2 (Jun 10 2008 - 18:55:13)
>> 
>> Board: MIPS CPU Speed 200 MHz
>> DRAM:  16 MB
>> sflash.c:266:DF_F_DataflashProbe: Entered
>> sflash.c:269:DF_F_DataflashProbe: flash type is 0x1
>> sflash.c:270:DF_F_DataflashProbe: num pages 32768
>> DataFlash:Nb pages:  32768
>> Page Size:    256
>> Size= 8388608 bytes
>> Logical address: 0xAD000000
>> Nb Erase Blocks:    128
>> Erase Block Size:  65536
>> Area 0:    AD000000 to AD003FFF
>> Area 1:    AD004000 to AD03FFFF
>> Area 2:    AD040000 to AD30BFFF
>> Area 3:    AD30C000 to AD7FFFFF
>> crc matched
>> In:    serial
>> Out:   serial
>> Err:   serial
>> Net:    Eth.
>> 
>> Type "run flash_nfs" to mount root filesystem over NFS
>> 
>> Hit any key to stop autoboot:  \b\b\b 0
>> ### JFFS2 loading '/boot/uImage' to 0x80800000
>> Scanning JFFS2 FS:   \b\b.  \b\b..............................\b\b- \b\b done.
>> ### JFFS2 load complete: 3249008 bytes loaded to 0x80800000
>> ## Booting image at 80800000 ...
>>   Image Name:   Linux Kernel Image with ramdisk.
>>   Created:      2009-06-22   4:37:12 UTC
>>   Image Type:   MIPS Linux Kernel Image (gzip compressed)
>>   Data Size:    3248944 Bytes =  3.1 MB
>>   Load Address: 80100000
>>   Entry Point:  80578000
>>   Verifying Checksum ... Bad Data CRC

Well, this is what it is - the data is not consistent with the checksum
in contained in the U-Boot headers.

If I look at the datasize (3248944) and remember that the U-Boot headers
are 64 bytes, then "3249008 bytes loaded" looks pretty good.  So we
likely do have no truncation here.  So either the image in flash is
corrupt or it gets corrupted on the transfer into RAM.

You could test for the latter by transferring the image twice into
different locations into RAM and "cmp"ing them.  If this fails you know
that you very likely still have hw problems.  If it passes, try to
regenerate the image and check it with "imi <address>" after every
step.  This will ensure the checksum is still correct.

Cheers
  Detlev

-- 
The best way to predict the future is to invent it.
                                           -- Alan Kay
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

Hi Detlev,

> Please disable unneccessary debug output the next time - this makes it
> hard to see the salient things - thanks.
Done, next bunch of code will be posted w/o debug output (see code 
below), I just thought it would help track down the issues.

>> => setenv ethaddr 00-e0-86-0c-84-fd
>> eth_set_enetaddr(num=0, addr=00-e0-86-0c-84-fd)
> 
> Wow, our parser groks '-' as delimiters?  Didn't know that ;)
Nice :)


> Ok, 2.6.30 so you definitely need a fdt for the kernel.  Either pass it
> through U-Boot or use a cuImage wrapper in the Linux kernel.
I got an FDT generated and passed it in through U-Boot (see code below)

> Judiging from include/configs/EP88x.h you do not have FDT support
> enabled in your U-Boot at all (-> CONFIG_OF_LIBFDT).  That the output
> stays the same also hints in this direction, as otherwise you'll see
> something like this:
> 
> ## Flattened Device Tree blob at 00600000
>    Booting using the fdt blob at 0x600000
>    Uncompressing Kernel Image ... OK
You're right, I turned on CONFIG_OF_LIBFDT in include/configs/EP88x.h.

Here's where I'm at now:

U-Boot 2009.03-svn8591 (Jun 25 2009 - 10:18:12)

CPU:   MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
        8 kB I-Cache 8 kB D-Cache FEC present
Board: EP88xC 1.1  CPLD revision 2
DRAM:  64 MB
FLASH: 32 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   FEC ETHERNET, FEC2 ETHERNET
Hit any key to stop autoboot:  0
Wrong Image Format for bootm command
ERROR: can't get kernel image!
=> setenv ipaddr 10.0.54.150
=> setenv serverip 10.0.54.129
=> setenv bootargs root=/dev/ram0 rw
=> setenv ethaddr 00-e0-86-0c-84-fd
=> tftp 400000 ep88x_uimage2
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_uimage2'.
Load address: 0x400000
Loading: #################################################################
          ########
done
Bytes transferred = 1061544 (1032a8 hex)
=> tftp 550000 ep88x_ramdisk3
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_ramdisk3'.
Load address: 0x550000
Loading: #################################################################
          #############################################################
done
Bytes transferred = 1846099 (1c2b53 hex)
=> tftp 750000 ep88x_dtb
Using FEC ETHERNET device
TFTP from server 10.0.54.129; our IP address is 10.0.54.150
Filename 'ep88x_dtb'.
Load address: 0x750000
Loading: #
done
Bytes transferred = 12288 (3000 hex)
=> bootm 400000 550000 750000
## Booting kernel from Legacy Image at 00400000 ...
    Image Name:   Linux-2.6.30-rc2-01402-gd4e2f68-
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    1061480 Bytes =  1 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 00550000 ...
    Image Name:   Simple Embedded Linux Framework
    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
    Data Size:    1846035 Bytes =  1.8 MB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
## Flattened Device Tree blob at 00750000
    Booting using the fdt blob at 0x750000
    Uncompressing Kernel Image ... OK
    Loading Ramdisk to 03daa000, end 03f6cb13 ... OK

Now the usual hang, any more suggestions for what to do next?

Thanks a lot!
Mikhail Zaturenskiy

[U-Boot] Trouble "booting using board info"

[Detlev Zundel]

Hi Mikhail,

> You're right, I turned on CONFIG_OF_LIBFDT in include/configs/EP88x.h.

Wow, you _are_ quick ;)

> Here's where I'm at now:
>
> U-Boot 2009.03-svn8591 (Jun 25 2009 - 10:18:12)
>
> CPU:   MPC885ZPnn at 100 MHz [40.0...133.0 MHz]
>        8 kB I-Cache 8 kB D-Cache FEC present
> Board: EP88xC 1.1  CPLD revision 2
> DRAM:  64 MB
> FLASH: 32 MB
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FEC ETHERNET, FEC2 ETHERNET
> Hit any key to stop autoboot:  0
> Wrong Image Format for bootm command
> ERROR: can't get kernel image!
> => setenv ipaddr 10.0.54.150
> => setenv serverip 10.0.54.129
> => setenv bootargs root=/dev/ram0 rw
> => setenv ethaddr 00-e0-86-0c-84-fd
> => tftp 400000 ep88x_uimage2
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_uimage2'.
> Load address: 0x400000
> Loading: #################################################################
>          ########
> done
> Bytes transferred = 1061544 (1032a8 hex)
> => tftp 550000 ep88x_ramdisk3
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_ramdisk3'.
> Load address: 0x550000
> Loading: #################################################################
>          #############################################################
> done
> Bytes transferred = 1846099 (1c2b53 hex)
> => tftp 750000 ep88x_dtb
> Using FEC ETHERNET device
> TFTP from server 10.0.54.129; our IP address is 10.0.54.150
> Filename 'ep88x_dtb'.
> Load address: 0x750000
> Loading: #
> done
> Bytes transferred = 12288 (3000 hex)
> => bootm 400000 550000 750000
> ## Booting kernel from Legacy Image at 00400000 ...
>    Image Name:   Linux-2.6.30-rc2-01402-gd4e2f68-
>    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
>    Data Size:    1061480 Bytes =  1 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 00550000 ...
>    Image Name:   Simple Embedded Linux Framework
>    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
>    Data Size:    1846035 Bytes =  1.8 MB
>    Load Address: 00000000
>    Entry Point:  00000000
>    Verifying Checksum ... OK
> ## Flattened Device Tree blob at 00750000
>    Booting using the fdt blob at 0x750000
>    Uncompressing Kernel Image ... OK
>    Loading Ramdisk to 03daa000, end 03f6cb13 ... OK
>
> Now the usual hang, any more suggestions for what to do next?

If you are in the good position to own a JTAG debugger, now would be the
time to place it next to your board :)

If not, then try at least to be sure that "linux,stdout-path" is
sensible in your dts (compare to others).  Another option is to try the
postmortem debugging of the logbuffer described in our docs[1].

As I do not have much 8xx 2.6 exposure I don't know if this is supported
here, but you may try:

arch/powerpc/Kconfig.debug:128
 "Kernel hacking"
config PPC_EARLY_DEBUG
        bool "Early debugging (dangerous)"
        # PPC_EARLY_DEBUG on 440 leaves AS=1 mappings above the TLB high water
        # mark, which doesn't work with current 440 KVM.
        depends on !KVM
        help
          Say Y to enable some early debugging facilities that may be available
          for your processor/board combination. Those facilities are hacks
          intended to debug problems early during boot, this should not be
          enabled in a production kernel.
          Note that enabling this will also cause the kernel default log level
          to be pushed to max automatically very early during boot

If this all fails and as you are way past U-Boot, change the mailing
list to linuxppc-dev :)

Cheers
  Detlev

[1] http://www.denx.de/wiki/view/DULG/LinuxPostMortemAnalysis

-- 
You are God.  Remember?
      -- Timothy Leary
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

 > If this all fails and as you are way past U-Boot, change the mailing
 > list to linuxppc-dev :)

Is this really "way past U-Boot"? I was under the impression that my 
issue is at the hand-off point from U-Boot to the kernel and that the 
kernel wasn't doing anything yet. Am I wrong?

[U-Boot] Trouble "booting using board info"

[Detlev Zundel]

Hi Mikhail,

>> If this all fails and as you are way past U-Boot, change the mailing
>> list to linuxppc-dev :)
>
> Is this really "way past U-Boot"? I was under the impression that my
> issue is at the hand-off point from U-Boot to the kernel and that the
> kernel wasn't doing anything yet. Am I wrong?

Well U-Boot called the entry function of the Linux kernel, so we are
inside Linux territory.  The fact that you do not see any output on your
terminal is not enough top infer that Linux does _nothing_.  For all you
see, it may well boot into a fully functioning system without using a
console on your serial port...

Cheers
  Detlev

-- 
Spelling is a lossed art
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

Hi Detlev,

>
> Well U-Boot called the entry function of the Linux kernel, so we are
> inside Linux territory.  The fact that you do not see any output on your
> terminal is not enough top infer that Linux does _nothing_.  For all you
> see, it may well boot into a fully functioning system without using a
> console on your serial port...
>
> Got it, thanks for helping me understand this better.

I did a post-mortem analysis of the kernel as you earlier suggested:

<6>Using Embedded Planet EP88xC machine description.
<0>Kernel panic - not syncing: Error: Failed to allocate 0x1
................0x800000..
<0>.
<4>Call Trace:.
<4>................69e0] show_stack...............................21f00]
[c001bcb4] panic+0x8c/0x1................ [c01fac70] lmb_alloc+0x0/0xc.
<4>[c0221f70] [c01................_page+0x60/0x74.
<4>[c0221f80] [c01a4484] pte_alloc_one_kernel+0x

Looks like it IS time to change the mailing list to linuxppc-dev :)

Mikhail Zaturenskiy

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

Is it possible to look at a post-fixup device tree in u-boot? It looks
like u-boot is not updating my dts with the values for my RAM, cpu
frequency, etc. before loading the kernel.

Is there any obvious reason for this? Am I missing a #define of some sort?

[U-Boot] Trouble "booting using board info"

[Jerry Van Baren]

Mikhail Zaturenskiy wrote:
> Is it possible to look at a post-fixup device tree in u-boot? It looks
> like u-boot is not updating my dts with the values for my RAM, cpu
> frequency, etc. before loading the kernel.
> 
> Is there any obvious reason for this? Am I missing a #define of some sort?

Hi Mikhail,

The board fixup is a board-specific thing.  Are you doing that in your 
board configuration?

If you have CONFIG_OF_BOARD_SETUP defined (if you don't that probably is 
the answer to your missing #define question), you can run
   fdt boardsetup
and then
   fdt print /
to see what the fixed up tree looks like.

You can also run the bootm command step-by-step (some steps may not 
apply to your board)...

bootm start
bootm loados
bootm ramdisk
bootm fdt
bootm bdt
bootm cmdline
bootm prep

Print out the tree:
fdt print /

(last step is...)
bootm go

Best regards,
gvb

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

> The board fixup is a board-specific thing. ?Are you doing that in your board
> configuration?
Didn't realize it was board-specific.

> If you have CONFIG_OF_BOARD_SETUP defined (if you don't that probably is the
> answer to your missing #define question), you can run
> ?fdt boardsetup
> and then
> ?fdt print /
> to see what the fixed up tree looks like.
No I do not have this defined, when I include it I cannot compile
u-boot, errors out like this:
common/libcommon.a(cmd_fdt.o): In function `do_fdt':
/home/devone/embedded/orbitServer/u-boot-2009.03/common/cmd_fdt.c:437:
undefined reference to `ft_board_setup'
lib_ppc/libppc.a(bootm.o): In function `boot_body_linux':
/home/devone/embedded/orbitServer/u-boot-2009.03/lib_ppc/bootm.c:272:
undefined reference to `ft_board_setup'
make: *** [u-boot] Error 1

So I'm not sure I want to mess with getting CONFIG_OF_BOARD_SETUP
unless I absolutely have to.

> You can also run the bootm command step-by-step (some steps may not apply to
> your board)...
>
> bootm start
> bootm loados
> bootm ramdisk
> bootm fdt
> bootm bdt
> bootm cmdline
> bootm prep
>
> Print out the tree:
> fdt print /
>
> (last step is...)
> bootm go
I didn't realize I could do this! Thanks!
After "bootm start 400000 - 750000"  I'm able to do a "fdt print" to
see the fdt I passed in, thought for some reason when I run "bootm
loados" it never gets past "Uncompressing Kernel Image..." any idea
why? It doesn't freeze here when I do "bootm 400000 - 750000".

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

>> If you have CONFIG_OF_BOARD_SETUP defined (if you don't that probably is the
>> answer to your missing #define question), you can run
>> ?fdt boardsetup
>> and then
>> ?fdt print /
>> to see what the fixed up tree looks like.
> No I do not have this defined, when I include it I cannot compile
> u-boot, errors out like this:
> common/libcommon.a(cmd_fdt.o): In function `do_fdt':
> /home/devone/embedded/orbitServer/u-boot-2009.03/common/cmd_fdt.c:437:
> undefined reference to `ft_board_setup'
> lib_ppc/libppc.a(bootm.o): In function `boot_body_linux':
> /home/devone/embedded/orbitServer/u-boot-2009.03/lib_ppc/bootm.c:272:
> undefined reference to `ft_board_setup'
> make: *** [u-boot] Error 1
Got it... thanks to
"http://www.mail-archive.com/u-boot-users at lists.sourceforge.net/msg05111.html".
I added the following to the very end of
"u-boot-2009.03/board/ep88x/ep88x.c":

#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
void ft_board_setup(void *blob, bd_t *bd)
{
        ft_cpu_setup(blob, bd);
}
#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */


>> You can also run the bootm command step-by-step (some steps may not apply to
>> your board)...
>>
>> bootm start
>> bootm loados
>> bootm ramdisk
>> bootm fdt
>> bootm bdt
>> bootm cmdline
>> bootm prep
>>
>> Print out the tree:
>> fdt print /
>>
>> (last step is...)
>> bootm go
> I didn't realize I could do this! Thanks!
> After "bootm start 400000 - 750000" ?I'm able to do a "fdt print" to
> see the fdt I passed in, thought for some reason when I run "bootm
> loados" it never gets past "Uncompressing Kernel Image..." any idea
> why? It doesn't freeze here when I do "bootm 400000 - 750000".
>
u-boot's "fdt" and step-by-step "bootm" are still giving me a hard
time, but I don't really care anymore at this point as I'm finally
getting my console output and can move on to debugging my linux kernel
and adding a file system.

Thanks for suggestions!

[U-Boot] Trouble "booting using board info"

[Mikhail Zaturenskiy]

> Got it... thanks to
> "http://www.mail-archive.com/u-boot-users at lists.sourceforge.net/msg05111.html".
> I added the following to the very end of
> "u-boot-2009.03/board/ep88x/ep88x.c":
>
> #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
> void ft_board_setup(void *blob, bd_t *bd)
> {
> ? ? ? ?ft_cpu_setup(blob, bd);
> }
> #endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
>
Forgot to mention that this function got u-boot to update my device
tree properly, I had to make only minimal changes to my device tree
"linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts", correcting some
addresses to match the IMMR set in my
"u-boot-2009.03/include/configs/EP88x.h".

I didn't even need to use /chosen/linux,stdout-path in my DTS, just
used "console=ttyCPM0,9600n8" in my boot args.

[U-Boot] Trouble "booting using board info"

[Jerry Van Baren]

Mikhail Zaturenskiy wrote:
>> Got it... thanks to
>> "http://www.mail-archive.com/u-boot-users at lists.sourceforge.net/msg05111.html".
>> I added the following to the very end of
>> "u-boot-2009.03/board/ep88x/ep88x.c":
>>
>> #if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
>> void ft_board_setup(void *blob, bd_t *bd)
>> {
>>        ft_cpu_setup(blob, bd);
>> }
>> #endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
>>
> Forgot to mention that this function got u-boot to update my device
> tree properly, I had to make only minimal changes to my device tree
> "linux-2.6-denx/arch/powerpc/boot/dts/ep88xc.dts", correcting some
> addresses to match the IMMR set in my
> "u-boot-2009.03/include/configs/EP88x.h".
> 
> I didn't even need to use /chosen/linux,stdout-path in my DTS, just
> used "console=ttyCPM0,9600n8" in my boot args.

Hi Mikhail,

The /chosen node should be created and populated by the fdt support to 
reflect the board's hardware.  If you run the "fdt chosen" command, you 
should see what is created.  If it isn't created, you are missing a 
setup piece in your board support customization.

Having a /chosen node in the DTS is deprecated.

Best regards,
gvb