Linux Bootup Time Reduction for Digital Still Camera

1
Linux Bootup Time Reduction for Digital Still
Camera

• Chan Ju, Park
• SW Laboratories
• Samsung Electronics

2
Agenda

• Introduction
• DSC Bootup Procedure
• Bootup time reduction methods
• Boot loader
• Kernel
• Root File system
• Application Optimization
• Suspend/resume
• Results
• Further works
• Conclusion

3
terms

• DSC
• Digital still camera
• Bootup time
• The time from platform power on to preview state
• Preview state
• The DSC state for ready-to-shot
• 3A
• Auto focus, auto white balance, auto expose
• Suspend/resume
• Suspend to dram
• RFS
• Root file system for Linux Kernel
• Robust FS
• Linux file system for OneNAND flash
• Normal boot, suspend/resume boot

4
introduction

• About this project
• In samsung, Embedded Linux ported for many CE
  devices
  
• DTV, DMB, Mobile phone, DVR, other set top boxes,
  etc
  
• But not DSC area
• DSC use many RTOSes ( vxworks, pSos, uITRON,
  Nucleus, etc)
  
• Project stated for evaluation of embedded linux
• Why Linux in DSC
• Technical Convergence in CE Devices
• Plentiful of Application
• Open S/W Platform
• Cost?

5

• Embedded Linux on DSC
• There exist only few cases which was published
• E.g. Ricoh Company made prototype Linux DSC
• DSC bootup time
• Long bootup time diminish customer satisfaction
• Bootup Time is more important in DSC

6

• Linux Bootup Time
• PC 1 min or more
• Embedded System 210 sec
• Depends on system, Applications, Policy
• Image loading, H/W peripherals, application init
• applied Bootup methods for DSC
• Normal Boot
• bootloader preview application running
• Suspend/Resume
• using suspend-to-ram
• Goals
• Normal boot 2 sec
• Suspend/resume 1 sec

7
Test Environments

• Target Platform
• Core
• ARM926EJS
• Image processor
• Samsung S5C7380x
• System clock
• 216Mhz Fclock,108Mhz Hclock
• Memory
• 64MB DDR,
• 64MB One-NAND flash ( async mode )
• DSC Module etc
• 6M CCD(CMOS) censor, AF/Zoom/Shutter/Iris motor,
  Digital LCD, JPEG/MPEG codec, etc.
  
• USB, ADC, SD/MMC Card, etc

• Kernel
• 2.4.20
• Non-compressed Image
• Size about 1MB
• File System
• Root fs Cramfs
• Robust FS for Flash filesystem in OneNAND

8
Bootup time reduction is

• Every little makes a mickle
• All kinds of techniques are needed
• Firmware (boot loader)
• Minimal system init
• shortening image copy time
• Boot devices
• Hardware initialization
• One time System initialization
• Remove H/W probing time
• Only initialize the device which was used when
  bootup
  
• E.g. Dsc motors, storage (HDD, Card, Flash), DSP,
  etc

9

• Image small sizing
• kernel, root fs (libraries), D/D Modules, etc
• Depends on the kernel configuration
• Device driver initialization
• Remove H/W probing Initialization
• Using hard coding
• Module loading policy
• Using static module if needed
• Other modules can load when needed
• application optimization
• Resource loading
• Memory allocation
• App setup procedure
• Suspend/resume

10
DSC Booting Procedure
11

• bootloader
• reset OneNAND boot loader(xloader) execute
• xloader copied to SDRAM execute at SDRAM
• xloader copy u-boot to RAM
• DSC motor init
• u-boot execute copy kernel Image to SDRAM
• kernel init
• Kernel Init code execute
• init kernel subsystem
• init static module
• mount cramfs
• execute init script
• application init
• execute basic DSC application module
• setup preview mode sequence
• display preview OSD Image

12
Boot time measurements

• Using H/W devices
• Expensive
• Target code modification is needed
• Exact
• Using serial outputs
• ARM or MIPS has no counter register (x86TSC
  reg.)
  
• Using host serial in cross development
  environments
  
• features
• Cheap
• No or few modification for the target code
• Can collect much data
• Comparatively small differences

13
Initial bootup time (before optimization)

• Just after kernel and D/D porting
• Using NAND flash, zImage

14
Applied methods

• Normal bootup
• bootloader
• OneNAND booting (more faster than Nand flash, 2
  times)
  
• Kernel / device driver
• use Preset LJP (Loop Per Jiffies)
• module init optimization
• use non-compressed kernel image
• size optimization ( kernel, library )
• remove kernel message
• File system
• application optimization
• Suspend/resume

15
Boot loader

• Not using u-boot except development period
• Boot loader
• initializes a system
• loads the Kernel image into RAM
• Minimal initialization
• Memory, clock
• Boot device
• NAND Flash
• OneNAND Flash
• When power on, xloader (1KB bootloader of OneNAND
  flash) is executed automatically
  
