04:33 <pepijndevos[m]> Huh what's that for?

08:11 <_florent_> cr1901, pepijndevos[m]: pythondata-auto are in fact just here to give us more flexibility for deployment vs git submodules. For private projects or experiments, this is not really useful.

08:13 <_florent_> Wolfvak: Can you verify that the default configuration is also only providing 64MiB? (./make.py --board=orangecrab --build --load)

08:14 <_florent_> Wolfvak: if so, I could have a look. (I could also have a look if not, but we'll then know that this related to the additional parameters).

13:09 <Wolfvak> _florent_, I've also been thinking it might just be a dtb thing since that's what indicates memory regions

13:09 <Wolfvak> I used the one from the gh issue with the latest for orangecrab

13:09 <Wolfvak> gonna try building the gw without any custom options too

13:10 <_florent_> Wolfvak: the LiteX BIOS should also report the DRAM size based on the one computed during the build, does it matches the one in Linux?

13:12 <Wolfvak> yep the BIOS reports the full 128MiB

13:13 <Wolfvak> and `hexdump /sys/firmware/devicetree/base/memory@40000000/reg` reports that the devicetree is wrong

13:38 <Wolfvak> btw there's a bug in line 765 of make.py, someone left a stray `...platforms.orangecrab`, should be `...platforms.gsd_orangecrab`

13:38 <Wolfvak> (or at least that fixed it for me, must've been a recent change)

13:54 <Wolfvak> and yeah, using the rv32.dtb I get with the build gives me 128 megs so that was my bad

14:27 <somlo> very early, alpha quality, read-only, experimental LiteSATA linux driver https://github.com/litex-hub/linux/commit/cd0693dc796834af1271617363b879641f624f91 (in the https://github.com/litex-hub/linux/tree/litex-rebase branch)

14:27 <somlo> https://pastebin.com/P4JKWn4t for a first (apparently successful) read test...

14:29 <somlo> now I gotta go and do $DAYJOB things for a while, will play a bit more with this over the next few days (add write support, get it to actually scan the disk for partitions, etc.)

16:56 <_florent_> somlo: Great, thanks , that's already a first good step!

16:57 <_florent_> somlo: I'll try to add the missing features in the interface soon (IRQs and allow running the Identify command from software)

17:20 <somlo> _florent_: no rush, it'll be a few days before I can play with it some more. Not sure whether it's worth enabling (requiring) the full SATA IdentifyDevice command given how well encapsulated the rest of the interface is, though

17:21 <somlo> maybe just exposing a register (e.g. part of the phy) that allows the software to read how many 512-byte sectors the device has total would be enough?

17:23 <somlo> and not having to read a sector as part of initialization would be nice (right now I need to use a global buffer, since dma-mapping anything on the stack of the probe method fails in linux)

17:24 <somlo> either way (except for the "don't make me read a buffer" thing) it's still mostly on me to improve the driver before we'd actually need any of the additional stuff (irq, identify/sector-count registers, etc)

23:14 <swetland> heya litex folks, I'm building some ethernet phy pmods (LAN8720A, expecting 50MHz clock from the MAC) -- is there a good example in one of the existing Litex board targets of configuring the ethernet MAC against a RMII PHY for 100TX, with the MAC providing the clock to the PHY?