ucLinux

[DerekWilson]

I'm looking into it for embedded systems app ...

Is it easy to use/configure/taylor?

Thanks

 

[drag]

How embedded is 'embedded'?
You can read/write C code and know how to configure and compile custom kernels, right?

ucLinux is a kernel that is specificly optimized to be used on very small systems that use a CPU that do not have a memory management unit. Most modern cpus don't have this problem, even ones that are commonly used in embedded systems.

The standard kernel.org kernel can be ran on non-MMU cpus, also. So even if your not using a MMU you can still use the vanilla kernel code.

Then there are other embedded kernels that would be suitable for a controller type setup.. like RTLinux or a stripped down kernel.org kernel with realtime-preempt patches.

Probably if you still have questions the uclinux mailing list would be a good place to ask about the appropriate-ness of this kernel for your project.

Personally; I have no clue, I am no embedded developer...

 

[DerekWilson]

the application would be similar to a router, and the controller would not have an mmu.

 

[drag]

I realy don't know, unfortunately.

Personally I'd like to stick as close to the vanilla kernel.org kernel as possible. But it realy depends on amount of resources you have and the driver support for your hardware.

Their mailing list may be a better place to ask...

 

[xtknight]

The official 2.6.22 kernel has support for the Blackfin architecture (which is what is served by uCLinux). Currently Ubuntu Gutsy (~alpha) has this although that's probably a poor choice for embedded stuff, just throwing it out there.

I think what you do is transfer a kernel image over to the chip via TFTP, but I'm not completely sure how it all works.

See if your device is listed for vanilla kernel support: http://kernelnewbies.org/Linux...e73cf59509a560d791afe9

 

[drag]

I think what you do is transfer a kernel image over to the chip via TFTP, but I'm not completely sure how it all works.

It's not hard to do a netboot.

You need to have a DHCP server setup on a Linux machine with a tftpd server. It matters a lot which tftpd server you use as it's all a bit touchy. It's a bit of trial and error to find the one that works best for you. The tftpd doesn't have to be on the same server.

Then you need a machine that supports something like netboot or Intel's PXE. Nicer boards with onboard will have PXE support, otherwise most Intel nics and others will have it. Check the documentation on the device. For stuff that doesn't support PXE some have programmable EEPROMs that will help you do netboot, otherwise you can usually use a floppy...

SysLinux is a simplistic Linux booter that has lots of variations for various things. Like PXELinux for booting Linux using PXE http://syslinux.zytor.com/pxe.php

Details depend on the devices you have at hand and whatnot. I've only used x86 for doing netboot stuff and I have had good luck with both using boot floppies for el'cheapo realtech 10/100 and PXE with rather expensive Intel 10/100/1000 ethernet.

As a example for PXE it works like this:

The computer boots up. Goes through POST, pasts BIOS. The machine is configured to attempt to do the network boot.

PXE stuff kicks in, sends out a DHCP request with it's MAC address.

The DHCP server matches the MAC address with your pre-configured defaults for that machine. Tells it to download the pxelinux.0 bootloader from the specificed tftp server and executes it. The pxelinux downloads the pxelinux.cfg, finds the best matching entry for that nic card, downloads the appropriate vmlinux image and initrd image.

It executes the kernel, the kernel decompresses the initrd, runs the init script, which sets up the environment for booting (usually off of NFS).

For newer Debian systems using the initramfs initrd system it will have pre-existing nfs-boot scripts and environment you can use that make it pretty easy. I suppose they will be aviable for Ubuntu also.

Initramfs is a lot easier for me to deal with compared to earlier initrd stuff. The scripting makes sense and it's not to difficult to modify scripts from one system to run on another.

This is for things like x86 thin clients and clustering though.

This is all running from mostly memory. So it may be a bit innaccurate. The tricky part for me was the tftpd server... Sometimes they need to be reset and other times it may take a few tries to find the most compatable one. Paying attention to logs is important.


For embedded development it's going to be somewhat different. You'll probably have a nic card with a programmable eeprom to do the netboot.

Then depending on how much resources you have aviable you'll do something like...
boot a stripped down kernel with a simple shell environment built into the actual kernel for executing code from inside the kernel.
or maybe
you will run all your stuff from a tmpfs environment and never get farther then the initrd image, if you have enough ram.
or maybe
you'll do a full boot from nfs.

Lots of variations.