Re: [U-Boot] [PATCH v2 15/28] phy: mt76x8-usb-phy: add slew rate calibration and remove non-mt7628 part

[Daniel Schwierzeck]

Am 18.09.19 um 04:15 schrieb Weijie Gao:
> This patch adds slew rate calibration for mt76x8-usb-phy, removes code
> which belongs to mt7620, and gets rid of using syscon and regmap by using
> clock driver and reset controller.
> 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/phy/Kconfig  |   2 +
>  drivers/phy/mt76x8-usb-phy.c | 225 ---
>  2 files changed, 159 insertions(+), 68 deletions(-)
> 
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 02312273e2..5c7b221431 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -200,6 +200,8 @@ config KEYSTONE_USB_PHY
>  config MT76X8_USB_PHY
>   bool "MediaTek MT76x8 (7628/88) USB PHY support"
>   depends on PHY
> + select CLK
> + select DM_RESET

in patch 27/28 you select those unconditionally for ARCH_MTMIPS. Thus
it's superfluous here. Maybe the depends on should be changed to PHY &&
ARCH_MTMIPS instead?

>   help
>Support the USB PHY in MT76x8 SoCs
>  
> diff --git a/drivers/phy/mt76x8-usb-phy.c b/drivers/phy/mt76x8-usb-phy.c
> index 268da8ef6c..1e7c5f334b 100644
> --- a/drivers/phy/mt76x8-usb-phy.c
> +++ b/drivers/phy/mt76x8-usb-phy.c
> @@ -6,93 +6,185 @@
>   * Copyright (C) 2017 John Crispin 
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> -#include 
> +#include 
>  #include 
> -
> -#define RT_SYSC_REG_SYSCFG1  0x014
> -#define RT_SYSC_REG_CLKCFG1  0x030
> -#define RT_SYSC_REG_USB_PHY_CFG  0x05c
> +#include 
>  
>  #define OFS_U2_PHY_AC0   0x800
> +#define USBPLL_FBDIV_S   16
> +#define USBPLL_FBDIV_M   GENMASK(22, 16)
> +#define BG_TRIM_S8
> +#define BG_TRIM_MGENMASK(11, 8)
> +#define BG_RBSEL_S   6
> +#define BG_RBSEL_M   GENMASK(7, 6)
> +#define BG_RASEL_S   4
> +#define BG_RASEL_M   GENMASK(5, 4)
> +#define BGR_DIV_S2
> +#define BGR_DIV_MGENMASK(3, 2)
> +#define CHP_EN   BIT(1)
> +
>  #define OFS_U2_PHY_AC1   0x804
> +#define VRT_VREF_SEL_S   28
> +#define VRT_VREF_SEL_M   GENMASK(30, 28)
> +#define TERM_VREF_SEL_S  24
> +#define TERM_VREF_SEL_M  GENMASK(26, 24)
> +#define USBPLL_RSVD  BIT(4)
> +#define USBPLL_ACCEN BIT(3)
> +#define USBPLL_LFBIT(2)
> +
>  #define OFS_U2_PHY_AC2   0x808
> +
>  #define OFS_U2_PHY_ACR0  0x810
> -#define OFS_U2_PHY_ACR1  0x814
> -#define OFS_U2_PHY_ACR2  0x818
> +#define HSTX_SRCAL_ENBIT(23)
> +#define HSTX_SRCTRL_S16
> +#define HSTX_SRCTRL_MGENMASK(18, 16)
> +
>  #define OFS_U2_PHY_ACR3  0x81C
> -#define OFS_U2_PHY_ACR4  0x820
> -#define OFS_U2_PHY_AMON0 0x824
> +#define HSTX_DBIST_S 28
> +#define HSTX_DBIST_M GENMASK(31, 28)
> +#define HSRX_BIAS_EN_SEL_S   20
> +#define HSRX_BIAS_EN_SEL_M   GENMASK(21, 20)
> +
>  #define OFS_U2_PHY_DCR0  0x860
> -#define OFS_U2_PHY_DCR1  0x864
> +#define PHYD_RESERVE_S   8
> +#define PHYD_RESERVE_M   GENMASK(23, 8)
> +#define CDR_FILT_S   0
> +#define CDR_FILT_M   GENMASK(3, 0)
> +
>  #define OFS_U2_PHY_DTM0  0x868
> -#define OFS_U2_PHY_DTM1  0x86C
> +#define FORCE_USB_CLKEN  BIT(25)
> +
> +#define OFS_FM_CR0   0xf00
> +#define FREQDET_EN   BIT(24)
> +#define CYCLECNT_S   0
> +#define CYCLECNT_M   GENMASK(23, 0)
>  
> -#define RT_RSTCTRL_UDEV  BIT(25)
> -#define RT_RSTCTRL_UHST  BIT(22)
> -#define RT_SYSCFG1_USB0_HOST_MODEBIT(10)
> +#define OFS_FM_MONR0 0xf0c
>  
> -#define MT7620_CLKCFG1_UPHY0_CLK_EN  BIT(25)
> -#define MT7620_CLKCFG1_UPHY1_CLK_EN  BIT(22)
> -#define RT_CLKCFG1_UPHY1_CLK_EN  BIT(20)
> -#define RT_CLKCFG1_UPHY0_CLK_EN  BIT(18)
> +#define OFS_FM_MONR1 0xf10
> +#define FRCK_EN  BIT(8)
>  
> -#define USB_PHY_UTMI_8B60M   BIT(1)
> -#define UDEV_WAKEUP  BIT(0)
> +#define U2_SR_COEF_7628  32
>  
>  struct mt76x8_usb_phy {
> - u32 clk;
>   void __iomem*base;
> - struct regmap   *sysctl;
> + struct clk  cg; /* for clock gating */
> + struct reset_ctlrst_phy;
>  };
>  
> -static void 

Re: [U-Boot] [PATCH v2 22/28] mmc: mtk-sd: add a dts property cd-active-high for builtin-cd mode

[Daniel Schwierzeck]

Am 18.09.19 um 04:15 schrieb Weijie Gao:
> This patch adds a dts property cd-active-high for builtin-cd mode to make
> it configurable instead of using hardcoded active-low.
> 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/mmc/mtk-sd.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
> index 7069fe8948..814a1b5fe9 100644
> --- a/drivers/mmc/mtk-sd.c
> +++ b/drivers/mmc/mtk-sd.c
> @@ -270,6 +270,7 @@ struct msdc_host {
>  
>   /* whether to use gpio detection or built-in hw detection */
>   bool builtin_cd;
> + bool cd_active_high;
>  
>   /* card detection / write protection GPIOs */
>  #if CONFIG_IS_ENABLED(DM_GPIO)
> @@ -852,7 +853,12 @@ static int msdc_ops_get_cd(struct udevice *dev)
>  
>   if (host->builtin_cd) {
>   val = readl(>base->msdc_ps);
> - return !(val & MSDC_PS_CDSTS);
> + val &= MSDC_PS_CDSTS;
> +
> + if (!host->cd_active_high)
> + val = !val;
> +
> + return val;

you could shorten this to

return !(val & MSDC_PS_CDSTS) ^ host->cd_active_high;

>   }
>  
>  #if CONFIG_IS_ENABLED(DM_GPIO)
> @@ -1355,6 +1361,7 @@ static int msdc_ofdata_to_platdata(struct udevice *dev)
>   host->latch_ck = dev_read_u32_default(dev, "latch-ck", 0);
>   host->r_smpl = dev_read_u32_default(dev, "r_smpl", 0);
>   host->builtin_cd = dev_read_u32_default(dev, "builtin-cd", 0);
> + host->cd_active_high = dev_read_bool(dev, "cd-active-high");
>  
>   return 0;
>  }
> 

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

Re: [U-Boot] [PATCH] net: Always build the string_to_enetaddr() helper

[Ondřej Jirman]

Hello, 

On Tue, Sep 17, 2019 at 09:22:20PM +, Joe Hershberger wrote:
> Hi Simon,
> 
> On Sat, Sep 14, 2019 at 1:55 PM Simon Goldschmidt
>  wrote:
> >
> > Joe Hershberger  schrieb am Sa., 14. Sep. 2019,
> > 20:46:
> >
> > > On Sat, Sep 14, 2019 at 1:32 PM Tom Rini  wrote:
> > > >
> > > > On Sat, Sep 14, 2019 at 04:05:44PM +0200, Ondřej Jirman wrote:
> > > > > Hi,
> > > > >
> > > > > On Fri, Sep 13, 2019 at 07:40:22PM -0500, Joe Hershberger wrote:
> > > > > > Part of the env cleanup moved this out of the environment code and
> > > into
> > > > > > the net code. However, this helper is sometimes needed even when the
> > > net
> > > > > > stack isn't included.
> > > > > >
> > > > > > Move the helper to lib/net_utils.c like it's similarly-purposed
> > > > > > string_to_ip(). Also rename the moved function to similar naming.
> > > > > >
> > > > > > Signed-off-by: Joe Hershberger 
> > > > > > Reported-by: Ondrej Jirman 
> > > > >
> > > > > I've tested the patch and it works, but I'be found other related
> > > issue, where
> > > > > u-boot thinks %pM will format a MAC address string, but it does just
> > > > > print out the pointer due to relevant functions being gated by
> > > CONFIG_CMD_NET
> > > > > guard in lib/vsprintf.c.
> > > > >
> > > > > The gating should probably be done so that it panics/halts the u-boot
> > > if gated
> > > > > pointer flags are used by u-boot code, because that will clearly be
> > > incorrect,
> > > > > without calling code ever knowing. This way the user will know that
> > > something
> > > > > is wrong and will have to fix the code.
> > > >
> > > > I'm not in favor of panic because of calling an unimplemented print
> > > > format character.  I guess we'll need to see what the size increase is
> > > > on un-guarding these formats and go from there.
> > >
> > > I'll look into it. I'm also not in favor of a panic.
> > >
> >
> > In lwIP, we're using macros for such format characters. Would it work to do
> > that here and make the compiler complain about an undefined symbol of the
> > macro for this extended format character isn't defined?
> 
> Maybe... Though, if we don't successfully police the usage of the
> macro, it won't help. I'd like to evaluate the code-size impact and
> maybe just always include it.

How about a one-time console warning if unsupported format modifier is used
at run-time, if panic is too aggressive?

Anything that will hint at the error, would be nice.

regards,
o.

> -Joe
> 
> > Regards,
> > Simon
> > ___
> > 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: Always build the string_to_enetaddr() helper

[Ondřej Jirman]

On Sat, Sep 14, 2019 at 02:29:11PM -0400, Tom Rini wrote:
> On Sat, Sep 14, 2019 at 04:05:44PM +0200, Ondřej Jirman wrote:
> > Hi,
> > 
> > On Fri, Sep 13, 2019 at 07:40:22PM -0500, Joe Hershberger wrote:
> > > Part of the env cleanup moved this out of the environment code and into
> > > the net code. However, this helper is sometimes needed even when the net
> > > stack isn't included.
> > > 
> > > Move the helper to lib/net_utils.c like it's similarly-purposed
> > > string_to_ip(). Also rename the moved function to similar naming.
> > > 
> > > Signed-off-by: Joe Hershberger 
> > > Reported-by: Ondrej Jirman 
> > 
> > I've tested the patch and it works, but I'be found other related issue, 
> > where
> > u-boot thinks %pM will format a MAC address string, but it does just
> > print out the pointer due to relevant functions being gated by 
> > CONFIG_CMD_NET
> > guard in lib/vsprintf.c.
> > 
> > The gating should probably be done so that it panics/halts the u-boot if 
> > gated
> > pointer flags are used by u-boot code, because that will clearly be 
> > incorrect,
> > without calling code ever knowing. This way the user will know that 
> > something
> > is wrong and will have to fix the code.
> 
> I'm not in favor of panic because of calling an unimplemented print
> format character.  I guess we'll need to see what the size increase is
> on un-guarding these formats and go from there.

OTOH, u-boot doesn't use snprintf everywhere, and uses sprintf quite liberally,
so:

  char buf[exepected_size_for_format_X];

  sprintf(buf, "%pX", some_pointer);

may conceivably overflow the buffer, because u-boot will format a generic
pointer there instead of what the developer expected (based on config
option, the dev may never tried disabling), so only some users may be affected
by silent or not so silent stack corruption.

I think this is unlikely atm, because all formats I inspected, seem to
produce longer strings than the 64-bit generic pointer formatting.

That was why I suggested the panic(), because it may not be just a superficial
formatting issue.

Anyway, you definitely want a loud error, rather than silently
passing incorrect/unexpected data somewhere where it matters, like DTB.

regards,
o.



> -- 
> Tom



> ___
> 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 v2] sunxi: H6: DRAM: Add support for half DQ

[Maxime Ripard]

Hi,

On Fri, Aug 23, 2019 at 07:24:04PM +0200, Jernej Skrabec wrote:
> Half DQ configuration seems to be very rare for H6 based boards/STBs,
> but exists nevertheless. Currently the only known product which needs
> this support is Tanix TX6 mini.
>
> This commit adds support for half DQ configuration. Code was tested
> for regressions on other configurations (OrangePi 3 1 GiB/LPDDR3, Tanix
> TX6 4 GiB/DDR3) and none were found.
>
> Thanks to Icenowy Zheng for help with this code.
>
> Reviewed-by: Andre Przywara 
> Tested-by: thomas graichen 
> Signed-off-by: Jernej Skrabec 

Reviewed-by: Maxime Ripard 

Jagan, can you pick that up?

Thanks!
Maxime


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

Re: [U-Boot] [PATCH v2] arm: dts: sync dts for Allwinner H6

[Maxime Ripard]

On Sun, Aug 25, 2019 at 06:04:18PM +0200, Clément Péron wrote:
> Sync Kernel DTS for Allwinner H6 boards.
>
> Drop /omit-if-no-ref/ keyword as it's not supported by U-boot.
>
> commit  Linux 5.3-rc4
>
> Signed-off-by: Clément Péron 

Acked-by: Maxime Ripard 

Maxime


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

Re: [U-Boot] [ANN] U-Boot v2019.10-rc3 released

[Matthias Brugger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 18/09/2019 16:25, Tom Rini wrote:
> On Wed, Sep 18, 2019 at 04:23:35PM +0200, Matthias Brugger wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>> 
>> Hi Tom,
>> 
>> On 27/08/2019 02:19, Tom Rini wrote:
>>> Hey all,
>>> 
>>> It's release day and here's v2019.10-rc3.  We're well into what should
>>> be the stabilization period at this point.  Going forward I am hoping
>>> for PRs that are bug fixes / regression fixes, Kconfig migrations or
>>> very self contained new boards and similar.  If you have a series is
>>> "big" but doesn't quite fit into that list, please let me know with a
>>> patchwork link to the series in reply here.  I'd like to get a handle
>>> on how much stuff like that it outstanding so that I can get an idea on
>>> what I should try and do about a "next" branch more often than I have
>>> and what rules might apply to it.
>>> 
>>> In terms of a changelog, git log --merges v2019.10-rc2..v2019.10-rc3 
>>> continues to look pretty good but the content there varies based on
>>> what was given to me in the PR.  So please, the more details in the
>>> request the better!
>>> 
>>> I'm still planning on doing -rc4 on September 9th and -rc5 on September
>>>  23rd with the release scheduled on October 7th.  Thanks all!
>>> 
>> 
>> I wasn't able to find a -rc4 tag in the git log. Did you postpone the 
>> publication of v2019.10-rc4?
> 
> Ah, so, thanks for bringing it up.  I did indeed fail to tag -rc4 on 
> schedule (missed my reminder) and didn't recall it until this past Monday.
> Things have been generally quiet, but there are a few fixes I do need to
> grab, and I'm just going to do -rc4 on the 23rd at this point.
> 

Perfect, thanks for the update :)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEiUuSfQSYnG8EMsBltDliWyzx00MFAl2CTcgACgkQtDliWyzx
00OUqRAAoPB4zHSK+xBNreog4wLcNtY6jRtZd6n6T91ZL/hilMl+PThvnoSIIvIm
JNkR5aqDpxwNNlT2IdCJngZ38dHndENNbkbLeFcj8qKoDFpDV0gKqXQcdehfF1H9
xIsybqbk6vvOZh0XuHD000mOOnFIkuou1eDtL1IAAad8mm+qPwhn6nAjlO9rHdIH
gJwAnxQxYYL4suyDzeWdNKFuRP1DAv92sCKWEWYc3XQMumtCQ6QVqmj8FfYgIfBy
96K76o3R4zdjOHwamusnHwQYpCQ0xdGk2fe2Gciy5jBUWcVsOoITDqMLB2afNnpU
4OBAHmlsQN7+Q1s3MhFEn1DhI6eFUm0P8ZnznmlUarsctLpsnLRvi2bOIUKvNa0L
505e8kx+vjrp9+snuDgzsQGmE0h9wU3aOZ9ZA2SBJiyEoeTjTYWXQZio/c0QcuEv
u7G4Mi4PkfCWdwhkbgwU1w6LUOOZ6taDa+uoOXMORHKcRXDUBsqx0lqL1y+JbWAq
Gcx9hF5pY13f6a6YtfUsc7NZ2V8eHXG18OSq/QFJ3JvLJljfqhZU8lA3by5AhWDK
YizE/7TSBTyMSab9pxk+K+ZTAUxwTzJ9XNWejDhIFxQfJ9VXo3SCLHh4OHN4QI8m
MPWEt68lePK3PON4rM/48V2jOQixN5y81jMtecQq+SwYxbJiOBg=
=R2Gs
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] libfdt: fix typo on comment

[Giulio Benetti]

Signed-off-by: Giulio Benetti 
---
 scripts/dtc/libfdt/libfdt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/dtc/libfdt/libfdt.h b/scripts/dtc/libfdt/libfdt.h
index cf86ddba88..53d577d2a8 100644
--- a/scripts/dtc/libfdt/libfdt.h
+++ b/scripts/dtc/libfdt/libfdt.h
@@ -734,7 +734,7 @@ uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
 /**
  * fdt_get_alias_namelen - get alias based on substring
  * @fdt: pointer to the device tree blob
- * @name: name of the alias th look up
+ * @name: name of the alias to look up
  * @namelen: number of characters of name to consider
  *
  * Identical to fdt_get_alias(), but only examine the first namelen
-- 
2.20.1

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

Re: [U-Boot] [PATCH V2] [RFC] usb: storage: Limit transfer size to 120 kiB

[Marek Vasut]

On 9/18/19 12:27 PM, Bin Meng wrote:
> On Wed, Sep 18, 2019 at 6:07 PM Marek Vasut  wrote:
>>
>> On 9/18/19 4:13 AM, Bin Meng wrote:
>>> On Tue, Sep 17, 2019 at 10:43 PM Marek Vasut  wrote:

 Due to constant influx of more and more weird and broken USB sticks,
 do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85

 usb: storage: scsiglue: further describe our 240 sector limit

 Just so we have some sort of documentation as to why
 we limit our Mass Storage transfers to 240 sectors,
 let's update the comment to make clearer that
 devices were found that would choke with larger
 transfers.

 While at that, also make sure to clarify that other
 operating systems have similar, albeit different,
 limits on mass storage transfers.

 And reduce the maximum transfer length of USB storage to 120 kiB.

 Signed-off-by: Marek Vasut 
 Cc: Bin Meng 
 Cc: Simon Glass 
 ---
 V2: Reshuffle the code a bit, always clamp the transfer size to 240 blocks
 ---
  common/usb_storage.c | 43 ++-
  1 file changed, 22 insertions(+), 21 deletions(-)

 diff --git a/common/usb_storage.c b/common/usb_storage.c
 index 8c889bb1a6..e1b539a082 100644
 --- a/common/usb_storage.c
 +++ b/common/usb_storage.c
 @@ -938,31 +938,32 @@ do_retry:
  static void usb_stor_set_max_xfer_blk(struct usb_device *udev,
   struct us_data *us)
  {
 -   unsigned short blk;
 -   size_t __maybe_unused size;
 -   int __maybe_unused ret;
 -
 -#if !CONFIG_IS_ENABLED(DM_USB)
 -#ifdef CONFIG_USB_EHCI_HCD
 /*
 -* The U-Boot EHCI driver can handle any transfer length as long as
 -* there is enough free heap space left, but the SCSI READ(10) and
 -* WRITE(10) commands are limited to 65535 blocks.
 +* Limit the total size of a transfer to 120 KB.
 +*
 +* Some devices are known to choke with anything larger. It seems 
 like
 +* the problem stems from the fact that original IDE controllers 
 had
 +* only an 8-bit register to hold the number of sectors in one 
 transfer
 +* and even those couldn't handle a full 256 sectors.
 +*
 +* Because we want to make sure we interoperate with as many 
 devices as
 +* possible, we will maintain a 240 sector transfer size limit for 
 USB
 +* Mass Storage devices.
 +*
 +* Tests show that other operating have similar limits with 
 Microsoft
 +* Windows 7 limiting transfers to 128 sectors for both USB2 and 
 USB3
 +* and Apple Mac OS X 10.11 limiting transfers to 256 sectors for 
 USB2
 +* and 2048 for USB3 devices.
  */
 -   blk = USHRT_MAX;
 -#else
 -   blk = 20;
 -#endif
 -#else
 +   unsigned short blk = 240;
 +
 +#if CONFIG_IS_ENABLED(DM_USB)
 +   size_t size;
 +   int ret;
 +
 ret = usb_get_max_xfer_size(udev, (size_t *));
 -   if (ret < 0) {
 -   /* unimplemented, let's use default 20 */
 -   blk = 20;
 -   } else {
 -   if (size > USHRT_MAX * 512)
 -   size = USHRT_MAX * 512;
 +   if ((ret >= 0) && (size < 240 * 512))
>>>
>>> size < blk * 512
>>>
 blk = size / 512;
 -   }
  #endif

 us->max_xfer_blk = blk;
 --
>>>
>>> Looks good otherwise
>>>
>>> Reviewed-by: Bin Meng 
>>
>> Fixed and added to next . This really needs a LOT of testing.
>> I am worried about performance here.
> 
> Agree. I was wondering how Linux managed to set such limit for all usb
> storage devices and no performance degradation reported?

I suspect they create a new QH/qTD chain during the transfer and load it
into the controller right when the previous one finishes.

> BTW: it looks you missed adding my "Reviewed-by"
> https://gitlab.denx.de/u-boot/custodians/u-boot-usb/commit/85a0cb96dabf7572db3c6726a276a48c5c77a9da

Should be fixed now.

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

Re: [U-Boot] [ANN] U-Boot v2019.10-rc3 released

[Tom Rini]

On Wed, Sep 18, 2019 at 04:23:35PM +0200, Matthias Brugger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi Tom,
> 
> On 27/08/2019 02:19, Tom Rini wrote:
> > Hey all,
> > 
> > It's release day and here's v2019.10-rc3.  We're well into what should be
> > the stabilization period at this point.  Going forward I am hoping for PRs
> > that are bug fixes / regression fixes, Kconfig migrations or very self
> > contained new boards and similar.  If you have a series is "big" but
> > doesn't quite fit into that list, please let me know with a patchwork link
> > to the series in reply here.  I'd like to get a handle on how much stuff
> > like that it outstanding so that I can get an idea on what I should try and
> > do about a "next" branch more often than I have and what rules might apply
> > to it.
> > 
> > In terms of a changelog, git log --merges v2019.10-rc2..v2019.10-rc3 
> > continues to look pretty good but the content there varies based on what 
> > was given to me in the PR.  So please, the more details in the request the
> > better!
> > 
> > I'm still planning on doing -rc4 on September 9th and -rc5 on September 
> > 23rd with the release scheduled on October 7th.  Thanks all!
> > 
> 
> I wasn't able to find a -rc4 tag in the git log. Did you postpone the
> publication of v2019.10-rc4?

Ah, so, thanks for bringing it up.  I did indeed fail to tag -rc4 on
schedule (missed my reminder) and didn't recall it until this past
Monday.  Things have been generally quiet, but there are a few fixes I
do need to grab, and I'm just going to do -rc4 on the 23rd at this
point.

-- 
Tom


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

Re: [U-Boot] [ANN] U-Boot v2019.10-rc3 released

[Matthias Brugger]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Tom,

On 27/08/2019 02:19, Tom Rini wrote:
> Hey all,
> 
> It's release day and here's v2019.10-rc3.  We're well into what should be
> the stabilization period at this point.  Going forward I am hoping for PRs
> that are bug fixes / regression fixes, Kconfig migrations or very self
> contained new boards and similar.  If you have a series is "big" but
> doesn't quite fit into that list, please let me know with a patchwork link
> to the series in reply here.  I'd like to get a handle on how much stuff
> like that it outstanding so that I can get an idea on what I should try and
> do about a "next" branch more often than I have and what rules might apply
> to it.
> 
> In terms of a changelog, git log --merges v2019.10-rc2..v2019.10-rc3 
> continues to look pretty good but the content there varies based on what 
> was given to me in the PR.  So please, the more details in the request the
> better!
> 
> I'm still planning on doing -rc4 on September 9th and -rc5 on September 
> 23rd with the release scheduled on October 7th.  Thanks all!
> 

I wasn't able to find a -rc4 tag in the git log. Did you postpone the
publication of v2019.10-rc4?

Regards,
Matthias

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

iQIzBAEBCAAdFiEEiUuSfQSYnG8EMsBltDliWyzx00MFAl2CPeQACgkQtDliWyzx
00PJEg/+KkTKsFn30hziVl+b1aAJOk4pFQBZ8TLPfhB2ZLDGDHRD0sZS9nHcKCTf
TetS9ljYn/g/VNJWtRuJhBkTyx9s03pjDEO43Mmnuj+LC7FAOXQ9QnFkfH5DYl4x
dDuA109RIgdMH8GpD1Mszc8ekj6Md1F8WwN0151WCteh269wabSpcEXzgms9eSRm
zQ95DAYN5l6JkU2ebRxcRnEWsjmHJyVEuObIJzUrCg7zi2rybVVukcjg40EVZWAq
QjbpnD4b1FkA2grOMUSQ4KCMgsDRutKPp1Jk7/SaebtMMjvjbWkJhMIsa5CfihNJ
UlqVkIkxP9evwdUQmBDluMK5CWDxHMdSp0r0mqEonQUG779j027lootriMd/Izsh
UD6+Wyu+W1iyDmDfBoBui4e0ssOiWKACdE8Cp0XLzk7Nj8VTzXh1sl7JuKNDch5X
vL+/669c+tXPlaAx1yCLwk817muqo/1Hd1SZcJZufrmNro9q68zXR2dWhOEgKomo
ULqYlOg5y/MOZZf95VeE8UWa2Y4LQ5pUr0p1iVMG6XIfR9mpYyQTIBTgpjT3XOXX
Ei9V3WklokGTzEzgVP/DQNOU1DgnfGVReVXEmuO5fXrHdgu4TZxzVbTgujDdwgNd
WP+nR67keJh4C91P8cmqi0jpKGZbfsOaZBs5z/HoaJ1n94tysZE=
=ituH
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] rsa: Return immediately if required-key verification fails

[Philippe Reynes]

From: Daniele Alessandrelli 

Currently, if image verification with a required key fails, rsa_verify()
code tries to find another key to verify the FIT image. This however, is
not the intended behavior as the documentation says that required keys
"must be verified for the image / configuration to be considered valid".

This patch fixes the issue by making rsa_verify() return immediately if
the verification of a required key fails.

Signed-off-by: Daniele Alessandrelli 
---
 lib/rsa/rsa-verify.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 287fcc4..82dc513 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -437,8 +437,7 @@ int rsa_verify(struct image_sign_info *info,
if (info->required_keynode != -1) {
ret = rsa_verify_with_keynode(info, hash, sig, sig_len,
info->required_keynode);
-   if (!ret)
-   return ret;
+   return ret;
}
 
/* Look for a key that matches our hint */
-- 
2.7.4

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

[U-Boot] [PATCH 0/2] rsa signature: check that required key is really mandatory

[Philippe Reynes]

This serie fix an issue with the required key on rsa signature. If a required
key is defined, only FIT signed with this key should be accepted. right now,
there is an issue with required key, u-boot may used others key than required
key.

The first commit add a test in vboot to check that u-boot don't allow FIT with
another key than the required key. This test fails and show the issue.
The second commit fix this issue with required key, so the test with required
key succeed.

Daniele Alessandrelli (1):
  rsa: Return immediately if required-key verification fails

Philippe Reynes (1):
  pytest: vboot: add a test for required key

 lib/rsa/rsa-verify.c   |  3 +-
 test/py/tests/test_vboot.py| 57 ++
 .../tests/vboot/sign-configs-sha256-pss-prod.its   | 46 +
 3 files changed, 104 insertions(+), 2 deletions(-)
 create mode 100644 test/py/tests/vboot/sign-configs-sha256-pss-prod.its

-- 
2.7.4

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

[U-Boot] [PATCH 1/2] pytest: vboot: add a test for required key

[Philippe Reynes]

This commit add a test in the vboot test to check that
when a required key is asked, only FIT signed with this
key is used/accepted by u-boot.

Signed-off-by: Philippe Reynes 
---
 test/py/tests/test_vboot.py| 57 ++
 .../tests/vboot/sign-configs-sha256-pss-prod.its   | 46 +
 2 files changed, 103 insertions(+)
 create mode 100644 test/py/tests/vboot/sign-configs-sha256-pss-prod.its

diff --git a/test/py/tests/test_vboot.py b/test/py/tests/test_vboot.py
index 4627ceb..9c41ee5 100644
--- a/test/py/tests/test_vboot.py
+++ b/test/py/tests/test_vboot.py
@@ -80,6 +80,8 @@ def test_vboot(u_boot_console):
 assert(expect_string in ''.join(output))
 if boots:
 assert('sandbox: continuing, as we cannot run' in ''.join(output))
+else:
+assert('sandbox: continuing, as we cannot run' not in 
''.join(output))
 
 def make_fit(its):
 """Make a new FIT from the .its source file.
@@ -106,6 +108,20 @@ def test_vboot(u_boot_console):
 util.run_and_log(cons, [mkimage, '-F', '-k', tmpdir, '-K', dtb,
 '-r', fit])
 
+def sign_fit_norequire(sha_algo):
+"""Sign the FIT
+
+Signs the FIT and writes the signature into it. It also writes the
+public key into the dtb.
+
+Args:
+sha_algo: Either 'sha1' or 'sha256', to select the algorithm to
+use.
+"""
+cons.log.action('%s: Sign images' % sha_algo)
+util.run_and_log(cons, [mkimage, '-F', '-k', tmpdir, '-K', dtb,
+fit])
+
 def replace_fit_totalsize(size):
 """Replace FIT header's totalsize with something greater.
 
@@ -195,6 +211,35 @@ def test_vboot(u_boot_console):
 util.run_and_log_expect_exception(cons, [fit_check_sign, '-f', fit,
 '-k', dtb], 1, 'Failed to verify required signature')
 
+def test_required_key(sha_algo, padding):
+"""Test verified boot with the given hash algorithm.
+
+This function test if u-boot reject an image when a required
+key isn't used to sign a FIT.
+
+Args:
+sha_algo: Either 'sha1' or 'sha256', to select the algorithm to
+use.
+"""
+# Compile our device tree files for kernel and U-Boot. These are
+# regenerated here since mkimage will modify them (by adding a
+# public key) below.
+dtc('sandbox-kernel.dts')
+dtc('sandbox-u-boot.dts')
+
+# Build the FIT with prod key (keys required)
+# Build the FIT with dev key (keys NOT required)
+# The dtb contain the key prod and dev and the key prod are set as 
required.
+# Then try to boot the FIT with dev key
+# This FIT should not be accepted by u-boot because the key prod is 
required
+cons.log.action('%s: Test FIT with configs images' % sha_algo)
+make_fit('sign-configs-%s%s-prod.its' % (sha_algo , padding))
+sign_fit(sha_algo)
+make_fit('sign-configs-%s%s.its' % (sha_algo , padding))
+sign_fit(sha_algo)
+
+run_bootm(sha_algo, 'signed configs', '', False)
+
 cons = u_boot_console
 tmpdir = cons.config.result_dir + '/'
 tmp = tmpdir + 'vboot.tmp'
@@ -217,6 +262,17 @@ def test_vboot(u_boot_console):
 util.run_and_log(cons, 'openssl req -batch -new -x509 -key %sdev.key -out '
  '%sdev.crt' % (tmpdir, tmpdir))
 
+# Create an RSA key pair (prod)
+public_exponent = 65537
+util.run_and_log(cons, 'openssl genpkey -algorithm RSA -out %sprod.key '
+ '-pkeyopt rsa_keygen_bits:2048 '
+ '-pkeyopt rsa_keygen_pubexp:%d' %
+ (tmpdir, public_exponent))
+
+# Create a certificate containing the public key (prod)
+util.run_and_log(cons, 'openssl req -batch -new -x509 -key %sprod.key -out 
'
+ '%sprod.crt' % (tmpdir, tmpdir))
+
 # Create a number kernel image with zeroes
 with open('%stest-kernel.bin' % tmpdir, 'w') as fd:
 fd.write(5000 * chr(0))
@@ -230,6 +286,7 @@ def test_vboot(u_boot_console):
 test_with_algo('sha1','-pss')
 test_with_algo('sha256','')
 test_with_algo('sha256','-pss')
+test_required_key('sha256','-pss')
 finally:
 # Go back to the original U-Boot with the correct dtb.
 cons.config.dtb = old_dtb
diff --git a/test/py/tests/vboot/sign-configs-sha256-pss-prod.its 
b/test/py/tests/vboot/sign-configs-sha256-pss-prod.its
new file mode 100644
index 000..aac732e
--- /dev/null
+++ b/test/py/tests/vboot/sign-configs-sha256-pss-prod.its
@@ -0,0 +1,46 @@
+/dts-v1/;
+
+/ {
+   description = "Chrome OS kernel image with one or more FDT blobs";
+   #address-cells = <1>;
+
+   images {
+   kernel {
+   data = /incbin/("test-kernel.bin");
+   type = 

[U-Boot] Verified boot interrogation

[Roger Clark]

Hello everyone,

After studying the verified boot feature I have some interrogations.

If my understanding is correct the procedure should be the following :
1) Generate private keys and certificate
2) Generate a uboot and a dts file to describe the key
3) Generate a kernel/dtb/ramdisk and an its file to describe the fit image
(files + conf + signatures)
4) Signature of the fit image and creation of a u-boot dtb file containing
the public key
5) Insertion of the uboot dtb file in the uboot binary

A am I correct so far ?

My question is why the step 4 is not divided in two steps ? I don't
understand why the public key generation needs the fit image as input.This
creates a link between uboot and the kernel and I don't see how I can flash
a new kernel without re-flashing a linked uboot.

The thing is I don't want to update uboot as often as the kernel.

Sorry if this is a stupid question..

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

[U-Boot] fpga spi on uboot driver

[jérémy alcim]

hi,

I search how to make a multiplexing for my unstandar spi on my fpga.
why ? because my spi register are 1 slot more.
this slot is a sublayer for non standard connection data bus selector.
I have 1 card connected at 4 card by my spi implementation.
i want to use my spi chip on the fpga with the standard  command.
Then for that i make a spi driver.
on this driver i need to make 4 udevice (for only 1 spi chip on
device-tree).
why ? because i want set my registre slot for select the good data bus,
then for select the good card connected on him.
I have make a simple command who work, but its not approved by ma boss...
He want use the standard interface with the unstandard spi hardware.

I search find 2 week... but not find how to do.
Are you an idea for make 4 spi on uboot with only 1 on device-tree ?
Actually i write 4 time the same device on dts...
Then i run 4 time the driver... its not good...

Thanks for reading with my bad english ^^.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/28] pinctrl: add support for MediaTek MT7628

[Daniel Schwierzeck]

Am 18.09.19 um 04:15 schrieb Weijie Gao:
> This patch adds pinctrl support for mt7628, with a file for common pinmux
> functions and a file for mt7628 which has additional support for pinconf.
> 
> Signed-off-by: Weijie Gao 
> ---
>  drivers/pinctrl/Kconfig   |   1 +
>  drivers/pinctrl/Makefile  |   1 +
>  drivers/pinctrl/mtmips/Kconfig|  13 +
>  drivers/pinctrl/mtmips/Makefile   |   7 +
>  drivers/pinctrl/mtmips/pinctrl-mt7628.c   | 585 ++
>  .../pinctrl/mtmips/pinctrl-mtmips-common.c|  87 +++
>  .../pinctrl/mtmips/pinctrl-mtmips-common.h|  53 ++
>  7 files changed, 747 insertions(+)
>  create mode 100644 drivers/pinctrl/mtmips/Kconfig
>  create mode 100644 drivers/pinctrl/mtmips/Makefile
>  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mt7628.c
>  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.c
>  create mode 100644 drivers/pinctrl/mtmips/pinctrl-mtmips-common.h
> 
> diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> index a0ac167d14..1634dffb35 100644
> --- a/drivers/pinctrl/Kconfig
> +++ b/drivers/pinctrl/Kconfig
> @@ -244,6 +244,7 @@ source "drivers/pinctrl/exynos/Kconfig"
>  source "drivers/pinctrl/mediatek/Kconfig"
>  source "drivers/pinctrl/meson/Kconfig"
>  source "drivers/pinctrl/mscc/Kconfig"
> +source "drivers/pinctrl/mtmips/Kconfig"
>  source "drivers/pinctrl/mvebu/Kconfig"
>  source "drivers/pinctrl/nxp/Kconfig"
>  source "drivers/pinctrl/renesas/Kconfig"
> diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> index 4b080b74dc..ce0879a2b7 100644
> --- a/drivers/pinctrl/Makefile
> +++ b/drivers/pinctrl/Makefile
> @@ -9,6 +9,7 @@ obj-y += nxp/
>  obj-$(CONFIG_$(SPL_)PINCTRL_ROCKCHIP)+= rockchip/
>  obj-$(CONFIG_ARCH_ASPEED) += aspeed/
>  obj-$(CONFIG_ARCH_ATH79) += ath79/
> +obj-$(CONFIG_ARCH_MTMIPS) += mtmips/
>  obj-$(CONFIG_ARCH_RMOBILE) += renesas/
>  obj-$(CONFIG_PINCTRL_SANDBOX)+= pinctrl-sandbox.o
>  
> diff --git a/drivers/pinctrl/mtmips/Kconfig b/drivers/pinctrl/mtmips/Kconfig
> new file mode 100644
> index 00..8482a38ebc
> --- /dev/null
> +++ b/drivers/pinctrl/mtmips/Kconfig
> @@ -0,0 +1,13 @@
> +
> +config PINCTRL_MTMIPS
> + depends on ARCH_MTMIPS
> + bool
> +
> +config PINCTRL_MT7628
> + bool "MediaTek MT7628 pin control driver"
> + select PINCTRL_MTMIPS
> + depends on SOC_MT7628 && PINCTRL_GENERIC
> + help
> +   Support pin multiplexing control on MediaTek MT7628.
> +   The driver is controlled by a device tree node which contains
> +   the pin mux functions for each available pin groups.
> diff --git a/drivers/pinctrl/mtmips/Makefile b/drivers/pinctrl/mtmips/Makefile
> new file mode 100644
> index 00..3ba5c0c66d
> --- /dev/null
> +++ b/drivers/pinctrl/mtmips/Makefile
> @@ -0,0 +1,7 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +# Core
> +obj-$(CONFIG_PINCTRL_MTMIPS) += pinctrl-mtmips-common.o
> +
> +# SoC Drivers
> +obj-$(CONFIG_PINCTRL_MT7628) += pinctrl-mt7628.o
> diff --git a/drivers/pinctrl/mtmips/pinctrl-mt7628.c 
> b/drivers/pinctrl/mtmips/pinctrl-mt7628.c
> new file mode 100644
> index 00..6883450a09
> --- /dev/null
> +++ b/drivers/pinctrl/mtmips/pinctrl-mt7628.c
> @@ -0,0 +1,585 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019 MediaTek Inc. All Rights Reserved.
> + *
> + * Author: Weijie Gao 
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-mtmips-common.h"
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +#define AGPIO_OFS0
> +#define GPIOMODE1_OFS0x24
> +#define GPIOMODE2_OFS0x28
> +
> +#define EPHY4_1_PAD_SHIFT17
> +#define EPHY4_1_PAD_MASK 0x0f
> +#define EPHY0_SHIFT  16
> +#define RF_OLT_MODE_SHIFT12
> +#define N9_EINT_SRC_SHIFT9
> +#define WLED_OD_SHIFT8
> +#define REF_CLKO_PAD_SHIFT   4
> +#define I2S_CLK_PAD_SHIFT3
> +#define I2S_WS_PAD_SHIFT 2
> +#define I2S_SDO_PAD_SHIFT1
> +#define I2S_SDI_PAD_SHIFT0
> +
> +#define GM4_MASK 3
> +
> +#define P4LED_K_SHIFT26
> +#define P3LED_K_SHIFT24
> +#define P2LED_K_SHIFT22
> +#define P1LED_K_SHIFT20
> +#define P0LED_K_SHIFT18
> +#define WLED_K_SHIFT 16
> +#define P4LED_A_SHIFT10
> +#define P3LED_A_SHIFT8
> +#define P2LED_A_SHIFT6
> +#define P1LED_A_SHIFT4
> +#define P0LED_A_SHIFT2
> +#define WLED_A_SHIFT 0
> +
> +#define PWM1_SHIFT   30
> +#define PWM0_SHIFT   28
> +#define 

