Advent Vega kernel source code now available!

[Guest Cass67]

Eduardo,

You compiled ICS? You able to run with systemui not crashing on boot if so?

Cheers

Cass

[Guest ejtagle]

Eduardo,

You compiled ICS? You able to run with systemui not crashing on boot if so?

Cheers

Cass

Not completely... I always prefer to use a plain busybux linux box to test kernels..Otherwise, it becomes much difficult to find out who/where are bugs... Using busybox allos me to bring each system up individually, and carry separate tests for them. Launching a full ICS image makes it much harder to debug. Once i get everything working properly at the kernel and busybox levels, that will be the moment to try the ICS image ;)

[Guest Cass67]

Not completely... I always prefer to use a plain busybux linux box to test kernels..Otherwise, it becomes much difficult to find out who/where are bugs... Using busybox allos me to bring each system up individually, and carry separate tests for them. Launching a full ICS image makes it much harder to debug. Once i get everything working properly at the kernel and busybox levels, that will be the moment to try the ICS image ;)

Yeah I thought that was your method. Just seemed from your words above like you had compiled it already. ;)

Cheers

Cass

[Guest nelles]

lg optimus 2x is going to get ics soon ... so i hope we can rip some native tegra 2 libraries from it ....

[Guest pershoot]

great work eduardo and cass!

i too have been trying to sort the green issue to no avail (on another tegra2 device).

i wonder what changed in ICS to cause this when working with the supplied hwcomposer.

hmm..

Edited December 10, 2011 by pershoot

[Guest newbe5]

great work eduardo and cass!

i too have been trying to sort the green issue to no avail (on another tegra2 device).

i wonder what changed in ICS to cause this when working with the supplied hwcomposer.

hmm..

Are we 100% sure that this is something that has changed in ICS? Has anyone tried compiling 3.2 from source (since these are now available) to confirm that the same issue isn't present in AOSP Honeycomb?

[Guest rvdgeer]

Are we 100% sure that this is something that has changed in ICS? Has anyone tried compiling 3.2 from source (since these are now available) to confirm that the same issue isn't present in AOSP Honeycomb?

I'm most definitely not a dev, but could it be the kernel...?

Look at what's written here: Notion Ink

[Guest Cass67]

I'm most definitely not a dev, but could it be the kernel...?

Look at what's written here: Notion Ink

We are running on the .39 kernel just now and it shows the green flash ... not sure where MrDeadlocked got the idea it was kernel specific this problem .. Need to catch up with him and see why he thinks this .. Ive been talking with him about some other issues and he didnt mention it was kernel, maybe a new development over the past week ive had downtime ...

Cheers

Cass

[Guest Cass67]

Are we 100% sure that this is something that has changed in ICS? Has anyone tried compiling 3.2 from source (since these are now available) to confirm that the same issue isn't present in AOSP Honeycomb?

100% sure of nothing at this point mate .. all i know is the hwcomposer libs and the stub code in android pre HC is the same as what we are running now in ICS.. i compared many source files related to this, EGL, Gralloc, hwcomposer and they all seem the same code as ICS ... I could have missed something but the code in libhardware is quite short...

It may be worth a shot compiling HC to see what the score is .. but with my luck over the past week ill probably blow the Vega up trying to install it ;)

edit :- actually it would not surprise me if the problem lies somewhere else in the code like the frameworks for animations and transitions, as Eduardo mentioned earlier it could be we have something weird in the colorspaces going on ... it seems we get green when it we should be transparency, the flash is much reduced when we turn animations off...

Edited December 10, 2011 by Cass67

[Guest Cass67]

great work eduardo and cass!

i too have been trying to sort the green issue to no avail (on another tegra2 device).

i wonder what changed in ICS to cause this when working with the supplied hwcomposer.

hmm..

Good to see more and more are looking at this issue, im sure we'll have it beat before long ;)

[Guest brucelee666]

Good to see more and more are looking at this issue, im sure we'll have it beat before long ;)

You may want to speak with fards over on the hannspad ics dev on tabletroms, he posted this on the 7/12:-

"WEE bit busy..

NEWS

.39 kernel progressing nicely https://github.com/fards/android-tegra-nv-2.6.39

