Re: [U-Boot] [PATCH v2 6/6] net: macb: Add compatible string for MACB on SiFive Unleashed

[Bin Meng]

Hi Anup,

On Wed, Jun 19, 2019 at 12:01 PM Anup Patel  wrote:
>
> We have a separate compatible string for MACB ethernet on SiFive
> Unleashed so this patch adds the SiFive MACB compatible string to
> the MACB ethernet driver.
>
> Signed-off-by: Anup Patel 
> ---
>  drivers/net/macb.c | 1 +
>  1 file changed, 1 insertion(+)
>

You need add the codes to handle the 10/100/1000Mbps link speed
changes since you dropped the gemgxl clock driver.

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

Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot partitions

[Peng Fan]

gauri.org>; Marek Vasut
> 
> Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing boot
> partitions
> 
> Hi Peng, Marek,
> 
> On 18/06/19 10:33 AM, Peng Fan wrote:
> >> Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode when accessing
> >> boot partitions
> >>
> >> On 6/17/19 4:46 PM, Jean-Jacques Hiblot wrote:
> >>>
> >>> On 17/06/2019 12:34, Marek Vasut wrote:
>  On 6/17/19 11:09 AM, Jean-Jacques Hiblot wrote:
> > On 15/06/2019 17:15, Marek Vasut wrote:
> >> On 6/14/19 5:27 PM, Jean-Jacques Hiblot wrote:
> >>> Marek, Faiz,
> >>>
> >>> On 11/06/2019 17:59, Faiz Abbas wrote:
>  Hi Marek,
> 
>  On 11/06/19 3:34 PM, Marek Vasut wrote:
> > On 6/11/19 10:12 AM, Faiz Abbas wrote:
> >> Peng, Marek,
> >>
> >> On 11/06/19 6:47 AM, Peng Fan wrote:
>  partitions
> 
>  On 6/10/19 7:59 AM, Peng Fan wrote:
> >> Subject: Re: [U-Boot] [PATCH] mmc: Avoid HS400 mode
> when
> >> accessing boot partitions
> >>
> >> Hi Marek, Peng,
> >>
> >> On 03/06/19 12:04 PM, Peng Fan wrote:
>  Subject: [PATCH] mmc: Avoid HS400 mode when
> accessing
>  boot partitions
> 
>  According to JEDEC JESD84-B51.pdf section 6.3.3 Boot
>  operation ,
>  HS200 & HS400 mode is not supported during boot
> >> operation.
>  The
>  U-Boot code currently only applies this restriction to
>  HS200 mode, extend this to
>  HS400 mode as well.
> >> The spec in section 6.3.3 (according to my understanding)
> >> is talking about "boot operation" which is a way of
> >> getting data from the the eMMC without going through the
> >> Device identification mode (Section
> >> 6.4.4) i.e. without sending any commands. All the host
> >> has to do is hold the command line low in Pre-Idle mode
> >> to automatically receive data at the preconfigured
> >> frequency and bus width.
> >>
> >> When U-boot is accessing the partition, it has already
> >> gone through the Device identification mode and is in
> >> data transfer mode (i.e. it needs to send commands for
> >> read/write to happen). In this case, we need to switch
> >> the partition in Extended CSD to access the boot
> >> partition (Section 6.2.5). The spec doesn't say anything
> >> about
> >> HS200 and
>  HS400 not being supported here.
> > Yes, the spec does not mention this. It only mentions
> > HS200/400 not supported during boot operation.
> >
> >> Also, I don't see linux kernel switching down speed when
> >> trying to access a boot partition (unless its being very
> >> sneaky about it). So if you are seeing issues with
> >> accessing boot partitions at
> >> HS200/HS400 then you should probably look at how linux
> >> code is working
>  instead.
> > There might be bug in U-Boot code.
>  So are we gonna leave this inconsistency in for current
>  release or what's it gonna be ? Like I said, we're in rc3,
>  it's fine to do bigger changes in next release, but we
>  should at least fix this in current release.
> >>> I'll pick up your patch in this release.
> >>>
> >> The issue that Marek is facing is not a regression, is it?
> >> Are we really going to merge something that we know to be
> >> wrong just so we are consistently wrong?
> > First of all, you established this is "wrong" without any real
> > backing except for your interpretation of the specification. I
> > would still like to hear from Jean the real reason why he
> > added this filtering in the first place.
>  I think Peng agrees with my interpretation. The backing for it
>  being "right" is also JJ's and your interpretation of spec. The
>  additional justification that I am trying to give is that there
>  is no code to fallback in kernel and I have observed it working
>  in kernel with no issues. I needed your observations (with any
>  HS200/HS400 supporting
>  platform) in kernel for additional data points.
> 
> > That said, we're in rc4 , the release is just around the corner.
> > I would like to avoid big changes in the MMC subsystem , or
> > any subsystem for that matter. That's for next release , and
> > if you have a patch for next, please post it, I am happy to
> > test it on the hardware I have available.
>  I am not saying 

Re: [U-Boot] [PATCH 0/4] Update SiFive Unleashed Clock Driver

[Anup Patel]

On Wed, Jun 19, 2019 at 8:41 AM Troy Benjegerdes
 wrote:
>
>
>
> > On Jun 18, 2019, at 4:18 AM, Anup Patel  wrote:
> >
> > This series update SiFive Unleashed clock driver so that:
> > 1. It is in sync with upstream Linux driver
> > 2. It uses latest DT bindings as-per upstream Linux driver
> >
> > With this series, we can now use latest DT bindings with U-Boot. I have
> > tested SiFive Serial driver and Cadence MACB ethernet driver with this
> > changes and both work fine.
> >
> > The legacy FSBL will still pass DTB to U-Boot with older DT bindings
> > which will break the updated SiFive Unleashed clock driver. To tackle
> > this, we have embedded DTB in OpenSBI FW_PAYLOAD firmware for SiFive
> > Unleashed so that OpenSBI will override and pass updated DTB to U-Boot.
> >
> > In fact, the updated DTB passed by OpenSBI can be used by latest Linux
> > (i.e. V5.2-rc1 or higher) as well.
> >
> > The OpenSBI changes to embed SiFive Unleashed DTB can be found in
> > sifive_unleashed_dtb_fix_v1 branch of:
> > https://github.com/avpatel/opensbi.git
> >
> > This series can be found in riscv_unleashed_clk_sync_v1 branch of:
> > https://github.com/avpatel/u-boot.git
>
> There are some discrepancies I’m finding in the clocking… If I use the
> HiFive_U-Boot as FSBL, it does the following (with some extra debug
> code)
>
> U-Boot 2018.09-g8bbdd51-dirty (Jun 18 2019 - 19:46:55 -0700)
>
> DRAM:  2 GiB
> MMC:
> In:serial
> Out:   serial
> Err:   serial
> Net:   gem_mdc_clk_div: macb_hz: 5
> gmac0
> Hit any key to stop autoboot:  0
>
> Where as the close-to-u-boot master version does this:
>
> U-Boot 2019.07-rc4-05661-gc998035-dirty (Jun 18 2019 - 19:51:10 -0700)
>
> CPU:   rv64imafdc
> Model: sifive,hifive-unleashed-a00
> DRAM:  8 GiB
> In:serial@1001
> Out:   serial@1001
> Err:   serial@1001
> Net:   gem_mdc_clk_div: macb_hz: 93324
>
> For reference, I’ve checked all my changes into the ‘dev/new-dts’ branch
> of github.com/tmagik/freedom-u-sdk, and the ‘make test_s’ target will build
> and then copy various files to /var/lib/tftpboot to run the test, and assumes
> you have a DHCP and TFTP server running locally.
>
> Another issue with the mainline u-boot is it does not have the OTP driver
> that the HiFive_U-Boot version does, so when it selects a random mac
> address this causes TFTP to fail in one of my test environments.
>
> FYI, the patch applied is:
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 5a6cba5..d21026d 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -813,6 +813,8 @@ static u32 macb_mdc_clk_div(int id, struct macb_device 
> *macb)
> unsigned long macb_hz = 
> HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
>  #endif
>
> +   printf("%s: macb_hz: %d\n", __func__, macb_hz);
> +
> if (macb_hz < 2000)
> config = MACB_BF(CLK, MACB_CLK_DIV8);
> else if (macb_hz < 4000)
> @@ -835,6 +837,7 @@ static u32 gem_mdc_clk_div(int id, struct macb_device 
> *macb)
> unsigned long macb_hz = 
> HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
>  #endif
>
> +   printf("%s: macb_hz: %d\n", __func__, macb_hz);
> if (macb_hz < 2000)
> config = GEM_BF(CLK, GEM_CLK_DIV8);
> else if (macb_hz < 4000)

We had noticed this difference when we first got upstream U-Boot
MACB driver working on SiFive Unleashed board.

The real issue is the hard-coding in HiFive_U-Boot because even the
Linux MACB driver sees different value. The clock frequency we see
upstream U-Boot matches Linux MACB driver because we are using
similar SiFive clock driver. (@Atish, please correct me if I am wrong
here?)

Eventually, we realized that hard-coding in HiFive_U-Boot for MACB
driver is just a HACK. There were lot of such hacks in HiFive_U-Boot
without any GIT history. We trust the upstream Linux drivers more
hence took those as reference for upstream U-Boot.

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

Re: [U-Boot] [PATCH] driver: watchdog: Add new iMX/LSCH2 WDT driver

[Stefan Roese]

Hi Robert,

(Cc'ing Marek and Heiko)

On 18.06.19 17:52, Robert Hancock wrote:

This is a new watchdog timer driver for iMX and LSCH2 using the WDT
framework and driver model. This allows ensuring that U-Boot uses the
same watchdog timer instance and same settings (ex: internal or external
reset) specified in the device tree.

This driver can be used in preference to the old imx_watchdog driver for
boards which have been converted to use the driver model.

Signed-off-by: Robert Hancock 


Marek just recently added DM (WDT) support to the imx driver:

https://patchwork.ozlabs.org/patch/1112591/
https://patchwork.ozlabs.org/patch/1112592/

Please take a look at this driver.

Thanks,
Stefan


---
  drivers/watchdog/Kconfig   |  14 --
  drivers/watchdog/Makefile  |   3 ++
  drivers/watchdog/imx_wdt.c | 112 +
  3 files changed, 126 insertions(+), 3 deletions(-)
  create mode 100644 drivers/watchdog/imx_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index dbafb74..0e8c8e5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -27,11 +27,11 @@ config BCM2835_WDT
  hardware, with a max timeout of ~15secs.
  
  config IMX_WATCHDOG

-   bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
+   bool "Enable legacy Watchdog Timer support for IMX and LSCH2 of NXP"
select HW_WATCHDOG
help
-  Select this to enable the IMX and LSCH2 of Layerscape watchdog
-  driver.
+  Select this to enable the IMX and LSCH2 of Layerscape legacy watchdog
+  driver (not using driver model).
  
  config OMAP_WATCHDOG

bool "TI OMAP watchdog driver"
@@ -109,6 +109,14 @@ config WDT_CDNS
   Select this to enable Cadence watchdog timer, which can be found on 
some
   Xilinx Microzed Platform.
  
+config WDT_IMX

+   bool "iMX/LSCH2 watchdog timer support"
+   depends on WDT && (ARCH_MX25 || ARCH_MX31 || ARCH_MX35 || ARCH_MX5 || 
ARCH_MX6 || ARCH_MX7 || ARCH_VF610)
+   imply WATCHDOG
+   help
+  Select this to enable the IMX and LSCH2 of Layerscape watchdog
+  driver using driver model.
+
  config WDT_MPC8xx
bool "MPC8xx watchdog timer support"
depends on WDT && MPC8xx
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index e3f4fdb..49dd457 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -5,11 +5,13 @@
  
  obj-$(CONFIG_WDT_AT91) += at91sam9_wdt.o

  obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o
+ifndef CONFIG_WDT_IMX
  ifneq (,$(filter $(SOC), mx25 mx31 mx35 mx5 mx6 mx7 vf610))
  obj-y += imx_watchdog.o
  else
  obj-$(CONFIG_IMX_WATCHDOG) += imx_watchdog.o
  endif
+endif
  obj-$(CONFIG_S5P)   += s5p_wdt.o
  obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
  obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
@@ -24,6 +26,7 @@ obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
  obj-$(CONFIG_BCM2835_WDT)   += bcm2835_wdt.o
  obj-$(CONFIG_WDT_ORION) += orion_wdt.o
  obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
+obj-$(CONFIG_WDT_IMX) += imx_wdt.o
  obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
  obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
  obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
diff --git a/drivers/watchdog/imx_wdt.c b/drivers/watchdog/imx_wdt.c
new file mode 100644
index 000..1b4a5e6
--- /dev/null
+++ b/drivers/watchdog/imx_wdt.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * imx_wdt.c - WDT driver for Freescale/NXP i.MX on-chip watchdog
+ * Copyright (c) 2019 SED Systems, a division of Calian Ltd.
+ *
+ * Based on Linux 4.19 drivers/watchdog/imx2_wdt.c which is:
+ *  Copyright (C) 2010 Wolfram Sang, Pengutronix e.K. 
+ *  Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct imx_wdt_priv {
+   struct watchdog_regs *regs;
+   bool ext_reset;
+};
+
+static int imx_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+   u16 timeout_reg = (timeout / 500) - 1;
+   u16 wcr = WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_SRS |
+ WCR_WDA | SET_WCR_WT(timeout_reg);
+
+   if (priv->ext_reset)
+   wcr |= WCR_WDT;
+
+   debug("%s timeout %llu, wcr %04hX\n", __func__, timeout, wcr);
+
+   writew(wcr, >regs->wcr);
+
+   return 0;
+}
+
+static int imx_wdt_reset(struct udevice *dev)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   writew(0x, >regs->wsr);
+   writew(0x, >regs->wsr);
+   return 0;
+}
+
+static int imx_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+   u16 wcr = WCR_WDE;
+
+   if (priv->ext_reset)
+   wcr |= WCR_SRS; /* do not assert internal reset */
+   else
+   wcr |= WCR_WDA; /* do not assert external reset */
+
+   debug("%s 

Re: [U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache

[Ilias Apalodimas]

Heinrich,

[...]
> > Unfortunately, this is not practical right now because there is
> > already some sort of assumption (and consensus) that we would re-use
> > "Standalone MM services", which is already there in EDK2, as
> > secure storage for UEFI variables.
> > In the case, all the cache would be bypassed.
> > In my old prototype, I utilized the cache but dropped that feature
> > for several reasons.
> > >>>
> > >>>What has EDK2 code to do with it?
> > >>
> > >>Did you follow my comment below?
> > Unfortunately, this is not practical right now because there is
> > already some sort of assumption (and consensus) that we would re-use
> > "Standalone MM services", which is already there in EDK2, as
> > secure storage for UEFI variables.
> > >We are already working towards having StandAloneMM as an early OP-TEE TA.
> > >This will provide us with a secure variable storage for armv7/v8.
> > 
> > What would this OP-TEE binary do? - This seems to be a source of
> > misunderstanding when reviewing this patch.
> 
> I and Ilias will give you more details offline, here's a short(?)
> answer:
> 
> Standalone MM services here means a SPD entity which provides
> [Get|Set]Variable APIs to non-secure side firmware, that is
> currently EDK2. So the source code of Standalone MM services
> is included in EDK2 repository as a matter of fact.
> 
> Here is one drawback: It won't allow for other entities running
> concurrently on secure side. One example of useful secure feature
> is (software-based) TPM. So Linaro is working on modifying/transforming 
> Standalone MM to one OP-TEE application, which Ilias mentioned above.
> 
Exactly. The current StMM implementation exists for Armv8 *only* in SPM (Secure
Partition Manager). The idea is to make it an OP-TEE application, so we can run
it on on Armv7s as well. As Akashi-san mentions SPD (Secure Payload Dispatcher)
and SPM are mutually exclusive so having everything as OP-TEE trusted
applications gives us a number of advantages at the moment.

> > My guess is that OP-TEE is used to read non-volatile variables only once
> > when starting U-Boot and to write non-volatile variables whenever they
> > are changed.
> 
> So OP-TEE version of StMM is still on-going project and I assume
> that this OP-TEE app will support the same set of functionality/APIs
> as StMM does.
Yes that's the goal 

> 
> > All further reading of non-volatile variables and all access to volatile
> > variables will be handled by the U-Boot internal variable cache.
> > 
> > For volatile variables I would assume OP-TEE to never see them. This
> > requires that the U-Boot variable cachek supports reading from and
> > writing to the cache at runtime.
> 
> No. As far as I correctly understand, StMM handles volatile
> variables as well as non-volatile variables.
> EDK2 on non-secure side will redirect user's request directly
> to secure side even without *caching* variable's values.
> 
Similar understanding here. The question is, will we have to think of something
for non-arm architectures?

> > StandaloneMmPkg seems to be the hardware independent part of the
> > solution. Where will the hardware driver reside in your OP-TEE solution?
It depends on where your hardware is. If you have a NOR flash directly connected
to the secure world the answer is yes. 
For starters we are going to use RPMB + U-Boot supplicant.

> > 
> > Is the EDK2 hardware store for variables of the MACCHIATObin here:
> > edk2-platforms/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c?
No idea, i can ask around.

> > 
> > Which hardware platform will you use for testing the U-Boot development
> > of you OP-TEE driver?
> 
> Ilias will be able to answer those questions.
- stm32mp1 ST board based on armv7 [1]
- Socionext DeveloperBox for armv8 [2]. This has a running EDKII implementation
of StMM in SPM. The underlying firmware should be irrelevant though since the 
whole functionality is contained within an OP-TEE TA (trusted application). If i
remember correctly that will need an extra driver in OP-TEE (if we port U-Boot
on that)
- TI AM6 board [3]. I don't have the board in my hands yet, so no details on it


[1] https://www.st.com/en/evaluation-tools/stm32mp157c-dk2.html
[2] https://www.96boards.org/product/developerbox/
[3] http://www.ti.com/tool/PROCESSOR-SDK-AM65X 


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

Re: [U-Boot] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Mario Six]

Hi Wolfgang,

On Tue, Jun 18, 2019 at 3:46 PM Wolfgang Denk  wrote:
>
> Hello everybody,
>
> I wrote:
>
> > as discussed before, we want to switch from the old git server to
> > more powerful soft- and hardware.  We will move the U-Boot master
> > repository and all custodian repositories to gitlab.
> ...
> > The switch will take place as follows:
> >
> > 1. We will create user accounts for all custodians at gitlab.denx.de
> >You will receive an e-mail notification with your login
> >credentials. We will start with this this afternoon (CEST),
> >so if you have not received such an e-mail by tomorrow morning,
> >please let us know.
> >
> > 2. We will block your SSH keys on the old git server, thus
> >effectively turning the custodian repositories into read-only
> >mode.  Custodians will not be able to push any new stuff to the
> >old repositories any more.
> >
> >This phase will start when all custodian repositories have been
> >created, but in no case before  12:00 p. m. (noon) CEST.  the
> >next steps will follow as quickly as possible, ideally only a few
> >minutes later.
> >
> > 3. The old repository will be cloned to the new gitlab server.  This
> >should not take long.  We don't expect any long interruption.
> >You wanted to have another cup of coffee anyway :-)
> >
> > 4. The custodian can resume work using the gitlab server, as soon as
> >he can "see" his repository there.  Tom should already be
> >prepared to pull from the gitlab repos.
>
> All these steps have been completed by now.  All custodians should
> be able to access the new repositories now, and use all teh gitlab
> features that are enabled for this project (including CI runners).
>
> The U-Boot web pages (especially the source code links and the
> custodian page) have been updated to reference the new gitlab
> repositories.
>
> By now, the gitlab repos represent the official and active mainline
> / custodian repositories.
>
I have not received an e-mail about the MPC83xx repository yet, so I think
something did not quite work as expected. Could you have a look?

>
> > 5. After all custodians have been moved, URL rewrite rules will be
> >activated, and the DNS will be changed, so that the old URLs
> >will still be working, though only for read-only access.
> >
> >Note: this last step is the most error-prone one.  It is likely
> >that the rewrite roles are incomplete at the beginning, and/or
> >incorrect for a few special cases.  Please be patient and report
> >such errors with enough detail to reproduce, then we will fix
> >them.
>
> This is what we will be working on now.
>
> Thanks for your patience!
>
> Best regards,
>
> Wolfgang Denk
>
Best regards,
Mario
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/6] clk: sifive: Sync-up DT bindings header with upstream Linux

[Anup Patel]

The location and license header of DT bindings header for SiFive
clock driver has changed in upstream Linux hence this patch.

Signed-off-by: Anup Patel 
---
 drivers/clk/sifive/fu540-prci.c   |  2 +-
 include/dt-bindings/clk/sifive-fu540-prci.h   | 29 ---
 include/dt-bindings/clock/sifive-fu540-prci.h | 18 
 3 files changed, 19 insertions(+), 30 deletions(-)
 delete mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
 create mode 100644 include/dt-bindings/clock/sifive-fu540-prci.h

diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index cdbf35e871..ceb318e062 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -38,7 +38,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
diff --git a/include/dt-bindings/clk/sifive-fu540-prci.h 
b/include/dt-bindings/clk/sifive-fu540-prci.h
deleted file mode 100644
index 531523ea62..00
--- a/include/dt-bindings/clk/sifive-fu540-prci.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2019 Western Digital Corporation or its affiliates.
- *
- * Copyright (C) 2018 SiFive, Inc.
- * Wesley Terpstra
- * Paul Walmsley
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef __LINUX_CLK_SIFIVE_FU540_PRCI_H
-#define __LINUX_CLK_SIFIVE_FU540_PRCI_H
-
-/* Clock indexes for use by Device Tree data */
-
-#define PRCI_CLK_COREPLL   0
-#define PRCI_CLK_DDRPLL1
-#define PRCI_CLK_GEMGXLPLL 2
-#define PRCI_CLK_TLCLK 3
-
-#endif
diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h 
b/include/dt-bindings/clock/sifive-fu540-prci.h
new file mode 100644
index 00..6a0b70a37d
--- /dev/null
+++ b/include/dt-bindings/clock/sifive-fu540-prci.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018-2019 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_SIFIVE_FU540_PRCI_H
+#define __DT_BINDINGS_CLOCK_SIFIVE_FU540_PRCI_H
+
+/* Clock indexes for use by Device Tree data and the PRCI driver */
+
+#define PRCI_CLK_COREPLL  0
+#define PRCI_CLK_DDRPLL   1
+#define PRCI_CLK_GEMGXLPLL2
+#define PRCI_CLK_TLCLK3
+
+#endif
-- 
2.17.1

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

[U-Boot] [PATCH v2 6/6] net: macb: Add compatible string for MACB on SiFive Unleashed

[Anup Patel]

We have a separate compatible string for MACB ethernet on SiFive
Unleashed so this patch adds the SiFive MACB compatible string to
the MACB ethernet driver.

Signed-off-by: Anup Patel 
---
 drivers/net/macb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c5560a7111..383c37d8e6 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -1225,6 +1225,7 @@ static const struct udevice_id macb_eth_ids[] = {
{ .compatible = "atmel,sama5d3-gem" },
{ .compatible = "atmel,sama5d4-gem" },
{ .compatible = "cdns,zynq-gem" },
+   { .compatible = "sifive,fu540-macb" },
{ }
 };
 
-- 
2.17.1

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

[U-Boot] [PATCH v2 4/6] clk: sifive: Sync-up main driver with upstream Linux

[Anup Patel]

The DT bindings of SiFive clock driver in upstream Linux has
changes. As-per latest DT bindings, the clock driver takes two
parent clocks and compatible string has also changed.

This patch sync-up SiFive clock driver implementation as-per
upstream Linux so that we now use latest DT bindings.

Signed-off-by: Anup Patel 
---
 drivers/clk/sifive/fu540-prci.c | 96 -
 1 file changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index ceb318e062..ce0769f2d1 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -158,30 +158,32 @@
  * PRCI per-device instance data
  */
 struct __prci_data {
-   void *base;
-   struct clk parent;
+   void *va;
+   struct clk parent_hfclk;
+   struct clk parent_rtcclk;
 };
 
 /**
  * struct __prci_wrpll_data - WRPLL configuration and integration data
  * @c: WRPLL current configuration record
- * @bypass: fn ptr to code to bypass the WRPLL (if applicable; else NULL)
- * @no_bypass: fn ptr to code to not bypass the WRPLL (if applicable; else 
NULL)
+ * @enable_bypass: fn ptr to code to bypass the WRPLL (if applicable; else 
NULL)
+ * @disable_bypass: fn ptr to code to not bypass the WRPLL (or NULL)
  * @cfg0_offs: WRPLL CFG0 register offset (in bytes) from the PRCI base address
  *
- * @bypass and @no_bypass are used for WRPLL instances that contain a separate
- * external glitchless clock mux downstream from the PLL.  The WRPLL internal
- * bypass mux is not glitchless.
+ * @enable_bypass and @disable_bypass are used for WRPLL instances
+ * that contain a separate external glitchless clock mux downstream
+ * from the PLL.  The WRPLL internal bypass mux is not glitchless.
  */
 struct __prci_wrpll_data {
struct wrpll_cfg c;
-   void (*bypass)(struct __prci_data *pd);
-   void (*no_bypass)(struct __prci_data *pd);
+   void (*enable_bypass)(struct __prci_data *pd);
+   void (*disable_bypass)(struct __prci_data *pd);
u8 cfg0_offs;
 };
 
 struct __prci_clock;
 
