The stock i586 kernel doesn't boot on the XO if you're using an initrd. Without an initrd, it boots (and then fails because we really kind of require an initrd in most circumstances) Using the OLPC kernel config as opposed to the Fedora config works fine. Sadly, large diff.
I'm having the same issue with the fit-pc (http://www.fit-pc.com/) which is using the same geode processor that the XO is using. The device comes with either Ubuntu or Gentoo so their kernels might shed some light on the issue.
What bootloader is the XO using?
The XO boots directly from OpenFirmware. Which should mean I should be able to better debug it.
And this is due to a bug in where OpenFirmware was putting the initrd. From my mail... > After going down a few more dead ends than I would have preferred, I've > figured out the root cause of the problems booting the Fedora kernel on > the XO. The base problem is that OFW always loads the initrd at > 0x800000 which, while it used to be okay, isn't a safe assumption with > current kernels. With the Fedora kernel images for example, this ends > up being smack in the middle of the .bss and thus things explode. > > The correct thing to do with an initrd (according to > Documentation/boot/x86/i386/boot.txt and manual verification with hpa) > is to first check the value of initrd_addr_max (0x22c) in the header of > the bzImage. initrd_addr_max is defined as the maximum safe address for > a byte of the initrd, so you want to load the ramdisk at > initrd_addr_max-len(ramdisk)+1. This then will make OFW's kernel > loading match that of all the other bootloaders used on x86. It might > also be worth checking some of the other newer things (especially the > kernel_alignment field), but I've got no indication of them causing any > problems at all right now with anything that anyone is actually doing in > practice. Mitch sent me a patch which can be put into olpc.fth temporarily and which will be in the next ofw release