<tnt>
There was several issues I had to work around. The first and second issues are from BIOS and Linux respectively. But the third one, I'd suspect is from the core getting locked up somehow.
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
<_florent_>
tnt: Good, I'll have a closer look. BTW would it be OK for you to put these notes in a LitePCIe Github issue? I think this could be useful to keep a trace of the issuses and future reference.
<tnt>
_florent_: Sure, I'll open an issue
<_florent_>
tnt: great, thanks!
<tnt>
I also saw in another issue the link status register should be viable using litex bridge so I want to take a look at that too.
<tnt>
But first I really need to put some fan control, this thing is unbearable.
<tnt>
Does litex have a auto fan pwm control from XADC sensors by any chance ? :D
<_florent_>
tnt: regarding link_status, I added this to debug specific systems on 7-series, not sure the register is present on Ultrascale (if not, we should :))
<_florent_>
tnt: would you like to add this or do you want me to add it?
<_florent_>
tnt: otherwise for the FAN control, we have the PWM core, the XADC core, but you'll have to connect them :)
<_florent_>
tnt: and regulation loops are always a bit specific to the hardware
<tnt>
I'll have a look at adding the LTSSM status. Probably good I get more familiar with the internals anyway.
<tnt>
I'll just add both and just setting it from the shell will be good enough for now. ATM I run it 30min with the fan disconnected then plug it for 5min so it can't be much worse :p
<_florent_>
cr1901: regarding the HyperRAM, as tnt said, the improvements directly come from avoiding the initial latency for each access
<_florent_>
cr1901: for write, we generate the ack early, letting the CPU generate another access and if a consecutive access if present at the end of the word transfer on the HyperRAM, we continue the burst
<_florent_>
cr1901: for read, the always read at least one additional burst and if the CPU generate another consecutive access, we just present it and read an additional word, etc...
<_florent_>
cr1901: the clock is not even stopped since the CPU can be run very fast on Titanium, but this could be useful for slower FPGAs
<_florent_>
tnt: First thing I generally do on FPGA dev boards is also disconnecting the fan :)
<tnt>
At least the 4x / 8x behavior is consistent with the previous tests on the old platform. 8x enumerates and reads the ID fine, but dma_test hangs.
<tnt>
_florent_: heh yeah, but it does get quite toasty, despite having almost nothing in the FPGA ATM. I'll look into a better fan than the "blower style" thing they put on there by default.
<_florent_>
tnt: ok that's already better yes
<_florent_>
tnt: Fans situation on FPGA dev boards is similar to what we had 20 years ago on computers, maybe at some points vendors will realize FPGA boards are generally on developers' desks and then should do something...
Melkhior_ has quit [Quit: Leaving]
Melkhior has joined #litex
bluecmd has quit [Quit: You have been kicked for being idle]
FabM has quit [Remote host closed the connection]
ejcspii has joined #litex
<amstan>
I find it super weird that the chips i worked with (cycloneV, aria10) don't include temp sensors either.