arm/raspberrypi: VideoCore and U-boot testing

[Pavel Pisa]

Hello everybody,

On Wednesday 11 of May 2016 22:37:48 Jan Sommer wrote:
> Am Montag, 2. Mai 2016, 00:15:31 CEST schrieb Pavel Pisa:
> [...]
>
> > 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.
>
> I built everything from scratch (toolchain, rtems, u-boot)

Be carefull that there is fundamental problem in the recent
Newlib with strlen(). The discussion on Newlib mainling
list waits for some resolution/continuation.
So if you receive fail later in mount then it can be problem
of strlen. But it is not related to _CPU_Context_Restart_self
stuck.

> applied your 
> patches for the printouts and my Pi1 B+ gets stuck at the same places. That
> means:
> If I run ticker.bin directly without u-boot it runs fine
> If I run it with u-boot it gets stuck at the call to
> arm_cp15_set_domain_access_control(dac);

> If I uncomment this call it gets stuck with u-boot after
>  heir start address 0x0001797C
>  _CPU_Context_Restart_self

I am on busines trip (OSADL.org meeting) now.
So only quick reply from my unfinished findings

I have replaced

-  arm_cp15_set_domain_access_control(dac);

by

+  arm_cp15_set_domain_access_control(-1);

in arm_cp15_start_setup_translation_table(), which is how
U-boot setups this and it should be maximally permissive.

As for the stuck in _CPU_Context_Restart_self,
I have managed JTAG to be enabled by RTEMS startup
(I need to prepare patch to correct GPIO pin alternative
functions setup in RTEMS mainline, it is very weird in actual
state) and found actual reason.

The CPSR is set to zero during switch to the first/init task.
I have debugged that saved flags are zero already in heir->Registers
before call of

  _CPU_Context_Restart_self( &heir->Registers );

On the other hand LR has correct value and when I have corrected
SPSR value by debugger before switch then boot continued
to mount where has been some another problem.
I have checked if the stack location is not a problem for U-boot
startup but that seems to be OK. So I am not sure what wrong still.

In each case thanks for testing it proves that it is not only
some local problem or my mistake in builds.

Best wishes,

              Pavel