[PATCH] libcsupport: Workaround for GCC 5.1 and later

[Sebastian Huber]

Disable an optimization which would lead to a recursive calloc() call in
calloc().
---
 cpukit/libcsupport/Makefile.am | 8 ++--
 cpukit/wrapup/Makefile.am  | 1 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
index 7474079..a5da5f1 100644
--- a/cpukit/libcsupport/Makefile.am
+++ b/cpukit/libcsupport/Makefile.am
@@ -1,8 +1,9 @@
 include $(top_srcdir)/automake/multilib.am
 include $(top_srcdir)/automake/compile.am
 
-noinst_LIBRARIES = libcsupport.a
+noinst_LIBRARIES = libcsupport.a libcalloc.a
 libcsupport_a_CPPFLAGS = $(AM_CPPFLAGS)
+libcalloc_a_CPPFLAGS = $(AM_CPPFLAGS)
 
 include_rtemsdir = $(includedir)/rtems
 include_rtems_HEADERS = include/console.h
@@ -79,7 +80,7 @@ ID_C_FILES = src/getegid.c src/geteuid.c src/getgid.c 
src/getgroups.c \
 src/seteuid.c src/setgid.c src/setuid.c src/setegid.c src/setpgid.c \
 src/setsid.c
 
-MALLOC_C_FILES = src/malloc_initialize.c src/calloc.c src/malloc.c \
+MALLOC_C_FILES = src/malloc_initialize.c src/malloc.c \
 src/realloc.c src/_calloc_r.c src/_malloc_r.c \
 src/free.c src/_free_r.c \
 src/_realloc_r.c src/mallocfreespace.c \
@@ -138,6 +139,9 @@ libcsupport_a_SOURCES += $(LIBC_GLUE_C_FILES) 
$(PASSWORD_GROUP_C_FILES) \
 
 libcsupport_a_SOURCES += src/flockfile.c src/funlockfile.c src/ftrylockfile.c
 
+libcalloc_a_SOURCES = src/calloc.c
+libcalloc_a_CFLAGS = -fno-builtin
+
 EXTRA_DIST = src/TODO src/CASES src/README
 
 include $(srcdir)/preinstall.am
diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am
index 53861df..5fd6e33 100644
--- a/cpukit/wrapup/Makefile.am
+++ b/cpukit/wrapup/Makefile.am
@@ -21,6 +21,7 @@ endif
 
 TMP_LIBS += ../libcrypt/libcrypt.a
 TMP_LIBS += ../libcsupport/libcsupport.a
+TMP_LIBS += ../libcsupport/libcalloc.a
 TMP_LIBS += ../libblock/libblock.a
 if LIBDOSFS
 TMP_LIBS += ../libfs/libdosfs.a
-- 
1.8.4.5

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Interrupt server on BBB

[Martin Galvan]

Hi everyone! I'm currently trying to use an interrupt server task for
handling USB interrupts on the Beaglebone Black. Here's the code I'm
using:

rtems_interrupt_server_initialize(1, 1500, RTEMS_TIMESLICE | RTEMS_PREEMPT,
RTEMS_DEFAULT_ATTRIBUTES, NULL);

rtems_interrupt_server_handler_install(NULL, AM335X_INT_USB1, "USB_interrupt",
RTEMS_INTERRUPT_UNIQUE,
reinterpret_cast(USB1HostIntHandler), NULL);

I checked the return codes of both functions and it's always
RTEMS_SUCCESSFUL. At the same time I have a separate thread which is
constantly doing a printk for debugging purposes.

Right now what happens is that the printk thread runs about 10-15
times and then the system hangs in the middle of the print. Am I doing
something wrong?

Thanks a lot!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libcsupport: Workaround for GCC 5.1 and later

[Joel Sherrill]

This is possible to do inside the file itself using function
attributes or pragmas. I am not sure which method is best but
wanted to pass along so we could decide as a group.


optimize
The optimize attribute is used to specify that a function is to be compiled 
with different optimization options than specified on the command line. 
Arguments can either be numbers or strings. Numbers are assumed to be an 
optimization level. Strings that begin with O are assumed to be an optimization 
option, while other options are assumed to be used with a -f prefix. You can 
also use the ‘#pragma GCC optimize’ pragma to set the optimization options that 
affect more than one function. See Function Specific Option Pragmas, for 
details about the ‘#pragma GCC optimize’ pragma.
This can be used for instance to have frequently-executed functions compiled 
with more aggressive optimization options that produce faster and larger code, 
while other functions can be compiled with less aggressive options.



--joel  

On 7/13/2015 3:20 AM, Sebastian Huber wrote:

Disable an optimization which would lead to a recursive calloc() call in
calloc().
---
  cpukit/libcsupport/Makefile.am | 8 ++--
  cpukit/wrapup/Makefile.am  | 1 +
  2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
index 7474079..a5da5f1 100644
--- a/cpukit/libcsupport/Makefile.am
+++ b/cpukit/libcsupport/Makefile.am
@@ -1,8 +1,9 @@
  include $(top_srcdir)/automake/multilib.am
  include $(top_srcdir)/automake/compile.am

-noinst_LIBRARIES = libcsupport.a
+noinst_LIBRARIES = libcsupport.a libcalloc.a
  libcsupport_a_CPPFLAGS = $(AM_CPPFLAGS)
+libcalloc_a_CPPFLAGS = $(AM_CPPFLAGS)

  include_rtemsdir = $(includedir)/rtems
  include_rtems_HEADERS = include/console.h
@@ -79,7 +80,7 @@ ID_C_FILES = src/getegid.c src/geteuid.c src/getgid.c 
src/getgroups.c \
  src/seteuid.c src/setgid.c src/setuid.c src/setegid.c src/setpgid.c \
  src/setsid.c

-MALLOC_C_FILES = src/malloc_initialize.c src/calloc.c src/malloc.c \
+MALLOC_C_FILES = src/malloc_initialize.c src/malloc.c \
  src/realloc.c src/_calloc_r.c src/_malloc_r.c \
  src/free.c src/_free_r.c \
  src/_realloc_r.c src/mallocfreespace.c \
