Can't program new TinyFPGA BX ~ 2023-08-22, possibly no metadata?

[eyz]

I just received a new TinyFPGA BX which was ordered through Crowd Supply and shipped by Mouser. I cannot program this new one, but I have an older TinyFPGA BX that programs fine with the same tools.

The power LED is solid red, and the boot LED is pulsing red (during all commands captured below)

Any tips on how to proceed? The messages seem to imply there's a bootloader, but maybe no metadata. Do I need to manually write metadata to the board somehow?

I have many micro-controller boards on hand and in theory could send some SPI commands or similar if needed to resolve this. I believe I have a TinyFPGA programmer as well, if applicable.

$ pip3 list | grep tinyprog
tinyprog                           1.0.21

$ lsusb | grep 1d50
Bus 003 Device 021: ID 1d50:6130 OpenMoko, Inc. 

$ python3 --version
Python 3.10.12

$ tinyprog -p hardware.bin

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Programming /dev/ttyACM0 with hardware.bin
Traceback (most recent call last):
  File "/home/isaac/.local/bin/tinyprog", line 8, in <module>
    sys.exit(main())
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__main__.py", line 334, in main
    addr = fpga.meta.userimage_addr_range()[0]
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__init__.py", line 182, in userimage_addr_range
    return self._get_addr_range(u"userimage")
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__init__.py", line 188, in _get_addr_range
    addr_str = self.root[u"bootmeta"][u"addrmap"][name]
TypeError: 'NoneType' object is not subscriptable
make: *** [Makefile:2: upload] Error 1

$ tinyprog -l

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

        /dev/ttyACM0: No metadata

$ tinyprog -m
Traceback (most recent call last):
  File "/home/isaac/.local/bin/tinyprog", line 8, in <module>
    sys.exit(main())
  File "/home/isaac/.local/lib/python3.10/site-packages/tinyprog/__main__.py", line 257, in main
    m["port"] = str(port)
TypeError: 'NoneType' object does not support item assignment

$ 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!

[drujensen]

@eyz Confirming that I am running into this same issue. Received this board from Crowd Supply today. If you solve it, would be interested.

looking at the code:

class TinyProg(object):
    def __init__(self, ser, progress=None):
        ...

        # temporary hack, should have better database as well as SFPD reading
        if flash_id[0:2] == [0x9D, 0x60]:
            # ISSI
            self.security_page_bit_offset = 4
            self.security_page_write_cmd = 0x62
            self.security_page_read_cmd = 0x68
            self.security_page_erase_cmd = 0x64
    
        else:
            # Adesto
            self.security_page_bit_offset = 0
            self.security_page_write_cmd = 0x42
            self.security_page_read_cmd = 0x48
            self.security_page_erase_cmd = 0x44

        self.meta = TinyMeta(self)

Looks like these cmd are not working and meta is returning None. Maybe our boards didn't come with the meta json included?

[eyz]

Looks like these cmd are not working and meta is returning None. Maybe our boards didn't come with the meta json included?

I suspect the bootloader is programmed (because tinyprog indicates it's there) but the metadata file wasn't uploaded. I wonder if it's a known issue for any of the boards produced. I ordered two more and would be overjoyed if they had the metadata on them, so I don't have to figure out how to upload the metadata myself. That said, if it's super easy to connect some SPI up and use an Arduino sketch to upload the metadata I would be up for it.

[eyz]

@tinyfpga is there another TinyFPGA BX production run that includes these metadata files?

[drujensen]

@eyz I did a bit of hacking on the tinyprog project to bypass the meta check. This is only a temporary solution and will break your other fpga's if you do this. You have been warned!

Find where tinyprog source code is at. should be under site-packages and hard code the self.root in the __init__ of the TinyMeta class found in the __init__.py file as follows:

class TinyMeta(object):
    def __init__(self, prog):
        self.prog = prog
        prog.wake()
        self.root = {
            "boardmeta": {
                "hver": "0.0.0",
                "name": "TinyFPGA BX",
                "fpga": "ICE40LP8K-cm81",
                "uuid": "4a300a6f-895a-44d3-b021-356c6b38b339",
            },
            "bootmeta": {
                "bver": "2.0.0",
                "bootloader": "TinyFPGA USB Bootloader",
                "update": "https://tinyfpga.com/update/tinyfpga-bx",
                "addrmap": {
                    "bootloader": "0x00000-0x28000",
                    "userimage":  "0x28000-0x50000",
                    "userdata":   "0x50000-0xFC000",
                    "desc.tgz":   "0xFC000-0xFFFFF"
                }
            }
        }

If you want to be extra safe, copy or fork the project somewhere and then run this python script directly instead of using the one in the path. (Note: I generated a UUID to avoid conflicts)

[eyz]

@eyz I did a bit of hacking on the tinyprog project to bypass the meta check.

Nice! It looks like you are simply hard-coding the expected metadata where it would normally be retrieved from the Tiny FPGA BX. Since I'm only using this one FPGA with tinyprog that's a completely acceptable solution. Great hack! If the USB ID is specific to the tiny FPGA BX maybe this could be a suitable workaround for others as well, such as if that USB ID is found it would simply drop this in if it couldn't be located, like a "use default metadata" flag.

In my case, I found the file you patched in ~/.local/lib/python3.10/site-packages/tinyprog/init.py (for my user install) and /usr/local/lib/python3.10/dist-packages/tinyprog/init.py (for an old root install) on my Ubuntu 22.04.3 system -

class TinyMeta(object):
    def __init__(self, prog):
        self.prog = prog
        prog.wake()
#        self.root = self._read_metadata()
        self.root = {
            "boardmeta": {
                "hver": "0.0.0",
                "name": "TinyFPGA BX",
                "fpga": "ICE40LP8K-cm81",
                "uuid": "4a300a6f-895a-44d3-b021-356c6b38b339",
            },
            "bootmeta": {
                "bver": "2.0.0",
                "bootloader": "TinyFPGA USB Bootloader",
                "update": "https://tinyfpga.com/update/tinyfpga-bx",
                "addrmap": {
                    "bootloader": "0x00000-0x28000",
                    "userimage":  "0x28000-0x50000",
                    "userdata":   "0x50000-0xFC000",
                    "desc.tgz":   "0xFC000-0xFFFFF"
                }
            }
        }

Great idea! Thanks!

$ tinyprog -p hardware.bin

    TinyProg CLI
    ------------
    Using device id 1d50:6130
    Only one board with active bootloader, using it.
    Programming /dev/ttyACM0 with hardware.bin
    Programming at addr 028000
    Waking up SPI flash
    135100 bytes to program
    Erasing: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 358kB/s]
    Writing: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 229kB/s]
    Reading: 100%|█████████████████████████████████████████████████████████████| 135k/135k [00:00<00:00, 458kB/s]
    Success!

A solid red light is a good red light (flashed successfully, thus solid red now) -

[eyz]

See https://github.com/tinyfpga/TinyFPGA-Bootloader#fpga-board-metadata for some context on the following if you want to dig in.

Security page dumps from an older TinyFPGA BX board

I was successfully able to dump security pages 1, 2, and 3 to binary files from my older model TinyFPGA BX. However, when I tried to program them onto my new TinyFPGA BX (where they are blank, all default flash 0xFF) I saw no evidence of the security pages being updated, presumably because they are write-protected. I suspect there is some process to unlock the write-protection outside of tinyprog. Without this information I believe I cannot proceed further in correcting the security page metadata.

What I modified to dump out the security pages from a TinyFPGA BX that is about 3 years old -

    def read_security_register_page(self, page):
        data = self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255) # Isaac debug
        print("read_security_register_page", page, data) # Isaac debug
        with open("tinyfpga-bx-security-page." + str(page), "wb") as security_page_file: # Isaac debug
          security_page_file.write(data) # Isaac debug
        return data # Isaac debug
        #return self.cmd(self.security_page_read_cmd, addr=page << (8 + self.security_page_bit_offset), data=b'\x00', read_len=255)

