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.c...@intel.com wrote:
>>>>>
>>>>>
>>>>> From: Tien Fong Chee <tien.fong.c...@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.c...@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@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.
--
Best regards,
Marek Vasut
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
