Accessing uart on Galaxy Nexus i9250

gblues · May 22, 2012

I have a different Samsung phone, but I suspect the same process will work. But as I am new to hardware hacking, I want to make sure I understand exactly how to read the output.

Here's what I _think_ I would need to do:

1) Get a mini-USB breakout dongle.
2) Obtain a 619kOhm resistor and wire it as Adam illustrates on page 2.
3) Wire GND, TX, and RX to the matching pins on the FTDI Friend
4) Connect the breakout dongle to my phone, and connect mini-USB cable from the DTDI Friend to the PC
5) Not sure what happens here; I assume Windows loads a serial USB driver and creates a port I can access from a terminal emulator?

E:V:A · May 22, 2012

Well don't be silly! Search the proper threads for "your phone" and post your question there. It is very likely, it's been answered already! For all we know your phone may be completely different from this one and thus use completely different resistor values. Also make sure your FTDI friend is using 5V levels or you'll need to add a level shifter as well...but then again it depends on your phone. And if you have already used your FTDI device before, windows will automatically detect and install the right device driver, or you'll need to download and install it... Then you download Realterm and connect to the new serial COM port.

AdamOutler · May 22, 2012

E:V:A said:
Have you actually managed to figure out on what (serial?) device ( /dev/xxxx ) all this output is coming from?

I.e. Given that the Kernel is loading in the background, while you're in the FIQ debugger, you should be able to get a shell at the same time (by connecting through BT/WiFi or by local shell on telephone). Now assuming you have this, what device is your serial FIQ debugger located on? (You should then be able to intercept and/or inject [echo] FIQ commands on that device.)

well, I have not yet... however /proc/cmdline contains this

Code:

console=ttyFIQ0 androidboot.console=ttyFIQ0

And by default on most OMAP kernels the debug serial ports are /dev/ttyO0 (that's the Letter O and a zero), or /dev/ttyO2(that's letter O and a 2). The odd thing is that ttyO2 is missing from this device...

However this device has ttyGS0, G1, G2, G3... ttyGS3, a ttyO0, O1, O3, and ttyFIQ0

The problem is that when FIQ is active, the debug output is not displayed. In order to get the kernel messages, FIQ must be removed and a new kernel needs to be compiled. Standard UART is not possible on a stock Nexus.

gblues · May 24, 2012

E:V:A said:
Well don't be silly! Search the proper threads for "your phone" and post your question there. It is very likely, it's been answered already! For all we know your phone may be completely different from this one and thus use completely different resistor values. Also make sure your FTDI friend is using 5V levels or you'll need to add a level shifter as well...but then again it depends on your phone. And if you have already used your FTDI device before, windows will automatically detect and install the right device driver, or you'll need to download and install it... Then you download Realterm and connect to the new serial COM port.

Sorry I wasn't more clear--my phone is the SGH-T589 and it uses the FSA9280 chip, so I'm confident the resistor values are identical. Thanks for the info!

E:V:A · May 24, 2012

AdamOutler said:
The problem is that when FIQ is active, the debug output is not displayed. In order to get the kernel messages, FIQ must be removed and a new kernel needs to be compiled. Standard UART is not possible on a stock Nexus.

Aah, yes, that makes sense...or does it?
I'm confused. On the one hand, from my previous observations mentioned above, it seemed that debug/Kernel messages was still produced in the "the background" while you were entering the FIQ-db. But that could just be apparent. Because it would make more sense, if FIQ does indeed stop all debug output. Why? Because FIQ is a processor debug state, and thus you should halt everything apart from the FIQ debugger itself. But then we have more than one processor core, so I have no clue as to what happens in/to them while in FIQ-debugger...

Also could you clarify your statement: "Standard UART is not possible on a stock Nexus."
(What do you consider standard and why not?)

AdamOutler · May 24, 2012

E:V:A said:
Aah, yes, that makes sense...or does it?
I'm confused. On the one hand, from my previous observations mentioned above, it seemed that debug/Kernel messages was still produced in the "the background" while you were entering the FIQ-db. But that could just be apparent. Because it would make more sense, if FIQ does indeed stop all debug output. Why? Because FIQ is a processor debug state, and thus you should halt everything apart from the FIQ debugger itself. But then we have more than one processor core, so I have no clue as to what happens in/to them while in FIQ-debugger...

