Corrupted test marker with u-boot and zynq

[Chris Johns]

On 17/8/20 12:48 am, Joel Sherrill wrote:
> On Sun, Aug 16, 2020, 5:22 AM <Jan.Sommer at dlr.de <mailto:Jan.Sommer at dlr.de>> wrote:
> 
>     Hello,
> 
>     I try to create a setup to run the rtems testsuite on a Xilinx Zynq device
>     with u-boot.
>     I built everything with the 5.0.0-m2006-2 pre-release.
>     It now works in general, but quite a number of tests have a corrupted begin
>     test marker (see below).
>     This way, rtems-test does not recognize the test and counts it as timeout.
>     The value of wrong characters is the same for multiple runs of the same
>     test, but is different for different tests (or not present at all).
> 
> Some setups have trouble getting all the characters from the loader out before
> the body of the ioctl support code in the console driver runs. This has been
> discussed a couple of times with no generally accepted resolution. The best bet
> may be waiting for the TX buffer to go empty in the console ioctl code. We
> tried disabling the ioctl support code and flushing at boot but I don't recall
> flushing in the ioctl support in the driver which would be more acceptable.
> 
>     If I execute the elf file via JTAG, everything works fine.
>     Has someone encountered such behavior before?
>     Looks like the something is going wrong during the handover from u-boot to rtems
> 
> Exactly. It is fast enough where reprogramming the uart seems to cause issues
> with outstanding and early IO.

Is the UART is initialised on a Zynq? The ps7_init support in the bootloader
should handle the UART set up so the configuration defined in the SystemZ
component in Vivado is used.

Also this is a testsuite test and printk should be used as we remap puts, printf
etc to printk. The polled output routine should honour the TX fifo state.

>     > Load address: 0x10000000
>     > Loading: ###
>     >          2.9 MiB/s
>     > done
>     > Bytes transferred = 39140 (98e4 hex)
>     > ## Booting kernel from Legacy Image at 10000000 ...
>     >    Image Name:   RTEMS
>     >    Image Type:   ARM RTEMS Kernel Image (gzip compressed)
>     >    Data Size:    39076 Bytes = 38.2 KiB
>     >    Load Address: 00104000
>     >    Entry Point:  00104000
>     >    Verifying Checksum ... OK
>     >    Uncompressing Kernel Image ... OK
>     > CC** BEGIN OF TEST SP 16 ***

It is weird the first `*` has gone. If you look here there are a couple of lf
chars prepended to the test banner...

https://git.rtems.org/rtems/tree/cpukit/libtest/testbeginend.c#n38

>     > *** TEST VERSION: 5.0.0-m2006-2
>     > *** TEST STATE: EXPECTED_PASS
>     > *** TEST BUILD: RTEMS_POSIX_API

I have built my u-boot from source and with 5.1-rc2 I get the following...

$ rtems-run --rtems-bsp=xilinx_zynq_zedboard /opt/src/rtems/sp16.exe


RTEMS Testing - Run, 5.0.not_released
 Command Line: /opt/work/rtems/5/bin/rtems-run --rtems-bsp=xilinx_zynq_zedboard
/opt/src/rtems/sp16.exe
 Host: FreeBSD ruru 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
 Python: 3.7.6 (default, Mar  3 2020, 01:18:14) [Clang 8.0.1
(tags/RELEASE_801/final 366581)]
Host: FreeBSD-12.1-RELEASE-p2-amd64-64bit-ELF (FreeBSD ruru 12.1-RELEASE-p2
FreeBSD 12.1-RELEASE-p2 GENERIC amd64 amd64)
reading uEnv.txt
165 bytes read in 11 ms (14.6 KiB/s)
Importing environment from mmc ...
Checking if uenvcmd is set ...
Running uenvcmd ...
Booting RTEMS from net
ethernet at e000b000 Waiting for PHY auto negotiation to complete..... done
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 10.10.5.132 (253 ms)
Using ethernet at e000b000 device
TFTP from server 10.10.5.2; our IP address is 10.10.5.132
Filename 'zed/rtems.img'.
Load address: 0x2000000
Loading: ###
         2 MiB/s
done
Bytes transferred = 38567 (96a7 hex)
## Booting kernel from Legacy Image at 02000000 ...
   Image Name:   RTEMS
   Image Type:   ARM RTEMS Kernel Image (gzip compressed)
   Data Size:    38503 Bytes = 37.6 KiB
   Load Address: 00104000
   Entry Point:  00104000
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Transferring control to RTEMS (at address 00104000) ...




*** BEGIN OF TEST SP 16 ***
*** TEST VERSION: 5.1.0
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 7.5.0 20191114 (RTEMS 5, RSB 5.1-rc2, Newlib 7947581)
TA1 - rtems_region_ident - rnid => 32010001
TA1 - rtems_region_get_segment - wait on 1000 byte segment from region 2
TA1 - got segment from region 2 - 0x00000040
TA1 - rtems_region_get_segment - wait on 3K segment from region 3
TA1 - got segment from region 3 - 0x00000040

I am a little confused.

Chris