QUADSPI and OCTOSPI are different controllers.
You're reporting behaviour as described in the OCTOSPI App Note
21 = 2 MB
22 = 4 MB
23 = 8 MB
24 = 16 MB
DEVSIZE is a 5-bit field in OCTOSPI_DCR1, where 2^(DEVSIZE+1) is the size.
The initialization code takes the DeviceSize field and does the subtraction
So Init.DeviceSize = 24 defines a 16MB device
STM32Cube_FW_H7_V1.8.0\Drivers\STM32H7xx_HAL_Driver\Src\stm32h7xx_hal_ospi.c
HAL_OSPI_Init
/* Configure memory type, device size, chip select high time, clocked chip select high time, delay block bypass, free running clock, clock mode */
MODIFY_REG(hospi->Instance->DCR1,
(OCTOSPI_DCR1_MTYP | OCTOSPI_DCR1_DEVSIZE | OCTOSPI_DCR1_CSHT | OCTOSPI_DCR1_CKCSHT |
OCTOSPI_DCR1_DLYBYP | OCTOSPI_DCR1_FRCK | OCTOSPI_DCR1_CKMODE),
(hospi->Init.MemoryType | ((hospi->Init.DeviceSize - 1U) << OCTOSPI_DCR1_DEVSIZE_Pos) |
((hospi->Init.ChipSelectHighTime - 1U) << OCTOSPI_DCR1_CSHT_Pos) |
(hospi->Init.ClkChipSelectHighTime << OCTOSPI_DCR1_CKCSHT_Pos) |
hospi->Init.DelayBlockBypass | hospi->Init.ClockMode));
The memory devices themselves just tend to mask to the address bit counts they support, and the image you can read simply wraps within the address space.
In the STM32H74x/75x parts the last 32-bytes of the part have issues, I think there's an errata on that.
