07:58 <_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

07:59 <_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

08:00 <_florent_> with ice40 it's a not possible

08:01 <_florent_> but it's possible to use the UART bridge

08:08 <_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

08:08 <_florent_> this will allow you test the SPI Flash peripheral from your Host using LiteX server and python scripts

08:09 <_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

08:11 <_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.

13:42 <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

13:42 <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

13:42 <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.

13:42 <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.

14:25 <_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.

15:27 <somlo> _florent_, daveshah: https://github.com/riscv/riscv-pk/pull/230

15:27 <somlo> with luck, I can just point at their upstream repo when creating linux-on-litex-rocket :)

17:53 <_florent_> somlo: :) (in the quest of linux-on-litex-rocket as single README file? :))

17:55 <somlo> yeah, a.k.a. "upstream-first" :D

19:00 <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

19:00 <cjearls> system on the microSD card on my orangecrab board, but I'm not sure. How might I fix this issue?

19:01 <daveshah> fopen returning NULL seems very strange, regardless of whether or not it is using a ramdisk

19:01 <daveshah> particularly as those other things are working

19:02 <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

19:02 <cjearls> Thank you, I thought the same, but wanted to check in here for a sanity check

19:03 <daveshah> I'm pretty sure that the busybox utils that you mention working will use similar calls

19:03 <cjearls> daveshah: Does this seem like something that I should create an issue for somewhere?

19:04 <cjearls> That's what I would've thought as well

19:04 <daveshah> Yeah, an issue on linux-on-litex-vexriscv seems reasonable enough to me

19:04 <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

19:05 <cjearls> Alright, I'll do that. Thanks.

19:05 <daveshah> hmm, I'm not sure if unknown-elf is right here

19:05 <daveshah> the best bet is probably to get buildroot up and running and use the compiler that builds

19:06 <cjearls> Oh, cool, I already have buildroot working so I could transfer the program I wanted to run to the microSD

19:07 <daveshah> There will be a compiler somewhere in there, or you can do it properly and make your program a buildroot package

19:24 <cjearls> Ok, I'll take a look at that

19:33 <zyp> -unknown-elf is probably linked against libnosys which provides dummy implementations for syscalls, meant for use on bare metal systems

19:33 <zyp> I mean, the libc provided with it

19:54 <cjearls> I built the buildroot compiler, and it appears like file access is working properly now. Thanks for your help