MIPS Development board!

The other day I found a MIPS based development board and I knew I needed one.  I have loved the MIPS instruction set for a long time.  I bought a Creator Ci20 development board, which can be found at Imagination's web store.  I have found that most of the references to this board talk about Linux or Android, but I want to do bare-metal and work with real time operating systems on this board.

One brave developer embarked on a bare-metal project, which he hopes to get back to when he can. Nicholas's posts are listed out in his blog post: The CI20 bare-metal project.  His posts are really good and a great starting point into working with this board.  This is where I will start working from, reading his posts and building from his knowledge.  Thank you very much Nicholas for your project and detailed posts.

This being said, I grabbed crosstool-ng (latest version is 1.22) and built the mips-unknown-elf tools to work with the board in a bare-metal fashion.  First you must install crosstool-ng, then you use that to automatically build your tool chain.  If you want a list of the supported tool chain samples call crosstool-ng with the list-samples command: ct-ng list-samples.  This will print out a list of all the supported tool chain configurations it knows how to build.  I knew I wanted mips-unknown-elf, so I called crosstool-ng with the following command: ct-ng mips-unknown-elf and it built a configuration for the bare metal MIPS tool chain.  Finally, you tell crosstool-ng to build the tool chain for you with the following command: ct-ng build.  I left this to go about it's business while made myself a little adapter board.

The pin out for my existing TTL Serial converter don't match the board's pin out for the dedicated UART header. I don't want to continually reconnect jumper wires from the converter to the board.

I finished this, to notice that the tool chain was completely built, I think I now love crosstool-ng!

The tool chain appears to work, gcc complained about no input files, and gdb informed me that it was compiled to target mips-unknown-elf.

I have the tool chain, adapter for my TTL Serial converter, power adapter and Ethernet cable ready, I can plug it all together and power up the board.

I still need to: 

1. Create a Bitbucket repository to store the code for this project.
2. Setup the build system.
3. Setup Doxygen to generate documentation.
4. Setup a TFTP server to allow me to boot the board off development code easily.
5. Setup scripts for build process to copy the image automatically to the TFTP location.
6. Test to make sure board will boot the image from TFTP.

Power Supply Firmware Upgrade

This weekend I decided to upgrade the firmware in my home made power supply.  I wanted to increase the stability of the voltage measurement and the response of the display.
  Oversampling the ADC is how I decided to increase the accuracy and stability of the voltage measurement.  I chose to use a new architecture, that utilizes a real time operating system.  The first RTOS that came to mind for an 8-bit microchip processor was OSA RTOS.  This is a wonderful, tiny RTOS that is meant to be used on very small processors, such as the PIC18F46K22 that is inserted into the READY for PIC board used in my power supply.  I bought the board from MikroElectronika, just for this project.  The below picture shows the power supply with the top open, you can see the READY for PIC board on the right near the back.

The firmware architecture is fairly simple, I used 3 tasks in conjunction with message passing.
The firmware entry point ( main ) sets up this architecture and then schedules all tasks, this can be seen below in the diagram.

The firmware first initializes the system, which consists of board support type operations such as LCD, ADC and Timer initialization routines.  After this, the real time operating system is initialized, and the tasks are created.  Once those steps are complete, we need to have the operating system enable all the interrupts, so that the scheduler can cycle between tasks.  Finally, we enter into an infinite loop that will schedule time for each task in turn.

The first task, is also the most complicated one.  The handle samples task, manages the ADC sampling, voltage monitor oversampling and decimation.  This task actually samples 4 different ADC channels which all point to the same signal, this decreases the number of iterations
required to calculate the voltage value to display. The task makes use of a module called voltage monitor to handle the rolling over sample and decimation process.  Once it has the decimated value, it checks to see if the message is available, and then sends the decimated sample if possible.  In the event that there is a timeout while waiting for the message, the task will yield to the operating system scheduler.  This can all be seen in the below diagram.

The second task, is the update LCD task.  The diagram for this task is found below.

As you can see from the diagram, this task simply waits until there is a message to update the LCD.
If there is a message available; it will be retrieved, the voltage will be calculated, then output buffers will be built and displayed.  Again, like the handle samples task, if the message is not available, the task will yield to the operating system scheduler.

The final task, the idle task is very simple.  This is a task I used mostly for debugging the system. However in the future, it could be used to gather real time data about the system if I add more features.  For instance, I could add PC based control of the power supply via a UART.  There would be a task added to handle the commands from the UART, I could add a command to retrieve the diagnostic data from the global status structure.  Currently, the idle task tracks operating system errors, operating system event errors, operating system messages received and sent.  The flow of the idle task can be seen in the diagram below.

You may have noticed common theme in the way the tasks behave, namely that they always yield to the operating system scheduler as soon as they can.  This promotes a fast responsive application. The task flow knows the best possible way to give control back to the operating system, so it is best to do that when possible.

As I worked on this project, I used a logic analyzer to capture start up to full task scheduling in the application.  You can see that screenshot below, if you want to see a video of me talking about the power supply and this upgrade please use this link to view the video.

Time and No Time...

I have been pretty slammed the last few weeks, I haven't had time for much of anything at all.  That being said, I am exploring Qt Creator IDE that was talked up in the C++ Pro group on LinkedIn.  It seems to be exactly what they said it was, awesome.  I haven't had any chance to sit down and work on Placement Alloc/Malloc/New system yet.  But it will eventually get implemented.  Here is the mandatory screenshot of Qt Creator with my OS project loaded...

Working IRQs and System Timer

