How to use Kermit

1 install: sudo apt-get install ckermit

2 commands:

connect(c)	connect to serial device (kermit -c)
ctrl+\ & c	switch to Kermit cmd prompt from serial port
quit(q)	exit from Kermit
log session	save info in session.log at current direction
send	send file using Kermit protocol to uboot
transmit	send txt file to board
run	execute external command(eg, calling xmodem for sending files)
!	leave Kermit to execute a shell. When exit the shell, it will return to Kermit
?	show all commands

3 download file into development board:

         Step-1: loadb 0x200000 (at uboot prompt)

         Step-2: send ~/uImage (at kermit prompt)

4 use Kermit for normal user:

         Configure ~/.kermrc and get permission for /dev/ttyUSB0

         # ls -l /dev/ttyUSB0

         crw-rw---- 1 root uucp 4, 64 07-17 03:53 /dev/ttyUSB0

         # groupmems -a kery -g uucp

5 configure Kermit:

First, kermit uses ~/.kermrc for initializing, or it is not exist then uses /etc/kermit/kermrc.

#sudo gedit /etc/kermit/kermrc (# cat > ~/.kermrc):

set line /dev/ttyUSB0

set speed 115200

set handshake none

set flow-control none

set carrier-watch off

robust

set file type bin

set file name lit

set rec pack 1000

set send pack 1000

set window 5

set transmit echo on

set transmit pause 20

set transmit timeout 1

set transmit prompt 62

set prompt Kermit>

define sz !sz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)

define rz !rz \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)

define sx !sx \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)

define rx !rx \%1 \%2 \%3 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line)

c      #connect to serial port when execute Kermit

6 u-boot configuration:

setenv baudrate 115200

setenv stdin serial

setenv stdout serial

setenv stderr serial

setenv consoledev ttyS0

setenv loads_echo 1

setenv loadaddr 200000                #RAM address

setenv loadkernaddr 1000000       #RAM address for tftp download kernel

setenv loadramdaddr 1200000     #RAM address for tftp download ramdisk

setenv kernaddr fe810000             #flash address for kernel

setenv ramdiskaddr fe9a0000       #flash address for ramdisk

setenv ramdisksize 65000              #ramdisk file system size in flash

setenv bootdrive sda1                    #boot device

setenv netdev eth0

setenv ipaddr 59.64.155.244                          #board’s netdev(eth0) ip

setenv bootdelay '3'                                         #unit: Second

setenv bootcmd 'run flashramboot'                 #default boot: from flash

setenv serverip 59.64.155.122                        #nfs server/tftp server ip

setenv rootpath '/home/kery/rootfsln'          #nfs server root direction or link

setenv tftp_path 'bootln'                                     #tftp server root direction or link

setenv netmask 255.255.255.0

setenv gatewayip 59.64.155.1

setenv setargs 'setenv bootfile \$tftp_path/uImage;setenv ramdiskfile \$tftp_path/rootfs.ext2.gz.uboot;'

setenv setnfsargs 'setenv bootargs root=/dev/nfs rw

nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off

console=$consoledev,$baudrate $othbootargs' 

setenv tftpnfsboot  'run setargs;run setnfsargs;tftp $loadkernaddr $bootfile;bootm $loadkernaddr'

setenv tftpramboot 'run setargs;run setramargs;tftp $loadkernaddr $bootfile;tftp $loadramdaddr $ramdiskfile;bootm $loadkernaddr $loadramdaddr'

setenv setenv1 'setenv rootpath /home/kery/rootfs;setenv ipaddr 59.64.155.244;setenv ethaddr 08:00:3e:03:01:10;setenv eth1addr 08:00:3e:03:01:11;setenv eth2addr 08:00:3e:03:01:12'

saveenv

Init Process

Init is the first process after kernel is started. Process step:

1. Mount basic file system, and initialize log system.

2. Parse /init.rc and /init.%hardware%.rc.

3. Execute early-init action in init.rc.

4. Device specific initialize.

5. Initialize property system, and load android image, then print” ANDROID”.

6. Execute init action in init.rc.

7. Start property service.

8. Execute early-boot and boot actions in init.rc.

9. Execute property action in init.rc.

10. Enter into an indefinite loop to wait for device/property set/child process exit events. For example, if an SD card is plugined, init will receive a device add event, so it can make node for the device. Most of the important process is forked in init, so if any of them crashed, init will receive a SIGCHLD then translate it into a child process exit event, so in the loop init can handle the process exit event and execute the commands defined in *.rc(it will run command onrestart).

Process list

USER     PID   PPID  VSIZE RSS   WCHAN    PC         NAME

root     1     0     548   196   c00b8c14 0000d5cc S /init

root     2     0     0     0     c006bf70 00000000 S kthreadd

