I want to be able to debug the Quark SoC on the Intel Galileo Board from the reset vector (or close to it).
I know that OpenOCD can't do a direct reset/break debug since the ARM JTAG interface on the board doesn't include the two necessary pins for such procedure.
I am trying the latest beta version of the Intel System Studio 2015 and I am using OpenOCD to debug on the Intel XDB for the Quark. It was suggested that, once I had control of the target I can issue a soft reset that would stop the target on an address that would be very close to the reset vector if not the reset vector itself. I must say that I am pretty clueless about achieving this. I got access to the Quark and I am able to see the trace and the registers, but I don't understand how to get the XDB to do a soft reset on the target and stop just or on the reset vector.
I tried using the efi "loadthis" command on the XDB> command line; it didn't work since I don't know the address of the EFI header, but this may be the wrong approach.
If I manage to get the target to do a soft reset, how would I make it stop right after the reset? I may need to set a break point, but I don't know which address should I target for such break.
I would really appreciate any information on this issue since it is very important for me to do UEFI/BIOS debug for what I am trying to do.
Thank you beforehand for any help you may be able to provide.
you can use the reset icon in the GUI menu:
You can use efi loadthis in two ways, with or without an address. Without it will look for a module header starting at the current instruction pointer. With an address it will look for a header at that address. Try also efi 'loadfrommap <filename>" this will try to load all symbols of the modules in the map file. If you want to load only one of the modules use efi 'loadmodfrommap <filename> <modulename>" Regards, Paul
Intel System Studio 2015 can't really stop at the reset vector.In my case it always skipped a great deal of code before stopping after reset. I guess this was a consequence of the way in which I had my PC configured making the USB connection to have a long delay before sending the stop command to the debugger. In my case, I am using the ARM-USB-OCD-H debugger from Olimex.
This is what I did to achieve what I wanted:
1.) I modified the reset vector to point to address 0xfffff666 on the first jump an add a Jmp $ instruction at that address (0xfffff666). There is no sensitive code at that address; only a bunch of 0s which I think are there only for segment alignment. At least, for the purpose of debugging the boot loading process this worked well.
2.) Once I followed the procedure described by Paul Farquhar in the above post the XDB stopped at 0xfffff666; then, I modified the IP to point to the original first address of code after the jump at the reset vector; i.e. I filled IP with 0xfffff668 and debugged the code step by step.
Note: I tried to add the Jmp $ at the reset vector to start from there, but either the debugger or the processor refused to proceed with a modified IP at the reset vector. Maybe I misunderstood the addressing at the reset vector, but the procedure explained here (placing the Jmp $ just before the original address after jump and modifying the first jmp at the reset vector to point to 0xfffff666) worked perfectly.
Note 2: I made a copy of the whole flash memory before modifying the code in order to keep a backup and in order to be able to do the modifications and reprogram the memory for debugging.
Please, let me know if you need some additional information here.
Some additional information.
This is how the reset vector and the code at the destination of the first jump after reset looks like in the original code:
Code at the destination of the first jump after reset:
And this is how the reset vector and the code at the destination of the first jump after reset looks like after the modifications that allowed me to debug (almost) from the reset vector:
Modified Reset Vector:
Modified code at the destination of the first jump after reset:
Note that the actual address in the flash memory device is not actually 0xffff... but 0x007f... since the flash memory device on the Galileo board is only 8 MB in size. Nevertheless, for the processor the actual address looks like 0xffff...