
On 11/23/2015 09:38 AM, Marek Vasut wrote:
On Monday, November 23, 2015 at 03:36:14 PM, Dinh Nguyen wrote:
On 11/20/2015 06:49 AM, Marek Vasut wrote:
On Friday, November 20, 2015 at 12:28:47 AM, Dinh Nguyen wrote:
On 11/19/2015 04:45 PM, Marek Vasut wrote:
On Thursday, November 19, 2015 at 10:35:47 PM, dinguyen@opensource.altera.com
wrote:
From: Dinh Nguyen dinguyen@opensource.altera.com
Update Makefile to build Arria 10.
Signed-off-by: Dinh Nguyen dinguyen@opensource.altera.com
arch/arm/mach-socfpga/Makefile | 7 +++++-- arch/arm/mach-socfpga/arria10/Makefile | 7 +++++++ 2 files changed, 12 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-socfpga/arria10/Makefile
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile index 316b326..0dbe9bb 100644 --- a/arch/arm/mach-socfpga/Makefile +++ b/arch/arm/mach-socfpga/Makefile @@ -6,15 +6,18 @@
# # SPDX-License-Identifier: GPL-2.0+ #
+ifneq ($(CONFIG_TARGET_SOCFPGA_ARRIA10),y)
obj-y += misc.o timer.o reset_manager.o system_manager.o
clock_manager.o \
fpga_manager.o scan_manager.o
obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
# QTS-generated config file wrappers obj-y += wrap_pll_config.o obj-$(CONFIG_SPL_BUILD) += wrap_iocsr_config.o wrap_pinmux_config.o \
wrap_sdram_config.o
+else +obj-y += arria10/
So why exactly does A10 have it's own dedicated dir if most of the code is probably shared between A10 and AV/CV ?
Yes, there are some sharing. But I think that there will be enough differences that will ultimately warrant it's own directory. I think with it's own directory, the Makefile changes stay a bit cleaner. I
Linux doesn't seem to require a separate directory though, does it ? I'm not convinced we need one either.
One of the biggest differences is that the A10's SDRAM support is going to be a bit ugly.
The SDRAM code goes into drivers/ddr/ , no problem.
The main point is that we need to program the FPGA during U-Boot booting up with a ~>10 MB rbf file while being limited to the OCRAM's size. I would like to contain this ugliness in it's own directory.
What's the problem with this ? We already support loading files from storage in SPL, so just compile the FPGA manager into SPL as well and use it.
Ok, let me re-work it all under the c5/a5 directory. Thanks for reviewing.
But you didn't really answer my question -- what is the problem with the FPGA loader in SPL ?
I thought you've already answered your own question. For whatever reason, the downstream A10 is re-doing the FPGA manager just for this purpose.
Dinh