Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,728,638 Members 54,335 Now Online
XDA Developers Android and Mobile Development Forum

Accessing uart on Galaxy Nexus i9250

Tip us?
 
Rebellos
Old
#51  
Senior Recognized Developer
Thanks Meter 3420
Posts: 1,339
Join Date: May 2009
Location: Gdańsk

 
DONATE TO ME
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.
Feedback on my development is highly appreciated, but first you should read this GUIDE and watch this MOVIE.

If you like my work - you can help me getting various cool stuff by clicking donation link in my profile. It's not required while pressing is, just appreciated.

Pretty owsom Android/Kernel dev tips&tricks: http://omappedia.org/wiki/Android_How-tos

Git HOW-TO by eagleeyetom: http://forum.xda-developers.com/show...php?p=31304826
15-minutes GIT introduction: http://try.github.com
If you want to submit patches to my git projects - use the guides above and make a pull request.
 
E:V:A
Old
(Last edited by E:V:A; 30th June 2012 at 01:04 PM.)
#52  
E:V:A's Avatar
Recognized Developer
Thanks Meter 1696
Posts: 1,297
Join Date: Dec 2011
Location: -∇ϕ
Quote:
Originally Posted by Rebellos View Post
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.)

Quote:
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.
MSM8960 Info, Architecture and Bootloader(s)
El Grande Partition Table Reference
How to talk to the Modem with AT commands

[REF][ServiceMode] How to make your Samsung perform dog tricks
[REF|R&D|RF] RF/Radio properties of Samsung ServiceMode

Want to know when your phone is getting tracked or tapped?

Help us develop the IMSI Catcher / Spy Detector!
(To be part of the EFF & The Guardian Project toolsets.)
_______________________________
If you like what I do, just click THANKS!
Everything I do is free, altruism is the way!
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
I do not answer support related PM's.

 
Rebellos
Old
#53  
Senior Recognized Developer
Thanks Meter 3420
Posts: 1,339
Join Date: May 2009
Location: Gdańsk

 
DONATE TO ME
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. :P 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 :P. 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.
Feedback on my development is highly appreciated, but first you should read this GUIDE and watch this MOVIE.

If you like my work - you can help me getting various cool stuff by clicking donation link in my profile. It's not required while pressing is, just appreciated.

Pretty owsom Android/Kernel dev tips&tricks: http://omappedia.org/wiki/Android_How-tos

Git HOW-TO by eagleeyetom: http://forum.xda-developers.com/show...php?p=31304826
15-minutes GIT introduction: http://try.github.com
If you want to submit patches to my git projects - use the guides above and make a pull request.
 
kurokrosk
Old
(Last edited by kurokrosk; 4th July 2012 at 03:21 AM.)
#54  
Junior Member
Thanks Meter 5
Posts: 2
Join Date: Jun 2012
Quote:
Originally Posted by E:V:A View Post
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...


Quote:
Originally Posted by Rebellos
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.
The Following 2 Users Say Thank You to kurokrosk For This Useful Post: [ Click to Expand ]
 
E:V:A
Old
#55  
E:V:A's Avatar
Recognized Developer
Thanks Meter 1696
Posts: 1,297
Join Date: Dec 2011
Location: -∇ϕ
^^ http://www.riveywood.com/fiqvsirq.html
MSM8960 Info, Architecture and Bootloader(s)
El Grande Partition Table Reference
How to talk to the Modem with AT commands

[REF][ServiceMode] How to make your Samsung perform dog tricks
[REF|R&D|RF] RF/Radio properties of Samsung ServiceMode

Want to know when your phone is getting tracked or tapped?

Help us develop the IMSI Catcher / Spy Detector!
(To be part of the EFF & The Guardian Project toolsets.)
_______________________________
If you like what I do, just click THANKS!
Everything I do is free, altruism is the way!
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
I do not answer support related PM's.

 
E:V:A
Old
(Last edited by E:V:A; 5th July 2012 at 11:50 AM.)
#56  
E:V:A's Avatar
Recognized Developer
Thanks Meter 1696
Posts: 1,297
Join Date: Dec 2011
Location: -∇ϕ
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

Attached Thumbnails
Click image for larger version

Name:	MIPI_TDWG_NIDnT_4.jpg
Views:	3956
Size:	41.1 KB
ID:	1178313  
Attached Files
File Type: 7z Doing_More_with_Less_IEEE_1149.7_tutorial.pdf.7z - [Click for QR Code] (479.1 KB, 52 views)
MSM8960 Info, Architecture and Bootloader(s)
El Grande Partition Table Reference
How to talk to the Modem with AT commands

[REF][ServiceMode] How to make your Samsung perform dog tricks
[REF|R&D|RF] RF/Radio properties of Samsung ServiceMode

Want to know when your phone is getting tracked or tapped?

Help us develop the IMSI Catcher / Spy Detector!
(To be part of the EFF & The Guardian Project toolsets.)
_______________________________
If you like what I do, just click THANKS!
Everything I do is free, altruism is the way!
ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
I do not answer support related PM's.

The Following User Says Thank You to E:V:A For This Useful Post: [ Click to Expand ]
 
xd.bx
Old
#57  
Senior Member
Thanks Meter 282
Posts: 406
Join Date: May 2011
Location: Copenhague
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-...-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.
Attached Thumbnails
Click image for larger version

Name:	IMG_0004.jpg
Views:	514
Size:	270.3 KB
ID:	1204277  
Away for a short while
The Following 2 Users Say Thank You to xd.bx For This Useful Post: [ Click to Expand ]
 
Tordred
Old
#58  
Junior Member
Thanks Meter 0
Posts: 9
Join Date: Aug 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?

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes