13:58 <benh_> _florent_: how did you simulate ? it works for me

13:58 <benh_> (the stack issue)

13:58 <benh_> _florent_: do you have the sram set to 0x2000 (8Kb) ?

13:58 <benh_> KB rather

13:59 <benh_> there *is* a bug in my code but I'm surprised it affects you :)

14:02 <benh_> _florent_: also what gcc / binutils are you using ? (actually respond on github, easier that way, I'm off to bed, I'll have a look tomorrow)

15:20 <_florent_> benh_: i just tested your proposed fix and it works in simulation: https://github.com/enjoy-digital/litex/commit/5b2f9c244dd71d2896f2bfca9a61c91f49f0251e

15:20 <tpb> Title: cores/cpu/microwatt: revert setup stack and fix missing subi %r1,%r1… · enjoy-digital/litex@5b2f9c2 · GitHub (at github.com)

18:45 <somlo> _florent_: I just diff-ed current master against 860ac1e2, and there are no sdcard related gateware changes

18:45 <somlo> that's the commit where I can still boot from sdcard (with litesdcard, slowly)

18:45 <somlo> so it's clearly a software bug we're still chasing

18:46 <_florent_> somlo: i also just started looking at this :)

18:47 <somlo> I built 860ac1e2 over the weekend, and got it to load and run `boot.bin` from sdcard successfully (it took a *long* time to load, but it worked)

18:48 <somlo> so (given the current litesdcard gateware) the breakage is somewhere in software; although the generic fatfs stuff seems to work fine for spi-sdcard

19:41 <_florent_> somlo: i got linux booting from sdcard with litesdcard, unfortunately github seems to be down so i can't push, the changes are: https://hastebin.com/epuhapulud.cs

19:41 <tpb> Title: hastebin (at hastebin.com)

19:42 <_florent_> somlo: can you do a test?

19:50 <keesj> why the flush cpu caches (line 62 of the hastbin?)

19:51 <_florent_> that's the next thing to investigate :)

19:51 <keesj> does all data go through the cache?

20:04 <somlo> _florent_: building now, will report back once I have it running. BTW, shouldn't we factor out busy_wait_us() (there's one in both spisdcard.c and in sdcard.c, and they look the same to me)

20:28 <Skip> _florent_: I've responded to https://github.com/enjoy-digital/liteeth/issues/38. Even with with_hw_init_reset = false the Ethernet core still requires the rst_n pad and still drives it. Is that expected?

20:29 <Skip> I tested with a current liteeth, but I didn't update anything else. Perhaps that's part of the problem?

20:54 <somlo> _florent_: besides the possibly duplicated `busy_wait_us()`, that patch does make it work for me (nexys4ddr, rocket)

22:12 <benh_> _florent_: somlo another "issue" is normally on power, the first 0x4000 of memory are exception vectors...

22:13 <benh_> something we need to "fix" if we ever going to have Linux working, we'll need DRAM at 0

22:13 <benh_> and "ideally" we need to keep that space free for vector in the bios in case it takes interrupts

22:14 <benh_> on "standalone" microwatt I have a control bit SW can use to select whether DRAM or block RAM is down at 0 but for flash, I'm thinking of adding a microwatt specific extension to allow the core to find its exceptions at f* instead of 0 during boot

22:21 <zyp> does it matter whether it's DRAM or block ram at 0 as long as it's writable?

22:23 <benh_> in theory no, but it would need to be more than 8K for Linux I think

22:24 <benh_> and it would force us to use CONFIG_RELOCATABLE which is unfortunate

22:24 <benh_> The kernel on powerpc likes just sitting at 0 and having RAM onwards from there

22:24 <benh_> it *can* run from elsewhere but it's a bit more messy (and includes some runtime overhead)

22:28 <zyp> okay, fair, I'm used to thinking from a bare metal perspective where things are a bit more flexible in regards to what goes where

22:28 <somlo> benh_: you can have a custom memory map for your CPU; Rocket wants the first 0x10000000 for its own "internal" SoC (the plic, and other stuff defined in chisel)

22:29 <zyp> I guess it should be easy enough to tell litex to put dram at 0

22:29 <somlo> https://github.com/enjoy-digital/litex/blob/master/litex/soc/cores/cpu/rocket/core.py#L79

22:29 <tpb> Title: litex/core.py at master · enjoy-digital/litex · GitHub (at github.com)

22:30 <somlo> so on Rocket the init address is 0x10000000, as far as LiteX is concerned, and I make sure to compile Rocket to jump there after it's done with its own internal initialization

22:30 <benh_> right, I don't think it's hard, I was just thinking out loud :-)

22:30 <benh_> we might need some trickery if we want to have sane exception vectors while running from BIOS before the OS boots

22:34 <zyp> by the way, how well does litex support memory maps >4G currently?

22:36 <zyp> the ecp5 board I'm working on got a sodimm socket that you can put an 8GB stick into (or 16GB if you can find one)

22:38 <somlo> zyp: I moved main_ram to 0x80000000 with nothing else above it so that RAM can grow contiguously with the availability of larger amounts

22:39 <somlo> but I never had access to anything with more than 1G (the trellisboard), so what would *actually* happen is untested, afaik

22:39 <somlo> to be precise, I moved main_ram to 0x80000000 for *Rocket*

22:40 <zyp> will be fun to see when I finish the board :)

23:09 <somlo> _florent_, keesj: on rocket it works fine even with the `flush_cpu_dcache()` call

23:10 <somlo> I'm wondering if on some CPUs the sdcard read/write sram buffers are marked cacheable, and then whatever hardware writes to them gets ignored by the CPU?

23:11 <somlo> * even *without* the `flush_cpu_dcache()` call (i.e., with that line commented out)

23:11 <somlo> getting tired of staring at this monitor, gotta go through my evening shut-down routine, catch y'all tomorrow :)

23:14 <benh_> somlo: I could support up to 52 bits of physical address with microwatt :)

23:49 <somlo> benh_: I'm fairly certain I can have > 32 on Rocket as well, I'm just too lazy to think about it in the absence of a board I can test on :)