[dpdk-dev] [RFC 0/6] Flattened Device Tree access from DPDK

Jan Viktorin viktorin at rehivetech.com
Tue Mar 29 12:34:29 CEST 2016


On Mon, 28 Mar 2016 10:43:00 +0800
Jianbo Liu <jianbo.liu at linaro.org> wrote:

> On 26 March 2016 at 09:12, Jan Viktorin <viktorin at rehivetech.com> wrote:
> > Hello,
> >
> > while extending the DPDK by a kind of platform devices (for the 16.07), an
> > access to the FDT might be necessary (or at least very helpful). This patch
> > series for 16.07 introduces an approach to solve this topic.
> >
> > The API is designed from scratch and there is only the Linux backend for it.
> > The Linux backend can read and traverse the /proc/device-tree structure. The
> > API, however, stays as independent as possible. It is possible to:
> >
> > * open the FDT in a platform independent way (rte_fdt_open/close)
> > * define a path in the FDT in an abstract way (rte_fdt_path)
> > * read strings, 32 and 64 bit values, a binary content (rte_fdt_path_readX)
> > * walk the FDT structure from a selected point (rte_fdt_path_walk)
> >
> > I've included unit tests of the API and of the Linux implemention. Some basic
> > API tests are introduced in the patch 3. Then a simplified device-tree file
> > structure is added together with more tests testing the Linux backend (4,5).
> > I've left those 3 patches separated for now but I think they can be aggregated
> > into a single patch later.
> >
> > Here, I've encounter an issue. The testing FDT files (app/test/linux-fdt) need
> > to be copied (or linked) to the working directory of the _test_ executable. I
> > have no idea, how to integrate such logic into the build system.
> >  
> Why not store FDT files in the code, for example, as a group of binary arrays?
> When test is executed, it firstly creates the files in the working
> directory from those arrays.

Do you know some working solution of this? I am thinking of something
like objcopy of file contents, then link it to the test application.

This about extending the "test framework" a bit. Would somebody else
use such a feature?

Anyway, thank you for this idea.

Jan

> 
> Jianbo



-- 
   Jan Viktorin                  E-mail: Viktorin at RehiveTech.com
   System Architect              Web:    www.RehiveTech.com
   RehiveTech
   Brno, Czech Republic


More information about the dev mailing list