linux-tegra-nv-3.4 Nvidia tegra3 kernel branch for grouper

Search This thread

USBhost

Recognized Contributor
Oct 23, 2013
6,007
7,085
u:r:usbhost:s0
OnePlus 8T
OnePlus 12
In regards to getting UART through the headphone jack..... I see that with a Nexus 4 it uses a DEBUGGER_TRIGGER which operates actually through the 3.5mm mic input. It senses with mic input and then switches headphone out from audio to UART data.

I thought it was confirmed that our original Nexus 7 does NOT have a TRRS jack, meaning you cannot plug a mic'd headset into the 3.5mm jack and use the mic. Therefore.....you cannot trigger the UART either in such a way. Maybe a kernel could be built where the UART was hard coded.


Am I wrong? (I want to be wrong)
If the kernel won't boot won't
Uart not work if it was hard coded?

I was thinking
Maybe you can tell the kernel to do a logcat the vary first thing
Before it does any thing else
 

redeyedjedi

Senior Member
May 1, 2011
831
505
Google Pixel 6 Pro

Well.....what are active headphones? For a Nex4 the trigger is the mic "ring" but there isn't one on our TRS jack. Could it be that a small voltage is applied to one of the L/R channels?


this is driving me nuts. Either debug wont work through headphone jack or our tablet can support a mic headset.
I'm trying to figure out how that last statement is wrong.

---------- Post added at 02:52 PM ---------- Previous post was at 02:40 PM ----------

https://android.googlesource.com/ke...arch/arm/mach-msm/lge/mako/board-mako-sound.c


line 235 - 247. The nexus 4 trigger.
 
Last edited:

redeyedjedi

Senior Member
May 1, 2011
831
505
Google Pixel 6 Pro
I have obtained a schematic for our nexus 7 WiFi tablet and I've had a chance to look it over. I found a few interesting things that need to be investigated further. It looks like we do not have a TRRS jack like I suspected we didn't. It does not matter tho.... the debug info can traverse the headphone out via transmit on L channel and receive on R channel.

what's needs to be investigated tho....is the pogo pins. The debug port has traces on mb leading directly to "Hout r2" and "Hout l2".

these are headphone out left and right channel that lead to the pogo pins. They are a/c coupled to Hout r1 and Hout l1 which are the headphone out traces leading directly the headphone jack. In theory the uart port is also coupled to the headphone jack but I'm trying to understand why they would bother with using the coupling caps to separate the pogo pins from the headphone jack.

of the top of my head I'm not sure if those caps would block any, some, or all of that debug data but there must be some reason for this method. To further make things interesting....those other two pogo pins are a ground and a voltage source!!! How convenient! Could it be that we need to use these pogo pins to get some debug info??

I'm just not quite ready to go soldering on this new tablet yet.
 
Last edited:

sgt. meow

Senior Member
Dec 21, 2011
4,423
2,973
25
Dhaka
If only JBQ or someone else could put an end to our misery. Nevertheless that discovery is something to take note of.
So you're saying that the debug port is connected to the POGO pins which are in turn connected to the headphone jack to which the UART port is also theoretically connected? I'm not an electrical engineer whizz-kid or something i.e I have no idea of what you have just said. :)
But if you need me to modify the kernel somehow, lemme know. It appears as though @HTCDreamOn has added the armv7 flags to the compression Makefile. Need to pull in a few changes.
To summarise: I'm a noob at electrical modifications, hit me up if you need to change something in the kernel, great job.

---------- Post added at 12:43 PM ---------- Previous post was at 12:30 PM ----------

Also this by @HTCDreamOn
I still need to get round to inspecting the board files more closely, haven't had any time since reinstalling Linux. Unfortunately as much as I want 3.4, I'm not rich/experienced/stupid enough to open up my own N7 and start soldering stuff.so yeah looks like we need to find someone who is.

This may be completely unrelated, but try this: plug in some earphones, then start interacting with the screen. You can hear some interference when you touch it. Does this mean anything?
Although UART should have no relation to the screen, does the above mean anything?
 

redeyedjedi

Senior Member
May 1, 2011
831
505
Google Pixel 6 Pro
If only JBQ or someone else could put an end to our misery. Nevertheless that discovery is something to take note of.
So you're saying that the debug port is connected to the POGO pins which are in turn connected to the headphone jack to which the UART port is also theoretically connected? I'm not an electrical engineer whizz-kid or something i.e I have no idea of what you have just said. :)
But if you need me to modify the kernel somehow, lemme know. It appears as though @HTCDreamOn has added the armv7 flags to the compression Makefile. Need to pull in a few changes.
To summarise: I'm a noob at electrical modifications, hit me up if you need to change something in the kernel, great job.

---------- Post added at 12:43 PM ---------- Previous post was at 12:30 PM ----------

Also this by @HTCDreamOn

Although UART should have no relation to the screen, does the above mean anything?

The only solid copper traces from the debug port go to the pogo pins. From there......they are connected to the headphone jack but there are two A/c capacitors in the way. In any audio circuit this is called A/C coupling or DC blocking.....in other words.....and audio signal which is AC electricity will pass right through....but DC stops there.....it can't go through an AC capacitor....so you hear music and not some 5v signal like from the battery.

It could be that uart data is also AC........I don't really know.....but if so....then these two caps are an engineering mistake and a waste of parts which may be degrading the audio out quality as it passes through. I'm guessing that it does block or affect that debug data.....but using the pogo pins instead eliminates the possibility.




has anyone ever listen to music from the pogo pins and compared that to the quality of the headphone jack..... I wonder.

regardless....my ftdi uart adapter is in the mail...anyone who already has it and wants to get debug info should use the middle two pogo pins. I'm guessing that the code is the same as nexus 4.......but the method is different. We don't have trrs. ....but we got pogo pins with grnd, 5v, and rx/TX.

I think the "trigger" is if you supply 5v then audio comes out....if tablet supplies 5v then debug comes out. Has anyone verified if you have to give 5v at that pogo pin before audio comes out the other pins??
 
Last edited:

HTCDreamOn

Senior Member
Jun 17, 2012
1,069
1,353
The only solid copper traces from the debug port go to the pogo pins. From there......they are connected to the headphone jack but there are two A/c capacitors in the way. In any audio circuit this is called A/C coupling or DC blocking.....in other words.....and audio signal which is AC electricity will pass right through....but DC stops there.....it can't go through an AC capacitor....so you hear music and not some 5v signal like from the battery.

It could be that uart data is also AC........I don't really know.....but if so....then these two caps are an engineering mistake and a waste of parts which may be degrading the audio out quality as it passes through. I'm guessing that it does block or affect that debug data.....but using the pogo pins instead eliminates the possibility.




has anyone ever listen to music from the pogo pins and compared that to the quality of the headphone jack..... I wonder.

regardless....my ftdi uart adapter is in the mail...anyone who already has it and wants to get debug info should use the middle two pogo pins. I'm guessing that the code is the same as nexus 4.......but the method is different. We don't have trrs. ....but we got pogo pins with grnd, 5v, and rx/TX.

I think the "trigger" is if you supply 5v then audio comes out....if tablet supplies 5v then debug comes out. Has anyone verified if you have to give 5v at that pogo pin before audio comes out the other pins??

You are awesome. I didn't even understand most of that which makes you doubley awesome :silly: but honestly thanks so much for helping out, if you ever get output then you'll be far more important to this project than sgt. meow and I.
 

redeyedjedi

Senior Member
May 1, 2011
831
505
Google Pixel 6 Pro
I have a couple of usb UART devices now.... but Im having trouble finding a good application that can simply display the raw data being fed to the device. Any suggestions?? It would seem this would be easy but :confused::confused:
 

HeadKase

Senior Member
Nov 7, 2006
82
25
Arizona
Last edited:

sgt. meow

Senior Member
Dec 21, 2011
4,423
2,973
25
Dhaka
That's been there for a long time. Maybe it does have helpful info. I'll look at the board files.
 

redeyedjedi

Senior Member
May 1, 2011
831
505
Google Pixel 6 Pro
Not sure if you guys have seen this thread... sorry if someone posted the link (I looked and didn't see it)... I was reading that you were looking in to the pogo pins... seems as though 1 and 4 charge when the device is turned off... do 2 and 3 lead to the headphone jack @redeyedjedi? http://xdaforums.com/showthread.php?t=1800099&page=2 ... just read in this thread http://xdaforums.com/showthread.php?t=1800099&page=11 that the two middle pins are for audio

Yes....but those pogo pins are the only unadulterated path to UART. I got a serial debugger...but in my tests I forgot ONE TIME that the ground pin was closest to the camera.....and blew the voltage regulator in the charging circuit. I just got two more broken screen nex7's and will start again trying to get debug info.....I need a good serial port monitor to view the raw data....on two occasions my debugger showed it was transmitting UART data....but none of the windows progs I have will show it. GRRR!

---------- Post added at 02:52 PM ---------- Previous post was at 02:51 PM ----------

I assume you already know about the 3.10 sources released by Google, but just in case:

https://android.googlesource.com/kernel/tegra/

Are there any useful information in there or it's too generic?

It's too old.

---------- Post added at 02:54 PM ---------- Previous post was at 02:52 PM ----------

That's been there for a long time. Maybe it does have helpful info. I'll look at the board files.

What program are you using on your pc for viewing uart data? I have two sacrificial lambs ready for the slaughterhouse.
 
  • Like
Reactions: Monfro and estape11

sgt. meow

Senior Member
Dec 21, 2011
4,423
2,973
25
Dhaka
Yes....but those pogo pins are the only unadulterated path to UART. I got a serial debugger...but in my tests I forgot ONE TIME that the ground pin was closest to the camera.....and blew the voltage regulator in the charging circuit. I just got two more broken screen nex7's and will start again trying to get debug info.....I need a good serial port monitor to view the raw data....on two occasions my debugger showed it was transmitting UART data....but none of the windows progs I have will show it. GRRR!

---------- Post added at 02:52 PM ---------- Previous post was at 02:51 PM ----------



It's too old.

---------- Post added at 02:54 PM ---------- Previous post was at 02:52 PM ----------



What program are you using on your pc for viewing uart data? I have two sacrificial lambs ready for the slaughterhouse.


https://groups.google.com/forum/#!topic/android-kernel/hFXhwLOduLI
http://xdaforums.com/showthread.php?t=1209288
http://xdaforums.com/showthread.php?t=925034
http://xdaforums.com/showthread.php?t=1901376
http://xdaforums.com/showthread.php?t=1644204 (email the dev here for more info)
http://xdaforums.com/showthread.php?t=1547425

I have absolutely no experience with UART as you an tell. But the 4th and 3rd ones seem most promising.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 18
    Title says it all.

    Basically, I'm gonna need help on this, I don't know how much, but I will need it. I'm pushing all my changes to my GitHub repo regularly, but so far I'm simply trying to get the grouper board files set up. Here's how I'm going about that:

    • cherry-pick Google's commits which added grouper support to 3.1.10 kernel
    • Fix conflicts
    • Compile
    • Inspect errors
    • Update grouper board files against kai board files commits from here (from the k3.3: kai: Updates to board files commit onwards
    • Recompile
    • etc.

    Beyond this I'm not really too knowledgeable in al the device tree stuff. Sure, I've read up on alot of stuff, but have no practical experience. Therefore once I've got the board files how I think they should be, if things still don't work then I will need help. Luckily, it looks like the kai board and grouper are extremely similar. So with any luck it'll work without too much hassle.

    Beyond this stuff will probably be broken anyway, so I will need help with that.

    Feel free to discuss anything relevant, and to offer anything you think might be useful. There are some real devs here who would make a big impact on this, as there's only so much blind tinkering I can do.

    Thanks :)
    9
    You need to make one, basically the N7 has a UART port in the headphone jack but you need to make an adapter: http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ it's widely assumed the process is the same for all Nexus devices but I haven't found anyone testing it with the N7 do there's no confirming it would work. Hopefully if it didn't then it'd must be a case of enabling stuff in the kernel (there may have been some commits disabling it for release). If you wanna help out then this would be invaluable though :)

    You can find test points that a serial debugger can be soldered directly on the mb. Id be thinking balls deep here....tho you might get the info over the headphone jack we never did. Its about 4 points and a grnd that need to be soldered. You will need A debugger to see where the custom board file fails. This exact process was done to get the 3.1.10 to boot on the old view sonic gtab.

    Fwiw. ....the 3.8 branch gets a lot of attention from Tegra. Are the open source Tegra drivers at 3.4 too? I would love to see this happen.

    I will post a link when I find it again for a good uart debugger....total cost about 7 bucks.
    Another thing essential to this would be to get a ram disk from a nexus 7 2013 or some other device on 3.4kernel. That ram disk needs to be compared to any good one and the differences closely inspected.

    The way I got 4.2 jb to boot on the gtab involved mix and match proprietary blobs...those nasty files where we don't get to see the code.

    This thread deserves attention.....a whole bunch of external hardware possibilities open up with a 3.4 or 3.8 kernel. The grouper board files and the proprietary blobs are key.

    My nex7 is dead but I will see about buying another. I really want this.

    I'm confident the next step must be someone getting debug info.
    8
    Here's an updated link https://github.com/enssorcel/Grouper-3.4
    The first on doesn't seem to be working

    Woops sorry, I linked to my testing branch so I had deleted it already. For whoever's following this, you want to go here to see what I've merged into the master branch i.e. what I've fixed, and click the branch pulldown and go here to see what we've been working on, the names are self-explanatory.

    Thanks to @sgt. meow 's help we've made quite a bit of progress, we've fixed the errors for the majority of the grouper files so we're getting close to a successful compilation. Beyond that, who knows.

    EDIT: Just fixed board-grouper-power.c. sensors will be the next focus, hopefully fixed soon.

    EDIT1: All board files are fixed! (well, the compilation errors are gone, but we don't know if they work yet)
    6
    Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3

    I don't suppose anyone has a serial cable and access to UART or anything similar?
    6
    As you all probably know, even after updating the board files against KAI from the nvidia source, we couldn't get it to boot. So we applied a few commits from Google, and guess what, still doesn't boot. If anyone wants to join in the chat at hangouts, drop in your gmail here. We need all the help we can get.