Re: [U-Boot] [PATCH v5 7/8] board: intel: Add new slimbootloader board

[Bin Meng]

Hi Aiden,

On Wed, Jul 24, 2019 at 11:18 AM Park, Aiden  wrote:
>
> Hi Andy,
>
> > -Original Message-
> > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > Sent: Tuesday, July 23, 2019 5:27 AM
> > To: Bin Meng 
> > Cc: Park, Aiden ; U-Boot Mailing List  > b...@lists.denx.de>; Simon Glass 
> > Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board
> >
> > On Tue, Jul 23, 2019 at 9:15 AM Bin Meng  wrote:
> > > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko
> > >  wrote:
> > > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden  
> > > > wrote:
> >
> > > > >  board/intel/slimbootloader/README   | 133 
> > > > > 
> > > >
> > > > Shouldn't become reST one?
> > >
> > > I think this will need be converted to reST after my doc series are 
> > > applied.
> >
> > I had an impression that reST conversion is targeting 2019.10. It means in 
> > your
> > branch you will have it applied earlier.
> >
> Let me change this to reST if necessary.
> Hi Bin, do you want me to change this one to reST or later? Let me know.

I have no preference. You can either convert to reST later, or rebase
on top of this series to get it converted to reST now:
http://patchwork.ozlabs.org/project/uboot/list/?series=120139

>
> > > > > +int board_early_init_r(void)
> > > > > +{
> > > > > +   /*
> > > > > +* Make sure PCI bus is enumerated so that peripherals on the 
> > > > > PCI bus
> > > > > +* can be discovered by their drivers
> > > > > +*/
> > > > > +   pci_init();
> > > >
> > > > I'm not sure this is how U-Boot is designed with DM.
> > > > At least my expectations that bus gets initialized followed by the
> > > > certain driver in a lazy way.
> > > > Isn't it the case? Bin?
> > >
> > > For most x86 board, yes, PCI gets enumerated automatically if some PCI
> > > APIs are called in the early initialization codes: eg: pci_{read,
> > > write}_config().
> > >
> > > But for boards like coreboot/slimbootloader, if there is no touch to
> > > any PCI config register on that board in the early phase, PCI bus
> > > remains not probed.
> >
> > Thanks for explanation!
> > Perhaps this needs a comment in the code.
> >
> Thanks Bin for your explanation. Slim Bootloader have done PCI config space 
> setup
> and PCI device enumeration in Slim Bootloader stages.
>

Yes, and we should not re-program registers like BARs in U-Boot to
avoid mismatch, so that's why in coreboot/slimbootloader defconfig we
have:
# CONFIG_PCI_PNP is not set

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

Re: [U-Boot] [PATCH 00/50] doc: Shape into useful HTML docs

[Bin Meng]

Hi Tom,

On Tue, Jul 23, 2019 at 11:29 PM Tom Rini  wrote:
>
> On Tue, Jul 23, 2019 at 05:00:52PM +0200, Wolfgang Denk wrote:
> > Dear Bin,
> >
> > In message 
> >  you 
> > wrote:
> > >
> > > > @Wolfgang, is it possible to host the Sphinx HTML docs on denx.de?
> > > >
> > > > This series is available at u-boot-x86/doc for testing.
> > > >
> > >
> > > Ping?
> >
> > Yes, this is possible.  Where can I find the HTML files?  And where
> > would you want to put them?  And what is the planned update
> > strategy?
> >
> > I mean, plain HTML documents are a bit lame, as they refer to a
> > specific version of U-Boot only.  What if I want to see the docs for
> > a version of half a year ago?
>
> Thinking out loud, how about ...// and we re-generate the docs
> for each full release?

If I understand correctly, you were proposing exact the same thing as
I thought, so something like:

http://denx.de/u-boot/doc/html/v2018.07/
http://denx.de/u-boot/doc/html/v2019.10-rc1/
http://denx.de/u-boot/doc/html/latest/

Anyway these are doc update strategy and has nothing to do with the
patch series itself. If no issues, could you please apply them?
I am afraid the longer time it sits in the patch queue, the
possibility of merge conflicts happen.

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

Re: [U-Boot] [PATCH 00/50] doc: Shape into useful HTML docs

[Bin Meng]

Hi Wolfgang,

On Tue, Jul 23, 2019 at 11:01 PM Wolfgang Denk  wrote:
>
> Dear Bin,
>
> In message 
>  you 
> wrote:
> >
> > > @Wolfgang, is it possible to host the Sphinx HTML docs on denx.de?
> > >
> > > This series is available at u-boot-x86/doc for testing.
> > >
> >
> > Ping?
>
> Yes, this is possible.  Where can I find the HTML files?  And where

The HTML files can be generated from the U-Boot source tree by "make htmldocs".

> would you want to put them?  And what is the planned update
> strategy?

If possible, can we have denx.de or gitlab.denx.de host the generated HTML docs?

>
> I mean, plain HTML documents are a bit lame, as they refer to a
> specific version of U-Boot only.  What if I want to see the docs for
> a version of half a year ago?
>
> What exactly are your plans?

For versioned HTML, let's take a look at how Linux kernel does:
https://www.kernel.org/doc/html/

I think we can imitate Linux by having released doc archive (generated
for each release), latest doc which is nightly built that always
points to latest htmldocs in the tree. Maybe we can have additional
-rc release doc for current release (eg: v2019.10-rc1), and these -rc
htmldocs will get cleaned up when the official release is out.
Thoughts?

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

Re: [U-Boot] [PATCH] mmd: sdhci: fix non GPIO card detect

[Baruch Siach]

Hi Peng,

On Wed, Jul 24, 2019 at 01:17:49AM +, Peng Fan wrote:
> > Subject: Re: [PATCH] mmd: sdhci: fix non GPIO card detect
> > On Tue, Jul 23, 2019 at 04:47:47PM +0530, Faiz Abbas wrote:
> > > On 23/07/19 4:16 PM, Baruch Siach wrote:
> > > > On Tue, Jul 23, 2019 at 03:35:31PM +0530, Faiz Abbas wrote:
> > > >> On 23/07/19 2:39 PM, Baruch Siach wrote:
> > > >>> On Tue, Jul 23, 2019 at 02:27:28PM +0530, Faiz Abbas wrote:
> > >  On 23/07/19 1:30 PM, Peng Fan wrote:
> > > > + Faiz
> > > >
> > > >> Subject: [PATCH] mmd: sdhci: fix non GPIO card detect
> > > >>
> > > >> Some SD cards do not assert the SDHCI_CARD_PRESENT bit. Only
> > > >> the SDHCI_CARD_DETECT_PIN_LEVEL is enabled. Consider that
> > > >> enough for card detect indication.
> > > >>
> > > >> This fixes SD card access from SPL, since DM_GPIO is not
> > > >> available in SPL code.
> > > >>
> > > >> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
> > > >> Cc: T Karthik Reddy 
> > > >> Cc: Michal Simek 
> > > >> Signed-off-by: Baruch Siach 
> > > >> ---
> > > >>  drivers/mmc/sdhci.c | 2 +-
> > > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >>
> > > >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> > > >> 2779bca93f08..17a28181fcca 100644
> > > >> --- a/drivers/mmc/sdhci.c
> > > >> +++ b/drivers/mmc/sdhci.c
> > > >> @@ -683,7 +683,7 @@ int sdhci_get_cd(struct udevice *dev)
> > > >>}
> > > >>  #endif
> > > >>value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> > > >> - SDHCI_CARD_PRESENT);
> > > >> + (SDHCI_CARD_PRESENT |
> > SDHCI_CARD_DETECT_PIN_LEVEL));
> > > >
> > > > Faiz, are you fine with this change?
> > > 
> > >  Not really. The spec is pretty clear that DETECT_PIN_LEVEL is not
> > >  to be trusted. Also how does the CARD_PRESENT assertion depend on
> > >  the SD card you use? Are you normally muxing the SDCD line to the
> > >  IP (for hardware to detect) or are you connecting it as a gpio which
> > software must detect?
> > > >>>
> > > >>> I tested SanDisk 8GB SD card, class 10, UHS1, on Armada 388 based
> > > >>> SolidRun Clearfog Base. The SDHCI_PRESENT_STATE register
> > > >>> consistently reads 0x01f6, that is, CARD_PRESENT is disabled,
> > DETECT_PIN_LEVEL is enabled.
> > > >>>
> > > >>> The SD card-detect GPIO is present at the hardware level, but it
> > > >>> is not accessible from SPL code because there is currently no
> > > >>> SPL_DM_GPIO. The main U-Boot image detects the SD card correctly
> > > >>> (once the other MMC patches I posted are applied).
> > > >>>
> > > >>> Without this patch boot from SD card is broken. What is the right fix
> > then?
> > > >>
> > > >> There are two choices to implement card detect:
> > > >>
> > > >> 1. Mux the card detect line from the SD card cage directly to the
> > > >> host controller and expect PRESENT state register to indicate
> > > >> whether card is present or not.
> > > >>
> > > >> 2. Mux the card detect line as a GPIO and use software
> > > >> (dm_gpio_get_value() call) to detect whether card is present or
> > > >> not. In that case, PRESENT_STATE[16,17,18] are completely useless
> > > >> because there is no card detect line going into the IP.
> > > >>
> > > >> It seems that you are using #2. What confuses me is how any cards
> > > >> are able to assert CARD_DETECT.
> > > >
> > > > As far as I can see the Armada 388 SD host controller does not
> > > > provide option #1. The Clearfog indeed uses option #2. Until commit
> > da18c62b6e6a4 ("mmc:
> > > > sdhci: Implement SDHCI card detect") it used to work because the
> > > > mv_sdhci driver does not implement the get_cd callback, so
> > > > card-detect was ignored. Now we have a get_cd implementation at the
> > > > sdhci level that returns 0 in SPL because the GPIO is not accessible.
> > > >
> > > > What would you suggest?
> > >
> > > You can just add your own get_cd() callback instead of using 
> > > sdhci_get_cd().
> > 
> > I can do that, but I would still hit the basic problem. GPIOs are not 
> > accessible
> > from SPL when DM is enabled. I guess that would affect a few other
> > platforms.
> > 
> > How about making an exception for SPL? Something like this:
> > 
> > diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> > 654931a82f54..03c132631d23 100644
> > --- a/drivers/mmc/sdhci.c
> > +++ b/drivers/mmc/sdhci.c
> > @@ -672,6 +672,9 @@ int sdhci_get_cd(struct udevice *dev)
> > /* If polling, assume that the card is always present. */
> > if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
> > return 1;
> > +   /* In SPL we have no DM_GPIO access; assume card is present */
> 
> I think this assumption is wrong. It is not always true the DM_GPIO not
> enabled in SPL.

How can you enable DM_GPIO in SPL?

The dm_gpio_get_value() code is under CONFIG_IS_ENABLED(DM_GPIO). The 

[U-Boot] [PATCH v11 4/4] doc: sifive-fu540: Update README to explicitly load DTB for Linux

[Anup Patel]

We should explicitly load DTB from TFTP server or MMC/SD card
for Linux booting. This will allow us:
1. To use different Linux DTB for SiFive Unleashed board with
   expansion board connected.
2. Avoid re-flashing OpenSBI firmware whenever board connections
   change.

This patch updates reference bootlog in SiFive FU540 README
as-per above.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Reviewed-by: Joe Hershberger 
---
 doc/README.sifive-fu540 | 317 
 1 file changed, 191 insertions(+), 126 deletions(-)

diff --git a/doc/README.sifive-fu540 b/doc/README.sifive-fu540
index 944ba1c8a0..a106c9206f 100644
--- a/doc/README.sifive-fu540
+++ b/doc/README.sifive-fu540
@@ -59,41 +59,64 @@ Once you plugin the sdcard and power up, you should see the 
U-Boot prompt.
 
 Sample boot log from HiFive Unleashed board
 ===
-U-Boot 2019.07-rc4-00013-g1837f893b0 (Jun 20 2019 - 11:08:48 +0530)
+U-Boot 2019.07-00024-g350ff02f5b (Jul 22 2019 - 11:45:02 +0530)
 
 CPU:   rv64imafdc
 Model: SiFive HiFive Unleashed A00
 DRAM:  8 GiB
+MMC:   spi@1005:mmc@0: 0
 In:serial@1001
 Out:   serial@1001
 Err:   serial@1001
 Net:   eth0: ethernet@1009
 Hit any key to stop autoboot:  0
 => version
-U-Boot 2019.07-rc4-00013-g1837f893b0 (Jun 20 2019 - 11:08:48 +0530)
+U-Boot 2019.07-00024-g350ff02f5b (Jul 22 2019 - 11:45:02 +0530)
 
 riscv64-linux-gcc.br_real (Buildroot 2018.11-rc2-3-ga0787e9) 8.2.0
 GNU ld (GNU Binutils) 2.31.1
-=>
-===
+=> mmc info
+Device: spi@1005:mmc@0
+Manufacturer ID: 3
+OEM: 5344
+Name: SU08G
+Bus Speed: 2000
+Mode: SD Legacy
+Rd Block Len: 512
+SD version 2.0
+High Capacity: Yes
+Capacity: 7.4 GiB
+Bus Width: 1-bit
+Erase Group Size: 512 Bytes
+=> mmc part
 
-Now you can configure your networking, tftp server and use tftp boot method to
-load uImage.
+Partition Map for MMC device 0  --   Partition Type: EFI
 
-==
-=> setenv ipaddr 10.206.5.241
+PartStart LBA   End LBA Name
+Attributes
+Type GUID
+Partition GUID
+  1 0x0800  0x000107ff  "bootloader"
+attrs:  0x
+type:   2e54b353-1271-4842-806f-e436d6af6985
+guid:   393bbd36-7111-491c-9869-ce24008f6403
+  2 0x00040800  0x00ecdfde  ""
+attrs:  0x
+type:   0fc63daf-8483-4772-8e79-3d69d8477de4
+guid:   7fc9a949-5480-48c7-b623-04923080757f
+=> setenv ipaddr 10.206.7.133
 => setenv netmask 255.255.252.0
 => setenv serverip 10.206.4.143
 => setenv gateway 10.206.4.1
-=> tftpboot ${kernel_addr_r} /sifive/fu540/uImage
+=> tftpboot ${kernel_addr_r} /sifive/fu540/Image
 ethernet@1009: PHY present at 0
 ethernet@1009: Starting autonegotiation...
 ethernet@1009: Autonegotiation complete
-ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x7c00)
+ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x3c00)
 Using ethernet@1009 device
-TFTP from server 10.206.4.143; our IP address is 10.206.5.241
-Filename '/sifive/fu540/uImage'.
-Load address: 0x8060
+TFTP from server 10.206.4.143; our IP address is 10.206.7.133
+Filename '/sifive/fu540/Image'.
+Load address: 0x8400
 Loading: #
  #
  #
@@ -103,50 +126,77 @@ Loading: 
#
  #
  #
  #
- 
- 1.5 MiB/s
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ #
+ 

[U-Boot] [PATCH v11 2/4] net: macb: Fix check for little-endian system in gmac_configure_dma()

[Anup Patel]

Instead of depending on CONFIG_SYS_LITTLE_ENDIAN, we check at runtime
whether underlying system is little-endian or big-endian. This way
we are not dependent on any U-Boot specific OR compiler specific macro
to check system endianness.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Reviewed-by: Ramon Fried 
---
 drivers/net/macb.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index a2f5b7f813..956e688548 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -84,6 +84,8 @@ struct macb_dma_desc {
 struct macb_device {
void*regs;
 
+   boolis_big_endian;
+
const struct macb_config *config;
 
unsigned intrx_tail;
@@ -743,11 +745,10 @@ static void gmac_configure_dma(struct macb_device *macb)
dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
dmacfg &= ~GEM_BIT(ENDIA_PKT);
 
-#ifdef CONFIG_SYS_LITTLE_ENDIAN
-   dmacfg &= ~GEM_BIT(ENDIA_DESC);
-#else
+   if (macb->is_big_endian)
dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
-#endif
+   else
+   dmacfg &= ~GEM_BIT(ENDIA_DESC);
 
dmacfg &= ~GEM_BIT(ADDR64);
gem_writel(macb, DMACFG, dmacfg);
@@ -1222,6 +1223,8 @@ static int macb_eth_probe(struct udevice *dev)
 
macb->regs = (void *)pdata->iobase;
 
+   macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678);
+
macb->config = (struct macb_config *)dev_get_driver_data(dev);
if (!macb->config)
macb->config = _gem_config;
-- 
2.17.1

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

[U-Boot] [PATCH v11 3/4] riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support

[Anup Patel]

We typically use same set of distro images (yocto, debian, fedora, etc.)
on both QEMU RISC-V virt machine and SiFive Unleashed board.

With growing kernel and ramdisk images, we need to re-adjust default
U-Boot environment variables. The config header for QEMU RISC-V virt
machine has been already updated to handle bigger kernel and ramdisk
images hence this patch updates SiFive FU540 config header accordingly.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Reviewed-by: Joe Hershberger 
Reviewed-by: David Abdurachmanov 
Tested-by: David Abdurachmanov 
---
 include/configs/sifive-fu540.h | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/include/configs/sifive-fu540.h b/include/configs/sifive-fu540.h
index 7007b5f6af..858b7a7da1 100644
--- a/include/configs/sifive-fu540.h
+++ b/include/configs/sifive-fu540.h
@@ -18,12 +18,12 @@
 
 #define CONFIG_SYS_MALLOC_LEN  SZ_8M
 
-#define CONFIG_SYS_BOOTM_LEN   SZ_16M
+#define CONFIG_SYS_BOOTM_LEN   SZ_64M
 
 #define CONFIG_STANDALONE_LOAD_ADDR0x8020
 
 /* Environment options */
-#define CONFIG_ENV_SIZESZ_4K
+#define CONFIG_ENV_SIZESZ_128K
 
 #define BOOT_TARGET_DEVICES(func) \
func(DHCP, dhcp, na)
@@ -33,11 +33,15 @@
 #define CONFIG_EXTRA_ENV_SETTINGS \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-   "kernel_addr_r=0x8060\0" \
-   "fdt_addr_r=0x8220\0" \
-   "scriptaddr=0x8230\0" \
-   "pxefile_addr_r=0x8240\0" \
-   "ramdisk_addr_r=0x8250\0" \
+   "kernel_addr_r=0x8400\0" \
+   "fdt_addr_r=0x8800\0" \
+   "scriptaddr=0x8810\0" \
+   "pxefile_addr_r=0x8820\0" \
+   "ramdisk_addr_r=0x8830\0" \
BOOTENV
 
+#define CONFIG_PREBOOT \
+   "setenv fdt_addr ${fdtcontroladdr};" \
+   "fdt addr ${fdtcontroladdr};"
+
 #endif /* __CONFIG_H */
-- 
2.17.1

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

[U-Boot] [PATCH v11 0/4] Update SiFive Unleashed Drivers

[Anup Patel]

This series update SiFive Unleashed clock driver and Cadence MACB 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 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.

The updated DTB passed by OpenSBI is in fact the DTB build by upstream Linux
so we can straight away pass this DTB to Linux as well.

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

To try this series use latest OpenSBI at:
https://github.com/riscv/opensbi.git
And Linux-5.3-rc1 from v5.3-rc1_unleashed branch at:
https://github.com/avpatel/linux.git

Changes since v10:
- Addressed comments from Joe on MACB driver changes

Changes since v9:
- Remove all accepted and merged patches except MACB driver patches
- Rebased MACB driver patches upon v2 patches from Ramon Fried
  (Refer, https://www.mail-archive.com/u-boot@lists.denx.de/msg334300.html)
- Added separate patch to sync-up SiFive Unleashed config header with
  QEMU RISC-V virt machine config header
- Added separate patch for more updates to SiFive Unleashed README

Changes since v8:
- Removed probe() from macb_config for PATCH6
- Renamed set_tx_clk() to clk_init() in macb_config for PATCH6

Changes since v7:
- Update PATCH6 to not treat dma_burst_length = 0 as skip gmac_configure_dma()
- Update PATCH9 to check endianess at runtime

Changes since v6:
- Added separate patch to fix endianess check in gmac_configure_dma()

Changes since v5:
- Addressed Ramon's comments in PATCH6
- Addressed Bin's comments in PATCH7

Changes since v4:
- Rebased patches upon Ramon's MACB changes
  (Refer, https://patchwork.ozlabs.org/patch/1114025/)
- Added PATCH7 to setup ethaddr based on board serial number read from OTP
- Added PATCH8 to update documentation

Changes since v3:
- Extend MACB ethernet driver for SiFive Unleashed board (just like Linux)

Changes since v2:
- Dropped PATCH6 which adds new compatible string to MACB driver because
  more changes are required in MACB driver for different ethernet speeds

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

Anup Patel (4):
  net: macb: Extend MACB driver for SiFive Unleashed board
  net: macb: Fix check for little-endian system in gmac_configure_dma()
  riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support
  doc: sifive-fu540: Update README to explicitly load DTB for Linux

 doc/README.sifive-fu540| 317 -
 drivers/net/macb.c |  84 ++---
 include/configs/sifive-fu540.h |  18 +-
 3 files changed, 265 insertions(+), 154 deletions(-)

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

[U-Boot] [PATCH v11 1/4] net: macb: Extend MACB driver for SiFive Unleashed board

[Anup Patel]

The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
different TX clock for 1000mbps vs 10/100mbps.

This patch adds SiFive MACB compatible string and extends the MACB
ethernet driver to change TX clock using TX_CLK_SEL register for
SiFive MACB.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Reviewed-by: Ramon Fried 
---
 drivers/net/macb.c | 73 +++---
 1 file changed, 56 insertions(+), 17 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 92ec05559b..a2f5b7f813 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -83,7 +83,8 @@ struct macb_dma_desc {
 
 struct macb_device {
void*regs;
-   unsigned intdma_burst_length;
+
+   const struct macb_config *config;
 
unsigned intrx_tail;
unsigned inttx_head;
@@ -123,6 +124,8 @@ struct macb_device {
 
 struct macb_config {
unsigned intdma_burst_length;
+
+   int (*clk_init)(struct udevice *dev, ulong rate);
 };
 
 #ifndef CONFIG_DM_ETH
@@ -483,21 +486,38 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
  * when operation failed.
  */
 #ifdef CONFIG_DM_ETH
+static int macb_sifive_clk_init(struct udevice *dev, ulong rate)
+{
+   fdt_addr_t addr;
+   void *gemgxl_regs;
+
+   addr = dev_read_addr_index(dev, 1);
+   if (addr == FDT_ADDR_T_NONE)
+   return -ENODEV;
+
+   gemgxl_regs = (void __iomem *)addr;
+   if (!gemgxl_regs)
+   return -ENODEV;
+
+   /*
+* SiFive 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, gemgxl_regs);
+   return 0;
+}
+
 int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
 {
 #ifdef CONFIG_CLK
+   struct macb_device *macb = dev_get_priv(dev);
struct clk tx_clk;
ulong rate;
int ret;
 
-   /*
-* "tx_clk" is an optional clock source for MACB.
-* Ignore if it does not exist in DT.
-*/
-   ret = clk_get_by_name(dev, "tx_clk", _clk);
-   if (ret)
-   return 0;
-
switch (speed) {
case _10BASET:
rate = 250; /* 2.5 MHz */
@@ -513,6 +533,17 @@ int __weak macb_linkspd_cb(struct udevice *dev, unsigned 
int speed)
return 0;
}
 
+   if (macb->config->clk_init)
+   return macb->config->clk_init(dev, rate);
+
+   /*
+* "tx_clk" is an optional clock source for MACB.
+* Ignore if it does not exist in DT.
+*/
+   ret = clk_get_by_name(dev, "tx_clk", _clk);
+   if (ret)
+   return 0;
+
if (tx_clk.dev) {
ret = clk_set_rate(_clk, rate);
if (ret)
@@ -705,8 +736,9 @@ static void gmac_configure_dma(struct macb_device *macb)
dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
dmacfg |= GEM_BF(RXBS, buffer_size);
 
-   if (macb->dma_burst_length)
-   dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
+   if (macb->config->dma_burst_length)
+   dmacfg = GEM_BFINS(FBLDO,
+  macb->config->dma_burst_length, dmacfg);
 
dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
dmacfg &= ~GEM_BIT(ENDIA_PKT);
@@ -1169,15 +1201,15 @@ static int macb_enable_clk(struct udevice *dev)
 
 static const struct macb_config default_gem_config = {
.dma_burst_length = 16,
+   .clk_init = NULL,
 };
 
 static int macb_eth_probe(struct udevice *dev)
 {
-   const struct macb_config *macb_config;
struct eth_pdata *pdata = dev_get_platdata(dev);
struct macb_device *macb = dev_get_priv(dev);
const char *phy_mode;
-   __maybe_unused int ret;
+   int ret;
 
phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
   NULL);
@@ -1190,11 +1222,10 @@ static int macb_eth_probe(struct udevice *dev)
 
macb->regs = (void *)pdata->iobase;
 
-   macb_config = (struct macb_config *)dev_get_driver_data(dev);
-   if (!macb_config)
-   macb_config = _gem_config;
+   macb->config = (struct macb_config *)dev_get_driver_data(dev);
+   if (!macb->config)
+   macb->config = _gem_config;
 
-   macb->dma_burst_length = macb_config->dma_burst_length;
 #ifdef CONFIG_CLK
ret = macb_enable_clk(dev);
if (ret)
@@ -1257,6 +1288,12 @@ static int macb_eth_ofdata_to_platdata(struct udevice 
*dev)
 
 static const struct macb_config sama5d4_config = {
.dma_burst_length = 4,
+   .clk_init = NULL,
+};
+
+static const struct macb_config sifive_config = {
+   

Re: [U-Boot] [PATCH 00/18] autoboot: Tidy up autoboot code

[Simon Glass]

Hi Tom,

On Thu, 11 Jul 2019 at 07:04, Tom Rini  wrote:
>
> On Sun, May 05, 2019 at 03:53:24PM -0600, Simon Glass wrote:
>
> > This series cleans up autoboot.c a bit to:
> >
> > - Convert options to Kconfig
> > - Use C code instead of C preprocessor where possible
> > - Add a few comments
> >
> >
> > Simon Glass (18):
> >   main: Use conditional run_preboot_environment_command()
> >   Convert CONFIG_SHOW_BOOT_PROGRESS to Kconfig
> >   Add CONFIG_USE_PREBOOT to boards that use CONFIG_PREBOOT
> >   Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to Kconfig
> >   autoboot: Use CONFIG_AUTOBOOT_STOP_STR_SHA256 indirectly
> >   autoboot: Drop #ifdef for CONFIG_AUTOBOOT_ENCRYPTION
> >   autoboot: Improve docs for CONFIG_AUTOBOOT_ENCRYPTION
> >   autoboot: Use if() for CONFIG_SILENT_CONSOLE
> >   autoboot: Drop #ifdef CONFIG_AUTOBOOT_KEYED
> >   autoboot: Drop unused CONFIG_MENUPROMPT
> >   autoboot: Rename CONFIG_MENUKEY to CONFIG_AUTOBOOT_MENUKEY
> >   snow: Define CONFIG_AUTOBOOT_MENUKEY
> >   autoboot: Tidy up use of menukey
> >   autoboot: Rename CONFIG_MENU_SHOW to include AUTOBOOT
> >   Convert CONFIG_AUTOBOOT_MENU_SHOW to Kconfig
> >   autoboot: Add comments for menu_show()
> >   autoboot: Move a few more options from #ifdef to if()
> >   autoboot: Adjust the implementation in autoboot_command()
>
> Unfortunately this doesn't apply cleanly and needs a bit of work to make
> apply again, can you please rebase?  Thanks!

You probably saw, but I sent a v2 of this.

I have a little series to remove a bit more from common.h as well. If
that passes testing I'll send it in a few days.

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

[U-Boot] Please pull u-boot-dm (take 2)

[Simon Glass]

Hi Tom,

This includes the gitlab fix and also I updated ifwitool.c to drop the
unused inline functions.


The following changes since commit ff8c23e784f57a7098e91a200ed7f5a48612b653:

  Merge tag 'u-boot-stm32-20190723' of
https://gitlab.denx.de/u-boot/custodians/u-boot-stm (2019-07-23
14:16:21 -0400)

are available in the Git repository at:

  git://git.denx.de/u-boot-dm.git tags/dm-pull-23jul19-take2

for you to fetch changes up to 6e38047b66e37659b937cf301e0de37a90d9eaa2:

  dm: device: make power domain calls optional (2019-07-23 20:27:58 -0700)


Minor driver-model fixes and tweaks
A few device-tree fixes
Binman support for extracting files from an image


Anatolij Gustschin (1):
  dm: device: make power domain calls optional

Baruch Siach (2):
  dm: uclass: fix comment copy/paste error
  buildman: fix invocation examples typos

Bin Meng (4):
  dm: timer: Skip device that does not have a valid ofnode in pre_probe()
  dm: core: Call clk_set_defaults() during probe() only for a valid ofnode
  dm: core: Set correct "status" value for a node
  dm: Fix parameter description of dev_read_name()

Marek Vasut (1):
  common: fdt_support: Add missing cpu_to_fdt32() to fdt_pci_dma_ranges()

Masahiro Yamada (1):
  fdt: make fdt_get_base_address() return OF_BAD_ADDR when "reg" not found

Sekhar Nori (1):
  clk: initialize clk->data when using default xlate

Simon Glass (68):
  x86: Add ifwitool for Intel Integrated Firmware Image
  cbfs: Add an enum and comment for the magic number
  cbfs: Rename checksum to attributes_offset
  tools: Drop duplicate raise_on_error argument
  binman: Fix comment in bsection.GetEntries()
  binman: Correct two typos in function names in ftest
  binman: Add coverage tools info for Python 3
  patman: Add a way to set the search path for tools
  binman: Add a --toolpath option to set the tool search path
  binman: Add missing comments to bsection
  binman: Add missing comments toentry
  binman: Tidy up help for --indir
  binman: Use a better error for missing Intel descriptor
  binman: Detect skipped tests
  binman: Add a function to create a sample ELF file
  binman: Add a function to decode an ELF file
  binman: Ensure that coverage has access to site packages
  binman: Assume Intel descriptor is at the start of the image
  binman: Don't assume there is an ME region
  binman: Update entry.SetOffsetSize to be optional
  binman: Allow text directly in the node
  patman: Add functions to compress and decompress data
  binman: Use the tools.Decompress method
  binman: Drop unnecessary debug handling
  binman: Use tools compression function for blob handling
  binman: Correct comment in u_boot_spl_elf
  binman: Support ELF files for TPL
  binman: Fix up the _DoTestFile() function -u argument
  binman: Allow verbosity control when running tests
  binman: Allow preserving test directories
  binman: Pass the toolpath to tests
  patman: Add a function to write ifwitool
  binman: Add a utility library for coreboot CBFS
  binman: Add support for CBFS entries
  binman: Add support for Intel IFWI entries
  binman: Pad empty areas of the CBFS with files
  binman: Add support for fixed-offset files in CBFS
  binman: Simplify the entry test
  binman: Update future features
  binman: Update help for new features
  binman: Add a convenience functions for real-DTB tests
  binman: Add an FDT map
  binman: Add an image header
  binman: Convert to use ArgumentParser
  binman: Move compression into the Entry base class
  binman: Drop an unused arg in Entry.Lookup()
  binman: Allow easy importing of entry modules
  binman: Fix up ProcessUpdateContents error and comments
  binman: Call ProcessUpdateContents() consistently
  binman: Add a return value to ProcessContentsUpdate()
  binman: Add a control for post-pack entry expansion
  binman: Allow entries to expand after packing
  binman: Allow device-tree entries to be compressed
  binman: Provide the actual data address for cbfs files
  binman: Use the cbfs memlen field only for uncompressed length
  binman: Support FDT update for CBFS
  binman: Detect bad CBFS file types
  binman: Allow listing the entries in an image
  binman: Support locating an FDT map
  binman: Support locating an image header
  binman: Support reading an image into an Image object
  binman: Convert Image to a subclass of Entry
  binman: Support listing an image
  binman: Allow for logging information to be displayed
  binman: Allow reading an entry from an image
  binman: Support reading from CBFS entries
  binman: Add an 'extract' co

Re: [U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On Tue, 23 Jul 2019 at 20:23, Tom Rini  wrote:
>
> On Tue, Jul 23, 2019 at 08:08:03PM -0700, Simon Glass wrote:
> > Hi Tom,
> >
> > On Tue, 23 Jul 2019 at 11:16, Tom Rini  wrote:
> > >
> > > On Mon, Jul 22, 2019 at 08:48:45AM -0600, Simon Glass wrote:
> > >
> > > > Hi Tom,
> > > >
> > > > Build is here: https://travis-ci.org/sglass68/u-boot/builds/561552377
> > > >
> > > > The following changes since commit 
> > > > 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> > > >
> > > >   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > >   git://git.denx.de/u-boot-dm.git tags/dm-pull-22jul19
> > > >
> > > > for you to fetch changes up to 857ad7985ff63989c3c7feff56c2dc353d7d7c9a:
> > > >
> > > >   dm: device: make power domain calls optional (2019-07-20 19:50:44 
> > > > -0600)
> > > >
> > >
> > > First, in my LLVM-7 test:
> > > /home/trini/u-boot/u-boot/tools/ifwitool.c:584:23: warning: unused 
> > > function 'read_le8' [-Wunused-function]
> > > static inline uint8_t read_le8(const void *src)
> > >   ^
> > > /home/trini/u-boot/u-boot/tools/ifwitool.c:695:20: warning: unused 
> > > function 'zero_n' [-Wunused-function]
> > > static inline void zero_n(void *dest, size_t n)
> > >
> > > Which is simple to fix.  But I don't see why it's not being caught in
> > > the travis test off-hand.
> >
> > I'm not sure either. Possible it depends on the compiler used?
>
> I'm concerned the travis job isn't running LLVM like we think it is.
>
> > >  And I further see I didn't get LLVM-7
> > > included in GitLab at all yet.
> > >
> > > Next however I see:
> > > https://gitlab.denx.de/u-boot/u-boot/-/jobs/1222
> > > which is the binman tests failing and needs to be fixed.
> >
> > Oh dear, I don't seem to have any idea about gitlab yet. Have updated
> > the gitlab config file. Should I stop using travis completely now?
>
> Long term I think GitLab CI is going to be better for custodians as
> we'll have more build resources available and thus the jobs will
> complete quicker.  I don't know why the binman testsuite doesn't fail in
> travis like it does there.

Well that is because I updated the travis config but not the gitlab. Doing that.

> The good news is the gitlab job runs in a
> defined docker container you can pull and try locally :)

OK good. Will give this all a crack at some point.

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Tue, Jul 23, 2019 at 08:08:03PM -0700, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 23 Jul 2019 at 11:16, Tom Rini  wrote:
> >
> > On Mon, Jul 22, 2019 at 08:48:45AM -0600, Simon Glass wrote:
> >
> > > Hi Tom,
> > >
> > > Build is here: https://travis-ci.org/sglass68/u-boot/builds/561552377
> > >
> > > The following changes since commit 
> > > 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> > >
> > >   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> > >
> > > are available in the Git repository at:
> > >
> > >   git://git.denx.de/u-boot-dm.git tags/dm-pull-22jul19
> > >
> > > for you to fetch changes up to 857ad7985ff63989c3c7feff56c2dc353d7d7c9a:
> > >
> > >   dm: device: make power domain calls optional (2019-07-20 19:50:44 -0600)
> > >
> >
> > First, in my LLVM-7 test:
> > /home/trini/u-boot/u-boot/tools/ifwitool.c:584:23: warning: unused function 
> > 'read_le8' [-Wunused-function]
> > static inline uint8_t read_le8(const void *src)
> >   ^
> > /home/trini/u-boot/u-boot/tools/ifwitool.c:695:20: warning: unused function 
> > 'zero_n' [-Wunused-function]
> > static inline void zero_n(void *dest, size_t n)
> >
> > Which is simple to fix.  But I don't see why it's not being caught in
> > the travis test off-hand.
> 
> I'm not sure either. Possible it depends on the compiler used?

I'm concerned the travis job isn't running LLVM like we think it is.

> >  And I further see I didn't get LLVM-7
> > included in GitLab at all yet.
> >
> > Next however I see:
> > https://gitlab.denx.de/u-boot/u-boot/-/jobs/1222
> > which is the binman tests failing and needs to be fixed.
> 
> Oh dear, I don't seem to have any idea about gitlab yet. Have updated
> the gitlab config file. Should I stop using travis completely now?

Long term I think GitLab CI is going to be better for custodians as
we'll have more build resources available and thus the jobs will
complete quicker.  I don't know why the binman testsuite doesn't fail in
travis like it does there.  The good news is the gitlab job runs in a
defined docker container you can pull and try locally :)

-- 
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 v5 7/8] board: intel: Add new slimbootloader board

[Park, Aiden]

Hi Andy,

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Tuesday, July 23, 2019 5:27 AM
> To: Bin Meng 
> Cc: Park, Aiden ; U-Boot Mailing List  b...@lists.denx.de>; Simon Glass 
> Subject: Re: [PATCH v5 7/8] board: intel: Add new slimbootloader board
> 
> On Tue, Jul 23, 2019 at 9:15 AM Bin Meng  wrote:
> > On Mon, Jul 22, 2019 at 11:49 PM Andy Shevchenko
> >  wrote:
> > > On Wed, Jul 17, 2019 at 7:42 AM Park, Aiden  wrote:
> 
> > > >  board/intel/slimbootloader/README   | 133 
> > >
> > > Shouldn't become reST one?
> >
> > I think this will need be converted to reST after my doc series are applied.
> 
> I had an impression that reST conversion is targeting 2019.10. It means in 
> your
> branch you will have it applied earlier.
> 
Let me change this to reST if necessary.
Hi Bin, do you want me to change this one to reST or later? Let me know.

> > > > +int board_early_init_r(void)
> > > > +{
> > > > +   /*
> > > > +* Make sure PCI bus is enumerated so that peripherals on the 
> > > > PCI bus
> > > > +* can be discovered by their drivers
> > > > +*/
> > > > +   pci_init();
> > >
> > > I'm not sure this is how U-Boot is designed with DM.
> > > At least my expectations that bus gets initialized followed by the
> > > certain driver in a lazy way.
> > > Isn't it the case? Bin?
> >
> > For most x86 board, yes, PCI gets enumerated automatically if some PCI
> > APIs are called in the early initialization codes: eg: pci_{read,
> > write}_config().
> >
> > But for boards like coreboot/slimbootloader, if there is no touch to
> > any PCI config register on that board in the early phase, PCI bus
> > remains not probed.
> 
> Thanks for explanation!
> Perhaps this needs a comment in the code.
> 
Thanks Bin for your explanation. Slim Bootloader have done PCI config space 
setup
and PCI device enumeration in Slim Bootloader stages.

> --
> With Best Regards,
> Andy Shevchenko

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

[U-Boot] [PATCH 2/4] armv8: ls2088aqds: The ls2088aqds board supports the I2C driver model.

[Chuanhua Han]

This patch is updating ls2088aqds board init code to support DM_I2C.

Signed-off-by: Chuanhua Han 
---
depends on:
- http://patchwork.ozlabs.org/project/uboot/list/?series=118772
- http://patchwork.ozlabs.org/project/uboot/list/?series=117226

 board/freescale/ls2080aqds/eth.c| 75 +
 board/freescale/ls2080aqds/ls2080aqds.c |  8 
 include/configs/ls2080aqds.h|  3 ++
 3 files changed, 86 insertions(+)

diff --git a/board/freescale/ls2080aqds/eth.c b/board/freescale/ls2080aqds/eth.c
index f706fd4..b1d6827 100644
--- a/board/freescale/ls2080aqds/eth.c
+++ b/board/freescale/ls2080aqds/eth.c
@@ -107,7 +107,16 @@ static void sgmii_configure_repeater(int serdes_port)
int *riser_phy_addr = _riser_phy_addr[0];
 
/* Set I2c to Slot 1 */
+#ifndef CONFIG_DM_I2C
i2c_write(0x77, 0, 0, , 1);
+#else
+   struct udevice *udev;
+
+   ret = i2c_get_chip_for_busnum(0, 0x77, 1, );
+   if (!ret)
+   dm_i2c_write(udev, 0, , 1);
+#endif
+
 
for (dpmac = 0; dpmac < 8; dpmac++) {
/* Check the PHY status */
@@ -120,7 +129,14 @@ static void sgmii_configure_repeater(int serdes_port)
mii_bus = 1;
dpmac_id = dpmac + 9;
a = 0xb;
+#ifndef CONFIG_DM_I2C
i2c_write(0x76, 0, 0, , 1);
+#else
+   ret = i2c_get_chip_for_busnum(0, 0x76, 1, );
+   if (!ret)
+   dm_i2c_write(udev, 0, , 1);
+#endif
+
break;
}
 
@@ -153,6 +169,7 @@ static void sgmii_configure_repeater(int serdes_port)
 
for (i = 0; i < 4; i++) {
for (j = 0; j < 4; j++) {
+#ifndef CONFIG_DM_I2C
a = 0x18;
i2c_write(i2c_addr[dpmac], 6, 1, , 1);
a = 0x38;
@@ -176,6 +193,31 @@ static void sgmii_configure_repeater(int serdes_port)
i2c_write(i2c_addr[dpmac], 0x2d, 1, , 1);
a = 0x20;
i2c_write(i2c_addr[dpmac], 4, 1, , 1);
+#else
+   i2c_get_chip_for_busnum(0, i2c_addr[dpmac],
+   1, );
+
+   a = 0x18;
+   dm_i2c_write(udev, 6, , 1);
+   a = 0x38;
+   dm_i2c_write(udev, 4, , 1);
+   a = 0x4;
+   dm_i2c_write(udev, 8, , 1);
+
+   dm_i2c_write(udev, 0xf, _a_eq[i], 1);
+   dm_i2c_write(udev, 0x11, _a_ctl2[j], 1);
+
+   dm_i2c_write(udev, 0x16, _b_eq[i], 1);
+   dm_i2c_write(udev, 0x18, _b_ctl2[j], 1);
+
+   a = 0x14;
+   dm_i2c_write(udev, 0x23, , 1);
+   a = 0xb5;
+   dm_i2c_write(udev, 0x2d, , 1);
+   a = 0x20;
+   dm_i2c_write(udev, 4, , 1);
+
+#endif
mdelay(100);
ret = miiphy_read(dev[mii_bus],
  riser_phy_addr[dpmac],
@@ -231,7 +273,15 @@ static void qsgmii_configure_repeater(int dpmac)
unsigned short value;
 
/* Set I2c to Slot 1 */
+#ifndef CONFIG_DM_I2C
i2c_write(0x77, 0, 0, , 1);
+#else
+   struct udevice *udev;
+
+   ret = i2c_get_chip_for_busnum(0, 0x77, 1, );
+   if (!ret)
+   dm_i2c_write(udev, 0, , 1);
+#endif
 
switch (dpmac) {
case 1:
@@ -282,6 +332,7 @@ static void qsgmii_configure_repeater(int dpmac)
 
for (i = 0; i < 4; i++) {
for (j = 0; j < 4; j++) {
+#ifndef CONFIG_DM_I2C
a = 0x18;
i2c_write(i2c_phy_addr, 6, 1, , 1);
a = 0x38;
@@ -301,6 +352,30 @@ static void qsgmii_configure_repeater(int dpmac)
i2c_write(i2c_phy_addr, 0x2d, 1, , 1);
a = 0x20;
i2c_write(i2c_phy_addr, 4, 1, , 1);
+#else
+   i2c_get_chip_for_busnum(0, i2c_phy_addr, 1, );
+   a = 0x18;
+   dm_i2c_write(udev, 6, , 1);
+   a = 0x38;
+   dm_i2c_write(udev, 4, , 1);
+   a = 0x4;
+   dm_i2c_write(udev, 8, , 1);
+
+   dm_i2c_write(udev, 0xf, _a_eq[i], 1);
+   dm_i2c_write(udev, 0x11, _a_ctl2[j], 1);
+
+   dm_i2c_write(udev, 0x16, _b_eq[i], 1);
+   dm_i2c_write(udev, 0x18, 

[U-Boot] [PATCH 3/4] configs: ls2088aqds: Enable DM support for ds3231 rtc

[Chuanhua Han]

Enable related configs on all ls2088aqds boards to support ds3231
rtc DM function.

Signed-off-by: Chuanhua Han 
---
depends on:
- http://patchwork.ozlabs.org/project/uboot/list/?series=118772
- http://patchwork.ozlabs.org/project/uboot/list/?series=117226

 configs/ls2088aqds_tfa_defconfig | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/configs/ls2088aqds_tfa_defconfig b/configs/ls2088aqds_tfa_defconfig
index e798c59..95921b0 100644
--- a/configs/ls2088aqds_tfa_defconfig
+++ b/configs/ls2088aqds_tfa_defconfig
@@ -1,12 +1,12 @@
 CONFIG_ARM=y
 CONFIG_TARGET_LS2080AQDS=y
+CONFIG_SYS_MALLOC_F_LEN=0x6000
 CONFIG_SYS_TEXT_BASE=0x8200
 CONFIG_TFABOOT=y
 CONFIG_NR_DRAM_BANKS=3
 CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y
 CONFIG_SEC_FIRMWARE_ARMV8_PSCI=y
 CONFIG_AHCI=y
-# CONFIG_SYS_MALLOC_F is not set
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
@@ -63,3 +63,11 @@ CONFIG_DM_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_XHCI_DWC3=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
+CONFIG_DM_I2C=y
+CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
+CONFIG_I2C_DEFAULT_BUS_NUMBER=0
+CONFIG_DM_GPIO=y
+CONFIG_I2C_MUX=y
+CONFIG_I2C_MUX_PCA954x=y
+CONFIG_DM_RTC=y
+CONFIG_DS3231_BUS_NUM=0
-- 
2.9.5

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

[U-Boot] [PATCH 4/4] armv8: ls2088aqds : Add ds3232 node

[Chuanhua Han]

This patch adds the ds3232-rtc node under the i2c0->i2c-mux@77->i2c@0
for ls2088aqds boards.

Signed-off-by: Chuanhua Han 
---
depends on:
- http://patchwork.ozlabs.org/project/uboot/list/?series=118772
- http://patchwork.ozlabs.org/project/uboot/list/?series=117226

 arch/arm/dts/fsl-ls2080a-qds.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/fsl-ls2080a-qds.dts b/arch/arm/dts/fsl-ls2080a-qds.dts
index 2a0a528..13461b5 100644
--- a/arch/arm/dts/fsl-ls2080a-qds.dts
+++ b/arch/arm/dts/fsl-ls2080a-qds.dts
@@ -19,6 +19,25 @@
};
 };
 
+ {
+   status = "okay";
+   pca9547@77 {
+   compatible = "nxp,pca9547";
+   reg = <0x77>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x00>;
+   rtc@68 {
+   compatible = "dallas,ds3232";
+   reg = <0x68>;
+   };
+   };
+   };
+};
+
  {
bus-num = <0>;
status = "okay";
-- 
2.9.5

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

[U-Boot] [PATCH 1/4] rtc: ds3232/ds3231: Add support to generate 32KHz output for driver module

[Chuanhua Han]

This patch add an implementation of the rtc_enable_32khz_output() that
uses the driver model i2c APIs.

Signed-off-by: Chuanhua Han 
---
depends on:
- http://patchwork.ozlabs.org/project/uboot/list/?series=118772
- http://patchwork.ozlabs.org/project/uboot/list/?series=117226

 drivers/rtc/Kconfig  | 10 ++
 drivers/rtc/ds3231.c | 21 +
 include/rtc.h|  6 ++
 3 files changed, 37 insertions(+)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index fd0009b..040d241 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -31,6 +31,12 @@ config TPL_DM_RTC
  drivers to perform the actual functions. See rtc.h for a
  description of the API.
 
+config RTC_ENABLE_32KHZ_OUTPUT
+   bool "Enable RTC 32Khz output"
+   help
+  Some real-time clocks support the output of 32kHz square waves (such 
as ds3231),
+  the config symbol choose Real Time Clock device 32Khz output feature.
+
 config RTC_PCF2127
bool "Enable PCF2127 driver"
depends on DM_RTC
@@ -41,6 +47,10 @@ config RTC_PCF2127
  has a selectable I2C-bus or SPI-bus, a backup battery switch-over 
circuit, a
  programmable watchdog function, a timestamp function, and many other 
features.
 
+config DS3231_BUS_NUM
+   hex "I2C bus of the DS3231 device"
+   default 0
+
 config RTC_DS1307
bool "Enable DS1307 driver"
depends on DM_RTC
diff --git a/drivers/rtc/ds3231.c b/drivers/rtc/ds3231.c
index 79b026a..dbd77a6 100644
--- a/drivers/rtc/ds3231.c
+++ b/drivers/rtc/ds3231.c
@@ -148,11 +148,13 @@ void rtc_reset (void)
 /*
  * Enable 32KHz output
  */
+#ifdef CONFIG_RTC_ENABLE_32KHZ_OUTPUT
 void rtc_enable_32khz_output(void)
 {
rtc_write(RTC_STAT_REG_ADDR,
  RTC_STAT_BIT_BB32KHZ | RTC_STAT_BIT_EN32KHZ);
 }
+#endif
 
 /*
  * Helper functions
@@ -251,6 +253,25 @@ static int ds3231_probe(struct udevice *dev)
return 0;
 }
 
+#ifdef CONFIG_RTC_ENABLE_32KHZ_OUTPUT
+void rtc_enable_32khz_output(void)
+{
+   int ret;
+   struct udevice *dev;
+
+#ifdef CONFIG_DS3231_BUS_NUM
+   ret = i2c_get_chip_for_busnum(CONFIG_DS3231_BUS_NUM,
+ CONFIG_SYS_I2C_RTC_ADDR, 1, );
+#else
+   ret = i2c_get_chip_for_busnum(0, CONFIG_SYS_I2C_RTC_ADDR, 1, );
+#endif
+   if (!ret)
+   dm_i2c_reg_write(dev, RTC_STAT_REG_ADDR,
+RTC_STAT_BIT_BB32KHZ |
+RTC_STAT_BIT_EN32KHZ);
+}
+#endif
+
 static const struct rtc_ops ds3231_rtc_ops = {
.get = ds3231_rtc_get,
.set = ds3231_rtc_set,
diff --git a/include/rtc.h b/include/rtc.h
index b255bdc..df7de09 100644
--- a/include/rtc.h
+++ b/include/rtc.h
@@ -166,11 +166,17 @@ int rtc_read32(struct udevice *dev, unsigned int reg, u32 
*valuep);
  */
 int rtc_write32(struct udevice *dev, unsigned int reg, u32 value);
 
+#ifdef CONFIG_RTC_ENABLE_32KHZ_OUTPUT
+void rtc_enable_32khz_output(void);
+#endif
+
 #else
 int rtc_get (struct rtc_time *);
 int rtc_set (struct rtc_time *);
 void rtc_reset (void);
+#ifdef CONFIG_RTC_ENABLE_32KHZ_OUTPUT
 void rtc_enable_32khz_output(void);
+#endif
 
 /**
  * rtc_read8() - Read an 8-bit register
-- 
2.9.5

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

Re: [U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

On Tue, 23 Jul 2019 at 11:16, Tom Rini  wrote:
>
> On Mon, Jul 22, 2019 at 08:48:45AM -0600, Simon Glass wrote:
>
> > Hi Tom,
> >
> > Build is here: https://travis-ci.org/sglass68/u-boot/builds/561552377
> >
> > The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> >
> >   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> >
> > are available in the Git repository at:
> >
> >   git://git.denx.de/u-boot-dm.git tags/dm-pull-22jul19
> >
> > for you to fetch changes up to 857ad7985ff63989c3c7feff56c2dc353d7d7c9a:
> >
> >   dm: device: make power domain calls optional (2019-07-20 19:50:44 -0600)
> >
>
> First, in my LLVM-7 test:
> /home/trini/u-boot/u-boot/tools/ifwitool.c:584:23: warning: unused function 
> 'read_le8' [-Wunused-function]
> static inline uint8_t read_le8(const void *src)
>   ^
> /home/trini/u-boot/u-boot/tools/ifwitool.c:695:20: warning: unused function 
> 'zero_n' [-Wunused-function]
> static inline void zero_n(void *dest, size_t n)
>
> Which is simple to fix.  But I don't see why it's not being caught in
> the travis test off-hand.

I'm not sure either. Possible it depends on the compiler used?

>  And I further see I didn't get LLVM-7
> included in GitLab at all yet.
>
> Next however I see:
> https://gitlab.denx.de/u-boot/u-boot/-/jobs/1222
> which is the binman tests failing and needs to be fixed.

Oh dear, I don't seem to have any idea about gitlab yet. Have updated
the gitlab config file. Should I stop using travis completely now?

>
> --
> Tom

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

Re: [U-Boot] [PATCH v5 5/8] x86: slimbootloader: Set TSC information for timer driver

[Park, Aiden]

Hi Andy,

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Monday, July 22, 2019 8:42 AM
> To: Park, Aiden 
> Cc: U-Boot Mailing List ; Simon Glass
> ; Bin Meng 
> Subject: Re: [PATCH v5 5/8] x86: slimbootloader: Set TSC information for timer
> driver
> 
> On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden  wrote:
> >
> > Slim Bootloader provides TSC clock information in its performance info
> > hob. For now, TSC clock information is only used for timer driver from
> > the performance info hob.
> > - Get TSC frequency from performance info hob
> > - Set tsc_base and clock_rate for timer driver
> 
> So why do we need this at all? We have a common TSC driver that works for all
> x86.
> 
This series also uses TSC driver, but giving these values will bypass TSC 
calibration in the driver.
Slim Bootloader already has CPU specific TSC value and provides the TSC value
in its performance data HOB. Therefore, U-Boot TSC driver does not have to 
re-calibrate TSC.

> > +#define LOADER_PERFORMANCE_INFO_GUID \
> > +   { \
> > +   0x868204be, 0x23d0, 0x4ff9, \
> > +   { 0xac, 0x34, 0xb9, 0x95, 0xac, 0x04, 0xb1, 0xb9 } \
> > +   }
> 
> Use EFI_GUID(), please.
> 
Let me use EFI_GUID.

> > +struct performance_info {
> 
> Same, you better to make less generic names for data structs.
>
Let me use particular one. Thanks.

> > +} __packed;
> 
> Same question. If it's aligned naturally by 32-bit boundaries, Why do you need
> __packed?
>
Let me remote __packed. Thanks.
 
> --
> With Best Regards,
> Andy Shevchenko

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

Re: [U-Boot] [PATCH v5 4/8] x86: slimbootloader: Add serial driver

[Park, Aiden]

Hi Andy,

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Monday, July 22, 2019 8:38 AM
> To: Park, Aiden 
> Cc: U-Boot Mailing List ; Simon Glass
> ; Bin Meng 
> Subject: Re: [PATCH v5 4/8] x86: slimbootloader: Add serial driver
> 
> On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden  wrote:
> >
> > Slim Bootloader provides serial port info thru its HOB list pointer.
> > All these HOBs are eligible for Slim Bootloader based board only.
> > - Get serial port information from the serial port info hob
> > - Leverage ns16550 driver with slimbootloader specific platform data
> 
> > +   /*
> > +* The serial_info->type provides port io or mmio access type info,
> > +* but the access type will be controlled by
> > +* CONFIG_SYS_NS16550_PORT_MAPPED or
> CONFIG_SYS_NS16550_MEM32.
> > +*
> > +* TBD: ns16550 access type configuration in runtime.
> > +*  ex) plat->access_type = serial_info->type
> > +*/
> 
> io -> IO
> mmio -> MMIO
> 
Let me change this.

> > +   plat->base = serial_info->base;
> > +   /* ns16550 uses reg_shift, then covert stride to shift */
> 
> > +   plat->reg_shift = (serial_info->stride >> 1);
> 
> Too many parenthesis.
>
Let me remove parenthesis.
 
> > +   plat->clock = serial_info->clk;
> > +
> > +   return 0;
> > +}
> 
> > +/**
> > + * A GUID to get SerialPort info hob which is provided by Slim
> > +Bootloader  */ #define LOADER_SERIAL_PORT_INFO_GUID \
> > +   { \
> > +   0x6c6872fe, 0x56a9, 0x4403, \
> > +   { 0xbb, 0x98, 0x95, 0x8d, 0x62, 0xde, 0x87, 0xf1 } \
> > +   }
> 
> EFI_GUID()
>
Let me use EFI_GUID.

> > +struct serial_port_info {
> 
> serial is not this platform namespace, choose more particular one, please.
> 
This header file is only for arch-slimbootloader. Anyway, let me use particular 
one.

> > +   u8  rev;
> > +   u8  rsvd[3];
> > +   u32 type;
> > +   u32 base;
> > +   u32 baud;
> > +   u32 stride;
> > +   u32 clk;
> > +   u32 rsvd1;
> 
> > +} __packed;
> 
> Does __packed service for anything here?
> 
Thanks. This is not necessary. Let me remove __packed.

> --
> With Best Regards,
> Andy Shevchenko

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

Re: [U-Boot] [RFC PATCH 00/11] SPL support for RISC-V

[Bin Meng]

Hi Lukas,

On Wed, Jul 24, 2019 at 5:34 AM Auer, Lukas
 wrote:
>
> Hi Bin,
>
> On Tue, 2019-07-23 at 16:32 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Mon, Jul 22, 2019 at 2:00 AM Lukas Auer
> >  wrote:
> > > This series adds support for SPL to RISC-V U-Boot. Images can be booted
> > > via OpenSBI (FW_DYNAMIC firmware) or by directly jumping to them. In the
> > > former case, OpenSBI and U-Boot proper are bundled as a FIT image and
> > > made available to U-Boot SPL. Currently, only the QEMU board enables
> > > U-Boot SPL with a dedicated configuration. It uses RAM as SPL boot
> > > device.
> > >
> > > On many RISC-V CPUs, the device tree is provided to U-Boot by the
> > > first stage bootloader. This requires changes to U-Boot SPL (patches 1,
> > > 2 and 3), which modify the behavior on other boards as well. To get
> > > feedback on this, I am therefore sending this series as RFC first.
> > >
> > > To test this series, OpenSBI has to be compiled first. The
> > > fw_dynamic.bin binary must be copied into the U-Boot root directory.
> > > Alternatively, the location of the binary can be specified with the
> > > OPENSBI environment variable. U-Boot can then be build as normal using
> > > the configuration qemu-riscv64_spl_defconfig for 64-bit builds or
> > > qemu-riscv32_spl_defconfig for 32-bit builds. The outputs from the build
> > > process are the U-Boot SPL binary (spl/u-boot-spl.bin) and the U-Boot
> > > FIT image (u-boot.itb) containing U-Boot proper and OpenSBI.
> > >
> > > U-Boot can be run in QEMU with the following command.
> > >
> > > qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \
> > > -device loader,file=u-boot.itb,addr=0x8020
> > >
> >
> > Nice job done! It looks the SPL support was cleanly implemented.
> >
>
> Thank you very much! :)
>
> > I've tested this series, on qemu-riscv64 with UP and SMP, both work fine.
> > However when testing on qemu-riscv32, the U-Boot proper does not boot.
> > Please have a look.
> >
> > Regards,
> > Bin
>
> Thank you for reviewing and testing the series!
>
> Do you mean that the U-Boot prompt does not appear? Testing the series

I mean U-Boot proper, the S-mode payload that SPL loads.

> on qemu-riscv32, I get the U-Boot prompt from U-Boot proper. I did not
> try to boot Linux on qemu-riscv32, however. I will try that tomorrow.

After debugging myself, it turns out to be a false alarm. Sorry about that.

I was using a 64-bit OpenSBI fw_dynamic.bin. Looks OpenSBI doc does
not clearly mention how 32-bit build is to be done, and I will send a
patch for that. After switching a 32-bit OpenSBI firmware now I am
able to boot to 32-bit U-Boot proper.

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

Re: [U-Boot] [PATCH v5 3/8] x86: slimbootloader: Add memory configuration

[Park, Aiden]

Hi Andy,

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Monday, July 22, 2019 8:34 AM
> To: Park, Aiden 
> Cc: U-Boot Mailing List ; Simon Glass
> ; Bin Meng 
> Subject: Re: [PATCH v5 3/8] x86: slimbootloader: Add memory configuration
> 
> On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden  wrote:
> >
> > Slim Bootloader provides memory map info thru its HOB list pointer.
> > Configure memory size and relocation memory from the HOB data, and
> > provide e820 entries as well.
> > - Get memory size from the memory map info hob
> > - Set ram top for U-Boot relocation lower than 4GB
> > - Provide e820 entries from the memory map info hob
> 
> > +++ b/arch/x86/cpu/slimbootloader/dram.c
> 
> sdram.c is more common name in the sources AFAICS.
> 
Okay. let me use sdram.

> > +ulong board_get_usable_ram_top(ulong total_size) {
> > +   struct memory_map_info *data = NULL;
> > +   int i = 0;
> > +   phys_addr_t addr_start = 0;
> > +   phys_addr_t addr_end = 0;
> 
> Unnecessary assignments (check entire series for them).
>
Okay. let me check this in entire series.
 
> > +   data = (struct memory_map_info *)get_memory_map_info();
> 
> Casting from / to void * is redundant. Check entire series.
> 
Do you mean casting void * to (struct *)? Anyway, let me remove casting if 
redundant in entire series.

> > +   if (!data)
> > +   panic("memory map info hob not found\n");
> 
> > +   /**
> > +* sorted memory map entries from Slim Bootloader based on physical
> > +* start memory address, from low to high. So do reversed search to
> > +* get highest usable, suitable size, 4KB aligned available memory
> > +* under 4GB.
> > +*/
> 
> > +   for (i = data->count - 1; i >= 0; i--) {
> 
> Hmm... Maybe
> 
> i = data->count;
> while (i--) {
>  ...
> }
> 
> Easier to read.
> 
Okay. let me change this.

> > +   if (data->entry[i].type != E820_RAM)
> > +   continue;
> > +
> > +   addr_start = data->entry[i].addr;
> > +   addr_end = addr_start + data->entry[i].size;
> > +
> > +   if (addr_start > SZ_4G)
> > +   continue;
> > +
> > +   if (addr_end > SZ_4G)
> > +   addr_end = SZ_4G;
> > +
> > +   if (addr_end < total_size)
> > +   continue;
> > +
> 
> > +   /* to relocate u-boot at 4K aligned memory */
> 
> u-boot -> U-Boot
>
Let me change this.
 
> > +   addr_end = rounddown(addr_end - total_size, SZ_4K);
> > +   if (addr_end >= addr_start) {
> > +   ram_top = (ulong)addr_end + total_size;
> > +   break;
> > +   }
> > +   }
> > +
> > +   if (!ram_top)
> > +   panic("failed to find available memory for
> > + relocation!");
> > +
> > +   return ram_top;
> > +}
> > +
> > +/**
> > + * The memory initialization has already been done in previous Slim
> > +Bootloader
> > + * stage thru FSP-M. Instead, this sets the ram_size from the memory
> > +map info
> > + * hob.
> > + */
> > +int dram_init(void)
> > +{
> > +   struct memory_map_info *data = NULL;
> > +   int i = 0;
> > +   phys_size_t ram_size = 0;
> > +
> > +   data = (struct memory_map_info *)get_memory_map_info();
> > +   if (!data)
> > +   panic("memory map info hob not found\n");
> > +
> > +   /**
> > +* sorted memory map entries from Slim Bootloader based on physical
> > +* start memory address, from low to high. So do reversed search to
> > +* simply get highest usable memory address as ram size
> > +*/
> 
> > +   for (i = data->count - 1; i >= 0; i--) {
> > +   if (data->entry[i].type != E820_RAM)
> > +   continue;
> 
> Second time?
> 
> Perhaps you may do rather macro:
> 
> #define for_each_map_info_entry_reversed(...) \
>   for () \
>   if (!cond) {} else
>
Okay, let me use macro.
 
> > +
> > +   /* simply use the highest usable memory address as ram
> > + size */
> 
> ram -> RAM
>
Let me change this.
 
> > +   ram_size = data->entry[i].addr + data->entry[i].size;
> > +   break;
> > +   }
> > +
> > +   if (!ram_size)
> > +   panic("failed to detect memory size");
> > +
> > +   gd->ram_size = ram_size;
> > +   return 0;
> > +}
> 
> > +int dram_init_banksize(void)
> > +{
> > +   /* simply use a single bank to have whole size for now */
> > +   if (CONFIG_NR_DRAM_BANKS) {
> 
> if (!foo) might be slightly better if ever this code gets modified.
> 
Okay. Let me change this.

> > +   gd->bd->bi_dram[0].start = 0;
> > +   gd->bd->bi_dram[0].size = gd->ram_size;
> > +   }
> > +   return 0;
> > +}
> 
> > +#define LOADER_MEMORY_MAP_INFO_GUID \
> > +   { \
> > +   0xa1ff7424, 0x7a1a, 0x478e, \
> > 

Re: [U-Boot] [PATCH v5 1/8] x86: Add new slimbootloader CPU type

[Bin Meng]

Hi Aiden,

On Wed, Jul 24, 2019 at 10:37 AM Park, Aiden  wrote:
>
> Hi Andy,
>
> > -Original Message-
> > From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> > Sent: Monday, July 22, 2019 8:14 AM
> > To: Park, Aiden 
> > Cc: U-Boot Mailing List ; Simon Glass
> > ; Bin Meng 
> > Subject: Re: [PATCH v5 1/8] x86: Add new slimbootloader CPU type
> >
> > On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden  wrote:
> > >
> > > This slimbootloader cpu type is to enable U-Boot as a payload which
> >
> > cpu -> CPU
> >
> Let me change this.
>
> > > runs on top of Slim Bootloader(https://github.com/slimbootloader).
> > > The Slim Bootloader is designed with multi-stage architecture for the
> > > execution from reset vector to OS booting, and supports qemu,
> >
> > qemu -> QEMU
> >
> Let me change this.
>
> > > Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP
> > > (https://github.com/IntelFsp) for silicon initialization including CAR
> > > and memory initialization.
> > > The Slim Bootloader generates new HOB(Hand Off Block) which are serial
> > > port info, memory map info, performance data info and so on, and
> > > passes it to a Payload. U-Boot as a payload will use these HOB
> > > information for basic initialization such as serial console.
> >
> > > +config SYS_SLIMBOOTLOADER
> >
> > > +   bool
> > > +   default y
> >
> > def_bool y ?
> >
> Thanks. Let me fix this and select SYS_SLIMBOOTLOADER in board Kconfig.
>
> > > +   imply SYS_NS16550
> > > +   imply AHCI_PCI
> > > +   imply SCSI
> > > +   imply SCSI_AHCI
> > > +   imply MMC
> > > +   imply MMC_PCI
> > > +   imply MMC_SDHCI
> > > +   imply MMC_SDHCI_SDMA
> > > +   imply USB
> > > +   imply USB_EHCI_HCD
> > > +   imply USB_XHCI_HCD
> > > +   imply USB_STORAGE
> > > +   imply USB_KEYBOARD
> > > +   imply E1000
> >
> > > +   imply RTL8169
> >
> > Is it part of SoC? I dunno we have Realtek inside, usually either Intel or 
> > Synopsys.
> >
> Yes on silicon Slim Bootloader supports, but not verified with this series.
> I think removing this one would be better until this is really required.
>
> Hi Bin, RTL8169 has been added as your recommended, but it hasn't been 
> verified.
> Is it okay to skip adding RTL8169 in this series? Let me add this later if it 
> is really required.
>

RTL8169 is a common PCIe NIC so it's possible to have that wired on
board. As I mentioned, for any board drivers, let's move that to board
Kconfig file.

[snip]

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

Re: [U-Boot] [EXT] Re: [PATCH v2] rtc: ds3232/ds3231: Add support to generate 32KHz output for driver module

[Chuanhua Han]

Dear Wolfgang Denk

> -Original Message-
> From: Wolfgang Denk 
> Sent: 2019年7月23日 23:05
> To: Chuanhua Han 
> Cc: lu...@denx.de; tr...@konsulko.com; Prabhakar Kushwaha
> ; u-boot@lists.denx.de
> Subject: [EXT] Re: [PATCH v2] rtc: ds3232/ds3231: Add support to generate
> 32KHz output for driver module
> 
> Caution: EXT Email
> 
> Dear Chuanhua Han,
> 
> In message <20190723095745.37138-1-chuanhua@nxp.com> you wrote:
> > This patch add an implementation of the rtc_enable_32khz_output() that
> > uses the driver model i2c APIs.
> >
> > Signed-off-by: Chuanhua Han 
> > ---
> > Change in v2:
> >   - Add RTC_ENABLE_32KHZ_OUTPUT option so this code compiles
> only
> > in that cases where it is really useful.
> 
> So when exactly is it useful?
> 
> If I understand correctly, there are no users of this code in mainline.  
> Should
> the patch then not be part of a patch series that adds such users?
> 
> Adding potentially "useful" code just on speculation is not nice
> maintenance-wise.
> 
> I recommend to withdraw this patch and submit it together with some real
> consumer of this feature.
Ok, I will send the current patch together with the one that actually uses this 
function. Thanks for your advice!
> 
> Thanks.
> 
> 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
> "The question of whether a computer can think is no more  interesting than
> the question of whether a submarine can swim"
> - Edsgar W.  Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v5 1/8] x86: Add new slimbootloader CPU type

[Park, Aiden]

Hi Andy,

> -Original Message-
> From: Andy Shevchenko [mailto:andy.shevche...@gmail.com]
> Sent: Monday, July 22, 2019 8:14 AM
> To: Park, Aiden 
> Cc: U-Boot Mailing List ; Simon Glass
> ; Bin Meng 
> Subject: Re: [PATCH v5 1/8] x86: Add new slimbootloader CPU type
> 
> On Wed, Jul 17, 2019 at 7:41 AM Park, Aiden  wrote:
> >
> > This slimbootloader cpu type is to enable U-Boot as a payload which
> 
> cpu -> CPU
> 
Let me change this.

> > runs on top of Slim Bootloader(https://github.com/slimbootloader).
> > The Slim Bootloader is designed with multi-stage architecture for the
> > execution from reset vector to OS booting, and supports qemu,
> 
> qemu -> QEMU
> 
Let me change this.

> > Apollolake, Whiskeylake and Coffeelake platforms consuming Intel FSP
> > (https://github.com/IntelFsp) for silicon initialization including CAR
> > and memory initialization.
> > The Slim Bootloader generates new HOB(Hand Off Block) which are serial
> > port info, memory map info, performance data info and so on, and
> > passes it to a Payload. U-Boot as a payload will use these HOB
> > information for basic initialization such as serial console.
> 
> > +config SYS_SLIMBOOTLOADER
> 
> > +   bool
> > +   default y
> 
> def_bool y ?
>
Thanks. Let me fix this and select SYS_SLIMBOOTLOADER in board Kconfig.
 
> > +   imply SYS_NS16550
> > +   imply AHCI_PCI
> > +   imply SCSI
> > +   imply SCSI_AHCI
> > +   imply MMC
> > +   imply MMC_PCI
> > +   imply MMC_SDHCI
> > +   imply MMC_SDHCI_SDMA
> > +   imply USB
> > +   imply USB_EHCI_HCD
> > +   imply USB_XHCI_HCD
> > +   imply USB_STORAGE
> > +   imply USB_KEYBOARD
> > +   imply E1000
> 
> > +   imply RTL8169
> 
> Is it part of SoC? I dunno we have Realtek inside, usually either Intel or 
> Synopsys.
>
Yes on silicon Slim Bootloader supports, but not verified with this series.
I think removing this one would be better until this is really required.

Hi Bin, RTL8169 has been added as your recommended, but it hasn't been verified.
Is it okay to skip adding RTL8169 in this series? Let me add this later if it 
is really required.   

> > -#ifndef CONFIG_HAVE_FSP
> > +#if !defined(CONFIG_HAVE_FSP)
> && !defined(CONFIG_SYS_SLIMBOOTLOADER)
> 
> > -#ifdef CONFIG_HAVE_FSP
> > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER)
> 
> Hmm... Maybe reasonable to have an additional option to tell something
> CONFIG_WE_HAVE_HOB_BUT_FSP.
>
Okay, let me add a new option - CONFIG_USE_HOB.
This will be selected by CONFIG_HAVE_FSP or CONFIG_SYS_SLIMBOOTLOADER.
 
> > /* Store the HOB list if we have one */
> > test%esi, %esi
> > jz  skip_hob
> > movl%esi, GD_HOB_LIST(%edx)
> >
> > +#ifdef CONFIG_HAVE_FSP
> 
> > +#endif
> 
> > +#ifndef __SLIMBOOTLOADER_ARCH_H__
> > +#define __SLIMBOOTLOADER_ARCH_H__
> > +
> > +#include 
> 
> Is it going to be expanded later?
> Otherwise I do not really see a point.
>
Yes, this is expanded in next patches. To avoid this confusion, let me remove 
this in 1st patch.

> > +#endif
> 
> > -#ifdef CONFIG_HAVE_FSP
> > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER)
> 
> > -#ifdef CONFIG_HAVE_FSP
> > +#if defined(CONFIG_HAVE_FSP) || defined(CONFIG_SYS_SLIMBOOTLOADER)
> 
> Same as above.
> 
> --
> With Best Regards,
> Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-stm32/master for v2019.10-rc1: u-boot-stm32-20190723

[Tom Rini]

On Tue, Jul 23, 2019 at 07:20:49AM +, Patrick DELAUNAY wrote:

> 
> Hi Tom
> 
> please pull the STM32 related patches for v2019.10-rc1 = u-boot-stm32-20190723
> 
> Travis CI status:
>   https://travis-ci.org/patrickdelaunay/u-boot/builds/562084625
>   the warnings are not related to the patchsets.
> 
> Thanks,
> Patrick
> 
> The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> 
>   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> 
> are available in the git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git 
> tags/u-boot-stm32-20190723
> 
> for you to fetch changes up to 1f99eaff08f699472860c82480344e824a737d57:
> 
>   rtc: Add rtc driver for stm32mp1 (2019-07-22 11:04:52 +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] Pull request: u-boot-rockchip/tags/rockchip-for-v2019.07-2

[Tom Rini]

On Mon, Jul 22, 2019 at 10:03:43PM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull some fix up for rockchip platform:
> - rk3399 sdhci driver fixup
> - TPL BANNER fixup
> 
> The Travis build is not complete when I send this mail, but it
> should be OK for the fixes are simple.
> Travis:
> https://travis-ci.org/keveryang/u-boot/builds/562114389
> 
> Thanks,
> - Kever
> 
> The following changes since commit 8b1ceb0ac1aa1746c6751d698ce7a012a236fa65:
> 
>   rockchip: Remove obsolete references to pyelftools (2019-07-20 23:59:44 
> +0800)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/rockchip-for-v2019.07-2
> 
> for you to fetch changes up to 89e39172301f15b29f663baf704bf2163a0cfa46:
> 
>   rockchip: TPL banner should depend on CONFIG_TPL_BANNER_PRINT (2019-07-22 
> 21:52:59 +0800)
> 

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] [PATCH] mmc: sdhci: fix chip detect gpio property name

[Peng Fan]

> Subject: [PATCH] mmc: sdhci: fix chip detect gpio property name
> 
> The standard property name for chip-detect gpio is "cd-gpios". All in-tree DT
> files use only this name.
> 
> Fixes: 451931ea700 ("mmc: sdhci: Read cd-gpio from devicetree")
> Cc: T Karthik Reddy 
> Cc: Michal Simek 
> Signed-off-by: Baruch Siach 
> ---
>  drivers/mmc/sdhci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> 0a0770cc2035..2779bca93f08 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -623,7 +623,7 @@ static int sdhci_init(struct mmc *mmc)  #if
> CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
>   struct udevice *dev = mmc->dev;
> 
> - gpio_request_by_name(dev, "cd-gpio", 0,
> + gpio_request_by_name(dev, "cd-gpios", 0,
>>cd_gpio, GPIOD_IS_IN);

Applied to mmc/master.

Thanks,
Peng

>  #endif
> 
> --
> 2.20.1

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

Re: [U-Boot] [PATCH] mmc: mv_sdhci: fix uninitialized pointer deref on probe

[Peng Fan]

> Subject: [PATCH] mmc: mv_sdhci: fix uninitialized pointer deref on probe
> 
> Since commit 3d296365e4e8 ("mmc: sdhci: Add support for
> sdhci-caps-mask") sdhci_setup_cfg() expects a valid sdhci_host mmc field.
> Move the mmc field initialization before sdhci_setup_cfg() call to avoid crash
> on mmc pointer dereference.
> 
> Fixes: 3d296365e4e8 ("mmc: sdhci: Add support for sdhci-caps-mask")
> Cc: Faiz Abbas 
> Signed-off-by: Baruch Siach 
> ---
>  drivers/mmc/mv_sdhci.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c index
> bf26d2e4e265..f5f3e4324719 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -114,6 +114,9 @@ static int mv_sdhci_probe(struct udevice *dev)
>   host->name = MVSDH_NAME;
>   host->ioaddr = (void *)devfdt_get_addr(dev);
>   host->quirks = SDHCI_QUIRK_32BIT_DMA_ADDR |
> SDHCI_QUIRK_WAIT_SEND_CMD;
> + host->mmc = >mmc;
> + host->mmc->dev = dev;
> + host->mmc->priv = host;
> 
>   ret = sdhci_setup_cfg(>cfg, host, 0, 0);
>   if (ret)
> @@ -124,9 +127,6 @@ static int mv_sdhci_probe(struct udevice *dev)
>   sdhci_mvebu_mbus_config(host->ioaddr);
>   }
> 
> - host->mmc = >mmc;
> - host->mmc->dev = dev;
> - host->mmc->priv = host;
>   upriv->mmc = host->mmc;
> 
>   return sdhci_probe(dev);

Applied to mmc/master.

Thanks,
Peng

> --
> 2.20.1

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

Re: [U-Boot] [PATCH v1] test/py: add MMC/SD block write test

[Peng Fan]

> Subject: [PATCH v1] test/py: add MMC/SD block write test
> 
> Add a standalone MMC block write test. This allows direct testing of MMC
> access rather than relying on doing so as a side-effect of e.g. DFU or UMS
> testing, which may not be enabled on all platforms.
> 
> Signed-off-by: Jean-Jacques Hiblot 
> 
> ---
> This patch relies on patch "cmd: mem: Add a command to fill the memory
> with random data".
> 
>  test/py/tests/test_mmc_wr.py | 105
> +++
>  1 file changed, 105 insertions(+)
>  create mode 100644 test/py/tests/test_mmc_wr.py
> 
> diff --git a/test/py/tests/test_mmc_wr.py b/test/py/tests/test_mmc_wr.py
> new file mode 100644 index 00..601279a6a4
> --- /dev/null
> +++ b/test/py/tests/test_mmc_wr.py
> @@ -0,0 +1,105 @@
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (c) 2019, Texas Instrument
> +# Author: Jean-Jacques Hiblot 
> +
> +# Test U-Boot's "mmc write" command. The test generates random data,
> +writes it # to the eMMC or SD card, then reads it back and performs a
> comparison.
> +
> +import pytest
> +import u_boot_utils
> +
> +"""
> +This test relies on boardenv_* to containing configuration values to
> +define which MMC devices should be tested. For example:
> +
> +env__mmc_wr_configs = (
> +{
> +"fixture_id": "emmc-boot0",
> +"is_emmc": True,
> +"devid": 1,
> +"partid": 1,
> +"sector": 0x10,
> +"count": 100,
> +"test_iterations": 50,
> +},
> +{
> +"fixture_id": "emmc-boot1",
> +"is_emmc": True,
> +"devid": 1,
> +"partid": 2,
> +"sector": 0x10,
> +"count": 100,
> +"test_iterations": 50,
> +},
> +)
> +
> +"""
> +
> +@pytest.mark.buildconfigspec('cmd_mmc','cmd_memory')
> +def test_mmc_wr(u_boot_console, env__mmc_wr_config):
> +"""Test the "mmc write" command.
> +
> +Args:
> +u_boot_console: A U-Boot console connection.
> +env__mmc_wr_config: The single MMC configuration on which
> +to run the test. See the file-level comment above for details
> +of the format.
> +
> +Returns:
> +Nothing.
> +"""
> +
> +is_emmc = env__mmc_wr_config['is_emmc']
> +devid = env__mmc_wr_config['devid']
> +partid = env__mmc_wr_config.get('partid', 0)
> +sector = env__mmc_wr_config.get('sector', 0)
> +count_sectors = env__mmc_wr_config.get('count', 1)
> +test_iterations = env__mmc_wr_config.get('test_iterations', 1)
> +
> +
> +count_bytes = count_sectors * 512
> +bcfg = u_boot_console.config.buildconfig
> +ram_base = u_boot_utils.find_ram_base(u_boot_console)
> +src_addr = '0x%08x' % ram_base
> +dst_addr = '0x%08x' % (ram_base + count_bytes)
> +
> +
> +for i in range(test_iterations):
> + # Generate random data
> + cmd = 'random %s %x' % (src_addr, count_bytes)
> + response = u_boot_console.run_command(cmd)
> + good_response = '%d bytes filled with random data' % (count_bytes)
> + assert good_response in response
> +
> + # Select MMC device
> + cmd = 'mmc dev %d' % devid
> + if is_emmc:
> + cmd += ' %d' % partid
> + response = u_boot_console.run_command(cmd)
> + assert 'no card present' not in response
> + if is_emmc:
> + partid_response = "(part %d)" % partid
> + else:
> + partid_response = ""
> + good_response = 'mmc%d%s is current device' % (devid,
> partid_response)
> + assert good_response in response
> +
> + # Write data
> + cmd = 'mmc write %s %x %x' % (src_addr, sector, count_sectors)
> + response = u_boot_console.run_command(cmd)
> + good_response = 'MMC write: dev # %d, block # %d, count %d ... %d
> blocks written: OK' % (
> + devid, sector, count_sectors, count_sectors)
> + assert good_response in response
> +
> + # Read data
> + cmd = 'mmc read %s %x %x' % (dst_addr, sector, count_sectors)
> + response = u_boot_console.run_command(cmd)
> + good_response = 'MMC read: dev # %d, block # %d, count %d ... %d
> blocks read: OK' % (
> + devid, sector, count_sectors, count_sectors)
> + assert good_response in response
> +
> + # Compare src and dst data
> + cmd = 'cmp.b %s %s %x' % (src_addr, dst_addr, count_bytes)
> + response = u_boot_console.run_command(cmd)
> + good_response = 'Total of %d byte(s) were the same' % (count_bytes)
> + assert good_response in response

Applied to mmc/master.

Thanks,
Peng

> --
> 2.17.1

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

Re: [U-Boot] [PATCH] mmc: sti_sdhci: Fix sdhci_setup_cfg() call.

[Peng Fan]

> Subject: [PATCH] mmc: sti_sdhci: Fix sdhci_setup_cfg() call.
> 
> host->mmc and host->mmc->dev must be set before calling
> sdhci_setup_cfg() to avoid hang during mmc initialization.
> 
> Thanks to commit 3d296365e4e8
> ("mmc: sdhci: Add support for sdhci-caps-mask") which put this issue into
> evidence.
> 
> Signed-off-by: Patrice Chotard 
> ---
> 
>  drivers/mmc/sti_sdhci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mmc/sti_sdhci.c b/drivers/mmc/sti_sdhci.c index
> 8ed47e113d..c7f1947edd 100644
> --- a/drivers/mmc/sti_sdhci.c
> +++ b/drivers/mmc/sti_sdhci.c
> @@ -97,14 +97,14 @@ static int sti_sdhci_probe(struct udevice *dev)
>  SDHCI_QUIRK_NO_HISPD_BIT;
> 
>   host->host_caps = MMC_MODE_DDR_52MHz;
> + host->mmc = >mmc;
> + host->mmc->dev = dev;
> 
>   ret = sdhci_setup_cfg(>cfg, host, 5000, 40);
>   if (ret)
>   return ret;
> 
> - host->mmc = >mmc;
>   host->mmc->priv = host;

Should this line also be moved?

Regards,
Peng

> - host->mmc->dev = dev;
>   upriv->mmc = host->mmc;
> 
>   return sdhci_probe(dev);
> --
> 2.17.1

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

Re: [U-Boot] [RFC PATCH 00/11] SPL support for RISC-V

[Auer, Lukas]

Hi Bin,

On Tue, 2019-07-23 at 16:32 +0800, Bin Meng wrote:
> Hi Lukas,
> 
> On Mon, Jul 22, 2019 at 2:00 AM Lukas Auer
>  wrote:
> > This series adds support for SPL to RISC-V U-Boot. Images can be booted
> > via OpenSBI (FW_DYNAMIC firmware) or by directly jumping to them. In the
> > former case, OpenSBI and U-Boot proper are bundled as a FIT image and
> > made available to U-Boot SPL. Currently, only the QEMU board enables
> > U-Boot SPL with a dedicated configuration. It uses RAM as SPL boot
> > device.
> > 
> > On many RISC-V CPUs, the device tree is provided to U-Boot by the
> > first stage bootloader. This requires changes to U-Boot SPL (patches 1,
> > 2 and 3), which modify the behavior on other boards as well. To get
> > feedback on this, I am therefore sending this series as RFC first.
> > 
> > To test this series, OpenSBI has to be compiled first. The
> > fw_dynamic.bin binary must be copied into the U-Boot root directory.
> > Alternatively, the location of the binary can be specified with the
> > OPENSBI environment variable. U-Boot can then be build as normal using
> > the configuration qemu-riscv64_spl_defconfig for 64-bit builds or
> > qemu-riscv32_spl_defconfig for 32-bit builds. The outputs from the build
> > process are the U-Boot SPL binary (spl/u-boot-spl.bin) and the U-Boot
> > FIT image (u-boot.itb) containing U-Boot proper and OpenSBI.
> > 
> > U-Boot can be run in QEMU with the following command.
> > 
> > qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \
> > -device loader,file=u-boot.itb,addr=0x8020
> > 
> 
> Nice job done! It looks the SPL support was cleanly implemented.
> 

Thank you very much! :)

> I've tested this series, on qemu-riscv64 with UP and SMP, both work fine.
> However when testing on qemu-riscv32, the U-Boot proper does not boot.
> Please have a look.
> 
> Regards,
> Bin

Thank you for reviewing and testing the series!

Do you mean that the U-Boot prompt does not appear? Testing the series
on qemu-riscv32, I get the U-Boot prompt from U-Boot proper. I did not
try to boot Linux on qemu-riscv32, however. I will try that tomorrow.

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

Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode

[Peng Fan]

> Subject: Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode
> 
> Hi Igor,
> 
> thanks for your comments! Is there any solution, patch or workaround I can
> try to power on the 2nd CPU core in secure mode with mainline kernel?

The upstream maintainer rejected the legacy method for i.MX7, so in upstream
psci was used, with psci, the kernel is booted in non-secure mode.

Regards,
Peng.

> 
> Thanks and best regards
> 
> Tobias
> 
> > I'm afraid you're right.
> > Just after a bit of time researching and discussing with Stefan, seems
> > that we need to introduce two different wrappers for booting the
> > mainline kernel and downstream NXP kernel.
> >
> > * NXP kernel has legacy code to enable all cores, which works only
> > when running in secure mode.
> > * Mainline kernel, as you said before, does use PSCI for this, which
> > is provided by U-boot (which adds proper psci nodes to the linux dtb
> > on-fly before transferring control to the linux kernel entry point).
> > When we try to load it in secure mode, it continues running on the
> > same Secure PL1, and communication using SMC calling convention
> > doesn't make sense at this case.
> 
> 

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

Re: [U-Boot] [PATCH u-boot-mmc 1/1] mmc: sdhci: Read cd-gpios instead of cd-gpio from devicetree

[Peng Fan]

> Subject: [PATCH u-boot-mmc 1/1] mmc: sdhci: Read cd-gpios instead of
> cd-gpio from devicetree
> 
> Linux's documentation (Documentation/devicetree/bindings/mmc/mmc.txt)
> says the property should be named cd-gpios, not cd-gpio. All the dts files use
> cd-gpios.

There was already a patch,
https://patchwork.ozlabs.org/patch/1135207/

Regards,
Peng.

> 
> Signed-off-by: Marek Behún 
> Cc: T Karthik Reddy 
> Cc: Michal Simek 
> Cc: Peng Fan 
> ---
>  drivers/mmc/sdhci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> c4e88790bc..d0e9cc55f6 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -594,7 +594,7 @@ static int sdhci_init(struct mmc *mmc)  #if
> CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
>   struct udevice *dev = mmc->dev;
> 
> - gpio_request_by_name(dev, "cd-gpio", 0,
> + gpio_request_by_name(dev, "cd-gpios", 0,
>>cd_gpio, GPIOD_IS_IN);
>  #endif
> 
> --
> 2.21.0

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

Re: [U-Boot] [PATCH] mmd: sdhci: fix non GPIO card detect

[Peng Fan]

> Subject: Re: [PATCH] mmd: sdhci: fix non GPIO card detect
> 
> Hi Faiz,
> 
> On Tue, Jul 23, 2019 at 04:47:47PM +0530, Faiz Abbas wrote:
> > On 23/07/19 4:16 PM, Baruch Siach wrote:
> > > On Tue, Jul 23, 2019 at 03:35:31PM +0530, Faiz Abbas wrote:
> > >> On 23/07/19 2:39 PM, Baruch Siach wrote:
> > >>> On Tue, Jul 23, 2019 at 02:27:28PM +0530, Faiz Abbas wrote:
> >  On 23/07/19 1:30 PM, Peng Fan wrote:
> > > + Faiz
> > >
> > >> Subject: [PATCH] mmd: sdhci: fix non GPIO card detect
> > >>
> > >> Some SD cards do not assert the SDHCI_CARD_PRESENT bit. Only
> > >> the SDHCI_CARD_DETECT_PIN_LEVEL is enabled. Consider that
> > >> enough for card detect indication.
> > >>
> > >> This fixes SD card access from SPL, since DM_GPIO is not
> > >> available in SPL code.
> > >>
> > >> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
> > >> Cc: T Karthik Reddy 
> > >> Cc: Michal Simek 
> > >> Signed-off-by: Baruch Siach 
> > >> ---
> > >>  drivers/mmc/sdhci.c | 2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >>
> > >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> > >> 2779bca93f08..17a28181fcca 100644
> > >> --- a/drivers/mmc/sdhci.c
> > >> +++ b/drivers/mmc/sdhci.c
> > >> @@ -683,7 +683,7 @@ int sdhci_get_cd(struct udevice *dev)
> > >>  }
> > >>  #endif
> > >>  value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> > >> -   SDHCI_CARD_PRESENT);
> > >> +   (SDHCI_CARD_PRESENT |
> SDHCI_CARD_DETECT_PIN_LEVEL));
> > >
> > > Faiz, are you fine with this change?
> > 
> >  Not really. The spec is pretty clear that DETECT_PIN_LEVEL is not
> >  to be trusted. Also how does the CARD_PRESENT assertion depend on
> >  the SD card you use? Are you normally muxing the SDCD line to the
> >  IP (for hardware to detect) or are you connecting it as a gpio which
> software must detect?
> > >>>
> > >>> I tested SanDisk 8GB SD card, class 10, UHS1, on Armada 388 based
> > >>> SolidRun Clearfog Base. The SDHCI_PRESENT_STATE register
> > >>> consistently reads 0x01f6, that is, CARD_PRESENT is disabled,
> DETECT_PIN_LEVEL is enabled.
> > >>>
> > >>> The SD card-detect GPIO is present at the hardware level, but it
> > >>> is not accessible from SPL code because there is currently no
> > >>> SPL_DM_GPIO. The main U-Boot image detects the SD card correctly
> > >>> (once the other MMC patches I posted are applied).
> > >>>
> > >>> Without this patch boot from SD card is broken. What is the right fix
> then?
> > >>
> > >> There are two choices to implement card detect:
> > >>
> > >> 1. Mux the card detect line from the SD card cage directly to the
> > >> host controller and expect PRESENT state register to indicate
> > >> whether card is present or not.
> > >>
> > >> 2. Mux the card detect line as a GPIO and use software
> > >> (dm_gpio_get_value() call) to detect whether card is present or
> > >> not. In that case, PRESENT_STATE[16,17,18] are completely useless
> > >> because there is no card detect line going into the IP.
> > >>
> > >> It seems that you are using #2. What confuses me is how any cards
> > >> are able to assert CARD_DETECT.
> > >
> > > As far as I can see the Armada 388 SD host controller does not
> > > provide option #1. The Clearfog indeed uses option #2. Until commit
> da18c62b6e6a4 ("mmc:
> > > sdhci: Implement SDHCI card detect") it used to work because the
> > > mv_sdhci driver does not implement the get_cd callback, so
> > > card-detect was ignored. Now we have a get_cd implementation at the
> > > sdhci level that returns 0 in SPL because the GPIO is not accessible.
> > >
> > > What would you suggest?
> >
> > You can just add your own get_cd() callback instead of using sdhci_get_cd().
> 
> I can do that, but I would still hit the basic problem. GPIOs are not 
> accessible
> from SPL when DM is enabled. I guess that would affect a few other
> platforms.
> 
> How about making an exception for SPL? Something like this:
> 
> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> 654931a82f54..03c132631d23 100644
> --- a/drivers/mmc/sdhci.c
> +++ b/drivers/mmc/sdhci.c
> @@ -672,6 +672,9 @@ int sdhci_get_cd(struct udevice *dev)
>   /* If polling, assume that the card is always present. */
>   if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
>   return 1;
> + /* In SPL we have no DM_GPIO access; assume card is present */

I think this assumption is wrong. It is not always true the DM_GPIO not
enabled in SPL.

Regards,
Peng.

> + if (IS_ENABLED(CONFIG_SPL_BUILD))
> + return 1;
> 
>  #if CONFIG_IS_ENABLED(DM_GPIO)
>   value = dm_gpio_get_value(>cd_gpio);
> 
> What do you think?
> 
> --
> 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbaruch.
> siach.name%2Fblog%2Fdata=02%7C01%7Cpeng.fan%40nxp.com%7C5
> 

Re: [U-Boot] [PATCH] mx6sabresd: Reduce overall SPL size

[Peng Fan]

> Subject: [PATCH] mx6sabresd: Reduce overall SPL size
> 
> Currently the SPL binary is 67 kB, which leaves only 1 kB of free internal RAM
> space.
> 
> The following options can be safely removed to save some precious SPL space:
> 
> - CONFIG_SPL_FS_EXT4: u-boot-dtb.img is stored in raw sector via dd
> command (at offset 69 kB)
> - CONFIG_SPL_I2C_SUPPORT: I2C is not used during SPL
> - CONFIG_SPL_OS_BOOT: no need to make Falcon mode supported by default
> 
> After this change the SPL binary size gets down to 51 kB.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/mx6sabresd_defconfig | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
> index 9400805831..84862feb8b 100644
> --- a/configs/mx6sabresd_defconfig
> +++ b/configs/mx6sabresd_defconfig
> @@ -23,9 +23,6 @@ CONFIG_BOUNCE_BUFFER=y
>  CONFIG_SPL_TEXT_BASE=0x00908000
>  CONFIG_SPL_SEPARATE_BSS=y
>  CONFIG_SPL_FIT_IMAGE_TINY=y
> -CONFIG_SPL_FS_EXT4=y
> -CONFIG_SPL_I2C_SUPPORT=y
> -CONFIG_SPL_OS_BOOT=y
>  CONFIG_SPL_USB_HOST_SUPPORT=y
>  CONFIG_SPL_USB_GADGET=y
>  CONFIG_SPL_USB_SDP_SUPPORT=y

Reviewed-by: Peng Fan 

> --
> 2.17.1

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

Re: [U-Boot] [PATCH v2] net: davinci_emac: convert to using the driver model

[Joe Hershberger]

On Mon, Jun 24, 2019 at 9:22 AM Bartosz Golaszewski  wrote:
>
> From: Bartosz Golaszewski 
>
> Now that we removed all legacy boards selecting TI_EMAC we can
> completely convert the driver code to using the driver model.
> This patch also updates all remaining users of davinci_emac.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - moved the packetp assignment to the top of the recv() callback which fixes
>   a crash on am3517_evm
> - dropped a redundant call to net_process_received_packet(): this is already
>   called from eth core
>
> Thanks goes to Adam Ford for much appreciated testing and help.
>
> Tested on da850-lcdk and da850-evm.

Looks like a build failure on this patch...

https://travis-ci.org/jhershbe/u-boot/jobs/562799958

Can you have a look?

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

Re: [U-Boot] [PATCH v2 00/18] autoboot: Tidy up autoboot code

[Lukasz Majewski]

Hi Simon,

> This series cleans up autoboot.c a bit to:
> 
> - Convert options to Kconfig
> - Use C code instead of C preprocessor where possible
> - Add a few comments
> 

Thanks Simon for this clean up series.

Reviewed-by: Lukasz Majewski 

> Changes in v2:
> - Rebase to master
> 
> Simon Glass (18):
>   main: Use conditional run_preboot_environment_command()
>   Convert CONFIG_SHOW_BOOT_PROGRESS to Kconfig
>   Add CONFIG_USE_PREBOOT to boards that use CONFIG_PREBOOT
>   Convert CONFIG_USE_PREBOOT and CONFIG_PREBOOT to Kconfig
>   autoboot: Use CONFIG_AUTOBOOT_STOP_STR_SHA256 indirectly
>   autoboot: Drop #ifdef for CONFIG_AUTOBOOT_ENCRYPTION
>   autoboot: Improve docs for CONFIG_AUTOBOOT_ENCRYPTION
>   autoboot: Use if() for CONFIG_SILENT_CONSOLE
>   autoboot: Drop #ifdef CONFIG_AUTOBOOT_KEYED
>   autoboot: Drop unused CONFIG_MENUPROMPT
>   autoboot: Rename CONFIG_MENUKEY to CONFIG_AUTOBOOT_MENUKEY
>   snow: Define CONFIG_AUTOBOOT_MENUKEY
>   autoboot: Tidy up use of menukey
>   autoboot: Rename CONFIG_MENU_SHOW to include AUTOBOOT
>   Convert CONFIG_AUTOBOOT_MENU_SHOW to Kconfig
>   autoboot: Add comments for menu_show()
>   autoboot: Move a few more options from #ifdef to if()
>   autoboot: Adjust the implementation in autoboot_command()
> 
>  README| 167
> +- cmd/Kconfig   |
> 34 +++- cmd/bootmenu.c|   2 +-
>  common/Kconfig| 162 +
>  common/autoboot.c | 121 +++--
>  common/main.c |   5 +-
>  configs/A10-OLinuXino-Lime_defconfig  |   1 +
>  configs/A10s-OLinuXino-M_defconfig|   1 +
>  configs/A13-OLinuXinoM_defconfig  |   1 +
>  configs/A13-OLinuXino_defconfig   |   1 +
>  configs/A20-OLinuXino-Lime2-eMMC_defconfig|   1 +
>  configs/A20-OLinuXino-Lime2_defconfig |   1 +
>  configs/A20-OLinuXino-Lime_defconfig  |   1 +
>  configs/A20-OLinuXino_MICRO-eMMC_defconfig|   1 +
>  configs/A20-OLinuXino_MICRO_defconfig |   1 +
>  configs/A20-Olimex-SOM-EVB_defconfig  |   1 +
>  configs/A20-Olimex-SOM204-EVB-eMMC_defconfig  |   1 +
>  configs/A20-Olimex-SOM204-EVB_defconfig   |   1 +
>  configs/A33-OLinuXino_defconfig   |   1 +
>  configs/Ainol_AW1_defconfig   |   1 +
>  configs/Ampe_A76_defconfig|   1 +
>  configs/Auxtek-T003_defconfig |   1 +
>  configs/Auxtek-T004_defconfig |   1 +
>  configs/Bananapi_M2_Ultra_defconfig   |   1 +
>  configs/Bananapi_defconfig|   1 +
>  configs/Bananapi_m2m_defconfig|   1 +
>  configs/Bananapro_defconfig   |   1 +
>  configs/CHIP_defconfig|   1 +
>  configs/CHIP_pro_defconfig|   1 +
>  configs/CSQ_CS908_defconfig   |   1 +
>  configs/Chuwi_V7_CW0825_defconfig |   1 +
>  configs/Colombus_defconfig|   1 +
>  configs/Cubieboard2_defconfig |   1 +
>  configs/Cubieboard4_defconfig |   1 +
>  configs/Cubieboard_defconfig  |   1 +
>  configs/Cubietruck_defconfig  |   1 +
>  configs/Cubietruck_plus_defconfig |   1 +
>  configs/Empire_electronix_d709_defconfig  |   1 +
>  configs/Empire_electronix_m712_defconfig  |   1 +
>  configs/Hummingbird_A31_defconfig |   1 +
>  configs/Hyundai_A7HD_defconfig|   1 +
>  configs/Itead_Ibox_A20_defconfig  |   1 +
>  configs/Lamobo_R1_defconfig   |   1 +
>  configs/LicheePi_Zero_defconfig   |   1 +
>  configs/Linksprite_pcDuino3_Nano_defconfig|   1 +
>  configs/Linksprite_pcDuino3_defconfig |   1 +
>  configs/Linksprite_pcDuino_defconfig  |   1 +
>  configs/MK808C_defconfig  |   1 +
>  configs/MPC8349EMDS_PCI64_defconfig   |   2 +
>  configs/MPC8349EMDS_SLAVE_defconfig   |   2 +
>  configs/MPC8349EMDS_defconfig |   2 +
>  configs/MSI_Primo73_defconfig |   1 +
>  configs/MSI_Primo81_defconfig |   1 +
>  configs/Marsboard_A10_defconfig   |   1 +
>  configs/Mele_A1000G_quad_defconfig|   1 +
>  configs/Mele_A1000_defconfig  |   1 +
>  configs/Mele_I7_defconfig |   1 +
>  configs/Mele_M3_defconfig |   1 +
>  configs/Mele_M5_defconfig |   1 +
>  configs/Mele_M9_defconfig |   1 +
>  configs/Merrii_A80_Optimus_defconfig  |   1 +
>  configs/Mini-X_defconfig  |   1 +
>  .../Nintendo_NES_Classic_Edition_defconfig|   1 +
>  configs/Orangepi_defconfig|   1 +
>  configs/Orangepi_mini_defconfig   

Re: [U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Nemanja Savic]

Thank you Adam for your answer. Sounds like a good starting point for me.
Additionally I would like to ask you further questions regarding your
answers.

> 3. Is device tree used by u-boot the same device tree later used by linu
>
>> > kernel?
>>
>> On my imx6q_logic board, the device tree is appended to the code, but
>> it's only used for U-Boot and or SPL.  SPL is the secondary program
>> loader, and it has a much reduced device tree because of the limited
>> space.  I load a separate device tree for the kernel, because I keep
>> the kernels and their respecive device trees in sync to prevent
>> issues.
>>
>
Does that mean that dtb is already part of the u-boot image? After making
mx6sabreauto_defconfig, the u-boot binary is called something like (I am
not at work at the moment) uboot-dtb.imx, which might imply that dtb is
already part of the binary?

Another question is, which macro or function should I use to print simple
debug messages from the driver function such as probe, etc ...?

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

Re: [U-Boot] [PATCH 0/6] arm: socfpga: gen5: DM improvements

[Simon Goldschmidt]

Am 23.07.2019 um 22:27 schrieb Simon Goldschmidt:

This series ports more ad-hoc code to DM drivers (reset, clk, timer).


This is how far I got with DM/DTS "conversion" for now. Converting from 
"board/qts/*.h" to DTS is still pending since I yet failed to find a 
solution that allows FPGA images to define different clock or I/O 
requirements without requiring Linux drivers for clock or pinmux...


Converting from "board/qts/*.h" to U-Boot devicetree is probably not too 
hard, but reconfiguration after configuring the FPGA (e.g. from FIT) 
requires more work.


BTW, we're now quite short on SRAM in SPL. Next steps on this platform 
might require to separate "boot from MMC" and "boot from QSPI" to reduce 
SRAM usage.


Regards,
Simon




Simon Goldschmidt (6):
   ddr: socfpga: gen5: constify altera_gen5_sdram_ops
   arm: socfpga: gen5: increase SPL_SYS_MALLOC_F_LEN
   timer: dw-apb: add reset handling
   arm: socfpga: gen5: move initial reset handling to reset driver
   arm: socfpga: gen5: add readonly clk driver
   arm: socfpga: gen5: use DM_TIMER for systick

  MAINTAINERS   |   1 +
  arch/arm/dts/socfpga-common-u-boot.dtsi   |  78 
  arch/arm/dts/socfpga.dtsi |   5 +
  .../dts/socfpga_cyclone5_socrates-u-boot.dtsi |   1 +
  .../socfpga_cyclone5_socrates_handoff.dtsi|  26 ++
  arch/arm/mach-socfpga/Kconfig |   7 +-
  arch/arm/mach-socfpga/Makefile|   1 -
  arch/arm/mach-socfpga/reset_manager_gen5.c|  13 -
  arch/arm/mach-socfpga/spl_gen5.c  |  24 +-
  arch/arm/mach-socfpga/timer.c |  23 --
  drivers/clk/altera/Makefile   |   1 +
  drivers/clk/altera/clk-gen5.c | 338 ++
  drivers/ddr/altera/sdram_gen5.c   |   2 +-
  drivers/timer/dw-apb-timer.c  |  18 +-
  14 files changed, 483 insertions(+), 55 deletions(-)
  create mode 100644 arch/arm/dts/socfpga_cyclone5_socrates_handoff.dtsi
  delete mode 100644 arch/arm/mach-socfpga/timer.c
  create mode 100644 drivers/clk/altera/clk-gen5.c



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

[U-Boot] [PATCH 3/6] timer: dw-apb: add reset handling

[Simon Goldschmidt]

To use this timer on socfpga as system tick, it needs to take itself out
of reset.

Signed-off-by: Simon Goldschmidt 
---

 drivers/timer/dw-apb-timer.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/timer/dw-apb-timer.c b/drivers/timer/dw-apb-timer.c
index 86312b8dc7..fad22be8c9 100644
--- a/drivers/timer/dw-apb-timer.c
+++ b/drivers/timer/dw-apb-timer.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -18,7 +19,8 @@
 #define DW_APB_CTRL0x8
 
 struct dw_apb_timer_priv {
-   fdt_addr_t  regs;
+   fdt_addr_t regs;
+   struct reset_ctl_bulk resets;
 };
 
 static int dw_apb_timer_get_count(struct udevice *dev, u64 *count)
@@ -42,6 +44,12 @@ static int dw_apb_timer_probe(struct udevice *dev)
struct clk clk;
int ret;
 
+   ret = reset_get_bulk(dev, >resets);
+   if (ret)
+   dev_warn(dev, "Can't get reset: %d\n", ret);
+   else
+   reset_deassert_bulk(>resets);
+
ret = clk_get_by_index(dev, 0, );
if (ret)
return ret;
@@ -67,6 +75,13 @@ static int dw_apb_timer_ofdata_to_platdata(struct udevice 
*dev)
return 0;
 }
 
+static int dw_apb_timer_remove(struct udevice *dev)
+{
+   struct dw_apb_timer_priv *priv = dev_get_priv(dev);
+
+   return reset_release_bulk(>resets);
+}
+
 static const struct timer_ops dw_apb_timer_ops = {
.get_count  = dw_apb_timer_get_count,
 };
@@ -83,5 +98,6 @@ U_BOOT_DRIVER(dw_apb_timer) = {
.probe  = dw_apb_timer_probe,
.of_match   = dw_apb_timer_ids,
.ofdata_to_platdata = dw_apb_timer_ofdata_to_platdata,
+   .remove = dw_apb_timer_remove,
.priv_auto_alloc_size = sizeof(struct dw_apb_timer_priv),
 };
-- 
2.20.1

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

[U-Boot] [PATCH 6/6] arm: socfpga: gen5: use DM_TIMER for systick

[Simon Goldschmidt]

This removes the ad-hoc timer code in arch.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/dts/socfpga-common-u-boot.dtsi |  8 
 arch/arm/mach-socfpga/Kconfig   |  3 +++
 arch/arm/mach-socfpga/Makefile  |  1 -
 arch/arm/mach-socfpga/spl_gen5.c|  3 ---
 arch/arm/mach-socfpga/timer.c   | 23 ---
 5 files changed, 11 insertions(+), 27 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/timer.c

diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi 
b/arch/arm/dts/socfpga-common-u-boot.dtsi
index 270ba99a63..e0305d7fc7 100644
--- a/arch/arm/dts/socfpga-common-u-boot.dtsi
+++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
@@ -5,6 +5,10 @@
  * Copyright (c) 2019 Simon Goldschmidt
  */
 /{
+   chosen {
+   tick-timer = 
+   };
+
soc {
u-boot,dm-pre-reloc;
clkmgr@ffd04000 {
@@ -16,6 +20,10 @@
};
 };
 
+ {
+   u-boot,dm-pre-reloc;
+};
+
  {
u-boot,dm-pre-reloc;
 };
diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 81052f27d5..518ac8ec4a 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -56,6 +56,9 @@ config TARGET_SOCFPGA_GEN5
select CLK
select SPL_ALTERA_SDRAM
select SPL_CLK if SPL
+   select SPL_TIMER if SPL
+   select TIMER
+   imply DESIGNWARE_APB_TIMER
imply FPGA_SOCFPGA
imply SPL_SIZE_LIMIT_SUBTRACT_GD
imply SPL_SIZE_LIMIT_SUBTRACT_MALLOC
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..3b839c9ffd 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -16,7 +16,6 @@ obj-y += misc_gen5.o
 obj-y  += reset_manager_gen5.o
 obj-y  += scan_manager.o
 obj-y  += system_manager_gen5.o
-obj-y  += timer.o
 obj-y  += wrap_pll_config.o
 obj-y  += fpga_manager.o
 endif
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index 1ae8025746..7a67f538d8 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -103,9 +103,6 @@ void board_init_f(ulong dummy)
socfpga_bridges_reset(1);
}
 
-   socfpga_per_reset(SOCFPGA_RESET(OSC1TIMER0), 0);
-   timer_init();
-
debug("Reconfigure Clock Manager\n");
/* reconfigure the PLLs */
if (cm_basic_init(cm_default_cfg))
diff --git a/arch/arm/mach-socfpga/timer.c b/arch/arm/mach-socfpga/timer.c
deleted file mode 100644
index f1c0262ae5..00
--- a/arch/arm/mach-socfpga/timer.c
+++ /dev/null
@@ -1,23 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- *  Copyright (C) 2012 Altera Corporation 
- */
-
-#include 
-#include 
-#include 
-
-#define TIMER_LOAD_VAL 0x
-
-static const struct socfpga_timer *timer_base = (void *)CONFIG_SYS_TIMERBASE;
-
-/*
- * Timer initialization
- */
-int timer_init(void)
-{
-   writel(TIMER_LOAD_VAL, _base->load_val);
-   writel(TIMER_LOAD_VAL, _base->curr_val);
-   writel(readl(_base->ctrl) | 0x3, _base->ctrl);
-   return 0;
-}
-- 
2.20.1

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

[U-Boot] [PATCH 4/6] arm: socfpga: gen5: move initial reset handling to reset driver

[Simon Goldschmidt]

This moves disabling all peripherals from ad-hoc code in arch/arm
to the socfpga reset driver.

To do this, DM initialization and UCLASS_RESET probing has to be done
earlier in the SPL.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/mach-socfpga/reset_manager_gen5.c | 13 -
 arch/arm/mach-socfpga/spl_gen5.c   | 21 +
 2 files changed, 9 insertions(+), 25 deletions(-)

diff --git a/arch/arm/mach-socfpga/reset_manager_gen5.c 
b/arch/arm/mach-socfpga/reset_manager_gen5.c
index 9a32f5abfe..34e59b852b 100644
--- a/arch/arm/mach-socfpga/reset_manager_gen5.c
+++ b/arch/arm/mach-socfpga/reset_manager_gen5.c
@@ -48,19 +48,6 @@ void socfpga_per_reset(u32 reset, int set)
clrbits_le32(reg, 1 << RSTMGR_RESET(reset));
 }
 
-/*
- * Assert reset on every peripheral but L4WD0.
- * Watchdog must be kept intact to prevent glitches
- * and/or hangs.
- */
-void socfpga_per_reset_all(void)
-{
-   const u32 l4wd0 = 1 << RSTMGR_RESET(SOCFPGA_RESET(L4WD0));
-
-   writel(~l4wd0, _manager_base->per_mod_reset);
-   writel(0x, _manager_base->per2_mod_reset);
-}
-
 #define L3REGS_REMAP_LWHPS2FPGA_MASK   0x10
 #define L3REGS_REMAP_HPS2FPGA_MASK 0x08
 #define L3REGS_REMAP_OCRAM_MASK0x01
diff --git a/arch/arm/mach-socfpga/spl_gen5.c b/arch/arm/mach-socfpga/spl_gen5.c
index 87b76b47de..1ae8025746 100644
--- a/arch/arm/mach-socfpga/spl_gen5.c
+++ b/arch/arm/mach-socfpga/spl_gen5.c
@@ -84,12 +84,19 @@ void board_init_f(ulong dummy)
socfpga_sdram_remap_zero();
socfpga_pl310_clear();
 
+   ret = spl_early_init();
+   if (ret) {
+   debug("spl_early_init() failed: %d\n", ret);
+   hang();
+   }
+
debug("Freezing all I/O banks\n");
/* freeze all IO banks */
sys_mgr_frzctrl_freeze_req();
 
-   /* Put everything into reset but L4WD0. */
-   socfpga_per_reset_all();
+   ret = uclass_get_device(UCLASS_RESET, 0, );
+   if (ret)
+   debug("Reset init failed: %d\n", ret);
 
if (!socfpga_is_booting_from_fpga()) {
/* Put FPGA bridges into reset too. */
@@ -130,16 +137,6 @@ void board_init_f(ulong dummy)
debug_uart_init();
 #endif
 
-   ret = spl_early_init();
-   if (ret) {
-   debug("spl_early_init() failed: %d\n", ret);
-   hang();
-   }
-
-   ret = uclass_get_device(UCLASS_RESET, 0, );
-   if (ret)
-   debug("Reset init failed: %d\n", ret);
-
/* enable console uart printing */
preloader_console_init();
 
-- 
2.20.1

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

[U-Boot] [PATCH 2/6] arm: socfpga: gen5: increase SPL_SYS_MALLOC_F_LEN

[Simon Goldschmidt]

In preparation to adding more DM based drivers, increase the SPL
pre-relocation heap just enough to allow those new drivers to run.

Signed-off-by: Simon Goldschmidt 
---

 arch/arm/mach-socfpga/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 1d914648e3..9efdcd6f10 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -13,7 +13,7 @@ config SPL_STACK_R_ADDR
default 0x0080 if TARGET_SOCFPGA_GEN5
 
 config SPL_SYS_MALLOC_F_LEN
-   default 0x800 if TARGET_SOCFPGA_GEN5
+   default 0x1100 if TARGET_SOCFPGA_GEN5
 
 config SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE
default 0xa2
-- 
2.20.1

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

[U-Boot] [PATCH 5/6] arm: socfpga: gen5: add readonly clk driver

[Simon Goldschmidt]

This adds clk-gen5 as a readonly DM_CLK driver that can return clocks for
the peripherals.

Further changes are:
- select DM_CLK for gen5 U-Boot and SPL
- add SPL tags to clock nodes in socfpga-common-u-boot.dtsi
- adjust socfpga.dtsi to provide missing src selection registers
- start 'handoff.dtsi' file for socrates (conatains clock speeds for now)

Signed-off-by: Simon Goldschmidt 
---

 MAINTAINERS   |   1 +
 arch/arm/dts/socfpga-common-u-boot.dtsi   |  70 
 arch/arm/dts/socfpga.dtsi |   5 +
 .../dts/socfpga_cyclone5_socrates-u-boot.dtsi |   1 +
 .../socfpga_cyclone5_socrates_handoff.dtsi|  26 ++
 arch/arm/mach-socfpga/Kconfig |   2 +
 drivers/clk/altera/Makefile   |   1 +
 drivers/clk/altera/clk-gen5.c | 338 ++
 8 files changed, 444 insertions(+)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_socrates_handoff.dtsi
 create mode 100644 drivers/clk/altera/clk-gen5.c

diff --git a/MAINTAINERS b/MAINTAINERS
index a7d626..b7a9a2671f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -94,6 +94,7 @@ M:Simon Goldschmidt 
 S: Maintainted
 T: git https://gitlab.denx.de/u-boot/custodians/u-boot-socfpga.git
 F: arch/arm/mach-socfpga/
+F: drivers/clk/altera/clk-gen5.c
 
 ARM AMLOGIC SOC SUPPORT
 M: Neil Armstrong 
diff --git a/arch/arm/dts/socfpga-common-u-boot.dtsi 
b/arch/arm/dts/socfpga-common-u-boot.dtsi
index 322c858c4b..270ba99a63 100644
--- a/arch/arm/dts/socfpga-common-u-boot.dtsi
+++ b/arch/arm/dts/socfpga-common-u-boot.dtsi
@@ -7,6 +7,12 @@
 /{
soc {
u-boot,dm-pre-reloc;
+   clkmgr@ffd04000 {
+   u-boot,dm-pre-reloc;
+   clocks {
+   u-boot,dm-pre-reloc;
+   };
+   };
};
 };
 
@@ -17,3 +23,67 @@
  {
u-boot,dm-pre-reloc;
 };
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+_periph_ref_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_pll {
+   u-boot,dm-pre-reloc;
+};
+
+ {
+   u-boot,dm-pre-reloc;
+};
+
+_qspi_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_nand_sdmmc_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_pll {
+   u-boot,dm-pre-reloc;
+};
+
+_qspi_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_nand_mmc_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_base_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_mp_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_sp_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_clk {
+   u-boot,dm-pre-reloc;
+};
+
+_clk_divided {
+   u-boot,dm-pre-reloc;
+};
+
+_clk {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi
index 51a6a51b53..319334899b 100644
--- a/arch/arm/dts/socfpga.dtsi
+++ b/arch/arm/dts/socfpga.dtsi
@@ -332,6 +332,7 @@
compatible = 
"altr,socfpga-gate-clk";
clocks = <>, 
<_base_clk>;
div-reg = <0x64 4 3>;
+   src-reg = <0x70 0 1>;
clk-gate = <0x60 2>;
};
 
@@ -340,6 +341,7 @@
compatible = 
"altr,socfpga-gate-clk";
clocks = <>, 
<_base_clk>;
div-reg = <0x64 7 3>;
+   src-reg = <0x70 1 1>;
clk-gate = <0x60 3>;
};
 
@@ -453,6 +455,7 @@
#clock-cells = <0>;
compatible = 
"altr,socfpga-gate-clk";
clocks = <_periph_ref_clk>, 
<_nand_sdmmc_clk>, <_nand_mmc_clk>;
+   src-reg = <0xac 0 2>;
clk-gate = <0xa0 8>;
clk-phase = <0 135>;
};
@@ -469,6 +472,7 @@
#clock-cells = <0>;
compatible = 
"altr,socfpga-gate-clk";
clocks = <_periph_ref_clk>, 
<_nand_sdmmc_clk>, <_nand_mmc_clk>;
+   src-reg = <0xac 2 2>;
clk-gate = <0xa0 9>;
};
 
@@ -491,6 +495,7 @@
#clock-cells = <0>;
compatible = 
"altr,socfpga-gate-clk";
clocks = <_periph_ref_clk>, 

[U-Boot] [PATCH 1/6] ddr: socfpga: gen5: constify altera_gen5_sdram_ops

[Simon Goldschmidt]

Make the function pointer struct const, as it does not need to be
writable. This doesn't really change anything other than moving this
variable to a different section. No functional change.

Signed-off-by: Simon Goldschmidt 
---

 drivers/ddr/altera/sdram_gen5.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/altera/sdram_gen5.c b/drivers/ddr/altera/sdram_gen5.c
index fcd89b619d..8c8ea19eb9 100644
--- a/drivers/ddr/altera/sdram_gen5.c
+++ b/drivers/ddr/altera/sdram_gen5.c
@@ -626,7 +626,7 @@ static int altera_gen5_sdram_get_info(struct udevice *dev,
return 0;
 }
 
-static struct ram_ops altera_gen5_sdram_ops = {
+static const struct ram_ops altera_gen5_sdram_ops = {
.get_info = altera_gen5_sdram_get_info,
 };
 
-- 
2.20.1

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

[U-Boot] [PATCH 0/6] arm: socfpga: gen5: DM improvements

[Simon Goldschmidt]

This series ports more ad-hoc code to DM drivers (reset, clk, timer).


Simon Goldschmidt (6):
  ddr: socfpga: gen5: constify altera_gen5_sdram_ops
  arm: socfpga: gen5: increase SPL_SYS_MALLOC_F_LEN
  timer: dw-apb: add reset handling
  arm: socfpga: gen5: move initial reset handling to reset driver
  arm: socfpga: gen5: add readonly clk driver
  arm: socfpga: gen5: use DM_TIMER for systick

 MAINTAINERS   |   1 +
 arch/arm/dts/socfpga-common-u-boot.dtsi   |  78 
 arch/arm/dts/socfpga.dtsi |   5 +
 .../dts/socfpga_cyclone5_socrates-u-boot.dtsi |   1 +
 .../socfpga_cyclone5_socrates_handoff.dtsi|  26 ++
 arch/arm/mach-socfpga/Kconfig |   7 +-
 arch/arm/mach-socfpga/Makefile|   1 -
 arch/arm/mach-socfpga/reset_manager_gen5.c|  13 -
 arch/arm/mach-socfpga/spl_gen5.c  |  24 +-
 arch/arm/mach-socfpga/timer.c |  23 --
 drivers/clk/altera/Makefile   |   1 +
 drivers/clk/altera/clk-gen5.c | 338 ++
 drivers/ddr/altera/sdram_gen5.c   |   2 +-
 drivers/timer/dw-apb-timer.c  |  18 +-
 14 files changed, 483 insertions(+), 55 deletions(-)
 create mode 100644 arch/arm/dts/socfpga_cyclone5_socrates_handoff.dtsi
 delete mode 100644 arch/arm/mach-socfpga/timer.c
 create mode 100644 drivers/clk/altera/clk-gen5.c

-- 
2.20.1

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

Re: [U-Boot] [PATCH 19/24] rockchip: rk3328: Migrate to use common board file

[Matwey V. Kornilov]

22.07.2019 15:02, Kever Yang пишет:
> Use common board file for board_init() and board_late_init(),
> for Rockchip SoCs have very similar process.
> 
> Signed-off-by: Kever Yang 

Tested-by: Matwey V. Kornilov 

Hi,

I've just checked that rock64-rk3328_defconfig is still bootable with
this series.

> ---
> 
>  arch/arm/mach-rockchip/Kconfig |  1 +
>  board/rockchip/evb_rk3328/evb-rk3328.c | 64 --
>  2 files changed, 1 insertion(+), 64 deletions(-)
> 
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index b75c209b66..2b8bb8aa25 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -110,6 +110,7 @@ config ROCKCHIP_RK3328
>   select ARM64
>   select SUPPORT_SPL
>   select SPL
> + imply ROCKCHIP_COMMON_BOARD
>   imply SPL_ROCKCHIP_COMMON_BOARD
>   imply SPL_SERIAL_SUPPORT
>   imply SPL_SEPARATE_BSS
> diff --git a/board/rockchip/evb_rk3328/evb-rk3328.c 
> b/board/rockchip/evb_rk3328/evb-rk3328.c
> index 64595c783d..779bc646b2 100644
> --- a/board/rockchip/evb_rk3328/evb-rk3328.c
> +++ b/board/rockchip/evb_rk3328/evb-rk3328.c
> @@ -3,67 +3,3 @@
>   * (C) Copyright 2016 Rockchip Electronics Co., Ltd
>   */
>  
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -DECLARE_GLOBAL_DATA_PTR;
> -
> -int board_init(void)
> -{
> - int ret;
> -
> - ret = regulators_enable_boot_on(false);
> - if (ret)
> - debug("%s: Cannot enable boot on regulator\n", __func__);
> -
> - return ret;
> -}
> -
> -#if defined(CONFIG_USB_GADGET) && defined(CONFIG_USB_GADGET_DWC2_OTG)
> -#include 
> -#include 
> -
> -static struct dwc2_plat_otg_data otg_data = {
> - .rx_fifo_sz = 512,
> - .np_tx_fifo_sz  = 16,
> - .tx_fifo_sz = 128,
> -};
> -
> -int board_usb_init(int index, enum usb_init_type init)
> -{
> - int node;
> - const char *mode;
> - bool matched = false;
> - const void *blob = gd->fdt_blob;
> -
> - /* find the usb_otg node */
> - node = fdt_node_offset_by_compatible(blob, -1,
> - "snps,dwc2");
> -
> - while (node > 0) {
> - mode = fdt_getprop(blob, node, "dr_mode", NULL);
> - if (mode && strcmp(mode, "otg") == 0) {
> - matched = true;
> - break;
> - }
> -
> - node = fdt_node_offset_by_compatible(blob, node,
> - "snps,dwc2");
> - }
> - if (!matched) {
> - debug("Not found usb_otg device\n");
> - return -ENODEV;
> - }
> - otg_data.regs_otg = fdtdec_get_addr(blob, node, "reg");
> -
> - return dwc2_udc_probe(_data);
> -}
> -
> -int board_usb_cleanup(int index, enum usb_init_type init)
> -{
> - return 0;
> -}
> -#endif
> 


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

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Marek Vasut]

On 7/23/19 9:27 PM, Simon Goldschmidt wrote:
> Am 23.07.2019 um 21:26 schrieb Marek Vasut:
>> On 7/23/19 9:12 PM, Simon Goldschmidt wrote:
>>> Am 23.07.2019 um 21:09 schrieb Marek Vasut:
 On 7/23/19 8:37 PM, Simon Goldschmidt wrote:
> Am 21.07.2019 um 12:45 schrieb Marek Vasut:
>> On 7/15/19 9:47 PM, Simon Goldschmidt wrote:
>>> This adds a define for the bit in rstmgr's ctrl regiser that issues
>>> a cold reset (we had a define for the warm reset bit only) in
>>> preparation
>>> for a proper sysrese driver.
>>>
>>
>> Applied all four, thanks.
>>
>
> Where did you push these? I see them at gitlab but not on github, is
> your github mirror dead then?

 https://github.com/marex/u-boot-socfpga/commits/master lists them just
 fine. Note that gitlab is the primary repo.

>>>
>>> Hmm, right. Sorry, I must have done something wrong.
>>>
>>> I have been using github as upstream
>>
>> It never was upstream, please don't use it as such. It's a necessary
>> mirror for the travis CI, that's all.
>>
> 
> Noted. Given the bad connectivity to the old denx git, I sometimes had
> no other option. I hope that's better now.

I never had those problems, but the gitlab instance is on a different
server. If you have connectivity issues, please report them.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Simon Goldschmidt]

Am 23.07.2019 um 21:26 schrieb Marek Vasut:

On 7/23/19 9:12 PM, Simon Goldschmidt wrote:

Am 23.07.2019 um 21:09 schrieb Marek Vasut:

On 7/23/19 8:37 PM, Simon Goldschmidt wrote:

Am 21.07.2019 um 12:45 schrieb Marek Vasut:

On 7/15/19 9:47 PM, Simon Goldschmidt wrote:

This adds a define for the bit in rstmgr's ctrl regiser that issues
a cold reset (we had a define for the warm reset bit only) in
preparation
for a proper sysrese driver.



Applied all four, thanks.



Where did you push these? I see them at gitlab but not on github, is
your github mirror dead then?


https://github.com/marex/u-boot-socfpga/commits/master lists them just
fine. Note that gitlab is the primary repo.



Hmm, right. Sorry, I must have done something wrong.

I have been using github as upstream


It never was upstream, please don't use it as such. It's a necessary
mirror for the travis CI, that's all.



Noted. Given the bad connectivity to the old denx git, I sometimes had 
no other option. I hope that's better now.


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

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Marek Vasut]

On 7/23/19 9:12 PM, Simon Goldschmidt wrote:
> Am 23.07.2019 um 21:09 schrieb Marek Vasut:
>> On 7/23/19 8:37 PM, Simon Goldschmidt wrote:
>>> Am 21.07.2019 um 12:45 schrieb Marek Vasut:
 On 7/15/19 9:47 PM, Simon Goldschmidt wrote:
> This adds a define for the bit in rstmgr's ctrl regiser that issues
> a cold reset (we had a define for the warm reset bit only) in
> preparation
> for a proper sysrese driver.
>

 Applied all four, thanks.

>>>
>>> Where did you push these? I see them at gitlab but not on github, is
>>> your github mirror dead then?
>>
>> https://github.com/marex/u-boot-socfpga/commits/master lists them just
>> fine. Note that gitlab is the primary repo.
>>
> 
> Hmm, right. Sorry, I must have done something wrong.
> 
> I have been using github as upstream

It never was upstream, please don't use it as such. It's a necessary
mirror for the travis CI, that's all.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Simon Goldschmidt]

Am 23.07.2019 um 21:09 schrieb Marek Vasut:

On 7/23/19 8:37 PM, Simon Goldschmidt wrote:

Am 21.07.2019 um 12:45 schrieb Marek Vasut:

On 7/15/19 9:47 PM, Simon Goldschmidt wrote:

This adds a define for the bit in rstmgr's ctrl regiser that issues
a cold reset (we had a define for the warm reset bit only) in
preparation
for a proper sysrese driver.



Applied all four, thanks.



Where did you push these? I see them at gitlab but not on github, is
your github mirror dead then?


https://github.com/marex/u-boot-socfpga/commits/master lists them just
fine. Note that gitlab is the primary repo.



Hmm, right. Sorry, I must have done something wrong.

I have been using github as upstream because of denx.de performance 
issues. I have now switched to gitlab, let's see if performance stays as 
good as it is now :-)


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

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Marek Vasut]

On 7/23/19 8:37 PM, Simon Goldschmidt wrote:
> Am 21.07.2019 um 12:45 schrieb Marek Vasut:
>> On 7/15/19 9:47 PM, Simon Goldschmidt wrote:
>>> This adds a define for the bit in rstmgr's ctrl regiser that issues
>>> a cold reset (we had a define for the warm reset bit only) in
>>> preparation
>>> for a proper sysrese driver.
>>>
>>
>> Applied all four, thanks.
>>
> 
> Where did you push these? I see them at gitlab but not on github, is
> your github mirror dead then?

https://github.com/marex/u-boot-socfpga/commits/master lists them just
fine. Note that gitlab is the primary repo.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 1/4] arm: socfpga: rst: add register definition for cold reset

[Simon Goldschmidt]

Am 21.07.2019 um 12:45 schrieb Marek Vasut:

On 7/15/19 9:47 PM, Simon Goldschmidt wrote:

This adds a define for the bit in rstmgr's ctrl regiser that issues
a cold reset (we had a define for the warm reset bit only) in preparation
for a proper sysrese driver.



Applied all four, thanks.



Where did you push these? I see them at gitlab but not on github, is 
your github mirror dead then?


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

Re: [U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Adam Ford]

On Tue, Jul 23, 2019 at 12:32 PM Nemanja Savic  wrote:
>
> Hi all list members,
>
> this is my first post. I am almost new to u-boot, which means that a few
> times in my life I had tasks to implement some commands and perform
> initialization of GPIOS, etc. In summary very simple tasks. Now I have a
> bit harder tasks - to update from version 2015.04 to 2017.03. The board is
> based on i.mx6 Sabre Auto DualLite, so I am speaking of fscl u-boot.
>

If you want to look at the overall history and progression, I would
suggest looking at commit history for the defconfig file from which
your device was based.

I don't know if it's the right board, but you can try this:
https://gitlab.denx.de/u-boot/u-boot/commits/master/configs/mx6sabreauto_defconfig


> I would like to clarify a few things:
> 1. When previously dealt with u-boot, the configuration of the board was
> done by using #define SOMETHING. As far as I could see, u-boot is now able
> to read the device tree and to load drivers based on that. Is this
> preferred way of configuring u-boot now? If yes where can I find more
> information about this with some examples. The thing is, my device tree has
> gpio-led entry, but unfortunately i don't see debug messages I am printing
> withing driver probe function (I print usinf printf, maybe other way of
> printing should be used).

Much of the #defines have been migrating to Kconfig which places the
default values for a given board into _defconfig files.  If you are
looking for an option previously defined in the include/configs/, you
might find them now located in corresponding defconfig file.  If you
want to enable something, check to see if it's in the menuconfig.
>
> 2. How not to use device tree for loading drivers at all? When I set
> CONFIG_OF_CONTROL=n
> I am not able to compile the code.

CONFIG_OF_CONTROL is part of the equation, but many of the drivers
were and are still being migrated to a new driver model (DM) and
OF_CONTROL requires the DM to be enabled.  I have an imx6 board that I
am trying to maintain, and using DM has become more and more of a
requirement, and OF_CONTROL is becoming the default because you can
greatly reduce the amount of board specific code by having the system
scan the device tree.
>
> 3. Is device tree used by u-boot the same device tree later used by linu
> kernel?

On my imx6q_logic board, the device tree is appended to the code, but
it's only used for U-Boot and or SPL.  SPL is the secondary program
loader, and it has a much reduced device tree because of the limited
space.  I load a separate device tree for the kernel, because I keep
the kernels and their respecive device trees in sync to prevent
issues.
>
> 4. How can to know if I should use menuconfig or not?

I would recommend looking at the  i.mx6 Sabre Auto DualLite
configurations, both the _defconfig and the include/configs files as a
starting point.  You can always search the menuconfig for various
options.  Many of the device drivers are organized in a similar
manner.
>
> Thank you very much I hope we will have a great time in the list :D

