On Thu, Jun 11, 2026 at 07:29:47AM +0000, Joita Mitra wrote: > Hi, > I am investigating a direct Linux boot flow where ARM Trusted Firmware (TF-A) > transfers control directly to Linux instead of booting U-Boot first. > Current flow: > > BL2 -> BL31 -> U-Boot -> Linux > > Target flow: > > BL2 -> BL31 -> Linux > > While studying the ARM64 boot flow in U-Boot, I examined: > > cmd/booti.c > boot/bootm.c > boot/bootm_os.c > > and observed that U-Boot performs significantly more work than simply jumping > to the kernel entry point. > To replicate the required functionality inside TF-A, I am trying to identify > which steps are essential. > Could you please clarify: > > 1. Which parts of the booti flow are mandatory before entering an ARM64 > Linux kernel? > 2. > If Linux is already loaded at its final execution address, which parts of > booti can safely be skipped? > 3. Are there any minimal examples showing the required state that Linux > expects when entered from firmware instead of U-Boot? > > My goal is to reproduce only the minimum required Linux preparation steps > inside TF-A. > At this stage, the most important unanswered question is not how to jump to > Linux, but what exact environment U-Boot creates that Linux depends on. > Any pointers to the relevant source files or functions would be greatly > appreciated. > Thank you.
What's required to boot the Linux kernel is documented by the linux kernel. See https://www.kernel.org/doc/html/latest/arch/arm64/booting.html for arm64 for example. -- Tom
signature.asc
Description: PGP signature
