Generated header file ti_herc/reg_spi.h contains complete registers
and fields set for Ti MibSPI peripheral.
Care has to be taken that only TMS570_SPI1, TMS570_SPI3 and TMS570_SPI5
are of this complete multibuffer type. TMS570_SPI2 and TMS570_SPI4
have substantial part of registers removed but else they are compatible.
The symbol can be used by bsp_start_hook_0 when complete
RAM memory is initialization and overwritten during BSP
self-test. The test overwrites even memory used to store
return address / link register and regular resturn from
bsp_start_hook_0 is not possible then.
This makes the new Termios devices independent of device major/minor
numbers. It enables BSP independent Termios device drivers which may
reside in the cpukit domain. These drivers require an IMFS and do not
work with the device file system. However, the device file system
should go away in the future.
The BSP support is divided to startup/bspsmp_api.c file where
functions required by SuperCore are defined and BCM2836 hardware
initialization part in startup/bspsmp_init.c.
Separation is done to prevent smpfatal08 test build failure.
Protection by rtems_interrupt_disable() is incompatible with SMP build.
Actual page table entries manipulation function does not need locking
and disabling cache and can be run concurrently even on multiple
CPUs as long as changes do not modify same region. If the function
is called from more threads/CPUs to modify same region with different
mapping options concurrently then there is problem at another level
of virtual address space management and has to be solved by mutex
or other locking at that level.
We always build a C++ compiler and building with C++ does not effect
RTEMS or the runtime. This patch always enabled the support. There is
no need to manually enable it any more.
You can disable C++ with '--disable-cxx'.
If an architecture does not have a C++ compiler support is automatically
disabled.
Code works but there is problem how to setup caching for the regions
(arm_cp15_set_translation_table_entries arguments).
If ARMV7_MMU_DATA_READ_WRITE_CACHED is used then CPU
accesses are noncoherent with VideoCore and some
part of image update are not visible until pushed from
cache by other activities. If ARMV7_MMU_DATA_READ_WRITE
is used then access is extremely slow.
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
The first, mistake in buffer size computation for cache flush
and invalidate has been corrected.
GCC __attribute__( ( aligned( 64 ) ) ) should work and works for local
variables. Code ensures right stack alignment. But attribute has
to be moved to type declaration to ensure that structure size is affected
by attribute. But even this seems to not work reliably for some reason.
May it be, the stack area between frame start and end of local variable buffer
accessed during context switch or some stack prefetch during resturn
such way that some cache lines belonging to buffer are filled to cache.
Extending buffer by one more cache line padding helps there.
In the longer term perspective, buffer should be moved to some static
area or cache aligned dynamic memory allocated. Concurrent calls
to the VideoCore operations and access serialization should be added
too but problem is that some calls are required during workspace and MMU
setup so variant without need of mutex would be required as well.
Framebuffer setup code and other VideoCore calls check more
precisely for errors and do not proceed forward with incorrect
data now.
Signed-off-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Using conditional branches to find bits is extremely inefficient
and for asynchronous delivery of different interrupt sources
lead to total confusion of branch prediction unit.
Exception table setup is processed by common CPU architecture support.
For ARM architecture, it can be found in the file
rtems/c/src/lib/libbsp/arm/shared/start/start.S
and ends by bsp_vector_table_copy_done label.
The actual tabel content can be found at
bsp_start_vector_table_begin
For ARMv7-A and even other variant with hypervisor mode support,
it is even not necessary to copy table to address 0 at all
because CP15 register can be used to specify alternative
table start address
arm_cp15_set_vector_base_address(&)bsp_start_vector_table_begin;
ARMv7-M have register to set exception table base as well.
