lowtolerance

It’s interesting that it’s failing consistently at a different percentage for you than it is for me. What model of Pi are you using? Try commenting out lines 188-216 of the xenium-flash.cpp file and uncommenting lines 220-226, then re-running install and re-running xenium-programmer. When it finishes you should have a file called “flash.bin” in the working directory and just run the “diff” command against that binary and whatever xeniumOS/prometheos binary you’re using. If it doesn’t report any differences, then there are no differences.

I had already stumbled across this thread and this recommendation while I was chasing down a solution to the problem. For me, adding that line of code did not make any difference in the end, as the verification still fails every time at the same percentage. If I’m understanding it correctly, this line of code states that we should wait until the last byte has actually been written to flash before proceeding with the next byte, so it’s essentially verifying the flash on the fly. It’s not a suitable replacement for the existing verification routine, though, as the xenium-flash program will just hang if there’s a legitimate issue and it will never get past the write routine. I’m working on debugging this problem but I suspect that the Pi Zero 2 W and other newer Pi’s are trying to move the process along faster than the flash can keep up. Koos added some code specifically to insert an additional delay for the BitBus clock on Pi 3B+, but he never tested it on anything but the Pi Zero and 3B+ (and the Onion Omega2 but that’s irrelevant). It may just be that the timing for the BitBus clock needs to be tweaked further for Xenium Programmer to work properly with other Pi models. I’ll update this thread once I know more.

I was running into this issue with Xenium Programmer running on a Pi 2 W where it would fail right at 50% every time. At first I thought it might have been a hardware issue with the modchip, but it was happening on all of the open xenium chips I tried. I wasn’t using the official PCB, just jumper wires, so I thought maybe there was a problem with the wiring. But why was it failing at 50% every time? I looked through the source looking for anything that might explain this behavior and noticed Koos left some commented out code for dumping the contents of flash, so I commented out the verification routine and uncommented the dump code, recompiled, re-ran the installer and xenium-programmer script and successfully dumped the contents of my modchip’s flash, which I then ran a diff against the prometheos BIOS image I had flashed. 100% identical binaries. So it seems like there is definitely a bug in xenium programmer causing flash verification to fail right at the halfway point.

Nice work! I’m partial to DX4M’s Xbox EEPROM Utility running on an esp8266 or esp32 dev board, which features a web UI that can be used to see and modify your EEPROM’s contents “live” and save a backup, but the Pico is so popular that it’s great to have a utility focused around it.

MakeMHz claims that it's not OK to use someone else's code, actually. But in reality, his code is heavily dependent on the work of others. There is a certain level of cognitive dissonance necessary to support MakeMHz and attack the people attempting to duplicate his efforts.

I’ve been playing around with Stellar web installer and it’s… interesting. Not surprisingly, it violates GPL, but getting MakeMHz to respect other programmers’ licensing is a lost cause, which is a big part of the reason why I won’t buy Stellar. Anyway, that’s beside the point. Normally, you need to have Stellar hooked up to your PC for the installer to do anything, but it’s trivial to override the JavaScript that checks for this and proceed to the part where the installer asks you to “upload” the 5838 BIOS image. The BIOS is then “unpacked” and the kernel decrypted, uncompressed and extracted, and that unmodified kernel is what gets flashed to Stellar, where it is presumably patched and assembled into a valid BIOS. It’s possible to add a few lines of JavaScript to save the kernel as a file instead of sending it directly over USB and see exactly what gets flashed to Stellar, but I’m hesitant to provide any such code given MakeMHz’s tendency to abuse DMCA claims. When it was first announced, the press release claimed that StellarOS uses a “reimplemented” kernel, but I fail to see where “reimplementation” comes into play. To me, this implies that MakeMHz built the functional equivalent of Microsoft’s kernel using none of the original code. Patching code into Microsoft’s kernel or utilizing any portion of Microsoft’s kernel code to build StellarOS disqualifies it as a reimplementation of the kernel, in my opinion. And I’m not a lawyer, but it doesn’t seem super legal on MakeMHz’s behalf, either, to claim and utilize Microsoft’s code as their own. The press release shames the shit out of other BIOS makers for using source code stolen from Microsoft to produce their BIOS, but using Microsoft’s binary code is fair game? It makes very little sense to me. It’s entirely possible that I’m missing something, so hopefully someone with more knowledge than me than can clarify.