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

[Chee, Tien Fong]

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 ?
Yes, it can be optional if no user design.
>  I think you can try looking at mkimage -E
> , which would allow you to do partial image loading in SPL.
Okay.
>