µnOS

http://www.miray.de/products/system.html

New port underway...

R&B

Hi there!

As bbrv announced, there is a new port on the way: The embeddable RTOS µnOS will be ported to the Pegasos platform. BTW: The name is pronounced mju:nos and means microkernel-on-nanokernel operating system.

First of all - to avoid any confusion - µnOS is not a linux derivate. It is a completely own development, initially done from scratch and today a mature RTOS with a modern architecture. Thus, there will be an own section for µnOS in the future as [Linux Distributions]->[Other] is definitely not the correct place to find µnOS at.

As a (very) short introduction to µnOS, here are its basic features:
- real-time microkernel (real microkernel = ~40 K)
- IPC driven client/server architecture
- highly portable (now to be shown with Pegasos)
- embeddable due to small footprint

More information is to be found on the Miray-Homepage and the Miray-Community-Site.

Our infodragon aliases several developers who will post here in the future. It is a synonym for a reliable source of information concerning µnOS and provides latest information on the progress accomplished on the µnOS port to Pegasos.

Thanks for posting those details.

We will be upgrading PPCZone in the weeks ahead and we will establish a Forum specifically for µnOS. It will not be confused in any way with any distribution of GNU/Linux.

R&B

The first step in porting µnOS to Pegasos is done: the 'µnOS on PPC' team announces that it is possible now to load and start the first raw binary over Ethernet on an ODW.

This may sound trivial for people who have to do with Linux and derivates, as they have many tools already available if not the whole toolchain for this. But please keep in mind that µnOS is completely original, not derived from any other project, and already runs on the x86 and XScale platforms. For those platforms the COFF is used. For the PPC platform, we have to deal with the ELF. Thus, the first step (prior to start porting) is (and since today 'was') to create a decoder tool which decodes the ELF containing the kernel etc. into a raw image that can be loaded and executed directly. OpenFirmware on Pegasos only supports loading ELF files with a fixed address base. This is not sufficient in case of loading µnOS. According to the versatility of the file format, decoding ELF is merely writing a complete linker. This is the reason why this task, easy at first sight, took some days.

The next step will be to get the Sphere microkernel (or at least parts of it) working on Pegasos. We will keep you updated on further progress.

The 'µnOS on PPC' team proudly announces that 'Sphere', the microkernel µnOS is based upon has been ported successfully and is running (almost) completely.

Over the first ten days after the last post there has been great progress by porting the Sphere microkernel to Pegasos. This is even more important as the microkernel contains a part which wraps all the code that is directly hardware dependent. It is called 'nanokernel' and contains the whole assembler code of the microkernel, apart from driver code which (as in any solid microkernel design) is run in user space, not in the kernel. So, despite driver code, the hardware related part of this port is done.

Unfortunately, there is one little issue with the 8259A interrupt controller left. We are still waiting for tech specs or information promised by Genesi/bplan for a week now. It is not possible to continue porting and testing of the parts of µnOS based upon the Sphere microkernel without proper interrupt handling. Thus, we are stuck at this point for almost a week now but we hope to hear from Genesi soon. We first have been waiting with this news as we planned to post it when the Sphere microkernel would have been ported completely. But now we did not want to let you wait any longer, but rather share the good news about the achieved progress with you.

We are really looking forward to continue work and to keep you updated about further progress. The next step will be to get the process manager of µnOS running.

That is GREAT! Please keep us all posted.

R&B

How does it compare in task switching with others OS in the same hardware?
It could be interesting once it's ported to compare it it with quark...

The 8259A is pretty common and you can find lots of information about it on the internet. Try the following:
http://www.rnix.org/doc/8259A.pdf
http://www.xs4all.nl/~ganswijk/chipdir/reg/8259.txt
http://satyap.csoft.net/8259.html

You can probably also dig through the source code of one of the many hobby OSs as this pic is very common.

Thank you for the infomative links. But information about the 8259A is not the problem. The problem is that the 8259A is designed for x86 and expects a certain behaviour of the processor (interrupt acknowledge sequence). A PPC processor does not provide this behaviour in the same manner. So, the question is: how is it done on Pegasos?

Hi guys, ...

I am not entirely sure of what you really want here, and as i keep saying the existing sample working code, either in linux, or the older openbsd release, is accesible, and you should be able to extract the needed info from there.

Basically, as i understand it, the powerpc has one pin for external interrupts, which corresponds to one interrupt vector called external. The via southbridge and its embedded 8259A interrupt controller is interfaced to that pin, and you will then get a powerpc external interrupt each time an interrupt is send to the 8259A. The interrupt vector should then easily enough investigate what happened on the 8259A for which you have the docs and act acordyingly. If you have some trouble with the powerpc interrupt vector, i invite you to consult some of the powerpc programming manual available from freescale (they will even send them to you free of charge if you ask for printed copies). The one you want is called Programing environment manual for 32bit implementations of the powerpc architecture.

There is really nothing magic about the pegasos interrupt stuff, and it doesn't differ in much from other powerpc CHRP implementations, apart that we don't have an openpic, and the code used probes the chip directly for information about level or edge for each interrupt. The interrupts are currently mapped to each device with :

$ more /proc/interrupts
CPU0
2: 0 i8259 Edge 82c59 secondary cascade
9: 19042865 i8259 Edge ohci_hcd:usb1, ohci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb4, libata, sym53c8xx, ehci_hcd:usb5, ohci1394, VIA686A, eth0, radeon@pci:0000:01:08.0
14: 544656 i8259 Edge ide0
15: 706059 i8259 Edge ide1
BAD: 0

So, you see most everything is mapped on interrupt 9, apart from the two ide channels which have 14 and 15 (instead of just one). The above is auto-probed by linux anyway.

But then, it is my believe that guys coding their own OS like you do are well aware of the above information, and i am truly baffled about what you really want

Friendly,

Sven Luther

Hello,
where is it possible to ask for manuals' prints?
Thanks,
Karel