Setting up test.py for a platform with 2 U-Boots?

Setting up test.py for a platform with 2 U-Boots?

[Tom Rini]

Hey,

So I'm trying to enable our test.py framework on am65x_evm_r5 +
am65x_evm_a53.  The short version is this platform has an R5 core that
sets things up and fires off the A53 cores.  So there's two U-Boots and
the console log looks like this (I used SOURCE_DATE_EPOCH to give both
binaries the same timestamp):

U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000)
SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla')
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.3():v2.3
NOTICE:  BL31: Built : 11:22:40, Apr 21 2020
INFO:    GICv3 without legacy support detected.
INFO:    ARM GICv3 driver initialized in EL3
INFO:    SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla')
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Initializing BL32
I/TC: 
I/TC: OP-TEE version: 3.8.0-267-g8287cbcf (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10))) #1 Tue Apr 21 05:57:19 UTC 2020 aarch64
I/TC: Initialized
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x80080000
INFO:    SPSR = 0x3c9

U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000)
SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla')
Trying to boot from MMC2


U-Boot 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000)

SoC:   AM65x SR 1.0
Model: Texas Instruments AM654 Base Board
Board: AM6-COMPROCEVM rev E3
DRAM:  4 GiB
MMC:   sdhci at 4f80000: 0, sdhci at 04FA0000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Detected: SER-PCIEUSBEVM rev E3
Net:   
Warning: cpsw_nuss at 046000000 using MAC address from ROM
eth0: cpsw_nuss at 046000000
Hit any key to stop autoboot:  2 \b\b\b 0 
=> 

But when I run test.py:
...
            if m != 0:
                raise Exception('Bad pattern found on console: ' +
>                               self.bad_pattern_ids[m - 1])
E                               Exception: Bad pattern found on console: spl_signon

test/py/u_boot_console_base.py:365: Exception
------------------------------------------------------ Captured stdout setup ------------------------------------------------------
+u-boot-test-reset am65x_evm_a53 na
picocom v2.2

port is        : /dev/serial/by-path/pci-0000:08:00.0-usb-0:1.4.2.5:1.0-port0
flowcontrol    : none
baudrate is    : 115200
parity is      : none
databits are   : 8
stopbits are   : 1
escape is      : C-a
local echo is  : no
noinit is      : no
noreset is     : no
nolock is      : no
send_cmd is    : sz -vv
receive_cmd is : rz -vv -E
imap is        :
omap is        :
emap is        : crcrlf,delbs,

Type [C-a] [C-h] to see available commands

Terminal ready

U-Boot SPL 2020.07-rc1-00386-g8737c65fe4e3 (May 07 2020 - 18:29:35 +0000)
SYSFW ABI: 2.9 (firmware rev 0x0013 '19.12.2-v2019.12b (Terrific Lla')
================================================ 308 deselected, 1 error in 5.30s =================================================

And that's even with:
env__spl_skipped = True
in u_boot_boardenv_am65x_evm_a53_na.py for the platform.  Any ideas on what to
do here?  I even tried turning off serial support in the R5 side of things, but
it still failed.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200507/4647cd54/attachment.sig>

Setting up test.py for a platform with 2 U-Boots?

[Stephen Warren]

On 5/7/20 12:48 PM, Tom Rini wrote:
> Hey,
> 
> So I'm trying to enable our test.py framework on am65x_evm_r5 +
> am65x_evm_a53.  The short version is this platform has an R5 core that
> sets things up and fires off the A53 cores.  So there's two U-Boots and
> the console log looks like this (I used SOURCE_DATE_EPOCH to give both
> binaries the same timestamp):
...
> And that's even with:
> env__spl_skipped = True
> in u_boot_boardenv_am65x_evm_a53_na.py for the platform.  Any ideas on what to
> do here?  I even tried turning off serial support in the R5 side of things, but
> it still failed.  Thanks!

It's odd that disabling serial support on the R5 didn't fix this; are
you sure that patch actually prevented the serial output from appearing,
and the board still booted without issue?

Anyway, u_boot_console_base.py:ConsoleBase:ensure_spawned() does roughly
this:

if SPL will print signon message:
    Wait for SPL signon message
Wait for main U-Boot signon message

Maybe we need to expand that to a loop that iterates over a list of
signon messages, with the default list value being either [spl, main] or
[main] as configured by the current logic, but if the env file provides
an alternate list, that's used instead, e.g. [spl, main, spl, main] (or
whatever)?

e.g. very roughly:

msgs = self.config.env.get('env__boot_signon_msgs')
if msgs:
    signons = parse(msgs)
else if spl:
    signons = [spl, main]
else:
    signons = [main]
for signon in signons:
    self.p.expect(signon)

Setting up test.py for a platform with 2 U-Boots?

[Tom Rini]

On Thu, May 07, 2020 at 05:17:15PM -0600, Stephen Warren wrote:
> On 5/7/20 12:48 PM, Tom Rini wrote:
> > Hey,
> > 
> > So I'm trying to enable our test.py framework on am65x_evm_r5 +
> > am65x_evm_a53.  The short version is this platform has an R5 core that
> > sets things up and fires off the A53 cores.  So there's two U-Boots and
> > the console log looks like this (I used SOURCE_DATE_EPOCH to give both
> > binaries the same timestamp):
> ...
> > And that's even with:
> > env__spl_skipped = True
> > in u_boot_boardenv_am65x_evm_a53_na.py for the platform.  Any ideas on what to
> > do here?  I even tried turning off serial support in the R5 side of things, but
> > it still failed.  Thanks!
> 
> It's odd that disabling serial support on the R5 didn't fix this; are
> you sure that patch actually prevented the serial output from appearing,
> and the board still booted without issue?

So, I thought I had disabled serial in r5 case but I guess I hadn't
really.  I got it going now with a combination of disabling serial there
AND telling pytest to not do the SPL test.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200511/94435ec5/attachment.sig>