| *** tpb <[email protected]> has joined #litex | 00: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 #litex | 00:40 | |
| tpw_rules | anybody seen quartus complain about invalid PLL settings? seems something is wrong with the calculator | 02:10 |
|---|---|---|
| *** slagernate <[email protected]> has joined #litex | 03:18 | |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 03:20 | |
| *** TMM_ <[email protected]> has joined #litex | 03:20 | |
| *** Degi <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 03:56 | |
| *** Degi <[email protected]> has joined #litex | 03:57 | |
| *** minute <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 04:05 | |
| *** minute <[email protected]> has joined #litex | 04:05 | |
| *** pbsds <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 04:18 | |
| *** pbsds <[email protected]> has joined #litex | 04:18 | |
| *** pbsds <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 04:24 | |
| tpw_rules | how are the framebuffer colors supposed to be encoded? i've somehow got r and b swapped. but the colorbars look right | 04:59 |
| tpw_rules | in both rgb888 and rgb565 modes | 04:59 |
| tpw_rules | yeah these are definitely backwards | 05: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#L689 | 05:05 |
| tpw_rules | https://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 #litex | 05:29 | |
| slagernate | gatecat: would you happen to have your build script handy? You mentioned picorv32 was working for you | 05:33 |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #litex | 06: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 issue | 06:42 |
| _florent_ | slagernate: you just need to install Verilator for this | 06:42 |
| _florent_ | slagernate: 5) of https://github.com/enjoy-digital/litex/wiki/Installation | 06: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 well | 06:50 |
| *** Guest13 <[email protected]> has quit IRC (Quit: Client closed) | 06:51 | |
| slagernate | I.e. I am getting the BIOS output expected in https://github.com/enjoy-digital/litex/wiki/Installation | 06:51 |
| slagernate | It 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 |
| 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 | 06:56 |
| tnt | slagernate: did you try to build the older version ? | 07:38 |
| *** giggiu16 <[email protected]> has joined #litex | 07: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 #litex | 08: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 |
| Melkhior | Between 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#L173 | 09:59 |
| *** giggiu16 <[email protected]> has joined #litex | 09:59 | |
| Melkhior | and https://github.com/rdolbeau/NuBusFPGA/blob/d0d98f13900e6c19f28e0a76bf8fff20a5e923f4/nubus-to-ztex-gateware/goblin_fb.py#L211 | 10:02 |
| *** likewise <[email protected]> has joined #litex | 10: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 #litex | 11:33 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 11:34 | |
| *** Brinx <[email protected]> has joined #litex | 11:34 | |
| *** Brinx <[email protected]> has quit IRC (Remote host closed the connection) | 11:34 | |
| *** Brinx <[email protected]> has joined #litex | 11:34 | |
| *** giggiu16 <[email protected]> has joined #litex | 12:16 | |
| *** giggiu16 <[email protected]> has quit IRC (Client Quit) | 12:19 | |
| *** giggiu16 <[email protected]> has joined #litex | 12:19 | |
| tpw_rules | Melkhior: the problem is the colorbar module displays the wrong colors if the framebuffer displays the right colors | 12:24 |
| 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. | 12:25 |
| Melkhior | @tpw_rules then I'd say the colorbar module has an issue... | 12:30 |
| Melkhior | I admint I only cared for what Linux displays when using the FB when I originally tried the LItex FB :-) | 12:31 |
| tpw_rules | but the code in there is very straightforward | 12:31 |
| Melkhior | it is my firm opinion than endianess is _never_ straightforward :-) | 12:32 |
| tpw_rules | yeah but there's no endianness in the colorbar code. it's just like source.r.eq(0xff) # red | 12:32 |
| Melkhior | ouch | 12:33 |
| Melkhior | I don't know, seems weird | 12:37 |
| 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 ? | 12:40 |
| Melkhior | My version only worked through trial-and-error, not "this is how it should be" ... | 12:41 |
| tpw_rules | https://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 2 | 12:41 |
| tpw_rules | https://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_rules | did you use litex's hdmi phy? | 12:43 |
| Melkhior | this would explain that ... if both HDMI and FB are reversed, it all works out in the end | 12:44 |
| Melkhior | yes I use the LItex HDMI PHY | 12:44 |
| tpw_rules | unless you try to use the colorbars to test your color! | 12:44 |
| tpw_rules | then yeah your framebuffer reads are probably backwards too | 12:44 |
| Melkhior | also the VGA PHY, vaguely remember a discrepancy, but I'm not sure | 12:44 |
| Melkhior | X11 can accommodate both r8g8b8 and b8g8r8 and I changed it at some point while tracking down issues in my Xrender code | 12:46 |
| tpw_rules | so now it's triple backwards for you :) | 12:46 |
| tpw_rules | well i will try to submit a PR this weekend to get everything straightened out but i don't have any hdmi boards to test with | 12:47 |
| Melkhior | yes, at least... the host are big-endians (sparc or mac68k), but NuBus is LE (SBus is BE), then Wishbone ... | 12:47 |
| Melkhior | it's even more of a mess than a straightforward SoC | 12:48 |
| Melkhior | mmmmm | 12:49 |
| Melkhior | https://github.com/enjoy-digital/litex/commit/dc0a4ea40bddcbc9f96b08a8eb46c39ec6bfff20 | 12:49 |
| Melkhior | someone agrees with you! | 12:50 |
| tpw_rules | funny that that doesn't update the framebuffer code | 12:51 |
| Melkhior | might have tested only with the colorbar :-) | 12:51 |
| tpw_rules | also i guess github's search index didn't catch that yet | 12:52 |
| *** giggiu16 <[email protected]> has quit IRC (Quit: Client closed) | 12:53 | |
| tpw_rules | thanks for finding that. saves me a bit of work | 12:53 |
| Melkhior | no problem | 12:54 |
| 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) | 12:55 |
| Melkhior | (the acceleration stuff is not technically part of the FB) | 12:56 |
| trabucayre | this fix is to correct relation channel id <-> color according to DVI specs | 13:03 |
| trabucayre | tpw_rules: https://glenwing.github.io/docs/DVI-1.0.pdf fig. 3.2 p.26 | 13:07 |
| tpw_rules | trabucayre: yeah, your fix is correct | 13:18 |
| trabucayre | and no I've tested with the video terminal : https://twitter.com/GwenhaelG/status/1565053922812755969/photo/1 | 13:19 |
| trabucayre | :) | 13:20 |
| tpw_rules | no what? | 13:20 |
| trabucayre | Melkhior> might have tested only with the colorbar :-) | 13:25 |
| 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 | 13:27 |
| trabucayre | maybe another swap before video phy ? ( -1 x -1 = 1) | 13:29 |
| tpw_rules | did you test with the framebuffer? there is another swap in there that needs to be done | 14:18 |
| tpw_rules | or just the terminal? | 14:18 |
| trabucayre | not checked if framebuffer is used | 14:34 |
| trabucayre | but i think so | 14: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 #litex | 16:55 | |
| *** Brinx <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 16:59 | |
| tpw_rules | anybody used quartus PLLs with litex? it seems to be generating slightly bad frequencies that make quartus barf | 17:10 |
| *** TMM_ <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 17:29 | |
| *** TMM_ <[email protected]> has joined #litex | 17:29 | |
| 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? | 17:32 |
| tpw_rules | i mean being submodules they are inherently pinned by the version of the pythondata-cpu-vexriscv-smp itself, right? | 17:33 |
| zyp | right | 17:33 |
| zyp | so you should be able to do a bisect on the pythondata repo | 17:33 |
| minute | ah yeah | 17:35 |
| 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? | 18:19 |
| minute | with pythondata-cpu-vexriscv_smp @ 60c32b141906ea4b8ba6ec19c66a321a1477e55c everything is fine, no random oops in a bridge driver and no usb errors | 18:23 |
| minute | @ 4306ae2eb5464bc37d14eff9a3c051d7b0c17d0d does not build | 18: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 |
| minute | etc | 18:28 |
| slagernate | tnt: will try sometime tonight | 18:37 |
| minute | anyway https://github.com/litex-hub/pythondata-cpu-vexriscv_smp/issues/7 | 18:39 |
| *** likewise <[email protected]> has quit IRC (Quit: Client closed) | 18:55 | |
| *** zjason` <zjason`[email protected]> has joined #litex | 19:33 | |
| *** zjason <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 19:35 | |
| slagernate | tnt: (in ~5 hours) | 21:28 |
| minute | LiteX laptop https://twitter.com/minut_e/status/1575958855800205312 | 21:42 |
| slagernate | minute:sick | 21:44 |
| *** ewen <[email protected]> has joined #litex | 22:23 | |
| *** nelgau_ <[email protected]> has quit IRC (Remote host closed the connection) | 22:55 | |
| *** nelgau <[email protected]> has joined #litex | 22: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/!