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,