New Product - BlackIce Mx

[Folknology]

What will control which of these methods is used? If I have a multi-boot configuration in the flash memory will it boot straight into that on power on?

Booting from the default (0) image/bitfile in flash from power on would make the best sense

I am interested in what the user interface for writing from the host to the flash memory is. Presumably there will be ways to write a bitfile which is a single or multi-boot configuration, and other data such as roms to different addresses in the flash memory. Writing a concatenation of a bitfile and other data from one host file is also useful.

Although not determined yet and open for discussion how we operate this there is a mode button, this could toggle between modes of direct program and program flash for example. I am open to suggestions what do you think?

[lawrie]

I am open to suggestions what do you think?

I think the normal way of working should be to preload a multi-boot configuration into the flash memory and for the default programming mode to overwrite the default, cold boot, configuration in flash, and then get the ice40 to boot to it.

If you want to stick with the "cat bitfile >/dev/ttyACM0" configuration method, we could add a header with address and length to the bitfile, or better, have a series of chunks with address and length headers, so that you could write new configurations and roms and other data to the flash in one go.

I am not sure when you would want to do the direct programming rather than writing to flash, but you could have a flag in the header to say do direct programming rather than flash programming.

[Folknology]

I think the normal way of working should be to preload a multi-boot configuration into the flash memory and for the default programming mode to overwrite the default, cold boot, configuration in flash, and then get the ice40 to boot to it.

I concur.

If you want to stick with the "cat bitfile >/dev/ttyACM0" configuration method

Definitely would like to keep this

we could add a header with address and length to the bitfile, or better, have a series of chunks with address and length headers, so that you could write new configurations and roms and other data to the flash in one go.

I'm rusty on the Lattice bitfile contents and meta data, much of what you are suggesting may already designed in, we would just have to check for it (semi parse the meta data)?

I am not sure when you would want to do the direct programming rather than writing to flash, but you could have a flag in the header to say do direct programming rather than flash programming.

It maybe possible to automagically do this is the meta data is parsed..

[lawrie]

I'm rusty on the Lattice bitfile contents and meta data, much of what you are suggesting may already designed in, we would just have to check for it (semi parse the meta data)?

There is some information in this thread on experiments I did with multi-boot configurations on the TinyFPGA BX. Luke Valenty added an extra layer of his own metadata to the flash memory for that board, using security sectors in the flash memory.

I think you need the address and length headers to support writing roms and other data to the flash memory, but bitfiles and multi-boot configurations are self identifying in the first few bytes so you could make such headers optional. Bitfiles seem to start 0xF00F7E99AAFE and multi-boot configurations (produced by icemulti) start 0x7E99AAFE. A multi-boot configuration would normally be written to address 0, and a bitfile to address 0xE0 (the coldboot image of a multi-boot configuration).

[lawrie]

I think a couple of use cases we should support are:

1. Writing a bitfile and associated data (usually ROMs) to the flash memory in one go as done by Ice40Atom and Ice40Beeb, currently using dfu-util.

2. Writing a multi-boot configuration and associated data in one go for a boot menu and multiple programs, e.g. a reto-computer boot menu that lets you choose if you want to run an Acorn Atom or a BBC Micro or another retro computer. These would all have separate bitstreams and separate ROMs.

These would need multiple chunks and headers with address and length to say where to write each piece of data.

[Folknology]

I have been playing with the new BlackIceMx lego...

[Folknology]

Writing a multi-boot configuration and associated data in one go for a boot menu and multiple programs, e.g. a reto-computer boot menu that lets you choose if you want to run an Acorn Atom or a BBC Micro or another retro computer. These would all have separate bitstreams and separate ROMs.

This is an interesting idea, I was just thinking how this could be implemented, Lattice quotes :

If Cold Boot is enabled, the FPGA reads the logic values on pins CBSEL[1:0]. The FPGA uses the value as a vector and then reads from the indicated vector address.

Given that I can control CBSEL[1:0] from the STM32 it could offer a menu to select which vector. However I could only change CBSEL1 in practice as this is connected to wp on the flash, the other is connected to the hold pin which would mess with loading from the flash if enabled..

It might be possible to overcome this by monitoring the Ice40 SS pin and releasing hold when it changes or after a fixed time from Ice40 reset perhaps.

Actually we could only fit 3 full images in the 4Mbit flash, also one is likely to require some runtime flash in addition to Ice40 bit images so maybe limiting it to fewer choices makes more sense, 2 choices is perhaps best..

[lawrie]

I used the multiboot capability for something similar on the TinyFPGA BX. That board uses a multiboot configuration with 2 bit images by default. It colds boots to the USB bootloader at address 0xe0, and writes the user image to 0x28000, which the usb bootloader uses SB_WARMBOOT to boot to.

I modified the configuration to have 4 images - see https://github.com/lawrie/TinyFPGA-Bootloader/blob/master/boards/TinyFPGA_BX/Makefile

I then implemented a multi-boot menu for the FPGC games console that used the image at 0x28000 as the menu, leaving the USB bootloader at 0xe0. The games menu reads the ice40 bitfile and the picorv32 program from an SD card and writes them both to the flash memory. The bitfile is written to 0x78000 which is the 4th multiboot configuration and it uses SB_WARMBOOT to boot to it - see https://discourse.tinyfpga.com/t/bx-portable-game-console-project-collaboration/553/154

So that uses 3 bit images, but as the Blackice Mx does not use a USB bootloader, it could do this with two images. The TinyFPGA BX has 8Mbit of flash, so it supports 4 images in flash, plus a lot more space for programs or other data.

[lawrie]

I have been playing with the new BlackIceMx lego...

Test point adapters similar to the Digilent ones would be useful for those mixed signal connectors so that you could look at the digital or analog signals with an oscilloscope or logic analyser while a Pmod is connected.

[Folknology]

BlackIceMx is getting ready for manufacture this week, I started the file uploads, feel free to take a peek..

[lawrie]

Ah, I hadn't realised that the COMS/DBG header was essentially the same as the Raspberry Pi header on the Blackice II.

[Folknology]

Yes I have tried to maintain some limited feature consistency with BlackIce II where possible I2C, UART, SPI and SW Debug/prog pins. However there are some subtle differences, when programming from the RPi use the USB as the SPI is just for data purposes slave of the ICE40. In addition we have JTAG pins mapped onto the RPi header although not used with IceCore (Ice40Hx) they can be used with NextCore (ECP5) when that emerges later in the year.