Boot Linux FIT image from SPL
Hi,
I was wondering whether it's possible to boot a Linux FIT image (kernel zImage, DTB, initramfs) straight from SPL? Specifically, I'm trying to reduce the boot time when booting into a tiny Linux with RAM disk over USB SDP (i.MX6ULL). This works fine with the chain ROM -> SPL -> u-boot proper -> Linux. I have given it a try to boot the FIT image straight from SPL, but I'm getting a few (debug-level) errors:
U-Boot SPL 2021.10-00003-gc254f7c98d-dirty (Dec 27 2021 - 20:15:09 +0100) Trying to boot from USB SDP SDP: initialize... SDP: handle requests... Downloading file of size 2440036 to 0x81000000... done Jumping to header at 0x81000000 Header Tag is not an IMX image Found header at 0x81000000 fit read sector 0, sectors=2440036, dst=88302888, count=2440036, size=0x253b64 cannot find property 'firmware': -1 kernel: 'kernel-1' Embedded data: dst=82000000, size=13caf0 Image OS is Linux fdt: 'fdt-imx6ull-myir-mys-6ulx-eval.dtb' Embedded data: dst=8213caf0, size=64f7 cannot find property 'loadables': -1
The "loadables" config property seems to be specific to the u-boot proper FIT image. I have consulted the falcon-mode readme, but it doesn't mention FIT images which leads me to believe that this is not an intended use case?
Best regards, Sven
Hi Sven,
On Tue, Dec 28, 2021 at 8:57 AM Sven Schwermer sven@svenschwermer.de wrote:
Hi,
I was wondering whether it's possible to boot a Linux FIT image (kernel zImage, DTB, initramfs) straight from SPL? Specifically, I'm trying to reduce the boot time when booting into a tiny Linux with RAM disk over USB SDP (i.MX6ULL). This works fine with the chain ROM -> SPL -> u-boot proper -> Linux. I have given it a try to boot the FIT image straight from SPL, but I'm getting a few (debug-level) errors:
U-Boot SPL 2021.10-00003-gc254f7c98d-dirty (Dec 27 2021 - 20:15:09 +0100) Trying to boot from USB SDP SDP: initialize... SDP: handle requests... Downloading file of size 2440036 to 0x81000000... done Jumping to header at 0x81000000 Header Tag is not an IMX image Found header at 0x81000000 fit read sector 0, sectors=2440036, dst=88302888, count=2440036, size=0x253b64 cannot find property 'firmware': -1 kernel: 'kernel-1' Embedded data: dst=82000000, size=13caf0 Image OS is Linux fdt: 'fdt-imx6ull-myir-mys-6ulx-eval.dtb' Embedded data: dst=8213caf0, size=64f7 cannot find property 'loadables': -1
The "loadables" config property seems to be specific to the u-boot proper FIT image. I have consulted the falcon-mode readme, but it doesn't mention FIT images which leads me to believe that this is not an intended use case?
People load FIT images via Falcon mode on Layerscape: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/fsl-la...
Hope this helps.
Regards,
Fabio Estevam
On Tue, Dec 28, 2021 at 9:13 AM Fabio Estevam festevam@gmail.com wrote:
People load FIT images via Falcon mode on Layerscape: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/fsl-la...
There was a typo in the URL above. Correct one is:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/fsl-la...
Hi Fabio,
Thank you for the hint. That's a _very_ useful document. In the meantime, I have been able to boot my Linux FIT image straight from SPL on my i.MX6ULL platform.
I have, however, noticed that Linux boots much faster when launched from u-boot proper compared to SPL. Time to (initramfs) init is 1.2s vs. 5s. That is with identical FIT images (kernel, device tree, initramfs, kernel command line). I ruled out differing core clock rates (both run at 396MHz), caches (caches seem to be disabled before handing over to Linux) and differing load addresses (might cause additional relocations, copies).
What other setup could u-boot proper do that would make Linux boot faster that I haven't thought about?
Best regards, Sven
On 12/28/21 13:15, Fabio Estevam wrote:
On Tue, Dec 28, 2021 at 9:13 AM Fabio Estevam festevam@gmail.com wrote:
People load FIT images via Falcon mode on Layerscape: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/fsl-la...
There was a typo in the URL above. Correct one is:
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/cpu/armv8/fsl-la...
Hi Sven,
On Thu, Dec 30, 2021 at 6:22 PM Sven Schwermer sven@svenschwermer.de wrote:
Hi Fabio,
Thank you for the hint. That's a _very_ useful document. In the meantime, I have been able to boot my Linux FIT image straight from SPL on my i.MX6ULL platform.
Glad you got it to work. It would be nice if you could submit a patch adding a document adapted for i.MX6ULL.
I have, however, noticed that Linux boots much faster when launched from u-boot proper compared to SPL. Time to (initramfs) init is 1.2s vs. 5s. That is with identical FIT images (kernel, device tree, initramfs, kernel command line). I ruled out differing core clock rates (both run at 396MHz), caches (caches seem to be disabled before handing over to Linux) and differing load addresses (might cause additional relocations, copies).
What other setup could u-boot proper do that would make Linux boot faster that I haven't thought about?
Looking at your previous log, I see that you boot from serial download mode.
I recall seeing such a slow boot behavior when booting from SDP and this was fixed by the following commit:
commit c5437e5b8aff9c952ebaab9be7670439c141e4e7 Author: Ye Li ye.li@nxp.com Date: Mon May 14 09:44:29 2018 -0300
imx: Enable ACTLR.SMP bit for all i.MX cortex-a7 platforms
According to the Cortex-A7 TRM, for ACTLR.SMP bit "You must ensure this bit is set to 1 before the caches and MMU are enabled, or any cache and TLB maintenance operations are performed". ROM sets this bit in normal boot flow, but when in serial download mode, it is not set. Here we add it in u-boot as a common flow for all i.MX cortex-a7 platforms, including mx7d, mx6ul/ull and mx7ulp.
Signed-off-by: Ye Li ye.li@nxp.com [fabio: adapted to U-Boot mainline codebase and make checkpatch happy] Signed-off-by: Fabio Estevam fabio.estevam@nxp.com
Such slow boot is not observed if you boot from other media, such as eMMC, for example.
You could try performing the setting of ACTLR.SMP bit inside SPL. Currently, it is done only inside U-Boot proper.
Hope this helps.
Hi Fabio,
Glad you got it to work. It would be nice if you could submit a patch adding a document adapted for i.MX6ULL.
I'll need to sort my notes and go through my changes. I'll try to submit relevant patches.
You could try performing the setting of ACTLR.SMP bit inside SPL. Currently, it is done only inside U-Boot proper.
Hope this helps.
This does indeed make all the difference. Thank you very much for the tip! I'll send a patch soon.
Best regards, Sven
Hi Fabio,
You could try performing the setting of ACTLR.SMP bit inside SPL. Currently, it is done only inside U-Boot proper.
I have one more question about this: Is it save to just enable D/I caches (enable_caches) in SPL for all of mach-imx or will this have unforeseen side effects? In that case, I can just make enable_ca7_smp non-static and call that for all of mach-imx in SPL. In either case, what would be the proper spot for this? I'm thinking somewhere in SPL's board_init_r or spl_init/spl_common_init?
Best regards, Sven
Hi Sven,
On Fri, Dec 31, 2021 at 11:38 AM Sven Schwermer sven@svenschwermer.de wrote:
I have one more question about this: Is it save to just enable D/I caches (enable_caches) in SPL for all of mach-imx or will this have unforeseen side effects? In that case, I can just make enable_ca7_smp non-static and call that for all of mach-imx in SPL. In either case, what would be the proper spot for this? I'm thinking somewhere in SPL's board_init_r or spl_init/spl_common_init?
To be on the safe side, I would only call enable_ca7_smp() for SPL.
What about calling it from arch_cpu_init() in arch/arm/mach-imx/mx6/soc.c?
Regards,
Fabio Estevam
Best regards, Sven
participants (2)
-
Fabio Estevam -
Sven Schwermer