Iris as bootloader
Bas Wijnen
wijnen at debian.org
Mon Aug 23 17:56:19 EDT 2010
Hi,
It's been some time since I wrote about Iris. A lot has happened!
For those who are new here, or have forgotten who Iris is: she's a
microkernel (so she's not running on Linux, but instead of Linux), using
capabilities for communication. Her main feature is that she allows the
user to do what they want. In particular, if a programmer tries to
force some nonsense (such as pop-up screens, annoying sounds, "you need
to click this button before you can continue", ...) onto the user, Iris
tries to make it as easy as possible to refuse that nonsense. This is a
bit paradoxal: I'm a big supporter of free software, and don't advise
anyone to use non-free programs. Still this feature is particularly
useful for non-free programs, because with free programs you can change
their source. Ah well, Iris is going to be very user-friendly for free
software users as well. :-)
Anyway, on to the news:
- Iris can boot from nand flash. This is with a very simple custom
boot-loader, not u-boot. I'm very happy with this, because it means
that I can now use my NanoNote without a host computer. Next step is to
remove the need for the serial connection, so I can reinsert my
battery. Then I can finally use it as a portable device. :-)
- I've added functionality to boot into an other kernel. This means
Iris can be used as a boot loader. Why is that good? Because Iris is a
complete system. She can control the display, for example. It will be
possible to make her look like grub, with a menu where you can select
whether you want to boot Iris or GNU/Linux. And since Iris can be
started from USB boot mode, she can also be used to unbrick a NanoNote,
without needing the buggy nand write support of usbboot. A good boot
loader should be at most 496 kB in nand[1]. Iris easily fits in there.
- Speaking of which, I have also succeeded in writing the nand flash.
I'm planning to create an image which can be uploaded over USB, which
will provide the nand flash as a standard USB mass storage device. That
should put an end to all troubles with respect to reflashing, especially
those related to unbricking.
That's it for now. I welcome all comments, questions and feature requests.
Oh, and if someone who understands the cache can write a page about it
on the wiki, that would be great. It's behaving very strange for me.[2]
Thanks,
Bas
[1] The reason is that the nand is erased in blocks of 512 kB, and the
first 16 kB are used for the initial code which bootstraps the boot
loader. You don't want to erase and reprogram the boot loader when
changing other parts of the nand, so no other things must be in its
block(s). Using more than one block for the boot loader is a waste of
space.
[2] For booting into an other kernel, I first load the new kernel into a
contiguous region of physical memory, preceded or followed by some
copying code (depening on which way it needs to be copied). All this
happens with write-back cache enabled, in useg. Then I let the kernel
jump to the copying code (so it executes in kernel mode). That code
will copy the kernel to the physical location where it wants to be and
then jump to the entry point. kseg0 is also set to use write-back
cache. If I copy to kseg0 (0x80000000-...), it doesn't work. Flushing
the cache before jumping to the copying code doesn't help. If I copy
and jump to kseg1 (0xa0000000-...), which is always uncached, everything
works fine. When using cached code, everything works, until I try to
jump to the entry point. The copying itself works fine, and the data
does get copied. But at the entry point there is appearantly some
broken code which gives random errors (machine check exception, among
others).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20100823/1c6a1e2e/attachment.pgp>
More information about the discussion
mailing list