Advent Vega kernel source code now available!

[Guest ejtagle]

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 February 6, 2013 by ejtagle

[Guest fosser2]

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/redeyedjedi/android_device_smba1002/commit/571e2a015d6b4593995f5a458d470cd969f6fbcd

Edited February 6, 2013 by fosser2

[Guest ejtagle]

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 February 6, 2013 by ejtagle

[Guest fosser2]

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.

[Guest ejtagle]

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

[Guest 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... ;)

libbt-hci.rar

[Guest joilaroi]

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

[Guest ejtagle]

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

[Guest joilaroi]

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

[Guest ejtagle]

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

[Guest 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?

folio-dmesg.txt

folio-logcat.txt

Edited February 9, 2013 by DerArtem

[Guest ejtagle]

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

[Guest DerArtem]

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.

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

[Guest ejtagle]

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

[Guest fosser2]

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.

[Guest ejtagle]

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 February 11, 2013 by ejtagle

[Guest fosser2]

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 February 12, 2013 by fosser2

[Guest DerArtem]

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 :/

[Guest ejtagle]

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 February 13, 2013 by ejtagle

[Guest 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 February 13, 2013 by DerArtem

[Guest ejtagle]

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

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

# CONFIG_BT_L2CAP is not set

# CONFIG_BT_SCO is not set

# CONFIG_BT_RFCOMM is not set

# CONFIG_BT_RFCOMM_TTY is not set

# CONFIG_BT_BNEP is not set

# CONFIG_BT_BNEP_MC_FILTER is not set

# CONFIG_BT_BNEP_PROTO_FILTER is not set

# CONFIG_BT_HIDP is not set

Also attached, for reference, the userial_vendor.c I am using...

userial_vendor.rar

userial.rar

[Guest Scanno]

Eduardo,

I asked in the google android forum about support for other bt chipsets. I got the answer below:

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

Bluedroid does support other chipsets. Nexus 4 uses Qualcomm Bluetooth controller. You can take it as an example.

Multi-channel transport is supported. Please see: external/bluetooth/bluedroid/hci/src/hci_mct.c

All the source codes are provided.

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

I am sure you haad a look thus, but just in case....

[Guest ejtagle]

Eduardo,

I asked in the google android forum about support for other bt chipsets. I got the answer below:

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

Bluedroid does support other chipsets. Nexus 4 uses Qualcomm Bluetooth controller. You can take it as an example.

Multi-channel transport is supported. Please see: external/bluetooth/bluedroid/hci/src/hci_mct.c

All the source codes are provided.

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

I am sure you haad a look thus, but just in case....

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

[Guest fosser2]

Hey ejtagle,

I'm wondering what the function of the file "board-shuttle-bootinfo.c" is. I'm trying to figure out if it will help our tablet or if its just for debugging purposes. Thanks!

[Guest ejtagle]

Hey ejtagle,

I'm wondering what the function of the file "board-shuttle-bootinfo.c" is. I'm trying to figure out if it will help our tablet or if its just for debugging purposes. Thanks!

Debugging purposes, only... ;)