[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 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at 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.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     > <mailto:sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at 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.