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

[Chee, Tien Fong <tien.fong.chee@intel.com>]

On Thu, 2019-01-03 at 21:14 +0100, Marek Vasut wrote:
> 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@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@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
Yes, i found it in mkimage.c
> 
> > 
> > 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.
So, you want 2 files periph.rbf.mkimage, and fitImage(contains
core.rbf) or both periph.rbf and core.rbf in one fitImage?
> 
> > 
> > 3. Is this partial loading come from common code or already
> > supported?
> Loading subsets of fitImage is supported in SPL, see mkimage -E
> above.
Okay, i will explore.
>