Re: [PATCH 1/2] cpukit: Add Epiphany architecture port v2
On 09/05/15 16:45, Hesham ALMatary wrote:
[...]
diff --git a/cpukit/score/cpu/epiphany/cpu.c b/cpukit/score/cpu/epiphany/cpu.c
new file mode 100644
index 000..9ec8f94
--- /dev/null
+++ b/cpukit/score/cpu/epiphany/cpu.c
@@ -0,0 +1,114 @@
+/*
+ * Epiphany CPU Dependent Source
+ *
+ * Copyright (c) 2015 University of York.
+ * Hesham ALMatary
+ *
+ * COPYRIGHT (c) 1989-1999.
+ * On-Line Applications Research Corporation (OAR).
I doubt that OAR has a copyright for contents of this new file, but if
they have one, then the license change from the standard RTEMS license
to BSD is a problem.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+void _init(void);
+void _fini(void);
+
+void _init(void)
+{
+ /* Do nothing */
+}
+
+void _fini(void)
+{
+ /* Do nothing */
+}
If you need to define _init() and _fini() here, then something is wrong
with the GCC configuration for this target. For example:
nm /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.9.2/crti.o
T _fini
T _init
[...]
diff --git a/cpukit/score/cpu/epiphany/rtems/score/cpu.h
b/cpukit/score/cpu/epiphany/rtems/score/cpu.h
new file mode 100644
index 000..9958599
--- /dev/null
+++ b/cpukit/score/cpu/epiphany/rtems/score/cpu.h
@@ -0,0 +1,1185 @@
[...]
+
+static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
+{
+ /* TODO */
+}
+
+static inline void _CPU_Context_validate( uintptr_t pattern )
+{
+ while (1) {
+/* TODO */
+ }
+}
+
It would be nice to have implementations of the above two functions at
least for all new ports. See test sptests/spcontext01. It ensures that
the context switch and interrupt code works now and later if some makes
a modification.
The Doxygen comment copy and paste in the cpu.h files is a real mess in
general. It would be better to mention only the architectures specifics
in this file, e.g. references to the ABI documents.
--
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
I think there is a mistake in some bsp_specs files
Hi all
I read the bsp_specs files contained in some bsps, which reside in libbsp/arm,
libbsp/bfin and libbsp/m32r
*endfile:
%{!qrtems: *(old_endfiles)} %{qrtems: crtend.o%s crtn.o%s }
^
I think it should be %.
I wrote a specs file and tested using gcc 4.8.2.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] cpukit: Add Epiphany architecture port v2
On Wed, May 13, 2015 at 8:40 AM, Sebastian Huber
wrote:
>
>
> On 09/05/15 16:45, Hesham ALMatary wrote:
> [...]
>>
>> diff --git a/cpukit/score/cpu/epiphany/cpu.c
>> b/cpukit/score/cpu/epiphany/cpu.c
>> new file mode 100644
>> index 000..9ec8f94
>> --- /dev/null
>> +++ b/cpukit/score/cpu/epiphany/cpu.c
>> @@ -0,0 +1,114 @@
>> +/*
>> + * Epiphany CPU Dependent Source
>> + *
>> + * Copyright (c) 2015 University of York.
>> + * Hesham ALMatary
>> + *
>> + * COPYRIGHT (c) 1989-1999.
>> + * On-Line Applications Research Corporation (OAR).
>
>
> I doubt that OAR has a copyright for contents of this new file, but if they
> have one, then the license change from the standard RTEMS license to BSD is
> a problem.
>
I left the OAR copyrights because the file is copied from other ports
which OAR has copyrights on. The change of the licence from for OAR
files licensed with RTEMS to BSD needs permission. I believe Joel is
OK with that and gave me the permission.
>> + *
>>
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the
>> distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>> PURPOSE
>> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE
>> LIABLE
>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> CONSEQUENTIAL
>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
>> GOODS
>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
>> STRICT
>> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
>> WAY
>> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
>> + * SUCH DAMAGE.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +void _init(void);
>> +void _fini(void);
>> +
>> +void _init(void)
>> +{
>> + /* Do nothing */
>> +}
>> +
>> +void _fini(void)
>> +{
>> + /* Do nothing */
>> +}
>
>
> If you need to define _init() and _fini() here, then something is wrong with
> the GCC configuration for this target. For example:
>
> nm /opt/rtems-4.11/lib/gcc/sparc-rtems4.11/4.9.2/crti.o
> T _fini
> T _init
>
> [...]
>
>> diff --git a/cpukit/score/cpu/epiphany/rtems/score/cpu.h
>> b/cpukit/score/cpu/epiphany/rtems/score/cpu.h
>> new file mode 100644
>> index 000..9958599
>> --- /dev/null
>> +++ b/cpukit/score/cpu/epiphany/rtems/score/cpu.h
>> @@ -0,0 +1,1185 @@
>
> [...]
>>
>> +
>> +static inline void _CPU_Context_volatile_clobber( uintptr_t pattern )
>> +{
>> + /* TODO */
>> +}
>> +
>> +static inline void _CPU_Context_validate( uintptr_t pattern )
>> +{
>> + while (1) {
>> +/* TODO */
>> + }
>> +}
>> +
>
>
> It would be nice to have implementations of the above two functions at least
> for all new ports. See test sptests/spcontext01. It ensures that the
> context switch and interrupt code works now and later if some makes a
> modification.
>
OK, I will implement them for the next version of the patches.
> The Doxygen comment copy and paste in the cpu.h files is a real mess in
> general. It would be better to mention only the architectures specifics in
> this file, e.g. references to the ABI documents.
Should I delete all the copied comments and just add architecture
specific comments? Other ports just copied this file from no_cpu.h as
is and add minor changes like what I did.
> --
> 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.
>
Thanks for your feedback, next set of patches will account for your comments.
--
Hesham
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: I think there is a mistake in some bsp_specs files
On 5/13/2015 4:07 AM, Tom wrote:
> Hi all
>
> I read the bsp_specs files contained in some bsps, which reside in
> libbsp/arm, libbsp/bfin and libbsp/m32r
>
> *endfile:
> %{!qrtems: *(old_endfiles)} %{qrtems: crtend.o%s crtn.o%s }
> ^
> I think it should be %.
>
> I wrote a specs file and tested using gcc 4.8.2.
>
>
This definitely looks like a typo that we are lucky appears
to have no impact. The only time the bsp_spec is used, the other
path (-qrtems) is tripped.
Is there objection to me fixing this in the following files:
arm/altera-cyclone-v/bsp_specs
arm/beagle/bsp_specs
arm/csb336/bsp_specs
arm/csb337/bsp_specs
arm/edb7312/bsp_specs
arm/gba/bsp_specs
arm/gdbarmsim/bsp_specs
arm/gp32/bsp_specs
arm/gumstix/bsp_specs
arm/lm3s69xx/bsp_specs
arm/lpc176x/bsp_specs
arm/lpc24xx/bsp_specs
arm/lpc32xx/bsp_specs
arm/nds/bsp_specs
arm/raspberrypi/bsp_specs
arm/realview-pbx-a9/bsp_specs
arm/rtl22xx/bsp_specs
arm/smdk2410/bsp_specs
arm/stm32f4/bsp_specs
arm/tms570/bsp_specs
arm/xilinx-zynq/bsp_specs
bfin/bf537Stamp/bsp_specs
bfin/eZKit533/bsp_specs
bfin/TLL6527M/bsp_specs
m32r/m32rsim/bsp_specs
--
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: I think there is a mistake in some bsp_specs files
On 14/05/2015 3:10 am, Joel Sherrill wrote:
>
>
> On 5/13/2015 4:07 AM, Tom wrote:
>> Hi all
>>
>> I read the bsp_specs files contained in some bsps, which reside in
>> libbsp/arm, libbsp/bfin and libbsp/m32r
>>
>> *endfile:
>> %{!qrtems: *(old_endfiles)} %{qrtems: crtend.o%s crtn.o%s }
>> ^
>> I think it should be %.
>>
>> I wrote a specs file and tested using gcc 4.8.2.
>>
>>
> This definitely looks like a typo that we are lucky appears
> to have no impact. The only time the bsp_spec is used, the other
> path (-qrtems) is tripped.
>
> Is there objection to me fixing this in the following files:
>
No. Please raise a ticket to track the change.
Thanks.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: I think there is a mistake in some bsp_specs files
On May 13, 2015 6:57:29 PM CDT, Chris Johns wrote:
>On 14/05/2015 3:10 am, Joel Sherrill wrote:
>>
>>
>> On 5/13/2015 4:07 AM, Tom wrote:
>>> Hi all
>>>
>>> I read the bsp_specs files contained in some bsps, which reside in
>>> libbsp/arm, libbsp/bfin and libbsp/m32r
>>>
>>> *endfile:
>>> %{!qrtems: *(old_endfiles)} %{qrtems: crtend.o%s crtn.o%s }
>>> ^
>>> I think it should be %.
>>>
>>> I wrote a specs file and tested using gcc 4.8.2.
>>>
>>>
>> This definitely looks like a typo that we are lucky appears
>> to have no impact. The only time the bsp_spec is used, the other
>> path (-qrtems) is tripped.
>>
>> Is there objection to me fixing this in the following files:
>>
>
>No. Please raise a ticket to track the change.
If there is a ticket can it be done before branching? I would have filed the
ticket.
>Thanks.
>Chris
--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: I think there is a mistake in some bsp_specs files
On 14/05/2015 9:59 am, Joel Sherrill wrote:
>
>
> On May 13, 2015 6:57:29 PM CDT, Chris Johns wrote:
>> On 14/05/2015 3:10 am, Joel Sherrill wrote:
>>>
>>>
>>> On 5/13/2015 4:07 AM, Tom wrote:
Hi all
I read the bsp_specs files contained in some bsps, which reside in
libbsp/arm, libbsp/bfin and libbsp/m32r
*endfile:
%{!qrtems: *(old_endfiles)} %{qrtems: crtend.o%s crtn.o%s }
^
I think it should be %.
I wrote a specs file and tested using gcc 4.8.2.
>>> This definitely looks like a typo that we are lucky appears
>>> to have no impact. The only time the bsp_spec is used, the other
>>> path (-qrtems) is tripped.
>>>
>>> Is there objection to me fixing this in the following files:
>>>
>>
>> No. Please raise a ticket to track the change.
>
> If there is a ticket can it be done before branching? I would have filed the
> ticket.
>
Sorry about that, I meant no objection from me.
Yes it can be committed but I would like a ticket to track an changes
until we branch.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
