Corrupted test marker with u-boot and zynq

Tue Aug 18 08:26:54 UTC 2020

> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org]
> Sent: Monday, August 17, 2020 6:38 AM
> To: joel at rtems.org; Sommer, Jan
> Cc: rtems-users at rtems.org
> Subject: Re: Corrupted test marker with u-boot and zynq
> 
> 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.
> 

I did some more testing yesterday.
If I add " zynq_uart_reset_tx_flush(ctx);" to the begin of the function "void zynq_uart_initialize(rtems_termios_device_context *base)", then the issue does not appear anymore

Would this be a solution which could be accepted as a patch?

Regards, 

   Jan

> 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