06:28 <KSmith> _florent_ thanks for the reply yesterday, i was able to use commit 88a268354daaaa6422ed875ad8c580dbaf1d81a1 and it no longer gives an error and generates an image. i have a follow up question, buildroot generates 3 files in output/images rootfs.tar, rootfs.cpio and Image, however reading boot.json and looking at the prebuilt i require 4 files

06:28 <KSmith> root.cpio, Image, rv32.dtb and emulator.bin, were the emulator.bin and rv32.dtb suppose to be generated or is there another step required to get these two files?

10:49 <Krickit> hi everyone

10:50 <Krickit> there is anyone?

10:51 <sorear> if you have a specific question, you'll get an answer faster if you ask it now with as many details as possible

10:51 <sorear> this applies to most IRC channels

10:52 <Krickit> yes I generated i liteX for my versa ecp5 with picorv32

10:53 <Krickit> when i try to do place and route i have this error: Unable to reach CIB within 1 routing segment for clock 'clk100_1' with driver 'clk100' at site 'P3/PL68C'

10:54 <Krickit> i did't change nothing and I verified all PIN

10:54 <daveshah> You are doing anything else unusual? Or just using the target as is

10:54 <Krickit> just using the target

10:55 <Krickit> I want understand how it works now

10:55 <Krickit> is it a possible falsepath?

11:04 <daveshah> No not a false path, rather it is unable to use the correct clock routing for some reason

11:06 <Krickit> any suggestions?

11:45 <Krickit> I resolved

11:46 <Krickit> EHXPLLL (//.CLKI(main_crg_clkin),

11:46 <Krickit> changed CLKI(main_crg_clkin) with CLKI(clk100)

11:47 <Krickit> in the up lines there is a assign between those clock

11:47 <Krickit> and this, for diamond, is a problem in the route's fase

12:28 <Melkhior> KSmith I think the rv32.dtb is generated by the bistream generation process in linux-on-litex-vexriscv, in the directory buildroot/ (as a device tree, it is board/configuration-specific)

12:29 <Melkhior> The emulator is also in linux-on-litex-vexriscv, in emulator/emulator.bin

12:31 <Melkhior> I also have a question on booting linux-on-litex-vexriscv.I've managed to create a new platform/target in litex-boards for my board, generate a bitstream, get the litex prompt, watch the LEDs do their thing, and load a kernel. So far so good :-)However, if I use a prebuilt image from GitHub, the process hangs after:"Starting network: OKStarting

12:31 <Melkhior> dropbear sshd: [ 0.000000] random: dropbear: uninitialized urandom read (32 bytes read)OK"It seems to just sit there, not responding to the serial console (I only have a serial connection, plus some LEDs, no ethernet/sd/...).If I rebuild my own image in buildroot (from an existing tag such as 2020.08.x, as HEAD seems broken as mentioned in

12:31 <Melkhior> aGitHub issue), both the simulation and the real FPGA fail to boot with:"[ 0.000000] Kernel panic - not syncing: Scratch register read error! Expected: 0x12345678 but got: 0x78000000"

12:32 <KSmith> Melkhior thanks, i eventually figured it out after experimenting for a while. does the order in which you use make(get rv32.dtb and emulator) and generate the linux image(Image and roottfs.cpio have any influence/matter?

12:33 <KSmith> im also having end Kernel panic - not syncing: Scratch register read error! Expected: 0x12345678 but got: 0x78000000 error when attempting to test my own image

12:33 <KSmith> this is for the nexys4ddr board

12:34 <KSmith> https://pastebin.com/mJEz2qru

12:34 <tpb> Title: Kernal Panic - Pastebin.com (at pastebin.com)

12:41 <Melkhior> KSmith yes I see a similar backtrace...

12:41 <Melkhior> perhaps try the prebuilt one, to see if it goes further (for me it does, just seemingly hangs after starting sshd)

12:50 <KSmith> the prebuilt linux is working for me, i believe i have had it stop after dropbear and before login, however i was messing around with alot of different things so im unsure of what caused it

15:52 <Krickit> hi,

15:54 <Krickit> with the board Versa_Ecp5 what I have to do in order to view the text from UART?

15:57 <daveshah> Connect to the USB serial port (the second if there are two) at 115200 baud

16:06 <Krickit> yes, but is there any default text that should display?

17:07 <st-gourichon-fid> Hi! On a design with a SERV doing aligned 32bit read at flash then at next address (thus unaligned by one byte) appears to crash the CPU.

17:11 <st-gourichon-fid> Same crash with VexRiscV instead of SERV.

17:12 <st-gourichon-fid> Could it be a (known) bug in the flash-handling code?

17:35 <st-gourichon-fid> Now we do 8bit reads only, instead of 32bit reads, no crash.

19:58 <zyp> st-gourichon-fid, are unaligned reads supposed to be supported at all though?