| *** tpb has joined #litex | 00:00 | |
| xobs | Are there any examples of using the built-in litex SpiFlashDualQuad with write support and/or raw SPI commands? | 02:18 |
|---|---|---|
| xobs | I see, spiflash.c contains code to do that, if you set with_bitbang=True | 02:42 |
| futarisIRCcloud | Just noticed that some boards have moved, e.g. ac701.py : | 02:46 |
| futarisIRCcloud | https://github.com/litex-hub/litex-boards/blob/master/litex_boards/community/targets/ac701.py | 02:46 |
| tpb | Title: litex-boards/ac701.py at master · litex-hub/litex-boards · GitHub (at github.com) | 02:46 |
| *** spacekookie has quit IRC | 04:23 | |
| *** spacekookie has joined #litex | 04:23 | |
| *** rohitksingh_work has joined #litex | 04:54 | |
| *** tweakoz has joined #litex | 05:07 | |
| *** rohitksingh_wor1 has joined #litex | 05:57 | |
| *** rohitksingh_work has quit IRC | 05:59 | |
| *** tweakoz has quit IRC | 06:09 | |
| *** RedMercury has joined #litex | 07:14 | |
| *** RedMercury has quit IRC | 07:37 | |
| *** neonking has quit IRC | 07:40 | |
| _florent_ | xobs: i just saw https://github.com/im-tomu/foboot/issues/12#issuecomment-509123057 | 08:37 |
| tpb | Title: Replace PicoSoC XIP flash controller with LiteX version · Issue #12 · im-tomu/foboot · GitHub (at github.com) | 08:37 |
| xobs | _florent_: I'm trying to figure out what's different. | 08:37 |
| xobs | One thing I've just discovered is that SRAM and the CSRs appears to have moved. | 08:38 |
| _florent_ | xobs: anything i can do to help? can you give me the configuration you are using or give me a link to your SoC? | 08:38 |
| xobs | Now CSRs overlap with my SRAM region, which might be causing some problems. | 08:38 |
| _florent_ | xobs: ah indeed | 08:38 |
| _florent_ | xobs: you can still use the old mem_map if it's easier for now | 08:38 |
| _florent_ | xobs: you just need to force it on your SoC | 08:39 |
| _florent_ | xobs: if you give me a link to your SoC, i'll tell you what needs to be done | 08:39 |
| xobs | I just moved my SRAM to 0x01000000 and now it's working again. | 08:40 |
| xobs | So the issue was that there was an overlap in the "csr" region and my "sram" region, which was causing RAM to silently not be accessible. | 08:40 |
| _florent_ | ok good, interesting, i would need to investigate | 08:41 |
| _florent_ | would you mind creating an issue with for that? | 08:42 |
| xobs | Sure thing! | 08:42 |
| _florent_ | for info, here are the mem_map changes: https://github.com/enjoy-digital/litex/commit/9d170b09442f1f5947b7a024639339397bcab6b0 | 08:43 |
| tpb | Title: soc_core: rearrange default mem_map · enjoy-digital/litex@9d170b0 · GitHub (at github.com) | 08:43 |
| _florent_ | we no longer have the 256MB limitation, so the idea was to free up the space after main_ram for boards that have > 512MB of memory | 08:44 |
| _florent_ | but that's only a default mem_map and you can still use a custom mem_map when needed | 08:45 |
| _florent_ | here is how we can force the mem_map: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/soc_linux.py#L25 | 08:46 |
| tpb | Title: linux-on-litex-vexriscv/soc_linux.py at master · litex-hub/linux-on-litex-vexriscv · GitHub (at github.com) | 08:46 |
| xobs | I noticed that when I went through "git log" trying to figure out what changed to break my design. I think I have it working now! | 08:48 |
| _florent_ | ok good, thanks for the issue, a check is probably missing, i'll fix that | 08:51 |
| *** neonking has joined #litex | 09:37 | |
| somlo | want a *64-bit* RISC-V free-as-in-freedom computer that can run upstream Linux? check out http://www.contrib.andrew.cmu.edu/~somlo/BTCP/ | 12:48 |
| tpb | Title: A Trustworthy Free/Libre Linux Capable 64bit RISC-V Computer (at www.contrib.andrew.cmu.edu) | 12:48 |
| _florent_ | somlo: thanks | 13:13 |
| keesj | I am thinking of running my home server on the arty | 13:17 |
| keesj | I do think I want to rely on debian for the base system | 13:19 |
| *** rohitksingh_wor1 has quit IRC | 13:19 | |
| keesj | https://wiki.debian.org/RISC-V | 13:19 |
| tpb | Title: RISC-V - Debian Wiki (at wiki.debian.org) | 13:19 |
| *** neonking has quit IRC | 13:44 | |
| somlo | _florent_: thanks for the csr alignment patch, 64bit test in progress. Might have a small fix-up PR, once I'm done testing :) | 14:15 |
| somlo | _florent_: https://github.com/enjoy-digital/litex/pull/214 | 14:58 |
| tpb | Title: soc_core: additional csr_alignment follow-up fixes by gsomlo · Pull Request #214 · enjoy-digital/litex · GitHub (at github.com) | 14:58 |
| somlo | _florent_: I also ran a "grep -r '4\*' --include=*.py" in the litex repo top-level directory and got a bunch of "addr + 4*i" results in e.g. litex/tools/litex_client.py, comm_usb.py, etc. -- not sure if any of that has anything to do with CSR alignment, but it's not part of the follow-up PR #214 (which gets things working for me in sim and on the nexys4ddr) | 15:01 |
| daveshah | somlo: can you send me a prebuilt boot image for the rocket linux? | 15:29 |
| daveshah | I think I have it fitting on a Versa ECP5 now with highly experimental (possibly broken) DSP inference and a reduced threshold for picking BRAM over DRAM (this causes the ethernet domain to fail timing, but I'm turning a blind eye to that) along with the old -abc9 -widelut | 16:02 |
| daveshah | But I'm on a bad internet connection and don't have a suitable 64-bit RISC-V toolchain set up so can't actually see if it goes into Linux yet | 16:03 |
| daveshah | Annoyed that the Arch-provided riscv64 gcc only seems to have lp64d abi support | 16:04 |
| daveshah | \o/ got as far as Kernel panic - not syncing: incorrect cpio method used: use -H newc option | 16:24 |
| daveshah | \o/ it works, after adding -H newc | 16:28 |
| daveshah | somlo: if you want to try this, use Yosys from https://github.com/daveshah1/yosys/tree/ecp5_rocket_versa5g and `synth_ecp5 -abc9 -nowidelut -dsp` | 16:28 |
| tpb | Title: GitHub - daveshah1/yosys at ecp5_rocket_versa5g (at github.com) | 16:28 |
| daveshah | You'll have to ignore the timing failure in the ethernet domain for now, but it seems to be inconsequential | 16:29 |
| flammit | xobs: thanks for the tip on the spiflash.c/bitbang! it's exactly what i was trying to accomplish (though from linux userspace) | 16:45 |
| daveshah | Hmm, looks like *lowering* the system clock frequency from 75MHz to 50MHz so it passes timing causes TFTP boot to fail | 16:55 |
| daveshah | but it works reliably enough at the overclocked 75MHz | 16:55 |
| sorear | is the *MII clock somehow being generated from the 75mhz? | 17:09 |
| daveshah | Nope | 17:09 |
| daveshah | Totally different domain | 17:09 |
| daveshah | seems fine at 60MHz too | 17:09 |
| somlo | daveshah: http://mirror.ini.cmu.edu/boot.bin (sorry for the delay, had to step out of the office for a few hours) | 18:26 |
| somlo | daveshah: wait a sec, that one's broken, uploading a working one :) | 18:26 |
| daveshah | no problem, I managed to build one in the end anyway | 18:27 |
| somlo | oh, ok | 18:27 |
| daveshah | Forced me to set up the toolchain | 18:27 |
| daveshah | Will be useful in the future anywau | 18:27 |
| daveshah | Your instructions seem good other than the cpio issue above | 18:28 |
| daveshah | Perhaps a difference in the cpio arch linux bundles | 18:28 |
| somlo | daveshah: catching up with the accumulated IRC conversation :) | 18:28 |
| somlo | daveshah: I'm rebasing to the freshest 5.2 kernel and _florent_'s latest LiteX, then I'll try the ecp5versa hack -- thanks! | 18:46 |
| somlo | I'd be curious if this works on the TrellisBoard, btw :) | 18:46 |
| somlo | daveshah: on Fedora 30, `man cpio` contains ``-c Identical to "-H newc", use the new svr4 portable format ...`` | 18:50 |
| somlo | so I was *trying* to do the right thing, not sure if "-c" is a Fedora-only hack? | 18:51 |
| daveshah | Yup, need to sort out the TrellisBoard setup in LiteX with the new memory map stuff then I can test that | 18:51 |
| daveshah | Arch Linux `man cpio` says `-c Use the old portable (ASCII) archive format. This is the same as -H odc.` | 18:53 |
| somlo | oy | 18:54 |
| daveshah | Might be an older version, copyright is 2015 | 18:54 |
| somlo | the exact opposite :( | 18:54 |
| daveshah | No, looks like it is the latest upstream | 18:54 |
| daveshah | Hmm | 18:54 |
| somlo | ok, maybe I'll just spell it out explicitly, then :) | 18:54 |
| daveshah | Seems like arch linux is upstream cpio | 18:55 |
| daveshah | Seems the safest option | 18:55 |
| somlo | daveshah: done, good thing I was retracing all my steps anyway, now I get to test it to make 100% sure my instructions still work for me :) | 18:57 |
| somlo | and thanks for catching the discrepancy! | 18:57 |
| daveshah | Looks like https://src.fedoraproject.org/rpms/cpio/blob/master/f/cpio-2.9-rh.patch is the cause | 18:58 |
| tpb | Title: Tree - rpms/cpio - src.fedoraproject.org (at src.fedoraproject.org) | 18:58 |
| somlo | hmmm, not very nice of them... | 19:01 |
| somlo | I mean, unless they're valiantly trying to push that upstream... :) | 19:02 |
| somlo | nope, the patch isn't showing up anywhere on https://savannah.gnu.org/projects/cpio/ so unless I've missed something, RH just went ahead and swapped the meaning of "-c" in cpio... | 19:07 |
| tpb | Title: GNU cpio - Summary [Savannah] (at savannah.gnu.org) | 19:07 |
| mithro | flammit / xobs: An older version of the spi_flash module is in litex-buildenv -> https://github.com/timvideos/litex-buildenv/blob/master/gateware/spi_flash.py | 19:36 |
| tpb | Title: litex-buildenv/spi_flash.py at master · timvideos/litex-buildenv · GitHub (at github.com) | 19:37 |
| *** neonking has joined #litex | 22:30 | |
| *** neonking has joined #litex | 22:30 | |
| futarisIRCcloud | somlo: Looks good. | 23:40 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!