Best wishes.

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

Re: [U-Boot] Please pull u-boot-dm

[Tom Rini]

On Mon, Jul 22, 2019 at 08:48:45AM -0600, Simon Glass wrote:

> Hi Tom,
> 
> Build is here: https://travis-ci.org/sglass68/u-boot/builds/561552377
> 
> The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> 
>   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-dm.git tags/dm-pull-22jul19
> 
> for you to fetch changes up to 857ad7985ff63989c3c7feff56c2dc353d7d7c9a:
> 
>   dm: device: make power domain calls optional (2019-07-20 19:50:44 -0600)
> 

First, in my LLVM-7 test:
/home/trini/u-boot/u-boot/tools/ifwitool.c:584:23: warning: unused function 
'read_le8' [-Wunused-function]
static inline uint8_t read_le8(const void *src)
  ^
/home/trini/u-boot/u-boot/tools/ifwitool.c:695:20: warning: unused function 
'zero_n' [-Wunused-function]
static inline void zero_n(void *dest, size_t n)

Which is simple to fix.  But I don't see why it's not being caught in
the travis test off-hand.  And I further see I didn't get LLVM-7
included in GitLab at all yet.

Next however I see:
https://gitlab.denx.de/u-boot/u-boot/-/jobs/1222
which is the binman tests failing and needs to be fixed.

