From: Ville Ilvonen <ville.ilvonen@unikie.com>
To: discuss@spectrum-os.org
Subject: HW identification and configuration on Spectrum
Date: Tue, 16 Aug 2022 18:50:48 +0300 [thread overview]
Message-ID: <CAP-nJwHTmROzMbyYNtrTrOdXGV-iJvwPuJ3FSZb3gLy5R3z80Q@mail.gmail.com> (raw)
Hi,
Now that we've been developing Spectrum ARM (aarch64) support
with iMX8 boards, I'd like to get back to Spectrum HW configuration design.
On x86 the generic image with kernel supporting most devices as modules can
make sense. On ARM, the vendor specific BSP HW quirks are more common.
As of now, the spectrum fork for aarch64 just adds another config
after rpi configs
and replaces the default config to use that to build. With small
changes this could
be handled like rpi configs. In addition, cloud-hypervisor accepts
kernel only in
EFI format for aarch64[1]. Anyway, this would allow us to build an
aarch64 Spectrum installer
- even make it with a more generic kernel. That takes us to ARM
vendor/device specific HW
quirks which would need to be handled anyway. I'll intentionally leave
device specific
kernel hardening and disabling kernel module loading for security
reasons for now.
As of now the vendor/device specifics are not supported unless one builds device
specific Spectrum image with all configs build-time and skips
installer altogether.
The other option that I see. We discussed earlier nix-hardware and
device specific modules.
That would bring nixos configuration.nix and installation supporting
scripts to Spectrum,
though. Those could be called from the Spectrum installer but it would
change the installer
logic from writing an image to dynamically configuring the device
during install based on user
selections.
Any thoughts which would be the preferred way? Maybe some other way?
In the end, HW specifics are needed also on x86 as we saw with NUCs
and different
Lenovo laptops in the spring. I'm not convinced one image to rule them
all is realistic or secure.
Finally, this is by no means blocking the hardened iMX8 based Spectrum
development
but will keep that work in Spectrum fork until there's an agreed path
to implement this.
Integrating this sooner and making it more generic would make Spectrum
more useful
for a wider audience.
Best regards,
-Ville
[1] https://github.com/tiiuae/spectrum/pull/3#issuecomment-1211834302
next reply other threads:[~2022-08-16 15:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-16 15:50 Ville Ilvonen [this message]
2022-08-17 7:52 ` Alyssa Ross
2022-08-17 13:25 ` Ville Ilvonen
2022-08-17 13:39 ` Alyssa Ross
2022-08-18 9:15 ` Ville Ilvonen
2022-08-18 10:17 ` Development on the Spectrum host Alyssa Ross
2022-08-19 6:26 ` Ville Ilvonen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAP-nJwHTmROzMbyYNtrTrOdXGV-iJvwPuJ3FSZb3gLy5R3z80Q@mail.gmail.com \
--to=ville.ilvonen@unikie.com \
--cc=discuss@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).