From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web08.33127.1639522146940348118 for ; Tue, 14 Dec 2021 14:49:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=W7tTNZ+A; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: athierry@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639522146; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=SFAgIuHEu0CLNkLsauy4yoa/R4Heq94YUEstnrjwCn4=; b=W7tTNZ+Az9Po4gdfzl+ObpTSj/rfK21RDghvRYTM39FPyfrB/ean4ZJnMnCoAWHlQ+kgEn //hg4Zd/TZ22SEycOR8nQzC4BDm4xKwnxDxKyKF2rohIzb0e76gUUalV3K5SK5gWculxVh xuFq+YG8/lHY2+IzuIdH6pPJSnrPNy8= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-57-nwRWMkZgN6WHZZ6eWU5sCA-1; Tue, 14 Dec 2021 17:49:03 -0500 X-MC-Unique: nwRWMkZgN6WHZZ6eWU5sCA-1 Received: by mail-qt1-f197.google.com with SMTP id e14-20020a05622a110e00b002b0681d127eso28233347qty.15 for ; Tue, 14 Dec 2021 14:49:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=SFAgIuHEu0CLNkLsauy4yoa/R4Heq94YUEstnrjwCn4=; b=zJx7aQwJPHLCkOQ+WPofgvcnbh59nrKt1YDIDCbB7/Vx1NRgjFajksS8tEZH0k0ymV QMxMYE/z0OOT61cB31dTyeR7RA2lNgkFipmLyuiybOPOwI3oc789+QUVZmAG0Wkf61pE PdAY0qKjQwsTHL3ChhdaV5fRwn0moNf0hKYcvGFfV2S+btUV0Cmc7139MLRD9+Fa7XZ8 txhku1nNLJ+edahABI2EArvzhMcD8dxZTgyl/GpY4SJGU+zIqeEb4Obj2TWt2DZPTvwe rKf1R965R6LIRCPRlRkIdZrQUzrDPdg+npCvjqEMDVFLrL369N+UCZQIeHjGhcPzwxhE VxSg== X-Gm-Message-State: AOAM532UbVd+OPetKFCF6aCccZmyOMWzRytYH4LU5uQ7K9u1vge6zOWC S0arvwSKZOBnGxMIam6I0DUJ0U4Ru6hCQLa9yAgUm8hAPsX4od26DxCSZ5/9Tn6yKEm43XJr8Mz 6PcSW0NSCDpmeIw== X-Received: by 2002:ae9:e918:: with SMTP id x24mr6684494qkf.264.1639522142963; Tue, 14 Dec 2021 14:49:02 -0800 (PST) X-Google-Smtp-Source: ABdhPJy2K45x7aB8EpD6KsYQPo3WZ0xlchI85HaHlpa2MUk1Au2/kWAmMPN4cpNRzlsrCbXuDvSyZQ== X-Received: by 2002:ae9:e918:: with SMTP id x24mr6684485qkf.264.1639522142747; Tue, 14 Dec 2021 14:49:02 -0800 (PST) Return-Path: Received: from fedora (modemcable200.11-22-96.mc.videotron.ca. [96.22.11.200]) by smtp.gmail.com with ESMTPSA id y6sm139577qtn.23.2021.12.14.14.49.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Dec 2021 14:49:02 -0800 (PST) Date: Tue, 14 Dec 2021 17:49:00 -0500 From: "Adrien Thierry" To: Jeremy Linton Cc: Andrei Warkentin , "devel@edk2.groups.io" , Ard Biesheuvel , Pete Batard , Ard Biesheuvel , Leif Lindholm Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length Message-ID: References: <311d8e92-29c7-e1be-f32d-652d96912be0@arm.com> <737961b2-c92d-9d47-46eb-0631a08a2bbc@arm.com> MIME-Version: 1.0 In-Reply-To: <737961b2-c92d-9d47-46eb-0631a08a2bbc@arm.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=athierry@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > 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: - the miniuart base address "off by 0x40" in the DSDT (the subject of this thread) - how to properly get the clock rate with ACPI Ideally, the end goal would be to have both the serial console and BT working with the miniuart. Adrien