| *** tpb has joined #litex | 00:00 | |
| *** kgugala has quit IRC | 00:03 | |
| *** Dolu has quit IRC | 00:06 | |
| *** kgugala has joined #litex | 00:24 | |
| *** ranzbak has quit IRC | 00:28 | |
| *** lf has quit IRC | 00:56 | |
| *** lf has joined #litex | 00:56 | |
| *** ranzbak has joined #litex | 01:03 | |
| *** npcomp has quit IRC | 01:03 | |
| *** Degi_ has joined #litex | 01:12 | |
| *** Degi has quit IRC | 01:15 | |
| *** Degi_ is now known as Degi | 01:15 | |
| *** nelgau has quit IRC | 01:30 | |
| *** nelgau has joined #litex | 01:31 | |
| *** nelgau has quit IRC | 01:35 | |
| *** nelgau has joined #litex | 02:01 | |
| *** nelgau has quit IRC | 02:09 | |
| *** vitalmixofnutrie has joined #litex | 02:37 | |
| *** lkcl has quit IRC | 02:46 | |
| *** lkcl has joined #litex | 02:58 | |
| *** vitalmixofnutrie has quit IRC | 03:49 | |
| *** Bertl_oO is now known as Bertl_zZ | 04:14 | |
| *** lkcl has quit IRC | 06:02 | |
| *** lkcl has joined #litex | 06:15 | |
| *** kgugala_ has joined #litex | 06:20 | |
| *** kgugala has quit IRC | 06:21 | |
| *** kgugala has joined #litex | 07:37 | |
| *** kgugala_ has quit IRC | 07:41 | |
| _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:58 |
|---|---|---|
| _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 | 07:59 |
| _florent_ | with ice40 it's a not possible | 08:00 |
| *** lkcl has quit IRC | 08:00 | |
| _florent_ | but it's possible to use the UART bridge | 08:01 |
| _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:08 |
| _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:09 |
| _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. | 08:11 |
| *** lkcl has joined #litex | 08:13 | |
| *** lkcl has quit IRC | 08:22 | |
| *** lkcl has joined #litex | 08:33 | |
| *** lkcl has quit IRC | 08:43 | |
| *** lkcl has joined #litex | 08:57 | |
| *** lkcl has quit IRC | 09:57 | |
| *** Dolu has joined #litex | 10:07 | |
| *** lkcl has joined #litex | 10:09 | |
| *** Bertl_zZ is now known as Bertl | 10:26 | |
| *** kgugala has quit IRC | 12:15 | |
| *** kgugala has joined #litex | 12:15 | |
| 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. | 13:42 |
| _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. | 14:25 |
| *** roboknight has quit IRC | 14:39 | |
| *** roboknight has joined #litex | 14:43 | |
| 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 :) | 15:27 |
| *** lkcl has quit IRC | 15:52 | |
| *** lkcl has joined #litex | 16:05 | |
| *** Bertl is now known as Bertl_oO | 16:22 | |
| _florent_ | somlo: :) (in the quest of linux-on-litex-rocket as single README file? :)) | 17:53 |
| somlo | yeah, a.k.a. "upstream-first" :D | 17:55 |
| *** Bertl_oO is now known as Bertl | 18:01 | |
| *** somlo has quit IRC | 18:30 | |
| *** somlo has joined #litex | 18:56 | |
| *** cjearls has joined #litex | 18:57 | |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| cjearls | That's what I would've thought as well | 19:03 |
| 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:04 |
| 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:05 |
| cjearls | Oh, cool, I already have buildroot working so I could transfer the program I wanted to run to the microSD | 19:06 |
| daveshah | There will be a compiler somewhere in there, or you can do it properly and make your program a buildroot package | 19:07 |
| cjearls | Ok, I'll take a look at that | 19:24 |
| 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:33 |
| *** roboknight has quit IRC | 19:33 | |
| *** vitalmixofnutrie has joined #litex | 19:51 | |
| cjearls | I built the buildroot compiler, and it appears like file access is working properly now. Thanks for your help | 19:54 |
| *** leons has quit IRC | 20:10 | |
| *** leons has joined #litex | 20:10 | |
| *** roboknight has joined #litex | 21:05 | |
| *** roboknight has quit IRC | 21:08 | |
| *** Bertl is now known as Bertl_zZ | 21:27 | |
| *** FFY00 has quit IRC | 22:47 | |
| *** FFY00 has joined #litex | 22:48 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!