DGOS

source

2012-01-22T14:10:00.001-08:00

I simply haven't the time to work on DGOS anymore, sadly. If anyone is actually interested I can disclose the source.

Current state:

kernel
- Multithreading & Multitasking
- Protected memory
- Code pages can be shared between processes
- Support for kernel modules, including loading and unloading
- Drivers for some hardware: HDD, flash, ram, timers, display, sound, touch
- support for userspace applications & libraries
- ARMv4 & ARMv5 support, including emulation of some v5 instructions under v4
- Pluggable VFS & block device layer with NAND support

Userspace
- Heap code to support allocation & memory management
- Ability to load dynamic libraries in ELF format
- Currently posted libraries
  - libjpeg
  - libpng
  - zlib
- New libraries:
  - GfxLib: load images in jpeg & png formats, show semitransparent layers onscreen, etc
  - RtLib: runtime for DGOS (VFS calls, other syscalls)

PalmOS loader to run DGOS from inside palmOS

Work to do: wifi drivers (can wrap palmos ones), finish palmos compatibility layer, etc...

why DGOS?

2010-10-13T22:07:00.000-07:00

I get it. people have moved on form palm devices and nobody cares. why go on? mostly because i want to, but also because palm hardware is quite capable still. i have a friend help me on some stuff now, to make things a bit faster. does anyone care still?

Android?

2010-08-24T16:00:00.001-07:00

While playing around with Linux I accidentally made Android work on Palms. Is this of value to anyone?

UPDATE: "first success"

not dead

2010-06-20T21:42:00.001-07:00

i promise this isn't dead. i still work on this. font rendering is still a huge pain in the ass! :)

where i've been

2010-06-04T00:59:00.001-07:00

WHY haven't I updated the blog?
I've been working hard on this: http://www.kno.com

lack of time

2010-03-23T22:55:00.001-07:00

working in a startup, i have very little time lately, sadly.

still working on this once in a while though...

Meh

2010-03-02T01:50:00.001-08:00

My messing around with FAT code broke fat12...fixing it

FAT

2010-02-22T01:46:00.000-08:00

did some optimizations on fat code. it is much faster now :)
also it's been converted into a proper module instead of the weird half-module state it's been in

UI 2

2010-02-16T23:54:00.000-08:00

Who knew photoshopping many small images could be so time consuming. I created the 45 images today that make up all the images needed for buttons (button is 9 images, and there are 5 states: on off disabled, focused, focused&on)

Anyone want to take over the graphic design?

UI :)

2010-02-16T02:05:00.000-08:00

Just a small photo before i go to bed. I finally got around to drawing up the UI images so now a simple form can render :)

Note the subtle shadow. The ui is composed of PNG images with alpha blending. This means that ALL of the UI can be semi-transparent and have pretty shadows.

The final compositing is done by GfxLib's GfxLibLayer class.

Much much more UI shots soon... (as soon as I draw the other UI elements)

Freetype

2010-02-14T23:54:00.001-08:00

...is a pain in the rear...

fonts

2010-02-05T01:59:00.000-08:00

porting FreeType...

T|E2 NAND chip & general project status

2010-02-03T00:08:00.003-08:00

TE|2's NAND chip was connected in a rather weird way, but I made it work. TX's partition manager reads its partitions just fine too :)

I've been posting less statuses since I've been somewhat occupied with someone :) and thus have less time to code.

Also, expect to see a little UI demo soon

PXA270 USB

2010-01-22T00:51:00.001-08:00

I wish nothing but pain on the designers and implementers of the PXA270 USB gadget module. This thing has more bugs than features!

TX USB

2010-01-21T01:09:00.001-08:00

TX USB is showing signs of life. Mass storage, here we come

join?

2010-01-13T23:23:00.000-08:00

anyone want to help develop DGOS? ;-)

TxFFS driver

2010-01-03T23:36:00.001-08:00

The driver is done, and I am not quite sure why it isn't exactly working, but I feel I am close. The format my driver produces looks very much like TX's format, but not quite.

T|X internal storage

2009-12-27T12:30:00.000-08:00

TX internal storage is a NAND flash chip. This is difficult for a few reasons, mostly, because NAND needs wear-leveling, and special filesystems, neither of which is standardized. There isn't even a standard way to lay out a partition table! Thus to get TX internal storage to work there are three components to be created: BlockDevice driver to talk to the NAND chip, PartitionManager plugin to figure out the partitions on the device, and filesystem driver for the FS used in the TX (something called "BFFS").

I am happy to report that the first two pats are complete and working. The third is harder, however I've had some help from a programmer in China (irc handle tech_junkie_chz_5481), who seems to know a lot about this BFFS and has helped me craft a driver for it all in one night. The testing is going to start soon.

PS: Hello from Buenos Aires!

UiLib

2009-12-17T22:34:00.000-08:00

Did some work on UiLib and various UI components.

Now off to a 2-week vacation :)

E2 final update

2009-12-16T03:55:00.001-08:00

T|E2 now boot reliably into DGOS. Now i will go back to userspace work.

T|E2

2009-12-13T13:28:00.000-08:00

T|E2's processor is a generation older then TX's and LD's (and htu slacks some features DGOS kernel uses), but the kernel comes up (somewhat) on it. Will work today on making that 100%

TX NAND further updates

2009-12-12T03:41:00.000-08:00

TX NAND speaks to me just fine, AND i am able to parse palm's strange partition table, ECC codes, as well as bad block chains. Next: parsing their filesystem used on the TX: It's called "blunk flash file system" and getting an official copy of the spec for it costs $15,000

TX NAND speaketh...

2009-12-11T01:52:00.000-08:00

...and it says CE F1 80 15

[for those who have no idea what that means - the TX internal storage driver had been started, and just successfully spoke to the flash chip. Those numbers are the chip's ID number]

Update

2009-12-10T01:13:00.001-08:00

My new job is getting me into habit of daily status updates, so here goes :).

LD usb driver still being stubborn, TX internal memory chip can be read/written/erased, but data is still somewhat cryptic, next demo will demonstrate a functionality like CardExport, but under DGOS on an LD, and the one after that will be a TX demo. Lots of work needs to be done on the UI, and I welcome all takers, who want to make an effort to develop/help with the UI design/programming (I am just one man, working an average of 45 minutes a day on this, afterall)

Small update

2009-12-08T02:20:00.000-08:00

A small but important bug was fixed in module makefiles, and lifedrive USB driver has been split off into its own module, and some more work was done on it. now it's maybe 60% done :)

Look for more updates soon.

GfxLib transparency works well

2009-12-07T02:17:00.000-08:00

A small video. Shows two semitransparent layers interacting using GfxLib. Also shown is the boot process. Enjoy.

The quickly-written and messy source code to this simple test app is as follows:

#include <kTypes.h>
#include <errors.h>
#include <RtLib.h>
#include <GfxLib.h>



static char __x[128];
#define printf(...)   do{sprintf(__x,__VA_ARGS__);_DGOS_DEBUG_TMP_printStr(__x);}while(0)
#define perr(...)   do{printf(__VA_ARGS__); while(1) SchedYield();}while(0)

