Hi,
On 12/14/21 00:21, Andrei Warkentin 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.
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 don'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 presumably more-Linux friendly option.
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.
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 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 considered
broken just because you don't like the definitions. I don't like the
definitions either, but that's all we got.
Yes, I tend to agree WRT to changing the base address for the existing
HID. So I wasn't disagreeing with your intent, just trying to point out
a way forward without changing the base addr. Although, I'm going to
continue thinking its broken :)
Thanks,
A
________________________________
From: Jeremy Linton <jeremy.lin...@arm.com>
Sent: Monday, December 13, 2021 11:39 PM
To: devel@edk2.groups.io <devel@edk2.groups.io>; Andrei Warkentin <awarken...@vmware.com>; Ard
Biesheuvel <a...@kernel.org>; Adrien Thierry <athie...@redhat.com>; Pete Batard
<p...@akeo.ie>
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>; Leif Lindholm
<l...@nuviainc.com>
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 <a...@kernel.org>
Sent: Monday, December 13, 2021 9:14 AM
To: Adrien Thierry <athie...@redhat.com>; Andrei Warkentin <awarken...@vmware.com>;
Pete Batard <p...@akeo.ie>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>; Ard Biesheuvel
<ardb+tianoc...@kernel.org>; Leif Lindholm <l...@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 <athie...@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.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#84825): https://edk2.groups.io/g/devel/message/84825
Mute This Topic: https://groups.io/mt/87501357/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
