Advent Vega kernel source code now available!

[Guest a_appleby]

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

That's very good news! I am glad I suggested I port the patches while you work on something else. ;)

Once again, great work! I am looking forward to putting this to work.

[Guest winnipeg]

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

Don’t know if this is of use:

https://patchwork.kernel.org/patch/972832/

Sorry for post in this thread.

Thank you.

[Guest ejtagle]

Don’t know if this is of use:

https://patchwork.kernel.org/patch/972832/

Sorry for post in this thread.

Thank you.

I doubt this specific patch would help with vega, but it is a clear example of the extreme importance that having the right pinmux configurations is.

I've been working trying to get the right pinmux configurations. After losing lots of time trying to guess the correct configuration, i decided to do what i should have done a lot of time ago: I wrote a module for the .32 kernel that is able to read the configuration of the tegra chip (pinmux, pinmux drive, memory controller and clocks). It reads it directly from the hardware registers of tegra at the time of read of the proc filesystem entries, so it is able to get the exact required configuration for a given system. With that information, it should be extremely easy to write the required tables for the .36+ kernel.

The module reads the configuration from the hw in realtime, and creates nicely formatted tables, so, i suggest to try to read the configuration when all peripherals are active... sound, 3d graphics, bluetooth, network, camera, usb... the more active the system, the better, otherwise the nvrm_daemon will not configure properly all the pinmuxes or clocks..

I ran out of time again. I have attached the source of the config peek module for the .32 kernel... i also attached the configurations read from my POV mobii tegra2, and i also attached my attempt of porting all of those tables to the 11.2.11.. though, i haven-t tried to compile it yet. The files simply apply over the latest 11.2.11 release of the nvidia kernel for tegra, i have compiled it , but not with the new tables...

Well, tomorrow i will try to test this

Eduardo

config-peek-32.rar

[Guest ejtagle]

