On Thu, 4 Apr 2019 at 16:51, Radoslaw Biernacki <radoslaw.bierna...@linaro.org> wrote: > > There is one additional need which we just discovered with Fu Wei. > We need second secure UART for RAS and MM from EL0. > I'm adding a patch here (not sure if addresses and IRQ's are in your style so > please check those). > I will adapt FW to your changes in next patch. > OK, I will take this into my next version of patch. Thanks.
> From fbc84e29b966f94a27fe84195987e6ba0c55c1bc Mon Sep 17 00:00:00 2001 > From: Radoslaw Biernacki <radoslaw.bierna...@gmail.com> > Date: Thu, 4 Apr 2019 14:41:21 +0700 > Subject: [PATCH] Add 2nd secure uart Rebase of Fu Wei patch > > --- > hw/arm/sbsa-ref.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c > index 6b26111840..dcfb34ff5b 100644 > --- a/hw/arm/sbsa-ref.c > +++ b/hw/arm/sbsa-ref.c > @@ -67,6 +67,7 @@ enum { > SBSA_PCIE_ECAM, > SBSA_GPIO, > SBSA_SECURE_UART, > + SBSA_SECURE_UART_MM, > SBSA_SECURE_MEM, > SBSA_AHCI, > SBSA_EHCI, > @@ -105,7 +106,9 @@ static const MemMapEntry sbsa_ref_memmap[] = { > [SBSA_RTC] = { 0x60010000, 0x00001000 }, > [SBSA_GPIO] = { 0x60020000, 0x00001000 }, > [SBSA_SECURE_UART] = { 0x60030000, 0x00001000 }, > - [SBSA_SMMU] = { 0x60040000, 0x00020000 }, > + /* The UART is a secure UART for S-EL0 OS testing */ > + [SBSA_SECURE_UART_MM] = { 0x60040000, 0x00001000 }, > + [SBSA_SMMU] = { 0x60050000, 0x00020000 }, > /* Space here reserved for more SMMUs */ > [SBSA_AHCI] = { 0x60100000, 0x00010000 }, > [SBSA_EHCI] = { 0x60110000, 0x00010000 }, > @@ -126,8 +129,9 @@ static const int sbsa_ref_irqmap[] = { > [SBSA_PCIE] = 3, /* ... to 6 */ > [SBSA_GPIO] = 7, > [SBSA_SECURE_UART] = 8, > - [SBSA_AHCI] = 9, > - [SBSA_EHCI] = 10, > + [SBSA_SECURE_UART_MM] = 9, > + [SBSA_AHCI] = 10, > + [SBSA_EHCI] = 11, > }; > > /* > @@ -645,6 +649,7 @@ static void sbsa_ref_init(MachineState *machine) > create_uart(vms, pic, SBSA_UART, sysmem, serial_hd(0)); > > create_uart(vms, pic, SBSA_SECURE_UART, secure_sysmem, serial_hd(1)); > + create_uart(vms, pic, SBSA_SECURE_UART_MM, secure_sysmem, serial_hd(2)); > > create_rtc(vms, pic); > > -- > 2.17.1 > > > On Thu, 4 Apr 2019 at 15:27, Hongbo Zhang <hongbo.zh...@linaro.org> wrote: >> >> I would like to wait for more days to see if there are any further >> comments, and if no I will send another iteration with memory map >> slightly changed. >> >> On Wed, 20 Mar 2019 at 18:27, Ard Biesheuvel <ard.biesheu...@linaro.org> >> wrote: >> > >> > On Mon, 18 Mar 2019 at 03:39, Hongbo Zhang <hongbo.zh...@linaro.org> wrote: >> > > >> > > On Fri, 15 Mar 2019 at 18:41, Ard Biesheuvel <ard.biesheu...@linaro.org> >> > > wrote: >> > > > >> > > > On Fri, 15 Mar 2019 at 11:08, Hongbo Zhang <hongbo.zh...@linaro.org> >> > > > wrote: >> > > > > >> > > > > For the Aarch64, there is one machine 'virt', it is primarily meant >> > > > > to >> > > > > run on KVM and execute virtualization workloads, but we need an >> > > > > environment as faithful as possible to physical hardware, for >> > > > > supporting >> > > > > firmware and OS development for pysical Aarch64 machines. >> > > > > >> > > > > This patch introduces new machine type 'sbsa-ref' with main features: >> > > > > - Based on 'virt' machine type. >> > > > > - A new memory map. >> > > > > - CPU type cortex-a57. >> > > > > - EL2 and EL3 are enabled. >> > > > > - GIC version 3. >> > > > > - System bus AHCI controller. >> > > > > - System bus EHCI controller. >> > > > >> > > > Hello Hongbo, >> > > > >> > > > Apologies for bringing this up now, but I seem to remember that the >> > > > EHCI does not support 64-bit DMA. Did you run into any issues with >> > > > this? Or was this fixed in QEMU in the mean time? >> > > > >> > > Hi Ard, >> > > Which EHCI do you mean? >> > > This time I use a newly introduced system bus EHCI, commit 114529f7 >> > > and I only tested USB mouse and key board, didn't test DMA function. >> > > >> > >> > The host controller doesn't work without DMA, so if mouse and keyboard >> > worked for you, and no DRAM exists below the 4 GB mark, this has >> > apparently been fixed in QEMU.