(Help request) :: wierd CSV error in partition table, compiler fails

[code4sex]

IDF documentation says:

"Second stage bootloader binary image is loaded from flash starting at address 0x1000. If Secure Boot is in use then the first 4 kB sector of flash is used to store secure boot IV and digest of the bootloader image. Otherwise, this sector is unused."
// SRC: https://docs.espressif.com/projects/esp ... artup.html

I'm not using secure boot and I hence my desire to make use of the first 4KB section.

Partitions.csv has the following content:

Code: Select all

# Name, Type, SubType, Offset, Size, Flags
abc, data, 200, 0x0000, 0x1000, encrypted
nvs, data, nvs, 0x10000, 0x3000
otadata, data, ota, 0x20000, 0x2000
ota1, app, ota_1, 0x30000, 0xE0000

// Also, SDKconfig :: Partition table => Offset of partition table = 0x7000

Compiling under IDF 5.0 gets this stupid error: "CSV Error: First partition offset 0x0 overlaps end of partition table 0x8000"...

Wow! Can anyone figure out how a 0x1000 bytes partition starting at the beggining of flash @ 0x0000 can overlap "end of partition table 0x8000"??????

[chegewara]

https://docs.espressif.com/projects/esp ... ables.html
https://docs.espressif.com/projects/esp ... ble-offset

[code4sex]

chegewara,
thanks for the reply.

though the 1st link about partition table offset is not relevant to the subject, the 2nd one gives a clue:
"Partitions with blank offsets in the CSV file will start after the previous partition, or after the partition table in the case of the first partition."

Since my table resides @ 0x7000....0x8000 and my target "abc" partition is the first one and also has a zero offset then I get this "bingo".... sad...
looks like a clumsy hardcoded limitation for secure boot option.
okay, in such a case I'll have to go without partition table always keeping in mind that the 0x0000 ... 0x1000 range is my own data.

thx.

[adokitkat]

Hello. The offset is from the start of the flash memory, not from the bootloader end memory location. The bootloader occupies 0x0000 - 0x8000 space by default. The size of the partition table is 0x1000, hence by default it is in 0x8000 - 0x9000 space region. If the bootloader is smaller than 0x8000 (practically <=0x7000), you can set CONFIG_PARTITION_TABLE_OFFSET to e.g. 0x7000 and save 0x1000 bytes. Then everything shifts by 0x1000 and the first partition would be on offset 0x8000, not 0x9000.

[code4sex]

The bootloader occupies 0x0000 - 0x8000 space by default

Nopes! 2nd stage bootloader starts @ 0x1000.

IDF docs: "First stage bootloader in ROM loads second-stage bootloader image to RAM (IRAM & DRAM) from flash offset 0x1000".
src: https://docs.espressif.com/projects/esp ... artup.html

The first 4K is either occupied by secure boot stuff or is not used at all (refer to the initial post above).

[MicroController]

I would just consider 0x0000-0x8000 as 'reserved' for/by bootloader stuff.

hence my desire to make use of the first 4KB section.

But not just to save some 0.05% of flash space, right?

[code4sex]

But not just to save some 0.05% of flash space, right?

Sure not )
It's just a very nice and neat location (0x0000) for some tech purposes.

PS. 16M flash chip looks mighty at first. But then we bump into the 4M address space limit for DRAM (1-byte alignment) in mmap_* functions. IRAM mapping is times larger but, ouch! - 32-bit alignment is rather nasty drawback.
So not quite comfortable to run in the upper address space for many reasons.

[adokitkat]

I would just consider 0x0000-0x8000 as 'reserved' for/by bootloader stuff.

Sorry, this is what I meant.