<tpb>
Title: GitHub - skiphansen/panog2_linux: Prebuilt images for Linux for the Pano Logic G2 (at github.com)
<john_k[m]>
the VexRISCV SMP email is exciting
<john_k[m]>
is there info anywhere on how to use buildroot to compile the kernel / rootfs for linux-on-litex-vexriscv?
<john_k[m]>
I tried the typical buildroot `make BR2_EXTERNAL=/home/dev/Code/linux-on-litex-vexriscv/buildroot/ menuconfig` but it doesn't pick anything up, I see BR2_EXTERNAL_LITEX_VEXRISCV_PATH mentioned in external.mk but it's not obvious where that should point to as `package` directory doesn't exist in the linux-on-litex-vexriscv dir
<john_k[m]>
ah setting it also to the same dir and then manually loading the vexriscv defconfig works, needed to also manually create a .config symlink after the menuconfig
<john_k[m]>
if someone could sanity check how I'm invoking that, i'll issue a PR to the readme
CarlFK has joined #litex
<Skip>
mithro: No I hadn't noticed Charle's VexRISCV SMP ... my mind was blown enough with one processor!
shuffle2 has joined #litex
<mithro>
john_k[m]: Sending a PR to the readme would be great!
<mithro>
Skip: With how huge the panologic FPGA is, the issue is almost certainly going to be memory bandwidth
<shuffle2>
i'd like to use liteEth on lattice, and uart, whereever that lives. but i'm on windows, and dont really want to run the litex_setup.py script...is there a less hueg/gross way to use this subset? i've already used migen for other stuff, just not litex
<mithro>
We could probably do like a 32 way complex pretty easily
<Skip>
mithro: and 1/2 of the SDRAM isn't be used yet...
<mithro>
Skip: kgugala was working on that
<Skip>
Cool!
<mithro>
shuffle2: You can just use them like any other Python module, but you need to make sure to update everything when you do
<john_k[m]>
mithro: oh? interesting!
<mithro>
shuffle2: A virtualenv and litex_setup.py works pretty well
<tpb>
Title: Linux · timvideos/litex-buildenv Wiki · GitHub (at github.com)
<john_k[m]>
I'll have to hook my Pano2 back up once I'm done with some ULX3s work
<john_k[m]>
looks like some great progress has been mad
<john_k[m]>
* looks like some great progress has been made
<zyp>
shuffle2, you could also just add them to pythonpath and import them as is
<zyp>
I have a deps/ directory with migen, litex and the other lite* repos checked out as git submodules and an __init__.py that reads like this: https://paste.jvnv.net/view/Fp5KI
<scanakci>
@sajattack[m] : I do not have any experience with vexriscv. Once I boot up Linux on FPGA, I will try to compare BP with Rocket and potentially Vex.
<scanakci>
I also printed the opcode (msr_read(mbadaddr)) which is adba2acf. Not sure where this opcode comes from. I printed the memory starting from 0x8000_0000 until end of bbl in trap function. It seems legit (i.e. matches with bbl dump and does not contain weird opcode)
<sorear>
missing a fence.i somewhere and reading garbage from the i$?
<scanakci>
This guy had a similar issue. He noticed that bss area was not clear before the boot-up. bss size looks 0 byte in my case so I do not think this is the problem. However, it tells me that illegal instruction trap may be misleading here.
<daveshah>
Does it fail exactly the same way each time?
<scanakci>
@daveshah yes it is deterministic
<scanakci>
@sorear would not it cause issues on Simulation too?
<sorear>
you mean spike/etc or verilator/etc?
<scanakci>
verilator
<daveshah>
Deterministic is good, that significantly reduces the likelihood that its something like marginal DDR3 or timing
<sorear>
maybe change something unrelated in a lower-address function to perturb the addresses, and see what changes?
<scanakci>
will give it a shot
acathla has quit [Read error: Connection reset by peer]