What is DragonOne?

I got sick of writing software and reading about hardware all the time. I wanted to get back onto the hardware scene, and the best way to do that was to get my hands dirty again.

My experience so far has been building hardware interfaces to the x86-based machines, building embedded systems around the Z80 processor,  working with the PIC microcontroller (hacking those playstations was fun :-) and building simple (by todays measures) electronic devices.

All of the technologies I worked with were pre-SMT and considered older technologies by now. To acquire this experience and be able to boast that I had actual experience working with the DragonBalls and StrongARMs other than reading extensively about them, I started working on the DragonOne.

DragonOne is a simple Dragonball based device, that allowed me to refresh my hardware design experience, give me an experience working with a 32-bit embedded microprocessor and learn the skills I needed to start working on my next more serious device :-)

What about this page?

Well, few things. I wanted to pay the community back by providing more information and documentation based on my findings. With each documented experience, the newbie's life (and sometimes the experienced's life) becomes easier and easier, so I wanted to add one more experience hoping to put a smile on a newbie's face. I, also, needed a place to document my findings and work. Besides, it was fun :-)

Here's a list of the following sections:

Why The DragonBall?
The Design
PCB Layout
Cool Hints
Linux - you're almost there

Why The Dragonball?

The moment I read the summary specs of this processor I fell in love with it. 

First, it had a 68000 core, which I admired when I helped two friends, back in college, by building them a simple preemptive multitasking operating system to run on their 68HC11-based home control system. It was mere pleasure working with the simple, yet elegant, instruction set, especially after having worked with the x86 and Z80s for so long.

Second, it had many of the most important devices built in, UARTs, LCD controller, memory controller, PWM in addition to an elegant bootstrap mode that you can interface with using your terminal client before installing any software.

Third, it had enough processing power with low power consumption to be useful enough for a fun loving experimenter. 

The final reason is that enormous number of people interested in the processor, this makes it easy to find information, software, guides and help from to many sources. It also means that the processor is widely used enough, for your experience with it to be significant and yield fruit sometime in the future :-)

Enough with the cheesy talk, and lets get down to business.

The Design

I didn't want to reinvent the wheel. All I wanted was a simple design to get me going, my purpose wasn't spending much time doing things I already knew how to do, but more of the things new to me (SMT PCB layout, working with a 32-bit embedded microprocessor, installing Linux or Windows CE on a new architecture, etc.). So I decided to use  Tom Walsh's EZ328SIMM as my base line.

The EZ328SIMM was simple enough. A Dragonball, flash, dynamic ram, bus transcievers and some supporting logic, and it was open hardware (open hardware? what??!! if that's what you're thinking, visit Tom's site, he'll explain it to you). 

I replicated  the design on Eagle (since I liked their PCB layout application). I didn't make many changes, except for the choice of signals I exposed and taking out the battery (I didn't think I needed one), as it wasn't going to be a real system, not at this phase at least.

I also replaced the form factor from a simm to a board with connectors. A simm would have been too troublesome for me, since I needed other hardware built to be able to interface with it, and there were just too much mechanical work that would have added to the complexity of troubleshooting a first experiment.

PCB Layout

Contrary to the circuit digital design, the PCB Layout was significantly different than Tom's layout (please don't visually compare, it's embarrassing :-\). Space wasn't a big issue with me as it was with Tom, the form factor was different, and this was my first shot at SMT PCB layout with chips of this number of pins (my second design with a StrongARM, which I'll post soon is much much better).

By recalling past experience, searching in the internet, following mailing list and news group discussions, I got a list of few guidelines to follow while designing a PCB. I will list them below. If you think there are more that are important, don't just shrug, send me a list, and I'll be glad to add them for all the newbies out there.

You can also find excellent guidelines in the MC68EZ328 User's Manual, under section 17. This manual should be your close friend if you're working with a Dragonball. It's not the best manual (I hate the layout and how much information is missing or ambiguous), but still it will save you lots of time if you study it carefully (which you should do with any part you design for).

You can find the gerber files here. If you intend to use those BEWARE that there is a MISTAKE in the design that is easy to deal with. It is listed below with the other issues you need to be aware of. I recommend you read it carefully if you are ever going to use the board:

The Serial connection to your PC is simple. Just purchase a nul modem cable (or make one) and connect it to your transciever (the MAX or ADM chip). It connecting CTS and RTS doesn't really add lots of reliability in a workbench environment, but it's only a couple of wires. The CTS and RTS should also go through the transciever, it has two channels for Tx and two for Rx, so use the extra two for CTS and RTS. For mechanical information layout of the cable connections, go here.

Ok, we got our PCB assembled, lets get to the fun stuff :-)


I'm not going to explain what the bootstrap mode in dragonball is and how to use it, you can refer to the users's manual for that. But I will explain how it's used to program the flash memory. This needs to be used at least for the initial testing and linux installation, since later you can use a kernel loader such as the one provided by Tom on his web site.

