porting custom OS to a 3com palm pda

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View

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

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.


Re: porting custom OS to a 3com palm pda
Quoted text here. Click to load it

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 :-)...


Site Timeline