[opensuse-arm] Stupid questions about u-boot, kernel, boot.scr.img
Hi all, I'm trying to get RasPi to boot with U-Boot, streamlined with the other ARM platforms (I guess). So how is this designed to work? That's what I understand: * U-Boot * loads boot.scr.img from <whatever the board boots from> * boot.scr loads kernel.img * really?, or the zImage directly? * from where? always from the same boot partition U-Boot came from? or possibly from the root fs? (extload should be able to do that?) * maybe boot.scr has the kernel cmdline embedded? Or does it load it from storage? If this is not correct, please tell me the correct sequence (or point me to the documentation ;) Then, the more interesting questions are: * who creates kernel.img U-Boot image (if this is used)? * who creates boot.scr.img? Actually I am trying to do the following for the RPI: * u-boot on SDCard FAT partition * boot.script on SDCard FAT partition, intelligent enough to fetch some sort of config from /boot on ext4 rootfs (for kernel command line options) * boot.script to load kernel from /boot on ext4 rootfs The idea is, that the FAT partitions does not need to be touched after a kernel update etc, but that it will just fetch all that's needed from the rootfs. Not sure if this is a good idea and if it is going to work, but it would surely make kernel updates etc. much more painless than they are now. Best regards, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi, Le 10/09/2013 15:43, Stefan Seyfried a écrit :
Hi all,
I'm trying to get RasPi to boot with U-Boot, streamlined with the other ARM platforms (I guess).
Raspberry Pi is a bit special. ;)
So how is this designed to work? That's what I understand:
* U-Boot * loads boot.scr.img from <whatever the board boots from> * boot.scr loads kernel.img * really?, or the zImage directly? * from where? always from the same boot partition U-Boot came from? or possibly from the root fs? (extload should be able to do that?) * maybe boot.scr has the kernel cmdline embedded? Or does it load it from storage?
boot.scr is a compiled version of boot.script. So it depends what you put in boot.script. We should use zImage from /boot in rootfs if possible.
If this is not correct, please tell me the correct sequence (or point me to the documentation ;)
Then, the more interesting questions are: * who creates kernel.img U-Boot image (if this is used)?
It is you when you call make in u-boot
* who creates boot.scr.img?
It is you in the u-boot rpm build.
Actually I am trying to do the following for the RPI:
* u-boot on SDCard FAT partition * boot.script on SDCard FAT partition, intelligent enough to fetch some sort of config from /boot on ext4 rootfs (for kernel command line options) * boot.script to load kernel from /boot on ext4 rootfs
The idea is, that the FAT partitions does not need to be touched after a kernel update etc, but that it will just fetch all that's needed from the rootfs.
Good idea. ;)
Not sure if this is a good idea and if it is going to work, but it would surely make kernel updates etc. much more painless than they are now.
I am ok with that. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 10.09.2013 15:58, schrieb Guillaume Gardet:
Hi,
Le 10/09/2013 15:43, Stefan Seyfried a écrit :
Hi all,
I'm trying to get RasPi to boot with U-Boot, streamlined with the other ARM platforms (I guess).
Raspberry Pi is a bit special. ;)
I know :-)
boot.scr is a compiled version of boot.script. So it depends what you put in boot.script. We should use zImage from /boot in rootfs if possible.
I managed to do that. Steps to achieve this: 1) I patched U-Boot to preserve the command line that the bootcode.bin passed to it (the bootcode.bin is loading the u-boot as a kernel, so it passes the commandline) and expose it as $bootargs_orig. Additionally I enabled ext2/ext4 Filesytems. Result is in home:seife:ARM/u-boot-rpib 2) installed my u-boot-rpib.rpm, copied /boot/u-boot.bin onto the FAT-partition (not renamed). 3) edit config.txt on the FAT partition, add the line kernel=u-boot.bin 4) create a script, e.g. /tmp/boot.scr: # u-boot script to boot from second partition, can be / or /boot prefixes="/boot/ /" kernel="zImage" dev=mmc part=0:2 # second partition # the boot args we got from the firmware loader setenv bootargs \"$bootargs_orig\" echo echo "searching for kernel in..." for prefix in $prefixes; do echo "\\c $prefix " # hush has no "break" command, so we must put this inside the loop... if load $dev $part $kernel_addr_r ${prefix}zImage; then echo echo "booting the kernel... good luck :-)" echo bootz $kernel_addr_r fi done 5) create a u-boot image from the script: mkimage -A arm -T script -C none -n "RaspberryPi boot helper" \ -d /tmp/boot.scr /tmp/boot.scr.uimg 6) copy /boot.scr.uimg onto the FAT partition. 7) reboot, enjoy! :-) The script searches zImage in the second partition, which should be ext2 or ext4. It searches first in /boot, if this fails it tries /, so that a setup with 3 partitions, first FAT, second ext2 /boot, third for rootfs will also work.
* who creates boot.scr.img?
It is you in the u-boot rpm build.
Well, I did not find anything in the u-boot build / spec file that would do this. I notice that other architectures also use a boot.scr, wo I was wondering which part of the build process actually creates this script / image file.
Actually I am trying to do the following for the RPI:
* u-boot on SDCard FAT partition * boot.script on SDCard FAT partition, intelligent enough to
This works
fetch some sort of config from /boot on ext4 rootfs (for kernel command line options)
I did not get this to work (without compiling the config into a uimage file, which would not be "easy" to edit), so I guess we have to live with cmdline.txt in the FAT partition for now (this gets read by the bootcode.bin loader) which is not the worst we could have :-) Have fun and good luck :-) Stefan -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
On 10.09.2013, at 16:46, Stefan Seyfried wrote:
Am 10.09.2013 15:58, schrieb Guillaume Gardet:
Hi,
Le 10/09/2013 15:43, Stefan Seyfried a écrit :
Hi all,
I'm trying to get RasPi to boot with U-Boot, streamlined with the other ARM platforms (I guess).
Raspberry Pi is a bit special. ;)
I know :-)
boot.scr is a compiled version of boot.script. So it depends what you put in boot.script. We should use zImage from /boot in rootfs if possible.
I managed to do that.
Steps to achieve this:
1) I patched U-Boot to preserve the command line that the bootcode.bin passed to it (the bootcode.bin is loading the u-boot as a kernel, so it passes the commandline) and expose it as $bootargs_orig. Additionally I enabled ext2/ext4 Filesytems. Result is in home:seife:ARM/u-boot-rpib
2) installed my u-boot-rpib.rpm, copied /boot/u-boot.bin onto the FAT-partition (not renamed).
3) edit config.txt on the FAT partition, add the line
kernel=u-boot.bin
4) create a script, e.g. /tmp/boot.scr:
# u-boot script to boot from second partition, can be / or /boot prefixes="/boot/ /" kernel="zImage" dev=mmc part=0:2 # second partition # the boot args we got from the firmware loader setenv bootargs \"$bootargs_orig\" echo echo "searching for kernel in..." for prefix in $prefixes; do echo "\\c $prefix " # hush has no "break" command, so we must put this inside the loop... if load $dev $part $kernel_addr_r ${prefix}zImage; then echo echo "booting the kernel... good luck :-)" echo bootz $kernel_addr_r fi done
5) create a u-boot image from the script:
mkimage -A arm -T script -C none -n "RaspberryPi boot helper" \ -d /tmp/boot.scr /tmp/boot.scr.uimg
6) copy /boot.scr.uimg onto the FAT partition.
7) reboot, enjoy! :-)
The script searches zImage in the second partition, which should be ext2 or ext4. It searches first in /boot, if this fails it tries /, so that a setup with 3 partitions, first FAT, second ext2 /boot, third for rootfs will also work.
* who creates boot.scr.img?
It is you in the u-boot rpm build.
Well, I did not find anything in the u-boot build / spec file that would do this. I notice that other architectures also use a boot.scr, wo I was wondering which part of the build process actually creates this script / image file.
It's part of the JeOS package :). Oh, and thanks a lot for sitting down on this! I'm looking very much forward to a full ARMv6 tree with u-boot enabled Raspberry PI support :). Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Hi Stefan, thanks a lot for wrapping your head around it..
The script searches zImage in the second partition, which should be ext2 or ext4. It searches first in /boot, if this fails it tries /, so that a setup with 3 partitions, first FAT, second ext2 /boot, third for rootfs will also work.
Right. what we usually did though is the patch the bootloader to load the SPL from extX, if possible, so that we can avoid the FAT partition. Other than that I think there is a magic "use UEFI partition layout" flag in kiwi to create the extra fat partition..
* who creates boot.scr.img? It is you in the u-boot rpm build.
No, actually it is uboot-image-setup.in in openSUSE:Factory:ARM JeOS Greetings, Dirk -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
Am 11.09.2013 12:37, schrieb Dirk Müller:
Hi Stefan,
thanks a lot for wrapping your head around it..
I'm still trying :-)
The script searches zImage in the second partition, which should be ext2 or ext4. It searches first in /boot, if this fails it tries /, so that a setup with 3 partitions, first FAT, second ext2 /boot, third for rootfs will also work.
Right. what we usually did though is the patch the bootloader to load the SPL from extX, if possible, so that we can avoid the FAT partition.
On the raspi, there is no way around the FAT partition, since the chip loads its bootloader ("bootcode.bin") from it. This bootcode.bin reads a file "config.txt" from the FAT partition and applies settings in there. Additionally, the contents of "cmdline.txt" are used for the kernel command line. One of these settings is kernel=foo.xxx which decides which "kernel" to load. Normally, a "kernel.img" is loaded. But if we copy u-boot.bin to kernel.img (or change the config to kernel=u-boot.bin), then U-Boot is used. U-Boot needs a patch, because it needs to retrieve the "kernel cmdline" and later pass it on to the linux kernel.
Other than that I think there is a magic "use UEFI partition layout" flag in kiwi to create the extra fat partition..
I'll have to look into that.
* who creates boot.scr.img? It is you in the u-boot rpm build.
No, actually it is uboot-image-setup.in in openSUSE:Factory:ARM JeOS
Yes, that was the information I was missing. I'll do further experiments. I'm not even 100% sure I will go with U-Boot, since I had massive problems with its limited (function wise) drivers. It simply could not read one of my SD-Cards (a Transcend Class 10 16GB SDHC which works very well once linux is booted). I might use a linux kernel as "bootloader" and then kexec into the final kernel. This option would also allow me to use a very sophisticated script language for the boot configuration file :-) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org
participants (4)
-
Alexander Graf -
Dirk Müller -
Guillaume Gardet -
Stefan Seyfried