root     3     2     0     0     c005cc50 00000000 S ksoftirqd/0

root     4     2     0     0     c007e408 00000000 S watchdog/0

root     5     2     0     0     c0068eec 00000000 S events/0

root     10    2     0     0     c0224f90 00000000 S suspend/0

root     81    2     0     0     c0068eec 00000000 S kblockd/0

root     143   2     0     0     c008f948 00000000 S kswapd0

root     195   2     0     0     c01721f0 00000000 S mtdblockd

root     726   1     772   180   c019dbc4 afe0c1dc S /system/bin/sh

system   727   1     840   188   c022d8a0 afe0c47c S /system/bin/servicemanager

root     729   1     1920  336   ffffffff afe0c1dc S /system/bin/mountd

radio    733   1     12796 648   ffffffff beaab18c S /system/bin/rild

root     734   1     72000 14172 c00b92b0 afe0c5a4 S zygote

root     736   1     1080  216   c00b8c14 bedc021c S /system/bin/dbus-daemon

root     737   1     832   208   c02b6e80 afe0c1dc S /system/bin/installd

root     768   1     720   272   c02265ec afe0c1dc S /system/bin/logcat

system   825   734   574128 28360 ffffffff afe0c47c S system_server

radio    877   734   158260 20040 ffffffff afe0d404 S com.android.phone

system   882   734   144664 24296 ffffffff afe0d404 S android.process.omsservice

app_5    928   734   100888 13336 ffffffff afe0d404 S com.android.inputmethod.borqs

app_18   960   734   104180 15208 ffffffff afe0d404 S com.android.mms

system   1018  734   94732 13792 ffffffff afe0d404 S oms.dm

app_1    1424  734   111904 17024 ffffffff afe0d404 S oms.messaging

root     1684  1     3364  176   ffffffff 0000e8f4 S /sbin/adbd

root     1724  1692  920   356   00000000 afe0c1dc R ps

Zygote: It is the first Dalvik VM. Zygote service does the following tasks step by step:

1. Create JAVA VM

2. Register android native function for JAVA VM.

3. Call the main function in the JAVA class named com.android.internal.os.ZygoteInit whose source is device/java/android/com/android/internal/os/ZygoteInit.java.

  a) Load ZygoteInit class

  b) Register zygote socket

  c) Load preload classes (the default file is device/java/android/preloaded-classes)

  d) Load preload resources

  e) Call Zygote::forkSystemServer (implemented in device/dalvik/vm/InternalNative.c) to fork a new process. In the new process, call the main function in the JAVA class named com.android.server.SystemServer, whose source is in device/java/services/com/android/server.

    i. Load libandroid_servers.so

ii. Call JNI native init1 function implemented in

device/libs/android_servers/com_android_server_SystemServers. It only calls system_init implemented in device/servers/system/library/system_init.cpp.

*If running on simulator, instantiate AudioFlinger, MediaPlayerService and CameraService here.

*Call init2 function in JAVA class named com.android.server.SystemServer, whose source is in device/java/services/com/android/server. This function is very critical for Android because it start all of Android JAVA services.

*If not running on simulator, call IPCThreadState::self()->joinThreadPool() to enter into service dispatcher.

SystemServer::init2 will start a new thread to start all JAVA services as follows:

Core Services:

   1. Starting Power Manager

   2. Creating Activity Manager

   3. Starting Telephony Registry

   4. Starting Package Manager

   5. Set Activity Manager Service as System Process

   6. Starting Context Manager

   7. Starting System Context Providers

   8. Starting Battery Service

   9. Starting Alarm Manager

  10. Starting Sensor Service

  11. Starting Window Manager

  12. Starting Bluetooth Service

  13. Starting Mount Service

Other services

   1. Starting Status Bar Service

   2. Starting Hardware Service

   3. Starting NetStat Service

   4. Starting Connectivity Service

   5. Starting Notification Manager

   6. Starting DeviceStorageMonitor Service

   7. Starting Location Manager

   8. Starting Search Service

   9. Starting Clipboard Service

  10. Starting Checkin Service

  11. Starting Wallpaper Service

  12. Starting Audio Service

  13. Starting HeadsetObserver

  14. Starting AdbSettingsObserver

Finally SystemServer::init2 will call ActivityManagerService.systemReady to launch the first activity by senting Intent.CATEGORY_HOME intent.

There is another way to start system server, which is through a program named system_server whose source is device/servers/system/system_main.cpp. It also calls system_init to start system services. So there is a question: why does Android have two methods to start system services? My guess is that directly start system_server may have synchronous problem with zygote because system_server will call JNI to start SystemServer::init2, while at that time zygote may not start JAVA VM yet. So Android uses another method. After zynote is initialized, fork a new process to start system services.

Android Init Language

The Android Init Language consists of four broad classes of statements, which are Actions, Commands, Services, and Options. Lines which start with a # are comments.

