Re: [PATCH v4 1/2] x86: Support APU5 & APU6 in PCEngines platform driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 09.02.23 07:04, Philip Prindeville wrote:

Hi,


Yes, eth0 on the APU6 is an i210 w/ SFP cage, and i211 on all of the other ports.

oh, did you already check whether that has any influence for userland ?
(different drivers ? different device naming) ?

I've asked PC Engines for a definitive list of what GPIO lines are used for what on all of the current revs of the boards.  I'll share that as soon as I get it.

Good luck :)

Last time tried, I got back some quite incomplete spec. (IIRC still
apu2+3). Had to do lots of trial+error. But at least got some
schematics, already better than most of the other x86 vendors.

If yes then what is the advantage of using the APU driver over the ACPI exported functionality?

Other than ACPI being less than reliable in a lot of cases?

ACK. The problem isn't ACPI itself (except the fact that it's
unnecessarily complicated and huge step backwards compared
to DT, which already existed before), but the board/bios vendors,
who rarely manage to do it right. It seems that those folks are
really acting on fire+forget.

If people wanted to use ACPI instead of the APU driver, why not just build their kernels without the APU driver linked in?

Easier: blacklist the module (those folks are using distro kernels,
which usually use modules for all non-essential drivers).

I've been thinking about this the last few days, and the APU's are all low-power, headless (no video), SBC's. They're designed for embedded usage. That is, they don't have generic distros like Ubuntu (et al) installed on them,

Not quite correct. Semi-embedded, or better lets call it "appliance".
They're officially announced to run with mainline distros, and users
do that. I've built industrial applications running on Debian (actually,
Devuan) with these boxes myself.

NDA forbids telling more clear, but you'll have to climb up large towers
or fly offshore in order to get your hands on them. Yes, environments where stability really matters and field rolls or firmware changes are
the last thing you want.

Changing the kernel and what's visible in user-space typically isn't a problem as long as both happen at the same time. That's what we've done with OpenWRT, adding the 2 new board models, and the mapping of led triggers to GPIO lines.

For your case (openwrt) that might be okay, but doesn't work for
those using mainline distros.


--mtx

--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287



[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux