Re: [U-Boot] [PATCH v7 10/13] cmd: mtd: add 'mtd' command

[Miquel Raynal]

Hi Stefan,

Stefan Roese  wrote on Sat, 1 Sep 2018 10:59:56 +0200:

> On 31.08.2018 16:57, Miquel Raynal wrote:
> > There should not be a 'nand' command, a 'sf' command and certainly not
> > a new 'spi-nand' command. Write a 'mtd' command instead to manage all
> > MTD devices/partitions at once. This should be the preferred way to
> > access any MTD device.  
> > > Signed-off-by: Miquel Raynal   
> > Acked-by: Jagan Teki 
> > ---
> >   cmd/Kconfig  |  10 +-
> >   cmd/Makefile |   1 +
> >   cmd/mtd.c| 517 +++
> >   drivers/mtd/Makefile |   2 +-
> >   include/mtd.h|   1 +
> >   5 files changed, 528 insertions(+), 3 deletions(-)
> >   create mode 100644 cmd/mtd.c  
> > > diff --git a/cmd/Kconfig b/cmd/Kconfig  
> > index ef43ed8dda..0778d2ecff 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -847,6 +847,12 @@ config CMD_MMC_SWRITE
> >   Enable support for the "mmc swrite" command to write Android sparse
> >   images to eMMC.  
> >   > +config CMD_MTD  
> > +   bool "mtd"
> > +   select MTD_PARTITIONS
> > +   help
> > + MTD commands support.
> > +
> >   config CMD_NAND
> > bool "nand"
> > default y if NAND_SUNXI
> > @@ -1671,14 +1677,14 @@ config CMD_MTDPARTS  
> >   >   config MTDIDS_DEFAULT  
> > string "Default MTD IDs"
> > -   depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > +   depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > help
> >   Defines a default MTD IDs list for use with MTD partitions in the
> >   Linux MTD command line partitions format.  
> >   >   config MTDPARTS_DEFAULT  
> > string "Default MTD partition scheme"
> > -   depends on CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > +   depends on CMD_MTD || CMD_MTDPARTS || CMD_NAND || CMD_FLASH
> > help
> >   Defines a default MTD partitioning scheme in the Linux MTD command
> >   line partitions format
> > diff --git a/cmd/Makefile b/cmd/Makefile
> > index 323f1fd2c7..32fd102189 100644
> > --- a/cmd/Makefile
> > +++ b/cmd/Makefile
> > @@ -90,6 +90,7 @@ obj-$(CONFIG_CMD_MISC) += misc.o
> >   obj-$(CONFIG_CMD_MMC) += mmc.o
> >   obj-$(CONFIG_CMD_MMC_SPI) += mmc_spi.o
> >   obj-$(CONFIG_MP) += mp.o
> > +obj-$(CONFIG_CMD_MTD) += mtd.o
> >   obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
> >   obj-$(CONFIG_CMD_NAND) += nand.o
> >   obj-$(CONFIG_CMD_NET) += net.o
> > diff --git a/cmd/mtd.c b/cmd/mtd.c
> > new file mode 100644
> > index 00..32295fe86c
> > --- /dev/null
> > +++ b/cmd/mtd.c
> > @@ -0,0 +1,517 @@
> > +// SPDX-License-Identifier:  GPL-2.0+
> > +/*
> > + * mtd.c
> > + *
> > + * Generic command to handle basic operations on any memory device.
> > + *
> > + * Copyright: Bootlin, 2018
> > + * Author: Miquèl Raynal 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define MTD_NAME_MAX_LEN 20
> > +
> > +static char *old_mtdparts;
> > +
> > +static void mtd_dump_buf(u8 *buf, uint len, uint offset)
> > +{
> > +   int i, j;
> > +
> > +   for (i = 0; i < len; ) {
> > +   printf("0x%08x:\t", offset + i);
> > +   for (j = 0; j < 8; j++)
> > +   printf("%02x ", buf[i + j]);
> > +   printf(" ");
> > +   i += 8;
> > +   for (j = 0; j < 8; j++)
> > +   printf("%02x ", buf[i + j]);
> > +   printf("\n");
> > +   i += 8;
> > +   }
> > +}
> > +
> > +static void mtd_show_parts(struct mtd_info *mtd, int level)
> > +{
> > +   struct mtd_info *part;
> > +   int i;
> > +
> > +   if (list_empty(&mtd->partitions))
> > +   return;
> > +
> > +   list_for_each_entry(part, &mtd->partitions, node) {
> > +   for (i = 0; i < level; i++)
> > +   printf("\t");
> > +   printf("* %s\n", part->name);
> > +   for (i = 0; i < level; i++)
> > +   printf("\t");
> > +   printf("  > Offset: 0x%llx bytes\n", part->offset);
> > +   for (i = 0; i < level; i++)
> > +   printf("\t");
> > +   printf("  > Size: 0x%llx bytes\n", part->size);
> > +
> > +   mtd_show_parts(part, level + 1);
> > +   }
> > +}
> > +
> > +static void mtd_show_device(struct mtd_info *mtd)
> > +{
> > +   /* Device */
> > +   printf("* %s", mtd->name);
> > +   if (mtd->dev)
> > +   printf(" [device: %s] [parent: %s] [driver: %s]",
> > +  mtd->dev->name, mtd->dev->parent->name,
> > +  mtd->dev->driver->name);
> > +   printf("\n");
> > +
> > +   /* MTD device information */
> > +   printf("  > type: ");
> > +   switch (mtd->type) {
> > +   case MTD_RAM:
> > +   printf("RAM\n");
> > +   break;
> > +   case MTD_ROM:
> > +   printf("ROM\n");
> > +   break;
> > +   case MTD_NORFLASH:
> > +   printf("NOR flash\n");
> > +   break;
> > +   case MTD_NANDFLASH:
> > +

Re: [U-Boot] [PATCH v7 02/13] lib: strto: fix metric suffix parsing in strtoul[l]

[Miquel Raynal]

Hi Stefan,

Stefan Roese  wrote on Sat, 1 Sep 2018 10:48:25 +0200:

> On 31.08.2018 16:57, Miquel Raynal wrote:
> > While 1kB or 1kiB will be parsed correctly, 1k will return the right
> > amount, but the metric suffix will not be escaped once the char
> > pointer updated. Fix this situation by simplifying the move of the
> > endp pointer.  
> > > Signed-off-by: Miquel Raynal   
> > ---
> >   lib/strto.c | 22 ++
> >   1 file changed, 10 insertions(+), 12 deletions(-)  
> > > diff --git a/lib/strto.c b/lib/strto.c  
> > index 84f8d92d57..502a0153e7 100644
> > --- a/lib/strto.c
> > +++ b/lib/strto.c
> > @@ -97,12 +97,11 @@ unsigned long ustrtoul(const char *cp, char **endp, 
> > unsigned int base)
> > case 'K':
> > case 'k':
> > result *= 1024;
> > -   if ((*endp)[1] == 'i') {
> > -   if ((*endp)[2] == 'B')
> > -   (*endp) += 3;
> > -   else
> > -   (*endp) += 2;
> > -   }
> > +   (*endp)++;
> > +   if (**endp == 'i')
> > +   (*endp)++;
> > +   if (**endp == 'B')
> > +   (*endp)++;
> > }
> > return result;
> >   }
> > @@ -122,12 +121,11 @@ unsigned long long ustrtoull(const char *cp, char 
> > **endp, unsigned int base)
> > case 'K':
> > case 'k':
> > result *= 1024;
> > -   if ((*endp)[1] == 'i') {
> > -   if ((*endp)[2] == 'B')
> > -   (*endp) += 3;
> > -   else
> > -   (*endp) += 2;
> > -   }
> > +   (*endp)++;
> > +   if (**endp == 'i')
> > +   (*endp)++;
> > +   if (**endp == 'B')
> > +   (*endp)++;
> > }
> > return result;
> >   }
> >   
> Even though KiB is not equal to KB in general (at least in Linux
> userspace AFAIK), lets not change this in U-Boot and always use
> KiB and KB as a representation for 1024 (instead of 1000). So:

That's right I did not mentioned it in the commit log. I could
update it to reflect that it is intentional to mix 'k' and 'kiB' as a
representation of '* 12014' (already the case, but being clarified in
the above change).

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

Re: [U-Boot] [PATCH v7 01/13] lib: strto: parse all lowercase metric prefixes in ustrtoul[l]

[Miquel Raynal]

Hi Stefan,

Stefan Roese  wrote on Sat, 1 Sep 2018 10:43:01 +0200:

> On 31.08.2018 16:57, Miquel Raynal wrote:
> > Both ustrtoul and ustrtoull interpret 1k but not 1m or 1g. Even if the
> > SI symbols for Mega and Giga are 'M' and 'G', certain entries of
> > eg. mtdparts also use (wrongly) the metric prefix 'm' and 'g'.  
> > > I do not see how parsing lowercase prefixes could break anything, so  
> > parse them like their uppercase counterpart.  
> > > Signed-off-by: Miquel Raynal   
> > ---
> >   lib/strto.c | 4 
> >   1 file changed, 4 insertions(+)  
> > > diff --git a/lib/strto.c b/lib/strto.c  
> > index 7f6076909a..84f8d92d57 100644
> > --- a/lib/strto.c
> > +++ b/lib/strto.c
> > @@ -87,9 +87,11 @@ unsigned long ustrtoul(const char *cp, char **endp, 
> > unsigned int base)
> > unsigned long result = simple_strtoul(cp, endp, base);
> > switch (**endp) {
> > case 'G':
> > +   case 'g':
> > result *= 1024;
> > /* fall through */
> > case 'M':
> > +   case 'm':
> > result *= 1024;
> > /* fall through */
> > case 'K':
> > @@ -110,9 +112,11 @@ unsigned long long ustrtoull(const char *cp, char 
> > **endp, unsigned int base)
> > unsigned long long result = simple_strtoull(cp, endp, base);
> > switch (**endp) {
> > case 'G':
> > +   case 'g':
> > result *= 1024;
> > /* fall through */
> > case 'M':
> > +   case 'm':  
> 
> Wouldn't it be better, to use tolower() on the char and drop all the
> upper case checks completely - also for the 'K' case?

Sure, I can do that!

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

Re: [U-Boot] [PATCH v6 00/31] SPI-NAND support

[Miquel Raynal]

Hi Jagan,

Jagan Teki  wrote on Sun, 2 Sep 2018
23:47:37 +0530:

> On Thu, Aug 30, 2018 at 6:13 PM, Miquel Raynal
>  wrote:
> > Hello,
> >
> > Miquel Raynal  wrote on Fri, 17 Aug 2018
> > 10:38:46 +0200:
> >  
> >> Hi Tom, Jagan,
> >>
> >> Boris Brezillon  wrote on Thu, 16 Aug 2018
> >> 18:58:58 +0200:
> >>  
> >> > Tom, Jagan,
> >> >
> >> > On Thu, 16 Aug 2018 17:29:58 +0200
> >> > Miquel Raynal  wrote:
> >> >  
> >> > > During the last months, Boris Brezillon shared his work to support
> >> > > serial flashes within Linux. First, he delivered (and merged) a new
> >> > > layer called spi-mem. He also initiated in Linux MTD subsystem the move
> >> > > of all 'raw' NAND related code to a raw/ subdirectory, adding at the
> >> > > same time a NAND core that would be shared with all NAND devices. Then,
> >> > > he contributed a generic SPI-NAND driver, making use of this NAND core,
> >> > > as well as some vendor code to drive a few chips.
> >> > >
> >> > > On top of this work, I made some cleanups in the MTD layer and added an
> >> > > 'mtd' U-Boot command to handle all sort of MTD devices. This should
> >> > > become the default command instead of having one per flash flavor
> >> > > ('sf', 'nand', 'spi-nand' ?).
> >> > >
> >> > > The series has been tested on an Ocelot board PCB123 (VSC7514),
> >> > > featuring a Macronix SPI NAND chip.
> >> > >
> >> > > TL;DR: the series contains:
> >> > > - A few patches from Linux to resynchronize some areas of the MTD 
> >> > > layer.
> >> > > - Various fixes and re-organization of the MTD subsystem.
> >> > > - The introduction of the SPI-mem interface.
> >> > > - The addition of the generic SPI-NAND driver (and its bindings).
> >> > > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
> >> > > - A new 'mtd' command.
> >> > > - Support for spi-nand devices in mtdparts.
> >> > >
> >> > > To test your SPI-NAND device with U-Boot simply follow these lines:
> >> > >  
> >> > > > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
> >> > > > ubi part bar # create a static UBI volume in the bar 
> >> > > > partition
> >> > > > mtd list # show the current MTD devices/partitions  
> >> > >
> >> > > Thanks,
> >> > > Miquèl
> >> > >  
> >> >
> >> > [...]
> >> >
> >> > Can we get some of those patches merged to avoid sending another
> >> > version containing more than 30 patches. Here is a list of patches which
> >> > IMO are ready to be merged:
> >> >
> >> >  - 1 to 4
> >> >  - 5 and 6 if 6 is squashed in 5
> >> >  - 7 to 23  
> 
> Yes, I've picked these and build is under progress [1]
> 
> [1] https://travis-ci.org/openedev/u-boot-amarula/builds/423668176

Cool! I'll poll the page for build errors but do not hesitate to ping
if you see something wrong.

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

Re: [U-Boot] [PATCH 00/12] riscv: Add QEMU virt board support

[Rick Chen]

 > From: Bin Meng [mailto:bmeng...@gmail.com]
 > Sent: Thursday, August 30, 2018 3:54 PM
 > To: Rick Jian-Zhi Chen(陳建志); U-Boot Mailing List
 > Subject: [PATCH 00/12] riscv: Add QEMU virt board support
 >
 > This series adds QEMU RISC-V 'virt' board target support, with the hope of
 > helping people easily test U-Boot on RISC-V.
 >
 > Some existing RISC-V codes have been changed to make it easily to support new
 > targets. Some spotted coding style issues are fixed.
 >
 > This series is available at u-boot-x86/riscv-working for testing.
 >
 >
 > Bin Meng (12):
 >   riscv: kconfig: Normalize architecture name spelling
 >   riscv: Remove setup.h
 >   riscv: bootm: Correct the 1st kernel argument to hart id
 >   riscv: Remove mach type
 >   riscv: Move the linker script to the CPU root directory
 >   riscv: Fix coding style issues in the linker script
 >   riscv: Explicitly pass -march and -mabi to the compiler
 >   riscv: Add a helper routine to print CPU information
 >   riscv: Make start.S available for all targets
 >   riscv: ae350: Clean up mixed tabs and spaces in the dts
 >   riscv: kconfig: Select DM and OF_CONTROL
 >   riscv: Add QEMU virt board support
 >
 >  arch/Kconfig|   5 +-
 >  arch/riscv/Kconfig  |  10 +-
 >  arch/riscv/Makefile |   3 +-
 >  arch/riscv/config.mk|   9 +-
 >  arch/riscv/cpu/Makefile |   7 ++
 >  arch/riscv/cpu/ax25/Makefile|   2 -
 >  arch/riscv/cpu/cpu.c|  49 
 >  arch/riscv/cpu/qemu/Makefile|   6 +
 >  arch/riscv/cpu/qemu/cpu.c   |  29 +
 >  arch/riscv/cpu/qemu/dram.c  |  17 +++
 >  arch/riscv/cpu/{ax25 => }/start.S   |   0
 >  arch/riscv/cpu/{ax25 => }/u-boot.lds|  60 +-
 >  arch/riscv/dts/ae350.dts| 177 +++--
 >  arch/riscv/include/asm/bootm.h  |  13 ---
 >  arch/riscv/include/asm/csr.h| 124 
 >  arch/riscv/include/asm/mach-types.h |  29 -
 >  arch/riscv/include/asm/setup.h  | 194

 >  arch/riscv/include/asm/u-boot.h |   1 -
 >  arch/riscv/lib/bootm.c  |  19 +---
 >  board/AndesTech/ax25-ae350/ax25-ae350.c |   2 -
 >  board/emulation/qemu-riscv/Kconfig  |  21 
 >  board/emulation/qemu-riscv/MAINTAINERS  |   7 ++
 >  board/emulation/qemu-riscv/Makefile |   5 +
 >  board/emulation/qemu-riscv/qemu-riscv.c |  23 
 >  cmd/bdinfo.c|   1 -
 >  configs/ax25-ae350_defconfig|   2 -
 >  configs/qemu-riscv32_defconfig  |  10 ++
 >  configs/qemu-riscv64_defconfig  |  11 ++
 >  doc/README.qemu-riscv   |  46 
 >  include/configs/qemu-riscv.h|  21 
 >  30 files changed, 520 insertions(+), 383 deletions(-)  create mode 100644
 > arch/riscv/cpu/Makefile  create mode 100644 arch/riscv/cpu/cpu.c  create
 > mode 100644 arch/riscv/cpu/qemu/Makefile  create mode 100644
 > arch/riscv/cpu/qemu/cpu.c  create mode 100644 arch/riscv/cpu/qemu/dram.c
 > rename arch/riscv/cpu/{ax25 => }/start.S (100%)  rename arch/riscv/cpu/{ax25
 > => }/u-boot.lds (54%)  delete mode 100644 arch/riscv/include/asm/bootm.h
 > create mode 100644 arch/riscv/include/asm/csr.h  delete mode 100644
 > arch/riscv/include/asm/mach-types.h
 >  delete mode 100644 arch/riscv/include/asm/setup.h  create mode 100644
 > board/emulation/qemu-riscv/Kconfig
 >  create mode 100644 board/emulation/qemu-riscv/MAINTAINERS
 >  create mode 100644 board/emulation/qemu-riscv/Makefile
 >  create mode 100644 board/emulation/qemu-riscv/qemu-riscv.c
 >  create mode 100644 configs/qemu-riscv32_defconfig  create mode 100644
 > configs/qemu-riscv64_defconfig  create mode 100644 doc/README.qemu-riscv
 > create mode 100644 include/configs/qemu-riscv.h
 >
 > --
 > 2.7.4
>

Hi Bin

Thanks for your reviewing for code clean and make it easier to support
new targets.
I will merge this series to u-boot-riscv when next merge window open. :)

B.R

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

[U-Boot] [PATCH v3 5/8] powerpc: mpc85xx: Select BINMAN by default

[Jagdish Gediya]

Signed-off-by: Jagdish Gediya 
Reviewed-by: Bin Meng 
---
 No changes for v2 and v3.

 arch/powerpc/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 8faef0b..c727d91 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -20,6 +20,7 @@ config MPC85xx
select CREATE_ARCH_SYMLINK
select SYS_FSL_DDR
select SYS_FSL_DDR_BE
+   select BINMAN
imply CMD_HASH
imply CMD_IRQ
imply USB_EHCI_HCD if USB
-- 
2.7.4

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

[U-Boot] [PATCH v3 7/8] powerpc: dts: Add u-boot.dtsi to use binman for MPC85xx boards

[Jagdish Gediya]

Signed-off-by: Jagdish Gediya 
Reviewed-by: Bin Meng 
---
Changes for v2:
- Remove mpc85xx-u-boot.dtsi
- Update u-boot.dtsi to use CONFIG_MPC85XX_HAVE_RESET_VECTOR

Changes for v3:
- Use 'sort-by-offset' property instead of 'sort-by-pos'

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

diff --git a/arch/powerpc/dts/u-boot.dtsi b/arch/powerpc/dts/u-boot.dtsi
new file mode 100644
index 000..213d543
--- /dev/null
+++ b/arch/powerpc/dts/u-boot.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+#include 
+
+/ {
+   binman {
+   filename = "u-boot-with-dtb.bin";
+   skip-at-start = ;
+   sort-by-offset;
+   pad-byte = <0xff>;
+   size = ;
+
+   u-boot-with-ucode-ptr {
+   offset = ;
+   optional-ucode;
+   };
+
+   u-boot-dtb-with-ucode {
+#ifdef CONFIG_MPC85xx
+   align = <256>;
+#endif
+   };
+#ifdef CONFIG_MPC85XX_HAVE_RESET_VECTOR
+   powerpc-mpc85xx-bootpg-resetvec {
+   offset = <(CONFIG_RESET_VECTOR_ADDRESS - 0xffc)>;
+   };
+#endif
+   };
+};
-- 
2.7.4

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

[U-Boot] [PATCH v3 6/8] powerpc: mpc85xx: Use binman to embed dtb inside U-Boot

[Jagdish Gediya]

Below is the sequence to embed dtb inside U-Boot,
1. Remove bootpg and resetvec section if needed
2. Append dtb
3. Append bootpg and resetvec section back if removed in step 1

Above procedure is required only when CONFIG_MPC85xx and
CONFIG_OF_SEPARATE are defined.

Add new config CONFIG_MPC85XX_HAVE_RESET_VECTOR to indicate that
image has resetvec section. Step 1 and step 3 described above are
required only if this config is y.

Signed-off-by: Jagdish Gediya 
---
Changes for v2:
- Don't change the generic target
- Add new config option to use binman

Changes for v3:
- Commit message change('u-boot' -> 'U-Boot')

 Makefile | 23 ++-
 arch/powerpc/cpu/mpc85xx/Kconfig |  4 
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index b5bf8ab..03baa74 100644
--- a/Makefile
+++ b/Makefile
@@ -861,6 +861,10 @@ ifneq ($(CONFIG_SYS_INIT_SP_BSS_OFFSET),)
 ALL-y += init_sp_bss_offset_check
 endif
 
+ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
+ALL-y += u-boot-with-dtb.bin
+endif
+
 LDFLAGS_u-boot += $(LDFLAGS_FINAL)
 
 # Avoid 'Not enough room for program headers' error on binutils 2.28 onwards.
@@ -983,7 +987,8 @@ spl/u-boot-spl.srec: spl/u-boot-spl FORCE
$(call if_changed,objcopy)
 
 OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
-   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec)
+   $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
+   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R 
.resetvec)
 
 binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
@@ -1202,6 +1207,18 @@ u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
$(call if_changed,socboot)
 endif
 
+ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
+u-boot-with-dtb.bin: u-boot.bin u-boot.dtb \
+   $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR), u-boot-br.bin) FORCE
+   $(call if_changed,binman)
+
+ifeq ($(CONFIG_MPC85XX_HAVE_RESET_VECTOR),y)
+OBJCOPYFLAGS_u-boot-br.bin := -O binary -j .bootpg -j .resetvec
+u-boot-br.bin: u-boot FORCE
+   $(call if_changed,objcopy)
+endif
+endif
+
 # x86 uses a large ROM. We fill it with 0xff, put the 16-bit stuff (including
 # reset vector) at the top, Intel ME descriptor at the bottom, and U-Boot in
 # the middle. This is handled by binman based on an image description in the
@@ -1296,8 +1313,12 @@ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
 ifeq ($(ARCH),arm)
 UBOOT_BINLOAD := u-boot.img
 else
+ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
+UBOOT_BINLOAD := u-boot-with-dtb.bin
+else
 UBOOT_BINLOAD := u-boot.bin
 endif
+endif
 
 OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary 
--pad-to=$(CONFIG_SPL_PAD_TO) \
  --gap-fill=0xff
diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 19e8d02..7d139ff 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -1143,6 +1143,10 @@ config ARCH_T4240
imply CMD_REGINFO
imply FSL_SATA
 
+config MPC85XX_HAVE_RESET_VECTOR
+   bool "Indicate reset vector at CONFIG_RESET_VECTOR_ADDRESS - 0xffc"
+   depends on MPC85xx
+
 config BOOKE
bool
default y
-- 
2.7.4

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

[U-Boot] [PATCH v3 2/8] powerpc/dts: Makefile changes to clean and build dts

[Jagdish Gediya]

Signed-off-by: Jagdish Gediya 
Reviewed-by: Bin Meng 
Reviewed-by: Simon Glass 
---
 No changes for v2 and v3.

 arch/powerpc/dts/Makefile | 12 
 dts/Makefile  |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/dts/Makefile

diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
new file mode 100644
index 000..de14e7b
--- /dev/null
+++ b/arch/powerpc/dts/Makefile
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+targets += $(dtb-y)
+
+# Add any required device tree compiler flags here
+DTC_FLAGS +=
+
+PHONY += dtbs
+dtbs: $(addprefix $(obj)/, $(dtb-y))
+   @:
+
+clean-files := *.dtb
diff --git a/dts/Makefile b/dts/Makefile
index 36dfbe7..9a9a3d5 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -61,4 +61,4 @@ dtbs: $(obj)/dt.dtb $(obj)/dt-spl.dtb
 clean-files := dt.dtb.S dt-spl.dtb.S
 
 # Let clean descend into dts directories
-subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts 
../arch/sandbox/dts ../arch/x86/dts
+subdir- += ../arch/arm/dts ../arch/microblaze/dts ../arch/mips/dts 
../arch/sandbox/dts ../arch/x86/dts ../arch/powerpc/dts
-- 
2.7.4

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

[U-Boot] [PATCH v3 8/8] powerpc: dts: Enable device tree support for T2080QDS

[Jagdish Gediya]

Add device tree for T2080QDS board and enable CONFIG_OF_CONTROL
so that device tree can be compiled.

Update board README for device tree usage.

Signed-off-by: Jagdish Gediya 
Reviewed-by: Bin Meng 
---
Changes for v2:
- Enable CONFIG_MPC85XX_HAVE_RESET_VECTOR in T2080QDS_defconfig
- README and commit message changes as per Bin Meng's comments

No changes for v3.

 arch/powerpc/dts/Makefile |  2 ++
 arch/powerpc/dts/e6500_power_isa.dtsi | 39 ++
 arch/powerpc/dts/t2080.dtsi   | 62 +++
 arch/powerpc/dts/t2080qds.dts | 17 ++
 board/freescale/t208xqds/README   | 19 +++
 configs/T2080QDS_NAND_defconfig   |  3 +-
 configs/T2080QDS_SDCARD_defconfig |  3 +-
 configs/T2080QDS_SPIFLASH_defconfig   |  3 +-
 configs/T2080QDS_defconfig|  4 ++-
 9 files changed, 148 insertions(+), 4 deletions(-)
 create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
 create mode 100644 arch/powerpc/dts/t2080.dtsi
 create mode 100644 arch/powerpc/dts/t2080qds.dts

diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index de14e7b..a19aa56 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -1,5 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0+
 
+dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb
+
 targets += $(dtb-y)
 
 # Add any required device tree compiler flags here