... it has been a nightmare to upload this file... the flash uploader fails with error403... and the default uploader asks for a captcha in a window so small, that it is nearly impossible to read... :(

patch-11.2.11.zip

[Guest a_appleby]

... it has been a nightmare to upload this file... the flash uploader fails with error403... and the default uploader asks for a captcha in a window so small, that it is nearly impossible to read... :(

Eduardo, I'm building it now. There were two missing commas in board-shuttle-clocks.c which were stopping the compilation process.

I am about to try it out now.

[Guest BillyBobJoe]

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?

This setting is for when the Vega (P10AN01) is acting as a device, not a host. So would drawing from the PC which would account for the hot USB cable and/or the extra hot parts of the board as it is not expecting this much power.

For some items this is a great setting as they will use the USB power to charge but the tablets don't may be wise to level this at the 2mA setting just to keep the poor little things from getting overheated.

Billy..

Not sure if any of the internal devices have had their individual settings, if they have any, changed to a higher value?

[Guest a_appleby]

This setting is for when the Vega (P10AN01) is acting as a device, not a host. So would drawing from the PC which would account for the hot USB cable and/or the extra hot parts of the board as it is not expecting this much power.

For some items this is a great setting as they will use the USB power to charge but the tablets don't may be wise to level this at the 2mA setting just to keep the poor little things from getting overheated.

Billy..

Not sure if any of the internal devices have had their individual settings, if they have any, changed to a higher value?

It should be ok to have it set at 2mA then.

Eduardo, I have tried your patch and I get a garbled screen. However, your patches give me a garbled screen which is different from the one I obtain. It shows bars across the entire screen, from the top to the bottom of the screen. Something's still not right.

I obtained a garbled screen which had bars in the middle and two large white areas on the sides with the kernel I patched. This is also what I get with the rebel1 kernel if I add any patches.

I am not sure which of the two is closer to working.

[Guest ejtagle]

It should be ok to have it set at 2mA then.

Eduardo, I have tried your patch and I get a garbled screen. However, your patches give me a garbled screen which is different from the one I obtain. It shows bars across the entire screen, from the top to the bottom of the screen. Something's still not right.

I obtained a garbled screen which had bars in the middle and two large white areas on the sides with the kernel I patched. This is also what I get with the rebel1 kernel if I add any patches.

I am not sure which of the two is closer to working.

Well, the configuration used is exactly the one being used in the vega by the .32 kernel. Guess we will have to go incrementally from the .36 booting kernel to the 11.2.11 kernel .... There is not too much to test... If you comment out the pinmux drive table contents, did you at least get the console ? -- I do get the framebuffer console up and running for a few seconds... I will continue investigation ... There is something different in the initialization of the .32 versus .36 kernel, but i am failing to get what it is :(

[Guest CoWPlagued]

Thought I'd add my ramblings to the mix.

We seem to have two issues here, which may be in some way connected, or could be completely different.

The USB power requirements -

500mw is the standard limit per usb socket for most controllers. operating as a slave I doubt the vega requires any power at all as it's already powered all it's circuitry and doesn't support usb charging, so where as other devices might allow large currents over 500ma for fast charging, the vega will only need to take in enough power to indicate a change in capacitance and notify the host of connection. It's entirely possibly that the circuit that is enabled to initiate the usb when in slave mode is little more than a resistor or diode, and allowing any power at all through the circuit will overload the basic components, but you'd have thought there'd be some protection from this???

The Speaker issue is a little different, a tearing cone or burned out winding is clearly too much power going to the speaker unit. The ALC5624 has two circuits for the speaker and headphone drivers potentially operating at different voltages (although they do both have an overlap voltage of 3-3.6v, and a nominal voltage of 3.3v is usually used) . I'm not sure if the Vega has a secondary amp but the 1.7W on chip speaker driver, should be plenty. So unless the speakers really are crap, It's odd that the chip should even be able to output enough power to do damage .....

I've had a quick, and I do mean quick skim of the data sheet, so forgive me if this is completely wrong ot unrelated ... but

If the chip was set to the wrong mode Class AD/Class D would this would effect the load to the speakers and, I guess, overload the chip a bit? like adding the wrong impedance speakers to an amp. I'm no speaker/audio expert but doesn't the speaker class also effect things like what state the speaker/amp is in with no signal, so possibly overloading it even if the sound is muted???

I'd be interested to see if swapping the speakers over shows the channel with the damaged speaker to work again, as the headphones run on a different driver this wouldn't show if the internal speaker driver had blown a channel.

[Guest a_appleby]

Well, the configuration used is exactly the one being used in the vega by the .32 kernel. Guess we will have to go incrementally from the .36 booting kernel to the 11.2.11 kernel .... There is not too much to test... If you comment out the pinmux drive table contents, did you at least get the console ? -- I do get the framebuffer console up and running for a few seconds... I will continue investigation ... There is something different in the initialization of the .32 versus .36 kernel, but i am failing to get what it is :(

We can't go incrementally from the working kernel to the 11.2.11 kernel as I have tried that myself, some patches fail and some patches simply result in garbled output on the screen. Our kernel was an older version of 11.2.x and then got updated to 11.2.4.

The kernel we have hasn't got all the patches which were added to the nvidia repo up to 11.2.4. Some patches haven't been merged as there were changes made to the source and they failed to apply.

It doesn't seem like it's so easy to find what broke it. Perhaps we should use git bisect between 11.2.4 and 11.2.11?

What's so special about the 11.2.4+ we have? It easily gets broken by any patch from the repository.

Thought I'd add my ramblings to the mix.

We seem to have two issues here, which may be in some way connected, or could be completely different.

The USB power requirements -

500mw is the standard limit per usb socket for most controllers. operating as a slave I doubt the vega requires any power at all as it's already powered all it's circuitry and doesn't support usb charging, so where as other devices might allow large currents over 500ma for fast charging, the vega will only need to take in enough power to indicate a change in capacitance and notify the host of connection. It's entirely possibly that the circuit that is enabled to initiate the usb when in slave mode is little more than a resistor or diode, and allowing any power at all through the circuit will overload the basic components, but you'd have thought there'd be some protection from this???

The Speaker issue is a little different, a tearing cone or burned out winding is clearly too much power going to the speaker unit. The ALC5624 has two circuits for the speaker and headphone drivers potentially operating at different voltages (although they do both have an overlap voltage of 3-3.6v, and a nominal voltage of 3.3v is usually used) . I'm not sure if the Vega has a secondary amp but the 1.7W on chip speaker driver, should be plenty. So unless the speakers really are crap, It's odd that the chip should even be able to output enough power to do damage .....

I've had a quick, and I do mean quick skim of the data sheet, so forgive me if this is completely wrong ot unrelated ... but

If the chip was set to the wrong mode Class AD/Class D would this would effect the load to the speakers and, I guess, overload the chip a bit? like adding the wrong impedance speakers to an amp. I'm no speaker/audio expert but doesn't the speaker class also effect things like what state the speaker/amp is in with no signal, so possibly overloading it even if the sound is muted???

I'd be interested to see if swapping the speakers over shows the channel with the damaged speaker to work again, as the headphones run on a different driver this wouldn't show if the internal speaker driver had blown a channel.

Speaker coils can also melt if you drive a continuous current (DC) through them instead of AC.

[Guest ejtagle]

...

The Speaker issue is a little different, a tearing cone or burned out winding is clearly too much power going to the speaker unit. The ALC5624 has two circuits for the speaker and headphone drivers potentially operating at different voltages (although they do both have an overlap voltage of 3-3.6v, and a nominal voltage of 3.3v is usually used) . I'm not sure if the Vega has a secondary amp but the 1.7W on chip speaker driver, should be plenty. So unless the speakers really are crap, It's odd that the chip should even be able to output enough power to do damage .....

I've had a quick, and I do mean quick skim of the data sheet, so forgive me if this is completely wrong ot unrelated ... but

If the chip was set to the wrong mode Class AD/Class D would this would effect the load to the speakers and, I guess, overload the chip a bit? like adding the wrong impedance speakers to an amp. I'm no speaker/audio expert but doesn't the speaker class also effect things like what state the speaker/amp is in with no signal, so possibly overloading it even if the sound is muted???

I'd be interested to see if swapping the speakers over shows the channel with the damaged speaker to work again, as the headphones run on a different driver this wouldn't show if the internal speaker driver had blown a channel.

No external amplifiers. They use jut the ALC main amplifier for the speakers (1Wrms per channel) and the auxiliary amplifier for the headphones. I will try to measure if DC is present across the speaker coils.. I had no time until now... Busy writing the config-peek module for the .32 kernel.

[Guest brucelee666]

I know your looking into other things but regarding the reboot problem

Have you seen this or tried updating the file mentioned

restore voltage to nominal when reboot patch on 11.2.11 commit

[Guest ejtagle]

I know your looking into other things but regarding the reboot problem

Have you seen this or tried updating the file mentioned

restore voltage to nominal when reboot patch on 11.2.11 commit

Well, if we succeed to boot he 11.2.11 nvidia tegra2 kernel, we will get this patch already applied. But, until now, it refuses to boot. Will try to find out why. The reboot failure problably is caused by the same problem that is making LP0 (super low power) suspend not to work ... I will continue investigation

[Guest ejtagle]

We can't go incrementally from the working kernel to the 11.2.11 kernel as I have tried that myself, some patches fail and some patches simply result in garbled output on the screen. Our kernel was an older version of 11.2.x and then got updated to 11.2.4.

The kernel we have hasn't got all the patches which were added to the nvidia repo up to 11.2.4. Some patches haven't been merged as there were changes made to the source and they failed to apply.

It doesn't seem like it's so easy to find what broke it. Perhaps we should use git bisect between 11.2.4 and 11.2.11?

What's so special about the 11.2.4+ we have? It easily gets broken by any patch from the repository.

...

two approaches would be great to try:

1) , get the original 11.2.4 and port the vega drivers to it (should require nearly no change at all) ... to make sure that the unmodified 11.2.4 boots as the booting .36 kernel we have... If it does not boot, we could do a diff between the booting .36 and the 11.2.4 to know exactly what has beeen changed.

2) If the unmodified 11.2.4 with added vega support works, then we can do the git bisect...

Either or it is something very silly, or something very severe (such as a gcc bug triggered by some specific sequence of code :( )

Eduardo

[Guest Cass67]

look into bma150.c, for

ctx->input->name = "bma150"

Instead of "bma150", it should be "accelerometer_tegra" if you want sensors.tegra.so to recognize the accelerometer automatically ..

Or edit the library replacing "accelerometer_tegra" by "bma150" . Be creful there, as there is a "tegra_accelerometer" that must NOT be changed!

Hi Eduardo,

Thanks for the info the other day, seems Android detects the sensor now .. However it still does not work, and after a pile of looking and playing im not sure if its a kernel issue, we are not initializing something or if we have an Android issue that's maybe hard to resolve without source ..

http://pastebin.com/7V24zFKv

Ive tried as many combinations of libs from transformer to iconia builds and i fail ....

Any ideas looking at this if this could be a kernel issue still ?

Im struggling to find anything on the last vendor messages from the paste...

EDIT:- Should also add, Android app AndroSensor detects the sensors now, accel, gyro ,magnetic field and orientation but just is not able to receive events .. so we are advanced a bit from the other day..

Cheers

Cass

Edited August 9, 2011 by Cass67

[Guest ejtagle]

two approaches would be great to try:

1) , get the original 11.2.4 and port the vega drivers to it (should require nearly no change at all) ... to make sure that the unmodified 11.2.4 boots as the booting .36 kernel we have... If it does not boot, we could do a diff between the booting .36 and the 11.2.4 to know exactly what has beeen changed.

2) If the unmodified 11.2.4 with added vega support works, then we can do the git bisect...

Either or it is something very silly, or something very severe (such as a gcc bug triggered by some specific sequence of code :( )

Eduardo

UPDATE!: Very good news! -- Now i finally realized what was the cause preventing the 11.2.11 kernel from booting (thanks video camera! - I had to do a video recording of the framebuffer while it was displaying the boot messages... And the last line was "... disabling unneeded voltage regulators left on by bootloader..." ... I may say... inspiring phrase... I decided to leave the regulators that the bootloader enables, enabled. And that was all that was required.

The 11.2.11 kernel boots, and as a curiosity, the reboot process also started to work :)

I still have to investigate if LP0 suspend is working or not. I left it disabled by now, but, you can try it. Just comment the line

tegra_lp0_vec_start = tegra_lp0_vec_size = 0;

in board-shuttle.c so the kernel command line parser passes the LP0 vector found to the kernel itself. Maybe the LP0 is also working :D

Attached the updated files with the proper tables for the voltage regulators. You should get the 11.2.11 nvidia kernel and just overwrite with the supplied files and compile!

Well, hope we are much closer ... still, we have to investigate the ultra-loud speaker volume issue ...

Regards,

Eduardo

patch-11.2.11-working.rar

[Guest a_appleby]

UPDATE!: Very good news! -- Now i finally realized what was the cause preventing the 11.2.11 kernel from booting (thanks video camera! - I had to do a video recording of the framebuffer while it was displaying the boot messages... And the last line was "... disabling unneeded voltage regulators left on by bootloader..." ... I may say... inspiring phrase... I decided to leave the regulators that the bootloader enables, enabled. And that was all that was required.

The 11.2.11 kernel boots, and as a curiosity, the reboot process also started to work :)

I still have to investigate if LP0 suspend is working or not. I left it disabled by now, but, you can try it. Just comment the line

tegra_lp0_vec_start = tegra_lp0_vec_size = 0;

in board-shuttle.c so the kernel command line parser passes the LP0 vector found to the kernel itself. Maybe the LP0 is also working :D

Attached the updated files with the proper tables for the voltage regulators. You should get the 11.2.11 nvidia kernel and just overwrite with the supplied files and compile!

Well, hope we are much closer ... still, we have to investigate the ultra-loud speaker volume issue ...

Regards,

Eduardo

I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.

The kernel was also unable to set the pclk.

[Guest BillyBobJoe]

Hey Ed and everybody,

Couldn't get to sleep last night so started to read the ALC5624 data sheet from Realtek, I haven't finished so don't spoil the ending I'm guessing the butler did it.

After looking at the data sheet and Eduardo's driver have come to the belief that we just need to change one line:

static struct alc5624_platform_data alc5624_pdata = {

#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,36)

.mclk = "clk_dev1",

#else

.mclk = "cdev1",

#endif

.spkvdd_mv = 5000, /* Speaker Vdd in millivolts */

.hpvdd_mv = 3300, /* Headphone Vdd in millivolts */

};

"Recommended Operating Conditions

Parameter Symbol Min Typ Max Units

Analog AVDD1, AVDD2 2.3 3.3 3.6 V

Headphone HPVDD 2.3 3.3 3.6 V

Speaker SPKVDD1 2.3 3.3 5 V

Note 1: A 10μF Capacitor must be connected from SPKVDD to SPKGND, and should be placed as close as possible to

the SPKVDD pin of the ALC5624.

"

If we change the SPKVdd to 3.3V rather than the 5V as the spec says that this could spike to 8V and still be within normal working range.

Now with the couple of quick changes to the kernel config we should be looking good. If someone else has any suggestions feel free to let me know.

My earlier question regards the headphones was to see if there was a shared 10uF capacitor or if there used a separate one for each output. My concern was that the chip had been damaged but it is very had to tell without actually having a broken one to play with.

I am hoping that the speakers are so bad that they break first.

Billy..

Edited August 9, 2011 by BillyBobJoe

[Guest rebel1]

I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.

The kernel was also unable to set the pclk.

Hi,

i can confirm, that we have some problems with the clocks.

<4>[	7.031900] Unable to set parent sclk of clock avp.sclk: -38

<4>[	7.033274] Unable to initialize clock pll_e

<4>[	7.033768] Unable to set clock clk_dev1 to rate 11289600: -38

<4>[	7.033792] Unable to set clock clk_dev2 to rate 24000000: -38

<4>[	7.033908] Unable to set clock dsi to rate 1000000: -22

<4>[	7.034026] Unable to find parent clk_p of clock sdmmc2

.....

<6>[	8.035063] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

<3>[	8.035219] Failed to set 1 : 2 pclk divider

<3>[	8.072209] ulpi_phy_power_on: timeout waiting for phy clock to                                               	start

<3>[	8.077982] ulpi_phy_power_on: ulpi write failed

<3>[	8.078008] tegra-ehci tegra-ehci.1: Failed to power on the phy

<4>[	8.078074] tegra-ehci: probe of tegra-ehci.1 failed with error -110

<3>[	8.078181] Failed to set 1 : 2 pclk divider

....

<3>[	8.129385] Failed to set 1 : 2 pclk divider

<3>[	8.129419] Failed to set 1 : 2 pclk divider

....

<3>[   31.321780] tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Full paste

[Guest ejtagle]

I tried it out. It keeps dying in init with an init: untracked pid 93 exited error. It keeps doing this forever.

The kernel was also unable to set the pclk.

... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..

The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?

Hey Ed and everybody,

Couldn't get to sleep last night so started to read the ALC5624 data sheet from Realtek, I haven't finished so don't spoil the ending I'm guessing the butler did it.

After looking at the data sheet and Eduardo's driver have come to the belief that we just need to change one line:

static struct alc5624_platform_data alc5624_pdata = {

#if LINUX_VERSION_CODE == KERNEL_VERSION(2,6,36)

.mclk = "clk_dev1",

#else

.mclk = "cdev1",

#endif

.spkvdd_mv = 5000, /* Speaker Vdd in millivolts */

.hpvdd_mv = 3300, /* Headphone Vdd in millivolts */

};

"Recommended Operating Conditions

Parameter Symbol Min Typ Max Units

Analog AVDD1, AVDD2 2.3 3.3 3.6 V

Headphone HPVDD 2.3 3.3 3.6 V

Speaker SPKVDD1 2.3 3.3 5 V

Note 1: A 10μF Capacitor must be connected from SPKVDD to SPKGND, and should be placed as close as possible to

the SPKVDD pin of the ALC5624.

"

If we change the SPKVdd to 3.3V rather than the 5V as the spec says that this could spike to 8V and still be within normal working range.

Now with the couple of quick changes to the kernel config we should be looking good. If someone else has any suggestions feel free to let me know.

My earlier question regards the headphones was to see if there was a shared 10uF capacitor or if there used a separate one for each output. My concern was that the chip had been damaged but it is very had to tell without actually having a broken one to play with.

I am hoping that the speakers are so bad that they break first.

Billy..

.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v

The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...

Hi,

i can confirm, that we have some problems with the clocks.

<4>[	7.031900] Unable to set parent sclk of clock avp.sclk: -38

<4>[	7.033274] Unable to initialize clock pll_e

<4>[	7.033768] Unable to set clock clk_dev1 to rate 11289600: -38

<4>[	7.033792] Unable to set clock clk_dev2 to rate 24000000: -38

<4>[	7.033908] Unable to set clock dsi to rate 1000000: -22

<4>[	7.034026] Unable to find parent clk_p of clock sdmmc2

.....

<6>[	8.035063] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

<3>[	8.035219] Failed to set 1 : 2 pclk divider

<3>[	8.072209] ulpi_phy_power_on: timeout waiting for phy clock to                                   				start

<3>[	8.077982] ulpi_phy_power_on: ulpi write failed

<3>[	8.078008] tegra-ehci tegra-ehci.1: Failed to power on the phy

<4>[	8.078074] tegra-ehci: probe of tegra-ehci.1 failed with error -110

<3>[	8.078181] Failed to set 1 : 2 pclk divider

....

<3>[	8.129385] Failed to set 1 : 2 pclk divider

<3>[	8.129419] Failed to set 1 : 2 pclk divider

....

<3>[   31.321780] tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Full paste

You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.

All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)

Edited August 9, 2011 by ejtagle

[Guest newbe5]

... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..

The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?

.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v

The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...

You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.

All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)

Are you placing the overheating speaker issue in the "not big problems" pot? Do you think you have a cast iron solution for this? I apologise but I am a little out of the loop right now. My wife is in hospital and I do not have much time to work on Android unfortunately.

newbe5

[Guest rebel1]

... but the kernel itself boots. There is no hardware lockup. I can confirm that using busybox as the shell, you are able to reach a console, issue commands, etc,etc..

The message you are getting is output by the init process (in userspace)... seems it is trying to launch another process at init time, and that process is dying unexpectly... Now, we should try to find out the process itself. Perhaps some android component depends on an specific version of the kernel ?

.. i have still to measure things, but.. there are separate physical outputs for headphones and for speakers. Speakers do not need a capacitor in series (though it shoudn't hurt. I have to measure if there is a capacitor or not in series with speakers) .. The ALC has 2 separate amplifiers. The headphone one is just very standard. Just 2 outputs (left and right), Low power... And uses HPVDD as its power supply. On the Vega, the HPVDD pin of the ALC is tied to +3v

The speaker amplifier has 4 outputs (two for each channel, and can be used as in a half bridge configuration (just connecting , for each channel, left, and right. one of the amplifier outputs through a capacitor to one of the speaker terminat, and the other speaker terminal to ground, or it can be used as a full bridge amplifier, coneecting one terminal of the speaker to one of the terminals of the amplifier, and the other terminal to the other terminal of the same channel amplifier. In tis way, you can reach 1Wrms per speaker. This amplifier uses SPKVDD as power supply, and in the vega, it is tied to +5v.

I have still to measure out the exact connections being used in vega to connect the speakers... This is probably the next task i will do...

You are right... there are still clock issues. The tegra2 clock table should be right as it is right now (it was dumped from a running .32 kernel), but the .36 kernel still does not support some of those combinations. I will take a look to see if they are important or not... But, as i said before, the problems we are having right now are not caused by a non-booting kernel, rather than, they are caused by some android component (probably a daemon that refuses to load at init time) that does not like the new kernel... or perhaps a kernel config issue...

Will continue investigation. Just take into account that my testing platform is busybox, not android at this time ;) (i have to isolate the problems.. either they are kernel related, or android related. Using android to try the kernel does not allow me to separate causes :) )

On a second look, seems the new clock table configuration (extracted from the .32 kernel) that we are now using, is not completely supported by the .36 kernel. So, audio seems not to be initializing properly (i found out by looking at your latest log). As a workaround, you can use an older board-shuttle-clocks.c ... The one we used for the booting .36 kernel. That config was supported by the kernel. Later, i will take a look to either add the missing support for this (.32) clock config to the 11.2.11, or to just revert to the previous clock table (i have no reason to believe the older clock table is worse than current one, quite in fact, i do suspect it is better :) ) ... And the bug of the tps6586x-rtc.. seems someone is trying to set an invalid date :S ... Quite strange thing! - Didn't happebn to me. Will take also a look later.

All the problems we have right now, trust me, they are not big problems at all. What i was mostly worried about was on hardware lookups. But this is not the case right now :) -- All the other things are relatively easy to fix - mostly minor configuration adjustments ... with no guessing involved :)

Hi,

it seems that i have forget to say, that i have tested the "older" clock configuration, too.

But unfortunately:

<4>[	5.413082] Unable to set clock hclk to rate 108000000: -22

<4>[	5.413110] Unable to set clock pclk to rate 54000000: -22

<4>[	5.414597] Unable to set clock clk_dev1 to rate 11289600: -38

<4>[	5.414616] Unable to set clock clk_dev2 to rate 26000000: -38

<4>[	5.414709] Unable to set clock dsi to rate 5000000: -22

Full Log

[Guest ejtagle]

Are you placing the overheating speaker issue in the "not big problems" pot? Do you think you have a cast iron solution for this? I apologise but I am a little out of the loop right now. My wife is in hospital and I do not have much time to work on Android unfortunately.

newbe5

Yes, i do not consider that problem as a big problem. Don't take it wrong: The problem is really important, but the solution should not be hard. From all that i have read and heard, seems to be just caused by programming the ALC to a higher volume that was possible with the .32 kernel (probably limited on purpose in the .32 kernel, but there is no way to check that,as the software component responsible of setting the volume in .32 is a closed source daemon called nvrm_daemon.

But, i do recall that the new .36 kernel sound output is much louder than the .32 kernel. And much louder means very much higher power output to the speakers (remember, humans are sensible to the logrithm of real power, so an apparent perceived increase of sound pressure level (=volume) of 3 times, means more than 10 times the original power to the speakers. I cause i will take care of this - Don't worry. It is on my list :)

[Guest ejtagle]

Hi,it seems that i have forget to say, that i have tested the "older" clock configuration, too.But unfortunately:

<4>[	5.413082] Unable to set clock hclk to rate 108000000: -22<4>[	5.413110] Unable to set clock pclk to rate 54000000: -22<4>[	5.414597] Unable to set clock clk_dev1 to rate 11289600: -38<4>[	5.414616] Unable to set clock clk_dev2 to rate 26000000: -38<4>[	5.414709] Unable to set clock dsi to rate 5000000: -22

Full Log

Yes, this is also in my todo list. This is more a limitation of the .36 kernel than a real problem.. But, just to be sure, i will take a look :)

UPDATE: I just looked at your log: One line calls my attention:

tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Please, do me a favor. Use the old board-shuttle-clocks.c for the booting kernel, and also change the following line in board-shuttle-pinmux.c:

in the line:

{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ...

Change

TEGRA_MUX_OSC to TEGRA_MUX_PLLA_OUT

The .36 kernel requires TEGRA_PINGROUP_CDEV1 to output TEGRA_MUX_PLLA_OUT . otherwise, audio stops working. The previous .32 kernel seems not to require it. You should get no ALSA related errors with those modifications

Edited August 9, 2011 by ejtagle

[Guest a_appleby]

Yes, this is also in my todo list. This is more a limitation of the .36 kernel than a real problem.. But, just to be sure, i will take a look :)

UPDATE: I just looked at your log: One line calls my attention:

tegra_hifi_hw_params(): unable to get required 44100 hz sampling rate of 12000000 hz SYSCLK

Please, do me a favor. Use the old board-shuttle-clocks.c for the booting kernel, and also change the following line in board-shuttle-pinmux.c:

in the line:

{TEGRA_PINGROUP_CDEV1, TEGRA_MUX_OSC, ...

Change

TEGRA_MUX_OSC to TEGRA_MUX_PLLA_OUT

The .36 kernel requires TEGRA_PINGROUP_CDEV1 to output TEGRA_MUX_PLLA_OUT . otherwise, audio stops working. The previous .32 kernel seems not to require it. You should get no ALSA related errors with those modifications

I have tried, as you recommended, to build a kernel with the old working board-shuttle-clocks.c and the change you said we should make. I've changed TEGRA_MUX_OSC at line 35 of board-shuttle-pinmux.c to TEGRA_MUX_PLLA_OUT.

I couldn't get an adb connection with that setup, the usb device was registering for 0.5-1 seconds and was going away.

Edited August 9, 2011 by a_appleby