Development and debugging of UEFI drivers on Intel Galileo, part 3: we begin hardware debugging

  • Tutorial

Hello, dear readers of Habr.
After a short break, I continue to publish my notes ( first , second ) on the development and debugging of UEFI components on the Intel Galileo open hardware platform. In the third part, we will talk about connecting a FT2232H-based JTAG debugger to Galileo and setting up a debugging environment for it.

Entry and disclaimer

According to the already established tradition, it should be mentioned that you use all of the information below at your own peril and risk, the author is not responsible for possible loss of board performance, time, mood and / or faith in humanity. Everything described is drawn from open sources, a list of which is given at the end of this article, and this publication cannot be considered a violation of the NDA on my part.

A starting point

At the moment, I assume that you already have an Intel Galileo board for which you have compiled the firmware and image of Yocto Linux and can do it again at any time. I will not dwell on the assembly of software for Galileo in this part of the article - read the last part , if necessary.
It also implies that you have a debugger that is compatible with OpenOCD, best of all - based on the FTDI FTxx32H series of chips , because these are the ones used by Intel engineers to write and test debugging tools for Galileo. I can not guarantee that other debuggers will not work - I did not check. In this article, I will use the breakout board on the FT2232H as a debugger, which differs from the "adult" debuggers on the same chip only in the absence of a beautiful case and a chip for shifting logic levels, is not needed for debugging on Galileo.

Iron part

With the iron part, everything is quite simple - you just need to correctly connect the contacts of the JTAG connector on the Galileo with the necessary FT2232H terminals.
The outputs of FTxx32H series chips are marked with xyBUSz, where instead of x is the channel designation (A, B, C or D), instead of y is the designation of the first (D) or second (C) set of outputs of each channel, and instead of z is the output number ( 0-7 for the first and 0-9 for the second set of conclusions).
To work with JTAG, you need to connect as follows:
xDBUS0 <-> TCK
xDBUS1 <-> TDI
xDBUS2 <-> TDO
xDBUS3 <-> TMS
TRST can be connected to any free output of the same channel, in my case it is xCBUS0, you can use any other, but you will have to make the corresponding change in the OpenOCD configuration.

Software part

We get Intel System Studio
But here everything is a little more complicated, especially for Windows users who have no way to run sudo apt-get install openocd and after 10 seconds start writing the configuration for their debugger. The guys from Intel know about this, and therefore included OpenOCD and GDB in the distribution kit of Intel System Studio 2015 Beta, which can be downloaded from here after registration . It also has an Intel System Debugger, which acts as a GUI for GDB and is designed for those who have not yet comprehended Tao enough to work with it directly from the console. Your humble servant has already embarked on this Path, but it is difficult, and the temptation to use the GUI is great, because Intel added support for UEFI debugging not so long ago. As a result, I succumbed, I propose to succumb to you.
After registering, downloading and installing ISS, you need to take several additional steps: write a configuration for your debugger (by default there are configurations only for TinCanTools FLYSWATTER2 and Olimex ARM-USB-OCD-H ), connect debugging symbols so that you can debug C code, not in assembler. On Windows, you will also need to install the libusbK driver for the selected debugger channel instead of the standard FTDI driver so that OpenOCD can find it. Let's get started.

We write a configuration for OpenOCD
Setting up OpenOCD usually consists of two parts: writing the configuration of the debugger and the board being debugged. Good Intel developers saved us from the second, and we will do the first by analogy. Go to the directory where you installed System Studio, and from there - to debugger \ openocd \ scripts \ interface \ ftdi , and copy the file olimex-arm-usb-ocd-h.cfg , naming a copy of debugger.cfg . Open the resulting file in your favorite editor and delete the lines ftdi_device_desc , ftdi_layout_signal nSRST , ftdi_layout_signal LED , in the line ftdi_vid_pid change the VID and PID of the debugger to your values. If you use channels B, C or D, add the line ftdi_channel 1 ,ftdi_channel 2 or ftdi_channel 3 respectively. Save changes and configuration for your debugger is ready.
If you want to know what magic numbers in the ftdi_layout_init line mean , configure additional signals or transfer TRST from xCBUS0 to another output - welcome to the documentation .
Ready debugger.cfg for breakout board on FT2232H
interface ftdi
ftdi_vid_pid 0x0403 0x6010
ftdi_channel 0
ftdi_layout_init 0x0c08 0x0f1b
ftdi_layout_signal nTRST -data 0x0100 -noe 0x0400

Install the libusbK driver
Linux users can safely skip this step because they have the correct driver already installed. Windows users need to install the aforementioned driver instead of the standard one. There are several ways to do this, the easiest of which, in my opinion, is to use the Zadig utility . Download and run the latest version, check the List All Devices checkbox in the Options menu , select your device from the list, select libusbK as the driver and click the Replace Driver button .
If everything is done correctly, the program window will look something like this:

Checking the operation of OpenOCD
Now you need to verify that the debugger is connected correctly and OpenOCD can use it to access Galileo via JTAG. To do this, you need to run openocd, specifying the configuration files for the debugger (debugger.cfg created in the first step) and for the board (included in the ISS package) as parameters. To do this, run the command line from the administrator, change the current directory to debugger \ openocd \ bin , and from there run the command
openocd -f .. \ scripts \ intefrace \ ftdi \ debugger.h -f .. \ scripts \ board \ quark_x10xx_board.cfg
If you did everything correctly, the command will output approximately the following:
Info : clock speed 4000 kHz
Info : JTAG tap: quark_x10xx.cltap tap/device found: 0x0e681013 (mfg: 0x009, part: 0xe681, ver: 0x0) enabling core tap
Info : JTAG tap: quark_x10xx.cpu enabled
If you have instead only
Error: libusb_open() failed with LIBUSB_ERROR_NOT_SUPPORTED
it means something is wrong either with the driver or with the debugger configuration.

We get debugging symbols
If the firmware assembly for Galileo described in the previous part occurred on your main system, you can skip this step. It happened to me in a virtual machine, so for source-based debugging you need to get the source code of the firmware and files with debugging information from it.
Copy the directory Quark_EDKII_vX.YZ from your home directory to the VM on the desktop of the main OS, start Intel Debugger with the xdb_remote script (in Windows, the link to it is in the menu Start-> ISS-> Debugger Startup-> Quark SoC ), open the Options- window > Source Directories ..., create a rule on the first tab to replace the old path to the copied directory with a new one, in my case it is "\ home \ congatec \ Galileo" -> "C: \ Users \ Nikolaj \ Desktop", and on the second tab add the same directory to the list Source Directories. Both of these actions will help the debugger to independently find the source code of the debugged modules.

Connect to Galileo
Launch OpenOCD and Intel Debugger as described above, click Reset on Galileo, and then the Connect button in the debugger window. If a listing of the module that stopped when connecting the debugger appeared in the Assembler window - fine, you can proceed with hardware debugging. To check if there is an error in the previous step, stop in the DXE phase (3-5 seconds after the board reboot) and enter the efi "setsuffix .debug" and efi loadthis commands in the xdb> prompt. If everything was done correctly, then the debugging symbols will be loaded successfully, and the debugger will go from the Assembler tab to the source editor. If you get a “System Table Not Found” message in response to loadthis, try stopping execution a little later or a little earlier.

Conclusion and plans

In the next part of the article, we will write a simple DXE driver, we will establish a quick assembly of the firmware with it and try to debug it using Intel Debugger prepared in this article, as well as other debugging tools. Thank you for your attention, see you in the next part.
PS Dear UFO, maybe now you can add a profile UEFI hub ? It would be great.


Interfacing FTDI USB Hi-Speed ​​Devices to a JTAG TAP | FTDI Application Note
Debug Adapter Configuration | OpenOCD Documentation
Source Level Debug using OpenOCD / GDB / Eclipse on Intel Quark SoC X1000 | Intel Application Note

Also popular now: