LinuxQuestions.org
Review your favorite Linux distribution.
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-14-2021, 07:26 AM   #61
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76

blacklist kernel-firmware and just use what you have and deal with problems only if/when they arise.
 
1 members found this post helpful.
Old 02-14-2021, 07:46 AM   #62
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by pchristy View Post
On the 400, the critical file for Bluetooth is BCM4345C5.hcd (for the 4 it seems ti be the C0 version - see above).
So, in the interests of "keep it simple" and Slackwaresque...

if [ "BCM4345C5.hcd" == "Bluetooth driver file for the RPi 400" ]; then

Code:
root@torq:~# mkdir -p /usr/lib/firmware/updates/brcm
root@torq:~# ln -svf /usr/lib/firmware/brcm/BCM4345C5.hcd /usr/lib/firmware/updates/brcm/BCM.hcd
'/usr/lib/firmware/updates/brcm/BCM.hcd' -> '/usr/lib/firmware/brcm/BCM4345C5.hcd'
root@torq:~#
elif [ "BCM4345C0.hcd" == "Bluetooth driver file for the RPi 0/3/4" ]; then

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:~#
fi

Quote:
Originally Posted by pchristy View Post
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.
Isn't 'BCM4345C0.hcd' and 'BCM4345C5.hcd' installed with the Raspberry Pi bluez-firmware?
 
Old 02-14-2021, 08:59 AM   #63
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
Louigi: The problem is not the kernel-firmware package, but sndwvs Pi package from his build kit, which has two files with the same name in firmware. On the 400, the wrong one gets loaded.

Exaga: That would solve the problem for differentiating between the 4 and 400 (I think - don't have a 4 to try it on!). I'm not sure it would solve the problem of having two files of the same name in different folders. Does the "update" folder always get tried first? or does it still go in alphabetical order? And will it still load if the symbolic link has a simplified file name? I'm not sat in front of the 400 at the moment (sat in the workshop repairing and old RC transmitter!)

I'll have a play later...

P.S. I rebuilt the Bluez package to add the patches for the 400. It does not seem to build any firmware, nor can I find any in the "stock" bluez package. There is a Bluez firmware package, but it doesn't contain any BCM4345XX files!

--
Pete

Last edited by pchristy; 02-14-2021 at 09:04 AM.
 
Old 02-14-2021, 11:23 AM   #64
louigi600
Member
 
Registered: Dec 2013
Location: Italy
Distribution: Slackware
Posts: 619

Original Poster
Blog Entries: 19

Rep: Reputation: 76
I that case maybe you can do something like I sometimes do: untar the package into /tmp without installing it, remove what you don't need, copy the stuff over to / and run doinst.sh manually.
You can even write a script that can do that automatically maybe even making it look like you did a propper install in /var/log/packages (or wherever current has moved that).
 
1 members found this post helpful.
Old 02-14-2021, 01:04 PM   #65
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
Now I know about the issue - and its solution - its not an issue any more, at least not for me. However, I can see future 400 owners running into the same issues, unless they stumble across the threads here.

Its like a lot of things - once you are aware of the problem and its solution, it is no longer a problem. -current versions of Slackware are all about noting problems, and if possible offering solutions, so that when the "release" version hits the servers, all the issues are sorted - hopefully!

To my mind, this is an issue. I can see the problem, and a manual solution to it. What I can't see is an automated solution! I know that Pis (Pies?) have a method of reporting the type somewhere or other, so it might be possible to use that information at the installation stage to make sure the right firmware is loaded - or rather the wrong firmware is NOT loaded!

That part of the process is getting a bit above my pay-grade ( ), but hopefully between Exaga, sndwaves and drmozes, someone cleverer than me will find a way of sorting it!

--
Pete
 
Old 02-14-2021, 03:09 PM   #66
HappyTux
Senior Member
 
Registered: Mar 2003
Location: Nova Scotia, Canada
Distribution: Debian AMD64
Posts: 3,892

Rep: Reputation: 171Reputation: 171
Quote:
Originally Posted by Exaga View Post
"Linux users don't want to learn, they want you to do it for them!"
"Windows users using linux want it spoon fed to them like they already are used to." I would think that should read, then again you and I could be unique and want to use our brains. I do not ask questions, I answer them and if needed I will search forever to get the answer to a problem.

Edit: and the laziness of them, I will take the question they ask put it into to Google and see it answered in the first hit, they did not even search. For those I answer the question telling them exactly how I found it with links to both the search and the page with the solution. There is my off topic rant for the day, thanks for the opportunity.

Last edited by HappyTux; 02-14-2021 at 03:16 PM.
 
Old 02-14-2021, 04:25 PM   #67
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by pchristy View Post
Exaga: That would solve the problem for differentiating between the 4 and 400 (I think - don't have a 4 to try it on!). I'm not sure it would solve the problem of having two files of the same name in different folders. Does the "update" folder always get tried first? or does it still go in alphabetical order? And will it still load if the symbolic link has a simplified file name? I'm not sat in front of the 400 at the moment (sat in the workshop repairing and old RC transmitter!)

I'll have a play later...

P.S. I rebuilt the Bluez package to add the patches for the 400. It does not seem to build any firmware, nor can I find any in the "stock" bluez package. There is a Bluez firmware package, but it doesn't contain any BCM4345XX files!
It's not a consideration of mine as to how sndwvs goes about creating Slackware pkgs for his slarm64 project. That's sndwvs' responsibility.

When I build something for sarpi-hacks to include the Bluetooth shizzle I'll be doing it pretty much how Louigi described...

Quote:
Originally Posted by louigi600 View Post
I that case maybe you can do something like I sometimes do: untar the package into /tmp without installing it, remove what you don't need, copy the stuff over to / and run doinst.sh manually.
You can even write a script that can do that automatically maybe even making it look like you did a propper install in /var/log/packages (or wherever current has moved that).
... but in a Slackware pkg where both the 'BCM4345C0.hcd' and 'BCM4345C5.hcd' files will be located in the same directory (i.e. '/usr/lib/firmware/brcm') - I'll probably grep the output of 'cat /proc/device-tree/model' - or some other non-variable output - that differentiates RPi versions from each other to determine what the specific hardware is - so the required symlink (i.e. '/usr/lib/firmware/updates/brcm/BCM.hcd') will be pointed to the correct driver file. If not all RPi models use the same Bluetooth driver file then this is how I'd go about sorting it out.

Incidentally, there's not a great deal of clarity in my mind over which Bluetooth driver file is needed for the RPi 400. You are making it wayyyyy too convoluted by going into so much detail about things when it's not required. For example, I don't have a glimpse of a Sherlock Holmes clue what the following means...

Quote:
Originally Posted by pchristy View Post
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.
If this relates to, or is descriptive of, something within slarm64 then please make that known beyond all shadow of a doubt. If it relates to official Slackware ARM then I am even more in the dark than I initially thought. At the moment I'm assuming 'BCM4345C0.hcd' is the RPi zero/3/4 Bluetooth driver and 'BCM4345C5.hcd' is the RPi 400 Bluetooth driver in the distributed Raspberry Pi bluez-firmware package.
 
Old 02-15-2021, 04:15 AM   #68
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
Hi Exaga, and sorry about the confusion! Its probably because I've been a bit confused myself! Essentially I'm talking Slarm64 (running 32 bit software on a 64 bit system always struck me like having a V8 Mustang and disconnecting half the spark plugs! )

I could not understand where the offending ap6256 folder was coming from. It isn't in the Slarm64 firmware packages and it isn't in Bluez. I don't recall it being in sarpi-hacks. The answer came from sndwvs answer #49 (above). He says he has created that kernel-firmware-bcm2711xxx package from upstream, and that is where the problem originates - for me, anyway! The ap6256 folder appears to have come from Manjaro-arm. I have no idea what system that is aimed at, but it is that package that causes the conflict on the 400.

Going slightly off-topic here, but hopefully this will provide some insights into how I ended up here!

As far as I can tell, there are two ways of installing Slarm64: Sarpi-64 and using one of sndwvs image files to kick start. The easiest way is to use sndwvs image files - but that comes with the offending "upstream" package built in. Because it was built in, and not installed by me, I had no idea of its existence until this thread!

Sarpi64 provides a more "Slackware" like approach with the installer, but it doesn't work with the stock Slarm64 tree! The Slackware installer requires specific names for the various folders. Most importantly is the one containing a, ap, d, k, etc, folders. It needs to be called "slackwareXXX". "slackware" will work, "slackware64" will work, slackwareaarch64 will work (I think!). "slarm64" WON'T work. In order to get the Slackware installer to work with Slarm64, it is necessary to have a local tree with the folders re-named accordingly. (Or dive into Slackware's initrd and edit all the files before rebuilding it!) Also, for some reason I never got to the bottom of, using sarpi64 / Slackware installer, I could never get X to start automatically. Setting runlevel 4 in initrd refused to start sddm, or any of the other window managers, although "startx" worked just fine from the command line.

That's why I went with sndwvs images, and why I spent so long finding out about the firmware issues. And looking back, its probably what AlienBob was warning me about in some of my first posts here!

As I say, it results from having two firmware packages with identical names, and the wrong one being loaded by default.

Sorry for being long-winded, but hopefully my explanation of how I got here will clarify things a bit! (Or maybe not???)



--
Pete
 
Old 02-16-2021, 01:18 AM   #69
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
Quote:
Originally Posted by louigi600 View Post
Originally Posted by louigi600 View Post
I that case maybe you can do something like I sometimes do: untar the package into /tmp without installing it, remove what you don't need, copy the stuff over to / and run doinst.sh manually.
You can even write a script that can do that automatically maybe even making it look like you did a proper install in /var/log/packages (or wherever current has moved that).
... but in a Slackware pkg where both the 'BCM4345C0.hcd' and 'BCM4345C5.hcd' files will be located in the same directory (i.e. '/usr/lib/firmware/brcm') - I'll probably grep the output of 'cat /proc/device-tree/model' - or some other non-variable output - that differentiates RPi versions from each other to determine what the specific hardware is - so the required symlink (i.e. '/usr/lib/firmware/updates/brcm/BCM.hcd') will be pointed to the correct driver file. If not all RPi models use the same Bluetooth driver file then this is how I'd go about sorting it out.
That was meant as a user workaround ... not for packaging. For packaging I don't think there will be a permanent solution: the RPi foundation will keep on rolling out new releases with slightly different hardware specs and unpredictable requirements for making them work, new boot firmwares with unpredictable effects on previously working drivers and new firmwares with unpredictable paths. The only predictable thing is that at some point things will brake and one will have to see what they have done on RPiOS to sort it out
There is a somewhat disturbing subliminal message in that: "Luke .... Use RPiOS on the RPis".
 
Old 02-16-2021, 01:27 AM   #70
Desiderius
Member
 
Registered: Jun 2017
Posts: 88

Rep: Reputation: Disabled
Thanks a lot Exaga

I have followed your instructions and .... it works FINALLY !

I agree with louigi600 : Does the Raspberry foundation wants to force their users to use RPIOS ?

And be registered secretly by Microsoft at the same time :

https://www.cyberciti.biz/linux-news...-pis-linux-os/
 
Old 02-16-2021, 03:50 AM   #71
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by pchristy View Post
Hi Exaga, and sorry about the confusion! Its probably because I've been a bit confused myself!
The only confusion with Slackware is what we bring ourselves. Not only do you seem confused but you are also confusing me/others with non-relevant and impertinent information relating to slarm64. A specific and separate thread to address your slarm64 issue(s) may be prudent and more beneficial.
 
1 members found this post helpful.
Old 02-16-2021, 04:00 AM   #72
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by louigi600 View Post
The only predictable thing is that at some point things will brake and one will have to see what they have done on RPiOS to sort it out

There is a somewhat disturbing subliminal message in that: "Luke .... Use RPiOS on the RPis".
To be quite honest Louigi, that's exactly what I've done for the past +8 years. I've always maintained that there wasn't a problem until users started to alert me, or complain, that RPi Bluetooth/wireless was broken and then I found a solution and implemented it via the sarpi-hacks pkg. It shouldn't be difficult at all to create a method to make it work under the current configuration. As long as we keep things simple, relevant, and applicable, it'll work fine.

Regarding any alleged "subliminal messages", (LOL! Love the Star Wars reference <3)... of course the Raspberry Pi OS is the manufacturer's preferred software for the device. I understand that. As Slackware users we just need to try and keep on top of things and maintain full functionality. Sometimes "You need to unlearn what you have learned." and "Do or do not. There is no try." in the pursuit of unsupported software and hardware working together in blissful harmony.
 
1 members found this post helpful.
Old 02-16-2021, 04:11 AM   #73
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by Desiderius View Post
Thanks a lot Exaga

I have followed your instructions and .... it works FINALLY !

I agree with louigi600 : Does the Raspberry foundation wants to force their users to use RPIOS ?

And be registered secretly by Microsoft at the same time :

https://www.cyberciti.biz/linux-news...-pis-linux-os/
Good to know Desiderius. Thank you! Glad it's working for you.

Don't be too concerned about the Raspberry Pi OS or the 'secret' Microsoft repository. If it ever gets to the point where things have stopped working with Slackware ARM on the RPi devices and cannot be resolved, we'll just try to find another way.

Ultimately, there's always 3rd party USB adapters for wireless/Bluetooth which generally work as expected - which are cheap and available, and I personally prefer to use these in any event rather than the onboard Cypress shizzle.
 
Old 02-16-2021, 06:15 AM   #74
pchristy
Member
 
Registered: Oct 2012
Location: South Devon, UK
Distribution: Slackware
Posts: 697

Rep: Reputation: Disabled
Quote:
Originally Posted by Exaga View Post
The only confusion with Slackware is what we bring ourselves. Not only do you seem confused but you are also confusing me/others with non-relevant and impertinent information relating to slarm64. A specific and separate thread to address your slarm64 issue(s) may be prudent and more beneficial.
You are probably right! However, in my defence, it would appear that most of these bluetooth / wifi issues are firmware related, and these do appear to be somewhat independent of the specific version of Slackware - firmware being largely independent of distro architecture.

Until some method can be devised of ensuring that only the correct firmware is applied - and I can see this is a problem, with so many flavours of ARM machines out there - this issue will continue to cause problems.

Cheers,

--
Pete
 
Old 02-16-2021, 09:23 AM   #75
Exaga
SARPi Maintainer
 
Registered: Nov 2012
Distribution: Slackware [ARM]
Posts: 639

Rep: Reputation: 375Reputation: 375Reputation: 375Reputation: 375
Quote:
Originally Posted by pchristy View Post
Until some method can be devised of ensuring that only the correct firmware is applied - and I can see this is a problem, with so many flavours of ARM machines out there - this issue will continue to cause problems.
I don't envisage any problem(s) with implementing a method by which the correct firmware is addressed according to the specific RPi model/revision. As long as each RPi hardware device uses only one BCM434* chipset version it will be easy. All it requires is manipulation of the appropriate information from the hardware in order to achieve it.

NB: Not all "flavours of ARM machines out there" use the Broadcom BCM43430 (Raspberry Pi 3B) or BCM43455 (Raspberry Pi 3B+/4B) or BCM43456 (Raspberry Pi 400) chipsets. I am only aware of the Raspberry Pi ARM devices which use these chipsets. There may well be others but with regards to SARPi my only interest is in the Raspberry Pi devices.
 
1 members found this post helpful.
  


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 07:55 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