@@ -138,6 +139,9 @@ libcsupport_a_SOURCES += $(LIBC_GLUE_C_FILES) 
$(PASSWORD_GROUP_C_FILES) \

  libcsupport_a_SOURCES += src/flockfile.c src/funlockfile.c src/ftrylockfile.c

+libcalloc_a_SOURCES = src/calloc.c
+libcalloc_a_CFLAGS = -fno-builtin
+
  EXTRA_DIST = src/TODO src/CASES src/README

  include $(srcdir)/preinstall.am
diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am
index 53861df..5fd6e33 100644
--- a/cpukit/wrapup/Makefile.am
+++ b/cpukit/wrapup/Makefile.am
@@ -21,6 +21,7 @@ endif

  TMP_LIBS += ../libcrypt/libcrypt.a
  TMP_LIBS += ../libcsupport/libcsupport.a
+TMP_LIBS += ../libcsupport/libcalloc.a
  TMP_LIBS += ../libblock/libblock.a
  if LIBDOSFS
  TMP_LIBS += ../libfs/libdosfs.a



--
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: Using tar to access files

[Pavel Pisa]

Hello Sujay Raj,


On Tuesday 30 of June 2015 06:39:28 Sujay Raj wrote:
> I need to access configurations files the for web server I am porting to
> rtems.
>
> I create a tar archive , that contains the required folders and files ,
> convert it into c source using rtems-bin2c , ( a header file and a c source
> ) and link them with my project.
>
> In the init, I call
>
> sc = Untar_FromMemory((void *)TARFILE_START, (size_t)TARFILE_SIZE);
>
> where TARFILE_START is the macro with the name of the array , TARFILE_SIZE
> is the size of the array.
>
> But when I run the program, I get errors of the form
>
> "Untar: failed to create file /"
>

I have noticed and reported similar problem and workaround some
time ago. Problem is, that Untar_FromMemory() function fails
when it reaches a directory entry in a TAR file and given
directory already exists. It fails even for existing
top level directory which has to exists in RTEMS runing
system and are packed by TAR by default.

My fix is not ideal. Other (more generic option) is to use
stat(const char *path, struct stat *buf) with check
that target is already existing direcory. But using stat()
in really minimal application can lead to unneeded overhead.
Other option is to ignore directory create errors completelly
but I do not like something like that in RT system.

There is alternative way to untar file by other RTEMS functions
but we use Untar_FromMemory() in more projects. If there is no
objection or opinion for other solution, I prepare and check
patch with stat().


>From 4ce027b21cfde5bc6143d51d244345e05dd85cd4 Mon Sep 17 00:00:00 2001
Message-Id: 
<4ce027b21cfde5bc6143d51d244345e05dd85cd4.1436800331.git.pp...@pikron.com>
From: Pavel Pisa 
Date: Mon, 31 Mar 2014 00:57:12 +0200
Subject: [PATCH] untar: workaround for fail on top level directory existence.
To: rtems-de...@rtems.org

Signed-off-by: Pavel Pisa 
---
 cpukit/libmisc/untar/untar.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
index aed8fed..498fa12 100644
--- a/cpukit/libmisc/untar/untar.c
+++ b/cpukit/libmisc/untar/untar.c
@@ -203,6 +203,8 @@ Untar_FromMemory(
   }
 } else if (linkflag == DIRTYPE) {
   if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
+if ( !strcmp(fname, "/") || !strcmp(fname, "./"))
+  continue;
 printk("Untar: failed to create directory %s\n", fname);
 retval = UNTAR_FAIL;
 break;
-- 
1.9.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS STM32 BSP Development

[Gedare Bloom]

On Mon, Jul 6, 2015 at 1:00 PM, Isaac Gutekunst
 wrote:
> Hi RTEMS Developers,
>
> As mentioned in my previous email to rtems-users, we are looking to develop
> a BSP family for use with the STM32 family of processors. There is a lot of
> similarity among the silicon itself, and the Cube software distribution
> provides a common API.
>
> We are hoping to leverage this to make a BSP (or BSP family) to allow
> seamless migration between all processors in the family. We believe the
> easiest way to get there (and support most if not all STM32 processors) is
> to use the HAL provided by ST. Our BSP would be based on the work of
> Sebastian Huber and Embedded Brains, with some parts added and replaced to
> use the more generic STM32Cube HAL.
>
> The STM32Cube code is MISRA-C 2004 compliant, clean, mature, and well
> documented. However, we are not 100% sure about the acceptability of
> including it in RTEMS. We would really like to contribute this BSP back, so
> we want to get the licencing concerns out of the way ASAP.
>
> Here are our concerns:
>
> The STM32Cube zip download file contains a Release_Notes.html
>
> This page contains the text:
>
> Licensed under MCD-ST Liberty SW License Agreement V2, (the "License"); You
> may not use this package except in compliance with the License. You may
> obtain a copy of the License at:
>
>http://www.st.com/software_license_agreement_liberty_v2
>
> Unless required by applicable law or agreed to in writing, software
> distributed under the License is distributed on an "AS IS" BASIS,
> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
> the License for the specific language governing permissions and limitations
> under the License.
>
>
> However, the components we want appear to be BSD licenced. These are
> CMSIS
> STM32F4xx_HAL_Driver.
>
> The Licence and Release Notes in these sub-directories indicates that the
> components are BSD licenced (with an exception for a subset of CMSIS that's
> not BSD licenced).
>
> However, we are concerned that the top level licence "pollutes" the nested
> licences. In order to overcome that concern, we would prefer to see the BSD
> licenced code available as a separate download. However, since the download
> is obtainable without accepting an EULA, it might be OK.
>
>
> The specific paragraph in the MCD-ST Liberty SW License Agreement that
> concerns us the most is:
>
> "Licensed Software: means the enclosed SOFTWARE/FIRMWARE, EXAMPLES,
> PROJECT TEMPLATE and all the related documentation and design tools licensed
> and delivered in the form of object and/or source code as the case maybe. "
>
>
> When taken in conjunction with
>
> "Unless otherwise explicitly stated in this Agreement, You may not sell,
> assign, sublicense, lease, rent or otherwise distribute the Licensed
> Software for commercial purposes, in whole or in part..."
>
> Is concerning for RTEMS, because it may pollute the sub-licenced code. I
> feel the top level licence is overridden by the nested licences, and it was
> not STs intention to limit the use of the HAL code. I do believe they are
> protecting their rights with regards to the Middleware. The STM32_Audio code
> for example contains a nested duplication of the top level MCD-ST licence.
>
>
> What do you all think about these licencing concerns? Can some of these
> files) be accepted into the RTEMS tree?
>
It would be best to get a statement from the vendor that the licenses
within individual files over-ride the MCD-ST one.

I agree with your assessment in general. For example, if I download a
GPL3 package containing some files with only a permissive license
(e.g. BSD), I can pull out those files for re-use with the BSD
licensing. So, if the source code is downloadable without having to
agree to an EULA, I suspect the BSD license applies to these files,
rather than the MCD-ST one. But that is just my lay understanding.

Gedare

> I want to focus on the licensing concerns first, and when these are
> resolved, move onto other issues such as style, technical considerations,
> and the fun stuff: BSP architecture and development!
>
> --
> Isaac Gutekunst
> Embedded Systems Software Engineer
> isaac.guteku...@vecna.com
> www.vecna.com
> ___
> 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: Interrupt server on BBB

[Gedare Bloom]

Since you run the server task at priority 1, if it does not work
correctly then it can be causing a non-responsive system.

Do you reach the USB1HostIntHandler function? What does it do?

-Gedare

On Fri, Jul 10, 2015 at 5:33 PM, Martin Galvan
 wrote:
> Hi everyone! I'm currently trying to use an interrupt server task for
> handling USB interrupts on the Beaglebone Black. Here's the code I'm
> using:
>
> rtems_interrupt_server_initialize(1, 1500, RTEMS_TIMESLICE | RTEMS_PREEMPT,
> RTEMS_DEFAULT_ATTRIBUTES, NULL);
>
> rtems_interrupt_server_handler_install(NULL, AM335X_INT_USB1, "USB_interrupt",
> RTEMS_INTERRUPT_UNIQUE,
> reinterpret_cast(USB1HostIntHandler), NULL);
>
> I checked the return codes of both functions and it's always
> RTEMS_SUCCESSFUL. At the same time I have a separate thread which is
> constantly doing a printk for debugging purposes.
>
> Right now what happens is that the printk thread runs about 10-15
> times and then the system hangs in the middle of the print. Am I doing
> something wrong?
>
> Thanks a lot!
>
> --
>
> Martin Galvan
>
> Software Engineer
>
> Taller Technologies Argentina
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
> Phone: 54 351 4217888 / +54 351 4218211
> ___
> 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: arm atag retrieval problem

[Gedare Bloom]

On Sat, Jul 11, 2015 at 11:29 AM, QIAO YANG  wrote:
> Hi,
>
> I tried to retrieve atag command lines but I've got wired problems:
> I ran a quick scan for atags, start from 0x100, and I've got an output like
> :
>
> [ATAG_CORE] flags: 0, pagesize: 0, rootdev: 0
> [ATAG_MEM] size: 800, start: 0
> [ATAG_CMDLINE] found:
> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
> bcm2708.boardrev=0xf bcm2708.serial=0x8247b4bb smsc95xx.macaddr=B8s
> start addr:12C
>  size : 2E616D64
> didn't find [ATAG_NONE]
>
> which told me that:
> 1. The start address of atag cmdline is 0x12C
> 2. The size of this tag is 0x2E616D64
> The size of the tag is abnormal.
> From the output, it seems that I only retrieved part of the cmdline.
>
Perhaps you have messed up the field layout or somehow gotten the
wrong field offsets?

>
> I've also tried to use the mailbox interface to get the cmdline. what I've
> got is exactly the same part of string without error reponse. Even if I
> tried to print the following characters, they are all empty.
> I think that the atags area maybe rewritten in some way but I didn't managed
> to figure out. What bothers me most is the length of the tag, because the
> tag id is correct, part of the value is readable, there's no reason that the
> data between them is incorrect. The atag area should be written by
> videocore, who load the cmdline.txt where we can add additional lines.
>
>
> Besides I've also got a question that how can I get the value of r2 that
> passed by bootloader to kernel image? It should store the value of start
> address of ATAG or the magic of device tree. What I've found in linux is
> that there is a function like init( *param), which is called when loading
> the kernel, and the function get the value of r2 as the parameter passed to
> it.  I wonder how can I get this value, though by default the atag starts
> from 0x100.
>
Check in the BSP boot-up code (usually in the bsp subdirectory, start.S file).

>
> If it takes too long to implement the feature (atag, device tree ), I've
> got other ways to detect if a hdmi device is present and then disable/enable
> the graphic console. If I'm allowed to pass the atag/device tree
> implementation.
>
Can you clarify this statement? What "other ways" do you mean?

>
> Best wishes.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SMP support for Raspberry Pi 2

[Gedare Bloom]

Did you change configure, or configure.ac?

After you change configure.ac or Makefile.am files, you need to run
sb-bootstrap again.

On Sun, Jul 12, 2015 at 7:05 AM, Rohini Kulkarni  wrote:
> 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
>  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
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Code refactor: Changes to memory management initialization

[Gedare Bloom]

On Thu, Jul 9, 2015 at 9:53 AM,   wrote:
> From: Rohini Kulkarni 
>
> ---
>  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 
>  #include 
>  #include 
> +#include 
>
>  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 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +void raspberrypi_setup_mmu_and_cache(void)
This function should be in the start text section. Also, you could
make it static and put it into the bspstarthooks.c file.
> +{
> +  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;
Check for line length > 80 characters.

> +#endif
> +  domain_set = ARM_MMU_DEFAULT_CLIENT_DOMAIN;
> +
> +  bsp_memory_management_initialize(
> +bsp_initial_mmu_ctrl_set,
> +bsp_initial_mmu_ctrl_clear,
> +domain_set
Just pass ARM_MMU_DEFAULT_CLIENT_DOMAIN directly here.

> +  );
> +}
> \ 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 
>  #include 
>  #include 
> +#include 
>  #include 
>
> -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  );
Put the closing ); on a line by itself, like below.

> +
>arm_cp15_start_setup_translation_table_and_en

Re: [PATCH] libcsupport: Workaround for GCC 5.1 and later

[Gedare Bloom]

I'm fine with the build system hack to deal with this issue. Is there
a PR in gcc on this, and do we have a ticket to track it too?

Gedare

On Mon, Jul 13, 2015 at 10:37 AM, Joel Sherrill
 wrote:
> This is possible to do inside the file itself using function
> attributes or pragmas. I am not sure which method is best but
> wanted to pass along so we could decide as a group.
>
>> optimize
>> The optimize attribute is used to specify that a function is to be
>> compiled with different optimization options than specified on the command
>> line. Arguments can either be numbers or strings. Numbers are assumed to be
>> an optimization level. Strings that begin with O are assumed to be an
>> optimization option, while other options are assumed to be used with a -f
>> prefix. You can also use the ‘#pragma GCC optimize’ pragma to set the
>> optimization options that affect more than one function. See Function
>> Specific Option Pragmas, for details about the ‘#pragma GCC optimize’
>> pragma.
>> This can be used for instance to have frequently-executed functions
>> compiled with more aggressive optimization options that produce faster and
>> larger code, while other functions can be compiled with less aggressive
>> options.
>
>
>
> --joel
>
> On 7/13/2015 3:20 AM, Sebastian Huber wrote:
>>
>> Disable an optimization which would lead to a recursive calloc() call in
>> calloc().
>> ---
>>   cpukit/libcsupport/Makefile.am | 8 ++--
>>   cpukit/wrapup/Makefile.am  | 1 +
>>   2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/cpukit/libcsupport/Makefile.am
>> b/cpukit/libcsupport/Makefile.am
>> index 7474079..a5da5f1 100644
>> --- a/cpukit/libcsupport/Makefile.am
>> +++ b/cpukit/libcsupport/Makefile.am
>> @@ -1,8 +1,9 @@
>>   include $(top_srcdir)/automake/multilib.am
>>   include $(top_srcdir)/automake/compile.am
>>
>> -noinst_LIBRARIES = libcsupport.a
>> +noinst_LIBRARIES = libcsupport.a libcalloc.a
>>   libcsupport_a_CPPFLAGS = $(AM_CPPFLAGS)
>> +libcalloc_a_CPPFLAGS = $(AM_CPPFLAGS)
>>
>>   include_rtemsdir = $(includedir)/rtems
>>   include_rtems_HEADERS = include/console.h
>> @@ -79,7 +80,7 @@ ID_C_FILES = src/getegid.c src/geteuid.c src/getgid.c
>> src/getgroups.c \
>>   src/seteuid.c src/setgid.c src/setuid.c src/setegid.c src/setpgid.c
>> \
>>   src/setsid.c
>>
>> -MALLOC_C_FILES = src/malloc_initialize.c src/calloc.c src/malloc.c \
>> +MALLOC_C_FILES = src/malloc_initialize.c src/malloc.c \
>>   src/realloc.c src/_calloc_r.c src/_malloc_r.c \
>>   src/free.c src/_free_r.c \
>>   src/_realloc_r.c src/mallocfreespace.c \
>> @@ -138,6 +139,9 @@ libcsupport_a_SOURCES += $(LIBC_GLUE_C_FILES)
>> $(PASSWORD_GROUP_C_FILES) \
>>
>>   libcsupport_a_SOURCES += src/flockfile.c src/funlockfile.c
>> src/ftrylockfile.c
>>
>> +libcalloc_a_SOURCES = src/calloc.c
>> +libcalloc_a_CFLAGS = -fno-builtin
>> +
>>   EXTRA_DIST = src/TODO src/CASES src/README
>>
>>   include $(srcdir)/preinstall.am
>> diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am
>> index 53861df..5fd6e33 100644
>> --- a/cpukit/wrapup/Makefile.am
>> +++ b/cpukit/wrapup/Makefile.am
>> @@ -21,6 +21,7 @@ endif
>>
>>   TMP_LIBS += ../libcrypt/libcrypt.a
>>   TMP_LIBS += ../libcsupport/libcsupport.a
>> +TMP_LIBS += ../libcsupport/libcalloc.a
>>   TMP_LIBS += ../libblock/libblock.a
>>   if LIBDOSFS
>>   TMP_LIBS += ../libfs/libdosfs.a
>>
>
> --
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using tar to access files

[Gedare Bloom]

