<jevinskie[m]>
What is the situation with Linux on LiteX and USB on the orangecrab? Do I only get a serial port? I’m wondering how I can get networking on the orangecrab Linux
<swetland>
daughterboard with an ethernet PHY? 10/100 shouldn't be too hard. Gbe might be hairy
<cr1901_>
I would run a ppp connection over serial to a Pi or something w/ Ethernet personally
<cr1901_>
but I'm a bit nuts
<jevinskie[m]>
<cr1901_> "I would run a ppp connection..." <- That sounds more like it for me, I’m trying to keep it over usb. I wonder if I can have two serial endpoints or present as two CDC devices one for ppp and one for kernel logging
FabM has joined #litex
FabM has joined #litex
FabM has quit [Changing host]
<swetland>
well if it's over usb you might as well do CDC Ethernet
<swetland>
it's pretty simple and you're then exchanging ethernet frames over usb
<swetland>
and should just look like another interface on the host you plug it into
<swetland>
likely far less painful and more plug'n'play than PPP
<tnt>
yeah, but iirc the default bitstream uses a pure CDC (like ... hw logic thing, risc-v sees it as a hw uart)
<swetland>
ah, I see
<tnt>
I wonder if you can use gadget cdc/serial as a console device on linux.
<tnt>
(not that there is any support for gadget driver for the OC but ...)
<tnt>
swetland: btw, I'm disappointed you didn't go for the full 16 CGA colors :D
<swetland>
I could not get the damn intensity bit wired up right
<tnt>
I think you'd pretty much have to make a LUT
<swetland>
I realized that not only are migens bit slices BACKWARDS from verilog, they're also *range exclusive* instead of *range inclusive*
<tnt>
Ah well yeah, they're python semantics.
<tnt>
I told you ... I hate it.
<swetland>
I am not a python fan and this experience is not changing that
<swetland>
In general the shape of migen/nmigen/amarath is nice but I really think a DSL instead of just re-using python with its quirks and goddamn syntatic whitespace would be a huge improvement
<swetland>
building a system inside python is like building build systems inside gnu make
<swetland>
you can make a nice build system but everyone looks and says "oh I know this, it's make!" and suddenly it all goes to hell ^^
<amstan>
I agree, reusing python dsl is quite poor if you need expressions and flow control. It works a lot better if your stuff is declarative only.
<amstan>
On the other hand it wouldn't be too hard to create a dsl and convert it to the amaranth internal datastructures
<swetland>
the other thing that's frustrating is you can occasionally end up deep in some python backtrace with no clear idea what caused it
<amstan>
i think that's fixable, the exceptions can be rewritten
<swetland>
so here's something that is proving nonobvious -- I'd like to reconfigure vecriscv in litex for main ram at 0x8000_0000, so that it's easier to compile code to run on both it and qemu
<swetland>
(I realize I can change qemu sources as well, but since I'm customizing the "soc" anyway...)
<tnt>
see lattice_crosslink_nx_evn.py as example and look at line 62
<swetland>
that almost gets me there. cores/vexriscv.py declares io region @80000000 size 80000000. editing that to @C0000000/40000000 at least has it building, but that's ugly
<tnt>
Oh yeah, you might have another propblen ...
<tnt>
the Vex scala code actually defines what is considered "IO" ( which influences cachine / mmu / ... ).
<swetland>
ahhhh I was afraid of that
<swetland>
on the plus side I've already figured out how to rebuild vexriscv from the scala
<swetland>
I'm using the "linux" variant which defines io as 256MB @ B000_0000, E000_0000, and F000_0000
<swetland>
well not that lucky
<swetland>
bios does start but serial download is blowing up
<tnt>
B0 is still conflict right
<tnt>
oh I guess depend how much ram you have.
<tnt>
why are you using the linux variant btw ?
<swetland>
only 32MB at 8000_0000, so plenty of room
<swetland>
I want a target with full U/S/M modes and a MMU
<tnt>
if you're trying to run linux, moving the ram is going to be a pain, the address is hardcoded at a bunch of places.
<swetland>
doing some "how to write an OS" workshops with some friends
<swetland>
definitely not planning on running linux.
<swetland>
but it is beginning to look like it'll be simpler to move the main ram region in Qemu (was just hoping to not have people have to build a modified qemu, but such is life)
<swetland>
I thought RISCV would be fun -- it's a "real" cpu, but not terribly complex, it runs fine in Qemu and on ECP5 platforms
<_florent_>
But I'm not familiar enough with VexRiscv internals to say
<davebee>
Got gdb connected to my vexriscv yesterday, thanks to tnt. I can breakpoint, but not step. But it was enough to let me work out why FreeRTOS wasn't running. Now it does, so I have an OS running on my CPU. Next : implement semaphores and queues.
<davebee>
My C++ library code uses std::atomic<>. Not sure if the vexriscv supports atomics. Where should I ask?
<tnt>
it depends on which vex variant you're using
<tnt>
only the 'linux' variant in litex is configuted for LR/SC + AMO operations.
<davebee>
okay, thanks. I'm using standard+debug. I'll take a look.
<davebee>
Atomics are really handy, but the library I'm using was targetted at an STM327xx which does support them. There is probably a software fix.
<davebee>
stm32f7xx
<tnt>
OTOH does std::atomic actually use the RISC-V atomic operations ?
<tnt>
I mean, usually you can do atomics without hw support just disabling interrupt ...
<zyp>
I think if you don't have atomic instructions, the compiler generates a software implementation that calls stubs that you can provide to disable interrupts
<zyp>
tnt, yeah, if available it does
kbeckmann1 is now known as kbeckmann
<xobs[m]>
tnt: It does, yes. Platforms that don't have arlmkxa just don't have that package.
<xobs[m]>
* It does, yes. Platforms that don't have atomics just don't have that package.
<xobs[m]>
The software fix is to bodge it in a machine mode handler.
<pepijndevos[m]>
On a board without a nice usb interface, what's the best way to work with it? I have a jtag thingy to program the fpga, but then on the ulx3s I'd use litex_term --kernel to serial boot my code, so would I need a uart thingy to do that?
<rowang077[m]>
pepijndevos: You can boot over ethernet yes or over UART. I have never done it though
<tnt>
xobs[m]: yeah, I know you can use machine mode emulation, but as zyp pointed out, I expected GCC and stdc++ to have sw only solutions ot that.
<tnt>
pepijndevos[m]: in theory with crossover uart and a xxxBone bridge you should be able to yes.
<pepijndevos[m]>
Does etherbone completely take over the phy, or can the SoC still do ethernet? Kinda the whole point of the colorlight board for me is the ethernet. On the other hand, if I can use etherbone to twiddle registers in my SoC such that I don't have to deal with ethernet at all... 🤔
<tnt>
IIUC they can both work at the same time.
<_florent_>
pepijndevos[m]: you can do both at the same time, but we don't yet have a add_xy method for it, you have to do it manually in your target file
<tpb>
Title: FSiC2022 - F-Si wiki (at wiki.f-si.org)
genpaku has joined #litex
<davebee>
thanks for the comments on atomics.
<cr1901_>
tnt: What's the difference between machine mode emulation and "gcc providing a stub for you to implement atomics"?
<cr1901_>
Re: "I expected GCC and stdc++ to have sw only solutions ot that."
<davebee>
I'm building with -march=rv32im ie no atomics. gcc creates calls to __atomic_fetch_add_4() and __atomic_fetch_sub_4(). I don't have these as Litex builds the newlib runtime and does nto include any C++ stuff. But I should be able to writes something.
davebee has quit [Quit: Leaving]
<_florent_>
mithro: not yet, I'll look
FabM has quit [Quit: Leaving]
<mithro>
It's in Paris which seems like your neck of the woods
<tnt>
cr1901_: machine mode emulation is basically you compile cod efor RV32IMA but you'd don't actually have Atomics instruction in hardware. The CPU traps as illegal instructions and you provide a "bios" that emulates them and then returns from the trap.
<tnt>
cr1901_: That's actually what I did to run linux on ice40 because the hw atomics were too big to fit.
<swetland>
What I've found is that I can move memory by adjusting soc/cores/cpu/vexriscv/core.py but all my various attempts to override things from radiona_ulx3s.py have failed
<swetland>
and the io region definitely needs to be adjusted (keeping the CSRs where they are but ensuring it doesn't overlap the higher memory window