Originally Posted by E:V:A
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...
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.