Hello everybody,
there are Yang Qiao patches updated for RTEMS 4.12.
I have checked that RTEMS build after applying.
I have not tested them on target.
But but there should be minimal impact. I have removed initialization
of VideoCore and required changes in memory mapping from basic patches
set because this part has to be redone.
This means that actual code should be usable as library of functions
reusable from other drivers and applications for now but VideoCore
faramebuffer is not activated by default/should not cause problems.
There is added call of mailbox access during initialization
to obtain command line passed to the application from boot
cmdline.txt file.
Be warned, that it is not that command line which is passed
to loaded kernel from U-boot (if U-boot is used).
The command line is read through mailbox twice,
it has to be available as early as possible when
rest of patches is in the use and it is used first time
before memory areas/workspace is set. May it be, that one call
can be eliminated, but I am not sure if BSS clean does not
been problem there. At least Yang Qiao has added the second call.
If RTEMS start blocks on the rpi_init_cmdline() call then
we know that mailbox interface has problems so everithing
works on RPi1 and RPi2 then basic mailbox works.
If there is problem try to remove rpi_init_cmdline() to
confirm that it is source of problems.
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c
@@ -26,4 +26,5 @@
void bsp_start(void)
{
bsp_interrupt_initialize();
+ rpi_init_cmdline();
}
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
@@ -7,6 +7,7 @@
@@ -29,6 +30,7 @@
void BSP_START_TEXT_SECTION bsp_start_hook_0(void)
{
+ rpi_init_cmdline();
}
The proposed patches
arm/raspberrypi: add VideoCore framebuffer without initialization
arm/raspberrypi: add VideoCore frame buffer control support
arm/raspberrypi: add cmdline support for rpi bsp
arm/raspberrypi: add VideoCore framebuffer without initialization
If there is agreement that they are OK or some minor adjustment
are enough and somebody tests that they do not break any of RPi1 and RPi2
then I update these patches and push them to RTEMS master.
The problematic patch is
arm/raspberrypi: call VideoCore framebuffer initialization
I am sending that one too but memory mapping has to be redone.
Proposed
RAM_MMU (AIW) : ORIGIN = 256M - 64M - 16k, LENGTH = 16k
is broken because memory division between VideoCore and ARM CPU
is configurable and if translation table overlaps VideoCore memory
then bad things can happen. On the other hand if the end of
memory is set at too low address then we cannot utilize more memory
for workspace if VideoCore reports the limit higher.
There are next options
1) put RAM_MMU to the address 0x4000 or 0xC000 (16 kB should be enough I hope),
RTEMS uses memory only above 0x8000. The end of usable RAM can be obtained
through mailbox interface and and used to setup workarea size
I see only one possible problem with this interface now and it is that
this area can be used by boot loader to pass ATAGs or device-tree
which should be used one day by RPi RTEMS to obtain command line
and other information provided by original Broadcom boot code and U-boot.
Actual size an location of FDT does not overlap with 0x8000+ adsres
but FDT is nearly 32 kB now so there can arise problem in future.
2) put RAM_MMU at fixed, safe location, for example below 64 MB and setup
only small workspace first and then add area from 64 MB to memory
division limit to memory pool later. I am not sure how this should
be done correct way, because standard RTEMS memory setup which I know
gets continuous area and divides it between regions in one go.
3) do not setup fixed RAM_MMU region at all, take memory division
address from mailbox, round it down to 16 kB, then subtract 16 kB
and setup translation table there. Then use standard RTEMS workspace
setup for range ending before translation table start.
The 1) is simplest but limits region size used to pass data by loader.
So I would like to hear what do you think about these options and some
suggestion which RTEMS provided functions should be used. I have that
analyzed much better lays year but I do not remember all my findings now.
Best wishes,
Pavel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
