07:04 <_florent_> nickoe: the --init args in litex_sim only support binary files for now, I could add json support but this is not yet the case

07:04 <_florent_> nickoe: for a small demo of litex_sim with ram initialization, you can do:

07:04 <_florent_> litex_sim

07:04 <_florent_> litex_bare_metal_demo --build-path=build/sim

07:05 <_florent_> litex_sim --ram-init=demo.bin

07:07 <_florent_> when using --with-sdram and --sdram-init, you also have to be aware that the initial memtest can corrupt the pre-initialized content

07:08 <_florent_> you can disable the memtest by adding this: https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/sim.py#L146

07:45 <nickoe> Right now my "custom software" os just the demp modified a bit.

07:53 <shenki> _florent_: I got the sd card working! I saw someone else had a PR up that described the correct pinout; once I copied that it worked (but not with the card I was first using, I had to use a different one)

07:53 <shenki> I sent a PR taht adds support for the numato sd card adaptor

10:33 <_florent_> shenki: great! I saw the PR, I'll merge it, thanks. (In the future we'll probably create definitions of the different PMODs outside the targets to be able to use a specific PMOD with a specific target more easily :))

10:34 <shenki> No worries

10:35 <_florent_> shenki: there is currently an issue with the Linux SDCard driver (issue in the driver or gateware, we don't know yet), if you hit this, please let us know :)

10:35 <_florent_> https://github.com/enjoy-digital/litesdcard/issues/22

10:40 <shenki> I've been using it today with mor1kx and it was ok so far

10:40 <shenki> _florent_: it does hang sometimes in the bios. I am netbooting, so I want the sd read to timeout, but some times it does not

10:45 <_florent_> shenki: IIRC I also saw this, I should do more testing on this.

12:52 <rozpruwacz> Hi all. I just started tinkering with the litex. I'm using de0 nano board and I wonder what would be the best way to add some new peripherials to the already defined de0nano board. For example, I want to add SD card controller or ethernet mac because I have some breakout boards that I can connect to GPIO connectors. Currently the de0nano board

12:52 <rozpruwacz> defines just gpios so I would somehow override those to use them for my peripherials. What would be the most elegant way to do it ? Copy paste'ing entire platform and board files seems not so elegant to me. Is there a better way ?

12:56 <zyp> rozpruwacz, platform.add_extension()

13:06 <rozpruwacz> thanks, I look into it

13:15 <rozpruwacz> I see that I can also reffer to already defined GPIOs trough defined connector like this: Pins("JP2:3"). quite neat :)

13:28 <_florent_> rozpruwacz: here is an example with SDCard pins added with add_extension: https://github.com/enjoy-digital/litesdcard/blob/master/bench/trellisboard.py#L40-L51

13:29 <_florent_> in your target you can then get the pads with platform.request() as if it was defined in the platform file

13:30 <_florent_> otherwise to extend an existing target, you can just copy the litex_boards target and add your own peripherals after the ones defined in BaseSoC (or create another target reusing BaseSoC from litex_boards)

13:32 <_florent_> the previous example I gave is extending BaseSoC from litex_boards target

14:55 <mikeK_de1soc> rozpruwacz: which DE0-nano board are you using? The de0-nano-Soc?

14:56 <mikeK_de1soc> I got some stuff working on the De1-Soc..  similar board..

14:56 <rozpruwacz> no, DE0-nano with cyclone IV FPGA

14:56 <mikeK_de1soc> Ah, ok.. thanks..

14:57 <rozpruwacz> Do You use liteeth ip ?

14:57 <mikeK_de1soc> Do you have a SD card connected on the GPIO pins?

14:57 <rozpruwacz> not yet but I plan to do so

14:58 <mikeK_de1soc> no... not there yet... the reason I am asking on the DE1-Soc the Ethernet is connected to the HPS side of the chip..

14:58 <rozpruwacz> I'm trying to setup ethernet but have problem with liteeth ip. The synthesis generates 30k+ LEs

14:58 <mikeK_de1soc> yup..

14:59 <mikeK_de1soc> I got he RiscV to go on my board, bit it's taking up 20K LE's

14:59 <mikeK_de1soc> If we can try to figure out how to use the HPS side of the chip! I am all ears!  :)

15:11 <trabucayre> mikeK_de1soc: I suppose it's the same approach as for the PS (zynq)

15:12 <mikeK_de1soc> PS? not sure of that board..

15:12 <trabucayre> as long as you can avoid to use qsys :)

15:12 <mikeK_de1soc> yeah..

15:13 <mikeK_de1soc> it's just a shame... we need a board that has like a HUGE LE fpga...   :)

15:13 <mikeK_de1soc> jsut expensive..

15:14 <trabucayre> yep

15:41 <acathla> xobs, _florent_ : I want to write something similar to foboot but working over infrared instead of USB. Should I take the code I need to flash the SPI flash memory from foboot or is there something more recent or more adapted in LiteX? Or somewhere else?

15:42 <acathla> the flash write part seems tightly integrated with DFU

15:44 <_florent_> acathla: we don't have something equivalent to foboot directly in LiteX, so yes I would say you can look at foboot (I think foboot was used as the DFU booloader for Fomu and OrangeCrab)

15:45 <acathla> Ok, DFU seems not that much linked to USB.

15:45 <acathla> Thank you

15:47 <_florent_> maybe there is a new/different bootloader developed for Betrusted by xobs/bunnie, but I've not been following closely the development

15:49 <_florent_> but at least I know we don't such bootloader directly in LiteX :), so foboot is a good candidate if you want Migen/LiteX code

16:24 <xobs> acathla: mostly it was a bit banged spi driver.

16:25 <xobs> It was originally taken from toboot, which traces its lineage back to the fadecandy bootloader.

17:24 <mikeK_de1soc> I just got a LED counter to work in Litex... OH joy!  :)   Feel like a High school Student!  ;)

17:48 <acathla> congratuations mikeK_de1soc ! =)

18:10 <mikeK_de1soc> Thanks!  still learning migen-Litex- and nMigen... my goal is to get this ADC DAC board working..   baby steps..

18:13 <mikeK_de1soc> acathla: for what's it's worth.. I found this file:  "dfu.py" in the litex/litex/build  directory..  if this helps..

18:13 <mikeK_de1soc> place to start playing!! :)

18:19 <acathla> mikeK_de1soc, it's just to call the dfu-tools

18:28 <mikeK_de1soc> oh ok...

18:45 <somlo> _florent_: do you remember how the argument value for sdcard ACMD41 was picked here: https://github.com/enjoy-digital/litex/blob/master/litex/soc/software/liblitesdcard/sdcard.c#L159 ?

22:00 <nickoe> _florent_: So I did try that --ram-init option to lxsim with the demo.bin but it asserts. https://dpaste.com/6ERQAYU59

22:00 <tpb> Title: dpaste: 6ERQAYU59 (at dpaste.com)

22:01 <nickoe> Is that a bug or do I need more options?

22:10 <nickoe> _florent_: https://i.snipboard.io/W3wILk.jpg

22:12 <nickoe> So I run with --ram-init=demo.bin --with-sdram

22:13 <nickoe> why does it think args.ram_init is None?

22:14 <nickoe> it is certainly not none, https://i.snipboard.io/q4LjSG.jpg

22:17 <dayjaby> If with_sdram is set, then you cannot specify a ram_init (that's how I interpret the code)

22:18 <dayjaby> assert ram_init is None just tries to make sure that ram_init is None, which failed the assert

22:18 <nickoe> But is that intended?

22:18 <nickoe> I mean, I would epect to be able to boot my demo app with a simulation of having sdram

22:19 <nickoe> The assert was added in https://github.com/enjoy-digital/litex/commit/411bca790a6a263d994d724f8f366ce5d98e75cc

22:19 <nickoe> I can't really tell if that line, 225 is really intendedor not.

22:19 <nickoe> *intended.

22:20 <nickoe> florent wrote this yesterday,https://dpaste.com/FUF8CFPPP

22:20 <tpb> Title: dpaste: FUF8CFPPP (at dpaste.com)

22:21 <dayjaby> is there no way to fill the RAM later in litex_sim like you could do with litex_term?

22:23 <nickoe> dayjaby: I don't know.

22:23 <nickoe> I guess not because of what florent metioned, but even if I skip the ram test, I guess that is fine as this is a simulation.

22:24 <nickoe> but I tried to add that adn remove the assert. It still does not seem to boot much. I mean, the last thing I see is the liftoff message, but no demo app output.

22:41 <dayjaby> @nickoe did you get the last message: "It seems possible: `$ lxterm /dev/ttyUSBX --kernel=demo.bin`"? I guess you would have to run lxsim with serial. how did you build the demo bin?

22:43 <nickoe> No, when should I have that messagE?

22:44 <nickoe> dayjaby: The demo.bin works fine without the --with-sdram arg and works fine on the real target as well.

22:44 <nickoe> but I build it like, python ../../../litex/litex/soc/software/demo/demo.py --build-path build/mars_ax3/ &

22:46 <dayjaby> ah nice that command worked:)  trying your lxsim call now

22:47 <nickoe> So if you run it without the with sdram arg it should boot the demo instead of the bios

22:52 <nickoe> dayjaby: What do you get?

22:54 <dayjaby> Same as you. Trying to run lxsim with some serial arguments in order to try to boot the demo.bin via lxterm

22:59 <nickoe> I don't think it supports sertial. Maybe the etherbone stuff can be used?

23:01 <dayjaby> Not etherbone then, but rather ethernet. You have to setup a tftp server to host the demo.bin then

23:07 <dayjaby> https://github.com/litex-hub/linux-on-litex-vexriscv#load-the-linux-images-over-ethernet explains the process a bit more detailed

23:10 <nickoe> yeah, well, I am not really interesed in the ethernet for now

23:11 <nickoe> I just wanted to have a simulation with sdram enabled and be able to load my "demo" app

23:12 <nickoe> I have to call it a day

23:12 <nickoe> gn

23:12 <dayjaby> Good night!