Re: [U-Boot] [PATCH] ARM: mvebu: sync Armada-38x dts with Linux 4.20
Hi Chris,
On Fri, Dec 07, 2018 at 04:21:47PM +1300, Chris Packham wrote:
> Sync the Armada-38x device tree files with Linux 4.20-rc5. The changes
> not taken are new compatible strings for the uart and nand flash
> controller. The nand binding is best updated if/when the mtd/nand
> infrastructure is updated.
>
> Signed-off-by: Chris Packham
> ---
> I've updated the clearfog and controlcenterdc boards enough for them to
> compile. In the case of clearfog there are a lot of changes in Linux so
> it's probably best if the board maintainer looks at what is needed.
> controlcenterdc isn't in linux so again I've just done enough for
> compilation.
[...]
> diff --git a/arch/arm/dts/armada-388-clearfog.dts
> b/arch/arm/dts/armada-388-clearfog.dts
> index 16a47d59e667..a70ce0391221 100644
> --- a/arch/arm/dts/armada-388-clearfog.dts
> +++ b/arch/arm/dts/armada-388-clearfog.dts
> @@ -118,18 +118,7 @@
> status = "okay";
> };
>
> - spi1: spi@10680 {
> - /*
> - * CS0: W25Q32
> - * CS1:
> - * CS2: mikrobus
> - */
> - pinctrl-0 = <_pins _spi1_cs_pins
> _spi_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> - };
> -
> - usb0: usb3@f8000 {
> + usb3@f8000 {
> /* CON7, USB-A port on back of device */
> status = "okay";
> };
> @@ -322,6 +311,18 @@
> };
> };
>
> + {
> + /*
> + * Add SPI CS pins for clearfog:
> + * CS0: W25Q32
> + * CS1: PIC microcontroller (Pro models)
> + * CS2: mikrobus
> + */
> + pinctrl-0 = <_pins _spi_pins>;
> + pinctrl-names = "default";
> + status = "okay";
You took this from the kernel armada-388-clearfog.dtsi but ignored
armada-388-clearfog.dts. This is a mess, actually. Both are wrong in different
ways.
In this patch, the removal of _spi1_cs_pins is right. The addition of
the "CS1: PIC microcontroller" comment is wrong. In production Clearfog Pro
model the PIC controller is not assembled. Even the PIC assembly option does
not included SPI signals. See page 10 of the schematics:
https://wiki.solid-run.com/lib/exe/fetch.php?media=a38x:carrierboard:docs:clearfog-schematics-2.1.pdf
baruch
> +};
> +
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 00/11] mtd/sf: Various fixes
+Tom for the question about missing SoBs.
Hi Jagan,
On Thu, 6 Dec 2018 00:48:47 +0530
Jagan Teki wrote:
> On Sun, Dec 2, 2018 at 3:25 PM Boris Brezillon
> wrote:
> >
> > Hello,
> >
> > This is the 4th version of the mtd / sf fixes patchset. This v4 just
> > adds a new check in del_mtd_device() (and a debug() when
> > del_mtd_partitions() fails).
> >
> > Regards,
> >
> > Boris
> >
> > P.S.: travis-ci results =>
> > https://travis-ci.org/bbrezillon/u-boot/builds/461943011
> >
> > Boris Brezillon (11):
> > mtd: Add a function to report when the MTD dev list has been updated
> > mtd: Parse mtdparts/mtdids again when the MTD list has been updated
> > mtd: Delete partitions attached to the device when a device is deleted
> > mtd: sf: Make sure we don't register the same device twice
> > mtd: Use get_mtdids() instead of env_get("mtdids") in
> > mtd_search_alternate_name()
> > mtd: Be more strict on the "mtdparts=" prefix check
> > mtd: Make sure the name passed in mtdparts fits in mtd_name[]
> > mtd: Make sure we don't parse MTD partitions belonging to another dev
> > mtd: Don't stop MTD partition creation when it fails on one device
> > mtd: sf: Unregister the MTD device prior to removing the spi_flash obj
> > mtd: sf: Make sf_mtd.c more robust
>
> Applied to u-boot-spi/master
I see that those patches have been merged in mainline, which is great.
Just have one question: looks like your SoB is missing while you're
clearly reported as the committer. Since I found the same problem on
2614a208471e ("common: command: tempory buffer should have size of
command line buf"), I wanted to know if this is a common practice in
u-boot to not add SoBs when maintainers apply patches to their tree?
Regards,
Boris
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Unable to saveenv to MMC
How would I go about validating whether I can access the partition from u-boot? On Fri, Dec 7, 2018 at 1:47 AM Frank Wunderlich wrote: > can you try to access the partiton from uboot? > > ls mmc 0:0 > > regards Frank > > > Von: "Robin Polak" > > I'm having trouble persisting my environment variables to the SD Card > > onto which I have FAT formatted and then written U-Boot to using the > > following command: > > ... > > => saveenv > > Saving Environment to FAT... Unable to use mmc 0:0... Failed (1) > -- -- Robin Polak ro...@robinpolak.com 917-494-2080 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/2] Roll CRC16-CCITT into the hash infrastructure
On Sun, Nov 25, 2018 at 07:22:19PM +0100, Philipp Tomsich wrote: > The CRC16-CCITT checksum function is useful for space-constrained > applications (such as obtaining a checksum across a 2KBit or 4KBit > EEPROM) in boot applications. It has not been accessible from boot > scripts until now (due to not having a dedicated command and not being > supported by the hash infrstructure) limiting its applicability > outside of custom commands. > > This adds the CRC16-CCITT (poly 0x1021, init 0x0) algorithm to the > list of available hashes and adds a new crc16_ccitt_wd_buf() to make > this possible. > > Signed-off-by: Philipp Tomsich 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] [U-Boot,1/2] lib: merge CRC16-CCITT into u-boot/crc.h
On Sun, Nov 25, 2018 at 07:22:18PM +0100, Philipp Tomsich wrote: > This merges the CRC16-CCITT headers into u-boot/crc.h to prepare for > rolling CRC16 into the hash infrastructure. Given that CRC8, CRC32 > and CRC32-C already have their prototypes in a single header file, it > seems a good idea to also include CRC16-CCITT in the same. > > Signed-off-by: Philipp Tomsich 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] [BUG] Odroid-C2 does not boot with U-Boot master anymore
On 08.12.18 14:16, Heinrich Schuchardt wrote:
> Hello Alex,
>
> the patch 7a82c3051c8f ("efi_loader: Align runtime section to 64kb")
> currently breaks booting Linux on the Odroid-C2.
>
> Output stops for kernel 4.18 after earlycon is replaced:
> [0.012518] console [tty0] enabled
> [0.015923] bootconsole [meson0] disabled
> Without your patch it continues.
>
> The calculation introduced by the patch does what is expected:
> ram_start = 0x
> ram_end = 0x8000
> __efi_runtime_start = 0x7ff67118
> ~runtime_mask = 0x
> runtime_start = 0x7ff6
> runtime_end = 0x7ff7
>
> These two memory reservation do not conflict with addresses in question:
> arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
> 0x-0x0100
> arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
> 0x1000-0x1020
I'll write up a nice patch description after some sleep, but here's at
least something that makes it work again for me:
diff --git a/lib/efi_loader/efi_runtime.c b/lib/efi_loader/efi_runtime.c
index 95844efdb0..4f2aa9deda 100644
--- a/lib/efi_loader/efi_runtime.c
+++ b/lib/efi_loader/efi_runtime.c
@@ -436,8 +436,13 @@ static efi_status_t EFIAPI efi_set_virtual_address_map(
uint32_t descriptor_version,
struct efi_mem_desc *virtmap)
{
+#if defined(__aarch64__)
+ unsigned long runtime_mask = SZ_64K - 1;
+#else
+ unsigned long runtime_mask = EFI_PAGE_MASK;
+#endif
ulong runtime_start = (ulong)&__efi_runtime_start &
- ~(ulong)EFI_PAGE_MASK;
+ ~runtime_mask;
int n = memory_map_size / descriptor_size;
int i;
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 01/11] mtd: Add a function to report when the MTD dev list has been updated
Hi Boris,
> We need to parse mtdparts/mtids again everytime a device has been
> added/removed from the MTD list, but there's currently no way to know
> when such an update has been done.
>
> Add an ->updated field to the idr struct that we set to true every
> time a device is added/removed and expose a function returning the
> value of this field and resetting it to false.
>
> Signed-off-by: Boris Brezillon
> Tested-by: Heiko Schocher
This series fixed a but on Vybrid, when I run several times "mtdpart
default" after calling sf probe for two SPI-NOR memories.
When I called "mtdpart default" for the second time, the mtd partitions
were gone despite being visible with "mtdparts" command.
Hence,
Tested-by: Lukasz Majewski
> ---
> Changes in v4:
> - Add T-b tag
>
> Changes in v2:
> - None
>
> Changes in v2:
> - None
> ---
> drivers/mtd/mtdcore.c | 16 +++-
> include/linux/mtd/mtd.h | 1 +
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
> index fb6c779abbfe..7a15ded8c883 100644
> --- a/drivers/mtd/mtdcore.c
> +++ b/drivers/mtd/mtdcore.c
> @@ -87,14 +87,17 @@ struct idr_layer {
>
> struct idr {
> struct idr_layer id[MAX_IDR_ID];
> + bool updated;
> };
>
> #define DEFINE_IDR(name) struct idr name;
>
> void idr_remove(struct idr *idp, int id)
> {
> - if (idp->id[id].used)
> + if (idp->id[id].used) {
> idp->id[id].used = 0;
> + idp->updated = true;
> + }
>
> return;
> }
> @@ -134,6 +137,7 @@ int idr_alloc(struct idr *idp, void *ptr, int
> start, int end, gfp_t gfp_mask) if (idl->used == 0) {
> idl->used = 1;
> idl->ptr = ptr;
> + idp->updated = true;
> return i;
> }
> i++;
> @@ -155,6 +159,16 @@ struct mtd_info *__mtd_next_device(int i)
> }
> EXPORT_SYMBOL_GPL(__mtd_next_device);
>
> +bool mtd_dev_list_updated(void)
> +{
> + if (mtd_idr.updated) {
> + mtd_idr.updated = false;
> + return true;
> + }
> +
> + return false;
> +}
> +
> #ifndef __UBOOT__
> static LIST_HEAD(mtd_notifiers);
>
> diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> index 68e591532492..d20ebd820289 100644
> --- a/include/linux/mtd/mtd.h
> +++ b/include/linux/mtd/mtd.h
> @@ -581,6 +581,7 @@ int mtd_arg_off_size(int argc, char *const
> argv[], int *idx, loff_t *off, void mtd_get_len_incl_bad(struct
> mtd_info *mtd, uint64_t offset, const uint64_t length, uint64_t
> *len_incl_bad, int *truncated);
> +bool mtd_dev_list_updated(void);
>
> /* drivers/mtd/mtd_uboot.c */
> int mtd_search_alternate_name(const char *mtdname, char *altname,
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpBvnDpesKa7.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [BUG] Odroid-C2 does not boot with U-Boot master anymore
On 08.12.18 14:16, Heinrich Schuchardt wrote:
> Hello Alex,
>
> the patch 7a82c3051c8f ("efi_loader: Align runtime section to 64kb")
> currently breaks booting Linux on the Odroid-C2.
>
> Output stops for kernel 4.18 after earlycon is replaced:
> [0.012518] console [tty0] enabled
> [0.015923] bootconsole [meson0] disabled
> Without your patch it continues.
>
> The calculation introduced by the patch does what is expected:
> ram_start = 0x
> ram_end = 0x8000
> __efi_runtime_start = 0x7ff67118
> ~runtime_mask = 0x
> runtime_start = 0x7ff6
> runtime_end = 0x7ff7
>
> These two memory reservation do not conflict with addresses in question:
> arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
> 0x-0x0100
> arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
> 0x1000-0x1020
We had an unaligned runtime start before already, so I don't quite
understand yet why increasing that to 64kb would break things.
I do fully understand that this patch *is* the culprit. I just would
like to understand why, so we can fix it appropriately.
Loic, this is probably also the failing patch for you?
Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: revert "Align runtime section to 64kb"
Commit 7a82c3051c8f ("efi_loader: Align runtime section to 64kb") lets
booting Linux fail at least on the Odroid C2. The patch alone applied to
v2018.09 or v2018.11 causes the error.
With the patch memory may be marked as code that contains variables.
So let's revert it and look for a better solution to reach compliance
with the 64kb alignment requirement of the UEFI spec.
Fixes: 7a82c3051c8f ("efi_loader: Align runtime section to 64kb")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_memory.c | 20 +++-
1 file changed, 3 insertions(+), 17 deletions(-)
diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
index 4bb517473e4..5359118b4d7 100644
--- a/lib/efi_loader/efi_memory.c
+++ b/lib/efi_loader/efi_memory.c
@@ -11,7 +11,6 @@
#include
#include
#include
-#include
DECLARE_GLOBAL_DATA_PTR;
@@ -603,7 +602,6 @@ __weak void efi_add_known_memory(void)
static void add_u_boot_and_runtime(void)
{
unsigned long runtime_start, runtime_end, runtime_pages;
- unsigned long runtime_mask = EFI_PAGE_MASK;
unsigned long uboot_start, uboot_pages;
unsigned long uboot_stack_size = 16 * 1024 * 1024;
@@ -612,22 +610,10 @@ static void add_u_boot_and_runtime(void)
uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
-#if defined(__aarch64__)
- /*
-* Runtime Services must be 64KiB aligned according to the
-* "AArch64 Platforms" section in the UEFI spec (2.7+).
-*/
-
- runtime_mask = SZ_64K - 1;
-#endif
-
- /*
-* Add Runtime Services. We mark surrounding boottime code as runtime as
-* well to fulfill the runtime alignment constraints but avoid padding.
-*/
- runtime_start = (ulong)&__efi_runtime_start & ~runtime_mask;
+ /* Add Runtime Services */
+ runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
runtime_end = (ulong)&__efi_runtime_stop;
- runtime_end = (runtime_end + runtime_mask) & ~runtime_mask;
+ runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
efi_add_memory_map(runtime_start, runtime_pages,
EFI_RUNTIME_SERVICES_CODE, false);
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] New item at list end for backwards compatibility
On Sat, Dec 08, 2018 at 05:26:49PM +0100, Stefano Babic wrote: > Hi Marek, Robert, > > On 05/12/18 15:52, Marek Vasut wrote: > > From: Robert Berger > > > > Signed-off-by: Robert Berger > > > > I received this off-list from Robert, it's a bugfix to mkimage, where > > the IH_TYPE_ enumeration changed recently and broke backward mkimage > > backward compatibility. > > > > That's true - new image type must be always appended for compatible reason. > > > Peng, can you respin the patch, test it and repost it ? Thanks > > I am reviewing and applying Peng's - but Peng posted a patch for i.MX8M, > patch for i.MX8 was already applied. > > If nobody complains, I fix this myself by applying Peng's i.MX8M (not > MX8) patch, I mean this one: > > http://patchwork.ozlabs.org/patch/1000376/ > > Note: this also breaks compatibility I think the first problem is that the comment "Do not change values for backward compatibility." is not clear enough because I see lots of middle of the list insertions which in turn change all of the values that follow. A downside of an enum I suppose. What we need to do is yank the IMX8 part out to fix all of the broken images, and put the new ones at the back, and Cc the various distro folks as they'll want to make sure to pick this fix up. -- 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] ARM: at91: Fix 'boot.bin' generation when CONFIG_SD_BOOT is enabled
On AT91 platforms configured for SD_BOOT, this commit avoids the
generation of the PMECC header used for booting from NAND flash. This
issue was found by attempting to boot the SAMA5D3-XPLD board with the
'sama5d3_xplained_mmc_defconfig'.
[PMECC Reference]
http://www.at91.com/linux4sam/bin/view/Linux4SAM/AT91Bootstrap
[Mailing List Thread]
https://lists.denx.de/pipermail/u-boot/2018-December/350666.html
Fixes: 5541543f ("configs: at91: Remove CONFIG_SYS_EXTRA_OPTIONS assignment")
Reported-by: Daniel Evans
Cc: Robert Nelson
Cc: Eugen Hristev
Cc: Wenyou Yang
Signed-off-by: Derald D. Woods
---
scripts/Makefile.spl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 22bd8f7c27..e727cb610f 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -166,10 +166,12 @@ ifeq ($(CONFIG_SYS_SOC),"at91")
MKIMAGEFLAGS_boot.bin = -T atmelimage
ifeq ($(CONFIG_SPL_GENERATE_ATMEL_PMECC_HEADER),y)
+ifneq ($(CONFIG_SD_BOOT),y)
MKIMAGEFLAGS_boot.bin += -n $(shell $(obj)/../tools/atmel_pmecc_params)
boot.bin: $(obj)/../tools/atmel_pmecc_params
endif
+endif
boot.bin: $(obj)/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] pcm058: fix NAND flash not using badblock table
Hi Harald, On 07/12/18 22:18, Harald Seiler wrote: > Hello Stefano, > > On Fri, 2018-12-07 at 19:55 +0100, Stefano Babic wrote: >> Hi Harald, >> >> On 07/12/18 13:18, Marek Vasut wrote: >>> On 12/07/2018 01:15 PM, Harald Seiler wrote: Hello Marek, >>> >>> Hi, >>> On Fri, 2018-12-07 at 12:48 +0100, Marek Vasut wrote: > On 12/07/2018 10:19 AM, Harald Seiler wrote: >> Currently, U-Boot ignores the BBT stored in the last 4 blocks of NAND >> flash because the NAND_BBT_USE_FLASH flag is not set. This leads to >> two issues: >> >> * U-Boot silently uses a memory-only BBT which is initialized with all >> blocks marked as good. This means, actual bad blocks are marked good >> and U-Boot might try writing to or reading from them. >> * The BBT in flash, which will be created once Linux boots up, is not >> off limits for a driver ontop, like UBI. While it does not seem to >> consistently produce an error, sometimes UBI will fail to attach >> because the BBT blocks obviously don't contain valid UBI data. >> >> To fix this, this patch sets the CONFIG_SYS_NAND_USE_FLASH_BBT option, >> which is used in ./drivers/mtd/nand/raw/mxs_nand.c to decide whether >> a BBT in flash is used. >> >> Signed-off-by: Harald Seiler > > V2 Changelog is missing. > >> --- >> include/configs/pcm058.h | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/include/configs/pcm058.h b/include/configs/pcm058.h >> index 49048c163f..b9bc08b388 100644 >> --- a/include/configs/pcm058.h >> +++ b/include/configs/pcm058.h >> @@ -55,6 +55,7 @@ >> #define CONFIG_SYS_NAND_BASE0x4000 >> #define CONFIG_SYS_NAND_5_ADDR_CYCLE >> #define CONFIG_SYS_NAND_ONFI_DETECTION >> +#define CONFIG_SYS_NAND_USE_FLASH_BBT > > Shouldn't this be enabled on all boards with GPMI NAND ? > I looked at other boards and they all defined this config, so I assumed this was the way to go ... >> >> Let me understand. If Isearch for CONFIG_NAND_MXS, I get 27 boards using >> this drivers, with different SOC (mx28, mx6[Dual|Quad|Solo], mx6sx, >> mx6ull). But none of them is setting CONFIG_SYS_NAND_USE_FLASH_BBT. >> >> When does it happen the issue ? It should happen if we create a UBI >> container and its volumes in U-Boot. If UBI is generated in linux, this >> should not happen. Is it the case or does it happen in any condition ? > > Linux will write the badblock table to the last 4 blocks by default which > U-Boot ignores at the moment. So the issue happens if you use the default > kernel config (which you pointed out below). Right, or in any case where there is a mismatch in the configuration between U-Boot and Linux. > >> I think the issue happens because there is a disalignment between kernel >> and u-boot. Kernel mainline for this board (file >> imx6qdl-phytec-phycore-som.dtsi) sets "nand-on-flash-bbt", while U-Boot >> not. That mean that this can always happen if kernel and U-Boot does not >> use the same setup for the driver. >> >> Maybe with previous kernel versions there was no problem because Linux >> used the same setup as U-Boot. > > This is exactly what I think is going on ... Right. > >> Anyway, this discourage setting CONFIG_SYS_NAND_USE_FLASH_BBT >> unconditionally for all boards with GPMI driver. >> > > I agree, it only makes sense in cases where Linux also does it this way. > Although, not doing it this way means not having any persistent badblock > table at all, which I feel is never a good idea ... > >>> But yes, as far as I understand, it would make sense to have it enabled most of the time. Although there is some code which makes this configuration from the devicetree, which might be an even better solution. >> >> Device tree has already this option as I see in >> drivers/mtd/nand/raw/nand_base.c. The driver enforces this if no DT (as >> in this case) is used. > > What do you mean by enforce? Without DT, behavior is decided at compile time. > If no devicetree is used, the code does not > set any flags as far as I understand it, which also aligns with the results > of my experimentation ... (Currently bbt_options is 0) Ok - we agree that this change cannot be done for all boards because it depends if Linux is using or not, and we do not know the common use cases for thoese boards. It must be decided any time by the board maintainer (well, in this case me..). Use case for this board is running kernel mainline, so it makes sense to apply this patch. 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] arm: imx7d: cl-som-imx7: migration to CONFIG_BLK
On 20/11/18 16:49, Yaniv Levinsky wrote: > Enable driver model for USB, MMC and REGULATOR drivers. > Set run-time configuration via Device Tree. > > Signed-off-by: Yaniv Levinsky > --- > configs/cl-som-imx7_defconfig | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/configs/cl-som-imx7_defconfig b/configs/cl-som-imx7_defconfig > index 0eed5264f2..ea7ad5c596 100644 > --- a/configs/cl-som-imx7_defconfig > +++ b/configs/cl-som-imx7_defconfig > @@ -43,8 +43,11 @@ CONFIG_CMD_EXT4=y > CONFIG_CMD_EXT4_WRITE=y > CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > +CONFIG_OF_CONTROL=y > +CONFIG_DEFAULT_DEVICE_TREE="imx7d-sdb" > # CONFIG_ENV_IS_IN_MMC is not set > CONFIG_ENV_IS_IN_SPI_FLASH=y > +CONFIG_DM_MMC=y > CONFIG_FSL_ESDHC=y > CONFIG_SPI_FLASH=y > CONFIG_SPI_FLASH_ATMEL=y > @@ -56,12 +59,13 @@ CONFIG_SPI_FLASH_STMICRO=y > CONFIG_SPI_FLASH_SST=y > CONFIG_SPI_FLASH_WINBOND=y > CONFIG_MII=y > +CONFIG_DM_REGULATOR=y > CONFIG_SPI=y > CONFIG_MXC_SPI=y > CONFIG_USB=y > +CONFIG_DM_USB=y > CONFIG_USB_EHCI_HCD=y > CONFIG_MXC_USB_OTG_HACTIVE=y > CONFIG_USB_STORAGE=y > CONFIG_USB_GADGET=y > CONFIG_CI_UDC=y > -CONFIG_OF_LIBFDT=y > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 v2 0/3] ARM: pinctrl: Provide pinctrl driver for Vybrid (vf610)
On 20/11/18 00:38, Lukasz Majewski wrote: > This series enables pinctrl driver for the vybrid NXP SoC. > > > Changes in v2: > - Remove mux_mask from the imx_pinctrl_soc_info specific for vf610 > - Define vf610 mux_mask in the DTS (as it is read from there) > > Lukasz Majewski (3): > ARM: vybrid: Provide pinctrl driver for Vybrid (vf610) > ARM: DTS: Add iomux node to vf.dtsi for Vybrid devices > ARM: DTS: Provide pinfunc definitions for vybrid vf610 from Linux > kernel > > arch/arm/dts/vf.dtsi| 6 + > arch/arm/dts/vf610-pinfunc.h| 810 > > drivers/pinctrl/nxp/Kconfig | 14 + > drivers/pinctrl/nxp/Makefile| 1 + > drivers/pinctrl/nxp/pinctrl-vf610.c | 40 ++ > 5 files changed, 871 insertions(+) > create mode 100644 arch/arm/dts/vf610-pinfunc.h > create mode 100644 drivers/pinctrl/nxp/pinctrl-vf610.c > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V2 1/2] SPL: Add HAB image authentication to FIT
On 17/11/18 10:10, Peng Fan wrote: > From: Ye Li > > Introduce two board level callback functions to FIT image loading process, and > a SPL_FIT_FOUND flag to differentiate FIT image or RAW image. > > Implement functions in imx common SPL codes to call HAB funtion > to authenticate the FIT image. Generally, we have to sign multiple regions > in FIT image: > 1. Sign FIT FDT data (configuration) > 2. Sign FIT external data (Sub-images) > > Because the CSF supports to sign multiple memory blocks, so that we can use > one > signature to cover all regions in FIT image and only authenticate once. > The authentication should be done after the entire FIT image is loaded into > memory including all sub-images. > We use "-p" option to generate FIT image to reserve a space for FIT IVT > and FIT CSF, also this help to fix the offset of the external data > (u-boot-nodtb.bin, > ATF, u-boot DTB). > > The signed FIT image layout is as below: > -- > | | | | | | || > | FIT | FIT | FIT | | U-BOOT| ATF | U-BOOT | > | FDT | IVT | CSF | | nodtb.bin | | DTB | > | | | | | | || > -- > > Signed-off-by: Ye Li > Reviewed-by: Peng Fan > Reviewed-by: Tom Rini > Signed-off-by: Peng Fan > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 v2] imx: hab: extend hab_auth_img to calculate ivt_offset
On 21/11/18 14:50, Parthiban Nallathambi wrote: > Current implementation of hab_auth_img command needs ivt_offset to > authenticate the image. But ivt header is placed at the end of image > date after padding. > > This leaves the usage of hab_auth_img command to fixed size or static > offset for ivt header. New function "get_image_ivt_offset" is introduced > to find the ivt offset during runtime. The case conditional check in this > function is same as boot_get_kernel in common/bootm.c > > With this variable length image e.g. FIT image with any random size can > have IVT at the end and ivt_offset option can be left optional > > Can be used as "hab_auth_img $loadaddr $filesize" from u-boot script > > Signed-off-by: Parthiban Nallathambi > --- > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 2/2] imx: bootaux: fix stack and pc assignment on 64-bit platforms
On 14/11/18 17:55, Gary Bisson wrote: > Using ulong is wrong as its size depends on the Host CPU architecture > (32-bit vs. 64-bit) although the Cortex-M4 is always 32-bit. > > Without this patch, the stack and PC are obviously wrong and it > generates an abort when used on 64-bit processors such as the i.MX8MQ. > > Signed-off-by: Gary Bisson > --- > arch/arm/mach-imx/imx_bootaux.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c > index a1ea5c13f1..3103001b7c 100644 > --- a/arch/arm/mach-imx/imx_bootaux.c > +++ b/arch/arm/mach-imx/imx_bootaux.c > @@ -17,8 +17,8 @@ int arch_auxiliary_core_up(u32 core_id, ulong > boot_private_data) > if (!boot_private_data) > return -EINVAL; > > - stack = *(ulong *)boot_private_data; > - pc = *(ulong *)(boot_private_data + 4); > + stack = *(u32 *)boot_private_data; > + pc = *(u32 *)(boot_private_data + 4); > > /* Set the stack and pc to M4 bootROM */ > writel(stack, M4_BOOTROM_BASE_ADDR); > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: mx8m: add memory mapping for CAAM and TCM
On 14/11/18 17:55, Gary Bisson wrote:
> Otherwise can't boot the M4 core as it is impossible to load its
> firmware into the TCM memory.
>
> Signed-off-by: Gary Bisson
> ---
> arch/arm/mach-imx/mx8m/soc.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx8m/soc.c b/arch/arm/mach-imx/mx8m/soc.c
> index 46873aa8dd..11251c5f9a 100644
> --- a/arch/arm/mach-imx/mx8m/soc.c
> +++ b/arch/arm/mach-imx/mx8m/soc.c
> @@ -77,6 +77,22 @@ static struct mm_region imx8m_mem_map[] = {
> .size = 0x10UL,
> .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
>PTE_BLOCK_OUTER_SHARE
> + }, {
> + /* CAAM */
> + .virt = 0x10UL,
> + .phys = 0x10UL,
> + .size = 0x8000UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> + }, {
> + /* TCM */
> + .virt = 0x7CUL,
> + .phys = 0x7CUL,
> + .size = 0x8UL,
> + .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
> + PTE_BLOCK_NON_SHARE |
> + PTE_BLOCK_PXN | PTE_BLOCK_UXN
> }, {
> /* OCRAM */
> .virt = 0x90UL,
>
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
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] tools: improve portability of imx_cntr_image.sh
On 09/11/18 14:30, Martin Husemann wrote:
> Replace non-portable operator == with =
>
> The operator == in sh(1) / test(1) is non-POSIX and only implemented by
> some shells (like bash). It is equivalent to the standard defined operator =.
>
> ---
> tools/imx_cntr_image.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/imx_cntr_image.sh b/tools/imx_cntr_image.sh
> index 4c629e8694..972b95ccbe 100755
> --- a/tools/imx_cntr_image.sh
> +++ b/tools/imx_cntr_image.sh
> @@ -10,7 +10,7 @@ file=$1
> blobs=`awk '/^APPEND/ {print $2} /^IMAGE/ || /^DATA/ {print $3}' $file`
> for f in $blobs; do
> tmp=$srctree/$f
> - if [ $f == "u-boot-dtb.bin" ]; then
> + if [ $f = "u-boot-dtb.bin" ]; then
> continue
> fi
>
>
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] embestmx6boards: Add SPL support
On 08/11/18 11:28, Fabien Lahoudere wrote: > In order to boot faster with falcon mode, we need to add SPL > support to riotboard. > > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: imx8qxp_mek: imximage: remove config.h
On 05/11/18 11:01, Peng Fan wrote: > config.h is not needed, remove it. > > Signed-off-by: Peng Fan > --- > board/freescale/imx8qxp_mek/imximage.cfg | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/board/freescale/imx8qxp_mek/imximage.cfg > b/board/freescale/imx8qxp_mek/imximage.cfg > index 9d39f25bf6..bbffb1a88f 100644 > --- a/board/freescale/imx8qxp_mek/imximage.cfg > +++ b/board/freescale/imx8qxp_mek/imximage.cfg > @@ -7,7 +7,6 @@ > */ > > #define __ASSEMBLY__ > -#include > > /* Boot from SD, sector size 0x400 */ > BOOT_FROM SD 0x400 > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 3/3] configs: mx23_olinuxino_defconfig: disable bootefi command
On 29/10/18 20:21, Michael Heimpold wrote: > CONFIG_CMD_BOOTEFI is enabled by Kconfig default, but rarely > used on this board/platform. > So let's disable it for the boards default config. > This also saves around 16 KiB in the final u-boot.sb. > > Signed-off-by: Michael Heimpold > --- > configs/mx23_olinuxino_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/mx23_olinuxino_defconfig > b/configs/mx23_olinuxino_defconfig > index 598547a5f5..1bf76e2e11 100644 > --- a/configs/mx23_olinuxino_defconfig > +++ b/configs/mx23_olinuxino_defconfig > @@ -14,6 +14,7 @@ CONFIG_VERSION_VARIABLE=y > CONFIG_ARCH_MISC_INIT=y > # CONFIG_SPL_FRAMEWORK is not set > CONFIG_HUSH_PARSER=y > +# CONFIG_CMD_BOOTEFI is not set > # CONFIG_CMD_FLASH is not set > CONFIG_CMD_GPIO=y > CONFIG_CMD_MMC=y > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 2/3] configs: mx23_olinuxino_defconfig: fix status led definition
On 29/10/18 20:21, Michael Heimpold wrote:
> While migrating individual status led usages to Kconfig stuff,
> a (random) value was introduced for this board which does not
> work but produces the following error message during boot:
>
> __led_init: failed requesting GPIO59!
>
> Since Kconfig does not seem to accept a define as this point,
> but the mxs gpio driver requires not only a simple integer value,
> we need to use the plain value of MX23_PAD_SSP1_DETECT__GPIO_2_1.
>
> Signed-off-by: Michael Heimpold
> Fixes: 2d8d190c8394 ("status_led: Kconfig migration")
> ---
> configs/mx23_olinuxino_defconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configs/mx23_olinuxino_defconfig
> b/configs/mx23_olinuxino_defconfig
> index 6597dc3870..598547a5f5 100644
> --- a/configs/mx23_olinuxino_defconfig
> +++ b/configs/mx23_olinuxino_defconfig
> @@ -26,7 +26,7 @@ CONFIG_ENV_IS_IN_MMC=y
> CONFIG_LED_STATUS=y
> CONFIG_LED_STATUS_GPIO=y
> CONFIG_LED_STATUS0=y
> -CONFIG_LED_STATUS_BIT=59
> +CONFIG_LED_STATUS_BIT=778
> CONFIG_LED_STATUS_STATE=2
> CONFIG_LED_STATUS_BOOT_ENABLE=y
> CONFIG_LED_STATUS_BOOT=0
>
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
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] w1: Add driver for i.MX bus master controller
On 24/10/18 10:21, Martin Fuzzey wrote: > Two variants of controllers are supported: > V1 (bitwise only) found in > i.MX21, i.MX27, i.MX31, i.MX51 > V2 (byte operations) found in > i.MX25, i.MX35, i.MX50, i.MX53 > > Only tested on i.MX53 hardware but in both modes > (by modifying the device tree). > > Signed-off-by: Martin Fuzzey > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 v2 2/2] watchdog: imx: add config to disable wdog reset
On 18/10/18 12:27, Xiaoliang Yang wrote: > Add Kconfig option WATCHDOG_RESET_DISABLE to disable watchdog reset > in imx_watchdog driver, so that the watchdog will not be fed in > u-boot if CONFIG_WATCHDOG_RESET_DISABLE is enabled. > > Signed-off-by: Xiaoliang Yang > --- > arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 |2 ++ > drivers/watchdog/Kconfig |6 ++ > drivers/watchdog/imx_watchdog.c|2 ++ > 3 files changed, 10 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 > b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 > index 9176546..9583bf7 100644 > --- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch2 Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 v2 1/2] watchdog: driver support for fsl-lsch2
On 18/10/18 12:27, Xiaoliang Yang wrote: > Support watchdog driver for fsl-lsch2. It's disabled in default. > If you want to use it, please enable CONFIG_IMX_WATCHDOG. > Define CONFIG_WATCHDOG_TIMEOUT_MSECS to set watchdog timeout. > > Signed-off-by: Xiaoliang Yang > --- > v1->v2: Remove LSCH3 config from imx-watchdog.c, because it only > support LSCH2 platforms. > Use Kconfig option IMX_WATCHDOG to introduce how to use > watchdog driver in README.lsch2. > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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] warp7: configs: add CONFIG_FIT option
On 29/09/18 14:05, Pierre-Jean Texier wrote: > This enable FIT image support. > > Signed-off-by: Pierre-Jean Texier > --- > configs/warp7_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig > index 15a6673..919d484 100644 > --- a/configs/warp7_defconfig > +++ b/configs/warp7_defconfig > @@ -8,6 +8,8 @@ CONFIG_ARMV7_BOOT_SEC_DEFAULT=y > CONFIG_IMX_RDC=y > CONFIG_IMX_BOOTAUX=y > CONFIG_NR_DRAM_BANKS=1 > +CONFIG_FIT=y > +CONFIG_FIT_VERBOSE=y > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/warp7/imximage.cfg" > CONFIG_HUSH_PARSER=y > # CONFIG_CMD_BOOTD is not set > Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V3 6/6] board: ge: Store bootcount in EEPROM on PPD and Bx50v3
On 17/10/18 10:33, Fabien Lahoudere wrote: > From: Denis Zalevskiy > > u-boot's ext3/4 write/modify functionality sometimes corrupts > filesystem in the case if it requires recovery (e.g. after unexpected > shutdown) and we want to avoid the only filesystem modification we > have - bootcounter writing. So, bootcounter will be stored in the EEPROM > where VPD is stored. > > Signed-off-by: Denis Zalevskiy > > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V3 5/6] board: ge: Move VPD reading to the vpd_reader
On 17/10/18 10:33, Fabien Lahoudere wrote:
> From: Denis Zalevskiy
>
> Merge functionality duplicated in bx50v3 and mx53ppd: the logic
> is the same except that process_vpd is called at different phases.
> Also read_vpd could end up in error, so there is no VPD data in this
> case - it shouldn't be processed.
>
> Signed-off-by: Denis Zalevskiy
> Signed-off-by: Fabien Lahoudere
> ---
> board/ge/bx50v3/bx50v3.c | 48
> ++--
> board/ge/common/vpd_reader.c | 37 +++---
> board/ge/common/vpd_reader.h | 16 ++-
> board/ge/mx53ppd/mx53ppd.c | 38 +++
> 4 files changed, 63 insertions(+), 76 deletions(-)
>
> diff --git a/board/ge/bx50v3/bx50v3.c b/board/ge/bx50v3/bx50v3.c
> index ca500f5..78e7ee6 100644
> --- a/board/ge/bx50v3/bx50v3.c
> +++ b/board/ge/bx50v3/bx50v3.c
> @@ -33,8 +33,6 @@
> #include "../../../drivers/net/e1000.h"
> DECLARE_GLOBAL_DATA_PTR;
>
> -struct vpd_cache;
> -
> static int confidx = 3; /* Default to b850v3. */
> static struct vpd_cache vpd;
>
> @@ -552,6 +550,7 @@ int overwrite_console(void)
> #define VPD_MAC_ADDRESS_LENGTH 6
>
> struct vpd_cache {
> + bool is_read;
> u8 product_id;
> u8 has;
> unsigned char mac1[VPD_MAC_ADDRESS_LENGTH];
> @@ -561,11 +560,9 @@ struct vpd_cache {
> /*
> * Extracts MAC and product information from the VPD.
> */
> -static int vpd_callback(void *userdata, u8 id, u8 version, u8 type,
> +static int vpd_callback(struct vpd_cache *vpd, u8 id, u8 version, u8 type,
> size_t size, u8 const *data)
> {
> - struct vpd_cache *vpd = (struct vpd_cache *)userdata;
> -
> if (id == VPD_BLOCK_HWID && version == 1 && type != VPD_TYPE_INVALID &&
> size >= 1) {
> vpd->product_id = data[0];
> @@ -589,6 +586,11 @@ static void process_vpd(struct vpd_cache *vpd)
> int fec_index = -1;
> int i210_index = -1;
>
> + if (!vpd->is_read) {
> + printf("VPD wasn't read");
> + return;
> + }
> +
> switch (vpd->product_id) {
> case VPD_PRODUCT_B450:
> env_set("confidx", "1");
> @@ -614,35 +616,6 @@ static void process_vpd(struct vpd_cache *vpd)
> eth_env_set_enetaddr_by_index("eth", i210_index, vpd->mac2);
> }
>
> -static int read_vpd(void)
> -{
> - int res;
> - static const int size = CONFIG_SYS_VPD_EEPROM_SIZE;
> - uint8_t *data;
> - unsigned int current_i2c_bus = i2c_get_bus_num();
> -
> - res = i2c_set_bus_num(CONFIG_SYS_VPD_EEPROM_I2C_BUS);
> - if (res < 0)
> - return res;
> -
> - data = (uint8_t *)malloc(size);
> - if (!data)
> - return -ENOMEM;
> -
> - res = i2c_read(CONFIG_SYS_VPD_EEPROM_I2C_ADDR, 0,
> -CONFIG_SYS_VPD_EEPROM_I2C_ADDR_LEN, data, size);
> -
> - if (res == 0) {
> - memset(, 0, sizeof(vpd));
> - vpd_reader(size, data, , vpd_callback);
> - }
> -
> - free(data);
> -
> - i2c_set_bus_num(current_i2c_bus);
> - return res;
> -}
> -
> int board_eth_init(bd_t *bis)
> {
> setup_iomux_enet();
> @@ -705,9 +678,10 @@ int board_init(void)
> setup_i2c(2, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info2);
> setup_i2c(3, CONFIG_SYS_I2C_SPEED, 0x7f, _pad_info3);
>
> - read_vpd();
> -
> - set_confidx();
> + if (!read_vpd(, vpd_callback)) {
> + vpd.is_read = true;
> + set_confidx();
> + }
>
> gpio_direction_output(SUS_S3_OUT, 1);
> gpio_direction_output(WIFI_EN, 1);
> diff --git a/board/ge/common/vpd_reader.c b/board/ge/common/vpd_reader.c
> index c471583..12410d9 100644
> --- a/board/ge/common/vpd_reader.c
> +++ b/board/ge/common/vpd_reader.c
> @@ -5,6 +5,7 @@
>
> #include "vpd_reader.h"
>
> +#include
> #include
> #include
>
> @@ -105,9 +106,9 @@ static const size_t HEADER_BLOCK_ECC_LEN = 4;
>
> static const u8 ECC_BLOCK_ID = 0xFF;
>
> -int vpd_reader(size_t size, u8 *data, void *userdata,
> -int (*fn)(void *userdata, u8 id, u8 version, u8 type,
> - size_t size, u8 const *data))
> +static int vpd_reader(size_t size, u8 *data, struct vpd_cache *userdata,
> + int (*fn)(struct vpd_cache *, u8 id, u8 version, u8 type,
> + size_t size, u8 const *data))
> {
> if (size < HEADER_BLOCK_LEN || !data || !fn)
> return -EINVAL;
> @@ -194,3 +195,33 @@ int vpd_reader(size_t size, u8 *data, void *userdata,
> return ret;
> }
> }
> +
> +int read_vpd(struct vpd_cache *cache,
> + int (*process_block)(struct vpd_cache *, u8 id, u8 version,
> + u8 type, size_t size, u8 const *data))
> +{
> + static const size_t size = CONFIG_SYS_VPD_EEPROM_SIZE;
> +
> + int res;
> + u8 *data;
> + unsigned int current_i2c_bus =
Re: [U-Boot] [PATCH V3 4/6] bootcount: Configure length limit for I2C bootcount
On 17/10/18 10:33, Fabien Lahoudere wrote: > From: Denis Zalevskiy > > Bootcount driver should verify size against the maximum available space. > New configuration parameter adds this capability and keeps backward > compatibility by providing default value. > > Signed-off-by: Denis Zalevskiy > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V3 3/6] bootcount: i2c: Add bus switching to the I2C bootcount driver
On 17/10/18 10:33, Fabien Lahoudere wrote: > From: Denis Zalevskiy > > If there is an I2C mux, current bus should be switched before > manipulating with I2C. > > Signed-off-by: Denis Zalevskiy > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V3 2/6] board: ge: Move VPD EEPROM configuration to the defconfig
On 17/10/18 10:33, Fabien Lahoudere wrote: > From: Denis Zalevskiy > > Use standard configuration logic to define EEPROM constants. > Names are based on VPD_EEPROM_ prefix because EEPROM_ is already > used by i2c_eeprom driver. > > Signed-off-by: Denis Zalevskiy > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 V3 1/6] board: ge: Remove EEPROM bus param from read_vpd()
Hi Fabien, On 17/10/18 10:33, Fabien Lahoudere wrote: > From: Denis Zalevskiy > > The bus is statically defined, so remove redundant parameters > from read_vpd() for PPD and Bx50v3. > > Signed-off-by: Denis Zalevskiy > Signed-off-by: Fabien Lahoudere > --- Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = 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 2/2] arm: imx8qxp: build u-boot-dtb.cfgout before checking files
Hi Peng, On 05/11/18 11:01, Peng Fan wrote: > Build u-boot-dtb.cfgout before checking files, otherwise > u-boot-dtb.cfgout is generated at late stage and cause final image not > generated. > > Signed-off-by: Peng Fan > --- > arch/arm/mach-imx/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile > index 72fe23a2b9..a3190ad2f0 100644 > --- a/arch/arm/mach-imx/Makefile > +++ b/arch/arm/mach-imx/Makefile > @@ -89,7 +89,7 @@ IMX_CONFIG = $(CONFIG_IMX_CONFIG:"%"=%) > ifeq ($(CONFIG_ARCH_IMX8), y) > CNTR_DEPFILES := $(srctree)/tools/imx_cntr_image.sh > IMAGE_TYPE := imx8image > -DEPFILE_EXISTS := $(shell if [ -f u-boot-dtb.cfgout ]; then $(CNTR_DEPFILES) > u-boot-dtb.cfgout; echo $$?; fi) > +DEPFILE_EXISTS := $(shell $(CPP) $(cpp_flags) -x c -o u-boot-dtb.cfgout > $(srctree)/$(IMX_CONFIG); if [ -f u-boot-dtb.cfgout ]; then $(CNTR_DEPFILES) > u-boot-dtb.cfgout; echo $$?; fi) > else > IMAGE_TYPE := imximage > DEPFILE_EXISTS := 0 > This fixes an issue but it creates apparently a new one. After applying this, the board is not built clean. It looks like it cannot find ahab-container.img, even if it is present in my U-Boot directory. +Fail open first container file ahab-container.img +make[2]: *** [u-boot-dtb.imx] Error 1 +make[1]: *** [u-boot-dtb.imx] Error 2 +make: *** [sub-make] Error 2 Without it, build is fine. 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 v1] tools: logos: crop Toradex logo slightly
Hi Stefan,
> From: Stefan Agner
>
> The current bitmap is a bit larger than necessary, it has a black
> border around the Toradex logo. Crop the logo slightly which safes
> some space, useful especially on Colibri VFxx.
I can confirm that those changes, as well as
[PATCH v1] board: toradex: colibri_vf: unset NFS and LOADS/B
[PATCH v1] mtd: nand: raw: allow to disable unneeded ECC layouts
[PATCH v1] fs: fat: dynamically allocate memory for temporary buffer
Reduce the u-boot.vyb binary for colibri_vf, so it is possible to put
more device tree description data to vf.dtsi and hence convert some
vf610 boards to DTS/DM.
Tested-by: Lukasz Majewski
Thanks Stefan :-)
>
> Signed-off-by: Stefan Agner
> ---
>
> tools/logos/toradex.bmp | Bin 24982 -> 23298 bytes
> 1 file changed, 0 insertions(+), 0 deletions(-)
>
> diff --git a/tools/logos/toradex.bmp b/tools/logos/toradex.bmp
> index
> 3e2dcf23358dd46fc7b1bb0dae70d3ba985606ee..8b5cb18e8475b3eda72c9f0e821b2aad17bc1bae
> 100644 GIT binary patch delta 505
> zcmYLEO-oxr6rCd>(HDKjZ>@>Jpis10rD|SMpO}a~;ztZ>#n#YvXDMP^LN{G@Ros~Y
> z7ZzGv2rXT;2fM2V{0-tp-MG+&1*NzVD!qwH2j zqA&|eIdVc37wR8om8$e!Zz<*l6?djGE9YG(S~;)!9==vfFLUm4-15@m|9r0G
> zmizeCFm60Pec_#Ey3_){ltsV`(*{R;a?MtR!GlVHyVU}jnm+JXtq3Lc0*@L5*6#@X
> zZWM?FBG5Uvi_1-;;7M@9V643tT)ro*yB*RRyf5r!m%wIs7(X6Z&}P4>2dpwK^!TCA
> z#vApR)u#7*|L~|!Y@L=^>|}#ZB|Th=)POrtDVzOa=q< zTCNWr4?o94(4CgaqoH;%G%TNcHS!SLa%5g3A@fQ%jYNRCF+X@VE-pJ+(CWB8
> zDGB)@pZ0ionrZ=CrbK@;9R;^%B+8u4K>wYo&*H6Kdi+g)O1ODE*9`if$Qv)_#k`r8
> Tu-(CC?xpL%4;b52`
>
> delta 656
> zcmXw!ODIHP6vw|?uE!njFhgTzOi3nYyasb;yv8sxo^!iK9tlwv3RzGrG(|QZDZa9j
> zB?~JZ+1My$i;az@WKD$CWZ~X(xb^k>++`QLBjQaHR3{E^tlYa7
> z)+w+|)TbsGvzX}UqTV=PO%wUG_^qEgSQ8tBeJ!7_i5^I%n~giXW{@^6RYN>W!v46l
> zZnTmTwxA%p5v^)Y2)QGZeq#<|oysNFT8OjO0P4s2 zf{70}efyfocU>k(xMn2%=P%%;Ou?--52dJHO4+QS`l^!nSw-~J;C6l%lwr~5F=qKz
> zmy?(Jy*yd_Wjye{4y`=ZDsxrI1-IXU5n+X*mIJivEJ(i7hzuVMUi3JcX#IAJ8&;aF
> zsBO3WN1EXwgprVHrN`B`5$D^R(R&|Pe+lV@v!3JlZpi4#JQJUH6Lh5}x
> zJarfUd2L|nEy26~M84?DfS$fmoLlIpxszBE*3T+sI<+ON_XaQ WVdOzbgrkvqwA_u-FJz9T1ojITOUl0h
>
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp19rpyA6wFZ.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5] pico-imx7d: Increase the CONFIG_ENV_OFFSET size
Hi Fabio, On 08/12/18 14:53, Fabio Estevam wrote: > U-Boot binary has grown in such a way that it goes beyond the reserved > area for the environment variables. > > Running "saveenv" causes U-Boot to hang because of this overlap. > > Fix this problem by increasing the CONFIG_ENV_OFFSET size. > > Also, in order to prevent this same problem to happen again in > the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap > in build-time. > > CONFIG_BOARD_SIZE_LIMIT is CONFIG_ENV_OFFSET - 69 kB, as u-boot.img > is flashed into the 69 kB offset. > > Signed-off-by: Fabio Estevam > --- > Changes since v4: > - Use math expressions for better readability > > Hi Stefano, > > This one depends on Wolfgang's v2 patch: > https://lists.denx.de/pipermail/u-boot/2018-December/351138.html > Yes, I see the long thread with Wolfgang. IMHO it is better I apply both of them to u-boot.imx, even if Wolfgang's is quite "shared" (he patches /Makefile, too). Regards, Stefano > include/configs/pico-imx7d.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h > index 2bc42a0..333c0b4 100644 > --- a/include/configs/pico-imx7d.h > +++ b/include/configs/pico-imx7d.h > @@ -134,7 +134,8 @@ > /* FLASH and environment organization */ > #define CONFIG_ENV_SIZE SZ_8K > > -#define CONFIG_ENV_OFFSET(8 * SZ_64K) > +#define CONFIG_ENV_OFFSET(768 * 1024) > +#define CONFIG_BOARD_SIZE_LIMIT ((768 - 69) * 1024) > #define CONFIG_SYS_FSL_USDHC_NUM 2 > > #define CONFIG_SYS_MMC_ENV_DEV 0 > -- = 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] New item at list end for backwards compatibility
Hi Marek, Robert,
On 05/12/18 15:52, Marek Vasut wrote:
> From: Robert Berger
>
> Signed-off-by: Robert Berger
>
> I received this off-list from Robert, it's a bugfix to mkimage, where
> the IH_TYPE_ enumeration changed recently and broke backward mkimage
> backward compatibility.
>
That's true - new image type must be always appended for compatible reason.
> Peng, can you respin the patch, test it and repost it ? Thanks
I am reviewing and applying Peng's - but Peng posted a patch for i.MX8M,
patch for i.MX8 was already applied.
If nobody complains, I fix this myself by applying Peng's i.MX8M (not
MX8) patch, I mean this one:
http://patchwork.ozlabs.org/patch/1000376/
Note: this also breaks compatibility
Regards,
Stefano
>
> ---
> diff --git a/include/image.h b/include/image.h
> index 031c355..866e9f1 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -251,7 +251,6 @@ enum {
> IH_TYPE_FLATDT, /* Binary Flat Device Tree Blob */
> IH_TYPE_KWBIMAGE, /* Kirkwood Boot Image */
> IH_TYPE_IMXIMAGE, /* Freescale IMXBoot Image */
> - IH_TYPE_IMX8IMAGE, /* Freescale IMX8Boot Image */
> IH_TYPE_UBLIMAGE, /* Davinci UBL Image*/
> IH_TYPE_OMAPIMAGE, /* TI OMAP Config Header Image */
> IH_TYPE_AISIMAGE, /* TI Davinci AIS Image */
> @@ -278,6 +277,7 @@ enum {
> IH_TYPE_PMMC,/* TI Power Management Micro-Controller
> Firmware */
> IH_TYPE_STM32IMAGE, /* STMicroelectronics STM32 Image */
> IH_TYPE_SOCFPGAIMAGE_V1,/* Altera SOCFPGA A10 Preloader */
> + IH_TYPE_IMX8IMAGE, /* Freescale IMX8Boot Image */
>
> IH_TYPE_COUNT, /* Number of image types */
> };
>
--
=
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] nand: fix up badblock skipping
Hi Jiri, Miquel,
On 24/10/18 15:56, Miquel Raynal wrote:
> Hi Jiri,
>
> Jiri Valek wrote on Fri, 19 Oct 2018 10:15:55
> +0200:
>
>> From: Jiri Valek
>>
>> Currently the badblock skipping fails. SPL loader fails to boot from NAND.
>> End up on message "SPL: failed to boot from all boot devices"
>>
>> Signed-off-by: Jiri Valek
>> ---
>>
>> drivers/mtd/nand/raw/mxs_nand_spl.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
>> b/drivers/mtd/nand/raw/mxs_nand_spl.c
>> index 2d7bbe83cc..56618c95dc 100644
>> --- a/drivers/mtd/nand/raw/mxs_nand_spl.c
>> +++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
>> @@ -239,6 +239,7 @@ int nand_spl_load_image(uint32_t offs, unsigned int
>> size, void *buf)
>> */
>> while (is_badblock(mtd, offs, 1)) {
>> page = page + nand_page_per_block;
>> +offs = offs + mtd.erasesize;
>> /* Check i we've reached the end of flash. */
>> if (page >= mtd->size >> chip->page_shift)
>> return -ENOMEM;
>
> Reviewed-by: Miquel Raynal
>
I agree that secto must be skipped, but implementation looks wrong. mtd
is a pointer, and the above line should be off + mtd->erasesize. Do you
build with it ? I tried to apply it, as expected it cannot be compiled
clean.
Best regards,
Stefano Babic
--
=
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 v3 13/28] mtd: ensure MTD is compiled when ENV_IS_IN_FLASH is selected
Dear Miquel, In message <20181206162300.7ccfddda@xps13> you wrote: > > Do you see another significant impact that must prevent NOR flashes to > depend on MTD? My concern here is only resources. If the memory footprint really does not grow, I'm fine with that. But I somwhow doubt this is possible. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The aim of science is not to open the door to everlasting wisdom but to set a limit on everlasting error. - Bertolt Brecht ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: fsl_esdhc: Avoid infinite loop in esdhc_send_cmd_common()
Hi Jaehoon, On Mon, Nov 19, 2018 at 10:31 AM Fabio Estevam wrote: > > The following hang is observed on a Hummingboard 2 MicroSOM > i2eX iMX6D - rev 1.3 with no eMMC populated on board: > > U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +) > Trying to boot from MMC1 > > U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +) > > CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) > CPU: Extended Commercial temperature grade (-20C to 105C) at 33C > Reset cause: POR > Board: MX6 HummingBoard2 > DRAM: 1 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > No panel detected: default to HDMI > Display: HDMI (1024x768) > In:serial > Out: serial > Err: serial > ---> hangs > > which is caused by the following infinite loop inside esdhc_send_cmd_common() > > while (!(esdhc_read32(>irqstat) & flags)) > ; > > Instead of looping forever, provide an exit path so that a timeout > error can be propagated in the case irqstat does not report > any interrupts, which may happen when no eMMC is populated on > board. > > Reported-by: Ricardo Salveti > Signed-off-by: Fabio Estevam Could this one be applied to 2019.01? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5] pico-imx7d: Increase the CONFIG_ENV_OFFSET size
U-Boot binary has grown in such a way that it goes beyond the reserved area for the environment variables. Running "saveenv" causes U-Boot to hang because of this overlap. Fix this problem by increasing the CONFIG_ENV_OFFSET size. Also, in order to prevent this same problem to happen again in the future, use CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time. CONFIG_BOARD_SIZE_LIMIT is CONFIG_ENV_OFFSET - 69 kB, as u-boot.img is flashed into the 69 kB offset. Signed-off-by: Fabio Estevam --- Changes since v4: - Use math expressions for better readability Hi Stefano, This one depends on Wolfgang's v2 patch: https://lists.denx.de/pipermail/u-boot/2018-December/351138.html include/configs/pico-imx7d.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h index 2bc42a0..333c0b4 100644 --- a/include/configs/pico-imx7d.h +++ b/include/configs/pico-imx7d.h @@ -134,7 +134,8 @@ /* FLASH and environment organization */ #define CONFIG_ENV_SIZESZ_8K -#define CONFIG_ENV_OFFSET (8 * SZ_64K) +#define CONFIG_ENV_OFFSET (768 * 1024) +#define CONFIG_BOARD_SIZE_LIMIT((768 - 69) * 1024) #define CONFIG_SYS_FSL_USDHC_NUM 2 #define CONFIG_SYS_MMC_ENV_DEV 0 -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Sat, Dec 08, 2018 at 02:24:02AM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > thanks, > Jagan. > > The following changes since commit 57dbc151437b36cc1105857d222df28b095236d7: > > rockchip: rk3399: Add MAINTAINERS entry (2018-12-06 10:24:12 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 8a6121ea078347de017c833e131eb4a806cf0c51: > > sunxi: update README.sunxi64 (2018-12-07 22:30:19 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20181207
On Fri, Dec 07, 2018 at 11:02:03AM +0100, Neil Armstrong wrote: > Hi Tom, > > Two simple fixes for the pinctrl driver. > > Thanks, > Neil > > The following changes since commit d452f27b3ea806fd99aee4b73a723318032c1d5c: > > Prepare v2019.01-rc1 (2018-12-03 23:50:13 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20181207 > > for you to fetch changes up to 139ebe9eb9dac96ab72680e7e8ba77ef9b4cc88b: > > pinctrl: meson: axg: Fix GPIO pin offsets (2018-12-07 11:01:09 +0100) > 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] [BUG] Odroid-C2 does not boot with U-Boot master anymore
Hello Alex,
the patch 7a82c3051c8f ("efi_loader: Align runtime section to 64kb")
currently breaks booting Linux on the Odroid-C2.
Output stops for kernel 4.18 after earlycon is replaced:
[0.012518] console [tty0] enabled
[0.015923] bootconsole [meson0] disabled
Without your patch it continues.
The calculation introduced by the patch does what is expected:
ram_start = 0x
ram_end = 0x8000
__efi_runtime_start = 0x7ff67118
~runtime_mask = 0x
runtime_start = 0x7ff6
runtime_end = 0x7ff7
These two memory reservation do not conflict with addresses in question:
arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
0x-0x0100
arch/arm/mach-meson/board-common.c(60) meson_board_add_reserved_memory:
0x1000-0x1020
Regards
Heinrich
On 9/17/18 1:54 PM, Alexander Graf wrote:
> The UEFI spec mandates that runtime sections are 64kb aligned to enable
> support for 64kb page size OSs.
>
> This patch ensures that we extend the runtime section to 64kb to be spec
> compliant.
>
> Signed-off-by: Alexander Graf
>
> ---
>
> v1 -> v2:
>
> - rename kb to KiB in accordance to the spec
> - add reference to spec section for alignment requirement
> - only use 64KiB alignment on aarch64
> ---
> lib/efi_loader/efi_memory.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index 5bd4f4d7fc..b4cb543275 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -563,6 +564,7 @@ __weak void efi_add_known_memory(void)
> static void add_u_boot_and_runtime(void)
> {
> unsigned long runtime_start, runtime_end, runtime_pages;
> + unsigned long runtime_mask = EFI_PAGE_MASK;
> unsigned long uboot_start, uboot_pages;
> unsigned long uboot_stack_size = 16 * 1024 * 1024;
>
> @@ -571,10 +573,22 @@ static void add_u_boot_and_runtime(void)
> uboot_pages = (gd->ram_top - uboot_start) >> EFI_PAGE_SHIFT;
> efi_add_memory_map(uboot_start, uboot_pages, EFI_LOADER_DATA, false);
>
> - /* Add Runtime Services */
> - runtime_start = (ulong)&__efi_runtime_start & ~EFI_PAGE_MASK;
> +#if defined(__aarch64__)
> + /*
> + * Runtime Services must be 64KiB aligned according to the
> + * "AArch64 Platforms" section in the UEFI spec (2.7+).
> + */
> +
> + runtime_mask = SZ_64K - 1;
> +#endif
> +
> + /*
> + * Add Runtime Services. We mark surrounding boottime code as runtime as
> + * well to fulfill the runtime alignment constraints but avoid padding.
> + */
> + runtime_start = (ulong)&__efi_runtime_start & ~runtime_mask;
> runtime_end = (ulong)&__efi_runtime_stop;
> - runtime_end = (runtime_end + EFI_PAGE_MASK) & ~EFI_PAGE_MASK;
> + runtime_end = (runtime_end + runtime_mask) & ~runtime_mask;
> runtime_pages = (runtime_end - runtime_start) >> EFI_PAGE_SHIFT;
> efi_add_memory_map(runtime_start, runtime_pages,
> EFI_RUNTIME_SERVICES_CODE, false);
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] gpio: mscc-bitbang-spi: Add a simple gpio driver for bitbgang spi
Hi,
On mar., oct. 09 2018, Gregory CLEMENT wrote:
> The VCore III SoCs such as the Luton but also the Ocelot can remap an SPI
> flash directly in memory. However, for writing in the flash the
> communication has to be done by software.
>
> Each of the signal used for the SPI are exposed in a single register. In
> order to be able to use the soft-spi driver, the management of this pin
> is done through this simple gpio driver.
>
> Even if the main purpose of this driver is to be used by soft-spi, it can
> still be used as a normal gpio driver but with limitation: for example
> the first pin can't be used as output.
>
> Signed-off-by: Gregory CLEMENT
> ---
> Changelog:
> v1 -> v2:
> - use const and static when needed
> - fix style
> - use dev_remap_addr
I sent this version 2 months ago and addressed all the comments, how
could we going further ?
Thanks,
Gregory
>
> drivers/gpio/Kconfig | 7 ++
> drivers/gpio/Makefile| 1 +
> drivers/gpio/gpio-mscc-bitbang-spi.c | 122 +++
> 3 files changed, 130 insertions(+)
> create mode 100644 drivers/gpio/gpio-mscc-bitbang-spi.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 5cd8b34400..947a59cce3 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -99,6 +99,13 @@ config LPC32XX_GPIO
> help
> Support for the LPC32XX GPIO driver.
>
> +config MSCC_BITBANG_SPI_GPIO
> + bool "Microsemi bitbang spi GPIO driver"
> + depends on DM_GPIO && SOC_VCOREIII
> + help
> + Support controlling the GPIO used for SPI bitbang by software. Can
> + be used by the VCoreIII SoCs, but it was mainly useful for Luton.
> +
> config MSM_GPIO
> bool "Qualcomm GPIO driver"
> depends on DM_GPIO
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index f186120684..2085dd3cba 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -58,3 +58,4 @@ obj-$(CONFIG_MVEBU_GPIO)+= mvebu_gpio.o
> obj-$(CONFIG_MSM_GPIO) += msm_gpio.o
> obj-$(CONFIG_$(SPL_)PCF8575_GPIO)+= pcf8575_gpio.o
> obj-$(CONFIG_PM8916_GPIO)+= pm8916_gpio.o
> +obj-$(CONFIG_MSCC_BITBANG_SPI_GPIO) += gpio-mscc-bitbang-spi.o
> diff --git a/drivers/gpio/gpio-mscc-bitbang-spi.c
> b/drivers/gpio/gpio-mscc-bitbang-spi.c
> new file mode 100644
> index 00..b675f9052c
> --- /dev/null
> +++ b/drivers/gpio/gpio-mscc-bitbang-spi.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +/*
> + * Microsemi SoCs pinctrl driver
> + *
> + * Author:
> + * License: Dual MIT/GPL
> + * Copyright (c) 2018 Microsemi Corporation
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum {
> + SDI,
> + CS0,
> + CS1,
> + CS2,
> + CS3,
> + SDO,
> + SCK
> +};
> +
> +static const int pinmap[] = { 0, 5, 6, 7, 8, 10, 12 };
> +
> +#define SW_SPI_CSn_OE 0x1E /* bits 1 to 4 */
> +#define SW_SPI_CS0_OE BIT(1)
> +#define SW_SPI_SDO_OE BIT(9)
> +#define SW_SPI_SCK_OE BIT(11)
> +#define SW_PIN_CTRL_MODE BIT(13)
> +
> +struct mscc_bb_spi_gpio {
> + void __iomem *regs;
> + u32 cache_val;
> +};
> +
> +static int mscc_bb_spi_gpio_set(struct udevice *dev, unsigned oft, int val)
> +{
> + struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
> +
> + if (val)
> + gpio->cache_val |= BIT(pinmap[oft]);
> + else
> + gpio->cache_val &= ~BIT(pinmap[oft]);
> +
> + writel(gpio->cache_val, gpio->regs);
> +
> + return 0;
> +}
> +
> +static int mscc_bb_spi_gpio_direction_output(struct udevice *dev, unsigned
> oft,
> + int val)
> +{
> + if (oft == 0) {
> + pr_err("SW_SPI_DSI can't be used as output\n");
> + return -ENOTSUPP;
> + }
> +
> + mscc_bb_spi_gpio_set(dev, oft, val);
> +
> + return 0;
> +}
> +
> +static int mscc_bb_spi_gpio_direction_input(struct udevice *dev, unsigned
> oft)
> +{
> + return 0;
> +}
> +
> +static int mscc_bb_spi_gpio_get(struct udevice *dev, unsigned int oft)
> +{
> + struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
> + u32 val = readl(gpio->regs);
> +
> + return !!(val & BIT(pinmap[oft]));
> +}
> +
> +static const struct dm_gpio_ops mscc_bb_spi_gpio_ops = {
> + .direction_output = mscc_bb_spi_gpio_direction_output,
> + .direction_input= mscc_bb_spi_gpio_direction_input,
> + .set_value = mscc_bb_spi_gpio_set,
> + .get_value = mscc_bb_spi_gpio_get,
> +};
> +
> +static int mscc_bb_spi_gpio_probe(struct udevice *dev)
> +{
> + struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
> + struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> +
> + gpio->regs = dev_remap_addr(dev);
> + if (!gpio->regs)
> + return -EINVAL;
> +
> + uc_priv->bank_name = dev->name;
> + uc_priv->gpio_count = ARRAY_SIZE(pinmap);
> +
[U-Boot] [PATCH v3] pinctrl: mscc: Add gpio and pinctrl driver for MSCC MIPS SoCs (VcoreIII based)
This driver supports the pin and gpio controller found in the Ocelot and
Luton SoCs.
The driver was inspired from the pinctrl driver in Linux, but was
simplified and was modified to allow supporting an other SoCs (Luton).
For Ocelot and Luton the controller is the same, only the pins to program
differ.
Signed-off-by: Gregory CLEMENT
---
Hi,
I sent the second version _2_ months ago and did not get
anyfeedback. I hope this patch could be merge soon.
Thanks!
Changelog:
v2 -> v3:
- fix the return value of mscc_gpio_get_direction (reported by Lars
Povlsen)
v1 -> v2:
- use clrbits and setbits from MIPS
- use const and static when needed
- fix style
- use dev_remap_addr
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/mscc/Kconfig | 22 +++
drivers/pinctrl/mscc/Makefile | 5 +
drivers/pinctrl/mscc/mscc-common.c| 236 ++
drivers/pinctrl/mscc/mscc-common.h| 51 ++
drivers/pinctrl/mscc/pinctrl-luton.c | 172 +++
drivers/pinctrl/mscc/pinctrl-ocelot.c | 188
8 files changed, 676 insertions(+)
create mode 100644 drivers/pinctrl/mscc/Kconfig
create mode 100644 drivers/pinctrl/mscc/Makefile
create mode 100644 drivers/pinctrl/mscc/mscc-common.c
create mode 100644 drivers/pinctrl/mscc/mscc-common.h
create mode 100644 drivers/pinctrl/mscc/pinctrl-luton.c
create mode 100644 drivers/pinctrl/mscc/pinctrl-ocelot.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ad0b8daba6..cc82f91579 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -305,6 +305,7 @@ source "drivers/pinctrl/nxp/Kconfig"
source "drivers/pinctrl/renesas/Kconfig"
source "drivers/pinctrl/uniphier/Kconfig"
source "drivers/pinctrl/exynos/Kconfig"
+source "drivers/pinctrl/mscc/Kconfig"
source "drivers/pinctrl/mvebu/Kconfig"
source "drivers/pinctrl/broadcom/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a3a6c6d163..2461dba293 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_PINCTRL_UNIPHIER)+= uniphier/
obj-$(CONFIG_PINCTRL_PIC32)+= pinctrl_pic32.o
obj-$(CONFIG_PINCTRL_EXYNOS) += exynos/
obj-$(CONFIG_PINCTRL_MESON)+= meson/
+obj-y += mscc/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_STI) += pinctrl-sti.o
diff --git a/drivers/pinctrl/mscc/Kconfig b/drivers/pinctrl/mscc/Kconfig
new file mode 100644
index 00..cfc6c06076
--- /dev/null
+++ b/drivers/pinctrl/mscc/Kconfig
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+config PINCTRL_MSCC
+ bool
+
+config PINCTRL_MSCC_OCELOT
+ depends on SOC_OCELOT && PINCTRL_FULL && OF_CONTROL
+ select PINCTRL_MSCC
+ default y
+ bool "Microsemi ocelot family pin control driver"
+ help
+ Support pin multiplexing and pin configuration control on
+ Microsemi ocelot SoCs.
+
+config PINCTRL_MSCC_LUTON
+ depends on SOC_LUTON && PINCTRL_FULL && OF_CONTROL
+ select PINCTRL_MSCC
+ default y
+ bool "Microsemi luton family pin control driver"
+ help
+ Support pin multiplexing and pin configuration control on
+ Microsemi luton SoCs.
diff --git a/drivers/pinctrl/mscc/Makefile b/drivers/pinctrl/mscc/Makefile
new file mode 100644
index 00..941f418ff9
--- /dev/null
+++ b/drivers/pinctrl/mscc/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+obj-$(CONFIG_PINCTRL_MSCC) += mscc-common.o
+obj-$(CONFIG_PINCTRL_MSCC_OCELOT) += pinctrl-ocelot.o
+obj-$(CONFIG_PINCTRL_MSCC_LUTON) += pinctrl-luton.o
diff --git a/drivers/pinctrl/mscc/mscc-common.c
b/drivers/pinctrl/mscc/mscc-common.c
new file mode 100644
index 00..d74b8a6649
--- /dev/null
+++ b/drivers/pinctrl/mscc/mscc-common.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Microsemi SoCs pinctrl driver
+ *
+ * Author:
+ * Author:
+ * License: Dual MIT/GPL
+ * Copyright (c) 2017 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mscc-common.h"
+
+#define MSCC_GPIO_OUT_SET 0x0
+#define MSCC_GPIO_OUT_CLR 0x4
+#define MSCC_GPIO_OUT 0x8
+#define MSCC_GPIO_IN 0xc
+#define MSCC_GPIO_OE 0x10
+#define MSCC_GPIO_INTR 0x14
+#define MSCC_GPIO_INTR_ENA 0x18
+#define MSCC_GPIO_INTR_IDENT 0x1c
+#define MSCC_GPIO_ALT0 0x20
+#define MSCC_GPIO_ALT1 0x24
+
+static int mscc_get_functions_count(struct udevice *dev)
+{
+ struct mscc_pinctrl *info = dev_get_priv(dev);
+
+ return info->num_func;
+}
+
+static const char *mscc_get_function_name(struct udevice *dev,
+ unsigned int
[U-Boot] [PATCH 1/1] test: overlay: NULL passed as fdt
The uts created in do_ut_overlay() is not the one used in
cmd_ut_category(). Currently all tests are therefore called with
uts->priv = NULL and fail.
Using a static variable is the easiest fix here.
Fixes: e93232e15ec9 ("test: overlay: Use cmd_ut_category()")
Signed-off-by: Heinrich Schuchardt
---
test/overlay/cmd_ut_overlay.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/test/overlay/cmd_ut_overlay.c b/test/overlay/cmd_ut_overlay.c
index 3d34c8ab53a..fc2491d0b47 100644
--- a/test/overlay/cmd_ut_overlay.c
+++ b/test/overlay/cmd_ut_overlay.c
@@ -23,6 +23,8 @@ extern u32 __dtb_test_fdt_base_begin;
extern u32 __dtb_test_fdt_overlay_begin;
extern u32 __dtb_test_fdt_overlay_stacked_begin;
+static void *fdt;
+
static int ut_fdt_getprop_u32_by_index(void *fdt, const char *path,
const char *name, int index,
u32 *out)
@@ -67,7 +69,6 @@ static int fdt_getprop_str(void *fdt, const char *path, const
char *name,
static int fdt_overlay_change_int_property(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
u32 val = 0;
ut_assertok(ut_fdt_getprop_u32(fdt, "/test-node", "test-int-property",
@@ -80,7 +81,6 @@ OVERLAY_TEST(fdt_overlay_change_int_property, 0);
static int fdt_overlay_change_str_property(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
const char *val = NULL;
ut_assertok(fdt_getprop_str(fdt, "/test-node", "test-str-property",
@@ -93,7 +93,6 @@ OVERLAY_TEST(fdt_overlay_change_str_property, 0);
static int fdt_overlay_add_str_property(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
const char *val = NULL;
ut_assertok(fdt_getprop_str(fdt, "/test-node", "test-str-property-2",
@@ -106,7 +105,6 @@ OVERLAY_TEST(fdt_overlay_add_str_property, 0);
static int fdt_overlay_add_node_by_phandle(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
int off;
off = fdt_path_offset(fdt, "/test-node/new-node");
@@ -120,7 +118,6 @@ OVERLAY_TEST(fdt_overlay_add_node_by_phandle, 0);
static int fdt_overlay_add_node_by_path(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
int off;
off = fdt_path_offset(fdt, "/new-node");
@@ -134,7 +131,6 @@ OVERLAY_TEST(fdt_overlay_add_node_by_path, 0);
static int fdt_overlay_add_subnode_property(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
int off;
off = fdt_path_offset(fdt, "/test-node/sub-test-node");
@@ -150,7 +146,6 @@ OVERLAY_TEST(fdt_overlay_add_subnode_property, 0);
static int fdt_overlay_local_phandle(struct unit_test_state *uts)
{
uint32_t local_phandle;
- void *fdt = uts->priv;
u32 val = 0;
int off;
@@ -175,7 +170,6 @@ OVERLAY_TEST(fdt_overlay_local_phandle, 0);
static int fdt_overlay_local_phandles(struct unit_test_state *uts)
{
uint32_t local_phandle, test_phandle;
- void *fdt = uts->priv;
u32 val = 0;
int off;
@@ -205,7 +199,6 @@ OVERLAY_TEST(fdt_overlay_local_phandles, 0);
static int fdt_overlay_stacked(struct unit_test_state *uts)
{
- void *fdt = uts->priv;
u32 val = 0;
ut_assertok(ut_fdt_getprop_u32(fdt, "/new-local-node",
@@ -225,7 +218,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
void *fdt_base = &__dtb_test_fdt_base_begin;
void *fdt_overlay = &__dtb_test_fdt_overlay_begin;
void *fdt_overlay_stacked = &__dtb_test_fdt_overlay_stacked_begin;
- void *fdt_base_copy, *fdt_overlay_copy, *fdt_overlay_stacked_copy;
+ void *fdt_overlay_copy, *fdt_overlay_stacked_copy;
int ret = -ENOMEM;
uts = calloc(1, sizeof(*uts));
@@ -235,10 +228,9 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
ut_assertok(fdt_check_header(fdt_base));
ut_assertok(fdt_check_header(fdt_overlay));
- fdt_base_copy = malloc(FDT_COPY_SIZE);
- if (!fdt_base_copy)
+ fdt = malloc(FDT_COPY_SIZE);
+ if (!fdt)
goto err1;
- uts->priv = fdt_base_copy;
fdt_overlay_copy = malloc(FDT_COPY_SIZE);
if (!fdt_overlay_copy)
@@ -254,7 +246,7 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
* (and relocate it since the memory might be mapped
* read-only)
*/
- ut_assertok(fdt_open_into(fdt_base, fdt_base_copy, FDT_COPY_SIZE));
+ ut_assertok(fdt_open_into(fdt_base, fdt, FDT_COPY_SIZE));
/*
* Resize the overlay to 4k so that we have room to operate on
@@ -275,10 +267,10 @@ int do_ut_overlay(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
FDT_COPY_SIZE));
/* Apply the overlay */
- ut_assertok(fdt_overlay_apply(fdt_base_copy, fdt_overlay_copy));
+
[U-Boot] [BUG] ut overlay fails with v2018.03 and later on qemu-arm64_defconfig
Hello Simon,
on qemu-arm_defconfig fails with
=> ut overlay
Running 9 overlay tests
Test: fdt_overlay_add_node_by_path
test/overlay/cmd_ut_overlay.c:127, fdt_overlay_add_node_by_path(): off >= 0
Test: fdt_overlay_add_node_by_phandle
test/overlay/cmd_ut_overlay.c:113, fdt_overlay_add_node_by_phandle():
off >= 0
Test: fdt_overlay_add_str_property
test/overlay/cmd_ut_overlay.c:100, fdt_overlay_add_str_property(): 0 ==
fdt_getprop_str(fdt, "/test-node", "test-str-property-2", ):
Expected 0, got -9
Test: fdt_overlay_add_subnode_property
test/overlay/cmd_ut_overlay.c:141, fdt_overlay_add_subnode_property():
off >= 0
Test: fdt_overlay_change_int_property
test/overlay/cmd_ut_overlay.c:74, fdt_overlay_change_int_property(): 0
== ut_fdt_getprop_u32(fdt, "/test-node", "test-int-property", ):
Expected 0, got -9
Test: fdt_overlay_change_str_property
test/overlay/cmd_ut_overlay.c:87, fdt_overlay_change_str_property(): 0
== fdt_getprop_str(fdt, "/test-node", "test-str-property", ):
Expected 0, got -9
Test: fdt_overlay_local_phandle
test/overlay/cmd_ut_overlay.c:158, fdt_overlay_local_phandle(): off >= 0
Test: fdt_overlay_local_phandles
test/overlay/cmd_ut_overlay.c:183, fdt_overlay_local_phandles(): off >= 0
Test: fdt_overlay_stacked
test/overlay/cmd_ut_overlay.c:212, fdt_overlay_stacked(): 0 ==
ut_fdt_getprop_u32(fdt, "/new-local-node", "stacked-test-int-property",
): Expected 0, got -9
Failures: 9
This is reproducable with v2018.03, v2018.05, v2018.07, v2018.09,
v2018.11 and with current origin/master (358902586727 "Merge branch
'2018-12-06-master-imports'").
For the elder releases I had to apply
d796735c334b "test: overlay: add missing include"
The value of off is -9 in the tests above. This is -FDT_ERR_BADMAGIC.
Adding some debug output sheds more light:
test/overlay/cmd_ut_overlay.c(290) do_ut_overlay: fdt_base_copy
7ef33340
test/overlay/cmd_ut_overlay.c(291) do_ut_overlay: uts->priv 7ef33340
Running 9 overlay tests
Test: fdt_overlay_add_node_by_path
test/overlay/cmd_ut_overlay.c(127) fdt_overlay_add_node_by_path:
uts->priv
This is the patch that led to problem:
e93232e15ec9 ("test: overlay: Use cmd_ut_category()")
The uts created in do_ut_overlay() is not the one used in cmd_ut_category().
The easiest fix would be using a static variable for passing the fdt.
The neatest solution would be cmd_ut_category() calling an
initialization function for the category so that we can use a single
instance of uts for the whole test.
As this API is your design I would prefer leaving the resolution to you.
Besides resolving the error I think we should run 'ut overlay' on Travis
CI for all qemu platforms.
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] rsa: read out public_exponent value based on 32-bit alignment
Public_exponent is a 64-bit data, which is stored in the device tree
blob in a 32-bit alignment address. This causes a problem for ARM64 when
public_exponent is read out one shot as a 64-bit data from an unaligned
address. Hence, to solve this problem, public_exponent is read out as two
32-bit datas, and then concatenating them.
Signed-off-by: Ooi, Joyce
---
lib/rsa/rsa-mod-exp.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/rsa/rsa-mod-exp.c b/lib/rsa/rsa-mod-exp.c
index 9d78aa1..3eace38 100644
--- a/lib/rsa/rsa-mod-exp.c
+++ b/lib/rsa/rsa-mod-exp.c
@@ -252,6 +252,9 @@ int rsa_mod_exp_sw(const uint8_t *sig, uint32_t sig_len,
{
struct rsa_public_key key;
int ret;
+ uint64_t exponent =
+ (uint64_t)(*((uint32_t *)(prop->public_exponent + 4))) << 32 |
+ *((uint32_t *)(prop->public_exponent));
if (!prop) {
debug("%s: Skipping invalid prop", __func__);
@@ -263,8 +266,7 @@ int rsa_mod_exp_sw(const uint8_t *sig, uint32_t sig_len,
if (!prop->public_exponent)
key.exponent = RSA_DEFAULT_PUBEXP;
else
- key.exponent =
- fdt64_to_cpu(*((uint64_t *)(prop->public_exponent)));
+ key.exponent = fdt64_to_cpu(exponent);
if (!key.len || !prop->modulus || !prop->rr) {
debug("%s: Missing RSA key info", __func__);
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