int _start(){
   
   GfxImage* i;
   GfxLayer* L;
   GfxLayer* L2;
   UInt32 iw, ih, sw = 324, sh = 484;
   Int32 x = 0, y = 0, dx = 1, dy = 1;
   UInt16* d;
   Err e;
   
   printf("TEST RUNNING\n");
   
   if(!GfxLayersInit(GFX_LIB_ROTATION_NORMAL)){
      perr("cannot init GfxLayers\n");
   }
   
   printf("setting color\n");
   GfxLayersSetBackground(GfxColorMakeRGB(192,255,192));
   
   printf("creating layer\n");
   L2 = GfxLayerCreate(0, 0, 324, 484);
   if(!L2) perr("cannot create layer with bg\n");

   
   printf("calculating layer\n");
   printf("L=0x%08x\n", L2);
   printf("I=0x%08x\n", GfxLayerGetImage(L2));
   printf("D=0x%08x\n", GfxImageGetData(GfxLayerGetImage(L2)));
   printf("A=0x%08x\n", GfxImageGetAlpha(GfxLayerGetImage(L2)));
   
   d = GfxImageGetData(GfxLayerGetImage(L2));
   MemSet(GfxImageGetAlpha(GfxLayerGetImage(L2)), 324*484, 0xFF);

   for(y = 0; y < 484; y++){
      for(x = 0; x < 324; x++){
         UInt32 r,g,b;
         
         r = y * 256 / 484;
         g = y * 256 / 484;
         b = y * 256 / 484;
         
         r = ((r * x) + (256 * (323 - x))) / 323;
         g = ((256 * x) + (g * (323 - x))) / 323;
         
         
         *d++ = (((y / 10) & 1) == ((x / 10) & 1)) ? \
                  GfxColorMakeRGB(r,g,b) : \
                  GfxColorMakeRGB(0,0,b);
      }
   }
   
   printf("drawing layer\n");
   GfxLayerRedraw(L2);
   
   
   printf("loading img\n");
   
   e = GfxLibLoadPng(3,L"/test.png", &i, false);
   if(e) perr("cannot load image: 0x%04x\n",e);
   
   GfxImageGetDimensions(i, &iw, &ih);

   printf("img is %dx%d\n",iw,ih);
   
   L = GfxLayerCreateWithImage(0, 0, i);
   if(!L) perr("cannot create layer with image\n");


   x = 0;
   y = 0;

   while(1){
      
      x += dx;
      y += dy;
      
      if((x + iw >= sw) || x <0){
         dx = -dx;
         x += 2 * dx;
      }
      if((y + ih >= sh) || y < 0){
         dy = -dy;
         y += 2 * dy;
      }
      
      GfxLayerSetLocation(L, x, y);
   }

   while(1) SchedYield();   //idle well
}

Demo Time?

2009-12-02T00:03:00.000-08:00

Perhaps it's time for a small demo? Perhaps a video of the boot process on an LD or a TX? Or maybe a small demo of a simple doodling app. While hardly impressive by itself, both of these build on an entirely new OS, which makes them impressive.

Or perhaps wait till the UI lib is finished, and a new semi-transparent UI can be demoed as well?

Or perhaps both?

What do you think. Comment to reply.

[currently LD is the most supported device, with TX close behind given that it is so similar. T|E2 was tested a few times and worked reasonably well, to some extent, but lately it doesn't. I think my new scheduler code is to blame. I'll look inot it later.]

on GfxLib and alpha-blending

2009-11-27T23:50:00.000-08:00

GfxLib has seen some new code added to it. This is the general graphics library for the OS, providing basic drawing (like lines and rectangles), as well as advanced drawing (alpha-blended images). The alpha-blending code exists in multiple versions ,to take advantage of different processors. The "generic C" version can pull off 15 frames per second on alpha-blending a fullscreen image on 324x484 resolution. This version will run on any ARM processor ever used in Palm devices. The "fast" version requires a ARMv5 processor (like one in iQue, Zodiac) and can pull off 21 frames per second on the same fullscreen alpha-blended image. The "WMMX" version requires an XScale CPU (like one in LifeDrive, TX) and uses Intel's WMMX (their MMX for mobile) and is twice as fast as the "genereic C" version, managing a whopping 30 frames per second on fullscreen alpha-blending test.

These FPS numbers may seem low, but remember that (1) it is rare to redraw the fullscreen, generally only the changed area needs redrawing, (2) these might become faster as I optimize them more (3) comparing to more modern hardware is pointless, since almost all modern hardware has graphics acceleration chips and PalmOS devices do not (with the exception of the Zodiac, but I am not supporting it anyways for now)

For the technically curious: C version processes one pixel at a time. ARMv5 version processes two pixels at a time, using the "Enhanced DSP instructions" that this architecture provides (SMUL<x><y> and SMLA<x><y>) to do the parallel multiplication. The WMMX version processes four pixels at a time and makes heavy use of WMMX instructions (TBCST, WLDR, WSTR, WUNPACKEL, WSUB, WAND, WOR, WSLL, WSLR, WMUL, WMAC) to do parallel processing of al four pixels.

Also a rather large (9%) speedup was attained by strategically placed "PLD" instructions, that instruct the D-cache to pre-load data into the cache.

PalmOS-based loader

2009-11-22T12:22:00.000-08:00

PalmOS-based loader has been rewritten and now is finished. It loads DGOS as if it was just another PalmOS app. You tap it, it evicts PalmOS from ram and loads the DGOS kernel in under a second. It even has a [somewhat] cute icon:

Simplicity

2009-11-17T17:48:00.000-08:00

Here is a simple kernel module, demonstrating how easy it is to write and build one.

kmod.c


#include <kernel.h>
#include <errors.h>
#include <timers.h>
#include <usrProcess.h>





Err kmod_main(UInt32 reason, void* data){
 
 UInt64 time = timersGetTicks64();
 
 if (reason == K_MOD_LOADED){
  
  charsPrintF("Module loaded at 0x%08lx\n", time);
 }
 else if(reason == K_MOD_UNLOADED){
  
  charsPrintF("Module unloaded at 0x%08lx\n", time);
 }
 else{
  
  charsPrintF("Module called with unknown command (0x%x,0x%08x)\n", reason, data); 
 }
 
 return errNone;
}

Makefile


LIBNAME = kmod.kmod
CC = arm-linux-elf-gcc
FLAGS = -O4 -fpic  -fshort-wchar -mthumb-interwork
SLIBS = 
DLIBS = ../KernelLib/KernelLib.lib
CCFLAGS = $(FLAGS) -I../Src/public -I../Src
LDFLAGS = $(FLAGS) -nostartfiles -nodefaultlibs -nostdlib $(DLIBS) $(SLIBS) \
          -Wl,-shared -Wl,-soname,$(LIBNAME)




kmod.kmod: kmod.o
 $(CC) kmod.o -o kmod.kmod $(LDFLAGS) -e kmod_main

kmod.o: kmod.c
 $(CC) $(CCFLAGS) -o kmod.o -c kmod.c

