lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3

[Alexander Sack]

using script from branch below to generate imx51 .img using a lucid a vmlinuz, the latest lucid uboot.bin from this package we hang when trying to "fatload mmc 0:2 0x90008000 /uimage" (check script for the real command)

Branch: https://code.edge.launchpad.net/~ubuntu-armel/+junk/uboot-image-script

[Alexander Sack (asac)]

blocks essential spec:
  + https://blueprints.launchpad.net/ubuntu/+spec/mobile-lucid-imx51-debian-cd-to-uboot

[Alexander Sack (asac)]

i can get a working image it seems using the following steps:

 1. get a current redboot lucid image; put that on the sd card

 2. get the current uboot.bin from archive

 3. sudo dd conv=notrunc if=uboot-imx51_to3.bin of=/dev/mmcblk0 bs=512 skip=1 seek=1

 4. copy the uImage produced by our script uboot-image-script to the fat partition:
        cp uImage /media/4B4C-AB5E/

 5. check the uImage: (optional step)

mkimage -l /media/4B4C-AB5E/uImage
Image Name: LinuxRocks
Created: Mon Jan 11 15:54:24 2010
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 3062156 Bytes = 2990.39 kB = 2.92 MB
Load Address: 0x90008000
Entry Point: 0x90008000

 6. umount, plug sd into board and load to success:

U-Boot 2009.08 (Jan 11 2010 - 11:22:01)

CPU: Freescale i.MX51 family 2.0V at 400 MHz
mx51 pll1: 800MHz
mx51 pll2: 665MHz
mx51 pll3: 216MHz
ipg clock : 66500000Hz
ipg per clock : 665000000Hz
uart clock : 66500000Hz
cspi clock : 54000000Hz
Board: MX51 BABBAGE 3.0 [POR]
Boot Device: MMC
DRAM: 512 MB
MMC: FSL_ESDHC: 0
JEDEC ID: 0xbf:0x25:0x41
*** Warning - bad CRC, using default environment

In: serial
Out: serial
Err: serial
Net: FEC0 [PRIME]
Hit any key to stop autoboot: 0
BBG U-Boot > mmcinfo
Device: FSL_ESDHC
Manufacturer ID: 3
OEM: 5344
Name: SD04G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 1945882623
Bus Width: 4-bit
BBG U-Boot > fatls mmc 0:2 /
            casper/
            dists/
            pics/
            .disk/
            install/
            preseed/
            pool/
     3246 md5sum.txt
      228 readme.diskdefines
  3062220 uimage

3 file(s), 7 dir(s)

BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage
reading /uimage

3062220 bytes read
BBG U-Boot > iminfo 0x90008000

## Checking Image at 90008000 ...
   Legacy image found
   Image Name: LinuxRocks
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 3062156 Bytes = 2.9 MB
   Load Address: 90008000
   Entry Point: 90008000
   Verifying Checksum ... OK

[Alexander Sack (asac)]

using casper vmlinuz from the same image:

mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n LinuxRocks -d /media/4B4C-AB5E/casper/vmlinuz /media/4*/uimage1

->

BBG U-Boot > run bootargs_base
BBG U-Boot > mmcinfo
Device: FSL_ESDHC
Manufacturer ID: 3
OEM: 5344
Name: SD04G
Tran Speed: 25000000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 1945882623
Bus Width: 4-bit
BBG U-Boot > fatload mmc 0:2 0x90800000 /uimage1
reading /uimage1

3085760 bytes read
BBG U-Boot > bootm 0x90800000
## Booting kernel from Legacy Image at 90800000 ...
   Image Name: LinuxRocks
   Image Type: ARM Linux Kernel Image (uncompressed)
   Data Size: 3085696 Bytes = 2.9 MB
   Load Address: 90008000
   Entry Point: 90008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux.................................................................................................................................................................................................... done, booting the kernel.

[Alexander Sack (asac)]

so ... seems pretty obvious the script messes something up with how the image is produced.

