Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

On 04/06/2020 14:53, Niteesh G. S. wrote:

I have a few questions which I would like to resolve before sending in 
the patch.


1) Will the definitions for the wrapper functions go under 
cpukit/libtest like it

is currently done for printf, puts, etc.?

No, the wrapper function should be defined along with the test.

And also why are we wrapping printf
and puts? Is it to provide definitions for BSPs that don't compile 
with POSIX

and don't link against newlib?
This is a hack to work around issues with the use of the floating point 
unit in printf().


2) How are we going to let the tests register a device tree? If we are 
placing the
wrapper function under cpukit/libtest, one way would be to have an 
extern variable
in that file which we initialize in the test executable. If we are 
placing it local

to the test then we can define it in the test itself.

I would define the wrapper in the tests.


3) I played around with the linker wrap options. And I want to make 
sure that I
understand it correctly. In this patch, will we be using it in the 
following way?


In openfirm.c we will have the following
const void *bsp_fdt_get();
void ofw_init() {

...

fdtp = bsp_fdt_get();

}
In normal use case(when not testing)
bsp_fdt_get will resolve to the original bsp_fdt_get function right?

And while testing
we will be linking the __wrap_bsp_get_fdt function with the test 
executable right?

and all calls to bsp_get_fdt will resolve to __wrap_bsp_get_fdt
Yes, references to bsp_get_fdt will be resolved to __wrap_bsp_get_fdt 
and references to __real_bsp_get_fdt will be resolved to bsp_get_fdt by 
the linker.


4) Are there any major changes that have to be made other than moving the
files to cpukit?

I haven't looked at the file content yet.


5) Christian suggested that I define commonly used functions like 
malloc, free,
KASSERT into a single header file which will be imported in every 
source file.

This is to decrease the number of redefinitions for these functions.
malloc has been defined as
#define malloc(size, type, flag) malloc(size)
We ignore the type and flags. Is that OK? The malloc implementation in 
RTEMS

doesn't support types and flags will this cause any problem?


This is fine.

There is a FreeBSD malloc implementation(rtems_bsdnet_malloc) under 
libnetworking

can we move it to a commonplace so that other files can use it?

No, please keep libnetworking as is. This is more or less read-only code.


On Thu, Jun 4, 2020 at 11:38 AM Sebastian Huber 
> wrote:


On 04/06/2020 07:57, Chris Johns wrote:

> On 4/6/20 3:22 pm, Sebastian Huber wrote:
>> This approach avoids the need to actively register a device
tree. This could
>> simplify the low level startup a bit. The draw back is that it
needs a special
>> feature of the linker for the tests.
> But we already use this feature and need it for the tests to
link so does it
> matter if it is used here?

I am in favour of this approach using the linker wrap.


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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Niteesh G. S.]

I have a few questions which I would like to resolve before sending in the
patch.

1) Will the definitions for the wrapper functions go under cpukit/libtest
like it
is currently done for printf, puts, etc.? And also why are we wrapping
printf
and puts? Is it to provide definitions for BSPs that don't compile with
POSIX
and don't link against newlib?

2) How are we going to let the tests register a device tree? If we are
placing the
wrapper function under cpukit/libtest, one way would be to have an extern
variable
in that file which we initialize in the test executable. If we are placing
it local
to the test then we can define it in the test itself.

3) I played around with the linker wrap options. And I want to make sure
that I
understand it correctly. In this patch, will we be using it in the
following way?

In openfirm.c we will have the following
const void *bsp_fdt_get();
void ofw_init() {

...

fdtp = bsp_fdt_get();

}
In normal use case(when not testing)
bsp_fdt_get will resolve to the original bsp_fdt_get function right?

And while testing
we will be linking the __wrap_bsp_get_fdt function with the test executable
right?
and all calls to bsp_get_fdt will resolve to __wrap_bsp_get_fdt

4) Are there any major changes that have to be made other than moving the
files to cpukit?

5) Christian suggested that I define commonly used functions like malloc,
free,
KASSERT into a single header file which will be imported in every source
file.
This is to decrease the number of redefinitions for these functions.
malloc has been defined as
#define malloc(size, type, flag) malloc(size)
We ignore the type and flags. Is that OK? The malloc implementation in RTEMS
doesn't support types and flags will this cause any problem?
There is a FreeBSD malloc implementation(rtems_bsdnet_malloc) under
libnetworking
can we move it to a commonplace so that other files can use it?

On Thu, Jun 4, 2020 at 11:38 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/06/2020 07:57, Chris Johns wrote:
>
> > On 4/6/20 3:22 pm, Sebastian Huber wrote:
> >> This approach avoids the need to actively register a device tree. This
> could
> >> simplify the low level startup a bit. The draw back is that it needs a
> special
> >> feature of the linker for the tests.
> > But we already use this feature and need it for the tests to link so
> does it
> > matter if it is used here?
>
> I am in favour of this approach using the linker wrap.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

On 04/06/2020 07:57, Chris Johns wrote:


On 4/6/20 3:22 pm, Sebastian Huber wrote:

This approach avoids the need to actively register a device tree. This could
simplify the low level startup a bit. The draw back is that it needs a special
feature of the linker for the tests.

But we already use this feature and need it for the tests to link so does it
matter if it is used here?


I am in favour of this approach using the linker wrap.

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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Chris Johns]

On 4/6/20 3:22 pm, Sebastian Huber wrote:
> This approach avoids the need to actively register a device tree. This could
> simplify the low level startup a bit. The draw back is that it needs a special
> feature of the linker for the tests.

But we already use this feature and need it for the tests to link so does it
matter if it is used here?

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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

On 01/06/2020 20:55, Niteesh G. S. wrote:

On Fri, May 29, 2020 at 6:49 PM Sebastian Huber 
> wrote:


On 29/05/2020 12:41, Niteesh G. S. wrote:

Hello Sebastian,

> Hello,
>
> On Fri, May 29, 2020 at 12:52 PM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>
> >> wrote:
>
>     Hello,
>
>     since this code is not BSP-specific it should be located in
>     cpukit. How
>     many FreeBSD source files do you intend to import within
this project?
>
>
> This code depends on a bsp that has FDT support. We first
imported it to
> cpukit but then decided to move it to bsps/shared since we
weren't able to
> import BSP related files (bsp/fdt.h in this case) from cpukit.

Please think about how BSP dependencies can be avoided since this
will
also allow us to write unit tests for this infrastructure. One
option is
to add an API to register the device tree. BSPs which have a
device tree
do this before the API is used. Unit tests override the device
tree to
run the test cases.

From what I understood, the API will have the responsibility to 
provide all objects
which will be used by the FreeBSD source. In the current case, it is 
the DTB.
During testing, we override the DTB that will be supplied by the BSP 
with a custom

one like the one in libfdt test. Please correct if I misunderstood it.

Can you please provide some pointers on how to implement one? Or 
please point

to sources of something similar if available.

I can think of a really simple design where the API holds a reference 
to the FDT blob
which it gets through the register function. Under normal operation, 
the BSP will register
the FDT during start up. And while testing just the before running the 
test we can override
the FDT reference by again registering with a custom FDT blob. But I 
don't think this
would scale well in the future. So, please mention about the design 
and implementation

of the API.


I think your proposed approach is fine in general.

The goal should be to move this stuff to cpukit and add tests for it to 
the standard test suite (for example testsuites/libtests/devicetree*).


An alternative to registering a pointer would be to define a provider 
function (currently this is bsp_fdt_get()). Tests can use a wrapper 
function with support from the linker:


const void *test_device_tree;

const void *__wrap_bsp_fdt_get(void)

{

    if (test_device_tree != NULL) {

        return test_device_tree;

    }

    return __real_bsp_fdt_get();

}

This approach avoids the need to actively register a device tree. This 
could simplify the low level startup a bit. The draw back is that it 
needs a special feature of the linker for the tests.


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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Niteesh G. S.]

Hello,

This email is a reminder since this thread has lost activity.

Thanks,
Niteesh.

On Tue, Jun 2, 2020 at 12:25 AM Niteesh G. S.  wrote:

