I would like to ask you a crucial question. I am trying to build a UEFI firmware for the Intel Galileo board which will be completely written in assembly language to be able to cun my custom OS also completely writen in assembly and I would like to ask you what are the debug possibilities i could use since the very begining of the board boot (from the reset vector).

I was wondering if I could use the board built-in LED diod to signalize ie. a checkpoint or so via the Legacy GPIO, but the LED is not powered directly from the GPIO od the SoC, but the SoC's GPIO is led to a multiplexer, out of which the LED is powered - and there's a problem that the selector pin of this multiplexer is not set HIGH in default and that the powering of this MUX's selector pin is maintained by a GPIO IC PCAL9535AHF (which is evident from the board schematic), which itself requires an I2C communication to be set, because it doesn't power the selector pin in default. But there's a problem that I cannot, god knows why, evidently work with the MMIO devices even though everything (every register) I had to initialize I initialized. So I need to do some debugging here.

I would also like to ask you how soon I am allowed by the SoC to use the PCI devices, both I/O mapped and MMIO, as I would like to use them as soon as possible, especially the output devices, such as GPIO, I2C etc.

Next I thought I could use the JTAG interface, which is admired by everyone, but when I run my code before the Stage 1 initialisation, the SoC refuses to enter the Probe mode on the TAP controller's request. When I readed through the

Intel® Quark™ SoC X1000 UEFI Firmware Writers Guide

and the

Intel® Quark™ SoC X1000 Datasheet

and opened the

Intel® Quark SoC X1000 Debug Operations User Guide,

there was written "Not all SKUs of the Intel® Quark SoC X1000 ship with JTAG debugging enabled. To receive details on how to enable JTAG on these SKUs, contact your Intel account team." in the part "2.1 SKU-Based JTAG Debug Capability".

So I am contacting you, dear Intel community, in order to ask you, whether and how it is possible to debug the pure assembly firmware from the very begining of the code execution or at least from the point right after switching to the processor's protected mode.

Thank you in advance for your interrest in my issues and for your competent answers.

Intel® Quark™ SoC X1000 contains eight GPIOs within the legacy bridge. These GPIO pins are interrupt-capable. They support rising/falling/both edge-triggered interrupts.These legacy GPIOs provide the ability to drive GPE events and hence to resume an Intel® Quark™ SoC X1000 device in a low-power state.There are:• 6 GPIO pins in the resume power well In the Intel® Quark™ X1000 Datasheet, these pins are referred to as GPIO_SUS[5:0]. The GPIOs in the resume well can be used to drive a General Purpose Event (GPE) through the ACPI sub-system that subsequently takes the Intel® Quark™ SoC X1000 out of a low-power state.• 2 GPIO pins in the core well In the Intel® Quark™ X1000 Datasheet, these pins are referred to as GPIO[9:8].The eight legacy GPIO are indexed in the range [0,7] and can be accessed from userspace through sysfs interface.To load the legacy GPIO driver, type: modprobe gpio-schThe commands below demonstrate how to drive a signal to the first legacy GPIO:root@quark# echo 0 > /sys/class/gpio/export # Reserve first legacy GPIOroot@quark# echo "out" > /sys/class/gpio/gpio0/direction # Set as outputroot@quark# echo "1" > /sys/class/gpio/gpio0/value # Drive logical one

The GPIO and I2C components are contained within the same PCI function and share resources as a consequence. This GPIO interface is a new register interface and is enabled by the GPIO section of the intel_qrk_gip device driver module. In the Intel® Quark™ SoC X1000 Datasheet, these pins are referred to as GPIO[7:0]. These GPIO pins are interrupt-capable. They support rising/falling edge-triggered interrupts (but not both edged interrupts) and high/low level-triggered interrupts.To load the GPIO driver in isolation (that is, without the I2C enabling logic contained in the GIP block) type:modprobe intel_qrk_gip i2c=0ormodprobe intel_qrk_gip i2c=0 enable_msi=0Note: MSIs are enabled by default. Disabling MSIs is not recommended for performance reasons.

The I2C register interface is 100% compatible with the upstream i2c-designware-core driver.This register interface is incorporated in the intel_qrk_gip driver, which provides a standard I2C interface when loaded. The GIP interface can be loaded in either MSI or non-MSI mode using the commands:modprobe intel_qrk_gipormodprobe intel_qrk_gip enable_msi=0In either case, loading this driver and using the command modprobe i2c-dev populates: /dev/i2c-0Once populated, it is possible to communicate with downstream I2C devices using the standard Linux* API to interact with the I2C bus.To load the I2C driver in isolation (that is, without the GPIO enabling logic contained in the GIP block), type:modprobe intel_qrk_gip gpio=0ormodprobe intel_qrk_gip gpio=0 enable_msi=0The GIP block defaults the I2C devices to fast mode operation (400 kHz). To set to the standard mode operation (100 kHz), type:modprobe intel_qrk_gip i2c_std_mode=1Alternatively, you can set the i2c_std_mode parameter to “1” in the platform data (intel_qrk_gip_get_pdata) section of the Intel® Quark™ SoC X1000 Software

I would like to thank You very much for your time and for your explanation in terms of working under Linux (and with GRUB in terms of some operations described in the attached document).

But I would like to ask you again about the same, emphasizing that I am not running Linux on Galileo, nor I have an official UEFI firmware loaded there - that's the point. I would like, as I have already mentioned, to build my own firmware according to the Quark UEFI Firmware Writer's Guide, but so that I can load my own OS that i have previously built - before buying Galileo - this was the original reason why I bought the Galileo board, because I wanted to run my own, entirely in assembly written, OS, and the Galileo seemed to be the the best development board that would fit my needs - and I also knew that Intel has boasts of its good name for good reasons that the public has been aware of for decades I have spent a lot of work on my own OS it and it works perfectly when I load it as an OS on a PC from BIOS (or UEFI with a legacy OS' support). But there is no official way how to run it on Galileo, even the one particular always mentioned forum link to an EDKII module built by a fan doesn't help me, so i decided to build a totally new firmware for Galileo, entire written in the Assembly language.

Another and one of the main reasons is that I want to do this as my diploma thesis (or at least first as my bachelor's thesis).

So I am asking again - how can I enable the TAP controller even since the very begining of the 32-bit firmware code execution? Or are there another debugging options for the pure firmware at any point of execution (even before moving to the state described as the Stage I in the UEFI?