hello Alan,
thanks much for testing.
On Thursday 26 of May 2016 18:04:47 Alan Cudmore wrote:
> 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.
Great to hear that I have not broken support for RPi2.
> 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+.
For which of builds or for both?
In the series of YANG Qiao graphic patches is consideration
about L2 cache to be enabled and I have left that in as I have
separated that part of the commit which influences MMU configuration
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -32,6 +32,8 @@ extern "C" {
#define BSP_FEATURE_IRQ_EXTENSION
+#define RPI_L2_CACHE_ENABLE 1
+
#define BSP_GPIO_PIN_COUNT 32
#define BSP_GPIO_PINS_PER_BANK 32
#define BSP_GPIO_PINS_PER_SELECT_BANK 10
rtems/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
#if (RPI_L2_CACHE_ENABLE == 1)
#define BCM2835_VC_MEMORY_MAPPING 0x40000000
#else
#define BCM2835_VC_MEMORY_MAPPING 0xC0000000
#endif
But that only influences how VideoCore accesses main
memory from its side and which region CPU uses for
communication with VideoCore. So if framebuffer is not
used then it should have zero influence
As I can find about caches coherency on RPi,
there is some cache coherent region defined from side
of VideoCore accesses.
ARM1176JZF-S manual especially warns that MMU table walks
are not coherent with L1, from that I expect that they
are/can be cache coherent with L1. Internal TCM DMA is declared
as not cache coherent. Tnen manual says
6.2.4 Page-based attributes
The processor interprets the Shared bit in the MMU for regions
that are Cacheable as making the accesses Noncacheable. This
ensures memory coherency without incurring the cost of dedicated cache
coherency hardware. Behavior with MMU disabled on page 6-9 describes
the behavior of the memory system when the MMU is disabled.
6.7.1 Normal memory attribute
to handle the requirements of shared data. As a result, a region of memory
that is marked as being Cacheable and Shared is not cached by the processor
at level one. Marking the same
6.7.3 Strongly Ordered memory attribute
Another memory attribute, Strongly Ordered, is defined on a per-page basis in
the MMU.
6.7.4 Ordering requirements for memory accesses
This chapter defines most of the rules.
But to check that to all configuration of MMU and CP15 is not easy task.
I am not sure how well are these rules obeyed for RPi support.
Cortex-A has ability to keep coherence even for pages marked
as sharable and cacheable, so difference of RPi2 should be considered
in BSP as well.
For sure, there should be sync of I and D cache after library
load by dlopen. Sync of L1 data cache at least after page table
updates etc.
> 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.
As I understand that should make all cores except to 0 to sleep
and not waste power and throughput by busylooping on a signal.
Other option is to try build RTEMS with SMP support and
run it correctly on all cores.
Please, can you test my version with
--video=auto --console=fbcons
in "cmdline.txt" to check if console output to HDMI works
on RPi2.
Thanks again and best wishes,
Pavel
PS: I would not be available over this weekend
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
