Update

Well the remote control idea worked! I can access the phone and get it to perform remote stuffs for me like playing a sound (so I can find the damn thing) or get it to reboot. Really, this was just a small prototype to see if it was possible so the project has been put into the depths of my subversion vault but worked pretty nicely.

Of course it was also missing things, I'd of liked to have added SSL and some kind of authentication to keep the connection secure.

Either way, I've been working on another little prototype. But until it's a bit more stable i'll continue to keep it quiet. It's not that interesting.

Also, Winamp OpenAL plugin is moving on, mostly robustness testing such as fixing memory leaks and so on.

Ideas

I've been a bit quiet recently as I've been working to get the Winamp OpenAL plugin more stable with its new features such as 3D and some initial effects.

I've also been shown something on the iPhone that lets you contact your iPhone over the internet, for example, incase it gets stolen or lost for example. It lets you make a little noise or wipe it completely.

I knocked up a little Java app that could accept a command to play a tune - but getting it on my HTC Touch Diamond wasn't so easy as I had problems finding the SDK to get it to work on the phone.

So, I switched over to Microsoft Visual Studio and am in the process for writing a nice little C++ application that will connect into my server at home every so often to report its [the phones] IP address. It'll also have a server that you can connect to and send it commands.

Luckily enough it can be tested over ActiveSync so there isn't a security issue yet but ultimately it'd need something like SSL and user auth.

But yeh, I like the idea of being able to talk to it and get it to play tunes when it gets lost. Of if it gets stolen - send me back it's GPS data! And of course a wipe command for email/contacts/data etc.

samos progression; newlib and operating system interfacing

With SAMOS nicely looping around it's probably time to find a way for programs to access the Operating System. I've already mentioned that system calls (syscalls) are implemented and work and these now need to be expanded from just Device Driver calls.

Firstly, we'll need to provide a few calls that newlib can use (for example sbrk which is called from malloc for memory allocation on the heap). It's probably worth trying to map inbyte and outbyte too so the user can do getchar and printf and it be routed through to the Operating System.

Other things we may want (other than Device Driver read/write register/memory) is the ability for an application to do something in user-mode when an interrupt is triggered.

Finally it'd be nice to have things such as TCP/IP stacks and a method of Inter-process communication (IPC). Being a microkernel the idea is what these things will all execute in user-mode - but be managed from Kernel mode. This means we'll have a services manager that can be queried - and probably abstracted - so provide a single C header/c file to do Sockets & Pipes (IPC).

For example, the application would call:

initialise_pipes();
...
procs = get_procs();
...
proc = get_proc(proc_id);
...
pipe_to_proc = create_pipe(proc);
pipe_write(pipe_to_proc, "hello", 5);

The Pipe abstraction would do something like:

initialises_pipes() {
my_service_id = samos_get_service("pipes");
}

pipe_write(pipe, data, len) {
send_service_message(my_service_id, WRITE_PIPE_ID, pipe, data, len);
}
...

The actual Pipe service might be a process that's interrupt driven:

pipe_write_intc()
{
details = get_details();
details.recv.push_data(data,len);
}

As you can see I haven't really worked through the details and this is all off the top of my head but the point is that virtually everything (except service queries) is executed in user-mode. Sure, those Services will have to request the Kernel to setup memory mappings because two (or more) processes and maybe that'd be a hard-code Operating System call so that the Operating System (rather than a Service-provided thing). This way the Operating System is in control of checking & allowing those two processes to communicate.

This is much the same way I see the Device Driver model working. Most of the device driver will be written in user-mode with register/memory read/writes as syscalls where required and control procedures (with parameters) where a time-critical process of multiple register/memory read/writes is required.

The benefit, of course, is that the OS can detect exceptions generated during user-mode driver code and disable further access to that driver. If the exception occurs in the kernel-mode driver - because the OS has no idea what's happened - the Kernel probably has to panic.

These are just my thoughts as I develop my OS without reading any other material. My intention is to do this (develop it based on my ideas, of course some will be affected by what I've used/seen) but not to copy anything and try to create something entirely new and see how well that works. Or not!

samos - pre-empting!!

Below is the startup sequence using the PSIM PowerPC simulator built into GDB. It correctly preempts and starts to execute the idle thread - which uses a System Call to write out the Serial Driver.

Of course by the time it preempts the second time something had gone wrong - hence the large amount of memory debugging.

Also, it's using newlib which is a good sign of progress. Once the preempting problem is fixed, and with the newlib C library, an ethernet/serial based serial debugger would be a next port of call. Oh and moving to Qemu or something which has an ethernet device... and an ethernet driver. Hmm... fun times!

From there - or with them statically linked - parse and load ELF images and load them in!

Anything from interrupts.c is tracing from psim.

Update:
Fixed it - update the memory management to be correct. The scheduler now loops around the idle thread!

Wooooohoo!

TARGET-PPC32: copying interrupt vectors to RAM...
KERNEL: initialising memory pool 0x0001CA90, size 0x02000000
KERNEL: initialising the scheduler...
KERNEL: initialising the kernels heap...
KERNEL: mempool at 0x0001CA90 alloc 0x00404000 at 0x0001CA90
KERNEL: initialising memory pool 0x0001CA90, size 0x00404000
KERNEL: initialising the task manager (dynamic)...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CA90
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CA9C
KERNEL: creating kernel process...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001CAA8
KERNEL: creating idle thread...
KERNEL: mempool at 0x0001CA90 alloc 0x00000220 at 0x0001CAB4
KERNEL: mempool at 0x0001CA90 alloc 0x00001000 at 0x0001CCD4
KERNEL: thread (Kernel Idle) create spb=0x0001CCD4, sps=0x00001000, sp=0x0001DCD3
KERNEL: attaching the idle thread...
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001DCD4
KERNEL: mempool at 0x0001CA90 alloc 0x00000220 at 0x0001DCE0
KERNEL: mempool at 0x0001CA90 alloc 0x00001000 at 0x0001DF00
KERNEL: thread (Kernel Scheduler) create spb=0x0001DF00, sps=0x00001000, sp=0x0001EEFF
KERNEL: mempool at 0x0001CA90 alloc 0x0000000C at 0x0001EF00
KERNEL: scheduler initialised


KERNEL: SAMOS Version 0.1
TARGET-PPC32: enabling external interrupts...
interrupts.c:464: external interrupt - cia=0x2104
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread
interrupts.c:464: external interrupt - cia=0x4cfc
interrupts.c:396: system-call interrupt - cia=0x5e70
KERNEL: idle thread

samos scheduler & syscalls

System calls are now working and the scheduler is almost there! For some reasons some static data is getting corrupted but other than that the timers are kicking in an pre-empting a procedure which does constant syscalls.

Arduino Mega

Just got my Arduino Mega in the post this morning and before popping out for the evening I did the typical hello world over the Serial connection and got some LEDs going - astonishingly easy which is always good.

Tomorrows mission is to wire up a matrix of LEDs for a Spectrum Analyser and update the Winamp Visualisation code to support the serial connection. With any luck it should be fairly easy to do, the only thing I need to really worry about is the power consumption of so many LEDs but hey ho.

Also, on the arduemu front - would it be weird to get arduemu running on a real arduino? That'd be like one of those motivational posters or something weird like that eh? I'm still trying to work through the opcodes of the arduino and it's ultamtely a question of time rather than skill - although the status flag documentation is the instruction set continues to be as helpful as a punch to the face. If you're an Arduino person and have access to sourceforge.net or an openID and want to help give me a shout!

project update(s)

SAMOS is moving along nicely and I've started reading up on the ia32 architecture and ACPI ready for a target port to the 386 based family. I've also fixed the interrupt handling on the PowerPC code and need to take another look at trigger/level driven interrupt handling on the OPIC.

Wumpus OpenAL Output for Winamp, I've been working on panning, effects, 3D and XRAM stuff and thats starting to take shape (check out the SVN) so you can pan and move the mono sources around now. Stability isn't quite there yet and I'm not sure the code is as efficent as it could be but it's all moving along nicely.

Arduemu; we've started to talk about getting development up and going again. I'll probably start working again on the opcodes of the processor fairly soon and Rich is looking to start working on stuff in a few weeks time.

So yeh, all fun 'n' games.