Isembard-OS / Blog: Recent posts

The bug from Hell

I have just isolated possibly the most confusing bug I have ever created! It is possibly the most confusing bug ever created!

The initial block of Isembard code run via u-boot on the beagleboard (all hand crafted ARM code) consists of the kernel, followed by a list of initial drivers.

The kernel consists of 128 bytes of relocation code that copies the rest of the kernel and the drivers to sensible places in physical RAM, and 7216 bytes of core code and data. The drivers are currently all less than 1000 bytes each and at this point there are only three. Total size of the file loaded into memory at boot is 8572 bytes. The final driver opens up the serial port in order to download other code.... read more

Posted by Simon Willcocks 2014-11-11 Labels: Bugs

Pin muxing and resource allocation

I'm going to write resource allocation drivers for muxed pins (physical omap35x pins which can be connected to a range of internal features).

Modules in the omap SoC can be powered down, and their clocks switched off when they are not needed. The drivers will power up the required modules, and enable any required pins, as features are requested by programs; they will power them down again if all the users of the module are released.

Posted by Simon Willcocks 2013-10-12

Speed limits

After making my previous blog entry, I realised that 250k system calls per second wasn't really acceptable, so I set out to find any bottlenecks in the process.

My biggest worry was that using the data abort mechanism to enter the kernel was flawed, and that the traditional SWI mechanism was significantly faster.

What I did find was that reading the abort address from coprocessor register 15 is extremely slow, taking the equivalent of over 30 normal instructions. I had assumed (hoped) that it would be almost like reading a processor register or, at worst, like reading a word from memory. It has to be read, however, so I modified the kernel to store the value in memory and retrieve it as necessary.... read more

Posted by Simon Willcocks 2013-04-11 Labels: timings

Some early timings

Now I've got two programs running in separate maps, one a simple UART (serial port) driver that using busy-waiting and the other a program that uses the service of the driver, I thought I'd try to work out how long it takes to make a simple inter-map call. Since there are no timers running yet, the simplest way of timing the calls is to do lots of them in a loop and output a character after every million or so, and time the frequency of the output characters.... read more

Posted by Simon Willcocks 2013-04-03

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks