[U-Boot] [PATCH 1/6] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Marek Vasut]

On 1/3/19 8:28 AM, Chee, Tien Fong wrote:
> On Thu, 2019-01-03 at 06:27 +0100, Marek Vasut wrote:
>> On 1/3/19 6:07 AM, Chee, Tien Fong wrote:
>>>
>>> On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
>>>>
>>>> On 1/1/19 4:10 AM, Chee, Tien Fong wrote:
>>>>>
>>>>>
>>>>> On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
>>>>>>
>>>>>>
>>>>>> On 12/30/18 9:13 AM, tien.fong.chee at intel.com wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>>>>
>>>>>>> This patch adds description on properties about file name
>>>>>>> used
>>>>>>> for
>>>>>>> both
>>>>>>> peripheral bitstream and core bitstream.
>>>>>>>
>>>>>>> Signed-off-by: Tien Fong Chee <tien.fong.chee at intel.com>
>>>>>>> ---
>>>>>>>  .../fpga/altera-socfpga-a10-fpga-mgr.txt           |   21
>>>>>>> ++++++++++++++++++++
>>>>>>>  1 files changed, 21 insertions(+), 0 deletions(-)
>>>>>>>
>>>>>>> diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-
>>>>>>> a10-
>>>>>>> fpga-
>>>>>>> mgr.txt b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>>>>>> fpga-
>>>>>>> mgr.txt
>>>>>>> index 2fd8e7a..4552edc 100644
>>>>>>> --- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>>>>>> fpga-
>>>>>>> mgr.txt
>>>>>>> +++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-
>>>>>>> fpga-
>>>>>>> mgr.txt
>>>>>>> @@ -7,13 +7,34 @@ Required properties:
>>>>>>>                 - The second index is for writing FPGA
>>>>>>> configuration data.
>>>>>>>  - resets     : Phandle and reset specifier for the
>>>>>>> device's
>>>>>>> reset.
>>>>>>>  - clocks     : Clocks used by the device.
>>>>>>> +- altr,bitstream : File name for FPGA peripheral raw
>>>>>>> binary
>>>>>>> which
>>>>>>> is used
>>>>>>> +		   to initialize FPGA IOs, PLL, IO48 and
>>>>>>> DDR.
>>>>>>> +		   or
>>>>>>> +		   File name for full RBF, consist of
>>>>>>> periph
>>>>>>> RBF
>>>>>>> and core RBF
>>>>>>> +- altr,bitstream-core : File name for core RBF which
>>>>>>> contains
>>>>>>> FPGA
>>>>>>> design
>>>>>>> +			which is used to program FPGA CRAM
>>>>>>> and
>>>>>>> ERAM.
>>>>>>>  
>>>>>>>  Example:
>>>>>>>  
>>>>>>> +- Examples for booting with early IO release, enter early
>>>>>>> user
>>>>>>> mode(periph RBF):
>>>>>>> +
>>>>>>> +	fpga_mgr: fpga-mgr at ffd03000 {
>>>>>>> +		compatible = "altr,socfpga-a10-fpga-mgr";
>>>>>>> +		reg = <0xffd03000 0x100
>>>>>>> +		       0xffcfe400 0x20>;
>>>>>>> +		clocks = <&l4_mp_clk>;
>>>>>>> +		resets = <&rst FPGAMGR_RESET>;
>>>>>>> +		altr,bitstream =
>>>>>>> "ghrd_10as066n2.periph.rbf.mkimage";
>>>>>>> +		altr,bitstream-core =
>>>>>>> "ghrd_10as066n2.core.rbf.mkimage";
>>>>>> What is this .mkimage format about ? Is that uImage ? Since
>>>>>> it's
>>>>>> two
>>>>>> files, it could probably be bundled into fitImage instead ?
>>>>>>
>>>>> What is this .mkimage format about ? Is that uImage ?
>>>>> mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n
>>>>> \"RBF\"
>>>>> -d
>>>>>  ghrd_10as066n2.periph.rbf ghrd_10as066n2.periph.rbf.mkimage.
>>>>> Yeah, this is uImage. The reason of using it for appending the
>>>>> header
>>>>> contains file size and CRC checksum to the
>>>>> ghrd_10as066n2.periph.rbf.
>>>>> These both file size and CRC checksum are required in socfpga
>>>>> loadfs
>>>>> driver.
>>>> CRC32 is real weak. fitImage supports all kinds of more fitting
>>>> checksum
>>>> algorithms and more.
>>> Okay.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Since it's two> files, it could probably be bundled into
>>>>> fitImage
>>>>> instead ?
>>>>> I assume you are saying the series fitImage implementation
>>>>> patches
>>>>> as i
>>>>> had previously submitted which contains U-Boot, and FPGA core
>>>>> bitstream
>>>>> in fitImage.
>>>> No, just bundle the bitstream in a fitImage if it's multiple
>>>> files
>>>> and
>>>> if it makes sense.
>>> I need to explore 1st what's already supported in mainstream for
>>> loading bitstream in a fitImage. That's would be good if you have
>>> ideas
>>> and details of implementation to share out.
>>>>
>>>>
>>>>>
>>>>>
>>>>> core bitstream can be bundled into fitImage, with the file
>>>>> name as ghrd_10as066n2.core.rbf, without mkimage, so this
>>>>> bitstream
>>>>> would be loadded into DDR with function fpga load instead of
>>>>> fpga
>>>>> loadfs. ghrd_10as066n2.periph.rbf.mkimage is separate file
>>>>> required
>>>>> for
>>>>> getting DDR up 1st before loading fitImage.
>>>> Does that mean you only need to load one of the files (you can do
>>>> that
>>>> with fitImage too) ? But then, what's the point of specifying
>>>> both in
>>>> the DT if only one is needed ?
>>> Here is the description of the flow based on the previous submitted
>>> series patches for setting up the DDR with
>>> periph.rbf.mkimage(standalone file), then followed by the core.rbf
>>> in
>>> fitImage loading into DDR for programming user design into FPGA.
>>> The
>>> implementation of loading core.rbf in fitImage into DDR is already
>>> supported in the common code, and programming into FPGA through a
>>> function called fpga load(which requires DDR get up running 1st).
>> So the core.rbf is optional ? I think you can try looking at mkimage
>> -E
>> , which would allow you to do partial image loading in SPL.
> 1. Is it mkimage -e, which -e==> set entry point to 'ep' (hex)?

No, it is -E => place data outside of the FIT structure

> 2. What you means with partial loading? partial loading for periph.rbf
> or core.rbf or both rbfs?

That you can only load the relevant image from the fitImage, not the
entire fitImage, which lets you load the core bitstream in SPL.

> 3. Is this partial loading come from common code or already supported?

Loading subsets of fitImage is supported in SPL, see mkimage -E above.

-- 
Best regards,
Marek Vasut