Re: [U-Boot] [PATCH 05/14] dfu: allow read with 0 data for EOF indication

[Patrick DELAUNAY]

Hi Lukasz,

> From: Lukasz Majewski 
> Sent: mardi 17 septembre 2019 12:29
> 
> Hi Patrick,
> 
> > This patch allows into the DFU backend to indicate that there is no
> > remaining data (for EOF for example). That allows users to read a
> > buffer greater than the device size; the dfu stack stops the read
> > request when the backend return a length=0 without error.
> >
> > Signed-off-by: Patrick Delaunay 
> > ---
> >
> >  drivers/dfu/dfu.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index
> > 8bd5216017..50919fcae9 100644
> > --- a/drivers/dfu/dfu.c
> > +++ b/drivers/dfu/dfu.c
> > @@ -396,6 +396,8 @@ static int dfu_read_buffer_fill(struct dfu_entity
> > *dfu, void *buf, int size) debug("%s: Read error!\n", __func__);
> > return ret;
> > }
> > +   if (dfu->b_left == 0)
> > +   break;
> 
> I guess that this is the use case for sending commands?

Yes,

The use-case is for virtual partition, also used for "command".

Command is requested by updload in the associated alternate 
And result is done by reading on the same alternate.

During enumeration I set the size of the alternate at the maximum size of the 
answer
This test allow to read, without error, until the backend / callback read at 
the requested offset with a offset = 0.


> Could you provide a more descriptive use case for this change (the 
> description in
> the above commit message is not enough for me to get it).

Yes, I will update the comment in V2.

The issue is the DFU read size is limited by get_medium_size = r_left and the 
stack expectes that read is allowed up to this size.

Today the DFU backend can't indicate to the DFU stack when the end of available 
data to read is reached, without and raising error.
Because in dfu_read_buffer_fill the loop is infinite until
- read_medium raised a error
- size = 0
- no more to read in DFU buffer (r_left = 0)

This patch allow the backend to indicate that that it can't provide no more 
data to fill the DFU buffer, by setting b_left =0 even is the available size id 
is lower of the total size indicated by get_medium_size.

For USB DFU stack point of view, it is acceptable (read lenght < requested size 
in DFU_UPLOAD and the transaction is stopped).

It is never a issue for flash device (where chunk are always completely read, 
b_left will be never 0) but it is usefulll for virtual partition when we only 
know the max size of this alternate.

Without this patch, I have a infinite loop, when for on backend the result of 
read_medium  is 0 (OK) but dfu->b_left = 0
=> r_left is not decreased and size is not updated
I try an other solution: raised a error when no more date is available but in 
this case the data read is not correctly managed in the loop.

PS: It is used in my example for stm32mp1

=> board/st/stm32mp1/stm32mp1.c

I force size to size = 1KB for all virtual partition , in 
dfu_get_medium_size_virt.

But in fucntio called dfu_read_medium_virt, I limit the size the each virtual 
partition in dfu_otp_read...

=> only 8 bytes for pmic  (in dfu_pmic_read, the second read at offset 8, 
misc_read return -EACCES)


dfu-util -d 0483:5720 -a 26 -U pmic.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #26 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from DFU device to PC
Upload  [=] 100%8 bytes
Upload done.

===> but 1KB for otp

dfu-util -d 0483:5720 -a 25 -U otp.bin
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Setting #25 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0110
Device returned transfer size 4096
Copying data from DFU device to PC
Upload  [=] 100% 1024 bytes
Upload done.


> 
> > dfu->offset += dfu->b_left;
> > dfu->r_left -= dfu->b_left;
> >
> 
> 
> 
> Best regards,
> 
> Lukasz Majewski
> 

Best regards

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

[U-Boot] [PATCH v1] armv8: fsl-layerscape: LS1044A/1048A: enable Only 1x 10GE port

[Pramod Kumar]

LS1044A/1048A is LS1088 personality which support only one 1x 10GE port.
MAC1 and MAC2 are associated with 1G SGMII, 2.5G SGMII, and XFI.
Disable MAC1 to have only one 1x 10GE port

Signed-off-by: Pramod Kumar 
---
 arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 33 +-
 1 file changed, 32 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c 
b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
index 8e8b45a..11090e8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
@@ -5,6 +5,11 @@
 
 #include 
 #include 
+#include 
+#include 
+#define PERSONALITY_LS1088A_TYPE   0
+#define PERSONALITY_LS1044A_LS1048A_TYPE   1
+#define PERSONALITY_INVALID_TYPE   -1
 
 struct serdes_config {
u8 ip_protocol;
@@ -32,6 +37,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x3A, {SGMII3, PCIE1, SGMII1, SGMII2 }, {3, 5, 3, 3 } },
{}
 };
+
 static struct serdes_config serdes2_cfg_tbl[] = {
/* SerDes 2 */
{0x0C, {PCIE1, PCIE1, PCIE1, PCIE1 }, {8, 8, 8, 8 } },
@@ -48,6 +54,22 @@ static struct serdes_config *serdes_cfg_tbl[] = {
serdes2_cfg_tbl,
 };
 
+int check_personality_type(void)
+{
+   struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+   unsigned int  svr, ver;
+   int personality;
+
+   svr = gur_in32(>svr);
+   ver = SVR_SOC_VER(svr);
+   if (ver == SVR_LS1088A)
+   personality =  PERSONALITY_LS1088A_TYPE;
+   else
+   personality = PERSONALITY_LS1044A_LS1048A_TYPE;
+
+   return personality;
+}
+
 int serdes_get_number(int serdes, int cfg)
 {
struct serdes_config *ptr;
@@ -84,10 +106,19 @@ int serdes_get_number(int serdes, int cfg)
 enum srds_prtcl serdes_get_prtcl(int serdes, int cfg, int lane)
 {
struct serdes_config *ptr;
+   int personality_type;
 
if (serdes >= ARRAY_SIZE(serdes_cfg_tbl))
return 0;
-
+   /*
+* LS1044A/1048A  support only one XFI port
+* Disable MAC1 for LS1044A/1048A
+*/
+   if (!serdes && lane == 2) {
+   personality_type = check_personality_type();
+   if (personality_type == PERSONALITY_LS1044A_LS1048A_TYPE)
+   return 0;
+   }
ptr = serdes_cfg_tbl[serdes];
while (ptr->ip_protocol) {
if (ptr->ip_protocol == cfg)
-- 
2.7.4

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

Re: [U-Boot] [RFC 02/15] test: add tests for u16_strcmp()

[Heinrich Schuchardt]

On 9/18/19 3:26 AM, AKASHI Takahiro wrote:
> New seven test cases for u16_strcmp() are added under Unicode unit test,
> which should be executed by "ut unicode" command.
>
> Signed-off-by: AKASHI Takahiro 

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

Re: [U-Boot] [RFC 01/15] lib: charset: add u16_strcmp()

[Heinrich Schuchardt]

On 9/18/19 3:26 AM, AKASHI Takahiro wrote:
> u16 version of strcmp(): u16_strncmp() works like u16_strcmp() but only
> at most n characters (in u16) are compared.
> This function will be used in my UEFI secure boot patch.
>
> Signed-off-by: AKASHI Takahiro 

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

[U-Boot] [PATCH v2] armv7: ls102xa: Correct entry of SCFG_QSPI_CLKSEL

[Kuldeep Singh]

Value 0xC is reserved. Replace it with correct value 0x5 which
is ClusterPLL/16

Signed-off-by: Ashish Kumar 
Signed-off-by: Kuldeep Singh 
---
v2:
Reword commit message
 arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h 
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 137cd61804..f2ba182346 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -155,7 +155,7 @@ struct ccsr_gur {
 #define SCFG_ETSECCMCR_GE0_CLK125  0x
 #define SCFG_ETSECCMCR_GE1_CLK125  0x0800
 #define SCFG_PIXCLKCR_PXCKEN   0x8000
-#define SCFG_QSPI_CLKSEL   0xc010
+#define SCFG_QSPI_CLKSEL   0x5010
 #define SCFG_SNPCNFGCR_SEC_RD_WR   0xc000
 #define SCFG_SNPCNFGCR_DCU_RD_WR   0x0300
 #define SCFG_SNPCNFGCR_SATA_RD_WR  0x00c0
-- 
2.17.1

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

Re: [U-Boot] [PATCH V2] [RFC] usb: storage: Limit transfer size to 120 kiB

[Bin Meng]

On Wed, Sep 18, 2019 at 6:07 PM Marek Vasut  wrote:
>
> On 9/18/19 4:13 AM, Bin Meng wrote:
> > On Tue, Sep 17, 2019 at 10:43 PM Marek Vasut  wrote:
> >>
> >> Due to constant influx of more and more weird and broken USB sticks,
> >> do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85
> >>
> >> usb: storage: scsiglue: further describe our 240 sector limit
> >>
> >> Just so we have some sort of documentation as to why
> >> we limit our Mass Storage transfers to 240 sectors,
> >> let's update the comment to make clearer that
> >> devices were found that would choke with larger
> >> transfers.
> >>
> >> While at that, also make sure to clarify that other
> >> operating systems have similar, albeit different,
> >> limits on mass storage transfers.
> >>
> >> And reduce the maximum transfer length of USB storage to 120 kiB.
> >>
> >> Signed-off-by: Marek Vasut 
> >> Cc: Bin Meng 
> >> Cc: Simon Glass 
> >> ---
> >> V2: Reshuffle the code a bit, always clamp the transfer size to 240 blocks
> >> ---
> >>  common/usb_storage.c | 43 ++-
> >>  1 file changed, 22 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/common/usb_storage.c b/common/usb_storage.c
> >> index 8c889bb1a6..e1b539a082 100644
> >> --- a/common/usb_storage.c
> >> +++ b/common/usb_storage.c
> >> @@ -938,31 +938,32 @@ do_retry:
> >>  static void usb_stor_set_max_xfer_blk(struct usb_device *udev,
> >>   struct us_data *us)
> >>  {
> >> -   unsigned short blk;
> >> -   size_t __maybe_unused size;
> >> -   int __maybe_unused ret;
> >> -
> >> -#if !CONFIG_IS_ENABLED(DM_USB)
> >> -#ifdef CONFIG_USB_EHCI_HCD
> >> /*
> >> -* The U-Boot EHCI driver can handle any transfer length as long as
> >> -* there is enough free heap space left, but the SCSI READ(10) and
> >> -* WRITE(10) commands are limited to 65535 blocks.
> >> +* Limit the total size of a transfer to 120 KB.
> >> +*
> >> +* Some devices are known to choke with anything larger. It seems 
> >> like
> >> +* the problem stems from the fact that original IDE controllers 
> >> had
> >> +* only an 8-bit register to hold the number of sectors in one 
> >> transfer
> >> +* and even those couldn't handle a full 256 sectors.
> >> +*
> >> +* Because we want to make sure we interoperate with as many 
> >> devices as
> >> +* possible, we will maintain a 240 sector transfer size limit for 
> >> USB
> >> +* Mass Storage devices.
> >> +*
> >> +* Tests show that other operating have similar limits with 
> >> Microsoft
> >> +* Windows 7 limiting transfers to 128 sectors for both USB2 and 
> >> USB3
> >> +* and Apple Mac OS X 10.11 limiting transfers to 256 sectors for 
> >> USB2
> >> +* and 2048 for USB3 devices.
> >>  */
> >> -   blk = USHRT_MAX;
> >> -#else
> >> -   blk = 20;
> >> -#endif
> >> -#else
> >> +   unsigned short blk = 240;
> >> +
> >> +#if CONFIG_IS_ENABLED(DM_USB)
> >> +   size_t size;
> >> +   int ret;
> >> +
> >> ret = usb_get_max_xfer_size(udev, (size_t *));
> >> -   if (ret < 0) {
> >> -   /* unimplemented, let's use default 20 */
> >> -   blk = 20;
> >> -   } else {
> >> -   if (size > USHRT_MAX * 512)
> >> -   size = USHRT_MAX * 512;
> >> +   if ((ret >= 0) && (size < 240 * 512))
> >
> > size < blk * 512
> >
> >> blk = size / 512;
> >> -   }
> >>  #endif
> >>
> >> us->max_xfer_blk = blk;
> >> --
> >
> > Looks good otherwise
> >
> > Reviewed-by: Bin Meng 
>
> Fixed and added to next . This really needs a LOT of testing.
> I am worried about performance here.

Agree. I was wondering how Linux managed to set such limit for all usb
storage devices and no performance degradation reported?

BTW: it looks you missed adding my "Reviewed-by"
https://gitlab.denx.de/u-boot/custodians/u-boot-usb/commit/85a0cb96dabf7572db3c6726a276a48c5c77a9da

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

Re: [U-Boot] Odroid n1- booting hangs if we add memtest=4 to kernel command line.

[Anand Moon]

Hi Kevrer,

On Wed, 18 Sep 2019 at 12:02, Kever Yang  wrote:
>
> Hi Anand,
>
>
> On 2019/9/16 下午7:03, Anand Moon wrote:
>
> Hi Jagan / Kever,
>
> I have with me Odroid - N1 per-released development board,
> It's almost same form factor to "Firefly-RK3399 Board" with
> rk3399-sdram-ddr3-1600.dtsi ram configuration.
>
> I have configure Odroid - N1 board to boot using TPL / SPL configuration
> using latest kernel and latest u-boot, but I am facing some issue with not
> able to upgrade my distro packages, It's literally hangs on heavy I/O
> operations.
>
> So I would like to check if the memory is working correctly, but below
> command failed.
>
> # sudo memtester 1024 5
> memtester version 4.3.0 (64-bit)
> Copyright (C) 2001-2012 Charles Cazabon.
> Licensed under the GNU General Public License version 2 (only).
>
> pagesize is 4096
> pagesizemask is 0xf000
> want 1024MB (1073741824 bytes)
> got  1024MB (1073741824 bytes), trying mlock ...
>
> Then I would like to enable *memtest=4* via bootargs ie kernel command
> line and it failed to boot up.
>
>
> I'm not able to understand well about your issue, does it:
> - boots fine with odroid-N1 but hang at memtester ?
> - hang at "Starting kernel..." with kernel command like update
> Since it boots OK, the DRAM should works OK, you can replace the TPL with 
> rockchip binary ddr[0]
> to double check if they have the same output.
> I have no idea about the bootargs "memtest=4", but I suppose this should not 
> affect the kernel
> boot process, maybe you have do something wrong and not update the bootargs 
> as what you
> expect, you can print it in U-Boot to check the actually bootargs.
>
> Thanks,
> - Kever
> [0] 
> https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk3399_ddr_800MHz_v1.23.bin
>

Ok thanks for your input. I will give this a try.

Here is the scenario I faced  I am using Archlinux using latest u-boot
and 5.13 kernel.
First issue that during upgrade on distro packages it suddenly stop
with not kernel panic.
So I could not understand the root caused.

1 > Then I tried some fio test with large file mapping it also failed
with no kernel panic.
2 > Then I tired memtester it also failed with no kernel panic.
3 > Finally I tried the memtest kernel memory testing feature at boot
time, but it hangs.

So I could only conclude that it's not able to map large file, because
memory is not tuned correctly.

Well I have tried to rebuild the u-boot using below image

[0] 
https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk3399_ddr_800MHz_v1.23.bin

Here is the boot log of above and kernel panic using fio command below.

[1] https://pastebin.com/Qe0Lpqss

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1
--name=test --filename=test --bs=4k --iodepth=64 --size=4G
--readwrite=randrw --rwmixread=75

Again memtester is not able to test memory, it's not able to map large file map.

[root@alarm ~]# memtester 4GB
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xf000
want 4096MB (4294967296 bytes)
got  3866MB (4054790144 bytes), trying mlock ...[  110.647775] SError
Interrupt on CPU5, code 0xbf00 -- SError
[  110.647776] CPU: 5 PID: 372 Comm: memtester Not tainted 5.3.0-xn1ml1 #2
[  110.64] Hardware name: Hardkernel ODROID-N1 (DT)
[  110.647778] pstate: 0005 (nzcv daif -PAN -UAO)
[  110.647779] pc : clear_page+0x10/0x24
[  110.647780] lr : __cpu_clear_user_page+0xc/0x18
[  110.647781] sp : 11bcbaf0
[  110.647781] x29: 11bcbaf0 x28: 8000eda6ccc0
[  110.647783] x27: 8000e562 x26: 8000e562c3c0
[  110.647785] x25: 7e0003971dc0 x24: 
[  110.647786] x23: 7e27 x22: 1000
[  110.647788] x21: 6600 x20: 
[  110.647790] x19: 8000e562 x18: 
[  110.647791] x17: 0010 x16: 0010
[  110.647793] x15:  x14: 009e
[  110.647795] x13: 7e27 x12: 7e0003ba8500
[  110.647796] x11:  x10: 11bcb9c0
[  110.647798] x9 : 0001 x8 : 8000efafc230
[  110.647799] x7 : 1665 x6 : 
[  110.647801] x5 : 0000 x4 : 0001
[  110.647803] x3 : 7fc0 x2 : 0004
[  110.647804] x1 : 0040 x0 : 89dff4c0
[  110.647806] Kernel panic - not syncing: Asynchronous SError Interrupt
[  110.647807] CPU: 5 PID: 372 Comm: memtester Not tainted 5.3.0-xn1ml1 #2
[  110.647808] Hardware name: Hardkernel ODROID-N1 (DT)
[  110.647809] Call trace:
[  110.647809]  dump_backtrace+0x0/0x140
[  110.647810]  show_stack+0x14/0x20
[  110.647811]  dump_stack+0x98/0xbc
[  110.647811]  panic+0x130/0x2fc
[  110.647812]  __stack_chk_fail+0x0/0x18
[  110.647813]  arm64_serror_panic+0x74/0x80
[  110.647814]  is_valid_bugaddr+0x0/0x8
[  

Re: [U-Boot] [PATCH V2] [RFC] usb: storage: Limit transfer size to 120 kiB

[Marek Vasut]

On 9/18/19 4:13 AM, Bin Meng wrote:
> On Tue, Sep 17, 2019 at 10:43 PM Marek Vasut  wrote:
>>
>> Due to constant influx of more and more weird and broken USB sticks,
>> do as Linux does in commit 779b457f66e10de3471479373463b27fd308dc85
>>
>> usb: storage: scsiglue: further describe our 240 sector limit
>>
>> Just so we have some sort of documentation as to why
>> we limit our Mass Storage transfers to 240 sectors,
>> let's update the comment to make clearer that
>> devices were found that would choke with larger
>> transfers.
>>
>> While at that, also make sure to clarify that other
>> operating systems have similar, albeit different,
>> limits on mass storage transfers.
>>
>> And reduce the maximum transfer length of USB storage to 120 kiB.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Bin Meng 
>> Cc: Simon Glass 
>> ---
>> V2: Reshuffle the code a bit, always clamp the transfer size to 240 blocks
>> ---
>>  common/usb_storage.c | 43 ++-
>>  1 file changed, 22 insertions(+), 21 deletions(-)
>>
>> diff --git a/common/usb_storage.c b/common/usb_storage.c
>> index 8c889bb1a6..e1b539a082 100644
>> --- a/common/usb_storage.c
>> +++ b/common/usb_storage.c
>> @@ -938,31 +938,32 @@ do_retry:
>>  static void usb_stor_set_max_xfer_blk(struct usb_device *udev,
>>   struct us_data *us)
>>  {
>> -   unsigned short blk;
>> -   size_t __maybe_unused size;
>> -   int __maybe_unused ret;
>> -
>> -#if !CONFIG_IS_ENABLED(DM_USB)
>> -#ifdef CONFIG_USB_EHCI_HCD
>> /*
>> -* The U-Boot EHCI driver can handle any transfer length as long as
>> -* there is enough free heap space left, but the SCSI READ(10) and
>> -* WRITE(10) commands are limited to 65535 blocks.
>> +* Limit the total size of a transfer to 120 KB.
>> +*
>> +* Some devices are known to choke with anything larger. It seems 
>> like
>> +* the problem stems from the fact that original IDE controllers had
>> +* only an 8-bit register to hold the number of sectors in one 
>> transfer
>> +* and even those couldn't handle a full 256 sectors.
>> +*
>> +* Because we want to make sure we interoperate with as many devices 
>> as
>> +* possible, we will maintain a 240 sector transfer size limit for 
>> USB
>> +* Mass Storage devices.
>> +*
>> +* Tests show that other operating have similar limits with Microsoft
>> +* Windows 7 limiting transfers to 128 sectors for both USB2 and USB3
>> +* and Apple Mac OS X 10.11 limiting transfers to 256 sectors for 
>> USB2
>> +* and 2048 for USB3 devices.
>>  */
>> -   blk = USHRT_MAX;
>> -#else
>> -   blk = 20;
>> -#endif
>> -#else
>> +   unsigned short blk = 240;
>> +
>> +#if CONFIG_IS_ENABLED(DM_USB)
>> +   size_t size;
>> +   int ret;
>> +
>> ret = usb_get_max_xfer_size(udev, (size_t *));
>> -   if (ret < 0) {
>> -   /* unimplemented, let's use default 20 */
>> -   blk = 20;
>> -   } else {
>> -   if (size > USHRT_MAX * 512)
>> -   size = USHRT_MAX * 512;
>> +   if ((ret >= 0) && (size < 240 * 512))
> 
> size < blk * 512
> 
>> blk = size / 512;
>> -   }
>>  #endif
>>
>> us->max_xfer_blk = blk;
>> --
> 
> Looks good otherwise
> 
> Reviewed-by: Bin Meng 

Fixed and added to next . This really needs a LOT of testing.
I am worried about performance here.

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

[U-Boot] [PATCH 1/2] rockchip: evb-rk3288: Drop explicit SPL_TEXT

[Kever Yang]

SPL_TEXT_BASE is 0x0 by default, based on the kconfig
definition move in below commit.

"configs: move CONFIG_SPL_TEXT_BASE to Kconfig"
(sha1: f89d6133eef2e068f9c33853b6584d7fcbfa9d2e)

So, don't define it explicitly.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3288_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 405fde0c80..8be66a600d 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -14,7 +14,6 @@ CONFIG_SILENT_CONSOLE=y
 CONFIG_DEFAULT_FDT_FILE="rk3288-evb-rk808.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
-CONFIG_SPL_TEXT_BASE=0
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
-- 
2.17.1

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

[U-Boot] [PATCH 2/2] rockchip: config: evb-rk3288: enable SPL_STACK_R

[Kever Yang]

We need a new STACK in SDRAM instead of SRAM so that the EMMC controller
can work properly. The EMMC/SD controller's master is not able to access
SRAM area, it can only access DRAM area.

Signed-off-by: Kever Yang 
---

 configs/evb-rk3288_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 8be66a600d..7b0e908f71 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -5,6 +5,7 @@ CONFIG_ROCKCHIP_RK3288=y
 CONFIG_TARGET_EVB_RK3288=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SPL_SIZE_LIMIT=307200
+CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEBUG_UART_BASE=0xff69
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART=y
@@ -14,6 +15,8 @@ CONFIG_SILENT_CONSOLE=y
 CONFIG_DEFAULT_FDT_FILE="rk3288-evb-rk808.dtb"
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH 6/7] configs: tinker: Enable SDRAM, SPL stack

[Kever Yang]

On 2019/9/18 下午1:25, Jagan Teki wrote:

On Wed, Sep 18, 2019 at 10:36 AM Kever Yang  wrote:


On 2019/9/17 下午2:10, Jagan Teki wrote:

SPL sets up SDRAM while in its board_init_f()
function, it is possible for the stack to move
there before board_init_r() is reached.

So it is required to reserve the stack for SDRAM,
with a proper location and size otherwise any
operations during SPL handoff would leads to failure.

On, this particular context tinker-rk3288 SPL is
failing to launch U-Boot proper on SDRAM due to
lack of stack.

If no SPL_STACK_R, it should still use CONFIG_SPL_STACK when system
init, right?

SPL_STACK vs SPL_STTACK_R would be different in their usage former is
used to setup the stack during early while calling board_init_f but
the later used to setup the stack (with DRAM base) while calling
board_init_r. if CONFIG_SPL_STACK_R is defined, then at this point the
stack and global_data are relocated to below CONFIG_SPL_STACK_R_ADDR.

CONFIG_SPL_STACK_R_ADDR - 0x8 (this would be as part of sdram map)
CONFIG_SPL_STACK  - 0xff718000 (this address where SDRAM not been used)

Since the issue, is due to launch U-Boot proper from mmc, the stack
that SPL during that time was not set it up.


I think the root cause is: the master of emmc controller can no access 
SRAM, and the emmc init
driver needs to use memory based on CONFIG_SPL_STACK, if this is in 
SRAM, then the emmc driver
will init fail, and 'fifo-mode' can work around this issue. So the 
CONFIG_SPL_STACK_R is needed

for emmc/sd controller driver.

Thanks,
- Kever



It sounds like this should not cause failure if there no one touch the
CONFIG_SPL_STACK area.

I remember while implementing TPL, on vyasa I do take care of this
STACK_R, so same been reused it for tinker.




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

Re: [U-Boot] [U-BOOT PATCH v1 1/2] gpio: fu540: add support for DM based gpio driver for FU540-SoC

[Bin Meng]

Hi Sagar,

On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam
 wrote:
>
> This patch adds a DM based driver model for gpio controller present in
> FU540-C000 SoC on HiFive Unleashed A00 board. This SoC has one GPIO
> bank and 16 GPIO lines in total, out of which GPIO0 to GPIO9 and
> GPIO15 are routed to the J1 header on the board.
>
> This implementation is ported from linux based gpio driver submitted
> for review by Wesley W. Terpstra  and/or Atish Patra
>  (many thanks !!). The linux driver can be referred
> here [1]
>
> [1]: https://lkml.org/lkml/2018/10/9/1103
>
> Signed-off-by: Sagar Shrikant Kadam 
> ---
>  arch/riscv/include/asm/arch-generic/gpio.h |  35 +++
>  arch/riscv/include/asm/gpio.h  |   6 ++
>  drivers/gpio/Kconfig   |   8 ++
>  drivers/gpio/Makefile  |   1 +
>  drivers/gpio/sifive-gpio.c | 143 
> +
>  5 files changed, 193 insertions(+)
>  create mode 100644 arch/riscv/include/asm/arch-generic/gpio.h
>  create mode 100644 arch/riscv/include/asm/gpio.h
>  create mode 100644 drivers/gpio/sifive-gpio.c
>
> diff --git a/arch/riscv/include/asm/arch-generic/gpio.h 
> b/arch/riscv/include/asm/arch-generic/gpio.h
> new file mode 100644
> index 000..7287298
> --- /dev/null
> +++ b/arch/riscv/include/asm/arch-generic/gpio.h
> @@ -0,0 +1,35 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2019 SiFive, Inc.
> + */
> +
> +#ifndef _GPIO_FU540_H

_GPIO_SIFIVE_H

> +#define _GPIO_FU540_H
> +
> +#define GPIO_INPUT_VAL 0x00
> +#define GPIO_INPUT_EN  0x04
> +#define GPIO_OUTPUT_EN 0x08
> +#define GPIO_OUTPUT_VAL0x0C
> +#define GPIO_RISE_IE   0x18
> +#define GPIO_RISE_IP   0x1C
> +#define GPIO_FALL_IE   0x20
> +#define GPIO_FALL_IP   0x24
> +#define GPIO_HIGH_IE   0x28
> +#define GPIO_HIGH_IP   0x2C
> +#define GPIO_LOW_IE0x30
> +#define GPIO_LOW_IP0x34
> +#define GPIO_OUTPUT_XOR0x40
> +
> +#define NR_GPIOS   16
> +
> +enum gpio_state {
> +   LOW,
> +   HIGH
> +};
> +
> +/* Details about a GPIO bank */
> +struct fu540_gpio_platdata {

sifive_gpio_platdata

> +   void *base; /* address of registers in physical memory */
> +};
> +
> +#endif /* _GPIO_FU540_H */
> diff --git a/arch/riscv/include/asm/gpio.h b/arch/riscv/include/asm/gpio.h
> new file mode 100644
> index 000..008d756
> --- /dev/null
> +++ b/arch/riscv/include/asm/gpio.h
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2018 SiFive, Inc.
> + */
> +
> +#include 
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index f2dabb5..ec48f26 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -285,6 +285,14 @@ config STM32_GPIO
>   usable on many stm32 families like stm32f4/f7/h7 and stm32mp1.
>   Tested on STM32F7.
>
> +config SIFIVE_GPIO
> +   bool "SiFive FU540 GPIO driver"

just "SiFive GPIO driver"?

> +   depends on DM_GPIO
> +   help
> + Device model driver for GPIO controller present in FU540 SoC. This

present in SiFive FU540 SoC

> + driver enables GPIO interface on HiFive Unleashed A00 board a board

remove "a board"

> + from SiFive Inc. having FU540-C000 SoC.

remove this line

> +
>  config MVEBU_GPIO
> bool "Marvell MVEBU GPIO driver"
> depends on DM_GPIO && ARCH_MVEBU
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 4a8aa0f..ccc49e2 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -61,3 +61,4 @@ obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
>  obj-$(CONFIG_PM8916_GPIO)  += pm8916_gpio.o
>  obj-$(CONFIG_MT7621_GPIO)  += mt7621_gpio.o
>  obj-$(CONFIG_MSCC_SGPIO)   += mscc_sgpio.o
> +obj-$(CONFIG_SIFIVE_GPIO)  += sifive-gpio.o
> diff --git a/drivers/gpio/sifive-gpio.c b/drivers/gpio/sifive-gpio.c
> new file mode 100644
> index 000..4bf8acf
> --- /dev/null
> +++ b/drivers/gpio/sifive-gpio.c
> @@ -0,0 +1,143 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * SiFive GPIO driver
> + *
> + * Copyright (C) 2019 SiFive, Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static int fu540_gpio_probe(struct udevice *dev)

Please rename all function names to have "sifive_" prefix.

> +{
> +   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> +
> +   uc_priv->bank_name = dev->name;
> +
> +   /*
> +* Use the gpio count mentioned in device tree,
> +* if not specified in dt, set NR_GPIOS as default
> +*/
> +   uc_priv->gpio_count = dev_read_u32_default(dev, "ngpios", NR_GPIOS);
> +
> +   return 0;
> +}
> +
> +static void fu540_update_gpio_reg(void *bptr, u32 offset, bool value)
> +{
> +   void __iomem *ptr = (void __iomem *)bptr;
> +
> +   u32 bit = BIT(offset);
> +   u32 old = readl(ptr);
> +
> +   if (value)
> +   writel(old | bit, ptr);
> +   else

Re: [U-Boot] [PATCH 6/7] configs: tinker: Enable SDRAM, SPL stack

[Kever Yang]

On 2019/9/17 下午2:10, Jagan Teki wrote:

SPL sets up SDRAM while in its board_init_f()
function, it is possible for the stack to move
there before board_init_r() is reached.

So it is required to reserve the stack for SDRAM,
with a proper location and size otherwise any
operations during SPL handoff would leads to failure.

On, this particular context tinker-rk3288 SPL is
failing to launch U-Boot proper on SDRAM due to
lack of stack.

  U-Boot SPL 2019.10-rc3-00297-g5ba8b12543 (Sep 12 2019 - 08:50:36 +0530)
  Trying to boot from MMC1
  spl: mmc init failed with error: -110
  SPL: failed to boot from all boot devices
  ### ERROR ### Please RESET the board ###

So, enable SPL_STACK_R_ADDR and it's related-config
items for SDRAM, SPL stack to setup properly.

Reported-by: Jagan Teki 
Signed-off-by: Jagan Teki 


Reviewed-by: Kever Yang

Thanks,
- Kever

---
  configs/tinker-rk3288_defconfig | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/configs/tinker-rk3288_defconfig b/configs/tinker-rk3288_defconfig
index adab1cba42..359be078ac 100644
--- a/configs/tinker-rk3288_defconfig
+++ b/configs/tinker-rk3288_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x0100
  CONFIG_ROCKCHIP_RK3288=y
  CONFIG_TARGET_TINKER_RK3288=y
  CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL_STACK_R_ADDR=0x8
  CONFIG_SPL_SIZE_LIMIT=307200
  CONFIG_DEBUG_UART_BASE=0xff69
  CONFIG_DEBUG_UART_CLOCK=2400
@@ -15,6 +16,8 @@ CONFIG_CONSOLE_MUX=y
  CONFIG_DEFAULT_FDT_FILE="rk3288-tinker.dtb"
  # CONFIG_DISPLAY_CPUINFO is not set
  CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
  CONFIG_CMD_GPIO=y
  CONFIG_CMD_GPT=y
  CONFIG_CMD_I2C=y



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

[U-Boot] [PATCH v3 0/3] env: Add CONFIG_ENV_FULL_SUPPORT

[Patrick Delaunay]

Hi,

This patchset is a the 3rd version of
  http://patchwork.ozlabs.org/project/uboot/list/?series=129339
  "env: Add CONFIG_ENV_SUPPORT"

The first patch of the serie only solves the regression introduced by
commit 7d4776545b0f ("env: solve compilation error
in SPL"); change_ok was always NULL in U-Boot.
See "U-Boot: Environment flags broken for U-Boot" mail
http://u-boot.10912.n7.nabble.com/U-Boot-Environment-flags-broken-for-U-Boot-tt382673.html

This first patch can be integrated in master branch
for v2019.10 as requested Tom Rimi.

The next patches of the serie is a proposal after Wolfgang Denk
review on the first proposal: I make the env support coherent between
U-Boot, SPL and TPL.

I need to change many defconfig (to add CONFIG_(SPL/TPL)_ENV_IS_NOWHERE)
because I modify the dependency between the CONFIG used by SPL.

Moreover the size of SPL increase after this last patch.

For example on stm32mp15_basic, the SPL sizes:

  620244616 892   67532   107cc spl/u-boot-spl 3e6c

increase by 250 byte to

  622744640 896   67810   108e2 spl/u-boot-spl 3f56

And the patch also breaks the compilation of few boards, when SPL size is
near to its limit (.sram overflowed in SPL or SPL image too big):
 imx6q_logic (by 1572 bytes)
 omap3_logic_somlv (by 220 bytes)
 omap3_logic (by 276 bytes)
 omap35_logic_somlv (by 156 bytes)
 omap35_logic (by 3064 bytes)
 smartweb (by 408 bytes)
 duovero (by 952 bytes)
 x600 (by 1624 bytes)

So the last patch can't be integrated today with these errors
but any review and advice are welcome.

Best regards.

Patrick Delaunay.


Changes in v3:
- It is a version 3 of
  http://patchwork.ozlabs.org/project/uboot/list/?series=129339
  "env: Add CONFIG_ENV_SUPPORT"
  after Tom Rimi and Wolfgang Denk remarks

Changes in v2:
- Update commit message after Lukasz Majewki review

Patrick Delaunay (3):
  env: correct the check of env_flags_validate presence
  env: introduce macro ENV_IS_IN_SOMEWHERE
  env: Add CONFIG_ENV_FULL_SUPPORT

 arch/arm/mach-omap2/Kconfig   |  1 -
 arch/arm/mach-omap2/am33xx/Kconfig|  2 --
 board/birdland/bav335x/board.c|  2 +-
 board/gateworks/gw_ventana/gw_ventana_spl.c   |  2 +-
 board/liebherr/display5/spl.c |  4 +--
 board/tcl/sl50/board.c|  2 +-
 board/ti/am335x/board.c   |  2 +-
 board/ti/am57xx/board.c   |  2 +-
 board/ti/dra7xx/evm.c |  2 +-
 cmd/Kconfig   |  2 ++
 cmd/nvedit.c  | 27 ---
 common/spl/Kconfig| 20 --
 common/spl/spl_ext.c  |  2 +-
 common/spl/spl_fat.c  |  2 +-
 configs/A10-OLinuXino-Lime_defconfig  |  1 +
 configs/A10s-OLinuXino-M_defconfig|  1 +
 configs/A13-OLinuXinoM_defconfig  |  1 +
 configs/A13-OLinuXino_defconfig   |  1 +
 configs/A20-OLinuXino-Lime2-eMMC_defconfig|  1 +
 configs/A20-OLinuXino-Lime2_defconfig |  1 +
 configs/A20-OLinuXino-Lime_defconfig  |  1 +
 configs/A20-OLinuXino_MICRO-eMMC_defconfig|  1 +
 configs/A20-OLinuXino_MICRO_defconfig |  1 +
 configs/A20-Olimex-SOM-EVB_defconfig  |  1 +
 configs/A20-Olimex-SOM204-EVB-eMMC_defconfig  |  1 +
 configs/A20-Olimex-SOM204-EVB_defconfig   |  1 +
 configs/A33-OLinuXino_defconfig   |  1 +
 configs/Ainol_AW1_defconfig   |  1 +
 configs/Ampe_A76_defconfig|  1 +
 configs/Auxtek-T003_defconfig |  1 +
 configs/Auxtek-T004_defconfig |  1 +
 configs/B4420QDS_NAND_defconfig   |  1 -
 configs/B4860QDS_NAND_defconfig   |  1 -
 configs/BSC9131RDB_NAND_SYSCLK100_defconfig   |  1 +
 configs/BSC9131RDB_NAND_defconfig |  1 +
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig   |  1 +
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig   |  1 +
 configs/Bananapi_M2_Ultra_defconfig   |  1 +
 configs/Bananapi_defconfig|  1 +
 configs/Bananapi_m2m_defconfig|  1 +
 configs/Bananapro_defconfig   |  1 +
 configs/C29XPCIE_NAND_defconfig   |  2 +-
 configs/CHIP_pro_defconfig|  1 +
 configs/CSQ_CS908_defconfig   |  1 +
 configs/Chuwi_V7_CW0825_defconfig |  1 +
 configs/Colombus_defconfig|  1 +
 configs/Cubieboard2_defconfig |  1 +
 configs/Cubieboard4_defconfig |  1 +
 configs/Cubieboard_defconfig  |  1 +
 configs/Cubietruck_defconfig  |  1 +
 configs/Cubietruck_plus_defconfig |  1 +
 configs/Empire_electronix_d709_defconfig  |  1 +
 configs/Empire_electronix_m712_defconfig  |  1 +
 configs/Hummingbird_A31_defconfig |  1 +
 

[U-Boot] [PATCH v3 1/3] env: correct the check of env_flags_validate presence

[Patrick Delaunay]

This patch corrects the check of env_flags_validate presence because
"flags.c" is always compiled in U-Boot and CONFIG_ENV_SUPPORT
don't exist; so the macro CONFIG_IS_ENABLED(ENV_SUPPORT) only provides
the expected result for SPL and TPL (check activation of
CONFIG_SPL_ENV_SUPPORT and CONFIG_TPL_ENV_SUPPORT).

This patch solves the regression introduced by
commit 7d4776545b0f ("env: solve compilation error
in SPL"); change_ok was always NULL in U-Boot.

Signed-off-by: Patrick Delaunay 
---

Changes in v3: None
Changes in v2: None

 env/common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/env/common.c b/env/common.c
index 3fb60509dd..f677b5b0da 100644
--- a/env/common.c
+++ b/env/common.c
@@ -24,8 +24,10 @@ DECLARE_GLOBAL_DATA_PTR;
 #include 
 
 struct hsearch_data env_htab = {
-#if CONFIG_IS_ENABLED(ENV_SUPPORT)
-   /* defined in flags.c, only compile with ENV_SUPPORT */
+#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
+   /* defined in flags.c, only compiled in U-Boot or
+* with $(SPL_TPL_)ENV_SUPPORT
+*/
.change_ok = env_flags_validate,
 #endif
 };
-- 
2.17.1

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

[U-Boot] [PATCH v3 2/3] env: introduce macro ENV_IS_IN_SOMEWHERE

[Patrick Delaunay]

This patch introduce a macro ENV_IS_IN_SOMEWHERE to check if the
the environment can be saved somewhere, in a device or in a file system,
without assumption on CONFIG$(SPL_TPL_)ENV_IS_NOWHERE.

Since the commit 208bd2b85ecc ("env: allow ENV_IS_NOWHERE with
other storage target"), is is allowed to activated ENV_IS_NOWHERE with
other CONFIG_IS_IN...
It is only the case for U-Boot but the restriction in Kconfig
could also removed for SPL and TPL
(depends on !SPL_ENV_IS_NOWHERE / depends on !TPL_ENV_IS_NOWHERE).

This macro ENV_IS_IN_DEVICE can be used in code to check if the
environment for U-Boot / SPL / TPL is really managed (at least one
CONFIG$(SPL_TPL_)ENV_IS_IN_.. is activated).

Signed-off-by: Patrick Delaunay 
---

Changes in v3: None
Changes in v2: None

 cmd/nvedit.c  | 29 +++--
 include/env.h | 13 +
 2 files changed, 20 insertions(+), 22 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 1cb0bc1460..7a6ec5ae30 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -40,28 +40,13 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdefined(CONFIG_ENV_IS_IN_EEPROM)|| \
-   defined(CONFIG_ENV_IS_IN_FLASH) || \
-   defined(CONFIG_ENV_IS_IN_MMC)   || \
-   defined(CONFIG_ENV_IS_IN_FAT)   || \
-   defined(CONFIG_ENV_IS_IN_EXT4)  || \
-   defined(CONFIG_ENV_IS_IN_NAND)  || \
-   defined(CONFIG_ENV_IS_IN_NVRAM) || \
-   defined(CONFIG_ENV_IS_IN_ONENAND)   || \
-   defined(CONFIG_ENV_IS_IN_SATA)  || \
-   defined(CONFIG_ENV_IS_IN_SPI_FLASH) || \
-   defined(CONFIG_ENV_IS_IN_REMOTE)|| \
-   defined(CONFIG_ENV_IS_IN_UBI)
-
-#define ENV_IS_IN_DEVICE
-
-#endif
-
-#if!defined(ENV_IS_IN_DEVICE)  && \
-   !defined(CONFIG_ENV_IS_NOWHERE)
+#if !defined(CONFIG_SPL_BUILD) || CONFIG_IS_ENABLED(ENV_SUPPORT)
+#if!ENV_IS_IN_SOMEWHERE&& \
+   !CONFIG_IS_ENABLED(ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|MMC|FAT|EXT4|\
 NAND|NVRAM|ONENAND|SATA|SPI_FLASH|REMOTE|UBI} or CONFIG_ENV_IS_NOWHERE
 #endif
+#endif
 
 /*
  * Maximum expected input data size for import command
@@ -744,7 +729,7 @@ ulong env_get_ulong(const char *name, int base, ulong 
default_val)
 }
 
 #ifndef CONFIG_SPL_BUILD
-#if defined(CONFIG_CMD_SAVEENV) && defined(ENV_IS_IN_DEVICE)
+#if defined(CONFIG_CMD_SAVEENV) && ENV_IS_IN_SOMEWHERE
 static int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc,
   char * const argv[])
 {
@@ -1309,7 +1294,7 @@ static cmd_tbl_t cmd_env_sub[] = {
 #if defined(CONFIG_CMD_RUN)
U_BOOT_CMD_MKENT(run, CONFIG_SYS_MAXARGS, 1, do_run, "", ""),
 #endif
-#if defined(CONFIG_CMD_SAVEENV) && defined(ENV_IS_IN_DEVICE)
+#if defined(CONFIG_CMD_SAVEENV) && ENV_IS_IN_SOMEWHERE
U_BOOT_CMD_MKENT(save, 1, 0, do_env_save, "", ""),
 #if defined(CONFIG_CMD_ERASEENV)
U_BOOT_CMD_MKENT(erase, 1, 0, do_env_erase, "", ""),
@@ -1392,7 +1377,7 @@ static char env_help_text[] =
 #if defined(CONFIG_CMD_RUN)
"env run var [...] - run commands in an environment variable\n"
 #endif
-#if defined(CONFIG_CMD_SAVEENV) && defined(ENV_IS_IN_DEVICE)
+#if defined(CONFIG_CMD_SAVEENV) && ENV_IS_IN_SOMEWHERE
"env save - save environment\n"
 #if defined(CONFIG_CMD_ERASEENV)
"env erase - erase environment\n"
diff --git a/include/env.h b/include/env.h
index a74a261337..0088d3b1e8 100644
--- a/include/env.h
+++ b/include/env.h
@@ -35,6 +35,19 @@ struct env_clbk_tbl {
int flags);
 };
 
+#define ENV_IS_IN_SOMEWHERE \
+   (CONFIG_IS_ENABLED(ENV_IS_IN_EEPROM) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_EXT4) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_FAT) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_FLASH) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_MMC) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_NAND) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_NVRAM) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_ONENAND) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_REMOTE) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_SPI_FLASH) || \
+CONFIG_IS_ENABLED(ENV_IS_IN_UBI))
+
 /*
  * Define a callback that can be associated with variables.
  * when associated through the ".callbacks" environment variable, the callback
-- 
2.17.1

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

[U-Boot] [RESEND][PATCH v2] configs: ls1012ardb: Add CONFIG_ENV_ADDR for LS1012ARDB

[Kuldeep Singh]

This configuration helps in picking the environment from flash before
DDR init.

Signed-off-by: Ashish Kumar 
Signed-off-by: Kuldeep Singh 
---
v2:
Reword commit message

 include/configs/ls1012ardb.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/configs/ls1012ardb.h b/include/configs/ls1012ardb.h
index f6640fa499..a5e27404f8 100644
--- a/include/configs/ls1012ardb.h
+++ b/include/configs/ls1012ardb.h
@@ -17,6 +17,10 @@
 #define CONFIG_SYS_MEMTEST_END 0x9fff
 
 
+/* ENV */
+#define CONFIG_SYS_FSL_QSPI_BASE   0x4000
+#define CONFIG_ENV_ADDR(CONFIG_SYS_FSL_QSPI_BASE + \
+CONFIG_ENV_OFFSET)
 /*
  * I2C IO expander
  */
-- 
2.17.1

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

[U-Boot] [PATCH v2] armv8: ls1028a: add more personalities support

[Yuantian Tang]

Add LS1027A, LS1018A and LS1017A  personalities support to
LS1028A processor soc family.

LS1028A processor is the prime personality of LS1028A soc family.
LS1027A processor is a lower funtionality version of QorIQ LS1028A
which does not support the multimedia subsystems, such as LCD
controller, GPU, and eDP PHY.
The QorIQ LS1018A and LS1017A are low power versions of the QorIQ
LS1028A and LS1027A processors, respectively which integrate single
64-bit Arm A72 core.

Signed-off-by: Tang Yuantian 
---
v2:
- refine description
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 3 +++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 3e2a24fe80..dee96afe2d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -58,6 +58,9 @@ static struct cpu_type cpu_type_list[] = {
CPU_TYPE_ENTRY(LS1026A, LS1026A, 2),
CPU_TYPE_ENTRY(LS2040A, LS2040A, 4),
CPU_TYPE_ENTRY(LS1012A, LS1012A, 1),
+   CPU_TYPE_ENTRY(LS1017A, LS1017A, 1),
+   CPU_TYPE_ENTRY(LS1018A, LS1018A, 1),
+   CPU_TYPE_ENTRY(LS1027A, LS1027A, 2),
CPU_TYPE_ENTRY(LS1028A, LS1028A, 2),
CPU_TYPE_ENTRY(LS1088A, LS1088A, 8),
CPU_TYPE_ENTRY(LS1084A, LS1084A, 8),
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h

--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -83,6 +83,9 @@ enum boot_src get_boot_src(void);
 /* LS1043A/LS1023A 23x23 package silicon has different value of VAR_PER */
 #define SVR_LS1043A_P230x879202
 #define SVR_LS1023A_P230x87920A
+#define SVR_LS1017A0x870B24
+#define SVR_LS1018A0x870B20
+#define SVR_LS1027A0x870B04
 #define SVR_LS1028A0x870B00
 #define SVR_LS1046A0x870700
 #define SVR_LS1026A0x870708
-- 
2.17.1

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

[U-Boot] [PATCH] armv8: ls1028a: add more personalities support

[Yuantian Tang]

Add LS1027A, LS1018A and LS1017A  personalities support to
LS1028A processor soc family.

LS1028A processor is the prime personality of LS1028A soc family.
LS1027A processor is a lower funtionality version of QorIQ LS1028A
which does not support the multimedia subsystems, such as LCD
controller, GPU, and eDP PHY.
The QorIQ LS1018A and LS1017A are low power versions of the QorIQ
LS1028A and LS1027A processors, respectively which integrate single
64-bit Arm A72 core.

Signed-off-by: Tang Yuantian 
---
 arch/arm/cpu/armv8/fsl-layerscape/cpu.c| 3 +++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c 
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 3e2a24fe80..dee96afe2d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -58,6 +58,9 @@ static struct cpu_type cpu_type_list[] = {
CPU_TYPE_ENTRY(LS1026A, LS1026A, 2),
CPU_TYPE_ENTRY(LS2040A, LS2040A, 4),
CPU_TYPE_ENTRY(LS1012A, LS1012A, 1),
+   CPU_TYPE_ENTRY(LS1017A, LS1017A, 1),
+   CPU_TYPE_ENTRY(LS1018A, LS1018A, 1),
+   CPU_TYPE_ENTRY(LS1027A, LS1027A, 2),
CPU_TYPE_ENTRY(LS1028A, LS1028A, 2),
CPU_TYPE_ENTRY(LS1088A, LS1088A, 8),
CPU_TYPE_ENTRY(LS1084A, LS1084A, 8),
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/soc.h 
b/arch/arm/include/asm/arch-fsl-layerscape/soc.h

--- a/arch/arm/include/asm/arch-fsl-layerscape/soc.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/soc.h
@@ -83,6 +83,9 @@ enum boot_src get_boot_src(void);
 /* LS1043A/LS1023A 23x23 package silicon has different value of VAR_PER */
 #define SVR_LS1043A_P230x879202
 #define SVR_LS1023A_P230x87920A
+#define SVR_LS1017A0x870B24
+#define SVR_LS1018A0x870B20
+#define SVR_LS1027A0x870B04
 #define SVR_LS1028A0x870B00
 #define SVR_LS1046A0x870700
 #define SVR_LS1026A0x870708
-- 
2.17.1

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

Re: [U-Boot] Ethernet on i.MX8MM with mainline U-Boot

[Peng Fan]

Hi Frider,

> -Original Message-
> From: Schrempf Frieder 
> Sent: 2019年9月17日 21:49
> To: Peng Fan 
> Cc: u-boot@lists.denx.de
> Subject: Ethernet on i.MX8MM with mainline U-Boot
> 
> Hi Peng,
> 
> I tried to get Ethernet running on i.MX8MM with mainline U-Boot and your
> latest patches for SoC-support.
> I added the missing clocks, but something still seems to be wrong. It seems
> like the clock parents are not set correctly.
> 
> If I run "dm tree", I see that the enet_axi is a child of clock-osc-24m, but I
> would expect it to be under sys_pll1_266m as specified in the devicetree.
> 
> Do you have an idea what could be wrong or some working code to look at?

I think it might be clk_set_defaults not work for U-Boot proper.
I have not tried enet. Will give a look.

Regards,
Peng.

> 
> Thanks for your help!
> 
> Regards,
> Frieder
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 3/4] imx6: spl: Reduce SPL limit size in case CONFIG_SECURE_BOOT is enabled

[Stefano Babic]

Hi Jagan, Breno,

On 17/09/19 09:13, Jagan Teki wrote:
> Hi Breno,
> 
> On Thu, Jul 18, 2019 at 6:06 PM Breno Matheus Lima  wrote:
>>
>> In case CONFIG_SECURE_BOOT is enabled we need to limit the SPL size to
>> avoid a possible HAB failure event:
>>
>> - HAB Event 1 -
>> event data:
>> 0xdb 0x00 0x14 0x42 0x33 0x22 0x33 0x00
>> 0x00 0x00 0x00 0x0f 0x00 0x90 0x70 0x00
>> 0x00 0x01 0x10 0x00
>> STS = HAB_FAILURE (0x33)
>> RSN = HAB_INV_ADDRESS (0x22)
>> CTX = HAB_CTX_TARGET (0x33)
>> ENG = HAB_ENG_ANY (0x00)
>>
>> As explained in Commit 23612534fe0f ("spl: imx6: Provide a SPL_SIZE_LIMIT
>> default") the i.MX6 SPL size limit is 68KB.
>>
>> The ROM code is copying the image size defined in boot data to its
>> respective load address, in case we exceed the OCRAM free region a
>> HAB invalid address failure event is generated.
>>
>> The maximum CSF size is defined in CONFIG_CSF_SIZE, reduce SPL size
>> limit based on this configuration.
>>
>> Signed-off-by: Breno Lima 
>> ---
>>  tools/spl_size_limit.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/tools/spl_size_limit.c b/tools/spl_size_limit.c
>> index 98ff491867..8902e30129 100644
>> --- a/tools/spl_size_limit.c
>> +++ b/tools/spl_size_limit.c
>> @@ -14,6 +14,9 @@ int main(int argc, char *argv[])
>>
>>  #ifdef CONFIG_SPL_SIZE_LIMIT
>> spl_size_limit = CONFIG_SPL_SIZE_LIMIT;
>> +#if defined(CONFIG_SECURE_BOOT) && defined(CONFIG_CSF_SIZE)
>> +   spl_size_limit -= CONFIG_CSF_SIZE;
>> +#endif
> 
> But, if the target enable HAB on SPL the size would be part of SPL
> limit, isn't ?

Indeed - it is not clear to me, too, if it is correct, even if CSF is
added later by the NXP signing tools. The patch reduces significantly
the available space for SPL, I just wondering why just mamoj is
affected. Jagan, does it work without this patch applied ?

Regards,
Stefano

> 
> Just now I have looked at this, since one of my board (imx6_mamoj)
> fails to build.
> 
> Jagan.
> 


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

Re: [U-Boot] [U-BOOT PATCH v1 2/2] configs: fu540: enable gpio driver

[Bin Meng]

On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam
 wrote:
>
> Enable the DM based GPIO driver for FU540-C000 SoC.
>
> Signed-off-by: Sagar Shrikant Kadam 
> ---
>  board/sifive/fu540/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-BOOT PATCH v1 0/2] add gpio support for HiFive Unleashed A00 board.

[Bin Meng]

Hi Sagar,

On Tue, Sep 10, 2019 at 11:44 PM Sagar Shrikant Kadam
 wrote:
>
> U-Boot currently is missing GPIO support for FU540-C000 SoC which is
> mounted on HiFive Unleashed A00 board. This patch is intended to add DM
> based GPIO controller driver in order to access GPIO pins within the SoC
> using GPIO command in U-Boot. More details on the GPIO controller within
> the SoC can be found at[1]
>
> The driver is based above master branch of u-boot-riscv.git and provides a
> method to configure Input/Output mode of the GPIO pin along with an option
> to set or clear state of the GPIO pin. The patch is available in
> dev/sagark/gpio_v3 branch here[2].
>
> GPIO device node added to the mainline bound device tree for HiFive
> Unleashed is available in dev/sagark/mlv5.3-rc5 branch of repo here[3].
>
> This implementation is ported from linux driver submitted for review
> at [4].
>
> More details of GPIO pin routing on J1 header is available in schematic
> document[5]
>
> [1] https://static.dev.sifive.com/FU540-C000-v1.0.pdf
> [2] https://github.com/sagsifive/u-boot
> [3] https://github.com/sagsifive/riscv-linux-hifive/
> [4] https://lkml.org/lkml/2018/10/9/1103
> [5] 
> https://static.dev.sifive.com/dev-kits/hifive-unleashed/hifive-unleashed-a00-schematics.pdf
>
> Driver Testing:
> #Set GPIO1 high.
> =>gpio set 1
>   Can be confirmed by probing pin No #24 on J1 Header or memory dump of
>   gpio register space viz: #md 0x1006
>
> #Set GPIO1 low
> =>gpio clear 0
>
> #Toggle GPIO1
> =>gpio toggle 1 #Toggle value of GPIO1
> =>gpio toggle 1 #Toggle value of GPIO1
>
> #Configure pin as input
> =>gpio input 3  #Configure gpio line 3 as input.
>
> #Error check
> =>gpio set 16   #Not a valid GPIO number for FU540-C000
>   GPIO: '16' not found
>   Command 'gpio' failed: Error -22
>

I tested this:

=> gpio status -a
Bank gpio@1006:
gpio@10060: unknown
gpio@10061: unknown
gpio@10062: unknown
gpio@10063: unknown
gpio@10064: unknown
gpio@10065: unknown
gpio@10066: unknown
gpio@10067: unknown
gpio@10068: unknown
gpio@10069: unknown
gpio@100610: unknown
gpio@100611: unknown
gpio@100612: unknown
gpio@100613: unknown
gpio@100614: unknown
gpio@100615: unknown

The status is "unknown" for all gpio pins, which is wrong. It should
be either input or output.

Also the gpio pin name is weird. I think we should use "0, 1, 2 ..."

Regards,
Bin

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

Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms

[Stefan Roese]

Hi Frieder,

On 18.09.19 09:08, Schrempf Frieder wrote:




One further update on this QSPI driver. This driver only works when
loaded via "imx_usb" on the i.MX6ULL EVK. When programmed into QSPI
and booted from QSPI this driver does not detect the SPI NOR
flash:

=> sf probe
unrecognized JEDEC id bytes: ff, ff, ff

Do you have any idea what might explain this difference. I would have
expected that when booting via QSPI it would be "easier" for the
driver, as the BootROM already initializes the QSPI interface. Which
is not the case in the boot via serial download (imx_usb) mode. Here
everyhting (pinmux, clocks, etc) need to be configured.

My feeling is that something is configured "incorrectly" by the
BootROM in this case which is not re-configured as the QSPI driver
needs it to be currently.

Do you have any ideas on what might be the problem here? Is there
something that I can do to help test this? Would it help if I would
send the debug logging of the driver?


I have a strong suspicion of what goes wrong in your case. We
experienced exactly the same issue recently on i.MX6ULL. For some
reasons (I guess differences in BootROM) this does not happen on i.MX6UL.

The problem is, that the BootROM sets the TDH bits in the QuadSPI_FLSHCR
register to '01' in case it uses the DDR mode. Afterwards when U-Boot or
Linux try to access the flash in SDR mode, they fail as the TDH bits are
still set. Resetting them to '00' solves the problem.

Unfortunately the TDH bits are not documented in the manual of the
i.MX6UL/ULL, but they can be found in the manual of the i.MX7.

For the QSPI driver, this means it needs a fix to set/reset the TDH bits
according to the mode that is used (DDR/SDR).

For more details please also look here:
https://community.nxp.com/thread/507260


Perfect. With these bits set to 00 again, booting from QSPI now
works on the EVK. Many thanks for this hint! :)

BTW: When receiving your mail I was just comparing the registers
settings and wondering about this difference in bit 16 as well. ;)

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

Re: [U-Boot] [EXT] Re: [PATCH 1/6] spi: fsl_qspi: Fix DDR mode setting for latest iMX platforms

[Schrempf Frieder]

Hi Stefan,

On 18.09.19 06:51, Stefan Roese wrote:
> Hi Ashish,
> 
> On 13.09.19 15:11, Stefan Roese wrote:
>> On 12.09.19 14:36, Stefan Roese wrote:
>>
>> 
>>
 The spi-mem version is still under debug, I could make it working
 for ls1088rdb, ls1046rdb, but it is failing for
 ls1012ardb and ls2088ardb and untested for i.mx and other Layerscape
 silicon/boards . It is derived from work done by Frieder earlier.
 This version can be found here:
 https://github.com/erashish007/u-boot-spi-mem/tree/spi-mem-port
>>>
>>> Many thanks. I did some tests with this version and it seems to work
>>> fine in general on the i.MX6ULL EVK. My first tests show that reading
>>> and writing has no issues. So this is very promising. The only thing
>>> I noticed is, that when using SPI for environment via
>>> CONFIG_ENV_IS_IN_SPI_FLASH, the board hangs upon bootup while trying
>>> to read the env. Since you already added some debug print's to the
>>> env code, I suspect that you also did run into this problem.
>>>
>>> I'll try to help with this driver version. At least I can debug this
>>> env issue and can always do some test on my mx6ull platform for you
>>> once you have any updates here. Just let me know.
>>
>> Okay, this one with the env in SPI NOR is fixed. Its a problem with
>> your PR debug printf macro. Please change it this way:
>>
>> -#define PR(fmt, ...) \
>> -    fprintf(stderr, "DEBUG: %s:%d:%s(): " fmt" \n", \
>> +#define PR(fmt, ...)    \
>> +    printf("DEBUG: %s:%d:%s(): " fmt" \n", \
>>
>> With this change, I can successfully boot with SPI NOR environment
>> on my board. I will do some further tests with your driver next
>> week and will get back to you with the results. Please keep me in
>> the loop, if you have updates on the driver.
> 
> One further update on this QSPI driver. This driver only works when
> loaded via "imx_usb" on the i.MX6ULL EVK. When programmed into QSPI
> and booted from QSPI this driver does not detect the SPI NOR
> flash:
> 
> => sf probe
> unrecognized JEDEC id bytes: ff, ff, ff
> 
> Do you have any idea what might explain this difference. I would have
> expected that when booting via QSPI it would be "easier" for the
> driver, as the BootROM already initializes the QSPI interface. Which
> is not the case in the boot via serial download (imx_usb) mode. Here
> everyhting (pinmux, clocks, etc) need to be configured.
> 
> My feeling is that something is configured "incorrectly" by the
> BootROM in this case which is not re-configured as the QSPI driver
> needs it to be currently.
> 
> Do you have any ideas on what might be the problem here? Is there
> something that I can do to help test this? Would it help if I would
> send the debug logging of the driver?

I have a strong suspicion of what goes wrong in your case. We 
experienced exactly the same issue recently on i.MX6ULL. For some 
reasons (I guess differences in BootROM) this does not happen on i.MX6UL.

The problem is, that the BootROM sets the TDH bits in the QuadSPI_FLSHCR 
register to '01' in case it uses the DDR mode. Afterwards when U-Boot or 
Linux try to access the flash in SDR mode, they fail as the TDH bits are 
still set. Resetting them to '00' solves the problem.

Unfortunately the TDH bits are not documented in the manual of the 
i.MX6UL/ULL, but they can be found in the manual of the i.MX7.

For the QSPI driver, this means it needs a fix to set/reset the TDH bits 
according to the mode that is used (DDR/SDR).

For more details please also look here: 
https://community.nxp.com/thread/507260

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

Re: [U-Boot] Odroid n1- booting hangs if we add memtest=4 to kernel command line.

[Kever Yang]

Hi Anand,


On 2019/9/16 下午7:03, Anand Moon wrote:

Hi Jagan / Kever,

I have with me Odroid - N1 per-released development board,
It's almost same form factor to "Firefly-RK3399 Board" with
rk3399-sdram-ddr3-1600.dtsi ram configuration.

I have configure Odroid - N1 board to boot using TPL / SPL configuration
using latest kernel and latest u-boot, but I am facing some issue with not
able to upgrade my distro packages, It's literally hangs on heavy I/O
operations.

So I would like to check if the memory is working correctly, but below
command failed.

# sudo memtester 1024 5
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xf000
want 1024MB (1073741824 bytes)
got  1024MB (1073741824 bytes), trying mlock ...

Then I would like to enable *memtest=4* via bootargs ie kernel command
line and it failed to boot up.



I'm not able to understand well about your issue, does it:
- boots fine with odroid-N1 but hang at memtester ?
- hang at "Starting kernel..." with kernel command like update
Since it boots OK, the DRAM should works OK, you can replace the TPL 
with rockchip binary ddr[0]

to double check if they have the same output.
I have no idea about the bootargs "memtest=4", but I suppose this should 
not affect the kernel
boot process, maybe you have do something wrong and not update the 
bootargs as what you

expect, you can print it in U-Boot to check the actually bootargs.

Thanks,
- Kever
[0] 
https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk3399_ddr_800MHz_v1.23.bin 


below is the logs.
---
U-Boot TPL 2019.10-rc3-00320-g23b93e33ad-dirty (Sep 16 2019 - 18:17:38)
con reg
cru , cic , grf , sgrf , pmucru , pmu
Starting SDRAM initialization...
sdram_init: data trained for rank 2, ch 0
sdram_init: data trained for rank 2, ch 1
Channel 0: sdram_init: data train failed for channel 0
Channel 1: sdram_init: data train failed for channel 0
256B stride
cic: ctr10  : (0xff62 - 0x14)
cic: status0: (0xff620010 - 0x101)
grf: ddrc0_con0 : (0xff77e380 - 0x1f81)
grf: ddrc1_con0 : (0xff77e388 - 0x1f81)
grf: soc_con0   : (0xff77e200 - 0x0)
pmu: noc_auto_ena : (0xff3100d8 - 0x0)
pmu: bus_idle_req : (0xff310060 - 0x0)
pmu: bus_idle_st : (0xff310064 - 0x0)
pmugrf: os_reg2 : (0xff320308 - 0x3aa17aa1)
pmugrf: os_reg3 : (0xff32030c - 0x2005)
pmusgrf: soc_con4 : (0xff33e010 - 0x3600)
Finish SDRAM initialization...
Trying to boot from BOOTROM
Returning to boot ROM...

U-Boot SPL 2019.10-rc3-00320-g23b93e33ad-dirty (Sep 16 2019 - 18:17:38 +0530)
Trying to boot from MMC1
NOTICE:  BL31: v2.1(release):v2.1-705-g42cdeb93
NOTICE:  BL31: Built : 18:17:28, Sep 16 2019


U-Boot 2019.10-rc3-00320-g23b93e33ad-dirty (Sep 16 2019 - 18:19:19 +0530)

Model: Hardkernel ODROID-N1
DRAM:  rk3399_dmc_probe: pmugrf = ff32
3.9 GiB
MMC:   dwmmc@fe32: 1, sdhci@fe33: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:serial@ff1a
Out:   serial@ff1a
Err:   serial@ff1a
Model: Hardkernel ODROID-N1
rockchip_dnl_key_pressed: adc_channel_single_shot fail!
Net:
Warning: ethernet@fe30 (eth0) using random MAC address - f2:12:d7:dd:0e:72
eth0: ethernet@fe30
Hit any key to stop autoboot:  0
Card did not respond to voltage select!
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
871 bytes read in 5 ms (169.9 KiB/s)
## Executing script at 0050
24838656 bytes read in 1049 ms (22.6 MiB/s)
56286 bytes read in 10 ms (5.4 MiB/s)
7326472 bytes read in 314 ms (22.3 MiB/s)
## Flattened Device Tree blob at 01f0
Booting using the fdt blob at 0x1f0
Loading Ramdisk to f5818000, end f5f14b08 ... OK
Loading Device Tree to f5807000, end f5817fff ... OK

Starting kernel ...

-
Can you share some input on how to resolve this issue?
or is it I am missing some configuration.

Here is the normal boot log of the
[0] https://pastebin.com/AxmqxeuU

Best Regards
-Anand

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