| *** tpb has joined #litex | 00:00 | |
| *** indy has quit IRC | 00:10 | |
| *** indy has joined #litex | 00:20 | |
| *** lf_ has joined #litex | 00:45 | |
| *** lf has quit IRC | 00:45 | |
| *** chgavilana has quit IRC | 02:09 | |
| *** Degi_ has joined #litex | 03:46 | |
| *** Degi has quit IRC | 03:48 | |
| *** Degi_ is now known as Degi | 03:48 | |
| *** Bertl_oO is now known as Bertl_zZ | 05:15 | |
| *** _whitelogger has quit IRC | 06:12 | |
| *** _whitelogger has joined #litex | 06:14 | |
| *** hansfbaier has joined #litex | 08:15 | |
| *** Melkhior has joined #litex | 09:52 | |
| Melkhior | somlo _florent_ Is HW design some sort of dark art ?:-) Rocket is willing to load the boot.bin from the micro-sd card ... in SPI mode, as suggested by somlo. | 09:56 |
|---|---|---|
| Melkhior | So theoretically, SPI mode can work ; why can't it work for VexRiscV or my design, your guess is as good (or waaaaaay better if I'm honest) than mine :-) | 09:58 |
| Melkhior | ... well back to normal: fixed the boot.bin to have a proper dts (with a SPI sdcard instead of SD-mode), regenerated the bitstream ... and SPI mode now fail as well. | 10:10 |
| Melkhior | Guess I'll fall back to serialboot | 10:11 |
| Melkhior | Removed the sdcard from the DTS, serialboot'ed: | 10:37 |
| Melkhior | # cat /proc/cpuinfo | 10:37 |
| Melkhior | processor : 0 | 10:37 |
| Melkhior | hart : 0 | 10:37 |
| Melkhior | isa : rv64imafdc | 10:37 |
| Melkhior | mmu : sv39 | 10:37 |
| Melkhior | uarch : sifive,rocket0 | 10:37 |
| Melkhior | Apparently, the sdcard is the 'root' of all evil ;-) | 10:38 |
| *** hansfbaier has quit IRC | 10:46 | |
| *** hansfbaier has joined #litex | 10:48 | |
| *** Melkhior has quit IRC | 11:07 | |
| *** hansfbaier has quit IRC | 11:13 | |
| *** CarlFK[m] has quit IRC | 11:19 | |
| *** promach3 has quit IRC | 11:19 | |
| *** xobs has quit IRC | 11:19 | |
| *** jryans has quit IRC | 11:19 | |
| *** david-sawatzke[m has quit IRC | 11:19 | |
| *** sajattack[m] has quit IRC | 11:19 | |
| *** disasm[m] has quit IRC | 11:19 | |
| *** jevinskie[m] has quit IRC | 11:19 | |
| *** apolkosnik[m] has quit IRC | 11:19 | |
| *** leons has quit IRC | 11:19 | |
| *** promach3 has joined #litex | 11:31 | |
| *** tpb has joined #litex | 11:40 | |
| *** apolkosnik[m] has joined #litex | 11:53 | |
| *** xobs has joined #litex | 11:53 | |
| *** sajattack[m] has joined #litex | 11:53 | |
| *** david-sawatzke[m has joined #litex | 11:53 | |
| *** jevinskie[m] has joined #litex | 11:53 | |
| *** disasm[m] has joined #litex | 11:53 | |
| *** leons has joined #litex | 11:53 | |
| *** jryans has joined #litex | 11:53 | |
| *** CarlFK[m] has joined #litex | 11:53 | |
| *** midnight has quit IRC | 11:55 | |
| *** midnight has joined #litex | 11:57 | |
| *** Bertl_zZ is now known as Bertl | 12:00 | |
| somlo | Melkhior: in spi-mode, the sdcard only uses CSR/MMIO to transfer data -- while "native" litesdcard uses DMA. So the data takes very different paths between RAM and the actual microSD card | 13:18 |
| *** Melkhior has joined #litex | 13:20 | |
| somlo | then there's the somewhat less likely issue of electrical power. e.g., I have a trellisboard which also works fine with spi-mode sdcard, but will reset/crash the fpga when the physical card is inserted when using native mode -- *unless* I use an external power supply, which allows it to work fine... | 13:21 |
| Melkhior | @somlo so tw problems - one is SD-mode w/ rocket where the DMA fails, the other is that for some reason SPI-mode is essentially not working for me ? (it does worke very occasionnaly for reasons unknown...) | 13:21 |
| Melkhior | Could be power, but with LiteX I have an external power supply rated 5V/3A (the SBus is limited to 5V/2A). Could be not enough capacitance/decoupling/... ? I didn't really think about that bit when doing the board... | 13:24 |
| somlo | pcb design and power are waaay outside my comfort zone :) | 13:25 |
| Melkhior | mine too :-) | 13:26 |
| Melkhior | Also I suppose sd-mode, being faster with more pins, is more power-hungry than SPI (as in your experience with the trellisboard)... and SD-mode is quite reliable read-only to load the kernel + rootfs with linux-on-litex-vexriscv ; it works even with my dual-core SoC with all the extra instructions and bigger cache (got the space in the FPGA, might | 13:28 |
| Melkhior | as well use it:-) ). | 13:29 |
| Melkhior | However, Linux doesn't see the sdcard at all, don't know why - it's in /proc/device-tree | 13:29 |
| Melkhior | I'm guessing my kernel from buildroot is too old and doesn't have a driver ? | 13:30 |
| Melkhior | But newer buildroot don't compile, I'm stuck with 88a268354d | 13:30 |
| somlo | I was going to say, depends on the kernel. I'd suggest trying the "litex-rebase" branch of https://github.com/litex-hub/linux | 13:30 |
| somlo | also not familiar with buildroot -- I use a raw busybox-based initramfs.cpio for rocket (my current goal is to get things working at all, doing useful stuff with it can wait for later ;) | 13:32 |
| Melkhior | Could try that yes, keep the rootfs and only rebuild a newer kernel. Worth a shot... | 13:32 |
| Melkhior | Yes, I saw that - your instructions were quite nice, I got a boot.bin that works (via serialboot only;-) ) fine with Rocket using them | 13:33 |
| Melkhior | buildroot had a bit more stuff, which is useful when your SoC has no ethernet and no working mass storage and the only interface to the outside world is the serial console :-) | 13:34 |
| geertu | Melkhior: Does https://github.com/geertu/linux/tree/litex-v5.11 work any better? | 13:53 |
| geertu | I use the rootfs and opensbi from the prebuilts, but my own kernel | 13:54 |
| somlo | shorne: ping | 14:03 |
| somlo | brb | 14:24 |
| *** somlo has quit IRC | 14:24 | |
| *** somlo has joined #litex | 14:27 | |
| Melkhior | @geertu I'll try ASAP | 14:28 |
| Melkhior | @geertu Was able to compile to a 'good' image: the kernel loads fine; however I get a hang when accessing the sdcard it seems: | 14:48 |
| Melkhior | [ 1.387471] printk: bootconsole [sbi0] disabled | 14:48 |
| Melkhior | [ 1.387471] printk: bootconsole [sbi0] disabled | 14:48 |
| Melkhior | [ 1.407928] libphy: Fixed MDIO Bus: probed | 14:48 |
| Melkhior | [ 1.410771] i2c /dev entries driver | 14:48 |
| Melkhior | [ 1.416094] litex-mmc f0005000.mmc: invalid resource | 14:48 |
| Melkhior | [ 1.416925] MAP_RESOURCE 2 failed | 14:48 |
| Melkhior | (and yet both the kernel and rootfs were loaded from said sdcard!) | 14:50 |
| somlo | that's the devm_ioremap_resource call on the sdreader MMIO range failing | 14:51 |
| somlo | Melkhior: the bios (loading kernel and rootfs) are a different code base; once the kernel starts booting, it won't use the bios, but rather its own built-in driver to talk to the hardware | 14:52 |
| somlo | low-hanging-fruit: typo in the DT node for the sdcard (wrong address for the third entry, the one specific to the sdreader)? | 14:53 |
| Melkhior | OK ; btw @somlo I also tried the branch you suggested, but I must have messed up the configuration - I got a > 22 MiB image that wouldn't boot. @geertu branch has a default vexriscv config that worked for me | 14:53 |
| Melkhior | DTS is | 14:54 |
| Melkhior | mmc@f0005800 { | 14:54 |
| Melkhior | compatible = "litex,mmc"; | 14:54 |
| Melkhior | bus-width = <0x4>; | 14:54 |
| Melkhior | reg = <0xf0005000 0x100 0xf0005800 0x100>; | 14:54 |
| Melkhior | status = "okay"; | 14:54 |
| Melkhior | }; | 14:54 |
| somlo | the litex_rebase branch needs a vexriscv defconfig :) | 14:54 |
| somlo | you have too few entries in reg | 14:54 |
| somlo | you need four (address, size) pairs | 14:55 |
| Melkhior | should come out of json2dts.py ... | 14:55 |
| Melkhior | I _think_ | 14:55 |
| Melkhior | Source file should be ./build/sbustoztex/sbustoztex.dts from linux-on-litex-vexriscv, says: | 14:56 |
| Melkhior | mmc0: mmc@f0005800 { | 14:57 |
| Melkhior | compatible = "litex,mmc"; | 14:57 |
| Melkhior | bus-width = <4>; | 14:57 |
| Melkhior | reg = < | 14:57 |
| Melkhior | 0xf0005000 0x100 | 14:57 |
| Melkhior | 0xf0005800 0x100 | 14:57 |
| Melkhior | >; | 14:57 |
| Melkhior | status = "okay"; | 14:57 |
| Melkhior | }; | 14:57 |
| Melkhior | only two as well | 14:57 |
| geertu | Melkhior: To fix the too large kernel image, you need https://github.com/geertu/linux/commit/d7894d2d078e5e255fa2e0e8bd3739079a854b39 | 14:57 |
| geertu | and https://github.com/geertu/linux/commit/44d9a61725d2eb26228ba8e14bcdd16dbbb0e777 | 14:57 |
| somlo | technically, json2dts *should* take care of it, but I haven't adapted it to deal with rocket yet, so I'm not super familiar with it | 14:58 |
| Melkhior | @geertu OK thanks; though your branch works for me I might stick with that :-) | 14:58 |
| geertu | Melkhior: I have | 14:58 |
| geertu | mmc0: mmc@f0004800 { | 14:58 |
| geertu | compatible = "litex,mmc"; | 14:58 |
| geertu | reg = < | 14:58 |
| geertu | 0xf0004800 0x100 | 14:58 |
| geertu | 0xf0005000 0x100 | 14:58 |
| somlo | the four entries in reg <> should correspond to your csr.csv | 14:58 |
| geertu | 0xf0005800 0x100 | 14:58 |
| geertu | 0xf0006000 0x100>; | 14:58 |
| geertu | bus-width = <0x04>; | 14:58 |
| Melkhior | @somlo this is with VexRiscV ATM, as it works in the BIOS | 14:58 |
| geertu | status = "okay"; | 14:58 |
| geertu | }; | 14:58 |
| geertu | also with linux-on-litex-vexriscv? | 14:59 |
| somlo | Melkhior: yes, understood. But since it's the same driver in linux, it'll need similar magic in DTS :) | 14:59 |
| Melkhior | :-) | 15:00 |
| somlo | I was going to say: in csr.csv, you should have sdphy, sdcore, sdblock2mem, sdmem2block | 15:00 |
| Melkhior | magic is the word... | 15:00 |
| somlo | "csr_base" entries | 15:00 |
| somlo | those are your start addresses for each of the four pairs in "reg" | 15:00 |
| somlo | use 0x100 for the extent of each pair as that should be "close enough" | 15:01 |
| somlo | your json2dts might be out of date or buggy, but as mentioned, I haven't dealt with it yet, so I don't know for sure | 15:01 |
| Melkhior | OK will fix that and try again | 15:02 |
| Melkhior | (I don't seem to have a csr.csv, but I have a csr.json with the entries in decimal, close enough I guess:-) ) | 15:02 |
| Melkhior | mmm, goes further but then infinite loop in the kernel: | 15:09 |
| Melkhior | [ 2.697537] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 0 via div=256 | 15:09 |
| Melkhior | [ 3.745523] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 0 via div=2 | 15:09 |
| Melkhior | [ 4.973482] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 0 via div=256 | 15:09 |
| Melkhior | [ 6.017523] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 0 via div=2 | 15:09 |
| Melkhior | [ 7.245492] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 0 via div=256 | 15:09 |
| Melkhior | [ 8.289514] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 0 via div=2 | 15:09 |
| Melkhior | [ 9.517482] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 0 via div=256 | 15:09 |
| Melkhior | [ 10.561525] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 0 via div=2 | 15:09 |
| Melkhior | [ 11.789480] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 0 via div=256 | 15:09 |
| Melkhior | [ 12.833513] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 0 via div=2 | 15:09 |
| Melkhior | (repeat ad nauseam) | 15:09 |
| Melkhior | in the DTS, what should be the address of the 'mmc' ? | 15:10 |
| Melkhior | I have mmc0: mmc@f0005800 | 15:10 |
| geertu | Melkhior: replace the dev_info() call by dev_dbg() | 15:10 |
| geertu | Melkhior: the address depends on what you have configured inyour SoC | 15:10 |
| Melkhior | that was the last block of registers, but geertu's DTS uses 4800 (the first block) | 15:10 |
| Melkhior | now 5800 is in the middle for me ... | 15:11 |
| Melkhior | should it be the first block ? | 15:11 |
| Melkhior | that would be f0005000 whic his what the kernel reports | 15:11 |
| somlo | Melkhior: when you built the bitstream, did you get/keep the csr.csv file that was generated during the build? | 15:15 |
| somlo | it should contain the authoritative addresses that need to be placed in DT specific to your "hardware" | 15:15 |
| somlo | look for a line (in csr.csv) starting with "csr_base,sdphy" | 15:16 |
| Melkhior | I have a csr.json instead, does it not have all the information ? | 15:16 |
| somlo | should have it, although maybe in a slightly different format ? | 15:16 |
| somlo | search for "sdphy", "sdcore", sdblock2mem", and "sdmem2block" in your json file | 15:17 |
| Melkhior | "csr_bases": { | 15:17 |
| Melkhior | (...) | 15:17 |
| Melkhior | "sdphy": 4026552320, | 15:17 |
| Melkhior | that's F0005000 | 15:17 |
| Melkhior | I fixed the DTS I think, that's how I get the kernel's infinite loop | 15:18 |
| Melkhior | I have all four registers, with the same relative offset than Geert's (just a different base) | 15:19 |
| somlo | what is the "clock-frequency" value for your CPU (also in DTS)? | 15:19 |
| somlo | it's used to compute the divider for clocking the sdcard | 15:19 |
| somlo | and it seems that's not going over too well in your environment | 15:19 |
| Melkhior | 100 MHz | 15:21 |
| somlo | so `clock-frequency = <100000000>;` then ? | 15:24 |
| Melkhior | yes | 15:25 |
| Melkhior | ... in JSON: 500 | 15:25 |
| Melkhior | ... in JSON: "config_clock_frequency": 100000000, | 15:25 |
| somlo | the line that says "set to 0 via div=2" concerns me a bit | 15:27 |
| Melkhior | @geertu with 'dev_dbg' instead of 'dev_info' I get no output ?!? | 15:28 |
| Melkhior | @somlo yes seems the code sees host->freq at 0 ... | 15:28 |
| Melkhior | I added 'host->freq = 100000000;' in the function, but it doesn't help much: | 15:28 |
| Melkhior | [ 2.701396] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 390625 via div=256 | 15:28 |
| Melkhior | [ 3.745428] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 12500000 via di | 15:28 |
| Melkhior | v=8 | 15:28 |
| Melkhior | [ 4.973389] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 390625 via div=256 | 15:28 |
| Melkhior | [ 6.017425] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 12500000 via di | 15:28 |
| Melkhior | v=8 | 15:29 |
| Melkhior | [ 7.245391] litex-mmc f0005000.mmc: Requested clk_freq=0: set to 390625 via div=256 | 15:29 |
| Melkhior | [ 8.289433] litex-mmc f0005000.mmc: Requested clk_freq=12500000: set to 12500000 via di | 15:29 |
| Melkhior | v=8 | 15:29 |
| Melkhior | (the 'set to XXX' value is 'host->freq / div', so I guess host->freq is 0) | 15:29 |
| somlo | Melkhior: I was going to suggest https://pastebin.com/rM6YtKqp but you already did something similar | 15:31 |
| Melkhior | mmm the "config_clock_frequency": 100000000," in the JSON doesn't make it all the way to the DTS: | 15:31 |
| tpb | Title: diff --git a/drivers/mmc/host/litex_mmc.c b/drivers/mmc/host/litex_mmc.cindex - Pastebin.com (at pastebin.com) | 15:31 |
| Melkhior | cpu@0 { | 15:31 |
| Melkhior | clock-frequency = <0x0>; | 15:32 |
| somlo | yeah, json2dts again -- maybe hard-code it directly in the dts... | 15:32 |
| Melkhior | just did :-) | 15:33 |
| somlo | there's something weird about how json2dts seems to not work for you -- I haven't used it, but if it's *this* broken (for linux-on-litex-vexriscv) someone would have noticed, I think. So I wonder where that breakage occurs for you, figuring that out might help fix a bunch of things... | 15:34 |
| Melkhior | I'm running a slightly older version from late last october, didn't update everything for fear of breaking something - except for the sdcard (which may still be my HW!) everything works beautifully | 15:38 |
| Melkhior | with fixed DTS and unpatched kernel, I also get the 'infinite loop' with the proper divider (8 for 12500000) | 15:38 |
| Melkhior | This is SMP as well... | 15:39 |
| Melkhior | (OTOH, the 'rocket' tests are with all-new (from yesterday) repositories) | 15:41 |
| geertu | Melkhior: Things have changed since last Oct, both on the gateware as Linux driver side | 15:41 |
| geertu | So you need to use a recent LiteX, linux-on-litex-vexriscv, and kernel | 15:42 |
| Melkhior | Ilitesdcard I _did_ update | 15:42 |
| Melkhior | but everything else might be older :-( | 15:42 |
| Melkhior | OK | 15:43 |
| Melkhior | I will need to restart in a new environment I guess, to have a clean LIteX setup | 15:44 |
| Melkhior | might take a while :-( | 15:44 |
| Melkhior | Thanks a lot for all the help everyone :-) | 15:44 |
| somlo | Melkhior: I have a morning routine of "git pull" for all repos I don't hack on, and fetch-upstream + rebase for everything where I do have current ongoing changes | 15:50 |
| somlo | it's a bit of a treadmill, but better to have the latest and greatest, since things do tend to move at a pretty brisk pace :) | 15:51 |
| somlo | (even on days I otherwise have no time to play with LiteX, just to make sure I get to complain in a timely way about anything that affects me negatively :) | 15:51 |
| Melkhior | ... my main desktop is still on Debian 9 as it works-for-me:-) My mac laptop is from 2009. And - that FPGA board was bought for https://github.com/rdolbeau/SBusFPGA ; I'm still playing with 25+ years old SPARCstation... | 15:55 |
| Melkhior | "latest and greatest" is *not* my middle name :-) | 15:55 |
| Melkhior | I guess for LiteX i should learn to update more :-) | 15:57 |
| *** Melkhior has quit IRC | 16:06 | |
| somlo | _florent_: I built rocket/litex for nexys4ddr with the jtagbone analyzer: https://pastebin.com/72Jdniu8 | 17:04 |
| tpb | Title: diff --git a/litex_boards/targets/nexys4ddr.py b/litex_boards/targets/nexys4ddr. - Pastebin.com (at pastebin.com) | 17:04 |
| _florent_ | somlo: not sure I tested jtagbone with the analyzer yet, I was planning to test it later this week | 17:06 |
| _florent_ | so if you have issues, please report them :) | 17:06 |
| somlo | but my old litescope_cli command line: `litescope_cli -v basesoc_cpu_mem_axi_aw_payload_addr 0x80000000 -r basesoc_cpu_mem_axi_w_valid` | 17:06 |
| somlo | fails with a `AssertionError: Found multiple candidates:` and a bunch of signals in my list | 17:06 |
| somlo | running it without any arguments gets me a dump.vcd | 17:07 |
| somlo | but I can't use triggers, apparently | 17:07 |
| _florent_ | somlo: ok, the issue you have should not be related to the change to jtagbone. This happens when checking the .csv with the passed triggers | 17:08 |
| somlo | I can no longer build it the old way did `add_uartbone()` get renamed ? | 17:08 |
| somlo | sorry, gotta run (take my Mom in for a vaccine), be back in an hour or so | 17:09 |
| _florent_ | somlo: uartbone should still work with upstream, I'm going to check | 17:11 |
| _florent_ | somlo: I'm able to build arty when adding self.add_uartbone(name="serial") to the SoC and doing ./arty.py --uart-name=crossover | 17:14 |
| *** kgugala has quit IRC | 17:25 | |
| *** Zguig has joined #litex | 18:12 | |
| Zguig | Hi guys, I did something that works to unable flashing the FPGA gateware for: linux virtex project / ecpix5 board (should be compatible with all boards having the flash function working). Could somebody have a look to the issue I have openned to check if I can commit my implementation? https://github.com/litex-hub/linux-on-litex-vexriscv/issues/189 | 18:21 |
| *** kgugala has joined #litex | 18:38 | |
| _florent_ | Hi Zguig, thanks for looking at that, sorry I saw your issue but haven't been able to answer before, just did | 18:41 |
| Zguig | Hi _florent_, thanks for your reply, I will have a look to the https://github.com/quartiq/bscan_spi_bitstreams/blob/master/lattice_bscan_spi.py that is required by OpenOCD to flash if I understood well the story | 18:42 |
| Zguig | I did the "easy" way :) | 18:43 |
| *** dkozel has quit IRC | 18:43 | |
| _florent_ | Zguig: if this is too complicated, we could use an alternative, that would be nice to evaluate ECPProg: https://github.com/gregdavill/ecpprog and ECPDap: https://github.com/adamgreig/ecpdap | 18:48 |
| Zguig | It seems not so easy to pass through OpenOCD for this. What don't you like in OpenFPGALoader ? It can do load and flash | 18:53 |
| Zguig | In fact it is the official tool from the manufacturer of this board http://docs.lambdaconcept.com/ecpix-5/features/debug.html | 18:53 |
| tpb | Title: Debug ECPIX-5 Documentation documentation (at docs.lambdaconcept.com) | 18:53 |
| Zguig | What I see nice with this project is the number of FPGA supported | 18:58 |
| Zguig | From what I saw in the boards, only few have flash implemented, based on custom routines | 18:59 |
| _florent_ | Zguig: I have a preference for OpenOCD because that's also what we are using for Xilinx FPGAs | 19:01 |
| _florent_ | but if using OpenFPGALoader makes flashing a lot easier on ECP5, we could use that | 19:02 |
| Zguig | And how did you manage to get the proxy gateware for xilinx? | 19:02 |
| _florent_ | these are pre-generated | 19:03 |
| _florent_ | but I was also able to generate them from Migen IIRC | 19:03 |
| Zguig | From xilinx tools? | 19:03 |
| _florent_ | generate with Migen with the Xilinx tools yes | 19:04 |
| _florent_ | generated | 19:04 |
| _florent_ | sorry I have to go | 19:04 |
| Zguig | OK, thanks! I try to check if I can go further with OpenOCD | 19:04 |
| *** Zguig has quit IRC | 19:46 | |
| somlo | _florent_: fwiw, jtagbone and litescope work -- it's that the soc was internally renamed from "basesoc" to just "soc", so the names of the signals I was passing into the client were wrong | 19:54 |
| somlo | so I think everything is fine from my perspective -- I can keep the console on the "standard" uart and do debugging/litescope over jtag, which is the intuitive thing to do -- thanks for implementing it, and sorry for the false alarm | 19:55 |
| *** davidlattimore has quit IRC | 20:13 | |
| *** davidlattimore has joined #litex | 20:14 | |
| _florent_ | somlo: thanks for the feedback, nice to know it's working correctly. We should really get rid of this renaming, I'll try to look at it soon (https://github.com/enjoy-digital/litex/issues/667) | 20:19 |
| somlo | _florent_: litescope is awesome, and I love that I know how to use it now (thanks again for that, btw). But I just came to realize I actually need to understand the LiteSDCard (and DMA) FSMs, to even stand a chance of figuring out why they're misbehaving (and only under Linux, not in the bios)... | 20:26 |
| somlo | so it looks like I have to go down a layer of abstraction and learn yet another new thing :D | 20:27 |
| *** somlo has quit IRC | 20:28 | |
| *** somlo has joined #litex | 20:29 | |
| *** Bertl is now known as Bertl_oO | 21:39 | |
| *** oter has joined #litex | 22:26 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!