> -----Original Message----- > From: Chris Johns [mailto:chr...@rtems.org] > Sent: Wednesday, August 19, 2020 1:25 AM > To: Sommer, Jan; j...@rtems.org > Cc: users@rtems.org > Subject: Re: Corrupted test marker with u-boot and zynq > > On 18/8/20 6:26 pm, jan.som...@dlr.de wrote: > >> -----Original Message----- > >> From: Chris Johns [mailto:chr...@rtems.org] > >> Sent: Monday, August 17, 2020 6:38 AM > >> To: j...@rtems.org; Sommer, Jan > >> Cc: rtems-us...@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.som...@dlr.de > >> <mailto:jan.som...@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@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@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 _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
