blacklist kernel-firmware and just use what you have and deal with problems only if/when they arise.

So, in the interests of "keep it simple" and Slackwaresque... :rolleyes:

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

elif [ "BCM4345C0.hcd" == "Bluetooth driver file for the RPi 0/3/4" ]; then

fi

Isn't 'BCM4345C0.hcd' and 'BCM4345C5.hcd' installed with the Raspberry Pi bluez-firmware?

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

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

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

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

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

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

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.

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

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 :D
There is a somewhat disturbing subliminal message in that: "Luke .... Use RPiOS on the RPis".

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/

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.

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

Good to know Desiderius. Thank you! Glad it's working for you. :thumbsup:

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

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

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.