[U-Boot] [PATCH 0/6] Add support for loading FPGA bitstream

From: Tien Fong Chee tien.fong.chee@intel.com
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition: 1. spl_w_dtb-mkpimage.bin mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin
FAT partition contains: Bitstreams ---------- Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
1. ghrd_10as066n2.periph.rbf.mkimage 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
2. ghrd_10as066n2.core.rbf.mkimage mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
1. ghrd_10as066n2.rbf.mkimage (full RBF) mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image ------------ 3. u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches. 1. [U-Boot] [PATCH] misc: fs_loader: Switching private data allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954.html Reviewed-by: Simon Glass s...@chromium.org
2. [U-Boot] [PATCH v2] Add support for initializing MMC https://www.mail-archive.com/u-boot@lists.denx.de/msg310532.html Version 2 under review.
This series is working on top of u-boot.git - http://git.denx.de/u-boot.git .
Marek Vasut (1): ARM: socfpga: Synchronize the configuration for A10 SoCDK
Tien Fong Chee (5): ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10 ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK ARM: dts: socfpga: Add missing SDMMC reset spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
arch/arm/dts/socfpga_arria10.dtsi | 1 + arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 18 + .../include/mach/fpga_manager_arria10.h | 40 ++- arch/arm/mach-socfpga/spl_a10.c | 46 +++- configs/socfpga_arria10_defconfig | 46 ++- .../fpga/altera-socfpga-a10-fpga-mgr.txt | 21 + drivers/fpga/Kconfig | 9 + drivers/fpga/socfpga_arria10.c | 396 +++++++++++++++++++- 8 files changed, 558 insertions(+), 19 deletions(-)

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"; + }; + +- 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 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.
- Is it mkimage -e, which -e==> set entry point to 'ep' (hex)?
No, it is -E => place data outside of the FIT structure
- 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.
- 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.
- 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
- 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?
- 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: [...]
- 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: [...]
- 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: [...]
- 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?
- 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: [...]
- 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?
- 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.

From: Tien Fong Chee tien.fong.chee@intel.com
Add FPGA driver to support program FPGA with FPGA bitstream loading from filesystem. The driver are designed based on generic firmware loader framework. The driver can handle FPGA program operation from loading FPGA bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com --- arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 18 + .../include/mach/fpga_manager_arria10.h | 40 ++- drivers/fpga/Kconfig | 9 + drivers/fpga/socfpga_arria10.c | 396 +++++++++++++++++++- 4 files changed, 451 insertions(+), 12 deletions(-)
diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts index 998d811..ff9835d 100644 --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts @@ -18,6 +18,24 @@ /dts-v1/; #include "socfpga_arria10_socdk.dtsi"
+/ { + chosen { + firmware-loader = &fs_loader0; + }; + + fs_loader0: fs-loader@0 { + u-boot,dm-pre-reloc; + compatible = "u-boot,fs-loader"; + phandlepart = <&mmc 1>; + }; +}; + +&fpga_mgr { + u-boot,dm-pre-reloc; + altr,bitstream = "ghrd_10as066n2.periph.rbf.mkimage"; + altr,bitstream-core = "ghrd_10as066n2.core.rbf.mkimage"; +}; + &mmc { u-boot,dm-pre-reloc; status = "okay"; diff --git a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h index 09d13f6..4acfa7d 100644 --- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h +++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h @@ -1,9 +1,12 @@ /* SPDX-License-Identifier: GPL-2.0 */ /* - * Copyright (C) 2017 Intel Corporation <www.intel.com> + * Copyright (C) 2017-2018 Intel Corporation <www.intel.com> * All rights reserved. */
+#include <altera.h> +#include <image.h> + #ifndef _FPGA_MANAGER_ARRIA10_H_ #define _FPGA_MANAGER_ARRIA10_H_
@@ -51,6 +54,10 @@ #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK BIT(24) #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB 16
+#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED 0xa65c +#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d +#define FPGA_SOCFPGA_A10_RBF_PERIPH 0x0001 +#define FPGA_SOCFPGA_A10_RBF_CORE 0x8001 #ifndef __ASSEMBLY__
struct socfpga_fpga_manager { @@ -88,12 +95,41 @@ struct socfpga_fpga_manager { u32 imgcfg_fifo_status; };
+enum rbf_type { + unknown, + periph_section, + core_section +}; + +enum rbf_security { + invalid, + unencrypted, + encrypted +}; + +struct rbf_info { + enum rbf_type section; + enum rbf_security security; +}; + +struct fpga_loadfs_info { + fpga_fs_info *fpga_fsinfo; + u32 remaining; + u32 offset; + u32 datacrc; + struct rbf_info rbfinfo; + struct image_header header; +}; + /* Functions */ int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size); int fpgamgr_program_finish(void); int is_fpgamgr_user_mode(void); int fpgamgr_wait_early_user_mode(void); - +int is_fpgamgr_early_user_mode(void); +const char *get_fpga_filename(const void *fdt, int *len, u32 rbf_type); +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf, size_t bsize, + u32 offset); #endif /* __ASSEMBLY__ */
#endif /* _FPGA_MANAGER_ARRIA10_H_ */ diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig index 50e9019..c9dcf7b 100644 --- a/drivers/fpga/Kconfig +++ b/drivers/fpga/Kconfig @@ -21,6 +21,15 @@ config FPGA_SOCFPGA
This provides common functionality for Gen5 and Arria10 devices.
+config FPGA_SOCFPGA_A10_CRC_CHECK + bool "Enable CRC cheking on Arria10 FPGA bistream" + default y if FPGA_SOCFPGA + help + Enable the CRC checking on Arria 10 FPGA bitstream + + This provides CRC checking to ensure integrated of Arria 10 FPGA + bitstream is programmed into FPGA. + config FPGA_CYCLON2 bool "Enable Altera FPGA driver for Cyclone II" depends on FPGA_ALTERA diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c index 114dd91..570bd99 100644 --- a/drivers/fpga/socfpga_arria10.c +++ b/drivers/fpga/socfpga_arria10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 /* - * Copyright (C) 2017 Intel Corporation <www.intel.com> + * Copyright (C) 2017-2018 Intel Corporation <www.intel.com> */
#include <asm/io.h> @@ -10,8 +10,11 @@ #include <asm/arch/sdram.h> #include <asm/arch/misc.h> #include <altera.h> +#include <asm/arch/pinmux.h> #include <common.h> +#include <dm/ofnode.h> #include <errno.h> +#include <fs_loader.h> #include <wait_bit.h> #include <watchdog.h>
@@ -64,7 +67,7 @@ static int wait_for_user_mode(void) 1, FPGA_TIMEOUT_MSEC, false); }
-static int is_fpgamgr_early_user_mode(void) +int is_fpgamgr_early_user_mode(void) { return (readl(&fpga_manager_base->imgcfg_stat) & ALT_FPGAMGR_IMGCFG_STAT_F2S_EARLY_USERMODE_SET_MSK) != 0; @@ -447,13 +450,368 @@ int fpgamgr_program_finish(void) return 0; }
+const char *get_fpga_filename(const void *fdt, int *len, u32 rbf_type) +{ + const char *fpga_filename = NULL; + int node_offset; + + fdtdec_find_aliases_for_id(gd->fdt_blob, "fpga_mgr", + COMPAT_ALTERA_SOCFPGA_FPGA0, + &node_offset, 1); + + ofnode fpgamgr_node = offset_to_ofnode(node_offset); + + if (ofnode_valid(fpgamgr_node)) { + if (rbf_type == FPGA_SOCFPGA_A10_RBF_CORE) + fpga_filename = ofnode_read_string(fpgamgr_node, + "altr,bitstream-core"); + else if (rbf_type == FPGA_SOCFPGA_A10_RBF_PERIPH) + fpga_filename = ofnode_read_string(fpgamgr_node, + "altr,bitstream"); + } + + return fpga_filename; +} + +static void get_rbf_image_info(struct rbf_info *rbf, u16 *buffer) +{ + /* + * Magic ID starting at: + * -> 1st dword[15:0] in periph.rbf + * -> 2nd dword[15:0] in core.rbf + * Note: dword == 32 bits + */ + u32 word_reading_max = 2; + u32 i; + + for (i = 0; i < word_reading_max; i++) { + if (*(buffer + i) == FPGA_SOCFPGA_A10_RBF_UNENCRYPTED) { + rbf->security = unencrypted; + } else if (*(buffer + i) == FPGA_SOCFPGA_A10_RBF_ENCRYPTED) { + rbf->security = encrypted; + } else if (*(buffer + i + 1) == + FPGA_SOCFPGA_A10_RBF_UNENCRYPTED) { + rbf->security = unencrypted; + } else if (*(buffer + i + 1) == + FPGA_SOCFPGA_A10_RBF_ENCRYPTED) { + rbf->security = encrypted; + } else { + rbf->security = invalid; + continue; + } + + /* PERIPH RBF(buffer + i + 1), CORE RBF(buffer + i + 2) */ + if (*(buffer + i + 1) == FPGA_SOCFPGA_A10_RBF_PERIPH) { + rbf->section = periph_section; + break; + } else if (*(buffer + i + 1) == FPGA_SOCFPGA_A10_RBF_CORE) { + rbf->section = core_section; + break; + } else if (*(buffer + i + 2) == FPGA_SOCFPGA_A10_RBF_PERIPH) { + rbf->section = periph_section; + break; + } else if (*(buffer + i + 2) == FPGA_SOCFPGA_A10_RBF_CORE) { + rbf->section = core_section; + break; + } + + rbf->section = unknown; + break; + + WATCHDOG_RESET(); + } +} + +#ifdef CONFIG_FS_LOADER +static int first_loading_rbf_to_buffer(struct udevice *dev, + struct fpga_loadfs_info *fpga_loadfs, + u32 *buffer, u32 *buffer_bsize) +{ + u32 *buffer_p_after_header = NULL; + u32 buffersz_after_header = 0; + u32 totalsz_header_rbf = 0; + u32 *buffer_p = (u32 *)*buffer; + struct image_header *header = &(fpga_loadfs->header); + size_t buffer_size = *buffer_bsize; + int ret = 0; + + /* Load mkimage header into buffer */ + ret = request_firmware_into_buf(dev, + fpga_loadfs->fpga_fsinfo->filename, + header, + sizeof(struct image_header), + fpga_loadfs->offset); + if (ret < 0) { + debug("FPGA: Failed to read RBF mkimage header from flash.\n"); + return -ENOENT; + } + + WATCHDOG_RESET(); + + if (!image_check_magic(header)) { + debug("FPGA: Bad Magic Number.\n"); + return -EBADF; + } + + if (!image_check_hcrc(header)) { + debug("FPGA: Bad Header Checksum.\n"); + return -EPERM; + } + + /* Getting RBF data size from mkimage header */ + fpga_loadfs->remaining = image_get_data_size(header); + + /* Calculate total size of both RBF with mkimage header */ + totalsz_header_rbf = fpga_loadfs->remaining + + sizeof(struct image_header); + + /* + * Determine buffer size vs RBF size, and calculating number of + * chunk by chunk transfer is required due to smaller buffer size + * compare to RBF + */ + if (totalsz_header_rbf > buffer_size) { + /* Calculate size of RBF in the buffer */ + buffersz_after_header = + buffer_size - sizeof(struct image_header); + fpga_loadfs->remaining -= buffersz_after_header; + } else { + /* Loading whole RBF into buffer */ + buffer_size = totalsz_header_rbf; + /* Calculate size of RBF in the buffer */ + buffersz_after_header = + buffer_size - sizeof(struct image_header); + fpga_loadfs->remaining = 0; + } + + /* Loading mkimage header and RBFinto buffer */ + ret = request_firmware_into_buf(dev, + fpga_loadfs->fpga_fsinfo->filename, + buffer_p, + buffer_size, + fpga_loadfs->offset); + if (ret < 0) { + debug("FPGA: Failed to read RBF mkimage header and RBF from "); + debug("flash.\n"); + return -ENOENT; + } + + /* + * Getting pointer of RBF starting address where it's + * right after mkimage header + */ + buffer_p_after_header = + (u32 *)((u_char *)buffer_p + sizeof(struct image_header)); + + /* Update next reading RBF offset */ + fpga_loadfs->offset += buffer_size; + + /* Getting info about RBF types */ + get_rbf_image_info(&fpga_loadfs->rbfinfo, (u16 *)buffer_p_after_header); + + /* + * Update the starting addr of RBF to init FPGA & programming RBF + * into FPGA + */ + *buffer = (u32)buffer_p_after_header; + + /* Update the size of RBF to be programmed into FPGA */ + *buffer_bsize = buffersz_after_header; + +#ifdef FPGA_SOCFPGA_A10_CRC_CHECK + fpga_loadfs->datacrc = crc32(fpga_loadfs->datacrc, + (u_char *)buffer_p_after_header, + buffersz_after_header); +#endif + +if (fpga_loadfs->remaining == 0) { +#ifdef FPGA_SOCFPGA_A10_CRC_CHECK + if (fpga_loadfs->datacrc != image_get_dcrc(&(fpga_loadfs->header))) { + debug("FPGA: Bad Data Checksum.\n"); + return -EPERM; + } +#endif +} + return 0; +} + +static int subsequent_loading_rbf_to_buffer(struct udevice *dev, + struct fpga_loadfs_info *fpga_loadfs, + u32 *buffer, u32 *buffer_bsize) +{ + int ret = 0; + u32 *buffer_p = (u32 *)*buffer; + + /* Read the RBF chunk by chunk. */ + if (fpga_loadfs->remaining > *buffer_bsize) { + fpga_loadfs->remaining -= *buffer_bsize; + } else { + *buffer_bsize = fpga_loadfs->remaining; + fpga_loadfs->remaining = 0; + } + + ret = request_firmware_into_buf(dev, + fpga_loadfs->fpga_fsinfo->filename, + buffer_p, + *buffer_bsize, + fpga_loadfs->offset); + if (ret < 0) { + debug("FPGA: Failed to read RBF from flash.\n"); + return -ENOENT; + } + +#ifdef FPGA_SOCFPGA_A10_CRC_CHECK + fpga_loadfs->datacrc = crc32(fpga_loadfs->datacrc, + (unsigned char *)buffer_p, + *buffer_bsize); +#endif + +if (fpga_loadfs->remaining == 0) { +#ifdef FPGA_SOCFPGA_A10_CRC_CHECK + if (fpga_loadfs->datacrc != image_get_dcrc(&(fpga_loadfs->header))) { + debug("FPGA: Bad Data Checksum.\n"); + return -EPERM; + } +#endif +} + + /* Update next reading RBF offset */ + fpga_loadfs->offset += *buffer_bsize; + + return 0; +} + +int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf, size_t bsize, + u32 offset) +{ + struct fpga_loadfs_info fpga_loadfs; + int status = 0; + int ret = 0; + u32 buffer = (u32) buf; + u32 buffer_ori = (u32) buf; + size_t buffer_sizebytes = bsize; + size_t buffer_sizebytes_ori = bsize; + size_t total_sizeof_mkimage = sizeof(struct image_header); + struct udevice *dev; + + ret = uclass_get_device(UCLASS_FS_FIRMWARE_LOADER, 0, &dev); + if (ret) + return ret; + + memset(&fpga_loadfs, 0, sizeof(fpga_loadfs)); + + WATCHDOG_RESET(); + + fpga_loadfs.fpga_fsinfo = fpga_fsinfo; + fpga_loadfs.offset = offset; + + printf("Start to program FPGA ...\n"); + + /* + * Note: Both buffer and buffer_sizebytes values can be altered by + * function below. + */ + ret = first_loading_rbf_to_buffer(dev, &fpga_loadfs, &buffer, + &buffer_sizebytes); + if (ret) + return ret; + + if ((fpga_loadfs.rbfinfo.section == core_section) && + !(is_fpgamgr_early_user_mode() && !is_fpgamgr_user_mode())) { + debug("FPGA : FPGA must be in Early Release mode to program "); + debug("core.\n"); + return 0; + } + + /* Disable all signals from hps peripheral controller to fpga */ + writel(0, &system_manager_base->fpgaintf_en_global); + + /* Disable all axi bridges (hps2fpga, lwhps2fpga & fpga2hps) */ + socfpga_bridges_reset(); + + if (fpga_loadfs.rbfinfo.section == periph_section) { + /* Initialize the FPGA Manager */ + status = fpgamgr_program_init((u32 *)buffer, buffer_sizebytes); + if (status) { + debug("FPGA: Init with periph rbf failed.\n"); + return -EPERM; + } + } + + WATCHDOG_RESET(); + + /* Transfer RBF to FPGA Manager */ + fpgamgr_program_write((void *)buffer, buffer_sizebytes); + + total_sizeof_mkimage += buffer_sizebytes; + + WATCHDOG_RESET(); + + while (fpga_loadfs.remaining) { + ret = subsequent_loading_rbf_to_buffer(dev, + &fpga_loadfs, + &buffer_ori, + &buffer_sizebytes_ori); + + if (ret) + return ret; + + /* Transfer data to FPGA Manager */ + fpgamgr_program_write((void *)buffer_ori, + buffer_sizebytes_ori); + + total_sizeof_mkimage += buffer_sizebytes_ori; + + WATCHDOG_RESET(); + } + + if (fpga_loadfs.rbfinfo.section == periph_section) { + if (fpgamgr_wait_early_user_mode() != -ETIMEDOUT) { + config_pins(gd->fdt_blob, "shared"); + puts("FPGA: Early Release Succeeded.\n"); + } else { + debug("FPGA: Failed to see Early Release.\n"); + return -EIO; + } + + /* For monolithic bitstream */ + if (is_fpgamgr_user_mode()) { + /* Ensure the FPGA entering config done */ + status = fpgamgr_program_finish(); + if (status) + return status; + + config_pins(gd->fdt_blob, "fpga"); + puts("FPGA: Enter user mode.\n"); + } + } else if (fpga_loadfs.rbfinfo.section == core_section) { + /* Ensure the FPGA entering config done */ + status = fpgamgr_program_finish(); + if (status) + return status; + + config_pins(gd->fdt_blob, "fpga"); + puts("FPGA: Enter user mode.\n"); + } else { + debug("Config Error: Unsupported FGPA RBF type.\n"); + return -ENOEXEC; + } + + return (int)total_sizeof_mkimage; +} +#endif + /* - * FPGA Manager to program the FPGA. This is the interface used by FPGA driver. - * Return 0 for sucess, non-zero for error. + * This function is used to load the core RBF from the OCRAM where the location + * of the image is defined in the load property in the FIT image source file + * (.its) */ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) { - int status; + unsigned long status; + struct rbf_info rbfinfo; + + memset(&rbfinfo, 0, sizeof(rbfinfo));
/* disable all signals from hps peripheral controller to fpga */ writel(0, &system_manager_base->fpgaintf_en_global); @@ -461,13 +819,31 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) /* disable all axi bridge (hps2fpga, lwhps2fpga & fpga2hps) */ socfpga_bridges_reset();
- /* Initialize the FPGA Manager */ - status = fpgamgr_program_init((u32 *)rbf_data, rbf_size); - if (status) - return status; + /* Getting info about RBF types */ + get_rbf_image_info(&rbfinfo, (u16 *)rbf_data); + + if (rbfinfo.section == periph_section) { + /* Initialize the FPGA Manager */ + status = fpgamgr_program_init((u32 *)rbf_data, rbf_size); + if (status) + return status; + } + + if ((rbfinfo.section == core_section) && + !(is_fpgamgr_early_user_mode() && !is_fpgamgr_user_mode())) { + debug("FPGA : FPGA must be in Early Release mode to program "); + debug("core.\n"); + return 0; + }
/* Write the RBF data to FPGA Manager */ fpgamgr_program_write(rbf_data, rbf_size);
- return fpgamgr_program_finish(); + status = fpgamgr_program_finish(); + if (status) { + config_pins(gd->fdt_blob, "fpga"); + puts("FPGA: Enter user mode.\n"); + } + + return status; }

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
Add FPGA driver to support program FPGA with FPGA bitstream loading from filesystem. The driver are designed based on generic firmware loader framework. The driver can handle FPGA program operation from loading FPGA bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
What changed from V5 in each of those patches ?

