Announcements

ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.

Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

We had 2 the same and 6 different. I swapped out all 8 for the ones on scanno's git and like magic sleep is working... I'm just happy its finally working again :)

I really really appreciate the help you guys are on this thread!

EDIT: guess not... Ok this might sound crazy but I have to watch a video FIRST before I attempt to sleep my tablet. If I reboot my tablet and put it to sleep right away it does the sleep loop. As soon as I watch a video and then sleep its fine until I restart again. Ejtagle do you have any thoughts on this?

Well, the AVP processor is initialized the first time you see a video... Before that, it should be on a reset state... Quite strange, i may say... Either a kernel bug (perhaps we also have this issue, as there are reports of non sleeping vegas... But, when you stop watching videos, then the AVP is reset ... This seems to be an actual bug on the avp code..

Either we force to load the AVP firmware (just an small app loading openMax), or we figure out how to fix the AVP driver (perhaps calling the uninitialization code at startup...) ...

The other option is to disable timer2 until the first firmware load command... ;)

Edited 6 Feb 2013 by ejtagle

0

Share this post

Link to post

Share on other sites

Well, the AVP processor is initialized the first time you see a video... Before that, it should be on a reset state... Quite strange, i may say... Either a kernel bug (perhaps we also have this issue, as there are reports of non sleeping vegas... But, when you stop watching videos, then the AVP is reset ... This seems to be an actual bug on the avp code..

Either we force to load the AVP firmware (just an small app loading openMax), or we figure out how to fix the AVP driver (perhaps calling the uninitialization code at startup...) ...

The other option is to disable timer2 until the first firmware load command... ;)

Is there any other known working nvrm_avp.bin files that I could try? The issue seems to lie within that file. I also removed the other 7 files and it doesn't seem like they are used at all. Could you tell me their function? Lastly I tried the Xoom nvrm_avp.bin file but that broke youtube and videos. Sleep did work though.... This seems to be a pretty touchy issue since we are dealing w/ these bins.

EDIT: you can tell on startup of the tablet AVP is initialized. It seems the main difference between playing an actual video file and AVP on startup is the following:

Share this post

Link to post

Share on other sites

Well, the AVP processor is initialized the first time you see a video... Before that, it should be on a reset state... Quite strange, i may say... Either a kernel bug (perhaps we also have this issue, as there are reports of non sleeping vegas... But, when you stop watching videos, then the AVP is reset ... This seems to be an actual bug on the avp code..

Either we force to load the AVP firmware (just an small app loading openMax), or we figure out how to fix the AVP driver (perhaps calling the uninitialization code at startup...) ...

The other option is to disable timer2 until the first firmware load command... ;)

The main difference between all those .bin files is the load address... AVP mmu is used to relocate memory, so the 00001000 is the one being used. It must match the nvidia proprietary libs. Mixes usually don't work...

As a curiosity, avp_*.bin is a pseudo OS that allows dynamic loading of modules (*.axf) ,,, It is like the BIOS of the AVP processor...

If you don't use the TEGRA_AVP_KERNEL_ON_MMU, then the other avp_*.bin come into play. Memory is allocated from carveout, and carveout MUST start at the address specified by the .bin file to be able to be used...

Edited 6 Feb 2013 by ejtagle

0

Share this post

Link to post

Share on other sites

The main difference between all those .bin files is the load address... AVP mmu is used to relocate memory, so the 00001000 is the one being used. It must match the nvidia proprietary libs. Mixes usually don't work...

As a curiosity, avp_*.bin is a pseudo OS that allows dynamic loading of modules (*.axf) ,,, It is like the BIOS of the AVP processor...

I guess there are 2 reasons I'm asking that. One the xoom only has nvrm_avp.bin and none of the other ones. Secondly I kept our original nvrm_avp.bin and deleted the rest of the files. Video still worked just fine, HD/SD. So I'm just kind of curious myself. Hopefully this "bug" will help solve the issues you've had with some of the vegas not sleeping.

1

Share this post

Link to post

Share on other sites

I guess there are 2 reasons I'm asking that. One the xoom only has nvrm_avp.bin and none of the other ones. Secondly I kept our original nvrm_avp.bin and deleted the rest of the files. Video still worked just fine, HD/SD. So I'm just kind of curious myself. Hopefully this "bug" will help solve the issues you've had with some of the vegas not sleeping.

BTW, the Xoom libraries are no example of anything. Motorola never updated to the latest kernel, in fact, they foward ported the video subsystem of 2.6.36 to 2.6.39... And Proprietary libs used there are targeting that mix. Of cause, if it works for you, great! :) ... Maybe at AVP kernel side, they are up to date, but i dont know ... (make sure it is actually using hw acceleration... If it does not say Nvidia in the logcats when opening video, then you are using sw decoding... (instead of Nvidia, it will say google... )

0

Share this post

Link to post

Share on other sites

Regarding Bluetooth, i finally had time to end the required libbt-vendor that is required to interface our BCSP based chip to the bluedroid. It should also work for AR6003. The library compiles, but is untested. I will start testing it myself and debug it from now on. But, Ill post the lib as it is right now, so if someone also wants to try it... ;)

Share this post

Link to post

Share on other sites

Regarding Bluetooth, i finally had time to end the required libbt-vendor that is required to interface our BCSP based chip to the bluedroid. It should also work for AR6003. The library compiles, but is untested. I will start testing it myself and debug it from now on. But, Ill post the lib as it is right now, so if someone also wants to try it... ;)

Hi ejtagle.

I've been following your work for some time because of ar6000 wifi and bt.

In your libbt-vendor folder there is a conf folder for your csr_tegra. Should I use this conf with Type = hci?

Thanks for your libs and work.

Best regards

No, you don't need to add anything to *.rc. I have already integrated the hciattach/nv_hciattach and bccmd functionality into the libbt-vendor (it was the only way to sync initialization with bluedroid).

abtfilt is a problem, right now. abtfilt is used to "tune" wifi parameters to make bt/wifi coexistence smoother.. But, abtfilt uses DBus to detect if Bluetooth is active or not. When Google replaced bluez by bluedroid, it was also removing DBus as the communication channel between the framework and the bt stack. So, now with bluedroid, abtfilt will not be able to detect that bt is active. We will have to try... maybe things work without abtfilt. The other possibility is to integrate abtfilt into libbt-vendor ...

Type = hci is used for those wifi/bt combo drivers that expose an HCI interface, without using an UART to communicate with the bt part of the combo. That is the exact case of the ar6003, as was pointed out by DerArtem. When you set Type = HCI, the only other thing that you need to set is the HCIDevice to n, where n is HCIn, or the index of the HCI netlink interface to use...

1

Share this post

Link to post

Share on other sites

No, you don't need to add anything to *.rc. I have already integrated the hciattach/nv_hciattach and bccmd functionality into the libbt-vendor (it was the only way to sync initialization with bluedroid).

abtfilt is a problem, right now. abtfilt is used to "tune" wifi parameters to make bt/wifi coexistence smoother.. But, abtfilt uses DBus to detect if Bluetooth is active or not. When Google replaced bluez by bluedroid, it was also removing DBus as the communication channel between the framework and the bt stack. So, now with bluedroid, abtfilt will not be able to detect that bt is active. We will have to try... maybe things work without abtfilt. The other possibility is to integrate abtfilt into libbt-vendor ...

Type = hci is used for those wifi/bt combo drivers that expose an HCI interface, without using an UART to communicate with the bt part of the combo. That is the exact case of the ar6003, as was pointed out by DerArtem. When you set Type = HCI, the only other thing that you need to set is the HCIDevice to n, where n is HCIn, or the index of the HCI netlink interface to use...

So if im using ar6000/ar6002 I should use Type = csr_tegra? I dont have a *.psr file.

I am experiencing the same problems as you... Everything seems fine but it does not work...I am starting to think thatperhaps i am missing some initialization steps, such as upping the hci interface... I will check that... ;)

No, it is just fine. The graphic stuff just starts before the permissions have been set. But this is not a problem since it get's restarted later.

I am experiencing the same problems as you... Everything seems fine but it does not work...I am starting to think thatperhaps i am missing some initialization steps, such as upping the hci interface... I will check that... ;)

Yeah, it would be nice if you could check what's wrong with bluetooth...

Share this post

Link to post

Share on other sites

No, it is just fine. The graphic stuff just starts before the permissions have been set. But this is not a problem since it get's restarted later.

Yeah, it would be nice if you could check what's wrong with bluetooth...

I am still reading the hci kernel code... What we are trying to achieve is to bypass the bluez kernel modules that implement part of the bluetooth stack, and get a raw socket to the HCI layer... According to what i have read so far, this is perfectly possible... Maybe i am missing to add a

/* Set the socket to RAW */

if (ioctl(vnd_netlink.fd, HCISETRAW, 1) < 0) {

LOGE("Can't access device");

}

at the end of the userial_vendor_open function, that is the one that opensthe raw socket to the HCI layer...

0

Share this post

Link to post

Share on other sites

BTW, the Xoom libraries are no example of anything. Motorola never updated to the latest kernel, in fact, they foward ported the video subsystem of 2.6.36 to 2.6.39... And Proprietary libs used there are targeting that mix. Of cause, if it works for you, great! :) ... Maybe at AVP kernel side, they are up to date, but i dont know ... (make sure it is actually using hw acceleration... If it does not say Nvidia in the logcats when opening video, then you are using sw decoding... (instead of Nvidia, it will say google... )

Hey ejtagle,

I'm just wondering where you guys got your prop. files from? Just yesterday I redownloaded the Ventana ICS image and dumped the libs out of that. I then hex compared them to mine and they were the same. Since our libs are different I was wondering where you got them because obviously they aren't from the Ventana ICS image.

0

Share this post

Link to post

Share on other sites

Hey ejtagle,I'm just wondering where you guys got your prop. files from? Just yesterday I redownloaded the Ventana ICS image and dumped the libs out of that. I then hex compared them to mine and they were the same. Since our libs are different I was wondering where you got them because obviously they aren't from the Ventana ICS image.

No they are not. I seem to remember we had troubles with the ventana libs.. Specifically, because there was a bug in the openGL ES implementation that causedtexture corruptions if the texture size was big enoygh (in our cse, if the txture was the screen size. And that caused troubles with rotation... When the tablet wasin portrait mode, the android desktop was shown vertically compressed to half the real height...After fighting against that issue, and testing lots of other libs, i seem to remember we settled down into the libs used with the asus transformer... Those libs fixed our problems, as far as i can remember, and they were the last ICS image officially released by a manufacturer for a Tegra2 device...
Edited 11 Feb 2013 by ejtagle

1

Share this post

Link to post

Share on other sites

No they are not. I seem to remember we had troubles with the ventana libs.. Specifically, because there was a bug in the openGL ES implementation that causedtexture corruptions if the texture size was big enoygh (in our cse, if the txture was the screen size. And that caused troubles with rotation... When the tablet wasin portrait mode, the android desktop was shown vertically compressed to half the real height...After fighting against that issue, and testing lots of other libs, i seem to remember we settled down into the libs used with the asus transformer... Those libs fixed our problems, as far as i can remember, and they were the last ICS image officially released by a manufacturer for a Tegra2 device...

Ohh, ok thanks for that. Great to know!

EDIT: I was wondering if there was an "official" list of NEEDED libs and how you tested all of them to see if they worked. I really don't want to have to do this if its been done before. :)

Edited 12 Feb 2013 by fosser2

0

Share this post

Link to post

Share on other sites

I am still reading the hci kernel code... What we are trying to achieve is to bypass the bluez kernel modules that implement part of the bluetooth stack, and get a raw socket to the HCI layer... According to what i have read so far, this is perfectly possible... Maybe i am missing to add a

/* Set the socket to RAW */

if (ioctl(vnd_netlink.fd, HCISETRAW, 1) < 0) {

LOGE("Can't access device");

}

at the end of the userial_vendor_open function, that is the one that opensthe raw socket to the HCI layer...

I did an small modification (attached!) to the bluedroid library, to add debug dumps on reads and writes of the HCI channel. After deselecting the following options in the kernel config, i seem to be getting answers to the queries of the bluedroid stack :) -- Nevertheless, something seems to be missing. Maybe you will be luckier than me with the ar6003...

Yes, but Qualcomm also supports H4. I wrote a utility that was supposed to switch our bt chipset to the H4 from the BCSP protocol, and found out that the rom inside the bt chipset does not support it - When trying to switch it to H$, the bt chip`just stops responding.

I have written a h4 to linux kernel HCI layer, and i got some sort of pseudo working thing... But bluedroid stack seems to talk to the chip, but something seems to be missing... I still have to investigate this issue a little bit more ...