Linux seamless booting

Linux seamless booting

[Fortini Matteo]

Hi all,
we've been working on a PPC512x board booting with u-boot + linux 
2.6.24.6, and one major issue for our application is boot time.

Right now, we went down to less than 6s boot time (i.e. time from power 
off to launch of the user app), even with some drivers installed, i.e.:

    * CAN bus
    * GPU on PCI bus
    * USB host
    * UBI

with r/o squashfs root and r/w ubifs configuration filesystem mounted 
from a NOR flash memory.

This time could be enough for the high-level application (we're showing 
a splash screen in about 2-3s so it's ok if the main app takes a little 
longer to come up), but the whole system is connected to others via CAN 
and we can't afford the "black out" period between u-boot and linux.

Some other operating systems (e.g. QNX) have this "seamless booting" 
function, in which drivers are started in stages, so that a (minimal) 
functionality can be given in milliseconds, and more functionalities 
come up as time goes by.

Is there a way to support something similar with the u-boot -> linux 
solution?

Thank you,
Matteo

Re: Linux seamless booting

[Roberto Guerra]

Did you try "setenv bootdelay 0" in uboot?

On Mon, Oct 12, 2009 at 7:07 AM, Fortini Matteo <matteo.fortini@mta.it> wro=
te:
> Hi all,
> we've been working on a PPC512x board booting with u-boot + linux 2.6.24.=
6,
> and one major issue for our application is boot time.
>
> Right now, we went down to less than 6s boot time (i.e. time from power o=
ff
> to launch of the user app), even with some drivers installed, i.e.:
>
> =A0 * CAN bus
> =A0 * GPU on PCI bus
> =A0 * USB host
> =A0 * UBI
>
> with r/o squashfs root and r/w ubifs configuration filesystem mounted fro=
m a
> NOR flash memory.
>
> This time could be enough for the high-level application (we're showing a
> splash screen in about 2-3s so it's ok if the main app takes a little lon=
ger
> to come up), but the whole system is connected to others via CAN and we
> can't afford the "black out" period between u-boot and linux.
>
> Some other operating systems (e.g. QNX) have this "seamless booting"
> function, in which drivers are started in stages, so that a (minimal)
> functionality can be given in milliseconds, and more functionalities come=
 up
> as time goes by.
>
> Is there a way to support something similar with the u-boot -> linux
> solution?
>
> Thank you,
> Matteo
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>

Re: Linux seamless booting

[Fortini Matteo]

Yes, that's what we're currently using, but the problem is a little 
broader: I should answer to CAN messages in at most 100-200ms from 
powerup, and that can be done in u-boot.
However, handing CAN transmission control over to Linux is quite 
complicated nowadays, since it would involve passing structures in 
memory and hacking through device init.
It'd be nice to have a framework with which u-boot could hand-over 
devices to Linux in a clean and defined way.
We were thinking about starting some kind of development in that 
direction, but with very little resources, so I was looking for someone 
who had looked at the same problem.

Thanks,
Matteo

Roberto Guerra ha scritto:
> Did you try "setenv bootdelay 0" in uboot?
>
> On Mon, Oct 12, 2009 at 7:07 AM, Fortini Matteo <matteo.fortini@mta.it> wrote:
>   
>> Hi all,
>> we've been working on a PPC512x board booting with u-boot + linux 2.6.24.6,
>> and one major issue for our application is boot time.
>>
>> Right now, we went down to less than 6s boot time (i.e. time from power off
>> to launch of the user app), even with some drivers installed, i.e.:
>>
>>   * CAN bus
>>   * GPU on PCI bus
>>   * USB host
>>   * UBI
>>
>> with r/o squashfs root and r/w ubifs configuration filesystem mounted from a
>> NOR flash memory.
>>
>> This time could be enough for the high-level application (we're showing a
>> splash screen in about 2-3s so it's ok if the main app takes a little longer
>> to come up), but the whole system is connected to others via CAN and we
>> can't afford the "black out" period between u-boot and linux.
>>
>> Some other operating systems (e.g. QNX) have this "seamless booting"
>> function, in which drivers are started in stages, so that a (minimal)
>> functionality can be given in milliseconds, and more functionalities come up
>> as time goes by.
>>
>> Is there a way to support something similar with the u-boot -> linux
>> solution?
>>
>> Thank you,
>> Matteo
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>>
>>     
> .
>
>   

Re: [U-Boot] Linux seamless booting

[Kenneth Johansson]

On Mon, 2009-10-12 at 15:54 +0200, Fortini Matteo wrote:
> Yes, that's what we're currently using, but the problem is a little 
> broader: I should answer to CAN messages in at most 100-200ms from 
> powerup, and that can be done in u-boot.

if you are in that interval you definitely need to go to a more exotic
start sequence than usual. 

one solution would be to do as you suggest and do a special driver that
is living outside of the kernel during startup. you still need to hack
into the interrupt code to let your "external" driver handle the CAN.
then you need to hack up the ordinary driver to take over from yours.

I have not seen this solution on any project I worked on but should be
doable. 

optimizing the boot time of linux so it starts up in 200ms is probably
going to be quite hard. I did 2 seconds to /sbin/init started from ide
driver without to much trouble. removing the IDE and going to a root on
NOR would probably get closer to 1.5 but to get down to 200ms would
probably mean removing most of u-boot and only keep the dram setup then
you probably need to remove most of the drivers from the kernel and load
them later as modules. I have never really tried to do a insane fast
boot like this so I'm not sure what problems you will run up against.
but maybe it's possible. but 200ms feels a bit to optimistic.


> However, handing CAN transmission control over to Linux is quite 
> complicated nowadays, since it would involve passing structures in 
> memory and hacking through device init.
> It'd be nice to have a framework with which u-boot could hand-over 
> devices to Linux in a clean and defined way.
not likely to happen as a generic solution. Much better to just remove
the boat loader then and work on optimizing the linux startup code.