On Sun, 2018-12-30 at 16:45 +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
Add FPGA driver to support program FPGA with FPGA bitstream loading from filesystem. The driver are designed based on generic firmware loader framework. The driver can handle FPGA program operation from loading FPGA bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
What changed from V5 in each of those patches ?
I assume you are saying the v5 i had submmited in 2017.
The major changes i have made are: 1. Stripping of the "fpga loadfs" command support layer on U-Boot console because the DDR would be corrupted if FPGA is reprogrammed. 2. Minor restructure and codes clean up such as understandable name for functions. 3. Using finalized generic firmware loader interface in this driver.

On 1/1/19 4:28 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:45 +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
Add FPGA driver to support program FPGA with FPGA bitstream loading from filesystem. The driver are designed based on generic firmware loader framework. The driver can handle FPGA program operation from loading FPGA bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
What changed from V5 in each of those patches ?
I assume you are saying the v5 i had submmited in 2017.
The major changes i have made are:
- Stripping of the "fpga loadfs" command support layer on U-Boot
console because the DDR would be corrupted if FPGA is reprogrammed. 2. Minor restructure and codes clean up such as understandable name for functions. 3. Using finalized generic firmware loader interface in this driver.
This should be in the changelog.

On Tue, 2019-01-01 at 21:27 +0100, Marek Vasut wrote:
On 1/1/19 4:28 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:45 +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
Add FPGA driver to support program FPGA with FPGA bitstream loading from filesystem. The driver are designed based on generic firmware loader framework. The driver can handle FPGA program operation from loading FPGA bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
What changed from V5 in each of those patches ?
I assume you are saying the v5 i had submmited in 2017.
The major changes i have made are:
- Stripping of the "fpga loadfs" command support layer on U-Boot
console because the DDR would be corrupted if FPGA is reprogrammed. 2. Minor restructure and codes clean up such as understandable name for functions. 3. Using finalized generic firmware loader interface in this driver.
This should be in the changelog.
Okay.

From: Tien Fong Chee tien.fong.chee@intel.com
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com --- configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
+CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y

On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
+CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y

On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.

On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.
I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed?

On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.
I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed?
Please explore this, it'll be beneficial in the long run.

On Thu, 2019-01-03 at 21:15 +0100, Marek Vasut wrote:
On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.
I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed?
Please explore this, it'll be beneficial in the long run.
Okay.

On Thu, 2019-01-03 at 21:15 +0100, Marek Vasut wrote:
On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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
Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
configs/socfpga_arria10_defconfig | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 6ebda81..8158dbb 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,8 +27,16 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y +CONFIG_SPL_FAT_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.
I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed?
Please explore this, it'll be beneficial in the long run.
There is a progress on working to move statically allocating into dynamically allocation https://www.mail-archive.com/u-boot@lists.denx.d e/msg308353.html .
I quickly apply the patch and having minor fixing on it. This indeed reduce the SPL image size, but creating overflow/corruption during runtime. So, the problem is still not enough memory for the SPL.
I think we can add a new SPL_FAT_WRITE config to exclude the fat_write.c from SPL, because most of the time, SPL needs very simple FAT reading. This would help us save 64KB memory space if that's default value for FAT cluster.
What do you think?

On 1/15/19 9:16 AM, Chee, Tien Fong wrote:
On Thu, 2019-01-03 at 21:15 +0100, Marek Vasut wrote:
On 1/3/19 6:36 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:29 +0100, Marek Vasut wrote:
On 1/1/19 4:32 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:47 +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 > > Update the default configuration file to enable the > necessary > functionality > to get the SoCFPGA loadfs driver support. This would enable > the > implementation of programming bitstream into FPGA from MMC. > > Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com > --- > configs/socfpga_arria10_defconfig | 8 ++++++++ > 1 files changed, 8 insertions(+), 0 deletions(-) > > diff --git a/configs/socfpga_arria10_defconfig > b/configs/socfpga_arria10_defconfig > index 6ebda81..8158dbb 100644 > --- a/configs/socfpga_arria10_defconfig > +++ b/configs/socfpga_arria10_defconfig > @@ -27,8 +27,16 @@ > CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" > # CONFIG_EFI_PARTITION is not set > CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" > CONFIG_ENV_IS_IN_MMC=y > +CONFIG_SPL_ENV_SUPPORT=y > CONFIG_SPL_DM=y > CONFIG_SPL_DM_SEQ_ALIAS=y > +CONFIG_SPL_DM_MMC=y > +CONFIG_SPL_MMC_SUPPORT=y > +CONFIG_SPL_EXT_SUPPORT=y > +CONFIG_SPL_FAT_SUPPORT=y > +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y > +CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 This breaks systems with large FAT clusters. Why is this needed for programming the FPGA from MMC ?
This is final tuning in term of getting balance between performance and SPL image size for the socdk devkit. User can change that if they need large FAT cluster in their design, right?
I think it'd rather make sense to fix the FAT driver to avoid statically allocating those massive buffers for big clusters. I think that can be done by allocating those on stack instead ... or mallocating them.
I need to explore 1st as i'm not familiar with FAT driver. Or can we temporary keeping this patch 1st until FAT issue is separately fixed?
Please explore this, it'll be beneficial in the long run.
There is a progress on working to move statically allocating into dynamically allocation https://www.mail-archive.com/u-boot@lists.denx.d e/msg308353.html .
I quickly apply the patch and having minor fixing on it. This indeed reduce the SPL image size, but creating overflow/corruption during runtime. So, the problem is still not enough memory for the SPL.
I think we can add a new SPL_FAT_WRITE config to exclude the fat_write.c from SPL, because most of the time, SPL needs very simple FAT reading. This would help us save 64KB memory space if that's default value for FAT cluster.
What do you think?
Sounds good.

From: Tien Fong Chee tien.fong.chee@intel.com
The SDMMC reset is missing from DT, so the reset manager cannot unreset the SDMMC. Add the missing DT reset entry.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com --- arch/arm/dts/socfpga_arria10.dtsi | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/socfpga_arria10.dtsi b/arch/arm/dts/socfpga_arria10.dtsi index 2c5249c..c11a5c0 100644 --- a/arch/arm/dts/socfpga_arria10.dtsi +++ b/arch/arm/dts/socfpga_arria10.dtsi @@ -660,6 +660,7 @@ fifo-depth = <0x400>; clocks = <&l4_mp_clk>, <&sdmmc_clk>; clock-names = "biu", "ciu"; + resets = <&rst SDMMC_RESET>; status = "disabled"; };

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
The SDMMC reset is missing from DT, so the reset manager cannot unreset the SDMMC. Add the missing DT reset entry.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
arch/arm/dts/socfpga_arria10.dtsi | 1 + 1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/dts/socfpga_arria10.dtsi b/arch/arm/dts/socfpga_arria10.dtsi index 2c5249c..c11a5c0 100644 --- a/arch/arm/dts/socfpga_arria10.dtsi +++ b/arch/arm/dts/socfpga_arria10.dtsi @@ -660,6 +660,7 @@ fifo-depth = <0x400>; clocks = <&l4_mp_clk>, <&sdmmc_clk>; clock-names = "biu", "ciu";
};resets = <&rst SDMMC_RESET>; status = "disabled";
Applied, thanks

From: Tien Fong Chee tien.fong.chee@intel.com
Add support for loading FPGA bitstream to get DDR up running before U-Boot is loaded into DDR. Boot device initialization, generic firmware loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com --- arch/arm/mach-socfpga/spl_a10.c | 46 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c index 3ea64f7..93f5f46 100644 --- a/arch/arm/mach-socfpga/spl_a10.c +++ b/arch/arm/mach-socfpga/spl_a10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2012 Altera Corporation <www.altera.com> + * Copyright (C) 2012-2018 Altera Corporation <www.altera.com> */
#include <common.h> @@ -23,9 +23,14 @@ #include <fdtdec.h> #include <watchdog.h> #include <asm/arch/pinmux.h> +#include <asm/arch/fpga_manager.h> +#include <mmc.h>
DECLARE_GLOBAL_DATA_PTR;
+#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024) +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024 * 1024) + static const struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
@@ -73,6 +78,45 @@ void spl_board_init(void) WATCHDOG_RESET();
arch_early_init_r(); + + /* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */ + if (is_fpgamgr_user_mode()) { + config_pins(gd->fdt_blob, "shared"); + config_pins(gd->fdt_blob, "fpga"); + } else if (!is_fpgamgr_early_user_mode()) { + /* Program IOSSM(early IO release) or full FPGA */ + fpga_fs_info fpga_fsinfo; + int len; + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN); + + fpga_fsinfo.filename = (char *)get_fpga_filename( + gd->fdt_blob, + &len, + FPGA_SOCFPGA_A10_RBF_PERIPH); + + if (fpga_fsinfo.filename) + socfpga_loadfs(&fpga_fsinfo, buf, sizeof(buf), 0); + } + + /* If the IOSSM/full FPGA is already loaded, start DDR */ + if (is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode()) + ddr_calibration_sequence(); + + if (!is_fpgamgr_user_mode()) { + fpga_fs_info fpga_fsinfo; + int len; + + fpga_fsinfo.filename = (char *)get_fpga_filename( + gd->fdt_blob, + &len, + FPGA_SOCFPGA_A10_RBF_CORE); + + if (fpga_fsinfo.filename) + socfpga_loadfs(&fpga_fsinfo, + (const void *)FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR, + (size_t)FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE, + 0); + } }
void board_init_f(ulong dummy)

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
Add support for loading FPGA bitstream to get DDR up running before U-Boot is loaded into DDR. Boot device initialization, generic firmware loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
arch/arm/mach-socfpga/spl_a10.c | 46 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c index 3ea64f7..93f5f46 100644 --- a/arch/arm/mach-socfpga/spl_a10.c +++ b/arch/arm/mach-socfpga/spl_a10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /*
- Copyright (C) 2012 Altera Corporation <www.altera.com>
*/
- Copyright (C) 2012-2018 Altera Corporation <www.altera.com>
#include <common.h> @@ -23,9 +23,14 @@ #include <fdtdec.h> #include <watchdog.h> #include <asm/arch/pinmux.h> +#include <asm/arch/fpga_manager.h> +#include <mmc.h>
DECLARE_GLOBAL_DATA_PTR;
+#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024) +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024 * 1024)
static const struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS;
@@ -73,6 +78,45 @@ void spl_board_init(void) WATCHDOG_RESET();
arch_early_init_r();
- /* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
- if (is_fpgamgr_user_mode()) {
config_pins(gd->fdt_blob, "shared");
config_pins(gd->fdt_blob, "fpga");
What happens if config_pins() fails ? The function returns some return value.
- } else if (!is_fpgamgr_early_user_mode()) {
/* Program IOSSM(early IO release) or full FPGA */
fpga_fs_info fpga_fsinfo;
int len;
char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
fpga_fsinfo.filename = (char *)get_fpga_filename(
Is the cast needed ?
gd->fdt_blob,
&len,
FPGA_SOCFPGA_A10_RBF_PERIPH);
if (fpga_fsinfo.filename)
socfpga_loadfs(&fpga_fsinfo, buf, sizeof(buf), 0);
- }
- /* If the IOSSM/full FPGA is already loaded, start DDR */
- if (is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode())
ddr_calibration_sequence();
- if (!is_fpgamgr_user_mode()) {
fpga_fs_info fpga_fsinfo;
int len;
fpga_fsinfo.filename = (char *)get_fpga_filename(
gd->fdt_blob,
&len,
FPGA_SOCFPGA_A10_RBF_CORE);
if (fpga_fsinfo.filename)
socfpga_loadfs(&fpga_fsinfo,
(const void *)FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR,
(size_t)FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE,
0);
- }
}
void board_init_f(ulong dummy)

