Re: [rpi bsp] configure fb section in mmu table and improvement for mailbox

[Sebastian Huber]

On 28/07/15 02:31, Pavel Pisa wrote:

>I think it's much closer to what we expected. you may checkout my github
>and my dropbox. 
>https://github.com/yangqiao/rtems/tree/framebuffer
>https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl=0
>
>The commits log is messy, I'll rebase it afterward until we think it's
>acceptable.

I think that Sebastian, Joel or some other core developer opinion
would be nice there.


I don't have time to check out external repositories. I will only look 
at information included in e-mails posted to the devel list.


I am not sure why you need additional sections in the MMU table for the 
frame buffer. In case it needs non-cachable memory, why don't you put it 
into the .bsp_nocache section?  You can also use a heap for this 
section, see rtems_cache_coherent_allocate().


--
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: [rpi bsp] configure fb section in mmu table and improvement for mailbox

[Pavel Pisa]

Hello Sebastian,

On Wednesday 29 of July 2015 09:06:47 Sebastian Huber wrote:
> On 28/07/15 02:31, Pavel Pisa wrote:
> >> >I think it's much closer to what we expected. you may checkout my
> >> > github and my dropbox. 
> >> >https://github.com/yangqiao/rtems/tree/framebuffer
> >> >https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl
> >> >=0
> >> >
> >> >The commits log is messy, I'll rebase it afterward until we think it's
> >> >acceptable.
> >
> > I think that Sebastian, Joel or some other core developer opinion
> > would be nice there.
>
> I don't have time to check out external repositories. I will only look
> at information included in e-mails posted to the devel list.
>
> I am not sure why you need additional sections in the MMU table for the
> frame buffer. In case it needs non-cachable memory, why don't you put it
> into the .bsp_nocache section?  You can also use a heap for this
> section, see rtems_cache_coherent_allocate().

I am not sure, if there is alternative way with .bsp_nocache section
and some request to reconfigure VideoCore memory placement/division.

Actual/standard way how RPi is used/setup is different.
The VideoCore detect/have specified actual amount of physical
memory then it reads "config.txt" file and reserves end
of memory for framebuffer and internal use. Operating system
has to adapt to that division.

So if RTEMS is intended to run on all RPi 1 boards with at least
two possible different amount of physical memory populated
and do not clash with user setup configs and some sizes
adjustment based (may be) even on VideoCore firmware version/binaries
then it needs to adapt to actual memory amount. Other option is
to use minimum for RTEMS application (i.e. 128 MB) and define rest
to 1 GB as noncacheable, but that is far from beeing ideal.

On the other hand, from my reading of CP15 setup the regions
size adaptation is not big problem. The end of heap/wokspace
should be adjusted as well. I have not looked into that,
but it should not be a problem/is resolved for other archs.

As for the code review, I understand you that inline patches
in email (until some size) are the best and that time is
great enemy. If you have some suggestion then I try
to guide Qiao Yang that direction.

To Qiao Yang, please, try to setup e-mail software/client
to send plain e-mails in the plain text format
and check that it does not clobber spaces, tabs and break
lines. The application of the patches in the case
of HTML formating is a problem. Your client sends text
version as well so it is not so critical and that can be used,
not sure about line wraps. But plain text would be better
for review.

Best wishes,

 Pavel


PS: I do not be available from August 7 to August 23.


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

Re: SMP support for Raspberry Pi 2

[Rohini Kulkarni]

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

[Sebastian Huber]

On 29/07/15 11:52, Rohini Kulkarni wrote:



On Tue, Jul 28, 2015 at 12:24 PM, Sebastian Huber 
> 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: [rpi bsp] configure fb section in mmu table and improvement for mailbox

[Sebastian Huber]

On 29/07/15 10:17, Pavel Pisa wrote:

Hello Sebastian,

On Wednesday 29 of July 2015 09:06:47 Sebastian Huber wrote:

On 28/07/15 02:31, Pavel Pisa wrote:

I think it's much closer to what we expected. you may checkout my
github and my dropbox. 
https://github.com/yangqiao/rtems/tree/framebuffer
https://www.dropbox.com/sh/95bu6skofkmrlvc/AABXjwvvFhQScJdo_rwj12V6a?dl
=0

The commits log is messy, I'll rebase it afterward until we think it's
acceptable.

I think that Sebastian, Joel or some other core developer opinion
would be nice there.

I don't have time to check out external repositories. I will only look
at information included in e-mails posted to the devel list.

I am not sure why you need additional sections in the MMU table for the
frame buffer. In case it needs non-cachable memory, why don't you put it
into the .bsp_nocache section?  You can also use a heap for this
section, see rtems_cache_coherent_allocate().

I am not sure, if there is alternative way with .bsp_nocache section
and some request to reconfigure VideoCore memory placement/division.

Actual/standard way how RPi is used/setup is different.
The VideoCore detect/have specified actual amount of physical
memory then it reads "config.txt" file and reserves end
of memory for framebuffer and internal use. Operating system
has to adapt to that division.

So if RTEMS is intended to run on all RPi 1 boards with at least
two possible different amount of physical memory populated
and do not clash with user setup configs and some sizes
adjustment based (may be) even on VideoCore firmware version/binaries
then it needs to adapt to actual memory amount. Other option is
to use minimum for RTEMS application (i.e. 128 MB) and define rest
to 1 GB as noncacheable, but that is far from beeing ideal.


So the memory layout is mostly unknown at link-time? In this case a 
writeable MMU configuration table is indeed an option.


A custom workspace initialization can be done via 
bsp_work_area_initialize().


--
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] [RTEMS] Move header files

[Joel Sherrill]

This patch does not apply for me.

Applying: Move header files
/home/joel/test-gcc/newlib-cygwin/.git/rebase-apply/patch:91: new blank line at 
EOF.
+
error: patch failed: newlib/libc/sys/rtems/machine/param.h:1
error: newlib/libc/sys/rtems/machine/param.h: patch does not apply
error: patch failed: newlib/libc/sys/rtems/sys/dirent.h:1
error: newlib/libc/sys/rtems/sys/dirent.h: patch does not apply
error: patch failed: newlib/libc/sys/rtems/sys/param.h:1
error: newlib/libc/sys/rtems/sys/param.h: patch does not apply
error: patch failed: newlib/libc/sys/rtems/sys/syslimits.h:1
error: newlib/libc/sys/rtems/sys/syslimits.h: patch does not apply
Patch failed at 0001 Move header files
The copy of the patch that failed is found in:
   /home/joel/test-gcc/newlib-cygwin/.git/rebase-apply/patch
When you have resolved this problem, run "git am --resolved".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

On 7/27/2015 4:31 AM, Sebastian Huber wrote:

During libgcc build the first include search path for <...> is
"../newlib/libc/sys/rtems/include".  Move all RTEMS specific header
files to "libc/sys/rtems/include" so that they can be found.  Later
during libc build the header files in the previous location were somehow
present, but for libgcc build they were invisible.  This change is
necessary to use  for the GCC thread model implementation.

newlib/ChangeLog
2015-07-27  Sebastian Huber  

 libc/sys/rtems/machine/_types.h: Move to ...
 libc/sys/rtems/include/machine/_types.h: ... here.
 libc/sys/rtems/machine/limits.h: Move to ...
 libc/sys/rtems/include/machine/limits.h: ... here.
 libc/sys/rtems/machine/param.h: Move to ...
 libc/sys/rtems/include/machine/param.h: ... here.
 libc/sys/rtems/sys/cpuset.h: Move to ...
 libc/sys/rtems/include/sys/cpuset.h: ... here.
 libc/sys/rtems/sys/dirent.h: Move to ...
 libc/sys/rtems/include/sys/dirent.h: ... here.
 libc/sys/rtems/sys/param.h: Move to ...
 libc/sys/rtems/include/sys/param.h: ... here.
 libc/sys/rtems/sys/syslimits.h: Move to ...
 libc/sys/rtems/include/sys/syslimits.h: ... here.
 libc/sys/rtems/sys/utime.h: Move to ...
 libc/sys/rtems/include/sys/utime.h: ... here.
---
  newlib/libc/sys/rtems/include/machine/_types.h |  38 +++
  newlib/libc/sys/rtems/include/machine/limits.h |   6 +
  newlib/libc/sys/rtems/include/machine/param.h  | 101 
  newlib/libc/sys/rtems/include/sys/cpuset.h | 311 +
  newlib/libc/sys/rtems/include/sys/dirent.h |  64 +
  newlib/libc/sys/rtems/include/sys/param.h  | 217 +
  newlib/libc/sys/rtems/include/sys/syslimits.h  |  64 +
  newlib/libc/sys/rtems/include/sys/utime.h  |  34 +++
  newlib/libc/sys/rtems/machine/_types.h |  38 ---
  newlib/libc/sys/rtems/machine/limits.h |   6 -
  newlib/libc/sys/rtems/machine/param.h  | 101 
  newlib/libc/sys/rtems/sys/cpuset.h | 311 -
  newlib/libc/sys/rtems/sys/dirent.h |  64 -
  newlib/libc/sys/rtems/sys/param.h  | 217 -
  newlib/libc/sys/rtems/sys/syslimits.h  |  64 -
  newlib/libc/sys/rtems/sys/utime.h  |  34 ---
  16 files changed, 835 insertions(+), 835 deletions(-)
  create mode 100644 newlib/libc/sys/rtems/include/machine/_types.h
  create mode 100644 newlib/libc/sys/rtems/include/machine/limits.h
  create mode 100644 newlib/libc/sys/rtems/include/machine/param.h
  create mode 100644 newlib/libc/sys/rtems/include/sys/cpuset.h
  create mode 100644 newlib/libc/sys/rtems/include/sys/dirent.h
  create mode 100644 newlib/libc/sys/rtems/include/sys/param.h
  create mode 100644 newlib/libc/sys/rtems/include/sys/syslimits.h
  create mode 100644 newlib/libc/sys/rtems/include/sys/utime.h
  delete mode 100644 newlib/libc/sys/rtems/machine/_types.h
  delete mode 100644 newlib/libc/sys/rtems/machine/limits.h
  delete mode 100644 newlib/libc/sys/rtems/machine/param.h
  delete mode 100644 newlib/libc/sys/rtems/sys/cpuset.h
  delete mode 100644 newlib/libc/sys/rtems/sys/dirent.h
  delete mode 100644 newlib/libc/sys/rtems/sys/param.h
  delete mode 100644 newlib/libc/sys/rtems/sys/syslimits.h
  delete mode 100644 newlib/libc/sys/rtems/sys/utime.h

diff --git a/newlib/libc/sys/rtems/include/machine/_types.h 
b/newlib/libc/sys/rtems/include/machine/_types.h
new file mode 100644
index 000..1711c7a
--- /dev/null
+++ b/newlib/libc/sys/rtems/include/machine/_types.h
@@ -0,0 +1,38 @@
+/*
+ *  $Id$
+ */
+
+#ifndef _MACHINE__TYPES_H
+#define _MACHINE__TYPES_H
+
+/* This disables some conflicting type definitions in  */
+#define _HAVE_SYSTYPES
+
+#include 
+
+typedef __int32_t blksize_t;
+typedef __int32_t blkcnt_t;
+
+typedef __uint64_t __dev_t;
+#define __dev_t_defined 1
+
+#if defined(__arm__) || define

Re: [rpi bsp] add cmdline options

[Pavel Pisa]

Hello Qiao Yang,

On Tuesday 28 of July 2015 01:35:45 Pavel Pisa wrote:
> Hello Qiao Yang,
>
> On Friday 24 of July 2015 18:04:47 QIAO YANG wrote:
> > Some updates for you. I've found out that my previous problem with
> > cmdline due to my minicom didn't wrap up the lines I've chosen the
> > interface of vc to retrieve cmdline so that we don't need to parse the
> > atag nor devicetree. Now we can use --video=...  to choose resolution and
> > --console=... to choose console.

I have got to little more testing. Ticker runs correctly
with console on serial port and even with graphics console.
But option --console=fbcons works only if it is the last option
on the line in cmdline.txt. Problem is in the comparison because
if there are more options then string provided by rpi_cmdline_arg()
continues after "fbcons" by blank character. I think that
copy of the string to the user provided buffer is not necessary
in rpi_cmdline_arg(). It would bring up issues with space enough
to fit data etc. I have use simple strncmp to resolve issue.
But something more elegant can be provided.

diff --git a/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c 
b/c/src/lib/libbsp/arm/raspberrypi
index 74cf78e..ad24d33 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/console/console_select.c
@@ -91,7 +91,7 @@ void bsp_console_select(void)
if (opt)
   {
   opt += sizeof("--console=")-1;
-  if (strcmp(opt,"fbcons") == 0)
+  if (strncmp(opt,"fbcons", sizeof("fbcons"-1)) == 0)
   {
 Console_Port_Minor = BSP_CONSOLE_FB;
 BSPPrintkPort  = BSP_CONSOLE_FB;
@@ -99,8 +99,8 @@ void bsp_console_select(void)
   }
   else
   {
-Console_Port_Minor = BSP_CONSOLE_FB;
-BSPPrintkPort  = BSP_CONSOLE_FB;
+Console_Port_Minor = BSP_CONSOLE_UART0;
+BSPPrintkPort  = BSP_CONSOLE_UART0;
   }

   /*

> As for the interface to command line through VC, I expect that
> this interface allows access only to value set in config.txt
> but it is not changed by U-boot if used. If that is true
> then use of ATAG or device tree would be better for flexibility.
> It would be reusable on other ARM targets as well.
> But that this can be tried in some follow up project.

It seems to me that behavior is as expected, VideoCore
returns what it parsed from cmdline.txt but arguments
set by U-boot are different. So long term term solution
is to implement shared ARM BSP atags and devicetree parser.
It can be minimal for start only to locate kernel command
line. It would help to other ARM BSPs in general.

MMU setup seems to be OK for me, but what I really
dislike is duplicate of arm-cp15-start.h to RPi.
Shared one should be used.

Les problem is to use different name for
arm_cp15_start_mmu_config_table to not clash
with the definition in header.

I think that the name arm_cp15_start_mmu_config_table
is not part of RTEMS API so it can be changed freely
and if original arm_cp15_start_mmu_config_table
is not defined then incorrect use is catch
easily.

Please, try to resolve this first. Then the suggested
change for strncmp and do more testing.

I suggest to adapt rpi_init_cmdline() a little.

void rpi_init_cmdline(void)
{
  bcm2835_get_cmdline_entries get_cmdline_entries;
  bcm2835_mailbox_get_cmdline(&get_cmdline_entries);
  int i; /*I suggest to be C89 compatible, do not
   mix declaration with code in single block */
  for (i = 0; i < MAX_CMDLINE_LENGTH; ++i)
  {
_rpi_cmdline[i] = get_cmdline_entries.cmdline[i];
  }
}

It is not necessary to place 512 bytes onto stack.
If you declare get_cmdline_entries static global

static bcm2835_get_cmdline_entries get_cmdline_entries;

Then you can read the line to this global.

If you declare then _rpi_cmdline as

char *_rpi_cmdline;

you only point it into right place and do not need
copy. You should add code, which ensures that command
line is zero terminated if you use strstr() later.

You can use something like


  bcm2835_mailbox_get_cmdline(&get_cmdline_entries);
  get_cmdline_entries.cmdline[sizeof(get_cmdline_entries.cmdline) - 1] = 0;

Generally code division to the functions
and files looks good.

Best wishes, 

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

Re: [rpi bsp] add cmdline options

[Gedare Bloom]

> MMU setup seems to be OK for me, but what I really
> dislike is duplicate of arm-cp15-start.h to RPi.
> Shared one should be used.
>
Yes if possible.

> Les problem is to use different name for
> arm_cp15_start_mmu_config_table to not clash
> with the definition in header.
>
> I think that the name arm_cp15_start_mmu_config_table
> is not part of RTEMS API so it can be changed freely
> and if original arm_cp15_start_mmu_config_table
> is not defined then incorrect use is catch
> easily.
>

Usually a BSP will define something like, raspberrypi_start_mmu_config_table.

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

Re: [PATCH] [RTEMS] Move header files

[Sebastian Huber]

Hello Joel,

maybe this is a problem with the e-mail client.  I attached it as a TAR archive.

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

0001-Move-header-files.tar.gz
Description: application/compressed-tar
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMSIS?

[Daniel Gutson]

Hi guys,

   I just got a student who likes this project and wants to provide a
CMSIS API to RTEMS as her career final project.
I will be her director.
Besides telling her to read stuff, documentation, and the github
source files, any initial advice about how to implement this
on top of RTEMS? I.e. an external library with RSB support?

  Daniel.

On Wed, Sep 3, 2014 at 11:36 AM, Joel Sherrill
 wrote:
> I hate to reply to my own post but need to in this case.
>
> https://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/
>
> Code is available and BSD licensed. Last comment gives link to
> blog making code available.
>
> We weren't the only ones with a problem with their license.
> On 9/3/2014 9:30 AM, Joel Sherrill wrote:
>> On 9/3/2014 6:47 AM, Sebastian Huber wrote:
>>> Hello,
>>>
>>> there are also BSD licensed CMSIS versions:
>>>
>>> http://comments.gmane.org/gmane.comp.lib.libopencm3/361
>>>
>>> The original ARM license makes it pretty useless for us.
>>>
>> Interestingly, these are from ARM but are really BSD licensed.
>>
>> I am not opposed to us using them as long as we review each file
>> for appropriate licensing.
>>
>> Someone from the RTEMS Community would also need to step up
>> and make sure we get updates periodically. Basically help out the
>> guy with the github site. Nothing is worse that importing third party
>> source without an upstream connection and feedback loop.
>>
>
> --
> 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



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMSIS?

[Joel Sherrill]

On 7/29/2015 3:21 PM, Daniel Gutson wrote:

Hi guys,

I just got a student who likes this project and wants to provide a
CMSIS API to RTEMS as her career final project.
I will be her director.
Besides telling her to read stuff, documentation, and the github
source files, any initial advice about how to implement this
on top of RTEMS? I.e. an external library with RSB support?


Looking back at the page I cited, I see this list:

(a) ./CMSIS/DSP_Lib - DSP Library sources and examples;
(b) ./CMSIS/Include - Header files;
(c) ./CMSIS/Lib - DSP Library build for various toolchains;
(d) ./CMSIS/RTOS - Header file template for CMSIS-RTOS implementation; and
(e) ./Device - Template files and implementations for Cortex-M class processors.

I assume the first part would be to implement the (d) CMSIS/RTOS
APIs in terms of RTEMS services. (a)-(c) appear to be unrelated
to RTOS and (e) looks like help for BSPs.

Is that the area you had in mind? Or something else?

If so, then I personally would begin by mapping those operations
onto available public services.

--joel


   Daniel.

On Wed, Sep 3, 2014 at 11:36 AM, Joel Sherrill
 wrote:

I hate to reply to my own post but need to in this case.

https://mbed.org/blog/entry/CMSIS-Components-BSD-Licensed/

Code is available and BSD licensed. Last comment gives link to
blog making code available.

We weren't the only ones with a problem with their license.
On 9/3/2014 9:30 AM, Joel Sherrill wrote:

On 9/3/2014 6:47 AM, Sebastian Huber wrote:

Hello,

there are also BSD licensed CMSIS versions:

http://comments.gmane.org/gmane.comp.lib.libopencm3/361

The original ARM license makes it pretty useless for us.


Interestingly, these are from ARM but are really BSD licensed.

I am not opposed to us using them as long as we review each file
for appropriate licensing.

Someone from the RTEMS Community would also need to step up
and make sure we get updates periodically. Basically help out the
guy with the github site. Nothing is worse that importing third party
source without an upstream connection and feedback loop.



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






--
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: [rpi bsp] configure fb section in mmu table and improvement for mailbox

[Chris Johns]

On 29/07/2015 8:04 pm, Sebastian Huber wrote:
> 
> A custom workspace initialization can be done via
> bsp_work_area_initialize().
> 

On the zynq the ethernet driver from Ric (SLAC) for the in tree
(existing) IP stack there is:

 uint8_t*  start;
 size_tsize = 0x10;
 uintptr_t boundary  = (uintptr_t) 0;
 uintptr_t alignment = (uintptr_t) 0x10;
 start = (uint8_t*) rtems_heap_allocate_aligned_with_boundary(size,
  alignment,
  boundary);
 arm_cp15_set_translation_table_entries(start,
@start[size],
ARMV7_MMU_DEVICE);

This creates an MMU entry at runtime for a 1M aligned block of memory
that has the cache disabled.

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

Nice surprise with C++11

[Sebastian Huber]

Hello,

please have a look at the following bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064

This is really nice in combination with defines and macros that use ( ) 
to make sure the content stays together.


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