Corrupted test marker with u-boot and zynq

Wed Aug 19 07:30:18 UTC 2020

> -----Original Message-----
> From: Chris Johns [mailto:chrisj at rtems.org]
> Sent: Wednesday, August 19, 2020 1:25 AM
> To: Sommer, Jan; joel at rtems.org
> Cc: users at rtems.org
> Subject: Re: Corrupted test marker with u-boot and zynq
> 
> On 18/8/20 6:26 pm, Jan.Sommer at dlr.de wrote:
> >> -----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
> 
> I assume you are using the default baudrate of 115200?
> 
> Is this custom hardware?
> 

It's a SoM from Trenz (e.g. here: https://shop.trenz-electronic.de/en/TE0715-04-15-1I-SoC-Module-with-Xilinx-Zynq-XC7Z015-1CLG485I-1-GByte-DDR3L-4-x-5-cm) which sits on the 0706 Carrier-board.

I compiled rtems with the following to set the clock values in line with vivado:
../rtems-5.0.0-m2006-2/configure --target=arm-rtems5 --prefix=~/rtems/bsps/5/arm --disable-networking --enable-rtemsbsp=xilinx_zynq_zedboard --enable-cxx --enable-posix ZYNQ_CLOCK_UART=100000000 BSP_ARM_A9MPCORE_PERIPHCLK=333333333U ZYNQ_CLOCK_CPU_1X=111111111U BSP_CONSOLE_MINOR=0 --enable-tests

> >
> > Would this be a solution which could be accepted as a patch?
> >
> 
> I do not see any harm in the change however I would like to know what the
> difference between your set up and mine is. Your output is missing ...
> 
> ## Transferring control to RTEMS (at address 00104000) ...
> 

Ah, yes.
I just tried with a bare metal hello_world from Xilinx and there this line appears, but not when I load rtems applications.
That's weird.
We have u-boot compiled from the Xilinx repositories: U-Boot 2019.01 (Jul 16 2020 - 14:44:10 +0000) Xilinx Zynq ZC702

Cheers,

   Jan

> 
> 
> *
> 
> ... compared to mine and I suspect that is more than the TX FIFO size in the
> UART.
> 
> Chris
> 
> >
> >> 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