kgugala has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Melkhior has joined #litex
<Melkhior>
Hello, I was checking the SoC size in my FPGA, and it seems that the default is much bigger now (using master HEAD for VexRiscv, not the default files in pythondata for the current test) than it was when I started. I had a note at 5400 LUT and now it is 8142. Pure curiosity not an issue, I am just wondering why. Is it because the new SoC has SMP
<Melkhior>
capability by default ? (I'm still using just one core in those tests). TIA
_whitelogger has joined #litex
<_florent_>
Melkhior: Hi, Dolu really tried to minimize the impact of SMP in the single core configuration, but it's still probably a bit bigger. This is also using the native LiteDRAM interface, if you want something very close to the previous configuration, you can try to use the Wishbone interface by adding: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/make.py#L211
<Melkhior>
_florent_ Thanks ; what's the difference between 'native LiteDRAM' and wishbone - bigger/smaller, bandwidth, latency ? (again just curious ; I was just checking the impact of my new stuff and the baseline has moved hence my curiosity :-)
<_florent_>
Melkhior: VexRiscv SMP can be directly interfaced to LiteDRAM for better performance/efficiency instead of using the common bus of the SoC that is shared with all the peripherals.
<Melkhior>
_florent_ so this direct connection is better/faster ? Then I'm going to stick with it :-)
<Melkhior>
I'm adding a lot more overhead with my extra instructions anyway:-)
<Melkhior>
thanks
mikeK_de1soc has joined #litex
<cr1901_modern>
_florent_: >VexRiscv SMP can be directly interfaced to LiteDRAM
<cr1901_modern>
How does that separate bus work? Is there a block diagram?
<mikeK_de1soc>
_florent_: I just wanted to apologize for my behaviour yesterday, I guess I am a little excited to get the VGA working on my board. Take the time you need to work on the VGA portion. Whenever you publish your work, I will definitively use it! Thanks. MikeK.
<_florent_>
Melkhior: yes direct connection has better performance: less latency, increased data-width and burst support
<_florent_>
Melkhior: BTW, I also ordered a Arrow Deca board
<cr1901_modern>
Thanks. Hmmm... so there's muxes to swap between litedram bus and I/O bus. Does this increase performance in any case besides "one core is accessing the I/O bus and another core is accessing the litedram bus"?
<_florent_>
mikeK_de1soc: I haven't noticed an inappropriate behavior yesterday, getting Video working is indeed very nice since very visual and I can understand you can be excited. It will just be easier for me to have a closer look an maybe do some simplification to support more configurations since current support is a bit experimental. I should work on this very soon.
<Melkhior>
_florent_ Cool for the Deca, will got one, don't know how much help I will be though beyond testing...
<_florent_>
cr1901_modern: that fact that it supports bursts, has an increased data-width and lower latency reduce the bottleneck between the CPU and memory
<cr1901_modern>
Oh it's possible to mux two wishbone buses where one supports burst and the other doesn't, and get the burst performance?
* cr1901_modern
will have to take a look when he has time
<mikeK_de1soc>
_florent_: Thanks! :)
<_florent_>
cr1901_modern: not yet in LiteX main SoC but BMB on VexRiscv'sice and the Native LiteDRAM interface support bursting
<cr1901_modern>
Cool
<cr1901_modern>
_florent_: Last q for now :P >>
<cr1901_modern>
If I have an external core written in nmigen that I want to include in a litex design, is there a canonical way in litex to generate the verilog so it goes in the build dir
<mikeK_de1soc>
I second that! I also have a Verilog file that I have created. how can we include the design into litex!
<mikeK_de1soc>
But my design is connected to the GPIO pins. MAybe we can use the same..
<mikeK_de1soc>
same method...
<cr1901_modern>
the minerva core has to already do this, but I think it's special-cased via a pythondata package that mithro made
<mikeK_de1soc>
where is the minerva core? My goal is to connect a High speed ADC board that I have for my DE1-SoC. The THDB-ADA. 150 Msps ADC and Dac. They have example verilog code I believe.
<cr1901_modern>
litex/soc/cores/cpu/minerva
<mikeK_de1soc>
ah ok.. it's a cpu core.. is this the same core that Linux-on-litex-vexriscV? I am still learning the in's and out of this stuff..
<mikeK_de1soc>
From my understanding no...
<cr1901_modern>
No, it's a different core
<mikeK_de1soc>
of the 2 cores, which one is more feature rich? I am suspecting the Linux-on-litex-VexriscV.
<cr1901_modern>
Most ppl for most situations have converged on vexriscv
<_florent_>
cr1901_modern: in fact pythondata is just a way to package the sources and get them during the build. The nMigen to verilog elaboration is done during the build here:
<_florent_>
that already provides a way to configure the nMigen sources and generate a verilog file for the CPU
<_florent_>
but the approach is in fact very similar with SpinalHDL/VeRiscv where we can generate during the build configurations that are not included in the pre-generated configurations.
<cr1901_modern>
Ahh okay thanks
<Melkhior>
Dumb question; as VexRiscv is an expandable core so well integrated with LiteX for RV32, how much effort would it be to have 'VexRiscv64' that would be pretty much the same but 64-bits ? (i.e. RV64I[M][A][C])
<Melkhior>
Work on extensions could probably use an easily-extensible RV64 core similar to VexRiscv for RV32 :-)
<_florent_>
Melkhior: that would be a question for Dolu
<Melkhior>
_florent_ yes probably. LiteX would only see the wider memory request I suppose. Though the BIOS/bootloader/kernel would be affected to some extent... probably not a trivial exercise
<Melkhior>
Litex already work with Rocket, so I guess most of that would be fine by default
<_florent_>
Melkhior: gsomlo already did the BIOS adaptation for Rocket indeed, so there shouldn't be that much work on the LiteX side.
<Melkhior>
using the integrated 'boot.bin' as @somlo does for Rocket (I tried porting opensbi, but coudl'nt make it work)
<Melkhior>
seems it's tough adding instructions in RV64 cores, while I did Zks (for chinese crypto) in Vexriscv in less than two hours as I had the test SW from Krypto :-)
<Melkhior>
VexRiscv is really nice for that kind of work - and with Litex it's just another linux box so SW is easy as well !
<Melkhior>
kudos again :-)
<somlo>
Melkhior: integrated boot.bin is b/c I wanted to reuse BBL (from riscv-pk) as the "emulator"
<somlo>
I guess opensbi is theoretically possible, and "a simple matter of programming" :P
<somlo>
Melkhior: It's lower on my list of priorities because I'm still scarred by the experience of dealing with edk2 a few years ago :D And I really badly want opensbi to be less of a dumpster fire, and I hope it is, but I'm afraid that if I look at it it'll turn out to be just as horrible
<somlo>
It's PTSD, basically :D
futarisIRCcloud has joined #litex
<Melkhior>
@somlo opensbi wasn't too bad, I rebuild it in RV64 after fixing what I thought were the relevant bits (constants, mostly) ... and then it compiled but didn't work and I had no idea what to do :-)
<somlo>
oh, good to know, thanks! I know Fedora-rv64 switched to opensbi (from BBL) at some point around 29..31
<somlo>
so if I ever get sdcard (or sata) to the point where something like systemd can boot from without timing out, I/we will have to deal with it
<Melkhior>
it works fine with linux-on-litex-vexriscv now, that's the default bootloader now I think (anyway that's the one I always use)
<mikeK_de1soc>
I have a question about the boot-loader if that's ok. I am in the process of compiling the linux-on-litex-vexriscv for the DE1-soc. Once i get it working, I want to load the bootloader. From my understanding, i would need a separate serial connection to the de1-soc separate from the jtag port? they mention GPIO pin 0 - 1 for TX and RX. this is for
<mikeK_de1soc>
the linux boot loading?? or can I use the same Jtag port, but it reroutes the serial connection inside? still puzzled.
kgugala has joined #litex
kgugala has quit [Read error: Connection reset by peer]
kgugala has joined #litex
kgugala_ has quit [Ping timeout: 256 seconds]
<mikeK_de1soc>
OH man, I am so CLOSE!!!
<mikeK_de1soc>
I get the Litex Prompt, but i think my serial connection is not good..
<mikeK_de1soc>
ARggg....
<mikeK_de1soc>
where can i change the speed in the litex code, I want to use 115K... :0
<Melkhior>
mikeK_de1soc in linux-on-litex-vexriscv, the default speed is set in soc_linux.py
<mikeK_de1soc>
so i have to set it to 115-2 in soc_linux?
<mikeK_de1soc>
i am assuming...
<Melkhior>
that's a trick:-) it's 115.2 by default in litex, but linux-on-litex-vexrisc override the default in the SoC in the python definition
<Melkhior>
at least that's my understanding of it
<Melkhior>
when using Linux you need a fast serial port if you use that to upload the BIOS/kernel/rootfs
<Melkhior>
even at high speed, it still takes forever
<mikeK_de1soc>
yeah i get that part... I just want SOMTHING to work...
<mikeK_de1soc>
ANYTHING!!!
<Melkhior>
if your board has a supported micro-sdcard slot, use that for those files, and use 115.2 (or lower) for the console, you will save yourself a lot of waiting ...
<Melkhior>
but beware - micro-sd can be even more temperamental than serial !
<mikeK_de1soc>
yes... but the de1-soc, the SD card slot is connected to HPS...
<mikeK_de1soc>
i think...
<mikeK_de1soc>
is this correct... def __init__(self, cpu_variant="linux", uart_baudrate=115.2e6 **kwargs):
<Melkhior>
no! that would be 115.2 mbit/s:-) because of the e6
<Melkhior>
it's scientific notation
<mikeK_de1soc>
yes yes yes
<mikeK_de1soc>
sorry i meant 3
<Melkhior>
uart_baudrate=115200 will do
<mikeK_de1soc>
yes yes
<mikeK_de1soc>
o kgreat
<Melkhior>
hopefully I remember this correctly, went through the same questions/issues when I started LiteX some months ago :-)
<mikeK_de1soc>
Pay it Forward!!! Thanks buddy!!! beers on the way... :)
<Melkhior>
exactly :-)
<Melkhior>
good luck
<mikeK_de1soc>
yup.. Tanks!
<mikeK_de1soc>
it's working!!!!! :)
<mikeK_de1soc>
but melkhior no here... :(
<mikeK_de1soc>
ok i have the litex Prompt!!!! how do i load up the linux image?
<Melkhior>
back, cool if it works :-)
<Melkhior>
type 'help' :-)
<mikeK_de1soc>
help
<mikeK_de1soc>
oops wrong window
<mikeK_de1soc>
:)
<Melkhior>
:-) :-)
<mikeK_de1soc>
LiteX BIOS, available commands:
<mikeK_de1soc>
leds - Set Leds value
<mikeK_de1soc>
flush_l2_cache - Flush L2 cache
<mikeK_de1soc>
flush_cpu_dcache - Flush CPU data cache
<mikeK_de1soc>
crc - Compute CRC32 of a part of the address space
<mikeK_de1soc>
ident - Identifier of the system
<mikeK_de1soc>
help - Print this help
<mikeK_de1soc>
serialboot - Boot from Serial (SFL)
<mikeK_de1soc>
reboot - Reboot
<mikeK_de1soc>
mem_speed - Test memory speed
<mikeK_de1soc>
mem_test - Test memory access
<mikeK_de1soc>
mem_copy - Copy address space
<mikeK_de1soc>
mem_write - Write address space
<mikeK_de1soc>
mem_read - Read address space
<mikeK_de1soc>
mem_list - List available memory regions
<mikeK_de1soc>
sdram_test - Test SDRAM
<Melkhior>
for VexRiscv, you will normally need a 'boot.json', which describe where to put which files, normally DTS, kernel, bootloader & rootfs
<mikeK_de1soc>
yes i have that.. but i can;t find it...
<mikeK_de1soc>
itex> serialboot
<mikeK_de1soc>
Booting from serial...
<mikeK_de1soc>
Press Q or ESC to abort boot completely.
<mikeK_de1soc>
sL5DdSMmkekro
<mikeK_de1soc>
[LXTERM] Received firmware download request from the device.
<mikeK_de1soc>
Exception in thread Thread-1:
<mikeK_de1soc>
Traceback (most recent call last):
<mikeK_de1soc>
File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
<mikeK_de1soc>
self.run()
<Melkhior>
you pass it to lxterm as --serial-boot or something like that (test system down ATM)
<mikeK_de1soc>
File "/usr/lib/python3.8/threading.py", line 870, in run
<tcal>
Sometimes after you connect with lxterm, if you just have the litex prompt, type "serialboot" there to kick things off (sometimes it's automatic, sometimes not). If you don't have the litex prompt but the litex bitstream is loaded, it will reboot if you hit the "reset" button (this is common on Arty boards; I didn't catch which board you were using).
<Melkhior>
some stuff got cut
<mikeK_de1soc>
the DE1-Soc..
<mikeK_de1soc>
i got it work manually...
<Melkhior>
I suggest moving all the files in the current directory and just have filename (no path) in the boot.json, just to make sure it's not a weirdness in the paths
<Melkhior>
seems it can find the kernel image in images/Image, but relative to what ...
<tcal>
Looks like a problem on the lxterm side? Yes, good suggestion by Melkhior.
<mikeK_de1soc>
ok so move the boot and rv32 to the previous directory.. ok doing that...
<Melkhior>
and check for typo :-)
<Melkhior>
been there, done that :-)
<mikeK_de1soc>
humm. interesting differnt error... File "/home/mikek/Documents/Cyclone5_SOC/Litex_directory/litex/litex/tools/litex_term.py", line 358, in upload
<mikeK_de1soc>
f = open(filename, "rb")
<mikeK_de1soc>
FileNotFoundError: [Errno 2] No such file or directory: 'Image'
<mikeK_de1soc>
which directory should you be running this in???
<mikeK_de1soc>
in the build directory?
<Melkhior>
it worked for me when eveything was in the same directory, and I started lxterm from there as the working directory ...
<Melkhior>
'Image' is the linux kernel, is it there with the right name ? plural & caps are killers :-)
<mikeK_de1soc>
that's just it I don;t see the Image file at all??
<Melkhior>
oh it's normal then :-)
<Melkhior>
you need to copy it over from the buildroot
<Melkhior>
along with rootfs
<mikeK_de1soc>
AH....... ok......
<mikeK_de1soc>
yes, i still have to do the buildroot stuff......
<Melkhior>
hehe :-)
<Melkhior>
yes you do
<mikeK_de1soc>
i was just getting the DE1-Soc up and running... look like I succeeded!
<Melkhior>
you need 4 files in there for the json
<mikeK_de1soc>
ok so where do i follow next in the instructions..
<mikeK_de1soc>
BTW.. the memory test worked!!!!
<mikeK_de1soc>
:)
<mikeK_de1soc>
the SD ram!!
<mikeK_de1soc>
ok i only have 2 files... boot.json and rv32.dtb
<mikeK_de1soc>
HAppy HAppy Joy Joy!!!!
<Melkhior>
the DTB which is from the DTS generated - i think - by linux-on-litex-vexriscv (you may need to compile the DTS to DTB using dtc)
<Melkhior>
the bootloader, which is likely OpenSBI (can be something else, OpenSBI is probably best), there's an opensbi repo for it for LiteX
<Melkhior>
the kernel & rootfs, which you get from buildroot (Image and rootf.cpiuo respectively)
<Melkhior>
and then the boot.json tells where to put those 4 in memory
<Melkhior>
great :-)
<Melkhior>
good luck with the buildroot!
<Melkhior>
got to go
<Melkhior>
bye
<mikeK_de1soc>
thanks man!!!!
<Melkhior>
4 + boot.json
<Melkhior>
really bye :-)
<mikeK_de1soc>
:)
alex83 has joined #litex
alex83 has quit [Client Quit]
<mikeK_de1soc>
YES SIR!!!
<mikeK_de1soc>
WORKING!!!!
<mikeK_de1soc>
Yup it's slow!!!!
sorear has quit [Remote host closed the connection]
davidlattimore has quit [Remote host closed the connection]
_florent_ has quit [Remote host closed the connection]
_florent_ has joined #litex
sorear has joined #litex
davidlattimore has joined #litex
Bertl is now known as Bertl_oO
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #litex
davidlattimore has quit [Remote host closed the connection]
sorear has quit [Remote host closed the connection]
_florent_ has quit [Remote host closed the connection]
_florent_ has joined #litex
sorear has joined #litex
<shorne_>
somlo: so I read up a bit more on the MMC kernel layers, what do you think will happen with litex_mmc is issued a multiblock transfer? it seems the request() code path will be the same, just the size of the buffer will be bigger sent to LITEX_MMC_SDBLK2MEM_LEN_OFF will be bigger. Then would we expect the hardware to handle the multi block protocol?
davidlattimore has joined #litex
<shorne_>
somlo: that is what it looks like, I put in a debug statement for write and did some simple test
<somlo>
shorne_: yeah, we just allocate buffers that correspond to the larger max_req_size, and it all "should" work out when the core mmc layer decides it's time to use cmd18 for reads instead of cmd17
<shorne_>
etc. it seems all commands after we try the multi block transfer fail
shorne_ is now known as shorne
<somlo>
right, it seems the card itself and/or the LiteSDCard FSMs somehow take a "wrong turn" somewhere and get stuck
<somlo>
I'm trying to find a slightly more detailed spec of the SDCard PHY layer than what's available at https://sdcard.org/downloads/pls/
<shorne>
alight, so the driver is a bit sub optimal but it seems we should be doing the "right" thing
<tpb>
Title: Simplified Specifications | SD Association (at sdcard.org)
<shorne>
Yeah, I have been looking for a good spec too