Better vexriscv linux support

[mateusz-holenko]

This PR updates submodules with the newest version of:

• VexRiscv supporting building emulator (BIOS) for LiteX target,
• LiteX
  • with the fixed netboot/flashboot for VexRiscv.linux cpu,
  • with cpu variant information generated to csr.csv,
• litex-renode with the enhancements in script generating Renode platform utilizing new information in csr.csv and supporting more peripherals

It also adds generation of emulator_ram to arty target when building for VexRiscv.linux cpu. This is a memory where VexRiscv emulator is loaded by the LiteX BIOS.

EDIT: I split this PR into 3 separate ones. This one contains now changes related to building Linux for VexRiscv using ./scripts/build-linux.sh script.

[mithro]

I don't understand what this is?

[mateusz-holenko]

It definiately requires a discussion.

I proposed some changes to LiteX BIOS booting sequence to make it easier to boot Linux on VexRiscv.
This was my PR: enjoy-digital/litex#216.
It has been merged to master, but then on top of that enjoy-digital added new commits:

• enjoy-digital/litex@af61688
• enjoy-digital/litex@462d12b

As a result VexRiscv emulator requires now it's own memory region described by EMULATOR_RAM_BASE or must be located at fixed location 0x20000000.

This modification to arty/base.py generates this new memory region.
I believe this should not be arty-specific, but don't know if there is some common code in litex-buildenv where this should go?

EDITED: I fixed the default emulator location from 0x50000000 to 0x20000000

[mateusz-holenko]

I've just realized that this is not the proper way of adding new memory region in LiteX. I'll change this to sth like:

self.submodules.emulator_ram = wishbone.SRAM(size)                                                                                                                                                                                                                           
self.register_mem('emulator_ram', self.mem_map['emulator_ram'], self.emulator_ram.bus, size)

[mithro]

Looks like this breaks the Lattice lm32 build in some way?

Traceback (most recent call last):
  File "./make.py", line 164, in <module>
    main()
  File "./make.py", line 148, in main
    vns = builder.build(**dict(args.build_option))
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/integration/builder.py", line 169, in build
    self.soc.finalize()
  File "/home/travis/build/timvideos/litex-buildenv/third_party/migen/migen/fhdl/module.py", line 157, in finalize
    self.do_finalize(*args, **kwargs)
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/integration/soc_core.py", line 507, in do_finalize
    self._wb_slaves, register=True, timeout_cycles=self.wishbone_timeout_cycles)
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/interconnect/wishbone.py", line 165, in __init__
    self.submodules.decoder = Decoder(shared, slaves, register)
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/interconnect/wishbone.py", line 116, in __init__
    for i, (fun, bus) in enumerate(slaves)]
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/interconnect/wishbone.py", line 116, in <listcomp>
    for i, (fun, bus) in enumerate(slaves)]
  File "/home/travis/build/timvideos/litex-buildenv/third_party/litex/litex/soc/integration/soc_core.py", line 104, in <lambda>
    return lambda a: (a[log2_int(size):-1] == (address >> log2_int(size)))
  File "/home/travis/build/timvideos/litex-buildenv/third_party/migen/migen/fhdl/bitcontainer.py", line 12, in log2_int
    raise ValueError("Not a power of 2")
ValueError: Not a power of 2
real	0m0.624s
user	0m0.465s
sys	0m0.043s
Makefile:301: recipe for target 'firmware-cmd' failed
make: *** [firmware-cmd] Error 1

[mateusz-holenko]

I noticed problems with Travis and will be investigate them shortly, but currently I have problems with running this branch on arty board. After the update of LiteX submodule vexriscv.linux cpu variant does not work on HW - it prints just two characters of the LiteX logo on UART and stops.

I narrowed the problem to the specific commit in LiteX: enjoy-digital/litex@9d170b0. If I revert it, the BIOS starts working fine.

[enjoy-digital]

@mateusz-holenko: it's still possible to use the old mem-map if needed, you can do it as it's done here:
https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L25-L33
with something like this:

       soc_cls.mem_map = {
           "rom":          0x00000000,
           "sram":         0x10000000,
           "main_ram":     0x40000000,
           "csr":          0x60000000,
       }

GitHub

litex-hub/linux-on-litex-vexriscv

Linux on LiteX-VexRiscv. Contribute to litex-hub/linux-on-litex-vexriscv development by creating an account on GitHub.

[mateusz-holenko]

While doing further tests on HW I noticed some problems in VexRiscv emulator. My fixes are waiting in this PR: SpinalHDL/VexRiscv#80.

We might wait with this PR until the changes are merged upstream, so there is no need to bump the submodules twice.

EDIT: The PR has been accepted to master.

[mateusz-holenko]

I created a separate PR that bumps the submodules: #179. Once it's merged to master I'll rebase this one on top of it, add changes in ./scripts/build-linux.sh and let you know it's ready for a review.

[todo]

to be removed later)

litex-buildenv/scripts/build-linux.sh

Lines 184 to 189 in 3463f3d

	# download and use pre-built RISC-V compiler (TODO: to be removed later)
	TOOLCHAIN_LOCATION=$TOP_DIR/third_party/riscv-toolchain
	mkdir -p $TOOLCHAIN_LOCATION
	(
	cd $TOOLCHAIN_LOCATION
	if [ ! -d riscv ]; then

---

This comment was generated by todo based on a TODO comment in 3463f3d in #174. cc @antmicro.

[mateusz-holenko]

NOTE: This PR requires changes from #176 and #179.

I rebased this branch to contain changes related directly to building Linux for VexRiscv in the context of the refreshed version of https://github.com/timvideos/litex-buildenv/wiki/HowTo-LCA2018-FPGA-Miniconf tutorial.

The new version of the tutorial is currently hosted here: https://github.com/antmicro/litex-buildenv/wiki/HowTo-LCA2018-FPGA-Miniconf-VexRiscv-Renode. It targets VexRiscv and Renode (instead of mor1kx and qemu) and has updated commands (mostly env variables) and their output. The only TODO left is about changing the URI to litex-buildenv after merging everything upstream (currently it points to antmicro's fork).

@mithro Where do you want me to put this tutorial and what title should it have?

GitHub

timvideos/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - timvideos/litex-buildenv

GitHub

antmicro/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - antmicro/litex-buildenv

[mateusz-holenko]

This PR together with #176 and #179 contain all the changes necessary for the tutorial.

I created a separate branch on antmicro's fork that combines all those changes into a single branch that can be used right away: https://github.com/antmicro/litex-buildenv/tree/riscv_linux.

GitHub

antmicro/litex-buildenv

An environment for building LiteX based FPGA designs. Makes it easy to get everything you need! - antmicro/litex-buildenv

[mithro]

This seems to be failing with;

Checking out files: 100% (63135/63135), done.
HEAD is now at 1c163f4c7b3f Linux 5.0
Downloading LiteX devicetree code.
Cloning into '/home/travis/build/timvideos/litex-buildenv/third_party/litex-devicetree'...
remote: Enumerating objects: 23, done.
remote: Total 23 (delta 0), reused 0 (delta 0), pack-reused 23
Receiving objects: 100% (23/23), 11.01 KiB | 490.00 KiB/s, done.
Resolving deltas: 100% (8/8), done.
grep: build/arty_net_vexriscv.linux//software/include/generated/mem.h: No such file or directory
grep: build/arty_net_vexriscv.linux//software/include/generated/mem.h: No such file or directory
grep: build/arty_net_vexriscv.linux//software/include/generated/mem.h: No such file or directory
./scripts/build-linux.sh: line 164: -1: substring expression < 0

[mateusz-holenko]

I can't reproduce it on my local machine. Thebuild firmware command should execute if no configuration (and thus mem.h) is generated before executing line 164 of build-linux.sh.

I added some debug logs to the script and triggered CI again to see what's going on.

[mateusz-holenko]

I now see what was going on. The test script does the initial build of the platform followed by make firmware-clean before running build-linux.sh.

As a result of cleaning the firmware the build/arty_net_vexriscv.linux//software directory (containing generated mem.h file) is removed, but test/csr.csv is not. I was wrongly assuming that they both should be in sync and exist together.

I changed the script to test for the existence of mem.h, as this is the important file from the script's perspective.

[mithro]

@mateusz-holenko test/csr.csv is generated in the make gateware step.

[mithro]

LGTM! Merging....