We are interested in developing Board Support Package and Bootloader code for SOCs based on ARMv8 Architecture (A57/A53). Can someone please suggest is Juno Board a good option for it?
We are interested in writing the BSP code for Memory Controller, UART,GIC,CCI etc. In a nutshell we want to replace the Bootloader coming with Juno Board deliverable with our own developed Bootloader code except the Boot ROM code. Is it possible to do it on Juno Board?
Hello,
Regarding the bootloader code: The Juno deliverables use the ARM Trusted Firmware stack, which is an open-source project hosted on GitHub. You can quite easily replace this with your own bootloader code, however it is highly recommended that you do not fully replace the ARM Trusted Firmware.
In addition to the application processors (Cortex-A53 and Cortex-A57), the Juno SoC includes a Cortex-M3 acting as the System Control Processor (SCP). This SCP is responsible for runtime thermal regulation, power management, reset control, etc. A runtime firmware image is transferred across to the SCP by the primary application processor during the boot sequence; while the ARM Trusted Firmware bootloader stack is open-source, the SCP runtime firmware is only distributed as a binary image.
With this in mind, we recommend taking control after the SCP runtime firmware image has been transferred. We have published a tutorial detailing how to safely take control of the system in EL2, after all platform-specific initialisation has been done for you. Doing this you are effectively replacing the UEFI bootloader stage, which hopefully is similar to what you want?
Regarding the BSP code: You can very easily write drivers for any of the ARM IP components included in the SoC, for example the UARTs are PL011 devices, so you would need to consult the PL011 UART Technical Reference Manual (TRM) on the ARM Infocenter. The same applies for the NIC-400, CCI-400, GIC-400, etc. You can consult the Juno SoC TRM for more information.
I hope this helps,
Ash.
Thanks Ash for such great information.
Can you please also let us know at what stage of bootloader the Memory Controller is initialized and is the code open for it as well?
Thanks & Regards,
Nitin
No problem.
I can confirm that the memory controller is initialised by the SCP runtime firmware binary image that I mentioned in my previous post.
The issue here is that both open-source and closed-source components are interacting during the boot process, so I guess it depends on how "early" you want to take control of the system. You could use the ARM Trusted Firmware stack as a reference for your own solution, as it contains all of the platform-specific initialisation that is performed by the primary application processor, but you would still need to transfer the runtime firmware binary image across to the SCP. Without doing this, you will not have access to a number of key system peripherals, including DDR, and the application processors will not be thermally protected.
I would still recommend taking control after Trusted Firmware if possible, such as by replacing the UEFI bootloader stage with your own solution.
If you wish to discuss this further, please send an email to support@arm.com
Regards,
Thanks Ash again for the update.
Suppose, we have a requirement where we want to change the parameters like DDR Timings, refresh settings, active bank etc in the kernel after the boot. So, is it possible to achieve in the Juno board after the SCP firmware has been loaded by the BL?
At least in the case of DDR timings, I'm afraid these are not modifiable. I'm not sure what you mean by "refresh settings, active bank etc in the kernel", but this may be something we can assist you with further as a proper support case.
If you'd like to do this, please send an email to support@arm.com