Like Paul, Werner's message triggered me to write something to this list again.
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.[1] (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 me. 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. :-) Thanks, Bas [1] 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.
signature.asc
Description: Digital signature
_______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
