uClinux -- Embedded Linux/Microcontroller -- uClinux: FAQ

- The latest most up to date FAQ's and Information
(http://www.ucdot.org/)
- HOW-TO Install from Official Distribution CD
(http://www.uClinux.org/get_started/go-cd.html)
- HOW-TO Install from Source Code
(http://www.uClinux.org/get_started/go-source.html)

1.2 Top
=====
Absolutely Necessary Files:
- uC-libc
(http://www.uClinux.org/pub/uClinux/libraries/uC-libc-310899.tar.gz)
- uC-libm
(http://www.uClinux.org/pub/uClinux/libraries/uC-libm-060199.tar.bz2)
- Linux Kernel 2.0.38
(http://www.kernel.org/pub/linux/kernel/v2.0/linux-2.0.38.tar.gz)
- uClinux 2.0.38.x
(http://www.uClinux.org/pub/uClinux/uClinux-2.0.x/)

1.3 Top
=====
Browse the uClinux file repository @ http://www.uClinux.org/pub/uClinux/ for
other important utilities and tools.

2.0 -- uClinux

2.1 Top
=====
Q. I would like to upgrade to the latest version of uClinux. Where can I
find the most recent patches?

A. You can find the very latest uClinux updates at http://www.uClinux.org/pub/uClinux/uClinux-2.0.x/.
You must apply this patch against a virginal linux-2.0.38 kernel (not
the uClinux 2.0.38.x kernel). Unpack the diff file into your linux
source directory, and then apply the patch using:

patch -p1 < [patchfile_name].

2.2 Top
=====
Q. What is the default password when logging in to uClinux?

A. The default password is 'uClinux' (note the capital C), and the
username can be anything.

2.3 Top
=====
Q. How can I change the login procedure / password?

A. Modify the file login.c, which can be found in /opt/uClinux/src/init/.
The string it checks is on line 24.

2.4 Top
=====
Q. My Linux distribution won't let me install uClinux from the CD. It says,
"error: failed dependencies: libc.so.5 is needed by uC-src-0.9.1-1"

A. To install from binary RPMs on certain distributions of linux, you must
turn off dependency checking. The 'rpm -i' command should be run with
the '--nodeps' option, for each of the packages you are installing.

2.5 Top
=====
Q. Does uClinux support multitasking? What limitations are imposed by not
having a MMU?

A. uClinux absolutely DOES support multi-tasking, although there are a
few things that you must keep in mind when designing programs...

1. uClinux does not implement fork(); instead it implements vfork().
This does not mean no multitasking, it simply means that the
parent blocks until the child does exec() or exit(). You can still
get full multitasking.

2. uClinux does not have autogrow stack and no brk(). You need to use
mmap() to allocate memory (which most modern code already does).
There is a compile time option to set the stack size of a program.

3. There is no memory protection. Any program can crash another
program or the kernel. This is not a problem as long as you are
aware of it, and design your code carefully.

4. Some architectures have various code size models, depending on how
position independance is achieved.

2.6 Top
=====
Q. Does uClinux support ___________ microprocessor / microcontroller?

A. uClinux supports a wide range of architecture. For an up-to-date list
of supported hardware, see http://www.uClinux.org/ports/.
Additionally, you may want to join the uClinux mailing list to find
out about ongoing projects by our many supporters and volunteers. To
join the mailing list, send an email to majordomo@uClinux.org,
with "subscribe uClinux-dev" in the body of the message. For more
information on the uClinux mailing lists, see http://www.uClinux.org/maillist/.

2.7 Top
=====
Q. I want to run uClinux on my new board. I am not sure where to start.
Can you give me some tips?

A. Well, you are already on the right track with uClinux! It is the
world's most portable embedded operating system. We want uClinux to
be available for the broadest range of hardware, so your contributions
are always appreciated!

Now, here are some important things you ought to consider when porting.

***

There are three major levels of porting:

1) ARCHITECTURE
The most complicated situation occurs when your processor is not yet supported
by uClinux, or it differs too much from any currently supported architecture.

You will have to create a new branch:
linux/arch/

This means creating, or adapting from a different architecture, around two
dozen files. These files handle instructions specific to the CPU core. See
the existing architectures for examples of instructions that need to be
addressed.

You still need to address the following two levels.

2) PLATFORM (Note: this level is really only relevant for the m68k,
non-MMU architecture.)

In this situation, you have a processor that is already supported by an
existing linux/arch branch, but has differences that impact the kernel,
such as core variants, on-chip peripherals, and so on.

You need to create a new branch:
linux/arch//platform/

This means creating around six files for traps (i.e. entries to kernel
functions from user programs), interrupt handler dispatchers, and vector
inits.

You still have one more level to consider.

3) BOARD
In this case, your architecture closely resembles an existing platform.
However, there are minor differences affecting the kernel; for example:
the amount or kind of memory, external peripherals, and so on.

You need to create a new branch:
linux/arch//platform//

This means creating a number of files (rom.ld and crt0_rom.S, for example).

***

The PLATFORM level is relevant specifically for the Motorola 68k
Family (non-MMU processors) for two reasons. First, there are many
variants of the 68k core family that have differences in the
supervisor/user modes, the presence of Floating Point Unit (FPU),
etc. Secondly, there are about 17 boards with a 68k core (more or
less supported), so this level brings a better clarity in
linux/arch/m68knommu.

Peripherals not directly impacting the kernel at boot time are
located in the "linux/drivers/" directory. These drivers are added
to the kernel according to "CONFIG_", as specified in
"config.in" (which is architecture-specific).

Here are a few example steps to follow when porting to a new board
(in this case, a variant of the m68k model without MMU support):

First, edit your config files:
-linux/Makefile
Set the name of the architecture (ARCH=...) here
-linux/arch/m68knommu/config.in
This is the input file needed to 'make config' or 'make
xconfig'
Define at least one symbol (and the stuff around) to
identify your board and put it here:
CONFIG_.
-linux/arch/m68knommu/Boards.mk
Add here the directory name of your board

After this you're ready to 'make [x]config', which creates:
linux/include/linux/autoconf.h and
linux/.config
do not touch, but it is useful to have a look inside,
to see which symbols are defined

Find additional files to adapt by grepping on a symbol of the board you
are based on; for instance:

'find . -name "*.[chS]" -exec grep -l CONFIG_PILOT {} \;'

Also, delimit your specific code by #ifdef CONFIG_

For example, you might change the following files:
linux/arch/m68knommu/console/68328fb.c
-set a different LCD size
linux/arch/m68knommu/kernel/setup.c
-startup banner and copyrights
linux/arch/m68knommu/mm/memory.c
-modify is_in_rom() according to your memory map.
-IMPORTANT ! saves nerves with romdisk !
linux/arch/m68knommu/platform/68EZ328/ints.c
-if needed, include some default init for the ramvec vectors
linux/arch/m68knommu/platform/68EZ328//crt0_ram.S
linux/arch/m68knommu/platform/68EZ328//crt0_rom.S
-these are the startup asm instructions
(reset handler). They config the minimum required
hardware, and init the bss segment to zero
and the data segment to the rom values.
The ram version is needed if you intend to run a
ram kernel, case when you want to run uClinux
keeping the other existing os in rom. If you intend
to have uClinux alone (and have no other good reason)
make it in rom and don't waste time with ram version.

linux/arch/m68knommu/platform/68EZ328//ram.ld
linux/arch/m68knommu/platform/68EZ328//rom.ld
-You describe here your memory regions and where the
segments go

linux/drivers/block/blkmem.c
-Specify how the kernel calculates the romdisk
start location
linux/drivers/char/68328serial.c
-configure the default uart modes for the serial console

3.0 -- uCsimm

3.1 Top
=====
Q. I've uploaded an image to my uCsimm, but I want to test it before
writing it to FLASH. How can I execute an image from RAM?

A. Type the command 'goram' from the bootloader prompt. Before this will
work, you must apply a patch to your kernel, which can be found at
http://www.uClinux.org/pub/uClinux/misc/uCsimm-goramfix.tar.gz.
Then, you must configure the kernel to execute from RAM. Recompile the
kernel using 'make menuconfig' and choose 'Kernel executes from (RAM)'
from the 'Platform Dependant Setup' menu.

3.2 Top
=====
Q. What do the bootloader codes mean? (the letters that show up when you
type 'go')

A. These letters are displayed by the code in

arch/m68knommu/platform/${PLATFORM}/${BOARD}-head.S
(in your case PLATFORM=68EZ328 and BOARD=ucsimm).

Here are their meanings:

A -- finished programming all 68EZ328 registers (chip selects,
LCD controller, UART) and set up the stack pointer
B -- PLL settled down
C -- Finished moving .data from FLASH in RAM
D -- Finished zeroing out .bss
E -- Ready to call init/main.c:start_kernel()

3.3 Top
=====
Q. What is the clock speed on the uCsimm?

A. The clock speed is 16.580608 MHz. We recommend you do NOT change this.
Changing the clock speed will affect the serial port speed, the DRAM
refresh, the LCD refresh, etc. If you are concerned about power
management, you should check out the power control module (see the
DragonballEZ manual).

3.4 Top
=====
Q. What is the normal power consumption of the uCsimm?

A. The current drawn by the uCsimm varies depending on several factors:
-Whether the CPU is running or idle.
-Ethernet enabled vs. disabled (this can make quite a difference).
-Whether you soldered in the ethernet LEDs, and so on.

With CPU running, and ethernet enabled, the uCsimm will draw about 110mA.
With CPU idle, and ethernet enable, the draw is about 70mA.
When ethernet is disabled, and CPU idle, the draw is only ~10mA.

NOTE:
- This is current going into the uCgardener board.
- The CPU is running at 16.580608 MHz.
- 'CPU idle' means only standard background tasks are running.
- 'ethernet disabled' means placing the CS8900 chip into software
standby mode (doesn't send or receive).

More on power consumption:
- Immediately after reset, while in bootloader, the uCsimm draws
about 135mA. So, battery applications should use a short 'AUTOBOOT'
value. A Reboot sequence goes something like this:
RESET (or power on)
- 1 second drawing >135mA; waiting for AUTOBOOT to kick in.
- Several seconds at ~110mA while uClinux loads up
- Idle mode (waiting for login) : ~70mA
- When using batteries, avoid programming the FLASH memory.

FLASH erase: >165mA
FLASH write: >150mA
(ethernet enabled)

3.5 Top
=====
Q. How can I minimize the power consumption of the uCsimm?

A. The most significant reduction in power consumption can be obtained
by disabling the ethernet chip (putting it in 'software standby' mode).
This will lower the current draw by about 60 mA. You should also
remove the RS-232 cable, as it draws current even if no data is being
sent or received.

With a bit of hacking, it's possible to get the current draw down to
1mA.

1. The MPU can be put into DOZE mode in the idle thread. This will do
wonders for idle power draw. Right now, it only stops the CPU.

2. You can move the kernel to DRAM when it starts. This may help or
hurt; the DRAM pulls lots of power but it's in active state anyway
so it may never be powering down. The FLASH pulls ~10mA when
running.

3. The RS232 line driver chip will go into sleep mode when it does
not sense another RS232 device at the other end. The charge pump
draws some power.

4. You can shut down the MPU completely (remember to tell it to
refresh the DRAM, there is a bit somewhere for this which I
remember setting the right way...). Set the interrupt mask
to allow for it to awake on an interrupt from a Port D pin.

3.6 Top
=====
Q. I've got a uCsimm. Would it be possible to have the root filesystem on
NFS?

A. Yes! Thanks to Vladimir for testing this out. The following HOW-TO
was adapted from his post on the mailing list. Note: there is a
problem with NFS file caching. See the caveat at the end of
this HOW-TO.

***

Mounting the root filesystem on NFS:
The main obstacle is to get the command line to the linux kernel,
since it contains the necessary parameters (IP address/netmask/default gw,
NFS server, directory to mount, etc). The easiest path is to supply the
command line manually.

To do that, you edit the file arch/m68knommu/kernel/setup.c and add
the following code around the line 119 (of course, you have to replace
the addresses, directory names, etc. with yours!):

--------------------------------------------------------
if (memcmp(command_line, "Arg!", 4))
command_line[4] = '\0';

memset(command_line, 0, 4);

+ #ifdef CONFIG_ROOT_NFS
+ strcpy(command_line+4,
+ "root=/dev/nfs "
+ "nfsroot=192.168.1.1:/opt/uClinux/romdisk "
+ "nfsaddrs=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0:"
+ "board:eth0:none");
+ #endif

strcpy(saved_command_line, command_line+4);
*cmdline_p = command_line+4;

--------------------------------------------------------

After that you have to do "make config" and add the support for root
filesystem on NFS.

Then, make sure you remove the link to the ROMFS image by doing

rm -f romfs.img

in your linux directory.

After that you have to rebuild the kernel (and I would recommend you to do
make clean; make dep; make linux.bin)

Now, before you load your kernel, you have to fix the /opt/uClinux/romdisk
directory. The problem is that it doesn't have a /dev directory, but instead
has @dev, a symbolic link, which gets properly resolved by the uClinux
version of genromfs. In your case you need the real /dev.

Do the following (as root):

cd /opt/uClinux
tar cvf - dev | (cd romdisk; tar xvf -)

Now you are ready to run (provided that you exported /opt/uClinux/romdisk
directory correctly).

Load the image, login to uClinux, and at the prompt, type mount. You should
see something like the following:

# mount
/dev/root on / type nfs (rw,addr=192.168.1.1)
/dev/ram0 on /var type ext2 (rw)
proc on /proc type proc (rw)
192.168.1.1:/home/vag/uClinux on /var/mnt type nfs (rw,addr=192.168.1.1)
#

***

And now, the bad news:

There is a problem with NFS file caching that eats up all the RAM.
The more stuff you read over NFS, the more RAM is allocated for the
file cache, but never gets freed.
---------------------------------------------------------------
# free
total: used: free: shared: buffers: cached:
Mem: 1855488 876544 978944 0 262144 192512
Swap: 0 0 0
---------------------------------------------------------------

This happens right after boot. Hopefully this NFS problem will soon
be fixed.

3.7 Top
=====
Q. I'm looking for more information about the LCD controller on the uCsimm.

A. The LCD controller on the uCsimm supports up to 640x480 resolution,
with up to 4 levels of gray out of a palette of 16. Touch screen support
is available with a small amount of external circuitry. The LCD driver
shares the DRAM with the CPU. Global environment variables are provided
allowing the bootloader to initialize the LCD driver on reset. A simple
frame buffer is provided, and is easy to program.
Here is the pinout for the LCD controller:

Function Module Pin

LD0 30

LD1 29

LD2 28

LD3 27

LFLM 26

LLAP 25

LCLK 24

LACD 23

	(if the LCD controller is not used, these pins can act as I/O port C)


3.8                                     Top
=====
Q.	Can you give some examples of LCD displays that have been used
	with the uCsimm, and info on how to connect them?

A.	If you have seen the uCsimm on display at a trade show, it was probably
	driving an Epson EG9013 640x480 LCD display. For a schematic on how to
	connect the LCD to the MC68EZ328, see the following pdf file:
	http://www.uclinux.org/pub/uCsimm/application-notes/uCsimm_LCD_EG9013.pdf

	Another LCD is the Sharp LM32019T, a blue/white 320x240 QVGA display.
	Data on the Sharp LM32019 display can be found at:
	http://www.uclinux.org/pub/uCsimm/application-notes/Sharp-LM32019.pdf

	A schematic for connecting the Sharp LM32019T to the Motorola DragonBall 
	MC68EZ328 can be found at:
	http://www.uclinux.org/pub/uCsimm/application-notes/cpu328m2.jpg

	In order to use this display, you will need a connector, Molex P/N
	52044-1245, and a High Voltage inverter.

	When you get the LCD & power supply, DO NOT HOOK THEM UP until you 
	have correctly identified the polarity of the 12V supply to the High 
	Voltage Inverter.

	The GROUND connection can be identified with an Ohmmeter. There are  
	four mounting holes on the unit (2 holes and 2 slotted). One of the 
	mounting holes will have a plated-through copper land around it. This 
	is the GROUND connection (Pin 2). The other connection is the +12 volt 
	line (Pin 1).

	A 'four-wire' touch plate can be used over the LCD panel, providing 
	touchscreen support. All you need is a simple voltage biasing circuit 
	and an A/D convertor. Consult this schematic for details on the electronics. 
	The A/D sits on the SPI bus (SRXD, STXD, *TOUCH). A bit line (AXIS) is 
	used to toggle the circuitry to read from the X & Y axis of the plate, 
	and there is an optional line (*TOUCHED) is used to generate an interrupt
	from it to the MC68EZ328 processor.  
	
	Connect the touch plate to connector JP2, add +5 volts (VCC) and write 
	your own software to implement the touch plate.

LCD uCsimm power

1 S 26 LFLM

2 CP1 25 LLP

3 CP2 24 LCLK

4

5

6 D0 30 LD0

7 D1 29 LD1

8 D2 28 LD2

9 D3 27 LD3

10 VDD 5V

11 VSS GND

12 VEE 16-22V

	Plus be sure to tie pin 5 high, otherwise the display
	could be in 'shutdown' mode and nothing will appear on
	the display. You also need to properly program the uCsimm to give the LCD proper
	timings and layout.

Copyright © 1998 - 2002 D. Jeff Dionne and Michael Durrant Copyright © 2001 - 2015 Arcturus Networks Inc.
uClinux, �Clinux, uCsimm, �Csimm, uCdimm, �Cdimm, Arcturus and the logos versions are Trademarks of Arcturus Networks Inc.