Vayavya's Blog http://vayavyalabs.com/blog Bridging Hardware and Software flows....... Thu, 29 Apr 2010 13:12:28 +0000 en hourly 1 http://wordpress.org/?v=3.0 Porting WinCE on eval boards – part 1 http://vayavyalabs.com/blog/?p=120 http://vayavyalabs.com/blog/?p=120#comments Thu, 29 Apr 2010 12:12:13 +0000 someshward http://vayavyalabs.com/blog/?p=120 Porting of WinCE on a new evaluation board is one challenging task. Though when some of the following things when kept in mind will always make the job easy. 1. Know details of your hardware board well - programming details of peripherals on the SoC - availability of RAM, flash technologies, etc, or much better, know the memory mapping details - hardware ports availability on the board - details of board layout and connections with SoC 2. Familiarize yourself with the Microsoft Visual Studio (I work with v2005) and Platform builder 3. Check for a working BSP targeting the same platform, - parts of the existing BSP involving writing of assembly code for boot loader and OAL layer can be reused for writing the new BSP. - more simpler, clone the existing BSP and tweak the cloned BSP to work for the new target - most of the OAL framework code duplication will be avoided 4. WINCE600 will always have some or the other support libraries provided to make job of the developer easy. Always check if there are any helpful libraries available for use. "google MSDN :D " Carrying out the porting for the new target will involve the development of following, 1. Boot loader (boot strapping of boot loader is a different issue) 3. KITL (Kernel Independent Trasport Layer) 2. OAL (OEM Abstraction Layer) 4. WinCE Device Drivers 5. Applications Will add details on the components in my future posts. cheers, somesh ]]> http://vayavyalabs.com/blog/?feed=rss2&p=120 0 Linux Run Level http://vayavyalabs.com/blog/?p=19 http://vayavyalabs.com/blog/?p=19#comments Tue, 17 Feb 2009 13:14:43 +0000 Administrator http://vayavyalabs.com/blog/?p=19 Linux kernel will start a program called init, if it finds it. The init process reads the file “/etc/inittab” and uses this file to determine how to create processes. Read the init man page for more information. Also note that init is always running and can dynamically do things and run processes based upon various signals. The administrator can also cause it to dynamically change system processes and runlevels by using the telinit program or editing the “/etc/inittab” file.

Runlevels

Linux utilizes what is called “runlevels”. A runlevel is a software configuration of the system that allows only a selected group of processes to exist. Init can run the system in one of eight runlevels. These runlevels are 0-6 and S or s.

The standard Run Level for a linux machine booting up in full GUI mode is Run Level 5.The most common need for Run Level 3 is for debugging problems and installing graphic drivers.

If you want to specify a default Run Level other than 5, the option can be changed in your /etc/inittab as defined by the initdefault directive. Below is a table specifying the other various Run Levels and State properties.

Run Level State
0 halt (shutdown) system
1 single user mode
2 multi user with no network exported
3 default full multi user console (text) only
4 reserved for local use (and X-window)
5 X-window full GUI mode
6 reboot system

  1. Change Run Level After Boot Up

    2. The easiest way to change the Run Level after the system has already been booted up is to open up the console and use init. There is an example below on how to change the Run Level to 3.

    init 3

  2. Change Run Level on System Boot Up

    3. If however your Linux machine is currently powered off and you would like to boot directly into an alternative Run Level, you can change the Run Level by accessing the linux startup boot menu (GRUB). Simply choose the desired kernel and add init 3 into the kernel string.

However my experience so far is that students get confused with ssh and KDE/Gnome Desktop login. SSH logins are handled by sshd server which starts at run level 2/3. KDE/Genome Desktop login are handled by GDM/XDM/KDM display manager which starts at run level 5

The “/etc/inittab” file tells init which runlevel to start the system at and describes the processes to be run at each runlevel. An entry in the inittab file has the following format:

id : runlevels : action : process

id - A unique sequence of 1-4 characters which identifies an entry in inittab.

runlevels - Lists the runlevels for which the specified action should be taken. This field may contain multiple characters for different runlevels allowing a particular process to run at multiple runlevels. For example, 123 specifies that the process should be started in runlevels 1, 2, and 3.

action - Describes which action should be taken.

Valid actions are listed below
Action Description
respawn The process will be restarted whenever it terminates.
wait The process will be started once when the specified runlevel is entered and init will wait for its termination.
once The process will be executed once when the specified runlevel is entered
boot The process will be executed during system boot. The runlevels field is ignored.
bootwait Same as “boot” above, but init waits for its termination.
off This does nothing.
ondemand This process will be executed whenever the specified ondemand runlevel is called.
initdefault Specifies the runlevel which should be entered after system boot. If none exists, init will ask for a runlevel on the console. The process field is ignored.
sysinit The process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored.
powerwait The process will be executed when init receives the SIGPWR signal. Init will wait for the process to finish before continuing.
powerfail Same as powerwait but init does not wait for the process to complete.
powerokwait The process will be executed when init receives the SIGPWR signal provided there is a file called “/etc/powerstatus” containing the word “OK”. This means that the power has come back again.
ctrlaltdel This process is executed when init receives the SIGINT signal. This means someone on the system console has pressed the “CTRL-ALT-DEL” key combination.
kbrequest The process will be executed when init receives a signal from the keyboard handler that a special key combination was pressed on the console keyboard.

process -Specifies the process to be executed. If the process starts with the ‘+’ character, init will not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing their own utmp/wtmp housekeeping (a historic bug).

]]> http://vayavyalabs.com/blog/?feed=rss2&p=19 1 Embedded C language http://vayavyalabs.com/blog/?p=13 http://vayavyalabs.com/blog/?p=13#comments Mon, 16 Feb 2009 04:45:39 +0000 Administrator http://vayavyalabs.com/blog/?p=13 A topic of debate about the phrase, “Do you work on Embedded C language?”.

I belong to the category who say there is nothing called Embedded C language, but C language for Embedded Systems. C language used for programming on embedded systems would need using the language in a smart way.

  1. Bit manipulations.
  2. Pointer Arithmetic.
  3. Usage of volatile, const, extern, …. etc
  4. cod optimizations of written code

The following link is a good one which has some basic questions about “C for Embedded”:
http://www.embedded.com/2000/0005/0005feat2.htm

Stay tuned for more posts…

Posted by : Someshwar D.

]]> http://vayavyalabs.com/blog/?feed=rss2&p=13 2