Load FPGA Bitfiles to Flash #30
Conversation
|
Here are the changes needed on the FPGA side: |
|
@harbaum could you please advise how to continue both MR FPGA companion and my A2600? I am using the m0s(6) and m0s(7) for external hw pin uart purpose in the VIC20 and C64 core. I am also using m0s(5) also as back-up in primer 20k for uart purpose to overcome pin overlap with RGB multicolor LED. |
|
I haven't tried this myself and I am not sure I fully understand the use case. This allows the esp32 to read a core from SD card and to flash it to the FPGAs own SPI flash? This works while the FPGA is still running as otherwise the FPGA would not be able to provide the SD card access during that. Right? The new core is flashed to 0x1000000 which is where the Atari ST stores it's ROMs. So this would not work with the Atari ST core, anyway. So this is meant to be used with which cores? I must admit I do like the idea of being able to update the core from the running system. But I need to check why and how this collides with the usage of m0s[5..7]. I assume these are used to tell the FPGA to reboot with a different core. I need to check and understand that. |
|
Hello, sorry for the slow response. The use case that I was thinking of for this is to be able to have a /cores folder on the sdcard that holds the different cores that are available for the Tang FPGA boards. Then the menu system can be used to switch between the cores without any external help. So an end user could change between the A2600, Atari ST, C64, Amiga, or any other cores from the user menu instead of a computer. This was just a demo of how this could be done with the simplest a2600 core. A full solution would have to be implemented in a way that works for all of the cores. The location in the SPI Flash for the secondary bit file could be any location, on a page boundary. It could even be at 0x00, without multiboot, but I'm working on a bootloader that I'd like to keep at 0x00. A final implementation would probably have a Cores or Platforms option in the menu but I was trying to change as little code as possible as a proof of concept. As a side note, for this use case the bootloader is not necessarily needed. If all the cores that are loaded to the FPGA have the SPI pins and the Flash CS pin exposed then the esp32 will be able program the FPGA. As a nice bonus the esprog tool can be used to program the FPGA from a computer. If there was ever a bad flash it would be nice to have the bootloader to be able to recover. I have a hardware design that I'm working on right now that puts the Tang Primer 20K, esp32-s3, 32Mbit of SDRAM, HDMI, audio, and USB on a low cost board. It is going to need a esp32 bootloader solution. It would also be cool to put all of your cores and roms on the sd card and be able to switch between cores. |
|
I'd really like to get forward with this one as I really like the general idea. This particular firmware PR imho has no negative effect on existing setups so far except that for the esp32 the IRQ pin changes which imho would not hurt at all. But maybe we should come up with a complete concept for this. |
| #define PIN_NUM_MISO 13 | ||
| #define PIN_NUM_MOSI 11 | ||
| #define PIN_NUM_CLK 12 | ||
| #define PIN_NUM_CS 10 | ||
| #define PIN_NUM_IRQ 14 |
There was a problem hiding this comment.
Why are you moving this away from pin 14?
| @@ -412,9 +427,48 @@ void mcu_hw_spi_init(void) { | |||
| debugf(" IRQn = GPIO%d", PIN_NUM_IRQ); | |||
| gpio_set_pull_mode(PIN_NUM_IRQ, GPIO_PULLUP_ONLY); | |||
| gpio_set_direction(PIN_NUM_IRQ, GPIO_MODE_INPUT); | |||
| gpio_install_isr_service(ESP_INTR_FLAG_LEVEL1); | |||
| gpio_install_isr_service(ESP_INTR_FLAG_LEVEL2); | |||
Here is a commit that allows loading a bit file to SPI flash and then restarting the FPGA.
Will work on getting a commit for the changes needed on the FPGA side in place.