On Sun, 2018-12-30 at 16:51 +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
Add support for loading FPGA bitstream to get DDR up running before U-Boot is loaded into DDR. Boot device initialization, generic firmware loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
arch/arm/mach-socfpga/spl_a10.c | 46 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach- socfpga/spl_a10.c index 3ea64f7..93f5f46 100644 --- a/arch/arm/mach-socfpga/spl_a10.c +++ b/arch/arm/mach-socfpga/spl_a10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /*
- * Copyright (C) 2012 Altera Corporation <www.altera.com>
- * Copyright (C) 2012-2018 Altera Corporation <www.altera.com>
*/ #include <common.h> @@ -23,9 +23,14 @@ #include <fdtdec.h> #include <watchdog.h> #include <asm/arch/pinmux.h> +#include <asm/arch/fpga_manager.h> +#include <mmc.h> DECLARE_GLOBAL_DATA_PTR; +#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024) +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024 * 1024)
static const struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; @@ -73,6 +78,45 @@ void spl_board_init(void) WATCHDOG_RESET(); arch_early_init_r();
- /* If the full FPGA is already loaded, ie.from EPCQ,
config fpga pins */
- if (is_fpgamgr_user_mode()) {
config_pins(gd->fdt_blob, "shared");
config_pins(gd->fdt_blob, "fpga");
What happens if config_pins() fails ? The function returns some return value.
There is return value for config_pins, i can add the debug print out for the return value.
- } else if (!is_fpgamgr_early_user_mode()) {
/* Program IOSSM(early IO release) or full FPGA */
fpga_fs_info fpga_fsinfo;
int len;
char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
fpga_fsinfo.filename = (char *)get_fpga_filename(
Is the cast needed ?
there is a warning arch/arm/mach-socfpga/spl_a10.c:109:24: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] fpga_fsinfo.filename = get_fpga_filename(
gd->fdt_blob,
&len,
FPGA_SOCFPGA_A10_R
BF_PERIPH);
if (fpga_fsinfo.filename)
socfpga_loadfs(&fpga_fsinfo, buf,
sizeof(buf), 0);
- }
- /* If the IOSSM/full FPGA is already loaded, start DDR */
- if (is_fpgamgr_early_user_mode() ||
is_fpgamgr_user_mode())
ddr_calibration_sequence();
- if (!is_fpgamgr_user_mode()) {
fpga_fs_info fpga_fsinfo;
int len;
fpga_fsinfo.filename = (char *)get_fpga_filename(
gd->fdt_blob,
&len,
FPGA_SOCFPGA_A10_R
BF_CORE);
if (fpga_fsinfo.filename)
socfpga_loadfs(&fpga_fsinfo,
(const void
*)FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR,
(size_t)FPGA_SOCFGA_A10_RBF_CORE_B
UFFER_SIZE,
0);
- }
} void board_init_f(ulong dummy)

On 1/1/19 4:39 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:51 +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
Add support for loading FPGA bitstream to get DDR up running before U-Boot is loaded into DDR. Boot device initialization, generic firmware loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
arch/arm/mach-socfpga/spl_a10.c | 46 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach- socfpga/spl_a10.c index 3ea64f7..93f5f46 100644 --- a/arch/arm/mach-socfpga/spl_a10.c +++ b/arch/arm/mach-socfpga/spl_a10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /*
- * Copyright (C) 2012 Altera Corporation <www.altera.com>
- * Copyright (C) 2012-2018 Altera Corporation <www.altera.com>
*/ #include <common.h> @@ -23,9 +23,14 @@ #include <fdtdec.h> #include <watchdog.h> #include <asm/arch/pinmux.h> +#include <asm/arch/fpga_manager.h> +#include <mmc.h> DECLARE_GLOBAL_DATA_PTR; +#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024) +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024 * 1024)
static const struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; @@ -73,6 +78,45 @@ void spl_board_init(void) WATCHDOG_RESET(); arch_early_init_r();
- /* If the full FPGA is already loaded, ie.from EPCQ,
config fpga pins */
- if (is_fpgamgr_user_mode()) {
config_pins(gd->fdt_blob, "shared");
config_pins(gd->fdt_blob, "fpga");
What happens if config_pins() fails ? The function returns some return value.
There is return value for config_pins, i can add the debug print out for the return value.
And if the function fails, for whatever reason, what does that mean for the system ? Does the system fail ? I think so, right ?
- } else if (!is_fpgamgr_early_user_mode()) {
/* Program IOSSM(early IO release) or full FPGA */
fpga_fs_info fpga_fsinfo;
int len;
char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
fpga_fsinfo.filename = (char *)get_fpga_filename(
Is the cast needed ?
there is a warning arch/arm/mach-socfpga/spl_a10.c:109:24: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] fpga_fsinfo.filename = get_fpga_filename(
Which tells you that you're forcibly turning a string which the compiler assumes to be constant into one which is not. You're missing const somewhere or you need to remove it from somewhere.

On Tue, 2019-01-01 at 21:31 +0100, Marek Vasut wrote:
On 1/1/19 4:39 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:51 +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
Add support for loading FPGA bitstream to get DDR up running before U-Boot is loaded into DDR. Boot device initialization, generic firmware loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
arch/arm/mach-socfpga/spl_a10.c | 46 ++++++++++++++++++++++++++++++++++++++- 1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach- socfpga/spl_a10.c index 3ea64f7..93f5f46 100644 --- a/arch/arm/mach-socfpga/spl_a10.c +++ b/arch/arm/mach-socfpga/spl_a10.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /*
- * Copyright (C) 2012 Altera Corporation <www.altera.com>
- * Copyright (C) 2012-2018 Altera Corporation <www.altera.com
*/ #include <common.h> @@ -23,9 +23,14 @@ #include <fdtdec.h> #include <watchdog.h> #include <asm/arch/pinmux.h> +#include <asm/arch/fpga_manager.h> +#include <mmc.h> DECLARE_GLOBAL_DATA_PTR; +#define FPGA_SOCFGA_A10_RBF_CORE_LOAD_DDR (1 * 1024) +#define FPGA_SOCFGA_A10_RBF_CORE_BUFFER_SIZE (40 * 1024
static const struct socfpga_system_manager *sysmgr_regs = (struct socfpga_system_manager *)SOCFPGA_SYSMGR_ADDRESS; @@ -73,6 +78,45 @@ void spl_board_init(void) WATCHDOG_RESET(); arch_early_init_r();
- /* If the full FPGA is already loaded, ie.from EPCQ,
config fpga pins */
- if (is_fpgamgr_user_mode()) {
config_pins(gd->fdt_blob, "shared");
config_pins(gd->fdt_blob, "fpga");
What happens if config_pins() fails ? The function returns some return value.
There is return value for config_pins, i can add the debug print out for the return value.
And if the function fails, for whatever reason, what does that mean for the system ? Does the system fail ? I think so, right ?
Unexpected behavior. I can put the hang here or you got better idea?
- } else if (!is_fpgamgr_early_user_mode()) {
/* Program IOSSM(early IO release) or full
FPGA */
fpga_fs_info fpga_fsinfo;
int len;
char buf[16 * 1024]
__aligned(ARCH_DMA_MINALIGN);
fpga_fsinfo.filename = (char
*)get_fpga_filename(
Is the cast needed ?
there is a warning arch/arm/mach-socfpga/spl_a10.c:109:24: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] fpga_fsinfo.filename = get_fpga_filename(
Which tells you that you're forcibly turning a string which the compiler assumes to be constant into one which is not. You're missing const somewhere or you need to remove it from somewhere.
Yes, i can fix it.

From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com --- configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" @@ -10,26 +10,35 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800 CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_DFU_MMC=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y @@ -40,13 +49,30 @@ CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MMC_DW=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
Is this patch needed ? Why ? This enables a whole lot of stuff ....
configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" @@ -10,26 +10,35 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800 CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_DFU_MMC=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y @@ -40,13 +49,30 @@ CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MMC_DW=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y

On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote:
On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
Is this patch needed ? Why ? This enables a whole lot of stuff ....
These settings are mostly syn up from gen5 and our own downstream A10. These settings are mostly required to boot U-Boot and supporting A10 golden system reference design.
configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" @@ -10,26 +10,35 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800 CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma- names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_DFU_MMC=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y @@ -40,13 +49,30 @@ CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MMC_DW=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y

On 1/1/19 4:51 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote:
On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
Is this patch needed ? Why ? This enables a whole lot of stuff ....
These settings are mostly syn up from gen5 and our own downstream A10. These settings are mostly required to boot U-Boot and supporting A10 golden system reference design.
Hmmm, mind you, all the MTD and SPI stuff is not needed for the SDMMC configuration of the kit, which this patch would imply is the target. You want to split this into smaller config changes which enable logical blocks, not everything at once, and document why is each thing needed.
configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000
Why is this increase in malloc area needed ?
CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" @@ -10,26 +10,35 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800 CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma- names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_DFU_MMC=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y @@ -40,13 +49,30 @@ CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MMC_DW=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y
USB and DFU could be enabled separately.

On Tue, 2019-01-01 at 21:35 +0100, Marek Vasut wrote:
On 1/1/19 4:51 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote:
On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
Is this patch needed ? Why ? This enables a whole lot of stuff ....
These settings are mostly syn up from gen5 and our own downstream A10. These settings are mostly required to boot U-Boot and supporting A10 golden system reference design.
Hmmm, mind you, all the MTD and SPI stuff is not needed for the SDMMC configuration of the kit, which this patch would imply is the target. You want to split this into smaller config changes which enable logical blocks, not everything at once, and document why is each thing needed.
I can keep them minimal, enable them when required in separate patch.
configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000
Why is this increase in malloc area needed ?
This is set in the arria10_sdmmc_next, i guess you need this value for your use case? I can revert it if it is no longer required.
CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" @@ -10,26 +10,35 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x800 CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y +CONFIG_CMD_DFU=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma- names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_DFU_MMC=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_EXT_SUPPORT=y @@ -40,13 +49,30 @@ CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y +CONFIG_SYS_I2C_DW=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MTD_PARTITIONS=y +CONFIG_MMC_DW=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_GADGET_DOWNLOAD=y
USB and DFU could be enabled separately.
Okay.

On 1/2/19 9:50 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:35 +0100, Marek Vasut wrote:
On 1/1/19 4:51 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote:
On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Marek Vasut marex@denx.de
Update the default configuration file to enable the necessary functionality the get the kit working. That includes SPL SD/MMC support, USB, and I2C.
Signed-off-by: Marek Vasut marex@denx.de Signed-off-by: Tien Fong Chee tien.fong.chee@intel.com
Is this patch needed ? Why ? This enables a whole lot of stuff ....
These settings are mostly syn up from gen5 and our own downstream A10. These settings are mostly required to boot U-Boot and supporting A10 golden system reference design.
Hmmm, mind you, all the MTD and SPI stuff is not needed for the SDMMC configuration of the kit, which this patch would imply is the target. You want to split this into smaller config changes which enable logical blocks, not everything at once, and document why is each thing needed.
I can keep them minimal, enable them when required in separate patch.
Please do
configs/socfpga_arria10_defconfig | 38 +++++++++++++++++++++++++++++++----- 1 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 8158dbb..4b93321 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -1,7 +1,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x01000040 -CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SYS_MALLOC_F_LEN=0x8000
Why is this increase in malloc area needed ?
This is set in the arria10_sdmmc_next, i guess you need this value for your use case? I can revert it if it is no longer required.
I mean, you're sending a patch, I'd expect you know what it does ? :-)
[...]

On 12/30/18 9:13 AM, tien.fong.chee@intel.com wrote:
From: Tien Fong Chee tien.fong.chee@intel.com
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition:
- spl_w_dtb-mkpimage.bin
mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin
FAT partition contains: Bitstreams
Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
- ghrd_10as066n2.periph.rbf.mkimage
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
- ghrd_10as066n2.core.rbf.mkimage
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
- ghrd_10as066n2.rbf.mkimage (full RBF)
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image
- u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches.
[U-Boot] [PATCH] misc: fs_loader: Switching private data allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954.html Reviewed-by: Simon Glass s...@chromium.org
[U-Boot] [PATCH v2] Add support for initializing MMC https://www.mail-archive.com/u-boot@lists.denx.de/msg310532.html Version 2 under review.
The above should be made into documentation, since cover letters are dropped.

On Sun, 2018-12-30 at 16:44 +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
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition:
- spl_w_dtb-mkpimage.bin
mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl- dtb.bin
FAT partition contains: Bitstreams
Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
- ghrd_10as066n2.periph.rbf.mkimage
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
- ghrd_10as066n2.core.rbf.mkimage
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
- ghrd_10as066n2.rbf.mkimage (full RBF)
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image
- u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches.
- [U-Boot] [PATCH] misc: fs_loader: Switching private data
allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954.html Reviewed-by: Simon Glass s...@chromium.org
- [U-Boot] [PATCH v2] Add support for initializing MMC
https://www.mail-archive.com/u-boot@lists.denx.de/msg310532.html Version 2 under review.
The above should be made into documentation, since cover letters are dropped.
Happy new year Marek.
Yeah, the document would be sent out once the implementation is finalized. Hence, we need your mercy and help to get this done :-P, just kidding.

On 1/1/19 3:52 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:44 +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
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition:
- spl_w_dtb-mkpimage.bin
mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl- dtb.bin
FAT partition contains: Bitstreams
Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
- ghrd_10as066n2.periph.rbf.mkimage
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
- ghrd_10as066n2.core.rbf.mkimage
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
- ghrd_10as066n2.rbf.mkimage (full RBF)
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image
- u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches.
- [U-Boot] [PATCH] misc: fs_loader: Switching private data
allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954.html Reviewed-by: Simon Glass s...@chromium.org
- [U-Boot] [PATCH v2] Add support for initializing MMC
https://www.mail-archive.com/u-boot@lists.denx.de/msg310532.html Version 2 under review.
The above should be made into documentation, since cover letters are dropped.
Happy new year Marek.
Happy New Year to you too.
Yeah, the document would be sent out once the implementation is finalized. Hence, we need your mercy and help to get this done :-P, just kidding.
I hope you can wrap this into V7 .

On Tue, 2019-01-01 at 21:36 +0100, Marek Vasut wrote:
On 1/1/19 3:52 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:44 +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
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition:
- spl_w_dtb-mkpimage.bin
mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl- dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl- dtb.bin
FAT partition contains: Bitstreams
Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
- ghrd_10as066n2.periph.rbf.mkimage
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
- ghrd_10as066n2.core.rbf.mkimage
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
- ghrd_10as066n2.rbf.mkimage (full RBF)
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image
- u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches.
- [U-Boot] [PATCH] misc: fs_loader: Switching private data
allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954. html Reviewed-by: Simon Glass s...@chromium.org
- [U-Boot] [PATCH v2] Add support for initializing MMC
https://www.mail-archive.com/u-boot@lists.denx.de/msg310532. html Version 2 under review.
The above should be made into documentation, since cover letters are dropped.
Happy new year Marek.
Happy New Year to you too.
Yeah, the document would be sent out once the implementation is finalized. Hence, we need your mercy and help to get this done :-P, just kidding.
I hope you can wrap this into V7 .
Sure.

On 1/3/19 6:33 AM, Chee, Tien Fong wrote:
On Tue, 2019-01-01 at 21:36 +0100, Marek Vasut wrote:
On 1/1/19 3:52 AM, Chee, Tien Fong wrote:
On Sun, 2018-12-30 at 16:44 +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
These series of patches enable peripheral bitstream being programmed into FPGA to get the DDR up running. This's also called early IO release, because the peripheral bitstream is only initializing FPGA IOs, PLL, IO48 and DDR.
Once DDR is up running, core bitstream from MMC which contains user FPGA design would be loaded into DDR location. socfpga loadfs would be called to program core bitstream into FPGA and entering user mode.
Lastly, u-boot-dtb.img from MMC FAT partition would be loaded to DDR, and up running from there.
For this whole mechanism to work, the SDMMC flash layout would be designed as shown in below:
RAW partition:
- spl_w_dtb-mkpimage.bin
mkpimage -hv 1 -o spl/spl_w_dtb-mkpimage.bin spl/u-boot-spl- dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl-dtb.bin spl/u-boot-spl- dtb.bin
FAT partition contains: Bitstreams
Early IO release method is recommended for the sake of performance, improve up to 86% compare to full RBF.
- ghrd_10as066n2.periph.rbf.mkimage
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
- ghrd_10as066n2.core.rbf.mkimage
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.core.rbf ghrd_10as066n2.core.rbf.mkimage
OR
- ghrd_10as066n2.rbf.mkimage (full RBF)
mkimage -A arm -T firmware -C none -O u-boot -a 0 -e 0 -n "RBF" -d ghrd_10as066n2.rbf ghrd_10as066n2.rbf.mkimage
U-Boot image
- u-boot-dtb.img
For the testing purpose, these two patches are required to apply 1st before applying this series of patches.
- [U-Boot] [PATCH] misc: fs_loader: Switching private data
allocation to DM auto allocation https://www.mail-archive.com/u-boot@lists.denx.de/msg308954. html Reviewed-by: Simon Glass s...@chromium.org
- [U-Boot] [PATCH v2] Add support for initializing MMC
https://www.mail-archive.com/u-boot@lists.denx.de/msg310532. html Version 2 under review.
The above should be made into documentation, since cover letters are dropped.
Happy new year Marek.
Happy New Year to you too.
Yeah, the document would be sent out once the implementation is finalized. Hence, we need your mercy and help to get this done :-P, just kidding.
I hope you can wrap this into V7 .
Sure.
Thanks
participants (3)
-
Chee, Tien Fong
-
Marek Vasut
-
tien.fong.chee@intel.com