| Message ID | 1546157627-45489-2-git-send-email-tien.fong.chee@intel.com |
|---|---|
| State | Superseded |
| Delegated to: | Marek Vasut |
| Headers | show |
| Series | Add support for loading FPGA bitstream | expand |
On 12/30/18 9:13 AM, tien.fong.chee@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@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 ? > + }; > + > +- Examples for booting with full release, enter user mode with full 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.rbf.mkimage"; > }; >
On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote: > On 12/30/18 9:13 AM, tien.fong.chee@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@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. 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. 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. > > > > + }; > > + > > +- Examples for booting with full release, enter user mode with > > full 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.rbf.mkimage"; > > }; > > >
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@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@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. > 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. > 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 ?
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@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@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). >
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@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@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.
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@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@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. >
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@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@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)? 2. What you means with partial loading? partial loading for periph.rbf or core.rbf or both rbfs? 3. Is this partial loading come from common code or already supported? >
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@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@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.
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@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@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. >
On 1/4/19 1:46 AM, Chee, Tien Fong wrote: [...] >>> 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? Does it make sense ?
On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote: > On 1/4/19 1:46 AM, Chee, Tien Fong wrote: > [...] > > > > > > > > > > > > > > 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? > Does it make sense ? Which one you refer, 1 or 2? 1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf) in FAT partition 2. Both periph.rbf and core.rbf in one fitImage in FAT partition >
On 1/4/19 3:22 AM, Chee, Tien Fong wrote: > On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote: >> On 1/4/19 1:46 AM, Chee, Tien Fong wrote: >> [...] >> >>> >>>> >>>>> >>>>> 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? >> Does it make sense ? > Which one you refer, 1 or 2? > 1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf) in > FAT partition > 2. Both periph.rbf and core.rbf in one fitImage in FAT partition One fitImage file containing both .rbf files , stored in whatever storage the user needs.
On Fri, 2019-01-04 at 03:24 +0100, Marek Vasut wrote: > On 1/4/19 3:22 AM, Chee, Tien Fong wrote: > > > > On Fri, 2019-01-04 at 03:10 +0100, Marek Vasut wrote: > > > > > > On 1/4/19 1:46 AM, Chee, Tien Fong wrote: > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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? > > > Does it make sense ? > > Which one you refer, 1 or 2? > > 1. Two files => periph.rbf.mkimage, and fitImage(contains core.rbf) > > in > > FAT partition > > 2. Both periph.rbf and core.rbf in one fitImage in FAT partition > One fitImage file containing both .rbf files , stored in whatever > storage the user needs. Okay, let me explore feasibility of this kind implementation. >
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"; + }; + +- Examples for booting with full release, enter user mode with full 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.rbf.mkimage"; };