• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

Accessing uart on Galaxy Nexus i9250

Search This thread
Jan 24, 2012
5
0
I'm going to do some low-level software development on Samsung Galaxy Nexus (replacing kernel with custom one doing stuff that are not Android-related). To do so I'll require accessing uart output of bootloaders and Linux.

I'm looking for an information how to connect to i9250's uart serial port and possibly other stuff.

Currently the best what I've found is The all-in-one Galaxy S2 Hack Pack (http://forum.xda-developers.com/showthread.php?t=1316501), but obviously this is not entirely what I'm looking for. The i9250 service manual maybe some help too. If anyone has any information regarding this matter, please post.
 
Last edited:

superdetka

Member
Sep 28, 2011
8
2
I'm looking for an information how to connect to i9250's uart serial port and possibly other stuff.

To get access to your kernel's, bootloader's logs through UART you need UART jack(dont know this word in english, I think I guess 'jack') on your board, in your case i9250's.
If developers of board didn't add that jack to pcb design, your attempts to view logs will be unsuccessful.
If you find UART pins of your SoC, connect it to UART-USB converter and plug to your PC.
In bootloader sources you will find to which UART port debug messages will go, if your SoC has more than one controller.
In linux's kernel case debug port you could assign through startup string, like bootargs in uboot, or through menuconfig.

But all this stuff depends on have you got UART pins on board or not.
 
  • Like
Reactions: seanstar12

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
I'm looking for an information how to connect to i9250's uart serial port and possibly other stuff.

First you have to tell us what hardware you have! Find some links to "tear-aparts / tear-downs" etc. Also make sure, what you find, corresponds to your device. Samsung is going wild when it comes to making (incompatible) product variations. When we know the hardware we can start to find out the rest... In your case the most important is to find out about the application processor (AP), baseband processor (P) and the micro-USB mux.
 

balban

Member
Sep 19, 2011
13
2
Its the Galaxy Nexus GSM/HSPA version. It has an OMAP4460. The processor found on the pandaboard.
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,812
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
This device should have external UART.

Have you tried 619Kohms on the USB port yet? Most samsung device, including this one, have a FSA chip. This is the first way to tell if UART is properly connected.

If it is, than you can probe deeper to find the internal UART which will show more. The Internal UART connection will show UART before the FSA chip is initialized giving you even more to work with.

It's likely that because this is an OMAP chip, it should have the following characteristics:

192600 or 115200 bps
8 bits per word
1 stop bit
No parity
No flow control
1.8V high, Open drain


I'm not sure if the FSA chip will increase that level to 3V or not.
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
To briefly clarify (and confirm) what Adam says.

There is already built in UART-USB functionality controlled by the FSA (MUX). Thus you can just connect an external microUSB connector with appropriate resistor values, to get a serial connection. (Just google "I9x00 USB JIG"). But if you decide to use internal UART pins on the PCB, then you get earlier access to everything and you can start reading already at the IBL (Initial Boot Loader) stage, which are the absolute first characters coming out of phone after a reboot.
 
  • Like
Reactions: balban

balban

Member
Sep 19, 2011
13
2
I can confirm the 619Kohm trick works on Galaxy Nexus. I used a 3.3V USB/UART breakout card. Serial output:

�����[sbl_board_charger_init_post] : Succeed set model data : 0x78!!!!!
====== VCELL : 368500, SOC : 23, nType : 4 ======
[Charger] nScaledVCELL : 368500000, nDesriedSOC, : 23, nMaxSOC : 43, nMinSOC : 3
[ omap_power_get_reset_source :47] PRM_RSTST : 0x1
[ __omap_usbacc_test_donwload_by_musb :280] nDeviceType : 0x4
[ omap_usbacc_get_reboot_reason :333] nJigStatus = 0x00000001
[ __sbl_board_hw_init_late :719] final reboot mode in cable = 0x20000
[ __sbl_board_hw_init_late :730] Wake up by TA / USB / JIG
* FB base addr = 0xbea70000!
* PANEL_S6E8AA0_ID_READ : 0x12, 0x8e, 0x9f.
[ omap_power_get_reset_source :47] PRM_RSTST : 0x1
message.command =
message.status =
message.recovery =

Starting kernel at 0x81808000...
<hit enter twice to activate fiq debugger>

AST_POWERON
 
  • Like
Reactions: funkym0nk3y

balban

Member
Sep 19, 2011
13
2
This is what comes prior to the above, in case anyone is interested.


-- OMAP 00004460 (version 04460e11) PPA release 1.6.1 Hash 30639809--
Device type: HS, DEBUG OFF
CPFROM HAL API support integrated
THERMAL support integrated: Run Time + Boot time
HDCP support integrated
-- PROD PPA RC3.2.3 --
Reset reason = 00037ba2
PRM_RSTST = 00000002
PPA freed 2992 bytes


Texas Instruments X-Loader 1.41 (Nov 16 2011 - 16:28:45)
Starting OS Bootloader from MMC/SD1 ...
EXCEPTION : CM_CLKMODE_DPLL_ABE = 0x7
EXCEPTION : CM_IDLEST_DPLL_ABE = 0x1
EXCEPTION : CM_CLKSEL_DPLL_ABE = 0x804018
EXCEPTION : CM_CLKMODE_DPLL_CORE = 0xf
EXCEPTION : CM_IDLEST_DPLL_CORE = 0x1
EXCEPTION : CM_CLKSEL_DPLL_CORE = 0x7d05
EXCEPTION : CM_CLKMODE_DPLL_PER = 0x107
EXCEPTION : CM_IDLEST_DPLL_PER = 0x1
EXCEPTION : CM_CLKSEL_DPLL_PER = 0x1400
EXCEPTION : CM_CLKMODE_DPLL_MPU = 0x117
EXCEPTION : CM_IDLEST_DPLL_MPU = 0x1
EXCEPTION : CM_CLKSEL_DPLL_MPU = 0x807d07
CFG_LOADADDR = 0xa0208000
1st instruct = 0xEA000007
[ __omap_twl6030_init_vbat_cfg :49] SA_PHOENIX_START_CONDITION = 0x8
[ __omap_twl6030_init_vbat_cfg :54] SA_PH_CFG_VBATLOWV = 0x80
[ __omap_twl6030_init_vbat_cfg :63] SA_PH_CFG_VBATLOWV = 0x80
[ __omap_twl6030_init_vbat_cfg :86] SA_BBSPOR_CFG = 0x78
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
Now, could we have the English translation (of all that above) please?

[And if debug is OFF, how can we turn it ON?]

I seem to be able to count 4 bootloaders there, how many damn boot loaders are there!?
 

balban

Member
Sep 19, 2011
13
2
USB - UART 619Kohm cable

Would anyone build a custom 619Kohm mini-USB to UART cable and ship it in the U.S. or India? We need it.

Is there any supplier of this in the U.S.?

Thanks,
Bahadir
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,812
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
I've attached a circuit diagram. You will need to modify your cable. You will need a UART device like the FTDIFriend or Bus Pirate. I specified the communications settings above.

Here is the cable modifications and where to hook up on the MicroUSB port.
attachment.php


Power is disconnected
Data- and Data+ are your signal lines.
Pin X (aka Pin4) is connected to ground via 619Kohm resistor
Ground is used as a reference.

Just tear up a MicroUSB cable and modify it as above.
 

Attachments

  • SamsungUART.PNG
    SamsungUART.PNG
    6.7 KB · Views: 5,676
Last edited:

iamsage2

New member
Nov 4, 2011
2
0
I managed to get the UART cable done and also some output from there. Now my questions is has anyone managed to get kernel boot log out of the UART as well? Atm. I get only the bootloader things:
Code:
[sbl_board_charger_init_post] : Succeed set model data : 0x78!!!!!
====== VCELL : 380250, SOC : 57, nType : 4 ======
[Charger] nScaledVCELL : 380250000, nDesriedSOC, : 60, nMaxSOC : 80, nMinSOC : 40
[ omap_power_get_reset_source :47]       PRM_RSTST : 0x1
[ __omap_usbacc_test_donwload_by_musb :280]      nDeviceType : 0x4
[ omap_usbacc_get_reboot_reason :333]    nJigStatus = 0x00000001
[ __sbl_board_hw_init_late :719]         final reboot mode in cable =  0x20000
[ __sbl_board_hw_init_late :730]         Wake up by TA / USB / JIG
* FB base addr = 0xbea70000!
* PANEL_S6E8AA0_ID_READ : 0x12, 0x8e, 0x9d.
[ omap_power_get_reset_source :47]       PRM_RSTST : 0x1
message.command = 
message.status = 
message.recovery =

Starting kernel at 0x81808000...

So does anyone know what kernel configs and cmdline I need in order to get the kernel messages out from the UART?

Thanks in advance.
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
Where is the actual resistor values determined? I know it has something to do with the USB MUX, but are the actual values determined by code or by hardware? Or is the Nexus MUX different? I'm wondering because according to this thread (for the GT-I9100) the resistor value should be R = 523 K.

---------- Post added at 11:58 AM ---------- Previous post was at 11:55 AM ----------

So does anyone know what kernel configs and cmdline I need in order to get the kernel messages out from the UART?
Check the link above...
...and let us know how it goes.

[EDIT] I've just answered my own questions, plus a resistor reference table over here.
 
Last edited:

iamsage2

New member
Nov 4, 2011
2
0
I managed to get the kernel output out with the 619K resistor. Just had to enable some kernel options of FIQ_DEBUGGER

Code:
CONFIG_FIQ_DEBUGGER=y
CONFIG_FIQ_DEBUGGER_NO_SLEEP=y
# CONFIG_FIQ_DEBUGGER_WAKEUP_IRQ_ALWAYS_ON is not set
CONFIG_FIQ_DEBUGGER_CONSOLE=y
CONFIG_FIQ_DEBUGGER_CONSOLE_DEFAULT_ENABLE=y

And have the console=ttyFIQ0 on cmdline. Thanks for the nice thread :)
 

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,812
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Hey guys... I just got a Galaxy Nexus. I'm going to be doing some work. I used UART for the first time last night.

This works differently than standard UART with SBL or U-BOOT. How do you access the command line parmeters for the kernel, or do you need to take a kernel, un-boot.img it and then add new parmeters?
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
...How do you access the command line parmeters for the kernel, or do you need to take a kernel, un-boot.img it and then add new parmeters?
Probably you don't remember this and this. But basically you can use the sblParam tool, to look at and set your command line on the fly. (Do backup and check that the output of that program is the same, as it was originally developed for a different phone.) You can check with:

# hexdump -C /mnt/.lfs/param.blk

BTW. Do you know what the voltage levels are for Tx/Rx (D+/D-), when using the various resistor values, for USB/UART?
In particular the values:

150K UART Cable
255K
Factory Mode Boot OFF-USB
301K
Factory Mode Boot ON-USB
523K
Factory Mode Boot OFF-UART
619K
Factory Mode Boot ON-UART

I'd also like to know if the voltages changes when switching USB/UART mode when using:
a) The PhoneUtil menu: *#7284#
b) The ServiceMode menu : *#197328640#
Code:
==> MAIN MENU --> COMMON --> DIAG CONFIG
[1] LOG VIA USB *
[2] LOG VIA UART
Why?
1) It may be possible that there are already level-shifters built in to the MUX, and thus we may no longer need to build level shifter UART cables.
(Your PC should automatically recognize a new serial device, using one of the ~7 drivers included in the Samsung CDC, when connecting disconnecting via USB and using some (?) of the resistors above.)
2) I have the FTDI FT232R-3V3 cable and need to check if its TTL 5V or CMOS 3.3V levels on the output..

This is all hypothetical, so it may be that I'm on a wild goose chase... But I'm still waiting for my μUSB breakout connector and cable...and then found out I may have the wrong levels for my cable.
 
Last edited:

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,215
-∇ϕ
Those menus don't exist on my stock device.
Really!? I don't believe it. They must have changed the code(s) to something else. Sometimes you also need to write the "*#" parts twice before or after the number, for reasons unknown, but probably some lame attempts to further hide these menus from curious users. Did you try *#0011#? (Or any other of the hundreds of "hidden" function codes?) No worry, we can find them by looking in the baseband or the available Apps on the phone...

[EDIT] Ah, I just remembered, the various codes are pointers to the various sub-menus in the servicemode app, so if they have updated this app, which they surely have if you're on ICS and Nexus, the sub-entry codes have likely changed as well. (Remember that this app is just a wrapper for the real/native code running on BP which is different for different platforms (phones). However, most main entry codes should always be the same. Like 0011 and 06 etc etc.

Also try:
Code:
# find / -iname "*service*"
If indeed none of these menus are available, they must have done some interesting kernel mods to extend the auto-detection and for tweaking functionality elsewhere. You're on ICS 404, right?
 
Last edited:

AdamOutler

Retired Senior Recognized Developer
Feb 18, 2011
5,224
9,812
Miami, Fl̨̞̲̟̦̀̈̃͛҃҅͟orida
Really!? I don't believe it. They must have changed the code(s) to something else. Sometimes you also need to write the "*#" parts twice before or after the number, for reasons unknown, but probably some lame attempts to further hide these menus from curious users. Did you try *#0011#? (Or any other of the hundreds of "hidden" function codes?) No worry, we can find them by looking in the baseband or the available Apps on the phone...

[EDIT] Ah, I just remembered, the various codes are pointers to the various sub-menus in the servicemode app, so if they have updated this app, which they surely have if you're on ICS and Nexus, the sub-entry codes have likely changed as well. (Remember that this app is just a wrapper for the real/native code running on BP which is different for different platforms (phones). However, most main entry codes should always be the same. Like 0011 and 06 etc etc.

Also try:
Code:
# find / -iname "*service*"
If indeed none of these menus are available, they must have done some interesting kernel mods to extend the auto-detection and for tweaking functionality elsewhere. You're on ICS 404, right?
I dont have find or hexdump yet. I have decided that any modifications i do to this device will be CASUAL implementations. I am running stock 4.0.2 ICL53F.i9250XWKL2.

I believe there is a root exploit out there i can port into CASUAL. Its a matter of getting time to do it.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    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'.
    3
    This device should have external UART.

    Have you tried 619Kohms on the USB port yet? Most samsung device, including this one, have a FSA chip. This is the first way to tell if UART is properly connected.

    If it is, than you can probe deeper to find the internal UART which will show more. The Internal UART connection will show UART before the FSA chip is initialized giving you even more to work with.

    It's likely that because this is an OMAP chip, it should have the following characteristics:

    192600 or 115200 bps
    8 bits per word
    1 stop bit
    No parity
    No flow control
    1.8V high, Open drain


    I'm not sure if the FSA chip will increase that level to 3V or not.
    3
    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.
    3
    I've attached a circuit diagram. You will need to modify your cable. You will need a UART device like the FTDIFriend or Bus Pirate. I specified the communications settings above.

    Here is the cable modifications and where to hook up on the MicroUSB port.
    attachment.php


    Power is disconnected
    Data- and Data+ are your signal lines.
    Pin X (aka Pin4) is connected to ground via 619Kohm resistor
    Ground is used as a reference.

    Just tear up a MicroUSB cable and modify it as above.
    2
    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.