This message was posted on behalf of Intel Corporation
Thank you for your interest in the Intel Galileo Board.
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.
• 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-sch
The commands below demonstrate how to drive a signal to the first legacy GPIO:
root@quark# echo 0 > /sys/class/gpio/export # Reserve first legacy GPIO
root@quark# echo "out" > /sys/class/gpio/gpio0/direction # Set as output
root@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=0
modprobe intel_qrk_gip i2c=0 enable_msi=0
Note: 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_gip enable_msi=0
In either case, loading this driver and using the command modprobe i2c-dev populates: /dev/i2c-0
Once 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=0
modprobe intel_qrk_gip gpio=0 enable_msi=0
The 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=1
Alternatively, 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
Also regarding JTAG debugging you can follow this guide for Source Level Debug using OpenOCD/GDB/Eclipse:
Hope this helps.
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?
Thank you again for your helpful information and response.