Also could you clarify your statement: "Standard UART is not possible on a stock Nexus."
(What do you consider standard and why not?)

Fiq debugger starts and then stops. It is worthless after 3 seconds unless you enter commands

When I say standard UART, I mean kernel/bootloader output messages and console.

E:V:A · May 28, 2012

So after having watched part of this excellent video by Mike Anderson, (PTR Group), titled: "Using OpenOCD JTAG in Android Kernel Debugging", it seem that the FIQ debugger may be part of some JTAG activation state.

He further says that for multi-core processors, the uboot debuggers never use more than one core, becuase of possible problems. However, it does not seem (to me) if this FIQ debugger is started from bootloader and thus it is still possible that all kernel have already been loaded.

http://www.youtube.com/embed/JzMj_iU4vxs

Had it not been for the missing sound in the first half of this 1:50 hr long video, and the unreadable screen shots, this could have been one of the best AOS specific JTAG introductions I have seen so far.

His presentation slides are available here.

An interesting side note from this video and some other documents I have read. Is that the JIG resistor values are indeed use to activate JTAG. If you look at block diagram, you'll see that USB_ID is connected to the JTAG port. Thus when you connect a JTAG, you can/are also change the USB_ID...to something.

Sorry, if this was a little off topic.

E:V:A · Jun 1, 2012

Having been Googling around for the hidden/secret menu codes for the i9250, just for fun, have not resulted in anything! Strange.

@Adam: Did you find any additional hidden codes for this device?

Soon I'll post some more general and detailed instructions on finding the hidden codes. But for your phone I'm quite confident you'll find the Samsung "Secret Codes" in either:

Phone.apk
TelephonyProvider.apk
GoogleServicesFramework.apk
ApplicationsProvider.apk

However, I noticed you have odex'ed files, so you need to either find the de-odexed files or do it yourself, if you know how to. Then you can use jed to decompile the entire apk's and eventually find all the codes. Look for java/class files called something like "ServiceModeApp" or "KeystringBroadcastReceiver"...

kurokrosk · Jun 29, 2012

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'.

E:V:A · Jun 29, 2012

kurokrosk said:
... 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.

This is what I have been suggesting several times before. You should try to use a different resistor value for your jig. I think the 150K value (labelled as "UART") may help. You can also try with the 523K, 255K values, as shown in this post, and also mentioned in this thread.

In addition, as I have also mentioned before (I can't recall where), the possibility of being able to get serial console without the use of a serial converter, by using the correct USB (virtual serial over USB) drivers. I have no idea how these drivers work, but I'm convinced this should work, as both adb, OEM JTAG tracing (SWT) and "usb GSM modem" are using these (at least in windows). I have been looking at some of these (windows) drivers .inf files for a number of similar phones, and I am sure someone could just change the USB ID/VER codes to the correct ones.

For example, in some of the drivers they are named as:
"Samsung Modem Diagnostic Serial Port" (0x04E8:6601/6640)
and in yet another driver it is called:
"Samsung USB Diagnostic Serial Port Driver" (ssuderserd.inf, 0x04E8:6860)

Now that would be a really great thing, as it would eliminate all additional hardware, in order to get early console/debug output!!

Rebellos · Jun 29, 2012

Kurokrosk, do you have any clue why would they assign IRQ instead of FIQ to FIQ_debugger? While it's possible - it kinda breaks main assumption, as IRQs are much often unavailable than FIQs in case of kernel panics, so it becomes unusable.
According to FSA driver - 150K resistor would indeed trigger the desired mode with stock driver. As EVA stated.
It might be possible that there's serial port emulating module inside of kernel somewhere. Just for debugging purposes. But I doubt it's possible to get very early/bootloader output logs without serial converter - FSA9280 for which we got datasheet doesn't have USB interface inside like FTDI232 used in converters, it's multiplexer only. If FSA9480 doesn't differ in this case - it's not possible to get early logs without kernel USB driver, which of course fails together with kernel in case of panic or hang.

E:V:A · Jun 30, 2012

Rebellos said:
But I doubt it's possible to get very early/bootloader output logs without serial converter - FSA9280 for which we got datasheet doesn't have USB interface inside like FTDI232 used in converters, it's multiplexer only. If FSA9480 doesn't differ in this case - it's not possible to get early logs without kernel USB driver, which of course fails together with kernel in case of panic or hang.

Now, "very early", and "early" is of course a bit of a hardware and terminology definition problem. That we can't get IBL output is rather likely, but anything after 1st or 2nd boot loader may be possible, depending on what's inside those bootloaders. You are the bootloader expert here, so you tell me (us) what is actually present in this one. But you surely agree that we have seen many that allow for download via USB or UART.

It may be useful to remember that the actual signal lines are the same wheter they are called RxD/TxD (UART) or DP/DM (USB). Thus the FSA is just a signal mux as you said, but there is nothing in our current documentation that states that this device (or many other for that matter), actually contain that (FSA9280) chip. In fact it seem unlikely it is using this chip, although the resistor value behavior conform to that of the data sheet. But this can be perfectly emulated in code. Furthermore, it seem that all mux chips are always in the "powered-on" state. (Another option, mentioned somewhere, was that part of this chip have been "integrated" into the PMIC, however, this seem unlikely to me. Probably this person was referring to the level shifters.)

So what I am saying is, that since debug output is eventually handed over from bootloader to kernel (which explains why certain resistor values allows for early vs. late boot/kernel debug output), it should be possible to get most of this output using your USB connection only, depending on what is available in bootloader and your USB drivers, and the initial MUX settings. (There is probably a chain of muxes here, but should be configured correctly by hardwiring or bootloader.)

Do you have any clue why would they assign IRQ instead of FIQ to FIQ_debugger? While it's possible - it kinda breaks main assumption, as IRQs are much often unavailable than FIQs in case of kernel panics, so it becomes unusable.

Let me try to answer that, as I have been working on a FIQ document... I'll just quote:

"The difference between IRQ and FIQ is with FIQ you have to process your
stuff as quickly as possible and then get the .... out of there. An IRQ
may be interrupted by an FIQ but an IRQ cannot interrupt an FIQ. To make
FIQs faster, they have more shadow registers. FIQs cannot call SWIs. FIQs
must also disable interrupts. If it becomes necessary for an FIQ routine
to re-enable interrupts, it's too slow and should be IRQ not FIQ."

For those unaware of the acronyms, FIQ is simply the last interrupt vector
in the list which means it's not limited to a branch instruction as the other
interrupts are. That means it can execute faster than the other IRQ handlers.

Normal IRQs are limited to a branch instruction since they have to ensure
their code fits into a single word. FIQ, because it won't overwrite any
other IRQ vectors, can just run the code directly without a branch
instruction (hence the "fast").

The FIQ input line is just a way for external elements to kick the ARM
chip into FIQ mode and start executing the correct exception. There's
nothing on the ARM itself which prevents that from happening except
the CPSR.

To enable FIQ in supervisor mode:

Code:

MRS r1, cpsr         ; get the cpsr.
BIC r1, r1, #0x40    ; enable FIQ (ORR to disable).
MSR cpsr_c, r1       ; copy it back, control field bit update.

A similar thing can be done for normal IRQs, but using #0x80 instead of #0x40.

Source: Here and here.

Hope this helps.

Rebellos · Jun 30, 2012

The thing is that whole UART driver might be put in about 40opcodes, thats 160bytes of code. USB driver with the very basic functionality fits in 2-4kb. Sending any character through UART is fully hardware handled, all software has to do is put character into certain SFR. Sending single byte through USB needs passing through at least 1-2 virtual layers, usually software FIFOs and so on. As USB is much more universal.

So usually you won't meet USB-UART debug interface in bootloader. I think there might be such thing in kernel. But due to its complexity and RAM requirement it's not really good debugging thing - will fail in too many cases where kernel crash.

I know pretty well what FIQs are

. The thing is that these are much less often used by kernel. When IRQ fires, other IRQs are disabled by default until that IRQ handler enables nested IRQs. If something happens before that enabling - FIQ debugger set on IRQ becomes trash. Also if something corrupts IRQ stack - same thing, FIQ debugger is unusable.

kurokrosk · Jul 4, 2012

E:V:A said:
This is what I have been suggesting several times before. You should try to use a different resistor value for your jig. I think the 150K value (labelled as "UART") may help. You can also try with the 523K, 255K values, as shown in this post, and also mentioned in this thread.

Yep. I did read extensively the resources you have posted before, but could not resolve myself to try the 150k resistor. I went for the 619k resistor which had been confirmed to work. Now I am, however, pretty convinced that the 150k will work (although I won't do it, as I had quite some trouble setting up the cable already).

About early prints via USB, I am buying Rebellos explanation. Printing outputs to USB from the bootloader does not make much sense to me, as USB is so much more convoluted that the standard UART. I doubt bootloader developpers added such a functionality (print to USB) when they surely have the hardware to do with UART.
Of course, data transfer is another thing, and USB link is de facto necessary...

Rebellos said:
Kurokrosk, do you have any clue why would they assign IRQ instead of FIQ to FIQ_debugger?

From what I have collected (OMAP TRM and www-riveywood-com/fiqvsirq.html):
Each ARM core has one FIQ input pin (nFIQ), and one IRQ input pin (nIRQ). Only two pins. Interrupts can come from many sources, so having two input lines is obviously not enough. So interrupts are centralized by an interrupt controller, which exposes many interrupts lines to the multiples components of the device. The interrupt controller will manage incoming IRQs, check their priority, and dispatch them to the ARM core(s). Fact is this interrupt controller (at least in OMAP4460, the GNex chip) exposes only one FIQ line which bypass all the interrupt arbitration logic, and is directly linked to nFIQ. This line can also be used as a classic IRQ line.

The FIQ mode is rarely used though. Using it would mean that we have only one very high priority source linked directly to nFIQ, which has priority over every other IRQs (that would include radio, touch screen, button, etc...).

Is making the FIQ debugger "the single very high priority interrupt source" reliable/correct/reasonable ? FIQ debugger has been designed as such, but Google/Samsung may have not intended to use it with FIQ. After all, from their point of view, FIQ debugger could have been only a quick and dirty way to get some register info or a uart console, but it is very lacking in debugging power. If there was a case where a IRQ got stuck somewhere, they have means to use JTAG.
Also, and I have not put much though in it to confirm, is such a complex piece of code like a debugger compatible with the FIQ philosophy of "make it quick and get out" ?
Another explanation is that something else may be using the FIQ line already.

E:V:A · Jul 4, 2012

^^ http://www.riveywood.com/fiqvsirq.html

E:V:A · Jul 5, 2012

Samsung is a major participant in the MIPI consortia.
See some of the MIPI documents regarding JTAG (1149.1, 1149.7, NIDnT) and the SWD (Software Dubug) interface.

"MIPI_TDWG_whitepaper_NIDnT_V1_0" (pdf)
"MIPI_TDWG_whitepaper_v3_2" (pdf)

and

xd.bx · Jul 17, 2012

Hi,

I tried both values (619 KOhms and 150 Kohms). Contrary to Adam, there was no difference in the bootloaders's output. The only difference was that the kernel did not recognize the 619 Kohms value for the FIQ and stopped outputting anything - whereas with the 150 Kohms it worked fine (see pid below).

I used the following parts:

http://www.sparkfun.com/products/10031 USB MicroB Plug Breakout Board
http://www.dealextreme.com/p/usb-to-uart-5-pin-cp2102-module-serial-converter-81872?item=18 USB to UART 5-Pin CP2102 Module Serial Converter

You will also need a 150 Kohms resistor and a 5 pin row header which is easy to find. Note: VCC is not connected, which is normal.

Tordred · Aug 29, 2012

I am trying to access UART in order to configure the GPS chip in the i9250, but I do not need to access it from the PC. A terminal app should be qsufficient. The /vendor/sirfgps.conf says that the UART of the GPS chip is directed to the ttyO0. But when I try to access and read the output of ttyO0 I only get weired characters. What parameters do I have to consider accessing the ttyO0?

Accessing uart on Galaxy Nexus i9250

Senior Member

Inactive Recognized Developer

Retired Senior Recognized Developer

Senior Member

Inactive Recognized Developer

Retired Senior Recognized Developer

Inactive Recognized Developer

Inactive Recognized Developer

New member

Inactive Recognized Developer

Senior Recognized Developer

Inactive Recognized Developer

Senior Recognized Developer

New member

Inactive Recognized Developer

Inactive Recognized Developer

Attachments

Senior Member

Attachments

Member

Similar threads

Top Liked Posts