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 :-)
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?
Linux - you're almost there
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.
|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
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.
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:
If you were smarter than me, it will work the first time, if not, happy debugging :-)
Before I move to the Linux section, I wanted to point you out to few hints that might prove to be useful.
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:
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
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...