Corrupted test marker with u-boot and zynq
chrisj at rtems.org
Tue Aug 18 23:25:29 UTC 2020
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:
>>> 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
>>> 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
>>> 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
>>> 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
>>> 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.
>> 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...
>>> > *** 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-
>> Host: FreeBSD ruru 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC
>> 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-
>> 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
>> 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.
More information about the users