[U-Boot] U-Boot as a next bootloader in a chain - reading the kernel boot args provided by the previous stage bootlader?
Hi,
I need to use U-Boot (or barebox) as a bootloader in a Raspberry Pi based system to extend booting flexibility. The problem however is that certain kernel boot arguments are prepared by the previous stage bootloader (start.elf) basing on the properties of the individual board. For example in one of the boards I use, the kernel command line when a standard kernel is booted, looks as follows (MAC address and serial number are partially masked for privacy):
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xd bcm2708.serial=0x6f15XXXX smsc95xx.macaddr=B8:27:EB:XX:XX:XX bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
Only the "console=ttyAMA0 root=/dev/mmcblk0p2 rootwait" is provided by the user (in the cmdline.txt file). The rest is generated by the start.elf.
Of course when I boot the u-boot.bin instead of zImage, the same parameters are passed to it, but the U-Boot is not able to read them and to pass them to the finally booted kernel. As U-Boot shares a lot of code with the Linux kernel it should be possible to add necessary functions. It could be useful in all applications where U-Boot is used as an additional stage in the boot chain e.g., to add new booting functionalities (booting from the network, booting from the flash disk etc.).
I have found a nice description, how the paremeters are passed in ARM architecture: http://www.simtec.co.uk/products/SWLINUX/files/booting%5Farticle.html but of course the solution should be probably portable (or implemented for each platform independently with unified API).
-- Regards, Wojtek
Wojciech M. Zabołotny My GPG/PGP keys: standard: 8192R/FE58A848 (0720 9430 85DB 7CCD F4C5 5F1E 5107 91FB FE58 A848) confidential: 16384R/C76D2FB0 (C4E7 9597 CF22 7B5D 28BF 4656 FED7 A63F C76D 2FB0)
Hello Wojciech,
On Mon, 16 Nov 2015 10:42:50 +0100, Wojciech Zabolotny wzab01@gmail.com wrote:
Hi,
I need to use U-Boot (or barebox) as a bootloader in a Raspberry Pi based system to extend booting flexibility. The problem however is that certain kernel boot arguments are prepared by the previous stage bootloader (start.elf) basing on the properties of the individual board. For example in one of the boards I use, the kernel command line when a standard kernel is booted, looks as follows (MAC address and serial number are partially masked for privacy):
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xd bcm2708.serial=0x6f15XXXX smsc95xx.macaddr=B8:27:EB:XX:XX:XX bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
Only the "console=ttyAMA0 root=/dev/mmcblk0p2 rootwait" is provided by the user (in the cmdline.txt file). The rest is generated by the start.elf.
Of course when I boot the u-boot.bin instead of zImage, the same parameters are passed to it, but the U-Boot is not able to read them and to pass them to the finally booted kernel. As U-Boot shares a lot of code with the Linux kernel it should be possible to add necessary functions. It could be useful in all applications where U-Boot is used as an additional stage in the boot chain e.g., to add new booting functionalities (booting from the network, booting from the flash disk etc.).
I have found a nice description, how the paremeters are passed in ARM architecture: http://www.simtec.co.uk/products/SWLINUX/files/booting%5Farticle.html but of course the solution should be probably portable (or implemented for each platform independently with unified API).
Not sure what kind of answer you're asking for here. Do you want to know if what you're suggesting is feasible? Are you looking for someone to implement it? Are you going to implement it yourself but asking for feedback?
--
(aside: if the above should be a signature delimiter, then it lacks a space after the dashes)
Amicalement,
2015-11-16 11:52 GMT+01:00 Albert ARIBAUD albert.u.boot@aribaud.net:
Hello Wojciech,
On Mon, 16 Nov 2015 10:42:50 +0100, Wojciech Zabolotny wzab01@gmail.com wrote:
Hi,
I need to use U-Boot (or barebox) as a bootloader in a Raspberry Pi based system to extend booting flexibility. The problem however is that certain kernel boot arguments are prepared by the previous stage bootloader (start.elf) basing on the properties of the individual board. For example in one of the boards I use, the kernel command line when a standard kernel is booted, looks as follows (MAC address and serial number are partially masked for privacy):
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xd bcm2708.serial=0x6f15XXXX smsc95xx.macaddr=B8:27:EB:XX:XX:XX bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
Only the "console=ttyAMA0 root=/dev/mmcblk0p2 rootwait" is provided by the user (in the cmdline.txt file). The rest is generated by the start.elf.
Of course when I boot the u-boot.bin instead of zImage, the same parameters are passed to it, but the U-Boot is not able to read them and to pass them to the finally booted kernel. As U-Boot shares a lot of code with the Linux kernel it should be possible to add necessary functions. It could be useful in all applications where U-Boot is used as an additional stage in the boot chain e.g., to add new booting functionalities (booting from the network, booting from the flash disk etc.).
I have found a nice description, how the paremeters are passed in ARM architecture: http://www.simtec.co.uk/products/SWLINUX/files/booting%5Farticle.html but of course the solution should be probably portable (or implemented for each platform independently with unified API).
Not sure what kind of answer you're asking for here. Do you want to know if what you're suggesting is feasible? Are you looking for someone to implement it? Are you going to implement it yourself but asking for feedback?
--
(aside: if the above should be a signature delimiter, then it lacks a space after the dashes)
Amicalement,
Albert.
Dear Albert,
Yes the first question is if this feature is feasible.
If yes, then I'd like to propose such functionality as a possible improvement. I think that may be more people interested in such a feature.
I'll appreciate any sugestions/pointers regarding the possible implementation.
Probably I can try to implement it. Of course if there are other interested users who can do it, I'll be definitely happy to discuss that with them.
Regards,
Hello Wojciech,
On Mon, 16 Nov 2015 13:09:43 +0100, Wojciech Zabolotny wzab01@gmail.com wrote:
2015-11-16 11:52 GMT+01:00 Albert ARIBAUD albert.u.boot@aribaud.net:
Hello Wojciech,
On Mon, 16 Nov 2015 10:42:50 +0100, Wojciech Zabolotny wzab01@gmail.com wrote:
Hi,
I need to use U-Boot (or barebox) as a bootloader in a Raspberry Pi based system to extend booting flexibility. The problem however is that certain kernel boot arguments are prepared by the previous stage bootloader (start.elf) basing on the properties of the individual board. For example in one of the boards I use, the kernel command line when a standard kernel is booted, looks as follows (MAC address and serial number are partially masked for privacy):
dma.dmachans=0x7f35 bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708.boardrev=0xd bcm2708.serial=0x6f15XXXX smsc95xx.macaddr=B8:27:EB:XX:XX:XX bcm2708_fb.fbswap=1 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0 root=/dev/mmcblk0p2 rootwait
Only the "console=ttyAMA0 root=/dev/mmcblk0p2 rootwait" is provided by the user (in the cmdline.txt file). The rest is generated by the start.elf.
Of course when I boot the u-boot.bin instead of zImage, the same parameters are passed to it, but the U-Boot is not able to read them and to pass them to the finally booted kernel. As U-Boot shares a lot of code with the Linux kernel it should be possible to add necessary functions. It could be useful in all applications where U-Boot is used as an additional stage in the boot chain e.g., to add new booting functionalities (booting from the network, booting from the flash disk etc.).
I have found a nice description, how the paremeters are passed in ARM architecture: http://www.simtec.co.uk/products/SWLINUX/files/booting%5Farticle.html but of course the solution should be probably portable (or implemented for each platform independently with unified API).
Not sure what kind of answer you're asking for here. Do you want to know if what you're suggesting is feasible? Are you looking for someone to implement it? Are you going to implement it yourself but asking for feedback?
--
(aside: if the above should be a signature delimiter, then it lacks a space after the dashes)
Amicalement,
Albert.
Dear Albert,
Yes the first question is if this feature is feasible.
In software, just about anything is feasible; ask any PHB. :)
Specifically, catching information passed to U-Boot's entry point is something that e.g. OMAPs do already. It is probably not going to be portable, though, because the passing method is inherently specific to your platform and pre-U-Boot loader.
If yes, then I'd like to propose such functionality as a possible improvement. I think that may be more people interested in such a feature.
I'll appreciate any sugestions/pointers regarding the possible implementation.
Probably I can try to implement it. Of course if there are other interested users who can do it, I'll be definitely happy to discuss that with them.
Best is that you post a patch with a working implementation which can be build above current u-boot/master branch; people interested in it will comment.
Regards,
Amicalement,
participants (2)
-
Albert ARIBAUD -
Wojciech Zabolotny