Re: [U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > > ---
> > > >  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?
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > > 
> > > > 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.
> > > 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.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > > ---
> > > >  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 
> > > > + *  Copyright (C) 2012-2018 Altera Corporation  > > > >
> > > >   */
> > > >  
> > > >  #include 
> > > > @@ -23,9 +23,14 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > >  
> > > >  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 ?
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.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This patch adds description on properties about file name used
> > > > for
> > > > both
> > > > peripheral bitstream and core bitstream.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  .../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 = <_mp_clk>;
> > > > +   resets = < 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).
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > 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.
> This should be in the changelog.
Okay.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] ARM: socfpga: Synchronize the configuration for A10 SoCDK

[Chee, Tien Fong]

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.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Marek Vasut 
> > > > 
> > > > 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 
> > > > Signed-off-by: Tien Fong Chee 
> > > 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=0x0140
> > > > -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.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] ARM: socfpga: Synchronize the configuration for A10 SoCDK

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:54 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Marek Vasut 
> > 
> > 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 
> > Signed-off-by: Tien Fong Chee 
> 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=0x0140
> > -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
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:51 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> > ---
> >  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 
> > + *  Copyright (C) 2012-2018 Altera Corporation 
> >   */
> >  
> >  #include 
> > @@ -23,9 +23,14 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >  
> >  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,
> > +   ,
> > +   FPGA_SOCFPGA_A10_R
> > BF_PERIPH);
> > +
> > +   if (fpga_fsinfo.filename)
> > +   socfpga_loadfs(_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,
> > +   ,
> > +   FPGA_SOCFPGA_A10_R
> > BF_CORE);
> > +
> > +   if (fpga_fsinfo.filename)
> > +   socfpga_loadfs(_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)
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/6] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:47 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> > ---
> >  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
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:45 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> 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.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:46 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patch adds description on properties about file name used for
> > both
> > peripheral bitstream and core bitstream.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  .../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 = <_mp_clk>;
> > +   resets = < 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 = <_mp_clk>;
> >     resets = < FPGAMGR_RESET>;
> > +   altr,bitstream = "ghrd_10as066n2.rbf.mkimage";
> >     };
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Sun, 2018-12-30 at 16:44 +0100, Marek Vasut wrote:
> On 12/30/18 9:13 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> > 
> > 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.
> 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.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Add support for initializing MMC

[Chee, Tien Fong]

On Sun, 2018-12-30 at 00:28 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Firmware loader would encounter problem if the MMC is accessed before
> initializing it. This patch would adding the support of probing block
> device and initializing MMC before the MMC is accessed by firmware
> loader.
> 
> Signed-off-by: Tien Fong Chee 
> 
> ---
> Changes in v2:
> - Initializing MMC through probing the blk device
Please ignore this patch, just realized missing a line status checking
code. I would resend another patch.
> ---
>  drivers/misc/fs_loader.c | 32 
>  1 file changed, 32 insertions(+)
> 
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 57a14a3..d981b5a 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -252,6 +253,37 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>  
>  static int fs_loader_probe(struct udevice *dev)
>  {
> +#if defined(CONFIG_DM_MMC) && defined(CONFIG_BLK)
> + int ret;
> + struct device_platdata *plat = dev->platdata;
> +
> + ret = mmc_initialize(NULL);
> + if (ret) {
> + debug("MMC: could not initialize mmc. error: %d\n",
> ret);
> +
> + return ret;
> + }
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node = ofnode_get_by_phandle(plat-
> >phandlepart.phandle);
> +
> + struct udevice *mmc_dev = NULL;
> +
> + ret = device_get_global_by_ofnode(node, _dev);
> + if (!ret) {
> + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> + struct udevice *dev;
> +
> + if (blk_get_from_parent(mmc->dev, ))
> + {
> + debug("MMC: No block device: %d\n",
> + ret);
> +
> + return ret;
> + }
> + }
> + }
> +#endif
>   return 0;
>  };
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for initializing MMC

[Chee, Tien Fong]

On Sat, 2018-12-22 at 13:51 -0700, Simon Glass wrote:
> Hi Tien,
> 
> On Fri, 21 Dec 2018 at 10:50, Chee, Tien Fong  om> wrote:
> > 
> > 
> > On Fri, 2018-12-21 at 10:16 -0700, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On Fri, 21 Dec 2018 at 01:25, Chee, Tien Fong  > > el.c
> > > om> wrote:
> > > > 
> > > > 
> > > > 
> > > > On Fri, 2018-12-14 at 14:53 +0800, tien.fong.c...@intel.com
> > > > wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > Firmware loader would encounter problem if the MMC is
> > > > > accessed
> > > > > before
> > > > > initializing it. This patch would adding the support of
> > > > > initializing
> > > > > MMC before the MMC is accessed by firmware loader.
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > ---
> > > > >  drivers/misc/fs_loader.c |   31
> > > > > +++
> > > > >  1 files changed, 31 insertions(+), 0 deletions(-)
> > > > > 
> > > > Any comment for this patch?
> > > This should not be needed with CONFIG_DM_MMC enabled as it should
> > > be
> > > enough to probe the mmc device. Is that right?
> > No, CONFIG_DM_MMC is required, otherwise compiler would tell you
> > error.
> > This whole mechanism is always developed in DM context.
> > What's your concern? You want me to add CONFIG_DM_MMC or replace
> > with
> > CONFIG_MMC? or You want to improve the document?
> Well, mmc_blk_probe() calls mmc_init() on the device. So instead of
> the code you have, would it be possible to probe the blk device? You
> can use device_find_first_child() for that. Perhaps write a function
> in blk.h which probes the first block device for a parent?
Yeah, sure. Let me find out more info.
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for initializing MMC

[Chee, Tien Fong]

On Fri, 2018-12-21 at 10:16 -0700, Simon Glass wrote:
> Hi,
> 
> On Fri, 21 Dec 2018 at 01:25, Chee, Tien Fong  om> wrote:
> > 
> > 
> > On Fri, 2018-12-14 at 14:53 +0800, tien.fong.c...@intel.com wrote:
> > > 
> > > From: Tien Fong Chee 
> > > 
> > > Firmware loader would encounter problem if the MMC is accessed
> > > before
> > > initializing it. This patch would adding the support of
> > > initializing
> > > MMC before the MMC is accessed by firmware loader.
> > > 
> > > Signed-off-by: Tien Fong Chee 
> > > ---
> > >  drivers/misc/fs_loader.c |   31 +++
> > >  1 files changed, 31 insertions(+), 0 deletions(-)
> > > 
> > Any comment for this patch?
> This should not be needed with CONFIG_DM_MMC enabled as it should be
> enough to probe the mmc device. Is that right?
No, CONFIG_DM_MMC is required, otherwise compiler would tell you error.
This whole mechanism is always developed in DM context.
What's your concern? You want me to add CONFIG_DM_MMC or replace with
CONFIG_MMC? or You want to improve the document?
> 
> Regards,
> Simon
> 
> > 
> > 
> > > 
> > > diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> > > index 57a14a3..744fa46 100644
> > > --- a/drivers/misc/fs_loader.c
> > > +++ b/drivers/misc/fs_loader.c
> > > @@ -12,6 +12,7 @@
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > > 
> > >  DECLARE_GLOBAL_DATA_PTR;
> > > @@ -252,6 +253,36 @@ static int
> > > fs_loader_ofdata_to_platdata(struct
> > > udevice *dev)
> > > 
> > >  static int fs_loader_probe(struct udevice *dev)
> > >  {
> > > +#ifdef CONFIG_MMC
> > > + int ret;
> > > + struct device_platdata *plat = dev->platdata;
> > > +
> > > + ret = mmc_initialize(NULL);
> > > + if (ret) {
> > > + debug("MMC: could not initialize mmc. error: %d\n",
> > > ret);
> > > +
> > > + return ret;
> > > + }
> > > +
> > > + if (plat->phandlepart.phandle) {
> > > + ofnode node = ofnode_get_by_phandle(plat-
> > > > 
> > > > phandlepart.phandle);
> > > +
> > > + struct udevice *mmc_dev = NULL;
> > > +
> > > + ret = device_get_global_by_ofnode(node, _dev);
> > > + if (!ret) {
> > > + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> > > +
> > > + ret = mmc_init(mmc);
> > > + if (ret) {
> > > + debug("MMC: mmc init failed with
> > > error: %d\n",
> > > + ret);
> > > +
> > > + return ret;
> > > + }
> > > + }
> > > + }
> > > +#endif
> > >   return 0;
> > >  };
> > > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for initializing MMC

[Chee, Tien Fong]

On Fri, 2018-12-14 at 14:53 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Firmware loader would encounter problem if the MMC is accessed before
> initializing it. This patch would adding the support of initializing
> MMC before the MMC is accessed by firmware loader.
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  drivers/misc/fs_loader.c |   31 +++
>  1 files changed, 31 insertions(+), 0 deletions(-)
> 
Any comment for this patch?

> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 57a14a3..744fa46 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -252,6 +253,36 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>  
>  static int fs_loader_probe(struct udevice *dev)
>  {
> +#ifdef CONFIG_MMC
> + int ret;
> + struct device_platdata *plat = dev->platdata;
> +
> + ret = mmc_initialize(NULL);
> + if (ret) {
> + debug("MMC: could not initialize mmc. error: %d\n",
> ret);
> +
> + return ret;
> + }
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node = ofnode_get_by_phandle(plat-
> >phandlepart.phandle);
> +
> + struct udevice *mmc_dev = NULL;
> +
> + ret = device_get_global_by_ofnode(node, _dev);
> + if (!ret) {
> + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> +
> + ret = mmc_init(mmc);
> + if (ret) {
> + debug("MMC: mmc init failed with
> error: %d\n",
> + ret);
> +
> + return ret;
> + }
> + }
> + }
> +#endif
>   return 0;
>  };
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Wed, 2018-11-28 at 18:55 +0100, Marek Vasut wrote:
> On 11/28/2018 05:17 PM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-28 at 16:10 +0100, Marek Vasut wrote:
> > > 
> > > On 11/28/2018 03:49 PM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Tue, 2018-11-27 at 13:07 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/27/2018 09:45 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2018-11-26 at 12:15 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/26/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > > > 
> > > > > > > > > > > > This patch adds description on properties about
> > > > > > > > > > > > file
> > > > > > > > > > > > name
> > > > > > > > > > > > used
> > > > > > > > > > > > for
> > > > > > > > > > > > both
> > > > > > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > > > > > > 
> > > > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > > > ntel
> > > > > > > > > > > > .com
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > ---
> > > > > > > > > > > >  .../fpga/altera-socfpga-a10-fpga-
> > > > > > > > > > > > mgr.txt   |6
> > > > > > > > > > > > ++
> > > > > > > > > > > >  1 files changed, 6 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-

Re: [U-Boot] [PATCH] Add support for initializing MMC

[Chee, Tien Fong]

On Thu, 2018-12-13 at 23:32 +0800, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee 
> 
> Firmware loader would encounter problem if the MMC is accessed before
> initializing it. This patch would adding the support of initializing
> MMC before the MMC is accessed by firmware loader.
> 
> Signed-off-by: Tien Fong Chee 
> ---
>  drivers/misc/fs_loader.c |   33 -
>  1 files changed, 32 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> index 57a14a3..675f625 100644
> --- a/drivers/misc/fs_loader.c
> +++ b/drivers/misc/fs_loader.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -221,6 +222,7 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>  {
>   const char *fs_loader_path;
>   u32 phandlepart[2];
> + struct device_platdata *plat = NULL;
>  
>   fs_loader_path = ofnode_get_chosen_prop("firmware-loader");
>  
> @@ -229,7 +231,6 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>  
>   fs_loader_node = ofnode_path(fs_loader_path);
>   if (ofnode_valid(fs_loader_node)) {
> - struct device_platdata *plat;
>   plat = dev->platdata;
>  
>   if (!ofnode_read_u32_array(fs_loader_node,
> @@ -247,6 +248,36 @@ static int fs_loader_ofdata_to_platdata(struct
> udevice *dev)
>   }
>   }
>  
I just realized this portion of codes should be moved to polling
function. I will send out another patch tomorrow.
> +#ifdef CONFIG_MMC
> + int ret;
> +
> + ret = mmc_initialize(NULL);
> + if (ret) {
> + debug("MMC: could not initialize mmc. error: %d\n",
> ret);
> +
> + return ret;
> + }
> +
> + if (plat->phandlepart.phandle) {
> + ofnode node = ofnode_get_by_phandle(plat-
> >phandlepart.phandle);
> +
> + struct udevice *mmc_dev = NULL;
> +
> + ret = device_get_global_by_ofnode(node, _dev);
> + if (!ret) {
> + struct mmc *mmc = mmc_get_mmc_dev(mmc_dev);
> +
> + ret = mmc_init(mmc);
> + if (ret) {
> + debug("MMC: mmc init failed with
> error: %d\n",
> + ret);
> +
> + return ret;
> + }
> + }
> + }
> +#endif
> +
>   return 0;
>  }
>  
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Wed, 2018-11-28 at 16:10 +0100, Marek Vasut wrote:
> On 11/28/2018 03:49 PM, Chee, Tien Fong wrote:
> > 
> > On Tue, 2018-11-27 at 13:07 +0100, Marek Vasut wrote:
> > > 
> > > On 11/27/2018 09:45 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Mon, 2018-11-26 at 12:15 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/26/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > This patch adds description on properties about
> > > > > > > > > > file
> > > > > > > > > > name
> > > > > > > > > > used
> > > > > > > > > > for
> > > > > > > > > > both
> > > > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > >  .../fpga/altera-socfpga-a10-fpga-
> > > > > > > > > > mgr.txt   |6
> > > > > > > > > > ++
> > > > > > > > > >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA
> > > > > > > &g

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

[Chee, Tien Fong]

On Wed, 2018-11-28 at 16:10 +0100, Marek Vasut wrote:
> On 11/28/2018 03:49 PM, Chee, Tien Fong wrote:
> > 
> > On Tue, 2018-11-27 at 13:07 +0100, Marek Vasut wrote:
> > > 
> > > On 11/27/2018 09:45 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Mon, 2018-11-26 at 12:15 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/26/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > This patch adds description on properties about
> > > > > > > > > > file
> > > > > > > > > > name
> > > > > > > > > > used
> > > > > > > > > > for
> > > > > > > > > > both
> > > > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > >  .../fpga/altera-socfpga-a10-fpga-
> > > > > > > > > > mgr.txt   |6
> > > > > > > > > > ++
> > > > > > > > > >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA
> > > > > > > &g

Re: [U-Boot] [PATCH 2/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Tue, 2018-11-27 at 13:08 +0100, Marek Vasut wrote:
> On 11/27/2018 09:54 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-11-26 at 12:18 +0100, Marek Vasut wrote:
> > > 
> > > On 11/26/2018 11:09 AM, Chee, Tien Fong wrote:
> > > [...]
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > diff --git a/drivers/fpga/Kconfig
> > > > > > > > b/drivers/fpga/Kconfig
> > > > > > > > index 50e9019..06a8204 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 CHECK_FPGA_DATA_CRC
> > > > > > > config FPGA_SOCFPGA_A10_CRC_CHECK
> > > > > > > 
> > > > > > > What is this for and why shouldn't this be ON by default
> > > > > > > ?
> > > > > > Both periph.rbf or full.rbf are wrapped with mkimage. So,
> > > > > > this
> > > > > > CRC
> > > > > > checking can be used to check the integrity of the loading
> > > > > > bitstream
> > > > > > data against checksum from mkimage. It is off for the sake
> > > > > > of
> > > > > > performance.
> > > > > Is there a measurable performance degradation ? I presume
> > > > > that's
> > > > > because
> > > > > caches are disabled at that point, yes? Enable caches and see
> > > > > if
> > > > > that
> > > > > helps.
> > > > Just logical sense, performance sure getting degraded,
> > > > especially
> > > > loading full rbf, but may be not that obvious for periph.rbf
> > > > because of
> > > > very small size, i can try to measure. If not much difference,
> > > > i
> > > > can
> > > > enable checking in default.
> > > Hard numbers are the only relevant argument here, please measure.
> > > And try it with caches enabled as much as possible, you want
> > > users to
> > > boot fast. Arria10 is particularly annoyingly slow at booting.
> > sure.
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +   bool "Enable CRC cheking on Arria10 FPGA
> > > > > > > > bistream"
> > > > > > > > +   depends on FPGA_SOCFPGA
> > > > > > > > +   help
> > > > > > > > +    Say Y here to 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
> > > >

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

[Chee, Tien Fong]

On Tue, 2018-11-27 at 13:07 +0100, Marek Vasut wrote:
> On 11/27/2018 09:45 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-11-26 at 12:15 +0100, Marek Vasut wrote:
> > > 
> > > On 11/26/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee 
> > > > > > > > 
> > > > > > > > This patch adds description on properties about file
> > > > > > > > name
> > > > > > > > used
> > > > > > > > for
> > > > > > > > both
> > > > > > > > peripheral bitstream and core bitstream.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > >
> > > > > > > > ---
> > > > > > > >  .../fpga/altera-socfpga-a10-fpga-
> > > > > > > > mgr.txt   |6
> > > > > > > > ++
> > > > > > > >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA
> > > > > > > > peripheral
> > > > > > > > raw
> > > > > > > > binary
> > > > > > > > which is used
> > > > > > > > +     to initialize FPGA IOs, PLL,
> > > > > > > > IO48
> > > > > > > > and
> > > > > > > > DDR.
> > > > > > > > +- altr,bitstream_core : File name for core raw binary
> > > > > > > > which
> > > > > > > > contains FPGA design
> > > > > > > > +   which is used to program FPGA
> > > > > > > > CRAM
> > > > > > > > and
> > > > > > > > ERAM.
> > > > > > > bitstream- instead of bitstream_
> > > > > > Noted.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > btw can we get something that works with full bitstream
> > > > > > > too ?
> > > > > > This patchset actually support the full bitstream too,
> > > > > > unfortunately it
> > > > > > is blocked by hardware MPFE issue. The patchs

Re: [U-Boot] [PATCH 4/9] ARM: socfpga: Bundle U-Boot fitImage into SFP on Arria10

[Chee, Tien Fong]

On Tue, 2018-11-27 at 13:09 +0100, Marek Vasut wrote:
> On 11/27/2018 10:00 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-11-26 at 12:22 +0100, Marek Vasut wrote:
> > > 
> > > On 11/26/2018 11:30 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Fri, 2018-11-23 at 13:40 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/23/2018 10:54 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee 
> > > > > > > Did you change Author:ship of the patch ?
> > > > > I believe you did, so please fix that.
> > > > Very sorry. I din't realize the author name was changed.
> > > Please be careful next time.
> > Sure.
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Bundle U-Boot fitImage containing U-Boot and FPGA
> > > > > > > > bitstream
> > > > > > > > into
> > > > > > > > the
> > > > > > > > u-boot-with-spl.sfp on Arria10. This lets U-Boot
> > > > > > > > operate in
> > > > > > > > a
> > > > > > > > very
> > > > > > > > similar fashion to Gen5, where the U-Boot binary got
> > > > > > > > loaded
> > > > > > > > by
> > > > > > > > the
> > > > > > > > SPL from a uImage concatenated at the end of the SPL
> > > > > > > > SFP
> > > > > > > > image.
> > > > > > > > On
> > > > > > > > Gen10, the U-Boot is in fitImage which contains the
> > > > > > > > FPGA
> > > > > > > > bitstream
> > > > > > > > as well. In this case, the SPL can load the FPGA
> > > > > > > > bitstream
> > > > > > > > first
> > > > > > > > and
> > > > > > > > load the U-Boot afterward in the same manner. This is
> > > > > > > > nonetheless a
> > > > > > > > stopgap measure until there is a proper firmware loader
> > > > > > > > in
> > > > > > > > U-
> > > > > > > > Boot.
> > > > > > > Right, this is a stopgap measure until FW loader is
> > > > > > > present.
> > > > > > > Why
> > > > > > > is
> > > > > > > this
> > > > > > > patch needed at all in this series ?
> > > > > > This patch is cherry picked from the sdmmc_next custodian,
> > > > > > so
> > > > > > this
> > > > > > patch is required for generating FIT image. I can remove
> > > > > > the
> > > > > > stopgap
> > > > > > comment to avoid confusing.
> > > > > But why is this patch needed at all ? You use the firmware
> > > > > loader
> > > > > to
> > > > > load the FPGA bitstream. Where does the fitImage come into
> > > > > play ?
> > > > > 
> > > > > The fitImage was used to circumvent the missing FW loader,
> > > > > when I
> > > > > needed
> > > > > to load multiple files (bitstream and u-boot binary). Now
> > > > > there
> > > > > is no
> > > > > such requirement anymore, so the entire fitImage machinery is
> > > > > probably
> > > > > not needed ?
> > > > Loading issue is not the reason we choose the fitImage. We
> > > > choose
> > > > it
> > > > because it allows more flexibility in handling various type
> > > > images,
> > > > especially it allows user more choices to enhance integrity and
> > > > security protection.
> > > Do you need to load multiple images at all ? Do you need the
> > > extra
> > > flexibility or does it only bloat and slow down the boot process
> > > for
> > > no
> > > benefit at all? If a user needs it, they can enable it, but do we
> > > need
> > > it by default ?
> > Okay, then we add in the fitImage support and let user to enable
> > it.
> > So, without CONFIG_SPL_FIT is defined, then the boot process would
> > be
> > with individual files such as u-boot-dtb.img instead of u-boot.itb.
> Yes, so all these fitImage patches can be dropped for now ?
This patch can be dropped. But i don't know it is good idea to reserve
the patch 5-8, this would be easier for user to enable CONFIG_SPL_FIT
in future.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/9] ARM: socfpga: Bundle U-Boot fitImage into SFP on Arria10

[Chee, Tien Fong]

On Mon, 2018-11-26 at 12:22 +0100, Marek Vasut wrote:
> On 11/26/2018 11:30 AM, Chee, Tien Fong wrote:
> > 
> > On Fri, 2018-11-23 at 13:40 +0100, Marek Vasut wrote:
> > > 
> > > On 11/23/2018 10:54 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > Did you change Author:ship of the patch ?
> > > I believe you did, so please fix that.
> > Very sorry. I din't realize the author name was changed.
> Please be careful next time.
Sure.
> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Bundle U-Boot fitImage containing U-Boot and FPGA bitstream
> > > > > > into
> > > > > > the
> > > > > > u-boot-with-spl.sfp on Arria10. This lets U-Boot operate in
> > > > > > a
> > > > > > very
> > > > > > similar fashion to Gen5, where the U-Boot binary got loaded
> > > > > > by
> > > > > > the
> > > > > > SPL from a uImage concatenated at the end of the SPL SFP
> > > > > > image.
> > > > > > On
> > > > > > Gen10, the U-Boot is in fitImage which contains the FPGA
> > > > > > bitstream
> > > > > > as well. In this case, the SPL can load the FPGA bitstream
> > > > > > first
> > > > > > and
> > > > > > load the U-Boot afterward in the same manner. This is
> > > > > > nonetheless a
> > > > > > stopgap measure until there is a proper firmware loader in
> > > > > > U-
> > > > > > Boot.
> > > > > Right, this is a stopgap measure until FW loader is present.
> > > > > Why
> > > > > is
> > > > > this
> > > > > patch needed at all in this series ?
> > > > This patch is cherry picked from the sdmmc_next custodian, so
> > > > this
> > > > patch is required for generating FIT image. I can remove the
> > > > stopgap
> > > > comment to avoid confusing.
> > > But why is this patch needed at all ? You use the firmware loader
> > > to
> > > load the FPGA bitstream. Where does the fitImage come into play ?
> > > 
> > > The fitImage was used to circumvent the missing FW loader, when I
> > > needed
> > > to load multiple files (bitstream and u-boot binary). Now there
> > > is no
> > > such requirement anymore, so the entire fitImage machinery is
> > > probably
> > > not needed ?
> > Loading issue is not the reason we choose the fitImage. We choose
> > it
> > because it allows more flexibility in handling various type images,
> > especially it allows user more choices to enhance integrity and
> > security protection.
> Do you need to load multiple images at all ? Do you need the extra
> flexibility or does it only bloat and slow down the boot process for
> no
> benefit at all? If a user needs it, they can enable it, but do we
> need
> it by default ?
Okay, then we add in the fitImage support and let user to enable it.
So, without CONFIG_SPL_FIT is defined, then the boot process would be
with individual files such as u-boot-dtb.img instead of u-boot.itb.
> 
> > 
> > Although we plan to use fitImage as our default implementation, but
> > this series of patches are still allow fw loading individual
> > bitstream
> > image in filesystem partition. So, it is up to user to made the
> > choice.
> Right, so is the fitImage needed at all ?
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs

[Chee, Tien Fong]

On Mon, 2018-11-26 at 12:20 +0100, Marek Vasut wrote:
> On 11/26/2018 11:10 AM, Chee, Tien Fong wrote:
> > 
> > On Fri, 2018-11-23 at 13:31 +0100, Marek Vasut wrote:
> > > 
> > > On 11/23/2018 10:51 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-11-21 at 15:19 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > 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 
> > > > > > ---
> > > > > >  arch/arm/mach-socfpga/spl_a10.c |   49
> > > > > > ++-
> > > > > >  common/spl/spl_mmc.c|2 +-
> > > > > >  include/mmc.h   |1 +
> > > > > >  3 files changed, 50 insertions(+), 2 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/spl_a10.c
> > > > > > index 3ea64f7..67a4fac 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 
> > > > > > + *  Copyright (C) 2012-2018 Altera Corporation  > > > > > .com
> > > > > > > 
> > > > > > > 
> > > > > >   */
> > > > > >  
> > > > > >  #include 
> > > > > > @@ -23,6 +23,10 @@
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +#define RBF0
> > > > > >  
> > > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > >  
> > > > > > @@ -73,6 +77,49 @@ 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;
> > > > > > +   char buf[16 * 1024]
> > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > +   struct spl_boot_device bootdev;
> > > > > > +   int len = 0;
> > > > > > +
> > > > > > +   bootdev.boot_device = spl_boot_device();
> > > > > > +
> > > > > > +   /* Init MMC driver before reading FPGA
> > > > > > bitstream
> > > > > > from flash */
> > > > > > +   if (bootdev.boot_device ==
> > > > > > BOOT_DEVICE_MMC1) {
> > > > > > +   struct mmc *mmc = NULL;
> > > > > > +   int err = 0;
> > > > > > +
> > > > > > +   err = spl_mmc_find_device(,
> > > > > > bootdev.boot_device);
> > > > > > +   if (err)
> > > > > > +   return;
> > > > > > +
> > > > > > +   err = mmc_init(mmc);
> > > > > I thought all this backend specific stuff would be hidden in
> > > > > the
> > > > > FW
> > > > > loader.
> > > > The backend supported by FW loader is up to generic file system
> > > > interface layer. flash driver init is expected done by SPL/U-
> > > > Boot
> > > > common init sequence framwork or user. Unfortunately, fw loader
> > > > need to
> > > > access flash before init sequence.
> > > This is actually accessing eMMC though , not flash . If we need
> > > this
> > > huge boilerplate code every time we use the FW loader, than the
> > > FW
> > > loader needs fixing. I can understand the spl_boot_device() being
> > > outside of the FW loader, but not the mmc_init() and co.
> > I can explore the posibility of adding the flash int mechanism into
> > the
> > fm loader probe function.
> What do you mean by "flash int" ? Note that we're talking about eMMC
> here, not flash. Unless you mean "backend init" by all that, in which
> case that'd only make sense, thanks.
I means backend init such as MMC, and NAND driver init.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Mon, 2018-11-26 at 12:18 +0100, Marek Vasut wrote:
> On 11/26/2018 11:09 AM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > > > index 50e9019..06a8204 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 CHECK_FPGA_DATA_CRC
> > > > > config FPGA_SOCFPGA_A10_CRC_CHECK
> > > > > 
> > > > > What is this for and why shouldn't this be ON by default ?
> > > > Both periph.rbf or full.rbf are wrapped with mkimage. So, this
> > > > CRC
> > > > checking can be used to check the integrity of the loading
> > > > bitstream
> > > > data against checksum from mkimage. It is off for the sake of
> > > > performance.
> > > Is there a measurable performance degradation ? I presume that's
> > > because
> > > caches are disabled at that point, yes? Enable caches and see if
> > > that
> > > helps.
> > Just logical sense, performance sure getting degraded, especially
> > loading full rbf, but may be not that obvious for periph.rbf
> > because of
> > very small size, i can try to measure. If not much difference, i
> > can
> > enable checking in default.
> Hard numbers are the only relevant argument here, please measure.
> And try it with caches enabled as much as possible, you want users to
> boot fast. Arria10 is particularly annoyingly slow at booting.
sure.
> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > +   bool "Enable CRC cheking on Arria10 FPGA bistream"
> > > > > > +   depends on FPGA_SOCFPGA
> > > > > > +   help
> > > > > > +    Say Y here to 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..d9ad237 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 
> > > > > > + * Copyright (C) 2017-2018 Intel Corporation  > > > > > m>
> > > > > >   */
> > > > > >  
> > > > > >  #include 
> > > > > > @@ -10,8 +10,10 @@
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > > +#include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > > +#include 
> > > > > >  #include 
> > > > > >  #include 
> > > > > >  
> > > > > > @@ -21,6 +23,10 @@
> > > > > >  #define COMPRESSION_OFFSET 229
> > > > > >  #define FPGA_TIMEOUT_MSEC  1000  /* timeout in ms */
> > > > > >  #define FPGA_TIMEOUT_CNT   0x100
> > > > > > +#define RBF_UNENCRYPTED0xa65c
> > > > > > +#define RBF_ENCRYPTED  0xa65d
> > > > > > +#define ARRIA10RBF_PERIPH  0x0001
> > > > > > +#define ARRIA10RBF_CORE0x8001
> > > > > This looks awfully similar to the PERIPH_RBF and CORE_RBF
> > > > > above.
> > > > PERIPH_RBF and CORE_RBF are the flags, so i can change them to
> > > > enum.
> > > > But above #define are magic content used to identify the
> > > > bistream
> > > > type.
> > > > If above #define are not suitable, what can you suggest?
> > > Maybe you can just align those two to avoid duplication ?
> > What's you means with duplication, they are different thing.
> > How about i change the name to ARRIA10RBF_PERIPH_TYPE
> > and ARRIA10RBF_CORE_TYPE.
> ARRIA10RBF_PERIPH = (PERIPH_RBF << 15) | 1
We can't use the flag PERIPH_RBF(similar TRUE/FALSE) for magic content,
because they are not related each other. Magic content is defined by HW
design.

We identify the type of rbf such as periph, and core through this magic
content within the rbf. After we getting the type, then only we setting
the flag such as PERIPH_RBF to the function.
> 
> same for ... _CORE ... is that a coincidence ?
> 
> [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

[Chee, Tien Fong]

On Mon, 2018-11-26 at 12:15 +0100, Marek Vasut wrote:
> On 11/26/2018 10:44 AM, Chee, Tien Fong wrote:
> > 
> > On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> > > 
> > > On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > This patch adds description on properties about file name
> > > > > > used
> > > > > > for
> > > > > > both
> > > > > > peripheral bitstream and core bitstream.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |6
> > > > > > ++
> > > > > >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA peripheral
> > > > > > raw
> > > > > > binary
> > > > > > which is used
> > > > > > +     to initialize FPGA IOs, PLL,
> > > > > > IO48
> > > > > > and
> > > > > > DDR.
> > > > > > +- altr,bitstream_core : File name for core raw binary
> > > > > > which
> > > > > > contains FPGA design
> > > > > > +   which is used to program FPGA CRAM
> > > > > > and
> > > > > > ERAM.
> > > > > bitstream- instead of bitstream_
> > > > Noted.
> > > > > 
> > > > > 
> > > > > 
> > > > > btw can we get something that works with full bitstream too ?
> > > > This patchset actually support the full bitstream too,
> > > > unfortunately it
> > > > is blocked by hardware MPFE issue. The patchset for the MPFE
> > > > workaround
> > > > would come after this patchset. I would advice to use the early
> > > > IO
> > > > release method for the sake of performance.
> > > > 
> > > > For details of issue, you can read the from the link https://gi
> > > > thub
> > > > .com
> > > > /altera-opensource/u-boot-
> > > > socfpga/commits/socfpga_v2014.10_arria10_brin
> > > > gup
> > > > FogBugz #410989-6: Masking hardware sequenced warm reset for
> > > > logic
> > > > in…  …
> > > Does that work on ES2 ? I don't think so ...
> > Why you think it doesn't work, using early IO or full rbf? The
> > bitstream limitation? What you see from the print out?
> ES2 can only use full RBF, I don't think this is handled in this
> patchset at all.
i did testing the full rbf loading, but in the end i removed that
portion of codes because it stuck in DDR calibration due to MPFE HW
issue. So, i would put back that portion of codes after MPFE HW
workaround. My plan is to let early IO release up 1st.

Actually ES2 board also support early IO release, just you need ACDS
and SOCEDS version 17.1 onward to rebuild your hardware, and choosing
the early IO release setting inside the tool. We can discuss this more
if you need our help for early IO release RBFs.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/9] ARM: socfpga: Bundle U-Boot fitImage into SFP on Arria10

[Chee, Tien Fong]

On Fri, 2018-11-23 at 13:40 +0100, Marek Vasut wrote:
> On 11/23/2018 10:54 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> > > 
> > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > Did you change Author:ship of the patch ?
> I believe you did, so please fix that.
Very sorry. I din't realize the author name was changed.
> 
> > 
> > > 
> > > > 
> > > > Bundle U-Boot fitImage containing U-Boot and FPGA bitstream
> > > > into
> > > > the
> > > > u-boot-with-spl.sfp on Arria10. This lets U-Boot operate in a
> > > > very
> > > > similar fashion to Gen5, where the U-Boot binary got loaded by
> > > > the
> > > > SPL from a uImage concatenated at the end of the SPL SFP image.
> > > > On
> > > > Gen10, the U-Boot is in fitImage which contains the FPGA
> > > > bitstream
> > > > as well. In this case, the SPL can load the FPGA bitstream
> > > > first
> > > > and
> > > > load the U-Boot afterward in the same manner. This is
> > > > nonetheless a
> > > > stopgap measure until there is a proper firmware loader in U-
> > > > Boot.
> > > Right, this is a stopgap measure until FW loader is present. Why
> > > is
> > > this
> > > patch needed at all in this series ?
> > This patch is cherry picked from the sdmmc_next custodian, so this
> > patch is required for generating FIT image. I can remove the
> > stopgap
> > comment to avoid confusing.
> But why is this patch needed at all ? You use the firmware loader to
> load the FPGA bitstream. Where does the fitImage come into play ?
> 
> The fitImage was used to circumvent the missing FW loader, when I
> needed
> to load multiple files (bitstream and u-boot binary). Now there is no
> such requirement anymore, so the entire fitImage machinery is
> probably
> not needed ?
Loading issue is not the reason we choose the fitImage. We choose it
because it allows more flexibility in handling various type images,
especially it allows user more choices to enhance integrity and
security protection.

Although we plan to use fitImage as our default implementation, but
this series of patches are still allow fw loading individual bitstream
image in filesystem partition. So, it is up to user to made the choice.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/9] ARM: socfpga: Add SPL fitImage config match

[Chee, Tien Fong]

On Fri, 2018-11-23 at 13:34 +0100, Marek Vasut wrote:
> On 11/23/2018 11:05 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> > > 
> > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add empty SPL fitImage configuration match. This can be
> > > > extended
> > > > if there is ever need to support multiple boards with single
> > > > SFP
> > > > image.
> > > > 
> > > > Signed-off-by: Marek Vasut 
> > > It's missing your SoB line, but again, why is this patch needed ?
> > This patch i also cherry picked from sdmmc_next custodian, and i
> > didn't
> > made any changes, so i still need SoB?
> Yes
Noted.
> 
> > 
> > Without this patch, compiling failed with error"/uboot-
> > socfpga/common/common_fit.c:66: undefined reference to
> > `board_fit_config_name_match'"
> Sure, it will fail. Let's continue the discussion at 4/9.
Okay.
> 
> > 
> > > 
> > > > 
> > > > ---
> > > >  arch/arm/mach-socfpga/spl_a10.c |   10 ++
> > > >  1 files changed, 10 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> > > > socfpga/spl_a10.c
> > > > index 67a4fac..2baeba6 100644
> > > > --- a/arch/arm/mach-socfpga/spl_a10.c
> > > > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > > > @@ -148,3 +148,13 @@ void board_init_f(ulong dummy)
> > > >     config_dedicated_pins(gd->fdt_blob);
> > > >     WATCHDOG_RESET();
> > > >  }
> > > > +
> > > > +#ifdef CONFIG_SPL_LOAD_FIT
> > > > +int board_fit_config_name_match(const char *name)
> > > > +{
> > > > +   /* Just empty function now - can't decide what to
> > > > choose
> > > > */
> > > > +   debug("%s: %s\n", __func__, name);
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +#endif
> > > > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs

[Chee, Tien Fong]

On Fri, 2018-11-23 at 13:31 +0100, Marek Vasut wrote:
> On 11/23/2018 10:51 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-21 at 15:19 +0100, Marek Vasut wrote:
> > > 
> > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > > ---
> > > >  arch/arm/mach-socfpga/spl_a10.c |   49
> > > > ++-
> > > >  common/spl/spl_mmc.c|2 +-
> > > >  include/mmc.h   |1 +
> > > >  3 files changed, 50 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> > > > socfpga/spl_a10.c
> > > > index 3ea64f7..67a4fac 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 
> > > > + *  Copyright (C) 2012-2018 Altera Corporation  > > > >
> > > >   */
> > > >  
> > > >  #include 
> > > > @@ -23,6 +23,10 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#define RBF0
> > > >  
> > > >  DECLARE_GLOBAL_DATA_PTR;
> > > >  
> > > > @@ -73,6 +77,49 @@ 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;
> > > > +   char buf[16 * 1024]
> > > > __aligned(ARCH_DMA_MINALIGN);
> > > > +   struct spl_boot_device bootdev;
> > > > +   int len = 0;
> > > > +
> > > > +   bootdev.boot_device = spl_boot_device();
> > > > +
> > > > +   /* Init MMC driver before reading FPGA
> > > > bitstream
> > > > from flash */
> > > > +   if (bootdev.boot_device == BOOT_DEVICE_MMC1) {
> > > > +   struct mmc *mmc = NULL;
> > > > +   int err = 0;
> > > > +
> > > > +   err = spl_mmc_find_device(,
> > > > bootdev.boot_device);
> > > > +   if (err)
> > > > +   return;
> > > > +
> > > > +   err = mmc_init(mmc);
> > > I thought all this backend specific stuff would be hidden in the
> > > FW
> > > loader.
> > The backend supported by FW loader is up to generic file system
> > interface layer. flash driver init is expected done by SPL/U-Boot
> > common init sequence framwork or user. Unfortunately, fw loader
> > need to
> > access flash before init sequence.
> This is actually accessing eMMC though , not flash . If we need this
> huge boilerplate code every time we use the FW loader, than the FW
> loader needs fixing. I can understand the spl_boot_device() being
> outside of the FW loader, but not the mmc_init() and co.
I can explore the posibility of adding the flash int mechanism into the
fm loader probe function.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Fri, 2018-11-23 at 13:28 +0100, Marek Vasut wrote:
> On 11/23/2018 10:43 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-21 at 15:18 +0100, Marek Vasut wrote:
> > > 
> > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > 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 
> > > [...]
> > > 
> > > > 
> > > > 
> > > > @@ -51,6 +54,8 @@
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > > > BIT(24)
> > > >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > > > 16
> > > >  
> > > > +#define PERIPH_RBF 
> > > > 0
> > > > +#define CORE_RBF   
> > > > 1
> > > Enum, use something with specific prefix.
> > Noted.
> > > 
> > > 
> > > > 
> > > > 
> > > >  #ifndef __ASSEMBLY__
> > > >  
> > > >  struct socfpga_fpga_manager {
> > > > @@ -88,12 +93,33 @@ struct socfpga_fpga_manager {
> > > >     u32  imgcfg_fifo_status;
> > > >  };
> > > >  
> > > > +enum rbf_type {unknown, periph_section, core_section};
> > > > +enum rbf_security {invalid, unencrypted, encrypted};
> > > enum should use one line per entry.
> > Noted.
> > > 
> > > 
> > > > 
> > > > 
> > > > +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
> > > > core);
> > > > +void get_rbf_image_info(struct rbf_info *rbf, u16 *buffer);
> > > > +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/configs/socfpga_arria10_defconfig
> > > > b/configs/socfpga_arria10_defconfig
> > > > index 6ebda81..f88910c 100644
> > > > --- a/configs/socfpga_arria10_defconfig
> > > > +++ b/configs/socfpga_arria10_defconfig
> > > > @@ -27,8 +27,17 @@ 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_FS_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
> > > Separate patch
> > Okay.
> > > 
> > > 
> > > > 
> > > > 
> > > >  CONFIG_FPGA_SOCFPGA=y
> > > >  CONFIG_DM_GPIO=y
> > > >  CONFIG_DWAPB_GPIO=y
> > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kc

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

[Chee, Tien Fong]

On Fri, 2018-11-23 at 13:23 +0100, Marek Vasut wrote:
> On 11/23/2018 10:19 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> > > 
> > > On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This patch adds description on properties about file name used
> > > > for
> > > > both
> > > > peripheral bitstream and core bitstream.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |6
> > > > ++
> > > >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA peripheral raw
> > > > binary
> > > > which is used
> > > > +     to initialize FPGA IOs, PLL, IO48
> > > > and
> > > > DDR.
> > > > +- altr,bitstream_core : File name for core raw binary which
> > > > contains FPGA design
> > > > +   which is used to program FPGA CRAM and
> > > > ERAM.
> > > bitstream- instead of bitstream_
> > Noted.
> > > 
> > > 
> > > btw can we get something that works with full bitstream too ?
> > This patchset actually support the full bitstream too,
> > unfortunately it
> > is blocked by hardware MPFE issue. The patchset for the MPFE
> > workaround
> > would come after this patchset. I would advice to use the early IO
> > release method for the sake of performance.
> > 
> > For details of issue, you can read the from the link https://github
> > .com
> > /altera-opensource/u-boot-
> > socfpga/commits/socfpga_v2014.10_arria10_brin
> > gup
> > FogBugz #410989-6: Masking hardware sequenced warm reset for logic
> > in…  …
> Does that work on ES2 ? I don't think so ...
Why you think it doesn't work, using early IO or full rbf? The
bitstream limitation? What you see from the print out?
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/9] ARM: socfpga: Set default DTB address on A10

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:22 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> Again, not your patch, please don't change authorship.
> 
> http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=commit;h=eb32e56886
> 9b5f91fe34efb2642875a8da5f0ebd
> 
> > 
> > Set default DT blob address on A10 SoCDK, since this SoC uses OF
> > separate configuration. The 0xf address is just below the text
> > base and still leaves enough room for the DT to grow.
> Why is this needed ?
This patch i also cherry picked from sdmmc_next custodian. I think you
put this for FIT implementation? I saw there is load property
"0xf0" defined for fdt in .its.
> 
> > 
> > Signed-off-by: Marek Vasut 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/board.c |8 
> >  1 files changed, 8 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-
> > socfpga/board.c
> > index 7c8c05c..436a8a8 100644
> > --- a/arch/arm/mach-socfpga/board.c
> > +++ b/arch/arm/mach-socfpga/board.c
> > @@ -86,3 +86,11 @@ int g_dnl_board_usb_cable_connected(void)
> >     return 1;
> >  }
> >  #endif
> > +
> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) && \
> > +!defined(CONFIG_SPL_BUILD) && defined(CONFIG_OF_SEPARATE)
> > +void *board_fdt_blob_setup(void)
> > +{
> > +   return (void *)0xf0;
> > +}
> > +#endif
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/9] ARM: socfpga: Add SPL fitImage config match

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add empty SPL fitImage configuration match. This can be extended
> > if there is ever need to support multiple boards with single SFP
> > image.
> > 
> > Signed-off-by: Marek Vasut 
> It's missing your SoB line, but again, why is this patch needed ?
This patch i also cherry picked from sdmmc_next custodian, and i didn't
made any changes, so i still need SoB?
Without this patch, compiling failed with error"/uboot-
socfpga/common/common_fit.c:66: undefined reference to
`board_fit_config_name_match'"
> 
> > 
> > ---
> >  arch/arm/mach-socfpga/spl_a10.c |   10 ++
> >  1 files changed, 10 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> > socfpga/spl_a10.c
> > index 67a4fac..2baeba6 100644
> > --- a/arch/arm/mach-socfpga/spl_a10.c
> > +++ b/arch/arm/mach-socfpga/spl_a10.c
> > @@ -148,3 +148,13 @@ void board_init_f(ulong dummy)
> >     config_dedicated_pins(gd->fdt_blob);
> >     WATCHDOG_RESET();
> >  }
> > +
> > +#ifdef CONFIG_SPL_LOAD_FIT
> > +int board_fit_config_name_match(const char *name)
> > +{
> > +   /* Just empty function now - can't decide what to choose
> > */
> > +   debug("%s: %s\n", __func__, name);
> > +
> > +   return 0;
> > +}
> > +#endif
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/9] ARM: socfpga: Bundle U-Boot fitImage into SFP on Arria10

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:21 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> Did you change Author:ship of the patch ?
> 
> > 
> > Bundle U-Boot fitImage containing U-Boot and FPGA bitstream into
> > the
> > u-boot-with-spl.sfp on Arria10. This lets U-Boot operate in a very
> > similar fashion to Gen5, where the U-Boot binary got loaded by the
> > SPL from a uImage concatenated at the end of the SPL SFP image. On
> > Gen10, the U-Boot is in fitImage which contains the FPGA bitstream
> > as well. In this case, the SPL can load the FPGA bitstream first
> > and
> > load the U-Boot afterward in the same manner. This is nonetheless a
> > stopgap measure until there is a proper firmware loader in U-Boot.
> Right, this is a stopgap measure until FW loader is present. Why is
> this
> patch needed at all in this series ?
This patch is cherry picked from the sdmmc_next custodian, so this
patch is required for generating FIT image. I can remove the stopgap
comment to avoid confusing.
> 
> > 
> > Signed-off-by: Marek Vasut 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  Makefile |9 +++--
> >  include/configs/socfpga_common.h |4 
> >  2 files changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index a55915d..4ecc19d 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1212,9 +1212,14 @@ ifneq ($(CONFIG_ARCH_SOCFPGA),)
> >  quiet_cmd_socboot = SOCBOOT $@
> >  cmd_socboot = cat  spl/u-boot-spl.sfp spl/u-boot-spl.sfp   
> > \
> >     spl/u-boot-spl.sfp spl/u-boot-spl.sfp   
> > \
> > -   u-boot.img > $@ || rm -f $@
> > +   $2 > $@ || rm -f $@
> > +ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
> > +u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.itb FORCE
> > +   $(call if_changed,socboot,u-boot.itb)
> > +else
> >  u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
> > -   $(call if_changed,socboot)
> > +   $(call if_changed,socboot,u-boot.img)
> > +endif
> >  endif
> >  
> >  ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > index bd8f5c8..ffdc6eb 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -268,7 +268,11 @@ unsigned int
> > cm_get_qspi_controller_clk_hz(void);
> >  /* SPL SDMMC boot support */
> >  #ifdef CONFIG_SPL_MMC_SUPPORT
> >  #if defined(CONFIG_SPL_FAT_SUPPORT) ||
> > defined(CONFIG_SPL_EXT_SUPPORT)
> > +#if CONFIG_SPL_FIT
> > +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-
> > boot.itb"
> > +#else
> >  #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-
> > dtb.img"
> > +#endif
> >  #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
> >  #endif
> >  #else
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/9] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:19 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> > ---
> >  arch/arm/mach-socfpga/spl_a10.c |   49
> > ++-
> >  common/spl/spl_mmc.c|2 +-
> >  include/mmc.h   |1 +
> >  3 files changed, 50 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-
> > socfpga/spl_a10.c
> > index 3ea64f7..67a4fac 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 
> > + *  Copyright (C) 2012-2018 Altera Corporation 
> >   */
> >  
> >  #include 
> > @@ -23,6 +23,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +
> > +#define RBF0
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> > @@ -73,6 +77,49 @@ 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;
> > +   char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
> > +   struct spl_boot_device bootdev;
> > +   int len = 0;
> > +
> > +   bootdev.boot_device = spl_boot_device();
> > +
> > +   /* Init MMC driver before reading FPGA bitstream
> > from flash */
> > +   if (bootdev.boot_device == BOOT_DEVICE_MMC1) {
> > +   struct mmc *mmc = NULL;
> > +   int err = 0;
> > +
> > +   err = spl_mmc_find_device(,
> > bootdev.boot_device);
> > +   if (err)
> > +   return;
> > +
> > +   err = mmc_init(mmc);
> I thought all this backend specific stuff would be hidden in the FW
> loader.
The backend supported by FW loader is up to generic file system
interface layer. flash driver init is expected done by SPL/U-Boot
common init sequence framwork or user. Unfortunately, fw loader need to
access flash before init sequence.
> 
> > 
> > +   if (err) {
> > +   debug("spl: mmc init failed with
> > error: %d\n",
> > +   err);
> > +
> > +   return;
> > +   }
> > +   }
> > +
> > +   fpga_fsinfo.filename = (char
> > *)get_fpga_filename(gd->fdt_blob,
> > +    &
> > len,
> > +    R
> > BF);
> > +
> > +   socfpga_loadfs(_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();
> >  }
> >  
> >  void board_init_f(ulong dummy)
> > diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> > index 4d55dcc..b85e146 100644
> > --- a/common/spl/spl_mmc.c
> > +++ b/common/spl/spl_mmc.c
> > @@ -111,7 +111,7 @@ static int spl_mmc_get_device_index(u32
> > boot_device)
> >     return -ENODEV;
> >  }
> >  
> > -static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
> > +int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
> >  {
> >  #if CONFIG_IS_ENABLED(DM_MMC)
> >     struct udevice *dev;
> > diff --git a/include/mmc.h b/include/mmc.h
> > index 95548e9..de92909 100644
> > --- a/include/mmc.h
> > +++ b/include/mmc.h
> > @@ -829,6 +829,7 @@ int board_mmc_init(bd_t *bis);
> >  int cpu_mmc_init(bd_t *bis);
> >  int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr);
> >  int mmc_get_env_dev(void);
> > +int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device);
> >  
> >  /* Set block count limit because of 16 bit register limit on some
> > hardware*/
> >  #ifndef CONFIG_SYS_MMC_MAX_BLK_COUNT
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/9] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:18 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > 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 
> [...]
> 
> > 
> > @@ -51,6 +54,8 @@
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK 
> > BIT(24)
> >  #define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB  
> > 16
> >  
> > +#define PERIPH_RBF 
> > 0
> > +#define CORE_RBF   1
> Enum, use something with specific prefix.
Noted.
> 
> > 
> >  #ifndef __ASSEMBLY__
> >  
> >  struct socfpga_fpga_manager {
> > @@ -88,12 +93,33 @@ struct socfpga_fpga_manager {
> >     u32  imgcfg_fifo_status;
> >  };
> >  
> > +enum rbf_type {unknown, periph_section, core_section};
> > +enum rbf_security {invalid, unencrypted, encrypted};
> enum should use one line per entry.
Noted.
> 
> > 
> > +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
> > core);
> > +void get_rbf_image_info(struct rbf_info *rbf, u16 *buffer);
> > +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/configs/socfpga_arria10_defconfig
> > b/configs/socfpga_arria10_defconfig
> > index 6ebda81..f88910c 100644
> > --- a/configs/socfpga_arria10_defconfig
> > +++ b/configs/socfpga_arria10_defconfig
> > @@ -27,8 +27,17 @@ 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_FS_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
> Separate patch
Okay.
> 
> > 
> >  CONFIG_FPGA_SOCFPGA=y
> >  CONFIG_DM_GPIO=y
> >  CONFIG_DWAPB_GPIO=y
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 50e9019..06a8204 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 CHECK_FPGA_DATA_CRC
> config FPGA_SOCFPGA_A10_CRC_CHECK
> 
> What is this for and why shouldn't this be ON by default ?
Both periph.rbf or full.rbf are wrapped with mkimage. So, this CRC
checking can be used to check the integrity of the loading bitstream
data against checksum from mkimage. It is off for the sake of
performance.
> 
> > 
> > +   bool "Enable CRC cheking on Arria10 FPGA bistream"
> > +   depends on FPGA_SOCFPGA
> > +   help
> > +    Say Y here to 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..d9ad237 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 
> > + * Copyright (C) 2017-2018 Intel Corporation 
> >   */
> >  
> >  #include 
> > @@ -10,8 +10,10 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -21,6 +23,10 @@
> >  #define COMPRESSION_OFFSET 229
> >  #define FPGA_TIMEOUT_MSEC  1000  /* timeout in ms */
> >  #define FPGA_TIMEOUT_CNT   0x100
> > +#define RBF_UNENCRYPTED0xa65c
> > +#define RBF_ENCRYPTED  0xa65d
> > +#define ARRIA10RBF_PERIPH  0x0001
> > +#define ARRIA10RBF_CORE0x8001
> This looks awfully similar to the PERIPH_RBF 

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

[Chee, Tien Fong]

On Wed, 2018-11-21 at 15:11 +0100, Marek Vasut wrote:
> On 11/21/2018 11:41 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patch adds description on properties about file name used for
> > both
> > peripheral bitstream and core bitstream.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |6 ++
> >  1 files changed, 6 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..010322a 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,6 +7,10 @@ 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_periph : File name for FPGA peripheral raw binary
> > which is used
> > +     to initialize FPGA IOs, PLL, IO48 and
> > DDR.
> > +- altr,bitstream_core : File name for core raw binary which
> > contains FPGA design
> > +   which is used to program FPGA CRAM and
> > ERAM.
> bitstream- instead of bitstream_
Noted.
> 
> btw can we get something that works with full bitstream too ?
This patchset actually support the full bitstream too, unfortunately it
is blocked by hardware MPFE issue. The patchset for the MPFE workaround
would come after this patchset. I would advice to use the early IO
release method for the sake of performance.

For details of issue, you can read the from the link https://github.com
/altera-opensource/u-boot-socfpga/commits/socfpga_v2014.10_arria10_brin
gup
FogBugz #410989-6: Masking hardware sequenced warm reset for logic
in…  …

Tien Fong Chee
Tien Fong Chee committed on Feb 16, 2017
 
FogBugz #410989-5: Enable RAM boot  …

Tien Fong Chee
Tien Fong Chee committed on Feb 16, 2017
 
FogBugz #410989-4: Added software reset for QSPI  …

Tien Fong Chee
Tien Fong Chee committed on Feb 8, 2017
 
FogBugz #410989-3: Disable redundant redundant messages after a warm
…  …

Tien Fong Chee
Tien Fong Chee committed on Dec 21, 2016
 
FogBugz #410989-2: Reset MPFE NoC after programming periperal rbf  …

Tien Fong Chee
Tien Fong Chee committed on Dec 21, 2016
 
FogBugz #410989-1: Functions for setting/checking magic no. to
isw_ha…  …

Tien Fong Chee
Tien Fong Chee committed on Dec 21, 2016
> 
> > 
> >  Example:
> >  
> > @@ -16,4 +20,6 @@ Example:
> >        0xffcfe400 0x20>;
> >     clocks = <_mp_clk>;
> >     resets = < FPGAMGR_RESET>;
> > +   altr,bitstream_periph =
> > "ghrd_10as066n2.periph.rbf.mkimage";
> > +   altr,bitstream_core =
> > "ghrd_10as066n2.core.rbf.mkimage";
> >     };
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Tue, 2018-09-25 at 15:37 -0400, Tom Rini wrote:
> On Tue, Sep 25, 2018 at 07:02:42AM +0000, Chee, Tien Fong wrote:
> 
> > 
> > On Thu, 2018-09-20 at 21:42 -0700, Chee, Tien Fong wrote:
> > > 
> > > > 
> > > > 
> > If everybody agree with current framework, then the next version i
> > will
> > include the fixes:
> > 1. Adding DM_FLAG_PRE_RELOC, this would allow runtime to choose the
> > right fs_loader if the chosen node u-boot, fs-loader is not
> > defined.
> > 
> > 2. Let driver model handles all memory allocation
> > 
> > 3. Using local variable instead of messy casts.
> A new version of this series, or a follow up series?  Thanks again!
> 
This changes will be in follow up series to address feedback raised by
Simon and michal on v4.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-09-20 at 21:42 -0700, Chee, Tien Fong wrote:
> > 
If everybody agree with current framework, then the next version i will
include the fixes:
1. Adding DM_FLAG_PRE_RELOC, this would allow runtime to choose the
right fs_loader if the chosen node u-boot, fs-loader is not defined.

2. Let driver model handles all memory allocation

3. Using local variable instead of messy casts.

Thanks.
> On Tue, 2018-07-31 at 08:22 +0200, Michal Simek wrote:
> > 
> > On 30.7.2018 18:05, Simon Glass wrote:
> > > 
> > > 
> > > Hi Michal,
> > > 
> > > On 30 July 2018 at 07:30, Michal Simek 
> > > wrote:
> > > > 
> > > > 
> > > > On 30.7.2018 15:26, Simon Glass wrote:
> > > > > 
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > On 27 July 2018 at 02:40, Chee, Tien Fong  > > > > el
> > > > > .com> wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On 25.7.2018 18:03, Tom Rini wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > On 25 July 2018 at 03:48, Michal Simek  > > > > > > > > xi
> > > > > > > > > linx.com>
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > From: Tien Fong Chee  > > > > > > > > > > > > m>
> > > > > > > > > > > > > 
> > > > > > > > > [...]
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Also that DT binding is quite weird and I don't
> > > > > > > > > > > > think you
> > > > > > > > > > > > will get
> > > > > > > > > > > > ACK
> > > > > > > > > > > > for this from device tree community at all. I
> > > > > > > > > > > > think that
> > > > > > > > > > > > calling via
> > > > > > > > > > > > platdata and avoid DT nodes would be better way
> > > > > > > > > > > > to go.
> > > > >

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Tue, 2018-07-31 at 08:22 +0200, Michal Simek wrote:
> On 30.7.2018 18:05, Simon Glass wrote:
> > 
> > Hi Michal,
> > 
> > On 30 July 2018 at 07:30, Michal Simek 
> > wrote:
> > > 
> > > On 30.7.2018 15:26, Simon Glass wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > On 27 July 2018 at 02:40, Chee, Tien Fong  > > > .com> wrote:
> > > > > 
> > > > > 
> > > > > On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
> > > > > > 
> > > > > > On 25.7.2018 18:03, Tom Rini wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 25 July 2018 at 03:48, Michal Simek  > > > > > > > linx.com>
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek
> > > > > > > > > > wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com
> > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > > > 
> > > > > > > > [...]
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Also that DT binding is quite weird and I don't
> > > > > > > > > > > think you
> > > > > > > > > > > will get
> > > > > > > > > > > ACK
> > > > > > > > > > > for this from device tree community at all. I
> > > > > > > > > > > think that
> > > > > > > > > > > calling via
> > > > > > > > > > > platdata and avoid DT nodes would be better way
> > > > > > > > > > > to go.
> > > > > > > > > > Why do you think DT binding is weird? The DT is
> > > > > > > > > > designed
> > > > > > > > > > based on Simon
> > > > > > > > > > proposal, and i believe following the rules in DTS
> > > > > > > > > > spec.
> > > > > > > > > > There are some DT benefits with current design, i
> > > > > > > > > > think
> > > > > > > > > > someone may be
> > > > > > > > > > maintainer need to made the final decision on the
> > > > > > > > > > design.
> > > > > > > > > It is software configuration in file which should
> > > > > > > > > mostly
> > > > > > > > > describe
> > > > > > > > > hardware and state for hardware configuration.
> > > > > > > > > 
> > > > > > > > > Your fs_loader node is purely describe sw
> > > > > > > > > configuration which
> > > > > > > > > shouldn't
> > > > > > > > > be here.
> > > > > > > > > You have there run time configuration via variables.
> > > > > > > > > I think
> > > > > > > > > using on

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-07-30 at 10:05 -0600, Simon Glass wrote:
> Hi Michal,
> 
> On 30 July 2018 at 07:30, Michal Simek 
> wrote:
> > 
> > On 30.7.2018 15:26, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 27 July 2018 at 02:40, Chee, Tien Fong  > > om> wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
> > > > > 
> > > > > On 25.7.2018 18:03, Tom Rini wrote:
> > > > > > 
> > > > > > 
> > > > > > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 25 July 2018 at 03:48, Michal Simek  > > > > > > nx.com>
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > > 
> > > > > > > [...]
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Also that DT binding is quite weird and I don't
> > > > > > > > > > think you
> > > > > > > > > > will get
> > > > > > > > > > ACK
> > > > > > > > > > for this from device tree community at all. I think
> > > > > > > > > > that
> > > > > > > > > > calling via
> > > > > > > > > > platdata and avoid DT nodes would be better way to
> > > > > > > > > > go.
> > > > > > > > > Why do you think DT binding is weird? The DT is
> > > > > > > > > designed
> > > > > > > > > based on Simon
> > > > > > > > > proposal, and i believe following the rules in DTS
> > > > > > > > > spec.
> > > > > > > > > There are some DT benefits with current design, i
> > > > > > > > > think
> > > > > > > > > someone may be
> > > > > > > > > maintainer need to made the final decision on the
> > > > > > > > > design.
> > > > > > > > It is software configuration in file which should
> > > > > > > > mostly
> > > > > > > > describe
> > > > > > > > hardware and state for hardware configuration.
> > > > > > > > 
> > > > > > > > Your fs_loader node is purely describe sw configuration
> > > > > > > > which
> > > > > > > > shouldn't
> > > > > > > > be here.
> > > > > > > > You have there run time configuration via variables. I
> > > > > > > > think
> > > > > > > > using only
> > > > > > > > this way is enough. Default variables will match what
> > > > > > > > you would
> > > > > > > > want to
> > > > > > > > add to DT.
> > > > > > > I think DT makes sense in the U-Boot context.
> > > > > > > 
> > > > > > > We don't have a user space to handle policy decisions,
> > > > > > > and the
> > > > > > > '

Re: [U-Boot] [PATCH 2/3] enable fpga loadfs

[Chee, Tien Fong]

On Thu, 2018-07-26 at 10:10 +0200, Marek Vasut wrote:
> On 07/26/2018 09:54 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/dts/socfpga_arria10.dtsi|   12 
> >  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts |6 ++
> >  configs/socfpga_arria10_defconfig|   12 
> >  3 files changed, 30 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/arm/dts/socfpga_arria10.dtsi
> > b/arch/arm/dts/socfpga_arria10.dtsi
> > index b51febd..45aef6a 100644
> > --- a/arch/arm/dts/socfpga_arria10.dtsi
> > +++ b/arch/arm/dts/socfpga_arria10.dtsi
> > @@ -48,6 +48,12 @@
> >       <0xc100 0x100>;
> >     };
> >  
> > +   fs_loader0: fs-loader@0 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> Which hardware does this describe ?
> DT is hardware description ...
I agree with Simon, it still describes some hardware information
required for this whole mechanism to work although this pointer is not
represent a real hardware.
> 
> > 
> > +   };
> [...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-07-26 at 11:03 +0200, Michal Simek wrote:
> On 25.7.2018 18:03, Tom Rini wrote:
> > 
> > On Wed, Jul 25, 2018 at 09:47:17AM -0600, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 25 July 2018 at 03:48, Michal Simek 
> > > wrote:
> > > > 
> > > > 
> > > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > > 
> > > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> > > > > > 
> > > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > From: Tien Fong Chee 
> > > > > > > 
> > > [...]
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > Also that DT binding is quite weird and I don't think you
> > > > > > will get
> > > > > > ACK
> > > > > > for this from device tree community at all. I think that
> > > > > > calling via
> > > > > > platdata and avoid DT nodes would be better way to go.
> > > > > Why do you think DT binding is weird? The DT is designed
> > > > > based on Simon
> > > > > proposal, and i believe following the rules in DTS spec.
> > > > > There are some DT benefits with current design, i think
> > > > > someone may be
> > > > > maintainer need to made the final decision on the design.
> > > > It is software configuration in file which should mostly
> > > > describe
> > > > hardware and state for hardware configuration.
> > > > 
> > > > Your fs_loader node is purely describe sw configuration which
> > > > shouldn't
> > > > be here.
> > > > You have there run time configuration via variables. I think
> > > > using only
> > > > this way is enough. Default variables will match what you would
> > > > want to
> > > > add to DT.
> > > I think DT makes sense in the U-Boot context.
> > > 
> > > We don't have a user space to handle policy decisions, and the
> > > 'chosen' node is a good place to configure these common features.
> > > 
> > > While you can argue that the partition or filesystem where an
> > > image
> > > comes from is a software config, it is something that has to be
> > > configured. It has impact on hardware too, since the FPGA has to
> > > get
> > > its firmware from somewhere. We use the chosen node to specify
> > > the
> > > UART to use, and this is no different. Again, we don't have user-
> > > space
> > > config files in U-Boot.
> > > 
> > > This argument comes up from time to time and I'd really like to
> > > put it
> > > to bed for U-Boot. I understand that Linux has its own approach
> > > and
> > > rules, but in some cases they serve U-Boot poorly.
> > I want to second this as well.  So long as we're using our prefix
> > and
> > we've thought through and discussed what we're trying to do here,
> > it's
> > OK to do things that might not be accepted for Linux.
> > 
> I have not a problem with using chosen node with u-boot prefix
> properties and my colleague hopefully with finish work about moving
> u-boot,dm-pre-reloc; to chosen node where it should be (because
> current
> solution has also problem with ordering).
> 
> In this loader case doc is saying that you can rewrite it with
> variables
> on the prompt (or via script).
> For cases that you want to autodetect platform and pass/load correct
> dtb
> which setup u-boot this can be problematic and using DT is could be
> considered as easier for use.
> 
> In this case this is what was proposed:
> 
> + fs_loader0: fs-loader@0 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + phandlepart = < 1>;
> + };
> 
> + fs_loader1: fs-loader@1 {
> + u-boot,dm-pre-reloc;
> + compatible = "u-boot,fs-loader";
> + mtdpart = "UBI",
> + ubivol = "ubi0";
> + };
> 
> u-boot,dm-pre-reloc; requires DM_FLAG_PRE_RELOC which is not setup
> for
> this driver - it means this should be here.
You are right, i missed this one. The intention of design enables user
to call any loader with default storage through the sequence number  if
fs l

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-07-26 at 12:29 +0200, Michal Simek wrote:
> On 26.7.2018 11:23, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-07-25 at 11:48 +0200, Michal Simek wrote:
> > > 
> > > On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> > > > > 
> > > > > 
> > > > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > This is file system generic loader which can be used to
> > > > > > load
> > > > > > the file image from the storage into target such as memory.
> > > > > > The consumer driver would then use this loader to program
> > > > > > whatever,
> > > > > > ie. the FPGA device.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  drivers/misc/Kconfig |  10 ++
> > > > > >  drivers/misc/Makefile|   1 +
> > > > > >  drivers/misc/fs_loader.c | 295
> > > > > > +++
> > > > > >  include/dm/uclass-id.h   |   1 +
> > > > > >  include/fs_loader.h  |  79 +
> > > > > >  5 files changed, 386 insertions(+)
> > > > > >  create mode 100644 drivers/misc/fs_loader.c
> > > > > >  create mode 100644 include/fs_loader.h
> > > > > > 
> > > > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > > > index 17b3a80..4163b4f 100644
> > > > > > --- a/drivers/misc/Kconfig
> > > > > > +++ b/drivers/misc/Kconfig
> > > > > > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > > > > >     depends on MISC
> > > > > >     help
> > > > > >       Support gdsys FPGA's RXAUI control.
> > > > > > +
> > > > > > +config FS_LOADER
> > > > > > +   bool "Enable loader driver for file system"
> > > > > > +   help
> > > > > > +     This is file system generic loader which can be
> > > > > > used
> > > > > > to
> > > > > > load
> > > > > > +     the file image from the storage into target such
> > > > > > as
> > > > > > memory.
> > > > > > +
> > > > > > +     The consumer driver would then use this loader
> > > > > > to
> > > > > > program whatever,
> > > > > > +     ie. the FPGA device.
> > > > > > +
> > > > > >  endmenu
> > > > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > > > > > index 4ce9d21..67a36f8 100644
> > > > > > --- a/drivers/misc/Makefile
> > > > > > +++ b/drivers/misc/Makefile
> > > > > > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> > > > > >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> > > > > >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> > > > > >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > > > > > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > > > > > diff --git a/drivers/misc/fs_loader.c
> > > > > > b/drivers/misc/fs_loader.c
> > > > > > new file mode 100644
> > > > > > index 000..5fe642b
> > > > > > --- /dev/null
> > > > > > +++ b/drivers/misc/fs_loader.c
> > > > > > @@ -0,0 +1,295 @@
> > > > > > +/*
> > > > > > + * Copyright (C) 2018 Intel Corporation 
> > > > > > + *
> > > > > > + * SPDX-License-Identifier:GPL-2.0
> > > > > > + */
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +#include 
> > > > > > +
> > > > > > +DECLARE_GLOBAL_DATA_PTR;
&

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-07-25 at 11:48 +0200, Michal Simek wrote:
> On 25.7.2018 08:31, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> > > 
> > > On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  drivers/misc/Kconfig |  10 ++
> > > >  drivers/misc/Makefile|   1 +
> > > >  drivers/misc/fs_loader.c | 295
> > > > +++
> > > >  include/dm/uclass-id.h   |   1 +
> > > >  include/fs_loader.h  |  79 +
> > > >  5 files changed, 386 insertions(+)
> > > >  create mode 100644 drivers/misc/fs_loader.c
> > > >  create mode 100644 include/fs_loader.h
> > > > 
> > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > index 17b3a80..4163b4f 100644
> > > > --- a/drivers/misc/Kconfig
> > > > +++ b/drivers/misc/Kconfig
> > > > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > > >     depends on MISC
> > > >     help
> > > >       Support gdsys FPGA's RXAUI control.
> > > > +
> > > > +config FS_LOADER
> > > > +   bool "Enable loader driver for file system"
> > > > +   help
> > > > +     This is file system generic loader which can be used
> > > > to
> > > > load
> > > > +     the file image from the storage into target such as
> > > > memory.
> > > > +
> > > > +     The consumer driver would then use this loader to
> > > > program whatever,
> > > > +     ie. the FPGA device.
> > > > +
> > > >  endmenu
> > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > > > index 4ce9d21..67a36f8 100644
> > > > --- a/drivers/misc/Makefile
> > > > +++ b/drivers/misc/Makefile
> > > > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> > > >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> > > >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> > > >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > > > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > > > diff --git a/drivers/misc/fs_loader.c
> > > > b/drivers/misc/fs_loader.c
> > > > new file mode 100644
> > > > index 000..5fe642b
> > > > --- /dev/null
> > > > +++ b/drivers/misc/fs_loader.c
> > > > @@ -0,0 +1,295 @@
> > > > +/*
> > > > + * Copyright (C) 2018 Intel Corporation 
> > > > + *
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > > + */
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +struct firmware_priv {
> > > > +   const char *name;   /* Filename */
> > > > +   u32 offset; /* Offset of reading a file
> > > > */
> > > > +};
> > > > +
> > > > +#ifdef CONFIG_CMD_UBIFS
> > > > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > > > +{
> > > > +   int ret = ubi_part(mtdpart, NULL);
> > > > +
> > > > +   if (ret) {
> > > > +   debug("Cannot find mtd partition %s\n",
> > > > mtdpart);
> > > > +   return ret;
> > > > +   }
> > > > +
> > > > +   return cmd_ubifs_mount(ubivol);
> > > > +}
> > > > +
> > > > +static int umount_ubifs(void)
> > > > +{
> > > > +   return cmd_ubifs_umount();
> > > > +}
> > > > +#else
> > > > +static int mount_ubifs(char *mtdpart, char *ubivol)
> &

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-07-18 at 16:48 +0200, Michal Simek wrote:
> On 6.7.2018 10:28, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/misc/Kconfig |  10 ++
> >  drivers/misc/Makefile|   1 +
> >  drivers/misc/fs_loader.c | 295
> > +++
> >  include/dm/uclass-id.h   |   1 +
> >  include/fs_loader.h  |  79 +
> >  5 files changed, 386 insertions(+)
> >  create mode 100644 drivers/misc/fs_loader.c
> >  create mode 100644 include/fs_loader.h
> > 
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 17b3a80..4163b4f 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> >     depends on MISC
> >     help
> >       Support gdsys FPGA's RXAUI control.
> > +
> > +config FS_LOADER
> > +   bool "Enable loader driver for file system"
> > +   help
> > +     This is file system generic loader which can be used to
> > load
> > +     the file image from the storage into target such as
> > memory.
> > +
> > +     The consumer driver would then use this loader to
> > program whatever,
> > +     ie. the FPGA device.
> > +
> >  endmenu
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 4ce9d21..67a36f8 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> > new file mode 100644
> > index 000..5fe642b
> > --- /dev/null
> > +++ b/drivers/misc/fs_loader.c
> > @@ -0,0 +1,295 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct firmware_priv {
> > +   const char *name;   /* Filename */
> > +   u32 offset; /* Offset of reading a file */
> > +};
> > +
> > +#ifdef CONFIG_CMD_UBIFS
> > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > +{
> > +   int ret = ubi_part(mtdpart, NULL);
> > +
> > +   if (ret) {
> > +   debug("Cannot find mtd partition %s\n", mtdpart);
> > +   return ret;
> > +   }
> > +
> > +   return cmd_ubifs_mount(ubivol);
> > +}
> > +
> > +static int umount_ubifs(void)
> > +{
> > +   return cmd_ubifs_umount();
> > +}
> > +#else
> > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > +{
> > +   debug("Error: Cannot load image: no UBIFS support\n");
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +
> > +static int select_fs_dev(struct device_platdata *plat)
> > +{
> > +   int ret;
> > +
> > +   if (plat->phandlepart.phandle) {
> > +   ofnode node;
> > +
> > +   node = ofnode_get_by_phandle(plat-
> > >phandlepart.phandle);
> > +
> > +   int of_offset = ofnode_to_offset(node);
> > +
> > +   struct udevice *dev;
> > +
> > +   ret = device_get_global_by_of_offset(of_offset,
> > );
> > +   if (!ret) {
> > +   struct blk_desc *desc =
> > blk_get_by_device(dev);
> > +   if (desc) {
> > +   ret =
> > fs_set_blk_dev_with_part(desc,
> > +   plat-
> > >phandlepart.partition);
> > +   } else {
> > +   debug("%s: No device found\n",
> > __func__);
> > +   return -ENODEV;
> > +   }
> > +   }
> > +   } else if (plat->mtdpart && plat->ubivol) {
> > +   ret = mount_ubifs(plat->mtdpart, plat->ubivol);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
> I am curious why it is in generic FS loader any code which target any
> filesystem. It should be filesystem independent.
Because it supports our use case, and our preference using file system
instead of RAW. As I agree with Tom, it can be evolved to support RAW
in future.
> 
> Also that DT binding is quite weird and I don't think you will get
> ACK
> for this from device tree community at all. I think that calling via
> platdata and avoid DT nodes would be better way to go.
Why do you think DT binding is weird? The DT is designed based on Simon
proposal, and i believe following the rules in DTS spec.
There are some DT benefits with current design, i think someone may 

Re: [U-Boot] [PATCH] ddr: altera: Add ECC DRAM scrubbing support for Stratix 10

[Chee, Tien Fong]

On Tue, 2018-07-24 at 12:52 +0200, Marek Vasut wrote:
> On 07/24/2018 10:10 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-07-23 at 11:46 +0200, Marek Vasut wrote:
> > > 
> > > On 07/23/2018 10:20 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > The SDRAM must first be rewritten by zeroes if ECC is used to
> > > > initialize
> > > > the ECC metadata. Make the CPU overwrite the DRAM with zeroes
> > > > in
> > > > such a
> > > > case. This scrubbing implementation turns the caches on
> > > > temporarily, then
> > > > overwrites the whole RAM with zeroes, flushes the caches and
> > > > turns
> > > > them
> > > > off again. This provides satisfactory performance.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  drivers/ddr/altera/sdram_s10.c |   44
> > > > 
> > > >  1 files changed, 44 insertions(+), 0 deletions(-)
> > > > 
> > > > diff --git a/drivers/ddr/altera/sdram_s10.c
> > > > b/drivers/ddr/altera/sdram_s10.c
> > > > index 48f4f47..cce261f 100644
> > > > --- a/drivers/ddr/altera/sdram_s10.c
> > > > +++ b/drivers/ddr/altera/sdram_s10.c
> > > > @@ -8,6 +8,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -134,6 +135,47 @@ static int poll_hmc_clock_status(void)
> > > >      SYSMGR_HMC_CLK_STATUS_MSK,
> > > > true,
> > > > 1000, false);
> > > >  }
> > > >  
> > > > +/* Initialize SDRAM ECC bits to avoid false DBE */
> > > > +static void sdram_init_ecc_bits(unsigned long long size)
> > > > +{
> > > > +   /* 1GB per chunk */
> > > > +   unsigned long long size_byte = SZ_1G;
> > > > +   unsigned long long remaining_size;
> > > > +   unsigned long long dst_addr = 0x8000;
> > > > +   unsigned int start = get_timer(0);
> > > > +
> > > > +   icache_enable();
> > > > +
> > > > +   memset(0, 0, dst_addr);
> > > > +   gd->arch.tlb_addr = 0x4000;
> > > > +   gd->arch.tlb_size = PGTABLE_SIZE;
> > > Are you sure this is valid on arm64 ? It looks like something
> > > copies
> > > from arria10.
> > The cache on/off is copied from your implementation on Arria 10.
> > Yes, i
> > have tested it, it is working on Stratix 10 board.
> Right, except S10 is arm64, A10 is arm32, which is why I wonder
> whether
> careless copying is enough.
The PGTABLE_SIZE is getting from the function get_page_table_size()
which is specific for armv8 architecture. I'm also testing it on board
to ensure sufficient RAM for the page table.
> 
> > 
> > > 
> > > > 
> > > > 
> > > > +   dcache_enable();
> > > > +
> > > > +   remaining_size = size - dst_addr;
> > > > +   printf("DDRCAL: Scrubbing ECC RAM (%d MiB).\n",
> > > > (u32)(size
> > > > > 
> > > > > > 
> > > > > > 20));
> > > > +
> > > > +   while (remaining_size) {
> > > > +   if (remaining_size <= size_byte) {
> > > > +   memset((void *)dst_addr, 0,
> > > > remaining_size);
> > > > +   break;
> > > > +   } else {
> > > > +   memset((void *)dst_addr, 0,
> > > > size_byte);
> > > > +   dst_addr += size_byte;
> > > > +   }
> > > > +
> > > > +   WATCHDOG_RESET();
> > > > +   remaining_size -= size_byte;
> > > > +   }
> > > How long does this take ?
> > 1359ms for 2GB.
> So why do you need this watchdog reset hack ?
Yeah, for size scalable. When size growing up, it would take longer to
scrub. Without watchdog reset on time, it might be causing system to
reset.
> 
> > 
> > But I have no idea why Arria 10 board can't achieve the
> > same result. Could you try again on your Arria 10 ES board?
> There's nothing to try, the scrubbing works fine on A10.
Then

Re: [U-Boot] [PATCH] ddr: altera: Add ECC DRAM scrubbing support for Stratix 10

[Chee, Tien Fong]

On Mon, 2018-07-23 at 11:46 +0200, Marek Vasut wrote:
> On 07/23/2018 10:20 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > The SDRAM must first be rewritten by zeroes if ECC is used to
> > initialize
> > the ECC metadata. Make the CPU overwrite the DRAM with zeroes in
> > such a
> > case. This scrubbing implementation turns the caches on
> > temporarily, then
> > overwrites the whole RAM with zeroes, flushes the caches and turns
> > them
> > off again. This provides satisfactory performance.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/ddr/altera/sdram_s10.c |   44
> > 
> >  1 files changed, 44 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/ddr/altera/sdram_s10.c
> > b/drivers/ddr/altera/sdram_s10.c
> > index 48f4f47..cce261f 100644
> > --- a/drivers/ddr/altera/sdram_s10.c
> > +++ b/drivers/ddr/altera/sdram_s10.c
> > @@ -8,6 +8,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -134,6 +135,47 @@ static int poll_hmc_clock_status(void)
> >      SYSMGR_HMC_CLK_STATUS_MSK, true,
> > 1000, false);
> >  }
> >  
> > +/* Initialize SDRAM ECC bits to avoid false DBE */
> > +static void sdram_init_ecc_bits(unsigned long long size)
> > +{
> > +   /* 1GB per chunk */
> > +   unsigned long long size_byte = SZ_1G;
> > +   unsigned long long remaining_size;
> > +   unsigned long long dst_addr = 0x8000;
> > +   unsigned int start = get_timer(0);
> > +
> > +   icache_enable();
> > +
> > +   memset(0, 0, dst_addr);
> > +   gd->arch.tlb_addr = 0x4000;
> > +   gd->arch.tlb_size = PGTABLE_SIZE;
> Are you sure this is valid on arm64 ? It looks like something copies
> from arria10.
The cache on/off is copied from your implementation on Arria 10. Yes, i
have tested it, it is working on Stratix 10 board.
> 
> > 
> > +   dcache_enable();
> > +
> > +   remaining_size = size - dst_addr;
> > +   printf("DDRCAL: Scrubbing ECC RAM (%d MiB).\n", (u32)(size
> > >> 20));
> > +
> > +   while (remaining_size) {
> > +   if (remaining_size <= size_byte) {
> > +   memset((void *)dst_addr, 0,
> > remaining_size);
> > +   break;
> > +   } else {
> > +   memset((void *)dst_addr, 0, size_byte);
> > +   dst_addr += size_byte;
> > +   }
> > +
> > +   WATCHDOG_RESET();
> > +   remaining_size -= size_byte;
> > +   }
> How long does this take ?
1359ms for 2GB. But I have no idea why Arria 10 board can't achieve the
same result. Could you try again on your Arria 10 ES board?
> 
> > 
> > +   flush_dcache_all();
> > +   printf("DDRCAL: Scrubbing ECC RAM done.\n");
> > +   dcache_disable();
> > +
> > +   printf("SDRAM-ECC: Initialized success with %d ms\n",
> > +   (unsigned)get_timer(start));
> > +}
> > +
> >  /**
> >   * sdram_mmr_init_full() - Function to initialize SDRAM MMR
> >   *
> > @@ -351,6 +393,8 @@ int sdram_mmr_init_full(unsigned int unused)
> >     setbits_le32(SOCFPGA_SDR_ADDRESS + ECCCTRL2,
> >      (DDR_HMC_ECCCTL2_RMW_EN_SET_MSK |
> >       DDR_HMC_ECCCTL2_AWB_EN_SET_MSK));
> > +
> > +   sdram_init_ecc_bits(gd->ram_size);
> >     } else {
> >     clrbits_le32(SOCFPGA_SDR_ADDRESS + ECCCTRL1,
> >      (DDR_HMC_ECCCTL_AWB_CNT_RST_SET_MSK |
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Sun, 2018-07-15 at 15:21 -0600, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 12 July 2018 at 01:19, Chee, Tien Fong 
> wrote:
> > 
> > On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
> > > 
> > > Hi Tien,
> > > 
> > > On 6 July 2018 at 02:28,   wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  drivers/misc/Kconfig |  10 ++
> > > >  drivers/misc/Makefile|   1 +
> > > >  drivers/misc/fs_loader.c | 295
> > > > +++
> > > >  include/dm/uclass-id.h   |   1 +
> > > >  include/fs_loader.h  |  79 +
> > > >  5 files changed, 386 insertions(+)
> > > >  create mode 100644 drivers/misc/fs_loader.c
> > > >  create mode 100644 include/fs_loader.h
> > > > 
> [..]
> 
> > 
> > > 
> > > 
> > > > 
> > > > 
> > > > +   (*firmwarep)->priv = calloc(1, sizeof(struct
> > > > firmware_priv));
> > > > +   if (!(*firmwarep)->priv) {
> > > > +   free(*firmwarep);
> > > > +   return -ENOMEM;
> > > > +   }
> > > > +   }
> > > > +
> > > > +   ((struct firmware_priv *)((*firmwarep)->priv))->name =
> > > > name;
> > > Again this needs a local variable.
> > Why?
> Because these casts are really ugly and repetitive, particularly when
> used for assignments :-)
Okay.
> 
> [..]
> 
> > 
> > > 
> > > > 
> > > > + * release_firmware - Release the resource associated with a
> > > > firmware image
> > > > + * @firmware: Firmware resource to release
> > > > + */
> > > > +void release_firmware(struct firmware *firmware);
> > > > +
> > > > +/**
> > > > + * request_firmware_into_buf - Load firmware into a previously
> > > > allocated buffer.
> > > > + * @plat: Platform data such as storage and partition firmware
> > > > loading from.
> > > > + * @name: Name of firmware file.
> > > > + * @buf: Address of buffer to load firmware into.
> > > > + * @size: Size of buffer.
> > > > + * @offset: Offset of a file for start reading into buffer.
> > > > + * @firmwarep: Pointer to firmware image.
> > > > + *
> > > > + * The firmware is loaded directly into the buffer pointed to
> > > > by
> > > > @buf and
> > > > + * the @firmwarep data member is pointed at @buf.
> > > > + *
> > > > + * Return: Size of total read, negative value when error.
> > > > + */
> > > > +int request_firmware_into_buf(struct device_platdata *plat,
> > > > + const char *name,
> > > > + void *buf, size_t size, u32
> > > > offset,
> > > > + struct firmware **firmwarep);
> > > Without a test it's hard to see how this is used, but I'm not
> > > keen on
> > > the struct firmware ** here.
> > > 
> > > Can you just use struct firmware * instead?
> > > 
> > > Or maybe just return the fields individually since you only have
> > > start
> > > address and size, I think.
> > I can try to remove struct firmware, let driver model handles all
> > memory allocation, and then struct device_platdata *plat will
> > change
> > to struct udevice *dev. So, it would become like this
> > int request_firmware_into_buf(struct udevice *dev,
> >   const char *name,
> >   void *buf, size_t size, u32 offset);
> > I will remove release_firmware() after letting driver model to
> > handle
> > all memory deallocation.
> > So, the API interface would looks a bit different compare to Linux
> > firmware API interface. Does this change OK for you?
> I believe you would need:
> 
> > 
> > int request_firmware_into_buf(struct udevice *dev,
> >   const char *name,
> >   void **bufp, size_t *sizep, u32
> > offset);
> since you need to return the buffer and size?
Why need to return the buffer and size? There is no modification
required on noth buffer and size arguments by
request_firmware_into_buf().
Both buffer and size are allocated and defined by user, then
request_firmware_into_buf() would load the file into buffer based on
the size exactly defined by user.
> 
> What exactly is 'dev'? Is it the device in the FS_LOADER uclass?
Yes, contains FDT HW data.
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 5/6] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> On 6 July 2018 at 02:27,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add a document to describe file system firmware loader binding
> > information.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  doc/device-tree-bindings/chosen.txt | 21 +
> >  doc/device-tree-bindings/misc/fs_loader.txt | 48
> > +
> >  2 files changed, 69 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
> Reviewed-by: Simon Glass 
> 
> Apart from the naming of phandlepart, as I mentioned in the previous
> patch
Okay.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 6 July 2018 at 02:28,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/misc/Kconfig |  10 ++
> >  drivers/misc/Makefile|   1 +
> >  drivers/misc/fs_loader.c | 295
> > +++
> >  include/dm/uclass-id.h   |   1 +
> >  include/fs_loader.h  |  79 +
> >  5 files changed, 386 insertions(+)
> >  create mode 100644 drivers/misc/fs_loader.c
> >  create mode 100644 include/fs_loader.h
> > 
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 17b3a80..4163b4f 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > depends on MISC
> > help
> >   Support gdsys FPGA's RXAUI control.
> > +
> > +config FS_LOADER
> > +   bool "Enable loader driver for file system"
> > +   help
> > + This is file system generic loader which can be used to
> > load
> > + the file image from the storage into target such as
> > memory.
> *a* file image?
Okay.
> 
> > 
> > +
> > + The consumer driver would then use this loader to program
> > whatever,
> > + ie. the FPGA device.
> e.g. an FPGA device
Okay.
> 
> > 
> > +
> >  endmenu
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 4ce9d21..67a36f8 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> > new file mode 100644
> > index 000..5fe642b
> > --- /dev/null
> > +++ b/drivers/misc/fs_loader.c
> > @@ -0,0 +1,295 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct firmware_priv {
> > +   const char *name;   /* Filename */
> > +   u32 offset; /* Offset of reading a file */
> I don't understand that comment. Is it the offset within the file to
> read from? Please can you expand it a bit?
Sure. This is offset within the file, can be used in limited memory
buffer, chunk by chunk transfer from device storage to memory.
> 
> > 
> > +};
> > +
> > +#ifdef CONFIG_CMD_UBIFS
> > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > +{
> > +   int ret = ubi_part(mtdpart, NULL);
> > +
> > +   if (ret) {
> > +   debug("Cannot find mtd partition %s\n", mtdpart);
> > +   return ret;
> > +   }
> > +
> > +   return cmd_ubifs_mount(ubivol);
> > +}
> > +
> > +static int umount_ubifs(void)
> > +{
> > +   return cmd_ubifs_umount();
> > +}
> > +#else
> > +static int mount_ubifs(char *mtdpart, char *ubivol)
> > +{
> > +   debug("Error: Cannot load image: no UBIFS support\n");
> blank line here
Okay.
> 
> > 
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +
> > +static int select_fs_dev(struct device_platdata *plat)
> > +{
> > +   int ret;
> > +
> > +   if (plat->phandlepart.phandle) {
> > +   ofnode node;
> > +
> > +   node = ofnode_get_by_phandle(plat-
> > >phandlepart.phandle);
> > +
> > +   int of_offset = ofnode_to_offset(node);
> > +
> > +   struct udevice *dev;
> > +
> > +   ret = device_get_global_by_of_offset(of_offset,
> > );
> Can you please create device_get_global_by_ofnode() and use that
> instead? We should not use offsets in new code.
okay.
> 
> > 
> > +   if (!ret) {
> > +   struct blk_desc *desc =
> > blk_get_by_device(dev);
> > +   if (desc) {
> > +   ret =
> > fs_set_blk_dev_with_part(desc,
> > +   plat-
> > >phandlepart.partition);
> > +   } else {
> > +   debug("%s: No device found\n",
> > __func__);
> > +   return -ENODEV;
> > +   }
> > +   }
> > +   } else if (plat->mtdpart && plat->ubivol) {
> > +   ret = mount_ubifs(plat->mtdpart, plat->ubivol);
> > +   if (ret)
> > +   return ret;
> > +
> > +   ret = fs_set_blk_dev("ubi", NULL, FS_TYPE_UBIFS);
> > +   } else {
> > +

Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor

[Chee, Tien Fong]

On Wed, 2018-07-11 at 14:13 -0600, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 11 July 2018 at 08:23, Chee, Tien Fong 
> wrote:
> > 
> > On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> > > 
> > > Hi Tien,
> > > 
> > > On 6 July 2018 at 02:26,   wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add a function to find the block device descriptor of the
> > > > parent
> > > > device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  drivers/block/blk-uclass.c | 23 +++
> > > >  include/blk.h  |  9 +
> > > >  2 files changed, 32 insertions(+)
> > > > 
> > > > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-
> > > > uclass.c
> > > > index 9e0c823..facf527 100644
> > > > --- a/drivers/block/blk-uclass.c
> > > > +++ b/drivers/block/blk-uclass.c
> > > > @@ -132,6 +132,29 @@ struct blk_desc
> > > > *blk_get_devnum_by_typename(const char *if_typename, int
> > > > devnum)
> > > >  }
> > > > 
> > > >  /**
> > > > + * blk_get_by_device() - Get the block device descriptor for
> > > > the
> > > > given device
> > > > + * @dev:   Instance of a storage device
> > > > + *
> > > > + * Return: With block device descriptor on success , NULL if
> > > > there
> > > > is no such
> > > > + *block device.
> > > > + */
> > > > +struct blk_desc *blk_get_by_device(struct udevice *dev)
> > > > +{
> > > > +   struct udevice *child_dev, *next;
> > > > +
> > > > +   device_foreach_child_safe(child_dev, next, dev) {
> > > > +   if (device_get_uclass_id(child_dev) !=
> > > > UCLASS_BLK)
> > > > +   continue;
> > > > +
> > > > +   return dev_get_uclass_platdata(child_dev);
> > > > +   }
> > > > +
> > > > +   debug("%s: No block device found\n", __func__);
> > > > +
> > > > +   return NULL;
> > > > +}
> > > Is this different from blk_get_from_parent() ?
> > This new function would return block description.
> > blk_get_from_parents() would return child device.
> OK, but please implement your function by calling
> blk_get_from_parent(). There is no need to duplicate the logic.
> 
> Also how about calling it blk_get_desc_from_parent() ?
Okay.
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 3/6] block: Add a function to find block device descriptor

[Chee, Tien Fong]

On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 6 July 2018 at 02:26,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add a function to find the block device descriptor of the parent
> > device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/block/blk-uclass.c | 23 +++
> >  include/blk.h  |  9 +
> >  2 files changed, 32 insertions(+)
> > 
> > diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-
> > uclass.c
> > index 9e0c823..facf527 100644
> > --- a/drivers/block/blk-uclass.c
> > +++ b/drivers/block/blk-uclass.c
> > @@ -132,6 +132,29 @@ struct blk_desc
> > *blk_get_devnum_by_typename(const char *if_typename, int devnum)
> >  }
> > 
> >  /**
> > + * blk_get_by_device() - Get the block device descriptor for the
> > given device
> > + * @dev:   Instance of a storage device
> > + *
> > + * Return: With block device descriptor on success , NULL if there
> > is no such
> > + *block device.
> > + */
> > +struct blk_desc *blk_get_by_device(struct udevice *dev)
> > +{
> > +   struct udevice *child_dev, *next;
> > +
> > +   device_foreach_child_safe(child_dev, next, dev) {
> > +   if (device_get_uclass_id(child_dev) != UCLASS_BLK)
> > +   continue;
> > +
> > +   return dev_get_uclass_platdata(child_dev);
> > +   }
> > +
> > +   debug("%s: No block device found\n", __func__);
> > +
> > +   return NULL;
> > +}
> Is this different from blk_get_from_parent() ?
This new function would return block description. 
blk_get_from_parents() would return child device.
> 
> [..]
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 4/6] doc: Add new doc for file system firmware loader driver model

[Chee, Tien Fong]

On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 6 July 2018 at 02:27,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Provide information about
> > 
> > - overview of file system firmware loader driver model
> > - describe storage device and partition in device tree source
> > - describe fie system firmware loader API
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  doc/driver-model/fs_firmware_loader.txt | 133
> > 
> >  1 file changed, 133 insertions(+)
> >  create mode 100644 doc/driver-model/fs_firmware_loader.txt
> Reviewed-by: Simon Glass 
> 
> A few comments below.
> 
> > 
> > 
> > diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-
> > model/fs_firmware_loader.txt
> > new file mode 100644
> > index 000..290915a
> > --- /dev/null
> > +++ b/doc/driver-model/fs_firmware_loader.txt
> > @@ -0,0 +1,133 @@
> > +# Copyright (C) 2018 Intel Corporation 
> > +#
> > +# SPDX-License-Identifier:GPL-2.0
> > +
> > +Introduction
> > +
> > +
> > +This is file system firmware loader for U-Boot framework, which
> > has very close
> > +to some Linux Firmware API. For the details of Linux Firmware API,
> > you can refer
> > +to https://01.org/linuxgraphics/gfx-docs/drm/driver-api/firmware/i
> > ndex.html.
> > +
> > +File system firmware loader can be used to load whatever(firmware,
> > image,
> > +and binary) from the storage device in file system format into
> > target location
> > +such as memory, then consumer driver such as FPGA driver can
> > program FPGA image
> > +from the target location into FPGA.
> > +
> > +To enable firmware loader, CONFIG_FS_LOADER need to be set at
> > +_defconfig such as "CONFIG_FS_LOADER=y".
> > +
> > +Firmware Loader API core features
> > +-
> > +
> > +Firmware storage device described in device tree source
> > +---
> > +   For passing data like storage device phandle and partition
> > where the
> > +   firmware loading from to the firmware loader driver, those
> > data could be
> > +   defined in fs-loader node as shown in below:
> > +
> > +   Example for block device:
> > +   fs_loader0: fs-loader@0 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   phandlepart = < 1>;
> I don't like this name much. How about
> 
>    source-partition = < 1>;
Okay.
> 
> or something like that?
> 
> > 
> > +   };
> > +
> > +   < 1> means block storage device pointer and its
> > partition.
> > +
> > +   Above example is a description for block storage, but for
> > UBI storage
> > +   device, it can be described in FDT as shown in below:
> > +
> > +   Example for ubi:
> > +   fs_loader1: fs-loader@1 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "u-boot,fs-loader";
> > +   mtdpart = "UBI",
> > +   ubivol = "ubi0";
> > +   };
> > +
> > +   Then, firmware_loader property would be set with the path
> > of fs_loader
> > +   node under /chosen node such as:
> > +   /{
> > +   chosen {
> > +   firmware_loader = _loader0;
> > +   };
> > +   };
> > +
> > +   However, this driver is also designed to support U-boot
> > environment
> U-Boot
> 
> Please fix below also.
Okay.
> 
> > 
> > +   variables, so all these data from FDT can be overwritten
> > +   through the U-boot environment variable during run time.
> > +   For examples:
> > +   "storage_interface" - Storage interface, it can be "mmc",
> > "usb", "sata"
> > + or "ubi".
> > +   "fw_dev_part" - Block device number and its partition, it
> > can be "0:1".
> > +   "fw_ubi_mtdpart" - UBI device mtd partition, it can be
> > "UBI".
> > +   "fw_ubi_volume" - UBI volume, it can be "ubi0".
> > +
> > +   When above environment variables are set, environment
> > values would be
> > +   used instead of data from FDT.
> > +   The benefit of this design allows user to change storage
> > attribute data
> > +   at run time through U-boot console and saving the setting
> > as default
> > +   environment values in the storage for the next power cycle,
> > so no
> > +   compilation is required for both driver and FDT.
> > +
> > +File system firmware Loader API
> > +---
> > +
> > +int request_firmware_into_buf(struct device_platdata *plat,
> > +const char *name,
> > +void *buf, size_t size, u32
> > offset,
> > +struct firmware **firmwarep)
> > +
> > 
> > +Load firmware into a previously allocated buffer
> > +
> > +Parameters:
> > +
> > +1. struct device_platdata *plat
> > +   Platform 

Re: [U-Boot] [PATCH v4 5/6] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> On 6 July 2018 at 02:27,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add a document to describe file system firmware loader binding
> > information.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  doc/device-tree-bindings/chosen.txt | 21 +
> >  doc/device-tree-bindings/misc/fs_loader.txt | 48
> > +
> >  2 files changed, 69 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
> Reviewed-by: Simon Glass 
> 
> Apart from the naming of phandlepart, as I mentioned in the previous
> patch
Noted.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-07-11 at 08:02 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 6 July 2018 at 02:28,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/misc/Kconfig |  10 ++
> >  drivers/misc/Makefile|   1 +
> >  drivers/misc/fs_loader.c | 295
> > +++
> >  include/dm/uclass-id.h   |   1 +
> >  include/fs_loader.h  |  79 +
> >  5 files changed, 386 insertions(+)
> >  create mode 100644 drivers/misc/fs_loader.c
> >  create mode 100644 include/fs_loader.h
> I don't see a sandbox test for this. We need to add a test for every
> new uclass. Please let me know if you want some pointers to ideas.
> 
Yeah, i will add the sandbox for this once we finalize the design.
Sandbox is new to me, i would appreciate it very much if you can share
some ideas.
> [..]
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] arm: dts: socfpga: stratix10: update pdma

[Chee, Tien Fong]

On Tue, 2018-07-10 at 08:37 -0500, Dinh Nguyen wrote:
> 
> On 07/10/2018 08:11 AM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-07-09 at 22:28 +0200, Marek Vasut wrote:
> > > 
> > > On 07/09/2018 08:03 PM, Dinh Nguyen wrote:
> > > > 
> > > > 
> > > > 
> > > > 
> > > > On 05/31/2018 03:08 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > Update pdma properties for Stratix 10
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > ---
> > > > >  arch/arm/dts/socfpga_stratix10.dtsi | 20
> > > > > 
> > > > >  1 file changed, 20 insertions(+)
> > > > > 
> > > > > diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > b/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > index ccd3f32..311ba09 100644
> > > > > --- a/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> > > > > @@ -82,6 +82,26 @@
> > > > >   ranges = <0 0 0 0x>;
> > > > >   u-boot,dm-pre-reloc;
> > > > >  
> > > > > + amba {
> > > > > + u-boot,dm-pre-reloc;
> > > > > + compatible = "arm,amba-bus";
> > > > > + #address-cells = <1>;
> > > > > + #size-cells = <1>;
> > > > > + ranges;
> > > > > +
> > > > > + pdma: pdma@ffda {
> > > > > + u-boot,dm-pre-reloc;
> > > > > + compatible =
> > > > > "arm,pl330", "arm,dma330";
> > > > I think you got "arm,dma330" binding wrong. I don't see any
> > > > binding
> > > > with
> > > > that name.
> > Here https://patchwork.ozlabs.org/patch/923234/ .
> Oh okay...why do you need to add the additional binding "arm,dma330"?
pl330 is old name, now arm using dma330.
> 
> Dinh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Sun, 2018-07-08 at 20:39 -0600, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 2 July 2018 at 01:26, Chee, Tien Fong 
> wrote:
> > 
> > On Fri, 2018-06-29 at 21:19 -0700, Simon Glass wrote:
> > > 
> > > Hi Tien Fong,
> > > 
> > > On 28 June 2018 at 01:58, Chee, Tien Fong  > > om>
> > > wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-06-28 at 01:04 -0700, Chee, Tien Fong wrote:
> > > > > 
> > > > > 
> > > > > On Wed, 2018-06-27 at 14:03 -0700, Simon Glass wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi Tien Fong,
> > > > > > 
> > > > > > On 27 June 2018 at 01:32, Chee, Tien Fong  > > > > > ntel
> > > > > > .com
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 25 June 2018 at 07:28,  
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > 
> > > > > > > > > Add a document to describe file system firmware
> > > > > > > > > loader
> > > > > > > > > binding
> > > > > > > > > information.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > om>
> > > > > > > > > ---
> > > > > > > > >  doc/device-tree-bindings/chosen.txt | 22
> > > > > > > > > 
> > > > > > > > >  doc/device-tree-bindings/misc/fs_loader.txt | 52
> > > > > > > > > +
> > > > > > > > >  2 files changed, 74 insertions(+)
> > > > > > > > >  create mode 100644 doc/device-tree-
> > > > > > > > > bindings/misc/fs_loader.txt
> > > > > > > > > 
> > > > > > > > > diff --git a/doc/device-tree-bindings/chosen.txt
> > > > > > > > > b/doc/device-
> > > > > > > > > tree-
> > > > > > > > > bindings/chosen.txt
> > > > > > > > > index c96b8f7..738673c 100644
> > > > > > > > > --- a/doc/device-tree-bindings/chosen.txt
> > > > > > > > > +++ b/doc/device-tree-bindings/chosen.txt
> > > > > > > > > @@ -73,3 +73,25 @@ Example
> > > > > > > > > u-boot,spl-boot-order = "same-as-
> > > > > > > > > spl",
> > > > > > > > > ,
> > > > > > > > > "/sd
> > > > > > > > > hci@fe33";
> > > > > > > > > };
> > > > > > > > >  };
> > > > > > > > > +
> > > > > > > > > +firmware-loader property
> > > > > > > > > +
> > > > > > > > > +Multiple file system firmware loader nodes could be
> > > > > > > > > defined
> > > > > > > > > in
> > > > > > > > > device trees for
> > > > > > > > > +multiple storage type and their default partition,
> > > > > > > > > then
> > > > > > > > > a
> > > > > > > > > property
> > > > > > > > > +"firmware-loader" can be used to pass default
> > > > > > > > > firmware
> > > > > >

Re: [U-Boot] [PATCH v2] common/memsize.c: Increase save array for supporting memory size > 4GB

[Chee, Tien Fong]