Bootstrap allows the user to modify memory content in any location in the memory space available for Dragonball (including configuration registrered which are mapped to memory locations) by passing B records to the bootstrap logic through the serial port. It also allows for the start executing a program at a any memory location.

The way this is used is that the logic, in three sections, is passed to the bootstrap logic. The first section is an initialization of the configuration registers to correctly map the dynamic ram and flash memory in addition to other required initializations. The second section is an application (that will be executed later) which will be responsible for storing the third section into flash memory. And obviously the third section is the linux image to be stored in flash.

The second part is called the bootloader. Daniel Haensse (a cool guy you usually find hanging out around Tom's openhardware.net) provided me with a piece of code he wrote that works as a universal flash loader. As you will see from the comments in the code, this is GPLed code, which means that you can't ... you know what that means.

Daniel warned me that I can't use it directly if I have 2 8-bit flash memories (which I do), and that init.b was for the 68vz328, since that's what he's using on his Dragonix board. So I modified the code to deal with those two issues and added few other features and fixes. Of coarse the code was extremely helpful, especially that it had most of the logic needed.

If you compare the logic in those two zip files, you'll find that I applied the following changes (I haven't talked to Daniel to apply any of them yet, but I should soon):

Following are the steps you take to use this bootloader:

  1. You compile your linux image file (we'll discuss this in the next section) and place the binary at the folder just above the 2flash folder (this is how Daniel had it, and I kept it that way, as it was convinient to put a link on the parent folder to the actual generated image.bin so you don't need to keep copying files)
  2. Compile the bootloader (don't forget to comment or uncomment the takeControl method to enable to disable the menu)
  3. Use bbug or bbug32 or a terminal to the serial connection to your Dragonball (to dump the generated boot.b. You should use the terminal if you want to run a menu, because you will need to interact with the menu and see the output, which bbug doesn't allow you to do. Remember that the settings to the terminal (you can modify them by editing init.b) are 9600, 8bit, 1-stop and no parity.
  4. Execute the bootloader at 0x1000, on bbug you do that using "go 1000" while on a terminal window by typing (0000100000), where 00001000 is the address and the 00 tells the bootstrap logic to execute at the passed address.
  5. As Daniel told me: have fun!

If you were smarter than me, it will work the first time, if not, happy debugging :-)

Cool Hints

Before I move to the Linux section, I wanted to point you out to few hints that might prove to be useful. 

Linux - you're almost there

Until now (given that I'm updating this page fast enough), I have only built the a 2.0.38 kernel. It shouldn't be tough to upgrade to a 2.4 kernel, but I have this site to work on now :-).

Luckily, there are two excellent documents published by Craig Peacock fine site BeyondLogic.org (I love australian embedded sites, those guys rock).

The first document is a good guide for building your environemnt (cross compilers, libc and libm) and your initial file systems (i.e. romfs). It is an excellent document for a start with, but make sure you understand what is happening if you haven't built a linux kernel before. It also serves the purpose of providing links for all the pieces you need. I have the following two comments, though:

  1. In the section "Manually Building the Tool Chains - m68k-coff" and before building ("make LANGUAGES=c") you have to make a change (I was using kernel 2.4.2 and gcc 2.96 when I had a problem with this). I found a solution on the net and it worked (didn't want to claim this for myself) In the file bc-emit.c I commented the inclusion of bc-typecd.def and replaced it with the actual contents of the file ( I wasn't sure if bc-typecd.def was used anywhere else ). Then I replaced the SFtype with the actual macro (so that I can make a specific change) as follows:

    case SFcode:
        long temp = va_arg(arguments, long);
        bc_emit_bytecode_const((void *) &temp, sizeof temp);
        PRLIT(SFtype, &temp); }
  2. In the section "Standard Math Library" when you try to create symbolic links for math.h and mathf.h, you might get a "too many symbolic links" error, just copy the files :-)

The second document is about building linux and explaining what is actually happening when linux builds. It also gives few very important details about memory mapping your linux which you should really understand, especially if you have a custom solutions and not using a uCsimm stick.

There are also few issues I faced when building linux, and few modifications I needed to do for it to work after it was installed. Following is a list of them


That's all I have to say for now (at last, eh? :-) but I will try my best to keep this document updated. I don't promise to be able to help anyone with problems they face with their standard or custom systems, but I promise to at least think about it.

Other sources of information would be the Lineo uCsimm, openhardware.net, and the Dragonball Developers Lair. A good list is the openhardware.net list, maintained by Tom Walsh (thanks Tom) who's a veteran in  embedded development in general and Dragonball-based development in particular.

How can you contact me? Well.... draaag yooouuur moouusssseee riiiighttt heeerreee aaannddd CLICK

LCD Hooked

I hooked up the LCD to my DragonOne. I had to create a frame buffer driver for the LCD. I don't have time to document the details, but thought that I should at least put some photos up...