I'm not crazy, just reinventing the wheel :D
I wrote boot-loaders, mouse & keyboard mini-drivers, mini OS and so on.
I'm always trying to avoid DOS interrupts, using BIOS ones only, trying to go forward a unity mini OS, but suddenly I decided to write my own BIOS :)
The Legend said :
I was high-level programmer, then low-level one. One day I'll be machine-language programmer!
Is a BIOS written in assembly? How can I flash it? What's the mechanism? Can I start editing my current BIOS?
A BIOS can be written in assembly but doesn't have to be, some parts need to be to get the parameters for the system call since they don't match the compilers calling convention.
How do you flash it? Varies from motherboard to motherboard, I would start with an open source virtual machine and write a bios for that. Or create a virtual machine where you have written the bios. The mechanism varies from vendor to vendor, generally you boot dos (dos is not dead, it is very much alive in the PC world, esp motherboard development and embedded systems). I wouldn't mess around with a real motherboard, if you don't already know the answers to all of these questions you are going to brick a number of motherboards if you take that path.
You can try to take a bios upgrade for your mother board and reverse engineer it (although there is probably a click through agreement that says that you wont). If you figure it out you can both load it and hack at at. I wouldn't go there, you will brick your system before you figure it out.
Is writing a bios really what you are after? Fairly old school, would be like writing 6502 code for fun. There are many low level problems that are more useful and as interesting.
If you can write asm the writing machine code is not that difficult at all, you could just go do that for fun. x86 is dreadful, you should spend some time learning other systems and their asm and machine code (and writing operating systems for them). ARM dominates the world and doesn't rely on a bios. I have been told that to get a video card up on a non-x86 system you still have to fiddle something in x86 on the x86 bios, could figure out how to bring up a mainstream video card without the need to run the x86 bios. watch an emulator run the bios and see what it does, figure it out replace that power on init without the bios doing it...Writing an instruction set simulator or disassembler is the next step beyond writing machine code, I wouldn't waste even a second of time on x86 though, I can suggest a list of alternatives (or you could just play with the simulators I have written or collected).
If an x86 bios is the way you want to go, your best path is to write, replace, or hack on a bios for a virtual machine being qemu, virtualbox, or other. Replacing that bios with yours would likely be replacing a file in some directory or using a command line option to specify an alternate bios. Once you are well experienced in that then if there are still motherboards with legacy bioses on them perhaps you can hack your way into programming one (need to buy several of each type of motherboard as you WILL brick some). With so many embedded systems out there that can be had for $20 to $200 with the same level of experience gained, it doesn't make sense to hack on a pc motherboard without decent schematics and documentation. You could dig up an original PC with the schematic and bios listing being documented, and the bios being socketed so if yours doesn't boot (and doesn't destroy the motherboard) it isn't a brick you can reprogram or replace the bios chip. Probably want to use a microcontroller to stand in as a fake bios, as finding the right hardware to reprogram more bios chips is perhaps harder to find that working original PC's...There is an amiga community that is likely a lot more fun and would be happy to have you improving/tweaking their bios, say putting modern hardware behind the legacy system calls.
BIOS can be written in any of your favorite language, although lower level languages give you more control. Assembly and machine code are almost the same, the difference being microcode interface and what you type, eg. for machine code you'd only type 2 characters, and assembly give you alphanumerics. My hunt for custom BIOS began when I needed computer to boot up every few hours and haven't found any BIOS that does that.
To flash BIOS, follow manufacturer guidelines. BIOS has now been replaced with UEFI (for added security).
Checkout: https://www.pcworld.com/article/187437/how-to-update-your-bios.html
x86 and amd64 instruction reference: https://www.felixcloutier.com/x86/
x86 instructions with extensions: https://en.wikipedia.org/wiki/X86_instruction_listings
i386 instruction ref: https://css.csail.mit.edu/6.858/2014/readings/i386.pdf
x86 Assembly Guide: https://www.cs.virginia.edu/~evans/cs216/guides/x86.html
Intel Instruction Set Ref: https://software.intel.com/sites/default/files/managed/a4/60/325383-sdm-vol-2abcd.pdf
If you want to write a BIOS for an IBM PC Compatible computer (which is what the majority of desktop PCs are today, albeit with more extensions to the CPU instruction set, and some different BUS interfaces), then I suggest you look through the IBM PC, IBM PC XT, and IBM PC AT Technical Reference Manuals. Particularly the IBM PC AT manual, as that is what the de-facto standard is.
These manuals have a program listing of the complete BIOS that IBM used on their computers, and they are in assembly language. You might have to hunt through those manuals a little bit (especially the IBM PC AT one) to find them, as some aren't directly listed in the table of contents, but they are there. Hopefully those BIOSs can get you started.
There are ways to flash the bios other than to have the pc running perhaps. But it requires some hardware. Shouldn't be very expensive though.
You could try something like this kind of tecnique:
http://hackaday.com/2010/11/18/build-your-own-soic-progamming-clip/
This talk i saw today:
https://conference.hitb.org/hitbsecconf2015ams/sessions/how-many-million-bioses-would-you-like-to-infect/
It explained it in more detail, though you might not be looking for infection, some tecniques for getting to the bios are covered, where the programming clip is one of them.
FWIW Modbin is a DOS program that as the name suggests MODifies BIN images especially for the purpose of both simple qnd fairly extreme changes to existing BIOS code.
If you can obtain an old mobo (many are thrown away still working) I would encourage you to play around with the BIOS. It's informative and fun, if one is so inclined and you seem to be :) There was a time that I downloaded BIOS images from mobos that had the same or similar enough chipsets though made by a different manufacturer...sometimes to considerable advantage including such simple ones as continuing to get BIOS updates after the original mobo manufacturer dropped the ball or went belly up, but also features and performance oriented options and alterations.
This led to "HOT Flashing" which is pulling up a socketed BIOS chip so that the pins just barely made contact and once booted up, pulling that one and substituting a bad one (often one I had fuxored) while still running and flashing it employing the cached BIOS feature that kept the system active. Fun stuff for those of us of the geek persuasion and gave me the confidence to write device drivers for OS/2
Related
I searched for info about this but didn't find anything.
The idea is:
If I code a program in C, or any other languages, what else do I need to do for it to get recognized in BIOS and started by it as a DOS program or just a prompt program?
I got this idea after I booted an flash drive with windows using the ISO and Rufus, which put some code in the flash drive for the BIOS to recognize it and run, so I would like to do the same with a program of mine, for example.
Thanks in advance!
An interesting, but rather challenging exercise!
The BIOS will fetch a specific zone from the boot device, called a master boot record. In a "normal" situation with an OS and one or more partitions, the MBR will need to figure out where to find the OS, load that into memory, and pass control to it. At that time the regular boot sequence starts and somewhat later the OS will be running and be able to interact with you. More detail on the initial activities can be found here
Now, for educational purposes, this is not strictly necessary. You could write an MBR that just reads in a fixed part of the disk (the BIOS has functions that will allow you to read raw sectors off a disk, a disk can be considered as just a bunch of sectors each containing 512 bytes of information) and starts that code. You can find an open source MBR here and basically in any open source OS.
That was the "easy" part, because now you probably want to do something interesting. Unless you want to interact with each part of the hardware yourself, you will have to rely on the services provided by the BIOS to interact with keyboard, screen and disk. The traditionally best source about BIOS services is Ralf Brown's interrupt list.
One specific consideration: your C compiler comes with a standard library, and that library will need a specific OS for many of its operations (eg, to perform output to the screen, it will ask the operating system to perform that output, and the OS will typically use the BIOS or some direct access to the hardware to perform that task). So, in going the route explained above, you will also need to figure out a way to replace these services by some that use the BIOS and nothing more - ie, more or less rewrite the standard library.
In short, to arrive at something usable, you will be writing the essential parts of an operating system...
Actually BIOS is going to be dead in the next two years (INTEL will not support any BIOSes after this date) so you may want to learn UEFI standard. UEFI from v2.4 allows to write and add custom UEFI applications. (BTW the "traditional" BIOS settings on the UEFI computers is often implemented as a custom UEFI App).
I am reading a primer text on embedded C programming (it is: Barr & Massa, 2007). For companion hardware board to run examples, they recommend Arcom VIPER-Lite. But I do already have Beaglebone Black (BBB) board and I don't want to buy a new board.
The two boards have same architecture, namely, ARM but BBB uses TI AM3358BZCZ100 processor, clocked at 1GHz, whereas VIPER-Lite uses Intel's PXA255 processor, clocked at 200MHz. The BBB board has more memory and basically more of everything.
My question is, can I follow and execute embedded C code examples given in this book on my BBB board? Does embedded C code depend on processors or architecture or something else? I understand that very specific examples addressing particular peripherals/drivers may not be portable from one platform to next but is entire embedded code like this? I am hope I am making sense.
Intel X-Scale is not the same as Cortex-A8 - ARM architecture has been through a number of versions since then, and Intel implemented some proprietary features too. Moreover ARM licencees are free to implement proprietary peripheral sets and subsets of the core architecture.
In particular for board bring-up the PLL and SDRAM controller will be entirely different between different vendor's devices and even between different generations of device from the same vendor.
If you are running code on an already implemented OS (BeagleBone is delivered with Linux already installed), then you will not need to worry about board bring up and peripheral support; but you will also miss out in learning a great deal about embedded systems (other than perhaps embedded systems that run pre-installed or vendor supplied Linux distros, which is a small subset or all embedded systems).
Beyond board bring up the boards will have entirely different peripheral sets, different on-board devices, and differing I/O at different addresses and with different register sets - no code that directly accesses the I/O is will work. Code accessing devices through a standard Linus device driver interface may well work because an abstraction to a common interface is provided by the OS and board vendor or third party device drivers.
If you are not running the code on Linux - or are implementing low-level device drivers, then the programming environment in terms of memory map, MMU, PLL, I/O control, peripherals, and even instruction set will be different and any code will require adaptation, and you will need to get familiar with the corresponding data sheets or reference manuals and also the ARM technical reference.
So the answer is that it depends largely on where you are starting from; bare-metal or Linux.
There are resources related to "bare-metal" development on BeagleBone Black in particular TI's own bare-metal StarterWare library.
The concept you learn from most good text books can be applied any microprocessor or micro controller at a very high level. But if you want learn embedded system programming using Beagle Bone Black I suggest the following youtube links from Prof Derek Molloy. Prof Molloy does a fantastic job of teaching embedded System programming using BBB. Here are few links for you to get started.
The Beaglebone - Unboxing, Introduction Tutorial and First Example
Beaglebone: C/C++ Programming Introduction for ARM Embedded Linux Development using Eclipse CDT
Beaglebone: GPIO Programming on ARM Embedded Linux
The one problem you might want to be aware is that the video were based on Angstrom Distribution. The current BBB is shipped with Debian Distribution.
Also if you want to learn bare-metal embedded system program you might want check out
Embedded Systems - Shape The World
You might also want to take look at the following link for more material.
Beginning with programming microcontrollers
The xscale although ARM instruction set derived is not ARM in the sense that you want to use it. For some reason the native mode is big endian and normal ARM native mode is little endian. But more important the core processor is not insignificant, but not the bulk if the porting effort, most of not all of the peripherals are expected to differ between those two chips, most of the code would need a re-write unless it is a purely portable C program that runs on any say linux, then arm, xscale, x86 are completely irrelevant to the discussion. I suspect you are not in that situation. Even compiled as a generic command line linux app would still have problems in this situation with the endianness.
Basically you are saying I have two fords and I want to take the wheels off of one and put them on the other, without understanding that one is a ford festiva and the other is lets say an F350 pickup. Just because they have the same looking tiny ford badge on them, doesnt mean that the entirety of their components are identical.
If you are desperate to re-use these binaries, you are better off finding or making a simulator for the prior platform and then you can run that on anything.
I am looking for some information on programming ARM devices, in a particular non-particular way [1]. Assume that I am writing code for an ARM processor that is used a machine similar to a Apple II/Atari "**" XL/Commodore 64/DOS-PC, or even something that runs a multitasking OS like VMS or SUNOs. Assume further that any peripherals/OS specific stuff has already been abstracted into subroutines.Examples of this type of programing might be: a text/curses based game like rogue or moria; a curses based word processor ( or rather something based on a curses like library ) ; or a modem/terminal program.
I'm looking for two things. Materials to help learn ARM programming, though the ARM System Developers Guide may be enough, other resources would be helpful I'm looking in particular for something which explains the software ( and relative hardware ie registers ) differences of various generations of processor.
The other thing I'm looking for is a development environment which inculdes, emulation, a decent macro assembler, and a debugger. Along with any thing else that will help me see what is going on inside my programs.
[1] OK. Sorry I just couldn't resist that particular pun.
You have the choice of using ARM Cortex M or A series. If you are going to develop high end applications such as those which run on smartphones / tablets, then learning about ARM A is your choice. If you are going for an emphasis with hardware/low level stuff such as controllers then you should go for ARM Cortex-M. If you are into real time applications (which I doubt is your case, them use the R series).
Most of these new ARM generations are based on ARMv7 architecture and ISA, so reading the manuals on that could get you started. Most recently, a new ARMv8 architecture and ISA have been announced, it supports 64 bit processing.
Download the reference and technical manuals from ARM site to learn about the HW/peripherals.
I would go with auslen's suggestion of buying a board, you could go with TI's Stellaris Launch pad which has an ARM-M4F processor (supports floating point and SIMD), it sells for 12.99$
http://www.ti.com/ww/en/launchpad/stellaris_head.html?DCMP=stellaris-launchpad&HQS=stellaris-launchpad-b
or you could go with ST's discovery board (based on the same processor as above), but has audio, accelerometer and usb on board. it sells for 14.99$ http://www.st.com/internet/evalboard/product/252419.jsp
or the STM F3 board (10.99$)
http://www.st.com/internet/evalboard/product/254044.jsp
In any case, you need to check the examples which come with the board, without which you could go nowhere easily. The board comes with its own drivers, all is abstracted in a way, so you could get started from there!
As for OS, if your interest is an RTOS, ARM provides the CMSIS RTOS for it's M series processors
http://www.arm.com/products/processors/cortex-m/cortex-microcontroller-software-interface-standard.php
This book offers an introduction to the generations of ARM processors. Then focuses on cortex M3. It covers its ISA with lots of assembly code. It also addresses the built-in peripherals and how to start-up with C.
http://www.amazon.ca/Definitive-Guide-ARM-Cortex-M3/dp/185617963X/ref=sr_1_1?ie=UTF8&qid=1352506616&sr=8-1
good luck
infocenter.arm.com and look at the various ARM ARMs (architectural reference manuals) and TRM's (technical reference manuals) for the various architectures and cores. these manuals are better than most other companies documentation. except for the new 64 bit stuff, the difference from one architecture to the next is somewhat subtle as far as the instruction set goes. the major differences have to do with the peripherals, the mmu is a slow changing thing, the interrupt manager has taken big steps and the fpu has been replaced at least once if not twice wholesale (if you even have an fpu which, having one is the exception not the rule it consumes a huge real estate for such little return).
I am confused with your question. I think it is important to draw the line between learning the architecture/instruction set and learning the operating system calls, these are two separate things. Operating system stuff you rarely need to look beyond the source code (C/C++), and the limited asm is for hand tuned C libraries or boostrap code, and interrupt wrappers. Likewise the architecture, registers, instructions, etc vs the peripherals (the cores from arm generally have very very few peripherals, the bulk are in the vendor specific stuff) which I would separate as a separate learning curve, has little to do with asm and the instruction set so no different than learning a peripheral on any other platform, just some addresses you read and write.
If you are looking for non-operating system bare metal the stm32f0 discovery is $10, I highly recommend it. Looks like ti has a stellaris launchpad for just a little more (waiting for mine to arrive so I cant talk much about them, and shipping is free from ti so the cost is basically the same as the stm32 boards) the stm32f4 discovery is about $20 and I would barely call a microcontroller with all the stuff the cortex-m4 has.
Moving up to linux capable or designed for linux systems there is the raspberry pi, beaglebone and open-rd and on up (pandaboard). Again though you are just writing just another linux C/C++ program so there isnt much excitement there (related to a specific platform, the entertainment is the same for all platforms) and very little arm knowledge required if any. It is very easy to use any of these platforms for bare metal programming giving you race car like performance compared to the ARM based microcontrollers.
I have a thumb simulator which you are probably not interested in. gdb has the armulator which was the cornerstone of the company back in the day. skyeye or something like that has an arm instruction set simulator as does qemu, none of them will give you great visibility other than what gdb can provide. opencores has the amber project an armv2 clone, which you can see the close relationship to the armv4 and newer that you will not find rtl for without a box full of cash. with my arm and chip experience (No I do not work for arm) I do find the amber project worth looking at, but many folks wont know what to do with it and really are not interested in that level of visibility. (it is instruction compatible, a good design, but dont think you are looking at an arm design, no secrets there). you can learn the basic arm architecture from it and then move on to hardware for example...
With the microcontrollers being cortex-m based, you might find the older microcontrollers a better stepping stone to the upper end arm cores. ARM7tdmi based stuff like the sam7s and others from nxp, st, atmel, etc which you can still find at sparkfun and microcontroller pros and other places for arduino like prices.
I am looking for a modern system to do some bare bones Assembly programming (for fun/learning) that does not have the legacy burden of x86 platforms (where you still have to deal with BIOS, switching to protected mode, VESA horrors to be able to output pixels to the screen in modern resolutions/colordepths etc.). Do such systems even exist? I suspect it is not even possible today to do low-level graphics programming without dealing with proprietary hardware.
qemu is likely what you want if you dont want to have to build that stuff in. You wont get as much visibility as to what is going on in the guts of it.
For hardware, beagleboard (dont get the old one get the new one with reasonable connectors, etc), or the open-rd board. I was disappointed with the plug computer thing. The hawkboard I like better than the beagleboard, but am concerned about the big banner about a pcb design problem. The raspberry pi will be out at some point and will also provide what you are looking for. Note that for beagleboard, etc, you dont have to run linux or anything like that, you can write your own binary and xmodem it over or use the network and then just run it, not a problem at all.
The stellaris eval boards all/most have oled displays, monochrome and small but graphics, not sure how much you were after.
earth-lcd used to have an arm based board with a decent sized panel on it.
there is of course the gameboy advance and the nintendo ds. flash/developer cartridges are under $20. the gba is better to start with IMO, as the nds is like two gbas competing for shared resources and a little confusing. with a ez flash cartridge (open source software to program), was easy to put a bootloader on the gba and for like another $20 create a serial cable, I have a serial based bootloader for loading the programs. If you have an interest in this path start with the visual boy advance emulator to get your feet wet and see how you feel about the platform.
If you go to sparkfun.com there are likely a number of boards that either already have lcd connectors that you would mate up with a display or definitely displays and breakout boards that you could connect to a number of microcontroller development boards. Other than the insanely painful blue leds, and the implication that there is 64KB (there is but non-linear 32KB+16+16) the mbed board is nice, up to 100mhz, cortex-m3. I have some mbed samples at github as well that walk you through building an arm binary too boot an arm from flash for those that have not done it (and want to learn that rather than call some apis in a sandbox).
the armmite pro and the maple (sparkfun) are arm based arduino footprint platforms, so for example you can get the color lcd shield or the gameduino
There is the open pandora project. I was quite dissappointed with the experience, after over a year paid another fee to get the unit and it failed within a few minutes. Sent it back and I need to check my credit card statement, maybe we took the return and give it to someone who wants it path. I have used the gamepark gp32 and gpx2, but not the wiz, the gpx2 was fine other than some memory I/O problem in the chip that caused chaotic timing. the thing would run just fine but memory performance was all over the map and non-deterministic. the gp32 is not what you are looking for but the gpx2 might be, finding connectors for a serial cable might be more difficult now that the cell phone cable folks used to cut up is not as readily available.
gen 1 ipod nanos can still be had easily, as well as the older gen ipod classics. easy to homebrew, the lcd panels are easy to get at. grayscale only, maybe only black and white I dont remember. All the programming info is had from the ipodlinux folks.
I have not tried it yet but the barns and noble folks are homebrew friendly or as friendly as anyone on that scale has been so far. the nook color can easily be turned into a generic android device, so I assume that also means you could develop homebrew on the metal, not sure though, have not studied it.
You might look at always innovating, my experience with them was similar to the open pandora folks. These folks started with a modified beagleboard in a box with a display and batteries, then added a couple more products, any one of them should be very open, and homebrew friendly so you can write whatever level you want, boot and run on the metal, no problem. For the original product it was one of those wait for several months things.
I am hoping the raspberry pi becomes the next beagleboard but better.
BTW all hardware is proprietary, it is just a matter of whether they choose to provide programming information or not. vesa came about because no two vendors did it the same way, and that has not changed, you have to still read the dataseets and programmers reference manuals. But as you can see above I have only scratched the surface, and covered the sub or close to $100 items. If you are willing to pay in the thousands of dollars that greatly opens the door to graphics based development platforms that are well documented and relatively sandbox free. many are arm based since arm is the choice for phones, etc and these are phone-like, tablet-like, eval platforms.
The Android emulator is such a beast; it runs a linux kernel and driver stack (including /dev/fb) that one can log into via the android debugger bridge, and run (statically linked) arm-linux-eabi applications. Framebuffer access is possible; see example.
The meta-question rather is, what do you mean by "low-level" graphics programming; no emulator is going to expose all the register and chip state complexity that's behind a modern graphics chip pipeline. But simple framebuffer contents manipulation (pixel buffer access) is surely simple enough, as is experimenting with software rendering in ARM assembly.
Of course, things that you can do with the Android emulator you can also do with cheap physical ARM hardware, like the beagleboard and similar. Real complexity only begins when you want to access "advanced" things - that's anything accelerated functionality beyond just reading/writing framebuffer contents.
New Answer
I recently came across this while looking for emulators to run NetBSD on, but there's a project called GXemul that provides a full-system computer architecture emulation with support for a variety of virtual devices and CPUs. The primary and most up-to-date core looks to be MIPS-based, but it also lists support for emulating the ARM architecture. It even includes an integrated debugger and it sounds like you can just assemble your code into a raw binary with some bootstrapping code and boot it as a kernel inside the emulator from the commandline.
Previous Answer
This isn't an emulator, but if you're interested in having a complete, ARM-based computer that you can develop whatever you want on that doesn't cost much, you should keep an eye on the Raspberry Pi project. They're very close to selling a complete, tiny, low-power ARM-based computer for $25 a piece. It has USB ports, ethernet, video out, and an SD card reader, and can boot Linux, although in your case you'd probably want to boot your own code and access the hardware directly.
EDIT: Looks like Erik already mentioned it.
Next term, I'll need to write a basic operating system for Motorola 68K processor as part of a course lab material.
Is there a Linux emulator of a basic hardware setup with that processor? So my partners and I can debug quicker on our computers instead of physically restarting the board and stuff.
Is it possible to apply test-driven development technique to OS development? Code will be mostly assembly and C. What will be the main difficulties with trying to test-drive this? Any advice on how to do it?
I would recommend developing an operating system for the classic Amiga computers, which had different versions of the 68000 processor. Since the Amiga computer is a complete computer and is extremely well documented, I thought this would be a good exercise.
There is an emulator for it called UAE (and Win-UAE) which is very exact and
can be configured with different kinds of processors (68000 - 68060) and other capabilities. Normally, you would also need to acquire ROMs for it, but since you are developing an operating system yourself, this is not necessary.
Tools you will need is either Cygwin (for developing under Windows) or a Linux computer. Then you will need cross compilers. This includes both a C compiler and an assembler. Here is a template for creating a simple ROM which changes screen color and flicks the power LED. It will create a file 'kick.rom' which UAE then searches for in the current directory.
Reference on the 68000 instruction set can be found at the links below. Be aware that different assembler programs may use slightly different syntax and instruction set.
If you need to demo the operating system on real hardware, there are modern Amiga clones sold on Ebay and other places. Search for "Minimig".
Update:
Nowadays AROS also runs on UAE as well as physical Amigas.
Refs:
[UAE]
[WinUAE]
[Cygwin]
[Cross Compilers]
[68000 reference]
I would suggest QEMU for m68k emulation.
(The system emulator you want in QEMU is "Coldfire" - that's what Freescale calls the successor to the m68k architecture).
You certainly can tdd this project. First off decouple all accesses to the hardware with simple routine calls, e.g. getch() and printf, then you can provide simple mocks that provide test input and check output. You can then write well over 90% of the project on a PC using gcc, msdev or xcode. Once you have got some confidence in the decoupling routines you will need very little access to the hardware, and only then to occasionally check that your mocks are acting as you expect.
Keep to C until you find a particular bottle neck, and only then resort to assembler.
There are a few new projects that use hardware simulated 68000 cpus, the C-One project, the Minimig (Mini Amiga) project and the Natami (Native Amiga) project - they are new 68k compatible Amiga systems.
C One, reconfigurable computer, Minimig, in development, prototypes done: FPGA Arcade and Natami.
The Easy68k http://www.easy68k.com simulator might help you.
The uClinux project started on a m68k board. They may have the tools you need...