Re: Fwd: Build Linux: FAILED 6/rtems-aarch64 on x86_64-linux-gnu (aarch64-rtems6-gcc-a78cd75-newlib-fcaaf40-x86_64-linux-gnu-1)

[Sebastian Huber]

On 31/10/2020 16:25, Joel Sherrill wrote:

FYI failed on Centos and Ubuntu. I am not seeing logs posted from 
FreeBSD but I thought I started one there.


Not sure there is much to do beyond noting and reporting

I updated the RSB and this version builds on FreeBSD 12.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.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: Problems compiling rtems-libbsd

[Jiri Gaisler]

  
  


On 11/2/20 1:37 AM, Sebastian Huber
  wrote:

Hello
  Jiri,
  
  
  it builds for me. I guess you installed the BSP before with
  RTEMS_NETWORKING == True and then again with RTEMS_NETWORKING ==
  False. Please remove the BSP installation and start from scratch.
  
  

Thanks, that helped and it now compiles and runs on sis. One
  final question:
Do I need to port the RTEMS GRETH driver into the libbsd tree to
  get networking going, or is there some other trick? So far I can
  only get the lo0 device to come up ...


$ sudo ./sis -leon3 -bridge lxcbr0
~/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default/ping01.exe
  
   Loaded
/home/jiri/ibm/src/rtems/rtems-libbsd/build/sparc-rtems6-leon3-default/ping01.exe,
entry 0x4000
  sis> run
  
  *** BEGIN OF TEST LIBBSD PING 1 ***
  *** TEST VERSION:
6.0.0.e303ca4384fb97a9aa870b07b3d442aff562646b
  *** TEST STATE: EXPECTED_PASS
  *** TEST BUILD: RTEMS_POSIX_API
  *** TEST TOOLS: 10.2.1 20200904 (RTEMS 6, RSB
31f936a7b74d60bda609a9960c6e1a705ba54974, Newlib a0d7982)
  nexus0: 
  [zone: unpcb] kern.ipc.maxsockets limit reached
  info: lo0: link state changed to UP
  ifconfig: interface gr_eth1 does not exist
  assertion "exit_code == EX_OK" failed: file
"../../testsuite/include/rtems/bsd/test/default-network-init.h",
line 97, function: default_network_ifconfig_hwif0
  cpu 0 in error mode (tt = 0x80)
  

  


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

Re: How does context switching work?

[Richi Dubey]

Hi Mr. Dörfler,

Thanks for your reply.

When the first task is reactivated, it leaves the contextswitch function.
> Therefore all the code around the context switch function handles the same
> task it was called for.

When I am debugging sp16.exe,after TA1 calls task_wake_after, it calls the
_Context_Switch() function, and I think (correct me if I am wrong) TA5
follows the execution after TA1 calls _Context_Switch.

I have attached the gdb trace with this mail. Let me know what you think.

Thanks,
Richi.


On Sun, Nov 1, 2020 at 12:35 AM Thomas Dörfler <
thomas.doerf...@embedded-brains.de> wrote:

> Richi,
>
> inside the contextswitch function, the current context ist suspended (so
> it is stuck/frozen die nside the context switch code) and execution
> switches to a different task. When the first task is reactivated, it leaves
> the contextswitch function. Therefore all the code around the context
> switch function handles the same task it was called for.
>
> 
> embedded brains GmbH
> Thomas Doerfler
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: thomas.doerf...@embedded-brains.de
> Phone: +49-89-18 94 741-12
> Fax:   +49-89-18 94 741-09
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
>
> Am 31.10.2020 16:49 schrieb Richi Dubey :
>
> Hi,
>
> I want to learn more about how context switching works in RTEMS. I saw the
> following lines in theaddispatch.c:
>
> _Thread_Save_fp( executing );
> _Context_Switch( &executing->Registers, &heir->Registers );
> _Thread_Restore_fp( executing );
>
> I do not understand how it works. Here, the executing process saves its
> context by calling _Thread_Save_fp( executing ), then if a different
> process resumes execution after the context switch, why does it get the
> context of previous process (executing)?
>
> Can someone help me learn more about this?
>
> Thanks,
> Richi.
>
>
>
Right now we are in Task_1:

197   puts( "TA1 - rtems_task_wake_after - yield processor" );
(gdb) 
0x00102590  197   puts( "TA1 - rtems_task_wake_after - yield processor" 
);
(gdb) 
0x00102594  197   puts( "TA1 - rtems_task_wake_after - yield processor" 
);
(gdb) 
198   status = rtems_task_wake_after( RTEMS_YIELD_PROCESSOR );
(gdb) si
0x0010259a  198   status = rtems_task_wake_after( RTEMS_YIELD_PROCESSOR 
);
(gdb) 
rtems_task_wake_after (ticks=46) at 
/home/richi/quick-start/src/rtems/c/src/../../cpukit/rtems/src/taskwakeafter.c:28
28  {
(gdb) ni
0x0010b27a  28  {
(gdb) 
0x0010b27c  28  {
(gdb) 
0x0010b27e  28  {
(gdb) 
36cpu_self = _Thread_Dispatch_disable();
(gdb) 
0x0010b284  36cpu_self = _Thread_Dispatch_disable();
(gdb) 
37  executing = _Per_CPU_Get_executing( cpu_self );
(gdb) 
0x0010b288  37  executing = _Per_CPU_Get_executing( cpu_self );
(gdb) 
0x0010b28c  37  executing = _Per_CPU_Get_executing( cpu_self );
(gdb) 
39  if ( ticks == 0 ) {
(gdb) 
0x0010b290  39  if ( ticks == 0 ) {
(gdb) 
0x0010b292  39  if ( ticks == 0 ) {
(gdb) 
40_Thread_Yield( executing );
(gdb) ni
0x0010b296  40_Thread_Yield( executing );
(gdb) 
0x0010b29a  40_Thread_Yield( executing );
(gdb) 
46_Thread_Dispatch_direct( cpu_self );
(gdb) si
0x0010b2ba  46_Thread_Dispatch_direct( cpu_self );
(gdb) 
_Thread_Dispatch_direct (cpu_self=0x202180 <_RTEMS_tasks_Objects+1280>) at 
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:351
351 {
(gdb) ni
0x00110662  351 {
(gdb) 
0x00110664  351 {
(gdb) 
0x00110666  351 {
(gdb) 
354   if ( cpu_self->thread_dispatch_disable_level != 1 ) {
(gdb) 
0x0011066a  354   if ( cpu_self->thread_dispatch_disable_level != 1 ) {
(gdb) 
354   if ( cpu_self->thread_dispatch_disable_level != 1 ) {
(gdb) 
0x0011066e  354   if ( cpu_self->thread_dispatch_disable_level != 1 ) {
(gdb) 
358   _ISR_Local_disable( level );
(gdb) 
0x0011067a  358   _ISR_Local_disable( level );
(gdb) 
359   _Thread_Do_dispatch( cpu_self, level );
(gdb) 
0x0011067e  359   _Thread_Do_dispatch( cpu_self, level );
(gdb) si
0x00110680  359   _Thread_Do_dispatch( cpu_self, level );
(gdb) 
_Thread_Do_dispatch (cpu_self=0x1, level=48) at 
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threaddispatch.c:260
260 {
(gdb) ni
0x0011059a  260 {
(gdb) 
0x0011059c  260 {
(gdb) 
0x0011059e  260 {
(gdb) 
0x001105a0  260 {
(gdb) 
267 !_ISR_Is_enabled( level )
(gdb) 
0x001105a4  267 !_ISR_Is_enabled( level )
(gdb) 
0x001105a8  267 !_ISR_Is_enabled( level )
(gdb) ni
267 !_ISR_Is_enabled( level )
(gdb) 
0x001105ae  267 !_ISR_Is_enabled( level )
(gdb) 
266   if (
(gdb) 
0x001105b2  266   i

Re: How does context switching work?

[Richi Dubey]

Thanks a lot for your reply.

But that code is okay because the floating point unit is not used during
> that sequence. it is untouched and up to a point it doesn't matter when the
> floating point unit is restored as long as it's before the thread needs it.
> And RTEMS should not be using floating point operations except in very
> special places in the code base.
> not sure that helps but the floating point unit and the integer unit are
> separate and most of the time can be contact switched separately completely
> safely.

I understand. This is smart.

The _Context_Switch() function changes the thread stack and the
> non-volatile (callee save) registers. So, the value of the executing
> local variable changes with a call to _Context_Switch().

I understand. Thank you.

On Mon, Nov 2, 2020 at 11:48 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 31/10/2020 16:50, Richi Dubey wrote:
>
> >
> > I want to learn more about how context switching works in RTEMS. I saw
> > the following lines in theaddispatch.c:
> >
> > _Thread_Save_fp( executing );
> > _Context_Switch( &executing->Registers, &heir->Registers );
> > _Thread_Restore_fp( executing );
> >
> > I do not understand how it works. Here, the executing process saves
> > its context by calling _Thread_Save_fp( executing ), then if a
> > different process resumes execution after the context switch, why does
> > it get the context of previous process (executing)?
> The _Context_Switch() function changes the thread stack and the
> non-volatile (callee save) registers. So, the value of the executing
> local variable changes with a call to _Context_Switch().
>
> --
> 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

How does RTEMS decide which process to execute next on calling rtems_task_exit

[Richi Dubey]

Hi,

While debugging sp16.exe, when Task_1 calls rtems_task_wake_after,
following the stack trace would lead us to the scheduler code that makes a
decision in selecting the next thread to execute. rtems_task_wake_after ->
_Thread_Yield -> _Scheduler_Yield -> *scheduler->Operations.yield.

But I tried a lot and checked inside each stack when Task_5
calls rtems_task_exit(), but I could not find any code that calls the
scheduler to make a decision on the next thread to execute. I also tried
setting watchpoint, but to no avail:

--
rtems_task_exit () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/rtems/src/taskexit.c:23
23 {
(gdb) awatch cpu_self->heir
Hardware access (read/write) watchpoint 8: cpu_self->heir
(gdb) c
Continuing.
Watchpoint 8 deleted because the program has left the block
in which its expression is valid.

Thread 1 hit Breakpoint 5, _Terminate (the_source=RTEMS_FATAL_SOURCE_EXIT,
the_error=0) at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/interr.c:36
36  _User_extensions_Fatal( the_source, the_error );
(gdb)
--

Can someone tell me how I can achieve my goal?

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

[PATCH] libtests/dl06: Add -lm

[Sebastian Huber]

There is probably something wrong with this test program.  If it is compiled
without function/data sections, no optimization, and no linker garbage
collection, then there is an undefined reference to atan2() and tan().  Fix
this issue by adding -lm.
---
 spec/build/testsuites/libtests/dl06.yml | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/spec/build/testsuites/libtests/dl06.yml 
b/spec/build/testsuites/libtests/dl06.yml
index 2f5d4ab08d..e1bbd006c9 100644
--- a/spec/build/testsuites/libtests/dl06.yml
+++ b/spec/build/testsuites/libtests/dl06.yml
@@ -42,7 +42,8 @@ ldflags: []
 links: []
 prepare-build: null
 prepare-configure: null
-stlib: []
+stlib:
+- m
 type: build
 use-after: []
 use-before: []
-- 
2.26.2

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

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Niteesh G. S.]

ping.

On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S.  wrote:

> Hello,
>
> On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer 
> wrote:
>
>> Hello Niteesh,
>>
>> sorry for adding another delay: I think the new build system needs a bit
>> of time to settle. As soon as there are some more PASS in the table that
>> Sebastian created [1] (especially for beagle) we should try to get these
>> patches merged. Before that I would like to avoid big changes because it
>> might get hard to distinguish new bugs from build system bugs.
>
>
> No problem. Currently, I have my university exams going on and also I am
> waiting for my logic analyzer. As soon as it arrives I'll start verifying
> the previous
> drivers and finish refactoring the other ones.
>
> Thanks,
> Niteesh.
>
>
>
>>
>> Best regards
>>
>> Christian
>>
>> [1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
>>
>> On 16/09/2020 19:05, Niteesh G. S. wrote:
>> > Hello,
>> >
>> > Sorry for the delay, I was a bit occupied with my university work.
>> > Now since the new build system is merged I would like to get my
>> > GSoC work merged too.
>> >
>> > The goal of this series patches is to implement the OFW API into RTEMS
>> > and modify libBSD to use this RTEMS API instead of its own.
>> >
>> > Thanks,
>> > Niteesh.
>> >
>> > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu > > > wrote:
>> >
>> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
>> > interface. This API is created to be compatible with FreeBSD
>> > OpenFirmWare interface. The main intention is to make
>> > porting of FreeBSD drivers to RTEMS easier.
>> >
>> > Most functions implemented have an direct one-one mapping
>> > with the original OFW API and some extra auxiliary functions
>> > were implemented to make working with device trees easier in
>> > RTEMS.
>> >
>> > Update #3784
>> > ---
>> >  bsps/include/ofw/ofw.h| 548 +++
>> >  bsps/include/ofw/ofw_compat.h |  74 
>> >  bsps/shared/ofw/ofw.c | 682
>> ++
>> >  spec/build/bsps/obj.yml   |   5 +
>> >  4 files changed, 1309 insertions(+)
>> >  create mode 100644 bsps/include/ofw/ofw.h
>> >  create mode 100644 bsps/include/ofw/ofw_compat.h
>> >  create mode 100644 bsps/shared/ofw/ofw.c
>> >
>> > diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
>> > new file mode 100644
>> > index 00..411010be89
>> > --- /dev/null
>> > +++ b/bsps/include/ofw/ofw.h
>> > @@ -0,0 +1,548 @@
>> > +/* SPDX-License-Identifier: BSD-2-Clause */
>> > +
>> > +/**
>> > + * @file
>> > + *
>> > + * @ingroup ofw
>> > + *
>> > + * RTEMS FDT implementation of OpenFirmWare Interface.
>> > + *
>> > + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
>> > interface.
>> > + * This API is created to be compatible with FreeBSD OpenFirmWare
>> > interface.
>> > + * The main intention is to make porting of FreeBSD drivers to
>> > RTEMS easier.
>> > + */
>> > +
>> > +/*
>> > + * Copyright (C) 2020 Niteesh Babu G S > > >
>> > + *
>> > + * 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 COPYRIGHT HOLDERS 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 COPYRIGHT OWNER 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.
>> > + */
>> > +
>> > +#ifndef _OFW_H
>> > +#define _OFW_H
>> > +
>> > +#ifdef __cplusplus
>> > 

[PATCH] rtems-bsps: Use build specification items

[Sebastian Huber]

Close #4123.
---
 rtems-bsps | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/rtems-bsps b/rtems-bsps
index 574ba1aad4..8f3a887b9d 100755
--- a/rtems-bsps
+++ b/rtems-bsps
@@ -32,11 +32,18 @@ from __future__ import print_function
 import argparse
 import os
 import os.path
+import re
 import sys
 
 rtems_version = 6
 
 
+_BUILD_TYPE_BSP = re.compile(r"build-type:\s*bsp\n")
+_ARCH = re.compile(r"arch:\s*(\S+)\n")
+_FAMILY = re.compile(r"family:\s*(\S+)\n")
+_BSP = re.compile(r"bsp:\s*(\S+)\n")
+
+
 class ArchBsps:
 """Collects and processes the BSPs for a range of architectures
 creating output in text, markdown and HTML ir pandoc is installed"""
@@ -44,10 +51,10 @@ class ArchBsps:
 self.trace = trace
 self._output = []
 self.top = os.path.realpath(path)
-self.base = os.path.join(self.top, 'bsps')
+self.base = os.path.join(self.top, 'spec', 'build', 'bsps')
 self.configs = []
 self.archs = {}
-self._collect('.cfg')
+self._collect('.yml')
 self._process()
 
 def _clear(self):
@@ -70,17 +77,15 @@ class ArchBsps:
 """Process the collected list of config files."""
 self.archs = {}
 for cfg in self.configs:
-config_path = cfg[len(self.base) + 1:]
-config_parts = config_path.split(os.sep)
-if len(config_parts) == 4:
-arch = config_parts[0]
-family = config_parts[1]
-bsp = os.path.splitext(config_parts[3])[0]
-if arch not in self.archs:
-self.archs[arch] = {}
-if family not in self.archs[arch]:
-self.archs[arch][family] = {}
-self.archs[arch][family][bsp] = config_path
+with open(cfg, 'r') as cfg_file:
+content = cfg_file.read()
+if _BUILD_TYPE_BSP.search(content):
+arch = _ARCH.search(content).group(1)
+family = _FAMILY.search(content).group(1)
+bsp = _BSP.search(content).group(1)
+self.archs.setdefault(arch, {})
+self.archs[arch].setdefault(family, {})
+self.archs[arch][family][bsp] = cfg[len(self.base) + 1:]
 
 def _max_arch_len(self):
 """Finds the longest arch label"""
-- 
2.26.2

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

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

On 02/11/2020 18:06, Niteesh G. S. wrote:
> ping.

Yes, of course you are right that it would be time to integrate it. The
nasty part why I haven't started to do something into that direction is
that we currently still have the old build system and the new in
parallel. But I think we should start to integrate your code anyway.

Please correct me if I'm wrong: Currently there are two parts:

1. Adding the OFW interface.

2. Using in in BBB.

Is that correct?

I think the first one should be not too hard. There are already some
parts that use only the new build system. Wouldn't be a problem to do
that with OFW too. So to all participating at the discussion: Is there
any blocker left why we wouldn't integrate an updated version of the
patches?

The second part is a bit harder. BBB is one of the BSPs that are quite
entry friendly and therefore it should currently build with old and new
build system till the old system is removed.

Best regards

Christian

> 
> On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S.  > wrote:
> 
> Hello,
> 
> On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> sorry for adding another delay: I think the new build system
> needs a bit
> of time to settle. As soon as there are some more PASS in the
> table that
> Sebastian created [1] (especially for beagle) we should try to
> get these
> patches merged. Before that I would like to avoid big changes
> because it
> might get hard to distinguish new bugs from build system bugs.
> 
> 
> No problem. Currently, I have my university exams going on and also I am
> waiting for my logic analyzer. As soon as it arrives I'll start
> verifying the previous
> drivers and finish refactoring the other ones.
> 
> Thanks,
> Niteesh.
> 
>  
> 
> 
> Best regards
> 
> Christian
> 
> [1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
> 
> On 16/09/2020 19:05, Niteesh G. S. wrote:
> > Hello,
> >
> > Sorry for the delay, I was a bit occupied with my university work.
> > Now since the new build system is merged I would like to get my
> > GSoC work merged too.
> >
> > The goal of this series patches is to implement the OFW API
> into RTEMS
> > and modify libBSD to use this RTEMS API instead of its own.
> >
> > Thanks,
> > Niteesh.
> >
> > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu
> mailto:niteesh...@gmail.com>
> > >>
> wrote:
> >
> >     RTEMS OFW is a FDT only implementation of the OpenFirmWare
> >     interface. This API is created to be compatible with FreeBSD
> >     OpenFirmWare interface. The main intention is to make
> >     porting of FreeBSD drivers to RTEMS easier.
> >
> >     Most functions implemented have an direct one-one mapping
> >     with the original OFW API and some extra auxiliary functions
> >     were implemented to make working with device trees easier in
> >     RTEMS.
> >
> >     Update #3784
> >     ---
> >      bsps/include/ofw/ofw.h        | 548
> +++
> >      bsps/include/ofw/ofw_compat.h |  74 
> >      bsps/shared/ofw/ofw.c         | 682
> ++
> >      spec/build/bsps/obj.yml       |   5 +
> >      4 files changed, 1309 insertions(+)
> >      create mode 100644 bsps/include/ofw/ofw.h
> >      create mode 100644 bsps/include/ofw/ofw_compat.h
> >      create mode 100644 bsps/shared/ofw/ofw.c
> >
> >     diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> >     new file mode 100644
> >     index 00..411010be89
> >     --- /dev/null
> >     +++ b/bsps/include/ofw/ofw.h
> >     @@ -0,0 +1,548 @@
> >     +/* SPDX-License-Identifier: BSD-2-Clause */
> >     +
> >     +/**
> >     + * @file
> >     + *
> >     + * @ingroup ofw
> >     + *
> >     + * RTEMS FDT implementation of OpenFirmWare Interface.
> >     + *
> >     + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
> >     interface.
> >     + * This API is created to be compatible with FreeBSD
> OpenFirmWare
> >     interface.
> >     + * The main intention is to make porting of FreeBSD
> drivers to
> >     RTEMS easier.
> >     + */
> >     +
> >     +/*
> >     + * Copyright (C) 2020 Niteesh Babu G S
> mailto:niteesh...@

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

On 03/11/2020 03:42, Niteesh G. S. wrote:
> Hello Christian,
> 
> On Tue, Nov 3, 2020 at 12:43 AM Christian Mauderer  > wrote:
> 
> Hello Niteesh,
> 
> On 02/11/2020 18:06, Niteesh G. S. wrote:
> > ping.
> 
> Yes, of course you are right that it would be time to integrate it. The
> nasty part why I haven't started to do something into that direction is
> that we currently still have the old build system and the new in
> parallel. But I think we should start to integrate your code anyway.
> 
> Please correct me if I'm wrong: Currently there are two parts:
> 
> 1. Adding the OFW interface.
> 
> 2. Using in in BBB.
> 
> Is that correct?
> 
> There is also the FreeBSD structures to makeporting of drivers easy.
> I guess merging this after a thorough inspection should also not be
> an issue.
> 

Do the patches for the OFW interface and the FreeBSD structures still
work on a current RTEMS master?

Best regards

Christian

> 
> I think the first one should be not too hard. There are already some
> parts that use only the new build system. Wouldn't be a problem to do
> that with OFW too. So to all participating at the discussion: Is there
> any blocker left why we wouldn't integrate an updated version of the
> patches?
> 
>  
> The only blocker seen during the development was the license issue.
> But that is now resolved since we figured out that all the referenced
> code comes under the BSD 2 license.
>  
> 
> The second part is a bit harder. BBB is one of the BSPs that are quite
> entry friendly and therefore it should currently build with old and new
> build system till the old system is removed.
> 
>  
> OK. I'll wait until the old system gets removed, I still have some work left
> to do on the drivers.
> 
> Thanks,
> Niteesh
> 
> Best regards
> 
> Christian
> 
> >
> > On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S.
> mailto:niteesh...@gmail.com>
> > >> wrote:
> >
> >     Hello,
> >
> >     On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> >> wrote:
> >
> >         Hello Niteesh,
> >
> >         sorry for adding another delay: I think the new build system
> >         needs a bit
> >         of time to settle. As soon as there are some more PASS in the
> >         table that
> >         Sebastian created [1] (especially for beagle) we should try to
> >         get these
> >         patches merged. Before that I would like to avoid big changes
> >         because it
> >         might get hard to distinguish new bugs from build system bugs.
> >
> >
> >     No problem. Currently, I have my university exams going on and
> also I am
> >     waiting for my logic analyzer. As soon as it arrives I'll start
> >     verifying the previous
> >     drivers and finish refactoring the other ones.
> >
> >     Thanks,
> >     Niteesh.
> >
> >      
> >
> >
> >         Best regards
> >
> >         Christian
> >
> >         [1]
> https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
> >
> >         On 16/09/2020 19:05, Niteesh G. S. wrote:
> >         > Hello,
> >         >
> >         > Sorry for the delay, I was a bit occupied with my
> university work.
> >         > Now since the new build system is merged I would like to
> get my
> >         > GSoC work merged too.
> >         >
> >         > The goal of this series patches is to implement the OFW API
> >         into RTEMS
> >         > and modify libBSD to use this RTEMS API instead of its own.
> >         >
> >         > Thanks,
> >         > Niteesh.
> >         >
> >         > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu
> >         mailto:niteesh...@gmail.com>
> >
> >         >     >         wrote:
> >         >
> >         >     RTEMS OFW is a FDT only implementation of the
> OpenFirmWare
> >         >     interface. This API is created to be compatible with
> FreeBSD
> >         >     OpenFirmWare interface. The main intention is to make
> >         >     porting of FreeBSD drivers to RTEMS easier.
> >         >
> >         >     Most functions implemented have an direct one-one
> mapping
> >         >     with the original OFW API and some extra auxiliary
> functions
> >         >     were implemented to make working with device trees
> easier in
> >         >     RTEMS.
> >         >