Rpi4 - Current Bullseye build. It's contain components and service to maintain update firmware (bootloader and vl805 side) of raspberry?

The question it’s on title… it’s a simply a my general question… try to explain what have I discovered in this period :slight_smile: :

For update bootloader and VL805 side it’s need to be use “rpi-eeprom-update”.
Searching on google it’s very easy to found how i need to do (also on official raspberry documentation). “sudo rpi-eeprom-update -a -d” and “sudo reboot” when it’s finished.

Recently i have discovered one things… in /var/lib/ can be available a service. “rpi-eeprom-update.service” that need to maintain updated both componet in background whitout ask nothings to the user.

This .service don’t need to be triggered by “apt update/upgrade” procedure it should be on by default so this both component it’s be maintain upgradable to last recent commit.

Currently i use OSMC Daily on my Rpi2… i look inside and for example here this component it’s not available. Also from SSH “rpi-eeprom-update” it’s exited somethigs like “command not found”.
On Rpi4 build it’s included ?

No - because you shouldn’t need to update it frequently.

Lol ok… you want to know because i made this specific question ?
I have discovered sometime on my Rpi4 i’m using Retropie… retropie it’s contain this service but OS it’s based on a Legacy Raspberry Pi OS Buster.
That OS it’s not anymore maintained about this side :slight_smile: And my raspberry pi4… over this side it’s remain “stuck” at a firmware whit about two years ago :slight_smile:

I have a second SD whit OSMC… if it’s contain this package i can try to boot that and try to upgrade by that :slight_smile:

I’m still unsure of why you want / need to upgrade it.

Bootloader is covered by OSMC.

My understanding is that there isn’t a need to really maintain EEPROM updates.
I’m also not keen on updating parts of a device that persist beyond the OS.

There were some USB fixes shortly after release that were significant re. power consumption and heat.

If a user installs OSMC, we issue an update and they’re not keen on OSMC, they can get rid of it completely. They are also aware of the changes we made and they’re isolated to OSMC and the media that that they installed it on.

I don’t want to change more persistent parts of their board. This will lead to confusion.

If i understand correctly how does it work it’s the rpi-eeprom-update can provide the update for bootloader and VL805 size and it’s follow the source from Raspberry PiOS Bullseye and also from GitHub here:
https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware

So if the current OSMC build it’s contain this service in theory, the two components, it’s be updated in background and automatically whitout ask to user :slight_smile:

This my it’s a generic request… anyway i know this two update they cannot be considered “safe” because it’s exist a little risk this update can fail and, for example if bootlader flash it’s fail you can obtain a brick raspberry (in theory if you fail to update the VL805 usb it’s not work anymore but you can try to reflash and reboot your pi).

anyway, this is a more than generic request :slight_smile: I’m also somehow trying to figure out how it all works exactly… i have some info but i don’t have idea if it’s correct :slight_smile:

We don’t want to do that and I’m still not sure why you need to update this.

I’m trying to figure out why some distros do this and, probably i have find out they should but then it fails somehow (like retropie for made an example).

in fact i ask if osmc contain this feature and not how i can update… i know how i can update if i want :wink:

We do not.

I made that clear last week.

my exact request is also clear i think and i hope… otherwise I would have requested something like ‘how i can update’ :wink:

@sam_nazarko if effects… comes to mind i can made the same thread request in other section of forum like “General Discussion” :slight_smile:
Infact it’s not really a support request… but a more specific request about a feature :slight_smile:

Ops…