| *** tpb <[email protected]> has joined #litex | 00:00 | |
| *** rektide <[email protected]> has joined #litex | 00:11 | |
| *** benh <[email protected]> has quit IRC (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) | 01:23 | |
| *** benh <[email protected]> has joined #litex | 01:24 | |
| *** Guest13 <[email protected]> has joined #litex | 02:26 | |
| *** Brinx <[email protected]> has joined #litex | 02:49 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 02:54 | |
| *** pbsds <[email protected]> has quit IRC (Quit: The Lounge - https://thelounge.chat) | 03:05 | |
| *** pbsds <[email protected]> has joined #litex | 03:05 | |
| *** Degi_ <[email protected]> has joined #litex | 03:59 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 04:01 | |
| *** Degi_ is now known as Degi | 04:01 | |
| *** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 04:06 | |
| *** nickoe17 <[email protected]> has quit IRC (Quit: Client closed) | 04:48 | |
| *** nickoe17 <[email protected]> has joined #litex | 04:49 | |
| *** Guest13 <[email protected]> has joined #litex | 05:50 | |
| *** Guest13 <[email protected]> has quit IRC (Client Quit) | 05:51 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex | 06:08 | |
| *** slagernate <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 06:19 | |
| *** Brinx <[email protected]> has joined #litex | 06:51 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 06:56 | |
| *** nickoe17 <[email protected]> has quit IRC (Quit: Client closed) | 07:23 | |
| *** nickoe17 <[email protected]> has joined #litex | 07:23 | |
| *** Brinx <[email protected]> has joined #litex | 07:34 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 07:35 | |
| *** Brinx <[email protected]> has joined #litex | 07:35 | |
| tnt | Anyone know what would cause long (5-15 us) periods where the requester interface of the xilinx PCIe core is not ready ? | 07:51 |
|---|---|---|
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 08:03 | |
| *** Brinx <[email protected]> has joined #litex | 08:03 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 265 seconds) | 08:08 | |
| *** Brinx <[email protected]> has joined #litex | 08:40 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 08:42 | |
| *** Brinx <[email protected]> has joined #litex | 08:42 | |
| minute | looks like my liteeth/linux issue is dts related | 08:47 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 09:06 | |
| *** TMM_ <[email protected]> has joined #litex | 09:06 | |
| minute | yes it is. my custom dts subtely diverged from the generated one, and liteeth buffer address moved from 0xb0000000 to 0x80000000 | 09:31 |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 09:53 | |
| *** Brinx <[email protected]> has joined #litex | 09:54 | |
| *** nickoe17 <[email protected]> has quit IRC (Quit: Client closed) | 09:59 | |
| *** nickoe17 <[email protected]> has joined #litex | 09:59 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 11:58 | |
| somlo | gatecat: I tried `--tmg-ripup` with nextpnr (litex+rocket on both ecpix5 and trellisboard). Once I'm through with the yosys run (using flow3, that's really nice), I can either run nextpnr in a loop *without* ripup, and usually pass timing within 24 hours (takes about 30-45 minutes per run, given the rocket+litex design) | 12:12 |
| somlo | with `--tmg-ripup` it took 2 days the first time around and it *still* failed timing; I interrupted the second run after 3 days :) | 12:13 |
| somlo | from a "clueless user" practical perspective, taking one's chances by repeatedly running "regular" nextpnr (assuming it's "close" to passing timing already) is a better strategy :) | 12:14 |
| *** Brinx <[email protected]> has joined #litex | 12:30 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 12:30 | |
| *** Brinx <[email protected]> has joined #litex | 12:30 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 12:31 | |
| *** Brinx <[email protected]> has joined #litex | 12:31 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 12:31 | |
| *** Brinx <[email protected]> has joined #litex | 12:31 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 240 seconds) | 12:33 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 12:36 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Quit: quit) | 12:42 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 12:51 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Client Quit) | 12:53 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 12:54 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 268 seconds) | 13:06 | |
| *** mtretter <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 13:06 | |
| *** mtretter <[email protected]> has joined #litex | 13:07 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 13:07 | |
| minute | how i do i define the drive strength of lvcmos18 pads in a litex platform? | 13:14 |
| minute | Misc("DRIVE=4") ? | 13:16 |
| *** Guest13 <[email protected]> has joined #litex | 13:52 | |
| *** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 14:00 | |
| *** Guest13 <[email protected]> has joined #litex | 14:17 | |
| *** hrberg <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 14:24 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 14:26 | |
| *** Brinx <[email protected]> has joined #litex | 14:31 | |
| *** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 14:31 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 260 seconds) | 14:35 | |
| *** nickoe17 <[email protected]> has quit IRC (Quit: Client closed) | 14:47 | |
| *** nickoe17 <[email protected]> has joined #litex | 14:47 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Quit: quit) | 15:19 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 15:20 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 246 seconds) | 15:28 | |
| *** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex | 15:30 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving) | 16:03 | |
| minute | has anyone gotten xorg or tinyx to build in litex' buildroot? | 16:19 |
| minute | ah, it appears that kdrive build doesn't result in a binary, and switching back to modular X won't do anything before cleaning the previous build files in the xorg package | 16:29 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 16:52 | |
| *** TMM_ <[email protected]> has joined #litex | 16:52 | |
| minute | ok, i have Xorg running on litex-on-linux-vexriscv, and mouse works with xf86-input-mouse, but can't get the keyboard to work. evdev and libinput drivers are broken somehow | 17:34 |
| minute | i guess libinput is somehow defective... libinput debug-events shows the devices but no events | 17:34 |
| minute | cat /dev/input/event0 etc gives me live data though | 17:34 |
| geertu | minute: Does evtest show the correct events? | 17:41 |
| minute | geertu: just installed it, lets see | 17:41 |
| minute | geertu: shows some weird stuff. for example, for the keyboard, the ~type~ of the event changes for each key | 17:45 |
| minute | Event: time -1655458136.000210, type 210 (?), code 0 (?), value 913631 | 17:45 |
| minute | Event: time -1655458136.000212, type 212 (?), code 0 (?), value 997708 | 17:45 |
| minute | etc | 17:45 |
| minute | strange because the keyboard works in the linux console | 17:45 |
| minute | it's like the kernel event devices are messed up somehow | 17:45 |
| minute | so the timestamp (seconds) is actually ending up in the "type" field of events | 17:49 |
| minute | maybe some kind of alignment / struct packing issue?! | 17:49 |
| geertu | minute: Any weird code that assumes unknown architectures are big-endian. while risc-v is little-endian? | 17:49 |
| minute | in the kernel? am i the first person testing this? | 17:50 |
| geertu | minute: I actually haven't connected a keyboard to any of my risc-v boards yet ;-) | 17:51 |
| minute | huh! | 17:51 |
| minute | at least /dev/input/mouse0 works, but we don't have anything like that for xorg except evdev | 17:51 |
| geertu | drivers/input/evdev.c has an #ifdef __BIG_ENDIAN | 17:52 |
| geertu | ohoh, that is actually the wrong check | 17:53 |
| geertu | #define __BIG_ENDIAN 4321 | 17:53 |
| geertu | #define __LITTLE_ENDIAN 1234 | 17:54 |
| minute | also just seen that ifdef ther | 17:54 |
| minute | geertu: can you explain what's the wrong check? | 17:55 |
| *** Brinx <[email protected]> has joined #litex | 17:55 | |
| geertu | minute: both __BIG_ENDIAN and __LITTLE_ENDIAN might be defined | 17:55 |
| geertu | Many places check for #if __BYTE_ORDER == __BIG_ENDIAN | 17:55 |
| minute | oh, huh? | 17:55 |
| minute | i see, that's weird | 17:56 |
| minute | i'll try replacing that | 17:56 |
| geertu | There are many places that check for __BIG_ENDIAN | 17:56 |
| minute | :| | 17:56 |
| minute | geertu: that was not the problem | 18:00 |
| geertu | minute: just discovered that myself, too. my vexriscv build has the little-endian variant of the code in drivers/input/evdev.c | 18:01 |
| minute | geertu: can you reproduce the same problem? | 18:02 |
| geertu | minute: haven't tried yet. no keyboard on my risc-v boards. | 18:04 |
| minute | ah. | 18:05 |
| minute | gonna add some printks then... | 18:06 |
| minute | some more potential for mismatches https://github.com/torvalds/linux/blob/master/include/uapi/linux/input.h#L29 | 18:09 |
| geertu | minute: Right, you are using vexriscv, which is 32-bit, Does your userspace agree with the kernel about the size of the timestamps? | 18:10 |
| minute | lets see, have to dig in buildroot | 18:10 |
| geertu | when linux on vexriscv was started, the 32-bit API wasn't fixed yet, IIRC. | 18:11 |
| minute | ok, how am i going to figure that out... | 18:12 |
| minute | i mean, both the userspace and kernel are built by the same buildroot | 18:12 |
| geertu | minute: check the C library | 18:13 |
| geertu | sources | 18:13 |
| minute | apparently it's glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d3 | 18:15 |
| minute | not sure what exactly i should be looking for though | 18:16 |
| minute | hmm hmm > GLIBC will enable __USE_TIME_BITS64 if it sees -D_TIME_BITS=64 | 18:21 |
| minute | geertu: it is indeed a 64bit vs 32bit time problem. i changed evtest.c to use a custom struct instead of input_event. if i define sec and usec as uint32_t, the data is correct! | 18:35 |
| minute | i don't know how to fix this on a buildroot level so i'm gonna patch libinput for my demo purposes :| | 18:37 |
| minute | andrew pinski on twitter says that 32 bit in the kernel is wrong, it should always be 64 bit | 18:44 |
| minute | aha, > CONFIG_COMPAT_32BIT_TIME=y | 18:47 |
| minute | this doesn't affect evdev in the kernel though, i think | 18:51 |
| *** slagernate <[email protected]> has joined #litex | 18:57 | |
| minute | i harcoded this to be 64 bit in the kernel (can't read the define logic there) and the events work, the timestamps are messed up though (i think seconds and usec are swapped)... easy to fix | 19:08 |
| *** hrberg <[email protected]> has joined #litex | 19:11 | |
| cr1901 | Is this an "upstream only cares about 64-bit RV" problem? | 19:45 |
| minute | cr1901: i don't know what the root of the problem is in the kernel, might be something of a corner case that nobody else bumped against yet | 19:46 |
| minute | here's xorg running on litex-vexriscv on a custom kintex-7 device https://twitter.com/minut_e/status/1575206015532167168 | 19:47 |
| cr1901 | good stuff :) | 19:52 |
| minute | yeah, quite enjoyable | 19:52 |
| minute | endless further hacking opportunities... | 19:53 |
| tpw_rules | what did you use for a framebuffer? | 19:53 |
| geertu | minute: Probably it's just due to a mismatch between kernel and userspace. | 19:53 |
| geertu | The rootfs.cpio I'm using on vexriscv also doesn't work in compat mode on 64-bit RZ/Five | 19:54 |
| geertu | Initially, RV32 was deemed not to be suitable for Linux | 19:55 |
| cr1901 | I don't get why | 19:55 |
| geertu | Later, that was retracted, and there was never going to be a compat mode. | 19:55 |
| geertu | Finally, compat mode did appear ;-) | 19:55 |
| cr1901 | It's another RISC in a sea of RISC | 19:56 |
| *** slagernate <[email protected]> has quit IRC (Quit: Client closed) | 21:36 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!