<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.
<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 :-)
<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.
<Melkhior>
Guess I'll fall back to serialboot
<Melkhior>
Removed the sdcard from the DTS, serialboot'ed:
<Melkhior>
# cat /proc/cpuinfo
<Melkhior>
processor : 0
<Melkhior>
hart : 0
<Melkhior>
isa : rv64imafdc
<Melkhior>
mmu : sv39
<Melkhior>
uarch : sifive,rocket0
<Melkhior>
Apparently, the sdcard is the 'root' of all evil ;-)
hansfbaier has quit [Read error: Connection reset by peer]
hansfbaier has joined #litex
Melkhior has quit [Quit: Ping timeout (120 seconds)]
hansfbaier has quit [Read error: Connection reset by peer]
CarlFK[m] has quit [Quit: Bridge terminating on SIGTERM]
promach3 has quit [Quit: Bridge terminating on SIGTERM]
xobs has quit [Quit: Bridge terminating on SIGTERM]
jryans has quit [Quit: Bridge terminating on SIGTERM]
david-sawatzke[m has quit [Quit: Bridge terminating on SIGTERM]
sajattack[m] has quit [Quit: Bridge terminating on SIGTERM]
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
apolkosnik[m] has quit [Quit: Bridge terminating on SIGTERM]
leons has quit [Quit: Bridge terminating on SIGTERM]
promach3 has joined #litex
tpb has quit [Disconnected by services]
tpb has joined #litex
apolkosnik[m] has joined #litex
xobs has joined #litex
disasm[m] has joined #litex
david-sawatzke[m has joined #litex
sajattack[m] has joined #litex
jevinskie[m] has joined #litex
leons has joined #litex
CarlFK[m] has joined #litex
jryans has joined #litex
midnight has quit [Ping timeout: 240 seconds]
midnight has joined #litex
Bertl_zZ is now known as Bertl
<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
Melkhior has joined #litex
<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...
<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...)
<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...
<somlo>
pcb design and power are waaay outside my comfort zone :)
<Melkhior>
mine too :-)
<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
<Melkhior>
as well use it:-) ).
<Melkhior>
However, Linux doesn't see the sdcard at all, don't know why - it's in /proc/device-tree
<Melkhior>
I'm guessing my kernel from buildroot is too old and doesn't have a driver ?
<Melkhior>
But newer buildroot don't compile, I'm stuck with 88a268354d
<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 ;)
<Melkhior>
Could try that yes, keep the rootfs and only rebuild a newer kernel. Worth a shot...
<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
<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 :-)
<Melkhior>
(and yet both the kernel and rootfs were loaded from said sdcard!)
<somlo>
that's the devm_ioremap_resource call on the sdreader MMIO range failing
<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
<somlo>
low-hanging-fruit: typo in the DT node for the sdcard (wrong address for the third entry, the one specific to the sdreader)?
<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
<somlo>
yeah, json2dts again -- maybe hard-code it directly in the dts...
<Melkhior>
just did :-)
<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...
<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
<Melkhior>
with fixed DTS and unpatched kernel, I also get the 'infinite loop' with the proper divider (8 for 12500000)
<Melkhior>
This is SMP as well...
<Melkhior>
(OTOH, the 'rocket' tests are with all-new (from yesterday) repositories)
<geertu>
Melkhior: Things have changed since last Oct, both on the gateware as Linux driver side
<geertu>
So you need to use a recent LiteX, linux-on-litex-vexriscv, and kernel
<Melkhior>
Ilitesdcard I _did_ update
<Melkhior>
but everything else might be older :-(
<Melkhior>
OK
<Melkhior>
I will need to restart in a new environment I guess, to have a clean LIteX setup
<Melkhior>
might take a while :-(
<Melkhior>
Thanks a lot for all the help everyone :-)
<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
<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 :)
<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 :)
<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...
<Melkhior>
"latest and greatest" is *not* my middle name :-)
<Melkhior>
I guess for LiteX i should learn to update more :-)
Melkhior has quit [Quit: Ping timeout (120 seconds)]
<_florent_>
somlo: not sure I tested jtagbone with the analyzer yet, I was planning to test it later this week
<_florent_>
so if you have issues, please report them :)
<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`
<somlo>
fails with a `AssertionError: Found multiple candidates:` and a bunch of signals in my list
<somlo>
running it without any arguments gets me a dump.vcd
<somlo>
but I can't use triggers, apparently
<_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
<somlo>
I can no longer build it the old way did `add_uartbone()` get renamed ?
<somlo>
sorry, gotta run (take my Mom in for a vaccine), be back in an hour or so
<_florent_>
somlo: uartbone should still work with upstream, I'm going to check
<_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
kgugala has quit [Remote host closed the connection]
Zguig has joined #litex
<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
kgugala has joined #litex
<_florent_>
Hi Zguig, thanks for looking at that, sorry I saw your issue but haven't been able to answer before, just did
<Zguig>
What I see nice with this project is the number of FPGA supported
<Zguig>
From what I saw in the boards, only few have flash implemented, based on custom routines
<_florent_>
Zguig: I have a preference for OpenOCD because that's also what we are using for Xilinx FPGAs
<_florent_>
but if using OpenFPGALoader makes flashing a lot easier on ECP5, we could use that
<Zguig>
And how did you manage to get the proxy gateware for xilinx?
<_florent_>
these are pre-generated
<_florent_>
but I was also able to generate them from Migen IIRC
<Zguig>
From xilinx tools?
<_florent_>
generate with Migen with the Xilinx tools yes
<_florent_>
generated
<_florent_>
sorry I have to go
<Zguig>
OK, thanks! I try to check if I can go further with OpenOCD
Zguig has quit [Quit: Connection closed]
<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
<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
davidlattimore has quit [Read error: Connection reset by peer]
davidlattimore has joined #litex
<_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)
<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)...
<somlo>
so it looks like I have to go down a layer of abstraction and learn yet another new thing :D