From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wes1-so1.wedos.net (wes1-so1.wedos.net [46.28.106.15]) by dpdk.org (Postfix) with ESMTP id C491C558B for ; Tue, 29 Mar 2016 12:34:14 +0200 (CEST) Received: from pcviktorin.fit.vutbr.cz (pcviktorin.fit.vutbr.cz [147.229.13.147]) by wes1-so1.wedos.net (Postfix) with ESMTPSA id 3qZ6Zt2jBtz5DN; Tue, 29 Mar 2016 12:34:14 +0200 (CEST) Date: Tue, 29 Mar 2016 12:34:29 +0200 From: Jan Viktorin To: Jianbo Liu Cc: dev@dpdk.org, Thomas Monjalon , Stephen Hemminger , Keith Wiles , david.marchand@6wind.com, Jerin Jacob , Bruce Richardson Message-ID: <20160329123429.2aa49c8a@pcviktorin.fit.vutbr.cz> In-Reply-To: References: <1458954760-2333-1-git-send-email-viktorin@rehivetech.com> Organization: RehiveTech MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC 0/6] Flattened Device Tree access from DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 10:34:14 -0000 On Mon, 28 Mar 2016 10:43:00 +0800 Jianbo Liu wrote: > On 26 March 2016 at 09:12, Jan Viktorin 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@RehiveTech.com System Architect Web: www.RehiveTech.com RehiveTech Brno, Czech Republic