| *** tpb has joined #litex | 00:00 | |
| *** lkcl has quit IRC | 00:07 | |
| *** lkcl has joined #litex | 00:20 | |
| *** Bertl_oO is now known as Bertl_zZ | 00:23 | |
| *** lf has quit IRC | 00:37 | |
| *** lf has joined #litex | 00:37 | |
| *** lkcl has quit IRC | 01:03 | |
| *** lkcl has joined #litex | 01:17 | |
| *** futarisIRCcloud has joined #litex | 01:40 | |
| *** benh has quit IRC | 01:56 | |
| *** benh has joined #litex | 01:57 | |
| *** lkcl has quit IRC | 02:04 | |
| *** lkcl has joined #litex | 02:18 | |
| *** Degi_ has joined #litex | 03:30 | |
| *** Degi has quit IRC | 03:32 | |
| *** Degi_ is now known as Degi | 03:32 | |
| *** awordnot has quit IRC | 05:24 | |
| *** awordnot has joined #litex | 05:58 | |
| *** lkcl has quit IRC | 06:39 | |
| *** kgugala has joined #litex | 06:41 | |
| *** kgugala_ has quit IRC | 06:44 | |
| *** lkcl has joined #litex | 06:53 | |
| *** lkcl has quit IRC | 07:37 | |
| *** lkcl has joined #litex | 07:50 | |
| *** Bertl_zZ is now known as Bertl | 11:12 | |
| 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 | 13:05 |
|---|---|---|
| somlo | so it's only when using jtagbone that reading registers is broken for me | 13:06 |
| somlo | haven't tried "classic" uartbone yet, might give that a shot too for completeness | 13:07 |
| somlo | _florent_: console-over-jtag, "classic" uartbone debugging also works fine for reading back register values via litex_client | 13:34 |
| 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 :) | 13:35 |
| _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). | 14:08 |
| *** Melkhior has joined #litex | 15:40 | |
| 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), | 15:45 |
| 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... | 15:45 |
| _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? | 15:50 |
| 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' | 15:52 |
| Melkhior | That got me updated verilog in pythondata_cpu_vexriscv_smp, with which I rebuilt the bitstream with 'linux-on-litex-vexriscv' 'make.py' | 15:53 |
| Melkhior | except for that weird 'stuff never seem to finish' behavior, everything else went smoothly... | 15:54 |
| 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...) | 15:55 |
| Melkhior | Anyway no big deal, but I'm curious as it's a really weird failure mode. | 15:56 |
| somlo | Melkhior: sounds like a job for `git bisect` :) | 15:56 |
| Melkhior | @somlo yes, but it will take a good chunk of forever as synthesizing the bitstream is not fast :-/ | 15:57 |
| Melkhior | Fortunately it's the one case where the sd-card work so testing the bitstream is quick :-) | 15:58 |
| 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... | 15:59 |
| Melkhior | Not sure I'll find the time so no promise :-/ | 15:59 |
| 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) | 16:02 |
| 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) | 16:03 |
| somlo | if it's any consolation, the thing was probably on its last legs anyway... | 16:04 |
| somlo | probably an old capacitor | 16:05 |
| 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... | 16:08 |
| geertu | somlo: git bisect run /path/to/script | 16:11 |
| geertu | Usually I'm too lazy to write the script (which has to be perfect ;-) | 16:12 |
| 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... | 16:23 |
| 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 | 16:41 |
| 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 | 16:42 |
| 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 | 16:43 |
| 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. | 17:00 |
| 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]" | 17:02 |
| nickoe | https://dpaste.com/D8NYZNLLM | 17:03 |
| tpb | Title: dpaste: D8NYZNLLM (at dpaste.com) | 17:03 |
| daveshah | nickoe: are you using U13 in your platform file for something? | 17:08 |
| nickoe | yes, uart tx | 17:09 |
| *** kgugala_ has joined #litex | 17:09 | |
| daveshah | is that the correct pin? | 17:10 |
| nickoe | but I guess I could hack that around if needed, I think it was just added to a random pin without having any idea about the gpio banks. | 17:10 |
| nickoe | daveshah: Yeah, I just checked with the pcb design. | 17:10 |
| daveshah | Then the package is probably set up wrong | 17:11 |
| nickoe | mm, not the package, the pcb design -- right? | 17:11 |
| nickoe | daveshah: there are lots ofother pins with that warning, see https://dpaste.com/D8NYZNLLM#line-1415 | 17:12 |
| tpb | Title: dpaste: D8NYZNLLM (at dpaste.com) | 17:12 |
| *** kgugala has quit IRC | 17:13 | |
| daveshah | you sure it is the cpg236 package? | 17:13 |
| nickoe | hm, no it is not | 17:15 |
| nickoe | it is xc7a35tcsg324-1 | 17:16 |
| daveshah | then you'll need to change that in the platform file | 17:17 |
| nickoe | yeah, I just did, XilinxPlatform.__init__(self, "xc7a35t-csg324-1", _io, toolchain=toolchain) | 17:17 |
| nickoe | the user manual for the module suggests this, https://dpaste.com/9JWMZD7UY | 17:18 |
| tpb | Title: dpaste: 9JWMZD7UY (at dpaste.com) | 17:18 |
| nickoe | so I guess I need to set that pin to low | 17:18 |
| nickoe | how do I do that in the platform code? | 17:18 |
| daveshah | if you look at the top of the log file, vivado is trying to build for the xc7a35t-cpg236-1 device | 17:18 |
| daveshah | you'll need to sort that first | 17:18 |
| *** kgugala_ has quit IRC | 17:19 | |
| daveshah | setting a pin to a constant can be done in the target | 17:19 |
| daveshah | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/trellisboard.py#L110 | 17:19 |
| *** kgugala has joined #litex | 17:19 | |
| nickoe | upated build log https://dpaste.com/A59KBJRXB | 17:19 |
| daveshah | is an example of setting a pin to 1, setting a pin to 0 is much the same | 17:19 |
| tpb | Title: dpaste: A59KBJRXB (at dpaste.com) | 17:19 |
| nickoe | (now using the correct package) | 17:19 |
| daveshah | I'm not sure why that error is happening, possibly one of the address pins is wrong | 17:20 |
| daveshah | that might be one for _florent_ | 17:20 |
| _florent_ | nickoe: that's probably a missing INTERNAL_VREF constraints on the DRAM bank, ex: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/arty.py#L326 | 17:23 |
| nickoe | I used this as a base for my base (pun intended), by the way, https://github.com/timvideos/litex-buildenv/blob/master/targets/arty/base.py | 17:25 |
| nickoe | and this for the platforms https://github.com/timvideos/litex-buildenv/blob/master/platforms/arty.py | 17:28 |
| nickoe | so I have self.add_platform_command("set_property INTERNAL_VREF 0.750 [get_iobanks 34]") | 17:28 |
| nickoe | my ddr3 sdram is on bank 15 | 17:30 |
| nickoe | and if I use low voltage ram, I guess I need to set it to 1.35/2? | 17:32 |
| nickoe | So "set_property INTERNAL_VREF 0.675 [get_iobanks 15] ? | 17:32 |
| _florent_ | nickoe: yes exactly | 17:34 |
| nickoe | mm, now I changed something .. I am not sure about.. https://dpaste.com/6SZN4XMBC | 17:35 |
| tpb | Title: dpaste: 6SZN4XMBC (at dpaste.com) | 17:35 |
| mithro | _florent_: Regarding https://github.com/litex-hub/pythondata-auto/pull/7 -- eine / umarco is the expert on GitHub Actions | 17:36 |
| nickoe | pushed my changes here for reference, https://github.com/nickoe/litex-buildenv/commit/f46ff5aa9515696bcee0134021a9ed81a2e66029 | 17:43 |
| 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() ! | 17:44 |
| Melkhior | For some reason, this: | 17:44 |
| Melkhior | static long long microseconds(void) | 17:44 |
| Melkhior | { | 17:44 |
| Melkhior | struct timeval t; | 17:44 |
| Melkhior | gettimeofday(&t,(struct timezone *) 0); | 17:44 |
| Melkhior | return t.tv_sec * (long long) 1000000 + t.tv_usec; | 17:44 |
| Melkhior | } | 17:44 |
| Melkhior | Returns a constant value, so the difference between call is always 0 and the calibrating goes into an infinite loop... | 17:44 |
| Melkhior | Now to figure out why gettimeofday() behave like that, and whether it's a hardware or software problem... | 17:44 |
| Melkhior | to be continued :-) | 17:46 |
| _florent_ | mithro: I think the remaining issue is only a permission issue (for the bot to push changes on the repositories): https://github.com/litex-hub/pythondata-auto/runs/1824573452?check_suite_focus=true | 17:46 |
| *** Melkhior has quit IRC | 17:51 | |
| nickoe | daveshah: is it a valid place to put this signal? https://github.com/timvideos/litex-buildenv/commit/e113369880fb636549088a45cbdbafac78debfb5 | 17:52 |
| nickoe | mm, no, I guess it should just be a "signal" or something? | 17:53 |
| nickoe | mm | 17:54 |
| nickoe | ok, like this I guess https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/trellisboard.py#L66 | 17:54 |
| somlo | Melkhior: a total shot in the dark, but any chance it's related to either timebase-frequency or clock-frequency in the DTS? :) | 17:54 |
| somlo | probably not, but since we were on that topic a few days ago... | 17:54 |
| *** Bertl is now known as Bertl_oO | 17:59 | |
| 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 | 18:02 |
| nickoe | hmm, why do I get this error https://dpaste.com/9RPM8ZMWQ from this change trying to add LEDChaser? https://github.com/timvideos/litex-buildenv/commit/ae98c83277eabe7e48acc455138f094b1b4d748c | 18:02 |
| tpb | Title: dpaste: 9RPM8ZMWQ (at dpaste.com) | 18:02 |
| nickoe | I have four user_led's defined in the platform. | 18:02 |
| *** Melkhior has joined #litex | 18:06 | |
| 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... | 18:08 |
| Melkhior | seems that whatever real-time mechanism is backing gettimeofday() is MIA ... | 18:08 |
| daveshah | this has strong "64 bit time_t" vibes but I can't point to a specific problem | 18:10 |
| Melkhior | perhaps | 18:11 |
| Melkhior | but this is the 'latest' buidlroot with Geert's v5.11 kernel, so both should be quite up-to-date and compatible... | 18:12 |
| Melkhior | maybe a configuration issue ? | 18:12 |
| Melkhior | could have messed that up when I upgraded buildroot/kernel... | 18:12 |
| Melkhior | anyway I'll try to track & report | 18:13 |
| Melkhior | thanks for the suggestions | 18:13 |
| geertu | Melkhior: does "sleep 1" in a shell return after 1s? | 18:13 |
| 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? | 18:19 |
| daveshah | The ram test should be automatic on boot if your target is supported properly | 18:19 |
| daveshah | *set up properly | 18:20 |
| daveshah | The flash I'm not so sure about as I've not used flash with litex before | 18:20 |
| Melkhior | @geeru yes it seems to work properly | 18:20 |
| nickoe | it completed a "fe" with "Flash erased" | 18:21 |
| Melkhior | @geertu sorry | 18:22 |
| nickoe | oh, there a sdrinit command | 18:22 |
| Melkhior | @geertu the 'sleep' is from busybox, dunno if it changes the implementation | 18:22 |
| 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 | 18:51 |
| nickoe | is there a way to generate a memory map over stuff i a litex soc easily? | 18:56 |
| _florent_ | nickoe: the memtest is passing it seems, congrats :) | 19:01 |
| nickoe | I have no idea how much that tests, but I guess it is a good starting point. | 19:02 |
| nickoe | how can I test flash? | 19:02 |
| _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 | 19:03 |
| nickoe | _florent_: I am not sure if this is good? https://dpaste.com/8PJH9DKRD | 19:03 |
| tpb | Title: dpaste: 8PJH9DKRD (at dpaste.com) | 19:03 |
| _florent_ | sorry I have to go | 19:03 |
| nickoe | ok | 19:04 |
| nickoe | I only have these commands, https://dpaste.com/CA997LUBA | 19:04 |
| tpb | Title: dpaste: CA997LUBA (at dpaste.com) | 19:04 |
| _florent_ | memtest is already testing the main_ram | 19:04 |
| _florent_ | ah, you are using an old version of LiteX | 19:04 |
| _florent_ | I would recommend using upstream | 19:05 |
| nickoe | old?! I used https://github.com/timvideos/litex-buildenv | 19:06 |
| mithro | Litex-BuildEnv lags behind the current upstream version | 19:15 |
| nickoe | mithro: How much? | 19:17 |
| 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. | 19:17 |
| mithro | nickoe: dunno at the moment, the Travis CI breakage hasn't been fixed | 19:18 |
| nickoe | mm, ok, but in the meantime, do you see anythin wrong with this change? https://github.com/timvideos/litex-buildenv/commit/ae98c83277eabe7e48acc455138f094b1b4d748c | 19:19 |
| nickoe | I mean expect for the comment that says this is static.. I can't compile that and get https://dpaste.com/9RPM8ZMWQ | 19:20 |
| tpb | Title: dpaste: 9RPM8ZMWQ (at dpaste.com) | 19:20 |
| nickoe | maybe I did something wrong with? https://github.com/nickoe/litex-buildenv/blob/mars_ax3/platforms/mars_ax3.py#L9-L12 | 19:21 |
| mithro | Look at the code in home/nickoe/litex_test/litex-buildenv/third_party/litex/litex/build/generic_platform.py around the ValueError | 19:22 |
| nickoe | it do seem to hit the value error at 224 | 19:26 |
| nickoe | in def request_all(self, name): | 19:26 |
| nickoe | I still don't get why it fails. The code looks the same to the upstream litex as well. | 19:30 |
| 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 ) | 19:49 |
| 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? | 19:50 |
| *** Melkhior has quit IRC | 20:16 | |
| _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. | 20:48 |
| ius | guess i could try an older kernel | 20:49 |
| 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 | 20:50 |
| 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) | 20:54 |
| _florent_ | ius: this could be an issue in the driver, not sure we tested multiple instances of the same peripherals | 20:57 |
| ius | yes, i figured, so thats why im trying to get jtag working | 20:58 |
| *** dkozel has quit IRC | 21:02 | |
| *** dkozel has joined #litex | 21:04 | |
| nickoe | _florent_: Why can't I do self.comb += platform.request("user_led", 2).eq(1) ? | 23:02 |
| nickoe | I have four leds specified in the platform | 23:02 |
| nickoe | mithro: mm, maybe this old issue should just be closed? https://github.com/timvideos/litex-buildenv/issues/71 | 23:27 |
| nickoe | hmm, if I rename the leds in the platform code away from "user_led" then it works :O Why is this? | 23:36 |
| nickoe | I guess the only reason is that the platform object is not quite the right one or something. | 23:53 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
