Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.
I've been working as an ASIC design for the last 9 years and it's my first time to hear that there is something called Booting Sequence in ASIC ..
You may encounter this term with Operating Systems .. Processors .. and even FPGA, when the design is loaded to the FPGA each time you power-on the system .. but in ASIC, I have no clue !
If you want to ask about something in specific like PLL, or memory controller don't generalize .. can't you have an ASIC chip without a memory controller !!!
PLL and Memories, are design components .. while ASIC is a process/methodology of implementing this design ..
Bootloader
The first program which runs on any Android system is the bootloader. Technically, the bootloader is outside the realm of Android itself, and is used to do very low-level system initialization, before loading the Linux kernel. The kernel then does the bulk of hardware, driver and file system initialization, before starting up the user-space programs and applications that make up Android.
Often, the first-stage bootloader will provide support for loading recovery images to the system flash, or performing other recovery, update, or debugging tasks.
The bootloader on the ADP1 detects certain keypresses, which can be used to make it load a 'recovery' image (second instance of the kernel and system), or put the phone into a mode where the developer can perform development tasks ('fastboot' mode), such as re-writing flash images, directly downloading and executing an alternate kernel image, etc.
'init'
A key component of the Android bootup sequence is the program 'init', which is a specialized program for initializing elements of the Android system. Unlike other Linux systems (embedded or otherwise), Android uses its own initialization program. (Linux desktop systems have historically used some combination of /etc/inittab and sysV init levels - e.g. /etc/rc.d/init.d with symlinks in /etc/rc.d/rc.[2345]). Some embedded Linux systems use simplified forms of these -- such as the init program included in busybox, which processes a limited form of /etc/inittab, or a direct invocation of a shell script or small program to do fixed initialization steps.
The Android 'init' program processes two files, executing the commands it finds in them, called 'init.rc' and 'init.<machine_name>.rc', where <machine_name> is the name of the hardware that Android is running on. (Usually, this is a code word. The name of the HTC1 hardware for the ADP1 is 'trout', and the name of the emulator is 'goldfish'.
The 'init.rc' file is intended to provide the generic initialization instructions, while the 'init.<machine_name>.rc' file is intended to provide the machine-specific initialization instructions.
'init' resources
The syntax for these .rc files is documented in a readme file in the source tree. See the Android init language reference
Sequence of boot steps on ADP1
firmware
first-stage bootloader runs
it detects if a special key is held, and can launch the recovery image, or the 'fastboot' bootloader
eventually, a kernel is loaded into RAM (usually with an initrd)
normally, this will be the kernel from the 'boot' flash partition.
kernel
the kernel boots
core kernel initialization
memory and I/O areas are initialized
interrupts are started, and the process table is initialized
driver initialization
kernel daemons (threads) are started
root file system is mounted
the first user-space process is started
usually /init (note that other Linux systems usually start /sbin/init)
user space
the kernel runs /init
/init processes /init.rc and /init.<machine_name>.rc
dalvik VM is started (zygote). See Android Zygote Startup
several daemons are started:
rild - radio interface link daemon
vold - volume daemon (media volumes, as in file systems - nothing to do with audio volume)
the system_server starts, and initializes several core services
See Enea Android Blog: The System Server in Android
initalization is done in 2 steps:
1) a library is loaded to initialize interfaces to native services, then
2) java-based core services are initialized in ServerThread::run() in SystemServer.java
the activity manager starts core applications (which are themselves dalvik applications)
com.android.phone - phone application
android.process.acore - home (desktop) and a few core apps.
other processes are also started by /init, somewhere in there:
adb
mediaserver
dbus-daemon
akmd
in our design center the boot sequence is done by a small logic to mainly implement wait time and means:
1-to have the regulator(s) on,
2-to have the internal clock stabilize,
3-after we allows the "digital" to work (read internal/external memories....)
hi
in all devices or in meachins the booting is the most importent process which will start from bootstrap code present in processor internal ROM memory, it is happing because once the processor starts it dont know where the program or OS has been stored and which peripherals are interfaced to get this info the boot strap code will point to the memory area where BIOS or bootup code is ther then the processor will read bootup code form ther then from that code it will get information about all pheripherals and memories and continues to work with application
Booting Sequence in SoC/ASIC
In any SoC/ASIC will have atleast One Master Processor (ARM/MIPS/MicrController) to control the Data path and Control path. ARM based SoC are common in nature nowadays and better to explain in ARM points of view, but still applicable for any Master Processor.
1. System is Powered-Up and all devices are in its active state
2. Reset Sequence (Resetting the SoC and the output is resetting all other peripherals as well)
3. Once the reset is received by the Master Processor (ARM), all it's internal registers, accumulators are cleared with reset values.
4. After reset de-assertion, the Address Bus of the ARM will point to RESET VECTOR (0x00000000(LOW VECTOR) or 0xFFFF0000(High Vector) based on the pin configuration for reset vector).
5. This RESET VECTOR will always start from the ROM Address and these ROM CONTENTS or BOOT_CODE would be INITIALISATION, MEMORY MAPPING, CONFIGURATION, INTERRUPT HANDLING, and STACK DECLARATION for the entire SoC.
6. During BOOT CODE execution, Processor will get the Program Data from the ROM for the internal variable declaration, Data Memory Addresses (entire memory mapping), Stack definitions for different modes, Stack Pointer declarations, Cache Management (if Cache memory is used), Interrupt Vector Definitions, Interrupt Handler initialisation etc.
7. Once all the above settings are done Program Counter will jump to the main() which will be pointing the application code for individual tasks which will be executing in the RAM.
8. In most of the SoC architecture the Testcases would be writing inside the application code which will be executing in the RAM.
9. Once the Test is finished result would be updated bu toggling any of the GPIO toggling or some part of the DRAM is used for the RESULT memory (SCRATCH PAD Area).
The above explanation is very simple and applicable in most SoCs. If anything I missed please alert.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