clean:
 rm -rf *.o kmod.kmod

funny code fragments

2009-11-16T23:25:00.000-08:00


Err elfUnload(Process* p, void* base){
 
 if(p == taskGetKernelProcess()) {
  
  Panic("ELF unload in kernel not implemented. why are you trying it anyways?");
 }

Networking

2009-11-12T22:17:00.000-08:00

Wifi chipset in lifedrive and tx is not documented. i do not plan to reverse engineeer it. I plan to run the palmos driver in a palmos container layer, and use it to talk to the wifi chip. palmos supports one raw socket per interface, thus giving me all the network access i need, and the DGOS networking stack can then use that interface to talk to the wifi chip directly.

initfs

2009-10-15T00:14:00.000-07:00

When DGOS boots, it has no filesystem or device drivers. This is a problem since the filesystem and block device drivers are modules - files on the filesystem. We are thus left with a chicken-and-egg scenario that we need the filesystem access to load modules and we need the filesystem modules to have filesystem access. This is solved using initfs. This is a simple flat filesystem in ram that has just the bare minimum modules required to bring up the filesystem and device support needed to load the rest of the system. The bootloader loads two files to RAM. The kernel and the initfs image. The kernel then uses the initfs image to load the modules needed to access the main filesystem. initfs memory is then freed, and with this new ability to read the filesystem the kernel can go on booting.

DGOS used to have a very simple initfs FS and init_blk block device in it. I decided to replace initfs with just FAT, since it is simple, and there is little harm in compiling it into the kernel. This also means that the initfs image for most devices will now contain just one module - the block device driver for SD card (or in the case of lifedrive - two: SD and HDD drivers). FAT driver will now be part of the kernel and thus doesn ot need to be a module in initfs.

Artwork [or some likeness thereof]

2009-10-14T12:18:00.000-07:00

FAT32?

2009-09-23T22:01:00.001-07:00

done

Project is alive

2009-09-07T23:17:00.000-07:00

I've been having lots of personal things to deal with lately, hence no updates here, but project is moving forward :)

FAT32.n+1

2009-08-11T18:59:00.001-07:00

Busy at work lately, so had little time to work on the FAT code, but the dir code now works well, and file code is almost done as well...

FAT32 again

2009-07-28T11:25:00.001-07:00

FAT32 work is still going on. Yes it's a pain in the ass, but it's moving. LFN code is written. FAT code is written. Just file and dir code left

FAT32

2009-07-20T13:02:00.000-07:00

FAT32 is a terrible filesystem. Fat16 and 12 are ok because the FAT is small enough to fit in memory (max 128K) so that it can be fast. FAT32 FAT can be up to 256 MB in size, and cannot be fit in memory. Since FAT32 does not feature a free cluster bitmap, finding free clusters on a moderately-filled FS can be a big pain. My FAT32 driver attempts to optimize this by creating a compressed free-cluster bitmap in memory and fills it lazily as FAT sectors are read for general use. This means that the longer one uses a FAT32 volume, the faster file creation and writes get. This is a strict improvement over most other FAT32 drivers, which start slow ad remain slow.

General Project Status

2009-07-17T12:38:00.000-07:00

I get asked a lot what the project status is, and when i can release a beta. First let me say that this question is rather pointless. No, not because I want to be cruel and keep it a secret. It's because I really do not know and have no way of knowing. I work on this in my free time, so while I can estimate the percentage completion of the project, I cannot estimate the time remaining because I do not have any hard time commitment to this project.

That being said, it is also worthwhile to point out that normally a whole modern OS (even a simple one) is work for hundreds of engineers and a year or two of work, while I am just one guy and working in my free time.

The heart of any OS is the kernel. It provides memory, scheduling, storage, and arbitration of other resources. DGOS kernel is written from the ground up by me over the last few months. IT provides full protected-memory processes with multitasking and support for multiple hardware storage and filesystem drivers. It has a plugin architecture, which functions in a way not unlike the way microsoft windows drivers work. The kernel works, and I do not forsee much more work in it coming up, since all new things will be loadable kernel plugins, and not work on the kernel itself. The kernel is written in C and arm assembly and is compiled by the metrowerks codewarrior compiler. All plugins have to be compiled by GCC. (There is no support in CodeWarrior to produce working plugins, though with enough effort, it can be done)

Close to the kernel are the drivers. They provide various services and methods to work with hardware. DGOS kernel currently best supports the PXA270 processor (such as the one in a Palm LifeDrive). There are drivers for timers, real time clock, LCD, sound and touchscreen, the notification LEDs, the built-in hard disk, and the SD card. This, of course, leaves out WiFi, Bluetooth, and USB. Work on USB is ongoing, and WiFi and bluetooth will be done later or provided by PalmOS drivers wrapped in special DGOS wrappers (not unlike ndiswrapper does on linux). Currently written drivers are in the kernel, all future ones will be loadable plugins.

Above the kernel sits RtLib. It's the userspace library that wraps the usually-strangely-called system calls into ARM-EABI compatible function calls, as well as providing basinc runtime services like heap management. You can read all about it in a recent post about RtLib => [here] <= . RtLib is still being written, but it already provides many useable things, and simple apps have run on top of it.

Userspace apps run on top of RtLib and may use any number of other libraries, as they wish. Currently two uch libraries exist. The DGOS port of jpeglib (which is interesting in that it required no code changes and built form the original source just fine, and ran) and GfxLib (which is a simple library that currently provides abilities to draw rectangles, lines, circles, and a very very simple fixed-width font). In the future it will probably be expanded slightly, but in general it's expected to be the basic simple drawing library.

The UI will be provided by UiLib, which still needs to be written. Luckily this is not a huge effort, since a lot of SkinUI code can (and will) be reused for it.

PalmOS compatibility will be provided by an application whose job will be to

Provide a full R9-table of functions that NAtive PalmOS apps need
Host such apps and handle their hardware accesses in appropriate ways
Parse and access PalmOS's data structures on disk, so that PalmOS and DGOS can share PalmOS files(reboot into PalmOS and your datebook has the entries you just added in DGOS
Allow Palm's PACE to run, or implement DGOS's own version of PACE
Provide access to things like network and expansion cards

Of course no OS is complete without its own userspace apps, and an SDK. The SDK is hard since putting one together is a monumental task. Luckily for DGOS this is not hard, since almost any linux library will run on DGOS is recompiled for it. Of course the UI toolkit will be different, BUT to PalmOS programmers the UI apiw ill be familiar and simple, so the SDK will be a mix of linux standard APIs and PalmOS UI apis, with a mix-in of user-requested features I choose to implement.

So so summarize, the project is doing well, and there is a chance of a release of something of interest to developers (but likely not to final users yet) really soon.

FAT32

2009-07-14T09:04:00.001-07:00

the fat32 library i had apparently is more worthless than i had imagined, and i had pointlessly spent time outfitting it with LFN support. Writing a new one now

On Architecture: RtLib

2009-07-13T22:40:00.000-07:00

RtLib is the main runtime library that all apps will dynamically link against. While it is technically possible to write a DGOS app that does not use RtLib, it's needlessly complicated and pointless(One would have to do manual heap management, manually initialize all libraries, manually get and parse app params, manually make systemcalls, and not use any delay-loaded dynamic libraries). It provides useful things like

Runtime functions needed for support of float and double types (no need for each app to have a local copy and waste memory on it)
Systemcall wrappers (like VfsFileOpen or GetCurTid)
Memory management (like malloc, free, and realloc)
Other commonly useful things (like CreateThread or CreateProcess)
Manual library management(RtLibLibLoad, RtLibLibUnload, RtLibLibFindSym)
Syncronization primitives (like mutexes, semaphores, mailboxes, events, and request queues)
Startup code (init libraries, init heap, allow libraries to self-initialize, get app command and parameter block from the kernel, find main(), call main() )

It is currently my intention to make RtLib open source, just like all other non-kernel pieces of the OS.
Just like all non-kernel components of the OS, RtLib is compiled using the arm-elf-gcc toolchain (I use version 4.2.3). As a sidenote, the kernel is compiled using CodeWarrior, but all loadable kernel modules will be written using GCC as well.

Work Continues

2009-07-12T09:55:00.003-07:00

I'm back from my vacation, and work goes on. Now will be doing some RtLib work for app startup.

Module Loader.3

2009-06-25T02:06:00.001-07:00

Unloading stuff works too :)

Module Loader.2

2009-06-24T01:35:00.000-07:00

Just did some testing and bug fixing. Module loader works as expected. Here's some technical info.

Each process has a list of loaded modules in it, including a reference count. When module A depends on module B, and A is loaded B is loaded automatically. If it was already a loaded (perhaps an already-loaded module C depended on it), its reference count gets incremented. This all assures that when all modules depending on a certain module are unloaded, it can as well be unloaded, so as to free up the address space it takes up. The per-process module list is just a linked list, containing base address, module name (not path), and a pointer to the system-global list.

The system-global module list is what enables memory sharing of code and read-only data between processes loading the same module. It is a hashtable, indexed by a hash of the PATH of the module. This means that process A can load library A version X from path Y ad process B can load library A version Z from path T and they will not collide. The global table entries also have reference count, but this is per-process. This means that if 2 processes load module A, it's ref count in global table will be 2. If one process loads the module 5 times, the global reference count will still be 1. In any case the point is that when no more processes have a module loaded, we can evict it from memory, and free it up.

Module Loader

2009-06-23T13:59:00.000-07:00

Module loader appears to be complete. It now shared code and rodata pages between processes, and r/w data is shared using COW pages. This significantly reduces use of physical memory and is thus good. Now work moves on to testing this, and then to pagefile code.

COW & memory sharing

2009-06-22T00:01:00.001-07:00

COW(copy on write) memory has been implemented, and I am 90% of the way there to implement code & data sharing between processes that load the same modules (thus saving valuable physical memory)

Sector Cache

2009-06-20T02:09:00.000-07:00

A simple sector cache has been added for block devices, causing a great increase in I/O throughput. :)

Debugging & USB

2009-06-17T12:43:00.000-07:00

To help me debug userspace apps, the kernel has a builtin GDB stub, that allows debugging of any app on the device using the serial port. Unfortunately my PC has no serial port and I have no USBtoSerial adapters, so I am now writing the USB driver code, so that I can debug using USB.

This should be a useful tool for all other developers too, of course.

IT WORKS!!!

2009-06-12T01:15:00.000-07:00

The kernel can now load libraries and executables, which can link dynamically to each other.

This works as expected! This is a huge step, and now work on RtLib resumes

ElfLoader works!

2009-06-11T15:28:00.000-07:00

May the man who created the Arm version of the Elf standard burn in hell! But despite his best efforts at creating the most convoluted and impossible to load binary format in the world I have written a loader for it. So far the loader can load and relocate an executable and any shared libraries it needs, including function calls between them!

ELF.3

2009-06-08T13:00:00.001-07:00

The elf loader is well on track, and the continuing work on it has helped uncover some bugs in the VAD code (which upon closer inspection were bugs in the AVL tree code that is the storage for the VAD tree)

ELF.2

2009-06-05T23:24:00.000-07:00

After spending more than 20 hours trying to do a build of gcc crosscompiler. Nothing worked. After a LOT of work, i managed to build gcc/gdb for target arm-elf, host linux-i686.

Now continuing work on the DGOS elf loader...

ELF

2009-06-05T00:57:00.000-07:00

I implementing an ELF loader for the kernel. This will allow usage of unmodified arm-elf-gcc to make DGOS apps, libraries, and kernel modules.

RtLib

2009-06-04T01:03:00.001-07:00

RtLib got a lot of work done on it, it now loads to the init process, as expected, and heap management as well as thread management work well.

Block Devices, PartitionManager, Loadable FSs/BlockDeviceDrivers

2009-06-02T02:12:00.000-07:00

Block device manager got a few fixes and improvements, including ability to notify many clients about addition/removal of devices.

Parititon manager was separated out from VFS code and is now a separate component. This makes it easier to use.

Block device drivers and filesystems can now be implemented as loadable kernel modules, which can make future support of other FSs and devices easier.

VADs, stack guards, signals, libraries

2009-05-31T00:00:00.001-07:00

VADs are now working, this means that pagefaults can now be sorted based on cause and handled thusly. Thereforw non-committed stacks now work, stack guards work, and user processes are notified of pagefaults and are given a chance to handle them.

Also some more work was done on library support, and unloading now works too, as well ask keeping track of all such actions.

usrCallback

2009-05-29T09:18:00.000-07:00

usrCallback module was just added to the kernel. It allows the kernel to call a function in a user app and get back some results, just like a normal callback, but while respecting all kernel-user boundaries.

DBF update2

2009-05-29T00:53:00.000-07:00

RtLib is now a DBF library and loads well.

DBF format and loader

2009-05-28T02:03:00.001-07:00

DBF is the binary format used by DGOS. It is simple, and almost any ARM compiler cna be made to emit it. It allows for libraries and executables that may or may not be compiler as position-independent code. All libraries and applications always have read-write access to their globals, and code is write-protected, as any good OS should so.

The kernel DBF loader code is now written and works.
RtLib work is proceeding.

Kernel fixes

2009-05-27T00:55:00.000-07:00

A few kernel bugs were fixed (a serious kernel stack corruption by a stray DMA was a fun one to track down).

The SD/SDHC/SDXC/MMC driver in the kernel now works very well, and integrated with the block device manager and the FS manager gladly mounts volumes on it.

Now back to working on RtLib

[also the GDB stub in kernel is almost complete, so debugging RtLib and user apps will be nice and easy]

AC97.2

2009-04-16T01:52:00.001-07:00

Touchscreen works very well using the new DMA driver for AC97

in fact it can even distinguish between stylus and finger press :)

AC97

2009-04-13T01:59:00.000-07:00

Got AC97 to work with DMA, so now audio works, and touchscreen data is sent to the memory without CPU involvement :). Calibration works well, and the pressure-sensitivity of the panel is used too, so instead of the plain boring (X,Y) coordinates, DGOS provides (X,Y and Z) Where Z is the force user is applying to the touchscreen. It can be used for better flow in note-taking applications for example, or for sensing finger presses for gesture analysis [finger generates bigger Z values]

