Issue with using SPI flash for holding second boot slot

RE: Issue with using SPI flash for holding second boot slot

Hung Bui — Fri, 13 Sep 2024 13:17:24 GMT

Hi Maarten,

Thanks for the detailed investigation.
I think you found the right culprit. I haven't looked deep into this but from what I can see in the doc:
https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/scripts/partition_manager/partition_manager.html

If it's not QSPI NOR then you will have to use CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y. In your case you are using SPI so need to override the PM driver ?

RE: Issue with using SPI flash for holding second boot slot

Maarten "merethan" — Thu, 12 Sep 2024 19:31:10 GMT

Yep, boots. So I'd say this is a bug, that one can work around with CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK=y.

Make sure it is set to 'y' for both the application code and mcuboot. This is harder than it should be with sysbuild in between you and both these builds. Double-check it before testing.

There's further investigation pending on why a partition on an external but very standard JEDEC flash is somehow considered a partition without suitable driver available (really CONFIG_SPI_FLASH is all you need, and I had it enabled all this time for both appcode & mcuboot) but one can work around it by setting the before mentioned PM_OVERRIDE_EXTERNAL_DRIVER_CHECK.

Solved, I guess?

On to the next thing that blows up. But this crime scene is solved, for now at least. As for the exact motives of the perpetrator, some further investigation is needed.

RE: Issue with using SPI flash for holding second boot slot

Maarten "merethan" — Thu, 12 Sep 2024 19:13:50 GMT

/* The full list of partitions will be here cut down to partitions that
 * are defined over devices with drivers enabled in Kconfig.
 */

Uhoh.. Would this be really it..? Something going sideways there?

const struct flash_area default_flash_map[] = {
	FLASH_MAP_PM_LIST
};

const int flash_map_entries = ARRAY_SIZE(default_flash_map);
const struct flash_area *flash_map = default_flash_map;

Above snippet is from flash_map_partition_manager.c

I need go look into what CONFIG_PM_OVERRIDE_EXTERNAL_DRIVER_CHECK does. And possibly if there is a driver-thing for realsies broken, fix that. I do have CONFIG_SPI_NOR though, which should be all one needs for NOR flash adhering to JEDEC standards. So there likely ain't much of an external driver to fix. And I already verified I can read & write the flash from the serial shell.

Debugging software: A crime scene game where you are the victim, the perpetrator, the detective and the witness all yourself, in one person.

RE: Issue with using SPI flash for holding second boot slot

Maarten "merethan" — Thu, 12 Sep 2024 18:57:56 GMT

Few notes:

static inline uint32_t __flash_area_ids_for_slot(int img, int slot)
{
    static const int all_slots[] = {
        FOR_EACH_NONEMPTY_TERM(FIXED_PARTITION_ID, (,), ALL_AVAILABLE_SLOTS)
    };
    return all_slots[img * 2 + slot];
};

Snippet from sysflash.h

Function flash_area_id_from_multi_image_slot() which through some macro-indirection uses __flash_area_ids_for_slot() which uses some more macro-indirection creates a list & searches the partitions in the device tree. The partitions I have in the device tree are placeholders, as everything is to be overwritten by the partition manager (which parses pm-static.yml) somehow. How this mechanism is to work I not understood yet. So if this DT partition list is overwritten by the PM partition list by the time everything gets linked together, I not know.

It may be a clue though, if one does DT and the other does PM, for one reason or another.