[U-Boot-Users] Booting multi-file images with a FDT but no initrd
Hello U-boot list!
I'm using U-boot 1.3.0 to boot Linux on a Freescale MPC8349E-mITX, and I have a small issue with multi-file images. I use a device tree but no initrd, and I'm not quite sure how to boot the image in a good way. The image is created in this way:
mkimage -A ppc -O Linux -T multi -d vmlinux.bin.gz:cmxb.dtb /tftpboot/vmlinux+fdt.img
I can boot it with (in U-boot)
setenv loadaddr 600000 tftp $loadaddr /tftpboot/vmlinux+fdt.img bootm $loadaddr - 7a9634
and it starts just fine. My issue is with the address of the FDT - I'd like to avoid having to hardcode this address since the kernel size can change. If I just do 'bootm' or 'bootm $loadaddr -' it will end with
Verifying Checksum ... OK Uncompressing Multi-File Image ... OK Loading Ramdisk to 0ff6c000, end 0ff6f000 ... OK
and just lock there. So to the question: Is it possible to boot a multifile image in this way without having an initrd and without the hardcoded address, or must I modify the U-boot code to get such functionality?
// Simon
In message 20071204150416.7aa7dda6@seasc0532.dyn.rnd.as.sw.ericsson.se you wrote:
I'm using U-boot 1.3.0 to boot Linux on a Freescale MPC8349E-mITX, and I have a small issue with multi-file images. I use a device tree but no initrd, and I'm not quite sure how to boot the image in a good way. The image is created in this way:
In theory this should "just work", but it doesn't at the moment. There are plans to implement a more flexible format for U-Boot images, especially for multi-file images, which will solve this problem.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Tue, 04 Dec 2007 16:28:24 +0100 Wolfgang Denk wd@denx.de wrote:
In message 20071204150416.7aa7dda6@seasc0532.dyn.rnd.as.sw.ericsson.se you wrote:
I'm using U-boot 1.3.0 to boot Linux on a Freescale MPC8349E-mITX, and I have a small issue with multi-file images. I use a device tree but no initrd, and I'm not quite sure how to boot the image in a good way. The image is created in this way:
In theory this should "just work", but it doesn't at the moment. There are plans to implement a more flexible format for U-Boot images, especially for multi-file images, which will solve this problem.
Thanks for the information.
I solved it for now by creating a standalone application which reads the multi-file image and sets the "fdtaddr" environment variable if it finds one. I can thereafter boot with (basically)
tftp $loadaddr ... tftp 40000 .../parse-multifile go 40004 $loadaddr bootm $loadaddr - $fdtaddr
If anyone is interested, I can send the short C-file.
// Simon
Simon Kagstrom wrote: [...]
I'm using U-boot 1.3.0 to boot Linux on a Freescale MPC8349E-mITX, and I have a small issue with multi-file images. I use a device tree but no initrd, and I'm not quite sure how to boot the image in a good way. The image is created in this way:
[...]
I solved it for now by creating a standalone application which reads the multi-file image and sets the "fdtaddr" environment variable if it finds one.
Hi Simon,
Another workaround is to use a mulit-image file with three images (kernel, initrd, blob) and ignore the second one by calling "bootm <addr> -". Note that the second image in the file can a bogus one-byte file (it needs to be at least one byte in size, because mkimage refuses the create a multi-image file with a zero-sized member).
Note that this booting scenario will be supported in a much more elegant manner once the new image format is developed. Please stay tuned.
Regards, Bartlomiej
On Wed, 05 Dec 2007 11:08:46 +0100 Bartlomiej Sieka tur@semihalf.com wrote:
Another workaround is to use a mulit-image file with three images (kernel, initrd, blob) and ignore the second one by calling "bootm <addr> -". Note that the second image in the file can a bogus one-byte file (it needs to be at least one byte in size, because mkimage refuses the create a multi-image file with a zero-sized member).
Ah, you are right. I thought I tested this before but apparently I did some mistake then. It boots OK now, and this is clearly a more clean workaround until the new image format arrives.
Thanks, // Simon
participants (3)
-
Bartlomiej Sieka -
Simon Kagstrom -
Wolfgang Denk