Sorry for the delays

2009-03-11T16:09:00.001-07:00

Sorry for the delays

I will now dedicate a lot more time to DGOS. I also welcome any and all developers who would like to help with this effort. If you would like to help, please email me at dmitrygr@gmail.com

Updates

2009-02-10T17:50:00.001-08:00

Had a lot less time lately thanks to my work and a new hobby (rc airplanes)

Some work was done still. VFS is working and stable. Init code is being made

FAT VFS library is mostly done

2008-12-09T00:57:00.000-08:00

FAT VFS library is mostly done, and of course supports things that lack in PalmOS like correct size reporting for big volumes and file moving without a need to copy it and then delete the original (it supports FAT-only move). Also kernel threads can now easily call VFS functions directly, just like user level threads. Block device layer has received an update, and now has DlkDevV2-compliant drivers for SDHC cards, lifedrive built-in HDD, and TX's and T5's built-in NAND flash.

Work has started on RtLib rewrite. RtLib is the runtime library that all DGOS applications and Subsystems load by default. It provides user-level callable interfaces to kernel functions (things like VFS, Thread manipulation, etc). All native DGOS apps will use functions in RtLib to do what they do, and all PalmOS apps wil lcall native PalmOS api, which will be directed to PSS (PalmSubSystem) which then translates the parameters to what RtLib uses, and calls RtLib. This way the programmers who choose to code for DGOS directly do not have to be tied to PalmOS's archaic API structure.

On filesystems

2008-11-18T23:33:00.000-08:00

Some PalmOS thigns will not work on DGOS. Specifically I am talking about SlotDrivers and FsLibs. Why? Specifically because:

In DGOS, for efficiency reasons, the driver model is differet from PalmOS
Drivers are in kernel space in DGOS, so they can make very quick system calls, and admitting any PalmOS code into kernel space is a bad idea because it was never written to be even thread safe
Porting an existing driver to DGOS is not hard

Filesystems are created as a kernel module, and register themselves with the DGOS kernel using the vfsRegisterFs() function, which takes, as a parameter, a pointer to a VfsFS structure. This structure is a table of function pointers and an FS name.

The module provides this, and from then on, until it is unregistered using vfsUnregisterFs(), it can be used to mount and format filesystems.

Here it is in details:


#define VFS_OPEN_MODE_READ                  1
#define VFS_OPEN_MODE_RW                    2
#define VFS_OPEN_MODE_EXCLUSIVE             4

#define VFS_SEEK_SET                        0
#define VFS_SEEK_CUR                        1
#define VFS_SEEK_END                        2

#define FILE_ATTR_HIDDEN                    0x00000001
#define FILE_ATTR_SYSTEM                    0x00000002
#define FILE_ATTR_READONLY                  0x00000004
#define FILE_ATTR_ARCHIVE                   0x00000008

#define VFS_FS_NAME_SZ                      16

typedef Err (*VfsVolInitFn)        (void** fsData);
typedef Err (*VfsVolDeinitFn)      (void* fsData);

typedef Err (*VfsFsMountFn)        (void* fsData,UInt32 blkDev);
typedef Err (*VfsFsUnmountFn)      (void* fsData);
typedef Err (*VfsFsSizesFn)        (void* fsData,UInt64* free,UInt64* used,UInt64* total);    //in bytes
typedef Err (*VfsFsInfoFn)         (void* fsData,VfsFsInfo* info);
typedef Err (*VfsFsCreate)         (void* fsData,UInt32 blkDev);
typedef Err (*VfsFsGetLabel)       (void* fsData,wchar_t* label,UInt32* size /* in / out */);
typedef Err (*VfsFsSetLabel)       (void* fsData,const wchar_t* label);

typedef Err (*VfsFileCreateFn)     (void* fsData,const wchar_t* path);
typedef Err (*VfsFileDeleteFn)     (void* fsData,const wchar_t* path);
typedef Err (*VfsFileRenameFn)     (void* fsData,const wchar_t* oldPath,const wchar_t* newPath);        //MUST handle moving files too, not just renaming

typedef Err (*VfsFileOpenFn)       (void* fsData,const wchar_t* path,UInt32 mode,void** openFileData);
typedef Err (*VfsFileCloseFn)      (void* fsData,void* openFileData);
typedef Err (*VfsFileReadFn)       (void* fsData,void* openFileData,void* buf,UInt32 bytes,UInt32* done);
typedef Err (*VfsFileWriteFn)      (void* fsData,void* openFileData,const void* buf,UInt32 bytes,UInt32* done);
typedef Err (*VfsFileSeekFn)       (void* fsData,void* openFileData,UInt32 whence,Int32 offset);
typedef Err (*VfsFileTellFn)       (void* fsData,void* openFileData,UInt32* position);
typedef Err (*VfsFileGetAttrFn)    (void* fsData,void* openFileData,UInt32* attr);
typedef Err (*VfsFileSetAttrFn)    (void* fsData,void* openFileData,UInt32 attr);
typedef Err (*VfsFileGetDateFn)    (void* fsData,void* openFileData,UInt32* create,UInt32* mod,UInt32* access);    //null to not get
typedef Err (*VfsFileSetDateFn)    (void* fsData,void* openFileData,UInt32* create,UInt32* mod,UInt32* access);    //null to not set
typedef Err (*VfsFileGetSizeFn)    (void* fsData,void* openFileData,UInt32* sz);
typedef Err (*VfsFileSetSizeFn)    (void* fsData,void* openFileData,UInt32 sz);

typedef Err (*VfsDirCreateFn)      (void* fsData,const wchar_t* path);
typedef Err (*VfsDirDeleteFn)      (void* fsData,const wchar_t* path);
typedef Err (*VfsDirOpenFn)        (void* fsData,const wchar_t* path,void** openDirData);
typedef Err (*VfsDirCloseFn)       (void* fsData,void* openDirData);
typedef Err (*VfsDirEnumeFn)       (void* fsData,void* openDirData,UInt32* iterator,VfsDirEntry* entry);

typedef struct{
    
    wchar_t                 fsName[VFS_FS_NAME_SZ];
    
    //vol ops
    VfsVolInitFn            volInit;
    VfsVolDeinitFn          volDeinit;
    
    //FS ops
    VfsFsMountFn            fsMount;
    VfsFsUnmountFn          fsUnmount;
    VfsFsSizesFn            fsSizes;        //used,free,total
    VfsFsInfoFn             fsInfo;
    VfsFsCreate             fsCreate;       //format a disk
    VfsFsGetLabel           fsGetLabel;
    VfsFsSetLabel           fsSetLabel;
    
    //ops on unopened files
    VfsFileCreateFn         fileCreate;
    VfsFileDeleteFn         fileDelete;
    VfsFileRenameFn         fileRename;
    
    //ops on opened files
    VfsFileOpenFn           fileOpen;
    VfsFileCloseFn          fileClose;
    VfsFileReadFn           fileRead;
    VfsFileWriteFn          fileWrite;
    VfsFileSeekFn           fileSeek;
    VfsFileTellFn           fileTell;
    VfsFileGetAttrFn        fileGetAttr;
    VfsFileSetAttrFn        fileSetAttr;
    VfsFileGetDateFn        fileGetDates;
    VfsFileSetDateFn        fileSetDates;
    VfsFileGetSizeFn        fileGetSize;
    VfsFileSetSizeFn        fileSetSize;    //resize
    
    //ops on unopened dirs
    VfsDirCreateFn          dirCreate;
    VfsDirDeleteFn          dirDelete;
    
    //open on open dirs
    VfsDirOpenFn            dirOpen;
    VfsDirCloseFn           dirClose;
    VfsDirEnumeFn           dirEnumerate;
    
}VfsFS;

