Updates on Iris

Wolfgang Spraul wolfgang at qi-hardware.com
Sat Oct 31 23:36:07 EDT 2009


Bas,
wow this is a great update, thanks a lot.
I feel bad a bit because we have let you down somewhat - the Ben NanoNote
is still not shipping, the shop is not open, only a select few got samples...
Argh...
But I hope this will change very soon, work goes on every day to come out
with a high quality product.

> - The display unit is the old AUO version, which is not in the Ben.  I
>   have no datasheet of it.  Is there source code somewhere which makes

Well, good thing Qi Hardware is different, we want all datasheets of
components in our products to be open. So as you know we kicked out the AUO
LCM and replaced it with a Giantplus LCM that has an open datasheet.
I will try to see whether I can send you the AUO datasheet privately and
with some restrictions.
In parallel, I think Mirko has some Giantplus replacement screens for some
of the very early prototype recipients that still have the AUO screen,
like you. Maybe Mirko can send you a Giantplus LCM?

> So things are looking good.  If anyone is interested to help in any way,
> please let me know. :-)

Right now I think I can help best by focusing on shipping the first NanoNotes.
After that focus will shift to promote and support many software projects,
your kernel being high on my list...

Wolfgang

On Sat, Oct 31, 2009 at 10:19:29AM +0100, Bas Wijnen wrote:
> Hi,
> 
> Recently I promised to write some updates on Iris, my new
> capability-based microkernel system.  Here it is.
> 
> *** Summary ***
> 
> The kernel is mostly done; most important drivers to do are lcd and
> sound; most important task at the moment is to implement a file system
> and design a way to use it.
> 
> In the next section is a question about my LCD driver.  If you know
> something about the AUO unit, please read at least that. :-)
> 
> 
> *** Kernel and drivers ***
> 
> The kernel itself is mostly finished.  I still need to fix some details,
> and possibly one or two extra features, but that's all.  That may sound
> like the system is fully functioning, but remember that it is a
> microkernel, which means that most of the work is not done by the
> kernel.
> 
> For example, the device drivers are userspace programs.  I currently
> have drivers for the keyboard, the power button and the internal buzzer
> (a piezo-electric component connected to the output pin of PWM4; it has
> nothing to do with the sound card).  I have a very limited driver for
> the USB device controller, which allows me to initiate a reset without
> needing to replug the power.  This means that almost all the work for
> the USB device is done, but I'm only using it in a very limited way.
> 
> I'm working on an lcd driver, but it doesn't currently work.  Which
> brings me to the following:
> 
> - Warning: when booting Iris in its current state, the lcd will switch
>   on and display nonsense.  Leaving it on for a minute or so makes the
>   device unbootable for some time (probably until it cooled down).  I
>   don't know if this is harmful for the device, so don't try.
> 
> - The display unit is the old AUO version, which is not in the Ben.  I
>   have no datasheet of it.  Is there source code somewhere which makes
>   it work, that I can inspect?  If people want to look at my source
>   code, that is very welcome as well, of course.  The relevant file is:
>   http://projects.qi-hardware.com/index.php/p/iris/source/tree/master/boot-programs/lcd.ccp
>   (This pops up a "save?" dialog in the browser, because the site
>   doesn't seem to realize that it is a text file.  Can someone fix
>   that?)
> 
> 
> *** The rest of the system ***
> 
> Except drivers, there must be some programs to use the Ben.  I currently
> have a simple session manager (something which responds to "I'm a
> driver; allow me to be used" and "I need a driver, do you have one?"
> requests), and one program: a metronome.  The metronome periodically
> beeps the buzzer; the frequency and period of the beeps can be adjusted
> with the keyboard.  Not a very exciting program, but good for testing,
> and it doesn't need a working display.
> 
> 
> *** Missing features ***
> 
> At the moment, all processes (including drivers) are sent in one binary
> chunk with the kernel at boot time.  There is no support yet to run a
> new program from the system.  This is something to work on.  It isn't
> very hard in principle, but I need to have a good filesystem interface
> before I can implement it.  Once I have that, I need to change the usb
> driver to implement a file system, so I can compile programs on my host
> and run them directly on the Ben, without needing to build and transfer
> filesystem images.
> 
> When the file system is working, I want to strip most of the boot
> processes, and start with just enough to load the rest from the
> filesystem (and replacements for the boot versions as well).
> 
> 
> *** Terminal switching, or: what makes starting programs so hard? ***
> 
> The reason that starting a new program isn't a trivial task, is that I
> want to handle the "terminal" in a good way.  In order to use the
> drivers (get keyboard events, display things, make sounds),
> communication with the driver is required.  Often, such a driver can (or
> should) only be used by one process at a time.  For example, the
> keyboard should only send events to the process which is currently in
> focus.  The way X handles this is the worst possible method from a
> security standpoint: it lets the processes decide who gets the events.
> This means the user never knows if he is talking to a trusted program,
> or if there is an other program sniffing his input, for example.  So I
> don't want to use this approach.
> 
> What I do want, is a system where several processes can request the same
> driver, and the user (or a program of his choice) will decide which of
> them gets access to the driver.  There will be a set of drivers, which I
> call the "terminal", that together make up the working environment of
> the user.  The active program should have access to those drivers (if
> allowed by the user).  All other programs should not.  The complex part
> is that the active program changes with time.  When the user switches to
> a different program, the old active program should no longer be able to
> use the drivers, and the new one should.
> 
> However, in order to make programs easy to write, I want them to be able
> to assume that they are always connected with a driver.  This means that
> an emulation layer is needed, which is active when the program is not
> connected to the driver.  Properly designing this part is what makes
> starting new programs so hard.
> 
> 
> *** Conclusion ***
> 
> When the LCD driver and filesystem parts are fixed, I can start with
> "real" programs.  At first, I'm planning some simple PDA-style programs,
> such as an alarm clock and an editor for short notes.  While writing
> these, I will be designing my window system interface.
> 
> So things are looking good.  If anyone is interested to help in any way,
> please let me know. :-)
> 
> Thanks,
> Bas



> _______________________________________________
> Qi Developer Mailing List
> Mail to list (members only): developer at lists.qi-hardware.com
> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer




More information about the discussion mailing list


interactive