-- 
Tom


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

[U-Boot] Updating uboot from 2015.04 to 2017.03 - doubts and other questions

[Nemanja Savic]

Hi all list members,

this is my first post. I am almost new to u-boot, which means that a few
times in my life I had tasks to implement some commands and perform
initialization of GPIOS, etc. In summary very simple tasks. Now I have a
bit harder tasks - to update from version 2015.04 to 2017.03. The board is
based on i.mx6 Sabre Auto DualLite, so I am speaking of fscl u-boot.

I would like to clarify a few things:
1. When previously dealt with u-boot, the configuration of the board was
done by using #define SOMETHING. As far as I could see, u-boot is now able
to read the device tree and to load drivers based on that. Is this
preferred way of configuring u-boot now? If yes where can I find more
information about this with some examples. The thing is, my device tree has
gpio-led entry, but unfortunately i don't see debug messages I am printing
withing driver probe function (I print usinf printf, maybe other way of
printing should be used).

2. How not to use device tree for loading drivers at all? When I set
CONFIG_OF_CONTROL=n
I am not able to compile the code.

3. Is device tree used by u-boot the same device tree later used by linu
kernel?

4. How can to know if I should use menuconfig or not?

Thank you very much I hope we will have a great time in the list :D
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses

[Nevo Hed]

For context from upstream linux,
https://github.com/torvalds/linux/commit/f66b2aff46eaf0825dbe1560e28fcb845dd2a215

I was intending to submit the parallel change here once fully tested
end-end on our hardware,
but if not too late my proposal is to name the above nodes as
"cpm-mdio" & "cps-mdio"


On Tue, Jul 23, 2019 at 1:03 PM Nevo Hed  wrote:
>
> Sorry for the late input
>
> The cp110s have an mdio and an xmdio so
> Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio
>
> I knew the new field is coming but didn't catch that the 'dtsi's patch
>
> [also apologies if you get this a second time]
>
> On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger  
> wrote:
> >
> > On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean
> >  wrote:
> > >
> > > Implicitly Marvell MDIO driver uses DT node names for devices, but in this
> > > case that is not unique.  Set MDIO device names for master/slave to
> > > cpm/cps.
> > >
> > > Signed-off-by: Alex Marginean 
> >
> > Acked-by: Joe Hershberger 
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v10 3/4] riscv: sifive: fu540: Sync-up config header with RISC-V QEMU support

[David Abdurachmanov]

On Mon, Jul 22, 2019 at 10:48 AM Anup Patel  wrote:
>
> We typically use same set of distro images (yocto, debian, fedora, etc.)
> on both QEMU RISC-V virt machine and SiFive Unleashed board.
>
> With growing kernel and ramdisk images, we need to re-adjust default
> U-Boot environment variables. The config header for QEMU RISC-V virt
> machine has been already updated to handle bigger kernel and ramdisk
> images hence this patch updates SiFive FU540 config header accordingly.
>
> Signed-off-by: Anup Patel 
> ---

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

Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses

[Nevo Hed]

Sorry for the late input

The cp110s have an mdio and an xmdio so
Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio

I knew the new field is coming but didn't catch that the 'dtsi's patch

[also apologies if you get this a second time]

On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger  wrote:
>
> On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean
>  wrote:
> >
> > Implicitly Marvell MDIO driver uses DT node names for devices, but in this
> > case that is not unique.  Set MDIO device names for master/slave to
> > cpm/cps.
> >
> > Signed-off-by: Alex Marginean 
>
> Acked-by: Joe Hershberger 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/50] doc: Shape into useful HTML docs

[Tom Rini]

On Tue, Jul 23, 2019 at 05:00:52PM +0200, Wolfgang Denk wrote:
> Dear Bin,
> 
> In message 
>  you 
> wrote:
> >
> > > @Wolfgang, is it possible to host the Sphinx HTML docs on denx.de?
> > >
> > > This series is available at u-boot-x86/doc for testing.
> > >
> >
> > Ping?
> 
> Yes, this is possible.  Where can I find the HTML files?  And where
> would you want to put them?  And what is the planned update
> strategy?
> 
> I mean, plain HTML documents are a bit lame, as they refer to a
> specific version of U-Boot only.  What if I want to see the docs for
> a version of half a year ago?

Thinking out loud, how about ...// and we re-generate the docs
for each full release?

-- 
Tom


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

[U-Boot] [PATCH] mx6sabresd: Reduce overall SPL size

[Fabio Estevam]

Currently the SPL binary is 67 kB, which leaves only 1 kB of free
internal RAM space.

The following options can be safely removed to save some precious
SPL space:

- CONFIG_SPL_FS_EXT4: u-boot-dtb.img is stored in raw sector via dd
command (at offset 69 kB)
- CONFIG_SPL_I2C_SUPPORT: I2C is not used during SPL
- CONFIG_SPL_OS_BOOT: no need to make Falcon mode supported
by default

After this change the SPL binary size gets down to 51 kB.

Signed-off-by: Fabio Estevam 
---
 configs/mx6sabresd_defconfig | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 9400805831..84862feb8b 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -23,9 +23,6 @@ CONFIG_BOUNCE_BUFFER=y
 CONFIG_SPL_TEXT_BASE=0x00908000
 CONFIG_SPL_SEPARATE_BSS=y
 CONFIG_SPL_FIT_IMAGE_TINY=y
-CONFIG_SPL_FS_EXT4=y
-CONFIG_SPL_I2C_SUPPORT=y
-CONFIG_SPL_OS_BOOT=y
 CONFIG_SPL_USB_HOST_SUPPORT=y
 CONFIG_SPL_USB_GADGET=y
 CONFIG_SPL_USB_SDP_SUPPORT=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH 4/4] arm: dts: Set custom names for cp110 master/slave MDIO buses

[Nevo Hed]

Sorry for the late input

The cp110s have an mdio and an xmdio so
Locally I have been naming them cpm-xmdio, cpm-mdio, cps-xmdio, cps-mdio

I knew the new field is coming but didn't catch that the 'dtsi's patch

On Mon, Jul 22, 2019 at 8:30 PM Joe Hershberger  wrote:
>
> On Wed, Jul 17, 2019 at 10:12 AM Alex Marginean
>  wrote:
> >
> > Implicitly Marvell MDIO driver uses DT node names for devices, but in this
> > case that is not unique.  Set MDIO device names for master/slave to
> > cpm/cps.
> >
> > Signed-off-by: Alex Marginean 
>
> Acked-by: Joe Hershberger 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] arm: dts: ficus: Enable booting from eMMC when using SPL

[Manivannan Sadhasivam]

On Mon, May 27, 2019 at 02:49:49PM +0800, Kever Yang wrote:
> 
> 
> On 05/20/2019 11:46 PM, Manivannan Sadhasivam wrote:
> > This commits enables booting from eMMC when using SPL on 96Boards
> > Ficus board by adding SDHCI to boot order. Since the SDHCI driver
> > already has the reloc flag, this works straightaway.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> 
> Reviewed-by: Kever Yang 
> 

Ping!

> Thanks,
> - Kever
> > ---
> >  arch/arm/dts/rk3399-ficus-u-boot.dtsi | 1 +
> >  arch/arm/dts/rk3399-ficus.dts | 2 ++
> >  2 files changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-ficus-u-boot.dtsi 
> > b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> > index eab86bdb30..67b63a8352 100644
> > --- a/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-ficus-u-boot.dtsi
> > @@ -3,4 +3,5 @@
> >   * Copyright (C) 2019 Jagan Teki 
> >   */
> >  
> > +#include "rk3399-u-boot.dtsi"
> >  #include "rk3399-sdram-ddr3-1600.dtsi"
> > diff --git a/arch/arm/dts/rk3399-ficus.dts b/arch/arm/dts/rk3399-ficus.dts
> > index 4b2dd82b67..0f219f4a9c 100644
> > --- a/arch/arm/dts/rk3399-ficus.dts
> > +++ b/arch/arm/dts/rk3399-ficus.dts
> > @@ -15,6 +15,8 @@
> >  
> > chosen {
> > stdout-path = "serial2:150n8";
> > +   u-boot,spl-boot-order = \
> > +   , 
> > };
> >  
> > clkin_gmac: external-gmac-clock {
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] arm: dts: rock960: Enable booting from eMMC when using SPL

[Manivannan Sadhasivam]

On Mon, May 27, 2019 at 02:49:39PM +0800, Kever Yang wrote:
> 
> 
> On 05/20/2019 11:46 PM, Manivannan Sadhasivam wrote:
> > This commits enables booting from eMMC when using SPL on 96Boards
> > Rock960 board by adding SDHCI to boot order. Since the SDHCI driver
> > already has the reloc flag, this works straightaway.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> 
> Reviewed-by: Kever Yang 
> 

Ping!

> Thanks,
> - Kever
> > ---
> >  arch/arm/dts/rk3399-rock960-u-boot.dtsi | 1 +
> >  arch/arm/dts/rk3399-rock960.dts | 2 ++
> >  2 files changed, 3 insertions(+)
> >
> > diff --git a/arch/arm/dts/rk3399-rock960-u-boot.dtsi 
> > b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> > index 5256f6d3f2..7fb5072a9b 100644
> > --- a/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3399-rock960-u-boot.dtsi
> > @@ -3,4 +3,5 @@
> >   * Copyright (C) 2019 Jagan Teki 
> >   */
> >  
> > +#include "rk3399-u-boot.dtsi"
> >  #include "rk3399-sdram-lpddr3-2GB-1600.dtsi"
> > diff --git a/arch/arm/dts/rk3399-rock960.dts 
> > b/arch/arm/dts/rk3399-rock960.dts
> > index 7e06bc97e5..c8b9075c73 100644
> > --- a/arch/arm/dts/rk3399-rock960.dts
> > +++ b/arch/arm/dts/rk3399-rock960.dts
> > @@ -12,6 +12,8 @@
> >  
> > chosen {
> > stdout-path = "serial2:150n8";
> > +   u-boot,spl-boot-order = \
> > +   , 
> > };
> >  };
> >  
> 
> 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2] rtc: ds3232/ds3231: Add support to generate 32KHz output for driver module

[Wolfgang Denk]

Dear Chuanhua Han,

In message <20190723095745.37138-1-chuanhua@nxp.com> you wrote:
> This patch add an implementation of the rtc_enable_32khz_output() that
> uses the driver model i2c APIs.
>
> Signed-off-by: Chuanhua Han 
> ---
> Change in v2:
>   - Add RTC_ENABLE_32KHZ_OUTPUT option so this code compiles only 
> in that cases where it is really useful.

So when exactly is it useful?

If I understand correctly, there are no users of this code in
mainline.  Should the patch then not be part of a patch series that
adds such users?

Adding potentially "useful" code just on speculation is not nice
maintenance-wise.

I recommend to withdraw this patch and submit it together with some
real consumer of this feature.

Thanks.

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
"The question of whether a computer can think is no more  interesting
than the question of whether a submarine can swim"
- Edsgar W.  Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/50] doc: Shape into useful HTML docs

[Wolfgang Denk]

Dear Bin,

In message  
you wrote:
>
> > @Wolfgang, is it possible to host the Sphinx HTML docs on denx.de?
> >
> > This series is available at u-boot-x86/doc for testing.
> >
>
> Ping?

Yes, this is possible.  Where can I find the HTML files?  And where
would you want to put them?  And what is the planned update
strategy?

I mean, plain HTML documents are a bit lame, as they refer to a
specific version of U-Boot only.  What if I want to see the docs for
a version of half a year ago?

What exactly are your plans?

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
To be a winner, all you need to give is all you have.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH u-boot-spi v2 1/1] spi: mvebu_a3700_spi: Fix clock prescale computation

[Marek Behún]

The prescaler value computation can yield wrong result if given 0x1f at
the beginning: the value is computed to be 0x20, but the maximum value
the register can hold 0x1f, so the actual stored value in this case is
0, which is obviously wrong.
Set the upper bound of the value to 0x1f with the min macro.

Signed-off-by: Marek Behún 
---
 drivers/spi/mvebu_a3700_spi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/mvebu_a3700_spi.c b/drivers/spi/mvebu_a3700_spi.c
index feeafdceaa..99ad505f24 100644
--- a/drivers/spi/mvebu_a3700_spi.c
+++ b/drivers/spi/mvebu_a3700_spi.c
@@ -181,10 +181,9 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
hz)
data = readl(>cfg);
 
prescale = DIV_ROUND_UP(clk_get_rate(>clk), hz);
-   if (prescale > 0x1f)
-   prescale = 0x1f;
-   else if (prescale > 0xf)
+   if (prescale > 0xf)
prescale = 0x10 + (prescale + 1) / 2;
+   prescale = min(prescale, 0x1fu);
 
data &= ~MVEBU_SPI_A3700_CLK_PRESCALE_MASK;
data |= prescale & MVEBU_SPI_A3700_CLK_PRESCALE_MASK;
-- 
2.21.0

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

[U-Boot] [PATCH u-boot-mmc 1/1] mmc: sdhci: Read cd-gpios instead of cd-gpio from devicetree

[Marek Behún]

Linux's documentation (Documentation/devicetree/bindings/mmc/mmc.txt)
says the property should be named cd-gpios, not cd-gpio. All the dts
files use cd-gpios.

Signed-off-by: Marek Behún 
Cc: T Karthik Reddy 
Cc: Michal Simek 
Cc: Peng Fan 
---
 drivers/mmc/sdhci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index c4e88790bc..d0e9cc55f6 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -594,7 +594,7 @@ static int sdhci_init(struct mmc *mmc)
 #if CONFIG_IS_ENABLED(DM_MMC) && CONFIG_IS_ENABLED(DM_GPIO)
struct udevice *dev = mmc->dev;
 
-   gpio_request_by_name(dev, "cd-gpio", 0,
+   gpio_request_by_name(dev, "cd-gpios", 0,
 >cd_gpio, GPIOD_IS_IN);
 #endif
 
-- 
2.21.0

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

Re: [U-Boot] [PATCH 1/3] spi: Add spi_write_then_read

[Adam Ford]

On Mon, Jul 22, 2019 at 7:01 AM Jagan Teki  wrote:
>
> Add support for SPI synchronous write followed by read,
> this is common interface call from spi-nor to spi drivers.
>
For the while series:
Tested-by: Adam Ford  #da850-evm

> Reviewed-by: Simon Glass 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/spi-uclass.c | 24 
>  include/spi.h| 20 
>  2 files changed, 44 insertions(+)
>
[snip]
> --
> 2.18.0.321.gffc6fa0e3
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] dm: core: device: switch off power domain after device removal

[Lokesh Vutla]

On 15/07/19 1:27 AM, Anatolij Gustschin wrote:
> The power domain associated with a device is enabled when probing,
> but currently the domain remains enabled when the device is removed.
> Some boards started to disable power domains for selected devices
> via custom board_quiesce_devices(), but it doesn't work in many
> cases, i. e. because devices still can be accessed later in
> .remove() callback on behalf of dm_remove_devices_flags().
> 
> Utilize the DM core to power off the device power domain, but add a
> device flag to be able to selectively let the power domain enabled
> after device removal. This might be required for devices that must
> remain enabled when booting OS, i. e. serial console for debug
> output, etc.
> 
> Signed-off-by: Anatolij Gustschin 
> ---
> Changes in v2:
>  - use CONFIG_IS_ENABLED(POWER_DOMAIN) to reduce code size
> 
>  drivers/core/device-remove.c | 9 +
>  include/dm/device.h  | 6 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/core/device-remove.c b/drivers/core/device-remove.c
> index 586fadee0a..abed84a652 100644
> --- a/drivers/core/device-remove.c
> +++ b/drivers/core/device-remove.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  int device_chld_unbind(struct udevice *dev, struct driver *drv)
>  {
> @@ -154,6 +155,7 @@ static bool flags_remove(uint flags, uint drv_flags)
>  
>  int device_remove(struct udevice *dev, uint flags)
>  {
> + struct power_domain pd;
>   const struct driver *drv;
>   int ret;
>  
> @@ -192,6 +194,13 @@ int device_remove(struct udevice *dev, uint flags)
>   }
>   }
>  
> + if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
> + device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN &&
> + !(dev->flags & DM_FLAG_REMOVE_WITH_PD_ON)) {

This is going to hit every board and all serial drivers needs to be updated. Can
we add an extra check here for (dev != gd->cur_serial_dev).

Thanks and regards,
Lokesh

> + if (!power_domain_get(dev, ))
> + power_domain_off();
> + }
> +
>   if (flags_remove(flags, drv->flags)) {
>   device_free(dev);
>  
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 27a6d7b9fd..9a98a4a39e 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -61,6 +61,12 @@ struct driver_info;
>   */
>  #define DM_FLAG_OS_PREPARE   (1 << 10)
>  
> +/*
> + * Device is removed without switching off its power domain. This might
> + * be required, i. e. for serial console (debug) output when booting OS.
> + */
> +#define DM_FLAG_REMOVE_WITH_PD_ON(1 << 11)
> +
>  /*
>   * One or multiple of these flags are passed to device_remove() so that
>   * a selective device removal as specified by the remove-stage and the
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Remote code execution vulnerabilities in U-Boot's NFS and other IP parsing code

[Fermín Serna]

Of course, sorry about that.
Please note this was a quick untested patch used for highlighting the
vulnerabilities. I would start with it but most likely needs some
extra work. At this time, I would appreciate someone else to take it
form here.

See inline below.

diff --git a/net/net.c b/net/net.c
index 58b0417cbe..9957450392 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1256,6 +1256,12 @@ void net_process_received_packet(uchar
*in_packet, int len)
 "received UDP (to=%pI4, from=%pI4, len=%d)\n",
 _ip, _ip, len);

+if ((ntohs(ip->udp_len) < UDP_HDR_SIZE) ||
+(ntohs(ip->udp_len) > len)) {
+   printf(" Invalid IP->udp_len field\n");
+   return;
+}
+
 #ifdef CONFIG_UDP_CHECKSUM
  if (ip->udp_xsum != 0) {
  ulong   xsum;
@@ -1305,6 +1311,7 @@ void net_process_received_packet(uchar
*in_packet, int len)
  ntohs(ip->udp_src),
  ntohs(ip->udp_len) - UDP_HDR_SIZE);
 #endif
+
  /*
  * IP header OK.  Pass the packet to the current handler.
  */
diff --git a/net/nfs.c b/net/nfs.c
index d6a7f8e827..da6fd76327 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -48,12 +48,12 @@
 static int fs_mounted;
 static unsigned long rpc_id;
 static int nfs_offset = -1;
-static int nfs_len;
+static unsigned int nfs_len;
 static ulong nfs_timeout = NFS_TIMEOUT;

 static char dirfh[NFS_FHSIZE]; /* NFSv2 / NFSv3 file handle of directory */
 static char filefh[NFS3_FHSIZE]; /* NFSv2 / NFSv3 file handle */
-static int filefh3_length; /* (variable) length of filefh when NFSv3 */
+static unsigned int filefh3_length; /* (variable) length of filefh
when NFSv3 */

 static enum net_loop_state nfs_download_state;
 static struct in_addr nfs_server_ip;
@@ -432,7 +432,8 @@ static int rpc_lookup_reply(int prog, uchar *pkt,
unsigned len)
 {
  struct rpc_t rpc_pkt;

- memcpy(_pkt.u.data[0], pkt, len);
+ memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+ memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  debug("%s\n", __func__);

@@ -464,7 +465,8 @@ static int nfs_mount_reply(uchar *pkt, unsigned len)

  debug("%s\n", __func__);

- memcpy(_pkt.u.data[0], pkt, len);
+memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
  return -NFS_RPC_ERR;
@@ -490,7 +492,8 @@ static int nfs_umountall_reply(uchar *pkt, unsigned len)

  debug("%s\n", __func__);

- memcpy(_pkt.u.data[0], pkt, len);
+memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
  return -NFS_RPC_ERR;
@@ -514,7 +517,8 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)

  debug("%s\n", __func__);

- memcpy(_pkt.u.data[0], pkt, len);
+memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
  return -NFS_RPC_ERR;
@@ -608,12 +612,13 @@ static int nfs3_get_attributes_offset(uint32_t *data)
 static int nfs_readlink_reply(uchar *pkt, unsigned len)
 {
  struct rpc_t rpc_pkt;
- int rlen;
- int nfsv3_data_offset = 0;
+ unsigned int rlen;
+ unsigned int nfsv3_data_offset = 0;

  debug("%s\n", __func__);

- memcpy((unsigned char *)_pkt, pkt, len);
+memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
  return -NFS_RPC_ERR;
@@ -639,15 +644,23 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len)

  strcat(nfs_path, "/");
  pathlen = strlen(nfs_path);
+
+if (rlen > sizeof(nfs_path_buff) - pathlen)
+  return -NFS_RPC_ERR;
+
  memcpy(nfs_path + pathlen,
 (uchar *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset]),
 rlen);
- nfs_path[pathlen + rlen] = 0;
+ nfs_path[pathlen + rlen - 1] = 0;
  } else {
+
+if (rlen > sizeof(nfs_path_buff))
+  return -NFS_RPC_ERR;
+
  memcpy(nfs_path,
 (uchar *)&(rpc_pkt.u.reply.data[2 + nfsv3_data_offset]),
 rlen);
- nfs_path[rlen] = 0;
+ nfs_path[rlen - 1] = 0;
  }
  return 0;
 }
@@ -655,12 +668,13 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len)
 static int nfs_read_reply(uchar *pkt, unsigned len)
 {
  struct rpc_t rpc_pkt;
- int rlen;
+ unsigned int rlen;
  uchar *data_ptr;

  debug("%s\n", __func__);

- memcpy(_pkt.u.data[0], pkt, sizeof(rpc_pkt.u.reply));
+memset(_pkt.u.data[0], 0, sizeof(struct rpc_t));
+memcpy(_pkt.u.data[0], pkt, min(len, sizeof(struct rpc_t)));

  if (ntohl(rpc_pkt.u.reply.id) > rpc_id)
  return -NFS_RPC_ERR;
@@ -687,6 +701,11 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
  if (supported_nfs_versions & NFSV2_FLAG) {
  rlen = ntohl(rpc_pkt.u.reply.data[18]);
  data_ptr = (uchar *)&(rpc_pkt.u.reply.data[19]);
+
+ // Make sure at rlen at least does not goes 

Re: [U-Boot] Pull request: u-boot-rockchip/tags/rockchip-for-v2019.07

[Tom Rini]

On Sun, Jul 21, 2019 at 11:11:40AM +0800, Kever Yang wrote:

> Hi Tom,
> 
> Please pull rockchip the update:
> - rk3399 lpddr4 support
> - rk3399-rock960 board support improvement
> - Eliminate pyelftools dependency by make_fit_atf.py
> - clean up rockchip dts to use -u-boot.dtsi
> - use ARM arch/generic timer instead of rk_timer
> - clean up Kconfig options for board support
> 
> Travis:
> https://travis-ci.org/keveryang/u-boot/builds/561434501
> 
> Thanks,
> - Kever
> 
> The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> 
>   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> 
> are available in the Git repository at:
> 
>   https://gitlab.denx.de/u-boot/custodians/u-boot-rockchip.git 
> tags/rockchip-for-v2019.07
> 
> for you to fetch changes up to 8b1ceb0ac1aa1746c6751d698ce7a012a236fa65:
> 
>   rockchip: Remove obsolete references to pyelftools (2019-07-20 23:59:44 
> +0800)
> 

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 request: u-boot-nds32/master

[Tom Rini]

On Fri, Jul 19, 2019 at 03:24:51PM +0800, ub...@andestech.com wrote:

> Hi Tom,
> 
> Please pull some nds32 updates:
> - Update nds32 MAINTAINERS from Macpaul to Rick.
> 
> https://travis-ci.org/rickchen36/u-boot-nds32/builds/560328107
> 
> Thanks
> 
> Rick
> 
> 
> The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> 
>   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> 
> are available in the Git repository at:
> 
>   g...@gitlab.denx.de:u-boot/custodians/u-boot-nds32.git
> 
> for you to fetch changes up to 995fa61fc3769222eac79946890c721bdc27f82b:
> 
>   MAINTAINERS: Remove Macpaul and add Rick as nds32 maintainer (2019-07-19 
> 15:09:57 +0800)
> 

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 request: u-boot-riscv/master

[Tom Rini]

On Fri, Jul 19, 2019 at 03:06:24PM +0800, ub...@andestech.com wrote:

> Hi Tom,
> 
> Please pull some riscv updates:
> 
> - Update SiFive Unleashed clock driver.
> - Enables SiFive SPI driver and MMC SPI driver for SiFive Unleashed board
> 
> https://travis-ci.org/rickchen36/u-boot-riscv/builds/560423274
> 
> Thanks
> Rick
> 
> 
> The following changes since commit 0de815356474912ef5bef9a69f0327a5a93bb2c2:
> 
>   Merge branch '2019-07-17-master-imports' (2019-07-18 11:31:37 -0400)
> 
> are available in the Git repository at:
> 
>   g...@gitlab.denx.de:u-boot/custodians/u-boot-riscv.git
> 
> for you to fetch changes up to 8911a22aee1e2a176af93ebf502477f2df2fc912:
> 
>   doc: sifive-fu540: Update README for SiFive SPI and MMC SPI drivers 
> (2019-07-19 14:25:06 +0800)
> 

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 request: u-boot-net.git master

[Tom Rini]

On Thu, Jul 18, 2019 at 04:38:22PM -0500, Joe Hershberger wrote:

> Hi Tom,
> 
> These patches passed Travis-CI here: 
> https://travis-ci.org/jhershbe/u-boot/builds/559182108
> 
> The following changes since commit 0e80dda32c8d724c2a98dbbfb2f1e59762788f15:
> 
>   Merge branch 'master' of 
> https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi (2019-07-16 11:19:31 
> -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-net.git master
> 
> for you to fetch changes up to bbfc562719c463ba6e7b03125aedd5720a325d2d:
> 
>   net: unaligned copying of unsigned long (2019-07-18 16:37:13 -0500)
> 

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] [PATCH] mmd: sdhci: fix non GPIO card detect

[Baruch Siach]

Hi Faiz,

On Tue, Jul 23, 2019 at 04:47:47PM +0530, Faiz Abbas wrote:
> On 23/07/19 4:16 PM, Baruch Siach wrote:
> > On Tue, Jul 23, 2019 at 03:35:31PM +0530, Faiz Abbas wrote:
> >> On 23/07/19 2:39 PM, Baruch Siach wrote:
> >>> On Tue, Jul 23, 2019 at 02:27:28PM +0530, Faiz Abbas wrote:
>  On 23/07/19 1:30 PM, Peng Fan wrote:
> > + Faiz
> >
> >> Subject: [PATCH] mmd: sdhci: fix non GPIO card detect
> >>
> >> Some SD cards do not assert the SDHCI_CARD_PRESENT bit. Only the
> >> SDHCI_CARD_DETECT_PIN_LEVEL is enabled. Consider that enough for card
> >> detect indication.
> >>
> >> This fixes SD card access from SPL, since DM_GPIO is not available in 
> >> SPL
> >> code.
> >>
> >> Fixes: da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect")
> >> Cc: T Karthik Reddy 
> >> Cc: Michal Simek 
> >> Signed-off-by: Baruch Siach 
> >> ---
> >>  drivers/mmc/sdhci.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
> >> 2779bca93f08..17a28181fcca 100644
> >> --- a/drivers/mmc/sdhci.c
> >> +++ b/drivers/mmc/sdhci.c
> >> @@ -683,7 +683,7 @@ int sdhci_get_cd(struct udevice *dev)
> >>}
> >>  #endif
> >>value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
> >> - SDHCI_CARD_PRESENT);
> >> + (SDHCI_CARD_PRESENT | SDHCI_CARD_DETECT_PIN_LEVEL));
> >
> > Faiz, are you fine with this change?
> 
>  Not really. The spec is pretty clear that DETECT_PIN_LEVEL is not to be
>  trusted. Also how does the CARD_PRESENT assertion depend on the SD card
>  you use? Are you normally muxing the SDCD line to the IP (for hardware
>  to detect) or are you connecting it as a gpio which software must detect?
> >>>
> >>> I tested SanDisk 8GB SD card, class 10, UHS1, on Armada 388 based 
> >>> SolidRun 
> >>> Clearfog Base. The SDHCI_PRESENT_STATE register consistently reads 
> >>> 0x01f6, 
> >>> that is, CARD_PRESENT is disabled, DETECT_PIN_LEVEL is enabled.
> >>>
> >>> The SD card-detect GPIO is present at the hardware level, but it is not 
> >>> accessible from SPL code because there is currently no SPL_DM_GPIO. The 
> >>> main 
> >>> U-Boot image detects the SD card correctly (once the other MMC patches I 
> >>> posted are applied).
> >>>
> >>> Without this patch boot from SD card is broken. What is the right fix 
> >>> then?
> >>
> >> There are two choices to implement card detect:
> >>
> >> 1. Mux the card detect line from the SD card cage directly to the host
> >> controller and expect PRESENT state register to indicate whether card is
> >> present or not.
> >>
> >> 2. Mux the card detect line as a GPIO and use software
> >> (dm_gpio_get_value() call) to detect whether card is present or not. In
> >> that case, PRESENT_STATE[16,17,18] are completely useless because there
> >> is no card detect line going into the IP.
> >>
> >> It seems that you are using #2. What confuses me is how any cards are
> >> able to assert CARD_DETECT.
> > 
> > As far as I can see the Armada 388 SD host controller does not provide 
> > option 
> > #1. The Clearfog indeed uses option #2. Until commit da18c62b6e6a4 ("mmc: 
> > sdhci: Implement SDHCI card detect") it used to work because the mv_sdhci 
> > driver does not implement the get_cd callback, so card-detect was ignored. 
> > Now 
> > we have a get_cd implementation at the sdhci level that returns 0 in SPL 
> > because the GPIO is not accessible.
> > 
> > What would you suggest?
> 
> You can just add your own get_cd() callback instead of using sdhci_get_cd().

I can do that, but I would still hit the basic problem. GPIOs are not 
accessible from SPL when DM is enabled. I guess that would affect a few other 
platforms.

How about making an exception for SPL? Something like this:

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 654931a82f54..03c132631d23 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -672,6 +672,9 @@ int sdhci_get_cd(struct udevice *dev)
/* If polling, assume that the card is always present. */
if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
return 1;
+   /* In SPL we have no DM_GPIO access; assume card is present */
+   if (IS_ENABLED(CONFIG_SPL_BUILD))
+   return 1;
 
 #if CONFIG_IS_ENABLED(DM_GPIO)
value = dm_gpio_get_value(>cd_gpio);

What do you think?

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: dts: stih410-b2260: Sync DT with kernel v5.2

[Patrice Chotard]

Synchronize U-boot DT with kernel v5.2 for stih410-b2260.
Update stih410-b2260-u-boot.dtsi accordingly.

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stih407-clock.dtsi| 113 ++--
 arch/arm/dts/stih407-family.dtsi   | 200 --
 arch/arm/dts/stih407-pinctrl.dtsi  | 129 +-
 arch/arm/dts/stih410-b2260-u-boot.dtsi |  17 ++
 arch/arm/dts/stih410-b2260.dts | 128 +++---
 arch/arm/dts/stih410-clock.dtsi| 110 ++--
 arch/arm/dts/stih410-pinctrl.dtsi  |   7 +-
 arch/arm/dts/stih410.dtsi  | 227 -
 8 files changed, 370 insertions(+), 561 deletions(-)

diff --git a/arch/arm/dts/stih407-clock.dtsi b/arch/arm/dts/stih407-clock.dtsi
index 13029c03d7..1ab40db7c9 100644
--- a/arch/arm/dts/stih407-clock.dtsi
+++ b/arch/arm/dts/stih407-clock.dtsi
@@ -1,38 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * Copyright (C) 2014 STMicroelectronics R Limited
- *
- * 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.
  */
 #include 
 / {
+   /*
+* Fixed 30MHz oscillator inputs to SoC
+*/
+   clk_sysin: clk-sysin {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <3000>;
+   };
+
+   clk_tmdsout_hdmi: clk-tmdsout-hdmi {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <0>;
+   };
+
clocks {
#address-cells = <1>;
#size-cells = <1>;
ranges;
 
-   /*
-* Fixed 30MHz oscillator inputs to SoC
-*/
-   clk_sysin: clk-sysin {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <3000>;
-   };
-
-   /*
-* ARM Peripheral clock for timers
-*/
-   arm_periph_clk: clk-m-a9-periphs {
-   #clock-cells = <0>;
-   compatible = "fixed-factor-clock";
-
-   clocks = <_m_a9>;
-   clock-div = <2>;
-   clock-mult = <1>;
-   };
-
/*
 * A9 PLL.
 */
@@ -62,35 +53,22 @@
 <_a9_pll 0>,
 <_s_c0_flexgen 13>,
 <_m_a9_ext2f_div2>;
-   };
 
-   /*
-* ARM Peripheral clock for timers
-*/
-   clk_m_a9_ext2f_div2: clk-m-a9-ext2f-div2s {
-   #clock-cells = <0>;
-   compatible = "fixed-factor-clock";
 
-   clocks = <_s_c0_flexgen 13>;
-
-   clock-output-names = "clk-m-a9-ext2f-div2";
-
-   clock-div = <2>;
-   clock-mult = <1>;
-   };
+   /*
+* ARM Peripheral clock for timers
+*/
+   arm_periph_clk: clk-m-a9-periphs {
+   #clock-cells = <0>;
+   compatible = "fixed-factor-clock";
 
-   /*
-* Bootloader initialized system infrastructure clock for
-* serial devices.
-*/
-   clk_ext2f_a9: clockgen-c0@13 {
-   #clock-cells = <0>;
-   compatible = "fixed-clock";
-   clock-frequency = <2>;
-   clock-output-names = "clk-s-icn-reg-0";
+   clocks = <_m_a9>;
+   clock-div = <2>;
+   clock-mult = <1>;
+   };
};
 
-   clockgen-a@090ff000 {
+   clockgen-a@90ff000 {
compatible = "st,clkgen-c32";
reg = <0x90ff000 0x1000>;
 
@@ -101,6 +79,7 @@
clocks = <_sysin>;
 
clock-output-names = "clk-s-a0-pll-ofd-0";
+   clock-critical = <0>; /* clk-s-a0-pll-ofd-0 */
};
 
clk_s_a0_flexgen: clk-s-a0-flexgen {
@@ -112,6 +91,7 @@
 <_sysin>;
 
clock-output-names = "clk-ic-lmi0";
+   clock-critical = ;
};
};
 
@@ -126,9 +106,10 @@
 "clk-s-c0-fs0-ch1",
 "clk-s-c0-fs0-ch2",
 

Re: [U-Boot] [PATCH v1] colibri_imx7: boot kernel in secure mode

[Tobias Junghans]

Hi Igor,

thanks for your comments! Is there any solution, patch or workaround I can try 
to power on the 2nd CPU core in secure mode with mainline kernel?

Thanks and best regards

Tobias

> I'm afraid you're right.
> Just after a bit of time researching and discussing with Stefan, seems
> that we need to introduce two different wrappers for booting the
> mainline kernel and downstream NXP kernel.
> 
> * NXP kernel has legacy code to enable all cores, which works only when
> running in secure mode.
> * Mainline kernel, as you said before, does use PSCI for this, which
> is provided by U-boot (which adds proper psci nodes to the linux
> dtb on-fly before transferring control to the linux kernel entry point).
> When we try to load it in secure mode, it continues running on the same
> Secure PL1, and communication using SMC calling convention doesn't make
> sense at this case.



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

[U-Boot] R-Car-gpio0_00-fails-with-“gpio input” command

[Tiezhuang Dong]

Hi,
Attached is to fix below issue:
--
=> gpio input gpio@e6050
gpio: requesting pin 0 failed
gpio - query and control gpio pins
--
Fix:
drivers/pinctrl/renesas/pfc.c +470
//for (i = 1; i < pfc->info->nr_pins; i++) {
for (i = 0; i < pfc->info->nr_pins; i++) {
---

Thank you and Best Regards
Tiezhuang Dong 董铁庄

Application Engineering Section，
Technical Customer Engagement Department 3,
Automotive Technical Customer Engagement Division,
（ABU / ATCED / ATC3 / Application Engineering Section）

Tel: 010-82351155-6631
 13552056582
URL: http://www.cn.renesas.com




0001-fix-R-Car-gpio0_00-operation-fails-with-gpio-input-c.patch
Description: 0001-fix-R-Car-gpio0_00-operation-fails-with-gpio-input-c.patch
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 00/11] SPL support for RISC-V

[Bin Meng]

Hi Lukas,

On Mon, Jul 22, 2019 at 2:00 AM Lukas Auer
 wrote:
>
> This series adds support for SPL to RISC-V U-Boot. Images can be booted
> via OpenSBI (FW_DYNAMIC firmware) or by directly jumping to them. In the
> former case, OpenSBI and U-Boot proper are bundled as a FIT image and
> made available to U-Boot SPL. Currently, only the QEMU board enables
> U-Boot SPL with a dedicated configuration. It uses RAM as SPL boot
> device.
>
> On many RISC-V CPUs, the device tree is provided to U-Boot by the
> first stage bootloader. This requires changes to U-Boot SPL (patches 1,
> 2 and 3), which modify the behavior on other boards as well. To get
> feedback on this, I am therefore sending this series as RFC first.
>
> To test this series, OpenSBI has to be compiled first. The
> fw_dynamic.bin binary must be copied into the U-Boot root directory.
> Alternatively, the location of the binary can be specified with the
> OPENSBI environment variable. U-Boot can then be build as normal using
> the configuration qemu-riscv64_spl_defconfig for 64-bit builds or
> qemu-riscv32_spl_defconfig for 32-bit builds. The outputs from the build
> process are the U-Boot SPL binary (spl/u-boot-spl.bin) and the U-Boot
> FIT image (u-boot.itb) containing U-Boot proper and OpenSBI.
>
> U-Boot can be run in QEMU with the following command.
>
> qemu-system-riscv64 -nographic -machine virt -kernel spl/u-boot-spl \
> -device loader,file=u-boot.itb,addr=0x8020
>

Nice job done! It looks the SPL support was cleanly implemented.

I've tested this series, on qemu-riscv64 with UP and SMP, both work fine.
However when testing on qemu-riscv32, the U-Boot proper does not boot.
Please have a look.

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

[U-Boot] [PATCH 31/47] configs: P2041RDB: Enable PCIe driver

[Hou Zhiqiang]

Enable the DM PCIe driver in P2041RDB defconfig.

Signed-off-by: Hou Zhiqiang 
---
 configs/P2041RDB_NAND_defconfig | 4 
 configs/P2041RDB_SDCARD_defconfig   | 4 
 configs/P2041RDB_SPIFLASH_defconfig | 4 
 configs/P2041RDB_defconfig  | 4 
 4 files changed, 16 insertions(+)

diff --git a/configs/P2041RDB_NAND_defconfig b/configs/P2041RDB_NAND_defconfig
index 73baf49..43434aa 100644
--- a/configs/P2041RDB_NAND_defconfig
+++ b/configs/P2041RDB_NAND_defconfig
@@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/P2041RDB_SDCARD_defconfig 
b/configs/P2041RDB_SDCARD_defconfig
index d75f8b1..8d0efa4 100644
--- a/configs/P2041RDB_SDCARD_defconfig
+++ b/configs/P2041RDB_SDCARD_defconfig
@@ -40,6 +40,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/P2041RDB_SPIFLASH_defconfig 
b/configs/P2041RDB_SPIFLASH_defconfig
index 925f0cd..eadb35b 100644
--- a/configs/P2041RDB_SPIFLASH_defconfig
+++ b/configs/P2041RDB_SPIFLASH_defconfig
@@ -40,6 +40,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/P2041RDB_defconfig b/configs/P2041RDB_defconfig
index 1923b7a..8208907 100644
--- a/configs/P2041RDB_defconfig
+++ b/configs/P2041RDB_defconfig
@@ -39,6 +39,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
-- 
2.9.5

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

[U-Boot] [PATCH 40/47] P5040: dts: Added PCIe DT nodes

[Hou Zhiqiang]

P5040 integrated 3 PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 2.0, and this
patch is to add DT node for each PCIe controller.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/p5040.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/dts/p5040.dtsi b/arch/powerpc/dts/p5040.dtsi
index b6f6c5d..8ab123d 100644
--- a/arch/powerpc/dts/p5040.dtsi
+++ b/arch/powerpc/dts/p5040.dtsi
@@ -59,4 +59,40 @@
clock-frequency = <0x0>;
};
};
+
+   pcie@ffe20 {
+   compatible = "fsl,pcie-p5040", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe20 0x0 0x1000>;   /* registers */
+   law_trgt_if = <0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf800 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x 0x0 
0x2000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe201000 {
+   compatible = "fsl,pcie-p5040", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe201000 0x0 0x1000>;   /* registers */
+   law_trgt_if = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf801 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe202000 {
+   compatible = "fsl,pcie-p5040", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe202000 0x0 0x1000>;   /* registers */
+   law_trgt_if = <2>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf802 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x4000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
 };
-- 
2.9.5

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

[U-Boot] [PATCH 43/47] powerpc: MPC85xxCDS: Disable legacy PCI fixup when DM_PCI is selected

[Hou Zhiqiang]

Disable legacy PCI and PCIe fixup when CONFIG_DM_PCI is selected.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/common/cds_pci_ft.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/freescale/common/cds_pci_ft.c 
b/board/freescale/common/cds_pci_ft.c
index 3ff2fa4..fb2e5c7 100644
--- a/board/freescale/common/cds_pci_ft.c
+++ b/board/freescale/common/cds_pci_ft.c
@@ -9,6 +9,7 @@
 #include "cadmus.h"
 
 #if defined(CONFIG_OF_BOARD_SETUP)
+#if defined(CONFIG_PCI) && !defined(CONFIG_DM_PCI)
 static void cds_pci_fixup(void *blob)
 {
int node;
@@ -61,11 +62,12 @@ static void cds_pci_fixup(void *blob)
}
}
 }
+#endif
 
 int ft_board_setup(void *blob, bd_t *bd)
 {
ft_cpu_setup(blob, bd);
-#ifdef CONFIG_PCI
+#if defined(CONFIG_PCI) && !defined(CONFIG_DM_PCI)
ft_pci_setup(blob, bd);
cds_pci_fixup(blob);
 #endif
-- 
2.9.5

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

[U-Boot] [PATCH 32/47] dm: pcie_fsl: Add P3041 PCIe support

[Hou Zhiqiang]

Add compatible string for P3041 PCIe.

Signed-off-by: Hou Zhiqiang 
---
 drivers/pci/pcie_fsl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 61f08e7..a4e0cd1 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -629,6 +629,7 @@ static struct fsl_pcie_data t2080_data = {
 static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-p1_p2", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
+   { .compatible = "fsl,pcie-p3041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
-- 
2.9.5

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

[U-Boot] [PATCH 20/47] powerpc: p1_p2_rdb: Compile legacy PCIe routines conditionally

[Hou Zhiqiang]

Compile the legacy PCIe initialization reoutines for P1020,
P1021, P1024, P1025 and P2020 RDB boards only when DM_PCI
is not enabled.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c 
b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 4b151e8..5982a91 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -277,7 +277,7 @@ int checkboard(void)
return 0;
 }
 
-#ifdef CONFIG_PCI
+#if defined(CONFIG_PCI) && !defined(CONFIG_DM_PCI)
 void pci_init_board(void)
 {
fsl_pcie_init_board(0);
@@ -443,7 +443,9 @@ int ft_board_setup(void *blob, bd_t *bd)
 
fdt_fixup_memory(blob, (u64)base, (u64)size);
 
+#if !defined(CONFIG_DM_PCI)
FT_FSL_PCI_SETUP;
+#endif
 
 #ifdef CONFIG_QE
do_fixup_by_compat(blob, "fsl,qe", "status", "okay",
-- 
2.9.5

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

[U-Boot] [PATCH 24/47] configs: P1020RDB: Enable PCIe driver

[Hou Zhiqiang]

Enable the DM PCIe driver in P1020RDB defconfig.

Signed-off-by: Hou Zhiqiang 
---
 configs/P1020RDB-PC_36BIT_NAND_defconfig | 4 
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   | 4 
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig | 4 
 configs/P1020RDB-PC_36BIT_defconfig  | 4 
 configs/P1020RDB-PC_NAND_defconfig   | 4 
 configs/P1020RDB-PC_SDCARD_defconfig | 4 
 configs/P1020RDB-PC_SPIFLASH_defconfig   | 4 
 configs/P1020RDB-PC_defconfig| 4 
 configs/P1020RDB-PD_NAND_defconfig   | 4 
 configs/P1020RDB-PD_SDCARD_defconfig | 4 
 configs/P1020RDB-PD_SPIFLASH_defconfig   | 4 
 configs/P1020RDB-PD_defconfig| 4 
 12 files changed, 48 insertions(+)

diff --git a/configs/P1020RDB-PC_36BIT_NAND_defconfig 
b/configs/P1020RDB-PC_36BIT_NAND_defconfig
index 8fce49d..557fb49 100644
--- a/configs/P1020RDB-PC_36BIT_NAND_defconfig
+++ b/configs/P1020RDB-PC_36BIT_NAND_defconfig
@@ -55,6 +55,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig 
b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
index 80a4a0a..28ec227 100644
--- a/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SDCARD_defconfig
@@ -52,6 +52,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
index ee565d4..84b88ae 100644
--- a/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
+++ b/configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig
@@ -53,6 +53,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_36BIT_defconfig 
b/configs/P1020RDB-PC_36BIT_defconfig
index 7d7c55f..fea964d 100644
--- a/configs/P1020RDB-PC_36BIT_defconfig
+++ b/configs/P1020RDB-PC_36BIT_defconfig
@@ -42,6 +42,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_NAND_defconfig 
b/configs/P1020RDB-PC_NAND_defconfig
index b729089..62199b9 100644
--- a/configs/P1020RDB-PC_NAND_defconfig
+++ b/configs/P1020RDB-PC_NAND_defconfig
@@ -54,6 +54,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_SDCARD_defconfig 
b/configs/P1020RDB-PC_SDCARD_defconfig
index 4622efd..f10e4fa 100644
--- a/configs/P1020RDB-PC_SDCARD_defconfig
+++ b/configs/P1020RDB-PC_SDCARD_defconfig
@@ -51,6 +51,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_SPIFLASH_defconfig 
b/configs/P1020RDB-PC_SPIFLASH_defconfig
index 9cd897f..bacae37 100644
--- a/configs/P1020RDB-PC_SPIFLASH_defconfig
+++ b/configs/P1020RDB-PC_SPIFLASH_defconfig
@@ -52,6 +52,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PC_defconfig b/configs/P1020RDB-PC_defconfig
index 595ff5f..0a6f974 100644
--- a/configs/P1020RDB-PC_defconfig
+++ b/configs/P1020RDB-PC_defconfig
@@ -41,6 +41,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PD_NAND_defconfig 
b/configs/P1020RDB-PD_NAND_defconfig
index b45122d..2c41054 100644
--- a/configs/P1020RDB-PD_NAND_defconfig
+++ b/configs/P1020RDB-PD_NAND_defconfig
@@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_SYS_NS16550=y
diff --git a/configs/P1020RDB-PD_SDCARD_defconfig 
b/configs/P1020RDB-PD_SDCARD_defconfig
index c559879..7f0c7d4 100644
--- a/configs/P1020RDB-PD_SDCARD_defconfig
+++ b/configs/P1020RDB-PD_SDCARD_defconfig
@@ -55,6 +55,10 @@ 

[U-Boot] [PATCH 07/47] powerpc: T4240RDB: Disable legacy PCIe driver when DM_PCI is enabled

[Hou Zhiqiang]

Disable legacy PCIe driver and unused PCIe macros when DM_PCI enabled.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/T4240RDB.h | 35 +++
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git a/include/configs/T4240RDB.h b/include/configs/T4240RDB.h
index a818f0c..8cdc17c 100644
--- a/include/configs/T4240RDB.h
+++ b/include/configs/T4240RDB.h
@@ -63,7 +63,6 @@
 #define CONFIG_PCIE1   /* PCIE controller 1 */
 #define CONFIG_PCIE2   /* PCIE controller 2 */
 #define CONFIG_PCIE3   /* PCIE controller 3 */
-#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 
 #define CONFIG_ENV_OVERWRITE
@@ -178,44 +177,48 @@
 
 /* controller 1, direct to uli, tgtid 3, Base address 2 */
 #define CONFIG_SYS_PCIE1_MEM_VIRT  0x8000
-#define CONFIG_SYS_PCIE1_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE1_MEM_PHYS  0xcull
-#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE1_IO_VIRT   0xf800
-#define CONFIG_SYS_PCIE1_IO_BUS0x
 #define CONFIG_SYS_PCIE1_IO_PHYS   0xff800ull
-#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
 
 /* controller 2, Slot 2, tgtid 2, Base address 201000 */
 #define CONFIG_SYS_PCIE2_MEM_VIRT  0xa000
-#define CONFIG_SYS_PCIE2_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE2_MEM_PHYS  0xc2000ull
-#define CONFIG_SYS_PCIE2_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE2_IO_VIRT   0xf801
-#define CONFIG_SYS_PCIE2_IO_BUS0x
 #define CONFIG_SYS_PCIE2_IO_PHYS   0xff801ull
-#define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
 
 /* controller 3, Slot 1, tgtid 1, Base address 202000 */
 #define CONFIG_SYS_PCIE3_MEM_VIRT  0xc000
-#define CONFIG_SYS_PCIE3_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE3_MEM_PHYS  0xc4000ull
-#define CONFIG_SYS_PCIE3_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE3_IO_VIRT   0xf802
-#define CONFIG_SYS_PCIE3_IO_BUS0x
 #define CONFIG_SYS_PCIE3_IO_PHYS   0xff802ull
-#define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
 
 /* controller 4, Base address 203000 */
 #define CONFIG_SYS_PCIE4_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE4_MEM_PHYS  0xc6000ull
-#define CONFIG_SYS_PCIE4_MEM_SIZE  0x2000  /* 512M */
-#define CONFIG_SYS_PCIE4_IO_BUS0x
 #define CONFIG_SYS_PCIE4_IO_PHYS   0xff803ull
-#define CONFIG_SYS_PCIE4_IO_SIZE   0x0001  /* 64k */
 
 #ifdef CONFIG_PCI
+#if !defined(CONFIG_DM_PCI)
+#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
+#define CONFIG_SYS_PCIE1_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE1_IO_BUS0x
+#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
+#define CONFIG_SYS_PCIE2_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE2_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE2_IO_BUS0x
+#define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
+#define CONFIG_SYS_PCIE3_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE3_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE3_IO_BUS0x
+#define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
+#define CONFIG_SYS_PCIE4_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE4_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE4_IO_BUS0x
+#define CONFIG_SYS_PCIE4_IO_SIZE   0x0001  /* 64k */
 #define CONFIG_PCI_INDIRECT_BRIDGE
+#endif
 
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
 #endif /* CONFIG_PCI */
-- 
2.9.5

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

[U-Boot] [PATCH 12/47] powerpc: T102xRDB: Remove the useless macro CONFIG_ARCH_T1040

[Hou Zhiqiang]

Remove the macro CONFIG_ARCH_T1040 from the T102xRDB.h and
the PCIE4 related macros, as there are only 3 PCIe controllers
on T102x SoCs.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/T102xRDB.h | 24 
 1 file changed, 24 deletions(-)

diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h
index cce65f5..3715e25 100644
--- a/include/configs/T102xRDB.h
+++ b/include/configs/T102xRDB.h
@@ -500,9 +500,6 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_PCIE1   /* PCIE controller 1 */
 #define CONFIG_PCIE2   /* PCIE controller 2 */
 #define CONFIG_PCIE3   /* PCIE controller 3 */
-#ifdef CONFIG_ARCH_T1040
-#define CONFIG_PCIE4   /* PCIE controller 4 */
-#endif
 #define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 #define CONFIG_PCI_INDIRECT_BRIDGE
@@ -571,27 +568,6 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
 #endif
 
-/* controller 4, Base address 203000, to be removed */
-#ifdef CONFIG_PCIE4
-#define CONFIG_SYS_PCIE4_MEM_VIRT   0xb000
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE4_MEM_BUS   0xe000
-#define CONFIG_SYS_PCIE4_MEM_PHYS   0xc3000ull
-#else
-#define CONFIG_SYS_PCIE4_MEM_BUS   0xb000
-#define CONFIG_SYS_PCIE4_MEM_PHYS  0xb000
-#endif
-#define CONFIG_SYS_PCIE4_MEM_SIZE   0x1000  /* 256M */
-#define CONFIG_SYS_PCIE4_IO_VIRT   0xf803
-#define CONFIG_SYS_PCIE4_IO_BUS0x
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE4_IO_PHYS   0xff803ull
-#else
-#define CONFIG_SYS_PCIE4_IO_PHYS   0xf803
-#endif
-#define CONFIG_SYS_PCIE4_IO_SIZE   0x0001  /* 64k */
-#endif
-
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
 #endif /* CONFIG_PCI */
 
-- 
2.9.5

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

[U-Boot] mkimage unable to assign sign value to fitimage

[deepak kumar Pradhan]

HI ,

I am using marvell armada 388 clearfog pro device.
I am using fitimage to upgrade my device. To make the device bootup secure
I want to sign the fitimage and verify the same in u-boot.
1. However I am observing that the mkimage is unable to assign sign value
to my fit image.
2. One more issue I am facing that is when I am enabling the CONFIG_FIT and
FIT_SIGNATURE, the mkimage is throughing error like below



*"mkimage -f fitimage-temp.its -k keys
fitimage-kernel-rfs-dtb.itbUnsupported signature algorithm (sha1,rs2048)
for 'signature@1' signature node in 'kernel@1' image nodemkimage Can't add
hashes to FIT blob"*

Can someone help me out and uide me what I am doing wrong?

Below are the outputs
*mkimage -F -k keys bkp-fitimage-initramfs-script.bin *
FIT description: U-Boot fitImage for Aprisa
NEXT/4.14.54+gitAUTOINC+7c0df4bf46/clearfog
Created: Tue Jul 16 12:25:27 2019
 Image 0 (kernel@1)
  Description:  Linux kernel
  Created:  Tue Jul 16 12:25:27 2019
  Type: Kernel Image
  Compression:  uncompressed
  Data Size:4906704 Bytes = 4791.70 KiB = 4.68 MiB
  Architecture: ARM
  OS:   Linux
  Load Address: 0x01314c40
  Entry Point:  0x01314c40
  Hash algo:crc32
  Hash value:   8aeccf3a
  Hash algo:sha1
  Hash value:   b8fafa028a78428a90304ab913877d2d0adbfd88

*  Sign algo:sha1,rs2048:my_key  Sign value:   unavailable*
  Timestamp:unavailable
 Image 1 (f...@armada-388-clearfog.dtb)
  Description:  Flattened Device Tree blob
  Created:  Tue Jul 16 12:25:27 2019
  Type: Flat Device Tree
  Compression:  uncompressed
  Data Size:18373 Bytes = 17.94 KiB = 0.02 MiB
  Architecture: ARM
  Hash algo:crc32
  Hash value:   dbe5de9d
  Hash algo:sha1
  Hash value:   c1b29ef3c908ecf4c9e800f573a7c33184954b4f
*  Sign algo:sha1,rs2048:my_key*
*  Sign value:   unavailable*
  Timestamp:unavailable

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

[U-Boot] [PATCH 05/47] dm: pcie_fsl: Add T4240 PCIe support

[Hou Zhiqiang]

Add compatible string for T4240 PCIe.

Signed-off-by: Hou Zhiqiang 
---
 drivers/pci/pcie_fsl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index e13e5a6..961d8e3 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -616,6 +616,7 @@ static struct fsl_pcie_data t2080_data = {
 
 static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
+   { .compatible = "fsl,pcie-t4240", .data = (ulong)_data },
{ }
 };
 
-- 
2.9.5

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

[U-Boot] [PATCH 15/47] powerpc: T104xRDB: Compile legacy PCIe routines conditionally

[Hou Zhiqiang]

Compile the legacy PCIe initialization reoutines only when
DM_PCI is not enabled.

Signed-off-by: Hou Zhiqiang 
---
 board/freescale/t104xrdb/pci.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/t104xrdb/pci.c b/board/freescale/t104xrdb/pci.c
index 9fd6659..6b666ba 100644
--- a/board/freescale/t104xrdb/pci.c
+++ b/board/freescale/t104xrdb/pci.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 
+#if !defined(CONFIG_DM_PCI)
 void pci_init_board(void)
 {
fsl_pcie_init_board(0);
@@ -20,3 +21,4 @@ void pci_of_setup(void *blob, bd_t *bd)
 {
FT_FSL_PCI_SETUP;
 }
+#endif
-- 
2.9.5

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

[U-Boot] [PATCH 29/47] P2041: dts: Added PCIe DT nodes

[Hou Zhiqiang]

P2041 integrated 3 PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 2.0, and this
patch is to add DT node for each PCIe controller.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/p2041.dtsi | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/powerpc/dts/p2041.dtsi b/arch/powerpc/dts/p2041.dtsi
index 9aa0422..55f7adc 100644
--- a/arch/powerpc/dts/p2041.dtsi
+++ b/arch/powerpc/dts/p2041.dtsi
@@ -60,4 +60,40 @@
clock-frequency = <0x0>;
};
};
+
+   pcie@ffe20 {
+   compatible = "fsl,pcie-p2041", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe20 0x0 0x1000>;   /* registers */
+   law_trgt_if = <0>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf800 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x 0x0 
0x2000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe201000 {
+   compatible = "fsl,pcie-p2041", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe201000 0x0 0x1000>;   /* registers */
+   law_trgt_if = <1>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf801 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
+
+   pcie@ffe202000 {
+   compatible = "fsl,pcie-p2041", "fsl,pcie-fsl-qoriq";
+   reg = <0xf 0xfe202000 0x0 0x1000>;   /* registers */
+   law_trgt_if = <2>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+   ranges = <0x0100 0x0 0x 0xf 0xf802 0x0 
0x0001   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x4000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
 };
-- 
2.9.5

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

[U-Boot] [PATCH 16/47] dm: pcie_fsl: Add T104x PCIe support

[Hou Zhiqiang]

Add compatible string for T104x PCIe.

Signed-off-by: Hou Zhiqiang 
---
 drivers/pci/pcie_fsl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 25df84d..c4b4ace 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -616,6 +616,7 @@ static struct fsl_pcie_data t2080_data = {
 
 static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
+   { .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t4240", .data = (ulong)_data },
{ }
-- 
2.9.5

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

[U-Boot] [PATCH 39/47] dm: pcie_fsl: Add P5040 PCIe support

[Hou Zhiqiang]

Add compatible string for P5040 PCIe.

Signed-off-by: Hou Zhiqiang 
---
 drivers/pci/pcie_fsl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index f61e39e..1411b1f 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -631,6 +631,7 @@ static const struct udevice_id fsl_pcie_ids[] = {
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p3041", .data = (ulong)_data },
{ .compatible = "fsl,pcie-p4080", .data = (ulong)_data },
+   { .compatible = "fsl,pcie-p5040", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t102x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t104x", .data = (ulong)_data },
{ .compatible = "fsl,pcie-t2080", .data = (ulong)_data },
-- 
2.9.5

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

[U-Boot] [PATCH 19/47] configs: T1042D4RDB: Enable PCIe driver

[Hou Zhiqiang]

Enable the DM PCIe driver in T1042D4RDB defconfig.

Signed-off-by: Hou Zhiqiang 
---
 configs/T1042D4RDB_NAND_defconfig | 4 
 configs/T1042D4RDB_SDCARD_defconfig   | 4 
 configs/T1042D4RDB_SPIFLASH_defconfig | 4 
 configs/T1042D4RDB_defconfig  | 4 
 4 files changed, 16 insertions(+)

diff --git a/configs/T1042D4RDB_NAND_defconfig 
b/configs/T1042D4RDB_NAND_defconfig
index 2edd3b3..e51124b 100644
--- a/configs/T1042D4RDB_NAND_defconfig
+++ b/configs/T1042D4RDB_NAND_defconfig
@@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/T1042D4RDB_SDCARD_defconfig 
b/configs/T1042D4RDB_SDCARD_defconfig
index f5a8613..fa9b3e3 100644
--- a/configs/T1042D4RDB_SDCARD_defconfig
+++ b/configs/T1042D4RDB_SDCARD_defconfig
@@ -57,6 +57,10 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/T1042D4RDB_SPIFLASH_defconfig 
b/configs/T1042D4RDB_SPIFLASH_defconfig
index 945740a..fdec9a2 100644
--- a/configs/T1042D4RDB_SPIFLASH_defconfig
+++ b/configs/T1042D4RDB_SPIFLASH_defconfig
@@ -58,6 +58,10 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
diff --git a/configs/T1042D4RDB_defconfig b/configs/T1042D4RDB_defconfig
index 3be988c..86c0a7f 100644
--- a/configs/T1042D4RDB_defconfig
+++ b/configs/T1042D4RDB_defconfig
@@ -46,6 +46,10 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_SYS_NS16550=y
 CONFIG_SPI=y
-- 
2.9.5

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

[U-Boot] [PATCH 45/47] MPC8548: dts: Added PCIe DT node

[Hou Zhiqiang]

MPC8548 integrated a PCIe controllers, which is compatible with
the PCI Express™ Base Specification, Revision 1.0a, and this
patch is to add DT node for the PCIe controller.

Signed-off-by: Hou Zhiqiang 
---
 arch/powerpc/dts/mpc8548-post.dtsi  | 9 +
 arch/powerpc/dts/mpc8548cds.dts | 6 ++
 arch/powerpc/dts/mpc8548cds_36b.dts | 6 ++
 3 files changed, 21 insertions(+)

diff --git a/arch/powerpc/dts/mpc8548-post.dtsi 
b/arch/powerpc/dts/mpc8548-post.dtsi
index 5533a4b..2206f2d 100644
--- a/arch/powerpc/dts/mpc8548-post.dtsi
+++ b/arch/powerpc/dts/mpc8548-post.dtsi
@@ -25,3 +25,12 @@
last-interrupt-source = <255>;
};
 };
+
+ {
+   compatible = "fsl,pcie-mpc8548", "fsl,pcie-fsl-qoriq";
+   law_trgt_if = <2>;
+   #address-cells = <3>;
+   #size-cells = <2>;
+   device_type = "pci";
+   bus-range = <0x0 0xff>;
+};
diff --git a/arch/powerpc/dts/mpc8548cds.dts b/arch/powerpc/dts/mpc8548cds.dts
index cceea34..3b927bd 100644
--- a/arch/powerpc/dts/mpc8548cds.dts
+++ b/arch/powerpc/dts/mpc8548cds.dts
@@ -18,6 +18,12 @@
soc: soc8548@e000 {
ranges = <0x0 0x0 0xe000 0x10>;
};
+
+   pcie: pcie@e000a000 {
+   reg = <0x0 0xe000a000 0x0 0x1000>;  /* registers */
+   ranges = <0x0100 0x0 0x 0x0 0xe300 0x0 
0x0010   /* downstream I/O */
+ 0x0200 0x0 0xa000 0x0 0xa000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
 };
 
 /include/ "mpc8548-post.dtsi"
diff --git a/arch/powerpc/dts/mpc8548cds_36b.dts 
b/arch/powerpc/dts/mpc8548cds_36b.dts
index faff35c..98d7c24 100644
--- a/arch/powerpc/dts/mpc8548cds_36b.dts
+++ b/arch/powerpc/dts/mpc8548cds_36b.dts
@@ -18,6 +18,12 @@
soc: soc8548@fe000 {
ranges = <0x0 0xf 0xe000 0x10>;
};
+
+   pcie: pcie@fe000a000 {
+   reg = <0xf 0xe000a000 0x0 0x1000>;  /* registers */
+   ranges = <0x0100 0x0 0x 0xf 0xe300 0x0 
0x0010   /* downstream I/O */
+ 0x0200 0x0 0xe000 0xc 0x2000 0x0 
0x2000>; /* non-prefetchable memory */
+   };
 };
 
 /include/ "mpc8548-post.dtsi"
-- 
2.9.5

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

[U-Boot] [PATCH 47/47] configs: MPC8548CDS: Enable PCIe driver

[Hou Zhiqiang]

Enable the DM PCIe driver in MPC8548CDS defconfig.

Signed-off-by: Hou Zhiqiang 
---
 configs/MPC8548CDS_36BIT_defconfig  | 4 
 configs/MPC8548CDS_defconfig| 4 
 configs/MPC8548CDS_legacy_defconfig | 4 
 3 files changed, 12 insertions(+)

diff --git a/configs/MPC8548CDS_36BIT_defconfig 
b/configs/MPC8548CDS_36BIT_defconfig
index f259f19..102716b 100644
--- a/configs/MPC8548CDS_36BIT_defconfig
+++ b/configs/MPC8548CDS_36BIT_defconfig
@@ -26,6 +26,10 @@ CONFIG_SYS_FLASH_CFI=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_CONS_INDEX=2
diff --git a/configs/MPC8548CDS_defconfig b/configs/MPC8548CDS_defconfig
index 72239da..9cccb60 100644
--- a/configs/MPC8548CDS_defconfig
+++ b/configs/MPC8548CDS_defconfig
@@ -25,6 +25,10 @@ CONFIG_SYS_FLASH_CFI=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_CONS_INDEX=2
diff --git a/configs/MPC8548CDS_legacy_defconfig 
b/configs/MPC8548CDS_legacy_defconfig
index f2420c3..782f827 100644
--- a/configs/MPC8548CDS_legacy_defconfig
+++ b/configs/MPC8548CDS_legacy_defconfig
@@ -25,6 +25,10 @@ CONFIG_SYS_FLASH_CFI=y
 CONFIG_PHY_MARVELL=y
 CONFIG_PHY_GIGE=y
 CONFIG_E1000=y
+CONFIG_DM=y
+CONFIG_DM_PCI=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_PCIE_FSL=y
 CONFIG_MII=y
 CONFIG_TSEC_ENET=y
 CONFIG_CONS_INDEX=2
-- 
2.9.5

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

[U-Boot] [PATCH 30/47] powerpc: P2041RDB: Disable legacy PCIe driver when DM_PCI is enabled

[Hou Zhiqiang]

Disable legacy PCIe driver and unused PCIe macros when DM_PCI enabled.

Signed-off-by: Hou Zhiqiang 
---
 include/configs/P2041RDB.h | 55 +-
 1 file changed, 15 insertions(+), 40 deletions(-)

diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h
index b433308..ba670d7 100644
--- a/include/configs/P2041RDB.h
+++ b/include/configs/P2041RDB.h
@@ -37,7 +37,6 @@
 #define CONFIG_PCIE1   /* PCIE controller 1 */
 #define CONFIG_PCIE2   /* PCIE controller 2 */
 #define CONFIG_PCIE3   /* PCIE controller 3 */
-#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_SYS_PCI_64BIT   /* enable 64-bit PCI resources */
 
 #define CONFIG_SYS_SRIO
@@ -354,60 +353,21 @@ unsigned long get_board_sys_clk(unsigned long dummy);
 
 /* controller 1, direct to uli, tgtid 3, Base address 2 */
 #define CONFIG_SYS_PCIE1_MEM_VIRT  0x8000
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE1_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE1_MEM_PHYS  0xcull
-#else
-#define CONFIG_SYS_PCIE1_MEM_BUS   0x8000
-#define CONFIG_SYS_PCIE1_MEM_PHYS  0x8000
-#endif
-#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE1_IO_VIRT   0xf800
-#define CONFIG_SYS_PCIE1_IO_BUS0x
-#ifdef CONFIG_PHYS_64BIT
 #define CONFIG_SYS_PCIE1_IO_PHYS   0xff800ull
-#else
-#define CONFIG_SYS_PCIE1_IO_PHYS   0xf800
-#endif
-#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
 
 /* controller 2, Slot 2, tgtid 2, Base address 201000 */
 #define CONFIG_SYS_PCIE2_MEM_VIRT  0xa000
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE2_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE2_MEM_PHYS  0xc2000ull
-#else
-#define CONFIG_SYS_PCIE2_MEM_BUS   0xa000
-#define CONFIG_SYS_PCIE2_MEM_PHYS  0xa000
-#endif
-#define CONFIG_SYS_PCIE2_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE2_IO_VIRT   0xf801
-#define CONFIG_SYS_PCIE2_IO_BUS0x
-#ifdef CONFIG_PHYS_64BIT
 #define CONFIG_SYS_PCIE2_IO_PHYS   0xff801ull
-#else
-#define CONFIG_SYS_PCIE2_IO_PHYS   0xf801
-#endif
-#define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
 
 /* controller 3, Slot 1, tgtid 1, Base address 202000 */
 #define CONFIG_SYS_PCIE3_MEM_VIRT  0xc000
-#ifdef CONFIG_PHYS_64BIT
-#define CONFIG_SYS_PCIE3_MEM_BUS   0xe000
 #define CONFIG_SYS_PCIE3_MEM_PHYS  0xc4000ull
-#else
-#define CONFIG_SYS_PCIE3_MEM_BUS   0xc000
-#define CONFIG_SYS_PCIE3_MEM_PHYS  0xc000
-#endif
-#define CONFIG_SYS_PCIE3_MEM_SIZE  0x2000  /* 512M */
 #define CONFIG_SYS_PCIE3_IO_VIRT   0xf802
-#define CONFIG_SYS_PCIE3_IO_BUS0x
-#ifdef CONFIG_PHYS_64BIT
 #define CONFIG_SYS_PCIE3_IO_PHYS   0xff802ull
-#else
-#define CONFIG_SYS_PCIE3_IO_PHYS   0xf802
-#endif
-#define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
 
 /* Qman/Bman */
 #define CONFIG_SYS_BMAN_NUM_PORTALS10
@@ -489,7 +449,22 @@ unsigned long get_board_sys_clk(unsigned long dummy);
 #endif
 
 #ifdef CONFIG_PCI
+#if !defined(CONFIG_DM_PCI)
+#define CONFIG_FSL_PCI_INIT/* Use common FSL init code */
 #define CONFIG_PCI_INDIRECT_BRIDGE
+#define CONFIG_SYS_PCIE1_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE1_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE1_IO_BUS0x
+#define CONFIG_SYS_PCIE1_IO_SIZE   0x0001  /* 64k */
+#define CONFIG_SYS_PCIE2_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE2_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE2_IO_BUS0x
+#define CONFIG_SYS_PCIE2_IO_SIZE   0x0001  /* 64k */
+#define CONFIG_SYS_PCIE3_MEM_BUS   0xe000
+#define CONFIG_SYS_PCIE3_MEM_SIZE  0x2000  /* 512M */
+#define CONFIG_SYS_PCIE3_IO_BUS0x
+#define CONFIG_SYS_PCIE3_IO_SIZE   0x0001  /* 64k */
+#endif
 
 #define CONFIG_PCI_SCAN_SHOW   /* show pci devices on startup */
 #endif /* CONFIG_PCI */
-- 
2.9.5

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