Jump to content
PaulOBrien

Advent Vega kernel source code now available!

Recommended Posts

strace has been very useful so far... I wrote an small app that directly calls the libnvomx.so and tries to decode video ... I got the exact same error as libstagefright does while trying to play video (out of resources)

Using strace to get a log, seems the libnvrm.so from our libs used by libnvomx.so is reading /sys/module/fuse/parameters/tegra_chip_id and also /sys/module/fuse/parameters/tegra_chip_rev and passes that information to another process. As soon as that process receives that information, it commits suicide and also seems to be the responsible of denying hw acceleration for video decoding to the client... So, i think that we have a verification on the hw revision of the chip... Our tegra2 chip is revision 3, so it is rather old...

I have verified that the libnvrm.so from the google package does not have that verification in place, so i guess i will try either to patch the kernel to lie on chip version, or to mix libraries ;)

Let;s see what happens next ;)

edit1: -- Mixing libraries didnt work...

Share this post


Link to post
Share on other sites

Seems the prime ics libnvomx is no use either .. loads but, seems same results .. the gralloc from prime wont load on my initial tests .. not did much tests to be honest but without replacing all libs and dicking around i get

I/SurfaceFlinger( 326): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...

E/HAL ( 326): load: module=/system/lib/hw/gralloc.tegra.so

E/HAL ( 326): Cannot load library: get_lib_extents[749]: 326 - /system/lib/hw/gralloc.tegra.so is not a valid ELF object

Compiled for tegra3 only ?

Ill play later but im not holding out much hope..

Cass

Share this post


Link to post
Share on other sites

To Cass,

Hi m8,

Did you change the screen rotation values (gyro) in ICS? People say it's better then in HC. If yes, it's probably easy to port to the .36 kernel right?

Could you send me the file or give me a git where I can get it from?

Kind Regards,

Areo

Share this post


Link to post
Share on other sites

To Cass,

Hi m8,

Did you change the screen rotation values (gyro) in ICS? People say it's better then in HC. If yes, it's probably easy to port to the .36 kernel right?

Could you send me the file or give me a git where I can get it from?

Kind Regards,

Areo

Hey bud,

I can see a slight diff in the driver from 39 to 36 but its hard to say if that would make a diff in the rotation feel between both kernels, id have been more inclined to blame the android framework diffs between HC and ICS more than anything else.

https://github.com/wooshy1/android-tegra-nv-2.6.39 << our ICS kernel

https://github.com/wooshy1/kernel_2.6.36_nvidia_base << HC kernel

drivers/input/misc/bma150.c << file in question

and the main diffs i can see from .39 to .36 are as follows

> /*#define xy_flip*/

> static int temp1;

> #ifdef xy_flip

> temp1=(acc->x * -1);

> acc->x=acc->y;

> acc->y=temp1;

> #endif

The .36 has the above the .39 does not as far as i can see from a simple diff of the 2 versions of files, the other changes relate to power management additions in .39..

Rgds

Cass

Share this post


Link to post
Share on other sites

Seems the prime ics libnvomx is no use either .. loads but, seems same results .. the gralloc from prime wont load on my initial tests .. not did much tests to be honest but without replacing all libs and dicking around i get

I/SurfaceFlinger( 326): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...

E/HAL ( 326): load: module=/system/lib/hw/gralloc.tegra.so

E/HAL ( 326): Cannot load library: get_lib_extents[749]: 326 - /system/lib/hw/gralloc.tegra.so is not a valid ELF object

Compiled for tegra3 only ?

Ill play later but im not holding out much hope..

Cass

Hey Cass,

did you try the files from inside the chinese Xoom Development Image too?

Share this post


Link to post
Share on other sites

Hey bud,

I can see a slight diff in the driver from 39 to 36 but its hard to say if that would make a diff in the rotation feel between both kernels, id have been more inclined to blame the android framework diffs between HC and ICS more than anything else.

https://github.com/w...tegra-nv-2.6.39 << our ICS kernel

https://github.com/w....36_nvidia_base << HC kernel

drivers/input/misc/bma150.c << file in question

and the main diffs i can see from .39 to .36 are as follows

> /*#define xy_flip*/

> static int temp1;

> #ifdef xy_flip

> temp1=(acc->x * -1);

> acc->x=acc->y;

> acc->y=temp1;

> #endif

The .36 has the above the .39 does not as far as i can see from a simple diff of the 2 versions of files, the other changes relate to power management additions in .39..

Rgds

Cass

This is not defined as you can see /**/ so that is why I havent re-enabled it in the .36 kernel. The main difference regarding the two kernels is the fact the .39 has a kernel config option that .36 did not have I have set this in my last update to github. I have pm'd you about this Aero.

CONFIG_INPUT_BMA150_I2C=y[/CODE]

tells BMA150 driver to output i2c instead of raw iirc

regards

wooshy1

Share this post


Link to post
Share on other sites

This is not defined as you can see /**/ so that is why I havent re-enabled it in the .36 kernel. The main difference regarding the two kernels is the fact the .39 has a kernel config option that .36 did not have I have set this in my last update to github. I have pm'd you about this Aero.

CONFIG_INPUT_BMA150_I2C=y[/CODE]

tells BMA150 driver to output i2c instead of raw iirc

regards

wooshy1

You know .. didnt even notice that ;)

Share this post


Link to post
Share on other sites

This is not defined as you can see /**/ so that is why I havent re-enabled it in the .36 kernel. The main difference regarding the two kernels is the fact the .39 has a kernel config option that .36 did not have I have set this in my last update to github. I have pm'd you about this Aero.

CONFIG_INPUT_BMA150_I2C=y[/CODE]

tells BMA150 driver to output i2c instead of raw iirc

regards

wooshy1

Hi wooshy1,

Please, can you can share the solution with the community? Many people want to solve the problem with the rotation. Public post is better than PM. :)

Thanks in advance.

Share this post


Link to post
Share on other sites

Hi wooshy1,

Please, can you can share the solution with the community? Many people want to solve the problem with the rotation. Public post is better than PM. :)

Thanks in advance.

It is in my github it is just a kernel config option to be set at kernel build time.

https://github.com/wooshy1/kernel_2.6.36_nvidia_base

Share this post


Link to post
Share on other sites

Hey Cass,

did you try the files from inside the chinese Xoom Development Image too?

yeah ... the gralloc is slightly different in as much as we dont get hung up when we see the error

E/gralloc ( 95): HDCP: hdcp_open failed, error 1

It boots as normal but HQ video is still a no go... when we use libnvomx from that image we still see the same error wrt HQ video. When we use all libnv* libs then it hangs at surfaceflinger as ive seen before with the Google Xoom libs released... ive not found the right balance of libs from this image to test yet and to be honest im not sure i will going by past results ...

Share this post


Link to post
Share on other sites

yeah ... the gralloc is slightly different in as much as we dont get hung up when we see the error

E/gralloc ( 95): HDCP: hdcp_open failed, error 1

It boots as normal but HQ video is still a no go... when we use libnvomx from that image we still see the same error wrt HQ video. When we use all libnv* libs then it hangs at surfaceflinger as ive seen before with the Google Xoom libs released... ive not found the right balance of libs from this image to test yet and to be honest im not sure i will going by past results ...

Damn. The Xoom ICS Custom Rom devs apparently fixed Hardware Acceleration with these Files, but Samsung Galaxy Tab devs on xda ran into the same problem as you did:

http://forum.xda-developers.com/showpost.php?p=21277105&postcount=419

Is there such a difference in the Tegra 2 Chips built into the Xoom, could a hidden Moto Hardware Check be the culprit or is it a Kernel thing?

Share this post


Link to post
Share on other sites

Damn. The Xoom ICS Custom Rom devs apparently fixed Hardware Acceleration with these Files, but Samsung Galaxy Tab devs on xda ran into the same problem as you did:

http://forum.xda-dev...5&postcount=419

Is there such a difference in the Tegra 2 Chips built into the Xoom, could a hidden Moto Hardware Check be the culprit or is it a Kernel thing?

I am at it... Until now, things seem to be related to an incomplete implementation of the libnvomx.so . I think an explanation is in order... As you know, to be able to render ICS withtout hardware glitches required to use pretty new "leaked" libraries...Trying to use previous HC libraries did not work, as seems there is an incompatibility between them and ICS (green flashes, etc,etc).

So we used leaked libraries, or libraries that seem to target tegra3 rather than tegra2...

The fact is that there has been a refactoring in the omx subsystem. NVidia wanted to allow more than one instance of the omx client at the same time, and so, it wrote several new avp kernel components. Specifically, i refer to tegra_mediaserver and tegra_avp. But, even if kernel wise, those components support both tegra2 and tegra3, the new propietary libs seem to only support tegra3 with them. And, the old interface that would allow to use tegra2 with omx,, even if present on the latest kernel sources, does not compile and/or work. The old interface is called tegra_nvavp. Seems some of the leaked libs could use that old interface, and in such case, tegra2 omx acceleration could work, but, first, we must fix the tegra_nvavp component of the kernel so it works...I am trying exaxctly that. Supposedly, using our no-greenflash libs(that were attached previously and adding an small patch to libmedia to export a deprecated api, could make those libraries work with hw acceleration in omx for tegra2.

The other option is to wait for nvidia to release new hw acceleration libs that use the tegra_mediaserver and support both tegra2 and tegra3..

I am trying to fix tegra_nvavp ... I am pretty close.. I ll report if it works or not:)

PD: I am in PTOso that is why updates are not as frequent as they used to be... Have to rest a bit ;)...

Share this post


Link to post
Share on other sites

I am trying to fix tegra_nvavp ... I am pretty close.. I ll report if it works or not:)

Thanks Eduardo. Good to hear! I would not set my hopes too high for Nvidia to release any useful line of tegra2 code in the near future.

BTW Acer Iconia 500 ICS HW Acceleration has also been made to work with the "chinese" Xoom Files:

http://forum.tegraow...c.php?f=9&t=106

Apperantly these guys do not want to release their code, therefore they don't post on xda anymore. But maybe you would like to contact them and ask how they did it?

Edited by pizzaboy75

Share this post


Link to post
Share on other sites

I am at it... Until now, things seem to be related to an incomplete implementation of the libnvomx.so . I think an explanation is in order... As you know, to be able to render ICS withtout hardware glitches required to use pretty new "leaked" libraries...Trying to use previous HC libraries did not work, as seems there is an incompatibility between them and ICS (green flashes, etc,etc).

So we used leaked libraries, or libraries that seem to target tegra3 rather than tegra2...

The fact is that there has been a refactoring in the omx subsystem. NVidia wanted to allow more than one instance of the omx client at the same time, and so, it wrote several new avp kernel components. Specifically, i refer to tegra_mediaserver and tegra_avp. But, even if kernel wise, those components support both tegra2 and tegra3, the new propietary libs seem to only support tegra3 with them. And, the old interface that would allow to use tegra2 with omx,, even if present on the latest kernel sources, does not compile and/or work. The old interface is called tegra_nvavp. Seems some of the leaked libs could use that old interface, and in such case, tegra2 omx acceleration could work, but, first, we must fix the tegra_nvavp component of the kernel so it works...I am trying exaxctly that. Supposedly, using our no-greenflash libs(that were attached previously and adding an small patch to libmedia to export a deprecated api, could make those libraries work with hw acceleration in omx for tegra2.

The other option is to wait for nvidia to release new hw acceleration libs that use the tegra_mediaserver and support both tegra2 and tegra3..

I am trying to fix tegra_nvavp ... I am pretty close.. I ll report if it works or not:)

PD: I am in PTOso that is why updates are not as frequent as they used to be... Have to rest a bit ;)...

good luck eduardo. i tried briefly to shimmy in nvavp a short while back (they left it uncompilable in both .36/.39), but there were other deps i was working with at the time for import, so abandoned it, and left it on the backburner.

if this avenue doesnt work (+ your libmedia patch), ill try to hack the binary up to take the suspected check out.

Edited by pershoot

Share this post


Link to post
Share on other sites

I am at it... Until now, things seem to be related to an incomplete implementation of the libnvomx.so . I think an explanation is in order... As you know, to be able to render ICS withtout hardware glitches required to use pretty new "leaked" libraries...Trying to use previous HC libraries did not work, as seems there is an incompatibility between them and ICS (green flashes, etc,etc).

So we used leaked libraries, or libraries that seem to target tegra3 rather than tegra2...

The fact is that there has been a refactoring in the omx subsystem. NVidia wanted to allow more than one instance of the omx client at the same time, and so, it wrote several new avp kernel components. Specifically, i refer to tegra_mediaserver and tegra_avp. But, even if kernel wise, those components support both tegra2 and tegra3, the new propietary libs seem to only support tegra3 with them. And, the old interface that would allow to use tegra2 with omx,, even if present on the latest kernel sources, does not compile and/or work. The old interface is called tegra_nvavp. Seems some of the leaked libs could use that old interface, and in such case, tegra2 omx acceleration could work, but, first, we must fix the tegra_nvavp component of the kernel so it works...I am trying exaxctly that. Supposedly, using our no-greenflash libs(that were attached previously and adding an small patch to libmedia to export a deprecated api, could make those libraries work with hw acceleration in omx for tegra2.

The other option is to wait for nvidia to release new hw acceleration libs that use the tegra_mediaserver and support both tegra2 and tegra3..

I am trying to fix tegra_nvavp ... I am pretty close.. I ll report if it works or not:)

PD: I am in PTOso that is why updates are not as frequent as they used to be... Have to rest a bit ;)...

Good luck mate .. get your rest ...

Im puzzled as to why the A500 and the Xoom do not have this issue, cant find the A500 source from the working build posted earlier on TegraOwners forum but they appear to be using the 2.6.36.4 kernel (2.6.36.4-thor-V3.9r7) .. got from that from a strings on the boot.img, cant find it on github or other such place... The libs have the same results on our hardware platform as the xoom ones, suspect they are the same as the xoom ones but ive not compared them at the binary level ... I have mixed and matched a pile depending on the libs that contain the functions each panic complains about ... im at the stage now where really its libnvddk_2d_v2.so and libnvrm_graphics.so that seem to be the ones that cause no boot.. same as tests ive done before ..

Share this post


Link to post
Share on other sites

Good luck mate .. get your rest ...

Im puzzled as to why the A500 and the Xoom do not have this issue, cant find the A500 source from the working build posted earlier on TegraOwners forum but they appear to be using the 2.6.36.4 kernel (2.6.36.4-thor-V3.9r7) .. got from that from a strings on the boot.img, cant find it on github or other such place... The libs have the same results on our hardware platform as the xoom ones, suspect they are the same as the xoom ones but ive not compared them at the binary level ... I have mixed and matched a pile depending on the libs that contain the functions each panic complains about ... im at the stage now where really its libnvddk_2d_v2.so and libnvrm_graphics.so that seem to be the ones that cause no boot.. same as tests ive done before ..

Chipset - wise, both xoom, shuttle and A500 share exactly the same tegra2 chip.. But, there is a difference... The amount of SDRAM that each device has... I have isolated the problem to libnvrm.so ... That library is the (lib nv= nvidia rm=resource manager) responsible of allocating gpu memory for graphics and omx related things. If i replace libnvrm.soby a VC3.2 version, the android system does not display anything, but... omx works... How do i know that ? -because i wrote an small app that uses omx without using the android layer... With our green-fix libraries, omx does not work, and returns outofresources.

libnvrm.so internally uses the nvmap and knvmap drivers, and those drivers are configured by platform data .. So, i am investigationg if the problem is an incorrect configuration of nvmap... Curiosity aside, most .36/.39 ports are based on my original shuttle support, so, perhaps, they all have the same "bug" ? ;)

Is there any interest in me posting the omx test tool ? -- Its ugly code, and don't expect to get some sort of display from it, but, it does not depend on the android subsystem, so it is much easier to debug and strace() ....

Share this post


Link to post
Share on other sites

Chipset - wise, both xoom, shuttle and A500 share exactly the same tegra2 chip.. But, there is a difference... The amount of SDRAM that each device has... I have isolated the problem to libnvrm.so ... That library is the (lib nv= nvidia rm=resource manager) responsible of allocating gpu memory for graphics and omx related things. If i replace libnvrm.soby a VC3.2 version, the android system does not display anything, but... omx works... How do i know that ? -because i wrote an small app that uses omx without using the android layer... With our green-fix libraries, omx does not work, and returns outofresources.

libnvrm.so internally uses the nvmap and knvmap drivers, and those drivers are configured by platform data .. So, i am investigationg if the problem is an incorrect configuration of nvmap... Curiosity aside, most .36/.39 ports are based on my original shuttle support, so, perhaps, they all have the same "bug" ? ;)

Is there any interest in me posting the omx test tool ? -- Its ugly code, and don't expect to get some sort of display from it, but, it does not depend on the android subsystem, so it is much easier to debug and strace() ....

Hi,

Thanks for the explanation, makes sense given we have half the ram they do and by the results ive gotten .. sure post up the test lib, i may find something else to add to the mix using it but if the problem is as you think, at the platform data level then i dont expect to be of much help as i dont know the hw at that level, never mind the code you wrote :/ ... Pershoot may get something out of it though ..

Cheers

Cass

Share this post


Link to post
Share on other sites

Finally some kind of advance... Comparing the Xoom platform data related to nvmap and framebuiffers, i found xoom is using a 32bit per pixel framebufer, and we are using 16 bpp instead. I changed ours to use 32bpp (and an extra 4Mb of RAM for the framebuffer), and now, omx has advanced a bit. No errors are shown, no failures... but it does not decode.... According to dmesg, all the required codecs were loaded into AVP, and also, they seem to be working.. Perhaps, this is the time to try that leaked xoom libraries, as i do suspect the problem is caused by the mixing of libs... *.axf,*.bin and libnvomx* / libnvmm* and libnvrm.so must match...

If you want to try HC libs, please remember to patch libmedia ... otherwise omx won't load. .

Also attached the omx tests i wrote ... messy code, but should not give any errors if omx is working... omx_play and demo_decode are already compiled... don-t bother trying to recompile them ... unless you plan to change them...

patch2.6.39-jan13.rar

framework403.rar

omx.rar

Share this post


Link to post
Share on other sites

Finally some kind of advance... Comparing the Xoom platform data related to nvmap and framebuiffers, i found xoom is using a 32bit per pixel framebufer, and we are using 16 bpp instead. I changed ours to use 32bpp (and an extra 4Mb of RAM for the framebuffer), and now, omx has advanced a bit. No errors are shown, no failures... but it does not decode.... According to dmesg, all the required codecs were loaded into AVP, and also, they seem to be working.. Perhaps, this is the time to try that leaked xoom libraries, as i do suspect the problem is caused by the mixing of libs... *.axf,*.bin and libnvomx* / libnvmm* and libnvrm.so must match...

If you want to try HC libs, please remember to patch libmedia ... otherwise omx won't load. .

Also attached the omx tests i wrote ... messy code, but should not give any errors if omx is working... omx_play and demo_decode are already compiled... don-t bother trying to recompile them ... unless you plan to change them...

Thanks .. ill take a look at this later when i have some time ..

Cass

Share this post


Link to post
Share on other sites

This may not relate to the sleep/resume problem on ics build but noticed some amendments to the sleep files in mach-tegra, these are part of the amartin/chromeos3 nvidia git but changes could be relevant to the 39 kernel files also.

Omit L2 flush for LP2 nvidia commit

The files in the commit were not updated on wooshy1 git or the 39 tree as the new commit is dated november the last commit to 39 for sleep was october.

This may also be worth looking at ?:-

set gpio as wake up source nvidia commit

Edited by brucelee666

Share this post


Link to post
Share on other sites

Finally some kind of advance... Comparing the Xoom platform data related to nvmap and framebuiffers, i found xoom is using a 32bit per pixel framebufer, and we are using 16 bpp instead. I changed ours to use 32bpp (and an extra 4Mb of RAM for the framebuffer), and now, omx has advanced a bit. No errors are shown, no failures... but it does not decode.... According to dmesg, all the required codecs were loaded into AVP, and also, they seem to be working.. Perhaps, this is the time to try that leaked xoom libraries, as i do suspect the problem is caused by the mixing of libs... *.axf,*.bin and libnvomx* / libnvmm* and libnvrm.so must match...

If you want to try HC libs, please remember to patch libmedia ... otherwise omx won't load. .

Also attached the omx tests i wrote ... messy code, but should not give any errors if omx is working... omx_play and demo_decode are already compiled... don-t bother trying to recompile them ... unless you plan to change them...

Ok as you say there is definate progress ... with the green flash libs we load EGL perfectly it seems on boot, no more bitching about preferred version 1 loading version 4 instead or something similar ... but .. Xoom libs and Chines leak build libs appear one in the same ... They all fail to load the EGL properly and usually die in surfaceflinger or something like that.

with green flash libs as base and mixing omx and rm libs still fail on boot and still fail at the same point with libnvrm_graphics.so etc ... even when changing out the firmware files ....

but ... the closest working appears to be the green flash libs, no complaints at all but indeed as you mention does not decode ... results below show decode with green flash libs.. (with or without the Xoom axf files)

Chinese leak libnvomx and google release libnvomx.so (same file)

===================================================

I/OMXCodec( 99): [OMX.Nvidia.h264.decode] AVC profile = 100 (High), level = 31

I/OMXCodec( 99): [OMX.Nvidia.h264.decode] video dimensions are 1280 x 720

I/OMXCodec( 99): [OMX.Nvidia.h264.decode] Crop rect is 1280 x 720 @ (0, 0)

E/OMXCodec( 99): [OMX.Nvidia.h264.decode] ERROR(0x80001000, 2)

translates to

+ /** There were insufficient resources to perform the requested operation */

+ OMX_ErrorInsufficientResources = (OMX_S32) 0x80001000,

green flash libnvomx

====================

I/OMXCodec( 99): [OMX.google.h264.decoder] AVC profile = 100 (High), level = 31

I/OMXCodec( 99): [OMX.google.h264.decoder] video dimensions are 320 x 240

I/OMXCodec( 99): [OMX.google.h264.decoder] Crop rect is 320 x 240 @ (0, 0)

E/SoftAVC ( 99): Decoder failed: -2

E/OMXCodec( 99): [OMX.google.h264.decoder] ERROR(0x80001001, -1007)

E/MediaPlayer( 957): error (1, -2147483648)

E/MediaPlayer( 957): Error (1,-2147483648)

translates to

+ /** There was an error, but the cause of the error could not be determined */

+ OMX_ErrorUndefined = (OMX_S32) 0x80001001,

Interestingly if you compare, the Xoom lib seems more proper as its trying to render at 720, the green flash is not... Ive not looked too much into the rest of the stuff you provided as ive been short of time today .. probably have some more over the course of the w/e..

Cheers

Cass<br>

Edited by Cass67

Share this post


Link to post
Share on other sites

This may not relate to the sleep/resume problem on ics build but noticed some amendments to the sleep files in mach-tegra, these are part of the amartin/chromeos3 nvidia git but changes could be relevant to the 39 kernel files also.

Omit L2 flush for LP2 nvidia commit

The files in the commit were not updated on wooshy1 git or the 39 tree as the new commit is dated november the last commit to 39 for sleep was october.

This may also be worth looking at ?:-

set gpio as wake up source nvidia commit

Tried both commits, some code we already had .. i added / removed what was contained that was required and it made no diff here.. still same results ... keep trying though, good to have another set of eyes helping out :)

edit . may be worth looking to see if there is anything you can spot in LP1 that we dont have .. thats what we use ..

Cheers

Cass

Edited by Cass67

Share this post


Link to post
Share on other sites

Actually tried the HC libs this morning. does not boot, patched libmedia also with what you provided.

E/OMXMaster( 99): OMX plugin failed w/ error 0x80001001 after registering 0 components

Just loops ... something is missing its the same error code as the newer libs ..

Cass

Edited by Cass67

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

×

Important Information

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