[U-Boot] [PATCH] cmd/bdinfo: correct comment in board_detail

[Chris Packham]

This appears to be a simple typo that dates back to the original
implementation of board_detail in commit e79394643b26 ("common: Update
cmd_bdinfo for PPC").

Signed-off-by: Chris Packham 
---

 cmd/bdinfo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/bdinfo.c b/cmd/bdinfo.c
index 81ac78da940c..96d7b72df233 100644
--- a/cmd/bdinfo.c
+++ b/cmd/bdinfo.c
@@ -166,7 +166,7 @@ static inline void __maybe_unused print_std_bdinfo(const 
bd_t *bd)
 #if defined(CONFIG_PPC)
 void __weak board_detail(void)
 {
-   /* Please define boot_detail() for your platform */
+   /* Please define board_detail() for your platform */
 }
 
 int do_bdinfo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
-- 
2.13.0

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

Re: [U-Boot] [PATCH 1/5] arm: socfpga: Add checking function on searching boot device

[Chee, Tien Fong]

On Jum, 2017-08-04 at 15:10 +0200, Marek Vasut wrote:
> On 08/04/2017 07:37 AM, Chee, Tien Fong wrote:
> > 
> > On Rab, 2017-08-02 at 23:32 +0200, Marek Vasut wrote:
> > > 
> > > On 08/02/2017 12:21 PM, Chee, Tien Fong wrote:
> > > > 
> > > > 
> > > > On Isn, 2017-07-31 at 12:53 +0200, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > On 07/31/2017 12:50 PM, tien.fong.c...@intel.com wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > From: Tien Fong Chee 
> > > > > > 
> > > > > > Function for checking boot device type, which is required
> > > > > > for
> > > > > > locating
> > > > > > flash where U-boot image, FPGA design are stored.
> > > > > > 
> > > > > > Signed-off-by: Tien Fong Chee 
> > > > > > ---
> > > > > >  arch/arm/mach-socfpga/include/mach/misc.h |   19
> > > > > > +++
> > > > > >  arch/arm/mach-socfpga/misc_arria10.c  |   22
> > > > > > ++
> > > > > >  2 files changed, 41 insertions(+), 0 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > b/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > index 0b65783..b219aac 100644
> > > > > > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > > > > > @@ -14,6 +14,24 @@ struct bsel {
> > > > > >     const char  *name;
> > > > > >  };
> > > > > >  
> > > > > > +enum {
> > > > > > +   BOOT_DEVICE_RAM,
> > > > > > +   BOOT_DEVICE_MMC1,
> > > > > > +   BOOT_DEVICE_MMC2,
> > > > > > +   BOOT_DEVICE_MMC2_2,
> > > > > > +   BOOT_DEVICE_NAND,
> > > > > > +   BOOT_DEVICE_ONENAND,
> > > > > > +   BOOT_DEVICE_NOR,
> > > > > > +   BOOT_DEVICE_UART,
> > > > > > +   BOOT_DEVICE_SPI,
> > > > > > +   BOOT_DEVICE_USB,
> > > > > > +   BOOT_DEVICE_SATA,
> > > > > > +   BOOT_DEVICE_I2C,
> > > > > > +   BOOT_DEVICE_BOARD,
> > > > > > +   BOOT_DEVICE_DFU,
> > > > > > +   BOOT_DEVICE_NONE
> > > > > Why do you have so many bootdevices here if half of them
> > > > > aren't
> > > > > supported/used ?
> > > > > 
> > > > Okay, i will reduce it, i refered this from spl.h
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > +};
> > > > > > +
> > > > > >  extern struct bsel bsel_str[];
> > > > > >  
> > > > > >  #ifdef CONFIG_FPGA
> > > > > > @@ -26,6 +44,7 @@ static inline void socfpga_fpga_add(void)
> > > > > > {}
> > > > > >  unsigned int dedicated_uart_com_port(const void *blob);
> > > > > >  unsigned int shared_uart_com_port(const void *blob);
> > > > > >  unsigned int uart_com_port(const void *blob);
> > > > > > +u32 boot_device(void);
> > > > > >  #endif
> > > > > >  
> > > > > >  #endif /* _MISC_H_ */
> > > > > > diff --git a/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/misc_arria10.c
> > > > > > index 9d751f6..069a0a6 100644
> > > > > > --- a/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > +++ b/arch/arm/mach-socfpga/misc_arria10.c
> > > > > > @@ -235,6 +235,28 @@ unsigned int uart_com_port(const void
> > > > > > *blob)
> > > > > >     return shared_uart_com_port(blob);
> > > > > >  }
> > > > > >  
> > > > > > +u32 boot_device(void)
> > > > > > +{
> > > > > > +   const u32 bsel = readl(_regs->bootinfo);
> > > > > > +
> > > > > > +   switch (SYSMGR_GET_BOOTINFO_BSEL(bsel)) {
> > > > > This looks very similar to what is on Gen5 ?
> > > > > 
> > > > I refered from  function spl_boot_device in spl.c . I copied
> > > > the
> > > > function here, because U-boot also need it.
> > > So can the same code used for gen5 be recycled on gen10 ?
> > > 
> > Are you means SYSMGR_GET_BOOTINFO_BSEL? This is common #define
> > shared
> > between gen5 and gen10. 
> > If you means boot_device function, then gen5 doesn't has this
> > function.
> > Please correct me if i misunderstand your question.
> Did you try for example git grep BOOT_DEVICE arch/arm/mach-socfpga ?
> It should point you to spl_boot_device in spl.c
> 
Okay, i know what's you trying to say. I can change this function as
common code for both SPL and U-boot.

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

Re: [U-Boot] [PATCH 2/2] ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices

[Lokesh Vutla]

On 8/5/2017 8:12 AM, Nishanth Menon wrote:
> OMAP5432 did go into production with AVS class0 registers which were
> mutually exclusive from AVS Class 1.5 registers.
> 
> Most OMAP5-uEVM boards use the pre-production Class1.5 which has
> production efuse registers set to 0. However on production devices,
> these are set to valid data.
> 
> scale_vcore logic is already smart enough to detect this and use the
> "Nominal voltage" on devices that do not have efuse registers populated.
> 
> On a test production device populated as follows:
> MPU OPP_NOM:
> => md.l 0x04A0021C4 1
> 4a0021c4: 03a003e9   
> (0x3e9 = 1.01v) vs nom voltage of 1.06v
> MPU OPP_HIGH:
> => md.l 0x04A0021C8 1
> 4a0021c8: 03400485   ..@.
> 
> MM OPP_NOM:
> => md.l 0x04A0021A4 1
> 4a0021a4: 038003d4   
> (0x3d4 = 980mV) vs nom voltage of 1.025v
> MM OPP_OD:
> => md.l 0x04A0021A8 1
> 4a0021a8: 03600403   ..`.
> 
> CORE OPP_NOM:
> => md.l 0x04A0021D8 1
> 4a0021d8: 03cf   
> (0x3cf = 975mV) vs nom voltage of 1.040v
> 
> Since the efuse values are'nt currently used, we do not regress on
> existing pre-production samples (they continue to use nominal voltage).
> 
> But on boards that do have production samples populated, we can leverage
> the optimal voltages necessary for proper operation.
> 
> Tested on:
> a) 720-2644-001 OMAP5UEVM with production sample.
> b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
> 
> Data based on OMAP5432 Technical reference Manual SWPU282AF (May
> 2012-Revised Aug 2016)
> 
> NOTE: All collaterals on OMAP5432 silicon itself seems to have been
> removed from ti.com, though EVM details are still available:
> http://www.ti.com/tool/OMAP5432-EVM
> 


Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh


> Signed-off-by: Nishanth Menon 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0

[Lokesh Vutla]

On 8/5/2017 8:12 AM, Nishanth Menon wrote:
> ES2.0 descopes OPP_LOW definition. So remove it from macros defined.

Reviewed-by: Lokesh Vutla 

Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] mmc: uniphier-sd: Factor out register IO

[Masahiro Yamada]

Hi Marek,


2017-08-06 4:23 GMT+09:00 Marek Vasut :
> On 08/03/2017 02:36 PM, Masahiro Yamada wrote:
>> Hi Marek,
>
> Hi,
>
> [...]
>
>>> +static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg)
>>
>> "const" is unneeded here.
>
> Why? The function should not modify reg , so it is const.


Because "const" is useless here.

The "reg" is not a pointer, so it is obvious
that there is no impact to the callers.



Moreover, whether "reg" is constant or not
depends on how you implement the function.


If you force "const" to the argument, the only choice for the implementation
will be as follows:



static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, const u32 reg)
{
  if (priv->caps & UNIPHIER_SD_CAP_64BIT)
 return readl(priv->regbase + (reg << 1));
  else
 return readl(priv->regbase + reg);
}



If you want to implement the function as follows, you need to drop "const".

static u32 uniphier_sd_readl(struct uniphier_sd_priv *priv, u32 reg)
{
  if (priv->caps & UNIPHIER_SD_CAP_64BIT)
  reg <<= 1;

  return readl(priv->regbase + reg);
}





>> Also, could you use "unsigned int" or "int" for reg?
>
> Why?


Because "unsigned int" or "int" is more natural.

No reason to use a fixed width variable for the address offset.






-- 
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] regulator: pbias: Add PBIAS regulator for proper voltage switching on MMC1

[Jaehoon Chung]

Hi JJ,

On 08/04/2017 09:26 PM, Jean-Jacques Hiblot wrote:
> Hi Jaehoon,
> 
> 
> On 01/08/2017 06:23, Jaehoon Chung wrote:
>> Dear JJ,
>>
>> On 07/19/2017 10:52 PM, Jean-Jacques Hiblot wrote:
>>> In the TI SOCs a PBIAS cell exists to provide a bias voltage to the MMC1
>>> IO cells. Without this bias voltage these I/O cells can not function
>>> properly. The PBIAS cell is controlled by software.
>>>
>>> Signed-off-by: Jean-Jacques Hiblot 
>>> Reviewed-by: Tom Rini 
>>> Reviewed-by: Simon Glass 
>>> ---
>>>
>>> changes since v1:
>>>   - automatically select the PBIAS driver if DM_REGULATOR, DM_MMC and
>>> MMC_OMAP_HS are set
>>>   - use the dev_read_*() API to access the DT
>>>
>>>   drivers/mmc/Kconfig   |   1 +
>>>   drivers/power/regulator/Kconfig   |  10 +
>>>   drivers/power/regulator/Makefile  |   1 +
>>>   drivers/power/regulator/pbias_regulator.c | 302 
>>> ++
>>>   4 files changed, 314 insertions(+)
>>>   create mode 100644 drivers/power/regulator/pbias_regulator.c
>>>
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index 588e118..63e1122 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -158,6 +158,7 @@ config MMC_PCI
>>>   config MMC_OMAP_HS
>>>   bool "TI OMAP High Speed Multimedia Card Interface support"
>>>   select DM_MMC_OPS if DM_MMC
>>> +select DM_REGULATOR_PBIAS if DM_MMC && DM_REGULATOR
>>>   help
>>> This selects the TI OMAP High Speed Multimedia card Interface.
>>> If you have an omap2plus board with a Multimedia Card slot,
>>> diff --git a/drivers/power/regulator/Kconfig 
>>> b/drivers/power/regulator/Kconfig
>>> index f213487..f4ed3cc 100644
>>> --- a/drivers/power/regulator/Kconfig
>>> +++ b/drivers/power/regulator/Kconfig
>>> @@ -142,6 +142,16 @@ config DM_REGULATOR_PALMAS
>>>   features for REGULATOR PALMAS and the family of PALMAS PMICs.
>>>   The driver implements get/set api for: value and enable.
>>>   +config DM_REGULATOR_PBIAS
>>> +bool "Enable driver for PBIAS regulator"
>> pbias_regulator is using the regmap and syscon..
>> I think that i needs to select REGMAP and SYSCON at here.
>>
>> So i dropped the your patch from my repository.
>> Could you resend the patch? otherwise i will resend your patch after fixing.
>> let me know what you want.
> I won't be able to work on it before September. So I guess, it's better if 
> you can make the changes.

Sorry for reviewing late. If you resend the patch, i will pick this immediately.

Best Regards,
Jaehoon Chung

> Thank you,
> 
> jean-Jacques
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>> +---help---
>>> +This enables implementation of driver-model regulator uclass
>>> +features for pseudo-regulator PBIAS found in the OMAP SOCs.
>>> +This pseudo-regulator is used to provide a BIAS voltage to MMC1
>>> +signal pads and must be configured properly during a voltage switch.
>>> +Voltage switching is required by some operating modes of SDcards and
>>> +eMMC.
>>> +
>>>   config DM_REGULATOR_LP873X
>>>   bool "Enable driver for LP873X PMIC regulators"
>>>   depends on PMIC_LP873X
>>> diff --git a/drivers/power/regulator/Makefile 
>>> b/drivers/power/regulator/Makefile
>>> index ce14d08..75d611a 100644
>>> --- a/drivers/power/regulator/Makefile
>>> +++ b/drivers/power/regulator/Makefile
>>> @@ -17,5 +17,6 @@ obj-$(CONFIG_REGULATOR_S5M8767) += s5m8767.o
>>>   obj-$(CONFIG_DM_REGULATOR_SANDBOX) += sandbox.o
>>>   obj-$(CONFIG_REGULATOR_TPS65090) += tps65090_regulator.o
>>>   obj-$(CONFIG_$(SPL_)DM_REGULATOR_PALMAS) += palmas_regulator.o
>>> +obj-$(CONFIG_$(SPL_)DM_REGULATOR_PBIAS) += pbias_regulator.o
>>>   obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP873X) += lp873x_regulator.o
>>>   obj-$(CONFIG_$(SPL_)DM_REGULATOR_LP87565) += lp87565_regulator.o
>>> diff --git a/drivers/power/regulator/pbias_regulator.c 
>>> b/drivers/power/regulator/pbias_regulator.c
>>> new file mode 100644
>>> index 000..303eca9
>>> --- /dev/null
>>> +++ b/drivers/power/regulator/pbias_regulator.c
>>> @@ -0,0 +1,302 @@
>>> +/*
>>> + * (C) Copyright 2016 Texas Instruments Incorporated, 
>>> + * Jean-Jacques Hiblot 
>>> + *
>>> + * SPDX-License-Identifier:GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +struct pbias_reg_info {
>>> +u32 enable;
>>> +u32 enable_mask;
>>> +u32 disable_val;
>>> +u32 vmode;
>>> +unsigned int enable_time;
>>> +char *name;
>>> +};
>>> +
>>> +struct pbias_priv {
>>> +struct regmap *regmap;
>>> +int offset;
>>> +};
>>> +
>>> +static const struct pmic_child_info pmic_children_info[] = {
>>> +{ .prefix = "pbias", .driver = "pbias_regulator"},
>>> +{ },
>>> +};
>>> +
>>> +static int 

Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368

[Andy Yan]

Hi :

When run buildman rockchip on the master branch of current 
u-boot-rockchip tree, I got warnings about 16 rockchip arm32 based boards:


   include/config/auto.config: line x: ARCH: command not found.

   the line x is the definition of the: SPL_LDSCRITP 
"arch/$(ARCH)/cpu/u-boot-spl.lds"


   not sure is there somethings wrong about this series change.


On 2017年08月07日 01:18, Philipp Tomsich wrote:

Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our
header file.

Signed-off-by: Philipp Tomsich 
Reviewed-by: Simon Glass 
---

Changes in v4:
- (added) sets TPL_LDSCRIPT via Kconfig

Changes in v3: None
Changes in v2: None

  arch/arm/mach-rockchip/Kconfig  | 7 +++
  include/configs/rk3368_common.h | 2 --
  2 files changed, 7 insertions(+), 2 deletions(-)


Applied to u-boot-rockchip, thanks!






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

[U-Boot] [PATCH v2] m68k: add board stmark2, mcf5441x based

[Angelo Dureghello]

Sysam stmark2 board is a generic and fully (hw and sw) open board, with
a mcf54415 Coldfire CPU, 128MB of DDR2, 16MB of SPI flash and SD card
as non volatile memories, and a wifi module included on-board.
The board is actually used mainly for Coldfire custodian testing activity
related to the mcf5441x Coldfire family.

For further information please see: http://sysam.it/cff_stmark2.html

Signed-off-by: Angelo Dureghello 
---

Changes in v2:
 - remove CMD_REGINFO
 - add board information in commit message
---
 arch/m68k/Kconfig   |   5 +
 board/sysam/stmark2/Kconfig |  15 +++
 board/sysam/stmark2/MAINTAINERS |   6 ++
 board/sysam/stmark2/Makefile|   8 ++
 board/sysam/stmark2/sbf_dram_init.S | 119 +
 board/sysam/stmark2/stmark2.c   |  47 +
 configs/stmark2_defconfig   |  26 +
 include/configs/stmark2.h   | 199 
 scripts/config_whitelist.txt|   1 +
 9 files changed, 426 insertions(+)
 create mode 100644 board/sysam/stmark2/Kconfig
 create mode 100644 board/sysam/stmark2/MAINTAINERS
 create mode 100644 board/sysam/stmark2/Makefile
 create mode 100644 board/sysam/stmark2/sbf_dram_init.S
 create mode 100644 board/sysam/stmark2/stmark2.c
 create mode 100644 configs/stmark2_defconfig
 create mode 100644 include/configs/stmark2.h

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 88e7d6a7b6..ce30e97935 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -208,6 +208,10 @@ config TARGET_AMCORE
bool "Support AMCORE"
select M5307
 
+config TARGET_STMARK2
+bool "Support stmark2"
+select M54418
+
 endchoice
 
 source "board/BuS/eb_cpu5282/Kconfig"
@@ -231,5 +235,6 @@ source "board/freescale/m54455evb/Kconfig"
 source "board/freescale/m547xevb/Kconfig"
 source "board/freescale/m548xevb/Kconfig"
 source "board/sysam/amcore/Kconfig"
+source "board/sysam/stmark2/Kconfig"
 
 endmenu
diff --git a/board/sysam/stmark2/Kconfig b/board/sysam/stmark2/Kconfig
new file mode 100644
index 00..87ab7ab7b5
--- /dev/null
+++ b/board/sysam/stmark2/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_STMARK2
+
+config SYS_CPU
+   default "mcf5445x"
+
+config SYS_BOARD
+   default "stmark2"
+
+config SYS_VENDOR
+   default "sysam"
+
+config SYS_CONFIG_NAME
+   default "stmark2"
+
+endif
diff --git a/board/sysam/stmark2/MAINTAINERS b/board/sysam/stmark2/MAINTAINERS
new file mode 100644
index 00..b87f432bb3
--- /dev/null
+++ b/board/sysam/stmark2/MAINTAINERS
@@ -0,0 +1,6 @@
+STMARK2 BOARD
+M: Angelo Dureghello 
+S: Maintained
+F: board/sysam/stmark2/
+F: include/configs/stmark2.h
+F: configs/stmark2_defconfig
diff --git a/board/sysam/stmark2/Makefile b/board/sysam/stmark2/Makefile
new file mode 100644
index 00..064a57ea05
--- /dev/null
+++ b/board/sysam/stmark2/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014  Angelo Dureghello 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y = stmark2.o
+extra-y += sbf_dram_init.o
diff --git a/board/sysam/stmark2/sbf_dram_init.S 
b/board/sysam/stmark2/sbf_dram_init.S
new file mode 100644
index 00..52abda5c3c
--- /dev/null
+++ b/board/sysam/stmark2/sbf_dram_init.S
@@ -0,0 +1,119 @@
+/*
+ * Board-specific early ddr/sdram init.
+ *
+ * (C) Copyright 2017 Angelo Dureghello 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+.equ   PPMCR0, 0xfc04002d
+.equ   MSCR_SDRAMC,0xec094060
+.equ   MISCCR2,0xec09001a
+.equ   DDR_RCR,0xfc0b8180
+.equ   DDR_PADCR,  0xfc0b81ac
+.equ   DDR_CR00,   0xfc0b8000
+.equ   DDR_CR06,   0xfc0b8018
+.equ   DDR_CR09,   0xfc0b8024
+.equ   DDR_CR40,   0xfc0b80a0
+.equ   DDR_CR45,   0xfc0b80b4
+.equ   DDR_CR56,   0xfc0b80e0
+
+.global sbf_dram_init
+.text
+
+sbf_dram_init:
+   /* CD46 = DDR on */
+   move.l  #PPMCR0, %a1
+   move.b  #46, (%a1)
+
+   /* stmark 2, max drive strength */
+   move.l  #MSCR_SDRAMC, %a1
+   move.b  #1, (%a1)
+
+   /*
+* use cpu clock, seems more realiable
+*
+* DDR2 clock is serviced from DDR controller as input clock / 2
+* so, if clock comes from
+*   vco, i.e. 480(vco) / 2, so ddr clock is 240 Mhz (measured)
+*   cpu, i.e. 250(cpu) / 2, so ddr clock is 125 Mhz (measured)
+*
+* .
+*/ \DDR2 can't be clocked lower than 125Mhz
+*   / ! \   DDR2 init must pass further i/dcache enable test
+*  /_\
+*  WARNING
+*/
+
+   /* cpu / 2 = 125 Mhz for 480 Mhz pll */
+   move.l  #MISCCR2, %a1
+   move.w  #0xa01d, (%a1)
+
+   /* DDR force sw reset settings */
+   move.l  #DDR_RCR, %a1
+   move.l  #0x, (%a1)
+   move.l  #0x4000, (%a1)
+
+   /*
+* PAD_ODT_CS: for us seems both 1(75 ohm) and 2(150ohm) are good,
+* 

Re: [U-Boot] [PATCH 2/4] dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB

[Simon Glass]

Hi Marek,

On 6 August 2017 at 13:17, Marek Vasut  wrote:
> On 08/06/2017 07:15 AM, Simon Glass wrote:
>> On 24 July 2017 at 09:07,   wrote:
>>> From: Patrice Chotard 
>>>
>>> Add CONFIG_DM_USB flag to avoid following compilation errors
>>> detected by buildman :
>>> +drivers/usb/host/built-in.o: In function `xhci_dwc3_remove':
>>> +drivers/usb/host/xhci-dwc3.c:168: undefined reference to `xhci_deregister'
>>> +drivers/usb/host/built-in.o: In function `xhci_dwc3_probe':
>>> +drivers/usb/host/xhci-dwc3.c:145: undefined reference to `usb_get_dr_mode'
>>> +drivers/usb/host/xhci-dwc3.c:152: undefined reference to `xhci_register'
>>>
>>> introduced by patch d5c3f014da3 "usb: host: xhci-dwc3: Convert driver to DM"
>>>
>>> Signed-off-by: Patrice Chotard 
>>> Reported-by: Ran Wang 
>>> ---
>>>  drivers/usb/host/xhci-dwc3.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>
>> Reviewed-by: Simon Glass 
>>
> Um, this patch was applied like two weeks ago. Is this some automated
> botmail ... reviewman ? :)

There is no mention of it being applied on this thread, so it looked
like an open patch to me.

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

Re: [U-Boot] [PATCH 2/4] dm: usb: host: xhci-dwc3: add missing #ifdef CONFIG_DM_USB

[Marek Vasut]

On 08/06/2017 07:15 AM, Simon Glass wrote:
> On 24 July 2017 at 09:07,   wrote:
>> From: Patrice Chotard 
>>
>> Add CONFIG_DM_USB flag to avoid following compilation errors
>> detected by buildman :
>> +drivers/usb/host/built-in.o: In function `xhci_dwc3_remove':
>> +drivers/usb/host/xhci-dwc3.c:168: undefined reference to `xhci_deregister'
>> +drivers/usb/host/built-in.o: In function `xhci_dwc3_probe':
>> +drivers/usb/host/xhci-dwc3.c:145: undefined reference to `usb_get_dr_mode'
>> +drivers/usb/host/xhci-dwc3.c:152: undefined reference to `xhci_register'
>>
>> introduced by patch d5c3f014da3 "usb: host: xhci-dwc3: Convert driver to DM"
>>
>> Signed-off-by: Patrice Chotard 
>> Reported-by: Ran Wang 
>> ---
>>  drivers/usb/host/xhci-dwc3.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> Reviewed-by: Simon Glass 
> 
Um, this patch was applied like two weeks ago. Is this some automated
botmail ... reviewman ? :)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] m68k: add board stmark2, mcf5441x based

[Angelo Dureghello]

Hi Bin,

On 05/08/2017 15:19, Bin Meng wrote:

Hi Angelo,

On Sat, Jul 15, 2017 at 5:45 AM, Angelo Dureghello  wrote:

Signed-off-by: Angelo Dureghello 


Can you please write something about your board in the commit message?


sure, sending patch v2.




---
  arch/m68k/Kconfig   |   5 +
  board/sysam/stmark2/Kconfig |  15 +++
  board/sysam/stmark2/MAINTAINERS |   6 ++
  board/sysam/stmark2/Makefile|   8 ++
  board/sysam/stmark2/sbf_dram_init.S | 119 +
  board/sysam/stmark2/stmark2.c   |  47 +
  configs/stmark2_defconfig   |  26 +
  include/configs/stmark2.h   | 202 
  scripts/config_whitelist.txt|   1 +
  9 files changed, 429 insertions(+)
  create mode 100644 board/sysam/stmark2/Kconfig
  create mode 100644 board/sysam/stmark2/MAINTAINERS
  create mode 100644 board/sysam/stmark2/Makefile
  create mode 100644 board/sysam/stmark2/sbf_dram_init.S
  create mode 100644 board/sysam/stmark2/stmark2.c
  create mode 100644 configs/stmark2_defconfig
  create mode 100644 include/configs/stmark2.h

diff --git a/arch/m68k/Kconfig b/arch/m68k/Kconfig
index 26509b73c6..42fb91539a 100644
--- a/arch/m68k/Kconfig
+++ b/arch/m68k/Kconfig
@@ -200,6 +200,10 @@ config TARGET_AMCORE
 bool "Support AMCORE"
 select M5307

+config TARGET_STMARK2
+bool "Support stmark2"
+select M54418
+
  endchoice

  source "board/BuS/eb_cpu5282/Kconfig"
@@ -223,5 +227,6 @@ source "board/freescale/m54455evb/Kconfig"
  source "board/freescale/m547xevb/Kconfig"
  source "board/freescale/m548xevb/Kconfig"
  source "board/sysam/amcore/Kconfig"
+source "board/sysam/stmark2/Kconfig"

  endmenu
diff --git a/board/sysam/stmark2/Kconfig b/board/sysam/stmark2/Kconfig
new file mode 100644
index 00..87ab7ab7b5
--- /dev/null
+++ b/board/sysam/stmark2/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_STMARK2
+
+config SYS_CPU
+   default "mcf5445x"
+
+config SYS_BOARD
+   default "stmark2"
+
+config SYS_VENDOR
+   default "sysam"
+
+config SYS_CONFIG_NAME
+   default "stmark2"
+
+endif
diff --git a/board/sysam/stmark2/MAINTAINERS b/board/sysam/stmark2/MAINTAINERS
new file mode 100644
index 00..b87f432bb3
--- /dev/null
+++ b/board/sysam/stmark2/MAINTAINERS
@@ -0,0 +1,6 @@
+STMARK2 BOARD
+M: Angelo Dureghello 
+S: Maintained
+F: board/sysam/stmark2/
+F: include/configs/stmark2.h
+F: configs/stmark2_defconfig
diff --git a/board/sysam/stmark2/Makefile b/board/sysam/stmark2/Makefile
new file mode 100644
index 00..064a57ea05
--- /dev/null
+++ b/board/sysam/stmark2/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014  Angelo Dureghello 
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y = stmark2.o
+extra-y += sbf_dram_init.o
diff --git a/board/sysam/stmark2/sbf_dram_init.S 
b/board/sysam/stmark2/sbf_dram_init.S
new file mode 100644
index 00..52abda5c3c
--- /dev/null
+++ b/board/sysam/stmark2/sbf_dram_init.S
@@ -0,0 +1,119 @@
+/*
+ * Board-specific early ddr/sdram init.
+ *
+ * (C) Copyright 2017 Angelo Dureghello 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+.equ   PPMCR0, 0xfc04002d
+.equ   MSCR_SDRAMC,0xec094060
+.equ   MISCCR2,0xec09001a
+.equ   DDR_RCR,0xfc0b8180
+.equ   DDR_PADCR,  0xfc0b81ac
+.equ   DDR_CR00,   0xfc0b8000
+.equ   DDR_CR06,   0xfc0b8018
+.equ   DDR_CR09,   0xfc0b8024
+.equ   DDR_CR40,   0xfc0b80a0
+.equ   DDR_CR45,   0xfc0b80b4
+.equ   DDR_CR56,   0xfc0b80e0
+
+.global sbf_dram_init
+.text
+
+sbf_dram_init:
+   /* CD46 = DDR on */
+   move.l  #PPMCR0, %a1
+   move.b  #46, (%a1)
+
+   /* stmark 2, max drive strength */
+   move.l  #MSCR_SDRAMC, %a1
+   move.b  #1, (%a1)
+
+   /*
+* use cpu clock, seems more realiable
+*
+* DDR2 clock is serviced from DDR controller as input clock / 2
+* so, if clock comes from
+*   vco, i.e. 480(vco) / 2, so ddr clock is 240 Mhz (measured)
+*   cpu, i.e. 250(cpu) / 2, so ddr clock is 125 Mhz (measured)
+*
+* .
+*/ \DDR2 can't be clocked lower than 125Mhz
+*   / ! \   DDR2 init must pass further i/dcache enable test
+*  /_\
+*  WARNING
+*/
+
+   /* cpu / 2 = 125 Mhz for 480 Mhz pll */
+   move.l  #MISCCR2, %a1
+   move.w  #0xa01d, (%a1)
+
+   /* DDR force sw reset settings */
+   move.l  #DDR_RCR, %a1
+   move.l  #0x, (%a1)
+   move.l  #0x4000, (%a1)
+
+   /*
+* PAD_ODT_CS: for us seems both 1(75 ohm) and 2(150ohm) are good,
+* 500/700 mV are ok
+*/
+   move.l  #DDR_PADCR, %a1
+   move.l  #0x01030203, (%a1)  /* as freescale tower */
+
+   move.l  #DDR_CR00, %a1
+   move.l  #0x01010101, (%a1)+ /* 0x00 */
+   

Re: [U-Boot] [PATCH] m68k: add board stmark2, mcf5441x based

[Angelo Dureghello]

Hi Christophe,

On 05/08/2017 14:58, christophe leroy wrote:



Le 14/07/2017 à 23:45, Angelo Dureghello a écrit :

Signed-off-by: Angelo Dureghello 
---
 arch/m68k/Kconfig   |   5 +
 board/sysam/stmark2/Kconfig |  15 +++
 board/sysam/stmark2/MAINTAINERS |   6 ++
 board/sysam/stmark2/Makefile|   8 ++
 board/sysam/stmark2/sbf_dram_init.S | 119 +
 board/sysam/stmark2/stmark2.c   |  47 +
 configs/stmark2_defconfig   |  26 +
 include/configs/stmark2.h   | 202 
 scripts/config_whitelist.txt|   1 +
 9 files changed, 429 insertions(+)
 create mode 100644 board/sysam/stmark2/Kconfig
 create mode 100644 board/sysam/stmark2/MAINTAINERS
 create mode 100644 board/sysam/stmark2/Makefile
 create mode 100644 board/sysam/stmark2/sbf_dram_init.S
 create mode 100644 board/sysam/stmark2/stmark2.c
 create mode 100644 configs/stmark2_defconfig
 create mode 100644 include/configs/stmark2.h



[...]


diff --git a/include/configs/stmark2.h b/include/configs/stmark2.h
new file mode 100644
index 00..bd1f64bc8f
--- /dev/null
+++ b/include/configs/stmark2.h
@@ -0,0 +1,202 @@
+/*
+ * Sysam stmark2 board configuration
+ *
+ * (C) Copyright 2016  Angelo Dureghello 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __STMARK2_CONFIG_H
+#define __STMARK2_CONFIG_H
+
+#define CONFIG_STMARK2
+#define CONFIG_HOSTNAMEstmark2
+
+#define CONFIG_MCFUART
+#define CONFIG_SYS_UART_PORT0
+#define CONFIG_SYS_BAUDRATE_TABLE{ 9600 , 19200 , 38400 , 57600, 115200 }
+
+#define LDS_BOARD_TEXT \
+board/sysam/stmark2/sbf_dram_init.o (.text*)
+
+#define CONFIG_TIMESTAMP
+
+/* commands */
+#define CONFIG_CMD_REGINFO


CMD_REGINFO is only on PowerPC 8xx, 85xx and 86xx



thanks, checking / fixing.


Christophe


+
+#define CONFIG_BOOTARGS\
+"console=ttyS0,115200 root=/dev/ram0 rw "\
+"rootfstype=ramfs "\
+"rdinit=/bin/init "\
+"devtmpfs.mount=1"
+
+#define CONFIG_BOOTCOMMAND\
+"sf probe 0:1 5000; "\
+"sf read ${loadaddr} 0x10 ${kern_size}; "\
+"bootm ${loadaddr}"
+
+#define CONFIG_EXTRA_ENV_SETTINGS\
+"kern_size=0x70\0"\
+"loadaddr=0x40001000\0"\
+"-(rootfs)\0"\
+"update_uboot=loady ${loadaddr}; "\
+"sf probe 0:1 5000; "\
+"sf erase 0 0x8; "\
+"sf write ${loadaddr} 0 ${filesize}\0"\
+"update_kernel=loady ${loadaddr}; "\
+"setenv kern_size ${filesize}; saveenv; "\
+"sf probe 0:1 5000; "\
+"sf erase 0x10 0x70; "\
+"sf write ${loadaddr} 0x10 ${filesize}\0"\
+"update_rootfs=loady ${loadaddr}; "\
+"sf probe 0:1 5000; "\
+"sf erase 0x0080 0x10; "\
+"sf write ${loadaddr} 0x0080 ${filesize}\0"\
+""
+
+/* Realtime clock */
+#undef CONFIG_MCFRTC
+#define CONFIG_RTC_MCFRRTC
+#define CONFIG_SYS_MCFRRTC_BASE0xFC0A8000
+
+/* spi not partitions */
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_MTD_DEVICE
+#define CONFIG_JFFS2_CMDLINE
+#define CONFIG_JFFS2_DEV"nor0"
+#define MTDIDS_DEFAULT"nor0=spi-flash.0"
+#define MTDPARTS_DEFAULT \
+"mtdparts=spi-flash.0:" \
+"1m(u-boot),"\
+"7m(kernel),"\
+"-(rootfs)"
+
+/* Timer */
+#define CONFIG_MCFTMR
+#undef CONFIG_MCFPIT
+
+/* DSPI and Serial Flash */
+#define CONFIG_CF_SPI
+#define CONFIG_CF_DSPI
+#define CONFIG_SF_DEFAULT_SPEED5000
+#define CONFIG_SERIAL_FLASH
+#define CONFIG_HARD_SPI
+#define CONFIG_SPI_FLASH_ISSI
+#define CONFIG_ENV_SPI_BUS0
+#define CONFIG_ENV_SPI_CS1
+
+#define CONFIG_SYS_SBFHDR_SIZE0x7
+
+#define CONFIG_SYS_DSPI_CTAR0(DSPI_CTAR_TRSZ(7) | \
+DSPI_CTAR_PCSSCK_1CLK | \
+DSPI_CTAR_PASC(0) | \
+DSPI_CTAR_PDT(0) | \
+DSPI_CTAR_CSSCK(0) | \
+DSPI_CTAR_ASC(0) | \
+DSPI_CTAR_DT(1) | \
+DSPI_CTAR_BR(6))
+#define CONFIG_SYS_DSPI_CTAR1(CONFIG_SYS_DSPI_CTAR0)
+#define CONFIG_SYS_DSPI_CTAR2(CONFIG_SYS_DSPI_CTAR0)
+
+/* Input, PCI, Flexbus, and VCO */
+#define CONFIG_EXTRA_CLOCK
+
+#define CONFIG_PRAM2048/* 2048 KB */
+#define CONFIG_SYS_LONGHELP
+#define CONFIG_AUTO_COMPLETE
+#define CONFIG_SYS_CBSIZE256/* Console I/O Buffer Size */
+
+/* Print Buffer Size */
+#define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + \
+

Re: [U-Boot] [RFC] efi_loader: Add test to boot OpenBSD's efi bootloader

[Rob Clark]

On Sun, Aug 6, 2017 at 2:54 PM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Sun,  6 Aug 2017 12:10:28 -0400
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Kinda works, but since we don't have an 'exit' command like grub, we
>> have to reboot, which leaves the "board" in a bad state (I guess,
>> since the next test fails).  I haven't tackled the travis bits to get
>> travis to download OpenBSD's bootloader, or other little details like
>> that.
>
> What does the grub "exit" command do?  Simply call EFI_BOOT_SERVICE.Exit()?
> Wouldn't be too difficult for me to add a command that does this.

Yeah, I think just calls BS->Exit().. that would be quite useful.

BR,
-R

> The OpenBSD bootloader currently just executes an illegal instruction
> as EFI_RUNTIME_SERVICES.ResetSystem() didn't work at the time I wrote
> the code.  Perhaps I should revisit that issue now.
>
>>  test/py/tests/test_efi_loader.py | 19 +++
>>  1 file changed, 19 insertions(+)
>>
>> diff --git a/test/py/tests/test_efi_loader.py 
>> b/test/py/tests/test_efi_loader.py
>> index 5d7f5dbfb2..376f6442a3 100644
>> --- a/test/py/tests/test_efi_loader.py
>> +++ b/test/py/tests/test_efi_loader.py
>> @@ -193,3 +193,22 @@ def test_efi_grub_net(u_boot_console):
>>
>>  # And give us our U-Boot prompt back
>>  u_boot_console.run_command('')
>> +
>> +@pytest.mark.buildconfigspec('cmd_bootefi')
>> +def test_efi_openbsd_net(u_boot_console):
>> +"""Run OpenBSD's bootloader via TFTP.
>> +
>> +The bootaa64.efi file is downloaded from the TFTP server and
>> +gets executed.
>> +"""
>> +
>> +addr = fetch_tftp_file(u_boot_console, 'env__efi_loader_openbsd_file')
>> +
>> +u_boot_console.run_command('bootefi %x' % addr, wait_for_prompt=False)
>> +
>> +# Check that bootloader loads properly:
>> +u_boot_console.wait_for('boot>')
>> +
>> +# There is no exit, but there is a reboot cmd.. maybe we need to do
>> +# more than this to get u-boot running again??
>> +u_boot_console.run_command('reboot', wait_for_prompt=False, 
>> wait_for_echo=False)
>> --
>> 2.13.0
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
>>
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] efi_loader: Add test to boot OpenBSD's efi bootloader

[Mark Kettenis]

> From: Rob Clark 
> Date: Sun,  6 Aug 2017 12:10:28 -0400
> 
> Signed-off-by: Rob Clark 
> ---
> Kinda works, but since we don't have an 'exit' command like grub, we
> have to reboot, which leaves the "board" in a bad state (I guess,
> since the next test fails).  I haven't tackled the travis bits to get
> travis to download OpenBSD's bootloader, or other little details like
> that.

What does the grub "exit" command do?  Simply call EFI_BOOT_SERVICE.Exit()?
Wouldn't be too difficult for me to add a command that does this.

The OpenBSD bootloader currently just executes an illegal instruction
as EFI_RUNTIME_SERVICES.ResetSystem() didn't work at the time I wrote
the code.  Perhaps I should revisit that issue now.

>  test/py/tests/test_efi_loader.py | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/test/py/tests/test_efi_loader.py 
> b/test/py/tests/test_efi_loader.py
> index 5d7f5dbfb2..376f6442a3 100644
> --- a/test/py/tests/test_efi_loader.py
> +++ b/test/py/tests/test_efi_loader.py
> @@ -193,3 +193,22 @@ def test_efi_grub_net(u_boot_console):
>  
>  # And give us our U-Boot prompt back
>  u_boot_console.run_command('')
> +
> +@pytest.mark.buildconfigspec('cmd_bootefi')
> +def test_efi_openbsd_net(u_boot_console):
> +"""Run OpenBSD's bootloader via TFTP.
> +
> +The bootaa64.efi file is downloaded from the TFTP server and
> +gets executed.
> +"""
> +
> +addr = fetch_tftp_file(u_boot_console, 'env__efi_loader_openbsd_file')
> +
> +u_boot_console.run_command('bootefi %x' % addr, wait_for_prompt=False)
> +
> +# Check that bootloader loads properly:
> +u_boot_console.wait_for('boot>')
> +
> +# There is no exit, but there is a reboot cmd.. maybe we need to do
> +# more than this to get u-boot running again??
> +u_boot_console.run_command('reboot', wait_for_prompt=False, 
> wait_for_echo=False)
> -- 
> 2.13.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Sun, Aug 6, 2017 at 2:47 PM, Rob Clark  wrote:
> On Sun, Aug 6, 2017 at 2:37 PM, Mark Kettenis  wrote:
>>> Date: Sun, 6 Aug 2017 20:21:45 +0200 (CEST)
>>> From: Mark Kettenis 
>>>
>>> > Mind sending me or pastebin'ing your u-boot .config?  There are some
>>> > different device-path construction depending on legacy vs
>>> > CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
>>> > by vexpress_ca15_tc2.. so I think it should work..)
>>>
>>> See below.  The Banana Pi (and all other sunxi boards) indeed uses the
>>> legacy code path.  And I think there is a bug in the legacy codepath
>>> where it encodes the partition in the "file" path component.
>>
>> If I fix the code to not insert the partition number there, I can boot
>> from SD card and SATA again.
>>
>> diff --git a/lib/efi_loader/efi_device_path.c 
>> b/lib/efi_loader/efi_device_path.c
>> index b5acf73f98..8ba0db2d7a 100644
>> --- a/lib/efi_loader/efi_device_path.c
>> +++ b/lib/efi_loader/efi_device_path.c
>> @@ -305,8 +305,8 @@ static void *dp_part_fill(void *buf, struct blk_desc 
>> *desc, int part)
>> struct efi_device_path_file_path *fp;
>> char devname[32] = { 0 }; /* fp->str is u16[32] long */
>>
>> -   snprintf(devname, sizeof(devname), "%d.%d.%d", desc->if_type,
>> -desc->devnum, part);
>> +   snprintf(devname, sizeof(devname), "%d.%d", desc->if_type,
>> +desc->devnum);
>>
>> memcpy(buf, , sizeof(ROOT));
>> buf += sizeof(ROOT);
>
>
> Hmm, that is probably not a good idea, since now the disk object along
> w/ partition objects will have same devicepath.  (One change from
> before is now we have diskobjs for the disk (part=0) and child
> diskobjs for each partition.. fwiw in UEFI terminology a
> efi_device_path_hard_drive_path is actually a partition.. for maximum
> confusion)

Oh, scratch that.. you are right, part shouldn't be in the string..
since it results in the children having different parent device paths.

(It is still probably a bit funny to file-paths for parent of the
partition objects.. I'll try to come up with something a bit better.)

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Sun, Aug 6, 2017 at 2:37 PM, Mark Kettenis  wrote:
>> Date: Sun, 6 Aug 2017 20:21:45 +0200 (CEST)
>> From: Mark Kettenis 
>>
>> > Mind sending me or pastebin'ing your u-boot .config?  There are some
>> > different device-path construction depending on legacy vs
>> > CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
>> > by vexpress_ca15_tc2.. so I think it should work..)
>>
>> See below.  The Banana Pi (and all other sunxi boards) indeed uses the
>> legacy code path.  And I think there is a bug in the legacy codepath
>> where it encodes the partition in the "file" path component.
>
> If I fix the code to not insert the partition number there, I can boot
> from SD card and SATA again.
>
> diff --git a/lib/efi_loader/efi_device_path.c 
> b/lib/efi_loader/efi_device_path.c
> index b5acf73f98..8ba0db2d7a 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -305,8 +305,8 @@ static void *dp_part_fill(void *buf, struct blk_desc 
> *desc, int part)
> struct efi_device_path_file_path *fp;
> char devname[32] = { 0 }; /* fp->str is u16[32] long */
>
> -   snprintf(devname, sizeof(devname), "%d.%d.%d", desc->if_type,
> -desc->devnum, part);
> +   snprintf(devname, sizeof(devname), "%d.%d", desc->if_type,
> +desc->devnum);
>
> memcpy(buf, , sizeof(ROOT));
> buf += sizeof(ROOT);


Hmm, that is probably not a good idea, since now the disk object along
w/ partition objects will have same devicepath.  (One change from
before is now we have diskobjs for the disk (part=0) and child
diskobjs for each partition.. fwiw in UEFI terminology a
efi_device_path_hard_drive_path is actually a partition.. for maximum
confusion)

Probably that we have a file-path node w/ child hard-drive objects is
confusing your previous workaround.. let me see if I can come up with
something better.

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Sun, Aug 6, 2017 at 2:21 PM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Sun, 6 Aug 2017 13:49:43 -0400
>>
>> On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis  
>> wrote:
>> >> From: Rob Clark 
>> >> Date: Sun, 6 Aug 2017 11:34:15 -0400
>> >>
>> >> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark  wrote:
>> >> >
>> >> > I've started trying to hack up test_efi_loader.py to add a test that
>> >> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
>> >> > since not a py expert or too familiar w/ u-boot's test framework.  But
>> >> > I'll see if I can get to the point where I can run the same thing on
>> >> > various arm7 and aarch64 devices in qemu.
>> >> >
>> >>
>> >> Making a bit of progress on this (running it on a vexpress_ca15_tc2
>> >> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>> >
>> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17=text/x-cvsweb-markup
>> >
>> > Your failure below looks a bit different from what I'm getting on the
>> > Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
>> > call in efi_main() fails.  Somehow the device path of the registered
>> > disk devices isn't matched correctly to the boot device path...
>>
>> that is.. odd.. mind adding in lib/efi_loader/Makefile:
>>
>>   ccflags-y += -DDEBUG=1
>>
>> ?
>>
>> (you can make the console output easier to read again w/ #undef DEBUG
>> at top of efi_console.c)
>>
>> With my complete patchset (ie. assuming this isn't in the middle of a
>> bisect between 13/20 and 15/20) the device paths for the diskobj and
>> EFI_LOADED_IMAGE::DeviceHandle should be constructed identically.
>> (Ie. the patchset consolidates the two different places it was
>> constructed before... and also fixes the thing I notice you work
>> around in efi_diskprobe())
>>
>> > BTW, the OpenBSD code runs fine without the alignment hack.  Our code
>> > is pretty minimal and doesn't actualy look into the device path
>> > components.  It just matches the components based on type and by soing
>> > memcmp.
>>
>> Hmm, well I do suspect there are still cases where u-boot could crash
>> because of unaligned access without the hack.  Although I'm less
>> convinced that we should need the hack on armv7 and more thinking this
>> is something specific about banana-pi (or allwinner?).  The
>> vexpress_ca15_tc2 "board" in qemu seems to be working properly..
>
> I suspect qemu simply doesn't emulate the alignment trap.  The u-boot
> startup code explicitly enables alignment fauls on armv7.  See
> arch/arm/cpu/armv7/start.S:152.  This helps catching bugs!

Hmm, that is a really bad idea with EFI_LOADER.. since the efi payload
is inheriting this setting.


BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: LocateHandle should return EFI_NOT_FOUND if none found

[Mark Kettenis]

> From: Rob Clark 
> Date: Sun,  6 Aug 2017 12:23:50 -0400
> 
> Spotted this debugging OpenBSD's bootloader in qemu.  (Wouldn't really
> fix anything, the problem was not having any disks, but we should
> probably return the correct error code.)
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Mark Kettenis 

> ---
>  lib/efi_loader/efi_boottime.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 5ff2d2d4b0..ada119325c 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -643,6 +643,9 @@ static efi_status_t EFIAPI efi_locate_handle(
>   }
>  
>   *buffer_size = size;
> + if (size == 0)
> + return EFI_NOT_FOUND;
> +
>   return EFI_SUCCESS;
>  }
>  
> -- 
> 2.13.0
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Mark Kettenis]

> Date: Sun, 6 Aug 2017 20:21:45 +0200 (CEST)
> From: Mark Kettenis 
> 
> > Mind sending me or pastebin'ing your u-boot .config?  There are some
> > different device-path construction depending on legacy vs
> > CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
> > by vexpress_ca15_tc2.. so I think it should work..)
> 
> See below.  The Banana Pi (and all other sunxi boards) indeed uses the
> legacy code path.  And I think there is a bug in the legacy codepath
> where it encodes the partition in the "file" path component.

If I fix the code to not insert the partition number there, I can boot
from SD card and SATA again.

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index b5acf73f98..8ba0db2d7a 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -305,8 +305,8 @@ static void *dp_part_fill(void *buf, struct blk_desc *desc, 
int part)
struct efi_device_path_file_path *fp;
char devname[32] = { 0 }; /* fp->str is u16[32] long */
 
-   snprintf(devname, sizeof(devname), "%d.%d.%d", desc->if_type,
-desc->devnum, part);
+   snprintf(devname, sizeof(devname), "%d.%d", desc->if_type,
+desc->devnum);
 
memcpy(buf, , sizeof(ROOT));
buf += sizeof(ROOT);
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Convert CONFIG_SYS_I2C_OMAP24XX et al to Kconfig

[Adam Ford]

On Thu, Jul 27, 2017 at 6:55 AM, Tom Rini  wrote:
> On Wed, Jul 26, 2017 at 09:22:06PM -0500, Adam Ford wrote:
>> On Wed, Jul 26, 2017 at 8:52 PM, Tom Rini  wrote:
>> > On Wed, Jul 26, 2017 at 09:03:37AM -0500, Adam Ford wrote:
>> >
>> >> This converts the following to Kconfig:
>> >>CONFIG_SYS_I2C_OMAP24XX
>> >>CONFIG_SYS_I2C_OMAP34XX
>> >>
>> >> Signed-off-by: Adam Ford 
>> >
>> > This needs some manual attention.  We should just drop
>> > CONFIG_SYS_I2C_OMAP24XX as it's meaningless now.  Also:
>> >
>> I thought the same thing, but I looked at the driver and the driver
>> has some explicit differences that are unique to the
>> CONFIG_SYS_I2C_OMAP34XX.
>>
>> As an example:
>> #if defined(CONFIG_OMAP34XX)
>> /*
>> * Have to enable interrupts for OMAP2/3, these IPs don't have
>> * an 'irqstatus_raw' register and we shall have to poll 'stat'
>> */
>> writew(I2C_IE_XRDY_IE | I2C_IE_RRDY_IE | I2C_IE_ARDY_IE |
>>   I2C_IE_NACK_IE | I2C_IE_AL_IE, _base->ie);
>> #endif
>>
>>
>>
>> The comment in the code even states there are some minor differences:
>>   "Status functions now read irqstatus_raw as per TRM guidelines
>> (except for OMAP243X and OMAP34XX)"
>>
>> So I think we need both.
>> Looking at the ti_omap4_common.h, it defines  CONFIG_SYS_I2C_OMAP24XX,
>> but not OMAP34XX, so it appears to me like we might want a naming
>> convention change.
>
> But nothing toggles off of SYS_I2C_OMAP24XX vs SYS_I2C_OMAP34XX is the
> key.  It might have back when we supported omap1/2 systems as well, but
> it doesn't today.  Everything inside the driver keys off of
> OMAP34XX/AM33XX/etc/etc now.
>

Got it.  That makes sense.  Since the name of the source files is
omap24xx_i2c.c/.h , would you object to dumping the
CONFIG_SYS_I2C_OMAP34XX in favor of keeping the
CONFIG_SYS_I2C_OMAP24XX for consistency?

adam

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

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Mark Kettenis]

> From: Rob Clark 
> Date: Sun, 6 Aug 2017 13:49:43 -0400
> 
> On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis  wrote:
> >> From: Rob Clark 
> >> Date: Sun, 6 Aug 2017 11:34:15 -0400
> >>
> >> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark  wrote:
> >> >
> >> > I've started trying to hack up test_efi_loader.py to add a test that
> >> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
> >> > since not a py expert or too familiar w/ u-boot's test framework.  But
> >> > I'll see if I can get to the point where I can run the same thing on
> >> > various arm7 and aarch64 devices in qemu.
> >> >
> >>
> >> Making a bit of progress on this (running it on a vexpress_ca15_tc2
> >> board in qemu).. any hint where I can find BOOTARM.EFI src code?
> >
> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17=text/x-cvsweb-markup
> >
> > Your failure below looks a bit different from what I'm getting on the
> > Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
> > call in efi_main() fails.  Somehow the device path of the registered
> > disk devices isn't matched correctly to the boot device path...
> 
> that is.. odd.. mind adding in lib/efi_loader/Makefile:
> 
>   ccflags-y += -DDEBUG=1
> 
> ?
> 
> (you can make the console output easier to read again w/ #undef DEBUG
> at top of efi_console.c)
> 
> With my complete patchset (ie. assuming this isn't in the middle of a
> bisect between 13/20 and 15/20) the device paths for the diskobj and
> EFI_LOADED_IMAGE::DeviceHandle should be constructed identically.
> (Ie. the patchset consolidates the two different places it was
> constructed before... and also fixes the thing I notice you work
> around in efi_diskprobe())
> 
> > BTW, the OpenBSD code runs fine without the alignment hack.  Our code
> > is pretty minimal and doesn't actualy look into the device path
> > components.  It just matches the components based on type and by soing
> > memcmp.
> 
> Hmm, well I do suspect there are still cases where u-boot could crash
> because of unaligned access without the hack.  Although I'm less
> convinced that we should need the hack on armv7 and more thinking this
> is something specific about banana-pi (or allwinner?).  The
> vexpress_ca15_tc2 "board" in qemu seems to be working properly..

I suspect qemu simply doesn't emulate the alignment trap.  The u-boot
startup code explicitly enables alignment fauls on armv7.  See
arch/arm/cpu/armv7/start.S:152.  This helps catching bugs!

> Mind sending me or pastebin'ing your u-boot .config?  There are some
> different device-path construction depending on legacy vs
> CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
> by vexpress_ca15_tc2.. so I think it should work..)

See below.  The Banana Pi (and all other sunxi boards) indeed uses the
legacy code path.  And I think there is a bug in the legacy codepath
where it encodes the partition in the "file" path component.

> If OpenBSD supports the vexpress boards, I guess with a suitable qemu
> -sd disk.img I should be able to try booting all the way to OS..

I think it does.  We don't have a "miniroot" image for it though.  It
might be possible to take 

  http://ftp.openbsd.org/pub/OpenBSD/snapshots/armv7/miniroot-cubie-61.fs

and dd the vexpress u-boot into the right location and copy the device
tree onto the msdos filesystem in that image.

#
# Automatically generated file; DO NOT EDIT.
# U-Boot 2017.09-rc1 Configuration
#
CONFIG_CREATE_ARCH_SYMLINK=y
# CONFIG_ARC is not set
CONFIG_ARM=y
# CONFIG_M68K is not set
# CONFIG_MICROBLAZE is not set
# CONFIG_MIPS is not set
# CONFIG_NDS32 is not set
# CONFIG_NIOS2 is not set
# CONFIG_PPC is not set
# CONFIG_SANDBOX is not set
# CONFIG_SH is not set
# CONFIG_X86 is not set
# CONFIG_XTENSA is not set
CONFIG_SYS_ARCH="arm"
CONFIG_SYS_CPU="armv7"
CONFIG_SYS_SOC="sunxi"
CONFIG_SYS_BOARD="sunxi"
CONFIG_SYS_CONFIG_NAME="sun7i"

#
# ARM architecture
#
CONFIG_HAS_VBAR=y
CONFIG_HAS_THUMB2=y
CONFIG_ARM_ASM_UNIFIED=y
CONFIG_CPU_V7=y
CONFIG_SYS_ARM_ARCH=7
CONFIG_SYS_CACHE_SHIFT_6=y
CONFIG_SYS_CACHELINE_SIZE=64
# CONFIG_ARM_SMCCC is not set
# CONFIG_SEMIHOSTING is not set
# CONFIG_SYS_THUMB_BUILD is not set
CONFIG_SPL_SYS_THUMB_BUILD=y
# CONFIG_SYS_L2CACHE_OFF is not set
# CONFIG_ENABLE_ARM_SOC_BOOT0_HOOK is not set
# CONFIG_ARM_CORTEX_CPU_IS_UP is not set
CONFIG_USE_ARCH_MEMCPY=y
CONFIG_SPL_USE_ARCH_MEMCPY=y
CONFIG_USE_ARCH_MEMSET=y
CONFIG_SPL_USE_ARCH_MEMSET=y
# CONFIG_ARM64_SUPPORT_AARCH32 is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_TARGET_EDB93XX is not set
# CONFIG_TARGET_ASPENITE is not set
# CONFIG_TARGET_GPLUGD is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_KIRKWOOD is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_TARGET_DEVKIT3250 is not set
# CONFIG_TARGET_WORK_92105 is not set
# CONFIG_TARGET_MX25PDK is not set
# CONFIG_TARGET_ZMX25 is not set
# 

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Peter Robinson]

On Sun, Aug 6, 2017 at 6:49 PM, Rob Clark  wrote:
> On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis  wrote:
>>> From: Rob Clark 
>>> Date: Sun, 6 Aug 2017 11:34:15 -0400
>>>
>>> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark  wrote:
>>> >
>>> > I've started trying to hack up test_efi_loader.py to add a test that
>>> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
>>> > since not a py expert or too familiar w/ u-boot's test framework.  But
>>> > I'll see if I can get to the point where I can run the same thing on
>>> > various arm7 and aarch64 devices in qemu.
>>> >
>>>
>>> Making a bit of progress on this (running it on a vexpress_ca15_tc2
>>> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>>
>> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17=text/x-cvsweb-markup
>>
>> Your failure below looks a bit different from what I'm getting on the
>> Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
>> call in efi_main() fails.  Somehow the device path of the registered
>> disk devices isn't matched correctly to the boot device path...
>
> that is.. odd.. mind adding in lib/efi_loader/Makefile:
>
>   ccflags-y += -DDEBUG=1
>
> ?
>
> (you can make the console output easier to read again w/ #undef DEBUG
> at top of efi_console.c)
>
> With my complete patchset (ie. assuming this isn't in the middle of a
> bisect between 13/20 and 15/20) the device paths for the diskobj and
> EFI_LOADED_IMAGE::DeviceHandle should be constructed identically.
> (Ie. the patchset consolidates the two different places it was
> constructed before... and also fixes the thing I notice you work
> around in efi_diskprobe())
>
>> BTW, the OpenBSD code runs fine without the alignment hack.  Our code
>> is pretty minimal and doesn't actualy look into the device path
>> components.  It just matches the components based on type and by soing
>> memcmp.
>
> Hmm, well I do suspect there are still cases where u-boot could crash
> because of unaligned access without the hack.  Although I'm less
> convinced that we should need the hack on armv7 and more thinking this
> is something specific about banana-pi (or allwinner?).  The
> vexpress_ca15_tc2 "board" in qemu seems to be working properly..

All AllWinner SoCs are Cortex-A series so ARMv7, in the case of the
banana pi series are AW A20s so are Cortex-A7 based so should be fine
too
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2] efi_loader: LocateHandle should return EFI_NOT_FOUND if none found

[Rob Clark]

Spotted this debugging OpenBSD's bootloader in qemu.  (Wouldn't really
fix anything, the problem was not having any disks, but we should
probably return the correct error code.)

Signed-off-by: Rob Clark 
---
v2: early-return in the EFI_NOT_FOUND case, as suggested by Heinrich

 lib/efi_loader/efi_boottime.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 5ff2d2d4b0..93ca05f3ef 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -633,6 +633,10 @@ static efi_status_t EFIAPI efi_locate_handle(
return EFI_BUFFER_TOO_SMALL;
}
 
+   *buffer_size = size;
+   if (size == 0)
+   return EFI_NOT_FOUND;
+
/* Then fill the array */
list_for_each(lhandle, _obj_list) {
struct efi_object *efiobj;
@@ -642,7 +646,6 @@ static efi_status_t EFIAPI efi_locate_handle(
}
}
 
-   *buffer_size = size;
return EFI_SUCCESS;
 }
 
-- 
2.13.0

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

Re: [U-Boot] [U-Boot, v4, 10/66] spl: dm: Kconfig: SPL_RAM depends on SPL_DM

[Philipp Tomsich]

> This commit models the dependency from SPL_RAM to SPL_DM in Kconfig.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/ram/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 5/6] rockchip: lion-rk3368: defconfig: enable DM timer for all stages

[Philipp Tomsich]

> There is no reasonably robust way (this will be needed so early that
> diagnostics will be limited) to specify the base-address of the secure
> timer through the DTS for TPL and SPL.  In order to allow us a cleaner
> way to structure our SPL and TPL stage, we now move to a DM timer
> driver.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  configs/lion-rk3368_defconfig | 4 
>  1 file changed, 4 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 61/66] spl: support TPL_STACK, TPL_MAX_SIZE and TPL_TEXT_BASE via Kconfig

[Philipp Tomsich]

> Let's clean up behind ourselves and move the (newly defined)
> TPL_STACK, TPL_MAX_SIZE and TPL_TEXT_BASE into Kconfig.  Given that
> 0x0 might be considered to be valid values for TPL_TEXT_BASE and
> TPL_STACK, we need to introduce helper config options
> ("TPL_NEEDS_SEPARATE_...") to indicate that these symbols are used
> (and not inherited from their SPL variants) for any given
> target-platform.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - moves TPL_STACK, TPL_MAX_SIZE and TPL_TEXT_BASE to Kconfig
> 
> Changes in v2: None
> 
>  common/spl/Kconfig | 39 +++
>  1 file changed, 39 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 12/66] spl: dm: Kconfig: SPL_CLK depends on SPL_DM

[Philipp Tomsich]

> SPL_CLK should also depend on SPL_DM (and not just on CLK).
> Add the additional dependency.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 54/66] rockchip: spl: make spl-boot-order code reusable (split from rk3399)

[Philipp Tomsich]

> In order to reuse the support for the u-boot,spl-boot-order property
> from the rk3399, we split it into a reusable module that can be
> included by the SPL code for any of our boards.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - added in v2
> 
>  arch/arm/mach-rockchip/Makefile   |   2 +-
>  arch/arm/mach-rockchip/rk3399-board-spl.c | 104 
>  arch/arm/mach-rockchip/spl-boot-order.c   | 108 
> ++
>  3 files changed, 109 insertions(+), 105 deletions(-)
>  create mode 100644 arch/arm/mach-rockchip/spl-boot-order.c
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 37/66] rockchip: pinctrl: rk3368: add SPI support

[Philipp Tomsich]

> To implement pinctrl support for the RK3368, we need to add the
> bit-definitions to configure the IOMUX and tie these into the
> pinctrl framework. This also adds the mapping from the IRQ# back
> onto the periheral id for the SPI devices.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - use symbolic constants for shift amount in IOMUX for SPI pinctrl
> - fixes a broken sentence in a comment
> 
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c | 118 
> ++
>  1 file changed, 118 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 16/66] armv8: move low-level assembly functions into function-sections

[Philipp Tomsich]

> TPL builds today don't need to call into firmware or set up the MMU
> (if this changes, it should be controlled through a config option
> whether to include this or not), but include the needed support code
> for this anyway.  By moving these unused low-level functions into
> seperate function-sections, the linker can garbage-collect the unused
> sections.
> 
> Note that (if DM support is enabled), there will be a call to the
> cache-flushing code from alloc_priv(...) in drivers/core/device.c.
> This then add 52 bytes of binary size (an increase from 20589 to 20641
> bytes) compared to completely removing this code.
> 
> Even for a feature-rich TPL (including DM support as for the RK3368),
> this equates to a size difference of significantly more than 10% in
> TPL binary size.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - removes spurious change to Makefile
> 
> Changes in v3:
> - change to use function-sections (instead of disabling at the
>   Makefile-level for TPL builds) per Tom's suggestion
> 
> Changes in v2: None
> 
>  arch/arm/cpu/armv8/cache.S  | 22 ++
>  arch/arm/cpu/armv8/tlb.S|  4 +++-
>  arch/arm/cpu/armv8/transition.S |  6 ++
>  3 files changed, 31 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 34/66] rockchip: pinctrl: rk3368: add GMAC (RGMII only) support

[Philipp Tomsich]

> To add GMAC (Gigabit Ethernet) support (limited to RGMII only at this
> point), we need support for additional pin-configuration.  This commit
> adds the pinctrl support for GMAC in RGMII mode:
>  * adds a PERIPH_ID_GMAC and the mapping from IRQ number to PERIPH_ID
>  * configures the RGMII pins
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - removed the RK3368-prefix on bit-definitions for GMAC pinctrl
> 
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c | 36 
> +++
>  1 file changed, 36 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 53/66] rockchip: rk3368: spl: add TPL support

[Philipp Tomsich]

> This adds the TPL support for the RK3368, including the u-boot-tpl.lds.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - removes the '#define DEBUG'
> - uses the syscon API to access GRF and SGRF to avoid using hard-coded
>   addresses
> 
> Changes in v2:
> - copies the enum for the IOMUX config of the debug UART into the TPL
>   support code, as the various constants are otherwise private to the
>   pinctrl code (and we can't include pinctrl in the TPL stage due to
>   size constraints/dependencies)
> 
>  arch/arm/mach-rockchip/Makefile  |   1 +
>  arch/arm/mach-rockchip/rk3368-board-tpl.c| 177 
> +++
>  arch/arm/mach-rockchip/rk3368/u-boot-tpl.lds |  13 ++
>  3 files changed, 191 insertions(+)
>  create mode 100644 arch/arm/mach-rockchip/rk3368-board-tpl.c
>  create mode 100644 arch/arm/mach-rockchip/rk3368/u-boot-tpl.lds
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 23/66] drivers: spl: consistently use the $(SPL_TPL_) macro

[Philipp Tomsich]

> To simplify drivers/Makefile a bit when using TPL/SPL, we consistently
> use the $(SPL_TPL_) macro to test for drivers that have separate
> configuration symbols for the full U-boot, SPL and TPL stages.
> Instead of explicitly repeating them in two separate if-guarded
> sections of the Makefile, we can now simply list these options once.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/Makefile | 36 
>  1 file changed, 16 insertions(+), 20 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 20/66] lib: spl: differentiate between TPL and SPL for libfdt/of_control/of_platdata

[Philipp Tomsich]

> This splits the compilation of code modules for TPL and SPL for
> OF_CONTROL (and related) features between TPL and SPL.  The typical
> use-case of this is a TPL stage that uses OF_PLATDATA at TPL and
> provides full OF_CONTROL at SPL (e.g. on the RK3368).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  lib/Makefile | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 39/66] rockchip: clk: rk3368: support OF_PLATDATA for the RK3368 clk driver

[Philipp Tomsich]

> With the RK3368's limited TPL size, we'll want to use OF_PLATFDATA for
> the SPL stage.  This implements support for OF_PLATDATA in the clock
> driver for the RK3368.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 17 +
>  1 file changed, 17 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Rob Clark]

On Sun, Aug 6, 2017 at 1:28 PM, Mark Kettenis  wrote:
>> From: Rob Clark 
>> Date: Sun, 6 Aug 2017 11:34:15 -0400
>>
>> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark  wrote:
>> >
>> > I've started trying to hack up test_efi_loader.py to add a test that
>> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
>> > since not a py expert or too familiar w/ u-boot's test framework.  But
>> > I'll see if I can get to the point where I can run the same thing on
>> > various arm7 and aarch64 devices in qemu.
>> >
>>
>> Making a bit of progress on this (running it on a vexpress_ca15_tc2
>> board in qemu).. any hint where I can find BOOTARM.EFI src code?
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17=text/x-cvsweb-markup
>
> Your failure below looks a bit different from what I'm getting on the
> Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
> call in efi_main() fails.  Somehow the device path of the registered
> disk devices isn't matched correctly to the boot device path...

that is.. odd.. mind adding in lib/efi_loader/Makefile:

  ccflags-y += -DDEBUG=1

?

(you can make the console output easier to read again w/ #undef DEBUG
at top of efi_console.c)

With my complete patchset (ie. assuming this isn't in the middle of a
bisect between 13/20 and 15/20) the device paths for the diskobj and
EFI_LOADED_IMAGE::DeviceHandle should be constructed identically.
(Ie. the patchset consolidates the two different places it was
constructed before... and also fixes the thing I notice you work
around in efi_diskprobe())

> BTW, the OpenBSD code runs fine without the alignment hack.  Our code
> is pretty minimal and doesn't actualy look into the device path
> components.  It just matches the components based on type and by soing
> memcmp.

Hmm, well I do suspect there are still cases where u-boot could crash
because of unaligned access without the hack.  Although I'm less
convinced that we should need the hack on armv7 and more thinking this
is something specific about banana-pi (or allwinner?).  The
vexpress_ca15_tc2 "board" in qemu seems to be working properly..

Mind sending me or pastebin'ing your u-boot .config?  There are some
different device-path construction depending on legacy vs
CONFIG_DM+CONFIG_BLK (the legacy case *looks* right to me, and is used
by vexpress_ca15_tc2.. so I think it should work..)

If OpenBSD supports the vexpress boards, I guess with a suitable qemu
-sd disk.img I should be able to try booting all the way to OS..

BR,
-R
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 36/66] rockchip: pinctrl: rk3368: move IOMUX bit-definitions to pinctrl driver

[Philipp Tomsich]

> There is no real reason to keep the bit-definitions for the IOMUX in
> the grf header file (which defines the register layout of the GRF block):
> these should only be used by our pinctrl driver (with the possible
> exception of early debug-init code in TPL/SPL).
> 
> This moves the relevant definitions from the grf_rk3368.h header
> into the pinctrl driver pinctrl_rk3368.c.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - moved bit-definitions pertinent to pinctrl (i.e. the various IOMUX
>   definitions) to the rk3368 pinctrl driver implementation
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 376 
> 
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c   | 366 +++
>  2 files changed, 366 insertions(+), 376 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 26/66] rockchip: rk3368: mkimage: add support for the RK3368

[Philipp Tomsich]

> This commit adds support for RK3368 SoC in mkimage.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  tools/rkcommon.c | 1 +
>  1 file changed, 1 insertion(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 6/6] rockchip: rk3368: remove setup of secure timer from TPL/SPL

[Philipp Tomsich]

> When using DM timers w/ the timer0 block within the RK3368, we no
> longer depend on the ARMv8 generic timer counting.  This allows us to
> drop the secure timer initialisation from the TPL and SPL stages.
> 
> The secure timer will later be set up by ATF, which starts the ARMv8
> generic timer.  Thus, there will be a dependency from Linux to the ATF
> through the ARMv8 generic timer... this seems reasonable, as Linux
> will require the ATF (and PSCI) to start up the secondary cores anyway
> (in other words: we don't add any new dependencies).
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3368-board-spl.c | 20 
>  arch/arm/mach-rockchip/rk3368-board-tpl.c | 19 ---
>  2 files changed, 39 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 1/6] timer: add OF_PLATDATA support for timer-uclass

[Philipp Tomsich]

> The timer-uclass depends on full OF_CONTROL through its interrogation
> of /chosen and the code to determine the clock-frequency.
> 
> For the OF_PLATDATA case, these code-paths are disabled and it becomes
> the timer driver's responsibility to correctly set the clock-frequency
> in the uclass priv-data.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2:
> - marks blob as maybe_unused (to accomodate the OF_CONTROL case w/o
>   warnings)
> 
>  drivers/timer/timer-uclass.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 60/66] rockchip: Kconfig: preset TPL_LDSCRIPT via Kconfig for the RK3368

[Philipp Tomsich]

> Set TPL_LDSCRIPT in Kconfig, so we don't have to pollute our
> header file.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - (added) sets TPL_LDSCRIPT via Kconfig
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig  | 7 +++
>  include/configs/rk3368_common.h | 2 --
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/3] spl: add hierarchical defaults for SPL_LDSCRIPT

[Philipp Tomsich]

> With SPL_LDSCRIPT moved to Kconfig (and this being a 'string' config
> node), all the lingering definitions in header files will cause errors
> due to the redefinition of the configuration item.
> 
> As we don't want to pollute the defconfig files (and values should
> usually be identical for entire architectures), the defaults are moved
> into Kconfig.  Kconfig will always pick the first default that
> matches, so please keep these values at the end of each file (to allow
> any board-specific Kconfig, which will be included earlier) to
> override with an unconditional default setting.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
>  arch/arm/Kconfig  | 12 
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig |  3 +++
>  arch/arm/mach-at91/Kconfig|  4 
>  arch/arm/mach-davinci/Kconfig |  4 
>  arch/arm/mach-exynos/Kconfig  |  3 +++
>  arch/arm/mach-omap2/Kconfig   |  3 +++
>  arch/arm/mach-orion5x/Kconfig |  3 +++
>  arch/arm/mach-sunxi/Kconfig   |  3 +++
>  arch/arm/mach-zynq/Kconfig|  3 +++
>  arch/microblaze/Kconfig   |  3 +++
>  board/armadeus/apf27/Kconfig  |  3 +++
>  board/freescale/mx31pdk/Kconfig   |  3 +++
>  board/spear/x600/Kconfig  |  3 +++
>  13 files changed, 50 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 2/6] dm: timer: normalise SPL and TPL support

[Philipp Tomsich]

> To fully support DM timer in SPL and TPL, we need a few things cleaned
> up and normalised:
> - inclusion of the uclass and drivers should be an all-or-nothing
>   decision for each stage and under control of $(SPL_TPL_)TIMER
>   instead of having the two-level configuration with TIMER and
>   $(SPL_TPL_)TIMER_SUPPORT
> - when $(SPL_TPL_)TIMER is enabled, the ARMv8 generic timer code can
>   not be compiled in
> 
> This normalises configuration to $(SPL_TPL_)TIMER and moves the config
> options to drivers/timer/Kconfig (and cleans up the collateral damage
> to some defconfigs that had SPL_TIMER_SUPPORT enabled).
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2: None
> 
>  arch/arm/cpu/armv8/Makefile |  2 ++
>  common/spl/Kconfig  |  8 
>  configs/chromebook_link64_defconfig |  2 +-
>  configs/qemu-x86_64_defconfig   |  2 +-
>  drivers/Makefile|  3 +--
>  drivers/timer/Kconfig   | 18 ++
>  drivers/timer/Makefile  |  2 +-
>  7 files changed, 24 insertions(+), 13 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v0 13/20] efi_loader: use proper device-paths for partitions

[Mark Kettenis]

> From: Rob Clark 
> Date: Sun, 6 Aug 2017 11:34:15 -0400
> 
> On Sun, Aug 6, 2017 at 10:45 AM, Rob Clark  wrote:
> >
> > I've started trying to hack up test_efi_loader.py to add a test that
> > loads OpenBSD's bootloader..  kinda muddling through it at this point,
> > since not a py expert or too familiar w/ u-boot's test framework.  But
> > I'll see if I can get to the point where I can run the same thing on
> > various arm7 and aarch64 devices in qemu.
> >
> 
> Making a bit of progress on this (running it on a vexpress_ca15_tc2
> board in qemu).. any hint where I can find BOOTARM.EFI src code?

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/armv7/stand/efiboot/efiboot.c?rev=1.17=text/x-cvsweb-markup

Your failure below looks a bit different from what I'm getting on the
Banana Pi now.  There I get stuck because the 2nd BS->HandleProtocol()
call in efi_main() fails.  Somehow the device path of the registered
disk devices isn't matched correctly to the boot device path...

BTW, the OpenBSD code runs fine without the alignment hack.  Our code
is pretty minimal and doesn't actualy look into the device path
components.  It just matches the components based on type and by soing
memcmp.

> => tftpboot 8040 obsdboot.efi
> smc911x: MAC 52:54:00:12:34:56
> smc911x: detected LAN9118 controller
> smc911x: phy initialized
> smc911x: MAC 52:54:00:12:34:56
> Using smc911x-0 device
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
> Filename 'obsdboot.efi'.
> Load address: 0x8040
> Loading: *%08#
> 12.4 MiB/s
> done
> Bytes transferred = 64908 (fd8c hex)
> smc911x: MAC 52:54:00:12:34:56
> => crc32 8040 $filesize
> CRC32 for 8040 ... 8040fd8b ==> a9ac4fcf
> => bootefi 8040
> ## Starting EFI application at 8040 ...
> WARNING: Invalid device tree, expect boot to fail
> BS->LocateHandle() returns 0
> undefined instruction
> pc : [<9eec65c4>]   lr : [<9eeca390>]
> sp : 9fed7a18  ip : 003f fp : 9fed7a2c
> r10:   r9 : 9eed4658 r8 : 
> r7 : 9eed1ce4  r6 : 9eed3538 r5 : 9fed7a6c  r4 : 9eed4658
> r3 :   r2 : 9eed2f8e r1 : 9eed1ee0  r0 : 
> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
> Resetting CPU ...
> 
> resetting ...
> 
> 
> U-Boot 2017.09-rc1-00025-g534695d189 (Aug 06 2017 - 06:58:16 -0400)
> 
> DRAM:  1 GiB
> WARNING: Caches not enabled
> Flash: 128 MiB
> MMC:   MMC: 0
> *** Warning - bad CRC, using default environment
> 
> In:serial
> Out:   serial
> Err:   serial
> Net:   smc911x-0
> Hit any key to stop autoboot:  2
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 63/66] rockchip: rk3368: mark TPL as not inheriting its stack, text-base and size from SPL

[Philipp Tomsich]

> The RK3368 needs to have a different base-address and stack-pointer
> for its TPL stage.  Now that we want to do this via Kconfig, we need
> to tick the appropriate 'TPL_NEEDS_...' boxes.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - use 'select if' for SPL/TPL presets that need SPL/TPL to avoid errors
>   on defconfig, if SPL/TPL is not enabled (thanks to Andy for noticing)
> 
> Changes in v3:
> - changes Kconfig, so RK3368 will notify the SPL configuration of
>   its need to have the TPL text-base, stack-pointer and max-size
>   configured
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 48/66] net: gmac_rockchip: Add support for the RK3368 GMAC

[Philipp Tomsich]

> The GMAC in the RK3368 once again is identical to the incarnation in
> the RK3288 and the RK3399, except for where some of the configuration
> and control registers are located in the GRF.
> 
> This adds the RK3368-specific logic necessary to reuse this driver.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> 
> Acked-by: Joe Hershberger 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - moves the bit-definitions (for GRF registers) specific to the GMAC
>   into the GMAC driver: these include interface speed selection and
>   configuring the RGMII output mode
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3368.h |  1 +
>  drivers/net/gmac_rockchip.c | 78 
> +
>  2 files changed, 79 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 22/66] spl: add TPL_DRIVER_MISC_SUPPORT option

[Philipp Tomsich]

> This adds the TPL_DRIVER_MISC_SUPPORT option to allow activation of
> DRIVER_MISC_SUPPORT for devices that need it in the TPL stage.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> 
> Version-changes: 3
> - removes TPL_MISC_DRIVERS_SUPPORT from the whitelist
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  common/spl/Kconfig   | 8 
>  scripts/config_whitelist.txt | 1 -
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 46/66] rockchip: clk: rk3368: mark 'priv' __maybe_unused in rk3368_clk_set_rate()

[Philipp Tomsich]

> With the clock support in rk3368_clk_set_rate() conditionalized on
> various feature definitions, 'priv' can remain unused (e.g. in the
> SPL build when only MMC is enabled).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 51/66] rockchip: rk3368: dts: add DMC node in rk3368.dtsi

[Philipp Tomsich]

> For full SPL support, including DRAM initialisation, we need a few
> nodes from the DTS: this commit adds the DMC (DRAM controller) node,
> the service_msch (memory scheduler) node and marks GRF, PMUGRF and CRU
> as 'u-boot,dm-pre-reloc'.  In addition to this, we also include the
> dt-binding for the DMC to allow DTS files including this DTSI to refer
> to the symbolic constants for the DDR3 bin and for the
> memory-schedule.
> 
> Note that the DMC contains both the memory regions for the
> (Designware) protocol controller as well as the DDR PHY.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - removes a 'u-boot,dm-pre-reloc' from dmc-node in rk3368.dtsi
> 
>  arch/arm/dts/rk3368.dtsi | 25 +++--
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 14/66] spl: dm: Kconfig: split OF_CONTROL and OF_PLATDATA between SPL and TPL

[Philipp Tomsich]

> For the RK3368, we want to use OF_PLATDATA in TPL, but full OF_CONTROL
> in SPL: this requires the introduction of a new family of
> configuration options to decouple SPL_OF_CONTROL and SPL_OF_PLATDATA
> from TPL.
> 
> Consequently, Makefile.spl needs to be adjusted to test for these
> configuration items through the $(SPL_TPL_) macro instead of
> hard-coding the SPL variant.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Makefile |  2 +-
>  dts/Kconfig  | 29 +
>  scripts/Makefile.spl |  4 ++--
>  3 files changed, 32 insertions(+), 3 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 41/66] rockchip: clk: rk3368: implement DPLL (DRAM PLL) support

[Philipp Tomsich]

> To implement a TPL stage (incl. its DRAM controller setup) for the
> RK3368, we'll want to configure the DPLL (DRAM PLL).
> 
> This commit implements setting the DPLL (CLK_DDR) and provides PLL
> configuration details for the common DRAM operating speeds found on
> RK3368 boards.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 35 +++
>  1 file changed, 35 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 49/66] rockchip: Makefile: streamline SPL/TPL configuration

[Philipp Tomsich]

> Handling TPL and SPL in the Makefile for mach-rockchip was based on
> nested if checks and/or if-else-if paths.  This can be simplified and
> made more readable by using $(SPL_TPL_) and by introducing
> intermediate variables for the aggregation of SPL and TPL features.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Makefile | 46 
> +
>  1 file changed, 28 insertions(+), 18 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 64/66] moveconfig: migrate TPL_STACK, TPL_TEXT_BASE and TPL_MAX_SIZE

[Philipp Tomsich]

> We can finally drop TPL_STACK, TPL_TEXT_BASE and TPL_MAX_SIZE off the
> whitelist (this time it's really happening!) and migrate the setting
> (only used on the RK3368-uQ7 so far) into Kconfig.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - migrate to Kconfig, so we don't need these in each defconfig
> 
> Changes in v3:
> - runs moveconfig.py TPL_STACK TPL_TEXT_BASE TPL_MAX_SIZE
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig  | 9 +
>  include/configs/rk3368_common.h | 4 
>  scripts/config_whitelist.txt| 3 ---
>  3 files changed, 9 insertions(+), 7 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 42/66] rockchip: clk: rk3368: define DMA1_SRST_REQ and DMA2_SRST_REQ

[Philipp Tomsich]

> On he RK3368, we need to temporarily disable security on the DMA
> engines during TPL and SPL to allow the MMC host to DMA into DRAM.  To
> do so, we need to reset the two DMA engines, which in turn requires
> the DMA1_SRST_REQ and DMA2_SRST_REQ constants to refer to the
> appropriate bits in the CRU.
> 
> As the ATF correctly initialises security (and only leaves EL3 after
> doing so), this can not pose a security issue.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/cru_rk3368.h | 4 
>  1 file changed, 4 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 09/66] spl: dm: Kconfig: split REGMAP/SYSCON support for TPL from SPL

[Philipp Tomsich]

> This change introduces TPL variants of the REGMAP and SYSCON config
> options (i.e. TPL_REGMAP and TPL_SYSCON in analogy to SPL_REGMAP and
> SPL_SYSCON) in preparation of a finer-grained feature selection for
> building feature-rich TPL variants.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/core/Kconfig  | 19 +++
>  drivers/core/Makefile |  4 ++--
>  2 files changed, 21 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 24/66] rockchip: Makefile: allow selective inclusion of sdram_common.o from TPL/SPL/U-Boot

[Philipp Tomsich]

> The utility functions in sdram_common.c will be useful both for some
> SPL implementations (and if unused, the linked will discard these
> anyway) and for the full U-Boot stage.
> 
> This changes selects sdram_common.o through the $(SPL_TPL_) macro to
> allow better control of its inclusion through the CONFIG_ROM,
> CONFIG_SPL_RAM or CONFIG_TPL_RAM options.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Makefile | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 21/66] spl: consistently use $(SPL_TPL_) to select features for SPL and TPL builds

[Philipp Tomsich]

> To allow for a finer-grained control of features for TPL and SPL
> builds all modules/boot-methods/etc. need to be consistently selected
> based on the $(SPL_TPL_) macros.
> 
> This allows splitting the associated config-options in Kconfig: we
> don't split the Kconfig options here and now, as this should happen on
> an as-needed basis, whenever someone needs a feature/boot-method/etc.
> in their TPL.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  common/Makefile |  8 
>  common/spl/Makefile | 36 ++--
>  2 files changed, 22 insertions(+), 22 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 15/66] spl: dm: use CONFIG_IS_ENABLED to test for the DM option

[Philipp Tomsich]

> Even though there's now a TPL_DM configuration option, the spl logic
> still checks for SPL_DM and thus does not pick up the proper config
> option.
> 
> This introduces the use of CONFIG_IS_ENABLED(DM) in spl.c to always
> pick up the desired configuration option instead of having a
> hard-coded check for the SPL variant.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  common/spl/spl.c|  5 +++--
>  include/linux/kconfig.h | 13 +
>  2 files changed, 16 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 08/66] spl: dm: Kconfig: use more specific prereqs for SPL_REGMAP and SPL_SYSCON

[Philipp Tomsich]

> SPL_REGMAP and SPL_SYSCON were marked as depending on DM, when a
> stricter dependency of SPL_DM was possible.  This commit makes the
> prereq more specific.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/core/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 47/66] rockchip: clk: rk3368: add support for configuring the SPI clocks

[Philipp Tomsich]

> As SPI support may be useful in the boot-flow, this adds support for
> configuring the SPI controller's clocks in the RK3368 clock driver.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Philipp Tomsich 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - added SPI clock setup
> 
>  drivers/clk/rockchip/clk_rk3368.c | 132 
> ++
>  1 file changed, 106 insertions(+), 26 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 4/6] dts: rk3368: make timer0 accessible for SPL and TPL

[Philipp Tomsich]

> To use it with the DM timer driver in SPL and TPL, timer0 needs to be
> marked as pre-reloc.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2:
> - add 'clock-frequency' prop to timer in the -u-boot.dtsi
> 
>  arch/arm/dts/rk3368-lion-u-boot.dtsi | 5 +
>  arch/arm/dts/rk3368.dtsi | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 59/66] spl: Kconfig: migrate $(SPL_TPL_)LDSCRIPT to Kconfig

[Philipp Tomsich]

> Now that we have split up SPL_LDSCRIPT into a SPL and TPL variant and
> have started to use the TPL-variant for the RK3368, it's time to clean
> up behind ourselves: move both variants into Kconfig and remove them
> from the whitelist.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - moves SPL_LDSCRIPT and TPL_LDSCRIPT into Kconfig, as requested by
>   by Tom; this gets rid of the whitelist-entry for SPL_LDSCRIPT (which
>   qualifies as a preexisting condition) and of the newly created one
>   for TPL_LDSCRIPT
> 
> Changes in v2: None
> 
>  common/spl/Kconfig   | 18 ++
>  scripts/Makefile.spl |  9 -
>  scripts/config_whitelist.txt |  2 --
>  3 files changed, 26 insertions(+), 3 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 57/66] rockchip: spi: enable support for the rk_spi driver for the RK3368

[Philipp Tomsich]

> For the RK3368, we can reuse the SPI driver (although we'll have to
> eventually investigate whether it can be merged with the
> designware_spi.c driver) also used for the RK3288 and RK3399.
> This adds the necessary compatible string to support the RK3368.
> 
> Note that the assumption that GPLL will be clocked at 594MHz is not
> true for the RK3368, but this will not lead to incorrect functioning
> (just to a lower-than-expected SPI operating frequency): this has been
> documented in the driver, so it doesn't cause any headaches when
> someone next needs to touch the clock code of this driver.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Version-changes: 2
> - added in this version
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/spi/rk_spi.c | 9 +
>  1 file changed, 9 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 33/66] rockchip: rk3368: dts: add sgrf node

[Philipp Tomsich]

> We will to drop device security temporarily (until the ATF initialises
> it fully) from the TPL/SPL stage: this requires access to some
> registers in the SGRF.
> 
> This adds the sgrf node to the rk3368.dtsi, so we can then bind a
> syscon device onto it and access its memory ranges.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/dts/rk3368.dtsi | 5 +
>  1 file changed, 5 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 28/66] rockchip: rk3368: spl: define COUNTER_FREQUENCY to 24MHz

[Philipp Tomsich]

> The BootROM of the RK3368 Boot ROM does not initialise cntfrq_el0.
> This change defines COUNTER_FREQUENCY, which is used by the AArch64 init
> code in arch/arm/cpu/armv8/start.S to set up cntfrq_el0.
> 
> If the counter-frequency is not correctly set up, the calculation of
> delays using the ARMv8 generic timer can not work correctly.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  include/configs/rk3368_common.h | 2 ++
>  1 file changed, 2 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 3/3] rockchip: rk3368: spl: move SPL_LDSCRIPT to Kconfig

[Philipp Tomsich]

> With the new way of doing things (i.e. the hierarchical selection of
> SPL_LDSCRIPT via Kconfig) in place, this moves the SPL_LDSCRIPT setting
> for the RK3368 from defconfig back into Kconfig.
> 
> With this done, there should be no lingering cases of SPL_LDSCRIPT
> outside of Kconfig files.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
>  arch/arm/mach-rockchip/rk3368/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 19/66] spl: Kconfig: split SYS_MALLOC_SIMPLE for TPL and SPL

[Philipp Tomsich]

> As include/malloc.h already checks for SYS_MALLOC_SIMPLE using the
> CONFIG_IS_ENABLED macro, we need to move to having separate entries
> as we switch to fully separate configuration for SPL and TPL.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  common/spl/Kconfig | 9 +
>  1 file changed, 9 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 30/66] rockchip: rk3368: syscon: MSCH/PMUGRF/GRF support for OF_PLATDATA

[Philipp Tomsich]

> The RK3368 has both a limited TPL size (just 0x7000 bytes) and the
> added challenge of booting in AArch64, which increases the code size
> for TPL (particularily when using the LP64 programming model).  For
> this reason we expect the RK3368 to always use OF_PLATDATA for its
> TPL stage.
> 
> This change adds support for the MSCH, PMUGRF and GRF register regions
> in syscon, which are necessary for initialising the RK3368's DRAM
> controller.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - commit message now correctly refers to TPL
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 35 
> +++
>  1 file changed, 35 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 29/66] rockchip: rk3368: spl: add memory layout for TPL and SPL

[Philipp Tomsich]

> For the RK3368, we use a multi-stage boot-process consisting of the
> following:
>   1.  TPL: initalises DRAM, returns to boot-ROM (which then loads
>the next stage and transfers control to it)
>   2.  SPL: a full-features SPL stage including OF_CONTROL and FIT
>image loading, which fetches the ATF, DTB and full U-Boot
>  and then transfers control to the ATF (using the BL31
>  parameter block to indicate the location of BL33/U-Boot)
>   3.  ATF: sets up the secure world and exits to BL33 (i.e. a full
>U-Boot) in the normal world
>   4.  full U-Boot
> 
> TPL/SPL and the full U-Boot are built from this tree and need to
> run from distinct text addresses and with distinct initial stack
> pointer addresses.
> 
> This commit sets up the configuration to run:
>   -  TPL from the SRAM at 0xff8c (note that the first 0x1000
>are reserved for use by the boot-ROM and contain the SP
>when the TPL is entered)
>   -  SPL from DRAM at 0x0
>   -  U-Boot from DRAM at 0x20
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  include/configs/rk3368_common.h | 11 +++
>  1 file changed, 11 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 44/66] rockchip: clk: rk3368: support configuring the DRAM PLL (from TPL)

[Philipp Tomsich]

> As part of the DRAM initialisation process (running as part of the TPL
> stage) on the RK3368, we need to set up the DRAM PLL.
> 
> This implements support for configuring the PLL to for 1200, 1332 or
> 1600 MHz (i.e. for DDR3-1200, DDR3-1333, DDR3-1600 operating modes).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 25/66] rockchip: rk3368: improve Kconfig text for the RK3368

[Philipp Tomsich]

> The RK3368 option in Kconfig referred to the RK3328 (copy-and-paste)
> and had a few typos and unnecessarily used UTF-8 characters.  While
> fixing this, I also reformatted and further clarified the text
> (e.g. made the grouping into a a big and little cluster of 4 cores
> each explicit).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig | 15 +--
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 27/66] rockchip: rk3368: pmugrf: add definitions for os_reg[0..3]

[Philipp Tomsich]

> On the RK3368 we use a TPL-stage similar to Rockchip's DDR init
> (i.e. it initialises DRAM, leaves some info for the next stage and
> returns to the BootROM).  To allow compatibility with Rockchip's DDR
> init code, we use the same register os_reg2 in pmugrf for passing
> this info (i.e. DRAM size and configuration) between stages.
> 
> This change adds the definitions for os_reg[0] through os_reg[3] to
> the pmugrf structure for the RK3368.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 38/66] rockchip: clk: rk3368: implement bandwidth adjust for PLLs

[Philipp Tomsich]

> The RK3368 TRM recommends to configure the bandwith adjustment (CON2)
> for PLLs to NF/2.  This implements this for all reconfigurations of
> PLLs and removes the 'has_bwadj' flag (as the RK3368 always has the
> bandwidth-adjustment feature according to its manual).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 43/66] rockchip: clk: rk3368: implement MMC/SD clock reparenting

[Philipp Tomsich]

> The original clock support for MMC/SD cards on the RK3368 suffered
> from a tendency to select a divider less-or-equal to the the one
> giving the requested clock-rate: this can lead to higher-than-expected
> (or rather: higher than supported) clock rates for the MMC/SD
> communiction.
> 
> This change rewrites the MMC/SD clock generation to:
>  * always generate a clock less-than-or-equal to the requested clock
>  * support reparenting among the CPLL, GPLL and OSC24M parents to
>generate the highest clock that does not exceed the requested rate
> 
> In addition to this, the Linux DTS uses HCLK_MMC/HCLK_SDMMC instead of
> SCLK_MMC/SCLK_SDMMC: to match this (and to ensure that clock setup
> always works), we adjust the driver appropriately.
> 
> This includes the changes from:
>  - rockchip: clk: rk3368: convert MMC_PLL_SEL_* definitions to shifted-value 
> form
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/cru_rk3368.h |   8 +-
>  drivers/clk/rockchip/clk_rk3368.c   | 119 
> ++--
>  2 files changed, 95 insertions(+), 32 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 13/66] spl: dm: Kconfig: split CLK support for SPL and TPL

[Philipp Tomsich]

> Introduce TPL_CLK to allow finer-grained selection of TPL features
> for feature-rich (i.e. DM-based) TPL stages.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/Kconfig  | 10 ++
>  drivers/clk/Makefile |  2 +-
>  2 files changed, 11 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 17/66] armv8: spl: Support separate stack for TPL

[Philipp Tomsich]

> To allow a TPL and SPL to run from different addresses/memories, we
> need to split setup of the TPL and SPL stacks.  To do so, we introduce
> CONFIG_TPL_STACK (not listed in Kconfig) which can be used to override
> the initial stack pointer for TPL.
> 
> To provide backward compatibility for existing boards, this is added
> as an optional configuration item and the normal search order (i.e.
> SPL_STACK, then SYS_STACK) apply if not defined.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/lib/crt0_64.S   | 4 +++-
>  scripts/config_whitelist.txt | 1 +
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] rockchip: rk3188: rock: adjust for SPL/TPL split

[Philipp Tomsich]

> With the changes to split SPL/TPL for the RK3368, I apparently missed
> some needed adjustments to the RK3188 Kconfig and rock_defconfig.
> 
> This fixes build-issues for the rock board after applying the RK3368
> enablement (and SPL/TPL) set that resulted from TPL_SERIAL_SUPPORT,
> TPL_ROCKCHIP_BACK_TO_BROM and TPL_TINY_MEMSET being separate symbols
> now.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
>  arch/arm/mach-rockchip/Makefile   | 4 +++-
>  arch/arm/mach-rockchip/rk3188/Kconfig | 3 ---
>  configs/rock_defconfig| 2 ++
>  lib/Kconfig   | 9 +
>  4 files changed, 14 insertions(+), 4 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 50/66] rockchip: rk3368: add DRAM controller driver with DRAM initialisation

[Philipp Tomsich]

> This adds a DRAM controller driver for the RK3368 and places it in
> drivers/ram/rockchip (where the other DM-enabled DRAM controller
> drivers for rockchip devices should also be moved eventually).
> 
> At this stage, only the following feature-set is supported:
>  - DDR3
>  - 32-bit configuration (i.e. fully populated)
>  - dual-rank (i.e. no auto-detection of ranks)
>  - DDR3-1600K speed-bin
> 
> This driver expects to run from a TPL stage that will later return to
> the RK3368 BROM.  It communicates with later stages through the
> os_reg2 in the pmugrf (i.e. using the same mechanism as Rockchip's DDR
> init code).
> 
> Unlike other DMC drivers for RK32xx and RK33xx parts, the required
> timings are calculated within the driver based on a target frequency
> and a DDR3 speed-bin (only the DDR3-1600K speed-bin is support at this
> time).
> 
> The RK3368 also has the DDRC0_CON0 (DDR ch. 0, control-register 0)
> register for controlling the operation of its (single-channel) DRAM
> controller in the GRF block.  This provides for selecting DDR3, mobile
> DDR modes, and control low-power operation.
> As part of this change, DDRC0_CON0 is also added to the GRF structure
> definition (at offset 0x600).
> 
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - updates pctl and phy reset sequences per feedback from t...@rock-chips.com
> 
> Changes in v3:
> - correctly states the location of the driver in the commit message
> 
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/ddr_rk3368.h|  187 
>  arch/arm/include/asm/arch-rockchip/grf_rk3368.h|3 +
>  arch/arm/mach-rockchip/rk3368/Makefile |1 -
>  arch/arm/mach-rockchip/rk3368/sdram_rk3368.c   |   60 --
>  .../clock/rockchip,rk3368-dmc.txt  |   67 ++
>  drivers/ram/Makefile   |2 +
>  drivers/ram/rockchip/Makefile  |7 +
>  drivers/ram/rockchip/dmc-rk3368.c  | 1007 
> 
>  include/dt-bindings/memory/rk3368-dmc.h|   30 +
>  9 files changed, 1303 insertions(+), 61 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-rockchip/ddr_rk3368.h
>  delete mode 100644 arch/arm/mach-rockchip/rk3368/sdram_rk3368.c
>  create mode 100644 doc/device-tree-bindings/clock/rockchip,rk3368-dmc.txt
>  create mode 100644 drivers/ram/rockchip/Makefile
>  create mode 100644 drivers/ram/rockchip/dmc-rk3368.c
>  create mode 100644 include/dt-bindings/memory/rk3368-dmc.h
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 31/66] rockchip: rk3368: syscon: SGRF support for OF_PLATDATA

[Philipp Tomsich]

> In TPL we will need to configure security in the SGRF of the RK3368.
> This change adds support for the SGRF as a syscon device, so we can
> retrieve its address range through the syscon API in TPL (and can
> avoid having to hard-code the address).
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - adds SGRF syscon support with OF_PLATDATA (to allow access to the
>   SGRF address range from TPL)
> 
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/rk3368/syscon_rk3368.c | 9 +
>  1 file changed, 9 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 45/66] rockchip: clk: rk3368: add support for GMAC (SLCK_MAC) clock

[Philipp Tomsich]

> To enable the GMAC on the RK3368, we need to set up the clocking
> appropriately to generate a tx_clk for the MAC.
> 
> This adds an implementation that implements the use of the <_gmac>
> clock (i.e. an external 125MHz clock for RGMII provided by the PHY).
> This is the clock setup used by the boards currently supported by
> U-Boot (i.e. Geekbox, Sheep and RK3368-uQ7).
> 
> This includes the change from commit
>  - rockchip: clk: rk3368: define GMAC_MUX_SEL_EXTCLK
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/include/asm/arch-rockchip/cru_rk3368.h |  3 +++
>  drivers/clk/rockchip/clk_rk3368.c   | 19 +--
>  2 files changed, 20 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 52/66] rockchip: rk3368: spl: enable SPL_FRAMEWORK in rk3368_common.h

[Philipp Tomsich]

> To build TPL and SPL stages for the RK3368, we will also need to
> enable the SPL_FRAMEWORK.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Version-changes: 2
> - dropped duplicate definition (this in fact dropped one of the
>   patches in this series) of CONFIG_SYS_SDRAM_BASE from
>   rk3368_common.h
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  include/configs/rk3368_common.h | 1 +
>  1 file changed, 1 insertion(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 40/66] rockchip: clk: rk3368: do not change CPLL/GPLL before returning to BROM

[Philipp Tomsich]

> The RK3368 has a somewhat temperamental BootROM (which I learned the
> hard way) when it comes to reconfiguring the CPLL and GPLL (in fact,
> experiments show that changing the GPLL broke things for me, while
> changing the CPLL seems to be more benign).  These should not be
> modified by the SPL stage, if we intend to return to the BootROM for
> chain booting the next stage.
> 
> This commit changes the clock initialisation to not change CPLL/GPLL
> before returning to the BootROM (i.e. in TPL).  As it's safe to change
> these settings if we no longer intend to return to U-Boot, we'll run
> the full PLL setup a little later (i.e. in SPL).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk_rk3368.c | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 56/66] rockchip: rk3368: spl: mark SPL and TPL as supported for ROCKCHIP_RK3368

[Philipp Tomsich]

> With SPL and TPL support for the RK3368 in place, mark SPL and TPL as
> supported from Kconfig for the RK3368.  As this is primarily tested on
> the RK3368-uQ7, we'll leave it to board's individual defconfig to
> enable.
> 
> Also enable DEBUG_UART_BOARD_INIT for the RK3368, so we get output
> during the early boot-up, as we turn on TPL and SPL.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - use imply for SPL/TPL preselects where SPL/TPL may not be enabled
>   to avoid warning on applying a defconfig (thanks to Andy for reporting)
> 
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig | 7 +++
>  1 file changed, 7 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 11/66] spl: dm: Kconfig: introduce TPL_RAM (in analogy to SPL_RAM)

[Philipp Tomsich]

> To allow finer grained selection of features for TPL, we introduce
> TPL_RAM (in analogy to SPL_RAM).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/ram/Kconfig | 9 +
>  1 file changed, 9 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 62/66] armv8: TPL_STACK will always be defined, so test CONFIG_TPL_NEEDS_SEPARATE_STACK

[Philipp Tomsich]

> Now that TPL_STACK has been moved off the whitelist (ok, I'm lying:
> the 'moving off the whitelist' part comes in once moveconfig
> runs... which will be a few commits down the line) and added to
> Kconfig, we need to test CONFIG_TPL_NEEDS_SEPARATE_STACK to see
> whether the value from TPL_STACK should be used or whether we try to
> inherit whatever SPL uses.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - changes the test to CONFIG_TPL_NEEDS_SEPARATE_STACK, as TPL_STACK
>   will be a hex-value now (and this always be defined)
> 
> Changes in v2: None
> 
>  arch/arm/lib/crt0_64.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 35/66] rockchip: pinctrl: rk3368: add support for configuring the MMC pins

[Philipp Tomsich]

> The RK3368 has two SD/MMC controllers that can be used from U-Boot
> both during SPL and for booting an OS from the full bootloader stage.
> While both are configured to (mostly) sensible settings from the BROM,
> additional configuration for the MMC controller is needed to configure
> it to 8bit mode.
> 
> This adds pinctrl support for the MMC controller.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - removed the RK3368 prefix on the SD/MMC pin definitions
> 
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c | 48 
> +++
>  1 file changed, 48 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 65/66] rockchip: board: puma-rk3399: fix warnings in puma_rk3399/fit_spl_atf.its

[Philipp Tomsich]

> The ITS file generated warnings due to @ designations in the naming
> which cause DTC to complain as follows:
>   Warning (unit_address_vs_reg): Node /images/uboot@1 has a unit name, but no 
> reg property
>   Warning (unit_address_vs_reg): Node /images/atf@1 has a unit name, but no 
> reg property
>   Warning (unit_address_vs_reg): Node /images/pmu@1 has a unit name, but no 
> reg property
>   Warning (unit_address_vs_reg): Node /images/fdt@1 has a unit name, but no 
> reg property
>   Warning (unit_address_vs_reg): Node /configurations/conf@1 has a unit name, 
> but no reg property
> 
> This removes the @ part from the names, as we only have a single
> image for each payload aspect (and only a single configuration) anyway.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v2, 3/6] rockchip: timer: add device-model timer driver for RK3368 (and similar)

[Philipp Tomsich]

> This adds a device-model driver for the timer block in the RK3368 (and
> similar devices that share the same timer block, such as the RK3288) for
> the down-counting (i.e. non-secure) timers.
> 
> This allows us to configure U-Boot for the RK3368 in such a way that
> we can run with the secure timer inaccessible or uninitialised (note
> that the ARMv8 generic timer does not count, if the secure timer is
> not enabled).
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v2:
> - remove the DEBUG (missed this initially, as there were no debug()
>   calls in the file anyway)
> - rework the reload_value code for improved readability
> - pull the uc_priv->clock_rate init into the OF_PLATDATA block
> 
>  drivers/timer/Kconfig  |   7 +++
>  drivers/timer/Makefile |   1 +
>  drivers/timer/rockchip_timer.c | 107 
> +
>  3 files changed, 115 insertions(+)
>  create mode 100644 drivers/timer/rockchip_timer.c
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 58/66] rockchip: board: lion-rk3368: add support for the RK3368-uQ7

[Philipp Tomsich]

> The RK3368-uQ7 (codenamed 'Lion') is a micro-Qseven (40mm x 70mm,
> MXM-230 edge connector compatible with the Qseven specification)
> form-factor system-on-module based on the octo-core Rockchip RK3368.
> It is designed, supported and manufactured by Theobroma Systems.
> 
> It provides the following features:
>  - 8x Cortex-A53 (in 2 clusters of 4 cores each)
>  - (on-module) up to 4GB of DDR3 memory
>  - (on-module) SPI-NOR flash
>  - (on-module) eMMC
>  - Gigabit Ethernet (with an on-module KSZ9031 PHY)
>  - USB
>  - HDMI
>  - MIPI-DSI/single-channel LVDS (muxed on the 'LVDS-A' pin-group)
>  - various 'slow' interfaces (e.g. UART, SPI, I2C, I2S, ...)
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - (after rebase) update defconfig
> - (after rebase and defconfig update) lion_rk3368.h: remove
>   CONFIG_ENV_IS_NOWHERE
> - moves remaining 'u-boot,dm-pre-reloc' to -u-boot.dtsi
> - marks sgrf-node as pre-reloc
> - defines SPL_LDSCRIPT and TPL_LDSCRIPT via defconfig
> 
> Changes in v2:
> - marks pinctrl-node as 'u-boot,dm-pre-reloc' to ensure MMC2 (eMMC)
>   works in the SPL stage
> - makes uart0 as 'u-boot,dm-pre-reloc' to allow initialising the
>   preloader console (instead of relying solely on the debug UART)
> - adds support for SPI1 (and the on-module SPI flash)
> - splits the a 'u-boot.dtsi' off the DTS file
> - updates the defconfig for SPI and SPI flash support
> 
>  arch/arm/dts/Makefile  |   1 +
>  arch/arm/dts/rk3368-lion-u-boot.dtsi   |  88 ++
>  arch/arm/dts/rk3368-lion.dts   | 195 
> +
>  arch/arm/dts/rk3368.dtsi   |   4 -
>  arch/arm/mach-rockchip/rk3368/Kconfig  |  21 +++
>  board/theobroma-systems/lion_rk3368/Kconfig|  15 ++
>  board/theobroma-systems/lion_rk3368/MAINTAINERS|  10 ++
>  board/theobroma-systems/lion_rk3368/Makefile   |   7 +
>  board/theobroma-systems/lion_rk3368/README |  60 +++
>  .../theobroma-systems/lion_rk3368/fit_spl_atf.its  |  51 ++
>  board/theobroma-systems/lion_rk3368/lion_rk3368.c  |  25 +++
>  configs/lion-rk3368_defconfig  |  92 ++
>  include/configs/lion_rk3368.h  |  18 ++
>  13 files changed, 583 insertions(+), 4 deletions(-)
>  create mode 100644 arch/arm/dts/rk3368-lion-u-boot.dtsi
>  create mode 100644 arch/arm/dts/rk3368-lion.dts
>  create mode 100644 board/theobroma-systems/lion_rk3368/Kconfig
>  create mode 100644 board/theobroma-systems/lion_rk3368/MAINTAINERS
>  create mode 100644 board/theobroma-systems/lion_rk3368/Makefile
>  create mode 100644 board/theobroma-systems/lion_rk3368/README
>  create mode 100644 board/theobroma-systems/lion_rk3368/fit_spl_atf.its
>  create mode 100644 board/theobroma-systems/lion_rk3368/lion_rk3368.c
>  create mode 100644 configs/lion-rk3368_defconfig
>  create mode 100644 include/configs/lion_rk3368.h
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 18/66] spl: allow a separate TEXT_BASE, LDSCRIPT and MAX_SIZE for TPL

[Philipp Tomsich]

> For the bringup of the RK3368, we need to support TPL and SPL running
> from different addresses... which requires both stages to use a
> distinct TEXT_BASE.
> 
> This commit adds support for having a separate LDSCRIPT for TPL (which
> is expected to make use of the TPL_MAX_SIZE define) and for having a
> the option of defining TPL_TEXT_BASE and having the TPL stage linked
> against this address.
> 
> Note that the handling of the TEXT_BASE is designed to not interfere
> with the previous assumption that SPL_TEXT_BASE should be used for TPL
> as well, unless TPL_TEXT_BASE is defined.  For this reason, the test
> in Makefile.spl uses the following (seemingly redundant checks):
>  1. looks for $(SPL_TPL_)TEXT_BASE
>  2. looks for SPL_TEXT_BASE (even when building in TPL)
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  scripts/Makefile.spl | 10 --
>  scripts/config_whitelist.txt |  3 +++
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 32/66] rockchip: rk3368: grf: use shifted-constants

[Philipp Tomsich]

> The RK3368 GRF header was still defines with a shifted-mask but with
> non-shifted function selectors for the IOMUX defines.  As the RK3368
> support is still fresh enough to allow a quick change, we do this now
> before having more code use this.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4:
> - restore the symbolic constant for the shift-values in the IOMUX
>   enums
> 
> Changes in v3: None
> Changes in v2:
> - dropped the RK3368_ prefix for the GRF constants
> 
>  arch/arm/include/asm/arch-rockchip/grf_rk3368.h | 413 
> ++--
>  drivers/pinctrl/rockchip/pinctrl_rk3368.c   |   9 +-
>  2 files changed, 242 insertions(+), 180 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 55/66] rockchip: rk3368: spl: add SPL support

[Philipp Tomsich]

> Adds SPL support for the RK3368 (assuming that our TPL stage has
> initialised DRAM and set up the memory firewall).
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - reuses the support for configuring the boot order using the
>   u-boot,spl-boot-order property
> - drops the initialisation of the debug_uart
> - adds pinctrl-configuration for the preloader UART
> 
>  arch/arm/mach-rockchip/Makefile   |  2 +-
>  arch/arm/mach-rockchip/rk3368-board-spl.c | 98 
> +++
>  2 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/mach-rockchip/rk3368-board-spl.c
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 66/66] rockchip: board: puma_rk3399: rename ATF firmware

[Philipp Tomsich]

> From: Klaus Goger 
> 
> prefix the bl31 firmware needed to build uboot.itb so it can coexist in
> the build area with ATFs from other boards (i.e. lion_rk3368)
> 
> Signed-off-by: Klaus Goger 
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Philipp Tomsich 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  board/theobroma-systems/puma_rk3399/README  | 2 +-
>  board/theobroma-systems/puma_rk3399/fit_spl_atf.its | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 07/66] spl: dm: Kconfig: fix help text for SPL/TPL confusion

[Philipp Tomsich]

> TPL_NAND_SUPPORT, TPL_SERIAL_SUPPORT, TPL_SPI_FLASH_SUPPORT and
> TPL_SPI_SUPPORT refer to SPL in their help text.  This fixes up
> the description to correctly reference TPL.
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> ---
> 
> Changes in v4: None
> Changes in v3:
> - (new patch) added fix-up of SPL/TPL confusion in help text
> 
> Changes in v2: None
> 
>  common/spl/Kconfig | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 02/66] spl: configure 'return to bootrom' separately for SPL and TPL

[Philipp Tomsich]

> On the RK3368, we want our TPL to use the 'return to bootrom' boot
> method (to have the bootrom load up the SPL stage) and then continue
> with different boot methods (MMC, SPI, etc.) from SPL.
> 
> This adds the config option needed to control the availabily of the
> 'return to bootrom' boot-method separately for the TPL stage.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  common/spl/Kconfig | 11 +++
>  1 file changed, 11 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 04/66] rockchip: back-to-bootrom: split BACK_TO_BOOTROM for TPL/SPL

[Philipp Tomsich]

> The back-to-bootrom option is rather unfortunately named
>   CONFIG_ROCKCHIP_SPL_BACK_TO_BOOTROM
> instead of
>   CONFIG_SPL_ROCKCHIP_BACK_TO_BOOTROM
> 
> To make is selectable through CONFIG_IS_ENABLED(ROCKCHIP_BACK_TO_BOOTROM),
> we need to rename it.  At the same time, we introduce a TPL_ variant of
> the option to give us finer-grained control over when it should be used.
> 
> This change is motivated by our RK3368 boot process, which returns to
> the boot ROM only from the TPL stage, but not from the SPL stage.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/Kconfig| 15 +--
>  arch/arm/mach-rockchip/rk3188-board-spl.c |  5 ++---
>  arch/arm/mach-rockchip/rk3188-board.c |  2 +-
>  arch/arm/mach-rockchip/rk3288-board-spl.c |  4 ++--
>  arch/arm/mach-rockchip/rk3288-board.c |  4 ++--
>  arch/arm/mach-rockchip/rk3399-board-spl.c |  4 ++--
>  configs/evb-rk3288_defconfig  |  2 +-
>  configs/fennec-rk3288_defconfig   |  2 +-
>  configs/firefly-rk3288_defconfig  |  2 +-
>  configs/miqi-rk3288_defconfig |  2 +-
>  configs/popmetal-rk3288_defconfig |  2 +-
>  configs/rock2_defconfig   |  2 +-
>  configs/rock_defconfig|  2 +-
>  configs/tinker-rk3288_defconfig   |  2 +-
>  doc/README.rockchip   |  2 +-
>  include/configs/rk3188_common.h   |  2 +-
>  include/configs/rk3288_common.h   |  2 +-
>  include/configs/rock.h|  2 +-
>  include/configs/rockchip-common.h |  2 +-
>  19 files changed, 35 insertions(+), 25 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 05/66] rockchip: back-to-bootrom: simplify the #ifdef-check for LIBGENERIC in TPL/SPL

[Philipp Tomsich]

> With the finer-grained control over LIBGENERIC_SUPPORT for TPL/SPL (i.e.
> with the newly introduced distinction between TPL_LIBGENERIC_SUPPORT and
> SPL_LIBGENERIC_SUPPORT), we can simplify the #ifdef-check to simply use
> CONFIG_IS_ENABELD.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/bootrom.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 06/66] spl: use TPL_SYS_MALLOC_F_LEN for TPL

[Philipp Tomsich]

> The (upstream) changes to break up SYS_MALLOC_F_LEN for the full
> U-Boot and the SPL stage, break TPL (if simple malloc is enabled in
> TPL).
> 
> This adds support for a TPL-variant of SYS_MALLOC_F_LEN:
> - adds TPL_SYS_MALLOC_F_LEN
> - rewrites a test for CONFIG_SPL_SYS_MALLOC_F_LEN to access
>   CONFIG_VAL(SYS_MALLOC_F_LEN)
> 
> Signed-off-by: Philipp Tomsich 
> Reviewed-by: Simon Glass 
> 
> Version-changes: 3
> - (new patch) adds changes to SYS_MALLOC_F_LEN for TPL to fix breakage
>   from rebasing to u-boot-rockchip/master
> 
> Version-changes: 4
> - changes (one-line) summary text
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  Kconfig  | 12 +++-
>  common/spl/spl.c |  2 +-
>  2 files changed, 12 insertions(+), 2 deletions(-)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4, 03/66] rockchip: back-to-bootrom: add 'back-to-bootrom' support for AArch64

[Philipp Tomsich]

> The back-to-bootrom support for Rockchip is equivalent to an
> (assembly) implementation of setjmp/longjmp (i.e. it saves the
> stack-pointer, link-register and callee-saved registers). Up until
> now, this had only been implemented for AArch32 (i.e. ARMv7 or older),
> which puts the new ARMv8 devices (which boot in AArch64 mode) at a
> slight disadvantage.
> 
> To allow use of the 'back-to-bootrom' feature on new devices (e.g. the
> RK3368), this commit adds an implementation for AArch64.
> 
> Signed-off-by: Philipp Tomsich 
> 
> Reviewed-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  arch/arm/mach-rockchip/save_boot_param.S | 37 
> 
>  1 file changed, 37 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/3] rockchip: set Pre-reloc malloc pool size to 4kb for rk3368 based boards

[Philipp Tomsich]

> The default 1kb pre-reloc malloc pool is not enough for dm
> core to enable the dm-pre-reloc device drivers.
> 
> Signed-off-by: Andy Yan 
> Acked-by: Philipp Tomsich 
> Reviewed-by: Philipp Tomsich 
> ---
> 
>  configs/evb-px5_defconfig  | 1 +
>  configs/geekbox_defconfig  | 1 +
>  configs/sheep-rk3368_defconfig | 1 +
>  3 files changed, 3 insertions(+)
> 

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot