I'm trying to write emulator for ARM Cortex M3. How can I read the binary file then decode it? I want to use binary files as a resource of my emulator. I created a project with Atmel Studio and I compiled it. Now, I have a .hex file. I can also convert this file to binary file with hex2bin. After that, how can I use that binary file for fetching and decoding instructions ? I'm working on Visual Studio with C/C++.
First, need to mention that writing an emulator for a processor is not an easy task, other have already spend lot of time on it, you can take a look at QEmu for example. One project is currenlty using Qemu to emulate a Cortex M3 based board, the ZephyrProject.
An intermediate step, could be to use a tool that already understand/decode hex or bin file, and Radare is one of those kind of tool. With it you will be abvle to disassemble many elf files and get the instructions from it (that you'll then have to emulate ;) ).
That said, if you still really want/need to make the emulation, and start to read and understand the hex or binary files, the first thing to do will to study the Intel Hex file format (yes, even ARM is using this Intel format ;) ).
You can find the official specification here or in the technical support website of ARM.
Have fun ;)
Related
I'm a newbie to learning OS development. From the book I read, it said that boot loader will copy first MBR into 0x7c00, and starts from there in real mode.
And, example starts with 16 bit assembly code.
But, when I looked at today's linux kernel, arch/x86/boot has 'header.S' and 'boot.h', but actual code is implemented in main.c.
This seems to be useful by "not writing assembly."
But, how is this done specifically in Linux?
I can roughly imagine that there might be special gcc options and link strategy, but I can't see the detail.
I'm reading this question more as an X-Y problem. It seems to me the question is more about whether you can write a bootloader (boot code) in C for your own OS development. The simple answer is YES, but not recommended. Modern Linux kernels are probably not the best source of information for creating bootloaders written in C unless you have an understanding of what their code is doing.
If using GCC there are restrictions on what you can do with the generated code. In newer versions of GCC there is an -m16 option that is documented this way:
The -m16 option is the same as -m32, except for that it outputs the ".code16gcc" assembly directive at the beginning of the assembly output so that the binary can run in 16-bit mode.
This is a bit deceptive. Although the code can run in 16-bit real mode, the code generated by the back end uses 386 address and operand prefixes to make normally 32-bit code execute in 16-bit real mode. This means the code generated by GCC can't be used on processors earlier than the 386 (like the 8086/80186/80286 etc). This can be a problem if you want a bootloader that can run on the widest array of hardware. If you don't care about pre-386 systems then GCC will work.
Bootloader code that uses GCC has another downside. The address and operand prefixes that get get added to many instructions add up and can make a bootloader bloated. The first stage of a bootloader is usually very constrained in space so this could potentially become a problem.
You will need inline assembly or assembly language objects with functions to interact with the hardware. You don't have access to the Linux C library (printf etc) in bootloader code. For example if you want to write to the video display you have to code that functionality yourself either writing directly to video memory or through BIOS interrupts.
To tie it altogether and place things in the binary file usable as an MBR you will likely need a specially crafted linker script. In most projects these linker scripts have an .ld extension. This drives the process of taking all the object files putting them together in a fashion that is compatible with the legacy BIOS boot process (code that runs in real mode at 0x07c00).
There are so many pitfalls in doing this that I recommend against it. If you are intending to write a 32-bit or 64-bit kernel then I'd suggest not writing your own bootloader and use an existing one like GRUB. In the versions of Linux from the 1990s it had its own bootloader that could be executed from floppy. Modern Linux relies on third party bootloaders to do most of that work now. In particular it supports bootloaders that conform to the Multiboot specification
There are many tutorials on the internet that use GRUB as a bootloader. OS Dev Wiki is an invaluable resource. They have a Bare Bones tutorial that uses the original Multiboot specification (supported by GRUB) to boot strap a basic kernel. The Mulitboot specification can easily be developed for using a minimal of assembly language code. Multiboot compatible bootloaders will automatically place the CPU in protected mode, enable the A20 line, can be used to get a memory map, and can be told to place you in a specific video mode at boot time.
Last year someone on the #Osdev chat asked about writing a 2 stage bootloader located in the first 2 sectors of a floppy disk (or disk image) developed entirely in GCC and inline assembly. I don't recommend this as it is rather complex and inline assembly is very hard to get right. It is very easy to write bad inline assembly that seems to work but isn't correct.
I have made available some sample code that uses a linker script, C with inline assembly to work with the BIOS interrupts to read from the disk and write to the video display. If anything this code should be an example why it's non-trivial to do what you are asking.
I am trying to load an ascii file into memory using the command line and I would like to know if there is a command that does it using ARM DS-5 IDE.
I have in the past use the previous ARM tools (RVDS) and been able to perform this task using the readfile command.
Thanks in advance.
The DS-5 loadfile and load commands will annoyingly only work with executable images because they both demand to know an entry point address. Simply putting arbitrary data (such as your text, or a raw binary like a Linux zImage) into the target's memory is done with very-unintuitive-named restore command, with which you still have to add the binary argument to avoid getting the same error as the others about not understanding the file format.
ARM Infocenter: DS-5 File-related commands
Considering that C is a systems programming language, how can I compile C code into raw x86 machine code that could be invoked without the presence of an operating system? (IE: You can assume I have a boot sector that loads the raw machine code from disk into memory then jumps directly to the first instruction).
And now, for bonus points: Ideally, I'd like to compile using Visual Studio 2010's compiler because I've already got it. Failing that, what's the best way to accomplish the task, without having to install a bunch of dependencies or having to make large sweeping configuration changes across my entire system? I'd be compiling on Windows 7.
Usually, you don't. Instead, you compile your code normally, and then (either with the linker or some other tool) extract a raw binary from the object file.
For example, on Linux, you can use the objcopy tool to copy an object file to a raw binary file.
$ objcopy -O binary object.elf object.binary
First off you dont use any libraries that require a system call (printf, fopen, read, etc). then you compile the C files normally. the major difference is the linker step, if you are used to letting the c compiler call the linker (or letting some gui do it) you will likely need to take over that manually in some form. The specific solution depends on your tools, you will need to have some bootstrap code (the small amount of assembly that is needed to cover the assumptions of C compilers and programmers and launch the entry point in your C program), and a linker script or the right command line options for the linker to control the address space for the binary as well as to link the objects together. Then depending on the output format of the linker you might have to convert it to some other binary format (intel hex, srec, exe, com, coff, elf, raw binary, etc) to be compatible with wherever it is going to be loaded or run.
I was wondering if there was a way to set the compiler to compile my code into a .bin file which only has the 1's and 0's, no hex code as in a .exe file. I want the code to run on the processor, not the operating system. Are there any settings to set it to that in the Express edition?? Thanks in advance.
There is nothing magic about a ".bin" file. The extension generally just indicates a binary file, but all files are binary. So you can create a ".bin" file by renaming the ".exe" file that your linker generates to ".bin".
I presume you won't be satisfied with that, so I'll elaborate a little further. The ".exe" file extension (at least on Windows, which I'll assume since you've added a Visual Studio-related tag) implies a binary file with a special format—a Portable Executable, or PE for short. This is the standard form of binary file used on Windows operating systems, both for executables and DLLs.
So a PE file is a binary (".bin") file, but an unknown binary file with a ".bin" extension is not necessarily a PE file. You could have taken some other binary file (like an image) and renamed it to have a ".bin" extension. It just contains a sequence of binary bits in no particular format. You won't be able to execute the file because it's not in the correct, recognized format. It's lacking the magic PE header that makes it executable. There's a reason that C build systems output PE files by default: that's the only type of file that's going to be of any use to you.
And like user1167662 says in his comment, there is nothing magical about hex code. Code in binary files can be represented in either hex or binary format. It's exactly the same information either way. Any good text editor (at least, one designed for programmers), can open and display the contents of a file using either representation (or ASCII, or decimal).
I want it to be as low level as possible for optimal performance.
There is nothing "lower level" about it, and you certainly won't get any optimized performance. PE files already contain native machine code that runs directly on your microprocessor. It's not interpreted like managed code would be. It contains a series of instructions in your processor's machine language. PE files just contain an additional header that allows them to be recognized and executed by the operating system. This has no effect on performance.
To build an operating system.
Now, that's a bit different… In particular, it's going to be a lot more difficult than writing a regular Windows application. You have a lot of work ahead of you, because you can't rely on the operating system to do anything to help you out. You'll need to get down-and-dirty with the underlying hardware that you're targeting—a developer's guide/manual for your CPU will be very useful.
And you'll have to get a different build environment. Visual Studio is not going to do you any good if you're not creating a PE file in the recognized format. Neither is Microsoft's C++ linker included with it, link.exe. The linker doesn't support outputting "flat" binary files (i.e., those with the PE header stripped off). You're going to need a different linker. The GCC toolset can do this. There is a Windows port; it is called MinGW.
I also recommend a book on operating system development. It's too much to cover in an answer to a Stack Overflow question. And for learning purposes, I strongly suggest playing with an architecture other than Intel's x86.
I'm about to go through a Micro-Controller project which controls a robotic arm. My problem is that # MS Windows there are MikroElectronica (IDE: MicroC) compile .c to Hex put the hex in Proteus and simulate. Then using a special (PCB) Kit with CD (carries windows software) I would put the microchip and install the hex file or what ever.
First all the respect to Ms but I just hate it! I adore Ubuntu/linux and open-source I need from the experts to tell me in "Steps" how to do the previously mentioned in linux with minimal complications.
The Electrical and Mechanical Engineers along with me always brag about Ms is easy. I want to show them how Computer Science guy uses open-source technology and how strong and reliable it is.
Please help !
You wish to demonstrate the power of Linux by trying to run products designed for another operating system on it? Chances are those tools may work in Wine.
Or maybe you can use Hi-Tech C as a compiler and try gEDA for simulation. It is also possible to compile Microchip C30 on Linux if you are working on 16-bit PIC:s. In any case, this may not be as easy as using the out-of the-box Windows tools. It will be more educational, nevertheless.
If you can be flexible and opt for AVR then you will have free GCC compiler and programming tools. All open source and Linux/Mac friendly. More info at www.avrfreaks.com.
Here is a compiler, linker and simulator tutorial for PIC on linux. Here is one that uses SDCC c compiler. Google throws out lots of websites when you search for linux pic.
From my side, I cross-compile and program Microchip dsPIC from Linux but it is not really straightforward. Here are the big steps
First I built the C30 toolchain from Microchip sources (you need to apply a few patches on the given sources for it to compile).
Once you have the toolchain binaries, you will need to have the specific Microchip MCU resources. Those are coming with the C30 installation on a win32. I copied those files from the Windows installation folder onto my linux filesystem.
Here you should be able to compile and link some C & ASM code to a hex file through command line.
Second step, I wanted to build my projects within the Eclipse IDE. To do that we "just" had to write a couple makefiles to call our new C30 toolchain.
Third step, program the .hex onto your microchip MCU. Two ways to do it. If you have a Pickit2, Microchip provides a command line tool to play with it. I personally have an ICD2 programmer. I use the command line tool provided in the Piklab project.
Now I don't have any facility to debug with my ICD2 under Linux.
Now Microchip provides an alternative IDE with "Mplab X" which is based on Netbeans (sick) and should work under Linux and MacOS. But this project seemed to be yet under development, I don't know if it is really usable.