From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::141; helo=mail-it1-x141.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-it1-x141.google.com (mail-it1-x141.google.com [IPv6:2607:f8b0:4864:20::141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 334F8210D9791 for ; Tue, 29 Jan 2019 04:57:46 -0800 (PST) Received: by mail-it1-x141.google.com with SMTP id h193so4296244ita.5 for ; Tue, 29 Jan 2019 04:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fw0gCFWgWfVJIKXU/uAiWoexJrzNSjdmCfN/3PA3+tU=; b=axp7B/QTU21X7C4VXStB85TWgsQwQbUAfjlfiY1mGRGWu6c5Te4m9HoFuuUVq+EfVI 74BKTa1njIgZXSKqKWIuQ6OZzaxBHUezmsA0vxOmqdsgZQ+fEKyF7sjh2GGjrp1GixNZ Dt3FVPK1rY8GHRpMyIokKzHJ6iLa0BFC5z310= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fw0gCFWgWfVJIKXU/uAiWoexJrzNSjdmCfN/3PA3+tU=; b=MWwkq6yToDH9+bsaHi4iUBc5HhiyCUaWfyhf79qeUJYDhzKgrECnQ503BWaGmy0z42 T7UuxJ8XuYKk69V2f30bDPmfFTzfJrBkt7GKHayf+P8qYmu9sLzQqoJ8QjPacztYkPr/ LepttlCuR3o/ciOBfXc/lpT7BLCCLdoU3lXwZQOgbcBKYpS+EqeS4rxsJPKhCPBNjoTP tPeIE/j7/SxeYxtvQaPeuRSWSLYLhThU3XflS5fPdUEAYmaZHSK8UbbnZoqIPGolZr5t XYPCXAiAaY7jJFIeSaX24134qdeq2hKo9W3klUl8WKk1S1fDObUI47+f96Cp1WxrGhOE Gzcg== X-Gm-Message-State: AJcUukdp4ENvxcOW32pbLVVHV7oazkS7aOkTn4dzPKqirklOvObx6/h5 xEQHlXeE7ENBFenghDpBOgJASr06w7XYcITNqRbeUIpDlYk= X-Google-Smtp-Source: ALg8bN4G3PurVjR7VcE6hGSymFu6gxR6+j1rBliaPrNft7vcxO/nil9prEriI/DtoqMgyELzz70RIVcftEQ+5ICOgVs= X-Received: by 2002:a05:660c:4b:: with SMTP id p11mr13392534itk.71.1548766666027; Tue, 29 Jan 2019 04:57:46 -0800 (PST) MIME-Version: 1.0 References: <20190128124445.9868-1-pete@akeo.ie> <20190128124445.9868-4-pete@akeo.ie> In-Reply-To: From: Ard Biesheuvel Date: Tue, 29 Jan 2019 13:57:34 +0100 Message-ID: To: Pete Batard , Leif Lindholm Cc: "edk2-devel@lists.01.org" Subject: Re: [PATCH v3 edk2-platforms 03/23] Platform/Raspberry/Pi3: Add ACPI tables X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2019 12:57:47 -0000 Content-Type: text/plain; charset="UTF-8" On Tue, 29 Jan 2019 at 13:54, Pete Batard wrote: > > Hi Ard, thanks for the reviews, > > On 2019.01.28 13:24, Ard Biesheuvel wrote: > > A couple of general remarks on these tables. > > > > - AFAICT (but is is difficult to tell from the binary dumps), these > > are based on ACPI 5.0, which predates the introduction of ARM support > > into the spec. That essentially makes them Windows-only, and not spec > > based, which is unfortunate. However, since this SoC does not have an > > interrupt controller permitted by ACPI, that actually does not matter > > a lot in practice. > > Publicly, these tables are only meant to boot Windows and we got them > from Microsoft. So they are not exactly meant to be ACPI compliant (for > instance, AFAIK, there's no definition of ACPI that includes the RPI > interrupt controller). > > As such, we really don't want to touch these because we have run into > nightmarish situation where Windows wouldn't boot at all after we tried > to alter them. > > In other words, if we are to try to change much in here, we will > probably need to have Microsoft's involvement... > > > - _CID fields should be properly formatted ACPI or PNP handles, you > > can't put arbitrary strings in there (like BCMAUXSPI or VC4) > > The Microsoft Windows drivers expect those exact IDs, so that's not > something we can alter either. Once again, these ACPI tables were not > designed to be ACPI compliant, and making them so that late in the game > is going to break a lot of things downstream, so we don't believe that > we can do that at this stage. > No, I kind of figured that. It is just very unfortunate that we have two completely separate descriptions for Windows vs Linux, so that is why I brought it up. > > I will apply your other request for ACPI (drop the "-mcmodel=tiny" > workaround in [BuildOptions]), as well as the changes you requested for > 1/2/19 and, if you are okay with having our hands tied with regards to > ACPI compliance, submit a v4 later on today. > Sure, although I was expecting Leif to chime in as well. Leif?