qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/5] hw/arm/aspeed: Select console UART from machine


From: Andrew Jeffery
Subject: Re: [PATCH 2/5] hw/arm/aspeed: Select console UART from machine
Date: Tue, 31 Aug 2021 20:53:10 +0930
User-agent: Cyrus-JMAP/3.5.0-alpha0-1124-g8f1c7cb9de-fm-20210824.001-g8f1c7cb9

Hi Cédric, Peter,

On Tue, 31 Aug 2021, at 20:09, Cédric Le Goater wrote:
> On 8/28/21 5:58 PM, Peter Delevoryas wrote:
> > I think I’m a little confused on this part. What I meant by “most machines 
> > just use UART5” was that most DTS’s use “stdout-path=&uart5”, but fuji uses 
> > “stdout-path=&uart1”. I /do/ see that SCU510 includes a bit related to 
> > UART, but it’s for disabling booting from UART1 and UART5. I just care 
> > about the console aspect, not booting.
> 
> The UART can be switched with SCU70[29] on the AST2500, btw.

If it helps, neither the AST2600's "Boot from UART" feature nor the 
AST2[456]00's "Debug UART" feature are related to which UART is used as 
the BMC console by u-boot and/or the kernel - the latter is entirely a 
software thing.

The "Debug UART" is a hardware backdoor, a UART-to-AHB bridge 
implemented by the SoC. It provides a shell environment that allows you 
to issue transactions directly on the AHB if you perform a magic knock. 
I have a driver for it implemented here:

https://github.com/amboar/cve-2019-6260/blob/master/src/debug.c

SCU70[29] on the AST2500 selects whether this backdoor is exposed on 
UART1 or UART5.

The "Boot from UART" feature is implemented in the AST2600 ROM code as 
a fallback for loading the SPL if fetching it from SPI-NOR or the eMMC 
fails, or the SPL is incorrectly signed for secure-boot.

I think Peter is on the right track with this patch?

Andrew



reply via email to

[Prev in Thread] Current Thread [Next in Thread]