Advent Vega kernel source code now available!

[Guest Cass67]

Well, attached the next patch to the kernel, that should solve most issues:

1) SDHCI host fixed. Now we are able to mount the SD card without trouble

2) NAND driver fixed. Now it actually uses the timing information for the NAND chips on Shuttle

3) Several power management functions updated to the latest framework

4) Added back the missing IOCTRLs to the framebuffer driver that Nvidia removed from 2.6.36 to 2.6.39... This should make gralloc and openGl acceleration work

5) Fixed clock settings (some clock names changed from 2.6.36 to 2.6.39) on several components

6) Fixed some pin mux entries that required adjustment to work in the 2.6.39 kernel

7) Probably some other things i am forgetting right now...

8) Adjusted audio components, they are now properly recognized, but still crash the kernel while trying to reproduce audio. I still have to figure out where is the problem...

Well, except audio, everything else should be working just fine.

Regards,

Eduardo

Boots further, right up to unlock screen then hangs, i get kicked from adb and TS does not work ... ill try to get a log of the hang/crash ... The logcat im viewing on boot does not really show anything ....

Nearly there :)

EDIT :- ahh only hangs when the TS is touched .... without touching it the tab stays up ... ill try to see why

Edit2:- http://pastebin.com/8BCZkXtc << does not really show anything and last_kmesg is not in this kernel it seems .. i need to figure how to add unless you have other ideas ..

Edit3:- Not sure if its my code fixes in the atheros drivers(probably) or the kernel is not ok for wifi device yet but i can compile the module now and insmod it but i get no more out of the thing other than

<4>[ 140.102808] Normal WIFI mode.

#lsmod

ar6000 217748 0 - Live 0xbf045000

all i did to fix the compile errors on atheros was add

#include <linux/shed.c>

in a few complaining files .. Not sure if this is correct ....was not needed on previous kernels so i am a bit suspicious of this "fix" :)

Cheers

Cass

Edited December 2, 2011 by Cass67

[Guest ejtagle]

Boots further, right up to unlock screen then hangs, i get kicked from adb and TS does not work ... ill try to get a log of the hang/crash ... The logcat im viewing on boot does not really show anything ....

Nearly there :)

EDIT :- ahh only hangs when the TS is touched .... without touching it the tab stays up ... ill try to see why

Edit2:- http://pastebin.com/8BCZkXtc << does not really show anything and last_kmesg is not in this kernel it seems .. i need to figure how to add unless you have other ideas ..

Edit3:- Not sure if its my code fixes in the atheros drivers(probably) or the kernel is not ok for wifi device yet but i can compile the module now and insmod it but i get no more out of the thing other than

<4>[ 140.102808] Normal WIFI mode.

#lsmod

ar6000 217748 0 - Live 0xbf045000

all i did to fix the compile errors on atheros was add

#include <linux/shed.c>

in a few complaining files .. Not sure if this is correct ....was not needed on previous kernels so i am a bit suspicious of this "fix" :)

Cheers

Cass

Normal WIFI mode.

I had this problem before... The driver loads, but in fact, is not being initialized .... I will try to remember what i did to fix it ;) -- Was something very silly, but i can't remember what i did...

last_kmsg

There is a feature called RAM console, or something similar... The idea is to keep the last log in RAM between boots .. I will add support for that. It is very simple to add support, and i think it will help here ;)

.. crash ...

Perhaps the crash is caused by the system trying to initialize audio when you touch the screen ... Or perhaps, something related to the touchscreen ... There is a bug in the kernel audio subsystem (more precisely, it is in tegra_alc5624.c,, function tegra_hifi_hw_params. There is a NULL reference pointer access violation there... I still have to find the cause (probably, a silly thing, but i still have to figure out the cause) ... And i will also take a look at the android event collector, to see the real touchscreen requirements ...

Edited December 2, 2011 by ejtagle

[Guest Cass67]

Perhaps the crash is caused by the system trying to initialize audio when you touch the screen ...

Dont think its related to this kernel bug, i just removed SND support from the kernel and its the same issue ... Unless android is demanding it and hanging, does not seem likely to me .. id have thought android would spin on boot rather than get this far...

Edit - Ram console -

Support for ram console appears to be there ... just need the /proc entry, that part appears not to be getting done .. .. the entries are in .config for sure and the ramconsole.o is compiled. strange !!

Edited December 2, 2011 by Cass67

[Guest ejtagle]

Dont think its related to this kernel bug, i just removed SND support from the kernel and its the same issue ... Unless android is demanding it and hanging, does not seem likely to me .. id have thought android would spin on boot rather than get this far...

Edit - Ram console -

Support for ram console appears to be there ... just need the /proc entry, that part appears not to be getting done .. .. the entries are in .config for sure and the ramconsole.o is compiled. strange !!

I think that on the 2.6.39 kernel, we need to explicitly load the ram console (it is now a platform device). That entry is missing ... I have noticed that they load it explicitly on the other board-xxxx.c files for the natively supported boards. I think that just adding the same thing to our board-shuttle.c file would do the trick ;)

[Guest Cass67]

I think that on the 2.6.39 kernel, we need to explicitly load the ram console (it is now a platform device). That entry is missing ... I have noticed that they load it explicitly on the other board-xxxx.c files for the natively supported boards. I think that just adding the same thing to our board-shuttle.c file would do the trick ;)

Lets see shall we :)

[Guest ejtagle]

Lets see shall we :)

Something along this should work... I haven't tried to compile it, but it should register the RAM console ...

board-shuttle.rar

[Guest Cass67]

Something along this should work... I haven't tried to compile it, but it should register the RAM console ...

Cheers, works fine ... all i managed to do was hang the vega on flashing the kernel :) compiled fine but not bootable .. lol surprisingly ;)

Just have to try and force a warm reboot now after touching the screen as when it hangs and i power it off i lose last_kmsg... for some reason i managed to fix the earlier reboot after hang .. need to figure how ..

EDIT:- Ok, maybe something here as i seem to have got logs by hitting reboot and touching screen at same time, everything hung as usual and then after 30 secs or so it reboot ..

http://pastebin.com/AM7KSB7A

Maybe from line 464 is interesting... Although the crash begins 80+ lines before

Edited December 2, 2011 by Cass67

[Guest ejtagle]

Cheers, works fine ... all i managed to do was hang the vega on flashing the kernel :) compiled fine but not bootable .. lol surprisingly ;)

Just have to try and force a warm reboot now after touching the screen as when it hangs and i power it off i lose last_kmsg... for some reason i managed to fix the earlier reboot after hang .. need to figure how ..

EDIT:- Ok, maybe something here as i seem to have got logs by hitting reboot and touching screen at same time, everything hung as usual and then after 30 secs or so it reboot ..

http://pastebin.com/AM7KSB7A

Maybe from line 464 is interesting... Although the crash begins 80+ lines before

Interesting... seems to be a bug in the evdev subsystem... I will check it, as i did some mods to allow suspension even if the accelerometer was working...

[Guest ejtagle]

Interesting... seems to be a bug in the evdev subsystem... I will check it, as i did some mods to allow suspension even if the accelerometer was working...

Sorry about this. While doing the merging between the 2.6.36 and 2.6.39 sources, i missed a bit. Attached the evdev.c that should fix the crash :)

PD: Reboot time can be configured in the .config file ;)

evdev.rar

Edited December 2, 2011 by ejtagle

[Guest Cass67]

Sorry about this. While doing the merging between the 2.6.36 and 2.6.39 sources, i missed a bit. Attached the evdev.c that should fix the crash :)

PD: Reboot time can be configured in the .config file ;)

Hey no probs apologies not needed, I learn a thing or two along the way.. Ill try this when I get home in a bit. :)

EDIT:- Yep that fixed it .. TS now works .. nice one .... Now i guess to look to hwcomposer/gralloc or other nvlibs to try and resolve the green overlay issue ... there must be a combo somewhere that works ...

Cheers

Edited December 2, 2011 by Cass67

[Guest ejtagle]

Hey no probs apologies not needed, I learn a thing or two along the way.. Ill try this when I get home in a bit. :)

EDIT:- Yep that fixed it .. TS now works .. nice one .... Now i guess to look to hwcomposer/gralloc or other nvlibs to try and resolve the green overlay issue ... there must be a combo somewhere that works ...

Cheers

The green overlay issue reminds me of something.. When dealing with YUV colorspaces, if you just set the Y component, but not the U or V components, you get a green overlay ... HC worked fine with the hwcomposer ... Perhaps the problem is ICS ... We have all the source code of the graphics subsystem ... I'd guess perhaps there is a bug somewhere ... I will check that (after fixing audio and wifi kernel module ;)

Regards,

Eduardo

[Guest Cass67]

The green overlay issue reminds me of something.. When dealing with YUV colorspaces, if you just set the Y component, but not the U or V components, you get a green overlay ... HC worked fine with the hwcomposer ... Perhaps the problem is ICS ... We have all the source code of the graphics subsystem ... I'd guess perhaps there is a bug somewhere ... I will check that (after fixing audio and wifi kernel module ;)

Regards,

Eduardo

Yeah could be ... im sure i seen this issue resolved elsewhere .. ill do some research see if i cant come up with something too ...

[Guest ejtagle]

Wifi working! :)

Remember to copy to /system/lib/hw/wlan

PD: This is the base 2.1.151 driver with some customizations to be able to control the powerup/down of the wlan card

wifi_atheros_src.rar

wifi_atheros.rar

[Guest Cass67]

Wifi working! :)

Remember to copy to /system/lib/hw/wlan

PD: This is the base 2.1.151 driver with some customizations to be able to control the powerup/down of the wlan card

Thx... ill have a look at this when i get a moment ...

EDIT :- unless im missing something i get the same result as before with this driver ...

http://pastebin.com/4x0i37vS

Edited December 3, 2011 by Cass67

[Guest ejtagle]

Thx... ill have a look at this when i get a moment ...

EDIT :- unless im missing something i get the same result as before with this driver ...

http://pastebin.com/4x0i37vS

When i do

insmod ar6000.ko, i get:

[ 7668.475090] Normal WIFI mode.

[ 7668.495105] ar6000_available

[ 7668.509900] AR6000: Unsupported configuration opcode: 3

[ 7668.526457] Firmware mode set

[ 7668.541231] AR6000: Unsupported configuration opcode: 3

[ 7668.554847] AR6000: Unsupported configuration opcode: 5

[ 7668.569379] BMI enabled

[ 7668.584505] ar6000_avail: name=wlan0 hifdevice=0xd8ac9000, dev=0xd84be000 (0), ar=0xd84be460

[ 7668.600987] old options [0] old sleep [29]

[ 7668.615052] Set hi_refclk_hz : Ref Clock=26000000

[ 7668.629936] AR6000: eeprom transfer by HOST

[ 7668.643850] eeprom_ar6000_transfer: Enter

[ 7668.657454] enable_SI

[ 7669.028455] disable_SI

[ 7669.043716] AR6000: BMISetAppStart

[ 7669.053929] AR6000: enable HI_OPTION_TIMER_WAR

[ 7669.064394] AR6000: firmware_transfer

[ 7669.074208] firmware_transfer: /system/lib/hw/wlan/athwlan.bin.z77 size 93530 bufsize 94208

[ 7669.084959] firmware_transfer: BMILZData: len=8192, remaining=86016

[ 7669.132373] firmware_transfer: BMILZData: len=8192, remaining=77824

[ 7669.177757] firmware_transfer: BMILZData: len=8192, remaining=69632

[ 7669.223967] firmware_transfer: BMILZData: len=8192, remaining=61440

[ 7669.269326] firmware_transfer: BMILZData: len=8192, remaining=53248

[ 7669.315070] firmware_transfer: BMILZData: len=8192, remaining=45056

[ 7669.360927] firmware_transfer: BMILZData: len=8192, remaining=36864

