<minute>
yes it is. my custom dts subtely diverged from the generated one, and liteeth buffer address moved from 0xb0000000 to 0x80000000
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
nickoe17 has quit [Quit: Client closed]
nickoe17 has joined #litex
Brinx has quit [Remote host closed the connection]
<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)
<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 :)
<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 :)
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
shoragan has quit [Ping timeout: 240 seconds]
shoragan has joined #litex
shoragan has quit [Quit: quit]
shoragan has joined #litex
shoragan has quit [Client Quit]
shoragan has joined #litex
shoragan has quit [Ping timeout: 268 seconds]
mtretter has quit [Ping timeout: 268 seconds]
mtretter has joined #litex
shoragan has joined #litex
<minute>
how i do i define the drive strength of lvcmos18 pads in a litex platform?
<minute>
Misc("DRIVE=4") ?
Guest13 has joined #litex
Guest13 has quit [Quit: Client closed]
Guest13 has joined #litex
hrberg has quit [Ping timeout: 246 seconds]
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Guest13 has quit [Quit: Client closed]
Brinx has quit [Ping timeout: 260 seconds]
nickoe17 has quit [Quit: Client closed]
nickoe17 has joined #litex
shoragan has quit [Quit: quit]
shoragan has joined #litex
shoragan has quit [Ping timeout: 246 seconds]
shoragan has joined #litex
FabM has quit [Quit: Leaving]
<minute>
has anyone gotten xorg or tinyx to build in litex' buildroot?
<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
<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
<minute>
i guess libinput is somehow defective... libinput debug-events shows the devices but no events
<minute>
cat /dev/input/event0 etc gives me live data though
<geertu>
minute: Does evtest show the correct events?
<minute>
geertu: just installed it, lets see
<minute>
geertu: shows some weird stuff. for example, for the keyboard, the ~type~ of the event changes for each key
<minute>
Event: time -1655458136.000210, type 210 (?), code 0 (?), value 913631
<minute>
Event: time -1655458136.000212, type 212 (?), code 0 (?), value 997708
<minute>
etc
<minute>
strange because the keyboard works in the linux console
<minute>
it's like the kernel event devices are messed up somehow
<minute>
so the timestamp (seconds) is actually ending up in the "type" field of events
<minute>
maybe some kind of alignment / struct packing issue?!
<geertu>
minute: Any weird code that assumes unknown architectures are big-endian. while risc-v is little-endian?
<minute>
in the kernel? am i the first person testing this?
<geertu>
minute: I actually haven't connected a keyboard to any of my risc-v boards yet ;-)
<minute>
huh!
<minute>
at least /dev/input/mouse0 works, but we don't have anything like that for xorg except evdev
<geertu>
drivers/input/evdev.c has an #ifdef __BIG_ENDIAN
<geertu>
ohoh, that is actually the wrong check
<geertu>
#define __BIG_ENDIAN 4321
<geertu>
#define __LITTLE_ENDIAN 1234
<minute>
also just seen that ifdef ther
<minute>
geertu: can you explain what's the wrong check?
Brinx has joined #litex
<geertu>
minute: both __BIG_ENDIAN and __LITTLE_ENDIAN might be defined
<geertu>
Many places check for #if __BYTE_ORDER == __BIG_ENDIAN
<minute>
oh, huh?
<minute>
i see, that's weird
<minute>
i'll try replacing that
<geertu>
There are many places that check for __BIG_ENDIAN
<minute>
:|
<minute>
geertu: that was not the problem
<geertu>
minute: just discovered that myself, too. my vexriscv build has the little-endian variant of the code in drivers/input/evdev.c
<minute>
geertu: can you reproduce the same problem?
<geertu>
minute: haven't tried yet. no keyboard on my risc-v boards.
<minute>
not sure what exactly i should be looking for though
<minute>
hmm hmm > GLIBC will enable __USE_TIME_BITS64 if it sees -D_TIME_BITS=64
<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!
<minute>
i don't know how to fix this on a buildroot level so i'm gonna patch libinput for my demo purposes :|
<minute>
andrew pinski on twitter says that 32 bit in the kernel is wrong, it should always be 64 bit
<minute>
aha, > CONFIG_COMPAT_32BIT_TIME=y
<minute>
this doesn't affect evdev in the kernel though, i think
slagernate has joined #litex
<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
hrberg has joined #litex
<cr1901>
Is this an "upstream only cares about 64-bit RV" problem?
<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