LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 02-12-2021, 09:29 AM   #46
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375

Quote:
Originally Posted by louigi600 View Post
So recapping :

Does RPiOS send some vc command to switch on the onboard BT, something with rfkill: they must do something which is not driver/firmware related (I tried with their kernel and firmware).
Hi Louigi,

After reading over your own efforts, and those of others, in an attempt to solve this Cypress Bluetooth shizzle on Slackware ARM, I decided to look into this issue with the mindset that it cannot be that difficult to get working - given that Bluetooth works perfectly on the Raspberry Pi OS. Initially I assumed it must be a /dev rule or some other configuration setting that was missing. Historically, in my experience, the key to solving Slackware problems such as this usually lies in the amount of Jaffa cakes consumed while working on it and the level of enjoyment reached while doing so. On this particular wet, cold, freezing, winter's day the enjoyment factor cannot easily be measured. However, this venture took less than a box of (10) Jaffa cakes - and I finished the rest off because they were lonely. Full moon, half moon, total eclipse! <3

So, working loosely from what you (and others) have already tried and done, first I took a look at the Raspberry Pi OS Bluetooth files and configurations. I installed the 'bluez' pkg and noticed that it added a '/usr/lib/firmware/brcm' directory full of driver files. There's just one of them that's relevant to RPi4 Bluetooth, namely the 'BCM4345C0.hcd' file. So, this was my starting point. I copied the entire '/usr/lib/firmware/brcm' directory from the Raspberry Pi OS to Slackware ARM into the same location.

Then I looked at the Raspberry Pi's Device Tree overlays README specifically for boot related Bluetooth settings. As a result I added the following to my 'boot/config.txt' file:

Code:
dtparam=krnbt=on
enable_uart=0
I then spent 25-30 minutes on Google to see what other users had done to get around the problem of Bluetooth not working on the RPi4 and, I have to say, what a plethora of confusion and chaos that revealed! However, I came across this Arch Linux ARM package enabling integrated Bluetooth on Raspberry Pi 3B/3B+/Zero W page with some interesting information. This lead me into creating a directory (which didn't already exist) containing a symlink to the appropriate Bluetooth driver:

Code:
root@torq:~# mkdir -p /usr/lib/firmware/updates/brcm
root@torq:~# ln -svf /usr/lib/firmware/brcm/BCM4345C0.hcd /usr/lib/firmware/updates/brcm/BCM.hcd
'/usr/lib/firmware/updates/brcm/BCM.hcd' -> '/usr/lib/firmware/brcm/BCM4345C0.hcd'
root@torq:~#
I rebooted the RPi4 and did some testing...

Code:
root@torq:~# echo $MACHTYPE
arm-slackware-linux-gnueabihf
root@torq:~# cat /etc/slackware-version
Slackware 14.2+
root@torq:~# cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.2
root@torq:~# hcidump
HCI sniffer - Bluetooth packet analyzer ver 5.55
device: hci0 snap_len: 1500 filter: 0xffffffff
root@torq:~# hcitool dev
Devices:
        hci0    AA:AA:AA:AA:AA:AA
root@torq:~# bluetoothctl
Agent registered
[CHG] Controller AA:AA:AA:AA:AA:AA Pairable: yes
[bluetooth]# power on
Changing power on succeeded
[bluetooth]# scan on
Discovery started
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: yes
[NEW] Device 61:0D:45:B4:B2:CC 61-0D-45-B4-B2-CC
[NEW] Device 0B:D6:50:46:BA:F5 0B-D6-50-46-BA-F5
[NEW] Device D0:03:4B:57:88:87 D0-03-4B-57-88-87
[NEW] Device 1E:0D:43:77:1D:12 1E-0D-43-77-1D-12
[NEW] Device 08:BE:03:36:81:C7 08-BE-03-36-81-C7
[NEW] Device 40:CB:C0:B6:64:EE 40-CB-C0-B6-64-EE
[bluetooth]# exit
root@torq:~#
I won't be looking to waste any more time on this. I certainly don't need or want Bluetooth but I sincerely hope it works the same for everyone else. I'll think about doing something with the sarpi-hacks pkg to include the above. No guarantees.

The important thing to note here is that it was solved with Slackware ARM and eating Jaffa cakes at the same time, washed down with strong Italian (100% Arabica) coffee. HOO-RAH!
 
5 members found this post helpful.
Old 02-12-2021, 04:57 PM   #47
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Thanks Exaga ... I can confirm that this fixes it on both RPi4 and RPi0
Code:
root@rpi4:~# hciconfig 
hci0:   Type: Primary  Bus: UART
        BD Address: DC:A6:32:E3:69:00  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:4181 acl:0 sco:0 events:395 errors:0
        TX bytes:59723 acl:0 sco:0 commands:393 errors:0

root@rpi4:~# hcitool scan
Scanning ...
        D4:11:A3:D8:2E:3C       Galaxy A40
root@rpi4:~#
Code:
root@rpi0:~# hcitool dev
Devices:
        hci0    B8:27:EB:DC:34:E1
root@rpi0:~# hciconfig  
hci0:   Type: Primary  Bus: UART
        BD Address: B8:27:EB:DC:34:E1  ACL MTU: 1021:8  SCO MTU: 64:1
        UP RUNNING 
        RX bytes:2875 acl:0 sco:0 events:213 errors:0
        TX bytes:31922 acl:0 sco:0 commands:213 errors:0

root@rpi0:~# hcitool scan
Scanning ...
        D4:11:A3:D8:2E:3C       Galaxy A40
root@rpi0:~#
 
2 members found this post helpful.
Old 02-13-2021, 02:46 AM   #48
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
Thanks for your efforts, Exaga! Regarding your comment about not needing bluetooth, it is actually quite important on the 400 which doesn't have an audio out jack.

The only way to get audio out of a 400 is either via the HDMI lead, or bluetooth. Since most monitors don't offer HDMI audio, that leaves only bluetooth, so for some of us, it is quite important!

I'll try adding your commands to the config.txt file on my 400 and report back later today. Mine is currently working OK, but I note that the there has been an overnight upgrade to the kernel-firmware file in slarm64, which may overwrite that dreaded brcm folder again!

Again, thanks for your efforts investigating this!

--
Pete
 
Old 02-13-2021, 03:27 AM   #49
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by pchristy View Post
I'll try adding your commands to the config.txt file on my 400 and report back later today. Mine is currently working OK, but I note that the there has been an overnight upgrade to the kernel-firmware file in slarm64, which may overwrite that dreaded brcm folder again!
if you are using the distribution firmware it is updated according to the slackware distribution, but for some boards, including raspberry pi 3/4, there is its own firmware (upstream + specific for a specific SoC/board) kernel-firmware-bcm2711-5.10.9-aarch64-1mara.txz
 
Old 02-13-2021, 04:59 AM   #50
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
sndwvs: Thanks for pointing that out! I have just been using slackpkg to update from the distribution. Perhaps I should add slackpkg+ and add the location of that firmware file. Is this documented anywhere?

That also answers the question of where the ap6256 folder that caused me so much trouble came from! I originally loaded my installation from one of your images, and then pointed slackpkg at the distribution to update and install everything. Although this updated the /lib/firmware/brcm folder, it didn't update the ap6256 folder, which had an older - and incompatible - version of the BCM4345C5.hcd firmware needed by my 400. My 400 kept loading the wrong firmware, because ap6256 is higher up the "pecking order" than brcm! It took me some time to find that issue!

According to the dates on the files, the two now appear to be in sync.

I think this needs to be flagged up - and/or some kind of work-around devised. Those of us new to ARM are not familiar with these foibles!

BTW, as an aside, although the kernel-firmware package appears to have been updated in the distribution, slackpkg isn't picking it up. I'm guessing this is because the changelog and other associated files haven't caught up yet.

Cheers,

--
Pete
 
Old 02-13-2021, 05:50 AM   #51
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
these are not general distribution packages, so they are not included in slarm64. they are supplied as part of the build kit.
 
Old 02-13-2021, 06:38 AM   #52
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by pchristy View Post
Thanks for your efforts, Exaga! Regarding your comment about not needing bluetooth, it is actually quite important on the 400 which doesn't have an audio out jack.
You're welcome. The truth is that I couldn't idly stand by any longer and watch Louigi struggling with this Bluetooth issue, because he's helped me out so many times in the past, and consequently this was somewhat imbalancing my moral equilibrium. Although, I'm very much in favour of users solving their own problems as that's how we learn and grow in Slackware knowledge and experience, a viable solution seemed to be going nowhere fast this time.

Quote:
Originally Posted by pchristy View Post
The only way to get audio out of a 400 is either via the HDMI lead, or bluetooth. Since most monitors don't offer HDMI audio, that leaves only bluetooth, so for some of us, it is quite important!
I hear you on the RPi 400 Bluetooth and I'm sure for many other users it's equally as important. But I do not have this model and solving problems on hardware I do not own, or have use of, is well within the realms of pretence and guesswork. The only time I get involved with RPi Bluetooth (and wireless networking) is mostly when users alert me to problems with SARPi shizzle. The irony is that I'd rather users come to me and say, "Hey! I found an issue with SARPi and here's how I fixed it..." than "Your SARPi shizzle is busted and YOU need to fix it!". Too often users miss the point and opportunity to learn so much from doing so. Hence the old adage "Linux users don't want to learn, they want you to do it for them!"

On that basis, the Slackware Team includes infinitely more than what users need within the Slackware OS and, within that scope, any thing is possible. That's why it has always been, and will be, the ultimate Linux distribution available. On top of that there's the Slackbook, SlackDocs, Slackbuilds, with the ability to easily build your own (DIY) software pkgs if they don't already exist, with these LQ forums for gaining/sharing experience, etc. (ad infinitum). The possibilities are limitless.

Quote:
Originally Posted by pchristy View Post
I'll try adding your commands to the config.txt file on my 400 and report back later today. Mine is currently working OK, but I note that the there has been an overnight upgrade to the kernel-firmware file in slarm64, which may overwrite that dreaded brcm folder again!
We're dealing with closed-source bespoke firmware licensed by Broadcom. I'm aware now that there have been a few changes recently in the configuration and how it works. Slackware ARM doesn't include the RPi wireless/Bluetooth firmware and it's one of the very few allowances I add within SARPi. I very much wish it wasn't the case, or that the firmware was open-source, or that users would install their own 3rd party USB wireless and Bluetooth adapters which are officially supported under Slackware ARM or with drivers that can be compiled from source.
 
1 members found this post helpful.
Old 02-13-2021, 06:50 AM   #53
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by louigi600 View Post
Thanks Exaga ... I can confirm that this fixes it on both RPi4 and RPi0
Thanks Louigi. I'm unsure if the RPi3B [not 3B+] might need a different driver file. The 3B+ uses the same driver(s) as the RPi4 afaik. I haven't tested it yet and I might not. Need to decide if supporting the onboard wireless/Bluetooth via SARPi is the best way forward.
 
Old 02-13-2021, 08:11 AM   #54
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Quote:
Originally Posted by Exaga View Post
Thanks Louigi. I'm unsure if the RPi3B [not 3B+] might need a different driver file. The 3B+ uses the same driver(s) as the RPi4 afaik. I haven't tested it yet and I might not. Need to decide if supporting the onboard wireless/Bluetooth via SARPi is the best way forward.
My media player is an RPi3 ... I can confirm that it's working there too (tested with my multiboot uSD).
I forgot to note the revision ... I'll update this post next time I get round to doing that.

Ok back from the walk:
Code:
root@rpi3:~# cat /proc/device-tree/model 
Raspberry Pi 3 Model B Plus Rev 1.3
root@rpi3:~# hcitool dev
Devices:
        hci0    43:45:C0:00:1F:AC
root@rpi3:~# hcitool scan
Scanning ...
root@rpi3:~# hcitool scan
Scanning ...
        48:6D:BB:E8:45:D7       TOSHIBA TV
root@rpi3:~#

Last edited by louigi600; 02-13-2021 at 09:59 AM.
 
Old 02-13-2021, 10:04 AM   #55
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
I added Exaga's extra commands to my config.txt and it doesn't appear to have broken anything! Mind you, it was working OK before, so that is probably not a good test!

Exaga: Yes, I hear your comments about hardware availability for testing. Judging by most of the posts on here, it looks as if I may be the sole 400 user present! I've always tried to make it clear that the solutions I've found may not work on other Pis (Pies?) but at least they've pointed in the right direction - ie: firmware issues, that seem to be at the root of most of the wifi/bluetooth problems!

sndwvs: Again, I hear what you are saying. I am just pointing out that it was build-kit specific components (included in the images) that caused me problems in correctly diagnosing the firmware issues. Having two versions of the - supposedly - same firmware in different folders was what led me on a merry chase trying to fix the issue. Had I not had the ap6256 folder installed, I would have got it all working a lot sooner.

Please don't think I'm criticising - I'm not! But it is one of the reasons that I'll be a lot happier when I can install using the slackware installer - or something similar - rather than a pre-packaged image. For the moment, the image is the only real prospect to get started.

I did try sarpi64, and managed to get that to work once I had prepared a source disk that used slackware as the folder names rather than slarm (the slackware installer didn't like slarm!). Unfortunately that method broke something in sddm, and I couldn't get it to launch. Something to revisit in future perhaps!

So many things to learn, and so little time....



--
Pete
 
Old 02-13-2021, 10:21 AM   #56
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by pchristy View Post
Please don't think I'm criticising - I'm not! But it is one of the reasons that I'll be a lot happier when I can install using the slackware installer - or something similar - rather than a pre-packaged image. For the moment, the image is the only real prospect to get started.
the installer will not solve this problem or is similar to it, the reason is that all SoC are different in the distribution (and rightly so) only what comes with kernel.org everything else is just hacks for a specific SoC/board. in any case, until it is will be upstream.
 
Old 02-13-2021, 11:47 AM   #57
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
Sorry I can't resist going off topic:
Quote:
Originally Posted by pchristy View Post
... it looks as if I may be the sole 400 user present!
Several times I've been tempted to buy a RPi400, after all a 4Gb ram RPi4 + case + keyboard is more expensive then a RPi400 ... and the amount of time you would save in hacking a standard RPi4 into the top left corner of a standard USB keyboard enclosure is colossal.
Maybe you will soon loose your primacy
But I do plan to put an RPi4 into an old laptop stripped of the obsolete hardware ... after all an 80WattHour battery pack will probably be able to power the display and the RPi4 @ 100% cpu load for over 8 hours: we need a decent browser for that project to make sense
 
Old 02-13-2021, 12:10 PM   #58
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by louigi600 View Post
Sorry I can't resist going off topic:
Going off-topic is great! It's like going off-piste but without any skis or snowboard.

I'm currently eating chicken burgers in ciabatta's with Reggae Reggae sauce, downloading "Detroit: Become Human" on Windows 10 (Steam have a sale on until 15 February 10:00 PST), and (re)building a Slackware ARM time machine on the RPi3!
 
Old 02-13-2021, 01:21 PM   #59
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
@Exaga :I sent you a PM
 
Old 02-14-2021, 05:17 AM   #60
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
I updated the distribution kernel-firmware this morning, and everything still works. However, I've now had a close look at the various firmware files and have some additional information for sndwvs and Exaga...

On the 400, the critical file for Bluetooth is BCM4345C5.hcd (for the 4 it seems ti be the C0 version - see above).

The BCM4345C5.hcd file is NOT part of the kernel-firmware package. However, there are TWO versions of it in sndwvs package referenced above (#49): in ap6256 there is a BCM4345C5 file with a file size of 39411 dated January 24. In the brcm folder is another BCM4345C5 file with a size of 49610 also dated January 24.

Note the difference in file sizes! Despite having the same name, they are different files! The one in ap6256 will be loaded preferentially because it is higher in the alphabetical order, but this is the WRONG file for the 400, and prevents bluetooth from working properly.

I can't see an easy way to work around this in an automated fashion. Again, please don't take this as a criticism! I hope that by pointing out this anomaly, someone cleverer than I can figure out a way to ensure the correct version of the file is loaded "automagically".

Best to discover these hiccups at the development stage, before rolling out a "production" version!

--
Pete
 
  


Reply

Tags
bluetooth, firmware, sarpi, slackware arm


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Create/add a 'Revision needed' Forum (like Intro) for Threads *needing revision/rewrite* (n00bs) !!! LQ Suggestions & Feedback 1 12-20-2017 03:26 PM
[SOLVED] bluetooth dongle + bluetooth speaker but no sound on the bluetooth speaker vonbiber Slackware 4 05-11-2017 09:53 AM
svn restore directory to a revision also removing files not part of revision Four Linux - Software 1 03-03-2009 04:18 PM
"make-kpkg --revision=foo.1.0 kernel_image" gives some errors (kernel 2.6.3) Duukkis Debian 14 05-23-2004 03:58 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 09:08 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration