On Mon, Oct 30, 2017 at 06:31:19PM +0100, Kristian Peters wrote:
> Hi,
> 
> As I thought, a simple addition to acpi/dsdt.c and the Mac mini is able
> to boot. I used the external hard drive from a fresh 6.2-install on
> another computer to that purpose. This patch is tested (tried to compile
> the release under the newly built kernel) and was made against 6.2-release.
> 
> I attach the patch and the dmesg-output of the Mac mini running with the
> patched kernel.
> 
> Can you merge it in -current?
> 
> --- 6.2/src/sys/dev/acpi/dsdt.c Sun May 28 17:36:45 2017
> +++ src/sys/dev/acpi/dsdt.c     Mon Oct 30 16:08:39 2017
> @@ -2488,6 +2488,11 @@
>                         aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
>                             val, mode, fld->v_field.flags);
>                         break;
> +               case ACPI_OPREG_CMOS:
> +                       printf("RegionSpace: %u\n",
> ref1->v_opregion.iospace);
> +                       aml_rwgas(ref1, fld->v_field.bitpos + bpos, blen,
> +                           val, mode, fld->v_field.flags);
> +                       break;
>                 default:
>                         aml_die("Unsupported RegionSpace 0x%x",
>                             ref1->v_opregion.iospace);
> 
> PS: I still fail to build the full release and, thus, also the
> install62.fs image I want to use for installation. So it would be great
> if you consider fixing the issue soon.
> 
> Best wishes, *Kristian
> 

I don't think this is right. It may be "solving" your problem but our rwgas
implementation doesn't handle this type of OpRegion. So, at best, we're ignoring
the request (with the changes above), or worse, perhaps trashing some memory.

Someone needs to add the I/O for this type of region (CMOS NVRAM) to
the gasio code in acpi.c. There is a sequence of IN/OUT instructions that need 
to
occur (in a proper order, with correct locking because the OS is using the
device also) to get at those NVRAM registers. It probably isn't a huge amount
of work, but nobody has stepped up to do it yet.

If you want a workaround, you might try just ignoring ACPI_OPREG_CMOS locally
in your tree. That too isn't right but at least it won't be possibly causing
side effects/damage elsewhere.

-ml

Reply via email to