> On Fri, May 29, 2020 at 6:49 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29/05/2020 12:41, Niteesh G. S. wrote:
>>
> Hello Sebastian,
>
>> > Hello,
>> >
>> > On Fri, May 29, 2020 at 12:52 PM Sebastian Huber
>> > > > > wrote:
>> >
>> > Hello,
>> >
>> > since this code is not BSP-specific it should be located in
>> > cpukit. How
>> > many FreeBSD source files do you intend to import within this
>> project?
>> >
>> >
>> > This code depends on a bsp that has FDT support. We first imported it to
>> > cpukit but then decided to move it to bsps/shared since we weren't able
>> to
>> > import BSP related files (bsp/fdt.h in this case) from cpukit.
>>
>> Please think about how BSP dependencies can be avoided since this will
>> also allow us to write unit tests for this infrastructure. One option is
>> to add an API to register the device tree. BSPs which have a device tree
>> do this before the API is used. Unit tests override the device tree to
>> run the test cases.
>
>
> From what I understood, the API will have the responsibility to provide
> all objects
> which will be used by the FreeBSD source. In the current case, it is the
> DTB.
> During testing, we override the DTB that will be supplied by the BSP with
> a custom
> one like the one in libfdt test. Please correct if I misunderstood it.
>
> Can you please provide some pointers on how to implement one? Or please
> point
> to sources of something similar if available.
>
> I can think of a really simple design where the API holds a reference to
> the FDT blob
> which it gets through the register function. Under normal operation, the
> BSP will register
> the FDT during start up. And while testing just the before running the
> test we can override
> the FDT reference by again registering with a custom FDT blob. But I don't
> think this
> would scale well in the future. So, please mention about the design and
> implementation
> of the API.
>
> Thanks,
> Niteesh.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Niteesh G. S.]

On Fri, May 29, 2020 at 6:49 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 29/05/2020 12:41, Niteesh G. S. wrote:
>
Hello Sebastian,

> > Hello,
> >
> > On Fri, May 29, 2020 at 12:52 PM Sebastian Huber
> >  > > wrote:
> >
> > Hello,
> >
> > since this code is not BSP-specific it should be located in
> > cpukit. How
> > many FreeBSD source files do you intend to import within this
> project?
> >
> >
> > This code depends on a bsp that has FDT support. We first imported it to
> > cpukit but then decided to move it to bsps/shared since we weren't able
> to
> > import BSP related files (bsp/fdt.h in this case) from cpukit.
>
> Please think about how BSP dependencies can be avoided since this will
> also allow us to write unit tests for this infrastructure. One option is
> to add an API to register the device tree. BSPs which have a device tree
> do this before the API is used. Unit tests override the device tree to
> run the test cases.


>From what I understood, the API will have the responsibility to provide all
objects
which will be used by the FreeBSD source. In the current case, it is the
DTB.
During testing, we override the DTB that will be supplied by the BSP with a
custom
one like the one in libfdt test. Please correct if I misunderstood it.

Can you please provide some pointers on how to implement one? Or please
point
to sources of something similar if available.

I can think of a really simple design where the API holds a reference to
the FDT blob
which it gets through the register function. Under normal operation, the
BSP will register
the FDT during start up. And while testing just the before running the test
we can override
the FDT reference by again registering with a custom FDT blob. But I don't
think this
would scale well in the future. So, please mention about the design and
implementation
of the API.

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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

On 29/05/2020 12:41, Niteesh G. S. wrote:


Hello,

On Fri, May 29, 2020 at 12:52 PM Sebastian Huber 
> wrote:


Hello,

since this code is not BSP-specific it should be located in
cpukit. How
many FreeBSD source files do you intend to import within this project?


This code depends on a bsp that has FDT support. We first imported it to
cpukit but then decided to move it to bsps/shared since we weren't able to
import BSP related files (bsp/fdt.h in this case) from cpukit.


Please think about how BSP dependencies can be avoided since this will 
also allow us to write unit tests for this infrastructure. One option is 
to add an API to register the device tree. BSPs which have a device tree 
do this before the API is used. Unit tests override the device tree to 
run the test cases.


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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Niteesh G. S.]

Hello,

On Fri, May 29, 2020 at 12:52 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> since this code is not BSP-specific it should be located in cpukit. How
> many FreeBSD source files do you intend to import within this project?
>

This code depends on a bsp that has FDT support. We first imported it to
cpukit but then decided to move it to bsps/shared since we weren't able to
import BSP related files (bsp/fdt.h in this case) from cpukit.
The below is the link to my branch where I imported all this code under
cpukit/libfreebsd.
https://github.com/gs-niteesh/rtems/commits/test_branch

As far as my GSoC project is concerned. I will be importing the Beaglebone
pinmux driver. But in the future, we mostly plan to import drivers so we
switched
to a folder under bsps.

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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[Sebastian Huber]

Hello,

since this code is not BSP-specific it should be located in cpukit. How 
many FreeBSD source files do you intend to import within this project?


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

[PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

[G S Niteesh Babu]

freebsd head: b8c57b4

The following files have been imported from FreeBSD to implement
OF_* functions into RTEMS.
1) openfirm.h
2) openfirm.c
3) ofw_fdt.c
---
 bsps/shared/freebsd/dev/ofw/ofw_fdt.c  | 479 ++
 bsps/shared/freebsd/dev/ofw/openfirm.c | 848 +
 bsps/shared/freebsd/dev/ofw/openfirm.h | 187 ++
 3 files changed, 1514 insertions(+)
 create mode 100644 bsps/shared/freebsd/dev/ofw/ofw_fdt.c
 create mode 100644 bsps/shared/freebsd/dev/ofw/openfirm.c
 create mode 100644 bsps/shared/freebsd/dev/ofw/openfirm.h

diff --git a/bsps/shared/freebsd/dev/ofw/ofw_fdt.c 
b/bsps/shared/freebsd/dev/ofw/ofw_fdt.c
new file mode 100644
index 00..e4f72e8142
--- /dev/null
+++ b/bsps/shared/freebsd/dev/ofw/ofw_fdt.c
@@ -0,0 +1,479 @@
+/*-
+ * SPDX-License-Identifier: BSD-2-Clause-FreeBSD
+ *
+ * Copyright (c) 2009-2010 The FreeBSD Foundation
+ * All rights reserved.
+ *
+ * This software was developed by Semihalf under sponsorship from
+ * the FreeBSD Foundation.
+ *
+ * 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 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "ofw_if.h"
+
+#ifdef DEBUG
+#define debugf(fmt, args...) do { printf("%s(): ", __func__);  \
+printf(fmt,##args); } while (0)
+#else
+#define debugf(fmt, args...)
+#endif
+
+#if defined(__arm__)
+#if defined(SOC_MV_ARMADAXP) || defined(SOC_MV_ARMADA38X) || \
+defined(SOC_MV_DISCOVERY) || defined(SOC_MV_DOVE) || \
+defined(SOC_MV_FREY) || defined(SOC_MV_KIRKWOOD) || \
+defined(SOC_MV_LOKIPLUS) || defined(SOC_MV_ORION)
+#define FDT_MARVELL
+#endif
+#endif
+
+static int ofw_fdt_init(ofw_t, void *);
+static phandle_t ofw_fdt_peer(ofw_t, phandle_t);
+static phandle_t ofw_fdt_child(ofw_t, phandle_t);
+static phandle_t ofw_fdt_parent(ofw_t, phandle_t);
+static phandle_t ofw_fdt_instance_to_package(ofw_t, ihandle_t);
+static ssize_t ofw_fdt_getproplen(ofw_t, phandle_t, const char *);
+static ssize_t ofw_fdt_getprop(ofw_t, phandle_t, const char *, void *, size_t);
+static int ofw_fdt_nextprop(ofw_t, phandle_t, const char *, char *, size_t);
+static int ofw_fdt_setprop(ofw_t, phandle_t, const char *, const void *,
+size_t);
+static ssize_t ofw_fdt_canon(ofw_t, const char *, char *, size_t);
+static phandle_t ofw_fdt_finddevice(ofw_t, const char *);
+static ssize_t ofw_fdt_instance_to_path(ofw_t, ihandle_t, char *, size_t);
+static ssize_t ofw_fdt_package_to_path(ofw_t, phandle_t, char *, size_t);
+static int ofw_fdt_interpret(ofw_t, const char *, int, cell_t *);
+
+static ofw_method_t ofw_fdt_methods[] = {
+   OFWMETHOD(ofw_init, ofw_fdt_init),
+   OFWMETHOD(ofw_peer, ofw_fdt_peer),
+   OFWMETHOD(ofw_child,ofw_fdt_child),
+   OFWMETHOD(ofw_parent,   ofw_fdt_parent),
+   OFWMETHOD(ofw_instance_to_package,  ofw_fdt_instance_to_package),
+   OFWMETHOD(ofw_getproplen,   ofw_fdt_getproplen),
+   OFWMETHOD(ofw_getprop,  ofw_fdt_getprop),
+   OFWMETHOD(ofw_nextprop, ofw_fdt_nextprop),
+   OFWMETHOD(ofw_setprop,  ofw_fdt_setprop),
+   OFWMETHOD(ofw_canon,ofw_fdt_canon),
+   OFWMETHOD(ofw_finddevice,   ofw_fdt_finddevice),
+   OFWMETHOD(ofw_instance_to_path, ofw_fdt_instance_to_path),
+   OFWMETHOD(ofw_package_to_path,  ofw_fdt_package_to_path),
+   OFWMETHOD(ofw_interpret,ofw_fdt_interpret),
+   { 0, 0 }
+};
+
+static ofw_def_t ofw_fdt = {
+   OFW_FDT,
+   ofw_fdt_methods,
+   0
+};