+/* struct __prci_clock_ops - clock operations */
 struct __prci_clock_ops {
int (*set_rate)(struct __prci_clock *pc,
unsigned long rate,
@@ -197,8 +199,7 @@ struct __prci_clock_ops {
  * struct __prci_clock - describes a clock device managed by PRCI
  * @name: user-readable clock name string - should match the manual
  * @parent_name: parent name for this clock
- * @ops: struct clk_ops for the Linux clock framework to use for control
- * @hw: Linux-private clock data
+ * @ops: struct __prci_clock_ops for control
  * @pwd: WRPLL-specific data, associated with this clock (if not NULL)
  * @pd: PRCI-specific data associated with this clock (if not NULL)
  *
@@ -232,12 +233,12 @@ struct __prci_clock {
  */
 static u32 __prci_readl(struct __prci_data *pd, u32 offs)
 {
-   return readl(pd->base + offs);
+   return readl(pd->va + offs);
 }
 
 static void __prci_writel(u32 v, u32 offs, struct __prci_data *pd)
 {
-   return writel(v, pd->base + offs);
+   writel(v, pd->va + offs);
 }
 
 /* WRPLL-related private functions */
@@ -279,10 +280,8 @@ static void __prci_wrpll_unpack(struct wrpll_cfg *c, u32 r)
c->flags &= (WRPLL_FLAGS_INT_FEEDBACK_MASK |
 WRPLL_FLAGS_EXT_FEEDBACK_MASK);
 
-   if (r & PRCI_COREPLLCFG0_FSE_MASK)
-   c->flags |= WRPLL_FLAGS_INT_FEEDBACK_MASK;
-   else
-   c->flags |= WRPLL_FLAGS_EXT_FEEDBACK_MASK;
+   /* external feedback mode not supported */
+   c->flags |= WRPLL_FLAGS_INT_FEEDBACK_MASK;
 }
 
 /**
@@ -300,7 +299,7 @@ static void __prci_wrpll_unpack(struct wrpll_cfg *c, u32 r)
  * Returns: a value suitable for writing into a PRCI PLL configuration
  *  register
  */
-static u32 __prci_wrpll_pack(struct wrpll_cfg *c)
+static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
 {
u32 r = 0;
 
@@ -308,8 +307,9 @@ static u32 __prci_wrpll_pack(struct wrpll_cfg *c)
r |= c->divf << PRCI_COREPLLCFG0_DIVF_SHIFT;
r |= c->divq << PRCI_COREPLLCFG0_DIVQ_SHIFT;
r |= c->range << PRCI_COREPLLCFG0_RANGE_SHIFT;
-   if (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK)
-   r |= PRCI_COREPLLCFG0_FSE_MASK;
+
+   /* external feedback mode not supported */
+   r |= PRCI_COREPLLCFG0_FSE_MASK;
 
return r;
 }
@@ -352,7 +352,7 @@ static void __prci_wrpll_write_cfg(struct __prci_data *pd,
 {
__prci_writel(__prci_wrpll_pack(c), pwd->cfg0_offs, pd);
 
-   memcpy(>c, c, sizeof(struct wrpll_cfg));
+   memcpy(>c, c, sizeof(*c));
 }
 
 /* Core clock mux control */
@@ -431,17 +431,17 @@ static int sifive_fu540_prci_wrpll_set_rate(struct 
__prci_clock *pc,
 
r = wrpll_configure_for_rate(>c, rate, parent_rate);
if (r)
-   return -ERANGE;
+   return r;
 
-   if (pwd->bypass)
-   pwd->bypass(pd);
+   if 

[U-Boot] [PATCH v2 5/6] clk: sifive: Drop GEMGXL clock driver

[Anup Patel]

The GEMGXL clock driver is now directly part of Cadence MACB
ethernet driver in upstream Linux kernel. There is no separate
GEMGXL clock driver in upstream Linux kernel hence we drop
GEMGXL clock driver from U-Boot as well.

Signed-off-by: Anup Patel 
---
 board/sifive/fu540/Kconfig   |  1 -
 drivers/clk/sifive/Kconfig   |  7 
 drivers/clk/sifive/Makefile  |  2 --
 drivers/clk/sifive/gemgxl-mgmt.c | 60 
 4 files changed, 70 deletions(-)
 delete mode 100644 drivers/clk/sifive/gemgxl-mgmt.c

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 8eb5e304ab..f46437901d 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -28,7 +28,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply CMD_PING
imply CLK_SIFIVE
imply CLK_SIFIVE_FU540_PRCI
-   imply CLK_SIFIVE_GEMGXL_MGMT
imply DOS_PARTITION
imply EFI_PARTITION
imply IP_DYN
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index d90be1943f..c4d0a1f9b1 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -14,10 +14,3 @@ config CLK_SIFIVE_FU540_PRCI
  Supports the Power Reset Clock interface (PRCI) IP block found in
  FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
  enable this driver.
-
-config CLK_SIFIVE_GEMGXL_MGMT
-   bool "GEMGXL management for SiFive FU540 SoCs"
-   depends on CLK_SIFIVE
-   help
- Supports the GEMGXL management IP block found in FU540 SoCs to
- control GEM TX clock operation mode for 10/100/1000 Mbps.
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 0813360ca7..b224279afb 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,5 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
-
-obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT)   += gemgxl-mgmt.o
diff --git a/drivers/clk/sifive/gemgxl-mgmt.c b/drivers/clk/sifive/gemgxl-mgmt.c
deleted file mode 100644
index eb37416b5e..00
--- a/drivers/clk/sifive/gemgxl-mgmt.c
+++ /dev/null
@@ -1,60 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2019, Bin Meng 
- */
-
-#include 
-#include 
-#include 
-#include 
-
-struct gemgxl_mgmt_regs {
-   __u32 tx_clk_sel;
-};
-
-struct gemgxl_mgmt_platdata {
-   struct gemgxl_mgmt_regs *regs;
-};
-
-static int gemgxl_mgmt_ofdata_to_platdata(struct udevice *dev)
-{
-   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(dev);
-
-   plat->regs = (struct gemgxl_mgmt_regs *)dev_read_addr(dev);
-
-   return 0;
-}
-
-static ulong gemgxl_mgmt_set_rate(struct clk *clk, ulong rate)
-{
-   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(clk->dev);
-
-   /*
-* GEMGXL TX clock operation mode:
-*
-* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
-* and output clock on GMII output signal GTX_CLK
-* 1 = MII mode. Use MII input signal TX_CLK in TX logic
-*/
-   writel(rate != 12500, >regs->tx_clk_sel);
-
-   return 0;
-}
-
-const struct clk_ops gemgxl_mgmt_ops = {
-   .set_rate = gemgxl_mgmt_set_rate,
-};
-
-static const struct udevice_id gemgxl_mgmt_match[] = {
-   { .compatible = "sifive,cadencegemgxlmgmt0", },
-   { /* sentinel */ }
-};
-
-U_BOOT_DRIVER(sifive_gemgxl_mgmt) = {
-   .name = "sifive-gemgxl-mgmt",
-   .id = UCLASS_CLK,
-   .of_match = gemgxl_mgmt_match,
-   .ofdata_to_platdata = gemgxl_mgmt_ofdata_to_platdata,
-   .platdata_auto_alloc_size = sizeof(struct gemgxl_mgmt_platdata),
-   .ops = _mgmt_ops,
-};
-- 
2.17.1

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

[U-Boot] [PATCH v2 2/6] clk: sifive: Sync-up WRPLL library with upstream Linux

[Anup Patel]

Now that SiFive clock driver is merged in upstream Linux, we
sync-up WRPLL library used by SiFive clock driver with upstream
Linux sources.

Signed-off-by: Anup Patel 
---
 drivers/clk/analogbits/wrpll-cln28hpc.c   | 165 --
 drivers/clk/sifive/fu540-prci.c   |  26 +--
 include/linux/clk/analogbits-wrpll-cln28hpc.h |  70 +++-
 3 files changed, 107 insertions(+), 154 deletions(-)

diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c 
b/drivers/clk/analogbits/wrpll-cln28hpc.c
index 68eb1148b9..776ead319a 100644
--- a/drivers/clk/analogbits/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -1,20 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) 2019 Western Digital Corporation or its affiliates.
- *
- * Copyright (C) 2018 SiFive, Inc.
+ * Copyright (C) 2018-2019 SiFive, Inc.
  * Wesley Terpstra
  * Paul Walmsley
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
  * This library supports configuration parsing and reprogramming of
  * the CLN28HPC variant of the Analog Bits Wide Range PLL.  The
  * intention is for this library to be reusable for any device that
@@ -29,6 +18,7 @@
  * References:
  * - Analog Bits "Wide Range PLL Datasheet", version 2015.10.01
  * - SiFive FU540-C000 Manual v1p0, Chapter 7 "Clocking and Reset"
+ *   https://static.dev.sifive.com/FU540-C000-v1.0.pdf
  */
 
 #include 
@@ -84,40 +74,38 @@
  * range selection.
  *
  * Return: The RANGE value to be presented to the PLL configuration inputs,
- * or -1 upon error.
+ * or a negative return code upon error.
  */
 static int __wrpll_calc_filter_range(unsigned long post_divr_freq)
 {
-   u8 range;
-
if (post_divr_freq < MIN_POST_DIVR_FREQ ||
post_divr_freq > MAX_POST_DIVR_FREQ) {
WARN(1, "%s: post-divider reference freq out of range: %lu",
 __func__, post_divr_freq);
-   return -1;
+   return -ERANGE;
}
 
-   if (post_divr_freq < 1100)
-   range = 1;
-   else if (post_divr_freq < 1800)
-   range = 2;
-   else if (post_divr_freq < 3000)
-   range = 3;
-   else if (post_divr_freq < 5000)
-   range = 4;
-   else if (post_divr_freq < 8000)
-   range = 5;
-   else if (post_divr_freq < 13000)
-   range = 6;
-   else
-   range = 7;
-
-   return range;
+   switch (post_divr_freq) {
+   case 0 ... 1099:
+   return 1;
+   case 1100 ... 1799:
+   return 2;
+   case 1800 ... 2999:
+   return 3;
+   case 3000 ... 4999:
+   return 4;
+   case 5000 ... 7999:
+   return 5;
+   case 8000 ... 12999:
+   return 6;
+   }
+
+   return 7;
 }
 
 /**
  * __wrpll_calc_fbdiv() - return feedback fixed divide value
- * @c: ptr to a struct analogbits_wrpll_cfg record to read from
+ * @c: ptr to a struct wrpll_cfg record to read from
  *
  * The internal feedback path includes a fixed by-two divider; the
  * external feedback path does not.  Return the appropriate divider
@@ -132,7 +120,7 @@ static int __wrpll_calc_filter_range(unsigned long 
post_divr_freq)
  * Return: 2 if internal feedback is enabled or 1 if external feedback
  * is enabled.
  */
-static u8 __wrpll_calc_fbdiv(struct analogbits_wrpll_cfg *c)
+static u8 __wrpll_calc_fbdiv(const struct wrpll_cfg *c)
 {
return (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK) ? 2 : 1;
 }
@@ -172,7 +160,7 @@ static u8 __wrpll_calc_divq(u32 target_rate, u64 *vco_rate)
*vco_rate = MIN_VCO_FREQ;
} else {
divq = ilog2(s);
-   *vco_rate = target_rate << divq;
+   *vco_rate = (u64)target_rate << divq;
}
 
 wcd_out:
@@ -181,7 +169,7 @@ wcd_out:
 
 /**
  * __wrpll_update_parent_rate() - update PLL data when parent rate changes
- * @c: ptr to a struct analogbits_wrpll_cfg record to write PLL data to
+ * @c: ptr to a struct wrpll_cfg record to write PLL data to
  * @parent_rate: PLL input refclk rate (pre-R-divider)
  *
  * Pre-compute some data used by the PLL configuration algorithm when
@@ -189,46 +177,40 @@ wcd_out:
  * computation when the parent rate remains constant - expected to be
  * the common case.
  *
- * Returns: 0 upon success or -1 if the reference clock rate is out of range.
+ * Returns: 0 upon success or -ERANGE if the reference clock rate is
+ * out of range.
  */
-static int 

[U-Boot] [PATCH v2 1/6] clk: sifive: Factor-out PLL library as separate module

[Anup Patel]

To match SiFive clock driver with latest Linux, we factor-out PLL
library as separate module under drivers/clk/analogbits.

Signed-off-by: Anup Patel 
---
 drivers/clk/Kconfig   | 1 +
 drivers/clk/Makefile  | 1 +
 drivers/clk/analogbits/Kconfig| 4 
 drivers/clk/analogbits/Makefile   | 3 +++
 drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c   | 3 +--
 drivers/clk/sifive/Kconfig| 3 ---
 drivers/clk/sifive/Makefile   | 2 --
 drivers/clk/sifive/fu540-prci.c   | 3 +--
 .../sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h  | 0
 9 files changed, 11 insertions(+), 9 deletions(-)
 create mode 100644 drivers/clk/analogbits/Kconfig
 create mode 100644 drivers/clk/analogbits/Makefile
 rename drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c (99%)
 rename {drivers/clk/sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h 
(100%)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 96969b9e30..7b81eacf50 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -98,6 +98,7 @@ config CLK_STM32MP1
  Enable the STM32 clock (RCC) driver. Enable support for
  manipulating STM32MP1's on-SoC clocks.
 
+source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/imx/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 719b9b8e02..f0ced49e5a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
 
+obj-y += analogbits/
 obj-y += imx/
 obj-y += tegra/
 obj-$(CONFIG_ARCH_ASPEED) += aspeed/
diff --git a/drivers/clk/analogbits/Kconfig b/drivers/clk/analogbits/Kconfig
new file mode 100644
index 00..1d25e6f124
--- /dev/null
+++ b/drivers/clk/analogbits/Kconfig
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config CLK_ANALOGBITS_WRPLL_CLN28HPC
+   bool
diff --git a/drivers/clk/analogbits/Makefile b/drivers/clk/analogbits/Makefile
new file mode 100644
index 00..ec1bb4092b
--- /dev/null
+++ b/drivers/clk/analogbits/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o
diff --git a/drivers/clk/sifive/wrpll-cln28hpc.c 
b/drivers/clk/analogbits/wrpll-cln28hpc.c
similarity index 99%
rename from drivers/clk/sifive/wrpll-cln28hpc.c
rename to drivers/clk/analogbits/wrpll-cln28hpc.c
index d377849693..68eb1148b9 100644
--- a/drivers/clk/sifive/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -35,8 +35,7 @@
 #include 
 #include 
 #include 
-
-#include "analogbits-wrpll-cln28hpc.h"
+#include 
 
 /* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */
 #define MIN_INPUT_FREQ 700
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index 644881b948..d90be1943f 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -1,8 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-config CLK_ANALOGBITS_WRPLL_CLN28HPC
-   bool
-
 config CLK_SIFIVE
bool "SiFive SoC driver support"
depends on CLK
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index f8263e79b7..0813360ca7 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,7 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 
-obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o
-
 obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
 
 obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT)   += gemgxl-mgmt.o
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index 2d47ebc6b1..56084db2e6 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -37,10 +37,9 @@
 #include 
 
 #include 
+#include 
 #include 
 
-#include "analogbits-wrpll-cln28hpc.h"
-
 /*
  * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
  * hfclk and rtcclk
diff --git a/drivers/clk/sifive/analogbits-wrpll-cln28hpc.h 
b/include/linux/clk/analogbits-wrpll-cln28hpc.h
similarity index 100%
rename from drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
rename to include/linux/clk/analogbits-wrpll-cln28hpc.h
-- 
2.17.1

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

[U-Boot] [PATCH v2 0/6] Update SiFive Unleashed Drivers

[Anup Patel]

This series update SiFive Unleashed clock and ethernet drivers so that:
1. It is in sync with upstream Linux driver
2. It uses latest DT bindings as-per upstream Linux driver

With this series, we can now use latest DT bindings with U-Boot. I have
tested SiFive Serial driver and Cadence MACB ethernet driver with this
changes and both work fine.

The legacy FSBL will still pass DTB to U-Boot with older DT bindings
which will break the updated SiFive Unleashed clock driver. To tackle
this, we have embedded DTB in OpenSBI FW_PAYLOAD firmware for SiFive
Unleashed so that OpenSBI will override and pass updated DTB to U-Boot.

In fact, the updated DTB passed by OpenSBI can be used by latest Linux
(i.e. V5.2-rc1 or higher) as well.

The OpenSBI changes to embed SiFive Unleashed DTB can be found in
sifive_unleashed_dtb_fix_v2 branch of:
https://github.com/avpatel/opensbi.git

This series can be found in riscv_unleashed_clk_sync_v2 branch of:
https://github.com/avpatel/u-boot.git

Changes since v1:
- Dropped GEMGXL clock driver
- Added new compatible string for SiFive MACB ethernet

Anup Patel (6):
  clk: sifive: Factor-out PLL library as separate module
  clk: sifive: Sync-up WRPLL library with upstream Linux
  clk: sifive: Sync-up DT bindings header with upstream Linux
  clk: sifive: Sync-up main driver with upstream Linux
  clk: sifive: Drop GEMGXL clock driver
  net: macb: Add compatible string for MACB on SiFive Unleashed

 board/sifive/fu540/Kconfig|   1 -
 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/analogbits/Kconfig|   4 +
 drivers/clk/analogbits/Makefile   |   3 +
 .../{sifive => analogbits}/wrpll-cln28hpc.c   | 168 --
 drivers/clk/sifive/Kconfig|  10 --
 drivers/clk/sifive/Makefile   |   4 -
 drivers/clk/sifive/fu540-prci.c   | 123 +++--
 drivers/clk/sifive/gemgxl-mgmt.c  |  60 ---
 drivers/net/macb.c|   1 +
 include/dt-bindings/clk/sifive-fu540-prci.h   |  29 ---
 include/dt-bindings/clock/sifive-fu540-prci.h |  18 ++
 .../linux/clk}/analogbits-wrpll-cln28hpc.h|  70 +++-
 14 files changed, 196 insertions(+), 297 deletions(-)
 create mode 100644 drivers/clk/analogbits/Kconfig
 create mode 100644 drivers/clk/analogbits/Makefile
 rename drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c (69%)
 delete mode 100644 drivers/clk/sifive/gemgxl-mgmt.c
 delete mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
 create mode 100644 include/dt-bindings/clock/sifive-fu540-prci.h
 rename {drivers/clk/sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h 
(52%)

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

[U-Boot] [PATCH v2] MAINTAINERS: Update git repo links

[Bin Meng]

Update all git repo links with the new gitlab ones.

Signed-off-by: Bin Meng 
Acked-by: Wolfgang Denk 

---

Changes in v2:
- add .git suffix to the repo links

 MAINTAINERS | 106 ++--
 1 file changed, 53 insertions(+), 53 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e26eda..8600b91 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -55,7 +55,7 @@ M:Alexey Brodkin 
 M: Eugeniy Paltsev 
 S: Maintained
 L: uboot-snps-...@synopsys.com
-T: git git://git.denx.de/u-boot-arc.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-arc.git
 F: arch/arc/
 F: board/synopsys/
 
@@ -84,7 +84,7 @@ F:drivers/mmc/snps_dw_mmc.c
 ARM
 M: Albert Aribaud 
 S: Maintained
-T: git git://git.denx.de/u-boot-arm.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-arm.git
 F: arch/arm/
 F: cmd/arm/
 
@@ -92,14 +92,14 @@ ARM ALTERA SOCFPGA
 M: Marek Vasut 
 M: Simon Goldschmidt 
 S: Maintainted
-T: git git://git.denx.de/u-boot-socfpga.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-socfpga.git
 F: arch/arm/mach-socfpga/
 
 ARM AMLOGIC SOC SUPPORT
 M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
-T: git git://git.denx.de/u-boot-amlogic.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git
 F: arch/arm/mach-meson/
 F: arch/arm/include/asm/arch-meson/
 F: drivers/clk/meson/
@@ -153,7 +153,7 @@ M:  Stefano Babic 
 M: Fabio Estevam 
 R: NXP i.MX U-Boot Team 
 S: Maintained
-T: git git://git.denx.de/u-boot-imx.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
 F: arch/arm/cpu/arm1136/mx*/
 F: arch/arm/cpu/arm926ejs/mx*/
 F: arch/arm/cpu/armv7/vf610/
@@ -174,7 +174,7 @@ F:  arch/arm/include/asm/arch-hi6220/
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
 S: Maintained
-T: git git://git.denx.de/u-boot-marvell.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-marvell.git
 F: arch/arm/mach-kirkwood/
 F: arch/arm/mach-mvebu/
 F: drivers/ata/ahci_mvebu.c
@@ -188,7 +188,7 @@ F:  drivers/watchdog/orion_wdt.c
 ARM MARVELL PXA
 M: Marek Vasut 
 S: Maintained
-T: git git://git.denx.de/u-boot-pxa.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-pxa.git
 F: arch/arm/cpu/pxa/
 F: arch/arm/include/asm/arch-pxa/
 
@@ -217,7 +217,7 @@ N:  mediatek
 ARM MICROCHIP/ATMEL AT91
 M: Eugen Hristev 
 S: Maintained
-T: git git://git.denx.de/u-boot-atmel.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git
 F: arch/arm/mach-at91/
 F: board/atmel/
 
@@ -234,7 +234,7 @@ ARM RENESAS RMOBILE/R-CAR
 M: Nobuhiro Iwamatsu 
 M: Marek Vasut 
 S: Maintained
-T: git git://git.denx.de/u-boot-sh.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-sh.git
 F: arch/arm/mach-rmobile/
 
 ARM ROCKCHIP
@@ -242,7 +242,7 @@ M:  Simon Glass 
 M: Philipp Tomsich 
 M: Kever Yang 
 S: Maintained
-T: git git://git.denx.de/u-boot-rockchip.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git
 F: arch/arm/include/asm/arch-rockchip/
 F: arch/arm/mach-rockchip/
 F: board/rockchip/
@@ -264,7 +264,7 @@ F:  tools/rkspi.c
 ARM SAMSUNG
 M: Minkyu Kang 
 S: Maintained
-T: git git://git.denx.de/u-boot-samsung.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-samsung.git
 F: arch/arm/mach-exynos/
 F: arch/arm/mach-s5pc1xx/
 F: arch/arm/cpu/armv7/s5p-common/
@@ -289,7 +289,7 @@ F:  arch/arm/include/asm/arch-sti*/
 ARM STM SPEAR
 #M:Vipin Kumar 
 S: Orphaned (Since 2016-02)
-T: git git://git.denx.de/u-boot-stm.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git
 F: arch/arm/cpu/arm926ejs/spear/
 F: arch/arm/include/asm/arch-spear/
 
@@ -326,7 +326,7 @@ ARM SUNXI
 M: Jagan Teki 
 M: Maxime Ripard 
 S: Maintained
-T: git git://git.denx.de/u-boot-sunxi.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi.git
 F: arch/arm/cpu/armv7/sunxi/
 F: arch/arm/include/asm/arch-sunxi/
 F: arch/arm/mach-sunxi/
@@ -335,14 +335,14 @@ F:board/sunxi/
 ARM TEGRA
 M: Tom Warren 
 S: Maintained
-T: git git://git.denx.de/u-boot-tegra.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-tegra.git
 F: arch/arm/mach-tegra/
 F: arch/arm/include/asm/arch-tegra*/
 
 ARM TI
 M: Tom Rini 
 S: Maintained
-T: git git://git.denx.de/u-boot-ti.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-ti.git
 F: arch/arm/mach-davinci/
 F: arch/arm/mach-k3/
 F: arch/arm/mach-keystone/
@@ -352,7 +352,7 @@ F:  arch/arm/include/asm/ti-common/
 ARM UNIPHIER
 M: Masahiro Yamada 
 S: Maintained
-T: git 

Re: [U-Boot] [PATCH 0/4] Update SiFive Unleashed Clock Driver

[Troy Benjegerdes]

> On Jun 18, 2019, at 4:18 AM, Anup Patel  wrote:
> 
> This series update SiFive Unleashed clock driver so that:
> 1. It is in sync with upstream Linux driver
> 2. It uses latest DT bindings as-per upstream Linux driver
> 
> With this series, we can now use latest DT bindings with U-Boot. I have
> tested SiFive Serial driver and Cadence MACB ethernet driver with this
> changes and both work fine.
> 
> The legacy FSBL will still pass DTB to U-Boot with older DT bindings
> which will break the updated SiFive Unleashed clock driver. To tackle
> this, we have embedded DTB in OpenSBI FW_PAYLOAD firmware for SiFive
> Unleashed so that OpenSBI will override and pass updated DTB to U-Boot.
> 
> In fact, the updated DTB passed by OpenSBI can be used by latest Linux
> (i.e. V5.2-rc1 or higher) as well.
> 
> The OpenSBI changes to embed SiFive Unleashed DTB can be found in
> sifive_unleashed_dtb_fix_v1 branch of:
> https://github.com/avpatel/opensbi.git
> 
> This series can be found in riscv_unleashed_clk_sync_v1 branch of:
> https://github.com/avpatel/u-boot.git

There are some discrepancies I’m finding in the clocking… If I use the
HiFive_U-Boot as FSBL, it does the following (with some extra debug
code)

U-Boot 2018.09-g8bbdd51-dirty (Jun 18 2019 - 19:46:55 -0700)

DRAM:  2 GiB
MMC:
In:serial
Out:   serial
Err:   serial
Net:   gem_mdc_clk_div: macb_hz: 5
gmac0
Hit any key to stop autoboot:  0

Where as the close-to-u-boot master version does this:

U-Boot 2019.07-rc4-05661-gc998035-dirty (Jun 18 2019 - 19:51:10 -0700)

CPU:   rv64imafdc
Model: sifive,hifive-unleashed-a00
DRAM:  8 GiB
In:serial@1001
Out:   serial@1001
Err:   serial@1001
Net:   gem_mdc_clk_div: macb_hz: 93324

For reference, I’ve checked all my changes into the ‘dev/new-dts’ branch
of github.com/tmagik/freedom-u-sdk, and the ‘make test_s’ target will build
and then copy various files to /var/lib/tftpboot to run the test, and assumes
you have a DHCP and TFTP server running locally.

Another issue with the mainline u-boot is it does not have the OTP driver
that the HiFive_U-Boot version does, so when it selects a random mac
address this causes TFTP to fail in one of my test environments.

FYI, the patch applied is:

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 5a6cba5..d21026d 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -813,6 +813,8 @@ static u32 macb_mdc_clk_div(int id, struct macb_device 
*macb)
unsigned long macb_hz = 
HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
 #endif
 
+   printf("%s: macb_hz: %d\n", __func__, macb_hz);
+
if (macb_hz < 2000)
config = MACB_BF(CLK, MACB_CLK_DIV8);
else if (macb_hz < 4000)
@@ -835,6 +837,7 @@ static u32 gem_mdc_clk_div(int id, struct macb_device *macb)
unsigned long macb_hz = 
HIFIVE_ETHERNET_CLK_FREQ;//get_macb_pclk_rate(id);
 #endif
 
+   printf("%s: macb_hz: %d\n", __func__, macb_hz);
if (macb_hz < 2000)
config = GEM_BF(CLK, GEM_CLK_DIV8);
else if (macb_hz < 4000)

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

Re: [U-Boot] [PATCH] MAINTAINERS: Update git repo links

[Bin Meng]

Hi Masahiro,

On Wed, Jun 19, 2019 at 10:38 AM Masahiro Yamada
 wrote:
>
> On Wed, Jun 19, 2019 at 1:49 AM Wolfgang Denk  wrote:
> >
> > Dear Bin,
> >
> > In message <1560872253-6077-1-git-send-email-bmeng...@gmail.com> you wrote:
> > > Update all git repo links with the new gitlab ones.
> > >
> > > Signed-off-by: Bin Meng 
> > > ---
> > >
> > >  MAINTAINERS | 106 
> > > ++--
> > >  1 file changed, 53 insertions(+), 53 deletions(-)
> >
> > Thanks a lot!
> >
> > Acked-by: Wolfgang Denk 
> >
> > Best regards,
> >
> > Wolfgang Denk
>
>
> This involves two changes
>   [1]  git.denx.de/*  ->  gitlab.denx.de/u-boot/*
>   [2]  git:// -> https://
>
>
> Wolfgang said:
> "  c) git:// access is not available yet; this depends on the
>  URL rewrite rules and DNS changes and will be added later
>  - ASAP, see below.
> "
>
>
> Which is efficient and better to advertise, git:// or https:// ?
> No difference in the clone speed?
>

I am not sure.

>
> BTW, I recommend to add '.git' to URL
> Otherwise, my git shows a warning:
>
> masahiro@pug:~/ref$ git clone https://gitlab.denx.de/u-boot/u-boot  u-boot_
> Cloning into 'u-boot_'...
> warning: redirecting to https://gitlab.denx.de/u-boot/u-boot.git/
>

My git does not complain.
$ git --version
git version 2.7.4

But I can add the .git suffix in v2.

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

Re: [U-Boot] [PATCH] MAINTAINERS: Update git repo links

[Masahiro Yamada]

On Wed, Jun 19, 2019 at 1:49 AM Wolfgang Denk  wrote:
>
> Dear Bin,
>
> In message <1560872253-6077-1-git-send-email-bmeng...@gmail.com> you wrote:
> > Update all git repo links with the new gitlab ones.
> >
> > Signed-off-by: Bin Meng 
> > ---
> >
> >  MAINTAINERS | 106 
> > ++--
> >  1 file changed, 53 insertions(+), 53 deletions(-)
>
> Thanks a lot!
>
> Acked-by: Wolfgang Denk 
>
> Best regards,
>
> Wolfgang Denk


This involves two changes
  [1]  git.denx.de/*  ->  gitlab.denx.de/u-boot/*
  [2]  git:// -> https://


Wolfgang said:
"  c) git:// access is not available yet; this depends on the
 URL rewrite rules and DNS changes and will be added later
 - ASAP, see below.
"


Which is efficient and better to advertise, git:// or https:// ?
No difference in the clone speed?


BTW, I recommend to add '.git' to URL
Otherwise, my git shows a warning:

masahiro@pug:~/ref$ git clone https://gitlab.denx.de/u-boot/u-boot  u-boot_
Cloning into 'u-boot_'...
warning: redirecting to https://gitlab.denx.de/u-boot/u-boot.git/



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

Re: [U-Boot] [PATCH v2 4/4] net: NC-SI setup and handling

[Joel Stanley]

On Tue, 18 Jun 2019 at 01:38, Samuel Mendoza-Jonas  
wrote:
>
> Add the handling of NC-SI ethernet frames, and add a check at the start
> of net_loop() to configure NC-SI before starting other network commands.
> This also adds an "ncsi" command to manually start NC-SI configuration.
>
> Signed-off-by: Samuel Mendoza-Jonas 
> ---
> v2: Update ncsi command help text
>
>  cmd/Kconfig   |  8 
>  cmd/net.c | 18 ++
>  include/net.h |  2 +-
>  net/net.c | 27 ++-
>  4 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 0badcb3fe0..9851b04972 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -1332,6 +1332,14 @@ config CMD_LINK_LOCAL
> help
>   Acquire a network IP address using the link-local protocol
>
> +config CMD_NCSI
> +   bool "ncsi"
> +   depends on PHY_NCSI
> +   help
> + Manually configure the attached NIC via NC-SI.
> + Normally this happens automatically before other network
> + operations.

Do we need to make it even clearer that "this command not required to use NCSI"?

I'm thinking of future me wondering if we should put this in openbmc
builds or not. It would be good to have your advice on this.

Cheers,

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

Re: [U-Boot] [PATCH v2 2/4] phy: Include NC-SI in phy setup

[Joel Stanley]

On Tue, 18 Jun 2019 at 01:37, Samuel Mendoza-Jonas  
wrote:
>
> Add NC-SI to the usual phy handling. This makes two notable changes:
> - Somewhat similar to a fixed phy, phy_connect() will create an NC-SI
> phy if CONFIG_PHY_NCSI is defined.
> - An early return is added to phy_read() and phy_write() to handle a
> case like the NC-SI phy which does not define a bus.
>
> Signed-off-by: Samuel Mendoza-Jonas 

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

Re: [U-Boot] [PATCH v2 1/4] phy: Add support for the NC-SI protocol

[Joel Stanley]

On Tue, 18 Jun 2019 at 01:37, Samuel Mendoza-Jonas  
wrote:
>
> This introduces support for the NC-SI protocol, modelled as a phy driver
> for other ethernet drivers to consume.
>
> NC-SI (Network Controller Sideband Interface) is a protocol to manage a
> sideband connection to a proper network interface, for example a BMC
> (Baseboard Management Controller) sharing the NIC of the host system.
> Probing and configuration occurs by communicating with the "remote" NIC
> via NC-SI control frames (Ethernet header 0x88f8).
>
> This implementation is roughly based on the upstream Linux
> implementation[0], with a reduced feature set and an emphasis on getting
> a link up as fast as possible rather than probing the full possible
> topology of the bus.
> The current phy model relies on the network being "up", sending NC-SI
> command frames via net_send_packet() and receiving them from the
> net_loop() loop (added in a following patch).
>
> The ncsi-pkt.h header[1] is copied from the Linux kernel for consistent
> field definitions.
>
> [0]: https://github.com/torvalds/linux/tree/master/net/ncsi
> [1]: https://github.com/torvalds/linux/blob/master/net/ncsi/ncsi-pkt.h
>
> Signed-off-by: Samuel Mendoza-Jonas 
> ---
> v2:
> - Fix endianess issue when setting MAC address
> - Make checksum offsets easier to read
> - Instantiate per-phy ncsi_priv structures
> - Used update ncsi-pkt.h version to include SPDX header

Thanks, the updates look good.

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

Re: [U-Boot] [PATCH v2 0/4] NC-SI PHY Support

[Joel Stanley]

On Tue, 18 Jun 2019 at 08:35, Cédric Le Goater  wrote:
>
> On 18/06/2019 03:37, Samuel Mendoza-Jonas wrote:
> > This series introduces support for the NC-SI protocol to u-boot,
> > functionality which so far has only been available in vendor trees.
>
> Would it be complex to add a romulus DT and config file ?

I think it's a great idea to follow up with that. I suggested Sam
focus on the network and ftgmac100 parts of NCSI first.

We will need to add support for the NCSI clocking in addition to the
device tree and config.

Cheers,

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

Re: [U-Boot] [PATCH V2 1/3] test: dm: adc: use the real device name

[Peng Fan]

Hi Simon, Tom
> Subject: [PATCH V2 1/3] test: dm: adc: use the real device name
> 
> "adc" is not the real device name, "adc@0" is.
> 
> Signed-off-by: Peng Fan 

Will you pick up this patchset?
https://patchwork.ozlabs.org/patch/1103212/
https://patchwork.ozlabs.org/patch/1103213/
https://patchwork.ozlabs.org/patch/1103214/

Thanks,
Peng.

> ---
> 
> V2:
>  new
> 
>  test/dm/adc.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/test/dm/adc.c b/test/dm/adc.c index 1f82304f41..da7bd4bf1f
> 100644
> --- a/test/dm/adc.c
> +++ b/test/dm/adc.c
> @@ -24,7 +24,7 @@ static int dm_test_adc_bind(struct unit_test_state *uts)
>   struct udevice *dev;
>   unsigned int channel_mask;
> 
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
>   ut_asserteq_str(SANDBOX_ADC_DEVNAME, dev->name);
> 
>   ut_assertok(adc_channel_mask(dev, _mask)); @@ -38,7 +38,7
> @@ static int dm_test_adc_wrong_channel_selection(struct unit_test_state
> *uts)  {
>   struct udevice *dev;
> 
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
>   ut_asserteq(-EINVAL, adc_start_channel(dev,
> SANDBOX_ADC_CHANNELS));
> 
>   return 0;
> @@ -51,7 +51,7 @@ static int dm_test_adc_supply(struct unit_test_state
> *uts)
>   struct udevice *dev;
>   int uV;
> 
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
> 
>   /* Test Vss value - predefined 0 uV */
>   ut_assertok(adc_vss_value(dev, ));
> @@ -94,7 +94,7 @@ static int
> dm_test_adc_single_channel_conversion(struct unit_test_state *uts)
>   unsigned int i, data;
>   struct udevice *dev;
> 
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
>   /* Test each ADC channel's value */
>   for (i = 0; i < SANDBOX_ADC_CHANNELS; i++, tdata++) {
>   ut_assertok(adc_start_channel(dev, tdata->id)); @@ -117,7 +117,7
> @@ static int dm_test_adc_multi_channel_conversion(struct unit_test_state
> *uts)
>  ADC_CHANNEL(2) | ADC_CHANNEL(3);
> 
>   /* Start multi channel conversion */
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
>   ut_assertok(adc_start_channels(dev, channel_mask));
>   ut_assertok(adc_channels_data(dev, channel_mask, channels));
> 
> @@ -136,7 +136,7 @@ static int dm_test_adc_single_channel_shot(struct
> unit_test_state *uts)
> 
>   for (i = 0; i < SANDBOX_ADC_CHANNELS; i++, tdata++) {
>   /* Start single channel conversion */
> - ut_assertok(adc_channel_single_shot("adc", tdata->id, ));
> + ut_assertok(adc_channel_single_shot("adc@0", tdata->id, ));
>   /* Compare the expected and returned conversion data. */
>   ut_asserteq(tdata->data, data);
>   }
> @@ -155,7 +155,7 @@ static int dm_test_adc_multi_channel_shot(struct
> unit_test_state *uts)
>  ADC_CHANNEL(2) | ADC_CHANNEL(3);
> 
>   /* Start single call and multi channel conversion */
> - ut_assertok(adc_channels_single_shot("adc", channel_mask, channels));
> + ut_assertok(adc_channels_single_shot("adc@0", channel_mask,
> +channels));
> 
>   /* Compare the expected and returned conversion data. */
>   for (i = 0; i < SANDBOX_ADC_CHANNELS; i++, tdata++) @@ -183,7
> +183,7 @@ static int dm_test_adc_raw_to_uV(struct unit_test_state *uts)
>   struct udevice *dev;
>   int uV;
> 
> - ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc", ));
> + ut_assertok(uclass_get_device_by_name(UCLASS_ADC, "adc@0",
> ));
>   /* Test each ADC channel's value in microvolts */
>   for (i = 0; i < SANDBOX_ADC_CHANNELS; i++, tdata++) {
>   ut_assertok(adc_start_channel(dev, tdata->id));
> --
> 2.16.4

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

[U-Boot] [PATCH V2 5/5] imx8qxp_mek: switch to use container image

[Peng Fan]

Because FIT could not be used for AHAB secure boot on i.MX8,
so switch to use container image that could let SPL verify
ATF and U-Boot with AHAB.

Note: The AHAB related code has not been added.

Signed-off-by: Peng Fan 
---
 board/freescale/imx8qxp_mek/README  |  4 +---
 board/freescale/imx8qxp_mek/uboot-container.cfg | 13 +
 configs/imx8qxp_mek_defconfig   |  5 ++---
 3 files changed, 16 insertions(+), 6 deletions(-)
 create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg

diff --git a/board/freescale/imx8qxp_mek/README 
b/board/freescale/imx8qxp_mek/README
index f32290e3a2..6dc151b166 100644
--- a/board/freescale/imx8qxp_mek/README
+++ b/board/freescale/imx8qxp_mek/README
@@ -39,11 +39,9 @@ $ cp imx-sc-firmware-0.7/mx8qx-mek-scfw-tcm.bin  .
 
 Build U-Boot
 
-$ export ATF_LOAD_ADDR=0x8000
-$ export BL33_LOAD_ADDR=0x8002
 $ make imx8qxp_mek_defconfig
 $ make flash.bin
-$ dd if=u-boot.itb of=flash.bin bs=512 seek=528
+$ dd if=u-boot.cnt of=flash.bin bs=512 seek=528
 
 Flash the binary into the SD card
 =
diff --git a/board/freescale/imx8qxp_mek/uboot-container.cfg 
b/board/freescale/imx8qxp_mek/uboot-container.cfg
new file mode 100644
index 00..8165811818
--- /dev/null
+++ b/board/freescale/imx8qxp_mek/uboot-container.cfg
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2019 NXP
+ */
+
+#define __ASSEMBLY__
+
+/* This file is to create a container image could be loaded by SPL */
+BOOT_FROM SD 0x400
+SOC_TYPE IMX8QX
+CONTAINER
+IMAGE A35 bl31.bin 0x8000
+IMAGE A35 u-boot.bin   CONFIG_SYS_TEXT_BASE
diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig
index d735d34b8b..5d6c5f968f 100644
--- a/configs/imx8qxp_mek_defconfig
+++ b/configs/imx8qxp_mek_defconfig
@@ -7,15 +7,14 @@ CONFIG_SPL_GPIO_SUPPORT=y
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_SPL_LOAD_IMX_CONTAINER=y
+CONFIG_IMX_CONTAINER_CFG="board/freescale/imx8qxp_mek/uboot-container.cfg"
 CONFIG_TARGET_IMX8QXP_MEK=y
 CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=3
 CONFIG_SPL=y
-CONFIG_FIT=y
-CONFIG_SPL_LOAD_FIT=y
-CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-imx/mkimage_fit_atf.sh"
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/imx8qxp_mek/imximage.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_LOG=y
-- 
2.16.4

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

[U-Boot] [PATCH V2 4/5] imx: add container target

[Peng Fan]

To support SPL loading container file, add a new Makefile target,
and introduce a new Kconfig file to source the cfg file which
will be parsed by mkimage.

Signed-off-by: Peng Fan 
---
 Makefile   |  8 
 arch/arm/mach-imx/Makefile | 14 --
 arch/arm/mach-imx/imx8/Kconfig |  7 +++
 3 files changed, 27 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index c55ffa265f..09b354bea9 100644
--- a/Makefile
+++ b/Makefile
@@ -1333,9 +1333,17 @@ SPL: spl/u-boot-spl.bin FORCE
$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
 
 ifeq ($(CONFIG_ARCH_IMX8M)$(CONFIG_ARCH_IMX8), y)
+ifeq ($(CONFIG_SPL_LOAD_IMX_CONTAINER), y)
+u-boot.cnt: u-boot.bin FORCE
+   $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
+
+flash.bin: spl/u-boot-spl.bin u-boot.cnt FORCE
+   $(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
+else
 flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
 endif
+endif
 
 u-boot-with-spl.imx u-boot-with-nand-spl.imx: SPL u-boot.bin FORCE
$(Q)$(MAKE) $(build)=arch/arm/mach-imx $@
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 898478fc4a..6de81408f8 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -89,6 +89,11 @@ IMX_CONFIG = $(CONFIG_IMX_CONFIG:"%"=%)
$(Q)mkdir -p $(dir $@)
$(call if_changed_dep,cpp_cfg)
 
+IMX_CONTAINER_CFG = $(CONFIG_IMX_CONTAINER_CFG:"%"=%)
+container.cfg: $(IMX_CONTAINER_CFG) FORCE
+   $(Q)mkdir -p $(dir $@)
+   $(call if_changed_dep,cpp_cfg)
+
 ifeq ($(CONFIG_ARCH_IMX8), y)
 CNTR_DEPFILES := $(srctree)/tools/imx_cntr_image.sh
 IMAGE_TYPE := imx8image
@@ -157,10 +162,15 @@ SPL:
 MKIMAGEFLAGS_flash.bin = -n spl/u-boot-spl.cfgout -T $(IMAGE_TYPE) -e 0x10
 flash.bin: MKIMAGEOUTPUT = flash.log
 
-flash.bin: spl/u-boot-spl.bin u-boot.itb FORCE
-ifeq ($(SPL_DEPFILE_EXISTS),0)
+MKIMAGEFLAGS_u-boot.cnt = -n container.cfg -T $(IMAGE_TYPE) -e 0x10
+u-boot.cnt: MKIMAGEOUTPUT = u-boot.cnt.log
+
+ifeq ($(CONFIG_SPL_LOAD_IMX_CONTAINER), y)
+u-boot.cnt: u-boot.bin container.cfg FORCE
$(call if_changed,mkimage)
 endif
+flash.bin: spl/u-boot-spl.bin FORCE
+   $(call if_changed,mkimage)
 endif
 
 else
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index e9496cb611..d17760e333 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -29,6 +29,13 @@ config SPL_LOAD_IMX_CONTAINER
help
  This is to let SPL could load i.MX8 Container image
 
+config IMX_CONTAINER_CFG
+   string "i.MX Container config file"
+   depends on SPL
+   help
+ This is to specific the cfg file for generating container
+ image which will be loaded by SPL.
+
 choice
prompt "i.MX8 board select"
optional
-- 
2.16.4

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

[U-Boot] [PATCH V2 3/5] spl: mmc: support loading i.MX container format file

[Peng Fan]

i.MX8 only support AHAB secure boot with Container format image,
we could not use FIT to support secure boot, so introduce container
support to let SPL could load container images.

Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
Cc: York Sun 
Cc: Marek Vasut 
Cc: Alex Kiernan 
Cc: Simon Glass 
Cc: Philipp Tomsich 
Cc: Kever Yang 
Cc: Heiko Schocher 
Signed-off-by: Peng Fan 
---
 common/spl/spl_mmc.c | 10 ++
 include/spl.h| 12 
 2 files changed, 22 insertions(+)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index bf53a1dadf..6320af055b 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -79,6 +79,16 @@ int mmc_load_image_raw_sector(struct spl_image_info 
*spl_image,
load.bl_len = mmc->read_bl_len;
load.read = h_spl_load_read;
ret = spl_load_simple_fit(spl_image, , sector, header);
+   } else if (IS_ENABLED(CONFIG_SPL_LOAD_IMX_CONTAINER)) {
+   struct spl_load_info load;
+
+   load.dev = mmc;
+   load.priv = NULL;
+   load.filename = NULL;
+   load.bl_len = mmc->read_bl_len;
+   load.read = h_spl_load_read;
+
+   ret = spl_load_imx_container(spl_image, , sector);
} else {
ret = mmc_load_legacy(spl_image, mmc, sector, header);
}
diff --git a/include/spl.h b/include/spl.h
index a9aaef345f..e280685b68 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -125,6 +125,18 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 #define SPL_COPY_PAYLOAD_ONLY  1
 #define SPL_FIT_FOUND  2
 
+/**
+ * spl_load_imx_container() - Loads a imx container image from a device.
+ * @spl_image: Image description to set up
+ * @info:  Structure containing the information required to load data.
+ * @sector:Sector number where container image is located in the device
+ *
+ * Reads the container image @sector in the device. Loads u-boot image to
+ * specified load address.
+ */
+int spl_load_imx_container(struct spl_image_info *spl_image,
+  struct spl_load_info *info, ulong sector);
+
 /* SPL common functions */
 void preloader_console_init(void);
 u32 spl_boot_device(void);
-- 
2.16.4

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

[U-Boot] [PATCH V2 1/5] spl: Add function to get u-boot raw sector

[Peng Fan]

Add a weak function spl_mmc_get_uboot_raw_sector to get u-boot raw
sector. At default it returns CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR.
Users can overwrite it to return customized offset.

This is to support i.MX8 specific image type container image type.

Cc: Tien Fong Chee 
Cc: Peng Fan 
Cc: Simon Goldschmidt 
Cc: York Sun 
Cc: Marek Vasut 
Cc: Alex Kiernan 
Signed-off-by: Peng Fan 
---
 common/spl/spl_mmc.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 324d91c884..bf53a1dadf 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -149,6 +149,13 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 
boot_device)
return 0;
 }
 
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
+unsigned long __weak spl_mmc_get_uboot_raw_sector(struct mmc *mmc)
+{
+   return CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR;
+}
+#endif
+
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION
 static int mmc_load_image_raw_partition(struct spl_image_info *spl_image,
struct mmc *mmc, int partition)
@@ -181,7 +188,7 @@ static int mmc_load_image_raw_partition(struct 
spl_image_info *spl_image,
 
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
return mmc_load_image_raw_sector(spl_image, mmc,
-   info.start + CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+   info.start + spl_mmc_get_uboot_raw_sector(mmc));
 #else
return mmc_load_image_raw_sector(spl_image, mmc, info.start);
 #endif
@@ -366,7 +373,7 @@ int spl_mmc_load_image(struct spl_image_info *spl_image,
 #endif
 #ifdef CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
err = mmc_load_image_raw_sector(spl_image, mmc,
-   CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
+   spl_mmc_get_uboot_raw_sector(mmc));
if (!err)
return err;
 #endif
-- 
2.16.4

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

[U-Boot] [PATCH V2 2/5] imx8: support parsing i.MX8 Container file

[Peng Fan]

Add parsing i.MX8 Container file support, this is to let
SPL could load images in a container file to destination address.

Signed-off-by: Peng Fan 
---
 arch/arm/include/asm/arch-imx8/image.h   |  56 +++
 arch/arm/mach-imx/imx8/Kconfig   |   6 ++
 arch/arm/mach-imx/imx8/Makefile  |   4 ++
 arch/arm/mach-imx/imx8/parse-container.c | 120 +++
 4 files changed, 186 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-imx8/image.h
 create mode 100644 arch/arm/mach-imx/imx8/parse-container.c

diff --git a/arch/arm/include/asm/arch-imx8/image.h 
b/arch/arm/include/asm/arch-imx8/image.h
new file mode 100644
index 00..c1e5700859
--- /dev/null
+++ b/arch/arm/include/asm/arch-imx8/image.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#ifndef __CONTAINER_HEADER_H_
+#define __CONTAINER_HEADER_H_
+
+#include 
+#include 
+
+#define IV_MAX_LEN 32
+#define HASH_MAX_LEN   64
+
+#define CONTAINER_HDR_ALIGNMENT 0x400
+#define CONTAINER_HDR_EMMC_OFFSET 0
+#define CONTAINER_HDR_MMCSD_OFFSET SZ_32K
+#define CONTAINER_HDR_QSPI_OFFSET SZ_4K
+#define CONTAINER_HDR_NAND_OFFSET SZ_128M
+
+struct container_hdr {
+   u8 version;
+   u8 length_lsb;
+   u8 length_msb;
+   u8 tag;
+   u32 flags;
+   u16 sw_version;
+   u8 fuse_version;
+   u8 num_images;
+   u16 sig_blk_offset;
+   u16 reserved;
+} __packed;
+
+struct boot_img_t {
+   u32 offset;
+   u32 size;
+   u64 dst;
+   u64 entry;
+   u32 hab_flags;
+   u32 meta;
+   u8 hash[HASH_MAX_LEN];
+   u8 iv[IV_MAX_LEN];
+} __packed;
+
+struct signature_block_hdr {
+   u8 version;
+   u8 length_lsb;
+   u8 length_msb;
+   u8 tag;
+   u16 srk_table_offset;
+   u16 cert_offset;
+   u16 blob_offset;
+   u16 signature_offset;
+   u32 reserved;
+} __packed;
+#endif
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index bbe323d5ca..e9496cb611 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -23,6 +23,12 @@ config IMX8QXP
 config SYS_SOC
default "imx8"
 
+config SPL_LOAD_IMX_CONTAINER
+   bool "Enable SPL loading U-Boot as a i.MX Container image"
+   depends on SPL
+   help
+ This is to let SPL could load i.MX8 Container image
+
 choice
prompt "i.MX8 board select"
optional
diff --git a/arch/arm/mach-imx/imx8/Makefile b/arch/arm/mach-imx/imx8/Makefile
index 31ad169ccf..19690110a5 100644
--- a/arch/arm/mach-imx/imx8/Makefile
+++ b/arch/arm/mach-imx/imx8/Makefile
@@ -5,3 +5,7 @@
 #
 
 obj-y += cpu.o iomux.o
+
+ifdef CONFIG_SPL_BUILD
+obj-$(CONFIG_SPL_LOAD_IMX_CONTAINER) += parse-container.o
+endif
diff --git a/arch/arm/mach-imx/imx8/parse-container.c 
b/arch/arm/mach-imx/imx8/parse-container.c
new file mode 100644
index 00..32f78bdddf
--- /dev/null
+++ b/arch/arm/mach-imx/imx8/parse-container.c
@@ -0,0 +1,120 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static struct boot_img_t *read_auth_image(struct spl_image_info *spl_image,
+ struct spl_load_info *info,
+ struct container_hdr *container,
+ int image_index,
+ u32 container_sector)
+{
+   struct boot_img_t *images;
+   ulong sector;
+   u32 sectors;
+
+   if (image_index > container->num_images) {
+   debug("Invalid image number\n");
+   return NULL;
+   }
+
+   images = (struct boot_img_t *)((u8 *)container +
+  sizeof(struct container_hdr));
+
+   if (images[image_index].offset % info->bl_len) {
+   printf("%s: image%d offset not aligned to %u\n",
+  __func__, image_index, info->bl_len);
+   return NULL;
+   }
+
+   sectors = roundup(images[image_index].size, info->bl_len) /
+   info->bl_len;
+   sector = images[image_index].offset / info->bl_len +
+   container_sector;
+
+   debug("%s: container: %p sector: %lu sectors: %u\n", __func__,
+ container, sector, sectors);
+   if (info->read(info, sector, sectors,
+  (void *)images[image_index].entry) != sectors) {
+   printf("%s wrong\n", __func__);
+   return NULL;
+   }
+
+   return [image_index];
+}
+
+static int read_auth_container(struct spl_image_info *spl_image,
+  struct spl_load_info *info, ulong sector)
+{
+   struct container_hdr *container = NULL;
+   u16 length;
+   u32 sectors;
+   int i, size;
+
+   size = roundup(CONTAINER_HDR_ALIGNMENT, info->bl_len);
+   sectors = size / 

[U-Boot] [PATCH V2 0/5] add i.MX8 container loading support

[Peng Fan]

The V1 version:
https://patchwork.ozlabs.org/cover/1096334/

This patchset is to support i.MX8 container loading from SPL,
i.MX8 AHAB secure boot not support FIT image, so we need to
use container image.

Currently still use a fixed offset for the 2nd container(u-boot.cnt),
future patches will drop this fixed offset and use dynamaic offset
according to the size of 1st container for spl.
Only MMC is supported now, future patches will also support SPI/NOR/NAND
following similar style as mmc part, if the mmc part is ok.

Based on the comments in https://patchwork.ozlabs.org/patch/1096336/
So I think we have agreed the approach, the only comments that
not addressed from Lukasz is add doc for the container format.
The detailed format could be found in RM
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf
Chapter 5.9.4 High Level Container Format

CI: https://travis-ci.org/MrVan/u-boot/builds/547161366

V2:
 Drop cleanup Makefile since V1, that patch is not correct.
 Rebased on master

Peng Fan (5):
  spl: Add function to get u-boot raw sector
  imx8: support parsing i.MX8 Container file
  spl: mmc: support loading i.MX container format file
  imx: add container target
  imx8qxp_mek: switch to use container image

 Makefile|   8 ++
 arch/arm/include/asm/arch-imx8/image.h  |  56 +++
 arch/arm/mach-imx/Makefile  |  14 ++-
 arch/arm/mach-imx/imx8/Kconfig  |  13 +++
 arch/arm/mach-imx/imx8/Makefile |   4 +
 arch/arm/mach-imx/imx8/parse-container.c| 120 
 board/freescale/imx8qxp_mek/README  |   4 +-
 board/freescale/imx8qxp_mek/uboot-container.cfg |  13 +++
 common/spl/spl_mmc.c|  21 -
 configs/imx8qxp_mek_defconfig   |   5 +-
 include/spl.h   |  12 +++
 11 files changed, 260 insertions(+), 10 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-imx8/image.h
 create mode 100644 arch/arm/mach-imx/imx8/parse-container.c
 create mode 100644 board/freescale/imx8qxp_mek/uboot-container.cfg

-- 
2.16.4

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

Re: [U-Boot] [PATCH v2 3/3] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP

[Breno Matheus Lima]

Hi Sjoerd,

Em seg, 17 de jun de 2019 às 11:26, Sjoerd Simons
 escreveu:
>
> On Tue, 2019-06-04 at 18:56 -0300, Fabio Estevam wrote:
> > On Tue, Jun 4, 2019 at 5:41 PM Sjoerd Simons
> >  wrote:
>
> > We have been using imx_usb_loader for a long time. After DM / fit
> > comvesion the IVT piece is not added into the final .img.
> >
> > From the main Makefile:
> >
> > ifdef CONFIG_SPL_LOAD_FIT
> > MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O
> > u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
> > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
> > else
> > MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> > MKIMAGEFLAGS_u-boot-ivt.img = -A $(ARCH) -T firmware_ivt -C none -O
> > u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board"
> > u-boot-ivt.img: MKIMAGEOUTPUT = u-boot-ivt.img.log
> > CLEAN_FILES += u-boot-ivt.img.log u-boot-dtb.imx.log SPL.log u-
> > boot.imx.log
> > endif
> >
> > we  can see that the ivt is not added for the CONFIG_SPL_LOAD_FIT
> > case.
> >
> > I tried to change this logic, but so far was not able to make it
> > work.
>
> So when looking through how secure boot can work from the SPL i can
> accross e246bfcfe. Which explains the u-boot SPL expect a signed fit
> image with roughly the following layout:
>
> --
> | | | |   |   | ||
> | FIT | FIT | FIT |   | U-BOOT| ATF | U-BOOT |
> | FDT | IVT | CSF |   | nodtb.bin | |   DTB  |
> | | | |   |   | ||
> --
>
> The code aligns the IVT at 0x1000 and the standard CSF size is
> 0x2000. So one has to set CONFIG_FIT_EXTERNAL_OFFSET=0x3000 (assuming the FIT 
> FDT <= 0x1000 bytes) to make CONFIG_SECURE_BOOT work in this setup (even if 
> HAB is off and the image isn't signed). Otherwise the SPL won't pick up the 
> correct location for all the external data.
>
> Seems a bit ugly that the start offset of the external data can't be
> introspected from the fdt blob, but oh well.
>
> The way this seems to work for i.mx8 is that the SECOND_LOADER command
> sticks in a IVT header into the fit image. I assume some other tooling
> can then stick the CSF data in the appropriate place (anyone have a
> pointer?).
>

Thanks for looking at this issue.

We are using similar structure in NXP U-Boot for i.MX8M devices, you
can use dd tool as explained in document below:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/guides/mx8m_mx8mm_secure_boot.txt?h=imx_v2018.03_4.14.98_2.0.0_ga#n301

> Now i guess the first question becomes whether the i.mx6 should follow
> the same layout. And if so how to integrate it properly (teach mkimage
> about handling firmware_ivt for fit images?).
>

IMHO we should follow the same layout as in i.MX8M, as far as I know
in NXP BSP this is handled by imx-mkimage tool:
https://source.codeaurora.org/external/imx/imx-mkimage/?h=imx_4.14.98_2.0.0_ga

Perhaps we can try similar with mkimage tool included in upstream U-Boot?

> Relatedly i was looking for a good description of using HAB for loading
> the OS in FIT images, but failed to find a good document. pointers
> welcome.
>

For HAB API usage you can take a look in HABv4 RVT Guidelines and
Recommendations application note:
https://www.nxp.com/docs/en/application-note/AN12263.pdf

The U-Boot docs in NXP BSP U-Boot also provides an overview:
https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4?h=imx_v2018.03_4.14.98_2.0.0_ga

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

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Kever Yang]

Hi Paul,


On 06/19/2019 12:12 AM, Mark Kettenis wrote:
>> From: Paul Kocialkowski 
>> Date: Tue, 18 Jun 2019 14:47:33 +0200
>>
>> Hi Kever,
>>
>> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
>>> Hi Paul,
>>>
>>>
>>> On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
 Hi,

 On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
>  wrote:
>> Hi,
>>
>> On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com wrote:
>>> From: Nick Xie 
>> Was this tested with SPL support? I don't see DRAM configuration here
>> so it seems that it relies on the non-free rockchip loader.
>>
>> If that is the case, could you please indicate that in the commit
>> message?
>>
>> To maintainers: please do not merge this series before DRAM init and
>> SPL support is available for these boards.
>>
>> It seems that other RK3399 boards were merged without SPL support and
>> sofar, I have the feeling that nobody cared to explain how we got into
>> this broken situation. Please don't merge any more such board.
> fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> with TPL-enabled (which was discussed on the threads, if you remember)
> with below boot chain.
>
> rkbin (TPL) -> SPL -> U-Boot proper
>
> Same case for this board as well.
 Here is a quote from Philipp Tomsich on the thread we discussed this:

 " On some boards, there will be no TPL and only a SPL stage that will
 initialise DRAM (as the move to having TPL on the RK3399 is optional).

 I agree with Paul that the DRAM init should be part of U-Boot whenever
 we add new boards and make an open DRAM init a prerequisite. "

 So even if I frequently confuse SPL and TPL, it doesn't change the fact
 that no board should be merged without proper DRAM init.

 Please stop pushing for merging these boards. I'm not sure what we
 should do about the boards that were merged already without DRAM init,
 but maybe they should be reverted.
>>> I don't think we have to have full DRAM init source code for each
>>> board before we can merge it, I believe most of the board on U-Boot
>>> mainline need to removed due to this rule. There are so many boards
>>> from different vendor need a binary loader before U-Boot, and I can
>>> see only very few drivers for dram at driver/ram/, and I believe rockchip
>>> is already the most open vendor on this area.
>> Well, I am not talking about full DRAM init source code as in dynamic
>> link training. I am talking about having at least static DRAM register
>> configuration values, 

I can tell you that this is no work for all the boards, you can see how
rockchip
lpddr4(WIP, send by Jagan) driver works.
>> which is present for a good number of rockchip
>> boards.

No, there is no rockchip board only have static DRAM register
configuration values,
that maybe happens in other vendor.
>>
>> Of course, it would be best if Rockchip would consider releasing this
>> source code, 

Rockchip already release all the DRAM init source code, including DDR3 ,
LPDDR3,
and LPDDR4(wip). You can see the driver at driver/ram/rockchip/ for
everything,
which is not only static register configuration.
As I have said, rockchip is already the most open vendor in this area
till now, I don't know
if you have working on rockchip SoC based boards.

>> which would be the easiest and friendliest solution
>> towards the community here. Are there internal discussions ongoing
>> about this? If not, it would be greatly appreciated to start such
>> discussions and clearly identify what the blocking points are.
>>
>>> I won't use this rule to stop developers contribute there source code,
>> This is really sad and I think that Philipp was, like me, inclined to
>> go towards the other direction.
>>
>>> for a board support, we only need the board to have the full documentation
>>> about how to setup and boot with upstream U-Boot. and I think the
>>> most of people cares more about features in U-Boot proper. Everything
>>> before U-Boot proper, you can use TPL/SPL or alternative to use binary
>>> from vendor, as you can see all over the U-Boot mainline now, although
>>> we encourage people to use full open source TPL/SPL.
>>> Specifically for U-Boot Rockchip platform, I would like people to
>>> support not only U-Boot
>>> proper, but also for full SPL(ATF, OP-TEE support, itb image and other
>>> features)
>>> support. And for DRAM init,
>>> - if this belongs to SPL for this board, you must implement it or else
>>> SPL won't work;
>>> - if this does not belong to SPL for this board, you need implement full
>>> function SPL;
>>> and you can either to have full function TPL with DRAM init(which is
>>> prefered)
>>> or alternatively use binary loader from vendor.
>> This is not really a technical argument here, more of a policy argument
>> that ensures we have 

[U-Boot] [PATCH] disk: part: Don't skip partition init

[Robert Hancock]

blk_get_device_by_str was skipping part_init when hw partition 0 was
selected because it is the default. However, this caused issues when
switching to a non-zero partition and then back to partition zero, as
stale data from the wrong partition was returned.

Remove this optimization and call part_init regardless of the selected
partition.

Signed-off-by: Robert Hancock 
---
 disk/part.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index 862078f..f14bc22 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -414,11 +414,10 @@ int blk_get_device_by_str(const char *ifname, const char 
*dev_hwpart_str,
 #ifdef CONFIG_HAVE_BLOCK_DEVICE
/*
 * Updates the partition table for the specified hw partition.
-* Does not need to be done for hwpart 0 since it is default and
-* already loaded.
+* Always should be done, otherwise hw partition 0 will return stale
+* data after displaying a non-zero hw partition.
 */
-   if(hwpart != 0)
-   part_init(*dev_desc);
+   part_init(*dev_desc);
 #endif
 
 cleanup:
-- 
1.8.3.1

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

[U-Boot] [PATCH 4/5] fpga: virtex2: Add additional clock cycles after DONE assertion

[Robert Hancock]

Some Xilinx FPGA configuration options can result in the startup
sequence extending past the end of the FPGA bitstream. Continue applying
CCLK clock cycles for 8 cycles after DONE is asserted in order to ensure
the startup sequence is complete, as recommended by Xilinx.

Signed-off-by: Robert Hancock 
---
 drivers/fpga/virtex2.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c
index 2383c69..5028244 100644
--- a/drivers/fpga/virtex2.c
+++ b/drivers/fpga/virtex2.c
@@ -247,6 +247,7 @@ static int 
virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
  int cookie)
 {
int ret_val = FPGA_SUCCESS;
+   int num_done = 0;
unsigned long ts;
 
/*
@@ -264,12 +265,18 @@ static int 
virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
 
/*
 * Check for successful configuration.  FPGA INIT_B and DONE
-* should both be high upon successful configuration.
+* should both be high upon successful configuration. Continue pulsing
+* clock with data set to all ones until DONE is asserted and for 8
+* clock cycles afterwards.
 */
ts = get_timer(0);
-   ret_val = FPGA_SUCCESS;
-   while (((*fn->done)(cookie) == FPGA_FAIL) ||
-  (*fn->init)(cookie)) {
+   while (true) {
+   if ((*fn->done)(cookie) == FPGA_SUCCESS &&
+   !((*fn->init)(cookie))) {
+   if (num_done++ >= 8)
+   break;
+   }
+
if (get_timer(ts) > CONFIG_SYS_FPGA_WAIT_CONFIG) {
printf("%s:%d: ** Timeout after %d ticks waiting for 
DONE to assert and INIT to deassert\n",
   __func__, __LINE__, CONFIG_SYS_FPGA_WAIT_CONFIG);
@@ -277,6 +284,11 @@ static int 
virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
ret_val = FPGA_FAIL;
break;
}
+   (*fn->wdata) (0xff, true, cookie);
+   CONFIG_FPGA_DELAY();
+   (*fn->clk) (false, true, cookie);
+   CONFIG_FPGA_DELAY();
+   (*fn->clk) (true, true, cookie);
}
 
if (ret_val == FPGA_SUCCESS) {
-- 
1.8.3.1

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[Jernej Škrabec]

Dne torek, 18. junij 2019 ob 19:13:16 CEST je Clément Péron napisal(a):
> Hi,
> 
> On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
> > The first USB controller on the H6 SoC shares a PHY with the OTG
> > controller. Reportedly to avoid problems with the VBUS regulator under
> > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
> > 
> > However on boards which can't use peripheral mode (because they have an
> > always-on VBUS supply on an USB-A socket) we don't need this trick, and
> > can properly connect host controller 0 to the PHY 0.
> > 
> > Amend the Pine H64 .dts to reflect this. This enables the upper USB port
> > in U-Boot on this board.
> > 
> > Signed-off-by: Andre Przywara 
> > ---
> > 
> >  arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > b/arch/arm/dts/sun50i-h6-pine-h64.dts index 4802902e12..aad7646b18 100644
> > --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
> > @@ -96,6 +96,8 @@
> > 
> >  };
> >  
> >   {
> > 
> > +   phys = < 0>;
> > +   phy-names = "usb";
> > 
> > status = "okay";
> >  
> >  };
> > 
> > @@ -120,6 +122,8 @@
> > 
> >  };
> >  
> >   {
> > 
> > +   phys = < 0>;
> > +   phy-names = "usb";
> > 
> > status = "okay";
> >  
> >  };
> > 
> > @@ -255,7 +259,6 @@
> > 
> >   {
> >  
> > dr_mode = "host";
> > 
> > -   status = "okay";
> > 
> >  };
> 
> Maybe you should add explicit comments in the device-tree to avoid
> losing this at next sync with linux dt.

If DT change is U-Boot specific, it should be moved to *-u-boot.dtsi file, 
although I'm not sure if you can delete properties in such way.

Best regards,
Jernej

> 
> Regards,
> Clement
> 
> >   {
> > 
> > --
> > 2.14.5




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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[Chen-Yu Tsai]

On Wed, Jun 19, 2019 at 1:17 AM Jernej Škrabec  wrote:
>
> Dne torek, 18. junij 2019 ob 19:13:16 CEST je Clément Péron napisal(a):
> > Hi,
> >
> > On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
> > > The first USB controller on the H6 SoC shares a PHY with the OTG
> > > controller. Reportedly to avoid problems with the VBUS regulator under
> > > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
> > >
> > > However on boards which can't use peripheral mode (because they have an
> > > always-on VBUS supply on an USB-A socket) we don't need this trick, and
> > > can properly connect host controller 0 to the PHY 0.
> > >
> > > Amend the Pine H64 .dts to reflect this. This enables the upper USB port
> > > in U-Boot on this board.
> > >
> > > Signed-off-by: Andre Przywara 
> > > ---
> > >
> > >  arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > b/arch/arm/dts/sun50i-h6-pine-h64.dts index 4802902e12..aad7646b18 100644
> > > --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
> > > @@ -96,6 +96,8 @@
> > >
> > >  };
> > >
> > >   {
> > >
> > > +   phys = < 0>;
> > > +   phy-names = "usb";
> > >
> > > status = "okay";
> > >
> > >  };
> > >
> > > @@ -120,6 +122,8 @@
> > >
> > >  };
> > >
> > >   {
> > >
> > > +   phys = < 0>;
> > > +   phy-names = "usb";
> > >
> > > status = "okay";
> > >
> > >  };
> > >
> > > @@ -255,7 +259,6 @@
> > >
> > >   {
> > >
> > > dr_mode = "host";
> > >
> > > -   status = "okay";
> > >
> > >  };
> >
> > Maybe you should add explicit comments in the device-tree to avoid
> > losing this at next sync with linux dt.
>
> If DT change is U-Boot specific, it should be moved to *-u-boot.dtsi file,
> although I'm not sure if you can delete properties in such way.

You can use /delete-property/. Though in the case of "status",
it is best to set it to "disabled", since no property is the same
as "okay".

The question then becomes when the *-u-boot.dtsi file is merged in.

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

Re: [U-Boot] [PATCH] pinctrl: renesas: Synchronize Gen2/Gen3 tables with Linux 5.2-rc5

[Jeremy Kerr]

Hi Eugeniu,

> Replicating the chronology of the issue, do you think it could be
> related to 1) the patch size or to 2) the moderator's approval event?
> 
>   +--+
>   |1. Patch sent |
>   +--+---+
>  |   
>   +--v+
>   |2. U-Boot reports awaiting moderator's approval|
>   |   (the patch does not show up in patchwork)   |
>   +--++
>  |   
>   +--v---+
>   |3. Reply A (not rendered by patchwork)|
>   +--+---+
>  |   
>   +--v---+
>   |4. Reply B (not rendered by patchwork)|
>   +--+---+
>  |   
>   +--v-+
>   |5. Patch approved by moderator  |
>   |   (the patch shows up in patchwork)|
>   +--+-+
>  |   
>   +--v---+
>   |6. Reply C (rendered by patchwork)|
>   +--+---+
>  |
>   +--v---+
>   |7. Reply D (rendered by patchwork)|
>   +--+


Ah, that would explain it. If an incoming email is not a patch, then
patchwork will assume it is a follow-up to a patch, and try to find the
relevant patch (through the References: and In-Reply-To headers). If no
suitable patch is found, then patchwork does not save the email.

It sounds like that's what's happening here. Since reply A and reply B
are referencing a patch that does not (yet) exist, then the comments are
not kept.

The alternative would be to keep *every* submission to the list, in case
a relevant patch arrives later...

Cheers,


Jeremy




> > I guess we
> > could attempt to decode these, though that's arguably a new feature
> > so
> > I'm not sure if we could backport it to 'stable/2.1'. In any case,
> > could you provide an mbox replete with all the headers so I can see
> > if
> > there are any heuristics we can use to identify these emails?
> 
> Do you mean https://patchwork.ozlabs.org/patch/1117783/mbox/ ?
> 
> > Stephen
> > 
> > [1] https://marc.info/?l=u-boot=156085461011871=mbox
> 
> Thanks again!
> 

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

[U-Boot] [PATCH 2/5] fpga: virtex2: added Kconfig option

[Robert Hancock]

Add an option to allow this driver to be selected with Kconfig. As noted
in the description, this driver should also work with many newer Xilinx
FPGA families as the programming methods are essentially the same.

Also added a missing FPGA_XILINX dependency to the similar Spartan 3
driver.

Signed-off-by: Robert Hancock 
---
 drivers/fpga/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 8f59193..105a299 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -58,9 +58,17 @@ config FPGA_ZYNQMPPL
 
 config FPGA_SPARTAN3
bool "Enable Spartan3 FPGA driver"
+   depends on FPGA_XILINX
help
  Enable Spartan3 FPGA driver for loading in BIT format.
 
+config FPGA_VIRTEX2
+   bool "Enable Xilinx Virtex-II and later FPGA driver"
+   depends on FPGA_XILINX
+   help
+ Enable Virtex-II FPGA driver for loading in BIT format. This driver
+ also supports many newer Xilinx FPGA families.
+
 config FPGA_ZYNQPL
bool "Enable Xilinx FPGA for Zynq"
depends on ARCH_ZYNQ
-- 
1.8.3.1

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

[U-Boot] [PATCH] driver: watchdog: Add new iMX/LSCH2 WDT driver

[Robert Hancock]

This is a new watchdog timer driver for iMX and LSCH2 using the WDT
framework and driver model. This allows ensuring that U-Boot uses the
same watchdog timer instance and same settings (ex: internal or external
reset) specified in the device tree.

This driver can be used in preference to the old imx_watchdog driver for
boards which have been converted to use the driver model.

Signed-off-by: Robert Hancock 
---
 drivers/watchdog/Kconfig   |  14 --
 drivers/watchdog/Makefile  |   3 ++
 drivers/watchdog/imx_wdt.c | 112 +
 3 files changed, 126 insertions(+), 3 deletions(-)
 create mode 100644 drivers/watchdog/imx_wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index dbafb74..0e8c8e5 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -27,11 +27,11 @@ config BCM2835_WDT
  hardware, with a max timeout of ~15secs.
 
 config IMX_WATCHDOG
-   bool "Enable Watchdog Timer support for IMX and LSCH2 of NXP"
+   bool "Enable legacy Watchdog Timer support for IMX and LSCH2 of NXP"
select HW_WATCHDOG
help
-  Select this to enable the IMX and LSCH2 of Layerscape watchdog
-  driver.
+  Select this to enable the IMX and LSCH2 of Layerscape legacy watchdog
+  driver (not using driver model).
 
 config OMAP_WATCHDOG
bool "TI OMAP watchdog driver"
@@ -109,6 +109,14 @@ config WDT_CDNS
   Select this to enable Cadence watchdog timer, which can be found on 
some
   Xilinx Microzed Platform.
 
+config WDT_IMX
+   bool "iMX/LSCH2 watchdog timer support"
+   depends on WDT && (ARCH_MX25 || ARCH_MX31 || ARCH_MX35 || ARCH_MX5 || 
ARCH_MX6 || ARCH_MX7 || ARCH_VF610)
+   imply WATCHDOG
+   help
+  Select this to enable the IMX and LSCH2 of Layerscape watchdog
+  driver using driver model.
+
 config WDT_MPC8xx
bool "MPC8xx watchdog timer support"
depends on WDT && MPC8xx
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index e3f4fdb..49dd457 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -5,11 +5,13 @@
 
 obj-$(CONFIG_WDT_AT91) += at91sam9_wdt.o
 obj-$(CONFIG_FTWDT010_WATCHDOG) += ftwdt010_wdt.o
+ifndef CONFIG_WDT_IMX
 ifneq (,$(filter $(SOC), mx25 mx31 mx35 mx5 mx6 mx7 vf610))
 obj-y += imx_watchdog.o
 else
 obj-$(CONFIG_IMX_WATCHDOG) += imx_watchdog.o
 endif
+endif
 obj-$(CONFIG_S5P)   += s5p_wdt.o
 obj-$(CONFIG_XILINX_TB_WATCHDOG) += xilinx_tb_wdt.o
 obj-$(CONFIG_OMAP_WATCHDOG) += omap_wdt.o
@@ -24,6 +26,7 @@ obj-$(CONFIG_WDT_BCM6345) += bcm6345_wdt.o
 obj-$(CONFIG_BCM2835_WDT)   += bcm2835_wdt.o
 obj-$(CONFIG_WDT_ORION) += orion_wdt.o
 obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
+obj-$(CONFIG_WDT_IMX) += imx_wdt.o
 obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
 obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
 obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
diff --git a/drivers/watchdog/imx_wdt.c b/drivers/watchdog/imx_wdt.c
new file mode 100644
index 000..1b4a5e6
--- /dev/null
+++ b/drivers/watchdog/imx_wdt.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * imx_wdt.c - WDT driver for Freescale/NXP i.MX on-chip watchdog
+ * Copyright (c) 2019 SED Systems, a division of Calian Ltd.
+ *
+ * Based on Linux 4.19 drivers/watchdog/imx2_wdt.c which is:
+ *  Copyright (C) 2010 Wolfram Sang, Pengutronix e.K. 
+ *  Copyright (C) 2014 Freescale Semiconductor, Inc.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct imx_wdt_priv {
+   struct watchdog_regs *regs;
+   bool ext_reset;
+};
+
+static int imx_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+   u16 timeout_reg = (timeout / 500) - 1;
+   u16 wcr = WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_SRS |
+ WCR_WDA | SET_WCR_WT(timeout_reg);
+
+   if (priv->ext_reset)
+   wcr |= WCR_WDT;
+
+   debug("%s timeout %llu, wcr %04hX\n", __func__, timeout, wcr);
+
+   writew(wcr, >regs->wcr);
+
+   return 0;
+}
+
+static int imx_wdt_reset(struct udevice *dev)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+
+   writew(0x, >regs->wsr);
+   writew(0x, >regs->wsr);
+   return 0;
+}
+
+static int imx_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+   struct imx_wdt_priv *priv = dev_get_priv(dev);
+   u16 wcr = WCR_WDE;
+
+   if (priv->ext_reset)
+   wcr |= WCR_SRS; /* do not assert internal reset */
+   else
+   wcr |= WCR_WDA; /* do not assert external reset */
+
+   debug("%s wcr %04hX\n", __func__, wcr);
+
+   /* Write 3 times to ensure it works, due to IMX6Q errata ERR004346 */
+   writew(wcr, >regs->wcr);
+   writew(wcr, >regs->wcr);
+   writew(wcr, >regs->wcr);
+
+   return 0;
+}
+
+static int imx_wdt_ofdata_to_platdata(struct udevice *dev)
+{
+   struct 

[U-Boot] [PATCH 3/5] fpga: virtex2: Split out image writing from pre/post operations

[Robert Hancock]

This is in preparation for adding slave serial programming support,
which uses the same pre/post operations as slave SelectMAP, to avoid
duplicating code.

Signed-off-by: Robert Hancock 
---
 drivers/fpga/virtex2.c | 331 ++---
 1 file changed, 174 insertions(+), 157 deletions(-)

diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c
index b01a31f..2383c69 100644
--- a/drivers/fpga/virtex2.c
+++ b/drivers/fpga/virtex2.c
@@ -154,202 +154,219 @@ static int virtex2_info(xilinx_desc *desc)
  *INIT_B and DONE lines.  If both are high, configuration has
  *succeeded. Congratulations!
  */
-static int virtex2_ssm_load(xilinx_desc *desc, const void *buf, size_t bsize)
+static int virtex2_slave_pre(xilinx_virtex2_slave_selectmap_fns *fn, int 
cookie)
 {
-   int ret_val = FPGA_FAIL;
-   xilinx_virtex2_slave_selectmap_fns *fn = desc->iface_fns;
+   unsigned long ts;
 
PRINTF("%s:%d: Start with interface functions @ 0x%p\n",
   __func__, __LINE__, fn);
 
-   if (fn) {
-   size_t bytecount = 0;
-   unsigned char *data = (unsigned char *)buf;
-   int cookie = desc->cookie;
-   unsigned long ts;
-
-   /* Gotta split this one up (so the stack won't blow??) */
-   PRINTF("%s:%d: Function Table:\n"
-  "  base   0x%p\n"
-  "  struct 0x%p\n"
-  "  pre0x%p\n"
-  "  prog   0x%p\n"
-  "  init   0x%p\n"
-  "  error  0x%p\n",
-  __func__, __LINE__,
-  , fn, fn->pre, fn->pgm, fn->init, fn->err);
-   PRINTF("  clock  0x%p\n"
-  "  cs 0x%p\n"
-  "  write  0x%p\n"
-  "  rdata  0x%p\n"
-  "  wdata  0x%p\n"
-  "  busy   0x%p\n"
-  "  abort  0x%p\n"
-  "  post   0x%p\n\n",
-  fn->clk, fn->cs, fn->wr, fn->rdata, fn->wdata,
-  fn->busy, fn->abort, fn->post);
+   if (!fn) {
+   printf("%s:%d: NULL Interface function table!\n",
+  __func__, __LINE__);
+   return FPGA_FAIL;
+   }
+
+   /* Gotta split this one up (so the stack won't blow??) */
+   PRINTF("%s:%d: Function Table:\n"
+  "  base   0x%p\n"
+  "  struct 0x%p\n"
+  "  pre0x%p\n"
+  "  prog   0x%p\n"
+  "  init   0x%p\n"
+  "  error  0x%p\n",
+  __func__, __LINE__,
+  , fn, fn->pre, fn->pgm, fn->init, fn->err);
+   PRINTF("  clock  0x%p\n"
+  "  cs 0x%p\n"
+  "  write  0x%p\n"
+  "  rdata  0x%p\n"
+  "  wdata  0x%p\n"
+  "  busy   0x%p\n"
+  "  abort  0x%p\n"
+  "  post   0x%p\n\n",
+  fn->clk, fn->cs, fn->wr, fn->rdata, fn->wdata,
+  fn->busy, fn->abort, fn->post);
 
 #ifdef CONFIG_SYS_FPGA_PROG_FEEDBACK
-   printf("Initializing FPGA Device %d...\n", cookie);
+   printf("Initializing FPGA Device %d...\n", cookie);
 #endif
-   /*
-* Run the pre configuration function if there is one.
-*/
-   if (*fn->pre)
-   (*fn->pre)(cookie);
-
-   /*
-* Assert the program line.  The minimum pulse width for
-* Virtex II devices is 300 nS (Tprogram parameter in
-* datasheet). There is no maximum value for the pulse width.
-* Check to make sure that INIT_B goes low after assertion of
-* PROG_B
-*/
-   (*fn->pgm)(true, true, cookie);
-   udelay(10);
-   ts = get_timer(0);
-   do {
-   if (get_timer(ts) > CONFIG_SYS_FPGA_WAIT_INIT) {
-   printf("%s:%d: ** Timeout after %d ticks 
waiting for INIT to assert.\n",
-  __func__, __LINE__,
-  CONFIG_SYS_FPGA_WAIT_INIT);
-   (*fn->abort)(cookie);
-   return FPGA_FAIL;
-   }
-   } while (!(*fn->init)(cookie));
+   /*
+* Run the pre configuration function if there is one.
+*/
+   if (*fn->pre)
+   (*fn->pre)(cookie);
+
+   /*
+* Assert the program line.  The minimum pulse width for
+* Virtex II devices is 300 nS (Tprogram parameter in datasheet).
+* There is no maximum value for the pulse width. Check to make
+* sure that INIT_B goes low after assertion of PROG_B
+*/
+   (*fn->pgm)(true, true, cookie);
+   udelay(10);
+   ts = 

[U-Boot] [PATCH 5/5] fpga: virtex2: Add slave serial programming support

[Robert Hancock]

This adds support for slave serial programming, in addition to the
previously supported slave SelectMAP mode. There are two ways that this
can be used:

-Using the clk and wdata callbacks in order to write image data one bit
at a time using pure bit-banging. This works, but is rather painfully
slow with typical image sizes.

-By specifying the wbulkdata callback instead, the image loading process
can be offloaded to SPI hardware. In this mode the clk and wdata
callbacks do not need to be specified. This allows the image to be
loaded much faster, taking only a few seconds with even relatively large
images.

Slave serial programming has been tested on the Kintex-7 series of
FPGAs.

Signed-off-by: Robert Hancock 
---
 drivers/fpga/virtex2.c | 96 +++---
 include/virtex2.h  | 13 ++-
 2 files changed, 86 insertions(+), 23 deletions(-)

diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c
index 5028244..3957368 100644
--- a/drivers/fpga/virtex2.c
+++ b/drivers/fpga/virtex2.c
@@ -3,6 +3,8 @@
  * (C) Copyright 2002
  * Rich Ireland, Enterasys Networks, rirel...@enterasys.com.
  * Keith Outwater, keith_outwa...@mvis.com
+ *
+ * Copyright (c) 2019 SED Systems, a division of Calian Ltd.
  */
 
 /*
@@ -141,8 +143,8 @@ static int virtex2_info(xilinx_desc *desc)
 }
 
 /*
- * Virtex-II Slave SelectMap configuration loader. Configuration via
- * SelectMap is as follows:
+ * Virtex-II Slave SelectMap or Serial configuration loader. Configuration
+ * is as follows:
  * 1. Set the FPGA's PROG_B line low.
  * 2. Set the FPGA's PROG_B line high.  Wait for INIT_B to go high.
  * 3. Write data to the SelectMap port.  If INIT_B goes low at any time
@@ -154,7 +156,7 @@ static int virtex2_info(xilinx_desc *desc)
  *INIT_B and DONE lines.  If both are high, configuration has
  *succeeded. Congratulations!
  */
-static int virtex2_slave_pre(xilinx_virtex2_slave_selectmap_fns *fn, int 
cookie)
+static int virtex2_slave_pre(xilinx_virtex2_slave_fns *fn, int cookie)
 {
unsigned long ts;
 
@@ -243,7 +245,7 @@ static int 
virtex2_slave_pre(xilinx_virtex2_slave_selectmap_fns *fn, int cookie)
return FPGA_SUCCESS;
 }
 
-static int virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
+static int virtex2_slave_post(xilinx_virtex2_slave_fns *fn,
  int cookie)
 {
int ret_val = FPGA_SUCCESS;
@@ -284,11 +286,16 @@ static int 
virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
ret_val = FPGA_FAIL;
break;
}
-   (*fn->wdata) (0xff, true, cookie);
-   CONFIG_FPGA_DELAY();
-   (*fn->clk) (false, true, cookie);
-   CONFIG_FPGA_DELAY();
-   (*fn->clk) (true, true, cookie);
+   if (fn->wbulkdata) {
+   unsigned char dummy = 0xff;
+   (*fn->wbulkdata)(, 1, true, cookie);
+   } else {
+   (*fn->wdata)(0xff, true, cookie);
+   CONFIG_FPGA_DELAY();
+   (*fn->clk)(false, true, cookie);
+   CONFIG_FPGA_DELAY();
+   (*fn->clk)(true, true, cookie);
+   }
}
 
if (ret_val == FPGA_SUCCESS) {
@@ -312,7 +319,7 @@ static int 
virtex2_slave_post(xilinx_virtex2_slave_selectmap_fns *fn,
 static int virtex2_ssm_load(xilinx_desc *desc, const void *buf, size_t bsize)
 {
int ret_val = FPGA_FAIL;
-   xilinx_virtex2_slave_selectmap_fns *fn = desc->iface_fns;
+   xilinx_virtex2_slave_fns *fn = desc->iface_fns;
size_t bytecount = 0;
unsigned char *data = (unsigned char *)buf;
int cookie = desc->cookie;
@@ -387,7 +394,7 @@ static int virtex2_ssm_load(xilinx_desc *desc, const void 
*buf, size_t bsize)
 static int virtex2_ssm_dump(xilinx_desc *desc, const void *buf, size_t bsize)
 {
int ret_val = FPGA_FAIL;
-   xilinx_virtex2_slave_selectmap_fns *fn = desc->iface_fns;
+   xilinx_virtex2_slave_fns *fn = desc->iface_fns;
 
if (fn) {
unsigned char *data = (unsigned char *)buf;
@@ -438,8 +445,71 @@ static int virtex2_ssm_dump(xilinx_desc *desc, const void 
*buf, size_t bsize)
 
 static int virtex2_ss_load(xilinx_desc *desc, const void *buf, size_t bsize)
 {
-   printf("%s: Slave Serial Loading is unsupported\n", __func__);
-   return FPGA_FAIL;
+   int ret_val = FPGA_FAIL;
+   xilinx_virtex2_slave_fns *fn = desc->iface_fns;
+   unsigned char *data = (unsigned char *)buf;
+   int cookie = desc->cookie;
+
+   ret_val = virtex2_slave_pre(fn, cookie);
+   if (ret_val != FPGA_SUCCESS)
+   return ret_val;
+
+   if (fn->wbulkdata) {
+   /* Load the data in a single chunk */
+   (*fn->wbulkdata)(data, bsize, true, cookie);
+   } else {
+   size_t bytecount = 0;
+
+   /*
+  

[U-Boot] [PATCH 1/5] fpga: virtex2: cosmetic: Cleanup code style

[Robert Hancock]

Address Checkpatch warnings in virtex2 code prior to making other
changes. No functional change intended.

Signed-off-by: Robert Hancock 
---
 drivers/fpga/virtex2.c | 270 +
 1 file changed, 136 insertions(+), 134 deletions(-)

diff --git a/drivers/fpga/virtex2.c b/drivers/fpga/virtex2.c
index 02773d6..b01a31f 100644
--- a/drivers/fpga/virtex2.c
+++ b/drivers/fpga/virtex2.c
@@ -19,16 +19,16 @@
 #endif
 
 #ifdef FPGA_DEBUG
-#definePRINTF(fmt,args...) printf (fmt ,##args)
+#definePRINTF(fmt, args...)printf(fmt, ##args)
 #else
-#define PRINTF(fmt,args...)
+#define PRINTF(fmt, args...)
 #endif
 
 /*
  * If the SelectMap interface can be overrun by the processor, define
- * CONFIG_SYS_FPGA_CHECK_BUSY and/or CONFIG_FPGA_DELAY in the board 
configuration
- * file and add board-specific support for checking BUSY status. By default,
- * assume that the SelectMap interface cannot be overrun.
+ * CONFIG_SYS_FPGA_CHECK_BUSY and/or CONFIG_FPGA_DELAY in the board
+ * configuration file and add board-specific support for checking BUSY status.
+ * By default, assume that the SelectMap interface cannot be overrun.
  */
 #ifndef CONFIG_SYS_FPGA_CHECK_BUSY
 #undef CONFIG_SYS_FPGA_CHECK_BUSY
@@ -65,7 +65,7 @@
  * an XC2V1000, if anyone can ever get ahold of one.
  */
 #ifndef CONFIG_SYS_FPGA_WAIT_INIT
-#define CONFIG_SYS_FPGA_WAIT_INIT  CONFIG_SYS_HZ/2 /* 500 ms */
+#define CONFIG_SYS_FPGA_WAIT_INIT  CONFIG_SYS_HZ / 2   /* 500 ms */
 #endif
 
 /*
@@ -74,14 +74,14 @@
  * clock frequencies (i.e. 66 MHz or less), BUSY monitoring is unnecessary.
  */
 #ifndef CONFIG_SYS_FPGA_WAIT_BUSY
-#define CONFIG_SYS_FPGA_WAIT_BUSY  CONFIG_SYS_HZ/200   /* 5 ms*/
+#define CONFIG_SYS_FPGA_WAIT_BUSY  CONFIG_SYS_HZ / 200 /* 5 ms*/
 #endif
 
 /* Default timeout for waiting for FPGA to enter operational mode after
  * configuration data has been written.
  */
 #ifndefCONFIG_SYS_FPGA_WAIT_CONFIG
-#define CONFIG_SYS_FPGA_WAIT_CONFIGCONFIG_SYS_HZ/5 /* 200 ms */
+#define CONFIG_SYS_FPGA_WAIT_CONFIGCONFIG_SYS_HZ / 5   /* 200 ms */
 #endif
 
 static int virtex2_ssm_load(xilinx_desc *desc, const void *buf, size_t bsize);
@@ -97,18 +97,18 @@ static int virtex2_load(xilinx_desc *desc, const void *buf, 
size_t bsize,
 
switch (desc->iface) {
case slave_serial:
-   PRINTF ("%s: Launching Slave Serial Load\n", __FUNCTION__);
+   PRINTF("%s: Launching Slave Serial Load\n", __func__);
ret_val = virtex2_ss_load(desc, buf, bsize);
break;
 
case slave_selectmap:
-   PRINTF ("%s: Launching Slave Parallel Load\n", __FUNCTION__);
+   PRINTF("%s: Launching Slave Parallel Load\n", __func__);
ret_val = virtex2_ssm_load(desc, buf, bsize);
break;
 
default:
-   printf ("%s: Unsupported interface type, %d\n",
-   __FUNCTION__, desc->iface);
+   printf("%s: Unsupported interface type, %d\n",
+  __func__, desc->iface);
}
return ret_val;
 }
@@ -119,18 +119,18 @@ static int virtex2_dump(xilinx_desc *desc, const void 
*buf, size_t bsize)
 
switch (desc->iface) {
case slave_serial:
-   PRINTF ("%s: Launching Slave Serial Dump\n", __FUNCTION__);
+   PRINTF("%s: Launching Slave Serial Dump\n", __func__);
ret_val = virtex2_ss_dump(desc, buf, bsize);
break;
 
case slave_parallel:
-   PRINTF ("%s: Launching Slave Parallel Dump\n", __FUNCTION__);
+   PRINTF("%s: Launching Slave Parallel Dump\n", __func__);
ret_val = virtex2_ssm_dump(desc, buf, bsize);
break;
 
default:
-   printf ("%s: Unsupported interface type, %d\n",
-   __FUNCTION__, desc->iface);
+   printf("%s: Unsupported interface type, %d\n",
+  __func__, desc->iface);
}
return ret_val;
 }
@@ -159,135 +159,135 @@ static int virtex2_ssm_load(xilinx_desc *desc, const 
void *buf, size_t bsize)
int ret_val = FPGA_FAIL;
xilinx_virtex2_slave_selectmap_fns *fn = desc->iface_fns;
 
-   PRINTF ("%s:%d: Start with interface functions @ 0x%p\n",
-   __FUNCTION__, __LINE__, fn);
+   PRINTF("%s:%d: Start with interface functions @ 0x%p\n",
+  __func__, __LINE__, fn);
 
if (fn) {
size_t bytecount = 0;
-   unsigned char *data = (unsigned char *) buf;
+   unsigned char *data = (unsigned char *)buf;
int cookie = desc->cookie;
unsigned long ts;
 
/* Gotta split this one up (so the stack won't blow??) */
-   PRINTF ("%s:%d: Function Table:\n"
-   "  base   0x%p\n"
-   

[U-Boot] [PATCH 0/5] Virtex2 FPGA enhancements

[Robert Hancock]

These changes add support for slave serial mode, in addition to the
existing slave SelectMAP mode, for programming Xilinx Virtex2 (and later)
FPGAs, as well as fixing up code style and an issue with the programming
sequence.

Robert Hancock (5):
  fpga: virtex2: cosmetic: Cleanup code style
  fpga: virtex2: added Kconfig option
  fpga: virtex2: Split out image writing from pre/post operations
  fpga: virtex2: Add additional clock cycles after DONE assertion
  fpga: virtex2: Add slave serial programming support

 drivers/fpga/Kconfig   |   8 +
 drivers/fpga/virtex2.c | 503 +
 include/virtex2.h  |  13 +-
 3 files changed, 313 insertions(+), 211 deletions(-)

-- 
1.8.3.1

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

Re: [U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache

[AKASHI Takahiro]

Heinrich,

On Tue, Jun 18, 2019 at 10:45:26PM +0200, Heinrich Schuchardt wrote:
> On 6/18/19 12:34 PM, Ilias Apalodimas wrote:
> >Hi all,
> >
> >[...]
> >I think one version of the functions serving at runtime and boottime is
> >enough.
> >
> >The cache should be used both at runtime and at boottime.
> 
> So do you mean that we should replace the existing "boottime" version
> of get/set_variable with my code (algorithm)?
> 
> This is a bit complicated work because we should be able to *udpate*
> UEFI variables at boottime, but my version of hsearch_runtime() is
> a stripped (and modified) version and doesn't support it.
> >>>
> >>>Do we really need a multilevel hash table? I would not expect hundreds
> >>>of variables.
> >>
> >>Please don't change your point suddenly.
> >>Here we are discussing whether "The cache should be used both at runtime
> >>and at boottime" or not.
> >>
> >Heinrich, the idea here is to present a copy of the variables on the OS
> >and totally disable RT variable updating from the OS.
> >If someone wants to update UEFI variables, we can pack them to a Capsule
> >(using FIT image format) and apply them on next reboot.
> >Given the fact that UEFI variables are not updated that often, isn't this a
> >viable option? If it is, then we need to keep the access separated
> >(as Akashi-san suggests) allowing bootime to change the variables.
> >
> 
> Making the existing hsearch_r() executable at UEFI runtime is,
> as I said before, quite painful.
> >>>
> >>>You could start the cache implementation with a less complicated data
> >>>structure like a linked list.
> >>
> >>This is totally a different issue. I listed this issue
> >>in my cover letter.
> >>
> 
> >Essentially I
> >expect three modules working together:
> >
> >UEFI API implementation <-> Cache <-> Persistence driver
> >
> >I would suggest to put each of these into a separate file.
> >
> >Both the API implementation and the Cache have to be available at
> >Boottime and at Runtime. A first version of the persistence driver may
> >only be working at boottime.
> 
> Unfortunately, this is not practical right now because there is
> already some sort of assumption (and consensus) that we would re-use
> "Standalone MM services", which is already there in EDK2, as
> secure storage for UEFI variables.
> In the case, all the cache would be bypassed.
> In my old prototype, I utilized the cache but dropped that feature
> for several reasons.
> >>>
> >>>What has EDK2 code to do with it?
> >>
> >>Did you follow my comment below?
> Unfortunately, this is not practical right now because there is
> already some sort of assumption (and consensus) that we would re-use
> "Standalone MM services", which is already there in EDK2, as
> secure storage for UEFI variables.
> >We are already working towards having StandAloneMM as an early OP-TEE TA.
> >This will provide us with a secure variable storage for armv7/v8.
> 
> What would this OP-TEE binary do? - This seems to be a source of
> misunderstanding when reviewing this patch.

I and Ilias will give you more details offline, here's a short(?)
answer:

Standalone MM services here means a SPD entity which provides
[Get|Set]Variable APIs to non-secure side firmware, that is
currently EDK2. So the source code of Standalone MM services
is included in EDK2 repository as a matter of fact.

Here is one drawback: It won't allow for other entities running
concurrently on secure side. One example of useful secure feature
is (software-based) TPM. So Linaro is working on modifying/transforming 
Standalone MM to one OP-TEE application, which Ilias mentioned above.

> My guess is that OP-TEE is used to read non-volatile variables only once
> when starting U-Boot and to write non-volatile variables whenever they
> are changed.

So OP-TEE version of StMM is still on-going project and I assume
that this OP-TEE app will support the same set of functionality/APIs
as StMM does.

> All further reading of non-volatile variables and all access to volatile
> variables will be handled by the U-Boot internal variable cache.
> 
> For volatile variables I would assume OP-TEE to never see them. This
> requires that the U-Boot variable cachek supports reading from and
> writing to the cache at runtime.

No. As far as I correctly understand, StMM handles volatile
variables as well as non-volatile variables.
EDK2 on non-secure side will redirect user's request directly
to secure side even without *caching* variable's values.

> StandaloneMmPkg seems to be the hardware independent part of the
> solution. Where will the hardware driver reside in your OP-TEE solution?
> 
> Is the EDK2 hardware store for variables of the MACCHIATObin here:
> edk2-platforms/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c?
> 
> Which hardware platform will you use for testing the U-Boot development
> of you OP-TEE 

Re: [U-Boot] [linux-sunxi] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support

[André Przywara]

On 18/06/2019 08:50, Jagan Teki wrote:
> On Thu, May 16, 2019 at 6:56 AM Andre Przywara  wrote:

Hi,

>> this series enables USB support on the H6 boards. This is mostly just
>> adding some missing pieces here and there, the actual controller and PHY
>> are very similar to the previous ones, if not identical.
>> This is for the 2.0 ports only at the moment, USB 3.0 will be done
>> later (started porting Icenowy's Linux driver).
>> The Pine H64 shares a similar problem as the Pine64+ boards regarding
>> the upper USB port. To enable this port, we need the first patch
>> from the series [1] fixing this issue on the A64 boards.
>>
>> Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was
>> lingering in one of my branches for a while.
>> Patch 2 enables GPIO support for the H6, as this is needed for the Pine
>> H64 to enable the VBUS regulator.
>> Patch 3 adds the clock and reset gates mappings for the USB controller and
>> the PHY, the values are taken from the manual and verified against
>> Linux.
>> Patch 4 adds some code to the PHY driver to skip over not implemented
>> PHYs, as the H6 uses a PHY0/PHY3 combination in the DT.
>> Patch 5 then eventually enables USB in the existing defconfigs.
>> Patch 6 adds the .dts fixes required to get the upper USB port to work
>> on the Pine H64.
>>
>> Clément, can you please verify that this works for the Beelink box?
>> I guess the USB 2.0 port is probably the OTG one, so this setup would
>> look somewhat similar to the PineH64, which would allow you to copy
>> the USB DT nodes from there.
>>
>> Cheers,
>> Andre.
>>
>> [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html
>>
>> Andre Przywara (6):
>>   sunxi: move SUNXI_GPIO to Kconfig
>>   sunxi: gpio: Enable support for H6 pin controller
>>   sunxi: clocks: Add H6 USB clock gates and resets
>>   sunxi: phy: Add USB PHY support for Allwinner H6
>>   sunxi: H6: Enable USB for existing boards
>>   sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
> 
> Except 6/6 (it can be part of DTS sync during MW) and rest
> 
> Reviewed-by: Jagan Teki 

Thanks Jagan!
I will do some minor fixes and drop the DT part in a v2, to be send as
soon as possible.

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

[U-Boot] [PATCH 4/7] sunxi: H6: Add DDR3 support to DRAM controller driver

[Andre Przywara]

At the moment the H6 DRAM driver only supports LPDDR3 DRAM.

Extend the driver to cover DDR3 DRAM as well.

The changes are partly motivated by looking at the ZynqMP register
documentation, partly by looking at register dumps after boot0/libdram
has initialised the controller.

Many thanks to Jernej for contributing some fixes!

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h |  7 +++
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 71 +---
 2 files changed, 57 insertions(+), 21 deletions(-)

diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h 
b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
index b28ae583c9..8b8085611f 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
@@ -9,6 +9,8 @@
 #ifndef _SUNXI_DRAM_SUN50I_H6_H
 #define _SUNXI_DRAM_SUN50I_H6_H
 
+#include 
+
 enum sunxi_dram_type {
SUNXI_DRAM_TYPE_DDR3 = 3,
SUNXI_DRAM_TYPE_DDR4,
@@ -16,6 +18,11 @@ enum sunxi_dram_type {
SUNXI_DRAM_TYPE_LPDDR3,
 };
 
+static inline bool sunxi_dram_is_lpddr(int type)
+{
+   return type >= SUNXI_DRAM_TYPE_LPDDR2;
+}
+
 /*
  * The following information is mainly retrieved by disassembly and some FPGA
  * test code of sun50iw3 platform.
diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 697b8af4ce..0436265bdb 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -42,6 +42,7 @@ static void mctl_core_init(struct dram_para *para)
mctl_com_init(para);
switch (para->type) {
case SUNXI_DRAM_TYPE_LPDDR3:
+   case SUNXI_DRAM_TYPE_DDR3:
mctl_set_timing_params(para);
break;
default:
@@ -302,22 +303,37 @@ static void mctl_com_init(struct dram_para *para)
reg_val = 0x3f00;
clrsetbits_le32(_com->unk_0x008, 0x3f00, reg_val);
 
-   /* TODO: half DQ, non-LPDDR3 types */
-   writel(MSTR_DEVICETYPE_LPDDR3 | MSTR_BUSWIDTH_FULL |
-  MSTR_BURST_LENGTH(8) | MSTR_ACTIVE_RANKS(para->ranks) |
-  0x8000, _ctl->mstr);
-   writel(DCR_LPDDR3 | DCR_DDR8BANK | 0x400, _phy->dcr);
+   /* TODO: half DQ, DDR4 */
+   reg_val = MSTR_BUSWIDTH_FULL | MSTR_BURST_LENGTH(8) |
+ MSTR_ACTIVE_RANKS(para->ranks);
+   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
+   reg_val |= MSTR_DEVICETYPE_LPDDR3;
+   if (para->type == SUNXI_DRAM_TYPE_DDR3)
+   reg_val |= MSTR_DEVICETYPE_DDR3 | MSTR_2TMODE;
+   writel(reg_val | BIT(31), _ctl->mstr);
+
+   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
+   reg_val = DCR_LPDDR3 | DCR_DDR8BANK;
+   if (para->type == SUNXI_DRAM_TYPE_DDR3)
+   reg_val = DCR_DDR3 | DCR_DDR8BANK | BIT(28); /* 2T mode */
+   writel(reg_val | 0x400, _phy->dcr);
 
if (para->ranks == 2)
writel(0x0303, _ctl->odtmap);
else
writel(0x0201, _ctl->odtmap);
 
-   /* TODO: non-LPDDR3 types */
-   tmp = para->clk * 7 / 2000;
-   reg_val = 0x0400;
-   reg_val |= (tmp + 7) << 24;
-   reg_val |= (((para->clk < 400) ? 3 : 4) - tmp) << 16;
+   /* TODO: DDR4 */
+   if (para->type == SUNXI_DRAM_TYPE_LPDDR3) {
+   tmp = para->clk * 7 / 2000;
+   reg_val = 0x0400;
+   reg_val |= (tmp + 7) << 24;
+   reg_val |= (((para->clk < 400) ? 3 : 4) - tmp) << 16;
+   } else if (para->type == SUNXI_DRAM_TYPE_DDR3) {
+   reg_val = 0x06000400;   /* TODO?: Use CL - CWL value in [7:0] */
+   } else if (para->type == SUNXI_DRAM_TYPE_DDR4) {
+   panic("DDR4 not yet supported\n");
+   }
writel(reg_val, _ctl->odtcfg);
 
/* TODO: half DQ */
@@ -372,6 +388,9 @@ static void mctl_bit_delay_set(struct dram_para *para)
setbits_le32(_phy->pgcr[0], BIT(26));
udelay(1);
 
+   if (para->type != SUNXI_DRAM_TYPE_LPDDR3)
+   return;
+
for (i = 1; i < 14; i++) {
val = readl(_phy->acbdlr[i]);
val += 0x0a0a0a0a;
@@ -419,7 +438,8 @@ static void mctl_channel_init(struct dram_para *para)
else
clrsetbits_le32(_phy->dtcr[1], 0x3, 0x1);
 
-   clrbits_le32(_phy->dtcr[1], BIT(1));
+   if (sunxi_dram_is_lpddr(para->type))
+   clrbits_le32(_phy->dtcr[1], BIT(1));
if (para->ranks == 2) {
writel(0x00010001, _phy->rankidr);
writel(0x2, _phy->odtcr);
@@ -428,8 +448,11 @@ static void mctl_channel_init(struct dram_para *para)
writel(0x1, _phy->odtcr);
}
 
-   /* TODO: non-LPDDR3 types */
-   clrsetbits_le32(_phy->dtcr[0], 0xF000, 0x1040);
+   /* set bits [3:0] to 1? 0 not valid in ZynqMP d/s */
+   if (para->type == SUNXI_DRAM_TYPE_LPDDR3)
+   

[U-Boot] [PATCH 3/7] sunxi: H6: move LPDDR3 timing definition into separate file

[Andre Przywara]

Currently the H6 DRAM driver only supports one kind of LPDDR3 DRAM.
Split the timing parameters for LPDDR3-1333 into a separate file, to
allow selecting an alternative later at compile time (as the sunxi-dw
driver does).

Signed-off-by: Andre Przywara 
---
 arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h  |  28 
 arch/arm/mach-sunxi/Kconfig   |  10 +-
 arch/arm/mach-sunxi/Makefile  |   1 +
 arch/arm/mach-sunxi/dram_sun50i_h6.c  | 150 +-
 arch/arm/mach-sunxi/dram_timings/Makefile |   1 +
 arch/arm/mach-sunxi/dram_timings/h6_lpddr3_1333.c | 132 +++
 configs/orangepi_one_plus_defconfig   |   1 +
 configs/pine_h64_defconfig|   1 +
 8 files changed, 176 insertions(+), 148 deletions(-)
 create mode 100644 arch/arm/mach-sunxi/dram_timings/h6_lpddr3_1333.c

diff --git a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h 
b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
index eeb4da5c3f..b28ae583c9 100644
--- a/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h
@@ -287,6 +287,32 @@ check_member(sunxi_mctl_phy_reg, dx[3].reserved_0xf0, 
0xaf0);
 #define DCR_DDR4   (4 << 0)
 #define DCR_DDR8BANK   BIT(3)
 
+
+/*
+ * The delay parameters below allow to allegedly specify delay times of some
+ * unknown unit for each individual bit trace in each of the four data bytes
+ * the 32-bit wide access consists of. Also three control signals can be
+ * adjusted individually.
+ */
+#define NR_OF_BYTE_LANES   (32 / BITS_PER_BYTE)
+/* The eight data lines (DQn) plus DM, DQS, DQS/DM/DQ Output Enable and DQSN */
+#define WR_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 4)
+/*
+ * The eight data lines (DQn) plus DM, DQS, DQS/DM/DQ Output Enable, DQSN,
+ * Termination and Power down
+ */
+#define RD_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 6)
+struct dram_para {
+   u32 clk;
+   enum sunxi_dram_type type;
+   u8 cols;
+   u8 rows;
+   u8 ranks;
+   const u8 dx_read_delays[NR_OF_BYTE_LANES][RD_LINES_PER_BYTE_LANE];
+   const u8 dx_write_delays[NR_OF_BYTE_LANES][WR_LINES_PER_BYTE_LANE];
+};
+
+
 static inline int ns_to_t(int nanoseconds)
 {
const unsigned int ctrl_freq = CONFIG_DRAM_CLK / 2;
@@ -294,4 +320,6 @@ static inline int ns_to_t(int nanoseconds)
return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
 }
 
+void mctl_set_timing_params(struct dram_para *para);
+
 #endif /* _SUNXI_DRAM_SUN50I_H6_H */
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 1669e62a6d..e01cb6a09a 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -340,7 +340,7 @@ config ARM_BOOT_HOOK_RMR
This allows both the SPL and the U-Boot proper to be entered in
either mode and switch to AArch64 if needed.
 
-if SUNXI_DRAM_DW
+if SUNXI_DRAM_DW || DRAM_SUN50I_H6
 config SUNXI_DRAM_DDR3
bool
 
@@ -370,6 +370,14 @@ config SUNXI_DRAM_LPDDR3_STOCK
This option is the LPDDR3 timing used by the stock boot0 by
Allwinner.
 
+config SUNXI_DRAM_H6_LPDDR3
+   bool "LPDDR3-1333 on the H6 DRAM controller"
+   select SUNXI_DRAM_LPDDR3
+   depends on DRAM_SUN50I_H6
+   ---help---
+   This option is the LPDDR3 timing used by the stock boot0 by
+   Allwinner.
+
 config SUNXI_DRAM_DDR2_V3S
bool "DDR2 found in V3s chip"
select SUNXI_DRAM_DDR2
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 43a93e3085..d129f33479 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -39,4 +39,5 @@ obj-$(CONFIG_SPL_SPI_SUNXI)   += spl_spi_sunxi.o
 obj-$(CONFIG_SUNXI_DRAM_DW)+= dram_sunxi_dw.o
 obj-$(CONFIG_SUNXI_DRAM_DW)+= dram_timings/
 obj-$(CONFIG_DRAM_SUN50I_H6)   += dram_sun50i_h6.o
+obj-$(CONFIG_DRAM_SUN50I_H6)   += dram_timings/
 endif
diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 7a8b724f08..697b8af4ce 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -32,33 +32,8 @@
  * similar PHY is ZynqMP.
  */
 
-/*
- * The delay parameters below allow to allegedly specify delay times of some
- * unknown unit for each individual bit trace in each of the four data bytes
- * the 32-bit wide access consists of. Also three control signals can be
- * adjusted individually.
- */
-#define NR_OF_BYTE_LANES   (32 / BITS_PER_BYTE)
-/* The eight data lines (DQn) plus DM, DQS, DQS/DM/DQ Output Enable and DQSN */
-#define WR_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 4)
-/*
- * The eight data lines (DQn) plus DM, DQS, DQS/DM/DQ Output Enable, DQSN,
- * Termination and Power down
- */
-#define RD_LINES_PER_BYTE_LANE (BITS_PER_BYTE + 6)
-struct dram_para {
-   u32 clk;
-   enum sunxi_dram_type type;
-   u8 cols;
-   u8 rows;
-   u8 ranks;
-   const u8 

[U-Boot] [PATCH 5/7] sunxi: H6: Add DDR3-1333 timings

[Andre Przywara]

Add a routine to program the timing parameters for DDR3-1333 DRAM chips
connected to the H6 DRAM controller.

The values were gathered from doing back-calculations from a register
dump, trying to match them up with the official JEDEC DDDR3 spec.
If in doubt, the register dump values were taken for now, but the JEDEC
recommendation were added as a comment.

Many thanks to Jernej for contributing fixes!

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/Kconfig |   8 ++
 arch/arm/mach-sunxi/dram_timings/Makefile   |   1 +
 arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c | 144 
 3 files changed, 153 insertions(+)
 create mode 100644 arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c

diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index e01cb6a09a..12fa3ad811 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -378,6 +378,14 @@ config SUNXI_DRAM_H6_LPDDR3
This option is the LPDDR3 timing used by the stock boot0 by
Allwinner.
 
+config SUNXI_DRAM_H6_DDR3_1333
+   bool "DDR3-1333 boot0 timings on the H6 DRAM controller"
+   select SUNXI_DRAM_DDR3
+   depends on DRAM_SUN50I_H6
+   ---help---
+   This option is the DDR3 timing used by the boot0 on H6 TV boxes
+   which use a DDR3-1333 timing.
+
 config SUNXI_DRAM_DDR2_V3S
bool "DDR2 found in V3s chip"
select SUNXI_DRAM_DDR2
diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile 
b/arch/arm/mach-sunxi/dram_timings/Makefile
index c3e74362eb..45f2e5a6b9 100644
--- a/arch/arm/mach-sunxi/dram_timings/Makefile
+++ b/arch/arm/mach-sunxi/dram_timings/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_SUNXI_DRAM_DDR3_1333)  += ddr3_1333.o
 obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK)  += lpddr3_stock.o
 obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)  += ddr2_v3s.o
 obj-$(CONFIG_SUNXI_DRAM_H6_LPDDR3) += h6_lpddr3_1333.o
+obj-$(CONFIG_SUNXI_DRAM_H6_DDR3_1333)  += h6_ddr3_1333.o
diff --git a/arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c 
b/arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c
new file mode 100644
index 00..12de4db310
--- /dev/null
+++ b/arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c
@@ -0,0 +1,144 @@
+/*
+ * sun50i H6 DDR3-1333 timings, as programmed by Allwinner's boot0
+ * for some TV boxes with the H6 and DDR3 memory.
+ *
+ * The chips are probably able to be driven by a faster clock, but boot0
+ * uses a more conservative timing (as usual).
+ *
+ * (C) Copyright 2018,2019 Arm Ltd.
+ *   based on previous work by:
+ *   (C) Copyright 2017  Icenowy Zheng 
+ *
+ * References used:
+ * - JEDEC DDR3 SDRAM standard:JESD79-3F.pdf
+ * - Samsung K4B2G0446D datasheet
+ * - ZynqMP UG1087 register DDRC/PHY documentation
+ *
+ * Many thanks to Jernej Skrabec for contributing some fixes!
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+
+/*
+ * Only the first four are used for DDR3(?)
+ * MR0: BL8, seq. read burst, no test, fast exit (DLL on), no DLL reset,
+ * CAS latency (CL): 11, write recovery (WR): 12
+ * MR1: DLL enabled, output strength RZQ/6, Rtt_norm RZQ/2,
+ * write levelling disabled, TDQS disabled, output buffer enabled
+ * MR2: manual full array self refresh, dynamic ODT off,
+ * CAS write latency (CWL): 8
+ */
+static u32 mr_ddr3[7] = {
+   0x1c70, 0x0040, 0x0018, 0x,
+   0x, 0x0400, 0x0848,
+};
+
+/* TODO: flexible timing */
+void mctl_set_timing_params(struct dram_para *para)
+{
+   struct sunxi_mctl_ctl_reg * const mctl_ctl =
+   (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
+   struct sunxi_mctl_phy_reg * const mctl_phy =
+   (struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
+   int i;
+
+   u8 tccd = 2;/* JEDEC: 4nCK */
+   u8 tfaw = ns_to_t(50);  /* JEDEC: 40 ns */
+   u8 trrd = max(ns_to_t(10), 2);  /* JEDEC: max(7.5 ns, 4nCK) */
+   u8 trcd = ns_to_t(15);  /* JEDEC: 13.75 ns */
+   u8 trc  = ns_to_t(53);  /* JEDEC: 48.75 ns */
+   u8 txp  = max(ns_to_t(8), 2);   /* JEDEC: max(6 ns, 3nCK) */
+   u8 twtr = max(ns_to_t(8), 2);   /* JEDEC: max(7.5 ns, 4nCK) */
+   u8 trtp = max(ns_to_t(8), 2);   /* JEDEC: max(7.5 ns, 4nCK) */
+   u8 twr  = max(ns_to_t(15), 2);  /* ? */
+   u8 trp  = ns_to_t(15);  /* JEDEC: >= 13.75 ns */
+   u8 tras = ns_to_t(38);  /* JEDEC >= 35 ns, <= 9*trefi */
+   u8 twtr_sa  = 2;/* ? */
+   u8 tcksrea  = 4;/* ? */
+   u16 trefi   = ns_to_t(7800) / 32;   /* JEDEC: 7.8us@Tcase <= 85C */
+   u16 trfc= ns_to_t(350); /* JEDEC: 160 ns for 2Gb */
+   u16 txsr= 4;/* ? */
+
+   u8 tmrw = 0;/* ? */
+   

[U-Boot] [PATCH 6/7] sunxi: H6: Add DDR3 DRAM delay values

[Andre Przywara]

From: Jernej Skrabec 

Add some basic line delay values to be used with DDR3 DRAM chips on
some H6 TV boxes.
Taken from a register dump after boot0 initialised the DRAM.
Put them as the default delay values for DDR3 DRAM until we know better.

Signed-off-by: Jernej Skrabec 
Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 0436265bdb..5fe53bf463 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -597,17 +597,28 @@ unsigned long mctl_calc_size(struct dram_para *para)
return (1ULL << (para->cols + para->rows + 3)) * 4 * para->ranks;
 }
 
-#define SUN50I_H6_DX_WRITE_DELAYS  \
+#define SUN50I_H6_LPDDR3_DX_WRITE_DELAYS   \
{{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
 {  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
 {  0,  0,  0,  0,  0,  0,  0,  0,  0,  4,  4,  0 },\
 {  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 }}
-#define SUN50I_H6_DX_READ_DELAYS   \
+#define SUN50I_H6_LPDDR3_DX_READ_DELAYS
\
{{  4,  4,  4,  4,  4,  4,  4,  4,  4,  0,  0,  0,  0,  0 },\
 {  4,  4,  4,  4,  4,  4,  4,  4,  4,  0,  0,  0,  0,  0 },\
 {  4,  4,  4,  4,  4,  4,  4,  4,  4,  0,  0,  0,  0,  0 },\
 {  4,  4,  4,  4,  4,  4,  4,  4,  4,  0,  0,  0,  0,  0 }}
 
+#define SUN50I_H6_DDR3_DX_WRITE_DELAYS \
+   {{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
+{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
+{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
+{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 }}
+#define SUN50I_H6_DDR3_DX_READ_DELAYS  \
+   {{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
+{  4,  4,  4,  4,  4,  4,  4,  4,  4,  0,  0,  0,  0,  0 },\
+{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 },\
+{  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 }}
+
 unsigned long sunxi_dram_init(void)
 {
struct sunxi_mctl_com_reg * const mctl_com =
@@ -619,12 +630,12 @@ unsigned long sunxi_dram_init(void)
.rows = 14,
 #ifdef CONFIG_SUNXI_DRAM_H6_LPDDR3
.type = SUNXI_DRAM_TYPE_LPDDR3,
-   .dx_read_delays  = SUN50I_H6_DX_READ_DELAYS,
-   .dx_write_delays = SUN50I_H6_DX_WRITE_DELAYS,
+   .dx_read_delays  = SUN50I_H6_LPDDR3_DX_READ_DELAYS,
+   .dx_write_delays = SUN50I_H6_LPDDR3_DX_WRITE_DELAYS,
 #elif defined(CONFIG_SUNXI_DRAM_H6_DDR3_1333)
.type = SUNXI_DRAM_TYPE_DDR3,
-   .dx_read_delays  = SUN50I_H6_DX_READ_DELAYS,
-   .dx_write_delays = SUN50I_H6_DX_WRITE_DELAYS,
+   .dx_read_delays  = SUN50I_H6_DDR3_DX_READ_DELAYS,
+   .dx_write_delays = SUN50I_H6_DDR3_DX_WRITE_DELAYS,
 #endif
};
 
-- 
2.14.5

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

[U-Boot] [PATCH 7/7] sunxi: H6: Add basic Eachlink H6 Mini support

[Andre Przywara]

The Eachlink H6 Mini is a modestly priced TV box, using the Allwinner H6
SoC. It comes with 4GB of DRAM (3GB usable) and 32GB of eMMC in the
typical TV box enclosure.
This adds a basic device tree and defconfig for it.

It contrast to the other supported H6 boards the H6 Mini uses DDR3 DRAM
chips (not LPDDR3), which require a different DRAM controller setup.

Signed-off-by: Andre Przywara 
---
 arch/arm/dts/Makefile   |   1 +
 arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts | 116 
 configs/eachlink_h6_mini_defconfig  |  17 
 3 files changed, 134 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts
 create mode 100644 configs/eachlink_h6_mini_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 528fb909d5..c463aca190 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -507,6 +507,7 @@ dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-orangepi-zero-plus2.dtb
 dtb-$(CONFIG_MACH_SUN50I_H6) += \
sun50i-h6-beelink-gs1.dtb \
+   sun50i-h6-eachlink-h6-mini.dtb \
sun50i-h6-orangepi-lite2.dtb \
sun50i-h6-orangepi-one-plus.dtb \
sun50i-h6-pine-h64.dtb
diff --git a/arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts 
b/arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts
new file mode 100644
index 00..5956b5ccd7
--- /dev/null
+++ b/arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Copyright (c) 2018 Arm Ltd.
+ * based on work by:
+ *   Copyright (c) 2017 Icenowy Zheng 
+ */
+
+/dts-v1/;
+
+#include "sun50i-h6.dtsi"
+
+#include 
+
+/ {
+   model = "Eachlink H6 Mini";
+   compatible = "eachlink,h6-mini", "allwinner,sun50i-h6";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
+   reg_vcc5v: vcc5v {
+   /* supply from the micro-USB DC jack */
+   compatible = "regulator-fixed";
+   regulator-name = "vcc-5v";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   regulator-always-on;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
+ {
+   phys = < 0>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
+   bus-width = <4>;
+   status = "okay";
+};
+
+ {
+   vmmc-supply = <_vcc3v3>;
+   vqmmc-supply = <_vcc3v3>;
+   non-removable;
+   cap-mmc-hw-reset;
+   bus-width = <8>;
+   status = "okay";
+};
+
+ {
+   phys = < 0>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ph_pins>;
+   status = "okay";
+};
+
+ {
+   dr_mode = "host";
+   status = "okay";
+};
+
+ {
+   usb0_vbus-supply = <_vcc5v>;
+   status = "okay";
+};
diff --git a/configs/eachlink_h6_mini_defconfig 
b/configs/eachlink_h6_mini_defconfig
new file mode 100644
index 00..d471a24dd5
--- /dev/null
+++ b/configs/eachlink_h6_mini_defconfig
@@ -0,0 +1,17 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_SPL=y
+CONFIG_MACH_SUN50I_H6=y
+CONFIG_DRAM_CLK=660
+CONFIG_DRAM_ZQ=3881979
+CONFIG_SUNXI_DRAM_H6_DDR3_1333=y
+CONFIG_MMC0_CD_PIN="PF6"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=2
+# CONFIG_PSCI_RESET is not set
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_TEXT_BASE=0x20060
+# CONFIG_CMD_FLASH is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+# CONFIG_SPL_EFI_PARTITION is not set
+CONFIG_DEFAULT_DEVICE_TREE="sun50i-h6-eachlink-h6-mini"
-- 
2.14.5

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

[U-Boot] [PATCH 1/7] sunxi: H6: DRAM: avoid memcpy() on MMIO registers

[Andre Przywara]

Using memcpy() is, however tempting, not a good idea: It depends on the
specific implementation of memcpy, also lacks barriers. In this
particular case the first registers were written using 64-bit writes,
and the last register using four separate single-byte writes.

Replace the memcpy with a proper loop using the writel() accessor.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index 5da90a2835..e2f141eb9b 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -182,6 +182,7 @@ static void mctl_set_timing_lpddr3(struct dram_para *para)
(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
struct sunxi_mctl_phy_reg * const mctl_phy =
(struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
+   int i;
 
u8 tccd = 2;
u8 tfaw = max(ns_to_t(50), 4);
@@ -237,8 +238,9 @@ static void mctl_set_timing_lpddr3(struct dram_para *para)
u8 twr2rd   = tcwl + 4 + 1 + twtr;
u8 trd2wr   = tcl + 4 + (tcksrea >> 1) - tcwl + 1;
 
-   /* set mode register */
-   memcpy(mctl_phy->mr, mr_lpddr3, sizeof(mr_lpddr3));
+   /* set mode registers */
+   for (i = 0; i < ARRAY_SIZE(mr_lpddr3); i++)
+   writel(mr_lpddr3[i], _phy->mr[i]);
 
/* set DRAM timing */
writel((twtp << 24) | (tfaw << 16) | (trasmax << 8) | tras,
-- 
2.14.5

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

[U-Boot] [PATCH 2/7] sunxi: H6: DRAM: follow recommended PHY init algorithm

[Andre Przywara]

The DRAM controller manual suggests to first program the PHY
initialisation parameters to the PHY_PIR register, and then set bit 0 to
trigger the initialisation. This is also used in boot0.

Follow this recommendation by setting bit 0 in a separate step.

Signed-off-by: Andre Przywara 
---
 arch/arm/mach-sunxi/dram_sun50i_h6.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-sunxi/dram_sun50i_h6.c 
b/arch/arm/mach-sunxi/dram_sun50i_h6.c
index e2f141eb9b..7a8b724f08 100644
--- a/arch/arm/mach-sunxi/dram_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/dram_sun50i_h6.c
@@ -75,12 +75,14 @@ static void mctl_core_init(struct dram_para *para)
mctl_channel_init(para);
 }
 
+/* PHY initialisation */
 static void mctl_phy_pir_init(u32 val)
 {
struct sunxi_mctl_phy_reg * const mctl_phy =
(struct sunxi_mctl_phy_reg *)SUNXI_DRAM_PHY0_BASE;
 
-   writel(val | BIT(0), _phy->pir);
+   writel(val, _phy->pir);
+   writel(val | BIT(0), _phy->pir);   /* Start initialisation. */
mctl_await_completion(_phy->pgsr[0], BIT(0), BIT(0));
 }
 
-- 
2.14.5

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

[U-Boot] [PATCH 0/7] sunxi: Add H6 DDR3 DRAM support

[Andre Przywara]

So far the SPL DRAM driver for the Allwinner H6 SoC only supports
LPDDR3 DRAM chips, which are used on most single board computers with
this SoC.
There are some TV boxes with the H6 out now, but most of them are
using DDR3 DRAM instead of LPDDR3.

This series extends the existing H6 DRAM driver to cover DDR3 DRAMs
as well. The information used in these patches is from:
- register dumps after Allwinner's boot0 (libdram) has initialised
  the DRAM
- some disassembly of the libdram library
- timing parameters as found in the boot0 binary
- comparison with Xilinx ZynqMP DRAM controller documentation

The box I played with (Eachlink H6 Mini) has 3GB of DDR3-1600 chips and
runs at 840 MHz, however I couldn't get it to work with these parameters.
Instead Jernej suggested to use a lower clock and adjust some timing
parameters, which made it work for me as well.

Many thanks to Jernej Skrabec for his help, also to others who helped
with testing and experiments.

The first two patches contain some fixes for the existing driver.
Patch 3 moves the existing LPDDR3 timing parameters into a separate file,
patch 5 introduces the respective DDR3 timings, patch 6 adds some
generic delay lines values.
Patch 4 enhances the DRAM controller driver to program DDR3 specific
registers as well and use different settings on other registers.
The final patch introduces support for the Eachlink H6 Mini TV box, with
the usual device tree and defconfig file.

Please have a look and comment!

Cheers,
Andre.

Andre Przywara (6):
  sunxi: H6: DRAM: avoid memcpy() on MMIO registers
  sunxi: H6: DRAM: follow recommended PHY init algorithm
  sunxi: H6: move LPDDR3 timing definition into separate file
  sunxi: H6: Add DDR3 support to DRAM controller driver
  sunxi: H6: Add DDR3-1333 timings
  sunxi: H6: Add basic Eachlink H6 Mini support

Jernej Skrabec (1):
  sunxi: H6: Add DDR3 DRAM delay values

 arch/arm/dts/Makefile |   1 +
 arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts   | 116 +++
 arch/arm/include/asm/arch-sunxi/dram_sun50i_h6.h  |  35 
 arch/arm/mach-sunxi/Kconfig   |  18 +-
 arch/arm/mach-sunxi/Makefile  |   1 +
 arch/arm/mach-sunxi/dram_sun50i_h6.c  | 240 +++---
 arch/arm/mach-sunxi/dram_timings/Makefile |   2 +
 arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c   | 144 +
 arch/arm/mach-sunxi/dram_timings/h6_lpddr3_1333.c | 132 
 configs/eachlink_h6_mini_defconfig|  17 ++
 configs/orangepi_one_plus_defconfig   |   1 +
 configs/pine_h64_defconfig|   1 +
 12 files changed, 537 insertions(+), 171 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h6-eachlink-h6-mini.dts
 create mode 100644 arch/arm/mach-sunxi/dram_timings/h6_ddr3_1333.c
 create mode 100644 arch/arm/mach-sunxi/dram_timings/h6_lpddr3_1333.c
 create mode 100644 configs/eachlink_h6_mini_defconfig

-- 
2.14.5

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

Re: [U-Boot] [linux-sunxi] Re: [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[André Przywara]

On 18/06/2019 18:17, Jernej Škrabec wrote:
> Dne torek, 18. junij 2019 ob 19:13:16 CEST je Clément Péron napisal(a):

Hi,

>> On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
>>> The first USB controller on the H6 SoC shares a PHY with the OTG
>>> controller. Reportedly to avoid problems with the VBUS regulator under
>>> Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
>>>
>>> However on boards which can't use peripheral mode (because they have an
>>> always-on VBUS supply on an USB-A socket) we don't need this trick, and
>>> can properly connect host controller 0 to the PHY 0.
>>>
>>> Amend the Pine H64 .dts to reflect this. This enables the upper USB port
>>> in U-Boot on this board.
>>>
>>> Signed-off-by: Andre Przywara 
>>> ---
>>>
>>>  arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
>>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts
>>> b/arch/arm/dts/sun50i-h6-pine-h64.dts index 4802902e12..aad7646b18 100644
>>> --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
>>> +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
>>> @@ -96,6 +96,8 @@
>>>
>>>  };
>>>  
>>>   {
>>>
>>> +   phys = < 0>;
>>> +   phy-names = "usb";
>>>
>>> status = "okay";
>>>  
>>>  };
>>>
>>> @@ -120,6 +122,8 @@
>>>
>>>  };
>>>  
>>>   {
>>>
>>> +   phys = < 0>;
>>> +   phy-names = "usb";
>>>
>>> status = "okay";
>>>  
>>>  };
>>>
>>> @@ -255,7 +259,6 @@
>>>
>>>   {
>>>  
>>> dr_mode = "host";
>>>
>>> -   status = "okay";
>>>
>>>  };
>>
>> Maybe you should add explicit comments in the device-tree to avoid
>> losing this at next sync with linux dt.
> 
> If DT change is U-Boot specific, it should be moved to *-u-boot.dtsi file, 
> although I'm not sure if you can delete properties in such way.

I never planned to deviate from Linux, just wanted to provide something
that works, for now. This change should go into Linux as well, of
course. Will push this there ASAP.

Cheers,
Andre.

> 
> Best regards,
> Jernej
> 
>>
>> Regards,
>> Clement
>>
>>>   {
>>>
>>> --
>>> 2.14.5
> 
> 
> 
> 

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

Re: [U-Boot] [linux-sunxi] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support

[André Przywara]

On Tue, 18 Jun 2019 19:22:34 +0200
Clément Péron  wrote:

Hi,


> On Tue, 18 Jun 2019 at 19:08, Clément Péron  wrote:
> >
> > Hi Andre,
> >
> > On Tue, 18 Jun 2019 at 09:50, Jagan Teki  
> > wrote:  
> > >
> > > On Thu, May 16, 2019 at 6:56 AM Andre Przywara  
> > > wrote:  
> > > >
> > > > Hi,
> > > >
> > > > this series enables USB support on the H6 boards. This is mostly just
> > > > adding some missing pieces here and there, the actual controller and PHY
> > > > are very similar to the previous ones, if not identical.
> > > > This is for the 2.0 ports only at the moment, USB 3.0 will be done
> > > > later (started porting Icenowy's Linux driver).
> > > > The Pine H64 shares a similar problem as the Pine64+ boards regarding
> > > > the upper USB port. To enable this port, we need the first patch
> > > > from the series [1] fixing this issue on the A64 boards.
> > > >
> > > > Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was
> > > > lingering in one of my branches for a while.
> > > > Patch 2 enables GPIO support for the H6, as this is needed for the Pine
> > > > H64 to enable the VBUS regulator.
> > > > Patch 3 adds the clock and reset gates mappings for the USB controller 
> > > > and
> > > > the PHY, the values are taken from the manual and verified against
> > > > Linux.
> > > > Patch 4 adds some code to the PHY driver to skip over not implemented
> > > > PHYs, as the H6 uses a PHY0/PHY3 combination in the DT.
> > > > Patch 5 then eventually enables USB in the existing defconfigs.
> > > > Patch 6 adds the .dts fixes required to get the upper USB port to work
> > > > on the Pine H64.
> > > >
> > > > Clément, can you please verify that this works for the Beelink box?  
> > Thank you for the notice.
> >
> > Works fine on my board:  
> I have tested with and without the trick in usb2otg node and both seems 
> working.
> (only tested usb start; usb tree).

You mean dropping the status="okay"?

Yeah, I figured as well that it works both ways. Actually older kernels
require the MUSB driver to be enabled, while newer kernels don't seem to
care. As this affects the Debian Buster kernel (4.19, in the installer),
I plan on just leaving it as it is right now.

> Why not leave it to avoid a difference with linux?

Technically we should disable it, as it's not usable and might clash
with EHCI0/OHCI0, but for said reason I just keep it.

Thanks for having a look!

Cheers,
Andre.

> > U-Boot 2019.07-rc4 (Jun 18 2019 - 19:06:21 +0200) Allwinner Technology
> >
> > CPU:   Allwinner H6 (SUN50I)
> > Model: Beelink GS1
> > DRAM:  2 GiB
> > MMC:   mmc@402: 0, mmc@4022000: 1
> > Loading Environment from FAT... Unable to use mmc 1:1... In:
> > serial@500
> > Out:   serial@500
> > Err:   serial@500
> > Net:   No ethernet found.
> > starting USB...
> > Bus usb@5101000: USB EHCI 1.00
> > Bus usb@5101400: USB OHCI 1.0
> > scanning bus usb@5101000 for devices... 1 USB Device(s) found
> >
> > Regards,
> > Clément
> >  
> > > > I guess the USB 2.0 port is probably the OTG one, so this setup would
> > > > look somewhat similar to the PineH64, which would allow you to copy
> > > > the USB DT nodes from there.
> > > >
> > > > Cheers,
> > > > Andre.
> > > >
> > > > [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html
> > > >
> > > > Andre Przywara (6):
> > > >   sunxi: move SUNXI_GPIO to Kconfig
> > > >   sunxi: gpio: Enable support for H6 pin controller
> > > >   sunxi: clocks: Add H6 USB clock gates and resets
> > > >   sunxi: phy: Add USB PHY support for Allwinner H6
> > > >   sunxi: H6: Enable USB for existing boards
> > > >   sunxi: Pine64: DTS: enable USB PHY 0 for HCI0  
> > >
> > > Except 6/6 (it can be part of DTS sync during MW) and rest
> > >
> > > Reviewed-by: Jagan Teki   

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

Re: [U-Boot] [BUG] fs: fat: error when handling long file names

[AKASHI, Takahiro]

Heinrich,

On Tue, Jun 18, 2019 at 09:00:56PM +0200, Heinrich Schuchardt wrote:
> Hello Takahiro
> 
> I hope you have an idea what might be missing in the FAT file system
> support for long names.
> 
> When running the SCT I saw this error for the GetInfo functional test:
> 
> GetInfo() Basic Test - checkpoint3 -- PASS
> 
> E4F4F6A2-7538-4C79-AA3C-67184EC70E16
> 
> /home/supven01/work/sct_workspace/edk2/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleFileSystem/BlackBoxTest/SimpleFileSystemBBTestFunction.c:8607:
> SystemInfo->Size - 18, BufferSize - 18, Tpl - 8
> 
> 
> EFI: Entry efi_file_open(7ef8c250, 7edeb0c0,
> "BBTestGetInfoBasicTestCheckpoint3_File_0", 8003, 0)
> Error: allocating new dir entry
> 
> EFI: Exit: efi_file_open: 14
> 
> EFI: Entry efi_file_open(7ef8c250, 7edeb0c8,
> "BBTestGetInfoBasicTestCheckpoint3_File_1", 8003, 0)
> Error: allocating new dir entry
> 
> In the EFI shell output to a file with a long name sometimes fails
> (depending on the history of the volume).
> 
> FS0:\> echo a > foo
> FS0:\> echo a > abcdefgh.ijk
> FS0:\> echo a > abcdefgh.ijkl
> ** Unable to write file /abcdefgh.ijkl **
> FS0:\>

If this happens again, can you send me the binary of the file system?
Probably the first 1MB will be enough if you don't have lots of
files/directories on it.
This will help me analyze the volume's header.

> Up to now the SCT test is the only thing that fails reproducibly.

SCT will create bunch of files and the logs can be quite big.
It's kinda stress test.

-Takahiro Akashi

> I use this repo for building:
> https://github.com/xypron/u-boot-build/tree/qemu-arm64
> 
> make sct-prepare
> make sct
> 
> Best regards
> 
> Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 6/6] ARM: dm: spi: Add support DM/DTS for i.MX28 mxs SPI driver (DM_SPI conversion)

[Marek Vasut]

On 6/19/19 12:01 AM, Lukasz Majewski wrote:
> This patch converts mxs_spi driver to support DM/DTS.
> 
> Signed-off-by: Lukasz Majewski 

Tags should be "spi: mxs:" .

btw can you drop the non-DM part of the driver altogether ?

The rest of the patchset is much better, thanks.

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

Re: [U-Boot] [PATCH v4 4/6] ARM: dm: mxs: gpio: Add support for DM/DTS in the mxs_gpio.c driver (DM_GPIO)

[Marek Vasut]

On 6/19/19 12:01 AM, Lukasz Majewski wrote:
> This patch adds support for DM/DTS in the mxs_gpio.c driver.
> Information regarding per gpio controller pin number is passed via DTS.
> 
> Signed-off-by: Lukasz Majewski 
> 
> ---

Here the tags should be "gpio: mxs:" .

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

Re: [U-Boot] [PATCH v4 5/6] ARM: imx: pinctrl: Add support for i.MX2[38] mxs pinctrl driver

[Marek Vasut]

On 6/19/19 12:01 AM, Lukasz Majewski wrote:
> The code responsible for setting proper values in the MUX registers
> (in the mxs_pinctrl_set_state()) has been ported from Linux kernel
> - SHA1: 17bb763e7eaf tag v5.1.11 from linux-stable.

Maybe you want to keep the DTs and this driver based off the same
version of Linux kernel.

Tags are "pinctrl: mxs: ".

> As the pinctrl node in the imx28.dtsi file has gpio pins nodes as subnodes,
> it was necessary to use 'dm_scan_fdt_dev()' (as a .bind method) to also
> make them 'visible' by the DM's "gpio_mxs" driver.
> 
> Signed-off-by: Lukasz Majewski 
> 

[...]

> +static void mxs_pinctrl_rmwl(u32 value, u32 mask, u8 shift, void __iomem 
> *reg)
> +{
> + u32 tmp;

This is clrsetbits_le32() reimplementation.

> + tmp = readl(reg);
> + tmp &= ~(mask << shift);
> + tmp |= value << shift;
> + writel(tmp, reg);
> +}
[...

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

Re: [U-Boot] [PATCH v4 2/6] ARM: imx: net: Enable support for i.MX28 DM_ETH in the fec_mxc.c driver

[Marek Vasut]

On 6/19/19 12:01 AM, Lukasz Majewski wrote:
> The fec_mxc.c driver can be reused by i.MX28 when DM_ETH is enabled.
> One only needs to add proper compatible and dependency on FEC_MXC in the
> Kconfig.
> 
> Signed-off-by: Lukasz Majewski 
Tags should be "net: fec:" , see git log --oneline drivers/net/fec .
Driver additions should always use "subsystem: driver:" tag, when in
doubt, check git log.

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

Re: [U-Boot] [PATCH v4 3/6] DTS: dm: mxs: gpio: Provide 'gpio-ranges' for mxs_gpio driver

[Marek Vasut]

On 6/19/19 12:01 AM, Lukasz Majewski wrote:
> Those properties are U-Boot specific as the mxs gpio Linux driver (up to
> version v5.1.11) is not supporting them.
> 
> Signed-off-by: Lukasz Majewski 

Tags should be "ARM: dts: imx:" , just like 1/6 .

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

[U-Boot] [PATCH v4 6/6] ARM: dm: spi: Add support DM/DTS for i.MX28 mxs SPI driver (DM_SPI conversion)

[Lukasz Majewski]

This patch converts mxs_spi driver to support DM/DTS.

Signed-off-by: Lukasz Majewski 

---

Changes in v4:
- Adjust the driver to support i.MX23 (add compatible, adjust clk code)
- Use BIT() macro where applicable

Changes in v3:
- Set more appropriate tags

Changes in v2:
- New patch (conversion of mxs_spi.c to DM_SPI)

 drivers/spi/mxs_spi.c | 400 +++---
 1 file changed, 317 insertions(+), 83 deletions(-)

diff --git a/drivers/spi/mxs_spi.c b/drivers/spi/mxs_spi.c
index 5065e407f8..3a9756fbf1 100644
--- a/drivers/spi/mxs_spi.c
+++ b/drivers/spi/mxs_spi.c
@@ -2,6 +2,9 @@
 /*
  * Freescale i.MX28 SPI driver
  *
+ * Copyright (C) 2019 DENX Software Engineering
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
  * Copyright (C) 2011 Marek Vasut 
  * on behalf of DENX Software Engineering GmbH
  *
@@ -27,6 +30,19 @@
 
 #define MXSSSP_SMALL_TRANSFER  512
 
+static void mxs_spi_start_xfer(struct mxs_ssp_regs *ssp_regs)
+{
+   writel(SSP_CTRL0_LOCK_CS, _regs->hw_ssp_ctrl0_set);
+   writel(SSP_CTRL0_IGNORE_CRC, _regs->hw_ssp_ctrl0_clr);
+}
+
+static void mxs_spi_end_xfer(struct mxs_ssp_regs *ssp_regs)
+{
+   writel(SSP_CTRL0_LOCK_CS, _regs->hw_ssp_ctrl0_clr);
+   writel(SSP_CTRL0_IGNORE_CRC, _regs->hw_ssp_ctrl0_set);
+}
+
+#if !CONFIG_IS_ENABLED(DM_SPI)
 struct mxs_spi_slave {
struct spi_slaveslave;
uint32_tmax_khz;
@@ -38,94 +54,38 @@ static inline struct mxs_spi_slave *to_mxs_slave(struct 
spi_slave *slave)
 {
return container_of(slave, struct mxs_spi_slave, slave);
 }
+#else
+#include 
+#include 
+struct mxs_spi_platdata {
+   s32 frequency;  /* Default clock frequency, -1 for none */
+   fdt_addr_t base;/* SPI IP block base address */
+   int num_cs; /* Number of CSes supported */
+   int dma_id; /* ID of the DMA channel */
+   int clk_id; /* ID of the SSP clock */
+};
 
-int spi_cs_is_valid(unsigned int bus, unsigned int cs)
-{
-   /* MXS SPI: 4 ports and 3 chip selects maximum */
-   if (!mxs_ssp_bus_id_valid(bus) || cs > 2)
-   return 0;
-   else
-   return 1;
-}
-
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
-{
-   struct mxs_spi_slave *mxs_slave;
-
-   if (!spi_cs_is_valid(bus, cs)) {
-   printf("mxs_spi: invalid bus %d / chip select %d\n", bus, cs);
-   return NULL;
-   }
-
-   mxs_slave = spi_alloc_slave(struct mxs_spi_slave, bus, cs);
-   if (!mxs_slave)
-   return NULL;
-
-   if (mxs_dma_init_channel(MXS_DMA_CHANNEL_AHB_APBH_SSP0 + bus))
-   goto err_init;
-
-   mxs_slave->max_khz = max_hz / 1000;
-   mxs_slave->mode = mode;
-   mxs_slave->regs = mxs_ssp_regs_by_bus(bus);
-
-   return _slave->slave;
-
-err_init:
-   free(mxs_slave);
-   return NULL;
-}
-
-void spi_free_slave(struct spi_slave *slave)
-{
-   struct mxs_spi_slave *mxs_slave = to_mxs_slave(slave);
-   free(mxs_slave);
-}
-
-int spi_claim_bus(struct spi_slave *slave)
-{
-   struct mxs_spi_slave *mxs_slave = to_mxs_slave(slave);
-   struct mxs_ssp_regs *ssp_regs = mxs_slave->regs;
-   uint32_t reg = 0;
-
-   mxs_reset_block(_regs->hw_ssp_ctrl0_reg);
-
-   writel((slave->cs << MXS_SSP_CHIPSELECT_SHIFT) |
-  SSP_CTRL0_BUS_WIDTH_ONE_BIT,
-  _regs->hw_ssp_ctrl0);
-
-   reg = SSP_CTRL1_SSP_MODE_SPI | SSP_CTRL1_WORD_LENGTH_EIGHT_BITS;
-   reg |= (mxs_slave->mode & SPI_CPOL) ? SSP_CTRL1_POLARITY : 0;
-   reg |= (mxs_slave->mode & SPI_CPHA) ? SSP_CTRL1_PHASE : 0;
-   writel(reg, _regs->hw_ssp_ctrl1);
-
-   writel(0, _regs->hw_ssp_cmd0);
-
-   mxs_set_ssp_busclock(slave->bus, mxs_slave->max_khz);
-
-   return 0;
-}
-
-void spi_release_bus(struct spi_slave *slave)
-{
-}
-
-static void mxs_spi_start_xfer(struct mxs_ssp_regs *ssp_regs)
-{
-   writel(SSP_CTRL0_LOCK_CS, _regs->hw_ssp_ctrl0_set);
-   writel(SSP_CTRL0_IGNORE_CRC, _regs->hw_ssp_ctrl0_clr);
-}
-
-static void mxs_spi_end_xfer(struct mxs_ssp_regs *ssp_regs)
-{
-   writel(SSP_CTRL0_LOCK_CS, _regs->hw_ssp_ctrl0_clr);
-   writel(SSP_CTRL0_IGNORE_CRC, _regs->hw_ssp_ctrl0_set);
-}
+struct mxs_spi_priv {
+   struct mxs_ssp_regs *regs;
+   unsigned int dma_channel;
+   unsigned int max_freq;
+   unsigned int clk_id;
+   unsigned int mode;
+};
+#endif
 
+#if !CONFIG_IS_ENABLED(DM_SPI)
 static int mxs_spi_xfer_pio(struct mxs_spi_slave *slave,
char *data, int length, int write, unsigned long flags)
 {
struct mxs_ssp_regs *ssp_regs = slave->regs;
+#else
+static int mxs_spi_xfer_pio(struct mxs_spi_priv *priv,
+   char *data, int length, int write,
+   unsigned long flags)
+{
+   struct 

[U-Boot] [PATCH v4 4/6] ARM: dm: mxs: gpio: Add support for DM/DTS in the mxs_gpio.c driver (DM_GPIO)

[Lukasz Majewski]

This patch adds support for DM/DTS in the mxs_gpio.c driver.
Information regarding per gpio controller pin number is passed via DTS.

Signed-off-by: Lukasz Majewski 

---

Changes in v4:
- Use BIT() macro instead of 1 << offset
- Use devfdt_get_addr to get gpio number
- Use gpio-ranges property to setup gpios

Changes in v3:
- Set more apropriate tags

Changes in v2:
- Use #if !CONFIG_IS_ENABLED(DM_GPIO) instead of plain #ifdef CONFIG_DM_GPIO

 drivers/gpio/mxs_gpio.c | 148 
 1 file changed, 148 insertions(+)

diff --git a/drivers/gpio/mxs_gpio.c b/drivers/gpio/mxs_gpio.c
index c2c8a25886..b2451fdda8 100644
--- a/drivers/gpio/mxs_gpio.c
+++ b/drivers/gpio/mxs_gpio.c
@@ -51,6 +51,7 @@ void mxs_gpio_init(void)
}
 }
 
+#if !CONFIG_IS_ENABLED(DM_GPIO)
 int gpio_get_value(unsigned gpio)
 {
uint32_t bank = PAD_BANK(gpio);
@@ -127,3 +128,150 @@ int name_to_gpio(const char *name)
 
return (bank << MXS_PAD_BANK_SHIFT) | (pin << MXS_PAD_PIN_SHIFT);
 }
+#else /* CONFIG_DM_GPIO */
+#include 
+#include 
+#include 
+#define MXS_MAX_GPIO_PER_BANK  32
+
+DECLARE_GLOBAL_DATA_PTR;
+/*
+ * According to i.MX28 Reference Manual:
+ * 'i.MX28 Applications Processor Reference Manual, Rev. 1, 2010'
+ * The i.MX28 has following number of GPIOs available:
+ * Bank 0: 0-28 -> 29 PINS
+ * Bank 1: 0-31 -> 32 PINS
+ * Bank 2: 0-27 -> 28 PINS
+ * Bank 3: 0-30 -> 31 PINS
+ * Bank 4: 0-20 -> 21 PINS
+ */
+
+struct mxs_gpio_priv {
+   unsigned int bank;
+};
+
+static int mxs_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)(MXS_PINCTRL_BASE +
+  PINCTRL_DIN(priv->bank));
+
+   return (readl(>reg) >> offset) & 1;
+}
+
+static int mxs_gpio_set_value(struct udevice *dev, unsigned offset,
+ int value)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)(MXS_PINCTRL_BASE +
+  PINCTRL_DOUT(priv->bank));
+   if (value)
+   writel(BIT(offset), >reg_set);
+   else
+   writel(BIT(offset), >reg_clr);
+
+   return 0;
+}
+
+static int mxs_gpio_direction_input(struct udevice *dev, unsigned offset)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)(MXS_PINCTRL_BASE +
+  PINCTRL_DOE(priv->bank));
+
+   writel(BIT(offset), >reg_clr);
+
+   return 0;
+}
+
+static int mxs_gpio_direction_output(struct udevice *dev, unsigned offset,
+int value)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)(MXS_PINCTRL_BASE +
+  PINCTRL_DOE(priv->bank));
+
+   mxs_gpio_set_value(dev, offset, value);
+
+   writel(BIT(offset), >reg_set);
+
+   return 0;
+}
+
+static int mxs_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct mxs_register_32 *reg =
+   (struct mxs_register_32 *)(MXS_PINCTRL_BASE +
+  PINCTRL_DOE(priv->bank));
+   bool is_output = !!(readl(>reg) >> offset);
+
+   return is_output ? GPIOF_OUTPUT : GPIOF_INPUT;
+}
+
+static const struct dm_gpio_ops gpio_mxs_ops = {
+   .direction_input= mxs_gpio_direction_input,
+   .direction_output   = mxs_gpio_direction_output,
+   .get_value  = mxs_gpio_get_value,
+   .set_value  = mxs_gpio_set_value,
+   .get_function   = mxs_gpio_get_function,
+};
+
+static int mxs_gpio_probe(struct udevice *dev)
+{
+   struct mxs_gpio_priv *priv = dev_get_priv(dev);
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   struct fdtdec_phandle_args args;
+   int node = dev_of_offset(dev);
+   char name[16], *str;
+   fdt_addr_t addr;
+   int ret;
+
+   addr = devfdt_get_addr(dev);
+   if (addr == FDT_ADDR_T_NONE) {
+   printf("%s: No 'reg' property defined!\n", __func__);
+   return -EINVAL;
+   }
+
+   priv->bank = (unsigned int)addr;
+
+   snprintf(name, sizeof(name), "GPIO%d_", priv->bank);
+   str = strdup(name);
+   if (!str)
+   return -ENOMEM;
+
+   uc_priv->bank_name = str;
+
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, node, "gpio-ranges",
+NULL, 3, 0, );
+   if (ret)
+   printf("%s: 'gpio-ranges' not defined - using default!\n",
+  __func__);
+
+   uc_priv->gpio_count = 

[U-Boot] [PATCH v4 1/6] ARM: dts: imx: Copy imx28 device tree related files from Linux kernel (v5.1.9)

[Lukasz Majewski]

This patch copies from the Linux kernel (tag v5.1.9) SHA1: 2df16141a2c4
i.MX28 related device tree files.

Signed-off-by: Lukasz Majewski 
---

Changes in v4:
- Add 12 digit SHA1 ID for tag v5.1.9

Changes in v3:
- Update tag to 5.1.9
- Set more apropriate tags

Changes in v2: None

 arch/arm/dts/imx28-pinfunc.h |  506 
 arch/arm/dts/imx28.dtsi  | 1330 ++
 arch/arm/dts/mxs-pinfunc.h   |   31 +
 3 files changed, 1867 insertions(+)
 create mode 100644 arch/arm/dts/imx28-pinfunc.h
 create mode 100644 arch/arm/dts/imx28.dtsi
 create mode 100644 arch/arm/dts/mxs-pinfunc.h

diff --git a/arch/arm/dts/imx28-pinfunc.h b/arch/arm/dts/imx28-pinfunc.h
new file mode 100644
index 00..e11f69ba0f
--- /dev/null
+++ b/arch/arm/dts/imx28-pinfunc.h
@@ -0,0 +1,506 @@
+/*
+ * Header providing constants for i.MX28 pinctrl bindings.
+ *
+ * Copyright (C) 2013 Lothar Waßmann 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#ifndef __DT_BINDINGS_MX28_PINCTRL_H__
+#define __DT_BINDINGS_MX28_PINCTRL_H__
+
+#include "mxs-pinfunc.h"
+
+#define MX28_PAD_GPMI_D00__GPMI_D0 0x
+#define MX28_PAD_GPMI_D01__GPMI_D1 0x0010
+#define MX28_PAD_GPMI_D02__GPMI_D2 0x0020
+#define MX28_PAD_GPMI_D03__GPMI_D3 0x0030
+#define MX28_PAD_GPMI_D04__GPMI_D4 0x0040
+#define MX28_PAD_GPMI_D05__GPMI_D5 0x0050
+#define MX28_PAD_GPMI_D06__GPMI_D6 0x0060
+#define MX28_PAD_GPMI_D07__GPMI_D7 0x0070
+#define MX28_PAD_GPMI_CE0N__GPMI_CE0N  0x0100
+#define MX28_PAD_GPMI_CE1N__GPMI_CE1N  0x0110
+#define MX28_PAD_GPMI_CE2N__GPMI_CE2N  0x0120
+#define MX28_PAD_GPMI_CE3N__GPMI_CE3N  0x0130
+#define MX28_PAD_GPMI_RDY0__GPMI_READY00x0140
+#define MX28_PAD_GPMI_RDY1__GPMI_READY10x0150
+#define MX28_PAD_GPMI_RDY2__GPMI_READY20x0160
+#define MX28_PAD_GPMI_RDY3__GPMI_READY30x0170
+#define MX28_PAD_GPMI_RDN__GPMI_RDN0x0180
+#define MX28_PAD_GPMI_WRN__GPMI_WRN0x0190
+#define MX28_PAD_GPMI_ALE__GPMI_ALE0x01a0
+#define MX28_PAD_GPMI_CLE__GPMI_CLE0x01b0
+#define MX28_PAD_GPMI_RESETN__GPMI_RESETN  0x01c0
+#define MX28_PAD_LCD_D00__LCD_D0   0x1000
+#define MX28_PAD_LCD_D01__LCD_D1   0x1010
+#define MX28_PAD_LCD_D02__LCD_D2   0x1020
+#define MX28_PAD_LCD_D03__LCD_D3   0x1030
+#define MX28_PAD_LCD_D04__LCD_D4   0x1040
+#define MX28_PAD_LCD_D05__LCD_D5   0x1050
+#define MX28_PAD_LCD_D06__LCD_D6   0x1060
+#define MX28_PAD_LCD_D07__LCD_D7   0x1070
+#define MX28_PAD_LCD_D08__LCD_D8   0x1080
+#define MX28_PAD_LCD_D09__LCD_D9   0x1090
+#define MX28_PAD_LCD_D10__LCD_D10  0x10a0
+#define MX28_PAD_LCD_D11__LCD_D11  0x10b0
+#define MX28_PAD_LCD_D12__LCD_D12  0x10c0
+#define MX28_PAD_LCD_D13__LCD_D13  0x10d0
+#define MX28_PAD_LCD_D14__LCD_D14  0x10e0
+#define MX28_PAD_LCD_D15__LCD_D15  0x10f0
+#define MX28_PAD_LCD_D16__LCD_D16  0x1100
+#define MX28_PAD_LCD_D17__LCD_D17  0x1110
+#define MX28_PAD_LCD_D18__LCD_D18  0x1120
+#define MX28_PAD_LCD_D19__LCD_D19  0x1130
+#define MX28_PAD_LCD_D20__LCD_D20  0x1140
+#define MX28_PAD_LCD_D21__LCD_D21  0x1150
+#define MX28_PAD_LCD_D22__LCD_D22  0x1160
+#define MX28_PAD_LCD_D23__LCD_D23  0x1170
+#define MX28_PAD_LCD_RD_E__LCD_RD_E0x1180
+#define MX28_PAD_LCD_WR_RWN__LCD_WR_RWN0x1190
+#define MX28_PAD_LCD_RS__LCD_RS0x11a0
+#define MX28_PAD_LCD_CS__LCD_CS0x11b0
+#define MX28_PAD_LCD_VSYNC__LCD_VSYNC  0x11c0
+#define MX28_PAD_LCD_HSYNC__LCD_HSYNC  0x11d0
+#define MX28_PAD_LCD_DOTCLK__LCD_DOTCLK0x11e0
+#define MX28_PAD_LCD_ENABLE__LCD_ENABLE0x11f0
+#define MX28_PAD_SSP0_DATA0__SSP0_D0   0x2000
+#define MX28_PAD_SSP0_DATA1__SSP0_D1   0x2010
+#define MX28_PAD_SSP0_DATA2__SSP0_D2   0x2020
+#define MX28_PAD_SSP0_DATA3__SSP0_D3   0x2030

[U-Boot] [PATCH v4 5/6] ARM: imx: pinctrl: Add support for i.MX2[38] mxs pinctrl driver

[Lukasz Majewski]

The code responsible for setting proper values in the MUX registers
(in the mxs_pinctrl_set_state()) has been ported from Linux kernel
- SHA1: 17bb763e7eaf tag v5.1.11 from linux-stable.

As the pinctrl node in the imx28.dtsi file has gpio pins nodes as subnodes,
it was necessary to use 'dm_scan_fdt_dev()' (as a .bind method) to also
make them 'visible' by the DM's "gpio_mxs" driver.

Signed-off-by: Lukasz Majewski 

---

Changes in v4:
- Use Linux kernel code to setup pins instead of Barebox
- Add soc specific data and compatible for i.MX23 and i.MX28
- Use devm_kfree() to release temporary memory

Changes in v3:
- Set more apropriate tags

Changes in v2: None

 drivers/pinctrl/nxp/Kconfig   |  10 ++
 drivers/pinctrl/nxp/Makefile  |   1 +
 drivers/pinctrl/nxp/pinctrl-mxs.c | 200 ++
 drivers/pinctrl/nxp/pinctrl-mxs.h |  55 +++
 4 files changed, 266 insertions(+)
 create mode 100644 drivers/pinctrl/nxp/pinctrl-mxs.c
 create mode 100644 drivers/pinctrl/nxp/pinctrl-mxs.h

diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
index 61f93be42d..f2e67ca231 100644
--- a/drivers/pinctrl/nxp/Kconfig
+++ b/drivers/pinctrl/nxp/Kconfig
@@ -89,6 +89,16 @@ config PINCTRL_IMX8M
  only parses the 'fsl,pins' property and configure related
  registers.
 
+config PINCTRL_MXS
+   bool "NXP MXS pinctrl driver"
+   depends on ARCH_MX28 && PINCTRL_FULL
+   help
+ Say Y here to enable the i.MX mxs pinctrl driver
+
+ This option provides a simple pinctrl driver for i.MX mxs SoC
+ familiy, e.g. i.MX28. This feature depends on device tree
+ configuration.
+
 config PINCTRL_VYBRID
bool "Vybrid (vf610) pinctrl driver"
depends on ARCH_VF610 && PINCTRL_FULL
diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
index b340d9448a..b86448aac9 100644
--- a/drivers/pinctrl/nxp/Makefile
+++ b/drivers/pinctrl/nxp/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_PINCTRL_IMX7ULP)   += pinctrl-imx7ulp.o
 obj-$(CONFIG_PINCTRL_IMX_SCU)  += pinctrl-scu.o
 obj-$(CONFIG_PINCTRL_IMX8) += pinctrl-imx8.o
 obj-$(CONFIG_PINCTRL_IMX8M)+= pinctrl-imx8m.o
+obj-$(CONFIG_PINCTRL_MXS)  += pinctrl-mxs.o
 obj-$(CONFIG_PINCTRL_VYBRID)   += pinctrl-vf610.o
diff --git a/drivers/pinctrl/nxp/pinctrl-mxs.c 
b/drivers/pinctrl/nxp/pinctrl-mxs.c
new file mode 100644
index 00..d429d6943a
--- /dev/null
+++ b/drivers/pinctrl/nxp/pinctrl-mxs.c
@@ -0,0 +1,200 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 DENX Software Engineering
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pinctrl-mxs.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct mxs_pinctrl_priv {
+   void __iomem *base;
+   const struct mxs_regs *regs;
+};
+
+static void mxs_pinctrl_rmwl(u32 value, u32 mask, u8 shift, void __iomem *reg)
+{
+   u32 tmp;
+
+   tmp = readl(reg);
+   tmp &= ~(mask << shift);
+   tmp |= value << shift;
+   writel(tmp, reg);
+}
+
+static unsigned long mxs_dt_node_to_map(struct udevice *conf)
+{
+   unsigned long config = 0;
+   int ret;
+   u32 val;
+
+   ret = dev_read_u32(conf, "fsl,drive-strength", );
+   if (!ret)
+   config = val | MA_PRESENT;
+
+   ret = dev_read_u32(conf, "fsl,voltage", );
+   if (!ret)
+   config |= val << VOL_SHIFT | VOL_PRESENT;
+
+   ret = dev_read_u32(conf, "fsl,pull-up", );
+   if (!ret)
+   config |= val << PULL_SHIFT | PULL_PRESENT;
+
+   return config;
+}
+
+static int mxs_pinctrl_set_mux(struct udevice *dev, u32 val, int bank, int pin)
+{
+   struct mxs_pinctrl_priv *iomux = dev_get_priv(dev);
+   int muxsel = MUXID_TO_MUXSEL(val), shift;
+   void __iomem *reg;
+
+   reg = iomux->base + iomux->regs->muxsel;
+   reg += bank * 0x20 + pin / 16 * 0x10;
+   shift = pin % 16 * 2;
+
+   mxs_pinctrl_rmwl(muxsel, 0x3, shift, reg);
+   debug(" mux %d,", muxsel);
+
+   return 0;
+}
+
+static int mxs_pinctrl_set_state(struct udevice *dev, struct udevice *conf)
+{
+   struct mxs_pinctrl_priv *iomux = dev_get_priv(dev);
+   u32 *pin_data, val, ma, vol, pull;
+   int npins, size, i, ret;
+   unsigned long config;
+
+   debug("\n%s: set state: %s\n", __func__, conf->name);
+
+   size = dev_read_size(conf, "fsl,pinmux-ids");
+   if (size < 0)
+   return size;
+
+   if (!size || size % sizeof(int)) {
+   dev_err(dev, "Invalid fsl,pinmux-ids property in %s\n",
+   conf->name);
+   return -EINVAL;
+   }
+
+   npins = size / sizeof(int);
+
+   pin_data = devm_kzalloc(dev, size, 0);
+   if (!pin_data)
+   return -ENOMEM;
+
+   ret = dev_read_u32_array(conf, "fsl,pinmux-ids", pin_data, npins);
+ 

[U-Boot] [PATCH v4 2/6] ARM: imx: net: Enable support for i.MX28 DM_ETH in the fec_mxc.c driver

[Lukasz Majewski]

The fec_mxc.c driver can be reused by i.MX28 when DM_ETH is enabled.
One only needs to add proper compatible and dependency on FEC_MXC in the
Kconfig.

Signed-off-by: Lukasz Majewski 
---

Changes in v4:
- Sort the entries for compatibles and Kconfig

Changes in v3:
- Set more apropriate tags

Changes in v2: None

 drivers/net/Kconfig   | 2 +-
 drivers/net/fec_mxc.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e6a4fdf30e..60273dc737 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -190,7 +190,7 @@ config FEC_MXC_MDIO_BASE
 
 config FEC_MXC
bool "FEC Ethernet controller"
-   depends on MX5 || MX6 || MX7 || IMX8 || VF610
+   depends on MX28 || MX5 || MX6 || MX7 || IMX8 || VF610
help
  This driver supports the 10/100 Fast Ethernet controller for
  NXP i.MX processors.
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index d7c080943a..96e3ad9a1a 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1485,6 +1485,7 @@ static int fecmxc_ofdata_to_platdata(struct udevice *dev)
 }
 
 static const struct udevice_id fecmxc_ids[] = {
+   { .compatible = "fsl,imx28-fec" },
{ .compatible = "fsl,imx6q-fec" },
{ .compatible = "fsl,imx6sl-fec" },
{ .compatible = "fsl,imx6sx-fec" },
-- 
2.11.0

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

[U-Boot] [PATCH v4 3/6] DTS: dm: mxs: gpio: Provide 'gpio-ranges' for mxs_gpio driver

[Lukasz Majewski]

Those properties are U-Boot specific as the mxs gpio Linux driver (up to
version v5.1.11) is not supporting them.

Signed-off-by: Lukasz Majewski 

---

Changes in v4:
- New file - imx28-u-boot.dtsi

Changes in v3: None
Changes in v2: None

 arch/arm/dts/imx28-u-boot.dtsi | 28 
 1 file changed, 28 insertions(+)
 create mode 100644 arch/arm/dts/imx28-u-boot.dtsi

diff --git a/arch/arm/dts/imx28-u-boot.dtsi b/arch/arm/dts/imx28-u-boot.dtsi
new file mode 100644
index 00..a5bf74b1b7
--- /dev/null
+++ b/arch/arm/dts/imx28-u-boot.dtsi
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * SPDX-License-Identifier: GPL-2.0+ or X11
+ */
+#include "imx28.dtsi"
+
+ {
+   gpio-ranges = < 0 0 29>;
+};
+
+ {
+   gpio-ranges = < 29 0 32>;
+};
+
+ {
+   gpio-ranges = < 61 0 28>;
+};
+
+ {
+   gpio-ranges = < 89 0 31>;
+};
+
+ {
+   gpio-ranges = < 120 0 21>;
+};
-- 
2.11.0

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

[U-Boot] [PATCH v4 0/6] DM: Convert i.MX28 gpio, pinmux, spi and eth drivers to DM/DTS

[Lukasz Majewski]

This patch series converts some i.MX28 drivers to use DM/DTS.

Converted drivers:
- mxs_gpio.c - gpio driver
- pinctrl-mxs.c - pinmux driver
- Adjust fec_eth.c to support also i.MX28 SoC.
- mxs_spi.c - SPI driver

After applying this series it is possible to use ETH on i.MX28
board with following DTS description:

 {
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;
phy-supply = <_fec_3v3>;
phy-reset-gpios = < 13 GPIO_ACTIVE_LOW>;
phy-reset-duration = <1>;
phy-reset-post-delay = <1>;
status = "okay";

fixed-link {
  speed = <100>;
  full-duplex;
};
};

And store the received binaries on SPI-NOR memory.

Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/547299325

Applied on top of u-boot/master branch
SHA1: c2ea87883ef309570c8903e6de4b8b78685d73d0


Changes in v4:
- Add 12 digit SHA1 ID for tag v5.1.9
- Sort the entries for compatibles and Kconfig
- New file - imx28-u-boot.dtsi
- Use BIT() macro instead of 1 << offset
- Use devfdt_get_addr to get gpio number
- Use gpio-ranges property to setup gpios
- Use Linux kernel code to setup pins instead of Barebox
- Add soc specific data and compatible for i.MX23 and i.MX28
- Use devm_kfree() to release temporary memory
- Adjust the driver to support i.MX23 (add compatible, adjust clk code)
- Use BIT() macro where applicable

Changes in v3:
- Update tag to 5.1.9
- Set more apropriate tags
- Set more apropriate tags
- Set more apropriate tags
- Set more apropriate tags
- Set more appropriate tags

Changes in v2:
- Use #if !CONFIG_IS_ENABLED(DM_GPIO) instead of plain #ifdef CONFIG_DM_GPIO
- New patch (conversion of mxs_spi.c to DM_SPI)

Lukasz Majewski (6):
  ARM: dts: imx: Copy imx28 device tree related files from Linux kernel
(v5.1.9)
  ARM: imx: net: Enable support for i.MX28 DM_ETH in the fec_mxc.c
driver
  DTS: dm: mxs: gpio: Provide 'gpio-ranges' for mxs_gpio driver
  ARM: dm: mxs: gpio: Add support for DM/DTS in the mxs_gpio.c driver
(DM_GPIO)
  ARM: imx: pinctrl: Add support for i.MX2[38] mxs pinctrl driver
  ARM: dm: spi: Add support DM/DTS for i.MX28 mxs SPI driver (DM_SPI
conversion)

 arch/arm/dts/imx28-pinfunc.h  |  506 ++
 arch/arm/dts/imx28-u-boot.dtsi|   28 +
 arch/arm/dts/imx28.dtsi   | 1330 +
 arch/arm/dts/mxs-pinfunc.h|   31 +
 drivers/gpio/mxs_gpio.c   |  148 +
 drivers/net/Kconfig   |2 +-
 drivers/net/fec_mxc.c |1 +
 drivers/pinctrl/nxp/Kconfig   |   10 +
 drivers/pinctrl/nxp/Makefile  |1 +
 drivers/pinctrl/nxp/pinctrl-mxs.c |  200 ++
 drivers/pinctrl/nxp/pinctrl-mxs.h |   55 ++
 drivers/spi/mxs_spi.c |  400 ---
 12 files changed, 2628 insertions(+), 84 deletions(-)
 create mode 100644 arch/arm/dts/imx28-pinfunc.h
 create mode 100644 arch/arm/dts/imx28-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx28.dtsi
 create mode 100644 arch/arm/dts/mxs-pinfunc.h
 create mode 100644 drivers/pinctrl/nxp/pinctrl-mxs.c
 create mode 100644 drivers/pinctrl/nxp/pinctrl-mxs.h

-- 
2.11.0

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

Re: [U-Boot] [PATCH] mmc: tmio: sdhi: Do not use auto-retuning in HS400 mode

[Marek Vasut]

On 5/22/19 8:37 PM, Marek Vasut wrote:
> The SDHI supports automatic correction of sampling point in
> HS200/SDR104 modes. However, on R-Car Gen3, this feature is
> not supported in HS400 mode.
> 
> Auto and manual correction cannot both be used in HS400 mode.
> Therefore, in HS400 mode, disable auto correction and ignore
> the error status.
> 
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> Cc: Peng Fan 

Please postpone this patch, I'll be sending V2 once there's more
information on this topic.

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

Re: [U-Boot] [PATCH v2 2/2] fastboot: Fix slot names reported by getvar

[Lukasz Majewski]

On Tue, 18 Jun 2019 17:34:54 +0300
Sam Protsenko  wrote:

> Hi Lukasz,
> 
> Seems like the versioning is basically useless in fastboot USB
> protocol. It exists, but only host requests the version from device
> (bootloader), like "fastboot getvar version". It always returns "0.4"
> [1], and it was unchanged for 5 years or so. I didn't find any
> handshake with protocol version exchange. Alas, as I mentioned before,
> we probably can't keep the backward compatibility in universal way.
> The only way I see to make U-Boot work with both "a" and "_a"
> prefixes, is to introduce some new config option or dedicated
> environment variable, so that user can specify which format should be
> used.
> 
> I suggest merging this as is, as we don't have any users for slotted
> partitions in upstream U-Boot anyway, at this moment. If need arises,
> we can add option or variable later. Of course, I don't suggest to
> merge this right now, as codebase is frozen, and this is not an ideal
> bugfix and can even break backward compatibility. Let's take it when
> merge window opens.
> 
> Please tell me what is the preferred course of actions on this one,
> from your point of view.

As you stated in the other mail - you shall prepare some fix for
current code base (without the _a suffix) for this release. Please
proceed.

Regarding the supported features - maybe we shall introduce new env
variable - like fastboot_version = "0.5" (then - 0.6, 0.7).

And in U-Boot just decide which set of features would be 0.5 or 0.6.

Then, we can also use Kconfig option to enable needed features.

Otherwise, we will have regressions all the time as the "fastboot"
protocol changes without any notice in the versioning (inside the
protocol).

> 
> Thanks!
> 
> [1]
> http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/fastboot/fb_getvar.c;h=4268628f5ef0210507c5d23f2e4209b2afc07029;hb=refs/heads/master#l84
> [2]
> https://android.googlesource.com/platform/system/core/+/9bfecb0e3444306ec57d7fafe4a99a47d3848c17%5E%21/#F0
> 
> On Sat, Jun 15, 2019 at 6:29 PM Lukasz Majewski  wrote:
> >
> > Hi Sam,
> >  
> > > Fastboot tool recently underwent changes w.r.t. A/B slot format:
> > >   1. In commit [1] the new slot format was introduced, according
> > > to new A/B specification [2]. New slot format is "a", and old
> > > format "_a" is now considered legacy.
> > >   2. In commit [3] the legacy format "_a" was fixed and fastboot
> > > tool should support both "a" and "_a" slot formats now.
> > >   3. Finally, commit [4] drops the legacy slot format ("_a")
> > > completely. That makes the latest fastboot tool incompatible with
> > > "_a" format.
> > >
> > > Last change leads to next error, when running "fastboot flash"
> > > with current U-Boot:
> > >
> > > $ fastboot flash boot boot.img
> > > Sending 'boot__a' (11301 KB)OKAY [  0.451s]
> > > Writing 'boot__a'   FAILED (remote: 'cannot find
> > > partition') fastboot: error: Command failed
> > >
> > > To overcome this issue we should report slot names in "a" format
> > > instead of "_a". Of course, this change breaks U-Boot
> > > compatibility with older fastboot tools, but that shouldn't be a
> > > problem as A/B is not implemented in U-Boot yet, and there are
> > > not users for slotted partitions out there anyway. This fact can
> > > be checked like this:
> > >
> > > $ grep -Ir \b'boot_a\b' *
> > >
> > > Let's use new slot format in order to fix "fastboot flash" with
> > > slotted partitions and to be in sync with AOSP master.
> > >
> > > With this patch, U-Boot depends on most recent fastboot tool
> > > (patch [1] or later), for working with slotted partitions.  
> >
> > Is there any "version" number scheme for the fastboot protocol
> > specification?
> >
> > I do remember that in the past there were some mismatches for some
> > "fastboot" specification depending on vendor. Now it turns out that
> > there is a problem between AOSP versions ...
> >
> > (My point is that for example even lthor had version number for
> > specification update. Is something similar for fastboot?).
> >  
> > >
> > > [1]
> > > https://android.googlesource.com/platform/system/core/+/8091947847d5e5130b09d2ac0a4bdc900f3b77c5
> > > [2]
> > > https://source.android.com/devices/tech/ota/ab/ab_implement#partitions
> > > [3]
> > > https://android.googlesource.com/platform/system/core/+/04396f62da6150b94e02d50e5302fd980048833d
> > > [4]
> > > https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f
> > >
> > > Signed-off-by: Sam Protsenko 
> > > ---
> > > Changes in v2:
> > >   - don't change slot format in "slot-suffixes" variable (it's now
> > > dropped in [PATCH 1/2])
> > >   - improve commit message
> > >
> > >  drivers/fastboot/fb_getvar.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/fastboot/fb_getvar.c
> > > b/drivers/fastboot/fb_getvar.c index f89c7f62e6..9ee5054485 100644
> > > --- 

[U-Boot] [PATCH] imx :hab: Add hab version command

[Sjoerd Simons]

THe RVT data includes a major and minor version in its header
parameter. Add a new command to print this out.

Signed-off-by: Sjoerd Simons 

---
Unfortunately there doesn't seem to be a way to get the minor version of
the hab ROM. While there is a get_version function pointer in the vector
table it's documented to only be valid during the ROM phase and a quick
hack to try and call it on my board always returned 1 :/.

 arch/arm/include/asm/mach-imx/hab.h |  1 +
 arch/arm/mach-imx/hab.c | 21 +
 2 files changed, 22 insertions(+)

diff --git a/arch/arm/include/asm/mach-imx/hab.h 
b/arch/arm/include/asm/mach-imx/hab.h
index 95df88423c..5c82a148b4 100644
--- a/arch/arm/include/asm/mach-imx/hab.h
+++ b/arch/arm/include/asm/mach-imx/hab.h
@@ -189,6 +189,7 @@ typedef void hapi_clock_init_t(void);
 #define HAB_CID_ROM 0 /**< ROM Caller ID */
 #define HAB_CID_UBOOT 1 /**< UBOOT Caller ID*/
 
+#define HAB_TAG_RVT  0xDD  /* ROM Vector Table */
 #define HAB_CMD_HDR  0xD4  /* CSF Header */
 #define HAB_CMD_WRT_DAT  0xCC  /* Write Data command tag */
 #define HAB_CMD_CHK_DAT  0xCF  /* Check Data command tag */
diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index d42a15e877..e8487932c0 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -365,6 +365,21 @@ static int do_hab_failsafe(cmd_tbl_t *cmdtp, int flag, int 
argc,
return 0;
 }
 
+static int do_hab_version(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+   struct hab_hdr *hdr = (struct hab_hdr *)HAB_RVT_BASE;
+
+   if (hdr->tag != HAB_TAG_RVT) {
+   printf("Unexpected header tag: %x\n", hdr->tag);
+   return CMD_RET_FAILURE;
+   }
+
+   printf("HAB version: %d.%d\n", hdr->par >> 4, hdr->par & 0xf);
+
+   return 0;
+}
+
 static int do_authenticate_image_or_failover(cmd_tbl_t *cmdtp, int flag,
 int argc, char * const argv[])
 {
@@ -421,6 +436,12 @@ U_BOOT_CMD(
"ivt_offset - hex offset of IVT in the image"
  );
 
+U_BOOT_CMD(
+   hab_version, 1, 0, do_hab_version,
+   "print HAB major/minor version",
+   ""
+ );
+
 #endif /* !defined(CONFIG_SPL_BUILD) */
 
 /* Get CSF Header length */
-- 
2.20.1

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

Re: [U-Boot] [U-Boot-Custodians] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Anatolij Gustschin]

On Tue, 18 Jun 2019 22:49:44 +0200
Heinrich Schuchardt xypron.g...@gmx.de wrote:
...
>> I tried to push to u-boot-net an got this...
>>
>> --8<--
>>
>> $ git push -u -v net-push master
>> Pushing to g...@gitlab.denx.de:u-boot/custodians/u-boot-net.git  
>
>Just use https, e.g
>
>git remote set-url net \
>https://gitlab.denx.de/u-boot/custodians/u-boot-net.git

Something went wrong when importing u-boot-net repository, this
repository is empty on gitlab server. This might be the reason.
Cloning via https doesn't work, too.

@Harald: could you please have a look?

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

Re: [U-Boot] [U-Boot-Custodians] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Heinrich Schuchardt]

On 6/18/19 10:08 PM, Joe Hershberger wrote:

On Tue, Jun 18, 2019 at 8:47 AM Wolfgang Denk  wrote:


Hello everybody,

I wrote:


as discussed before, we want to switch from the old git server to
more powerful soft- and hardware.  We will move the U-Boot master
repository and all custodian repositories to gitlab.

...

The switch will take place as follows:

1. We will create user accounts for all custodians at gitlab.denx.de
You will receive an e-mail notification with your login
credentials. We will start with this this afternoon (CEST),
so if you have not received such an e-mail by tomorrow morning,
please let us know.

2. We will block your SSH keys on the old git server, thus
effectively turning the custodian repositories into read-only
mode.  Custodians will not be able to push any new stuff to the
old repositories any more.

This phase will start when all custodian repositories have been
created, but in no case before  12:00 p. m. (noon) CEST.  the
next steps will follow as quickly as possible, ideally only a few
minutes later.

3. The old repository will be cloned to the new gitlab server.  This
should not take long.  We don't expect any long interruption.
You wanted to have another cup of coffee anyway :-)

4. The custodian can resume work using the gitlab server, as soon as
he can "see" his repository there.  Tom should already be
prepared to pull from the gitlab repos.


All these steps have been completed by now.  All custodians should
be able to access the new repositories now, and use all teh gitlab
features that are enabled for this project (including CI runners).


I tried to push to u-boot-net an got this...

--8<--

$ git push -u -v net-push master
Pushing to g...@gitlab.denx.de:u-boot/custodians/u-boot-net.git


Just use https, e.g

git remote set-url net \
https://gitlab.denx.de/u-boot/custodians/u-boot-net.git

And in .gitconfig put your email address:

[credential "https://gitlab.denx.de;]
username = joe.hershber...@gmail.com

At least this setup worked for EFI.

Best reards

Heinrich


gitaly-receive-pack: fatal: error: %v
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

-->8---

SSH seems to be fine, but something about the path is no good. Can
someone check this on the server?

Thanks,
-Joe


The U-Boot web pages (especially the source code links and the
custodian page) have been updated to reference the new gitlab
repositories.

By now, the gitlab repos represent the official and active mainline
/ custodian repositories.



5. After all custodians have been moved, URL rewrite rules will be
activated, and the DNS will be changed, so that the old URLs
will still be working, though only for read-only access.

Note: this last step is the most error-prone one.  It is likely
that the rewrite roles are incomplete at the beginning, and/or
incorrect for a few special cases.  Please be patient and report
such errors with enough detail to reproduce, then we will fix
them.


This is what we will be working on now.

Thanks for your patience!

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.
___
U-Boot-Custodians mailing list
u-boot-custodi...@lists.denx.de
https://lists.denx.de/listinfo/u-boot-custodians

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



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

Re: [U-Boot] [RFC 6/6] efi_loader: variable: support runtime variable access via cache

[Heinrich Schuchardt]

On 6/18/19 12:34 PM, Ilias Apalodimas wrote:

Hi all,

[...]

I think one version of the functions serving at runtime and boottime is
enough.

The cache should be used both at runtime and at boottime.


So do you mean that we should replace the existing "boottime" version
of get/set_variable with my code (algorithm)?

This is a bit complicated work because we should be able to *udpate*
UEFI variables at boottime, but my version of hsearch_runtime() is
a stripped (and modified) version and doesn't support it.


Do we really need a multilevel hash table? I would not expect hundreds
of variables.


Please don't change your point suddenly.
Here we are discussing whether "The cache should be used both at runtime
and at boottime" or not.


Heinrich, the idea here is to present a copy of the variables on the OS
and totally disable RT variable updating from the OS.
If someone wants to update UEFI variables, we can pack them to a Capsule
(using FIT image format) and apply them on next reboot.
Given the fact that UEFI variables are not updated that often, isn't this a
viable option? If it is, then we need to keep the access separated
(as Akashi-san suggests) allowing bootime to change the variables.



Making the existing hsearch_r() executable at UEFI runtime is,
as I said before, quite painful.


You could start the cache implementation with a less complicated data
structure like a linked list.


This is totally a different issue. I listed this issue
in my cover letter.




Essentially I
expect three modules working together:

UEFI API implementation <-> Cache <-> Persistence driver

I would suggest to put each of these into a separate file.

Both the API implementation and the Cache have to be available at
Boottime and at Runtime. A first version of the persistence driver may
only be working at boottime.


Unfortunately, this is not practical right now because there is
already some sort of assumption (and consensus) that we would re-use
"Standalone MM services", which is already there in EDK2, as
secure storage for UEFI variables.
In the case, all the cache would be bypassed.
In my old prototype, I utilized the cache but dropped that feature
for several reasons.


What has EDK2 code to do with it?


Did you follow my comment below?

Unfortunately, this is not practical right now because there is
already some sort of assumption (and consensus) that we would re-use
"Standalone MM services", which is already there in EDK2, as
secure storage for UEFI variables.

We are already working towards having StandAloneMM as an early OP-TEE TA.
This will provide us with a secure variable storage for armv7/v8.


What would this OP-TEE binary do? - This seems to be a source of
misunderstanding when reviewing this patch.

My guess is that OP-TEE is used to read non-volatile variables only once
when starting U-Boot and to write non-volatile variables whenever they
are changed.

All further reading of non-volatile variables and all access to volatile
variables will be handled by the U-Boot internal variable cache.

For volatile variables I would assume OP-TEE to never see them. This
requires that the U-Boot variable cachek supports reading from and
writing to the cache at runtime.

StandaloneMmPkg seems to be the hardware independent part of the
solution. Where will the hardware driver reside in your OP-TEE solution?

Is the EDK2 hardware store for variables of the MACCHIATObin here:
edk2-platforms/Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c?

Which hardware platform will you use for testing the U-Boot development
of you OP-TEE driver?

Best regards

Heinrich






In case of write you could do a write-through in your cache if needed.




The NV-cache content should be written to non-volatile memory on Reset()
and on ExitBootServices() and if possible when updating variables at
runtime.


I'm not sure your intent here, but are you going to write back
the cache only once?
It won't work as every change of UEFI variable must be flushed
to persistent storage instantly.







Thanks
/Ilias



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

Re: [U-Boot] [PATCH] spl, Makefile: Take external offset into account for fit images

[Sjoerd Simons]

On Tue, 2019-06-18 at 22:20 +0200, Marek Vasut wrote:
> On 6/18/19 10:13 PM, Sjoerd Simons wrote:
> > When building a FIT image for SPL to load also take into account
> > the
> > configured external offset. This allows the SPL to load the u-boot
> > FIT
> > image correctly when configuring SECURE_BOOT on i.mx6 is enabled
> > (with CONFIG_FIT_EXTERNAL_OFFSET=0x3000).
> > 
> > Note this doesn't allow secure booting; but it does allow an
> > unsigned
> > SPL/u-boot with secure boot support eanbled to boot on open device.
> 
> Does this change behavior on systems which don't use
> CONFIG_FIT_EXTERNAL_OFFSET ?

Nope; in that case the default CONFIG_FIT_EXTERNAL_OFFSET is 0x0, which
gets essentially ignored if passed as a argument to -p 

> 
> > Signed-off-by: Sjoerd Simons 
> > 
> > ---
> > 
> >  Makefile | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Makefile b/Makefile
> > index c55ffa265f..a8808aeefd 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1240,6 +1240,7 @@ endif
> >  ifdef CONFIG_SPL_LOAD_FIT
> >  MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none
> > -O u-boot \
> > -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> > +   -p $(CONFIG_FIT_EXTERNAL_OFFSET) \
> > -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
> > $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst
> > ",,$(CONFIG_OF_LIST)))
> >  else
> > 
> 
> 

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

Re: [U-Boot] [PATCH] spl, Makefile: Take external offset into account for fit images

[Marek Vasut]

On 6/18/19 10:13 PM, Sjoerd Simons wrote:
> When building a FIT image for SPL to load also take into account the
> configured external offset. This allows the SPL to load the u-boot FIT
> image correctly when configuring SECURE_BOOT on i.mx6 is enabled
> (with CONFIG_FIT_EXTERNAL_OFFSET=0x3000).
> 
> Note this doesn't allow secure booting; but it does allow an unsigned
> SPL/u-boot with secure boot support eanbled to boot on open device.

Does this change behavior on systems which don't use
CONFIG_FIT_EXTERNAL_OFFSET ?

> Signed-off-by: Sjoerd Simons 
> 
> ---
> 
>  Makefile | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Makefile b/Makefile
> index c55ffa265f..a8808aeefd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1240,6 +1240,7 @@ endif
>  ifdef CONFIG_SPL_LOAD_FIT
>  MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
>   -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
> + -p $(CONFIG_FIT_EXTERNAL_OFFSET) \
>   -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
>   $(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
>  else
> 


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

[U-Boot] [PATCH] spl, Makefile: Take external offset into account for fit images

[Sjoerd Simons]

When building a FIT image for SPL to load also take into account the
configured external offset. This allows the SPL to load the u-boot FIT
image correctly when configuring SECURE_BOOT on i.mx6 is enabled
(with CONFIG_FIT_EXTERNAL_OFFSET=0x3000).

Note this doesn't allow secure booting; but it does allow an unsigned
SPL/u-boot with secure boot support eanbled to boot on open device.

Signed-off-by: Sjoerd Simons 

---

 Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Makefile b/Makefile
index c55ffa265f..a8808aeefd 100644
--- a/Makefile
+++ b/Makefile
@@ -1240,6 +1240,7 @@ endif
 ifdef CONFIG_SPL_LOAD_FIT
 MKIMAGEFLAGS_u-boot.img = -f auto -A $(ARCH) -T firmware -C none -O u-boot \
-a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \
+   -p $(CONFIG_FIT_EXTERNAL_OFFSET) \
-n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \
$(patsubst %,-b arch/$(ARCH)/dts/%.dtb,$(subst ",,$(CONFIG_OF_LIST)))
 else
-- 
2.20.1

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

Re: [U-Boot] [U-Boot-Custodians] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Joe Hershberger]

On Tue, Jun 18, 2019 at 8:47 AM Wolfgang Denk  wrote:
>
> Hello everybody,
>
> I wrote:
>
> > as discussed before, we want to switch from the old git server to
> > more powerful soft- and hardware.  We will move the U-Boot master
> > repository and all custodian repositories to gitlab.
> ...
> > The switch will take place as follows:
> >
> > 1. We will create user accounts for all custodians at gitlab.denx.de
> >You will receive an e-mail notification with your login
> >credentials. We will start with this this afternoon (CEST),
> >so if you have not received such an e-mail by tomorrow morning,
> >please let us know.
> >
> > 2. We will block your SSH keys on the old git server, thus
> >effectively turning the custodian repositories into read-only
> >mode.  Custodians will not be able to push any new stuff to the
> >old repositories any more.
> >
> >This phase will start when all custodian repositories have been
> >created, but in no case before  12:00 p. m. (noon) CEST.  the
> >next steps will follow as quickly as possible, ideally only a few
> >minutes later.
> >
> > 3. The old repository will be cloned to the new gitlab server.  This
> >should not take long.  We don't expect any long interruption.
> >You wanted to have another cup of coffee anyway :-)
> >
> > 4. The custodian can resume work using the gitlab server, as soon as
> >he can "see" his repository there.  Tom should already be
> >prepared to pull from the gitlab repos.
>
> All these steps have been completed by now.  All custodians should
> be able to access the new repositories now, and use all teh gitlab
> features that are enabled for this project (including CI runners).

I tried to push to u-boot-net an got this...

--8<--

$ git push -u -v net-push master
Pushing to g...@gitlab.denx.de:u-boot/custodians/u-boot-net.git
gitaly-receive-pack: fatal: error: %v
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

-->8---

SSH seems to be fine, but something about the path is no good. Can
someone check this on the server?

Thanks,
-Joe

> The U-Boot web pages (especially the source code links and the
> custodian page) have been updated to reference the new gitlab
> repositories.
>
> By now, the gitlab repos represent the official and active mainline
> / custodian repositories.
>
>
> > 5. After all custodians have been moved, URL rewrite rules will be
> >activated, and the DNS will be changed, so that the old URLs
> >will still be working, though only for read-only access.
> >
> >Note: this last step is the most error-prone one.  It is likely
> >that the rewrite roles are incomplete at the beginning, and/or
> >incorrect for a few special cases.  Please be patient and report
> >such errors with enough detail to reproduce, then we will fix
> >them.
>
> This is what we will be working on now.
>
> Thanks for your patience!
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Living on Earth may be expensive, but it includes an annual free trip
> around the Sun.
> ___
> U-Boot-Custodians mailing list
> u-boot-custodi...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot-custodians
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [BUG] fs: fat: error when handling long file names

[Heinrich Schuchardt]

Hello Takahiro

I hope you have an idea what might be missing in the FAT file system
support for long names.

When running the SCT I saw this error for the GetInfo functional test:

GetInfo() Basic Test - checkpoint3 -- PASS

E4F4F6A2-7538-4C79-AA3C-67184EC70E16

/home/supven01/work/sct_workspace/edk2/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleFileSystem/BlackBoxTest/SimpleFileSystemBBTestFunction.c:8607:
SystemInfo->Size - 18, BufferSize - 18, Tpl - 8


EFI: Entry efi_file_open(7ef8c250, 7edeb0c0,
"BBTestGetInfoBasicTestCheckpoint3_File_0", 8003, 0)
Error: allocating new dir entry

EFI: Exit: efi_file_open: 14

EFI: Entry efi_file_open(7ef8c250, 7edeb0c8,
"BBTestGetInfoBasicTestCheckpoint3_File_1", 8003, 0)
Error: allocating new dir entry

In the EFI shell output to a file with a long name sometimes fails
(depending on the history of the volume).

FS0:\> echo a > foo
FS0:\> echo a > abcdefgh.ijk
FS0:\> echo a > abcdefgh.ijkl
** Unable to write file /abcdefgh.ijkl **
FS0:\>

Up to now the SCT test is the only thing that fails reproducibly.

I use this repo for building:
https://github.com/xypron/u-boot-build/tree/qemu-arm64

make sct-prepare
make sct

Best regards

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

Re: [U-Boot] [RFC 1/6] efi_loader: runtime: make SetVirtualAddressMap configurable

[Mark Kettenis]

> From: Heinrich Schuchardt 
> Date: Sun, 16 Jun 2019 23:52:49 +0200
> 
> On 6/15/19 11:14 PM, Mark Kettenis wrote:
> >> From: Heinrich Schuchardt 
> >> Date: Sat, 15 Jun 2019 21:46:02 +0200
> >>
> >> On 6/5/19 6:21 AM, AKASHI Takahiro wrote:
> >>> OS does not always need to call SetVirtualAddressMap.
> >>> (Ard confirmed this on arm64 linux.)
> >>> So let this API configurable. If disabled, it will return EFI_UNSUPPORTED
> >>> as UEFI specification requires.
> >>
> >> Currently we do not support this scenario. Alex's patch should go in first.
> >
> > OpenBSD/arm64 will always call this function.  It does this in order
> 
> OpenBSD/arm32 does not call it. I have no clue why the 32bit and 64bit
> code have diverged.

Beyond the device drivers, there isn't much shared code between
OpenBSD/armv7 and OpenBSD/arm64.  And the code that handles EFI
runtime services is tied quite closely to the memory management code
which is quite different between AArch32 and AArch64.  The primary
reason for adding support for EFI runtime services to OpenBSD/amd64
was to support getting and setting the time on machines with
"fullblown" UEFI support.  Machines that have armv7 CPUs *and*
fullblown UEFI support are pretty much non-existent so I didn't
implement support for armv7 yet.

> > to randomize the virtual addresses used by runtime services to make it
> > harder for an attacker to call into UEFI runtime services.  Note that
> > the UEFI 2.7 standard provides no indication that this interface might
> > be optional, so I don't think OpenBSD is doing anything wrong here.
> >
> > I think it is unwise to make this API configurable.  But disabling it
> > by default like this diff does would be a seriously bad idea.  It
> > means U-Boot would no longer be backwards compatible with UEFI 2.7.
> 
> The current UEFI specification is 2.8. It foresees that
> SetVirtualAddressMap() can be marked as unsupported but that does not
> imply that we have to make it customizable. And disabling it by default
> does not make much sense while most operating systems use it.

Right!  Thanks,

Mark

> >>> Signed-off-by: AKASHI Takahiro 
> >>> ---
> >>>lib/efi_loader/Kconfig   | 7 +++
> >>>lib/efi_loader/efi_runtime.c | 8 
> >>>2 files changed, 15 insertions(+)
> >>>
> >>> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> >>> index 8bf4b1754d06..bb9c7582b14d 100644
> >>> --- a/lib/efi_loader/Kconfig
> >>> +++ b/lib/efi_loader/Kconfig
> >>> @@ -44,6 +44,13 @@ config EFI_SET_TIME
> >>> Provide the SetTime() runtime service at boottime. This 
> >>> service
> >>> can be used by an EFI application to adjust the real time 
> >>> clock.
> >>>
> >>> +config EFI_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> >>> + bool "runtime service: SetVirtualAddressMap"
> >>> + default n
> >>> + help
> >>> +   Enable SetVirtualAddressMap runtime service. This API will be
> >>> +   called by OS just before it enters into virtual address mode.
> >>> +
> >>>config EFI_DEVICE_PATH_TO_TEXT
> >>>   bool "Device path to text protocol"
> >>>   default y
> >>> diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
> >>> index 9c50955c9bd0..60442cb21d37 100644
> >>> --- a/lib/efi_loader/efi_runtime.c
> >>> +++ b/lib/efi_loader/efi_runtime.c
> >>> @@ -374,10 +374,12 @@ static const struct efi_runtime_detach_list_struct 
> >>> efi_runtime_detach_list[] = {
> >>>   /* do_reset is gone */
> >>>   .ptr = _runtime_services.reset_system,
> >>>   .patchto = efi_reset_system,
> >>> +#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> >>>   }, {
> >>>   /* invalidate_*cache_all are gone */
> >>>   .ptr = _runtime_services.set_virtual_address_map,
> >>>   .patchto = _unimplemented,
> >>> +#endif
> >>>   }, {
> >>>   /* RTC accessors are gone */
> >>>   .ptr = _runtime_services.get_time,
> >>> @@ -512,6 +514,7 @@ void efi_runtime_relocate(ulong offset, struct 
> >>> efi_mem_desc *map)
> >>>invalidate_icache_all();
> >>>}
> >>>
> >>> +#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> >>>/**
> >>> * efi_set_virtual_address_map() - change from physical to virtual 
> >>> mapping
> >>> *
> >>> @@ -619,6 +622,7 @@ static efi_status_t EFIAPI 
> >>> efi_set_virtual_address_map(
> >>>
> >>>   return EFI_EXIT(EFI_INVALID_PARAMETER);
> >>>}
> >>> +#endif /* CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP */
> >>>
> >>>/**
> >>> * efi_add_runtime_mmio() - add memory-mapped IO region
> >>> @@ -796,7 +800,11 @@ struct efi_runtime_services __efi_runtime_data 
> >>> efi_runtime_services = {
> >>>   .set_time = _set_time_boottime,
> >>>   .get_wakeup_time = (void *)_unimplemented,
> >>>   .set_wakeup_time = (void *)_unimplemented,
> >>> +#ifdef CONFIG_RUNTIME_SET_VIRTUAL_ADDRESS_MAP
> >>>   .set_virtual_address_map = 

Re: [U-Boot] [PATCH v1] fs: do_load: pass device path for efi payload

[Heinrich Schuchardt]

On 6/18/19 3:03 PM, Mian Yousaf Kaukab wrote:

fatload command can be used to load the EFI payload since EFI system
partition is always a FAT partition. Call into EFI code from do_load()
to set the device path from which the last binary was loaded. An EFI
application like grub2 can’t find its configuration file without the
device path set.

Since device path is now set in do_load() there is no need to set it
in do_load_wrapper() for the load command.

Signed-off-by: Mian Yousaf Kaukab 


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

Re: [U-Boot] [linux-sunxi] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support

[Clément Péron]

On Tue, 18 Jun 2019 at 19:08, Clément Péron  wrote:
>
> Hi Andre,
>
> On Tue, 18 Jun 2019 at 09:50, Jagan Teki  wrote:
> >
> > On Thu, May 16, 2019 at 6:56 AM Andre Przywara  
> > wrote:
> > >
> > > Hi,
> > >
> > > this series enables USB support on the H6 boards. This is mostly just
> > > adding some missing pieces here and there, the actual controller and PHY
> > > are very similar to the previous ones, if not identical.
> > > This is for the 2.0 ports only at the moment, USB 3.0 will be done
> > > later (started porting Icenowy's Linux driver).
> > > The Pine H64 shares a similar problem as the Pine64+ boards regarding
> > > the upper USB port. To enable this port, we need the first patch
> > > from the series [1] fixing this issue on the A64 boards.
> > >
> > > Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was
> > > lingering in one of my branches for a while.
> > > Patch 2 enables GPIO support for the H6, as this is needed for the Pine
> > > H64 to enable the VBUS regulator.
> > > Patch 3 adds the clock and reset gates mappings for the USB controller and
> > > the PHY, the values are taken from the manual and verified against
> > > Linux.
> > > Patch 4 adds some code to the PHY driver to skip over not implemented
> > > PHYs, as the H6 uses a PHY0/PHY3 combination in the DT.
> > > Patch 5 then eventually enables USB in the existing defconfigs.
> > > Patch 6 adds the .dts fixes required to get the upper USB port to work
> > > on the Pine H64.
> > >
> > > Clément, can you please verify that this works for the Beelink box?
> Thank you for the notice.
>
> Works fine on my board:
I have tested with and without the trick in usb2otg node and both seems working.
(only tested usb start; usb tree).
Why not leave it to avoid a difference with linux?

Regards,
Clément




> U-Boot 2019.07-rc4 (Jun 18 2019 - 19:06:21 +0200) Allwinner Technology
>
> CPU:   Allwinner H6 (SUN50I)
> Model: Beelink GS1
> DRAM:  2 GiB
> MMC:   mmc@402: 0, mmc@4022000: 1
> Loading Environment from FAT... Unable to use mmc 1:1... In:serial@500
> Out:   serial@500
> Err:   serial@500
> Net:   No ethernet found.
> starting USB...
> Bus usb@5101000: USB EHCI 1.00
> Bus usb@5101400: USB OHCI 1.0
> scanning bus usb@5101000 for devices... 1 USB Device(s) found
>
> Regards,
> Clément
>
> > > I guess the USB 2.0 port is probably the OTG one, so this setup would
> > > look somewhat similar to the PineH64, which would allow you to copy
> > > the USB DT nodes from there.
> > >
> > > Cheers,
> > > Andre.
> > >
> > > [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html
> > >
> > > Andre Przywara (6):
> > >   sunxi: move SUNXI_GPIO to Kconfig
> > >   sunxi: gpio: Enable support for H6 pin controller
> > >   sunxi: clocks: Add H6 USB clock gates and resets
> > >   sunxi: phy: Add USB PHY support for Allwinner H6
> > >   sunxi: H6: Enable USB for existing boards
> > >   sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
> >
> > Except 6/6 (it can be part of DTS sync during MW) and rest
> >
> > Reviewed-by: Jagan Teki 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/6] sunxi: phy: Add USB PHY support for Allwinner H6

[Clément Péron]

Hi,

On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
>
> The USB PHY used in the Allwinner H6 SoC has some pecularities (as usual),

Checkpatch warning:
WARNING: 'pecularities' may be misspelled - perhaps 'peculiarities'?

> which require a small addition to the USB PHY driver:
> In this case the second PHY is PHY3, not PHY1, so we need to skip number
> 1 and 2 in the code. Just use the respective code from Linux for that.
>
> Signed-off-by: Andre Przywara 
> ---
>  drivers/phy/allwinner/phy-sun4i-usb.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c 
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index f206fa3f5d..5e8f87717f 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -75,6 +75,7 @@ enum sun4i_usb_phy_type {
> sun8i_h3_phy,
> sun8i_v3s_phy,
> sun50i_a64_phy,
> +   sun50i_h6_phy,
>  };
>
>  struct sun4i_usb_phy_cfg {
> @@ -85,6 +86,7 @@ struct sun4i_usb_phy_cfg {
> bool dedicated_clocks;
> bool enable_pmu_unk1;
> bool phy0_dual_route;
> +   int missing_phys;
>  };
>
>  struct sun4i_usb_phy_info {
> @@ -349,6 +351,9 @@ static int sun4i_usb_phy_xlate(struct phy *phy,
> if (args->args_count >= data->cfg->num_phys)
> return -EINVAL;
>
> +   if (data->cfg->missing_phys & BIT(args->args[0]))
> +   return -ENODEV;
> +
> if (args->args_count)
> phy->id = args->args[0];
> else
> @@ -429,6 +434,9 @@ static int sun4i_usb_phy_probe(struct udevice *dev)
> struct sun4i_usb_phy_info *info = _info[i];
> char name[16];
>
> +   if (data->cfg->missing_phys & BIT(i))
> +   continue;
> +
> phy->gpio_vbus = sunxi_name_to_gpio(info->gpio_vbus);
> if (phy->gpio_vbus >= 0) {
> ret = gpio_request(phy->gpio_vbus, "usb_vbus");
> @@ -583,6 +591,17 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
> .phy0_dual_route = true,
>  };
>
> +static const struct sun4i_usb_phy_cfg sun50i_h6_cfg = {
> +   .num_phys = 4,
> +   .type = sun50i_h6_phy,
> +   .disc_thresh = 3,
> +   .phyctl_offset = REG_PHYCTL_A33,
> +   .dedicated_clocks = true,
> +   .enable_pmu_unk1 = true,
> +   .phy0_dual_route = true,
> +   .missing_phys = BIT(1) | BIT(2),
> +};
> +
>  static const struct udevice_id sun4i_usb_phy_ids[] = {
> { .compatible = "allwinner,sun4i-a10-usb-phy", .data = 
> (ulong)_a10_cfg },
> { .compatible = "allwinner,sun5i-a13-usb-phy", .data = 
> (ulong)_a13_cfg },
> @@ -594,6 +613,7 @@ static const struct udevice_id sun4i_usb_phy_ids[] = {
> { .compatible = "allwinner,sun8i-h3-usb-phy", .data = 
> (ulong)_h3_cfg },
> { .compatible = "allwinner,sun8i-v3s-usb-phy", .data = 
> (ulong)_v3s_cfg },
> { .compatible = "allwinner,sun50i-a64-usb-phy", .data = 
> (ulong)_a64_cfg},
> +   { .compatible = "allwinner,sun50i-h6-usb-phy", .data = 
> (ulong)_h6_cfg},
> { }
>  };
>
> --
> 2.14.5
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

[Clément Péron]

Hi,

On Thu, 16 May 2019 at 03:27, Andre Przywara  wrote:
>
> The first USB controller on the H6 SoC shares a PHY with the OTG
> controller. Reportedly to avoid problems with the VBUS regulator under
> Linux, we don't link OHCI0/EHCI0 to the USB PHY in the H6 .dtsi file.
>
> However on boards which can't use peripheral mode (because they have an
> always-on VBUS supply on an USB-A socket) we don't need this trick, and
> can properly connect host controller 0 to the PHY 0.
>
> Amend the Pine H64 .dts to reflect this. This enables the upper USB port
> in U-Boot on this board.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/dts/sun50i-h6-pine-h64.dts | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/sun50i-h6-pine-h64.dts 
> b/arch/arm/dts/sun50i-h6-pine-h64.dts
> index 4802902e12..aad7646b18 100644
> --- a/arch/arm/dts/sun50i-h6-pine-h64.dts
> +++ b/arch/arm/dts/sun50i-h6-pine-h64.dts
> @@ -96,6 +96,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -120,6 +122,8 @@
>  };
>
>   {
> +   phys = < 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -255,7 +259,6 @@
>
>   {
> dr_mode = "host";
> -   status = "okay";
>  };

Maybe you should add explicit comments in the device-tree to avoid
losing this at next sync with linux dt.

Regards,
Clement

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

Re: [U-Boot] [linux-sunxi] [PATCH 0/6] sunxi: H6: Enable USB (2.0) support

[Clément Péron]

Hi Andre,

On Tue, 18 Jun 2019 at 09:50, Jagan Teki  wrote:
>
> On Thu, May 16, 2019 at 6:56 AM Andre Przywara  wrote:
> >
> > Hi,
> >
> > this series enables USB support on the H6 boards. This is mostly just
> > adding some missing pieces here and there, the actual controller and PHY
> > are very similar to the previous ones, if not identical.
> > This is for the 2.0 ports only at the moment, USB 3.0 will be done
> > later (started porting Icenowy's Linux driver).
> > The Pine H64 shares a similar problem as the Pine64+ boards regarding
> > the upper USB port. To enable this port, we need the first patch
> > from the series [1] fixing this issue on the A64 boards.
> >
> > Patch 1 is a drive-by patch to bring SUNXI_GPIO to Kconfig, as this was
> > lingering in one of my branches for a while.
> > Patch 2 enables GPIO support for the H6, as this is needed for the Pine
> > H64 to enable the VBUS regulator.
> > Patch 3 adds the clock and reset gates mappings for the USB controller and
> > the PHY, the values are taken from the manual and verified against
> > Linux.
> > Patch 4 adds some code to the PHY driver to skip over not implemented
> > PHYs, as the H6 uses a PHY0/PHY3 combination in the DT.
> > Patch 5 then eventually enables USB in the existing defconfigs.
> > Patch 6 adds the .dts fixes required to get the upper USB port to work
> > on the Pine H64.
> >
> > Clément, can you please verify that this works for the Beelink box?
Thank you for the notice.

Works fine on my board:
U-Boot 2019.07-rc4 (Jun 18 2019 - 19:06:21 +0200) Allwinner Technology

CPU:   Allwinner H6 (SUN50I)
Model: Beelink GS1
DRAM:  2 GiB
MMC:   mmc@402: 0, mmc@4022000: 1
Loading Environment from FAT... Unable to use mmc 1:1... In:serial@500
Out:   serial@500
Err:   serial@500
Net:   No ethernet found.
starting USB...
Bus usb@5101000: USB EHCI 1.00
Bus usb@5101400: USB OHCI 1.0
scanning bus usb@5101000 for devices... 1 USB Device(s) found

Regards,
Clément

> > I guess the USB 2.0 port is probably the OTG one, so this setup would
> > look somewhat similar to the PineH64, which would allow you to copy
> > the USB DT nodes from there.
> >
> > Cheers,
> > Andre.
> >
> > [1] https://lists.denx.de/pipermail/u-boot/2019-May/369520.html
> >
> > Andre Przywara (6):
> >   sunxi: move SUNXI_GPIO to Kconfig
> >   sunxi: gpio: Enable support for H6 pin controller
> >   sunxi: clocks: Add H6 USB clock gates and resets
> >   sunxi: phy: Add USB PHY support for Allwinner H6
> >   sunxi: H6: Enable USB for existing boards
> >   sunxi: Pine64: DTS: enable USB PHY 0 for HCI0
>
> Except 6/6 (it can be part of DTS sync during MW) and rest
>
> Reviewed-by: Jagan Teki 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-spi/master

[Tom Rini]

On Mon, Jun 17, 2019 at 01:15:45PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Summary:
> - Drop zipitz2 board (Tom)
> - Add DEPRECATED option (Tom)
> - Mark legacy or non-dm drivers as DEPRECATED (Jagan)
> 
> thanks,
> Jagan.
> 
> The following changes since commit 68b90e57bc034e237923b02acb633dc4e91d44cb:
> 
>   configs: tinker-rk3288 disable CONFIG_SPL_I2C_SUPPORT (2019-06-11 08:13:05 
> -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-spi.git master
> 
> for you to fetch changes up to 88369d33e322e0cdfbb1f0c33021ad424578619e:
> 
>   configs: Disable now unbuildable SPI options for boards (2019-06-13 
> 12:51:06 +0530)
> 

Applied to u-boot/master, thanks!

-- 
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] [PULL] u-boot-usb/master

[Tom Rini]

On Fri, Jun 14, 2019 at 12:45:47PM +0200, Marek Vasut wrote:

> Assorted gadget fixes.
> 
> The following changes since commit c2ea87883ef309570c8903e6de4b8b78685d73d0:
> 
>   Merge tag 'efi-2019-07-rc5' of git://git.denx.de/u-boot-efi
> (2019-06-12 07:15:38 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 220f655176de8e6aa4aaea91bb2182260d26c4a4:
> 
>   fastboot: Check if partition really exist in getvar_has_slot()
> (2019-06-14 12:39:54 +0200)
> 

Applied to u-boot/master, thanks!

-- 
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] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Tom Rini]

On Mon, Jun 17, 2019 at 04:42:09PM +0200, Wolfgang Denk wrote:
> Hello everybody,
> 
> as discussed before, we want to switch from the old git server to
> more powerful soft- and hardware.  We will move the U-Boot master
> repository and all custodian repositories to gitlab.
> 
> The new URLs for cloning will become
> 
>   https://gitlab.denx.de/u-boot/u-boot
> 
> for the master repository and
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-XXX
> 
> for the XXX custodian repo.

On a related note, where do we go for a new repository?  I'd like to get
"u-boot-gitlab-ci-runner" configured so I can more easily publish the
Dockerfile (and license, etc) for the gitlab-ci runner container.
Thanks!

-- 
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] [PATCH] MAINTAINERS: Update git repo links

[Wolfgang Denk]

Dear Bin,

In message <1560872253-6077-1-git-send-email-bmeng...@gmail.com> you wrote:
> Update all git repo links with the new gitlab ones.
>
> Signed-off-by: Bin Meng 
> ---
>
>  MAINTAINERS | 106 
> ++--
>  1 file changed, 53 insertions(+), 53 deletions(-)

Thanks a lot!

Acked-by: Wolfgang Denk 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A conservative is a man who believes that nothing should be done for
the first time.   - Alfred E. Wiggam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] usb: dwc2: allow peripheral mode for OTG configuration

[Marek Vasut]

On 6/18/19 4:57 PM, Patrick Delaunay wrote:
> Allow device mode in DWC2 driver when device tree select the dr_mode
> "peripheral" or "otg".
> 
> The device mode is not allowed when dr_mode = "host" in device tree.
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Marek Vasut 

> ---
> 
> Changes in v2: None
> 
>  drivers/usb/gadget/dwc2_udc_otg.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index 023439c..35f4147 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -1041,7 +1041,8 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct 
> udevice *dev)
>   void (*set_params)(struct dwc2_plat_otg_data *data);
>   int ret;
>  
> - if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL) {
> + if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL &&
> + usb_get_dr_mode(node) != USB_DR_MODE_OTG) {
>   dev_dbg(dev, "Invalid mode\n");
>   return -ENODEV;
>   }
> 


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

Re: [U-Boot] [PATCH v2 1/3] usb: dwc2: correctly handle binding for g-tx-fifo-size

[Marek Vasut]

On 6/18/19 4:57 PM, Patrick Delaunay wrote:
> Manage g-tx-fifo-size as a array as specify in the binding.
> 
> Signed-off-by: Patrick Delaunay 

Reviewed-by: Marek Vasut 

I'm missing 2/3 , although I think it might be better if you take this
whole series through u-boot-stm .

> ---
> 
> Changes in v2:
> - move dt update in a separate patch
> - remove unecessary temporary variable
> 
>  drivers/usb/gadget/dwc2_udc_otg.c | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/gadget/dwc2_udc_otg.c 
> b/drivers/usb/gadget/dwc2_udc_otg.c
> index 494ab53..023439c 100644
> --- a/drivers/usb/gadget/dwc2_udc_otg.c
> +++ b/drivers/usb/gadget/dwc2_udc_otg.c
> @@ -1039,6 +1039,7 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct 
> udevice *dev)
>   int node = dev_of_offset(dev);
>   ulong drvdata;
>   void (*set_params)(struct dwc2_plat_otg_data *data);
> + int ret;
>  
>   if (usb_get_dr_mode(node) != USB_DR_MODE_PERIPHERAL) {
>   dev_dbg(dev, "Invalid mode\n");
> @@ -1050,7 +1051,18 @@ static int dwc2_udc_otg_ofdata_to_platdata(struct 
> udevice *dev)
>   platdata->rx_fifo_sz = dev_read_u32_default(dev, "g-rx-fifo-size", 0);
>   platdata->np_tx_fifo_sz = dev_read_u32_default(dev,
>  "g-np-tx-fifo-size", 0);
> - platdata->tx_fifo_sz = dev_read_u32_default(dev, "g-tx-fifo-size", 0);
> +
> + platdata->tx_fifo_sz_nb =
> + dev_read_size(dev, "g-tx-fifo-size") / sizeof(u32);
> + if (platdata->tx_fifo_sz_nb > DWC2_MAX_HW_ENDPOINTS)
> + platdata->tx_fifo_sz_nb = DWC2_MAX_HW_ENDPOINTS;
> + if (platdata->tx_fifo_sz_nb) {
> + ret = dev_read_u32_array(dev, "g-tx-fifo-size",
> +  platdata->tx_fifo_sz_array,
> +  platdata->tx_fifo_sz_nb);
> + if (ret)
> + return ret;
> + }
>  
>   platdata->force_b_session_valid =
>   dev_read_bool(dev, "u-boot,force-b-session-valid");
> 


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

Re: [U-Boot] [PATCH v3] fastboot: Remove "slot-suffixes" variable

[Marek Vasut]

On 6/18/19 4:57 PM, Sam Protsenko wrote:
> Hi Marek,
> 
> As you mentioned USB PR is now open, please apply this patch in u-boot-usb.

Fastboot is gadget stuff, so that's up to Lukasz.
Is this a bugfix ?

Also, please stop top-posting.

> Thanks!
> 
> On Tue, Jun 18, 2019 at 5:55 PM Sam Protsenko
>  wrote:
>>
>> "slot-suffixes" variable was dropped in fastboot tool (in [1]). Let's
>> track AOSP/master and drop this variable in U-Boot as well.
>>
>> [1] 
>> https://android.googlesource.com/platform/system/core/+/42b18a518bac85c3eea14206f6cbafbd1e98a31f
>>
>> Signed-off-by: Sam Protsenko 
>> ---
>> Changes in v3:
>>   - rebase on top of this merged patch (v1):
>> "[PATCH] fastboot: Fix slot names reported by getvar"
>> Changes in v2:
>>   - add this patch to patch series
>>   - drop slot-suffix variable instead of returning "a,b"
>>
>>  drivers/fastboot/fb_getvar.c | 8 
>>  1 file changed, 8 deletions(-)
>>
>> diff --git a/drivers/fastboot/fb_getvar.c b/drivers/fastboot/fb_getvar.c
>> index bf957e8326..c15b4f8fca 100644
>> --- a/drivers/fastboot/fb_getvar.c
>> +++ b/drivers/fastboot/fb_getvar.c
>> @@ -64,9 +64,6 @@ static const struct {
>> }, {
>> .variable = "current-slot",
>> .dispatch = getvar_current_slot
>> -   }, {
>> -   .variable = "slot-suffixes",
>> -   .dispatch = getvar_slot_suffixes
>>  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
>> }, {
>> .variable = "has-slot",
>> @@ -182,11 +179,6 @@ static void getvar_current_slot(char *var_parameter, 
>> char *response)
>> fastboot_okay("a", response);
>>  }
>>
>> -static void getvar_slot_suffixes(char *var_parameter, char *response)
>> -{
>> -   fastboot_okay("a,b", response);
>> -}
>> -
>>  #if CONFIG_IS_ENABLED(FASTBOOT_FLASH)
>>  static void getvar_has_slot(char *part_name, char *response)
>>  {
>> --
>> 2.20.1
>>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
> 


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

Re: [U-Boot] [PATCH v1] x86: Revert "Don't set up MTRRs in SPL"

[Bin Meng]

On Wed, Jun 19, 2019 at 12:06 AM Andy Shevchenko
 wrote:
>
> This breaks Intel Edison to work. It gets laggish and unable to boot kernel.
>
> Reverts commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a for now
> till better solution will be proposed.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/lib/init_helpers.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>

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

Re: [U-Boot] [PATCH v2] arm64: dts: rockchip: Add support for Khadas Edge/Edge-V/Captain boards

[Mark Kettenis]

> From: Paul Kocialkowski 
> Date: Tue, 18 Jun 2019 14:47:33 +0200
> 
> Hi Kever,
> 
> On Tue, 2019-06-18 at 18:08 +0800, Kever Yang wrote:
> > Hi Paul,
> > 
> > 
> > On 06/18/2019 05:03 PM, Paul Kocialkowski wrote:
> > > Hi,
> > > 
> > > On Tue, 2019-06-18 at 14:27 +0530, Jagan Teki wrote:
> > > > On Tue, Jun 18, 2019 at 1:55 PM Paul Kocialkowski
> > > >  wrote:
> > > > > Hi,
> > > > > 
> > > > > On Mon, 2019-06-17 at 15:24 +0800, xieqin...@gmail.com wrote:
> > > > > > From: Nick Xie 
> > > > > Was this tested with SPL support? I don't see DRAM configuration here
> > > > > so it seems that it relies on the non-free rockchip loader.
> > > > > 
> > > > > If that is the case, could you please indicate that in the commit
> > > > > message?
> > > > > 
> > > > > To maintainers: please do not merge this series before DRAM init and
> > > > > SPL support is available for these boards.
> > > > > 
> > > > > It seems that other RK3399 boards were merged without SPL support and
> > > > > sofar, I have the feeling that nobody cared to explain how we got into
> > > > > this broken situation. Please don't merge any more such board.
> > > > fyi: no rk3399 boards were merged w/o SPL. lpddr4 boards were merged
> > > > with TPL-enabled (which was discussed on the threads, if you remember)
> > > > with below boot chain.
> > > > 
> > > > rkbin (TPL) -> SPL -> U-Boot proper
> > > > 
> > > > Same case for this board as well.
> > > Here is a quote from Philipp Tomsich on the thread we discussed this:
> > > 
> > > " On some boards, there will be no TPL and only a SPL stage that will
> > > initialise DRAM (as the move to having TPL on the RK3399 is optional).
> > > 
> > > I agree with Paul that the DRAM init should be part of U-Boot whenever
> > > we add new boards and make an open DRAM init a prerequisite. "
> > > 
> > > So even if I frequently confuse SPL and TPL, it doesn't change the fact
> > > that no board should be merged without proper DRAM init.
> > > 
> > > Please stop pushing for merging these boards. I'm not sure what we
> > > should do about the boards that were merged already without DRAM init,
> > > but maybe they should be reverted.
> >
> > I don't think we have to have full DRAM init source code for each
> > board before we can merge it, I believe most of the board on U-Boot
> > mainline need to removed due to this rule. There are so many boards
> > from different vendor need a binary loader before U-Boot, and I can
> > see only very few drivers for dram at driver/ram/, and I believe rockchip
> > is already the most open vendor on this area.
> 
> Well, I am not talking about full DRAM init source code as in dynamic
> link training. I am talking about having at least static DRAM register
> configuration values, which is present for a good number of rockchip
> boards.
> 
> Of course, it would be best if Rockchip would consider releasing this
> source code, which would be the easiest and friendliest solution
> towards the community here. Are there internal discussions ongoing
> about this? If not, it would be greatly appreciated to start such
> discussions and clearly identify what the blocking points are.
> 
> > I won't use this rule to stop developers contribute there source code,
> 
> This is really sad and I think that Philipp was, like me, inclined to
> go towards the other direction.
> 
> > for a board support, we only need the board to have the full documentation
> > about how to setup and boot with upstream U-Boot. and I think the
> > most of people cares more about features in U-Boot proper. Everything
> > before U-Boot proper, you can use TPL/SPL or alternative to use binary
> > from vendor, as you can see all over the U-Boot mainline now, although
> > we encourage people to use full open source TPL/SPL.
> > Specifically for U-Boot Rockchip platform, I would like people to
> > support not only U-Boot
> > proper, but also for full SPL(ATF, OP-TEE support, itb image and other
> > features)
> > support. And for DRAM init,
> > - if this belongs to SPL for this board, you must implement it or else
> > SPL won't work;
> > - if this does not belong to SPL for this board, you need implement full
> > function SPL;
> > and you can either to have full function TPL with DRAM init(which is
> > prefered)
> > or alternatively use binary loader from vendor.
> 
> This is not really a technical argument here, more of a policy argument
> that ensures we have full free software support for the boards we
> support, and not only half-cooked support (that will most likely never
> be completed as soon as something that works gets merged). So it is a
> strategical decision, not a strictly pragmatic one.

While having full open source software support for boards is a noble
goal, I think there should be some room for pragmatism here.  A
significant number of u_boot targets rely on closed source components.
In the particular case of RK3399 the situation is better than for
other boards since you can combine the binary loader 

[U-Boot] [PATCH v1] x86: Revert "Don't set up MTRRs in SPL"

[Andy Shevchenko]

This breaks Intel Edison to work. It gets laggish and unable to boot kernel.

Reverts commit 665cb18ea64aabbeb03d27a4c92ddec1baccb87a for now
till better solution will be proposed.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/lib/init_helpers.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index ac85278cdf..0481f453ca 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -18,10 +18,7 @@ __weak ulong board_get_usable_ram_top(ulong total_size)
 
 int init_cache_f_r(void)
 {
-#if (CONFIG_IS_ENABLED(X86_32BIT_INIT) || \
- (!defined(CONFIG_SPL_BUILD) && \
-  !CONFIG_IS_ENABLED(CONFIG_X86_RUN_64BIT))) && \
-!defined(CONFIG_HAVE_FSP)
+#if CONFIG_IS_ENABLED(X86_32BIT_INIT) && !defined(CONFIG_HAVE_FSP)
int ret;
 
ret = mtrr_commit(false);
-- 
2.20.1

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

Re: [U-Boot] [U-Boot-Custodians] [ANNOUNCEMENT] Switching to gitlab.denx.de

[Bin Meng]

On Tue, Jun 18, 2019 at 10:50 PM Wolfgang Denk  wrote:
>
> Dear Daniel,
>
> In message 
>  you 
> wrote:
> >
> > > All these steps have been completed by now.  All custodians should
> > > be able to access the new repositories now, and use all teh gitlab
> > > features that are enabled for this project (including CI runners).
> >
> > works for me and the MIPS repository, thanks.
>
> Thanks for the confirmation.
>
> > should we update the source links in MAINTAINERS file as well?
>
> Yes, of coure.  Volunteers welcome :-)
>

Here we go :)
http://patchwork.ozlabs.org/patch/1118071/

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

[U-Boot] [PATCH] MAINTAINERS: Update git repo links

[Bin Meng]

Update all git repo links with the new gitlab ones.

Signed-off-by: Bin Meng 
---

 MAINTAINERS | 106 ++--
 1 file changed, 53 insertions(+), 53 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e26eda..65e9a1f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -55,7 +55,7 @@ M:Alexey Brodkin 
 M: Eugeniy Paltsev 
 S: Maintained
 L: uboot-snps-...@synopsys.com
-T: git git://git.denx.de/u-boot-arc.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-arc
 F: arch/arc/
 F: board/synopsys/
 
@@ -84,7 +84,7 @@ F:drivers/mmc/snps_dw_mmc.c
 ARM
 M: Albert Aribaud 
 S: Maintained
-T: git git://git.denx.de/u-boot-arm.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-arm
 F: arch/arm/
 F: cmd/arm/
 
@@ -92,14 +92,14 @@ ARM ALTERA SOCFPGA
 M: Marek Vasut 
 M: Simon Goldschmidt 
 S: Maintainted
-T: git git://git.denx.de/u-boot-socfpga.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-socfpga
 F: arch/arm/mach-socfpga/
 
 ARM AMLOGIC SOC SUPPORT
 M: Neil Armstrong 
 S: Maintained
 L: u-boot-amlo...@groups.io
-T: git git://git.denx.de/u-boot-amlogic.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic
 F: arch/arm/mach-meson/
 F: arch/arm/include/asm/arch-meson/
 F: drivers/clk/meson/
@@ -153,7 +153,7 @@ M:  Stefano Babic 
 M: Fabio Estevam 
 R: NXP i.MX U-Boot Team 
 S: Maintained
-T: git git://git.denx.de/u-boot-imx.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-imx
 F: arch/arm/cpu/arm1136/mx*/
 F: arch/arm/cpu/arm926ejs/mx*/
 F: arch/arm/cpu/armv7/vf610/
@@ -174,7 +174,7 @@ F:  arch/arm/include/asm/arch-hi6220/
 ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K
 M: Stefan Roese 
 S: Maintained
-T: git git://git.denx.de/u-boot-marvell.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-marvell
 F: arch/arm/mach-kirkwood/
 F: arch/arm/mach-mvebu/
 F: drivers/ata/ahci_mvebu.c
@@ -188,7 +188,7 @@ F:  drivers/watchdog/orion_wdt.c
 ARM MARVELL PXA
 M: Marek Vasut 
 S: Maintained
-T: git git://git.denx.de/u-boot-pxa.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-pxa
 F: arch/arm/cpu/pxa/
 F: arch/arm/include/asm/arch-pxa/
 
@@ -217,7 +217,7 @@ N:  mediatek
 ARM MICROCHIP/ATMEL AT91
 M: Eugen Hristev 
 S: Maintained
-T: git git://git.denx.de/u-boot-atmel.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-atmel
 F: arch/arm/mach-at91/
 F: board/atmel/
 
@@ -234,7 +234,7 @@ ARM RENESAS RMOBILE/R-CAR
 M: Nobuhiro Iwamatsu 
 M: Marek Vasut 
 S: Maintained
-T: git git://git.denx.de/u-boot-sh.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-sh
 F: arch/arm/mach-rmobile/
 
 ARM ROCKCHIP
@@ -242,7 +242,7 @@ M:  Simon Glass 
 M: Philipp Tomsich 
 M: Kever Yang 
 S: Maintained
-T: git git://git.denx.de/u-boot-rockchip.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip
 F: arch/arm/include/asm/arch-rockchip/
 F: arch/arm/mach-rockchip/
 F: board/rockchip/
@@ -264,7 +264,7 @@ F:  tools/rkspi.c
 ARM SAMSUNG
 M: Minkyu Kang 
 S: Maintained
-T: git git://git.denx.de/u-boot-samsung.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-samsung
 F: arch/arm/mach-exynos/
 F: arch/arm/mach-s5pc1xx/
 F: arch/arm/cpu/armv7/s5p-common/
@@ -289,7 +289,7 @@ F:  arch/arm/include/asm/arch-sti*/
 ARM STM SPEAR
 #M:Vipin Kumar 
 S: Orphaned (Since 2016-02)
-T: git git://git.denx.de/u-boot-stm.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-stm
 F: arch/arm/cpu/arm926ejs/spear/
 F: arch/arm/include/asm/arch-spear/
 
@@ -326,7 +326,7 @@ ARM SUNXI
 M: Jagan Teki 
 M: Maxime Ripard 
 S: Maintained
-T: git git://git.denx.de/u-boot-sunxi.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi
 F: arch/arm/cpu/armv7/sunxi/
 F: arch/arm/include/asm/arch-sunxi/
 F: arch/arm/mach-sunxi/
@@ -335,14 +335,14 @@ F:board/sunxi/
 ARM TEGRA
 M: Tom Warren 
 S: Maintained
-T: git git://git.denx.de/u-boot-tegra.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-tegra
 F: arch/arm/mach-tegra/
 F: arch/arm/include/asm/arch-tegra*/
 
 ARM TI
 M: Tom Rini 
 S: Maintained
-T: git git://git.denx.de/u-boot-ti.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-ti
 F: arch/arm/mach-davinci/
 F: arch/arm/mach-k3/
 F: arch/arm/mach-keystone/
@@ -352,7 +352,7 @@ F:  arch/arm/include/asm/ti-common/
 ARM UNIPHIER
 M: Masahiro Yamada 
 S: Maintained
-T: git git://git.denx.de/u-boot-uniphier.git
+T: git https://gitlab.denx.de/u-boot/custodians/u-boot-uniphier
 F: arch/arm/mach-uniphier/
 F: 

Re: [U-Boot] [PATCH] pinctrl: renesas: Synchronize Gen2/Gen3 tables with Linux 5.2-rc5

[Eugeniu Rosca]

Hi Stephen,

Many thanks for your feedback.

On Tue, Jun 18, 2019 at 03:17:39PM +0100, Stephen Finucane wrote:
> On Tue, 2019-06-18 at 13:47 +0200, Eugeniu Rosca wrote:
> > Jeremy, Stephen,
> > cc: Tom
> > 
> > FYI, another patchwork glitch is apparently showing up in
> > https://patchwork.ozlabs.org/patch/1117783/ , where none of the
> > messages visible in https://marc.info/?t=15607865572=1=4 is
> > being rendered.
> 
> Looking at [1], it seems this is base64 encoded.

Is this concluded from the non-ASCII format of the mbox file returned by
https://marc.info? FWIW, my other U-Boot contributions look similar:
https://marc.info/?l=u-boot=155862561809782=mbox
https://marc.info/?l=u-boot=155680022731874=mbox

Nevertheless, patchwork didn't experience issues displaying the
subsequent replies in those threads.

> Did you send this with
> 'git-send-email' and, if so, did you do anything funky?

I did use 'git' to submit all the above patches passing the usual
parameters: `git send-email --to A --to B --cc C my.patch`.

FWIW, u-boot-boun...@lists.denx.de replied below to [1]:

 ---8<
 Your message to U-Boot awaits moderator approval
 Your mail to 'U-Boot' with the subject
[PATCH] pinctrl: renesas: Synchronize Gen2/Gen3 tables with Linux 5.2-rc5

 Is being held until the list moderator can review it for approval.
 The reason it is being held:
Message body is too big: 192878 bytes with a limit of 100 KB
 Either the message will get posted to the list, or you will receive
 notification of the moderator's decision.  If you would like to cancel
 this posting, please visit the following URL:
 ---8<

Replicating the chronology of the issue, do you think it could be
related to 1) the patch size or to 2) the moderator's approval event?

  +--+
  |1. Patch sent |
  +--+---+
 |   
  +--v+
  |2. U-Boot reports awaiting moderator's approval|
  |   (the patch does not show up in patchwork)   |
  +--++
 |   
  +--v---+
  |3. Reply A (not rendered by patchwork)|
  +--+---+
 |   
  +--v---+
  |4. Reply B (not rendered by patchwork)|
  +--+---+
 |   
  +--v-+
  |5. Patch approved by moderator  |
  |   (the patch shows up in patchwork)|
  +--+-+
 |   
  +--v---+
  |6. Reply C (rendered by patchwork)|
  +--+---+
 |
  +--v---+
  |7. Reply D (rendered by patchwork)|
  +--+

> I guess we
> could attempt to decode these, though that's arguably a new feature so
> I'm not sure if we could backport it to 'stable/2.1'. In any case,
> could you provide an mbox replete with all the headers so I can see if
> there are any heuristics we can use to identify these emails?

Do you mean https://patchwork.ozlabs.org/patch/1117783/mbox/ ?

> 
> Stephen
> 
> [1] https://marc.info/?l=u-boot=156085461011871=mbox

Thanks again!

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

[U-Boot] [PATCH 1/4 v3] net: add MDIO_MUX DM class

[Alexandru Marginean]

Adds a class for MDIO MUXes, which control access to a series of
downstream child MDIOs.
MDIO MUX drivers are required to implement a select function used to switch
between child buses.
MUX children are registered as MDIO buses and they can be used just like
regular MDIOs.

Signed-off-by: Alex Marginean 
---

Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server

 drivers/net/Kconfig|  12 +++
 include/dm/uclass-id.h |   1 +
 include/miiphy.h   |  20 
 net/Makefile   |   1 +
 net/mdio-mux-uclass.c  | 232 +
 5 files changed, 266 insertions(+)
 create mode 100644 net/mdio-mux-uclass.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 635f8d72c2..0dc26ac254 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -24,6 +24,18 @@ config DM_MDIO
  This is currently implemented in net/mdio-uclass.c
  Look in include/miiphy.h for details.
 
+config DM_MDIO_MUX
+   bool "Enable Driver Model for MDIO MUX devices"
+   depends on DM_MDIO
+   help
+ Enable driver model for MDIO MUX devices
+
+ Adds UCLASS_MDIO_MUX DM class supporting MDIO MUXes.  Useful for
+ systems that support DM_MDIO and integrate one or multiple muxes on
+ the MDIO bus.
+ This is currently implemented in net/mdio-mux-uclass.c
+ Look in include/miiphy.h for details.
+
 config MDIO_SANDBOX
depends on DM_MDIO && SANDBOX
default y
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 90667e62cf..b859a9ec04 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -59,6 +59,7 @@ enum uclass_id {
UCLASS_MAILBOX, /* Mailbox controller */
UCLASS_MASS_STORAGE,/* Mass storage device */
UCLASS_MDIO,/* MDIO bus */
+   UCLASS_MDIO_MUX,/* MDIO MUX/switch */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/miiphy.h b/include/miiphy.h
index e6dd441983..9b97d09f18 100644
--- a/include/miiphy.h
+++ b/include/miiphy.h
@@ -167,4 +167,24 @@ struct phy_device *dm_mdio_phy_connect(struct udevice 
*dev, int addr,
 
 #endif
 
+#ifdef CONFIG_DM_MDIO_MUX
+
+/* indicates none of the child buses is selected */
+#define MDIO_MUX_SELECT_NONE   -1
+
+/**
+ * struct mdio_mux_ops - MDIO MUX operations
+ *
+ * @select: Selects a child bus
+ * @deselect: Clean up selection.  Optional, can be NULL
+ */
+struct mdio_mux_ops {
+   int (*select)(struct udevice *mux, int cur, int sel);
+   int (*deselect)(struct udevice *mux, int sel);
+};
+
+#define mdio_mux_get_ops(dev) ((struct mdio_mux_ops *)(dev)->driver->ops)
+
+#endif
+
 #endif
diff --git a/net/Makefile b/net/Makefile
index 6251ff3991..826544f05f 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -16,6 +16,7 @@ else
 obj-$(CONFIG_NET)  += eth_legacy.o
 endif
 obj-$(CONFIG_DM_MDIO)  += mdio-uclass.o
+obj-$(CONFIG_DM_MDIO_MUX) += mdio-mux-uclass.o
 obj-$(CONFIG_NET)  += eth_common.o
 obj-$(CONFIG_CMD_LINK_LOCAL) += link_local.o
 obj-$(CONFIG_NET)  += net.o
diff --git a/net/mdio-mux-uclass.c b/net/mdio-mux-uclass.c
new file mode 100644
index 00..e3fe12a531
--- /dev/null
+++ b/net/mdio-mux-uclass.c
@@ -0,0 +1,232 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MDIO_MUX_CHILD_DRV_NAME"mdio-mux-bus-drv"
+
+/**
+ * struct mdio_mux_perdev_priv - Per-device class data for MDIO MUX DM
+ *
+ * @parent_mdio: Parent DM MDIO device, this is called for actual MDIO I/O 
after
+ *   setting up the mux.  Typically this is a real MDIO device,
+ *   unless there are cascaded muxes.
+ * @selected:Current child bus selection.  Defaults to -1
+ */
+struct mdio_mux_perdev_priv {
+   struct udevice *mdio_parent;
+   int selected;
+};
+
+/*
+ * This source file uses three types of devices, as follows:
+ * - mux is the hardware MDIO MUX which selects between the existing child MDIO
+ * buses, this is the device relevant for MDIO MUX class of drivers.
+ * - ch is a child MDIO bus, this is just a representation of an mux selection,
+ * not a real piece of hardware.
+ * - mdio_parent is the actual MDIO bus called to perform reads/writes  after
+ * the MUX is configured.  Typically this is a real MDIO device, unless there
+ * are cascaded muxes.
+ */
+
+/**
+ * struct mdio_mux_ch_data - Per-device data for child MDIOs
+ *
+ * @sel: Selection value used by the MDIO MUX to access this child MDIO bus
+ */
+struct mdio_mux_ch_data {
+   int sel;
+};
+
+static struct udevice *mmux_get_parent_mdio(struct udevice *mux)
+{
+   struct mdio_mux_perdev_priv *pdata = dev_get_uclass_priv(mux);
+
+   return 

[U-Boot] [PATCH 2/4 v3] doc: bindings: Add description for MDIO MUX dts nodes

[Alexandru Marginean]

Adds a short bindings document describing the expected structure of a MDIO
MUX dts node.  This is based on Linux binding and the example is in fact
copied from there.

Signed-off-by: Alex Marginean 
---

Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server

 doc/device-tree-bindings/net/mdio-mux.txt | 61 +++
 1 file changed, 61 insertions(+)
 create mode 100644 doc/device-tree-bindings/net/mdio-mux.txt

diff --git a/doc/device-tree-bindings/net/mdio-mux.txt 
b/doc/device-tree-bindings/net/mdio-mux.txt
new file mode 100644
index 00..fdf817fd93
--- /dev/null
+++ b/doc/device-tree-bindings/net/mdio-mux.txt
@@ -0,0 +1,61 @@
+The expected structure of an MDIO MUX device tree node is described here.  This
+is heavily based on current Linux specification.
+The MDIO buses downstream of the MUX should be described in the device tree as
+child nodes as indicated below.
+
+Required properties:
+mdio-parent-bus = a phandle to the MDIO bus used to perform actual I/O.  This 
is
+  typically a real MDIO device, unless there are cascaded 
MUXes.
+#address-cells = <1>, each MDIO group is identified by one 32b value.
+#size-cells = <0>
+
+Other properties:
+The properties described here are sufficient for MDIO MUX DM class code, but
+MUX drivers may define additional properties, either required or optional.
+
+Required properties in child nodes:
+reg = value to be configured on the MUX to select the respective downstream
+  MDIO.
+
+Child nodes should normally contain PHY nodes, referenced by phandle from
+ethernet nodes of the eth interfaces using these PHYs.
+
+Example structure, extracted from Linux bindings document:
+
+   /* The parent MDIO bus. */
+   smi1: mdio@118001900 {
+   compatible = "cavium,octeon-3860-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x11800 0x1900 0x0 0x40>;
+   };
+
+   /*
+  An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a
+  pair of GPIO lines.  Child busses 2 and 3 populated with 4
+  PHYs each.
+*/
+   mdio-mux {
+   compatible = "mdio-mux-gpio";
+   gpios = < 3 0>, < 4 0>;
+   mdio-parent-bus = <>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mdio@2 {
+   reg = <2>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   phy11: ethernet-phy@1 {
+   reg = <1>;
+   marvell,reg-init = <3 0x10 0 0x5777>,
+   <3 0x11 0 0x00aa>,
+   <3 0x12 0 0x4105>,
+   <3 0x13 0 0x0a60>;
+   interrupt-parent = <>;
+   interrupts = <10 8>; /* Pin 10, active low */
+   };
+   };
+   };
+
-- 
2.17.1

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

[U-Boot] [PATCH 3/4 v3] test: dm_mdio: add a 2nd register to the emulated PHY

[Alexandru Marginean]

This 2nd register is used by the follow-up MDIO MUX test.

Signed-off-by: Alex Marginean 
---

Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server

 drivers/net/mdio_sandbox.c | 16 +---
 test/dm/mdio.c |  3 +++
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
index 07515e078c..df053f5381 100644
--- a/drivers/net/mdio_sandbox.c
+++ b/drivers/net/mdio_sandbox.c
@@ -9,11 +9,11 @@
 #include 
 
 #define SANDBOX_PHY_ADDR   5
-#define SANDBOX_PHY_REG0
+#define SANDBOX_PHY_REG_CNT2
 
 struct mdio_sandbox_priv {
int enabled;
-   u16 reg;
+   u16 reg[SANDBOX_PHY_REG_CNT];
 };
 
 static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int reg)
@@ -27,10 +27,10 @@ static int mdio_sandbox_read(struct udevice *dev, int addr, 
int devad, int reg)
return -ENODEV;
if (devad != MDIO_DEVAD_NONE)
return -ENODEV;
-   if (reg != SANDBOX_PHY_REG)
+   if (reg < 0 || reg > SANDBOX_PHY_REG_CNT)
return -ENODEV;
 
-   return priv->reg;
+   return priv->reg[reg];
 }
 
 static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int 
reg,
@@ -45,10 +45,10 @@ static int mdio_sandbox_write(struct udevice *dev, int 
addr, int devad, int reg,
return -ENODEV;
if (devad != MDIO_DEVAD_NONE)
return -ENODEV;
-   if (reg != SANDBOX_PHY_REG)
+   if (reg < 0 || reg > SANDBOX_PHY_REG_CNT)
return -ENODEV;
 
-   priv->reg = val;
+   priv->reg[reg] = val;
 
return 0;
 }
@@ -56,8 +56,10 @@ static int mdio_sandbox_write(struct udevice *dev, int addr, 
int devad, int reg,
 static int mdio_sandbox_reset(struct udevice *dev)
 {
struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+   int i;
 
-   priv->reg = 0;
+   for (i = 0; i < SANDBOX_PHY_REG_CNT; i++)
+   priv->reg[i] = 0;
 
return 0;
 }
diff --git a/test/dm/mdio.c b/test/dm/mdio.c
index 5b66255f7d..dc229aed6d 100644
--- a/test/dm/mdio.c
+++ b/test/dm/mdio.c
@@ -13,6 +13,9 @@
 
 /* macros copied over from mdio_sandbox.c */
 #define SANDBOX_PHY_ADDR   5
+#define SANDBOX_PHY_REG_CNT2
+
+/* test using 1st register, 0 */
 #define SANDBOX_PHY_REG0
 
 #define TEST_REG_VALUE 0xabcd
-- 
2.17.1

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

[U-Boot] [PATCH 4/4 v3] test: dm: add a test for MDIO MUX DM uclass

[Alexandru Marginean]

Adds a test using a makeshift MDIO MUX.  The test is based on the existing
MDIO test.  It uses the last emulated PHY register to verify MUX selection.

Signed-off-by: Alex Marginean 
---

Changes in v2:
- no change
Changes in v3:
- no change, just fighting with the email server

 arch/Kconfig   |  1 +
 arch/sandbox/dts/test.dts  | 21 +++-
 drivers/net/Kconfig| 10 
 drivers/net/Makefile   |  1 +
 drivers/net/mdio_mux_sandbox.c | 97 ++
 test/dm/Makefile   |  1 +
 test/dm/mdio_mux.c | 80 
 7 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 drivers/net/mdio_mux_sandbox.c
 create mode 100644 test/dm/mdio_mux.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 1e62a7615d..1a0f1ab8a7 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -122,6 +122,7 @@ config SANDBOX
imply PCH
imply PHYLIB
imply DM_MDIO
+   imply DM_MDIO_MUX
 
 config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dd50a951a8..a05e437abf 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -808,7 +808,26 @@
dma-names = "m2m", "tx0", "rx0";
};
 
-   mdio-test {
+   /*
+* keep mdio-mux ahead of mdio, u-boot doesn't do reference count on
+* these devices and we don't want mdio-parent-bus to be released before
+* the mux.
+*/
+   mdio-mux-test {
+   compatible = "sandbox,mdio-mux";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   mdio-parent-bus = <>;
+
+   mdio-ch-test@0 {
+   reg = <0>;
+   };
+   mdio-ch-test@1 {
+   reg = <1>;
+   };
+   };
+
+   mdio: mdio-test {
compatible = "sandbox,mdio";
};
 };
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 0dc26ac254..403df5e960 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -46,6 +46,16 @@ config MDIO_SANDBOX
 
  This driver is used in for testing in test/dm/mdio.c
 
+config MDIO_MUX_SANDBOX
+   depends on DM_MDIO_MUX && MDIO_SANDBOX
+   default y
+   bool "Sandbox: Mocked MDIO-MUX driver"
+   help
+ This driver implements dummy select/deselect ops mimicking a MUX on
+ the MDIO bux.  It uses mdio_sandbox driver as parent MDIO.
+
+ This driver is used for testing in test/dm/mdio.c
+
 menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 40038427db..a3706ca27b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
 obj-y += mscc_eswitch/
 obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
 obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
+obj-$(CONFIG_MDIO_MUX_SANDBOX) += mdio_mux_sandbox.o
diff --git a/drivers/net/mdio_mux_sandbox.c b/drivers/net/mdio_mux_sandbox.c
new file mode 100644
index 00..3dba4d18a1
--- /dev/null
+++ b/drivers/net/mdio_mux_sandbox.c
@@ -0,0 +1,97 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include 
+#include 
+#include 
+
+/* macros copied over from mdio_sandbox.c */
+#define SANDBOX_PHY_ADDR   5
+#define SANDBOX_PHY_REG_CNT2
+
+struct mdio_mux_sandbox_priv {
+   int enabled;
+   int sel;
+};
+
+static int mdio_mux_sandbox_mark_selection(struct udevice *dev, int sel)
+{
+   struct udevice *mdio;
+   struct mdio_ops *ops;
+   int err;
+
+   /*
+* find the sandbox parent mdio and write a register on the PHY there
+* so the mux test can verify selection.
+*/
+   err = uclass_get_device_by_name(UCLASS_MDIO, "mdio-test", );
+   if (err)
+   return err;
+   ops = mdio_get_ops(mdio);
+   return ops->write(mdio, SANDBOX_PHY_ADDR, MDIO_DEVAD_NONE,
+ SANDBOX_PHY_REG_CNT - 1, (u16)sel);
+}
+
+static int mdio_mux_sandbox_select(struct udevice *dev, int cur, int sel)
+{
+   struct mdio_mux_sandbox_priv *priv = dev_get_priv(dev);
+
+   if (!priv->enabled)
+   return -ENODEV;
+
+   if (cur != priv->sel)
+   return -EINVAL;
+
+   priv->sel = sel;
+   mdio_mux_sandbox_mark_selection(dev, priv->sel);
+
+   return 0;
+}
+
+static int mdio_mux_sandbox_deselect(struct udevice *dev, int sel)
+{
+   struct mdio_mux_sandbox_priv *priv = dev_get_priv(dev);
+
+   if (!priv->enabled)
+   return -ENODEV;
+
+   if (sel != priv->sel)
+   return -EINVAL;
+
+   priv->sel = -1;
+   mdio_mux_sandbox_mark_selection(dev, priv->sel);
+
+   return 0;
+}
+
+static const struct mdio_mux_ops mdio_mux_sandbox_ops = {
+   .select =