<shenki>
shorne: I wasn't yet testing your changes, but I can do that once I get my kernel booting
<shenki>
23:45 < geertu> shenki: You need to build a kernel from litex-hub/linux#linux-rebase
<shenki>
i don't think that will help; the only driver that is relevant in that branch is the vexriscv interrupt controller
<shenki>
and that wouldn't be loaded as the device tree doesn't contain the compatible for that driver
<shenki>
also, I would expect to see early uart output before irqs enabled
<sajattack[m]>
<Melkhior> "sajattack: ilp32d requires..." <- I think maybe my linker supports ilp32d but my compiler doesn't? Does that make any sense?
<sajattack[m]>
I have my gcc toolchain and my kernel set to ilp32d, and I used the same toolchain to produce gdb, which resulted in ilp32d gdb, and I specified gcc with ilp32d as my linker, but I have no flag for rust to make it ilp32d
peeps[zen] has joined #litex
peepsalot has quit [Ping timeout: 260 seconds]
geertu has joined #litex
_whitelogger has joined #litex
<sajattack[m]>
nevermind, built an ilp32 gcc toolchain and now it's complaining it can't link soft float and hard float together
<sajattack[m]>
so rust must be using ilp32d
<sajattack[m]>
<Melkhior> "sajattack: ilp32d requires..." <- how did you configure gdb?
<sajattack[m]>
I learned how to get qemu and gdb to work together instead of trying to gdb on the actual board https://hastebin.com/urigazuruw.rust
<tpb>
Title: hastebin (at hastebin.com)
Degi has quit [Ping timeout: 268 seconds]
Degi has joined #litex
peeps[zen] is now known as peepsalot
alainlou has quit [Quit: Client closed]
Yam26 has joined #litex
<sajattack[m]>
so that seems to me like the stdout object is a nullptr
<Yam26>
Hello,
<Yam26>
I have a few questions about LPDDR4 ram. Is it appropriate to ask here? I have two channels LPDDR4. At 800MT/s, it's pretty reliable. But at 1000MT/s, the calibration is not reliable. If the calibration works, then I could run sdram_bist and use it with no problem. Can anyone give me a suggestion how to make the calibration more reliable? The
<Yam26>
one that seems to be a problem is the read leveling.
<Yam26>
yeah, I notice that. what do you think is the problem, why it is not clean.
<_florent_>
this could be some wrong electrical setting on the FPGA side or LPDDR4 side
<Yam26>
I see.
<Yam26>
it's highly possible :-)
<_florent_>
you can probably do some tests with different settings and see how it impacts the calibration
<_florent_>
shenki: For LiteEth TX: The MAC has N slots, the software first checks if a slot is available, if so, it can fill the SRAM memory and then initiate the Xfer through the start CSR that will fill the slot FIFO.
<Yam26>
Can you suggest the settings that I should try ? I read through LPDDR4 specification, it seems like I can do Vref calibration, but I don't think litedram is doing that.
<_florent_>
The core then starts the Xfer when the slot FIFO is non-empty and free the slot when the Xfer is done
<shenki>
for recieve, how does the hardware know that the slot has been read?
<leons>
IIRC you clear the receive event
<leons>
shenki: What do you mean by writing a model?
<_florent_>
For LiteETH RX, the core can only store the incoming packet if a slot is available
<_florent_>
Yam26: I'll try to have more information on the max validated sys_clk_freq with the LPDDR4 test board
<Yam26>
_florent_ thank you
<leons>
Where it should really be an EventSourceLevel. When you enable timestamping that already is the case. The EventSourcePulse doesn't really allow you to simply determine how many packets have been sent by the HW, you have to work around that in SW using the level CSR and it as far as I'm concerned that gets ugly quickly
<leons>
As soon as LiteX has versioned register sets in peripherals, we could modify it to use an EventSourceLevel and have the Linux driver detect that automatically
<shenki>
leons: this means software doesn't know how many packets have been sent?
<Yam26>
my board works fine at 50MHz, I'm pushing it. I need around 1000MT/s for my application. This is calculated assuming with 64 bits wide already.
<leons>
shenki: it can know, by knowing how many have been sent and what the contents of the level CSR are. But it would be much nicer to just couple the event to the source of the FIFO which the HW has anways
<leons>
That way you can in SW just loop until the event is deasserted
<leons>
and read a packet in every loop iteration. So the HW would tell you which slot to read. It would also make it possible to have an out-of-order send, for example when one would want to build a fancy LACP integration
<leons>
s/which slot to read/which slot is ready
<shenki>
I'm not following you completely. I do welcome improvements to the logic though!
<shenki>
If you want to add some documentation (or open an issue that describes your proposed improvement) I would be grateful
<leons>
I think it's an issue which has to first be solved on the HW side -- it would be a breaking interface change and we should introduce versioning into the register set by then
<leons>
Such that at least newer drivers could detect older HW
<shenki>
yeah, that is something we have to be careful of now that we have support in linux
<leons>
We're already stuck in the situation that older drivers will fail badly and silently on newer interfaces, because the current interface is not versioned. I think that's something we must improve on. Not every software can read in the SoCs header files and know what the registers look like. Sometimes you want to build your software ahead of time
<shenki>
Yeah. One way to mitigate this is to add new functionality to new registers below the current set
<shenki>
that won't always be possible of course
<leons>
I'm thinking of something like a 32-bit read-only register, of which the upper 16 bits are a counter for breaking changes and the lower 16 bits would be a bitmask of features the HW has
<leons>
shenki: yes, but changing the event handling in LiteEth would be an example of such a breaking change I think
<leons>
And IMHO at some point there should be a breaking change. We don't want to carry over legacy interfaces to the end of time...
<shenki>
yeah the bitmask idea is interesting. it would get messy; I'd prefer to collect up a set of improvements into a new major release of the gateware
<shenki>
the downside is that goes against the iterate quickly approach that we've been able to have so far
<leons>
There was an issue for that once, but if I remember correctly it didn't get much traction. florent, would you be open to revisiting that?
<leons>
As more drivers make it into upstream projects the problem is only going to get bigger
cr1901 has quit [Read error: Connection reset by peer]
<shenki>
another improvement to make would be to add DMA support to liteeth, instead of the CPU having to copy buffers into the SRAM
<leons>
Yup! All possible with a versioned interface :D
<shenki>
We can get about 30MBit on microwatt on the Arty currently. That goes up from ~20MBit with an optimised memcpy_io routine, so we're very much limited by copying packets in and out
<_florent_>
leons: I'm OK with this direction. We first need to improve the CSR mapping inside a module to simplify adding/removing registers inside a Module with a common API.
<_florent_>
Then we could add an API version register
<_florent_>
and update it each time the API is updated
<_florent_>
For the hardware capabilities, we would have to see if this would need to be regrouped in a single register or it would be spread in the different registers
<leons>
Makes a lot of sense. Do you want me to look into the CSR mapping?
<leons>
Alternatively I would even be fine with putting the register set versions in a different register set, which people could disable if they so desire. Sort of a “peripheral discovery core”. But that might lead to even more fragmentation.
<_florent_>
leons: Sorry if progress is this is slow on this, the scope if the project is very large and for now it's easier to have companies funding new features/customization than funding such evolutions/maintenance. I'm trying to get more people involved, but it can take time.
<_florent_>
leons: If you have time to look at the CSR mapping, this could be very useful yes.
<jevinskie[m]>
Hmm the triple speed reference demo from intel which works fine with my 10/100 adapter doesn’t even use tx_clk, just gtx_clk. I wonder if I have to feed gtx a 125 MHz clock and give the PHY core a 25 MHz clock divided from that?
michalsieron has joined #litex
michalsieron has quit [Quit: michalsieron]
emkat has joined #litex
<emkat>
Is it possible to simulate other targets than the simsoc with lxsim? I'd like to simulate my own soc which contains custom hardware modules.
<_florent_>
emkat: you can use lxsim as a basis and extend it with your custom modules
<emkat>
Should I do that by modifying litex_sim.py or is it possible to tell lxsim to use a different file?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
cr19011 has joined #litex
Yam26 has quit [Ping timeout: 256 seconds]
<_florent_>
emkat: For now youhave to modify litex_sim.py manually
<emkat>
_florent_: I just read the contents of lxsim and found out that it uses entry_points.txt to call litex.tools.litex_sim:main. So I think that means I can just copypaste litex_sim.py elsewhere, modify it as needed (but keeping the sim-related code) and run the main function, correct?
<emkat>
I have to go now, but thanks for your help!
emkat has quit [Quit: Leaving]
Las[m] has joined #litex
<Las[m]>
Hi, I'm trying to package Litex with Nix, and I need to figure out the dependencies. Is there anything other than Migen and Verilator?
<leons>
Doesn’t make sense to upstream to nixpkgs IMHO
<leons>
But I can offer to split out the packages into a non-Tock related repo this evening
<Las[m]>
Quite a coincidence
<leons>
It also features an updater script for the TOML-defined package versions
<Las[m]>
I'm going to upstream Migen FWIW
<leons>
That’s great, I think that makes sense
<leons>
But for all the LiteX packages, not so much
<Las[m]>
Where are those TOML-defined package versions?
<leons>
I have it on a staging branch currently. Only pushing to master once I’ve verified everything works. Let me upstream my local changes in a few hours
<leons>
s/upstream/push
<Las[m]>
Nice, thanks
<leons>
Does it sound good for you to just split out the LiteX package definitions in a separate repo? I worked hard on getting all the tests working with the package interdependencies using fixed-point function evaluation these past days
<Las[m]>
Yeah
<Las[m]>
wdym? Are you using something custom that isn't callPackage?
<leons>
I would rather concentrate our efforts on one repo instead of fragmenting everything :)
<leons>
I do use callPackage but there’s a ton of recursive dependencies for the check phase so I built a little magic to take care of it :)
<leons>
I don’t think it’s very relevant for the general LiteX channel, should we discuss this in a private chat once I’ve pushed it?
<Las[m]>
Sure.
<leons>
It’d be super great to have someone else involved as well, that means it’s going to be much better maintained :)
<mm001>
Hi! I have a beginner question regarding LiteX UDP. Maybe someone can help me. I have a RV901T board, and can build rgmii_test.py and load it with ISE impact. I can ping the board. Now I would like to make very simple UDP transfer, without CPU. I have seen in the code that the UDP core has sink and source.valid/ready/data. Can I directly access these signals in rgmii_test.py?
<mm001>
I have tested to wire the data[0] directly to the LED, just as a first test, like this: self.comb += platform.request("user_led").eq(ethcore.udp.rx.source.ready)
<mm001>
This must be wrong, because as soon as I send an udp packet to the board, the board somehow "crashes", does not respond to ping anymore.
<Las[m]>
Leon: I'm having issues joining your room BTW. Not sure if there's some federation issue between your instance and matrix.org.
<leons>
mhm, there shouldn't be - using it with others just fine. Perhaps you can invite me to a room instead?
<_florent_>
if you want to receive UDP data, you can use LiteEthUDP2StreamRX
<_florent_>
you'll get a valid/ready/data stream with your UDP data
<_florent_>
And you could do something similar to : self.sync += If(udp_rx.source.valid, leds.eq(udp_rx.source.data))
Martoni42 has joined #litex
pftbest has quit [Remote host closed the connection]
pftbest has joined #litex
pftbest has quit [Ping timeout: 260 seconds]
pftbest has joined #litex
cr19011 is now known as cr1901
<mm001>
Ok, thanks! I'll try that out. Can I put LiteEthUDP2StreamRX directly into the class RGMIITest? Or is the UDP in this class already connected to something else?
<mm001>
Sorry, I'm still a bit confused about what is connected how etc... By the way, the rgmii_test.py also crashes without my changes when I send a udp packet to it. I guess that's normal?
<_florent_>
mm001: it's probably crashing because udp.rx.source.ready is not set to 1
<_florent_>
it should not crash with self.comb += ethcore.udp.rx.source.ready.eq(1)
<_florent_>
I'll provide an example tomorrow
Martoni42 has quit [Ping timeout: 260 seconds]
<jevinskie[m]>
@ florent is the MII PHY core expected to work with a RGMII PHY if fed 25 MHz GTX clk? Or do I need to port the GMII PHY to altera ddr even though I’m only interested in 100 mbps mode right now?
futarisIRCcloud has joined #litex
alainlou has joined #litex
alainlou has quit [Client Quit]
<mm001>
@florent Just tested with self.comb += ethcore.udp.rx.source.ready.eq(1), still crashes on udp packet...
<mm001>
(just for your info)
mm001 has quit [Quit: Leaving]
mm001 has joined #litex
futarisIRCcloud has quit [Quit: Connection closed for inactivity]