Jump to content

Advent Vega kernel source code now available!


Guest PaulOBrien

Recommended Posts

It is an i2c problem, but caused by the touchscreen controller... I don't know why, but seems like the touchscreen takes a long time to initialize... And it shouldn't. What you see in the logs is that the touchscreen controller is not responding to i2c commands... Are you absolutely sure this didn't happen with the original android 2.2 ROM ? -- Cause it could be a hw problem... "Not reasponding" means that some areas do not work, or that no screen area works at all ?

I'll flash ModdedStock v2 today and try to create logs again. But it's not easy, because it has to be shut down for an extended period before the problem appears.

In the first couple of seconds, the touchscreen is not responsive anywhere.

Then it's responsive in the right 4cm column of the screen, but nowhere else, however it senses multiple touch everywhere, but always registering touches in very right column too, no matter where I touch it with the multiple fingers.

Then (a couple of minutes later) it starts registering single touches, (but not drags) on the majority of the screen, and almost always registers ghost touches on the right side too.

Then (after another couple of minutes) it start working fine...

The i2c error messages come when I try to click very rapidly (and with multiple fingers too) on the lest side of the screen in the first couple of minutes.

I noticed a section in the it7260 pdf about a command to synchronize CDC. I don't think it's currently implemented in the driver. What is that good for?

Regards,

Z

Link to comment
Share on other sites

I'll flash ModdedStock v2 today and try to create logs again. But it's not easy, because it has to be shut down for an extended period before the problem appears.

In the first couple of seconds, the touchscreen is not responsive anywhere.

Then it's responsive in the right 4cm column of the screen, but nowhere else, however it senses multiple touch everywhere, but always registering touches in very right column too, no matter where I touch it with the multiple fingers.

Then (a couple of minutes later) it starts registering single touches, (but not drags) on the majority of the screen, and almost always registers ghost touches on the right side too.

Then (after another couple of minutes) it start working fine...

The i2c error messages come when I try to click very rapidly (and with multiple fingers too) on the lest side of the screen in the first couple of minutes.

I noticed a section in the it7260 pdf about a command to synchronize CDC. I don't think it's currently implemented in the driver. What is that good for?

Regards,

Z

CDC = Capacitive to Digital Converter...? (no idea, it is just a mere speculation) -- There is no explanation on that command... I have no idea on the purpose of it...

As a sidenote, the new driver is using CDC autotuning, and the one present in 2.2 is not... Have no idea if it does make a difference or not... But made sense at that time...

Edited by ejtagle
Link to comment
Share on other sites

Well.. here it is the last kernel version:

-Fixes the sleep problems, as explained in the previous posts... It was an android bug, not a driver bug ...

-Fixes pops in audio capture and playback... No promises, but it works for me

-Tries to reduce noise in recording, using the tricks outlined by CowPlagued

-The camera defaults now to powered down. The libcamera will turn it on demand, saving power

Well, thats all

Eduardo

Could you tell me if there's a possibility to upload a compiled version of this kernel? If I have understood it correctly, one could extract the boot.img and repack it with the new kernel to implement these fixes? Because the battery drain while in standby is quite heavy now and this fix would be the last major hurdle for me.

I have already applied the new libcamera (from earlier in this topic) and can happily report that it is working perfectly for me...

Link to comment
Share on other sites

Could you tell me if there's a possibility to upload a compiled version of this kernel? If I have understood it correctly, one could extract the boot.img and repack it with the new kernel to implement these fixes? Because the battery drain while in standby is quite heavy now and this fix would be the last major hurdle for me.

I have already applied the new libcamera (from earlier in this topic) and can happily report that it is working perfectly for me...

I prepare an update for VC 9n and 9b right now.

Wait a little bit, then you can downlod it at the known threads.

Link to comment
Share on other sites

Guest Alexzandro

Hello everybody!

I'm so happy Eduardo and rebel1 share same device as mine! Leonardo da Vinci had the same intent in developing knowledge as I can modestly see!

Keep up the refining work - ICSandwich is coming !

Hope for Mrz_hun he also has a POV

Regards

Alessandro

Link to comment
Share on other sites

Guest CoWPlagued
<br />Well.. here it is the last kernel version:<br /><br />-Fixes the sleep problems, as explained in the previous posts... It was an android bug, not a driver bug ...<br />-Fixes pops in audio capture and playback... No promises, but it works for me<br />-Tries to reduce noise in recording, using the tricks outlined by CowPlagued<br />-The camera defaults now to powered down. The libcamera will turn it on demand, saving power<br /><br />Well, thats all<br /> Eduardo<br />
<br /><br /><br />

Awesome work. Rec sound now much better, no pops at all. (And talking tomcat works ;) !!) Everything else looking good. Shall report back on battery life.

Cheers

Link to comment
Share on other sites

A bit of an update regarding the touchscreen issue:

I reflashed ModdedStock v2 while touchscreen wasn't working, and the reflash did not solve it.

I looked at proc/kmsg, but it did not seem to report any i2c problems, only messages like it7260 irq triggered, (which - to me - did not seem to indicate a problem).

While the touchscreen was problematic, I managed (through adb) to upload the touchscreen utility, and to recalibrate the screen with it. It solved the problem instantly, which is very interesting because the recalibration in 9n never fixed it.

Now I am letting it rest powered dow for a while, to find out if the problem is still there.

If it comes back with moddedstock, i'll try to dump proc/kmsg again in case it contains something interesting...

Btw, this is a POV Mobii Tegra, not an original Advent Vega...

Link to comment
Share on other sites

A bit of an update regarding the touchscreen issue:

I reflashed ModdedStock v2 while touchscreen wasn't working, and the reflash did not solve it.

I looked at proc/kmsg, but it did not seem to report any i2c problems, only messages like it7260 irq triggered, (which - to me - did not seem to indicate a problem).

While the touchscreen was problematic, I managed (through adb) to upload the touchscreen utility, and to recalibrate the screen with it. It solved the problem instantly, which is very interesting because the recalibration in 9n never fixed it.

Now I am letting it rest powered dow for a while, to find out if the problem is still there.

If it comes back with moddedstock, i'll try to dump proc/kmsg again in case it contains something interesting...

Btw, this is a POV Mobii Tegra, not an original Advent Vega...

I also have a POV Mobii ;) - BTW ... i have heard about all the problems on autorotation... There are contradictory requirements here: If you try an accelerometer test program, you should get 9.8 m/s² as the acceleration in the Z axis, if the screen is perfecty horizontal. But, to get it, i had to adjust the scaling factors of the accelerometer driver. Seems the autorotation of HC requires a value close to that maximum in an specific axis to rotate the screen... That is why it is required to place screen in a given position ... If i change the scaling, then it seems to work faster, but then measurements would be in an arbitrary unit.... Or perhaps, an even faster accelerometer update rate is required... :S Any ideas ?

Edited by ejtagle
Link to comment
Share on other sites

Another update regarding the touchscreen issue.

I flashed the stock POV Mobii Tegra ROM back last night, and let it rest until morning.

When I turned it on, the touchscreen problem was there, but it resolved itself in less than a minute. I remember Eduardo mentioned that the back hw key initiates a recalibration, but to be honest, I don't remember if I pressed the back key during testing. I will try to see if the touchscreen is bad when I get home this evening. If it is, I'm pretty sure it's a HW issue, and I'll try to get my tablet replaced.

Eduardo, do you know what kind of recalibration the back button triggers? And what kind the stock touchscreen recalibration tool triggers?

Link to comment
Share on other sites

Another update regarding the touchscreen issue.

I flashed the stock POV Mobii Tegra ROM back last night, and let it rest until morning.

When I turned it on, the touchscreen problem was there, but it resolved itself in less than a minute. I remember Eduardo mentioned that the back hw key initiates a recalibration, but to be honest, I don't remember if I pressed the back key during testing. I will try to see if the touchscreen is bad when I get home this evening. If it is, I'm pretty sure it's a HW issue, and I'll try to get my tablet replaced.

Eduardo, do you know what kind of recalibration the back button triggers? And what kind the stock touchscreen recalibration tool triggers?

As far as i know, the same recalibration...

Link to comment
Share on other sites

Just a quick note on the clock resetting to the start of the epoch when reinstallng, or sometimes, rebooting... I have an idea on the possible causes.. In the shuttle hardware, there are 2 RTCs (Realtime clock) ... One of them is in the Tegra2 SoC, and the other is in the TPS6586x . The .32 kernel didnt support the Tegra2 embedded RTC. It just used the TPS6586x RTC. The new .36 kernel supports both RTCs. I do suspect that one of those RTCs is not keeping the date after powerdown. And that Android is taking the date from that RTC.

The reason i enabled the Tegra2 RTC is that that RTC supports waking up the device from deep sleep, allowing us to program alarms to wake up the device. The TPS6586x , even if it also has HW to support alarms, seems not to be properly tied to the Tegra2 SoC to allow the RTC to wake up the SoC... Seems it is unable to signal an interrupt to the Tegra2 SoC - Or, at least, i didn't find any information on the .32 kernel to assume this is working... If you look at the kernel files related to RTC, you'd find that i have configured an interrupt for the tps6586x RTC. That interrupt line was just a guess.. There is no proof that it is actually working...

The Tegra2 RTC, as it is internal to the SoC, supports alarms, but i don't know if it is kept powered on while the tablet is off... a requirement to keep the time while the tablet is off...

we will have to get date from both RTC clocks, and synchronize the failing one to the wroking one at the android boot. I think it could work ;)

Link to comment
Share on other sites

Just a quick note on the clock resetting to the start of the epoch when reinstallng, or sometimes, rebooting... I have an idea on the possible causes.. In the shuttle hardware, there are 2 RTCs (Realtime clock) ... One of them is in the Tegra2 SoC, and the other is in the TPS6586x . The .32 kernel didnt support the Tegra2 embedded RTC. It just used the TPS6586x RTC. The new .36 kernel supports both RTCs. I do suspect that one of those RTCs is not keeping the date after powerdown. And that Android is taking the date from that RTC.

The reason i enabled the Tegra2 RTC is that that RTC supports waking up the device from deep sleep, allowing us to program alarms to wake up the device. The TPS6586x , even if it also has HW to support alarms, seems not to be properly tied to the Tegra2 SoC to allow the RTC to wake up the SoC... Seems it is unable to signal an interrupt to the Tegra2 SoC - Or, at least, i didn't find any information on the .32 kernel to assume this is working... If you look at the kernel files related to RTC, you'd find that i have configured an interrupt for the tps6586x RTC. That interrupt line was just a guess.. There is no proof that it is actually working...

The Tegra2 RTC, as it is internal to the SoC, supports alarms, but i don't know if it is kept powered on while the tablet is off... a requirement to keep the time while the tablet is off...

we will have to get date from both RTC clocks, and synchronize the failing one to the wroking one at the android boot. I think it could work ;)

If you set the time at moddedstock then it keeps time when installing VegaComb. Presumably ModdedStock sets the TPS6586x which is then transferred through to VC.

Link to comment
Share on other sites

Just a quick note on the clock resetting to the start of the epoch when reinstallng, or sometimes, rebooting... I have an idea on the possible causes.. In the shuttle hardware, there are 2 RTCs (Realtime clock) ... One of them is in the Tegra2 SoC, and the other is in the TPS6586x . The .32 kernel didnt support the Tegra2 embedded RTC. It just used the TPS6586x RTC. The new .36 kernel supports both RTCs. I do suspect that one of those RTCs is not keeping the date after powerdown. And that Android is taking the date from that RTC.

The reason i enabled the Tegra2 RTC is that that RTC supports waking up the device from deep sleep, allowing us to program alarms to wake up the device. The TPS6586x , even if it also has HW to support alarms, seems not to be properly tied to the Tegra2 SoC to allow the RTC to wake up the SoC... Seems it is unable to signal an interrupt to the Tegra2 SoC - Or, at least, i didn't find any information on the .32 kernel to assume this is working... If you look at the kernel files related to RTC, you'd find that i have configured an interrupt for the tps6586x RTC. That interrupt line was just a guess.. There is no proof that it is actually working...

The Tegra2 RTC, as it is internal to the SoC, supports alarms, but i don't know if it is kept powered on while the tablet is off... a requirement to keep the time while the tablet is off...

we will have to get date from both RTC clocks, and synchronize the failing one to the wroking one at the android boot. I think it could work ;)

That is what i mean in my post at TabletRoms.

But I have no idea, why it doesn´t work for some poeple?! :huh:

I compile the kernel with both rtc´s , because android alarms only work on the tegra rtc.

The only trick that i did is to set rtc1 (The TPS rtc) in the kernel config as default rtc for system date and clock.

And yes, the tegra rtc don´t hold the data after powerdown.

rebel1

Link to comment
Share on other sites

Ok,

i checked it again.

The problem is, that when kernel and android starts , the system time and date is set by the TPS rtc (when it have valid data),this is rtc1.

But when you set date and time under Android it is written to rtc0, the tegra rtc and not to rtc1.

Unfortunately the tegra rtc can't hold the data when you power off and so you loose date and time after reboot.

A quick workaround is to set only the TPS rtc active in the kernel,but then we will loose alarm wakeups in deep standby.

rebel1

Link to comment
Share on other sites

Well, in this case, i think we can take the best from both RTCs ;) -- Attached my mods to the tegra RTC driver, so it, at initialization, get the date from the TPS RTC, and then, everytime the date is updated, it also sets the TPS date... So, it uses the TPS RTC as a backup ;)

To use it, please take a look at the new options i added to the kernel config:

-Enable both RTCs (tegra and TPS)

-Use rtc0 as the rtc that supplies the system time at boot

-Enable RTC_TEGRA2_BACKUP_RTC

-Set RTC_TEGRA2_BACKUP_RTC_DEV to rtc1

Also, i included my kernel config so you can peek the options i am using (just in case)

This "patch" makes the tablet able to keep the time even if shut down ;)

Regards,

Eduardo

RTC-WAR.rar

Link to comment
Share on other sites

Another update on my touchscreen ordeal:I went back to POV Mobii Stock ROM (v1.10) and only saw the problem initially until I recalibrated the touchscreen.

I have not seen the problem ever since, even thought I left the device on charger overnight (completely powered off).

This morning it was working well. (I made sure not to press the back button before confirming the touchscreen was OK).

I am now going to go back to VegaComb (9n update2) and try I'll to wipe battery status in clockwork before flashing it.

I'm not a hardware expert, but I have a feeling (and this is just a guess) that this might have to do with some overvoltage.

The reason I think this, is that most of the time I use my tablet, I leave it on the charger.I think (!) that when I pulled it off the charger, and battery loses some power, my touch screen slowly starts to regain functionality. (I will have to check this hypothesis.)

Can this be possible?

Edit:

After reflashing VegaComb, the touchscreen problem is immediately back!

Edited by mrz_hun
Link to comment
Share on other sites

Well, in this case, i think we can take the best from both RTCs ;) -- Attached my mods to the tegra RTC driver, so it, at initialization, get the date from the TPS RTC, and then, everytime the date is updated, it also sets the TPS date... So, it uses the TPS RTC as a backup ;)

To use it, please take a look at the new options i added to the kernel config:

-Enable both RTCs (tegra and TPS)

-Use rtc0 as the rtc that supplies the system time at boot

-Enable RTC_TEGRA2_BACKUP_RTC

-Set RTC_TEGRA2_BACKUP_RTC_DEV to rtc1

Also, i included my kernel config so you can peek the options i am using (just in case)

This "patch" makes the tablet able to keep the time even if shut down ;)

Regards,

Eduardo

Hi Eduardo,

great work again. ;)

I wish that I have only the half of your knowledge about the linux kernel and drivers! But I have amazing fun to learn from you and your work on this project. Big thanks for that. :D

Ok, back to topic.

Your patch have no side effects for people like me that becomes valid data from the TPS before the last patch,

now we will see, if it can fix the problem for people that have a problem with the clock before.

I don´t understand at the moment why the TPS rtc did not delivers valid data for them.

Rene

Edited by rebel1
Link to comment
Share on other sites

Well, in this case, i think we can take the best from both RTCs ;) -- Attached my mods to the tegra RTC driver, so it, at initialization, get the date from the TPS RTC, and then, everytime the date is updated, it also sets the TPS date... So, it uses the TPS RTC as a backup ;)

To use it, please take a look at the new options i added to the kernel config:

-Enable both RTCs (tegra and TPS)

-Use rtc0 as the rtc that supplies the system time at boot

-Enable RTC_TEGRA2_BACKUP_RTC

-Set RTC_TEGRA2_BACKUP_RTC_DEV to rtc1

Also, i included my kernel config so you can peek the options i am using (just in case)

This "patch" makes the tablet able to keep the time even if shut down ;)

Regards,

Eduardo

Patch works great for me .. thanks very much ... i was one of the problem users :)

edit :- weirdly although the patch works, on boot the time is 1hr ahead of my tz london BST .. then it flicks back to proper time ... clocksync is uninstalled and network time is not set .. so i guess one clock on boot is out slightly and the other is fine ... no issue, just thought id mention it :)

Cheers

Cass

Edited by Cass67
Link to comment
Share on other sites

Patch works great for me .. thanks very much ... i was one of the problem users :)

edit :- weirdly although the patch works, on boot the time is 1hr ahead of my tz london BST .. then it flicks back to proper time ... clocksync is uninstalled and network time is not set .. so i guess one clock on boot is out slightly and the other is fine ... no issue, just thought id mention it :)

Cheers

Cass

Probably that is true... You can tell exactly if that is the case or not using adb.. just do

cat /sysclass/rtc/rtc0/time

cat /sysclass/rtc/rtc1/time

And you can compare the time stored in each RTC to see if they match. You can also try to set the date, even if setting the same. This will force both rts to be in sync ;)

My guess, for the people who are not getting the right time from the TPS RTC is as follows: I assume the RTC is powered by the same main battery as the Vega itself. So, if the battery completely drains, then TPS will lose time. The main problem here is that VC is unable to set the TPS time (without the patch)... And, once the TPS loses power, it will stop holding a valid time... and, as the linux kernel gets the time from it, then Android gets the system time from it. But, if you set the system time using "Settings", , then system time and the Tegra RTC , both are set... but not the TPS. So, if the tablet is never shut down, then system time will be correct (the tegra RTC and the linux system time will track the real time... But, if you reboot it, tegra2 rtc loses power, so it stops tracking time.. and TPS RTC does not lose power, but it was never set, so the tracked time will be incorrect... Using ModStock, as it uses the .32 kernel, allows us to set the TPS RTC, but not the tegra RTC... And the TPS RTC will track time , at least, until battery runs out of juice :D

Eduardo

Edited by ejtagle
Link to comment
Share on other sites

Another update on my touchscreen ordeal:I went back to POV Mobii Stock ROM (v1.10) and only saw the problem initially until I recalibrated the touchscreen.

I have not seen the problem ever since, even thought I left the device on charger overnight (completely powered off).

This morning it was working well. (I made sure not to press the back button before confirming the touchscreen was OK).

I am now going to go back to VegaComb (9n update2) and try I'll to wipe battery status in clockwork before flashing it.

I'm not a hardware expert, but I have a feeling (and this is just a guess) that this might have to do with some overvoltage.

The reason I think this, is that most of the time I use my tablet, I leave it on the charger.I think (!) that when I pulled it off the charger, and battery loses some power, my touch screen slowly starts to regain functionality. (I will have to check this hypothesis.)

Can this be possible?

Edit:

After reflashing VegaComb, the touchscreen problem is immediately back!

I suspect the problem is the autotuning feature that it is left enabled in the .36 kernel, but was not used in the .32 kernel...

Link to comment
Share on other sites

I'm having trouble booting into recovery or bootloader mode.

What is the exact process?

Whenever I run adb reboot-bootloader, or adb reboot recovery it just reboots normally.

I tried turning the device completely off, then back on. But I just can't get into recovery or bootloader mode.

Edited by mrz_hun
Link to comment
Share on other sites

Guest jevdroid

Hey guys,

I'm trying to hook VC9 to a shared internet connection on a froyo phone through USB. The phone's internet sharing works when connecting to a Windows machine. Seems I need a set of drivers for VC9 that allow network access through USB. Anyone knows if they exist and where to get them?

Link to comment
Share on other sites

Hey guys,

I'm trying to hook VC9 to a shared internet connection on a froyo phone through USB. The phone's internet sharing works when connecting to a Windows machine. Seems I need a set of drivers for VC9 that allow network access through USB. Anyone knows if they exist and where to get them?

Probably the kernel supports it... but it is not compiled into the default kernel. Even if compiled into the kernel, i don't know if Android would be able to configure the interface and use it...

Link to comment
Share on other sites

BTW. i was thinking about the HDMI issue... The display not filling the screen is probably an Android issue, not a kernel one (perhaps related to DPI or perhaps related to some hardcoded values in HC... Tegra2 supports several HDMI resolutions... The kernel is configured right now to output 1280x720. This resolution can even be increased to full HD (1920x1080), but it is required to recompile the kernel. It could also be lowered to 720x480 or 720x576 ... Perhaps HC is expecting it to be 720x576 ... and that causes the "left top" image issue... I think that lowering down the HDMI output resolution just to let Android fill the screen is the dumbest idea i have heard so far... Quite to the contrary, i am thinking in increasing the output resolution to fullHD... After all, the most useful use of HDMI is to display movies ;) -- And perhaps, Android could be convinced to output to that resolution..

Ideas, thoughts ? :)

Eduardo

Link to comment
Share on other sites

Hey guys,

I'm trying to hook VC9 to a shared internet connection on a froyo phone through USB. The phone's internet sharing works when connecting to a Windows machine. Seems I need a set of drivers for VC9 that allow network access through USB. Anyone knows if they exist and where to get them?

Search for reverse tethering. You should find a couple of threads at XDA. (I haven't tried any of the methods described, but they might work for you.)

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.