[meta-xilinx] [PATCH 05/20] Add basic Xilinx HDF support

Philip Balister philip at balister.org
Tue Apr 19 04:00:50 PDT 2016


On 04/19/2016 05:48 AM, Nathan Rossi wrote:
> On Tue, Apr 19, 2016 at 7:04 PM, Jason Wu <jason.wu.misc at gmail.com> wrote:
>> Hi Cyril,
>> On 19/04/2016 3:13 AM, Cyril Chemparathy wrote:
>>>
>>> Hi Jason,
>>>
>>> On 4/13/2016 2:23 AM, Jason Wu wrote:
>>> [...]
>>>>>
>>>>> install -d ${D}${PLATFORM_INIT_DIR}
>>>>> for fn in ${PLATFORM_INIT}; do
>>>>> unzip -o ${S}/${HDF} ${fn} -d ${D}${PLATFORM_INIT_DIR}
>>>>> done
>>>
>>>
>>> Unfortunately, the approach of peeling open the HDF file and consuming
>>> its content is problematic.  The HDF file contents are fundamentally in
>>> a tool dependent format, and these contents are meant to be accessed
>>> indirectly through HSI interfaces.
>>
>> Well, I have no problem using HSI to extract the hdf, however, I believe
>> Nathan does not want to have any xilinx tool dependency on the meta-xilinx.
>> Thus, I think this is the best solution for us at this point. I am open to
>> other suggestion on better way of handling without xilinx tool dependency.
> 
> For a task this simple, I really don't see any benefits in using HSI,
> since it is not as if there is any platform processing it is simply
> extracting the pre-generated files. In fact I think there is a
> potential for more problems with using the HSI tools (version
> incompatibilities are the biggest issue) as opposed to simply
> extracting the HDF file, at least for this case.
> 
>>
>> The other issue is if this patch is not accepted, the board support will be
>> missing.
> 
> With the changes discussed previously, I am happy to apply it. I doubt
> there will be a better solution to this problem any time in the
> relatively near future.
> 
>>
>>>
>>> Moving forward, we would like to implement a meta-xilinx-tools layer
>>> with dependencies on Xilinx maintained tools (e.g. HSI) instead of
>>> breaking open the HDF in this fashion.
> 
> I have always been interested in having HSI available for use within
> Yocto/OE/meta-xilinx. The biggest problem has always been that HSI is
> tied to the Xilinx tools which is a really hefty dependency (and the
> implied issues with licensing, EULA, support, platform compatibility,
> version-ing, etc. that come with it) for what is a relatively simple
> task (comparatively to generated bitstreams). Maybe this is something
> Xilinx has a solution for? standalone distribution or open-source HSI?
> definitely would make it considerably easier for project like Yocto/OE
> and others to allow for tool automation.

Adding a Xilinx tool dependency to the layer would also limit the Linux
distros you could do builds on.

Philip

> 
> Regards,
> Nathan
> 
>>
>> I am fine with meta-xilin-tools layer. Any idea when this layer will be
>> ready?
>>
>> Best regards,
>>
>> Jason
>>
>>>
>>> Thanks
>>> -- Cyril.



More information about the meta-xilinx mailing list