search

litex-hub / linux-on-litex-vexriscv

Linux on LiteX-VexRiscv
BSD 2-Clause "Simplified" License
573 stars 174 forks source link

SPIFlash instantiation in make.py causes unintended errors #252

Closed essele closed 2 years ago

essele commented 2 years ago

The current approach to creating spiflash modules in make.py causes a lot of objects to be instantiated (as each board that has a flash module will cause one to be instantiated), the way the SpiNorFlashModule is coded the "read_cmds" array will persist, this will cause an error if a x1 only capable device is instantiated after a x4 capable device.

This is easily reproduced by changing the default read command on the HADBadge to READ_1_1_4. When you try to run make.py you'll get an error for the ECPIX5 board because the IS25LP256D doesn't support x4 ... despite the fact that it's called with READ_1_1_1.

I assume SpiNorFlashModule is not really intended to be instantiated more than once?

Also ... instantiating flash in the make.py script seems to be at odds with some devices that do it in the litex-boards target. Is there a standard approach?

enjoy-digital commented 2 years ago

Hi @essele,

to give a bit of context, LiteSPI integration in LiteX-Boards target has been done after the current SPI Flash integration in Linux-on-LiteX-VexRiscv and a cleanup pass on this still needs to be done. I'll try to do it soon and also address the issue you saw.

enjoy-digital commented 2 years ago

The integration has just been updated and now reuses the integration already done in LiteX-Boards' targets. I removed SPI Flash support for board not already having the integration done in LiteX-Boards.

With this, we should now have working MMAPed SPI Flash support, but this would still need an update of the Linux driver as described in https://github.com/litex-hub/linux-on-litex-vexriscv/issues/235.