Data relocation when using LOAD_L2=STANDALONE
#2
(06-09-2020, 02:10 PM)LPLA Wrote: Hello,

as you know PULPissimo has an option to boot from flash by setting the LOAD_L2 parameter in the tb_pulp.sv to STANDALONE.
As far as I know it won't actually boot from flash but instead load the data from flash to the L2 and execute it. Is this still the case?

Bluewww:
It should work but I have recently got some feedback that it required manual changes. I'll try to get them upstream.

So I was running the hello example from the pulp_rt_examples using the STANDALONE variant.
This works just fine but I was wondering about the contents of the different memories after the end of the computation.

We can see that when using STANDALONE the flash memory uses its preload feature to contain "slm_files/flash_stim.slm" which should be the image of the hello example.
When instead using JTAG there is a different image loaded into L2 called stim.txt.

There are several question which I hope someone can answer:



Is there a reason why the actual data from those images is different?
I'm not talking about formatting but rather the actual data itself.
For example:

The first few lines of the .slm file:
@00000000 00
@00000001 70
@00000002 00
@00000003 00
@00000004 04
@00000005 00
@00000006 00
@00000007 00
@00000008 80
@00000009 80
@0000000A 00
@0000000B 1C

The first few lines of the .txt file:
1C000000_0000000000000000
1C000008_0000000000000000
1C000010_0000000000000000

Bluewww:
The images should contain the same data, but I haven't looked into it  in detail. The slm file is just a verilog memory dump that is read with $readmemh into the flash's internal memory (which is why the first address is 0) and then later read by the bootcode, while the .txt files contains the information the pulp tap is supposed to inject into the interconnect that is connected to the L2 (which is why it uses the L2 base address).




I'm pretty sure that the memory called "boot rom" contains the boot code which is unrelated to the executed (hello example) code. Is this correct?
Bluewww:
yes

The code of the hello example should reside somewhere in L2. Now using QuestaSim to check the contents of the different L2 sections I get confused.
There is some data in .../bank_sram_pri0_i/MEM which looks a bit scattered as there are some undefined entries.
The data in .../bank_sram_pri1_i/MEM is more coherent.
Also there is a bit of data in every 0 cut of every CUT X.
By that i mean ...CUTS[X]/RTL_0/bank_i/cut_0/MEM.

What actually resides in pri0, pri1, cut_0?
I struggled to find the data of either the flash_stim.slm or the stim.txt files anywhere in L2.

Bluewww:
The 0x1c00'0000 to 0x1c00'8000 is mapped to pri0 (32 KiB), 0x1c00'8000 to 0x1c01'0000 is mapped to pr1 (32 KiB), 0x1c01'0000 to 1c08'0000 (448 KiB) is mapped to CUTS[0]/.../bank_i/* to CUTS[3]/.../bank_i/* in an 4-byte(=word) interleaved manner, meaning the first word goes into bank 0, the next one into bank 1, the next one into bank 2 etc. Now furthemore each bank is split into 7 consecutive cuts (cut_0 to cut_6) where each cut is 16 KiB. The way the memory instances were named is not ideal.



In regards to my previous question there is also the boot-code repo which is what I am currently trying to extend.
If I'm not mistaken the boot_code.cde which I linked to in the above post is the binary of the boot_code.c found in this repo, is that correct?

Bluewww:
yes, though it is possible that the .cde is outdated since it has been a while we imported the last version

Looking at the linker script link.ld we can see that there are only two entries in the memory table: ROM and L2.
How is data actually relocated from flash to L2? As far as I remember the flash is not memory mapped or is it?

Bluewww:
boot_code.c contains a routine that configures the udma to load data from the flash over qspi into the L2. This should happen when you set the STANDALONE flag im the testbench.

I'm trying to modify the files in a way which allows me to load (preloaded) data from flash to defined addresses in L2, similar to how the (preloaded) hello example has to somehow be relocated.
Unfortunately I'm not allowed to modify boot_code.c so I'm guessing I have to modify the linker script link.ld and the main startup file crt0.S or add additional files.
Does anyone know if it is actually possible to load data from an arbitrary address in flash to an arbitrary address in L2 during boot phase?

Bluewww:
You would have to study boot_code.c to see if it provides that capability, but I don't think so. What is possible though is that you have a shim binary that gets loaded into L2 and executed, which contains code to load the rest of the data you want from any flash address to any l2 address.



Thank you,
LPLA
Reply


Messages In This Thread
RE: Data relocation when using LOAD_L2=STANDALONE - by bluewww - 06-09-2020, 02:35 PM

Forum Jump: