_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
kgugala has quit [Ping timeout: 260 seconds]
Dolu has quit [Ping timeout: 264 seconds]
kgugala has joined #litex
ranzbak has quit [Ping timeout: 272 seconds]
lf has quit [Ping timeout: 258 seconds]
lf has joined #litex
ranzbak has joined #litex
npcomp has quit [Ping timeout: 240 seconds]
Degi_ has joined #litex
Degi has quit [Ping timeout: 265 seconds]
Degi_ is now known as Degi
nelgau has quit [Remote host closed the connection]
nelgau has joined #litex
nelgau has quit [Ping timeout: 240 seconds]
nelgau has joined #litex
nelgau has quit [Ping timeout: 272 seconds]
vitalmixofnutrie has joined #litex
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #litex
vitalmixofnutrie has quit [Ping timeout: 240 seconds]
Bertl_oO is now known as Bertl_zZ
lkcl has quit [Ping timeout: 256 seconds]
lkcl has joined #litex
kgugala_ has joined #litex
kgugala has quit [Ping timeout: 240 seconds]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 260 seconds]
<_florent_> roboknight: for XIP, depending the SPI Flash you are using it's possible the dummy cycles will need to be adapted: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/fomu.py#L103
<_florent_> the difficulty with small ice40 FPGAs is that due to the small size, the bringup can be more difficult: on larger FPGA, we generally start with the BIOS in ROM, verify the SPI Flash is working correctly from the BIOS (with mem_read) and then switch to XIP from SPI Flash
<_florent_> with ice40 it's a not possible
lkcl has quit [Ping timeout: 256 seconds]
<_florent_> but it's possible to use the UART bridge
<_florent_> ex you build your target with the crossover UART and bridge (using the iceBreaker here): ./icebreaker.py --cpu-type=vexriscv --cpu-variant=minimal --uart-name=crossover+bridge --build
<_florent_> this will allow you test the SPI Flash peripheral from your Host using LiteX server and python scripts
<_florent_> to learn how to use it, you can have a look at: https://github.com/enjoy-digital/litex/wiki/Use-Host-Bridge-to-control-debug-a-SoC
<_florent_> with the bridge, you can also use LiteScope for debug (https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To-Debug-A-SoC) but still because of the lack of RAM on ice40, it will be a bit limited.
lkcl has joined #litex
lkcl has quit [Ping timeout: 272 seconds]
lkcl has joined #litex
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #litex
lkcl has quit [Ping timeout: 264 seconds]
Dolu has joined #litex
lkcl has joined #litex
Bertl_zZ is now known as Bertl
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
<roboknight> florent: Thanks for the info... I'm going to try that... it appears that I have "uartbone" and "crossover". Not sure which will provide the crossover+bridge (they both seem to be a wishbone bridge of some type). I'll try crossover first. At any rate, I checked the SPI flash datasheet and it seems to indicate 8 dummy cycles for FAST_READ. My real
<roboknight> problem is that I actually tried 0 cycles to see something change in the SPI output and it appeared that the # of cycles didn't change (I checked the scope). The other strange thing is that changing my clock speed doesn't seem to change anything at all. My SPI is still attempting to run at 12MHz (even if I set the clock faster or slower). So I'm
<roboknight> not sure what is going on there. I'd post some of my setup code for the board, but the machine I'm using here is separate from the dev machine.
<roboknight> At any rate, I'm trying to track things down one at a time, so I'll try the crossover and see how that goes.
<_florent_> roboknight: crossover+bridge support is recent (5 days ago) so you should probably update LiteX if you don't have it. With it you will be able to control the access to the SPI Flash so it should be easier. For the SPI clock, maybe you could add a print in the code to see if the divider has changed.
roboknight has quit [Remote host closed the connection]
roboknight has joined #litex
<somlo> _florent_, daveshah: https://github.com/riscv/riscv-pk/pull/230
<somlo> with luck, I can just point at their upstream repo when creating linux-on-litex-rocket :)
lkcl has quit [Ping timeout: 260 seconds]
lkcl has joined #litex
Bertl is now known as Bertl_oO
<_florent_> somlo: :) (in the quest of linux-on-litex-rocket as single README file? :))
<somlo> yeah, a.k.a. "upstream-first" :D
Bertl_oO is now known as Bertl
somlo has quit [Remote host closed the connection]
somlo has joined #litex
cjearls has joined #litex
<cjearls> Hi, I'm running a custom VexRiscv on linux-on-litex-vexriscv. I'd like to read data from a file, but I'm running into an issue where my filesystem appears to be working properly, I can ls, mkdir, and use things like echo or vim to make, edit, and read files, but my C fopen() function is always returning NULL. I'm thinking this might have something to do with the filesystem being virtual instead of actually reading and writing to the file
<cjearls> system on the microSD card on my orangecrab board, but I'm not sure. How might I fix this issue?
<daveshah> fopen returning NULL seems very strange, regardless of whether or not it is using a ramdisk
<daveshah> particularly as those other things are working
<daveshah> it almost seems like a syscall issue, something subtly borked in the kernel/userspace interface, but without poking at things I can't really suggest any targeted debugging there
<cjearls> Thank you, I thought the same, but wanted to check in here for a sanity check
<daveshah> I'm pretty sure that the busybox utils that you mention working will use similar calls
<cjearls> daveshah: Does this seem like something that I should create an issue for somewhere?
<cjearls> That's what I would've thought as well
<daveshah> Yeah, an issue on linux-on-litex-vexriscv seems reasonable enough to me
<cjearls> Could it be my compiler? I'm just running the recommended riscv64-unknown-elf-gcc-8.3.0-2019.08.0-x86_64-linux-ubuntu14 compiler with -O3 enabled
<cjearls> Alright, I'll do that. Thanks.
<daveshah> hmm, I'm not sure if unknown-elf is right here
<daveshah> the best bet is probably to get buildroot up and running and use the compiler that builds
<cjearls> Oh, cool, I already have buildroot working so I could transfer the program I wanted to run to the microSD
<daveshah> There will be a compiler somewhere in there, or you can do it properly and make your program a buildroot package
<cjearls> Ok, I'll take a look at that
<zyp> -unknown-elf is probably linked against libnosys which provides dummy implementations for syscalls, meant for use on bare metal systems
<zyp> I mean, the libc provided with it
roboknight has quit [Remote host closed the connection]
vitalmixofnutrie has joined #litex
<cjearls> I built the buildroot compiler, and it appears like file access is working properly now. Thanks for your help
leons has quit [Ping timeout: 268 seconds]
leons has joined #litex
roboknight has joined #litex
roboknight has quit [Remote host closed the connection]
Bertl is now known as Bertl_zZ
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex