PaulOBrien

Advent Vega kernel source code now available!

2862 posts in this topic

With screen up mine is the right one... next to he usb port... Yours is right or left with screen up??? Because i think that is not a real speaker problem, its a near speaker problem...

I this photo:

5209067148_da6308ef40.jpg

With screen down, down in the photo is left, left is up...etc. I think something somewhere near the speaker is getting too hot (not the speaker directly), my batt had marked more than 40ºC and is not really near this point. So this speaker seems to be the failing one, because the temperature is too hot, and it depends of the quality of the speakers if it resist this hot.

I think this because:

1) For what i read, only this speaker is failing, the one next to the usb port. If there is a volume problem, why didnt blow the 2 speakers?

2) Like i said before, with volume 0 the back of the tablet gets very hot (like when we are using overclocking in Corvus5).

3) It seems that the change in mvolts from 500 to 2 is helping, but is getting hot too, maybe less, but more that with Corvus5 or old Vegacomb.

So i think that some component is getting really hot and kill this speaker, but i dont know how can we check it.

Corvus.

Hi,

my problematic speaker is the one on the other site, when i look from the back of the tablet it is the right one.

0

Share this post


Link to post
Share on other sites

OK All,

I've been reading the USB specification and the value "Maximum VBUS power usage" refers to is the maximum power any one device can draw from the USB interface. If we have allowed devices to draw up to 500mA this could cause any are all USB connected devices to 'burn out'

What we may be finding is that it is in fact the USB controller that is struggling and the source of the overheating problem. By setting this back to 2mA which a quite normal setting for devices, so returning to this more standard setting (Digital Cameras, etc..) then we should find all are problems are solved.

Billy..

PS.

If in doubt please verify these claims yourself as no-one will take responsibility if you damage your own or others equipment. As you never know I might be wrong......

A USB device specifies its power consumption expressed in 2mA units in the configuration descriptor. Low power bus powered functions draw all its power from the VBUS and cannot draw any more than one unit load. The USB specification defines a unit load as 100mA

Edited by BillyBobJoe
0

Share this post


Link to post
Share on other sites

OK All,

I've been reading the USB specification and the value "Maximum VBUS power usage" refers to is the maximum power any one device can draw from the USB interface. If we have allowed devices to draw up to 500mA this could cause any are all USB connected devices to 'burn out'

What we may be finding is that it is in fact the USB controller that is struggling and the source of the overheating problem. By setting this back to 2mA which a quite normal setting for devices, so returning to this more standard setting (Digital Cameras, etc..) then we should find all are problems are solved.

Billy..

PS.

If in doubt please verify these claims yourself as no-one will take responsibility if you damage your own or others equipment. As you never know I might be wrong......

A USB device specifies its power consumption expressed in 2mA units in the configuration descriptor. Low power bus powered functions draw all its power from the VBUS and cannot draw any more than one unit load. The USB specification defines a unit load as 100mA

I may be inclined to agree with this. At least one user has noted that his speaker "burnt out" while his volume was muted. He was using his tablet to play games while plugged in to the power supply, and he could smell smoke coming from his tablet. Maybe the combination of this USB issue and extra heat generated by the battery charging circuit are pushing the components around them over the edge?

I still think it would be prudent to also lower the volume in conjunction with the 2ma fix though, as I would be reluctant to release this as a speculative "fix" for the issue without any concrete evidence :/

newbe5

0

Share this post


Link to post
Share on other sites

OK All,

I've been reading the USB specification and the value "Maximum VBUS power usage" refers to is the maximum power any one device can draw from the USB interface. If we have allowed devices to draw up to 500mA this could cause any are all USB connected devices to 'burn out'

What we may be finding is that it is in fact the USB controller that is struggling and the source of the overheating problem. By setting this back to 2mA which a quite normal setting for devices, so returning to this more standard setting (Digital Cameras, etc..) then we should find all are problems are solved.

Billy..

PS.

If in doubt please verify these claims yourself as no-one will take responsibility if you damage your own or others equipment. As you never know I might be wrong......

A USB device specifies its power consumption expressed in 2mA units in the configuration descriptor. Low power bus powered functions draw all its power from the VBUS and cannot draw any more than one unit load. The USB specification defines a unit load as 100mA

Well.. 2 questions here...

Is the overheat related to the volume issue ? -- Perhaps both are different problems...

1) Does the overheat happen when the tablet is plugged through USB to something ? - Or the overheat does not depend on plugging of the USB controller to something ?

2) I really doubt that the overheat of some components could damage a speaker.. The speaker is has plastic back, if something is overheating so badly, you could easily spot the problem. The back of the speaker would melt.

3) The problem could be related, instead to an overload of the power supply instead... It would be nice to know exactly what is happening here... Guess will have to measure... i wish i had an optic pyrometer (contactless thermometer) so it would be much easier to spot what is overheating... Will have to improvise something instead...

But, don't panic ! :) -- probably it is just too much power going to the speakers ... heat can translate to other places through convection, so, the fact that you think the tablet case is hot at one place does not mean that exacty below it there is a hot spot. Ahh.. and don't trust the batery temperature reported. I really doubt the vega has i battery temperature sensor... Firmware is reporting a fixed temperature, or at least, that is what i think it does ;)

Edited by ejtagle
0

Share this post


Link to post
Share on other sites

I may be inclined to agree with this. At least one user has noted that his speaker "burnt out" while his volume was muted. He was using his tablet to play games while plugged in to the power supply, and he could smell smoke coming from his tablet. Maybe the combination of this USB issue and extra heat generated by the battery charging circuit are pushing the components around them over the edge?

The power supply may be the deciding factor with many of the "burn outs". The extra load will put an additioal strain on the PSU, more heat, allow the USB controller to get driven harder, yet more heat.

Billy..

PS My little girl says :D

0

Share this post


Link to post
Share on other sites

I did notice that in the .32 kernel config we have these options set in usb gadget support

Maximum VBUS Power usuage (2-500ma) = 2

USB peripheral controller = DUMMY HCD (DEVELOPMENT)

however we have them set like this in .36 kernel config

Maximum VBUS Power usuage (2-500ma) = 500

USB peripheral controller = Freescale Highspeed USB DR Peripheral Controller

I don't think the usb peripheral controller option will make a difference but the Maximum VBUS power usage may help.

Can you confirm this is better? Did USB client or host break after setting this back to the old .32 value?

I can confirm the POV shuttle uses the ALC5624. I physically checked this by opening the tablet and reading the chip label. Yes, originally the Tegra devkit used a WM8903, but the ALC5624 integrates a power amplifier, saving BOM costs to the manufacturer (less components, cheaper).

If you try to use the wm8903 driver for the ALC5624, it won-t work at all. The internal programming is different.

Regarding power, the only thing that can be done to limit power reaching the speakers, is just to lower down the speaker volume. You can do it using an ALSA mixer, but i assume Android already controls the ALSA mixer, so the only "safe" way to limit speaker volume is to limit the maximum allowable volume at the driver level. That is what i tried to do with the latest patch. Seems there is a bug somewhere.

Nowadays i am porting the vega support patches and drivers to the latest 11.2.11 nvidia kernel. I already checked out the nvidia repo, and i am working on the porting (not finished yet, again ran out of time while doing it ) ... and, once i get it running, i will also port the volume limiting patch. A very strange thing is that the default volume is less than half the maximum possible... What is happening here is very strange. The ALC5624 has 1Wrms per speaker output. I didn-t think that was a problem at all... but, perhaps, those manufacturers are using 100mW speakers (the ones used in headphones!) ... It would be nice to try to get the speaker model used, so we can check the maximum power supported by it, and limit the volume of the ALC accordingly... :S

Eduardo, how far are you with the porting? I'm about to start working on that myself.

0

Share this post


Link to post
Share on other sites

Well.. 2 questions here...

Is the overheat related to the volume issue ? -- Perhaps both are different problems...

1) Does the overheat happen when the tablet is plugged through USB to something ? - Or the overheat does not depend on plugging of the USB controller to something ?

2) I really doubt that the overheat of some components could damage a speaker.. The speaker is has plastic back, if something is overheating so badly, you could easily spot the problem. The back of the speaker would melt.

3) The problem could be related, instead to an overload of the power supply instead... It would be nice to know exactly what is happening here... Guess will have to measure... i wish i had an optic pyrometer (contactless thermometer) so it would be much easier to spot what is overheating... Will have to improvise something instead...

But, don't panic ! :)

Eduardo,

You're right, number one don't panic.

We need to unfortunate Devs that have suffered from the affliction to help us out here as my Vega just fine and the only real issue is the USB connection to my WinTel PC is not working which may be related to the same setting.

The speaker getting physically damaged is an outside chance but ALC5624 may have suffered a mishap. It could be the temperature sensor has not been set to shut down or the setting needs to be review and set to a lower option.

RN Channel Temp. Sensor Threshold Setting

001: 35°C 011: 65°C

101: 95°C 111: 125°C

Ed, we are all a little envious of your obvious ability but could suggest you may have to improvise via the use of a finger and if it is real hot use a finger nail. This will give you about 15 seconds before it will really cause you any serious pain.

Best of luck..

Billy..

0

Share this post


Link to post
Share on other sites

Can you confirm this is better? Did USB client or host break after setting this back to the old .32 value?

Eduardo, how far are you with the porting? I'm about to start working on that myself.

Well, i have taken a look at the required things to do... Essentially, it is a matter of getting the 11.2.11 NV kernel, and then comparing the modified files between the .36 version we already have and the ones of the 11.2.11. I would not expect majors problems there. But, what i wouldn't try is to apply patches to the .36 kernel in the hope of bringing it to the 11.2.11 version. Too many conflicts if we try to follow that path.

I also have some experimental patches not released yet to try to enable LP0 mode (extreme power saving for tegra2) .. Will also try to port that.

Regards,

Eduardo

0

Share this post


Link to post
Share on other sites

Eduardo,

You're right, number one don't panic.

We need to unfortunate Devs that have suffered from the affliction to help us out here as my Vega just fine and the only real issue is the USB connection to my WinTel PC is not working which may be related to the same setting.

The speaker getting physically damaged is an outside chance but ALC5624 may have suffered a mishap. It could be the temperature sensor has not been set to shut down or the setting needs to be review and set to a lower option.

RN Channel Temp. Sensor Threshold Setting

001: 35°C 011: 65°C

101: 95°C 111: 125°C

Ed, we are all a little envious of your obvious ability but could suggest you may have to improvise via the use of a finger and if it is real hot use a finger nail. This will give you about 15 seconds before it will really cause you any serious pain.

Best of luck..

Billy..

I will use a finger ;) - the ALC codec is the square chip next to the HDMI port ... it is easy to check it -- Regarding the ALC internal temperature sensor... It is disabled right now. The original Realtek drivers didn't enable it, and every time i tried to enable the sensor, the ALC went and still goes into shutdown mode, even if it is absolutely cold. I really would like to try to enable it, but, seems something is missing in the documentation ... i should say i lost more than 5 days trying to enable it, without success. And i always got an overcurrent/overtemp when enabling it. I 'd guess it is the startup transient, but i was unable to enable the codec if leaving the overtemp/overcurrent enabled.. :(

0

Share this post


Link to post
Share on other sites

Can you confirm this is better? Did USB client or host break after setting this back to the old .32 value?

I can confirm it built and booted but I was testing something else at the time and did not really check it.

0

Share this post


Link to post
Share on other sites

Well, i have taken a look at the required things to do... Essentially, it is a matter of getting the 11.2.11 NV kernel, and then comparing the modified files between the .36 version we already have and the ones of the 11.2.11. I would not expect majors problems there. But, what i wouldn't try is to apply patches to the .36 kernel in the hope of bringing it to the 11.2.11 version. Too many conflicts if we try to follow that path.

I also have some experimental patches not released yet to try to enable LP0 mode (extreme power saving for tegra2) .. Will also try to port that.

Regards,

Eduardo

Ok, I tracked down some patches even this tree needs and I will try to port them. The problem is diffing against the current tree is a no-no. I will give it a shot and report back.

Did you get a shot to test the LP0 patch?

I can confirm it built and booted but I was testing something else at the time and did not really check it.

Thanks for the answer.

update: Eduardo, try to fix or improve something else. I am currently working on the kernel.

Edited by a_appleby
0

Share this post


Link to post
Share on other sites

I found this in 44 build thread and this suggests that is two problems.

Billy..

Yep - I took mine apart earlier - for me, the central part of the speaker (the ring) has separated from the surrounding material. Other than that, everything looks in good shape (it still smells horrible though).

For me, the speaker is lightly glued in or forced, they both came out relatively easily with a screwdriver - and it would be trivial to replace with the same part.

0

Share this post


Link to post
Share on other sites

Is it always the left speaker people have problems with ? Appears i may be a victim? of this too ... cant seem to hear any sound from Left on mine :) need to flash back to a diff rom to be 100% but looks like im one of the chosen :)

I have never had my volume up 100% on this either.. ach well .. tis but a scratch ...

EDIT: Yup .. stock rom too .. looks like my left is gone ....

Cass

Edited by Cass67
0

Share this post


Link to post
Share on other sites

For me, the speaker is lightly glued in or forced, they both came out relatively easily with a screwdriver - and it would be trivial to replace with the same part.

Any idea what that part is ?

0

Share this post


Link to post
Share on other sites

Ok, I tracked down some patches even this tree needs and I will try to port them. The problem is diffing against the current tree is a no-no. I will give it a shot and report back.

Did you get a shot to test the LP0 patch?

Thanks for the answer.

update: Eduardo, try to fix or improve something else. I am currently working on the kernel.

Hope you are luckier that i here... I did the port of the drivers to the 11.2.11... the kernel does not boot... The display is garbled. I have seen this problem before :( ... The last time i had this problem, i lost a lot of time trying to figure out the cause. Just reordering!!! the functions in shuttle-...c fixed the non booting. But, that didn[t make sense at all

Regarding the LP0 patch, it should work, but somehow, it does not ... the same problems we still have with reboots... The tegra does not reboot, but it should.... Ahhh... seems this will take time :/

0

Share this post


Link to post
Share on other sites

Any idea what that part is ?

Cass,

The Dixons Stores Group have a spares devision (www.partmaster.co.uk). I'll give them a call on Monday to see what availability is like.

I'll also ask around to see if they the same or very similar to any laptop internal sets.

Billy..

0

Share this post


Link to post
Share on other sites

cant seem to hear any sound from Left on mine

EDIT: Yup .. stock rom too .. looks like my left is gone ....

Cass,

Out of interest, have you tried using headphones ? If you do does the left work fine ?

Billy..

0

Share this post


Link to post
Share on other sites

Cass,

Out of interest, have you tried using headphones ? If you do does the left work fine ?

Billy..

Yeah headphones work perfect... Keep us posted on the partmaster lead..

Also on another note, took mine apart today to have a look.. seems like a small tear on the speaker, covering with surgical tape like Rebel suggested earlier failed to fix for me.. mine is gone...

Cheers

Cass

Edited by Cass67
0

Share this post


Link to post
Share on other sites

Trying to get these changes working on 2.6.38-chromeos to use the LDK, but not having much joy. Every toolchain I try with ejtagle's files, even the Android NDK with GCC 4.4.0 gives garbled output on the screen.

Any suggestions as to what I'm doing wrong?

Here's my 2.6.38 repo: https://github.com/H...h/2.6.38.3-vega

Compiles, but I haven't done the sound stuff properly and I've no idea whether it boots because nothing I compile works.

If I get 2.6.38 chromeos branch working kernel wise, with GPT support enabled, ChromiumOS Tegra2 images should work.

Edited by Hexxeh
0

Share this post


Link to post
Share on other sites

Trying to get these changes working on 2.6.38-chromeos to use the LDK, but not having much joy. Every toolchain I try with ejtagle's files, even the Android NDK with GCC 4.4.0 gives garbled output on the screen.

Any suggestions as to what I'm doing wrong?

Here's my 2.6.38 repo: https://github.com/H...h/2.6.38.3-vega

Compiles, but I haven't done the sound stuff properly and I've no idea whether it boots because nothing I compile works.

If I get 2.6.38 chromeos branch working kernel wise, with GPT support enabled, ChromiumOS Tegra2 images should work.

Garbled screen seems to be caused by something related to pinmux not properly configured. I have written a kernel module to peek at the right configuration used in .32 kernel. Stay tuned :) --- With the proper pinmux config, i expect the chromeos port to work :)

0

Share this post


Link to post
Share on other sites

Garbled screen seems to be caused by something related to pinmux not properly configured. I have written a kernel module to peek at the right configuration used in .32 kernel. Stay tuned :) --- With the proper pinmux config, i expect the chromeos port to work :)

Eduardo, I am now porting your changes to the 11.2.11 kernel. I've made all other required changes to the kernel.

We might fix some of the GPU memory issues with this kernel. It has some patches our kernel didn't have. It couldn't boot with them anyway.

Do you think changes to the pinmux will be required?

update:

The kernel is now up to date and it's building. Only the patches from rebel1's repository are left.

update 2:

Eduardo, it looks like I am getting the garbled screen with this kernel as well. It shows randomly coloured bars in the middle of the screen and white on the two big sides.

Edited by a_appleby
0

Share this post


Link to post
Share on other sites

What kernel is 11.2.11?

Also, even using ejtagle or rebel1's code unmodified, I get corrupted output. I believe it's related to my compiler, not the code itself.

I'm using GCC from android-ndk-r5c to compile.

Edited by Hexxeh
0

Share this post


Link to post
Share on other sites

Just a quick update to the overheating speaker issue. I have been using my Vega (unplugged from power and USB) for the last day, to browse the web, watch a lot of youtube videos in the youtube app, and also watch a couple of movies. It hasn't seemed overly hot to me at all, and speakers are still working perfectly.

My daughter has also been playing zoodles and watching YouTube, and no issues whatsoever.

So, unless my Vega is bombproof, I have to conclude that this issue is indeed linked to use when plugged in to the Power/USB. I can't confirm which one causes the issue (or maybe it requires both to be plugged in). So, I believe now that lowering the volume will NOT in fact help this issue, unless it's the combination of extra heat and the speakers being overworked. However, sound does still distort quite badly after about 60%, so it is still worth lowering the level in my opinion.

If anyone knows otherwise please let me know!

newbe5

Edited by newbe5
0

Share this post


Link to post
Share on other sites

What kernel is 11.2.11?

Also, even using ejtagle or rebel1's code unmodified, I get corrupted output. I believe it's related to my compiler, not the code itself.

I'm using GCC from android-ndk-r5c to compile.

Hexxeh, 11.2.11 is a tag in the nvidia git repo.

You can find it here: http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git;a=tag;h=1a227d0ecf6cad19a52044f9c984edf73cbf66c4

The right toolchain is version 4.4.0. It looks like the kernels are very picky about the compiler you use to build them. I suspect some parts of the code are removed at build time by gcc and that breaks the final kernel.

I don't know if this helps in any way, but I got the same result from rebel1's kernel after applying any of the patches I've mentioned in a previous post.

You patch something like the scheduler, the network code or the video memory allocation code and you get the bars in the middle of the screen. It's not making sense as it should either not boot at all or work normally.

Regarding the USB problem, it's very strange. Is that 2mA or 500mA supposed to be for Vega's USB as a guest or for Vega's USB as host?

0

Share this post


Link to post
Share on other sites

Eduardo, I am now porting your changes to the 11.2.11 kernel. I've made all other required changes to the kernel.

We might fix some of the GPU memory issues with this kernel. It has some patches our kernel didn't have. It couldn't boot with them anyway.

Do you think changes to the pinmux will be required?

update:

The kernel is now up to date and it's building. Only the patches from rebel1's repository are left.

update 2:

Eduardo, it looks like I am getting the garbled screen with this kernel as well. It shows randomly coloured bars in the middle of the screen and white on the two big sides.

I am pretty sure it has something to do with the pinmux code. I did a revealing experiment: I just commented out the pinmux setting code, and even if some devices do not initialize properly, the console is initialized and the screens shows the booting messages until a point when the booting process locks.

As you should know, it is impossible to extract the pinmux settings from the .32 kernel, as the pinmux is programmed using a closed source user daemon (nvrm_daemon, or something like that), and the debugfs in .32 is not reading the actual pinmux settings: Instead it is displaying the initialization tables for pinmux before the nvrm_daemon modifies the settings.

The only way around this is to write a module for the .32 kernel that actually reads the pinmux settings from the hw registers and dumps them to the user. I have just done that ... So, give me a bit of time,and ill post what i find out, and the .32 kernel module written for that purpose... So we can all play with it :D

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2016. MoDaCo uses IntelliTxt technology.