Re: [U-Boot] [PATCH 1/7] arm: socfpga: update de0 nano default environment

[Westergreen, Dalon]

On Sat, 2017-01-21 at 20:28 +0100, Marek Vasut wrote:

On 01/21/2017 06:31 PM, Dalon Westergreen wrote:


From: Dalon Westergreen 
mailto:dalon.westergr...@intel.com>>

The default values for CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
and CONFIG_SYS_MMCSD_FS_OS_PARTITION have changed and as
as result the default uboot environment for this board
needs updating.  This sets the default envirnment to
use the CONFIG_SYS_MMCSD_FS_BOOT_PARTITION and
CONFIG_SYS_MMCSD_FS_OS_PARTITION configs for the boot
and os partitions.

Also set the default fdtimage value to match the
devicetree name in the linux kernel for this board.

Signed-off-by: Dalon Westergreen 
mailto:dalon.westergr...@intel.com>>



While I'm fine with the patch, wouldn't it make more sense to move
toward distro bootcmd (git grep for DISTRO_BOOTCMD, ie RPi is using
it). Major distros agreed on how to handle the U-Boot env, so it'd
be nice to have Altera SoCs follow.

What do you think ?



I like the idea,  I think moving in that direction makes sense. For now i 
suggest just cleaning
up the current environment so it boots with the current default sdcard image. 
Agreed?




de0 fix spaces



This is probably not supposed to be part of the description ? :)



---
 include/configs/socfpga_de0_nano_soc.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/configs/socfpga_de0_nano_soc.h 
b/include/configs/socfpga_de0_nano_soc.h
index 6b9546e..205b859 100644
--- a/include/configs/socfpga_de0_nano_soc.h
+++ b/include/configs/socfpga_de0_nano_soc.h
@@ -39,15 +39,17 @@
"bootm ${loadaddr} - ${fdt_addr}\0" \
"bootimage=zImage\0" \
"fdt_addr=100\0" \
-   "fdtimage=socfpga.dtb\0" \
+   "fdtimage=socfpga_cyclone5_de0_sockit.dtb\0" \
"bootm ${loadaddr} - ${fdt_addr}\0" \
-   "mmcroot=/dev/mmcblk0p2\0" \
+   "mmc_boot=" __stringify(CONFIG_SYS_MMCSD_FS_BOOT_PARTITION) "\0" \
+   "mmc_os=" __stringify(CONFIG_SYS_MMCSD_FS_OS_PARTITION) "\0" \
+   "mmcroot=/dev/mmcblk0p${mmc_os}\0" \
"mmcboot=setenv bootargs " CONFIG_BOOTARGS \
" root=${mmcroot} rw rootwait;" \
"bootz ${loadaddr} - ${fdt_addr}\0" \
"mmcload=mmc rescan;" \
-   "load mmc 0:1 ${loadaddr} ${bootimage};" \
-   "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \
+   "load mmc 0:${mmc_boot} ${loadaddr} ${bootimage};" \
+   "load mmc 0:${mmc_boot} ${fdt_addr} ${fdtimage}\0" \

 /* The rest of the configuration is shared */
 #include 






___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] arm: socfpga: update arria5 socdk default environment

[Westergreen, Dalon]

On Sat, 2017-01-21 at 20:29 +0100, Marek Vasut wrote:
> On 01/21/2017 06:31 PM, Dalon Westergreen wrote:
> > 
> > From: Dalon Westergreen 
> > 
> > The default values for CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
> > and CONFIG_SYS_MMCSD_FS_OS_PARTITION have changed and as
> > as result the default uboot environment for this board
> > needs updating.  This sets the default envirnment to
> > use the CONFIG_SYS_MMCSD_FS_BOOT_PARTITION and
> > CONFIG_SYS_MMCSD_FS_OS_PARTITION configs for the boot
> > and os partitions.
> > 
> > Also set the default fdtimage value to match the
> > devicetree name in the linux kernel for this board.
> > 
> > Signed-off-by: Dalon Westergreen 
> 
> Acked-by: Marek Vasut 
> 
> but please see my comment on 1/7
> 
> btw I think this is repeating too much, why don't we pull the env into
> socfpga_common.h first ?

I'd prefer to keep the boards separate and look at
moving to disto boot.
> 
> > 
> > ---
> >  include/configs/socfpga_arria5_socdk.h | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/include/configs/socfpga_arria5_socdk.h
> > b/include/configs/socfpga_arria5_socdk.h
> > index 3b0b416..0a7fcd2 100644
> > --- a/include/configs/socfpga_arria5_socdk.h
> > +++ b/include/configs/socfpga_arria5_socdk.h
> > @@ -44,15 +44,17 @@
> >     "bootm ${loadaddr} - ${fdt_addr}\0" \
> >     "bootimage=zImage\0" \
> >     "fdt_addr=100\0" \
> > -   "fdtimage=socfpga.dtb\0" \
> > +   "fdtimage=socfpga_arria5_socdk.dtb\0" \
> >     "bootm ${loadaddr} - ${fdt_addr}\0" \
> > -   "mmcroot=/dev/mmcblk0p2\0" \
> > +   "mmc_boot=" __stringify(CONFIG_SYS_MMCSD_FS_BOOT_PARTITION) "\0" \
> > +   "mmc_os=" __stringify(CONFIG_SYS_MMCSD_FS_OS_PARTITION) "\0" \
> > +   "mmcroot=/dev/mmcblk0p${mmc_os}\0" \
> >     "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
> >     " root=${mmcroot} rw rootwait;" \
> >     "bootz ${loadaddr} - ${fdt_addr}\0" \
> >     "mmcload=mmc rescan;" \
> > -   "load mmc 0:1 ${loadaddr} ${bootimage};" \
> > -   "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \
> > +   "load mmc 0:${mmc_boot} ${loadaddr} ${bootimage};" \
> > +   "load mmc 0:${mmc_boot} ${fdt_addr} ${fdtimage}\0" \
> >     "qspiload=sf probe && mtdparts default && run ubiload\0" \
> >     "qspiboot=setenv bootargs " CONFIG_BOOTARGS \
> >     " ubi.mtd=1,64 root=ubi0:rootfs rw rootfstype=ubifs;"\
> > 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/7] arm: socfpga: update arria5 socdk default environment

[Westergreen, Dalon]

On Sun, 2017-01-22 at 01:36 +0100, Marek Vasut wrote:
> On 01/22/2017 12:04 AM, Westergreen, Dalon wrote:
> > 
> > On Sat, 2017-01-21 at 20:29 +0100, Marek Vasut wrote:
> > > 
> > > On 01/21/2017 06:31 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > From: Dalon Westergreen 
> > > > 
> > > > The default values for CONFIG_SYS_MMCSD_FS_BOOT_PARTITION
> > > > and CONFIG_SYS_MMCSD_FS_OS_PARTITION have changed and as
> > > > as result the default uboot environment for this board
> > > > needs updating.  This sets the default envirnment to
> > > > use the CONFIG_SYS_MMCSD_FS_BOOT_PARTITION and
> > > > CONFIG_SYS_MMCSD_FS_OS_PARTITION configs for the boot
> > > > and os partitions.
> > > > 
> > > > Also set the default fdtimage value to match the
> > > > devicetree name in the linux kernel for this board.
> > > > 
> > > > Signed-off-by: Dalon Westergreen 
> > > 
> > > Acked-by: Marek Vasut 
> > > 
> > > but please see my comment on 1/7
> > > 
> > > btw I think this is repeating too much, why don't we pull the env into
> > > socfpga_common.h first ?
> > 
> > I'd prefer to keep the boards separate and look at
> > moving to disto boot.
> 
> If you create common env in socfpga_common.h first and then update it,
> the update will be in a single patch changing a single file. So will
> then be the switch to distro bootcmd. I would prefer such course of
> action over many patches doing the same thing in many files.
> 
> Given how similar (and broken) the envs are for those boards, pulling
> the common env should be easy and very beneficial.
> 
Okay, agreed.  I will move all of the common env variables to 
socfpga_common.h.  I will change the new board patch to do the same.


-- 
Thanks,
Dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/7] arm: socfpga: update de0 nano default environment

[Westergreen, Dalon]

On Tue, 2017-01-24 at 21:08 -0600, Dinh Nguyen wrote:
> 
> On 01/24/2017 11:05 AM, Dalon Westergreen wrote:
> > 
> > From: Dalon Westergreen 
> > 
> > Remove the default environment as it is now in a common
> > header.
> > 
> > Add the CONFIG_DEFAULT_DEVICE_TREE to the board's defconfig
> > to set the linux devicetree name.
> > 
> > Signed-off-by: Dalon Westergreen 
> > ---
> >  configs/socfpga_de0_nano_soc_defconfig |  3 +--
> >  include/configs/socfpga_de0_nano_soc.h | 19 +--
> >  2 files changed, 2 insertions(+), 20 deletions(-)
> > 
> > diff --git a/configs/socfpga_de0_nano_soc_defconfig
> > b/configs/socfpga_de0_nano_soc_defconfig
> > index af41e1e..4837809 100644
> > --- a/configs/socfpga_de0_nano_soc_defconfig
> > +++ b/configs/socfpga_de0_nano_soc_defconfig
> > @@ -4,6 +4,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
> >  CONFIG_TARGET_SOCFPGA_TERASIC_DE0_NANO=y
> >  CONFIG_SPL_STACK_R_ADDR=0x0080
> >  CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de0_nano_soc"
> > +CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_sockit.dtb"
> 
> This should be socfpga_cyclone5_de0_nano_soc.dtb
> 
No, just checked the dts in the kernel source.  it is
socfpga_cyclone5_de0_sockit.dts. I can change this to
what you like, but my intent had been to match names
in the kernel source where possible.

thanks.
> Dinh
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/7] arm: socfpga: update de0 nano default environment

[Westergreen, Dalon]

On Tue, 2017-01-24 at 21:16 -0600, Dinh Nguyen wrote:
> 
> On 01/24/2017 09:11 PM, Westergreen, Dalon wrote:
> > 
> > On Tue, 2017-01-24 at 21:08 -0600, Dinh Nguyen wrote:
> > > 
> > > 
> > > On 01/24/2017 11:05 AM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > From: Dalon Westergreen 
> > > > 
> > > > Remove the default environment as it is now in a common
> > > > header.
> > > > 
> > > > Add the CONFIG_DEFAULT_DEVICE_TREE to the board's defconfig
> > > > to set the linux devicetree name.
> > > > 
> > > > Signed-off-by: Dalon Westergreen 
> > > > ---
> > > >  configs/socfpga_de0_nano_soc_defconfig |  3 +--
> > > >  include/configs/socfpga_de0_nano_soc.h | 19 +--
> > > >  2 files changed, 2 insertions(+), 20 deletions(-)
> > > > 
> > > > diff --git a/configs/socfpga_de0_nano_soc_defconfig
> > > > b/configs/socfpga_de0_nano_soc_defconfig
> > > > index af41e1e..4837809 100644
> > > > --- a/configs/socfpga_de0_nano_soc_defconfig
> > > > +++ b/configs/socfpga_de0_nano_soc_defconfig
> > > > @@ -4,6 +4,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
> > > >  CONFIG_TARGET_SOCFPGA_TERASIC_DE0_NANO=y
> > > >  CONFIG_SPL_STACK_R_ADDR=0x0080
> > > >  CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de0_nano_soc"
> > > > +CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_sockit.dtb"
> > > 
> > > This should be socfpga_cyclone5_de0_nano_soc.dtb
> > > 
> > No, just checked the dts in the kernel source.  it is
> > socfpga_cyclone5_de0_sockit.dts. I can change this to
> > what you like, but my intent had been to match names
> > in the kernel source where possible.
> > 
> 
> This is U-Boot: check under U-Boot's arch/arm/dts/
> 
> socfpga_cyclone5_sockit.dtb is for the sockit
> socfpga_cyclone5_de0_nano_soc.dtb is for the DE0 Nano board.
> 
> 
> commit 55c7a765f63ab10b9a3b8cbd38bf1483901a7b36
> Author: Dinh Nguyen 
> Date:   Tue Sep 1 17:41:52 2015 -0500
> 
> arm: socfpga: Add support for the Terasic DE-0 Atlas board
> 
> Add support for the Terasic DE0-Nano/Atlas-SoC Kit, which is
> CycloneV based board. The board can boot from SD/MMC. Ethernet is also
> supported.
> 
> 
Ah, i see.  I was under the impression CONFIG_DEFAULT_FDT_FILE
was only being used for the uboot env and CONFIG_DEFAULT_DEVICE_TREE
was for the dts being used by uboot. I am using 
CONFIG_DEFAULT_FDT_FILE to set the uboot env fdtimage
variable.  Is that not the case?  


> Dinh
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
-- 
--
Dalon Westergreen
Embedded Specialist
Intel Programmable Solutions Group
Phone : 1.858.202.3518
--
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/7] arm: socfpga: add env settings to common header

[Westergreen, Dalon]

On Tue, 2017-01-24 at 21:31 -0600, Dinh Nguyen wrote:
> 
> On 01/24/2017 11:05 AM, Dalon Westergreen wrote:
> > 
> > From: Dalon Westergreen 
> > 
> > Move repeated environment settings for socfpga boards
> > to a common header.
> > 
> > The default values for the boot partition and the
> > OS filesystem partition have changed and as
> > as result the default uboot environment for socfpga
> > boards needs updating.
> > 
> > Move to using  CONFIG_DEFAULT_DEVICE_TREE for setting the
> > default linux devicetree used during linux boot.
> > 
> > Signed-off-by: Dalon Westergreen 
> > ---
> >  include/configs/socfpga_common.h | 27 +++
> >  1 file changed, 27 insertions(+)
> > 
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > index 6285266..bdd6e2f 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -336,5 +336,32 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >   * Stack setup
> >   */
> >  #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
> > +   
> > +/* Extra Environment */
> > +#ifndef CONFIG_EXTRA_ENV_SETTINGS
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> > +   "verify=n\0" \
> > +   "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> > +   "bootimage=" CONFIG_BOOTFILE "\0" \
> > +   "fdt_addr=100\0" \
> > +   "fdtimage=" CONFIG_DEFAULT_FDT_FILE "\0" \
> > +   "ramboot=setenv bootargs " CONFIG_BOOTARGS ";" \
> > +   "bootm ${loadaddr} - ${fdt_addr}\0" \
> > +   "mmcroot=/dev/mmcblk0p3\0" \
> 
> Should this be mmcblk0p2?
that was the point of the patches, p1 is now the
a2 partition, so the fat and root partition 
shifted up by 1.

> 
> Dinh
-- 
--
Dalon Westergreen
Embedded Specialist
Intel Programmable Solutions Group
Phone : 1.858.202.3518
--
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Distroboot support for DE0-nano-SoC board

[Westergreen, Dalon]

On Sat, 2017-01-28 at 21:53 +0100, Marek Vasut wrote:
> On 01/28/2017 09:47 PM, Frank Kunz wrote:
> > 
> > This adds common distribution boot environment variables for
> > DE0-nanos-SoC board. The current boot procedure is extended to run
> > the distribution boot as fallback.
> > The SOC ROM loader scans for the SPL in the special partition 0xa2
> > (partition mode)
> > if this is not found it scans the MMC card sector 0 (raw mode), for up to
> > four valid SPLs. When a partition table (MBR, GPT) is used with raw mode,
> > the first SPL must not be written to the MMC and the ROM loader uses the
> > second SPL.
> > 
> > Frank Kunz (3):
> >   socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC
> >   socfpga: Add distoboot support for DE0-nano-SoC
> >   socfpga: Adapt environment storage for DE0-nano-SoC
> > 
> >  include/configs/socfpga_de0_nano_soc.h | 32
> > +++-
> >  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> CCing Dalon, he sent a series
> [PATCH v7 0/7] arm: socfpga: update default u-boot environment
> 
> Can you two coordinate the efforts ? I think it'd make sense to wait for
> his series to reach v8 and then rebase on top of it. I would also like
> Dalon to do a v8 which just extracts the common env, so we can
> merge that first and then look into the more intrusive bits.
> 
Cool, i can submit a v8 which just moves the env to a common location.
I have reservations about the use use of raw mode while an MBR is
present.  It is definitely not an intended use, although it does
work. If you like i can just merge the two patch sets into v8?

thanks,
dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] SPL: add support to boot from a partition type

[Westergreen, Dalon]

On Sat, 2017-01-28 at 19:06 -0500, Tom Rini wrote:
> On Sat, Jan 28, 2017 at 03:20:09PM -0800, Dalon Westergreen wrote:
> 
> > 
> > From: Dalon Westergreen 
> > 
> > the socfpga bootrom supports mmc booting from either a raw image
> > starting at 0x0, or from a partition of type 0xa2.  This patch
> > adds support for locating the boot image in the first type 0xa2
> > partition found.
> > 
> > Signed-off-by: Dalon Westergreen 
> > ---
> >  common/spl/Kconfig   | 17 +
> >  common/spl/spl_mmc.c | 45 -
> >  disk/part_dos.c  |  1 +
> >  include/part.h   |  1 +
> >  4 files changed, 63 insertions(+), 1 deletion(-)
> 
> Today socfpga sets SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to 1.  Do you
> really have enough cases where the special partition isn't going to be
> likely known when building U-Boot for a given platform?
All of our kits actually ship with the third partition being the 0xa2
partition.  Normally the 1 partition is the fat partition.  I want to
support the case where the 0xa2 partition is arbitrary and used only for
the SPL.  the 1 partition is a fat partition with the full u-boot image.

> 
> The code itself looks fine (I don't see an easy way to get at the
> max_entries field of the partition type struct, but assuming that the
> ROM only support MBR tables today you could use the DOS_ENTRY_NUMBERS
> constant with a comment above it).  But we're making this bit of code
> even more complex and adding more #ifdefs.
> 
> [snip]
> > 
> > @@ -331,12 +367,19 @@ int spl_mmc_load_image(struct spl_image_info
> > *spl_image,
> >     CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION);
> >     if (!err)
> >     return err;
> > +   
> > +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE
> > +   err = mmc_load_image_raw_partition_type(spl_image, mmc,
> > +   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE);
> > +   if (!err)
> > +   return err;
> > +#endif
> 
> ... but couldn't we re-structure things so that both of the "boot from a
> partition" options take the same point from spl_mmc_load_image() instead
> set a partition variable depending on static/dynamic partition # being
> used?  Or would that make things even messier looking?  Thanks!
> 
yes, i like this.  seems cleaner.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] SPL: add support to boot from a partition type

[Westergreen, Dalon]

On Sat, 2017-01-28 at 21:05 -0500, Tom Rini wrote:
> On Sun, Jan 29, 2017 at 01:59:17AM +0000, Westergreen, Dalon wrote:
> > 
> > On Sat, 2017-01-28 at 19:06 -0500, Tom Rini wrote:
> > > 
> > > On Sat, Jan 28, 2017 at 03:20:09PM -0800, Dalon Westergreen wrote:
> > > 
> > > > 
> > > > 
> > > > From: Dalon Westergreen 
> > > > 
> > > > the socfpga bootrom supports mmc booting from either a raw image
> > > > starting at 0x0, or from a partition of type 0xa2.  This patch
> > > > adds support for locating the boot image in the first type 0xa2
> > > > partition found.
> > > > 
> > > > Signed-off-by: Dalon Westergreen 
> > > > ---
> > > >  common/spl/Kconfig   | 17 +
> > > >  common/spl/spl_mmc.c | 45 -
> > > >  disk/part_dos.c  |  1 +
> > > >  include/part.h   |  1 +
> > > >  4 files changed, 63 insertions(+), 1 deletion(-)
> > > 
> > > Today socfpga sets SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION to 1.  Do you
> > > really have enough cases where the special partition isn't going to be
> > > likely known when building U-Boot for a given platform?
> > All of our kits actually ship with the third partition being the 0xa2
> > partition.  Normally the 1 partition is the fat partition.  I want to
> > support the case where the 0xa2 partition is arbitrary and used only for
> > the SPL.  the 1 partition is a fat partition with the full u-boot image.
> 
> Er, this code is where we determine where to load U-Boot from, SPL is
> running.  So if I follow you, the bootrom would load SPL from the
> partition with 0xa2 as the type, usually #3 and then we load U-Boot from
> the FAT partition (which would be SPL_FS_LOAD_PAYLOAD_NAME and such) ?
> 
yes, or if FAT isn't enabled, the spl would load the image in the 0xa2
partition or the CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION offset by
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.  Both are reasonable and 
supported.  my current thought is if partition = -1 and 
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE is set then search
for the a2 partition.  work for you?

--dalon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 5/7] arm: socfpga: Update DE1 environment

[Westergreen, Dalon]

On Mon, 2017-01-30 at 16:07 +0100, Alexander Graf wrote:
> On 01/29/2017 12:05 AM, Dalon Westergreen wrote:
> > 
> > From: Dalon Westergreen 
> > 
> > Remove the default environment as it is now in a common
> > header.
> > 
> > Add the CONFIG_DEFAULT_DEVICE_TREE to the board's defconfig
> > to set the linux devicetree name.
> > 
> > Signed-off-by: Dalon Westergreen 
> > Acked-by: Marek Vasut 
> > Acked-by: Dinh Nguyen 
> > ---
> >   configs/socfpga_de1_soc_defconfig |  1 +
> >   include/configs/socfpga_de1_soc.h | 19 +--
> >   2 files changed, 2 insertions(+), 18 deletions(-)
> > 
> > diff --git a/configs/socfpga_de1_soc_defconfig
> > b/configs/socfpga_de1_soc_defconfig
> > index 032deef..d78e8a1 100644
> > --- a/configs/socfpga_de1_soc_defconfig
> > +++ b/configs/socfpga_de1_soc_defconfig
> > @@ -6,6 +6,7 @@ CONFIG_TARGET_SOCFPGA_TERASIC_DE1_SOC=y
> >   CONFIG_SPL_STACK_R_ADDR=0x0080
> >   CONFIG_SPL_YMODEM_SUPPORT=y
> >   CONFIG_DEFAULT_DEVICE_TREE="socfpga_cyclone5_de1_soc"
> > +CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de1_soc.dtb"
> >   CONFIG_FIT=y
> >   CONFIG_SYS_CONSOLE_IS_IN_ENV=y
> >   CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
> > diff --git a/include/configs/socfpga_de1_soc.h
> > b/include/configs/socfpga_de1_soc.h
> > index deec647..3142bd1 100644
> > --- a/include/configs/socfpga_de1_soc.h
> > +++ b/include/configs/socfpga_de1_soc.h
> > @@ -18,7 +18,7 @@
> >   #define PHYS_SDRAM_1_SIZE 0x4000  /* 1GiB */
> >   
> >   /* Booting Linux */
> > -#define CONFIG_BOOTFILE"fitImage"
> > +#define CONFIG_BOOTFILE"zImage"
> 
> ok, here you're confusing me. I thought the point of having the crude, 
> hacky mmcload/mmcboot in bootcmd was because you want to be legacy 
> compatible. If you're changing the bootfile name, that point is moot.
> 
> So at this point, why not just switch to distro boot and extlinux.conf / 
> efi altogether?
> 
Bootfile was never used in the environment, neither have any of the
kits by default been using fitimages. When the environment was moved
to a common one i setting the bootfile def to match what was actually
used.  moving to distro boot is in the works and i will look at
SCAN_DEV_FOR_EFI for legacy support.

thanks,
dalon
> 
> Alex
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/2] spl: socfpga: stratix10: add hex file output for spl image

[Westergreen, Dalon]

On Fri, 2018-09-07 at 19:36 +0200, Marek Vasut wrote:
> On 09/07/2018 06:40 PM, Dalon L Westergreen wrote:
> On Fri, 2018-09-07 at 18:25 +0200, Marek Vasut wrote:
> On 09/07/2018 06:15 PM, Dalon L Westergreen wrote:
> On Thu, 2018-09-06 at 23:56 +0200, Marek Vasut wrote:
> On 09/06/2018 11:26 PM, Dalon L Westergreen wrote:
> On Thu, 2018-09-06 at 15:41 +0200, Marek Vasut wrote:
> On 09/06/2018 03:39 PM, Dalon L Westergreen wrote:
> On Thu, 2018-09-06 at 12:09 +0200, Marek Vasut wrote:
> On 09/06/2018 05:02 AM, Dalon Westergreen wrote:
> Stratix10 requires a hex image of the spl for boot.  The hex
> image is added to the FPGA configuration image and loaded to
> the processor memory by the configuration engine.
> 
> v2:
>   -> add CONFIG_OF_EMBED to include dtb in elf
>   -> generate hex from elf source
> 
> Signed-off-by: Dalon Westergreen    >    >>    >    
> ---
>  configs/socfpga_stratix10_defconfig | 1 +
>  scripts/Makefile.spl| 6 ++
>  2 files changed, 7 insertions(+)
> 
> diff --git a/configs/socfpga_stratix10_defconfig 
> b/configs/socfpga_stratix10_defconfig
> index dceadff439..17cc732cbe 100644
> --- a/configs/socfpga_stratix10_defconfig
> +++ b/configs/socfpga_stratix10_defconfig
> @@ -56,3 +56,4 @@ CONFIG_DM_USB=y
>  CONFIG_USB_DWC2=y
>  CONFIG_USB_STORAGE=y
>  CONFIG_USE_TINY_PRINTF=y
> +CONFIG_OF_EMBED=y
> 
> Why is this needed ? And where did the objcopy hack go ? What is the
> explanation here ?
> 
> You suggested the use of CONFIG_OF_EMBED as an alternative to using the
> u-boot-spl-dtb.bin for objcopy.
> The intent is to ensure that the spl elf has the dtb included, and then
> a simple objcopy to elf to hex is fine.
> You no longer need the --change-address as the elf indicates the correct
> start address, unlike the binary.
> 
> And that's fine with your usecase ? Fine be me then ...
> 
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 76d08fd92b..b09bd40b2a 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -190,6 +190,7 @@ endif
>  ifdef CONFIG_ARCH_SOCFPGA
>  ALL-$(CONFIG_TARGET_SOCFPGA_GEN5)+= $(obj)/$(SPL_BIN).sfp
>  ALL-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += $(obj)/$(SPL_BIN).sfp
> +ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10)   += $(obj)/$(SPL_BIN).hex
> 
> CONFIG_SPL_TARGET "u-boot-spl.hex" can replace this addition I think ?
> 
> This doesnt actually work as CONFIG_SPL_TARGET doesnt appear to be an
> SPL target, but rather a
> target for creating combined u-boot + spl images at the top level. Adding
> 
> ALL-$(CONFIG_SPL_TARGET) += $(obj)/$(SPL_BIN).hex
> 
> in Makefile.spl and
> CONFIG_SPL_TARGET="u-boot-spl.hex"
> in the socfpga_stratix10_config
> 
> results in a build failure with no target for u-boot-spl.hex
> 
> I mean, just define CONFIG_SPL_TARGET and it should generate the
> matching file automatically. See the README, it explains this macro.
> 
> I still get:
> 
> make: *** No rule to make target 'u-boot-spl.hex', needed by 'all'.  Stop.
> 
> 
> When i look at all of the other defined CONFIG_SPL_TARGET, for example
> 
> I guess you did add the u-boot-spl.hex target already ?
> 
> [dwesterg@dwesterg-mobl  u-boot]$ grep -R 
> u-boot-with-spl.bin *
> 
> ...
> 
> ...
> 
> include/configs/uniphier.h:#define CONFIG_SPL_TARGET  
> "u-boot-with-spl.bin"
> 
> Makefile:OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
> 
> Makefile:u-boot-with-spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCE
> 
> Makefile:u-boot.ubl: u-boot-with-spl.bin FORCE
> 
> [dwesterg@dwesterg-mobl  u-boot]$ 
> 
> 
> or 
> 
> 
> [dwesterg@dwesterg-mobl  u-boot]$ grep -R 
> u-boot-with-nand-spl.imx *
> 
> arch/arm/mach-imx/Makefile:u-boot-with-nand-spl.imx: spl/u-boot-nand-spl.imx 
> u-boot.uim FORCE
> 
> include/configs/m53evk.h:#define CONFIG_SPL_TARGET
> "u-boot-with-nand-spl.imx"
> 
> Makefile:u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE
> 
> 
> you find the corresponding target in the makefile.  There is no target for 
> u-boot-spl.hex,
> 
> furthermore the CONFIG_SPL_TARGET seems to combine spl with uboot to create a 
> combined image.
> 
> 
> ifdef CONFIG_TPL
> 
> SPL_PAYLOAD := tpl/u-boot-with-tpl.bin
> 
> else
> 
> SPL_PAYLOAD := u-boot.bin
> 
> endif
> 
> 
> OBJCOPYFLAGS_u-boot-with-spl.bin = -I binary -O binary \
> 
>--pad-to=$(CONFIG_SPL_PAD_TO)
> 
> u-boot-with-spl.bin: spl/u-boot-spl.bin $(SPL_PAYLOAD) FORCE
> 
> $(call if_changed,pad_c

Re: [U-Boot] [PATCH v2] socfpga: clean up sfp generation

[Westergreen, Dalon]

On Sun, 2018-10-14 at 19:58 +0200, Marek Vasut wrote:
> On 10/13/2018 12:13 AM, Dalon Westergreen wrote:
> From: Dalon Westergreen 
> Move the sfp file generation entirely to the root Makefile.  Thismeans that
> the u-boot-spl.sfp will only be generated when requiredand only for the
> socfpga variants that require it.
> sfp generation is now entirely controlled by CONFIG_BUILD_TARGETbeing set to
> either spl/u-boot-spl.sfp or more likelyu-boot-with-spl.sfp
> Signed-off-by: Dalon Westergreen 
> ---v2:  -> condense changes to 1 patch to avoid breaking git bisect---
> Makefile | 11 --- scripts/Makefile.spl | 12  2
> files changed, 8 insertions(+), 15 deletions(-)
> diff --git a/Makefile b/Makefileindex aadd1ec8c6..16ce14d071 100644---
> a/Makefile+++ b/Makefile@@ -1207,6 +1207,14 @@ u-boot.spr: spl/u-boot-spl.img
> u-boot.img FORCE  $(call if_changed,pad_cat)  ifneq
> ($(CONFIG_ARCH_SOCFPGA),)+ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
> Shouldn't that be ifneq ($(CONFIG),) ?, just like the line above ?

That was just cut and paste from scripts/Makefile.spl, but i will change it.
--dalon
> +MKIMAGEFLAGS_$(SPL_BIN).sfp = -T
> socfpgaimage_v1+else+MKIMAGEFLAGS_$(SPL_BIN).sfp = -T
> socfpgaimage+endif+spl/u-boot-spl.sfp: spl/u-boot-spl.bin FORCE+  $(call
> if_changed,mkimage)
> Otherwise it looks good I think :)
> 


smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED

[Westergreen, Dalon]

On Thu, 2020-02-20 at 17:44 +0100, Marek Vasut wrote:

On 2/20/20 3:12 AM, Ang, Chee Hong wrote:

On 2/19/20 1:25 PM,



chee.hong@intel.com

 wrote:

From: Chee Hong Ang <



chee.hong@intel.com

>


CONFIG_OF_EMBED was primarily enabled to support the agilex spl hex

file requirements.  Since this option now produces a warning during

build, and the spl hex can be created using alternate methods,

CONFIG_OF_EMBED is no longer needed.


Signed-off-by: Chee Hong Ang <



chee.hong@intel.com

>


If I apply just this patch, is the platform still bootable ?

Yes. I tested on the platform.

There is a similar patch from Dalon for Stratix10 and it still yet to be applied

to mainline:



https://lists.denx.de/pipermail/u-boot/2019-September/384906.html



I hope the patch from Dalon get applied to mainline before these patchsets.


In fact, this "CONFIG_OF_EMBED" produce warning during build.

Better get rid of this.


If you just remove OF_EMBED, will the DT still be correctly passed in ?

The warning is there for a reason and just removing OF_EMBED to silence

the warning isn't the right approach. But if this works on Agilex, fine.

Yes, it is fine, the u-boot binary and dtb are just cat'ed together instead.

--dalon

Re: [PATCH v2 06/21] configs: socfpga: Enable FIT image loading with ATF support

[Westergreen, Dalon]

On Thu, 2020-02-20 at 21:00 +0100, Simon Goldschmidt wrote:

Am 20.02.2020 um 17:45 schrieb Marek Vasut:

On 2/20/20 3:15 AM, Ang, Chee Hong wrote:

On 2/19/20 1:25 PM,



chee.hong@intel.com

 wrote:

From: Chee Hong Ang <



chee.hong@intel.com

>


SPL now loads ATF (BL31), U-Boot proper and DTB from FIT image. The

new boot flow with ATF support is as follow:


SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)


Signed-off-by: Chee Hong Ang <



chee.hong@intel.com

>

---

 configs/socfpga_agilex_defconfig| 8 +++-

 configs/socfpga_stratix10_defconfig | 8 +++-

 2 files changed, 14 insertions(+), 2 deletions(-)


diff --git a/configs/socfpga_agilex_defconfig

b/configs/socfpga_agilex_defconfig

index 693a774..0065ff0 100644

--- a/configs/socfpga_agilex_defconfig

+++ b/configs/socfpga_agilex_defconfig

@@ -1,6 +1,6 @@

 CONFIG_ARM=y

 CONFIG_ARCH_SOCFPGA=y

-CONFIG_SYS_TEXT_BASE=0x1000

+CONFIG_SYS_TEXT_BASE=0x20


Why did the text base change ?

This defconfig support ATF.

ATF will occupy from this address range (0x1000)

U-Boot now starts at 0x20.


Then please document it in the commit message.


Or even better, could we have 2 defconfigs, one for ATF, one for

non-ATF? That way, we get build coverage that this still works.

This patch set does already add a separate defconfig for non-ATF in 21/21

--dalon



Regards,

Simon



 CONFIG_SYS_MALLOC_F_LEN=0x2000

 CONFIG_ENV_SIZE=0x1000

 CONFIG_ENV_OFFSET=0x200

@@ -10,10 +10,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y

 CONFIG_IDENT_STRING="socfpga_agilex"

 CONFIG_SPL_FS_FAT=y

 CONFIG_SPL_TEXT_BASE=0xFFE0

+CONFIG_FIT=y

+CONFIG_SPL_LOAD_FIT=y

+CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"

 CONFIG_BOOTDELAY=5

+CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y


Is legacy image support really needed ?

Let me check. Will get rid of this if it's not needed. Thanks.


Thanks

Re: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED

[Westergreen, Dalon]

On Tue, 2020-02-25 at 18:55 +0100, Marek Vasut wrote:

On 2/24/20 3:26 AM, Ang, Chee Hong wrote:

On 2/21/20 7:15 PM, Ang, Chee Hong wrote:

On 2/20/20 6:04 PM, Westergreen, Dalon wrote:


Please fix your mailer, it makes your reply completely unreadable.


On Thu, 2020-02-20 at 17:44 +0100, Marek Vasut wrote:


On 2/20/20 3:12 AM, Ang, Chee Hong wrote:


On 2/19/20 1:25 PM,


mailto:chee.hong@intel.com>

chee.hong@intel.com

>


<mailto:chee.hong@intel.com>

chee.hong@intel.com



 wrote:


From: Chee Hong Ang <


mailto:chee.hong@intel.com>

chee.hong@intel.com

>


<mailto:chee.hong@intel.com>

chee.hong@intel.com






CONFIG_OF_EMBED was primarily enabled to support the agilex spl hex


file requirements.  Since this option now produces a warning during


build, and the spl hex can be created using alternate methods,


CONFIG_OF_EMBED is no longer needed.


OK, so this patch removes functionality.

Can that functionality be retained ? Or what can be done here?

The functionality is no longer required.


Because you always depend on ATF now ?

No. We have 2 different defconfigs in the patchset, one use ATF one without

ATF. Both no longer using CONFIG_OF_EMBED and they worked fine.


OK. So how is the .hex file generated now ?

In our tree the patch i submitted to generate the hex file via objcopy is being 
used. I can resubmit this?

Otherwise, people are just manually calling objcopy to convert the cat'ed 
spl-dtb.bin to a hex file offset
to the appropriate address.

--dalon

Re: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED

[Westergreen, Dalon]

On Tue, 2020-02-25 at 18:55 +0100, Marek Vasut wrote:
> On 2/24/20 3:26 AM, Ang, Chee Hong wrote:
> > > On 2/21/20 7:15 PM, Ang, Chee Hong wrote:
> > > > > On 2/20/20 6:04 PM, Westergreen, Dalon wrote:
> > > > > 
> > > > > Please fix your mailer, it makes your reply completely unreadable.
> > > > > 
> > > > > > On Thu, 2020-02-20 at 17:44 +0100, Marek Vasut wrote:
> > > > > > 
> > > > > > On 2/20/20 3:12 AM, Ang, Chee Hong wrote:
> > > > > > 
> > > > > > On 2/19/20 1:25 PM,
> > > > > > 
> > > > > > <mailto:chee.hong@intel.com>
> > > > > > 
> > > > > > chee.hong@intel.com
> > > > > > 
> > > > > >  wrote:
> > > > > > 
> > > > > > From: Chee Hong Ang <
> > > > > > 
> > > > > > <mailto:chee.hong@intel.com>
> > > > > > 
> > > > > > chee.hong@intel.com
> > > > > > 
> > > > > > 
> > > > > > CONFIG_OF_EMBED was primarily enabled to support the agilex spl hex
> > > > > > 
> > > > > > file requirements.  Since this option now produces a warning during
> > > > > > 
> > > > > > build, and the spl hex can be created using alternate methods,
> > > > > > 
> > > > > > CONFIG_OF_EMBED is no longer needed.
> > > > > 
> > > > > OK, so this patch removes functionality.
> > > > > Can that functionality be retained ? Or what can be done here?
> > > > The functionality is no longer required.
> > > 
> > > Because you always depend on ATF now ?
> > No. We have 2 different defconfigs in the patchset, one use ATF one without
> > ATF. Both no longer using CONFIG_OF_EMBED and they worked fine.
> 
> OK. So how is the .hex file generated now ?

