yashsingh1/xdaforums huggingface dataset:
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
Don't worry, not giving up, just thinking. We Ideally need someone with a serial cable because we're kinda stuck without debuuging unless we can find someone who can spot the problems from the code.
[Nexus 7 Developer Discussion [Developers Only]] USBhost:
where can one get such a cable
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
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 :)
[Nexus 7 Developer Discussion [Developers Only]] USBhost:
interesting I'll see what I can do

Not making any promises

Edit: it shouldn't be too hard to make

Just need $17.17 to make it

Will see
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
I'm not sure you'll have much luck with the UART cable. An RD (now retired) got his device to recognise the UART board, but failed to receive any output. :(
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
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.
[Nexus 7 Developer Discussion [Developers Only]] Thömy:
Maybe the kernel boots far enough to leave some traces in last_kmsg. The only problem is that the contents are lost if the device is powered off. If you're lucky the contents survive a short time without power. But usually if the kernel boots far enough it will panic and restart itself.
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
You can see traces of multiROM but yeah that's the main problem. I'll have a go anyway, thanks.

Thanks to everyone supporting us, linking in sigs, etc., as sgt. meow said if you can help in anyway then just drop your gmail here or in a PM to one of us so you can join the discussion.

EDIT: Nope doesn't work. Interestingly the secondary ROM appears to fall back on the internal kernel if it can't boot. But no, no traces from the failed boot.
[Nexus 7 Developer Discussion [Developers Only]] Doward:
So where are we at on this? How can I help?
[Nexus 7 Developer Discussion [Developers Only]] Erovia:
This thread deserves more attention.

Hope you guys can figure it out, it would give a new boost to our faithful devices. :fingers-crossed:
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
We've applied Googles commits for the grouper board files then adapted Nvidia's commits for the Kai developer board for grouper to get the board files up to date with 3.4. When we die this wed hoped they were similar enough that it would work but I don't think that's the case. To help you can

Debug the non booting image with a serial cable and UART

If you don't have a serial cable then dont waste money on one because no one has got output from UART as of yet

Send me or sgt. meow your gmail to join the "dev" discussion

fork the source and play around with it to see if you can make anything work

just simply spread the word and ask for help

Thanks, if we ever get it booting it'll be so much easier to get stuff working, I'm learning C pretty quickly so as soon as we can get anything useful from kmsg or dmesg then we should be able to get development going much faster. It may or may not seem "fast" at the moment but that's cause we're basically just experimenting.
[Nexus 7 Developer Discussion [Developers Only]] Erovia:
So as of now, you have a 3.4 kernel with Google's and Nvidia's commits, but doesn't give any lifesign?

Without logs it's imposibble to tell, but either very few or very many code is missing.

Anyway, I've tipped the portal, maybe they feature this thread. It would give a great deal of boost to the project.
[Nexus 7 Developer Discussion [Developers Only]] lupohirp:
mmmm....this commit https://github.com/enssorcel/Grouper-3.4/commit/f6d950f12ce66697d927a306fa2f12ee51257130 doesn't disable bus drivers???

EDIT:Wait: disable this CONFIG_TEGRA_IOMMU_SMMU=y since in CM sources is disabled but IOMMU is needed beacuse on kernel 3.1 it was enabled a prevoius version: CONFIG_IOMMU_SUPPORT=y.

Check in your sources if this config is already there....if there is, so enable it, else.....you must enable CONFIG_PLATFORM_ENABLE_IOMMU and then resolve errors.

Can you post errors so maybe i can help???

Edit2: or maybe you can port the code that is enabled if CONFIG_IOMMU_SUPPORT is activated.
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
Pretty much yeah. Thanks a bunch, if this got on the portal hopefully lots more people could help.

I couldn't find this anywhere in the 3.1.10 defconfig, and with it enabled we got an error due to a missing deceleration or something (I can't remember exactly).
[Nexus 7 Developer Discussion [Developers Only]] lupohirp:
yes but on kernel 3.1 you have this : CONFIG_IOMMU_SUPPORT=y. in your kernel you haven't any IOMMU generic support and tegra IOMMU (the one that you have enabled and seems strange since also CM and Google disabled it) doesn't work....
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
Well scratching out PLATFORM_ENABLE_IOMMU and enabling IOMMU_SUPPORT instead (without any other change) allows the build to finish without errors. Still doesn't boot though. Of course I tried the zImage method and not the boot.img method.
[Nexus 7 Developer Discussion [Developers Only]] lupohirp:
IOMMU_SUPPORT was present in 3.4 code??
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
Surprisingly yes. It built drivers/iommu w/o errors.
[Nexus 7 Developer Discussion [Developers Only]] TeamMex:
Hey what branch is the correct branch? master or Board-grouper-testing :)

I like to help correctly :)
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
board-grouper-testing is the last branch updated. It was created to work out board file problems.

But I do work on test (on my repo) and then send pull requests to board-grouper-testing from there.
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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.
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
I'm no hardware engineer so I'd surely end up breaking something, I think we may have some people on the case though in regards to UART.

I'm not sure about 3.8 yet, it's not even the main release for Nexus devices yet. But yes, we do have the entire 3.4 source for tegra3 with all the drivers.

Why do we need the ramdisk from a 3.4 kernel? Surely the 3.1.10 ramdisk would work, as the mount points etc. should be the same?

That's getting a ROM booting, we don't need anything proprietary for the kernel... if there was anything proprietary in the kernel (which there isn't) then it'd be impossible to port anyway.

Thanks for your support :good:
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
As far as booting a different kernel on a rom it's not that the mount points are different... it's just tricky to get the custom kernel to call the hardware blobs at the right time. From personal experience on the gtab, we had a 2.6.39 kernel from nvidia/viewsonic/malata. ..and blobs for a rom that expected a 2.6.39.

once the tablet was booted for the first time on jellybean 4.1 and the 3.1.10 kernel, those same proprietary blobs were used.

However... I was the first one to get jb 4.2 to boot, but this occurred AFTER experimenting with newer updated proprietary blobs which Nvidia actually released for the tf101 board. Tegra2 had 3 different boards and even tho the tf101 board was newer....some of those updated blobs worked for our Tegra2. ..and jb 4.2 finally booted.

I looked into this in the past....... and i remember that there is a phone...iIRC an HTC, which has a tegra3 chip AND the 3.4 kernel. My "idea" was to make custom board files......get UART. ...and start expirementing with blobs from that phone.

as far as booting the kernel... xda member "fosser2" is the guy who soldered the serial debugger to his motherboard. Then....others were sending him test kernels and he would pastebin the results and eventually...it happened. He would be WAY more helpful.....and he could more correctly explain things that I can't. I will pm him and see if I can get a hold of him.

I personally can't say I have specific knowledge of what needs to be done.......but I have a lot of experience in accomplishing the same thing on an older tablet. The lesson was....it ended up being more than just the kernel to get it to boot. But I bet you could use a test 3.4 and try to boot Ubuntu also.

I'm buying another nex7 in a few days and i too will attempt a serial connection.
[Nexus 7 Developer Discussion [Developers Only]] Monfro:
About HTC One X 3.4 kernel:

http://xdaforums.com/showthread.php?t=1640532

Great news you will be working on Nvidia 3.4 kernel too!!
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
That kernel was brought up completely from mainline. We use the nVidia source, A little different.

[MENTION=4035939]redeyedjedi[/MENTION]

Great to see you here too, dude. What blobs are you talking about? Those in the ramdisk's sbin directory?
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
No.... get ready for more long-winded response....

I'm not talking about the kernel....or anything in the zimage. I'm suggesting that your kernel could be Bootable, but won't boot because of the ROM. More specifically....I'm talking about the files you would find under /vendor/asus/grouper of a ROM build.

these files are the same as you can find in the Linux Nvidia tegra git.......where you got the kernel source.....BUT not kernel files..there are also updated blobs in that git which would go into /vendor/asus/grouper.

This is just theory but important. I'm suggesting that there may be files in /vendor/htc/onex (or whatever it's called) which are made for tegra3 running 3.4 kernel...and those files could be placed in /vendor/asus/grouper

this may not even be an issue at all....but my old view sonic gtab never got support past froyo. ......nothing. BUT.....with the help of 3.1.10 code from the Nvidia tegra git we got gingerbread, ics, and jb 4.1.

I got 4.2 also.....

AFTER using some tegra2 blob files from the Asus transformer tf101. These were ROM blob files that made the tablet finally boot....and eventually after a lot of toying around we had HW acceleration, etc.

I really need to talk to fosser2. ...he is the kernel guy. I am merely trying to point out what other steps may be needed to boot this kernel...tho I'm almost certain that the very next step should be to get debug info spitting out as soon as you push the power button. I'm excited by the possibility of getting good it through the headphone jack. I'm buying a new nex7 today.

all the stuff I'm talking about should be considered after we get some serial debug Goin. The only concerns i have about the ram disk is that the 3.4 kernel in general could have some differences with respect to a 3.1 ram disk. ...maybe the Nvidia git is complete here since there IS a tegra3 device running a 3.4 kernel......there will be some blob files that are the same between the onex and the nexus.
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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)
[Nexus 7 Developer Discussion [Developers Only]] USBhost:
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
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
[MENTION=4035939]redeyedjedi[/MENTION] and [MENTION=5501864]USBhost[/MENTION]

The headphone jack UART is still our best shot. Look at this: https://android.googlesource.com/kernel/tegra/+/android-tegra3-grouper-3.1-jb-fr1

We just need to find out the appropriate triggers.
[Nexus 7 Developer Discussion [Developers Only]] USBhost:
Has any one asked Google about it
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
Nope.
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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.
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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.
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
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 [MENTION=4693882]HTCDreamOn[/MENTION] 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 [MENTION=4693882]HTCDreamOn[/MENTION]

Although UART should have no relation to the screen, does the above mean anything?
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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??
[Nexus 7 Developer Discussion [Developers Only]] HTCDreamOn:
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.
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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:
[Nexus 7 Developer Discussion [Developers Only]] AshRoller:
i think you can use linux terminal to display serial console output
[Nexus 7 Developer Discussion [Developers Only]] n1kolaa:
did someone sow thouse codes?

its 3.4 kernel for andorid l :)

https://android.googlesource.com/kernel/tegra/+/android-tegra-molly-3.4-l-preview
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
I have seen that before. Thanks for bringing it to our attention again.

If any of you wish to help please join our Hangouts. We're not making muchb progress anymore. :(
[Nexus 7 Developer Discussion [Developers Only]] HeadKase:
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 [MENTION=4035939]redeyedjedi[/MENTION]? 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
[Nexus 7 Developer Discussion [Developers Only]] Erovia:
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?
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
That's been there for a long time. Maybe it does have helpful info. I'll look at the board files.
[Nexus 7 Developer Discussion [Developers Only]] AshRoller:
sadly it's for New Google Set Top Boxes codenamed "Molly" , no grouper codes.
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
Yeah but maybe the way they were updated from the nVidia source tells us something? Just maybe. ;)
[Nexus 7 Developer Discussion [Developers Only]] redeyedjedi:
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.
[Nexus 7 Developer Discussion [Developers Only]] sgt. meow:
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.
[Sony Xperia S, Acro S, Ion] RFC08:
My xperia s started having around a minute delay between clicking on a contact to make a call and actually making the call and there is a delay with texts aswell, I restored all my apps with titanium backup then downloaded updates and phone worked fine for a week until it did some app updates then the delay happended again. Is there a quick way to resolve this without restoring everything again?
[Sony Xperia S, Acro S, Ion] lubbesflipperi:
I experience the same issue on almost all the ROMs i tried on my Xperia S. Still having this on latest RC 2 of official paranoid.

I hope someone knows how to fix this.

Cheers
[Sony Xperia S, Acro S, Ion] tel033:
Experiencing this for a while now it comes and goes any fix??
[MDA, XDA, 1010 General] Sci:
Been nosing around here for a bit, but finally I need to ask something I can't seem to find already.

I have a Wallaby. It works just lovely, but I've bought an SDIO wifi card (Spectec SDW-821 802.11b/g), intending to use it on it.

The issue is that even once I perseude it to install, the cards instructions tell me to configure it with the WLAN utility. Which doesn't seem to be included on the developer ROM? I've tried installing it from an incorrect wifi card driver set, which unsuprisingly doesn't work. On PPC2003, it also comes up as not recognised each time it's inserted.

Maybe I'm just looking in the wrong place, but I can't see the util. What would be the right ROM choice to allow use of an SDIO wifi card?
[MDA, XDA, 1010 General] Rudegar:
wallaby dont support SDIO

no wifi card will ever work in it
[MDA, XDA, 1010 General] Sci:
Well that explains that then! Thanks resolving that at least! ^_^;