People you could contact if you need help

About this project

hello
i am opening this thread to ask if somebody knows about the port of uclinux to the palm 68k PDA.
from what has been written in their uclinux-web and what you can read from browsing the linux sources, it seems something code is really existing about a real physical port to this target
(even if somebody is talking about "virtual port", meaning the target is a palm emulator)

I really hacked the palm who is called "m105". I do it to force the cpu (68328, m68k family) to bootstrap with the serial bootstrap mode (a special bootstrap mode which only the 328 is provided with)

So i am able to compile a tiny c or assembly code ("hello world", "ROM dumper", and something as easy as these apps), to download and to execute it

unfortunately i have a few issues with the memory map (so with the gnu linker script) that makes me impossible to write applications bigger than 1kbyte

i wander if there is some documentation / hacks or real port of something working that could help me to fix my issues

googling i found there is a compiled uclinux image from http://palm-linux.sourceforge.net/
it use useless, it doesn't work with my m105 display (information reported to this URL is partially wrong, the m105 has no frame buffer support, i can appreciate), but it works serially: it shows me something was done, and it works, so it helps me to have HOPE about success

I emailed the uclinux mail list with still nothing answered: it seems nobody is being working for years
also all the old web materials seem to be lost: a lot of broken links

have you read something about ?
have you collaborated or worked on this project ?

it should be an interesting embedded study opportunity

About the board

First let's get into the hardware stuff. Many wonderful things can be discovered by consulting the MC68328 DragonBall ™ User's Manual. Read this cover to digital cover and you will gain endless insights on what your Pilot is capable of. Many of these capabilities are not exposed by the PalmOS so if you want 'em you'll have to be prepared to go direct. WARNING: one of the primary purposes of the PalmOS (and most operating systems) is to isolate you from the specifics of the hardware. A Pilot application that writes exclusively to the PalmOS APIs has a good chance of being fully portable to other platforms running the PalmOS (e.g., the Emulator running on the Mac, new hardware devices). Writing directly to the hardware is like playing with fire -- you might get burned as USRobotics and their licensees release new hardware, operating system upgrades, etc. Plus, since the multitasking PalmOS manages and uses much of the hardware you may be interested in playing with there's a good chance conflicts will arise with unexpected consequences. On the other hand, fire is pretty cool and so are some of the nifty DragonBall capabilities the PalmOS doesn't provide access to (yet).

Starting at address $fffff000 you can find the 68328 registers. These are not the CPU registers but a block of registers (~130 total) that control hardware functions like interrupts, parallel I/O (hey, I don't see a parallel port on my Pilot!), audio, timers, serial I/O, the LCD display, and the Real Time Clock. What these registers are do are beyond the scope of this document (and in many cases beyond the scope of my knowledge!) but I'll call out a couple here to give you an idea of what can be found.

Memory Locations

68k vectors, including traps starting at $80 for instance trap #15 at $bc point to $10c03656

00000000

00007fff

Dynamic RAM. The 68k vectors are in Dynamic RAM.

00008000

0fffffff

Faults on access attempt

10000000

10007fff

Mirror of the 00000000-00007fff range above (RO w/o permission)

10008000

1001ffff

Storage RAM on 128k machine (RO w/o permission)

10020000

1003ffff

Out of bounds but doesn't cause a fault

10040000

10bfffff

Faults on access attempt

10c00000

10c7ffff

512K ROM!

fffff000

fffffb12

DragonBall registers

Open questions

...

Problems

...

Images of the board

NVRAM

Types of NVRAM

One type of NVRAM is SRAM that is made non-volatile by connecting it to a constant power source such as a battery. Since SRAM requires continual power supply in order to maintain its data, an NVRAM that is made from an SRAM will need to use an available power supply to make sure it continues working.

Another type of NVRAM uses EEPROM (Electrically Erasable Programmable Read-Only Memory) circuit chips to save its information when power is turned off. In this case, NVRAM is composed of a combination of SRAM and EEPROM chips incorporated into a single semi-conductor die.

NVRAM chips don't require much power and backup can be guaranteed for up to ten years.

Bad NVRAM

When NVRAM is failing, it generally means that your computer hardware is not retaining the necessary specialized settings that it ought to though the default BIOS settings remain. Since the BIOS relies on the settings stored in NVRAM in order to handle the particular hardware you have, performance may lack in stability. The contents of the NVRAM chip can become corrupted for a variety of reasons:

A failure of the embedded battery. If the battery embedded in the NVRAM chip fails, then this means that your system clock will stop running and important system configuration information may not be maintained.

A failure of the BIOS chip on your motherboard. If the BIOS chip is going bad or is not making proper contact with the motherboard's contacts, then the NVRAM will fail.

About uClinux

uClinux has no sense in such a PDA: on m100,m105,m500 (and similar) there is no network (wired/wireless) interface, and if you could think to use Net Overt IrDA ... well you have to consider the uart line is multiplexed with the IrDA: that means if you use the serial console you can use the Irda comm.

Also, flash is still not flashable (dunno if there is an hardware protection, also the flash chip is still unknown ... no label on it and it does not reply the CFI query): where to put the fat kernel image + rootfs ? in ram ? you have to consider you could not back to palmOS once uclinux has been started

the LCD is not supported, there is no framebuffer, also the touchscreen is not implemented with a driver

uClinux is assumed as "a good point to look for, when i need an example, or with a look for a bit of inspiration about 68xx328"

what/where

kernel 2.4.x there is a port of cLinux http://palm-linux.sourceforge.net/ but do not trust it: it is pretty old, and informations on that pages are not completely right (a lot of errata information ... for example the m105 has no working framebuffer)

kernel 2.6.x has no sense at all (nommu is not supported, and if it could, 2.6 is "too much fat" )

About firmware

I am replacing the firmware: a MON is in developing
With an hw hack I am able to force the CPU to boot into the special serial bootstrap mode, so i can upload the firmware by UART
There is a lot to work to support the hw

About devtools

palmOS dev tools are not still available, so I don't know how to compile what has been developed by the sourceforge team

doc

if you need information/help, you could contact by email ( flamemaniii@gmail.com )

68K Books

The following is a list of books about 68K programming

Bibico Cando suggested

"Microprocessor Systems Design : 68000 Hardware, Software, and Interfacing" by Alan Clements. PWS Pub. Co.; ISBN: 0534948227, I own this book and find this is a good book to understand, 68K based mechanisms, Interrupt, FPU

"The Motorola MC6800 Microprocessor Family: Assembly Language, Interface Design and System Design." by Thomas L. Harman & Barbara Lawson. Prentice Hall, 1985. ISBN: 0-13-603960-X 01, I found this excellent, it became my bible for 68K, It covers everything in some detail, even has a good description of stack frames.

"Dr Dobbs Toolbook of 68000 Programming" A Brady book, published by Prentice Hall. 1986 ISBN: 0-13-216649-6 (Hardback) 0-13-216557-0 (Paperback). This is quite good. Stuff like Tiny basic, Forth, the ECB Tutor firmware and a simple multitasking kernel. Good book for getting the ideas flowing.

"68000 Microprocessor Assembly Language Programming" by Lawrence Leventhal. It covers the subject quite well for the original 68000 chips but you may need to look at a few other publications for some of the later ones.A quick search on amazon.com did not come up with this book. It's probably out of print--I remember it from 1982 or so. I can't recall any recent books covering the 68xxx family.

Unofficial Bug List

This list is for bugs/features that do not appear in Motorola's "release notes".

68EZ328 Maskset 1J75C

1. LCD Display Controller doesn't work with SRAM. Motorola reports various problems when using DRAM, however it also does not work with SRAM. Only fix is to use a later maskset (1J83G or later).

Common problems and Gotchas

1. During development of software with the 68EZ328 I have found a common problem was not setting the I/O pin functions correctly via the relevant SEL register (eg. PCSEL to select either LCD function or general I/O pin) for the port that the I/O pin is on. This seems to happen easily as the description for most peripherals in the user manual rarely mentions this. Also don't forget to set the pull-up/down correctly for your system.

2. Gary Kato reported to "comp.sys.68k" news group the following "Gotcha".

I ran into a something when trying to let the Dragonball's UART receive FIFO control the RTS signal. According to the Users Manual, you should just be able to set a bit to do this, however it seems you have to turn the RTS signal off with its control bit (in the same register) in order for this to happen. It is like the manual control bit has precedence over the FIFO. The Users Manual implies the the FIFO has precedence (ignoring the RTS control bit).

3. DTACK on startup in bootstrap mode.

I found that DTACK (PG0) is not high when the processor starts in bootstrap mode. The user manual is not clear on this but it does suggest that this pin defaults to DTACK signal after a reset. I examined this on the CRO and discovered that there is a noisy low signal on this pin after a reset. Therefore the internal pull-up is not active or strong enough to pull this pin high. This problem has caught me out twice now! If you are going to use this signal as an I/O then dont connect it to something critical for bootstrap mode operation like the enable for the serial port transceiver - silly me.

Tips & Tricks

1. Getting RAM to start at location 0x00000000 in memory map.

Why do this you ask. Well in 68K systems the interrupt vectors are stored in low memory. To be able to change them from your program code they need to be stored in RAM. This is a common design goal for 68K systems. Orgainising the mapping of ROM to location 0x00000000 to fetch initial PC and stack and then switching RAM to location 0x00000000 shortly after this is acheived in different ways for different 68K processors. I present here a simple method of acheiving this with Dragonball processors.

All 68K processors start by fetching the initial stack and Program Counter (PC) address from locations 0x00000000-0x00000007. The Dragonball processors map the device connected to CSA0 to all memory locations after reset. Therefore, for an embedded system, CSA0 must be used to decode your ROM device. The default size of the device connected to CSA0 is 128KB. Therefore if the actual device connected to CSA0 is at least 128KB in size then it will appear in memory repeated every 128KB. Therefore if your desired location for your ROM device appears on a 128KB location (it is almost impossible for it not to, given the available options in the chip select registers) then the initial PC can point directly at the starting location you wish to have your ROM located at even though you have not yet programmed the chip select registers so that it appears there. It appears there already because the ROM device is repeated through memory. Very early in the startup code the chip select register should be programmed so that CSA0 only appears at its desired location. As long as that is consistant with where it is assumed to be from the inital PC address then the CPU wont notice the change to the decoding of CSA0. After CSA0 has been programmed correctly then the chip select for the RAM can then be setup. The RAM can be programmed to start at location 0x00000000 as the code is happily executing from the ROM device elsewhere in memory.

Worked Example

2MB FLASH device, connected to CSA0 - to be mapped to location 0x00800000, also mapped to 0x00000000 after reset
256KB SRAM device, connected to CSB0 - to be mapped to location 0x00000000
Entry Point of code is 0x00000008 bytes into FLASH device (ie 0x00800008 in memory map)

Place 0x00800008 at location 0x00000004 of FLASH device (this is the inital PC)

The system I am developing uses a very small PCB and is jam packed with devices. There is no room to stick an emulation ROM and no room to stick a header that could take a daughter board to allow an emulation ROM to be attached during debugging. Also the extra cost of an emulation ROM device or inconvienance of having a daughterboard (to lose) are additional considerations. However I would still like to be able to use the on-board hardware break-point capability. It requires that the system be put into emulation mode. In emulation mode the CPU boots via the EMUCS signal which is used to decode an emulation ROM device that would typically store the debug monitor code.

I thought it would be good to be able to use the hardware break-points without going into emulation mode but Motorola have told me this wont work. (I tried it anyway but could not make it work). So my next plan is to get into emulation mode without using an emulation ROM! To do this I need to fool the CPU into thinking that it is entering emulation mode but then jump directly into my code stored in the normal ROM device.

I have worked out two different ways to acheive this...

2.1 Connect EMUCS to CSA0 via "and" gate (74LCX08)

Using an "and" gate to connect CSA0 and EMUCS together so that either chip select will select the ROM memory. In emulation mode the code will start executing from location 0x00000010 in the ROM device. You can then re-program the chip selects and disable the hardmap (see ICEMCR register description) and you then have full control.

I have tried out this solution using an ariel construction using an "and" gate (74LCX08) to connect together the CSA0 and EMUCS signals taking the output of the gate to the flash memory in my system. I ran into a "small" problem. The CPU sets A18 and A19 high during boot in emulation mode. This causes the CPU to read from high up in my flash memory. It would probably be better to gate these two address lines so that the op-code fetched from the flash memory is near the start of the device. Also note that the emulation ROM is supposed to be an 8 bit device. When using the flash memory in my system (16 bit device) the CPU will in fact read the same location twice as A0 is not connected to the flash memory. This is not a problem if the op-code it fetches has the same byte in both the upper and lower bytes. I also noticed that there are four types of exceptions that can be generated by reading various op-codes. As mentioned above you can use Trap 14 (0x4E4E). You can also generate an illegal instruction exception by using an illegal instruction (eg 0x4F4F). You can also generate line 1010 (A Line) or Line 1111 (F Line) exceptions by using an op-code where the top nibble is either 0xA or 0xF.

By hardwiring the bit pattern 0x4E to the EMUCS signal (I am currently using a 74HC575, clocked by the system reset signal) the CPU will read a TRAP 14 op-code on every access to memory decoded by EMUCS. This op-code will cause the CPU to decode a vector from my ROM device (TRAP 14) and then jump to a the interrupt handler decoded from the vector. Thus any attempt to fetch an instruction from the emulation ROM will instead jump to the TRAP 14 handler.

The theory is that on entering emulation mode after a reset the trap 14 handler vector, which must be in ROM, will cause the CPU to jump to my appropriate initialisation code in the ROM. After the chip selects have been setup appropriately (see "Getting RAM to start at location 0x00000000 in memory map" above) then the TRAP 14 vector can be changed to point to the break-point handler function. Thus the trap 14 vector stored in ROM mimics the 0xFFFC0020 entry point for entry to emulation mode and the trap 14 vector placed in RAM mimics the 0xFFFC0010 entry point for break-points.

I have not tried this, I abandonned this idea in favour of the first suggestion above. I am fairly certain it would work though.

Note1: I have released a GDB stub that utilises the hardware breakpoint capability. See notes in software downloads section.
Note2: I have seen that 68VZ328 appears to support enabling emulation mode via software! This may make all of the above redundant on 68VZ328!
Note3: I have found that the 68EZ328 must have an external reset (taking RESET* low) to enter emulation mode. A watchdog reset will not cause the CPU to check if an emulation mode start request has been requested.