Hi,HiddenSquid
Thank you for your question and detail information.
I know you are trying to use/modify the greenVIP demo to create a custom project. So, you can refer to the S32ZE_GreenVIP_1.x.1/doc/UG_S32ZE_GreenVIP.pdf for your application.
The Bootloader application has been integrated for both flavors of GreenVIP (SMU_LA|SMU_LAV) on the S32Z2 device. BootROM acts as a stage 1 bootloader, loading the primary application (SMU_LA|SMU_LAV). Following this, Bootloader takes control in stage 2 to load secondary applications (such as RTU_0 cores, RTU_1 cores, FLEXLLCE and others).
GreenVIP booting in Service Mode for SMU_LA on S32Z2 device as the following picture.
1.When the bootCFG pins are at the correct position, then the bootROM chip starts executing code from address 0x0, which is the address for external flash.
>>>The BootROM does not directly "fetch instructions and execute" from the 0x0 location of the external Flash. After power-on, the chip first runs the BootROM in its internal ROM. Based on the settings in BootCFG/switches, it selects the boot medium (such as QSPI/SD/eMMC, etc.), and then reads the boot header/IVT on the boot medium to determine the subsequent actions.
2.At the address 0x0 is the IVT (Image Vector Table), which is a part of the BLOB, with the purpose of pointing to the DCD, the boot table and the defining the boot core.
In the S32 Design Studio IVT tool there is the option to load the DCD and the Application bootloader. What exactly is the application bootloader and why do I need to provide the application bootloader with a RAM start and entry pointers? Is it just another name for the boot table or where or how can I configure the boot table?
>>>The Application Bootloader is the first-stage application image. For S32Z/E + greenVIP, it is usually the boot management program on the SMU/M33 side. The BootROM will move it to RAM and jump to its entry point.
The IVT tool also has an option of "Export BLOB" and Export "IVT Image". What is the difference or what does a BLOB contain?
>>>The function of IVT is to serve as a "pointer table", instructing the BootROM where to retrieve the DCD , the application bootloader and other image blocks, used for being parsed by BootROM.
BLOB is based on the IVT, the relevant images are physically assembled into a single writable overall image (which can be directly written to the boot medium) according to memory/alignment.
3.Then the DCD (Device Configuration Data) section runs, at 0x0000_0100, which is supposed to configure memory access and clocks for each core.
The S32 DS also has DCD tool, where I can add or edit the WRITE and CHECK commands. Do I understand correctly that it is for configuring peripheral registers? Can I actually initialize all registers with the DCD or how do I know which registers should be modified by the DCD and which can me modified during runtime?
Can or under which conditions should it be configured if I am trying to boot my own code?
>>>The role of DCD is a set of "early initialization scripts for peripheral/storage subsystems" executed during the BootROM stage. It's typical functions include initializing SRAM/DDR, setting QSPI parameters, certain necessary clocks/reset, etc. so that the subsequent application image can be correctly transferred and executed. DCD aims to minimize the hardware conditions that must be prepared "after BootROM and before the application image", higher-level peripheral initialization (such as drivers, complex timing modules) should be done within the application bootloader/application.
4.Then the Boot Table runs, located at 0x0010_0000, with the purpose of loading all the cores code in to RAM.
Please confirm this and as I already asked above, where can the boot table be configured?
>>>After the SMU is started by the BootROM, the Bootloader will load and/or start all the images for the RTUs, according to the Boot Table. You can refer to the 3.4 Compile the boot table of UG_S32ZE_GreenVIP.pdf to know more about the boot table configuration.
5.Additionally, as I understand, one of the large benefits of greenVIP is to have a multicore boot up sequence that is deterministic and can be or already is verified for Automotive grade safety. Please confirm or correct me if I'm wrong? Does that also mean the code for the M33 boot core should not or can not be modified?
>>>The GreenVIP (S32Z/E Vehicle Integration Platform) is intended to provide a functional software platform that allows customers to begin developing their applications on the S32Z/E family with minimal effort. It enables standalone development of each single application (vECU), and their integration. GreenVIP platform is aimed to demonstrate a proper use of S32Z/E benefitting from unique device features. For the application of M33 at the software level, the customer can make modifications. This is a software-level development application. The greenvip we provide is for customer reference and use, facilitating the customer's rapid development.
6.Furthermore, if each cores binaries are just copied from FLASH to RAM during the boot sequence, is the intended way to use greenVIP architecture for custom projects, to just flash my own code binaries to the appropriate FLASH address as appointed by greenVIP User Guide Table 11. Flash address for each partition? So for example if I want to run code on RTU_0_C0, I flash my binaries to address 0x0024_0000?
>>>For the GreenVIP application, if you flash your binaries to address 0x0024_0000, as you flash your RTU_0_C0.bin to this address, the SMU Bootloader will automatically copy it to the RAM. However, it can only be started if the entry/start address is the same.
Hope this information can help you.
BR
Joey