RKI Image for Raspberry PI 2

[Alan Cudmore]

Hi Pavel,
Here is what I have been able to try so far:
rtems git head:
   “old” firmware - what I have been using for tests 
       Works on RPI A+
       Works on RPI 2
    latest firmware from raspberry pi github
        Works on RPI A+
        Does not work on RPI 2
        
Your rtems-rpi-devel branch:
    “old” firmware
        Works on RPI A+
        Works on RPI 2
     latest firmware from raspberry pi github
         Works on RPI A+
         Does not work on RPI 2

So it seems that the tests are consistent. 

I just have to figure out the differences between the latest firmware and what I have been using.

I also noticed that the dhrystone benchmark is much slower on the Pi2 than the Pi A+. 

I recall that we had fixed a cache configuration problem on the Pi2 and it was significantly faster, even though it was only using 1 core. Maybe this has changed in the past year or so. 

My old firmware did have a config.txt entry :
arm_control=0x1000
This did not have an effect on the new firmware tests.

Alan


> On May 26, 2016, at 3:10 AM, Pavel Pisa <ppisa4lists at pikron.com> wrote:
> 
> Hello Alan,
> 
> thanks for the report.
> 
> On Thursday 26 of May 2016 04:03:21 Alan Cudmore wrote:
>> I just tried the firmware in the repository above ( did not realize the
>> whole git repo was over 3 gigs! )
>> 
>> I backed up my RTEMS pi SD card and copied the contents of the firmware
>> "boot" directory to my card. I replaced kernel.img and kernel7.img with my
>> RKI images for the Pi and Pi2.
>> 
>> RTEMS boots on my Pi Model A+, but not on the 2. Same RTEMS images that
>> booted on my old card.
>> 
>> My old card boot directory is based off of a NOOBS installation.  I'll have
>> to investigate more.. Maybe I can upload my SD card contents to my github
>> account ( I think that would be OK with the license, since the official
>> firmware is on github as well )
> 
> Please, can you check new and old firmware with my branch
> rtems-rpi-devel from
> 
>  https://github.com/ppisa/rtems
> 
> to check if it works at leas on the firmware known to work with
> your previous build?
> 
> As for the debugging, I have JTAG working on RPi1.
> I have no real HW experience with RTEMS on RPi2.
> (I have prepared RT Linux kernel for my colleagues
> at university who has it, but I do not consider to buy RPi2,
> but I consider RPi3).
> 
> To find where boot stucks, add next lines
> ------------------------------------------------------------------------
> #include <bsp/usart.h>
> 
> void ll_chrout(char ch)
> {
>  bcm2835_usart_fns.deviceWritePolled(0, ch);
> }
> 
> void ll_strout(char *str)
> {
>  char ch;
>  while ((ch = *(str++)) != 0) {
>    if (ch == '\n')
>      bcm2835_usart_fns.deviceWritePolled(0, '\r');
>    bcm2835_usart_fns.deviceWritePolled(0, ch);
>  }
> }
> ------------------------------------------------------------------------
> 
> to c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
> 
> then add/spread some
> 
> ll_strout(" XXX reached\n");
> 
> over the RTEMS sources, start with the functions
> 
> void BSP_START_TEXT_SECTION bsp_start_hook_0(void)
> 
> void BSP_START_TEXT_SECTION bsp_start_hook_1(void)
> 
> 
> In c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
> is critical
> 
>    arm_cp15_set_domain_access_control(dac);
> 
> can be replaced for test by
> 
>    arm_cp15_set_domain_access_control(-1);
> 
> add print in start and end of arm_cp15_start_setup_translation_table()
> 
> In cpukit/score/src/threadhandler.c critical is
> 
>    level = executing->Start.isr_level;
>   _ISR_Set_level( level );
> 
> where IRQ can fire and if exeption table is misconfigured then deadly
> fails.
> 
> Best wishes,
> 
>             Pavel
> 
> 
>