Linux and Raspberry Pi + HAT config issues

Red herrings.
I am NOT diverting attention from the topic. Setting up a Linux based Raspberry Pi music player with a DAC HAT is a NIGHTMARE if one chooses to do it in a personalised way. If on the other hand, one chooses to use ready made images, it is different, provided a home network is connected to.

I have not known Linux for system freezes and crashes, but the introduction of systemd brought that unwelcome instability reminding me and many others of Windows 3.1, Windows 95, Windows 98 and Windows ME! huge hiccups during boot and shutdown were something unheard of in Linux, but systemd made Linux manifest them even to the shock of well seasoned Linux users.

Please note, I have experienced system freezes on the Raspberry Pi notwithstanding I DO NOT MIX REPOSITORIES!

Finally, using an additional sound card, like a DAC HAT, should NOT force users into software lock-ins forcing them to use ready made OS images or FAIL.

I end up, writing I want a customised music player using three terminals without a graphical interface running. The terminals are to be accessed the old way using "CTRL+ALT+F1", "CTRL+ALT+F2" and "CTRL+ALT+F3". On terminal 1 alsamixer is to run, on the next the player, mplayer or mpg123 or any other equivalent and on the third an equiliser. This seems to be an impossibility!
 
This seems to be an impossibility!
As impossible as your google-foo perhaps?
Man, it's Linux ! you have to do the hard yards yourself and not whine like the common Windows butt-hurt. 🙂

https://www.makeuseof.com/best-command-line-music-players-linux/
https://www.makeuseof.com/play-music-linux-terminal-with-cmus/
https://www.tecmint.com/command-line-music-players-for-linux/

If your Pi is freezing do some diagnostics starting with the power supply... you have a multi-meter don't you ?... ? don't you ?
 
The misleading information of this thread is the unreal impression that Linux is some god gift given to humanity from the heavens! It is not. Linux is actually a constant pain: I use it to save money by avoiding to have the latest hardware to run an OS. Even the latter, is slowly changing with the new spate of young developers who do not want to continue supporting older hardware. The previous generations of developers did their utmost to support old hardware much unlike what is happening now. Linux will soon become yet another OS requiring state of the art hardware. The other reason for using Linux are the extreme wealth of command line tools and other graphical programs which in the Windows and Mac worlds are purchased against a payment. So, the real reason for choosing Linux is economical, that is, to save money!

I tried, and actually succeeded, to set up a music player the way I want, although not yet a complete success. However, I am put back by the introduction of new bugs due to bad choices by the Raspberry Pi developer team, who insist on installing their OS and do not give information as to how to setup missing drivers for unsupported devices.

I remember myself browsing the Pi file system to examine/audit which drivers are installed, and actually, found the drivers for the IQaudIO DAC, but they were not being loaded at boot. Seeing this I used modprobe -i kernel_module_name to load the missing modules and still, the DAC was not recognised. This is a nightmare.

The golden quesion is: Does anyone know and understand how drivers are installed and what should be done additionally to make the Pi recognise a sound card hat?
 
I think, for my next purchase, the choice of DAC hat should go to something which has a good reputation of being supported and well performing. Reading about Pi DAC hats, I found that HiFiBerry DAC hats have good support and an attractive reputation. If HiFiBerries change the situation from a DAC not supported and not detected to one that is supported and detected, that will be enough for me to decide on using a HiFiBerry instead, but I need to know more about them to make an informed decision.
 
I believe it is a combination of the data on the HAT eeprom plus the dtoverlay that makes it happen.

HAT info
name: hat
product: JustBoom Digi HAT v1.1
product_id: 0x0002
product_ver: 0x0101
uuid: 20781897-663c-429a-938c-00000000041f
vendor: JustBoom

Of course, some hardware vendors don't have 100% compliant HATs, some don't get their software included in RPiOS or upstream Linux and then there are others that just do hardware and use their opposition's dtoverlays and drivers (cheating IMO).
 
I believe it is a combination of the data on the HAT eeprom plus the dtoverlay that makes it happen.
Greg, thanks a lot, I did not know about the RPi HAT EEPROM specs https://github.com/raspberrypi/hats .

IIUC reading the HAT EEPROM is done by the VC firmware, before linux boots. The I2C bus used for the eeprom belongs to the proprietary VC block. RPi-specific, but so are the hats, that's fair.

Since the overlay DTB binary can be stored in the eeprom, its format must fit the kernel - overlays stored for pre-5.4 kernels may not work for 5.4+ kernels https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/

IIUC the eeprom I2C address is only one (0x50), no support for multiple hats.

Even the aforementioned hifiberry implements the eeprom on some of its hats only. IMO it is not so surprising many hat vendors do not implement this.
 
Greg, thanks a lot, I did not know about the RPi HAT EEPROM specs https://github.com/raspberrypi/hats .

IIUC reading the HAT EEPROM is done by the VC firmware, before linux boots. The I2C bus used for the eeprom belongs to the proprietary VC block. RPi-specific, but so are the hats, that's fair.

Since the overlay DTB binary can be stored in the eeprom, its format must fit the kernel - overlays stored for pre-5.4 kernels may not work for 5.4+ kernels https://www.hifiberry.com/docs/software/configuring-linux-3-18-x/

IIUC the eeprom I2C address is only one (0x50), no support for multiple hats.

Even the aforementioned hifiberry implements the eeprom on some of its hats only. IMO it is not so surprising many hat vendors do not implement this.
IIRC it was back in the beginning of the year that we started getting some trouble reports that certain HiFiBerry cards could not be configured via the standard dtoverlay line in config.txt. Eventually the EEPROM issue became known and we started configuring force_eeprom_read=0 in config.txt for all HiFiBerry cards/overlays.
 
Hi Tim,

I was just a little curious what method HiFiBerry use to auto detect their own HATs, but not curious enough to download HiFiBerryOS.

Did they implement force_eeprom_read=0 in config.txt? That would be ironic.

I haven't used any player other than piCorePlayer, so I don't know how other people do things???
 
Good question. In our case we let user pick from an internal list of named I2S devices or if their device is not in the named list then they can pick from the DT overlay list in /boot/overlays that ships with the Pi Linux kernel. HAT manufacturers should spec which overlay to use, lol.

The config parameter force_eeprom_read=0 prevents the Pi firmware from reading the HAT's EEPROM. We add this to config.txt if the device or overlay selected by the user contains the string "hifiberry". This way the firmware can avoid processing a bad eeprom overlay which AFAIK causes a system hang.
https://www.raspberrypi.com/documentation/computers/config_txt.html#force_eeprom_read
 
I think, for my next purchase, the choice of DAC hat should go to something which has a good reputation of being supported and well performing. Reading about Pi DAC hats, I found that HiFiBerry DAC hats have good support and an attractive reputation. If HiFiBerries change the situation from a DAC not supported and not detected to one that is supported and detected, that will be enough for me to decide on using a HiFiBerry instead, but I need to know more about them to make an informed decision.
That way madness lies, unless you want to use Hifiberry OS.
 
Yatsushiro said:
That way madness lies, unless you want to use Hifiberry OS.
I am still not decided what I should buy as DAC HATs seem to be not always properly supported with the provision of drivers from their makers. This means, I will have not only to think and rethink, but I have to do more research and reading. As you correctly hinted, purchasing a DAC HAT by another manufacturer to end up in the same situation, is not at all an intelligent step to take.
 
If it helps...

I have the IQAudioPRO HAT DAC on a Pi 3. I installed the now defunct Archphile - which is a customisation of archlinux. This ran absolutely fine without any bootup pops / clicks or other issues and was as easy as uncommenting the required dtoverlay for the one of many HAT DACs preconfigured with the customisation.

I have since applied a rolling update. All I had to do, was use the latest / recompile MPD and all seems to work fine.