| View previous topic :: View next topic |
| Author |
Message |
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
 Posted: Fri Oct 11, 2019 4:51 am Post subject: What I'd like to see fixed on ARM SBCs. |
 |
|
- No more device tree. Some Raspberry Pi HATs embed EEPROMs to eliminate the need for device tree. Single board computers can come with EEPROMs to eliminate device trees, too.
- Intuitive cross-compilation in chroot.
- Right now, cross-compilation to ARM platform on gentoo is largely broken.
- Fast support from mainline linux.
- I don't like depending on downstream linux kernels which manufacturers can stop supporting anytime soon.
- No more binary blobs that make it difficult to install gentoo manually. I don't like thinking about bootcode.bin, start.elf, etc, ...
- Improved Multilib support // When I use 64-bit kernel, it's difficult to use 32-bit utilities such as vcgencmd.
- Don't mix bluetooth with serial devices.
- Don't mix Ethernet or SATA with USB.
People who use binary distributions may have none of these issues. But, on gentoo, these issues consume a lot of time and frustrate me.
I may try x86 single board computers later. |
|
| Back to top |
|
 |
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Fri Oct 11, 2019 5:55 am Post subject: Re: What I'd like to see fixed on ARM SBCs. |
|
|
| crocket wrote: | - No more device tree. Some Raspberry Pi HATs embed EEPROMs to eliminate the need for device tree. Single board computers can come with EEPROMs to eliminate device trees, too.
|
The problem is that there is no plug'n'pray, so for example to add a sound card there is the need for a new dtb. And once you learn to use them they are great:
https://elinux.org/images/a/a3/Elce2013-petazzoni-devicetree-for-dummies.pdf
| crocket wrote: |
Intuitive cross-compilation in chroot.
- Right now, cross-compilation to ARM platform on gentoo is largely broken.
Fast support from mainline linux.
- I don't like depending on downstream linux kernels which manufacturers can stop supporting anytime soon.
No more binary blobs that make it difficult to install gentoo manually. I don't like thinking about bootcode.bin, start.elf, etc, ...
Improved Multilib support // When I use 64-bit kernel, it's difficult to use 32-bit utilities such as vcgencmd.
Don't mix bluetooth with serial devices.
Don't mix Ethernet or SATA with USB.
People who use binary distributions may have none of these issues. But, on gentoo, these issues consume a lot of time and frustrate me.
I may try x86 single board computers later. |
Those are raspberry pi specific problems, not ARM ones. USB adapters (even embedded ones) are a cheap solution dictated gy greed not by the architecture.
Apparently everybody goes amlogic now for cheap boards, but also pine64 has some new boards, some have a pci express slot btw.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
| Posted: Fri Oct 11, 2019 6:55 am Post subject: Re: What I'd like to see fixed on ARM SBCs. |
|
|
There is InnoMaker Raspberry Pi HiFi DAC HAT which includes integrated EEPROM for automatic configuration(Option).
| erm67 wrote: | Those are raspberry pi specific problems, not ARM ones. USB adapters (even embedded ones) are a cheap solution dictated gy greed not by the architecture.
Apparently everybody goes amlogic now for cheap boards, but also pine64 has some new boards, some have a pci express slot btw. |
Yes, cheap greedy manufacturers are the bottleneck. Do you recommend any specific affordable ARM SBCs for a headless server? I want the best of the best.
AML-S905X-CC (Le Potato) comes to my mind when I think about easy configuration.
At this point, I just want to utilize an SBC for wake-on-lan and VPN and SSH relay. For my lightweight usecases, an SBC that's easy to configure and maintain is the best SBC. |
|
| Back to top |
|
|
erm67
l33t
Joined: 01 Nov 2005
Posts: 653
Location: EU
|
| Posted: Fri Oct 11, 2019 1:32 pm Post subject: |
|
|
I2S sound cards are just a gimmick to sell, most of them are just crap. It is just that some people love to have exotic stuff like an I2S bus, but nobody really understands why trasmitting the same digital data over a slow exotic bus like I2S should be better than doing that over the USB bus exp. if the same DAC chipset is connected to the bus .... most of the problems are caused by noise coming from the PSU or ground loops. Oh so called "USB purifiers" that allegedly clean the 5V of the USB port are just a scam as well, if the USB sound card sucks and doesn't filter the power line it will just suck a bit less with "purifier" maybe  and most importantly even a cheap china usb sound card with an spdif out configured to passthrough digital data to an external amplifier will make a better job than every I2S sound card.
Get something like this and a pair of JBL loudspeakers if you want to be serious:
http://www.rotel.com/product/a14
a raspy running mpd connected to the USB port will make wonders there is also some software (for PC) that will interpolate the music to DSD64 and should sound great
The N2 has a nice DAC on board btw. it has a decent analog line out but even cheap china DAC from SMSL are better than it, if your HIFI system is half decent you will hear the difference. Of course using SPDIF and passthrough there will be no difference since the PCM data will be sent unaltered to the ampli over the optical fiber.
My main HIFI is a vintage Technics superlinear class AA amplifier combined to a pair of Wharfedale speakers, and it still kicks ass to every class D or T ampli out there It sounds also better than the entry level sonos, that use a class D ampli inside. The Technics is also great with the chromecast audio, you can get one for maybe 10$ on ebay and has a good AKM DAC on board, I use it only to listen to spotify but it is a nice way to refurbish a vintage HIFI and the AKM dac is certainly better than the Sabre chipset used in most toy 'HI FI' card for the raspi.
Anyway regarding DTC and DTBs, if you read the book:
| Quote: | Since the DT is OS independent, it should also be stable.
The original idea is that DTBs can be flashed on some devices by the manufacturer, so that the user can install whichever operating system it wants.
Once a Device Tree binding is defined, and used in DTBs, tshould no longer be changed anymore. It can only be extended.
This normally means thatDevice Tree bindings becomepart of the kernel ABI, and it should be handled with thesame care.
However, kernel developers are realizing that this is really hardto achieve and slowing down the integration of drivers.IThe ARM Kernel Mini-summit discussions have relaxed thoserules.
There will be additional discussions during the Kernel Summit,with final conclusions published afterwards.Free Electrons. Kernel, drivers and embedded Linux development, consulting, training and support.http://free-electrons.com41/45
|
Ideally it should be possible to burn the DTB to an eprom and the kernel would use it, however this has not happen, not because DTBs are bad but because vendors and programmers like to change symbols inside the dtb at every kernel release. In theory since the DTB are part of the kernel ABI, I should need a new DTB when going from kernel 4.x to kernel 5.x and not at every odd kernel release like is currently happening.
_________________
Ok boomer
True ignorance is not the absence of knowledge, but the refusal to acquire it.
Ab esse ad posse valet, a posse ad esse non valet consequentia
My fediverse account: @erm67@erm67.dynu.net |
|
| Back to top |
|
|
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
| Posted: Fri Oct 11, 2019 11:13 pm Post subject: |
|
|
I wish ARM SBCs used enumerable buses so that I don't need to care about a device tree.
How about odroid-c1+ and odroid-c2? Are they easy to configure and supported by mainline linux and mainline u-boot? |
|
| Back to top |
|
|
crocket
Guru
Joined: 29 Apr 2017
Posts: 558
|
| Posted: Sat Dec 14, 2019 11:36 pm Post subject: |
|
|
| erm67 wrote: | | I2S sound cards are just a gimmick to sell, most of them are just crap. It is just that some people love to have exotic stuff like an I2S bus, but nobody really understands why trasmitting the same digital data over a slow exotic bus like I2S should be better than doing that over the USB bus exp. if the same DAC chipset is connected to the bus .... most of the problems are caused by noise coming from the PSU or ground loops. Oh so called "USB purifiers" that allegedly clean the 5V of the USB port are just a scam as well, if the USB sound card sucks and doesn't filter the power line it will just suck a bit less with "purifier" maybe and most importantly even a cheap china usb sound card with an spdif out configured to passthrough digital data to an external amplifier will make a better job than every I2S sound card. |
Raspberry Pi 4B USB ports are still noisy according to Raspberry Pi 4B for music playback.
That's why you can benefit from I2S DACs. I2S bus is cleaner on Raspberry Pi.
But, I read that limiting ethernet speed to 100Mbps on Raspberry Pi 3 B+ fixed noise pollution on USB DACs.
Perhaps, Raspberry Pi 4B has noiser USB bus than Raspberry Pi 3 B+.
I am using a chinese generic TPA3251 amplifier with my onboard soundcard. This setup produces acceptable sounds for me as long as I subdue crazy power supply noise by lowering the amplifier volume. If I wanted to move the amplifier volume knob beyond 12'o clock, I would need a proper DAC like Topping D10. My usual listening volume is between 8~9'o clock.
By the way, how do you compile mainline linux kernel for Odroid N2? Did hardkernel reveal kernel configuration options for Odroid N2? |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo on ARM
