On 01/06/2020 20:55, Niteesh G. S. wrote:
On Fri, May 29, 2020 at 6:49 PM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto: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
> <sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>
> <mailto:sebastian.hu...@embedded-brains.de
<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