On Mon, Jul 13, 2015 at 11:26 AM, Pavel Pisa  wrote:
> Hello Sujay Raj,
>
>
> On Tuesday 30 of June 2015 06:39:28 Sujay Raj wrote:
>> I need to access configurations files the for web server I am porting to
>> rtems.
>>
>> I create a tar archive , that contains the required folders and files ,
>> convert it into c source using rtems-bin2c , ( a header file and a c source
>> ) and link them with my project.
>>
>> In the init, I call
>>
>> sc = Untar_FromMemory((void *)TARFILE_START, (size_t)TARFILE_SIZE);
>>
>> where TARFILE_START is the macro with the name of the array , TARFILE_SIZE
>> is the size of the array.
>>
>> But when I run the program, I get errors of the form
>>
>> "Untar: failed to create file /"
>>
>
> I have noticed and reported similar problem and workaround some
> time ago. Problem is, that Untar_FromMemory() function fails
> when it reaches a directory entry in a TAR file and given
> directory already exists. It fails even for existing
> top level directory which has to exists in RTEMS runing
> system and are packed by TAR by default.
>
> My fix is not ideal. Other (more generic option) is to use
> stat(const char *path, struct stat *buf) with check
> that target is already existing direcory. But using stat()
> in really minimal application can lead to unneeded overhead.
> Other option is to ignore directory create errors completelly
> but I do not like something like that in RT system.
>
> There is alternative way to untar file by other RTEMS functions
> but we use Untar_FromMemory() in more projects. If there is no
> objection or opinion for other solution, I prepare and check
> patch with stat().
>
>
> From 4ce027b21cfde5bc6143d51d244345e05dd85cd4 Mon Sep 17 00:00:00 2001
> Message-Id: 
> <4ce027b21cfde5bc6143d51d244345e05dd85cd4.1436800331.git.pp...@pikron.com>
> From: Pavel Pisa 
> Date: Mon, 31 Mar 2014 00:57:12 +0200
> Subject: [PATCH] untar: workaround for fail on top level directory existence.
> To: rtems-de...@rtems.org
>
> Signed-off-by: Pavel Pisa 
> ---
>  cpukit/libmisc/untar/untar.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
> index aed8fed..498fa12 100644
> --- a/cpukit/libmisc/untar/untar.c
> +++ b/cpukit/libmisc/untar/untar.c
> @@ -203,6 +203,8 @@ Untar_FromMemory(
>}
>  } else if (linkflag == DIRTYPE) {
>if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
> +if ( !strcmp(fname, "/") || !strcmp(fname, "./"))
> +  continue;
So this just proceeds if the top-level directly already exists? I
don't really have a problem with the patch if there is a test case
that shows the problem case, but I think the reported failure may be
elsewhere since Sujay said the error was "Untar: failed to create
file" and not "directory".

>  printk("Untar: failed to create directory %s\n", fname);
>  retval = UNTAR_FAIL;
>  break;
> --
> 1.9.1
> ___
> 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: arm atag retrieval problem

[桥 杨]

> 在 2015年7月13日，17:40，Gedare Bloom  写道：
> 
>> On Sat, Jul 11, 2015 at 11:29 AM, QIAO YANG  wrote:
>> Hi,
>> 
>> I tried to retrieve atag command lines but I've got wired problems:
>> I ran a quick scan for atags, start from 0x100, and I've got an output like
>> :
>> 
>> [ATAG_CORE] flags: 0, pagesize: 0, rootdev: 0
>> [ATAG_MEM] size: 800, start: 0
>> [ATAG_CMDLINE] found:
>> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
>> bcm2708.boardrev=0xf bcm2708.serial=0x8247b4bb smsc95xx.macaddr=B8s
>> start addr:12C
>> size : 2E616D64
>> didn't find [ATAG_NONE]
>> 
>> which told me that:
>> 1. The start address of atag cmdline is 0x12C
>> 2. The size of this tag is 0x2E616D64
>> The size of the tag is abnormal.
>> From the output, it seems that I only retrieved part of the cmdline.
> Perhaps you have messed up the field layout or somehow gotten the
> wrong field offsets?

I've verified that. 


> 
>> 
>> I've also tried to use the mailbox interface to get the cmdline. what I've
>> got is exactly the same part of string without error reponse. Even if I
>> tried to print the following characters, they are all empty.
>> I think that the atags area maybe rewritten in some way but I didn't managed
>> to figure out. What bothers me most is the length of the tag, because the
>> tag id is correct, part of the value is readable, there's no reason that the
>> data between them is incorrect. The atag area should be written by
>> videocore, who load the cmdline.txt where we can add additional lines.
>> 
>> 
>> Besides I've also got a question that how can I get the value of r2 that
>> passed by bootloader to kernel image? It should store the value of start
>> address of ATAG or the magic of device tree. What I've found in linux is
>> that there is a function like init( *param), which is called when loading
>> the kernel, and the function get the value of r2 as the parameter passed to
>> it.  I wonder how can I get this value, though by default the atag starts
>> from 0x100.
> Check in the BSP boot-up code (usually in the bsp subdirectory, start.S file).

I've found it. It use the default startup code. Is there a possibility that the 
default arm start.S messed up something?  This might also explain why it bugged 
when using uboot to load it?

> 
>> 
>> If it takes too long to implement the feature (atag, device tree ), I've
>> got other ways to detect if a hdmi device is present and then disable/enable
>> the graphic console. If I'm allowed to pass the atag/device tree
>> implementation.
> Can you clarify this statement? What "other ways" do you mean?
> 

If no display is connected , when we query the display size , vc will return 
656*416.  I'm not sure if it's acceptable to be used as a probe.


>> 
>> Best wishes.
>> 
>> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: arm atag retrieval problem

[Gedare Bloom]

On Mon, Jul 13, 2015 at 12:17 PM, 桥 杨  wrote:
>
>
>> 在 2015年7月13日，17:40，Gedare Bloom  写道：
>>
>>> On Sat, Jul 11, 2015 at 11:29 AM, QIAO YANG  wrote:
>>> Hi,
>>>
>>> I tried to retrieve atag command lines but I've got wired problems:
>>> I ran a quick scan for atags, start from 0x100, and I've got an output like
>>> :
>>>
>>> [ATAG_CORE] flags: 0, pagesize: 0, rootdev: 0
>>> [ATAG_MEM] size: 800, start: 0
>>> [ATAG_CMDLINE] found:
>>> dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416
>>> bcm2708.boardrev=0xf bcm2708.serial=0x8247b4bb smsc95xx.macaddr=B8s
>>> start addr:12C
>>> size : 2E616D64
>>> didn't find [ATAG_NONE]
>>>
>>> which told me that:
>>> 1. The start address of atag cmdline is 0x12C
>>> 2. The size of this tag is 0x2E616D64
>>> The size of the tag is abnormal.
>>> From the output, it seems that I only retrieved part of the cmdline.
>> Perhaps you have messed up the field layout or somehow gotten the
>> wrong field offsets?
>
> I've verified that.
>
>
>>
>>>
>>> I've also tried to use the mailbox interface to get the cmdline. what I've
>>> got is exactly the same part of string without error reponse. Even if I
>>> tried to print the following characters, they are all empty.
>>> I think that the atags area maybe rewritten in some way but I didn't managed
>>> to figure out. What bothers me most is the length of the tag, because the
>>> tag id is correct, part of the value is readable, there's no reason that the
>>> data between them is incorrect. The atag area should be written by
>>> videocore, who load the cmdline.txt where we can add additional lines.
>>>
>>>
>>> Besides I've also got a question that how can I get the value of r2 that
>>> passed by bootloader to kernel image? It should store the value of start
>>> address of ATAG or the magic of device tree. What I've found in linux is
>>> that there is a function like init( *param), which is called when loading
>>> the kernel, and the function get the value of r2 as the parameter passed to
>>> it.  I wonder how can I get this value, though by default the atag starts
>>> from 0x100.
>> Check in the BSP boot-up code (usually in the bsp subdirectory, start.S 
>> file).
>
> I've found it. It use the default startup code. Is there a possibility that 
> the default arm start.S messed up something?  This might also explain why it 
> bugged when using uboot to load it?
>
The default may not preserve the r2 register?

>>
>>>
>>> If it takes too long to implement the feature (atag, device tree ), I've
>>> got other ways to detect if a hdmi device is present and then disable/enable
>>> the graphic console. If I'm allowed to pass the atag/device tree
>>> implementation.
>> Can you clarify this statement? What "other ways" do you mean?
>>
>
> If no display is connected , when we query the display size , vc will return 
> 656*416.  I'm not sure if it's acceptable to be used as a probe.
>
If the return value without a display is a constant value, then this
should be ok to use temporarily at least. But you should continue to
work on getting the atag/dt working correctly, while you can work on
other parts of your project in parallel (Porting the graphics toolkit
to RSB).

>
>>>
>>> Best wishes.
>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libcsupport: Workaround for GCC 5.1 and later

[Sebastian Huber]

Yes, this option sounded like the right way to fix it, but...

https://gcc.gnu.org/ml/gcc-help/2015-03/msg00093.html
https://gcc.gnu.org/ml/gcc-help/2015-03/msg00094.html

- Joel Sherrill  schrieb:
> This is possible to do inside the file itself using function
> attributes or pragmas. I am not sure which method is best but
> wanted to pass along so we could decide as a group.
> 
> > optimize
> > The optimize attribute is used to specify that a function is to be compiled 
> > with different optimization options than specified on the command line. 
> > Arguments can either be numbers or strings. Numbers are assumed to be an 
> > optimization level. Strings that begin with O are assumed to be an 
> > optimization option, while other options are assumed to be used with a -f 
> > prefix. You can also use the ‘#pragma GCC optimize’ pragma to set the 
> > optimization options that affect more than one function. See Function 
> > Specific Option Pragmas, for details about the ‘#pragma GCC optimize’ 
> > pragma.
> > This can be used for instance to have frequently-executed functions 
> > compiled with more aggressive optimization options that produce faster and 
> > larger code, while other functions can be compiled with less aggressive 
> > options.
> 
> 
> --joel
> 
> On 7/13/2015 3:20 AM, Sebastian Huber wrote:
> > Disable an optimization which would lead to a recursive calloc() call in
> > calloc().
> > ---
> >   cpukit/libcsupport/Makefile.am | 8 ++--
> >   cpukit/wrapup/Makefile.am  | 1 +
> >   2 files changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
> > index 7474079..a5da5f1 100644
> > --- a/cpukit/libcsupport/Makefile.am
> > +++ b/cpukit/libcsupport/Makefile.am
> > @@ -1,8 +1,9 @@
> >   include $(top_srcdir)/automake/multilib.am
> >   include $(top_srcdir)/automake/compile.am
> >
> > -noinst_LIBRARIES = libcsupport.a
> > +noinst_LIBRARIES = libcsupport.a libcalloc.a
> >   libcsupport_a_CPPFLAGS = $(AM_CPPFLAGS)
> > +libcalloc_a_CPPFLAGS = $(AM_CPPFLAGS)
> >
> >   include_rtemsdir = $(includedir)/rtems
> >   include_rtems_HEADERS = include/console.h
> > @@ -79,7 +80,7 @@ ID_C_FILES = src/getegid.c src/geteuid.c src/getgid.c 
> > src/getgroups.c \
> >   src/seteuid.c src/setgid.c src/setuid.c src/setegid.c src/setpgid.c \
> >   src/setsid.c
> >
> > -MALLOC_C_FILES = src/malloc_initialize.c src/calloc.c src/malloc.c \
> > +MALLOC_C_FILES = src/malloc_initialize.c src/malloc.c \
> >   src/realloc.c src/_calloc_r.c src/_malloc_r.c \
> >   src/free.c src/_free_r.c \
> >   src/_realloc_r.c src/mallocfreespace.c \
> > @@ -138,6 +139,9 @@ libcsupport_a_SOURCES += $(LIBC_GLUE_C_FILES) 
> > $(PASSWORD_GROUP_C_FILES) \
> >
> >   libcsupport_a_SOURCES += src/flockfile.c src/funlockfile.c 
> > src/ftrylockfile.c
> >
> > +libcalloc_a_SOURCES = src/calloc.c
> > +libcalloc_a_CFLAGS = -fno-builtin
> > +
> >   EXTRA_DIST = src/TODO src/CASES src/README
> >
> >   include $(srcdir)/preinstall.am
> > diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am
> > index 53861df..5fd6e33 100644
> > --- a/cpukit/wrapup/Makefile.am
> > +++ b/cpukit/wrapup/Makefile.am
> > @@ -21,6 +21,7 @@ endif
> >
> >   TMP_LIBS += ../libcrypt/libcrypt.a
> >   TMP_LIBS += ../libcsupport/libcsupport.a
> > +TMP_LIBS += ../libcsupport/libcalloc.a
> >   TMP_LIBS += ../libblock/libblock.a
> >   if LIBDOSFS
> >   TMP_LIBS += ../libfs/libdosfs.a
> >
> 
> -- 
> 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

-- 
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
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] libcsupport: Workaround for GCC 5.1 and later

[Joel Sherrill]

On 7/13/2015 1:06 PM, Sebastian Huber wrote:

Yes, this option sounded like the right way to fix it, but...

https://gcc.gnu.org/ml/gcc-help/2015-03/msg00093.html
https://gcc.gnu.org/ml/gcc-help/2015-03/msg00094.html


Ouch! That is a big red flashing sign which says stay away!

And to Gedare's point of raising this as a PR, it is just
an optimization side-effect more than bug.

I wonder if this could impact any code in newlib? It should
have the same issue with the default calloc(). And maybe
some other routines like the string and mem* ones?


- Joel Sherrill  schrieb:

This is possible to do inside the file itself using function
attributes or pragmas. I am not sure which method is best but
wanted to pass along so we could decide as a group.


optimize
The optimize attribute is used to specify that a function is to be compiled 
with different optimization options than specified on the command line. 
Arguments can either be numbers or strings. Numbers are assumed to be an 
optimization level. Strings that begin with O are assumed to be an optimization 
option, while other options are assumed to be used with a -f prefix. You can 
also use the ‘#pragma GCC optimize’ pragma to set the optimization options that 
affect more than one function. See Function Specific Option Pragmas, for 
details about the ‘#pragma GCC optimize’ pragma.
This can be used for instance to have frequently-executed functions compiled 
with more aggressive optimization options that produce faster and larger code, 
while other functions can be compiled with less aggressive options.



--joel  

On 7/13/2015 3:20 AM, Sebastian Huber wrote:

Disable an optimization which would lead to a recursive calloc() call in
calloc().
---
   cpukit/libcsupport/Makefile.am | 8 ++--
   cpukit/wrapup/Makefile.am  | 1 +
   2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/cpukit/libcsupport/Makefile.am b/cpukit/libcsupport/Makefile.am
index 7474079..a5da5f1 100644
--- a/cpukit/libcsupport/Makefile.am
+++ b/cpukit/libcsupport/Makefile.am
@@ -1,8 +1,9 @@
   include $(top_srcdir)/automake/multilib.am
   include $(top_srcdir)/automake/compile.am

-noinst_LIBRARIES = libcsupport.a
+noinst_LIBRARIES = libcsupport.a libcalloc.a
   libcsupport_a_CPPFLAGS = $(AM_CPPFLAGS)
+libcalloc_a_CPPFLAGS = $(AM_CPPFLAGS)

   include_rtemsdir = $(includedir)/rtems
   include_rtems_HEADERS = include/console.h
@@ -79,7 +80,7 @@ ID_C_FILES = src/getegid.c src/geteuid.c src/getgid.c 
src/getgroups.c \
   src/seteuid.c src/setgid.c src/setuid.c src/setegid.c src/setpgid.c \
   src/setsid.c

-MALLOC_C_FILES = src/malloc_initialize.c src/calloc.c src/malloc.c \
+MALLOC_C_FILES = src/malloc_initialize.c src/malloc.c \
   src/realloc.c src/_calloc_r.c src/_malloc_r.c \
   src/free.c src/_free_r.c \
   src/_realloc_r.c src/mallocfreespace.c \
@@ -138,6 +139,9 @@ libcsupport_a_SOURCES += $(LIBC_GLUE_C_FILES) 
$(PASSWORD_GROUP_C_FILES) \

   libcsupport_a_SOURCES += src/flockfile.c src/funlockfile.c src/ftrylockfile.c

+libcalloc_a_SOURCES = src/calloc.c
+libcalloc_a_CFLAGS = -fno-builtin
+
   EXTRA_DIST = src/TODO src/CASES src/README

   include $(srcdir)/preinstall.am
diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am
index 53861df..5fd6e33 100644
--- a/cpukit/wrapup/Makefile.am
+++ b/cpukit/wrapup/Makefile.am
@@ -21,6 +21,7 @@ endif

   TMP_LIBS += ../libcrypt/libcrypt.a
   TMP_LIBS += ../libcsupport/libcsupport.a
+TMP_LIBS += ../libcsupport/libcalloc.a
   TMP_LIBS += ../libblock/libblock.a
   if LIBDOSFS
   TMP_LIBS += ../libfs/libdosfs.a



--
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




--
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: SMP support for Raspberry Pi 2

[Rohini Kulkarni]

I did change the configure file to add support for --enable-smp option.

Ok, I suppose that is the problem.
What is the sb option for?
On 13 Jul 2015 21:13, "Gedare Bloom"  wrote:

> Did you change configure, or configure.ac?
>
> After you change configure.ac or Makefile.am files, you need to run
> sb-bootstrap again.
>
> On Sun, Jul 12, 2015 at 7:05 AM, Rohini Kulkarni 
> wrote:
> > 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
> >  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
> >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SMP support for Raspberry Pi 2

[Joel Sherrill]

On 7/13/2015 1:24 PM, Rohini Kulkarni wrote:

I did change the configure file to add support for --enable-smp option.

Ok, I suppose that is the problem.


You need to edit the configure.ac and then bootstrap again. Look at
sparc/leon3, powerpc/qoriq, or i386/pc386 for examples.

You need to configure with --enable-smp and make sure the cpuopts.h
has this. It will be a configure in a clean directory. I am pretty
sure it will be set even when the BSP doesn't really support SMP.


What is the sb option for?


He was referring to the "sb-bootstrap" program in 
rtems-source-builder/source-builder.
You can also just run the bootstrap found in the top of the rtems tree in the
raspberrypi directory. sb-bootstrap parallelizes the process but if you only do
one directory, that doesn't matter.


On 13 Jul 2015 21:13, "Gedare Bloom" mailto:ged...@gwu.edu>> 
wrote:

Did you change configure, or configure.ac ?

After you change configure.ac  or Makefile.am files, 
you need to run
sb-bootstrap again.

On Sun, Jul 12, 2015 at 7:05 AM, Rohini Kulkarni mailto:krohini1...@gmail.com>> wrote:
 > 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
 > mailto: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 

 >> 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



--
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: Interrupt server on BBB

[Martin Galvan]

Actually, it seems like the issue is what Ragunath described here:

https://lists.rtems.org/pipermail/devel/2015-May/011419.html

It looks like the Beagle bsp_interrupt_dispatch function isn't
designed to work with the interrupt server task. From what I saw, this
is the only board where bsp_interrupt_dispatch actually enables the
interrupt vectors.

So far we've been able to solve this by hacking around with mutexes.
However, in the above thread Sebastian suggested that we may need to
disable nested interrupts altogether. I'll investigate a bit further
to see if we could instead just remove the interrupt vector
disabling/enabling from bsp_interrupt_dispatch.

