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 notifications@github.com 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 https://github.com/raspberrypi/firmware/issues/702#issuecomment-274354016, 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 notifications@github.com 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 https://github.com/raspberrypi/firmware/issues/702#issuecomment-353387265, 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.

[6by9]

Camera support is not built into the start_cd.elf. USB, Wifi, ethernet and TCP/IP are functions of the main OS, not the firmware. (Exception being network/USB booting on 2837 based products, but that is only done after having tried the SDcard which you have present).

Initialising video will probe for an HDMI display (aborts quickly if no hot-plug detect), and DSI panels over I2C. Add ignore_lcd=1 to config.txt to skip the probing of DSI panels if you don't want it. Other than that, setting up the display infrastructure is pretty light weight with a few register writes and memory allocations. You can also add force_eeprom_read=0 to ignore probing of HAT EEPROMs over I2C. (Both of those are a function of start*.elf, not bootcode.bin. You're shipping start_cd.elf, I'm not clear if you are actually running those based on your comments).

There's very little left after that other than loading stuff off SD card and setting up basic state.

[BigEd]

Thanks... but note that we do see we've lost 150ms on Pi Zero, and the Zero W boot times are much worse than the zero. So there's something going on.

See here for measurements and a bisection:

Finally, comparing with a Pi Zero and a Pi Zero W:

Pi Zero:

• 732/576ms - original firmware blob released with Diamondback
• 882/728ms - current firmware blob, as of 24/7/2018

Pi Zero W:

• 782/584ms - original firmware blob released with Diamondback
• 1030/787ms - current firmware blob, as of 24/7/2018

Conclusions:

• The firmware blob changes post Diamondback have slowed boot by ~150ms
• The Pi Zero W is slower to boot that the Pi Zero, by 50-150ms (depending on the firmware)

In the following comment you'll see that a bisection pins blame on addition of boot from USB mass storage:

4/1/2017 - raspberrypi/firmware@87edb82

• fastest boot time: 584ms

10/1/2017 - raspberrypi/firmware@e44f66a

• fastest boot time: 721ms

So the commit that is responsible for the slowdown is from 12/1/2017.

commit e44f66a9e4e41636634501a093f9a55ceefb46d6
Author: popcornmix <popcornmix@gmail.com>
Date:   Tue Jan 10 19:29:51 2017 +0000
    firmware: Add usb/net support from next branch

[6by9]

Your issue is diverging rapidly from the original issue raised.

• Do you use start_cd.elf? Your posts so far have been very ambiguous. Seeing as you appear to be making mailbox calls then you must be.
• Have you tried the earlier bootcode.bin with the later start_cd.elf, and vice versa? (AFAIK they should be compatible). Confirm whether it is the bootcode.bin or start_cd.elf change. We don't always divulge all the minor details in the commit text. You'll note that start_cd.elf also changed in that commit.
• Have you tried the suggestions above for disabling display and HAT probing? It may not be the chunk of time that you have lost, but reducing boot time is reducing boot time.
• Neither Pi0 nor Pi0W support net or USB booting from the bootrom, nor have the LAN9514 or LAN7500 to work from, therefore all the bootcode changes should be nops or very close.

Boot time is not a major concern for us, so I'm afraid you're going to have to do some of the legwork.

[BigEd]

Apologies, it's true that this issue is a request for smaller, in the hope that smaller will be faster.

We have found a commit which slows down booting significantly on the Zero. It might be surprising that this commit does that, but it does. Even better if it needn't do that.

I'll see what we can do with your other points.

[6by9]

Looking through the bootcode source, that merge was bringing in several months worth of work from ghollingworth, so not a trivial one liner. It has changed the order in which the SDRAM and some clocks are brought up, and there is a 100ms delay added to give time for the clocks to settle.

Not an area I'm going to investigate. @ghollingworth any recollections of specifics? Commit 0f71ba52 added it at 3s, then dropped to 100ms in cc6c5564.

[ghollingworth]

Yeah, it's possible there's a delay that could be removed, but not going to be able to look into it for quite some time. I do have an interested party who may look into it in a couple of months

[MichaIng]

Hey guys, the other reason to have either some start_headless.elf or some config.txt setting is power consumption. There was the setting hdmi_ignore_composite=1 that allowed to disable the whole video/framebuffer pipe from boot on, thus had a very similar/identical effect then running tvservice -o manually afterwards. But this setting got removed with RPi4 firmware support.

Really, I guess most RPis are running completely headless, most likely not even with any display close to attach when wanted. And currently there is a large bunch of video output and even camera related related features and kernel modules loaded which will never be used on these headless RPis.

Having a headless setting or start file that prevents any framebuffer init (so no /dev/fb0 spawn with RAM allocation), HDMI and SDTV completely ignored from very boot on, would be great.

I tried to disable /soc/fb via custom dtoverlay, but then another fallback framebuffer device is loaded on boot instead, so no benefit with this, or one needs to add it runtime-wise via dtoverlay command. But then one can use tvservice -o as well.

---

Also the current start_cd.elf could be probably improved. I recognised some error messages, especially about vcsm service failing. Why not disable this then? I currently have a custom dtoverlay:

/dts-v1/;
/plugin/;

/ {
        compatible = "brcm,bcm2835";

        fragment@0 {
                target-path = "/soc/vcsm";
                __overlay__ {
                        status = "disabled";
                };
        };
};

• Works great, no error messages on boot anymore with 16M gpu_mem/start_cd.

The RPi camera is not usable with 16M gpu_mem I guess (?). So why bcm2835_codec and bcm2835_v4l2 modules are loaded then, which pull a bunch of ~10 additional dependency modules. In the past those were only loaded automatically with start_x=1/start_x.elf, which is anyway required for the camera to work.