02:44 <scanakci> are there some constraints when setting the memory map? I would like to set memory map as provided in the figure. https://usercontent.irccloud-cdn.com/file/cJOYWUih/memmap.png

02:45 <scanakci> I am getting bunch of "relocation truncated to fit" errors. I come across some constraints related to RISCV linker, but could not fix the issue.

02:45 <scanakci> (when I am compiling litex-bios for simulation)

02:46 <scanakci> setting main_ram to 0x8000_0000 fixes the issue, but I need my rom to reside at that address

04:50 <sorear> with both of the currently implemented riscv64 code models, data and text must be less than 2GB apart

04:51 <sorear> if you need rom to be at 80000000, maybe put ram at 40000000

04:51 <sorear> Or have one at 0 and the other at 40000000

14:18 <kbeckmann> On a similar topic, is it possible to have a parent-child like mapping of memory, e.g. main_ram @ 0x8000_0000 which consists of foo_ram @ 0x8000_0000 with length 0x10000, and bar_ram at 0x8000_0000 with length 0x8000, thus creating main_ram at 0x8000_0000 with the length 0x18000

14:19 <kbeckmann> oh i mean of course that bar_ram is located at 0x8001_0000

14:21 <kbeckmann> the reason that i want this is to be able to expose a large contiguous memory area that consists of multiple external different ram modules.

18:00 <scanakci> thanks @sorear. I will keep that in my mind.

18:01 <scanakci> I changed the layout and tried with couple of different memory maps. However, still getting the same errors.

18:01 <scanakci> My observation is that setting rom to 0x8000_0000 is causing this problem.

18:02 <sorear> yes, why do people do that? it seems like a terrible idea

18:02 <sorear> is everyone just blindly copying berkeley or is there an actual reason not to put ram at 0x4000_0000?

18:03 <sorear> don't use 0x8000_0000 or higher for anything if you can help it

18:05 <sorear> if you have more than 1GB of RAM you need to think carefully about what's going to be accessible before MMU setup. after MMU setup, text and data should be virtually adjacent to each other

18:05 <sorear> if you don't have a MMU at all, you probably don't need more than 31 bits for physical addresses

18:06 <sorear> basically don't use 0x8000_0000 for *anything* and you shouldn't get that error

18:07 <scanakci> thank you @sorear.

18:08 <sorear> I'm not upset at you I'm upset that all of the guides to copy put RAM and ROM at the *worst possible* addresses

20:04 <_florent_> kbeckmann: not sure there is a convenient way actually to do parent-child like mapping. One thing you can do is use add_memory_region with type="linker" to do something similar (you have a look at https://github.com/enjoy-digital/litex/pull/285)

20:04 <tpb> Title: [RFC] Linker region concept by mateusz-holenko · Pull Request #285 · enjoy-digital/litex · GitHub (at github.com)

20:24 <kbeckmann> thanks _florent_ , will try it out!

22:06 <scanakci> I guess I am close to running bios on blackparrot. At least, I should be able to print LITEX logo very soon. Currently, I can see that Blackparrot fetches instructions/data properly from ROM/SRAM. I verified that BP is reaching to main function in main.c.

22:10 <scanakci> The problem is that nothing is printed to the console. I see that BP calls printf, putsnonl, uart_write in order. My understanding is that uart_write is the function that is supposed to show texts on the screen. uart_write is performing a csr write as far as I see in the generated/csr.h file.

22:15 <scanakci> I am using uart_polling as a side note. I had tested it before with Rocket and it worked properly.