[U-Boot] Two U-Boot versions on same device

[U-Boot] Two U-Boot versions on same device

[Rishi Dhupar]

Strange question but I am using an OMAP 3530 and the boot process currently
is from TI's X-Loader to U-Boot to Linux.

What I want is to have two different versions of U-Boot, an extremely
optimized and small one (to reduce boot time) but then also a debug version
that has a built in device test suite and allows updating of the Linux
kernel.

The optimized version would boot first and then check if a GPIO is set, if
so then it would boot into the debug U-Boot to perform tests or software
updates.

Anyone do anything like this or is it even possible?

Thanks.

[U-Boot] Two U-Boot versions on same device

[Matthias Kaehlcke]

El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:

> Strange question but I am using an OMAP 3530 and the boot process currently
> is from TI's X-Loader to U-Boot to Linux.
> 
> What I want is to have two different versions of U-Boot, an extremely
> optimized and small one (to reduce boot time) but then also a debug version
> that has a built in device test suite and allows updating of the Linux
> kernel.
> 
> The optimized version would boot first and then check if a GPIO is set, if
> so then it would boot into the debug U-Boot to perform tests or software
> updates.
> 
> Anyone do anything like this or is it even possible?

i think it should be possible, but i wonder if you really need
this. do you have hard data that suggest that the test suite or
allowing to update the linux slows down U-Boot significantly?

in my environment i use scripts stored in environment variables to
update the kernel and the rootfs, afaik this doesn't add any overhead
at all.
the test suite you mentioned might be a different issue depending on
its size, as it has to be copied from flash to RAM at boot time. if
it's just adds a few kB i think it shouldn't be relevant, especially
on your high-profile system

best regards

-- 
Matthias Kaehlcke
Embedded Linux Developer
Barcelona

      There is no passion to be found playing small - in settling
    for a life that is less than the one you are capable of living
                       (Nelson Mandela)
                                                                 .''`.
    using free software / Debian GNU/Linux | http://debian.org  : :'  :
                                                                `. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-

[U-Boot] Two U-Boot versions on same device

[Rishi Dhupar]

The size differences are substantial.  170 K for the regular uboot binary
and about 1.1 MB for the uboot binary with diagnostic software.

On Fri, Mar 5, 2010 at 7:31 AM, Matthias Kaehlcke <matthias@kaehlcke.net>wrote:

> El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:
>
> > Strange question but I am using an OMAP 3530 and the boot process
> currently
> > is from TI's X-Loader to U-Boot to Linux.
> >
> > What I want is to have two different versions of U-Boot, an extremely
> > optimized and small one (to reduce boot time) but then also a debug
> version
> > that has a built in device test suite and allows updating of the Linux
> > kernel.
> >
> > The optimized version would boot first and then check if a GPIO is set,
> if
> > so then it would boot into the debug U-Boot to perform tests or software
> > updates.
> >
> > Anyone do anything like this or is it even possible?
>
> i think it should be possible, but i wonder if you really need
> this. do you have hard data that suggest that the test suite or
> allowing to update the linux slows down U-Boot significantly?
>
> in my environment i use scripts stored in environment variables to
> update the kernel and the rootfs, afaik this doesn't add any overhead
> at all.
> the test suite you mentioned might be a different issue depending on
> its size, as it has to be copied from flash to RAM at boot time. if
> it's just adds a few kB i think it shouldn't be relevant, especially
> on your high-profile system
>
> best regards
>
> --
> Matthias Kaehlcke
> Embedded Linux Developer
> Barcelona
>
>      There is no passion to be found playing small - in settling
>    for a life that is less than the one you are capable of living
>                       (Nelson Mandela)
>                                                                 .''`.
>    using free software / Debian GNU/Linux | http://debian.org  : :'  :
>                                                                `. `'`
> gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4                  `-
>

[U-Boot] Two U-Boot versions on same device

[Nishanth Menon]

On Fri, Mar 5, 2010 at 1:14 PM, Rishi Dhupar <rishid@gmail.com> wrote:
> The size differences are substantial. ?170 K for the regular uboot binary
> and about 1.1 MB for the uboot binary with diagnostic software.
>
> On Fri, Mar 5, 2010 at 7:31 AM, Matthias Kaehlcke <matthias@kaehlcke.net>wrote:
>
>> El Fri, Mar 05, 2010 at 07:09:11AM -0500 Rishi Dhupar ha dit:
>>
>> > Strange question but I am using an OMAP 3530 and the boot process
>> currently
>> > is from TI's X-Loader to U-Boot to Linux.
two options:
a) something called configuration header - which will allow you to
boot from NAND kind of devices straight to SDRAM.
b) try barebox.. I used to have something as small as 32k when it was
called u-boot-v2..
Regards,
Nishanth Menon

[U-Boot] Two U-Boot versions on same device

[Ian Jeffray]

On 05/03/2010 12:09, Rishi Dhupar wrote:
> Strange question but I am using an OMAP 3530 and the boot process currently
> is from TI's X-Loader to U-Boot to Linux.
>
> What I want is to have two different versions of U-Boot, an extremely
> optimized and small one (to reduce boot time) but then also a debug version
> that has a built in device test suite and allows updating of the Linux
> kernel.
>
> The optimized version would boot first and then check if a GPIO is set, if
> so then it would boot into the debug U-Boot to perform tests or software
> updates.
>
> Anyone do anything like this or is it even possible?

Certainly possible.  Fairly trivial.  Just put two builds in your flash
and ramload the larger one when required - just like when testing a new
version of U-Boot before committing to flash.

But is it really worth the hassle?  Is the network code really that
large, or startup time really significantly longer in your 'debug'
version?


I.