Actions and Services implicitly declare a new section. All commands or options belong to the section most recently declared. Commands or options before the first section are ignored.

Actions and Services have unique names. If a second Action or Service is declared with the same name as an existing one, it is ignored as an error.

Actions are named sequences of commands. Actions have a trigger which is used to determine when the action should occur. When an event occurs which matches an action's trigger, that action is added to the tail of a to-be-executed queue (unless it is already on the queue).

Each action in the queue is dequeued in sequence and each command in that action is executed in sequence. Init handles other activities (device creation/destruction, property setting, process restarting) "between" the execution of the commands in activities. Actions take the form of:

on <trigger>

   <command>

   <command>

   <command>

Services are programs which init launches and (optionally) restarts when they exit. Services take the form of:

service <name> <pathname> [ <argument> ]*

   <option>

   <option>

   ...

Options are modifiers to services. They affect how and when init runs the service.

critical	This is a device-critical service. If it exits more than four times in four minutes, the device will reboot into recovery mode.
disabled	This service will not automatically start with its class. It must be explicitly started by name.
oneshot	Do not restart the service when it exits.
onrestart	Execute a Command (see below) when service restarts.
setenv <name> <value>	Set environment variable <name> to <value> in the launched process.
socket <name> <type> <perm> [ <user> [ <group> ] ]	Create a unix domain socket named /dev/socket/<name> and pass its fd to the launched process.  <type> must be "dgram" or "stream". User and group default to 0.
user <username>	Change to username before exec'ing this service. Currently defaults to root. Currently, if your process requires linux capabilities then you cannot use this command. You must instead request the capabilities in-process while still root, and then drop to your desired uid.
group <groupname> [ <groupname> ]*	Change to groupname before exec'ing this service.  Additional groupnames beyond the first one are used to set the supplemental groups of the process (via setgroups()). Currently defaults to root.
class <name>	Specify a class name for the service. All services in a named class may be started or stopped together. A service is in the class "default" if one is not specified via the class option.

Triggers are strings which can be used to match certain kinds of events and used to cause an action to occur.

boot	First trigger that will occur when init starts (after /init.conf is loaded)
<name>=<value>	Triggers of this form occur when the property <name> is set to the specific value <value>.
device-added-<path> device-removed-<path>	Triggers of these forms occur when a device node is added or removed.
service-exited-<name>	Triggers of this form occur when the specified service exits.

Commands

The builtin supported commands are defined in device/system/init/keywords.h. Commands are implementd in device/system/init/bultins.c.

exec <path> [ <argument> ]*	Fork&execute a program (<path>). This will block until the program completes execution. It is best to avoid exec as unlike the builtin commands; it runs the risk of getting init "stuck".(maybe there should be a timeout?)
export <name> <value>	Set the environment variable <name> equal to <value> in the global environment (which will be inherited by all processes started after this command is executed)
ifup <interface>	Bring the network interface <interface> online.
import <filename>	Parse an init config file, extending current configuration.
hostname <name>	Set the host name.
chdir <directory>	Change working directory.
chmod <octal-mode> <path>	Change file access permissions.
chown <owner> <group> <path>	Change file owner and group.
chroot <directory>	Change process root directory.
class_start <serviceclass>	Start all services of the specified class if they are not already running.
class_stop <serviceclass>	Stop all services of the specified class if they are currently running.
domainname <name>	Set the domain name.
insmod <path>	Install the module at <path>
mkdir <path> [mode] [owner] [group]	Create a directory at <path>, optionally with the given mode, owner, and group. If not provided, the directory is created with permissions 755 and owned by the root user and root group.
mount <type> <device> <dir> [ <mountoption> ]*	Attempt to mount the named device at directory <dir> <device> may be of the form mtd@name to specify a mtd block device by name. <mountoption>s include "ro", "rw", "remount", "noatime", ...
setprop <name> <value>	Set system property <name> to <value>.
setrlimit <resource> <cur> <max>	Set the rlimit for a resource.
start <service>	Start a service running if it is not already running.
stop <service>	Stop a service from running if it is currently running.
symlink <target> <path>	Create a symbolic link at <path> with the value <target>
sysclktz <mins_west_of_gmt>	Set system clock base (0 if system clock ticks in GMT)
trigger <event>	Trigger an event. Used to queue an action from another action.
write <path> <string> [ <string> ]*	Open the file at <path> and write one or more strings to it with write
setkey	TBD

property: a storage provided by Android for sharing setting values of System environment between processes. it's on the shared memory area and can be referred by processes through API, but modifying is only allowed for init process. If there is need to change of an environment value, application should request to init process.

(1) property_get()

(2) property_set()

(3) start_property_service()

(4) socket of property service: use for requesting to change property value from other processes.