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

Bug #506761 reported by Alexander Sack
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
uboot-imx (Ubuntu)
Medium
Oliver Grawert
Nominated for Jaunty by r12056
Nominated for Karmic by r12056
Lucid
Medium
Oliver Grawert

Bug Description

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

Revision history for this message
Alexander Sack (asac) wrote :
description: updated
tags: added: armel
Changed in uboot-imx (Ubuntu):
status: New → Incomplete
importance: Undecided → Critical
Changed in uboot-imx (Ubuntu Lucid):
status: Incomplete → Confirmed
milestone: none → lucid-alpha-3
assignee: nobody → Oliver Grawert (ogra)
Revision history for this message
Alexander Sack (asac) wrote :

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

Revision history for this message
Alexander Sack (asac) wrote :

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.

Revision history for this message
Alexander Sack (asac) wrote :

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

Revision history for this message
Alexander Sack (asac) wrote :

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.

Revision history for this message
Alexander Sack (asac) wrote :

commands to boot that were:

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

Revision history for this message
Zhang Lily (r58066) wrote :

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

Revision history for this message
Oliver Grawert (ogra) wrote :

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 ?

Revision history for this message
Zhang Lily (r58066) wrote :

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.

Revision history for this message
Loïc Minier (lool) wrote :

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.

Revision history for this message
Oliver Grawert (ogra) wrote :

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 ?

Revision history for this message
Dave Martin (dave-martin-arm) wrote :

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)

Revision history for this message
Alexander Sack (asac) wrote :

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

Changed in uboot-imx (Ubuntu Lucid):
importance: Critical → Undecided
milestone: lucid-alpha-3 → none
Revision history for this message
Alexander Sack (asac) wrote :

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

Changed in uboot-imx (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in uboot-imx (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Oliver Grawert (ogra) wrote :

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.

Revision history for this message
Alexander Sack (asac) wrote :

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)
Changed in uboot-imx (Ubuntu Lucid):
status: Won't Fix → Triaged
status: Triaged → Confirmed
importance: Undecided → Critical
Alexander Sack (asac)
Changed in uboot-imx (Ubuntu Lucid):
milestone: none → lucid-alpha-3
Revision history for this message
Alexander Sack (asac) wrote :

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

Changed in uboot-imx (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in uboot-imx (Ubuntu):
milestone: lucid-alpha-3 → later
Paul Larson (pwlars)
Changed in uboot-imx (Ubuntu Lucid):
milestone: lucid-alpha-3 → none
Revision history for this message
Paul Larson (pwlars) wrote :

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.

Changed in uboot-imx (Ubuntu Lucid):
importance: Critical → Medium
Changed in uboot-imx (Ubuntu):
importance: Critical → Medium
Revision history for this message
Oliver Grawert (ogra) wrote :

wont happen for lucid or other older releases...

Changed in uboot-imx (Ubuntu):
status: Confirmed → Won't Fix
Revision history for this message
Taiten Peng (taitenpeng) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers