| *** tpb has joined #litex | 00:00 | |
| *** _whitelogger has quit IRC | 00:30 | |
| *** _whitelogger has joined #litex | 00:32 | |
| *** Skip has quit IRC | 00:47 | |
| *** futarisIRCcloud has quit IRC | 02:03 | |
| *** Degi has quit IRC | 02:08 | |
| *** Degi has joined #litex | 02:09 | |
| *** futarisIRCcloud has joined #litex | 03:24 | |
| *** _whitelogger has quit IRC | 04:00 | |
| *** _whitelogger has joined #litex | 04:02 | |
| *** _whitelogger has quit IRC | 04:24 | |
| *** _whitelogger has joined #litex | 04:26 | |
| *** st-gourichon-fid has joined #litex | 05:44 | |
| *** _whitelogger has quit IRC | 07:00 | |
| *** _whitelogger has joined #litex | 07:02 | |
| 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:58 |
| benh_ | there *is* a bug in my code but I'm surprised it affects you :) | 13:59 |
| 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) | 14:02 |
| _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) | 15:20 |
| *** Skip has joined #litex | 15:56 | |
| *** CarlFK has quit IRC | 16:41 | |
| 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:45 |
| _florent_ | somlo: i also just started looking at this :) | 18:46 |
| 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:47 |
| 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 | 18:48 |
| _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:41 |
| _florent_ | somlo: can you do a test? | 19:42 |
| *** CarlFK has joined #litex | 19:48 | |
| keesj | why the flush cpu caches (line 62 of the hastbin?) | 19:50 |
| _florent_ | that's the next thing to investigate :) | 19:51 |
| keesj | does all data go through the cache? | 19:51 |
| 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:04 |
| 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:28 |
| Skip | I tested with a current liteeth, but I didn't update anything else. Perhaps that's part of the problem? | 20:29 |
| somlo | _florent_: besides the possibly duplicated `busy_wait_us()`, that patch does make it work for me (nexys4ddr, rocket) | 20:54 |
| *** st-gourichon-fid has quit IRC | 21:01 | |
| *** st-gourichon-fid has joined #litex | 21:03 | |
| *** st-gourichon-fid has quit IRC | 21:11 | |
| *** Skip has quit IRC | 21:51 | |
| *** Skip has joined #litex | 22:04 | |
| benh_ | _florent_: somlo another "issue" is normally on power, the first 0x4000 of memory are exception vectors... | 22:12 |
| 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:13 |
| 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:14 |
| zyp | does it matter whether it's DRAM or block ram at 0 as long as it's writable? | 22:21 |
| benh_ | in theory no, but it would need to be more than 8K for Linux I think | 22:23 |
| 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:24 |
| 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:28 |
| 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:29 |
| 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:30 |
| zyp | by the way, how well does litex support memory maps >4G currently? | 22:34 |
| 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:36 |
| 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:38 |
| 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:39 |
| zyp | will be fun to see when I finish the board :) | 22:40 |
| somlo | _florent_, keesj: on rocket it works fine even with the `flush_cpu_dcache()` call | 23:09 |
| 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:10 |
| 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:11 |
| benh_ | somlo: I could support up to 52 bits of physical address with microwatt :) | 23:14 |
| 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 :) | 23:49 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!