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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
