On Fri, Apr 17, 2020 at 11:38 PM Gedare Bloom wrote:
> On Fri, Apr 17, 2020 at 11:48 AM Eshan Dhawan
> wrote:
> >
> >
> >
> > On Fri, Apr 17, 2020 at 9:49 PM Gedare Bloom wrote:
> >>
> >> On Fri, Apr 17, 2020 at 8:31 AM Eshan dhawan
> wrote:
> >> >
> >> > ---
> >> >
On Fri, Apr 17, 2020 at 11:48 AM Eshan Dhawan wrote:
>
>
>
> On Fri, Apr 17, 2020 at 9:49 PM Gedare Bloom wrote:
>>
>> On Fri, Apr 17, 2020 at 8:31 AM Eshan dhawan wrote:
>> >
>> > ---
>> > testsuites/psxtests/Makefile.am | 10 ++
>> > testsuites/psxtests/configure.ac
On Fri, Apr 17, 2020 at 9:49 PM Gedare Bloom wrote:
> On Fri, Apr 17, 2020 at 8:31 AM Eshan dhawan
> wrote:
> >
> > ---
> > testsuites/psxtests/Makefile.am | 10 ++
> > testsuites/psxtests/configure.ac | 1 +
> > testsuites/psxtests/psxgetcpuclockid01/init.c | 149
On Fri, Apr 17, 2020 at 11:33 AM Sebastian Huber
wrote:
>
> On 17/04/2020 19:30, Gedare Bloom wrote:
>
> On Fri, Apr 17, 2020 at 2:11 AM Sebastian Huber
> wrote:
>
> Close #3953.
> ---
> c-user/user_extensions.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git
OK I would prefer to have it close a ticket on 5.1 that addresses the
fact it was a latent bug. I'm not sure how to feel about having
commits made prior to cutting a release, that update tickets for
milestones after the release. I suppose it is just a minor annoyance
to me.
On Fri, Apr 17, 2020
On 17/04/2020 19:30, Gedare Bloom wrote:
On Fri, Apr 17, 2020 at 2:11 AM Sebastian Huber
wrote:
Close #3953.
---
c-user/user_extensions.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/c-user/user_extensions.rst b/c-user/user_extensions.rst
index c3bd1c6..89b86fd 100644
---
Thanks, push it with the doc
On Fri, Apr 17, 2020 at 2:11 AM Sebastian Huber
wrote:
>
> Check that the extensions table is not NULL. Change format.
>
> Update #3953.
> ---
> cpukit/sapi/src/extensioncreate.c | 14 ++
> testsuites/sptests/sp07/init.c| 5 +
> 2 files
On Fri, Apr 17, 2020 at 2:11 AM Sebastian Huber
wrote:
>
> Close #3953.
> ---
> c-user/user_extensions.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/c-user/user_extensions.rst b/c-user/user_extensions.rst
> index c3bd1c6..89b86fd 100644
> --- a/c-user/user_extensions.rst
> +++
push after testing, thanks
On Fri, Apr 17, 2020 at 7:08 AM Christian Mauderer
wrote:
>
> Update #3869.
> ---
> freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
>
On 17/04/2020 18:16, Joel Sherrill wrote:
After some Google searching and talking to Chris, I modified my nohup
command that starts the script to add "running now and reporting results.
I don't know how to capture this info and the fact that removing gcc
from the FreeBSD 12 test machine to
On Fri, Apr 17, 2020 at 10:17 AM Joel Sherrill wrote:
>
> After some Google searching and talking to Chris, I modified my nohup command
> that starts the script to add " reporting results.
>
> I don't know how to capture this info and the fact that removing gcc from the
> FreeBSD 12 test
Hello Joel,
thanks for your comment.
On 17/04/2020 16:41, Joel Sherrill wrote:
Code annotations are a must. Sebastian is right that putting something
above the body is the way to go. We are using a requirements comment
block above the entry point to the method. A script integrates with the
On Fri, Apr 17, 2020 at 8:31 AM Eshan dhawan wrote:
>
> ---
> testsuites/psxtests/Makefile.am | 10 ++
> testsuites/psxtests/configure.ac | 1 +
> testsuites/psxtests/psxgetcpuclockid01/init.c | 149 ++
> .../psxgetcpuclockid01/psxgetcpuclockid01.doc
After some Google searching and talking to Chris, I modified my nohup
command that starts the script to add " wrote:
> Hi
>
> I see this type of failure on rtems-tools and rtems-tester. I run nohup'ed
> and I suspect these happen after the connection is dropped. I see what I
> think is discussion
On Fri, Apr 17, 2020 at 9:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:
> Hello,
>
> with the pre-qualified build of RTEMS
>
> https://lists.rtems.org/pipermail/devel/2020-April/059445.html
>
> I try out the following approach. I run Doxygen on the set of
> pre-qualified
---
testsuites/psxtests/Makefile.am | 10 ++
testsuites/psxtests/configure.ac | 1 +
testsuites/psxtests/psxgetcpuclockid01/init.c | 149 ++
.../psxgetcpuclockid01/psxgetcpuclockid01.doc | 23 +++
.../psxgetcpuclockid01/psxgetcpuclockid01.scn | 4 +
On 17/04/2020 16:15, Joel Sherrill wrote:
I anticipate that we will switch to your new build system after 5.x is
released but that is a community discussion and decision.
Once the RTEMS 5 release is done, I will write some more stuff about it.
I found some general issues while working with
Great work and thanks for the report!
I anticipate that we will switch to your new build system after 5.x is
released but that is a community discussion and decision.
Can you quickly remind us all what is needed so a source file can be
considered pre-qualified? Are all of required artifacts and
Hello,
with the pre-qualified build of RTEMS
https://lists.rtems.org/pipermail/devel/2020-April/059445.html
I try out the following approach. I run Doxygen on the set of
pre-qualified files to produce the documentation and a tagfile:
# The TAGFILES tag can be used to specify one or more tag
Hello,
for the ESA pre-qualification activity we would like to have an RTEMS
build which includes the pre-qualified parts and in addition give
applications the option to use most of the remaining functionality
provided by a standard RTEMS (excluded are POSIX signals and timers). To
achieve
Update #3869.
---
freebsd/sys/arm/freescale/imx/imx6_usbphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
b/freebsd/sys/arm/freescale/imx/imx6_usbphy.c
index 7df2e124..508e49c8 100644
---
On 17/04/2020 15:04, jan.som...@dlr.de wrote:
> I can confirm, that the current 5-freebsd-12 branch builds now for pc686-BSP.
> Thanks.
Thanks for testing and sorry for introducing these bugs. It seems I had
very bad luck with this patch set. It already broke two builds and I
just found another
I can confirm, that the current 5-freebsd-12 branch builds now for pc686-BSP.
Thanks.
> -Original Message-
> From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Christian
> Mauderer
> Sent: Friday, April 17, 2020 2:49 PM
> To: Sebastian Huber; devel@rtems.org
> Subject: Re: [PATCH
On 17/04/2020 14:42, Sebastian Huber wrote:
> Please push it, if it fixes the build.
>
Thanks. Pushed.
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone:
Please push it, if it fixes the build.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
---
freebsd/sys/dev/extres/regulator/regulator.c | 2 ++
freebsd/sys/dev/gpio/gpioregulator.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
b/freebsd/sys/dev/extres/regulator/regulator.c
index ca2de6c4..49020bdb 100644
---
On 17/04/2020 14:15, Sebastian Huber wrote:
>
> On 17/04/2020 14:03, Christian Mauderer wrote:
>> just noted that the logic isn't entirely correct: Should it be the
>> following?
>>
>> #if (defined(__rtems__) && defined(FDT)) || !defined(__rtems__)
>>
>> The conditionals with some second
On 17/04/2020 14:03, Christian Mauderer wrote:
just noted that the logic isn't entirely correct: Should it be the
following?
#if (defined(__rtems__) && defined(FDT)) || !defined(__rtems__)
The conditionals with some second define are always a bit tricky in libbsd.
What about
#if
On 17/04/2020 13:21, Sebastian Huber wrote:
> Thanks, please push it.
>
Hello Sebastian,
just noted that the logic isn't entirely correct: Should it be the
following?
#if (defined(__rtems__) && defined(FDT)) || !defined(__rtems__)
The conditionals with some second define are always a bit
Thank you.
I will see, that we prepare a similar patch set for the master branch as well.
Have a nice week-end,
Jan
> -Original Message-
> From: Sebastian Huber [mailto:sebastian.hu...@embedded-brains.de]
> Sent: Friday, April 17, 2020 1:20 PM
> To: Sommer, Jan; devel@rtems.org
>
Thanks, please push it.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 17/04/2020 10:24, Jan Sommer wrote:
This is the backport for the 5-freebsd-12 branch to make rtems-libbsd compile
for i386 again:
- It also introduces path-mappings to waf_libbsd.py as introduced here:
https://lists.rtems.org/pipermail/devel/2020-February/057457.html
Changes compared to
This is the backport for the 5-freebsd-12 branch to make rtems-libbsd compile
for i386 again:
- It also introduces path-mappings to waf_libbsd.py as introduced here:
https://lists.rtems.org/pipermail/devel/2020-February/057457.html
Changes compared to v4:
- Split up the changes in more
- Update imported files to compile rtems-libbsd for i386 based BSPs
- Mostly commenting out parts which create compile or link errors in
RTEMS, but aren't needed
---
freebsd/sbin/sysctl/sysctl.c| 8
freebsd/sys/dev/pci/pci_pci.c | 2 ++
- callout_reset_on takes a cpu which is ignored by the subsequent call
to callout_reset_sbt_on in RTEMS.
- The macro is redefined to discard the cpu argument directly which
enables uses of it with cpu-dependent variables (disabled in
RETMS) without further changes, e.g. in iflib.c.
---
- The files in the i386 directory have been moved to common x86 directories by
FreeBSD:
- freebsd/sys/x86/x86/legacy.c
- freebsd/sys/x86/include/machine/legacyvar.h
- freebsd/sys/x86/include/machine/specialreg.h
- Add header files in rtemsbsd directory to direct compiler to new files
---
- path-mappings allow to fix autogenerated include paths for some corner
cases of target platforms without the need to change the build system
- Currently used for i386 based bsps
---
libbsd.py | 8
waf_libbsd.py | 13 +++--
2 files changed, 19 insertions(+), 2 deletions(-)
- Update FreeBSD files in libbsd.py to required by i386 based BSPs
- Some machine specific header files have moved to different directories
in FreeBSD
- Add missing files e1000 network driver (iflib*)
---
libbsd.py | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git
- cpusets and SMP are currently not supported in libbsd for RTEMS
- Disable the ifc_cpus context variable and replace its usage,
essentially hard-coding for cpu 0
---
freebsd/sys/net/iflib.c | 24
1 file changed, 24 insertions(+)
diff --git a/freebsd/sys/net/iflib.c
Hello Jan,
On 17/04/2020 10:11, jan.som...@dlr.de wrote:
> Hi Christian,
>
> Yes, with this patch my build works again.
> Thank you very much.
Thanks for testing.
Best regards
Christian
>
> Best regards,
>
>Jan
>
>> -Ursprüngliche Nachricht-
>> Von: Christian Mauderer
Close #3953.
---
c-user/user_extensions.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/c-user/user_extensions.rst b/c-user/user_extensions.rst
index c3bd1c6..89b86fd 100644
--- a/c-user/user_extensions.rst
+++ b/c-user/user_extensions.rst
@@ -466,6 +466,8 @@ DIRECTIVE STATUS CODES:
Check that the extensions table is not NULL. Change format.
Update #3953.
---
cpukit/sapi/src/extensioncreate.c | 14 ++
testsuites/sptests/sp07/init.c| 5 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/cpukit/sapi/src/extensioncreate.c
Hi Christian,
Yes, with this patch my build works again.
Thank you very much.
Best regards,
Jan
> -Ursprüngliche Nachricht-
> Von: Christian Mauderer [mailto:christian.maude...@embedded-brains.de]
> Gesendet: Freitag, 17. April 2020 09:17
> An: Sommer, Jan; devel@rtems.org
>
Hello Jan,
can you please try this patch:
https://lists.rtems.org/pipermail/devel/2020-April/059419.html
I've still seen quite some linker errors in if_em.c. But as far as I can
tell they doesn't seem to be related. Are they?
Best regards
Christian
On 17/04/2020 08:17, Christian Mauderer
---
freebsd/sys/dev/extres/regulator/regulator.c | 2 ++
freebsd/sys/dev/gpio/gpioregulator.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/freebsd/sys/dev/extres/regulator/regulator.c
b/freebsd/sys/dev/extres/regulator/regulator.c
index ca2de6c4..53e45ee7 100644
---
Hello Gedare,
On 16/04/2020 21:16, Gedare Bloom wrote:
> You can push this to 5.1, update the ticket milestone if you do.
Thanks. In that case I most likely should create an extra ticket. I'm
not sure whether Sebastian sees that one as close enough to finished to
be a 5.1 ticket. For me it was a
Hello Jan,
On 16/04/2020 22:27, jan.som...@dlr.de wrote:
> I have a question:
> I just rebased my working tree for the i386 target to the current
> 5-freebsd-12 branch.
> The compilation now fails in regulator related files.
> It seems that I am missing the FDT define and that comments out some
47 matches
Mail list logo