[ 7669.406192] firmware_transfer: BMILZData: len=8192, remaining=28672

[ 7669.451359] firmware_transfer: BMILZData: len=8192, remaining=20480

[ 7669.496742] firmware_transfer: BMILZData: len=8192, remaining=12288

[ 7669.541841] firmware_transfer: BMILZData: len=8192, remaining=4096

[ 7669.586768] firmware_transfer: BMILZData: len=4096, remaining=0

[ 7669.613603] firmware_transfer: /system/lib/hw/wlan/data.patch.hw2_0.bin size 1328 bufsize 4096

[ 7669.637259] ar6000_init() Got WMI @ 0xd8947600.

[ 7669.803167] mac address = cc:d8:11:00:a1:6c

[ 7669.811998] ar6000_init() WMI is ready

[ 7669.821424] wmi_control_rx() : Unknown id 0x101e

[ 7669.833109] AR6000 Reg Code = 0x60

[ 7670.413134] AR6000 scan complete: 0

Perhaps your kernel config differs from mine ? , or the driver can't find the updated firmware files ... I am using the same kernel sources/driver sources and patches as you ;)

[Guest ejtagle]

Well, so we are all on the same page, i have attached my latests patches to the 2.6.39 kernel ... They solve the audio crash... but, truth to be said, audio is not working... And it is pretty strange.

i2s register settings are identical between 2.6.36 and 2.6.39 kernels, Also audio clock settings. I have even actually measured with a digital oscilloscope that the sound data gets to the audio codec. and it does!. And the audio codec registers contain the right values to be able to output sound... The same values as the 2.6.36 kernel... But no sound is output. And, just in case, no ... there is no broken hw... The 2.6.36 properly outputs sound right now...

I have also observed that USB host is not working in the 2.6.39 kernel... It sorts of works by the fact that the kernel detects that an USB device was plugged, but then fails to enumerate it.

I think that all those problems could be caused by some sort of missing voltage regulator programming, but i didn't find it yet. I think that i will have to actually measure those voltages on the PCB... Arggg! :(

Well, all the other things are working properly. In fact, i do suspect that this kernel is more power efficient than the 2.6.36 kernel...

Well, if someone has any idea on the causes of the sound not working, and /or the failures of the enumeration of USB devices in host mode, just let me know

Regards,

Eduardo

patch2.6.39_v09.rar

[Guest RaYmAn84]

Well, so we are all on the same page, i have attached my latests patches to the 2.6.39 kernel ... They solve the audio crash... but, truth to be said, audio is not working... And it is pretty strange.

i2s register settings are identical between 2.6.36 and 2.6.39 kernels, Also audio clock settings. I have even actually measured with a digital oscilloscope that the sound data gets to the audio codec. and it does!. And the audio codec registers contain the right values to be able to output sound... The same values as the 2.6.36 kernel... But no sound is output. And, just in case, no ... there is no broken hw... The 2.6.36 properly outputs sound right now...

I have also observed that USB host is not working in the 2.6.39 kernel... It sorts of works by the fact that the kernel detects that an USB device was plugged, but then fails to enumerate it.

I think that all those problems could be caused by some sort of missing voltage regulator programming, but i didn't find it yet. I think that i will have to actually measure those voltages on the PCB... Arggg! :(

Well, all the other things are working properly. In fact, i do suspect that this kernel is more power efficient than the 2.6.36 kernel...

Well, if someone has any idea on the causes of the sound not working, and /or the failures of the enumeration of USB devices in host mode, just let me know

Regards,

Eduardo

Hi Eduardo!

Good job on the porting effort :)

I've been looking at your changes, and while it looks good all-in-all, I'm curious about the fairly high amount of changes in generic tegra files.

Are these changes really necessary? Keep in mind that ANY changes to anything but board-specific drivers and board files will require more work whenever we need to port to a new kernel.

With adam I'm trying to keep it as 'stock' as possible to avoid this issue. Admittedly my adam 2.6.39 kernel doesn't quite boot atm, but I've only spent around an hour porting it so far ;)

-RaYmAn

[Guest ejtagle]

Hi Eduardo!

Good job on the porting effort :)

I've been looking at your changes, and while it looks good all-in-all, I'm curious about the fairly high amount of changes in generic tegra files.

Are these changes really necessary? Keep in mind that ANY changes to anything but board-specific drivers and board files will require more work whenever we need to port to a new kernel.

With adam I'm trying to keep it as 'stock' as possible to avoid this issue. Admittedly my adam 2.6.39 kernel doesn't quite boot atm, but I've only spent around an hour porting it so far ;)

-RaYmAn

Hi! ... If you compare the changes between the stock files and my versions, you'll notice i had to do them... For example, the SDHCI host driver expects to find some voltage regulators for the sdioio and sdio host. Those regulators do not exist in the tegra2 platform. And if the driver does not find them, it aborts the initialization ... Perhaps this could be handled by a virtual regulator ... but the other modification to that file is the gpio registering calls, that try to register several gpios with the same names... and they fail if more than one SDHCI slot is used , as is the case in both adam and shuttle. All those problems had to be corrected...

The most important modification is to the video subsystem files.... Nvidia removed some propietary interfaces from the framebuffer driver from 2.6.36 to the 2.6.39 versions... Probably, those propietary ioctls could be substituted by code running in the hwcomposer component provided by NVidia, but, we don't have such modified hwcomposer,,, The only hwcomposer/overlay/openGL drivers we have are for the 2.6.36 kernel, and they require those propietary interfaces to work. If, at some point, we get updated drivers(hwcomposer/overlay/opengl) from nvidia, then we will be able to revert it.

Don't worry, all the modifications to the stock files don't require further work. They will work as they are for all tegra2 based telephones/tablets/pcs... I think that the 2.6.39 is mostly being developed for the tegra3, and that is why we need to mod some things to make them work for the tegra2 platform ... NVidia focuses testing in the tegra3, and not so throughtly on the tegra2 at this time...

[Guest RaYmAn84]

Hi! ... If you compare the changes between the stock files and my versions, you'll notice i had to do them... For example, the SDHCI host driver expects to find some voltage regulators for the sdioio and sdio host. Those regulators do not exist in the tegra2 platform. And if the driver does not find them, it aborts the initialization ... Perhaps this could be handled by a virtual regulator ... but the other modification to that file is the gpio registering calls, that try to register several gpios with the same names... and they fail if more than one SDHCI slot is used , as is the case in both adam and shuttle. All those problems had to be corrected...

Hmm.. Interesting. I've gotten my 2.6.39 booting now as well, but without making those changes.

Admittedly, the external SDcard seems to not work. It might be related to the gpio changes I guess. I still need to get the dmesg.txt off the device ;)

Other than that, everything seems to work well. Including USB host (adam only has 'native' host ports. The OTG port only really works as device port).

The most important modification is to the video subsystem files.... Nvidia removed some propietary interfaces from the framebuffer driver from 2.6.36 to the 2.6.39 versions... Probably, those propietary ioctls could be substituted by code running in the hwcomposer component provided by NVidia, but, we don't have such modified hwcomposer,,, The only hwcomposer/overlay/openGL drivers we have are for the 2.6.36 kernel, and they require those propietary interfaces to work. If, at some point, we get updated drivers(hwcomposer/overlay/opengl) from nvidia, then we will be able to revert it.

Updated drivers are not far behind ;)

Don't worry, all the modifications to the stock files don't require further work. They will work as they are for all tegra2 based telephones/tablets/pcs... I think that the 2.6.39 is mostly being developed for the tegra3, and that is why we need to mod some things to make them work for the tegra2 platform ... NVidia focuses testing in the tegra3, and not so throughtly on the tegra2 at this time...

What I meant about modifications is that they need to be forward ported everytime a new tegra kernel is out or if someone wants to base it on something else.

It's true that 2.6.39 is certainly more directed at tegra3, but it still works surprisingly well :)

[Guest Cass67]

[quote name='ejtagle' timestamp='1323061076' post='1858653'

]

Well, if someone has any idea on the causes of the sound not working, and /or the failures of the enumeration of USB devices in host mode, just let me know

Regards,

Eduardo

Edited December 5, 2011 by Cass67

[Guest ejtagle]

Hmm.. Interesting. I've gotten my 2.6.39 booting now as well, but without making those changes.

Admittedly, the external SDcard seems to not work. It might be related to the gpio changes I guess. I still need to get the dmesg.txt off the device ;)

Other than that, everything seems to work well. Including USB host (adam only has 'native' host ports. The OTG port only really works as device port).

Updated drivers are not far behind ;)

What I meant about modifications is that they need to be forward ported everytime a new tegra kernel is out or if someone wants to base it on something else.

It's true that 2.6.39 is certainly more directed at tegra3, but it still works surprisingly well :)

The modifications are not needed to make the kernel boot... But, some of them are required either to support old hw acceleration nvidia provided binaries (and, thus, those mods could be reverted once we get the updated drivers), or to fix puntual problems (the silly assumtion that the SDHCI has a voltage regulator... Ok, we can circunvent it using the virtual voltage regulator driver i wrote) ... or the gpio naming (that is an actual bug of the driver), or, related to audio, there is also a bug... fixed by the patch... or, regarding the evdev subsystem, the patch is to allow suspension when an accelerometer is reporting events continuously ... otherwise, the device does never suspend...

Don't worry, most mods will go away with updated user level drivers...

[Guest Areo]

Hi all,

Yes again this question:

Because I still have issues with my pc building ICS could somebody send me a build to work on?

Areo

[Guest ejtagle]

Hi all,

Yes again this question:

Because I still have issues with my pc building ICS could somebody send me a build to work on?

Areo

Are you shure you have enough free space on your /tmp drive ? -- I got out of space errors even having plenty of space available on the main drive where the ICS sources are stored, and i found out that the problem was the /tmp folder that was mounted in a different drive without enough free space ... And i found out that the ICS build system requires several gygabytes of free space in that temp folder to be able to do a successful build of ICS. Also, you need probably more than 3GB of free RAM, or at least, a suitable swap partition to emulate them ... With those things solved, your ICS build should complete without trouble... ;)

(and by free space, i mena either free space or the maximum disk space quota configured for the user doing the ICS build ,) )

Edited December 6, 2011 by ejtagle

[Guest Areo]

Are you shure you have enough free space on your /tmp drive ? -- I got out of space errors even having plenty of space available on the main drive where the ICS sources are stored, and i found out that the problem was the /tmp folder that was mounted in a different drive without enough free space ... And i found out that the ICS build system requires several gygabytes of free space in that temp folder to be able to do a successful build of ICS. Also, you need probably more than 3GB of free RAM, or at least, a suitable swap partition to emulate them ... With those things solved, your ICS build should complete without trouble... ;)

(and by free space, i mena either free space or the maximum disk space quota configured for the user doing the ICS build ,) )

I have 1,75TB free space on that drive, my temp drive is the same as where it stores ICS. I have 24GB RAM from which 16 is usable for ICS compiling. But still getting the errors.

Full specs:

-12 Terrabyte of free space

-24 RAM DDR3

-i7 @ 4,9 GHZ

-HD5970 Toxic Edition x2 = 8GB DDR5

Kind Regards,

Areo

Edited December 6, 2011 by Areo

[Guest ejtagle]

I have 1,75TB free space on that drive, my temp drive is the same as where it stores ICS. I have 24GB RAM from which 16 is usable for ICS compiling. But still getting the errors.

Full specs:

-12 Terrabyte of free space

-24 RAM DDR3

-i7 @ 4,9 GHZ

-HD5970 Toxic Edition x2 = 8GB DDR5

Kind Regards,

Areo

It should be more than enough to build ICS... Perhaps a sw issue ?

Perhaps, it would be nice if you post the build logs ... Someone could help spotting the issue ;) -- You don't need to do a full build. Just wait until it fails, then relaunch the build and it will only log the failure ... ;)