mcuboot: enable use on RISC-V with ram load mode

[maass-hamburg]

this enables the use of mcuboot on riscv with ram load mode.

for that a function to get the flash_img_get_upload_slot() is needed.

Fixes: #83941

[nordicjm]

Changes look OK, one nit.

[maass-hamburg]

We have some problems in ci, now that CONFIG_ROM_START_OFFSET isn't ignored anymore on RISCV platforms and actually used.

[d3zd3z]

The CI issues will have to be addressed.

[nordicjm]

why is CONFIG_ROM_START_OFFSET > 0 needed here but only for risc?

[maass-hamburg]

• I don't wanted to change it for the other archs
• there are some riscv soc, that don't work, so the part to add a offset is only used, if that offset is needed

[nordicjm]

If the others are failing, they should be fixed, this is adding a hack (would suggest getting build logs from CI then pinging the maintainers of those platforms since they would be broken)

[maass-hamburg]

the problem was mainly opentitan, which needs to put a other rom header in front. maybe @snematbakhsh can help

[maass-hamburg]

@nordicjm the opentitan one is not compatible with having a CONFIG_ROM_START_OFFSET, because it has to put something soc specific in front in the linker.

[nordicjm]

@tkng-rivos @snematbakhsh as submitters of that board, can you take a look/fix?

[snematbakhsh]

@maass-hamburg Once we turn on CONFIG_ROM_START_OFFSET for risc-v, I think we need to account for the manifest (similar to what is done here for another SOC). So I think we want to change soc/lowrisc/opentitan/Kconfig.defconfig as follows:

# The OpenTitan SoC requires a manifest in front of the
# application binary.
config ROM_START_OFFSET
	default 0x404

.. and subsequently we no longer need the "GREATER 0" special case.

Why 0x404 and not 0x400 for 1024 byte manifest, you ask? It's this bug, I will take care of it after you land your PR (so just use 0x404).

[maass-hamburg]

@snematbakhsh the CONFIG_ROM_START_OFFSET will result in everything before the offset being filled with zeros. But you need to write the start address in the manifest see here:

zephyr/soc/lowrisc/opentitan/rom_header.S

Line 25 in 90ff9c0

.word(__start - __rom_header)

We would also have to remove the part for creating the manifest, because it would conflict with the CONFIG_ROM_START_OFFSET code.

[snematbakhsh]

@maass-hamburg

the CONFIG_ROM_START_OFFSET will result in everything before the offset being filled with zeros.

It seems to work fine on my side, did I miss something?
Applying patches 1d65a59 (to generate .bin) and 387478c (my proposed change as previously discussed).

$ west build -b opentitan_earlgrey samples/hello_world/
$ hexdump build/zephyr/zephyr.bin | more
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000380 0000 0000 0404 0000 0000 0000 0000 0000
0000390 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 0000 0000 1197 f000 8193 4541 0297 0000

I think this works because the SORT_KEY for the OpenTitan manifest ("000...") precedes the SORT_KEY for rom_start_offset.ld ("0x0").

[maass-hamburg]

seems like its working

[maass-hamburg]

@tkng-rivos @snematbakhsh ping ??

[nordicjm]

minor nit.

[maass-hamburg]

fixed nit.

[cfriedt]

This seems completely unrelated to the PR. Please revert.

[maass-hamburg]

@cfriedt these tests are now failing, and I don't know why. You may want to take a look.

Fixed

[maass-hamburg]

qemu_riscv64 and qemu_riscv32 do not support a different a ROM offset. The start has to be at 0x80000000. It is not using the Entry point address from the elf file. It might be possible to set a start address via command line/options, but that's not done in this PR.