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]>
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 -.-
<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
<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).
<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?
<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]