On Sat, 2018-06-23 at 05:29 +0200, Marek Vasut wrote:
> On 06/21/2018 08:31 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-21 at 06:34 +0200, Marek Vasut wrote:
> > > 
> > > On 06/20/2018 09:06 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > In ARM 64-bits, memory size can be supported is more than 4GB,
> > > > hence increasing save array is needed to cope with testing
> > > > larger
> > > > memory.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > > 
> > > > Changes in v2:
> > > > - Change save array size to save[BITS_PER_LONG - 1]
> > > > ---
> > > >  common/memsize.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/common/memsize.c b/common/memsize.c
> > > > index 5670e95..13b0047 100644
> > > > --- a/common/memsize.c
> > > > +++ b/common/memsize.c
> > > > @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> > > >  long get_ram_size(long *base, long maxsize)
> > > >  {
> > > >     volatile long *addr;
> > > > -   long   save[31];
> > > > +   long   save[BITS_PER_LONG - 1];
> > > >     long   save_base;
> > > >     long   cnt;
> > > >     long   val;
> > > > 
> > > Does this work with LPAE systems, where bits per long == 32 and
> > > the
> > > address space is bigger ? Or with similar setups ? I mean, you
> > > can
> > > have
> > > > 
> > > > 
> > > > 4 GiB of RAM on 32bit system ...
> > This function is designed to work with 32bit or 64 bits system, for
> > example the argument such as maxsize can be 32bit or 64 bit, if
> > value
> > larger than 4GiB is passed as maxsize argument with 32bit system,
> > the
> > whole thing will go wrong.
> And what do you do when you identify a problem in mainline ? :-)
> 
I have no idea at this moment, how about fixing the issue for save
array in 64-bit 1st?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Fri, 2018-06-29 at 21:19 -0700, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 28 June 2018 at 01:58, Chee, Tien Fong 
> wrote:
> > 
> > On Thu, 2018-06-28 at 01:04 -0700, Chee, Tien Fong wrote:
> > > 
> > > On Wed, 2018-06-27 at 14:03 -0700, Simon Glass wrote:
> > > > 
> > > > 
> > > > Hi Tien Fong,
> > > > 
> > > > On 27 June 2018 at 01:32, Chee, Tien Fong  > > > .com
> > > > > 
> > > > > 
> > > > wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > On 25 June 2018 at 07:28,  
> > > > > > wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > From: Tien Fong Chee 
> > > > > > > 
> > > > > > > Add a document to describe file system firmware loader
> > > > > > > binding
> > > > > > > information.
> > > > > > > 
> > > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > > ---
> > > > > > >  doc/device-tree-bindings/chosen.txt | 22
> > > > > > > 
> > > > > > >  doc/device-tree-bindings/misc/fs_loader.txt | 52
> > > > > > > +
> > > > > > >  2 files changed, 74 insertions(+)
> > > > > > >  create mode 100644 doc/device-tree-
> > > > > > > bindings/misc/fs_loader.txt
> > > > > > > 
> > > > > > > diff --git a/doc/device-tree-bindings/chosen.txt
> > > > > > > b/doc/device-
> > > > > > > tree-
> > > > > > > bindings/chosen.txt
> > > > > > > index c96b8f7..738673c 100644
> > > > > > > --- a/doc/device-tree-bindings/chosen.txt
> > > > > > > +++ b/doc/device-tree-bindings/chosen.txt
> > > > > > > @@ -73,3 +73,25 @@ Example
> > > > > > > u-boot,spl-boot-order = "same-as-spl",
> > > > > > > ,
> > > > > > > "/sd
> > > > > > > hci@fe33";
> > > > > > > };
> > > > > > >  };
> > > > > > > +
> > > > > > > +firmware-loader property
> > > > > > > +
> > > > > > > +Multiple file system firmware loader nodes could be
> > > > > > > defined
> > > > > > > in
> > > > > > > device trees for
> > > > > > > +multiple storage type and their default partition, then
> > > > > > > a
> > > > > > > property
> > > > > > > +"firmware-loader" can be used to pass default firmware
> > > > > > > loader
> > > > > > > +node(default storage type) to the firmware loader
> > > > > > > driver.
> > > > > > > +
> > > > > > > +Example
> > > > > > > +---
> > > > > > > +/ {
> > > > > > > +   chosen {
> > > > > > > +   firmware-loader = _loader0;
> > > > > > > +   };
> > > > > > > +
> > > > > > > +   fs_loader0: fs_loader@0 {
> > > > > > This should be :
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > +   fs_loader0: fs-loader@0 {
> > > > > > since hyphen is used for node and property names.
> > > > > > Underscore is
> > > > > > used
> > > > > > for phandles (so you have that correct).
> > > > > > 
> > > > > Okay.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > 

Re: [U-Boot] [PATCH v3 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Fri, 2018-06-29 at 14:13 +0200, Anatolij Gustschin wrote:
> Hi,
> 
> please see some comments below.
> 
> On Mon, 25 Jun 2018 21:28:58 +0800
> tien.fong.c...@intel.com tien.fong.c...@intel.com wrote:
> 
> > 
> > +/**
> > + * _request_firmware_prepare - Prepare firmware struct.
> > + *
> > + * @firmware_p: Pointer to pointer to firmware image.
> > + * @name: Name of firmware file.
> > + * @dbuf: Address of buffer to load firmware into.
> > + * @size: Size of buffer.
> > + * @offset: Offset of a file for start reading into buffer.
> > + *
> > + * Return: Negative value if fail, 0 for successful.
> > + */
> > +static int _request_firmware_prepare(struct firmware **firmware_p,
> > +   const char *name, void *dbuf,
> > +   size_t size, u32 offset)
> > +{
> > +   struct firmware *firmware;
> > +   struct firmware_priv *fw_priv;
> > +
> > +   *firmware_p = NULL;
> > +
> > +   if (!name || name[0] == '\0')
> > +   return -EINVAL;
> > +
> > +   firmware = calloc(1, sizeof(*firmware));
> > +   if (!firmware)
> > +   return -ENOMEM;
> > +
> > +   fw_priv = calloc(1, sizeof(*fw_priv));
> > +   if (!fw_priv) {
> > +   free(firmware);
> > +   return -ENOMEM;
> > +   }
> please add a note to API description that the API user should
> free() *firmware_p and *firmware_p->priv structs after usage of
> request_firmware_into_buf(), otherwise it will always leak memory
> while subsequent calls of request_firmware_into_buf() with the
> same *firmware_p argument.
> 
Okay, i will add the description into doc. I can create a function to
release memory allocation and setting both *firmware_p and fw_priv to
null for user.
> Or probably we should better allow request_firmware_into_buf() to
> be called multiple times with prepared *firmware_p stuct for
> reloading the same firmware image when needed.
> Then request_firmware_into_buf() should check if the given
> *firmware_p stuct is already initialized and must not call
> _request_firmware_prepare() in this case.
> 
Okay, this should work in this way by checking both *firmware_p and
fw_priv, if they are not null, memory allocation would be skipped for
better performance. However, *firmware_p always need to get updated
with function arguments, because it could be chunk by chunk
transferring if image is larger than available buffer.
> > 
> > +
> > +   fw_priv->name = name;
> > +   fw_priv->offset = offset;
> > +   firmware->data = dbuf;
> > +   firmware->size = size;
> > +   firmware->priv = fw_priv;
> > +   *firmware_p = firmware;
> > +
> > +   return 0;
> > +}
> --
> Anatolij
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Thu, 2018-06-28 at 01:04 -0700, Chee, Tien Fong wrote:
> On Wed, 2018-06-27 at 14:03 -0700, Simon Glass wrote:
> > 
> > Hi Tien Fong,
> > 
> > On 27 June 2018 at 01:32, Chee, Tien Fong  > >
> > wrote:
> > > 
> > > 
> > > On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > On 25 June 2018 at 07:28,   wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee 
> > > > > 
> > > > > Add a document to describe file system firmware loader
> > > > > binding
> > > > > information.
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee 
> > > > > ---
> > > > >  doc/device-tree-bindings/chosen.txt | 22
> > > > > 
> > > > >  doc/device-tree-bindings/misc/fs_loader.txt | 52
> > > > > +
> > > > >  2 files changed, 74 insertions(+)
> > > > >  create mode 100644 doc/device-tree-
> > > > > bindings/misc/fs_loader.txt
> > > > > 
> > > > > diff --git a/doc/device-tree-bindings/chosen.txt
> > > > > b/doc/device-
> > > > > tree-
> > > > > bindings/chosen.txt
> > > > > index c96b8f7..738673c 100644
> > > > > --- a/doc/device-tree-bindings/chosen.txt
> > > > > +++ b/doc/device-tree-bindings/chosen.txt
> > > > > @@ -73,3 +73,25 @@ Example
> > > > > u-boot,spl-boot-order = "same-as-spl",
> > > > > ,
> > > > > "/sd
> > > > > hci@fe33";
> > > > > };
> > > > >  };
> > > > > +
> > > > > +firmware-loader property
> > > > > +
> > > > > +Multiple file system firmware loader nodes could be defined
> > > > > in
> > > > > device trees for
> > > > > +multiple storage type and their default partition, then a
> > > > > property
> > > > > +"firmware-loader" can be used to pass default firmware
> > > > > loader
> > > > > +node(default storage type) to the firmware loader driver.
> > > > > +
> > > > > +Example
> > > > > +---
> > > > > +/ {
> > > > > +   chosen {
> > > > > +   firmware-loader = _loader0;
> > > > > +   };
> > > > > +
> > > > > +   fs_loader0: fs_loader@0 {
> > > > This should be :
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > +   fs_loader0: fs-loader@0 {
> > > > since hyphen is used for node and property names. Underscore is
> > > > used
> > > > for phandles (so you have that correct).
> > > > 
> > > Okay.
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > +   u-boot,dm-pre-reloc;
> > > > > +   compatible = "fs_loader";
> > > > How about u-boot,fs-loader since this is U-Boot specific I
> > > > think.
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > +   storage_device = "mmc";
> > > > storage-device
> > > > 
> > > Okay
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > +   devpart = "0:1";
> > > > I think you should use a phandle to the node containing the mmc
> > > > device to use.
> > > > 
> > > >    storage-device = <_3 1>;
> > > > 
> > > > for example (meaning use that MMC, partition 1.
> > > > 
> > > How to get device number based on node of a storage?
> > > This could make design more complicated because this driver is
> > > designed
> > > to support both fdt and without fdt(U-boot env and hard coding in
> > > driver).
> > I think it is fine to support the environment as a way of providing
> > this info, but there is no need to support non-DM. Everything
> > should
> > 

Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Wed, 2018-06-27 at 14:03 -0700, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 27 June 2018 at 01:32, Chee, Tien Fong 
> wrote:
> > 
> > On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 25 June 2018 at 07:28,   wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Add a document to describe file system firmware loader binding
> > > > information.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  doc/device-tree-bindings/chosen.txt | 22 
> > > >  doc/device-tree-bindings/misc/fs_loader.txt | 52
> > > > +
> > > >  2 files changed, 74 insertions(+)
> > > >  create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
> > > > 
> > > > diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-
> > > > tree-
> > > > bindings/chosen.txt
> > > > index c96b8f7..738673c 100644
> > > > --- a/doc/device-tree-bindings/chosen.txt
> > > > +++ b/doc/device-tree-bindings/chosen.txt
> > > > @@ -73,3 +73,25 @@ Example
> > > > u-boot,spl-boot-order = "same-as-spl", ,
> > > > "/sd
> > > > hci@fe33";
> > > > };
> > > >  };
> > > > +
> > > > +firmware-loader property
> > > > +
> > > > +Multiple file system firmware loader nodes could be defined in
> > > > device trees for
> > > > +multiple storage type and their default partition, then a
> > > > property
> > > > +"firmware-loader" can be used to pass default firmware loader
> > > > +node(default storage type) to the firmware loader driver.
> > > > +
> > > > +Example
> > > > +---
> > > > +/ {
> > > > +   chosen {
> > > > +   firmware-loader = _loader0;
> > > > +   };
> > > > +
> > > > +   fs_loader0: fs_loader@0 {
> > > This should be :
> > > 
> > > > 
> > > > 
> > > > +   fs_loader0: fs-loader@0 {
> > > since hyphen is used for node and property names. Underscore is
> > > used
> > > for phandles (so you have that correct).
> > > 
> > Okay.
> > > 
> > > > 
> > > > 
> > > > +   u-boot,dm-pre-reloc;
> > > > +   compatible = "fs_loader";
> > > How about u-boot,fs-loader since this is U-Boot specific I think.
> > > 
> > > 
> > > > 
> > > > 
> > > > +   storage_device = "mmc";
> > > storage-device
> > > 
> > Okay
> > > 
> > > > 
> > > > 
> > > > +   devpart = "0:1";
> > > I think you should use a phandle to the node containing the mmc
> > > device to use.
> > > 
> > >    storage-device = <_3 1>;
> > > 
> > > for example (meaning use that MMC, partition 1.
> > > 
> > How to get device number based on node of a storage?
> > This could make design more complicated because this driver is
> > designed
> > to support both fdt and without fdt(U-boot env and hard coding in
> > driver).
> I think it is fine to support the environment as a way of providing
> this info, but there is no need to support non-DM. Everything should
> be converting to DM now.
> 
Ok,i would keep the DM and environment support.

> We have:
> 
> uclass_get_device_by_phandle_id()
> device_get_global_by_of_offset()
> 
> I think we need to create a function called
> 
> device_get_global_by_phandle_id()
> 
> which can be used to obtain the device based on a phandle.
> 
I means the device number in the struct blk_desc, block device. I don't
 know how the device number is built up during driver model init. Is
there a function to retrive the device number?
> > 
> > > 
> > > > 
> > > > 
> > > > +   };
> > > > +};
> > > > diff --git a/doc/device-tree-bindings/misc/fs_loader.txt
> > > > b/doc/device-tree-bindings/misc/fs_loader.txt
> > > > new file mode 100644
> > > > index 000..78bea66
> > > > --- /dev/null
> > > > +++ b/doc/device-tree-bindings/misc/fs_loader.txt
&

Re: [U-Boot] [PATCH v3 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-06-27 at 14:03 -0700, Simon Glass wrote:
> Hi Tien Fong,
> 
> On 27 June 2018 at 01:41, Chee, Tien Fong 
> wrote:
> > 
> > On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 25 June 2018 at 07:28,   wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  drivers/misc/Kconfig |  10 ++
> > > >  drivers/misc/Makefile|   1 +
> > > >  drivers/misc/fs_loader.c | 238
> > > > +++
> > > >  include/dm/uclass-id.h   |   1 +
> > > >  include/fs_loader.h  |  28 ++
> > > >  5 files changed, 278 insertions(+)
> > > >  create mode 100644 drivers/misc/fs_loader.c
> > > >  create mode 100644 include/fs_loader.h
> > > This is definitely looking good. I think we need to figure out
> > > the
> > > binding to devices, to use phandles instead of strings. Also we
> > > need
> > > a
> > > sandbox driver and test.
> > > 
> > > I'm a little worried that you are blazing a trail here, but it is
> > > a
> > > valuable trail :-)
> > > 
> > > Tom, do you have any ideas / thoughts on the design?
> > > 
> > yeah, this part is most challenging, because this driver is
> > designed
> > based on file system implementation, which is abstract from
> > physical
> > device. So, it requires data like interface type, device number and
> > partition to work. Wonder how we can get those data if based on
> > physical storage node.
> > > 
> > > > 
> > > > 
> > > > 
> > > > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > > > index 17b3a80..4163b4f 100644
> > > > --- a/drivers/misc/Kconfig
> > > > +++ b/drivers/misc/Kconfig
> > > > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > > > depends on MISC
> > > > help
> > > >   Support gdsys FPGA's RXAUI control.
> > > > +
> > > > +config FS_LOADER
> > > > +   bool "Enable loader driver for file system"
> > > > +   help
> > > > + This is file system generic loader which can be used
> > > > to
> > > > load
> > > > + the file image from the storage into target such as
> > > > memory.
> > > > +
> > > > + The consumer driver would then use this loader to
> > > > program
> > > > whatever,
> > > > + ie. the FPGA device.
> > > > +
> > > >  endmenu
> > > > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > > > index 4ce9d21..67a36f8 100644
> > > > --- a/drivers/misc/Makefile
> > > > +++ b/drivers/misc/Makefile
> > > > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> > > >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> > > >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> > > >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > > > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > > > diff --git a/drivers/misc/fs_loader.c
> > > > b/drivers/misc/fs_loader.c
> > > > new file mode 100644
> > > > index 000..0dc385f
> > > > --- /dev/null
> > > > +++ b/drivers/misc/fs_loader.c
> > > > @@ -0,0 +1,238 @@
> > > > +/*
> > > > + * Copyright (C) 2018 Intel Corporation 
> > > > + *
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > > + */
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > +
> > > > +struct firmware_priv {
> > > > +   const char *name;   /* Filename */
> > > > +   u32 offset; /* Offset of read

Re: [U-Boot] [PATCH v3 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> Hi,
> 
> On 25 June 2018 at 07:28,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/misc/Kconfig |  10 ++
> >  drivers/misc/Makefile|   1 +
> >  drivers/misc/fs_loader.c | 238
> > +++
> >  include/dm/uclass-id.h   |   1 +
> >  include/fs_loader.h  |  28 ++
> >  5 files changed, 278 insertions(+)
> >  create mode 100644 drivers/misc/fs_loader.c
> >  create mode 100644 include/fs_loader.h
> This is definitely looking good. I think we need to figure out the
> binding to devices, to use phandles instead of strings. Also we need
> a
> sandbox driver and test.
> 
> I'm a little worried that you are blazing a trail here, but it is a
> valuable trail :-)
> 
> Tom, do you have any ideas / thoughts on the design?
> 
yeah, this part is most challenging, because this driver is designed
based on file system implementation, which is abstract from physical
device. So, it requires data like interface type, device number and
partition to work. Wonder how we can get those data if based on
physical storage node.
> > 
> > 
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 17b3a80..4163b4f 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -277,4 +277,14 @@ config GDSYS_RXAUI_CTRL
> > depends on MISC
> > help
> >   Support gdsys FPGA's RXAUI control.
> > +
> > +config FS_LOADER
> > +   bool "Enable loader driver for file system"
> > +   help
> > + This is file system generic loader which can be used to
> > load
> > + the file image from the storage into target such as
> > memory.
> > +
> > + The consumer driver would then use this loader to program
> > whatever,
> > + ie. the FPGA device.
> > +
> >  endmenu
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 4ce9d21..67a36f8 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -54,3 +54,4 @@ obj-$(CONFIG_STM32_RCC) += stm32_rcc.o
> >  obj-$(CONFIG_STM32MP_FUSE) += stm32mp_fuse.o
> >  obj-$(CONFIG_SYS_DPAA_QBMAN) += fsl_portals.o
> >  obj-$(CONFIG_GDSYS_RXAUI_CTRL) += gdsys_rxaui_ctrl.o
> > +obj-$(CONFIG_FS_LOADER) += fs_loader.o
> > diff --git a/drivers/misc/fs_loader.c b/drivers/misc/fs_loader.c
> > new file mode 100644
> > index 000..0dc385f
> > --- /dev/null
> > +++ b/drivers/misc/fs_loader.c
> > @@ -0,0 +1,238 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > +struct firmware_priv {
> > +   const char *name;   /* Filename */
> > +   u32 offset; /* Offset of reading a file */
> > +};
> > +
> > +static int select_fs_dev(struct device_platdata *plat)
> > +{
> > +   int ret;
> > +
> > +   if (!strcmp("mmc", plat->name)) {
> > +   ret = fs_set_blk_dev("mmc", plat->devpart,
> > FS_TYPE_ANY);
> > +   } else if (!strcmp("usb", plat->name)) {
> > +   ret = fs_set_blk_dev("usb", plat->devpart,
> > FS_TYPE_ANY);
> > +   } else if (!strcmp("sata", plat->name)) {
> > +   ret = fs_set_blk_dev("sata", plat->devpart,
> > FS_TYPE_ANY);
> For these I think you can look up the phandle to obtain the device,
> then check its uclass to find out its type.
> 
How to find the interface type of the file system based on the physical
device node? Some devices like NAND and QSPI could share the similar
interface type like UBI.
> > 
> > +   } else if (!strcmp("ubi", plat->name)) {
> > +   if (plat->ubivol)
> > +   ret = fs_set_blk_dev("ubi", NULL,
> > FS_TYPE_UBIFS);
> > +   else
> > +   ret = -ENODEV;
> > +   } else {
> > +   debug("Error: unsupported storage device.\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   if (ret)
> > +   debug("Error: could not access storage.\n");
> > +
> > +   return ret;
> > +}
> > +
> > +static void set_storage_devpart(struct device_platdata *plat, char
> > *devpart)
> > +{
> > +   plat->devpart = devpart;
> > +}
> > +
> > +static void set_storage_mtdpart(struct device_platdata *plat, char
> > *mtdpart)
> > +{
> > +   plat->mtdpart = mtdpart;
> > +}
> > +
> > +static void set_storage_ubivol(struct device_platdata *plat, char
> > *ubivol)
> > +{
> > +   plat->ubivol = ubivol;
> > +}
> > +
> > +/**
> > + * _request_firmware_prepare - Prepare firmware struct.
> > + *
> > + * 

Re: [U-Boot] [PATCH v3 2/3] doc: dtbinding: Add file system firmware loader binding document

[Chee, Tien Fong]

On Mon, 2018-06-25 at 21:58 -0600, Simon Glass wrote:
> Hi,
> 
> On 25 June 2018 at 07:28,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Add a document to describe file system firmware loader binding
> > information.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  doc/device-tree-bindings/chosen.txt | 22 
> >  doc/device-tree-bindings/misc/fs_loader.txt | 52
> > +
> >  2 files changed, 74 insertions(+)
> >  create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
> > 
> > diff --git a/doc/device-tree-bindings/chosen.txt b/doc/device-tree-
> > bindings/chosen.txt
> > index c96b8f7..738673c 100644
> > --- a/doc/device-tree-bindings/chosen.txt
> > +++ b/doc/device-tree-bindings/chosen.txt
> > @@ -73,3 +73,25 @@ Example
> > u-boot,spl-boot-order = "same-as-spl", , "/sd
> > hci@fe33";
> > };
> >  };
> > +
> > +firmware-loader property
> > +
> > +Multiple file system firmware loader nodes could be defined in
> > device trees for
> > +multiple storage type and their default partition, then a property
> > +"firmware-loader" can be used to pass default firmware loader
> > +node(default storage type) to the firmware loader driver.
> > +
> > +Example
> > +---
> > +/ {
> > +   chosen {
> > +   firmware-loader = _loader0;
> > +   };
> > +
> > +   fs_loader0: fs_loader@0 {
> This should be :
> 
> > 
> > +   fs_loader0: fs-loader@0 {
> since hyphen is used for node and property names. Underscore is used
> for phandles (so you have that correct).
> 
Okay.
> > 
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "fs_loader";
> How about u-boot,fs-loader since this is U-Boot specific I think.
> 
> 
> > 
> > +   storage_device = "mmc";
> storage-device
> 
Okay
> > 
> > +   devpart = "0:1";
> I think you should use a phandle to the node containing the mmc
> device to use.
> 
>    storage-device = <_3 1>;
> 
> for example (meaning use that MMC, partition 1.
> 
How to get device number based on node of a storage?
This could make design more complicated because this driver is designed
to support both fdt and without fdt(U-boot env and hard coding in
driver).
> > 
> > +   };
> > +};
> > diff --git a/doc/device-tree-bindings/misc/fs_loader.txt
> > b/doc/device-tree-bindings/misc/fs_loader.txt
> > new file mode 100644
> > index 000..78bea66
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/misc/fs_loader.txt
> > @@ -0,0 +1,52 @@
> > +* File system firmware loader
> > +
> > +Required properties:
> > +
> > +
> > +- compatible: should contain "fs_loader"
> > +- storage_device: which storage device loading from, could be:
> > + - mmc, usb, sata, and ubi.
> > +- devpart: which storage device and partition the image loading
> > from,
> > +  this property is required for mmc, usb and sata.
> > +- mdtpart: which partition of ubi the image loading from, this
> > property is
> > +  required for ubi.
> > +- ubivol: which volume of ubi the image loading from, this
> > proprety is required
> > + for ubi.
> > +
> > +Example of storage device and partition search set for mmc, usb,
> > sata and
> > +ubi in device tree source as shown in below:
> > +
> > +   Example of storage type and device partition search set for
> > mmc, usb,
> > +   sata and ubi as shown in below:
> > +   Example for mmc:
> > +   fs_loader0: fs_loader@0 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "fs_loader";
> > +   storage_device = "mmc";
> > +   devpart = "0:1";
> > +   };
> > +
> > +   Example for usb:
> > +   fs_loader1: fs_loader@1 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "fs_loader";
> > +   storage_device = "usb";
> > +   devpart = "0:1";
> > +   };
> > +
> > +   Example for sata:
> > +   fs_loader2: fs_loader@2 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "fs_loader";
> > +   storage_device = "sata";
> > +   devpart = "0:1";
> > +   };
> > +
> > +   Example for ubi:
> > +   fs_loader3: fs_loader@3 {
> > +   u-boot,dm-pre-reloc;
> > +   compatible = "fs_loader";
> > +   storage_device = "ubi";
> > +   mtdpart = "UBI",
> > +   ubivol = "ubi0";
> I'm not sure about ubi. It needs to refer to a particular device I
> suppose. How do we know the mapping from ubi to device?
> 
Actually this design is based on file system implementation which is
abstract from physical device, storage_device is used as interface of
file system, so nand and qspi may having the same ubi interface.

May be i can change the storage_device into storage_interface to avoid
confusing. 
> > 
> > +   };
> > --
> > 2.2.0
> > 
> Regards,
> Simon

Re: [U-Boot] [PATCH v2] common/memsize.c: Increase save array for supporting memory size > 4GB

[Chee, Tien Fong]

On Thu, 2018-06-21 at 06:34 +0200, Marek Vasut wrote:
> On 06/20/2018 09:06 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > In ARM 64-bits, memory size can be supported is more than 4GB,
> > hence increasing save array is needed to cope with testing larger
> > memory.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> > 
> > Changes in v2:
> > - Change save array size to save[BITS_PER_LONG - 1]
> > ---
> >  common/memsize.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/common/memsize.c b/common/memsize.c
> > index 5670e95..13b0047 100644
> > --- a/common/memsize.c
> > +++ b/common/memsize.c
> > @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >  long get_ram_size(long *base, long maxsize)
> >  {
> >     volatile long *addr;
> > -   long   save[31];
> > +   long   save[BITS_PER_LONG - 1];
> >     long   save_base;
> >     long   cnt;
> >     long   val;
> > 
> Does this work with LPAE systems, where bits per long == 32 and the
> address space is bigger ? Or with similar setups ? I mean, you can
> have
> > 
> > 4 GiB of RAM on 32bit system ...
This function is designed to work with 32bit or 64 bits system, for
example the argument such as maxsize can be 32bit or 64 bit, if value
larger than 4GiB is passed as maxsize argument with 32bit system, the
whole thing will go wrong.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] common/memsize.c: Increase save array for supporting memory size > 4GB

[Chee, Tien Fong]

On Mon, 2018-06-18 at 12:59 -0400, Tom Rini wrote:
> On Wed, Jun 13, 2018 at 03:32:43PM +0800, tien.fong.c...@intel.com
> wrote:
> 
> > 
> > From: Tien Fong Chee 
> > 
> > In ARM 64-bits, memory size can be supported is more than 4GB,
> > hence increasing save array is needed to cope with testing larger
> > memory.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  common/memsize.c |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> > 
> > diff --git a/common/memsize.c b/common/memsize.c
> > index 5670e95..b091203 100644
> > --- a/common/memsize.c
> > +++ b/common/memsize.c
> > @@ -26,7 +26,7 @@ DECLARE_GLOBAL_DATA_PTR;
> >  long get_ram_size(long *base, long maxsize)
> >  {
> >     volatile long *addr;
> > -   long   save[31];
> > +   long   save[BITS_PER_LONG];
> >     long   save_base;
> >     long   cnt;
> >     long   val;
> Since BITS_PER_LONG is 32 or 64, shouldn't we use B_P_L - 1 here?  Or
> are you saying there's also a case where this is wrong on 32bit
> today?
As long as the array is large enough to cope with shifting
implementation, then it should be fine. For 32-bit, only 31 units in
array required for storing 31 shifting values, and this apply for 64-
bit also as long as the implementation of first shifting value is not
change(cnt = (maxsize / sizeof(long)) >> 1).
IMO, for simplifying and safety purpose(may be one day implementation
change to "cnt = (maxsize / sizeof(long))", above B_P_L is still
workable.
> Thanks!
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-11 at 13:38 -0600, Simon Glass wrote:
> Hi,
> 
> On 11 June 2018 at 08:15, Marek Vasut  wrote:
> > 
> > On 06/11/2018 04:13 PM, Chee, Tien Fong wrote:
> > > 
> > > On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
> > > > 
> > > > On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
> > > > [...]
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Linux firmware loading method is different with this
> > > > > > > > > Linux loading firmware with
> > > > > > > > > 1. Firmware search paths - which is hardcoded in root
> > > > > > > > > file
> > > > > > > > > system
> > > > > > > > > 2. Built-in firmware - part of kernel binaries
> > > > > > > > > 
> > > > > > > > > This patch loading firmware with
> > > > > > > > > 1. Storage type and partition specified in DTS, but
> > > > > > > > > storage
> > > > > > > > > type
> > > > > > > > > can
> > > > > > > > > be overridden dev instance and partition through U-
> > > > > > > > > boot
> > > > > > > > > variable
> > > > > > > > > environment.
> > > > > > > > > 
> > > > > > > > > Or:
> > > > > > > > > 
> > > > > > > > > 2. Storage type can be set through dev instance, and
> > > > > > > > > partition
> > > > > > > > > through
> > > > > > > > > U-boot variable environment. No DTS is required.
> > > > > > > > And why can we not do as Linux does ?
> > > > > > > > 
> > > > > > > Because we don't have root file system, but i have
> > > > > > > mimicked the
> > > > > > > search
> > > > > > > path in our variable environment, but with both storage
> > > > > > > type
> > > > > > > and
> > > > > > > partition.
> > > > > > OK, so user can configure environment variable to inform U-
> > > > > > Boot
> > > > > > where
> > > > > > to
> > > > > > look for firmware, good (although, this probably fails in
> > > > > > early
> > > > > > env,
> > > > > > dunno of that's a problem).
> > > > > > 
> > > > > Without DTS, then you need to configure env variable, so that
> > > > > SPL
> > > > > and
> > > > > U-boot only know what storage type and partiton to look for
> > > > > firmware.
> > > > I guess that's fine ?
> > > > 
> > > Yes, it is already supported in this patches.
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > But why do we need the DT part of things ? I don't think we
> > > > > > do
> > > > > > need
> > > > > > it
> > > > > > at all.
> > > > > > 
> > > > > Leverage the flexibility and benefits of the DT such as
> > > > > changing
> > > > > both
> > > > > storage type and partitions without changing the codes.
> > > > DT is a hardware description. Does this describe hardware ? No
> > > > 
> > > Okay, then i will remove DT part.
> > Wait for feedback from sjg at least.
> I think using device tree is fine for this, but I suggest that the
> binding file (when you add it) should mention that the node for this
> driver should go in /chosen. That's what we use for settings, etc.
> 
Okay, sure. So, we agree supporting device tree is good to go.

> Things to do:
> - Add a sandbox driver for this uclass, and a test in test/dm/...
> - Add some documentation about it somehwere
> - Add a device-tree binding file - see doc/device-tree-bindings
> 
Okay, let me try.

> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-11 at 16:03 +0200, Marek Vasut wrote:
> On 06/11/2018 03:55 PM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > Linux firmware loading method is different with this
> > > > > > Linux loading firmware with
> > > > > > 1. Firmware search paths - which is hardcoded in root file
> > > > > > system
> > > > > > 2. Built-in firmware - part of kernel binaries
> > > > > > 
> > > > > > This patch loading firmware with
> > > > > > 1. Storage type and partition specified in DTS, but storage
> > > > > > type
> > > > > > can
> > > > > > be overridden dev instance and partition through U-boot
> > > > > > variable
> > > > > > environment.
> > > > > > 
> > > > > > Or:
> > > > > > 
> > > > > > 2. Storage type can be set through dev instance, and
> > > > > > partition
> > > > > > through
> > > > > > U-boot variable environment. No DTS is required.
> > > > > And why can we not do as Linux does ?
> > > > > 
> > > > Because we don't have root file system, but i have mimicked the
> > > > search
> > > > path in our variable environment, but with both storage type
> > > > and
> > > > partition.
> > > OK, so user can configure environment variable to inform U-Boot
> > > where
> > > to
> > > look for firmware, good (although, this probably fails in early
> > > env,
> > > dunno of that's a problem).
> > > 
> > Without DTS, then you need to configure env variable, so that SPL
> > and
> > U-boot only know what storage type and partiton to look for
> > firmware.
> I guess that's fine ?
> 
Yes, it is already supported in this patches.
> > 
> > > 
> > > But why do we need the DT part of things ? I don't think we do
> > > need
> > > it
> > > at all.
> > > 
> > Leverage the flexibility and benefits of the DT such as changing
> > both
> > storage type and partitions without changing the codes. 
> DT is a hardware description. Does this describe hardware ? No
> 
Okay, then i will remove DT part.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-11 at 15:38 +0200, Marek Vasut wrote:
> On 06/11/2018 02:42 PM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote:
> > > 
> > > On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > This is a configuration. You do not need (new) a DT
> > > > > > > > > compatible
> > > > > > > > > for
> > > > > > > > > that.
> > > > > > > > > So why is the DT compatible even needed in the FW
> > > > > > > > > loader
> > > > > > > > > at
> > > > > > > > > all ?
> > > > > > > > > 
> > > > > > > > I thought DT compatible is used by driver to find the
> > > > > > > > fs_loader
> > > > > > > > node in
> > > > > > > > DTS. May be i am wrong.
> > > > > > > There should be no FW loader in the DTS. Why would there
> > > > > > > be
> > > > > > > one ?
> > > > > > > 
> > > > > >  I added DTS support for user to define storage type and
> > > > > > default
> > > > > > partition. So you want me to remove the DTS?
> > > > > > Removing the DTS, then user can only set storage type and
> > > > > > partition
> > > > > > through dev instance. So, this design OK for you?
> > > > > How does Linux do it ?
> > > > > 
> > > > Linux firmware loading method is different with this
> > > > Linux loading firmware with
> > > > 1. Firmware search paths - which is hardcoded in root file
> > > > system
> > > > 2. Built-in firmware - part of kernel binaries
> > > > 
> > > > This patch loading firmware with
> > > > 1. Storage type and partition specified in DTS, but storage
> > > > type
> > > > can
> > > > be overridden dev instance and partition through U-boot
> > > > variable
> > > > environment.
> > > > 
> > > > Or:
> > > > 
> > > > 2. Storage type can be set through dev instance, and partition
> > > > through
> > > > U-boot variable environment. No DTS is required.
> > > And why can we not do as Linux does ?
> > > 
> > Because we don't have root file system, but i have mimicked the
> > search
> > path in our variable environment, but with both storage type and
> > partition.
> OK, so user can configure environment variable to inform U-Boot where
> to
> look for firmware, good (although, this probably fails in early env,
> dunno of that's a problem).
> 
Without DTS, then you need to configure env variable, so that SPL and
U-boot only know what storage type and partiton to look for firmware.

> But why do we need the DT part of things ? I don't think we do need
> it
> at all.
> 
Leverage the flexibility and benefits of the DT such as changing both
storage type and partitions without changing the codes. 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-11 at 13:55 +0200, Marek Vasut wrote:
> On 06/11/2018 01:53 PM, Chee, Tien Fong wrote:
> > 
> > On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> > > 
> > > On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> > > [...]
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > This is a configuration. You do not need (new) a DT
> > > > > > > compatible
> > > > > > > for
> > > > > > > that.
> > > > > > > So why is the DT compatible even needed in the FW loader
> > > > > > > at
> > > > > > > all ?
> > > > > > > 
> > > > > > I thought DT compatible is used by driver to find the
> > > > > > fs_loader
> > > > > > node in
> > > > > > DTS. May be i am wrong.
> > > > > There should be no FW loader in the DTS. Why would there be
> > > > > one ?
> > > > > 
> > > >  I added DTS support for user to define storage type and
> > > > default
> > > > partition. So you want me to remove the DTS?
> > > > Removing the DTS, then user can only set storage type and
> > > > partition
> > > > through dev instance. So, this design OK for you?
> > > How does Linux do it ?
> > > 
> > Linux firmware loading method is different with this
> > Linux loading firmware with
> > 1. Firmware search paths - which is hardcoded in root file system
> > 2. Built-in firmware - part of kernel binaries
> > 
> > This patch loading firmware with
> > 1. Storage type and partition specified in DTS, but storage type
> > can
> > be overridden dev instance and partition through U-boot variable
> > environment.
> > 
> > Or:
> > 
> > 2. Storage type can be set through dev instance, and partition
> > through
> > U-boot variable environment. No DTS is required.
> And why can we not do as Linux does ?
> 
Because we don't have root file system, but i have mimicked the search
path in our variable environment, but with both storage type and
partition.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Mon, 2018-06-11 at 11:39 +0200, Marek Vasut wrote:
> On 06/11/2018 07:01 AM, Chee, Tien Fong wrote:
> [...]
> > 
> > > 
> > > > 
> > > > > 
> > > > > This is a configuration. You do not need (new) a DT
> > > > > compatible
> > > > > for
> > > > > that.
> > > > > So why is the DT compatible even needed in the FW loader at
> > > > > all ?
> > > > > 
> > > > I thought DT compatible is used by driver to find the fs_loader
> > > > node in
> > > > DTS. May be i am wrong.
> > > There should be no FW loader in the DTS. Why would there be one ?
> > > 
> >  I added DTS support for user to define storage type and default
> > partition. So you want me to remove the DTS?
> > Removing the DTS, then user can only set storage type and partition
> > through dev instance. So, this design OK for you?
> How does Linux do it ?
> 
Linux firmware loading method is different with this
Linux loading firmware with
1. Firmware search paths - which is hardcoded in root file system
2. Built-in firmware - part of kernel binaries

This patch loading firmware with
1. Storage type and partition specified in DTS, but storage type can
be overridden dev instance and partition through U-boot variable
environment.

Or:

2. Storage type can be set through dev instance, and partition through
U-boot variable environment. No DTS is required.

> [...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] include: dma: Update the function description for dma_memcpy

[Chee, Tien Fong]

On Fri, 2018-06-08 at 13:59 -0800, Simon Glass wrote:
> Hi,
> 
> On 3 June 2018 at 23:14, Chee, Tien Fong 
> wrote:
> > 
> > On Fri, 2018-06-01 at 08:25 -0600, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 31 May 2018 at 02:08,   wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > Update the dma_memcpy description on return argument for DMA330
> > > > driver.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > >  include/dma.h | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/include/dma.h b/include/dma.h
> > > > index 0a0c9dd..b825c1e 100644
> > > > --- a/include/dma.h
> > > > +++ b/include/dma.h
> > > > @@ -79,8 +79,8 @@ int dma_get_device(u32 transfer_type, struct
> > > > udevice **devp);
> > > >   * @dst - destination pointer
> > > >   * @src - souce pointer
> > > >   * @len - data length to be copied
> > > > - * @return - on successful transfer returns no of bytes
> > > > -transferred and on failure return error code.
> > > > + * @return - on successful transfer returns no of bytes or
> > > > zero(for DMA330)
> > > > + *  transferred and on failure return error code.
> > > This is a public API so you cannot change it just for one device.
> > > You
> > > can change the API for everyone if you like.
> > > 
> > > But why would it want to return 0?
> > > 
> > Because we only able to check the DMA tranferring status, full
> > transfer
> > or failed. I can return the len argument user set if full tranfer
> > is
> > finished.
> OK. My concern is that you have a comment saying that the function
> does something different for one device versus others. This is not
> the
> place for such a comment. Here you can just document that it can
> return two possible meanings. You should add comments explaining what
> 0 means too (e.g. completed, but length unknown?).
> 
> For something in progress, you should use -EINPROGRESS / -EAGAIN
> 
Okay.
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-06-07 at 12:29 +0200, Marek Vasut wrote:
> On 06/07/2018 12:11 PM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 05/24/2018 07:04 AM, tien.fong.c...@intel.com
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > From: Tien Fong Chee 
> > > > > > > > > > 
> > > > > > > > > > This is file system generic loader which can be
> > > > > > > > > > used to
> > > > > > > > > > load
> > > > > > > > > > the file image from the storage into target such as
> > > > > > > > > > memory.
> > > > > > > > > > The consumer driver would then use this loader to
> > > > > > > > > > program
> > > > > > > > > > whatever,
> > > > > > > > > > ie. the FPGA device.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > > > .com
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > ---
> > > > > > > > > [...]
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > > > > > +{
> > > > > > > > > > +   return 0;
> > > > > > > > > > +};
> > > > > > > > > > +
> > > > > > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > > > > > +   { .compatible = "fs_loader"},
> > > > > > > > > Why exactly is there a DT compatible for a firmware
> > > > > > > > > loader?
> > > > > > > > > 
> > > > > > > > Correct me if i'm wrong, this is required to look the
> > > > > > > > platform
> > > > > > > > data
> > > > > > > > from DTS, right? Details of DTS in patch 2.
> > > > > > > How so ? The FW loader should behave as a library for
> > > > > > > other
> > > > > > > drivers
> > > > > > > to
> > > > > > > use, not like a driver.
> > > > > > > 
> > > > > > The fs_loader node in DTS just provide a way for user to
> > > > > > tell
> > > > > > the
> > > > > > firmware loader what storage device and default partition
> > > > > > to
> > > > > > load
> > > > > > data
> > > > > > from. Default partition can be overriden through the
> > > > > > variable
> > > > > > environment.
> > > > > So that's sitting in 

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-06-07 at 11:50 +0200, Marek Vasut wrote:
> On 06/07/2018 11:45 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 05/24/2018 07:04 AM, tien.fong.c...@intel.com wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > From: Tien Fong Chee 
> > > > > > > > 
> > > > > > > > This is file system generic loader which can be used to
> > > > > > > > load
> > > > > > > > the file image from the storage into target such as
> > > > > > > > memory.
> > > > > > > > The consumer driver would then use this loader to
> > > > > > > > program
> > > > > > > > whatever,
> > > > > > > > ie. the FPGA device.
> > > > > > > > 
> > > > > > > > Signed-off-by: Tien Fong Chee  > > > > > > > >
> > > > > > > > ---
> > > > > > > [...]
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > > > +{
> > > > > > > > +   return 0;
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > > > +   { .compatible = "fs_loader"},
> > > > > > > Why exactly is there a DT compatible for a firmware
> > > > > > > loader?
> > > > > > > 
> > > > > > Correct me if i'm wrong, this is required to look the
> > > > > > platform
> > > > > > data
> > > > > > from DTS, right? Details of DTS in patch 2.
> > > > > How so ? The FW loader should behave as a library for other
> > > > > drivers
> > > > > to
> > > > > use, not like a driver.
> > > > > 
> > > > The fs_loader node in DTS just provide a way for user to tell
> > > > the
> > > > firmware loader what storage device and default partition to
> > > > load
> > > > data
> > > > from. Default partition can be overriden through the variable
> > > > environment.
> > > So that's sitting in the chosen node ? But why do you need to
> > > match
> > > on it ?
> > > 
> > This is new device tree binding for firmware loader called
> > fs_loader
> > node. firmware loader need to know where is the storage device it
> > need
> > to load from. Those storage device would be defined in fs_loader
> > node.
> This is a configuration. You do not need (new) a DT compatible for
> that.
> So why is the DT compatible even needed in the FW loader at all ?
> 
I thought DT compatible is used by driver to find the fs_loader node in
DTS. May be i am wrong.
> > 
> > > 
> > > > 
> > > > Caller/other drivers can create different firmware loader
> > > > instance
> > > > based on different fs_loader node(different storage device) for
> > > > their
> > > > loading purpose.
> > > They can, but that could be done even without the DT compatible.
> > > 
> > Yes, once you get dev, you can set the storage type and partiiton
> > attributes through accessing dev->platdata.
> Can you show me the DT patch needed for this to work ?
> 
I can send you the patches separately, but this driver is designed to
work with/without DT.
> > 
> > > 
> > > > 
> > > > Why this cannot be used by other driver?
> > > I don't understand the question.
> > > 
> > I means why u say this firmware loader cannot be used by other
> > drivers.
> > I have tested with FPGA Manager driver(as caller).
> It must be used by other drivers, that is the point.
> 
yes, it can be used by FPGA manager driver.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-06-07 at 10:41 +0200, Marek Vasut wrote:
> On 06/07/2018 10:36 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> > > 
> > > On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 05/24/2018 07:04 AM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > This is file system generic loader which can be used to
> > > > > > load
> > > > > > the file image from the storage into target such as memory.
> > > > > > The consumer driver would then use this loader to program
> > > > > > whatever,
> > > > > > ie. the FPGA device.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > [...]
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > +static int fs_loader_probe(struct udevice *dev)
> > > > > > +{
> > > > > > +   return 0;
> > > > > > +};
> > > > > > +
> > > > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > > > +   { .compatible = "fs_loader"},
> > > > > Why exactly is there a DT compatible for a firmware loader?
> > > > > 
> > > > Correct me if i'm wrong, this is required to look the platform
> > > > data
> > > > from DTS, right? Details of DTS in patch 2.
> > > How so ? The FW loader should behave as a library for other
> > > drivers
> > > to
> > > use, not like a driver.
> > > 
> > The fs_loader node in DTS just provide a way for user to tell the
> > firmware loader what storage device and default partition to load
> > data
> > from. Default partition can be overriden through the variable
> > environment.
> So that's sitting in the chosen node ? But why do you need to match
> on it ?
> 
This is new device tree binding for firmware loader called fs_loader
node. firmware loader need to know where is the storage device it need
to load from. Those storage device would be defined in fs_loader node.
> > 
> > Caller/other drivers can create different firmware loader instance
> > based on different fs_loader node(different storage device) for
> > their
> > loading purpose.
> They can, but that could be done even without the DT compatible.
> 
Yes, once you get dev, you can set the storage type and partiiton
attributes through accessing dev->platdata.
> > 
> > Why this cannot be used by other driver?
> I don't understand the question.
> 
I means why u say this firmware loader cannot be used by other drivers.
I have tested with FPGA Manager driver(as caller).
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Thu, 2018-06-07 at 08:51 +0200, Marek Vasut wrote:
> On 06/07/2018 06:04 AM, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> > > 
> > > On 05/24/2018 07:04 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee 
> > > > ---
> > > [...]
> > > > 
> > > > 
> > > > +static int fs_loader_probe(struct udevice *dev)
> > > > +{
> > > > +   return 0;
> > > > +};
> > > > +
> > > > +static const struct udevice_id fs_loader_ids[] = {
> > > > +   { .compatible = "fs_loader"},
> > > Why exactly is there a DT compatible for a firmware loader?
> > > 
> > Correct me if i'm wrong, this is required to look the platform data
> > from DTS, right? Details of DTS in patch 2.
> How so ? The FW loader should behave as a library for other drivers
> to
> use, not like a driver.
> 
The fs_loader node in DTS just provide a way for user to tell the
firmware loader what storage device and default partition to load data
from. Default partition can be overriden through the variable
environment.

Caller/other drivers can create different firmware loader instance
based on different fs_loader node(different storage device) for their
loading purpose.

Why this cannot be used by other driver?
> > 
> > > 
> > > > 
> > > > 
> > > > +   { }
> > > > +};
> > > > +
> > > > +U_BOOT_DRIVER(fs_loader) = {
> > > > +   .name   = "fs_loader",
> > > > +   .id =
> > > > UCLASS_FS_FIRMWARE_LOADER,
> > > > +   .of_match   = fs_loader_ids,
> > > > +   .probe  = fs_loader_probe,
> > > > +   .ofdata_to_platdata =
> > > > fs_loader_ofdata_to_platdata,
> > > > +   .platdata_auto_alloc_size   = sizeof(struct
> > > > device_platdata),
> > > > +};
> > > > +
> > > > +UCLASS_DRIVER(fs_loader) = {
> > > > +   .id = UCLASS_FS_FIRMWARE_LOADER,
> > > > +   .name   = "fs_loader",
> > > > +};
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] common: Generic loader for file system

[Chee, Tien Fong]

On Wed, 2018-06-06 at 10:39 +0200, Marek Vasut wrote:
> On 05/24/2018 07:04 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> [...]
> > 
> > +static int fs_loader_probe(struct udevice *dev)
> > +{
> > +   return 0;
> > +};
> > +
> > +static const struct udevice_id fs_loader_ids[] = {
> > +   { .compatible = "fs_loader"},
> Why exactly is there a DT compatible for a firmware loader?
> 
Correct me if i'm wrong, this is required to look the platform data
from DTS, right? Details of DTS in patch 2.
> > 
> > +   { }
> > +};
> > +
> > +U_BOOT_DRIVER(fs_loader) = {
> > +   .name   = "fs_loader",
> > +   .id = UCLASS_FS_FIRMWARE_LOADER,
> > +   .of_match   = fs_loader_ids,
> > +   .probe  = fs_loader_probe,
> > +   .ofdata_to_platdata = fs_loader_ofdata_to_platdata,
> > +   .platdata_auto_alloc_size   = sizeof(struct
> > device_platdata),
> > +};
> > +
> > +UCLASS_DRIVER(fs_loader) = {
> > +   .id = UCLASS_FS_FIRMWARE_LOADER,
> > +   .name   = "fs_loader",
> > +};
> [...]
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] drivers: dma: Enable DMA-330 driver support

[Chee, Tien Fong]

On Fri, 2018-06-01 at 08:24 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 31 May 2018 at 02:08,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Enable DMAC driver support for DMA-330 controller.
> > The driver is also compatible to PL330 product.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/dma/Kconfig  |9 +-
> >  drivers/dma/Makefile |1 +
> >  drivers/dma/dma330.c | 1514
> > ++
> >  include/dma330.h |  136 +
> >  4 files changed, 1659 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/dma/dma330.c
> >  create mode 100644 include/dma330.h
> > 
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 4ee6afa..6e77e07 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -2,7 +2,7 @@ menu "DMA Support"
> > 
> >  config DMA
> > bool "Enable Driver Model for DMA drivers"
> > -   depends on DM
> > +   depends on DM || SPL_DM
> > help
> >   Enable driver model for DMA. DMA engines can do
> >   asynchronous data transfers without involving the host
> > @@ -34,4 +34,11 @@ config APBH_DMA_BURST8
> > 
> >  endif
> > 
> > +config DMA330_DMA
> > +   bool "PL330/DMA-330 DMA Controller(DMAC) driver"
> > +   depends on DMA
> > +   help
> > +Enable the DMA controller driver for both PL330 and
> > +DMA-330 products.
> > +
> >  endmenu # menu "DMA Support"
> > diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> > index 4eaef8a..bfad0dd 100644
> > --- a/drivers/dma/Makefile
> > +++ b/drivers/dma/Makefile
> > @@ -11,3 +11,4 @@ obj-$(CONFIG_FSL_DMA) += fsl_dma.o
> >  obj-$(CONFIG_TI_KSNAV) += keystone_nav.o keystone_nav_cfg.o
> >  obj-$(CONFIG_TI_EDMA3) += ti-edma3.o
> >  obj-$(CONFIG_DMA_LPC32XX) += lpc32xx_dma.o
> > +obj-$(CONFIG_DMA330_DMA) += dma330.o
> > diff --git a/drivers/dma/dma330.c b/drivers/dma/dma330.c
> > new file mode 100644
> > index 000..66575d8
> > --- /dev/null
> > +++ b/drivers/dma/dma330.c
> > @@ -0,0 +1,1514 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Register and Bit field Definitions */
> > +
> > +/* DMA Status */
> > +#define DS 0x0
> > +#define DS_ST_STOP 0x0
> > +#define DS_ST_EXEC 0x1
> > +#define DS_ST_CMISS0x2
> > +#define DS_ST_UPDTPC   0x3
> > +#define DS_ST_WFE  0x4
> > +#define DS_ST_ATBRR0x5
> > +#define DS_ST_QBUSY0x6
> > +#define DS_ST_WFP  0x7
> > +#define DS_ST_KILL 0x8
> > +#define DS_ST_CMPLT0x9
> > +#define DS_ST_FLTCMP   0xe
> > +#define DS_ST_FAULT0xf
> It is possible to use enum for some of these?
> 
> enum {
>    DS = 0,
>    DS_ST_STOP,
>  ...
> }
> 
Okay.
> > 
> > +
> > +/* DMA Program Count register */
> > +#define DPC0x4
> > +/* Interrupt Enable register */
> > +#define INTEN  0x20
> > +/* event-Interrupt Raw Status register */
> > +#define ES 0x24
> > +/* Interrupt Status register */
> > +#define INTSTATUS  0x28
> > +/* Interrupt Clear register */
> > +#define INTCLR 0x2c
> > +/* Fault Status DMA Manager register */
> > +#define FSM0x30
> > +/* Fault Status DMA Channel register */
> > +#define FSC0x34
> > +/* Fault Type DMA Manager register */
> > +#define FTM0x38
> > +
> > +/* Fault Type DMA Channel register */
> > +#define _FTC   0x40
> > +#define FTC(n) (_FTC + (n) * 0x4)
> > +
> > +/* Channel Status register */
> > +#define _CS0x100
> > +#define CS(n)  (_CS + (n) * 0x8)
> > +#define CS_CNS BIT(21)
> > +
> > +/* Channel Program Counter register */
> > +#define _CPC   0x104
> > +#define CPC(n) (_CPC + (n) * 0x8)
> > +
> > +/* Source Address register */
> > +#define _SA0x400
> > +#define SA(n)  (_SA + (n) * 0x20)
> > +
> > +/* Destination Address register */
> > +#define _DA0x404
> > +#define DA(n)  (_DA + (n) * 0x20)
> > +
> > +/* Channel Control register */
> > +#define _CC0x408
> > +#define CC(n)  (_CC + (n) * 0x20)
> > +
> > +/* Channel Control register (CCR) Setting */
> > +#define CC_SRCINC  BIT(0)
> > +#define CC_DSTINC  BIT(14)
> > +#define CC_SRCPRI  BIT(8)
> > +#define CC_DSTPRI  BIT(22)
> > +#define CC_SRCNS   BIT(9)
> > +#define CC_DSTNS   BIT(23)
> > +#define CC_SRCIA   BIT(10)
> > +#define CC_DSTIA   BIT(24)
> > +#define CC_SRCBRSTLEN_SHFT 4
> > +#define 

Re: [U-Boot] [PATCH v2 0/3] Generic file system firmware loader DM

[Chee, Tien Fong]

On Thu, 2018-05-24 at 13:04 +0800, tien.fong.c...@intel.com wrote:
Hi All,
> From: Tien Fong Chee 
> 
> This patchset contains generic file system loader DM which is very
> close to
> Linux firmware loader but for U-Boot framework. Generic file system
> firmware
> loader can be used load whatever into target location, and then
> consumer driver
> would use it to program whatever, ie. the FPGA. This version mainly
> resolved
> comments from Tom Rini in [v1].
> 
> This series is working on top of u-boot-socfpga.git -
>  http://git.denx.de/u-boot.git .
> 
> [v1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg286294.htm
> l
> 
> v1 -> v2 changes
> 
> - Changed the documents to rST format.
> 
Any comment on this patchset? Good to go :)?
> Tien Fong Chee (3):
>   doc: Add new doc for file system firmware loader driver model
>   doc: dtbinding: Add file system firmware loader binding document
>   common: Generic loader for file system
> 
>  doc/device-tree-bindings/misc/fs_loader.txt |  50 ++
>  doc/driver-model/fs_firmware_loader.txt | 103 
>  drivers/misc/Kconfig|  11 ++
>  drivers/misc/Makefile   |   1 +
>  drivers/misc/fs_loader.c| 240
> 
>  include/dm/uclass-id.h  |   1 +
>  include/fs_loader.h |  28 
>  7 files changed, 434 insertions(+)
>  create mode 100644 doc/device-tree-bindings/misc/fs_loader.txt
>  create mode 100644 doc/driver-model/fs_firmware_loader.txt
>  create mode 100644 drivers/misc/fs_loader.c
>  create mode 100644 include/fs_loader.h
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] drivers: dma: Add function to zeroes a range of destination such as memory

[Chee, Tien Fong]

On Fri, 2018-06-01 at 08:24 -0600, Simon Glass wrote:
> Hi Tien,
> 
> On 31 May 2018 at 02:08,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This new DMA class function enables DMA being used for initializing
> > a range of destination such as memory to zeros. This is quite
> > useful to
> > help accelerating the performance in scrubbing memory when ECC is
> > enabled.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/dma/dma-uclass.c | 15 +++
> >  include/dma.h| 12 
> >  2 files changed, 27 insertions(+)
> > 
> > diff --git a/drivers/dma/dma-uclass.c b/drivers/dma/dma-uclass.c
> > index a33f7d5..cb83c24 100644
> > --- a/drivers/dma/dma-uclass.c
> > +++ b/drivers/dma/dma-uclass.c
> > @@ -61,6 +61,21 @@ int dma_memcpy(void *dst, void *src, size_t len)
> > return ops->transfer(dev, DMA_MEM_TO_MEM, dst, src, len);
> >  }
> > 
> > +int dma_memcpy_zeroes(struct udevice *dev, void *dst, size_t len)
> > +{
> > +   const struct dma_ops *ops;
> > +
> > +   ops = device_get_ops(dev);
> > +   if (!ops->transfer_zeroes)
> > +   return -ENOSYS;
> > +
> > +   /* Invalidate the area, so no writeback into the RAM races
> > with DMA */
> > +   invalidate_dcache_range((unsigned long)dst, (unsigned
> > long)dst +
> > +   roundup(len, ARCH_DMA_MINALIGN));
> > +
> > +   return ops->transfer_zeroes(dev, dst, len);
> > +}
> > +
> >  UCLASS_DRIVER(dma) = {
> > .id = UCLASS_DMA,
> > .name   = "dma",
> > diff --git a/include/dma.h b/include/dma.h
> > index 50e9652..6bad2264 100644
> > --- a/include/dma.h
> > +++ b/include/dma.h
> > @@ -46,6 +46,7 @@ struct dma_ops {
> >  */
> > int (*transfer)(struct udevice *dev, int direction, void
> > *dst,
> > void *src, size_t len);
> > +   int (*transfer_zeroes)(struct udevice *dev, void *dst,
> > size_t len);
> I wonder if this could be done by using transfer() with a src of NULL
> ?
> 
Yes, may be with some description about src of NULL(just for DMA330
driver) on the doc. Otherwise, it would confuse people, and other DMA
driver may treating src with NULL as error or address 0x0.
What do you think?
> > 
> >  };
> > 
> >  /*
> > @@ -82,4 +83,15 @@ int dma_get_device(u32 transfer_type, struct
> > udevice **devp);
> >   */
> >  int dma_memcpy(void *dst, void *src, size_t len);
> > 
> > +/*
> > + * dma_memcpy_zeroes - Fill up destination with zeros through DMA.
> > + *
> > + * @dev: The DMA device
> > + * @dst: destination pointer
> > + * @len: length to be copied with zero
> > + * @return: on successful transfer returns zero.
> > + * on failure returns error code.
> > + */
> > +int dma_memcpy_zeroes(struct udevice *dev, void *dst, size_t len);
> > +
> >  #endif /* _DMA_H_ */
> > --
> > 2.2.0
> > 
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/5] include: dma: Update the function description for dma_memcpy

[Chee, Tien Fong]

On Fri, 2018-06-01 at 08:25 -0600, Simon Glass wrote:
> Hi,
> 
> On 31 May 2018 at 02:08,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Update the dma_memcpy description on return argument for DMA330
> > driver.
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  include/dma.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/dma.h b/include/dma.h
> > index 0a0c9dd..b825c1e 100644
> > --- a/include/dma.h
> > +++ b/include/dma.h
> > @@ -79,8 +79,8 @@ int dma_get_device(u32 transfer_type, struct
> > udevice **devp);
> >   * @dst - destination pointer
> >   * @src - souce pointer
> >   * @len - data length to be copied
> > - * @return - on successful transfer returns no of bytes
> > -transferred and on failure return error code.
> > + * @return - on successful transfer returns no of bytes or
> > zero(for DMA330)
> > + *  transferred and on failure return error code.
> This is a public API so you cannot change it just for one device. You
> can change the API for everyone if you like.
> 
> But why would it want to return 0?
> 
Because we only able to check the DMA tranferring status, full transfer
or failed. I can return the len argument user set if full tranfer is
finished.
> > 
> >   */
> >  int dma_memcpy(struct udevice *dev, void *dst, void *src, size_t
> > len);
> > 
> > --
> > 2.2.0
> > 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 5/5] arm: dts: socfpga: stratix10: update pdma

[Chee, Tien Fong]

On Fri, 2018-06-01 at 08:25 -0600, Simon Glass wrote:
> On 31 May 2018 at 02:08,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Update pdma properties for Stratix 10
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/dts/socfpga_stratix10.dtsi | 20 
> >  1 file changed, 20 insertions(+)
> Reviewed-by: Simon Glass 
> 
> Is there a DT binding file for this somewhere?
Yeah, it is in linux/Documentation
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/
bindings/dma/arm-pl330.txt

I can port over to U-boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/5] Add DMA driver for DMA330 controller

[Chee, Tien Fong]

On Thu, 2018-05-31 at 11:58 +0200, Marek Vasut wrote:
> On 05/31/2018 11:50 AM, See, Chin Liang wrote:
> > 
> > On Thu, 2018-05-31 at 11:24 +0200, Marek Vasut wrote:
> > > 
> > > On 05/31/2018 10:08 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee 
> > > > 
> > > > This patchset contains dm driver for DMA330 controller.
> > > > 
> > > > This series is working on top of u-boot-socfpga.git -
> > > >  http://git.denx.de/u-boot.git .
> > > > 
> > > > Tien Fong Chee (5):
> > > >   drivers: dma: Enable DMA-330 driver support
> > > >   drivers: dma: Add function to zeroes a range of destination
> > > > such
> > > > as
> > > > memory
> > > >   drivers: dma: Factor out dma_get_device from DMA class
> > > > function
> > > >   include: dma: Update the function description for dma_memcpy
> > > >   arm: dts: socfpga: stratix10: update pdma
> > > > 
> > > >  arch/arm/dts/socfpga_stratix10.dtsi |   20 +
> > > >  drivers/dma/Kconfig |9 +-
> > > >  drivers/dma/Makefile|1 +
> > > >  drivers/dma/dma-uclass.c|   23 +-
> > > >  drivers/dma/dma330.c| 1514
> > > > +++
> > > >  drivers/mtd/spi/spi_flash.c |9 +-
> > > >  include/dma.h   |   19 +-
> > > >  include/dma330.h|  136 
> > > >  8 files changed, 1719 insertions(+), 12 deletions(-)
> > > >  create mode 100644 drivers/dma/dma330.c
> > > >  create mode 100644 include/dma330.h
> > > > 
> > > I presume this is to zero-out the ECC RAM ? Just enable caches
> > > and
> > > use
> > > memset, it is much faster than this DMA witchcraft, at least on
> > > the
> > > A10.
> > Yes and no :) 
> > 
> > The patch enable DMA-330 support and also zero-out ECC RAM. 
> Right, that's what I said ?
> 
This driver also enable source to destination transferring through DMA.
> > 
> > While for the speed, DMA still faster as it has larger burst size.
> It takes ~0.9s to erase 2 GiB of RAM on the A10. How fast is the DMA?
> 
That is pretty fast. Using DMA dm on Stratix 10 also need around 3-4s
for 2GiB DRAM.

Would you mind to share us the codes for enabling the both cache and
MMU in SPL. I would like to replicate your changes at Stratix 10 for
the performance measurement.
> > 
> > We
> > can also parallel the zero out task with other tasks such as flash
> > controller init.
> The flash controller also needs some zeroing out ?
> 
I believe what Chin Liang saying is CPU is free to do other HW
initialization while DMA is zeroing the DRAM.

However, current driver is blocking, which means CPU has to wait the
DMA finish transferring.

I can pull the DMA transfer status check function out as a new class
function so user can check the DMA status at anytime.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Chee, Tien Fong]

On Fri, 2018-05-18 at 10:42 +0200, Marek Vasut wrote:
> On 05/18/2018 10:39 AM, Chee, Tien Fong wrote:
> > 
> > On Fri, 2018-05-18 at 09:50 +0200, Marek Vasut wrote:
> > > 
> > > On 05/18/2018 06:41 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-05-17 at 11:38 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 05/17/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Thu, 2018-05-17 at 10:24 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 05/17/2018 06:38 AM, Chee, Tien Fong wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The A10 clock manager parsed DT bindings generated by
> > > > > > > > > Quartus
> > > > > > > > > the
> > > > > > > > > bsp-editor to configure the A10 clocks. Sadly, those
> > > > > > > > > DT
> > > > > > > > > bindings
> > > > > > > > > changed at some point. The clock manager patch used
> > > > > > > > > the
> > > > > > > > > old
> > > > > > > > > ones,
> > > > > > > > > this patch replaces the bindings parser with one for
> > > > > > > > > the
> > > > > > > > > new
> > > > > > > > > set.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > > > > > > > Cc: Chin Liang See <chin.liang@intel.com>
> > > > > > > > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > > > > > > > ---
> > > > > > > > >  arch/arm/mach-socfpga/clock_manager_arria10.c  | 
> > > > > > > > > 158
> > > > > > > > > ++---
> > > > > > > > >  .../include/mach/clock_manager_arria10.h   |
> > > > > > > > >    2
> > > > > > > > > +-
> > > > > > > > >  2 files changed, 111 insertions(+), 49 deletions(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/arm/mach-
> > > > > > > > > socfpga/clock_manager_arria10.c
> > > > > > > > > b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > > > index 4ee6a82b5f..defa2f6261 100644
> > > > > > > > > --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > > > +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > > > @@ -9,6 +9,9 @@
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > >  
> > > > > > > > > +static const struct socfpga_clock_manager
> > > > > > > > > *clock_manager_base =
> > > > > > > > > + (struct socfpga_clock_manager
> > > > > > > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > > > > > > > +
> > > > > > > > >  static u32 eosc1_hz;
> > > > > > > > >  static u32 cb_intosc_hz;
> > > > > > > > >  static u32 f2s_free_hz;
> > > > > > > > > @@ -64,89 +67,150 @@ struct perpll_cfg {
> > > > > > > > >   u32 cntr8clk_cnt;
> > > > > > > > >   u32 cntr8clk_src;
> > > > > > > > >   u32 cntr9clk_cnt;
> > > > > > > > > + u32 cntr9clk_src;
> > > > > > > > Why add this? I believe this is not exist.
> > > > > > > It exists in the altera sources and it matches the
> > > > > > > pattern.
> > > > > > > What
> > > > > > > do
> > > > > > > you
> > > > > > > mean by "this is not exist" ?
> > > > > > > 
> > > > > > we don't have cntr9clk_src in perpll.
> > > > > https://github.com/altera-opensource/u-boot-socfpga/blob/socf
> > > > > pga_
> > > > > v201
> > > > > 4.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/clock
> > > > > _man
> > > > > ager
> > > > > .c#L229
> > > > > 
> > > > That is the bug, and i have already fixed it in mainstream
> > > > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-socfpga
> > > > /clo
> > > > ck_m
> > > > anager_arria10.c;h=4ee6a82b5f75215d6930d488aa39c572d1610073;hb=
> > > > HEAD
> > > > #l11
> > > > 4
> > > So the hardware really isn't symmetric in that way ? (why is this
> > > not
> > > fixed in the old altera for of u-boot then?)
> > > 
> > I have no idea why the HW was designed in that way. But the latest
> > hps.xml handoff file which is generated from qsys and quartus tools
> > based on our golden system reference design, the
> > i_clk_mgr_perpllgrp.cntr9clk.cnt is listed inside the file.
> > 
> > Our priority is getting the things fixed in mainstream, unless the
> > bugs
> > in old altera impacts the functionality and board booting up. In
> > the
> > end, we will get everything upstream and encouraging user to use
> > mainstream.
> > > 
> > > The a10_5v4 doesn't even list clock 9 at all. Why ?
> > > 
> > This infomation is missing inside the document. Our internal
> > register
> > mapping document has this listed.
> Er, since you say it is listed internally, then the cntr9clk_src
> exists?
> I am confused here, really.
> 
cntr9clk_src is not exists, but cntr9clk_cnt is exists.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Chee, Tien Fong]

On Fri, 2018-05-18 at 09:50 +0200, Marek Vasut wrote:
> On 05/18/2018 06:41 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-05-17 at 11:38 +0200, Marek Vasut wrote:
> > > 
> > > On 05/17/2018 10:44 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Thu, 2018-05-17 at 10:24 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 05/17/2018 06:38 AM, Chee, Tien Fong wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The A10 clock manager parsed DT bindings generated by
> > > > > > > Quartus
> > > > > > > the
> > > > > > > bsp-editor to configure the A10 clocks. Sadly, those DT
> > > > > > > bindings
> > > > > > > changed at some point. The clock manager patch used the
> > > > > > > old
> > > > > > > ones,
> > > > > > > this patch replaces the bindings parser with one for the
> > > > > > > new
> > > > > > > set.
> > > > > > > 
> > > > > > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > > > > > Cc: Chin Liang See <chin.liang@intel.com>
> > > > > > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > > > > > ---
> > > > > > >  arch/arm/mach-socfpga/clock_manager_arria10.c  | 158
> > > > > > > ++---
> > > > > > >  .../include/mach/clock_manager_arria10.h   |   2
> > > > > > > +-
> > > > > > >  2 files changed, 111 insertions(+), 49 deletions(-)
> > > > > > > 
> > > > > > > diff --git a/arch/arm/mach-
> > > > > > > socfpga/clock_manager_arria10.c
> > > > > > > b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > index 4ee6a82b5f..defa2f6261 100644
> > > > > > > --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > > > @@ -9,6 +9,9 @@
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > >  
> > > > > > > +static const struct socfpga_clock_manager
> > > > > > > *clock_manager_base =
> > > > > > > + (struct socfpga_clock_manager
> > > > > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > > > > > +
> > > > > > >  static u32 eosc1_hz;
> > > > > > >  static u32 cb_intosc_hz;
> > > > > > >  static u32 f2s_free_hz;
> > > > > > > @@ -64,89 +67,150 @@ struct perpll_cfg {
> > > > > > >   u32 cntr8clk_cnt;
> > > > > > >   u32 cntr8clk_src;
> > > > > > >   u32 cntr9clk_cnt;
> > > > > > > + u32 cntr9clk_src;
> > > > > > Why add this? I believe this is not exist.
> > > > > It exists in the altera sources and it matches the pattern.
> > > > > What
> > > > > do
> > > > > you
> > > > > mean by "this is not exist" ?
> > > > > 
> > > > we don't have cntr9clk_src in perpll.
> > > https://github.com/altera-opensource/u-boot-socfpga/blob/socfpga_
> > > v201
> > > 4.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/clock_man
> > > ager
> > > .c#L229
> > > 
> > That is the bug, and i have already fixed it in mainstream
> > http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-socfpga/clo
> > ck_m
> > anager_arria10.c;h=4ee6a82b5f75215d6930d488aa39c572d1610073;hb=HEAD
> > #l11
> > 4
> So the hardware really isn't symmetric in that way ? (why is this not
> fixed in the old altera for of u-boot then?)
> 
I have no idea why the HW was designed in that way. But the latest
hps.xml handoff file which is generated from qsys and quartus tools
based on our golden system reference design, the
i_clk_mgr_perpllgrp.cntr9clk.cnt is listed inside the file.

Our priority is getting the things fixed in mainstream, unless the bugs
in old altera impacts the functionality and board booting up. In the
end, we will get everything upstream and encouraging user to use
mainstream.
> The a10_5v4 doesn't even list clock 9 at all. Why ?
> 
This infomation is missing inside the document. Our internal register
mapping document has this listed.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] doc: Add new doc for file system firmware loader driver model

[Chee, Tien Fong]

On Thu, 2018-05-17 at 07:11 -0400, Tom Rini wrote:
> On Thu, May 17, 2018 at 04:27:27AM +0000, Chee, Tien Fong wrote:
> > 
> > On Wed, 2018-05-16 at 08:48 -0400, Tom Rini wrote:
> > > 
> > > On Wed, May 16, 2018 at 05:21:39PM +0800, tien.fong.c...@intel.co
> > > m
> > > wrote:
> > > 
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > 
> > > > Provide information about
> > > > 
> > > > - overview of file system firmware loader driver model
> > > > - describe default storage device in device tree source
> > > > - describe fie system firmware loader API
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > ---
> > > >  doc/driver-model/fs_firmware_loader.txt |  100
> > > > +++
> > > >  1 files changed, 100 insertions(+), 0 deletions(-)
> > > >  create mode 100644 doc/driver-model/fs_firmware_loader.txt
> > > > 
> > > > diff --git a/doc/driver-model/fs_firmware_loader.txt
> > > > b/doc/driver-
> > > > model/fs_firmware_loader.txt
> > > > new file mode 100644
> > > > index 000..167660a
> > > > --- /dev/null
> > > > +++ b/doc/driver-model/fs_firmware_loader.txt
> > > > @@ -0,0 +1,100 @@
> > > > +/*
> > > > + * Copyright (C) 2018 Intel Corporation 
> > > > + *
> > > > + * SPDX-License-Identifier:GPL-2.0
> > > > + */
> > > As this isn't code please don't put a code header up for the
> > > first
> > > comment block.  Frankly I'd rather see an rST comment block up
> > > front
> > > even with the rest being plain text as long term I imagine we'll
> > > move
> > > to
> > > rST.
> > > 
> > Okay, i will remove the license and changing it to rST format.
> You don't need to remove it, just move it :)
> 
Ohhi just need to change the license and copyright header to rST
format?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Chee, Tien Fong]

On Thu, 2018-05-17 at 11:38 +0200, Marek Vasut wrote:
> On 05/17/2018 10:44 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-05-17 at 10:24 +0200, Marek Vasut wrote:
> > > 
> > > On 05/17/2018 06:38 AM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > The A10 clock manager parsed DT bindings generated by Quartus
> > > > > the
> > > > > bsp-editor to configure the A10 clocks. Sadly, those DT
> > > > > bindings
> > > > > changed at some point. The clock manager patch used the old
> > > > > ones,
> > > > > this patch replaces the bindings parser with one for the new
> > > > > set.
> > > > > 
> > > > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > > > Cc: Chin Liang See <chin.liang@intel.com>
> > > > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > > > ---
> > > > >  arch/arm/mach-socfpga/clock_manager_arria10.c  | 158
> > > > > ++---
> > > > >  .../include/mach/clock_manager_arria10.h   |   2 +-
> > > > >  2 files changed, 111 insertions(+), 49 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > index 4ee6a82b5f..defa2f6261 100644
> > > > > --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > > > @@ -9,6 +9,9 @@
> > > > >  #include 
> > > > >  #include 
> > > > >  
> > > > > +static const struct socfpga_clock_manager
> > > > > *clock_manager_base =
> > > > > + (struct socfpga_clock_manager
> > > > > *)SOCFPGA_CLKMGR_ADDRESS;
> > > > > +
> > > > >  static u32 eosc1_hz;
> > > > >  static u32 cb_intosc_hz;
> > > > >  static u32 f2s_free_hz;
> > > > > @@ -64,89 +67,150 @@ struct perpll_cfg {
> > > > >   u32 cntr8clk_cnt;
> > > > >   u32 cntr8clk_src;
> > > > >   u32 cntr9clk_cnt;
> > > > > + u32 cntr9clk_src;
> > > > Why add this? I believe this is not exist.
> > > It exists in the altera sources and it matches the pattern. What
> > > do
> > > you
> > > mean by "this is not exist" ?
> > > 
> > we don't have cntr9clk_src in perpll.
> https://github.com/altera-opensource/u-boot-socfpga/blob/socfpga_v201
> 4.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/clock_manager
> .c#L229
> 
That is the bug, and i have already fixed it in mainstream
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-socfpga/clock_m
anager_arria10.c;h=4ee6a82b5f75215d6930d488aa39c572d1610073;hb=HEAD#l11
4

> You do ...
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Chee, Tien Fong]

On Thu, 2018-05-17 at 10:24 +0200, Marek Vasut wrote:
> On 05/17/2018 06:38 AM, Chee, Tien Fong wrote:
> > 
> > On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
> > > 
> > > The A10 clock manager parsed DT bindings generated by Quartus the
> > > bsp-editor to configure the A10 clocks. Sadly, those DT bindings
> > > changed at some point. The clock manager patch used the old ones,
> > > this patch replaces the bindings parser with one for the new set.
> > > 
> > > Signed-off-by: Marek Vasut <ma...@denx.de>
> > > Cc: Chin Liang See <chin.liang@intel.com>
> > > Cc: Dinh Nguyen <dingu...@kernel.org>
> > > ---
> > >  arch/arm/mach-socfpga/clock_manager_arria10.c  | 158
> > > ++---
> > >  .../include/mach/clock_manager_arria10.h   |   2 +-
> > >  2 files changed, 111 insertions(+), 49 deletions(-)
> > > 
> > > diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > index 4ee6a82b5f..defa2f6261 100644
> > > --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
> > > @@ -9,6 +9,9 @@
> > >  #include 
> > >  #include 
> > >  
> > > +static const struct socfpga_clock_manager *clock_manager_base =
> > > + (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
> > > +
> > >  static u32 eosc1_hz;
> > >  static u32 cb_intosc_hz;
> > >  static u32 f2s_free_hz;
> > > @@ -64,89 +67,150 @@ struct perpll_cfg {
> > >   u32 cntr8clk_cnt;
> > >   u32 cntr8clk_src;
> > >   u32 cntr9clk_cnt;
> > > + u32 cntr9clk_src;
> > Why add this? I believe this is not exist.
> It exists in the altera sources and it matches the pattern. What do
> you
> mean by "this is not exist" ?
> 
we don't have cntr9clk_src in perpll.
> > 
> > > 
> > >   u32 emacctl_emac0sel;
> > >   u32 emacctl_emac1sel;
> > >   u32 emacctl_emac2sel;
> > >   u32 gpiodiv_gpiodbclk;
> > >  };
> > >  
> [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Chee, Tien Fong]

On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
> The A10 clock manager parsed DT bindings generated by Quartus the
> bsp-editor to configure the A10 clocks. Sadly, those DT bindings
> changed at some point. The clock manager patch used the old ones,
> this patch replaces the bindings parser with one for the new set.
> 
> Signed-off-by: Marek Vasut 
> Cc: Chin Liang See 
> Cc: Dinh Nguyen 
> ---
>  arch/arm/mach-socfpga/clock_manager_arria10.c  | 158
> ++---
>  .../include/mach/clock_manager_arria10.h   |   2 +-
>  2 files changed, 111 insertions(+), 49 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/clock_manager_arria10.c
> b/arch/arm/mach-socfpga/clock_manager_arria10.c
> index 4ee6a82b5f..defa2f6261 100644
> --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
> +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
> @@ -9,6 +9,9 @@
>  #include 
>  #include 
>  
> +static const struct socfpga_clock_manager *clock_manager_base =
> + (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
> +
>  static u32 eosc1_hz;
>  static u32 cb_intosc_hz;
>  static u32 f2s_free_hz;
> @@ -64,89 +67,150 @@ struct perpll_cfg {
>   u32 cntr8clk_cnt;
>   u32 cntr8clk_src;
>   u32 cntr9clk_cnt;
> + u32 cntr9clk_src;
Why add this? I believe this is not exist.
>   u32 emacctl_emac0sel;
>   u32 emacctl_emac1sel;
>   u32 emacctl_emac2sel;
>   u32 gpiodiv_gpiodbclk;
>  };
>  
> -struct alteragrp_cfg {
> - u32 nocclk;
> - u32 mpuclk;
> +struct strtou32 {
> + const char *str;
> + const u32 val;
>  };
>  
> -static const struct socfpga_clock_manager *clock_manager_base =
> - (struct socfpga_clock_manager *)SOCFPGA_CLKMGR_ADDRESS;
> +static const struct strtou32 mainpll_cfg_tab[] = {
> + { "vco0-psrc", offsetof(struct mainpll_cfg, vco0_psrc) },
> + { "vco1-denom", offsetof(struct mainpll_cfg, vco1_denom) },
> + { "vco1-numer", offsetof(struct mainpll_cfg, vco1_numer) },
> + { "mpuclk-cnt", offsetof(struct mainpll_cfg, mpuclk_cnt) },
> + { "mpuclk-src", offsetof(struct mainpll_cfg, mpuclk_src) },
> + { "nocclk-cnt", offsetof(struct mainpll_cfg, nocclk_cnt) },
> + { "nocclk-src", offsetof(struct mainpll_cfg, nocclk_src) },
> + { "cntr2clk-cnt", offsetof(struct mainpll_cfg, cntr2clk_cnt)
> },
> + { "cntr3clk-cnt", offsetof(struct mainpll_cfg, cntr3clk_cnt)
> },
> + { "cntr4clk-cnt", offsetof(struct mainpll_cfg, cntr4clk_cnt)
> },
> + { "cntr5clk-cnt", offsetof(struct mainpll_cfg, cntr5clk_cnt)
> },
> + { "cntr6clk-cnt", offsetof(struct mainpll_cfg, cntr6clk_cnt)
> },
> + { "cntr7clk-cnt", offsetof(struct mainpll_cfg, cntr7clk_cnt)
> },
> + { "cntr7clk-src", offsetof(struct mainpll_cfg, cntr7clk_src)
> },
> + { "cntr8clk-cnt", offsetof(struct mainpll_cfg, cntr8clk_cnt)
> },
> + { "cntr9clk-cnt", offsetof(struct mainpll_cfg, cntr9clk_cnt)
> },
> + { "cntr9clk-src", offsetof(struct mainpll_cfg, cntr9clk_src)
> },
> + { "cntr15clk-cnt", offsetof(struct mainpll_cfg,
> cntr15clk_cnt) },
> + { "nocdiv-l4mainclk", offsetof(struct mainpll_cfg,
> nocdiv_l4mainclk) },
> + { "nocdiv-l4mpclk", offsetof(struct mainpll_cfg,
> nocdiv_l4mpclk) },
> + { "nocdiv-l4spclk", offsetof(struct mainpll_cfg,
> nocdiv_l4spclk) },
> + { "nocdiv-csatclk", offsetof(struct mainpll_cfg,
> nocdiv_csatclk) },
> + { "nocdiv-cstraceclk", offsetof(struct mainpll_cfg,
> nocdiv_cstraceclk) },
> + { "nocdiv-cspdbgclk", offsetof(struct mainpll_cfg,
> nocdiv_cspdbclk) },
> +};
> +
> +static const struct strtou32 perpll_cfg_tab[] = {
> + { "vco0-psrc", offsetof(struct perpll_cfg, vco0_psrc) },
> + { "vco1-denom", offsetof(struct perpll_cfg, vco1_denom) },
> + { "vco1-numer", offsetof(struct perpll_cfg, vco1_numer) },
> + { "cntr2clk-cnt", offsetof(struct perpll_cfg, cntr2clk_cnt)
> },
> + { "cntr2clk-src", offsetof(struct perpll_cfg, cntr2clk_src)
> },
> + { "cntr3clk-cnt", offsetof(struct perpll_cfg, cntr3clk_cnt)
> },
> + { "cntr3clk-src", offsetof(struct perpll_cfg, cntr3clk_src)
> },
> + { "cntr4clk-cnt", offsetof(struct perpll_cfg, cntr4clk_cnt)
> },
> + { "cntr4clk-src", offsetof(struct perpll_cfg, cntr4clk_src)
> },
> + { "cntr5clk-cnt", offsetof(struct perpll_cfg, cntr5clk_cnt)
> },
> + { "cntr5clk-src", offsetof(struct perpll_cfg, cntr5clk_src)
> },
> + { "cntr6clk-cnt", offsetof(struct perpll_cfg, cntr6clk_cnt)
> },
> + { "cntr6clk-src", offsetof(struct perpll_cfg, cntr6clk_src)
> },
> + { "cntr7clk-cnt", offsetof(struct perpll_cfg, cntr7clk_cnt)
> },
> + { "cntr8clk-cnt", offsetof(struct perpll_cfg, cntr8clk_cnt)
> },
> + { "cntr8clk-src", offsetof(struct perpll_cfg, cntr8clk_src)
> },
> + { "cntr9clk-cnt", offsetof(struct perpll_cfg, cntr9clk_cnt)
> },
> + { "emacctl-emac0sel", offsetof(struct perpll_cfg,
> emacctl_emac0sel) },
> + { 

Re: [U-Boot] [PATCH 1/3] doc: Add new doc for file system firmware loader driver model

[Chee, Tien Fong]

On Wed, 2018-05-16 at 08:48 -0400, Tom Rini wrote:
> On Wed, May 16, 2018 at 05:21:39PM +0800, tien.fong.c...@intel.com
> wrote:
> 
> > 
> > From: Tien Fong Chee 
> > 
> > Provide information about
> > 
> > - overview of file system firmware loader driver model
> > - describe default storage device in device tree source
> > - describe fie system firmware loader API
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  doc/driver-model/fs_firmware_loader.txt |  100
> > +++
> >  1 files changed, 100 insertions(+), 0 deletions(-)
> >  create mode 100644 doc/driver-model/fs_firmware_loader.txt
> > 
> > diff --git a/doc/driver-model/fs_firmware_loader.txt b/doc/driver-
> > model/fs_firmware_loader.txt
> > new file mode 100644
> > index 000..167660a
> > --- /dev/null
> > +++ b/doc/driver-model/fs_firmware_loader.txt
> > @@ -0,0 +1,100 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> As this isn't code please don't put a code header up for the first
> comment block.  Frankly I'd rather see an rST comment block up front
> even with the rest being plain text as long term I imagine we'll move
> to
> rST.
> 
Okay, i will remove the license and changing it to rST format.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-03-08 at 14:04 -0700, Simon Glass wrote:
> Hi,
> 
> On 7 March 2018 at 22:03, Chee, Tien Fong <tien.fong.c...@intel.com>
> wrote:
> > 
> > On Tue, 2018-03-06 at 10:51 -0700, Simon Glass wrote:
> > > 
> > > Hi,
> > > 
> > > On 5 March 2018 at 02:43,  <tien.fong.c...@intel.com> wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > Reviewed-by: Lothar Waßmann <l...@karo-electronics.de>
> > > > ---
> > > >  common/Kconfig |  10 ++
> > > >  common/Makefile|   1 +
> > > >  common/fs_loader.c | 353
> > > > +
> > > >  doc/README.firmware_loader |  86 +++
> > > >  include/fs_loader.h|  28 
> > > >  5 files changed, 478 insertions(+)
> > > >  create mode 100644 common/fs_loader.c
> > > >  create mode 100644 doc/README.firmware_loader
> > > >  create mode 100644 include/fs_loader.h
> > > This looks fine as a concept but I am not keen on the
> > > implementation.
> > > 
> > This patchset has been going through many rounds and a lot of time
> > spending in review, and it is already working and being tested. I
> > still
> > have a lot subsequent patches pending on this patchset. I would
> > suggest
> > to accept this patchset, then we can enhance it to driver model in
> > later.
> > 
> > > 
> > > 1. It should use driver model (only) in U-Boot proper. If there
> > > is
> > > some SPL problem then add a specific function or feature for SPL.
> > We can doing this in later since it is require sometime to figure
> > out
> > and testing.
> > 
> > > 
> > > 2. It should not be necessary ti manually init subsystems -
> > > driver
> > > model does this for you
> > This is for initializing storage driver in very early SPL, where
> > loading from storage to configure some critical HW need to done
> > first.
> > 
> > > 
> > > 3. You can use the uclass name to find things
> > Yeah, once it is converted to driver model, we can use the uclass
> > for
> > searching HW info in DTS.
> > > 
> > > 
> > > Please let me know if you need more info.
> Well I'm still not keen on this. Are you planning to do the
> conversion? It seems like a lot of work for someone else to do.
> 
Okay, i will try to convert it into driver model.

> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Tue, 2018-03-06 at 10:51 -0700, Simon Glass wrote:
> Hi,
> 
> On 5 March 2018 at 02:43,   wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Reviewed-by: Lothar Waßmann 
> > ---
> >  common/Kconfig |  10 ++
> >  common/Makefile|   1 +
> >  common/fs_loader.c | 353
> > +
> >  doc/README.firmware_loader |  86 +++
> >  include/fs_loader.h|  28 
> >  5 files changed, 478 insertions(+)
> >  create mode 100644 common/fs_loader.c
> >  create mode 100644 doc/README.firmware_loader
> >  create mode 100644 include/fs_loader.h
> This looks fine as a concept but I am not keen on the implementation.
> 
This patchset has been going through many rounds and a lot of time
spending in review, and it is already working and being tested. I still
have a lot subsequent patches pending on this patchset. I would suggest
to accept this patchset, then we can enhance it to driver model in
later.

> 1. It should use driver model (only) in U-Boot proper. If there is
> some SPL problem then add a specific function or feature for SPL.
We can doing this in later since it is require sometime to figure out
and testing.

> 2. It should not be necessary ti manually init subsystems - driver
> model does this for you
This is for initializing storage driver in very early SPL, where
loading from storage to configure some critical HW need to done first.

> 3. You can use the uclass name to find things
Yeah, once it is converted to driver model, we can use the uclass for
searching HW info in DTS.
> 
> Please let me know if you need more info.
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v9 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Tue, 2018-02-27 at 11:04 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Tue, 27 Feb 2018 13:21:57 +0800 tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Reviewed-by: Lothar Waßmann 
> > ---
> >  common/Kconfig |  10 ++
> >  common/Makefile|   1 +
> >  common/fs_loader.c | 365
> > +
> >  doc/README.firmware_loader |  83 +++
> >  include/fs_loader.h|  28 
> >  5 files changed, 487 insertions(+)
> >  create mode 100644 common/fs_loader.c
> >  create mode 100644 doc/README.firmware_loader
> >  create mode 100644 include/fs_loader.h
> > 
> > diff --git a/common/Kconfig b/common/Kconfig
> > index d5bc37e..ff88c6e 100644
> > --- a/common/Kconfig
> > +++ b/common/Kconfig
> > @@ -560,6 +560,16 @@ config DISPLAY_BOARDINFO
> >       when U-Boot starts up. The board function checkboard()
> > is called
> >       to do this.
> >  
> > +config GENERIC_FIRMWARE_LOADER
> > +   bool "Enable generic firmware loader driver for file
> > system"
> > +   depends on SPL
> > +   help
> > +     This is file system generic loader which can be used to
> > load
> > +     the file image from the storage into target such as
> > memory.
> > +
> > +     The consumer driver would then use this loader to
> > program whatever,
> > +     ie. the FPGA device.
> > +
> >  menu "Start-up hooks"
> >  
> >  config ARCH_EARLY_INIT_R
> > diff --git a/common/Makefile b/common/Makefile
> > index c7bde23..92d8fb3 100644
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -134,3 +134,4 @@ obj-$(CONFIG_$(SPL_)LOG) += log.o
> >  obj-$(CONFIG_$(SPL_)LOG_CONSOLE) += log_console.o
> >  obj-y += s_record.o
> >  obj-y += xyzModem.o
> > +obj-$(CONFIG_GENERIC_FIRMWARE_LOADER) += fs_loader.o
> > diff --git a/common/fs_loader.c b/common/fs_loader.c
> > new file mode 100644
> > index 000..7fc318f
> > --- /dev/null
> > +++ b/common/fs_loader.c
> > @@ -0,0 +1,365 @@
> > +/*
> > + * Copyright (C) 2018 Intel Corporation 
> > + *
> > + * SPDX-License-Identifier:GPL-2.0
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#ifdef CONFIG_CMD_UBIFS
> > +#include 
> > +#include 
> > +#endif
> > +#include 
> > +
> > +struct firmware_priv {
> > +   const char *name;   /* Filename */
> > +   u32 offset; /* Offset of reading a file */
> > +};
> > +
> > +static struct device_location default_locations[] = {
> > +   {
> > +   .name = "mmc",
> > +   .devpart = "0:1",
> > +   },
> > +   {
> > +   .name = "usb",
> > +   .devpart = "0:1",
> > +   },
> > +   {
> > +   .name = "sata",
> > +   .devpart = "0:1",
> > +   },
> > +   {
> > +   .name = "ubi",
> > +   .mtdpart = "UBI",
> > +   .ubivol = "ubi0",
> > +   },
> > +};
> > +
> > +/* USB build is not supported yet in SPL */
> > +#ifndef CONFIG_SPL_BUILD
> > +#ifdef CONFIG_USB_STORAGE
> > +static int init_usb(void)
> > +{
> > +   int err;
> > +
> > +   err = usb_init();
> > +   if (err)
> > +   return err;
> > +
> > +#ifndef CONFIG_DM_USB
> > +   err = usb_stor_scan(0);
> > +   if (err)
> > +   return err;
> > +#endif
> > +
> > +   return err;
> > +}
> > +#else
> > +static int init_usb(void)
> > +{
> > +   debug("Error: Cannot load flash image: no USB support\n");
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +#endif
> > +
> > +#ifdef CONFIG_SATA
> > +static int init_storage_sata(struct device_location *location)
> > +{
> > +   char *dup_str = NULL;
> > +   const char *dev_str, *part_str;
> > +   int dev;
> > +
> > +   /* Get device ID */
> > +   part_str = strchr(location->devpart, ':');
> > +   if (part_str) {
> > +   dup_str = strdup(location->devpart);
> > +   dup_str[part_str - location->devpart] = 0;
> > +   dev_str = dup_str;
> > +   part_str++;
> > +   } else {
> > +   dev_str = location->devpart;
> > +   }
> > +
> > +   dev = (int)simple_strtoul(dev_str, NULL, 10);
> > +
> > +   return sata_probe(dev);
> > 
> You are leaking the strdup() memory.
Good catch!!

> Furthermore, there is no need to mess around with the 'devpart'
> string
> like this. simple_strtoul() will convert the string up to the first
> non-digit character and return the position of this char in the
> second
> argument (if that's non-null). Thus you can easily check for a valid
> numerical argument.
> 
Okay, i would try with simple_strtoul().

> > 
> > +static void set_storage_devpart(char *name, char *devpart)
> > +{
> > +   size_t 

Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-02-22 at 10:02 +0100, Lothar Waßmann wrote:
> Hi,
> 
> On Mon,  5 Feb 2018 15:06:49 +0800 tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Reviewed-by: Lothar Waßmann 
> > ---
> >  common/Kconfig |   9 ++
> >  common/Makefile|   1 +
> >  common/fs_loader.c | 320
> > +
> >  doc/README.firmware_loader |  76 +++
> >  include/fs_loader.h|  28 
> >  5 files changed, 434 insertions(+)
> >  create mode 100644 common/fs_loader.c
> >  create mode 100644 doc/README.firmware_loader
> >  create mode 100644 include/fs_loader.h
> > 
> [...]
> > 
> > +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
> > +__weak int init_mmc(void)
> > +{
> > +   /* Just for the case MMC is not yet initialized */
> > +   struct mmc *mmc = NULL;
> > +   int err;
> > +
> > +#ifdef CONFIG_SPL
> > +   spl_mmc_find_device(, spl_boot_device());
> > +#else
> > +   debug("#define CONFIG_SPL is required or overrriding
> > %s\n",
> > 
> s/overrr/overr/
> 
I would remove it and adding the depend on CONFIG_SPL in Kconfig for
compile-time error checking.
> 
> 
> Lothar Waßmann
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-02-22 at 10:50 -0500, Tom Rini wrote:
> On Thu, Feb 22, 2018 at 03:28:12PM +0100, Marek Vasut wrote:
> > 
> > On 02/22/2018 09:18 AM, Chee, Tien Fong wrote:
> > > 
> > > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote:
> > > > 
> > > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > > > > 
> > > > > 
> > > > > From: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > > 
> > > > > This is file system generic loader which can be used to load
> > > > > the file image from the storage into target such as memory.
> > > > > The consumer driver would then use this loader to program
> > > > > whatever,
> > > > > ie. the FPGA device.
> > > > > 
> > > > > Signed-off-by: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > > Reviewed-by: Lothar Waßmann <l...@karo-electronics.de>
> > > > [...]
> > > > 
> > > > > 
> > > > > 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#include 
> > > > > +#ifdef CONFIG_SPL
> > > > Are the ifdefs needed ?
> > > > 
> > > Because spl.h contains some codes have its dependency with SPL.
> > > So, Tom
> > > adviced to make this part of code depend on CONFIG_SPL.
> > > However, only __weak int init_mmc() depend on the codes from
> > > spl.h, so
> > > user can override their own init_mmc() if SPL is not used.
> > You probably dont need those ifdefs around headers.
> In this case, we do.  You can only include  on architectures
> which have SPL support.
> 
> I wouldn't object to a separate patch series that adds a dummy
> asm-generic/spl.h and we go that route, if it also cleans up more of
> the
> code in general.  But I think that's separate from this
> series.  Thanks!
> 
Planning to add the depend on CONFIG_SPL in Kconfig instead of ifdefs .
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-02-22 at 15:28 +0100, Marek Vasut wrote:
> On 02/22/2018 09:18 AM, Chee, Tien Fong wrote:
> > 
> > On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote:
> > > 
> > > On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > > > 
> > > > 
> > > > From: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > 
> > > > This is file system generic loader which can be used to load
> > > > the file image from the storage into target such as memory.
> > > > The consumer driver would then use this loader to program
> > > > whatever,
> > > > ie. the FPGA device.
> > > > 
> > > > Signed-off-by: Tien Fong Chee <tien.fong.c...@intel.com>
> > > > Reviewed-by: Lothar Waßmann <l...@karo-electronics.de>
> > > [...]
> > > 
> > > > 
> > > > 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#ifdef CONFIG_SPL
> > > Are the ifdefs needed ?
> > > 
> > Because spl.h contains some codes have its dependency with SPL. So,
> > Tom
> > adviced to make this part of code depend on CONFIG_SPL.
> > However, only __weak int init_mmc() depend on the codes from spl.h,
> > so
> > user can override their own init_mmc() if SPL is not used.
> You probably dont need those ifdefs around headers.
> 
> > 
> > > 
> > > > 
> > > > +#include 
> > > > +#endif
> > > > +#include 
> > > > +#ifdef CONFIG_CMD_UBIFS
> > > > +#include 
> > > > +#include 
> > > > +#endif
> > > > +#include 
> > > > +
> > > > +struct firmware_priv {
> > > > +   const char *name;   /* Filename */
> > > > +   u32 offset; /* Offset of reading a file
> > > > */
> > > > +};
> > > > +
> > > > +static struct device_location default_locations[] = {
> > > > +   {
> > > > +   .name = "mmc",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > > +   {
> > > > +   .name = "usb",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > > +   {
> > > > +   .name = "sata",
> > > > +   .devpart = "0:1",
> > > > +   },
> > > How can this load from UBI if it's not listed here ?
> Well ?
> 
I can add ".name = ubi" and ".devpart = UBI" .
> [...]
> 
> > 
> > > 
> > > > 
> > > > +#ifdef CONFIG_SATA
> > > > +static int init_storage_sata(void)
> > > > +{
> > > > +   return sata_probe(0);
> > > Shouldn't the sata device number be pulled from devpart in
> > > default_locations table ?
> > > 
> > This may need to add the logic for splitting the device number and
> > partition into integer from the string. Let me think how to do it,
> > may
> > be i can leverage existing code.
> strtok(), strtol() or something ?
> 
yes, plan to use that.
> [...]
> 
> > 
> > > 
> > > > 
> > > > +#ifdef CONFIG_SPL
> > > > +   spl_mmc_find_device(, spl_boot_device());
> > > > +#else
> > > > +   debug("#define CONFIG_SPL is required or overrriding
> > > > %s\n",
> > > > +     __func__);
> > > This can be a compile-time error, maybe ?
> > > 
> > No compile error. When you open the file, "%s\n" is actually same
> > line
> > with debug(". .
> So what ? This missing macro can be detected at runtime, heck this
> code
> can even depend on CONFIG_SPL in Kconfig.
> 
Oh...I got you, i thought you means syntax error. So, i would remove it
and adding the depend on CONFIG_SPL in Kconfig.
> > 
> > > 
> > > > 
> > > > 
> > > > +   return -ENOENT;
> > > > +#endif
> > > > +
> > > > +   err = mmc_init(mmc);
> > > > +   if (err) {
> > > > +   debug("spl: mmc init failed with error: %d\n",
> > > > err);
> > > > +   return err;
> > > > +   }
> > > > +
> > > > +   return err;
> > > > +}
> > > > +#else
> > > > +__weak int init_mmc(void)
> > > > +{
> > > > +   /* Expect somewhere already initialize MMC */
> > > > +   return 0;
> > > > +}
> > > > +#endif
> > > [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v8 4/4] common: Generic firmware loader for file system

[Chee, Tien Fong]

On Thu, 2018-02-15 at 15:58 +0100, Marek Vasut wrote:
> On 02/05/2018 08:06 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This is file system generic loader which can be used to load
> > the file image from the storage into target such as memory.
> > The consumer driver would then use this loader to program whatever,
> > ie. the FPGA device.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Reviewed-by: Lothar Waßmann 
> [...]
> 
> > 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#ifdef CONFIG_SPL
> Are the ifdefs needed ?
> 
Because spl.h contains some codes have its dependency with SPL. So, Tom
adviced to make this part of code depend on CONFIG_SPL.
However, only __weak int init_mmc() depend on the codes from spl.h, so
user can override their own init_mmc() if SPL is not used.

> > 
> > +#include 
> > +#endif
> > +#include 
> > +#ifdef CONFIG_CMD_UBIFS
> > +#include 
> > +#include 
> > +#endif
> > +#include 
> > +
> > +struct firmware_priv {
> > +   const char *name;   /* Filename */
> > +   u32 offset; /* Offset of reading a file */
> > +};
> > +
> > +static struct device_location default_locations[] = {
> > +   {
> > +   .name = "mmc",
> > +   .devpart = "0:1",
> > +   },
> > +   {
> > +   .name = "usb",
> > +   .devpart = "0:1",
> > +   },
> > +   {
> > +   .name = "sata",
> > +   .devpart = "0:1",
> > +   },
> How can this load from UBI if it's not listed here ?
> 
> > 
> > +};
> > +
> > +/* USB build is not supported yet in SPL */
> > +#ifndef CONFIG_SPL_BUILD
> > +#ifdef CONFIG_USB_STORAGE
> > +static int init_usb(void)
> > +{
> > +   int err;
> > +
> > +   err = usb_init();
> > +   if (err)
> > +   return err;
> > +
> > +#ifndef CONFIG_DM_USB
> > +   err = usb_stor_scan(1);
> mode = 0 I think, we don't need this verbose output.
> 
Okay so i will change to usb_stor_scan(0) .
> > 
> > +   if (err)
> > +   return err;
> > +#endif
> > +
> > +   return err;
> > +}
> > +#else
> > +static int init_usb(void)
> > +{
> > +   debug("Error: Cannot load flash image: no USB support\n");
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +#endif
> > +
> > +#ifdef CONFIG_SATA
> > +static int init_storage_sata(void)
> > +{
> > +   return sata_probe(0);
> Shouldn't the sata device number be pulled from devpart in
> default_locations table ?
> 
This may need to add the logic for splitting the device number and
partition into integer from the string. Let me think how to do it, may
be i can leverage existing code.
> > 
> > +}
> > +#else
> > +static int init_storage_sata(void)
> > +{
> > +   debug("Error: Cannot load image: no SATA support\n");
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +
> > +#ifdef CONFIG_CMD_UBIFS
> > +static int mount_ubifs(struct device_location *location)
> > +{
> > +   int ret;
> > +   char cmd[32];
> > +
> > +   if (ret = ubi_part(location->mtdpart, NULL)) {
> > +   debug("Cannot find mtd partition %s\n", location-
> > >mtdpart);
> > +   return ret;
> > +   }
> > +
> > +   return cmd_ubifs_mount(location->ubivol);
> > +}
> > +
> > +static int umount_ubifs(void)
> > +{
> > +   return cmd_ubifs_umount();
> > +}
> > +#else
> > +static int mount_ubifs(struct device_location *location)
> > +{
> > +   debug("Error: Cannot load image: no UBIFS support\n");
> > +   return -ENOSYS;
> > +}
> > +#endif
> > +
> > +#if defined(CONFIG_SPL_MMC_SUPPORT) && defined(CONFIG_SPL_BUILD)
> > +__weak int init_mmc(void)
> > +{
> > +   /* Just for the case MMC is not yet initialized */
> > +   struct mmc *mmc = NULL;
> > +   int err;
> > +
> > +#ifdef CONFIG_SPL
> > +   spl_mmc_find_device(, spl_boot_device());
> > +#else
> > +   debug("#define CONFIG_SPL is required or overrriding
> > %s\n",
> > +     __func__);
> This can be a compile-time error, maybe ?
> 
No compile error. When you open the file, "%s\n" is actually same line
with debug(". .

> > 
> > +   return -ENOENT;
> > +#endif
> > +
> > +   err = mmc_init(mmc);
> > +   if (err) {
> > +   debug("spl: mmc init failed with error: %d\n",
> > err);
> > +   return err;
> > +   }
> > +
> > +   return err;
> > +}
> > +#else
> > +__weak int init_mmc(void)
> > +{
> > +   /* Expect somewhere already initialize MMC */
> > +   return 0;
> > +}
> > +#endif
> [...]
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot