linux-kernel - Re: Dealing with custom hardware on x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211124104723.GA8909@duo.ucw.cz>
Date:   Wed, 24 Nov 2021 11:47:23 +0100
From:   Pavel Machek <pavel@....cz>
To:     Chris Packham <Chris.Packham@...iedtelesis.co.nz>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Dealing with custom hardware on x86

Hi!

> I'm about to start a project involving custom hardware using an x86 CPU. 
> Complicating things somewhat we will have a CPU board supplied by a 3rd 
> party vendor using a COM Express type 7 connector which will plug in to 
> the board we're designing (actually 2 different boards each with some 
> modular aspects) .
> 
> Coming from an embedded (mostly ARM) background I'm used to describing 
> the hardware via a devicetree and dealing with plug-in modules by 
> loading devicetree overlays. How do people achieve this kind of thing on 
> x86?
> 
> I gather ACPI is involved somewhere but the knowledge that the BIOS has 
> will go as far as the COM Express header and somehow we'll have to tell 
> the kernel about the various non-probeable (mostly i2c) devices on our 
> board which is kind of where I'm stuck. Any pointers would be greatly 
> appreciated.

In x86 land, we usually use PCI/PCIE and have a add-on board expose
unique IDs with driver knowing what the IDs are. ACPI should not be
involved for add-on boards.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

Download attachment "signature.asc" of type "application/pgp-signature" (196 bytes)