From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by mx.groups.io with SMTP id smtpd.web10.3432.1639612393569984844 for ; Wed, 15 Dec 2021 15:53:13 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: arm.com, ip: 217.140.110.172, mailfrom: jeremy.linton@arm.com) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5656F1042; Wed, 15 Dec 2021 15:53:12 -0800 (PST) Received: from [192.168.122.166] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 139953F5A1; Wed, 15 Dec 2021 15:53:12 -0800 (PST) Message-ID: <877303fd-543a-19e9-1ef7-c74c795cb693@arm.com> Date: Wed, 15 Dec 2021 17:53:11 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length To: Adrien Thierry Cc: Andrei Warkentin , "devel@edk2.groups.io" , Ard Biesheuvel , Pete Batard , Ard Biesheuvel , Leif Lindholm References: <311d8e92-29c7-e1be-f32d-652d96912be0@arm.com> <737961b2-c92d-9d47-46eb-0631a08a2bbc@arm.com> From: "Jeremy Linton" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, On 12/14/21 16:49, Adrien Thierry wrote: >> The Raspberry Pi support in edk2-platforms, including ACPI, is a direct ancestor of the original ms-iot tree (https://github.com/ms-iot/RPi-UEFI, by way of https://github.com/andreiw/RaspberryPiPkg). >> The way the miniUART is described in ACPI came from Microsoft. Microsoft introduced DBG2/SPCR type 0x10 (https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table) and the BCM2836 _HID to describe the miniUART, and the contract is that the base address includes all those crazy registers. >> >> To the best of my knowledge, today there isn't any other way to correctly describe the miniUART in a DBG2, SPCR or DSDT. Moreover, because there's code out there in at least two operating systems coded against these specific definitions, you don't get to change how a _HID == BCM2836 device or SPCR/DBG2 type 0x10 is described. > > Thanks for your feedback! > I only had Linux in mind and didn't think about the other implementations > that would break. Thank you for stating the historical reasons why things > are set that way, I better understand now and see why this patch wouldn't > be such a great idea. > >> I guess I wasn't clear, I wasn't suggesting we change the existing >> mechanism, so yes, I agree we either need another mechanism, or linux is >> going to have to deal with it as is. The latter is IMHO the best option >> (and as I mentioned I have patches to make it work), but sort of moves >> us away from the standard uart/etc mechanisms we want for systemready. >> So in that regard its not ideal. > > I'm very interested to play with your patches if you could send them :) > I've been trying to add ACPI support to the miniuart Linux driver, and > stumbled across two issues: I sent you a hatchet job that works with the current firmware. > - the miniuart base address "off by 0x40" in the DSDT (the subject of > this thread) I think a reasonable choice is probably to add a structure to the linux acpi_device_id table, and put the offset in there, retrieve it during _probe with the macro that checks for a acpi device and picks off the acpi device match entry and then add the offset to the resource. > - how to properly get the clock rate with ACPI Again if you look in the Uart.asl file you modified at the pl011, you will see that there is a clock-frequency DSD. Something similar appears to work on the pi4 since the miniuart clock doesn't appear to be changing over core frequency changes, and if that starts it looks like ACPI won't be the only victim. > > Ideally, the end goal would be to have both the serial console and BT > working with the miniuart. > > Adrien >