Re: [U-Boot] [PATCH 08/20] arm: socfpga: add system manager for Arria 10

[Ley Foon Tan]

On Sab, 2017-02-25 at 22:36 +0100, Marek Vasut wrote:
> On 02/22/2017 10:47 AM, Ley Foon Tan wrote:
> > 
> > Add system manager support for Arria 10.
> But these are just headers, there's no system manager code here ?
Yes. Mainly for system manager's register struct and defines.
> 
> > 
> > Signed-off-by: Tien Fong Chee 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  .../arm/mach-socfpga/include/mach/system_manager.h | 54
> > ++-
> >  .../include/mach/system_manager_arria10.h  | 81
> > ++
> >  .../include/mach/system_manager_gen5.h |  1 +
> >  3 files changed, 135 insertions(+), 1 deletion(-)
> >  create mode 100755 arch/arm/mach-
> > socfpga/include/mach/system_manager_arria10.h
> > 
> > 
> > 
[...]

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

Re: [U-Boot] [PATCH 07/20] arm: socfpga: add clock driver for Arria 10

[Ley Foon Tan]

On Sab, 2017-02-25 at 22:35 +0100, Marek Vasut wrote:
> On 02/22/2017 10:47 AM, Ley Foon Tan wrote:
> > 
> > Add clock driver support for Arria 10 and update Gen5 clock driver.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  arch/arm/mach-socfpga/Makefile |3 +-
> >  arch/arm/mach-socfpga/clock_manager.c  |   36 +-
> >  arch/arm/mach-socfpga/clock_manager_arria10.c  | 1104
> > 
> >  arch/arm/mach-socfpga/clock_manager_gen5.c |  132 ++-
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h |8 +-
> >  .../include/mach/clock_manager_arria10.h   |  231 
> >  6 files changed, 1455 insertions(+), 59 deletions(-)
> >  create mode 100644 arch/arm/mach-socfpga/clock_manager_arria10.c
> >  mode change 100755 => 100644 arch/arm/mach-
> > socfpga/clock_manager_gen5.c
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/clock_manager_arria10.h
> > 
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index d81f003..c494930 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -10,7 +10,8 @@
> >  obj-y  += misc.o timer.o reset_manager.o clock_manager.o \
> >        fpga_manager.o board.o
> >  
> > -obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += reset_manager_arria10.o
> > +obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clock_manager_arria10.o \
> > +   reset_manager_arria10.o
> >  
> >  obj-$(CONFIG_SPL_BUILD) += spl.o freeze_controller.o
> >  
> > diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> > socfpga/clock_manager.c
> > index d675973..7f48193 100644
> > --- a/arch/arm/mach-socfpga/clock_manager.c
> > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > @@ -7,6 +7,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> > @@ -18,7 +19,12 @@ void cm_wait_for_lock(u32 mask)
> >     register u32 inter_val;
> >     u32 retry = 0;
> >     do {
> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> A10 should be below Gen5 to keep this sorted chronologically IMO.
Okay.
> 
> > 
> > +   inter_val = readl(_manager_base->stat) &
> > mask;
> > +#elif defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >     inter_val = readl(_manager_base->inter) &
> > mask;
> > +#endif
> > +   /* Wait for stable lock */
> >     if (inter_val == mask)
> >     retry++;
> >     else
> > @@ -31,22 +37,39 @@ void cm_wait_for_lock(u32 mask)
> >  /* function to poll in the fsm busy bit */
> >  void cm_wait_for_fsm(void)
> >  {
> > -   while (readl(_manager_base->stat) &
> > CLKMGR_STAT_BUSY)
> > +   while (readl(_manager_base->stat) &
> > +      CLKMGR_CLKMGR_STAT_BUSY_SET_MSK)
> >     ;
> >  }
> >  
> >  static void cm_print_clock_quick_summary(void)
> >  {
> >     printf("MPU   %10ld kHz\n", cm_get_mpu_clk_hz() /
> > 1000);
> > +   printf("MMC %8d kHz\n",
> > cm_get_mmc_controller_clk_hz() / 1000);
> > +   printf("QSPI%8d kHz\n",
> > +      cm_get_qspi_controller_clk_hz() / 1000);
> > +   printf("SPI %8d kHz\n",
> > cm_get_spi_controller_clk_hz() / 1000);
> > +#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > +   printf("EOSC1   %8d kHz\n", eosc1_hz / 1000);
> > +   printf("cb_intosc   %8d kHz\n", cb_intosc_hz / 1000);
> > +   printf("f2s_free%8d kHz\n", f2s_free_hz / 1000);
> > +   printf("Main VCO%8d kHz\n",
> > cm_get_main_vco_clk_hz()/1000);
> > +   printf("NOC %8d kHz\n", cm_get_noc_clk_hz()/1000);
> > +   printf("L4 Main %8d kHz\n",
> > +      cm_get_l4_noc_hz(CLKMGR_MAINPLL_NOCDIV_L4MAINCLK_LS
> > B)/1000);
> > +   printf("L4 MP   %8d kHz\n",
> > +      cm_get_l4_noc_hz(CLKMGR_MAINPLL_NOCDIV_L4MPCLK_LSB)
> > /1000);
> > +   printf("L4 SP   %8d kHz\n",
> > +      cm_get_l4_sp_clk_hz()/1000);
> > +   printf("L4 sys free %8d kHz\n",
> > cm_l4_sys_free_clk_hz/1000);
> > +#elif defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >     printf("DDR   %10ld kHz\n", cm_get_sdram_clk_hz() /
> > 1000);
> >     printf("EOSC1   %8d kHz\n", cm_get_osc_clk_hz(1) /
> > 1000);
> >     printf("EOSC2   %8d kHz\n", cm_get_osc_clk_hz(2) /
> > 1000);
> >     printf("F2S_SDR_REF %8d kHz\n",
> > cm_get_f2s_sdr_ref_clk_hz() / 1000);
> >     printf("F2S_PER_REF %8d kHz\n",
> > cm_get_f2s_per_ref_clk_hz() / 1000);
> > -   printf("MMC %8d kHz\n",
> > cm_get_mmc_controller_clk_hz() / 1000);
> > -   printf("QSPI%8d kHz\n",
> > cm_get_qspi_controller_clk_hz() / 1000);
> >     printf("UART%8d kHz\n", cm_get_l4_sp_clk_hz() /
> > 1000);
> > -   printf("SPI %8d kHz\n",
> > cm_get_spi_controller_clk_hz() / 1000);
> > +#endif
> >  }
> >  
> >  int set_cpu_clk_info(void)
> > @@ -57,7 +80,12 @@ int set_cpu_clk_info(void)
> >  
> >     gd->bd->bi_arm_freq = cm_get_mpu_clk_hz() / 

Re: [U-Boot] [U-Boot 0/2] add spl_early_init to fix rk3288 board broken issue

[Eddie Cai]

Hi Simon
I guess you may lost this patch. So a friendly ping.

2017-02-23 9:59 GMT+08:00 Eddie Cai :

> Andrew F. Davis's below patch broke rk3288 based board. that is because we
> call
> spl_init in board_init_f which is at very early stage. What Andrew want to
> fix
> is calling spl_init very late. That patch will make malloc_base, limit,
> ptr not
> initualized in spl_init when we call spl_init in board_init_f. This patch
> set
> add spl_early_init. it can be called in board_init_f. So we can fix this
> issue
> by using spl_early_init.
>
> commit b3d2861eb20a795b99292b823c923935df26dfc6
> Author: Andrew F. Davis 
> Date:   Fri Jan 27 10:39:19 2017 -0600
>
> spl: Remove overwrite of relocated malloc limit
>
> Eddie Cai (2):
>   spl: add spl_early_init
>   rockchip: use spl_early_init instead of spl_init
>
>  arch/arm/mach-rockchip/rk3288-board-spl.c |  2 +-
>  common/spl/spl.c  | 54
> ++-
>  include/asm-generic/global_data.h |  1 +
>  include/spl.h | 12 ++-
>  4 files changed, 59 insertions(+), 10 deletions(-)
>
> --
> 2.7.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] rockchip: set scan_dev_for_boot_part env for rockchip SoC

[Eddie Cai]

Hi Simon

2017-02-23 11:33 GMT+08:00 Simon Glass :

> Hi Eddie,
>
> On 22 February 2017 at 07:12, Eddie Cai  wrote:
> > Hi Simon
> >
> > 2017-02-22 17:05 GMT+08:00 Eddie Cai :
> >>
> >> Hi Simon
> >>
> >> 2017-02-22 11:59 GMT+08:00 Simon Glass :
> >>>
> >>> Hi Eddie,
> >>>
> >>> On 17 February 2017 at 00:57, Eddie Cai 
> >>> wrote:
> >>> > Auto write GPT table if fail to get GPT table when
> >>> > scan_dev_for_boot_part
> >>> >
> >>> > Signed-off-by: Eddie Cai 
> >>> > ---
> >>> >  arch/arm/mach-rockchip/rk3036-board.c | 20 ++-
> >>> >  arch/arm/mach-rockchip/rk3288-board.c | 20 ++-
> >>> >  arch/arm/mach-rockchip/rk3399-board.c | 46
> >>> > +++
> >>> >  3 files changed, 84 insertions(+), 2 deletions(-)
> >>> >  create mode 100644 arch/arm/mach-rockchip/rk3399-board.c
> >>> >
> >>> > diff --git a/arch/arm/mach-rockchip/rk3036-board.c
> >>> > b/arch/arm/mach-rockchip/rk3036-board.c
> >>> > index bf2b268..e9aeaff 100644
> >>> > --- a/arch/arm/mach-rockchip/rk3036-board.c
> >>> > +++ b/arch/arm/mach-rockchip/rk3036-board.c
> >>> > @@ -51,7 +51,25 @@ __weak int rk_board_late_init(void)
> >>> >  int board_late_init(void)
> >>> >  {
> >>> > setup_boot_mode();
> >>> > -
> >>> > +   setenv("scan_dev_for_boot_part",
> >>> > +   "part list ${devtype} ${devnum} -bootable
> test;
> >>> > "
> >>> > +   "if env exists test; then "
> >>> > +  "echo Found valid partition table; "
> >>> > +   "else "
> >>> > +  "echo No valid partition table, write the
> >>> > original partition table; "
> >>> > +  "gpt write ${devtype} ${devnum}
> >>> > ${partitions}; "
> >>> > +  "mmc rescan;"
> >>> > +   "fi;"
> >>> > +   "part list ${devtype} ${devnum} -bootable
> >>> > devplist; "
> >>> > +   "env exists devplist || setenv devplist 1; "
> >>> > +   "for distro_bootpart in ${devplist}; do "
> >>> > +   "if fstype ${devtype} "
> >>> > +   "${devnum}:${distro_bootpart} "
> >>> > +   "bootfstype; then "
> >>> > +   "run scan_dev_for_boot; "
> >>> > + "fi; "
> >>> > +   "done\0"
> >>> > +   );
> >>> > return rk_board_late_init();
> >>> >  }
> >>> >
> >>> > diff --git a/arch/arm/mach-rockchip/rk3288-board.c
> >>> > b/arch/arm/mach-rockchip/rk3288-board.c
> >>> > index 9894a25..386b155 100644
> >>> > --- a/arch/arm/mach-rockchip/rk3288-board.c
> >>> > +++ b/arch/arm/mach-rockchip/rk3288-board.c
> >>> > @@ -74,7 +74,25 @@ int board_late_init(void)
> >>> >  {
> >>> > setup_boot_mode();
> >>> > rk3288_qos_init();
> >>> > -
> >>> > +   setenv("scan_dev_for_boot_part",
> >>> > +   "part list ${devtype} ${devnum} -bootable
> test;
> >>> > "
> >>> > +   "if env exists test; then "
> >>> > +  "echo Found valid partition table; "
> >>> > +   "else "
> >>> > +  "echo No valid partition table, write the
> >>> > original partition table; "
> >>> > +  "gpt write ${devtype} ${devnum}
> >>> > ${partitions}; "
> >>> > +  "mmc rescan;"
> >>> > +   "fi;"
> >>> > +   "part list ${devtype} ${devnum} -bootable
> >>> > devplist; "
> >>> > +   "env exists devplist || setenv devplist 1; "
> >>> > +   "for distro_bootpart in ${devplist}; do "
> >>> > +   "if fstype ${devtype} "
> >>> > +   "${devnum}:${distro_bootpart} "
> >>> > +   "bootfstype; then "
> >>> > +   "run scan_dev_for_boot; "
> >>> > + "fi; "
> >>> > +   "done\0"
> >>> > +   );
> >>> > return rk_board_late_init();
> >>> >  }
> >>> >
> >>> > diff --git a/arch/arm/mach-rockchip/rk3399-board.c
> >>> > b/arch/arm/mach-rockchip/rk3399-board.c
> >>> > new file mode 100644
> >>> > index 000..3777643
> >>> > --- /dev/null
> >>> > +++ b/arch/arm/mach-rockchip/rk3399-board.c
> >>> > @@ -0,0 +1,46 @@
> >>> > +/*
> >>> > + * (C) Copyright 2017 ockchip Electronics Co., Ltd
> >>> > + *
> >>> > + * SPDX-License-Identifier: GPL-2.0+
> >>> > + */
> >>> > +
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +#include 
> >>> > +
> >>> > +DECLARE_GLOBAL_DATA_PTR;
> >>> > 

[U-Boot] distro bootcmd: auto write GPT table in scan_dev_for_boot_part

[Eddie Cai]

scan_dev_for_boot_part will fail when there is no GPT table. So add auto write
GPT table if fail to get it.

Signed-off-by: Eddie Cai 
---
 include/config_distro_bootcmd.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 0e01e82..3be8ffa 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -368,6 +368,14 @@
"\0"  \
\
"scan_dev_for_boot_part=" \
+   "part list ${devtype} ${devnum} -bootable test; "   
\
+   "if env exists test; then " \
+   "echo Found valid partition table; "\
+   "else " \
+   "echo No valid partition table, write the original 
partition table; "   \
+   "gpt write ${devtype} ${devnum} ${partitions}; "
\
+   "mmc rescan;"   \
+   "fi;"   \
"part list ${devtype} ${devnum} -bootable devplist; " \
"env exists devplist || setenv devplist 1; "  \
"for distro_bootpart in ${devplist}; do " \
-- 
2.7.4

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

Re: [U-Boot] [PATCH 1/4] arm: socfpga: Removing unused passing parameter of socfpga_bridges_reset

[Chee, Tien Fong]

On Ahd, 2017-03-05 at 01:57 +0100, Marek Vasut wrote:
> On 03/03/2017 01:50 PM, Chee Tien Fong wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patch removes the unused passing parameter of
> > socfpga_bridges_reset
> > function in Arria10.
> > 
> > Signed-off-by: Tien Fong Chee 
> > Cc: Marek Vasut 
> > Cc: Dinh Nguyen 
> > Cc: Ching Liang See 
> > Cc: Ley Foon 
> > Cc: Westergreen Dalon 
> We do NOT have arria10 support in mainline, I am confused.
> Can you please sync with Ley when submitting patches ?
> 
> Thanks
> 
This series is working on top of [1] initial patchset which enables 
the basic support for Arria 10 and other features.
https://www.mail-archive.com/u-boot@lists.denx.de/msg240053.html

I just realized i forgot to +CC you guys in the cover letter,
https://www.mail-archive.com/u-boot@lists.denx.de/msg240829.html.
I am sorry to have you confused.
> > 
> > ---
> >  arch/arm/mach-socfpga/include/mach/reset_manager.h |3 ---
> >  .../include/mach/reset_manager_arria10.h   |1 +
> >  .../mach-socfpga/include/mach/reset_manager_gen5.h |1 +
> >  arch/arm/mach-socfpga/reset_manager_arria10.c  |2 +-
> >  4 files changed, 3 insertions(+), 4 deletions(-)
> >  mode change 100755 => 100644 arch/arm/mach-
> > socfpga/include/mach/reset_manager_arria10.h
> >  mode change 100755 => 100644 arch/arm/mach-
> > socfpga/include/mach/reset_manager_gen5.h
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > index 64526b6..f5189e8 100644
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h
> > @@ -8,9 +8,6 @@
> >  #define_RESET_MANAGER_H_
> > 
> >  void reset_cpu(ulong addr);
> > -
> > -void socfpga_bridges_reset(int enable);
> > -
> >  void socfpga_per_reset(u32 reset, int set);
> >  void socfpga_per_reset_all(void);
> > 
> > diff --git a/arch/arm/mach-
> > socfpga/include/mach/reset_manager_arria10.h b/arch/arm/mach-
> > socfpga/include/mach/reset_manager_arria10.h
> > old mode 100755
> > new mode 100644
> > index 2668a86..954381c
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_arria10.h
> > @@ -16,6 +16,7 @@ void
> > reset_assert_fpga_connected_peripherals(void);
> >  void reset_deassert_osc1wd0(void);
> >  void reset_assert_uart(void);
> >  void reset_deassert_uart(void);
> > +void socfpga_bridges_reset(void);
> > 
> >  struct socfpga_reset_manager {
> >     u32 stat;
> > diff --git a/arch/arm/mach-
> > socfpga/include/mach/reset_manager_gen5.h b/arch/arm/mach-
> > socfpga/include/mach/reset_manager_gen5.h
> > old mode 100755
> > new mode 100644
> > index 028974a..da17f4c
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_gen5.h
> > @@ -8,6 +8,7 @@
> >  #define_RESET_MANAGER_GEN5_H_
> > 
> >  void reset_deassert_peripherals_handoff(void);
> > +void socfpga_bridges_reset(int enable);
> > 
> >  struct socfpga_reset_manager {
> >     u32 status;
> > diff --git a/arch/arm/mach-socfpga/reset_manager_arria10.c
> > b/arch/arm/mach-socfpga/reset_manager_arria10.c
> > index 01156de..684c6be 100644
> > --- a/arch/arm/mach-socfpga/reset_manager_arria10.c
> > +++ b/arch/arm/mach-socfpga/reset_manager_arria10.c
> > @@ -355,7 +355,7 @@ void socfpga_bridges_reset(int enable)
> >     /* For SoCFPGA-VT, this is NOP. */
> >  }
> >  #else
> > -void socfpga_bridges_reset(int enable)
> > +void socfpga_bridges_reset(void)
> >  {
> >  /* Disable all the bridges (hps2fpga, lwhps2fpga, fpga2hps,
> > fpga2sdram) */
> >     /* set idle request to all bridges */
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] Add Intel Arria 10 SoC FPGA driver

[Chee, Tien Fong]

On Jum, 2017-03-03 at 20:50 +0800, Chee Tien Fong wrote:
> From: Tien Fong Chee 
> 
> This patchset adds FPGA driver to Intel Arria 10 SoC.
> 
> This series is working on top of [1] initial patchset which enables
> the basic
> support for Arria 10 and other features.
> 
> [1]: https://www.mail-archive.com/u-boot@lists.denx.de/msg240053.html
> 
> Regards,
> Tien Fong
> 
> Tien Fong Chee (4):
>   arm: socfpga: Removing unused passing parameter of
> socfpga_bridges_reset
>   arm: socfpga: Restructure FPGA driver in the preparation to support
> A10.
>   arm: socfpga: Add Arria10 FPGA manager program assembly driver
>   arm: socfpga: Add FPGA driver support for Arria 10
> 
>  arch/arm/mach-socfpga/Makefile |3 +-
>  arch/arm/mach-socfpga/include/mach/fpga_manager.h  |   70 +--
>  .../include/mach/fpga_manager_arria10.h|  120 +
>  .../mach/{fpga_manager.h => fpga_manager_gen5.h}   |   66 ++--
>  arch/arm/mach-socfpga/include/mach/reset_manager.h |3 -
>  .../include/mach/reset_manager_arria10.h   |1 +
>  .../mach-socfpga/include/mach/reset_manager_gen5.h |1 +
>  arch/arm/mach-socfpga/lowlevel_init.S  |   48 ++
>  arch/arm/mach-socfpga/reset_manager_arria10.c  |2 +-
>  drivers/Makefile   |1 +
>  drivers/fpga/Makefile  |6 +-
>  drivers/fpga/socfpga.c |  272 +-
> -
>  drivers/fpga/socfpga_arria10.c |  565
> 
>  drivers/fpga/{socfpga.c => socfpga_gen5.c} |   33 +--
>  14 files changed, 792 insertions(+), 399 deletions(-)
>  create mode 100644 arch/arm/mach-
> socfpga/include/mach/fpga_manager_arria10.h
>  copy arch/arm/mach-socfpga/include/mach/{fpga_manager.h =>
> fpga_manager_gen5.h} (85%)
>  mode change 100755 => 100644 arch/arm/mach-
> socfpga/include/mach/reset_manager_arria10.h
>  mode change 100755 => 100644 arch/arm/mach-
> socfpga/include/mach/reset_manager_gen5.h
>  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
>  create mode 100644 drivers/fpga/socfpga_arria10.c
>  copy drivers/fpga/{socfpga.c => socfpga_gen5.c} (91%)
> 
+CC Marek, Dinh, LF, Dalon, CL ...
This is cover letter for this series patches https://www.mail-archive.c
om/u-boot@lists.denx.de/msg240843.html
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] fsl PPA: add support PPA image loading from NAND and SD

[york sun]

Sorry for top posting (using my phone).
I think we should flush the cache by range. If you are relying on PPA flushing 
the cache for you (it is the case now), it's better to put a comment there.

York


 Original Message 
From: "Z.Q. Hou" 
Sent: Sunday, March 5, 2017 07:07 PM
To: york sun 
,u-boot@lists.denx.de,o...@buserror.net,mingkai...@freescale.com,s...@chromium.org,Xiaobo
 Xie 
Subject: RE: [PATCH 3/5] fsl PPA: add support PPA image loading from NAND and SD


Hi York,

Thanks a lot for your comments!

> -Original Message-
> From: york sun
> Sent: Saturday, March 04, 2017 12:51 AM
> To: Z.Q. Hou ; u-boot@lists.denx.de;
> o...@buserror.net; mingkai...@freescale.com; s...@chromium.org; Xiaobo
> Xie 
> Subject: Re: [PATCH 3/5] fsl PPA: add support PPA image loading from NAND
> and SD
>
> On 03/03/2017 05:45 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 118
> > +++-
> >  1 file changed, 117 insertions(+), 1 deletion(-)
>
> 
>
> >
> >  #ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP
> >  ppa_fit_addr = (void *)CONFIG_SYS_LS_PPA_FW_ADDR;
> > + debug("%s: PPA image load from XIP\n", __func__); #else /*
> > +!CONFIG_SYS_LS_PPA_FW_IN_XIP */
> > + size_t fw_length, fdt_header_len = sizeof(struct fdt_header);
> > +
> > + /* Copy PPA image from MMC/SD/NAND to allocated memory */
> #ifdef
> > +CONFIG_SYS_LS_PPA_FW_IN_MMC
> > + struct mmc *mmc;
> > + int dev = CONFIG_SYS_MMC_ENV_DEV;
> > + struct fdt_header *fitp;
> > + u32 cnt;
> > + u32 blk = CONFIG_SYS_LS_PPA_FW_ADDR / 512;
> > +
> > + debug("%s: PPA image load from eMMC/SD\n", __func__);
> > +
> > + mmc_initialize(gd->bd);
> > + mmc = find_mmc_device(dev);
> > + if (!mmc) {
> > + printf("PPA: MMC cannot find device for PPA firmware\n");
> > + return -ENODEV;
> > + }
> > +
> > + mmc_init(mmc);
> > +
> > + fitp = malloc(roundup(fdt_header_len, 512));
> > + if (!fitp) {
> > + printf("PPA: malloc failed for FIT header(size 0x%zx)\n",
> > +roundup(fdt_header_len, 512));
> > + return -ENOMEM;
> > + }
> > +
> > + cnt = DIV_ROUND_UP(fdt_header_len, 512);
> > + debug("%s: MMC read PPA FIT header: dev # %u, block # %u,
> count %u\n",
> > +   __func__, dev, blk, cnt);
> > + ret = mmc->block_dev.block_read(>block_dev, blk, cnt, fitp);
> > + if (ret != cnt) {
> > + free(fitp);
> > + printf("MMC/SD read of PPA FIT header at offset 0x%x
> failed\n",
> > +CONFIG_SYS_LS_PPA_FW_ADDR);
> > + return -EIO;
> > + }
> > +
> > + /* flush cache after read */
> > + flush_cache((ulong)fitp, cnt * 512);
> > +
> > + fw_length = fdt_totalsize(fitp);
> > + free(fitp);
> > +
> > + fw_length = roundup(fw_length, 512);
> > + ppa_fit_addr = malloc(fw_length);
> > + if (!ppa_fit_addr) {
> > + printf("PPA: malloc failed for PPA image(size 0x%zx)\n",
> > +fw_length);
> > + return -ENOMEM;
> > + }
> > +
> > + cnt = DIV_ROUND_UP(fw_length, 512);
> > + debug("%s: MMC read PPA FIT image: dev # %u, block # %u,
> count %u\n",
> > +   __func__, dev, blk, cnt);
> > + ret = mmc->block_dev.block_read(>block_dev,
> > + blk, cnt, ppa_fit_addr);
> > + if (ret != cnt) {
> > + free(ppa_fit_addr);
> > + printf("MMC/SD read of PPA FIT header at offset 0x%x
> failed\n",
> > +CONFIG_SYS_LS_PPA_FW_ADDR);
> > + return -EIO;
> > + }
> > +
> > + flush_cache((ulong)ppa_fit_addr, cnt * 512);
> > +
> > +#elif CONFIG_SYS_LS_PPA_FW_IN_NAND
> > + struct fdt_header fit;
> > +
> > + debug("%s: PPA image load from NAND\n", __func__);
> > +
> > + nand_init();
> > + ret = nand_read(nand_info[0],
> (loff_t)CONFIG_SYS_LS_PPA_FW_ADDR,
> > +_header_len, (u_char *));
> > + if (ret == -EUCLEAN) {
> > + printf("NAND read of PPA FIT header at offset 0x%x failed\n",
> > +CONFIG_SYS_LS_PPA_FW_ADDR);
> > + return -EIO;
> > + }
> > +
> > + fw_length = fdt_totalsize();
> > +
> > + ppa_fit_addr = malloc(fw_length);
> > + if (!ppa_fit_addr) {
> > + printf("PPA: malloc failed for PPA image(size 0x%zx)\n",
> > +fw_length);
> > + return -ENOMEM;
> > + }
> > +
> > + ret = nand_read(nand_info[0],
> (loff_t)CONFIG_SYS_LS_PPA_FW_ADDR,
> > +_length, (u_char *)ppa_fit_addr);
> > + if (ret == -EUCLEAN) {
> > + free(ppa_fit_addr);
> > + printf("NAND read of PPA firmware at offset 0x%x failed\n",
> > +CONFIG_SYS_LS_PPA_FW_ADDR);
> > + return -EIO;
> > + }
> >  #else
> >  #error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
> >  #endif
> >
>
> Why do you flush the cache after reading from SD but not from NAND?

Added the flush operation because I referred to the FMan ucode loading process.
It works well when loading from SD without the flush cache action, will remove 
the flush action.

Thanks,
Zhiqiang
___
U-Boot mailing list
U-Boot@lists.denx.de

Re: [U-Boot] [PATCH 2/2] cmd: nand: Make the NAND options default to NAND_SUNXI

[Chen-Yu Tsai]

On Fri, Mar 3, 2017 at 10:32 PM, Maxime Ripard
 wrote:
> If we depend on the ARCH_SUNXI configuration option, the boards that do not
> have NAND support enabled (with the associated options) will not compile
> anymore.
>
> Depend on the NAND driver configuration option to make sure that is not the
> case.
>
> Reported-by: Chen-Yu Tsai 
> Signed-off-by: Maxime Ripard 

Tested-by: Chen-Yu Tsai 

> ---
>  cmd/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 585a00c31f4e..91e3d6a46769 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -438,7 +438,7 @@ config CMD_MMC
>
>  config CMD_NAND
> bool "nand"
> -   default y if ARCH_SUNXI
> +   default y if NAND_SUNXI

It would be nicer if it were a stronger constraint though. The user can still
enable CMD_NAND (such as by using a config from before this patch was applied)
and still break the build. I understand that this is hard to achieve since each
platform does things a bit differently.

ChenYu

> help
>   NAND support.
>
> @@ -847,7 +847,7 @@ config CMD_UBI
> tristate "Enable UBI - Unsorted block images commands"
> select CRC32
> select MTD_UBI
> -   default y if ARCH_SUNXI
> +   default y if NAND_SUNXI
> help
>   UBI is a software layer above MTD layer which admits use of LVM-like
>   logical volumes on top of MTD devices, hides some complexities of
> @@ -862,7 +862,7 @@ config CMD_UBIFS
> select CRC32
> select RBTREE if ARCH_SUNXI
> select LZO if ARCH_SUNXI
> -   default y if ARCH_SUNXI
> +   default y if NAND_SUNXI
> help
>   UBIFS is a file system for flash devices which works on top of UBI.
>
> --
> 2.11.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/5] fsl PPA: add support PPA image loading from NAND and SD

[Z.Q. Hou]

Hi York,

Thanks a lot for your comments!

> -Original Message-
> From: york sun
> Sent: Saturday, March 04, 2017 12:51 AM
> To: Z.Q. Hou ; u-boot@lists.denx.de;
> o...@buserror.net; mingkai...@freescale.com; s...@chromium.org; Xiaobo
> Xie 
> Subject: Re: [PATCH 3/5] fsl PPA: add support PPA image loading from NAND
> and SD
> 
> On 03/03/2017 05:45 AM, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Signed-off-by: Hou Zhiqiang 
> > ---
> >  arch/arm/cpu/armv8/fsl-layerscape/ppa.c | 118
> > +++-
> >  1 file changed, 117 insertions(+), 1 deletion(-)
> 
> 
> 
> >
> >  #ifdef CONFIG_SYS_LS_PPA_FW_IN_XIP
> > ppa_fit_addr = (void *)CONFIG_SYS_LS_PPA_FW_ADDR;
> > +   debug("%s: PPA image load from XIP\n", __func__); #else /*
> > +!CONFIG_SYS_LS_PPA_FW_IN_XIP */
> > +   size_t fw_length, fdt_header_len = sizeof(struct fdt_header);
> > +
> > +   /* Copy PPA image from MMC/SD/NAND to allocated memory */
> #ifdef
> > +CONFIG_SYS_LS_PPA_FW_IN_MMC
> > +   struct mmc *mmc;
> > +   int dev = CONFIG_SYS_MMC_ENV_DEV;
> > +   struct fdt_header *fitp;
> > +   u32 cnt;
> > +   u32 blk = CONFIG_SYS_LS_PPA_FW_ADDR / 512;
> > +
> > +   debug("%s: PPA image load from eMMC/SD\n", __func__);
> > +
> > +   mmc_initialize(gd->bd);
> > +   mmc = find_mmc_device(dev);
> > +   if (!mmc) {
> > +   printf("PPA: MMC cannot find device for PPA firmware\n");
> > +   return -ENODEV;
> > +   }
> > +
> > +   mmc_init(mmc);
> > +
> > +   fitp = malloc(roundup(fdt_header_len, 512));
> > +   if (!fitp) {
> > +   printf("PPA: malloc failed for FIT header(size 0x%zx)\n",
> > +  roundup(fdt_header_len, 512));
> > +   return -ENOMEM;
> > +   }
> > +
> > +   cnt = DIV_ROUND_UP(fdt_header_len, 512);
> > +   debug("%s: MMC read PPA FIT header: dev # %u, block # %u,
> count %u\n",
> > + __func__, dev, blk, cnt);
> > +   ret = mmc->block_dev.block_read(>block_dev, blk, cnt, fitp);
> > +   if (ret != cnt) {
> > +   free(fitp);
> > +   printf("MMC/SD read of PPA FIT header at offset 0x%x
> failed\n",
> > +  CONFIG_SYS_LS_PPA_FW_ADDR);
> > +   return -EIO;
> > +   }
> > +
> > +   /* flush cache after read */
> > +   flush_cache((ulong)fitp, cnt * 512);
> > +
> > +   fw_length = fdt_totalsize(fitp);
> > +   free(fitp);
> > +
> > +   fw_length = roundup(fw_length, 512);
> > +   ppa_fit_addr = malloc(fw_length);
> > +   if (!ppa_fit_addr) {
> > +   printf("PPA: malloc failed for PPA image(size 0x%zx)\n",
> > +  fw_length);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   cnt = DIV_ROUND_UP(fw_length, 512);
> > +   debug("%s: MMC read PPA FIT image: dev # %u, block # %u,
> count %u\n",
> > + __func__, dev, blk, cnt);
> > +   ret = mmc->block_dev.block_read(>block_dev,
> > +   blk, cnt, ppa_fit_addr);
> > +   if (ret != cnt) {
> > +   free(ppa_fit_addr);
> > +   printf("MMC/SD read of PPA FIT header at offset 0x%x
> failed\n",
> > +  CONFIG_SYS_LS_PPA_FW_ADDR);
> > +   return -EIO;
> > +   }
> > +
> > +   flush_cache((ulong)ppa_fit_addr, cnt * 512);
> > +
> > +#elif CONFIG_SYS_LS_PPA_FW_IN_NAND
> > +   struct fdt_header fit;
> > +
> > +   debug("%s: PPA image load from NAND\n", __func__);
> > +
> > +   nand_init();
> > +   ret = nand_read(nand_info[0],
> (loff_t)CONFIG_SYS_LS_PPA_FW_ADDR,
> > +  _header_len, (u_char *));
> > +   if (ret == -EUCLEAN) {
> > +   printf("NAND read of PPA FIT header at offset 0x%x failed\n",
> > +  CONFIG_SYS_LS_PPA_FW_ADDR);
> > +   return -EIO;
> > +   }
> > +
> > +   fw_length = fdt_totalsize();
> > +
> > +   ppa_fit_addr = malloc(fw_length);
> > +   if (!ppa_fit_addr) {
> > +   printf("PPA: malloc failed for PPA image(size 0x%zx)\n",
> > +  fw_length);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   ret = nand_read(nand_info[0],
> (loff_t)CONFIG_SYS_LS_PPA_FW_ADDR,
> > +  _length, (u_char *)ppa_fit_addr);
> > +   if (ret == -EUCLEAN) {
> > +   free(ppa_fit_addr);
> > +   printf("NAND read of PPA firmware at offset 0x%x failed\n",
> > +  CONFIG_SYS_LS_PPA_FW_ADDR);
> > +   return -EIO;
> > +   }
> >  #else
> >  #error "No CONFIG_SYS_LS_PPA_FW_IN_xxx defined"
> >  #endif
> >
> 
> Why do you flush the cache after reading from SD but not from NAND?

Added the flush operation because I referred to the FMan ucode loading process.
It works well when loading from SD without the flush cache action, will remove 
the flush action.

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

Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

[Dalon Westergreen]

On Sun, 2017-03-05 at 18:49 +0100, Marek Vasut wrote:
> On 03/05/2017 06:38 PM, Dalon Westergreen wrote:
> > 
> > On Tue, 2017-02-28 at 06:45 -0800, Dalon Westergreen wrote:
> > > 
> > > On Mon, 2017-02-20 at 06:35 -0800, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 02/20/2017 03:21 PM, Dalon Westergreen wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > > > > > > > configuration for the device.  This can lead to a boot
> > > > > > > > > > failure
> > > > > > > > > > on warm resets. This patch disables warm resets when CSEL=0.
> > > > > > > > > > This results in the clock and pll configurations being reset
> > > > > > > > > > on any reset issued when CSEL=0.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Dalon Westergreen 
> > > > > > > > > 
> > > > > > > > > What about my suggestion for V2 about just loading function
> > > > > > > > > pointer
> > > > > > > > > into
> > > > > > > > > the reset jump address register ?
> > > > > > > > 
> > > > > > > > Frankly, i really dont like relying on the existence of a
> > > > > > > > snippet of
> > > > > > > > code in
> > > > > > > > the
> > > > > > > > onchip ram being untouched to ensure a reboot/reset will occur
> > > > > > > > for
> > > > > > > > this
> > > > > > > > csel=0
> > > > > > > > case.  i am certain this case is rarely used, and confident that
> > > > > > > > it
> > > > > > > > isnt
> > > > > > > > being
> > > > > > > > used while trying to preserve sdram contents.
> > > > > > > 
> > > > > > > Well, you already rely on such snippet, it's SPL. If you corrupt
> > > > > > > SPL
> > > > > > > and
> > > > > > > do warm reset, your system hangs, I had that multiple times :)
> > > > > > 
> > > > > > True.  I would argue to just use cold resets but i think arria 10
> > > > > > has
> > > > > > more
> > > > > > use
> > > > > > for the warm reset case.
> > > > > 
> > > > > OK
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > the downside is that the scorecard is reset every boot. so the
> > > > > > > > bootrom
> > > > > > > > will
> > > > > > > > retry all the spl images again resulting in possibly longer boot
> > > > > > > > times.
> > > > > > > 
> > > > > > > Is that significant ?
> > > > > > 
> > > > > > The watchdog timeout is on the order of 1.5 seconds.  That would be
> > > > > > for
> > > > > > each
> > > > > > failed spl.
> > > > > 
> > > > > Hm, OK. But then your system is kinda broken, so you should expect
> > > > > this
> > > > > I guess.
> > > > 
> > > > My thought exactly...  I would like to see if Chin Liang or Dinh have
> > > > any
> > > > comments?
> > > 
> > > Chin Liang, Dinh, any comments?
> > 
> > Marek, I would like to propose we move forward with this patch?
> 
> TBH I'm still thinking if you turned the V2 into C code and passed a 
> function pointer into the warm reset jump address register, that'd be 
> the best.
> 
I will give it a shot, i just dont like relying on the spl image still
being present in the onchip ram.  There is nothing preventing an errant
process or user from overwriting it and i have run into customers using
that memory for their own purposes.

-dalon

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

Re: [U-Boot] BeagleBoard B7 (OMAP3530) fails to boot with the current U-Boot master branch

[Siarhei Siamashka]

On Sun, 5 Mar 2017 09:27:44 -0500
Tom Rini  wrote:

> On Sun, Mar 05, 2017 at 02:51:54PM +0200, Siarhei Siamashka wrote:
> > Hello All,
> > 
> > I have just unexpectedly found an old Beagleboard B7 in my closet and
> > tried to compile the current U-Boot master branch for it. Appears that
> > it is broken since almost 2 years ago:
> > 
> >https://lists.denx.de/pipermail/u-boot/2015-July/220332.html
> >https://lists.denx.de/pipermail/u-boot/2016-May/253777.html
> > 
> > And after trying to narrow it down, looks like the failure happens in
> > the prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c' when
> > it is compiled as Thumb2. At least the SPL can successfully boot after
> > the following change (GCC6 is needed for this pragma):  
> 
> Good job sorting this out.  I think it might be best to just disable
> Thumb on beagleboard.

Well, apparently this "disabling Thumb" plan is not moving anywhere
in practice. The current situation is less than perfect and downstream
(Robert Nelson) is already disabling Thumb since a while ago together
with CONFIG_SPL_EXT_SUPPORT. And the mainline U-Boot keeps providing
releases, which are unusable for OMAP3530 out-of-the box.

Regarding Thumb2 support in general. Yes, the old r1p3 revision of
Cortex A8 in OMAP3530 is affected by multiple Thumb errata. But I
checked the errata list and seems like we don't have to worry
about 657417 (A 32bit branch instruction that spans two 4K regions
can result in an incorrect instruction fetch or processor deadlock)
after all because the bug affects processors with 32KiB of L1
I-Cache, while OMAP3530 only has 16 KiB. The other Thumb errata
might also have no real effect on U-Boot, because some of them
involve the use of MMU and virtual addresses. In the end, we are
applying them for the sake of the Linux kernel and userland software.

Yes, I still don't like how errata workarounds are handled by U-Boot.
This stuff looks way too complicated and frameworkish. I mean that we
get the v7_arch_cp15_set_l2aux_ctrl() and v7_arch_cp15_set_acr()
functions implemented in the C code, and they also do some elaborate
runtime detection of the SoC variant. These functions are compiled as
Thumb code, so we get quite a bit of Thumb interworking activity
happening even before we have a chance to apply some relevant
errata workarounds. But no matter how ugly this stuff is, it does
not seem to cause real problems in practice.

So I suspect that the prcm_init() function fails not because of Thumb
as such, but because recompiling it as Thumb probably changes the
timings of the initialization in a subtle way. Also I don't quite
like the code constructs like this:

/* M (CORE_DPLL_MULT): CM_CLKSEL1_PLL[16:26] */
clrsetbits_le32(_base->clksel1_pll,
0x07FF, ptr->m << 16);

/* N (CORE_DPLL_DIV): CM_CLKSEL1_PLL[8:14] */
clrsetbits_le32(_base->clksel1_pll,
0x7F00, ptr->n << 8);

Wouldn't it be more reasonable to change both M and N values as a
single atomic operation? Maybe it's a good idea to check the the
OMAP3530 errata list to see if there are any known quirks in the
DPLL setup sequence. But I would prefer to leave the further
investigation up to the TI people and local OMAP experts.

Either way, as a quick and dirty workaround, we currently can enable
ARM mode compilation for just a singe clock.c file instead of the
whole SPL. And this source file can be even split into parts if
we want better granularity.

I have sent some OMAP3530 patches to the list:
https://lists.denx.de/pipermail/u-boot/2017-March/283074.html

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] sunxi: DM-based CLK, RESET and PINCTRL

[André Przywara]

On 01/03/17 21:19, Philipp Tomsich wrote:
> Hi everyone,
> 
> here's the the new version of CLK, RESET and PINCTRL drivers to
> configure sunxi from the device-tree.  This adds support for the
> upstream CCU node (for reset and pinctrl) and tries to address the
> various concerns people had.
> 
> Note that (to stay in sync with the Linux files), some of the
> patches may not fully adhere to the style (e.g. some of the code
> reused verbatim from Linux and in the config tables).
> 
> This has been tested with Ethernet, I2C, SPI and MMC on the A64-uQ7.
> See my separate patchsets for the conversion of these drivers over
> to support DM-based CLK, RESET and PINCTRL configuration.
> 
> Changes is v3:
>  * add support for the 'new-style' clock subsystem (CCU) by porting
>from Linux and adding the necessary glue implementation

Gah, is this really necessary? Do we really need to pull in the whole of
the complex Linux clock driver?
In the end all that U-Boot needs to do is to program a few simple
clocks, a task which it easily did so far with just some register
writes. I don't think it's appropriate for U-Boot to get the whole
complex clock driver from Linux for just that purpose.
One indication of this being too much is that the mailing list seemed to
have blocked patch 8/9, probably because it's too big ;-)
I am especially scared when it comes to adding all of the other SoC's
clock drivers to the code base as well.

So can't we do a much simpler (because limited) implementation?
If a peripheral driver gets the clock index from the DT and asks the
clock driver to program (or just enable) clock "75", can't we just have
a simple function which redirects this clock number to our already
existing code?
Something like (rough sketch):
int sun50i_clk_set_freq(int nr, int freq)
{
int idx;

switch (nr) {
case CLK_MMC0 ... CLK_MMC2:
idx = nr - CLK_MMC0;
return mmc_set_mod_clk(idx,
   clkreg_addr[MMC_CLK + idx],
   freq);
}
}
... with mmc_set_mod_clk() being a slightly changed version of the
existing implementation?

I think that would seriously reduce the bloat and be a better fit for
U-Boot. And it might even allow the SPL to reuse this by just calling
into the dispatch function with hardcoded parameters.

Cheers,
Andre.

>- add a CCU reset-driver (in addition to the legacy driver, which
>  will still be required for the R_* device nodes), which reuses
>  the reset-table from ccu-.c
>- add a clk-sunxi-ccu.c implementation based on Linux and reusing
>  both the low-level clock implementation (ccu_*.h) and the config
>  table (ccu-.c) from Linux
>  * reuse the 'allwinner,pinctrl.txt' documentation for the pinctrl
>binding from Linux
>  * adds the includes for the CCU dt-bindings from Linux
>  * adds support for printing the CCU subsystem via 'clk dump'
> 
> 
> Philipp Tomsich (9):
>   sunxi: add pinctrl (UCLASS_PINCTRL) support for sunxi
>   dm: core: Allow multiple drivers to bind for a single node
>   sunxi: CONFIG_DM_ALLOW_MULTIPLE_DRIVERS for gpio/pinctrl binding
>   Kconfig: sunxi: Select new option for allow multiple drivers to bind
>   sunxi: add module reset (UCLASS_RESET) support for sunxi
>   linux/kernel.h: sync DIV_ROUND_UP_ULL from kernel
>   clk: clk-uclass: add clk_get_by_output_name
>   sunxi: add clock driver (UCLASS_CLK) support for sunxi
>   cmd: move CONFIG_CMD_CLK to Kconfig
> 
>  arch/arm/Kconfig   |   1 +
>  arch/arm/include/asm/arch-sunxi/gpio-internal.h|  19 +
>  cmd/Kconfig|  10 +
>  .../pinctrl/allwinner,pinctrl.txt  | 142 
>  drivers/clk/Makefile   |   1 +
>  drivers/clk/clk-uclass.c   |  30 +
>  drivers/clk/sunxi/Makefile |  30 +
>  drivers/clk/sunxi/ccu-compatibility.h  | 232 ++
>  drivers/clk/sunxi/ccu-runtime-divider.c| 115 +++
>  drivers/clk/sunxi/ccu-runtime-fixedfactor.c|  17 +
>  drivers/clk/sunxi/ccu-sun50i-a64.c | 810 
> +
>  drivers/clk/sunxi/ccu-sun50i-a64.h |  64 ++
>  drivers/clk/sunxi/ccu_common.c |  27 +
>  drivers/clk/sunxi/ccu_common.h |  67 ++
>  drivers/clk/sunxi/ccu_div.c| 134 
>  drivers/clk/sunxi/ccu_div.h| 170 +
>  drivers/clk/sunxi/ccu_frac.c   | 106 +++
>  drivers/clk/sunxi/ccu_frac.h   |  46 ++
>  drivers/clk/sunxi/ccu_gate.c   |  80 ++
>  drivers/clk/sunxi/ccu_gate.h   |  45 ++
>  drivers/clk/sunxi/ccu_mp.c | 159 
>  drivers/clk/sunxi/ccu_mp.h |  70 ++
>  drivers/clk/sunxi/ccu_mult.h   |  39 +
>  

[U-Boot] [PATCH 2/2] arm: omap3: Bring back ARM errata workaround 725233

[Siarhei Siamashka]

The workaround for ARM errata 725233 had been lost since
commit 45bf05854bc94e (armv7: adapt omap3 to the new cache
maintenance framework). Bring it back in order to avoid
very difficult to reproduce, but actually encountered in
the wild CPU deadlocks when running software rendered
X11 desktop on OMAP3530 hardware.

This patch adds the new errata define to the whitelist instead
of introducing a new Kconfig option. It's probably best to
convert all ARM errata to Kconfig in one go via a separate
patch.

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/cpu/armv7/start.S | 13 +
 arch/arm/include/asm/arch-omap3/omap.h |  1 +
 arch/arm/mach-omap2/omap3/board.c  | 10 ++
 include/configs/ti_omap3_common.h  |  1 +
 scripts/config_whitelist.txt   |  1 +
 5 files changed, 26 insertions(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 7eee54b..1a6aee9 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -270,6 +270,19 @@ skip_errata_430973:
 skip_errata_621766:
 #endif
 
+#ifdef CONFIG_ARM_ERRATA_725233
+   cmp r2, #0x21   @ Only on < r2p1 (Cortex A8)
+   bge skip_errata_725233
+
+   mrc p15, 1, r0, c9, c0, 2   @ Read L2ACR
+   orr r0, r0, #(0x1 << 27)@ L2 PLD data forwarding disable
+   push{r1-r5} @ Save the cpu info registers
+   bl  v7_arch_cp15_set_l2aux_ctrl
+   pop {r1-r5} @ Restore the cpu info - fall through
+
+skip_errata_725233:
+#endif
+
mov pc, r5  @ back to my caller
 ENDPROC(cpu_init_cp15)
 
diff --git a/arch/arm/include/asm/arch-omap3/omap.h 
b/arch/arm/include/asm/arch-omap3/omap.h
index 91d73c2..db763e4 100644
--- a/arch/arm/include/asm/arch-omap3/omap.h
+++ b/arch/arm/include/asm/arch-omap3/omap.h
@@ -243,6 +243,7 @@ struct gpio {
  * ROM code API related flags
  */
 #define OMAP3_GP_ROMCODE_API_L2_INVAL  1
+#define OMAP3_GP_ROMCODE_API_WRITE_L2ACR   2
 #define OMAP3_GP_ROMCODE_API_WRITE_ACR 3
 
 /*
diff --git a/arch/arm/mach-omap2/omap3/board.c 
b/arch/arm/mach-omap2/omap3/board.c
index 5f55977..cc83cd7 100644
--- a/arch/arm/mach-omap2/omap3/board.c
+++ b/arch/arm/mach-omap2/omap3/board.c
@@ -368,6 +368,16 @@ void __weak omap3_set_aux_cr_secure(u32 acr)
   (u32 *)_romcode_params);
 }
 
+void v7_arch_cp15_set_l2aux_ctrl(u32 l2auxctrl, u32 cpu_midr,
+u32 cpu_rev_comb, u32 cpu_variant,
+u32 cpu_rev)
+{
+   if (get_device_type() == GP_DEVICE)
+   omap_smc1(OMAP3_GP_ROMCODE_API_WRITE_L2ACR, l2auxctrl);
+
+   /* L2 Cache Auxiliary Control Register is not banked */
+}
+
 void v7_arch_cp15_set_acr(u32 acr, u32 cpu_midr, u32 cpu_rev_comb,
  u32 cpu_variant, u32 cpu_rev)
 {
diff --git a/include/configs/ti_omap3_common.h 
b/include/configs/ti_omap3_common.h
index 0ad3235..cbd6f98 100644
--- a/include/configs/ti_omap3_common.h
+++ b/include/configs/ti_omap3_common.h
@@ -25,6 +25,7 @@
 #define CONFIG_ARM_ERRATA_454179
 #define CONFIG_ARM_ERRATA_430973
 #define CONFIG_ARM_ERRATA_621766
+#define CONFIG_ARM_ERRATA_725233
 
 /* The chip has SDRC controller */
 #define CONFIG_SDRC
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index f6c9101..bb5387d 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -145,6 +145,7 @@ CONFIG_ARM_ERRATA_430973
 CONFIG_ARM_ERRATA_454179
 CONFIG_ARM_ERRATA_621766
 CONFIG_ARM_ERRATA_716044
+CONFIG_ARM_ERRATA_725233
 CONFIG_ARM_ERRATA_742230
 CONFIG_ARM_ERRATA_743622
 CONFIG_ARM_ERRATA_751472
-- 
2.7.3

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

[U-Boot] [PATCH 1/2] arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530

[Siarhei Siamashka]

Boards with OMAP3530 SoC fail to boot since commit bd2c4522c26d5
("ti: armv7: enable EXT support in SPL (using ti_armv7_common.h)")
because it enabled the use of Thumb2 for the SPL.

Experiments have shown that the deadlock happens in the
prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c'.

This patch enforces the compilation of clock.c source file in
ARM mode and makes the deadlock disappear. We are yet to figure
out the root cause of the problem. Still this is somewhat
better than having non-bootable boards for years.

Signed-off-by: Siarhei Siamashka 
---
 arch/arm/mach-omap2/omap3/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-omap2/omap3/Makefile 
b/arch/arm/mach-omap2/omap3/Makefile
index b2fce96..06cc9f2 100644
--- a/arch/arm/mach-omap2/omap3/Makefile
+++ b/arch/arm/mach-omap2/omap3/Makefile
@@ -5,6 +5,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
+# If clock.c is compiled for Thumb2, then it fails on OMAP3530
+CFLAGS_clock.o += -marm
+
 obj-y  := lowlevel_init.o
 
 obj-y  += board.o
-- 
2.7.3

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

[U-Boot] [PATCH 0/2] Unbreak OMAP3530

[Siarhei Siamashka]

OMAP3530 lost the erratum 725233 workaround since 2011 and even
became completely non-bootable since 2015. These two patches make
it usable again. The most notable hardware is the original
BeagleBoard.

Siarhei Siamashka (2):
  arm: omap3: Compile clock.c with -marm option to unbreak OMAP3530
  arm: omap3: Bring back ARM errata workaround 725233

 arch/arm/cpu/armv7/start.S | 13 +
 arch/arm/include/asm/arch-omap3/omap.h |  1 +
 arch/arm/mach-omap2/omap3/Makefile |  3 +++
 arch/arm/mach-omap2/omap3/board.c  | 10 ++
 include/configs/ti_omap3_common.h  |  1 +
 scripts/config_whitelist.txt   |  1 +
 6 files changed, 29 insertions(+)

-- 
2.7.3

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

[U-Boot] [PATCH] video: cfb_console: fix 32-bit display on 64-bit architectures

[Andre Przywara]

"unsigned long" is a lousy data type when it comes to match peripheral
hardware registers with a fixed size.
Just do the obvious and match a 32-bit display format with an "u32"
data type for casting.
This fixes the logo display on 64-bit architectures, which produced
a black line on the right side of the logo with non-black backgrounds.

Signed-off-by: Andre Przywara 
---
 drivers/video/cfb_console.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 3c0696e..d75abb6 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1079,8 +1079,8 @@ __weak void video_set_lut(unsigned int index, unsigned 
char r,
 }
 
 #define FILL_32BIT_X888RGB(r,g,b) {\
-   *(unsigned long *)fb =  \
-   SWAP32((unsigned long)(((r<<16) |   \
+   *(u32 *)fb =\
+   SWAP32((unsigned int)(((r<<16) |\
(g<<8)  |   \
 b)));  \
fb += 4;\
@@ -1161,7 +1161,7 @@ static void draw_bitmap(uchar **fb, uchar *bm, struct 
palette *p,
break;
case GDF_32BIT_X888RGB:
for (i = 0; i < cnt; i++) {
-   *(unsigned long *) addr = p[bm[*off]].ce.dw;
+   *(u32 *) addr = p[bm[*off]].ce.dw;
addr += 4;
}
break;
@@ -1825,8 +1825,8 @@ static void plot_logo_or_black(void *screen, int x, int 
y, int black)
 (b >> 3)));
break;
case GDF_32BIT_X888RGB:
-   *(unsigned long *) dest =
-   SWAP32((unsigned long) (
+   *(u32 *) dest =
+   SWAP32((u32) (
(r << 16) |
(g <<  8) |
 b));
-- 
2.8.2

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

Re: [U-Boot] [PATCH 2/5] am335x_evm: Switch to using imply keyword

[Tom Rini]

On Sun, Mar 05, 2017 at 11:53:43PM +0100, Lukasz Majewski wrote:
> Hi Tom,
> 
> > These particular SPL options are part of what the ROM provides, but
> > for compatibility with how we have previously used them, move them to
> > being implied by the board being selected.
> > 
> > Signed-off-by: Tom Rini 
> > ---
> >  arch/arm/mach-omap2/am33xx/Kconfig | 3 +++
> >  board/ti/am335x/Kconfig| 9 -
> >  2 files changed, 3 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm/mach-omap2/am33xx/Kconfig
> > b/arch/arm/mach-omap2/am33xx/Kconfig index 5b5d3f8cec29..5adcead185de
> > 100644 --- a/arch/arm/mach-omap2/am33xx/Kconfig
> > +++ b/arch/arm/mach-omap2/am33xx/Kconfig
> > @@ -15,6 +15,9 @@ config TARGET_AM335X_EVM
> > select DM_SERIAL
> > select DM_GPIO
> > select TI_I2C_BOARD_DETECT
> > +   imply SPL_YMODEM_SUPPORT
> > +   imply SPL_ENV_SUPPORT
> > +   imply SPL_WATCHDOG_SUPPORT
> 
> Are you sure that WDT is enabled by ROM by default?

OK, good point, my wording was slightly unclear.  What I meant was that
these are SPL-usable features that are part of the SoC, rather than
something board-centric.  That said, yes, a quick re-read of the
initialization section of the AM335x TRM says that ROM sets up WDT1,
which matches up with my recollections from TI days and board bring up.
It's likely this should become a 'select' as if we don't twiddle it in
time, we will trigger it.

> IIRC we must enable it explicitly in the SPL.

We can reconfigure it to be more "precise" perhaps is the answer.  I
have a recollection of a bring up issue where in the problem was "Oh, we
got somewhat far, but hadn't touched the WDT and reset".

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] am335x_evm: Switch to using imply keyword

[Lukasz Majewski]

Hi Tom,

> These particular SPL options are part of what the ROM provides, but
> for compatibility with how we have previously used them, move them to
> being implied by the board being selected.
> 
> Signed-off-by: Tom Rini 
> ---
>  arch/arm/mach-omap2/am33xx/Kconfig | 3 +++
>  board/ti/am335x/Kconfig| 9 -
>  2 files changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/am33xx/Kconfig
> b/arch/arm/mach-omap2/am33xx/Kconfig index 5b5d3f8cec29..5adcead185de
> 100644 --- a/arch/arm/mach-omap2/am33xx/Kconfig
> +++ b/arch/arm/mach-omap2/am33xx/Kconfig
> @@ -15,6 +15,9 @@ config TARGET_AM335X_EVM
>   select DM_SERIAL
>   select DM_GPIO
>   select TI_I2C_BOARD_DETECT
> + imply SPL_YMODEM_SUPPORT
> + imply SPL_ENV_SUPPORT
> + imply SPL_WATCHDOG_SUPPORT

Are you sure that WDT is enabled by ROM by default?

IIRC we must enable it explicitly in the SPL.

>   help
> This option specifies support for the AM335x
> GP and HS EVM development platforms. The AM335x
> diff --git a/board/ti/am335x/Kconfig b/board/ti/am335x/Kconfig
> index a84e91b3dc56..97374bdc12ae 100644
> --- a/board/ti/am335x/Kconfig
> +++ b/board/ti/am335x/Kconfig
> @@ -1,14 +1,5 @@
>  if TARGET_AM335X_EVM
>  
> -config SPL_ENV_SUPPORT
> - default y
> -
> -config SPL_WATCHDOG_SUPPORT
> - default y
> -
> -config SPL_YMODEM_SUPPORT
> - default y
> -
>  config SYS_BOARD
>   default "am335x"
>  




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v1 1/2] misc: Add SCU IPC driver for Intel MID platforms

[Andy Shevchenko]

From: Felipe Balbi 

Intel MID platforms have few microcontrollers inside SoC, one of them is
so called System Controller Unit (SCU).

Here is the driver to communicate with microcontroller.

Signed-off-by: Vincent Tinelli 
Signed-off-by: Felipe Balbi 
Signed-off-by: Andy Shevchenko 
---
 arch/x86/Kconfig |   1 +
 drivers/misc/Kconfig |   6 ++
 drivers/misc/Makefile|   1 +
 drivers/misc/intel_scu_ipc.c | 199 +++
 include/intel_scu_ipc.h  |  57 +
 5 files changed, 264 insertions(+)
 create mode 100644 drivers/misc/intel_scu_ipc.c
 create mode 100644 include/intel_scu_ipc.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dfdd7564ea..6a747c332e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -83,6 +83,7 @@ endchoice
 # subarchitectures-specific options below
 config INTEL_MID
bool "Intel MID platform support"
+   select INTEL_SCU
help
  Select to build a U-Boot capable of supporting Intel MID
  (Mobile Internet Device) platform systems which do not have
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 1aae4bcd07..8d81f9c51c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -167,4 +167,10 @@ config I2C_EEPROM
depends on MISC
help
  Enable a generic driver for EEPROMs attached via I2C.
+
+config INTEL_SCU
+   bool "Enable support for SCU on Intel MID platforms"
+   depends on INTEL_MID
+   default y
+
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e3151ea097..47551e44d6 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -51,3 +51,4 @@ obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
 obj-$(CONFIG_FSL_DEVICE_DISABLE) += fsl_devdis.o
 obj-$(CONFIG_WINBOND_W83627) += winbond_w83627.o
 obj-$(CONFIG_QFW) += qfw.o
+obj-$(CONFIG_INTEL_SCU) += intel_scu_ipc.o
diff --git a/drivers/misc/intel_scu_ipc.c b/drivers/misc/intel_scu_ipc.c
new file mode 100644
index 00..19a99b0b68
--- /dev/null
+++ b/drivers/misc/intel_scu_ipc.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IPC_STATUS_ADDR 0x04
+#define IPC_SPTR_ADDR   0x08
+#define IPC_DPTR_ADDR   0x0C
+#define IPC_READ_BUFFER 0x90
+#define IPC_WRITE_BUFFER0x80
+#define IPC_IOCBIT(8)
+
+struct intel_scu {
+   void __iomem *base;
+};
+
+/* Only one for now */
+static struct intel_scu *the_scu;
+
+static void scu_writel(void __iomem *base, unsigned int offset, unsigned int 
val)
+{
+   writel(val, base + offset);
+}
+
+static unsigned int scu_readl(void __iomem *base, unsigned int offset)
+{
+   return readl(base + offset);
+}
+
+/*
+ * Command Register (Write Only):
+ * A write to this register results in an interrupt to the SCU core processor
+ * Format:
+ * |rfu2(8) | size(8) | command id(4) | rfu1(3) | ioc(1) | command(8)|
+ */
+static void intel_scu_ipc_send_command(struct intel_scu *scu, u32 cmd)
+{
+   scu_writel(scu->base, 0x00, cmd | IPC_IOC);
+}
+
+/*
+ * IPC Write Buffer (Write Only):
+ * 16-byte buffer for sending data associated with IPC command to
+ * SCU. Size of the data is specified in the IPC_COMMAND_REG register
+ */
+static void ipc_data_writel(struct intel_scu *scu, u32 data, u32 offset)
+{
+   scu_writel(scu->base, IPC_WRITE_BUFFER + offset, data);
+}
+
+/*
+ * Status Register (Read Only):
+ * Driver will read this register to get the ready/busy status of the IPC
+ * block and error status of the IPC command that was just processed by SCU
+ * Format:
+ * |rfu3(8)|error code(8)|initiator id(8)|cmd id(4)|rfu1(2)|error(1)|busy(1)|
+ */
+static u32 ipc_read_status(struct intel_scu *scu)
+{
+   return scu_readl(scu->base, IPC_STATUS_ADDR);
+}
+
+static u32 ipc_data_readl(struct intel_scu *scu, u32 offset)
+{
+   return scu_readl(scu->base, IPC_READ_BUFFER + offset);
+}
+
+static int intel_scu_ipc_check_status(struct intel_scu *scu)
+{
+   int loop_count = 300;
+   int status;
+
+   do {
+   status = ipc_read_status(scu);
+   udelay(1);
+   } while ((status & BIT(0)) && --loop_count);
+   if (!loop_count)
+   return -ETIMEDOUT;
+
+   if (status & BIT(1)) {
+   printf("%s() status=0x%08x\n", __func__, status);
+   return -EIO;
+   }
+
+   return 0;
+}
+
+static int intel_scu_ipc_raw_cmd(struct intel_scu *scu, u32 cmd, u32 sub,
+u8 *in, u8 inlen, u32 *out, u32 outlen,
+u32 dptr, u32 sptr)
+{
+   int i, err;
+   u32 wbuf[4];
+
+   if (inlen > 16)
+   return 

[U-Boot] [PATCH v1 2/2] misc: Introduce minimal PMU driver for Intel MID platforms

[Andy Shevchenko]

This simple PMU driver enables access to MMC controllers during probe
so tangier_sdhci can probe and be useful.

In the future it might be expanded to cover other Intel MID platforms,
that's why it's called intel_mid_pmu.c.

Signed-off-by: Felipe Balbi 
Signed-off-by: Andy Shevchenko 
---
 arch/x86/Kconfig |   2 +
 drivers/misc/Kconfig |   6 +++
 drivers/misc/Makefile|   1 +
 drivers/misc/intel_mid_pmu.c | 124 +++
 4 files changed, 133 insertions(+)
 create mode 100644 drivers/misc/intel_mid_pmu.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6a747c332e..04310653bb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -83,7 +83,9 @@ endchoice
 # subarchitectures-specific options below
 config INTEL_MID
bool "Intel MID platform support"
+   select MISC
select INTEL_SCU
+   select INTEL_MID_PMU
help
  Select to build a U-Boot capable of supporting Intel MID
  (Mobile Internet Device) platform systems which do not have
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 8d81f9c51c..0222a8beed 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -168,6 +168,12 @@ config I2C_EEPROM
help
  Enable a generic driver for EEPROMs attached via I2C.
 
+config INTEL_MID_PMU
+   bool "Support for PMU on Intel MID platforms"
+   depends on MISC
+   depends on INTEL_MID
+   default y
+
 config INTEL_SCU
bool "Enable support for SCU on Intel MID platforms"
depends on INTEL_MID
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 47551e44d6..98a58f241c 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -51,4 +51,5 @@ obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
 obj-$(CONFIG_FSL_DEVICE_DISABLE) += fsl_devdis.o
 obj-$(CONFIG_WINBOND_W83627) += winbond_w83627.o
 obj-$(CONFIG_QFW) += qfw.o
+obj-$(CONFIG_INTEL_MID_PMU) += intel_mid_pmu.o
 obj-$(CONFIG_INTEL_SCU) += intel_scu_ipc.o
diff --git a/drivers/misc/intel_mid_pmu.c b/drivers/misc/intel_mid_pmu.c
new file mode 100644
index 00..0eda3b4349
--- /dev/null
+++ b/drivers/misc/intel_mid_pmu.c
@@ -0,0 +1,124 @@
+/*
+ * Copyright (c) 2017 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Registers */
+#define PM_STS 0x00
+#define PM_CMD 0x04
+#define PM_ICS 0x08
+#define PM_WKC(x)  (0x10 + (x) * 4)
+#define PM_WKS(x)  (0x18 + (x) * 4)
+#define PM_SSC(x)  (0x20 + (x) * 4)
+#define PM_SSS(x)  (0x30 + (x) * 4)
+
+/* Bits in PM_STS */
+#define PM_STS_BUSY(1 << 8)
+
+/* List of Intel Tangier LSSs */
+#define PMU_LSS_TANGIER_SDIO0_01   1
+
+struct pmu_mid {
+   void __iomem *ioaddr;
+};
+
+static unsigned int pmu_readl(void __iomem *base, unsigned int offset)
+{
+   return readl(base + offset);
+}
+
+static void pmu_writel(void __iomem *base, unsigned int offset,
+   unsigned int value)
+{
+   writel(value, base + offset);
+}
+
+static int pmu_read_status(struct pmu_mid *pmu)
+{
+   int retry = 50;
+   u32 reg;
+
+   do {
+   reg = pmu_readl(pmu->ioaddr, PM_STS);
+   if (!(reg & PM_STS_BUSY))
+   return 0;
+
+   udelay(1);
+   } while (--retry);
+
+   printf("WARNING: PMU still busy\n");
+   return -EBUSY;
+}
+
+static int pmu_enable_mmc(struct pmu_mid *pmu)
+{
+   u32 pm_ssc0;
+   int ret;
+
+   /* Check PMU status */
+   ret = pmu_read_status(pmu);
+   if (ret)
+   return ret;
+
+   /* Read PMU values */
+   pm_ssc0 = pmu_readl(pmu->ioaddr, PM_SSS(0));
+
+   /* Modify PMU values */
+
+   /* Enable SDIO0, sdhci for SD card */
+   pm_ssc0 &= ~(0x3 << (PMU_LSS_TANGIER_SDIO0_01 * 2));
+
+   /* Write modified PMU values */
+   pmu_writel(pmu->ioaddr, PM_SSC(0), pm_ssc0);
+
+   /* Update modified PMU values */
+   pmu_writel(pmu->ioaddr, PM_CMD, 0x2201);
+
+   /* Check PMU status */
+   return pmu_read_status(pmu);
+}
+
+static int pmu_mid_bind(struct udevice *dev)
+{
+   /* This device is needed straight away */
+   return device_probe(dev);
+}
+
+static int pmu_mid_probe(struct udevice *dev)
+{
+   struct pmu_mid  *pmu = dev_get_uclass_priv(dev);
+   fdt_addr_t  base;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   pmu->ioaddr = devm_ioremap(dev, base, SZ_1K);
+   if (!pmu->ioaddr)
+   return -ENOMEM;
+
+   return pmu_enable_mmc(pmu);
+}
+
+static const struct udevice_id pmu_mid_match[] = {
+   { .compatible = "intel,pmu-mid" },
+   { .compatible = "intel,pmu-tangier" },
+   { /* sentinel 

Re: [U-Boot] [PATCH 1/2] arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC

[Frank Kunz]

Am 05.03.2017 um 18:36 schrieb Dalon Westergreen:
> On Sun, 2017-03-05 at 18:16 +0100, Marek Vasut wrote:
>> On 03/05/2017 01:54 PM, Frank Kunz wrote:
>>>
>>> This allows the SPL to scan the MMC for a valid uboot image on a second
>>> sector location defined by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when
>>> the default location "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + first
>>> partition offset" does not contain a valid uboot image.
>>>
>>> Signed-off-by: Frank Kunz 
>>> ---
>>> :100644 100644 dd5933d43c... bd3e83ddea... Minclude/configs/socfpga_
>>> de0_nano_soc.h
>>>  include/configs/socfpga_de0_nano_soc.h | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/include/configs/socfpga_de0_nano_soc.h
>>> b/include/configs/socfpga_de0_nano_soc.h
>>> index dd5933d43c..bd3e83ddea 100644
>>> --- a/include/configs/socfpga_de0_nano_soc.h
>>> +++ b/include/configs/socfpga_de0_nano_soc.h
>>> @@ -12,6 +12,8 @@
>>>  #define CONFIG_FAT_WRITE
>>>  #define CONFIG_HW_WATCHDOG
>>>
>>> +#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
>>> +
>>>  /* Memory configurations */
>>>  #define PHYS_SDRAM_1_SIZE  0x4000  /* 1GiB */
>>>
>>>
>> This looks like a horrid hack , didn't Dalon add support into U-Boot SPL 
>> to scan all partitions for the final u-boot image ?
> 
> I did.  The 0xA2 partition can be located on any partition number now.  I
> believe Frank places the SPL image at a 64KB offset from the start of the
> sdcard to skip the MBR/GPT.  But per our previous debate, it is not my
> favored implementation as it relies on the bootrom to load the SPL once.

I put the u-boot at 4x64kiB (sector 0x200) offset on the sdcard. With
CONFIG_SPL_ABORT_ON_RAW_IMAGE config enabled the spl scans first for the
configured partition in the partition table as implemented by Dalon, if
that fails it tries to find the u-boot at sector 0x200 (as configured by
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR). Without that config the spl
endless retries to find u-boot in the configured partition, which is not
there when using GPT.

> 
> Also, i mentioned before that i would like to hold off on this patch set and
> let Ley Foon et al finish the A10 stuff.
> 
> --dalon
> 
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH 2/2] arm: socfpga: Enable part command and EFI partition support for DE0-nano-SoC

[Frank Kunz]

Am 05.03.2017 um 18:17 schrieb Marek Vasut:
> On 03/05/2017 01:54 PM, Frank Kunz wrote:
>> Those features are used by distro boot with efi boot.
>>
>> Signed-off-by: Frank Kunz 
>> ---
>> :100644 100644 b122135690... c22b54b48d... M   
>> configs/socfpga_de0_nano_soc_defconfig
>>  configs/socfpga_de0_nano_soc_defconfig | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/configs/socfpga_de0_nano_soc_defconfig
>> b/configs/socfpga_de0_nano_soc_defconfig
>> index b122135690..c22b54b48d 100644
>> --- a/configs/socfpga_de0_nano_soc_defconfig
>> +++ b/configs/socfpga_de0_nano_soc_defconfig
>> @@ -4,11 +4,11 @@ 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_nano_soc.dtb"
>>  CONFIG_FIT=y
>>  CONFIG_SYS_CONSOLE_IS_IN_ENV=y
>>  CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
>>  CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
>> +CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb"
> 
> Is this move needed ? (no, it's not)

It is not needed, but "make savedefconfig" decided to do that. I do not
know how to overcome it.

> 
>>  CONFIG_VERSION_VARIABLE=y
>>  # CONFIG_DISPLAY_BOARDINFO is not set
>>  CONFIG_SPL=y
>> @@ -21,6 +21,7 @@ CONFIG_CMD_ASKENV=y
>>  CONFIG_CMD_GREPENV=y
>>  # CONFIG_CMD_FLASH is not set
>>  CONFIG_CMD_MMC=y
>> +CONFIG_CMD_PART=y
>>  CONFIG_CMD_SF=y
>>  CONFIG_CMD_SPI=y
>>  CONFIG_CMD_I2C=y
>> @@ -37,6 +38,8 @@ CONFIG_CMD_EXT4_WRITE=y
>>  CONFIG_CMD_FAT=y
>>  CONFIG_CMD_FS_GENERIC=y
>>  CONFIG_CMD_UBI=y
>> +CONFIG_EFI_PARTITION=y
>> +# CONFIG_SPL_EFI_PARTITION is not set
>>  CONFIG_SPL_DM=y
>>  CONFIG_DFU_MMC=y
>>  CONFIG_DM_GPIO=y
>> @@ -59,5 +62,3 @@ CONFIG_G_DNL_MANUFACTURER="terasic"
>>  CONFIG_G_DNL_VENDOR_NUM=0x0525
>>  CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
>>  CONFIG_USE_TINY_PRINTF=y
>> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE=y
>> -CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE=0xa2
> 
> +CC Dalon ...

Similar case here. "make savedefconfig" found that those two parameters
are already set by arch/arm/mach-socfpga/Kconfig and decided to remove
them here, I guess.

> 
>> \ No newline at end of file
>>
> 
> 

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

Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

[Marek Vasut]

On 03/05/2017 06:38 PM, Dalon Westergreen wrote:

On Tue, 2017-02-28 at 06:45 -0800, Dalon Westergreen wrote:

On Mon, 2017-02-20 at 06:35 -0800, Dalon Westergreen wrote:


On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote:



On 02/20/2017 03:21 PM, Dalon Westergreen wrote:




On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:




On 02/20/2017 03:10 PM, Dalon Westergreen wrote:





On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:





On 02/18/2017 02:34 AM, Dalon Westergreen wrote:






When CSEL=0x0 the socfpga bootrom does not touch the clock
configuration for the device.  This can lead to a boot failure
on warm resets. This patch disables warm resets when CSEL=0.
This results in the clock and pll configurations being reset
on any reset issued when CSEL=0.

Signed-off-by: Dalon Westergreen 


What about my suggestion for V2 about just loading function
pointer
into
the reset jump address register ?


Frankly, i really dont like relying on the existence of a snippet of
code in
the
onchip ram being untouched to ensure a reboot/reset will occur for
this
csel=0
case.  i am certain this case is rarely used, and confident that it
isnt
being
used while trying to preserve sdram contents.


Well, you already rely on such snippet, it's SPL. If you corrupt SPL
and
do warm reset, your system hangs, I had that multiple times :)


True.  I would argue to just use cold resets but i think arria 10 has
more
use
for the warm reset case.


OK














the downside is that the scorecard is reset every boot. so the
bootrom
will
retry all the spl images again resulting in possibly longer boot
times.


Is that significant ?


The watchdog timeout is on the order of 1.5 seconds.  That would be for
each
failed spl.


Hm, OK. But then your system is kinda broken, so you should expect this
I guess.


My thought exactly...  I would like to see if Chin Liang or Dinh have any
comments?


Chin Liang, Dinh, any comments?


Marek, I would like to propose we move forward with this patch?


TBH I'm still thinking if you turned the V2 into C code and passed a 
function pointer into the warm reset jump address register, that'd be 
the best.


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

Re: [U-Boot] [PATCH 1/2] arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC

[Marek Vasut]

On 03/05/2017 06:36 PM, Dalon Westergreen wrote:

On Sun, 2017-03-05 at 18:16 +0100, Marek Vasut wrote:

On 03/05/2017 01:54 PM, Frank Kunz wrote:


This allows the SPL to scan the MMC for a valid uboot image on a second
sector location defined by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when
the default location "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + first
partition offset" does not contain a valid uboot image.

Signed-off-by: Frank Kunz 
---
:100644 100644 dd5933d43c... bd3e83ddea... Minclude/configs/socfpga_
de0_nano_soc.h
 include/configs/socfpga_de0_nano_soc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/socfpga_de0_nano_soc.h
b/include/configs/socfpga_de0_nano_soc.h
index dd5933d43c..bd3e83ddea 100644
--- a/include/configs/socfpga_de0_nano_soc.h
+++ b/include/configs/socfpga_de0_nano_soc.h
@@ -12,6 +12,8 @@
 #define CONFIG_FAT_WRITE
 #define CONFIG_HW_WATCHDOG

+#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+
 /* Memory configurations */
 #define PHYS_SDRAM_1_SIZE  0x4000  /* 1GiB */



This looks like a horrid hack , didn't Dalon add support into U-Boot SPL
to scan all partitions for the final u-boot image ?


I did.  The 0xA2 partition can be located on any partition number now.  I
believe Frank places the SPL image at a 64KB offset from the start of the
sdcard to skip the MBR/GPT.  But per our previous debate, it is not my
favored implementation as it relies on the bootrom to load the SPL once.

Also, i mentioned before that i would like to hold off on this patch set and
let Ley Foon et al finish the A10 stuff.


OK, although I think the A10 will take a bit longer, so there's no point 
in blocking this simple(r) patchset ... just don't wind up in deadlock ...


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

Re: [U-Boot] [PATCH v3] arm: socfpga: fix issue with warm reset when CSEL is 0

[Dalon Westergreen]

On Tue, 2017-02-28 at 06:45 -0800, Dalon Westergreen wrote:
> On Mon, 2017-02-20 at 06:35 -0800, Dalon Westergreen wrote:
> > 
> > On Mon, 2017-02-20 at 15:24 +0100, Marek Vasut wrote:
> > > 
> > > 
> > > On 02/20/2017 03:21 PM, Dalon Westergreen wrote:
> > > > 
> > > > 
> > > > 
> > > > On Mon, 2017-02-20 at 15:14 +0100, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 02/20/2017 03:10 PM, Dalon Westergreen wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On Mon, 2017-02-20 at 10:07 +0100, Marek Vasut wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > On 02/18/2017 02:34 AM, Dalon Westergreen wrote:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > When CSEL=0x0 the socfpga bootrom does not touch the clock
> > > > > > > > configuration for the device.  This can lead to a boot failure
> > > > > > > > on warm resets. This patch disables warm resets when CSEL=0.
> > > > > > > > This results in the clock and pll configurations being reset
> > > > > > > > on any reset issued when CSEL=0.
> > > > > > > > 
> > > > > > > > Signed-off-by: Dalon Westergreen 
> > > > > > > 
> > > > > > > What about my suggestion for V2 about just loading function
> > > > > > > pointer
> > > > > > > into
> > > > > > > the reset jump address register ?
> > > > > > 
> > > > > > Frankly, i really dont like relying on the existence of a snippet of
> > > > > > code in
> > > > > > the
> > > > > > onchip ram being untouched to ensure a reboot/reset will occur for
> > > > > > this
> > > > > > csel=0
> > > > > > case.  i am certain this case is rarely used, and confident that it
> > > > > > isnt
> > > > > > being
> > > > > > used while trying to preserve sdram contents.
> > > > > 
> > > > > Well, you already rely on such snippet, it's SPL. If you corrupt SPL
> > > > > and
> > > > > do warm reset, your system hangs, I had that multiple times :)
> > > > 
> > > > True.  I would argue to just use cold resets but i think arria 10 has
> > > > more
> > > > use
> > > > for the warm reset case.
> > > 
> > > OK
> > > 
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > the downside is that the scorecard is reset every boot. so the
> > > > > > bootrom
> > > > > > will
> > > > > > retry all the spl images again resulting in possibly longer boot
> > > > > > times.
> > > > > 
> > > > > Is that significant ?
> > > > 
> > > > The watchdog timeout is on the order of 1.5 seconds.  That would be for
> > > > each
> > > > failed spl.
> > > 
> > > Hm, OK. But then your system is kinda broken, so you should expect this
> > > I guess.
> > 
> > My thought exactly...  I would like to see if Chin Liang or Dinh have any
> > comments?
> 
> Chin Liang, Dinh, any comments?

Marek, I would like to propose we move forward with this patch?

--dalon

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

Re: [U-Boot] [PATCH 1/2] arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC

[Dalon Westergreen]

On Sun, 2017-03-05 at 18:16 +0100, Marek Vasut wrote:
> On 03/05/2017 01:54 PM, Frank Kunz wrote:
> > 
> > This allows the SPL to scan the MMC for a valid uboot image on a second
> > sector location defined by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when
> > the default location "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + first
> > partition offset" does not contain a valid uboot image.
> > 
> > Signed-off-by: Frank Kunz 
> > ---
> > :100644 100644 dd5933d43c... bd3e83ddea... Minclude/configs/socfpga_
> > de0_nano_soc.h
> >  include/configs/socfpga_de0_nano_soc.h | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/include/configs/socfpga_de0_nano_soc.h
> > b/include/configs/socfpga_de0_nano_soc.h
> > index dd5933d43c..bd3e83ddea 100644
> > --- a/include/configs/socfpga_de0_nano_soc.h
> > +++ b/include/configs/socfpga_de0_nano_soc.h
> > @@ -12,6 +12,8 @@
> >  #define CONFIG_FAT_WRITE
> >  #define CONFIG_HW_WATCHDOG
> > 
> > +#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
> > +
> >  /* Memory configurations */
> >  #define PHYS_SDRAM_1_SIZE  0x4000  /* 1GiB */
> > 
> > 
> This looks like a horrid hack , didn't Dalon add support into U-Boot SPL 
> to scan all partitions for the final u-boot image ?

I did.  The 0xA2 partition can be located on any partition number now.  I
believe Frank places the SPL image at a 64KB offset from the start of the
sdcard to skip the MBR/GPT.  But per our previous debate, it is not my
favored implementation as it relies on the bootrom to load the SPL once.

Also, i mentioned before that i would like to hold off on this patch set and
let Ley Foon et al finish the A10 stuff.

--dalon

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

Re: [U-Boot] [PATCH 2/2] arm: socfpga: Enable part command and EFI partition support for DE0-nano-SoC

[Marek Vasut]

On 03/05/2017 01:54 PM, Frank Kunz wrote:

Those features are used by distro boot with efi boot.

Signed-off-by: Frank Kunz 
---
:100644 100644 b122135690... c22b54b48d... M
configs/socfpga_de0_nano_soc_defconfig
 configs/socfpga_de0_nano_soc_defconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index b122135690..c22b54b48d 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -4,11 +4,11 @@ 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_nano_soc.dtb"
 CONFIG_FIT=y
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
+CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb"


Is this move needed ? (no, it's not)


 CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
@@ -21,6 +21,7 @@ CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_I2C=y
@@ -37,6 +38,8 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
+CONFIG_EFI_PARTITION=y
+# CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
@@ -59,5 +62,3 @@ CONFIG_G_DNL_MANUFACTURER="terasic"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_USE_TINY_PRINTF=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE=0xa2


+CC Dalon ...


\ No newline at end of file



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

Re: [U-Boot] [PATCH 1/2] arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC

[Marek Vasut]

On 03/05/2017 01:54 PM, Frank Kunz wrote:

This allows the SPL to scan the MMC for a valid uboot image on a second
sector location defined by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when
the default location "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + first
partition offset" does not contain a valid uboot image.

Signed-off-by: Frank Kunz 
---
:100644 100644 dd5933d43c... bd3e83ddea... M
include/configs/socfpga_de0_nano_soc.h
 include/configs/socfpga_de0_nano_soc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/socfpga_de0_nano_soc.h 
b/include/configs/socfpga_de0_nano_soc.h
index dd5933d43c..bd3e83ddea 100644
--- a/include/configs/socfpga_de0_nano_soc.h
+++ b/include/configs/socfpga_de0_nano_soc.h
@@ -12,6 +12,8 @@
 #define CONFIG_FAT_WRITE
 #define CONFIG_HW_WATCHDOG

+#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+
 /* Memory configurations */
 #define PHYS_SDRAM_1_SIZE  0x4000  /* 1GiB */


This looks like a horrid hack , didn't Dalon add support into U-Boot SPL 
to scan all partitions for the final u-boot image ?

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

[U-Boot] [PATCH] net: zynq_gem: Fix masking of supported phydev features

[Nathan Rossi]

When the zynq_gem driver initializes the phy it sets the supported
features that the phy can support and advertise. However instead of
masking the supported features such that it limits the available
features it sets the phy to have the exact supported features of the
zynq_gem. This is problematic as it will enable features that a phy does
not have or cannot advertise.

Specifically this appears as an issue when using a phy that is only
capable of 10/100, but the zynq_gem driver will override this and try to
enable and advertise 10/100/1000.

Reported-by: Arno Steffens 
Fixes: 80243528ef ("net: gem: Fix gem driver on 1Gbps LAN")
Signed-off-by: Nathan Rossi 
Tested-by: Arno Steffens 
Cc: Joe Hershberger 
Cc: Michal Simek 
---
 drivers/net/zynq_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 86dd03feda..a160564439 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -340,7 +340,7 @@ static int zynq_phy_init(struct udevice *dev)
if (!priv->phydev)
return -ENODEV;
 
-   priv->phydev->supported = supported | ADVERTISED_Pause |
+   priv->phydev->supported &= supported | ADVERTISED_Pause |
  ADVERTISED_Asym_Pause;
priv->phydev->advertising = priv->phydev->supported;
 
-- 
2.11.0

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

Re: [U-Boot] BeagleBoard B7 (OMAP3530) fails to boot with the current U-Boot master branch

[Tom Rini]

On Sun, Mar 05, 2017 at 02:51:54PM +0200, Siarhei Siamashka wrote:
> Hello All,
> 
> I have just unexpectedly found an old Beagleboard B7 in my closet and
> tried to compile the current U-Boot master branch for it. Appears that
> it is broken since almost 2 years ago:
> 
>https://lists.denx.de/pipermail/u-boot/2015-July/220332.html
>https://lists.denx.de/pipermail/u-boot/2016-May/253777.html
> 
> And after trying to narrow it down, looks like the failure happens in
> the prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c' when
> it is compiled as Thumb2. At least the SPL can successfully boot after
> the following change (GCC6 is needed for this pragma):

Good job sorting this out.  I think it might be best to just disable
Thumb on beagleboard.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] arm: socfpga: Enable part command and EFI partition support for DE0-nano-SoC

[Frank Kunz]

Those features are used by distro boot with efi boot.

Signed-off-by: Frank Kunz 
---
:100644 100644 b122135690... c22b54b48d... M
configs/socfpga_de0_nano_soc_defconfig
 configs/socfpga_de0_nano_soc_defconfig | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/configs/socfpga_de0_nano_soc_defconfig 
b/configs/socfpga_de0_nano_soc_defconfig
index b122135690..c22b54b48d 100644
--- a/configs/socfpga_de0_nano_soc_defconfig
+++ b/configs/socfpga_de0_nano_soc_defconfig
@@ -4,11 +4,11 @@ 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_nano_soc.dtb"
 CONFIG_FIT=y
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
+CONFIG_DEFAULT_FDT_FILE="socfpga_cyclone5_de0_nano_soc.dtb"
 CONFIG_VERSION_VARIABLE=y
 # CONFIG_DISPLAY_BOARDINFO is not set
 CONFIG_SPL=y
@@ -21,6 +21,7 @@ CONFIG_CMD_ASKENV=y
 CONFIG_CMD_GREPENV=y
 # CONFIG_CMD_FLASH is not set
 CONFIG_CMD_MMC=y
+CONFIG_CMD_PART=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_SPI=y
 CONFIG_CMD_I2C=y
@@ -37,6 +38,8 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
 CONFIG_CMD_UBI=y
+CONFIG_EFI_PARTITION=y
+# CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SPL_DM=y
 CONFIG_DFU_MMC=y
 CONFIG_DM_GPIO=y
@@ -59,5 +62,3 @@ CONFIG_G_DNL_MANUFACTURER="terasic"
 CONFIG_G_DNL_VENDOR_NUM=0x0525
 CONFIG_G_DNL_PRODUCT_NUM=0xa4a5
 CONFIG_USE_TINY_PRINTF=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE=y
-CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE=0xa2
\ No newline at end of file
-- 
2.11.0

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

[U-Boot] [PATCH 1/2] arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC

[Frank Kunz]

This allows the SPL to scan the MMC for a valid uboot image on a second
sector location defined by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR when
the default location "CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR + first
partition offset" does not contain a valid uboot image.

Signed-off-by: Frank Kunz 
---
:100644 100644 dd5933d43c... bd3e83ddea... M
include/configs/socfpga_de0_nano_soc.h
 include/configs/socfpga_de0_nano_soc.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/configs/socfpga_de0_nano_soc.h 
b/include/configs/socfpga_de0_nano_soc.h
index dd5933d43c..bd3e83ddea 100644
--- a/include/configs/socfpga_de0_nano_soc.h
+++ b/include/configs/socfpga_de0_nano_soc.h
@@ -12,6 +12,8 @@
 #define CONFIG_FAT_WRITE
 #define CONFIG_HW_WATCHDOG
 
+#define CONFIG_SPL_ABORT_ON_RAW_IMAGE
+
 /* Memory configurations */
 #define PHYS_SDRAM_1_SIZE  0x4000  /* 1GiB */
 
-- 
2.11.0

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

[U-Boot] [PATCH 0/2] arm: socfpga: Enable EFI support for DE0-nano-SoC disto boot

[Frank Kunz]

This enables EFI support for DE0-nano-SoC distro boot.

The patches will apply on top of Dalon Westergreens "[PATCH v3 0/8] arm: 
socfpga: Move to using distro boot" series.

Tested on openSUSE openSUSE Tumbleweed ARM JeOS image.

Signed-off-by: Frank Kunz 

Frank Kunz (2):
  arm: socfpga: Enable abort for DE-nano-SoC SPL uboot load from MMC
  arm: socfpga: Enable part command and EFI partition support for
DE0-nano-SoC

 configs/socfpga_de0_nano_soc_defconfig | 7 ---
 include/configs/socfpga_de0_nano_soc.h | 2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

--
2.11.0

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

[U-Boot] BeagleBoard B7 (OMAP3530) fails to boot with the current U-Boot master branch

[Siarhei Siamashka]

Hello All,

I have just unexpectedly found an old Beagleboard B7 in my closet and
tried to compile the current U-Boot master branch for it. Appears that
it is broken since almost 2 years ago:

   https://lists.denx.de/pipermail/u-boot/2015-July/220332.html
   https://lists.denx.de/pipermail/u-boot/2016-May/253777.html

And after trying to narrow it down, looks like the failure happens in
the prcm_init() function from 'arch/arm/mach-omap2/omap3/clock.c' when
it is compiled as Thumb2. At least the SPL can successfully boot after
the following change (GCC6 is needed for this pragma):


diff --git a/arch/arm/mach-omap2/omap3/clock.c 
b/arch/arm/mach-omap2/omap3/clock.c
index 006969e..8064fa6 100644
--- a/arch/arm/mach-omap2/omap3/clock.c
+++ b/arch/arm/mach-omap2/omap3/clock.c
@@ -592,6 +592,8 @@ static void iva_init_36xx(u32 sil_index, u32 clk_index)
wait_on_value(ST_IVA2_CLK, 1, _base->idlest_pll_iva2, LDELAY);
 }
 
+#pragma GCC target ("arm")
+
 /**
  * prcm_init() - inits clocks for PRCM as defined in clocks.h
  *   called from SRAM, or Flash (using temp SRAM stack).
@@ -700,6 +702,8 @@ void prcm_init(void)
sdelay(5000);
 }
 
+#pragma GCC target ("thumb")
+
 /*
  * Enable usb ehci uhh, tll clocks
  */


Now it's very interesting to figure out what exactly is wrong
there. OMAP3530 and DM3730 have different code paths in this
function, so it's not very surprising that only OMAP3530 is
broken.

Yes, I know that OMAP3530 has a very old and buggy Cortex-A8 core.
But I tried to apply all the Thumb2 related errata workarounds early
in 'arch/arm/cpu/armv7/start.S'. And also enforced single-issue
execution (bit 10 in the AUXCR) as a workaround for the most nasty
erratum (657417: A 32-bit branch instruction that spans two 4K regions
can result in an incorrect operation) just because I don't fully trust
the linker.

-- 
Best regards,
Siarhei Siamashka
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/8] arm: socfpga: Add distro boot to socfpga common header

[Frank Kunz]

Am 19.02.2017 um 21:20 schrieb Dalon Westergreen:
> This adds a common environment and support for distro boot
> in the common socfpga header.
> 
> Signed-off-by: Dalon Westergreen 
> Acked-by: Marek Vasut 
> 
> --
> Changes in v4:
>  - Move env back to being right after the MBR
> Changes in v3:
>  - fix spacing between asterix
>  - remove verify=n as a default setting
> 
> Changes in v2:
>  - Remove unneeded CONFIG_BOOTFILE and fdt_addr
>  - cleanup spacing in MMC env size
> ---
>  include/configs/socfpga_common.h | 52 
> 
>  1 file changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index 582b04a..55e0bf9 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -67,6 +67,9 @@
>  #define CONFIG_SYS_HOSTNAME  CONFIG_SYS_BOARD
>  #endif
>  
> +#define CONFIG_CMD_PXE
> +#define CONFIG_MENU
> +
>  /*
>   * Cache
>   */
> @@ -245,13 +248,13 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>   * U-Boot environment
>   */
>  #if !defined(CONFIG_ENV_SIZE)
> -#define CONFIG_ENV_SIZE  4096
> +#define CONFIG_ENV_SIZE  (8 * 1024)
>  #endif
>  
>  /* Environment for SDMMC boot */
>  #if defined(CONFIG_ENV_IS_IN_MMC) && !defined(CONFIG_ENV_OFFSET)
> -#define CONFIG_SYS_MMC_ENV_DEV   0   /* device 0 */
> -#define CONFIG_ENV_OFFSET512 /* just after the MBR */
> +#define CONFIG_SYS_MMC_ENV_DEV   0 /* device 0 */
> +#define CONFIG_ENV_OFFSET512 /* just after the MBR */

That will cause a conflict on distributions that use GPT. I added
DE0-nano-SoC to openSUSE by using EFI boot which uses GPT. There this
will fail.

>  #endif
>  
>  /* Environment for QSPI boot */
> @@ -308,8 +311,12 @@ 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)
> -#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION   2
>  #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME  "u-boot-dtb.img"
> +#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION   1
> +#endif
> +#else
> +#ifndef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION
> +#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION   1
>  #endif
>  #endif
>  
> @@ -331,4 +338,41 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>   */
>  #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
>  
> +/* Extra Environment */
> +#ifndef CONFIG_SPL_BUILD
> +#include 
> +
> +#ifdef CONFIG_CMD_PXE
> +#define BOOT_TARGET_DEVICES_PXE(func) func(PXE, pxe, na)
> +#else
> +#define BOOT_TARGET_DEVICES_PXE(func)
> +#endif
> +
> +#ifdef CONFIG_CMD_MMC
> +#define BOOT_TARGET_DEVICES_MMC(func) func(MMC, mmc, 0)
> +#else
> +#define BOOT_TARGET_DEVICES_MMC(func)
> +#endif
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + BOOT_TARGET_DEVICES_MMC(func) \
> + BOOT_TARGET_DEVICES_PXE(func) \
> + func(DHCP, dhcp, na)
> +
> +#include 
> +
> +#ifndef CONFIG_EXTRA_ENV_SETTINGS
> +#define CONFIG_EXTRA_ENV_SETTINGS \
> + "fdtfile=" CONFIG_DEFAULT_FDT_FILE "\0" \
> + "bootm_size=0xa00\0" \
> + "kernel_addr_r="__stringify(CONFIG_SYS_LOAD_ADDR)"\0" \
> + "fdt_addr_r=0x0200\0" \
> + "scriptaddr=0x0210\0" \
> + "pxefile_addr_r=0x0220\0" \
> + "ramdisk_addr_r=0x0230\0" \
> + BOOTENV
> +
> +#endif
> +#endif
> +
>  #endif   /* __CONFIG_SOCFPGA_COMMON_H__ */
> 

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 14/17] sunxi: Pine64: defconfig: enable SPL FIT support

[André Przywara]

On 05/03/17 04:06, Jonathan Gray wrote:
> On Fri, Mar 03, 2017 at 09:55:25AM +, Andre Przywara wrote:
>> Hi,
>>
>> On 03/03/17 09:22, Maxime Ripard wrote:
>>> On Thu, Mar 02, 2017 at 12:03:20AM +0800, Icenowy Zheng wrote:

 2017???3???1??? 23:51??? Maxime Ripard 
 ?
>
> Hi Andre, 
>
> On Wed, Mar 01, 2017 at 02:25:26AM +, Andre Przywara wrote: 
>> The Pine64 (and all other 64-bit Allwinner boards) need to load an 
>> ARM Trusted Firmware image beside the actual U-Boot proper. 
>> This can now be easily achieved by using the just extended SPL FIT 
>> loading support, so enable it in the Pine64 defconfig. 
>> Also add the FIT image as a build target to 64-bit sunxi board to 
>> trigger the respective Makefile rules. 
>>
>> Signed-off-by: Andre Przywara  
>> --- 
>>   configs/pine64_plus_defconfig  | 6 ++ 
>>   include/configs/sunxi-common.h | 4  
>>   2 files changed, 10 insertions(+) 
>>
>> diff --git a/configs/pine64_plus_defconfig 
>> b/configs/pine64_plus_defconfig 
>> index 7c7d86f..2b47157 100644 
>> --- a/configs/pine64_plus_defconfig 
>> +++ b/configs/pine64_plus_defconfig 
>> @@ -3,9 +3,14 @@ CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER=y 
>>   CONFIG_ARCH_SUNXI=y 
>>   CONFIG_MACH_SUN50I=y 
>>   CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-pine64-plus" 
>> +CONFIG_OF_LIST="sun50i-a64-pine64 sun50i-a64-pine64-plus" 
>>   # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set 
>>   CONFIG_CONSOLE_MUX=y 
>>   CONFIG_SPL=y 
>> +CONFIG_FIT=y 
>> +CONFIG_SPL_FIT=y 
>> +CONFIG_SPL_LOAD_FIT=y 
>> +CONFIG_SPL_OF_LIBFDT=y 
>
> I'm not sure we want to force down that support to all our users. 

 A64 boards are now unusable without proper ATF.
>>>
>>> That's debatable, but that's not really what I meant. What I meant was
>>> that they're perfectly usable without FIT.
>>
>> But this is a defconfig for a certain, and the Pine64 is not really
>> usable without ATF at the moment in an upstream tree.
> 
> Could board/sunxi/README.pine64 be updated for the current state of
> things?

Ah, right, I forgot this, thanks for the heads up.

> Without FIT is it now possible with u-boot 2017.03 to use sunxi-spl.bin
> as a drop in replacement for Allwinner's boot0 and get a working
> combination of SPL/u-boot/ATF that can be redistributed when combining
> the parts with boot0img?

Yes, it boots - into U-Boot, but not yet into Linux. For this you need
ATF and thus this series.

> Using your repositories
> https://github.com/apritzel/arm-trusted-firmware/tree/allwinner (for ATF)

Yes.

> https://github.com/apritzel/pine64 (for boot0img)

This is now obsolete, at least with this series.

> README.pine64 still states that there is no SPL available.
> 
> Does it make any sense to build a combined spl+u-boot as is done with
> the armv7 sunxi targets without ATF?  Or will this not boot?

It will load and run U-Boot proper, but will crash once you try to load
Linux, because the ATF is missing.
But it would make sense to combine the SPL + u-boot.itb (which contains
the ATF) to one file. I just need to have a look what needs to be done
in the Makefile for this.

Cheers,
Andre.

> diff --git a/arch/arm/cpu/armv8/config.mk b/arch/arm/cpu/armv8/config.mk
> index 27b66d41b1..a323faf563 100644
> --- a/arch/arm/cpu/armv8/config.mk
> +++ b/arch/arm/cpu/armv8/config.mk
> @@ -12,3 +12,12 @@ PLATFORM_CPPFLAGS += $(PF_NO_UNALIGNED)
>  EFI_LDS := elf_aarch64_efi.lds
>  EFI_CRT0 := crt0_aarch64_efi.o
>  EFI_RELOC := reloc_aarch64_efi.o
> +
> +# Build a combined spl + u-boot image
> +ifdef CONFIG_ARCH_SUNXI
> +ifdef CONFIG_SPL
> +ifndef CONFIG_SPL_BUILD
> +ALL-y += u-boot-sunxi-with-spl.bin
> +endif
> +endif
> +endif
> 

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

Re: [U-Boot] [PATCH v1] env_mmc: configure environment offsets via device tree

[Igor Grinberg]

Hi Simon,

On 03/03/17 06:53, Simon Glass wrote:
> Hi Igor,
> 
> On 22 February 2017 at 00:35, Igor Grinberg  wrote:
>> Hi Philipp, Simon,
>>
>> On 02/22/17 05:59, Simon Glass wrote:
>>> Hi,
>>>
>>> On 20 February 2017 at 02:18, Dr. Philipp Tomsich
>>>  wrote:

 On 20 Feb 2017, at 08:22, Igor Grinberg  wrote:

 That sounds too odd...
 DT's purpose is to describe the h/w... and that does not look so...
 We also, have a dt file name in the environment, so this creates will 
 create
 a chicken and an egg problem…


 I don’t really follow… as far as I knew the DT name would have to come
 from some other source anyway, as the device containing the env might
 only be described through the device tree (e.g. mmc0).


 Why? U-Boot can live pretty well w/o DT.


 If U-Boot runs without DT, then nothing will/should change about how the
 setting
 is retrieved from CONFIG_ENV_OFFSET.
>>
>> ok.
>>

 The platform that motivated this change is ARCH_SUNXI, which does not use
 per-board defines but aims to have one generic bootloader per-SoC.
>>
>> Well, after a ten year experience with boars and different SoC vendors,
>> I don't think it is possible...
>> Unless all boards are copies of their respective reference design...
>>

 I really don't think we should go that direction. DT is not meant to 
 provide
 a solution to all your problems...


 I don’t see how this is different from other entries in chosen and config 
 as
 of today:
 common/autoboot.c allows an override through /config/bootdelay
 common/board_r.c uses /config/load-environment
 common/cli.c can pull in /config/bootcmd
 drivers/serial/serial-uclass.c uses /chosen/stdout-path

 In fact, it is the absence of this mechanism that is causing problems 
 today:
 CONFIG_ENV_OFFSET is not configurable through Kconfig, so we would
 need board-specific defines (e.g. CONFIG_SUNXI_BOARD_LYNX) and
 matching #ifdef primitives in a shared header (sunxi-common.h in our case).


 Right. Exactly, I think we should move the CONFIG_ENV_OFFSET to Kconfig.
 And that will solve the problem.


 Doing this would still get into the way of architectures that want to build
 a single
 ‘universal’ bootloader for their SoC: the ENV_OFFSET may not be the same
 across all board and vendor configurations. This can easily be handled with
 the
 (optional) prop in the DT, but not with the compile-time ENV_OFFSET.
>>
>> I think Kconfig would be enough for this, but please try your approach.
>> The 'universal' thing will probably work if you don't have too many boards 
>> and
>> they don't differ too much from each other...
>>

 If we decide to this, I’d at least like to introduce the function call to
 (the weak
 function) mmc_get_env_addr(…), so we can override this in the board code.
>>
>> That is how it works today:
>> include/environment.h:185:extern int mmc_get_env_addr(struct mmc *mmc, int 
>> copy, u32 *env_addr);
>>

 So putting this in the DT is the best (and least intrusive) option
 available.


 Ok. I see your point now. Yet I think we should keep the DT to its purpose 
 -
 which
 is to describe the h/w (and not the s/w placement layout).
>>>
>>> Well actually we put things like flash map in there and the
>>> environment position seems like a very good thing to have there.
>>
>> Well, I thought so too... But I had a discussion with kernel people
>> some time ago and they discourage this approach and would not like to
>> have the flash mapping in the DT.
> 
> I'm sorry to hear that, but it doesn't change the fact that it is very
> useful for dealing with hardware-specific differences between models.

According to kernel guys, these are not h/w specific, but rather device
specific... and it actually makes sense - on the same h/w design different
applications can use different flash mapping - just like the block devices.

> 
> Building the same software multiple times with different #ifdefs is
> often painful. Using a DT to handle these minor differences reduces
> the number of build combinations and simplifies testing.

Well, partially...
I agree that building different binaries with #ifdefs is very painful
and I highly discourage this approach.
Using a DT to handle these differences, IMO, is better but also not that
good, as it requires building multiple DT binaries (which I consider the
same as multiple U-Boot binaries) and therefore does not reduce the number
of build combinations... you just abstract the problem to a separate binary.

I'm more in favor of run time detection and adjustment of static data
along with dynamic code run.

Regarding the environment, I think it would be great to have U-Boot
detect where environment