| *** tpb has joined #litex | 00:00 | |
| *** Degi has quit IRC | 00:44 | |
| *** Degi has joined #litex | 00:47 | |
| *** FFY00 has quit IRC | 01:43 | |
| *** FFY00 has joined #litex | 01:44 | |
| *** jaseg has quit IRC | 02:21 | |
| *** jaseg has joined #litex | 02:22 | |
| *** FFY00 has quit IRC | 02:45 | |
| *** FFY00 has joined #litex | 02:46 | |
| *** HoloIRCUser1 has joined #litex | 04:41 | |
| *** HoloIRCUser has quit IRC | 04:42 | |
| *** HoloIRCUser has joined #litex | 04:42 | |
| *** HoloIRCUser1 has quit IRC | 04:42 | |
| *** kgugala_ has joined #litex | 05:28 | |
| *** HoloIRCUser1 has joined #litex | 05:30 | |
| *** HoloIRCUser has quit IRC | 05:30 | |
| *** kgugala_ has quit IRC | 05:31 | |
| *** kgugala_ has joined #litex | 05:31 | |
| *** kgugala has quit IRC | 05:32 | |
| *** HoloIRCUser has joined #litex | 05:39 | |
| *** HoloIRCUser1 has quit IRC | 05:42 | |
| *** HoloIRCUser1 has joined #litex | 05:43 | |
| *** HoloIRCUser has quit IRC | 05:43 | |
| *** HoloIRCUser has joined #litex | 06:00 | |
| *** HoloIRCUser1 has quit IRC | 06:02 | |
| *** HoloIRCUser1 has joined #litex | 06:03 | |
| *** HoloIRCUser has quit IRC | 06:03 | |
| *** HoloIRCUser has joined #litex | 06:15 | |
| *** HoloIRCUser1 has quit IRC | 06:18 | |
| *** jeanthom has joined #litex | 06:32 | |
| *** kgugala has joined #litex | 06:49 | |
| *** kgugala has quit IRC | 06:51 | |
| *** kgugala_ has quit IRC | 06:51 | |
| *** kgugala has joined #litex | 06:51 | |
| *** kgugala_ has joined #litex | 07:09 | |
| *** kgugala has quit IRC | 07:12 | |
| *** kgugala__ has joined #litex | 07:18 | |
| *** kgugala_ has quit IRC | 07:18 | |
| *** kgugala_ has joined #litex | 07:20 | |
| *** kgugala__ has quit IRC | 07:24 | |
| *** jeanthom has quit IRC | 08:06 | |
| *** st-gourichon-fid has joined #litex | 08:18 | |
| *** m4ssi has joined #litex | 08:29 | |
| *** jeanthom has joined #litex | 09:28 | |
| *** CarlFK has joined #litex | 09:35 | |
| *** kgugala has joined #litex | 09:55 | |
| *** kgugala has quit IRC | 09:55 | |
| *** kgugala_ has quit IRC | 09:56 | |
| *** kgugala has joined #litex | 09:56 | |
| *** kgugala_ has joined #litex | 10:06 | |
| *** kgugala has quit IRC | 10:09 | |
| *** kgugala_ has quit IRC | 10:09 | |
| *** kgugala has joined #litex | 10:09 | |
| *** kgugala_ has joined #litex | 10:11 | |
| *** kgugala has quit IRC | 10:13 | |
| *** kgugala_ has quit IRC | 10:13 | |
| *** kgugala_ has joined #litex | 10:14 | |
| pepijndevos | daveshah, I'm not changing the netlist at all, just reloading the RISC-V code. | 10:39 |
|---|---|---|
| daveshah | oh, that's much weirder then | 10:39 |
| daveshah | is the CPU resetting consistently with the same code? | 10:39 |
| pepijndevos | However, the idea that it could not only be a bug in my code, or even the compiler, but it could even be a CPU bug or a synthesis bug is dreadful haha | 10:40 |
| pepijndevos | Yea | 10:40 |
| pepijndevos | I can 100% reliably break it by commenting or uncommenting a certain line | 10:41 |
| pepijndevos | I'm not even sure what sort of crash it is tbh | 10:41 |
| disasm[m] | What's the line? | 10:41 |
| disasm[m] | Maybe you have a bus stall | 10:41 |
| pepijndevos | Some library code that calls my HAL/PAC stuff | 10:42 |
| pepijndevos | I think if it's a hard reset it'd litex_term would try to reload it again | 10:42 |
| pepijndevos | I think if it's a panic it'd at least run up to that point | 10:43 |
| pepijndevos | The LED tracer animation it has on boot remains active | 10:43 |
| pepijndevos | The first thing I do in my code is set the LEDs to something | 10:43 |
| pepijndevos | If I have the broken code, nothing happens at all. | 10:44 |
| pepijndevos | disasm[m], how would I detect a buss stall? | 10:44 |
| disasm[m] | Just define your own panic handler and set LEDs to something inside it | 10:44 |
| disasm[m] | <pepijndevos "disasm, how would I detect a bus"> By dumping one of the bus signals to one of LEDs | 10:44 |
| pepijndevos | I did define a custom panic handler, which is not it seems. | 10:45 |
| disasm[m] | This looks like a very long request on bus that doesn't finish | 10:45 |
| pepijndevos | *not run | 10:45 |
| pepijndevos | How... do I dump a bus signal to an LED? I assume that involves some deep digging around in LiteX internals... | 10:47 |
| disasm[m] | `self.comb += led.eq(somewhere.inside.your.soc)` | 10:50 |
| disasm[m] | But yeah, you need to extract the signal somehow | 10:50 |
| disasm[m] | You can also create another wishbone master and examine its signals | 10:50 |
| pepijndevos | But... okay, so imagine my HAL is horribly broken and it locks up the bus, would it not still run the first part of the code up to it touching the HAL? | 10:51 |
| pepijndevos | What kind of thing can stall the bus? Is just busywaiting enough to have that effect? I would hope not. | 10:53 |
| disasm[m] | <pepijndevos "What kind of thing can stall the"> Incorrect address or size, for example | 10:53 |
| disasm[m] | Hmm, now I think you probably have a stack overflow | 10:53 |
| pepijndevos | This sounds more likely actually... | 10:54 |
| pepijndevos | hold on... | 10:54 |
| disasm[m] | Check that you do not store there anything huge | 10:54 |
| pepijndevos | But still... would that not at least run up to that point? | 10:55 |
| pepijndevos | Ok I'll experiment a bit more | 10:55 |
| disasm[m] | Because stack layout changes and you may end up with overflow earlier | 10:55 |
| pepijndevos | Maybe it's another wonky linking issue -.- | 10:56 |
| _florent_ | pepijndevos: if you want to work on software with a good visibility of what is going on in the hardware, you can use litex_sim: https://github.com/enjoy-digital/litex/blob/master/litex/tools/litex_sim.py | 11:11 |
| tpb | Title: litex/litex_sim.py at master · enjoy-digital/litex · GitHub (at github.com) | 11:11 |
| _florent_ | it's a LiteX SoC similiar to the examples targets that instead of running on hardware will run with Verilator | 11:12 |
| _florent_ | just try litex_sim and you should see the BIOS prompt | 11:12 |
| _florent_ | you can then add custom peripherals, run custom software, etc... | 11:13 |
| _florent_ | and just add --trace to generate the waveform which you'll be able to analyze | 11:13 |
| _florent_ | We are using for example a custom version here: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py to boot linux with it in simulation and this has been very useful to the the VexRiscv SMP integration | 11:15 |
| tpb | Title: linux-on-litex-vexriscv/sim.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 11:15 |
| pepijndevos | _florent_, thanks, that's a good suggestion. The question is just if it's reproducible when removing my Rust HAL hacks from the equation. But it's a good test to rule out some problems. | 11:22 |
| pepijndevos | OMG I fixed it... it was a linker problem | 11:28 |
| pepijndevos | I was putting my bss and stack in sram, I thought that would make sense. | 11:28 |
| pepijndevos | But apparently Rust uses enough stack space that that does not make sense. | 11:29 |
| pepijndevos | Everything is in main ram now, and it does not crash. | 11:29 |
| pepijndevos | It does not properly work either, but that's probably my own fault. | 11:29 |
| pepijndevos | *also* my own fault | 11:29 |
| pepijndevos | Is there *any* data that makes sense to store in the sram? | 11:33 |
| zyp | sram exists because bios needs some working memory while it's initializing the main_ram | 11:34 |
| zyp | after bios you can use it for whatever fits | 11:35 |
| zyp | e.g. .data and/or .bss | 11:35 |
| zyp | or you could use it for particularly latency sensitive stuff | 11:37 |
| pepijndevos | I see ok | 11:41 |
| pepijndevos | actually no you should be able to use that but it's disabled by default | 11:56 |
| pepijndevos | oops | 11:56 |
| *** kgugala has joined #litex | 12:38 | |
| *** kgugala_ has quit IRC | 12:39 | |
| *** kgugala has quit IRC | 12:39 | |
| *** kgugala has joined #litex | 12:39 | |
| *** kgugala_ has joined #litex | 12:41 | |
| *** kgugala has quit IRC | 12:44 | |
| *** kgugala_ has quit IRC | 12:45 | |
| *** kgugala has joined #litex | 12:45 | |
| *** kgugala_ has joined #litex | 12:47 | |
| *** kgugala has quit IRC | 12:47 | |
| *** kgugala has joined #litex | 12:47 | |
| *** kgugala_ has quit IRC | 12:48 | |
| *** kgugala_ has joined #litex | 12:48 | |
| *** kgugala__ has joined #litex | 12:49 | |
| *** kgugala has quit IRC | 12:49 | |
| *** kgugala_ has quit IRC | 12:52 | |
| *** kgugala has joined #litex | 12:59 | |
| *** kgugala__ has quit IRC | 13:00 | |
| *** kgugala has quit IRC | 13:01 | |
| *** kgugala has joined #litex | 13:01 | |
| *** kgugala_ has joined #litex | 13:02 | |
| *** kgugala_ has quit IRC | 13:03 | |
| *** kgugala has quit IRC | 13:03 | |
| *** kgugala has joined #litex | 13:03 | |
| *** kgugala_ has joined #litex | 13:04 | |
| *** kgugala has quit IRC | 13:07 | |
| *** kgugala has joined #litex | 13:07 | |
| *** kgugala_ has quit IRC | 13:09 | |
| *** kgugala has quit IRC | 13:09 | |
| *** kgugala has joined #litex | 13:09 | |
| *** kgugala_ has joined #litex | 13:11 | |
| *** kgugala has quit IRC | 13:11 | |
| *** kgugala has joined #litex | 13:13 | |
| *** kgugala has quit IRC | 13:15 | |
| *** kgugala has joined #litex | 13:16 | |
| *** kgugala_ has quit IRC | 13:16 | |
| *** kgugala_ has joined #litex | 13:17 | |
| *** kgugala has quit IRC | 13:17 | |
| *** kgugala_ has quit IRC | 13:20 | |
| *** kgugala_ has joined #litex | 13:20 | |
| *** kgugala has joined #litex | 13:21 | |
| *** kgugala__ has joined #litex | 13:22 | |
| *** kgugala has quit IRC | 13:22 | |
| *** kgugala_ has quit IRC | 13:25 | |
| *** kgugala has joined #litex | 13:38 | |
| *** kgugala__ has quit IRC | 13:42 | |
| *** kgugala_ has joined #litex | 13:44 | |
| *** kgugala has quit IRC | 13:48 | |
| somlo | _florent_: re. PR #617 -- dropping the sdcard speed to 25000000 (half) gets the DMA-ed boot.bin to work perfectly | 13:55 |
| somlo | I'll run a binary "search" to isolate the maximum speed that works for me, then update the PR with that information | 13:56 |
| pepijndevos | hurray, my SPI peripheral is working great, but my GPIO one doesn't do anything. | 13:56 |
| somlo | looks like routing DMA through Rocket is slow, for some reason -- might be the repeated WB-to-AXI and data width conversions, or might just be rocket internals, that's still TBD... | 13:57 |
| *** kgugala has joined #litex | 14:02 | |
| *** kgugala_ has quit IRC | 14:03 | |
| *** kgugala_ has joined #litex | 14:03 | |
| *** kgugala has quit IRC | 14:04 | |
| *** kgugala has joined #litex | 14:04 | |
| *** kgugala_ has quit IRC | 14:05 | |
| *** kgugala_ has joined #litex | 14:05 | |
| *** kgugala has quit IRC | 14:06 | |
| *** kgugala has joined #litex | 14:06 | |
| *** kgugala_ has quit IRC | 14:07 | |
| *** kgugala_ has joined #litex | 14:07 | |
| *** kgugala has quit IRC | 14:11 | |
| *** kgugala has joined #litex | 14:14 | |
| *** kgugala has quit IRC | 14:15 | |
| *** kgugala_ has quit IRC | 14:15 | |
| *** kgugala_ has joined #litex | 14:15 | |
| *** kgugala has joined #litex | 14:17 | |
| *** kgugala_ has quit IRC | 14:17 | |
| *** kgugala_ has joined #litex | 14:18 | |
| *** kgugala has quit IRC | 14:21 | |
| *** kgugala_ has quit IRC | 14:21 | |
| *** kgugala has joined #litex | 14:21 | |
| *** kgugala has quit IRC | 14:28 | |
| *** kgugala_ has joined #litex | 14:30 | |
| *** kgugala_ has quit IRC | 14:31 | |
| *** kgugala has joined #litex | 14:31 | |
| pepijndevos | What am I doing wrong??? I can set the pins and it works, but if I use GPIOOut I can write to the register but nothing happens. https://bpa.st/AFDA | 14:40 |
| tpb | Title: View paste AFDA (at bpa.st) | 14:40 |
| pepijndevos | The SPI is working great | 14:41 |
| _florent_ | somlo: interesting, so that's why i suspected, strange the DMA bus is that slow on Rocket, i know how to handle this easily (stopping the SD clocker when the read fifo is almost full) and will try to implement it in the next days | 15:21 |
| _florent_ | somlo: we could merge the PR once update to work at a lowered frequency and i could implement the feature/increase the frequency. | 15:22 |
| pepijndevos | ahhhhhh going crazy... I can manually configure the pins with some nMigen, so my pin mapping is ok. To rule out my Rust code I'm now poking the address right from litex_term, if I write 0xffffffff to it, it reads back as 0x07000000, seemingly indicating 3 ones corresponding to my 3 wires | 15:28 |
| _florent_ | pepijndevos: strange, can you check the verilog or provide it? | 15:29 |
| _florent_ | pepijndevos: looking at your code, it seems correct | 15:29 |
| pepijndevos | uh oh... | 15:30 |
| pepijndevos | input wire oled_ctl_resn occurs once in the port and nowhere else | 15:30 |
| pepijndevos | hold on... why is that an input?? | 15:31 |
| pepijndevos | I can upload the verilog if you want and know a suitable pastebin | 15:34 |
| pepijndevos | There are some other oled bits present, so it's not like it's completely missing or anything | 15:35 |
| pepijndevos | https://hastebin.com/jatucaliho.php | 15:36 |
| tpb | Title: hastebin (at hastebin.com) | 15:36 |
| pepijndevos | So maybe some nMigen bug then? Super weird. | 15:38 |
| _florent_ | i'm going to test your code snipet | 15:44 |
| pepijndevos | which snippet? the code to add the GPIO? | 15:46 |
| _florent_ | yes | 15:47 |
| _florent_ | can you share the pads definition? | 15:47 |
| pepijndevos | _florent_, https://bpa.st/YEPA | 15:48 |
| tpb | Title: View paste YEPA (at bpa.st) | 15:48 |
| pepijndevos | it's the OLED display on the ULX3S :)) | 15:49 |
| pepijndevos | I can also make a PR with all the changes if you want. This header is kinda specifically for this display, and it's behind a flag like the SD card. | 15:55 |
| somlo | _florent_: ok, updated PR #617 -- Rocket DMA works fine with slowed-down LiteSDCard clock at 25MHz | 16:11 |
| *** MyGreenBalloon has joined #litex | 16:26 | |
| _florent_ | pepijndevos: sorry got interrupted, the issue is that GPIOOut does not work on record or pads (we should allow it, or generate an error). | 16:30 |
| _florent_ | you can do | 16:30 |
| _florent_ | https://www.irccloud.com/pastebin/JfD2NxMT/ | 16:30 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 16:30 |
| _florent_ | then | 16:30 |
| _florent_ | https://www.irccloud.com/pastebin/kvdzjniW/ | 16:30 |
| tpb | Title: Snippet | IRCCloud (at www.irccloud.com) | 16:30 |
| pepijndevos | _florent_, waaaah, what does that do? | 16:35 |
| pepijndevos | Is it something that is easy to fix? Would be happy to make a PR, but know basically zero nmigen. | 16:36 |
| _florent_ | i will have a look to fix this | 16:37 |
| _florent_ | BTW, we are still using Migen in LiteX, not nMigen :) | 16:37 |
| somlo | _florent_: oh, and my microSD pmod dongle just got delivered, so I can try it on my trellisboard -- can you shoot me the build command line you used to direct LiteSDCard to use the pmod instead of the built-in pins? | 16:45 |
| _florent_ | pepijndevos: this should now be fine with: https://github.com/enjoy-digital/litex/commit/2ec4604c41a828634be9029babe17281d4be0825 | 16:49 |
| tpb | Title: cores/gpio: add support for Record on GPIOOut, GPIOIn and GPIOInOut. · enjoy-digital/litex@2ec4604 · GitHub (at github.com) | 16:49 |
| _florent_ | somlo: you can comment out: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/trellisboard.py#L152-L157 | 16:50 |
| tpb | Title: litex-boards/trellisboard.py at master · litex-hub/litex-boards · GitHub (at github.com) | 16:50 |
| _florent_ | and here: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/trellisboard.py#L249 | 16:51 |
| *** m4ssi has quit IRC | 16:51 | |
| tpb | Title: litex-boards/trellisboard.py at master · litex-hub/litex-boards · GitHub (at github.com) | 16:51 |
| _florent_ | add: platform.add_extension("_sdcard_pmod_io") | 16:51 |
| pepijndevos | _florent_, awesome thanks :)) time to update I guess | 16:53 |
| *** kgugala_ has joined #litex | 17:02 | |
| *** kgugala has quit IRC | 17:04 | |
| *** kgugala has joined #litex | 17:15 | |
| *** kgugala_ has quit IRC | 17:19 | |
| *** MyGreenBalloon has quit IRC | 17:22 | |
| *** jeanthom has quit IRC | 17:33 | |
| *** CarlFK has quit IRC | 17:40 | |
| somlo | _florent_: I'm a total CI n00b, but if it's simply a matter of getting it to stop complaining about wishbone adr_width being bumped to 31 (probably a bunch of the tests are hardcoding 30?) -- I can try and pattern-match my way through an attempt to shut it up :) | 17:59 |
| *** jeanthom has joined #litex | 18:28 | |
| *** jeanthom has quit IRC | 18:54 | |
| *** jeanthom has joined #litex | 19:00 | |
| somlo | _florent_: turns out, CI had a valid complaint regarding axi_lite vs. wishbone address width assertions in the axi_lite <-> wishbone conversion modules | 19:04 |
| * somlo wonders how come these assertions didn't get triggered during actual builds, in which case I'd have figured it out before CI got all upset with me :) | 19:04 | |
| *** jeanthom has quit IRC | 19:25 | |
| *** tcal has joined #litex | 19:30 | |
| *** jeanthom has joined #litex | 19:40 | |
| *** DerFetzer[m] has joined #litex | 20:11 | |
| *** CarlFK has joined #litex | 20:12 | |
| *** FFY00 has quit IRC | 20:17 | |
| *** FFY00 has joined #litex | 20:18 | |
| *** FFY00 has quit IRC | 20:19 | |
| *** FFY00 has joined #litex | 20:20 | |
| *** jeanthom has quit IRC | 20:27 | |
| *** FFY00 has quit IRC | 20:46 | |
| *** FFY00 has joined #litex | 20:48 | |
| somlo | _florent_: I added a temporary patch that makes assert print out the offending values. When building with rocket, axi address width is 32, length of wb_adr is 29, and the wb_adr_shift is 3, and they all add up nicely with the original assert | 21:05 |
| somlo | I want to see the values CI gets when the assertion fails, and how they're calculated | 21:08 |
| somlo | I suspect those asserts will have to be updated, but simply adding a " - 1" to the mix isn't enough (while it shuts up CI, it doesn't actually work on Rocket :) ) | 21:09 |
| *** FFY00 has quit IRC | 21:16 | |
| *** jeanthom has joined #litex | 21:16 | |
| *** FFY00 has joined #litex | 21:17 | |
| *** FFY00 has quit IRC | 21:18 | |
| *** FFY00 has joined #litex | 21:19 | |
| *** jeanthom has quit IRC | 21:28 | |
| *** lf has quit IRC | 23:23 | |
| *** lf has joined #litex | 23:23 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!