diff --git a/arch/powerpc/dts/e6500_power_isa.dtsi 
b/arch/powerpc/dts/e6500_power_isa.dtsi
new file mode 100644
index 000..1b06170
--- /dev/null
+++ b/arch/powerpc/dts/e6500_power_isa.dtsi
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * e6500 Power ISA Device Tree Source (include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+/ {
+   cpus {
+   power-isa-version = "2.06";
+   power-isa-b;// Base
+   power-isa-e;// Embedded
+   power-isa-atb;  // Alternate Time Base
+   power-isa-cs;   // Cache Specification
+   power-isa-ds;   // Decorated Storage
+   power-isa-e.ed; // Embedded.Enhanced Debug
+   power-isa-e.pd; // Embedded.External PID
+   power-isa-e.hv; // Embedded.Hypervisor
+   power-isa-e.le; // Embedded.Little-Endian
+   power-isa-e.pm; // Embedded.Performance Monitor
+   power-isa-e.pc; // Embedded.Processor Control
+   power-isa-ecl;  // Embedded Cache Locking
+   power-isa-exp;  // External Proxy
+   power-isa-fp;   // Floating Point
+   power-isa-fp.r; // Floating Point.Record
+   power-isa-mmc;  // Memory Coherence
+   power-isa-scpm; // Store Conditional Page Mobility
+   power-isa-wt;   // Wait
+   power-isa-64;   // 64-bit
+   power-isa-e.pt; // Embedded.Page Table
+   power-isa-e.hv.lrat;// Embedded.Hypervisor.LRAT
+   power-isa-e.em; // Embedded Multi-Threading
+   power-isa-v;// Vector (AltiVec)
+   fsl,eref-er;// Enhanced Reservations
+   fsl,eref-deo;   // Data Cache Extended Operations
+   mmu-type = "power-embedded";
+   };
+};
diff --git a/arch/powerpc/dts/t2080.dtsi b/arch/powerpc/dts/t2080.dtsi
new file mode 100644
index 000..db65ea5
--- /dev/null
+++ b/arch/powerpc/dts/t2080.dtsi
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+ OR X11
+/*
+ * T2080/T2081 Silicon/SoC Device Tree Source (pre include)
+ *
+ * Copyright 2013 Freescale Semiconductor Inc.
+ * Copyright 2018 NXP
+ */
+
+/dts-v1/;
+
+/include/ "e6500_power_isa.dtsi"
+
+/ {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   interrupt-parent = <&mpic>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu0: PowerPC,e6500@0 {
+   device_type = "cpu";
+   reg = <0 1>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   cpu1: PowerPC,e6500@2 {
+   device_type = "cpu";
+   reg = <2 3>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   cpu2: PowerPC,e6500@4 {
+   device_type = "cpu";
+   reg = <4 5>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   cpu3: PowerPC,e6500@6 {
+   device_type = "cpu";
+   reg = <6 7>;
+   fsl,portid-mapping = <0x8000>;
+   };
+   };
+
+   soc: soc@ffe00 {
+   ranges = <0x

[U-Boot] [PATCH v3 3/8] binman: Add a new "skip-at-start" property in Section class

[Jagdish Gediya]

Currently binman calculates '_skip_at_start' based on 'end-at-4gb'
property and it is used for x86 images.

For PowerPC mpc85xx based CPU, CONFIG_SYS_TEXT_BASE is the entry
offset of the first entry. It can be 0xeff4 or 0xfff4 for
nor flash boot, 0x201000 for sd boot etc, so "_skip_at_start"
should be set to CONFIG_SYS_TEXT_BASE.

'end-at-4gb' property is not applicable where CONFIG_SYS_TEXT_BASE +
Image size != 4gb.

Add new property 'skip-at-start' in Section class so that
'_skip_at_start' can be calculated either based on 'end-at-4gb'
or based on "skip-at-start".

Add a test case to check that 'skip-at-start' and 'end-at-4gb'
property can't be used together.

Signed-off-by: Jagdish Gediya 
Reviewed-by: Bin Meng 
---
Changes for v2:
- Renamed 'start-pos' property to 'skip-at-start'
- Updated README

Changes for v3:
- Modification as per Simon Glass's comments
- Added test case for 'skip-at-start' property

 tools/binman/README |  9 +
 tools/binman/bsection.py| 15 +++
 tools/binman/ftest.py   |  8 
 .../test/80_4gb_and_skip_at_start_together.dts  | 21 +
 4 files changed, 49 insertions(+), 4 deletions(-)
 create mode 100644 tools/binman/test/80_4gb_and_skip_at_start_together.dts

diff --git a/tools/binman/README b/tools/binman/README
index cb34171..7cd33d4 100644
--- a/tools/binman/README
+++ b/tools/binman/README
@@ -397,6 +397,15 @@ end-at-4gb:
8MB ROM, the offset of the first entry would be 0xfff8 with
this option, instead of 0 without this option.
 
+skip-at-start:
+   This property specifies the entry offset of the first entry.
+
+   For PowerPC mpc85xx based CPU, CONFIG_SYS_TEXT_BASE is the entry
+   offset of the first entry. It can be 0xeff4 or 0xfff4 for
+   nor flash boot, 0x201000 for sd boot etc.
+
+   'end-at-4gb' property is not applicable where CONFIG_SYS_TEXT_BASE +
+   Image size != 4gb.
 
 Examples of the above options can be found in the tests. See the
 tools/binman/test directory.
diff --git a/tools/binman/bsection.py b/tools/binman/bsection.py
index a0bd1b6..5910092 100644
--- a/tools/binman/bsection.py
+++ b/tools/binman/bsection.py
@@ -59,7 +59,7 @@ class Section(object):
 self._pad_after = 0
 self._pad_byte = 0
 self._sort = False
-self._skip_at_start = 0
+self._skip_at_start = None
 self._end_4gb = False
 self._name_prefix = ''
 self._entries = OrderedDict()
@@ -79,10 +79,17 @@ class Section(object):
 self._pad_byte = fdt_util.GetInt(self._node, 'pad-byte', 0)
 self._sort = fdt_util.GetBool(self._node, 'sort-by-offset')
 self._end_4gb = fdt_util.GetBool(self._node, 'end-at-4gb')
-if self._end_4gb and not self._size:
-self._Raise("Section size must be provided when using end-at-4gb")
+self._skip_at_start = fdt_util.GetInt(self._node, 'skip-at-start')
 if self._end_4gb:
-self._skip_at_start = 0x1 - self._size
+if not self._size:
+self._Raise("Section size must be provided when using 
end-at-4gb")
+if self._skip_at_start is not None:
+self._Raise("Provide either 'end-at-4gb' or 'skip-at-start'")
+else:
+self._skip_at_start = 0x1 - self._size
+else:
+if self._skip_at_start is None:
+self._skip_at_start = 0
 self._name_prefix = fdt_util.GetString(self._node, 'name-prefix')
 
 def _ReadEntries(self):
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index a8456c2..36519a2 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -711,6 +711,14 @@ class TestFunctional(unittest.TestCase):
 self.assertIn("Section '/binman': Section size must be provided when "
   "using end-at-4gb", str(e.exception))
 
+def test4gbAndSkipAtStartTogether(self):
+"""Test that the end-at-4gb and skip-at-size property can't be used
+together"""
+with self.assertRaises(ValueError) as e:
+self._DoTestFile('80_4gb_and_skip_at_start_together.dts')
+self.assertIn("Section '/binman': Provide either 'end-at-4gb' or "
+  "'skip-at-start'", str(e.exception))
+
 def testPackX86RomOutside(self):
 """Test that the end-at-4gb property checks for offset boundaries"""
 with self.assertRaises(ValueError) as e:
diff --git a/tools/binman/test/80_4gb_and_skip_at_start_together.dts 
b/tools/binman/test/80_4gb_and_skip_at_start_together.dts
new file mode 100644
index 000..90c467d
--- /dev/null
+++ b/tools/binman/test/80_4gb_and_skip_at_start_together.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018 NXP
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+ 

[U-Boot] [PATCH v3 1/8] powerpc/dts: Define '_end' symbol in mpc85xx U-Boot lds files

[Jagdish Gediya]

'board_fdt_blob_setup' function sets up fdt blob at '&_end' so
define '_end' symbol in mpc85xx lds files.

Signed-off-by: Jagdish Gediya 
---
Changes for v2:
- Define '_end' symbol in lds file instead of defining new
  'board_fdt_blob_setup' function using existing '_init_end' symbol.

Changes for v3:
- Define '_end' symbol in spl lds files too.

 arch/powerpc/cpu/mpc85xx/u-boot-nand.lds | 1 +
 arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds | 1 +
 arch/powerpc/cpu/mpc85xx/u-boot-spl.lds  | 1 +
 arch/powerpc/cpu/mpc85xx/u-boot.lds  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
index 6db6da1..75b0285 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
@@ -74,6 +74,7 @@ SECTIONS
   .data.init : { *(.data.init) }
   . = ALIGN(256);
   __init_end = .;
+  _end = .;
 
   .bootpg ADDR(.text) - 0x1000 :
   {
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds
index 8588d7c..a2193bf 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds
@@ -42,6 +42,7 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+   _end = .;
 #if defined(CONFIG_FSL_IFC) /* Restrict bootpg at 4K boundry for IFC */
.bootpg ADDR(.text) + 0x1000 :
{
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 0495182..6dc8d99 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -55,6 +55,7 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+   _end = .;
 #ifdef CONFIG_SPL_SKIP_RELOCATE
. = ALIGN(4);
__bss_start = .;
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot.lds 
b/arch/powerpc/cpu/mpc85xx/u-boot.lds
index 14c31be..22bbac5 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot.lds
@@ -81,6 +81,7 @@ SECTIONS
   .data.init : { *(.data.init) }
   . = ALIGN(256);
   __init_end = .;
+  _end = .;
 
 #ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
   .bootpg ADDR(.text) - 0x1000 :
-- 
2.7.4

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

[U-Boot] [PATCH v3 4/8] binman: Add support for PowerPC mpc85xx 'bootpg + resetvec' entry

[Jagdish Gediya]

This entry contains the PowerPC mpc85xx boot page and resetvec
sections.

Signed-off-by: Jagdish Gediya 
---
Changes for v2:
- Updated README for new binman entry
- Added test

Changes for v3:
- Changed text from 'Powerpc' to 'PowerPC'

 tools/binman/README.entries| 14 +++-
 .../etype/powerpc_mpc85xx_bootpg_resetvec.py   | 25 ++
 tools/binman/ftest.py  |  8 +++
 .../test/81_powerpc_mpc85xx_bootpg_resetvec.dts| 16 ++
 4 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
 create mode 100644 tools/binman/test/81_powerpc_mpc85xx_bootpg_resetvec.dts

diff --git a/tools/binman/README.entries b/tools/binman/README.entries
index c6e7b22..6c78fb3 100644
--- a/tools/binman/README.entries
+++ b/tools/binman/README.entries
@@ -221,6 +221,18 @@ See README.x86 for information about Intel binary blobs.
 
 
 
+Entry: powerpc-mpc85xx-bootpg-resetvec: PowerPC mpc85xx bootpg + resetvec code 
for U-Boot
+-
+
+Properties / Entry arguments:
+- filename: Filename of u-boot-br.bin (default 'u-boot-br.bin')
+
+This enrty is valid for PowerPC mpc85xx cpus. This entry holds
+'bootpg + resetvec' code for PowerPC mpc85xx CPUs which needs to be
+placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
+
+
+
 Entry: section: Entry that contains other entries
 -
 
@@ -543,7 +555,7 @@ Properties / Entry arguments:
 - kernelkey: Name of the kernel key to use (inside keydir)
 - preamble-flags: Value of the vboot preamble flags (typically 0)
 
-Chromium OS  signs the read-write firmware and kernel, writing the signature
+Chromium OS signs the read-write firmware and kernel, writing the signature
 in this block. This allows U-Boot to verify that the next firmware stage
 and kernel are genuine.
 
diff --git a/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py 
b/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
new file mode 100644
index 000..59fedd2
--- /dev/null
+++ b/tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
@@ -0,0 +1,25 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2018 NXP
+#
+# Entry-type module for the PowerPC mpc85xx bootpg and resetvec code for U-Boot
+#
+
+from entry import Entry
+from blob import Entry_blob
+
+class Entry_powerpc_mpc85xx_bootpg_resetvec(Entry_blob):
+"""PowerPC mpc85xx bootpg + resetvec code for U-Boot
+
+Properties / Entry arguments:
+- filename: Filename of u-boot-br.bin (default 'u-boot-br.bin')
+
+This enrty is valid for PowerPC mpc85xx cpus. This entry holds
+'bootpg + resetvec' code for PowerPC mpc85xx CPUs which needs to be
+placed at offset 'RESET_VECTOR_ADDRESS - 0xffc'.
+"""
+
+def __init__(self, section, etype, node):
+Entry_blob.__init__(self, section, etype, node)
+
+def GetDefaultFilename(self):
+return 'u-boot-br.bin'
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 36519a2..924701a 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -39,6 +39,7 @@ U_BOOT_SPL_DTB_DATA   = 'spldtb'
 U_BOOT_TPL_DTB_DATA   = 'tpldtb'
 X86_START16_DATA  = 'start16'
 X86_START16_SPL_DATA  = 'start16spl'
+PPC_MPC85XX_BR_DATA   = 'ppcmpc85xxbr'
 U_BOOT_NODTB_DATA = 'nodtb with microcode pointer somewhere in here'
 U_BOOT_SPL_NODTB_DATA = 'splnodtb with microcode pointer somewhere in here'
 FSP_DATA  = 'fsp'
@@ -90,6 +91,7 @@ class TestFunctional(unittest.TestCase):
 TestFunctional._MakeInputFile('vga.bin', VGA_DATA)
 self._ResetDtbs()
 TestFunctional._MakeInputFile('u-boot-x86-16bit.bin', X86_START16_DATA)
+TestFunctional._MakeInputFile('u-boot-br.bin', PPC_MPC85XX_BR_DATA)
 TestFunctional._MakeInputFile('spl/u-boot-x86-16bit-spl.bin',
   X86_START16_SPL_DATA)
 TestFunctional._MakeInputFile('u-boot-nodtb.bin', U_BOOT_NODTB_DATA)
@@ -764,6 +766,12 @@ class TestFunctional(unittest.TestCase):
 data = self._DoReadFile('33_x86-start16.dts')
 self.assertEqual(X86_START16_DATA, data[:len(X86_START16_DATA)])
 
+def testPackPowerpcMpc85xxBootpgResetvec(self):
+"""Test that an image with powerpc-mpc85xx-bootpg-resetvec can be
+created"""
+data = self._DoReadFile('81_powerpc_mpc85xx_bootpg_resetvec.dts')
+self.assertEqual(PPC_MPC85XX_BR_DATA, data[:len(PPC_MPC85XX_BR_DATA)])
+
 def _RunMicrocodeTest(self, dts_fname, nodtb_data, ucode_second=False):
 """Handle running a test for insertion of microcode
 
diff --git a/tools/binman/test/81_powerpc_mpc85xx_bootpg_resetvec.dts 
b/tools/binman/test/81_powerpc_mpc85xx_bootpg_resetvec.dts
new file mode 100644
index 000..8f4b16c
--- /dev/null
+++ b/tools/binman/test/81_powerpc_mpc

[U-Boot] [PATCH v3 0/8] Device tree support for PowerPC in U-Boot

[Jagdish Gediya]

In current implementation, PowerPC does not support device tree in U-Boot.
This patch enables device tree support for PowerPC platform .

T2080AQDS board used as first platform.

Dtb is embedded in the U-Boot following below steps using binmam tool.

1. Remove bootpg and resetvec section if required
2. Append dtb using binman
3. Append bootpg and resetvec section back if removed in 1st step.

To enable binman tool, 'binman' node  has been added in the device tree.

Jagdish Gediya (8):
  powerpc/dts: Define '_end' symbol in mpc85xx U-Boot lds files
  powerpc/dts: Makefile changes to clean and build dts
  binman: Add a new "skip-at-start" property in Section class
  binman: Add support for PowerPC mpc85xx 'bootpg + resetvec' entry
  powerpc: mpc85xx: Select BINMAN by default
  powerpc: mpc85xx: Use binman to embed dtb inside U-Boot
  powerpc: dts: Add u-boot.dtsi to use binman for MPC85xx boards
  powerpc: dts: Enable device tree support for T2080QDS

 Makefile   | 23 +++-
 arch/powerpc/Kconfig   |  1 +
 arch/powerpc/cpu/mpc85xx/Kconfig   |  4 ++
 arch/powerpc/cpu/mpc85xx/u-boot-nand.lds   |  1 +
 arch/powerpc/cpu/mpc85xx/u-boot-nand_spl.lds   |  1 +
 arch/powerpc/cpu/mpc85xx/u-boot-spl.lds|  1 +
 arch/powerpc/cpu/mpc85xx/u-boot.lds|  1 +
 arch/powerpc/dts/Makefile  | 14 +
 arch/powerpc/dts/e6500_power_isa.dtsi  | 39 ++
 arch/powerpc/dts/t2080.dtsi| 62 ++
 arch/powerpc/dts/t2080qds.dts  | 17 ++
 arch/powerpc/dts/u-boot.dtsi   | 32 +++
 board/freescale/t208xqds/README| 19 +++
 configs/T2080QDS_NAND_defconfig|  3 +-
 configs/T2080QDS_SDCARD_defconfig  |  3 +-
 configs/T2080QDS_SPIFLASH_defconfig|  3 +-
 configs/T2080QDS_defconfig |  4 +-
 dts/Makefile   |  2 +-
 tools/binman/README|  9 
 tools/binman/README.entries| 14 -
 tools/binman/bsection.py   | 15 --
 .../etype/powerpc_mpc85xx_bootpg_resetvec.py   | 25 +
 tools/binman/ftest.py  | 16 ++
 .../test/80_4gb_and_skip_at_start_together.dts | 21 
 .../test/81_powerpc_mpc85xx_bootpg_resetvec.dts| 16 ++
 25 files changed, 335 insertions(+), 11 deletions(-)
 create mode 100644 arch/powerpc/dts/Makefile
 create mode 100644 arch/powerpc/dts/e6500_power_isa.dtsi
 create mode 100644 arch/powerpc/dts/t2080.dtsi
 create mode 100644 arch/powerpc/dts/t2080qds.dts
 create mode 100644 arch/powerpc/dts/u-boot.dtsi
 create mode 100644 tools/binman/etype/powerpc_mpc85xx_bootpg_resetvec.py
 create mode 100644 tools/binman/test/80_4gb_and_skip_at_start_together.dts
 create mode 100644 tools/binman/test/81_powerpc_mpc85xx_bootpg_resetvec.dts

-- 
2.7.4

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

Re: [U-Boot] U-Boot 2018.07 Still Broken for Allwinner H3 SoCs

[Chen-Yu Tsai]

Hi,

On Wed, Aug 1, 2018 at 9:22 PM Peter Robinson  wrote:
>
> On Tue, Jul 10, 2018 at 4:04 AM, Chen-Yu Tsai  wrote:
> > This is on a Libre Computer ALL-H3-CC H3 variant. Still running a
> > bisect, but v2018.07-rc1 is a working version. From the EHCI error
> > messages, I'm thinking it might be related to the USB changes lately.
> > Not sure if any other SoCs (ex. A64) are broken or not at the moment.
>
> I'm still seeing this issue in 2018.09 RC1, what's the status of a fix for 
> this?

This is a bug in binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=23571
It has been fixed upstream.

> > See log:
> >
> > U-Boot SPL 2018.07 (Jul 10 2018 - 10:21:03 +0800)
> > DRAM: 1024 MiB
> > Trying to boot from MMC1
> >
> >
> > U-Boot 2018.07 (Jul 10 2018 - 10:21:03 +0800) Allwinner Technology
> >
> > CPU:   Allwinner H3 (SUN8I 1680)
> > Model: Libre Computer Board ALL-H3-CC H3
> > DRAM:  1 GiB
> > MMC:   SUNXI SD/MMC: 0
> > Loading Environment from FAT... Unable to use mmc 0:1... Failed (-5)
> > In:serial
> > Out:   serial
> > Err:   serial
> > Net:   phy interface0
> > eth0: ethernet@1c3
> > starting USB...
> > USB0:   USB EHCI 1.00
> > USB1:   USB OHCI 1.0
> > USB2:   USB EHCI 1.00
> > USB3:   USB OHCI 1.0
> > USB4:   USB EHCI 1.00
> > USB5:   USB OHCI 1.0
> > scanning bus 0 for devices... 1 USB Device(s) found
> > scanning bus 2 for devices... 1 USB Device(s) found
> > scanning bus 4 for devices... 1 USB Device(s) found
> >scanning usb for storage devices... 0 Storage Device(s) found
> > Hit any key to stop autoboot:  0
> > switch to partitions #0, OK
> > mmc0 is current device
> > Scanning mmc 0:1...
> > Found U-Boot script /boot/boot.scr
> > 385 bytes read in 8 ms (46.9 KiB/s)
> > ## Executing script at 4310
> > 6343768 bytes read in 295 ms (20.5 MiB/s)
> > 18710 bytes read in 10 ms (1.8 MiB/s)
> > ## Flattened Device Tree blob at 4300
> >Booting using the fdt blob at 0x4300
> > EHCI failed to shut down host controller.
> > EHCI failed to shut down host controller.
> > EHCI failed to shut down host controller.
> >Loading Device Tree to 49ff8000, end 49fff915 ... OK
> >
> > Starting kernel ...
> >
> > data abort
> > pc : [<7dfadc6c>]  lr : [<7df82ed7>]
> > reloc pc : [<4a02bc6c>]lr : [<4a000ed7>]
> > sp : 79f5ce90  ip : 79f62b8a fp : 0003
> > r10: 7dfc3d14  r9 : 79f61ed8 r8 : 0400
> > r7 :   r6 : 4200 r5 : 49ff8000  r4 : 
> > r3 : 49ff8000  r2 : 49ff8000 r1 :   r0 : 
> > Flags: nZCv  IRQs off  FIQs off  Mode UK6_32
> > Code: e12fff1e e52de008 fa01 e3a0 (e49df008)
> > Resetting CPU ...
> >
> > resetting ...
> > ___
> > 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] [U-Boot, 1/8] rockchip: add STIMER_BASE for Rockchip SoCs

[Kever Yang]

Hi Philipp,


On 08/30/2018 05:11 PM, Philipp Tomsich wrote:
>
>
> On Wed, 18 Apr 2018, Kever Yang wrote:
>
>> Most of Rockchip SoCs have ARM arch/generic timer whose clock source
>> is from one of secure timer(if the soc supports Trust environment).
>>
>> STIMER can only access in secure mode, so it should be init before
>> the proper U-Boot(usually in non-secure mode).
>> Add a MACRO for timer base addr so that we can init with a common
>> function in SPL/TPL.
>>
>> Signed-off-by: Kever Yang 
>
> See below for required changes.
>
>> ---
>>
>> arch/arm/mach-rockchip/Kconfig | 16 
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/mach-rockchip/Kconfig
>> b/arch/arm/mach-rockchip/Kconfig
>> index 0adaed4..55d3d5c 100644
>> --- a/arch/arm/mach-rockchip/Kconfig
>> +++ b/arch/arm/mach-rockchip/Kconfig
>> @@ -191,6 +191,22 @@ config ROCKCHIP_BOOT_MODE_REG
>>   The Soc will enter to different boot mode(defined in
>> asm/arch/boot_mode.h)
>>   according to the value from this register.
>>
>> +config ROCKCHIP_STIMER_BASE
>> +    hex "Rockchip Secure timer base address"
>> +    default 0x200440a0 if ROCKCHIP_RK3036
>> +    default 0x20018020 if ROCKCHIP_RK3126
>> +    default 0x200440a0 if ROCKCHIP_RK3128
>> +    default 0x110d0020 if ROCKCHIP_RK322X
>> +    default 0xff810020 if ROCKCHIP_RK3288
>> +    default 0xff1d0020 if ROCKCHIP_RK3328
>> +    default 0xff830020 if ROCKCHIP_RK3368
>> +    default 0xff8680a0 if ROCKCHIP_RK3399
>> +    default 0x10350020 if ROCKCHIP_RV1108
>> +    default 0
>> +    help
>> +  The secure timer inited in SPL/TPL in secure word, ARM generic
>> timer
>> +  works after this timer work.
>
> NAK.
> This is not a user-configurable/selectable option, but rather a
> function of the chip used.
> This belongs into a header file in arch/arm/include/asm/arch-rockchip.

Yes, you are correct in one way, but I think if this goes to header
file, it will separate in different
header file for different SoCs, or with a lot if MACRO like "#if
defined(CONFIG_ROCKCHIP_RK3288) #elif"
in one header file.

Make ROCKCHIP_STIMER_BASE in Kconfig and use like ROCKCHIP_BOOT_MODE_REG
seems like a better idea to make things simple.

Actually there are many other configs like this:
- DEBUG_UART_BASE
- IRAM_START
- DRAM_START

One more consideration is, I don't think make SoC configs into too much
place is a good idea,
now we have 3 places for configs:
- Kconfig default value
- configs/soc_defconfig
- include/configs/soc_header.h (this is moving to Kconfig one by one now)

so I would not like to move it into arch/arm/include/asm/arch-rockchip,
if you insist this should go to header file instead of Kconfig, I would
prefer
to use header file in 'include/configs/' folder, how do you think?

Thanks,
- Kever
>
>> +
>> config ROCKCHIP_SPL_RESERVE_IRAM
>> hex "Size of IRAM reserved in SPL"
>> default 0
>>
>


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

[U-Boot] [PATCH 1/1] lib/slre: remove superfluous assignment

[Heinrich Schuchardt]

It makes no sense to assign a value to 'res' if the next use of the
variable is an assignment.

Signed-off-by: Heinrich Schuchardt 
---
 lib/slre.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/lib/slre.c b/lib/slre.c
index e26d344865..969c46a859 100644
--- a/lib/slre.c
+++ b/lib/slre.c
@@ -703,8 +703,6 @@ int main(int argc, char *argv[])
 
(void) memset(caps, 0, sizeof(caps));
 
-   res = 0;
-
res = slre_match(&slre, data, len, caps);
printf("Result [%d]: %d\n", i, res);
 
-- 
2.16.2

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

[U-Boot] [PATCH 1/1] efi_loader: use correct documentation style

[Heinrich Schuchardt]

We have moved generating html documentation with Sphinx.

%s/Return Value/Return/g

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_boottime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index ef4495ea46..cd5fdb7aa8 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3125,7 +3125,7 @@ struct efi_system_table __efi_runtime_data systab = {
 /**
  * efi_initialize_system_table() - Initialize system table
  *
- * Return Value:status code
+ * Return: status code
  */
 efi_status_t efi_initialize_system_table(void)
 {
-- 
2.18.0

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

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

[Marek Vasut]

On 09/03/2018 01:35 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 2 September 2018 at 12:24, Marek Vasut  wrote:
>> On 09/02/2018 03:07 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 1 September 2018 at 16:43, Marek Vasut  wrote:
 On 09/01/2018 11:45 PM, Simon Glass wrote:
> Hi Marek,
>
> On 30 August 2018 at 03:25, Marek Vasut  wrote:
>>
>> On 08/30/2018 02:29 AM, Simon Glass wrote:
>>> Hi Marek,
>>
>> Hi,
>>
>> [...]
>>
> If you have both EHCI and a xHCI controller which can occupy the same
> BFD, then how would you supply in the DT options needed by the
> controller itself? Don't you need two nodes in that case?

 For the PHY case, it's controller-type-independent.
>>>
>>> What do you mean? Your example of why you can't use compatible strings
>>> says you might have two different PHYs. But I think you should answer
>>> my questions:
>>>
> If you have both EHCI and a xHCI controller which can occupy the same
> BFD, then how would you supply in the DT options needed by the
> controller itself? Don't you need two nodes in that case?
>>
>> You need only one node (if the PHY works with both controller options),
>> which contains "reg" and "phy" properties. The driver matching is done
>> on the PCI ID/class and the node is associated with the driver based on
>> the "reg" property.
>
> I think you need two nodes if there are DT options that are different
> for each PHY. In fact I think this is impossible to do with the reg
> scheme.
>
> In effect the PHYs are different. They have different drivers,
> assuming drivers are needed. So I feel that using a common address to
> match two different devices is actually just weird.

 I think I lost you. But this discussion is really hypothetical. You
 _can_ have a USB PHY which can attach to both USB 2 and USB 3
 controller, in which case you would have only one DT node to describe it.
>>>
>>> Can you point to an example of this? Otherwise it seems hypothetical.
>>
>> Nope, it's just electrically viable.
> 
> OK, well I'm not sure that we can make any claims about any of this
> unless it is used somewhere.
> 
>>
>>> As a counter-example, see exynos54xx.dtsi.
>>
>> What exactly am I looking for ?
> 
> You can see a USB3 PHY which is attached to a USB3 host.
> 
>>
>>> I believe the correct way to do this is to enable/disable DT nodes. Do
>>> you have any pointers to suggest that the same node should be used for
>>> two devices?
>>
>> Nope
> 
> Then I believe that is incorrect, and it should be handled using two
> separate notes, with only one enabled at run-time.

I don't think you can claim it's either correct or incorrect if there is
no such hardware.

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

Re: [U-Boot] [PATCH v1] Makefile: Don't generate position independent code

[Simon Glass]

Hi,

On 10 August 2018 at 00:04, Bin Meng  wrote:
> On Thu, Aug 9, 2018 at 9:07 PM, Andy Shevchenko
>  wrote:
>> On Thu, 2018-08-09 at 14:25 +0200, Heinrich Schuchardt wrote:
>>
>>>  I did not test loading of
>>> Linux on x86.
>>
>> For the record I did test this.
>>
>
> Tested-by: Bin Meng 
> On QEMU x86 boards (except efi-x86_app_defconfig which is currently broken)
>
> applied to u-boot-x86, thanks!

This appears to break build sandbox on Ubuntu 18.04 at least (gcc-7.3).

Can we revert it, or do something else stop it from happening with sandbox?

At present all testing is broken for me.

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

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

[Simon Glass]

Hi Marek,

On 2 September 2018 at 12:24, Marek Vasut  wrote:
> On 09/02/2018 03:07 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 1 September 2018 at 16:43, Marek Vasut  wrote:
>>> On 09/01/2018 11:45 PM, Simon Glass wrote:
 Hi Marek,

 On 30 August 2018 at 03:25, Marek Vasut  wrote:
>
> On 08/30/2018 02:29 AM, Simon Glass wrote:
>> Hi Marek,
>
> Hi,
>
> [...]
>
 If you have both EHCI and a xHCI controller which can occupy the same
 BFD, then how would you supply in the DT options needed by the
 controller itself? Don't you need two nodes in that case?
>>>
>>> For the PHY case, it's controller-type-independent.
>>
>> What do you mean? Your example of why you can't use compatible strings
>> says you might have two different PHYs. But I think you should answer
>> my questions:
>>
 If you have both EHCI and a xHCI controller which can occupy the same
 BFD, then how would you supply in the DT options needed by the
 controller itself? Don't you need two nodes in that case?
>
> You need only one node (if the PHY works with both controller options),
> which contains "reg" and "phy" properties. The driver matching is done
> on the PCI ID/class and the node is associated with the driver based on
> the "reg" property.

 I think you need two nodes if there are DT options that are different
 for each PHY. In fact I think this is impossible to do with the reg
 scheme.

 In effect the PHYs are different. They have different drivers,
 assuming drivers are needed. So I feel that using a common address to
 match two different devices is actually just weird.
>>>
>>> I think I lost you. But this discussion is really hypothetical. You
>>> _can_ have a USB PHY which can attach to both USB 2 and USB 3
>>> controller, in which case you would have only one DT node to describe it.
>>
>> Can you point to an example of this? Otherwise it seems hypothetical.
>
> Nope, it's just electrically viable.

OK, well I'm not sure that we can make any claims about any of this
unless it is used somewhere.

>
>> As a counter-example, see exynos54xx.dtsi.
>
> What exactly am I looking for ?

You can see a USB3 PHY which is attached to a USB3 host.

>
>> I believe the correct way to do this is to enable/disable DT nodes. Do
>> you have any pointers to suggest that the same node should be used for
>> two devices?
>
> Nope

Then I believe that is incorrect, and it should be handled using two
separate notes, with only one enabled at run-time.

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

Re: [U-Boot] [PATCH V2 2/2] pci: Update documentation to make 'compatible' string optional

[Simon Glass]

Hi Marek,

On 2 September 2018 at 12:26, Marek Vasut  wrote:
> On 09/02/2018 03:07 AM, Simon Glass wrote:
>> Hi,
>>
>> On 1 September 2018 at 16:41, Marek Vasut  wrote:
>>> On 09/01/2018 11:45 PM, Simon Glass wrote:
 Hi Marek,

 On 30 August 2018 at 04:20, Marek Vasut  wrote:
> On 08/30/2018 02:29 AM, Simon Glass wrote:
>> Hi Marek,
>
> Hi,
>
>> On 24 August 2018 at 12:27, Marek Vasut  wrote:
>>> Reword the documentation to make it clear the compatible string is now
>>> optional, yet still matching on it takes precedence over PCI IDs and
>>> PCI classes.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Simon Glass 
>>> Cc: Tom Rini 
>>> ---
>>> V2: New patch
>>> ---
>>>  doc/driver-model/pci-info.txt | 14 +-
>>>  1 file changed, 9 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/doc/driver-model/pci-info.txt 
>>> b/doc/driver-model/pci-info.txt
>>> index e1701d1fbc..14364c5c75 100644
>>> --- a/doc/driver-model/pci-info.txt
>>> +++ b/doc/driver-model/pci-info.txt
>>> @@ -34,11 +34,15 @@ under that bus.
>>>  Note that this is all done on a lazy basis, as needed, so until 
>>> something is
>>>  touched on PCI (eg: a call to pci_find_devices()) it will not be 
>>> probed.
>>>
>>> -PCI devices can appear in the flattened device tree. If they do this 
>>> serves to
>>> -specify the driver to use for the device. In this case they will be 
>>> bound at
>>> -first. Each PCI device node must have a compatible string list as well 
>>> as a
>>> - property, as defined by the IEEE Std 1275-1994 PCI bus binding 
>>> document
>>> -v2.1. Note we must describe PCI devices with the same bus hierarchy as 
>>> the
>>> +PCI devices can appear in the flattened device tree. If they do, their 
>>> node
>>> +often contains extra information which cannot be derived from the PCI 
>>> IDs or
>>> +PCI class of the device. Each PCI device node must have a  
>>> property, as
>>> +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. 
>>> Compatible
>>> +string list is optional and generally not needed, since PCI is 
>>> discoverable
>>> +bus, albeit there are justified exceptions. If the compatible string is
>>> +present, matching on it takes precedence over PCI IDs and PCI classes.
>>> +
>>> +Note we must describe PCI devices with the same bus hierarchy as the
>>>  hardware, otherwise driver model cannot detect the correct 
>>> parent/children
>>>  relationship during PCI bus enumeration thus PCI devices won't be 
>>> bound to
>>>  their drivers accordingly. A working example like below:
>>> --
>>> 2.16.2
>>>
>>
>> Are we really saying that compatible strings are 'generally not needed'?
>
> Yes, PCI is a discoverable bus.
>
>> device tree pci supplement 2.1 talks about some new formats for the
>> compatible string, but doesn't say it is not needed. I much prefer a
>> compatible string since it is easy to find the driver in the source
>> code.
>
> But it duplicates (badly) what the PCI IDs and classes are used for
> since PCI's inception.
>
>> Can way say that a compatible string is preferred, but in extremis you
>> can avoid it by...
>
> No, see above, PCI is discoverable by design.

 I feel that these two things are orthogonal.

 You can probe the bus and find a device. That is the 'discoverable' part.

 But it is not automatically configurable. If it it were, there would
 be no DT node and no settings in the DT for the device. But from your
 patch, in some cases we need more information, and the DT node
 provides that.
>>>
>>> Pretty much, you can have stuff on the PCI card which needs extra info.
>>>
 So to get the settings to pass to the driver, you have to find the
 device-tree node to use for the device. The only way U-Boot supports
 is to use the 'reg' property, which specifies the PCI address. (We
 don't support a compatible string starting with "pci...". We could
 support that, but it is more code for essentially the same purpose.)
>>>
>>> Yes
>>>
 So we are not talking about the discoverability, which is already
 supported by U-Boot. We are talking about the configuration of the
 device, via settings passed to the driver.
>>>
>>> Yes
>>>
 In fact the only issue here is whether to require a compatible string
 for PCI nodes or allow matching solely based on the 'reg' property. Is
 the latter widely used in Linux? Presumably not on x86, which doesn't
 even use DT.
>>>
>>> I only see the compatible string used for bridges, the rest of the
>>> subdevices match on reg property.
>>
>> Where are you looking?
>
> Roughly 'git grep -A 10 pci arch/arm*/boot/dts' in Linux

I don't really understand why we need 'sta

[U-Boot] [PATCH 3/4] binman: Add support for Intel reference code

[Simon Glass]

Some platforms use this instead of FSP to set up the platform, including
memory. Add support for this in binman. This is needed for
chromebook_samus, for example.

Signed-off-by: Simon Glass 
---

 tools/binman/etype/intel_refcode.py | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 tools/binman/etype/intel_refcode.py

diff --git a/tools/binman/etype/intel_refcode.py 
b/tools/binman/etype/intel_refcode.py
new file mode 100644
index 000..045db589d17
--- /dev/null
+++ b/tools/binman/etype/intel_refcode.py
@@ -0,0 +1,27 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2016 Google, Inc
+# Written by Simon Glass 
+#
+# Entry-type module for Intel Memory Reference Code binary blob
+#
+
+from entry import Entry
+from blob import Entry_blob
+
+class Entry_intel_refcode(Entry_blob):
+"""Entry containing an Intel Reference Code file
+
+Properties / Entry arguments:
+- filename: Filename of file to read into entry
+
+This file contains code for setting up the platform on some Intel systems.
+This is executed by U-Boot when needed early during startup. A typical
+filename is 'refcode.bin'.
+
+See README.x86 for information about x86 binary blobs.
+"""
+def __init__(self, section, etype, node):
+Entry_blob.__init__(self, section, etype, node)
+
+def GetDefaultFilename(self):
+return 'refcode.bin'
-- 
2.19.0.rc1.350.ge57e33dbd1-goog

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

[U-Boot] [PATCH 4/4] Revert "x86: galileo: Fix boot failure"

[Simon Glass]

The root cause of this problem should now be fixed. Renable bootstage.

(Note, if this does not fix it, and instead a -ENOMEM error is produced,
then we probably need to increase CONFIG_SYS_MALLOC_F_LEN a bit).

This reverts commit 7995dd3782f90e1939969a4ead800a5e98e2d197.

Signed-off-by: Simon Glass 
---

 configs/galileo_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/galileo_defconfig b/configs/galileo_defconfig
index 63973028a71..9c58fa3a1af 100644
--- a/configs/galileo_defconfig
+++ b/configs/galileo_defconfig
@@ -8,6 +8,8 @@ CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
 CONFIG_NR_DRAM_BANKS=8
 CONFIG_FIT=y
+CONFIG_BOOTSTAGE=y
+CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="root=/dev/sdb3 init=/sbin/init rootwait ro"
 CONFIG_SYS_CONSOLE_INFO_QUIET=y
@@ -27,6 +29,7 @@ CONFIG_CMD_DHCP=y
 # CONFIG_CMD_NFS is not set
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
+CONFIG_CMD_BOOTSTAGE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_EXT4_WRITE=y
-- 
2.19.0.rc1.350.ge57e33dbd1-goog

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

[U-Boot] [PATCH 2/4] chromebook_samus: Increase pre-relocation memory

[Simon Glass]

With bootstage now allocating pre-relocation memory the current amount
available is insufficient. Increase it a little.

Signed-off-by: Simon Glass 
---

 configs/chromebook_samus_defconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/chromebook_samus_defconfig 
b/configs/chromebook_samus_defconfig
index e4c51f84d9f..cbfc6f05785 100644
--- a/configs/chromebook_samus_defconfig
+++ b/configs/chromebook_samus_defconfig
@@ -1,6 +1,6 @@
 CONFIG_X86=y
 CONFIG_SYS_TEXT_BASE=0xFFE0
-CONFIG_SYS_MALLOC_F_LEN=0x1800
+CONFIG_SYS_MALLOC_F_LEN=0x1a00
 CONFIG_DEBUG_UART_BOARD_INIT=y
 CONFIG_DEBUG_UART_BASE=0x3f8
 CONFIG_DEBUG_UART_CLOCK=1843200
-- 
2.19.0.rc1.350.ge57e33dbd1-goog

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

[U-Boot] [PATCH 1/4] Enable CONFIG_TIMER_EARLY with bootstage

[Simon Glass]

In initr_bootstage() we call bootstage_mark_name() which ends up calling
timer_get_us(). This call happens before initr_dm(), which inits driver
model.

On x86 we set gd->timer to NULL in the transition from board_init_f()
to board_init_r(). See board_init_f_r() for this assignment. So U-Boot
knows there is no timer available in the period immediately after
relocation.

On x86 the timer_get_us() call is implemented as calls to get_ticks() and
get_tbclk(). Both of these call dm_timer_init() to set up the timer, if
gd->timer is NULL and the early timer is not available.

However dm_timer_init() cannot succeed before initr_dm() is called.

So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable
CONFIG_TIMER_EARLY. Update the Kconfig to handle this.

Note: On most architectures we can rely on the pre-relocation memory still
being available, so that gd->timer pointers to a valid timer device and
everything works correctly. Admittedly this is not strictly correct since
the timer device is set up by pre-relocation U-Boot, but normally this is
fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot
disappears in board_init_f_r() and any attempt to access it will hang.
This is the reason why we must mark the timer as invalid when we get to
board_init_f_r().

Signed-off-by: Simon Glass 
---

 drivers/timer/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index 5ab6749193c..ff434de6f7c 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -30,6 +30,9 @@ config TPL_TIMER
 config TIMER_EARLY
bool "Allow timer to be used early in U-Boot"
depends on TIMER
+   # initr_bootstage() requires a timer and is called before initr_dm()
+   # so only the early timer is available
+   default y if X86 && BOOTSTAGE
help
  In some cases the timer must be accessible before driver model is
  active. Examples include when using CONFIG_TRACE to trace U-Boot's
-- 
2.19.0.rc1.350.ge57e33dbd1-goog

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

[U-Boot] [PATCH 0/4] x86: Fix up some bootstage problems

[Simon Glass]

There is a subtle problem with bootstage on x86. This series aims to fix
it so that it can be re-enabled on x86.


Simon Glass (4):
  Enable CONFIG_TIMER_EARLY with bootstage
  chromebook_samus: Increase pre-relocation memory
  binman: Add support for Intel reference code
  Revert "x86: galileo: Fix boot failure"

 configs/chromebook_samus_defconfig  |  2 +-
 configs/galileo_defconfig   |  3 +++
 drivers/timer/Kconfig   |  3 +++
 tools/binman/etype/intel_refcode.py | 27 +++
 4 files changed, 34 insertions(+), 1 deletion(-)
 create mode 100644 tools/binman/etype/intel_refcode.py

-- 
2.19.0.rc1.350.ge57e33dbd1-goog

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

Re: [U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

[Marek Vasut]

On 09/02/2018 08:41 PM, Jagan Teki wrote:
> On Sun, Sep 2, 2018 at 11:56 PM, Marek Vasut  wrote:
>> On 09/02/2018 08:00 PM, Jagan Teki wrote:
>>> On Sun, Aug 26, 2018 at 4:07 PM, Marek Vasut  wrote:
 On 08/26/2018 08:45 AM, Jagan Teki wrote:
> On Sat, Aug 25, 2018 at 11:04 PM, Marek Vasut  
> wrote:
>> Add DM support to the SH QSPI driver while retaining non-DM support.
>> The later is required as this driver is used in SPL which has a size
>> limitation of 16 kiB.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Nobuhiro Iwamatsu 
>> ---
>>  drivers/spi/sh_qspi.c | 215 
>> +++---
>>  1 file changed, 150 insertions(+), 65 deletions(-)
>>
>> diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
>> index e9123e2c39..64dfd748d6 100644
>> --- a/drivers/spi/sh_qspi.c
>> +++ b/drivers/spi/sh_qspi.c
>> @@ -67,15 +67,12 @@ struct sh_qspi_regs {
>>  };
>>
>>  struct sh_qspi_slave {
>> +#ifndef CONFIG_DM_SPI
>
> We are trying to drop non-dm code as much as possible (with
> MIGRATION.txt policy), how about adding PLTADATA or spi read glue code
> or any other?

 The SPL on that board (silk) has 16 kiB limit, right now I am at 15500 B
 with gcc 7.x already, adding any more overhead will make it overflow. So
 while I'd like to have it all fancy DM and stuff, it's not possible.
>>>
>>> How about having simple glue code for SPL, since it anyway used for
>>> read in real?
>>
>> I'd prefer to use the same driver for both SPL and U-Boot instead of
>> hacking stuff up. Not sure what exactly you mean by "glue" though.
> 
> Something that bypass spi stack and read the flash with local code,
> this usually suited for low SRAM size like silk example
> spl_spi_sunxi.c

But I am not _that_ cripplingly low, so I'd prefer to stick to a
standard solution instead of some hack.

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

Re: [U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

[Jagan Teki]

On Sun, Sep 2, 2018 at 11:56 PM, Marek Vasut  wrote:
> On 09/02/2018 08:00 PM, Jagan Teki wrote:
>> On Sun, Aug 26, 2018 at 4:07 PM, Marek Vasut  wrote:
>>> On 08/26/2018 08:45 AM, Jagan Teki wrote:
 On Sat, Aug 25, 2018 at 11:04 PM, Marek Vasut  
 wrote:
> Add DM support to the SH QSPI driver while retaining non-DM support.
> The later is required as this driver is used in SPL which has a size
> limitation of 16 kiB.
>
> Signed-off-by: Marek Vasut 
> Cc: Nobuhiro Iwamatsu 
> ---
>  drivers/spi/sh_qspi.c | 215 
> +++---
>  1 file changed, 150 insertions(+), 65 deletions(-)
>
> diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
> index e9123e2c39..64dfd748d6 100644
> --- a/drivers/spi/sh_qspi.c
> +++ b/drivers/spi/sh_qspi.c
> @@ -67,15 +67,12 @@ struct sh_qspi_regs {
>  };
>
>  struct sh_qspi_slave {
> +#ifndef CONFIG_DM_SPI

 We are trying to drop non-dm code as much as possible (with
 MIGRATION.txt policy), how about adding PLTADATA or spi read glue code
 or any other?
>>>
>>> The SPL on that board (silk) has 16 kiB limit, right now I am at 15500 B
>>> with gcc 7.x already, adding any more overhead will make it overflow. So
>>> while I'd like to have it all fancy DM and stuff, it's not possible.
>>
>> How about having simple glue code for SPL, since it anyway used for
>> read in real?
>
> I'd prefer to use the same driver for both SPL and U-Boot instead of
> hacking stuff up. Not sure what exactly you mean by "glue" though.

Something that bypass spi stack and read the flash with local code,
this usually suited for low SRAM size like silk example
spl_spi_sunxi.c
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

[Marek Vasut]

On 09/02/2018 08:00 PM, Jagan Teki wrote:
> On Sun, Aug 26, 2018 at 4:07 PM, Marek Vasut  wrote:
>> On 08/26/2018 08:45 AM, Jagan Teki wrote:
>>> On Sat, Aug 25, 2018 at 11:04 PM, Marek Vasut  wrote:
 Add DM support to the SH QSPI driver while retaining non-DM support.
 The later is required as this driver is used in SPL which has a size
 limitation of 16 kiB.

 Signed-off-by: Marek Vasut 
 Cc: Nobuhiro Iwamatsu 
 ---
  drivers/spi/sh_qspi.c | 215 
 +++---
  1 file changed, 150 insertions(+), 65 deletions(-)

 diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
 index e9123e2c39..64dfd748d6 100644
 --- a/drivers/spi/sh_qspi.c
 +++ b/drivers/spi/sh_qspi.c
 @@ -67,15 +67,12 @@ struct sh_qspi_regs {
  };

  struct sh_qspi_slave {
 +#ifndef CONFIG_DM_SPI
>>>
>>> We are trying to drop non-dm code as much as possible (with
>>> MIGRATION.txt policy), how about adding PLTADATA or spi read glue code
>>> or any other?
>>
>> The SPL on that board (silk) has 16 kiB limit, right now I am at 15500 B
>> with gcc 7.x already, adding any more overhead will make it overflow. So
>> while I'd like to have it all fancy DM and stuff, it's not possible.
> 
> How about having simple glue code for SPL, since it anyway used for
> read in real?

I'd prefer to use the same driver for both SPL and U-Boot instead of
hacking stuff up. Not sure what exactly you mean by "glue" though.

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

Re: [U-Boot] [PATCH V2 2/2] pci: Update documentation to make 'compatible' string optional

[Marek Vasut]

On 09/02/2018 03:07 AM, Simon Glass wrote:
> Hi,
> 
> On 1 September 2018 at 16:41, Marek Vasut  wrote:
>> On 09/01/2018 11:45 PM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 30 August 2018 at 04:20, Marek Vasut  wrote:
 On 08/30/2018 02:29 AM, Simon Glass wrote:
> Hi Marek,

 Hi,

> On 24 August 2018 at 12:27, Marek Vasut  wrote:
>> Reword the documentation to make it clear the compatible string is now
>> optional, yet still matching on it takes precedence over PCI IDs and
>> PCI classes.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Simon Glass 
>> Cc: Tom Rini 
>> ---
>> V2: New patch
>> ---
>>  doc/driver-model/pci-info.txt | 14 +-
>>  1 file changed, 9 insertions(+), 5 deletions(-)
>>
>> diff --git a/doc/driver-model/pci-info.txt 
>> b/doc/driver-model/pci-info.txt
>> index e1701d1fbc..14364c5c75 100644
>> --- a/doc/driver-model/pci-info.txt
>> +++ b/doc/driver-model/pci-info.txt
>> @@ -34,11 +34,15 @@ under that bus.
>>  Note that this is all done on a lazy basis, as needed, so until 
>> something is
>>  touched on PCI (eg: a call to pci_find_devices()) it will not be probed.
>>
>> -PCI devices can appear in the flattened device tree. If they do this 
>> serves to
>> -specify the driver to use for the device. In this case they will be 
>> bound at
>> -first. Each PCI device node must have a compatible string list as well 
>> as a
>> - property, as defined by the IEEE Std 1275-1994 PCI bus binding 
>> document
>> -v2.1. Note we must describe PCI devices with the same bus hierarchy as 
>> the
>> +PCI devices can appear in the flattened device tree. If they do, their 
>> node
>> +often contains extra information which cannot be derived from the PCI 
>> IDs or
>> +PCI class of the device. Each PCI device node must have a  
>> property, as
>> +defined by the IEEE Std 1275-1994 PCI bus binding document v2.1. 
>> Compatible
>> +string list is optional and generally not needed, since PCI is 
>> discoverable
>> +bus, albeit there are justified exceptions. If the compatible string is
>> +present, matching on it takes precedence over PCI IDs and PCI classes.
>> +
>> +Note we must describe PCI devices with the same bus hierarchy as the
>>  hardware, otherwise driver model cannot detect the correct 
>> parent/children
>>  relationship during PCI bus enumeration thus PCI devices won't be bound 
>> to
>>  their drivers accordingly. A working example like below:
>> --
>> 2.16.2
>>
>
> Are we really saying that compatible strings are 'generally not needed'?

 Yes, PCI is a discoverable bus.

> device tree pci supplement 2.1 talks about some new formats for the
> compatible string, but doesn't say it is not needed. I much prefer a
> compatible string since it is easy to find the driver in the source
> code.

 But it duplicates (badly) what the PCI IDs and classes are used for
 since PCI's inception.

> Can way say that a compatible string is preferred, but in extremis you
> can avoid it by...

 No, see above, PCI is discoverable by design.
>>>
>>> I feel that these two things are orthogonal.
>>>
>>> You can probe the bus and find a device. That is the 'discoverable' part.
>>>
>>> But it is not automatically configurable. If it it were, there would
>>> be no DT node and no settings in the DT for the device. But from your
>>> patch, in some cases we need more information, and the DT node
>>> provides that.
>>
>> Pretty much, you can have stuff on the PCI card which needs extra info.
>>
>>> So to get the settings to pass to the driver, you have to find the
>>> device-tree node to use for the device. The only way U-Boot supports
>>> is to use the 'reg' property, which specifies the PCI address. (We
>>> don't support a compatible string starting with "pci...". We could
>>> support that, but it is more code for essentially the same purpose.)
>>
>> Yes
>>
>>> So we are not talking about the discoverability, which is already
>>> supported by U-Boot. We are talking about the configuration of the
>>> device, via settings passed to the driver.
>>
>> Yes
>>
>>> In fact the only issue here is whether to require a compatible string
>>> for PCI nodes or allow matching solely based on the 'reg' property. Is
>>> the latter widely used in Linux? Presumably not on x86, which doesn't
>>> even use DT.
>>
>> I only see the compatible string used for bridges, the rest of the
>> subdevices match on reg property.
> 
> Where are you looking?

Roughly 'git grep -A 10 pci arch/arm*/boot/dts' in Linux

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

Re: [U-Boot] [PATCH] pci: Support parsing PCI controller DT subnodes

[Marek Vasut]

On 09/02/2018 03:07 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 1 September 2018 at 16:43, Marek Vasut  wrote:
>> On 09/01/2018 11:45 PM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 30 August 2018 at 03:25, Marek Vasut  wrote:

 On 08/30/2018 02:29 AM, Simon Glass wrote:
> Hi Marek,

 Hi,

 [...]

>>> If you have both EHCI and a xHCI controller which can occupy the same
>>> BFD, then how would you supply in the DT options needed by the
>>> controller itself? Don't you need two nodes in that case?
>>
>> For the PHY case, it's controller-type-independent.
>
> What do you mean? Your example of why you can't use compatible strings
> says you might have two different PHYs. But I think you should answer
> my questions:
>
>>> If you have both EHCI and a xHCI controller which can occupy the same
>>> BFD, then how would you supply in the DT options needed by the
>>> controller itself? Don't you need two nodes in that case?

 You need only one node (if the PHY works with both controller options),
 which contains "reg" and "phy" properties. The driver matching is done
 on the PCI ID/class and the node is associated with the driver based on
 the "reg" property.
>>>
>>> I think you need two nodes if there are DT options that are different
>>> for each PHY. In fact I think this is impossible to do with the reg
>>> scheme.
>>>
>>> In effect the PHYs are different. They have different drivers,
>>> assuming drivers are needed. So I feel that using a common address to
>>> match two different devices is actually just weird.
>>
>> I think I lost you. But this discussion is really hypothetical. You
>> _can_ have a USB PHY which can attach to both USB 2 and USB 3
>> controller, in which case you would have only one DT node to describe it.
> 
> Can you point to an example of this? Otherwise it seems hypothetical.

Nope, it's just electrically viable.

> As a counter-example, see exynos54xx.dtsi.

What exactly am I looking for ?

> I believe the correct way to do this is to enable/disable DT nodes. Do
> you have any pointers to suggest that the same node should be used for
> two devices?

Nope

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

Re: [U-Boot] [PATCH v6 00/31] SPI-NAND support

[Jagan Teki]

On Thu, Aug 30, 2018 at 6:13 PM, Miquel Raynal
 wrote:
> Hello,
>
> Miquel Raynal  wrote on Fri, 17 Aug 2018
> 10:38:46 +0200:
>
>> Hi Tom, Jagan,
>>
>> Boris Brezillon  wrote on Thu, 16 Aug 2018
>> 18:58:58 +0200:
>>
>> > Tom, Jagan,
>> >
>> > On Thu, 16 Aug 2018 17:29:58 +0200
>> > Miquel Raynal  wrote:
>> >
>> > > During the last months, Boris Brezillon shared his work to support
>> > > serial flashes within Linux. First, he delivered (and merged) a new
>> > > layer called spi-mem. He also initiated in Linux MTD subsystem the move
>> > > of all 'raw' NAND related code to a raw/ subdirectory, adding at the
>> > > same time a NAND core that would be shared with all NAND devices. Then,
>> > > he contributed a generic SPI-NAND driver, making use of this NAND core,
>> > > as well as some vendor code to drive a few chips.
>> > >
>> > > On top of this work, I made some cleanups in the MTD layer and added an
>> > > 'mtd' U-Boot command to handle all sort of MTD devices. This should
>> > > become the default command instead of having one per flash flavor
>> > > ('sf', 'nand', 'spi-nand' ?).
>> > >
>> > > The series has been tested on an Ocelot board PCB123 (VSC7514),
>> > > featuring a Macronix SPI NAND chip.
>> > >
>> > > TL;DR: the series contains:
>> > > - A few patches from Linux to resynchronize some areas of the MTD layer.
>> > > - Various fixes and re-organization of the MTD subsystem.
>> > > - The introduction of the SPI-mem interface.
>> > > - The addition of the generic SPI-NAND driver (and its bindings).
>> > > - Several SPI NAND chip drivers (Macronix, Micron, Winbond).
>> > > - A new 'mtd' command.
>> > > - Support for spi-nand devices in mtdparts.
>> > >
>> > > To test your SPI-NAND device with U-Boot simply follow these lines:
>> > >
>> > > > setenv mtdparts mtdparts=spi-nand0:1m(foo),-(bar)
>> > > > ubi part bar # create a static UBI volume in the bar partition
>> > > > mtd list # show the current MTD devices/partitions
>> > >
>> > > Thanks,
>> > > Miquèl
>> > >
>> >
>> > [...]
>> >
>> > Can we get some of those patches merged to avoid sending another
>> > version containing more than 30 patches. Here is a list of patches which
>> > IMO are ready to be merged:
>> >
>> >  - 1 to 4
>> >  - 5 and 6 if 6 is squashed in 5
>> >  - 7 to 23

Yes, I've picked these and build is under progress [1]

[1] https://travis-ci.org/openedev/u-boot-amarula/builds/423668176
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 02/13] pico-imx6ul: Convert to SPL

[Jagan Teki]

On Fri, Aug 31, 2018 at 12:40 AM, Otavio Salvador
 wrote:
> From: Fabio Estevam 
>
> There are two versions of imx6ul pico SOMs: one with 256MB and another
> one with 512MB of RAM.
>
> Convert to SPL so that both versions can be supported.
>
> Currently only the 256MB is tested/supported.
>
> Signed-off-by: Fabio Estevam 
> Signed-off-by: Fabio Berton 
> Signed-off-by: Otavio Salvador 
> ---
>
>  arch/arm/mach-imx/mx6/Kconfig |   1 +
>  board/technexion/pico-imx6ul/Makefile |   2 +-
>  board/technexion/pico-imx6ul/spl.c| 115 ++
>  configs/pico-imx6ul_defconfig |  14 +++-
>  include/configs/pico-imx6ul.h |   1 +
>  5 files changed, 131 insertions(+), 2 deletions(-)
>  create mode 100644 board/technexion/pico-imx6ul/spl.c
>
> diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
> index a2799c436e..06c25bae36 100644
> --- a/arch/arm/mach-imx/mx6/Kconfig
> +++ b/arch/arm/mach-imx/mx6/Kconfig
> @@ -402,6 +402,7 @@ config TARGET_OT1200
>  config TARGET_PICO_IMX6UL
> bool "PICO-IMX6UL-EMMC"
> select MX6UL
> +   select SUPPORT_SPL
>
>  config TARGET_LITEBOARD
> bool "Grinn liteBoard (i.MX6UL)"
> diff --git a/board/technexion/pico-imx6ul/Makefile 
> b/board/technexion/pico-imx6ul/Makefile
> index 8fdb7875ac..b7493df01c 100644
> --- a/board/technexion/pico-imx6ul/Makefile
> +++ b/board/technexion/pico-imx6ul/Makefile
> @@ -2,4 +2,4 @@
>  # (C) Copyright 2015 Technexion Ltd.
>  # (C) Copyright 2015 Freescale Semiconductor, Inc.
>
> -obj-y  := pico-imx6ul.o
> +obj-y  := pico-imx6ul.o spl.o
> diff --git a/board/technexion/pico-imx6ul/spl.c 
> b/board/technexion/pico-imx6ul/spl.c
> new file mode 100644
> index 00..6989c81946
> --- /dev/null
> +++ b/board/technexion/pico-imx6ul/spl.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+

space

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#if defined(CONFIG_SPL_BUILD)
> +#include 
> +
> +static struct mx6ul_iomux_grp_regs mx6_grp_ioregs = {
> +   .grp_addds = 0x0030,
> +   .grp_ddrmode_ctl = 0x0002,
> +   .grp_b0ds = 0x0030,
> +   .grp_ctlds = 0x0030,
> +   .grp_b1ds = 0x0030,
> +   .grp_ddrpke = 0x,
> +   .grp_ddrmode = 0x0002,
> +   .grp_ddr_type = 0x0008,
> +};
> +
> +static struct mx6ul_iomux_ddr_regs mx6_ddr_ioregs = {
> +   .dram_dqm0 = 0x0030,
> +   .dram_dqm1 = 0x0030,
> +   .dram_ras = 0x0030,
> +   .dram_cas = 0x0030,
> +   .dram_odt0 = 0x0030,
> +   .dram_odt1 = 0x0030,
> +   .dram_sdba2 = 0x,
> +   .dram_sdclk_0 = 0x0030,
> +   .dram_sdqs0 = 0x0030,
> +   .dram_sdqs1 = 0x0030,
> +   .dram_reset = 0x0030,
> +};
> +
> +static struct mx6_mmdc_calibration mx6_mmcd_calib = {
> +   .p0_mpwldectrl0 = 0x,
> +   .p0_mpdgctrl0 = 0x01380134,
> +   .p0_mprddlctl = 0x40404244,
> +   .p0_mpwrdlctl = 0x40405050,
> +};
> +
> +static struct mx6_ddr_sysinfo ddr_sysinfo = {
> +   .dsize  = 0,
> +   .cs1_mirror = 0,
> +   .cs_density = 32,
> +   .ncs= 1,
> +   .bi_on  = 1,
> +   .rtt_nom= 1,
> +   .rtt_wr = 0,
> +   .ralat  = 5,
> +   .walat  = 0,
> +   .mif3_mode  = 3,
> +   .rst_to_cke = 0x23,
> +   .sde_to_rst = 0x10,
> +   .refsel = 1,
> +   .refr = 3,
> +};
> +
> +static struct mx6_ddr3_cfg mem_ddr = {
> +   .mem_speed = 1333,
> +   .density = 2,
> +   .width = 16,
> +   .banks = 8,
> +   .rowaddr = 14,
> +   .coladdr = 10,
> +   .pagesz = 2,
> +   .trcd = 1350,
> +   .trcmin = 4950,
> +   .trasmin = 3600,
> +};
> +
> +static void ccgr_init(void)
> +{
> +   struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> +
> +   writel(0x, &ccm->CCGR0);
> +   writel(0x, &ccm->CCGR1);
> +   writel(0x, &ccm->CCGR2);
> +   writel(0x, &ccm->CCGR3);
> +   writel(0x, &ccm->CCGR4);
> +   writel(0x, &ccm->CCGR5);
> +   writel(0x, &ccm->CCGR6);
> +   writel(0x, &ccm->CCGR7);

These can be know values.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] mtd: spi: Add DM support to SH QSPI driver

[Jagan Teki]

On Sun, Aug 26, 2018 at 4:07 PM, Marek Vasut  wrote:
> On 08/26/2018 08:45 AM, Jagan Teki wrote:
>> On Sat, Aug 25, 2018 at 11:04 PM, Marek Vasut  wrote:
>>> Add DM support to the SH QSPI driver while retaining non-DM support.
>>> The later is required as this driver is used in SPL which has a size
>>> limitation of 16 kiB.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Nobuhiro Iwamatsu 
>>> ---
>>>  drivers/spi/sh_qspi.c | 215 
>>> +++---
>>>  1 file changed, 150 insertions(+), 65 deletions(-)
>>>
>>> diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
>>> index e9123e2c39..64dfd748d6 100644
>>> --- a/drivers/spi/sh_qspi.c
>>> +++ b/drivers/spi/sh_qspi.c
>>> @@ -67,15 +67,12 @@ struct sh_qspi_regs {
>>>  };
>>>
>>>  struct sh_qspi_slave {
>>> +#ifndef CONFIG_DM_SPI
>>
>> We are trying to drop non-dm code as much as possible (with
>> MIGRATION.txt policy), how about adding PLTADATA or spi read glue code
>> or any other?
>
> The SPL on that board (silk) has 16 kiB limit, right now I am at 15500 B
> with gcc 7.x already, adding any more overhead will make it overflow. So
> while I'd like to have it all fancy DM and stuff, it's not possible.

How about having simple glue code for SPL, since it anyway used for
read in real?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/9] dm: allow 4GB of DRAM on 32bit systems

[Alexander Graf]

> Am 02.09.2018 um 18:04 schrieb Vagrant Cascadian :
> 
>> On 2018-09-02, Alexander Graf  wrote:
>>> On 02.08.18 23:31, Dr. Philipp Tomsich wrote:
>>> 
 On 2 Aug 2018, at 22:36, Simon Glass  wrote:
 
 On 26 July 2018 at 07:59, Philipp Tomsich
 >>> > wrote:
> Even on 32bit systems a full 4GB of DRAM may be installed and reported
> by the DRAM controller.  Whether these 4GB are larger available
> depends on the size/configuration of address decoding windows and
> architectural features (e.g. consider a hypothetical architecture that
> uses dedicated instructions to access the 'memory-mapped' peripheral
> IO ranges).  In U-Boot, the available DRAM, as reported by the
> device-model is independent of the accessible DRAM (i.e. adjusted top
> and effective size).
> 
> This was first reported against the RK3288, which may have 4GB DRAM
> attached, but will have a small (e.g. 128MB) window not accessible due
> to address decoding limitations.
> 
> The solution is to increase the types used for storing the ram_size to
> have at least 33 bits even on 32bit systems... i.e. we need to use a
> u64 for these always (this was previously only the case for
> PHYS_64BIT, which will have unwanted side-effects for 32bit systems
> and would require more intrusive changes).
> 
> This commit changes the size-field in 'struct ram' and the ram_size in
> 'gd' to be a u64.
> 
> Reported-by: Marty E. Plummer 
> Signed-off-by: Philipp Tomsich 
> ---
> 
> include/asm-generic/global_data.h | 2 +-
> include/ram.h | 9 -
> 2 files changed, 9 insertions(+), 2 deletions(-)
> 
 
 Reviewed-by: Simon Glass mailto:s...@chromium.org>>
 
> diff --git a/include/asm-generic/global_data.h 
> b/include/asm-generic/global_data.h
> index 0fd4900..f3d687c 100644
> --- a/include/asm-generic/global_data.h
> +++ b/include/asm-generic/global_data.h
> @@ -55,7 +55,7 @@ typedef struct global_data {
>   unsigned long ram_base; /* Base address of RAM used by 
> U-Boot */
>   unsigned long ram_top;  /* Top address of RAM used by 
> U-Boot */
>   unsigned long relocaddr;/* Start address of U-Boot in RAM */
> -   phys_size_t ram_size;   /* RAM size */
> +   u64 ram_size;   /* RAM size */
>   unsigned long mon_len;  /* monitor len */
>   unsigned long irq_sp;   /* irq stack pointer */
>   unsigned long start_addr_sp;/* start_addr_stackpointer */
> diff --git a/include/ram.h b/include/ram.h
> index 67e22d7..1fe024f 100644
> --- a/include/ram.h
> +++ b/include/ram.h
> @@ -9,7 +9,14 @@
> 
> struct ram_info {
>   phys_addr_t base;
> -   size_t size;
> +   /*
> +* We use a 64bit type for the size to correctly handle 32bit
> +* systems with 4GB of DRAM (which would overflow a 32bit type
> +* and read back as 0).  For 64bit systems, we assume (for now)
 
 forever :-)
 
> +* that they will always have less than 2^65 byte of DRAM
> +* installed. -- prt
 
 Is the prt your signature? I suggest dropping it.
>>> 
>>> In fact it is. But I’ll need to rewrite the entire comment anyway for the 
>>> next
>>> version of this series as there’s even more functions and places that the
>>> memory size is stored in...
>>> 
 
> +*/
> +   u64 size;
>> 
>> With LPAE available in all modern ARM cores, shouldn't phys_addr_t just
>> be u64? And then we'd probably want to use that throughout the code, right?
> 
> Quite a few currently supported boards do not support LPAE, e.g. imx6.

What I'm trying to say is that we probably want to make phys_addr_t be u64 when 
CONFIG_LPAE is set.

Alex

> 
> 
> live well,
>  vagrant

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

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Stefano Babic]

On 02/09/2018 19:11, Tom Rini wrote:
> On Sun, Sep 02, 2018 at 07:06:06PM +0200, Stefano Babic wrote:
>>
>>
>> On 01/09/2018 13:37, Tom Rini wrote:
>>> On Fri, Aug 31, 2018 at 03:04:31PM +0200, Stefano Babic wrote:
>>>
 Hi Tom,

 please pull from u-boot-imx, thanks !

 The following changes since commit 
 11ed312896c5f5814064c5d45dcb2f53dc121437:

   configs: am57xx: change default board name to beagle_x15 (2018-08-26
 12:26:16 -0400)

 are available in the Git repository at:

   git://www.denx.de/git/u-boot-imx.git master

 for you to fetch changes up to 2846e663fd62200a189bba357135e284a379a38b:

   imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig (2018-08-31
 12:08:43 +0200)

>>>
>>> OK, NAK for the following problems:
>>> - Fail to build: https://travis-ci.org/trini/u-boot/jobs/423197300
>>>   The failing board is ids8313 and it's failing to configure as
>>>   CONFIG_SYS_BOOTCOUNT_I2C_BUS needs to be set, and isn't
>>
>> It looks wrong how I verify the whole build. Running buildman on my
>> host, all boards were built. I will
> 
> That's odd.  Are you building the world, or just arm? 

I am building i.MX, that could be the cause:

./tools/buildman/buildman imx mx25 mx27 mx31 mx35 mxs mx5 mx6 mx7 vf610


> I noticed this
> since my non-travis world build got stuck and then confirmed it just
> trying to build that single PowerPC board.

ok

> 
>>> - In looking into the above I see configs/ge_bx50v3_defconfig and
>>>   configs/mx53ppd_defconfig and a few more have a bunch of comments
>>>   added to it.  These will be blown away on the next re-sync.  Comments
>>>   need to go into the board README or something not an auto-generated
>>>   file.
>>
>> I saw this, but if the board maintainer won't use "make savedefonfig" to
>> generate its own defconfig, I have not blocked this if this lead to a
>> successful build.
> 
> It needs to be a rejection error, I try and remember to re-sync all of
> the defconfigs at least before the final release and if I'm doing it
> right, before the -rcs too.

ok

> 
>>> - So I start reading the whole diff and I see:
>>> commit 8e00d802e402d2a6734a88ebeb77a70efcfc354c
>>> Author: Sébastien Szymanski 
>>> Date:   Wed Jul 25 14:47:53 2018 +0200
>>>
>>> ARM: opos6ul: make the board boot again
>>>
>>> Which is wrong.  The -u-boot.dtsi file is automatically included and
>>> should have all of the U-Boot specific DTS changes.
>>
>> I have to understand why my build was successful...
> 
> It's not a fatal problem, it's just not doing things the right way.
> 
>>> - And since the above big real problems exist I'm going to point out for
>>>   you to fix:
>>> WARNING: no status info for 'mx7dsabresd_qspi'
>>> WARNING: no maintainers for 'mx7dsabresd_qspi'
>>>
>>
>> Note this, they will be fixed.
> 
> Fabio posted a patch for this one BTW.

Thanks, I pick it up.

Stefano


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

Re: [U-Boot] [PULL] Please pull u-boot-imx

[Tom Rini]

On Sun, Sep 02, 2018 at 07:06:06PM +0200, Stefano Babic wrote:
> 
> 
> On 01/09/2018 13:37, Tom Rini wrote:
> > On Fri, Aug 31, 2018 at 03:04:31PM +0200, Stefano Babic wrote:
> > 
> >> Hi Tom,
> >>
> >> please pull from u-boot-imx, thanks !
> >>
> >> The following changes since commit 
> >> 11ed312896c5f5814064c5d45dcb2f53dc121437:
> >>
> >>   configs: am57xx: change default board name to beagle_x15 (2018-08-26
> >> 12:26:16 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://www.denx.de/git/u-boot-imx.git master
> >>
> >> for you to fetch changes up to 2846e663fd62200a189bba357135e284a379a38b:
> >>
> >>   imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig (2018-08-31
> >> 12:08:43 +0200)
> >>
> > 
> > OK, NAK for the following problems:
> > - Fail to build: https://travis-ci.org/trini/u-boot/jobs/423197300
> >   The failing board is ids8313 and it's failing to configure as
> >   CONFIG_SYS_BOOTCOUNT_I2C_BUS needs to be set, and isn't
> 
> It looks wrong how I verify the whole build. Running buildman on my
> host, all boards were built. I will

That's odd.  Are you building the world, or just arm?  I noticed this
since my non-travis world build got stuck and then confirmed it just
trying to build that single PowerPC board.

> > - In looking into the above I see configs/ge_bx50v3_defconfig and
> >   configs/mx53ppd_defconfig and a few more have a bunch of comments
> >   added to it.  These will be blown away on the next re-sync.  Comments
> >   need to go into the board README or something not an auto-generated
> >   file.
> 
> I saw this, but if the board maintainer won't use "make savedefonfig" to
> generate its own defconfig, I have not blocked this if this lead to a
> successful build.

It needs to be a rejection error, I try and remember to re-sync all of
the defconfigs at least before the final release and if I'm doing it
right, before the -rcs too.

> > - So I start reading the whole diff and I see:
> > commit 8e00d802e402d2a6734a88ebeb77a70efcfc354c
> > Author: Sébastien Szymanski 
> > Date:   Wed Jul 25 14:47:53 2018 +0200
> > 
> > ARM: opos6ul: make the board boot again
> > 
> > Which is wrong.  The -u-boot.dtsi file is automatically included and
> > should have all of the U-Boot specific DTS changes.
> 
> I have to understand why my build was successful...

It's not a fatal problem, it's just not doing things the right way.

> > - And since the above big real problems exist I'm going to point out for
> >   you to fix:
> > WARNING: no status info for 'mx7dsabresd_qspi'
> > WARNING: no maintainers for 'mx7dsabresd_qspi'
> > 
> 
> Note this, they will be fixed.

Fabio posted a patch for this one BTW.

-- 
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] Please pull u-boot-imx

[Stefano Babic]

On 01/09/2018 13:37, Tom Rini wrote:
> On Fri, Aug 31, 2018 at 03:04:31PM +0200, Stefano Babic wrote:
> 
>> Hi Tom,
>>
>> please pull from u-boot-imx, thanks !
>>
>> The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
>>
>>   configs: am57xx: change default board name to beagle_x15 (2018-08-26
>> 12:26:16 -0400)
>>
>> are available in the Git repository at:
>>
>>   git://www.denx.de/git/u-boot-imx.git master
>>
>> for you to fetch changes up to 2846e663fd62200a189bba357135e284a379a38b:
>>
>>   imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig (2018-08-31
>> 12:08:43 +0200)
>>
> 
> OK, NAK for the following problems:
> - Fail to build: https://travis-ci.org/trini/u-boot/jobs/423197300
>   The failing board is ids8313 and it's failing to configure as
>   CONFIG_SYS_BOOTCOUNT_I2C_BUS needs to be set, and isn't

It looks wrong how I verify the whole build. Running buildman on my
host, all boards were built. I will

> - In looking into the above I see configs/ge_bx50v3_defconfig and
>   configs/mx53ppd_defconfig and a few more have a bunch of comments
>   added to it.  These will be blown away on the next re-sync.  Comments
>   need to go into the board README or something not an auto-generated
>   file.

I saw this, but if the board maintainer won't use "make savedefonfig" to
generate its own defconfig, I have not blocked this if this lead to a
successful build.

> - So I start reading the whole diff and I see:
> commit 8e00d802e402d2a6734a88ebeb77a70efcfc354c
> Author: Sébastien Szymanski 
> Date:   Wed Jul 25 14:47:53 2018 +0200
> 
> ARM: opos6ul: make the board boot again
> 
> Which is wrong.  The -u-boot.dtsi file is automatically included and
> should have all of the U-Boot specific DTS changes.

I have to understand why my build was successful...

> 
> - And since the above big real problems exist I'm going to point out for
>   you to fix:
> WARNING: no status info for 'mx7dsabresd_qspi'
> WARNING: no maintainers for 'mx7dsabresd_qspi'
> 

Note this, they will be fixed.

> Rather than fix it myself like I was going to before I found the other
> issues.
> 

Regards,
Stefano

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

Re: [U-Boot] [PATCH 1/9] dm: allow 4GB of DRAM on 32bit systems

[Vagrant Cascadian]

On 2018-09-02, Alexander Graf  wrote:
> On 02.08.18 23:31, Dr. Philipp Tomsich wrote:
>> 
>>> On 2 Aug 2018, at 22:36, Simon Glass  wrote:
>>>
>>> On 26 July 2018 at 07:59, Philipp Tomsich
>>> >> > wrote:
 Even on 32bit systems a full 4GB of DRAM may be installed and reported
 by the DRAM controller.  Whether these 4GB are larger available
 depends on the size/configuration of address decoding windows and
 architectural features (e.g. consider a hypothetical architecture that
 uses dedicated instructions to access the 'memory-mapped' peripheral
 IO ranges).  In U-Boot, the available DRAM, as reported by the
 device-model is independent of the accessible DRAM (i.e. adjusted top
 and effective size).

 This was first reported against the RK3288, which may have 4GB DRAM
 attached, but will have a small (e.g. 128MB) window not accessible due
 to address decoding limitations.

 The solution is to increase the types used for storing the ram_size to
 have at least 33 bits even on 32bit systems... i.e. we need to use a
 u64 for these always (this was previously only the case for
 PHYS_64BIT, which will have unwanted side-effects for 32bit systems
 and would require more intrusive changes).

 This commit changes the size-field in 'struct ram' and the ram_size in
 'gd' to be a u64.

 Reported-by: Marty E. Plummer 
 Signed-off-by: Philipp Tomsich 
 ---

 include/asm-generic/global_data.h | 2 +-
 include/ram.h | 9 -
 2 files changed, 9 insertions(+), 2 deletions(-)

>>>
>>> Reviewed-by: Simon Glass mailto:s...@chromium.org>>
>>>
 diff --git a/include/asm-generic/global_data.h 
 b/include/asm-generic/global_data.h
 index 0fd4900..f3d687c 100644
 --- a/include/asm-generic/global_data.h
 +++ b/include/asm-generic/global_data.h
 @@ -55,7 +55,7 @@ typedef struct global_data {
unsigned long ram_base; /* Base address of RAM used by 
 U-Boot */
unsigned long ram_top;  /* Top address of RAM used by 
 U-Boot */
unsigned long relocaddr;/* Start address of U-Boot in RAM */
 -   phys_size_t ram_size;   /* RAM size */
 +   u64 ram_size;   /* RAM size */
unsigned long mon_len;  /* monitor len */
unsigned long irq_sp;   /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */
 diff --git a/include/ram.h b/include/ram.h
 index 67e22d7..1fe024f 100644
 --- a/include/ram.h
 +++ b/include/ram.h
 @@ -9,7 +9,14 @@

 struct ram_info {
phys_addr_t base;
 -   size_t size;
 +   /*
 +* We use a 64bit type for the size to correctly handle 32bit
 +* systems with 4GB of DRAM (which would overflow a 32bit type
 +* and read back as 0).  For 64bit systems, we assume (for now)
>>>
>>> forever :-)
>>>
 +* that they will always have less than 2^65 byte of DRAM
 +* installed. -- prt
>>>
>>> Is the prt your signature? I suggest dropping it.
>> 
>> In fact it is. But I’ll need to rewrite the entire comment anyway for the 
>> next
>> version of this series as there’s even more functions and places that the
>> memory size is stored in...
>> 
>>>
 +*/
 +   u64 size;
>
> With LPAE available in all modern ARM cores, shouldn't phys_addr_t just
> be u64? And then we'd probably want to use that throughout the code, right?

Quite a few currently supported boards do not support LPAE, e.g. imx6.


live well,
  vagrant


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] Please pull u-boot-imx

[Tom Rini]

On Sun, Sep 02, 2018 at 03:20:25PM +0200, Sébastien Szymanski wrote:

> Hi Tom,
> 
> > On 1 Sep 2018, at 13:37, Tom Rini  wrote:
> > 
> > - So I start reading the whole diff and I see:
> > commit 8e00d802e402d2a6734a88ebeb77a70efcfc354c
> > Author: Sébastien Szymanski 
> > Date:   Wed Jul 25 14:47:53 2018 +0200
> > 
> >ARM: opos6ul: make the board boot again
> > 
> > Which is wrong.  The -u-boot.dtsi file is automatically included and
> > should have all of the U-Boot specific DTS changes.
> > 
> 
> :(
> 
> I don’t understand your comment. What -u-boot.dtsi file is
> automatically included ? I have put all the U-Boot specific DTS
> changes in imx6ul-opos6ul-u-boot.dtsi and imx6u-opos6uldev-u-boot.dts
> files.

Take a look at the u_boot_dtsi_options logic in scripts/Makefile.lib for
all of the possible dtsi files that will be automatically included if
found.  This is so that end the end for a given board you should be able
to drop in the dts file(s) from Linux, create a -u-boot.dtsi and then
have things work, no changes to the upstream files required nor
specifying an otherwise unusual name.

-- 
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] Please pull u-boot-imx

[Sébastien Szymanski]

Hi Tom,

> On 1 Sep 2018, at 13:37, Tom Rini  wrote:
> 
> - So I start reading the whole diff and I see:
> commit 8e00d802e402d2a6734a88ebeb77a70efcfc354c
> Author: Sébastien Szymanski 
> Date:   Wed Jul 25 14:47:53 2018 +0200
> 
>ARM: opos6ul: make the board boot again
> 
> Which is wrong.  The -u-boot.dtsi file is automatically included and
> should have all of the U-Boot specific DTS changes.
> 

:(

I don’t understand your comment. What -u-boot.dtsi file is automatically 
included ? I have put all the U-Boot specific DTS changes in 
imx6ul-opos6ul-u-boot.dtsi and imx6u-opos6uldev-u-boot.dts files.

Regards, 

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

--
Sébastien Szymanski
Software engineer, Armadeus Systems
Tel: +33 (0)9 72 29 41 44
Fax: +33 (0)9 72 28 79 26
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/9] dm: allow 4GB of DRAM on 32bit systems

[Alexander Graf]

On 02.08.18 23:31, Dr. Philipp Tomsich wrote:
> 
>> On 2 Aug 2018, at 22:36, Simon Glass  wrote:
>>
>> On 26 July 2018 at 07:59, Philipp Tomsich
>> > > wrote:
>>> Even on 32bit systems a full 4GB of DRAM may be installed and reported
>>> by the DRAM controller.  Whether these 4GB are larger available
>>> depends on the size/configuration of address decoding windows and
>>> architectural features (e.g. consider a hypothetical architecture that
>>> uses dedicated instructions to access the 'memory-mapped' peripheral
>>> IO ranges).  In U-Boot, the available DRAM, as reported by the
>>> device-model is independent of the accessible DRAM (i.e. adjusted top
>>> and effective size).
>>>
>>> This was first reported against the RK3288, which may have 4GB DRAM
>>> attached, but will have a small (e.g. 128MB) window not accessible due
>>> to address decoding limitations.
>>>
>>> The solution is to increase the types used for storing the ram_size to
>>> have at least 33 bits even on 32bit systems... i.e. we need to use a
>>> u64 for these always (this was previously only the case for
>>> PHYS_64BIT, which will have unwanted side-effects for 32bit systems
>>> and would require more intrusive changes).
>>>
>>> This commit changes the size-field in 'struct ram' and the ram_size in
>>> 'gd' to be a u64.
>>>
>>> Reported-by: Marty E. Plummer 
>>> Signed-off-by: Philipp Tomsich 
>>> ---
>>>
>>> include/asm-generic/global_data.h | 2 +-
>>> include/ram.h | 9 -
>>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>
>> Reviewed-by: Simon Glass mailto:s...@chromium.org>>
>>
>>> diff --git a/include/asm-generic/global_data.h 
>>> b/include/asm-generic/global_data.h
>>> index 0fd4900..f3d687c 100644
>>> --- a/include/asm-generic/global_data.h
>>> +++ b/include/asm-generic/global_data.h
>>> @@ -55,7 +55,7 @@ typedef struct global_data {
>>>unsigned long ram_base; /* Base address of RAM used by 
>>> U-Boot */
>>>unsigned long ram_top;  /* Top address of RAM used by U-Boot 
>>> */
>>>unsigned long relocaddr;/* Start address of U-Boot in RAM */
>>> -   phys_size_t ram_size;   /* RAM size */
>>> +   u64 ram_size;   /* RAM size */
>>>unsigned long mon_len;  /* monitor len */
>>>unsigned long irq_sp;   /* irq stack pointer */
>>>unsigned long start_addr_sp;/* start_addr_stackpointer */
>>> diff --git a/include/ram.h b/include/ram.h
>>> index 67e22d7..1fe024f 100644
>>> --- a/include/ram.h
>>> +++ b/include/ram.h
>>> @@ -9,7 +9,14 @@
>>>
>>> struct ram_info {
>>>phys_addr_t base;
>>> -   size_t size;
>>> +   /*
>>> +* We use a 64bit type for the size to correctly handle 32bit
>>> +* systems with 4GB of DRAM (which would overflow a 32bit type
>>> +* and read back as 0).  For 64bit systems, we assume (for now)
>>
>> forever :-)
>>
>>> +* that they will always have less than 2^65 byte of DRAM
>>> +* installed. -- prt
>>
>> Is the prt your signature? I suggest dropping it.
> 
> In fact it is. But I’ll need to rewrite the entire comment anyway for the next
> version of this series as there’s even more functions and places that the
> memory size is stored in...
> 
>>
>>> +*/
>>> +   u64 size;

With LPAE available in all modern ARM cores, shouldn't phys_addr_t just
be u64? And then we'd probably want to use that throughout the code, right?


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