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