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.

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
Bootstraping
Cool Hints
Linux - you're almost there
Finally...

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 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 power lines should form loops, whenever a branch goes out, it should meet a surrounding loop at another point. Other people prefer using meshs (grids), but I like loops because they are easier to layout. Of coarse if you're doing an n-layer design (where n > 2) then you should have power planes (for supply and ground)
• You minimum signal width should be 8mil
• The outer power loops (that feed the whole circuit) should have thick tracks,  because that's where the most current flows. The more the power line branch the thinner they can get (of coarse you still need to beware of what they are feeding and the expected current that will flow through them)
• Research the placement of your ICs before you touch the layout software. It will be MUCH easier to decide on the most efficient part placement before you start the layout than after it.
• Bypass capacitors. No one agreed on what the right amount was for bypass capacitors. For isntance in some designs a bypass capacitor is placed at each supply pin, and in some others, it is every other supply pin. I follow two rules of thumb, the higher the frequency the more capacitors needed, the more the current the more capacitors needed. I know it's vague, but this is something where you'll have to use your judgement and experience, if you're not sure, be on the conservative side, it's much easier to remove capacitors (I never saw a case where you need to do that) than to add ones where no pads exist.
• Crystals should be as close as possible to the IC they are connected to.

• The MISTAKE is that the nand gate (the left most IC on the design, 74lvx00) is mirrored horizontally (on a vertical axis). What this means is that the chip will need to be soldered on its back (:-\), which is not possible. My quick solution was to take the chip off the board (the people who soldered the board soldered it anyway, which pushed me to buy my zyphertronics kit :-) and then short circuit -XReset and -PReset. With this I jeopardized getting a bouncing effect, but I never noticed any problem (ofcoarse you have to use a push button and not just a wire on a breadboard :-)
• Another point to notice would be that the board expects a regulated 5v and 3.3v supply. You should provide the power supply and regulators on an external board. I assembled a simple circuit utilizing a 7805 for the 5V supply and an LM350 for the 1.5v.
• To connect to the serial port of your PC, you need a RS232 transciever, I used an ADM233 (A direct replacement for the MAX233).
• You will need to connect the -XReset and -BDM signals to two pushbuttons. Notice that the BSM and XReset are active low signals. So they need to be connected through a resistor to VDD and shorted to ground through the pushbutton (I really hope you didn't need this explanation :-\)
• You might want to add a simple power switch and power led

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

Bootstraping

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

• I made the "Bank B" manipulation logic conditional at compilation time. Because my board only had one bank.
• I modified the code so that I can set the programming length, instead of it being the whole length of the flash (which takes forever on an 8MB flash when you only need to program 1MB)
• I modified the logic that wait for the chip erase so that it would detect the toggling effect and detect an error on DQ5 instead of the logic that used a timeout mechanism. The reason I did that is that erasing my chips took much longer than the timeout, and increasing the timeout wasn't the best way to deal with it, so I fixed the problem more elegantly :-)
• I added a reset method (which is used from the menu that I will discuss later)
• I added a menu to give the user the option to erase, program, set a word in flash, get a word from flash and reset. I had to do that after I discovered how UNreliable bbug was. To enable the menu, you have to uncomment the call to the takeControl method in bootstrap.c (I probably should make it a conditional compilation block)

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. 

• There's a very useful site created by David Williams, that he calls Draongball Developers Lair. It's a very useful site, look around and see if there's something you can use, but what I'm pointing to are two sections, the "Common Problems and Gotchas" and the "Tips & Tricks" sections. BUT, there's a problem in the second section. I'll explain it in the following point.
• As the introduction to Section 4 ("Chip-Select Logic") in the Dragonball users's manual states, and I quote "From reset, all the addresses are mapped to CSA0 until group base address A is programmed and the EN bit is set". What this means (and I found this interpretation to be experimentally true) is that all locations one the memory chip connected to CSA0 are accessible at boot time. This is contrary to what David Williams claims in his site (mentioned in the previous point) that the memory is repeated each 128KByte, this is NOT true. The memory is repeated after the maximum size of your chip connected to CSA0, and that's not because Dragonball repeats it, but because your chip only decodes address lines in its address range. For if your flash memory chip is 2MBytes in size, and you try to access memory at location 0x200100 (2MBytes + 0x100 bytes) then location 0x100 of your memory is accessed, not because A21 was not asserted, but because your chip only decodes A0 through A20. Think about it. It seems that David had a 128KB EEPROM and that coincided with the fact that group base address is set in increments of 128KB, so he arrived at his conclusions.
• The base address for your chip should be a multiple of the size of your memory. So 0x10C00000 is not a good base address for an 8MB flash. I have no idea why uCsimm developers chose that base address :-\. Beware this could cause you tons of unwanted trouble
• Don't trust BBUG that much, if BBUG gives you an unexpected result, don't suspect your hardware or software yet, right a small app verification app, or memory dumper (to the serial port), convert it to a b record file and use the terminal to dump and execute it.

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); }
       break;
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

• I was building on a 2.4.2 kernel and a 2.96 gcc, and got an error when making the dependecies ("make dep"). All I did was replacing the file scripts/mkdep.c with one I got from a Readhat 7.1, this should affect anything else, and it worked fine.
• I modified the linker file rom.ld, under linux/arch/m68knommu/platform/68EZ328/ucsimm, to reflect my chosen memory settings. I modified romvec, flash and eflash so that my flash starts at 0x10000000 instead of what it was pointing to. Note here that I didn't include any bootloader in my linux image on the flash memory. Which means that contrary to the uCsimm version that should start 1MB after the beginning of flash memory, my linux would start at the beginning of the flash memory. Also modify ramvec, ram and eram as needed.
• I then modified crt0_rom.S, this is the first code that is executed of your linux build, and it is where all the configuration registers of your Dragonball are initialized. Make sure that they are initialized correctly, especially the chip select and address group base registers (ff100-ff106 and ff110-ff116). Also modify the line "moveb    #0x07, 0xfffffd0e" to become "moveb    #0x07, 0xfffffd0f" or "movew    #0x07, 0xfffffd0e".
• In linux/arch/m68knommu/platform/68EZ328/config.c, in the method config_BSP (Board Support Package configuration method) the command line arguments for the kernel are retrieved from the bootloader. I didn't have the uCsimm bootloader or anything compatible, so this part caused me problems. The specific code that I needed to replace was compiled conditionaly based on the definition of CONFIG_UCSIMM (in short surrounded by #ifdef), so I replaced this block with "command[0]=0;". If you want to pass parameters to linux somehow, this is the place to do it.

Finally...

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