• Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      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.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      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.

Advent Vega kernel source code now available!

2862 posts in this topic

Posted (edited)

I am also seeing this:


21:30:09.281 Info bluedroid 803 enable

21:30:09.281 Debug bt-btif 803 BTIF ENABLE BLUETOOTH

21:30:09.293 Debug bt-btif 803 bte_main_enable

21:30:09.317 Info bt_hci_bdroid 803 init

21:30:09.317 Error bt_hw 803 !!! Failed to load libbt-vendor.so !!!

21:30:09.317 Info bt-btif 803 libbt-hci init returns 0

21:30:09.317 Error bt_hci_bdroid 803 vendor lib is missing!

21:30:09.317 Error bt_hci_bdroid 803 vendor lib is missing!

21:30:09.317 Info bt_hci_bdroid 803 bt_hc_worker_thread started

21:30:09.317 Error bt_userial 803 userial_open: missing vendor lib interface !!!

21:30:09.317 Error bt_userial 803 userial_open: unable to open UART port

21:30:09.317 Info bt-btif 803 HC preload_cb 1 [0:SUCCESS 1:FAIL]

21:30:09.329 Debug bt-btif 803 btif_task: received trigger stack init event

21:30:11.348 Debug BluetoothAdapterService 1107362040 getState(): mAdapterProperties: com.android.bluetooth.btservice.AdapterProperties@42011a20

I am guessing we need to get libbt-vendor.so sources from somewhere....

We have those sources, if thats the problem! :) -- https://groups.googl...V7GXLZza0MJ��-- I'll see if something is needed ... AR6002 bt module does not need firmware to make it work, so this lib should be nearly trivial to implement... ;)

If you look at the places suggested at that post, you will find the definitions tor bluetooth for each supported device...

Edited by ejtagle
0

Share this post


Link to post
Share on other sites

Posted (edited)

We have those sources, if thats the problem! :) -- https://groups.googl...V7GXLZza0MJ��-- I'll see if something is needed ... AR6002 bt module does not need firmware to make it work, so this lib should be nearly trivial to implement... ;)

If you look at the places suggested at that post, you will find the definitions tor bluetooth for each supported device...

Thanks for the link. Will have a look at it. Hopefully I can find an implementation for the ar6002 that can be added to the device config.

Oh and 4.2.1 is out if yo did not know already.

EDIT:

Am I right in the assumption that atheros is part of Qualcomm? And us such we can use the Qualcomm implementation of the lib and add the line

BOARD_HAVE_BLUETOOTH_QCOM := true

To the board config. It should then compile the Qualcomm BT vendor lib if it is added to the device config (if it is not already part of the android download)

EDIT 2:

OK looks like it is part of the standard android repo. So it is just a matter of adding the line to the boardconfig. Can anybody confirm that Atheros = Qualcomm ?

Edited by Scanno
0

Share this post


Link to post
Share on other sites

Posted (edited)

Thanks for the link. Will have a look at it. Hopefully I can find an implementation for the ar6002 that can be added to the device config.

Oh and 4.2.1 is out if yo did not know already.

EDIT:

Am I right in the assumption that atheros is part of Qualcomm? And us such we can use the Qualcomm implementation of the lib and add the line

BOARD_HAVE_BLUETOOTH_QCOM := true

To the board config. It should then compile the Qualcomm BT vendor lib if it is added to the device config (if it is not already part of the android download)

EDIT 2:

OK looks like it is part of the standard android repo. So it is just a matter of adding the line to the boardconfig. Can anybody confirm that Atheros = Qualcomm ?

Even if they are not, most bluetooth chipsets use the same protocol (HCI), so probably it will work... or require very small adjustments... ;) -- But it would not hurt to make sure baudrate and serial port are the ones expected ...

Edited by ejtagle
0

Share this post


Link to post
Share on other sites

Posted

Even if they are not, most bluetooth chipsets use the same protocol (HCI), so probably it will work... or require very small adjustments... ;) -- But it would not hurt to make sure baudrate and serial port are the ones expected ...

Guess i spoke too soon.. Qualcomm bt libs will not work with our chip... Probably, the broadcom ones are much closer to what we need...

0

Share this post


Link to post
Share on other sites

Posted

The only way to make our bt chipset work with bluedroid, is to write a new lib for it... Basically, the bluedroid lib can use it through its HCI H4 driver, but our chip requires previous initialization ... That is what the hciattach utility did, but now we cant use it... I am working in porting the init code found in hciattach to the new required lib, but it will take some time... :S

0

Share this post


Link to post
Share on other sites

Posted

The only way to make our bt chipset work with bluedroid, is to write a new lib for it... Basically, the bluedroid lib can use it through its HCI H4 driver, but our chip requires previous initialization ... That is what the hciattach utility did, but now we cant use it... I am working in porting the init code found in hciattach to the new required lib, but it will take some time... :S

Thanks in advance for the effort. Hopefully it is not too much work.

I am still trying to get the backlight control working. Using the changes in the overlay did not work for me. But i will try some more combinations in the overlay config xml files.

0

Share this post


Link to post
Share on other sites

Posted

Thanks in advance for the effort. Hopefully it is not too much work.

I am still trying to get the backlight control working. Using the changes in the overlay did not work for me. But i will try some more combinations in the overlay config xml files.

The same thing relatedto backlight control happened to me with the n10 lunch target i was working with. The only thing required to make it work was to adjest the overlay entries with the ones i pasted here. There is an easy way to check if the lights module is properly loadingand being used: When androids boots, when the androd logo starts to roll, at nearly the end of the process, the backlight dims a bit... This happenede with the previous android versions and also happens with the new ones. If it does not dim, as it did on previous versions, there is something wrong with the lights module. If it dims, the problem is in the overlay... ;)

0

Share this post


Link to post
Share on other sites

Posted (edited)

The same thing relatedto backlight control happened to me with the n10 lunch target i was working with. The only thing required to make it work was to adjest the overlay entries with the ones i pasted here. There is an easy way to check if the lights module is properly loadingand being used: When androids boots, when the androd logo starts to roll, at nearly the end of the process, the backlight dims a bit... This happenede with the previous android versions and also happens with the new ones. If it does not dim, as it did on previous versions, there is something wrong with the lights module. If it dims, the problem is in the overlay... ;)

Thanks for the hint. lights.shuttle.so was not being build because of a := instead of a += <_<

Backlight working fine now.

Edited by Scanno
1

Share this post


Link to post
Share on other sites

Posted

Well... there good and bad news regarding bluetooth... As you know, bluedroid stack has replaced BlueZ stack as the main bluetooth stack on Android. This has several implications... Bluedroid was written by Broadcom, so, as you could imagine, there is essentially no support on it for other bluetooth solutions, such as all CSR chips out there (that use a USART protocol called BCSP). BCSP is the BlueChip Serial protocol, and it is used by some bluetooth chipsets such as the one the Shuttle is using.. :( ..

The stack supports an older protocol called H4, that is the one used by Broadcom. Even worse, in the original Bluez stack, the Bluetooth protocol (BCSP, or H4, or...) was / is implemented in kernel space, and also the power management of the chip, but in the new stack (Bluedroid), all the UART protocols are implemented in the stack itself... So, the bluetooth UART protocol implemented in kernel is not used at all...

There is some things missing in the bt stack (BT4.0 can't be enabled, as there are missing files!) .. What i fear is that this is a move to favour Broadcom some way.... Implementing their chip solutions is straightforward, but implementing all the other bluetooth chipsets usually requires reimplementing a lot of the stack code... I guess Broadcom even will license the complete stack, instead of the incomplete one we are given through AOSP to those manufacturers that use their chips...

I will see what can i do about BCSP on the bluedroid stack...

0

Share this post


Link to post
Share on other sites

Posted (edited)

Well, an update on the bluedroid stack.... I've been lately toying with 2 alternate solutions, both seem to be feasible:

1) Write a new module to implement the bcsp protocol, then add a libbt-vendor that instanciates that module... That would keep the all-in-userspace feature of the bluedroid stack, and would allow us to use a CSR bluetooth chipset.

2) The other possibility is to write a new module for the bluedroid stack that uses the linux kernel bluetooth subsystem (that is already implementing all the usart protocols we need, inclusing BCSP)... This is also perfecly possible, and would move a part of the processing (the usart protocol) to kernel space. That is the way blueZ works (uses the kernel bluetooth subsystem, instead of implementing it in userland, as bluedroid does). Yes, even if broadcom tells otherwise, i think it is more clean to use the linux kernel bluetooth subsystem, and would allow more bluetooth devices to work with bluedroid.

My personal opinion on BlueZ compared to bluedroid is that BlueZ is a far more clean and documented piece of code that bluedroid. By just looking at the bluedroid stack, you will find it to be of less quality than BlueZ.. The only explanation i find for this switch is that Google either has a cooperation agreement with Broadcom, or they just don't want to maintain and update the blueZ stack, and it was easier to switch to the supposedly more complete Broadcom supplied one...

I really don't care about the reasons, I really don't care if we need to hack the bluedroid stack to interface with CSR. Just, I would like that the chosen approach let us use the bluedroid stack with the CSR chips... And, the broader chip compatibility we could get, the better.

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack... ;) ... badword you Broadcom! (badword = censored word... I really hate when there is no apparent reason for the switch besides "lack of knowledge" ... or maybe commercial reasons, and that decision does not bring us any advantage, except a lot of work to port to the new stack ,,, :S :S )

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

Edited by ejtagle
0

Share this post


Link to post
Share on other sites

Posted

Well, an update on the bluedroid stack.... I've been lately toying with 2 alternate solutions, both seem to be feasible:

1) Write a new module to implement the bcsp protocol, then add a libbt-vendor that instanciates that module... That would keep the all-in-userspace feature of the bluedroid stack, and would allow us to use a CSR bluetooth chipset.

2) The other possibility is to write a new module for the bluedroid stack that uses the linux kernel bluetooth subsystem (that is already implementing all the usart protocols we need, inclusing BCSP)... This is also perfecly possible, and would move a part of the processing (the usart protocol) to kernel space. That is the way blueZ works (uses the kernel bluetooth subsystem, instead of implementing it in userland, as bluedroid does). Yes, even if broadcom tells otherwise, i think it is more clean to use the linux kernel bluetooth subsystem, and would allow more bluetooth devices to work with bluedroid.

My personal opinion on BlueZ compared to bluedroid is that BlueZ is a far more clean and documented piece of code that bluedroid. By just looking at the bluedroid stack, you will find it to be of less quality than BlueZ.. The only explanation i find for this switch is that Google either has a cooperation agreement with Broadcom, or they just don't want to maintain and update the blueZ stack, and it was easier to switch to the supposedly more complete Broadcom supplied one...

I really don't care about the reasons, I really don't care if we need to hack the bluedroid stack to interface with CSR. Just, I would like that the chosen approach let us use the bluedroid stack with the CSR chips... And, the broader chip compatibility we could get, the better.

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack... ;) ... badword you Broadcom! (badword = censored word... I really hate when there is no apparent reason for the switch besides "lack of knowledge" ... or maybe commercial reasons, and that decision does not bring us any advantage, except a lot of work to port to the new stack ,,, :S :S )

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

Eduardo,

I am just very happy that you want to try getting BT working on our devices. If i understand correctly, you want to interface the Bluedroid API with the kernel bluetooth subsystem?

I think it could be the best solution, using the parts that we know work.

0

Share this post


Link to post
Share on other sites

Posted

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

0

Share this post


Link to post
Share on other sites

Posted

Eduardo,

I am just very happy that you want to try getting BT working on our devices. If i understand correctly, you want to interface the Bluedroid API with the kernel bluetooth subsystem?

I think it could be the best solution, using the parts that we know work.

Yes, that is exactly the idea... Careful inspection of the bluedroid stack shows that this stack was written for an embedded system, where there is no kernel support for bluetooth (bare-bones embedded systems are like that... And probably, that was a good decision on Broadcom side, as they were licensing the stack to virtually anyone using their chips, and the stack does not target a given OS... Under linux, the OS is the one that should handle differences between hardware, and expose a unified view to the user space. That is why the bluetooth low level protocol (the communication to the chip) is done at kernel level.. and the chip is exposed to user space as a network adapter... Makes pretty good sense to me.. So, i think interfacing bluedroid to that subsystem can be the way to do it... I will try to test this! :)

0

Share this post


Link to post
Share on other sites

Posted

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

Maybe a permission thing... On the N10, it worked out of the box. Remember the data partition is on nand, not on SD... Unless we natively mount the sdcard, it wont work... And, SDcard takes some time to be recognized... Maybe adding a bootdelay=2 in the kernel command line could help here?

0

Share this post


Link to post
Share on other sites

Posted

I do not know what i am doing wrong. I am trying to get the multi-user stuff working. Overlay is correct and the multi-user is added. I just cannot get the sdcard to mount correctly. I have used the values from the init.grouper.rc (EXTERNAL-STORAGE, EMULATED-STORAGE-SOURCE and EMULATED-STORAGE-TARGET). I also experimented with the values and with vold.fstab to mount the sdcard on several directories, but the /0/ directories are not added to the sdcard. I have been trying for a few days but no luck so far.

The grouper has the internal sdcard as virtual sdcard. In the init.grouper.rc the virtual sdcard is mounted to /mnt/shell/...

If i set vold.fstab to mount the sdcard to that directory it does not get mounted. I am lost. Anyone have ideas?

I am trying to fix this on Adam tablet for a whole week and still no success. Problem is that once sdcard daemon is trying to create the /mnt/shell/emulated/0 which is in rootfs / is mounted as ro already.

@eduardo do you have an advice where sdcard should be started or how to leave rootfs mounted as rw, since later during creation of new user its creating a new dir?

0

Share this post


Link to post
Share on other sites

Posted

I am trying to fix this on Adam tablet for a whole week and still no success. Problem is that once sdcard daemon is trying to create the /mnt/shell/emulated/0 which is in rootfs / is mounted as ro already.

@eduardo do you have an advice where sdcard should be started or how to leave rootfs mounted as rw, since later during creation of new user its creating a new dir?

So basically you have the same problem i have..

You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

0

Share this post


Link to post
Share on other sites

Posted (edited)

So basically you have the same problem i have..

You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

Actually I have done some experiments remounting after boot and actually different users has folders in /data/media/ and pictures and other media are stored on data partition and in my case I have internal sd and external sd :) So my setup should be little different.

Edited by Borkata
0

Share this post


Link to post
Share on other sites

Posted

I think that i will write the module that interfaces to the linux bluetooth subsystem. I think it is the best approach here. And, as an added bonus, this would also allow us to continue using the hciattach tool that is part of the blueZ stack...

...

Any thoughts or suggestions or good reasons not to proceed with this solution (or reasons to proceed with it) are welcome!

ejtagle,

while I am a newbie and definitly not in a position to give advice to the gurus, I think this definitly is the way to go:

- I suspect such a work can enable BT for 4.2 not only on the Vega and relatives, but on lots of devices

- Kernel agnosticy is of no importance for Android. I consider it a misfeature - code duplication on a really stupid scale

- The possibility to use the hci tools will help porting lots of hack-scripts out there, that may not be beautifull, but scratch some dev's itch

0

Share this post


Link to post
Share on other sites

Posted (edited)

So basically you have the same problem i have..

You can leave rootfs as rw by commenting the remount in init.rc i think. But somehow i do not think it would solve the problem.

I have fixed it already. You can check last commit at https://github.com/n...on/tree/jb-aosp

Btw do you have mic workin?

Edited by Borkata
0

Share this post


Link to post
Share on other sites

Posted

Well, i am still investigating Bluedroid stack. Not only the serial protocol (BCSP or H$) is handled in userspace.. Seems all the scheduling of packets is handled in userspace. Bluez handles packet routing in kernel, allowing much more separation between servers (a2dp, internet sharing, etc)... Even, if there is a way to plug the datastream in bluedroid from the bluetooth stack in kernel (i already have a half written module...), i think that using bluedroid will be a huge step back regarding CSR support... Bluez has several workarounds in place to support most bluetooth chipsets out there, not only in kernel space, but also in the bluez daemon itself. Bluedroid has none of those: Has only workarounds for the broadcom chipset. Right now, i am not sure if it is a good move to go the bluedroid way, as i see no significant advantage: Instead of those, i see lots of problems supporting chipsets not manufactured by broadcom.. Lately, i have been thinking about reverting what Google did, and re-port bluez as the main android stack. All the things you could read about the supposed advantages bluedroid has, is not applying to CSR chips. Reverting to the bluez stack wont make apps incompatible with the resulting JB4.2 ... The supposed advantage of writing new extensions for bluedroid Google is advocating, are not true, as user apps can't directly link to the stack binaries... Well, i am now also considering this approach...

0

Share this post


Link to post
Share on other sites

Posted

ejtagle, a quick question if i may, do you happen to know the configure clock speed of the sdhci controller ?

0

Share this post


Link to post
Share on other sites

Posted

ejtagle, a quick question if i may, do you happen to know the configure clock speed of the sdhci controller ?

48Mhz... is the base clock used to derive all internal clockings...

0

Share this post


Link to post
Share on other sites

Posted (edited)

48Mhz... is the base clock used to derive all internal clockings...

Thanks. I just have a feeling there's something wrong with our micro sd card readers...

Edited by Daedric1383
0

Share this post


Link to post
Share on other sites

Posted (edited)

I am having some strange sound problems with 4.2.1. When using the volume buttons, I can see the volume indicator moving, but the sound level stays the same. When I restart an app, the app uses the new volume level, but changing the level while the app is active does not change the actual volume until I restart the app again.... Anyone else seeing the same problem?

It seems like when an audio stream is opened, volume changes are not applied to the current open audio stream... Cold that be possible?

Edited by Scanno
0

Share this post


Link to post
Share on other sites

Posted

I am having some strange sound problems with 4.2.1. When using the volume buttons, I can see the volume indicator moving, but the sound level stays the same. When I restart an app, the app uses the new volume level, but changing the level while the app is active does not change the actual volume until I restart the app again.... Anyone else seeing the same problem?

It seems like when an audio stream is opened, volume changes are not applied to the current open audio stream... Cold that be possible?

Strange... unless audio volume is setting the volume of something different, such as voice volume...

0

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

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.