porting custom OS to a 3com palm pda

Hi,

I want to load my home-brew os on a palm pda (I like the small resources on it vs. the IPAQ stuff, and used ones are cheep). I've looked over the uClinux stuff and found the memory map info I need. I also found the PalmLoader program to help me get some code into the ram when running PalmOS.

I couldn't find a driver for the buttons. Is there one? If not,it should be no big deal to reverse engineer which gpio pins they're tied to.

It appears uClinux must boot PalmOS, run a loader, and then jump to linux. Kinda cheesy, but I'm concerned it was done that way because of some technical imitation (Palm bootloader in ROM, or it's in a sector that is hw write protected, for instance). "Most" postings say the bootloader is writable. Does anyone have any info on this (only if you're sure,please)? If it isn't a problem, has anyone written a bootloader to flash? If so, I'd like to know where to find the code--it'll save me some time. Btw, if the newsgroups are correct, the models with flash are: III, IIIx, (NOT IIIe), V, Vx, plus the newer ones (I assume)--correct?

My last question. I've seen a few newsgroup articles that refer to the ability to bring up a (rommed?) bootloader in case the OS gets corrupted by "...pressing the back reset button while pressing the memo pad button..."). Is this true? If so, anyone know the protocol to get that bootloader to load an image? I doubt anyone but the developers know this, but it can't hurt to ask. :)

I know this was a long post. Thanks for your time! I appreciate it.

Jim

Hi Jim,

I would like to use the Palm as a development platform, but there seems to be little or no info available on the hardware, let alone a schematic and I asked here some time ago and got no reply. I'm using dragonball for a project and bought an Quickfire sbc from Cambridge Microprocessor Systems, (UK) because I don't have the time at present to reverse engineer the Palm hardware. For the buttons, you could buzz back the tracks to determine which port they are wired to and the early models are cheap enough now to completely disassemble / unsolder chips to reverse engineer the design if necessary.

As for the boot loader, some of the dragonball cpu's have a built in bootstrap mode in microcode which you can select via a hardware mode line and this allows downloading of images into memory via a serial port using bootstrap protocol records. This is really low level and bypasses everything, so you can always download code so long as there is ram in the system. You could either run the code in ram, or use a two stage bootstrap, with a loader and flash programming module downloaded into ram to start, which then loads the main program image into flash using s records or somesuch. There's even a few bytes of instruction buffer ram on the cpu itself, so you could in theory run a short program with no external memory. Have a look at the 328VZ docs for info on all this. The protocol looks like stripped down S records and it's fairly trivial to convert from S record to bootstrap record format. I've written a utility to do this to run under unix, but Motorola provide this for free on their website for dos / windoze boxes.

I bought a Palm recently for a few pounds and the flash and ram is in a plug in module, so another way would be to map the flash into another system's address space, then you could disassemble the code directly to see what it's doing to the hardware, ports etc, on power up init. Time consuming, but not impossible :-)...

Chris