Dumped security pages resulted in -

$ xxd tinyfpga-bx-security-page.1
00000000: 7b22 626f 6172 646d 6574 6122 3a7b 226e  {"boardmeta":{"n
00000010: 616d 6522 3a22 5469 6e79 4650 4741 2042  ame":"TinyFPGA B
00000020: 5822 2c22 6670 6761 223a 2269 6365 3430  X","fpga":"ice40
00000030: 6c70 386b 2d63 6d38 3122 2c22 6876 6572  lp8k-cm81","hver
00000040: 223a 2231 2e30 2e30 222c 2275 7569 6422  ":"1.0.0","uuid"
00000050: 3a22 3863 3934 3263 6136 2d36 6133 662d  :"8c942ca6-6a3f-
00000060: 3439 6537 2d39 3637 302d 6637 6462 3465  49e7-9670-f7db4e
00000070: 3462 3236 3736 227d 7d00 2020 2020 2020  4b2676"}}.      
00000080: 2020 2020 2020 2020 2020 2020 2020 2020                  
00000090: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000a0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000b0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000c0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000d0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000e0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000f0: 2020 2020 2020 2020 2020 2020 2020 20   

$ xxd tinyfpga-bx-security-page.2
00000000: 7b22 626f 6f74 6d65 7461 223a 7b22 626f  {"bootmeta":{"bo
00000010: 6f74 6c6f 6164 6572 223a 2254 696e 7946  otloader":"TinyF
00000020: 5047 4120 5553 4220 426f 6f74 6c6f 6164  PGA USB Bootload
00000030: 6572 222c 2262 7665 7222 3a22 312e 302e  er","bver":"1.0.
00000040: 3122 2c22 7570 6461 7465 223a 2268 7474  1","update":"htt
00000050: 7073 3a2f 2f74 696e 7966 7067 612e 636f  ps://tinyfpga.co
00000060: 6d2f 7570 6461 7465 2f74 696e 7966 7067  m/update/tinyfpg
00000070: 612d 6278 222c 2261 6464 726d 6170 223a  a-bx","addrmap":
00000080: 7b22 626f 6f74 6c6f 6164 6572 223a 2230  {"bootloader":"0
00000090: 7830 3030 6130 2d30 7832 3830 3030 222c  x000a0-0x28000",
000000a0: 2275 7365 7269 6d61 6765 223a 2230 7832  "userimage":"0x2
000000b0: 3830 3030 2d30 7835 3030 3030 222c 2275  8000-0x50000","u
000000c0: 7365 7264 6174 6122 3a22 3078 3530 3030  serdata":"0x5000
000000d0: 302d 3078 3130 3030 3030 227d 7d7d 0020  0-0x100000"}}}. 
000000e0: 2020 2020 2020 2020 2020 2020 2020 2020                  
000000f0: 2020 2020 2020 2020 2020 2020 2020 20  

$ xxd tinyfpga-bx-security-page.3
00000000: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000c0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000d0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000e0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
000000f0: ffff ffff ffff ffff ffff ffff ffff ff    ...............

Security pages likely are write-protected, otherwise this could work to update them

I tried reading back the binary dumps (above) and update the security pages on the newer board using this function, but no luck (probably due to write protection?) -

    def program_security_register_page(self, page, data):
        self.write_enable()
        self.cmd(self.security_page_write_cmd, page << (8 + self.security_page_bit_offset), data)
        self.wait_while_busy() 

^ I did not include the wrapper that calls this to attempt to re-program each security page, as it wasn't successful. This function is included in this GitHub comment for context only.

No differences once flashed between old and new boards in pages outside of security page area

I also compared my older board with the newer board with the same user bit-stream flashed, and I only saw a difference between the security pages, not the rest of the pages being read during programming, as confirmed by outputting the raw bytes in the rest of the read function calls -

   def read(self, addr, length, disable_progress=True):
        data = b''
        with tqdm(desc="    Reading", unit="B", unit_scale=True, total=length, disable=disable_progress) as pbar:
            while length > 0:
                read_length = min(255, length)
                data += self.cmd(0x0b, addr, b'\x00', read_len=read_length)
                self.progress(read_length)
                addr += read_length
                length -= read_length
                pbar.update(read_length)
            #print("read",addr,length,data) # Isaac debug
            return data

Physical write-protection investigation

From https://github.com/tinyfpga/TinyFPGA-BX/blob/master/board/TinyFPGA-BX-Schematic.pdf, perhaps this needs to be brought high to allow the security pages to be written? -

Datasheet for the AT25SF081-SSHD-B
SPI flash at https://www.mouser.com/datasheet/2/698/DIAL_S_A0012368008_1-2956400.pdf helps confirm -

[Blackninja543]

@eyz According to https://github.com/tinyfpga/TinyFPGA-BX/blob/master/TinyFPGA%20BX%20Card%20Back.png pin 10 (H4|spi_io2|SPI Flash WP_B/IO2) looks like it might also be the same write protect pin.

[eyz]

@eyz According to https://github.com/tinyfpga/TinyFPGA-BX/blob/master/TinyFPGA%20BX%20Card%20Back.png pin 10 (H4|spi_io2|SPI Flash WP_B/IO2) looks like it might also be the same write protect pin.

^ It looks like that net (circled in green) is pulled-up to 3.3 volts (circled in purple).

In addition to the labeled circular WP pad on the back, it looks like solder pad # 27 on the back is the same net.

Regarding the mention of pin 10 I think they mean labeled pad # 27, not the outside through-hole pin 10 on the edge of the board, see -

The datasheet states that the WP signal is active low, so I'd assume the pull-up means it's not hardware write-protected. Perhaps another layer of protection is preventing the security page area from being programmed -

At this point, I believe the security register lock bits have likely been set, which appears to permanently (one-time program) set the values in those pages, see -

Given this, I suspect those security page areas with the metadata may not be possible to change, even though the WP net is being pulled up high (which would otherwise disable the hardware write protection on the SPI flash chip)

Here are the security lock registers (LB3-LB1) -

[Blackninja543]

After doing some more research it does appear the fix is going to be a little harder.

SPI Flash Security Register Page 1 (write-protected)
One of the SPI flash security register pages contains fixed data about the board that does not change. This is the name of the board, the hardware revision of the board, and serial number unique to the board name. This security register page should be write protected as it should never be changed. If the rest of the SPI flash is erased, this minimal amount of information will help the user to find recovery instructions.

https://github.com/tinyfpga/TinyFPGA-Bootloader

[eyz]

After doing some more research it does appear the fix is going to be a little harder.

SPI Flash Security Register Page 1 (write-protected)
One of the SPI flash security register pages contains fixed data about the board that does not change. This is the name of the board, the hardware revision of the board, and serial number unique to the board name. This security register page should be write protected as it should never be changed. If the rest of the SPI flash is erased, this minimal amount of information will help the user to find recovery instructions.

https://github.com/tinyfpga/TinyFPGA-Bootloader

Yep. I saw that at the end of yesterday, prior to my deep dive research today in this comment / thread. I'm now deferring to those here to come up with a solution, or possibly return these units for replacements that are programmed properly. I'm only using the BX personally, so I'm fine leaving that workaround in my tool chain for the foreseeable future, although the proper solution is certainly having the metadata stored properly on the physical hardware.

@tinyfpga ?

[scm2000]

I edited the init method as suggested and was able to program my board, but is there a way that I can program the needed metadata onto the board myself?

[eyz]

I edited the init method as suggested and was able to program my board, but is there a way that I can program the needed metadata onto the board myself?

Based on my extensive research in the thread above, it's extremely unlikely that you can program the metadata into the security protected portion of the SPI flash. My finding was that it's most likely locked when they program the firmware on the board as part of their programming workflow, and effectively read only in that area, thus you can't update it again.