<somlo>
_florent_: some additional data on `--read` and `--write` on the nexys4ddr: I rebuilt the bitstream with analyzer and etherbone, and both writes and reads (to the scratch register) work fine; particularly, I can see written values not only from the bios command line, but also read them back with 100% accuracy
<somlo>
so it's only when using jtagbone that reading registers is broken for me
<somlo>
haven't tried "classic" uartbone yet, might give that a shot too for completeness
<somlo>
_florent_: console-over-jtag, "classic" uartbone debugging also works fine for reading back register values via litex_client
<somlo>
hope that narrows down the list of possible places things are going south... I tried looking through the sources last night, but would need a *lot* more time until things start making sense, and right now is not a good time for me from a $DAYJOB perspective :)
<_florent_>
Thanks for the feedback somlo, I'll also do some tests on the nexys4ddr but I'm not able to spend too much time on it currently (jtagbone is working fine on the setup I'm currently using with Kintex7 + JTAG HS2 cable and I need to go further on other aspects of this project for now).
Melkhior has joined #litex
<Melkhior>
Dumb question, is linux-on-litex-vexxriscv expected to work with the latest version of VexRiscV (rather than the specific commit in pythondata-cpu-vexriscv-smp) ? I've updated it to the latest VexRisCV to update my patch for 3-operands & the whole of B, but while I can synthesize/boot/run synthetic test (to check the new instructions one by one),
<Melkhior>
my longer-running binaries never finish, even if they don't use my new instructions. They don't hang the hardware, they just hog cpu until I control-c them... it was working fine with the detached head that pythondata-cpu-vexriscv-smp originally used, so just wondering...
<_florent_>
Melkhior: I only tested personally with pythondata-cpu-vexriscv-smp so can't say, but I think pythondata-cpu-vexriscv-smp is based on the dev branch of VexRiscv, is it what you are using?
<Melkhior>
I'm inside pythondata-cpu-vexriscv-smp, but I've updated the VexRiscV in 'pythondata_cpu_vexriscv_smp/verilog/ext/VexRiscv' to the head of 'master', added my stuff, and used 'generate.py'
<Melkhior>
That got me updated verilog in pythondata_cpu_vexriscv_smp, with which I rebuilt the bitstream with 'linux-on-litex-vexriscv' 'make.py'
<Melkhior>
except for that weird 'stuff never seem to finish' behavior, everything else went smoothly...
<Melkhior>
Last time I was using stuff not up-to-date enough, now I seem to have gone too far the other way:-) (at first I didn't realize pythondata_cpu_vexriscv_smp was getting VexRiscV in using a specific commit...)
<Melkhior>
Anyway no big deal, but I'm curious as it's a really weird failure mode.
<somlo>
Melkhior: sounds like a job for `git bisect` :)
<Melkhior>
@somlo yes, but it will take a good chunk of forever as synthesizing the bitstream is not fast :-/
<Melkhior>
Fortunately it's the one case where the sd-card work so testing the bitstream is quick :-)
<somlo>
yeah, allegedly there's a way to script the test and "good|bad" feedback with git bisect - and one day I'll even gather up all my energy and try it out for myself...
<Melkhior>
Not sure I'll find the time so no promise :-/
<Melkhior>
yes i've used bisect before - cost me a power supply and an expensive one at that :-) (lots and lots of power cycle to figure out a bug in LInux on a PowerMac G5 Quad ; a couple boot after I got it figured out, loud 'bang', burnt odor, magic smoke escapes from the very specific 1kW power supply of the G5... grrrr)
<somlo>
I've seen that happen too (although on a "vanilla" power supply on a very old pentium I was trying to use for a benchmark)
<somlo>
if it's any consolation, the thing was probably on its last legs anyway...
<somlo>
probably an old capacitor
<geertu>
A former co-worker had that happen with one of the old small-refrigerator-sized Silicon Graphics machines, while he was kneeling near it. Caused him to shake a bit...
<geertu>
somlo: git bisect run /path/to/script
<geertu>
Usually I'm too lazy to write the script (which has to be perfect ;-)
<Melkhior>
@geertu yeah, I jumped in my chair too, must have been a big capa - and then I had to reboot some systems, as it took down the breaker as well...
<somlo>
geertu: yeah, for me it's always been a tradeoff between spending time perfecting the script and just brute-forcing through with manual good/bad feedback
<somlo>
but in bitstream build situations where it takes a few hours to get feedback for each attempt, it might be worth going for the fire-and-forget script-based feature. It also depends on how bisect-able the upstream repo is (how many "broken" commits there are for you to accidentally land on during bisect, where things don't work for reasons unrelated to what you're hunting for
<somlo>
getting to the bottom of all that is a soft bucket-list item of mine, but like you, I'm lazy, so it's going to take a while
<nickoe>
mmm, daveshah, I am not sure what requests that cpu reset signal, but I just added it on an unused pin. Now it starts to run vivado with make gateware, but it seems like it is not overly happy with some pin constraints.
<nickoe>
like "CRITICAL WARNING: [Common 17-69] Command failed: 'U13' is not a valid site or package pin name. [/.../litex-buildenv/build/mars_ax3_base_vexriscv/gateware/mars_ax3.xdc:5]"
<Melkhior>
I think I found my problem, it seems the timing functions in the code are broken. I expected the cycle counter (rdycle/rdcycleh) to be the culprit, but no, it's actually getttimeofday() !
<somlo>
Melkhior: a total shot in the dark, but any chance it's related to either timebase-frequency or clock-frequency in the DTS? :)
<somlo>
probably not, but since we were on that topic a few days ago...
Bertl is now known as Bertl_oO
<mithro>
_florent_: BTW We will be moving the conda packages from litex-hub organization to the hdl organization as they are now being used in a couple of contexts, not just with litex
<nickoe>
I have four user_led's defined in the platform.
Melkhior has joined #litex
<Melkhior>
@somlo I don't think so, gettimeofday() actually fails (once tested...) and errno is 38, "Invalid system call number", so I lean toward a configuration issue in the kernel/buildroot...
<Melkhior>
seems that whatever real-time mechanism is backing gettimeofday() is MIA ...
<daveshah>
this has strong "64 bit time_t" vibes but I can't point to a specific problem
<Melkhior>
perhaps
<Melkhior>
but this is the 'latest' buidlroot with Geert's v5.11 kernel, so both should be quite up-to-date and compatible...
<Melkhior>
maybe a configuration issue ?
<Melkhior>
could have messed that up when I upgraded buildroot/kernel...
<Melkhior>
anyway I'll try to track & report
<Melkhior>
thanks for the suggestions
<geertu>
Melkhior: does "sleep 1" in a shell return after 1s?
<nickoe>
OMG OMG OMG daveshah it booted to the litex bios, I can see that via serial. Soo, how can I test the flash and ram?
<daveshah>
The ram test should be automatic on boot if your target is supported properly
<daveshah>
*set up properly
<daveshah>
The flash I'm not so sure about as I've not used flash with litex before
<Melkhior>
@geeru yes it seems to work properly
<nickoe>
it completed a "fe" with "Flash erased"
<Melkhior>
@geertu sorry
<nickoe>
oh, there a sdrinit command
<Melkhior>
@geertu the 'sleep' is from busybox, dunno if it changes the implementation
<nickoe>
daveshah: I am not sure if the pattern seen in the middle for that read levelling is good or not, but https://i.snipboard.io/d1fOT2.jpg
<nickoe>
is there a way to generate a memory map over stuff i a litex soc easily?
<_florent_>
nickoe: the memtest is passing it seems, congrats :)
<nickoe>
I have no idea how much that tests, but I guess it is a good starting point.
<nickoe>
how can I test flash?
<_florent_>
if the spiflash is integrated, you can do mem_list to get the base address of the flash and then do a mem_read to verify the content
<mithro>
Litex-BuildEnv lags behind the current upstream version
<nickoe>
mithro: How much?
<nickoe>
Are there any docs about how to actually do firmware for it? I would like to try to just get a register that I can write a byte in and it will be reflected on some io pins.
<mithro>
nickoe: dunno at the moment, the Travis CI breakage hasn't been fixed
<mithro>
Look at the code in home/nickoe/litex_test/litex-buildenv/third_party/litex/litex/build/generic_platform.py around the ValueError
<nickoe>
it do seem to hit the value error at 224
<nickoe>
in def request_all(self, name):
<nickoe>
I still don't get why it fails. The code looks the same to the upstream litex as well.
<ius>
_florent_: have you seen any segfaults on linux/vexriscv-smp with n>1 cores? if i build acorn with 1 core everything is fine, if i build with 4 userspace executables crash quite often ( https://p.6core.net/p/uVYThfx2kr1AKdBpYHC5YiUN )
<ius>
fact that i have never seen the kernel itself crash makes me wonder whether its perhaps /not/ a hardware bug, but instead some smp-related issue in the kernel?
Melkhior has quit [Quit: Connection closed]
<_florent_>
ius: that's indeed possibly related to the updated kernel. I tested various configurations with a 5.10 kernel and haven't seen this crash, but not sure I tested n>1 with the 5.11 kernel.
<ius>
guess i could try an older kernel
<ius>
i was actually trying to debug something else: i tried to add a second serial port, but that doesn't seem to work either
<ius>
added the port to SoC, device tree, modifed kernel config (for some reason liteuart has a Kconfig-configurable limit) - device appears in /dev but it appears to be dead for rx/tx (if i poke the register with devmem2 it works, though)
<_florent_>
ius: this could be an issue in the driver, not sure we tested multiple instances of the same peripherals
<ius>
yes, i figured, so thats why im trying to get jtag working
dkozel has quit [Quit: WeeChat 1.9.1]
dkozel has joined #litex
<nickoe>
_florent_: Why can't I do self.comb += platform.request("user_led", 2).eq(1) ?
<nickoe>
I have four leds specified in the platform