Re: [U-Boot] [PATCH] spl: dm_mmc: Initialize only the required mmc device
> Subject: Re: [PATCH] spl: dm_mmc: Initialize only the required mmc device
>
> Hi Peng,
>
> On 10/09/19 7:50 AM, Peng Fan wrote:
> >> Subject: [PATCH] spl: dm_mmc: Initialize only the required mmc device
> >>
> >> In SPL, all the available mmc devices gets initialized during boot.
> >> This might not work in cases where clocks are not available for
> >> certain mmc devices(other than boot device) and the support for
> >> enabling device might not be ready.
> >>
> >> Texas Instruments' K3 J721E device having a central system controller
> >> (dmsc) is one such example falling in this category. Below is the
> >> sequence for the failing scenario:
> >> - ROM comes up in SD mode and loads SPL by just initialing SD card.
> >> - SPL loads dmsc firmware from SD Card.
> >> Since ROM has enabled SD, SPL need not enable the SD, just need to re
> >> initialize the card. But SPL is trying to initialize other MMC
> >> instances which are in disabled state. Since dmsc firmware is not yet
> >> available, devices cannot be enabled. So in SPL, initialize only the mmc
> device that is needed.
> >>
> >> Signed-off-by: Lokesh Vutla
>
> Gentle Ping. Are you planning to take this patch for this merge window?
Just back from holiday. Yes, I'll pick it up and prepare PR to Tom.
Thanks,
Peng.
>
> Thanks and regards,
> Lokesh
>
> >> ---
> >> common/spl/spl_mmc.c | 14 --
> >> drivers/mmc/mmc.c| 24
> >> include/mmc.h| 1 +
> >> 3 files changed, 29 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
> >> b3619889f7..303f0f80bf 100644
> >> --- a/common/spl/spl_mmc.c
> >> +++ b/common/spl/spl_mmc.c
> >> @@ -113,31 +113,25 @@ static int spl_mmc_get_device_index(u32
> >> boot_device)
> >>
> >> static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device) {
> >> -#if CONFIG_IS_ENABLED(DM_MMC)
> >> - struct udevice *dev;
> >> -#endif
> >>int err, mmc_dev;
> >>
> >>mmc_dev = spl_mmc_get_device_index(boot_device);
> >>if (mmc_dev < 0)
> >>return mmc_dev;
> >>
> >> +#if CONFIG_IS_ENABLED(DM_MMC)
> >> + err = mmc_init_device(mmc_dev);
> >> +#else
> >>err = mmc_initialize(NULL);
> >> +#endif /* DM_MMC */
> >>if (err) {
> >> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> >>printf("spl: could not initialize mmc. error: %d\n", err);
> >> #endif
> >>return err;
> >>}
> >> -
> >> -#if CONFIG_IS_ENABLED(DM_MMC)
> >> - err = uclass_get_device(UCLASS_MMC, mmc_dev, );
> >> - if (!err)
> >> - *mmcp = mmc_get_mmc_dev(dev);
> >> -#else
> >>*mmcp = find_mmc_device(mmc_dev);
> >>err = *mmcp ? 0 : -ENODEV;
> >> -#endif
> >>if (err) {
> >> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> >>printf("spl: could not find mmc device %d. error: %d\n", diff
> >> --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index
> >> eecc7d687e..ec8f92ce8f
> >> 100644
> >> --- a/drivers/mmc/mmc.c
> >> +++ b/drivers/mmc/mmc.c
> >> @@ -2998,6 +2998,30 @@ int mmc_initialize(bd_t *bis)
> >>return 0;
> >> }
> >>
> >> +#if CONFIG_IS_ENABLED(DM_MMC)
> >> +int mmc_init_device(int num)
> >> +{
> >> + struct udevice *dev;
> >> + struct mmc *m;
> >> + int ret;
> >> +
> >> + ret = uclass_get_device(UCLASS_MMC, num, );
> >> + if (ret)
> >> + return ret;
> >> +
> >> + m = mmc_get_mmc_dev(dev);
> >> + if (!m)
> >> + return 0;
> >> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
> >> + mmc_set_preinit(m, 1);
> >> +#endif
> >> + if (m->preinit)
> >> + mmc_start_init(m);
> >> +
> >> + return 0;
> >> +}
> >> +#endif
> >> +
> >> #ifdef CONFIG_CMD_BKOPS_ENABLE
> >> int mmc_set_bkops_enable(struct mmc *mmc) { diff --git
> >> a/include/mmc.h b/include/mmc.h index 46422f41a4..878b4c9e57
> 100644
> >> --- a/include/mmc.h
> >> +++ b/include/mmc.h
> >> @@ -698,6 +698,7 @@ void mmc_destroy(struct mmc *mmc);
> >> */
> >> int mmc_unbind(struct udevice *dev); int mmc_initialize(bd_t *bis);
> >> +int mmc_init_device(int num);
> >> int mmc_init(struct mmc *mmc);
> >> int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);
> >
> > Reviewed-by: Peng Fan
> >
> >>
> >> --
> >> 2.22.0
> >
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/3] lib: rsa: add rsa_verify_with_pkey()
This function, and hence rsa_verify(), will perform RSA verification
with two essential parameters for a RSA public key in contract of
rsa_verify_with_keynode(), which requires additional three parameters
stored in FIT image.
It will be used in implementing UEFI secure boot, i.e. image authentication
and variable authentication.
Signed-off-by: AKASHI Takahiro
---
lib/rsa/Kconfig | 7 -
lib/rsa/Makefile | 1 -
lib/rsa/rsa-verify.c | 63 ++--
3 files changed, 55 insertions(+), 16 deletions(-)
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index d1743d7a4c47..62b7ab9c5e5c 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -30,13 +30,6 @@ config RSA_VERIFY
help
Add RSA signature verification support.
-config RSA_VERIFY_WITH_PKEY
- bool "Execute RSA verification without key parameters from FDT"
- depends on RSA
- help
- This options enables RSA signature verification without
- using public key parameters which is embedded control FDT.
-
config RSA_SOFTWARE_EXP
bool "Enable driver for RSA Modular Exponentiation in software"
depends on DM
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index 14ed3cb4012b..c07305188e0c 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -6,5 +6,4 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
-obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
index 1df42f28c64a..ce79984b30f9 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -17,9 +17,14 @@
#include "mkimage.h"
#include
#endif
+#include
#include
#include
+#ifndef __UBOOT__ /* for host tools */
+#undef CONFIG_RSA_VERIFY_WITH_PKEY
+#endif
+
/* Default public exponent for backward compatibility */
#define RSA_DEFAULT_PUBEXP 65537
@@ -344,6 +349,34 @@ static int rsa_verify_key(struct image_sign_info *info,
}
#endif
+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
+/**
+ * rsa_verify_with_pkey()
+ *
+ */
+static int rsa_verify_with_pkey(struct image_sign_info *info,
+ const void *hash, uint8_t *sig, uint sig_len)
+{
+ struct key_prop *prop;
+ int ret;
+
+ /* Public key is self-described to fill key_prop */
+ prop = rsa_gen_key_prop(info->key, info->keylen);
+ if (!prop) {
+ debug("Generating necessary parameter for decoding failed\n");
+ return -EACCES;
+ }
+
+ ret = rsa_verify_key(info, prop, sig, sig_len, hash,
+info->crypto->key_len);
+
+ rsa_free_key_prop(prop);
+
+ return ret;
+}
+#endif
+
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
/**
* rsa_verify_with_keynode() - Verify a signature against some data using
* information in node with prperties of RSA Key like modulus, exponent etc.
@@ -397,18 +430,21 @@ static int rsa_verify_with_keynode(struct image_sign_info
*info,
return ret;
}
+#endif
int rsa_verify(struct image_sign_info *info,
const struct image_region region[], int region_count,
uint8_t *sig, uint sig_len)
{
- const void *blob = info->fdt_blob;
/* Reserve memory for maximum checksum-length */
uint8_t hash[info->crypto->key_len];
+ int ret = -EACCES;
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
+ const void *blob = info->fdt_blob;
int ndepth, noffset;
int sig_node, node;
char name[100];
- int ret;
+#endif
/*
* Verify that the checksum-length does not exceed the
@@ -421,12 +457,6 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
- sig_node = fdt_subnode_offset(blob, 0, FIT_SIG_NODENAME);
- if (sig_node < 0) {
- debug("%s: No signature node found\n", __func__);
- return -ENOENT;
- }
-
/* Calculate checksum with checksum-algorithm */
ret = info->checksum->calculate(info->checksum->name,
region, region_count, hash);
@@ -435,6 +465,22 @@ int rsa_verify(struct image_sign_info *info,
return -EINVAL;
}
+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
+ if (!info->fdt_blob) {
+ /* don't rely on fdt properties */
+ ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
+
+ return ret;
+ }
+#endif
+
+#if CONFIG_IS_ENABLED(FIT_SIGNATURE)
+ sig_node = fdt_subnode_offset(blob, 0, FIT_SIG_NODENAME);
+ if (sig_node < 0) {
+ debug("%s: No signature node found\n", __func__);
+ return -ENOENT;
+ }
+
/* See if we must use a particular key */
if (info->required_keynode != -1) {
ret = rsa_verify_with_keynode(info, hash, sig, sig_len,
@@ -461,6 +507,7 @@ int
[U-Boot] [PATCH v1 2/3] lib: rsa: generate additional parameters for public key
In the current implementation of FIT_SIGNATURE, five parameters for
a RSA public key are required while only two of them are essential.
(See rsa-mod-exp.h and uImage.FIT/signature.txt)
This is a result of considering relatively limited computer power
and resources on embedded systems, while such a assumption may not
be quite practical for other use cases.
In this patch, added is a function, rsa_gen_key_prop(), which will
generate additional parameters for other uses, in particular
UEFI secure boot, on the fly.
Note: the current code uses some "big number" routines from BearSSL
for the calculation.
Signed-off-by: AKASHI Takahiro
---
include/u-boot/rsa-mod-exp.h | 3 +
lib/rsa/Kconfig | 7 +
lib/rsa/Makefile | 1 +
lib/rsa/rsa-keyprop.c| 585 +++
4 files changed, 596 insertions(+)
create mode 100644 lib/rsa/rsa-keyprop.c
diff --git a/include/u-boot/rsa-mod-exp.h b/include/u-boot/rsa-mod-exp.h
index 8a428c4b6a1a..ca189292d869 100644
--- a/include/u-boot/rsa-mod-exp.h
+++ b/include/u-boot/rsa-mod-exp.h
@@ -26,6 +26,9 @@ struct key_prop {
uint32_t exp_len; /* Exponent length in number of uint8_t */
};
+struct key_prop *rsa_gen_key_prop(const void *key, uint32_t keylen);
+void rsa_free_key_prop(struct key_prop *prop);
+
/**
* rsa_mod_exp_sw() - Perform RSA Modular Exponentiation in sw
*
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
index 62b7ab9c5e5c..d1743d7a4c47 100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -30,6 +30,13 @@ config RSA_VERIFY
help
Add RSA signature verification support.
+config RSA_VERIFY_WITH_PKEY
+ bool "Execute RSA verification without key parameters from FDT"
+ depends on RSA
+ help
+ This options enables RSA signature verification without
+ using public key parameters which is embedded control FDT.
+
config RSA_SOFTWARE_EXP
bool "Enable driver for RSA Modular Exponentiation in software"
depends on DM
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile
index c07305188e0c..14ed3cb4012b 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -6,4 +6,5 @@
# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
obj-$(CONFIG_$(SPL_)RSA_VERIFY) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_RSA_VERIFY_WITH_PKEY) += rsa-keyprop.o
obj-$(CONFIG_RSA_SOFTWARE_EXP) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-keyprop.c b/lib/rsa/rsa-keyprop.c
new file mode 100644
index ..d7d222e9bed9
--- /dev/null
+++ b/lib/rsa/rsa-keyprop.c
@@ -0,0 +1,585 @@
+// SPDX-License-Identifier: GPL-2.0+ and MIT
+/*
+ * RSA library - generate parameters for a public key
+ *
+ * Copyright (c) 2019 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * Big number routines in this file come from BearSSL:
+ * Copyright (c) 2016 Thomas Pornin
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static inline unsigned
+br_dec16be(const void *src)
+{
+ return be16_to_cpup(src);
+}
+
+static inline uint32_t
+br_dec32be(const void *src)
+{
+ return be32_to_cpup(src);
+}
+
+static inline void
+br_enc32be(void *dst, uint32_t x)
+{
+ __be32 tmp;
+
+ tmp = cpu_to_be32(x);
+ memcpy(dst, , sizeof(tmp));
+}
+
+/* stripped version of src/inner.h */
+
+static inline uint32_t
+NOT(uint32_t ctl)
+{
+ return ctl ^ 1;
+}
+
+static inline uint32_t
+MUX(uint32_t ctl, uint32_t x, uint32_t y)
+{
+ return y ^ (-ctl & (x ^ y));
+}
+
+static inline uint32_t
+EQ(uint32_t x, uint32_t y)
+{
+ uint32_t q;
+
+ q = x ^ y;
+ return NOT((q | -q) >> 31);
+}
+
+static inline uint32_t
+NEQ(uint32_t x, uint32_t y)
+{
+ uint32_t q;
+
+ q = x ^ y;
+ return (q | -q) >> 31;
+}
+
+static inline uint32_t
+GT(uint32_t x, uint32_t y)
+{
+ /*
+* If both x < 2^31 and y < 2^31, then y-x will have its high
+* bit set if x > y, cleared otherwise.
+*
+* If either x >= 2^31 or y >= 2^31 (but not both), then the
+* result is the high bit of x.
+*
+* If both x >= 2^31 and y >= 2^31, then we can virtually
+* subtract 2^31 from both, and we are back to the first case.
+* Since (y-2^31)-(x-2^31) = y-x, the subtraction is already
+* fine.
+*/
+ uint32_t z;
+
+ z = y - x;
+ return (z ^ ((x ^ y) & (x ^ z))) >> 31;
+}
+
+static inline uint32_t
+BIT_LENGTH(uint32_t x)
+{
+ uint32_t k, c;
+
+ k = NEQ(x, 0);
+ c = GT(x, 0x); x = MUX(c, x >> 16, x); k += c << 4;
+ c = GT(x, 0x00FF); x = MUX(c, x >> 8, x); k += c << 3;
+ c = GT(x, 0x000F); x = MUX(c, x >> 4, x); k += c << 2;
+ c = GT(x, 0x0003); x = MUX(c, x >> 2, x); k += c << 1;
+ k += GT(x, 0x0001);
+ return k;
+}
+
+#define GE(x, y) NOT(GT(y, x))
+#define LT(x, y) GT(y, x)
+#define MUL(x, y) ((uint64_t)(x) * (uint64_t)(y))
+
+static inline uint32_t
+br_i32_word(const uint32_t *a, uint32_t
[U-Boot] [PATCH v1 0/3] rsa: extend rsa_verify() for UEFI secure boot
The current rsa_verify() requires five parameters for a RSA public key for efficiency while RSA, in theory, requires only two. In addition, those parameters are expected to come from FIT image. So this function won't fit very well when we want to use it for the purpose of implementing UEFI secure boot, in particular, image authentication as well as variable authentication, where the essential two parameters are set to be retrieved from one of X509 certificates in signature database. So, in this patch, additional three parameters will be calculated on the fly when rsa_verify() is called without fdt which should contain parameters above. This calculation heavily relies on "big-number (or multi-precision) library." Therefore some routines from BearSSL[1] under MIT license are imported in this implementation. See Patch#2. # Please let me know if this is not appropriate. # Checkpatch will complain with lots of warnings/errors, but # I intentionally don't fix them for maximum maintainability. [1] https://bearssl.org/ Changes in v1 (Oct 9, 2019) * fix a build error on pine64-lts_defconfig (reported by Heinrich) by defining FIT_IMAGE_ENABLE_VERIFY flag and adding SPL_RSA_VERIFY config (patch#1) * remove FIT-specific code from image-sig.c and put them to new image-fit-sig.c to allow us to disable CONFIG_FIT_SIGNATURE (patch#1) * compile rsa-keyprop.c only if necessary (i.e. if CONFIG_RSA_VERIFY_WITH_PKEY) (patch#2) * add SPDX license identifier in rsa-keyprop.c (patch#2) * include instead of (patch#2) * use U-Boot's byteorder helper functions instead of BearSSL's (patch#2) AKASHI Takahiro (3): lib: rsa: decouple rsa from FIT image verification lib: rsa: generate additional parameters for public key lib: rsa: add rsa_verify_with_pkey() Kconfig | 1 + common/Makefile | 3 +- common/image-fit-sig.c | 417 + common/image-fit.c | 6 +- common/image-sig.c | 396 include/image.h | 14 +- include/u-boot/rsa-mod-exp.h | 3 + lib/rsa/Kconfig | 12 + lib/rsa/Makefile | 2 +- lib/rsa/rsa-keyprop.c| 585 +++ lib/rsa/rsa-verify.c | 65 +++- tools/Makefile | 2 +- 12 files changed, 1095 insertions(+), 411 deletions(-) create mode 100644 common/image-fit-sig.c create mode 100644 lib/rsa/rsa-keyprop.c -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/3] lib: rsa: decouple rsa from FIT image verification
Introduce new configuration, CONFIG_RSA_VERIFY which will decouple building
RSA functions from FIT verification and allow for adding a RSA-based
signature verification for other file formats, in particular PE file
for UEFI secure boot.
Signed-off-by: AKASHI Takahiro
---
Kconfig| 1 +
common/Makefile| 3 +-
common/image-fit-sig.c | 417 +
common/image-fit.c | 6 +-
common/image-sig.c | 396 --
include/image.h| 14 +-
lib/rsa/Kconfig| 12 ++
lib/rsa/Makefile | 2 +-
lib/rsa/rsa-verify.c | 2 +
tools/Makefile | 2 +-
10 files changed, 452 insertions(+), 403 deletions(-)
create mode 100644 common/image-fit-sig.c
diff --git a/Kconfig b/Kconfig
index 1f0904f7045e..cf885fc2750f 100644
--- a/Kconfig
+++ b/Kconfig
@@ -416,6 +416,7 @@ config SPL_FIT_SIGNATURE
depends on SPL_DM
select SPL_FIT
select SPL_RSA
+ select SPL_RSA_VERIFY
config SPL_LOAD_FIT
bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
diff --git a/common/Makefile b/common/Makefile
index 302d8beaf356..5457f4738a02 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -112,7 +112,8 @@ obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
obj-$(CONFIG_$(SPL_)MULTI_DTB_FIT) += boot_fit.o common_fit.o
-obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += image-sig.o
+obj-$(CONFIG_RSA_VERIFY) += image-sig.o
+obj-$(CONFIG_$(SPL_TPL_)FIT_SIGNATURE) += image-fit-sig.o
obj-$(CONFIG_IO_TRACE) += iotrace.o
obj-y += memsize.o
obj-y += stdio.o
diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
new file mode 100644
index ..f6caeb0c5901
--- /dev/null
+++ b/common/image-fit-sig.c
@@ -0,0 +1,417 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2013, Google Inc.
+ */
+
+#ifdef USE_HOSTCC
+#include "mkimage.h"
+#include
+#else
+#include
+#include
+DECLARE_GLOBAL_DATA_PTR;
+#endif /* !USE_HOSTCC*/
+#include
+#include
+#include
+
+#define IMAGE_MAX_HASHED_NODES 100
+
+#ifdef USE_HOSTCC
+void *host_blob;
+
+void image_set_host_blob(void *blob)
+{
+ host_blob = blob;
+}
+
+void *image_get_host_blob(void)
+{
+ return host_blob;
+}
+#endif
+
+/**
+ * fit_region_make_list() - Make a list of image regions
+ *
+ * Given a list of fdt_regions, create a list of image_regions. This is a
+ * simple conversion routine since the FDT and image code use different
+ * structures.
+ *
+ * @fit: FIT image
+ * @fdt_regions: Pointer to FDT regions
+ * @count: Number of FDT regions
+ * @region: Pointer to image regions, which must hold @count records. If
+ * region is NULL, then (except for an SPL build) the array will be
+ * allocated.
+ * @return: Pointer to image regions
+ */
+struct image_region *fit_region_make_list(const void *fit,
+ struct fdt_region *fdt_regions,
+ int count,
+ struct image_region *region)
+{
+ int i;
+
+ debug("Hash regions:\n");
+ debug("%10s %10s\n", "Offset", "Size");
+
+ /*
+* Use malloc() except in SPL (to save code size). In SPL the caller
+* must allocate the array.
+*/
+#ifndef CONFIG_SPL_BUILD
+ if (!region)
+ region = calloc(sizeof(*region), count);
+#endif
+ if (!region)
+ return NULL;
+ for (i = 0; i < count; i++) {
+ debug("%10x %10x\n", fdt_regions[i].offset,
+ fdt_regions[i].size);
+ region[i].data = fit + fdt_regions[i].offset;
+ region[i].size = fdt_regions[i].size;
+ }
+
+ return region;
+}
+
+static int fit_image_setup_verify(struct image_sign_info *info,
+ const void *fit, int noffset,
+ int required_keynode, char **err_msgp)
+{
+ char *algo_name;
+ const char *padding_name;
+
+ if (fdt_totalsize(fit) > CONFIG_FIT_SIGNATURE_MAX_SIZE) {
+ *err_msgp = "Total size too large";
+ return 1;
+ }
+
+ if (fit_image_hash_get_algo(fit, noffset, _name)) {
+ *err_msgp = "Can't get hash algo property";
+ return -1;
+ }
+
+ padding_name = fdt_getprop(fit, noffset, "padding", NULL);
+ if (!padding_name)
+ padding_name = RSA_DEFAULT_PADDING_NAME;
+
+ memset(info, '\0', sizeof(*info));
+ info->keyname = fdt_getprop(fit, noffset, "key-name-hint", NULL);
+ info->fit = (void *)fit;
+ info->node_offset = noffset;
+ info->name = algo_name;
+ info->checksum = image_get_checksum_algo(algo_name);
+ info->crypto = image_get_crypto_algo(algo_name);
+ info->padding = image_get_padding_algo(padding_name);
+
[U-Boot] [PATCH 9/9] mpc85xx, socrates: add DM PCI support
add DM PCI support on the socrates board.
use PCIE_FSL now.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/socrates.dts | 1 +
board/socrates/law.c | 2 --
board/socrates/socrates.c | 40 +--
configs/socrates_defconfig| 7 ++
include/configs/socrates.h| 9
5 files changed, 13 insertions(+), 46 deletions(-)
diff --git a/arch/powerpc/dts/socrates.dts b/arch/powerpc/dts/socrates.dts
index 452cf58b5e..af3fa92fff 100644
--- a/arch/powerpc/dts/socrates.dts
+++ b/arch/powerpc/dts/socrates.dts
@@ -332,6 +332,7 @@
device_type = "pci";
reg = <0xe0008000 0x1000>;
clock-frequency = <>;
+ law_trgt_if = <0>;
interrupt-map-mask = <0xf800 0x0 0x0 0x7>;
interrupt-map = <
diff --git a/board/socrates/law.c b/board/socrates/law.c
index 44703e8aca..840941b63e 100644
--- a/board/socrates/law.c
+++ b/board/socrates/law.c
@@ -31,9 +31,7 @@
struct law_entry law_table[] = {
SET_LAW(CONFIG_SYS_DDR_SDRAM_BASE, LAW_SIZE_512M, LAW_TRGT_IF_DDR),
- SET_LAW(CONFIG_SYS_PCI1_MEM_PHYS, LAW_SIZE_512M, LAW_TRGT_IF_PCI),
SET_LAW(CONFIG_SYS_LBC_FLASH_BASE, LAW_SIZE_64M, LAW_TRGT_IF_LBC),
- SET_LAW(CONFIG_SYS_PCI1_IO_PHYS, LAW_SIZE_16M, LAW_TRGT_IF_PCI),
#if defined(CONFIG_SYS_FPGA_BASE)
SET_LAW(CONFIG_SYS_FPGA_BASE, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
#endif
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index 8549883508..5f58b4c21b 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -50,7 +50,7 @@ int checkboard (void)
}
putc('\n');
-#ifdef CONFIG_PCI
+#if defined(CONFIG_PCI) || defined(CONFIG_DM_PCI)
/* Check the PCI_clk sel bit */
if (in_be32(>porpllsr) & (1<<15)) {
src = "SYSCLK";
@@ -126,6 +126,10 @@ int misc_init_r (void)
_info[CONFIG_SYS_MAX_FLASH_BANKS - 1]);
}
+#if defined(CONFIG_DM_PCI)
+ pci_init();
+#endif
+
return 0;
}
@@ -168,40 +172,6 @@ void local_bus_init (void)
upmconfig (UPMB, (uint *)UPMTableB, sizeof(UPMTableB)/sizeof(int));
}
-#if defined(CONFIG_PCI)
-/*
- * Initialize PCI Devices, report devices found.
- */
-
-#ifndef CONFIG_PCI_PNP
-static struct pci_config_table pci_mpc85xxads_config_table[] = {
- {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID,
-PCI_IDSEL_NUMBER, PCI_ANY_ID,
-pci_cfgfunc_config_device, {PCI_ENET0_IOADDR,
-PCI_ENET0_MEMADDR,
-PCI_COMMAND_MEMORY |
-PCI_COMMAND_MASTER}},
- {}
-};
-#endif
-
-
-static struct pci_controller hose = {
-#ifndef CONFIG_PCI_PNP
- config_table:pci_mpc85xxads_config_table,
-#endif
-};
-
-#endif /* CONFIG_PCI */
-
-
-void pci_init_board (void)
-{
-#ifdef CONFIG_PCI
- pci_mpc85xx_init ();
-#endif /* CONFIG_PCI */
-}
-
#ifdef CONFIG_BOARD_EARLY_INIT_R
int board_early_init_r (void)
{
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 5bd60e0886..bda436ad62 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -14,6 +14,10 @@ CONFIG_SYS_CONSOLE_IS_IN_ENV=y
CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_REGINFO=y
+# CONFIG_BOOTM_NETBSD is not set
+# CONFIG_BOOTM_PLAN9 is not set
+# CONFIG_BOOTM_RTEMS is not set
+# CONFIG_BOOTM_VXWORKS is not set
CONFIG_CMD_IMLS=y
CONFIG_CMD_DM=y
CONFIG_CMD_I2C=y
@@ -44,6 +48,8 @@ CONFIG_SYS_FLASH_CFI=y
CONFIG_PHY_MARVELL=y
CONFIG_MII=y
CONFIG_TSEC_ENET=y
+CONFIG_DM_PCI=y
+CONFIG_PCIE_FSL=y
CONFIG_DM_RTC=y
CONFIG_RTC_RX8025=y
CONFIG_SPECIFY_CONSOLE_INDEX=y
@@ -53,4 +59,5 @@ CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_DM_USB=y
# CONFIG_USB_EHCI_HCD is not set
+CONFIG_USB_OHCI_PCI=y
CONFIG_USB_STORAGE=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 7adaa344bc..a03005902f 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -19,8 +19,6 @@
/* High Level Configuration Options */
#define CONFIG_SOCRATES1
-#define CONFIG_PCI_INDIRECT_BRIDGE
-
/*
* Only possible on E500 Version 2 or newer cores.
*/
@@ -156,7 +154,6 @@
* General PCI
* Memory space is mapped 1-1.
*/
-#define CONFIG_SYS_PCI_PHYS0x8000 /* 1G PCI TLB */
/* PCI is clocked by the external source at 33 MHz */
#define CONFIG_PCI_CLK_FREQ3300
@@ -167,10 +164,6 @@
#define CONFIG_SYS_PCI1_IO_PHYSCONFIG_SYS_PCI1_IO_BASE
#define CONFIG_SYS_PCI1_IO_SIZE0x0100 /* 16M
*/
-#if defined(CONFIG_PCI)
-#undef CONFIG_PCI_SCAN_SHOW/* show pci devices on startup */
-#endif /* CONFIG_PCI */
-
#define CONFIG_TSEC1 1
#define CONFIG_TSEC1_NAME "TSEC0"
#define CONFIG_TSEC3 1
@@ -292,8 +285,6 @@
/* USB support */
#define CONFIG_USB_OHCI_NEW
[U-Boot] [PATCH 7/9] mpc85xx, socrates: enable DM I2C
enable DM I2C support for the socrates board.
Signed-off-by: Heiko Schocher
---
configs/socrates_defconfig | 4 +++-
include/configs/socrates.h | 18 +-
2 files changed, 4 insertions(+), 18 deletions(-)
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index be88cefe3e..80b5631d07 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -27,7 +27,6 @@ CONFIG_CMD_DHCP=y
CONFIG_CMD_MII=y
CONFIG_CMD_PING=y
CONFIG_CMD_SNTP=y
-CONFIG_CMD_DATE=y
# CONFIG_CMD_HASH is not set
CONFIG_CMD_EXT2=y
# CONFIG_CMD_IRQ is not set
@@ -36,6 +35,8 @@ CONFIG_DEFAULT_DEVICE_TREE="socrates"
CONFIG_ENV_IS_IN_FLASH=y
CONFIG_DM=y
CONFIG_BLK=y
+CONFIG_DM_I2C=y
+CONFIG_SYS_I2C_FSL=y
# CONFIG_MMC is not set
CONFIG_MTD_NOR_FLASH=y
CONFIG_FLASH_CFI_DRIVER=y
@@ -43,6 +44,7 @@ CONFIG_SYS_FLASH_CFI=y
CONFIG_PHY_MARVELL=y
CONFIG_MII=y
CONFIG_TSEC_ENET=y
+CONFIG_DM_RTC=y
CONFIG_RTC_RX8025=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index c35e8aed77..425d758e1d 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -160,23 +160,7 @@
#define CONFIG_SYS_BAUDRATE_TABLE \
{300, 600, 1200, 2400, 4800, 9600, 19200, 38400,115200}
-/*
- * I2C
- */
-#define CONFIG_SYS_I2C
-#define CONFIG_SYS_I2C_FSL
-#define CONFIG_SYS_FSL_I2C_SPEED 102124
-#define CONFIG_SYS_FSL_I2C_SLAVE 0x7F
-#define CONFIG_SYS_FSL_I2C_OFFSET 0x3000
-#define CONFIG_SYS_FSL_I2C2_SPEED 102124
-#define CONFIG_SYS_FSL_I2C2_SLAVE 0x7F
-#define CONFIG_SYS_FSL_I2C2_OFFSET 0x3100
-
-/* I2C RTC */
-#define CONFIG_SYS_I2C_RTC_ADDR0x32/* at address 0x32
*/
-
-/* I2C W83782G HW-Monitoring IC */
-#define CONFIG_SYS_I2C_W83782G_ADDR0x28/* W83782G address
*/
+#define CONFIG_SYS_SPD_BUS_NUM 0
#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 4
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/9] mpc85xx: add socrates dts from linux
add socrates device tree from linux:
commit 71ae5fc87c34 ("Merge tag 'linux-kselftest-5.2-rc1' of
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest")
and added SPDX license identifier.
Did not fix checkpatch warnings:
arch/powerpc/dts/socrates.dts:235: check: Please don't use multiple blank lines
arch/powerpc/dts/socrates.dts:238: error: code indent should use tabs where
possible
Also, add me as board maintainer.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/socrates.dts | 349 ++
board/socrates/MAINTAINERS| 3 +-
3 files changed, 352 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/dts/socrates.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index 021c85f00f..3195351c9c 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -8,6 +8,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb
dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb
dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb
dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb
+dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb
dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb
dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb
dtb-$(CONFIG_TARGET_T2080QDS) += t2080qds.dtb
diff --git a/arch/powerpc/dts/socrates.dts b/arch/powerpc/dts/socrates.dts
new file mode 100644
index 00..452cf58b5e
--- /dev/null
+++ b/arch/powerpc/dts/socrates.dts
@@ -0,0 +1,349 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree Source for the Socrates board (MPC8544).
+ *
+ * Copyright (c) 2008 Emcraft Systems.
+ * Sergei Poselenov,
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ model = "abb,socrates";
+ compatible = "abb,socrates";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ serial0 =
+ serial1 =
+ pci0 =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ PowerPC,8544@0 {
+ device_type = "cpu";
+ reg = <0>;
+ d-cache-line-size = <32>;
+ i-cache-line-size = <32>;
+ d-cache-size = <0x8000>;// L1, 32K
+ i-cache-size = <0x8000>;// L1, 32K
+ timebase-frequency = <0>;
+ bus-frequency = <0>;
+ clock-frequency = <0>;
+ next-level-cache = <>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x>; // Filled in by U-Boot
+ };
+
+ soc8544@e000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "soc";
+
+ ranges = <0x 0xe000 0x0010>;
+ bus-frequency = <0>;// Filled in by U-Boot
+ compatible = "fsl,mpc8544-immr", "simple-bus";
+
+ ecm-law@0 {
+ compatible = "fsl,ecm-law";
+ reg = <0x0 0x1000>;
+ fsl,num-laws = <10>;
+ };
+
+ ecm@1000 {
+ compatible = "fsl,mpc8544-ecm", "fsl,ecm";
+ reg = <0x1000 0x1000>;
+ interrupts = <17 2>;
+ interrupt-parent = <>;
+ };
+
+ memory-controller@2000 {
+ compatible = "fsl,mpc8544-memory-controller";
+ reg = <0x2000 0x1000>;
+ interrupt-parent = <>;
+ interrupts = <18 2>;
+ };
+
+ L2: l2-cache-controller@2 {
+ compatible = "fsl,mpc8544-l2-cache-controller";
+ reg = <0x2 0x1000>;
+ cache-line-size = <32>;
+ cache-size = <0x4>; // L2, 256K
+ interrupt-parent = <>;
+ interrupts = <16 2>;
+ };
+
+ i2c@3000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cell-index = <0>;
+ compatible = "fsl,mpc8544-i2c", "fsl-i2c";
+ reg = <0x3000 0x100>;
+ interrupts = <43 2>;
+ interrupt-parent = <>;
+ fsl,preserve-clocking;
+
+ dtt@28 {
+ compatible = "winbond,w83782d";
+ reg = <0x28>;
+ };
+ rtc@32 {
+ compatible = "epson,rx8025";
+ reg = <0x32>;
+ interrupts = <7 1>;
+
[U-Boot] [PATCH 8/9] mpc85xx, socrates: enable DM serial
switch to DM_SERIAL support.
Signed-off-by: Heiko Schocher
---
board/socrates/socrates.c | 5 +
configs/socrates_defconfig | 3 +++
include/configs/socrates.h | 12
3 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index f51b0203f7..8549883508 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -271,3 +271,8 @@ void *board_fdt_blob_setup(void)
return fw_dtb;
}
#endif
+
+int get_serial_clock(void)
+{
+ return 0;
+}
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 80b5631d07..5bd60e0886 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -46,6 +46,9 @@ CONFIG_MII=y
CONFIG_TSEC_ENET=y
CONFIG_DM_RTC=y
CONFIG_RTC_RX8025=y
+CONFIG_SPECIFY_CONSOLE_INDEX=y
+CONFIG_DM_SERIAL=y
+CONFIG_SERIAL_SEARCH_ALL=y
CONFIG_SYS_NS16550=y
CONFIG_USB=y
CONFIG_DM_USB=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 425d758e1d..7adaa344bc 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -148,18 +148,6 @@
#define CONFIG_SYS_BR2_PRELIM 0xc80018a1 /* UPMB, 32-bit */
#define CONFIG_SYS_OR2_PRELIM 0xfc00 /* 64 MB*/
-/* Serial Port */
-
-#define CONFIG_SYS_NS16550_SERIAL
-#define CONFIG_SYS_NS16550_REG_SIZE1
-#define CONFIG_SYS_NS16550_CLK get_bus_freq(0)
-
-#define CONFIG_SYS_NS16550_COM1(CONFIG_SYS_CCSRBAR+0x4500)
-#define CONFIG_SYS_NS16550_COM2(CONFIG_SYS_CCSRBAR+0x4600)
-
-#define CONFIG_SYS_BAUDRATE_TABLE \
- {300, 600, 1200, 2400, 4800, 9600, 19200, 38400,115200}
-
#define CONFIG_SYS_SPD_BUS_NUM 0
#define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 4
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/9] mpc85xx, socrates: add DM support
enable CONFIG_DM for the socrates board.
Signed-off-by: Heiko Schocher
---
board/socrates/socrates.c | 15 +++
configs/socrates_defconfig | 6 +-
include/configs/socrates.h | 13 +++--
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index da9ae5bebb..8f9583360b 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -432,3 +432,18 @@ void video_get_info_str (int line_number, char *info)
}
}
#endif
+
+#if defined(CONFIG_OF_SEPARATE)
+void *board_fdt_blob_setup(void)
+{
+ void *fw_dtb;
+
+ fw_dtb = (void *)(CONFIG_SYS_TEXT_BASE - CONFIG_ENV_SECT_SIZE);
+ if (fdt_magic(fw_dtb) != FDT_MAGIC) {
+ printf("DTB is not passed via %x\n", (u32)fw_dtb);
+ return NULL;
+ }
+
+ return fw_dtb;
+}
+#endif
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig
index 58d135b907..1730d5793b 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -3,6 +3,7 @@ CONFIG_SYS_TEXT_BASE=0xfff8
CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_SOCRATES=y
+# CONFIG_SYS_MALLOC_F is not set
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
@@ -15,6 +16,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_HUSH_PARSER=y
CONFIG_CMD_REGINFO=y
CONFIG_CMD_IMLS=y
+CONFIG_CMD_DM=y
CONFIG_CMD_I2C=y
CONFIG_CMD_NAND=y
CONFIG_CMD_PCI=y
@@ -31,7 +33,10 @@ CONFIG_CMD_DATE=y
# CONFIG_CMD_HASH is not set
CONFIG_CMD_EXT2=y
# CONFIG_CMD_IRQ is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="socrates"
CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_DM=y
# CONFIG_MMC is not set
CONFIG_MTD_NOR_FLASH=y
CONFIG_FLASH_CFI_DRIVER=y
@@ -46,4 +51,3 @@ CONFIG_USB=y
CONFIG_USB_STORAGE=y
CONFIG_VIDEO=y
CONFIG_CONSOLE_EXTRA_INFO=y
-CONFIG_OF_LIBFDT=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index 4192148b52..4e10786ed8 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -238,9 +238,10 @@
* Environment
*/
#define CONFIG_ENV_SECT_SIZE 0x2 /* 128K(one sector) for env */
-#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE -
CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - \
+ CONFIG_ENV_SECT_SIZE - CONFIG_ENV_SECT_SIZE)
#define CONFIG_ENV_SIZE0x4000
-#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR-CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR - CONFIG_ENV_SECT_SIZE)
#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE)
#define CONFIG_LOADS_ECHO 1 /* echo on for serial download */
@@ -280,7 +281,7 @@
"bootfile=/home/tftp/syscon3/uImage\0" \
"fdt_file=/home/tftp/syscon3/socrates.dtb\0"\
"initrd_file=/home/tftp/syscon3/uinitrd.gz\0" \
- "uboot_addr=FFFA\0" \
+ "uboot_addr=FFF6\0" \
"kernel_addr=FE00\0"\
"fdt_addr=FE1E\0" \
"ramdisk_addr=FE20\0" \
@@ -303,9 +304,9 @@
"run nfsargs addip addcons;"\
"bootm ${kernel_addr_r} - ${fdt_addr_r}\0" \
"update_uboot=tftp 10 ${uboot_file};" \
- "protect off fffa ;"\
- "era fffa ;"\
- "cp.b 10 fffa ${filesize};" \
+ "protect off fff6 ;"\
+ "era fff6 ;"\
+ "cp.b 10 fff6 ${filesize};" \
"setenv filesize;saveenv\0" \
"update_kernel=tftp 10 ${bootfile};"\
"era fe00 fe1d;"\
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/9] mpc85xx, socrates: disable VIDEO
disable video, as not really needed longer.
Signed-off-by: Heiko Schocher
---
board/socrates/socrates.c | 180 +
configs/socrates_defconfig | 3 -
include/configs/socrates.h | 15
3 files changed, 2 insertions(+), 196 deletions(-)
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c
index 8f9583360b..f51b0203f7 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -231,6 +231,7 @@ int ft_board_setup(void *blob, bd_t *bd)
val[i++] = gd->bd->bi_flashstart;
val[i++] = gd->bd->bi_flashsize;
+#if defined(CONFIG_VIDEO_MB862xx)
if (mb862xx.frameAdrs == CONFIG_SYS_LIME_BASE) {
/* Fixup LIME mapping */
val[i++] = 2; /* chip select number */
@@ -238,6 +239,7 @@ int ft_board_setup(void *blob, bd_t *bd)
val[i++] = CONFIG_SYS_LIME_BASE;
val[i++] = CONFIG_SYS_LIME_SIZE;
}
+#endif
/* Fixup FPGA mapping */
val[i++] = 3; /* chip select number */
@@ -255,184 +257,6 @@ int ft_board_setup(void *blob, bd_t *bd)
}
#endif /* CONFIG_OF_BOARD_SETUP */
-#define DEFAULT_BRIGHTNESS 25
-#define BACKLIGHT_ENABLE (1 << 31)
-
-static const gdc_regs init_regs [] =
-{
- {0x0100, 0x00010f00},
- {0x0020, 0x801901df},
- {0x0024, 0x},
- {0x0028, 0x},
- {0x002c, 0x},
- {0x0110, 0x},
- {0x0114, 0x},
- {0x0118, 0x01df0320},
- {0x0004, 0x041f},
- {0x0008, 0x031f031f},
- {0x000c, 0x017f0349},
- {0x0010, 0x020c},
- {0x0014, 0x01df01e9},
- {0x0018, 0x},
- {0x001c, 0x01e00320},
- {0x0100, 0x80010f00},
- {0x0, 0x0}
-};
-
-const gdc_regs *board_get_regs (void)
-{
- return init_regs;
-}
-
-int lime_probe(void)
-{
- uint cfg_br2;
- uint cfg_or2;
- int type;
-
- cfg_br2 = get_lbc_br(2);
- cfg_or2 = get_lbc_or(2);
-
- /* Configure GPCM for CS2 */
- set_lbc_br(2, 0);
- set_lbc_or(2, 0xfc000410);
- set_lbc_br(2, (CONFIG_SYS_LIME_BASE) | 0x1901);
-
- /* Get controller type */
- type = mb862xx_probe(CONFIG_SYS_LIME_BASE);
-
- /* Restore previous CS2 configuration */
- set_lbc_br(2, 0);
- set_lbc_or(2, cfg_or2);
- set_lbc_br(2, cfg_br2);
-
- return (type == MB862XX_TYPE_LIME) ? 1 : 0;
-}
-
-/* Returns Lime base address */
-unsigned int board_video_init (void)
-{
- if (!lime_probe())
- return 0;
-
- mb862xx.winSizeX = 800;
- mb862xx.winSizeY = 480;
- mb862xx.gdfIndex = GDF_15BIT_555RGB;
- mb862xx.gdfBytesPP = 2;
-
- return CONFIG_SYS_LIME_BASE;
-}
-
-#define W83782D_REG_CFG0x40
-#define W83782D_REG_BANK_SEL 0x4e
-#define W83782D_REG_ADCCLK 0x4b
-#define W83782D_REG_BEEP_CTRL 0x4d
-#define W83782D_REG_BEEP_CTRL2 0x57
-#define W83782D_REG_PWMOUT10x5b
-#define W83782D_REG_VBAT 0x5d
-
-static int w83782d_hwmon_init(void)
-{
- u8 buf;
-
- if (i2c_read(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_CFG, 1, , 1))
- return -1;
-
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_CFG, 0x80);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_BANK_SEL, 0);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_ADCCLK, 0x40);
-
- buf = i2c_reg_read(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_BEEP_CTRL);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_BEEP_CTRL,
- buf | 0x80);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_BEEP_CTRL2, 0);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_PWMOUT1, 0x47);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_VBAT, 0x01);
-
- buf = i2c_reg_read(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_CFG);
- i2c_reg_write(CONFIG_SYS_I2C_W83782G_ADDR, W83782D_REG_CFG,
- (buf & 0xf4) | 0x01);
- return 0;
-}
-
-static void board_backlight_brightness(int br)
-{
- u32 reg;
- u8 buf;
- u8 old_buf;
-
- /* Select bank 0 */
- if (i2c_read(CONFIG_SYS_I2C_W83782G_ADDR, 0x4e, 1, _buf, 1))
- goto err;
- else
- buf = old_buf & 0xf8;
-
- if (i2c_write(CONFIG_SYS_I2C_W83782G_ADDR, 0x4e, 1, , 1))
- goto err;
-
- if (br > 0) {
- /* PWMOUT1 duty cycle ctrl */
- buf = 255 / (100 / br);
- if (i2c_write(CONFIG_SYS_I2C_W83782G_ADDR, 0x5b, 1, , 1))
- goto err;
-
- /* LEDs on */
- reg = in_be32((void *)(CONFIG_SYS_FPGA_BASE + 0x0c));
- if (!(reg & BACKLIGHT_ENABLE))
- out_be32((void *)(CONFIG_SYS_FPGA_BASE + 0x0c),
-reg | BACKLIGHT_ENABLE);
- } else {
-
[U-Boot] [PATCH 5/9] mpc85xx, socrates: get rid of DM_USB warning
add some defines and get rid of USB warning. Signed-off-by: Heiko Schocher --- configs/socrates_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig index 1730d5793b..2c87ec5134 100644 --- a/configs/socrates_defconfig +++ b/configs/socrates_defconfig @@ -3,7 +3,6 @@ CONFIG_SYS_TEXT_BASE=0xfff8 CONFIG_MPC85xx=y # CONFIG_CMD_ERRATA is not set CONFIG_TARGET_SOCRATES=y -# CONFIG_SYS_MALLOC_F is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_OF_BOARD_SETUP=y @@ -37,6 +36,7 @@ CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="socrates" CONFIG_ENV_IS_IN_FLASH=y CONFIG_DM=y +CONFIG_BLK=y # CONFIG_MMC is not set CONFIG_MTD_NOR_FLASH=y CONFIG_FLASH_CFI_DRIVER=y @@ -47,6 +47,7 @@ CONFIG_TSEC_ENET=y CONFIG_RTC_RX8025=y CONFIG_SYS_NS16550=y CONFIG_USB=y +CONFIG_DM_USB=y # CONFIG_USB_EHCI_HCD is not set CONFIG_USB_STORAGE=y CONFIG_VIDEO=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/9] mpc85xx, socrates: suppress unknown flash warning
suppress warning:
Flash: ## Unknown flash on Bank 1 - Size = 0x = 0 MB
Signed-off-by: Heiko Schocher
---
include/configs/socrates.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/configs/socrates.h b/include/configs/socrates.h
index c7c30d367a..4192148b52 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -96,6 +96,7 @@
*/
#define CONFIG_SYS_LBC_CACHE_BASE 0xf000 /* Localbus cacheable
*/
+#define CONFIG_SYS_FLASH_QUIET_TEST
#define CONFIG_SYS_FLASH0 0xFE00
#define CONFIG_SYS_FLASH1 0xFC00
#define CONFIG_SYS_FLASH_BANKS_LIST{ CONFIG_SYS_FLASH1, CONFIG_SYS_FLASH0 }
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/9] mpc85xx, dts, socrates: add u-boot specific dtsi
add u-boot specific dtsi file for socrates board.
Signed-off-by: Heiko Schocher
---
arch/powerpc/dts/socrates-u-boot.dtsi | 40 +++
board/socrates/MAINTAINERS| 1 +
2 files changed, 41 insertions(+)
create mode 100644 arch/powerpc/dts/socrates-u-boot.dtsi
diff --git a/arch/powerpc/dts/socrates-u-boot.dtsi
b/arch/powerpc/dts/socrates-u-boot.dtsi
new file mode 100644
index 00..14a7c245dc
--- /dev/null
+++ b/arch/powerpc/dts/socrates-u-boot.dtsi
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de
+ */
+/ {
+ binman {
+ filename = "u-boot-socrates.bin";
+ pad-byte = <0xff>;
+ // Place dtb one sector before u-boot-nodtb.bin
+ blob {
+ filename = "dts/dt.dtb";
+ };
+ u-boot-nodtb {
+ filename = "u-boot-nodtb.bin";
+ offset = <0x2>;
+ };
+ };
+
+ chosen {
+ stdout-path =
+ };
+
+ soc8544@e000 {
+ i2c@3000 {
+ u-boot,dm-pre-reloc;
+ };
+ };
+};
+
+ {
+ clock-frequency = <3300>;
+ ranges = <0x0200 0x0 0x8000 0x8000 0x0 0x2000
+ 0x0100 0x0 0xe200 0xe200 0x0 0x0100>;
+};
+
+ {
+ u-boot,dm-pre-reloc;
+ clock-frequency = <0>;
+};
diff --git a/board/socrates/MAINTAINERS b/board/socrates/MAINTAINERS
index c5607fc342..2b27a73c18 100644
--- a/board/socrates/MAINTAINERS
+++ b/board/socrates/MAINTAINERS
@@ -5,3 +5,4 @@ F: board/socrates/
F: include/configs/socrates.h
F: configs/socrates_defconfig
F: arch/powerpc/dts/socrates.dts
+F: arch/powerpc/dts/socrates-u-boot.dtsi
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/9] powerpc: convert socrates board to DM
convert the socrates board to use DM. needs patchseries: pci: pcie_fsl: add support for none PCIe devices http://patchwork.ozlabs.org/project/uboot/list/?series=134976 fixes compiler warnings: = WARNING == This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. See doc/driver-model/migration.rst for more info. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. Travis build: https://travis-ci.org/hsdenx/u-boot-test/builds/595058715 Heiko Schocher (9): mpc85xx, socrates: suppress unknown flash warning mpc85xx: add socrates dts from linux mpc85xx, dts, socrates: add u-boot specific dtsi mpc85xx, socrates: add DM support mpc85xx, socrates: get rid of DM_USB warning mpc85xx, socrates: disable VIDEO mpc85xx, socrates: enable DM I2C mpc85xx, socrates: enable DM serial mpc85xx, socrates: add DM PCI support arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/socrates-u-boot.dtsi | 40 +++ arch/powerpc/dts/socrates.dts | 350 ++ board/socrates/MAINTAINERS| 4 +- board/socrates/law.c | 2 - board/socrates/socrates.c | 222 ++-- configs/socrates_defconfig| 24 +- include/configs/socrates.h| 68 + 8 files changed, 440 insertions(+), 271 deletions(-) create mode 100644 arch/powerpc/dts/socrates-u-boot.dtsi create mode 100644 arch/powerpc/dts/socrates.dts -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: dm_mmc: Initialize only the required mmc device
Hi Peng,
On 10/09/19 7:50 AM, Peng Fan wrote:
>> Subject: [PATCH] spl: dm_mmc: Initialize only the required mmc device
>>
>> In SPL, all the available mmc devices gets initialized during boot.
>> This might not work in cases where clocks are not available for certain mmc
>> devices(other than boot device) and the support for enabling device might not
>> be ready.
>>
>> Texas Instruments' K3 J721E device having a central system controller
>> (dmsc) is one such example falling in this category. Below is the sequence
>> for
>> the failing scenario:
>> - ROM comes up in SD mode and loads SPL by just initialing SD card.
>> - SPL loads dmsc firmware from SD Card.
>> Since ROM has enabled SD, SPL need not enable the SD, just need to re
>> initialize the card. But SPL is trying to initialize other MMC instances
>> which
>> are in disabled state. Since dmsc firmware is not yet available, devices
>> cannot
>> be enabled. So in SPL, initialize only the mmc device that is needed.
>>
>> Signed-off-by: Lokesh Vutla
Gentle Ping. Are you planning to take this patch for this merge window?
Thanks and regards,
Lokesh
>> ---
>> common/spl/spl_mmc.c | 14 --
>> drivers/mmc/mmc.c| 24
>> include/mmc.h| 1 +
>> 3 files changed, 29 insertions(+), 10 deletions(-)
>>
>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index
>> b3619889f7..303f0f80bf 100644
>> --- a/common/spl/spl_mmc.c
>> +++ b/common/spl/spl_mmc.c
>> @@ -113,31 +113,25 @@ static int spl_mmc_get_device_index(u32
>> boot_device)
>>
>> static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
>> { -#if CONFIG_IS_ENABLED(DM_MMC)
>> -struct udevice *dev;
>> -#endif
>> int err, mmc_dev;
>>
>> mmc_dev = spl_mmc_get_device_index(boot_device);
>> if (mmc_dev < 0)
>> return mmc_dev;
>>
>> +#if CONFIG_IS_ENABLED(DM_MMC)
>> +err = mmc_init_device(mmc_dev);
>> +#else
>> err = mmc_initialize(NULL);
>> +#endif /* DM_MMC */
>> if (err) {
>> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> printf("spl: could not initialize mmc. error: %d\n", err);
>> #endif
>> return err;
>> }
>> -
>> -#if CONFIG_IS_ENABLED(DM_MMC)
>> -err = uclass_get_device(UCLASS_MMC, mmc_dev, );
>> -if (!err)
>> -*mmcp = mmc_get_mmc_dev(dev);
>> -#else
>> *mmcp = find_mmc_device(mmc_dev);
>> err = *mmcp ? 0 : -ENODEV;
>> -#endif
>> if (err) {
>> #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> printf("spl: could not find mmc device %d. error: %d\n", diff
>> --git
>> a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index eecc7d687e..ec8f92ce8f
>> 100644
>> --- a/drivers/mmc/mmc.c
>> +++ b/drivers/mmc/mmc.c
>> @@ -2998,6 +2998,30 @@ int mmc_initialize(bd_t *bis)
>> return 0;
>> }
>>
>> +#if CONFIG_IS_ENABLED(DM_MMC)
>> +int mmc_init_device(int num)
>> +{
>> +struct udevice *dev;
>> +struct mmc *m;
>> +int ret;
>> +
>> +ret = uclass_get_device(UCLASS_MMC, num, );
>> +if (ret)
>> +return ret;
>> +
>> +m = mmc_get_mmc_dev(dev);
>> +if (!m)
>> +return 0;
>> +#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
>> +mmc_set_preinit(m, 1);
>> +#endif
>> +if (m->preinit)
>> +mmc_start_init(m);
>> +
>> +return 0;
>> +}
>> +#endif
>> +
>> #ifdef CONFIG_CMD_BKOPS_ENABLE
>> int mmc_set_bkops_enable(struct mmc *mmc) { diff --git
>> a/include/mmc.h b/include/mmc.h index 46422f41a4..878b4c9e57 100644
>> --- a/include/mmc.h
>> +++ b/include/mmc.h
>> @@ -698,6 +698,7 @@ void mmc_destroy(struct mmc *mmc);
>> */
>> int mmc_unbind(struct udevice *dev);
>> int mmc_initialize(bd_t *bis);
>> +int mmc_init_device(int num);
>> int mmc_init(struct mmc *mmc);
>> int mmc_send_tuning(struct mmc *mmc, u32 opcode, int *cmd_error);
>
> Reviewed-by: Peng Fan
>
>>
>> --
>> 2.22.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] pci: pcie_fsl: add support for "fsl, mpc8540-pci"
add support for "fsl,mpc8540-pci":
- add flag "ispci" in struct fsl_pcie_data
so we can code out differences to existing devices
without breaking them
- changes if ispci is set:
- in fsl_pcie_addr_valid() check only common checks
- fsl_pcie_link_up( returns always 1
- in inbound setup, add flag PIWAR_MEM_2G
- set pcie->enabled always to 1
Signed-off-by: Heiko Schocher
---
drivers/pci/pcie_fsl.c | 27 ++-
drivers/pci/pcie_fsl.h | 1 +
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index 05b2522dac..3c207e761e 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -23,6 +23,7 @@ static int fsl_pcie_link_up(struct fsl_pcie *pcie);
static int fsl_pcie_addr_valid(struct fsl_pcie *pcie, pci_dev_t bdf)
{
struct udevice *bus = pcie->bus;
+ struct fsl_pcie_data *info = pcie->info;
if (!pcie->enabled)
return -ENXIO;
@@ -33,6 +34,9 @@ static int fsl_pcie_addr_valid(struct fsl_pcie *pcie,
pci_dev_t bdf)
if (PCI_BUS(bdf) == (bus->seq + 1) && (PCI_DEV(bdf) > 0))
return -EINVAL;
+ if (info->ispci)
+ return 0;
+
if (PCI_BUS(bdf) > bus->seq && (!fsl_pcie_link_up(pcie) || pcie->mode))
return -EINVAL;
@@ -161,9 +165,13 @@ static int fsl_pcie_hose_write_config_dword(struct
fsl_pcie *pcie, uint offset,
static int fsl_pcie_link_up(struct fsl_pcie *pcie)
{
+ struct fsl_pcie_data *info = pcie->info;
ccsr_fsl_pci_t *regs = pcie->regs;
u16 ltssm;
+ if (info->ispci)
+ return 1;
+
if (pcie->block_rev >= PEX_IP_BLK_REV_3_0) {
ltssm = (in_be32(>pex_csr0)
& PEX_CSR0_LTSSM_MASK) >> PEX_CSR0_LTSSM_SHIFT;
@@ -251,6 +259,7 @@ static int fsl_pcie_setup_inbound_win(struct fsl_pcie
*pcie, int idx,
bool pf, u64 phys, u64 bus_addr,
pci_size_t size)
{
+ struct fsl_pcie_data *info = pcie->info;
ccsr_fsl_pci_t *regs = pcie->regs;
pit_t *pi = >pit[idx];
u32 sz = (__ilog2_u64(size) - 1);
@@ -275,6 +284,10 @@ static int fsl_pcie_setup_inbound_win(struct fsl_pcie
*pcie, int idx,
flag |= PIWAR_EN | PIWAR_READ_SNOOP | PIWAR_WRITE_SNOOP;
if (pf)
flag |= PIWAR_PF;
+
+ if (info->ispci)
+ flag |= PIWAR_MEM_2G;
+
out_be32(>piwar, flag | sz);
return 0;
@@ -508,6 +521,7 @@ static int fsl_pcie_init_ep(struct fsl_pcie *pcie)
static int fsl_pcie_probe(struct udevice *dev)
{
struct fsl_pcie *pcie = dev_get_priv(dev);
+ struct fsl_pcie_data *info = pcie->info;
ccsr_fsl_pci_t *regs = pcie->regs;
u16 val_16;
@@ -515,7 +529,10 @@ static int fsl_pcie_probe(struct udevice *dev)
pcie->block_rev = in_be32(>block_rev1);
list_add(>list, _pcie_list);
- pcie->enabled = is_serdes_configured(PCIE1 + pcie->idx);
+ if (info->ispci)
+ pcie->enabled = 1;
+ else
+ pcie->enabled = is_serdes_configured(PCIE1 + pcie->idx);
if (!pcie->enabled) {
printf("PCIe%d: %s disabled\n", pcie->idx, dev->name);
return 0;
@@ -579,6 +596,13 @@ static const struct dm_pci_ops fsl_pcie_ops = {
.write_config = fsl_pcie_write_config,
};
+static struct fsl_pcie_data mpc85xx_data = {
+ .block_offset = 0x8000,
+ .block_offset_mask = 0x,
+ .stride = 0x1000,
+ .ispci = 1,
+};
+
static struct fsl_pcie_data p1_p2_data = {
.block_offset = 0xa000,
.block_offset_mask = 0x,
@@ -598,6 +622,7 @@ static struct fsl_pcie_data t2080_data = {
};
static const struct udevice_id fsl_pcie_ids[] = {
+ { .compatible = "fsl,mpc8540-pci", .data = (ulong)_data },
{ .compatible = "fsl,pcie-mpc8548", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p1_p2", .data = (ulong)_p2_data },
{ .compatible = "fsl,pcie-p2041", .data = (ulong)_data },
diff --git a/drivers/pci/pcie_fsl.h b/drivers/pci/pcie_fsl.h
index dc8368d559..ef1b1ac8d4 100644
--- a/drivers/pci/pcie_fsl.h
+++ b/drivers/pci/pcie_fsl.h
@@ -47,6 +47,7 @@ struct fsl_pcie_data {
u32 block_offset; /* Offset from CCSR of 1st controller */
u32 block_offset_mask; /* Mask out the CCSR base */
u32 stride; /* Offset stride between controllers */
+ int ispci; /* if PCI only */
};
struct fsl_pcie {
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] pci: pcie_fsl: use pci_conv_size_to_32()
simplify read/write functions and use pci_conv_size_to_32().
Signed-off-by: Heiko Schocher
---
drivers/pci/pcie_fsl.c | 35 ++-
1 file changed, 2 insertions(+), 33 deletions(-)
diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c
index ab25aeee73..ada6e12e2f 100644
--- a/drivers/pci/pcie_fsl.c
+++ b/drivers/pci/pcie_fsl.c
@@ -58,21 +58,8 @@ static int fsl_pcie_read_config(struct udevice *bus,
pci_dev_t bdf,
bdf = bdf - PCI_BDF(bus->seq, 0, 0);
val = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
out_be32(>cfg_addr, val);
-
sync();
-
- switch (size) {
- case PCI_SIZE_8:
- *valuep = in_8((u8 *)>cfg_data + (offset & 3));
- break;
- case PCI_SIZE_16:
- *valuep = in_le16((u16 *)((u8 *)>cfg_data +
- (offset & 2)));
- break;
- case PCI_SIZE_32:
- *valuep = in_le32(>cfg_data);
- break;
- }
+ *valuep = pci_conv_32_to_size(in_le32(>cfg_data), offset, size);
return 0;
}
@@ -84,9 +71,6 @@ static int fsl_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
struct fsl_pcie *pcie = dev_get_priv(bus);
ccsr_fsl_pci_t *regs = pcie->regs;
u32 val;
- u8 val_8;
- u16 val_16;
- u32 val_32;
if (fsl_pcie_addr_valid(pcie, bdf))
return 0;
@@ -94,23 +78,8 @@ static int fsl_pcie_write_config(struct udevice *bus,
pci_dev_t bdf,
bdf = bdf - PCI_BDF(bus->seq, 0, 0);
val = bdf | (offset & 0xfc) | ((offset & 0xf00) << 16) | 0x8000;
out_be32(>cfg_addr, val);
-
sync();
-
- switch (size) {
- case PCI_SIZE_8:
- val_8 = value;
- out_8((u8 *)>cfg_data + (offset & 3), val_8);
- break;
- case PCI_SIZE_16:
- val_16 = value;
- out_le16((u16 *)((u8 *)>cfg_data + (offset & 2)), val_16);
- break;
- case PCI_SIZE_32:
- val_32 = value;
- out_le32(>cfg_data, val_32);
- break;
- }
+ out_le32(>cfg_data, pci_conv_size_to_32(0, value, offset, size));
return 0;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/3] pci: pcie_fsl: add support for none PCIe devices
add support for devices with compatible property: "fsl,mpc8540-pci". Unfortunately we can not change the property name, as already defined in linux. This patch superseeds patch [1]: http://patchwork.ozlabs.org/patch/1132418/ While working to integrate comments from Z.q. Hou to patch [1], I thought it may is the better idea, to use the already existing pcie_fsl driver and work in support for pci devices. Please comment! If it is no good idea, I have also a v2 of [1] with the comments from Z.q. Hou worked in ready to post... Travis build: https://travis-ci.org/hsdenx/u-boot-test/builds/595057579 (sheevaplug fails, but this is on discussion on list) Heiko Schocher (3): pci: pcie_fsl: use pci_conv_size_to_32() pci: pcie_fsl: reorder addr check function pci: pcie_fsl: add support for "fsl,mpc8540-pci" drivers/pci/pcie_fsl.c | 68 +++--- drivers/pci/pcie_fsl.h | 1 + 2 files changed, 32 insertions(+), 37 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] pci: pcie_fsl: reorder addr check function
reorder checks in fsl_pcie_addr_valid(). Check first stuff, we also can check when we use driver for PCI devices. Signed-off-by: Heiko Schocher --- drivers/pci/pcie_fsl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/pci/pcie_fsl.c b/drivers/pci/pcie_fsl.c index ada6e12e2f..05b2522dac 100644 --- a/drivers/pci/pcie_fsl.c +++ b/drivers/pci/pcie_fsl.c @@ -30,13 +30,13 @@ static int fsl_pcie_addr_valid(struct fsl_pcie *pcie, pci_dev_t bdf) if (PCI_BUS(bdf) < bus->seq) return -EINVAL; - if (PCI_BUS(bdf) > bus->seq && (!fsl_pcie_link_up(pcie) || pcie->mode)) + if (PCI_BUS(bdf) == (bus->seq + 1) && (PCI_DEV(bdf) > 0)) return -EINVAL; - if (PCI_BUS(bdf) == bus->seq && (PCI_DEV(bdf) > 0 || PCI_FUNC(bdf) > 0)) + if (PCI_BUS(bdf) > bus->seq && (!fsl_pcie_link_up(pcie) || pcie->mode)) return -EINVAL; - if (PCI_BUS(bdf) == (bus->seq + 1) && (PCI_DEV(bdf) > 0)) + if (PCI_BUS(bdf) == bus->seq && (PCI_DEV(bdf) > 0 || PCI_FUNC(bdf) > 0)) return -EINVAL; return 0; -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
Hello Michal, Am 08.10.2019 um 14:38 schrieb Michal Simek: On 08. 10. 19 14:35, Tom Rini wrote: On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: On 07. 10. 19 23:15, Tom Rini wrote: Hey all, It's release day and while we've once again had some last minute regression fixes, I feel things are as stable as they are likely to get so I've tagged and released v2019.07 and I would like to thank all of our contributor for their efforts. I expect v2019.10 :-) Oops. I did get the tag right this time at least. To repeat something I posted about in the previous -rc release, I've clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page that the "next" branch is expected to be rebased. Why? While I'm not sure if I want to apply things directly to the next branch and then give them some sort of automated testing, I do want to try and give changes some sort of build testing and similar sooner than I have, and that was at least a related problem. In terms of a changelog, git log --merges v2019.10-rc4..v2019.10 or git log --merges v2019.07..v2019.10 For this next release, one big concern I have but that I am hopeful we will be able to overcome is that we need to remove Python 2.7 support. Python 2.7 itself is end of lifed on January 1st, 2020. There's been a number of patches posted that get us a good part of the way there and I believe we can get the rest done before the deadline. The merge window is once again open and I plan to tag -rc1 on October 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. I am preparing pull request and I see that release has issue with sheevaplug board. 01: Prepare v2019.10 arm: + sheevaplug +u-boot.kwb exceeds file size limit: + limit: 524288 bytes + actual: 524632 bytes + excess: 344 bytes +make[1]: *** [u-boot.kwb] Error 1 +make[1]: *** Deleting file 'u-boot.kwb' +make: *** [sub-make] Error 2 There are also warnings about conversions to DM. Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me there's some /full/path string(s) somewhere that we should find and address. Thanks! It was catched by Travis on my branch. https://travis-ci.org/michalsimek/u-boot/jobs/594990410 But I was retesting it on my PC on tag too(log above). Sorry missed this thread yesterday ... Yes I detected this issue also here, as I wanted to send a pull request for ubi: https://lists.denx.de/pipermail/u-boot/2019-October/385848.html I asked Prafulla (listed as Board Maintainer) if there are plans to convert this board to DM or if it can be removed. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: imx8mm_evk: add board_mmc_get_env_dev
Add board_mmc_get_env_dev to correctly return devno for mmc env
Signed-off-by: Peng Fan
---
board/freescale/imx8mm_evk/imx8mm_evk.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/freescale/imx8mm_evk/imx8mm_evk.c
b/board/freescale/imx8mm_evk/imx8mm_evk.c
index 3706e1ec55..e4742338e3 100644
--- a/board/freescale/imx8mm_evk/imx8mm_evk.c
+++ b/board/freescale/imx8mm_evk/imx8mm_evk.c
@@ -19,6 +19,11 @@ int board_init(void)
return 0;
}
+int board_mmc_get_env_dev(int devno)
+{
+ return devno;
+}
+
int board_late_init(void)
{
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V3 27/27] imx: Add i.MX8MM EVK board support.
Hi Tim, > Subject: Re: [U-Boot] [PATCH V3 27/27] imx: Add i.MX8MM EVK board > support. > > On Mon, Aug 26, 2019 at 11:28 PM Peng Fan wrote: > > > > > diff --git a/board/freescale/imx8mm_evk/README > > b/board/freescale/imx8mm_evk/README > > new file mode 100644 > > index 00..a885bc5c97 > > --- /dev/null > > +++ b/board/freescale/imx8mm_evk/README > > Hi Peng, > > I'm working with an IMX8MM with U-Boot master + your v3 > i.MX8MM-support series. I have a few comments and questions below. I'll create a follow up patch to fix. > > > @@ -0,0 +1,37 @@ > > +U-Boot for the NXP i.MX8MM EVK board > > + > > +Quick Start > > +=== > > +- Build the ARM Trusted firmware binary > > +- Get ddr fimware > > +- Build U-Boot > > +- Boot > > + > > +Get and Build the ARM Trusted firmware > > +== > > +Note: srctree is U-Boot source directory Get ATF from: > > +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsou > > > +rce.codeaurora.org%2Fexternal%2Fimx%2Fimx-atfdata=02%7C01%7 > Cpeng > > > +.fan%40nxp.com%7C4fedc0bac43a4224ea7c08d74b555c69%7C686ea1d3bc > 2b4c6fa > > > +92cd99c5c301635%7C0%7C1%7C637060702303548820sdata=JxtdeK > Uu%2BRcZ > > +rggEEqvN9O75EzwrZXswQ0Fr6syIMx8%3Dreserved=0 > > +branch: imx_4.19.35_1.0.0 > > +$ make PLAT=imx8mm bl31 > > +$ cp build/imx8mm/release/bl31.bin $(srctree) > > + > > +Get the ddr and hdmi firmware > > There is no HDMI on i.MX8MM so remove 'hdmi' above Yes. > > > += > > +$ wget > > > +https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > > +.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-8.0.bin& > amp;dat > > > +a=02%7C01%7Cpeng.fan%40nxp.com%7C4fedc0bac43a4224ea7c08d74b55 > 5c69%7C6 > > > +86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637060702303548820 > sdat > > > +a=sguVqlRGiMw0FAARIQA%2FY%2Box%2FU8uWH%2B8rBwgc%2B7D8Ic%3 > Dreserv > > +ed=0 > > +$ chmod +x firmware-imx-8.0.bin > > +$ ./firmware-imx-8.0 > > +$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctree) > > typo: cp firmware-imx-8.0 Yes. > > > + > > +Build U-Boot > > + > > +$ export CROSS_COMPILE=aarch64-poky-linux- $ make > > +imx8mm_evk_defconfig $ export ATF_LOAD_ADDR=0x92 $ make > flash.bin > > Build fails due to default_serial_console undefined. Did you need to enable > DM_SERIAL? Using imx/master I do not met build failure. I not enable DM_SERIAL. > > After enabling DM_SERIAL build fails during image creation: > > MKIMAGE u-boot.itb > ./tools/imx8m_image.sh spl/u-boot-spl.cfgout 1 > 26061+0 records in > 26061+0 records out > 104244 bytes (104 kB, 102 KiB) copied, 0.0458568 s, 2.3 MB/s > MKIMAGE flash.bin > Not support no fit > arch/arm/mach-imx/Makefile:151: recipe for target 'flash.bin' failed > > If I hack using_fit=1 into tools/imx8mimage.c I can build flash.bin but it > does > not boot. > > Am I missing some additional necessary patches to tools? Please try imx/master. Thanks, Peng. > > Best Regards, > > Tim > > > + > > +Burn the flash.bin to MicroSD card offset 33KB $sudo dd if=flash.bin > > +of=/dev/sd[x] bs=1024 seek=33 > > + > > +Boot > > + > > +Set Boot switch to SD boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] RISC-V: Align boot image header with Linux.
On Wed, Oct 9, 2019 at 9:15 AM Atish Patra wrote:
>
nits: please remove the ending period in the commit summary
> The release linux boot image header in v5.3 is different from the
nits: Linux
> one present in U-boot. Align the header with the new version. The
nits: U-Boot
> changes in Linux are backward compatible. Previous u-boot releases
nits: U-Boot
> with older header will continue to work as well. As v5.3 kernel is
> the first one to support image header, there is no compatibility
> issue between new U-boot (with this patch) and older kernel.
nits: U-Boot
>
> Signed-off-by: Atish Patra
> ---
> arch/riscv/lib/image.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
> index d063beb7dfbe..41fca5939020 100644
> --- a/arch/riscv/lib/image.c
> +++ b/arch/riscv/lib/image.c
> @@ -14,20 +14,21 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> -/* ASCII version of "RISCV" defined in Linux kernel */
> -#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
> +/* ASCII version of "RSC\0x5" defined in Linux kernel */
> +#define LINUX_RISCV_IMAGE_MAGIC 0x05435352
>
> struct linux_image_h {
> uint32_tcode0; /* Executable code */
> uint32_tcode1; /* Executable code */
> uint64_ttext_offset;/* Image load offset */
> uint64_timage_size; /* Effective Image size */
> - uint64_tres1; /* reserved */
> + uint64_tflags; /* kernel flags(little endian) */
need have a space before (little endian)
> + uint32_tversion;/* version of the header */
> + uint32_tres1; /* reserved */
> uint64_tres2; /* reserved */
> uint64_tres3; /* reserved */
> - uint64_tmagic; /* Magic number */
> + uint32_tmagic; /* Magic number */
> uint32_tres4; /* reserved */
> - uint32_tres5; /* reserved */
> };
>
> int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] RISC-V: Align boot image header with Linux.
The release linux boot image header in v5.3 is different from the
one present in U-boot. Align the header with the new version. The
changes in Linux are backward compatible. Previous u-boot releases
with older header will continue to work as well. As v5.3 kernel is
the first one to support image header, there is no compatibility
issue between new U-boot (with this patch) and older kernel.
Signed-off-by: Atish Patra
---
arch/riscv/lib/image.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
index d063beb7dfbe..41fca5939020 100644
--- a/arch/riscv/lib/image.c
+++ b/arch/riscv/lib/image.c
@@ -14,20 +14,21 @@
DECLARE_GLOBAL_DATA_PTR;
-/* ASCII version of "RISCV" defined in Linux kernel */
-#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+/* ASCII version of "RSC\0x5" defined in Linux kernel */
+#define LINUX_RISCV_IMAGE_MAGIC 0x05435352
struct linux_image_h {
uint32_tcode0; /* Executable code */
uint32_tcode1; /* Executable code */
uint64_ttext_offset;/* Image load offset */
uint64_timage_size; /* Effective Image size */
- uint64_tres1; /* reserved */
+ uint64_tflags; /* kernel flags(little endian) */
+ uint32_tversion;/* version of the header */
+ uint32_tres1; /* reserved */
uint64_tres2; /* reserved */
uint64_tres3; /* reserved */
- uint64_tmagic; /* Magic number */
+ uint32_tmagic; /* Magic number */
uint32_tres4; /* reserved */
- uint32_tres5; /* reserved */
};
int booti_setup(ulong image, ulong *relocated_addr, ulong *size,
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] buildman: Perform tests in a temporary directory
On Mon, Oct 07, 2019 at 05:17:36PM -0400, Tom Rini wrote: > We may not always be able to write to the default output directory so > have a temporary directory for our output be created. > > Cc: Simon Glass > Reviewed-by: Stephen Warren > Suggested-by: Stephen Warren > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [gitlab-ci-runner][PATCH 2/2] Dockerfile: Update to current bionic tag
On Fri, Oct 04, 2019 at 11:32:35AM -0400, Tom Rini wrote: > As part of this we stop installing python-pytest (we enforce a specific > version via pip in tests) as well as python-coverage (this can and > should be done via pip as well). > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [gitlab-ci-runner][PATCH 1/2] Dockerfile: Switch to non-root user
On Fri, Oct 04, 2019 at 11:32:34AM -0400, Tom Rini wrote: > Add a 'uboot' user / group, allow them sudo access and make use of them > in the container. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] gitlab-ci: Switch to Ubuntu 18.04 image
On Fri, Oct 04, 2019 at 12:12:54PM -0400, Tom Rini wrote: > In order to run all filesystem tests we need to have newer ext4 tools, > move up to Ubuntu 18.04 'bionic' for our base. We need to change > slightly how we invoke the provided grub-mkimage. This will also make > future python3 work easier. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 3/3] kconfiglib: Update to the 12.14.0 release
On Fri, Sep 20, 2019 at 05:42:09PM -0400, Tom Rini wrote: > A large number of changes have happened upstream since our last sync > which was to 375506d. The reason to do the upgrade at this point is for > improved Python 3 support. > > As part of this upgrade we need to update moveconfig.py and > genboardscfg.py the current API. This is: > - Change "kconfiglib.Config" calls to "kconfiglib.Kconfig" > - Change get_symbol() calls to syms.get(). > - Change get_value() to str_value. > > Cc: Masahiro Yamada > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] gitlab-ci: Have buildman use /tmp for output
On Fri, Oct 04, 2019 at 12:12:53PM -0400, Tom Rini wrote: > When running as another user we might not be able to use '..' for > certain directories and this is the default for buildman. Specify an > output directory instead. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 2/3] genboardscfg.py: Remove "warnings" print section
On Fri, Sep 20, 2019 at 05:42:08PM -0400, Tom Rini wrote: > We tell kconfiglib to not print any warnings to us so drop this code as > it will be unused. > > Cc: Masahiro Yamada > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/3] genboardscfg.py: Convert to Python 3
On Fri, Sep 20, 2019 at 05:42:07PM -0400, Tom Rini wrote: > Convert this tool to requiring Python 3. The bulk of this is done with > the 2to3 tool In addition, we need to use the '//' operator to have our > division result return an int rather than a float and ensure that we use > UTF-8 when reading/writing files. > > Cc: Masahiro Yamada > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] travis.yml: Switch to bionic for the host distribution
On Tue, Oct 08, 2019 at 12:10:25PM -0400, Tom Rini wrote: > To match what we're doing in GitLab, move to 'bionic' for these builds > as well. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] IS_ERR_VALUE failing on socfpga gen5
In a series I'm currently preparing, I've stumbled accross the fact that IS_ERR_VALUE() doesn't reliably work on socfpga SPL as the onchip SRAM begins at 0x and the heap is at the end of the 32 bit range. Being like that, the current test for error (value >= -4095) which equals 'value >= 0xf001' would require us to waste the last 4K of that memory, which is not an option when it comes to using DM in SPL... Now on this platform, I'm sure I could find a range of 4096 bytes to use as invalid pointer range, but the question is: how do I integrate that into U-Boot in a clean manner? Would it be acceptable to change the error headers imported from Linux or would I have to through the hassle of changing Linux first? Or does anyone have a better idea to allow using the last 4K for heap? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: dts: imx6q-logicpd: Keep GEN3V3 alive
On Tue, Oct 8, 2019 at 1:40 PM Fabio Estevam wrote: > > Hi Adam, > > On Tue, Oct 8, 2019 at 3:32 PM Adam Ford wrote: > > > > The schematic shows Gen3V3 is driven by sw2_reg on the pfuze100 > > PMIC. Linux doesn't appear to have an issue keeping this rail > > up, but U-Boot shuts it down for some reason. > > > > This patch sets 'regulator-always-on' for sw2_reg to keept this > > rail powered. > > Why does U-Boot shuts down sw2_reg? I don't know. > > sw2_reg has a consumer: , so it should keep turned on. > I would agree. > Or you don't use usdhc1 port in U-Boot? I do use usdhc1 powered from that rail, but if I enable I2C, the MMC initialization dies and the board hangs. It seems like a bug to me, but I'll look into that later. At least for now, I can use this as a work-around for keeping the board alive. adam > > Just want to understand this problem better. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] arm: remove the H2200 board
U-Boot cannot be built for h2200_defconfig with CONFIG_DM=y.
The maintainer Lukasz Dalek suggested to remove the board.
https://lists.denx.de/pipermail/u-boot/2019-August/380685.html
Cc: Lukasz Dalek
Signed-off-by: Heinrich Schuchardt
---
arch/arm/Kconfig | 4 --
board/h2200/Kconfig| 9 ---
board/h2200/MAINTAINERS| 6 --
board/h2200/Makefile | 12
board/h2200/h2200-header.S | 14
board/h2200/h2200.c| 73 -
configs/h2200_defconfig| 38 ---
include/configs/h2200.h| 128 -
8 files changed, 284 deletions(-)
delete mode 100644 board/h2200/Kconfig
delete mode 100644 board/h2200/MAINTAINERS
delete mode 100644 board/h2200/Makefile
delete mode 100644 board/h2200/h2200-header.S
delete mode 100644 board/h2200/h2200.c
delete mode 100644 configs/h2200_defconfig
delete mode 100644 include/configs/h2200.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3b0e315061..416d0fdb75 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1479,9 +1479,6 @@ config TARGET_LS1046AFRWY
The LS1046A Freeway Board (FRWY) is a high-performance
development platform that supports the QorIQ LS1046A
Layerscape Architecture processor.
-config TARGET_H2200
- bool "Support h2200"
- select CPU_PXA
config TARGET_COLIBRI_PXA270
bool "Support colibri_pxa270"
@@ -1789,7 +1786,6 @@ source "board/freescale/mx35pdk/Kconfig"
source "board/freescale/s32v234evb/Kconfig"
source "board/grinn/chiliboard/Kconfig"
source "board/gumstix/pepper/Kconfig"
-source "board/h2200/Kconfig"
source "board/hisilicon/hikey/Kconfig"
source "board/hisilicon/hikey960/Kconfig"
source "board/hisilicon/poplar/Kconfig"
diff --git a/board/h2200/Kconfig b/board/h2200/Kconfig
deleted file mode 100644
index c0e0c1e763..00
--- a/board/h2200/Kconfig
+++ /dev/null
@@ -1,9 +0,0 @@
-if TARGET_H2200
-
-config SYS_BOARD
- default "h2200"
-
-config SYS_CONFIG_NAME
- default "h2200"
-
-endif
diff --git a/board/h2200/MAINTAINERS b/board/h2200/MAINTAINERS
deleted file mode 100644
index b66ff515cf..00
--- a/board/h2200/MAINTAINERS
+++ /dev/null
@@ -1,6 +0,0 @@
-H2200 BOARD
-M: Lukasz Dalek
-S: Maintained
-F: board/h2200/
-F: include/configs/h2200.h
-F: configs/h2200_defconfig
diff --git a/board/h2200/Makefile b/board/h2200/Makefile
deleted file mode 100644
index 690b766178..00
--- a/board/h2200/Makefile
+++ /dev/null
@@ -1,12 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# h2200 Support
-#
-# Copyright (C) 2012 Lukasz Dalek
-
-obj-y := h2200.o
-
-extra-y := h2200-header.bin
-
-$(obj)/h2200-header.bin: $(obj)/h2200-header.o
- $(OBJCOPY) -O binary $< $@
diff --git a/board/h2200/h2200-header.S b/board/h2200/h2200-header.S
deleted file mode 100644
index be8b7fb923..00
--- a/board/h2200/h2200-header.S
+++ /dev/null
@@ -1,14 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
-/*
- * iPAQ h2200 header
- *
- * Copyright (C) 2012 Lukasz Dalek
- */
-
- .word 0xea0003fe /* b 0x1000 */
-
- .org 0x40
- .ascii "ECEC"
-
- .org 0x1000 - 1
- .byte 0x0
diff --git a/board/h2200/h2200.c b/board/h2200/h2200.c
deleted file mode 100644
index e1b7b2ce8a..00
--- a/board/h2200/h2200.c
+++ /dev/null
@@ -1,73 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * iPAQ h2200 board configuration
- *
- * Copyright (C) 2012 Lukasz Dalek
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-DECLARE_GLOBAL_DATA_PTR;
-
-int board_eth_init(bd_t *bis)
-{
- usb_eth_initialize(bis);
- return 0;
-}
-
-void reset_cpu(ulong ignore)
-{
- /* Enable VLIO interface on Hamcop */
- writeb(0x1, 0x4000);
-
- /* Reset board (cold reset) */
- writeb(0xff, 0x4002);
-}
-
-int board_init(void)
-{
- /* We have RAM, disable cache */
- dcache_disable();
- icache_disable();
-
- gd->bd->bi_arch_number = MACH_TYPE_H2200;
-
- /* adress of boot parameters */
- gd->bd->bi_boot_params = 0xa100;
-
- /* Let host see that device is disconnected */
- udc_disconnect();
- mdelay(500);
-
- return 0;
-}
-
-int dram_init(void)
-{
- /*
-* Everything except MSC0 was already set up by
-* 1st stage bootloader.
-*
-* This setting enables access to companion chip.
-*/
- clrsetbits_le32(MSC0, 0x, CONFIG_SYS_MSC0_VAL);
- gd->ram_size = CONFIG_SYS_SDRAM_SIZE;
- return 0;
-}
-
-#ifdef CONFIG_USB_GADGET_PXA2XX
-int board_usb_init(int index, enum usb_init_type init)
-{
- return 0;
-}
-
-int board_usb_cleanup(int index, enum usb_init_type init)
-{
- return 0;
-}
-#endif
diff --git a/configs/h2200_defconfig b/configs/h2200_defconfig
deleted file mode 100644
index 72bb4d3f70..00
--- a/configs/h2200_defconfig
+++ /dev/null
@@ -1,38 +0,0 @@
-CONFIG_ARM=y
Re: [U-Boot] [PATCH 1/2] ARM: dts: imx6q-logicpd: Keep GEN3V3 alive
Hi Adam, On Tue, Oct 8, 2019 at 3:32 PM Adam Ford wrote: > > The schematic shows Gen3V3 is driven by sw2_reg on the pfuze100 > PMIC. Linux doesn't appear to have an issue keeping this rail > up, but U-Boot shuts it down for some reason. > > This patch sets 'regulator-always-on' for sw2_reg to keept this > rail powered. Why does U-Boot shuts down sw2_reg? sw2_reg has a consumer: , so it should keep turned on. Or you don't use usdhc1 port in U-Boot? Just want to understand this problem better. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: imx6q_logic: Enable I2C for PMIC functionality
The pfuze100 is the PMIC connected to the I2C bus. Currently, the I2C driver is disabled which prevents the PMIC from operating. This patch enables the I2C which also enables the PMIC in U-Boot. This also keeps the PMIC and I2C disabled in SPL due to size constraints of SPL. Signed-off-by: Adam Ford diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig index ec14b8eaf6..22ecec3be3 100644 --- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -22,7 +22,6 @@ CONFIG_SPL_RAW_IMAGE_SUPPORT=y CONFIG_SPL_SEPARATE_BSS=y # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set CONFIG_SPL_DMA_SUPPORT=y -CONFIG_SPL_I2C_SUPPORT=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_OS_BOOT=y CONFIG_SPL_PAYLOAD="u-boot.img" @@ -64,6 +63,7 @@ CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_OF_TRANSLATE=y CONFIG_PCF8575_GPIO=y +CONFIG_SYS_I2C_MXC=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_FSL_USDHC=y @@ -78,6 +78,7 @@ CONFIG_FEC_MXC=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_PINCTRL_IMX6=y +# CONFIG_SPL_PMIC_CHILDREN is not set CONFIG_DM_PMIC_PFUZE100=y CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_PFUZE100=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: dts: imx6q-logicpd: Keep GEN3V3 alive
The schematic shows Gen3V3 is driven by sw2_reg on the pfuze100
PMIC. Linux doesn't appear to have an issue keeping this rail
up, but U-Boot shuts it down for some reason.
This patch sets 'regulator-always-on' for sw2_reg to keept this
rail powered.
Signed-off-by: Adam Ford
diff --git a/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
b/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
index 625bed8f7d..93e92aab81 100644
--- a/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
+++ b/arch/arm/dts/imx6q-logicpd-u-boot.dtsi
@@ -16,3 +16,7 @@
{
u-boot,dm-spl;
};
+
+_reg {
+ regulator-always-on;
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] Makefile: Skip symbolic links to files for cscope
cscope complains that it can't find files that appears to be symbolic links cscope: cannot find file tools/binman/test/u_boot_binman_syms_bad.c cscope: cannot find file tools/version.h `find -L` tests properties, but name, and cscope can't cope with symbolic links (a lot of bugs in upstream were simple closed as kinda invalid). To work around the problem, exclude symbolic links from the cscope.files. Note, it's done in two pass to speed up the process (`-exec realpath ...` approach is not portable and introduces a 3x delay). Signed-off-by: Andy Shevchenko --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 54da5cd51c..968a70885b 100644 --- a/Makefile +++ b/Makefile @@ -1793,6 +1793,9 @@ etags: cscope: $(FIND) $(FINDFLAGS) $(TAG_SUBDIRS) -name '*.[chS]' -print > \ cscope.files + @find $(TAG_SUBDIRS) -name '*.[chS]' -type l -print | \ + grep -xvf - cscope.files > cscope.files.no-symlinks; \ + mv cscope.files.no-symlinks cscope.files cscope -b -q -k SYSTEM_MAP = \ -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rockchip: dts: rk3328: rock64: Add same-as-spl order
rk3328 can use same-as-spl option so next loaders are loaded from the same
medium.
Add the boot order in the rock64 dts otherwise booting from sdcard
will result in u-boot looking into the eMMC.
Signed-off-by: Emmanuel Vadot
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 1d441f7124..e5946d2d2d 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -5,6 +5,11 @@
#include "rk3328-u-boot.dtsi"
#include "rk3328-sdram-lpddr3-1600.dtsi"
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+};
_host0_xhci {
status = "okay";
--
2.22.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2] usb: ehci-mx6: Fix bus enumeration for DM case
Hi Marek,
On Mon, Jun 24, 2019 at 8:08 PM Marek Vasut wrote:
>
> The EHCI iMX6 driver is only partly converted to DT probing and
> still uses a tremendous amount of hard-coded addresses. Worse,
> the driver uses hard-coded SoC-model-specific base addresses, which
> are derived from values protected by SoC-specific macros, hence the
> driver is also compiled for a specific SoC model. Even worse, the
> driver depends on specific sequential indexing of the controllers,
> from which it derives offsets in the PHY and ANATOP register sets.
>
> However, when the driver is probed from DT, the indexing is not
> correct. In fact, each controller has index 0. This patch derives
> the index for DT probing case from the controller base addresses,
> which is not the way this should be done, however it is the least
> intrusive approach, favorable this close to release.
>
> The necessary steps to convert this driver fully to DT probing are
> described inside the patch, however this should be done in the next
> release and depends on iMX clock driver patches.
>
> Signed-off-by: Marek Vasut
> Cc: Abel Vesa
> Cc: Adam Ford
> Cc: Fabio Estevam
> Cc: Ludwig Zenz
> Cc: Lukasz Majewski
> Cc: Peng Fan
> Cc: Stefano Babic
> Cc: Vagrant Cascadian
> ---
> V2: Derive the controller index from it's base address
> ---
> drivers/usb/host/ehci-mx6.c | 37 +
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 33abfeada0..e9e6ed596d 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -503,6 +503,42 @@ static int ehci_usb_ofdata_to_platdata(struct udevice
> *dev)
> return 0;
> }
>
> +static int ehci_usb_bind(struct udevice *dev)
> +{
> + /*
> +* TODO:
> +* This driver is only partly converted to DT probing and still uses
> +* a tremendous amount of hard-coded addresses. To make things worse,
> +* the driver depends on specific sequential indexing of controllers,
> +* from which it derives offsets in the PHY and ANATOP register sets.
> +*
> +* Here we attempt to calculate these indexes from DT information as
> +* well as we can. The USB controllers on all existing iMX6/iMX7 SoCs
> +* are placed next to each other, at addresses incremented by 0x200.
> +* Thus, the index is derived from the multiple of 0x200 offset from
> +* the first controller address.
I'm afraid I'm a bit late, as the patch is already applied but
this statement is not true for iMX7S/iMX7D SoCs.
If you look into arch/arm/dts/imx7s.dtsi and
arch/arm/dts/imx7d.dtsi, you'll find that
addresses are not incremented by 0x200:
usbotg1: usb@30b1 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
reg = <0x30b1 0x200>;
usbotg2: usb@30b2 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
reg = <0x30b2 0x200>;
^^^
usbh: usb@30b3 {
compatible = "fsl,imx7d-usb", "fsl,imx27-usb";
reg = <0x30b3 0x200>;
^^^
Which causes probing issues:
Colibri iMX7 # usb start
starting USB...
Bus usb@30b1: USB EHCI 1.00
Bus usb@30b2: probe failed, error -22
scanning bus usb@30b1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
> +*
> +* However, to complete conversion of this driver to DT probing, the
> +* following has to be done:
> +* - DM clock framework support for iMX must be implemented
> +* - usb_power_config() has to be converted to clock framework
> +* -> Thus, the ad-hoc "index" variable goes away.
> +* - USB PHY handling has to be factored out into separate driver
> +* -> Thus, the ad-hoc "index" variable goes away from the PHY
> +* code, the PHY driver must parse it's address from DT. This
> +* USB driver must find the PHY driver via DT phandle.
> +* -> usb_power_config() shall be moved to PHY driver
> +* With these changes in place, the ad-hoc indexing goes away and
> +* the driver is fully converted to DT probing.
> +*/
> + fdt_size_t size;
> + fdt_addr_t addr = devfdt_get_addr_size_index(dev, 0, );
> +
> + dev->req_seq = (addr - USB_BASE_ADDR) / size;
> +
> + return 0;
> +}
> +
> static int ehci_usb_probe(struct udevice *dev)
> {
> struct usb_platdata *plat = dev_get_platdata(dev);
> @@ -564,6 +600,7 @@ U_BOOT_DRIVER(usb_mx6) = {
> .id = UCLASS_USB,
> .of_match = mx6_usb_ids,
> .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
> + .bind = ehci_usb_bind,
> .probe = ehci_usb_probe,
> .remove = ehci_deregister,
> .ops= _usb_ops,
> --
> 2.20.1
>
> ___
> U-Boot mailing list
>
Re: [U-Boot] [PATCH 4/8] ARM: socfpga: arria10: Add generic handoff devicetree include
On Mon, 2019-10-07 at 16:45 +0200, Simon Goldschmidt wrote:
> There's something wrong with your mailer: indentation of replies doesn't
> seemto work. It gets kind of hard to read who wrote what...
> On Mon, Oct 7, 2019 at 4:34 PM Dalon L Westergreen<
> dalon.westergr...@linux.intel.com> wrote:
> > On Sun, 2019-10-06 at 20:05 +0200, Simon Goldschmidt wrote:
> > Am 06.10.2019 um 19:44 schrieb Dalon L Westergreen:
> > On Sun, 2019-10-06 at 15:44 +0200, Marek Vasut wrote:
> > On 10/6/19 1:19 AM, Dalon L Westergreen wrote:
> > On Sat, 2019-10-05 at 01:51 +0200, Marek Vasut wrote:
> > On 10/5/19 12:30 AM, Dalon Westergreen wrote:
> > From: Dalon Westergreen <
> > dalon.westergr...@intel.com
> >
> >
> > > dalon.westergr...@intel.com
> >
> >
> > Generic handoff devicetree include uses a header generated bythe qts-filter-
> > a10.sh script in mach-socfpga. The scriptcreates the header based on design
> > specific implementationsfor clock and pinmux configurations.
> >
> > [...]
> > diff --git a/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria10_handoff_u-boot.dtsi
> >
> > [...]
> > - clock_manager@0xffd04000 {+ clkmgr@0xffd04000 {+ compatible =
> > "altr,socfpga-a10-clk-init";+ reg = <0xffd04000 0x0200>;+
> > reg-names = "soc_clock_manager_OCP_SLV"; u-boot,dm-pre-
> > reloc; mainpll {+ vco0-psrc =
> > ;+ vco1-denom =
> > ;+ vco1-numer =
> > ;
> >
> > But these bits are board-specific , they shouldn't be in common DT.
> >
> > This common dtsi requires that the top level u-boot.dtsi include the board
> > specific header. The format
> > and #define names are in fact common.
> >
> > OK, I now see what you're doing here. Can you explain that in a bit more
> > detail in the commit message ?
> >
> > Basically socfpga_board.h is included socfpga_board.dts , and then the
> > preprocessor correctly expands the values from socfpga_board.h in the
> > socfpga_board.dts , so this works for multiple boards too ?
> >
> > Exactly. Will add more detail in the commit message, and slim down the
> > included clocks in
> > the u-boot.dtsi
> >
> > I'm (still) working on a series to bring gen5 completely to devicetree,
> > so that the 'qts' directories can be removed. I chose a different
> > approach however, in that I generated everything into a '-handoff.dtsi'
> > file (*). I'd be happy if we could find a common mechanism for all
> > socfpga sub-archs. How does S10/Agilex handle this?
> >
> > (*): Gen5 has the downside that we're low on memory in SPL (regarding
> > DM), and as we require large binary arrays there, I chose to encode the
> > binary blob arrays in host byte order so that they could be used
> > in-place instead of copying them from BE (dtb) to LE (stack/heap). Maybe
> > that doesn't fit A10/S10/Agilex anyway?
> >
> > Can you share your patch set with me, privately or otherwise, just so we can
> > take a similarapproach in the devicetree?
>
> Give me a week max. and I'll send the series as RFC.
> > Also, have you looked at the bsp-editor python source that generates the
> > "generated" filesfrom the bsp-editor?
> > 19.1std/647/linux64/ip/altera/preloader/scripts
>
> No, I mainly focused on the U-Boot part for now. I just wrote a C programthat
> did the conversion from 'official generated' files to DTS...
> > I am hoping to replace these with a script included in the u-boot source.
> > iocsr.py doesa bunch of binary parsing.
>
> Right, a direct conversion from compilation output to U-Boot would be
> better.However, that would require Intel to keep that output consistent!
It should be consistent at this point. i would not worry about that.
> Regards,Simon
> > --dalon
> >
> > Regards,
> > Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARC: [plat-axs101]: migrate to DM_MMC
Signed-off-by: Eugeniy Paltsev --- configs/axs101_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/axs101_defconfig b/configs/axs101_defconfig index 0bfb532fc74..38c8ae998fd 100644 --- a/configs/axs101_defconfig +++ b/configs/axs101_defconfig @@ -35,7 +35,9 @@ CONFIG_DM=y CONFIG_DM_GPIO=y CONFIG_HSDK_CREG_GPIO=y CONFIG_MMC=y +CONFIG_DM_MMC=y CONFIG_MMC_DW=y +CONFIG_MMC_DW_SNPS=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARC: HSDK: introduce reset driver
Introduce reset driver for Synopsys ARC HSDK SoC
Signed-off-by: Eugeniy Paltsev
---
drivers/reset/Kconfig | 7 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-hsdk.c | 116
include/dt-bindings/reset/snps,hsdk-reset.h | 17 +++
4 files changed, 141 insertions(+)
create mode 100644 drivers/reset/reset-hsdk.c
create mode 100644 include/dt-bindings/reset/snps,hsdk-reset.h
diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 6ec6f39c85f..3071af5f692 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -91,6 +91,13 @@ config RESET_ROCKCHIP
though is that some reset signals, like I2C or MISC reset multiple
devices.
+config RESET_HSDK
+ bool "Synopsys HSDK Reset Driver"
+ depends on DM_RESET && TARGET_HSDK
+ default y
+ help
+ This enables the reset controller driver for HSDK board.
+
config RESET_MESON
bool "Reset controller driver for Amlogic Meson SoCs"
depends on DM_RESET && ARCH_MESON
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 7fec75bb492..1c4401c7f2b 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_STM32_RESET) += stm32-reset.o
obj-$(CONFIG_TEGRA_CAR_RESET) += tegra-car-reset.o
obj-$(CONFIG_TEGRA186_RESET) += tegra186-reset.o
obj-$(CONFIG_RESET_TI_SCI) += reset-ti-sci.o
+obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
obj-$(CONFIG_AST2500_RESET) += ast2500-reset.o
diff --git a/drivers/reset/reset-hsdk.c b/drivers/reset/reset-hsdk.c
new file mode 100644
index 000..213d6c87be1
--- /dev/null
+++ b/drivers/reset/reset-hsdk.c
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * HSDK SoC Reset Controller driver
+ *
+ * Copyright (C) 2019 Synopsys, Inc. All rights reserved.
+ * Author: Eugeniy Paltsev
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct hsdk_rst {
+ void __iomem*regs_ctl;
+ void __iomem*regs_rst;
+};
+
+static const u32 rst_map[] = {
+ BIT(16), /* APB_RST */
+ BIT(17), /* AXI_RST */
+ BIT(18), /* ETH_RST */
+ BIT(19), /* USB_RST */
+ BIT(20), /* SDIO_RST */
+ BIT(21), /* HDMI_RST */
+ BIT(22), /* GFX_RST */
+ BIT(25), /* DMAC_RST */
+ BIT(31), /* EBI_RST */
+};
+
+#define HSDK_MAX_RESETSARRAY_SIZE(rst_map)
+
+#define CGU_SYS_RST_CTRL 0x0
+#define CGU_IP_SW_RESET0x0
+#define CGU_IP_SW_RESET_DELAY_SHIFT16
+#define CGU_IP_SW_RESET_DELAY_MASK GENMASK(31, CGU_IP_SW_RESET_DELAY_SHIFT)
+#define CGU_IP_SW_RESET_DELAY 0
+#define CGU_IP_SW_RESET_RESET BIT(0)
+#define SW_RESET_TIMEOUT 1
+
+static void hsdk_reset_config(struct hsdk_rst *rst, unsigned long id)
+{
+ writel(rst_map[id], rst->regs_ctl + CGU_SYS_RST_CTRL);
+}
+
+static int hsdk_reset_do(struct hsdk_rst *rst)
+{
+ u32 reg;
+
+ reg = readl(rst->regs_rst + CGU_IP_SW_RESET);
+ reg &= ~CGU_IP_SW_RESET_DELAY_MASK;
+ reg |= CGU_IP_SW_RESET_DELAY << CGU_IP_SW_RESET_DELAY_SHIFT;
+ reg |= CGU_IP_SW_RESET_RESET;
+ writel(reg, rst->regs_rst + CGU_IP_SW_RESET);
+
+ /* wait till reset bit is back to 0 */
+ return readl_poll_timeout(rst->regs_rst + CGU_IP_SW_RESET, reg,
+ !(reg & CGU_IP_SW_RESET_RESET), SW_RESET_TIMEOUT);
+}
+
+static int hsdk_reset_reset(struct reset_ctl *rst_ctl)
+{
+ struct udevice *dev = rst_ctl->dev;
+ struct hsdk_rst *rst = dev_get_priv(dev);
+
+ if (rst_ctl->id >= HSDK_MAX_RESETS)
+ return -EINVAL;
+
+ debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, rst_ctl,
+ rst_ctl->dev, rst_ctl->id);
+
+ hsdk_reset_config(rst, rst_ctl->id);
+ return hsdk_reset_do(rst);
+}
+
+static int hsdk_reset_noop(struct reset_ctl *rst_ctl)
+{
+ return 0;
+}
+
+static const struct reset_ops hsdk_reset_ops = {
+ .request= hsdk_reset_noop,
+ .free = hsdk_reset_noop,
+ .rst_assert = hsdk_reset_noop,
+ .rst_deassert = hsdk_reset_reset,
+};
+
+static const struct udevice_id hsdk_reset_dt_match[] = {
+ { .compatible = "snps,hsdk-reset" },
+ { },
+};
+
+static int hsdk_reset_probe(struct udevice *dev)
+{
+ struct hsdk_rst *rst = dev_get_priv(dev);
+
+ rst->regs_ctl = dev_remap_addr_index(dev, 0);
+ if (!rst->regs_ctl)
+ return -EINVAL;
+
+ rst->regs_rst = dev_remap_addr_index(dev, 1);
+ if (!rst->regs_rst)
+ return -EINVAL;
+
+ return 0;
+}
+
+U_BOOT_DRIVER(hsdk_reset) = {
+ .name = "hsdk-reset",
+ .id = UCLASS_RESET,
+ .of_match = hsdk_reset_dt_match,
+ .ops = _reset_ops,
+ .probe =
[U-Boot] [PATCH 2/2] MAINTAINERS: add info about ARC HSDK reset driver
Signed-off-by: Eugeniy Paltsev --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index e752e4b3de0..4cecbb6d134 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -94,6 +94,13 @@ L: uboot-snps-...@synopsys.com F: doc/device-tree-bindings/gpio/snps,creg-gpio.txt F: drivers/gpio/hsdk-creg-gpio.c +ARC HSDK RESET +M: Eugeniy Paltsev +S: Maintained +L: uboot-snps-...@synopsys.com +F: include/dt-bindings/reset/snps,hsdk-reset.h +F: drivers/reset/reset-hsdk.c + ARC SYNOPSYS DW MMC EXTENSIONS M: Eugeniy Paltsev S: Maintained -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] arm: dts: ti: sync cpsw/mdio/phy with latest linux 1 - drop phy_id
Hi Tom, All, On 04/09/2019 11:38, Lokesh Vutla wrote: On 31/08/19 1:00 PM, Grygorii Strashko wrote: Synchronize CPSW/MDIO/PHY DT nodes with latest linux - replace deprecated phy_id property with phy-handle. For the series: Reviewed-by: Lokesh Vutla Are there anything else I need to do to have this merged? Sry, for impatience. -- Best regards, grygorii ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] travis.yml: Switch to bionic for the host distribution
To match what we're doing in GitLab, move to 'bionic' for these builds as well. Signed-off-by: Tom Rini --- .travis.yml | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/.travis.yml b/.travis.yml index 0ce09e35b7c6..c48b711659e9 100644 --- a/.travis.yml +++ b/.travis.yml @@ -4,7 +4,7 @@ # build U-Boot on Travis CI - https://travis-ci.org/ sudo: required -dist: xenial +dist: bionic language: c @@ -12,7 +12,7 @@ addons: apt: sources: - ubuntu-toolchain-r-test -- llvm-toolchain-xenial-7 +- llvm-toolchain-bionic-7 packages: - cppcheck - sloccount @@ -52,12 +52,13 @@ install: - pip install pytest==2.8.7 - pip install python-subunit - pip install pyelftools - - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd - - grub-mkimage -o ~/grub_x64.efi -O x86_64-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd + - grub-mkimage --prefix="" -o ~/grub_x86.efi -O i386-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd + - grub-mkimage --prefix="" -o ~/grub_x64.efi -O x86_64-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd - mkdir ~/grub2-arm - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di ) - mkdir ~/grub2-arm64 - ( cd ~/grub2-arm64; wget -O - http://download.opensuse.org/ports/aarch64/distribution/leap/42.2/repo/oss/suse/aarch64/grub2-arm64-efi-2.02~beta2-87.1.aarch64.rpm | rpm2cpio | cpio -di ) + - wget http://mirrors.kernel.org/ubuntu/pool/main/m/mpfr4/libmpfr4_3.1.4-1_amd64.deb && sudo dpkg -i libmpfr4_3.1.4-1_amd64.deb && rm libmpfr4_3.1.4-1_amd64.deb env: global: -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] buildman: Perform tests in a temporary directory
On 10/7/19 3:17 PM, Tom Rini wrote: We may not always be able to write to the default output directory so have a temporary directory for our output be created. Reviewed-by: Stephen Warren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arc: emsdp/iotdk: Switch to DM_MMC
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.
Signed-off-by: Alexey Brodkin
---
Changes v1 -> v2:
* FIFO size on IoTDK is 128 bytes as compared to 256 on EM SDP.
That gave us timeouts on data read with some cards. Fixed now.
arch/arc/dts/emsdp.dts | 23 ++
arch/arc/dts/iot_devkit.dts| 22 ++
board/synopsys/emsdp/emsdp.c | 29 ---
board/synopsys/iot_devkit/iot_devkit.c | 32 --
configs/emsdp_defconfig| 2 ++
configs/iot_devkit_defconfig | 2 ++
6 files changed, 49 insertions(+), 61 deletions(-)
diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts
index d307b95d8e..77362354d5 100644
--- a/arch/arc/dts/emsdp.dts
+++ b/arch/arc/dts/emsdp.dts
@@ -32,4 +32,27 @@
reg-shift = <2>;
reg-io-width = <4>;
};
+
+ mmcclk_biu: mmcclk-biu {
+ compatible = "fixed-clock";
+ clock-frequency = <1>;
+ #clock-cells = <0>;
+ };
+
+ mmcclk_ciu: mmcclk-ciu {
+ compatible = "fixed-clock";
+ clock-frequency = <1>;
+ #clock-cells = <0>;
+ };
+
+ mmc: mmc0@f001 {
+ compatible = "snps,dw-mshc";
+ reg = <0xf001 0x400>;
+ bus-width = <4>;
+ fifo-depth = <256>;
+ clocks = <_biu>, <_ciu>;
+ clock-names = "biu", "ciu";
+ max-frequency = <2500>;
+ };
+
};
diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts
index ebf5a950f0..c0173fa5ab 100644
--- a/arch/arc/dts/iot_devkit.dts
+++ b/arch/arc/dts/iot_devkit.dts
@@ -42,4 +42,26 @@
compatible = "nop-phy";
#phy-cells = <0>;
};
+
+ mmcclk_biu: mmcclk-biu {
+ compatible = "fixed-clock";
+ clock-frequency = <5000>;
+ #clock-cells = <0>;
+ };
+
+ mmcclk_ciu: mmcclk-ciu {
+ compatible = "fixed-clock";
+ clock-frequency = <5000>;
+ #clock-cells = <0>;
+ };
+
+ mmc: mmc0@f000b000 {
+ compatible = "snps,dw-mshc";
+ reg = <0xf000b000 0x400>;
+ bus-width = <4>;
+ fifo-depth = <128>;
+ clocks = <_biu>, <_ciu>;
+ clock-names = "biu", "ciu";
+ max-frequency = <2500>;
+ };
};
diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index 7a3fd5b7f2..5ba9f862e1 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -85,35 +85,6 @@ int board_early_init_r(void)
return 0;
}
-int board_mmc_init(bd_t *bis)
-{
- struct dwmci_host *host = NULL;
-
- host = malloc(sizeof(struct dwmci_host));
- if (!host) {
- printf("dwmci_host malloc fail!\n");
- return 1;
- }
-
- memset(host, 0, sizeof(struct dwmci_host));
- host->name = "Synopsys Mobile storage";
- host->ioaddr = SDIO_BASE;
- host->buswidth = 4;
- host->dev_index = 0;
- host->bus_hz = 5000;
-
- add_dwmci(host, host->bus_hz / 2, 40);
-
- return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct dwmci_host *host = mmc->priv;
-
- return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
#define CREG_BASE 0xF0001000
#define CREG_BOOT (void *)(CREG_BASE + 0x0FF0)
#define CREG_IP_SW_RESET (void *)(CREG_BASE + 0x0FF0)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 8424e09bd3..9dbdc128f8 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -145,38 +145,6 @@ int mach_cpu_init(void)
return set_cpu_freq(gd->cpu_clk);
}
-#define ARC_PERIPHERAL_BASE0xF000
-#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xB000)
-
-int board_mmc_init(bd_t *bis)
-{
- struct dwmci_host *host = NULL;
-
- host = malloc(sizeof(struct dwmci_host));
- if (!host) {
- printf("dwmci_host malloc fail!\n");
- return -ENOMEM;
- }
-
- memset(host, 0, sizeof(struct dwmci_host));
- host->name = "Synopsys Mobile storage";
- host->ioaddr = (void *)SDIO_BASE;
- host->buswidth = 4;
- host->dev_index = 0;
- host->bus_hz = 5000;
-
- add_dwmci(host, host->bus_hz / 2, 40);
-
- return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct dwmci_host *host = mmc->priv;
-
- return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
#define IOTDK_RESET_SEQ0x55AA6699
void reset_cpu(ulong addr)
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 1eca23fa95..09fe388e58 100644
---
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 04:36:08PM +0100, Peter Robinson wrote: > > It's release day and while we've once again had some last minute > > regression fixes, I feel things are as stable as they are likely to get > > so I've tagged and released v2019.07 and I would like to thank all of > > our contributor for their efforts. > > > > To repeat something I posted about in the previous -rc release, I've > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > that the "next" branch is expected to be rebased. Why? While I'm not > > sure if I want to apply things directly to the next branch and then give > > them some sort of automated testing, I do want to try and give changes > > some sort of build testing and similar sooner than I have, and that was > > at least a related problem. > > > > In terms of a changelog, > > git log --merges v2019.10-rc4..v2019.10 > > or > > git log --merges v2019.07..v2019.10 > > > > For this next release, one big concern I have but that I am hopeful we > > will be able to overcome is that we need to remove Python 2.7 support. > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > number of patches posted that get us a good part of the way there and I > > believe we can get the rest done before the deadline. > > I think the big missing piece was to rebase libfdt to the upstream > 1.5.x series that now supports python3, the issue there from memory > was that it bloats some things, Simon was investigating and going to > post a patch set for upstream dtc/libfdt to resolve some of the issues > but I'm not sure if he'd reported back on the latest status of that > work. The libfdt part, by itself, turns out to be easy (just the normal convert to python3 setup.py or whatever). But binman/buildman/test.py all need updating and are real work. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arc: emsdp: Increase max FAT cluster size
Some especially large SD-cards come from stock formatted with larger FAT cluster size so to accommodate those we just increase what we expect to have here in U-Boot given we have a plenty of space on EM SDP (16 MiB). Signed-off-by: Alexey Brodkin --- configs/emsdp_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig index 42415ea713..09fe388e58 100644 --- a/configs/emsdp_defconfig +++ b/configs/emsdp_defconfig @@ -29,6 +29,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_SNPS=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y -CONFIG_FS_FAT_MAX_CLUSTSIZE=4096 +CONFIG_FS_FAT_MAX_CLUSTSIZE=32768 CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_PANIC_HANG=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arc: emsdp/iotdk: Switch to DM_MMC
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion
to DM MMC. So doing it now.
Signed-off-by: Alexey Brodkin
---
arch/arc/dts/emsdp.dts | 23 ++
arch/arc/dts/iot_devkit.dts| 22 ++
board/synopsys/emsdp/emsdp.c | 29 ---
board/synopsys/iot_devkit/iot_devkit.c | 32 --
configs/emsdp_defconfig| 2 ++
configs/iot_devkit_defconfig | 2 ++
6 files changed, 49 insertions(+), 61 deletions(-)
diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts
index d307b95d8e..77362354d5 100644
--- a/arch/arc/dts/emsdp.dts
+++ b/arch/arc/dts/emsdp.dts
@@ -32,4 +32,27 @@
reg-shift = <2>;
reg-io-width = <4>;
};
+
+ mmcclk_biu: mmcclk-biu {
+ compatible = "fixed-clock";
+ clock-frequency = <1>;
+ #clock-cells = <0>;
+ };
+
+ mmcclk_ciu: mmcclk-ciu {
+ compatible = "fixed-clock";
+ clock-frequency = <1>;
+ #clock-cells = <0>;
+ };
+
+ mmc: mmc0@f001 {
+ compatible = "snps,dw-mshc";
+ reg = <0xf001 0x400>;
+ bus-width = <4>;
+ fifo-depth = <256>;
+ clocks = <_biu>, <_ciu>;
+ clock-names = "biu", "ciu";
+ max-frequency = <2500>;
+ };
+
};
diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts
index ebf5a950f0..e2cb602cae 100644
--- a/arch/arc/dts/iot_devkit.dts
+++ b/arch/arc/dts/iot_devkit.dts
@@ -42,4 +42,26 @@
compatible = "nop-phy";
#phy-cells = <0>;
};
+
+ mmcclk_biu: mmcclk-biu {
+ compatible = "fixed-clock";
+ clock-frequency = <5000>;
+ #clock-cells = <0>;
+ };
+
+ mmcclk_ciu: mmcclk-ciu {
+ compatible = "fixed-clock";
+ clock-frequency = <5000>;
+ #clock-cells = <0>;
+ };
+
+ mmc: mmc0@f000b000 {
+ compatible = "snps,dw-mshc";
+ reg = <0xf000b000 0x400>;
+ bus-width = <4>;
+ fifo-depth = <256>;
+ clocks = <_biu>, <_ciu>;
+ clock-names = "biu", "ciu";
+ max-frequency = <2500>;
+ };
};
diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c
index 7a3fd5b7f2..5ba9f862e1 100644
--- a/board/synopsys/emsdp/emsdp.c
+++ b/board/synopsys/emsdp/emsdp.c
@@ -85,35 +85,6 @@ int board_early_init_r(void)
return 0;
}
-int board_mmc_init(bd_t *bis)
-{
- struct dwmci_host *host = NULL;
-
- host = malloc(sizeof(struct dwmci_host));
- if (!host) {
- printf("dwmci_host malloc fail!\n");
- return 1;
- }
-
- memset(host, 0, sizeof(struct dwmci_host));
- host->name = "Synopsys Mobile storage";
- host->ioaddr = SDIO_BASE;
- host->buswidth = 4;
- host->dev_index = 0;
- host->bus_hz = 5000;
-
- add_dwmci(host, host->bus_hz / 2, 40);
-
- return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct dwmci_host *host = mmc->priv;
-
- return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
#define CREG_BASE 0xF0001000
#define CREG_BOOT (void *)(CREG_BASE + 0x0FF0)
#define CREG_IP_SW_RESET (void *)(CREG_BASE + 0x0FF0)
diff --git a/board/synopsys/iot_devkit/iot_devkit.c
b/board/synopsys/iot_devkit/iot_devkit.c
index 8424e09bd3..9dbdc128f8 100644
--- a/board/synopsys/iot_devkit/iot_devkit.c
+++ b/board/synopsys/iot_devkit/iot_devkit.c
@@ -145,38 +145,6 @@ int mach_cpu_init(void)
return set_cpu_freq(gd->cpu_clk);
}
-#define ARC_PERIPHERAL_BASE0xF000
-#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xB000)
-
-int board_mmc_init(bd_t *bis)
-{
- struct dwmci_host *host = NULL;
-
- host = malloc(sizeof(struct dwmci_host));
- if (!host) {
- printf("dwmci_host malloc fail!\n");
- return -ENOMEM;
- }
-
- memset(host, 0, sizeof(struct dwmci_host));
- host->name = "Synopsys Mobile storage";
- host->ioaddr = (void *)SDIO_BASE;
- host->buswidth = 4;
- host->dev_index = 0;
- host->bus_hz = 5000;
-
- add_dwmci(host, host->bus_hz / 2, 40);
-
- return 0;
-}
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct dwmci_host *host = mmc->priv;
-
- return !(dwmci_readl(host, DWMCI_CDETECT) & 1);
-}
-
#define IOTDK_RESET_SEQ0x55AA6699
void reset_cpu(ulong addr)
diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig
index 5e55e3e2b2..42415ea713 100644
--- a/configs/emsdp_defconfig
+++ b/configs/emsdp_defconfig
@@ -24,7 +24,9 @@ CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
# CONFIG_NET is not set
CONFIG_DM=y
Re: [U-Boot] [ANN] U-Boot v2019.10 released
> It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. > > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > that the "next" branch is expected to be rebased. Why? While I'm not > sure if I want to apply things directly to the next branch and then give > them some sort of automated testing, I do want to try and give changes > some sort of build testing and similar sooner than I have, and that was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful we > will be able to overcome is that we need to remove Python 2.7 support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > number of patches posted that get us a good part of the way there and I > believe we can get the rest done before the deadline. I think the big missing piece was to rebase libfdt to the upstream 1.5.x series that now supports python3, the issue there from memory was that it bloats some things, Simon was investigating and going to post a patch set for upstream dtc/libfdt to resolve some of the issues but I'm not sure if he'd reported back on the latest status of that work. Peter ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 04:17:08PM +0200, Michal Simek wrote: > On 08. 10. 19 16:02, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: > >> On 08. 10. 19 15:25, Tom Rini wrote: > >>> On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > >> On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > >>> On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > On 07. 10. 19 23:15, Tom Rini wrote: > >> Hey all, > >> > >> It's release day and while we've once again had some last minute > >> regression fixes, I feel things are as stable as they are likely > >> to get > >> so I've tagged and released v2019.07 and I would like to thank all > >> of > >> our contributor for their efforts. > > > > I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > > >> To repeat something I posted about in the previous -rc release, > >> I've > >> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > >> page > >> that the "next" branch is expected to be rebased. Why? While I'm > >> not > >> sure if I want to apply things directly to the next branch and > >> then give > >> them some sort of automated testing, I do want to try and give > >> changes > >> some sort of build testing and similar sooner than I have, and > >> that was > >> at least a related problem. > >> > >> In terms of a changelog, > >> git log --merges v2019.10-rc4..v2019.10 > >> or > >> git log --merges v2019.07..v2019.10 > >> > >> For this next release, one big concern I have but that I am > >> hopeful we > >> will be able to overcome is that we need to remove Python 2.7 > >> support. > >> Python 2.7 itself is end of lifed on January 1st, 2020. There's > >> been a > >> number of patches posted that get us a good part of the way there > >> and I > >> believe we can get the rest done before the deadline. > >> > >> The merge window is once again open and I plan to tag -rc1 on > >> October > >> 28th, bi-weekly -rcs thereafter and final release on January 6th, > >> 2020. > > > > I am preparing pull request and I see that release has issue with > > sheevaplug board. > > > > 01: Prepare v2019.10 > >arm: + sheevaplug > > +u-boot.kwb exceeds file size limit: > > + limit: 524288 bytes > > + actual: 524632 bytes > > + excess: 344 bytes > > +make[1]: *** [u-boot.kwb] Error 1 > > +make[1]: *** Deleting file 'u-boot.kwb' > > +make: *** [sub-make] Error 2 > > > >>> > >>> I saw this occasionally when I prepared the u-boot-x86 PR during past > >>> days, but I thought that was due to patches in my queue. However I > >>> remember I only saw excess 8 bytes or something, not 344 bytes ... > >>> > > There are also warnings about conversions to DM. > > > > Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address > this, > but my travis and gitlab pipelines passed. So that implies to me > >>> > >>> My latest run of gitlab-ci passed as well. Again I was not sure if > >>> that was due to I dropped some SPL patches that were previously in the > >>> queue. > >>> > there's some /full/path string(s) somewhere that we should find and > address. Thanks! > >> > >> I see a few full path to source files in the resulting binary: > >> $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > >> /home/trini/work/u-boot/u-boot/net/eth_legacy.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > > support it (and these come from BUG/BUG_ON) and I still don't know of > > anyplace that provides a full set of new enough toolchains for use on > > all of the
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 16:02, Tom Rini wrote: > On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: >> On 08. 10. 19 15:25, Tom Rini wrote: >>> On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: >> On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: >>> On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > On 07. 10. 19 23:15, Tom Rini wrote: >> Hey all, >> >> It's release day and while we've once again had some last minute >> regression fixes, I feel things are as stable as they are likely to >> get >> so I've tagged and released v2019.07 and I would like to thank all of >> our contributor for their efforts. > > I expect v2019.10 :-) Oops. I did get the tag right this time at least. >> To repeat something I posted about in the previous -rc release, I've >> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees >> page >> that the "next" branch is expected to be rebased. Why? While I'm >> not >> sure if I want to apply things directly to the next branch and then >> give >> them some sort of automated testing, I do want to try and give >> changes >> some sort of build testing and similar sooner than I have, and that >> was >> at least a related problem. >> >> In terms of a changelog, >> git log --merges v2019.10-rc4..v2019.10 >> or >> git log --merges v2019.07..v2019.10 >> >> For this next release, one big concern I have but that I am hopeful >> we >> will be able to overcome is that we need to remove Python 2.7 >> support. >> Python 2.7 itself is end of lifed on January 1st, 2020. There's >> been a >> number of patches posted that get us a good part of the way there >> and I >> believe we can get the rest done before the deadline. >> >> The merge window is once again open and I plan to tag -rc1 on October >> 28th, bi-weekly -rcs thereafter and final release on January 6th, >> 2020. > > I am preparing pull request and I see that release has issue with > sheevaplug board. > > 01: Prepare v2019.10 >arm: + sheevaplug > +u-boot.kwb exceeds file size limit: > + limit: 524288 bytes > + actual: 524632 bytes > + excess: 344 bytes > +make[1]: *** [u-boot.kwb] Error 1 > +make[1]: *** Deleting file 'u-boot.kwb' > +make: *** [sub-make] Error 2 > >>> >>> I saw this occasionally when I prepared the u-boot-x86 PR during past >>> days, but I thought that was due to patches in my queue. However I >>> remember I only saw excess 8 bytes or something, not 344 bytes ... >>> > There are also warnings about conversions to DM. > > Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me >>> >>> My latest run of gitlab-ci passed as well. Again I was not sure if >>> that was due to I dropped some SPL patches that were previously in the >>> queue. >>> there's some /full/path string(s) somewhere that we should find and address. Thanks! >> >> I see a few full path to source files in the resulting binary: >> $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c >> /home/trini/work/u-boot/u-boot/net/eth_legacy.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c >> /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > support it (and these come from BUG/BUG_ON) and I still don't know of > anyplace that provides a full set of new enough toolchains for use on > all of the architectures we care about. For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? >>> >>> Note that for Sheevaplug it's the full U-Boot that's blowing up and not >>> SPL/TPL. >> >> Anyway back to the problem. If path matters for all these cases. >> Path depends on your
Re: [U-Boot] Question [U-Boot,v2] nand: fix up badblock skipping
On 08/10/19 15:50, Ing. Jiří Valek wrote: > Hello, > can I ask what's wrong with my patch v2 ? > It's quite long time no answer.. > https://patchwork.ozlabs.org/patch/1037203/ > > Regards Jiri Valek I do not know - patch is set to "Changes Requested", see : https://patchwork.ozlabs.org/patch/1037203/ Then it is ignored. It looks like that V2 was also set to Changes Requested and never verified. I will change the state and apply to u-boot-imx. 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] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 03:56:41PM +0200, Michal Simek wrote: > On 08. 10. 19 15:25, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > >> On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > >>> > >>> On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > >> > >> On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > >>> On 07. 10. 19 23:15, Tom Rini wrote: > Hey all, > > It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to > get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. > >>> > >>> I expect v2019.10 :-) > >> > >> Oops. I did get the tag right this time at least. > >> > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > page > that the "next" branch is expected to be rebased. Why? While I'm > not > sure if I want to apply things directly to the next branch and then > give > them some sort of automated testing, I do want to try and give > changes > some sort of build testing and similar sooner than I have, and that > was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful > we > will be able to overcome is that we need to remove Python 2.7 > support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's > been a > number of patches posted that get us a good part of the way there > and I > believe we can get the rest done before the deadline. > > The merge window is once again open and I plan to tag -rc1 on October > 28th, bi-weekly -rcs thereafter and final release on January 6th, > 2020. > >>> > >>> I am preparing pull request and I see that release has issue with > >>> sheevaplug board. > >>> > >>> 01: Prepare v2019.10 > >>>arm: + sheevaplug > >>> +u-boot.kwb exceeds file size limit: > >>> + limit: 524288 bytes > >>> + actual: 524632 bytes > >>> + excess: 344 bytes > >>> +make[1]: *** [u-boot.kwb] Error 1 > >>> +make[1]: *** Deleting file 'u-boot.kwb' > >>> +make: *** [sub-make] Error 2 > >>> > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > days, but I thought that was due to patches in my queue. However I > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > >>> There are also warnings about conversions to DM. > >>> > >>> Is it OK to ignore these boards which should be likely removed? > >> > >> So, how / where are you making this fail? I know it's been noted > >> elsewhere that this happens, and also that the EFI PR will address > >> this, > >> but my travis and gitlab pipelines passed. So that implies to me > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > that was due to I dropped some SPL patches that were previously in the > > queue. > > > >> there's some /full/path string(s) somewhere that we should find and > >> address. Thanks! > > I see a few full path to source files in the resulting binary: > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > >>> > >>> And we have -fmacro-prefix-map patches but our default toolchain doesn't > >>> support it (and these come from BUG/BUG_ON) and I still don't know of > >>> anyplace that provides a full set of new enough toolchains for use on > >>> all of the architectures we care about. > >> > >> For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough > >> info? > > > > Note that for Sheevaplug it's the full U-Boot that's blowing up and not > > SPL/TPL. > > Anyway back to the problem. If path matters for all these cases. > Path depends on your github username because clone is done like
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 15:25, Tom Rini wrote: > On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: >> On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: >>> >>> On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: >> >> On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: >>> On 07. 10. 19 23:15, Tom Rini wrote: Hey all, It's release day and while we've once again had some last minute regression fixes, I feel things are as stable as they are likely to get so I've tagged and released v2019.07 and I would like to thank all of our contributor for their efforts. >>> >>> I expect v2019.10 :-) >> >> Oops. I did get the tag right this time at least. >> To repeat something I posted about in the previous -rc release, I've clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page that the "next" branch is expected to be rebased. Why? While I'm not sure if I want to apply things directly to the next branch and then give them some sort of automated testing, I do want to try and give changes some sort of build testing and similar sooner than I have, and that was at least a related problem. In terms of a changelog, git log --merges v2019.10-rc4..v2019.10 or git log --merges v2019.07..v2019.10 For this next release, one big concern I have but that I am hopeful we will be able to overcome is that we need to remove Python 2.7 support. Python 2.7 itself is end of lifed on January 1st, 2020. There's been a number of patches posted that get us a good part of the way there and I believe we can get the rest done before the deadline. The merge window is once again open and I plan to tag -rc1 on October 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. >>> >>> I am preparing pull request and I see that release has issue with >>> sheevaplug board. >>> >>> 01: Prepare v2019.10 >>>arm: + sheevaplug >>> +u-boot.kwb exceeds file size limit: >>> + limit: 524288 bytes >>> + actual: 524632 bytes >>> + excess: 344 bytes >>> +make[1]: *** [u-boot.kwb] Error 1 >>> +make[1]: *** Deleting file 'u-boot.kwb' >>> +make: *** [sub-make] Error 2 >>> > > I saw this occasionally when I prepared the u-boot-x86 PR during past > days, but I thought that was due to patches in my queue. However I > remember I only saw excess 8 bytes or something, not 344 bytes ... > >>> There are also warnings about conversions to DM. >>> >>> Is it OK to ignore these boards which should be likely removed? >> >> So, how / where are you making this fail? I know it's been noted >> elsewhere that this happens, and also that the EFI PR will address this, >> but my travis and gitlab pipelines passed. So that implies to me > > My latest run of gitlab-ci passed as well. Again I was not sure if > that was due to I dropped some SPL patches that were previously in the > queue. > >> there's some /full/path string(s) somewhere that we should find and >> address. Thanks! I see a few full path to source files in the resulting binary: $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c /home/trini/work/u-boot/u-boot/net/eth_legacy.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c >>> >>> And we have -fmacro-prefix-map patches but our default toolchain doesn't >>> support it (and these come from BUG/BUG_ON) and I still don't know of >>> anyplace that provides a full set of new enough toolchains for use on >>> all of the architectures we care about. >> >> For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough >> info? > > Note that for Sheevaplug it's the full U-Boot that's blowing up and not > SPL/TPL. Anyway back to the problem. If path matters for all these cases. Path depends on your github username because clone is done like that. git clone --depth=50 --branch=mainline-v20191008 https://github.com/michalsimek/u-boot.git michalsimek/u-boot And buildman is running without -o property. Shouldn't we setup -o property that it will behave the same for everybody? -o /tmp/ ? Then all pathes should be the same for everybody without any dependency on github user name. Thanks, Michal -- Michal Simek, Ing. (M.Eng),
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On 08/10/19 15:05, Adam Ford wrote: > On Tue, Oct 8, 2019 at 6:51 AM Peter Robinson wrote: >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load u-boot.img from MMC: 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - 08:03:23 +) 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 3 2019-09-26_17:31:27.63095 MMC Device 1 not found 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### >>> >>> Thanks for reporting this issue. >>> >>> Unfortunately, I don't have access to my Cuboxi, so I am adding Jon >>> and Baruch on Cc. >> >> Works after reverting the following commit. > > For reference reverting this on 2019.10 fixed my issues with the > udoo_neo board. > >> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit >> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a >> Author: Adam Ford >> Date: Thu May 23 14:11:30 2019 -0500 >> >> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 >> >> Currently, when the spl_boot_device checks the boot device, it >> will only return MMC1 when it's either sd or eMMC regardless >> of whether or not it's MMC1 or MMC2. This is a problem when >> booting from MMC2 if MMC isn't being manually configured like in >> the DM_SPL case with SPL_OF_CONTROL. >> >> This patch will check the register and return either MMC1 or >> MMC2. >> >> Signed-off-by: Adam Ford >> I tend to revert the pathc and let the "standard" case working. A board maintainer coould add a board_boot_order() function to still overwrite the behavior of spl_boot_device(). >>> >>> I will revert this and the rest of the series that goes with it. >> >> The series is merged since a very long time - do you propose to revert >> all of them ? > > I just got into my office. I'm looking into it now. I should have > something shortly. for sure, I'll revert the offending patch, but I > want to look into options on how to best approach keeping my board > booting without adding a bunch of extra layers. > I know time is of the essence if we want to get it into the final > release for 2019.10 That ship sailed yesterday! >>> >>> Sorry. >>> :-( >> >> It happens >> >>> Either way, I'll have a revert patch series sent today. >> >> Probably better off getting it fixed properly now, if that involved >> reverting it sure, if it involves patches on top fixing the situation >> and moving things forward do that. > > Apologizes to everyone. I pushed the patch [1] to revert this change. > Thank you to everyone for allowing me the courtesy of undoing it. > I also want to thank Stefano for bringing to my attention that we can > override the standard settings by adding board_boot_order() [2] > which actually let me default back to the serial down-loader in the > event that something goes wrong. > > Thanks Adam - I have already merged your two patches into my -next branch (it will become u-boot-imx, -master after Travis will finish). Best regards, Stefano > adam > > [1] - https://patchwork.ozlabs.org/patch/1173314/ > [2] - https://patchwork.ozlabs.org/patch/1173316/ > >> >>> adam > > adam >> >> commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 >> Author: Adam Ford >> Date: Thu May 23 14:11:32 2019 -0500 >> >> ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init >> >> Since the board uses SPL_OF_CONTROL now, we don't need to >> explicitly initialize the MMC driver, but we still need to >> pinmux the corresponding pins. This patch removes the >> initialization code and leave just the muxing behind. >> >> Signed-off-by: Adam Ford >> >> commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef >> Author: Adam Ford >> Date: Thu May 23 14:11:31 2019 -0500 >> >> ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL >> >> With the spl code correctly returning either MMC1 or MMC2, >> this board can not boot either from internal eMMC (MMC1) or >> the uSD card on the baseboard (MMC2) using the device tree. >> >> Signed-off-by: Adam Ford >> >> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a >> Author: Adam Ford >> Date: Thu May 23 14:11:30 2019 -0500 >> >> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 03:15:32PM +0200, Simon Goldschmidt wrote: > On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > > Hey all, > > > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > > regression fixes, I feel things are as stable as they are likely > > > > > > > to get > > > > > > > so I've tagged and released v2019.07 and I would like to thank > > > > > > > all of > > > > > > > our contributor for their efforts. > > > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > > > To repeat something I posted about in the previous -rc release, > > > > > > > I've > > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > > page > > > > > > > that the "next" branch is expected to be rebased. Why? While > > > > > > > I'm not > > > > > > > sure if I want to apply things directly to the next branch and > > > > > > > then give > > > > > > > them some sort of automated testing, I do want to try and give > > > > > > > changes > > > > > > > some sort of build testing and similar sooner than I have, and > > > > > > > that was > > > > > > > at least a related problem. > > > > > > > > > > > > > > In terms of a changelog, > > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > > or > > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > > > For this next release, one big concern I have but that I am > > > > > > > hopeful we > > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > > support. > > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > > been a > > > > > > > number of patches posted that get us a good part of the way there > > > > > > > and I > > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > > October > > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > > 2020. > > > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > > sheevaplug board. > > > > > > > > > > > > 01: Prepare v2019.10 > > > > > >arm: + sheevaplug > > > > > > +u-boot.kwb exceeds file size limit: > > > > > > + limit: 524288 bytes > > > > > > + actual: 524632 bytes > > > > > > + excess: 344 bytes > > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > > days, but I thought that was due to patches in my queue. However I > > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > > elsewhere that this happens, and also that the EFI PR will address > > > > > this, > > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > > that was due to I dropped some SPL patches that were previously in the > > > > queue. > > > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > > address. Thanks! > > > > > > I see a few full path to source files in the resulting binary: > > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > > support it (and these come from BUG/BUG_ON) and I still don't know of > > anyplace that provides a full set of new enough toolchains for use on > > all of the architectures we care about. > > For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? Note that for Sheevaplug it's the full U-Boot that's blowing up and not SPL/TPL. -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 8, 2019 at 2:54 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > > Hey all, > > > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > > regression fixes, I feel things are as stable as they are likely to > > > > > > get > > > > > > so I've tagged and released v2019.07 and I would like to thank all > > > > > > of > > > > > > our contributor for their efforts. > > > > > > > > > > I expect v2019.10 :-) > > > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees > > > > > > page > > > > > > that the "next" branch is expected to be rebased. Why? While I'm > > > > > > not > > > > > > sure if I want to apply things directly to the next branch and then > > > > > > give > > > > > > them some sort of automated testing, I do want to try and give > > > > > > changes > > > > > > some sort of build testing and similar sooner than I have, and that > > > > > > was > > > > > > at least a related problem. > > > > > > > > > > > > In terms of a changelog, > > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > > or > > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > > > For this next release, one big concern I have but that I am hopeful > > > > > > we > > > > > > will be able to overcome is that we need to remove Python 2.7 > > > > > > support. > > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's > > > > > > been a > > > > > > number of patches posted that get us a good part of the way there > > > > > > and I > > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on > > > > > > October > > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > > 2020. > > > > > > > > > > I am preparing pull request and I see that release has issue with > > > > > sheevaplug board. > > > > > > > > > > 01: Prepare v2019.10 > > > > >arm: + sheevaplug > > > > > +u-boot.kwb exceeds file size limit: > > > > > + limit: 524288 bytes > > > > > + actual: 524632 bytes > > > > > + excess: 344 bytes > > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > > +make: *** [sub-make] Error 2 > > > > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > > days, but I thought that was due to patches in my queue. However I > > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > > > There are also warnings about conversions to DM. > > > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > > > So, how / where are you making this fail? I know it's been noted > > > > elsewhere that this happens, and also that the EFI PR will address this, > > > > but my travis and gitlab pipelines passed. So that implies to me > > > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > > that was due to I dropped some SPL patches that were previously in the > > > queue. > > > > > > > there's some /full/path string(s) somewhere that we should find and > > > > address. Thanks! > > > > I see a few full path to source files in the resulting binary: > > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c > > And we have -fmacro-prefix-map patches but our default toolchain doesn't > support it (and these come from BUG/BUG_ON) and I still don't know of > anyplace that provides a full set of new enough toolchains for use on > all of the architectures we care about. For BUG/BUG_ON in SPL/TPL, wouldn't the function name and line be enough info? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On Tue, Oct 8, 2019 at 6:51 AM Peter Robinson wrote: > > > > > > >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > > > > >> u-boot.img from MMC: > > > > > >> > > > > > >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep > > > > > >> 24 2019 - > > > > > >> 08:03:23 +) > > > > > >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > > > > >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > > > > >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. > > > > > >> error: -19 > > > > > >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot > > > > > >> devices > > > > > >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the > > > > > >> board ### > > > > > > > > > > > > Thanks for reporting this issue. > > > > > > > > > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding > > > > > > Jon > > > > > > and Baruch on Cc. > > > > > > > > > > Works after reverting the following commit. > > > > > >>> > > > > > >>> For reference reverting this on 2019.10 fixed my issues with the > > > > > >>> udoo_neo board. > > > > > >>> > > > > > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > > > Author: Adam Ford > > > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > > > > > Currently, when the spl_boot_device checks the boot device, > > > > > it > > > > > will only return MMC1 when it's either sd or eMMC regardless > > > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > > > booting from MMC2 if MMC isn't being manually configured > > > > > like in > > > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > > > > > This patch will check the register and return either MMC1 or > > > > > MMC2. > > > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > > > >> > > > > > >> I tend to revert the pathc and let the "standard" case working. A > > > > > >> board > > > > > >> maintainer coould add a board_boot_order() function to still > > > > > >> overwrite > > > > > >> the behavior of spl_boot_device(). > > > > > > > > > > > > I will revert this and the rest of the series that goes with it. > > > > > > > > > > The series is merged since a very long time - do you propose to revert > > > > > all of them ? > > > > > > > > I just got into my office. I'm looking into it now. I should have > > > > something shortly. for sure, I'll revert the offending patch, but I > > > > want to look into options on how to best approach keeping my board > > > > booting without adding a bunch of extra layers. > > > > I know time is of the essence if we want to get it into the final > > > > release for 2019.10 > > > > > > That ship sailed yesterday! > > > > Sorry. > > :-( > > It happens > > > Either way, I'll have a revert patch series sent today. > > Probably better off getting it fixed properly now, if that involved > reverting it sure, if it involves patches on top fixing the situation > and moving things forward do that. Apologizes to everyone. I pushed the patch [1] to revert this change. Thank you to everyone for allowing me the courtesy of undoing it. I also want to thank Stefano for bringing to my attention that we can override the standard settings by adding board_boot_order() [2] which actually let me default back to the serial down-loader in the event that something goes wrong. adam [1] - https://patchwork.ozlabs.org/patch/1173314/ [2] - https://patchwork.ozlabs.org/patch/1173316/ > > > adam > > > > > > > > > > > adam > > > > > > > > > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > > > > > Author: Adam Ford > > > > > Date: Thu May 23 14:11:32 2019 -0500 > > > > > > > > > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > > > > > > > > > Since the board uses SPL_OF_CONTROL now, we don't need to > > > > > explicitly initialize the MMC driver, but we still need to > > > > > pinmux the corresponding pins. This patch removes the > > > > > initialization code and leave just the muxing behind. > > > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > > > > > Author: Adam Ford > > > > > Date: Thu May 23 14:11:31 2019 -0500 > > > > > > > > > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > > > > > > > > > With the spl code correctly returning either MMC1 or MMC2, > > > > > this board can not boot either from internal eMMC (MMC1) or > > > > > the uSD card on the baseboard (MMC2) using the device tree. > > > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a
[U-Boot] [PATCH] ARM: imx6q_logic: Fix MMC2 booting
With the reverting of a previous change to spl_boot_device,
this board needs a new solution to determining if we're booting
from MMC1 or MMC2.
This patch creates board_boot_order function which overrides the
standard, and returns not only MMC1, or MMC2, but also can fall
back to NAND or the serial downloader should other boot options
fail.
Signed-off-by: Adam Ford
diff --git a/board/logicpd/imx6/imx6logic.c b/board/logicpd/imx6/imx6logic.c
index 7a59b89d94..63893f5f33 100644
--- a/board/logicpd/imx6/imx6logic.c
+++ b/board/logicpd/imx6/imx6logic.c
@@ -207,6 +207,35 @@ struct fsl_esdhc_cfg usdhc_cfg[] = {
{USDHC2_BASE_ADDR} /* Baseboard */
};
+void board_boot_order(u32 *spl_boot_list)
+{
+ struct src *psrc = (struct src *)SRC_BASE_ADDR;
+ unsigned int reg = readl(>sbmr1) >> 11;
+ /*
+* Upon reading BOOT_CFG register the following map is done:
+* Bit 11 and 12 of BOOT_CFG register can determine the current
+* mmc port
+* 0x1 SD1-SOM
+* 0x2 SD2-Baseboard
+*/
+
+ reg &= 0x3; /* Only care about bottom 2 bits */
+ switch (reg) {
+ case 0:
+ spl_boot_list[0] = BOOT_DEVICE_MMC1;
+ break;
+ case 1:
+ spl_boot_list[0] = BOOT_DEVICE_MMC2;
+ break;
+ }
+
+ /* If we cannot find a valid MMC/SD card, try NAND */
+ spl_boot_list[1] = BOOT_DEVICE_NAND;
+
+ /* As a last resort, use serial downloader */
+ spl_boot_list[2] = BOOT_DEVICE_BOARD;
+}
+
int board_mmc_init(bd_t *bis)
{
struct src *psrc = (struct src *)SRC_BASE_ADDR;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] dm: spi: Return 0 if driver does not implement ops->cs_info
On Sun, Sep 29, 2019 at 4:04 PM Bin Meng wrote: > > Hi Jagan, > > On Mon, Sep 9, 2019 at 9:00 PM Bin Meng wrote: > > > > If an SPI controller driver does not implement ops->cs_info, that > > probably means any chip select number could be valid, hence let's > > return 0 for spi_cs_info(). > > > > Signed-off-by: Bin Meng > > Reviewed-by: Jagan Teki > > > > --- > > > > Changes in v2: > > - update spi-howto.rst to reflect the code changes > > > > doc/driver-model/spi-howto.rst | 4 ++-- > > drivers/spi/spi-uclass.c | 7 +++ > > 2 files changed, 5 insertions(+), 6 deletions(-) > > > > Ping for this series? > Another ping? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Revert "spl: imx6: Let spl_boot_device return USDHC1 or USDHC2"
Apologies to everyone whose board I broke by attempting to return
MMC1 or MMC2. I misunderstood how the MMC indexing worked.
This reverts commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a.
Signed-off-by: Adam Ford
diff --git a/arch/arm/mach-imx/spl.c b/arch/arm/mach-imx/spl.c
index 1f230aca33..9f1e0f6a72 100644
--- a/arch/arm/mach-imx/spl.c
+++ b/arch/arm/mach-imx/spl.c
@@ -24,7 +24,6 @@ u32 spl_boot_device(void)
{
unsigned int bmode = readl(_base->sbmr2);
u32 reg = imx6_src_get_boot_mode();
- u32 mmc_index = ((reg >> 11) & 0x03);
/*
* Check for BMODE if serial downloader is enabled
@@ -85,12 +84,11 @@ u32 spl_boot_device(void)
/* SD/eSD: 8.5.3, Table 8-15 */
case IMX6_BMODE_SD:
case IMX6_BMODE_ESD:
+ return BOOT_DEVICE_MMC1;
+ /* MMC/eMMC: 8.5.3 */
case IMX6_BMODE_MMC:
case IMX6_BMODE_EMMC:
- if (mmc_index == 1)
- return BOOT_DEVICE_MMC2;
- else
- return BOOT_DEVICE_MMC1;
+ return BOOT_DEVICE_MMC1;
/* NAND Flash: 8.5.2, Table 8-10 */
case IMX6_BMODE_NAND_MIN ... IMX6_BMODE_NAND_MAX:
return BOOT_DEVICE_NAND;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 08:50:17AM -0400, Tom Rini wrote: > On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > > Hey all, > > > > > > > > > > It's release day and while we've once again had some last minute > > > > > regression fixes, I feel things are as stable as they are likely to > > > > > get > > > > > so I've tagged and released v2019.07 and I would like to thank all of > > > > > our contributor for their efforts. > > > > > > > > I expect v2019.10 :-) > > > > > > Oops. I did get the tag right this time at least. > > > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > > > sure if I want to apply things directly to the next branch and then > > > > > give > > > > > them some sort of automated testing, I do want to try and give changes > > > > > some sort of build testing and similar sooner than I have, and that > > > > > was > > > > > at least a related problem. > > > > > > > > > > In terms of a changelog, > > > > > git log --merges v2019.10-rc4..v2019.10 > > > > > or > > > > > git log --merges v2019.07..v2019.10 > > > > > > > > > > For this next release, one big concern I have but that I am hopeful we > > > > > will be able to overcome is that we need to remove Python 2.7 support. > > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been > > > > > a > > > > > number of patches posted that get us a good part of the way there and > > > > > I > > > > > believe we can get the rest done before the deadline. > > > > > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, > > > > > 2020. > > > > > > > > I am preparing pull request and I see that release has issue with > > > > sheevaplug board. > > > > > > > > 01: Prepare v2019.10 > > > >arm: + sheevaplug > > > > +u-boot.kwb exceeds file size limit: > > > > + limit: 524288 bytes > > > > + actual: 524632 bytes > > > > + excess: 344 bytes > > > > +make[1]: *** [u-boot.kwb] Error 1 > > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > > +make: *** [sub-make] Error 2 > > > > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > > days, but I thought that was due to patches in my queue. However I > > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > > > There are also warnings about conversions to DM. > > > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > > > So, how / where are you making this fail? I know it's been noted > > > elsewhere that this happens, and also that the EFI PR will address this, > > > but my travis and gitlab pipelines passed. So that implies to me > > > > My latest run of gitlab-ci passed as well. Again I was not sure if > > that was due to I dropped some SPL patches that were previously in the > > queue. > > > > > there's some /full/path string(s) somewhere that we should find and > > > address. Thanks! > > I see a few full path to source files in the resulting binary: > $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c > /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c > /home/trini/work/u-boot/u-boot/net/eth_legacy.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c > /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c > /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c And we have -fmacro-prefix-map patches but our default toolchain doesn't support it (and these come from BUG/BUG_ON) and I still don't know of anyplace that provides a full set of new enough toolchains for use on all of the architectures we care about. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 08:42:58PM +0800, Bin Meng wrote: > On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > > On 07. 10. 19 23:15, Tom Rini wrote: > > > > Hey all, > > > > > > > > It's release day and while we've once again had some last minute > > > > regression fixes, I feel things are as stable as they are likely to get > > > > so I've tagged and released v2019.07 and I would like to thank all of > > > > our contributor for their efforts. > > > > > > I expect v2019.10 :-) > > > > Oops. I did get the tag right this time at least. > > > > > > To repeat something I posted about in the previous -rc release, I've > > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > > sure if I want to apply things directly to the next branch and then give > > > > them some sort of automated testing, I do want to try and give changes > > > > some sort of build testing and similar sooner than I have, and that was > > > > at least a related problem. > > > > > > > > In terms of a changelog, > > > > git log --merges v2019.10-rc4..v2019.10 > > > > or > > > > git log --merges v2019.07..v2019.10 > > > > > > > > For this next release, one big concern I have but that I am hopeful we > > > > will be able to overcome is that we need to remove Python 2.7 support. > > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > > > number of patches posted that get us a good part of the way there and I > > > > believe we can get the rest done before the deadline. > > > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > > > > > I am preparing pull request and I see that release has issue with > > > sheevaplug board. > > > > > > 01: Prepare v2019.10 > > >arm: + sheevaplug > > > +u-boot.kwb exceeds file size limit: > > > + limit: 524288 bytes > > > + actual: 524632 bytes > > > + excess: 344 bytes > > > +make[1]: *** [u-boot.kwb] Error 1 > > > +make[1]: *** Deleting file 'u-boot.kwb' > > > +make: *** [sub-make] Error 2 > > > > > I saw this occasionally when I prepared the u-boot-x86 PR during past > days, but I thought that was due to patches in my queue. However I > remember I only saw excess 8 bytes or something, not 344 bytes ... > > > > There are also warnings about conversions to DM. > > > > > > Is it OK to ignore these boards which should be likely removed? > > > > So, how / where are you making this fail? I know it's been noted > > elsewhere that this happens, and also that the EFI PR will address this, > > but my travis and gitlab pipelines passed. So that implies to me > > My latest run of gitlab-ci passed as well. Again I was not sure if > that was due to I dropped some SPL patches that were previously in the > queue. > > > there's some /full/path string(s) somewhere that we should find and > > address. Thanks! I see a few full path to source files in the resulting binary: $ strings /tmp/sheevaplug/current/sheevaplug/u-boot.bin | grep home /home/trini/work/u-boot/u-boot/drivers/mtd/mtdcore.c /home/trini/work/u-boot/u-boot/drivers/mtd/mtdpart.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/attach.c /home/trini/work/u-boot/u-boot/net/eth_legacy.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_base.c /home/trini/work/u-boot/u-boot/drivers/mtd/ubi/vtbl.c /home/trini/work/u-boot/u-boot/drivers/mtd/nand/raw/nand_bbt.c -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 8, 2019 at 8:36 PM Tom Rini wrote: > > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > > On 07. 10. 19 23:15, Tom Rini wrote: > > > Hey all, > > > > > > It's release day and while we've once again had some last minute > > > regression fixes, I feel things are as stable as they are likely to get > > > so I've tagged and released v2019.07 and I would like to thank all of > > > our contributor for their efforts. > > > > I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > > > > To repeat something I posted about in the previous -rc release, I've > > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > > that the "next" branch is expected to be rebased. Why? While I'm not > > > sure if I want to apply things directly to the next branch and then give > > > them some sort of automated testing, I do want to try and give changes > > > some sort of build testing and similar sooner than I have, and that was > > > at least a related problem. > > > > > > In terms of a changelog, > > > git log --merges v2019.10-rc4..v2019.10 > > > or > > > git log --merges v2019.07..v2019.10 > > > > > > For this next release, one big concern I have but that I am hopeful we > > > will be able to overcome is that we need to remove Python 2.7 support. > > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > > number of patches posted that get us a good part of the way there and I > > > believe we can get the rest done before the deadline. > > > > > > The merge window is once again open and I plan to tag -rc1 on October > > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > > > I am preparing pull request and I see that release has issue with > > sheevaplug board. > > > > 01: Prepare v2019.10 > >arm: + sheevaplug > > +u-boot.kwb exceeds file size limit: > > + limit: 524288 bytes > > + actual: 524632 bytes > > + excess: 344 bytes > > +make[1]: *** [u-boot.kwb] Error 1 > > +make[1]: *** Deleting file 'u-boot.kwb' > > +make: *** [sub-make] Error 2 > > I saw this occasionally when I prepared the u-boot-x86 PR during past days, but I thought that was due to patches in my queue. However I remember I only saw excess 8 bytes or something, not 344 bytes ... > > There are also warnings about conversions to DM. > > > > Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address this, > but my travis and gitlab pipelines passed. So that implies to me My latest run of gitlab-ci passed as well. Again I was not sure if that was due to I dropped some SPL patches that were previously in the queue. > there's some /full/path string(s) somewhere that we should find and > address. Thanks! Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 08. 10. 19 14:35, Tom Rini wrote: > On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: >> On 07. 10. 19 23:15, Tom Rini wrote: >>> Hey all, >>> >>> It's release day and while we've once again had some last minute >>> regression fixes, I feel things are as stable as they are likely to get >>> so I've tagged and released v2019.07 and I would like to thank all of >>> our contributor for their efforts. >> >> I expect v2019.10 :-) > > Oops. I did get the tag right this time at least. > >>> To repeat something I posted about in the previous -rc release, I've >>> clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page >>> that the "next" branch is expected to be rebased. Why? While I'm not >>> sure if I want to apply things directly to the next branch and then give >>> them some sort of automated testing, I do want to try and give changes >>> some sort of build testing and similar sooner than I have, and that was >>> at least a related problem. >>> >>> In terms of a changelog, >>> git log --merges v2019.10-rc4..v2019.10 >>> or >>> git log --merges v2019.07..v2019.10 >>> >>> For this next release, one big concern I have but that I am hopeful we >>> will be able to overcome is that we need to remove Python 2.7 support. >>> Python 2.7 itself is end of lifed on January 1st, 2020. There's been a >>> number of patches posted that get us a good part of the way there and I >>> believe we can get the rest done before the deadline. >>> >>> The merge window is once again open and I plan to tag -rc1 on October >>> 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. >> >> I am preparing pull request and I see that release has issue with >> sheevaplug board. >> >> 01: Prepare v2019.10 >>arm: + sheevaplug >> +u-boot.kwb exceeds file size limit: >> + limit: 524288 bytes >> + actual: 524632 bytes >> + excess: 344 bytes >> +make[1]: *** [u-boot.kwb] Error 1 >> +make[1]: *** Deleting file 'u-boot.kwb' >> +make: *** [sub-make] Error 2 >> >> There are also warnings about conversions to DM. >> >> Is it OK to ignore these boards which should be likely removed? > > So, how / where are you making this fail? I know it's been noted > elsewhere that this happens, and also that the EFI PR will address this, > but my travis and gitlab pipelines passed. So that implies to me > there's some /full/path string(s) somewhere that we should find and > address. Thanks! It was catched by Travis on my branch. https://travis-ci.org/michalsimek/u-boot/jobs/594990410 But I was retesting it on my PC on tag too(log above). Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On Tue, Oct 08, 2019 at 02:20:40PM +0200, Michal Simek wrote: > On 07. 10. 19 23:15, Tom Rini wrote: > > Hey all, > > > > It's release day and while we've once again had some last minute > > regression fixes, I feel things are as stable as they are likely to get > > so I've tagged and released v2019.07 and I would like to thank all of > > our contributor for their efforts. > > I expect v2019.10 :-) Oops. I did get the tag right this time at least. > > To repeat something I posted about in the previous -rc release, I've > > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > > that the "next" branch is expected to be rebased. Why? While I'm not > > sure if I want to apply things directly to the next branch and then give > > them some sort of automated testing, I do want to try and give changes > > some sort of build testing and similar sooner than I have, and that was > > at least a related problem. > > > > In terms of a changelog, > > git log --merges v2019.10-rc4..v2019.10 > > or > > git log --merges v2019.07..v2019.10 > > > > For this next release, one big concern I have but that I am hopeful we > > will be able to overcome is that we need to remove Python 2.7 support. > > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > > number of patches posted that get us a good part of the way there and I > > believe we can get the rest done before the deadline. > > > > The merge window is once again open and I plan to tag -rc1 on October > > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. > > I am preparing pull request and I see that release has issue with > sheevaplug board. > > 01: Prepare v2019.10 >arm: + sheevaplug > +u-boot.kwb exceeds file size limit: > + limit: 524288 bytes > + actual: 524632 bytes > + excess: 344 bytes > +make[1]: *** [u-boot.kwb] Error 1 > +make[1]: *** Deleting file 'u-boot.kwb' > +make: *** [sub-make] Error 2 > > There are also warnings about conversions to DM. > > Is it OK to ignore these boards which should be likely removed? So, how / where are you making this fail? I know it's been noted elsewhere that this happens, and also that the EFI PR will address this, but my travis and gitlab pipelines passed. So that implies to me there's some /full/path string(s) somewhere that we should find and address. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2019.10 released
On 07. 10. 19 23:15, Tom Rini wrote: > Hey all, > > It's release day and while we've once again had some last minute > regression fixes, I feel things are as stable as they are likely to get > so I've tagged and released v2019.07 and I would like to thank all of > our contributor for their efforts. I expect v2019.10 :-) > > To repeat something I posted about in the previous -rc release, I've > clarified on the http://www.denx.de/wiki/U-Boot/CustodianGitTrees page > that the "next" branch is expected to be rebased. Why? While I'm not > sure if I want to apply things directly to the next branch and then give > them some sort of automated testing, I do want to try and give changes > some sort of build testing and similar sooner than I have, and that was > at least a related problem. > > In terms of a changelog, > git log --merges v2019.10-rc4..v2019.10 > or > git log --merges v2019.07..v2019.10 > > For this next release, one big concern I have but that I am hopeful we > will be able to overcome is that we need to remove Python 2.7 support. > Python 2.7 itself is end of lifed on January 1st, 2020. There's been a > number of patches posted that get us a good part of the way there and I > believe we can get the rest done before the deadline. > > The merge window is once again open and I plan to tag -rc1 on October > 28th, bi-weekly -rcs thereafter and final release on January 6th, 2020. I am preparing pull request and I see that release has issue with sheevaplug board. 01: Prepare v2019.10 arm: + sheevaplug +u-boot.kwb exceeds file size limit: + limit: 524288 bytes + actual: 524632 bytes + excess: 344 bytes +make[1]: *** [u-boot.kwb] Error 1 +make[1]: *** Deleting file 'u-boot.kwb' +make: *** [sub-make] Error 2 There are also warnings about conversions to DM. Is it OK to ignore these boards which should be likely removed? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
> > > > >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > > > >> u-boot.img from MMC: > > > > >> > > > > >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep > > > > >> 24 2019 - > > > > >> 08:03:23 +) > > > > >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > > > >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > > > >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. > > > > >> error: -19 > > > > >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot > > > > >> devices > > > > >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board > > > > >> ### > > > > > > > > > > Thanks for reporting this issue. > > > > > > > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding > > > > > Jon > > > > > and Baruch on Cc. > > > > > > > > Works after reverting the following commit. > > > > >>> > > > > >>> For reference reverting this on 2019.10 fixed my issues with the > > > > >>> udoo_neo board. > > > > >>> > > > > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > > Author: Adam Ford > > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > > > Currently, when the spl_boot_device checks the boot device, it > > > > will only return MMC1 when it's either sd or eMMC regardless > > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > > booting from MMC2 if MMC isn't being manually configured like > > > > in > > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > > > This patch will check the register and return either MMC1 or > > > > MMC2. > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > >> > > > > >> I tend to revert the pathc and let the "standard" case working. A > > > > >> board > > > > >> maintainer coould add a board_boot_order() function to still > > > > >> overwrite > > > > >> the behavior of spl_boot_device(). > > > > > > > > > > I will revert this and the rest of the series that goes with it. > > > > > > > > The series is merged since a very long time - do you propose to revert > > > > all of them ? > > > > > > I just got into my office. I'm looking into it now. I should have > > > something shortly. for sure, I'll revert the offending patch, but I > > > want to look into options on how to best approach keeping my board > > > booting without adding a bunch of extra layers. > > > I know time is of the essence if we want to get it into the final > > > release for 2019.10 > > > > That ship sailed yesterday! > > Sorry. > :-( It happens > Either way, I'll have a revert patch series sent today. Probably better off getting it fixed properly now, if that involved reverting it sure, if it involves patches on top fixing the situation and moving things forward do that. > adam > > > > > > > > adam > > > > > > > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > > > > Author: Adam Ford > > > > Date: Thu May 23 14:11:32 2019 -0500 > > > > > > > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > > > > > > > Since the board uses SPL_OF_CONTROL now, we don't need to > > > > explicitly initialize the MMC driver, but we still need to > > > > pinmux the corresponding pins. This patch removes the > > > > initialization code and leave just the muxing behind. > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > > > > Author: Adam Ford > > > > Date: Thu May 23 14:11:31 2019 -0500 > > > > > > > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > > > > > > > With the spl code correctly returning either MMC1 or MMC2, > > > > this board can not boot either from internal eMMC (MMC1) or > > > > the uSD card on the baseboard (MMC2) using the device tree. > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > > Author: Adam Ford > > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > > > Currently, when the spl_boot_device checks the boot device, it > > > > will only return MMC1 when it's either sd or eMMC regardless > > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > > booting from MMC2 if MMC isn't being manually configured like in > > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > > > This patch will check the register and return either MMC1 or MMC2. > > > > > > > > Signed-off-by: Adam Ford > > > > > > > > Two of them affects just imx6q_logic, the only one with more > > > > side-effects is the one we discuss here. Of
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On Tue, Oct 8, 2019 at 6:45 AM Peter Robinson wrote: > > On Tue, Oct 8, 2019 at 12:43 PM Adam Ford wrote: > > > > On Tue, Oct 8, 2019 at 6:04 AM Stefano Babic wrote: > > > > > > On 08/10/19 12:42, Adam Ford wrote: > > > > On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic wrote: > > > >> > > > >> Hi everybody, > > > >> > > > >> thanks for deep analyses (I just jump at the end): > > > >> > > > >> On 08/10/19 12:03, Peter Robinson wrote: > > > On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > > > > Hi Vagrant, > > > > > > > > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > > > > wrote: > > > >> > > > >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > > >> u-boot.img from MMC: > > > >> > > > >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 > > > >> 2019 - > > > >> 08:03:23 +) > > > >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > > >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > > >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. > > > >> error: -19 > > > >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot > > > >> devices > > > >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board > > > >> ### > > > > > > > > Thanks for reporting this issue. > > > > > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > > > > and Baruch on Cc. > > > > > > Works after reverting the following commit. > > > >>> > > > >>> For reference reverting this on 2019.10 fixed my issues with the > > > >>> udoo_neo board. > > > >>> > > > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > Author: Adam Ford > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > Currently, when the spl_boot_device checks the boot device, it > > > will only return MMC1 when it's either sd or eMMC regardless > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > booting from MMC2 if MMC isn't being manually configured like in > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > This patch will check the register and return either MMC1 or > > > MMC2. > > > > > > Signed-off-by: Adam Ford > > > > > > >> > > > >> I tend to revert the pathc and let the "standard" case working. A board > > > >> maintainer coould add a board_boot_order() function to still overwrite > > > >> the behavior of spl_boot_device(). > > > > > > > > I will revert this and the rest of the series that goes with it. > > > > > > The series is merged since a very long time - do you propose to revert > > > all of them ? > > > > I just got into my office. I'm looking into it now. I should have > > something shortly. for sure, I'll revert the offending patch, but I > > want to look into options on how to best approach keeping my board > > booting without adding a bunch of extra layers. > > I know time is of the essence if we want to get it into the final > > release for 2019.10 > > That ship sailed yesterday! Sorry. :-( Either way, I'll have a revert patch series sent today. adam > > > > > adam > > > > > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > > > Author: Adam Ford > > > Date: Thu May 23 14:11:32 2019 -0500 > > > > > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > > > > > Since the board uses SPL_OF_CONTROL now, we don't need to > > > explicitly initialize the MMC driver, but we still need to > > > pinmux the corresponding pins. This patch removes the > > > initialization code and leave just the muxing behind. > > > > > > Signed-off-by: Adam Ford > > > > > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > > > Author: Adam Ford > > > Date: Thu May 23 14:11:31 2019 -0500 > > > > > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > > > > > With the spl code correctly returning either MMC1 or MMC2, > > > this board can not boot either from internal eMMC (MMC1) or > > > the uSD card on the baseboard (MMC2) using the device tree. > > > > > > Signed-off-by: Adam Ford > > > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > > Author: Adam Ford > > > Date: Thu May 23 14:11:30 2019 -0500 > > > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > > > Currently, when the spl_boot_device checks the boot device, it > > > will only return MMC1 when it's either sd or eMMC regardless > > > of whether or not it's MMC1 or MMC2. This is a problem when > > > booting from MMC2 if MMC isn't being manually configured like in > > > the DM_SPL case with SPL_OF_CONTROL. > > > > > > This patch will check the register and return either
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On Tue, Oct 8, 2019 at 12:43 PM Adam Ford wrote: > > On Tue, Oct 8, 2019 at 6:04 AM Stefano Babic wrote: > > > > On 08/10/19 12:42, Adam Ford wrote: > > > On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic wrote: > > >> > > >> Hi everybody, > > >> > > >> thanks for deep analyses (I just jump at the end): > > >> > > >> On 08/10/19 12:03, Peter Robinson wrote: > > On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > > > Hi Vagrant, > > > > > > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > > > wrote: > > >> > > >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > >> u-boot.img from MMC: > > >> > > >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 > > >> 2019 - > > >> 08:03:23 +) > > >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: > > >> -19 > > >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices > > >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### > > > > > > Thanks for reporting this issue. > > > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > > > and Baruch on Cc. > > > > Works after reverting the following commit. > > >>> > > >>> For reference reverting this on 2019.10 fixed my issues with the > > >>> udoo_neo board. > > >>> > > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > Author: Adam Ford > > Date: Thu May 23 14:11:30 2019 -0500 > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > Currently, when the spl_boot_device checks the boot device, it > > will only return MMC1 when it's either sd or eMMC regardless > > of whether or not it's MMC1 or MMC2. This is a problem when > > booting from MMC2 if MMC isn't being manually configured like in > > the DM_SPL case with SPL_OF_CONTROL. > > > > This patch will check the register and return either MMC1 or MMC2. > > > > Signed-off-by: Adam Ford > > > > >> > > >> I tend to revert the pathc and let the "standard" case working. A board > > >> maintainer coould add a board_boot_order() function to still overwrite > > >> the behavior of spl_boot_device(). > > > > > > I will revert this and the rest of the series that goes with it. > > > > The series is merged since a very long time - do you propose to revert > > all of them ? > > I just got into my office. I'm looking into it now. I should have > something shortly. for sure, I'll revert the offending patch, but I > want to look into options on how to best approach keeping my board > booting without adding a bunch of extra layers. > I know time is of the essence if we want to get it into the final > release for 2019.10 That ship sailed yesterday! > > adam > > > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > > Author: Adam Ford > > Date: Thu May 23 14:11:32 2019 -0500 > > > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > > > Since the board uses SPL_OF_CONTROL now, we don't need to > > explicitly initialize the MMC driver, but we still need to > > pinmux the corresponding pins. This patch removes the > > initialization code and leave just the muxing behind. > > > > Signed-off-by: Adam Ford > > > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > > Author: Adam Ford > > Date: Thu May 23 14:11:31 2019 -0500 > > > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > > > With the spl code correctly returning either MMC1 or MMC2, > > this board can not boot either from internal eMMC (MMC1) or > > the uSD card on the baseboard (MMC2) using the device tree. > > > > Signed-off-by: Adam Ford > > > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > > Author: Adam Ford > > Date: Thu May 23 14:11:30 2019 -0500 > > > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > > > Currently, when the spl_boot_device checks the boot device, it > > will only return MMC1 when it's either sd or eMMC regardless > > of whether or not it's MMC1 or MMC2. This is a problem when > > booting from MMC2 if MMC isn't being manually configured like in > > the DM_SPL case with SPL_OF_CONTROL. > > > > This patch will check the register and return either MMC1 or MMC2. > > > > Signed-off-by: Adam Ford > > > > Two of them affects just imx6q_logic, the only one with more > > side-effects is the one we discuss here. Of course, I can revert all > > three of them if you prefer to go on this way (I am happy with follow up > > pathces,too, after reverting just 14d319b1856). > > > > Regards, > > Stefano > > > > -- > >
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On Tue, Oct 8, 2019 at 6:04 AM Stefano Babic wrote: > > On 08/10/19 12:42, Adam Ford wrote: > > On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic wrote: > >> > >> Hi everybody, > >> > >> thanks for deep analyses (I just jump at the end): > >> > >> On 08/10/19 12:03, Peter Robinson wrote: > On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > > Hi Vagrant, > > > > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > > wrote: > >> > >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > >> u-boot.img from MMC: > >> > >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 > >> - > >> 08:03:23 +) > >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: > >> -19 > >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices > >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### > > > > Thanks for reporting this issue. > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > > and Baruch on Cc. > > Works after reverting the following commit. > >>> > >>> For reference reverting this on 2019.10 fixed my issues with the udoo_neo > >>> board. > >>> > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > Author: Adam Ford > Date: Thu May 23 14:11:30 2019 -0500 > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > Currently, when the spl_boot_device checks the boot device, it > will only return MMC1 when it's either sd or eMMC regardless > of whether or not it's MMC1 or MMC2. This is a problem when > booting from MMC2 if MMC isn't being manually configured like in > the DM_SPL case with SPL_OF_CONTROL. > > This patch will check the register and return either MMC1 or MMC2. > > Signed-off-by: Adam Ford > > >> > >> I tend to revert the pathc and let the "standard" case working. A board > >> maintainer coould add a board_boot_order() function to still overwrite > >> the behavior of spl_boot_device(). > > > > I will revert this and the rest of the series that goes with it. > > The series is merged since a very long time - do you propose to revert > all of them ? I just got into my office. I'm looking into it now. I should have something shortly. for sure, I'll revert the offending patch, but I want to look into options on how to best approach keeping my board booting without adding a bunch of extra layers. I know time is of the essence if we want to get it into the final release for 2019.10 adam > > commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 > Author: Adam Ford > Date: Thu May 23 14:11:32 2019 -0500 > > ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init > > Since the board uses SPL_OF_CONTROL now, we don't need to > explicitly initialize the MMC driver, but we still need to > pinmux the corresponding pins. This patch removes the > initialization code and leave just the muxing behind. > > Signed-off-by: Adam Ford > > commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef > Author: Adam Ford > Date: Thu May 23 14:11:31 2019 -0500 > > ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL > > With the spl code correctly returning either MMC1 or MMC2, > this board can not boot either from internal eMMC (MMC1) or > the uSD card on the baseboard (MMC2) using the device tree. > > Signed-off-by: Adam Ford > > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > Author: Adam Ford > Date: Thu May 23 14:11:30 2019 -0500 > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > Currently, when the spl_boot_device checks the boot device, it > will only return MMC1 when it's either sd or eMMC regardless > of whether or not it's MMC1 or MMC2. This is a problem when > booting from MMC2 if MMC isn't being manually configured like in > the DM_SPL case with SPL_OF_CONTROL. > > This patch will check the register and return either MMC1 or MMC2. > > Signed-off-by: Adam Ford > > Two of them affects just imx6q_logic, the only one with more > side-effects is the one we discuss here. Of course, I can revert all > three of them if you prefer to go on this way (I am happy with follow up > pathces,too, after reverting just 14d319b1856). > > 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 > =
Re: [U-Boot] [PATCH v4 0/3] env: Add CONFIG_ENV_FULL_SUPPORT
Dear Tom, In message <20191007223650.GR6716@bill-the-cat> you wrote: > > > Do I understand correctly that all of this is obsolete and no longer > > needed after Tom's commit d90fc9c3de ``Revert "env: solve > > compilation error in SPL"'' ? > > So, I think there's a new topic here. I seem to recall a concern from > the previous thread that we could have less restrictive environment > protections in SPL/TPL than we do in full U-Boot and thus open ourselves > to a potential problem. As of today, U-Boot is back to where it was > prior to the problematic patch being applied. But do we not have the > potential problem above and thus need to evaluate the rest of the > series (as the revert was largely the same as the first patch in the > series) ? Thanks! The (potential) problem of having less restrictive/secure code in SPL than in U-Boot proper resulted from the fact that the patch series allowed different configurations of the U-Boot environment features in these stages. After the revert of the original problem, I don't see the need for any such configuration, so if we simply do nothing we are as secure as we have been before. When accepting this new patch series, a full review of the impacts (size, security) is needed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In an infinite universe all things are possible, including the possi- bility that the universe does not exist. - Terry Pratchett, _The Dark Side of the Sun_ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH RFT v2 2/3] spi-nor: spi-nor-ids: Add entries for mt25q variants
On Fri, Sep 27, 2019 at 6:43 AM Vignesh Raghavendra wrote:
>
> Newer variants of mt25q* flashes support 4 Byte addressing opcodes. Add
> entries for the same. These flashes have bit 6 set in 5th byte of READ ID
> response.
>
> Signed-off-by: Vignesh Raghavendra
Tested-by: Simon Goldschmidt
I tested read ,write and erase on socfpga gen5 with n25q256a and mt25ql256a.
Regards,
Simon
> ---
> drivers/mtd/spi/spi-nor-ids.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index bb67661b40d2..c7b6cf002c54 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,11 +161,14 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> + { INFO6("mt25ql256a",0x20ba19, 0x104400, 64 * 1024, 512, SECT_4K
> | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { INFO6("mt25qu256a", 0x20bb19, 0x104400, 64 * 1024, 512, SECT_4K |
> SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES)
> },
> { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ) },
> + { INFO6("mt25ql512a", 0x20ba20, 0x104400, 64 * 1024, 1024, SECT_4K |
> USE_FSR | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ) },
> { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> --
> 2.23.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On 08/10/19 12:42, Adam Ford wrote: > On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic wrote: >> >> Hi everybody, >> >> thanks for deep analyses (I just jump at the end): >> >> On 08/10/19 12:03, Peter Robinson wrote: On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > Hi Vagrant, > > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > wrote: >> >> I just tested mx6cuboxi with 2019.10-rc4, and it fails to load >> u-boot.img from MMC: >> >> 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - >> 08:03:23 +) >> 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 >> 3 2019-09-26_17:31:27.63095 MMC Device 1 not found >> 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 >> 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices >> 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### > > Thanks for reporting this issue. > > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > and Baruch on Cc. Works after reverting the following commit. >>> >>> For reference reverting this on 2019.10 fixed my issues with the udoo_neo >>> board. >>> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a Author: Adam Ford Date: Thu May 23 14:11:30 2019 -0500 spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 Currently, when the spl_boot_device checks the boot device, it will only return MMC1 when it's either sd or eMMC regardless of whether or not it's MMC1 or MMC2. This is a problem when booting from MMC2 if MMC isn't being manually configured like in the DM_SPL case with SPL_OF_CONTROL. This patch will check the register and return either MMC1 or MMC2. Signed-off-by: Adam Ford >> >> I tend to revert the pathc and let the "standard" case working. A board >> maintainer coould add a board_boot_order() function to still overwrite >> the behavior of spl_boot_device(). > > I will revert this and the rest of the series that goes with it. The series is merged since a very long time - do you propose to revert all of them ? commit 8f4691e31a18254d225524a4b018b8cbcddc70b1 Author: Adam Ford Date: Thu May 23 14:11:32 2019 -0500 ARM: imx6q_logic: With SPL_OF_CONTROL enabled, remove MMC init Since the board uses SPL_OF_CONTROL now, we don't need to explicitly initialize the MMC driver, but we still need to pinmux the corresponding pins. This patch removes the initialization code and leave just the muxing behind. Signed-off-by: Adam Ford commit 0749bbb5c75d2b35eaf6acd438750cf08df314ef Author: Adam Ford Date: Thu May 23 14:11:31 2019 -0500 ARM: imx6q_logic: Enable SPL_DM with SPL_OF_CONTROL With the spl code correctly returning either MMC1 or MMC2, this board can not boot either from internal eMMC (MMC1) or the uSD card on the baseboard (MMC2) using the device tree. Signed-off-by: Adam Ford commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a Author: Adam Ford Date: Thu May 23 14:11:30 2019 -0500 spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 Currently, when the spl_boot_device checks the boot device, it will only return MMC1 when it's either sd or eMMC regardless of whether or not it's MMC1 or MMC2. This is a problem when booting from MMC2 if MMC isn't being manually configured like in the DM_SPL case with SPL_OF_CONTROL. This patch will check the register and return either MMC1 or MMC2. Signed-off-by: Adam Ford Two of them affects just imx6q_logic, the only one with more side-effects is the one we discuss here. Of course, I can revert all three of them if you prefer to go on this way (I am happy with follow up pathces,too, after reverting just 14d319b1856). 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 RFT v2 1/3] spi-nor: spi-nor-ids: Disable SPI_NOR_4B_OPCODES for n25q512* and n25q256*
On Fri, Sep 27, 2019 at 6:43 AM Vignesh Raghavendra wrote:
>
> Older variants of n25q256* and n25q512* do not support 4 Byte stateless
> addressing opcodes. Therefore drop SPI_NOR_4B_OPCODES flag from these
> entries.
>
> Signed-off-by: Vignesh Raghavendra
Tested-by: Simon Goldschmidt
I tested read ,write and erase on socfpga gen5 with n25q256a and mt25ql256a.
Regards,
Simon
> ---
> drivers/mtd/spi/spi-nor-ids.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> index df0643ed1d47..bb67661b40d2 100644
> --- a/drivers/mtd/spi/spi-nor-ids.c
> +++ b/drivers/mtd/spi/spi-nor-ids.c
> @@ -161,12 +161,12 @@ const struct flash_info spi_nor_ids[] = {
> { INFO("n25q064a",0x20bb17, 0, 64 * 1024, 128, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a11", 0x20bb18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO("n25q128a13", 0x20ba18, 0, 64 * 1024, 256, SECT_4K |
> SPI_NOR_QUAD_READ) },
> - { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> - { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("n25q256a",0x20ba19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> + { INFO("n25q256ax1", 0x20bb19, 0, 64 * 1024, 512, SECT_4K |
> SPI_NOR_QUAD_READ) },
> { INFO6("mt25qu512a", 0x20bb20, 0x104400, 64 * 1024, 1024,
> SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES)
> },
> - { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> - { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
> + { INFO("n25q512a",0x20bb20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ) },
> + { INFO("n25q512ax3", 0x20ba20, 0, 64 * 1024, 1024, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ) },
> { INFO("n25q00", 0x20ba21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("n25q00a", 0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> { INFO("mt25qu02g", 0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR
> | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> --
> 2.23.0
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
On Tue, Oct 8, 2019 at 5:19 AM Stefano Babic wrote: > > Hi everybody, > > thanks for deep analyses (I just jump at the end): > > On 08/10/19 12:03, Peter Robinson wrote: > >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > >>> Hi Vagrant, > >>> > >>> On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > >>> wrote: > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > u-boot.img from MMC: > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - > 08:03:23 +) > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### > >>> > >>> Thanks for reporting this issue. > >>> > >>> Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > >>> and Baruch on Cc. > >> > >> Works after reverting the following commit. > > > > For reference reverting this on 2019.10 fixed my issues with the udoo_neo > > board. > > > >> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > >> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > >> Author: Adam Ford > >> Date: Thu May 23 14:11:30 2019 -0500 > >> > >> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > >> > >> Currently, when the spl_boot_device checks the boot device, it > >> will only return MMC1 when it's either sd or eMMC regardless > >> of whether or not it's MMC1 or MMC2. This is a problem when > >> booting from MMC2 if MMC isn't being manually configured like in > >> the DM_SPL case with SPL_OF_CONTROL. > >> > >> This patch will check the register and return either MMC1 or MMC2. > >> > >> Signed-off-by: Adam Ford > >> > > I tend to revert the pathc and let the "standard" case working. A board > maintainer coould add a board_boot_order() function to still overwrite > the behavior of spl_boot_device(). I will revert this and the rest of the series that goes with it. I just need some time to wake up and test it. I'll have something in a couple hours. adam > > 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 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] ubi: Add "skipcheck" command to set/clear this bit in the UBI volume hdr
Hello Stefan, Am 17.09.2019 um 09:17 schrieb Stefan Roese: U-Boot now supports the "skip_check" flag to optionally skip the CRC check at open time. Currently its only possible to set this bit upon UBI volume creation. But it might be very useful to also set this bit on already installed systems (e.g. field upgrade) to make also use of the boot-time decrease on those systems. This patch now adds a new "ubi" command "ubi skipcheck" to set or clear this bit in the UBI volume header: => ubi skipcheck rootfs0 on Setting skip_check on volume rootfs0 BTW: This saves approx. 10 seconds Linux bootup time on a MT7688 based target with 128MiB of SPI NAND. Signed-off-by: Stefan Roese Reviewed-by: Heiko Schocher Cc: Quentin Schulz Cc: Boris Brezillon Cc: Heiko Schocher Cc: Andreas Dannenberg --- v2: - Add documentation to doc/README.ubi as suggested by Andreas cmd/ubi.c | 34 ++ doc/README.ubi | 33 + 2 files changed, 67 insertions(+) Just applied it locally and started a travis build [1] for your patch series. Unfortunately it breaks [2] sheevaplug board (size limit). Added Prafulla to cc may he can give a hint, if we can remove something? @Prafulla: This board drops a lot of build warnings [3] ... is it used anymore? Do you plan to update to DM support? Or should we remove this board? bye, Heiko [1] https://travis-ci.org/hsdenx/u-boot-ubi/builds/594929737 [2] https://travis-ci.org/hsdenx/u-boot-ubi/jobs/594929765 [3] build warnings sheevaplug = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does use CONFIG_MVSATA_IDE which is not ported to driver-model (DM) yet. Please update the storage controller driver to use CONFIG_AHCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell/master (watchdog related)
Hi Tom, please pull the following watchdog related patches: - Move WATCHDOG_TIMEOUT_MSECS to Kconfig (Heiko) Here the Travis build, without any issues: https://travis-ci.org/stroese/u-boot/builds/594946794 Thanks, Stefan The following changes since commit 61ba1244b548463dbfb3c5285b6b22e7c772c5bd: Prepare v2019.10 (2019-10-07 17:14:02 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to ca51ef7c0c6140e6590746b07dad19040f95ef60: watchdog: move WATCHDOG_TIMEOUT_MSECS to Kconfig (2019-10-08 07:46:38 +0200) Heiko Schocher (1): watchdog: move WATCHDOG_TIMEOUT_MSECS to Kconfig arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 1 - configs/dh_imx6_defconfig | 1 + configs/display5_defconfig | 1 + configs/display5_factory_defconfig | 1 + configs/ge_bx50v3_defconfig| 1 + configs/kp_imx6q_tpc_defconfig | 1 + configs/m53menlo_defconfig | 1 + configs/mx53ppd_defconfig | 1 + configs/tqma6s_wru4_mmc_defconfig | 1 + configs/warp_defconfig | 1 + drivers/watchdog/Kconfig | 9 + include/configs/dh_imx6.h | 1 - include/configs/display5.h | 1 - include/configs/ge_bx50v3.h| 2 -- include/configs/kp_imx6q_tpc.h | 1 - include/configs/m53menlo.h | 1 - include/configs/mx53ppd.h | 2 -- include/configs/socfpga_common.h | 1 - include/configs/socfpga_stratix10_socdk.h | 1 - include/configs/tqma6_wru4.h | 1 - include/configs/warp.h | 1 - scripts/config_whitelist.txt | 1 - 22 files changed, 18 insertions(+), 14 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] watchdog: move WATCHDOG_TIMEOUT_MSECS to Kconfig
On 30.09.19 09:33, Heiko Schocher wrote:
move WATCHDOG_TIMEOUT_MSECS to Kconfig and fix
all board defconfigs.
Signed-off-by: Heiko Schocher
Reviewed-by: Stefan Roese
Acked-by: Lukasz Majewski
Acked-by: Martyn Welch
---
Patchseries build fine on travis see:
https://travis-ci.org/hsdenx/u-boot-test/builds/591305674
Based on mainline commit:
d88eab4bcc: ("efi_loader: SetVariable() deleting variables")
Changes in v2:
- add Reviewed-by tag from Stefan
- add Acked-by tag from Lukasz and Martin
- rebased to
d88eab4bcc: ("efi_loader: SetVariable() deleting variables")
Sorry to Stefan, who had requested a rebase and I missed
the EMail...
arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 | 1 -
configs/dh_imx6_defconfig | 1 +
configs/display5_defconfig | 1 +
configs/display5_factory_defconfig | 1 +
configs/ge_bx50v3_defconfig| 1 +
configs/kp_imx6q_tpc_defconfig | 1 +
configs/m53menlo_defconfig | 1 +
configs/mx53ppd_defconfig | 1 +
configs/tqma6s_wru4_mmc_defconfig | 1 +
configs/warp_defconfig | 1 +
drivers/watchdog/Kconfig | 9 +
include/configs/dh_imx6.h | 1 -
include/configs/display5.h | 1 -
include/configs/ge_bx50v3.h| 2 --
include/configs/kp_imx6q_tpc.h | 1 -
include/configs/m53menlo.h | 1 -
include/configs/mx53ppd.h | 2 --
include/configs/socfpga_common.h | 1 -
include/configs/socfpga_stratix10_socdk.h | 1 -
include/configs/tqma6_wru4.h | 1 -
include/configs/warp.h | 1 -
scripts/config_whitelist.txt | 1 -
22 files changed, 18 insertions(+), 14 deletions(-)
Applied to u-boot-mavell/master
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] mx6cuboxi fails to load u-boot.img
Hi everybody, thanks for deep analyses (I just jump at the end): On 08/10/19 12:03, Peter Robinson wrote: >> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: >>> Hi Vagrant, >>> >>> On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian >>> wrote: I just tested mx6cuboxi with 2019.10-rc4, and it fails to load u-boot.img from MMC: 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - 08:03:23 +) 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 3 2019-09-26_17:31:27.63095 MMC Device 1 not found 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### >>> >>> Thanks for reporting this issue. >>> >>> Unfortunately, I don't have access to my Cuboxi, so I am adding Jon >>> and Baruch on Cc. >> >> Works after reverting the following commit. > > For reference reverting this on 2019.10 fixed my issues with the udoo_neo > board. > >> 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit >> commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a >> Author: Adam Ford >> Date: Thu May 23 14:11:30 2019 -0500 >> >> spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 >> >> Currently, when the spl_boot_device checks the boot device, it >> will only return MMC1 when it's either sd or eMMC regardless >> of whether or not it's MMC1 or MMC2. This is a problem when >> booting from MMC2 if MMC isn't being manually configured like in >> the DM_SPL case with SPL_OF_CONTROL. >> >> This patch will check the register and return either MMC1 or MMC2. >> >> Signed-off-by: Adam Ford >> I tend to revert the pathc and let the "standard" case working. A board maintainer coould add a board_boot_order() function to still overwrite the behavior of spl_boot_device(). 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] mx6cuboxi fails to load u-boot.img
> On Thu, Sep 26, 2019 at 05:07:21PM -0300, Fabio Estevam wrote: > > Hi Vagrant, > > > > On Thu, Sep 26, 2019 at 4:16 PM Vagrant Cascadian > > wrote: > > > > > > I just tested mx6cuboxi with 2019.10-rc4, and it fails to load > > > u-boot.img from MMC: > > > > > > 1 2019-09-26_17:31:27.63089 U-Boot SPL 2019.10-rc4+dfsg-1 (Sep 24 2019 - > > > 08:03:23 +) > > > 2 2019-09-26_17:31:27.63092 Trying to boot from MMC2 > > > 3 2019-09-26_17:31:27.63095 MMC Device 1 not found > > > 4 2019-09-26_17:31:27.63097 spl: could not find mmc device 1. error: -19 > > > 5 2019-09-26_17:31:27.63099 SPL: failed to boot from all boot devices > > > 6 2019-09-26_17:31:27.63101 ### ERROR ### Please RESET the board ### > > > > Thanks for reporting this issue. > > > > Unfortunately, I don't have access to my Cuboxi, so I am adding Jon > > and Baruch on Cc. > > Works after reverting the following commit. For reference reverting this on 2019.10 fixed my issues with the udoo_neo board. > 14d319b1856b86e593e01abd0a1e3c2d63b52a8a is the first bad commit > commit 14d319b1856b86e593e01abd0a1e3c2d63b52a8a > Author: Adam Ford > Date: Thu May 23 14:11:30 2019 -0500 > > spl: imx6: Let spl_boot_device return USDHC1 or USDHC2 > > Currently, when the spl_boot_device checks the boot device, it > will only return MMC1 when it's either sd or eMMC regardless > of whether or not it's MMC1 or MMC2. This is a problem when > booting from MMC2 if MMC isn't being manually configured like in > the DM_SPL case with SPL_OF_CONTROL. > > This patch will check the register and return either MMC1 or MMC2. > > Signed-off-by: Adam Ford > > arch/arm/mach-imx/spl.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] microblaze: defconfig: Enable devtmps and tmpfs
From: Manjukumar Matha Currently dropbear does not run in background because devtmps and tmpfs is not enabled by default. Enable devtmps and tmpfs to fix this issue. Signed-off-by: Manjukumar Matha Signed-off-by: Michal Simek --- arch/microblaze/configs/mmu_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/microblaze/configs/mmu_defconfig b/arch/microblaze/configs/mmu_defconfig index 654edfdc7867..b3b433db89d8 100644 --- a/arch/microblaze/configs/mmu_defconfig +++ b/arch/microblaze/configs/mmu_defconfig @@ -33,6 +33,8 @@ CONFIG_INET=y # CONFIG_IPV6 is not set CONFIG_BRIDGE=m CONFIG_PCI=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y CONFIG_MTD=y CONFIG_MTD_CFI=y CONFIG_MTD_CFI_INTELEXT=y @@ -73,6 +75,7 @@ CONFIG_UIO_PDRV_GENIRQ=y CONFIG_UIO_DMEM_GENIRQ=y CONFIG_EXT2_FS=y # CONFIG_DNOTIFY is not set +CONFIG_TMPFS=y CONFIG_CRAMFS=y CONFIG_ROMFS_FS=y CONFIG_NFS_FS=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd: avoid decimal conversion
Hi Tom,
On 19. 09. 19 15:28, Michal Simek wrote:
> On 13. 09. 19 17:09, Tom Rini wrote:
>> On Wed, Sep 11, 2019 at 03:39:53PM +0200, Michal Simek wrote:
>>
>>> From: T Karthik Reddy
>>>
>>> This patch uses auto instead of decimal in simple_strtoul().
>>>
>>> Signed-off-by: T Karthik Reddy
>>> Signed-off-by: Michal Simek
>>> ---
>>>
>>> cmd/test.c | 24
>>> 1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/cmd/test.c b/cmd/test.c
>>> index fa0c349f0827..258bfd880653 100644
>>> --- a/cmd/test.c
>>> +++ b/cmd/test.c
>>> @@ -113,28 +113,28 @@ static int do_test(cmd_tbl_t *cmdtp, int flag, int
>>> argc, char * const argv[])
>>> expr = strcmp(ap[0], ap[2]) > 0;
>>> break;
>>> case OP_INT_EQ:
>>> - expr = simple_strtol(ap[0], NULL, 10) ==
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) ==
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_INT_NEQ:
>>> - expr = simple_strtol(ap[0], NULL, 10) !=
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) !=
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_INT_LT:
>>> - expr = simple_strtol(ap[0], NULL, 10) <
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) <
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_INT_LE:
>>> - expr = simple_strtol(ap[0], NULL, 10) <=
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) <=
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_INT_GT:
>>> - expr = simple_strtol(ap[0], NULL, 10) >
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) >
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_INT_GE:
>>> - expr = simple_strtol(ap[0], NULL, 10) >=
>>> - simple_strtol(ap[2], NULL, 10);
>>> + expr = simple_strtol(ap[0], NULL, 0) >=
>>> + simple_strtol(ap[2], NULL, 0);
>>> break;
>>> case OP_FILE_EXISTS:
>>> expr = file_exists(ap[1], ap[2], ap[3], FS_TYPE_ANY);
>>
>> I'm going to NAK this, but could be argued around to changing my mind.
>> While it's true that in general command inputs are hex and not decimal,
>> this has been decimal since introduction in 2009. So changing it now is
>> breaking ABI and other peoples test scripts, so I don't think we can do
>> this, sorry.
>
> I also think that this is not breaking any ABI. test_hush_if_test.py is
> around for a while to capture issues in this space and I can't see any
> single failure in connection to this change.
>
> If this accepted then we can add more tests like this
> ('test 0x200 -gt 0x201', False),
> ('test 0x200 -gt 0x200', False),
> ('test 0x200 -gt 0x1ff', True),
> ('test 200 -gt 0x1ff', False),
> ('test 0x200 -gt 1ff', True),
>
> ('test 0x200 -lt 1ff', False),
> ('test 0x200 -eq 200', False),
> ('test 0x200 -ne 200', True),
>
> where some of them are failing without this patch
> ... test_hush_if_test[test 0x200 -gt 0x1ff-True]
>
> ... test_hush_if_test[test 200 -gt 0x1ff-False]
>
> ... test_hush_if_test[test 0x200 -gt 1ff-True]
>
> ... test_hush_if_test[test 0x200 -lt 1ff-False]
>
Any comment on this?
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [u-boot-imx/next] WaRP7 & Pico-Pi i.MX7 NOK
On 07/10/19 22:26, Pierre-Jean Texier wrote:
> Hi Stefano,
>
> Le 07/10/2019 à 21:58, Stefano Babic a écrit :
>> Hi Pierre-Jen,
>>
>> On 07/10/19 20:44, Pierre-Jean Texier wrote:
>>> Stefano, Peng,
>>>
>>> I just compiled a fresh U-Boot with u-boot-imx/next and It looks
>>> like commit 34f2feb ("imx: mmc_env: update runtime SD/MMC boot env
>>> device") [1]
>>> breaks my WaRP7 (but the same for the Pico-Pi i.MX7, tested by Joris in
>>> CC),
>>> see logs after:
>>>
>>> U-Boot 2019.10-rc4-00232-gd03193d (Oct 07 2019 - 18:44:25 +0200)
>>>
>>> CPU: Freescale i.MX7S rev1.2 800 MHz (running at 792 MHz)
>>> CPU: Extended Commercial temperature grade (-20C to 105C) at 33C
>>> Reset cause: POR
>>> Model: Warp i.MX7 Board
>>> Board: WARP7 in secure mode OPTEE DRAM 0x9d00-0xa000
>>> DRAM: 464 MiB
>>> MMC: FSL_SDHC: 1, FSL_SDHC: 0
>>> Loading Environment from MMC... MMC Device 2 not found
>>> *** Warning - No MMC card found, using default environment
>>> ...
>>> => env default -f -a
>>> ## Resetting to default environment
>>> => env save
>>> Saving Environment to MMC... MMC Device 2 not found
>>> No MMC card found
>>> Failed (1)
>>>
>>> FYI, with a git revert -s 34f2feb92db6146831bafa696b7b46785c9f6b10,
>>> all is working fine:
>>>
>>
>> Thanks for testing - at the moment, I will drop it from -next.
>
> No problem - thanks, I will update my repo after that.
>
>>
>>> => env default -f -a
>>> ## Resetting to default environment
>>> => env save
>>> Saving Environment to MMC... Writing to MMC(0)... OK
>>>
>>> So, can you consider this commit 'not applicable' for 2019.10 ?
>>>
>>
>> None of what you see in -next is for 2019.10. My last PR had already too
>> many patches and it cannot flow into 2019.10. Currently, -next has ~130
>> new commit, it cannot flow into the release - I will send PR afterwards.
>
> Understood, thanks for the clarification :).
>
Anyway, Peng's patch is not wrong, he simply tried to avoid to add board
code. But I left this out to avoid further breakages - I guess Peng
should send a folow up patch to add board code to imx8m.
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
[U-Boot] Please pull u-boot-x86
Hi Tom,
This PR includes the following changes for v2020.01:
- Rename existing FSP code to fsp1
- Add fsp2 directory in preparation to support FSP 2.0
- Various x86 platform codes update
- Various bug fixes and updates in dm core, sandbox and spl
GitLab CI passed
https://gitlab.denx.de/u-boot/custodians/u-boot-x86/pipelines/867
The following changes since commit 61ba1244b548463dbfb3c5285b6b22e7c772c5bd:
Prepare v2019.10 (2019-10-07 17:14:02 -0400)
are available in the git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-x86
for you to fetch changes up to cc2d27dcdc3e1c76d09d54015e3992380bd7e0fa:
x86: Use mtrr_commit() with FSP2 (2019-10-08 13:57:49 +0800)
Simon Glass (95):
x86: Rename existing FSP code to fsp1
x86: Move fsp_azalia.h to the generic fsp directory
x86: Create a new fsp_arch.h header
x86: Move fsp_api.h inclusion out of fsp_support.h
x86: Move fsp_types.h to the generic fsp directory
x86: Move fsp_fv.h to the generic fsp directory
x86: Move fsp_hob.h to the generic fsp directory
x86: Move fsp_infoheader.h to the generic fsp directory
x86: Move fsp_bootmode.h to the generic fsp directory
x86: Move fsp_ffs.h include to fsp_arch.h
binman: Pass the toolpath to binman from the main Makefile
binman: Allow selection of logging verbosity
mtd: spi: Add 'struct spi_flash {' to the code
serial: ns16550: Allow serial to enabled/disabled in SPL
spl: Avoid checking for Ctrl-C in SPL with print_buffer()
spl: handoff: Correct Kconfig condition for SPL and TPL
spl: Add an arch-specific hook for writing to SPL handoff
spl: Set up the bloblist in board_init_r()
spl: Add a function to determine the U-Boot phase
x86: sysreset: Allow reset driver to be included in SPL/TPL
x86: Rename some FSP functions to have an fsp_ prefix
x86: fsp: Create a common fsp_support.h header
x86: fsp: Use if() instead of #ifdef
x86: fsp: Tidy up comment style a little
x86: fsp: Move common dram functions into a common file
x86: Move common fsp functions into a common file
x86: fsp: Move common support functions into a common file
efi: Move inline functions to unconditional part of header
x86: fsp: Add a few more definitions for FSP2
x86: fsp: Add access to variable MRC data
x86: Move common Intel CPU info code into a function
x86: Add binman symbols to the image
x86: pci: Add a function to clear and set PCI config regs
x86: spl: Use hang() instead of a while() loop
x86: spl: Reduce priority of the basic SPL image loader
x86: spl: Move broadwell-specific code out of generic x86 spl
x86: fsp: Save usable RAM and hob_list in the handoff area
x86: Change condition for using CAR
x86: Add more comments to the start-up code
x86: Add various MTRR indexes and values
x86: Rename turbo ratio MSR to MSR_TURBO_RATIO_LIMIT
dm: core: Use U-Boot logging instead of pr_debug()
dm: core: Drop a few early returns
dm: core: Add documentation on how to debug driver model
dm: test: Fix running of multiple test from command line
dm: test: Don't fail when tests are skipped due to build
dm: core: Call ofdata_to_platdata() with of-platdata
dm: core: Correct the return value for uclass_find_first_device()
dm: core: Add device_foreach_child()
dm: test: Correct a stray backslash in dm_test_destroy()
sandbox: spmi: Add ranges property for address translation
sandbox: mmc: Fix up MMC emulator for valgrind
sandbox: Rename PCI ID for swap_case to be more specific
sandbox: Add support for clrsetio_32() and friends
sandbox: swap_case: Use statics where possible
sandbox: pci: Drop the get_devfn() method
sandbox: pci: Move pci_offset_to_barnum() to pci.h
sandbox: Add a -T flag to use the test device tree
sandbox: pci: Increase the memory space
sandbox: Allow use of real I/O with readl(), etc.
pci: sandbox: Move the emulators into their own node
pci: sandbox: Probe PCI emulation devices when used
pci: Show the result of binding a device
pci: Disable autoconfig in SPL
pci: Correct 'specifified' and 'Plese' typos
pci: Add more debug detail when resources are exhausted
pci: Show a message if PCI autoconfig fails
dm: pci: Add a function to read a PCI BAR
serial: ns16550: Add a PCI device/function field
binman: Allow verbose output with all commands
binman: Add a base implementation of Entry.ReadChildData()
binman: Handle reading data for end-at-4gb sections
binman: Take account of skip-at-start with image-header
log: Add log_nop() to avoid unused-variable warnings
cros_ec: Add MEC_EMI_BASE and size to the header file
iod: Enhance to
Re: [U-Boot] [PATCH v2 1/2] i.MX6: nand: extend nandbcb command for imx6UL(L)
On 08/10/19 10:12, Parthiban Nallathambi wrote:
> Hi Stefano,
>
> On 10/7/19 6:06 PM, Stefano Babic wrote:
>> Hi Parthiban,
>>
>> On 23/08/19 18:19, Parthiban Nallathambi wrote:
>>> Firmware Configuration Block(FCB) for imx6ul(l) needs to be
>>> BCH encoded. This patch depends on [1].
>>>
>>> [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=113810
>>>
>>
>> Why does it depend on this if it is just defoconfig for a board ?
>
> The patch series was nandbcb inclusion, but this is already merged in u-boot.
> patchwork query shows only the pending merger now.
>
> As the nandbcb is already in mainline, this patch should apply fine.
Please read the whole e-mail. Issue is not that patch cannot be applied,
issue is that it breaks several boards. All i.MX6 boards with NAND -
check again:
>> Building current source for 1 boards (1 thread, 8 jobs per thread)
>>arm: + pfla02
>> +arch/arm/mach-imx/built-in.o: In function `encode_bch_ecc':
>> +arch/arm/mach-imx/cmd_nandbcb.c:45: undefined reference to `init_bch'
>> +arch/arm/mach-imx/cmd_nandbcb.c:75: undefined reference to `encode_bch'
>> +arch/arm/mach-imx/cmd_nandbcb.c:87: undefined reference to `free_bch'
>> +arm-poky-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.28.0.20170307
>> assertion fail ../../bfd/elf32-arm.c:9512
>> +make[1]: *** [u-boot] Error 1
>> +make: *** [sub-make] Error 2
>> 001 /1 pfla02
The same happens to other boards, too.
Best regards,
Stefano Babic
>
> Thanks,
> Parthiban N
>
>>
>>> Signed-off-by: Parthiban Nallathambi
>>> Acked-by: Shyam Saini
>>> ---
>>>
>>> Notes:
>>> Changes in v2:
>>> - use kfree instead of free
>>>
>>> arch/arm/mach-imx/Kconfig | 1 +
>>> arch/arm/mach-imx/cmd_nandbcb.c | 72 -
>>> 2 files changed, 71 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>>> index aeb5493488..175bed601e 100644
>>> --- a/arch/arm/mach-imx/Kconfig
>>> +++ b/arch/arm/mach-imx/Kconfig
>>> @@ -74,6 +74,7 @@ config CMD_HDMIDETECT
>>> config CMD_NANDBCB
>>> bool "i.MX6 NAND Boot Control Block(BCB) command"
>>> depends on NAND && CMD_MTDPARTS
>>> + select BCH if MX6UL || MX6ULL
>>
>> This eems to break all i.MX6 boards (not UL(L)) using NAND. In fact, I
>> get these errors:
>>
>> Building current source for 1 boards (1 thread, 8 jobs per thread)
>>arm: + pfla02
>> +arch/arm/mach-imx/built-in.o: In function `encode_bch_ecc':
>> +arch/arm/mach-imx/cmd_nandbcb.c:45: undefined reference to `init_bch'
>> +arch/arm/mach-imx/cmd_nandbcb.c:75: undefined reference to `encode_bch'
>> +arch/arm/mach-imx/cmd_nandbcb.c:87: undefined reference to `free_bch'
>> +arm-poky-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.28.0.20170307
>> assertion fail ../../bfd/elf32-arm.c:9512
>> +make[1]: *** [u-boot] Error 1
>> +make: *** [sub-make] Error 2
>> 001 /1 pfla02
>>
>> Can you check this please ? I temporary remove the patch from -next branch.
>>
>> Best regards,
>> Stefano Babic
>>
>>> default y if ARCH_MX6 && NAND_MXS
>>> help
>>> Unlike normal 'nand write/erase' commands, this command update
>>> diff --git a/arch/arm/mach-imx/cmd_nandbcb.c
>>> b/arch/arm/mach-imx/cmd_nandbcb.c
>>> index 065b814b2e..e11df401e4 100644
>>> --- a/arch/arm/mach-imx/cmd_nandbcb.c
>>> +++ b/arch/arm/mach-imx/cmd_nandbcb.c
>>> @@ -14,8 +14,10 @@
>>>
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> +#include
>>> #include
>>> #include
>>> #include
>>> @@ -25,6 +27,66 @@
>>> #define BF_VAL(v, bf) (((v) & bf##_MASK) >> bf##_OFFSET)
>>> #define GETBIT(v, n) (((v) >> (n)) & 0x1)
>>>
>>> +static uint8_t reverse_bit(uint8_t b)
>>> +{
>>> + b = (b & 0xf0) >> 4 | (b & 0x0f) << 4;
>>> + b = (b & 0xcc) >> 2 | (b & 0x33) << 2;
>>> + b = (b & 0xaa) >> 1 | (b & 0x55) << 1;
>>> +
>>> + return b;
>>> +}
>>> +
>>> +static void encode_bch_ecc(void *buf, struct fcb_block *fcb, int eccbits)
>>> +{
>>> + int i, j, m = 13;
>>> + int blocksize = 128;
>>> + int numblocks = 8;
>>> + int ecc_buf_size = (m * eccbits + 7) / 8;
>>> + struct bch_control *bch = init_bch(m, eccbits, 0);
>>> + u8 *ecc_buf = kzalloc(ecc_buf_size, GFP_KERNEL);
>>> + u8 *tmp_buf = kzalloc(blocksize * numblocks, GFP_KERNEL);
>>> + u8 *psrc, *pdst;
>>> +
>>> + /*
>>> +* The blocks here are bit aligned. If eccbits is a multiple of 8,
>>> +* we just can copy bytes. Otherwiese we must move the blocks to
>>> +* the next free bit position.
>>> +*/
>>> + WARN_ON(eccbits % 8);
>>> +
>>> + memcpy(tmp_buf, fcb, sizeof(*fcb));
>>> +
>>> + for (i = 0; i < numblocks; i++) {
>>> + memset(ecc_buf, 0, ecc_buf_size);
>>> + psrc = tmp_buf + i * blocksize;
>>> + pdst = buf + i * (blocksize + ecc_buf_size);
>>> +
>>> + /* copy data byte aligned to destination buf */
>>> + memcpy(pdst, psrc, blocksize);
>>> +
>>>
Re: [U-Boot] [PATCH v2 1/2] i.MX6: nand: extend nandbcb command for imx6UL(L)
Hi Stefano,
On 10/7/19 6:06 PM, Stefano Babic wrote:
> Hi Parthiban,
>
> On 23/08/19 18:19, Parthiban Nallathambi wrote:
>> Firmware Configuration Block(FCB) for imx6ul(l) needs to be
>> BCH encoded. This patch depends on [1].
>>
>> [1]: https://patchwork.ozlabs.org/project/uboot/list/?series=113810
>>
>
> Why does it depend on this if it is just defoconfig for a board ?
The patch series was nandbcb inclusion, but this is already merged in u-boot.
patchwork query shows only the pending merger now.
As the nandbcb is already in mainline, this patch should apply fine.
Thanks,
Parthiban N
>
>> Signed-off-by: Parthiban Nallathambi
>> Acked-by: Shyam Saini
>> ---
>>
>> Notes:
>> Changes in v2:
>> - use kfree instead of free
>>
>> arch/arm/mach-imx/Kconfig | 1 +
>> arch/arm/mach-imx/cmd_nandbcb.c | 72 -
>> 2 files changed, 71 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
>> index aeb5493488..175bed601e 100644
>> --- a/arch/arm/mach-imx/Kconfig
>> +++ b/arch/arm/mach-imx/Kconfig
>> @@ -74,6 +74,7 @@ config CMD_HDMIDETECT
>> config CMD_NANDBCB
>> bool "i.MX6 NAND Boot Control Block(BCB) command"
>> depends on NAND && CMD_MTDPARTS
>> +select BCH if MX6UL || MX6ULL
>
> This eems to break all i.MX6 boards (not UL(L)) using NAND. In fact, I
> get these errors:
>
> Building current source for 1 boards (1 thread, 8 jobs per thread)
>arm: + pfla02
> +arch/arm/mach-imx/built-in.o: In function `encode_bch_ecc':
> +arch/arm/mach-imx/cmd_nandbcb.c:45: undefined reference to `init_bch'
> +arch/arm/mach-imx/cmd_nandbcb.c:75: undefined reference to `encode_bch'
> +arch/arm/mach-imx/cmd_nandbcb.c:87: undefined reference to `free_bch'
> +arm-poky-linux-gnueabi-ld.bfd: BFD (GNU Binutils) 2.28.0.20170307
> assertion fail ../../bfd/elf32-arm.c:9512
> +make[1]: *** [u-boot] Error 1
> +make: *** [sub-make] Error 2
> 001 /1 pfla02
>
> Can you check this please ? I temporary remove the patch from -next branch.
>
> Best regards,
> Stefano Babic
>
>> default y if ARCH_MX6 && NAND_MXS
>> help
>>Unlike normal 'nand write/erase' commands, this command update
>> diff --git a/arch/arm/mach-imx/cmd_nandbcb.c
>> b/arch/arm/mach-imx/cmd_nandbcb.c
>> index 065b814b2e..e11df401e4 100644
>> --- a/arch/arm/mach-imx/cmd_nandbcb.c
>> +++ b/arch/arm/mach-imx/cmd_nandbcb.c
>> @@ -14,8 +14,10 @@
>>
>> #include
>> #include
>> +#include
>> #include
>>
>> +#include
>> #include
>> #include
>> #include
>> @@ -25,6 +27,66 @@
>> #define BF_VAL(v, bf) (((v) & bf##_MASK) >> bf##_OFFSET)
>> #define GETBIT(v, n)(((v) >> (n)) & 0x1)
>>
>> +static uint8_t reverse_bit(uint8_t b)
>> +{
>> +b = (b & 0xf0) >> 4 | (b & 0x0f) << 4;
>> +b = (b & 0xcc) >> 2 | (b & 0x33) << 2;
>> +b = (b & 0xaa) >> 1 | (b & 0x55) << 1;
>> +
>> +return b;
>> +}
>> +
>> +static void encode_bch_ecc(void *buf, struct fcb_block *fcb, int eccbits)
>> +{
>> +int i, j, m = 13;
>> +int blocksize = 128;
>> +int numblocks = 8;
>> +int ecc_buf_size = (m * eccbits + 7) / 8;
>> +struct bch_control *bch = init_bch(m, eccbits, 0);
>> +u8 *ecc_buf = kzalloc(ecc_buf_size, GFP_KERNEL);
>> +u8 *tmp_buf = kzalloc(blocksize * numblocks, GFP_KERNEL);
>> +u8 *psrc, *pdst;
>> +
>> +/*
>> + * The blocks here are bit aligned. If eccbits is a multiple of 8,
>> + * we just can copy bytes. Otherwiese we must move the blocks to
>> + * the next free bit position.
>> + */
>> +WARN_ON(eccbits % 8);
>> +
>> +memcpy(tmp_buf, fcb, sizeof(*fcb));
>> +
>> +for (i = 0; i < numblocks; i++) {
>> +memset(ecc_buf, 0, ecc_buf_size);
>> +psrc = tmp_buf + i * blocksize;
>> +pdst = buf + i * (blocksize + ecc_buf_size);
>> +
>> +/* copy data byte aligned to destination buf */
>> +memcpy(pdst, psrc, blocksize);
>> +
>> +/*
>> + * imx-kobs use a modified encode_bch which reverse the
>> + * bit order of the data before calculating bch.
>> + * Do this in the buffer and use the bch lib here.
>> + */
>> +for (j = 0; j < blocksize; j++)
>> +psrc[j] = reverse_bit(psrc[j]);
>> +
>> +encode_bch(bch, psrc, blocksize, ecc_buf);
>> +
>> +/* reverse ecc bit */
>> +for (j = 0; j < ecc_buf_size; j++)
>> +ecc_buf[j] = reverse_bit(ecc_buf[j]);
>> +
>> +/* Here eccbuf is byte aligned and we can just copy it */
>> +memcpy(pdst + blocksize, ecc_buf, ecc_buf_size);
>> +}
>> +
>> +kfree(ecc_buf);
>> +kfree(tmp_buf);
>> +free_bch(bch);
>> +}
>> +
>> static u8 calculate_parity_13_8(u8 d)
>> {
>> u8 p = 0;
>> @@ -231,8 +293,14 @@ static int nandbcb_update(struct mtd_info *mtd, loff_t
>> off, size_t size,
Re: [U-Boot] [PATCH 0/5] xilinx: Introduce Zynq/ZynqMP virtual defconfig
čt 3. 10. 2019 v 12:33 odesílatel Michal Simek napsal: > > Hi, > > The following patch series implements a common function to get the dtb > for of_board configuration. Additionally provides a virtual defconfig > for Zynq and ZynqMP architectures with of_board configuration enabled. > > In future this should go in a way where we could remove all board specific > defconfigs for Zynq/ZynqMP boards. > > Thanks, > Michal > > > Ibai Erkiaga (5): > arm64: versal: Move common board dtb search > arm64: xilinx: Enable generic of_board_dtb > arm64: zynqmp: Introduce virtual defconfig > ARM: zynq: Introduce virtual defconfig > arm64: versal: remove debug uart for versal virt > > arch/arm/mach-versal/Kconfig | 5 -- > arch/arm/mach-versal/cpu.c | 21 -- > board/xilinx/Kconfig | 8 ++ > board/xilinx/common/board.c | 14 > configs/xilinx_versal_virt_defconfig | 5 -- > configs/xilinx_zynqmp_virt_defconfig | 108 +++ > configs/zynq_virt_defconfig | 79 > 7 files changed, 209 insertions(+), 31 deletions(-) > create mode 100644 configs/xilinx_zynqmp_virt_defconfig > create mode 100644 configs/zynq_virt_defconfig > > -- > 2.17.1 > There is nothing controversy with this that's why I have applied it for MW and let's see if something needs to be fixed. It is clear that there will be some patches for adding defconfig options to be generic as much as possible. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/13] arm64: zynqmp: Clean communication with PMUFW
st 2. 10. 2019 v 15:39 odesílatel Michal Simek napsal: > > Hi, > > This patch series using ZynqMP firmware driver to provide a interface to > communicate with the PMU Firmware. As part of the series a mailbox driver > is also implemented to handle communication through ipi interface. > > There are two new wiring: > 1. Reading PMUFW version via firmware driver > - mailbox driver in case of SPL > - SMC in case of full U-Boot > 2. Using the same patch for loading PMUFW configuration object > > The whole series is based on several patches I have sent already that's why > I am providing a branch which also contains this series. > https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze/tree/next > > Thanks, > Michal > > Changes in v2: > - Check error separately - Reported by Luca > - Align ret handling > - Also handle error from mbox_recv/mbox_send > - Move pm_api_id higher - Reported by Luca > - Fix macros for header protection > - pass rex_maxlen to ipi_req - reported by Luca > > Ibai Erkiaga (10): > mailbox: check ops prior calling > mailbox: allow subnode for mbox regs > mailbox: zynqmp: ipi mailbox driver > firmware: zynqmp: Add zynqmp-power support Applied all. Only in this patch I have fixed dependencies to be selected via ARCH fragment. Because IPI driver hasn't been adopted by Versal to be able to select IPI directly. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm64: versal: Enable clock driver
pá 4. 10. 2019 v 15:05 odesílatel Michal Simek napsal: > > Enable clock driver for Versal. > > Signed-off-by: Michal Simek > --- > > configs/xilinx_versal_virt_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/xilinx_versal_virt_defconfig > b/configs/xilinx_versal_virt_defconfig > index 75f8b983080d..f924d3e54221 100644 > --- a/configs/xilinx_versal_virt_defconfig > +++ b/configs/xilinx_versal_virt_defconfig > @@ -45,6 +45,7 @@ CONFIG_OF_BOARD=y > CONFIG_NET_RANDOM_ETHADDR=y > CONFIG_IP_DEFRAG=y > CONFIG_TFTP_BLOCKSIZE=4096 > +CONFIG_CLK_VERSAL=y > CONFIG_DM_GPIO=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_CADENCE=y > -- > 2.17.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 00/10] microblaze: External initrd support
st 25. 9. 2019 v 13:42 odesílatel Michal Simek napsal: > > Hi, > > Microblaze is not changing a lot but there was a real pain for not > supporting external initrd. That's why several patches in the series are > fixing this issue. The rest of patches are just cleanup which I found > when I was trying to fix it. > > Thanks, > Michal > > > Michal Simek (10): > microblaze: Remove unused variable ram_base > microblaze: Move CONFIG_LMB from board file to config.h > microblaze: Fix lmb memory initialization > microblaze: Define arch_lmb_reserve > microblaze: Switch to generic bootm implementation > microblaze: Enable cache by default > microblaze: Setup reasonable maximum bootm len > microblaze: Setup initrd_high and fdt_high at run time > microblaze: Remove additional headers > microblaze: Enable random mac generation > > arch/microblaze/Kconfig | 8 ++ > arch/microblaze/include/asm/config.h | 4 + > arch/microblaze/lib/bootm.c | 136 +++--- > .../microblaze-generic/microblaze-generic.c | 28 ++-- > common/image.c| 5 +- > configs/microblaze-generic_defconfig | 2 + > include/configs/microblaze-generic.h | 8 +- > 7 files changed, 129 insertions(+), 62 deletions(-) > > -- > 2.17.1 > Applied all. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] arm64: zynqmp: Define default SYS_PROMPT
st 25. 9. 2019 v 12:38 odesílatel Michal Simek napsal: > > All boards are using the same prompt that's why add it as default value to > Kconfig to simplify defconfigs. > > Signed-off-by: Michal Simek > --- > > cmd/Kconfig| 1 + > configs/avnet_ultra96_rev1_defconfig | 1 - > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 - > configs/xilinx_zynqmp_a2197_g_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_m_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_p_revA_defconfig | 1 - > configs/xilinx_zynqmp_a2197_revA_defconfig | 1 - > configs/xilinx_zynqmp_mini_defconfig | 1 - > configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 - > configs/xilinx_zynqmp_mini_emmc1_defconfig | 1 - > configs/xilinx_zynqmp_mini_nand_defconfig | 1 - > configs/xilinx_zynqmp_mini_qspi_defconfig | 1 - > configs/xilinx_zynqmp_zc1232_revA_defconfig| 1 - > configs/xilinx_zynqmp_zc1254_revA_defconfig| 1 - > configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm017_dc3_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 - > configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 - > configs/xilinx_zynqmp_zcu100_revC_defconfig| 1 - > configs/xilinx_zynqmp_zcu102_rev1_0_defconfig | 1 - > configs/xilinx_zynqmp_zcu102_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu102_revB_defconfig| 1 - > configs/xilinx_zynqmp_zcu104_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu104_revC_defconfig| 1 - > configs/xilinx_zynqmp_zcu106_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu111_revA_defconfig| 1 - > configs/xilinx_zynqmp_zcu1275_revA_defconfig | 1 - > configs/xilinx_zynqmp_zcu1275_revB_defconfig | 1 - > 29 files changed, 1 insertion(+), 28 deletions(-) > > diff --git a/cmd/Kconfig b/cmd/Kconfig > index ab65f87999dc..65360a69beb6 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -49,6 +49,7 @@ config SYS_LONGHELP > config SYS_PROMPT > string "Shell prompt" > default "Zynq> " if ARCH_ZYNQ > + default "ZynqMP> " if ARCH_ZYNQMP > default "=> " > help > This string is displayed in the command line to the left of the > diff --git a/configs/avnet_ultra96_rev1_defconfig > b/configs/avnet_ultra96_rev1_defconfig > index 924153081149..b5e61e621acd 100644 > --- a/configs/avnet_ultra96_rev1_defconfig > +++ b/configs/avnet_ultra96_rev1_defconfig > @@ -17,7 +17,6 @@ CONFIG_SPL_OS_BOOT=y > CONFIG_SPL_RAM_SUPPORT=y > CONFIG_SPL_RAM_DEVICE=y > CONFIG_SPL_ATF=y > -CONFIG_SYS_PROMPT="ZynqMP> " > CONFIG_CMD_BOOTMENU=y > CONFIG_CMD_MEMTEST=y > CONFIG_CMD_BIND=y > diff --git a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig > b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig > index f463318565ff..b9bb0c9b1112 100644 > --- a/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig > +++ b/configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig > @@ -16,7 +16,6 @@ CONFIG_SPL_LOAD_FIT=y > CONFIG_BOOTDELAY=0 > # CONFIG_DISPLAY_CPUINFO is not set > CONFIG_SPL_OS_BOOT=y > -CONFIG_SYS_PROMPT="ZynqMP> " > CONFIG_CMD_MEMTEST=y > CONFIG_CMD_FPGA_LOADBP=y > CONFIG_CMD_FPGA_LOADP=y > diff --git a/configs/xilinx_zynqmp_a2197_g_revA_defconfig > b/configs/xilinx_zynqmp_a2197_g_revA_defconfig > index 2f6dc7641a80..47a98c6d4d8b 100644 > --- a/configs/xilinx_zynqmp_a2197_g_revA_defconfig > +++ b/configs/xilinx_zynqmp_a2197_g_revA_defconfig > @@ -21,7 +21,6 @@ CONFIG_SPL_OS_BOOT=y > CONFIG_SPL_RAM_SUPPORT=y > CONFIG_SPL_RAM_DEVICE=y > CONFIG_SPL_ATF=y > -CONFIG_SYS_PROMPT="ZynqMP> " > CONFIG_CMD_THOR_DOWNLOAD=y > CONFIG_CMD_MEMTEST=y > CONFIG_SYS_ALT_MEMTEST=y > diff --git a/configs/xilinx_zynqmp_a2197_m_revA_defconfig > b/configs/xilinx_zynqmp_a2197_m_revA_defconfig > index d9107d6bb867..fb4020b2dfed 100644 > --- a/configs/xilinx_zynqmp_a2197_m_revA_defconfig > +++ b/configs/xilinx_zynqmp_a2197_m_revA_defconfig > @@ -21,7 +21,6 @@ CONFIG_SPL_OS_BOOT=y > CONFIG_SPL_RAM_SUPPORT=y > CONFIG_SPL_RAM_DEVICE=y > CONFIG_SPL_ATF=y > -CONFIG_SYS_PROMPT="ZynqMP> " > CONFIG_CMD_THOR_DOWNLOAD=y > CONFIG_CMD_MEMTEST=y > CONFIG_SYS_ALT_MEMTEST=y > diff --git a/configs/xilinx_zynqmp_a2197_p_revA_defconfig > b/configs/xilinx_zynqmp_a2197_p_revA_defconfig > index 4ce634cdaacf..d19c6b34cac6 100644 > --- a/configs/xilinx_zynqmp_a2197_p_revA_defconfig > +++
Re: [U-Boot] [PATCH] configs: apalis-tk1: Do not define CONFIG_SYS_BOOT_RAMDISK_HIGH again
st 25. 9. 2019 v 11:16 odesílatel Michal Simek napsal: > > CONFIG_SYS_BOOT_RAMDISK_HIGH is already defined in > arch/arm/include/asm/config.h:10:#define CONFIG_SYS_BOOT_RAMDISK_HIGH > that's why there is no reason to define it again in board file. > > Signed-off-by: Michal Simek > --- > > include/configs/apalis-tk1.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/include/configs/apalis-tk1.h b/include/configs/apalis-tk1.h > index dacf36bf79c8..fe45917b885d 100644 > --- a/include/configs/apalis-tk1.h > +++ b/include/configs/apalis-tk1.h > @@ -138,8 +138,6 @@ > > #define CONFIG_CMD_TIME > > -#define CONFIG_SYS_BOOT_RAMDISK_HIGH > - > #include "tegra-common-usb-gadget.h" > #include "tegra-common-post.h" > > -- > 2.17.1 > Didn't get any reaction on this that's why I am taking it via xilinx tree to mainline. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] arm64: zynqmp: Add support for Versal system controller
čt 19. 9. 2019 v 10:14 odesílatel Michal Simek napsal: > > Hi, > > these patches are adding support for System controller on Versal board > which is capable to monitor and talk to Versal device. > > Thanks, > Michal > > > Michal Simek (3): > arm64: zynqmp: Add generic a2197 system controller config > arm64: zynqmp: Add System Controller for a2197-g/p > arm64: zynqmp: Add a2197 memory board revA > > arch/arm/dts/Makefile |4 + > arch/arm/dts/zynqmp-a2197-g-revA.dts | 282 > arch/arm/dts/zynqmp-a2197-m-revA.dts | 461 +++ > arch/arm/dts/zynqmp-a2197-p-revA.dts | 567 > arch/arm/dts/zynqmp-a2197-revA.dts| 89 ++ > board/xilinx/zynqmp/zynqmp-a2197-g-revA |1 + > board/xilinx/zynqmp/zynqmp-a2197-m-revA |1 + > board/xilinx/zynqmp/zynqmp-a2197-p-revA |1 + > .../zynqmp/zynqmp-a2197-revA/psu_init_gpl.c | 1171 + > configs/xilinx_zynqmp_a2197_g_revA_defconfig | 116 ++ > configs/xilinx_zynqmp_a2197_m_revA_defconfig | 116 ++ > configs/xilinx_zynqmp_a2197_p_revA_defconfig | 117 ++ > configs/xilinx_zynqmp_a2197_revA_defconfig| 118 ++ > 13 files changed, 3044 insertions(+) > create mode 100644 arch/arm/dts/zynqmp-a2197-g-revA.dts > create mode 100644 arch/arm/dts/zynqmp-a2197-m-revA.dts > create mode 100644 arch/arm/dts/zynqmp-a2197-p-revA.dts > create mode 100644 arch/arm/dts/zynqmp-a2197-revA.dts > create mode 12 board/xilinx/zynqmp/zynqmp-a2197-g-revA > create mode 12 board/xilinx/zynqmp/zynqmp-a2197-m-revA > create mode 12 board/xilinx/zynqmp/zynqmp-a2197-p-revA > create mode 100644 board/xilinx/zynqmp/zynqmp-a2197-revA/psu_init_gpl.c > create mode 100644 configs/xilinx_zynqmp_a2197_g_revA_defconfig > create mode 100644 configs/xilinx_zynqmp_a2197_m_revA_defconfig > create mode 100644 configs/xilinx_zynqmp_a2197_p_revA_defconfig > create mode 100644 configs/xilinx_zynqmp_a2197_revA_defconfig > > -- > 2.17.1 > Applied all. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
