<tnt>
_florent_: ah nice (for ddr4) I might have a look next week. I'll see if I can generate a mig controller for my board.
<slagernate>
_florent_: Sorry, I was a little confused (I thought I had to somehow specify my specific CPU configuration when running litex_sim). I've just ran it and it is booting well
<slagernate>
So it would seem the bios is not compatible with the crosslinknx platform/target anymore. David brings up that bisecting the old bios code would likely be the fastest way to narrow down the bug
<tnt>
slagernate: did you try to build the older version ?
giggiu16 has joined #litex
<giggiu16>
_florent_: thanks for your response, I have actually followed the guide and also the linked example and it seems to somewhat work. What I'm missing is the part where I can explicitly control clock and signals from submodules of the SoC (example: https://github.com/enjoy-digital/litex/blob/master/test/test_spi.py#L19)
_franck_ has quit [Ping timeout: 252 seconds]
_franck_4 has joined #litex
giggiu16 has quit [Ping timeout: 252 seconds]
<Melkhior>
@tpw_rules: if the colors are displayed properly, then they are in the right order ;-)
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
giggiu16 has joined #litex
giggiu16 has quit [Client Quit]
giggiu16 has joined #litex
<tpw_rules>
Melkhior: the problem is the colorbar module displays the wrong colors if the framebuffer displays the right colors
<tpw_rules>
and if i swap red and blue in my PHY, then the colorbar displays the right colors and the framebuffer displays the wrong colors.
<Melkhior>
@tpw_rules then I'd say the colorbar module has an issue...
<Melkhior>
I admint I only cared for what Linux displays when using the FB when I originally tried the LItex FB :-)
<tpw_rules>
but the code in there is very straightforward
<Melkhior>
it is my firm opinion than endianess is _never_ straightforward :-)
<tpw_rules>
yeah but there's no endianness in the colorbar code. it's just like source.r.eq(0xff) # red
<Melkhior>
ouch
<Melkhior>
I don't know, seems weird
<Melkhior>
if when you write 0xff to red you get blue, then I guess maybe it's backward later on ? and the FB code is backward to accomdate that other backward-ness ?
<Melkhior>
My version only worked through trial-and-error, not "this is how it should be" ...
<tpw_rules>
funny that that doesn't update the framebuffer code
<Melkhior>
might have tested only with the colorbar :-)
<tpw_rules>
also i guess github's search index didn't catch that yet
giggiu16 has quit [Quit: Client closed]
<tpw_rules>
thanks for finding that. saves me a bit of work
<Melkhior>
no problem
<Melkhior>
if you want extra features, my variant of the FB is ugly but you get a CLUT for indexed modes, switchable depth (for MacOS/68k), optional hardware cursor (for X11 in NetBSD/sparc), and recently I added windowboxed resolution (so you can use a resolution lower than the output resolution, useful in MacOS for old software which don't like high resolution)
<Melkhior>
(the acceleration stuff is not technically part of the FB)
<trabucayre>
this fix is to correct relation channel id <-> color according to DVI specs
<trabucayre>
Melkhior> might have tested only with the colorbar :-)
<tpw_rules>
i mean my problem is with the framebuffer. the video terminal has that kind of ambiguous green. i think it would be hard to tell the red and blue were swapped
<trabucayre>
maybe another swap before video phy ? ( -1 x -1 = 1)
<tpw_rules>
did you test with the framebuffer? there is another swap in there that needs to be done
<tpw_rules>
or just the terminal?
<trabucayre>
not checked if framebuffer is used
<trabucayre>
but i think so
FabM has quit [Quit: Leaving]
Brinx has quit [Remote host closed the connection]
Brinx has joined #litex
Brinx has quit [Ping timeout: 246 seconds]
<tpw_rules>
anybody used quartus PLLs with litex? it seems to be generating slightly bad frequencies that make quartus barf
<minute>
i am hitting a regression (checked against backups) in vexriscv that makes ohci unusable and introduces some other instability (oopses and segfaults). i want to return to an earlier state, but SpinalHDL and VexRiscv git submodule versions are not pinned in pythondata-cpu-vexriscv-smp, is that correct?
<tpw_rules>
i mean being submodules they are inherently pinned by the version of the pythondata-cpu-vexriscv-smp itself, right?
<zyp>
right
<zyp>
so you should be able to do a bisect on the pythondata repo
<minute>
ah yeah
<minute>
btw, to try naxriscv i would basically just replace vexriscv occurences in make.py (of linux-on-litex-vexriscv), or is it more complicated?
<minute>
with pythondata-cpu-vexriscv_smp @ 60c32b141906ea4b8ba6ec19c66a321a1477e55c everything is fine, no random oops in a bridge driver and no usb errors
<minute>
@ 4306ae2eb5464bc37d14eff9a3c051d7b0c17d0d does not build
<minute>
[error] /home/mntmn/code/litex/pythondata-cpu-vexriscv-smp/pythondata_cpu_vexriscv_smp/verilog/ext/SpinalHDL/lib/src/main/scala/spinal/lib/bus/bmb/BmbInterconnectGenerator.scala:173:61: reference to Lock is ambiguous;