headless start.elf ?

[dp111]

With RPi often in headless environments could there but a cut down version that is smaller that start_cd.elf ? This would reduce boot time.

[Ferroin]

Some minimal degree of GPU initialization is required, as the GPU controls the L2 cache and a handful of other components that the Pi won't function without. While I can't be 100% certain, I'd be willing to bet that the framebuffer setup is probably the only thing that could reasonably be cut from start_cd.elf, and I'm not certain that that's all that good of an idea since it then requires you to use a serial console to do anything locally.

[dp111]

For many IOT/embedded applications a screen wouldn't be present so headless version would be fine. I would expect start.elf to be considerable smaller and so quicker.

[Ferroin]

Like I said though, assuming I understand the code correctly, about 90% of what it does even in start_cd.elf is stuff that is required. You need very special handling to run the SoC with no L2 cache (Linux has code for this if you're interested), and there are a handful of other components that the GPU regulates which need to be set up for things to actually work right. Cutting out the framebuffer setup would almost certainly reduce the size, but I would be willing to bet that it doesn't help much.

[Ruffio]

@dp111 what kind of boot time are you looking for? I can't see which RPi you are using but on RPi3 you can get pretty low if you disable things you are not going to use. WiFi? Bluetooth? Serial? Disable writting boot messages to screen. Disable swap. Nofix og disk etc. You have alot of options to optimize the boot time with respect to your needs. Search, there are alot of guides around. Consider closing this request...

[Ruffio]

@dp111 what you say?

[dp111]

My application is bare metal so linux fiddling doesn't help. Ideally I'd like bootcode and start.elf to be under 0.5second. Currently in my tests it is over 1.2seconds and has got worse over the last 6 months.

…

On 22 January 2017 at 19:46, Rasmus Christiansen ***@***.***> wrote: @dp111 <https://github.com/dp111> what you say? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AStSojFciD_IzZysWWkbw_6TMv1wdm5pks5rU7IxgaJpZM4LTXoN> .

[JamesH65]

@dp111 It seems unlikely we would have the resources to spend time on this - is it still something you are interested in?

[dp111]

@james I fully understand about resource. I'm still interested in quicker booting. I wonder if it would be possible to have flags in config.txt that can turn off features which are known to take time during boot ?

…

On 21 December 2017 at 15:59, James Hughes ***@***.***> wrote: @dp111 <https://github.com/dp111> It seems unlikely we would have the resources to spend time on this - is it still something you are interested in? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#702 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AStSooHjf_7OYasK4B4L8tlxC6VnRVcEks5tCoBOgaJpZM4LTXoN> .

[BigEd]

Examples of subsystems which might not be needed:

• USB
• Ethernet
• Wifi
• TCP/IP
• video out
• camera

It would be interesting just to know how much time each takes, but disabling the ones which are not needed and are time-consuming would be ideal.

In the PiTubeDirect project, we need only GPIO, and we run our own GPU code.
https://github.com/hoglet67/PiTubeDirect/wiki

In RGBtoHDMI we need GPIO and video.
https://github.com/hoglet67/RGBtoHDMI

[ghollingworth]

What time-scales are you talking about here? If you're running your own GPU code then there is no execution beyond bootcode.bin which doesn't start up any of the things you suggest above. It's only job is to load up the GPU code and execute it...

[BigEd]

We are booting normally with a stock bootcode.bin, and our ARM kernel loads up and runs a replacement GPU task. We're talking about the first few hundred milliseconds, from power-on to the point that the ARM code has control of the GPIOs.