For more interesting projects done by Flameman, be sure to check out his project index
- 1 Palm-m105-m68328-Flameman
- 1.1 Note
- 1.2 Introduction
- 1.2.1 People you could contact if you need help
- 1.2.2 About this project
- 1.2.3 About the board
- 1.2.4 Overview
- 1.2.5 Memory Locations
- 1.2.6 Problems
- 1.2.7 Images of the board
- 1.2.8 NVRAM
- 1.2.9 About uClinux
- 1.2.10 About firmware
- 1.2.11 About devtools
- 1.3 doc
I'm developing for this board, the wiki page will be improved soon
feel free to contact me (see the contact below)
The Target-goal of this page is
- install uClinux into flash
- make the board able to boot it
- describe how to flash
People you could contact if you need help
- flameman, i'm currently use this board for a project, email
- msn email@example.com
- email firstname.lastname@example.org
- irc.nick flameman (channel #edev, #gentoo-ppc)
- you ... if you want ;-)
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.
The board (palm m105) consists of:
- CPU MC68EZ328-16Mhz m68ez328-user-man.pdf
- RAM soldered 8MB-edo-k4e641612d
- LAN spi-to-ethernet (it will be added soon)
- UART RS232
- TOUCHSCREEN spi-ads7843 touchscreen-driver-ads7843.pdf
- ROM ROM-2MB ... the label is unreadable, i wander if it ~ to flash-sst39vf160 ~ (Fujitsu) flash-29LV160B.pdf
- POWER 3.3V
- System PCB xxx cm x xxx cm
- RTC the real time clock chip inside the cpu
palm m500 is using flash-amd-am29dl323d-32mbit-8bit, that is a 32 Megabit (4 M x 8-Bit/2 M x 16-Bit) CMOS 3.3V Volt, Simultaneous Operation Flash Memory
memory map of the board will be added as soon as possible
|addr begin||addr end||area|
|00000000||000003ff||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|
Images of the board
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.
Benefits of NVRAM
- NVRAM chips work like static RAM
- NVRAMs provide superior performance over other NVM products
- NVRAM's serve applications that require high-speed read/write operations with non-volatile memories such as parallel processing controllers for LANs and antilock braking systems.
- NVRAM chips don't require much power and backup can be guaranteed for up to ten years.
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.
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"
- 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" )
68EZ328 DragonBallEZ support uClinux/MC68EZ328 Flat model support (C) 1998,1999 Kenneth Albanowski, D. Jeff Dionne PalmV support by Lineo Inc. <jeff@uClinux.com> Console driver (without boot console): mono mc68328 40x26, 1 virtual console (max 63) Calibrating delay loop.. ok - 1.36 BogoMIPS Memory available: 1108k/1608k RAM, 0k/0k ROM (924k kernel data, 422k code) Swansea University Computer Society NET3.035 for Linux 2.0 NET3: Unix domain sockets 0.13 for Linux NET3.035. Swansea University Computer Society TCP/IP for NET3.034 IP Protocols: ICMP, UDP, TCP uClinux version 126.96.36.199pre3 (root@meteor) (gcc version 188.8.131.52) #2 Tue Jun 20 01:39:24 CDT 2000 MC68328 serial driver version 1.00 ttyS0 at 0xfffff900 (irq = 64) is a builtin MC68328 UART Ramdisk driver initialized : 16 ramdisks of 4096K size Blkmem copyright 1998,1999 D. Jeff Dionne Blkmem copyright 1998 Kenneth Albanowski Blkmem 1 disk images: 0: 6B090-B248F (RO) PPP: version 2.2.0 (dynamic channel allocation) TCP compression code copyright 1989 Regents of the University of California PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. PPP line discipline registered. SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256). CSLIP: code copyright 1989 Regents of the University of California. Open of blkmem arena 0 at 6b090, length 47400 VFS: Mounted root (romfs filesystem) readonly. Welcome to uClinux/Pilot! uClinux release 184.108.40.206pre3/Pilot release 1.0.0 #
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
palmOS dev tools are not still available, so I don't know how to compile what has been developed by the sourceforge team
you can find something useful here http://www.cs.cmu.edu/~pprk/
M68k Boot loader idea http://www.mac.linux-m68k.org/
2009-04: just opened, but it will be used for "doc & versioning" http://code.google.com/p/m68328/wiki/first
2011-03: sorry still not time to update that page, so if you need information/help, feel free to contact me by email
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.
- "MC68000 Assembly Language and Systems Programming." by William Ford & William Topp. DC Heath and Co. 1988. ISBN: 0-669-16085-7
- "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 or Palm's "release notes".
- 68EZ328 Maskset 1J75C
- 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).
- address registers are corrupted in higher bit, SRAM is not directly connected to the address bus, it is connected to DRAM controller with uses CAS and RAS addresses, anyway A22,A23,A24 are multiplexed with GPIO and these bit are set to 1 ... palm hack is not reporting correct information when i dump register
Common problems and Gotchas
- 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.
- When 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).
- 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
- 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. Organizing the mapping of ROM to location 0x00000000 to fetch initial PC and stack and then switching RAM to location 0x00000000 shortly after this is achieved in different ways for different 68K processors. I present here a simple method of achieving 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 consistent with where it is assumed to be from the initial 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.
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 initial PC)
Initializer code sets CSA0 to start at location 0x00800000, CSB0 to start at 0x00000000
- Using Hardware breakpoints without an emulation ROM.
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 inconvenience 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 achieve this...
- 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.
2.2 Cause CPU to read fixed bit pattern when EMUCS is active (using a 74HC575)
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 initialization 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 abandoned this idea in favor of the first suggestion above. I am fairly certain it would work though.
Note1: I have released a GDB stub that utilizes 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.