Lines Matching defs:code
135 to retrieve these in generic code. We choose ``arg2``, ``arg3`` and
136 ``arg4`` since the generic code uses ``arg1`` for stashing the SP manifest
150 On the Arm development platforms, BL1 code starts execution from the reset
181 a status code in the general purpose register ``X0/R0`` and call the
183 status code is one of:
230 of the status code
274 After performing platform setup, BL1 common code calls
276 required or to proceed with the normal boot process. If the platform code
357 BL2 generic code loads the images based on the list of loadable images
437 #. BL2 includes the reset code and the mailbox mechanism to differentiate
458 Boot ROM. Platform code can then program the jump address with
461 the PROGRAMMABLE_RESET_ADDRESS feature. Platform code can then
495 far as system register settings are concerned. Since BL1 code resides in ROM,
600 platform code in BL31:
608 these will be zero filled prior to invoking platform setup code.
615 used by the common BL31 code.
624 BL31 common and SPD initialization code depends on image and entrypoint
628 the platform code in BL31, or provided in a platform defined memory location
632 BL31 platform code before the caches are enabled.
636 code.
659 .. code:: c
669 ``bl31_params``. The code that allocates and populates these structures must set
677 the platform power management code with a Warm boot initialization
690 platform power management code is then invoked as required to initialize all
718 platform code in AArch32 EL3 Runtime Software:
745 Software platform code.
926 ignored and return the Unknown SMC Function Identifier result code ``0xFFFFFFFF``
961 in generic code.
963 An API implementation might have a dependency on platform code e.g. CPU_SUSPEND
1016 registered with the generic PSCI code to be supported.
1019 hooks to be registered with the generic PSCI code to be supported.
1074 .. code:: c
1090 .. code:: c
1143 processor flags at these points in the code.
1318 invocations of the reset handling code, this should be detected at runtime.
1405 the platform makefile. The generic CPU specific operations framework code exists
1441 The BL entrypoint code first invokes the ``plat_reset_handler()`` to allow
1558 Writing these errata involves lots of boilerplate and repetitive code. On
1618 correspond to particular addresses. TF-A code can refer to these symbols to
1654 Some of the linker symbols are mandatory as TF-A code relies on them to be
1660 used by any code but they help in understanding the bootloader images' memory
1668 - The BSS section must be zero-initialised before executing any C code.
1670 - The MMU setup code needs to know the extents of the coherent and read-only
1673 read-only memory region is divided between code and data.
1697 relocated from ROM to RAM before executing any C code.
1701 - ``__BL1_ROM_END__`` End address of BL1's ROM contents, covering its code
1717 that images don't overlap each other in an undesired way. As the code grows,
1733 For each bootloader image, the platform code must provide its start address
1744 sections must not overstep. The platform code must provide those.
2183 .. code:: c
2230 .. code:: c
2274 .. code:: c
2361 :ref:`Porting Guide`). Refer to the reference platform code for examples.
2363 Isolating code and read-only data on separate memory pages
2396 read-write permissions, whereas the code and read-only data below are configured
2400 contiguous to the code. Therefore, the end of the code section and the beginning
2402 mapped with the same memory attributes. As the code needs to be executable, this
2403 means that the read-only data stored on the same memory page as the code are
2407 TF provides the build flag ``SEPARATE_CODE_AND_RODATA`` to isolate the code and
2409 of the access permissions for the code and read-only data. In this case,
2410 platform code gets a finer-grained view of the image layout and can
2411 appropriately map the code region as executable and the read-only data as
2415 between the code and read-only data to ensure the segregation of the two. To
2417 code and exception vectors are now contiguous, like so:
2481 .. code:: c
2496 TF-A generic code publishes and subscribes to some events within. Platform
2508 .. code:: c
2518 .. code:: c
2532 Reclaiming the BL31 initialization code
2535 A significant amount of the code used for the initialization of BL31 is never
2537 footprint, the memory used for this code can be reclaimed after initialization
2540 The build option ``RECLAIM_INIT_CODE`` can be set to mark this boot time code
2629 To capture a timestamp in assembly code, the caller should use
2664 `PMF_CACHE_MAINT` is passed, then the PMF code will perform a
2671 PMF code structure
2682 assembly code.
2760 If ``ARM_ARCH_MAJOR == 8`` and ``ARM_ARCH_MINOR >= 3`` the code footprint of
2802 .. code:: make
2809 TF-A code is logically divided between the three boot loader stages mentioned
2810 in the previous sections. The code is also divided into the following
2811 categories (present as directories in the source code):
2813 - **Platform specific.** Choice of architecture specific code depends upon
2815 - **Common code.** This is platform and architecture agnostic code.
2816 - **Library code.** This code comprises of functionality commonly used by all
2817 other code. The PSCI implementation and other EL3 runtime frameworks reside
2824 Each boot loader stage uses code from one or more of the above mentioned
2825 categories. Based upon the above, the code layout looks like this:
2841 defined by the build system. This enables TF-A to compile certain code only