07:41 <geertu> nickoe: somlo: Just look at the generated images/boot.json

07:41 <geertu> linux-on-litex-vexriscv$ cat images/boot.json

07:41 <geertu> { "Image": "0x40000000", "rv32.dtb": "0x40ef0000", "rootfs.cpio": "0x41000000", "opensbi.bin": "0x40f00000"

07:41 <geertu> }

07:42 <geertu> (hmm, somehow the LFs after commas got lost)

09:24 <nickoe> geertu: Yeah, thank you. I will try it out when I get home.

16:42 <nickoe> geertu: Can I put a bitstream on to the sdcard as well?

16:42 <nickoe> Or only things that are to be loaded into memory of the soc?

17:05 <somlo> nickoe: loading bitstream from an sdcard is a feature that depends on your board (typically there's a jumper that configures whether the board should search for a .bit file on the first msdos formatted partition of an sdcard, or whether it should wait to be programmed over jtag/usb, etc.)

17:06 <nickoe> somlo: well, it looks like the bios searches for it, but I just tried to reload the bios.bin, but that sorta does not boot properly

17:07 <nickoe> somlo: So I just flashed the bittream on the device, and then https://dpaste.com/GRAQGX2H9

17:07 <tpb> Title: dpaste: GRAQGX2H9 (at dpaste.com)

17:07 <nickoe> it gets stuck in the end of that paste.

17:07 <somlo> nickoe: the bios "software" (or "firmware" if you will) is part of the bitstream itself, an gecomes accessible to the SoC as a SRAM "memory" once the FPGA has been programmed

17:07 <nickoe> I am not sure whats up with that.

17:08 <nickoe> yes, so I would expect that I can reload that as is again?

17:08 <somlo> how you get bitstream into the FPGA happens way before this thing even "nows" it's supposed to act out a LiteX SoC, which includes the ROM containing the bios for the "cpu" to "execute" :)

17:08 <somlo> * "knows"

17:09 <nickoe> But shouldn't I be able to reload and reboot the original bios.bin?

17:10 <somlo> litex_term will under certain circumstances let you load a new bios without needing to rebuild the whole bitstream that includes its default, "burned-in" state

17:11 <somlo> but you asked "can I put a bitstream on the sdcard", which is somewhat orthogonal to "can I update the bios opcodes of a default bios that came as part of the bitstream" :)

17:12 <somlo> the first one is "depends on whether the board will do that for you"; the latter is "yes, via litex_term, and I'm not super familiar with the details of *that*"

17:13 <nickoe> somlo: well, yes, but I wanted to verify that the bin file I am trying to boot from a sdcard works via serialboot fist.

17:13 <nickoe> *first

17:14 <nickoe> I figure, if I can serialboot a bin, it should also work on the sdcard. It is a bit eaasier to serialboot than sdard boot when testing.

17:15 <somlo> that makes sense -- as long as the only things you're changing are in the bios (i.e., *not* in the gateware itself), loading a fresh bios on top of what came default with the bitstream should save you all the vivado synthesis/place/route

17:15 <futarisIRCcloud> https://github.com/riscv/meta-riscv/pull/267 - RV32 should be working in meta-riscv openembedded now. Anyone tried it on litex yet?

17:21 <nickoe> how do I build this demo software? https://github.com/enjoy-digital/litex/tree/master/litex/soc/software/demo

17:22 <nickoe> there appears to be some more documentation about the boot stuff at https://github.com/enjoy-digital/litex/wiki/Load-Application-Code-To-CPU

17:25 <nickoe> similar issue when booting it from sdcard, https://dpaste.com/CDHDV2V7V

17:25 <tpb> Title: dpaste: CDHDV2V7V (at dpaste.com)

17:25 <nickoe> it sorta boots, but crashes.

17:26 <nickoe> _florent_: Any hint?

18:59 <nickoe> I created a bug abour the demo example seemingly not building https://github.com/enjoy-digital/litex/issues/814

19:08 <_florent_> nickoe: sorry, haven't been able to look at it yet, will do this evening or tomorrow

19:08 <_florent_> nickoe: for the demo, please be sure to first execute the target you want to test with to generate the software headers required by the demo app

19:09 <nickoe> _florent_: What command should I use for the arty? I mean, I was just following the README of the demo project.

19:13 <nickoe> ah, ok, now it did build the demo

19:40 <nickoe> ugh, the demo.bin boots fine via serial boot.. somlo :O

19:49 <nickoe> ok, that donut is fun

20:12 <nickoe> Is the only way to update the bitstream on artix7 to flash it directly via jtag or popping it on a SPI flash device?

20:27 <nickoe> gttp://www2.futureware.at/~nickoe/aausat/20210211_205012.mp4

20:28 <nickoe> I wonder why the demo.bin is different to the bios.bin... in that the bios.bin when serialbooted boots a bit and crashes, while the demo.bin does not.

22:38 <tcal> nickoe: maybe check which base address bios.bin was linked for? You can check by disassembling the .elf. demo.elf shows that it's compiled for base address 0x40000000, which is where serialboot puts it, so it's happy.

22:42 <nickoe> tcal: like this? https://dpaste.com/CVYEFLJGD

22:42 <tpb> Title: dpaste: CVYEFLJGD (at dpaste.com)

22:43 <tcal> Yeah, I see the .text and .rodata sections in 0x40000000, which is good.

22:44 <tcal> Now try with the bios.elf for the bios.bin that crashes.

22:44 <tcal> oh sorry i missed it

22:45 <tcal> yeah, you might be able to get bios to boot again, at 0x40000000, by adjusting the linker.ld script. I've never tried that.

22:47 <tcal> In what you pasted, you can see that the bios is linked to start executing at 0x00000000, which is the ROM for the Arty SoC.

22:52 <nickoe> tcal: ok. I wil play around with the demo project for a bit

22:52 <tcal> 👍

22:53 <nickoe> but that sorta explains why it is wonky.. I mean if the ld config for it is not the same.

22:53 <nickoe> although I am not sure why they are different by "default"

22:56 <tcal> Yep, there's a lot of little details. BIOS is meant to be the first thing that runs, to enable the SoC to load the actual "user application", so it's built into ROM. The demo is meant to be such a "user application". That's why by default they're linked for different memory regions. Serialboot is for the user app, so by default it sticks things at 0x40000000, although that can be overridden by the lxterm

22:56 <tcal> --kernel-adr option.

23:04 <nickoe> heh, I was like.. . why the hell can't I change this register... I forgot to build the bitstream and load it... --- at least I hope that is the reason.

23:05 <nickoe> tcal: Hm, yeah, makes sense.

23:05 <nickoe> tcal: is it possible to "sideload" a bitstream like with the firmware?

23:06 <nickoe> I mean the gateware

23:10 <tcal> Lots of things are possible! I'm pretty new to this area myself, so I'm not the best to answer. Foboot does some pretty amazing things for example, in a very constrained context. Do you mean something like load a new bitstream from an sdcard?

23:16 <nickoe> tcal: yeah

23:17 <nickoe> ok,I think I got my little register thing to work https://dpaste.com/CMNTCGG4R

23:17 <tpb> Title: dpaste: CMNTCGG4R (at dpaste.com)

23:17 <nickoe> next up, double check that the output matches with a logic analyer for sanity checking, but that must be tomorrow.!

23:18 <tcal> Cool! Reloading a bitstream....that's pretty board and device-dependent...

23:20 <nickoe> tcal: yeah, probably, but is as a SPI flash which I think the artix7 can boot from, but dunnot how to do that yet.