Chris Johns chrisj at rtems.org
Wed Jul 22 01:19:32 UTC 2015

On 22/07/2015 3:13 am, Ric Claus wrote:
> Hello All,
>   First, I apologize for the length of this message.  I hope you can bear with me as there are several points I’d like some help with.

Thanks for the review and detailed post.

>   I’m following https://git.rtems.org/rtems-tools/tree/doc/rtems-tester.txt to try out the xilinx_zynq_a9_qemu RTEMS BSP built with --enable-smp in the configure line.
> I found the use of the term BSP in this document confusing.  "./rtems-test —list-bsps" lists names that are different from those in the RTEMS tree.  For example, modifying the example as follows won’t work:
> $ ../../rtems.git/configure —target=arm-rtems4.11 \
>                     --enable-tests --enable-rtemsbsp=xilinx_zynq_a9_qemu_smp
> Maybe some clarification here might help the next person.

I wonder if the confusion is in some of the BSP names and the option
naming in the tester. I wonder if the option '--list-bsps' in the tester
should be '--list-testers' ?

RTEMS uses a configure option --enable-smp to specify an SMP build while
the tester's configuration is fixed in the tester so we need separate
tester configurations for a uniprocessor test run and an SMP test run
for the same BSP. Testing needs to be fixed and controlled and so I do
not want the tester to support options, eg SMP.

To further confuse things there are BSPs in RTEMS whose names include
SMP, for example realview_pbx_a9_qemu_smp. Does building
realview_pbx_a9_qemu_smp require the --enable-smp configure option ? I
do not know. There is no consistent behavior which leads to
realview_pbx_a9_qemu and realview_pbx_a9_qemu_smp as well as
xilinx_zynq_a9_qemu plus the --enable-smp option.

Unifying the arch/bsp naming is an on going effort. It is difficult to
change in the current build tree and my hope with the waf and RTEMS 5.0
effort we can get a step closer. I have introduced the BSP naming of
'arch/bsp' as a standard to the RSB 3rd party building as well as the
waf build support for packages such as examples-v2. I would like this to
flow across the whole project.

For the short term to help users I have added a script called rtems-bsps
to the top of the source tree. It will find all the available BSP in the
source and the path helps you figure out the variants.

> Next, for me: 
> $ arm-rtems4.11-run arm-rtems4.11/c/xilinx_zynq_a9_qemu/testsuites/samples/hello/hello.exe
> returns nothing, and the GDB example returns:
> (gdb) tar sim
> Connected to the simulator.
> (gdb) load
> Loading section .start, size 0x888 vma 0x0
> Loading section .text, size 0x28b2c vma 0x8c0
> Loading section .init, size 0xc vma 0x293ec
> Loading section .fini, size 0xc vma 0x293f8
> Loading section .rodata, size 0x1380 vma 0x29408
> Loading section .ARM.exidx, size 0x8 vma 0x2a788
> Loading section .eh_frame, size 0x74 vma 0x2a790
> Loading section .init_array, size 0x4 vma 0x2a804
> Loading section .fini_array, size 0x4 vma 0x2a808
> Loading section .jcr, size 0x4 vma 0x2a80c
> Loading section .data, size 0x970 vma 0x102800
> Start address 0x40
> Transfer rate: 1411616 bits in <1 sec.
> (gdb) r
> Starting program: /u1/home/claus/development/rtems/bld/xilinx_zynq/a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/testsuites/samples/hello/hello.exe
> [Inferior 1 (process 42000) exited with code 060]
> Can someone explain why, please?  Should this work?  

The ARM GDB simulator does not support the same Zynq hardware. The
rtems-bsps script shows the following are based on the gdbarmsim BSP:

arm1136jfs c/src/lib/libbsp/arm/gdbarmsim
arm1136js c/src/lib/libbsp/arm/gdbarmsim
arm7tdmi c/src/lib/libbsp/arm/gdbarmsim
arm920 c/src/lib/libbsp/arm/gdbarmsim
armcortexa9 c/src/lib/libbsp/arm/gdbarmsim

Last time I tried running these BSPs there were problems. I cannot
remember what they were.

> On the other hand, QEMU works and gives:
> qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic -M xilinx-zynq-a9 -m 256M -smp cpus=1 -kernel $(find bld/xilinx_zynq/a9_qemu/ -name hello.exe)
> Warning: nic cadence_gem.0 has no peer
> Warning: nic cadence_gem.1 has no peer
> Hello World


> However, with 2 cores enabled:
> qemu-system-arm -no-reboot -serial null -serial mon:stdio -net none -nographic -M xilinx-zynq-a9 -m 256M -smp cpus=2 -kernel $(find bld/xilinx_zynq/a9_qemu/ -name hello.exe)
> it fails with:
> Number of SMP cpus requested (2), exceeds max cpus supported by machine `xilinx-zynq-a9' (1)

Same executable as the previous run ?

Where did the qemu come from ?

> I verified as per the "SMP support for Raspberry Pi 2” thread that —enable-smp was really set during configure, the cpuopts.h files have "#define RTEMS_SMP 1”, and ZYNQ_CPUS = 2 in $DEV_ROOT/rtems/bld/a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/lib/libbsp/arm/xilinx-zynq/Makefile and config.status.  ticker.exe runs and smp01.exe produces no output in QEMU, when I leave the -smp parameter off.  What is the status of the ZYNQ BSPs?  Is the 2nd core nominally started, or is that something I need to work on?  Why is QEMU thinking there is only one core configured?
> Next, I tried to adapt the instructions in rtems-tester.txt to use QEMU:
> $DEV_ROOT/rtems/test/rtems-tools.git/tester/rtems-test \
> --log=log_xilinx_zynq_a9_qemu \
> --rtems-bsp=xilinx_zynq_a9_qemu_smp \
> --rtems-tools=$DEV_ROOT/rtems/4.11 \
> $DEV_ROOT/rtems/bld/xilinx_zynq/a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/testsuites
> Initially, this failed with:
> RTEMS Testing - Tester, v0.2.0
> error: BSP script not found: xilinx_zynq_a9_qemu
> I think there is an incorrect line in:
> $DEV_ROOT/rtems/test/rtems-tools.git/tester/rtems/testing/bsps/xilinx_zynq_a9_qemu_smp.mc
> realview_pbx_a9_qemu should be xilinx_zynq_a9_qemu, right?

Yes I agree. Patch ?

> Once I made that change, the tester seems to run, but most tests fail with:
> error: qemu.cfg:65: execute failed: qemu-system-arm -no-reboot -monitor none -serial stdio -nographic -net none -M xilinx-zynq-a9 -m 256M -smp cpus=2 -kernel bld/xilinx_zynq/a9_qemu/arm-rtems4.11/c/xilinx_zynq_a9_qemu/testsuites/fstests/fsbdpart01/fsbdpart01.exe: exit-code:1
> warning: switched to dry run due to errors

Is this all the log contains ?

Can you please try the --report-mode=all option ?

> Are these all due to the "-smp cpus=2” parameter?

I suppose so. Did the uniprocessor test run work ?


More information about the users mailing list