Reflash Pi Zero W factory rom?

[Thursten]

Hey guys!
So lately I've posted in one of the topics around here about my Pi Zero W not recognizing it's Wifi and Bluetooth devices, it so turns out there has been a problem at the Pi factory..
So apparently the Raspberry Pi's have some sort of super lowlevel rom/firmware, that gets flashed in the factory on some memory on the PCB..
Now there has been an error/mistake made at the factory as a batch of Pi Zero W's got the wrong rom flashed and so it "thinks" it has different hardware.

Now I have gotten a new one, but the old one still kind of works, can I reflash that firmware so the right hardware is detected? (Mind you, I'm not talking about the SD card image!!)

Here is the link to the article where it is kind of explained: Article on Pimoroni forums

Thanks in advance!
I hope the explanation is a bit clear.. As I don't know how to explain it in little text, please feel free to ask for more clarification! =)

Greets,
Thursten

[bensimmo]

There was an OTP write for a Camera problem back with the Zero/Zero"C"?

But that as much as I can remember (there is a sticky thread on that, Zero missing camera iirc).

Edit found,
Something like this viewtopic.php?t=160611

[W. H. Heydt]

So apparently the Raspberry Pi's have some sort of super lowlevel rom/firmware, that gets flashed in the factory on some memory on the PCB..

The SoC on a Pi has a minimal ROM that is not writable in any way (it's "programmed" by the masks used in manufacturing the chips). There is a very small amount of One Time Programming (OTP) space. A matter of perhaps as much as 8 bytes. This does not contain any instructions to run. It contains the board serial number (32 bit random number) and some flags that control certain behaviors. Note that any given bit can only be change ONE TIME, and that from a zero to a one, there is no going back. Other than that, the only "firmware" used on any PI is loaded from the SD card (or other boot media).

[Thursten]

So apparently the Raspberry Pi's have some sort of super lowlevel rom/firmware, that gets flashed in the factory on some memory on the PCB..

The SoC on a Pi has a minimal ROM that is not writable in any way (it's "programmed" by the masks used in manufacturing the chips). There is a very small amount of One Time Programming (OTP) space. A matter of perhaps as much as 8 bytes. This does not contain any instructions to run. It contains the board serial number (32 bit random number) and some flags that control certain behaviors. Note that any given bit can only be change ONE TIME, and that from a zero to a one, there is no going back. Other than that, the only "firmware" used on any PI is loaded from the SD card (or other boot media).

Yeah, so the thing is, that during the programming by the manufacturer there has been made a mistake, where in the board is recognized and "identifies" as a Pi model from 2012..
Something went wrong with programming the model and revision version..

If you would check the link I posted in my OP you'll see what I mean.. Now I've got a replacement since they are familiar with the mistake, I'm about to fire the new one up, but I didn't have to send the old one back.. So since it's only a rom/firmware mistake, and it does work, I was hoping to be able to reflash it and make it fully functional!

Do you guys think it might help if I contact the Pi foundation or customer service for extra information? Or are they on these forums as well?

Edit I think I'm refering to the SoC minim rom thing you're talking about..

[drgeoff]

https://lb.raspberrypi.org/forums/viewt ... p?t=178362

[mfa298]

...So since it's only a rom/firmware mistake, and it does work, I was hoping to be able to reflash it and make it fully functional!

The clue is in the name(s)
ROM - Read Only Memory (i.e. not write-able so you cant flash it)
OTP - One Time Programmable (i.e. can only be set once, in the case of the board revision that's set in the factory)

So if the issue is a bad board revision as the linked post suggests there's nothing you can do to change it permanently (there's a suggestion of a parameter you can set in config.txt but the person reporting the issue said it didn't work for them)

[W. H. Heydt]

...So since it's only a rom/firmware mistake, and it does work, I was hoping to be able to reflash it and make it fully functional!

The clue is in the name(s)
ROM - Read Only Memory (i.e. not write-able so you cant flash it)
OTP - One Time Programmable (i.e. can only be set once, in the case of the board revision that's set in the factory)

So if the issue is a bad board revision as the linked post suggests there's nothing you can do to change it permanently (there's a suggestion of a parameter you can set in config.txt but the person reporting the issue said it didn't work for them)

And there is nothing the factory can do to fix it, either...short of replacing the SoC.

[jamesh]

...So since it's only a rom/firmware mistake, and it does work, I was hoping to be able to reflash it and make it fully functional!

The clue is in the name(s)
ROM - Read Only Memory (i.e. not write-able so you cant flash it)
OTP - One Time Programmable (i.e. can only be set once, in the case of the board revision that's set in the factory)

So if the issue is a bad board revision as the linked post suggests there's nothing you can do to change it permanently (there's a suggestion of a parameter you can set in config.txt but the person reporting the issue said it didn't work for them)

And there is nothing the factory can do to fix it, either...short of replacing the SoC.

Which is why the OP was sent a new board.....

[mikerr]

If it has the wrong revision, and so loading the wrong dtb,
would renaming the dtb file on SD work?
(Obviously just as an awful hack to get a working unit)

[bensimmo]

It's a almost fully working Zero board though, just minus the BT/W .. (anything else, LEDs indicators, the extra gpio ?)

Would it need the 'overclock' setting to 1GHz too, if it's seeing it as a B v2 which defualts to 700MHz?

Of course, no harm in asking to find if he could or couldn't.

[Thursten]

Hmm.. That is kinda sad, that for a mistake at the factory, so many faulty boards can just be trown away..
It has the default value, doesn't that mean it hasn't been programmed at all? Or has it been done wrong?

[mfa298]

Hmm.. That is kinda sad, that for a mistake at the factory, so many faulty boards can just be trown away..
It has the default value, doesn't that mean it hasn't been programmed at all? Or has it been done wrong?

If it's not been set at all then it might be possible for the factory to set the relevant bits (depending when in the process that part is done). But the cost of doing so is almost certainly prohibitive (it probably wasn't even worth the store asking for it to be returned to them which is why you still have it).

Not every board made will work perfectly, most of those should get picked up in QA testing but a few will get through. It sounds like you got one of those few (and the odd ones that get through usually mean something else gets added to the QA checks so it doesn't happen again).

[bensimmo]

An alternative to throwing away, buy one of these. It'll be an upgrade to the Zero version I have (mines only $5)

[davidcoton]

Hmm.. That is kinda sad, that for a mistake at the factory, so many faulty boards can just be trown away..
It has the default value, doesn't that mean it hasn't been programmed at all? Or has it been done wrong?

But we don't know how many boards were affected. Only a handful have been reported here. Even if they are unprogrammed and could be repaired, it would cost more to collect the boards, repair, and return then than simply to replace them.

So you get the challenge of trying to salvage a board that is otherwise scrap. Free bonus, if you succeed. I guess @mikerr's suggestion (take the right dtb file and rename it as the one the board will load) is the best option. Add @bensimmo's suggestion about settings that may need attention (but maybe not id the renaming trick works?). Then just enjoy getting somethin for (financially) notthing, though I'm sure the salvage effort is worth far more than the board costs ... which is why it was replaced without a return.

[jamesh]

Hmm.. That is kinda sad, that for a mistake at the factory, so many faulty boards can just be trown away..
It has the default value, doesn't that mean it hasn't been programmed at all? Or has it been done wrong?

But we don't know how many boards were affected. Only a handful have been reported here. Even if they are unprogrammed and could be repaired, it would cost more to collect the boards, repair, and return then than simply to replace them.

So you get the challenge of trying to salvage a board that is otherwise scrap. Free bonus, if you succeed. I guess @mikerr's suggestion (take the right dtb file and rename it as the one the board will load) is the best option. Add @bensimmo's suggestion about settings that may need attention (but maybe not id the renaming trick works?). Then just enjoy getting somethin for (financially) notthing, though I'm sure the salvage effort is worth far more than the board costs ... which is why it was replaced without a return.

This. AFAIK, it's only a very few boards. It has happened a couple of times, I'm not sure how, but Sony are responsible so it all gets reported back to them to fix whatever caused the problem.

[DavidS]

As it is the correct SoC with the correct board, it should be possible to still access the HW, you just need to recode drivers to do what they should regardless of what the board/firmware reports to the OS (which would take a bit of work, though should still be doable).

And if you have an application that does not need WiFi/BlueTooth then you have the board for it.

[W. H. Heydt]

Hmm.. That is kinda sad, that for a mistake at the factory, so many faulty boards can just be trown away..
It has the default value, doesn't that mean it hasn't been programmed at all? Or has it been done wrong?

But we don't know how many boards were affected. Only a handful have been reported here. Even if they are unprogrammed and could be repaired, it would cost more to collect the boards, repair, and return then than simply to replace them.

So you get the challenge of trying to salvage a board that is otherwise scrap. Free bonus, if you succeed. I guess @mikerr's suggestion (take the right dtb file and rename it as the one the board will load) is the best option. Add @bensimmo's suggestion about settings that may need attention (but maybe not id the renaming trick works?). Then just enjoy getting somethin for (financially) notthing, though I'm sure the salvage effort is worth far more than the board costs ... which is why it was replaced without a return.

This. AFAIK, it's only a very few boards. It has happened a couple of times, I'm not sure how, but Sony are responsible so it all gets reported back to them to fix whatever caused the problem.

One would surmise that someone in the factory made a setup error and anything up to when the error was caught, to a whole batch run were wrong.

[W. H. Heydt]

As it is the correct SoC with the correct board, it should be possible to still access the HW, you just need to recode drivers to do what they should regardless of what the board/firmware reports to the OS (which would take a bit of work, though should still be doable).

And if you have an application that does not need WiFi/BlueTooth then you have the board for it.

One wonders if setting some dtoverlay values might do the trick...

[jamesh]

But we don't know how many boards were affected. Only a handful have been reported here. Even if they are unprogrammed and could be repaired, it would cost more to collect the boards, repair, and return then than simply to replace them.

So you get the challenge of trying to salvage a board that is otherwise scrap. Free bonus, if you succeed. I guess @mikerr's suggestion (take the right dtb file and rename it as the one the board will load) is the best option. Add @bensimmo's suggestion about settings that may need attention (but maybe not id the renaming trick works?). Then just enjoy getting somethin for (financially) notthing, though I'm sure the salvage effort is worth far more than the board costs ... which is why it was replaced without a return.

This. AFAIK, it's only a very few boards. It has happened a couple of times, I'm not sure how, but Sony are responsible so it all gets reported back to them to fix whatever caused the problem.

One would surmise that someone in the factory made a setup error and anything up to when the error was caught, to a whole batch run were wrong.

I don't know what the specific issue was/is. As I said, we feed back any production issues to Sony, and they fix them!