Linux Fast Boot on i.MX6 Sabresd Board

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Linux Fast Boot on i.MX6 Sabresd Board

Linux Fast Boot on i.MX6 Sabresd Board

The original implementation is from Frias Renato for Sabreauto board.

How to define the booting time?

The booting time we defined here is from the board be powered up to the main application working and main application be showed directly to the end user, for example: for the media play purpose board, the booting time count to the first video frame be shown on the screen.

For minimizing the booting time, some methods be tried.

  1. Optimizing for performance.
  2. Remove unnecessary modules at boot time.
  3. Start main application at the first time after the kernel be boot up.

Optimizing for performance:

U-Boot:

  1:Enable MMU and L2-Cache.

  2:Optimizing memset and memcpy.

  3:Implementation of SDMA, accelerate copying data from NOR flash to memory.

  4:Implementation of uSDHC’s ADMA, improve performance for SD card read.

Kernel:

  1:Optimizing _memcpy_fromio function at  arch/arm/kernel/io.c

  • Remove unnecessary modules:

U-Boot:

  1: Disable uart output at u-boot procedure and add quiet parameter to Kernel boot.

  2: Remove boot up delay at u-boot.

  3: Disable I2C, SPI, SPLASH_SCREEN at u-boot.

Kernel:

Below removing unnecessary modules just for Sabresd board boot up through SD card and MIPI camera overlay on LVDS screen application, for other special board and special board usage application please don’t use below directly.

  1: Modify arch/arm/mach-mx6/board-mx6q_sabresd.c just keep necessary module initialization at  mx6_sabresd_board_init: iomux configuration, uart0, voda, ipu, ldb, v4l2, mipi-csi, i2c1, uSDHC1, pwm0, dvfs, mipi camera clock.

  2: Update Linux kernel configuration file. Try to just keep necessary module and configuration to keep minim size. Build necessary modules from external to Kernel itself. Create uImage from Image instead of zImage to reduce Kernel self extraction time. Use ext4 file system on SD card to accelerate rootfs mounting.

   Notice: Kernel configuration remove NETWORK support, it includes Unix Domain Socket, the udev mechanism need it, so this kernel configuration can't support rootfs udev dynamic /dev/ nodes and all /dev/ nodes must be created before boot up at rootfs.

  • Start main application at the first time after the kernel boots up.

As normal boot up procedure, the init process will handle sysinit script firstly, this script will do some initialization and preparation for most of the user process, But this script normally will be executed for about 1~5 seconds, so now try do main application before the sysinit, while the necessary preparation of main application will be handle by this application internally.

See below example for MIPI camera overly on LVDS screen:

/etc/inittab

::once:/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -1 -d 0 -fg -fr 30

::once:/etc/rc.d/rcS

::once:/sbin/getty -L ttymxc0 115200 vt100 # GENERIC_SERIAL

  • Test result of fast boot on Sabresd board for MIPI camera overly on LVDS screen:

    The main application be executed from the board be powered up is about 958ms.

   Running Bootloader

[0.356417 0.356417] [ 0.046637] _regulator_get: get() with no identifier

[0.958425 0.602008] starting pid 21, tty '': '/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -^@

[0.969609 0.011184] starting pid 22, tty '': '/etc/rc.d/rcS'

[0.973368 0.003759] g_display_width = 1024, g_display_height = 768

[0.977540 0.004172] g_display_top = 0, g_display_left = 0

[0.980927 0.003387] starting pid 23, tty '': '/sbin/getty -L ttymxc0 115200 vt100 '

[1.048454 0.067527] Mounting /proc and /sys

[1.089526 0.041072] Setting the hostname to freescale

[1.116635 0.027109] Mounting filesystems

[1.527320 0.410685] sensor chip is ov5640_mipi_camera

[1.530627 0.003307] sensor frame size is 640x480

[1.533482 0.002855] sensor frame format is UYVY

[1.640221 0.106739] frame_rate is 30

[1.642249 0.002028]

[1.642270 0.000021] frame buffer width 0, height 0, bytesperline 0

[1.989728 0.347458]

[1.990761 0.001033] arm-none-linux-gnueabi-gcc (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease)

[2.001161 0.010400] root filesystem built on Tue, 11 Sep 2012 11:43:24 +0800

[2.006249 0.005088] Freescale Semiconductor, Inc.

[2.009394 0.003145]

[2.009531 0.000137] freescale login:

Please see below fast boot video.

I also attached sample code for U-boot and kernel for your reference. Patch code based on L3.0.35_12.09.01_GA.

Labels (2)
Attachments
Comments

Thank you for that insightful guide.

Can you give some more information about the points

"Implementation of SDMA, accelerate copying data from NOR flash to memory" and "Implementation of uSDHC’s ADMA, improve performance for SD card read"? Where can i find information to be able to implement this?

Where did you store the different parts of the system (bootloader, kernel, rootfs)?

Thank you in adavance.

Hi Ican Treed:

I upload the patch code of u-boot and kernel for fast boot. You can reference it, any question feel free to tell me.

Did you evaluated the option of using SystemD for the boot? it should give you similar result in performance boost and is very flexible.

Is is possible to faster the kernel's image uncompression process?

Usually LZO is the better trade of between uncompression speed and storage read performance.

I don't try and listen to the SystemD for the boot, could you describe it simply?

Do you happen to have a breakdown of where the time was spent in bootup before your optimisations and where afterwards? It would be interesting to see where you gain the biggest advantage.

Specifically for the u-boot optimisation it would be interesting to know what the load speed is before and after the optimisations?

For 12.0.9 GA code. with serial output, the U-boot boot up time without optimization is about 1.7s. while with optimization is about 0.5s, the optimization composed of screen splash: 200ms,  I2C init and PFUSE:730ms; Kernel load: 170ms .

Enable MMU and L2 cache will decrease about 1.x s u-boot check and load uImage  time.

Can you share your code changes for the optimization?

The optimization of U-Boot has been attached at the document of u-boot.tar.bz2.

Thanks!

Can you please post the original implementation, for SabreAI board? Thanks!

I'm very interested on how you enable the video camera on i.MX6 SabreAI board. Could you share some info about it? I like to know your kernel config and what camera through which interface to the SabreAI board. Thanks!

I have not touched SabreAI board, on SabreSD board which is my fast boot platform, camera interface is CSI serial. you can find kernel config of SabreSD for fastboot in the attachment kernel.tar.bz2.

Thanks!

The AI board has 1 MIPI CSI, 1 Camera LVDS-in and 2 video in. I find the OV5640 driver in my BSP but I didn't find a matching camera for the CSI port. I also  find some OV5642 camera sensor without the proper connector. Could you send me the detail info for the camers's manufacture and model? Thanks

SabreSD has one serial MIPI and one parallel MIPI interface, both those  MIPI interfaces have the same physical interfaces, my camera for fast boot is OV5640DSL-A00A that has serial MIPI interface, and our BSP (1209) has this camera driver. Thanks!

hello,

   When I transplant your sourcecode in i.MX53 platform and compile it,

   There is an error:

   "undefined reference to 'v7_dma_clean_range' ",plz help me.

    Can you give me the address of the whole source code of bootloader?

    and whether the patch supports i.Mx53?

This sample patch code dose not support i.Mx53,

For the call v7_dma_clean_range I think i.Mx53 should has the correspond code.

Below is u-boot code in i.Mx6x

cpu/arm_cortexa8/start.S

/*

*      v7_dma_clean_range(start,end)

*      - start   - virtual start address of region

*      - end     - virtual end address of region

*/

        .align 5

.global v7_dma_clean_range

v7_dma_clean_range:

        dcache_line_size r2, r3

        sub     r3, r2, #1

        bic     r0, r0, r3

#ifdef CONFIG_ARM_ERRATA_764369

        ALT_SMP(W(dsb))

        ALT_UP(W(nop))

#endif

1:

        mcr     p15, 0, r0, c7, c10, 1          @ clean D / U line

        add     r0, r0, r2

        cmp     r0, r1

        blo     1b

        dsb

        mov     pc, lr

If you follow my patch in the kernel configuration, the kernel should disable network option, that will disable udev service, so you need create those dev nodes on the rootfs manually.

Please see my rootfs video device node:

ls dev/video* -l

lrwxrwxrwx 1 root root     6 2013-03-19 09:14 dev/video -> video0

crw-rw---- 1 root root 81, 0 2012-10-08 18:08 dev/video0

crw-rw---- 1 root root 81, 1 1970-01-01 08:00 dev/video16

crw-rw---- 1 root root 81, 2 1970-01-01 08:00 dev/video17

Hi:

From your message

starting pid 21, tty '': '/unit_tests/mxc_v4l2_overlay.out -d /dev/video16 -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -fr 3

It show mxc_v4l2_overlay had been started.

/etc/rc.d/rcS may not be needed run for this demo.




Step by step procedure to patch and build a fast boot system is found here.

Leo

Dear Haidong Zheng,

I have a problem to perform the Camera module in the patched kernel.

The Error Message is like below. (for detailed, refer to attached file)

/unit_tests/mxc_v4l2_overlay.out -iw 640 -ih 480 -it 0 -il 0 -ow 1024 -oh 768 -ot 0 -ol 0 -r 0 -t -1 -d 0 -fg -fr 30

g_display_width = 1024, g_display_height = 768

g_display_top = 0, g_display_left =0

Unable to open /dev/video0

In this patch you used the 5640 MIPI Camera, but I'm using the Pallel Camera (OV5642MRSL-A01A).

For OV5642, I insert the below drivers into kernel.

- ipu_bg_overlay_sdc.c / ipu_fg_overlay_sdc.c

   . Linux.Menu -> Device Drivers -> Multimedia support -> Video capture adapter -> MXC Camera/V4L2 PRP Features support -> Select Camera/TV Decoder (ov5642)

