futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Bertl_oO is now known as Bertl_zZ
Degi_ has joined #litex
Degi has quit [Ping timeout: 264 seconds]
Degi_ is now known as Degi
futarisIRCcloud has joined #litex
_whitelogger has joined #litex
FFY00 has quit [Remote host closed the connection]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 240 seconds]
Bertl_zZ is now known as Bertl
dayjaby has joined #litex
<dayjaby>
Hello everyone o/ currently trying to run NuttX on a Litex/VexRISCV cpu, but NuttX requires CLINT support, which seems to be available only in VexRISCV SMP. Is it possible for a common human like me to implement it in VexRISCV?
<dayjaby>
NuttX requires CLINT for some time-related stuff like "sleep 5". Does VexRISCV offer any other interrupts to handle this?
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 272 seconds]
Melkhior has joined #litex
<Melkhior>
hello; following on yesterday's problem - gettimeofday() not working - seems that I ran into a 'known issue': there was a Linux ABI change at some point, the kernel for RV32 no longer define __ARCH_WANT_TIME32_SYSCALLS, so syscall 169 (gettimeofday) isn't there anymore. But that's still what is used by the SiFive binary toolchain I was using (it
<Melkhior>
has g++) and that creates static binaries... That's likely what caused my problems - seems gettimeofday inside buildroot is using the 64 bits version (syscall 403) instead.
<Melkhior>
So I'm trying to rebuild buildroot with a cross-g++ so I can use that directly instead of the SiFive toolchain...
Bertl is now known as Bertl_oO
<geertu>
Melkhior: correct, RV32 should only use the new 64-bit time syscalls
dayjaby has quit [Quit: Ping timeout (120 seconds)]
Melkhior has quit [Quit: Ping timeout (120 seconds)]
Melkhior has joined #litex
Zguig has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
FFY00 has joined #litex
kgugala_ has quit [Quit: -a- Connection Timed Out]
kgugala has joined #litex
<Melkhior>
Yep, seems switching to the C++-enabled version of the buildroot toolchain solved my problem, now my (new) binaries work
<Melkhior>
... at least the ones I tried :-)
<Melkhior>
@ius I've been running my tests of B/Zkne/Zknh on dual-core VexRiscV, never saw a userland error like you see...
<Melkhior>
I'm running 6 copies of an AES benchmark on 2 cores ATM, so far so good no issue...
<Melkhior>
they are not memory-intensive though, probably always run in-L1$
<_florent_>
mithro: no problem, it takes time to convert the different CI to Github Actions... and the Travis-CI breakage was a bit un-expected...
lkcl has joined #litex
dayjaby has quit [Quit: Connection closed]
Melkhior has quit [Quit: Connection closed]
Zguig has quit [Quit: Connection closed]
<somlo>
_florent_: trying to switch back to using uartbone and console-over-jtag, and unsure if things changed in a small way or I started doing something wrong
<somlo>
1. it appears I can't type to the bios prompt over the jtag console
<somlo>
2. after I disconnect from the jtag console (hit double-ctrl-c in litex_term), I can no longer program the bitstream with openocd: I get "Error: couldn't bind gdb to socket: Address already in use"
<somlo>
I'll try backing out of a few of the latest commits and retry, then try to bisect (unless you pre-empt me by figuring out what actually happened based only on the above symptoms :)
<somlo>
need to figure out how to recover from #2 without having to reboot my host computer :) Otherwise it'll be a very slow debug process...
<somlo>
_florent_: thanks, I'm building with reverted 4d1deffb, will report back if that changes things
<_florent_>
somlo: that's only software changes, so no need to rebuild :)
<somlo>
oh, it only changes litex_term ?
tpb has quit [Disconnected by services]
tpb has joined #litex
<somlo>
or whatever, the server/client software side of the jtag link (i.e. nothing that would go into the bios or gateware) -- I get it
<somlo>
in that case, I should try *adopting* it (I am using two-day-old versions of litex_[server|client|term] and litescope_client)
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<somlo>
but in that case there should be some bios/gateware changes that made pre-4d1deffb server|client|terminal *stop* working (from a week or so ago, when I was using them, pre-jtagbone)
<somlo>
lots of moving parts :)
<somlo>
anyway, litex_term leaves behind an openocd program running in the background, which then prevents new instances from being used explicitly from the cmdline to program the board
<somlo>
killing that will allow me to program the board once again
<somlo>
_florent_ : not exactly sure about #1 (not being able to type to the bios prompt) -- maybe that was a lingering side effect of having multiple openocd instances fighting over the same jtag serial link
<somlo>
but difference between yesteday and today's litex_term is that today's version inserts a \n after each keypress, making it impossible to type commands into the bios prompt
<somlo>
is there a command line argument to litex_term that would control this behavior, or do I need to revert 4d1deffb for now?
<somlo>
_florent_: I guess it has something to do with the new `binary_mode` flag, and how it should probably stay false when the jtag is used for tunneling console traffic? Not quite familiar with how all that hangs together :)
<somlo>
_florent_: final conclusion: after programming the nexys4ddr with openocd from the command line, then connecting via `litex_term jtag_uart`, I can't type to the bios prompt until I push the reset switch (not the *board* reset, just the *lite* reset)
<somlo>
that is true whether I use pre- or post- 4d1deffb litex_term
<somlo>
_florent_: also, post-4d1deffb is unusable right now, as it inserts a \n after each character typed at the prompt, preventing any multi-character command from being issued (the `binary_mode` thing, most likely)
<somlo>
so I'm able to get stuff done on my end for now. Happy to test any fixup over 4d1deffb you might want to try out.
<nickoe>
I can't figure out why, but maybe the "platform" object is missing something?
<nickoe>
But it looked like if I renamed my user_led's to something else and used that in the comb code (not request_all, but just request) then it built fine.
<shorne>
somlo: I ordered an sdcard pmod for my arty development board, I see you are working on the litex_mmc driver recently. I'll be testing it soon
<somlo>
shorne: in the (linux) driver's current state (in the litex-rebase branch of litex-hub/linux) I get frequent data timeouts during (single-block/cmd17 only) transfers
<somlo>
enabling multi-block transfers results in read errors at the moment, and I'm looking for a few days of relative peace and quiet at $DAYJOB to properly attempt to track down where (likely in the gateware state machines) things get stuck. Additionall fun provided by the fact that multi-block transfers work fine in the bios, just not in Linux :)
<somlo>
nickoe: ^^
<nickoe>
somlo: ok, I don't really know too much about it, I was just looking at trying to add sdcard to my project.
<somlo>
nickoe: if your target supports it, add `--with-sdcard` to your build command line, then you should get the bios functionality automatically, and should be able to boot from the sdcard
<nickoe>
somlo: I just added the pin definitions, but -- I use litex-buildenv, and that appears to be a bit out of data to all the other litex stuff, so now I am just considering what to do next. Just updating litex in the thirdparty dir gives other errors when making gateware.
<nickoe>
somlo: it looks like those "arguments" only exist for the targets in litex-boards?
<somlo>
once you boot a kernel (e.g. linux), it will want to use its own drivers to talk to the hardware, rather than whatever exists in the bios. Right now I've been staring at the linux driver for hours, and can't see anything it does that's fundamentally different from the bios, so I suspect timing related issues (bios is bare-metal with no competition, linux will be doing "other things" interleaved with tickling the sdcard gateware) -- this is obviously a
<somlo>
very simplistic thing for me to say, but that's about as much as I know right now :)
<nickoe>
I was also trying to understan if there was support for a card detect pin, but it appears that one "misuses" a dat signal for that.
<nickoe>
somlo: ok, I don't really intend to run linux on this, just some simple firmware.
<somlo>
nickoe: right, litex-boards has arguments for boards that are known to have an sdcard reader soldered on, or sometimes have pins for one of the "well known" pmod sockets where one would plug in a pmod sdcard reader
<nickoe>
But the point is, litex-buildenv does not use litex-boards
<somlo>
nickoe: then you should be ok with the bios (sdcard driver code in litex/soc/software/litblitesdcard)
<nickoe>
or it may do, but an old one, I dunno. It appears to be slightly messy all in all.
<somlo>
nickoe: I don't know much about litex-buildenv -- the generic (and probably next-to-useless) advice is "dig around in litex-boards, and cut'n'paste whatever makes sense into your design) :)
<nickoe>
yeah, that is what I have done until now
<nickoe>
ugh riscv64-unknown-elf-ld: region `rom' overflowed by 6460 bytes
<nickoe>
when I added the self.add_spi_sdcard()
<somlo>
nickoe: re. card-detect, I think a pmod based sdcard reader will have a dedicated pin for that; otherwise, it depends on what the designer of your specific board did when they, well, designed the board
<somlo>
some boards' sdcard readers have dedicated cd signals, some don't
<nickoe>
yeah, I know the hardware, but I am just not familiar with the migen/litex module api
<somlo>
nickoe: I assume you've already heard about the `--ingetraged-rom-size` argument? Again, modulo how things are done in litex-buildenv, I have found I need to set that to 0x10000 to fit the entire bios (when building with ethernet and/or sdcard gateware)
<somlo>
that something will have a bunch of arguments that it will pass in, including the size of the rom, the cpu model, etc.
<nickoe>
yeah, but the litex stuff from august did not have that as far as I can see, hence the litex-buildenv stuff does not have it as args.
<nickoe>
anyway, I just tried to select that mor1kx cpu instead
<somlo>
Not sure about tradeoffs between cpu models -- I need rv64gc, whic at the moment is Rocket; the other popular choice for linux-capable is vexriscv; if you need simple, there's lm32 and pico4v32 for risc-v, and a bunch of other stuff that implements other ISAs (mor1kx, microwatt, etc) that I'm *really* not familiar with at all
<zyp>
lm32 is not risc-v
<somlo>
there you go, I said I don't know :D
<zyp>
but there's a couple other risc-v options though
<nickoe>
I still have not really found how to run own firmware projects on it
<nickoe>
I mean, I have not really tried that hard yet.
<zyp>
just load it and run?
<somlo>
might look through "git log" for the "ascii donut" -- I remember _florent_ added an example on "how to run bare-metal stuff on LiteX" -- again, I'm very fuzzy on the details :)
<nickoe>
yeah, well, sure.
<nickoe>
zyp: is there a way to test if the SD card works?
<zyp>
I've had custom baremetal code running on vexriscv, IIRC I just fed the binary to the loader-function in litex_term
<zyp>
haven't tried SD card
<nickoe>
what about regular flash?
<zyp>
haven't tried that either :)
<somlo>
zyp: maybe the goal is to have the bare-metal program built into the bitstream (i.e., in addition to or instead of the bios)
<zyp>
yeah, I eventually wanna do that too
<zyp>
maybe
<zyp>
on the other hand I want to be able to change it without changing the bitstream :)
<somlo>
nickoe, zyp: there's litex/soc/software/bios/main.c -- you can figure out where to add a call to your own C stuff from there, in case you want things built directly into the bios
<zyp>
yeah
<somlo>
zyp: agree on "rapid prototyping" -- waiting for the bistream to rebuild just for a small software/bios change is wasting lots of time :)
<zyp>
I'm pretty sure I can figure out how, I just haven't had time yet :)
<somlo>
zyp: "It's a simple matter of programming!" :D
<zyp>
got a bunch of other stuff I wanna do as well, and I just started a new job on monday so it's limited how much time I've got
<somlo>
zyp: congrats on the new gig!
<zyp>
thanks :)
<nickoe>
zyp: What are you going to do?
<zyp>
embedded stuff, both software and hardware, probably mostly software
<nickoe>
is there a way to see the generated memory map?
<zyp>
csr.csv?
<nickoe>
ah, cool
<nickoe>
By the way, how do you make a custom register that one can just write to via sw?