I made a l-m-c patch to add imx51 support. I need your help to review and merge the code.
Only one comment for now. I'll test the patch.
On Wed, Sep 29, 2010 at 3:51 PM, Shawn Guo shawn.gsc@gmail.com wrote:
I made a l-m-c patch to add imx51 support. I need your help to review and merge the code.
-- Regards, Shawn
# Begin patch === modified file 'linaro-media-create' --- linaro-media-create 2010-09-28 18:53:19 +0000 +++ linaro-media-create 2010-09-30 00:36:30 +0000 @@ -62,6 +62,7 @@ * beagle * igep * vexpress
- * imx51
This should be named mx51evk or babbage3.0 since we'll support other imx51 boards later.
Additional/Optional options: -h --help @@ -274,7 +275,16 @@ }
On Wed, Sep 29, 2010, Shawn Guo wrote:
I made a l-m-c patch to add imx51 support. I need your help to review and merge the code.
Thanks!
You probably want to use the board name, mx51evk, not the SoC name, imx51; this also avoids mixing mx51 (kernel flavor) and imx51 (DEVNAME) in the script.
install_hwpack() {
- ensure_command qemu-arm-static qemu-arm-static
- # Check host architecture
- arch_is_arm=false
- arch_str=`uname -m`
- if [[ "$arch_str" == arm* ]]; then
- arch_is_arm=true
- fi
- if [ ! $arch_is_arm ]; then
These [ ! false ] or [ ! true ] are incorrect; [ ! anything ] is always false; "!" tests for non-empty.
I suggest you move the ensure_command to the place where qemu is copied and change it into something less bash-specific for readability: local arch_is_arm=no case `uname -m` in arm*) arch_is_arm=yes ensure_command qemu-arm-static qemu-arm-static sudo cp /usr/bin/qemu-arm-static ${chroot}/usr/bin ;; esac [...] if [ "arch_is_arm" = no ]; then sudo rm -f ${chroot}/usr/bin/qemu-arm-static fi
@@ -371,10 +385,17 @@
# Create a VFAT or FAT16 partition of 9 cylinders which is about 64M # and a linux partition of the rest
- if [ "$DEVIMAGE" = imx51 ]; then
- sudo sfdisk -D -H $HEADS -S $SECTORS $CYLINDER_ARG $partdev << THEEND
+1,9,$PARTITION_TYPE,* +10,,,- +THEEND
- else sudo sfdisk -D -H $HEADS -S $SECTORS $CYLINDER_ARG $partdev << THEEND
,9,$PARTITION_TYPE,* ,,,- THEEND
- fi
Could we just use the same partition layout for all images (the imx51 one), avoiding the if entirely?
Not your doing, but the sfdisk man page recommends avoiding the c,h,s specs especially since -H/-S are passed already
If you're using the early data on the image to store stuff, I recommend you protect it with a dumb partition (e.g. "non-FS data" type, 0xda).
- imx51)
sudo dd if=binary/usr/lib/u-boot/mx51evk/u-boot.imxof=/dev/mmcblk0 bs=512 seek=2
bs=1024 seek=1?
I definitely think you want a non-FS data partition protecting this zone
sync
Do you really need a sync in there? There are a bunch of syncs in the script already
sudo mkimage -A arm -O linux -T kernel -C none -a 0x90008000 -e0x90008000 \
-n Linux -d "${DIR}/binary/${parts_dir}"/vmlinuz*-mx51"${BOOT_DISK}/uImage"
sudo mkimage -A arm -O linux -T ramdisk -C none -a 0 \-e 0 -n initramfs \-d "${DIR}/binary/${parts_dir}"/initrd.img-*-linaro-mx51 \"${BOOT_DISK}/uInitrd"
Could you use -linaro-mx51 for the vmlinuz pattern as well? Ideally, please wrap this at 80 chars like the rest of the code now.
cat > ${TMP_DIR}/boot.cmd << BOOTCMD+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
+setenv bootargs '${serial_opts} ${splash_opts} ${lowmem_opt} ${boot_snippet} rootwait ro' +boot +BOOTCMD
would be great if you could merge this with the create_boot_cmd() logic
sudo mkimage -A arm -O linux -T script -C none -a 0 \-e 0 -n "$CODENAME 10.05" -d "${TMP_DIR}/boot.cmd" \"${BOOT_DISK}/boot.scr";;
the -n stuff needs to be updated
Otherwise looks good, thanks again!
Thanks for reviewing and helping. I addressed the the comments with the updated patch, except the following ones.
@@ -371,10 +385,17 @@
# Create a VFAT or FAT16 partition of 9 cylinders which is about 64M # and a linux partition of the rest
- if [ "$DEVIMAGE" = imx51 ]; then
- sudo sfdisk -D -H $HEADS -S $SECTORS $CYLINDER_ARG $partdev << THEEND
+1,9,$PARTITION_TYPE,* +10,,,- +THEEND
- else
sudo sfdisk -D -H $HEADS -S $SECTORS $CYLINDER_ARG $partdev << THEEND ,9,$PARTITION_TYPE,* ,,,- THEEND
- fi
Could we just use the same partition layout for all images (the imx51 one), avoiding the if entirely?
I'm unsure if OMAP ROM will be unhappy if the FAT partition is not at the beginning.
Not your doing, but the sfdisk man page recommends avoiding the c,h,s specs especially since -H/-S are passed already
If you're using the early data on the image to store stuff, I recommend you protect it with a dumb partition (e.g. "non-FS data" type, 0xda).
The u-boot.imx really needs to be at offset 1KB on card to make imx51 ROM happy. Even I create the "non-FS data" partition from 0 cylinder with sfdisk, it actually starts from sector 63 (offset ~ 32KB). We can not really get the u-boot.imx into this partition for now.
- cat > ${TMP_DIR}/boot.cmd << BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
This is something I'm not very clear. This bootcmd is written into boot.scr which has to be loaded out from card first, in order to launch the bootcmd. So we need to get "mmc init" executed before we load fatload boot.scr.
Maybe it's an issue. The u-boot.imx "mmc init" is not working in this case. I have to run "mmcinfo" before the first fatload, or it hangs.
On Thu, Sep 30, 2010 at 8:00 AM, Shawn Guo shawn.gsc@gmail.com wrote:
Could we just use the same partition layout for all images (the imx51 one), avoiding the if entirely?
I'm unsure if OMAP ROM will be unhappy if the FAT partition is not at the beginning.
I agree. Also it feels risky to me to change the partition layout of omap etc. at this point in cycle.
If you're using the early data on the image to store stuff, I recommend you protect it with a dumb partition (e.g. "non-FS data" type, 0xda).
The u-boot.imx really needs to be at offset 1KB on card to make imx51 ROM happy. Even I create the "non-FS data" partition from 0 cylinder with sfdisk, it actually starts from sector 63 (offset ~ 32KB). We can not really get the u-boot.imx into this partition for now.
I think the non-FS data partition is only there so you dont get it offered as free space if you later run fdisk etc.. Maybe see if creating that non-fs partition hurts even if the start offset is a bit odd.
- cat > ${TMP_DIR}/boot.cmd << BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
This is something I'm not very clear. This bootcmd is written into boot.scr which has to be loaded out from card first, in order to launch the bootcmd. So we need to get "mmc init" executed before we load fatload boot.scr.
Maybe it's an issue. The u-boot.imx "mmc init" is not working in this case. I have to run "mmcinfo" before the first fatload, or it hangs.
yeah. that was a bug i saw in some BSP u-boot for imx51 a few month back. And yes, the mmc init already needs to be part of of the built-in default commands in order to find the boot.scr on SD. So I don't think we need it in boot.scr.
On Thu, Sep 30, 2010 at 9:48 AM, Alexander Sack asac@linaro.org wrote:
On Thu, Sep 30, 2010 at 8:00 AM, Shawn Guo shawn.gsc@gmail.com wrote:
The u-boot.imx really needs to be at offset 1KB on card to make imx51 ROM happy. Even I create the "non-FS data" partition from 0 cylinder with sfdisk, it actually starts from sector 63 (offset ~ 32KB). We can not really get the u-boot.imx into this partition for now.
I think the non-FS data partition is only there so you dont get it offered as free space if you later run fdisk etc.. Maybe see if creating that non-fs partition hurts even if the start offset is a bit odd.
I think this is the only pending change left. I talked to Jamie and since we want to get the main feature in asap, we decided to merge your current patch. Please submit a follow up commit with the non-fs-data partition soonish.
Thanks for your work!!
On Thu, Sep 30, 2010 at 11:10 AM, Alexander Sack asac@linaro.org wrote:
On Thu, Sep 30, 2010 at 9:48 AM, Alexander Sack asac@linaro.org wrote:
On Thu, Sep 30, 2010 at 8:00 AM, Shawn Guo shawn.gsc@gmail.com wrote:
The u-boot.imx really needs to be at offset 1KB on card to make imx51 ROM happy. Even I create the "non-FS data" partition from 0 cylinder with sfdisk, it actually starts from sector 63 (offset ~ 32KB). We can not really get the u-boot.imx into this partition for now.
I think the non-FS data partition is only there so you dont get it offered as free space if you later run fdisk etc.. Maybe see if creating that non-fs partition hurts even if the start offset is a bit odd.
I think this is the only pending change left. I talked to Jamie and since we want to get the main feature in asap, we decided to merge your current patch. Please submit a follow up commit with the non-fs-data partition soonish.
What is the advantage of a non-fs-data partition over just leaving empty space at the beginning of the block device?
/Amit
On Thu, Sep 30, 2010 at 10:58 AM, Loïc Minier loic.minier@linaro.org wrote:
On Thu, Sep 30, 2010, Amit Kucheria wrote:
What is the advantage of a non-fs-data partition over just leaving empty space at the beginning of the block device?
That actually marks this space as being in use
Right. So the practical difference is that won't get this space offered as being free in your preferred partition tool ... reducing risk that you accidentially wipe u-boot from your SD.
On Thu, Sep 30, 2010, Alexander Sack wrote:
Right. So the practical difference is that won't get this space offered as being free in your preferred partition tool ... reducing risk that you accidentially wipe u-boot from your SD.
You can also more easily save/replace your bootloader and/or its data, whatever is in there. For instance, dd if=u-boot.imx of=/dev/sdb2 to write a new bootloader instead of bs=/seek=/skip= etc.
On Thu, Sep 30, 2010, Shawn Guo wrote:
I'm unsure if OMAP ROM will be unhappy if the FAT partition is not at the beginning.
According to the docs, OMAP ROM searches for a FAT partition with the bootable flag turned on. It certainly doesn't care (too much) about the location of the partition. I added a non-FS data partition in the bzr version now, and factored your code with the general case.
The u-boot.imx really needs to be at offset 1KB on card to make imx51 ROM happy. Even I create the "non-FS data" partition from 0 cylinder with sfdisk, it actually starts from sector 63 (offset ~ 32KB). We can not really get the u-boot.imx into this partition for now.
Sounds like a bug in sfdisk. I guess we need to move to parted at some point.
- cat > ${TMP_DIR}/boot.cmd << BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
This is something I'm not very clear. This bootcmd is written into boot.scr which has to be loaded out from card first, in order to launch the bootcmd. So we need to get "mmc init" executed before we load fatload boot.scr.
Hmm you're right; I was wondering because the other boards at one, but these boards need to drop it! Fixed
Maybe it's an issue. The u-boot.imx "mmc init" is not working in this case. I have to run "mmcinfo" before the first fatload, or it hangs.
If "mmc init" breaks in mx51evk u-boot, we should probably fix it; you could start by filing a bug against u-boot-linaro to track this, explaining how to trigger the bug.
On Thu, Sep 30, 2010, Loïc Minier wrote:
I added a non-FS data partition in thebzr version now, and factored your code with the general case.
Hmm I'll have to disable that on OMAP, otherwise u-boot wont find the boot script -- the ROM case was fine (user button pressed), but not the u-boot one.
On Thu, Sep 30, 2010 at 6:25 PM, Loïc Minier loic.minier@linaro.org wrote:
On Thu, Sep 30, 2010, Loïc Minier wrote:
I added a non-FS data partition in the bzr version now, and factored your code with the general case.
Hmm I'll have to disable that on OMAP, otherwise u-boot wont find the boot script -- the ROM case was fine (user button pressed), but not the u-boot one.
I'm not sure if it's the correct file to check, but I saw following line in u-boot-linaro-stable/include/configs/omap3_beagle.h.
"loadbootscript=fatload mmc 0 ${loadaddr} boot.scr\0"
That means beagle u-boot will always try to load boot.scr from the first partition, which probably makes Non-FS data partition implementation fails on beagle.
I tested the latest l-m-c and found it has problem even with mx51evk. As Non-FS data partition was added for mx51evk, the partition id for boot_disk and root_disk have to be incremented.
On Wed, Oct 06, 2010, Shawn Guo wrote:
That means beagle u-boot will always try to load boot.scr from the first partition, which probably makes Non-FS data partition implementation fails on beagle.
Yes; I had backed it out on beagle last week when I realized the same thing (20100930102516.GE26865@bee.dooz.org).
I tested the latest l-m-c and found it has problem even with mx51evk. As Non-FS data partition was added for mx51evk, the partition id for boot_disk and root_disk have to be incremented.
Ah sorry about that; I've backed out the change in this branch: lp:~lool/linaro-image-tools/back-out-non-fs-data-partition would you mind testing it and I'll merge it in mainline if it works as expected
(I don't have mx51evk to test myself)
Thanks!
On Wed, Oct 6, 2010 at 11:28 AM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Shawn Guo wrote:
That means beagle u-boot will always try to load boot.scr from the first partition, which probably makes Non-FS data partition implementation fails on beagle.
Yes; I had backed it out on beagle last week when I realized the same thing (20100930102516.GE26865@bee.dooz.org).
I tested the latest l-m-c and found it has problem even with mx51evk. As Non-FS data partition was added for mx51evk, the partition id for boot_disk and root_disk have to be incremented.
Ah sorry about that; I've backed out the change in this branch: lp:~lool/linaro-image-tools/back-out-non-fs-data-partition would you mind testing it and I'll merge it in mainline if it works as expected
How about something like lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead of backing out?
On Wed, Oct 06, 2010, Alexander Sack wrote:
How about something like lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead of backing out?
Thanks; I think that would work; you might want to patch root=/dev/mmcblk0p2 too
Perhaps you could add a comment near MMCOFFSET explaining what it does?
Thanks for fixing things up!
On Wed, Oct 6, 2010 at 12:58 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
How about something like lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead of backing out?
Thanks; I think that would work; you might want to patch root=/dev/mmcblk0p2 too
good catch. will do. i just noticed that we have boot_snippet=UUID=... still ... should we fix that to use the /dev/? or rather go for UUID everywhere?
Perhaps you could add a comment near MMCOFFSET explaining what it does?
yeah ... thought about that after pushing. will add comments.
Thanks for fixing things up!
Loďc Minier
On Wed, Oct 6, 2010 at 1:04 PM, Alexander Sack asac@linaro.org wrote:
On Wed, Oct 6, 2010 at 12:58 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
How about something like lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout instead of backing out?
Thanks; I think that would work; you might want to patch root=/dev/mmcblk0p2 too
good catch. will do. i just noticed that we have boot_snippet=UUID=... still ... should we fix that to use the /dev/? or rather go for UUID everywhere?
Re-pushed to same location. I used $MMC2 for root= and $MMC1 for UBOOT_PART= in flash-kernel.conf ... haven't tested.
On Wed, Oct 6, 2010 at 7:18 PM, Alexander Sack asac@linaro.org wrote:
Re-pushed to same location. I used $MMC2 for root= and $MMC1 for UBOOT_PART= in flash-kernel.conf ... haven't tested.
Tested it on mx51evk and it works fine.
On Wed, Oct 6, 2010 at 1:52 PM, Shawn Guo shawn.gsc@gmail.com wrote:
On Wed, Oct 6, 2010 at 7:18 PM, Alexander Sack asac@linaro.org wrote:
Re-pushed to same location. I used $MMC2 for root= and $MMC1 for UBOOT_PART= in flash-kernel.conf ... haven't tested.
Tested it on mx51evk and it works fine.
Thanks for confirm.
pushed lp:~asac/linaro-image-tools/part-offset-for-non-fs-data-layout to lp:linaro-image-tools (rev 133)
On Wed, Oct 06, 2010, Alexander Sack wrote:
good catch. will do. i just noticed that we have boot_snippet=UUID=... still ... should we fix that to use the /dev/? or rather go for UUID everywhere?
I think we should use UUID everywhere; in fact, there's a bug about lack of usage of an initrd in the image file case open. Note that you need initrd support for root=UUID=xyz stuff.
On Wed, Oct 6, 2010 at 1:25 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
good catch. will do. i just noticed that we have boot_snippet=UUID=... still ... should we fix that to use the /dev/? or rather go for UUID everywhere?
I think we should use UUID everywhere; in fact, there's a bug about lack of usage of an initrd in the image file case open. Note that you need initrd support for root=UUID=xyz stuff.
Hmm ... just made a patch going the other direction:
lp:~asac/linaro-image-tools/boot-snippet-cleanup
IMO, not requiring initrd feels something that we would want anyway sooner or later. But no strong opinion for this cycle either way.
BTW, do you know why the boot.cmd line for beagle IMAGE_FILE case used root= rather than boot_snippet? was there a bug in qemu about initrd or just a follow up hack of not using initrd there?
On Wed, Oct 6, 2010 at 1:29 PM, Alexander Sack asac@linaro.org wrote:
On Wed, Oct 6, 2010 at 1:25 PM, Loïc Minier loic.minier@linaro.org wrote:
I think we should use UUID everywhere; in fact, there's a bug about lack of usage of an initrd in the image file case open. Note that you need initrd support for root=UUID=xyz stuff.
Hmm ... just made a patch going the other direction:
lp:~asac/linaro-image-tools/boot-snippet-cleanup
Here what would happen if we use UUID everywhere:
lp:~asac/linaro-image-tools/unity-omap-bootcmd
I guess someone (mattman?) should sign this off and see if everything is still fine in qemu.
On Wed, Oct 6, 2010 at 1:46 PM, Alexander Sack asac@linaro.org wrote:
lp:~asac/linaro-image-tools/unity-omap-bootcmd
sorry for the noise. this was a typo. look at:
lp:~asac/linaro-image-tools/unify-omap-bootcmd
On Wed, Oct 06, 2010, Alexander Sack wrote:
Here what would happen if we use UUID everywhere: lp:~asac/linaro-image-tools/unify-omap-bootcmd
I've just noticed that this should use $INITRD_ADDR as done in bootm (not your doing but mine)
Note that there's still the mmc 0:1 which means first partition and wont work with the other change we're discussing
I guess someone (mattman?) should sign this off and see if everything is still fine in qemu.
It's more Peter looking after QEMU these days; Cc:ing him
On Wed, Oct 6, 2010 at 2:28 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
Here what would happen if we use UUID everywhere: lp:~asac/linaro-image-tools/unify-omap-bootcmd
I've just noticed that this should use $INITRD_ADDR as done in bootm (not your doing but mine)
Note that there's still the mmc 0:1 which means first partition and wont work with the other change we're discussing
Oh. I assumed u-boot does not see our non-fs data partition and our boot partition is mmc 0:1. But now I see that we use mmc 0:2 for mx51evk. I guess Shawn checked that this boots? If so we should guess it from offset accordingly.
I guess someone (mattman?) should sign this off and see if everything is still fine in qemu.
It's more Peter looking after QEMU these days; Cc:ing him
Peter, the basic idea is to use linaro-media-create from the branch mentioned above with --image_file option to produce a bootable qemu image. beagle board hwpack with headless working for our qemu in linaro is the goal here.
On 6 October 2010 17:14, Alexander Sack asac@linaro.org wrote:
On Wed, Oct 6, 2010 at 2:28 PM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Oct 06, 2010, Alexander Sack wrote:
I guess someone (mattman?) should sign this off and see if everything is still fine in qemu.
It's more Peter looking after QEMU these days; Cc:ing him
Peter, the basic idea is to use linaro-media-create from the branch mentioned above with --image_file option to produce a bootable qemu image. beagle board hwpack with headless working for our qemu in linaro is the goal here.
I'm on holiday so I'm not really in a position to test things until the start of next week, I'm afraid. (Also I've had reports that images weren't booting on qemu any more as a result of the kernel triggering an issue with the NAND modelling: https://bugs.launchpad.net/qemu-maemo/+bug/645311 so even if you do test with your updated script it might fail through no fault of the image creation script...)
-- PMM
On Thu, Oct 7, 2010 at 12:14 AM, Alexander Sack asac@linaro.org wrote:
Note that there's still the mmc 0:1 which means first partition and wont work with the other change we're discussing
Oh. I assumed u-boot does not see our non-fs data partition and our boot partition is mmc 0:1. But now I see that we use mmc 0:2 for mx51evk. I guess Shawn checked that this boots? If so we should guess it from offset accordingly.
Yes, I can only boot with mmc 0:2 on mx51evk, so u-boot should be able to see the non-fs data partition.
On Wed, Oct 06, 2010, Alexander Sack wrote:
lp:~asac/linaro-image-tools/boot-snippet-cleanup
IMO, not requiring initrd feels something that we would want anyway sooner or later. But no strong opinion for this cycle either way.
BTW, do you know why the boot.cmd line for beagle IMAGE_FILE case used root= rather than boot_snippet? was there a bug in qemu about initrd or just a follow up hack of not using initrd there?
I personally find UUID much cleaner than hardcoded device name; it is useful for changing the boot device (e.g. from MMC to USB); for instance, we're discussing moving to rootfs on USB on vexpress
On Wed, Oct 6, 2010 at 5:28 PM, Loïc Minier loic.minier@linaro.org wrote:
Ah sorry about that; I've backed out the change in this branch: lp:~lool/linaro-image-tools/back-out-non-fs-data-partition would you mind testing it and I'll merge it in mainline if it works as expected
There is a typo at line 403. The "<EOF" should be "<< EOF"?
And I'm not sure if it's another issue with sfdisk. But I will get the following layout with the sfdisk command in your l-m-c.
$ sudo fdisk -l -u /dev/mmcblk0
Disk /dev/mmcblk0: 1 GB, 1965841920 bytes 255 heads, 63 sectors/track, 239 cylinders, total 3839535 sectors Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System /dev/mmcblk0p2 63 16064 0 83 Linux /dev/mmcblk0p1 * 16065 160649 80262 c FAT32 LBA
This is actually the issue I ran into when I was working on mx51evk support. And I have to make it like the following to get the expected layout.
sudo sfdisk -D -H $HEADS -S $SECTORS $CYLINDER_ARG $partdev << THEEND 1,9,$PARTITION_TYPE,* 10,,,- THEEND
On Wed, Oct 06, 2010, Shawn Guo wrote:
There is a typo at line 403. The "<EOF" should be "<< EOF"?
Fixed in the branch; thanks
/dev/mmcblk0p2 63 16064 0 83 Linux /dev/mmcblk0p1 * 16065 160649 80262 c FAT32 LBA
This is actually the issue I ran into when I was working on mx51evk support. And I have to make it like the following to get the expected layout.
Ah, I'm not surprized; this is exactly the type of things which pushes me to create a non-FS-data partition to start with; I've added the "10" offset to the branch now
I would prefer if we could go with asac's branch though
On Thu, Sep 30, 2010 at 5:37 PM, Loïc Minier loic.minier@linaro.org wrote:
- cat > ${TMP_DIR}/boot.cmd << BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
This is something I'm not very clear. This bootcmd is written into boot.scr which has to be loaded out from card first, in order to launch the bootcmd. So we need to get "mmc init" executed before we load fatload boot.scr.
Hmm you're right; I was wondering because the other boards at one, but these boards need to drop it! Fixed
Maybe it's an issue. The u-boot.imx "mmc init" is not working in this case. I have to run "mmcinfo" before the first fatload, or it hangs.
If "mmc init" breaks in mx51evk u-boot, we should probably fix it; you could start by filing a bug against u-boot-linaro to track this, explaining how to trigger the bug.
https://bugs.launchpad.net/u-boot-linaro/+bug/655461
On Wed, Oct 6, 2010 at 11:13 AM, Shawn Guo shawn.gsc@gmail.com wrote:
On Thu, Sep 30, 2010 at 5:37 PM, Loïc Minier loic.minier@linaro.org wrote:
- cat > ${TMP_DIR}/boot.cmd << BOOTCMD
+setenv bootcmd 'fatload mmc 0:1 0x90000000 uImage; fatload mmc 0:1 0x90800000 uInitrd; bootm 0x90000000 0x90800000'
no mmc init?
This is something I'm not very clear. This bootcmd is written into boot.scr which has to be loaded out from card first, in order to launch the bootcmd. So we need to get "mmc init" executed before we load fatload boot.scr.
Hmm you're right; I was wondering because the other boards at one, but these boards need to drop it! Fixed
Maybe it's an issue. The u-boot.imx "mmc init" is not working in this case. I have to run "mmcinfo" before the first fatload, or it hangs.
If "mmc init" breaks in mx51evk u-boot, we should probably fix it; you could start by filing a bug against u-boot-linaro to track this, explaining how to trigger the bug.
My investigation shows this may not be a bug. I updated the details in the bug page.
-
Alexander Sack -
Amit Kucheria -
Loïc Minier -
Peter Maydell -
Shawn Guo