[U-Boot] [PATCH v4 5/5] riscv: configs: AE350 will use CONFIG_OF_SEPARATE when boots from flash
From: Rick Chen
When AE350 boots from flash, use CONFIG_OF_SEPARATE instead of
CONFIG_OF_BOARD.
Also remove unused code about prior_stage_fdt_address.
And modify CONFIG_SYS_FDT_BASE as flash address.
Signed-off-by: Rick Chen
Cc: Greentime Hu
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 4
configs/ae350_rv32_xip_defconfig| 2 +-
configs/ae350_rv64_xip_defconfig| 2 +-
include/configs/ax25-ae350.h| 2 +-
4 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index d343453..3d65ce7 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -67,10 +67,6 @@ ulong board_flash_get_legacy(ulong base, int banknum,
flash_info_t *info)
void *board_fdt_blob_setup(void)
{
- void **ptr = (void *)_stage_fdt_address;
- if (fdt_magic(*ptr) == FDT_MAGIC)
- return (void *)*ptr;
-
return (void *)CONFIG_SYS_FDT_BASE;
}
diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig
index 76534f2..07f1ecc 100644
--- a/configs/ae350_rv32_xip_defconfig
+++ b/configs/ae350_rv32_xip_defconfig
@@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_BOOTP_PREFER_SERVERIP=y
CONFIG_CMD_CACHE=y
-CONFIG_OF_BOARD=y
+CONFIG_OF_SEPARATE=y
CONFIG_DEFAULT_DEVICE_TREE="ae350_32"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_NET_RANDOM_ETHADDR=y
diff --git a/configs/ae350_rv64_xip_defconfig b/configs/ae350_rv64_xip_defconfig
index f7f2925..28afd81 100644
--- a/configs/ae350_rv64_xip_defconfig
+++ b/configs/ae350_rv64_xip_defconfig
@@ -16,7 +16,7 @@ CONFIG_CMD_SF_TEST=y
# CONFIG_CMD_SETEXPR is not set
CONFIG_BOOTP_PREFER_SERVERIP=y
CONFIG_CMD_CACHE=y
-CONFIG_OF_BOARD=y
+CONFIG_OF_SEPARATE=y
CONFIG_DEFAULT_DEVICE_TREE="ae350_64"
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_NET_RANDOM_ETHADDR=y
diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
index 395f3a4..a4037f3 100644
--- a/include/configs/ax25-ae350.h
+++ b/include/configs/ax25-ae350.h
@@ -40,7 +40,7 @@
#define CONFIG_SYS_MALLOC_LEN (512 << 10)
/* DT blob (fdt) address */
-#define CONFIG_SYS_FDT_BASE0x000f
+#define CONFIG_SYS_FDT_BASE0x800f
/*
* Physical Memory Map
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 3/5] riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled
From: Rick Chen
This patch will fix prior_stage_fdt_address write failure problem, when
AE350 boots from flash.
When AE350 boots from flash, prior_stage_fdt_address will be flash
address, we shall avoid it to be written.
Signed-off-by: Rick Chen
Cc: Greentime Hu
---
arch/riscv/cpu/cpu.c | 2 ++
arch/riscv/cpu/start.S | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index 0cfd7d6..e9a8b43 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -15,7 +15,9 @@
* The variables here must be stored in the data section since they are used
* before the bss section is available.
*/
+#ifdef CONFIG_OF_PRIOR_STAGE
phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
+#endif
#ifndef CONFIG_XIP
u32 hart_lottery __attribute__((section(".data"))) = 0;
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 3402d09..60ac8c6 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -111,8 +111,10 @@ call_board_init_f_0:
bneztp, secondary_hart_loop
#endif
+#ifdef CONFIG_OF_PRIOR_STAGE
la t0, prior_stage_fdt_address
SREGs1, 0(t0)
+#endif
jal board_init_f_init_reserve
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 4/5] riscv: configs: AE350 will use CONFIG_OF_PRIOR_STAGE when boots from ram
From: Rick Chen When AE350 boots from ram, use CONFIG_OF_PRIOR_STAGE instead of CONFIG_OF_BOARD. Signed-off-by: Rick Chen Cc: Greentime Hu Reviewed-by: Bin Meng Reviewed-by: Lukas Auer --- configs/ae350_rv32_defconfig | 2 +- configs/ae350_rv64_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/ae350_rv32_defconfig b/configs/ae350_rv32_defconfig index f029455..71d2716 100644 --- a/configs/ae350_rv32_defconfig +++ b/configs/ae350_rv32_defconfig @@ -14,7 +14,7 @@ CONFIG_CMD_SF_TEST=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y -CONFIG_OF_BOARD=y +CONFIG_OF_PRIOR_STAGE=y CONFIG_DEFAULT_DEVICE_TREE="ae350_32" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/configs/ae350_rv64_defconfig b/configs/ae350_rv64_defconfig index 98635a2..9bf1737 100644 --- a/configs/ae350_rv64_defconfig +++ b/configs/ae350_rv64_defconfig @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y # CONFIG_CMD_SETEXPR is not set CONFIG_BOOTP_PREFER_SERVERIP=y CONFIG_CMD_CACHE=y -CONFIG_OF_BOARD=y +CONFIG_OF_PRIOR_STAGE=y CONFIG_DEFAULT_DEVICE_TREE="ae350_64" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_NET_RANDOM_ETHADDR=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] riscv: configs: Support AE350 SMP booting from flash flow
From: Rick Chen Add two defconfigs to support AE350 SMP booting from flash. Signed-off-by: Rick Chen Cc: Greentime Hu Reviewed-by: Bin Meng Reviewed-by: Lukas Auer --- configs/ae350_rv32_xip_defconfig | 37 + configs/ae350_rv64_xip_defconfig | 38 ++ 2 files changed, 75 insertions(+) create mode 100644 configs/ae350_rv32_xip_defconfig create mode 100644 configs/ae350_rv64_xip_defconfig diff --git a/configs/ae350_rv32_xip_defconfig b/configs/ae350_rv32_xip_defconfig new file mode 100644 index 000..76534f2 --- /dev/null +++ b/configs/ae350_rv32_xip_defconfig @@ -0,0 +1,37 @@ +CONFIG_RISCV=y +CONFIG_SYS_TEXT_BASE=0x8000 +CONFIG_XIP=y +CONFIG_TARGET_AX25_AE350=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SYS_PROMPT="RISC-V # " +CONFIG_CMD_IMLS=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_BOOTP_PREFER_SERVERIP=y +CONFIG_CMD_CACHE=y +CONFIG_OF_BOARD=y +CONFIG_DEFAULT_DEVICE_TREE="ae350_32" +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_MMC=y +CONFIG_FTSDC010=y +CONFIG_FTSDC010_SDIO=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_CFI_FLASH=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_FTMAC100=y +CONFIG_BAUDRATE=38400 +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_ATCSPI200_SPI=y diff --git a/configs/ae350_rv64_xip_defconfig b/configs/ae350_rv64_xip_defconfig new file mode 100644 index 000..f7f2925 --- /dev/null +++ b/configs/ae350_rv64_xip_defconfig @@ -0,0 +1,38 @@ +CONFIG_RISCV=y +CONFIG_SYS_TEXT_BASE=0x8000 +CONFIG_XIP=y +CONFIG_TARGET_AX25_AE350=y +CONFIG_ARCH_RV64I=y +CONFIG_DISTRO_DEFAULTS=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_BOARD_EARLY_INIT_F=y +CONFIG_SYS_PROMPT="RISC-V # " +CONFIG_CMD_IMLS=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SF=y +CONFIG_CMD_SF_TEST=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_BOOTP_PREFER_SERVERIP=y +CONFIG_CMD_CACHE=y +CONFIG_OF_BOARD=y +CONFIG_DEFAULT_DEVICE_TREE="ae350_64" +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_MMC=y +CONFIG_FTSDC010=y +CONFIG_FTSDC010_SDIO=y +CONFIG_MTD_NOR_FLASH=y +CONFIG_FLASH_CFI_DRIVER=y +CONFIG_CFI_FLASH=y +CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y +CONFIG_SYS_FLASH_CFI=y +CONFIG_SPI_FLASH=y +CONFIG_SF_DEFAULT_MODE=0x0 +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_FTMAC100=y +CONFIG_BAUDRATE=38400 +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_ATCSPI200_SPI=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] riscv: Introduce CONFIG_XIP to support booting from flash
From: Rick Chen
When U-Boot boots from flash, during the boot process,
hart_lottery and available_harts_lock variable addresses
point to flash which is not writable. This causes boot
failures on AE350. Introduce a config option CONFIG_XIP
to support such configuration.
Signed-off-by: Rick Chen
Cc: Greentime Hu
Reviewed-by: Lukas Auer
---
arch/riscv/Kconfig | 7 +++
arch/riscv/cpu/cpu.c | 2 ++
arch/riscv/cpu/start.S | 6 ++
arch/riscv/include/asm/global_data.h | 2 ++
arch/riscv/lib/asm-offsets.c | 2 ++
arch/riscv/lib/smp.c | 2 ++
6 files changed, 21 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ae8ff7b..362f3cd 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -162,6 +162,13 @@ config SBI_IPI
default y if RISCV_SMODE
depends on SMP
+config XIP
+ bool "XIP mode"
+ help
+ XIP (eXecute In Place) is a method for executing code directly
+ from a NOR flash memory without copying the code to ram.
+ Say yes here if U-Boot boots from flash directly.
+
config STACK_SIZE_SHIFT
int
default 13
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index c32de8a..0cfd7d6 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -16,6 +16,7 @@
* before the bss section is available.
*/
phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
+#ifndef CONFIG_XIP
u32 hart_lottery __attribute__((section(".data"))) = 0;
/*
@@ -23,6 +24,7 @@ u32 hart_lottery __attribute__((section(".data"))) = 0;
* finished initialization of global data.
*/
u32 available_harts_lock = 1;
+#endif
static inline bool supports_extension(char ext)
{
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index a4433fb..3402d09 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -98,6 +98,7 @@ call_board_init_f_0:
mv sp, a0
#endif
+#ifndef CONFIG_XIP
/*
* Pick hart to initialize global data and run U-Boot. The other harts
* wait for initialization to complete.
@@ -106,6 +107,9 @@ call_board_init_f_0:
li s2, 1
amoswap.w s2, t1, 0(t0)
bnezs2, wait_for_gd_init
+#else
+ bneztp, secondary_hart_loop
+#endif
la t0, prior_stage_fdt_address
SREGs1, 0(t0)
@@ -115,6 +119,7 @@ call_board_init_f_0:
/* save the boot hart id to global_data */
SREGtp, GD_BOOT_HART(gp)
+#ifndef CONFIG_XIP
la t0, available_harts_lock
fence rw, w
amoswap.w zero, zero, 0(t0)
@@ -141,6 +146,7 @@ wait_for_gd_init:
* secondary_hart_loop.
*/
bnezs2, secondary_hart_loop
+#endif
/* Enable cache */
jal icache_enable
diff --git a/arch/riscv/include/asm/global_data.h
b/arch/riscv/include/asm/global_data.h
index dffcd45..b74bd7e 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -27,7 +27,9 @@ struct arch_global_data {
#ifdef CONFIG_SMP
struct ipi_data ipi[CONFIG_NR_CPUS];
#endif
+#ifndef CONFIG_XIP
ulong available_harts;
+#endif
};
#include
diff --git a/arch/riscv/lib/asm-offsets.c b/arch/riscv/lib/asm-offsets.c
index f998402..4fa4fd3 100644
--- a/arch/riscv/lib/asm-offsets.c
+++ b/arch/riscv/lib/asm-offsets.c
@@ -14,7 +14,9 @@
int main(void)
{
DEFINE(GD_BOOT_HART, offsetof(gd_t, arch.boot_hart));
+#ifndef CONFIG_XIP
DEFINE(GD_AVAILABLE_HARTS, offsetof(gd_t, arch.available_harts));
+#endif
return 0;
}
diff --git a/arch/riscv/lib/smp.c b/arch/riscv/lib/smp.c
index caa292c..cc66f15 100644
--- a/arch/riscv/lib/smp.c
+++ b/arch/riscv/lib/smp.c
@@ -63,9 +63,11 @@ static int send_ipi_many(struct ipi_data *ipi)
continue;
}
+#ifndef CONFIG_XIP
/* skip if hart is not available */
if (!(gd->arch.available_harts & (1 << reg)))
continue;
+#endif
gd->arch.ipi[reg].addr = ipi->addr;
gd->arch.ipi[reg].arg0 = ipi->arg0;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 0/5] AE350 support SMP boot from flash
From: Rick Chen In current RISC-V SMP flow, AE350 will encounter the the write failure problem since hart_lottery and available_harts_lock was not in ram address but in flash address when booing from flash. This patch can help to fix the failure problem when AE350 was booting from flash by disabling this two features. Changes in v4: - Use CONFIG_OF_SEPARATE instead of CONFIG_OF_BOARD in ae350_rv32_xip_defconfig and ae350_rv64_xip_defconfig. - Remove prior_stage_fdt_address in board_fdt_blob_setup. - Modify CONFIG_SYS_FDT_BASE as flash address. Changes in v3: - Modify CONFIG_XIP descriptions - Use #ifdef CONFIG_OF_PRIOR_STAGE to replace # if CONFIG_IS_ENABLED(OF_PRIOR_STAGE) - Recovery some blank lines - Add CONFIG_SF_DEFAULT_MODE=0x0 in ae350_rv32_xip_defconfig and ae350_rv64_xip_defconfig - #ifdef CONFIG_OF_PRIOR_STAGE shall also surround SREG s1, 0(t0) - Modify CONFIG_SYS_FDT_BASE from 0x000f as 0x800f in ax25-ae350.h Changes in v2: - Fix some typos - Also surround the declaration of prior_stage_fdt_address in arch/riscv/cpu/cpu.c with OF_PRIOR_STAGE - Use CONFIP_XIP to replace CONFIG_HART_LOTTERY and CONFIG_AVAILABLE_HARTS Rick Chen (5): riscv: Introduce CONFIG_XIP to support booting from flash riscv: configs: Support AE350 SMP booting from flash flow riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled riscv: configs: AE350 will use CONFIG_OF_PRIOR_STAGE when boots from ram riscv: configs: ae350 will use CONFIG_OF_SEPARATE when boots from flash arch/riscv/Kconfig | 7 ++ arch/riscv/cpu/cpu.c| 4 arch/riscv/cpu/start.S | 8 +++ arch/riscv/include/asm/global_data.h| 2 ++ arch/riscv/lib/asm-offsets.c| 2 ++ arch/riscv/lib/smp.c| 2 ++ board/AndesTech/ax25-ae350/ax25-ae350.c | 4 configs/ae350_rv32_defconfig| 2 +- configs/ae350_rv32_xip_defconfig| 37 configs/ae350_rv64_defconfig| 2 +- configs/ae350_rv64_xip_defconfig| 38 + include/configs/ax25-ae350.h| 2 +- 12 files changed, 103 insertions(+), 7 deletions(-) create mode 100644 configs/ae350_rv32_xip_defconfig create mode 100644 configs/ae350_rv64_xip_defconfig -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: memory leak in append value
When printing an UEFI variable an error may arise while converting an
illegal hexadecimal value. In this case a buffer is leaked.
Close the memory leak. Provide an error message.
Reported-by: Coverity (CID 185830)
Signed-off-by: Heinrich Schuchardt
---
cmd/nvedit_efi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/cmd/nvedit_efi.c b/cmd/nvedit_efi.c
index e65b38dbf3..2805e8182b 100644
--- a/cmd/nvedit_efi.c
+++ b/cmd/nvedit_efi.c
@@ -291,8 +291,11 @@ static int append_value(char **bufp, size_t *sizep, char
*data)
if (!tmp_buf)
return -1;
- if (hex2bin((u8 *)tmp_buf, data, len) < 0)
+ if (hex2bin((u8 *)tmp_buf, data, len) < 0) {
+ printf("Error: illegal hexadecimal string\n");
+ free(tmp_buf);
return -1;
+ }
value = tmp_buf;
} else { /* string */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Read a volume from a UBI image in RAM
Hello selvamuthukumar v, Am 29.04.2019 um 20:33 schrieb selvamuthukumar v: Hi I've a UBI image having two volumes, kernel and rootfs. I can tftp the UBI image to RAM and then write to NAND. I want to validate the kernel (checksum and signature) before writing the UBI image to flash. Is there a command available to read a volume from a UBI image that is in RAM? No. 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
Re: [U-Boot] [PATCH 6/6] ubispl: introduce separate CONFIG_UBI_SPL_SILENCE_MSG
Hello Markus,
Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher:
From: Markus Klotzbuecher
This allows to silence ubi and ubispl individually.
Signed-off-by: Markus Klotzbuecher
Cc: Heiko Schocher
Cc: Kyungmin Park
---
common/spl/Kconfig | 6 ++
drivers/mtd/ubispl/ubispl.h | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 0e91bd309b..37dce69e81 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -638,6 +638,12 @@ config SPL_UBI_LOAD_ARGS_ID
help
The UBI volume id from which to load the device tree
+config UBI_SPL_SILENCE_MSG
+ bool "silence UBI SPL messages"
+ default n
+ help
+ Disable messages from UBI SPL. This leaves warnings
+ and errors enabled.
endif # if SPL_UBI
diff --git a/drivers/mtd/ubispl/ubispl.h b/drivers/mtd/ubispl/ubispl.h
index bcc376c6d7..b7cb7fc941 100644
--- a/drivers/mtd/ubispl/ubispl.h
+++ b/drivers/mtd/ubispl/ubispl.h
@@ -129,7 +129,7 @@ struct ubi_scan_info {
#define ubi_dbg(fmt, ...)
#endif
-#ifdef CONFIG_UBI_SILENCE_MSG
+#ifdef CONFIG_UBI_SPL_SILENCE_MSG
#define ubi_msg(fmt, ...)
#else
#define ubi_msg(fmt, ...) printf("UBI: " fmt "\n", ##__VA_ARGS__)
Reviewed-by: Heiko Schocher
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
Re: [U-Boot] [PATCH 5/6] ubispl: add support for loading volumes by name
Hello Markus,
Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher:
From: Hamish Guthrie
The motivation is to use the UBI atomic volume rename functionality to
allow double copy software updates on UBI. To that end the SPL is
configured to always load the same volume name (e.g. "u-boot"),
whereas a software updater always installs into the secondary volume
"u-boot_r". After successful installation, these two volume names are
switched.
This extension is protected by #ifdefs as it will somewhat slow down
loading of volumes by id. This is because the code needs to disable
the optimization of ignoring all volume ids which are not
to-be-loaded, since these can only be resolved after attaching.
Signed-off-by: Hamish Guthrie
Signed-off-by: Markus Klotzbuecher
Cc: Heiko Schocher
Cc: Kyungmin Park
---
common/spl/Kconfig | 13 +++
common/spl/spl_ubi.c| 7 ++
drivers/mtd/ubispl/ubispl.c | 215 +++-
drivers/mtd/ubispl/ubispl.h | 7 ++
include/ubispl.h| 6 +
5 files changed, 246 insertions(+), 2 deletions(-)
diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 71bedea638..0e91bd309b 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -556,6 +556,13 @@ config SPL_UBI
README.ubispl for more info.
if SPL_UBI
+config SPL_UBI_LOAD_BY_VOLNAME
+ bool "Support loading volumes by name"
+ help
+ This enables support for loading UBI volumes by name. When this
+ is set, CONFIG_SPL_UBI_LOAD_MONITOR_VOLNAME can be used to
+ configure the volume name from which to load U-Boot.
+
config SPL_UBI_MAX_VOL_LEBS
int "Maximum number of LEBs per volume"
depends on SPL_UBI
@@ -613,6 +620,12 @@ config SPL_UBI_LOAD_MONITOR_ID
help
The UBI volume id from which to load U-Boot
+config SPL_UBI_LOAD_MONITOR_VOLNAME
+ string "volume name of U-Boot volume"
+ depends on SPL_UBI_LOAD_BY_VOLNAME
+ help
+ The UBI volume name from which to load U-Boot
+
config SPL_UBI_LOAD_KERNEL_ID
int "id of kernel volume"
depends on SPL_OS_BOOT && SPL_UBI
diff --git a/common/spl/spl_ubi.c b/common/spl/spl_ubi.c
index 67e5fadd7c..0cb5080882 100644
--- a/common/spl/spl_ubi.c
+++ b/common/spl/spl_ubi.c
@@ -62,7 +62,14 @@ int spl_ubi_load_image(struct spl_image_info *spl_image,
}
#endif
header = spl_get_load_buffer(-sizeof(*header), sizeof(header));
+#ifdef CONFIG_SPL_UBI_LOAD_BY_VOLNAME
+ volumes[0].vol_id = -1;
+ strncpy(volumes[0].name,
+ CONFIG_SPL_UBI_LOAD_MONITOR_VOLNAME,
+ UBI_VOL_NAME_MAX + 1);
+#else
volumes[0].vol_id = CONFIG_SPL_UBI_LOAD_MONITOR_ID;
+#endif
volumes[0].load_addr = (void *)header;
ret = ubispl_load_volumes(, volumes, 1);
diff --git a/drivers/mtd/ubispl/ubispl.c b/drivers/mtd/ubispl/ubispl.c
index eeb1cbefb7..3f3b9b4367 100644
--- a/drivers/mtd/ubispl/ubispl.c
+++ b/drivers/mtd/ubispl/ubispl.c
@@ -45,6 +45,187 @@ static int ubi_io_is_bad(struct ubi_scan_info *ubi, int peb)
return peb >= ubi->peb_count || peb < 0;
}
+#ifdef CONFIG_SPL_UBI_LOAD_BY_VOLNAME
+
+/**
+ * ubi_dump_vtbl_record - dump a ubi_vtbl_record object.
+ * @r: the object to dump
+ * @idx: volume table index
+ */
+void ubi_dump_vtbl_record(const struct ubi_vtbl_record *r, int idx)
+{
+ int name_len = be16_to_cpu(r->name_len);
+
+ ubi_dbg("Volume table record %d dump: size: %d",
+ idx, sizeof(struct ubi_vtbl_record));
+ ubi_dbg("\treserved_pebs %d", be32_to_cpu(r->reserved_pebs));
+ ubi_dbg("\talignment %d", be32_to_cpu(r->alignment));
+ ubi_dbg("\tdata_pad%d", be32_to_cpu(r->data_pad));
+ ubi_dbg("\tvol_type%d", (int)r->vol_type);
+ ubi_dbg("\tupd_marker %d", (int)r->upd_marker);
+ ubi_dbg("\tname_len%d", name_len);
+
+ if (r->name[0] == '\0') {
+ ubi_dbg("\tnameNULL");
+ return;
+ }
+
+ if (name_len <= UBI_VOL_NAME_MAX &&
+ strnlen(>name[0], name_len + 1) == name_len) {
+ ubi_dbg("\tname%s", >name[0]);
+ } else {
+ ubi_dbg("\t1st 5 characters of name: %c%c%c%c%c",
+ r->name[0], r->name[1], r->name[2], r->name[3],
+ r->name[4]);
+ }
+ ubi_dbg("\tcrc %#08x", be32_to_cpu(r->crc));
+}
+
+/* Empty volume table record */
+static struct ubi_vtbl_record empty_vtbl_record;
+
+/**
+ * vtbl_check - check if volume table is not corrupted and sensible.
+ * @ubi: UBI device description object
+ * @vtbl: volume table
+ *
+ * This function returns zero if @vtbl is all right, %1 if CRC is incorrect,
+ * and %-EINVAL if it contains inconsistent data.
+ */
+static int vtbl_check(struct ubi_scan_info *ubi,
+ struct ubi_vtbl_record *vtbl)
+{
+ int i, n, reserved_pebs, alignment,
Re: [U-Boot] [PATCH 4/6] ubispl: migrate configuration to Kconfig
Hello Markus, Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: From: Markus Klotzbuecher Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park Cc: Javier Martinez Canillas Cc: Enric Balletbo i Serra --- common/spl/Kconfig | 79 scripts/config_whitelist.txt | 12 -- 2 files changed, 79 insertions(+), 12 deletions(-) Please move from the config files: ./include/configs/omap3_igep00x0.h ./include/configs/am335x_igep003x.h also the symbols to the defconfig files, thanks. 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
Re: [U-Boot] [PATCH 3/6] ubi: fix UBI_SILENCE_MSG
Hello Markus, Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: From: Markus Klotzbuecher - drop CONFIG_ prefix from kconfig entry - fix small compilation issue with CONFIG_UBI_SILENCE_MSG Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park --- drivers/mtd/ubi/Kconfig | 2 +- drivers/mtd/ubi/io.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) good catch! Reviewed-by: Heiko Schocher 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
Re: [U-Boot] [PATCH 2/6] env: ubi: support configurable VID offset
Hello Markus,
Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher:
From: Hamish Guthrie
Please add a commit message.
Signed-off-by: Hamish Guthrie
Signed-off-by: Markus Klotzbuecher
Cc: Heiko Schocher
Cc: Kyungmin Park
---
env/Kconfig | 6 ++
env/ubi.c | 17 +
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/env/Kconfig b/env/Kconfig
index 44c47220c2..595b658c26 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -519,6 +519,12 @@ config ENV_UBI_VOLUME_REDUND
help
Name of the redundant volume that you want to store the environment
in.
+config ENV_UBI_VID_OFFSET
+ int "ubi environment VID offset"
+ depends on ENV_IS_IN_UBI
+ help
+ UBI VID offset for environment.
+
endif
config USE_DEFAULT_ENV_FILE
diff --git a/env/ubi.c b/env/ubi.c
index 1dfdf0a8c8..67379f2557 100644
--- a/env/ubi.c
+++ b/env/ubi.c
@@ -15,6 +15,15 @@
#include
#undef crc32
+#define _QUOTE(x) #x
+#define QUOTE(x) _QUOTE(x)
+
+#ifdef CONFIG_ENV_UBI_VID_OFFSET
+ #define UBI_VID_OFFSET QUOTE(CONFIG_ENV_UBI_VID_OFFSET)
+#else
+ #define UBI_VID_OFFSET NULL
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_CMD_SAVEENV
@@ -28,7 +37,7 @@ static int env_ubi_save(void)
if (ret)
return ret;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
return 1;
@@ -70,7 +79,7 @@ static int env_ubi_save(void)
if (ret)
return ret;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
return 1;
@@ -111,7 +120,7 @@ static int env_ubi_load(void)
tmp_env1 = (env_t *)env1_buf;
tmp_env2 = (env_t *)env2_buf;
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
set_default_env(NULL, 0);
@@ -148,7 +157,7 @@ static int env_ubi_load(void)
*/
memset(buf, 0x0, CONFIG_ENV_SIZE);
- if (ubi_part(CONFIG_ENV_UBI_PART, NULL)) {
+ if (ubi_part(CONFIG_ENV_UBI_PART, UBI_VID_OFFSET)) {
printf("\n** Cannot find mtd partition \"%s\"\n",
CONFIG_ENV_UBI_PART);
set_default_env(NULL, 0);
Reviewed-by: Heiko Schocher
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
Re: [U-Boot] [PATCH u-boot-marvell v2 05/15] arm: mvebu: turris_omnia: move I2C dependencies to Kconfig
Hello Marek, Am 30.04.2019 um 03:48 schrieb Marek Behún: The I2C dependencies are defined in include/configs/turris_omnia.h, because Turris Omnia won't boot correctly without I2C support. Move these dependencies to Kconfig, so that they are selected if Turris Omnia is selected as target. Signed-off-by: Marek Behún --- arch/arm/mach-mvebu/Kconfig| 5 + include/configs/turris_omnia.h | 11 --- 2 files changed, 5 insertions(+), 11 deletions(-) Reviewed-by: Heiko Schocher 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
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Markus, Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: From: Markus Klotzbuecher please add a commit message. Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park --- env/Kconfig | 6 ++ scripts/config_whitelist.txt | 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index 78300660c7..44c47220c2 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME help Name of the volume that you want to store the environment in. +config ENV_UBI_VOLUME_REDUND + string "UBI redundant volume name" + depends on ENV_IS_IN_UBI + help + Name of the redundant volume that you want to store the environment in. + endif config USE_DEFAULT_ENV_FILE diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index fa98efc24c..5d76c781d3 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK CONFIG_ENV_TOTAL_SIZE CONFIG_ENV_UBIFS_OPTION CONFIG_ENV_UBI_MTD -CONFIG_ENV_UBI_VOLUME_REDUND CONFIG_ENV_VERSION CONFIG_EP9302 CONFIG_EP9307 Please move from the config files: ./include/configs/omap3_igep00x0.h ./include/configs/gardena-smart-gateway-at91sam.h ./include/configs/am335x_igep003x.h also the symbols to the defconfig files, thanks. BTW: you can use the tool tools/moveconfig.py in u-boot source for this purpose. Beside of this, you can add my: Reviewed-by: Heiko Schocher 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
Re: [U-Boot] [PATCH 1/5] mtd: spi-nor: fix page program issue when using spi-mem driver
Hi,
+Jagan
On 26/04/19 2:52 PM, Weijie Gao wrote:
> Some SPI controllers can't write nor->page_size bytes in a single step
> because their TX FIFO is too small, but when that happens we should
> make sure a WRITE_EN command before each write access and READ_SR command
> after each write access is issued.
>
> We should allow nor->write() to return a size that is smaller than the
> requested write size to gracefully handle this case.
>
> Also, the spi_nor_write_data() should return the actual number of bytes
> that were written during the spi_mem_exec_op() operation.
>
> This patch is a combination of two commits backported from kernel:
>
> commit 630d6bd8a3b4 ("mtd: spi-nor: Support controllers with limit ...")
> commit 3baa8ec88c2f ("mtd: devices: m25p80: Make sure WRITE_EN is ...")
>
> Cc: Vignesh R
> Signed-off-by: Weijie Gao
Thanks for the patch.
Acked-by: Vignesh R
Jagan
This patch fixes a regression wrt writing to flash on two platforms.
Could you consider queuing this patch for next -rc?
Regards
Vignesh
> ---
> drivers/mtd/spi/spi-nor-core.c | 27 ---
> 1 file changed, 8 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index c4e2f6a..1acff74 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -116,7 +116,6 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor,
> loff_t to, size_t len,
> SPI_MEM_OP_ADDR(nor->addr_width, to, 1),
> SPI_MEM_OP_NO_DUMMY,
> SPI_MEM_OP_DATA_OUT(len, buf, 1));
> - size_t remaining = len;
> int ret;
>
> /* get transfer protocols. */
> @@ -127,22 +126,16 @@ static ssize_t spi_nor_write_data(struct spi_nor *nor,
> loff_t to, size_t len,
> if (nor->program_opcode == SPINOR_OP_AAI_WP && nor->sst_write_second)
> op.addr.nbytes = 0;
>
> - while (remaining) {
> - op.data.nbytes = remaining < UINT_MAX ? remaining : UINT_MAX;
> - ret = spi_mem_adjust_op_size(nor->spi, );
> - if (ret)
> - return ret;
> -
> - ret = spi_mem_exec_op(nor->spi, );
> - if (ret)
> - return ret;
> + ret = spi_mem_adjust_op_size(nor->spi, );
> + if (ret)
> + return ret;
> + op.data.nbytes = len < op.data.nbytes ? len : op.data.nbytes;
>
> - op.addr.val += op.data.nbytes;
> - remaining -= op.data.nbytes;
> - op.data.buf.out += op.data.nbytes;
> - }
> + ret = spi_mem_exec_op(nor->spi, );
> + if (ret)
> + return ret;
>
> - return len;
> + return op.data.nbytes;
> }
>
> /*
> @@ -1101,10 +1094,6 @@ static int spi_nor_write(struct mtd_info *mtd, loff_t
> to, size_t len,
> goto write_err;
> *retlen += written;
> i += written;
> - if (written != page_remain) {
> - ret = -EIO;
> - goto write_err;
> - }
> }
>
> write_err:
>
--
Regards
Vignesh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] i2c: mxc_i2c: Fix read and read->write xfers in DM mode
Hello Trent,
Am 16.04.2019 um 00:02 schrieb Trent Piepho:
This is an old driver that supports both device mapped and non-mapped
mode, and covers a wide range of hardware. It's hard to change without
risking breaking something. I have to tried to be exceedingly detailed
in this patch, so please excuse the length of the commit essay that
follows.
In device mapped mode the I2C xfer function does not handle plain read,
and some other, transfers correctly.
What it can't handle are transactions that:
Start with a read, or,
Have a write followed by a read, or,
Have more than one read in a row.
The common I2C/SMBUS read register and write register transactions
always start with a write, followed by a write or a read, and then end.
These work, so the bug is not apparent for most I2C slaves that only use
these common xfer forms.
The existing xfer loop initializes by sending the chip address in write
mode after it deals with bus arbitration and master setup. When
processing each message, if the next message will be a read, it sends a
repeated start followed by the chip address in read mode after the
current message.
Obviously, this does not work if the first message is a read, as the
chip is always addressed in write mode initially by i2c_init_transfer().
A write following a read does not work because the repeated start is
only sent when the next message is a read. There is no logic to send it
when the current message is a read and next is write. It should be sent
every time the bus changes direction.
The ability to use a plain read was added to this driver in
commit 2feec4eafd40 ("imx: mxc_i2c: tweak the i2c transfer method"),
but this applied only the non-DM code path.
This patch fixes the DM code path. The xfer function will call
i2c_init_transfer() with an alen of -1 to avoid sending the chip
address. The same way the non-DM code achieves this. The xfer
function's message loop will send the address and mode before each
message if the bus changes direction, and on the first message.
When reading data, the master hardware is one byte ahead of what we
receive. I.e., reading a byte from the data register returns a byte
*already received* by the master, and causes the master to start the RX
of the *next* byte. Therefor, before we read the final byte of a
message, we must tell the master what to do next. I add a "last" flag
to i2c_read_data() to tell it if the message is to be followed by a stop
or a repeated start. When last == true it acts exactly as before.
The non-DM code can only create an xfer where the read, if any, is the
final message of the xfer. And so the only callsite of i2c_read_data()
in the non-DM code has the "last" parameter as true. Therefore, this
change has no effect on the non-DM code. As all other changes are in
the DM xfer function, which is not even compiled in non-DM code, I am
confident that this patch has no effect on boards not using I2C_DM.
This greatly reduces the change of hardware that could be affected.
For DM boards, I have verified every transaction the "i2c" command can
create on a scope and they are all exactly as they are supposed to be.
I also tested write->read->write, which isn't possible with the i2c
command, and it works as well. I didn't fix multiple reads in a row, as
it's a lot more invasive and obviously no one has every wanted them
since they've never worked. It didn't seem like the extra complexity
was justified to support something no one uses.
Cc: Nandor Han
Cc: Heiko Schocher
Cc: Stefano Babic
Cc: Fabio Estevam
Cc: Breno Matheus Lima
Signed-off-by: Trent Piepho
---
drivers/i2c/mxc_i2c.c | 95 ++-
1 file changed, 64 insertions(+), 31 deletions(-)
Thanks for this work!
Your patch has
total: 64 errors, 2 warnings, 0 checks, 145 lines checked
Please fix and send a v2.
It would be good to become here some Tested by tags ...
Reviewed-by: Heiko Schocher
bye,
Heiko
diff --git a/drivers/i2c/mxc_i2c.c b/drivers/i2c/mxc_i2c.c
index f17a47f600..23119cce65 100644
--- a/drivers/i2c/mxc_i2c.c
+++ b/drivers/i2c/mxc_i2c.c
@@ -482,8 +482,13 @@ static int i2c_write_data(struct mxc_i2c_bus *i2c_bus, u8
chip, const u8 *buf,
return ret;
}
+/* Will generate a STOP after the last byte if "last" is true, i.e. this is the
+ * final message of a transaction. If not, it switches the bus back to TX mode
+ * and does not send a STOP, leaving the bus in a state where a repeated start
+ * and address can be sent for another message.
+ */
static int i2c_read_data(struct mxc_i2c_bus *i2c_bus, uchar chip, uchar *buf,
-int len)
+int len, bool last)
{
int ret;
unsigned int temp;
@@ -513,17 +518,31 @@ static int i2c_read_data(struct mxc_i2c_bus *i2c_bus,
uchar chip, uchar *buf,
return ret;
}
- /*
-* It must generate STOP before read I2DR to prevent
Re: [U-Boot] [PATCH 1/2] i2c: mxc_i2c: Document how non-DM functions work
Hello Trent, Am 16.04.2019 um 00:02 schrieb Trent Piepho: It is not very clear how these work in relation to the exact I2C xfers they produce. In paticular, the address length is somewhat overloaded in the read method. Clearly document the existing behavior. Maybe this will help the next person who needs to work on this driver and not break non-DM boards. Cc: Nandor Han Cc: Heiko Schocher Cc: Stefano Babic Cc: Fabio Estevam Cc: Breno Matheus Lima Signed-off-by: Trent Piepho --- drivers/i2c/mxc_i2c.c | 34 ++ 1 file changed, 34 insertions(+) Thanks, but your patch has a lot of checkpatch errors: total: 34 errors, 0 warnings, 0 checks, 52 lines checked please fix this and send a v2. Reviewed-by: Heiko Schocher 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
Re: [U-Boot] [PATCH] i2c: mxc: Hide kconfig based control in DM_I2C mode
Hello Trent, Am 12.04.2019 um 21:19 schrieb Trent Piepho: These options only apply when not using DM_I2C. When using device trees, the dt will enable and control the speeds of the I2C controller(s) and these configuration options have no effect. So disable them in DM_I2C mode. Otherwise they show up as decoys, and make it look like one is enabling I2C controllers and setting the speed when really it's doing nothing. Cc: Sriram Dash Cc: Priyanka Jain Cc: Heiko Schocher Signed-off-by: Trent Piepho --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Your patch has checkpatch warning: ERROR: DOS line endings #142: FILE: drivers/i2c/Kconfig:164: +if SYS_I2C_MXC && !DM_I2C^M$ Fixed this locally, please check furhter patches. diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index 1ef22e6bcd..df7fc7db0a 100644 --- a/drivers/i2c/Kconfig +++ b/drivers/i2c/Kconfig @@ -161,7 +161,7 @@ config SYS_I2C_MXC channels and operating on standard mode upto 100 kbits/s and fast mode upto 400 kbits/s. -if SYS_I2C_MXC +if SYS_I2C_MXC && !DM_I2C config SYS_I2C_MXC_I2C1 bool "NXP MXC I2C1" help Reviewed-by: Heiko Schocher 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
Re: [U-Boot] [PATCH u-boot-marvell v2 15/15] i2c: mvtwsi: fix reading status register after interrupt
Hello Marek,
Am 30.04.2019 um 03:48 schrieb Marek Behún:
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.
On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.
My theory is that the controller does approximately this:
1. sets interrupt flag in control register,
2. sets the value of status register,
3. causes an interrupt
In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.
The bug does not appear if I add a small delay before reading status
register.
Strange.
Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.
Signed-off-by: Marek Behún
Cc: Mario Six
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heiko Schocher
---
drivers/i2c/mvtwsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 74ac0a4aa7..483a71ba12 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -271,6 +271,7 @@ static int twsi_wait(struct mvtwsi_registers *twsi, int
expected_status,
do {
control = readl(>control);
if (control & MVTWSI_CONTROL_IFLG) {
+ ndelay(100);
status = readl(>status);
if (status == expected_status)
return 0;
Can you please add a comment in the code too?
Beside of that:
Acked-by: Heiko Schocher
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
Re: [U-Boot] [PATCH u-boot-marvell v2 01/15] arm: mvebu: turris_omnia: remove redundant code
Hello Marek, Am 30.04.2019 um 03:48 schrieb Marek Behún: The i2c slave disabling is done by mvtwsi driver and is not needed here. Signed-off-by: Marek Behún --- board/CZ.NIC/turris_omnia/turris_omnia.c | 13 - 1 file changed, 13 deletions(-) Acked-by: Heiko Schocher 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
Re: [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
Hello Marek, Am 30.04.2019 um 03:49 schrieb Marek Behun: I would really like not to see such board specific code added to this driver. Frankly, I fail to understand why used udelay(11) instead of udelay(10) should result in such a difference on your board. Could you please investigate a bit more and hopefully come up with a "better" solution for this issue? Thanks, Stefan Hi Stefan, I think I found what was the issue, just sent a patch series for Omnia, the last patch explains my theory and fixes the issue with one ndelay(100) You mean tha patch series "[U-Boot] [PATCH u-boot-marvell v2 00/15] Fixes for Turris Omnia" So we can ignore this patch? 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
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
Julius Werner schrieb am Di., 30. Apr. 2019, 02:38: > > However, compared to my above mentioned RFC patch, this here somehow > > fails when loading something from the image, e.g. using the cmd 'fpga > > loadmk'. Seems like this one doesn't transparently uncompress? > > It looks to me like do_fpga_loadmk() doesn't actually call > fit_load_image()? It calls fit_image_get_data() directly, so it > bypasses the code I'm adding. Maybe it should be using > fit_load_image() instead, but that's moving pretty far away from what > I was trying to do... it could be left for a later patch? > Ah, ok. I wasn't aware I had changed that command too :-) let me concentrate on finding out why booting the compressed fit,image doesn't work, then. Regards, Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: dts: k3-am654: Sync IOPAD macros with Linux
On 29/04/19 11:26 PM, Andreas Dannenberg wrote: > Transition to the IOPAD macros as used in Linux in which the pin mux > mode is specified using a dedicated parameter while also dropping the > related MUX_MODEx macros that are no longer needed. This transition > will allow us to keep both Linux and U-Boot DTS in sync more easily. > While at it also align the file name of the include file itself and > update any references accordingly. > > Signed-off-by: Andreas Dannenberg Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH,RESEND] mips: rename mach-mt7620 to mach-mtmips
Currently mach-mt7620 contains only support for mt7628. To avoid confusion,
rename mach-mt7620 to mach-mtmips, which means MediaTek MIPS platforms.
MT7620 and MT7628 should be distinguished by SOC_MT7620 and SOC_MT7628
because they do not share the same lowlevel codes.
Dependencies of four drivers are changed to SOC_MT7628 as these drivers
are only used by MT7628.
Cc: Daniel Schwierzeck
Reviewed-by: Stefan Roese
Signed-off-by: Weijie Gao
---
arch/mips/Kconfig | 6 +++---
arch/mips/Makefile | 2 +-
arch/mips/dts/Makefile | 2 +-
arch/mips/{mach-mt7620 => mach-mtmips}/Kconfig | 14 +++---
arch/mips/{mach-mt7620 => mach-mtmips}/Makefile| 0
arch/mips/{mach-mt7620 => mach-mtmips}/cpu.c | 0
.../{mach-mt7620 => mach-mtmips}/ddr_calibrate.c | 0
.../{mach-mt7620 => mach-mtmips}/lowlevel_init.S | 0
arch/mips/{mach-mt7620 => mach-mtmips}/mt76xx.h| 0
configs/gardena-smart-gateway-mt7688-ram_defconfig | 2 +-
configs/gardena-smart-gateway-mt7688_defconfig | 2 +-
configs/linkit-smart-7688-ram_defconfig| 2 +-
configs/linkit-smart-7688_defconfig| 2 +-
drivers/gpio/Kconfig | 2 +-
drivers/net/Kconfig| 2 +-
drivers/spi/Kconfig| 2 +-
drivers/watchdog/Kconfig | 2 +-
17 files changed, 20 insertions(+), 20 deletions(-)
rename arch/mips/{mach-mt7620 => mach-mtmips}/Kconfig (93%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/Makefile (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/cpu.c (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/ddr_calibrate.c (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/lowlevel_init.S (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/mt76xx.h (100%)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 194f4f349e..9cf8e9800d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -74,8 +74,8 @@ config ARCH_BMIPS
select SYSRESET
imply CMD_DM
-config ARCH_MT7620
- bool "Support MT7620/7688 SoCs"
+config ARCH_MTMIPS
+ bool "Support MediaTek MIPS platforms"
imply CMD_DM
select DISPLAY_CPUINFO
select DM
@@ -153,7 +153,7 @@ source "arch/mips/mach-mscc/Kconfig"
source "arch/mips/mach-bmips/Kconfig"
source "arch/mips/mach-jz47xx/Kconfig"
source "arch/mips/mach-pic32/Kconfig"
-source "arch/mips/mach-mt7620/Kconfig"
+source "arch/mips/mach-mtmips/Kconfig"
if MIPS
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 029d290f1e..af3f227436 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -15,7 +15,7 @@ machine-$(CONFIG_ARCH_ATH79) += ath79
machine-$(CONFIG_ARCH_BMIPS) += bmips
machine-$(CONFIG_ARCH_JZ47XX) += jz47xx
machine-$(CONFIG_MACH_PIC32) += pic32
-machine-$(CONFIG_ARCH_MT7620) += mt7620
+machine-$(CONFIG_ARCH_MTMIPS) += mtmips
machine-$(CONFIG_ARCH_MSCC) += mscc
machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 3522e6cdc8..e2de1da147 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0+
-dtb-$(CONFIG_ARCH_MT7620) += \
+dtb-$(CONFIG_ARCH_MTMIPS) += \
gardena-smart-gateway-mt7688.dtb \
linkit-smart-7688.dtb
dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mtmips/Kconfig
similarity index 93%
rename from arch/mips/mach-mt7620/Kconfig
rename to arch/mips/mach-mtmips/Kconfig
index a983443999..4af2d54528 100644
--- a/arch/mips/mach-mt7620/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -1,20 +1,20 @@
menu "MediaTek MIPS platforms"
- depends on ARCH_MT7620
+ depends on ARCH_MTMIPS
config SYS_MALLOC_F_LEN
default 0x1000
config SYS_SOC
- default "mt7620" if SOC_MT7620
+ default "mt7628" if SOC_MT7628
choice
prompt "MediaTek MIPS SoC select"
-config SOC_MT7620
- bool "MT7620/8"
+config SOC_MT7628
+ bool "MT7628"
select MIPS_L1_CACHE_SHIFT_5
help
- This supports MediaTek MIPS MT7620 family.
+ This supports MediaTek MT7628/MT7688.
endchoice
@@ -23,7 +23,7 @@ choice
config BOARD_GARDENA_SMART_GATEWAY_MT7688
bool "GARDENA smart Gateway"
- depends on SOC_MT7620
+ depends on SOC_MT7628
select BOARD_LATE_INIT
select SUPPORTS_BOOT_RAM
help
@@ -32,7 +32,7 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
config BOARD_LINKIT_SMART_7688
bool "LinkIt Smart 7688"
- depends on SOC_MT7620
+ depends on SOC_MT7628
select SUPPORTS_BOOT_RAM
help
Seeed LinkIt Smart 7688 boards have a MT7688 SoC with 128 MiB of RAM
diff --git a/arch/mips/mach-mt7620/Makefile b/arch/mips/mach-mtmips/Makefile
similarity index 100%
rename from
[U-Boot] [PATCH,v2] mips: rename mach-mt7620 to mach-mtmips
Currently mach-mt7620 contains only support for mt7628. To avoid confusion,
rename mach-mt7620 to mach-mtmips, which means MediaTek MIPS platforms.
MT7620 and MT7628 should be distinguished by SOC_MT7620 and SOC_MT7628
because they do not share the same lowlevel codes.
Dependencies of four drivers are changed to SOC_MT7628 as these drivers
are only used by MT7628.
Reviewed-by: Stefan Roese
Signed-off-by: Weijie Gao
---
Changes since v1: rename mach-mt7628 to mach-mtmips
---
arch/mips/Kconfig | 6 +++---
arch/mips/Makefile | 2 +-
arch/mips/dts/Makefile | 2 +-
arch/mips/{mach-mt7620 => mach-mtmips}/Kconfig | 14 +++---
arch/mips/{mach-mt7620 => mach-mtmips}/Makefile| 0
arch/mips/{mach-mt7620 => mach-mtmips}/cpu.c | 0
.../{mach-mt7620 => mach-mtmips}/ddr_calibrate.c | 0
.../{mach-mt7620 => mach-mtmips}/lowlevel_init.S | 0
arch/mips/{mach-mt7620 => mach-mtmips}/mt76xx.h| 0
configs/gardena-smart-gateway-mt7688-ram_defconfig | 2 +-
configs/gardena-smart-gateway-mt7688_defconfig | 2 +-
configs/linkit-smart-7688-ram_defconfig| 2 +-
configs/linkit-smart-7688_defconfig| 2 +-
drivers/gpio/Kconfig | 2 +-
drivers/net/Kconfig| 2 +-
drivers/spi/Kconfig| 2 +-
drivers/watchdog/Kconfig | 2 +-
17 files changed, 20 insertions(+), 20 deletions(-)
rename arch/mips/{mach-mt7620 => mach-mtmips}/Kconfig (93%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/Makefile (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/cpu.c (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/ddr_calibrate.c (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/lowlevel_init.S (100%)
rename arch/mips/{mach-mt7620 => mach-mtmips}/mt76xx.h (100%)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 194f4f349e..9cf8e9800d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -74,8 +74,8 @@ config ARCH_BMIPS
select SYSRESET
imply CMD_DM
-config ARCH_MT7620
- bool "Support MT7620/7688 SoCs"
+config ARCH_MTMIPS
+ bool "Support MediaTek MIPS platforms"
imply CMD_DM
select DISPLAY_CPUINFO
select DM
@@ -153,7 +153,7 @@ source "arch/mips/mach-mscc/Kconfig"
source "arch/mips/mach-bmips/Kconfig"
source "arch/mips/mach-jz47xx/Kconfig"
source "arch/mips/mach-pic32/Kconfig"
-source "arch/mips/mach-mt7620/Kconfig"
+source "arch/mips/mach-mtmips/Kconfig"
if MIPS
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 029d290f1e..af3f227436 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -15,7 +15,7 @@ machine-$(CONFIG_ARCH_ATH79) += ath79
machine-$(CONFIG_ARCH_BMIPS) += bmips
machine-$(CONFIG_ARCH_JZ47XX) += jz47xx
machine-$(CONFIG_MACH_PIC32) += pic32
-machine-$(CONFIG_ARCH_MT7620) += mt7620
+machine-$(CONFIG_ARCH_MTMIPS) += mtmips
machine-$(CONFIG_ARCH_MSCC) += mscc
machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y))
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 3522e6cdc8..e2de1da147 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0+
-dtb-$(CONFIG_ARCH_MT7620) += \
+dtb-$(CONFIG_ARCH_MTMIPS) += \
gardena-smart-gateway-mt7688.dtb \
linkit-smart-7688.dtb
dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mtmips/Kconfig
similarity index 93%
rename from arch/mips/mach-mt7620/Kconfig
rename to arch/mips/mach-mtmips/Kconfig
index a983443999..4af2d54528 100644
--- a/arch/mips/mach-mt7620/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -1,20 +1,20 @@
menu "MediaTek MIPS platforms"
- depends on ARCH_MT7620
+ depends on ARCH_MTMIPS
config SYS_MALLOC_F_LEN
default 0x1000
config SYS_SOC
- default "mt7620" if SOC_MT7620
+ default "mt7628" if SOC_MT7628
choice
prompt "MediaTek MIPS SoC select"
-config SOC_MT7620
- bool "MT7620/8"
+config SOC_MT7628
+ bool "MT7628"
select MIPS_L1_CACHE_SHIFT_5
help
- This supports MediaTek MIPS MT7620 family.
+ This supports MediaTek MT7628/MT7688.
endchoice
@@ -23,7 +23,7 @@ choice
config BOARD_GARDENA_SMART_GATEWAY_MT7688
bool "GARDENA smart Gateway"
- depends on SOC_MT7620
+ depends on SOC_MT7628
select BOARD_LATE_INIT
select SUPPORTS_BOOT_RAM
help
@@ -32,7 +32,7 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
config BOARD_LINKIT_SMART_7688
bool "LinkIt Smart 7688"
- depends on SOC_MT7620
+ depends on SOC_MT7628
select SUPPORTS_BOOT_RAM
help
Seeed LinkIt Smart 7688 boards have a MT7688 SoC with 128 MiB of RAM
diff --git a/arch/mips/mach-mt7620/Makefile b/arch/mips/mach-mtmips/Makefile
Re: [U-Boot] [PATCH] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
Superseded by https://patchwork.ozlabs.org/patch/1092945/
("[U-Boot,4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y")
--
Best Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/4] cmd: gpt: fix and tidy up help message
Apply the following changes:
- Guard the 'gpt read' command by 'ifdef CONFIG_CMD_GPT_RENAME',
since 'gpt read' is not available on CMD_GPT_RENAME=n
- Prefix the {read,swap,rename} commands with one space for consistency
- Prefix the 'guid' commands with 'gpt' for consistency
Signed-off-by: Eugeniu Rosca
---
cmd/gpt.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/cmd/gpt.c b/cmd/gpt.c
index 638870352f40..33cda513969f 100644
--- a/cmd/gpt.c
+++ b/cmd/gpt.c
@@ -876,21 +876,21 @@ U_BOOT_CMD(gpt, CONFIG_SYS_MAXARGS, 1, do_gpt,
" Example usage:\n"
" gpt write mmc 0 $partitions\n"
" gpt verify mmc 0 $partitions\n"
- " read \n"
- "- read GPT into a data structure for manipulation\n"
- " guid \n"
+ " gpt guid \n"
"- print disk GUID\n"
- " guid \n"
+ " gpt guid \n"
"- set environment variable to disk GUID\n"
" Example usage:\n"
" gpt guid mmc 0\n"
" gpt guid mmc 0 varname\n"
#ifdef CONFIG_CMD_GPT_RENAME
"gpt partition renaming commands:\n"
- "gpt swap\n"
+ " gpt read \n"
+ "- read GPT into a data structure for manipulation\n"
+ " gpt swap\n"
"- change all partitions named name1 to name2\n"
" and vice-versa\n"
- "gpt rename\n"
+ " gpt rename\n"
"- rename the specified partition\n"
" Example usage:\n"
" gpt swap mmc 0 foo bar\n"
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
platform are always the same. Below is consistent on each cold boot:
=> ### interrupt autoboot
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
=> env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
...
uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7
While the uuids do change on every 'gpt write' command, the values
appear to be taken from the same pool, in the same order.
As a user, I expect a trully random uuid value in the above example.
Otherwise, system/RFS designers and OS people might assume they have
a reliable/consistent uuid passed by the bootloader, while the truth
is U-Boot simply lacks entropy to generate a random string.
In its first attempt [1] to improve the uuid randomness, this patch
updated the seed based on the output of get_timer(), similar to [2].
There are two problems with this approach:
- get_timer() has a poor _ms_ resolution
- when gen_rand_uuid() is called in a loop, get_timer() returns the
same result, leading to the same seed being passed to srand(),
leading to the same uuid being generated for several partitions
with different names
This second patch addresses both drawbacks.
My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions'
in a loop for several minutes collecting 8844 randomly generated UUIDS.
Two consecutive cold boots are concatenated in the log. As a result,
all uuid values are unique (scripted check).
Thanks to Roman, who reported the issue and provided support in fixing.
[1] https://patchwork.ozlabs.org/patch/1091802/
[2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function")
[3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
=> while true; do \
env default -a; \
gpt write mmc 1 $partitions; \
print; done
Reported-by: Roman Stratiienko
Signed-off-by: Eugeniu Rosca
---
v2:
- Replaced get_timer(0) with get_ticks() and added rand() to seed value
- Performed extensive testing on R-Car3 (ARMv8)
v1:
- https://patchwork.ozlabs.org/patch/1091802/
---
lib/uuid.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/uuid.c b/lib/uuid.c
index fa20ee39fc32..2d4d6ef7e461 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin)
unsigned int *ptr = (unsigned int *)
int i;
+ srand(get_ticks() + rand());
+
/* Set all fields randomly */
for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++)
*(ptr + i) = cpu_to_be32(rand());
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/4] disk: efi: Fix memory leak on 'gpt verify'
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:
=> ### interrupt autoboot
=> gpt verify mmc 1
No partition list provided - only basic check
Verify GPT: success!
=> ### keep calling 'gpt verify mmc 1'
=> ### on 58th call, we are out of memory:
=> gpt verify mmc 1
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
Verify GPT: error!
This is caused by calling is_gpt_valid() twice (hence allocating pte
also twice via alloc_read_gpt_entries()) while freeing pte only _once_
in the caller of gpt_verify_headers(). Fix that by freeing the pte
allocated and populated for primary GPT _before_ allocating and
populating the pte for backup GPT. The latter will be freed by the
caller of gpt_verify_headers().
With the fix applied, the reproduction scenario [1-2] has been run
hundreds of times in a loop w/o running into OOM.
[1] gpt verify mmc 1
[2] gpt verify mmc 1 $partitions
Fixes: cef68bf9042dda ("gpt: part: Definition and declaration of GPT
verification functions")
Signed-off-by: Eugeniu Rosca
---
disk/part_efi.c | 4
1 file changed, 4 insertions(+)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 812d14cdd871..c0fa753339c8 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -698,6 +698,10 @@ int gpt_verify_headers(struct blk_desc *dev_desc,
gpt_header *gpt_head,
__func__);
return -1;
}
+
+ /* Free pte before allocating again */
+ free(*gpt_pte);
+
if (is_gpt_valid(dev_desc, (dev_desc->lba - 1),
gpt_head, gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid Backup GPT ***\n",
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/4] disk: efi: Fix memory leak on 'gpt guid'
Below is what happens on R-Car H3ULCB-KF using clean U-Boot
v2019.04-00810-g6aebc0d11a10 and r8a7795_ulcb_defconfig:
=> ### interrupt autoboot
=> gpt guid mmc 1
21200400-0804-0146-9dcc-a8c51255994f
success!
=> ### keep calling 'gpt guid mmc 1'
=> ### on 59th call, we are out of memory:
=> gpt guid mmc 1
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
get_disk_guid: *** ERROR: Invalid GPT ***
alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
GPT: Failed to allocate memory for PTE
get_disk_guid: *** ERROR: Invalid Backup GPT ***
error!
After some inspection, it looks like get_disk_guid(), added via v2017.09
commit 73d6d18b7147c9 ("GPT: add accessor function for disk GUID"),
unlike other callers of is_gpt_valid(), doesn't free the memory pointed
out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
via alloc_read_gpt_entries().
With the fix applied, the reproduction scenario has been run hundreds
of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.
Fixes: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
Signed-off-by: Eugeniu Rosca
---
disk/part_efi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 239455b8161e..812d14cdd871 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -209,6 +209,8 @@ int get_disk_guid(struct blk_desc * dev_desc, char *guid)
guid_bin = gpt_head->disk_guid.b;
uuid_bin_to_str(guid_bin, guid, UUID_STR_FORMAT_GUID);
+ /* Remember to free pte */
+ free(gpt_pte);
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/4] Misc EFI/GPT/UUID fixes
This is a collection of fixes addressing issues on R-Car H3ULCB-KF.
All have been tested on H3ULCB-KF and boot-tested on sandbox.
Below v1 patch is superseded by this series:
- https://patchwork.ozlabs.org/patch/1091802/
("lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y")
Eugeniu Rosca (4):
disk: efi: Fix memory leak on 'gpt guid'
disk: efi: Fix memory leak on 'gpt verify'
cmd: gpt: fix and tidy up help message
lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y
cmd/gpt.c | 12 ++--
disk/part_efi.c | 6 ++
lib/uuid.c | 2 ++
3 files changed, 14 insertions(+), 6 deletions(-)
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2019.07-rc1 released
Hey all, It's release day, and here is v2019.07-rc1. There's a few things that I still want to see come in, from my own queue, and I know there's also a few PRs to be made still too. So I expect this week to still be relatively busy. But after that, things should settle down. In terms of a changelog, git log --merges v2019.04..v2019.07-rc1 looks pretty good but the content there varies based on what was given to me in the PR. So please, the more details in the request the better! I'm also going to note here that we now also have both "u-boot-custodians" and "u-boot-maintainers" lists for custodians and board maintainers. These are low volume and intended to make it easier to get ahold of maintainers so that things like DM conversions and so forth aren't a surprise, in the future. I'm planning on doing -rc2 on the 13th and -rc3 on the 27th of May with -rc4 on June 10th and -rc5 on June 24th with the release scheduled on July 8th. Thanks all! -- 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] [PATCHv3] configs: move CONFIG_SPL_TEXT_BASE to Kconfig
On Mon, Apr 29, 2019 at 09:36:33PM -0400, Tom Rini wrote: > From: Simon Goldschmidt > > Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig and migrate existing > values. > > Signed-off-by: Simon Goldschmidt > [trini: Re-run migration] > 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] [PATCH u-boot-marvell v2 09/15] arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig
This driver is required for Turris Omnia to read ethernet addresses.
Move the dependency from turris_omnia_defconfig to Kconfig.
Signed-off-by: Marek Behún
---
arch/arm/mach-mvebu/Kconfig | 1 +
board/CZ.NIC/turris_omnia/turris_omnia.c | 11 ---
configs/turris_omnia_defconfig | 1 -
3 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 2bf829d10a..fc29c3b084 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -121,6 +121,7 @@ config TARGET_TURRIS_OMNIA
select I2C_MUX_PCA954x
select SPL_I2C_MUX
select SYS_I2C_MVTWSI
+ select ATSHA204A
config TARGET_TURRIS_MOX
bool "Support Turris Mox"
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index d4fb89f15f..640ee2a2a3 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -18,10 +18,7 @@
#include
#include
#include
-
-#ifdef CONFIG_ATSHA204A
# include
-#endif
#ifdef CONFIG_WDT_ORION
# include
@@ -388,7 +385,6 @@ int board_late_init(void)
return 0;
}
-#ifdef CONFIG_ATSHA204A
static struct udevice *get_atsha204a_dev(void)
{
static struct udevice *dev;
@@ -403,14 +399,12 @@ static struct udevice *get_atsha204a_dev(void)
return dev;
}
-#endif
int checkboard(void)
{
u32 version_num, serial_num;
int err = 1;
-#ifdef CONFIG_ATSHA204A
struct udevice *dev = get_atsha204a_dev();
if (dev) {
@@ -434,8 +428,6 @@ int checkboard(void)
}
out:
-#endif
-
if (err)
printf("Board: Turris Omnia (ver N/A). SN: N/A\n");
else
@@ -458,7 +450,6 @@ static void increment_mac(u8 *mac)
int misc_init_r(void)
{
-#ifdef CONFIG_ATSHA204A
int err;
struct udevice *dev = get_atsha204a_dev();
u8 mac0[4], mac1[4], mac[6];
@@ -503,8 +494,6 @@ int misc_init_r(void)
eth_env_set_enetaddr("eth2addr", mac);
out:
-#endif
-
return 0;
}
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index 5086da13a5..5a09dc3033 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -47,7 +47,6 @@ CONFIG_AHCI_MVEBU=y
CONFIG_SATA=y
CONFIG_SCSI=y
CONFIG_SCSI_AHCI=y
-CONFIG_ATSHA204A=y
CONFIG_DM_MMC=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_MV=y
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 07/15] arm: mvebu: turris_omnia: refactor I2C accessing code
Refactor code which accesses the microcontroller and EEPROM via I2C.
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 205 ---
1 file changed, 109 insertions(+), 96 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 055ebad000..6b8fa53c98 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -32,18 +32,25 @@
DECLARE_GLOBAL_DATA_PTR;
-#define OMNIA_I2C_EEPROM_DM_NAME "i2c@11000->i2cmux@70->i2c@0"
-#define OMNIA_I2C_EEPROM 0x54
-#define OMNIA_I2C_EEPROM_CONFIG_ADDR 0x0
-#define OMNIA_I2C_EEPROM_ADDRLEN 2
+#define OMNIA_I2C_BUS_NAME "i2c@11000->i2cmux@70->i2c@0"
+
+#define OMNIA_I2C_MCU_CHIP_ADDR0x2a
+#define OMNIA_I2C_MCU_CHIP_LEN 1
+
+#define OMNIA_I2C_EEPROM_CHIP_ADDR 0x54
+#define OMNIA_I2C_EEPROM_CHIP_LEN 2
#define OMNIA_I2C_EEPROM_MAGIC 0x0341a034
-#define OMNIA_I2C_MCU_DM_NAME "i2c@11000->i2cmux@70->i2c@0"
-#define OMNIA_I2C_MCU_ADDR_STATUS 0x1
-#define OMNIA_I2C_MCU_SATA 0x20
-#define OMNIA_I2C_MCU_CARDDET 0x10
-#define OMNIA_I2C_MCU 0x2a
-#define OMNIA_I2C_MCU_WDT_ADDR 0x0b
+enum mcu_commands {
+ CMD_GET_STATUS_WORD = 0x01,
+ CMD_GET_RESET = 0x09,
+ CMD_WATCHDOG_STATE = 0x0b,
+};
+
+enum status_word_bits {
+ CARD_DET_STSBIT = 0x0010,
+ MSATA_IND_STSBIT= 0x0020,
+};
#define OMNIA_ATSHA204_OTP_VERSION 0
#define OMNIA_ATSHA204_OTP_SERIAL 1
@@ -85,48 +92,97 @@ static struct serdes_map board_serdes_map_sata[] = {
{SGMII2, SERDES_SPEED_1_25_GBPS, SERDES_DEFAULT_MODE, 0, 0}
};
-static bool omnia_detect_sata(void)
+static struct udevice *omnia_get_i2c_chip(const char *name, uint addr,
+ uint offset_len)
{
struct udevice *bus, *dev;
- int ret, retry = 3;
- u16 mode;
-
- puts("SERDES0 card detect: ");
+ int ret;
- if (uclass_get_device_by_name(UCLASS_I2C, OMNIA_I2C_MCU_DM_NAME, ))
{
- puts("Cannot find MCU bus!\n");
- return false;
+ ret = uclass_get_device_by_name(UCLASS_I2C, OMNIA_I2C_BUS_NAME, );
+ if (ret) {
+ printf("Cannot get I2C bus %s: uclass_get_device_by_name
failed: %i\n",
+ OMNIA_I2C_BUS_NAME, ret);
+ return NULL;
}
- ret = i2c_get_chip(bus, OMNIA_I2C_MCU, 1, );
+ ret = i2c_get_chip(bus, addr, offset_len, );
if (ret) {
- puts("Cannot get MCU chip!\n");
- return false;
+ printf("Cannot get %s I2C chip: i2c_get_chip failed: %i\n",
+ name, ret);
+ return NULL;
}
- for (; retry > 0; --retry) {
- ret = dm_i2c_read(dev, OMNIA_I2C_MCU_ADDR_STATUS, (uchar *)
, 2);
- if (!ret)
- break;
- }
+ return dev;
+}
+
+static int omnia_mcu_read(u8 cmd, void *buf, int len)
+{
+ struct udevice *chip;
+
+ chip = omnia_get_i2c_chip("MCU", OMNIA_I2C_MCU_CHIP_ADDR,
+ OMNIA_I2C_MCU_CHIP_LEN);
+ if (!chip)
+ return -ENODEV;
+
+ return dm_i2c_read(chip, cmd, buf, len);
+}
- if (!retry) {
- puts("I2C read failed! Default PEX\n");
+#ifndef CONFIG_SPL_BUILD
+static int omnia_mcu_write(u8 cmd, const void *buf, int len)
+{
+ struct udevice *chip;
+
+ chip = omnia_get_i2c_chip("MCU", OMNIA_I2C_MCU_CHIP_ADDR,
+ OMNIA_I2C_MCU_CHIP_LEN);
+ if (!chip)
+ return -ENODEV;
+
+ return dm_i2c_write(chip, cmd, buf, len);
+}
+
+static bool disable_mcu_watchdog(void)
+{
+ int ret;
+
+ puts("Disabling MCU watchdog... ");
+
+ ret = omnia_mcu_write(CMD_WATCHDOG_STATE, "\x00", 1);
+ if (ret) {
+ printf("omnia_mcu_write failed: %i\n", ret);
return false;
}
- if (!(mode & OMNIA_I2C_MCU_CARDDET)) {
- puts("NONE\n");
+ puts("disabled\n");
+
+ return true;
+}
+#endif
+
+static bool omnia_detect_sata(void)
+{
+ int ret;
+ u16 stsword;
+
+ puts("MiniPCIe/mSATA card detection... ");
+
+ ret = omnia_mcu_read(CMD_GET_STATUS_WORD, , sizeof(stsword));
+ if (ret) {
+ printf("omnia_mcu_read failed: %i, defaulting to MiniPCIe
card\n",
+ ret);
return false;
}
- if (mode & OMNIA_I2C_MCU_SATA) {
- puts("SATA\n");
- return true;
- } else {
- puts("PEX\n");
+ if (!(stsword & CARD_DET_STSBIT)) {
+ puts("none\n");
return false;
}
+
+ if (stsword & MSATA_IND_STSBIT)
+
[U-Boot] [PATCH u-boot-marvell v2 08/15] arm: mvebu: turris_omnia: fix checkpatch warnings
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 6b8fa53c98..d4fb89f15f 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -290,12 +290,12 @@ static struct mv_ddr_topology_map board_topology_map_2g =
{
struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
{
- static int mem = 0;
+ static int mem;
struct omnia_eeprom oep;
/* Get the board config from EEPROM */
- if (mem == 0) {
- if(!omnia_read_eeprom())
+ if (!mem) {
+ if (!omnia_read_eeprom())
goto out;
printf("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
@@ -368,7 +368,7 @@ int board_early_init_f(void)
int board_init(void)
{
- /* adress of boot parameters */
+ /* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
#ifndef CONFIG_SPL_BUILD
@@ -391,9 +391,9 @@ int board_late_init(void)
#ifdef CONFIG_ATSHA204A
static struct udevice *get_atsha204a_dev(void)
{
- static struct udevice *dev = NULL;
+ static struct udevice *dev;
- if (dev != NULL)
+ if (dev)
return dev;
if (uclass_get_device_by_name(UCLASS_MISC, "atsha204a@64", )) {
@@ -420,13 +420,13 @@ int checkboard(void)
err = atsha204a_read(dev, ATSHA204A_ZONE_OTP, false,
OMNIA_ATSHA204_OTP_VERSION,
-(u8 *) _num);
+(u8 *)_num);
if (err)
goto out;
err = atsha204a_read(dev, ATSHA204A_ZONE_OTP, false,
OMNIA_ATSHA204_OTP_SERIAL,
-(u8 *) _num);
+(u8 *)_num);
if (err)
goto out;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 06/15] arm: mvebu: turris_omnia: add SCSI as boot target
If SCSI is enabled, U-Boot should try to boot also from SCSI device on Turris Omnia. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 5a7539c9be..5b9639e050 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -90,9 +90,16 @@ #define BOOT_TARGET_DEVICES_USB(func) #endif +#ifdef CONFIG_SCSI +#define BOOT_TARGET_DEVICES_SCSI(func) func(SCSI, scsi, 0) +#else +#define BOOT_TARGET_DEVICES_SCSI(func) +#endif + #define BOOT_TARGET_DEVICES(func) \ BOOT_TARGET_DEVICES_MMC(func) \ BOOT_TARGET_DEVICES_USB(func) \ + BOOT_TARGET_DEVICES_SCSI(func) \ func(PXE, pxe, na) \ func(DHCP, dhcp, na) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 05/15] arm: mvebu: turris_omnia: move I2C dependencies to Kconfig
The I2C dependencies are defined in include/configs/turris_omnia.h, because Turris Omnia won't boot correctly without I2C support. Move these dependencies to Kconfig, so that they are selected if Turris Omnia is selected as target. Signed-off-by: Marek Behún --- arch/arm/mach-mvebu/Kconfig| 5 + include/configs/turris_omnia.h | 11 --- 2 files changed, 5 insertions(+), 11 deletions(-) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index f99bd3bf65..2bf829d10a 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -116,6 +116,11 @@ config TARGET_DB_88F6820_AMC config TARGET_TURRIS_OMNIA bool "Support Turris Omnia" select 88F6820 + select DM_I2C + select I2C_MUX + select I2C_MUX_PCA954x + select SPL_I2C_MUX + select SYS_I2C_MVTWSI config TARGET_TURRIS_MOX bool "Support Turris Mox" diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 5e692e6829..5a7539c9be 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -18,17 +18,6 @@ */ #define CONFIG_SYS_TCLK25000 /* 250MHz */ -/* - * Commands configuration - */ - -/* I2C support */ -#define CONFIG_DM_I2C -#define CONFIG_I2C_MUX -#define CONFIG_I2C_MUX_PCA954x -#define CONFIG_SPL_I2C_MUX -#define CONFIG_SYS_I2C_MVTWSI - /* USB/EHCI configuration */ #define CONFIG_EHCI_IS_TDI -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 14/15] arm: mvebu: turris_omnia: add RESET button handling
There is a Factory RESET button on the back side of the Turris Omnia
router. When user presses this button before powering the device up and
keeps it pressed, the microcontroller prevents the main CPU from booting
and counts how long the RESET button is being pressed (and indicates
this by lighting up front LEDs).
The idea behind this is that the user can boot the device into several
Factory RESET modes.
This patch adds support for U-Boot to read into which Factory RESET mode
the user booted the device. The value is an integer stored into the
omnia_reset environment variable. It is 0 if the button was not pressed
at all during power up, otherwise it is the number identifying the
Factory RESET mode.
This patch also adds support for configuring (via Kconfig) if the
bootcmd environment variable should be overwritten if this Factory RESET
button was pressed during device powerup, and if this configuration
option is enabled, the value by which bootcmd should be overwritten with
is also a configurable option. The default value sets the colors of all
the LEDs on the front panel to green, then loads the rescue system image
from the SPI flash memory and then boots it.
Signed-off-by: Marek Behún
---
arch/arm/mach-mvebu/Kconfig | 43
board/CZ.NIC/turris_omnia/turris_omnia.c | 23 +
2 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index fc29c3b084..4229a505d1 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -116,6 +116,7 @@ config TARGET_DB_88F6820_AMC
config TARGET_TURRIS_OMNIA
bool "Support Turris Omnia"
select 88F6820
+ select BOARD_LATE_INIT
select DM_I2C
select I2C_MUX
select I2C_MUX_PCA954x
@@ -165,6 +166,48 @@ config TARGET_DB_XC3_24G4XG
endchoice
+if TARGET_TURRIS_OMNIA
+
+config TURRIS_OMNIA_RSTBTN_OVERWRITE_BOOTCMD
+ bool "Turris Omnia RESET button overwrites bootcmd"
+ default y
+ help
+ There is a RESET button on the back side of the Turris Omnia router,
+ which is read by the microcontroller before the main CPU is booted.
+ If this button is pressed during device poweron, the CPU is only
+ booted after the button is released.
+
+ The CPU can then read how long the RESET button was pressed (in time
+ intervals of cca 2 seconds, at most 12 different values), and U-Boot
+ stores this value into omnia_reset environment variable.
+ The microcontroller also lights up one front LED every time interval,
+ so that users can see the value they are forcing.
+
+ If this option is enabled, the board code will also overwrite the
+ bootcmd variable with a constant configurable in this configuration
+ (config TURRIS_OMNIA_RSTBTN_BOOTCMD_VALUE) if the RESET button was
+ pressed for at least one time interval.
+
+ Otherwise only the omnia_reset environment variable is set.
+
+config TURRIS_OMNIA_RSTBTN_BOOTCMD_VALUE
+ string "Turris Omnia RESET button bootcmd value"
+ default "i2c dev 2; i2c mw 0x2a.1 0x3 0x1c 1; i2c mw 0x2a.1 0x4 0x1c 1;
mw.l 0x0100 0x00ff000c; i2c write 0x0100 0x2a.1 0x5 4 -s; setenv
bootargs \\\"$bootargs omniarescue=$omnia_reset\\\"; sf probe; sf read
0x100 0x10 0x70; bootm 0x100; bootz 0x100"
+ depends on TURRIS_OMNIA_RSTBTN_OVERWRITE_BOOTCMD
+ help
+ If the RESET button is pressed during device poweron and released at
+ least after cca 2 seconds, the bootcmd will be overwritten with this
+ value.
+
+ You can use the omnia_reset environment variable in this command to
+ detect how long the reset button was pressed (or pass this value to
+ Linux as a boot parameter).
+
+ The default value of this command set the front LEDs to green color
+ and then tries to boot rescue system from SPI memory.
+
+endif
+
config SYS_BOARD
default "clearfog" if TARGET_CLEARFOG
default "helios4" if TARGET_HELIOS4
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index af43ee23d9..91fce6370c 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -328,6 +328,28 @@ static int set_regdomain(void)
printf("Regdomain set to %s\n", rd);
return env_set("regdomain", rd);
}
+
+static void handle_reset_button(void)
+{
+ int ret;
+ u8 reset_status;
+
+ ret = omnia_mcu_read(CMD_GET_RESET, _status, 1);
+ if (ret) {
+ printf("omnia_mcu_read failed: %i, reset status unknown!\n",
+ ret);
+ return;
+ }
+
+ env_set_ulong("omnia_reset", reset_status);
+
+#ifdef CONFIG_TURRIS_OMNIA_RSTBTN_OVERWRITE_BOOTCMD
+ if (reset_status) {
+ printf("RESET button was pressed, overwriting
Re: [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
> I would really like not to see such board specific code added to this > driver. > > Frankly, I fail to understand why used udelay(11) instead of udelay(10) > should result in such a difference on your board. Could you please > investigate a bit more and hopefully come up with a "better" solution > for this issue? > > Thanks, > Stefan Hi Stefan, I think I found what was the issue, just sent a patch series for Omnia, the last patch explains my theory and fixes the issue with one ndelay(100) Marek ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 15/15] i2c: mvtwsi: fix reading status register after interrupt
The twsi_wait function reads the control register for interrupt flag,
and if interrupt flag is present, it immediately reads status register.
On our device this sometimes causes bad value being read from status
register, as if the value was not yet updated.
My theory is that the controller does approximately this:
1. sets interrupt flag in control register,
2. sets the value of status register,
3. causes an interrupt
In U-Boot we do not use interrupts, so I think that it is possible that
sometimes the status register in the twsi_wait function is read between
points 1 and 2.
The bug does not appear if I add a small delay before reading status
register.
Wait 100ns (which in U-Boot currently means 1 us, because ndelay(i)
function calls udelay(DIV_ROUND_UP(i, 1000))) before reading the status
register.
Signed-off-by: Marek Behún
Cc: Mario Six
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Heiko Schocher
---
drivers/i2c/mvtwsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 74ac0a4aa7..483a71ba12 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -271,6 +271,7 @@ static int twsi_wait(struct mvtwsi_registers *twsi, int
expected_status,
do {
control = readl(>control);
if (control & MVTWSI_CONTROL_IFLG) {
+ ndelay(100);
status = readl(>status);
if (status == expected_status)
return 0;
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 12/15] arm: mvebu: turris_*: remove watchdog include
Since board watchdog is now unified and not handled in board files, remove the unnecessary includes. Signed-off-by: Marek Behún --- board/CZ.NIC/turris_mox/turris_mox.c | 4 board/CZ.NIC/turris_omnia/turris_omnia.c | 4 2 files changed, 8 deletions(-) diff --git a/board/CZ.NIC/turris_mox/turris_mox.c b/board/CZ.NIC/turris_mox/turris_mox.c index 8a4872343b..3818e3752a 100644 --- a/board/CZ.NIC/turris_mox/turris_mox.c +++ b/board/CZ.NIC/turris_mox/turris_mox.c @@ -16,10 +16,6 @@ #include #include -#ifdef CONFIG_WDT_ARMADA_37XX -#include -#endif - #include "mox_sp.h" #define MAX_MOX_MODULES10 diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index 54efd2d4c9..b073a985a5 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -20,10 +20,6 @@ #include # include -#ifdef CONFIG_WDT_ORION -# include -#endif - #include "../drivers/ddr/marvell/a38x/ddr3_init.h" #include <../serdes/a38x/high_speed_env_spec.h> -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 11/15] arm: mvebu: turris_omnia: print board info as Turris Mox
Unify the way how Omnia and Mox print board information (RAM size and
serial number).
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 8571541b0a..54efd2d4c9 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -426,11 +426,13 @@ int checkboard(void)
}
out:
+ printf("Turris Omnia:\n");
+ printf(" RAM size: %i MiB\n", omnia_get_ram_size_gb() * 1024);
if (err)
- printf("Board: Turris Omnia (ver N/A). SN: N/A\n");
+ printf(" Serial Number: unknown\n");
else
- printf("Board: Turris Omnia SNL %08X%08X\n",
- be32_to_cpu(version_num), be32_to_cpu(serial_num));
+ printf(" Serial Number: %08X%08X\n", be32_to_cpu(version_num),
+ be32_to_cpu(serial_num));
return 0;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 10/15] arm: mvebu: turris_omnia: refactor more code
Refactor RAM size reading from EEPROM in preparation for next patch.
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 58
1 file changed, 28 insertions(+), 30 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 640ee2a2a3..8571541b0a 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -236,6 +236,31 @@ static bool omnia_read_eeprom(struct omnia_eeprom *oep)
return true;
}
+static int omnia_get_ram_size_gb(void)
+{
+ static int ram_size;
+ struct omnia_eeprom oep;
+
+ if (!ram_size) {
+ /* Get the board config from EEPROM */
+ if (omnia_read_eeprom()) {
+ debug("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
+
+ if (oep.ramsize == 0x2)
+ ram_size = 2;
+ else
+ ram_size = 1;
+ } else {
+ /* Hardcoded fallback */
+ puts("Memory config from EEPROM read failed!\n");
+ puts("Falling back to default 1 GiB!\n");
+ ram_size = 1;
+ }
+ }
+
+ return ram_size;
+}
+
/*
* Define the DDR layout / topology here in the board file. This will
* be used by the DDR3 init code in the SPL U-Boot version to configure
@@ -287,37 +312,10 @@ static struct mv_ddr_topology_map board_topology_map_2g =
{
struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
{
- static int mem;
- struct omnia_eeprom oep;
-
- /* Get the board config from EEPROM */
- if (!mem) {
- if (!omnia_read_eeprom())
- goto out;
-
- printf("Memory config in EEPROM: 0x%02x\n", oep.ramsize);
-
- if (oep.ramsize == 0x2)
- mem = 2;
- else
- mem = 1;
- }
-
-out:
- /* Hardcoded fallback */
- if (mem == 0) {
- puts("WARNING: Memory config from EEPROM read failed.\n");
- puts("Falling back to default 1GiB map.\n");
- mem = 1;
- }
-
- /* Return the board topology as defined in the board code */
- if (mem == 1)
- return _topology_map_1g;
- if (mem == 2)
+ if (omnia_get_ram_size_gb() == 2)
return _topology_map_2g;
-
- return _topology_map_1g;
+ else
+ return _topology_map_1g;
}
#ifndef CONFIG_SPL_BUILD
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 03/15] arm: mvebu: turris_omnia: use AHCI and SATA driver model
Enable AHCI, SCSI and SATA for compliance with the driver model migration. Signed-off-by: Marek Behún --- configs/turris_omnia_defconfig | 7 +++ 1 file changed, 7 insertions(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index 2ad2f6e431..5086da13a5 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -26,6 +26,8 @@ CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y +CONFIG_CMD_SATA=y +CONFIG_CMD_SCSI=y CONFIG_CMD_SF=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y @@ -39,6 +41,11 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_MAX_HZ=y CONFIG_ENV_SPI_MAX_HZ=5000 CONFIG_SPL_OF_TRANSLATE=y +CONFIG_AHCI=y +CONFIG_AHCI_PCI=y +CONFIG_AHCI_MVEBU=y +CONFIG_SATA=y +CONFIG_SCSI=y CONFIG_SCSI_AHCI=y CONFIG_ATSHA204A=y CONFIG_DM_MMC=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 02/15] arm: mvebu: turris_omnia: add XHCI to defconfig
Add XHCI_HOST and XHCI_MVEBU to defconfig, so that user's can by default boot from USB on Turris Omnia. Signed-off-by: Marek Behún --- configs/turris_omnia_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index a528a9b5bc..2ad2f6e431 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -58,5 +58,7 @@ CONFIG_KIRKWOOD_SPI=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_MVEBU=y CONFIG_WDT=y CONFIG_WDT_ORION=y -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 13/15] arm: mvebu: turris_omnia: fix regdomain env var setting
The regdomain environment variable is set according to value read from EEPROM. This has to be done in board_late_init, after the environment variables are read from SPI. Select CONFIG_BOARD_LATE_INIT in Kconfig for the Turris Omnia target. Signed-off-by: Marek Behún --- board/CZ.NIC/turris_omnia/turris_omnia.c | 1 - 1 file changed, 1 deletion(-) diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c b/board/CZ.NIC/turris_omnia/turris_omnia.c index b073a985a5..af43ee23d9 100644 --- a/board/CZ.NIC/turris_omnia/turris_omnia.c +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c @@ -364,7 +364,6 @@ int board_init(void) #ifndef CONFIG_SPL_BUILD disable_mcu_watchdog(); - set_regdomain(); #endif return 0; -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 01/15] arm: mvebu: turris_omnia: remove redundant code
The i2c slave disabling is done by mvtwsi driver and is not needed here.
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 4c08f810a2..055ebad000 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -50,8 +50,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define OMNIA_ATSHA204_OTP_MAC03
#define OMNIA_ATSHA204_OTP_MAC14
-#define MVTWSI_ARMADA_DEBUG_REG0x8c
-
/*
* Those values and defines are taken from the Marvell U-Boot version
* "u-boot-2013.01-2014_T3.0"
@@ -297,8 +295,6 @@ static int set_regdomain(void)
int board_early_init_f(void)
{
- u32 i2c_debug_reg;
-
/* Configure MPP */
writel(0x, MVEBU_MPP_BASE + 0x00);
writel(0x, MVEBU_MPP_BASE + 0x04);
@@ -321,15 +317,6 @@ int board_early_init_f(void)
writel(OMNIA_GPP_OUT_ENA_LOW, MVEBU_GPIO0_BASE + 0x04);
writel(OMNIA_GPP_OUT_ENA_MID, MVEBU_GPIO1_BASE + 0x04);
- /*
-* Disable I2C debug mode blocking 0x64 I2C address.
-* Note: that would be redundant once Turris Omnia migrates to DM_I2C,
-* because the mvtwsi driver includes equivalent code.
-*/
- i2c_debug_reg = readl(MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
- i2c_debug_reg &= ~(1<<18);
- writel(i2c_debug_reg, MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
-
return 0;
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 04/15] arm: mvebu: turris_omnia: remove legacy macros from board header
These are not needed if MMC and SCSI DM drivers are used. Signed-off-by: Marek Behún --- include/configs/turris_omnia.h | 14 -- 1 file changed, 14 deletions(-) diff --git a/include/configs/turris_omnia.h b/include/configs/turris_omnia.h index 0e65a12345..5e692e6829 100644 --- a/include/configs/turris_omnia.h +++ b/include/configs/turris_omnia.h @@ -29,20 +29,6 @@ #define CONFIG_SPL_I2C_MUX #define CONFIG_SYS_I2C_MVTWSI -/* - * SDIO/MMC Card Configuration - */ -#define CONFIG_SYS_MMC_BASEMVEBU_SDIO_BASE - -/* - * SATA/SCSI/AHCI configuration - */ -#define CONFIG_SCSI_AHCI_PLAT -#define CONFIG_SYS_SCSI_MAX_SCSI_ID2 -#define CONFIG_SYS_SCSI_MAX_LUN1 -#define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \ -CONFIG_SYS_SCSI_MAX_LUN) - /* USB/EHCI configuration */ #define CONFIG_EHCI_IS_TDI -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH u-boot-marvell v2 00/15] Fixes for Turris Omnia
Hi, this is the second version of my fixes for Turris Omnia. I removed the patches which were already applied or provided a better fix. The other patches I shall describe now here as if this was the first version. 1. removes redundant code done by I2C mvtwsi driver from board file 2. adds XHCI support to defconfig 3. in compliance with driver model use AHCI, SATA and SCSI 4. remove legacy macros from config header 5. move I2C dependencies from header file to Kconfig for TARGET_TURRIS_OMNIA 6. add SCSI as boot target 7. board code refactoring 8. fix checkpatch warnings 9. add ATSHA204A dependency to Kconfig for TARGET_TURRIS_OMNIA 10. more board code refactoring 11. print board information in the same way Turris Mox does 12. remove watchdog header include (in Turris Mox board file as well) 13. fix setting of the regdomain environment variable used on Omnia 14. add code for handling the button on the back side of Omnia, the purpose of which is factory reset 15. fix I2C driver, which sometimes breaks the I2C controller until the device is powered off Marek Marek Behún (15): arm: mvebu: turris_omnia: remove redundant code arm: mvebu: turris_omnia: add XHCI to defconfig arm: mvebu: turris_omnia: use AHCI and SATA driver model arm: mvebu: turris_omnia: remove legacy macros from board header arm: mvebu: turris_omnia: move I2C dependencies to Kconfig arm: mvebu: turris_omnia: add SCSI as boot target arm: mvebu: turris_omnia: refactor I2C accessing code arm: mvebu: turris_omnia: fix checkpatch warnings arm: mvebu: turris_omnia: move ATSHA204A from defconfig to Kconfig arm: mvebu: turris_omnia: refactor more code arm: mvebu: turris_omnia: print board info as Turris Mox arm: mvebu: turris_*: remove watchdog include arm: mvebu: turris_omnia: fix regdomain env var setting arm: mvebu: turris_omnia: add RESET button handling i2c: mvtwsi: fix reading status register after interrupt arch/arm/mach-mvebu/Kconfig | 49 board/CZ.NIC/turris_mox/turris_mox.c | 4 - board/CZ.NIC/turris_omnia/turris_omnia.c | 333 --- configs/turris_omnia_defconfig | 10 +- drivers/i2c/mvtwsi.c | 1 + include/configs/turris_omnia.h | 32 +-- 6 files changed, 236 insertions(+), 193 deletions(-) -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] Tidy up some dangling OP-TEE gotchas
On 24/04/2019 01:43, Bryan O'Donoghue wrote: Rober P Day rightly pointed out that some odd OP-TEE specific defines were appearing in his defconfig, despite not having CONFIG_OPTEE=y set in his defconfig. Ping, Robert, Rui, Fabio - do you guys want changes here ? --- bod ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: rename arch mt7620 to mt7628
On Mon, 2019-04-29 at 16:27 +0200, Daniel Schwierzeck wrote: > > Am 29.04.19 um 11:40 schrieb Stefan Roese: > > On 29.04.19 11:28, Weijie Gao wrote: > >> On Mon, 2019-04-29 at 07:08 +0200, Stefan Roese wrote: > >>> On 28.04.19 11:38, Weijie Gao wrote: > The MediaTek MT7620 and MT7628 SoCs are different. > Although they use the same memory controller, the lowlevel code (CPU > PLL) > and other peripherals they use are totally different. Which means they > should use seperate mach directories. > >>> > >>> s/seperate/separate > >>> > Currently the mach mt7620 contains only architecture code of MT7628. > In case we add real arch support of MT7620 in the future, the arch > should > be renamed to mt7628, including both Kconfig files and directories. > Other files affected are also modified. > >>> > >>> Perhaps it would be possible to support both SoC's (MT7620 and > >>> MT7628/88) > >>> in one mach directory? Frankly I don't know the differences in > >>> detail, so > >>> its your call. > > > > > > > >> Dear Stefan, > >> > >> Thanks for pointing out the missing files. > >> > >> Here is the summary of HW components needed by u-boot for MT7620 and > >> MT7628: > >> > >> L1 data cache:MT7620 can not lock it. > >>MT7628 uses it to do DDR calibration. > >> CPU frequency (PLL): MT7620 can change it. MT7628 can't. > >>The PLL registers are different. > >> DRAM controller: Near the same. > >>MT7620 can't do calibration. > >>MT7628 has extra PAD configurations. > > > > These "devices / controllers" are handled in the mach-foo directory. > > > >> GPIO controller: Not the same IP core. > >> SPI controller: Not the same IP core. > >> Frame engine: Similar IP core, different generation. > >> Built-in Ethernet switch: Not the same IP core. > > > > And these controllers are handled in the drivers/foo directly. So any > > different IP core (between MT7620 and MT7628) has no effect to the > > mach directory. > > > > Please don't misunderstand me. I absolutely agree that we need to > > differentiate between those two SoC's. So moving to CONFIG_SOC_MT7628 > > instead of SOC_MT7620 makes perfect sense. I only want to avoid the > > creation of another mach-foo directory, where code might be shared > > between both SoC's. > > > >> > >> So I insist to split them into two mach directory. > > > > I see. Okay, lets move forward then with your patch and lets finally > > decide if and what can be shared between those SoC's, once (if) support > > for the MT7620 arrives in mainline. > > > > BTW: Do you plan on adding support for the MT7620 anytime soon? > > > > I agree with Stefan, there is no need to create separate mach- > directories. With the power of Kconfig and Kbuild you can easily handle > multiple SoCs within one mach- directory, for instance look at > mach-bmips or mach-mscc. Could you rather rename to mach-mediatek or > mach-mtmips so that we would have the Kconfig symbols ARCH_MEDIATEK and > SOC_MT7628 (plus SOC_MT7620 in the future)? Thanks. > > BTW: it's good to see that another vendor in the MIPS area is stepping > up to maintain its products in mainline ;) > Hi Daniel, You are right. I forgot I've already submitted a mach- like this: MediaTek's ARM SoCs - MT7623 and MT7629. They are both placed in mach-mediatek. A submenu can choose whether to build MT7623 or MT7629. ARCH_MEDIATEK is already used. I think ARCH_MTMIPS is just fine. I'll modify and resubmit the patch. Hi Stefan, I'm just starting to rewrite some lowlevel codes for mt7628 in the next one or two months. Then add support for MT7620. Best Regards, Weijie ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] crypto/fsl: Use __sec_set_jr_context_normal
On 25/04/2019 04:24, Breno Matheus Lima wrote:
I couldn't get encrypted boot working in my first attempt, doing the
exact same procedure with commit 22191ac35344 ("drivers/crypto/fsl:
assign job-rings to non-TrustZone") reverted works fine.
Hi Breno,
I noticed another patch from you re: dek blob, does that address this
issue for you are is this still a live thing ?
If you are running in secure-world, and the BootROM dek blob stuff
validates job-ring ownership it _should_ be possible to flip the
ownership bits to what the BootROM expects and then back again.
If its not working, presumably its because we aren't flipping ownership
at the right time.
Maybe better to set permissions to secure-world while we are in u-boot
and then switch to normal world before we hand over to the next boot phase.
---
bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.
On 4/26/19 11:05 AM, Marek Vasut wrote:
On 4/26/19 7:08 PM, Atish Patra wrote:
On 4/25/19 10:33 PM, Marek Vasut wrote:
On 4/25/19 9:56 PM, Atish Patra wrote:
Add gz parsing logic so that booti can parse both Image
and Image.gz.
Signed-off-by: Atish Patra
---
arch/riscv/lib/image.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/lib/image.c b/arch/riscv/lib/image.c
index e8802007c446..73ebd0da3885 100644
--- a/arch/riscv/lib/image.c
+++ b/arch/riscv/lib/image.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -16,6 +18,8 @@ DECLARE_GLOBAL_DATA_PTR;
/* ASCII version of "RISCV" defined in Linux kernel */
#define LINUX_RISCV_IMAGE_MAGIC 0x5643534952
+#define GZ_HEADER_0 0x1f
+#define GZ_HEADER_1 0x8b
struct linux_image_h {
uint32_t code0; /* Executable code */
@@ -32,9 +36,31 @@ int booti_setup(ulong image, ulong
*relocated_addr, ulong *size,
bool force_reloc)
{
struct linux_image_h *lhdr;
+ uint8_t *temp;
+ void *dest;
+ ulong dest_end;
+ int ret;
+ /* TODO: Is there a way to figure out length of compressed
Image.gz ?
+ * Otherwise, set it to SYS_BOOTM_LEN which should be sufficient.
+ */
Presumably this is a RFC patch then ?
Yeah. I am not very sure if there is a better way to determine the size.
Hence the comment. I am hoping somebody here would suggest something ;).
Mark the patch as RFC next time please.
Sure. Sorry for not marking RFC in the first time.
What happens if you have two (or more) gzip-ed files back-to-back ?
Wouldn't you then decompress both ? That might lead to all kinds of
problems.
That will be catastrophic. But this was intended only for booti and the
expectation was that only Image.gz must be loaded before this.
That also means it's horribly fragile.
Having said that, if we can find a reliable way of figuring out the
compressed file size here, we can get rid of this hack.
See below
+ int len = CONFIG_SYS_BOOTM_LEN;
+
+ temp = (uint8_t *)map_sysmem(image, 0);
Is the type cast really needed ?
Just wanted to be explicit. Will remove it.
- lhdr = (struct linux_image_h *)map_sysmem(image, 0);
+ if (*(temp) == GZ_HEADER_0 && *(temp+1) == GZ_HEADER_1) {
Wrap the image in some fitImage or so contained, mark the image as gzip
compressed there and all this goes away.
Yes. FIT image parsing can be done in that way. However, the idea was
here to load Image.gz directly. Image.gz is default compressed Linux
kernel image format in RISC-V.
Sigh, and the image header is compressed as well, so there's no way to
identify the image format, right ? And there's no decompressor, so the
dcompressing has to be done by bootloader, which would need some sort of
very smart way of figuring out which exact compression method is used ?
Yes. Image.gz is always gunzip. So checking first two bytes is enough to
confirm that it is a gz file.
The tricky part is length of the compressed file. I took another look at
the gunzip implementation in U-Boot. It looks like to me that compressed
header length just to parse the header correctly. It doesn't actually
use the "length" to decompress. In fact, it updates the length with
uncompressed bytes after the decompression.
Regards,
Atish
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/4] riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled
Hi lukas
Auer, Lukas 於 2019年4月29日 週一 下午7:55寫道：
>
> Hi Rick,
>
> On Mon, 2019-04-29 at 15:44 +0800, Andes wrote:
> > From: Rick Chen
> >
> > This patch will fix prior_stage_fdt_address write failure problem, when
> > AE350 boots from flash.
> >
> > When AE350 boots from flash, prior_stage_fdt_address will be flash
> > address, we shall avoid it to be written.
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > arch/riscv/cpu/cpu.c| 2 ++
> > arch/riscv/cpu/start.S | 2 ++
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 4
> > include/configs/ax25-ae350.h| 2 +-
> > 4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > index 0cfd7d6..e9a8b43 100644
> > --- a/arch/riscv/cpu/cpu.c
> > +++ b/arch/riscv/cpu/cpu.c
> > @@ -15,7 +15,9 @@
> > * The variables here must be stored in the data section since they are
> > used
> > * before the bss section is available.
> > */
> > +#ifdef CONFIG_OF_PRIOR_STAGE
> > phys_addr_t prior_stage_fdt_address __attribute__((section(".data")));
> > +#endif
> > #ifndef CONFIG_XIP
> > u32 hart_lottery __attribute__((section(".data"))) = 0;
> >
> > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
> > index 3402d09..60ac8c6 100644
> > --- a/arch/riscv/cpu/start.S
> > +++ b/arch/riscv/cpu/start.S
> > @@ -111,8 +111,10 @@ call_board_init_f_0:
> > bneztp, secondary_hart_loop
> > #endif
> >
> > +#ifdef CONFIG_OF_PRIOR_STAGE
> > la t0, prior_stage_fdt_address
> > SREGs1, 0(t0)
> > +#endif
> >
> > jal board_init_f_init_reserve
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > index d343453..3d65ce7 100644
> > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -67,10 +67,6 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> > flash_info_t *info)
> >
> > void *board_fdt_blob_setup(void)
> > {
> > - void **ptr = (void *)_stage_fdt_address;
> > - if (fdt_magic(*ptr) == FDT_MAGIC)
> > - return (void *)*ptr;
> > -
>
> Please move this change and the following into a separate patch.
>
> You may also try to use CONFIG_OF_SEPARATE instead of CONFIG_OF_BOARD.
> As far as I know, this is the recommended configuration and with this
> change, I don't think CONFIG_OF_BOARD is needed anymore.
>
OK.
I will move it into a separate patch and use CONFIG_OF_SEPARATE.
Thanks
Rick
> Thanks,
> Lukas
>
> > return (void *)CONFIG_SYS_FDT_BASE;
> > }
> >
> > diff --git a/include/configs/ax25-ae350.h b/include/configs/ax25-ae350.h
> > index 395f3a4..a4037f3 100644
> > --- a/include/configs/ax25-ae350.h
> > +++ b/include/configs/ax25-ae350.h
> > @@ -40,7 +40,7 @@
> > #define CONFIG_SYS_MALLOC_LEN (512 << 10)
> >
> > /* DT blob (fdt) address */
> > -#define CONFIG_SYS_FDT_BASE 0x000f
> > +#define CONFIG_SYS_FDT_BASE 0x800f
> >
> > /*
> > * Physical Memory Map
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] fit: Support compression for non-kernel components (e.g. FDT)
> However, compared to my above mentioned RFC patch, this here somehow > fails when loading something from the image, e.g. using the cmd 'fpga > loadmk'. Seems like this one doesn't transparently uncompress? It looks to me like do_fpga_loadmk() doesn't actually call fit_load_image()? It calls fit_image_get_data() directly, so it bypasses the code I'm adding. Maybe it should be using fit_load_image() instead, but that's moving pretty far away from what I was trying to do... it could be left for a later patch? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] ti: Add device-tree for am335x-pocketbeagle.
Add device-tree files from linux 5.1-rc7 needed to complete support
for PocketBeagle.
Signed-off-by: Vagrant Cascadian
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/am335x-osd335x-common.dtsi | 124 +
arch/arm/dts/am335x-pocketbeagle.dts| 237
3 files changed, 362 insertions(+)
create mode 100644 arch/arm/dts/am335x-osd335x-common.dtsi
create mode 100644 arch/arm/dts/am335x-pocketbeagle.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b4dc57edbd..d03419285a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -255,6 +255,7 @@ dtb-$(CONFIG_AM33XX) += \
am335x-evmsk.dtb \
am335x-bonegreen.dtb \
am335x-icev2.dtb \
+ am335x-pocketbeagle.dtb \
am335x-pxm50.dtb \
am335x-rut.dtb \
am335x-shc.dtb \
diff --git a/arch/arm/dts/am335x-osd335x-common.dtsi
b/arch/arm/dts/am335x-osd335x-common.dtsi
new file mode 100644
index 00..f8ff473f94
--- /dev/null
+++ b/arch/arm/dts/am335x-osd335x-common.dtsi
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Robert Nelson
+ */
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = <_reg>;
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x2000>; /* 512 MB */
+ };
+};
+
+_opp_table {
+ /*
+ * Octavo Systems:
+ * The EFUSE_SMA register is not programmed for any of the AM335x wafers
+ * we get and we are not programming them during our production test.
+ * Therefore, from a DEVICE_ID revision point of view, the silicon looks
+ * like it is Revision 2.1. However, from an EFUSE_SMA point of view for
+ * the HW OPP table, the silicon looks like it is Revision 1.0 (ie the
+ * EFUSE_SMA register reads as all zeros).
+ */
+ oppnitro-10 {
+ opp-supported-hw = <0x06 0x0100>;
+ };
+};
+
+_pinmux {
+ i2c0_pins: pinmux-i2c0-pins {
+ pinctrl-single,pins = <
+ AM33XX_IOPAD(0x988, PIN_INPUT_PULLUP | MUX_MODE0)
/* (C17) I2C0_SDA.I2C0_SDA */
+ AM33XX_IOPAD(0x98c, PIN_INPUT_PULLUP | MUX_MODE0)
/* (C16) I2C0_SCL.I2C0_SCL */
+ >;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ status = "okay";
+ clock-frequency = <40>;
+
+ tps: tps@24 {
+ reg = <0x24>;
+ };
+};
+
+/include/ "tps65217.dtsi"
+
+ {
+ interrupts = <7>; /* NMI */
+ interrupt-parent = <>;
+
+ ti,pmic-shutdown-controller;
+
+ pwrbutton {
+ interrupts = <2>;
+ status = "okay";
+ };
+
+ regulators {
+ dcdc1_reg: regulator@0 {
+ regulator-name = "vdds_dpr";
+ regulator-always-on;
+ };
+
+ dcdc2_reg: regulator@1 {
+ /* VDD_MPU voltage limits 0.95V - 1.26V with +/-4%
tolerance */
+ regulator-name = "vdd_mpu";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <1351500>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ dcdc3_reg: regulator@2 {
+ /* VDD_CORE voltage limits 0.95V - 1.1V with +/-4%
tolerance */
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <925000>;
+ regulator-max-microvolt = <115>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: regulator@3 {
+ regulator-name = "vio,vrtc,vdds";
+ regulator-always-on;
+ };
+
+ ldo2_reg: regulator@4 {
+ regulator-name = "vdd_3v3aux";
+ regulator-always-on;
+ };
+
+ ldo3_reg: regulator@5 {
+ regulator-name = "vdd_1v8";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ ldo4_reg: regulator@6 {
+ regulator-name = "vdd_3v3a";
+ regulator-always-on;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/am335x-pocketbeagle.dts
b/arch/arm/dts/am335x-pocketbeagle.dts
new file mode 100644
index 00..62fe5cab9f
--- /dev/null
+++ b/arch/arm/dts/am335x-pocketbeagle.dts
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0
[U-Boot] [PATCH 2/2] ti: Add am335x-pocketbeagle to am335x_evm_defconfig.
Add am335x-pocketbeagle to CONFIG_OF_LIST in am335x_evm_defconfig. Signed-off-by: Vagrant Cascadian --- configs/am335x_evm_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig index 105ff01d14..967ee82bca 100644 --- a/configs/am335x_evm_defconfig +++ b/configs/am335x_evm_defconfig @@ -31,7 +31,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),1 # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="am335x-evm" -CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2" +CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk am335x-bonegreen am335x-icev2 am335x-pocketbeagle" CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_SPL_ENV_IS_NOWHERE=y CONFIG_BOOTCOUNT_LIMIT=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] Finish support for enabling BeagleBoard.org PocketBeagle.
Partial support for PocketBeagle was added in: commit:eff0c977b3b9466657362869e04da231a892e31e "Add support for BeagleBoard.org PocketBeagle" This series: - Adds necessary device-tree files from linux 5.1-rc7 - Enables am335x-pocketbeagle in am335x_evm_defconfig. Vagrant Cascadian (2): ti: Add device-tree for am335x-pocketbeagle. ti: Add am335x-pocketbeagle to am335x_evm_defconfig. arch/arm/dts/Makefile | 1 + arch/arm/dts/am335x-osd335x-common.dtsi | 124 + arch/arm/dts/am335x-pocketbeagle.dts| 237 configs/am335x_evm_defconfig| 2 +- 4 files changed, 363 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/am335x-osd335x-common.dtsi create mode 100644 arch/arm/dts/am335x-pocketbeagle.dts -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Remove socfpga_sdram_apply_static_cfg()
On 4/29/19 3:02 PM, See, Chin Liang wrote: > On Mon, 2019-04-29 at 10:34 +0200, Marek Vasut wrote: >> On 4/26/19 8:39 AM, Simon Goldschmidt wrote: >>> >>> On Tue, Apr 23, 2019 at 6:14 PM Marek Vasut wrote: The usage of socfpga_sdram_apply_static_cfg() seems rather dubious and is confirmed to lead to a rare system hang when enabling bridges. This patch removes the socfpga_sdram_apply_static_cfg() altogether, because it's use seems unjustified and problematic. The socfpga_sdram_apply_static_cfg() triggers write to SDRAM staticcfg register to set the applycfg bit, which according to old vendor U-Boot sources can only be written when there is no traffic between the SDRAM controller and the rest of the system. Empirical measurements confirm this, setting the applycfg bit when there is traffic between the SDRAM controller and CPU leads to the SDRAM controller accesses being blocked shortly after. Altera originally solved this by moving the entire code which sets the staticcfg register to OCRAM [1]. The commit message claims that the applycfg bit needs to be set after write to fpgaportrst register. This is however inverted by Altera shortly after in [2], where the order becomes the exact opposite of what commit message [1] claims to be the required order. The explanation points to a possible problem in AMP use-case, where the FPGA might be sending transactions through the F2S bridge. However, the AMP is only the tip of the iceberg here. Any of the other L2, L3 or L4 masters can trigger transactions to the SDRAM. It becomes rather non-trivial to guarantee there are no transactions to the SDRAM controller. The SoCFPGA SDRAM driver always writes the applycfg bit in SPL. Thus, writing the applycfg again in bridge enable code seems redundant and can presumably be dropped. [1] https://github.com/altera-opensource/u-boot-socfpga/commit/75 905816ec95b0ccd515700b922628d7aa9036f8 [2] https://github.com/altera-opensource/u-boot-socfpga/commit/8b a6986b04a91d23c7adf529186b34c8d2967ad5 Signed-off-by: Marek Vasut Cc: Chin Liang See Cc: Dinh Nguyen Cc: Simon Goldschmidt Cc: Tien Fong Chee >>> Good catch! >>> >>> Reviewed-by: Simon Goldschmidt >> I am still hoping that Chin might jump in and explain the discrepancy >> between those two patches in Altera U-Boot fork I linked above. >> > > Hi Marek, Hi, > We still need the sdram_apply_static_cfg to ensure correct fpga2sdram > port is enabled, based on the new FPGA designs. https://www.intel.com/c > ontent/www/us/en/programmable/hps/cyclone- > v/hps.html#topic/sfo1411577376106.html I think the link might be broken, it leads to fpgaportrst description. Which "new FPGA designs" do you refer to ? Regarding sdram_apply_static_cfg, this only sets the applycfg bit, it has nothing to do with enabling or disabling the FPGA-to-SDRAM ports. Or does it ? The documentation is not clear what all the effects of this bit are. > For the AMP, I checked back the fogbugz case and the correct term > should be multi-core. In our test scenario, we use a NIOS II on FPGA to > pump transaction to FPGA2SDRAM continuously. It failed with original > code when FPGA config take place and that's why patch [2] needed. So [2] prevents traffic from F2S to reach the SDRAM controller by enabling the F2S ports _after_ the applycfg bit was set in the SDRAM controller. But that clearly contradicts [1], which claims: " To update the U-Boot FPGA2SDRAM enablement driver where applycfg bit need to be set after write to fpgaportrst. " > At same time, U-Boot run in serial manner. Hence we expect all L3 or L4 > masters are idle during that time. As example, tftp or fatload from > SDMMC shall be complete before next U-Boot console instruction such as > "fpga load" can take place. Right, except you cannot guarantee that in any way in AMP setup (a CPU can access the SDRAM, or some rogue traffic from L3/L4). > Hope this explains. Well, not really. I think the main point that's unclear is what the applycfg bit really does and/or affects. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] mvebu: turris_omnia: remove redundant code
The next version of this patchseries will include patch with name
"arm: mvebu: turris_omnia: move I2C dependencies to Kconfig",
which adds
select DM_I2C
to
config TARGET_TURRIS_OMNIA
Marek
On Sun, 28 Apr 2019 14:59:10 +0300
Baruch Siach wrote:
> Hi Marek,
>
> On Thu, Apr 25 2019, Marek Behún wrote:
> > The i2c slave disabling is done by mvtwsi driver and is not needed here.
> >
> > Signed-off-by: Marek Behún
> > Cc: Baruch Siach
> > ---
> > board/CZ.NIC/turris_omnia/turris_omnia.c | 11 ---
> > 1 file changed, 11 deletions(-)
> >
> > diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
> > b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > index c21d2f3ffa..c446f471a6 100644
> > --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> > +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > @@ -297,8 +297,6 @@ static int set_regdomain(void)
> >
> > int board_early_init_f(void)
> > {
> > - u32 i2c_debug_reg;
> > -
> > /* Configure MPP */
> > writel(0x, MVEBU_MPP_BASE + 0x00);
> > writel(0x, MVEBU_MPP_BASE + 0x04);
> > @@ -321,15 +319,6 @@ int board_early_init_f(void)
> > writel(OMNIA_GPP_OUT_ENA_LOW, MVEBU_GPIO0_BASE + 0x04);
> > writel(OMNIA_GPP_OUT_ENA_MID, MVEBU_GPIO1_BASE + 0x04);
> >
> > - /*
> > -* Disable I2C debug mode blocking 0x64 I2C address.
> > -* Note: that would be redundant once Turris Omnia migrates to DM_I2C,
> > -* because the mvtwsi driver includes equivalent code.
> > -*/
>
> As this comment notes, Turris Omnia needs to migrate to DM_I2C before
> removing this code. The non DM code path in the mvtwsi driver does not
> disable the debug I2C client.
>
> Is there a pending patch that enables DM_I2C for Turris Omnia?
>
> > - i2c_debug_reg = readl(MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
> > - i2c_debug_reg &= ~(1<<18);
> > - writel(i2c_debug_reg, MVEBU_TWSI_BASE + MVTWSI_ARMADA_DEBUG_REG);
> > -
> > return 0;
> > }
>
> baruch
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Read a volume from a UBI image in RAM
Hi I've a UBI image having two volumes, kernel and rootfs. I can tftp the UBI image to RAM and then write to NAND. I want to validate the kernel (checksum and signature) before writing the UBI image to flash. Is there a command available to read a volume from a UBI image that is in RAM? Thanks. Selva ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] fs: btrfs: add zstd decompression support
This adds decompression support for Zstandard, which has been included
in Linux btrfs driver for some time.
Signed-off-by: Marek Behún
---
fs/btrfs/Kconfig | 1 +
fs/btrfs/btrfs_tree.h | 5 ++--
fs/btrfs/compression.c | 59 ++
3 files changed, 63 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 22909d9fcc..f302b1fbef 100644
--- a/fs/btrfs/Kconfig
+++ b/fs/btrfs/Kconfig
@@ -2,6 +2,7 @@ config FS_BTRFS
bool "Enable BTRFS filesystem support"
select CRC32C
select LZO
+ select ZSTD
select RBTREE
help
This provides a single-device read-only BTRFS support. BTRFS is a
diff --git a/fs/btrfs/btrfs_tree.h b/fs/btrfs/btrfs_tree.h
index f90fbb2951..aa0f3d6c86 100644
--- a/fs/btrfs/btrfs_tree.h
+++ b/fs/btrfs/btrfs_tree.h
@@ -647,8 +647,9 @@ enum btrfs_compression_type {
BTRFS_COMPRESS_NONE = 0,
BTRFS_COMPRESS_ZLIB = 1,
BTRFS_COMPRESS_LZO = 2,
- BTRFS_COMPRESS_TYPES = 2,
- BTRFS_COMPRESS_LAST = 3,
+ BTRFS_COMPRESS_ZSTD = 3,
+ BTRFS_COMPRESS_TYPES = 3,
+ BTRFS_COMPRESS_LAST = 4,
};
struct btrfs_file_extent_item {
diff --git a/fs/btrfs/compression.c b/fs/btrfs/compression.c
index e5601b8f2b..346875d45a 100644
--- a/fs/btrfs/compression.c
+++ b/fs/btrfs/compression.c
@@ -6,7 +6,9 @@
*/
#include "btrfs.h"
+#include
#include
+#include
#include
#include
@@ -108,6 +110,61 @@ static u32 decompress_zlib(const u8 *_cbuf, u32 clen, u8
*dbuf, u32 dlen)
return res;
}
+#define ZSTD_BTRFS_MAX_WINDOWLOG 17
+#define ZSTD_BTRFS_MAX_INPUT (1 << ZSTD_BTRFS_MAX_WINDOWLOG)
+
+static u32 decompress_zstd(const u8 *cbuf, u32 clen, u8 *dbuf, u32 dlen)
+{
+ ZSTD_DStream *dstream;
+ ZSTD_inBuffer in_buf;
+ ZSTD_outBuffer out_buf;
+ void *workspace;
+ size_t wsize;
+ u32 res = -1;
+
+ wsize = ZSTD_DStreamWorkspaceBound(ZSTD_BTRFS_MAX_INPUT);
+ workspace = malloc(wsize);
+ if (!workspace) {
+ debug("%s: cannot allocate workspace of size %zu\n", __func__,
+ wsize);
+ return -1;
+ }
+
+ dstream = ZSTD_initDStream(ZSTD_BTRFS_MAX_INPUT, workspace, wsize);
+ if (!dstream) {
+ printf("%s: ZSTD_initDStream failed\n", __func__);
+ goto err_free;
+ }
+
+ in_buf.src = cbuf;
+ in_buf.pos = 0;
+ in_buf.size = clen;
+
+ out_buf.dst = dbuf;
+ out_buf.pos = 0;
+ out_buf.size = dlen;
+
+ while (1) {
+ size_t ret;
+
+ ret = ZSTD_decompressStream(dstream, _buf, _buf);
+ if (ZSTD_isError(ret)) {
+ printf("%s: ZSTD_decompressStream error %d\n", __func__,
+ ZSTD_getErrorCode(ret));
+ goto err_free;
+ }
+
+ if (in_buf.pos >= clen || !ret)
+ break;
+ }
+
+ res = out_buf.pos;
+
+err_free:
+ free(workspace);
+ return res;
+}
+
u32 btrfs_decompress(u8 type, const char *c, u32 clen, char *d, u32 dlen)
{
u32 res;
@@ -126,6 +183,8 @@ u32 btrfs_decompress(u8 type, const char *c, u32 clen, char
*d, u32 dlen)
return decompress_zlib(cbuf, clen, dbuf, dlen);
case BTRFS_COMPRESS_LZO:
return decompress_lzo(cbuf, clen, dbuf, dlen);
+ case BTRFS_COMPRESS_ZSTD:
+ return decompress_zstd(cbuf, clen, dbuf, dlen);
default:
printf("%s: Unsupported compression in extent: %i\n", __func__,
type);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] lib: Add xxhash support
This adds the xxhash support from Linux. Files are almost identical to
those added to Linux in commit 5d240522 ("lib: Add xxhash module") (they
haven't been touched since in Linux). The only difference is to add some
includes to be compatible with U-Boot. Also SPDX lincese tags were
added.
Signed-off-by: Marek Behún
---
include/linux/xxhash.h | 229
lib/Kconfig| 3 +
lib/Makefile | 1 +
lib/xxhash.c | 467 +
4 files changed, 700 insertions(+)
create mode 100644 include/linux/xxhash.h
create mode 100644 lib/xxhash.c
diff --git a/include/linux/xxhash.h b/include/linux/xxhash.h
new file mode 100644
index 00..85feb67fbd
--- /dev/null
+++ b/include/linux/xxhash.h
@@ -0,0 +1,229 @@
+/* SPDX-License-Identifier: (GPL-2.0 or BSD-2-Clause) */
+/*
+ * xxHash - Extremely Fast Hash algorithm
+ * Copyright (C) 2012-2016, Yann Collet.
+ *
+ * You can contact the author at:
+ * - xxHash homepage: http://cyan4973.github.io/xxHash/
+ * - xxHash source repository: https://github.com/Cyan4973/xxHash
+ */
+
+/*
+ * Notice extracted from xxHash homepage:
+ *
+ * xxHash is an extremely fast Hash algorithm, running at RAM speed limits.
+ * It also successfully passes all tests from the SMHasher suite.
+ *
+ * Comparison (single thread, Windows Seven 32 bits, using SMHasher on a Core 2
+ * Duo @3GHz)
+ *
+ * NameSpeed Q.Score Author
+ * xxHash 5.4 GB/s 10
+ * CrapWow 3.2 GB/s 2 Andrew
+ * MumurHash 3a2.7 GB/s 10 Austin Appleby
+ * SpookyHash 2.0 GB/s 10 Bob Jenkins
+ * SBox1.4 GB/s 9 Bret Mulvey
+ * Lookup3 1.2 GB/s 9 Bob Jenkins
+ * SuperFastHash 1.2 GB/s 1 Paul Hsieh
+ * CityHash64 1.05 GB/s10 Pike & Alakuijala
+ * FNV 0.55 GB/s 5 Fowler, Noll, Vo
+ * CRC32 0.43 GB/s 9
+ * MD5-32 0.33 GB/s10 Ronald L. Rivest
+ * SHA1-32 0.28 GB/s10
+ *
+ * Q.Score is a measure of quality of the hash function.
+ * It depends on successfully passing SMHasher test set.
+ * 10 is a perfect score.
+ *
+ * A 64-bits version, named xxh64 offers much better speed,
+ * but for 64-bits applications only.
+ * Name Speed on 64 bitsSpeed on 32 bits
+ * xxh64 13.8 GB/s1.9 GB/s
+ * xxh326.8 GB/s6.0 GB/s
+ */
+
+#ifndef XXHASH_H
+#define XXHASH_H
+
+#include
+
+/*-
+ * Simple Hash Functions
+ */
+
+/**
+ * xxh32() - calculate the 32-bit hash of the input with a given seed.
+ *
+ * @input: The data to hash.
+ * @length: The length of the data to hash.
+ * @seed: The seed can be used to alter the result predictably.
+ *
+ * Speed on Core 2 Duo @ 3 GHz (single thread, SMHasher benchmark) : 5.4 GB/s
+ *
+ * Return: The 32-bit hash of the data.
+ */
+uint32_t xxh32(const void *input, size_t length, uint32_t seed);
+
+/**
+ * xxh64() - calculate the 64-bit hash of the input with a given seed.
+ *
+ * @input: The data to hash.
+ * @length: The length of the data to hash.
+ * @seed: The seed can be used to alter the result predictably.
+ *
+ * This function runs 2x faster on 64-bit systems, but slower on 32-bit
systems.
+ *
+ * Return: The 64-bit hash of the data.
+ */
+uint64_t xxh64(const void *input, size_t length, uint64_t seed);
+
+/**
+ * xxhash() - calculate wordsize hash of the input with a given seed
+ * @input: The data to hash.
+ * @length: The length of the data to hash.
+ * @seed: The seed can be used to alter the result predictably.
+ *
+ * If the hash does not need to be comparable between machines with
+ * different word sizes, this function will call whichever of xxh32()
+ * or xxh64() is faster.
+ *
+ * Return: wordsize hash of the data.
+ */
+
+static inline unsigned long xxhash(const void *input, size_t length,
+ uint64_t seed)
+{
+#if BITS_PER_LONG == 64
+ return xxh64(input, length, seed);
+#else
+ return xxh32(input, length, seed);
+#endif
+}
+
+/*-
+ * Streaming Hash Functions
+ */
+
+/*
+ * These definitions are only meant to allow allocation of XXH state
+ * statically, on stack, or in a struct for example.
+ * Do not use members directly.
+ */
+
+/**
+ * struct xxh32_state - private xxh32 state, do not use members directly
+ */
+struct xxh32_state {
+ uint32_t total_len_32;
+ uint32_t large_len;
+ uint32_t v1;
+ uint32_t v2;
+ uint32_t v3;
+ uint32_t v4;
+ uint32_t mem32[4];
+ uint32_t memsize;
+};
+
+/**
+ * struct xxh32_state - private xxh64 state, do not use members directly
+ */
+struct xxh64_state {
+ uint64_t total_len;
+ uint64_t v1;
+ uint64_t v2;
+ uint64_t v3;
+ uint64_t v4;
+ uint64_t mem64[4];
+ uint32_t
[U-Boot] [PATCH v2 0/3] fs: btrfs: Add zstd decompression support
Hi, this is v2. The previous cover letter said: zstd has been enabled in kernel btrfs driver for over a year, it is time we support this also in U-Boot. This xxhash and zstd library are imported from kernel with minimal changes. This was tested on ARM target (Turris Omnia). Marek Changes since v1: - changed xxhash and zstd sources to use SPDX license identifiers Marek Behún (3): lib: Add xxhash support lib: add Zstandard decompression support fs: btrfs: add zstd decompression support fs/btrfs/Kconfig |1 + fs/btrfs/btrfs_tree.h |5 +- fs/btrfs/compression.c| 59 + include/linux/xxhash.h| 229 include/linux/zstd.h | 1147 + lib/Kconfig | 15 + lib/Makefile |2 + lib/xxhash.c | 467 +++ lib/zstd/Makefile |4 + lib/zstd/bitstream.h | 344 + lib/zstd/decompress.c | 2515 + lib/zstd/entropy_common.c | 213 lib/zstd/error_private.h | 43 + lib/zstd/fse.h| 545 lib/zstd/fse_decompress.c | 302 + lib/zstd/huf.h| 182 +++ lib/zstd/huf_decompress.c | 930 ++ lib/zstd/mem.h| 142 +++ lib/zstd/zstd_common.c| 65 + lib/zstd/zstd_internal.h | 253 lib/zstd/zstd_opt.h | 1004 +++ 21 files changed, 8465 insertions(+), 2 deletions(-) create mode 100644 include/linux/xxhash.h create mode 100644 include/linux/zstd.h create mode 100644 lib/xxhash.c create mode 100644 lib/zstd/Makefile create mode 100644 lib/zstd/bitstream.h create mode 100644 lib/zstd/decompress.c create mode 100644 lib/zstd/entropy_common.c create mode 100644 lib/zstd/error_private.h create mode 100644 lib/zstd/fse.h create mode 100644 lib/zstd/fse_decompress.c create mode 100644 lib/zstd/huf.h create mode 100644 lib/zstd/huf_decompress.c create mode 100644 lib/zstd/mem.h create mode 100644 lib/zstd/zstd_common.c create mode 100644 lib/zstd/zstd_internal.h create mode 100644 lib/zstd/zstd_opt.h -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
On 4/29/19 9:50 PM, Simon Goldschmidt wrote:
> Am 29.04.2019 um 21:23 schrieb Marek Vasut:
>> On 4/29/19 8:53 PM, Simon Goldschmidt wrote:
>>> Am 29.04.2019 um 20:33 schrieb Marek Vasut:
On 4/29/19 8:32 PM, Simon Goldschmidt wrote:
> Booting this board failed as the initial console isn't found since
> commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
> linux")
>
> The uart0 devicetree entry was missing "clock-frequency =
> <1>:"
> since that commit
>
> Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
> linux")
> Reported-by: rafael mello
> Signed-off-by: Simon Goldschmidt
> ---
>
> arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> index b620dd8dda..4be4083941 100644
> --- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> +++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> @@ -77,6 +77,7 @@
> };
> {
> + clock-frequency = <1>;
> u-boot,dm-pre-reloc;
> };
>
Applied, thanks.
>>>
>>> Wow, that was fast!
>>>
While at it, can we do something about Gen5 clock driver ?
>>>
>>> Which Gen5 clock driver, haha?
>>>
>>> I might find the time. Would you think the A10 driver would be a good
>>> point to start?
>>
>> For a read-only clock driver, based off DT, yes.
>
> Well, that would be a start, using the handoff values from Quartus.
>
> Would it make sense to convert the qts header output for gen5 to a dtsi
> format like A10? Not only the clock settings, but all information living
> in the qts directory would be better off in a devicetree.
I think so too :)
> And in addition, different FPGA configurations require different
> pinmux/iocsr configurations, which is a thing we haven't covered, yet. I
> don't want to update SPL just because an FPGA image decides to use
> loan-IO instead of a HPS GPIO...
Right ?
> However, the bindings from A10 handoff dtsi don't seem in a state to
> just copy them. (How does that handof dtsi get included anyway?)
The A10 bindings are ad-hoc mess for sure :)
(What do you mean, how?)
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] arm: sunxi: h6: fix reset using r_wdog
Hi Jagan, FYI the patch on ATF has been merged just now. It has been tested by André Przywara on A64, H5 and H6. https://github.com/ARM-software/arm-trusted-firmware/commit/523ab5be1a84e9aa15fb62c3a15a6338b01d3961 Thanks, Clement On Fri, 19 Apr 2019 at 11:19, Clément Péron wrote: > > Hi, > > On Fri, 19 Apr 2019 at 10:24, Jagan Teki wrote: > > > > On Fri, Apr 19, 2019 at 1:23 PM Clément Péron wrote: > > > > > > Hi, > > > > > > +Chen-Yu Tsai for test and +Icenowy because she try to contact AW > > > about this issue. > > > > > > On Wed, 17 Apr 2019 at 19:41, Clément Péron wrote: > > > > > > > > WDOG is broken for some H6 rev. The board is not > > > > reseted correctly. > > > > > > > > Use the R_WDOG instead. > > > > > > The issue is real except on Pine H64 and Rongpin RP-H6B which seems to > > > be NOT affected. > > > Lot of users on OrangePi boards (Lite2 / One Plus and 3) are > > > complaining about this issue. > > > > > > We perform a simple watchdog test on different board : > > > > > > Chen-Yu Tsai : > > > Pine h64 = H6 V200-AWIN H6448BA 7782 => OK > > > OrangePi Lite 2 = H6 V200-AWIN H8068BA 61C2 => KO > > > > > > Martin Ayotte : > > > PineH64 = H8069BA 6892 => OK > > > Orange Pi 3 = HA047BA 69W2 => KO > > > OPiOnePlus = H7310BA 6842 => KO > > > OPiLite2 = H6448BA 6662 => KO > > > > > > Clément Péron: > > > Beelink GS1 = H6 V200-AWIN H7309BA 6842 => KO > > > > > > After the series of result, Icenowy try to reach Allwinner about this > > > issue but they seems not interested to investigate it. > > > > > > I'm not sure if it's an HW errata or if there something misconfigured > > > but the result is here WDOG doesn't make these boards reboot. > > > And this should not happens ! > > > > How about Linux? same issue. > Yes, Linux use PSCI, call ATF and we have the same issue as ATF use > the watchdog to reboot. > > Clement ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
Am 29.04.2019 um 21:23 schrieb Marek Vasut:
On 4/29/19 8:53 PM, Simon Goldschmidt wrote:
Am 29.04.2019 um 20:33 schrieb Marek Vasut:
On 4/29/19 8:32 PM, Simon Goldschmidt wrote:
Booting this board failed as the initial console isn't found since
commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
linux")
The uart0 devicetree entry was missing "clock-frequency = <1>:"
since that commit
Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
linux")
Reported-by: rafael mello
Signed-off-by: Simon Goldschmidt
---
arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
index b620dd8dda..4be4083941 100644
--- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
+++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
@@ -77,6 +77,7 @@
};
{
+ clock-frequency = <1>;
u-boot,dm-pre-reloc;
};
Applied, thanks.
Wow, that was fast!
While at it, can we do something about Gen5 clock driver ?
Which Gen5 clock driver, haha?
I might find the time. Would you think the A10 driver would be a good
point to start?
For a read-only clock driver, based off DT, yes.
Well, that would be a start, using the handoff values from Quartus.
Would it make sense to convert the qts header output for gen5 to a dtsi
format like A10? Not only the clock settings, but all information living
in the qts directory would be better off in a devicetree.
And in addition, different FPGA configurations require different
pinmux/iocsr configurations, which is a thing we haven't covered, yet. I
don't want to update SPL just because an FPGA image decides to use
loan-IO instead of a HPS GPIO...
However, the bindings from A10 handoff dtsi don't seem in a state to
just copy them. (How does that handof dtsi get included anyway?)
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
On 4/29/19 8:53 PM, Simon Goldschmidt wrote:
> Am 29.04.2019 um 20:33 schrieb Marek Vasut:
>> On 4/29/19 8:32 PM, Simon Goldschmidt wrote:
>>> Booting this board failed as the initial console isn't found since
>>> commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
>>> linux")
>>>
>>> The uart0 devicetree entry was missing "clock-frequency = <1>:"
>>> since that commit
>>>
>>> Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from
>>> linux")
>>> Reported-by: rafael mello
>>> Signed-off-by: Simon Goldschmidt
>>> ---
>>>
>>> arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
>>> b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
>>> index b620dd8dda..4be4083941 100644
>>> --- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
>>> +++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
>>> @@ -77,6 +77,7 @@
>>> };
>>> {
>>> + clock-frequency = <1>;
>>> u-boot,dm-pre-reloc;
>>> };
>>>
>> Applied, thanks.
>
> Wow, that was fast!
>
>>
>> While at it, can we do something about Gen5 clock driver ?
>
> Which Gen5 clock driver, haha?
>
> I might find the time. Would you think the A10 driver would be a good
> point to start?
For a read-only clock driver, based off DT, yes.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
Am 29.04.2019 um 20:33 schrieb Marek Vasut:
On 4/29/19 8:32 PM, Simon Goldschmidt wrote:
Booting this board failed as the initial console isn't found since
commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
The uart0 devicetree entry was missing "clock-frequency = <1>:"
since that commit
Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
Reported-by: rafael mello
Signed-off-by: Simon Goldschmidt
---
arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
index b620dd8dda..4be4083941 100644
--- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
+++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
@@ -77,6 +77,7 @@
};
{
+ clock-frequency = <1>;
u-boot,dm-pre-reloc;
};
Applied, thanks.
Wow, that was fast!
While at it, can we do something about Gen5 clock driver ?
Which Gen5 clock driver, haha?
I might find the time. Would you think the A10 driver would be a good
point to start?
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] lib: Add xxhash support
On Mon, Apr 29, 2019 at 08:37:44PM +0200, Marek Behun wrote: > > Does xxhash.[ch] just come directly from Linux? If so, we should > > convert them to SPDX tags _unless_ Linux has already decided not to as > > they in turn come directly from another project and the kernel folks > > don't want to mess with it at all. Thanks! > > > > Hi Tom, > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/lib/xxhash.c?h=v5.1-rc7=5d2405227a9eaea48e8cc95756a06d407b11f141 > this is the only commit in the kernel touching the xxhash sources. The > author only says this: > > > I extracted it out from zstd since it is useful on its own. I copied > > the code from the upstream XXHash source repository and translated it > > into kernel style. > > I think we can add SPDX tags to both xxhash and zstd sources. Do you > agree? Shall I post v2? Sounds good to me, 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 v1 1/3] lib: Add xxhash support
> Does xxhash.[ch] just come directly from Linux? If so, we should > convert them to SPDX tags _unless_ Linux has already decided not to as > they in turn come directly from another project and the kernel folks > don't want to mess with it at all. Thanks! > Hi Tom, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/lib/xxhash.c?h=v5.1-rc7=5d2405227a9eaea48e8cc95756a06d407b11f141 this is the only commit in the kernel touching the xxhash sources. The author only says this: > I extracted it out from zstd since it is useful on its own. I copied > the code from the upstream XXHash source repository and translated it > into kernel style. I think we can add SPDX tags to both xxhash and zstd sources. Do you agree? Shall I post v2? Marek ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
On 4/29/19 8:32 PM, Simon Goldschmidt wrote:
> Booting this board failed as the initial console isn't found since
> commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
>
> The uart0 devicetree entry was missing "clock-frequency = <1>:"
> since that commit
>
> Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
> Reported-by: rafael mello
> Signed-off-by: Simon Goldschmidt
> ---
>
> arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> index b620dd8dda..4be4083941 100644
> --- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> +++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
> @@ -77,6 +77,7 @@
> };
>
> {
> + clock-frequency = <1>;
> u-boot,dm-pre-reloc;
> };
>
>
Applied, thanks.
While at it, can we do something about Gen5 clock driver ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dts: arm: socfpga: fix socfpga_de10_nano console
Booting this board failed as the initial console isn't found since
commit c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
The uart0 devicetree entry was missing "clock-frequency = <1>:"
since that commit
Fixes: c402e8170245 ("dts: arm: socfpga: merge gen5 devicetrees from linux")
Reported-by: rafael mello
Signed-off-by: Simon Goldschmidt
---
arch/arm/dts/socfpga_cyclone5_de10_nano.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
index b620dd8dda..4be4083941 100644
--- a/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
+++ b/arch/arm/dts/socfpga_cyclone5_de10_nano.dts
@@ -77,6 +77,7 @@
};
{
+ clock-frequency = <1>;
u-boot,dm-pre-reloc;
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
On 4/29/19 6:37 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski > > The support for DaVinci DM* SoCs has been dropped. The ifdefs in the > musb_hcd driver are no longer needed. Remove them. > > Signed-off-by: Bartosz Golaszewski Fine by me, feel free to take it via the TI tree. Acked-by: Marek Vasut -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: Zap lpc32xx_ssp driver-related code
Am 29.04.2019 um 19:57 schrieb Tom Rini: On Mon, Apr 29, 2019 at 10:22:07AM +0200, Simon Goldschmidt wrote: On Mon, Apr 29, 2019 at 2:22 AM Tom Rini wrote: On Sat, Apr 27, 2019 at 10:08:34PM +0200, Simon Goldschmidt wrote: On 22.04.19 23:00, Tom Rini wrote: On Mon, Apr 22, 2019 at 11:50:22PM +0300, Vladimir Zapolskiy wrote: Hi Jagan, Tom, On 04/19/2019 09:48 AM, Jagan Teki wrote: Dropped - lpc32xx_ssp driver - CONFIG_LPC32XX_SSP, LPC32XX_SSP_TIMEOUT items Dropped due to: - no active updates - no dm conversion - multiple pings for asking dm-conversion I really don't want to rush into moaning, however let me ask you to drop the reason given above as invalid, otherwise please clarify who were the addressees of these 'multiple pings'. Indeed. Since it was only last month or so that I setup a low-traffic list for maintainers / custodians for important issues like this, [..] Wait, which list are you talking about? Should I be monitoring anything else than this one? Ah, OK, so a new thing for my own mental checklist (which I ought to write down), there's now u-boot-custodians and u-boot-maintainers AT lists.denx.de, which are low volume custodian / maintainers only lists (they are public) to try and help avoid these "Hey, I maintain a board and just now found out I need to convert things for the next release?!?!?" problems, and similar. Right, I remember reading about the plan to have such lists here, but I failed to find them by searching the docs in git or searching the web. And if I fail to find them, it could be me, but just maybe I'm not the only maintainer not finding them ;-) I emailed everyone that's listed in MAINTAINERS when the lists opened. I think this in part means there may be a board entry or two missing your email? :) No, I'm not a maintainer of officially supported boards. Unfortunately, we're having non-mainlined private boards only. And my entry as socfpga maintainer/co-custodioan has just been aded now ;-) However, given the many companies out there using embedded Linux nowadays, I expect many such boards exist. Any while I understand we don't want to go into too much trouble of supporting such boards, I do think maintainers of such boards should be made aware of that list, too. I guess we could note it in the toplevel README file, but finding it on denx.de would certainly help, too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spi: Zap lpc32xx_ssp driver-related code
On Mon, Apr 29, 2019 at 10:22:07AM +0200, Simon Goldschmidt wrote: > On Mon, Apr 29, 2019 at 2:22 AM Tom Rini wrote: > > > > On Sat, Apr 27, 2019 at 10:08:34PM +0200, Simon Goldschmidt wrote: > > > > > > > > > On 22.04.19 23:00, Tom Rini wrote: > > > >On Mon, Apr 22, 2019 at 11:50:22PM +0300, Vladimir Zapolskiy wrote: > > > >>Hi Jagan, Tom, > > > >> > > > >>On 04/19/2019 09:48 AM, Jagan Teki wrote: > > > >>>Dropped > > > >>>- lpc32xx_ssp driver > > > >>>- CONFIG_LPC32XX_SSP, LPC32XX_SSP_TIMEOUT items > > > >>> > > > >>>Dropped due to: > > > >>>- no active updates > > > >>>- no dm conversion > > > >>>- multiple pings for asking dm-conversion > > > >> > > > >>I really don't want to rush into moaning, however let me ask you to drop > > > >>the reason given above as invalid, otherwise please clarify who were > > > >>the addressees of these 'multiple pings'. > > > > > > > >Indeed. Since it was only last month or so that I setup a low-traffic > > > >list for maintainers / custodians for important issues like this, [..] > > > > > > Wait, which list are you talking about? Should I be monitoring anything > > > else > > > than this one? > > > > Ah, OK, so a new thing for my own mental checklist (which I ought to > > write down), there's now u-boot-custodians and u-boot-maintainers AT > > lists.denx.de, which are low volume custodian / maintainers only lists > > (they are public) to try and help avoid these "Hey, I maintain a board > > and just now found out I need to convert things for the next > > release?!?!?" problems, and similar. > > Right, I remember reading about the plan to have such lists here, but > I failed to find them by searching the docs in git or searching the web. > > And if I fail to find them, it could be me, but just maybe I'm not the only > maintainer not finding them ;-) I emailed everyone that's listed in MAINTAINERS when the lists opened. I think this in part means there may be a board entry or two missing your email? :) -- 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 v1 1/3] lib: Add xxhash support
On Thu, Apr 25, 2019 at 06:07:42PM +0200, Marek Behún wrote:
> This adds the xxhash support from Linux. Files are almost identical to
> those added to Linux in commit 5d240522 ("lib: Add xxhash module") (they
> haven't been touched since in Linux). The only difference is to add some
> includes to be compatible with U-Boot.
>
> Signed-off-by: Marek Behún
> ---
> include/linux/xxhash.h | 259 +
> lib/Kconfig| 3 +
> lib/Makefile | 1 +
> lib/xxhash.c | 497 +
Does xxhash.[ch] just come directly from Linux? If so, we should
convert them to SPDX tags _unless_ Linux has already decided not to as
they in turn come directly from another project and the kernel folks
don't want to mess with it at all. 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 v1 2/3] lib: add Zstandard decompression support
On Thu, Apr 25, 2019 at 06:07:43PM +0200, Marek Behún wrote: > Add the zstd library from Linux kernel (only decompression support). > There are minimal changes to build with U-Boot, otherwise the files are > identical to Linux commit dc35da16 from March 2018, the files had not > been touched since in kernel. > > Signed-off-by: Marek Behún Similar to my comments on 1/3, we should SPDX convert or be clear why we aren't. 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] [PATCH v2] arm: dts: k3-am654: Sync IOPAD macros with Linux
Transition to the IOPAD macros as used in Linux in which the pin mux
mode is specified using a dedicated parameter while also dropping the
related MUX_MODEx macros that are no longer needed. This transition
will allow us to keep both Linux and U-Boot DTS in sync more easily.
While at it also align the file name of the include file itself and
update any references accordingly.
Signed-off-by: Andreas Dannenberg
---
Changes since initial submission:
- Also included renaming of the pinctrl header file to even better
align with Linux (Lokesh Vutla)
- Rebased & re-tested
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 48 +--
arch/arm/dts/k3-am654-r5-base-board.dts | 10 ++--
.../dt-bindings/pinctrl/{k3-am65.h => k3.h} | 15 +-
3 files changed, 31 insertions(+), 42 deletions(-)
rename include/dt-bindings/pinctrl/{k3-am65.h => k3.h} (73%)
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index c5d23d0203..f5c8253831 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -3,7 +3,7 @@
* Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
*/
-#include
+#include
#include
/ {
@@ -144,41 +144,41 @@
u-boot,dm-spl;
main_uart0_pins_default: main_uart0_pins_default {
pinctrl-single,pins = <
- AM65X_IOPAD(0x01e4, PIN_INPUT | MUX_MODE0) /*
(AF11) UART0_RXD */
- AM65X_IOPAD(0x01e8, PIN_OUTPUT | MUX_MODE0) /*
(AE11) UART0_TXD */
- AM65X_IOPAD(0x01ec, PIN_INPUT | MUX_MODE0) /*
(AG11) UART0_CTSn */
- AM65X_IOPAD(0x01f0, PIN_OUTPUT | MUX_MODE0) /*
(AD11) UART0_RTSn */
+ AM65X_IOPAD(0x01e4, PIN_INPUT, 0) /* (AF11)
UART0_RXD */
+ AM65X_IOPAD(0x01e8, PIN_OUTPUT, 0) /* (AE11)
UART0_TXD */
+ AM65X_IOPAD(0x01ec, PIN_INPUT, 0) /* (AG11)
UART0_CTSn */
+ AM65X_IOPAD(0x01f0, PIN_OUTPUT, 0) /* (AD11)
UART0_RTSn */
>;
u-boot,dm-spl;
};
main_mmc0_pins_default: main_mmc0_pins_default {
pinctrl-single,pins = <
- AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN | MUX_MODE0) /*
(B25) MMC0_CLK */
- AM65X_IOPAD(0x01aC, PIN_INPUT_PULLUP | MUX_MODE0) /*
(B27) MMC0_CMD */
- AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP | MUX_MODE0) /*
(A26) MMC0_DAT0 */
- AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP | MUX_MODE0) /*
(E25) MMC0_DAT1 */
- AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP | MUX_MODE0) /*
(C26) MMC0_DAT2 */
- AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP | MUX_MODE0) /*
(A25) MMC0_DAT3 */
- AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP | MUX_MODE0) /*
(E24) MMC0_DAT4 */
- AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP | MUX_MODE0) /*
(A24) MMC0_DAT5 */
- AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP | MUX_MODE0) /*
(B26) MMC0_DAT6 */
- AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP | MUX_MODE0) /*
(D25) MMC0_DAT7 */
- AM65X_IOPAD(0x01b0, PIN_INPUT | MUX_MODE0) /* (C25)
MMC0_DS */
+ AM65X_IOPAD(0x01a8, PIN_INPUT_PULLDOWN, 0) /*
(B25) MMC0_CLK */
+ AM65X_IOPAD(0x01aC, PIN_INPUT_PULLUP, 0)/*
(B27) MMC0_CMD */
+ AM65X_IOPAD(0x01a4, PIN_INPUT_PULLUP, 0)/*
(A26) MMC0_DAT0 */
+ AM65X_IOPAD(0x01a0, PIN_INPUT_PULLUP, 0)/*
(E25) MMC0_DAT1 */
+ AM65X_IOPAD(0x019c, PIN_INPUT_PULLUP, 0)/*
(C26) MMC0_DAT2 */
+ AM65X_IOPAD(0x0198, PIN_INPUT_PULLUP, 0)/*
(A25) MMC0_DAT3 */
+ AM65X_IOPAD(0x0194, PIN_INPUT_PULLUP, 0)/*
(E24) MMC0_DAT4 */
+ AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0)/*
(A24) MMC0_DAT5 */
+ AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0)/*
(B26) MMC0_DAT6 */
+ AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0)/*
(D25) MMC0_DAT7 */
+ AM65X_IOPAD(0x01b0, PIN_INPUT, 0)
/* (C25) MMC0_DS */
>;
u-boot,dm-spl;
};
main_mmc1_pins_default: main_mmc1_pins_default {
pinctrl-single,pins = <
- AM65X_IOPAD(0x02d4, PIN_INPUT_PULLDOWN | MUX_MODE0) /*
(C27) MMC1_CLK */
- AM65X_IOPAD(0x02d8, PIN_INPUT_PULLUP | MUX_MODE0) /*
(C28) MMC1_CMD */
- AM65X_IOPAD(0x02d0, PIN_INPUT_PULLUP | MUX_MODE0) /*
(D28) MMC1_DAT0 */
- AM65X_IOPAD(0x02cc, PIN_INPUT_PULLUP | MUX_MODE0) /*
(E27) MMC1_DAT1 */
-
Re: [U-Boot] Booting MX6 via Serial Download after DM conversion
On Thu, Apr 25, 2019 at 07:17:21AM +, Peng Fan wrote: > Hi Fabio, > > > -Original Message- > > From: Fabio Estevam [mailto:feste...@gmail.com] > > Sent: 2019年4月25日 6:23 > > To: Peng Fan > > Cc: Abel Vesa ; Stefano Babic ; > > Lukasz Majewski ; Michael Trimarchi > > ; dl-uboot-imx ; > > Jagan Teki ; Marcel Ziswiler > > ; U-Boot-Denx ; > > Adam Ford ; Ye Li ; Otavio Salvador > > ; Breno Matheus Lima > > Subject: Re: Booting MX6 via Serial Download after DM conversion > > > > Hi Peng, > > > > On Tue, Apr 23, 2019 at 11:18 PM Peng Fan wrote: > > > > > Not try this. > > > uuu should support SPL file being loaded, then if SPL could runs into > > > fastboot mode to interactive with uuu, then u-boot-dtb.img could be loaded > > I think. > > > > My colleague Breno tried to load SPL + u-boot-dtb.img using the UUU tool and > > it also failed. > > > > Could you please try to fix this regression? > > After check, it is not U-Boot issue, it is imx_usb should update to support > new u-boot-dtb.img. > > With your patch, file u-boot-dtb.img > u-boot-dtb.img: u-boot legacy uImage, U-Boot 2019.04-00664-gdbe9a81ff0\270, > Firmware/ARM, > Firmware Image (Not compressed), 490914 bytes, Thu Apr 25 07:26:46 2019, Load > Address: > 0x1780, Entry Point: 0x, Header CRC: 0xCBE07038, Data CRC: > 0x2C710405 > > without your patch, file u-boot-dtb.img > u-boot-dtb.img: Device Tree Blob version 17, size=1399, boot CPU=0, string > block size=139, DT > structure block size=1204 > > Actually now u-boot-dtb.img is a FIT image with a device tree wrapper. So > need fix imx_usb > to support both legacy and new image format. imx_usb is doing some checking of the second binary it sends along? That sounds odd to start with, is there some specific history there? 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] [PATCH 1/1] efi_loader: optional data in load options are binary
The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.
When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the Boot variable.
When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.
Here is an example session protocol:
=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
attributes: A-- (0x0001)
label: label1
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
data:
: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00 m.y. .o.p.t.i.o.
0010: 6e 00 00 00 n...
Boot00A1:
attributes: A-- (0x0001)
label: label2
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
data:
Signed-off-by: Heinrich Schuchardt
---
Resend to incorrect email address original post.
---
cmd/efidebug.c | 27 +--
include/efi_loader.h | 2 +-
lib/efi_loader/efi_bootmgr.c | 15 ---
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a40c4f4be2..e4cc92ec0e 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -545,7 +546,10 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
+ sizeof(struct efi_device_path); /* for END */
/* optional data */
- lo.optional_data = (u8 *)(argc == 6 ? "" : argv[6]);
+ if (argc < 6)
+ lo.optional_data = NULL;
+ else
+ lo.optional_data = (const u8 *)argv[6];
size = efi_serialize_load_option(, (u8 **));
if (!size) {
@@ -615,12 +619,13 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
/**
* show_efi_boot_opt_data() - dump UEFI load option
*
- * @id:Load option number
- * @data: Value of UEFI load option variable
+ * @id:load option number
+ * @data: value of UEFI load option variable
+ * @size: size of the boot option
*
* Decode the value of UEFI load option variable and print information.
*/
-static void show_efi_boot_opt_data(int id, void *data)
+static void show_efi_boot_opt_data(int id, void *data, size_t size)
{
struct efi_load_option lo;
char *label, *p;
@@ -638,7 +643,7 @@ static void show_efi_boot_opt_data(int id, void *data)
utf16_utf8_strncpy(, lo.label, label_len16);
printf("Boot%04X:\n", id);
- printf("\tattributes: %c%c%c (0x%08x)\n",
+ printf(" attributes: %c%c%c (0x%08x)\n",
/* ACTIVE */
lo.attributes & LOAD_OPTION_ACTIVE ? 'A' : '-',
/* FORCE RECONNECT */
@@ -646,14 +651,16 @@ static void show_efi_boot_opt_data(int id, void *data)
/* HIDDEN */
lo.attributes & LOAD_OPTION_HIDDEN ? 'H' : '-',
lo.attributes);
- printf("\tlabel: %s\n", label);
+ printf(" label: %s\n", label);
dp_str = efi_dp_str(lo.file_path);
- printf("\tfile_path: %ls\n", dp_str);
+ printf(" file_path: %ls\n", dp_str);
efi_free_pool(dp_str);
- printf("\tdata: %s\n", lo.optional_data);
-
+ printf(" data:\n");
+ print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
+ lo.optional_data, size + (u8 *)data -
+ (u8 *)lo.optional_data, true);
free(label);
}
@@ -686,7 +693,7 @@ static void show_efi_boot_opt(int id)
data));
}
if (ret == EFI_SUCCESS)
- show_efi_boot_opt_data(id, data);
+ show_efi_boot_opt_data(id, data, size);
else if (ret == EFI_NOT_FOUND)
printf("Boot%04X: not found\n", id);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 39ed8a6fa5..07b913d256 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -560,7 +560,7 @@ struct efi_load_option {
u16 file_path_length;
u16 *label;
struct efi_device_path *file_path;
- u8 *optional_data;
+ const u8 *optional_data;
};
void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 4ccba22875..7bf51874c1 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -53,19 +53,20 @@ void efi_deserialize_load_option(struct efi_load_option
*lo, u8 *data)
*/
unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data)
{
- unsigned long label_len, option_len;
+ unsigned long label_len;
unsigned long size;
u8 *p;
label_len = (u16_strlen(lo->label) + 1) * sizeof(u16);
-
Re: [U-Boot] [RESEND PATCH 0/3] arm: Introduce writel/readl_relaxed accessors
On Sun, Feb 10, 2019 at 9:49 PM Andre Przywara wrote: > > Hi, this is a resend of what I posted some weeks ago, just adding the > missing Signed-off-by: in patch 2/3, as pointed out by Philipp. I used > the opportunity to add his Reviewed-by: tags on the first two patches. > (Many thanks for that!) The rest is unchanged. > --- > > Admittedly this is the long way round to solve some nasty SPL code size > problem, but it looked beneficial to others as well, so here we go: > > arch/arm/include/asm/io.h looks like it's been around since the dawn of > time, and was more or less blindly copied from Linux. > We don't use and don't need most of the definitions, and mainline Linux > got rid of them anyway, so patch 1/3 cleans up this header file to > just contain what we need in U-Boot. > > Patch 2/3 introduces readl/writel_relaxed accessors, which are cheaper, > but more importantly save one (barrier) instruction per accessor. This > helps to bring down code size, since especially DRAM controller inits in > SPLs tend to do a lot of MMIO. > > Consequently patch 3/3 introduces them in the Allwinner H6 DRAM driver, > which reduces the SPL size by a whopping 2KB, due to a twist: > The AArch64 exception table needs to be 2KB aligned, but we don't do > anything special about it the linker script. So depending on where the > code before the vectors ends, we have potentially large padding: > At the moment this last address is 0x1824 for the H6, so the vectors can > only start at 0x2000. By reducing the code size before the vectors by just > (at least) 9 instructions, the vectors start at 0x1800 and we save most of > the padding. > > I understand that the proper solution is to fill the gap before the vectors > with code instead of NOPs, but I couldn't find any obvious way doing this > in the linker script. If anyone has any idea here, I am all ears. > > Cheers, > Andre. > > Andre Przywara (3): > arm: clean up asm/io.h > arm: introduce _relaxed MMIO accessors > sunxi: H6: use writel_relaxed for DRAM timing register accesses These have build issues with arm32, please send another series. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: optional data in load options are binary
The field boot OptionalData in structure _EFI_LOAD_OPTIONS is for binary
data.
When we use `efidebug boot add` we should convert the 5th argument from
UTF-8 to UTF-16 before putting it into the Boot variable.
When printing boot variables with `efidebug boot dump` we should support
the OptionalData being arbitrary binary data. So let's dump the data as
hexadecimal values.
Here is an example session protocol:
=> efidebug boot add 00a1 label1 scsi 0:1 doit1 'my option'
=> efidebug boot add 00a2 label2 scsi 0:1 doit2
=> efidebug boot dump
Boot00A0:
attributes: A-- (0x0001)
label: label1
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit1
data:
: 6d 00 79 00 20 00 6f 00 70 00 74 00 69 00 6f 00 m.y. .o.p.t.i.o.
0010: 6e 00 00 00 n...
Boot00A1:
attributes: A-- (0x0001)
label: label2
file_path: .../HD(1,MBR,0xeac4e18b,0x800,0x3fffe)/doit2
data:
Signed-off-by: Heinrich Schuchardt
---
cmd/efidebug.c | 27 +--
include/efi_loader.h | 2 +-
lib/efi_loader/efi_bootmgr.c | 15 ---
3 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a40c4f4be2..e4cc92ec0e 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -545,7 +546,10 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
+ sizeof(struct efi_device_path); /* for END */
/* optional data */
- lo.optional_data = (u8 *)(argc == 6 ? "" : argv[6]);
+ if (argc < 6)
+ lo.optional_data = NULL;
+ else
+ lo.optional_data = (const u8 *)argv[6];
size = efi_serialize_load_option(, (u8 **));
if (!size) {
@@ -615,12 +619,13 @@ static int do_efi_boot_rm(cmd_tbl_t *cmdtp, int flag,
/**
* show_efi_boot_opt_data() - dump UEFI load option
*
- * @id:Load option number
- * @data: Value of UEFI load option variable
+ * @id:load option number
+ * @data: value of UEFI load option variable
+ * @size: size of the boot option
*
* Decode the value of UEFI load option variable and print information.
*/
-static void show_efi_boot_opt_data(int id, void *data)
+static void show_efi_boot_opt_data(int id, void *data, size_t size)
{
struct efi_load_option lo;
char *label, *p;
@@ -638,7 +643,7 @@ static void show_efi_boot_opt_data(int id, void *data)
utf16_utf8_strncpy(, lo.label, label_len16);
printf("Boot%04X:\n", id);
- printf("\tattributes: %c%c%c (0x%08x)\n",
+ printf(" attributes: %c%c%c (0x%08x)\n",
/* ACTIVE */
lo.attributes & LOAD_OPTION_ACTIVE ? 'A' : '-',
/* FORCE RECONNECT */
@@ -646,14 +651,16 @@ static void show_efi_boot_opt_data(int id, void *data)
/* HIDDEN */
lo.attributes & LOAD_OPTION_HIDDEN ? 'H' : '-',
lo.attributes);
- printf("\tlabel: %s\n", label);
+ printf(" label: %s\n", label);
dp_str = efi_dp_str(lo.file_path);
- printf("\tfile_path: %ls\n", dp_str);
+ printf(" file_path: %ls\n", dp_str);
efi_free_pool(dp_str);
- printf("\tdata: %s\n", lo.optional_data);
-
+ printf(" data:\n");
+ print_hex_dump("", DUMP_PREFIX_OFFSET, 16, 1,
+ lo.optional_data, size + (u8 *)data -
+ (u8 *)lo.optional_data, true);
free(label);
}
@@ -686,7 +693,7 @@ static void show_efi_boot_opt(int id)
data));
}
if (ret == EFI_SUCCESS)
- show_efi_boot_opt_data(id, data);
+ show_efi_boot_opt_data(id, data, size);
else if (ret == EFI_NOT_FOUND)
printf("Boot%04X: not found\n", id);
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 39ed8a6fa5..07b913d256 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -560,7 +560,7 @@ struct efi_load_option {
u16 file_path_length;
u16 *label;
struct efi_device_path *file_path;
- u8 *optional_data;
+ const u8 *optional_data;
};
void efi_deserialize_load_option(struct efi_load_option *lo, u8 *data);
diff --git a/lib/efi_loader/efi_bootmgr.c b/lib/efi_loader/efi_bootmgr.c
index 4ccba22875..7bf51874c1 100644
--- a/lib/efi_loader/efi_bootmgr.c
+++ b/lib/efi_loader/efi_bootmgr.c
@@ -53,19 +53,20 @@ void efi_deserialize_load_option(struct efi_load_option
*lo, u8 *data)
*/
unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data)
{
- unsigned long label_len, option_len;
+ unsigned long label_len;
unsigned long size;
u8 *p;
label_len = (u16_strlen(lo->label) + 1) * sizeof(u16);
- option_len = strlen((char *)lo->optional_data);
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Sun, Apr 28, 2019 at 3:16 AM Tom Rini wrote: > > On Sat, Apr 27, 2019 at 09:47:21PM +0530, Jagan Teki wrote: > > Hi Tom, > > > > Please pull this PR. > > > > Summary: > > - H6 Beelink GS1 board (Clément) > > - Olimex A64-Teres-I board (Jonas) > > - sunxi build fix for CONFIG_CMD_PXE|DHCP (Ondrej) > > - _relaxed MMIO (Andre) > > NAK, this MMIO change (and readl/writel) stuff is causing tons of > warnings on arm32. km_kirkwood_128m16 is the first platform of many. > Thanks! I didn't notice since, my test was on arm64 targets, will send v2, thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] nand: davinci: remove dead code for dm644x
From: Bartosz Golaszewski
The support for DaVinci DM* SoCs has been dropped. The code that used
to be relevant to dm644x is no longer needed. Remove it.
Signed-off-by: Bartosz Golaszewski
---
drivers/mtd/nand/raw/davinci_nand.c | 39 -
1 file changed, 39 deletions(-)
diff --git a/drivers/mtd/nand/raw/davinci_nand.c
b/drivers/mtd/nand/raw/davinci_nand.c
index e6a84a52b4..cfa9b535c8 100644
--- a/drivers/mtd/nand/raw/davinci_nand.c
+++ b/drivers/mtd/nand/raw/davinci_nand.c
@@ -730,43 +730,6 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
return __raw_readl(_emif_regs->nandfsr) & 0x1;
}
-static void nand_flash_init(void)
-{
- /* This is for DM6446 EVM and *very* similar. DO NOT GROW THIS!
-* Instead, have your board_init() set EMIF timings, based on its
-* knowledge of the clocks and what devices are hooked up ... and
-* don't even do that unless no UBL handled it.
-*/
-#ifdef CONFIG_SOC_DM644X
- u_int32_t acfg1 = 0x3ffc;
-
- /*--*
-* NAND FLASH CHIP TIMEOUT @ 459 MHz *
-* *
-* AEMIF.CLK freq = PLL1/6 = 459/6 = 76.5 MHz*
-* AEMIF.CLK period = 1/76.5 MHz = 13.1 ns *
-* *
-*--*/
-acfg1 = 0
- | (0 << 31) /* selectStrobe */
- | (0 << 30) /* extWait */
- | (1 << 26) /* writeSetup 10 ns */
- | (3 << 20) /* writeStrobe 40 ns */
- | (1 << 17) /* writeHold10 ns */
- | (1 << 13) /* readSetup10 ns */
- | (5 << 7) /* readStrobe 60 ns */
- | (1 << 4) /* readHold 10 ns */
- | (3 << 2) /* turnAround ?? ns */
- | (0 << 0) /* asyncSize8-bit bus */
- ;
-
- __raw_writel(acfg1, _emif_regs->ab1cr); /* CS2 */
-
- /* NAND flash on CS2 */
- __raw_writel(0x0101, _emif_regs->nandfcr);
-#endif
-}
-
void davinci_nand_init(struct nand_chip *nand)
{
#if defined CONFIG_KEYSTONE_RBL_NAND
@@ -820,8 +783,6 @@ void davinci_nand_init(struct nand_chip *nand)
nand->write_buf = nand_davinci_write_buf;
nand->dev_ready = nand_davinci_dev_ready;
-
- nand_flash_init();
}
int board_nand_init(struct nand_chip *chip) __attribute__((weak));
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
From: Bartosz Golaszewski The support for DaVinci DM* SoCs has been dropped. The ifdefs in the musb_hcd driver are no longer needed. Remove them. Signed-off-by: Bartosz Golaszewski --- drivers/usb/musb/musb_hcd.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/usb/musb/musb_hcd.c b/drivers/usb/musb/musb_hcd.c index 2ee0f23b7e..1f2805270a 100644 --- a/drivers/usb/musb/musb_hcd.c +++ b/drivers/usb/musb/musb_hcd.c @@ -327,9 +327,7 @@ static int ctrlreq_out_data_phase(struct usb_device *dev, u32 len, void *buffer) csr = readw(>txcsr); csr |= MUSB_CSR0_TXPKTRDY; -#if !defined(CONFIG_SOC_DM365) csr |= MUSB_CSR0_H_DIS_PING; -#endif writew(csr, >txcsr); result = wait_until_ep0_ready(dev, MUSB_CSR0_TXPKTRDY); if (result < 0) @@ -352,9 +350,7 @@ static int ctrlreq_out_status_phase(struct usb_device *dev) /* Set the StatusPkt bit */ csr = readw(>txcsr); csr |= (MUSB_CSR0_TXPKTRDY | MUSB_CSR0_H_STATUSPKT); -#if !defined(CONFIG_SOC_DM365) csr |= MUSB_CSR0_H_DIS_PING; -#endif writew(csr, >txcsr); /* Wait until TXPKTRDY bit is cleared */ @@ -372,9 +368,7 @@ static int ctrlreq_in_status_phase(struct usb_device *dev) /* Set the StatusPkt bit and ReqPkt bit */ csr = MUSB_CSR0_H_REQPKT | MUSB_CSR0_H_STATUSPKT; -#if !defined(CONFIG_SOC_DM365) csr |= MUSB_CSR0_H_DIS_PING; -#endif writew(csr, >txcsr); result = wait_until_ep0_ready(dev, MUSB_CSR0_H_REQPKT); -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] arm: davinci: remove leftover code for dm* SoCs
From: Bartosz Golaszewski
The support for DaVinci DM* SoCs has been dropped a while ago. There's
still a lot of leftover code in mach-davinci though. Entirely remove
certain files and modify the common code to no longer reference
unsupported chips.
Note: all DaVinci platforms supported in u-boot now define SOC_DA8XX
but not all define SOC_DA850 (e.g. omapl138). We can safely remove
all ifdefs for the former, but let's leave the ones for the latter.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/cpu.c | 116 -
arch/arm/mach-davinci/dm355.c | 29 --
arch/arm/mach-davinci/dm365.c | 19 -
arch/arm/mach-davinci/dm365_lowlevel.c| 459 --
arch/arm/mach-davinci/dm644x.c| 80 ---
arch/arm/mach-davinci/dm646x.c| 25 -
.../mach-davinci/include/mach/davinci_misc.h | 4 +-
.../arm/mach-davinci/include/mach/emac_defs.h | 35 --
arch/arm/mach-davinci/include/mach/gpio.h | 14 +-
arch/arm/mach-davinci/include/mach/hardware.h | 216 -
arch/arm/mach-davinci/include/mach/i2c_defs.h | 4 -
.../mach-davinci/include/mach/syscfg_defs.h | 49 --
arch/arm/mach-davinci/misc.c | 5 +-
arch/arm/mach-davinci/psc.c | 76 ---
arch/arm/mach-davinci/spl.c | 5 -
15 files changed, 3 insertions(+), 1133 deletions(-)
delete mode 100644 arch/arm/mach-davinci/dm355.c
delete mode 100644 arch/arm/mach-davinci/dm365.c
delete mode 100644 arch/arm/mach-davinci/dm365_lowlevel.c
delete mode 100644 arch/arm/mach-davinci/dm644x.c
delete mode 100644 arch/arm/mach-davinci/dm646x.c
delete mode 100644 arch/arm/mach-davinci/include/mach/syscfg_defs.h
diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
index aca2f2961d..f97ad3fc74 100644
--- a/arch/arm/mach-davinci/cpu.c
+++ b/arch/arm/mach-davinci/cpu.c
@@ -27,25 +27,6 @@ DECLARE_GLOBAL_DATA_PTR;
#define PLLC_PLLDIV8 0x170
#define PLLC_PLLDIV9 0x174
-/* SOC-specific pll info */
-#ifdef CONFIG_SOC_DM355
-#define ARM_PLLDIV PLLC_PLLDIV1
-#define DDR_PLLDIV PLLC_PLLDIV1
-#endif
-
-#ifdef CONFIG_SOC_DM644X
-#define ARM_PLLDIV PLLC_PLLDIV2
-#define DSP_PLLDIV PLLC_PLLDIV1
-#define DDR_PLLDIV PLLC_PLLDIV2
-#endif
-
-#ifdef CONFIG_SOC_DM646X
-#define DSP_PLLDIV PLLC_PLLDIV1
-#define ARM_PLLDIV PLLC_PLLDIV2
-#define DDR_PLLDIV PLLC_PLLDIV1
-#endif
-
-#ifdef CONFIG_SOC_DA8XX
unsigned int sysdiv[9] = {
PLLC_PLLDIV1, PLLC_PLLDIV2, PLLC_PLLDIV3, PLLC_PLLDIV4, PLLC_PLLDIV5,
PLLC_PLLDIV6, PLLC_PLLDIV7, PLLC_PLLDIV8, PLLC_PLLDIV9
@@ -110,103 +91,6 @@ int set_cpu_clk_info(void)
return 0;
}
-#else /* CONFIG_SOC_DA8XX */
-
-static unsigned pll_div(volatile void *pllbase, unsigned offset)
-{
- u32 div;
-
- div = REG(pllbase + offset);
- return (div & BIT(15)) ? (1 + (div & 0x1f)) : 1;
-}
-
-static inline unsigned pll_prediv(volatile void *pllbase)
-{
-#ifdef CONFIG_SOC_DM355
- /* this register read seems to fail on pll0 */
- if (pllbase == (volatile void *)DAVINCI_PLL_CNTRL0_BASE)
- return 8;
- else
- return pll_div(pllbase, PLLC_PREDIV);
-#elif defined(CONFIG_SOC_DM365)
- return pll_div(pllbase, PLLC_PREDIV);
-#endif
- return 1;
-}
-
-static inline unsigned pll_postdiv(volatile void *pllbase)
-{
-#if defined(CONFIG_SOC_DM355) || defined(CONFIG_SOC_DM365)
- return pll_div(pllbase, PLLC_POSTDIV);
-#elif defined(CONFIG_SOC_DM6446)
- if (pllbase == (volatile void *)DAVINCI_PLL_CNTRL0_BASE)
- return pll_div(pllbase, PLLC_POSTDIV);
-#endif
- return 1;
-}
-
-static unsigned pll_sysclk_mhz(unsigned pll_addr, unsigned div)
-{
- volatile void *pllbase = (volatile void *) pll_addr;
-#ifdef CONFIG_SOC_DM646X
- unsignedbase = CONFIG_REFCLK_FREQ / 1000;
-#else
- unsignedbase = CONFIG_SYS_HZ_CLOCK / 1000;
-#endif
-
- /* the PLL might be bypassed */
- if (readl(pllbase + PLLC_PLLCTL) & BIT(0)) {
- base /= pll_prediv(pllbase);
-#if defined(CONFIG_SOC_DM365)
- base *= 2 * (readl(pllbase + PLLC_PLLM) & 0x0ff);
-#else
- base *= 1 + (REG(pllbase + PLLC_PLLM) & 0x0ff);
-#endif
- base /= pll_postdiv(pllbase);
- }
- return DIV_ROUND_UP(base, 1000 * pll_div(pllbase, div));
-}
-
-#ifdef DAVINCI_DM6467EVM
-unsigned int davinci_arm_clk_get()
-{
- return pll_sysclk_mhz(DAVINCI_PLL_CNTRL0_BASE, ARM_PLLDIV) * 100;
-}
-#endif
-
-#if defined(CONFIG_SOC_DM365)
-unsigned int davinci_clk_get(unsigned int div)
-{
- return pll_sysclk_mhz(DAVINCI_PLL_CNTRL0_BASE, div) * 100;
-}
-#endif
-
-int set_cpu_clk_info(void)
-{
- unsigned int pllbase = DAVINCI_PLL_CNTRL0_BASE;
-#if defined(CONFIG_SOC_DM365)
- pllbase = DAVINCI_PLL_CNTRL1_BASE;
-#endif
- gd->bd->bi_arm_freq = pll_sysclk_mhz(pllbase,
[U-Boot] [PATCH 2/5] arm: davinci: remove dead code for PHYs used by DaVinci DM* boards
From: Bartosz Golaszewski
The support for DaVinci DM* boards has been dropped a while ago. The
code for all those PHYs is no longer used and they have their own
proper PHY drivers in drivers/net/phy anyway. Remove all dead code.
Signed-off-by: Bartosz Golaszewski
---
arch/arm/mach-davinci/Makefile| 1 -
arch/arm/mach-davinci/dp83848.c | 127 --
arch/arm/mach-davinci/et1011c.c | 41 --
.../arm/mach-davinci/include/mach/emac_defs.h | 21 ---
arch/arm/mach-davinci/ksz8873.c | 52 ---
arch/arm/mach-davinci/lxt972.c| 112 ---
6 files changed, 354 deletions(-)
delete mode 100644 arch/arm/mach-davinci/dp83848.c
delete mode 100644 arch/arm/mach-davinci/et1011c.c
delete mode 100644 arch/arm/mach-davinci/ksz8873.c
delete mode 100644 arch/arm/mach-davinci/lxt972.c
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index df43b1d7e0..6887fe05dd 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_SOC_DM365) += dm365.o
obj-$(CONFIG_SOC_DM644X) += dm644x.o
obj-$(CONFIG_SOC_DM646X) += dm646x.o
obj-$(CONFIG_SOC_DA850)+= da850_pinmux.o
-obj-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o et1011c.o ksz8873.o
ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SPL_FRAMEWORK)+= spl.o
diff --git a/arch/arm/mach-davinci/dp83848.c b/arch/arm/mach-davinci/dp83848.c
deleted file mode 100644
index 7115d7bad2..00
--- a/arch/arm/mach-davinci/dp83848.c
+++ /dev/null
@@ -1,127 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * National Semiconductor DP83848 PHY Driver for TI DaVinci
- * (TMS320DM644x) based boards.
- *
- * Copyright (C) 2007 Sergey Kubushyn
- *
- *
- */
-
-#include
-#include
-#include
-#include
-#include "../../../drivers/net/ti/davinci_emac.h"
-
-#ifdef CONFIG_DRIVER_TI_EMAC
-
-#ifdef CONFIG_CMD_NET
-
-int dp83848_is_phy_connected(int phy_addr)
-{
- u_int16_t id1, id2;
-
- if (!davinci_eth_phy_read(phy_addr, DP83848_PHYID1_REG, ))
- return(0);
- if (!davinci_eth_phy_read(phy_addr, DP83848_PHYID2_REG, ))
- return(0);
-
- if ((id1 == DP83848_PHYID1_OUI) && (id2 == DP83848_PHYID2_OUI))
- return(1);
-
- return(0);
-}
-
-int dp83848_get_link_speed(int phy_addr)
-{
- u_int16_t tmp;
- volatile emac_regs* emac = (emac_regs *)EMAC_BASE_ADDR;
-
- if (!davinci_eth_phy_read(phy_addr, DP83848_STAT_REG, ))
- return(0);
-
- if (!(tmp & DP83848_LINK_STATUS)) /* link up? */
- return(0);
-
- if (!davinci_eth_phy_read(phy_addr, DP83848_PHY_STAT_REG, ))
- return(0);
-
- /* Speed doesn't matter, there is no setting for it in EMAC... */
- if (tmp & DP83848_DUPLEX) {
- /* set DM644x EMAC for Full Duplex */
- emac->MACCONTROL = EMAC_MACCONTROL_MIIEN_ENABLE |
- EMAC_MACCONTROL_FULLDUPLEX_ENABLE;
- } else {
- /*set DM644x EMAC for Half Duplex */
- emac->MACCONTROL = EMAC_MACCONTROL_MIIEN_ENABLE;
- }
-
- return(1);
-}
-
-
-int dp83848_init_phy(int phy_addr)
-{
- int ret = 1;
-
- if (!dp83848_get_link_speed(phy_addr)) {
- /* Try another time */
- udelay(10);
- ret = dp83848_get_link_speed(phy_addr);
- }
-
- /* Disable PHY Interrupts */
- davinci_eth_phy_write(phy_addr, DP83848_PHY_INTR_CTRL_REG, 0);
-
- return(ret);
-}
-
-
-int dp83848_auto_negotiate(int phy_addr)
-{
- u_int16_t tmp;
-
-
- if (!davinci_eth_phy_read(phy_addr, DP83848_CTL_REG, ))
- return(0);
-
- /* Restart Auto_negotiation */
- tmp &= ~DP83848_AUTONEG;/* remove autonegotiation enable */
- tmp |= DP83848_ISOLATE; /* Electrically isolate PHY */
- davinci_eth_phy_write(phy_addr, DP83848_CTL_REG, tmp);
-
- /* Set the Auto_negotiation Advertisement Register
-* MII advertising for Next page, 100BaseTxFD and HD,
-* 10BaseTFD and HD, IEEE 802.3
-*/
- tmp = DP83848_NP | DP83848_TX_FDX | DP83848_TX_HDX |
- DP83848_10_FDX | DP83848_10_HDX | DP83848_AN_IEEE_802_3;
- davinci_eth_phy_write(phy_addr, DP83848_ANA_REG, tmp);
-
-
- /* Read Control Register */
- if (!davinci_eth_phy_read(phy_addr, DP83848_CTL_REG, ))
- return(0);
-
- tmp |= DP83848_SPEED_SELECT | DP83848_AUTONEG | DP83848_DUPLEX_MODE;
- davinci_eth_phy_write(phy_addr, DP83848_CTL_REG, tmp);
-
- /* Restart Auto_negotiation */
- tmp |= DP83848_RESTART_AUTONEG;
- davinci_eth_phy_write(phy_addr, DP83848_CTL_REG, tmp);
-
- /*check AutoNegotiate complete */
- udelay(1);
-
[U-Boot] [PATCH 1/5] net: davinci_emac: drop support for unused PHYs
From: Bartosz Golaszewski
The boards with SoCs from the DaVinci DM* family used to come with
different PHYs that needed special support implemented in mach-davinci.
Since the support for these chips has long been removed, we can now
drop this unnused code from the emac driver.
Signed-off-by: Bartosz Golaszewski
---
drivers/net/ti/davinci_emac.c | 55 ---
1 file changed, 6 insertions(+), 49 deletions(-)
diff --git a/drivers/net/ti/davinci_emac.c b/drivers/net/ti/davinci_emac.c
index bb879d8d4f..9d53984973 100644
--- a/drivers/net/ti/davinci_emac.c
+++ b/drivers/net/ti/davinci_emac.c
@@ -816,55 +816,12 @@ int davinci_emac_initialize(void)
phy_id |= tmp & 0x;
- switch (phy_id) {
-#ifdef PHY_KSZ8873
- case PHY_KSZ8873:
- sprintf(phy[i].name, "KSZ8873 @ 0x%02x",
- active_phy_addr[i]);
- phy[i].init = ksz8873_init_phy;
- phy[i].is_phy_connected = ksz8873_is_phy_connected;
- phy[i].get_link_speed = ksz8873_get_link_speed;
- phy[i].auto_negotiate = ksz8873_auto_negotiate;
- break;
-#endif
-#ifdef PHY_LXT972
- case PHY_LXT972:
- sprintf(phy[i].name, "LXT972 @ 0x%02x",
- active_phy_addr[i]);
- phy[i].init = lxt972_init_phy;
- phy[i].is_phy_connected = lxt972_is_phy_connected;
- phy[i].get_link_speed = lxt972_get_link_speed;
- phy[i].auto_negotiate = lxt972_auto_negotiate;
- break;
-#endif
-#ifdef PHY_DP83848
- case PHY_DP83848:
- sprintf(phy[i].name, "DP83848 @ 0x%02x",
- active_phy_addr[i]);
- phy[i].init = dp83848_init_phy;
- phy[i].is_phy_connected = dp83848_is_phy_connected;
- phy[i].get_link_speed = dp83848_get_link_speed;
- phy[i].auto_negotiate = dp83848_auto_negotiate;
- break;
-#endif
-#ifdef PHY_ET1011C
- case PHY_ET1011C:
- sprintf(phy[i].name, "ET1011C @ 0x%02x",
- active_phy_addr[i]);
- phy[i].init = gen_init_phy;
- phy[i].is_phy_connected = gen_is_phy_connected;
- phy[i].get_link_speed = et1011c_get_link_speed;
- phy[i].auto_negotiate = gen_auto_negotiate;
- break;
-#endif
- default:
- sprintf(phy[i].name, "GENERIC @ 0x%02x",
- active_phy_addr[i]);
- phy[i].init = gen_init_phy;
- phy[i].is_phy_connected = gen_is_phy_connected;
- phy[i].get_link_speed = gen_get_link_speed;
- phy[i].auto_negotiate = gen_auto_negotiate;
- }
+ sprintf(phy[i].name, "GENERIC @ 0x%02x",
+ active_phy_addr[i]);
+ phy[i].init = gen_init_phy;
+ phy[i].is_phy_connected = gen_is_phy_connected;
+ phy[i].get_link_speed = gen_get_link_speed;
+ phy[i].auto_negotiate = gen_auto_negotiate;
debug("Ethernet PHY: %s\n", phy[i].name);
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] arm: remove leftover code for dm* SoCs
From: Bartosz Golaszewski
Commit 6761946fb716 ("arm: Remove unmaintained davinci boards") removed
support for certain DaVinci platforms. We still want to support the
da850 chips though and I'm currently working on converting all remaining
drivers to using the driver model (please don't remove it yet :)).
This series is the first step: let's remove all leftover dead code. This
will make things easier when adding support for driver model to NAND and
EMAC drivers.
Bartosz Golaszewski (5):
net: davinci_emac: drop support for unused PHYs
arm: davinci: remove dead code for PHYs used by DaVinci DM* boards
nand: davinci: remove dead code for dm644x
usb: musb_hcd: remove unnecessary ifdefs for dm* SoCs
arm: davinci: remove leftover code for dm* SoCs
arch/arm/mach-davinci/Makefile| 1 -
arch/arm/mach-davinci/cpu.c | 116 -
arch/arm/mach-davinci/dm355.c | 29 --
arch/arm/mach-davinci/dm365.c | 19 -
arch/arm/mach-davinci/dm365_lowlevel.c| 459 --
arch/arm/mach-davinci/dm644x.c| 80 ---
arch/arm/mach-davinci/dm646x.c| 25 -
arch/arm/mach-davinci/dp83848.c | 127 -
arch/arm/mach-davinci/et1011c.c | 41 --
.../mach-davinci/include/mach/davinci_misc.h | 4 +-
.../arm/mach-davinci/include/mach/emac_defs.h | 56 ---
arch/arm/mach-davinci/include/mach/gpio.h | 14 +-
arch/arm/mach-davinci/include/mach/hardware.h | 216 -
arch/arm/mach-davinci/include/mach/i2c_defs.h | 4 -
.../mach-davinci/include/mach/syscfg_defs.h | 49 --
arch/arm/mach-davinci/ksz8873.c | 52 --
arch/arm/mach-davinci/lxt972.c| 112 -
arch/arm/mach-davinci/misc.c | 5 +-
arch/arm/mach-davinci/psc.c | 76 ---
arch/arm/mach-davinci/spl.c | 5 -
drivers/mtd/nand/raw/davinci_nand.c | 39 --
drivers/net/ti/davinci_emac.c | 55 +--
drivers/usb/musb/musb_hcd.c | 6 -
23 files changed, 9 insertions(+), 1581 deletions(-)
delete mode 100644 arch/arm/mach-davinci/dm355.c
delete mode 100644 arch/arm/mach-davinci/dm365.c
delete mode 100644 arch/arm/mach-davinci/dm365_lowlevel.c
delete mode 100644 arch/arm/mach-davinci/dm644x.c
delete mode 100644 arch/arm/mach-davinci/dm646x.c
delete mode 100644 arch/arm/mach-davinci/dp83848.c
delete mode 100644 arch/arm/mach-davinci/et1011c.c
delete mode 100644 arch/arm/mach-davinci/include/mach/syscfg_defs.h
delete mode 100644 arch/arm/mach-davinci/ksz8873.c
delete mode 100644 arch/arm/mach-davinci/lxt972.c
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Add NanoPi R1 config
Please see attachment. I'm sending this defconfig and dts files because it wasn't in u-boot.git. nanopi_r1_defconfig Description: Binary data sun8i-h3-nanopi-r1.dts Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] simple-bus: add DM_FLAG_PRE_RELOC flag to simple-bus driver
Hello Heiko, On Mon, 2019-04-29 at 11:40 +0200, Heiko Schocher wrote: > Hello Simon, > > Am 22.04.2019 um 04:38 schrieb s...@google.com: > > On Wed, Apr 10, 2019 at 8:46 PM Lukas Auer > > wrote: > > > Boards such as qemu-riscv, which receive their device tree at runtime, > > > for example from QEMU or firmware, are unable to add the appropriate > > > device tree properties to make devices available pre relocation. > > > Instead, they must rely on the DM_FLAG_PRE_RELOC flag to be set for the > > > required drivers. > > > > > > Add the DM_FLAG_PRE_RELOC flag to the simple-bus driver to make devices > > > under it with drivers that have set the flag as well available pre > > > relocation for these boards. > > > > > > Signed-off-by: Lukas Auer > > > --- > > > > > > drivers/core/simple-bus.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > > Reviewed-by: Bin Meng > > > > Tested on QEMU RISC-V 'virt' target with 2 cores, M-mode > > Tested-by: Bin Meng > > > > Applied to u-boot-dm, thanks! > > I just tested current mainline U-Boot: > > * 6aebc0d11a - (origin/master, origin/HEAD) Revert "fs: btrfs: fix false > negatives in ROOT_ITEM > search" (vor 2 Tagen) > > on a not yet mainlined imx6ull port, and after SPL loaded U-Boot > into RAM I see no more output. After git bisect session, this > commit was found as the reason for breaking U-Boot. > > After reverting this commit, board boots fine again... > > Any Idea what could be wrong ? > > Thanks! > > bye, > Heiko Can you attach a debugger to the system? I can't think of anything apparent that this patch might have broken. Is U-Boot perhaps using a different serial console, which was not available without this patch? Thanks, Lukas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] smbios: add parsing API
Am Mo., 29. Apr. 2019 um 17:41 Uhr schrieb Simon Glass : > > Hi, > > On Thu, 25 Apr 2019 at 04:09, Alexander Graf wrote: > > > > > > On 16.04.19 13:38, Christian Gmeiner wrote: > > > Add an very simple API to be able to access SMBIOS strings > > > like vendor, model and bios version. > > > > > > Signed-off-by: Christian Gmeiner > > > --- > > > include/smbios.h| 37 ++ > > > lib/Kconfig | 6 ++ > > > lib/Makefile| 1 + > > > lib/smbios-parser.c | 162 > > > 4 files changed, 206 insertions(+) > > > create mode 100644 lib/smbios-parser.c > > Can you please also add a test for each of these functions, with sample data. > > BTW here is some code to write fake tables in case it helps: > > https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1062212/6/chromeos-config/libcros_config/identity_x86.cc Will try my best :) -- greets -- Christian Gmeiner, MSc https://christian-gmeiner.info ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram
Hi, On Mon, 29 Apr 2019 at 07:19, Tom Rini wrote: > > On Mon, Apr 29, 2019 at 03:06:39PM +0200, Heiko Schocher wrote: > > Hello Simon, > > > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > > >Am 25.04.2019 um 12:50 schrieb Tom Rini: > > >>On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > > >>>On Thu, Apr 25, 2019 at 1:59 AM Simon Glass wrote: > > > > Hi, > > > > On Wed, 24 Apr 2019 at 05:53, Tom Rini wrote: > > > > > >On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > >>On Wed, Apr 24, 2019 at 1:27 PM Tom Rini wrote: > > >>> > > >>>On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > wrote: > > > > > >If the malloc range passed to mem_malloc_init() is at the end of > > >address > > >range and 'start + size' overflows to 0, following allocations > > >fail as > > >mem_malloc_end is zero (which looks like uninitialized). > > > > > >Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > >Signed-off-by: Simon Goldschmidt > > >--- > > > > > >Changes in v4: None > > >Changes in v3: None > > > > > > common/dlmalloc.c | 4 > > > 1 file changed, 4 insertions(+) > > > > Reviewed-by: Simon Glass > > >>> > > >>>So, the problem with this patch is that it increases the generic > > >>>malloc > > >>>code size ever so slightly and blows up smartweb :( > > >> > > >>Ehrm, ok, so how do we proceed? > > > > > >A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > >if, of the malloc functions it doesn't discard there's something that > > >maybe could be optimized somewhere? > > > > I wonder if we should have a Kconfig option like SPL_CHECKS which > > enables these sorts of minor checks, which may only fix one board at > > the cost of code size? > > > > Then it could be enabled by default, but disabled on this board? > > >>> > > >>>For a bigger change, this might be an idea, but for a change that I can > > >>>cut > > >>>down to 16 or even 8 bytes code size increasement, I don't think having a > > >>>new option would be good. > > >>> > > >>>Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > > >>>are you using to get the size error? It works for me on Debian 9 but > > >>>doesn't > > >>>work with Ubuntu (both times, default cross compiler toolchain > > >>>installed). > > >> > > >>I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > > > >Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 > > >seems to produce smaller binaries (I thought they were getting smaller > > >with new versions, not larger). > > > > > >However, I've stripped down that patch to +8 Bytes only and sent v5. > > > > Thanks! > > > > Sorry for digging so late in, but I was on vacation... > > > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > > to convert it to DM to get rid of some compiler warnings ... > > > > I am unsure what to do now with this hardware ... > > Well, with regards to SPL + DM, this is one of the cases wherein we just > have-to allow for the SPL driver code at least to be a one-off. If the > "whatever ROM loads of our code" stage can set things up enough such > that we can hand off to a full U-Boot, that's great. If not, this is > then a case where TPL comes in to play, and that really is as one-off as > needed, to load a more general SPL and so forth. I think DM in SPL is a good thing, so long as there is space. If not, then we should allow non-DM also. I wonder if we need our policy to be written down somewhere? > > But, I'm fine with saying smartweb keeps and maintains whatever SPL code > it needs to use. It's just that in this case, it's not at all a DM > thing, it's a change in malloc. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] smbios: add parsing API
Am Mo., 29. Apr. 2019 um 17:35 Uhr schrieb Alexander Graf :
>
>
> On 29.04.19 16:29, Christian Gmeiner wrote:
> > Hi
> >
> > Am Do., 25. Apr. 2019 um 12:09 Uhr schrieb Alexander Graf :
> >>
> >> On 16.04.19 13:38, Christian Gmeiner wrote:
> >>> Add an very simple API to be able to access SMBIOS strings
> >>> like vendor, model and bios version.
> >>>
> >>> Signed-off-by: Christian Gmeiner
> >>> ---
> >>> include/smbios.h| 37 ++
> >>> lib/Kconfig | 6 ++
> >>> lib/Makefile| 1 +
> >>> lib/smbios-parser.c | 162
> >>> 4 files changed, 206 insertions(+)
> >>> create mode 100644 lib/smbios-parser.c
> >>>
> >>> diff --git a/include/smbios.h b/include/smbios.h
> >>> index 97b9ddce23..ad44e54245 100644
> >>> --- a/include/smbios.h
> >>> +++ b/include/smbios.h
> >>> @@ -237,4 +237,41 @@ typedef int (*smbios_write_type)(ulong *addr, int
> >>> handle);
> >>> */
> >>> ulong write_smbios_table(ulong addr);
> >>>
> >>> +
> >>> +struct smbios_parser;
> >>> +
> >>> +/**
> >>> + * smbios_parser_create() - Create smbios parser
> >>> + *
> >>> + * @addr:start address to search for SMBIOS structure
> >>> + * @len: size of search area
> >>> + * @return: NULL or valid pointer to a struct smbios_parser
> >>> + */
> >>> +struct smbios_parser *smbios_parser_create(unsigned int addr, unsigned
> >>> int len);
> >>> +
> >>> +/**
> >>> + * smbios_parser_destroy() - Destroy smbios parser
> >>> + *
> >>> + * @p: pointer to a struct smbios_parser
> >>> + */
> >>> +void smbios_parser_destroy(struct smbios_parser *p);
> >>> +
> >>> +/**
> >>> + * smbios_header() - Search for SMBIOS header type
> >>> + *
> >>> + * @p: pointer to a struct smbios_parser
> >>> + * @type:SMBIOS type
> >>> + * @return: NULL or a valid pointer to a struct smbios_header
> >>> + */
> >>> +struct smbios_header *smbios_header(const struct smbios_parser *p, int
> >>> type);
> >>> +
> >>> +/**
> >>> + * smbios_string() - Return string from SMBIOS
> >>> + *
> >>> + * @header: pointer to struct smbios_header
> >>> + * @index: string index
> >>> + * @return: NULL or a valid const char pointer
> >>> + */
> >>> +const char *smbios_string(const struct smbios_header *header, int index);
> >>> +
> >>> #endif /* _SMBIOS_H_ */
> >>> diff --git a/lib/Kconfig b/lib/Kconfig
> >>> index 2120216593..59aafc63a7 100644
> >>> --- a/lib/Kconfig
> >>> +++ b/lib/Kconfig
> >>> @@ -432,6 +432,12 @@ config SMBIOS_PRODUCT_NAME
> >>>
> >>> endmenu
> >>>
> >>> +config SMBIOS_PARSER
> >>> + bool "SMBIOS parser"
> >>> + default n
> >>> + help
> >>> + A simple parser for SMBIOS data.
> >>> +
> >>> source lib/efi/Kconfig
> >>> source lib/efi_loader/Kconfig
> >>> source lib/optee/Kconfig
> >>> diff --git a/lib/Makefile b/lib/Makefile
> >>> index 47829bfed5..f095bd420a 100644
> >>> --- a/lib/Makefile
> >>> +++ b/lib/Makefile
> >>> @@ -34,6 +34,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o
> >>> obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
> >>> obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
> >>> obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o
> >>> +obj-$(CONFIG_SMBIOS_PARSER) += smbios-parser.o
> >>> obj-$(CONFIG_IMAGE_SPARSE) += image-sparse.o
> >>> obj-y += ldiv.o
> >>> obj-$(CONFIG_MD5) += md5.o
> >>> diff --git a/lib/smbios-parser.c b/lib/smbios-parser.c
> >>> new file mode 100644
> >>> index 00..b24fd7210c
> >>> --- /dev/null
> >>> +++ b/lib/smbios-parser.c
> >>> @@ -0,0 +1,162 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright (C) 2019, Bachmann electronic GmbH
> >>> + */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +struct smbios_parser {
> >>> + void *search_area;
> >>> + unsigned int search_area_len;
> >>> + struct smbios_entry *entry;
> >>> + void *data;
> >>> +};
> >>> +
> >>> +static inline int verify_checksum(const struct smbios_entry *e)
> >>> +{
> >>> + /*
> >>> + * Checksums for SMBIOS tables are calculated to have a value, so
> >>> that
> >>> + * the sum over all bytes yields zero (using unsigned 8 bit
> >>> arithmetic).
> >>> + */
> >>> + u8 *byte = (u8 *)e;
> >>> + u8 sum = 0;
> >>> +
> >>> + for (int i = 0; i < e->length; i++)
> >>> + sum += byte[i];
> >>> +
> >>> + return sum;
> >>> +}
> >>> +
> >>> +static struct smbios_entry *find_smbios_entry(const struct smbios_parser
> >>> *p)
> >>> +{
> >>> + static const char sm_sig[] = "_SM_";
> >>> + u8 *buf = (u8 *)p->search_area;
> >>> + const u8 *end = (u8 *)p->search_area + p->search_area_len;
> >>> + struct smbios_entry *entry = NULL;
> >>> +
> >>> + /* look for smbios entry */
> >>> + while (buf < end) {
> >>
> >> Don't you have a way to pass the DMI pointer directly, maybe using cbfs?
> >> Searching through the SMBIOS search area is so 1990s (and pretty much
> >> only works on x86).
> >>
> > Coreboot adds a smbios cbmem entry
Re: [U-Boot] [PATCH 1/2] smbios: add parsing API
Hi, On Thu, 25 Apr 2019 at 04:09, Alexander Graf wrote: > > > On 16.04.19 13:38, Christian Gmeiner wrote: > > Add an very simple API to be able to access SMBIOS strings > > like vendor, model and bios version. > > > > Signed-off-by: Christian Gmeiner > > --- > > include/smbios.h| 37 ++ > > lib/Kconfig | 6 ++ > > lib/Makefile| 1 + > > lib/smbios-parser.c | 162 > > 4 files changed, 206 insertions(+) > > create mode 100644 lib/smbios-parser.c Can you please also add a test for each of these functions, with sample data. BTW here is some code to write fake tables in case it helps: https://chromium-review.googlesource.com/c/chromiumos/platform2/+/1062212/6/chromeos-config/libcros_config/identity_x86.cc Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] smbios: add parsing API
On 29.04.19 16:29, Christian Gmeiner wrote:
> Hi
>
> Am Do., 25. Apr. 2019 um 12:09 Uhr schrieb Alexander Graf :
>>
>> On 16.04.19 13:38, Christian Gmeiner wrote:
>>> Add an very simple API to be able to access SMBIOS strings
>>> like vendor, model and bios version.
>>>
>>> Signed-off-by: Christian Gmeiner
>>> ---
>>> include/smbios.h| 37 ++
>>> lib/Kconfig | 6 ++
>>> lib/Makefile| 1 +
>>> lib/smbios-parser.c | 162
>>> 4 files changed, 206 insertions(+)
>>> create mode 100644 lib/smbios-parser.c
>>>
>>> diff --git a/include/smbios.h b/include/smbios.h
>>> index 97b9ddce23..ad44e54245 100644
>>> --- a/include/smbios.h
>>> +++ b/include/smbios.h
>>> @@ -237,4 +237,41 @@ typedef int (*smbios_write_type)(ulong *addr, int
>>> handle);
>>> */
>>> ulong write_smbios_table(ulong addr);
>>>
>>> +
>>> +struct smbios_parser;
>>> +
>>> +/**
>>> + * smbios_parser_create() - Create smbios parser
>>> + *
>>> + * @addr:start address to search for SMBIOS structure
>>> + * @len: size of search area
>>> + * @return: NULL or valid pointer to a struct smbios_parser
>>> + */
>>> +struct smbios_parser *smbios_parser_create(unsigned int addr, unsigned int
>>> len);
>>> +
>>> +/**
>>> + * smbios_parser_destroy() - Destroy smbios parser
>>> + *
>>> + * @p: pointer to a struct smbios_parser
>>> + */
>>> +void smbios_parser_destroy(struct smbios_parser *p);
>>> +
>>> +/**
>>> + * smbios_header() - Search for SMBIOS header type
>>> + *
>>> + * @p: pointer to a struct smbios_parser
>>> + * @type:SMBIOS type
>>> + * @return: NULL or a valid pointer to a struct smbios_header
>>> + */
>>> +struct smbios_header *smbios_header(const struct smbios_parser *p, int
>>> type);
>>> +
>>> +/**
>>> + * smbios_string() - Return string from SMBIOS
>>> + *
>>> + * @header: pointer to struct smbios_header
>>> + * @index: string index
>>> + * @return: NULL or a valid const char pointer
>>> + */
>>> +const char *smbios_string(const struct smbios_header *header, int index);
>>> +
>>> #endif /* _SMBIOS_H_ */
>>> diff --git a/lib/Kconfig b/lib/Kconfig
>>> index 2120216593..59aafc63a7 100644
>>> --- a/lib/Kconfig
>>> +++ b/lib/Kconfig
>>> @@ -432,6 +432,12 @@ config SMBIOS_PRODUCT_NAME
>>>
>>> endmenu
>>>
>>> +config SMBIOS_PARSER
>>> + bool "SMBIOS parser"
>>> + default n
>>> + help
>>> + A simple parser for SMBIOS data.
>>> +
>>> source lib/efi/Kconfig
>>> source lib/efi_loader/Kconfig
>>> source lib/optee/Kconfig
>>> diff --git a/lib/Makefile b/lib/Makefile
>>> index 47829bfed5..f095bd420a 100644
>>> --- a/lib/Makefile
>>> +++ b/lib/Makefile
>>> @@ -34,6 +34,7 @@ obj-$(CONFIG_FIT) += fdtdec_common.o
>>> obj-$(CONFIG_TEST_FDTDEC) += fdtdec_test.o
>>> obj-$(CONFIG_GZIP_COMPRESSED) += gzip.o
>>> obj-$(CONFIG_GENERATE_SMBIOS_TABLE) += smbios.o
>>> +obj-$(CONFIG_SMBIOS_PARSER) += smbios-parser.o
>>> obj-$(CONFIG_IMAGE_SPARSE) += image-sparse.o
>>> obj-y += ldiv.o
>>> obj-$(CONFIG_MD5) += md5.o
>>> diff --git a/lib/smbios-parser.c b/lib/smbios-parser.c
>>> new file mode 100644
>>> index 00..b24fd7210c
>>> --- /dev/null
>>> +++ b/lib/smbios-parser.c
>>> @@ -0,0 +1,162 @@
>>> +// SPDX-License-Identifier: GPL-2.0+
>>> +/*
>>> + * Copyright (C) 2019, Bachmann electronic GmbH
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +struct smbios_parser {
>>> + void *search_area;
>>> + unsigned int search_area_len;
>>> + struct smbios_entry *entry;
>>> + void *data;
>>> +};
>>> +
>>> +static inline int verify_checksum(const struct smbios_entry *e)
>>> +{
>>> + /*
>>> + * Checksums for SMBIOS tables are calculated to have a value, so that
>>> + * the sum over all bytes yields zero (using unsigned 8 bit
>>> arithmetic).
>>> + */
>>> + u8 *byte = (u8 *)e;
>>> + u8 sum = 0;
>>> +
>>> + for (int i = 0; i < e->length; i++)
>>> + sum += byte[i];
>>> +
>>> + return sum;
>>> +}
>>> +
>>> +static struct smbios_entry *find_smbios_entry(const struct smbios_parser
>>> *p)
>>> +{
>>> + static const char sm_sig[] = "_SM_";
>>> + u8 *buf = (u8 *)p->search_area;
>>> + const u8 *end = (u8 *)p->search_area + p->search_area_len;
>>> + struct smbios_entry *entry = NULL;
>>> +
>>> + /* look for smbios entry */
>>> + while (buf < end) {
>>
>> Don't you have a way to pass the DMI pointer directly, maybe using cbfs?
>> Searching through the SMBIOS search area is so 1990s (and pretty much
>> only works on x86).
>>
> Coreboot adds a smbios cbmem entry which can be used to get the base address.
> Will make use of that mechanism in the next version of the patch set.
Thanks, that will make this code a lot more robust :).
>
>> I also don't think we really need all the smbios_parser logic. No need
>> to create special pseudo objects. IMHO you should either create an
>> actual UCLASS for SMBIOS with genuine callbacks and
Re: [U-Boot] [PATCH v1 02/18] usb: host: remove the xhci-zynqmp driver
On 29. 04. 19 2:55, Marek Vasut wrote: > On 4/5/19 2:55 PM, Jean-Jacques Hiblot wrote: >> This driver is not used anymore. >> >> Signed-off-by: Jean-Jacques Hiblot > > You want AB/RB from Michal on this one. Siva: Can you please take a look? M ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