wee bit unstable still but it allows several things...

no green

serious I kid you not...

audio to possibly work quite soon ..."

From the "no green" comment maybe he fixed it ????

[Guest Cass67]

You may want to speak with fards over on the hannspad ics dev on tabletroms, he posted this on the 7/12:-

"WEE bit busy..

NEWS

.39 kernel progressing nicely https://github.com/fards/android-tegra-nv-2.6.39

wee bit unstable still but it allows several things...

no green

serious I kid you not...

audio to possibly work quite soon ..."

From the "no green" comment maybe he fixed it ????

Done ;)

Thanks a lot

edit ... i still have green but then i still have many issues... needs more work .. if its confirmed with other people then i guess my build is to blame .. its being worked on ..

edit 2.. still green with the adam build i have .. now to try with fards haanspad build..

edit 3 .. beginning to think vega has special hardware .. green screen still apparent on the same build fards has no green screen on .. haanspad build is similar to the rest for us .. :( all fixes in place as far as i can tell that others have gotten it fixed with ..

Interested in seeing if pershoot comes back with similar results as it seems he has similar info ???

edit4 .. messing around in settings i now get a rather spiffy red boarder flash .. hey .. change is as good as a holiday they say :)

edit5 .. on the upshot Eduardo .. the wifi you provided earlier works for me now .. dunno what the diff was ;)

Edited December 11, 2011 by Cass67

[Guest ejtagle]

Done ;)

Thanks a lot

edit ... i still have green but then i still have many issues... needs more work .. if its confirmed with other people then i guess my build is to blame .. its being worked on ..

edit 2.. still green with the adam build i have .. now to try with fards haanspad build..

edit 3 .. beginning to think vega has special hardware .. green screen still apparent on the same build fards has no green screen on .. haanspad build is similar to the rest for us .. :( all fixes in place as far as i can tell that others have gotten it fixed with ..

Interested in seeing if pershoot comes back with similar results as it seems he has similar info ???

edit4 .. messing around in settings i now get a rather spiffy red boarder flash .. hey .. change is as good as a holiday they say :)

edit5 .. on the upshot Eduardo .. the wifi you provided earlier works for me now .. dunno what the diff was ;)

I was thinking... I really doubl there is a big difference between .36 and .39 kernels in the video subsystem... But, perhaps the difference is a memory alignment buffer issue. In the ICS source there are hwcomposer test utilities. Search for hwc* files, and you'll find them.

Perhaps the problem is the video memory allocator that is, under some circunstances, delivering memory blocks that are not aligned as required by the tegra2 hw. If you compare the .36 with the .39 video subsystem you will find that they added a forced alignment constraint to the user supplied video memory buffer addresses. They say it is required a 16byte alignment. That check was not present on the .36 kernel.

Perhaps, what we should check is the memory that was reserved for the hanspad for the video subsystem, compared to the amount of memory reserved for our shuttle. I found out they changed the amount of reserved memory. Perhaps, that would "fix"this issue...

[Guest pershoot]

Done ;)

Thanks a lot

edit ... i still have green but then i still have many issues... needs more work .. if its confirmed with other people then i guess my build is to blame .. its being worked on ..

edit 2.. still green with the adam build i have .. now to try with fards haanspad build..

edit 3 .. beginning to think vega has special hardware .. green screen still apparent on the same build fards has no green screen on .. haanspad build is similar to the rest for us .. :( all fixes in place as far as i can tell that others have gotten it fixed with ..

Interested in seeing if pershoot comes back with similar results as it seems he has similar info ???

edit4 .. messing around in settings i now get a rather spiffy red boarder flash .. hey .. change is as good as a holiday they say :)

edit5 .. on the upshot Eduardo .. the wifi you provided earlier works for me now .. dunno what the diff was ;)

here is the fix for the green splash on render issue.

need these libs (at a bare minimum) from fards's .39 based build (i believe you have them).

(your egl.cfg should have 0 1 tegra):

lib -

libnvddk_2d_v2.so

libcgdrv.so

libardrv_dynamic.so

libnvmm_vp6_video.so

libnvwsi.so

libnvwinsys.so

libnvos.so

libnvrm.so

libnvrm_graphics.so

lib/egl -

libGLESv2_tegra.so

libGLESv1_CM_tegra.so

libEGL_tegra.so

lib/hw -

hwcomposer.tegra.so

gralloc.tegra.so

my advice is to work with .36, as i believe this is currently stable/developed for your device.

back ported dc/fb/nvmap from .39 (using the new interface calls/allocation, etc.), for 2.6.36:

https://github.com/p...2898db6e153e309

https://github.com/p...99f1c02364caf9a

https://github.com/p...27ebf80724418ae

https://github.com/p...37e4963a1c688fe

youll need to modify some for your specific device. you can bring it under VARIATION_TEGRA and then remove that dependancy.

you could probably also use .39 (i have not backported/tested the nvhost stuff from there though), if you feel you have a stable subsystem to work with. dc/fb must not be modified for the older userspace/libs (you have the libs/userspace to work with them now).

in init.rc, set:

chmod 666 /dev/tegra_dc0

chmod 666 /dev/tegra_dc1

that should do it.

also use:

BoardConfig:

USE_OPENGL_RENDERER := true

Edited December 14, 2011 by pershoot

[Guest Cass67]

here is the fix for the green splash on render issue.

need these libs (at a bare minimum) from fards's .39 based build (i believe you have them).

(your egl.cfg should have 0 1 tegra):

lib -

libnvddk_2d_v2.so

libcgdrv.so

libardrv_dynamic.so

libnvmm_vp6_video.so

libnvwsi.so

libnvwinsys.so

libnvos.so

libnvrm.so

libnvrm_graphics.so

lib/egl -

libGLESv2_tegra.so

libGLESv1_CM_tegra.so

libEGL_tegra.so

lib/hw -

hwcomposer.tegra.so

gralloc.tegra.so

my advice is to work with .36, as i believe this is currently stable/developed for your device.

back ported dc/fb/nvmap from .39 (using the new interface calls/allocation, etc.), for 2.6.36:

https://github.com/p...2898db6e153e309

https://github.com/p...99f1c02364caf9a

https://github.com/p...27ebf80724418ae

https://github.com/p...37e4963a1c688fe

youll need to modify some for your specific device. you can bring it under VARIATION_TEGRA and then remove that dependancy.

you could probably also use .39 (i have not backported/tested the nvhost stuff from there though), if you feel you have a stable subsystem to work with. dc/fb must not be modified for the older userspace/libs (you have the libs/userspace to work with them now).

in init.rc, set:

chmod 666 /dev/tegra_dc0

chmod 666 /dev/tegra_dc1

that should do it.

also use:

BoardConfig:

USE_OPENGL_RENDERER := true

Thanks .. knew there had to be something extra in kernel ;) .. ill leave the perusing of the code to Eduardo in as much as how it relates to our .39 kernel just now .. it is pretty stable as is and id not want to have to roll back and add your patches to .36 .. im sure he can tell which fb patches need to be backed out or changed way quicker than i would by pouring over that lot given he wrote it all... good to see progress though .. nice one :)

edit :- actually .. there is no green flash now with .39, just pushed it all clean on a fresh compile .. seems i missed something in earlier tests .. its just slower performance .. still kernel changes maybe but definitely progress.. :D

edit2 :- turn off animations and force on 2d acceleration and performance is back to what id expect .. well usable ... now for the devices :)

Cheers

Cass

Edited December 15, 2011 by Cass67

[Guest ejtagle]

Thanks .. knew there had to be something extra in kernel ;) .. ill leave the perusing of the code to Eduardo in as much as how it relates to our .39 kernel just now .. it is pretty stable as is and id not want to have to roll back and add your patches to .36 .. im sure he can tell which fb patches need to be backed out or changed way quicker than i would by pouring over that lot given he wrote it all... good to see progress though .. nice one :)

edit :- actually .. there is no green flash now with .39, just pushed it all clean on a fresh compile .. seems i missed something in earlier tests .. its just slower performance .. still kernel changes maybe but definitely progress.. :D

edit2 :- turn off animations and force on 2d acceleration and performance is back to what id expect .. well usable ... now for the devices :)

Cheers

Cass

Yes, i also think that the .39 kernel is a better choice for ICS.. I still have to figure out the sound issues... Being busy lately ... It shouldn't be hard to figure out... Will do some extra measurements to find the causes ;)

But,we should be able to bring up all the other hw features without problems :D

Edited December 15, 2011 by ejtagle

[Guest Cass67]

OK, here is an update as to where we are with regards to the ICS port for Vega and relatives :-

Works

=====

touchscreen

hw acceleration

sdcard

bluetooth

wifi

No green flashes

In Progress

=========

sensors

sound

camera

Flakey

=====

Performance, slow'ish when animations are on and force 2d accel is off, fast with this rectified.

Power Button, screen gets all flashy with the power off dialogue box

Sleep, causes warm reboot

dns on wifi .. manual hack in place to use google servers, not looked to fix this yet

Ill put out a build soon for all to play with as soon as i figure out how ill handle the apps we all need to use .. currently ICS is a bit too bloated to fit in the same space as HC without stripping some of the default apps out ... which is not nice .. currently im sitting at 4.3MB free on /system after ripping out most of the default ICS apps ... None of the Gapps are installed yet either ...

Rgds

Cass

[Guest ejtagle]

OK, here is an update as to where we are with regards to the ICS port for Vega and relatives :-

Works

=====

touchscreen

hw acceleration

sdcard

bluetooth

wifi

No green flashes

In Progress

=========

sensors

sound

camera

Flakey

=====

Performance, slow'ish when animations are on and force 2d accel is off, fast with this rectified.

Power Button, screen gets all flashy with the power off dialogue box

Sleep, causes warm reboot

dns on wifi .. manual hack in place to use google servers, not looked to fix this yet

Ill put out a build soon for all to play with as soon as i figure out how ill handle the apps we all need to use .. currently ICS is a bit too bloated to fit in the same space as HC without stripping some of the default apps out ... which is not nice .. currently im sitting at 4.3MB free on /system after ripping out most of the default ICS apps ... None of the Gapps are installed yet either ...

Rgds

Cass

It would be very, very interesting to try another filesystem besides yaffs2.. There are either rom based filesystems (as used by the livecds), or the ubifs. Perhaps, they could offer better compression than the yaffs2 we are using right now... ;)

[Guest Cass67]

It would be very, very interesting to try another filesystem besides yaffs2.. There are either rom based filesystems (as used by the livecds), or the ubifs. Perhaps, they could offer better compression than the yaffs2 we are using right now... ;)

Great idea .. ill put out the build as is with all the missing apps shoved in /data then work forward to use a diff filesystem .. squashfs came to mind but for now to try and get some help ironing out the stuff thats outstanding i want to get this out here, coming up to xmas and my time is running short ;) ... Alpha2 will be where we play with FS i think ;)

Cheers

Cass

[Guest ejtagle]

Great idea .. ill put out the build as is with all the missing apps shoved in /data then work forward to use a diff filesystem .. squashfs came to mind but for now to try and get some help ironing out the stuff thats outstanding i want to get this out here, coming up to xmas and my time is running short ;) ... Alpha2 will be where we play with FS i think ;)

Cheers

Cass

That is the idea, squashfs ;) -- Anything i could help. just mention it. The only thing i am worried about is sound... All the other things should not be a problem... Just a matter of time :S

[Guest the_corvus]

That is the idea, squashfs ;) -- Anything i could help. just mention it. The only thing i am worried about is sound... All the other things should not be a problem... Just a matter of time :S

Hi boys...

too much time without seeing you... but i'm happy because you continue working on Vega.

Some info about audio (related with android in X86, but maybe usefull):

http://groups.google.com/group/android-x86/browse_thread/thread/1e82e2b8a6a5eaac/2dc278b39e287fe8#2dc278b39e287fe8

And about the red border, i read somewhere that using (or not using, i don remember) live walpapers fix it.

Corvus.

[Guest brucelee666]

Hi boys...

too much time without seeing you... but i'm happy because you continue working on Vega.

Some info about audio (related with android in X86, but maybe usefull):

http://groups.google...dc278b39e287fe8

And about the red border, i read somewhere that using (or not using, i don remember) live walpapers fix it.

Corvus.

Re. Red Border, this is what I sent newbe5 about the same problem (I think its the same problem) he mentioned on twitter:-

"Not on twitter but to answer your tweets on the red rectangle, it also happens in sdk emulator.

From what Ive seen in emulator it is the "Strict Mode Enabled" that causes the problem but the "Developer options" in the settings app does not seem to turn this off.

If you select the "Strice Mode Enabled" option as you expect green tick its now turned on.

If you select it again it does not turn it off it sets it to "build variant default".

To turn it off you have to go into the "Dev Tools" app which comes with the emulator image not sure if its in your rom, go into "development settings" select "SelectMode visual indicator" and select off."

You may know this already but for information hope this gets rid of the red border as it did on the sdk.

[Guest Cass67]

That is the idea, squashfs ;) -- Anything i could help. just mention it. The only thing i am worried about is sound... All the other things should not be a problem... Just a matter of time :S

squashfs works well :)

Have 8mb free with all apps and Gapps in place in /system

/dev/block/mtdblock3 151.4M 143.4M 8.0M 95% /system

/dev/block/loop0 3.5M 3.5M 0 100% /system/fonts

/dev/block/loop1 18.1M 18.1M 0 100% /system/framework

/dev/block/loop2 4.0M 4.0M 0 100% /system/usr

/dev/block/loop3 52.5M 52.5M 0 100% /system/app

Makes it slightly more difficult to change stuff on the fly, but with the exception of framwork we should not be impacted by these changes... and with the source we should not need to touch framework ...

Just some stuff to get right before i push out the Alpha1 build, ill do later today if i get a chance ..

Cass

[Guest Cass67]

Re. Red Border, this is what I sent newbe5 about the same problem (I think its the same problem) he mentioned on twitter:-

"Not on twitter but to answer your tweets on the red rectangle, it also happens in sdk emulator.

From what Ive seen in emulator it is the "Strict Mode Enabled" that causes the problem but the "Developer options" in the settings app does not seem to turn this off.

If you select the "Strice Mode Enabled" option as you expect green tick its now turned on.

If you select it again it does not turn it off it sets it to "build variant default".

To turn it off you have to go into the "Dev Tools" app which comes with the emulator image not sure if its in your rom, go into "development settings" select "SelectMode visual indicator" and select off."

You may know this already but for information hope this gets rid of the red border as it did on the sdk.

Fortunately we are not impacted by this red boarder flash anymore .. not green flashing too ;)

[Guest ejtagle]

squashfs works well :)

Have 8mb free with all apps and Gapps in place in /system

/dev/block/mtdblock3 151.4M 143.4M 8.0M 95% /system

/dev/block/loop0 3.5M 3.5M 0 100% /system/fonts

/dev/block/loop1 18.1M 18.1M 0 100% /system/framework

/dev/block/loop2 4.0M 4.0M 0 100% /system/usr

/dev/block/loop3 52.5M 52.5M 0 100% /system/app

Makes it slightly more difficult to change stuff on the fly, but with the exception of framwork we should not be impacted by these changes... and with the source we should not need to touch framework ...

Just some stuff to get right before i push out the Alpha1 build, ill do later today if i get a chance ..

Cass

Really, really an excellent work ;) Congrats, Cass! :D -- Yes, squashfs makes a little bit harder to change things... we could use a fused fs to allow to override squashedfs files, but i don't see the point on it. Originally, the idea has always been to not let the user uninstall core apps. In this case, we are getting essentially, more about twice the storage by compressing things. This is a huge advantage compared to not using it. I would also suspect it could be even faster , as the nand is quite slow compared with the tegra2 CPUs, so decompressing could easily mean the system loads faster... Yay!... I repeat, an excellent work! - Besides, a few reflashes to update things should not be a problem... And , if testing small patches, be could use http://www.denx.de/w...Know/MiniFOHome, that would allow small modifications to the squashed fs ;)

Or... using a more modern approach, unionfs ;) -- But mini_fo seems to be lighter and less resource hungry ...

Edited December 16, 2011 by ejtagle