<hansfbaier>
sajattack[m]: in the build dir then there are driver/kernel which contains the kernel module (which you have to insert) and driver/user there is a tool to access the kernel driver
<sajattack[m]>
Ok
<hansfbaier>
sajattack[m]: also, you might want to reboot the PC after flashin
<frubbl>
nats: The nmigen example is superset of using verilog code
<nats`>
thanks I'm applying it
<nats`>
maybe a stupid question, but is there a documentation somewhere on how to choose the soc ?
<frubbl>
nats: You mean the base class? Well I just looked at the code, what the features the different base classes have and picked the one that comes closest to what I need.
<nats`>
I mean using other soc like vexrisc or other (I'm a total beginner with this kind of workflow)
<frubbl>
nats: You mean which processor core?
<frubbl>
If you want the smallest possible core (slow!) use serv
<frubbl>
If you want something space efficient which can run linux, use vexriscv
<frubbl>
If you want an embedded core for bare metal, choose picorv32
<frubbl>
If you want a PowerPC core, use microwatt
<frubbl>
If you want a very space efficient core which can run linux, use mor1kx (OpenRISC architecture)
<frubbl>
If you want a RISC-V core for embedded which is written in nmigen, use minerva
<frubbl>
If you want a super powerful RISCV core which runs linux choose Rocket
<frubbl>
If you are nostalgic and like obsolete FPGA vendor softcores, use lm32
<frubbl>
nats: But most of the time you'd probably want vexriscv, that's why it is default
<nats`>
ah so SoCCore is a vexrisc ?
<nats`>
I'm browsing the source I'm lost sorry
rozpruwacz1 has joined #litex
<frubbl>
No SocCore is the a base class other SoC s are built on. VexRiscV is the CPU core
<frubbl>
IIRC
<frubbl>
It's quite a learning curve, that's for sure, but Python code is very well written and well worth the read
<frubbl>
s/Python/the Python/
<frubbl>
I learnt a ton reading _florent_'s code and I still do
<frubbl>
nats` ^
<frubbl>
It's some of the best code I've ever seen
<nats`>
I'm diving in right now :)
<nats`>
uhhmm I think I found it " cpu_type = "vexriscv"," in soc_core.py
<nats`>
maybe it worth using an integration for an ide because it's a long dive when you use sublime text and grep :D
<frubbl>
nats`, yes the cpu_type is an argument to the SoC
<frubbl>
Great you found it out!
<frubbl>
way to go!
<nats`>
vscode is cool, just loading the code is enough to get the navigation through source
RaivisR has quit [Ping timeout: 260 seconds]
<frubbl>
nats` Yes it is awesome
frubbl has quit [Quit: Connection closed]
RaivisR has joined #litex
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
rozpruwacz1 has quit [Quit: Leaving.]
Bertl_zZ is now known as Bertl
pepijndevos_ has joined #litex
kgugala has quit [*.net *.split]
pepijndevos has quit [*.net *.split]
<_florent_>
nats`: just for info, in the long term, I would like the SoCs to be only based on SoC or LiteXSoC (from soc.py) and completely remove soc_core.py and soc_sdram.py, but for retro-compatibility reasons, soc_code/soc_sdram are still there and mostly wrapping things around soc.py
<_florent_>
nats`: so the interesting parts are in soc.py
<_florent_>
Otherwise, VexRiscv is the default CPU (because probably the more polyvalent) but you can change it with --cpu-type on your target or cpu_type parameter on SoCCore
<acathla>
_florent_, shouldn't you write that somewhere, like directly in the files?
<_florent_>
that was also in SoCCore, but I remove it since we are still using SoCCore in the targets and was not sure it would be confusing or not
<acathla>
ok
<_florent_>
I'll add it back when all the targets will be adapted to use LiteXSoC
<_florent_>
and I'll then hide soc_core/soc_sdram somewhere in the codebase to still allow it to be used but not encourage it :)
kgugala has joined #litex
<nats`>
_florent_, I'm making note about everything causing me trouble as a newcomer
<nats`>
maybe it can be helpful to indicate some documentation work or something like that
<keesj>
nats`: I am also using vscode and recently starting using devcontainers (docker stuff) I can now clone my repo and the docker container will build all I need (yosys from source) and then clone litex
<keesj>
(to be fair.. I also have tmux and vim and such installed and .. use the terminal a lot). for the flashing I still have some tools outside of the container but with lxserver I might be able to do additional magic
<keesj>
stuff keeps slowly changing and my personal progress is slow here.
<keesj>
this week-end I hope to just get the default tinyfpga_bx working with the risc core. it currently is not working for me but I don't know why.
keesj has quit [Remote host closed the connection]
keesj has joined #litex
<keesj>
so the address where the bios is storred in the flash of the BX is a bit .. weird it at the end of the program partition while the programming tools so flashing it is not trivial unless I am missing something
<keesj>
this is the layout https://pastebin.com/tzf1q65Y "default" the "user image" if the bitstream , I modified the code to store the bios in the userdata and flashed that that that .. works but I wonder how this was intented to work. perhaps I am missing a step where the bios gets appended to the bitstream