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? > > 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) ... * ... 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
