Intel Sytem Studio 2015 (beta), OpenOCD Quark Real Mode Debug

[JBlac9]

Is it possible to debug the Quark SoC with Intel System Studio 2015 (Beta) and an OpenOCD probe? 

The processor always stops at the address 0x0008:0xFFFFFA72 when following the steps state below. When the debugger halts the processor at address: 0x0008:FFFFFA72, the processor is already working in protected mode, so my technique of rewriting the EIP to go back to the address in memory pointed by the jmp instruction (see the steps below) at the reset vector is useless.

Is there a way of debugging in real mode or stopping the processor before it enters protected mode?

STEPS

This is what I have done:

I have tried the steps suggested in this comment: https://software.intel.com/en-us/comment/1799840#comment-1799840. 

So far, what is suggested in the comment works since it stops some few instructions after the jmp instruction declared at the reset vector; there are some tricks that have to be implemented though. These have been useless so far since by the time the processor stops it is already in protected mode. This is what I did step-by-step:

Before Anything
-------------------------------------------------------------------------------
1.) Connect the Olimex ARM-USB-OCD-H to the PC
2.) Use Zadig.exe, an automated driver installer. You can obtain the software
    at: http://zadig.akeo.ie
3.) In Zadig, set the Options -> List All Devices if no device is shown in the
    interface's drop down menu.
4.) In the drop down menu chose the "Olimex OpenOCD JTAG ARM-USB-OCD-H 
    (Interface 0)"
5.) Select the WinUSB (*Most recent version) and push the button.
6.) Do the same for interface 1 if the Olimex probe.

Start Debugging
-------------------------------------------------------------------------------
1.) Make sure the Galileo board is unplugged.
2.) Plug the Olimex probe to the Galileo board.
3.) Plug in the Galileo board's power supply.
4.) Star the OpenOCD debugger as suggested by Intel System Debugger (year)
    Installation Guide and Release Notes on the section concerning the Quark
    SoC and OpenOCD debugging.
5.) Star the Quark SoC (Using OpenOCD) batch (icon) provided by Intel System
    Studio.
6.) Connect the XDB to the device.
7.)    Hold the Reboot button on the Galileo Board.
8.) Click the "restart" button on the XDB.
9.) Make sure that it runs for as short as possible and hit the "halt" button.
10.) The XDB should stop very close to the address where the reset vector
     declares the first near jump. (In my case it stops at address 0x0008:0xFFFFFA72)
11.) Load the CS with this value: 0x0008
12.) Load the EIP with this value: 0xFFFFF668 (The address of the near jump at
     the reset vector).
13. Start debugging.

Note: I am using the Galileo's "Flash-missingPDAT_Release-1.0.2.bin" provided on the Galileo's download website. There is a new version, but changing the file will not make a difference in this case.

[Paul_F_Intel · Accepted solution]

To answer your question: Yes it is possible to debug the Quark SOC with Intel® System Studio - but not from the reset vector.

The reason as we have discussed is the lack of hardware control to hold the CPU after reset.

So the debugger will try to reset and stop as quickly as possible to get as close as possible to the reset vector.

What I do is only use the reset command / icon in XDB. I don't press the reset switch on the Galileo. Doing that about 2 out of 10 times the debugger comes out in real-mode - which is not bad as in my BIOS version there are only a few instructions from the reset vector until the instructions to switch to protected mode. Sometimes I even land at FFF2.

If you really need to debug those first few real-mode op-codes then you will have a hard time catching the target with the debugger.

To workaround this issue you could program an endless loop into the first op-codes . Then every reset will arrive in this endless loop. Set the IP to the next op-code to debug the rest.

This is of course not suitable for production BIOS but OK for debugging.

[JBlac9]

Paul

Thank you, this is what I needed to know.

I am implementing a version of firmware that does quite more in real mode before entering protected mode; I am using the Galileo image provided by Intel to test my debugging strategies.

I will try the loop; this seems like a good debugging strategy for a short real mode code.

Best regards