We are happy to announce the beta release of native port of Inferno OS to Raspberry Pi.
There are some important points reached for this stage:
1. Mouse driver
2. Working wm/wm
3. Default memory split 240/16
4. A lot of small fixes and polishing
Repository: http://code.google.com/p/inferno-rpi/
So, we reached the point when we are able to package some small distribution.
It can:
1. Boot Kernel
2. Mount file system (kfs)
3. Init Usb subsystem
4. Load Keyboard driver (usb)
5. Load Ethernet driver (usb)
6. Initialize Net subsystem, obtain IP via DHCP
7. Start ndb/cs
8. Launch shell – console
It can not:
1. No mouse driver yet
2. Can not launch wm/wm (maybe due to mouse)
In Lab 19 we found a problem that kernel raises exception “Undefined instruction” and stops working. It happens on running JIT arm codes produced by Dis. Now it is time to have little review. In Lab 19 I just added sources used in 9pi for handling floating point exceptions but commented real call fpemu() – so the call fpiarm() only shifting PC to bypass the place of wrong instructions.
By looking at /libinterp/comp-arm.c it looks like that Dis Jit for Arm currently is not generating arm codes for floating point logic Read More
After the Lab 24 when we prepared the layout I took serious study of the ways to implement the ethernet driver. And I found that there is actual convergence of 2 ways of implementation that I saw in previous lab. Comparing to implementation of ethernet driver in C (ether.c, smsc.c) it is enough to have code worked up to call of kernelproxy() which just bypass control to etherusb.c – send a “bind” command into the control file and bypass as arguments usb end point files for input and output data streams.
If so Read More
This lab will be short; we will add all network modules needed for network layout and make a roadmap how to make the Raspberry Pi ethernet driver.
First have a look at other ports and inferno and find what is needed to compile with network support. Read More
We know that in Qt the models are not thread-safe – they totally depend on your implementation.
So what we may do to bypass model between threads?
Guess that we have some models which implementation we can not adjust much or can not make thread-safe.
Danger is that if some model is used somewhere (pointer to model, saved QModelIndex, etc), then when we move model object to another thread, for some resource consuming processing, Read More
Before this Lab, the only way to bypass information to our Raspberry Pi machine, was the TFTP which downloads kernel from development machine (used Mac). Because kernel also includes root filesystem, we can embed some files there to have minimal read-only filesystem which allows to run dis files and do some testing, like experimenting with USB support, etc.
Sure, there were no way to do something and keep results on storage as there is no one. In this lab we try to create a partition to have possibility to save files.
Let’s start: Read More
In previous lab we approached very close to get working Usb devices. In this lab we will try to get Usb keyboard working:
From previous lab 20 we got /dev/usb connected in our system, but what to do with it? Different systems handling usb in different ways, but Inferno and Plan9 has /dev/usb just as communication filesystem which should managed not by kernel but user-space process usbd which by communication with the file server manages the connectivity and start appropriate drivers for connected usb devices.
My first attempt was to have a look at original Inferno OS used to see possibilities to just reuse it. But looks like Plan9 own used was migrated so far from what Inferno has (if they had initial common file server names conventions). Because I took devusb.c from Plan9/bcm I also need used similar to Plan9. But I need limbo program!
Read More
Just small update:
To keep track of codebase of the Inferno OS on Raspberry Pi Labs we created the google code project to keep the repository and do other stuff related to the labs managements:
https://code.google.com/p/inferno-rpi/
All Labs-Commits:
https://code.google.com/p/inferno-rpi/source/list
To have our Inferno to communicate with external world we need to have the USB supported as most important parts including ethernet controller and keyboard are behind the USB subsystem. I had a look what parts the Inferno already had for usb support and what was implemented in 9pi. So I decided just to compile-in the Plan9 usb support as devusb.c and usbdwc.c from 9pi. Fortunately due to sharing almost same API of syscalls, the devusb is compiled perfectly and usbdwc needed just two fixes.
Still we need some additions to have the sources compatible: Read More
In previous Lab we got a screen working, but still no way to send commands into Raspberry computer. My guess that for time being it just simple enough to make the keyboard input coming from serial cable, so then I can play with Sh on raspberry and do some simple experiments onboard until I will have the Usb subsystem working and it recognize keyboard connected to RPi.
To work with input from Pl011 we should have it in non-blocking way. To do so we just make some function like pl011init() and check the serial io port for waiting bytes with timer (using addclock0link()). Take some consulting with port/devuart.c and see that for 115200 it is enough to check it every 22 ms. You may see that the programming is really simple: Read More
Before the Lab the development was going in total darkness…, um I meant using serial ftdi usb cable. But time comes to have a light screen. Amazingly it wasn’t so complicated. Yes, we just used codes from 9pi project (thanks to Richard Miller).
Our expected result is:
What is fun about Inferno OS that our CPU may not have MMU support and still we are able to port Inferno to such architecture. That’s because Inferno OS implements Dis virtual machine and all users processes are actually Dis byte-codes interpreters on JIT compiled. So address space is virtual by software layer and it is very good for portability of the system.
Anyway, still it is good to have the MMU initialized (may be needed later to work with framebuffer) and it looks simple enough to do. Read More
In the light of latest news (Snowden et all) it is very clear that all developers should really take care of safety of all communications that your application could perform. In the world of desktop application developments it is often is decided to be postponed and just use plain text protocols or so and later switch to use of SSL. Surely we should pay more attention to use ciphers when any need of QtNetwork is considered.
But what about using something different than just SSL? Let’s take a look at use of PGP in Qt Application. It is so good that there is great framework is already in place QCA (http://delta.affinix.com/qca/). All we need is just to take a look at API and find a simple way of making ciphers.
Let’s design very simple desktop application which can crypt some input text. I assume that have already installed GnuPG, generated keys, configured gpg-agent, installed and checked working pinentry-qt/pinentry-gtk(we are on linux now). Then you have installed qca and qca-gnupg
emerge --ask qca qca-gnupg
Just start Qt Creator, choose to make Qt Gui application, add to pro file a linking to qca: Read More
We are starting new season of the labs. Season 2 will be named as “Close to hardware”. And we start from important point to have clocks and timers working. But first we made a decision to make our codes close to 9pi source codes, especially assembler parts. But we found it little complicated as UReg struct on Plan 9 have r14 and link as union while Inferno has them separate. We can not change Ureg in arm/include as we would break another ports. Instead Read More
It is our 15-th Lab and it is the time came to make birth of the process Eve, run Dis virtual machine and our first Limbo program! Read More
Now we can study the C part of handling interrupts.
But before we start remember that we need to install stack pointers to appropriate modes: Read More
Time to write a code to process interrupts.
All interrupts that happens in system use the vector of interrupts (8 of them) which is located at 0xffff0000 (high memory case). This vector contains addresses that CPU should pass execution to. Read More
Inferno-Rpi boot from dos partition
Just to simplify installation I decided to put all needed files onto fat partition and bind them in init script.
So everything is much simple as all your files are on fat partition and easy accessible if you put SD into another computer to copy move etc files. No need to play with partitions and use kfs file system.
Make a SD with fat boot partition (let’s say 100MB), unzip files there and boot Rpi.
Download Link (~17MB Zip)