wijnen at debian.org
Sat Jun 1 15:51:27 EDT 2013
Like Paul, Werner's message triggered me to write something to this list
I have some news, which I consider a breakthrough, but you probably
won't consider it all that important. ;-) However, if you want to fix a
hard to reproduce bug in Linux, read on. (Strictly speaking, I didn't
check if the bug really is in Linux, but I think I would have noticed if
it wasn't; I've read that source many times to find the solution for the
bug, and never saw it.)
What was Iris again? It's my project to write a capability-based
microkernel. Capability-based means that there is no global path for
communication; all kernel-communication (and therefore inter-process
communication) is done by invoking a capability. If you don't have a
capability to another process' receiver, you cannot communicate.
(Well, there's shared memory, but to set that up for communication you
need a capability as well.)
The Ben NanoNote is the primary target for this kernel. I hope to add
other targets when the project is mature enough that that makes sense.
The state some time ago was that I had the kernel working, and I started
writing some userspace tools to test it. Most hardware had a working
driver (keyboard, display, buzzer, SD card, limited USB; no support for
DMA or sound yet). The next thing I wanted to do was make the device
wake itself up. So I started to write a driver for the RTC module,
which can do that.
But things didn't go so well. I kept locking the device up so badly
that I had to remove the battery and USB cable, wait some time (pressing
the power button seemed to help shortening that time) before powering it
up again. I was unable to solve this for a long time, and was
demotivated by it; I didn't do any work on Iris for several months.
But now I decided to take a look again, and I found the problem. And in
fact, this problem may also happen to Linux, where it should be a very
random unreproducible bug. So it may be important information for those
who want to fix that.
The problem is the following: The RTC is a module which is quite
separate from the rest of the SoC. In particular, it continues running
when the rest is turned off (the programmer's manual calls this
"hibernation", but it's the closest to "off" you get without removing
power). Because of this, it was a logical choice of Ingenic to use this
module for wakeup of the device.
So, when the device is off, the RTC remains running and it has three
reasons to power the device on:
- The power button is pressed: power-on reset. Only possible if the
device is off.
- The reset button is pressed: similar, but also possible when the
device is on.
- Timer alarm: timed wake-up. This is what I wanted to get to work.
There are two registers which are important:
- HRCR (hibernate reset counter register), which determines how long the
power button must be active before a power-on signal is given to the
SoC core. Having a high value in here was the reason the power button
used to be so slow responding (you'd need to hold it down two seconds).
- HWFCR (hibernate wakeup filter counter register), which determines how
long the "wake-up" signal is asserted in the event of a wake-up (no
matter what source).
I had thought that the latter register was meant to allow external
hardware (which can also see this signal) which was slower than the
core, to respond to it. So I set this to 0. However, that really does
what it advertises: it asserts the line for 0 seconds, in other words,
not at all. And then the core doesn't actually boot up. The only way
to then boot the device again is by powering down long enough that
random data shows up in this register (it is not initialized
automaticaly). I have now set it to write the maximum value (0xffe0) to
it, and everything works fine, including wake-up by alarm. (I expect
the lowest value, 0x0020, to work as well, but I didn't check.)
That's it for my update. If you got this far, I hope you liked it. :-)
If you want to try it out, that is possible. Please let me know if you
need instructions (you probably do, but I'm not writing them unless
asked for, as they're changing all the time). I'd like to discuss about
features that could be added (or removed), and I welcome other people
proposing changes (with or without patches). Don't hesitate to contact
If you want to try things out, but the installation seems prohibitively
hard (I can imagine ;-) ), then just say so and I'll make it a priority
to make it easier.
One cool thing about this project is that it is about the base of the
system; choices are made here that impact everything that runs on it.
Getting it right is a great challenge, IMO. :-)
 This architecture is very nice for security, but also for usability;
it forces developers to be explicit about things. For example, if you
write a program that opens a window, it is easy to force this specific
window to be "always on top" or "start hidden" or whatever. With X, you
can achieve similar results by instructing the window manager to handle
this for you. But it's realy hard to start a program in a way that X
will know that the window opened by that program is the one you mean,
but another window opened by a different (or the same) instance of the
same program is not. That's because the way it works is that you have
to tell the window manager what the program looks like (normally through
its class or window title) and there's no reason other programs can't
have these same features.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the discussion