[Alexander Sack (asac)]

ok, i committed a few changes to the script branch. seems to work now with:

./uboot-image-script ../out.img ../data/vmlinuz-2.6.31-601-imx51 ../data/uboot-imx51_to3.bin 240M

somewhat the trick was to increase boot partition size to 200M ... i will see if a lower size really is broken.

[Alexander Sack (asac)]

commands to boot that were:

mmcinfo
fatload mmc 0:2 0x90800000 /uimage1
bootm 0x90800000

[Zhang Lily (r58066)]

To build uImage, can change build target from zImage to uImage. For example,
make ARCH=arm CROSS_COMPILE=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi- uImage

You can copy mkimage to /usr/bin/mkimage

[Oliver Grawert (ogra)]

Thanks Zhang, sadly thats not the way it can work in ubuntu, we build a package of the kernel (natively on an armel machine) which then puts out a vmlinuz file to be used with the various supported bootloaders (redboot/uboot). for creating a bootloader specific variant of the kernel image we need to use the bootloader specific tools (in this case mkimage). cross compiling beyond cases for quick tests is no option in ubuntu and bootloader specific modifications can not happen in the kernel package but have to be handled by bootloader scripts (see redboot-tools which we use for redboot image creation).

one very helpful information that is missing in all freescale docs i found about uboot would be the options that are used for mkimage to create the uImage file at freescale. would it be possible for you to verify that we are using the right adresses here ?

[Zhang Lily (r58066)]

Since we use LTIB for building (do mkimage operation), all documents you got did not mention it. Sorry for inconvencience.
In FSL document for android platform, the following information is mentioned:
$ cd myandroid/kernel_imx/arch/arm/boot
$ ~/myandroid/bootable/bootloader/uboot-imx/tools/mkimage -A
arm -O linux -T kernel -C none -a 0x90008000 -e 0x90008000 -n
"Android Linux Kernel" -d ./zImage ./uImage

We will add similar information in all documents.

[Loïc Minier (lool)]

We don't have any issue creating uImages; we build zImages because they can be easily be converted to uImage if needs be or used as is; the issue seems to be with the filesystem code in uboot or with the script creating the partition table + filesystem.

[Oliver Grawert (ogra)]

wow, thanks zhang, another issue we have is that we dont know where exactly to load an uinitrd to, that isnt documented either, would you know what values to use here ?

[Dave Martin (dave-martin-arm)]

In my own experiments, I had success using commands like these:

ext2load mmc 0:2 0x90007fc0 uImage
ext2load mmc 0:2 0x907fffc0 initrd.uImg
[...]
bootm 0x90007fc0 0x907fffc0

The choice of 0x907fffc0 was arbitrary, but seemed to work for me (assuming the kernel zImage is < 8MB of course)

[Alexander Sack (asac)]

unmilestoning since the latest script code i committed makes this work well.

[Alexander Sack (asac)]

we seemed to work around this issue by using bigger fat partitions. setting lucid target to wont fix for now as this doesnt block release

[Oliver Grawert (ogra)]

even though initramfs and kernel load now, we still can not load boot.scr files which is essential for parsing the kernel cmdline options on SD boots.

[Alexander Sack (asac)]

Oliver found that this is a regression over the 2009.01 code we had before.

From checking the differences it seems unlikely that its in actual fat or fdos code; rather in mmc code.

I also get hangs when loading a larger chunk of blocks from SD cards using "mmc read"; so we should investigate in that direction imo.

[Alexander Sack (asac)]

we are going for redboot for imx ... until all bugs are fixed for uboot.

[Paul Larson (pwlars)]

marking this back down to medium since it no longer blocks an essential spec. We can revisit the importance at a later date if it becomes essential again.

[Oliver Grawert (ogra)]

wont happen for lucid or other older releases...

[Taiten Peng (taitenpeng)]

I saw this bug and able to duplicate on another i.Mx51 design, however it seems to be fix by my patch attached.
dunno if it's still helpful. or someone can test the patch as well.