On Mon, Jul 13, 2015 at 12:37 PM, Gedare Bloom  wrote:
> Since you run the server task at priority 1, if it does not work
> correctly then it can be causing a non-responsive system.
>
> Do you reach the USB1HostIntHandler function? What does it do?
>
> -Gedare
>
> On Fri, Jul 10, 2015 at 5:33 PM, Martin Galvan
>  wrote:
>> Hi everyone! I'm currently trying to use an interrupt server task for
>> handling USB interrupts on the Beaglebone Black. Here's the code I'm
>> using:
>>
>> rtems_interrupt_server_initialize(1, 1500, RTEMS_TIMESLICE | RTEMS_PREEMPT,
>> RTEMS_DEFAULT_ATTRIBUTES, NULL);
>>
>> rtems_interrupt_server_handler_install(NULL, AM335X_INT_USB1, 
>> "USB_interrupt",
>> RTEMS_INTERRUPT_UNIQUE,
>> reinterpret_cast(USB1HostIntHandler), NULL);
>>
>> I checked the return codes of both functions and it's always
>> RTEMS_SUCCESSFUL. At the same time I have a separate thread which is
>> constantly doing a printk for debugging purposes.
>>
>> Right now what happens is that the printk thread runs about 10-15
>> times and then the system hangs in the middle of the print. Am I doing
>> something wrong?
>>
>> Thanks a lot!
>>
>> --
>>
>> Martin Galvan
>>
>> Software Engineer
>>
>> Taller Technologies Argentina
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>> Phone: 54 351 4217888 / +54 351 4218211
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel



-- 


Martin Galvan

Software Engineer

Taller Technologies Argentina


San Lorenzo 47, 3rd Floor, Office 5

Córdoba, Argentina

Phone: 54 351 4217888 / +54 351 4218211
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] libcsupport: Workaround for GCC 5.1 and later

[Chris Johns]

On 14/07/2015 4:20 am, Joel Sherrill wrote:
> 
> 
> On 7/13/2015 1:06 PM, Sebastian Huber wrote:
>> Yes, this option sounded like the right way to fix it, but...
>>
>> https://gcc.gnu.org/ml/gcc-help/2015-03/msg00093.html
>> https://gcc.gnu.org/ml/gcc-help/2015-03/msg00094.html
> 
> Ouch! That is a big red flashing sign which says stay away!
> 
> And to Gedare's point of raising this as a PR, it is just
> an optimization side-effect more than bug.
> 
> I wonder if this could impact any code in newlib? It should
> have the same issue with the default calloc(). And maybe
> some other routines like the string and mem* ones?
> 

For the record can someone please explain why 'calloc' broke with gcc 5
on ARM in the first place ?

What is the code construct in that specific function [1] that is causing
the issue in the first place ? It seems a common type of idiom and I am
sure it must exist in user code.

Chris

[1] https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/calloc.c
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Using tar to access files

[Chris Johns]

On 14/07/2015 1:57 am, Gedare Bloom wrote:
> On Mon, Jul 13, 2015 at 11:26 AM, Pavel Pisa  wrote:
>> Hello Sujay Raj,
>>
>>
>> On Tuesday 30 of June 2015 06:39:28 Sujay Raj wrote:
>>> I need to access configurations files the for web server I am porting to
>>> rtems.
>>>
>>> I create a tar archive , that contains the required folders and files ,
>>> convert it into c source using rtems-bin2c , ( a header file and a c source
>>> ) and link them with my project.
>>>
>>> In the init, I call
>>>
>>> sc = Untar_FromMemory((void *)TARFILE_START, (size_t)TARFILE_SIZE);
>>>
>>> where TARFILE_START is the macro with the name of the array , TARFILE_SIZE
>>> is the size of the array.
>>>
>>> But when I run the program, I get errors of the form
>>>
>>> "Untar: failed to create file /"
>>>
>>
>> I have noticed and reported similar problem and workaround some
>> time ago. Problem is, that Untar_FromMemory() function fails
>> when it reaches a directory entry in a TAR file and given
>> directory already exists. It fails even for existing
>> top level directory which has to exists in RTEMS runing
>> system and are packed by TAR by default.
>>
>> My fix is not ideal. Other (more generic option) is to use
>> stat(const char *path, struct stat *buf) with check
>> that target is already existing direcory. But using stat()
>> in really minimal application can lead to unneeded overhead.
>> Other option is to ignore directory create errors completelly
>> but I do not like something like that in RT system.
>>
>> There is alternative way to untar file by other RTEMS functions
>> but we use Untar_FromMemory() in more projects. If there is no
>> objection or opinion for other solution, I prepare and check
>> patch with stat().
>>
>>
>> From 4ce027b21cfde5bc6143d51d244345e05dd85cd4 Mon Sep 17 00:00:00 2001
>> Message-Id: 
>> <4ce027b21cfde5bc6143d51d244345e05dd85cd4.1436800331.git.pp...@pikron.com>
>> From: Pavel Pisa 
>> Date: Mon, 31 Mar 2014 00:57:12 +0200
>> Subject: [PATCH] untar: workaround for fail on top level directory existence.
>> To: rtems-de...@rtems.org
>>
>> Signed-off-by: Pavel Pisa 
>> ---
>>  cpukit/libmisc/untar/untar.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/cpukit/libmisc/untar/untar.c b/cpukit/libmisc/untar/untar.c
>> index aed8fed..498fa12 100644
>> --- a/cpukit/libmisc/untar/untar.c
>> +++ b/cpukit/libmisc/untar/untar.c
>> @@ -203,6 +203,8 @@ Untar_FromMemory(
>>}
>>  } else if (linkflag == DIRTYPE) {
>>if ( mkdir(fname, S_IRWXU | S_IRWXG | S_IRWXO) != 0 ) {
>> +if ( !strcmp(fname, "/") || !strcmp(fname, "./"))
>> +  continue;
> So this just proceeds if the top-level directly already exists? I
> don't really have a problem with the patch if there is a test case
> that shows the problem case, but I think the reported failure may be
> elsewhere since Sujay said the error was "Untar: failed to create
> file" and not "directory".

Is this related to https://devel.rtems.org/ticket/2207 ?

Chris

> 
>>  printk("Untar: failed to create directory %s\n", fname);
>>  retval = UNTAR_FAIL;
>>  break;
>> --
>> 1.9.1
>> ___
>> 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