It may be possible to boot directly into Linux at some point in the future by replacing or reprogramming a device's ROM. This will be a difficult goal to achieve for an existing WinCE device, and may not ever be practical, so for now, Linux CE will be started from WinCE by way of a bootloader application.
Brad LaRonde has taken over devlopement of the Linux-specific bootloader. He has named the product of his efforts CyaCE, and you can find all about it here. It can load and execute an elf executable in kernel mode. Note that you'll need to add a line 'append=root=<device>' to cyacecfg.txt in order to mount root properly, where <device> it the root device such as /dev/ram0 (for ramdisk), or /dev/hda2 for second partition of a CompactFlash card (if CF card is set up as primary IDE IO address), or whatever.
CyaCE was based on Steve Hill's work on LoadLCE. You can find a description of Steve's work here.
LoadLCE, in turn, was based on a bootloader for NetBSD/hpcmips, which is available here.
One thing to bear in mind with all of these bootloaders is that they have to load the kernel image into "program memory," even if it's already in the "storage memory" section of your WinCE device. With a large kernel binary, I find that sometimes I have to shrink and grow the amount of memory allocated to "program memory" in order to get it to fit properly. You can do this from Start->Settings->System->Memory from within WinCE. If you don't have enough free memory, close some WinCE apps in Start->Settings->System->Task Manager, delete some files, and if all else fails, reset your WinCE device. Booting a real Linux kernel will wipe out all your WinCE data anyway, so you might as well get rid of it. Of course, back up your data first if you need to keep it.
NOTE: This section is of mostly historical interest. These applications are only useful to developers attempting to bootstrap kerenl development on a new CPU architecture or platform.
Here are some simple standalone programs for NEC VR41xx-based WinCE devices that demonstrate how the bootloader works and how the kernel is linked. These are not normal Linux apps, and are mostly useful only for bootloader and kernel debugging. They won't work on other MIPS parts, and also won't work on the VR4100 or VR4101 CPUs, due to differences in the serial registers.
They were linked as 32-bit little endian MIPS elf with the MIPS link script from the Linux kernel sources. I have only tested the binaries with the NetBSD/hpcmips bootloader on an Everex Freestyle A-10. Special binaries are also available for the Vadem Clio (thanks to Brad LaRonde for testing, and working through the process of narrowing down the correct GPIO line). Apparently, some devices (like the Clio) are using GPIO lines to enable/disable power to the serial transceiver, so those devices will require the correct GPIO to be set on (or off) to enable the serial port. This is pretty important to identify, since the kernel will probably first be brought up with console on the serial port.
WARNING! WARNING! WARNING! Running the following programs may corrupt the RAM on your WinCE device and cause you to loose stored data. Make sure to synch any important data with your desktop, and proceed at your own risk.
A simple application to test the serial communications (output only). A basic test to ensure that the bootloader and link script are functioning properly.
UPDATE (14-Aug-99): There was a bug in the Clio support due to a typo. The source is now fixed.
The serial port settings are hard-coded to 9600 baud, 8N1, no flow control.
A MIPS GDB stub for remote debugging. This was hacked together from several files in the Linux kernel source, and does not handle exceptions at present, so it cannot do breakpoints. It is somewhat useful for poking around, though.
The baud rate is hard-coded to 115200. To set that speed under Linux, you may have to use setserial to fake out the 38400 setting:
setserial /dev/ttyS0 spd_vhi
The gdb cross-debugger binary was built from the SuSE 6.1 gdb SRPM, but the stock gdb sources compiled fine without SuSE's patch. It does seem to insist on assuming the CPU is big endian, but that can be changed within gdb by issuing a 'set endian little' command.