Dediprog SPI flashing yields an unbootable system for every version except 5.2 which came with it
I bought a UP Squared board, which came with BIOS 5.2.
When I follow the instructions on using a Dediprog SF600Plus (rather than SF100) + a chip clip (rather than custom cable) + Dediprog's own SPI flashing software, I was able to successfully dump the v5.2 BIOS as a 16MB backup file. However, when I attempt to write BIOS v1.8 or or v3.3 (thanks for that @camillus) or v4.0 to the flash chip, the SPI programmer says everything verifies (meaning it read back the content and confirmed it was the same as the file I wanted written), but the UP Squared didn't boot (as evidenced by no HDMI output.)
When I use the same setup to write the v5.2 backup SPI dump back to the board, it once again boots fine and shows HDMI output. Unfortunately I didn't realize I needed a custom serial cable connection so I didn't get one, and I don't particularly want to pay $30+ for shipping a single cable, so I can't really debug where, if anywhere, boot is failing.
Any thoughts on why writing files like UPA1AM40.bin to the device fails to boot, but writing my backup back to it boots fine?
As an alternative I had tried using the GO.nsh approach by booting v5.2 into a UEFI shell and then running GO.nsh. There was one warning
"Not all of the file data will be written to flash because the file is longer than the flash area to be written to:
File: "UPA1AM40.BIN"
File Length: 16777216
Write Length: 16773120"
However, everything seemed to succeed after that based on the output messages. However when it was done, it would not boot. I dumped the flash with the Dediprog, and found that the shell method had correctly laid down exactly what was in the file and there were no diffs.
So it's largely the same question: is there any reason why I shouldn't be able to put 4.0 onto a system that already has 5.2 on it? Is there some anti-downgrade protection in place? Or is there maybe some super long-running initialization I need to wait for after reflashing a device?
Comments
-
Hi @r0h ,
I have tried now with an UP Squared device that had BIOS 4.4, I have updated the BIOS to 5.2 using an SF-100 programmer, then I also downgraded to BIOS 3.3 using the same SF-Programmer as well. Here is what I suggest, before flashing the BIOS, take off the CMOS battery for a few seconds, insert it and then flash the BIOS.
-
I tried that and it didn't work when I tried to write UPA1AM33.bin to the board.
Out of curiosity, I went ahead and wrote UPA1AM52.bin to the SPI flash with the Dediprog, and that worked fine. I also wrote UPA1AM61.bin and that worked fine. So it's just going backwards from 5.2 which is causing issues. The fact that you first went forward before going backwards makes me tend to suspect that the issue fundamentally comes down to which board revision someone has. Specifically I suspect it comes down to a flash part revision. I have a new board just bought in the last month, but presumably you have an older board?
I noticed in the old UPA1AM40 update files, they used to have a fparts.txt which described flash parts. The part on my board is a W25Q128JW. But when I run the GO.nsh based update, it identifies the part as a W25Q128FW, and according to fparts.txt that's supposedly a 8MB part:
W25Q128FW,0xEF6018, 0x8000000, 0x1000, 0x20, 64, 0
Now the Dediprog agrees that the W25Q128JW and W25Q128FW have the same ID = 0xEF6018, so it asks the human to select which one it is. But I seem to remember there being something about SPI flash parts being baked into the Intel SPI Flash Descriptor, so is it possible that the older firmware are just incapable of running on the W25Q128JW? @camillus What SPI flash part is on your board?
(The only problem with my hypothesis is that UPA1AM40.bin is a 16MB file rather than an 8MB one, so that sort of implies it's expected to work on this 16MB chip, although that could just be because there were other, different models of 16MB chips listed in the fparts.txt for older updates too... The other possibility is that it has to do with CPU stepping, because I saw in the UP news that the CPU revision was changed for the Intel atom too at some point. But I don't know how to check that, or how it would cause this problem.)
Also, can you send me the UPA1AM44.bin so I can see if that behaves differently than the UPA1AM40 for me?
-
@camillus a friendly request to LMK on the previous question
-
@camillus if you work for AAEON, can you try that on a new UP^2 board created in the last 2-3 months? Based on conversations with other people who've got old boards vs. new boards, it seems like it's specifically the new boards which are having trouble with downgrades, and I suspect you have an old board. Thank you
-
Hi @r0h ,
Yes I tried on older revisions, I will verify on a newer one like you suggested and let you know. Is there a reason you wish to use older BIOS?
-
@r0h said:
@camillus if you work for AAEON, can you try that on a new UP^2 board created in the last 2-3 months? Based on conversations with other people who've got old boards vs. new boards, it seems like it's specifically the new boards which are having trouble with downgrades, and I suspect you have an old board. Thank you
Hi @r0h ,
I can reproduce this issue on a new board and will verify from BIOS team about it.