On the current bootloader and the boot process

2008-11-12T01:18:00.000-08:00

The current bootloader is a hack on top of the PalmPowerups bootloader as used in PowerDrive. Booting while holding down the [home] key enters it, and it waits for a FAT32-formatted card [FAT12 and 16 NOT supported] card to be inserted containing a file called "kernel" in its root folder. The reason for lack of support for FAT12 and FAT16 is that the bootloader is NOT using my FAT driver, but in fact another one, under BSD license, which only supports FAT32 (and barely so).

After th ekernel is loaded from card into ram, the bootloader jumps to it.

The kernel copies itself to a known location in ram (the start of physical ram) and jumps to itself there. Once there it enables the MMU, and caches, and sets up the memory map for itself. Kernel space on DGOS begins at 0xE0000000. All lower addresses are available for use by user applications. This will allow a lot of PalmOS apps to run unmodified, that rely on memory addresses like 0x8xxxxxxx and 0xACxxxxxx being available to them.

Once the memory space is all setup, the LCD driver re-initializes the LCD (which has been on this entire time). LCD is initialized very early to enable printing debug messages to it. After that other peripherals are brought up, like LifeDrive's internal HDD.

A few more pieces

2008-11-12T01:15:00.000-08:00

The kernel rewrite is going well.

Finished the block device manager and cache.
The RTC driver is working as well (smallest driver in the whole OS)
The FAT32 driver is also shaping up quite well.
The module manager is up and running, and thus all drivers are now separate modules (with the exception of the SDHC and the FAT32 drivers, since they are needed to read the card and thus to load further modules. This requirement will eventually go away, as the bootloader will be modified to load the default block device and default filesystem drivers into ram by itself.

Unicode

2008-11-09T14:27:00.000-08:00

System string and locale manager has been rewritten to sully support unicode. All applications will thus support unicode by default, without any need for additional code by the programmer. For legacy apps (like PalmOS) a default encoding will need to be specified since they use 8-bit characters.

filesystems

2008-11-09T01:43:00.001-08:00

i am working on implementing FAT12/16/32/exFAT support working now.

DGOS blog

2008-11-02T13:55:00.000-08:00

This blog will follow the creation of DGOS. My operating system for mobile devices. It is currently being developed on a Palm LifeDrive. I will post here interesting pieces of code, ideas, or design decisions.

Today's post shows how easy it is to drive device drivers in DGOS. This is the COMPLETE source code for the hard drive driver in the LD. Note a complete lack of synchronization primitives, or anything else. The OS handles that for the driver.

Note that the only entry point into the driver is "hddInit"
Requests and responses are handled by the "requestQ" primitive. It is smart, blocking the driver thread while waiting for requests and blocking requesting threads while waiting for responses. While this driver is single-threaded, multithreaded drivers can use it too, since this primitive is thread-safe.

#include "HDD.h"
#include "task.h"
#include "blockDev.h"
#include "requestQ.h"
#include "kHeap.h"
#include "timers.h"
#include "gpio.h"


#define MCIO0            (map[14])
#define MECR            (map[ 5])

typedef struct{
    
    UInt32*    hddBase;
    UInt32    blkDevID;
    UInt32    reqQID;
    
    char    manuf[32];
    char    prod[32];
    char    serial[32];
    
    UInt32    numBlocks;
    
}HddGlobals;

typedef struct{
    
    UInt8 err_or_features;        //addr = 1
    UInt8 numSectors;            //addr = 2
    UInt8 lba_0_7;                //addr = 3
    UInt8 lba_8_15;                //addr = 4
    UInt8 lba_16_23;            //addr = 5
    UInt8 lba_24_31;            //addr = 6
    UInt8 status_or_cmd;        //addr = 7
    
}HddCmd;

static void hddPrvReadSec(volatile void* base,UInt8* buf);
static void hddPrvWriteSec(volatile void* base,UInt8* buf);

static Err hddPrvWaitForDriveReady(volatile void* hddBase){
    
    volatile UInt8* statusField = ((volatile UInt8*)hddBase) + 0x17;
    volatile UInt8* errField     = ((volatile UInt8*)hddBase) + 0x11;
    UInt32 t,v;
    
    t = timersGetTicks();
    
    do{
        v = *statusField;
        
        if(v == 0x50){        //ready
                
            return errNone;
        }
        
    }while(timersGetTicks() - t < timersTicksPerMsec() * 500);
    
    return 0xFF00 + *errField;
}

static Err hddPrvWaitForNotBusy(volatile void* hddBase){
    
    volatile UInt8* statusField = ((volatile UInt8*)hddBase) + 0x17;
    volatile UInt8* errField     = ((volatile UInt8*)hddBase) + 0x11;
    UInt32 t,v;
    
    
    t = timersGetTicks();
    
    do{
        v = *statusField;
        
        if(v & 0x80){        //busy
            
            //nothing
        }
        else if(v & 1){        //error
            
            break;
        }
        else{
            
            return errNone;
        }
        
    }while(timersGetTicks() - t < timersTicksPerMsec() * 500);
    
    return 0xFF00 + *errField;
}

static Err hddPrvWaitForReadyForData(volatile void* hddBase){
    
    volatile UInt8* statusField = ((volatile UInt8*)hddBase) + 0x17;
    volatile UInt8* errField     = ((volatile UInt8*)hddBase) + 0x11;
    UInt32 t,v;
    
    
    t = timersGetTicks();
    
    do{
        v = *statusField;
        
        if(!(v & 0x08)){    //not ready for dat
            
            //nothing
        }
        else if(v & 1){        //error
            
            break;
        }
        else{
            
            return errNone;
        }
        
    }while(timersGetTicks() - t < timersTicksPerMsec() * 1000);
    
    return 0xFF00 + *errField;
}

static Err hddPrvCmd(volatile void* hddBase,HddCmd* cmd){
    
    volatile UInt8* p = hddBase;
    Err e;
    
    e = hddPrvWaitForDriveReady(hddBase);
    if(e) return e;
    
    p[0x11] = cmd->err_or_features;
    p[0x12] = cmd->numSectors;
    p[0x13] = cmd->lba_0_7;
    p[0x14] = cmd->lba_8_15;
    p[0x15] = cmd->lba_16_23;
    p[0x16] = cmd->lba_24_31;
    p[0x17] = cmd->status_or_cmd;
    
    e = hddPrvWaitForNotBusy(hddBase);
    
    cmd->err_or_features     = p[0x11];
    cmd->numSectors            = p[0x12];
    cmd->lba_0_7            = p[0x13];
    cmd->lba_8_15            = p[0x14];
    cmd->lba_16_23            = p[0x15];
    cmd->lba_24_31            = p[0x16];
    cmd->status_or_cmd        = p[0x17];
    
    return e;
}

static Err hddPrvCmd_read(volatile void* hddBase,HddCmd* cmd,UInt32 numSectors,UInt8* buf){
    
    volatile UInt8* p = hddBase;
    Err e;
    
    e = hddPrvWaitForDriveReady(hddBase);
    if(e) return e;
    
    p[0x11] = cmd->err_or_features;
    p[0x12] = cmd->numSectors;
    p[0x13] = cmd->lba_0_7;
    p[0x14] = cmd->lba_8_15;
    p[0x15] = cmd->lba_16_23;
    p[0x16] = cmd->lba_24_31;
    p[0x17] = cmd->status_or_cmd;
    
    
    while(numSectors--){
        
        e = hddPrvWaitForNotBusy(hddBase);
        if(e) break;
        e = hddPrvWaitForReadyForData(hddBase);
        if(e) break;
        
        hddPrvReadSec(hddBase,buf);
        
        buf += 512;
    }
    
    cmd->err_or_features     = p[0x11];
    cmd->numSectors            = p[0x12];
    cmd->lba_0_7            = p[0x13];
    cmd->lba_8_15            = p[0x14];
    cmd->lba_16_23            = p[0x15];
    cmd->lba_24_31            = p[0x16];
    cmd->status_or_cmd        = p[0x17];
    
    return e;
}

static Err hddPrvCmd_write(volatile void* hddBase,HddCmd* cmd,UInt32 numSectors,UInt8* buf){
    
    volatile UInt8* p = hddBase;
    Err e;
    
    e = hddPrvWaitForDriveReady(hddBase);
    if(e) return e;
    
    p[0x11] = cmd->err_or_features;
    p[0x12] = cmd->numSectors;
    p[0x13] = cmd->lba_0_7;
    p[0x14] = cmd->lba_8_15;
    p[0x15] = cmd->lba_16_23;
    p[0x16] = cmd->lba_24_31;
    p[0x17] = cmd->status_or_cmd;
    
    while(numSectors--){
        
        e = hddPrvWaitForNotBusy(hddBase);
        if(e) break;
        e = hddPrvWaitForReadyForData(hddBase);
        if(e) break;
        
        hddPrvWriteSec(hddBase,(UInt8*)buf);
        
        buf += 512;
    }
    
    cmd->err_or_features     = p[0x11];
    cmd->numSectors            = p[0x12];
    cmd->lba_0_7            = p[0x13];
    cmd->lba_8_15            = p[0x14];
    cmd->lba_16_23            = p[0x15];
    cmd->lba_24_31            = p[0x16];
    cmd->status_or_cmd        = p[0x17];
    
    return e;
}

//MemMove that also does a byteswap16() on each moved halfword. Useful since device identification strings are byte-swapped in response.
static asm memSwapCopy(void* dstP,void* srcP,UInt32 len){        //only even lengths please
    
    MOV R2,R2,LSR #1
    
loop:
    
    LDRB R3, [R1],#1
    LDRB R12,[R1],#1
    
    STRB R3, [R0,#1]
    STRB R12,[R0],#2
    
    SUBS R2,R2,#1
    BNE  loop
    
    BX   LR
}

Err hddPrvReadDriveID(HddGlobals* g){
    
    HddCmd cmd;
    UInt32 bufP[128];
    UInt8* buf = (UInt8*)bufP;
    UInt32 i;
    Err e;
    
    cmd.lba_24_31 = 0xE0;
    cmd.status_or_cmd = 0xEC;        //drive identify [OPTIONAL cmd]
    
    e = hddPrvCmd_read(g->hddBase,&cmd,1,buf);
    if(e) return e;
    
    MemSet(g->serial,sizeof(g->serial),0);
    memSwapCopy(g->serial,buf + 20,20);
    
    MemSet(g->manuf,sizeof(g->manuf),0);
    memSwapCopy(g->manuf,buf + 46,8);
    
    MemSet(g->prod,sizeof(g->prod),0);
    memSwapCopy(g->prod,buf + 54,31);
    
    g->numBlocks = *(UInt32*)(buf + 120);
    
    return errNone;
}

static void hddPrvDrivePower(Boolean on){
    
    gpioSetState(115,on);
}

static void hddPrvDriveReset(){
    
    gpioSetState(98,false);
    taskDelay(taskGetCurTask(),2);
    gpioSetState(98,true);
}

static void hddPrvDriveInit(HddGlobals* g){
    
    hddPrvDrivePower(true);
    taskDelay(taskGetCurTask(),2);
    hddPrvDriveReset();
    taskDelay(taskGetCurTask(),20);
    
    hddPrvReadDriveID(g);
}

static Err hddReadWriteBlocks(HddGlobals* g,UInt32 first,UInt32 num,void* bufP,UInt32* numDone,Boolean write){
    
    Err (*func)(volatile void* hddBase,HddCmd* cmd,UInt32 numSectors,UInt8* buf);
    UInt32 numSec,done = 0;
    UInt8* buf = bufP;
    HddCmd cmd;
    Err e;
    
    
    func = write?hddPrvCmd_write:hddPrvCmd_read;
    
    if(((UInt32)bufP) & 3) Panic("non-word aligned buffer address");
    
    while(num){
        
        numSec = num;
        if(numSec > 255) numSec = 255;
        
        cmd.status_or_cmd = write?0x30:0x20;
        cmd.lba_0_7 = first;
        cmd.lba_8_15 = first >> 8;
        cmd.lba_16_23 = first >> 16;
        cmd.lba_24_31 = (first >> 24) | 0xE0;
        cmd.numSectors = numSec;
        cmd.err_or_features = 0;
        
        e = func(g->hddBase,&cmd,numSec,buf);
        
        if(e){
            
            *numDone = done;
            return e;
        }
        else{
            
            buf += 512 * numSec;
            num -= numSec;
        }
    }
    
    return errNone;
}

static void hddPrvIfaceInit(HddGlobals* g){
    
    volatile UInt32* map;
    
    map = mmuMapReq(true,0x48000000,1,MAP_PERM_SYS_RW);
    if(map == MMU_INVALID_PTR) Panic("Cannot map in memory controller");
    
    MCIO0 = 0x1460D;
    MECR &=~ 2;            //no PC-cars inserted
    MECR |= 1;            //two PC-card slots
    MECR |= 2;            //PC-card(s) inserted
    
    mmuMapRel((void*)map,1);
    
    gpioSetFunc(115,0);
    gpioSetDir(115,GPIO_DIR_OUT);
    
    gpioSetFunc(98,0);
    gpioSetDir(98,GPIO_DIR_OUT);
    
}

static void* hddPrvThread(void* gP){
    
    HddGlobals* g = gP;
    BlkDevCmd* c;
    UInt32 devID,reqQID,reqH;
    char* buf;
    UInt32 theirMemH;
    
    blkDevCreate("Internal HDD",&devID,&reqQID);
    
    g->blkDevID = devID;
    g->reqQID = reqQID;
    
    hddPrvIfaceInit(g);
    hddPrvDriveInit(g);
    
    while(1){
        
        charsPrintF("getting request\n");
        
        requestQserviceGet(taskGetCurTask(),reqQID,&reqH,(void**)&c);
        
        charsPrintF("request gotten\n");
        charsPrintF("cmd=%d\n",c->cmd);
        
        c->error = errNone;
        
        switch(c->cmd){
            
            case CMD_READ_BLOCKS:
                
                buf = taskMapInTheirMem(c->data.blocks.requestingProcess,c->data.blocks.buffer,c->data.blocks.numBlocks * 512,&theirMemH);
                blkDevNotifyOp(devID,true,false);
                c->error = hddReadWriteBlocks(g,c->data.blocks.firstBlock,c->data.blocks.numBlocks,buf,&c->data.blocks.numBlocks,false);
                blkDevNotifyOp(devID,false,false);
                taskUnmapTheirMem(buf,theirMemH);
                break;
            
            case CMD_WRITE_BLOCKS:
                
                buf = taskMapInTheirMem(c->data.blocks.requestingProcess,c->data.blocks.buffer,c->data.blocks.numBlocks * 512,&theirMemH);
                blkDevNotifyOp(devID,true,true);
                c->error = hddReadWriteBlocks(g,c->data.blocks.firstBlock,c->data.blocks.numBlocks,buf,&c->data.blocks.numBlocks,true);
                blkDevNotifyOp(devID,false,true);
                taskUnmapTheirMem(buf,theirMemH);
                break;
                
            case CMD_QUERY_INFO:
                
                c->data.info.numBlocks = g->numBlocks;
                c->data.info.removable = false;
                c->data.info.inserted = true;
                c->data.info.writeable = true;
                break;
            
            case CMD_QUERY_MANUF_NAME:
                
                MemMove(c->data.manufName,g->manuf,sizeof(g->manuf));
                break;
            
            case CMD_QUERY_PROD_NAME:
                
                MemMove(c->data.prodName,g->prod,sizeof(g->prod));
                break;
            
            case CMD_QUERY_SERIAL_NUM:
                
                MemMove(c->data.serialNum,g->serial,sizeof(g->serial));
                break;
            
            default:
                
                Panic("Unknown cmd to HDD driver");
                break; 
        }
        
        requestQserviceDone(reqH);
    }
}

void hddInit(){
    
    Thread* t;
    HddGlobals* g;
    volatile UInt32* hddBase;
    
    g = kHeapAlloc(sizeof(HddGlobals));
    if(!g) Panic("Cannot alloc HDD globals");
    
    hddBase = mmuMapReq(true,0x20000000,1,MAP_PERM_SYS_RW);
    if(hddBase == MMU_INVALID_PTR) Panic("Cannot map in HDD controller");
    
    charsPrintF("hddBase=0x%08lx\n",hddBase);
    
    g->hddBase = (UInt32*)hddBase;
    
    t = taskNewKernelThread(&hddPrvThread,g,PAGE_SIZE,DEFAULT_BLOCK_DRV_PRIORITY);
    taskUnblockThread(t);
    
    charsPrintF("done\n");
}





/////////////////   ASM CODE   ////////////////////////////////

//optimzed for speed from this C code:
//void hddPrvReadSec(volatile void* base,UInt8* buf){
//    volatile UInt16* p = base;
//    UInt16* dst = (UInt16*)buf;
//    UInt32 left = 256;
//    p += 5; //point it to I/O address
//    while(left--) *dst++ = *p;
//}
//advantage is that this ASM version reads 32 bytes at once
static asm void hddPrvReadSec(volatile void* base,UInt8* buf){
    
    STMFD SP!,{R4-R11,LR}
    ADD   R0,R0,#0x10
    MOV   R12,#16
    
loop:
    
    LDRH  R2, [R0]
    LDRH  R3, [R0]
    
    LDRH  R4, [R0]
    LDRH  R5, [R0]
    
    LDRH  R6, [R0]
    LDRH  R7, [R0]
    
    LDRH  R8, [R0]
    LDRH  R9, [R0]
    
    LDRH  R10,[R0]
    LDRH  R11,[R0]
    
    ORR   R2, R2, R3, LSL #16
    ORR   R3, R4, R5, LSL #16
    ORR   R4, R6, R7, LSL #16
    ORR   R5, R8, R9, LSL #16
    ORR   R6 ,R10,R11,LSL #16
    
    LDRH  R7, [R0]
    LDRH  R8, [R0]
    
    LDRH  R9, [R0]
    LDRH  R10,[R0]
    
    LDRH  R11,[R0]
    LDRH  LR, [R0]
    
    ORR   R7, R7, R8, LSL #16
    ORR   R8, R9, R10,LSL #16
    ORR   R9, R11,LR, LSL #16
    
    STMIA R1!,{R2-R9}        //32 bytes
    
    SUBS  R12,R12,#1
    BNE   loop
    
exit:
    
    LDMFD SP!,{R4-R11,LR}
    BX    LR
}

//optimzed for speed from this C code:
//void hddPrvWriteSec(volatile void* base,UInt8* buf){
//    volatile UInt16* p = base;
//    UInt16* src = (UInt16*)buf;
//    UInt32 left = 256;
//    p += 5; //point it to I/O address
//    while(left--) *p = *src++;
//}
//advantage is that this ASM version writes 32 bytes at once
static asm void hddPrvWriteSec(volatile void* base,UInt8* buf){

    STMFD SP!,{R4-R11,LR}
    ADD   R0,R0,#0x10
    MOV   R12,#16
    
loop:
    
    LDMIA R1!,{R2-R9}        //32 bytes
    
    MOV   R10,R2, LSR #16
    MOV   R11,R3, LSR #16
    MOV   LR ,R4, LSR #16
    
    STRH  R2, [R0]
    STRH  R10,[R0]
    
    STRH  R3, [R0]
    STRH  R11,[R0]
    
    STRH  R4, [R0]
    STRH  LR, [R0]
    
    MOV   R2, R5, LSR #16
    MOV   R3, R6, LSR #16
    MOV   R4, R7, LSR #16
    MOV   R10,R8, LSR #16
    MOV   R11,R9, LSR #16
    
    STRH  R5, [R0]
    STRH  R2, [R0]
    
    STRH  R6, [R0]
    STRH  R3, [R0]
    
    STRH  R7, [R0]
    STRH  R4, [R0]
    
    STRH  R8, [R0]
    STRH  R10,[R0]
    
    STRH  R9, [R0]
    STRH  R11,[R0]
    
    SUBS  R12,R12,#1
    BNE   loop
    
exit:
    
    LDMFD SP!,{R4-R11,LR}
    BX    LR
}