Wednesday, 2022-09-28

*** tpb <[email protected]> has joined #litex00:00
*** rektide <[email protected]> has joined #litex00:11
*** benh <[email protected]> has quit IRC (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in)01:23
*** benh <[email protected]> has joined #litex01:24
*** Guest13 <[email protected]> has joined #litex02:26
*** Brinx <[email protected]> has joined #litex02: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 #litex03:05
*** Degi_ <[email protected]> has joined #litex03:59
*** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds)04:01
*** Degi_ is now known as Degi04: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 #litex04:49
*** Guest13 <[email protected]> has joined #litex05:50
*** Guest13 <[email protected]> has quit IRC (Client Quit)05:51
*** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex06:08
*** slagernate <[email protected]> has quit IRC (Ping timeout: 252 seconds)06:19
*** Brinx <[email protected]> has joined #litex06: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 #litex07:23
*** Brinx <[email protected]> has joined #litex07:34
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)07:35
*** Brinx <[email protected]> has joined #litex07:35
tntAnyone 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 #litex08:03
*** Brinx <[email protected]> has quit IRC (Ping timeout: 265 seconds)08:08
*** Brinx <[email protected]> has joined #litex08:40
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)08:42
*** Brinx <[email protected]> has joined #litex08:42
minutelooks like my liteeth/linux issue is dts related08:47
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)09:06
*** TMM_ <[email protected]> has joined #litex09:06
minuteyes it is. my custom dts subtely diverged from the generated one, and liteeth buffer address moved from 0xb0000000 to 0x8000000009:31
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)09:53
*** Brinx <[email protected]> has joined #litex09:54
*** nickoe17 <[email protected]> has quit IRC (Quit: Client closed)09:59
*** nickoe17 <[email protected]> has joined #litex09:59
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)11:58
somlogatecat: 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
somlowith `--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
somlofrom 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 #litex12:30
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)12:30
*** Brinx <[email protected]> has joined #litex12:30
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)12:31
*** Brinx <[email protected]> has joined #litex12:31
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)12:31
*** Brinx <[email protected]> has joined #litex12:31
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 240 seconds)12:33
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex12:36
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Quit: quit)12:42
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex12:51
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Client Quit)12:53
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex12: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 #litex13:07
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex13:07
minutehow i do i define the drive strength of lvcmos18 pads in a litex platform?13:14
minuteMisc("DRIVE=4") ?13:16
*** Guest13 <[email protected]> has joined #litex13:52
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed)14:00
*** Guest13 <[email protected]> has joined #litex14: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 #litex14: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 #litex14:47
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Quit: quit)15:19
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex15:20
*** shoragan <shoragan!~shoragan@user/shoragan> has quit IRC (Ping timeout: 246 seconds)15:28
*** shoragan <shoragan!~shoragan@user/shoragan> has joined #litex15:30
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving)16:03
minutehas anyone gotten xorg or tinyx to build in litex' buildroot?16:19
minuteah, 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 package16:29
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)16:52
*** TMM_ <[email protected]> has joined #litex16:52
minuteok, 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 somehow17:34
minutei guess libinput is somehow defective... libinput debug-events shows the devices but no events17:34
minutecat /dev/input/event0 etc gives me live data though17:34
geertuminute: Does evtest show the correct events?17:41
minutegeertu: just installed it, lets see17:41
minutegeertu: shows some weird stuff. for example, for the keyboard, the ~type~ of the event changes for each key17:45
minuteEvent: time -1655458136.000210, type 210 (?), code 0 (?), value 91363117:45
minuteEvent: time -1655458136.000212, type 212 (?), code 0 (?), value 99770817:45
minuteetc17:45
minutestrange because the keyboard works in the linux console17:45
minuteit's like the kernel event devices are messed up somehow17:45
minuteso the timestamp (seconds) is actually ending up in the "type" field of events17:49
minutemaybe some kind of alignment / struct packing issue?! 17:49
geertuminute: Any weird code that assumes unknown architectures are big-endian. while risc-v is little-endian?17:49
minutein the kernel? am i the first person testing this?17:50
geertuminute: I actually haven't connected a keyboard to any of my risc-v boards yet ;-)17:51
minutehuh!17:51
minuteat least /dev/input/mouse0 works, but we don't have anything like that for xorg except evdev17:51
geertudrivers/input/evdev.c has an #ifdef __BIG_ENDIAN17:52
geertuohoh, that is actually the wrong check17:53
geertu#define __BIG_ENDIAN 432117:53
geertu#define __LITTLE_ENDIAN 123417:54
minutealso just seen that ifdef ther17:54
minutegeertu: can you explain what's the wrong check?17:55
*** Brinx <[email protected]> has joined #litex17:55
geertuminute: both __BIG_ENDIAN and __LITTLE_ENDIAN might be defined17:55
geertuMany places check for #if __BYTE_ORDER == __BIG_ENDIAN17:55
minuteoh, huh?17:55
minutei see, that's weird17:56
minutei'll try replacing that17:56
geertuThere are many places that check for __BIG_ENDIAN17:56
minute:|17:56
minutegeertu: that was not the problem18:00
geertuminute: just discovered that myself, too. my vexriscv build has the little-endian variant of the code in drivers/input/evdev.c18:01
minutegeertu: can you reproduce the same problem?18:02
geertuminute: haven't tried yet. no keyboard on my risc-v boards.18:04
minuteah.18:05
minutegonna add some printks then...18:06
minutesome more potential for mismatches https://github.com/torvalds/linux/blob/master/include/uapi/linux/input.h#L2918:09
geertuminute: Right, you are using vexriscv, which is 32-bit, Does your userspace agree with the kernel about the size of the timestamps?18:10
minutelets see, have to dig in buildroot18:10
geertuwhen linux on vexriscv was started, the 32-bit API wasn't fixed yet, IIRC.18:11
minuteok, how am i going to figure that out...18:12
minutei mean, both the userspace and kernel are built by the same buildroot18:12
geertuminute: check the C library18:13
geertusources18:13
minuteapparently it's glibc-2.36-44-g2628500f5dff1dd99c49a09b418b3b1ea3a6b5d318:15
minutenot sure what exactly i should be looking for though18:16
minutehmm hmm > GLIBC will enable __USE_TIME_BITS64 if it sees -D_TIME_BITS=6418:21
minutegeertu: 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
minutei don't know how to fix this on a buildroot level so i'm gonna patch libinput for my demo purposes :|18:37
minuteandrew pinski on twitter says that 32 bit in the kernel is wrong, it should always be 64 bit18:44
minuteaha, > CONFIG_COMPAT_32BIT_TIME=y18:47
minutethis doesn't affect evdev in the kernel though, i think18:51
*** slagernate <[email protected]> has joined #litex18:57
minutei 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 fix19:08
*** hrberg <[email protected]> has joined #litex19:11
cr1901Is this an "upstream only cares about 64-bit RV" problem?19:45
minutecr1901: 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 yet19:46
minutehere's xorg running on litex-vexriscv on a custom kintex-7 device https://twitter.com/minut_e/status/157520601553216716819:47
cr1901good stuff :)19:52
minuteyeah, quite enjoyable19:52
minuteendless further hacking opportunities...19:53
tpw_ruleswhat did you use for a framebuffer?19:53
geertuminute: Probably it's just due to a mismatch between kernel and userspace.19:53
geertuThe rootfs.cpio I'm using on vexriscv also doesn't work in compat mode on 64-bit RZ/Five19:54
geertuInitially, RV32 was deemed not to be suitable for Linux19:55
cr1901I don't get why19:55
geertuLater, that was retracted, and there was never going to be a compat mode.19:55
geertuFinally, compat mode did appear ;-)19:55
cr1901It's another RISC in a sea of RISC19: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/!