Bootloader enable or disable to load a program from app_image

[Unike267]

Hi @stnolting

I have a quick question about if the bootloader should be disabled (INT_BOOTLOADER_EN => false) to load a prebuild program located in the core as a neorv32_application_image.vhd .

I mean, if you don't disable the bootloader it will load by default from neorv32_bootloader_image.vhd and according to the datasheet there will be the following options:

• Autoboot from SPI flash (4.5.4). And if it is aborted, a console (4.5.3) will appear with the options:
• Help (h)
• Restart (r)
• Upload exe.bin via UART to IMEM (u)
• Store to SPI flash (s)
• Load exe from SPI flash (l)
• Boot from flash via XIP (x)
• Start the application, which is currently stored in the instruction memory (IMEM) (s)

Okey, my question is if there is a way to start the program located in the neorv32_application_image.vhd through the bootloader (load the IMEM content neorv32_application_image.vhd via bootloader) or if is necessary to disable the bootloader and start the program directly through content of the neorv32_application_image.vhd that it is in the IMEM since the design is synthesized (whether the bootloader is disabled or not).

The point is that until now I'm disabling the bootloader to load neorv32_application_image.vhd directly and I don't know if I'm right. 😅

Cheers!

---

/cc @umarcor

[Unike267]

Let me explain better.

According to the datasheet:

e: Start the application, which is currently stored in the instruction memory (IMEM)

Maybe I'm wrong but when the design is synthesized and the bootloader is enable, Is the content of the neorv32_application_image.vhd loaded in the IMEM?

If this is the case why does the e option not start it?

I tried to start with e a program contained in the neorv32_application_image.vhd (that I suppose that after the synthesis it is loaded in the IMEM) and it doesn't work.

As shown in the following image:

I think in these three possibilities:

• When the bootloader is enable the neorv32_application_image.vhd doesn't load in the IMEM. Therefore, to load a program from app_image the bootloader must be disable.
• When the bootloader is enable the neorv32_application_image.vhd is load in the IMEM. Therefore, according to the datasheet the e option should work and the bootloader could be enable.
• The eoption only works for preupload exe.bin programs. Therefore, the datasheet description is a bit confusing and to load a program from app_image the bootloader must be disable.

Could you please clarify which one is correct?

Thanks! 😃

[stnolting]

Hey @Unike267!

Okey, my question is if there is a way to start the program located in the neorv32_application_image.vhd through the bootloader

Unfortunately, this is not possible.

• When the bootloader is enable the neorv32_application_image.vhd doesn't load in the IMEM. Therefore, to load a program from app_image the bootloader must be disable.

✔️

• When the bootloader is enable the neorv32_application_image.vhd is load in the IMEM. Therefore, according to the datasheet the e option should work and the bootloader could be enable.

❌

• The eoption only works for preupload exe.bin programs. Therefore, the datasheet description is a bit confusing and to load a program from app_image the bootloader must be disable.

❌

The INT_BOOTLOADER_EN generic does not just enable the bootloader - there is some more stuff going on behind the scenes. 😉

When enabled, the bootloader ROM including the default bootloader code is implemented (= added to the processor) and the CPU reset vector is changed so that the core starts executing the bootloader when coming out of reset. Furthermore, the IMEM is implemented as empty RAM - so it is not initialized by neorv32_application_image.vhd during synthesis.

If the bootloader is disabled, the IMEM gets implemented as pre-initialized ROM (using neorv32_application_image.vhd).

Maybe I'm wrong but when the design is synthesized and the bootloader is enable, Is the content of the neorv32_application_image.vhd loaded in the IMEM?

So, no, the RAM is blank. This feature is intended for FPGAs (and ASICs) that do not support blockRAM initialization (like the large SRAM blocks in Lattice ice40 FPGAs).

If the IMEM would be implemented as pre-initialized RAM then the image could be corrupted during runtime (imagine some rogue pointer writing to IMEM), which would require a re-upload of the original program. Hence, the bootloader upload would be required anyway.

[Unike267]

Okey!

the IMEM is implemented as empty RAM - so it is not initialized by neorv32_application_image.vhd during synthesis.

That was my main doubt!

So, no, the RAM is blank. This feature is intended for FPGAs (and ASICs) that do not support blockRAM initialization (like the large SRAM blocks in Lattice ice40 FPGAs)

Got it!

If the IMEM would be implemented as pre-initialized RAM then the image could be corrupted during runtime (imagine some rogue pointer writing to IMEM), which would require a re-upload of the original program.

😱 Definitely that would be bad.

Thank you very much for clarifying this issue! 😄

[umarcor]

For completeness:

neorv32/rtl/core/neorv32_top.vhd

Line 269 in bf246fe

constant imem_as_rom_c : boolean := not INT_BOOTLOADER_EN;

neorv32/rtl/core/neorv32_top.vhd

Lines 807 to 812 in bf246fe

	if MEM_INT_IMEM_EN generate
	neorv32_int_imem_inst: entity neorv32.neorv32_imem
	generic map (
	IMEM_SIZE => imem_size_c,
	IMEM_AS_IROM => imem_as_rom_c
	)

neorv32/rtl/core/neorv32_imem.entity.vhd

Lines 41 to 45 in bf246fe

	entity neorv32_imem is
	generic (
	IMEM_SIZE : natural; -- processor-internal instruction memory size in bytes, has to be a power of 2
	IMEM_AS_IROM : boolean -- implement IMEM as pre-initialized read-only memory?
	);

neorv32/rtl/core/mem/neorv32_imem.default.vhd

Lines 59 to 66 in bf246fe

	-- ROM - initialized with executable code --
	constant mem_rom_c : mem32_t(0 to IMEM_SIZE/4-1) := mem32_init_f(application_init_image, IMEM_SIZE/4);
	-- The memory (RAM) is built from 4 individual byte-wide memories because some synthesis
	-- tools have issues inferring 32-bit memories that provide dedicated byte-enable signals
	-- and/or with multi-dimensional arrays. [NOTE] Read-during-write behavior is irrelevant
	-- as read and write accesses are mutually exclusive.
	signal mem_ram_b0, mem_ram_b1, mem_ram_b2, mem_ram_b3 : mem8_t(0 to IMEM_SIZE/4-1);

neorv32/rtl/core/mem/neorv32_imem.default.vhd

Lines 83 to 124 in bf246fe

	imem_rom:
	if (IMEM_AS_IROM = true) generate
	mem_access: process(clk_i)
	begin
	if rising_edge(clk_i) then -- no reset to infer block RAM
	rdata <= mem_rom_c(to_integer(unsigned(addr)));
	end if;
	end process mem_access;
	end generate;
	-- word aligned access --
	addr <= bus_req_i.addr(index_size_f(IMEM_SIZE/4)+1 downto 2);
	-- Implement IMEM as non-initialized RAM --------------------------------------------------
	-- -------------------------------------------------------------------------------------------
	imem_ram:
	if (IMEM_AS_IROM = false) generate
	mem_access: process(clk_i)
	begin
	if rising_edge(clk_i) then -- no reset to infer block RAM
	if (bus_req_i.stb = '1') and (bus_req_i.rw = '1') then
	if (bus_req_i.ben(0) = '1') then -- byte 0
	mem_ram_b0(to_integer(unsigned(addr))) <= bus_req_i.data(07 downto 00);
	end if;
	if (bus_req_i.ben(1) = '1') then -- byte 1
	mem_ram_b1(to_integer(unsigned(addr))) <= bus_req_i.data(15 downto 08);
	end if;
	if (bus_req_i.ben(2) = '1') then -- byte 2
	mem_ram_b2(to_integer(unsigned(addr))) <= bus_req_i.data(23 downto 16);
	end if;
	if (bus_req_i.ben(3) = '1') then -- byte 3
	mem_ram_b3(to_integer(unsigned(addr))) <= bus_req_i.data(31 downto 24);
	end if;
	end if;
	rdata(07 downto 00) <= mem_ram_b0(to_integer(unsigned(addr)));
	rdata(15 downto 08) <= mem_ram_b1(to_integer(unsigned(addr)));
	rdata(23 downto 16) <= mem_ram_b2(to_integer(unsigned(addr)));
	rdata(31 downto 24) <= mem_ram_b3(to_integer(unsigned(addr)));
	end if;
	end process mem_access;
	end generate;

[umarcor]

@stnolting would it be feasible to add a MEM_INIT_IMEM_AS_ROM generic, which defaults to false, together with changing https://github.com/stnolting/neorv32/blob/main/rtl/core/neorv32_top.vhd#L269 to MEM_INIT_IMEM_AS_ROM or not INT_BOOTLOADER_EN? So, to optionally have both IMEM and BOOT inferred as ROMs at the same time. Naturally, that would not make much sense with the default bootloader, because most of the features are meant to interact with IMEM. However, it would be useful with other bootloaders that interact with e.g. the SPI or some other peripheral before transferring execution to IMEM.

[stnolting]

Sure, that would be an easy update. But (from my very limited perspective 😅) I do not see any actual use case for this.

However, it would be useful with other bootloaders that interact with e.g. the SPI or some other peripheral before transferring execution to IMEM.

That's true. But then the bootloader cannot change the content of the IMEM anymore. All the (customized) bootloader could do is initializing things.

Of course one could come up with some scenarios for this. For example, put some persistent emulator code into IMEM and use the bootloader to initialize some external memory the emulator can consume. But then, why not combine the functionality of the bootloader + emulator into one image that is put into IMEM?

Maybe I'm just not able to think outside the box and this feature would be very useful for certain applications. 🤔

[umarcor]

You are right in the sense that all the functionality could be put into IMEM. We were thinking about using both just for separation of concerns. In the final application, data will be put into shared memory through a hardware component which is not part of the NEORV32 SoC, but which is configured on the same FPGA device. Then, a ping-pong scheme will be used for the NEORV32 SoC to process data and produce results. Therefore, having two ROMs allows us to more easily keep the actual application code separated from the external (say testbench) code that emulates the yet-to-be integrated data gathering hardware component.
Since the infrastructure to boot from BOOT and then transfer execution to IMEM exists in NEORV32 already, we thought it would be easier to use it. Nevertheless, we can assume/accept that the purpose of the bootloader is to just transfer/load software and run our tests using IMEM only.

[stnolting]

In the standard configuration, the bootloader ROM is limited to a maximum size of 8kB (which already restricts many use cases). I understand your setup, and I would also prefer to build on existing setups/configurations. However, in your case I would just add 1 or 2 (or even more) external memories containing all the individual program parts and stick to the non-bootloader boot configuration. 🙈