Git Product home page Git Product logo

Comments (3)

tmahlburg avatar tmahlburg commented on June 3, 2024

Great to hear this project still has some use for someone. This is what I would probably try:

In my opinion you don't really need the code of the other repositories. You should be able to use all the original files of the picorv32 repo (picorv32.v, picosoc.v, simpleuart.v, spimemio.v). Now you can use the wrapper (basys3.v) in this repository as a base. Basically you just need to change the wrapper to connect to your pmod flash instead of the onboard chip, which already use the same protocol, so it shouldn't be too difficult.

The stuff you need to edit are the four inouts called QspiDB (the data lines) as well as QspiCSn and QspiCLK. These are currently connected to the onboard SPI flash via the default Digilent constraints file (as linked in the README). They have to be changed to the corresponding pmod pins. This can either be done by changing the names in the names accordingly in the constraints file or by renaming the ports in the wrapper itself to the names used in the constraints file. In either case, you have to pay special attention to the QspiCLK wire. The onboard SPI flash doesn't expose its clock via pin, but has to be connected via the STARTUPE2 primitive. That's why it is not declared as input but as wire. This is probably not needed with your pmod SPI, so you can delete that part and just declare it as input and connect it as needed.

This should give you a working, unmodified PicoSoC. You still need to load the firmware.bin into the pmod flash of course, but it seems like you already figured out how to do that. If you have further questions, feel free to ask, and I will try to answer them. Good luck!

from picosoc-basys3.

DrmnSamoLiu avatar DrmnSamoLiu commented on June 3, 2024

Edit:
Ahhhh sorry, please don't mind the questions about building firmware. I saw you also provided a Makefile.
I really should take time and go through everything before asking dumb questions.

 
@tmahlburg
Thank you for your quick response!
I'm trying what you said right now (use your basys3.v on top of original picosoc), but had some question about QspiCLK.
If it shouldn't be wire for pmod SPI, then shouldn't it be output to the pin that I connected to physical SPI flash CLK instead of input that you mentioned?

I tried to set QspiCLK as output and connect it to the clk pin of flash chip via constraint, and it did worked just like the unexpected behavior I mentioned before ( only the right most 5 leds light up). I thought it was some clocking problem before but now I'm suspecting if I rebuild the firmware incorrectly....

Speaking of firmware, do you know if there is any .c source code and riscv-gcc build parameter that is working on basys3?

I'm using build command provided with TinyFPGA example:
firmware.elf: sections.lds start.S firmware.c riscv32-unknown-elf-gcc -march=rv32imc -nostartfiles -Wl,-Bstatic,-T,sections.lds,--strip-debug,-Map=firmware.map,--cref -ffreestanding -nostdlib -o firmware.elf start.S firmware.c

But I'm not sure what's built for ICE40 will work on Basys3.
I saw that you also provided sections.lds in your repo, should I just leave other parameters as is and use the sections.lds you provided?

Sorry for asking so many noobie questions..... I'm really not experienced enough in compiling code for such low level component


Update:

Just built a new firmware with firmware.c coming from here with the sections.lds and Makefile you provided. Only added -DNOSPIFLASH flag so gcc won't complain about things.
However behavior of Basys3 is still the same, 5 led lit and no UART output. Now I'm lost again :(

By the way what source code are you compiling with your Makefile ? I saw -DBASYS3 in it but I failed to find any firmware explicitly written for Basys3...


Update2:
For now I also tried modifying FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x400000 /* entire flash, 4 MiB */ in sections.lds to
FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x1000000 , as I am using a 128Mbit SPI flash.
Then I recompile basys3_fw.bin basys3_fw.elf basys3_sections.lds and used basys3_fw.bin as fw in flash but still no luck :(

from picosoc-basys3.

tmahlburg avatar tmahlburg commented on June 3, 2024

I'm trying what you said right now (use your basys3.v on top of original picosoc), but had some question about QspiCLK.
If it shouldn't be wire for pmod SPI, then shouldn't it be output to the pin that I connected to physical SPI flash CLK instead of input that you mentioned?

Yes, you're right, it's been a while since I wrote this, my memory is a little fuzzy on some of the details.

Update2:
For now I also tried modifying FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x400000 /* entire flash, 4 MiB */ in sections.lds to
FLASH (rx) : ORIGIN = 0x00100000, LENGTH = 0x1000000 , as I am using a 128Mbit SPI flash.
Then I recompile basys3_fw.bin basys3_fw.elf basys3_sections.lds and used basys3_fw.bin as fw in flash but still no luck :(

This project was actually just a byproduct of my project for my bachelor's thesis, to build a multithreaded RISC-V core, which I've not worked on for quite a while, since my thesis is done. Because of that, I just used a stripped down version of the firmware.c of the picosoc, because I did this wrapper more as a proof-of-concept, to show the core could be run on a basys3. I don't know, if I still have it somewhere, but I can check later. What I did was basically deleting everything except some LED and UART output to test it. The -DBASYS3 was used for the section at the top, where I set the MEM_TOTAL to the correct amount. The other important parameter is reg_uart_clkdiv, which needs to be set to the correct value depending on the clock rate you're running the core at and the baud rate your UART terminal is using. According to the README.md:

The UART Clock Divider Register must be set to the system clock frequency divided by the baud rate.

By simplifying the firmware it should be easier to find out what's wrong. The clock rate would actually be something you might want to look into. In the wrapper, it is set via the PLL ((base clock (100MHz, IIRC) * CLKFBOUT_MULT) / CLKOUT0_DIVIDE) and probably should be decreased, as it runs at 50 MHz right now. This is probably to fast for the cheap Artix-7 on the Basys3. You could try it running at 1 MHz, just to make sure clock speed isn't the problem.

Over the weekend, I might have time to check if I still get this to run on the internal flash and get back to you with a working firmware and so on.

from picosoc-basys3.

Related Issues (4)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.