On 9/6/26 10:30 AM, Carlo Caione wrote: > Document the common Genio 510 and Genio 700 eMMC boot chain, > board-specific external firmware prerequisites, binman build invocation > and generated images. >
... > +DDR-loader handoff contract > +--------------------------- > + > +The DDR loader and U-Boot SPL have no parameter-block or firmware-call > +interface. Their contract consists of a fixed image layout, initialized DRAM > +and the execution state at the SPL entry point. Different DDR-loader > +implementations may be used as long as they satisfy this contract for the > +selected board. The BootROM loads the eMMC boot0 payload to > +``CONFIG_MTK_GENIO_BROM_LOAD_ADDR``:: > + > + offset 0 +----------------------+ > + | DDR loader | > + | | > + offset CONFIG_MTK_GENIO_DDR_LOADER_SIZE +----------------------+ > + | U-Boot SPL | > + | CONFIG_SPL_MAX_SIZE | > + image end +----------------------+ > + > +The DDR loader then performs the following handoff:: > + > + initialize and train DRAM > + > + copy: > + source = CONFIG_MTK_GENIO_BROM_LOAD_ADDR > + + CONFIG_MTK_GENIO_DDR_LOADER_SIZE > + destination = CONFIG_SPL_TEXT_BASE > + size = CONFIG_SPL_MAX_SIZE Do CONFIG_MTK_GENIO_DDR_LOADER_SIZE and CONFIG_SPL_MAX_SIZE need to be the same or just CONFIG_SPL_MAX_SIZE >= CONFIG_MTK_GENIO_DDR_LOADER_SIZE? > + > + enter: > + PC = CONFIG_SPL_TEXT_BASE > + state = AArch64 EL3h > + exceptions = masked > + x0..x7 = 0 > + > +The loader must copy the complete fixed-size SPL window, make the copied > image > +coherent, leave the MMU and caches disabled and enter SPL with no live > +dependency on its own runtime state. The MMU and caches must be disabled at > +entry, and all writes performed by the loader must be visible to the CPU. > +SPL does not consume DRAM geometry, a devicetree or boot-source information > +from registers. > + > +SPL obtains platform information from its embedded control devicetree and > +initializes the console, clocks, pinctrl, watchdog and eMMC through U-Boot > +drivers. > + > +There is no runtime negotiation of these values. A replacement DDR loader is > +compatible only if it initializes the selected board's DRAM and follows the > +same image-layout and entry-state contract. It may represent the > corresponding > +addresses, offsets and sizes using any implementation-specific mechanism; the > +contract does not require particular variable or build-symbol names. > + > +Firmware image prerequisites > +---------------------------- > + > +The following external binaries are required to assemble the complete > +firmware images: > + > +``ddr-loader.bin`` > + A MediaTek DDR loader built for the target board and configured to satisfy > + the handoff contract above. The input may be shorter than the configured > + loader region; binman pads it with zeroes to the offset reserved before s/zeroes/zeros/ > + SPL. > + > +``BL31`` > + The U-Boot build variable naming the Arm Trusted Firmware-A BL31 binary > + built for the MT8188 platform. It is loaded and entered at > + ``CONFIG_MTK_GENIO_BL31_LOAD_ADDR``. > + > +``TEE`` > + The U-Boot build variable naming the OP-TEE binary. A standard OP-TEE v1 > + ``tee.bin`` image is supported. Binman removes its header and derives the > + load and entry addresses from it when creating the FIT. > + > +These binaries must match the selected board, its memory layout and its > +firmware security policy. In particular, a common image layout does not make > +DDR-loader or OP-TEE binaries interchangeable between the two boards. BL31 > and > +OP-TEE must agree on the secure-memory layout. SPL passes OP-TEE's entry > point > +in the standard BL31 parameters; ``CONFIG_SPL_ATF_NO_PLATFORM_PARAM`` > suppresses > +only the separate platform parameter. Place > +``ddr-loader.bin`` in a directory which can be passed to binman with Strange line wrap here. > +``BINMAN_INDIRS``. > +
