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. <niteesh...@gmail.com> 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 >> > <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. > > Thanks, > Niteesh. > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel