[U-Boot] U-Boot as a next bootloader in a chain - reading the kernel boot args provided by the previous stage bootlader?

[Wael Almattar]

Hi,

How do you suggest to implement such functionality? Do you want to
make u-boot able to modify kernel args which has been sent by
start.elf? or you want during u-boot stage to press a hotkey which
give you the opportunity to edit previous bootargs?

Please explain how do you expect u-boot to behave after implementing
this patch..

Best Regards,

Wael Almattar

Hello Wojciech,

On Mon, 16 Nov 2015 13:09:43 +0100, Wojciech Zabolotny
<wzab01 at gmail.com <http://lists.denx.de/mailman/listinfo/u-boot>> wrote:
>* 2015-11-16 11:52 GMT+01:00 Albert ARIBAUD <albert.u.boot at aribaud.net <http://lists.denx.de/mailman/listinfo/u-boot>>:
*>* > Hello Wojciech,
*>* >
*>* > On Mon, 16 Nov 2015 10:42:50 +0100, Wojciech Zabolotny
*>* > <wzab01 at gmail.com
<http://lists.denx.de/mailman/listinfo/u-boot>> 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
<http://www.simtec.co.uk/products/SWLINUX/files/booting_article.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,
-- 
Albert.