01:23 <Finde> that's awesome scanakci

01:24 <Finde> must've been a long simulation

02:42 <john_k[m]> Is there a good example of how to using litex software libraries to create a loadable binary?

02:43 <john_k[m]> * Is there a good example of how to use litex software libraries to create a loadable binary?

03:14 <john_k[m]> Skip: what’s the actual error?

03:28 <skip> self.register_mem("emulator_ram", self.mem_map["emulator_ram"], self.emulator_ram.bus, size)

03:29 <skip> I think I got past that. It seems that emulator_ram wasn't in emulator_ram. I added it and now it builds, but I can't get linux to boot.

03:30 <skip> After loading linux ramfs, etc (which takes forever at 115200) I get

03:30 <skip> [LXTERM] Booting the device.

03:30 <skip> and then garbage.

03:31 <skip> I'll bang on it more tomorrow. I'm brand new to litex so I have little clue, but at least it's doing *something* !

03:36 <john_k[m]> I meant what is the error that python spits out

03:37 <john_k[m]> You just showed the line but now what python was complaining about

03:37 <john_k[m]> * You just showed the line but not what python was complaining about

03:51 <scanakci> thanks @Finde, @somlo

03:52 <scanakci> it roughly takes 2 hours until asking for username/password

03:53 <scanakci> Typing username, password is really painful. I gave up and decide to switch to the FPGA

03:54 <scanakci> One thing that I observe is that LiteX converts the bbl into a memory file a little bit wrong. For a reason, first 1024 lines of memory file is wrong and I needed to manually modify the memory file.

03:55 <scanakci> I am using an outdated version, maybe the most recent version will convert it properly :)

09:34 <_florent_> Great scanakci for Linux on BlackParrot, please open an issue if you found something wrong in the simulation

09:35 <_florent_> scanakci: it's now also possible to run the simulation with LiteDRAM and with a DRAM model that could match the configuration you are going to use on hardware

09:35 <_florent_> scanakci: that could be the next step before running on real hardware

09:38 <_florent_> scanakci: imagine you want to run a configuration similar to the Arty board, you can do: litex_sim --with-sdram --sdram-module=MT48LC16M16 --sdram-data-width=16 --sdram-init=your_binary

10:10 <_florent_> john_k[m]: if you want to create firmware and load if to the SoC, you could have a look at: https://github.com/litex-hub/fpga_101/blob/master/lab004/README.md

10:10 <tpb> Title: fpga_101/README.md at master · litex-hub/fpga_101 · GitHub (at github.com)

10:34 <john_k[m]> Thanks florent, I’ll have a look soon

11:30 <somlo> scanakci: I use `riscv64-unknown-linux-gnu-objcopy -O binary bbl boot.bin` after building the bbl blob, that then loads fine on litex (at least with rocket). Not sure that's your problem, but worth a try

17:41 <scanakci> somlo: thanks. This actually fixed the issue on the simulation. I could simulate boot.bin directly after using objcopy. On FPGA, I was getting traps before now I do not. I cannot print sth to the screen, yet. I am asked to add a host mmio device to make it work.

17:43 <scanakci> _florent_: that is actually really nice feature to have. If Linux does not boot up on FPGA, I think I will update my LiteX to try this feature.

18:48 <somlo> scanakci: I'm not sure I follow the "print to screen" issue -- I had to modify bbl to support the litex UART, then used `CONFIG_HVC_RISCV_SBI=y` to have linux trap into bbl for console i/o

18:50 <somlo> scanakci: here's what I changed in bbl: https://github.com/riscv/riscv-pk/compare/master...gsomlo:gls-litex-devel

18:50 <tpb> Title: Comparing riscv:master...gsomlo:gls-litex-devel · riscv/riscv-pk · GitHub (at github.com)

18:50 <somlo> you may find the UART patch useful (unless I misunderstood what the problem is) :)

18:51 <scanakci> oh sorry for the confusion. You are absolutely correct :)

18:51 <somlo> (of course, it may be possible to support the litex uart natively in the linux kernel, but I figured I had more urgent problems to deal with first :) )

18:51 <scanakci> Thanks for pointing me that. I was about to investigate how to support Litex uart

18:54 <somlo> you'll need to pass a DTB (or compile one in, like I do) for BBL, which includes a description of the uart