start.elf and rpi-update or apt-get upgrade

[WanaGo]

Hello,

Question.

We have a customised start.elf file, and want to be able to do rpi-updates or apt-get upgrades to get normal system upgrades for Raspbian, however when these commands are executed, the start.elf file on SD card get replaced, and our system no longer boots.

Replacing them with our custom file again resolves the issue, however I was just wanting to know why this file gets updated/replaced, or if there is a way to do an update of everything else but exclude this file from being replaced?

I appreciate any input anyone has

Kind Regards
WanaGo

[jamesh]

start.elf is the firmware that is loaded on to the GPU. It usually needs to match the ARM side code (in case a feature was added in ARM that needed firmware support).

So when you do an update of the ARM side using rpi-update it will also update the firmware. I think apt-get stuff will be safe though.

Note that the firmware is being improved all the time with bug fixes and new code.

Out of interest, what have you changed in the start.elf? You really shouldn't be touching it in normal usage (and you have seen why). The only thing I can think of is that you are removing the Raspi logo and replacing it with your own.

[ghans]

Isn't the Raspi Logo baked into kernel.img ?

ghans

[DougieLawson]

Isn't the Raspi Logo baked into kernel.img ?

ghans

It's built as part of the kernel from
../linux/drivers/video/logo/logo_linux_clut224.* by processing a 224 colour ppm image file.

[AndrewS]

I wonder if the OP has simply confused the filenames, and they actually have a customised kernel.img ?

In which case, they just need to have a look at https://github.com/Hexxeh/rpi-update#skip_kernel

Edit: Or they could rename their own customised kernel to custom-kernel.img, and then add a kernel=custom-kernel.img option to config.txt, and then it won't matter if apt-get overwrites the 'normal' kernel.img

[jamesh]

Isn't the Raspi Logo baked into kernel.img ?

ghans

Good point. Ignore my nonsense talk.

Still intrigued as to why he may have a modified start.elf

[WanaGo]

Thanks for the reply everyone.

Out of interest, what have you changed in the start.elf? You really shouldn't be touching it in normal usage (and you have seen why).

Well, its all a bit hush hush at the moment, however we are working with Broadcom on a custom product which will be released in the next few months. The start.elf has been customised due to our hardware setup and what we have connected to the BCM2835.

I guess I really need to go back to them and get more information and see if these customisations can be detached from start.elf and put somewhere else, so if the code does need to be updated then our customisations remain intact. Getting information from them is not a quick process though, which is why I turned here to see if anyone might know.

From the tests I did, both the apt-get upgrade and the rpi-update caused the start.elf file to be 'updated' / 'overwritten' for whatever reason.

No we are not changing the Raspberry Pi logo or anything as trivial as that. Without the modifications we have in place, our system simply does not start.

I wish I could say more.

What I don't know however is what the specific modifications are, all I know is what they provide us. I assume the source used in the start.elf file is protected and only privy to certain people/companies? or is it openly available, do you know? I need to do more research myself. I am sort of only the messenger in this particular issue.

Kind Regards
WanaGo

[WanaGo]

I wonder if the OP has simply confused the filenames, and they actually have a customised kernel.img ?

In which case, they just need to have a look at https://github.com/Hexxeh/rpi-update#skip_kernel

Edit: Or they could rename their own customised kernel to custom-kernel.img, and then add a kernel=custom-kernel.img option to config.txt, and then it won't matter if apt-get overwrites the 'normal' kernel.img

Thanks for this reply also

I had seen this, but didnt see anything specific to start.elf.
No, I havent mistaken what file has been modified, it is start.elf, not kernel.img
Can this same method however be applied to start.elf and we split out our changes as you described for kernel.img, or is that a bit of an unknown and is subject to what the changes are?

Regards
WanaGo

[AndrewS]

In that case you'll simply need to remember to copy your custom start.elf file back to the /boot folder every time after running 'apt-get upgrade' or 'rpi-update' before rebooting.

AFAIK you're possibly the only person running a RaspberryPi with a custom start.elf that hasn't come from https://github.com/raspberrypi/firmware

I assume the source used in the start.elf file is protected and only privy to certain people/companies?

Correct.

[WanaGo]

Yes, as I suspected.

I will talk to Broadcom and see what can be done about this.
If the solution is simply copying back the start.elf and overwriting the one which was updated, then that is a step which should be fine to do - however I guess my concern is, why was it updated in the first place. Surely it would only be updated if there was a change that needed to be implemented, to compliment any changes that were made on the ARM side, as was described above. So my simply copying the start.elf file we have back over top of the updated one, then we break that link, and thus the update.

I am not sure what the solution is for this. hmm.

I have not heard of many other companies who have done what we have been working on, which is a good thing in a way. But I suppose it also means we are in uncharted waters to an extent, so may have to result to work arounds rather than solutions. It has been a hard road to get to this point I can tell you that. Light is at the end of the tunnel though.

Regards
WanaGo

[AndrewS]

however I guess my concern is, why was it updated in the first place.

You can find that out by reading through the full history https://github.com/raspberrypi/firmware/commits/master

I suspect many of the changes will be to fix bugs or add new features, that probably won't affect your product?
But of course that's just my uninformed guess

OTOH, if your product is being released in a few months, are you really at the stage where you still need to be pulling in constant (and often untested) updates?

[WanaGo]

Pretty much if it runs on the Pi (Raspbian only), then it will run on ours.

If there are fixed or features added then ideally I would like us to be able to get them also. The aim was that our product used as many standard parts of Raspbian as possible so it was easy for people to update as required and dont have to muck around with custom kernels and the like.
Seems we are mostly there, its just this one file.

[Paul Webster]

Looks like a few alternatives here ...

- You might have to persuade Broadcom / RPi Foundation to incorporate the Broadcom changes for your device into the RPi start.elf ... assuming it can detect the difference between the devices at run time and handle it all properly. That makes extra work for BCM /RPi which they might want to charge for
- get rpi-update modified to handle alternate start.elf ... with the danger that a change is made elsewhere that requires a particular version of start.elf and it breaks things horribly
- persuade BCM to move the start.elf changes out to somewhere special and then have a way for start.elf to load external stuff and have that mechanism incorporated into the RPi start.elf

[jamesh]

Pretty much if it runs on the Pi (Raspbian only), then it will run on ours.

If there are fixed or features added then ideally I would like us to be able to get them also. The aim was that our product used as many standard parts of Raspbian as possible so it was easy for people to update as required and dont have to muck around with custom kernels and the like.
Seems we are mostly there, its just this one file.

Who are you dealing with at Broadcom? Because this is the first I've heard of it and I work for Broadcom and generally know all the Raspi stuff!

[Gert van Loo]

Who are you dealing with at Broadcom? Because this is the first I've heard of it and I work for Broadcom and generally know all the Raspi stuff!

Ditto, I am responsible for the hardware side and thus far believed I know all our customers.

[WanaGo]

Naren but dealing directly with EDOM.

[WanaGo]

Have sent you two PM's.