> -----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 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@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
