Corrupted test marker with u-boot and zynq

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