Release tinyprog 1.0.24 on PyPI

[ewenmcneill]

Further to #25, another user has run into "invalid version string" issues as a result of there being no release version of 1.0.24 (https://discourse.tinyfpga.com/t/tinyprog-1-0-24-testing/886/2):

I noticed Atom now returns

Error: Invalid version string: ‘1.0.24.dev49’

Although tinyprog still attempts to load .bin through command prompt. I am working on a metadata issue with my BX.

@mithro, What else needs to be done before you're willing to release a non-development tinyprog 1.0.24 onto PyPI? (AFAICT @tinyfpga isn't doing releases any more, and the last non-development release was 1.0.21 for Python 3, and 1.0.23 for Python 2, both nearly a year old.)

It'd be nice to at least get a new non-development release up to PyPI before upstream Python stops supporting Python 2... :-)

[mithro]

If your happy it is working and won't brick people's devices then I can do a release today if you want.

[ewenmcneill]

If your happy it is working and won't brick people's devices then I can do a release today if you want.

The previous release versions have been known to brick people's devices -- hence the various issues/comments here, and on the TinyFPGA discourse forum.

I think the 1.0.24 development version is better than the earlier versions, but (a) it's clearly still not perfect (in combination with the Verilog; as I said before I think there's a race in the Verilog), and (b) I personally haven't tried reflashing the bootloader portion on a TinyFPGA BX with this version, nor do I specifically know of anyone who has updated the bootloader with this version (successfully or not).

Unfortunately it seems like the choices are:

1. Leave the 1.0.21/1.0.23 as the release versions on PyPI (which are known to brick boards for some people when upgrading the boot loader); or

2. Release a 1.0.24 on PyPI, with the risk that it might still brick boards for some people when upgrading the boot loader.

(Installing anything other than the boot loader isn't a big deal, as it can always be re-run; the bootloader upgrade process has two steps both of which have to work or it bricks the board.)

Unfortunately (a) the TinyFPGA BX hardware shipped with a bad bootloader (not sure if the newly manufactured boards still ship with the same bad bootloader, but https://tinyfpga.com/bx/guide.html still advises all new users to upgrade their bootloader...), (b) the boot upgrade process is somewhat fragile (only single bootloader, no built in recovery, just bails out if it fails to upgrade the bootloader rather than retrying).

Hence my question "what else do we need to do before it can be released". If "certain it won't brick people's devices" then I suspect that means there'll never be another release (short of, maybe, someone doing a full formal proof).

Ewen

[mithro]

@ewenmcneill I would say we should release if we are fairly confident this release would brick people's boards less than the current release.

Does mean we should test upgrading the bootloader a bit?

[ewenmcneill]

Does mean we should test upgrading the bootloader a bit?

It sounds like that's the most useful thing to test. While successful upgrades won't prove that it will "brick people's boards less than the current release", it'll at least give some confidence that it's not worse.

Do you have TinyFPGA BX boards that you could test upgrading the bootloader? (I have a couple, but won't have time until at least tomorrow, possibly later in the week.)

Ewen

[ewenmcneill]

@mithro It turns out that to test upgrading the bootloader, we'll need TinyFPGA boards that have the 1.0.0 bootloader (or earlier) on them, or the wrong VID/PID programmed into them. And AFAICT everything supplied since about July 2018 has the current 1.0.1 bootloader, with the correct VID/PID.

Perhaps @tinyfpga could supply some older ones that need updating for testing?

The current bootloader version is 1.0.1:

(LX P=tinyfpga_bx.minimal F=micropython) ewen@parthenon:/src/fpga/litex-buildenv$ curl https://tinyfpga.com/update/tinyfpga-bx/bootloader.json
{
  "version": "1.0.1",
  "notes": "Updates USB VID:PID to fix issues with APIO not recognizing the board.",
  "stage_one_url": "https://github.com/tinyfpga/TinyFPGA-Bootloader/releases/download/1.0.1/bootloader.bin",
  "stage_two_url": "https://github.com/tinyfpga/TinyFPGA-Bootloader/releases/download/1.0.1/tinyfpga_bx_fw.bin"
}
(LX P=tinyfpga_bx.minimal F=micropython) ewen@parthenon:/src/fpga/litex-buildenv$ 

and even on a couple of my never used TinyFPGA BX boards, that's what was supplied, from the original CrowdSupply campaign (as preorders), back in July 2018. Which means that it skips upgrading them.

(LX P=tinyfpga_bx.minimal F=micropython) ewen@parthenon:/src/fpga/litex-buildenv$ tinyprog --update-bootloader

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.

        All connected and active boards are up to date!

(LX P=tinyfpga_bx.minimal F=micropython) ewen@parthenon:/src/fpga/litex-buildenv$

AFAICT, as currently written, there's no "force bootloader update even with the same version" argument. So only users receiving 1.0.0 or earlier bootloader (ie, from early in the first Crowd Supply campaign) will even be able to go through the bootloader upgrade process. As best I can tell that's only "a few hundred of them" from July 2018.

@mithro Do you have any older TinyFPGA BX boards that have the wrong VID/PID that you could test with?

@tinyfpga Do you have any older TinyFPGA BX boards that have the wrong VID/PID that you could test with?

If neither of you have any, my guess is that we've probably exhausted the supply of users who are going to be able to brick their TinyFPGA BX boards by upgrading the firmware with tinyprog because tinyprog won't update the firmware on boards with the latest firmware (which in theory should be all of them after July 2018).

Ewen

tinyprog-test.txt

[ewenmcneill]

Closing issue to clean up my "issues opened" list, as the last tinyprog release was 18 months ago, and there appears to be no way to have sufficient confidence to make another release (given there are, AFAIK, only two bootloader versions ever released, and the one on essentially all boards ever supplied is the newest one).

At this point I suspect the best idea is for people to only pip install from the git repo directly.

Ewen