Friday, 2022-09-30

*** tpb <[email protected]> has joined #litex00:00
*** slagernate <[email protected]> has quit IRC (Ping timeout: 252 seconds)00:19
*** genpaku <[email protected]> has quit IRC (Remote host closed the connection)00:40
*** genpaku <[email protected]> has joined #litex00:40
tpw_rulesanybody seen quartus complain about invalid PLL settings? seems something is wrong with the calculator02:10
*** slagernate <[email protected]> has joined #litex03:18
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)03:20
*** TMM_ <[email protected]> has joined #litex03:20
*** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds)03:56
*** Degi <[email protected]> has joined #litex03:57
*** minute <[email protected]> has quit IRC (Ping timeout: 268 seconds)04:05
*** minute <[email protected]> has joined #litex04:05
*** pbsds <[email protected]> has quit IRC (Ping timeout: 252 seconds)04:18
*** pbsds <[email protected]> has joined #litex04:18
*** pbsds <[email protected]> has quit IRC (Ping timeout: 268 seconds)04:24
tpw_ruleshow are the framebuffer colors supposed to be encoded? i've somehow got r and b swapped. but the colorbars look right04:59
tpw_rulesin both rgb888 and rgb565 modes04:59
tpw_rulesyeah these are definitely backwards05:05
tpw_rules"format" https://www.kernel.org/doc/Documentation/devicetree/bindings/display/simple-framebuffer.txt vs https://github.com/enjoy-digital/litex/blob/ad8b7da63d34fd955e3e739693e101f4467a96d6/litex/soc/cores/video.py#L68905:05
tpw_ruleshttps://github.com/enjoy-digital/litex/blob/a7cc1af41640f505bacafceb87019dbbe7bdee3a/litex/soc/cores/video.py#L798 and this should be the blue. 05:14
*** Guest13 <[email protected]> has joined #litex05:29
slagernategatecat: would you happen to have your build script handy? You mentioned picorv32 was working for you05:33
*** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex06:10
_florent_ slagernate as suggested by gatecat, can you just test the litex_sim command? If  working, this will rule out a RISC-V toolchain issue06:42
_florent_slagernate: you just need to install Verilator for this06:42
_florent_slagernate: 5) of https://github.com/enjoy-digital/litex/wiki/Installation06:43
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.06:44
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 well06:50
*** Guest13 <[email protected]> has quit IRC (Quit: Client closed)06:51
slagernateI.e. I am getting the BIOS output expected in https://github.com/enjoy-digital/litex/wiki/Installation06:51
slagernateIt seems DavidCorrigan is no longer able to build for his board as well (CrosslinkNX Evaluation Board): https://github.com/enjoy-digital/litex/issues/1441#issuecomment-1263126036  ... He was one of the first to get it working on the CrosslinkNX platform.06:54
slagernateSo 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 bug06:56
tntslagernate: did you try to build the older version ?07:38
*** giggiu16 <[email protected]> has joined #litex07:48
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)08:14
*** _franck_ <[email protected]> has quit IRC (Ping timeout: 252 seconds)08:46
*** _franck_4 <[email protected]> has joined #litex08:46
*** giggiu16 <[email protected]> has quit IRC (Ping timeout: 252 seconds)09:29
Melkhior@tpw_rules: if the colors are displayed properly, then they are in the right order ;-)09:41
MelkhiorBetween the way the host write to the memory, the memory is being read in the FIFO, how the FIFO output is decoded, etc., it's not obvious to figure out which bits will become what ; I've had to deal with that in my 'extended' version of the LItex FB: https://github.com/rdolbeau/NuBusFPGA/blob/d0d98f13900e6c19f28e0a76bf8fff20a5e923f4/nubus-to-ztex-gateware/goblin_fb.py#L17309:59
*** giggiu16 <[email protected]> has joined #litex09:59
Melkhiorand https://github.com/rdolbeau/NuBusFPGA/blob/d0d98f13900e6c19f28e0a76bf8fff20a5e923f4/nubus-to-ztex-gateware/goblin_fb.py#L21110:02
*** likewise <[email protected]> has joined #litex10:36
*** giggiu16 <[email protected]> has quit IRC (Ping timeout: 252 seconds)10:50
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)10:50
*** Brinx <[email protected]> has joined #litex11:33
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)11:34
*** Brinx <[email protected]> has joined #litex11:34
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)11:34
*** Brinx <[email protected]> has joined #litex11:34
*** giggiu16 <[email protected]> has joined #litex12:16
*** giggiu16 <[email protected]> has quit IRC (Client Quit)12:19
*** giggiu16 <[email protected]> has joined #litex12:19
tpw_rulesMelkhior: the problem is the colorbar module displays the wrong colors if the framebuffer displays the right colors12:24
tpw_rulesand if i swap red and blue in my PHY, then the colorbar displays the right colors and the framebuffer displays the wrong colors.12:25
Melkhior@tpw_rules then I'd say the colorbar module has an issue...12:30
MelkhiorI admint I only cared for what Linux displays when using the FB when I originally tried the LItex FB :-)12:31
tpw_rulesbut the code in there is very straightforward12:31
Melkhiorit is my firm opinion than endianess is _never_ straightforward :-)12:32
tpw_rulesyeah but there's no endianness in the colorbar code. it's just like source.r.eq(0xff) # red12:32
Melkhiorouch12:33
MelkhiorI don't know, seems weird12:37
Melkhiorif 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 ?12:40
MelkhiorMy version only worked through trial-and-error, not "this is how it should be" ...12:41
tpw_ruleshttps://github.com/enjoy-digital/litex/blob/a7cc1af41640f505bacafceb87019dbbe7bdee3a/litex/soc/cores/video.py#L850 this is wrong too. blue goes in channel 0 and red goes in channel 212:41
tpw_ruleshttps://ez.analog.com/cfs-file/__key/telligent-evolution-components-attachments/00-317-00-00-00-05-21-37/HDMISpecification13a.pdf see page 104 (88 in the footer)12:42
tpw_rulesdid you use litex's hdmi phy?12:43
Melkhiorthis would explain that ... if both HDMI and FB are reversed, it all works out in the end12:44
Melkhioryes I use the LItex HDMI PHY12:44
tpw_rulesunless you try to use the colorbars to test your color!12:44
tpw_rulesthen yeah your framebuffer reads are probably backwards too12:44
Melkhioralso the VGA PHY, vaguely remember a discrepancy, but I'm not sure12:44
MelkhiorX11 can accommodate both r8g8b8 and b8g8r8 and I changed it at some point while tracking down issues in my Xrender code12:46
tpw_rulesso now it's triple backwards for you :)12:46
tpw_ruleswell i will try to submit a PR this weekend to get everything straightened out but i don't have any hdmi boards to test with12:47
Melkhioryes, at least... the host are big-endians (sparc or mac68k), but NuBus is LE (SBus is BE), then Wishbone ...12:47
Melkhiorit's even more of a mess than a straightforward SoC12:48
Melkhiormmmmm12:49
Melkhiorhttps://github.com/enjoy-digital/litex/commit/dc0a4ea40bddcbc9f96b08a8eb46c39ec6bfff2012:49
Melkhiorsomeone agrees with you!12:50
tpw_rulesfunny that that doesn't update the framebuffer code12:51
Melkhiormight have tested only with the colorbar :-)12:51
tpw_rulesalso i guess github's search index didn't catch that yet12:52
*** giggiu16 <[email protected]> has quit IRC (Quit: Client closed)12:53
tpw_rulesthanks for finding that. saves me a bit of work12:53
Melkhiorno problem12:54
Melkhiorif 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)12:55
Melkhior(the acceleration stuff is not technically part of the FB)12:56
trabucayrethis fix is to correct relation channel id <-> color according to DVI specs13:03
trabucayretpw_rules: https://glenwing.github.io/docs/DVI-1.0.pdf fig. 3.2 p.2613:07
tpw_rulestrabucayre: yeah, your fix is correct13:18
trabucayreand no I've tested with the video terminal : https://twitter.com/GwenhaelG/status/1565053922812755969/photo/113:19
trabucayre:)13:20
tpw_rulesno what?13:20
trabucayreMelkhior> might have tested only with the colorbar :-)13:25
tpw_rulesi 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 swapped13:27
trabucayremaybe another swap before video phy ? ( -1 x -1 = 1)13:29
tpw_rulesdid you test with the framebuffer? there is another swap in there that needs to be done14:18
tpw_rulesor just the terminal?14:18
trabucayrenot checked if framebuffer is used14:34
trabucayrebut i think so14:35
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Quit: Leaving)15:53
*** Brinx <[email protected]> has quit IRC (Remote host closed the connection)16:54
*** Brinx <[email protected]> has joined #litex16:55
*** Brinx <[email protected]> has quit IRC (Ping timeout: 246 seconds)16:59
tpw_rulesanybody used quartus PLLs with litex? it seems to be generating slightly bad frequencies that make quartus barf17:10
*** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.)17:29
*** TMM_ <[email protected]> has joined #litex17:29
minutei 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?17:32
tpw_rulesi mean being submodules they are inherently pinned by the version of the pythondata-cpu-vexriscv-smp itself, right?17:33
zypright17:33
zypso you should be able to do a bisect on the pythondata repo17:33
minuteah yeah17:35
minutebtw, to try naxriscv i would basically just replace vexriscv occurences in make.py (of linux-on-litex-vexriscv), or is it more complicated?18:19
minutewith pythondata-cpu-vexriscv_smp @ 60c32b141906ea4b8ba6ec19c66a321a1477e55c everything is fine, no random oops in a bridge driver and no usb errors18:23
minute@ 4306ae2eb5464bc37d14eff9a3c051d7b0c17d0d does not build18:28
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;18:28
minuteetc18:28
slagernatetnt: will try sometime tonight18:37
minuteanyway https://github.com/litex-hub/pythondata-cpu-vexriscv_smp/issues/718:39
*** likewise <[email protected]> has quit IRC (Quit: Client closed)18:55
*** zjason` <zjason`[email protected]> has joined #litex19:33
*** zjason <[email protected]> has quit IRC (Ping timeout: 268 seconds)19:35
slagernatetnt: (in ~5 hours)21:28
minuteLiteX laptop https://twitter.com/minut_e/status/157595885580020531221:42
slagernateminute:sick21:44
*** ewen <[email protected]> has joined #litex22:23
*** nelgau_ <[email protected]> has quit IRC (Remote host closed the connection)22:55
*** nelgau <[email protected]> has joined #litex22:56
*** ewen <[email protected]> has quit IRC (Ping timeout: 244 seconds)23:49
*** slagernate <[email protected]> has quit IRC (Ping timeout: 252 seconds)23:50

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!