• hardly influence to bootup time
• More fast than nand flash (2 times)

16
Flash Partition Usage (OneNAND flash)
0
xloader
boot partition
128K
bootloader paramters
param partition
256K
Linux Kernel Image
kernel partition
2MB
CRAMFS (Code Library files)
root partition
20MB
Robust FS (System Config Files User Data Files
)
Robust FS partition
Reserved Area
64MB OneNAND
17
Kernel D/D

• Using uncompressed Image
• Save decompressing time
• Preset loops_per_jiffy
• Find out loops_per_jiffy values, and hard coding
• Disable Console Output
• Just add quiet option to command line when
  compile
  
• Remove root file system check routine
• Concurrent driver init
• DSC Motor has long initialization time
• Modification zoom motor init code
• More than 1sec
• Motor init can be parallelized
• Initialize at start of the bootloader
• Remove the static device driver
• It makes smaller kernel
• Save the module init time at bootup
• The modules which is not need at bootup time can
  be loaded after bootup.

18

• Saving memory allocation time for Image
  processing
  
• Using boot-time allocation methods
• Kernel doesnt know about area
• Can save mem alloc time
• Can using the big area DMA memory
• Max 12MB contiguous memory required (capture
  mode)
  

19
Root File system

• Issues of Root File System
• Save copy time at bootloader
• Save decompressing time when kernel initialized
• small size image
• Using busy box
• CRAMFS
• Read only nand file system
• Modifiable directory has to mount another R/W
  file system
  
• We use robust file system for OneNAND
• It include bad block management algorithms
• Partial uncompressed cramfs
• Save decompressing time
• Not tested at this time

20
Application init loading

• Loading OSD data
• When system bootup, load only need data
• DSC application
• If preview mode, other process creation init
  loading can delay
  
• Memory allocation, copy
• Time spending
• DSC processing much Image data
• Storage device Init mount time
• Sd/mmc card initialization
• Initialization can be delayed
• Background processing
• Card Device Init (device init, mount, etc)
• storage information reading
• Init DCF/Exif S/W module

21
Results
22
Results
23
Suspend / Resume

• suspend-to-ram
• During system suspend, the ram change to
  self-refresh mode
  
• issues
• The cost of suspend/resume to Ram
• Power consumption
• Self refresh mode of DRAM
• power off all devices except but RAM
• Boot flags registers
• If it locates at DSP, consume more power
• Using power management unit (PMU)
• Other information will be stored at global
  variables in DRAM
  
• CPU register, stack, I/O register values

24
System suspend procedure
Power off Button Push
CPU Register Save to RAM
IO Register Contents save to RAM
Set to self refresh mode of RAM
Save flag of fast boot to PMU Register
Power off CPU all devices except PMU RAM
25
System resume procedure
Resume boot process
Normal boot process
Power on
PMU power on
Reset vector
Boot loader
Restore HW register values
DSC H/W init
Set interrupt for resume
Disable Interrupt
Restore variables CPU register values
Check if suspended
suspended
DSC HW / App init Check DSC Mode
Normal
Clock, Memory Init
Execute DSC app
Kernel loading jump
PMU Power Management Unit
26
Results of suspend/resume

• from reset to preview state
• About 800 ms
• For power saving
• It is possible to full shutdown when user does
  not operate during settled time
  

27
Excepted methods

• Kernel XIP
• Executing code directly from flash
• Reduce boot time and save cost, etc
• Current platform has no proper devices (e.g Nor
  Flash)
  
• Parallelizing of services execution
• applying techniques of parallelizing RC-scripts
  at system / user space start up
  
• Effectiveness depends on the number of services
• Embedded system such as DSC has not many services

28
Further works

• prelink (library execution optimization)
• Bootcache
• Suspend-to-disk
• Boot process analyzing with tools
• Ex) Bootchart
• optimized block copy in OneNAND
• OneNAND cached copy
• synchronous mode

29
Conclusion

• There exist many methods for reducing the Linux
  Bootup time
  
• The Reduction methods are variant
• from the DSC H/W or scenario,
• So we have to choice the proper policy.
• Linux Bootup methods for DSC
• normal boot
• Suspend/resume
• Many reduction methods can be adopted but,
• choice evaluation is needed
• Embedded Linux can satisfy the requirements of
  DSC Bootup time

30
References

• Linux on a Digital Camera, Porting 2.4 Linux
  kernel to an existing digital camera,Alain
  Volmat, Ricoh Company Ltd.
  
• Methods to Improve Bootup Time in LinuxTim R.
  Bird, Sony Electronics
  
• IBM developer white paper, Boot linux faster,
  parallelize Linux system services to improve boot
  speedhttp//www-106.ibm.com/developerworks/linu
  x/library/l-boot.html?cadgr-lnxw04BootFaster