arm/raspberrypi: VideoCore and U-boot testing

Sun May 1 22:15:31 UTC 2016

Hello Alan,

the first thanks for testing on RPi2, I have only more
RPi1 at this moment easily available.

I have spent allmost one day with attempts to test actual build
of RTEMS-4.12 RPi and have not been sucesfull. I decided
to use U-boot to not need manipulate with SD-card. My setup
for most targets is to use U-boot combined with our company
DHCP server which points boot back to my development computer
when MAC matches my some of my development target machines.
I use that setup with more systems and I manages RPi U-Boot
to work this way with Linux many times reliably and I have been
sucesfull last year with RTEMS 4.11 but I have not managed
actual 4.12 to work.

I have put my experimental data at my page

  http://cmp.felk.cvut.cz/~pisa/rtems/rpi-u-boot/

The archive of my SD card boot partition contents is
there

  http://cmp.felk.cvut.cz/~pisa/rtems/rpi-u-boot/rpi-u-boot-160501.tar.gz

I have use U-boot from Stephen Warren repo
  git://github.com/swarren/u-boot.git
Version d36dcaf11eb8726e3326388b64d5e741a6327a53
from rpi_dev branch.

U-boot is built by simple

  make distclean
  make rpi_defconfig
  make u-boot.bin

Boot is configured such way, that U-boot reads 

 extlinux/extlinux.conf

and presents menu. It is possible to load U-boot
images directly from the "extlinux" directory.

I prepare images by command

---------------------------------------------------
#!/bin/sh

OBJCOPY_FOR_TARGET=arm-rtems4.11-objcopy
OBJCOPY="$OBJCOPY_FOR_TARGET"

EXE_NAME=$1

START_ADDR=0x00008000

${OBJCOPY} -R -S --strip-debug -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
mkimage \
  -A arm -O rtems -T kernel -a $START_ADDR -e $START_ADDR -n "RTEMS" \
  -d "$EXE_NAME.gz" "$EXE_NAME.img"
---------------------------------------------------

Some problems diagnostics.

Generic problem (can be related to my toolchain build) is that

  /usr/arm-rtems4.12/lib/libc.a lib_a-strlen.o

is compiled as for ARM Thumb mode even that RTEMS for RPi1 is compiled
with option -mcpu=arm1176jzf-s leading to ARM mode. The most of the
Newlib seem to be compiled for ARM v4 32-bit mode, the most of files
with

  Tag_CPU_name: "ARM7TDMI"
  Tag_CPU_arch: v4T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: small
  Tag_ABI_optimization_goals: Aggressive Size

But only lib_a-strlen.o of my build has signature 

 readelf --all lib_a-strlen.o

  Tag_CPU_name: "6T2"
  Tag_CPU_arch: v6T2
  Tag_THUMB_ISA_use: Thumb-2

Which is incompatible with arm1176jzf-s. That is probably problem
in NewLib strlen for plain ARM architecture.

I have resolved problem by including simple replacement in BSP
to move testing forward

  size_t strlen(const char *str)
  {
    size_t c = 0;
    while (*(str++))
      c++;
    return c;
  }

After this patch pain binary of the ticker can run when read
directly by RPi loader. But U-boot failed.
I have tried JTAG debugging but it has been together with
U-boot complex and unreliable, so I have added low level
prints to the key functions and experimented with MMU
initialization alternatives. All can be found in the next
patch against GIT with complete set of graphic patches applied

  http://cmp.felk.cvut.cz/~pisa/rtems/rpi-u-boot/rtems-4.12-rpi-u-boot-debug-160501.patch

Set of graphics related patches is there but they has been
effectively disabled during testing

  http://cmp.felk.cvut.cz/~pisa/rtems/rpi-u-boot/rtems-rpi-graphics/

I have found that call of

  uint32_t dac = ARM_CP15_DAC_DOMAIN(client_domain, ARM_CP15_DAC_CLIENT);
  arm_cp15_set_domain_access_control(dac);

in the function arm_cp15_start_setup_translation_table() leads
to stuck of the boot process from U-boot.
When I disable the arm_cp15_set_domain_access_control() call then
boot from U-boot progress. On the other hand, when
arm_cp15_set_domain_access_control() is not present for bare boot
then such boot freezes. I have tried to
  dac = ARM_CP15_DAC_DOMAIN(client_domain, ARM_CP15_DAC_MANAGER);
but that dis not help either. It seems that U-boot leaves CPU in different
state than bare RPi boot and something clashes there.
Boot process run from U-boot then reaches 

 _Profiling_Thread_dispatch_disable ...
 printk test ...
 printk test OK
 heir start address 0x00017A4C
 _CPU_Context_Restart_self

where 0x00017A4C points correctly to thread handler
but it task activation blocks there.
RTEM core and ticker patched with the set of additional ll_strout
boot correctly with bare boot, so my experimental changes
should not cause problems.

All my experiments has been done with modified memory map

MEMORY {
        VECTOR_RAM     (AIW) : ORIGIN = 0x0       , LENGTH = 16k
        RAM_MMU        (AIW) : ORIGIN = 0x00004000, LENGTH = 16k
        RAM            (AIW) : ORIGIN = 0x00008000, LENGTH = 128M - 32k
}

this moves MMU table to the start which should allow to adjust of actual
available RAM for RTEMS workspace according to the VideoCore reported
division later.

But even build with MMU table start reverted back to

  07ffc000 T bsp_translation_table_base

does not help.

So this is result of my actual testing. It would be great if somebody
else checks boot process with U-boot as well and checks if
arm_cp15_set_domain_access_control() causes problem as well.

As for RPi2 and VideoCore mailboxes, I think I have found mistake
in the defines in src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h

  #define BCM2835_MBOX_BASE   (RPI_PERIPHERAL_BASE+0xB880)

  #define BCM2835_MBOX_PEEK   (BCM2835_MBOX_BASE+0x10)
  ...
  #define BCM2835_MBOX_FULL   (BCM2835_MBOX_BASE+0x80000000)
  #define BCM2835_MBOX_EMPTY  (BCM2835_MBOX_BASE+0x40000000)

But BCM2835_MBOX_FULL and BCM2835_MBOX_EMPTY should be masks without base,
should be changed to

  #define BCM2835_MBOX_FULL   0x80000000
  #define BCM2835_MBOX_EMPTY  0x40000000

There can be another problem that some addresses has to be adjusted for RPi2.
Peripherals base is different for sure, but that should be already handled
by RTEMS raspberrypi.h file.

By the way, I have noticed that actual QEMU includes Raspberry Pi
support by Gregory Estrade. So it would worth to test RTEMS
against this support.

Best wishes,

               Pavel