- ov5642.c

   . Linux.Menu -> Device Drivers -> Multimedia support -> Video capture adapter -> MXC Camera/V4L2 PRP Features support -> Select Overlay Routing (Overlay)

And I modified arch/arm/mach-mx6/board-mx6q_sabresd.c to register OV5642.

But I couldn't confirm the OV5642 Camera Operation, and the same error was occurred.

Could you tell me how to use the Pallel OV5642 Camera in the Fastboot patched Kernel?

Best Regards,

Eric.

Eric,

All devices nodes you want to use MUST be created before using them. Check my last comment, it has a link with this info.

Leo

Hi,Why i can't find "imx6_ssd_lite_defconfig" in "arch/arm/configs" ? my device is imx6q.

Dear Leo,

I confirmed the Fast boot operation in Linux.

Thanks for your response.

Dear All,

I want to apply the Fast Boot function into Android.

I'm using the Android jb4.2.2_1.1.0 BSP for i.MX6Q SabreSD board.

Could you give me any assistance?

Now I'm appying the attached code(kernel.tar.bz2, Patch code based on L3.0.35_12.09.01_GA) into Android jb4.2.2_1.1.0 BSP.

But I couldn't boot faster than the normal boot.

Best Regards,

Eric.

  • Optimizing _memcpy_fromio function at  arch/arm/kernel/io.c

This is an interesting change - did you profile the kernel to find whether it was actually being called or not and how much time the 'unoptimized' function took? There are actually scant few places where an i.MX6 would run across this function.

Apart from supporting ADMA in the SDHC controller, using SDMA (over a large chunk.. small copies take longer to set up than it takes to copy it) which seem functionally worthwhile and would give an improvement at least in CPU time used, a properly configured kernel (i.e. loaded to the correct load address and not needing any relocation) and U-Boot (i.e. has the correct load address hardcoded into it) should not be doing much memory copying at all past the early U-Boot relocation step - which the 2009.08 FSL BSP U-Boot doesn't do - and at least none that would benefit vastly from being more optimized. The small amount of time that U-Boot actually takes doing LARGE memory copies (especially if you're implementing SDMA..), and the small amount of instances of memcpy_fromio being called in the kernel seems that these are straw man optimizations.

Do you have any profiling data to support the speed improvement as a whole with each function change?

Ta,

Matt

can you tell me which version of u-boot is used?

Hello ,

Where can i find /unit_tests/mxc_v4l2_overlay.out utility ?

Which recipe i need to use for bitbake to get this built for me.


Thanks,

The recipe “imx-test” provides the unit_tests.

You will find the directory sources after baking:

tmp/work/imx6qsabresd-poky-linux-gnueabi/imx-test/1_3.10.53-1.1.0-r0/imx-test-3.10.53-1.1.0/test/mxc_v4l2_test

Regards,

-Curtis

Also getting this error when i build fsl-image-test :

new_fsl-release-bsp/my_build/tmp/sysroots/i686-linux/usr/bin/autoconf --include=. --force

| configure.ac:66: error: possibly undefined macro: AM_INIT_AUTOMAKE

|       If this token and others are legitimate, please use m4_pattern_allow.

|       See the Autoconf documentation.

| configure.ac:67: error: possibly undefined macro: AM_MAINTAINER_MODE

| configure.ac:72: error: possibly undefined macro: AM_SILENT_RULES

| configure.ac:115: error: possibly undefined macro: AM_CONDITIONAL

| configure.ac:291: error: possibly undefined macro: AM_PROG_CC_C_O

| configure.ac:377: error: possibly undefined macro: AM_PATH_PYTHON

| configure.ac:677: error: possibly undefined macro: AC_LANG_SOURCE

| configure.ac:893: error: possibly undefined macro: AM_LANGINFO_CODESET

| configure.ac:998: error: possibly undefined macro: AC_FUNC_VSNPRINTF_C99

| configure.ac:999: error: possibly undefined macro: AC_FUNC_PRINTF_UNIX98

| configure.ac:1170: error: possibly undefined macro: jm_AC_TYPE_LONG_LONG

| configure.ac:1176: error: possibly undefined macro: jm_AC_TYPE_INTMAX_T

| configure.ac:1178: error: possibly undefined macro: AC_FUNC_SNPRINTF_C99

but building core-image is perfectly fine ...

why its breaking in autoconf ?

Hey ,

does these patches support latest kernel eg 10.17 ?

applied your u-boot patch and u-boot seems running much faster now.

i notice that there is a ~1 sec pause between "Start kernel ..." and "Booting Linux on ..."

my kernel is only ~2.5MB in size. I wonder the time needed for loading the linux is normal?

(kernel is in eMMC)

Any steps to reduce this pause time to minimum?

Could I use this patch with MarS Board (embest-tech)
And.. how to use these files?

Which version of u-boot is used??

Do you have any boot time optimisation method for Android Nougat.

Regards,

Aravinth 

No ratings
Version history
Last update:
‎10-15-2012 11:04 PM
Updated by: