2850 replies to this topic

[ejtagle]

fosser2, on 06 February 2013 - 04:38 PM, said:

Well... you are very right...

I diffed our 8 avp related bins

nvrm_avp.bin
nvrm_avp_0ff00000.bin
nvrm_avp_8e000000.bin
nvrm_avp_9e000000.bin
nvrm_avp_00001000.bin ==
nvrm_avp_be000000.bin
nvrm_avp_e0000000.bin ==
nvrm_avp_eff00000.bin

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?

http://pastebin.com/LcmkjDEH

Lines 1081-3250 = Before video
Lines 3293-3407 = Video
Lines 3409-3493 = SLEEP
Line 3499 = Proof it stayed in LP1

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 by ejtagle, 06 February 2013 - 06:39 PM.

[fosser2]

ejtagle, on 06 February 2013 - 06:31 PM, said:

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:

<6>avp_svc_thread: AVP seems to be down; wait for kthread_stop

<6>avp_svc_thread: exiting

<6>avp_uninit: avp teardown done

Any thoughts on why AVP appears to be crashing on unload?


EDIT2: here is what we did to "fix" the problem for now...
https://github.com/r...d470cd969f6fbcd

Edited by fosser2, 06 February 2013 - 09:26 PM.

[ejtagle]

ejtagle, on 06 February 2013 - 06:31 PM, said:

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 by ejtagle, 06 February 2013 - 11:36 PM.

[fosser2]

ejtagle, on 06 February 2013 - 11:18 PM, said:

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.

[ejtagle]

fosser2, on 06 February 2013 - 11:37 PM, said:

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... )

[ejtagle]

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...

Attached Files

•  libbt-hci.rar   62.13K   7 downloads

[joilaroi]

ejtagle, on 07 February 2013 - 02:15 AM, said:

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.

Im gonna try your libbt-vendor for my ar6000 bluetooth. Do I need to add anything to init.board.rc besides permissions? Is abtfilt necessary?
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

[ejtagle]

joilaroi, on 07 February 2013 - 10:43 AM, said:

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

Im gonna try your libbt-vendor for my ar6000 bluetooth. Do I need to add anything to init.board.rc besides permissions? Is abtfilt necessary?
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...

[joilaroi]

ejtagle, on 07 February 2013 - 12:00 PM, said:

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 tried the ZTE Blade way of loading bt but it didnt work.

Thanks for your help!!!!

[ejtagle]

joilaroi, on 07 February 2013 - 12:11 PM, said:

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

I tried the ZTE Blade way of loading bt but it didnt work.

Thanks for your help!!!!

Try without the psr file. If it does not work, you could use the one in vegacomb... it is for the ar6002 ...

[DerArtem]

Hello,

I have tried the libbt-hci on the folio, but it does not work.
Attached are the logfiles.

Any idea what might be wrong?

Attached Files

•  folio-dmesg.txt   30.56K   4 downloads
•  folio-logcat.txt   178.53K   1 downloads

Edited by DerArtem, 09 February 2013 - 07:24 PM.

[ejtagle]

DerArtem, on 08 February 2013 - 01:54 PM, said:

Hello,

I have tried the libbt-hci on the folio, but it does not work.
Attached are the logfiles.

Any idea what might be wrong?

Random thoughts...you are probably missing permissions on /dev/nvhost-ctrl  .. That is why you are getting graphics errors... Check your ramdisk and udev config 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...

[DerArtem]

ejtagle, on 09 February 2013 - 04:17 PM, said:

Random thoughts...you are probably missing permissions on /dev/nvhost-ctrl  .. That is why you are getting graphics errors... Check your ramdisk and udev config file...

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.

ejtagle, on 09 February 2013 - 04:17 PM, said:

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...

[ejtagle]

DerArtem, on 09 February 2013 - 07:20 PM, said:

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...

[fosser2]

ejtagle, on 07 February 2013 - 12:53 AM, said:

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.

[ejtagle]

fosser2, on 10 February 2013 - 07:43 PM, said:

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 by ejtagle, 11 February 2013 - 04:14 AM.

[fosser2]

ejtagle, on 11 February 2013 - 04:11 AM, said:

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 by fosser2, 12 February 2013 - 04:44 AM.

[DerArtem]

ejtagle, on 10 February 2013 - 12:27 AM, said:

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...

Just tried that. Still does not work :/

[ejtagle]

DerArtem, on 12 February 2013 - 06:08 AM, said:

Just tried that. Still does not work :/

Try recompiling the kernel without l2cap/sco support. You just want raw hci sockets, and no other bluetooth layer on the kernel side interferring... I will also start debugging the problem...

I will also try it myself. And will also modify the userial_vendor_open to remove all fltering...


int userial_vendor_open(void)
{
struct sockaddr_hci a;
struct hci_filter flt;
    vnd_netlink.fd = -1;

    ALOGI("userial vendor open: opening hci%d", vnd_netlink.dev_id);

/* Create HCI socket */
vnd_netlink.fd = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI);
if (vnd_netlink.fd < 0) {
ALOGE("userial vendor open: Unable to open NETLINK socket");
return -1;
}

// Setup no filter
memset(&flt, 0, sizeof(flt));
memset((void *) &flt.type_mask, 0xff, sizeof(flt.type_mask));
memset((void *) &flt.event_mask, 0xff, sizeof(flt.event_mask));
if (setsockopt(vnd_netlink.fd, SOL_HCI, HCI_FILTER, &flt, sizeof(flt)) < 0) {
ALOGE("userial vendor open: HCI filter setup failed");
close(vnd_netlink.fd);
return -1;
}

// Bind socket to the HCI device */
memset(&a, 0, sizeof(a));
a.hci_family = AF_BLUETOOTH;
a.hci_dev = vnd_netlink.dev_id;
a.hci_channel = HCI_CHANNEL_RAW;

if (bind(vnd_netlink.fd, (struct sockaddr *) &a, sizeof(a)) < 0) {
ALOGE("userial vendor open: Unable to bind to open HCI%d device",vnd_netlink.dev_id);
close(vnd_netlink.fd);
return -1;
}

/* Set the socket to RAW */
if (ioctl(vnd_netlink.fd, HCISETRAW, 1) < 0) {
        ALOGE("Can't access device");
    }

    ALOGI("device fd = %d open", vnd_netlink.fd);

    return vnd_netlink.fd;
}

Edited by ejtagle, 13 February 2013 - 03:10 AM.

[DerArtem]

It look like the problem is somewhere else.

There is the bdt tool to test bluedroid. When enabeling BT and then disabling is says that BT is already disabled. Looks like BT is not getting marked as enabled correctly...

root@android:/ # bdt														
set_aid_and_cap : pid 1221, uid 0 gid 0
:::::::::::::::::::::::::::::::::::::::::::::::::::
:: Bluedroid test app starting
Loading HAL lib + extensions
HAL library loaded (Success)
INIT BT
HAL REQUEST SUCCESS
>enable
ENABLE BT
HAL REQUEST SUCCESS
>disable
DISABLE BT
Bluetooth is already disabled

I/bluedroid( 778): enable
D/bt-btif ( 778): BTIF ENABLE BLUETOOTH
D/BTIF_CORE( 778): not disabled
E/BluetoothAdapterState( 778): Error while turning Bluetooth On

I/bluedroid( 1197): init
D/btif_config.c( 1197): btif_config_init(L124): in initialized:0
D/bt-btif ( 1197): in initialized:0
D/btif_config.c( 1197): dump_node(L117): root, p->name:Bluedroid, child/value:0x40548588, bytes:160, p->used:0, type:0, p->flag:0
D/bt-btif ( 1197): ts[7].used:0
D/bt-btif ( 1197): alloc_thread_slot ret:7
D/bt-btif ( 1197): h:7, cmd_fdr:7, cmd_fdw:10
D/bt-btif ( 1197): h:7, thread id:1079281200
I/bte_conf( 1197): Attempt to load stack conf from /etc/bluetooth/bt_stack.conf
D/btif_config.c( 1197): dump_node(L117): found node, p->name:Address, child/value:0x405487f0, bytes:18, p->used:18, type:1, p->flag:0
D/bt-btif ( 1197): local bdaddr from bt_config.xml is  22:22:7e:b9:ed:31
I/GKI_LINUX( 1197): gki_task_entry: gki_task_entry task_id=1 [BTIF] starting
D/bt-btif ( 1197): btif task starting
D/bt-btif ( 1197): btif_associate_evt: notify ASSOCIATE_JVM
E/BTIF_CORE( 1197): ### ASSERT : external/bluetooth/bluedroid/main/../btif/src/btif_core.c line 487 Callback is NULL (0) ###
I/bluedroid( 1197): enable
D/bt-btif ( 1197): BTIF ENABLE BLUETOOTH
D/bt-btif ( 1197): bte_main_enable
I/bt_hci_bdroid( 1197): init
I/bt_vendor( 1197): init
I/bt_vnd_conf( 1197): Attempt to load conf from /etc/bluetooth/bt_vendor.conf
I/bt-btif ( 1197): libbt-hci init returns 0
I/bt_hci_bdroid( 1197): bt_hc_worker_thread started
I/GKI_LINUX( 1197): gki_task_entry: gki_task_entry task_id=0 [BTU] starting
I/bt_userial_vendor( 1197): userial vendor open: opening hci0
I/bt_userial_vendor( 1197): device fd = 11 open
E/bt_vendor( 1197): vendor lib fw conf done
I/bt-btif ( 1197): HC preload_cb 0 [0:SUCCESS 1:FAIL]
I/		( 1197): BTE_InitTraceLevels -- TRC_HCI
I/		( 1197): BTE_InitTraceLevels -- TRC_L2CAP
I/		( 1197): BTE_InitTraceLevels -- TRC_RFCOMM
I/		( 1197): BTE_InitTraceLevels -- TRC_AVDT
I/		( 1197): BTE_InitTraceLevels -- TRC_AVRC
I/		( 1197): BTE_InitTraceLevels -- TRC_A2D
I/		( 1197): BTE_InitTraceLevels -- TRC_BNEP
I/		( 1197): BTE_InitTraceLevels -- TRC_BTM
I/		( 1197): BTE_InitTraceLevels -- TRC_PAN
I/		( 1197): BTE_InitTraceLevels -- TRC_SDP
I/		( 1197): BTE_InitTraceLevels -- TRC_BTAPP
D/bt-btif ( 1197): btif_task: received trigger stack init event
I/bluedroid( 1197): enable
D/bt-btif ( 1197): BTIF ENABLE BLUETOOTH
D/BTIF_CORE( 1197): not disabled

Edited by DerArtem, 13 February 2013 - 07:59 PM.