Jump to content
OGXbox.com

Problems with the Xenium programmer


herooftheday
 Share

Recommended Posts

  • 1 month later...

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.

Link to comment
Share on other sites

5 hours ago, lowtolerance said:

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.

That's happening to me... Are there any files you can share? I am trying to flash and failing at 52 to 54 percent verification every damn time...

Link to comment
Share on other sites

1 hour ago, dtomcat said:

Add this line after line 173 (from original xenium-flash.cpp in src folder) and recomplile

 

image.thumb.png.bd510227d8e14c2ee30c578d262b47f9.png

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.

Link to comment
Share on other sites

3 hours ago, Bowlsnapper said:

That's happening to me... Are there any files you can share? I am trying to flash and failing at 52 to 54 percent verification every damn time...

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.

Link to comment
Share on other sites

24 minutes ago, lowtolerance said:

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

Correct.  Essentially waits for flash to be ready to write again after each write. This solved the verify issues I was having.   But speed is my guess also 

Link to comment
Share on other sites

Bump: I tried programming another freshly built chip and the programmer started to fail verification immediately. No count at all. Instant failure. I restarted the programmer and all of a sudden I started getting a verification count before verification would fail at 50-60%. There's no way these chips have faults 2 in a roy. My forst 3 were fine. Something is wrong with this programmer, I'm sure of it. @dtomcat

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.