_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 272 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
HoloIRCUser has joined #litex
HoloIRCUser1 has quit [Ping timeout: 264 seconds]
HoloIRCUser1 has joined #litex
HoloIRCUser has quit [Read error: Connection reset by peer]
HoloIRCUser has joined #litex
HoloIRCUser has quit [Client Quit]
HoloIRCUser1 has quit [Ping timeout: 246 seconds]
jeanthom has joined #litex
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Ping timeout: 246 seconds]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala__ has joined #litex
kgugala_ has quit [Read error: No route to host]
kgugala_ has joined #litex
kgugala__ has quit [Ping timeout: 246 seconds]
jeanthom has quit [Ping timeout: 265 seconds]
st-gourichon-fid has joined #litex
m4ssi has joined #litex
jeanthom has joined #litex
CarlFK has joined #litex
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Read error: No route to host]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Read error: No route to host]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
<pepijndevos> daveshah, I'm not changing the netlist at all, just reloading the RISC-V code.
<daveshah> oh, that's much weirder then
<daveshah> is the CPU resetting consistently with the same code?
<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
<pepijndevos> Yea
<pepijndevos> I can 100% reliably break it by commenting or uncommenting a certain line
<pepijndevos> I'm not even sure what sort of crash it is tbh
<disasm[m]> What's the line?
<disasm[m]> Maybe you have a bus stall
<pepijndevos> Some library code that calls my HAL/PAC stuff
<pepijndevos> I think if it's a hard reset it'd litex_term would try to reload it again
<pepijndevos> I think if it's a panic it'd at least run up to that point
<pepijndevos> The LED tracer animation it has on boot remains active
<pepijndevos> The first thing I do in my code is set the LEDs to something
<pepijndevos> If I have the broken code, nothing happens at all.
<pepijndevos> disasm[m], how would I detect a buss stall?
<disasm[m]> Just define your own panic handler and set LEDs to something inside it
<disasm[m]> <pepijndevos "disasm, how would I detect a bus"> By dumping one of the bus signals to one of LEDs
<pepijndevos> I did define a custom panic handler, which is not it seems.
<disasm[m]> This looks like a very long request on bus that doesn't finish
<pepijndevos> *not run
<pepijndevos> How... do I dump a bus signal to an LED? I assume that involves some deep digging around in LiteX internals...
<disasm[m]> `self.comb += led.eq(somewhere.inside.your.soc)`
<disasm[m]> But yeah, you need to extract the signal somehow
<disasm[m]> You can also create another wishbone master and examine its signals
<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?
<pepijndevos> What kind of thing can stall the bus? Is just busywaiting enough to have that effect? I would hope not.
<disasm[m]> <pepijndevos "What kind of thing can stall the"> Incorrect address or size, for example
<disasm[m]> Hmm, now I think you probably have a stack overflow
<pepijndevos> This sounds more likely actually...
<pepijndevos> hold on...
<disasm[m]> Check that you do not store there anything huge
<pepijndevos> But still... would that not at least run up to that point?
<pepijndevos> Ok I'll experiment a bit more
<disasm[m]> Because stack layout changes and you may end up with overflow earlier
<pepijndevos> Maybe it's another wonky linking issue -.-
<_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
<tpb> Title: litex/litex_sim.py at master · enjoy-digital/litex · GitHub (at github.com)
<_florent_> it's a LiteX SoC similiar to the examples targets that instead of running on hardware will run with Verilator
<_florent_> just try litex_sim and you should see the BIOS prompt
<_florent_> you can then add custom peripherals, run custom software, etc...
<_florent_> and just add --trace to generate the waveform which you'll be able to analyze
<_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
<tpb> Title: linux-on-litex-vexriscv/sim.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com)
<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.
<pepijndevos> OMG I fixed it... it was a linker problem
<pepijndevos> I was putting my bss and stack in sram, I thought that would make sense.
<pepijndevos> But apparently Rust uses enough stack space that that does not make sense.
<pepijndevos> Everything is in main ram now, and it does not crash.
<pepijndevos> It does not properly work either, but that's probably my own fault.
<pepijndevos> *also* my own fault
<pepijndevos> Is there *any* data that makes sense to store in the sram?
<zyp> sram exists because bios needs some working memory while it's initializing the main_ram
<zyp> after bios you can use it for whatever fits
<zyp> e.g. .data and/or .bss
<zyp> or you could use it for particularly latency sensitive stuff
<pepijndevos> I see ok
<pepijndevos> actually no you should be able to use that but it's disabled by default
<pepijndevos> oops
kgugala has joined #litex
kgugala_ has quit [Read error: No route to host]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 256 seconds]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala__ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Ping timeout: 246 seconds]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 264 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has quit [Read error: No route to host]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Read error: No route to host]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 246 seconds]
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 260 seconds]
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has joined #litex
kgugala__ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Ping timeout: 265 seconds]
kgugala has joined #litex
kgugala__ has quit [Ping timeout: 264 seconds]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 260 seconds]
<somlo> _florent_: re. PR #617 -- dropping the sdcard speed to 25000000 (half) gets the DMA-ed boot.bin to work perfectly
<somlo> I'll run a binary "search" to isolate the maximum speed that works for me, then update the PR with that information
<pepijndevos> hurray, my SPI peripheral is working great, but my GPIO one doesn't do anything.
<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...
kgugala has joined #litex
kgugala_ has quit [Read error: No route to host]
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Read error: No route to host]
kgugala_ has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 260 seconds]
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala has quit [Read error: No route to host]
kgugala_ has quit [Read error: No route to host]
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala_ has joined #litex
kgugala_ has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<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
<tpb> Title: View paste AFDA (at bpa.st)
<pepijndevos> The SPI is working great
<_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
<_florent_> somlo: we could merge the PR once update to work at a lowered frequency and i could implement the feature/increase the frequency.
<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
<_florent_> pepijndevos: strange, can you check the verilog or provide it?
<_florent_> pepijndevos: looking at your code, it seems correct
<pepijndevos> uh oh...
<pepijndevos> input wire oled_ctl_resn occurs once in the port and nowhere else
<pepijndevos> hold on... why is that an input??
<pepijndevos> I can upload the verilog if you want and know a suitable pastebin
<pepijndevos> There are some other oled bits present, so it's not like it's completely missing or anything
<tpb> Title: hastebin (at hastebin.com)
<pepijndevos> So maybe some nMigen bug then? Super weird.
<_florent_> i'm going to test your code snipet
<pepijndevos> which snippet? the code to add the GPIO?
<_florent_> yes
<_florent_> can you share the pads definition?
<pepijndevos> _florent_, https://bpa.st/YEPA
<tpb> Title: View paste YEPA (at bpa.st)
<pepijndevos> it's the OLED display on the ULX3S :))
<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.
<somlo> _florent_: ok, updated PR #617 -- Rocket DMA works fine with slowed-down LiteSDCard clock at 25MHz
MyGreenBalloon has joined #litex
<_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).
<_florent_> you can do
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<_florent_> then
<tpb> Title: Snippet | IRCCloud (at www.irccloud.com)
<pepijndevos> _florent_, waaaah, what does that do?
<pepijndevos> Is it something that is easy to fix? Would be happy to make a PR, but know basically zero nmigen.
<_florent_> i will have a look to fix this
<_florent_> BTW, we are still using Migen in LiteX, not nMigen :)
<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?
<tpb> Title: cores/gpio: add support for Record on GPIOOut, GPIOIn and GPIOInOut. · enjoy-digital/litex@2ec4604 · GitHub (at github.com)
<tpb> Title: litex-boards/trellisboard.py at master · litex-hub/litex-boards · GitHub (at github.com)
<tpb> Title: litex-boards/trellisboard.py at master · litex-hub/litex-boards · GitHub (at github.com)
m4ssi has quit [Remote host closed the connection]
<_florent_> add: platform.add_extension("_sdcard_pmod_io")
<pepijndevos> _florent_, awesome thanks :)) time to update I guess
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 265 seconds]
MyGreenBalloon has quit [Remote host closed the connection]
jeanthom has quit [Ping timeout: 256 seconds]
CarlFK has quit [Quit: Leaving.]
<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 :)
jeanthom has joined #litex
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #litex
<somlo> _florent_: turns out, CI had a valid complaint regarding axi_lite vs. wishbone address width assertions in the axi_lite <-> wishbone conversion modules
* 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 :)
jeanthom has quit [Ping timeout: 256 seconds]
tcal has joined #litex
jeanthom has joined #litex
DerFetzer[m] has joined #litex
CarlFK has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
jeanthom has quit [Ping timeout: 256 seconds]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
<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
<somlo> I want to see the values CI gets when the assertion fails, and how they're calculated
<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 :) )
FFY00 has quit [Remote host closed the connection]
jeanthom has joined #litex
FFY00 has joined #litex
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #litex
jeanthom has quit [Ping timeout: 246 seconds]
lf has quit [Ping timeout: 260 seconds]
lf has joined #litex