Yes, it’s possible. But pretty hard.
Too bad, initializing an IA processor isn’t as easy as an on other architectures.
After a reset, the IA core is starting in real mode and fetching instructions from flash. There isn’t any available memory at this moment.
That’s when normally a BIOS/UEFI kicks in and starts to initialize the components of the SOC/platform (e.g. memory controller).
After this is done, the BIOS hands it over to an bootloader (on Galileo it’s grub which then ‘starts’ a Linux kernel)
If you really want to do bare metal IA programming, I recommend this reading:
There you will learn how to bring an IA processor from real into protected mode and what protection and paging is.
Writing such code is fun BTW, and you will learn a lot about IA architecture.
You probably need a good embedded JTAG debugger to debug that code. OpenOCD is working on Quark/Galileo support. A patch is already public available.
To be really productive, I would recommend to start writing code AFTER the platform initialization – which means after the BIOS.
Replacing the Linux kernel and write an ‘application/mini-OS’ that is called from BIOS or bootloader might be more promising.
Thanks. This looks really interesting to do. but is there any document which explains this process or way to achieve it?
the manuals seems to contain large information of IA processors. What I was expecting was to able to stop this sequence of booting and going to grub.Also, I don't want to use SD card. There are Documents showing connection through serial port. Can't i get that through USB client port that is generally connected to load the program?
Te The USB connection was designed mainly for the Arduino Sketches (loading and debugging) and the RS232 UART was developed for serial connection (Linux) https://communities.intel.com/thread/46560 . Regarding the Programing document you will find useful information provided by Thomas_Faust_(Intel) using JTAG or OpenOCD with a “how to” called "Source Level Debug using OpenOCD/GDB/Eclipse on Intel® Quark SoC X1000” (https://communities.intel.com/docs/DOC-22203). Reference discussion: https://communities.intel.com/thread/48127
Also the set of instructions for the SoC X1000.
1 of 1 people found this helpful
I would like to merge these 2 similar threads, because you are asking the same question.
JTAG Debugger Compatibility with Intel Galileo
Is it possible to use intel galileo for bare metal programming?
In short: Yes, it is possible to write an on 'program' and run it bare-metal - also by using OpenOCD to 'download' the program into memory. Writing it to SPI and execute/debug from there is also possible.
Not a little bit longer: To do so, you need 'some' understanding of the IA architecture. If you write something bare-metal, you need to understand what real-mode is and what instructions are necessary to bring the CPU into protected mode. You also need to understand that you don't have access to memory or any other device after a reset. To set-up the SOC you need many, many, many lines of code. This code is BTW: called UEFI (aka BIOS) and is available in source code for Quark. If you seriously looking into bare-metal programming, I would start there and build/compile/look at the code/flash to SPI and run it first.
On the other hand, I don’t think that's what you really want (other than for educational reasons or to fulfill the maker spirit of learning new things). To write some 'programs' (other than Linux user mode applications or Arduino sketches) you can write a mini-OS that boots after UEFI or even write a UEFI module that is doing what you want (both options are more promising to get something useful out of it than starting from 'scratch' at reset vector)
If you can give me some more inside into your project and what you want to achieve with it, the community (or I) might be able to help you better.
@Sanket: Good you have OpenOCD up and running. Can you explain more on the eclipse issue? I can help you to set-up gdb/eclipse in top of OpenOCD. Did you followed the instructions in this document? Where do you stuck?
"Source Level Debug using OpenOCD/GDB/Eclipse on Intel® Quark SoC X1000 Application Note"
Thank you for explaining different options.
I wanted to use Intel Galileo to run my Assembly code(Something similar to Intel 8051 - micro controller). Which will just include flashing my code to board and using the GPIO and interrupt features of IA. As part of learning i also want to debug and test different registers during program execution.
The reason to do this is to use the same board for learning Assembly as well as high level language programming. I am new to IA but pretty much experienced with Assembly for 8085, 8051, ARM.
For the installation part, I have completed section 3.1, 3.2, 3.3. I did not do 3.4 and 3.5 as i do not want to debug kernel source. then i completed 4.1 and it worked well as per the doc.
My idea was to create sample project in eclipse which i can use to flash and debug. But i discovered that there is no configuration in Eclipse which suggested that this project supported Intel quark or IA assembly programming. Is there something that i am missing?. To be precise, I downloaded SDK from Intel links : Open Source Downloads
Hope you got my point!
Writing Assembly code for IA is complex –but a lot of fun and very, very educating. You learn a lot about the architecture.
Here is a recommended reading for you. It explains things like Pre-boot Sequence, IA operation modes ( real mode, protected mode, SMM), early initialization, Memory Configuration and Initialization aso.
Booting an Intel Architecture System, Part I: Early Initialization
Booting an Intel Architecture System, Part II: Advanced Initialization
Some years ago a friend of mine published a document that is a good read as well:
Minimal Intel Architecture Boot Loader - Bare Bones Functionality Required for Booting an Intel Architecture Platform
These seems to be good learning articles and very helpful.
Once I complete the initializing part, I can then use openOCD debugger to write my initialized code to Intel Galileo. Am i right?
How does that process help me?
I am still not clear on the coding part. Which tools can i use to write code for initializing. The document states that I need to change the mode of the controller to "Flat protected Mode" and various features it provide. But the real thing is how to do that in code(I saw the software manual : http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-instruction-set-reference-manual-325383.pdf)
what compiler can i use to compile the code written in Assembly?
After quit a few try I managed to get access to Intel quark board using "insight GUI". This makes visualization of registers and memory easy.
Then I loaded an Assembled x86 code to the board. The image shows the loading process getting completed successfully and instruction pointer set to the starting address of the code.
When I checked the actual contents of the memory pointed by instruction pointer. This was not the code that I was expecting. After searching on web what actually this code was doing I found this:
The loader does much work for you setting up your re-locations, and as we'll see much later, calling your preinitializers. When everything is ready, control is handed to your program by calling following :
xor of anything with itself sets it to zero. so the xor %ebp,%ebp sets %ebp to zero. This is suggested by the ABI (Application Binary Interface specification), to mark the outermost frame. Next we pop off the top of the stack. On entry we have argc, argv and envp on the stack, so the pop makes argc go into %esi. We're just going to save it and push it back on the stack in a minute. Since we popped off argc, %esp is now pointing at argv. The mov puts argv into %ecx without moving the stack pointer. Then we and the stack pointer with a mask that clears off the bottom four bits. Depending on where the stack pointer was it will move it lower, by 0 to 15 bytes. In any case it will make it aligned on an even multiple of 16 bytes. This alignment is done so that all of the stack variables are likely to be nicely aligned for memory and cache efficiency, in particular, this is required for SSE (Streaming SIMD Extensions), instructions that can work on vectors of single precision floating point simultaneously. In a particular run, the %esp was 0xbffff770 on entry to _start. After we popped argc off the stack, %esp was 0xbffff774. It moved up to a higher address (putting things on the stack moves down in memory, taking things off moves up in memory). After the and the stack pointer is back at 0xbffff770.
When I then tried to step to next instruction using the "si" command, the instruction pointer moved to different location and remained there for long time. This I assume it to be segmentation error and so it moves towards this location(0xc100945c).
Can someone explain why this is going to this location when the code was already existing and does not change even when I load new programs?
If this piece of program is not creating the error, how should I debug the issue?
my Assembler and simulator shows that the program runs without error(I tried with gcc as well as nasm assemblers)