Sorry, re-installed my OS and neglected to turn off HTML for my email default...

In our tree the patch i submitted to generate the hex file via objcopy is being
used. I can resubmit this?

Otherwise, people are just manually calling objcopy to convert the cat'ed spl-
dtb.bin to a hex file offset
to the appropriate address.

--dalon

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

[Westergreen, Dalon]

On Tue, 2019-02-12 at 01:01 +0800, Chee, Tien Fong wrote:
> On Mon, 2019-02-11 at 12:01 +0100, Marek Vasut wrote:
> > On 2/11/19 6:36 AM, Chee, Tien Fong wrote:
> > > On Tue, 2019-02-05 at 09:46 +0100, Marek Vasut wrote:
> > > > On 2/1/19 5:02 PM, Chee, Tien Fong wrote:
> > > > > 
> > > > > On Fri, 2019-02-01 at 09:25 +0100, Marek Vasut wrote:
> > > > > > 
> > > > > > On 2/1/19 4:48 AM, Chee, Tien Fong wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > On Thu, 2019-01-31 at 15:54 +0100, Marek Vasut wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On 1/31/19 3:51 PM, 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  > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > > changes for v7
> > > > > > > > > - Provided example of setting FPGA FIT image for both
> > > > > > > > > early
> > > > > > > > > IO
> > > > > > > > > release
> > > > > > > > >   and full release FPGA configuration.
> > > > > > > > > ---
> > > > > > > > >  .../fpga/altera-socfpga-a10-fpga-mgr.txt   |
> > > > > > > > > 34
> > > > > > > > > +-
> > > > > > > > >  1 file changed, 33 insertions(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > 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..5f81a32 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,8 +7,39 @@ 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
> > > > > > > > > bitstream
> > > > > > > > > which
> > > > > > > > > is used
> > > > > > > > > +to initialize FPGA IOs, PLL, IO48
> > > > > > > > > and
> > > > > > > > > DDR.
> > > > > > > > > This
> > > > > > > > > bitstream is
> > > > > > > > > +required to get DDR up running.
> > > > > > > > > +or
> > > > > > > > > +File name for full bitstream,
> > > > > > > > > consist
> > > > > > > > > of
> > > > > > > > > peripheral bitstream
> > > > > > > > > +and core bitstream.
> > > > > > > > > +- altr,bitstream-core(optional) : File name for core
> > > > > > > > > bitstream
> > > > > > > > > which contains
> > > > > > > > Is the name of the property 'altr,bitstream-
> > > > > > > > core(optional)' ?
> > > > > > > > I
> > > > > > > > think
> > > > > > > > the "optional" part should be in the description.
> > > > > > > Yes, you are right.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > +   FPGA design which is
> > > > > > > > > used to
> > > > > > > > > program FPGA CRAM
> > > > > > > > > +   and ERAM.
> > > > > > > > >  
> > > > > > > > > -Example:
> > > > > > > > > +Example: Bundles both peripheral bitstream and core
> > > > > > > > > bitstream
> > > > > > > > > into
> > > > > > > > > FIT image
> > > > > > > > > +  called fit_spl_fpga.itb. This FIT image can
> > > > > > > > > be
> > > > > > > > > created
> > > > > > > > > through running
> > > > > > > > > +  this command: tools/mkimage
> > > > > > > > > +-E -p 400
> > > > > > > > > +-f board/altera/arria10-
> > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > +fit_spl_fpga.itb
> > > > > > > > > +
> > > > > > > > > +  For details of describing structure and
> > > > > > > > > contents
> > > > > > > > > of
> > > > > > > > > the
> > > > > > > > > FIT image,
> > > > > > > > > +  please refer board/altera/arria10-
> > > > > > > > > socdk/fit_spl_fpga.its
> > > > > > > > > +
> > > > > > > > > +- Examples for booting with early IO release, and
> > > > > > > > > enter
> > > > > > > > > early
> > > > > > > > > user
> > > > > > > > > mode:
> > > > > > > > > +
> > > > > > > > > + fpga_mgr: fpga-mgr@ffd03000 {
> > > > > > > > > + compatible = "altr,socfpga-a10-f

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

[Westergreen, Dalon]

On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > 
> > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > 
> > > > > > On 2/13/19 3:18 PM, 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 
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > changes for v7
> > > > > > > - Removed casting for get_fpga_filename
> > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > bistream,
> > > > > > > using
> > > > > > > loadable
> > > > > > >   property from FIT.
> > > > > > > - Added checking for config_pins, return if error.
> > > > > > > ---
> > > > > > >  arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > -
> > > > > > >  1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > 
> > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > b/arch/arm/mach-
> > > > > > > socfpga/spl_a10.c
> > > > > > > index c97eacb..36003b1 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-2019 Altera Corporation  > > > > > > .com
> > > > > > > > 
> > > > > > >   */
> > > > > > >  
> > > > > > >  #include 
> > > > > > > @@ -23,6 +23,8 @@
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > > +#include 
> > > > > > > +#include 
> > > > > > >  
> > > > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > > >  
> > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > boot_device)
> > > > > > >  
> > > > > > >  void spl_board_init(void)
> > > > > > >  {
> > > > > > > + char buf[16 * 1024] __aligned(ARCH_DMA_MINALIGN);
> > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > #define ARCH_DMA_MINALIGN CONFIG_SYS_CACHELINE_SIZE
> > > > > They are not same thing?
> > > > See include/memalign.h and other drivers, the macro is preferred
> > > > as
> > > > it
> > > > hides the details.
> > > Okay.
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > +
> > > > > > >   /* enable console uart printing */
> > > > > > >   preloader_console_init();
> > > > > > >   WATCHDOG_RESET();
> > > > > > >  
> > > > > > >   arch_early_init_r();
> > > > > > > +
> > > > > > > + /* If the full FPGA is already loaded, ie.from
> > > > > > > EPCQ,
> > > > > > > config fpga pins */
> > > > > > > + if (is_fpgamgr_user_mode()) {
> > > > > > > + int ret = config_pins(gd->fdt_blob,
> > > > > > > "shared");
> > > > > > > +
> > > > > > > + if (ret)
> > > > > > > + return;
> > > > > > > +
> > > > > > > + ret = config_pins(gd->fdt_blob, "fpga");
> > > > > > > + if (ret)
> > > > > > > + return;
> > > > > > > + } else if (!is_fpgamgr_early_user_mode()) {
> > > > > > > + /* Program IOSSM(early IO release) or full
> > > > > > > FPGA */
> > > > > > > + fpga_fs_info fpga_fsinfo;
> > > > > > > + int len;
> > > > > > > +
> > > > > > > + fpga_fsinfo.filename =
> > > > > > > get_fpga_filename(gd-
> > > > > > > > 
> > > > > > > > fdt_blob, &len);
> > > > > > > +
> > > > > > > + if (fpga_fsinfo.filename)
> > > > > > > + socfpga_loadfs(&fpga_fsinfo, buf,
> > > > > > > sizeof(buf), 0);
> > > > > > Why is this code here twice ? The same code seems to be below
> > > > > > ...
> > > > > The 1st calling for periph program, then running ddr
> > > > > calibration,
> > > > > then
> > > > > 2nd calling for core program.
> > > > Then maybe the code can be deduplicated ?
> > > Hmm...seems cannot, because
> > > 1. DDR calibration is not part of fpga code.
> > > 2. fpga driver can only be used to process one bistream at a time,
> > > because different mode has different handling.
> > +   } else if (!is_fpgamgr_early_user_mode()) {
> > +   /* Program IOSSM(early IO release) or full FPGA */
> > +   fpga_fs_info fpga_fsinfo;
> > +   int len;
> > +
> > +   fpga_fsinfo.filename = get_fpga_filename(gd-
> > > fdt_blob, &len);
> > +
> > +   if (fpga_fsinfo.filename)
> > +   socfpga_loadfs(&fpga_fsinfo, buf,
> > sizeof(buf), 0);
> > 

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

[Westergreen, Dalon]

On Thu, 2019-02-14 at 16:59 +, Chee, Tien Fong wrote:
> On Thu, 2019-02-14 at 16:33 +0000, Westergreen, Dalon wrote:
> > On Thu, 2019-02-14 at 15:15 +, Chee, Tien Fong wrote:
> > > On Thu, 2019-02-14 at 13:28 +0100, Marek Vasut wrote:
> > > > On 2/14/19 12:38 PM, Chee, Tien Fong wrote:
> > > > > On Thu, 2019-02-14 at 11:42 +0100, Marek Vasut wrote:
> > > > > > On 2/14/19 7:50 AM, Chee, Tien Fong wrote:
> > > > > > > 
> > > > > > > On Wed, 2019-02-13 at 17:25 +0100, Marek Vasut wrote:
> > > > > > > > 
> > > > > > > > On 2/13/19 3:18 PM, 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  > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > > 
> > > > > > > > > changes for v7
> > > > > > > > > - Removed casting for get_fpga_filename
> > > > > > > > > - Removed hard coding DDR address for loading core
> > > > > > > > > bistream,
> > > > > > > > > using
> > > > > > > > > loadable
> > > > > > > > >   property from FIT.
> > > > > > > > > - Added checking for config_pins, return if error.
> > > > > > > > > ---
> > > > > > > > >  arch/arm/mach-socfpga/spl_a10.c | 41
> > > > > > > > > -
> > > > > > > > >  1 file changed, 40 insertions(+), 1 deletion(-)
> > > > > > > > > 
> > > > > > > > > diff --git a/arch/arm/mach-socfpga/spl_a10.c
> > > > > > > > > b/arch/arm/mach-
> > > > > > > > > socfpga/spl_a10.c
> > > > > > > > > index c97eacb..36003b1 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  > > > > > > > > com>
> > > > > > > > > + *  Copyright (C) 2012-2019 Altera Corporation  > > > > > > > > tera
> > > > > > > > > .com
> > > > > > > > > > 
> > > > > > > > >   */
> > > > > > > > >  
> > > > > > > > >  #include 
> > > > > > > > > @@ -23,6 +23,8 @@
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > >  #include 
> > > > > > > > > +#include 
> > > > > > > > > +#include 
> > > > > > > > >  
> > > > > > > > >  DECLARE_GLOBAL_DATA_PTR;
> > > > > > > > >  
> > > > > > > > > @@ -68,11 +70,48 @@ u32 spl_boot_mode(const u32
> > > > > > > > > boot_device)
> > > > > > > > >  
> > > > > > > > >  void spl_board_init(void)
> > > > > > > > >  {
> > > > > > > > > + char buf[16 * 1024]
> > > > > > > > > __aligned(ARCH_DMA_MINALIGN);
> > > > > > > > ALLOC_CACHE_ALIGN_BUFFER()
> > > > > > &

Re: [U-Boot] cyclone5 reboot: warm or cold reset?

[Westergreen, Dalon]

On Tue, 2019-04-30 at 22:09 +0200, Marek Vasut wrote:
> On 4/30/19 10:05 PM, Simon Goldschmidt wrote:
> > Am 30.04.2019 um 22:01 schrieb Marek Vasut:
> > > On 4/30/19 9:19 PM, Simon Goldschmidt wrote:
> > > > Am 30.04.2019 um 21:08 schrieb Marek Vasut:
> > > > > On 4/30/19 8:56 PM, Simon Goldschmidt wrote:
> > > > > > Hi all,
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > > I added some of those I think worth discussing this.
> > > > > > 
> > > > > > I was chasing a reboot problem on one of our cyclone5 boards today.
> > > > > > That
> > > > > > board boots from a "n25q256a" qspi flash. Up to now, U-Boot
> > > > > > configures
> > > > > > the boot ROM to just jump to OCRAM when rebooting and hope that the
> > > > > > SPL
> > > > > > is still there and fully working (nothing's overwritten).
> > > > > > 
> > > > > > For a long running production board, this is of course crap, as a
> > > > > > pointer running wild could always overwrite the SRAM. But there was
> > > > > > not
> > > > > > much we could do about it as long as U-Boot and/or Linux were
> > > > > > putting
> > > > > > out 32 Mbyte chip into 4-byte mode: it's not accessible by the Boot
> > > > > > ROM
> > > > > > unless in 3-byte mode. And while Linux "reboot" could reset the chip
> > > > > > into 3-byte mode, "reboot -f" and U-Boot "reset" can't.
> > > > > > 
> > > > > > Now with U-Boot and Linux having everything in place to leave the
> > > > > > spi-nor in 3-byte mode (as required for the Boot ROM) using 4-byte
> > > > > > opcodes, I thought rebooting from Linux would now work with loading
> > > > > > the
> > > > > > SPL from qspi (by disabling the magic that tells the Boot ROM to
> > > > > > jump to
> > > > > > OCRAM).
> > > > > 
> > > > > Well, if the chip is in the middle of some operation (erase or page
> > > > > program) and you reset the CPU just at the right moment, leaving the
> > > > > chip in 3byte addressing mode won't help you anyway.
> > > > 
> > > > Right, but unfortunately, that's not an issue for us :-)
> > > > 
> > > > > The only reliable solution is to connect reset to the SPI NOR chip and
> > > > > trigger the reset. Of course, some SPI NORs have a reset line, but
> > > > > it is
> > > > > not connected internally, which is a fantastic design. I think the
> > > > > N25Q256 had exactly such a problem, but only on some revisions, to
> > > > > make
> > > > > it even more messed up.
> > > > 
> > > > Yeah, well, let's just assume there *are* boards that either use spi-nor
> > > > chips without a working reset line and there *are* boards with spi-nor
> > > > chips having a reset line that is just not connected...
> > > > 
> > > > > > However, I found the Boot ROM still cannot load the SPL because it
> > > > > > tries
> > > > > > to load at 100 MHz (while on cold boot, it loads with 6.25 MHz).
> > > > > 
> > > > > Look at 
> > > > > https://patchwork.ozlabs.org/patch/729738/
> > > > > 
> > > > 
> > > > Interesting, I didn't know that one. I doesn't seem to have made it into
> > > > the tree, but it's a different thing slightly: it prevents the Boot ROM
> > > > jumping to OCRAM, but that's what I did and it still fails as the Boot
> > > > ROM uses a constant divider "4" resulting in loading SPL with 100 MHz
> > > > from the qspi chip. And that somehow fails.
> > > 
> > > It makes the bootrom jump "somewhere else" in OCRAM upon warm reset, to
> > > a code which resets the PLLs and then triggers another warm reset, this
> > > time with a jump address pointing to the SPL.
> > 
> > Well, what I read from hat patch is that it only writes the magic to
> > make Boot ROM jump to OCRAM if csel != 0. So it would try to load SPL
> > from QSPI for csel == 0 in my case (and I do have csel ==0 0).
> > 
> > I fail to see the "somewhere else" in the link you sent. Maybe that was
> > in an older version?
> 
> That's quite possible , there were a few iterations.

In some ES silicon for C5, which happens to be what is used on the DE0 board,
there was an issue that required CSEL=0.  As noted in the comments, for CSEL=0
the bootrom does not reset the PLL/clock configurations and as a result the QSPI
clock in your case is not being modified to a useable clock for the bootrom.
The patch just forced a cold reset when csel=0.   personally, i would like a
default to cold resets, with an option to use warm resets should a use case
exist (such as preserving DDR contents).

What changed with 4-byte access in the QSPI?

--dalon

> 
> > > > If I change the handoff files so that the qspi core runs at 200 MHz
> > > > instead of 400 MHz, it works (qspi loaded with 50 MHz), but I think cold
> > > > reset would still be better...
> > > > 
> > > > > > However, when triggering cold reset instead of warm reset in rstmgr
> > > > > > ctrl
> > > > > > register [1], it works fine (and qspi clock is 6.25 MHz).
> > > > > > 
> > > > > > Now the question is: why do we trigger warm reset instead of cold
> > > > > > reset?
> > > > > 
> > > > > I'd like to know that too. But it's like

Re: [U-Boot] [PATCH 03/10] ddr: altera: s10: Add multiple memory banks support

[Westergreen, Dalon]

On Tue, 2019-03-12 at 11:44 +0100, Marek Vasut wrote:
> On 3/12/19 9:31 AM, Ley Foon Tan wrote:
> > Setup bank start address and size based on total SDRAM
> > memory size calculated from hardware. Update sdram_size_check()
> > to support multiple banks.
> > 
> > Stratix10 supports up to 2 memory banks.
> > 
> > Bank 0: Address 0, size 2GB
> > Bank 1: Address 0x1, size 124GB
> > 
> > Signed-off-by: Dalon Westergreen 
> > Signed-off-by: Ley Foon Tan 
> 
> Shouldn't Quartus generate some sort of DT which gives you all the DRAM
> layout information ? Then you won't need any of this
> CONFIG_NR_DRAM_BANKS stuff, but you would be able to extract such info
> from DT and apply the sanity check only on DRAM you know exists.
> 
Yes, I think this can be much cleaner and the dts should provide the bank
information rather than creating the banks from the determined dram size.

The determined dram size can just be a check to validate the bank configuration
in the dts.

so

diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
b/arch/arm/dts/socfpga_stratix10_socdk.dts
index 6e8ddcd9f4..94c71bb0ed 100644
--- a/arch/arm/dts/socfpga_stratix10_socdk.dts
+++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
@@ -36,7 +36,9 @@

memory {
device_type = "memory";
-   reg = <0 0 0 0x8000>; /* 2GB */
+   /* 4GB */
+   reg = < 0 0x 0 0x8000
+   1 0x8000 0 0x8000>;
u-boot,dm-pre-reloc;
};
 };

--dalon





smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 04/10] arm: socfpga: Update dram_init_banksize() for Stratix10

[Westergreen, Dalon]

On Tue, 2019-03-12 at 11:45 +0100, Marek Vasut wrote:
> On 3/12/19 9:31 AM, Ley Foon Tan wrote:
> > Setup bi_dram struct based on returned from setup_memory_banks().
> > 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  arch/arm/mach-socfpga/board.c | 16 +++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
> > index 7c8c05cc31..a0e9917e47 100644
> > --- a/arch/arm/mach-socfpga/board.c
> > +++ b/arch/arm/mach-socfpga/board.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -48,8 +49,21 @@ int board_init(void)
> >  
> >  int dram_init_banksize(void)
> >  {
> > -   fdtdec_setup_memory_banksize();
> > +#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10) &&
> > defined(CONFIG_ALTERA_SDRAM)
> > +   phys_addr_t bank_start[CONFIG_NR_DRAM_BANKS];
> > +   phys_size_t bank_size[CONFIG_NR_DRAM_BANKS];
> > +   int bank;
> > +
> > +   gd->ram_size = sdram_calculate_size();
> > +   setup_memory_banks(bank_start, bank_size);
> >  
> > +   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> > +   gd->bd->bi_dram[bank].start = bank_start[bank];
> > +   gd->bd->bi_dram[bank].size = bank_size[bank];
> > +   }
> > +#else
> > +   fdtdec_setup_memory_banksize();
> > +#endif
> > return 0;
> >  }
> 
> Split this out into separate file if this really needs to be different,
> but can't you somehow use fdtdec_setup_memory_size() on S10 and then
> apply sanity checking instead ?
> 
yes, this can be done with fdtdec_setup_memory_size.

--dalon



smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 05/10] board: altera: Stratix10: Add board_get_usable_ram_top()

[Westergreen, Dalon]

On Tue, 2019-03-12 at 11:46 +0100, Marek Vasut wrote:
> On 3/12/19 9:31 AM, Ley Foon Tan wrote:
> > Add board_get_usable_ram_top() function. Limit maximum usable
> > ram top to 2GB.
> 
> Why ? There are ARM64 platforms which can access the entire DRAM range
> just fine, what's the problem ?
> 

The issue is the gap in memory between 2GB and 4GB.  There is some trickery
you can use to gain access to the memory in that range, but in general, you
dont have access.  I believe just setting the banks up in the dts will
resolve this.

--dalon

> > Signed-off-by: Dalon Westergreen 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  board/altera/stratix10-socdk/socfpga.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/board/altera/stratix10-socdk/socfpga.c
> > b/board/altera/stratix10-socdk/socfpga.c
> > index 043fc543f1..99c10d313c 100644
> > --- a/board/altera/stratix10-socdk/socfpga.c
> > +++ b/board/altera/stratix10-socdk/socfpga.c
> > @@ -5,3 +5,15 @@
> >   */
> >  
> >  #include 
> > +#include 
> > +#include 
> > +
> > +#ifdef CONFIG_ALTERA_SDRAM
> > +ulong board_get_usable_ram_top(ulong total_size)
> > +{
> > +   if (sdram_calculate_size() > SZ_2G)
> > +   return SZ_2G;
> > +   else
> > +   return sdram_calculate_size();
> > +}
> > +#endif
> > 
> 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [PATCH v1] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images

[Westergreen, Dalon]

Can you explain why this x4 image is needed?  the top level u-boot-with-spl.sfp
or whatever it is called already creates four spl entries.  what are you
generating the x4 image for?

--dalon

On Wed, 2020-08-05 at 16:15 +0800, Chee Hong Ang wrote:
> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required
> for booting up Cyclone5/Arria10.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  Makefile | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 2629a74..13429a0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1578,8 +1578,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE
>  ifneq ($(CONFIG_ARCH_SOCFPGA),)
>  quiet_cmd_socboot = SOCBOOT $@
>  cmd_socboot = catspl/u-boot-spl.sfp spl/u-boot-spl.sfp   \
> - spl/u-boot-spl.sfp spl/u-boot-spl.sfp   \
> - u-boot.img > $@ || rm -f $@
> + spl/u-boot-spl.sfp \
> + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \
> +   cat   spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@
>  u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
>   $(call if_changed,socboot)
>