| *** tpb has joined #litex | 00:00 | |
| nickoe | maybe I am mixing up the soc clases | 00:06 |
|---|---|---|
| *** lf has quit IRC | 00:36 | |
| *** lf has joined #litex | 00:36 | |
| *** futarisIRCcloud has quit IRC | 01:39 | |
| *** Bertl_oO is now known as Bertl_zZ | 01:46 | |
| *** Degi_ has joined #litex | 03:30 | |
| *** Degi has quit IRC | 03:30 | |
| *** Degi_ is now known as Degi | 03:30 | |
| *** futarisIRCcloud has joined #litex | 04:46 | |
| *** _whitelogger has quit IRC | 05:00 | |
| *** _whitelogger has joined #litex | 05:02 | |
| *** FFY00 has quit IRC | 05:16 | |
| *** kgugala_ has joined #litex | 06:54 | |
| *** kgugala has quit IRC | 06:57 | |
| *** kgugala has joined #litex | 07:07 | |
| *** kgugala_ has quit IRC | 07:10 | |
| *** Bertl_zZ is now known as Bertl | 10:27 | |
| *** dayjaby has joined #litex | 11:22 | |
| 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? | 11:43 |
| dayjaby | NuttX requires CLINT for some time-related stuff like "sleep 5". Does VexRISCV offer any other interrupts to handle this? | 11:43 |
| *** kgugala_ has joined #litex | 12:03 | |
| *** kgugala has quit IRC | 12:07 | |
| *** Melkhior has joined #litex | 12:31 | |
| 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 | 12:56 |
| 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. | 12:56 |
| Melkhior | So I'm trying to rebuild buildroot with a cross-g++ so I can use that directly instead of the SiFive toolchain... | 12:56 |
| *** Bertl is now known as Bertl_oO | 13:03 | |
| geertu | Melkhior: correct, RV32 should only use the new 64-bit time syscalls | 13:06 |
| *** dayjaby has quit IRC | 13:38 | |
| *** Melkhior has quit IRC | 13:38 | |
| *** Melkhior has joined #litex | 13:44 | |
| *** Zguig has joined #litex | 14:03 | |
| *** futarisIRCcloud has quit IRC | 14:39 | |
| *** FFY00 has joined #litex | 14:54 | |
| *** kgugala_ has quit IRC | 15:20 | |
| *** kgugala has joined #litex | 15:20 | |
| Melkhior | Yep, seems switching to the C++-enabled version of the buildroot toolchain solved my problem, now my (new) binaries work | 15:23 |
| Melkhior | ... at least the ones I tried :-) | 15:23 |
| Melkhior | @ius I've been running my tests of B/Zkne/Zknh on dual-core VexRiscV, never saw a userland error like you see... | 15:31 |
| Melkhior | I'm running 6 copies of an AES benchmark on 2 cores ATM, so far so good no issue... | 15:31 |
| Melkhior | they are not memory-intensive though, probably always run in-L1$ | 15:32 |
| *** dayjaby has joined #litex | 15:58 | |
| mithro | _florent_: I think we can just merge https://github.com/litex-hub/pythondata-auto/pull/7 and continue to iterate further | 16:06 |
| *** lkcl has quit IRC | 16:24 | |
| _florent_ | mithro: yes I agree | 16:33 |
| mithro | _florent_: Sorry I didn't do it sooner | 16:33 |
| _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... | 16:35 |
| *** lkcl has joined #litex | 16:37 | |
| *** dayjaby has quit IRC | 17:22 | |
| *** Melkhior has quit IRC | 17:31 | |
| *** Zguig has quit IRC | 17:40 | |
| 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 | 18:14 |
| somlo | 1. it appears I can't type to the bios prompt over the jtag console | 18:15 |
| 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" | 18:15 |
| 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 :) | 18:16 |
| 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... | 18:23 |
| _florent_ | somlo: I did a fix to jtagbone today: https://github.com/enjoy-digital/litex/commit/4d1deffbb037fc3cda4756d5d90432e3ea69f5dc but haven't tested yet in console mode. You can maybe try to revert this one. | 18:46 |
| *** tpb has joined #litex | 18:51 | |
| 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 | 18:51 |
| somlo | in that case, I should try *adopting* it (I am using two-day-old versions of litex_[server|client|term] and litescope_client) | 18:52 |
| *** kgugala has quit IRC | 18:52 | |
| *** kgugala has joined #litex | 18:53 | |
| 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) | 18:56 |
| somlo | lots of moving parts :) | 18:56 |
| 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 | 19:16 |
| somlo | killing that will allow me to program the board once again | 19:18 |
| 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 | 19:22 |
| 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 | 19:23 |
| somlo | is there a command line argument to litex_term that would control this behavior, or do I need to revert 4d1deffb for now? | 19:24 |
| 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 :) | 19:30 |
| 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) | 19:35 |
| somlo | that is true whether I use pre- or post- 4d1deffb litex_term | 19:35 |
| 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) | 19:36 |
| 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. | 19:37 |
| nickoe | mithro: So I added this and it seem to work, https://github.com/timvideos/litex-buildenv/compare/master...nickoe:mars_ax3 except for the platform.reqest_all in https://github.com/timvideos/litex-buildenv/compare/master...nickoe:mars_ax3#diff-b22d2c876f42c0b5738e4268ab3b1e000977b05c7b175ce2cb8470f153942e1bR104-R108 | 20:30 |
| nickoe | I can't figure out why, but maybe the "platform" object is missing something? | 20:31 |
| 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. | 20:32 |
| 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 | 21:51 |
| nickoe | shorne: can't you just use https://github.com/enjoy-digital/litesdcard ? | 22:30 |
| somlo | nickoe: that's the "gateware" (a.k.a. "hardware); there's a linux driver that talks to it from the kernel side of things | 22:35 |
| nickoe | somlo: there are some software for it here, I think. https://github.com/enjoy-digital/litex/tree/master/litex/soc/software/liblitesdcard | 22:38 |
| 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 | 22:39 |
| somlo | increasing the cmd and data timeouts (i.e., appending ", cmd_timeout=10e-1, data_timeout=10e-1" here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc.py#L1483 seems to help | 22:40 |
| 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 :) | 22:41 |
| somlo | nickoe: ^^ | 22:43 |
| nickoe | somlo: ok, I don't really know too much about it, I was just looking at trying to add sdcard to my project. | 22:44 |
| 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 | 22:45 |
| 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. | 22:45 |
| nickoe | somlo: it looks like those "arguments" only exist for the targets in litex-boards? | 22:46 |
| nickoe | and not the stuff in litex-buildenv | 22:46 |
| nickoe | somlo: this is my platform https://github.com/timvideos/litex-buildenv/compare/master...nickoe:mars_ax3 | 22:47 |
| 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 | 22:47 |
| somlo | very simplistic thing for me to say, but that's about as much as I know right now :) | 22:47 |
| 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. | 22:47 |
| nickoe | somlo: ok, I don't really intend to run linux on this, just some simple firmware. | 22:48 |
| 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 | 22:48 |
| nickoe | But the point is, litex-buildenv does not use litex-boards | 22:49 |
| somlo | nickoe: then you should be ok with the bios (sdcard driver code in litex/soc/software/litblitesdcard) | 22:49 |
| nickoe | or it may do, but an old one, I dunno. It appears to be slightly messy all in all. | 22:49 |
| 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) :) | 22:49 |
| nickoe | yeah, that is what I have done until now | 22:51 |
| nickoe | ugh riscv64-unknown-elf-ld: region `rom' overflowed by 6460 bytes | 22:53 |
| nickoe | when I added the self.add_spi_sdcard() | 22:53 |
| 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 | 22:53 |
| somlo | some boards' sdcard readers have dedicated cd signals, some don't | 22:53 |
| nickoe | yeah, I know the hardware, but I am just not familiar with the migen/litex module api | 22:54 |
| 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) | 22:56 |
| somlo | *integrated :) | 22:56 |
| nickoe | somlo: yes, there is this https://github.com/nickoe/litex-buildenv/blob/mars_ax3/targets/mars_ax3/base.py#L26-L30 | 22:57 |
| nickoe | I am just trying to figure out how to interpret that properly. | 22:57 |
| nickoe | I don't reall know the difference between the different cpu types :S | 22:59 |
| somlo | well, something is going to instantiate a BaseSoC and then pass it on to an instance of Builder (see for example https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/nexys4ddr.py#L136) | 22:59 |
| somlo | that something will have a bunch of arguments that it will pass in, including the size of the rom, the cpu model, etc. | 23:00 |
| 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. | 23:01 |
| nickoe | anyway, I just tried to select that mor1kx cpu instead | 23:02 |
| 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 | 23:03 |
| zyp | lm32 is not risc-v | 23:04 |
| somlo | there you go, I said I don't know :D | 23:04 |
| zyp | but there's a couple other risc-v options though | 23:04 |
| nickoe | I still have not really found how to run own firmware projects on it | 23:04 |
| nickoe | I mean, I have not really tried that hard yet. | 23:05 |
| zyp | just load it and run? | 23:05 |
| 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 :) | 23:06 |
| nickoe | yeah, well, sure. | 23:06 |
| nickoe | zyp: is there a way to test if the SD card works? | 23:06 |
| zyp | I've had custom baremetal code running on vexriscv, IIRC I just fed the binary to the loader-function in litex_term | 23:06 |
| zyp | haven't tried SD card | 23:06 |
| nickoe | what about regular flash? | 23:06 |
| zyp | haven't tried that either :) | 23:07 |
| 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) | 23:07 |
| zyp | yeah, I eventually wanna do that too | 23:07 |
| zyp | maybe | 23:07 |
| zyp | on the other hand I want to be able to change it without changing the bitstream :) | 23:07 |
| 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 | 23:08 |
| zyp | yeah | 23:08 |
| somlo | zyp: agree on "rapid prototyping" -- waiting for the bistream to rebuild just for a small software/bios change is wasting lots of time :) | 23:08 |
| zyp | I'm pretty sure I can figure out how, I just haven't had time yet :) | 23:08 |
| somlo | zyp: "It's a simple matter of programming!" :D | 23:09 |
| 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 | 23:09 |
| somlo | zyp: congrats on the new gig! | 23:09 |
| zyp | thanks :) | 23:09 |
| nickoe | zyp: What are you going to do? | 23:11 |
| zyp | embedded stuff, both software and hardware, probably mostly software | 23:11 |
| nickoe | is there a way to see the generated memory map? | 23:12 |
| zyp | csr.csv? | 23:12 |
| nickoe | ah, cool | 23:14 |
| nickoe | By the way, how do you make a custom register that one can just write to via sw? | 23:15 |
| zyp | just write to, as in write only? | 23:16 |
| nickoe | yeah, but also read if possible | 23:16 |
| nickoe | This should be SDRAM, dos this look right? https://dpaste.com/5P8U8YEMB | 23:17 |
| tpb | Title: dpaste: 5P8U8YEMB (at dpaste.com) | 23:17 |
| zyp | no | 23:18 |
| nickoe | if I write a four byte hex, https://dpaste.com/HRB72SXUZ | 23:18 |
| tpb | Title: dpaste: HRB72SXUZ (at dpaste.com) | 23:18 |
| zyp | wait, which cpu is this? looks big endian | 23:19 |
| zyp | if it's big endian then it's correct, just confusing the way the last argument is a number of bytes, while it writes words | 23:20 |
| nickoe | zyp: https://dpaste.com/7QHSRXLC5 | 23:21 |
| tpb | Title: dpaste: 7QHSRXLC5 (at dpaste.com) | 23:21 |
| zyp | ah, right, mor1kx is big endian | 23:21 |
| zyp | risc-v is little endian | 23:22 |
| nickoe | right | 23:22 |
| zyp | so you should see the opposite order if you do the same on a little endian cpu | 23:22 |
| nickoe | ok | 23:23 |
| *** FFY00 has quit IRC | 23:24 | |
| *** FFY00 has joined #litex | 23:25 | |
| nickoe | zyp: to me it does not look like the flash works properly? https://dpaste.com/2VNYBXCHU | 23:25 |
| tpb | Title: dpaste: 2VNYBXCHU (at dpaste.com) | 23:25 |
| zyp | not sure how this particular flash controller works, but generally you can't just write to flash like that | 23:27 |
| nickoe | mm, how can I write to flash from the bios then? | 23:27 |
| zyp | dunno, have you checked help if it has any particular commands? :) | 23:28 |
| nickoe | yes, there are nothin else, as far as I can see. | 23:29 |
| nickoe | https://dpaste.com/5RBH5M67D | 23:29 |
| tpb | Title: dpaste: 5RBH5M67D (at dpaste.com) | 23:29 |
| zyp | what's that on line 24? :) | 23:30 |
| nickoe | ugh | 23:31 |
| nickoe | I wonder what interface to the flash it uses, 1x or 4x spi? | 23:34 |
| nickoe | both are defined | 23:34 |
| nickoe | ah, def __init__(self, platform, spiflash="spiflash_1x", **kwargs): ? | 23:35 |
| nickoe | and https://github.com/nickoe/litex-buildenv/blob/mars_ax3/targets/mars_ax3/base.py#L68-L99 | 23:35 |
| nickoe | I wonder what that "spiflash_dummy" .. is | 23:35 |
| nickoe | oh right, so fewrites ff's https://dpaste.com/86NNM4CAK | 23:36 |
| tpb | Title: dpaste: 86NNM4CAK (at dpaste.com) | 23:36 |
| nickoe | zyp: It is not quite working as expected, https://dpaste.com/4MX5Q6DRU | 23:37 |
| tpb | Title: dpaste: 4MX5Q6DRU (at dpaste.com) | 23:37 |
| nickoe | but there are also a couple of parameters that I have not double checked, although I beleive they are correct as is https://github.com/nickoe/litex-buildenv/blob/mars_ax3/platforms/mars_ax3.py#L102-L113 | 23:40 |
| nickoe | zyp: the sdcard does not seem to be memory mapped, so I can't really test that easily from the bios? https://dpaste.com/FYCTH458B | 23:48 |
| tpb | Title: dpaste: FYCTH458B (at dpaste.com) | 23:48 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!