Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Jan 2003 19:40:30 +0100
From:      Ducrot Bruno <ducrot@poupinou.org>
To:        Nate Lawson <nate@root.org>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: bad ACPL asl's on motherboards
Message-ID:  <20030116184030.GX12516@poup.poupinou.org>
In-Reply-To: <Pine.BSF.4.21.0301160944210.46845-100000@root.org>
References:  <20030116171203.GW12516@poup.poupinou.org> <Pine.BSF.4.21.0301160944210.46845-100000@root.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 16, 2003 at 09:46:46AM -0800, Nate Lawson wrote:
> On Thu, 16 Jan 2003, Ducrot Bruno wrote:
> > It sound like a good idea.  However, there is a lot of isssues evolved.
> > First, a DSDT table can and will be generated autmatically on the POST,
> > because at least the memory controller can have different configurations
> > depending on the total amount of the system memory than need to be
> > reflected in the DSDT table.  Second, even if this is ok, you have
> > to consider that an OEM can have made modifications to their AML to
> > correct some bugs and justifying a bios upgrade.  You loose then those
> > bug fixes.
> 
> We have a way of overriding the bios:
> acpi_dsdt_load="YES"            # DSDT Overriding
> acpi_dsdt_name="/boot/abitBP6.aml"
>                                 # Override DSDT in BIOS by this file

The question is not to have a way of overriding the DSDT table, but
if this is ok or a no-go to provide in 5.0-current well known AML.

My point of view is that if you make such thing you can
have more issues.

Suppose you have 256Mo of ram, then you upgrade to 512Mo.  The override
will work, but then the DSDT you provided can potentially be not the
right one.

Here is an ASL example:

                OperationRegion (SMI0, SystemIO, 0x0000FE00, 0x00000002)
                Field (SMI0, AnyAcc, NoLock, Preserve)
                {
                    SMIC,   8
                }

                OperationRegion (SMI1, SystemMemory, 0x0FEFFEBD, 0x00000090)
                Field (SMI1, AnyAcc, NoLock, Preserve)
                {
                    BCMD,   8, 
                    DID,    32, 
                    INFO,   1024
                }

                Field (SMI1, AnyAcc, NoLock, Preserve)
                {
                    AccessAs (ByteAcc, 0x00), 
                    Offset (0x05), 
                    INF,    8
                }

                Mutex (PSMX, 0x00)
                Method (PHSS, 1, NotSerialized)
                {
                    Acquire (PSMX, 0xFFFF)
                    Store (0x80, BCMD)
                    Store (Arg0, DID)
                    Store (Zero, SMIC)
                    Release (PSMX)
                }

The latop here have 256Mo ram.  Actually, the OP of SMI1 is on the non-volatile
of the ACPI space.

When the method PHSS is called, then all is OK.

Now, if I upgrade to 512Mo, the OP SMI1 need to be declared as

                OperationRegion (SMI1, SystemMemory, 0x1FEFFEBD, 0x00000090)

or else the AML interpreter will report an error.  I need then to change
the /boot/foobar.aml file.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030116184030.GX12516>