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.

[jano]

hi!
any news on the manufacture of this? I'm on the waiting list (on tindie) since

Sun, 21 Apr, 20:52

[Folknology]

Hi @jano apologies for the delay, I will be giving an update on this soon, BlackIce Mx is currently in the process of manufacture a number of different parts have to come together from different countries. I have had some frustrating issues with getting components to the factory which has delayed things a little particularly on the IceCore module. However all of that has now been dealt with and production is ongoing. I will probably do an update next week on the details as well as product pages and shipping schedule etc..

Thank you for your patience.

BTW I will ship to those on the Tindie waitlist as a priority first just make sure you respond to the email as soon as the stock is entered to confirm your order (Tindie sends out the emails, you have to act on them I believe).

[jano]

Cool, good to know the project it's still alive, I can wait, no problem.

[Folknology]

Bit of an update on layout and options, whilst the MX build continues

So here is the BlackIce Mx carrier

Combined with IceCore

Fully loaded

Breadboard MixMod

Proto MixMod

Test Mixmod (extender)

I will be updating the Tindie product page over the next few days to include these options, when you get the email from the wait list and you turn this into an order you can select these options if you are interested. These new options replace the older addon Pmod options for BlackIce, although we do still have some of the older Proto Pmods if any one needs one (I will add this in as a separate product).

[Folknology]

Had a busy 'baking' day today..

[Folknology]

So a quick update, later today I will add stock to BlackIce Mx and it's optional addons to allow those who are waitlisted to convert their notifications into orders. I will plan the shipments over the weekend and commence shipments converted from the waitlist next week, please be patient as it may take a little time for me to get through the orders as there will like be quite a few if the waitlist is anything to go by. Keep an eye on your email or Tindie notifications over the next day or so....

[r.miller]

Started to order an Mx on tindie, but it seems to insist on billing in US dollars. Is there a way for me to pay in pounds for you to receive pounds, without the implied double currency conversion?

[jano]

Same thing here, I'm in Germany and will pay with euro