Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization
OK, thanks all for the views. That gave plenty insight into the details I
had not thought of earlier. Clearly not the way to go.
But then is such refactoring a good idea? These changes even if modified
will apply only to cp15 ARM BSPs.
On 24 Aug 2015 21:20, Pavel Pisa p...@cmp.felk.cvut.cz wrote:
Hello Chris and Rohini,
I have returned and catching the emails flow.
But please, consider that for some architectures it is critical
to have MMU table runtime alterable.
I.e. on RPi the actual memory division to cacheable
and peripheral area is know only at runtime. It depends
on user provided content of configuration files on SDcard
and actual boot loader and VideoCore firmware located
on the SDcard.
On the other hand there could exist even ARM systems
where linker script defined
bsp_translation_table_base = ORIGIN (RAM_MMU)
can be precomputed at compile time and reside in Flash.
But for sure, hardcoding of CP15 setup over all platforms
is incorrect way to go.
As for description how to configure fill the translation table,
i.e.
const arm_cp15_start_section_config arm_cp15_start_mmu_config_table[] = {
I do not think that it has to be global and it would be even
better if its type is not declared in
c/src/lib/libbsp/arm/shared/include/arm-cp15-start.h
because then it can be much easier declared as const on
options.
BSP_START_DATA_SECTION extern const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[];
On the other hand it has quite complex attributes and placement
requirements to be available before memory and workspace
setup, so the global define which enforces these is the best
solution.
We need, for sure, to be able to modify entries in the translation
table at runtime at least during startup phase. When PCI/PCIe becomes
more widespread in embedded/ARM systems then it starts to be even
important because then drivers which find a and map device PCI BARs
into memory space have to select right access and cache variants
according to the device and CPU characteristic. On the other hand,
more new SoC from Ti and FreeScale have option to switch busses
not only to be cache coherent between multiple CPU cores but even
for all/some subset of peripherals. Then even many peripheral
regions can be setup as cached on such systems without need
of special flush, invalidate cache operation before DMA/peripheral
coprocessor data passing.
So please, take in consideration these scenarios.
Making definitions as globals and use of these directly
without passing as parameters of initialization functions
make me worry.
May be some other layering and rearrangement could be better
but static and dynamic (BSP code cotrolled) use options needs
to be provided.
Best wishes,
Pavel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization
On Fri, Aug 14, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com
wrote:
On Fri, Aug 14, 2015 at 8:33 AM, Chris Johns chr...@rtems.org wrote:
On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
---
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-zynq_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
.begin = 0xe000U,
Why not pass the table to the bsp_memory_management_initialize call and
avoid making this table global ? Maybe all these tables should be static
and local to their file's in all ARM bsps that do this type MMU set up.
This global table and referencing it in the call limits its use and I
think makes things a little more fragile. See below.
I saw Raspberry Pi and altera define the arm_cp15_start_mmu_config_table.
The table is declared in the arm-cp15-start.h and mminit.c uses this as the
default table. So I didn't really understand why some had static tables
while others didn't.
Do all ARMs devices with MMUs have cp15 or is this limited to a specific
family ? The only reason I ask is bsp_memory_management_initialize is a
generic name.
Not all ARM devices have cp15. The existing definition of
bsp_memory_management_initialize supports only cp15. The definition would
not be useful to other devices. And this definition was being replicated by
some cp15 bsps again. So the reason for making these changes.
If something else exists does this call need to be updated ?
Yes, a different definition will be required.
I am still a little confused what the changes gives us. Should the RPi
not use the call and it be removed ? I do not know.
@@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
__attribute__ ((weak));
If all this code is going to be touched I feel adding weak versions for
all boards is a good thing.
The Zynq and I suspect the Cyclone need this because the memory mapped
can depend on what is loaded into the programmable logic (PL) side of
these devices. I currently override the weak Zynq call in production
code based on the PL logic loaded at run time. I wonder if this change
will break code. I am concerned it needs to get a clean link yet we now
have globals and other code referencing those globals. If the file is
not referenced and nothing else depends on it things are more robust.
I still don't have the deeper insight needed so I don't see dependencies.
But if having static tables is much more robust then we should apply that
to all.
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
-{
- uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
-ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
- );
-
- arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
-ctrl,
-(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
-zynq_mmu_config_table[0],
-RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
+{
+ uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
ARM_CP15_CTRL_Z;
+ uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+
+ bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear
);
}
+
+const size_t arm_cp15_start_mmu_config_table_size =
+ RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);
Same here. I think we should avoid globals.
Then I think raspberry Pi and altera should also follow this if this is
much more appropriate.
So what is the way out here?
Chris
\ No newline at end of file
--
Rohini Kulkarni
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization
On Fri, Aug 14, 2015 at 8:33 AM, Chris Johns chr...@rtems.org wrote:
On 14/08/2015 7:44 am, Rohini Kulkarni wrote:
---
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-zynq_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
.begin = 0xe000U,
Why not pass the table to the bsp_memory_management_initialize call and
avoid making this table global ? Maybe all these tables should be static
and local to their file's in all ARM bsps that do this type MMU set up.
This global table and referencing it in the call limits its use and I
think makes things a little more fragile. See below.
I saw Raspberry Pi and altera define the arm_cp15_start_mmu_config_table.
The table is declared in the arm-cp15-start.h and mminit.c uses this as the
default table. So I didn't really understand why some had static tables
while others didn't.
Do all ARMs devices with MMUs have cp15 or is this limited to a specific
family ? The only reason I ask is bsp_memory_management_initialize is a
generic name.
Not all ARM devices have cp15. The existing definition of
bsp_memory_management_initialize supports only cp15. The definition would
not be useful to other devices. And this definition was being replicated by
some cp15 bsps again. So the reason for making these changes.
If something else exists does this call need to be updated ?
Yes, a different definition will be required.
I am still a little confused what the changes gives us. Should the RPi
not use the call and it be removed ? I do not know.
@@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
__attribute__ ((weak));
If all this code is going to be touched I feel adding weak versions for
all boards is a good thing.
The Zynq and I suspect the Cyclone need this because the memory mapped
can depend on what is loaded into the programmable logic (PL) side of
these devices. I currently override the weak Zynq call in production
code based on the PL logic loaded at run time. I wonder if this change
will break code. I am concerned it needs to get a clean link yet we now
have globals and other code referencing those globals. If the file is
not referenced and nothing else depends on it things are more robust.
I still don't have the deeper insight needed so I don't see dependencies.
But if having static tables is much more robust then we should apply that
to all.
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
-{
- uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
-ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
- );
-
- arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
-ctrl,
-(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
-zynq_mmu_config_table[0],
-RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
+{
+ uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
ARM_CP15_CTRL_Z;
+ uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+
+ bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear
);
}
+
+const size_t arm_cp15_start_mmu_config_table_size =
+ RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);
Same here. I think we should avoid globals.
Then I think raspberry Pi and altera should also follow this if this is
much more appropriate.
Chris
\ No newline at end of file
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Code refactor changes to mm.h and mminit.c
---
c/src/lib/libbsp/arm/shared/mminit.c | 17 +++--
c/src/lib/libbsp/shared/include/mm.h |5 -
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..f2617f8 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -11,14 +11,19 @@
#include bsp/start.h
#include bsp/arm-cp15-start.h
#include bsp/linker-symbols.h
+#include libcpu/arm-cp15.h
#include bsp/mm.h
-BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(
+ uint32_t bsp_initial_mmu_ctrl_set,
+ uint32_t bsp_initial_mmu_ctrl_clear
+)
{
- uint32_t ctrl = arm_cp15_get_control();
-
- ctrl |= ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_S | ARM_CP15_CTRL_XP;
-
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+bsp_initial_mmu_ctrl_clear,
+bsp_initial_mmu_ctrl_set
+ );
+
arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
ctrl,
(uint32_t *) bsp_translation_table_base,
@@ -26,4 +31,4 @@ BSP_START_TEXT_SECTION void
bsp_memory_management_initialize(void)
arm_cp15_start_mmu_config_table[0],
arm_cp15_start_mmu_config_table_size
);
-}
+}
\ No newline at end of file
diff --git a/c/src/lib/libbsp/shared/include/mm.h
b/c/src/lib/libbsp/shared/include/mm.h
index 2152f68..aad6b05 100644
--- a/c/src/lib/libbsp/shared/include/mm.h
+++ b/c/src/lib/libbsp/shared/include/mm.h
@@ -33,7 +33,10 @@ extern C {
* @brief MM Support Package
*/
-void bsp_memory_management_initialize(void);
+void bsp_memory_management_initialize(
+ uint32_t bsp_initial_mmu_ctrl_set,
+ uint32_t bsp_initial_mmu_ctrl_clear
+);
#ifdef __cplusplus
}
--
1.7.9.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 3/4] Code refactor realview-pbx-a9 BSP MMU initialization
---
c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am |4 +++
.../arm/realview-pbx-a9/startup/bspstarthooks.c| 27 ++--
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
b/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
index 2cc7aa0..606f510 100644
--- a/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
+++ b/c/src/lib/libbsp/arm/realview-pbx-a9/Makefile.am
@@ -28,6 +28,7 @@ nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h
include_bsp_HEADERS =
include_bsp_HEADERS += ../../shared/include/utility.h
+include_bsp_HEADERS += ../../../libbsp/shared/include/mm.h
include_bsp_HEADERS += ../../shared/include/irq-generic.h
include_bsp_HEADERS += ../../shared/include/irq-info.h
include_bsp_HEADERS += ../../shared/include/stackalloc.h
@@ -131,6 +132,9 @@ libbsp_a_CPPFLAGS +=
-I$(srcdir)/../../../libcpu/arm/shared/include
# Start hooks
libbsp_a_SOURCES += startup/bspstarthooks.c
+# LIBMM
+libbsp_a_SOURCES += ../shared/mminit.c
+
# Framebuffer
libbsp_a_SOURCES += ../shared/arm-pl111-fb.c
libbsp_a_SOURCES += startup/fb-config.c
diff --git a/c/src/lib/libbsp/arm/realview-pbx-a9/startup/bspstarthooks.c
b/c/src/lib/libbsp/arm/realview-pbx-a9/startup/bspstarthooks.c
index ab766e8..74391b5 100644
--- a/c/src/lib/libbsp/arm/realview-pbx-a9/startup/bspstarthooks.c
+++ b/c/src/lib/libbsp/arm/realview-pbx-a9/startup/bspstarthooks.c
@@ -15,12 +15,13 @@
#define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
#include bsp.h
+#include bsp/mm.h
#include bsp/start.h
#include bsp/arm-cp15-start.h
#include bsp/arm-a9mpcore-start.h
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-rvpbxa9_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
.begin = 0x1000U,
@@ -37,19 +38,17 @@ rvpbxa9_mmu_config_table[] = {
}
};
+const size_t arm_cp15_start_mmu_config_table_size =
+ RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);
+
BSP_START_TEXT_SECTION static void setup_mmu_and_cache(void)
{
- uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
-ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
- );
-
- arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
-ctrl,
-(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
-rvpbxa9_mmu_config_table[0],
-RTEMS_ARRAY_SIZE(rvpbxa9_mmu_config_table)
+ uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+ uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+
+ bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear
);
}
@@ -78,4 +77,4 @@ BSP_START_TEXT_SECTION void bsp_start_hook_1(void)
bsp_start_copy_sections();
setup_mmu_and_cache();
bsp_start_clear_bss();
-}
+}
\ No newline at end of file
--
1.7.9.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/4] Code refactor xilinx-zynq BSP MMU initialization
---
c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am |4 +++
.../libbsp/arm/xilinx-zynq/startup/bspstartmmu.c | 27 ++--
2 files changed, 17 insertions(+), 14 deletions(-)
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index df4aa15..f7b23bd 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -28,6 +28,7 @@ nodist_include_bsp_HEADERS = ../../shared/include/bootcard.h
include_bsp_HEADERS =
include_bsp_HEADERS += ../../shared/include/utility.h
+include_bsp_HEADERS += ../../../libbsp/shared/include/mm.h
include_bsp_HEADERS += ../../shared/include/irq-generic.h
include_bsp_HEADERS += ../../shared/include/irq-info.h
include_bsp_HEADERS += ../../shared/include/stackalloc.h
@@ -133,6 +134,9 @@ libbsp_a_CPPFLAGS += -I$(srcdir)/../shared/arm-l2c-310
# Start hooks
libbsp_a_SOURCES += startup/bspstarthooks.c startup/bspstartmmu.c
+# LIBMM
+libbsp_a_SOURCES += ../shared/mminit.c
+
###
# Special Rules #
###
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
index c7a1089..e33e18b 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/startup/bspstartmmu.c
@@ -15,12 +15,13 @@
#define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
#include bsp.h
+#include bsp/mm.h
#include bsp/start.h
#include bsp/arm-cp15-start.h
#include bsp/arm-a9mpcore-start.h
-BSP_START_DATA_SECTION static const arm_cp15_start_section_config
-zynq_mmu_config_table[] = {
+BSP_START_DATA_SECTION const arm_cp15_start_section_config
+arm_cp15_start_mmu_config_table[] = {
ARMV7_CP15_START_DEFAULT_SECTIONS,
{
.begin = 0xe000U,
@@ -39,17 +40,15 @@ zynq_mmu_config_table[] = {
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void) __attribute__
((weak));
BSP_START_TEXT_SECTION void zynq_setup_mmu_and_cache(void)
-{
- uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
-ARM_CP15_CTRL_A,
-ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z
- );
-
- arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
-ctrl,
-(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
-zynq_mmu_config_table[0],
-RTEMS_ARRAY_SIZE(zynq_mmu_config_table)
+{
+ uint32_t bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+ uint32_t bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+
+ bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear
);
}
+
+const size_t arm_cp15_start_mmu_config_table_size =
+ RTEMS_ARRAY_SIZE(arm_cp15_start_mmu_config_table);
\ No newline at end of file
--
1.7.9.5
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: SMP support for Raspberry Pi 2
Hi, It would be great if somebody can help here. [1] How are the mailbox registers available for each core of Pi2 to be used. [2] Another thing is that I don't know which registers of Pi 1 are available for Pi2 as well. The ones in this link https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf , are quite different from the ones for Pi 1. [3] Can the same mailbox interface as Pi1 be used? Thanks. On Wed, Aug 12, 2015 at 1:29 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 8/11/2015 2:06 PM, Rohini Kulkarni wrote: Hi, I would have to register the related mailbox interrupt and associate it with a handler that should be same as _SMP_Inter_processor_interrupt_handler(). Am I right? That sounds correct. From where can I get a reference of how to do this? I would look at the Xilinx code that registers interrupts. The API should be the same. Also the clock driver, etc. The actual handler and IRQ number will vary. On 11 Aug 2015 00:41, Joel Sherrill joel.sherr...@oarcorp.com mailto: joel.sherr...@oarcorp.com wrote: The source for the CPU supplement is in doc/cpu_supplement in the RTEMS tree. I do not know when the latest online was built so reading it there is probably safest. To build it, you will likely have to install some texinfo and texlive tools. cd $r/doc ../bootstrap cd ../.. mkdir b-doc cd b-doc $r/doc/configure --enable-maintainer-mode \ --prefix=DIRECTORY make make install That should be similar to how it is built. --joel On 8/10/2015 1:35 PM, Rohini Kulkarni wrote: The documentation that Sebastian was referring to. On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. What is the CPU Architecture Supplement? You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. Thanks. On Wed, Jul 22, 2015 at 7:08 PM, Rohini Kulkarni krohini1...@gmail.com mailto:krohini1...@gmail.com mailto: krohini1...@gmail.com mailto:krohini1...@gmail.com mailto: krohini1...@gmail.com mailto:krohini1...@gmail.com mailto: krohini1...@gmail.com mailto:krohini1...@gmail.com wrote: Ok. Qemu suggestion seems helpful for the cache configuration issue though. I am trying with Pi 1. Thanks. On 22 Jul 2015 18:59, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Sorry, I cannot help you here since I never worked with a Raspberry Pi. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu
Re: Fwd: SMP support for Raspberry Pi 2
Hi, I would have to register the related mailbox interrupt and associate it with a handler that should be same as _SMP_Inter_processor_interrupt_handler(). Am I right? From where can I get a reference of how to do this? On 11 Aug 2015 00:41, Joel Sherrill joel.sherr...@oarcorp.com wrote: The source for the CPU supplement is in doc/cpu_supplement in the RTEMS tree. I do not know when the latest online was built so reading it there is probably safest. To build it, you will likely have to install some texinfo and texlive tools. cd $r/doc ../bootstrap cd ../.. mkdir b-doc cd b-doc $r/doc/configure --enable-maintainer-mode \ --prefix=DIRECTORY make make install That should be similar to how it is built. --joel On 8/10/2015 1:35 PM, Rohini Kulkarni wrote: The documentation that Sebastian was referring to. On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. What is the CPU Architecture Supplement? You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. Thanks. On Wed, Jul 22, 2015 at 7:08 PM, Rohini Kulkarni krohini1...@gmail.com mailto:krohini1...@gmail.com mailto: krohini1...@gmail.com mailto:krohini1...@gmail.com wrote: Ok. Qemu suggestion seems helpful for the cache configuration issue though. I am trying with Pi 1. Thanks. On 22 Jul 2015 18:59, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Sorry, I cannot help you here since I never worked with a Raspberry Pi. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Rohini Kulkarni -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Rohini Kulkarni -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
Yes I have tried this. Didn't work out :( On 11 Aug 2015 19:56, Joel Sherrill joel.sherr...@oarcorp.com wrote: Hi Has this been tried? Forwarded Message Subject: Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support Date: Tue, 28 Jul 2015 01:57:44 -0500 From: Sebastian Huber sebastian.hu...@embedded-brains.de To: Rohini Kulkarni krohini1...@gmail.com, Gedare Bloom ged...@gwu.edu CC: rtems-de...@rtems.org devel@rtems.org On 24/07/15 21:55, Rohini Kulkarni wrote: Hi, I have attached the report containing outputs of arm-rtems4.11-size and arm-rtems4.11-nm -S. From arm-rtems4.11-nm -S I don't see how memset() is accessing .text section. The start and end values for both are not overlapping. Maybe this patch helps: diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds index f1ad11c..f3b6232 100644 --- a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds +++ b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds @@ -62,7 +62,8 @@ REGION_ALIAS (REGION_NOCACHE_LOAD, RAM); bsp_stack_irq_size = DEFINED (bsp_stack_irq_size) ? bsp_stack_irq_size : 4096; bsp_stack_abt_size = DEFINED (bsp_stack_abt_size) ? bsp_stack_abt_size : 1024; -bsp_section_robarrier_align = DEFINED (bsp_section_robarrier_align) ? bsp_section_robarrier_align : 1M; +bsp_section_rwbarrier_align = DEFINED (bsp_section_rwbarrier_align) ? bsp_section_rwbarrier_align : 1M; + bsp_translation_table_base = ORIGIN (RAM_MMU); INCLUDE linkcmds.armv4 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
There is no documentation or information from forums I can find to get a lead. I suppose i will go ahead with mailboxes. Each core has 4 mailboxes, usage being left to us. One of the mailboxes can be used here. On Sun, Aug 9, 2015 at 2:28 AM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On August 8, 2015 3:17:01 PM CDT, Rohini Kulkarni krohini1...@gmail.com wrote: Can mailboxes be useful here? Nothing else that is coming to my mind They may be and I am seeing references to ARM's own mpcore which uses the GIC. This appears to be SOC specific but ARM has recommendations which may be followed by the SOC manufacturer On Sun, Aug 9, 2015 at 1:44 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I am stuck at how to set up IPI for Pi 2. This is a document I have referred to get an idea of interrupts. Would be great to get some help on how to proceed. On Fri, Jul 31, 2015 at 7:33 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 7/31/2015 8:11 AM, Rohini Kulkarni wrote: Hi, How is the number of processors to be used for an application specified? The used count minimum of that supported in hardware and that configured. How to specify the latter? https://docs.rtems.org/doc-current/share/rtems/html/c_user/Configuring-a-System-SMP-Specific-Configuration-Parameters.html#Configuring-a-System-SMP-Specific-Configuration-Parameters and see the smptests. Many of which do specify the maximum. Thanks. On 29 Jul 2015 15:29, Sebastian Huber sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de wrote: On 29/07/15 11:52, Rohini Kulkarni wrote: On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. I could locate the function in arm-a9mpcore-smp.c. but it would be helpful if I can know where this being called from, a deeper call hierarchy, so that I can ascertain this is a problem. I can see a Send_messgae function call this. But don't know where the send message is being called from. You can run one of the SMP tests on the realview_pbx_a9_qemu_smp BSP on Qemu and set a break point to _CPU_SMP_Send_interrupt() if you want to know how it is used. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Rohini Kulkarni -- Rohini Kulkarni --joel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
Can mailboxes be useful here? Nothing else that is coming to my mind On Sun, Aug 9, 2015 at 1:44 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I am stuck at how to set up IPI for Pi 2. This https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf is a document I have referred to get an idea of interrupts. Would be great to get some help on how to proceed. On Fri, Jul 31, 2015 at 7:33 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 7/31/2015 8:11 AM, Rohini Kulkarni wrote: Hi, How is the number of processors to be used for an application specified? The used count minimum of that supported in hardware and that configured. How to specify the latter? https://docs.rtems.org/doc-current/share/rtems/html/c_user/Configuring-a-System-SMP-Specific-Configuration-Parameters.html#Configuring-a-System-SMP-Specific-Configuration-Parameters and see the smptests. Many of which do specify the maximum. Thanks. On 29 Jul 2015 15:29, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: On 29/07/15 11:52, Rohini Kulkarni wrote: On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. I could locate the function in arm-a9mpcore-smp.c. but it would be helpful if I can know where this being called from, a deeper call hierarchy, so that I can ascertain this is a problem. I can see a Send_messgae function call this. But don't know where the send message is being called from. You can run one of the SMP tests on the realview_pbx_a9_qemu_smp BSP on Qemu and set a break point to _CPU_SMP_Send_interrupt() if you want to know how it is used. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Rohini Kulkarni -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On 5 Aug 2015 01:47, Gedare Bloom ged...@gwu.edu wrote: On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni krohini1...@gmail.com wrote: On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa ppisa4li...@pikron.com wrote: Hello Rohini and Gedare, On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote: What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. Qiao Yang in RPi 1 BSP now works in the similar area to enable right graphic memory mapping. So my guess is that there could be problem caused by used MMU mode granularity, which is is 1 MB so if RO and RW sections are present in the same 1MB aligned block ten there can be problem. It depends which section is filled the first. If data and then text (RO) the troubles begin. If the order is vice versa then some part of text can be RW instead of RO, but it should work and cache should not be a problem. But I have not dig into this case too much. Only short glimpse. One option is to define 1 MB alignment between text ad data for RPi case. There is quite a lot of memory when compared to most RTEMS embedded targets to the waste is not so important. I didn't quite get what this means. I have no clue on how to proceed with this. The MMU defines memory regions in 1MB chunks. Each chunk can have its own permissions (read-only, or read-write) set. If the .text and .data (or some other section) overlaps in the same 1MB chunk, and the wrong permission gets set, then there can be a problem e.g. part of .data might be RO or part of .text might be RW. Did you try the code Sebastian posted? to change the robarrier to rwbarrier? Ya, but its not helping either. Actually with the change the boot up is hanging even with read/write permission for .text section. Gedare Best wishes, Pavel On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote: Hi, I have attached the report containing outputs of arm-rtems4.11-size and arm-rtems4.11-nm -S. From arm-rtems4.11-nm -S I don't see how memset() is accessing .text section. The start and end values for both are not overlapping. On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom ged...@gwu.edu wrote: On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni krohini1...@gmail.com wrote: On 24 Jul 2015 12:35, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/07/15 23:24, Rohini Kulkarni wrote: I could finally get back to this issue. I used Pi 1 for debugging, but the reason for this problem will apply to Pi 2 also. With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) , a data abort exception occurs with memset() inside bsp_start_clear_bss() function. An illegal write access to an address according to me. Which exception and which address? Something is not working here. This is a part of the debugging output. When I used ARMV7_MMU_CODE_CACHED. (gdb) s bsp_start_clear_bss () at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 126 memset(bsp_section_bss_begin, 0, (size_t) bsp_section_bss_size); What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. (gdb) s memset (m=0x1157e0, c=0, n=64176) at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 59../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such file or directory. (gdb) s 49in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c (gdb) s _ARMV4_Exception_data_abort_default () at ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar m/armv4-exception-default.S:71 71subsp, #MORE_CONTEXT_SIZE When I set text section flag to ARMV7_MMU_READ_WRITE, the system starts successfully. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Wed, Aug 5, 2015 at 1:47 AM, Gedare Bloom ged...@gwu.edu wrote: On Tue, Aug 4, 2015 at 2:18 PM, Rohini Kulkarni krohini1...@gmail.com wrote: On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa ppisa4li...@pikron.com wrote: Hello Rohini and Gedare, On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote: What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. Qiao Yang in RPi 1 BSP now works in the similar area to enable right graphic memory mapping. So my guess is that there could be problem caused by used MMU mode granularity, which is is 1 MB so if RO and RW sections are present in the same 1MB aligned block ten there can be problem. It depends which section is filled the first. If data and then text (RO) the troubles begin. If the order is vice versa then some part of text can be RW instead of RO, but it should work and cache should not be a problem. But I have not dig into this case too much. Only short glimpse. One option is to define 1 MB alignment between text ad data for RPi case. There is quite a lot of memory when compared to most RTEMS embedded targets to the waste is not so important. I didn't quite get what this means. I have no clue on how to proceed with this. The MMU defines memory regions in 1MB chunks. Each chunk can have its own permissions (read-only, or read-write) set. If the .text and .data (or some other section) overlaps in the same 1MB chunk, and the wrong permission gets set, then there can be a problem e.g. part of .data might be RO or part of .text might be RW. Did you try the code Sebastian posted? to change the robarrier to rwbarrier? What exactly are these barriers? Gedare Best wishes, Pavel On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote: Hi, I have attached the report containing outputs of arm-rtems4.11-size and arm-rtems4.11-nm -S. From arm-rtems4.11-nm -S I don't see how memset() is accessing .text section. The start and end values for both are not overlapping. On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom ged...@gwu.edu wrote: On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni krohini1...@gmail.com wrote: On 24 Jul 2015 12:35, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/07/15 23:24, Rohini Kulkarni wrote: I could finally get back to this issue. I used Pi 1 for debugging, but the reason for this problem will apply to Pi 2 also. With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) , a data abort exception occurs with memset() inside bsp_start_clear_bss() function. An illegal write access to an address according to me. Which exception and which address? Something is not working here. This is a part of the debugging output. When I used ARMV7_MMU_CODE_CACHED. (gdb) s bsp_start_clear_bss () at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 126 memset(bsp_section_bss_begin, 0, (size_t) bsp_section_bss_size); What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. (gdb) s memset (m=0x1157e0, c=0, n=64176) at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 59../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such file or directory. (gdb) s 49in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c (gdb) s _ARMV4_Exception_data_abort_default () at ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar m/armv4-exception-default.S:71 71subsp, #MORE_CONTEXT_SIZE When I set text section flag to ARMV7_MMU_READ_WRITE, the system starts successfully. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Tue, Jul 28, 2015 at 5:51 AM, Pavel Pisa ppisa4li...@pikron.com wrote: Hello Rohini and Gedare, On Friday 24 of July 2015 15:33:03 Gedare Bloom wrote: What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. Qiao Yang in RPi 1 BSP now works in the similar area to enable right graphic memory mapping. So my guess is that there could be problem caused by used MMU mode granularity, which is is 1 MB so if RO and RW sections are present in the same 1MB aligned block ten there can be problem. It depends which section is filled the first. If data and then text (RO) the troubles begin. If the order is vice versa then some part of text can be RW instead of RO, but it should work and cache should not be a problem. But I have not dig into this case too much. Only short glimpse. One option is to define 1 MB alignment between text ad data for RPi case. There is quite a lot of memory when compared to most RTEMS embedded targets to the waste is not so important. I didn't quite get what this means. I have no clue on how to proceed with this. Best wishes, Pavel On Friday 24 of July 2015 21:55:00 Rohini Kulkarni wrote: Hi, I have attached the report containing outputs of arm-rtems4.11-size and arm-rtems4.11-nm -S. From arm-rtems4.11-nm -S I don't see how memset() is accessing .text section. The start and end values for both are not overlapping. On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom ged...@gwu.edu wrote: On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni krohini1...@gmail.com wrote: On 24 Jul 2015 12:35, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/07/15 23:24, Rohini Kulkarni wrote: I could finally get back to this issue. I used Pi 1 for debugging, but the reason for this problem will apply to Pi 2 also. With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) , a data abort exception occurs with memset() inside bsp_start_clear_bss() function. An illegal write access to an address according to me. Which exception and which address? Something is not working here. This is a part of the debugging output. When I used ARMV7_MMU_CODE_CACHED. (gdb) s bsp_start_clear_bss () at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 126 memset(bsp_section_bss_begin, 0, (size_t) bsp_section_bss_size); What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. (gdb) s memset (m=0x1157e0, c=0, n=64176) at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 59../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such file or directory. (gdb) s 49in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c (gdb) s _ARMV4_Exception_data_abort_default () at ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/ar m/armv4-exception-default.S:71 71subsp, #MORE_CONTEXT_SIZE When I set text section flag to ARMV7_MMU_READ_WRITE, the system starts successfully. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
Hi, How is the number of processors to be used for an application specified? The used count minimum of that supported in hardware and that configured. How to specify the latter? Thanks. On 29 Jul 2015 15:29, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 29/07/15 11:52, Rohini Kulkarni wrote: On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de mailto: sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. I could locate the function in arm-a9mpcore-smp.c. but it would be helpful if I can know where this being called from, a deeper call hierarchy, so that I can ascertain this is a problem. I can see a Send_messgae function call this. But don't know where the send message is being called from. You can run one of the SMP tests on the realview_pbx_a9_qemu_smp BSP on Qemu and set a break point to _CPU_SMP_Send_interrupt() if you want to know how it is used. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: Hello Rohini, please use the devel list. On 28/07/15 07:41, Rohini Kulkarni wrote: Hi, I wish to understand where the interprocessor interrupts are used during the boot process. During final initialization of SMP I can see rtems_interrupt_handler_install( ARM_GIC_IRQ_SGI_0, IPI, RTEMS_INTERRUPT_UNIQUE, bsp_inter_processor_interrupt, NULL ); Raspberry Pi 2 does not have the generic interrupt controller. Interrupt routing will have to be handled differently. So I wish to understand how/ where it is used. I suppose this might be the problem. Sorry, that the documentation is so scattered. I think we should move everything into the CPU Architecture Supplement. It would be nice if you can help to improve the documentation since you have a different view point. You must install the IPI during the system initialization. It is raised via the _CPU_SMP_Send_interrupt() function, for an example see arm-a9mpcore-smp.c. I could locate the function in arm-a9mpcore-smp.c. but it would be helpful if I can know where this being called from, a deeper call hierarchy, so that I can ascertain this is a problem. I can see a Send_messgae function call this. But don't know where the send message is being called from. Thanks. On Wed, Jul 22, 2015 at 7:08 PM, Rohini Kulkarni krohini1...@gmail.com mailto:krohini1...@gmail.com wrote: Ok. Qemu suggestion seems helpful for the cache configuration issue though. I am trying with Pi 1. Thanks. On 22 Jul 2015 18:59, Sebastian Huber sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de wrote: Sorry, I cannot help you here since I never worked with a Raspberry Pi. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de mailto:sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Rohini Kulkarni -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On 24 Jul 2015 12:35, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/07/15 23:24, Rohini Kulkarni wrote: I could finally get back to this issue. I used Pi 1 for debugging, but the reason for this problem will apply to Pi 2 also. With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) , a data abort exception occurs with memset() inside bsp_start_clear_bss() function. An illegal write access to an address according to me. Which exception and which address? Something is not working here. This is a part of the debugging output. When I used ARMV7_MMU_CODE_CACHED. (gdb) s bsp_start_clear_bss () at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 126 memset(bsp_section_bss_begin, 0, (size_t) bsp_section_bss_size); (gdb) s memset (m=0x1157e0, c=0, n=64176) at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 59../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such file or directory. (gdb) s 49in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c (gdb) s _ARMV4_Exception_data_abort_default () at ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:71 71subsp, #MORE_CONTEXT_SIZE When I set text section flag to ARMV7_MMU_READ_WRITE, the system starts successfully. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Fri, Jul 24, 2015 at 7:03 PM, Gedare Bloom ged...@gwu.edu wrote: On Fri, Jul 24, 2015 at 3:30 AM, Rohini Kulkarni krohini1...@gmail.com wrote: On 24 Jul 2015 12:35, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 23/07/15 23:24, Rohini Kulkarni wrote: I could finally get back to this issue. I used Pi 1 for debugging, but the reason for this problem will apply to Pi 2 also. With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) , a data abort exception occurs with memset() inside bsp_start_clear_bss() function. An illegal write access to an address according to me. Which exception and which address? Something is not working here. This is a part of the debugging output. When I used ARMV7_MMU_CODE_CACHED. (gdb) s bsp_start_clear_bss () at ../../../../../.././raspberrypi/lib/include/bsp/start.h:126 126 memset(bsp_section_bss_begin, 0, (size_t) bsp_section_bss_size); What are the values of bsp_section_bss_begin, and bsp_section_bss_size? Apparently, the memset is trying to write into the .text (code) section, which is a very bad thing to do indeed. (gdb) s memset (m=0x1157e0, c=0, n=64176) These memset parameters indicate the start location bsp_section_bss_begin and size of bss section bsp_section_bss_size. at ../../../../../gcc-4.9.2/newlib/libc/string/memset.c:59 59../../../../../gcc-4.9.2/newlib/libc/string/memset.c: No such file or directory. (gdb) s 49in ../../../../../gcc-4.9.2/newlib/libc/string/memset.c (gdb) s _ARMV4_Exception_data_abort_default () at ../../../../../../../../rtems-local/rtems/c/src/../../cpukit/score/cpu/arm/armv4-exception-default.S:71 71subsp, #MORE_CONTEXT_SIZE When I set text section flag to ARMV7_MMU_READ_WRITE, the system starts successfully. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Tue, Jun 23, 2015 at 4:27 PM, Rohini Kulkarni krohini1...@gmail.com
wrote:
On Tue, Jun 23, 2015 at 1:44 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Please avoid unnecessary white-space changes and white-space at the end
of line.
Something went wrong with the whitespace. I couldn't see that change in
my code. I'll rectify it.
On 22/06/15 22:59, Rohini Kulkarni wrote:
---
.../arm/raspberrypi/startup/mm_config_table.c | 18
+++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
Why is this not ARMV7_MMU_CODE_CACHED? Why can't this BSP use
ARMV7_CP15_START_DEFAULT_SECTIONS?
One question that came up when I figured out last night that this was the
only required change. This was the only uncached normal memory section in
the table. So there were many changes I tried before I made this cacheable.
Why was it not made cacheable (MMU_CODE_CACHED is read only. But then yes,
why is this made read write, differently from
ARMV7_CP15_START_DEFAULT_SECTIONS)
I could finally get back to this issue. I used Pi 1 for debugging, but the
reason for this problem will apply to Pi 2 also.
With text section set to ARMV7_MMU_CODE_CACHED ( which implies read only) ,
a data abort exception occurs with memset() inside bsp_start_clear_bss()
function. An illegal write access to an address according to me.
Making this text section ARMV7_MMU_READ_WRITE causes no problem.
The TEX bits 2 and 1 have been assigned the value for cacheable memory but
are used in the defines for CACHED sections.
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
Such a construct in a shared folder makes no sense.
Thats right. Will change the integration for the two memory
initializations
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0
Raspberry Pi 2 SMP debug
Hi, I need to debug my code to check what is going wrong with SMP initialization. Any suggestions on how I can go about this in the absence of actual debugging hardware? Thanks. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
Hi, I don't have #define RTEMS_SMP 1 in cpuopts.h. Have made changes only to libbsp/arm/raspberrypi/configure . On Sun, Jul 12, 2015 at 1:50 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: In the build tree, there are exactly two identical cpuopts.h files. In this file you must find a: /* if SMP is enabled */ #define RTEMS_SMP 1 -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de http://lists.rtems.org/mailman/listinfo/devel PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Code refactor: Changes to memory management initialization
Hi,
Please review the changes. I will work on the suggestions and make the
required modifications.
Thanks.
On 9 Jul 2015 19:24, krohini1...@gmail.com wrote:
From: Rohini Kulkarni krohini1...@gmail.com
---
c/src/lib/libbsp/arm/raspberrypi/Makefile.am |1 +
c/src/lib/libbsp/arm/raspberrypi/include/bsp.h | 14
.../libbsp/arm/raspberrypi/startup/bspstarthooks.c |8 ++---
.../libbsp/arm/raspberrypi/startup/bspstartmmu.c | 34
c/src/lib/libbsp/arm/shared/mminit.c | 20
c/src/lib/libbsp/shared/include/mm.h |6 +++-
6 files changed, 65 insertions(+), 18 deletions(-)
create mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index d59263c..74545d6 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -131,6 +131,7 @@ libbsp_a_CPPFLAGS +=
-I$(srcdir)/../../../libcpu/arm/shared/include
# Start hooks
libbsp_a_SOURCES += startup/bspstarthooks.c
+libbsp_a_SOURCES += startup/bspstartmmu.c
# LIBMM
libbsp_a_SOURCES += startup/mm_config_table.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
index c05a410..410d9ab 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -33,12 +33,6 @@ extern C {
#define BSP_FEATURE_IRQ_EXTENSION
-#ifdef __cplusplus
-}
-#endif /* __cplusplus */
-
-#endif /* LIBBSP_ARM_RASPBERRYPI_BSP_H */
-
/**
* @defgroup arm_raspberrypi Raspberry Pi Support
*
@@ -47,3 +41,11 @@ extern C {
* @brief Raspberry Pi support package
*
*/
+
+void raspberrypi_setup_mmu_and_cache(void);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_RASPBERRYPI_BSP_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
index 047c8ad..107649f 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
@@ -26,15 +26,15 @@
#include bsp/start.h
#include bsp/raspberrypi.h
#include bsp/mm.h
+#include bsp.h
void BSP_START_TEXT_SECTION bsp_start_hook_0(void)
-{
+{
}
-
void BSP_START_TEXT_SECTION bsp_start_hook_1(void)
{
bsp_start_copy_sections();
- bsp_memory_management_initialize();
+ raspberrypi_setup_mmu_and_cache();
bsp_start_clear_bss();
-}
+}
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
new file mode 100644
index 000..3741070
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
@@ -0,0 +1,34 @@
+#define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
+
+#include bsp/start.h
+#include bsp/arm-cp15-start.h
+#include bsp/linker-symbols.h
+#include libcpu/arm-cp15.h
+#include bsp/mm.h
+#include bsp.h
+
+void raspberrypi_setup_mmu_and_cache(void)
+{
+ uint32_t bsp_initial_mmu_ctrl_set;
+ uint32_t bsp_initial_mmu_ctrl_clear;
+ uint32_t domain_set;
+
+#if (BSP_IS_RPI2 == 1)
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+ bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+ bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+#else
+ bsp_initial_mmu_ctrl_clear = 0;
+ bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_S |
ARM_CP15_CTRL_XP;
+#endif
+ domain_set = ARM_MMU_DEFAULT_CLIENT_DOMAIN;
+
+ bsp_memory_management_initialize(
+bsp_initial_mmu_ctrl_set,
+bsp_initial_mmu_ctrl_clear,
+domain_set
+ );
+}
\ No newline at end of file
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..b477482 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -11,19 +11,25 @@
#include bsp/start.h
#include bsp/arm-cp15-start.h
#include bsp/linker-symbols.h
+#include libcpu/arm-cp15.h
#include bsp/mm.h
-BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
-{
- uint32_t ctrl = arm_cp15_get_control();
-
- ctrl |= ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_S | ARM_CP15_CTRL_XP;
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(
+ uint32_t bsp_initial_mmu_ctrl_set,
+ uint32_t bsp_initial_mmu_ctrl_clear,
+ uint32_t domain_set
+)
+{
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+bsp_initial_mmu_ctrl_clear,
+bsp_initial_mmu_ctrl_set );
+
arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
ctrl,
(uint32_t *) bsp_translation_table_base,
-ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+domain_set,
arm_cp15_start_mmu_config_table[0],
arm_cp15_start_mmu_config_table_size
);
-}
+}
\ No newline at end
Re: SMP support for Raspberry Pi 2
Hi, I am building with the --enable-smp option. But RTEMS_SMP is not getting defined. I have referred to the configure files of other BSPs which includes the script for --enable-smp option and changed the configure script for raspberry pi. What can be the reason, I am unable to understand what I am missing. Thanks. On 3 Jul 2015 22:43, Joel Sherrill joel.sherr...@oarcorp.com wrote: On July 3, 2015 11:53:07 AM CDT, Rohini Kulkarni krohini1...@gmail.com wrote: Any help that I can with this? On 1 Jul 2015 16:59, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I wish to know where the maximum number of processors for a variant are configured. I took a look at some configure scripts. I could see the processor count defined for xilinx-zynq in its configuration file as ZYNQ_CPUS=2. This looks to be BSP specific and could originate in configure.ac or a .h file. It is likely that each BSP has an underlying hardware limit. rtems_configuration_get_maximum_processors() called in gets this configured number. But I don't know from where. This is set initially based on the confdefs.h parameter CONFIGURE_SMP_MAXIMUM_PROCESSORS or something close to that (on phone). Ultimately the maximum CPUs for an application is the lower of those available or RTEMS is configured for. Also where is RTEMS_SMP defined for a bsp? A side-effect of building with --enable-smp. Thanks. -- Rohini Kulkarni --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Code refactor for ARM bsp MMU initialization
Hi,
I have made the suggested changes.
git send-email is failing to send the patch, need to settle it. Please
review the attached file.
Thanks.
On Wed, Jul 8, 2015 at 7:04 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
On 08/07/15 15:10, Rohini Kulkarni wrote:
On Wed, Jul 8, 2015 at 6:29 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de
mailto:sebastian.hu...@embedded-brains.de wrote:
Hello Rohini,
please use git format-patch to generate the patches.
Actually,that is what I have used. I pasted the patch here from the
resulting file.
Better use git send-email, or send the file as is since this will preserve
the commit message and author.
On 08/07/15 14:44, Rohini Kulkarni wrote:
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
@@ -0,0 +1,30 @@
+#define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
+
+#include bsp/start.h
+#include bsp/arm-cp15-start.h
+#include bsp/linker-symbols.h
+#include libcpu/arm-cp15.h
+#include bsp/mm.h
+#include bsp.h
+
+uint32_t bsp_initial_mmu_ctrl_set;
+uint32_t bsp_initial_mmu_ctrl_clear;
+uint32_t domain_set;
+
+void raspberrypi_setup_mmu_and_cache(void)
+{
+#if (BSP_IS_RPI2 == 1)
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+ bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+ bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+#else
+ bsp_initial_mmu_ctrl_clear = 0;
+ bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
ARM_CP15_CTRL_S | ARM_CP15_CTRL_XP;
+#endif
+ domain_set = ARM_MMU_DEFAULT_CLIENT_DOMAIN;
+
+ bsp_memory_management_initialize();
+}
Is there a reason, why you use global variables instead of
function parameters?
I have set them as extern in mm.h and are directly used in mminit.c
instead of being passed to bsp_memory_management_initialize. They will
be set by the bsp the source is being compiled for.
You should avoid global variables and functions in general. I don't see a
necessity for them here.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Rohini Kulkarni
From fa03daaa813419a0996e0b5cad0025ef85eebfbe Mon Sep 17 00:00:00 2001
From: RCK rck@ubuntu.(none)
Date: Thu, 9 Jul 2015 17:16:49 +0530
Subject: [PATCH 15/15] Code refactor: Changes to memory management initialization
---
c/src/lib/libbsp/arm/raspberrypi/Makefile.am |1 +
c/src/lib/libbsp/arm/raspberrypi/include/bsp.h | 14
.../libbsp/arm/raspberrypi/startup/bspstarthooks.c |8 ++---
.../libbsp/arm/raspberrypi/startup/bspstartmmu.c | 34
c/src/lib/libbsp/arm/shared/mminit.c | 20
c/src/lib/libbsp/shared/include/mm.h |6 +++-
6 files changed, 65 insertions(+), 18 deletions(-)
create mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index d59263c..74545d6 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -131,6 +131,7 @@ libbsp_a_CPPFLAGS += -I$(srcdir)/../../../libcpu/arm/shared/include
# Start hooks
libbsp_a_SOURCES += startup/bspstarthooks.c
+libbsp_a_SOURCES += startup/bspstartmmu.c
# LIBMM
libbsp_a_SOURCES += startup/mm_config_table.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
index c05a410..410d9ab 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -33,12 +33,6 @@ extern C {
#define BSP_FEATURE_IRQ_EXTENSION
-#ifdef __cplusplus
-}
-#endif /* __cplusplus */
-
-#endif /* LIBBSP_ARM_RASPBERRYPI_BSP_H */
-
/**
* @defgroup arm_raspberrypi Raspberry Pi Support
*
@@ -47,3 +41,11 @@ extern C {
* @brief Raspberry Pi support package
*
*/
+
+void raspberrypi_setup_mmu_and_cache(void);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_RASPBERRYPI_BSP_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
index 047c8ad..107649f 100644
--- a/c/src
Code refactor for ARM bsp MMU initialization
C {
* @brief MM Support Package
*/
+extern uint32_t bsp_initial_mmu_ctrl_set;
+extern uint32_t bsp_initial_mmu_ctrl_clear;
+extern uint32_t domain_set;
+
void bsp_memory_management_initialize(void);
#ifdef __cplusplus
--
1.7.9.5
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: SMP support for Raspberry Pi 2
On Wed, Jul 8, 2015 at 6:25 PM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 08/07/15 14:54, Rohini Kulkarni wrote: This piece of code gets the configured number of CPUs. I suppose this number is not specified and will have to be specified by me somewhere in the configurations. But I am unable to find out where. For examples, please have a look at testsuite/smptests. Umm,I don't see how the smptests will help figure out where to configure the number of processors. Don't they just use the number already configured for the variant. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
SMP on ARM
Hi all, I am trying to understand boot up for ARM BSPs so as to be able to implement SMP support for Pi 2. Please correct me where I am wrong. (It is verbose. But I have tried to make things as clear as I could) [1] From start.S for ARM, all cores start together. They run the bsp_start hook 0 and 1 and then go to boot_card() . boot_card() calls rtems_data_sructure_initialize() which further does SMP related initilazations. [2] the bsp_start_hooks include cpu initialization for cache/mmu etc. This is done for all cores before SMP initializations from boot_card(). For Raspberry Pi 2, only primary core, which is core 0, will run after reset, while other cores will wait for a jump address from where to execute. I need to ensure the sequence remains consistent for Pi 2. So before boot_card is called() , I need to get other cores to do the initialization from start.S while core0 waits. Is there something else that can be done? [3] Where do the other cores start waiting for an interrupt from primary core. Where does the interprocessor interrupt come into picture. Thanks! -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] GSoC: Cache configurations Raspberry Pi 2 support
On Tue, Jun 23, 2015 at 1:44 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de wrote:
Please avoid unnecessary white-space changes and white-space at the end of
line.
Something went wrong with the whitespace. I couldn't see that change in my
code. I'll rectify it.
On 22/06/15 22:59, Rohini Kulkarni wrote:
---
.../arm/raspberrypi/startup/mm_config_table.c | 18 +++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
Why is this not ARMV7_MMU_CODE_CACHED? Why can't this BSP use
ARMV7_CP15_START_DEFAULT_SECTIONS?
One question that came up when I figured out last night that this was the
only required change. This was the only uncached normal memory section in
the table. So there were many changes I tried before I made this cacheable.
Why was it not made cacheable (MMU_CODE_CACHED is read only. But then yes,
why is this made read write, differently from
ARMV7_CP15_START_DEFAULT_SECTIONS)
The TEX bits 2 and 1 have been assigned the value for cacheable memory but
are used in the defines for CACHED sections.
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
Such a construct in a shared folder makes no sense.
Thats right. Will change the integration for the two memory initializations
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0],
+arm_cp15_start_mmu_config_table_size
+ );
+}
+#else
BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
{
uint32_t ctrl = arm_cp15_get_control();
@@ -27,3 +49,4 @@ BSP_START_TEXT_SECTION void
bsp_memory_management_initialize(void)
arm_cp15_start_mmu_config_table_size
);
}
+#endif
\ No newline at end of file
--
1.7.9.5
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org
[PATCH] GSoC: Cache configurations Raspberry Pi 2 support
---
.../arm/raspberrypi/startup/mm_config_table.c | 18 +++
c/src/lib/libbsp/arm/shared/mminit.c | 23
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
index 8a6d37a..dd1941e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mm_config_table.c
@@ -31,39 +31,39 @@ const arm_cp15_start_section_config
arm_cp15_start_mmu_config_table[] = {
}, {
.begin = (uint32_t) bsp_section_fast_data_begin,
.end = (uint32_t) bsp_section_fast_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_start_begin,
.end = (uint32_t) bsp_section_start_end,
-.flags = ARMV7_MMU_CODE_CACHED
+.flags = ARMV7_MMU_CODE_CACHED
}, {
.begin = (uint32_t) bsp_section_vector_begin,
.end = (uint32_t) bsp_section_vector_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_text_begin,
.end = (uint32_t) bsp_section_text_end,
-.flags = ARMV7_MMU_READ_WRITE
+.flags = ARMV7_MMU_READ_WRITE | ARM_MMU_SECT_C | ARM_MMU_SECT_B
}, {
.begin = (uint32_t) bsp_section_rodata_begin,
.end = (uint32_t) bsp_section_rodata_end,
-.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
+.flags = ARMV7_MMU_DATA_READ_ONLY_CACHED
}, {
.begin = (uint32_t) bsp_section_data_begin,
.end = (uint32_t) bsp_section_data_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_bss_begin,
.end = (uint32_t) bsp_section_bss_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_work_begin,
.end = (uint32_t) bsp_section_work_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = (uint32_t) bsp_section_stack_begin,
.end = (uint32_t) bsp_section_stack_end,
-.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
+.flags = ARMV7_MMU_DATA_READ_WRITE_CACHED
}, {
.begin = RPI_PERIPHERAL_BASE,
.end = RPI_PERIPHERAL_BASE + RPI_PERIPHERAL_SIZE,
diff --git a/c/src/lib/libbsp/arm/shared/mminit.c
b/c/src/lib/libbsp/arm/shared/mminit.c
index acfbfc0..96ca1ec 100644
--- a/c/src/lib/libbsp/arm/shared/mminit.c
+++ b/c/src/lib/libbsp/arm/shared/mminit.c
@@ -13,6 +13,28 @@
#include bsp/linker-symbols.h
#include bsp/mm.h
+#if (BSP_IS_RPI2 == 1)
+BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
+{
+ /* Enable SMP in auxiliary control */
+ uint32_t actlr = arm_cp15_get_auxiliary_control();
+ actlr |= ARM_CORTEX_A9_ACTL_SMP;
+ arm_cp15_set_auxiliary_control(actlr);
+
+ uint32_t ctrl = arm_cp15_start_setup_mmu_and_cache(
+ARM_CP15_CTRL_A,
+ARM_CP15_CTRL_AFE| ARM_CP15_CTRL_Z
+ );
+
+ arm_cp15_start_setup_translation_table_and_enable_mmu_and_cache(
+ctrl,
+(uint32_t *) bsp_translation_table_base,
+ARM_MMU_DEFAULT_CLIENT_DOMAIN,
+arm_cp15_start_mmu_config_table[0],
+arm_cp15_start_mmu_config_table_size
+ );
+}
+#else
BSP_START_TEXT_SECTION void bsp_memory_management_initialize(void)
{
uint32_t ctrl = arm_cp15_get_control();
@@ -27,3 +49,4 @@ BSP_START_TEXT_SECTION void
bsp_memory_management_initialize(void)
arm_cp15_start_mmu_config_table_size
);
}
+#endif
\ No newline at end of file
--
1.7.9.5
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015: Raspberry Pi 2 Support
Hello, Are these the relevant functions from ~/rtems/cpukit/score/cpu/arm/rtems/score/cpu.h? _CPU_SMP_Get_current_processor() _CPU_SMP_Send_interrupt() _CPU_SMP_Processor_event_broadcast() _CPU_SMP_Processor_event_receive() I am unable to understand how ~/rtems/cpukit/score/cpu/no_cpu/rtems/score/no_cpu.h can be used. And am I right if I say these are in addition to what I have identified? Thanks! On Sun, Jun 21, 2015 at 12:50 PM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: Hello Rohini, the CPU functions relevant for SMP are documented in the no_cpu/cpu.h file. - Am 20. Jun 2015 um 22:02 schrieb Rohini Kulkarni krohini1...@gmail.com: Hi, I have added an SMP related post to my blog to define where exactly in the code I need to work. Some feedback to indicate if I am identifying the work area correctly would be very helpful! -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015: Raspberry Pi 2 Support
Hi all, I have managed to get a significant performance improvement with some changes in configurations. The measured time was for dhrystones reduced from 12 to too small to be measured For dhrystones the time was 0.4. The number of dhrystones per second increased from approximately 8 to 250 :) Thanks! On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I have added an SMP related post to my blog to define where exactly in the code I need to work. Some feedback to indicate if I am identifying the work area correctly would be very helpful! Thanks! On 18 Jun 2015 03:37, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have updated my blog to reflect my understanding and attempts for cache performance issue. Lately I have been trying around memory attributes for the mm_config_table. One set of configurations for cacheable memory (inner and outer levels)ended up reducing performance further ( which I really thought would improve). So this table set up certainly controls performance. The results are not improving after turning on cache. So memory sections are perhaps not even getting cached. I get a feeling it has got to do with this mm_config_table. Updates from the github code and blog might help in further discussion. Link to github code:https://github.com/krohini1593/rtems/tree/rohini Link to Blog http://rohiniwithrpi2.blogspot.in/p/blog-page_3.html Thanks! On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution. I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, Gedare Bloom ged...@gwu.edu wrote: On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni krohini1...@gmail.com wrote: But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. Ouch. Make sure you put it in a safe space for development, clear of threats like moisture, static shock, and cats. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote The person who posted the above comment (mrvn) posted the code here: https://github.com/mrvn/test/blob/master/mmu.cc Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop always accessing the bus. By putting this option
Re: GSoC 2015: Raspberry Pi 2 Support
:) There is very little code that had to be added. I need to clean the code and add conditional call for Pi 2. Then I would be ready to submit a patch. On 22 Jun 2015 00:52, Gedare Bloom ged...@gwu.edu wrote: On Sun, Jun 21, 2015 at 3:04 PM, Rohini Kulkarni krohini1...@gmail.com wrote: I missed mentioning the number of dhrystones in the previous mail. Originally it was 1 million. The new number of dhrystones I executed is 100 million. The next thing to do is to figure out what changes are contributing to the performance improvement, and then prepare patches. :) Great work On Mon, Jun 22, 2015 at 12:29 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have managed to get a significant performance improvement with some changes in configurations. The measured time was for dhrystones reduced from 12 to too small to be measured For dhrystones the time was 0.4. The number of dhrystones per second increased from approximately 8 to 250 :) Thanks! On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I have added an SMP related post to my blog to define where exactly in the code I need to work. Some feedback to indicate if I am identifying the work area correctly would be very helpful! Thanks! On 18 Jun 2015 03:37, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have updated my blog to reflect my understanding and attempts for cache performance issue. Lately I have been trying around memory attributes for the mm_config_table. One set of configurations for cacheable memory (inner and outer levels)ended up reducing performance further ( which I really thought would improve). So this table set up certainly controls performance. The results are not improving after turning on cache. So memory sections are perhaps not even getting cached. I get a feeling it has got to do with this mm_config_table. Updates from the github code and blog might help in further discussion. Link to github code:https://github.com/krohini1593/rtems/tree/rohini Link to Blog Thanks! On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution. I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, Gedare Bloom ged...@gwu.edu wrote: On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni krohini1...@gmail.com wrote: But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. Ouch. Make sure you put it in a safe space for development, clear of threats like moisture, static shock, and cats. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread
Re: GSoC 2015: Raspberry Pi 2 Support
I missed mentioning the number of dhrystones in the previous mail. Originally it was 1 million. The new number of dhrystones I executed is 100 million. On Mon, Jun 22, 2015 at 12:29 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have managed to get a significant performance improvement with some changes in configurations. The measured time was for dhrystones reduced from 12 to too small to be measured For dhrystones the time was 0.4. The number of dhrystones per second increased from approximately 8 to 250 :) Thanks! On Sun, Jun 21, 2015 at 1:32 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I have added an SMP related post to my blog to define where exactly in the code I need to work. Some feedback to indicate if I am identifying the work area correctly would be very helpful! Thanks! On 18 Jun 2015 03:37, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have updated my blog to reflect my understanding and attempts for cache performance issue. Lately I have been trying around memory attributes for the mm_config_table. One set of configurations for cacheable memory (inner and outer levels)ended up reducing performance further ( which I really thought would improve). So this table set up certainly controls performance. The results are not improving after turning on cache. So memory sections are perhaps not even getting cached. I get a feeling it has got to do with this mm_config_table. Updates from the github code and blog might help in further discussion. Link to github code:https://github.com/krohini1593/rtems/tree/rohini Link to Blog http://rohiniwithrpi2.blogspot.in/p/blog-page_3.html Thanks! On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution. I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, Gedare Bloom ged...@gwu.edu wrote: On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni krohini1...@gmail.com wrote: But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. Ouch. Make sure you put it in a safe space for development, clear of threats like moisture, static shock, and cats. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote
Re: GSoC 2015: Raspberry Pi 2 Support
Hi, I have added an SMP related post to my blog to define where exactly in the code I need to work. Some feedback to indicate if I am identifying the work area correctly would be very helpful! Thanks! On 18 Jun 2015 03:37, Rohini Kulkarni krohini1...@gmail.com wrote: Hi all, I have updated my blog to reflect my understanding and attempts for cache performance issue. Lately I have been trying around memory attributes for the mm_config_table. One set of configurations for cacheable memory (inner and outer levels)ended up reducing performance further ( which I really thought would improve). So this table set up certainly controls performance. The results are not improving after turning on cache. So memory sections are perhaps not even getting cached. I get a feeling it has got to do with this mm_config_table. Updates from the github code and blog might help in further discussion. Link to github code:https://github.com/krohini1593/rtems/tree/rohini Link to Blog http://rohiniwithrpi2.blogspot.in/p/blog-page_3.html Thanks! On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution. I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, Gedare Bloom ged...@gwu.edu wrote: On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni krohini1...@gmail.com wrote: But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. Ouch. Make sure you put it in a safe space for development, clear of threats like moisture, static shock, and cats. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote The person who posted the above comment (mrvn) posted the code here: https://github.com/mrvn/test/blob/master/mmu.cc Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop always accessing the bus. By putting this option in the config.txt file you can put the other cores to sleep, speeding up the code on core 1. arm_control=0x1000 It would be worth trying that option to see if the benchmark speeds up. Alan On Jun 2, 2015, at 8:05 AM, Hesham ALMatary heshamelmat...@gmail.com wrote: On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: From what I saw, they have
Re: GSoC 2015: Raspberry Pi 2 Support
Hi all, I have updated my blog to reflect my understanding and attempts for cache performance issue. Lately I have been trying around memory attributes for the mm_config_table. One set of configurations for cacheable memory (inner and outer levels)ended up reducing performance further ( which I really thought would improve). So this table set up certainly controls performance. The results are not improving after turning on cache. So memory sections are perhaps not even getting cached. I get a feeling it has got to do with this mm_config_table. Updates from the github code and blog might help in further discussion. Link to github code:https://github.com/krohini1593/rtems/tree/rohini Link to Blog http://rohiniwithrpi2.blogspot.in/p/blog-page_3.html Thanks! On Mon, Jun 15, 2015 at 8:29 PM, Alan Cudmore alan.cudm...@gmail.com wrote: Hi, Some of the code examples may give you some clues. Like this one: https://github.com/mrvn/test/blob/master/smp.cc Or this: https://github.com/PeterLemon/RaspberryPi/tree/master/SMP/SMPINIT If you still can't figure it out, you can always join the raspberrypi.org forums and ask on this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 When it comes to the Pi 2 and SMP, you are our RTEMS expert :) Thanks, Alan On Sat, Jun 13, 2015 at 2:29 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, This is regarding Pi 2 SMP support. After powering on, the secondary mailboxes read one of their four mailbox registers and wait for a non-zero content to be written. This content is to be the physical address of the location from where the cores are expected to start execution. I am stuck at figuring out this address. How should I go about understanding this? Thanks! On 3 Jun 2015 19:44, Gedare Bloom ged...@gwu.edu wrote: On Wed, Jun 3, 2015 at 2:39 AM, Rohini Kulkarni krohini1...@gmail.com wrote: But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. Ouch. Make sure you put it in a safe space for development, clear of threats like moisture, static shock, and cats. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote The person who posted the above comment (mrvn) posted the code here: https://github.com/mrvn/test/blob/master/mmu.cc Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop always accessing the bus. By putting this option in the config.txt file you can put the other cores to sleep, speeding up the code on core 1. arm_control=0x1000 It would be worth trying that option to see if the benchmark speeds up. Alan On Jun 2, 2015, at 8:05 AM, Hesham ALMatary heshamelmat...@gmail.com wrote: On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: From what I saw, they have to be enabled separately. Cache/mmu are disabled upon reset. For the existing Raspberry BSP [1] there's a code for MMU/Cache init, however I don't know about Pi2 and where its code is. [1] https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi On 2
Re: GSoC 2015: Raspberry Pi 2 Support
But, I can't say cache configurations have a role here. I'll push my code to my github project soon. P.S. The Pi2 board I possess seems to have broken down. It just isn't turning on. Unable to test further. Will order one immediately. On 3 Jun 2015 09:03, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote The person who posted the above comment (mrvn) posted the code here: https://github.com/mrvn/test/blob/master/mmu.cc Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop always accessing the bus. By putting this option in the config.txt file you can put the other cores to sleep, speeding up the code on core 1. arm_control=0x1000 It would be worth trying that option to see if the benchmark speeds up. Alan On Jun 2, 2015, at 8:05 AM, Hesham ALMatary heshamelmat...@gmail.com wrote: On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: From what I saw, they have to be enabled separately. Cache/mmu are disabled upon reset. For the existing Raspberry BSP [1] there's a code for MMU/Cache init, however I don't know about Pi2 and where its code is. [1] https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi On 2 Jun 2015 16:59, Hesham ALMatary heshamelmat...@gmail.com wrote: Hi, Aren't the MMU/Caches enabled by default for RPi [1]? [1] https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: Dr. Joel, So we can't say something solely on the basis of this result? I don't think so. If Linux performs the same, then what you did is as good as it gets. However, if Linux is faster then some setting still isn't right. You need a reference measurement to have any confidence. It is possible you did something but didn't actually turn the cache (or all the cache) on. On 2 Jun 2015 16:28, Rohini Kulkarni krohini1...@gmail.com wrote: I have not run it under linux on pi2 yet. Will have to run and check the result. On 2 Jun 2015 16:16, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: HI, I tried running the dhrystone benchmark with some changes for cache/mmu set up. However, the output shows a reduction in performance. The time to run through the dhrystone has increased from 12 to 13 and dhrystones run per second decreased. According to this result, things were better with caches disabled. I have been working on this since two days and could not figure out an improvement. Any pointers? How did it do under Linux on the Pi2? Thanks. On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi All, I have to implement the cache coherency support for Cortex A7. But for A7 MPCore, unlike for A9, I am not able to find any register description for the Snoop Control Unit from the TRM. I need help here on how to proceed. Additionally for A9 there is a single bit for A9 in the Auxiliary Control Register which enables cache broadcast operations. The register format is different for A7 and again I am unable to find how to achieve the same for A7. Thanks! On Tue, May 5
Re: GSoC 2015: Raspberry Pi 2 Support
Hi, Alan, your suggestion has resulted in much improvement arm_control=0x1000 This has simply worked! Looks like the other cores were taking up plenty of time. I was aware from references that the other cores run a WFI, but ya, did not get its impact. Time for each dhrystone has reduced to 7 from 13 and the no of dhrystones per second also increased. But this is a change only in the config.txt not actually in the boot code. Thanks Rohini On Wed, Jun 3, 2015 at 7:12 AM, Alan Cudmore alan.cudm...@gmail.com wrote: The caches are being enabled on the RPI 1 BSP. The same code is being executed by the RPI 2 BSP, but obviously it’s not sufficient for the cache setup. I have been reading through this long thread, and it is very informative: https://www.raspberrypi.org/forums/viewtopic.php?f=72t=98904 I am starting to understand the setup that is required to enable caches on the RPI 2. For example this message near the bottom of page 3 gives a good indication of the speedup available by configuring the MMU and caches correctly: Quote from above thread -- Enabling I/D caches and branch prediction, just like the julia demo uses, it takes ~12 seconds, or ~21 fps. It's just one core but also a much smaller loop than the julia demo has. Enabling the MMU and mapping memory inner/outer write-back, write allocate and the framebuffer inner write-through, no write allocate + outer write-back, write-allocate it takes ~8 seconds, of 32 fps. PS: 640x480x32 with MMU gets me ~256 fps. Must have a greater L2 cache effect. - End of quote The person who posted the above comment (mrvn) posted the code here: https://github.com/mrvn/test/blob/master/mmu.cc Also, it seems that when the Pi 2 starts up, cores 1-3 are put in a wait loop always accessing the bus. By putting this option in the config.txt file you can put the other cores to sleep, speeding up the code on core 1. arm_control=0x1000 It would be worth trying that option to see if the benchmark speeds up. Alan On Jun 2, 2015, at 8:05 AM, Hesham ALMatary heshamelmat...@gmail.com wrote: On Tue, Jun 2, 2015 at 12:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: From what I saw, they have to be enabled separately. Cache/mmu are disabled upon reset. For the existing Raspberry BSP [1] there's a code for MMU/Cache init, however I don't know about Pi2 and where its code is. [1] https://github.com/RTEMS/rtems/tree/master/c/src/lib/libbsp/arm/raspberrypi On 2 Jun 2015 16:59, Hesham ALMatary heshamelmat...@gmail.com wrote: Hi, Aren't the MMU/Caches enabled by default for RPi [1]? [1] https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: Dr. Joel, So we can't say something solely on the basis of this result? I don't think so. If Linux performs the same, then what you did is as good as it gets. However, if Linux is faster then some setting still isn't right. You need a reference measurement to have any confidence. It is possible you did something but didn't actually turn the cache (or all the cache) on. On 2 Jun 2015 16:28, Rohini Kulkarni krohini1...@gmail.com wrote: I have not run it under linux on pi2 yet. Will have to run and check the result. On 2 Jun 2015 16:16, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: HI, I tried running the dhrystone benchmark with some changes for cache/mmu set up. However, the output shows a reduction in performance. The time to run through the dhrystone has increased from 12 to 13 and dhrystones run per second decreased. According to this result, things were better with caches disabled. I have been working on this since two days and could not figure out an improvement. Any pointers? How did it do under Linux on the Pi2? Thanks. On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi All, I have to implement the cache coherency support for Cortex A7. But for A7 MPCore, unlike for A9, I am not able to find any register description for the Snoop Control Unit from the TRM. I need help here on how to proceed. Additionally for A9 there is a single bit for A9 in the Auxiliary Control Register which enables cache broadcast operations. The register format is different for A7 and again I am unable to find how to achieve the same for A7. Thanks! On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 5/5/2015 11:11 AM, Rohini Kulkarni wrote: Hi, I am working with the code for bsp hooks. I am referring to existing ARM multicore bsp codes, zync mainly. 1. There are existing hooks for the raspberry pi. Where should the code for the Pi2
Re: GSoC 2015: Raspberry Pi 2 Support
From what I saw, they have to be enabled separately. Cache/mmu are disabled upon reset. On 2 Jun 2015 16:59, Hesham ALMatary heshamelmat...@gmail.com wrote: Hi, Aren't the MMU/Caches enabled by default for RPi [1]? [1] https://github.com/RTEMS/rtems/blob/master/c/src/lib/libbsp/arm/shared/mminit.c On Tue, Jun 2, 2015 at 12:18 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 7:01:21 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: Dr. Joel, So we can't say something solely on the basis of this result? I don't think so. If Linux performs the same, then what you did is as good as it gets. However, if Linux is faster then some setting still isn't right. You need a reference measurement to have any confidence. It is possible you did something but didn't actually turn the cache (or all the cache) on. On 2 Jun 2015 16:28, Rohini Kulkarni krohini1...@gmail.com wrote: I have not run it under linux on pi2 yet. Will have to run and check the result. On 2 Jun 2015 16:16, Joel Sherrill joel.sherr...@oarcorp.com wrote: On June 2, 2015 5:58:33 AM EDT, Rohini Kulkarni krohini1...@gmail.com wrote: HI, I tried running the dhrystone benchmark with some changes for cache/mmu set up. However, the output shows a reduction in performance. The time to run through the dhrystone has increased from 12 to 13 and dhrystones run per second decreased. According to this result, things were better with caches disabled. I have been working on this since two days and could not figure out an improvement. Any pointers? How did it do under Linux on the Pi2? Thanks. On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi All, I have to implement the cache coherency support for Cortex A7. But for A7 MPCore, unlike for A9, I am not able to find any register description for the Snoop Control Unit from the TRM. I need help here on how to proceed. Additionally for A9 there is a single bit for A9 in the Auxiliary Control Register which enables cache broadcast operations. The register format is different for A7 and again I am unable to find how to achieve the same for A7. Thanks! On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 5/5/2015 11:11 AM, Rohini Kulkarni wrote: Hi, I am working with the code for bsp hooks. I am referring to existing ARM multicore bsp codes, zync mainly. 1. There are existing hooks for the raspberry pi. Where should the code for the Pi2 hooks be added? The Pi and Pi2 are remarkably similar so Pi2 should be placed inside the Pi BSP directory. There is already a Pi2 variant of that code built. But we know specific places where there are variances. Depending on the scope of what is different, it can be as simple as a cpp conditional in a .h to select a value or two implementations of a single method and the Makefile.am picking the right file to build based on the board variant. The big question to always ask is: Is this specific to the Pi2 and incompatible with the Pi? Since the Pi BSP is still missing capabilities, it is likely code common to both will be added this summer. For example, did the mailbox interface change? I don't know but would guess that it didn't. Each new capability added needs that added. And any differences need to be analyzed to pick the least intrusive way to provide alternate implementations. Or enable special code like the Pi2 SMP support which is dependent on --enable-smp and being a Pi2. 2. Am I right in understanding that I will have to implement A7 specific functions as have been for A9? I am referring specifically to the arm-a9mpcore-start.h Yes. If the code is very similar between the a7 and a9, then a discussion on devel@ should occur to decide the best way to minimize duplication. If you end up with a7 specific code, you should follow the location and naming patterns already established. That places it in libbsp/arm/shared/... so it can be used by any BSP with the right SMP core. I am referring to existing codes to locate and get hold of what needs to be done in the hooks. However, being new to such implementations, I am taking longer to understand the details. Any suggestions that might help here are welcome The answer will depend on the factors listed above. When code can be shared, we want to share it across as many BSPs as makes sense. When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then you want to find the way to account for the variation in the least intrusive code way possible. Thanks! On 1 May 2015 12:45, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Excited to be a part of this edition of GSoC! Thanks to everybody for helping me get here and congratulations to all the participating students! So, now getting to work, firstly I wish to know, specifically from
Re: GSoC 2015: Raspberry Pi 2 Support
HI, I tried running the dhrystone benchmark with some changes for cache/mmu set up. However, the output shows a reduction in performance. The time to run through the dhrystone has increased from 12 to 13 and dhrystones run per second decreased. According to this result, things were better with caches disabled. I have been working on this since two days and could not figure out an improvement. Any pointers? Thanks. On Thu, May 28, 2015 at 8:41 PM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi All, I have to implement the cache coherency support for Cortex A7. But for A7 MPCore, unlike for A9, I am not able to find any register description for the Snoop Control Unit from the TRM. I need help here on how to proceed. Additionally for A9 there is a single bit for A9 in the Auxiliary Control Register which enables cache broadcast operations. The register format is different for A7 and again I am unable to find how to achieve the same for A7. Thanks! On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 5/5/2015 11:11 AM, Rohini Kulkarni wrote: Hi, I am working with the code for bsp hooks. I am referring to existing ARM multicore bsp codes, zync mainly. 1. There are existing hooks for the raspberry pi. Where should the code for the Pi2 hooks be added? The Pi and Pi2 are remarkably similar so Pi2 should be placed inside the Pi BSP directory. There is already a Pi2 variant of that code built. But we know specific places where there are variances. Depending on the scope of what is different, it can be as simple as a cpp conditional in a .h to select a value or two implementations of a single method and the Makefile.am picking the right file to build based on the board variant. The big question to always ask is: Is this specific to the Pi2 and incompatible with the Pi? Since the Pi BSP is still missing capabilities, it is likely code common to both will be added this summer. For example, did the mailbox interface change? I don't know but would guess that it didn't. Each new capability added needs that added. And any differences need to be analyzed to pick the least intrusive way to provide alternate implementations. Or enable special code like the Pi2 SMP support which is dependent on --enable-smp and being a Pi2. 2. Am I right in understanding that I will have to implement A7 specific functions as have been for A9? I am referring specifically to the arm-a9mpcore-start.h Yes. If the code is very similar between the a7 and a9, then a discussion on devel@ should occur to decide the best way to minimize duplication. If you end up with a7 specific code, you should follow the location and naming patterns already established. That places it in libbsp/arm/shared/... so it can be used by any BSP with the right SMP core. I am referring to existing codes to locate and get hold of what needs to be done in the hooks. However, being new to such implementations, I am taking longer to understand the details. Any suggestions that might help here are welcome The answer will depend on the factors listed above. When code can be shared, we want to share it across as many BSPs as makes sense. When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then you want to find the way to account for the variation in the least intrusive code way possible. Thanks! On 1 May 2015 12:45, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Excited to be a part of this edition of GSoC! Thanks to everybody for helping me get here and congratulations to all the participating students! So, now getting to work, firstly I wish to know, specifically from my mentors, any changes that must be made to my proposed project or schedule. Secondly, are there any specifics for the development blog that we need to create for the project? Over time what is the blog expected to convey. Also, I have to create a new wiki page for my project as none exists. I want to know how to add one. -- Rohini Kulkarni -- Joel Sherrill, Ph.D. Director of Research developmentjoel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Rohini Kulkarni -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015: Raspberry Pi 2 Support
Hi All, I have to implement the cache coherency support for Cortex A7. But for A7 MPCore, unlike for A9, I am not able to find any register description for the Snoop Control Unit from the TRM. I need help here on how to proceed. Additionally for A9 there is a single bit for A9 in the Auxiliary Control Register which enables cache broadcast operations. The register format is different for A7 and again I am unable to find how to achieve the same for A7. Thanks! On Tue, May 5, 2015 at 10:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 5/5/2015 11:11 AM, Rohini Kulkarni wrote: Hi, I am working with the code for bsp hooks. I am referring to existing ARM multicore bsp codes, zync mainly. 1. There are existing hooks for the raspberry pi. Where should the code for the Pi2 hooks be added? The Pi and Pi2 are remarkably similar so Pi2 should be placed inside the Pi BSP directory. There is already a Pi2 variant of that code built. But we know specific places where there are variances. Depending on the scope of what is different, it can be as simple as a cpp conditional in a .h to select a value or two implementations of a single method and the Makefile.am picking the right file to build based on the board variant. The big question to always ask is: Is this specific to the Pi2 and incompatible with the Pi? Since the Pi BSP is still missing capabilities, it is likely code common to both will be added this summer. For example, did the mailbox interface change? I don't know but would guess that it didn't. Each new capability added needs that added. And any differences need to be analyzed to pick the least intrusive way to provide alternate implementations. Or enable special code like the Pi2 SMP support which is dependent on --enable-smp and being a Pi2. 2. Am I right in understanding that I will have to implement A7 specific functions as have been for A9? I am referring specifically to the arm-a9mpcore-start.h Yes. If the code is very similar between the a7 and a9, then a discussion on devel@ should occur to decide the best way to minimize duplication. If you end up with a7 specific code, you should follow the location and naming patterns already established. That places it in libbsp/arm/shared/... so it can be used by any BSP with the right SMP core. I am referring to existing codes to locate and get hold of what needs to be done in the hooks. However, being new to such implementations, I am taking longer to understand the details. Any suggestions that might help here are welcome The answer will depend on the factors listed above. When code can be shared, we want to share it across as many BSPs as makes sense. When it is unique to a specific BSP **variant** (e.g. Pi vs Pi2), then you want to find the way to account for the variation in the least intrusive code way possible. Thanks! On 1 May 2015 12:45, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Excited to be a part of this edition of GSoC! Thanks to everybody for helping me get here and congratulations to all the participating students! So, now getting to work, firstly I wish to know, specifically from my mentors, any changes that must be made to my proposed project or schedule. Secondly, are there any specifics for the development blog that we need to create for the project? Over time what is the blog expected to convey. Also, I have to create a new wiki page for my project as none exists. I want to know how to add one. -- Rohini Kulkarni -- Joel Sherrill, Ph.D. Director of Research developmentjoel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSoC 2015: Raspberry Pi 2 Support
Hi, I am working with the code for bsp hooks. I am referring to existing ARM multicore bsp codes, zync mainly. 1. There are existing hooks for the raspberry pi. Where should the code for the Pi2 hooks be added? 2. Am I right in understanding that I will have to implement A7 specific functions as have been for A9? I am referring specifically to the arm-a9mpcore-start.h I am referring to existing codes to locate and get hold of what needs to be done in the hooks. However, being new to such implementations, I am taking longer to understand the details. Any suggestions that might help here are welcome Thanks! On 1 May 2015 12:45, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, Excited to be a part of this edition of GSoC! Thanks to everybody for helping me get here and congratulations to all the participating students! So, now getting to work, firstly I wish to know, specifically from my mentors, any changes that must be made to my proposed project or schedule. Secondly, are there any specifics for the development blog that we need to create for the project? Over time what is the blog expected to convey. Also, I have to create a new wiki page for my project as none exists. I want to know how to add one. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GS0C 2015-Hello Word
Hi,
I was yet to submit the patch for hello world.
Attaching it here.
On Thu, Mar 26, 2015 at 7:15 PM, Gedare Bloom ged...@gwu.edu wrote:
Yes this is acceptable, thanks! Please post your patch too.
-Gedare
On Thu, Mar 26, 2015 at 1:07 AM, Rohini Kulkarni krohini1...@gmail.com
wrote:
Hi All,
I have chosen Raspberry Pi 2 support as my project. I recently received
the
raspberry pi board, but do not have a console set up yet. I have run the
the
hello world using QEMU for raspberry pi. Can this be accepted as proof? I
will get the actual pi running as soon as possible.
Please find the attached screenshot.
Thanks!
--
Rohini Kulkarni
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
Rohini Kulkarni
diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index d8fe450..4a57c96 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -28,7 +28,9 @@ rtems_task Init(
)
{
rtems_test_begin();
- printf( Hello World\n );
+ printf( \n\n*** HELLO WORLD TEST ***\n );
+ printf( Hello this is Rohini Kulkarni\n );
+ printf( *** END OF HELLO WORLD TEST ***\n );
rtems_test_end();
exit( 0 );
}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC Raspberry pi 2 project
Hi, I want to know what is the current work going on for Raspberry pi 2 support? The projects looks towards implementing arm architecture support, cache configuration and enabling SMP support. These are all parts of the Raspberry pi 2 BSP right? What work has already been done for the support. Thanks! On 21 Mar 2015 10:40, Rohini Kulkarni krohini1...@gmail.com wrote: Hello, I had a look at updated the project groups for raspberry pi improvements for my proposal. Because I had not tracked the page for a few days I was not aware that the Raspberry pi 2 support tasks had been defined. As I had also asked about SMP support earlier, this projects interests me more. Yes, I am new to bringing up an architecture support. Is the project considered suitable for somebody new to rtems. I want to prepare a draft proposal soon so that it can be reviewed in time. How can I get an idea about the time requirements in order to do my proposal? Some references to start with would be useful to know the current status. Also level of familiarity required and other requirements for implementation. Thanks! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Raspberry pi 2 project
Hello, I had a look at updated the project groups for raspberry pi improvements for my proposal. Because I had not tracked the page for a few days I was not aware that the Raspberry pi 2 support tasks had been defined. As I had also asked about SMP support earlier, this projects interests me more. Yes, I am new to bringing up an architecture support. Is the project considered suitable for somebody new to rtems. I want to prepare a draft proposal soon so that it can be reviewed in time. How can I get an idea about the time requirements in order to do my proposal? Some references to start with would be useful to know the current status. Also level of familiarity required and other requirements for implementation. Thanks! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS build problem
To tell exactly what I am doing, this is how I am updating the autoconf everytime with reference from the source builder documentation $ ../source-builder/sb-set-builder --log=l-4.11-at.txt --prefix=$HOME/development/rtems/4.11 4.11/rtems-autotools and then go on to build the toolset $ export PATH=~/development/rtems/4.11/bin:$PATH $ ../source-builder/sb-set-builder --log=l-4.11-sparc.txt --prefix=$HOME/development/rtems/4.11 4.11/rtems-sparc On Thu, Mar 19, 2015 at 12:41 PM, Chris Johns chr...@rtems.org wrote: On 19/03/2015 4:49 pm, Rohini Kulkarni wrote: There is an issue I've run into a few times. Everytime I run bootstrap script for rtems(say after restarting my machine) the bootstrap says autoconf version is not updated. So I have to build the toolset every such time when I have already built it and only want to compile rtems. Is there something that needs to be done that I'm missing out! Is the build procedure asking you to set your path to the location of the tools ? This error is normally due your path not being set. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS build problem
Hi! There is an issue I've run into a few times. Everytime I run bootstrap script for rtems(say after restarting my machine) the bootstrap says autoconf version is not updated. So I have to build the toolset every such time when I have already built it and only want to compile rtems. Is there something that needs to be done that I'm missing out! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GSoC 2015 - Raspberry Pi improvements
Hi, I am new to using Raspberry pi. I saw the READ ME for Raspberry pi BSP. I have got the files stated there, except the config.txt. I also read some steps on the Raspberry pi website regarding getting the image onto the SD card. Also, I do not understand what the stripping step will do. I need some help to figure out booting RTEMS on the board. Thanks! On 11 Mar 2015 19:29, Gedare Bloom ged...@gwu.edu wrote: On Wed, Mar 11, 2015 at 9:52 AM, Rohini Kulkarni krohini1...@gmail.com wrote: Hi, I am interested in contributing to this project. I referred the page Raspberry Pi improvements and also took a look at the work done under GSoc2013. It would be great if the mentors could help me with some queries. [1] Is there any reference for already proposed ideas. On the page Beagle BSP improvements , I saw a list of missing peripherals. Is there such a list for Raspberry Pi as well? There was an email thread about this recently, see [1]. I think there is plenty of work to do. [2] What are the requirements and how should I proceed for this project. You need to own a Raspberry Pi, or a Raspberry Pi 2. If you have an RPi2, you may consider adding it as a BSP variant and getting SMP working on it as a nice project. You should ideally demonstrate that you can build the tools and boot RTEMS on the RPi. [1] https://lists.rtems.org/pipermail/devel/2015-March/010181.html Thanks! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
GSOC 2015 - SMP Projects
Hi All, I am interested in doing a project under SMP (Improvements to SMP support). Are there any suitable SMP projects which can be undertaken as part of GSOC. However,I do not have an experience with such kind of development. Thanks! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Starting with RTEMS
Hi, How can I figure out which targets can be tested with a simulator. I would like to set up an environment which I can work with further. Thank you. On 17 Feb 2015 06:11, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 2/16/2015 6:33 PM, Nick Withers wrote: On Mon, 2015-02-16 at 22:57 +0530, Rohini Kulkarni wrote: Hi, I am trying to build RTEMS for arm. I want to know what --enable -rtemsbsp in config does, when building RTEMS. Hi Rohini! It selects which Board Support Package(s) (BSP(s)) you'd like to compile RTEMS for - or, if you prefer, which BSPs' code should be compiled - it takes a while for each and building the lot is almost always going to be unnecessary. There're a lot of different ARM variants and boards, what kind do you have? P.S., As a could you help be to use this kind o' question, this one'd probably be best on the users@ list :-) Good answer and I will pitch in that for many cases, you want one that will run on a simulator. Especially if you are looking at potential GSoC projects. :) Thank you. -- Rohini Kulkarni ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
