Problem with make firmware-connect

[dafchaparroar]

I'm working with the ice40_hx8k_b_evn. In time to do the "make firmware-connect" the console keeps loading and doesn't respond anymore.

~/litex-buildenv $ make firmware-connect
flterm --port=/dev/ttyUSB1 --speed=115200
[FLTERM] v2.4-29-g47d3b15 Starting...

[mithro]

I'm afraid ice40_hx8k_b_env is currently broken - see https://github.com/timvideos/litex-buildenv/issues/277 - I have some WIP fixes but haven't had time to pull it ll together.

[dafchaparroar]

Thanks for your comment. Now, I'm trying to simulate the program to search for possible issues in the BIOS but is not possible. I'm using the "sim" platform in the environment variables but in the moment to do the make gateware I have this message:

  File "/cain/litex-buildenv/platforms/sim.py", line 1, in <module>
    from litex.boards.platforms import sim
ImportError: cannot import name 'sim' from 'litex.boards.platforms' (/cain/litex-buildenv/third_party/litex/litex/boards/platforms/__init__.py)

I'm not sure about the problem because the file sim.py is in the platform file. Maybe the best option is to build the simulation using the top.v directly with the simulator.

[mithro]

@dafchaparroar

Sorry about this, but we currently don't have good simulation support. @stffrdhrn was trying to fix the issues with that in the pull request https://github.com/timvideos/litex-buildenv/pull/82 but I don't think it was ever finished.

On what the issues is with this board, there appear to be multiple problems. I created a work in progress pull request at https://github.com/timvideos/litex-buildenv/pull/313 and I believe the issues to be fixed are;

• [ ] Update the targets/ice40_hx8k_b_evn/base.py file for changes in upstream litex.
• [ ] Fix the SPI XIP Flash module to use the correct endian.
• [ ] Figure out why VexRISCV seems to require something to be mapped to address 0.

FYI - When trying to fix this we got side tracked in adding uart terminal over uart wishbone bridge support into wishbone-tool so we could attach gdb to the CPU and figure out why the firmware wasn't executing correctly.

[mithro]

@dafchaparroar - I would also like to apologize that you have hit the following issues, things have been a bit more bumpy than we would like at the moment.

[stffrdhrn]

@dafchaparroar

Sorry about this, but we currently don't have good simulation support. @stffrdhrn was trying to fix the issues with that in the pull request #82 but I don't think it was ever finished.

I had sim working but I remember there were a few problems:

1. We wanted the CI to work with sim but there were problems with the verilator toolchain available in CI, those are probably fixed now?
2. There seems to be some problem with how we setup network in the sim environment, I had it working but it maybe needed some hacking.

I can't remember what else was left, but it was working it was just not in a state that CI could run reliably.

[dafchaparroar]

@dafchaparroar - I would also like to apologize that you have hit the following issues, things have been a bit more bumpy than we would like at the moment.

Don't worry. We are learning about the topic and is important to understand the functioning of the project. With respect to my problems I had done the following:

1. In #277 @niklasnisbeth recommended to work with the da7488c commit. Here uP is working for my FPGA using the LM32, and now I'm working with this information searching the changes in the commits.
2. With respect to the simulation a partner is working with the top.v file. Is possible to create a new simulation project in Vivado (for now) using the information of this file without specifying a FPGA. Maybe here is possible to view the principal signals for search specifically issues. Also, I think that is possible to implement in Verilator or Gkwave, If we manage to do this, I will be commenting.