The system timer spitting out tick counts while a for loop spits out an index. This is pretty good step as now I have ISRs and IRQs as well as a system timer.

Current Screenshot

The Bochs emulation window on the upper left shows TOS just after it has halted.
You will notice in the Enhanced Debugger window that the eax register contains the hex 0xDEADBEEF,
which is the value I return from KMain(). I wasn't very fond of Netbeans as an IDE, but I had learned how to use it out of necessity while going to college. After I disabled all of the plug ins that I didn't need, I have fallen in love with Netbeans
and its ability to help me without getting in my way. The built in subversion,diff utilities and handling of custom Makefiles stand out as awesome features in my book.

Catching up...

All this extra time I cost myself was well used in contemplation over the period of a week or so. Armed with the freshly built Bochs in debugger mode, it was a bit easier to find the problems in my previous code for TOS. My Global Descriptor Table entries were being corrupted by my kernel heap memory management code. Also, apparently I had corrupted my Interrupt Descriptor Table entries as well. I decided to redo them with more Assembly code and less C++. The C++ I did write I marked it as extern "C" so that it would be called with C style conventions. While debugging this new code to make sure it works, I was gladly presented text output showing that not only did it work, but the Interrupt Service Request Routines were firing off continually. Awesome. Back to the drawing board for the Kernel Heap memory management system.

Frustration...

Well, I became completely frustrated with Windows 7 Pro 64 Bit and it's completely horrible resource usage. Quad core processor at 2.8 GHz per processor, 8 Gigs of ram, Raid-0 System Drive and a 1 Gig NVidia Graphics card and it scores 5.x something on windows performance scale. Uselessly slow system. I replaced the operating system with Ubuntu 10.10 64-bit desktop and I have not regretted it.

Even though it made getting back to working on my OS take longer, in the end this is better. I completely rebuilt my tool set for cross compilation and rebuilt Bochs so that it included all the debugger support I need.

Hobby Projects…

So Greg and I got with a few artists and another developer and started working on making an XNA 4.0 Based game.  I had to push my hobby OS into the background for a bit now.  Finally though, I have a working setup to allow me to do both easier.  My windows development machine was moved in to my bedroom with my Mac.  I moved the Linux Development machine into my home office.  I installed Xming and VMware Player on my windows development machine to allow me to test OS development stuff.  So I can do all the XNA game development on this machine while keeping the OS development completely separate on virtual machine and dedicated box in home office. Xming is performing awesomely over gigabit Ethernet as well.

So I am using a Linux box for dev now...

This is Bochs with the internal GUI debugger enabled, Kdevelop with some source and consoles in the background. This is running on an AMD Dual Core machine with 4 Gigs of ram. Yes, it is Ubuntu as the distribution.

Cheating at cross compiler setup...

So after much failure at setting up the latest GCC / GMP/ MPFR/ MPC/Bin utilities in Mac OS X 10.5.8 via manual configuration and compilation; I gave up and found an easier setup.

Mac Ports 1.9.2, with it comes a whole host of software at the simple command of the port utility.

Setting up the cross compilers for i386 elf was as simple as typing

sudo port install i386-elf-gcc

and then for nasm as well

sudo port install nasm

So from now on, my cross compilers are located in /opt/local/bin on my Mac dev box.

That was a lot easier than trying to battle with Mac OS X's semi-crippled GCC implementation.

Bochs on Mac OS X 10.4.11 or 10.5.8

Downloaded latest bochs-2.4.5.bar.gz and attempted to get it working correctly with OS X.

Tips for compiling Bochs from sources on OS X:

./configure \
--enable-smp \
--enable-disam \
--enable-debugger \
--enable-all-optimizations \
--disable-reset-on-triple-fault \
--disable-readline \
--with-nogui \
--with-carbon \
--with-x

make all

sudo make install

This configuration worked well, now onto getting it to boot the OS Image for me.

Maybe Later I will work on getting BFE2 debugger working with Bochs as well.

Cross Compiler setup on Ubuntu 10.10 PowerPC64

Well I have been reading a lot on Operating System Development at osdev.org and a few weeks ago decided to work on my own operating system.
Here is how I build the cross compilers for development:

gnu.org is where I got the dev tools from

• Downloaded binutils-2.21.tar.bz2
• Downloaded gcc-core-4.5.2.tar.bz2
• Downloaded gcc-g++-4.5.2.tar.bz2

I got GMP, MPFR and MPC From the Ubuntu repositories via apt-get.

After I installed the requirements ( GMP, MPFR, MPC ) I followed the rest of the cross-compiler setup guide.

The following were the commands as I modified them ( not much ):

• cd ~/Downloads/binutils*
  
• export PREFIX=/usr/local/cross
• export TARGET=i586-elf
• ./configure --target=$TARGET --prefix=$PREFIX --disable-nls
• make all
• sudo make install

• cd ~/Downloads/gcc*
• export PATH=$PATH:$PREFIX/bin
• ./configure --target=$TARGET --prefix=$PREFIX --disable-nls --without-headers --enable-languages=c,c++
• make all-gcc
• sudo make install-gcc

After this is all complete, I can checkout my copy of my operating system code from the subversion server, build it and test with Bochs. It turns out that on PowerPC64 Linux I have to use QEMU, so I don't get all the nice debug output I was getting from Bochs. I guess I will have to look for another way to debug the kernel I am building.

Power Mac G5 Dual Core

Well, I now have Mac Pro Dual Core G5. I have wanted one of these since the first time I saw it in the Apple Store. I plan on turning it into my Operating System Development Machine. I am still unsure if I will load Mac OS 10.4 and use that or Ubuntu 10.10.