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

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

[Wojciech Zabolotny]

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)

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

[Albert ARIBAUD]

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.

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

[Wojciech Zabolotny]

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,

-- 
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)

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

[Albert ARIBAUD]

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,
-- 
Albert.

[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@gmail.com <http://lists.denx.de/mailman/listinfo/u-boot>> wrote:
>* 2015-11-16 11:52 GMT+01:00 Albert ARIBAUD <albert.u.boot@aribaud.net <http://lists.denx.de/mailman/listinfo/u-boot>>:
*>* > Hello Wojciech,
*>* >
*>* > On Mon, 16 Nov 2015 10:42:50 +0100, Wojciech Zabolotny
*>* > <wzab01@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.