svn commit: r297954 - in head/sys: boot/efi/loader/arch/amd64 boot/i386/libi386 x86/acpica
Ian Lepore
ian at freebsd.org
Thu Apr 14 16:49:32 UTC 2016
On Thu, 2016-04-14 at 10:43 -0600, Warner Losh wrote:
> On Thu, Apr 14, 2016 at 2:22 AM, Andrew Turner <andrew at fubar.geek.nz>
> wrote:
>
> > On Thu, 14 Apr 2016 04:59:51 +0000 (UTC)
> > Warner Losh <imp at FreeBSD.org> wrote:
> >
> > > Author: imp
> > > Date: Thu Apr 14 04:59:51 2016
> > > New Revision: 297954
> > > URL: https://svnweb.freebsd.org/changeset/base/297954
> > >
> > > Log:
> > > Deprecate using hints.acpi.0.rsdp to communicate the RSDP to
> > > the
> > > system. This uses the hints mechnanism. This mostly works today
> > > because when there's no static hints (the default), this value
> > > can
> > > be fetched from the hint. When there is a static hints file, the
> > > hint
> > > passed from the boot loader to the kernel is ignored, but for
> > > the
> > > BIOS case we're able to find it anyway. However, with UEFI, the
> > > fallback doesn't work, so we get a panic instead.
> > >
> > > Switch to acpi.rsdp and use TUNABLE_ULONG_FETCH instead.
> > > Continue to
> > > generate the old values to allow for transitions. In addition,
> > > fall
> > > back to the old method if the new method isn't present.
> > >
> > > Add comments about all this.
> > >
> > > Differential Revision: https://reviews.freebsd.org/D5866
> >
> > Why not pass it in using module data as we do with the DTB? It
> > would
> > fix issues where we have either or both static hints and a stat
> > env.
> >
>
> I viewed that as brittle. And it was longer to code. This works with
> static
> hints, but not static env. Static env tends not to be used on x86.
>
> I'm open to putting it into module data as a more robust solution. I
> just
> didn't have the extra time it would take to do so at the moment.
>
Another thing that I think should be passed the way we pass loaded
modules is GELI password and/or key data. It's currently passed in the
environment, and static env subverts that. While static env has mostly
been an embedded-system thing to date, there is more x86 embedded
hardware hitting the market these days.
Maybe we need some helper code to make it easy to encapsulate data in a
module-like form on the loader side, and access it from the kernel
side, to make it easier to pass binary data from the loader without
having to ascii-encode it into the environment.
-- Ian
>
> > Whatever method is decided we will also need it on arm64 as we
> > claim to
> > support ACPI there, although no backwards compatibility will be
> > needed
> > as the code is most likely broken as it's only partially been
> > tested.
> >
>
> Yes. The issue is with ACPI + UEFI. With ACPI + BIOS, we could find
> things always, and this didn't matter. This change doesn't change
> that.
> But for UEFI, the RSDP table can be (and often is) located in areas
> the code doesn't search.
>
> We likely need to unify more than just passing in the RSDP, since if
> we want
> to callout to UEFI after the kernel has booted, there's a number of
> other
> things that need to be passed as well. I have a review that gets this
> working
> on x86 that I'll open up when more of my backlog has been pushed into
> the tree. I'll be sure to include you.
>
> Warner
More information about the svn-src-all
mailing list