From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from EUR05-AM6-obe.outbound.protection.outlook.com (EUR05-AM6-obe.outbound.protection.outlook.com [40.107.22.88]) by mx.groups.io with SMTP id smtpd.web10.25657.1639488979370598775 for ; Tue, 14 Dec 2021 05:36:20 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@armh.onmicrosoft.com header.s=selector2-armh-onmicrosoft-com header.b=K4832tIp; spf=pass (domain: arm.com, ip: 40.107.22.88, mailfrom: samer.el-haj-mahmoud@arm.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ktJJ1oBQ6n3AQoCfD+I1HvRpKwhTtZ0ozCKSjC4hK6c=; b=K4832tIpDg3g/v7k1z2Qtp1Edtwzkxd/C4Tv9f0LK5FiapRXBDowstB1koyTC4eVdDUEXfjMKhMcVYuEs97aS68SCE4qtUaJ6L9H1dyJLMqhAryaLNAugnD9CSPopqE4MiJXGpFScfzZsjuT0fmjll87h3oI45a49CxmgzcWRnU= Received: from DB6PR0301CA0057.eurprd03.prod.outlook.com (2603:10a6:4:54::25) by VI1PR08MB3967.eurprd08.prod.outlook.com (2603:10a6:803:df::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.18; Tue, 14 Dec 2021 13:36:08 +0000 Received: from DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:54:cafe::ea) by DB6PR0301CA0057.outlook.office365.com (2603:10a6:4:54::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.15 via Frontend Transport; Tue, 14 Dec 2021 13:36:08 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT013.mail.protection.outlook.com (10.152.20.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12 via Frontend Transport; Tue, 14 Dec 2021 13:36:08 +0000 Received: ("Tessian outbound de6049708a0a:v110"); Tue, 14 Dec 2021 13:36:08 +0000 X-CR-MTA-TID: 64aa7808 Received: from bcffe073fe37.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 70E8709B-2C70-40D9-9648-1C9F26FF3F29.1; Tue, 14 Dec 2021 13:35:58 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bcffe073fe37.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Dec 2021 13:35:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HhhN9fw99/rHcEIpqUlhkpcVe+oVXlK+bTFsZLWgcr0FM/sl7WcsNTj/1X72mmCheJ/rEENeDnE6M1nX/KIctU4dC94lH2Wh3jc+scRH5i/pFsXr4FImdI7Vd32YJkQBhrFqIGH/j2ThNMLYuLhtTYUNONM7ZRnbWLvLUm8iGrIR7Zokmyb8lkuf9dI2D4R7OtOpxqcysyefSMB5kljvTiaLzhxiti3VWYtInMUMIVvm47wpEmXq46o3+4DZuFQAJIVJGBSpFb/EJ+oxcHUK0Gsh0/s3M0gC1hjTm3+2eZJ+8OzioygxrMHWZHCH0fQLZqN1cxf4a97W2dtuoXA+iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ktJJ1oBQ6n3AQoCfD+I1HvRpKwhTtZ0ozCKSjC4hK6c=; b=beHr3jj7EwVySrGrGBmt6KkUGRi/qJ0NeWkDXBfaMA2Y57+xFdg/cUXVnAaaANsZhprkbr/LLRgfvA0EArm/s6lfDD3PLqXMRaUra4B32gfA/pw1GFr2prmYeOoj2qDux1FuttX5mRFoiZykJrExGfQ+KX428/JEvsi0FGmWxOS63Ma3psXkvD26PxtOc4kpubUm1c2bCKtJxRYasK9jsR3NF03RYR/I6repDhP7hqszx7avjFIjB+BgHm5jsd3HTUTsEH5Ec+yr51UVsp6sx8QY/ePh9ol2Sg2o1Vvt4hRx54ppg0NUH8RkLbR/7fkwewTsLDObYZcQ9aI3SRB3Hw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ktJJ1oBQ6n3AQoCfD+I1HvRpKwhTtZ0ozCKSjC4hK6c=; b=K4832tIpDg3g/v7k1z2Qtp1Edtwzkxd/C4Tv9f0LK5FiapRXBDowstB1koyTC4eVdDUEXfjMKhMcVYuEs97aS68SCE4qtUaJ6L9H1dyJLMqhAryaLNAugnD9CSPopqE4MiJXGpFScfzZsjuT0fmjll87h3oI45a49CxmgzcWRnU= Received: from VI1PR08MB5312.eurprd08.prod.outlook.com (2603:10a6:803:139::24) by VI1PR08MB3567.eurprd08.prod.outlook.com (2603:10a6:803:79::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Tue, 14 Dec 2021 13:35:55 +0000 Received: from VI1PR08MB5312.eurprd08.prod.outlook.com ([fe80::9877:2cb:362d:a662]) by VI1PR08MB5312.eurprd08.prod.outlook.com ([fe80::9877:2cb:362d:a662%7]) with mapi id 15.20.4778.018; Tue, 14 Dec 2021 13:35:54 +0000 From: "Samer El-Haj-Mahmoud" To: "devel@edk2.groups.io" , "Andrei Warkentin (awarkentin@vmware.com)" , Jeremy Linton , Ard Biesheuvel , Adrien Thierry , Pete Batard CC: Ard Biesheuvel , Leif Lindholm , Samer El-Haj-Mahmoud Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length Thread-Topic: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length Thread-Index: AQHX6S1uKoC/pXJ/f0WBTqQfwyJp3KwwkDIAgAAFpQCAAEQUAIAArciAgAALhgCAAHYv0A== Date: Tue, 14 Dec 2021 13:35:54 +0000 Message-ID: References: <311d8e92-29c7-e1be-f32d-652d96912be0@arm.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 8C2CA2DB1E26464E9982D81E870FE187.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: a77ff6c6-673c-4b5b-d214-08d9bf06af64 x-ms-traffictypediagnostic: VI1PR08MB3567:EE_|DB5EUR03FT013:EE_|VI1PR08MB3967:EE_ x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6108;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: dldj06WO/uCuOfKFwbdQFfqv790XH9GjeErKgv4JEDOVhJPU+Xn83d2kkQ8+uN8E1vKXbw9wSaNCm5miNDAHBERWl5Pg8lEw+kr+RO4v1OXHZ7Z9bNhpE7xiQFXyAcvpt5oKqaTLNRYF0TmSG0OUlHUQJDNN7rXc/TQnY4sEib9Y4SgZEy+4ZnvKbzGOacNUeMKG0+haI5aBmNt1HXX85JgTnxSZuQulBW4Wad0NR9bvrBpg5CtWoGd1oGQ0Nimt9cCHask8UJ5UGBfODt9VL8y5rFMQlJIGr9m48q7o9/HgeyrEBSsBaKtdiVkdLxYs/+klvmaTu+pRRUV0LHpEWvMW6oCg93rA0/XJzyceym9IdkLDl6x1v9gtaV0jIHBzekj3bUVCvXFznF87mLAMbejce97Phmee0h8cD187QFV30wCSdvTJ2CjTWvdjgTBez5TqsF4hyp6cUNYvs4m3E+nS/1FGRsxW/z/qayazwiQ+/qRe5aO7URl3ql9+M03r9bQJ6z/xOXwgA8Hbcy5DlD+vgUm8CxHsvp5mhtX22wXVieMQMjbpBeMTDc3YCSZV0gmkNPxyZaFrWAgeIXP3+8z2fW0lgRhzyDqQ4cax+Ka4hFypVYLk9pwdmgORweqDh6bff2rCxPm/0XuglwpyO4PZA6B2qlPxmSpXdP0mlIzDN6WUUNPXuuv+F6Bxbvxaf9ShGQ3lcPPwBY30Xwb4syyJ0wrbHi9E8ANIUguQH2Pd0NkYsgYQy1U7vCwqYbcbjr+idzQWpIH5Dpq8YK24BsRIY/ZoIhP9lsPPGVpSe6Wyfi3d/3GmJYSFyFAfSlPWj13uMS/HndAXQekrlPScMQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:VI1PR08MB5312.eurprd08.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(366004)(33656002)(5660300002)(45080400002)(54906003)(53546011)(508600001)(86362001)(83380400001)(52536014)(7696005)(316002)(110136005)(8676002)(66446008)(166002)(38070700005)(8936002)(76236003)(71200400001)(4326008)(186003)(66476007)(2906002)(966005)(26005)(6506007)(122000001)(66946007)(64756008)(55016003)(9686003)(38100700002)(76116006)(66556008);DIR:OUT;SFP:1101; MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3567 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Return-Path: Samer.El-Haj-Mahmoud@arm.com X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 5c38f71b-615f-476e-7aab-08d9bf06a773 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3l7cj+wrA9H3VgzT93ntqJAwQ3lN5SEFb/xzMroi90vOUJ4la8uWh47q7DkaNPZaSzgvY+jDegO9GQL3E1z/Cw20Jds+PIYPv2JzlgE6jCjZmF2TeDFBcAJxjJ8tzg9zIWNzDuLu6FsefiI1JuEuA2YUB6Ch2rVI+6z2/lMAPu+SMb7nIpJQg0swvQllYKUEk62oANVoq+uS/2LhxMCiqVdmmnTGvVuIXUtlp7ZdjJ1lTAU7S/3LO6xijgfTbTMKsPqW7K65NQzhSlaY2g0xJVvKMIH4lMH9I7nsi1eVkJO8CYteT7YvSOAWq86YrkIUy8+eCa5APkrD/95+2HWBLUJSdvOJGbiVVktzCe7C/Nm+2amdOwJ3sqvMNCAvie2IAvUPJhajayRKziUvCX4N8ZjBm4tB19/GlQ9GdeaYHSrGC8spKvxyRFHNA5RrYzaG7RVdnaf1tn1sJV2eLuF034JcIoEl7ew71Kt1HwYuyc2HCyKPk5pDLry4fHVkKCCOGZt2bMga+IyXuBMyO0gROJNUeDUULMlrNvkfddFFxyrxELlExc/SAeeO1dcF7ZQx/aq+OmIPJ5AM5cCns0F2Jxmj4YLKUzohecpeXayYojG3IQYPHPOlz65xeysEHFXSB0RXmEqdXM7ee6TXFsn6ZBs5u8HY5BHte2Bdtwn1RWjJCfZQ+WwPrf0VSLMPn09YDrKd9z8QtI0kjk7C2Qn0IAGsPH8zCoZCwK/D06oB79qao/WaGa6vLT2QHex9a49+Xgubyn6Tp+9nezi5ZWPQZbFNPUL4jQwr4DhUgvT0UG380y4WYMEL47XSEpa0ONlyZE6bnoDzabXEus6B2HFAHYZeNOFWIpCHcAOcNjVPFyXpjjarSnRqkTIGhjhsDNLEAddwApo9Y5iG7PBTZN6hHA== X-Forefront-Antispam-Report: CIP:63.35.35.123;CTRY:IE;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:64aa7808-outbound-1.mta.getcheckrecipient.com;PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com;CAT:NONE;SFS:(4636009)(36840700001)(46966006)(40470700001)(52536014)(47076005)(5660300002)(86362001)(81166007)(82310400004)(30864003)(55016003)(40460700001)(166002)(356005)(966005)(508600001)(45080400002)(33656002)(70586007)(70206006)(26005)(9686003)(8676002)(36860700001)(336012)(54906003)(2906002)(316002)(110136005)(6506007)(76236003)(53546011)(7696005)(4326008)(8936002)(83380400001)(186003);DIR:OUT;SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Dec 2021 13:36:08.2808 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a77ff6c6-673c-4b5b-d214-08d9bf06af64 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d;Ip=[63.35.35.123];Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT013.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3967 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_VI1PR08MB53127C8847D20BF19311906090759VI1PR08MB5312eurp_" --_000_VI1PR08MB53127C8847D20BF19311906090759VI1PR08MB5312eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see that DBG2/SPCR spec (https://docs.microsoft.com/en-us/windows-hardwar= e/drivers/bringup/acpi-debug-port-table) defines 0x10 for Serial type for B= CM2835: 0x0010 BCM2835 Should the spec be updated to make this more explicit? i.e. "BCM283x/BCM27x= x MiniUART" From: devel@edk2.groups.io On Behalf Of Andrei Warke= ntin via groups.io Sent: Tuesday, December 14, 2021 1:21 AM To: Jeremy Linton ; devel@edk2.groups.io; Ard Bieshe= uvel ; Adrien Thierry ; Pete Batard <= pete@akeo.ie> Cc: Ard Biesheuvel ; Leif Lindholm Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix = miniuart base address and length The Raspberry Pi support in edk2-platforms, including ACPI, is a direct anc= estor of the original ms-iot tree (https://github.com/ms-iot/RPi-UEFI, by w= ay of https://github.com/andreiw/RaspberryPiPkg). The way the miniUART is described in ACPI came from Microsoft. Microsoft in= troduced DBG2/SPCR type 0x10 (https://docs.microsoft.com/en-us/windows-hard= ware/drivers/bringup/acpi-debug-port-table) and the BCM2836 _HID to describ= e the miniUART, and the contract is that the base address includes all thos= e crazy registers. To the best of my knowledge, today there isn't any other way to correctly d= escribe the miniUART in a DBG2, SPCR or DSDT. Moreover, because there's cod= e out there in at least two operating systems coded against these specific = definitions, you don't get to change how a _HID =3D=3D BCM2836 device or SP= CR/DBG2 type 0x10 is described. If you wanted to introduce an alternate mechanism to describe the miniUART = - great. You'd have to pick a new _HID. And re-use one of the generic DBG2/= SPCR types or cajole for a new one (I'm guessing in the ASWG but I really d= on't know). But you surely can't haphazardly change an existing firmware<->= OS contract. Moreover, you can't deprecate the existing contract overnight = as well, so you'd have to add an option to expose the miniUART using a pres= umably more-Linux friendly option. If you do introduce a new mechanism to describe the miniUART in ACPI, I'm h= appy to add support for it in ESXi, paving the way for eventual deprecation= of the current mechanism (assuming you get all the other OSes to play ball= too...) Still a NAK. It's not a fix because it's not broken. And it's not considere= d broken just because you don't like the definitions. I don't like the defi= nitions either, but that's all we got. A ________________________________ From: Jeremy Linton > Sent: Monday, December 13, 2021 11:39 PM To: devel@edk2.groups.io >; Andrei Warkentin >; Ard Biesheuvel >; Adrien Thierry = >; Pete Batard > Cc: Ard Biesheuvel >; Leif Lindholm > Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix = miniuart base address and length Hi, On 12/13/21 13:17, Andrei Warkentin via groups.io wrote: > If I understand correctly, you want to describe the UART at 0x00215000 to= be at 0x00215040. > > This will break SPCR and DBG2 - so that's a regression for Windows, ESXi = and possibly the NetBSDs. > > I guess that's a NAK unless I misunderstood something. Presumably the end goal is to get BT working, or are we trying to get the console working too? Either way, the historical SPCR definition is less than ideal because it covers those AUX_IRQ/AUX_ENABLE registers which include information for the SPI which isn't included in the "uart" definition here. So, IMHO it is wrong, but its stuck that way unless we define another uart. Which if all we wanted it for was BT then we could just create another device under BCM2836 which is only the 8250 like registers. That is sorta ugly, but not having a standard uart is ugly too. The other ugly thing is to just use the address as is, and offset it by 0x40 in linux as part of the clock and ACPI bindings linux patch. (i've got a patch to make it work someone wants to bite into it. Lol). For linux the base clock-rate is going to have to be added as a _DSD too. Which I assume is a large part of why it has a custom SPCR id? Put another way, is anyone using the extra AUX_ registers, and what else are people (windows/etc) "quirking" with the SPCR id? For linux I've not particularly felt the need to fix this because I had BT working (although unreliably) this time last year when I was working on the SD/SDIO drivers, and my answer at the time was that one either gets a serial console using the pl011 or one gets BT with the pl011. But it looks like at a minimum the linux-firmware project and the brcmfmac firmware loader have been tweaked over the past year and getting BT working isn't as simple as just taking the miniuart-bt line out of config.txt as I have in my not particularly good notes from that time period. So, while its behaving like it did when it had bad firmware, it could be something in the lower level firmware since attempting to roll back to an older firmware/kernel I had on another disk didn't immediately fix it. > ________________________________ > From: Ard Biesheuvel > > Sent: Monday, December 13, 2021 9:14 AM > To: Adrien Thierry >; And= rei Warkentin >; Pete B= atard > > Cc: edk2-devel-groups-io >; Ard Biesheuvel >; Leif Lindholm > > Subject: Re: [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart ba= se address and length > > On Mon, 13 Dec 2021 at 15:54, Adrien Thierry > wrote: >> >> Hi Ard, Leif, Pete >> >> Do you have any feedback on this patch ? >> > > No objections from me but I'd like an ack from someone else as well. > > > > > > IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_VI1PR08MB53127C8847D20BF19311906090759VI1PR08MB5312eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see that DBG2/SPCR spec (= https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debu= g-port-table) defines 0x10 for Serial type for BCM2835:

 

0x0010

BCM2835

 

Should the spec be updated to make this more explici= t? i.e. “BCM283x/BCM27xx MiniUART”

 

 

 

From: devel@edk2.groups.io <devel@edk2.gro= ups.io> On Behalf Of Andrei Warkentin via groups.io
Sent: Tuesday, December 14, 2021 1:21 AM
To: Jeremy Linton <Jeremy.Linton@arm.com>; devel@edk2.groups.i= o; Ard Biesheuvel <ardb@kernel.org>; Adrien Thierry <athierry@redh= at.com>; Pete Batard <pete@akeo.ie>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm = <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryP= i: Fix miniuart base address and length

 

The Raspberry Pi support in edk2-platforms, including ACPI, i= s 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-d= ebug-port-table) and the BCM2836 _HID to describe the miniUART, and the contract is that th= e base address includes all those crazy registers.

 

To the best of my knowledge, today there isn't any o= ther way to correctly describe the miniUART in a DBG2, SPCR or DSDT. Moreov= er, 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 =3D=3D BCM2836 device or SPCR/DBG2 type= 0x10 is described.

 

If you wanted to introduce an alternate mechanism to= describe the miniUART - great. You'd have to pick a new _HID. And re-use o= ne of the generic DBG2/SPCR types or cajole for a new one (I'm guessing in = the ASWG but I really don't know). But you surely can't haphazardly change an existing firmware<->OS co= ntract. Moreover, you can't deprecate the existing contract overnight as we= ll, so you'd have to add an option to expose the miniUART using a presumabl= y more-Linux friendly option.

 

If you do introduce a new mechanism to describe the = miniUART in ACPI, I'm happy to add support for it in ESXi, paving the way f= or eventual deprecation of the current mechanism (assuming you get all the = other OSes to play ball too...)

 

Still a NAK. It's not a fix because it's not broken.= And it's not considered broken just because you don't like the definitions= . I don't like the definitions either, but that's all we got.

 

A

 

From: Jeremy Linton <jeremy.linton@arm.com>
Sent: Monday, December 13, 2021 11:39 PM
To: devel@edk2.groups.io= <devel@edk2.groups.io>; = Andrei Warkentin <awarkentin@vm= ware.com>; Ard Biesheuvel <ard= b@kernel.org>; Adrien Thierry <athierry@redhat.= com>; Pete Batard <pete@akeo.ie>
Cc: Ard Biesheuvel <= ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryP= i: Fix miniuart base address and length

 

Hi,

On 12/13/21 13:17, Andrei Warkentin via groups.io wrote:
> If I understand correctly, you want to describe the UART at 0x00215000= to be at 0x00215040.
>
> This will break SPCR and DBG2 - so that's a regression for Windows, ES= Xi and possibly the NetBSDs.
>
> I guess that's a NAK unless I misunderstood something.

Presumably the end goal is to get BT working, or are we trying to get
the console working too?

Either way, the historical SPCR definition is less than ideal because it covers those AUX_IRQ/AUX_ENABLE registers which include information for the SPI which isn't included in the "uart" definition here. So, I= MHO it
is wrong, but its stuck that way unless we define another uart. Which if all we wanted it for was BT then we could just create another device
under BCM2836 which is only the 8250 like registers. That is sorta ugly, but not having a standard uart is ugly too. The other ugly thing is to
just use the address as is, and offset it by 0x40 in linux as part of
the clock and ACPI bindings linux patch. (i've got a patch to make it
work someone wants to bite into it. Lol).

For linux the base clock-rate is going to have to be added as a _DSD
too. Which I assume is a large part of why it has a custom SPCR id? Put another way, is anyone using the extra AUX_ registers, and what else are people (windows/etc) "quirking" with the SPCR id?

For linux I've not particularly felt the need to fix this because I had BT working (although unreliably) this time last year when I was working on the SD/SDIO drivers, and my answer at the time was that one either
gets a serial console using the pl011 or one gets BT with the pl011. But it looks like at a minimum the linux-firmware project and the brcmfmac
firmware loader have been tweaked over the past year and getting BT
working isn't as simple as just taking the miniuart-bt line out of
config.txt as I have in my not particularly good notes from that time
period.

So, while its behaving like it did when it had bad firmware, it could be something in the lower level firmware since attempting to roll back to
an older firmware/kernel I had on another disk didn't immediately fix it.


> ________________________________
> From: Ard Biesheuvel <ardb@kerne= l.org>
> Sent: Monday, December 13, 2021 9:14 AM
> To: Adrien Thierry <athierry= @redhat.com>; Andrei Warkentin <awarkentin@vmware.com>; Pete Batard <pete@akeo.ie>
> Cc: edk2-devel-groups-io <d= evel@edk2.groups.io>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Leif Lindholm <leif@nuviainc.com>
> Subject: Re: [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart= base address and length
>
> On Mon, 13 Dec 2021 at 15:54, Adrien Thierry <athierry@redhat.com> wrote:
>>
>> Hi Ard, Leif, Pete
>>
>> Do you have any feedback on this patch ?
>>
>
> No objections from me but I'd like an ack from someone else as well. >
>
>
>
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_VI1PR08MB53127C8847D20BF19311906090759VI1PR08MB5312eurp_--