fiq debugger
First and foremost, many thanks to the participants of this thread. I'm doing kernel hacking on GNex and got valuable information here on retrieving UART output.
I did the trick of soldering a 619komh resistor in a micro usb cable + a uart-usb converter, and successfully got 'some' output :
- by default, I get the debug prompt (fiq debugger) for three seconds only
- by enabling in the kernel options : "Put the FIQ debugger into console mode by default", and I get the kernel logs until this message only
Code:
fsa9480 4-0025: cable detect change, from 'unknown/none' to 'jig'
Anything after is not retrievable.
This is as far as I could go with the info provided by the thread.
Below, I want to share things I came to understand but did not find any clues in this thread, and hopes it may help future developers that were puzzled by the same problems I encountered.
FIQ debugger:
The FIQ debugger is a valuable tool as it gives access to cpu registers and many commands to give to the OS. It takes the form of a kernel module. It has two modes, the "debug mode" which is a independant prompt with its own commands, and the "console mode" which is the regular shell on the device. The problem is we get access to this debugger for like 3 seconds only, making it indeed useless.
Some background first:
- by default, user interaction with the fiq debugger goes through the UART and the associated IRQ (and not the FIQ as its name should imply, although it is capable of using FIQ on other devices I think).
- At kernel boot, the fiq debugger requests the usage of UART2 and successfully register itself to the kernel, which will assign a irq number to the debugger (n'106). This means everything going through the UART2 port (micro sub -> fsa chip -> uart2) will trigger a irq106, and communicate with the debugger kernel module.
- 'Contact' is lost after 3 seconds (ie impossible to get logs or communicate with the debugger), as any requests from outside are not processed by the kernel. No processing, no control.
What is happenning? The event which breaks the uart link is the detection of a "jig" cable by the fsa driver. Detecting a jig will causes the kernel to change the functionality of the associated uart port from "simple uart input/output with the micro usb" to "uart redirected to another component" (according to kernel source, it is LTE, MODEM or AP, I have no idea what are those devices). Therefore, the detection of the jig cable breaks the uart link to the host.
If the fsa detects a 'uart' cable, though, the kernel will take no action: the default state of the uart port and the mux in between is a regular input/output.
The "trick" to keep the fiq debugger usable at all times would be to use a proper UART cable, or a cable detected as a 'uart' one (this would require to solder the correct resistor value). I have no idea if using a proper 'uart' cable (and not a 'jig' 619k-resistor cable) will result in no messages before the kernel boot. I also believe using a proper 'uart' cable should enable the use of fiq debugger even on a stock kernel.
Those who already have this 619k cable and don't want to meddle with it, can trick the kernel into thinking the 'jig' cable is a 'uart' cable. A simple edit will do.
In /drivers/misc/fsa9480.c, look for
Code:
_detected(usbsw, FSA9480_DETECT_JIG);
and change it to
Code:
_detected(usbsw, FSA9480_DETECT_UART);
This way, the fiq debugger keeps receiving requests coming from the micro usb and your host computer, as the kernel will not redirect the uart to other components.
Miscellaneous remarks:
- to enable the FIQ debugger, you are not required to tap enter twice at the very beginning. Just plugging the cable and pressing enter twice at any times will do. This makes things easier to debug.
- The /dev/ttyFIQ0 is a console registered by the FIQ debugger. Adding the kernel boot parameter "console=ttyFIQ0" will make you enable to use a full shell on the device, either if you enabled the "console mode" by default or if you typed "console" in the fiq debugger prompt. Not adding it will not prevent you from using the debug mode, but in console mode you will only get the console output.
- In debug mode, you will notice the debugger will sleep if not used ("suspending FIQ debugger"). To wake up, you should press twice <ENTER>. You can also prevent it to sleep by entering in debug mode 'nosleep'.