RE: [PATCH] mmc: fix the build error when MMC_WRITE is disabled
> Subject: [PATCH] mmc: fix the build error when MMC_WRITE is disabled > > erase_grp_size is used, when MMC_WRITE is enabled. > - error: ‘struct mmc’ has no member named ‘erase_grp_size’ > > Signed-off-by: Jaehoon Chung Reviewed-by: Peng Fan Regards, Peng. > --- > drivers/mmc/mmc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index > d43983d4a6..6a2b855435 100644 > --- a/drivers/mmc/mmc.c > +++ b/drivers/mmc/mmc.c > @@ -1126,9 +1126,11 @@ int mmc_hwpart_config(struct mmc *mmc, > > ext_csd[EXT_CSD_ERASE_GROUP_DEF] = 1; > > +#if CONFIG_IS_ENABLED(MMC_WRITE) > /* update erase group size to be high-capacity */ > mmc->erase_grp_size = > ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024; > +#endif > > } > > -- > 2.24.1
Re: [PATCH 1/5] imx8qm_rom7720_a1: Remove unused function detail_board_ddr_info()
On 16/01/20, Alifer Moraes wrote: > detail_board_ddr_info() is not used anywhere, so simply remove it. > > This function is only used by Layerscape, not by i.MX. > > This was detected by the following sparse warning: > > board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c:110:6: warning: no > previous > prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes] > > Signed-off-by: Alifer Moraes Reviewed-by: Oliver Graute
[PATCH v2 01/21] mips: add support to restore exception vector base before booting linux
In U-Boot the exception vector base will be moved to top of memory, to be
used to display register dump when exception occurs.
But some old linux kernel does not honor the base set in CP0_EBASE. A
modified exception vector base will cause kernel crash.
This patch adds an option to enable reset exception vector base to its
previous value, or a user configured value before booting linux kernel.
Signed-off-by: Weijie Gao
---
Changes since v1:
Moved core operations to trap_restore() in arch/mips/lib/traps.c.
Save previous ebase instead of using 0x8000 directly.
Add options to use customized ebase.
---
arch/mips/Kconfig | 30 +
arch/mips/include/asm/u-boot-mips.h | 2 ++
arch/mips/lib/bootm.c | 3 +++
arch/mips/lib/traps.c | 19 ++
4 files changed, 54 insertions(+)
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a3ae603044..5e20feeefb 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -287,6 +287,36 @@ config MIPS_RELOCATION_TABLE_SIZE
If unsure, leave at the default value.
+config RESTORE_EXCEPTION_VECTOR_BASE
+ bool "Restore exception vector base before booting linux kernel"
+ default n
+ help
+ In U-Boot the exception vector base will be moved to top of memory,
+ to be used to display register dump when exception occurs.
+ But some old linux kernel does not honor the base set in CP0_EBASE.
+ A modified exception vector base will cause kernel crash.
+
+ This option will restore the exception vector base to its previous
+ value.
+
+ If unsure, say N.
+
+config OVERRIDE_EXCEPTION_VECTOR_BASE
+ bool "Override the exception vector base to be restored"
+ depends on RESTORE_EXCEPTION_VECTOR_BASE
+ default n
+ help
+ Enable this option if you want to use a different exception vector
+ base rather than the previously saved one.
+
+config NEW_EXCEPTION_VECTOR_BASE
+ hex "New exception vector base"
+ depends on OVERRIDE_EXCEPTION_VECTOR_BASE
+ range 0x8000 0xb000
+ default 0x8000
+ help
+ The exception vector base to be restored before booting linux kernel
+
endmenu
menu "OS boot interface"
diff --git a/arch/mips/include/asm/u-boot-mips.h
b/arch/mips/include/asm/u-boot-mips.h
index 88438b9576..8b37cc4029 100644
--- a/arch/mips/include/asm/u-boot-mips.h
+++ b/arch/mips/include/asm/u-boot-mips.h
@@ -9,4 +9,6 @@ void except_vec_ejtag_debug(void);
int arch_misc_init(void);
+void trap_restore(void);
+
#endif /* _U_BOOT_MIPS_H_ */
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index 8c0d7672f2..f1db6d23b8 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -294,6 +294,9 @@ static void boot_jump_linux(bootm_headers_t *images)
bootstage_report();
#endif
+ if (CONFIG_IS_ENABLED(RESTORE_EXCEPTION_VECTOR_BASE))
+ trap_restore();
+
if (images->ft_len)
kernel(-2, (ulong)images->ft_addr, 0, 0);
else
diff --git a/arch/mips/lib/traps.c b/arch/mips/lib/traps.c
index 6fe8ebd16b..20f45fc4ed 100644
--- a/arch/mips/lib/traps.c
+++ b/arch/mips/lib/traps.c
@@ -19,6 +19,8 @@
DECLARE_GLOBAL_DATA_PTR;
+static unsigned long saved_ebase;
+
static void show_regs(const struct pt_regs *regs)
{
const int field = 2 * sizeof(unsigned long);
@@ -101,7 +103,24 @@ void trap_init(ulong reloc_addr)
set_handler(0x180, _vec3_generic, 0x80);
set_handler(0x280, _vec_ejtag_debug, 0x80);
+ saved_ebase = read_c0_ebase() & 0xf000;
+
write_c0_ebase(ebase);
clear_c0_status(ST0_BEV);
execution_hazard_barrier();
}
+
+void trap_restore(void)
+{
+ set_c0_status(ST0_BEV);
+ execution_hazard_barrier();
+
+#ifdef CONFIG_OVERRIDE_EXCEPTION_VECTOR_BASE
+ write_c0_ebase(CONFIG_NEW_EXCEPTION_VECTOR_BASE & 0xf000);
+#else
+ write_c0_ebase(saved_ebase);
+#endif
+
+ clear_c0_status(ST0_BEV);
+ execution_hazard_barrier();
+}
--
2.17.1
Re: [PATCH v2 1/9] lib: elf: Move the generic elf loading/validating functions to lib
On Fri, Jan 17, 2020 at 5:27 AM Lokesh Vutla wrote:
>
> Simon,
>
> On 13/01/20 11:24 AM, Keerthy wrote:
> > Move the generic elf loading/validating functions to lib/
> > so that they can be re-used and accessed by code existing
> > outside cmd.
> >
> > Signed-off-by: Keerthy
> > Suggested-by: Simon Goldschmidt
>
> Are you okay with this patch? If yes, Ill apply to u-boot-ti along with other
> patches in this series.
Yes.
Reviewed-by: Simon Goldschmidt
Regards,
Simon
>
> Thanks and regards,
> Lokesh
>
> > ---
> > Changes in v2:
> >
> > * Factored out all the generic elf handling functions under lib/elf.c
> >
> > cmd/Kconfig | 1 +
> > cmd/elf.c | 229
> > include/elf.h | 4 +
> > lib/Kconfig | 3 +
> > lib/Makefile | 1 +
> > lib/elf.c | 256 ++
> > 6 files changed, 265 insertions(+), 229 deletions(-)
> > create mode 100644 lib/elf.c
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 298feae24d..6f4f08d02a 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -375,6 +375,7 @@ config CMD_ADTIMG
> > config CMD_ELF
> > bool "bootelf, bootvx"
> > default y
> > + select ELF
> > help
> > Boot an ELF/vxWorks image from the memory.
> >
> > diff --git a/cmd/elf.c b/cmd/elf.c
> > index 32f12a72b9..23cc17aebc 100644
> > --- a/cmd/elf.c
> > +++ b/cmd/elf.c
> > @@ -26,211 +26,6 @@
> > #include
> > #endif
> >
> > -/*
> > - * A very simple ELF64 loader, assumes the image is valid, returns the
> > - * entry point address.
> > - *
> > - * Note if U-Boot is 32-bit, the loader assumes the to segment's
> > - * physical address and size is within the lower 32-bit address space.
> > - */
> > -static unsigned long load_elf64_image_phdr(unsigned long addr)
> > -{
> > - Elf64_Ehdr *ehdr; /* Elf header structure pointer */
> > - Elf64_Phdr *phdr; /* Program header structure pointer */
> > - int i;
> > -
> > - ehdr = (Elf64_Ehdr *)addr;
> > - phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
> > -
> > - /* Load each program header */
> > - for (i = 0; i < ehdr->e_phnum; ++i) {
> > - void *dst = (void *)(ulong)phdr->p_paddr;
> > - void *src = (void *)addr + phdr->p_offset;
> > -
> > - debug("Loading phdr %i to 0x%p (%lu bytes)\n",
> > - i, dst, (ulong)phdr->p_filesz);
> > - if (phdr->p_filesz)
> > - memcpy(dst, src, phdr->p_filesz);
> > - if (phdr->p_filesz != phdr->p_memsz)
> > - memset(dst + phdr->p_filesz, 0x00,
> > -phdr->p_memsz - phdr->p_filesz);
> > - flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN),
> > - roundup(phdr->p_memsz, ARCH_DMA_MINALIGN));
> > - ++phdr;
> > - }
> > -
> > - if (ehdr->e_machine == EM_PPC64 && (ehdr->e_flags &
> > - EF_PPC64_ELFV1_ABI)) {
> > - /*
> > - * For the 64-bit PowerPC ELF V1 ABI, e_entry is a function
> > - * descriptor pointer with the first double word being the
> > - * address of the entry point of the function.
> > - */
> > - uintptr_t addr = ehdr->e_entry;
> > -
> > - return *(Elf64_Addr *)addr;
> > - }
> > -
> > - return ehdr->e_entry;
> > -}
> > -
> > -static unsigned long load_elf64_image_shdr(unsigned long addr)
> > -{
> > - Elf64_Ehdr *ehdr; /* Elf header structure pointer */
> > - Elf64_Shdr *shdr; /* Section header structure pointer */
> > - unsigned char *strtab = 0; /* String table pointer */
> > - unsigned char *image; /* Binary image pointer */
> > - int i; /* Loop counter */
> > -
> > - ehdr = (Elf64_Ehdr *)addr;
> > -
> > - /* Find the section header string table for output info */
> > - shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
> > - (ehdr->e_shstrndx * sizeof(Elf64_Shdr)));
> > -
> > - if (shdr->sh_type == SHT_STRTAB)
> > - strtab = (unsigned char *)(addr + (ulong)shdr->sh_offset);
> > -
> > - /* Load each appropriate section */
> > - for (i = 0; i < ehdr->e_shnum; ++i) {
> > - shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
> > - (i * sizeof(Elf64_Shdr)));
> > -
> > - if (!(shdr->sh_flags & SHF_ALLOC) ||
> > - shdr->sh_addr == 0 || shdr->sh_size == 0) {
> > - continue;
> > - }
> > -
> > - if (strtab) {
> > - debug("%sing %s @ 0x%08lx (%ld bytes)\n",
> > - (shdr->sh_type == SHT_NOBITS) ? "Clear" :
> > "Load",
> > -[shdr->sh_name],
> > -(unsigned long)shdr->sh_addr,
> > -(long)shdr->sh_size);
> > -
[PATCH v2 19/21] mips: mtmips: add SPL support
This patch adds SPL support for mtmips platform. The lowlevel architecture
is split into SPL and the rest parts are built into a memory loadable
u-boot image. Optional SPL_DM and OF_CONTROL are also supported.
The increment of size is very small (< 10 KiB) if SPL_DM and OF_CONTROL are
not enabled and the memory bootable u-boot (u-boot.img) is generated
automatically so there is not need to add a separate config for it.
A lzma compressed payload (u-boot-lzma.img) is also generated and it will
be combined with u-boot-spl.bin to form the unified ROM bootable binary
u-boot-mtmips.bin.
A spl loader is added to support uncompress the payload.
Signed-off-by: Weijie Gao
---
Changes since v1:
move spl loader into this patch.
add full pinmux for all three uarts.
add optional DM & DT support.
---
Makefile| 9 ++
arch/mips/Kconfig | 3 +
arch/mips/dts/mt7628-u-boot.dtsi| 24
arch/mips/mach-mtmips/Kconfig | 24
arch/mips/mach-mtmips/Makefile | 1 +
arch/mips/mach-mtmips/include/mach/serial.h | 13 +++
arch/mips/mach-mtmips/include/mach/spl.h| 14 +++
arch/mips/mach-mtmips/mt7628/Makefile | 1 +
arch/mips/mach-mtmips/mt7628/serial.c | 34 ++
arch/mips/mach-mtmips/spl.c | 31 +
arch/mips/mach-mtmips/spl_load.c| 121
11 files changed, 275 insertions(+)
create mode 100644 arch/mips/dts/mt7628-u-boot.dtsi
create mode 100644 arch/mips/mach-mtmips/include/mach/serial.h
create mode 100644 arch/mips/mach-mtmips/include/mach/spl.h
create mode 100644 arch/mips/mach-mtmips/mt7628/serial.c
create mode 100644 arch/mips/mach-mtmips/spl.c
create mode 100644 arch/mips/mach-mtmips/spl_load.c
diff --git a/Makefile b/Makefile
index 8013cbd9f9..1e18a37913 100644
--- a/Makefile
+++ b/Makefile
@@ -895,6 +895,7 @@ ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
endif
ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
+ALL-$(CONFIG_ARCH_MTMIPS) += u-boot-mtmips.bin
# Add optional build target if defined in board/cpu/soc headers
ifneq ($(CONFIG_BUILD_TARGET),)
@@ -1664,6 +1665,14 @@ u-boot-mtk.bin: u-boot.bin FORCE
$(call if_changed,mkimage)
endif
+ifeq ($(CONFIG_SPL),y)
+u-boot-mtmips.bin: u-boot.dtb u-boot-lzma.img spl/u-boot-spl.bin FORCE
+ $(call if_changed,binman)
+else
+u-boot-mtmips.bin: u-boot.bin FORCE
+ $(call if_changed,copy)
+endif
+
ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
# Rule to link u-boot
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 5f82caf8be..5f74f549b5 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -98,6 +98,9 @@ config ARCH_MTMIPS
select SUPPORTS_CPU_MIPS32_R2
select SUPPORTS_LITTLE_ENDIAN
select SYSRESET
+ select SUPPORT_SPL
+ select SPL_LZMA
+ select BINMAN
config ARCH_JZ47XX
bool "Support Ingenic JZ47xx"
diff --git a/arch/mips/dts/mt7628-u-boot.dtsi b/arch/mips/dts/mt7628-u-boot.dtsi
new file mode 100644
index 00..213959105f
--- /dev/null
+++ b/arch/mips/dts/mt7628-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao
+ */
+
+/ {
+ binman {
+ filename = "u-boot-mtmips.bin";
+ pad-byte = <0xff>;
+
+#ifdef CONFIG_SPL
+ u-boot-spl {
+ };
+
+ u-boot-lzma-img {
+ };
+#else
+ u-boot {
+ };
+#endif
+ };
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 3f25de8b85..9b42d5b581 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -20,8 +20,16 @@ config SYS_ICACHE_LINE_SIZE
default 32
config SYS_TEXT_BASE
+ default 0x9c00 if !SPL
+ default 0x8020 if SPL
+
+config SPL_TEXT_BASE
default 0x9c00
+config SPL_LOADER_SUPPORT
+ bool
+ default y
+
choice
prompt "MediaTek MIPS SoC select"
@@ -34,6 +42,14 @@ config SOC_MT7628
select PINCTRL_MT7628
select MTK_SERIAL
select SYSRESET_RESETCTL
+ select SPL_SEPARATE_BSS if SPL
+ select SPL_INIT_STACK_WITHOUT_MALLOC_F if SPL
+ select SPL_OF_CONTROL if SPL_DM
+ select SPL_SIMPLE_BUS if SPL_DM
+ select SPL_DM_SERIAL if SPL_DM
+ select SPL_CLK if SPL_DM && SPL_SERIAL_SUPPORT
+ select SPL_SYSRESET if SPL_DM
+ select SPL_OF_LIBFDT if SPL_OF_CONTROL
help
This supports MediaTek MT7628/MT7688.
@@ -88,6 +104,14 @@ endchoice
config SUPPORTS_BOOT_RAM
bool
+config SPL_UART2_SPIS_PINMUX
+ bool "Use alternative pinmux for UART2 in SPL stage"
+ depends on SPL_SERIAL_SUPPORT
+ default n
+ help
+ Select this if the UART2 of your board is connected to GPIO 16/17
+ (shared with SPIS)
[PATCH v2 10/21] mips: mtmips: rewrite lowlevel codes of mt7628
This patch rewrites the mtmips architecture with the following changes: 1. Move MT7628 soc parts into a subfolder. 2. Lock parts of D-Cache as temporary stack. 3. Reimplement DDR initialization in C language. 4. Reimplement DDR calibration in a clear logic. 5. Add full support for auto size detection for DDR1 and DDR2. 6. Use accurate CPU clock depending on the input xtal frequency for timer and delay functions. Note: print_cpuinfo() has incompatible parts with MT7620 so it's moved into mt7628 subfolder. Signed-off-by: Weijie Gao --- Changes since v1: moved some changes to new patches --- arch/mips/mach-mtmips/Kconfig | 69 +--- arch/mips/mach-mtmips/Makefile| 7 +- arch/mips/mach-mtmips/cpu.c | 58 +--- arch/mips/mach-mtmips/ddr_cal.c | 211 +++ arch/mips/mach-mtmips/ddr_calibrate.c | 309 - arch/mips/mach-mtmips/ddr_init.c | 194 +++ arch/mips/mach-mtmips/include/mach/ddr.h | 52 +++ arch/mips/mach-mtmips/include/mach/mc.h | 180 ++ arch/mips/mach-mtmips/lowlevel_init.S | 328 -- arch/mips/mach-mtmips/mt7628/Makefile | 5 + arch/mips/mach-mtmips/mt7628/ddr.c| 173 + arch/mips/mach-mtmips/mt7628/init.c | 109 ++ arch/mips/mach-mtmips/mt7628/lowlevel_init.S | 161 + arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++ arch/mips/mach-mtmips/mt76xx.h| 32 -- .../gardena-smart-gateway-mt7688_defconfig| 2 - configs/linkit-smart-7688_defconfig | 2 - 17 files changed, 1202 insertions(+), 794 deletions(-) create mode 100644 arch/mips/mach-mtmips/ddr_cal.c delete mode 100644 arch/mips/mach-mtmips/ddr_calibrate.c create mode 100644 arch/mips/mach-mtmips/ddr_init.c create mode 100644 arch/mips/mach-mtmips/include/mach/ddr.h create mode 100644 arch/mips/mach-mtmips/include/mach/mc.h delete mode 100644 arch/mips/mach-mtmips/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/Makefile create mode 100644 arch/mips/mach-mtmips/mt7628/ddr.c create mode 100644 arch/mips/mach-mtmips/mt7628/init.c create mode 100644 arch/mips/mach-mtmips/mt7628/lowlevel_init.S create mode 100644 arch/mips/mach-mtmips/mt7628/mt7628.h delete mode 100644 arch/mips/mach-mtmips/mt76xx.h diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig index 8cb76c4560..3f25de8b85 100644 --- a/arch/mips/mach-mtmips/Kconfig +++ b/arch/mips/mach-mtmips/Kconfig @@ -19,12 +19,18 @@ config SYS_ICACHE_SIZE config SYS_ICACHE_LINE_SIZE default 32 +config SYS_TEXT_BASE + default 0x9c00 + choice prompt "MediaTek MIPS SoC select" config SOC_MT7628 bool "MT7628" select MIPS_L1_CACHE_SHIFT_5 + select MIPS_INIT_STACK_IN_SRAM + select MIPS_SRAM_INIT + select SYS_MIPS_CACHE_INIT_RAM_LOAD select PINCTRL_MT7628 select MTK_SERIAL select SYSRESET_RESETCTL @@ -79,69 +85,6 @@ config BOOT_ROM endchoice -choice - prompt "DDR2 size" - -config ONBOARD_DDR2_SIZE_256MBIT - bool "256MBit (32MByte) total size" - depends on BOOT_ROM - help - Use 256MBit (32MByte) of DDR total size - -config ONBOARD_DDR2_SIZE_512MBIT - bool "512MBit (64MByte) total size" - depends on BOOT_ROM - help - Use 512MBit (64MByte) of DDR total size - -config ONBOARD_DDR2_SIZE_1024MBIT - bool "1024MBit (128MByte) total size" - depends on BOOT_ROM - help - Use 1024MBit (128MByte) of DDR total size - -config ONBOARD_DDR2_SIZE_2048MBIT - bool "2048MBit (256MByte) total size" - depends on BOOT_ROM - help - Use 2048MBit (256MByte) of DDR total size - -endchoice - -choice - prompt "DDR2 chip width" - -config ONBOARD_DDR2_CHIP_WIDTH_8BIT - bool "8bit DDR chip width" - depends on BOOT_ROM - help - Use DDR chips with 8bit width - -config ONBOARD_DDR2_CHIP_WIDTH_16BIT - bool "16bit DDR chip width" - depends on BOOT_ROM - help - Use DDR chips with 16bit width - -endchoice - -choice - prompt "DDR2 bus width" - -config ONBOARD_DDR2_BUS_WIDTH_16BIT - bool "16bit DDR bus width" - depends on BOOT_ROM - help - Use 16bit DDR bus width - -config ONBOARD_DDR2_BUS_WIDTH_32BIT - bool "32bit DDR bus width" - depends on BOOT_ROM - help - Use 32bit DDR bus width - -endchoice - config SUPPORTS_BOOT_RAM bool diff --git a/arch/mips/mach-mtmips/Makefile b/arch/mips/mach-mtmips/Makefile index 1f3e65e8a5..72f0369030 100644 --- a/arch/mips/mach-mtmips/Makefile +++ b/arch/mips/mach-mtmips/Makefile @@ -1,8 +1,7 @@ # SPDX-License-Identifier: GPL-2.0+ obj-y += cpu.o +obj-y += ddr_init.o +obj-y += ddr_cal.o -ifndef CONFIG_SKIP_LOWLEVEL_INIT -obj-y += ddr_calibrate.o -obj-y += lowlevel_init.o -endif
[PATCH v2 21/21] mips: mtmips: add support for mt7628-rfb
This patch adds support for mt7628 reference board. SPL_DM and DT are not
enabled for SPL to save about 17KiB for u-boot-spl.bin.
Signed-off-by: Weijie Gao
---
Changes since v1: moved spl loader to another patch.
---
arch/mips/dts/Makefile| 1 +
arch/mips/dts/mediatek,mt7628-rfb.dts | 67 +++
arch/mips/mach-mtmips/Kconfig | 9
board/mediatek/mt7628/Kconfig | 12 +
board/mediatek/mt7628/MAINTAINERS | 7 +++
board/mediatek/mt7628/Makefile| 3 ++
board/mediatek/mt7628/board.c | 8
configs/mt7628_rfb_defconfig | 45 ++
include/configs/mt7628.h | 52 +
9 files changed, 204 insertions(+)
create mode 100644 arch/mips/dts/mediatek,mt7628-rfb.dts
create mode 100644 board/mediatek/mt7628/Kconfig
create mode 100644 board/mediatek/mt7628/MAINTAINERS
create mode 100644 board/mediatek/mt7628/Makefile
create mode 100644 board/mediatek/mt7628/board.c
create mode 100644 configs/mt7628_rfb_defconfig
create mode 100644 include/configs/mt7628.h
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index c9d75596f2..cbd0c8bc8b 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_BOARD_COMTREND_CT5361) += comtrend,ct-5361.dtb
dtb-$(CONFIG_BOARD_COMTREND_VR3032U) += comtrend,vr-3032u.dtb
dtb-$(CONFIG_BOARD_COMTREND_WAP5813N) += comtrend,wap-5813n.dtb
dtb-$(CONFIG_BOARD_HUAWEI_HG556A) += huawei,hg556a.dtb
+dtb-$(CONFIG_BOARD_MT7628_RFB) += mediatek,mt7628-rfb.dtb
dtb-$(CONFIG_BOARD_NETGEAR_CG3100D) += netgear,cg3100d.dtb
dtb-$(CONFIG_BOARD_NETGEAR_DGND3700V2) += netgear,dgnd3700v2.dtb
dtb-$(CONFIG_BOARD_SAGEM_FAST1704) += sagem,f...@st1704.dtb
diff --git a/arch/mips/dts/mediatek,mt7628-rfb.dts
b/arch/mips/dts/mediatek,mt7628-rfb.dts
new file mode 100644
index 00..6ff36daa6e
--- /dev/null
+++ b/arch/mips/dts/mediatek,mt7628-rfb.dts
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao
+ */
+
+/dts-v1/;
+
+#include "mt7628a.dtsi"
+
+/ {
+ compatible = "mediatek,mt7628-rfb", "ralink,mt7628a-soc";
+ model = "MediaTek MT7628 RFB";
+
+ aliases {
+ serial0 =
+ spi0 =
+ };
+
+ chosen {
+ stdout-path =
+ };
+};
+
+ {
+ state_default: pin_state {
+ pleds {
+ groups = "p0led", "p1led", "p2led", "p3led", "p4led";
+ function = "led";
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ num-cs = <2>;
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+ };
+};
+
+ {
+ mediatek,wan-port = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_router_mode>;
+};
+
+ {
+ bus-width = <4>;
+ cap-sd-highspeed;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_router_mode>;
+
+ status = "okay";
+};
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 441e2700c2..1cd1d16022 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -76,6 +76,14 @@ config BOARD_LINKIT_SMART_7688
ethernet ports, 1 USB port, 1 UART, GPIO buttons and LEDs, and
a MT7688 (PCIe).
+config BOARD_MT7628_RFB
+ bool "MediaTek MT7628 RFB"
+ depends on SOC_MT7628
+ help
+ The reference design of MT7628. The board has 128 MiB DDR2, 8 MiB
+ SPI-NOR flash, 1 built-in switch with 5 ports, 1 UART, 1 USB host,
+ 1 SDXC, 1 PCIe socket and JTAG pins.
+
endchoice
config SPL_UART2_SPIS_PINMUX
@@ -87,6 +95,7 @@ config SPL_UART2_SPIS_PINMUX
(shared with SPIS) rather than the usual GPIO 20/21.
source "board/gardena/smart-gateway-mt7688/Kconfig"
+source "board/mediatek/mt7628/Kconfig"
source "board/seeed/linkit-smart-7688/Kconfig"
endmenu
diff --git a/board/mediatek/mt7628/Kconfig b/board/mediatek/mt7628/Kconfig
new file mode 100644
index 00..d6b6f9d632
--- /dev/null
+++ b/board/mediatek/mt7628/Kconfig
@@ -0,0 +1,12 @@
+if BOARD_MT7628_RFB
+
+config SYS_BOARD
+ default "mt7628"
+
+config SYS_VENDOR
+ default "mediatek"
+
+config SYS_CONFIG_NAME
+ default "mt7628"
+
+endif
diff --git a/board/mediatek/mt7628/MAINTAINERS
b/board/mediatek/mt7628/MAINTAINERS
new file mode 100644
index 00..032fd0e2f7
--- /dev/null
+++ b/board/mediatek/mt7628/MAINTAINERS
@@ -0,0 +1,7 @@
+MT7628_RFB BOARD
+M: Weijie Gao
+S: Maintained
+F: board/mediatek/mt7628
+F: include/configs/mt7628.h
+F: configs/mt7628_rfb_defconfig
+F: arch/mips/dts/mediatek,mt7628-rfb.dts
diff --git a/board/mediatek/mt7628/Makefile
[PATCH v2 17/21] Makefile: add support to generate LZMA compressed u-boot image
This patch adds support for generating LZMA compressed u-boot image. The compressed image can be used for SPL to reduce the size of the u-boot binary. Reviewed-by: Simon Glass Signed-off-by: Weijie Gao --- Changes since v1: none --- Makefile | 13 + 1 file changed, 13 insertions(+) diff --git a/Makefile b/Makefile index 3f332e6885..8013cbd9f9 100644 --- a/Makefile +++ b/Makefile @@ -952,6 +952,9 @@ append = cat $(filter-out $< $(PHONY), $^) >> $@ quiet_cmd_pad_cat = CAT $@ cmd_pad_cat = $(cmd_objcopy) && $(append) || rm -f $@ +quiet_cmd_lzma = LZMA$@ +cmd_lzma = lzma -c -z -k -9 $< > $@ + cfg: u-boot.cfg quiet_cmd_cfgcheck = CFGCHK $2 @@ -1334,6 +1337,16 @@ else UBOOT_BIN := u-boot.bin endif +MKIMAGEFLAGS_u-boot-lzma.img = -A $(ARCH) -T standalone -C lzma -O u-boot \ + -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ + -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" + +u-boot.bin.lzma: u-boot.bin FORCE + $(call if_changed,lzma) + +u-boot-lzma.img: u-boot.bin.lzma FORCE + $(call if_changed,mkimage) + u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \ $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \ -- 2.17.1
[PATCH v2 20/21] mips: mtmips: enable SPL for all boards
This patch enables SPL for all mtmips boards. And also remove defconfig
files which are intend to build ram bootable u-boot files.
SPL_DM and OF_CONTROL are enabled for both boards.
Signed-off-by: Weijie Gao
---
Changes since v1: enabled DM & DT support, enabled compression support
---
arch/mips/mach-mtmips/Kconfig | 26 ---
arch/mips/mach-mtmips/spl.c | 4 +
board/gardena/smart-gateway-mt7688/board.c| 2 +
...gardena-smart-gateway-mt7688-ram_defconfig | 74 ---
.../gardena-smart-gateway-mt7688_defconfig| 11 ++-
configs/linkit-smart-7688-ram_defconfig | 65
configs/linkit-smart-7688_defconfig | 11 ++-
.../configs/gardena-smart-gateway-mt7688.h| 18 -
include/configs/linkit-smart-7688.h | 19 -
9 files changed, 57 insertions(+), 173 deletions(-)
delete mode 100644 configs/gardena-smart-gateway-mt7688-ram_defconfig
delete mode 100644 configs/linkit-smart-7688-ram_defconfig
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 9b42d5b581..441e2700c2 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -62,7 +62,6 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
bool "GARDENA smart Gateway"
depends on SOC_MT7628
select BOARD_LATE_INIT
- select SUPPORTS_BOOT_RAM
help
GARDENA smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
and 8 MiB of flash (SPI NOR) and additional SPI NAND storage.
@@ -70,7 +69,6 @@ config BOARD_GARDENA_SMART_GATEWAY_MT7688
config BOARD_LINKIT_SMART_7688
bool "LinkIt Smart 7688"
depends on SOC_MT7628
- select SUPPORTS_BOOT_RAM
help
Seeed LinkIt Smart 7688 boards have a MT7688 SoC with 128 MiB of RAM
and 32 MiB of flash (SPI).
@@ -80,30 +78,6 @@ config BOARD_LINKIT_SMART_7688
endchoice
-choice
- prompt "Boot mode"
-
-config BOOT_RAM
- bool "RAM boot"
- depends on SUPPORTS_BOOT_RAM
- help
- This builds an image that is linked to a RAM address. It can be used
- for booting from CFE via TFTP using an ELF image, but it can also be
- booted from RAM by other bootloaders using a BIN image.
-
-config BOOT_ROM
- bool "ROM boot"
- depends on SUPPORTS_BOOT_RAM
- help
- This builds an image that is linked to a ROM address. It can be
- used as main bootloader image which is programmed onto the onboard
- flash storage (SPI NOR).
-
-endchoice
-
-config SUPPORTS_BOOT_RAM
- bool
-
config SPL_UART2_SPIS_PINMUX
bool "Use alternative pinmux for UART2 in SPL stage"
depends on SPL_SERIAL_SUPPORT
diff --git a/arch/mips/mach-mtmips/spl.c b/arch/mips/mach-mtmips/spl.c
index f12fb70d75..2d506f73b2 100644
--- a/arch/mips/mach-mtmips/spl.c
+++ b/arch/mips/mach-mtmips/spl.c
@@ -18,6 +18,10 @@ void __noreturn board_init_f(ulong dummy)
spl_init();
#ifdef CONFIG_SPL_SERIAL_SUPPORT
+ /*
+* mtmips_spl_serial_init() is useful if debug uart is enabled,
+* or DM based serial is not enabled.
+*/
mtmips_spl_serial_init();
preloader_console_init();
#endif
diff --git a/board/gardena/smart-gateway-mt7688/board.c
b/board/gardena/smart-gateway-mt7688/board.c
index ae03f0a434..80f9f1ae65 100644
--- a/board/gardena/smart-gateway-mt7688/board.c
+++ b/board/gardena/smart-gateway-mt7688/board.c
@@ -294,8 +294,10 @@ err_free:
return ret;
}
+#ifndef CONFIG_SPL_BUILD
U_BOOT_CMD(
fd_write, 1, 0, do_fd_write,
"Write test factory-data values to SPI NOR",
"\n"
);
+#endif
diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
deleted file mode 100644
index 38c9272723..00
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ /dev/null
@@ -1,74 +0,0 @@
-CONFIG_MIPS=y
-CONFIG_SYS_TEXT_BASE=0x8001
-CONFIG_ENV_SIZE=0x1
-CONFIG_ENV_OFFSET=0xA
-CONFIG_NR_DRAM_BANKS=1
-CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
-CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c
-CONFIG_ENV_SECT_SIZE=0x1
-CONFIG_ARCH_MTMIPS=y
-CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y
-# CONFIG_MIPS_BOOT_ENV_LEGACY is not set
-CONFIG_MIPS_BOOT_FDT=y
-CONFIG_ENV_VARS_UBOOT_CONFIG=y
-CONFIG_FIT=y
-CONFIG_FIT_SIGNATURE=y
-CONFIG_LEGACY_IMAGE_FORMAT=y
-CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="cp.b 8300 8400 1 && dhcp uEnv.txt && env
import -t ${fileaddr} ${filesize} && run do_u_boot_init; reset"
-CONFIG_USE_PREBOOT=y
-CONFIG_SYS_CONSOLE_INFO_QUIET=y
-CONFIG_VERSION_VARIABLE=y
-CONFIG_BOARD_EARLY_INIT_F=y
-CONFIG_HUSH_PARSER=y
-CONFIG_CMD_LICENSE=y
-# CONFIG_CMD_ELF is not set
-# CONFIG_CMD_XIMG is not set
-CONFIG_CMD_MEMINFO=y
-# CONFIG_CMD_FLASH is not set
-CONFIG_CMD_GPIO=y
-# CONFIG_CMD_LOADS is not set
-CONFIG_CMD_MTD=y
-CONFIG_CMD_SPI=y
-CONFIG_CMD_WDT=y
[PATCH v2 18/21] tools: binman: add etype file for u-boot-lzma-img
This patch adds etype u-boot-lzma-img for binman. README.entries is also updated. Signed-off-by: Weijie Gao --- Changes since v1: updated README.entries, modified copyright and description. --- tools/binman/README.entries | 15 ++ tools/binman/etype/u_boot_lzma_img.py | 28 +++ 2 files changed, 43 insertions(+) create mode 100644 tools/binman/etype/u_boot_lzma_img.py diff --git a/tools/binman/README.entries b/tools/binman/README.entries index 6a816bba6b..0aea9b8f6d 100644 --- a/tools/binman/README.entries +++ b/tools/binman/README.entries @@ -747,6 +747,21 @@ applications. +Entry: u-boot-lzma-img: U-Boot legacy image with contents compressed by LZMA + + +Properties / Entry arguments: +- filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img') + +This is the U-Boot binary as a packaged image, in legacy format. It has a +header which allows it to be loaded at the correct address for execution. +Its contents are compressed by LZMA. + +You should use FIT (Flat Image Tree) instead of the legacy image for new +applications. + + + Entry: u-boot-nodtb: U-Boot flat binary without device tree appended diff --git a/tools/binman/etype/u_boot_lzma_img.py b/tools/binman/etype/u_boot_lzma_img.py new file mode 100644 index 00..966d6a46da --- /dev/null +++ b/tools/binman/etype/u_boot_lzma_img.py @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: GPL-2.0 +# Copyright (C) 2020 MediaTek Inc. All Rights Reserved. +# Author: Weijie Gao +# +# Entry-type module for U-Boot legacy image with contents compressed by LZMA +# + +from entry import Entry +from blob import Entry_blob + +class Entry_u_boot_lzma_img(Entry_blob): +"""U-Boot legacy image with contents compressed by LZMA + +Properties / Entry arguments: +- filename: Filename of u-boot-lzma.img (default 'u-boot-lzma.img') + +This is the U-Boot binary as a packaged image, in legacy format. It has a +header which allows it to be loaded at the correct address for execution. +Its contents are compressed by LZMA. + +You should use FIT (Flat Image Tree) instead of the legacy image for new +applications. +""" +def __init__(self, section, etype, node): +Entry_blob.__init__(self, section, etype, node) + +def GetDefaultFilename(self): +return 'u-boot-lzma.img' -- 2.17.1
[PATCH v2 15/21] mips: add an option to enable u_boot_list section for SPL loaders in u-boot-spl.lds
u_boot_list is not only used by DM, but also by some SPL image load methods
such as spl_nor.c.
This patch adds an option CONFIG_SPL_LOADER_SUPPORT in conjunction with
CONFIG_SPL_DM surrounding the u_boot_list section to make sure SPL image
loaders can be correctly built into u-boot SPL without DM enabled.
Signed-off-by: Weijie Gao
---
Changes since v1: uses a new config instead of removing CONFIG_SPL_DM
---
arch/mips/cpu/u-boot-spl.lds | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/cpu/u-boot-spl.lds b/arch/mips/cpu/u-boot-spl.lds
index e467491639..28ea4f2a48 100644
--- a/arch/mips/cpu/u-boot-spl.lds
+++ b/arch/mips/cpu/u-boot-spl.lds
@@ -27,7 +27,7 @@ SECTIONS
*(SORT_BY_ALIGNMENT(.sdata*))
} > .spl_mem
-#ifdef CONFIG_SPL_DM
+#if defined(CONFIG_SPL_DM) || defined(CONFIG_SPL_LOADER_SUPPORT)
. = ALIGN(4);
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)));
--
2.17.1
[PATCH v2 16/21] lib: enable lzma decompression support for SPL build
This patch enables LZMA decompression support for SPL build Reviewed-by: Tom Rini Signed-off-by: Weijie Gao --- Changes since v1: none --- lib/Kconfig | 5 + lib/Makefile | 1 + 2 files changed, 6 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index d040a87d26..6e491c3552 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -428,6 +428,11 @@ config SPL_LZ4 fast compression and decompression speed. It belongs to the LZ77 family of byte-oriented compression schemes. +config SPL_LZMA + bool "Enable LZMA decompression support for SPL build" + help + This enables support for LZMA compression altorithm for SPL boot. + config SPL_LZO bool "Enable LZO decompression support in SPL" help diff --git a/lib/Makefile b/lib/Makefile index 6b7b9ce85c..889f505800 100644 --- a/lib/Makefile +++ b/lib/Makefile @@ -65,6 +65,7 @@ obj-$(CONFIG_$(SPL_)ZLIB) += zlib/ obj-$(CONFIG_$(SPL_)ZSTD) += zstd/ obj-$(CONFIG_$(SPL_)GZIP) += gunzip.o obj-$(CONFIG_$(SPL_)LZO) += lzo/ +obj-$(CONFIG_$(SPL_)LZMA) += lzma/ obj-$(CONFIG_$(SPL_)LZ4) += lz4_wrapper.o obj-$(CONFIG_LIBAVB) += libavb/ -- 2.17.1
[PATCH v2 12/21] dts: mtmips: add u-boot, dm-pre-reloc for some nodes in mt7628a.dtsi
To enable DM support in SPL, some necessary nodes must be reserved for
serial, clk, sysreset and other drivers.
This patch adds u-boot,dm-pre-reloc for these nodes.
Signed-off-by: Weijie Gao
---
Changes since v1: newly added
---
arch/mips/dts/mt7628a.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 3d7b839e6d..744594c45a 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -23,11 +23,14 @@
#address-cells = <1>;
#size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
resetctl-reboot {
compatible = "resetctl-reboot";
resets = < MT7628_SYS_RST>;
reset-names = "sysreset";
+ u-boot,dm-pre-reloc;
};
clkctrl: clkctrl@0x2c {
@@ -42,6 +45,7 @@
reg = <0x34 0x4>;
compatible = "mediatek,mtmips-reset";
#reset-cells = <1>;
+ u-boot,dm-pre-reloc;
};
pinctrl: pinctrl@60 {
@@ -52,6 +56,8 @@
pinctrl-names = "default";
pinctrl-0 = <_default>;
+ u-boot,dm-pre-reloc;
+
state_default: pin_state {
};
@@ -260,6 +266,8 @@
reset-names = "uart0";
reg-shift = <2>;
+
+ u-boot,dm-pre-reloc;
};
uart1: uart1@d00 {
@@ -275,6 +283,8 @@
reset-names = "uart1";
reg-shift = <2>;
+
+ u-boot,dm-pre-reloc;
};
uart2: uart2@e00 {
@@ -290,6 +300,8 @@
reset-names = "uart2";
reg-shift = <2>;
+
+ u-boot,dm-pre-reloc;
};
};
--
2.17.1
[PATCH v2 14/21] mips: enable support for appending dtb to spl binary
If CONFIG_SPL_OF_CONTROL is enabled for SPL and CONFIG_OF_SEPARATE is also
enabled, the dtb will be appended to the u-boot-spl.bin.
When calling dm_init_and_scan() in SPL, fdtdec_setup() will try to locate
dtb at the end of u-boot-spl.bin, by referencing to _image_binary_end.
However _image_binary_end is currently missing in u-boot-spl.lds.
This patch adds _image_binary_end to u-boot-spl.lds to make sure linking
u-boot-spl will not fail.
Signed-off-by: Weijie Gao
---
Changes since v1: newly added
---
arch/mips/cpu/u-boot-spl.lds | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/mips/cpu/u-boot-spl.lds b/arch/mips/cpu/u-boot-spl.lds
index d08d6222c4..e467491639 100644
--- a/arch/mips/cpu/u-boot-spl.lds
+++ b/arch/mips/cpu/u-boot-spl.lds
@@ -37,6 +37,8 @@ SECTIONS
. = ALIGN(4);
__image_copy_end = .;
+ _image_binary_end = .;
+
.bss (NOLOAD) : {
__bss_start = .;
*(.bss*)
--
2.17.1
[PATCH v2 08/21] mips: add a mtmips-specific field to architecture-specific global data
SoCs of mtmips can use different CPU frequencies depending on the HW/SW
configurations. For example mt7628 uses 580MHz clock if the input xtal
frequency is 40MHz, and 575MHz clock if the xtal is 25MHz. Upon cold boot
the CPU uses the xtal frequency directly.
So hardcoding the timer frequency (half of the CPU frequency) in
CONFIG_SYS_MIPS_TIMER_FREQ is not a good idea for this case.
This patch adds a mtmips-specific field timer_freq to arch_global_data.
This field will be used later in mtmips-specific get_tbclk() to provide
accurate timer frequency in different boot stage.
Signed-off-by: Weijie Gao
---
Changes since v1: splitted from another patch.
---
arch/mips/include/asm/global_data.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/mips/include/asm/global_data.h
b/arch/mips/include/asm/global_data.h
index 7b4ad083ba..4c30fab871 100644
--- a/arch/mips/include/asm/global_data.h
+++ b/arch/mips/include/asm/global_data.h
@@ -27,6 +27,9 @@ struct arch_global_data {
#ifdef CONFIG_MIPS_L2_CACHE
unsigned short l2_line_size;
#endif
+#ifdef CONFIG_ARCH_MTMIPS
+ unsigned long timer_freq;
+#endif
};
#include
--
2.17.1
[PATCH v2 13/21] dts: mtmips: add alternative pinmux node for uart2
This patch adds a new pinmux for UART2, which shares the pins with SPIS.
Signed-off-by: Weijie Gao
---
Changes since v1: newly added
---
arch/mips/dts/mt7628a.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 744594c45a..f265cb6ad9 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -93,6 +93,11 @@
function = "uart2";
};
+ uart2_pwm_pins: uart2_pwm_pins {
+ groups = "spis";
+ function = "pwm_uart2";
+ };
+
i2c_pins: i2c_pins {
groups = "i2c";
function = "i2c";
--
2.17.1
[PATCH v2 11/21] dts: mtmips: remove all unusable nodes and properties from mt7628s.dtsi
This patch removes all unused and unusable nodes and properties from
mt7628s.dtsi.
Signed-off-by: Weijie Gao
---
Changes since v1: splitted from another patch
---
arch/mips/dts/mt7628a.dtsi | 68 --
1 file changed, 68 deletions(-)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index cdc643fe37..3d7b839e6d 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -7,24 +7,6 @@
#size-cells = <1>;
compatible = "ralink,mt7628a-soc";
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- compatible = "mti,mips24KEc";
- device_type = "cpu";
- reg = <0>;
- };
- };
-
- cpuintc: interrupt-controller {
- #address-cells = <0>;
- #interrupt-cells = <1>;
- interrupt-controller;
- compatible = "mti,cpu-interrupt-controller";
- };
-
clk48m: clk48m@0 {
compatible = "fixed-clock";
@@ -41,11 +23,6 @@
#address-cells = <1>;
#size-cells = <1>;
- sysc: system-controller@0 {
- compatible = "ralink,mt7620a-sysc", "syscon";
- reg = <0x0 0x100>;
- };
-
resetctl-reboot {
compatible = "resetctl-reboot";
@@ -223,32 +200,6 @@
resets = < MT7628_TIMER_RST>;
reset-names = "wdt";
-
- interrupt-parent = <>;
- interrupts = <24>;
- };
-
- intc: interrupt-controller@200 {
- compatible = "ralink,rt2880-intc";
- reg = <0x200 0x100>;
-
- interrupt-controller;
- #interrupt-cells = <1>;
-
- resets = < MT7628_INT_RST>;
- reset-names = "intc";
-
- interrupt-parent = <>;
- interrupts = <2>;
-
- ralink,intc-registers = <0x9c 0xa0
-0x6c 0xa4
-0x80 0x78>;
- };
-
- memory-controller@300 {
- compatible = "ralink,mt7620a-memc";
- reg = <0x300 0x100>;
};
gpio@600 {
@@ -261,9 +212,6 @@
resets = < MT7628_PIO_RST>;
reset-names = "pio";
- interrupt-parent = <>;
- interrupts = <6>;
-
gpio0: bank@0 {
reg = <0>;
compatible = "mtk,mt7621-gpio-bank";
@@ -311,9 +259,6 @@
resets = < MT7628_UART0_RST>;
reset-names = "uart0";
- interrupt-parent = <>;
- interrupts = <20>;
-
reg-shift = <2>;
};
@@ -329,9 +274,6 @@
resets = < MT7628_UART1_RST>;
reset-names = "uart1";
- interrupt-parent = <>;
- interrupts = <21>;
-
reg-shift = <2>;
};
@@ -347,9 +289,6 @@
resets = < MT7628_UART2_RST>;
reset-names = "uart2";
- interrupt-parent = <>;
- interrupts = <22>;
-
reg-shift = <2>;
};
};
@@ -361,8 +300,6 @@
resets = < MT7628_EPHY_RST>;
reset-names = "ephy";
-
- syscon = <>;
};
usb_phy: usb-phy@1012 {
@@ -371,8 +308,6 @@
#phy-cells = <0>;
- ralink,sysctl = <>;
-
resets = < MT7628_UPHY_RST>;
reset-names = "phy";
@@ -386,9 +321,6 @@
phys = <_phy>;
phy-names = "usb";
-
- interrupt-parent = <>;
- interrupts = <18>;
};
mmc: mmc@1013 {
--
2.17.1
[PATCH v2 04/21] mips: start.S: avoid overwriting outside gd when clearing global data in stack
When setting up initial stack, global data will also be put in the stack, and being cleared. The assembler instructions for clearing gd is as follows: movet0, k0 1: PTR_S zero, 0(t0) blt t0, t1, 1b PTR_ADDIU t0, PTRSIZE t0 is the start address of gd, t1 is the end address of gd (t0 + GD_SIZE). [PTR_ADDIU t0, PTRSIZE] is in the delay slot of [blt t0, t1, 1b], so it will be executed before the branch operation. However the comparison for the BLT instruction is done before executing the delay slot. This means when the last word just before k1 is cleared, the loop will continue to run once. This will clear an extra word at k1, which is outside the global data. Global data is placed at the top of the stack. If the initial stack is a SRAM or locked cache, the area outside them may be inaccessible. A write operation performed in this area may cause an exception. To solve this, [PTR_ADDIU t0, PTRSIZE] should be placed before the BLT instruction. Reviewed-by: Daniel Schwierzeck Reviewed-by: Stefan Roese Signed-off-by: Weijie Gao --- Changes since v1: none --- arch/mips/cpu/start.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index f9805fa000..dd93df9e4a 100644 --- a/arch/mips/cpu/start.S +++ b/arch/mips/cpu/start.S @@ -71,8 +71,9 @@ movet0, k0 1: PTR_S zero, 0(t0) + PTR_ADDIU t0, PTRSIZE blt t0, t1, 1b -PTR_ADDIU t0, PTRSIZE +nop #if CONFIG_VAL(SYS_MALLOC_F_LEN) PTR_S sp, GD_MALLOC_BASE(k0) # gd->malloc_base offset -- 2.17.1
[PATCH v2 05/21] sysreset: add reset controller based reboot driver
Some chips provide their sysreset function in reset controller, which is
normally a bit written to 1 to perform the sysreset.
This patch adds a new sysreset driver to take advantage of it.
Reviewed-by: Simon Glass
Signed-off-by: Weijie Gao
---
Changes since v1: none
---
drivers/sysreset/Kconfig | 6
drivers/sysreset/Makefile| 1 +
drivers/sysreset/sysreset_resetctl.c | 48
3 files changed, 55 insertions(+)
create mode 100644 drivers/sysreset/sysreset_resetctl.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index f09e138bb8..4be7433404 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -101,6 +101,12 @@ config SYSRESET_WATCHDOG
help
Reboot support for generic watchdog reset.
+config SYSRESET_RESETCTL
+ bool "Enable support for reset controller reboot driver"
+ select DM_RESET
+ help
+ Reboot support using generic reset controller.
+
config SYSRESET_X86
bool "Enable support for x86 processor reboot driver"
depends on X86
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 51af68fad3..3ed4bab9e3 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -16,5 +16,6 @@ obj-$(CONFIG_SYSRESET_SOCFPGA_S10) += sysreset_socfpga_s10.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
+obj-$(CONFIG_SYSRESET_RESETCTL) += sysreset_resetctl.o
obj-$(CONFIG_$(SPL_TPL_)SYSRESET_X86) += sysreset_x86.o
obj-$(CONFIG_TARGET_XTFPGA) += sysreset_xtfpga.o
diff --git a/drivers/sysreset/sysreset_resetctl.c
b/drivers/sysreset/sysreset_resetctl.c
new file mode 100644
index 00..b8203ba605
--- /dev/null
+++ b/drivers/sysreset/sysreset_resetctl.c
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ *
+ * Author: Weijie Gao
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct resetctl_reboot_priv {
+ struct reset_ctl_bulk resets;
+};
+
+static int resetctl_reboot_request(struct udevice *dev, enum sysreset_t type)
+{
+ struct resetctl_reboot_priv *priv = dev_get_priv(dev);
+
+ return reset_assert_bulk(>resets);
+}
+
+static struct sysreset_ops resetctl_reboot_ops = {
+ .request = resetctl_reboot_request,
+};
+
+int resetctl_reboot_probe(struct udevice *dev)
+{
+ struct resetctl_reboot_priv *priv = dev_get_priv(dev);
+
+ return reset_get_bulk(dev, >resets);
+}
+
+static const struct udevice_id resetctl_reboot_ids[] = {
+ { .compatible = "resetctl-reboot" },
+ { }
+};
+
+U_BOOT_DRIVER(resetctl_reboot) = {
+ .id = UCLASS_SYSRESET,
+ .name = "resetctl_reboot",
+ .of_match = resetctl_reboot_ids,
+ .ops = _reboot_ops,
+ .priv_auto_alloc_size = sizeof(struct resetctl_reboot_priv),
+ .probe = resetctl_reboot_probe,
+};
--
2.17.1
[PATCH v2 07/21] configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips boards
This patch enables CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips boards. Signed-off-by: Weijie Gao --- Changes since v1: Splitted from another patch. --- configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 + configs/gardena-smart-gateway-mt7688_defconfig | 1 + configs/linkit-smart-7688-ram_defconfig| 1 + configs/linkit-smart-7688_defconfig| 1 + 4 files changed, 4 insertions(+) diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig b/configs/gardena-smart-gateway-mt7688-ram_defconfig index 01fbc6e1a2..38c9272723 100644 --- a/configs/gardena-smart-gateway-mt7688-ram_defconfig +++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig @@ -7,6 +7,7 @@ CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y CONFIG_SYS_BOOTCOUNT_ADDR=0xb06c CONFIG_ENV_SECT_SIZE=0x1 CONFIG_ARCH_MTMIPS=y +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y # CONFIG_MIPS_BOOT_ENV_LEGACY is not set CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y diff --git a/configs/gardena-smart-gateway-mt7688_defconfig b/configs/gardena-smart-gateway-mt7688_defconfig index 9156c70155..cc0fa7f65b 100644 --- a/configs/gardena-smart-gateway-mt7688_defconfig +++ b/configs/gardena-smart-gateway-mt7688_defconfig @@ -10,6 +10,7 @@ CONFIG_ARCH_MTMIPS=y CONFIG_BOOT_ROM=y CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y # CONFIG_MIPS_BOOT_ENV_LEGACY is not set CONFIG_MIPS_BOOT_FDT=y CONFIG_ENV_VARS_UBOOT_CONFIG=y diff --git a/configs/linkit-smart-7688-ram_defconfig b/configs/linkit-smart-7688-ram_defconfig index 10a0438245..6d8969aacb 100644 --- a/configs/linkit-smart-7688-ram_defconfig +++ b/configs/linkit-smart-7688-ram_defconfig @@ -6,6 +6,7 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SECT_SIZE=0x1 CONFIG_ARCH_MTMIPS=y CONFIG_BOARD_LINKIT_SMART_7688=y +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y # CONFIG_MIPS_BOOT_ENV_LEGACY is not set CONFIG_MIPS_BOOT_FDT=y CONFIG_FIT=y diff --git a/configs/linkit-smart-7688_defconfig b/configs/linkit-smart-7688_defconfig index 9e12d164e1..9824c77aae 100644 --- a/configs/linkit-smart-7688_defconfig +++ b/configs/linkit-smart-7688_defconfig @@ -9,6 +9,7 @@ CONFIG_BOARD_LINKIT_SMART_7688=y CONFIG_BOOT_ROM=y CONFIG_ONBOARD_DDR2_SIZE_1024MBIT=y CONFIG_ONBOARD_DDR2_CHIP_WIDTH_16BIT=y +CONFIG_RESTORE_EXCEPTION_VECTOR_BASE=y # CONFIG_MIPS_BOOT_ENV_LEGACY is not set CONFIG_MIPS_BOOT_FDT=y CONFIG_FIT=y -- 2.17.1
[PATCH v2 00/21] Refactor the architecture parts of mt7628
This patch series are divided into two parts: The main part is to rewrite the whole architecture code of mt7628: 1. Lock parts of the d-cache for initial stack so the rest of the code can be reimplemented in C. 2. Memory controller & DDR initialization have been fully written to support detecting DDR size automatically. 3. DDR calibration has also been reimplemented with a clear logic. 4. Implemented a new sysreset driver to take advantage of the reset controller so we can drop the use of syscon-based sysreset to reduce size. The second part is to add SPL support for mt7628: 1. With SPL enabled we can build the ROM-bootable and RAM-bootable binary simultaneously, and we can drop RAM boot related configs and defconfig files. 2. Generate compressed u-boot.bin image for SPL to reduce size of final combined binary. 3. Enable DM support for SPL for a more flexible device probing. 4. Add a demo board (mt7628_rfb) aims at router application. Changes since v1: 1. Split 'mips: mtmips: rewrite lowlevel codes of mt7628' into multiple patches. 2. Dropped a patch which tried to use customized get_tbclk(). 3. Dropped a patch which tried to rename mt7628a.dtsi to mt7628.dtsi 4. Refactor the patch which restores exception vector base before booting linux. 5. Define a new option to enable u_boot_list in SPL. 6. Enable compressed spl payload for all boards. 7. Enable DM and DT support for linkit and gardena-smart-gateway. 8. Complete pinmux for all three UARTs for SPL. 9. Rewrite u_boot_lzma_img.py. Weijie Gao (21): mips: add support to restore exception vector base before booting linux mips: mtmips: add predefined i-cache/d-cache size and linesize mips: add an option to support initialize SRAM for initial stack mips: start.S: avoid overwriting outside gd when clearing global data in stack sysreset: add reset controller based reboot driver mips: mtmips: make use of sysreset-resetctrl for mt7628 soc configs: enable CONFIG_RESTORE_EXCEPTION_VECTOR_BASE for all mtmips boards mips: add a mtmips-specific field to architecture-specific global data mips: add a option to support not reserving malloc space on initial stack mips: mtmips: rewrite lowlevel codes of mt7628 dts: mtmips: remove all unusable nodes and properties from mt7628s.dtsi dts: mtmips: add u-boot,dm-pre-reloc for some nodes in mt7628a.dtsi dts: mtmips: add alternative pinmux node for uart2 mips: enable support for appending dtb to spl binary mips: add an option to enable u_boot_list section for SPL loaders in u-boot-spl.lds lib: enable lzma decompression support for SPL build Makefile: add support to generate LZMA compressed u-boot image tools: binman: add etype file for u-boot-lzma-img mips: mtmips: add SPL support mips: mtmips: enable SPL for all boards mips: mtmips: add support for mt7628-rfb Makefile | 22 ++ arch/mips/Kconfig | 60 arch/mips/cpu/start.S | 16 +- arch/mips/cpu/u-boot-spl.lds | 4 +- arch/mips/dts/Makefile| 1 + arch/mips/dts/mediatek,mt7628-rfb.dts | 67 arch/mips/dts/mt7628-u-boot.dtsi | 24 ++ arch/mips/dts/mt7628a.dtsi| 93 ++--- arch/mips/include/asm/global_data.h | 3 + arch/mips/include/asm/u-boot-mips.h | 2 + arch/mips/lib/bootm.c | 3 + arch/mips/lib/traps.c | 19 + arch/mips/mach-mtmips/Kconfig | 133 +++ arch/mips/mach-mtmips/Makefile| 8 +- arch/mips/mach-mtmips/cpu.c | 58 +--- arch/mips/mach-mtmips/ddr_cal.c | 211 +++ arch/mips/mach-mtmips/ddr_calibrate.c | 309 - arch/mips/mach-mtmips/ddr_init.c | 194 +++ arch/mips/mach-mtmips/include/mach/ddr.h | 52 +++ arch/mips/mach-mtmips/include/mach/mc.h | 180 ++ arch/mips/mach-mtmips/include/mach/serial.h | 13 + arch/mips/mach-mtmips/include/mach/spl.h | 14 + arch/mips/mach-mtmips/lowlevel_init.S | 328 -- arch/mips/mach-mtmips/mt7628/Makefile | 6 + arch/mips/mach-mtmips/mt7628/ddr.c| 173 + arch/mips/mach-mtmips/mt7628/init.c | 109 ++ arch/mips/mach-mtmips/mt7628/lowlevel_init.S | 161 + arch/mips/mach-mtmips/mt7628/mt7628.h | 104 ++ arch/mips/mach-mtmips/mt7628/serial.c | 34 ++ arch/mips/mach-mtmips/mt76xx.h| 32 -- arch/mips/mach-mtmips/spl.c | 35 ++ arch/mips/mach-mtmips/spl_load.c | 121 +++ board/gardena/smart-gateway-mt7688/board.c| 2 + board/mediatek/mt7628/Kconfig | 12 + board/mediatek/mt7628/MAINTAINERS | 7 + board/mediatek/mt7628/Makefile| 3 +
[PATCH v2 06/21] mips: mtmips: make use of sysreset-resetctrl for mt7628 soc
This patch replaces sysreset-syscon with sysreset-resetctrl for mt7628 soc.
Signed-off-by: Weijie Gao
---
Changes since v1: splitted from another patch.
---
arch/mips/dts/mt7628a.dtsi | 10 +-
arch/mips/mach-mtmips/Kconfig | 1 +
configs/gardena-smart-gateway-mt7688-ram_defconfig | 1 -
configs/gardena-smart-gateway-mt7688_defconfig | 1 -
configs/linkit-smart-7688-ram_defconfig| 1 -
configs/linkit-smart-7688_defconfig| 1 -
6 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/mips/dts/mt7628a.dtsi b/arch/mips/dts/mt7628a.dtsi
index 76a80c8952..cdc643fe37 100644
--- a/arch/mips/dts/mt7628a.dtsi
+++ b/arch/mips/dts/mt7628a.dtsi
@@ -46,11 +46,11 @@
reg = <0x0 0x100>;
};
- syscon-reboot {
- compatible = "syscon-reboot";
- regmap = <>;
- offset = <0x34>;
- mask = <0x1>;
+ resetctl-reboot {
+ compatible = "resetctl-reboot";
+
+ resets = < MT7628_SYS_RST>;
+ reset-names = "sysreset";
};
clkctrl: clkctrl@0x2c {
diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig
index 8e10719b27..8cb76c4560 100644
--- a/arch/mips/mach-mtmips/Kconfig
+++ b/arch/mips/mach-mtmips/Kconfig
@@ -27,6 +27,7 @@ config SOC_MT7628
select MIPS_L1_CACHE_SHIFT_5
select PINCTRL_MT7628
select MTK_SERIAL
+ select SYSRESET_RESETCTL
help
This supports MediaTek MT7628/MT7688.
diff --git a/configs/gardena-smart-gateway-mt7688-ram_defconfig
b/configs/gardena-smart-gateway-mt7688-ram_defconfig
index 979dcb5920..01fbc6e1a2 100644
--- a/configs/gardena-smart-gateway-mt7688-ram_defconfig
+++ b/configs/gardena-smart-gateway-mt7688-ram_defconfig
@@ -68,7 +68,6 @@ CONFIG_MT7628_ETH=y
CONFIG_PHY=y
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
CONFIG_WDT=y
CONFIG_WDT_MT7621=y
CONFIG_LZMA=y
diff --git a/configs/gardena-smart-gateway-mt7688_defconfig
b/configs/gardena-smart-gateway-mt7688_defconfig
index e8403a88fb..9156c70155 100644
--- a/configs/gardena-smart-gateway-mt7688_defconfig
+++ b/configs/gardena-smart-gateway-mt7688_defconfig
@@ -71,7 +71,6 @@ CONFIG_MT7628_ETH=y
CONFIG_PHY=y
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
CONFIG_WDT=y
CONFIG_WDT_MT7621=y
CONFIG_LZMA=y
diff --git a/configs/linkit-smart-7688-ram_defconfig
b/configs/linkit-smart-7688-ram_defconfig
index 6d2e9e4298..10a0438245 100644
--- a/configs/linkit-smart-7688-ram_defconfig
+++ b/configs/linkit-smart-7688-ram_defconfig
@@ -53,7 +53,6 @@ CONFIG_PHY=y
CONFIG_MT76X8_USB_PHY=y
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
diff --git a/configs/linkit-smart-7688_defconfig
b/configs/linkit-smart-7688_defconfig
index 28c8be2d53..9e12d164e1 100644
--- a/configs/linkit-smart-7688_defconfig
+++ b/configs/linkit-smart-7688_defconfig
@@ -57,7 +57,6 @@ CONFIG_PHY=y
CONFIG_MT76X8_USB_PHY=y
CONFIG_SPI=y
CONFIG_MT7621_SPI=y
-CONFIG_SYSRESET_SYSCON=y
CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_EHCI_HCD=y
--
2.17.1
[PATCH v2 03/21] mips: add an option to support initialize SRAM for initial stack
Currently CONFIG_MIPS_INIT_STACK_IN_SRAM assumes the memory space for the initial stack can be used directly. However on some platform the SRAM needs initialization, e.g. lock cache. This patch adds an option to allow a new function mips_sram_init() being called before setup_stack_gd. Reviewed-by: Daniel Schwierzeck Reviewed-by: Stefan Roese Signed-off-by: Weijie Gao --- Changes since v1: none --- arch/mips/Kconfig | 9 + arch/mips/cpu/start.S | 7 +++ 2 files changed, 16 insertions(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 5e20feeefb..bf30a56101 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -419,6 +419,15 @@ config MIPS_INIT_STACK_IN_SRAM lowlevel_init. Thus lowlevel_init does not need to be implemented in assembler. +config MIPS_SRAM_INIT + bool + default n + depends on MIPS_INIT_STACK_IN_SRAM + help + Select this if the SRAM for initial stack needs to be initialized + before it can be used. If enabled, a function mips_sram_init() will + be called just before setup_stack_gd. + config SYS_DCACHE_SIZE int default 0 diff --git a/arch/mips/cpu/start.S b/arch/mips/cpu/start.S index 1d21b2324a..f9805fa000 100644 --- a/arch/mips/cpu/start.S +++ b/arch/mips/cpu/start.S @@ -216,6 +216,13 @@ wr_done: #endif #ifdef CONFIG_MIPS_INIT_STACK_IN_SRAM +#ifdef CONFIG_MIPS_SRAM_INIT + /* Initialize the SRAM first */ + PTR_LA t9, mips_sram_init + jalrt9 +nop +#endif + /* Set up initial stack and global data */ setup_stack_gd -- 2.17.1
[PATCH v2 02/21] mips: mtmips: add predefined i-cache/d-cache size and linesize
Both mt7620 and mt7628 has the same cache configuration. There is no need to use CONFIG_SYS_CACHE_SIZE_AUTO to probe it at runtime. Add them into Kconfig to reduce some code size. Reviewed-by: Stefan Roese Signed-off-by: Weijie Gao --- Changes since v1: none --- arch/mips/mach-mtmips/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/arch/mips/mach-mtmips/Kconfig b/arch/mips/mach-mtmips/Kconfig index c8dcf19c0d..8e10719b27 100644 --- a/arch/mips/mach-mtmips/Kconfig +++ b/arch/mips/mach-mtmips/Kconfig @@ -7,6 +7,18 @@ config SYS_MALLOC_F_LEN config SYS_SOC default "mt7628" if SOC_MT7628 +config SYS_DCACHE_SIZE + default 32768 + +config SYS_DCACHE_LINE_SIZE + default 32 + +config SYS_ICACHE_SIZE + default 65536 + +config SYS_ICACHE_LINE_SIZE + default 32 + choice prompt "MediaTek MIPS SoC select" -- 2.17.1
[PATCH] versal: drivers: clk: Fix invalid clock name queries
From: Rajan Vaja The clock driver makes EEMI call to get the name of invalid clk when executing versal_get_clock_info() function. This results in error messages. Added check for validating clock before saving clock attribute and calling versal_pm_clock_get_name() in versal_get_clock_info() function. Signed-off-by: Rajan Vaja Signed-off-by: Michal Simek --- drivers/clk/clk_versal.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/clk/clk_versal.c b/drivers/clk/clk_versal.c index 7e97b0c4bf3a..6ca46c612df8 100644 --- a/drivers/clk/clk_versal.c +++ b/drivers/clk/clk_versal.c @@ -569,6 +569,12 @@ static void versal_get_clock_info(void) continue; clock[i].valid = attr & CLK_VALID_MASK; + + /* skip query for Invalid clock */ + ret = versal_is_valid_clock(i); + if (ret != CLK_VALID_MASK) + continue; + clock[i].type = ((attr >> CLK_TYPE_SHIFT) & 0x1) ? CLK_TYPE_EXTERNAL : CLK_TYPE_OUTPUT; nodetype = (attr >> NODE_TYPE_SHIFT) & NODE_CLASS_MASK; -- 2.25.0
Re: [PATCH v7 5/7] arm: dts: rk3188: Add rk3188-u-boot.dtsi
On 2020/1/10 上午2:46, Jagan Teki wrote:
Add U-Boot specific dtsi file for rk3188 SoC. This
would help to add U-Boot specific dts nodes, properties
which are common across rk3188.
Right now, the file is empty, will add required changes
in future patches.
Signed-off-by: Jagan Teki
Reviewed-by: Kever Yang
Thanks,
- Kever
---
arch/arm/dts/rk3188-radxarock-u-boot.dtsi | 2 ++
arch/arm/dts/rk3188-u-boot.dtsi | 4
2 files changed, 6 insertions(+)
create mode 100644 arch/arm/dts/rk3188-u-boot.dtsi
diff --git a/arch/arm/dts/rk3188-radxarock-u-boot.dtsi
b/arch/arm/dts/rk3188-radxarock-u-boot.dtsi
index 1bb5408592..204bb3a90e 100644
--- a/arch/arm/dts/rk3188-radxarock-u-boot.dtsi
+++ b/arch/arm/dts/rk3188-radxarock-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (c) 2018 Fuzhou Rockchip Electronics Co., Ltd.
*/
+#include "rk3188-u-boot.dtsi"
+
{
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/rk3188-u-boot.dtsi b/arch/arm/dts/rk3188-u-boot.dtsi
new file mode 100644
index 00..1e7d079315
--- /dev/null
+++ b/arch/arm/dts/rk3188-u-boot.dtsi
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Jagan Teki
+ */
Re: [PATCH v4 6/8] watchdog: kconfig: Enable designware for rk3399
On 2020/1/9 下午4:52, Jagan Teki wrote: Enable designware watchdog driver for rk3399 if WDT defined. Cc: Marek Vasut Signed-off-by: Jagan Teki Reviewed-by: Kever Yang Thanks, - Kever --- Changes for v4: - This change on top of below series https://patchwork.ozlabs.org/project/uboot/list/?series=151431 drivers/watchdog/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index bf5612a811..ceefee3a6b 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -48,6 +48,7 @@ config ULP_WATCHDOG config DESIGNWARE_WATCHDOG bool "Designware watchdog timer support" select HW_WATCHDOG if !WDT + default y if WDT && ROCKCHIP_RK3399 help Enable this to support Designware Watchdog Timer IP, present e.g. on Altera SoCFPGA SoCs.
Re: [PATCH v4 00/16] efi_loader: add secure boot support
[...] > > > If we implement secure boot according the UEFI specification, one option > > > would be to package the device tree as a UEFI driver image and let the > > > stub install it as a configuration table. The unload callback could be > > > used to remove the device tree. > > > > > > > Sure but this is not in scope for the current patchset is it? > > Exactly. > > > Similarly you can just include the DTB in U-Boot and naturally have it > > verified. > > > > I am not arguing that DTB verification is needed. We absolutely agree on > > that. > > All i am saying is that the extra functionality can be added in the future, > > since we already have a valid way of providing it with the current patchset. > > BTW, Ilias, > where should such a discussion about dtb verification be held, > Boot-arch ML, Linaro Connect, ELC or whatever else conference? > Otherwise just leave the decision in distributors' hands? We did send some e-mails on boot-arch ML in the past [1]. The subject is quite controversial since there are a lot of opinions on this. I think Linaro is working on a device tree evolution project at the moment with one of the subjects being device tree verification. We can certainly discuss more during Linaro Connect. [1] https://lists.linaro.org/pipermail/boot-architecture/2019-June/001053.html Thanks /Ilias > > Thanks, > -Takahiro Akashi > > > Regards > > /Ilias > > > > > > > > > > > > > Best regards > > > > > > > > > > Heinrich > > > > > > >
Re: [PATCH 0/2] Enable private ATF handoff structure
On 16. 01. 20 11:05, Marek Vasut wrote: > On 1/16/20 10:42 AM, Michal Simek wrote: >> On 16. 01. 20 10:10, Marek Vasut wrote: >>> On 1/16/20 8:25 AM, Michal Simek wrote: čt 19. 12. 2019 v 18:32 odesílatel Michal Simek napsal: > > Hi, > > Xilinx ZynqMP platform is using from the beggining specific structure > which > is passed from FSBL/SPL to ATF. > Maybe in future both options can be supported by ATF and we can remove > this > private structure completely. But as of now bl31_params are completely > ignored by ATF by RESET_TO_BL31=1 build flag. > > Thanks, > Michal > > > Michal Simek (2): > spl: atf: Enable option to rewrite bl2_plat_get_bl31_params() > arm: zynqmp: Wire SPL/ATF handoff structure properly > > arch/arm/mach-zynqmp/handoff.c| 17 +++- > arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 -- > arch/arm/mach-zynqmp/spl.c| 2 -- > common/spl/spl_atf.c | 15 +- > include/spl.h | 20 +++ > 5 files changed, 33 insertions(+), 23 deletions(-) > > -- > 2.24.0 > Applied. >>> >>> Can't you rather pass DT around ? >>> >> >> Unfortunately not. The best will be just update ATF to support standard >> method how to get information but that means that we break all backward >> compatibility and nothing will work. > > Isn't that what Xilinx does with their ABI between all BSP versions ? > The only stable thing is the ABI version, which never changes :-) This handoff structure is stable from beginning. >> Xilinx handoff structure is around fro quite a long time and that's >> something I need to unfortunately live with. > > Maybe you can develop a better method (DT) in parallel and slowly switch > over then ? bl2_plat_get_bl31_params() is something what it is used by ATF for a long time. Not sure if they are moving to DT way how to describe stuff. But from my point of view having alternatives and a way for conversion is right way to go. Thanks, Michal
[PATCH] clk: sci-clk: add slack to clk-set-rate passed to firmware
Add slack to the clock frequency parameters passed to firmware within clk_set_rate. min-freq is changed to 0 and max-rate is changed to ULONG_MAX. This fixes certain issues with pll clock rounding when the firmware is not able to set the frequency exactly to the target, the current implementation fails if the available frequency is even 1Hz off the target. With the change, the firmware still tries its best to set the frequency as close as possible to the target. Reported-by: Vishal Mahaveer Signed-off-by: Lokesh Vutla Signed-off-by: Tero Kristo --- drivers/clk/clk-ti-sci.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/clk/clk-ti-sci.c b/drivers/clk/clk-ti-sci.c index 478349f22f..ed1facbbcd 100644 --- a/drivers/clk/clk-ti-sci.c +++ b/drivers/clk/clk-ti-sci.c @@ -106,8 +106,7 @@ static ulong ti_sci_clk_set_rate(struct clk *clk, ulong rate) k3_avs_notify_freq(clk->id, clk->data, rate); #endif - /* Ask for exact frequency by using same value for min/target/max */ - ret = cops->set_freq(sci, clk->id, clk->data, rate, rate, rate); + ret = cops->set_freq(sci, clk->id, clk->data, 0, rate, ULONG_MAX); if (ret) dev_err(clk->dev, "%s: set_freq failed (%d)\n", __func__, ret); -- 2.23.0
Re: fat: handle Windows formatted partition (thru USB Mass Storage)
On Thu, Jan 16, 2020 at 10:31:49PM +0200, Andy Shevchenko wrote: > On Thu, Jan 16, 2020 at 9:20 PM Heinrich Schuchardt > wrote: > > On 1/16/20 11:39 AM, Andy Shevchenko wrote: > > > > > >>> Obviously U-Boot's fat code cannot handle it. > > >> > > >> So precisely, U-Boot cannot handle nested partition( table)s? > > > > > > Seems so. We need to be able to supply the partition number we would > > > like to open, something like > > >cmd [[:[:]]] > > > otherwise it will require some (error prone) heuristics to understand > > > which one user would like to use. > > > > > > > I have formatted a USB stick Windows 10. > > That is *not* the case I'm describing. > > Maybe I described it wrong. Let me try again. > > Prerequisites: > - the board with U-Boot and installed Linux OS on eMMC > - g_multi module in Linux OS that shares *one of the eMMC partitions* > (pay attention here) as a disk to Windows host I also misunderstood your assumption above; You are developing a linux-based USB gadget for Windows (10)? > Now, when you format that exposed disk (which is actually a partition > on eMMC!) in Windows, you will get nested partitioning. So why do you want to access *that* partition from U-Boot on the board? I don't think it is a common case. -Takahiro Akashi > P.S. I can easily reproduce this on real device with latest U-Boot. > U-Boot has obvious issue with recognizing such disks. > > -- > With Best Regards, > Andy Shevchenko
Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
On 16/01/20 11:46 PM, Tom Rini wrote:
> On Thu, Jan 16, 2020 at 08:03:51PM +0200, Igor Opaniuk wrote:
>> Hi Fabio,
>>
>> On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam wrote:
>>>
>>> Hi Anatolij,
>>>
>>> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin wrote:
>>>
Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot
test, but I have an i.MX8QXP based custom SoM with console on ttyLP2.
Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga
and it boots successfully (with NFS rootfs or rootfs on eMMC).
>>>
>>> I have just tested imx_4.14.98_2.0.0_ga and still get the same hang.
>>>
>>> [Adding Marcel]
>> Marcel is on vacation.
>>
>> FYI, mainline U-boot is broken on all our iMX8QXP and iMX8QM SoMs
>> at all since f0cc4eae9a ("core: device: use dev_power_domain_on") is merged,
>> the
>> status hasn't changed. I haven't got deeply into this issue, just
>> quickly tried different
>> combinations of TF-A and SECO/SCFW, none of them has any impact.
>> Will get back to this issue soon.
>>>
>>> Just wondering if anyone else managed to boot mainline U-Boot with
>>> mainline kernel on i.MX8QXP.
>> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
>
> Adding in Lokesh as he nak'd the revert before because that would break
> other platforms and I chimed in saying that breaking one set of
> platforms to unbreak another set of platforms isn't a trade-off I like.
>
Right, the mentioned patch f0cc4eae9a1 ("core: device: use dev_power_domain_on")
checks for power_domain return status when dm core tries to enable pd during
probe. If power domain enabling is failed then no point proceeding further to
probe.
There are 2 ways to solve this:
1) Drop the return check like below. Which IMHO is a hack:
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 9f39218423..c80ce16fbd 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -432,11 +432,8 @@ int device_probe(struct udevice *dev)
if (CONFIG_IS_ENABLED(POWER_DOMAIN) && dev->parent &&
(device_get_uclass_id(dev) != UCLASS_POWER_DOMAIN) &&
- !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF)) {
- ret = dev_power_domain_on(dev);
- if (ret)
- goto fail;
- }
+ !(drv->flags & DM_FLAG_DEFAULT_PD_CTRL_OFF))
+ dev_power_domain_on(dev);
ret = uclass_pre_probe_device(dev);
if (ret)
2) Debug which device power-domain is failing and fix the driver or make sure
that dm core will not touch the pd by enabling the flag
DM_FLAG_DEFAULT_PD_CTRL_OFF in it.
Thanks and regards,
Lokesh
[PATCH] mmc: fix the build error when MMC_WRITE is disabled
erase_grp_size is used, when MMC_WRITE is enabled. - error: ‘struct mmc’ has no member named ‘erase_grp_size’ Signed-off-by: Jaehoon Chung --- drivers/mmc/mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index d43983d4a6..6a2b855435 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -1126,9 +1126,11 @@ int mmc_hwpart_config(struct mmc *mmc, ext_csd[EXT_CSD_ERASE_GROUP_DEF] = 1; +#if CONFIG_IS_ENABLED(MMC_WRITE) /* update erase group size to be high-capacity */ mmc->erase_grp_size = ext_csd[EXT_CSD_HC_ERASE_GRP_SIZE] * 1024; +#endif } -- 2.24.1
Re: [PATCH v4 00/16] efi_loader: add secure boot support
On Thu, Jan 09, 2020 at 10:03:33PM +0200, Ilias Apalodimas wrote: > On Thu, Jan 09, 2020 at 08:09:27PM +0100, Heinrich Schuchardt wrote: > > On 1/9/20 9:02 AM, Ilias Apalodimas wrote: > > > On Thu, Jan 09, 2020 at 01:08:35AM +0100, Heinrich Schuchardt wrote: > > > > On 12/18/19 1:44 AM, AKASHI Takahiro wrote: > > > > > One of major missing features in current UEFI implementation is > > > > > "secure boot." > > > > > The ultimate goal of my attempt is to implement image authentication > > > > > based > > > > > on signature and provide UEFI secure boot support which would be fully > > > > > compliant with UEFI specification, section 32[1]. > > > > > (The code was originally developed by Patrick Wildt.) > > > > > > > > > > Please note, however, this patch doesn't work on its own; there are > > > > > a couple of functional dependencies[2] and [3], that I have submitted > > > > > before. For complete workable patch set, see my repository[4], > > > > > which also contains experimental timestamp-based revocation suuport. > > > > > > > > > > My "non-volatile" support[5], which is under discussion, is not > > > > > mandatory > > > > > and so not included here, but this inevitably implies that, for > > > > > example, > > > > > signature database variables, like db and dbx, won't be persistent > > > > > unless you > > > > > explicitly run "env save" command and that UEFI variables are not > > > > > separated > > > > > from U-Boot environment. Anyhow, Linaro is also working on > > > > > implementing > > > > > real "secure storage" solution based on TF-A and OP-TEE. > > > > > > > > > > > > > Device trees can be used for denial of service or to destroy hardware. > > > > > > > > How will you address the validation of device trees? > > > > > > Although this is really simple to solve, factoring in the different vendor > > > needs makes it quite complex. > > > There's a couple of options we can consider and not all of them are sane. > > > > > > 1. U-Boot embeds the DTB. This is straightforward. On Arm devices TF-A > > > verifies U-boot so you natively end up with a verified DTB. If U-Boot > > > does not > > > include the proper DTB (as is the case for several devices), one can > > > always > > > complite the correct DTB and compile with EXT_DTB. > > > 2. Use https://github.com/jiazhang0/SELoader which verifies non-PE files > > > 3. Add some custom code and use UEFI keyring to verify non PE files. This > > > is a > > > bad idea though since you'll 'polute' the UEFI keyring. > > > 4. FIT for DTB (??) > > > > > > In any case UEFI job is to verify PE/COFF executables and that's what > > > this patch > > > provides. DTB verification is beyond UEFI secure boot patches imho. > > > > > > Regards > > > /Ilias > > > > The UEFI specification does not mention device trees at all. EDK2 is > > based on ACPI tables. > > On one of the platforms i kknow of (socionext synquacer), it also provides DTB > as part of the firmware, which is identical to proposeal (1) I mentioned. > > > > > We already have verified boot via signed UEFI FIT images which can > > contain an UEFI image and a device tree. So for verified boot of Linux > > you would simply package shim and the device tree into a FIT image. Shim > > would verify GRUB and GRUB would verify the kernel and the ramdisk. In > > this scenario we don't need the current patch series at all and it > > integrates well with distributions like Debian which provide shim for > > arm64, cf. https://packages.debian.org/de/bullseye/shim-signed . > > Of course everything is verified, but that's not UEFI secure boot. It's > similar > but the verification does not go through DB/DBX and there are no secure > variables, so the current patchset has value. I believe that db/dbx schemes give us, distributors as well as users, more flexible manner of managing secure boot process. > > > > If we implement secure boot according the UEFI specification, one option > > would be to package the device tree as a UEFI driver image and let the > > stub install it as a configuration table. The unload callback could be > > used to remove the device tree. > > > > Sure but this is not in scope for the current patchset is it? Exactly. > Similarly you can just include the DTB in U-Boot and naturally have it > verified. > > I am not arguing that DTB verification is needed. We absolutely agree on that. > All i am saying is that the extra functionality can be added in the future, > since we already have a valid way of providing it with the current patchset. BTW, Ilias, where should such a discussion about dtb verification be held, Boot-arch ML, Linaro Connect, ELC or whatever else conference? Otherwise just leave the decision in distributors' hands? Thanks, -Takahiro Akashi > Regards > /Ilias > > > > > > > > > > Best regards > > > > > > > > Heinrich > > > > >
Re: [PATCH v4 2/6] rsa: add CONFIG_RSA_VERIFY_WITH_PKEY config
On 1/17/20 3:24 AM, AKASHI Takahiro wrote: On Tue, Jan 14, 2020 at 12:43:40PM +0100, Heinrich Schuchardt wrote: On 1/14/20 8:45 AM, AKASHI Takahiro wrote: On Wed, Jan 08, 2020 at 01:35:13PM +0100, Heinrich Schuchardt wrote: On 11/21/19 1:11 AM, AKASHI Takahiro wrote: In the next couple of commits, under new CONFIG_RSA_VERIFY_WITH_PKEY, rsa_verify() will be extended to be able to perform RSA decryption without additional RSA key properties from FIT image, i.e. rr and n0inv. Signed-off-by: AKASHI Takahiro Reviewed-by: Simon Glass The patch series does not build for some configurations. --- lib/rsa/Kconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index 03ffa2969048..71e4c06bf883 100644 --- a/lib/rsa/Kconfig +++ b/lib/rsa/Kconfig @@ -30,6 +30,20 @@ config RSA_VERIFY help Add RSA signature verification support. +config RSA_VERIFY_WITH_PKEY For CONFIG_RSA_VERIFY_WITH_PKEY=y and CONFIG_RSA_PUBLIC_KEY_PARSER=n I get an error: This error is inevitable as both RSA_VERIFY_WITH_PKEY and RSA_PUBLIC_KEY_PARSER are "select"able configurations with visible prompts and then No, it is not inevitbable. Just ensure that in the Makefiles all modules are selected that you need for your configuration. How? Can you please show me a simple solution? ifneq($(CONFIG_RSA_VERIFY_WITH_PKEY)$(CONFIG_RSA_PUBLIC_KEY_PARSER),) obj-y += foo.o endif or config RSA_VERIFY_WITH_PKEY depends on RSA_PUBLIC_KEY_PARSER or config RSA_VERIFY_WITH_PKEY select RSA_PUBLIC_KEY_PARSER Best regards Heinrich Thanks, -Takahiro Akashi we should generally avoid potential illegal configurations; Yes, we want to avoid potentially illegal configurations everywhere. This is why we have a randconfig build target. Best regards Heinrich The one should NOT forcibly select the other as the kernel kconfig document suggests. # Note: #select should be used with care. select will force #a symbol to a value without visiting the dependencies. #By abusing select you are able to select a symbol FOO even #if FOO depends on BAR that is not set. #In general use select only for non-visible symbols #(no prompts anywhere) and for symbols with no dependencies. #That will limit the usefulness but on the other hand avoid #the illegal configurations all over. -Takahiro Akashi lib/rsa/rsa-keyprop.c:669: undefined reference to `rsa_parse_pub_key' RSA_PUBLIC_KEY_PARSER depends on ASYMMETRIC_KEY_TYPE [=n] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=n] Please, fix the dependencies. Best regards Heinrich + bool "Execute RSA verification without key parameters from FDT" + depends on RSA + help + The standard RSA-signature verification code (FIT_SIGNATURE) uses + pre-calculated key properties, that are stored in fdt blob, in + decrypting a signature. + This does not suit the use case where there is no way defined to + provide such additional key properties in standardized form, + particularly UEFI secure boot. + This options enables RSA signature verification with a public key + directly specified in image_sign_info, where all the necessary + key properties will be calculated on the fly in verification code. + config RSA_SOFTWARE_EXP bool "Enable driver for RSA Modular Exponentiation in software" depends on DM
Re: [PATCH v4 08/16] efi_loader: image_loader: support image authentication
On 1/17/20 6:11 AM, AKASHI Takahiro wrote:
On Thu, Jan 09, 2020 at 12:55:17AM +0100, Heinrich Schuchardt wrote:
On 12/18/19 1:45 AM, AKASHI Takahiro wrote:
With this commit, image validation can be enforced, as UEFI specification
section 32.5 describes, if CONFIG_EFI_SECURE_BOOT is enabled.
Currently we support
* authentication based on db and dbx,
so dbx-validated image will always be rejected.
* following signature types:
EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images)
EFI_CERT_X509_GUID (x509 certificate for signed images)
Timestamp-based certificate revocation is not supported here.
Internally, authentication data is stored in one of certificates tables
of PE image (See efi_image_parse()) and will be verified by
efi_image_authenticate() before loading a given image.
It seems that UEFI specification defines the verification process
in a bit ambiguous way. I tried to implement it as closely to as
EDK2 does.
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 7 +-
lib/efi_loader/efi_boottime.c | 2 +-
lib/efi_loader/efi_image_loader.c | 454 +-
3 files changed, 449 insertions(+), 14 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 1f88caf86709..e12b49098fb0 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
static inline int guidcmp(const void *g1, const void *g2)
{
@@ -398,7 +399,8 @@ efi_status_t efi_set_watchdog(unsigned long timeout);
/* Called from places to check whether a timer expired */
void efi_timer_check(void);
/* PE loader implementation */
-efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle, void *efi,
+efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
+void *efi, size_t efi_size,
struct efi_loaded_image *loaded_image_info);
/* Called once to store the pristine gd pointer */
void efi_save_gd(void);
@@ -726,6 +728,9 @@ void efi_sigstore_free(struct efi_signature_store
*sigstore);
struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name);
bool efi_secure_boot_enabled(void);
+
+bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
+WIN_CERTIFICATE **auth, size_t *auth_len);
#endif /* CONFIG_EFI_SECURE_BOOT */
#else /* CONFIG_IS_ENABLED(EFI_LOADER) */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 493d906c641d..311681764034 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1879,7 +1879,7 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
efi_dp_split_file_path(file_path, , );
ret = efi_setup_loaded_image(dp, fp, image_obj, );
if (ret == EFI_SUCCESS)
- ret = efi_load_pe(*image_obj, dest_buffer, info);
+ ret = efi_load_pe(*image_obj, dest_buffer, source_size, info);
if (!source_buffer)
/* Release buffer to which file was loaded */
efi_free_pages((uintptr_t)dest_buffer,
diff --git a/lib/efi_loader/efi_image_loader.c
b/lib/efi_loader/efi_image_loader.c
index 13541cfa7a28..939758e61e3c 100644
--- a/lib/efi_loader/efi_image_loader.c
+++ b/lib/efi_loader/efi_image_loader.c
@@ -9,7 +9,9 @@
#include
#include
+#include
#include
+#include "../lib/crypto/pkcs7_parser.h"
const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID;
@@ -205,6 +207,367 @@ static void efi_set_code_and_data_type(
}
}
+#ifdef CONFIG_EFI_SECURE_BOOT
+/**
+ * efi_image_parse - parse a PE image
+ * @efi: Pointer to image
+ * @len: Size of @efi
+ * @regs: Pointer to a list of regions
+ * @auth: Pointer to a pointer to authentication data in PE
+ * @auth_len: Size of @auth
+ *
+ * Parse image binary in PE32(+) format, assuming that sanity of PE image
+ * has been checked by a caller.
+ * On success, an address of authentication data in @efi and its size will
+ * be returned in @auth and @auth_len, respectively.
+ *
+ * Return: true on success, false on error
+ */
+bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
+WIN_CERTIFICATE **auth, size_t *auth_len)
This function is way too long (> 100 lines). Please, cut it into logical
units.
+{
+ struct efi_image_regions *regs;
+ IMAGE_DOS_HEADER *dos;
+ IMAGE_NT_HEADERS32 *nt;
+ IMAGE_SECTION_HEADER *sections, **sorted;
+ int num_regions, num_sections, i, j;
+ int ctidx = IMAGE_DIRECTORY_ENTRY_SECURITY;
+ u32 align, size, authsz, authoff;
+ size_t bytes_hashed;
+
+ dos = (void *)efi;
+ nt = (void *)(efi + dos->e_lfanew);
+
+ /*
+* Count maximum number of regions to be digested.
+* We don't have to have an exact number here.
+
Re: [PATCH v4 03/16] efi_loader: add signature verification functions
On 1/17/20 3:20 AM, AKASHI Takahiro wrote:
On Wed, Jan 15, 2020 at 01:13:36AM +0100, Heinrich Schuchardt wrote:
On 1/15/20 12:43 AM, Heinrich Schuchardt wrote:
On 12/18/19 1:44 AM, AKASHI Takahiro wrote:
(snip)
diff --git a/lib/efi_loader/efi_signature.c
b/lib/efi_loader/efi_signature.c
new file mode 100644
index ..823d3311e010
--- /dev/null
+++ b/lib/efi_loader/efi_signature.c
@@ -0,0 +1,584 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Patrick Wildt
+ * Copyright (c) 2019 Linaro Limited, Author: AKASHI Takahiro
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+/*
+ * avoid duplicated inclusion:
+ * #include "../lib/crypto/x509_parser.h"
+ */
+#include "../lib/crypto/pkcs7_parser.h"
+
+const efi_guid_t efi_guid_image_security_database =
+ EFI_IMAGE_SECURITY_DATABASE_GUID;
+const efi_guid_t efi_guid_sha256 = EFI_CERT_SHA256_GUID;
+const efi_guid_t efi_guid_cert_rsa2048 = EFI_CERT_RSA2048_GUID;
+const efi_guid_t efi_guid_cert_x509 = EFI_CERT_X509_GUID;
+const efi_guid_t efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID;
+
+#ifdef CONFIG_EFI_SECURE_BOOT
This is the #ifdef to move to the Makefile. In the previous mail I got
into the wrong line.
No.
As you can see, those guids may also be referred to by other files
(see efi_variable.c and cmd/nvedit_efi.c)
even in !EFI_SECURE_BOOT case, and I think that this file is best fit
for them.
I cannot find any of these guids in any other C file after applying all
patches from
https://patchwork.ozlabs.org/project/uboot/list/?series==61166
git grep -n efi_guid_sha256
include/efi_loader.h:185:extern const efi_guid_t efi_guid_sha256;
lib/efi_loader/efi_signature.c:26:const efi_guid_t efi_guid_sha256 =
EFI_CERT_SHA256_GUID;
lib/efi_loader/efi_signature.c:252: if
(guidcmp(>sig_type, _guid_sha256)) {
lib/efi_loader/efi_signature.c:27:const efi_guid_t efi_guid_cert_rsa2048
= EFI_CERT_RSA2048_GUID;
git grep -n efi_guid_cert_x509
include/efi_loader.h:186:extern const efi_guid_t efi_guid_cert_x509;
include/efi_loader.h:187:extern const efi_guid_t efi_guid_cert_x509_sha256;
lib/efi_loader/efi_signature.c:28:const efi_guid_t efi_guid_cert_x509 =
EFI_CERT_X509_GUID;
lib/efi_loader/efi_signature.c:29:const efi_guid_t
efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID;
lib/efi_loader/efi_signature.c:283: if (guidcmp(>sig_type,
_guid_cert_x509)) {
lib/efi_loader/efi_signature.c:406: if (guidcmp(>sig_type,
_guid_cert_x509_sha256)) {
include/efi_loader.h:187:extern const efi_guid_t efi_guid_cert_x509_sha256;
lib/efi_loader/efi_signature.c:29:const efi_guid_t
efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID;
lib/efi_loader/efi_signature.c:406: if (guidcmp(>sig_type,
_guid_cert_x509_sha256)) {
Best regards
Heinrich
Re: [PATCH v4 05/16] efi_loader: variable: support variable authentication
On Wed, Jan 08, 2020 at 11:54:26PM +0100, Heinrich Schuchardt wrote:
> On 12/18/19 1:45 AM, AKASHI Takahiro wrote:
> >With this commit, EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS
> >is supported for authenticated variables and the system secure state
> >will transfer between setup mode and user mode as UEFI specification
> >section 32.3 describes.
> >
> >Internally, authentication data is stored as part of authenticated
> >variable's value. It is nothing but a pkcs7 message (but we need some
> >wrapper, see efi_variable_parse_signature()) and will be validated by
> >efi_variable_authenticate(), hence efi_signature_verify_with_db().
> >
> >Associated time value will be encoded in "{...,time=...}" along with
> >other UEFI variable's attributes.
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > include/efi_loader.h | 3 +
> > lib/efi_loader/efi_variable.c | 665 --
> > 2 files changed, 564 insertions(+), 104 deletions(-)
> >
> >diff --git a/include/efi_loader.h b/include/efi_loader.h
> >index 3b3618e0be24..1f88caf86709 100644
> >--- a/include/efi_loader.h
> >+++ b/include/efi_loader.h
> >@@ -175,6 +175,7 @@ extern const efi_guid_t efi_guid_image_security_database;
> > extern const efi_guid_t efi_guid_sha256;
> > extern const efi_guid_t efi_guid_cert_x509;
> > extern const efi_guid_t efi_guid_cert_x509_sha256;
> >+extern const efi_guid_t efi_guid_cert_type_pkcs7;
> >
> > extern unsigned int __efi_runtime_start, __efi_runtime_stop;
> > extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
> >@@ -723,6 +724,8 @@ efi_status_t efi_image_region_add(struct
> >efi_image_regions *regs,
> >
> > void efi_sigstore_free(struct efi_signature_store *sigstore);
> > struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name);
> >+
> >+bool efi_secure_boot_enabled(void);
> > #endif /* CONFIG_EFI_SECURE_BOOT */
> >
> > #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >diff --git a/lib/efi_loader/efi_variable.c b/lib/efi_loader/efi_variable.c
> >index 46f35bc60ba0..171b4abb4c58 100644
> >--- a/lib/efi_loader/efi_variable.c
> >+++ b/lib/efi_loader/efi_variable.c
> >@@ -10,7 +10,13 @@
> > #include
> > #include
> > #include
> >+#include
> > #include
> >+#include
> >+#include "../lib/crypto/pkcs7_parser.h"
> >+
> >+const efi_guid_t efi_guid_cert_type_pkcs7 = EFI_CERT_TYPE_PKCS7_GUID;
> >+static bool efi_secure_boot;
> >
> > #define READ_ONLY BIT(31)
> >
> >@@ -107,7 +113,7 @@ static const char *prefix(const char *str, const char
> >*prefix)
> > * @attrp: pointer to UEFI attributes
> > * Return: pointer to remainder of U-Boot variable value
> > */
> >-static const char *parse_attr(const char *str, u32 *attrp)
> >+static const char *parse_attr(const char *str, u32 *attrp, u64 *timep)
> > {
> > u32 attr = 0;
> > char sep = '{';
> >@@ -130,6 +136,12 @@ static const char *parse_attr(const char *str, u32
> >*attrp)
> > attr |= EFI_VARIABLE_BOOTSERVICE_ACCESS;
> > } else if ((s = prefix(str, "run"))) {
> > attr |= EFI_VARIABLE_RUNTIME_ACCESS;
> >+} else if ((s = prefix(str, "time="))) {
> >+attr |=
> >EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS;
> >+hex2bin((u8 *)timep, s, sizeof(*timep));
> >+s += sizeof(*timep) * 2;
> >+} else if (*str == '}') {
> >+break;
> > } else {
> > printf("invalid attribute: %s\n", str);
> > break;
> >@@ -147,48 +159,291 @@ static const char *parse_attr(const char *str, u32
> >*attrp)
> > }
> >
> > /**
> >- * efi_get_variable() - retrieve value of a UEFI variable
> >+ * efi_secure_boot_enabled - return if secure boot is enabled or not
> > *
> >- * This function implements the GetVariable runtime service.
> >+ * Return: true if enabled, false if disabled
> >+ */
> >+bool efi_secure_boot_enabled(void)
> >+{
> >+return efi_secure_boot;
> >+}
> >+
> >+#ifdef CONFIG_EFI_SECURE_BOOT
> >+static u8 pkcs7_hdr[] = {
> >+/* SEQUENCE */
> >+0x30, 0x82, 0x05, 0xc7,
> >+/* OID: pkcs7-signedData */
> >+0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x07, 0x02,
> >+/* Context Structured? */
> >+0xa0, 0x82, 0x05, 0xb8,
> >+};
> >+
> >+/**
> >+ * efi_variable_parse_signature - parse a signature in variable
> >+ * @buf:Pointer to variable's value
> >+ * @buflen: Length of @buf
> > *
> >- * See the Unified Extensible Firmware Interface (UEFI) specification for
> >- * details.
> >+ * Parse a signature embedded in variable's value and instantiate
> >+ * a pkcs7_message structure. Since pkcs7_parse_message() accepts only
> >+ * pkcs7's signedData, some header needed be prepended for correctly
> >+ * parsing authentication data, particularly for variable's.
> > *
> >- * @variable_name: name of the variable
> >- * @vendor: vendor GUID
> >- * @attributes:
Re: [PATCH v4 6/6] test: add rsa_verify() unit test
On 1/17/20 2:53 AM, AKASHI Takahiro wrote:
On Tue, Jan 14, 2020 at 01:04:58PM +0100, Heinrich Schuchardt wrote:
On 1/14/20 8:33 AM, AKASHI Takahiro wrote:
On Wed, Jan 08, 2020 at 06:43:51PM +0100, Heinrich Schuchardt wrote:
On 11/21/19 1:11 AM, AKASHI Takahiro wrote:
In this patch, a very simple test is added to verify that rsa_verify()
using rsa_verify_with_pkey() work correctly.
To keep the code simple, all the test data, either public key and
verified binary data, are embedded in the source.
Signed-off-by: AKASHI Takahiro
---
test/Kconfig | 12 +++
test/lib/Makefile | 1 +
test/lib/rsa.c| 206 ++
3 files changed, 219 insertions(+)
create mode 100644 test/lib/rsa.c
diff --git a/test/Kconfig b/test/Kconfig
index cb7954041eda..64d76c3b20a5 100644
--- a/test/Kconfig
+++ b/test/Kconfig
@@ -28,6 +28,18 @@ config UT_LIB_ASN1
Enables a test which exercises asn1 compiler and decoder function
via various parsers.
+config UT_LIB_RSA
+ bool "Unit test for rsa_verify() function"
+ imply RSA
+ imply ASYMMETRIC_KEY_TYPE
+ imply ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+ imply RSA_PUBLIC_KEY_PARSER
+ imply RSA_VERIFY_WITH_PKEY
This test should depend on RSA_VERIFY_WITH_PKEY because is cannot be
executed otherwise.
See below.
Best regards
Heinrich
+ default y
+ help
+ Enables rsa_verify() test, currently rsa_verify_with_pkey only()
+ only, at the 'ut lib' command.
+
endif
config UT_TIME
diff --git a/test/lib/Makefile b/test/lib/Makefile
index 72d2ec74b5f4..2bf6ef3935bb 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -8,3 +8,4 @@ obj-y += lmb.o
obj-y += string.o
obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
obj-$(CONFIG_UT_LIB_ASN1) += asn1.o
+obj-$(CONFIG_UT_LIB_RSA) += rsa.o
diff --git a/test/lib/rsa.c b/test/lib/rsa.c
new file mode 100644
index ..44f8ade226f4
--- /dev/null
+++ b/test/lib/rsa.c
@@ -0,0 +1,206 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2019 Linaro Limited
+ * Author: AKASHI Takahiro
+ *
+ * Unit test for rsa_verify() function
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
Please, remove this ifdef. Simply do not build this module if
CONFIG_RSA_VERIFY_WITH_PKEY is not defined.
That is why I added this #ifdef here to avoid a build error.
I think it is a good idea to make test code as generic as possible
to easily add more test cases.
It is preferable to move configuration dependencies to the Makefile.
You can create a new C file if you have tests needing a different
configuration.
test/lib/rsa_verify.c might be a better name for the file.
In test/Kconfig, please, replace
config UT_LIB_RSA
bool "Unit test for rsa_verify() function"
imply RSA
by
config UT_LIB_RSA
bool "Unit test for rsa_verify() function"
default y
depends on RSA
Initially in my development code, I did the exact same thing,
but I didn't adopt this approach.
If we follow your proposal, UT_LIB_RSA won't be selected
unless RSA is enabled.
So UT_LIB_RSA won't be executed under most existing configurations
in the current CI. This was not what I wanted.
What I wanted here is that, if UT (and UT_LIB) is selected, all
the configurations needed for enabling all the test cases be
also selected *automatically*.
What I want is that if I run 'make menuconfig' and select CONFIG_UT
manually I end up with a configuration that compiles and that does what
I have configured.
Just try:
make wandboard_config
make menuconfig
# set CONFIG_UT=y
# set CONFIG_UT_LIB_RSA=y
This results in
CONFIG_RSA=n
because 'imply RSA' does not switch on CONFIG_RSA in this case.
You end up with a configuration where the test is selected in .config
but cannot be executed.
Please, change your patches such that it is guaranteed that if a test is
activated in the configuration it is executed by the 'ut all' command.
Best regards
Heinrich
I think that this is what Tom implied in his comment.
Thanks,
-Takahiro Akashi
We run all unit tests in Gitlab CI. This requires default=y.
'imply' gives you no guarantee that RSA is selected. See the build
errors I reported for your other patches in the series.
Best regards
Heinrich
I believe that the original RSA helper functions (w/o WITH_PKEY)
should also be exercised in a unit test. Otherwise, the code
will only be exercised indirectly through FIT image verification
and such a situation will contradict what Tom (or Heinrich?) demanded
against my RSA patch.
-Takahiro Akashi
+/*
+ * openssl genrsa 2048 -out private.pem
+ * openssl rsa -in private.pem -pubout -outform der -out public.der
+ * dd if=public.der of=public.raw bs=24 skip=1
+ */
+static unsigned char public_key[] = {
+ 0x30, 0x82, 0x01, 0x0a, 0x02, 0x82, 0x01, 0x01, 0x00, 0xca, 0x25, 0x23,
+ 0xe0, 0x0a, 0x4d,
Re: [PATCH v2 8/9] configs: j721e_evm_r5: Add configs for environment in eMMC
On 13/01/20 11:24 AM, Keerthy wrote: > From: Faiz Abbas > > Add config to save and read back environment from eMMC. > > Signed-off-by: Faiz Abbas > Signed-off-by: Keerthy This is conflicting with https://patchwork.ozlabs.org/patch/1224239/. and this is breaking boot on J7. Can you rebase on top of https://gitlab.denx.de/u-boot/custodians/u-boot-ti/commits/next and repost the series? Thanks and regards, Lokesh
Re: [PATCH v4 08/16] efi_loader: image_loader: support image authentication
On Thu, Jan 09, 2020 at 12:55:17AM +0100, Heinrich Schuchardt wrote:
> On 12/18/19 1:45 AM, AKASHI Takahiro wrote:
> >With this commit, image validation can be enforced, as UEFI specification
> >section 32.5 describes, if CONFIG_EFI_SECURE_BOOT is enabled.
> >
> >Currently we support
> >* authentication based on db and dbx,
> > so dbx-validated image will always be rejected.
> >* following signature types:
> > EFI_CERT_SHA256_GUID (SHA256 digest for unsigned images)
> > EFI_CERT_X509_GUID (x509 certificate for signed images)
> >Timestamp-based certificate revocation is not supported here.
> >
> >Internally, authentication data is stored in one of certificates tables
> >of PE image (See efi_image_parse()) and will be verified by
> >efi_image_authenticate() before loading a given image.
> >
> >It seems that UEFI specification defines the verification process
> >in a bit ambiguous way. I tried to implement it as closely to as
> >EDK2 does.
> >
> >Signed-off-by: AKASHI Takahiro
> >---
> > include/efi_loader.h | 7 +-
> > lib/efi_loader/efi_boottime.c | 2 +-
> > lib/efi_loader/efi_image_loader.c | 454 +-
> > 3 files changed, 449 insertions(+), 14 deletions(-)
> >
> >diff --git a/include/efi_loader.h b/include/efi_loader.h
> >index 1f88caf86709..e12b49098fb0 100644
> >--- a/include/efi_loader.h
> >+++ b/include/efi_loader.h
> >@@ -11,6 +11,7 @@
> > #include
> > #include
> > #include
> >+#include
> >
> > static inline int guidcmp(const void *g1, const void *g2)
> > {
> >@@ -398,7 +399,8 @@ efi_status_t efi_set_watchdog(unsigned long timeout);
> > /* Called from places to check whether a timer expired */
> > void efi_timer_check(void);
> > /* PE loader implementation */
> >-efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle, void *efi,
> >+efi_status_t efi_load_pe(struct efi_loaded_image_obj *handle,
> >+ void *efi, size_t efi_size,
> > struct efi_loaded_image *loaded_image_info);
> > /* Called once to store the pristine gd pointer */
> > void efi_save_gd(void);
> >@@ -726,6 +728,9 @@ void efi_sigstore_free(struct efi_signature_store
> >*sigstore);
> > struct efi_signature_store *efi_sigstore_parse_sigdb(u16 *name);
> >
> > bool efi_secure_boot_enabled(void);
> >+
> >+bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
> >+ WIN_CERTIFICATE **auth, size_t *auth_len);
> > #endif /* CONFIG_EFI_SECURE_BOOT */
> >
> > #else /* CONFIG_IS_ENABLED(EFI_LOADER) */
> >diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> >index 493d906c641d..311681764034 100644
> >--- a/lib/efi_loader/efi_boottime.c
> >+++ b/lib/efi_loader/efi_boottime.c
> >@@ -1879,7 +1879,7 @@ efi_status_t EFIAPI efi_load_image(bool boot_policy,
> > efi_dp_split_file_path(file_path, , );
> > ret = efi_setup_loaded_image(dp, fp, image_obj, );
> > if (ret == EFI_SUCCESS)
> >-ret = efi_load_pe(*image_obj, dest_buffer, info);
> >+ret = efi_load_pe(*image_obj, dest_buffer, source_size, info);
> > if (!source_buffer)
> > /* Release buffer to which file was loaded */
> > efi_free_pages((uintptr_t)dest_buffer,
> >diff --git a/lib/efi_loader/efi_image_loader.c
> >b/lib/efi_loader/efi_image_loader.c
> >index 13541cfa7a28..939758e61e3c 100644
> >--- a/lib/efi_loader/efi_image_loader.c
> >+++ b/lib/efi_loader/efi_image_loader.c
> >@@ -9,7 +9,9 @@
> >
> > #include
> > #include
> >+#include
> > #include
> >+#include "../lib/crypto/pkcs7_parser.h"
> >
> > const efi_guid_t efi_global_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
> > const efi_guid_t efi_guid_device_path = EFI_DEVICE_PATH_PROTOCOL_GUID;
> >@@ -205,6 +207,367 @@ static void efi_set_code_and_data_type(
> > }
> > }
> >
> >+#ifdef CONFIG_EFI_SECURE_BOOT
> >+/**
> >+ * efi_image_parse - parse a PE image
> >+ * @efi:Pointer to image
> >+ * @len:Size of @efi
> >+ * @regs: Pointer to a list of regions
> >+ * @auth: Pointer to a pointer to authentication data in PE
> >+ * @auth_len: Size of @auth
> >+ *
> >+ * Parse image binary in PE32(+) format, assuming that sanity of PE image
> >+ * has been checked by a caller.
> >+ * On success, an address of authentication data in @efi and its size will
> >+ * be returned in @auth and @auth_len, respectively.
> >+ *
> >+ * Return: true on success, false on error
> >+ */
> >+bool efi_image_parse(void *efi, size_t len, struct efi_image_regions **regp,
> >+ WIN_CERTIFICATE **auth, size_t *auth_len)
>
>
> This function is way too long (> 100 lines). Please, cut it into logical
> units.
>
>
>
> >+{
> >+struct efi_image_regions *regs;
> >+IMAGE_DOS_HEADER *dos;
> >+IMAGE_NT_HEADERS32 *nt;
> >+IMAGE_SECTION_HEADER *sections, **sorted;
> >+int num_regions, num_sections, i, j;
> >+int ctidx = IMAGE_DIRECTORY_ENTRY_SECURITY;
> >+u32 align, size,
Re: [PATCH 0/3] Fix Odroid U3/X2 SD-card boot
Hi Marek, On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski wrote: > > Hi All > > This patchset restores booting from SD-card on Exynos4412-based Odroid > U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and > PMIC device name fixes: > https://patchwork.ozlabs.org/patch/1223558/ > https://patchwork.ozlabs.org/patch/1224228/ > > Best regards > Marek Szyprowski > Samsung R Institute Poland > Thanks for this fix, I have am issue with my odroid u3 boards, All my board will not boot up until I connect UART to usb port. basically the fan spin but will not load the kernel. So it their a solution to this problem. I tried the patch from Tobias Jakobi (odroid: defconfig: configure keyed autoboot) but this did not work at my end. -Anand
Re: [PATCH 3/3] arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
Hi Marek, On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski wrote: > > Use MMC0 for eMMC and MMC2 for SD-card as other Exynos-based boards do. > This allows to use common code to get MMC device id based on the XOM[7:5] > pins. > > Signed-off-by: Marek Szyprowski > --- Please add my Reviewed-by: Anand Moon -Anand
Re: [PATCH 2/3] arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
Hi Marek, On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski wrote: > > Card detect line for SD-card on Odroid U3/X2 boards are active low, so > add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't > support specifying line polarity. This restores S5P_SDHCI driver operation > on Odroid U3/X2 boards. > > Signed-off-by: Marek Szyprowski > --- Please add my Reviewed-by: Anand Moon -Anand
Re: [PATCH 1/3] mmc: s5p_sdhci: Read generic MMC properties from DT
Hi Marek, On Thu, 16 Jan 2020 at 20:56, Marek Szyprowski wrote: > > Read generic MMC properties from device-tree. This allows to specify for > example cd-inverted property and let MMC core to properly handle such > case. > > Signed-off-by: Marek Szyprowski > --- Please add my Reviewed-by: Anand Moon -Anand
Re: [PATCH v2 1/9] lib: elf: Move the generic elf loading/validating functions to lib
Simon,
On 13/01/20 11:24 AM, Keerthy wrote:
> Move the generic elf loading/validating functions to lib/
> so that they can be re-used and accessed by code existing
> outside cmd.
>
> Signed-off-by: Keerthy
> Suggested-by: Simon Goldschmidt
Are you okay with this patch? If yes, Ill apply to u-boot-ti along with other
patches in this series.
Thanks and regards,
Lokesh
> ---
> Changes in v2:
>
> * Factored out all the generic elf handling functions under lib/elf.c
>
> cmd/Kconfig | 1 +
> cmd/elf.c | 229
> include/elf.h | 4 +
> lib/Kconfig | 3 +
> lib/Makefile | 1 +
> lib/elf.c | 256 ++
> 6 files changed, 265 insertions(+), 229 deletions(-)
> create mode 100644 lib/elf.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 298feae24d..6f4f08d02a 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -375,6 +375,7 @@ config CMD_ADTIMG
> config CMD_ELF
> bool "bootelf, bootvx"
> default y
> + select ELF
> help
> Boot an ELF/vxWorks image from the memory.
>
> diff --git a/cmd/elf.c b/cmd/elf.c
> index 32f12a72b9..23cc17aebc 100644
> --- a/cmd/elf.c
> +++ b/cmd/elf.c
> @@ -26,211 +26,6 @@
> #include
> #endif
>
> -/*
> - * A very simple ELF64 loader, assumes the image is valid, returns the
> - * entry point address.
> - *
> - * Note if U-Boot is 32-bit, the loader assumes the to segment's
> - * physical address and size is within the lower 32-bit address space.
> - */
> -static unsigned long load_elf64_image_phdr(unsigned long addr)
> -{
> - Elf64_Ehdr *ehdr; /* Elf header structure pointer */
> - Elf64_Phdr *phdr; /* Program header structure pointer */
> - int i;
> -
> - ehdr = (Elf64_Ehdr *)addr;
> - phdr = (Elf64_Phdr *)(addr + (ulong)ehdr->e_phoff);
> -
> - /* Load each program header */
> - for (i = 0; i < ehdr->e_phnum; ++i) {
> - void *dst = (void *)(ulong)phdr->p_paddr;
> - void *src = (void *)addr + phdr->p_offset;
> -
> - debug("Loading phdr %i to 0x%p (%lu bytes)\n",
> - i, dst, (ulong)phdr->p_filesz);
> - if (phdr->p_filesz)
> - memcpy(dst, src, phdr->p_filesz);
> - if (phdr->p_filesz != phdr->p_memsz)
> - memset(dst + phdr->p_filesz, 0x00,
> -phdr->p_memsz - phdr->p_filesz);
> - flush_cache(rounddown((unsigned long)dst, ARCH_DMA_MINALIGN),
> - roundup(phdr->p_memsz, ARCH_DMA_MINALIGN));
> - ++phdr;
> - }
> -
> - if (ehdr->e_machine == EM_PPC64 && (ehdr->e_flags &
> - EF_PPC64_ELFV1_ABI)) {
> - /*
> - * For the 64-bit PowerPC ELF V1 ABI, e_entry is a function
> - * descriptor pointer with the first double word being the
> - * address of the entry point of the function.
> - */
> - uintptr_t addr = ehdr->e_entry;
> -
> - return *(Elf64_Addr *)addr;
> - }
> -
> - return ehdr->e_entry;
> -}
> -
> -static unsigned long load_elf64_image_shdr(unsigned long addr)
> -{
> - Elf64_Ehdr *ehdr; /* Elf header structure pointer */
> - Elf64_Shdr *shdr; /* Section header structure pointer */
> - unsigned char *strtab = 0; /* String table pointer */
> - unsigned char *image; /* Binary image pointer */
> - int i; /* Loop counter */
> -
> - ehdr = (Elf64_Ehdr *)addr;
> -
> - /* Find the section header string table for output info */
> - shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
> - (ehdr->e_shstrndx * sizeof(Elf64_Shdr)));
> -
> - if (shdr->sh_type == SHT_STRTAB)
> - strtab = (unsigned char *)(addr + (ulong)shdr->sh_offset);
> -
> - /* Load each appropriate section */
> - for (i = 0; i < ehdr->e_shnum; ++i) {
> - shdr = (Elf64_Shdr *)(addr + (ulong)ehdr->e_shoff +
> - (i * sizeof(Elf64_Shdr)));
> -
> - if (!(shdr->sh_flags & SHF_ALLOC) ||
> - shdr->sh_addr == 0 || shdr->sh_size == 0) {
> - continue;
> - }
> -
> - if (strtab) {
> - debug("%sing %s @ 0x%08lx (%ld bytes)\n",
> - (shdr->sh_type == SHT_NOBITS) ? "Clear" : "Load",
> -[shdr->sh_name],
> -(unsigned long)shdr->sh_addr,
> -(long)shdr->sh_size);
> - }
> -
> - if (shdr->sh_type == SHT_NOBITS) {
> - memset((void *)(uintptr_t)shdr->sh_addr, 0,
> -shdr->sh_size);
> - } else {
> - image = (unsigned char *)addr + (ulong)shdr->sh_offset;
> - memcpy((void *)(uintptr_t)shdr->sh_addr,
> -
Re: [U-Boot] [PATCH] defconfigs: Add a config for AM43xx High Security EVM with QSPI Boot support
On 08/01/20 4:24 AM, Andrew F. Davis wrote: > On AM43xx HS devices, QSPI boot is XIP and we use a single stage > bootloader. Add a defconfig for this. > > Signed-off-by: Andrew F. Davis This gives the following build warning. Can you fix it and re post? In file included from arch/arm/mach-omap2/am33xx/board.c:14: include/ns16550.h:31: warning: "CONFIG_SYS_NS16550_REG_SIZE" redefined #define CONFIG_SYS_NS16550_REG_SIZE (-1) In file included from include/config.h:8, from include/common.h:22, from arch/arm/mach-omap2/am33xx/board.c:10: include/configs/am43xx_evm.h:19: note: this is the location of the previous definition #define CONFIG_SYS_NS16550_REG_SIZE(-4) In file included from drivers/serial/ns16550.c:11: include/ns16550.h:31: warning: "CONFIG_SYS_NS16550_REG_SIZE" redefined #define CONFIG_SYS_NS16550_REG_SIZE (-1) In file included from include/config.h:8, from include/common.h:22, from drivers/serial/ns16550.c:7: include/configs/am43xx_evm.h:19: note: this is the location of the previous definition #define CONFIG_SYS_NS16550_REG_SIZE(-4) In file included from drivers/serial/serial_omap.c:12: include/ns16550.h:31: warning: "CONFIG_SYS_NS16550_REG_SIZE" redefined #define CONFIG_SYS_NS16550_REG_SIZE (-1) In file included from include/config.h:8, from include/common.h:22, from drivers/serial/serial_omap.c:9: include/configs/am43xx_evm.h:19: note: this is the location of the previous definition #define CONFIG_SYS_NS16550_REG_SIZE(-4) arch/arm/mach-omap2/config_secure.mk:97: recipe for target 'u-boot_HS_XIP_X-LOADER' failed make: *** [u-boot_HS_XIP_X-LOADER] Error 1 make: *** Deleting file 'u-boot_HS_XIP_X-LOADER' Thanks and regards, Lokesh
RE: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset driver for SPL
Hi Marek, > Subject: Re: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset > driver for SPL > > On 1/16/20 3:21 AM, Peng Fan wrote: > > Hello Peng, > > >> Subject: [RFC PATCH] imx: imx8mm-evk/imx8mn-evk: enable sysreset > >> driver for SPL > >> > > > > NAK, this will not work on i.MX8MM/N. > > > > Currently sysreset psci is enabled, however psci will not work for > > SPL, because SPL boots before BL31. > > Thank you for the constructive feedback. > > So basically , what we need is a real sysreset driver for iMX8MM , which can > work with bare-bones hardware interface, that is, poking some register, > correct ? Yes. > > So, either you or Claudius needs to implement a driver in drivers/sysreset, > which will bind in SPL and if needed, do some writel() into some registers to > reset the board, correct ? Yes. > > Because, I believe we can both agree that dumping such ad-hoc code which > implements reset in board code is not the right way, esp. nowadays with all > the DM/DT stuff in. Alought we still have ocram space, but our SPL is huge now, 100KB+ Regards, Peng.
Re: [PATCH v4 2/6] rsa: add CONFIG_RSA_VERIFY_WITH_PKEY config
On Tue, Jan 14, 2020 at 12:43:40PM +0100, Heinrich Schuchardt wrote: > On 1/14/20 8:45 AM, AKASHI Takahiro wrote: > >On Wed, Jan 08, 2020 at 01:35:13PM +0100, Heinrich Schuchardt wrote: > >>On 11/21/19 1:11 AM, AKASHI Takahiro wrote: > >>>In the next couple of commits, under new CONFIG_RSA_VERIFY_WITH_PKEY, > >>>rsa_verify() will be extended to be able to perform RSA decryption without > >>>additional RSA key properties from FIT image, i.e. rr and n0inv. > >>> > >>>Signed-off-by: AKASHI Takahiro > >>>Reviewed-by: Simon Glass > >> > >>The patch series does not build for some configurations. > >> > >>>--- > >>> lib/rsa/Kconfig | 14 ++ > >>> 1 file changed, 14 insertions(+) > >>> > >>>diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig > >>>index 03ffa2969048..71e4c06bf883 100644 > >>>--- a/lib/rsa/Kconfig > >>>+++ b/lib/rsa/Kconfig > >>>@@ -30,6 +30,20 @@ config RSA_VERIFY > >>> help > >>> Add RSA signature verification support. > >>> > >>>+config RSA_VERIFY_WITH_PKEY > >> > >>For CONFIG_RSA_VERIFY_WITH_PKEY=y and CONFIG_RSA_PUBLIC_KEY_PARSER=n > >>I get an error: > > > >This error is inevitable as both RSA_VERIFY_WITH_PKEY and > >RSA_PUBLIC_KEY_PARSER are "select"able configurations with > >visible prompts and then > > No, it is not inevitbable. Just ensure that in the Makefiles all modules > are selected that you need for your configuration. How? Can you please show me a simple solution? Thanks, -Takahiro Akashi > >we should generally avoid potential illegal configurations; > > Yes, we want to avoid potentially illegal configurations everywhere. > This is why we have a randconfig build target. > > Best regards > > Heinrich > > >The one should NOT forcibly select the other as the kernel kconfig > >document suggests. > > > ># Note: > >#select should be used with care. select will force > >#a symbol to a value without visiting the dependencies. > >#By abusing select you are able to select a symbol FOO even > >#if FOO depends on BAR that is not set. > >#In general use select only for non-visible symbols > >#(no prompts anywhere) and for symbols with no dependencies. > >#That will limit the usefulness but on the other hand avoid > >#the illegal configurations all over. > > > >-Takahiro Akashi > > > > > >>lib/rsa/rsa-keyprop.c:669: undefined reference to `rsa_parse_pub_key' > >> > >>RSA_PUBLIC_KEY_PARSER depends on > >>ASYMMETRIC_KEY_TYPE [=n] && ASYMMETRIC_PUBLIC_KEY_SUBTYPE [=n] > >> > >>Please, fix the dependencies. > >> > >>Best regards > >> > >>Heinrich > >> > >>>+ bool "Execute RSA verification without key parameters from FDT" > >>>+ depends on RSA > >>>+ help > >>>+The standard RSA-signature verification code (FIT_SIGNATURE) uses > >>>+pre-calculated key properties, that are stored in fdt blob, in > >>>+decrypting a signature. > >>>+This does not suit the use case where there is no way defined to > >>>+provide such additional key properties in standardized form, > >>>+particularly UEFI secure boot. > >>>+This options enables RSA signature verification with a public key > >>>+directly specified in image_sign_info, where all the necessary > >>>+key properties will be calculated on the fly in verification code. > >>>+ > >>> config RSA_SOFTWARE_EXP > >>> bool "Enable driver for RSA Modular Exponentiation in software" > >>> depends on DM > >>> > > >
Re: [PATCH v4 03/16] efi_loader: add signature verification functions
On Wed, Jan 15, 2020 at 01:13:36AM +0100, Heinrich Schuchardt wrote: > On 1/15/20 12:43 AM, Heinrich Schuchardt wrote: > >On 12/18/19 1:44 AM, AKASHI Takahiro wrote: (snip) > >>diff --git a/lib/efi_loader/efi_signature.c > >>b/lib/efi_loader/efi_signature.c > >>new file mode 100644 > >>index ..823d3311e010 > >>--- /dev/null > >>+++ b/lib/efi_loader/efi_signature.c > >>@@ -0,0 +1,584 @@ > >>+// SPDX-License-Identifier: GPL-2.0+ > >>+/* > >>+ * Copyright (c) 2018 Patrick Wildt > >>+ * Copyright (c) 2019 Linaro Limited, Author: AKASHI Takahiro > >>+ */ > >>+ > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+#include > >>+/* > >>+ * avoid duplicated inclusion: > >>+ * #include "../lib/crypto/x509_parser.h" > >>+ */ > >>+#include "../lib/crypto/pkcs7_parser.h" > >>+ > >>+const efi_guid_t efi_guid_image_security_database = > >>+ EFI_IMAGE_SECURITY_DATABASE_GUID; > >>+const efi_guid_t efi_guid_sha256 = EFI_CERT_SHA256_GUID; > >>+const efi_guid_t efi_guid_cert_rsa2048 = EFI_CERT_RSA2048_GUID; > >>+const efi_guid_t efi_guid_cert_x509 = EFI_CERT_X509_GUID; > >>+const efi_guid_t efi_guid_cert_x509_sha256 = EFI_CERT_X509_SHA256_GUID; > >>+ > >>+#ifdef CONFIG_EFI_SECURE_BOOT > > This is the #ifdef to move to the Makefile. In the previous mail I got > into the wrong line. No. As you can see, those guids may also be referred to by other files (see efi_variable.c and cmd/nvedit_efi.c) even in !EFI_SECURE_BOOT case, and I think that this file is best fit for them. -Takahiro Akashi > Best regards > > Heinrich
Re: [PATCH v4 6/6] test: add rsa_verify() unit test
On Tue, Jan 14, 2020 at 01:04:58PM +0100, Heinrich Schuchardt wrote:
> On 1/14/20 8:33 AM, AKASHI Takahiro wrote:
> >On Wed, Jan 08, 2020 at 06:43:51PM +0100, Heinrich Schuchardt wrote:
> >>
> >>
> >>On 11/21/19 1:11 AM, AKASHI Takahiro wrote:
> >>>In this patch, a very simple test is added to verify that rsa_verify()
> >>>using rsa_verify_with_pkey() work correctly.
> >>>
> >>>To keep the code simple, all the test data, either public key and
> >>>verified binary data, are embedded in the source.
> >>>
> >>>Signed-off-by: AKASHI Takahiro
> >>>---
> >>> test/Kconfig | 12 +++
> >>> test/lib/Makefile | 1 +
> >>> test/lib/rsa.c| 206 ++
> >>> 3 files changed, 219 insertions(+)
> >>> create mode 100644 test/lib/rsa.c
> >>>
> >>>diff --git a/test/Kconfig b/test/Kconfig
> >>>index cb7954041eda..64d76c3b20a5 100644
> >>>--- a/test/Kconfig
> >>>+++ b/test/Kconfig
> >>>@@ -28,6 +28,18 @@ config UT_LIB_ASN1
> >>> Enables a test which exercises asn1 compiler and decoder function
> >>> via various parsers.
> >>>
> >>>+config UT_LIB_RSA
> >>>+ bool "Unit test for rsa_verify() function"
> >>>+ imply RSA
> >>>+ imply ASYMMETRIC_KEY_TYPE
> >>>+ imply ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> >>>+ imply RSA_PUBLIC_KEY_PARSER
> >>>+ imply RSA_VERIFY_WITH_PKEY
> >>
> >>This test should depend on RSA_VERIFY_WITH_PKEY because is cannot be
> >>executed otherwise.
> >
> >See below.
> >
> >>Best regards
> >>
> >>Heinrich
> >>
> >>>+ default y
> >>>+ help
> >>>+Enables rsa_verify() test, currently rsa_verify_with_pkey only()
> >>>+only, at the 'ut lib' command.
> >>>+
> >>> endif
> >>>
> >>> config UT_TIME
> >>>diff --git a/test/lib/Makefile b/test/lib/Makefile
> >>>index 72d2ec74b5f4..2bf6ef3935bb 100644
> >>>--- a/test/lib/Makefile
> >>>+++ b/test/lib/Makefile
> >>>@@ -8,3 +8,4 @@ obj-y += lmb.o
> >>> obj-y += string.o
> >>> obj-$(CONFIG_ERRNO_STR) += test_errno_str.o
> >>> obj-$(CONFIG_UT_LIB_ASN1) += asn1.o
> >>>+obj-$(CONFIG_UT_LIB_RSA) += rsa.o
> >>>diff --git a/test/lib/rsa.c b/test/lib/rsa.c
> >>>new file mode 100644
> >>>index ..44f8ade226f4
> >>>--- /dev/null
> >>>+++ b/test/lib/rsa.c
> >>>@@ -0,0 +1,206 @@
> >>>+// SPDX-License-Identifier: GPL-2.0+
> >>>+/*
> >>>+ * Copyright (c) 2019 Linaro Limited
> >>>+ * Author: AKASHI Takahiro
> >>>+ *
> >>>+ * Unit test for rsa_verify() function
> >>>+ */
> >>>+
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+#include
> >>>+
> >>>+#ifdef CONFIG_RSA_VERIFY_WITH_PKEY
> >>
> >>Please, remove this ifdef. Simply do not build this module if
> >>CONFIG_RSA_VERIFY_WITH_PKEY is not defined.
> >
> >That is why I added this #ifdef here to avoid a build error.
> >I think it is a good idea to make test code as generic as possible
> >to easily add more test cases.
>
> It is preferable to move configuration dependencies to the Makefile.
>
> You can create a new C file if you have tests needing a different
> configuration.
>
> test/lib/rsa_verify.c might be a better name for the file.
>
> In test/Kconfig, please, replace
>
> config UT_LIB_RSA
> bool "Unit test for rsa_verify() function"
> imply RSA
>
> by
>
> config UT_LIB_RSA
> bool "Unit test for rsa_verify() function"
> default y
> depends on RSA
Initially in my development code, I did the exact same thing,
but I didn't adopt this approach.
If we follow your proposal, UT_LIB_RSA won't be selected
unless RSA is enabled.
So UT_LIB_RSA won't be executed under most existing configurations
in the current CI. This was not what I wanted.
What I wanted here is that, if UT (and UT_LIB) is selected, all
the configurations needed for enabling all the test cases be
also selected *automatically*.
I think that this is what Tom implied in his comment.
Thanks,
-Takahiro Akashi
> We run all unit tests in Gitlab CI. This requires default=y.
>
> 'imply' gives you no guarantee that RSA is selected. See the build
> errors I reported for your other patches in the series.
>
> Best regards
>
> Heinrich
>
> >
> >I believe that the original RSA helper functions (w/o WITH_PKEY)
> >should also be exercised in a unit test. Otherwise, the code
> >will only be exercised indirectly through FIT image verification
> >and such a situation will contradict what Tom (or Heinrich?) demanded
> >against my RSA patch.
> >
> >-Takahiro Akashi
> >
> >>>+/*
> >>>+ * openssl genrsa 2048 -out private.pem
> >>>+ * openssl rsa -in private.pem -pubout -outform der -out public.der
> >>>+ * dd if=public.der of=public.raw bs=24 skip=1
> >>>+ */
> >>>+static unsigned char public_key[] = {
> >>>+ 0x30, 0x82, 0x01, 0x0a, 0x02, 0x82, 0x01, 0x01, 0x00, 0xca, 0x25, 0x23,
> >>>+ 0xe0, 0x0a, 0x4d, 0x8f, 0x56, 0xfc, 0xc9, 0x06, 0x4c, 0xcc, 0x94, 0x43,
> >>>+ 0xe0, 0x56, 0x44, 0x6e, 0x37, 0x54, 0x87, 0x12, 0x84, 0xf9, 0x07, 0x4f,
> >>>+ 0xe4, 0x23, 0x40, 0xc3, 0x43, 0x84, 0x37, 0x86, 0xd3, 0x9d, 0x95,
[PATCH v2 3/3] rpi4: Enable GENET Ethernet controller
From: Amit Singh Tomar The Raspberry Pi 4 SoC features an integrated Gigabit Ethernet controller, connected as a platform device. Enable the new driver in the three applicable defconfigs, to allow TFTP booting on the board. Signed-off-by: Amit Singh Tomar [Andre: Add joined and 32-bit configs] Signed-off-by: Andre Przywara --- configs/rpi_4_32b_defconfig | 2 ++ configs/rpi_4_defconfig | 2 ++ configs/rpi_arm64_defconfig | 1 + 3 files changed, 5 insertions(+) diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig index 00f80f71ad..e7ea88bd4b 100644 --- a/configs/rpi_4_32b_defconfig +++ b/configs/rpi_4_32b_defconfig @@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_DM_ETH=y +CONFIG_BCMGENET=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig index 8cf1bb81ff..b0f9cf1c0e 100644 --- a/configs/rpi_4_defconfig +++ b/configs/rpi_4_defconfig @@ -24,6 +24,8 @@ CONFIG_DM_KEYBOARD=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_BCM2835=y +CONFIG_DM_ETH=y +CONFIG_BCMGENET=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set # CONFIG_REQUIRE_SERIAL_CONSOLE is not set diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig index 10fbe0db92..00b3096481 100644 --- a/configs/rpi_arm64_defconfig +++ b/configs/rpi_arm64_defconfig @@ -36,6 +36,7 @@ CONFIG_USB_KEYBOARD=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_LAN78XX=y CONFIG_USB_ETHER_SMSC95XX=y +CONFIG_BCMGENET=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_BPP32=y CONFIG_SYS_WHITE_ON_BLACK=y -- 2.14.5
[PATCH v2 0/3] Ethernet support for Raspberry Pi 4
This series adds Ethernet support for the Raspberry Pi 4. The SoC includes a "Broadcom Genet v5 MAC" IP, connected as a proper platform device (no USB anymore!). Patch 1 provides a driver for that. There does not seem to be publicly available documentation, so this is based on the Linux driver, but stripped down to just provide what U-Boot needs. Patch 2 fixes up the RPi4 memory map to accommodate the MMIO area the MAC lives in, while patch 3 enables it in the respective defconfigs. This version addresses the comments by the diligent reviewers and testers, for a changelog see below. To see the individual changes as patches, refer to [1]. Please have a look and test it, I hope this helps to simplify development, as you spare the SD card and its slot from heavy swapping. I dropped the Tested-by's, as there were changes in the code. Happy to reapply them when people confirm that it still works for them. Cheers, Andre. [1] https://github.com/apritzel/u-boot/commits/rpi4-eth-v2 Changelog v1 ... v2: - use native endianess functions when accessing MMIO registers - use dev_* DM wrappers for accessing devicetree data - round base and length for flush_dcache_range, plus a comment - check and round length for invalidate_cache_range - support RGMII_RXID PHY mode, to support mainline .dtb Amit Singh Tomar (3): net: Add support for Broadcom GENETv5 Ethernet controller rpi4: Update memory map to accommodate scb devices rpi4: Enable GENET Ethernet controller arch/arm/mach-bcm283x/init.c | 6 +- configs/rpi_4_32b_defconfig | 2 + configs/rpi_4_defconfig | 2 + configs/rpi_arm64_defconfig | 1 + drivers/net/Kconfig | 7 + drivers/net/Makefile | 1 + drivers/net/bcmgenet.c | 722 +++ 7 files changed, 738 insertions(+), 3 deletions(-) create mode 100644 drivers/net/bcmgenet.c -- 2.14.5
[PATCH v2 2/3] rpi4: Update memory map to accommodate scb devices
From: Amit Singh Tomar
Some of the devices(for instance, pcie and gnet controller) sitting on
SCB bus falls behind/below the memory range that we currenty have.
This patch updates the memory range to map those devices correctly.
Signed-off-by: Amit Singh Tomar
Reviewed-by: Andre Przywara
Signed-off-by: Andre Przywara
---
arch/arm/mach-bcm283x/init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-bcm283x/init.c b/arch/arm/mach-bcm283x/init.c
index 3b5f45b431..9966d6c833 100644
--- a/arch/arm/mach-bcm283x/init.c
+++ b/arch/arm/mach-bcm283x/init.c
@@ -42,9 +42,9 @@ static struct mm_region bcm2711_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
- .virt = 0xfe00UL,
- .phys = 0xfe00UL,
- .size = 0x0180UL,
+ .virt = 0xfc00UL,
+ .phys = 0xfc00UL,
+ .size = 0x0380UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
2.14.5
[PATCH v2 1/3] net: Add support for Broadcom GENETv5 Ethernet controller
From: Amit Singh Tomar The Broadcom GENET Ethernet MACs are used in several MIPS based SoCs and in the Broadcom 2711/2838 SoC used on the Raspberry Pi 4. There is no publicly available documentation, so this driver is based on the Linux driver. Compared to that the queue management is drastically simplified, also we only support version 5 of the IP and RGMII connections between MAC and PHY, as used on the RPi4. Signed-off-by: Amit Singh Tomar Reviewed-by: Andre Przywara [Andre: heavy cleanup and a few fixes] Signed-off-by: Andre Przywara --- drivers/net/Kconfig| 7 + drivers/net/Makefile | 1 + drivers/net/bcmgenet.c | 722 + 3 files changed, 730 insertions(+) create mode 100644 drivers/net/bcmgenet.c diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 01d087f229..4d1013c984 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -136,6 +136,13 @@ config BCM6368_ETH help This driver supports the BCM6368 Ethernet MAC. +config BCMGENET + bool "BCMGENET V5 support" + depends on DM_ETH + select PHYLIB + help + This driver supports the BCMGENET Ethernet MAC. + config DWC_ETH_QOS bool "Synopsys DWC Ethernet QOS device support" depends on DM_ETH diff --git a/drivers/net/Makefile b/drivers/net/Makefile index 30991834ec..6e0a68834d 100644 --- a/drivers/net/Makefile +++ b/drivers/net/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_AG7XXX) += ag7xxx.o obj-$(CONFIG_ARMADA100_FEC) += armada100_fec.o obj-$(CONFIG_BCM6348_ETH) += bcm6348-eth.o obj-$(CONFIG_BCM6368_ETH) += bcm6368-eth.o +obj-$(CONFIG_BCMGENET) += bcmgenet.o obj-$(CONFIG_DRIVER_AT91EMAC) += at91_emac.o obj-$(CONFIG_DRIVER_AX88180) += ax88180.o obj-$(CONFIG_BCM_SF2_ETH) += bcm-sf2-eth.o diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c new file mode 100644 index 00..4f8f190071 --- /dev/null +++ b/drivers/net/bcmgenet.c @@ -0,0 +1,722 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Amit Singh Tomar + * + * Driver for Broadcom GENETv5 Ethernet controller (as found on the RPi4) + * This driver is based on the Linux driver: + * drivers/net/ethernet/broadcom/genet/bcmgenet.c + * which is: Copyright (c) 2014-2017 Broadcom + * + * The hardware supports multiple queues (16 priority queues and one + * default queue), both for RX and TX. There are 256 DMA descriptors (both + * for TX and RX), and they live in MMIO registers. The hardware allows + * assigning descriptor ranges to queues, but we choose the most simple setup: + * All 256 descriptors are assigned to the default queue (#16). + * Also the Linux driver supports multiple generations of the MAC, whereas + * we only support v5, as used in the Raspberry Pi 4. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* Register definitions derived from Linux source */ +#define SYS_REV_CTRL 0x00 + +#define SYS_PORT_CTRL 0x04 +#define PORT_MODE_EXT_GPHY 3 + +#define GENET_SYS_OFF 0x +#define SYS_RBUF_FLUSH_CTRL(GENET_SYS_OFF + 0x08) +#define SYS_TBUF_FLUSH_CTRL(GENET_SYS_OFF + 0x0c) + +#define GENET_EXT_OFF 0x0080 +#define EXT_RGMII_OOB_CTRL (GENET_EXT_OFF + 0x0c) +#define RGMII_LINK BIT(4) +#define OOB_DISABLEBIT(5) +#define RGMII_MODE_EN BIT(6) +#define ID_MODE_DISBIT(16) + +#define GENET_RBUF_OFF 0x0300 +#define RBUF_TBUF_SIZE_CTRL(GENET_RBUF_OFF + 0xb4) +#define RBUF_CTRL (GENET_RBUF_OFF + 0x00) +#define RBUF_ALIGN_2B BIT(1) + +#define GENET_UMAC_OFF 0x0800 +#define UMAC_MIB_CTRL (GENET_UMAC_OFF + 0x580) +#define UMAC_MAX_FRAME_LEN (GENET_UMAC_OFF + 0x014) +#define UMAC_MAC0 (GENET_UMAC_OFF + 0x00c) +#define UMAC_MAC1 (GENET_UMAC_OFF + 0x010) +#define UMAC_CMD (GENET_UMAC_OFF + 0x008) +#define MDIO_CMD (GENET_UMAC_OFF + 0x614) +#define UMAC_TX_FLUSH (GENET_UMAC_OFF + 0x334) +#define MDIO_START_BUSYBIT(29) +#define MDIO_READ_FAIL BIT(28) +#define MDIO_RD(2 << 26) +#define MDIO_WRBIT(26) +#define MDIO_PMD_SHIFT 21 +#define MDIO_PMD_MASK 0x1f +#define MDIO_REG_SHIFT 16 +#define MDIO_REG_MASK 0x1f + +#define CMD_TX_EN BIT(0) +#define CMD_RX_EN BIT(1) +#define UMAC_SPEED_10 0 +#define UMAC_SPEED_100 1 +#define UMAC_SPEED_10002 +#define
Re: question: mx7ulp - LDO_ENABLED_MODE
On 16/01/20 18:33:17, Fabio Estevam wrote:
> Hi Jorge,
>
> On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
> wrote:
> >
> > Hi Fabio,
> >
> > I am trying to enable LDO in an imx7ulp based board but somehow the
> > board locks up as soon I write to PMC1_RUN (using the init_ldo_mode
> > sequence).
>
> Just looked at the i.MX7UL Reference Manual and it says:
>
> "28.5.9.1.1 Using internal LDO regulator
> After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is
> turned
> off, the process to turn on the PMC 1 using the internal LDO regulator
> is as follows:
> • Assert the LDOEN bit (PMC0_CTRL).
> • Assert the LDOOKDIS bit (PMC0_CTRL) if required.
> • Assert the PMC1ON bit (PMC0_CTRL)."
>
> So it seems we need to change the order to:
>
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -122,9 +122,6 @@ static void init_ldo_mode(void)
> {
> unsigned int reg;
>
> - /* Set LDOOKDIS */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> -
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> reg &= ~PMC1_LDOVL_MASK;
> @@ -151,6 +148,9 @@ static void init_ldo_mode(void)
> /* Set LDOEN bit */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
>
> + /* Set LDOOKDIS */
> + setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> +
> /* Set the PMC1ON bit */
> setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
> }
>
> Does this help?
no, unfortunately the same thing.
I think PMC0_CTRL_PMC1ON should not be on but cant figure out who sets it up.
>
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
>
> I think it was not set by default. I can confirm tomorrow with a
> i.MX7ULP Embedded Artists board.
that would be awesome. thanks a lot!
>
> Regards,
>
> Fabio Estevam
Re: question: mx7ulp - LDO_ENABLED_MODE
On 16/01/20 19:04:09, Fabio Estevam wrote:
> Hi Jorge,
>
> On Thu, Jan 16, 2020 at 6:51 PM Fabio Estevam wrote:
>
> > Could you please test these two patches? (They were only compiled tested)
>
> Please discard these patches. Just realized that CTRL is at a
> different offset for PMC1.
>
> Please try these instead.
um still nothing.
will debug more in the morning - will add more debug info.
thanks for the quick responses!
jorge
> From 50d4598ae23c549fe3809bfa5f365364ac36d71b Mon Sep 17 00:00:00 2001
> From: Fabio Estevam
> Date: Thu, 16 Jan 2020 18:59:30 -0300
> Subject: [PATCH 1/2] mx7ulp: Fix the PMC register set
>
> On i.MX7ULP the PMC0 registers control the M4 side and
> the PMC1 controls the A7 side.
>
> In order to enable the A7 LDO-enabled mode the PMC1 registers
> need to configured instead.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/mach-imx/mx7ulp/soc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
> index 8345b01398..481cfe226a 100644
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -16,6 +16,7 @@
> #define PMC0_CTRL_LDOOKDIS BIT(30)
> #define PMC0_CTRL_PMC1ON BIT(24)
> #define PMC1_BASE_ADDR 0x4040
> +#define PMC1_CTRL0x24
> #define PMC1_RUN 0x8
> #define PMC1_STOP0x10
> #define PMC1_VLPS0x14
> @@ -123,7 +124,7 @@ static void init_ldo_mode(void)
> unsigned int reg;
>
> /* Set LDOOKDIS */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
>
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> @@ -149,10 +150,10 @@ static void init_ldo_mode(void)
> writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
>
> /* Set LDOEN bit */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
>
> /* Set the PMC1ON bit */
> - setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
> }
> #endif
>
> @@ -198,7 +199,7 @@ static bool ldo_mode_is_enabled(void)
> {
> unsigned int reg;
>
> - reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
> + reg = readl(PMC1_BASE_ADDR + PMC1_CTRL);
> if (reg & PMC0_CTRL_LDOEN)
> return true;
> else
> --
> 2.17.1
>
> From d1a07fb70610184c042df7f593dd0ff8302235c8 Mon Sep 17 00:00:00 2001
> From: Fabio Estevam
> Date: Thu, 16 Jan 2020 19:00:23 -0300
> Subject: [PATCH 2/2] mx7ulp: Fix the order for enabling LDO
>
> As per the i.MX7ULP Reference Manual:
>
> "28.5.9.1.1 Using internal LDO regulator
> After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is
> turned
> off, the process to turn on the PMC 1 using the internal LDO regulator
> is as follows:
> - Assert the LDOEN bit (PMC0_CTRL).
> - Assert the LDOOKDIS bit (PMC0_CTRL) if required.
> - Assert the PMC1ON bit (PMC0_CTRL)."
>
> So follow the recommended intialization order.
>
> Signed-off-by: Fabio Estevam
> ---
> arch/arm/mach-imx/mx7ulp/soc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
> index 481cfe226a..9b114a8604 100644
> --- a/arch/arm/mach-imx/mx7ulp/soc.c
> +++ b/arch/arm/mach-imx/mx7ulp/soc.c
> @@ -123,9 +123,6 @@ static void init_ldo_mode(void)
> {
> unsigned int reg;
>
> - /* Set LDOOKDIS */
> - setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
> -
> /* Set LDOVL to 0.95V in PMC1_RUN */
> reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
> reg &= ~PMC1_LDOVL_MASK;
> @@ -152,6 +149,9 @@ static void init_ldo_mode(void)
> /* Set LDOEN bit */
> setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
>
> + /* Set LDOOKDIS */
> + setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
> +
> /* Set the PMC1ON bit */
> setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
> }
> --
> 2.17.1
>
Re: question: mx7ulp - LDO_ENABLED_MODE
On Thu, Jan 16, 2020 at 7:24 PM Jorge Ramirez-Ortiz, Gmail wrote: > um still nothing. > will debug more in the morning - will add more debug info. > thanks for the quick responses! Ok, just tested mainline U-Boot (without any changes) on my i.MX7ULP boards. On mx7ulp_evk I see: PMC1: LDO bypass mode and on mx7ul_com board I see: PMC1: LDO enabled mode The code I did to set and check LDO enabled is according to the RM and it seems to behave properly on these two boards. Let me know if you make any progress. Fabio Estevam
Re: question: mx7ulp - LDO_ENABLED_MODE
Hi Jorge,
On Thu, Jan 16, 2020 at 6:51 PM Fabio Estevam wrote:
> Could you please test these two patches? (They were only compiled tested)
Please discard these patches. Just realized that CTRL is at a
different offset for PMC1.
Please try these instead.
From 50d4598ae23c549fe3809bfa5f365364ac36d71b Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Thu, 16 Jan 2020 18:59:30 -0300
Subject: [PATCH 1/2] mx7ulp: Fix the PMC register set
On i.MX7ULP the PMC0 registers control the M4 side and
the PMC1 controls the A7 side.
In order to enable the A7 LDO-enabled mode the PMC1 registers
need to configured instead.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx7ulp/soc.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 8345b01398..481cfe226a 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -16,6 +16,7 @@
#define PMC0_CTRL_LDOOKDIS BIT(30)
#define PMC0_CTRL_PMC1ON BIT(24)
#define PMC1_BASE_ADDR 0x4040
+#define PMC1_CTRL 0x24
#define PMC1_RUN 0x8
#define PMC1_STOP 0x10
#define PMC1_VLPS 0x14
@@ -123,7 +124,7 @@ static void init_ldo_mode(void)
unsigned int reg;
/* Set LDOOKDIS */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
+ setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
@@ -149,10 +150,10 @@ static void init_ldo_mode(void)
writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
/* Set LDOEN bit */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
+ setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
/* Set the PMC1ON bit */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
+ setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
}
#endif
@@ -198,7 +199,7 @@ static bool ldo_mode_is_enabled(void)
{
unsigned int reg;
- reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
+ reg = readl(PMC1_BASE_ADDR + PMC1_CTRL);
if (reg & PMC0_CTRL_LDOEN)
return true;
else
--
2.17.1
From d1a07fb70610184c042df7f593dd0ff8302235c8 Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Thu, 16 Jan 2020 19:00:23 -0300
Subject: [PATCH 2/2] mx7ulp: Fix the order for enabling LDO
As per the i.MX7ULP Reference Manual:
"28.5.9.1.1 Using internal LDO regulator
After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is turned
off, the process to turn on the PMC 1 using the internal LDO regulator
is as follows:
- Assert the LDOEN bit (PMC0_CTRL).
- Assert the LDOOKDIS bit (PMC0_CTRL) if required.
- Assert the PMC1ON bit (PMC0_CTRL)."
So follow the recommended intialization order.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx7ulp/soc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 481cfe226a..9b114a8604 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -123,9 +123,6 @@ static void init_ldo_mode(void)
{
unsigned int reg;
- /* Set LDOOKDIS */
- setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
-
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
reg &= ~PMC1_LDOVL_MASK;
@@ -152,6 +149,9 @@ static void init_ldo_mode(void)
/* Set LDOEN bit */
setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOEN);
+ /* Set LDOOKDIS */
+ setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_LDOOKDIS);
+
/* Set the PMC1ON bit */
setbits_le32(PMC1_BASE_ADDR + PMC1_CTRL, PMC0_CTRL_PMC1ON);
}
--
2.17.1
Re: question: mx7ulp - LDO_ENABLED_MODE
Hi Jorge,
On Thu, Jan 16, 2020 at 6:33 PM Fabio Estevam wrote:
> > I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> > I am wondering if you think it is possible - in your experience- that
> > ROM might have already configured LDO? or was this also the case -
> > this bit already set- when you tested the feature?
I think I understand the problem now.
We are currently acessing the PMC0 registers, which control the M4 side.
M4 has LDO enabled set by the ROM, so that's why you see it enabled by default.
We need to access the PMC1 registers instead of PMC0.
Could you please test these two patches? (They were only compiled tested)
Regards,
Fabio Estevam
From bac282ace36ccbb4c46eda03b479eeba6953ff90 Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Thu, 16 Jan 2020 18:42:26 -0300
Subject: [PATCH 1/2] mx7ulp: Fix the PMC register set
On i.MX7ULP the PMC0 registers control the M4 side and
the PMC1 controls the A7 side.
In order to enable LDO mode the PMC1 registers need to
configured.
Reported-by: Jorge Ramirez-Ortiz
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx7ulp/soc.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 8345b01398..f9cfec72b2 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -10,11 +10,10 @@
#include
#include
-#define PMC0_BASE_ADDR 0x410a1000
-#define PMC0_CTRL 0x28
-#define PMC0_CTRL_LDOEN BIT(31)
-#define PMC0_CTRL_LDOOKDIS BIT(30)
-#define PMC0_CTRL_PMC1ON BIT(24)
+#define PMC_CTRL 0x28
+#define PMC_CTRL_LDOEN BIT(31)
+#define PMC_CTRL_LDOOKDIS BIT(30)
+#define PMC_CTRL_PMC1ON BIT(24)
#define PMC1_BASE_ADDR 0x4040
#define PMC1_RUN 0x8
#define PMC1_STOP 0x10
@@ -123,7 +122,7 @@ static void init_ldo_mode(void)
unsigned int reg;
/* Set LDOOKDIS */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
+ setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_LDOOKDIS);
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
@@ -149,10 +148,10 @@ static void init_ldo_mode(void)
writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
/* Set LDOEN bit */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
+ setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_LDOEN);
/* Set the PMC1ON bit */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
+ setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_PMC1ON);
}
#endif
@@ -190,16 +189,15 @@ const char *get_imx_type(u32 imxtype)
return "7ULP";
}
-#define PMC0_BASE_ADDR 0x410a1000
-#define PMC0_CTRL 0x28
-#define PMC0_CTRL_LDOEN BIT(31)
+#define PMC_CTRL 0x28
+#define PMC_CTRL_LDOEN BIT(31)
static bool ldo_mode_is_enabled(void)
{
unsigned int reg;
- reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
- if (reg & PMC0_CTRL_LDOEN)
+ reg = readl(PMC1_BASE_ADDR + PMC_CTRL);
+ if (reg & PMC_CTRL_LDOEN)
return true;
else
return false;
--
2.17.1
From 5c1dca768ef6e8deeb34eccac7e2c8ce06b4ef04 Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Thu, 16 Jan 2020 18:43:21 -0300
Subject: [PATCH 2/2] mx7ulp: Fix the order for enabling LDO
As per the i.MX7ULP Reference Manual:
"28.5.9.1.1 Using internal LDO regulator
After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is turned
off, the process to turn on the PMC 1 using the internal LDO regulator
is as follows:
- Assert the LDOEN bit (PMC0_CTRL).
- Assert the LDOOKDIS bit (PMC0_CTRL) if required.
- Assert the PMC1ON bit (PMC0_CTRL)."
So follow the recommended intialization order.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/mx7ulp/soc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index f9cfec72b2..8d232dd894 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -121,9 +121,6 @@ static void init_ldo_mode(void)
{
unsigned int reg;
- /* Set LDOOKDIS */
- setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_LDOOKDIS);
-
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
reg &= ~PMC1_LDOVL_MASK;
@@ -150,6 +147,9 @@ static void init_ldo_mode(void)
/* Set LDOEN bit */
setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_LDOEN);
+ /* Set LDOOKDIS */
+ setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_LDOOKDIS);
+
/* Set the PMC1ON bit */
setbits_le32(PMC1_BASE_ADDR + PMC_CTRL, PMC_CTRL_PMC1ON);
}
--
2.17.1
Re: question: mx7ulp - LDO_ENABLED_MODE
Hi Jorge,
On Thu, Jan 16, 2020 at 5:30 PM Jorge Ramirez-Ortiz, Foundries
wrote:
>
> Hi Fabio,
>
> I am trying to enable LDO in an imx7ulp based board but somehow the
> board locks up as soon I write to PMC1_RUN (using the init_ldo_mode
> sequence).
Just looked at the i.MX7UL Reference Manual and it says:
"28.5.9.1.1 Using internal LDO regulator
After a POR event, when the PMC 0 is running in RUN mode and the PMC 1 is turned
off, the process to turn on the PMC 1 using the internal LDO regulator
is as follows:
• Assert the LDOEN bit (PMC0_CTRL).
• Assert the LDOOKDIS bit (PMC0_CTRL) if required.
• Assert the PMC1ON bit (PMC0_CTRL)."
So it seems we need to change the order to:
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -122,9 +122,6 @@ static void init_ldo_mode(void)
{
unsigned int reg;
- /* Set LDOOKDIS */
- setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
-
/* Set LDOVL to 0.95V in PMC1_RUN */
reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
reg &= ~PMC1_LDOVL_MASK;
@@ -151,6 +148,9 @@ static void init_ldo_mode(void)
/* Set LDOEN bit */
setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
+ /* Set LDOOKDIS */
+ setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
+
/* Set the PMC1ON bit */
setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
}
Does this help?
> I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
> I am wondering if you think it is possible - in your experience- that
> ROM might have already configured LDO? or was this also the case -
> this bit already set- when you tested the feature?
I think it was not set by default. I can confirm tomorrow with a
i.MX7ULP Embedded Artists board.
Regards,
Fabio Estevam
Re: Please pull mmc-1-16-2020
On Thu, Jan 16, 2020 at 09:47:26AM +, Peng Fan wrote: > Hi Tom, > > Please pull mmc-1-16-2020 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/master
On Thu, Jan 16, 2020 at 03:34:55PM +0100, Stefan Roese wrote: > Hi Tom, > > please pull the first batch of MVEBU related patches in this merge > window: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: fat: handle Windows formatted partition (thru USB Mass Storage)
On Thu, Jan 16, 2020 at 9:20 PM Heinrich Schuchardt wrote: > On 1/16/20 11:39 AM, Andy Shevchenko wrote: > > > >>> Obviously U-Boot's fat code cannot handle it. > >> > >> So precisely, U-Boot cannot handle nested partition( table)s? > > > > Seems so. We need to be able to supply the partition number we would > > like to open, something like > >cmd [[:[:]]] > > otherwise it will require some (error prone) heuristics to understand > > which one user would like to use. > > > > I have formatted a USB stick Windows 10. That is *not* the case I'm describing. Maybe I described it wrong. Let me try again. Prerequisites: - the board with U-Boot and installed Linux OS on eMMC - g_multi module in Linux OS that shares *one of the eMMC partitions* (pay attention here) as a disk to Windows host Now, when you format that exposed disk (which is actually a partition on eMMC!) in Windows, you will get nested partitioning. P.S. I can easily reproduce this on real device with latest U-Boot. U-Boot has obvious issue with recognizing such disks. -- With Best Regards, Andy Shevchenko
question: mx7ulp - LDO_ENABLED_MODE
Hi Fabio,
I am trying to enable LDO in an imx7ulp based board but somehow the
board locks up as soon I write to PMC1_RUN (using the init_ldo_mode
sequence).
I think it is interesting that bit PMC0_CTRL_PMC1ON is already set so
I am wondering if you think it is possible - in your experience- that
ROM might have already configured LDO? or was this also the case -
this bit already set- when you tested the feature?
I also noticed that if I dont execute the init_ldo_mode sequence and
just check for the LODEN bit [see snipet below], this is already set
which too seems strange.
any suggestions or thoughts?
thanks in advance!
Jorge
#define PMC0_BASE_ADDR 0x410a1000
#define PMC0_CTRL 0x28
#define PMC0_CTRL_LDOEN BIT(31)
static bool ldo_mode_is_enabled(void)
{
unsigned int reg;
reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
if (reg & PMC0_CTRL_LDOEN)
return true;
else
return false;
}
[PATCH 1/1] Dockerfile: add graphviz
In reStructured text documentation we somtimes find formatting problems. Therefore I would like to add 'make htmldocs' to our Gitlab Ci steps and let all warning result in a build failure. For building the htmldocs target without warnings we need the Graphviz package. Signed-off-by: Heinrich Schuchardt --- resent due to missing Cc:u-boot@lists.denx.de --- Dockerfile | 1 + 1 file changed, 1 insertion(+) diff --git a/Dockerfile b/Dockerfile index d73ff3f..7d6d322 100644 --- a/Dockerfile +++ b/Dockerfile @@ -49,6 +49,7 @@ RUN apt-get update && apt-get install -y \ flex \ gdisk \ git \ + graphviz \ grub-efi-amd64-bin \ grub-efi-ia32-bin \ iasl \ -- 2.24.1
[PATCH] disk: part: rename parameter of lba512_muldiv()
div_by is a misleading parameter name, when we are doing >> div_by.
Rename it to right_shift.
Reported-by: Simon Glass
Signed-off-by: Heinrich Schuchardt
---
disk/part.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 8982ef3bae..4cc2fc19f7 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -104,17 +104,18 @@ typedef lbaint_t lba512_t;
#endif
/*
- * Overflowless variant of (block_count * mul_by / 2**div_by)
- * when div_by > mul_by
+ * Overflowless variant of (block_count * mul_by / 2**right_shift)
+ * when 2**right_shift > mul_by
*/
-static lba512_t lba512_muldiv(lba512_t block_count, lba512_t mul_by, int
div_by)
+static lba512_t lba512_muldiv(lba512_t block_count, lba512_t mul_by,
+ int right_shift)
{
lba512_t bc_quot, bc_rem;
/* x * m / d == x / d * m + (x % d) * m / d */
- bc_quot = block_count >> div_by;
- bc_rem = block_count - (bc_quot << div_by);
- return bc_quot * mul_by + ((bc_rem * mul_by) >> div_by);
+ bc_quot = block_count >> right_shift;
+ bc_rem = block_count - (bc_quot << right_shift);
+ return bc_quot * mul_by + ((bc_rem * mul_by) >> right_shift);
}
void dev_print (struct blk_desc *dev_desc)
--
2.24.1
Re: fat: handle Windows formatted partition (thru USB Mass Storage)
On 1/16/20 11:39 AM, Andy Shevchenko wrote: Obviously U-Boot's fat code cannot handle it. So precisely, U-Boot cannot handle nested partition( table)s? Seems so. We need to be able to supply the partition number we would like to open, something like cmd [[:[:]]] otherwise it will require some (error prone) heuristics to understand which one user would like to use. I have formatted a USB stick Windows 10. When I display the partition table with fdisk it shows: Device Boot StartEndSectors Size Id Type /dev/sdb1 1935758368 3615603091 1679844724 801G 61 SpeedStor /dev/sdb20 0 0 0B 65 Novell Netware 386 /dev/sdb4 28049408 28049850443 221.5K 0 Empty But there is no partition table at all. The FAT filesystem starts at sector 0. I can mount the disk with sudo mount /dev/sdb /mnt In U-Boot I can read the file system as partition 0: => ls scsi 0:0 System Volume Information/ 11 test.txt.txt 1 file(s), 1 dir(s) => load scsi 0:0 0x4020 test.txt.txt 11 bytes read in 10 ms (1000 Bytes/s) => md.b 0x4020 b 4020: 48 65 6c 6c 6f 20 77 6f 72 6c 64 Hello world => The UEFI shell started from U-Boot sees the file system: Mapping table FS0: Alias(s):F0a0:;BLK0: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0) In the UEFI shell I created a new text file. I could read it in Windows. Now I formatted the USB in Linux with gdisk to give it a GPT partition table: Number Start (sector)End (sector) Size Code Name 1204833556479 16.0 GiB0700 Microsoft basic data 23355648062521310 13.8 GiB0700 Microsoft basic data and formatted the partitions with mkfs.vfat as FAT32. Now Windows sees this USB stick as two partions and can read files created in Linux. So this is what I learnt: Windows 10 does not support MBR partition tables on USB sticks. Windows 10 supports GPT partition tables on USB sticks. Windows formats empty USB sticks without any partition table at all. There is no obvious compatibility issue in U-Boot. Best regards Heinrich
Re: [RFC PATCH] Revert "arm: Show cache warnings in U-Boot proper only"
On Tue, Jan 07, 2020 at 06:14:22PM +, Andre Przywara wrote:
> On Mon, 6 Jan 2020 11:01:21 -0500
> Tom Rini wrote:
>
> Hi Tom,
>
> thanks for chiming in on this!
>
> > On Thu, Dec 19, 2019 at 12:32:09PM +, Andre Przywara wrote:
> > > On Thu, 19 Dec 2019 12:43:35 +0100
> > > Marek Vasut wrote:
> > >
> > > Hi Marek,
> > >
> > > > On 12/19/19 12:36 PM, Andre Przywara wrote:
> > > > > On Thu, 19 Dec 2019 09:04:32 +0100
> > > > > Marek Vasut wrote:
> > > > >> On 12/19/19 2:23 AM, André Przywara wrote:
> > > > >>> On 19/12/2019 00:55, Marek Vasut wrote:
> > > > On 12/19/19 1:52 AM, Andre Przywara wrote:
> > > > > According to commit 11aa6a32eb5f ("arm: cache: Implement cache
> > > > > range
> > > > > check for v7"), which introduced check_cache_range(), this was
> > > > > meant
> > > > > as a pure debugging feature, only to be compiled in when a
> > > > > developer
> > > > > explicitly #defined DEBUG in cache.c. Presumably the intention
> > > > > was to
> > > > > help with finding *certain* alignment issues with DMA buffers.
> > > > >
> > > > > Commit bcc53bf09589 ("arm: Show cache warnings in U-Boot proper
> > > > > only")
> > > > > compiled this in *unconditionally* into U-Boot proper.
> > > > >
> > > > > This has the annoying side effect of producing tons of somewhat
> > > > > pointless warnings about non-aligned clean operations,
> > > > > which
> > > > > tend to be appeased by even more pointless rounding operations in
> > > > > many
> > > > > drivers (mostly those used on ARM boards).
> > > > >
> > > > > Bring back the old behaviour, of only compiling this in for DEBUG
> > > > > situations, but staying silent otherwise.
> > > > >
> > > > > This reverts commit bcc53bf095893fbdae531a9a7b5d4ef4a125a7fc.
> > > > >
> > > > > Signed-off-by: Andre Przywara
> > > > > ---
> > > > > Hi,
> > > > >
> > > > > if the intention was indeed to always force cache maintenance
> > > > > range
> > > > > alignments, I would like to open a discussion on this, because I
> > > > > believe
> > > > > it is not useful, especially in the clean case.
> > > >
> > > > Why don't you rather fix the cache op alignment bugs ?
> > > > >>>
> > > > >>> Which bugs do you mean?
> > > > >>
> > > > >> Well, the ones reported by this warning.
> > > > >
> > > > > As mentioned, most of them are just silenced in drivers, though not
> > > > > actually fixed.
> > > >
> > > > Do you have specific details here ? They should be fixed.
> > > >
> > > > > This patch here was actually triggered by me cleaning up
> > > > > sun8i-emac.c, which then made those warnings appear again.
> > > > > I will try to send out this series, which might make it more clear
> > > > > what I am after.
> > > > >
> > > > >>> Those that would currently trigger those warnings?
> > > > >>> I don't think they are actual bugs, besides I don't think they are
> > > > >>> any
> > > > >>> cases left for 32-bit ARM boards (leave alone the new RPi4 Ethernet
> > > > >>> driver in the rpi-4-32b_defconfig).
> > > > >>
> > > > >> If your cache isn't flushed or invalidated properly, it's a bug.
> > > > >> On ARM32, this is (was, before this warning) a real problem.
> > > > >
> > > > > The actual cache maintenance is fine in the drivers, it's the
> > > > > over-strict alignment requirements that bothers me and makes things
> > > > > actually worse:
> > > > >
> > > > > Architecturally (ARM ARM) there is no alignment requirement for VA
> > > > > operations. Walking over a range of addresses does get easier if you
> > > > > start on a cache line boundary, so this is what we do in the
> > > > > implementations for v7 and v8.
> > > >
> > > > U-Boot is not only V7 and V8, but also all the earlier ones (back to
> > > > V4).
> > >
> > > I checked v6 as well (same), and couldn't find any evidence that this
> > > would be different for v5 or v4, although CP15 does not seem to be
> > > architecturally defined there. Do you have an example of an older core
> > > failing that?
> > > But anyway this particular check and patch is affecting v7 only.
> > >
> > > > > Alignment gets critical when it comes to a pure invalidate call. If
> > > > > you have other dirty data in this same cache line, you might lose the
> > > > > latest stores, that's why it is important to align those *buffers*.
> > > > > So the strict check we have in v7_dcache_inval_range() is the right
> > > > > thing (at least for the base address). What is not right is to
> > > > > deliberately align just the *parameters* of the invalidate call, as
> > > > > seens in net/sun8i_emac.c or net/dwc_eth_qos.c, for instance. This
> > > > > could actually hide bugs. Drivers should always pass on the actual
> > > > > buffer address to invalidate().
> > > >
> > > > Sure, but that's
Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
On Thu, Jan 16, 2020 at 08:03:51PM +0200, Igor Opaniuk wrote:
> Hi Fabio,
>
> On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam wrote:
> >
> > Hi Anatolij,
> >
> > On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin wrote:
> >
> > > Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot
> > > test, but I have an i.MX8QXP based custom SoM with console on ttyLP2.
> > > Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga
> > > and it boots successfully (with NFS rootfs or rootfs on eMMC).
> >
> > I have just tested imx_4.14.98_2.0.0_ga and still get the same hang.
> >
> > [Adding Marcel]
> Marcel is on vacation.
>
> FYI, mainline U-boot is broken on all our iMX8QXP and iMX8QM SoMs
> at all since f0cc4eae9a ("core: device: use dev_power_domain_on") is merged,
> the
> status hasn't changed. I haven't got deeply into this issue, just
> quickly tried different
> combinations of TF-A and SECO/SCFW, none of them has any impact.
> Will get back to this issue soon.
> >
> > Just wondering if anyone else managed to boot mainline U-Boot with
> > mainline kernel on i.MX8QXP.
> I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
Adding in Lokesh as he nak'd the revert before because that would break
other platforms and I chimed in saying that breaking one set of
platforms to unbreak another set of platforms isn't a trade-off I like.
--
Tom
signature.asc
Description: PGP signature
Re: libfdt update increase boot time
Hi Patrice, On Fri, 17 Jan 2020 at 06:56, Patrice CHOTARD wrote: > > Hi All > > Since the last sync of libfdt [1], boot time increase of 2.3 seconds on > STM32MP1 dk2 board > > On v2020.1 tag: > > STM32MP> bootstage report > Timer summary in microseconds (9 records): >MarkElapsed Stage > 0 0 reset > 571,804571,804 board_init_f > 3,535,935 2,964,131 board_init_r > 3,954,721418,786 id=64 > 4,006,006 51,285 id=65 > 4,006,708702 main_loop > 4,559,423552,715 id=175 > > After reverting 'f0921f5098d8 (dt: Sync up to the latest libfdt)', boot time > was restored: > > STM32MP> bootstage report > Timer summary in microseconds (9 records): >MarkElapsed Stage > 0 0 reset > 568,918568,918 board_init_f > 1,801,471 1,232,553 board_init_r > 2,074,570273,099 id=64 > 2,101,242 26,672 id=65 > 2,101,944702 main_loop > 3,229,354 1,127,410 id=175 > > After some investigation, the new implementation of fdt32_ld() is responsible > of this time consuming. > > Same issue has been already encountered on TF-A side [2]. TF-A community has > decided to not update libfdt with v1.4.7 > > and stayed on the previous one v1.4.6 to avoid similar regression. I think it would be worth having an option to use a simple read instead of the unaligned handling of fdt32_ld. We could have it as an assumption, e.g. fdt_chk_alignment(). Regards, Simon > > > Thanks > > Patrice > > > [1] https://patchwork.ozlabs.org/cover/1185039/ > > [2] https://github.com/dgibson/dtc/issues/19 >
Re: libfdt update increase boot time
On Thu, Jan 16, 2020 at 05:56:27PM +, Patrice CHOTARD wrote: > Hi All > > Since the last sync of libfdt [1], boot time increase of 2.3 seconds on > STM32MP1 dk2 board > > On v2020.1 tag: > > STM32MP> bootstage report > Timer summary in microseconds (9 records): > Mark Elapsed Stage > 0 0 reset > 571,804 571,804 board_init_f > 3,535,935 2,964,131 board_init_r > 3,954,721 418,786 id=64 > 4,006,006 51,285 id=65 > 4,006,708 702 main_loop > 4,559,423 552,715 id=175 > > After reverting 'f0921f5098d8 (dt: Sync up to the latest libfdt)', boot time > was restored: > > STM32MP> bootstage report > Timer summary in microseconds (9 records): > Mark Elapsed Stage > 0 0 reset > 568,918 568,918 board_init_f > 1,801,471 1,232,553 board_init_r > 2,074,570 273,099 id=64 > 2,101,242 26,672 id=65 > 2,101,944 702 main_loop > 3,229,354 1,127,410 id=175 > > After some investigation, the new implementation of fdt32_ld() is responsible > of this time consuming. > > Same issue has been already encountered on TF-A side [2]. TF-A community has > decided to not update libfdt with v1.4.7 > > and stayed on the previous one v1.4.6 to avoid similar regression. > > > Thanks > > Patrice > > > [1] https://patchwork.ozlabs.org/cover/1185039/ > > [2] https://github.com/dgibson/dtc/issues/19 Ugh, this looks to be related to https://www.spinics.net/lists/devicetree-compiler/msg02230.html and thus the platform doing something wrong. I'm going to chime in. As an interim step can you please post a patch that reverts the two upstream changes and brings back the old behavior? That way I'll hopefully not let this slip my mind to make sure gets fixed here. Thanks! -- Tom signature.asc Description: PGP signature
Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
Hi Fabio,
On Thu, Jan 16, 2020 at 6:38 PM Fabio Estevam wrote:
>
> Hi Anatolij,
>
> On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin wrote:
>
> > Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot
> > test, but I have an i.MX8QXP based custom SoM with console on ttyLP2.
> > Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga
> > and it boots successfully (with NFS rootfs or rootfs on eMMC).
>
> I have just tested imx_4.14.98_2.0.0_ga and still get the same hang.
>
> [Adding Marcel]
Marcel is on vacation.
FYI, mainline U-boot is broken on all our iMX8QXP and iMX8QM SoMs
at all since f0cc4eae9a ("core: device: use dev_power_domain_on") is merged, the
status hasn't changed. I haven't got deeply into this issue, just
quickly tried different
combinations of TF-A and SECO/SCFW, none of them has any impact.
Will get back to this issue soon.
>
> Just wondering if anyone else managed to boot mainline U-Boot with
> mainline kernel on i.MX8QXP.
I can test it for you with the revert patch for f0cc4eae9a applied tomorrow.
>
> If so, what firmware combination was used?
>
> Thanks
Thanks
--
Best regards - Freundliche Grüsse - Meilleures salutations
Igor Opaniuk
mailto: igor.opan...@gmail.com
skype: igor.opanyuk
+380 (93) 836 40 67
http://ua.linkedin.com/in/iopaniuk
libfdt update increase boot time
Hi All Since the last sync of libfdt [1], boot time increase of 2.3 seconds on STM32MP1 dk2 board On v2020.1 tag: STM32MP> bootstage report Timer summary in microseconds (9 records): Mark Elapsed Stage 0 0 reset 571,804 571,804 board_init_f 3,535,935 2,964,131 board_init_r 3,954,721 418,786 id=64 4,006,006 51,285 id=65 4,006,708 702 main_loop 4,559,423 552,715 id=175 After reverting 'f0921f5098d8 (dt: Sync up to the latest libfdt)', boot time was restored: STM32MP> bootstage report Timer summary in microseconds (9 records): Mark Elapsed Stage 0 0 reset 568,918 568,918 board_init_f 1,801,471 1,232,553 board_init_r 2,074,570 273,099 id=64 2,101,242 26,672 id=65 2,101,944 702 main_loop 3,229,354 1,127,410 id=175 After some investigation, the new implementation of fdt32_ld() is responsible of this time consuming. Same issue has been already encountered on TF-A side [2]. TF-A community has decided to not update libfdt with v1.4.7 and stayed on the previous one v1.4.6 to avoid similar regression. Thanks Patrice [1] https://patchwork.ozlabs.org/cover/1185039/ [2] https://github.com/dgibson/dtc/issues/19
Re: EHCI timeout on Beagleboard xM with u-boot 2020.01
On Wed, Jan 15, 2020 at 01:31:13PM +, Guillaume Gardet wrote: > Hi, > > Booting u-boot 2020.01 on a Beagleboard xM, I get the following EHCI timeouts: > ** > USB0: USB EHCI 1.00 > scanning bus 0 for devices... EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008d80 > EHCI timed out on TD - token=0x80008c80 > EHCI timed out on TD - token=0x80008c80 > EHCI timed out on TD - token=0x80008c80 > EHCI timed out on TD - token=0x80008c80 > EHCI timed out on TD - token=0x80008c80 > 2 USB Device(s) found >scanning usb for ethernet devices... 0 Ethernet Device(s) found > ** Can you bisect down to when this was introduced? Thanks. -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] Xilinx patches for v2020.04
On Thu, Jan 16, 2020 at 08:39:31AM +0100, Michal Simek wrote: > Hi Tom, > > please pull the following changes to your tree. > The major part of this pull request is using only one defconfig for > Xilinx ZynqMP platforms. The same change should also happen with Zynq > platforms but I haven't had a time to do it (Microblaze is using it from > the begining and Versal too). > I have also added that custom script for u-boot.itb generation to get > things going before unification can happen as we talked about. > > I have sync up Linux DT with U-Boot but still there are things to work on. > > There are some minor changes in generic code. For more information take > a look at tag description below. > > Travis looks good > https://travis-ci.org/michalsimek/u-boot/builds/636763911 > and gitlab CI too. > https://gitlab.denx.de/u-boot/custodians/u-boot-microblaze/pipelines/1849 > > Thanks, > Michal > > > The following changes since commit 88366b96ee0d8640b2af53e4026dbaeed0fab5e0: > > travis: Switch to QEMU v4.2.0 globally (2020-01-11 08:07:03 -0500) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2020.04 > > for you to fetch changes up to ddb55ff8a66dabe3365735eff9f901bb259c223f: > > arm64: versal: Enable board_late_init calling (2020-01-14 09:06:42 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
Hi Fabio, On Thu, 16 Jan 2020 13:38:26 -0300 Fabio Estevam feste...@gmail.com wrote: > Hi Anatolij, > > On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin wrote: > > > Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot > > test, but I have an i.MX8QXP based custom SoM with console on ttyLP2. > > Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga > > and it boots successfully (with NFS rootfs or rootfs on eMMC). > > I have just tested imx_4.14.98_2.0.0_ga and still get the same hang. then it might be due to scfw API incompatibility? > [Adding Marcel] > > Just wondering if anyone else managed to boot mainline U-Boot with > mainline kernel on i.MX8QXP. yesterday I wanted to test some mainline drivers on my SoM and created simple device tree for booting with console output. Mainline kernel v5.5-rc6 booted successfully, (but without FEC support). > If so, what firmware combination was used? Unfortunately, my i.MX8QXP SoM was damaged today and it doesn't boot any more and it is not recoverable, so I cannot check the used firmware hashes. I only know that it was something from 4.14.98_2.0.0_ga release. -- Anatolij
Re: [PATCH] mx7dsabre: Fix dm probe pmic
Hi Joris,
On Thu, Jan 16, 2020 at 1:41 PM Joris Offouga wrote:
>
> With commit mx7dsabre: Enable DM_ETH 0d52bab4
Please reference commit like this:
With commit 0d52bab4621 ("mx7dsabre: Enable DM_ETH")
BTW, it would be better if this commit were split in two:
- One for syncing the dts
- Other one for converting to DM_ETH
>
> Device Tree has been update and change pfuze3000 node
>
> Signed-off-by: Joris Offouga
> ---
> board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c
> b/board/freescale/mx7dsabresd/mx7dsabresd.c
> index 835eed3316..41c620795c 100644
> --- a/board/freescale/mx7dsabresd/mx7dsabresd.c
> +++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
> @@ -264,7 +264,7 @@ int power_init_board(void)
> struct udevice *dev;
> int ret, dev_id, rev_id;
>
> - ret = pmic_get("pfuze3000@08", );
> + ret = pmic_get("pfuze3000@8", );
Thanks for the fix:
Reviewed-by: Fabio Estevam
[PATCH] mx7dsabre: Fix dm probe pmic
With commit mx7dsabre: Enable DM_ETH 0d52bab4
Device Tree has been update and change pfuze3000 node
Signed-off-by: Joris Offouga
---
board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/freescale/mx7dsabresd/mx7dsabresd.c
b/board/freescale/mx7dsabresd/mx7dsabresd.c
index 835eed3316..41c620795c 100644
--- a/board/freescale/mx7dsabresd/mx7dsabresd.c
+++ b/board/freescale/mx7dsabresd/mx7dsabresd.c
@@ -264,7 +264,7 @@ int power_init_board(void)
struct udevice *dev;
int ret, dev_id, rev_id;
- ret = pmic_get("pfuze3000@08", );
+ ret = pmic_get("pfuze3000@8", );
if (ret == -ENODEV)
return 0;
if (ret != 0)
--
2.20.1
Re: imx8qxp mek: Booting mainline kernel with mainline U-Boot
Hi Anatolij, On Tue, Jan 14, 2020 at 8:04 PM Anatolij Gustschin wrote: > Currently I do not have an i.MX8QXP MEK board with RevB CPU and cannot > test, but I have an i.MX8QXP based custom SoM with console on ttyLP2. > Here I tested with NXP BSP kernel based on branch imx_4.14.98_2.0.0_ga > and it boots successfully (with NFS rootfs or rootfs on eMMC). I have just tested imx_4.14.98_2.0.0_ga and still get the same hang. [Adding Marcel] Just wondering if anyone else managed to boot mainline U-Boot with mainline kernel on i.MX8QXP. If so, what firmware combination was used? Thanks
[PATCH 5/5] colibri-imx8x: Remove unused function detail_board_ddr_info()
detail_board_ddr_info() is not used anywhere, so simply remove it.
This function is only used by Layerscape, not by i.MX.
This was detected by the following sparse warning:
board/toradex/colibri-imx8x/colibri-imx8x.c:104:6: warning: no previous
prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes]
Signed-off-by: Alifer Moraes
---
board/toradex/colibri-imx8x/colibri-imx8x.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/toradex/colibri-imx8x/colibri-imx8x.c
b/board/toradex/colibri-imx8x/colibri-imx8x.c
index adeee67643..f9e947eede 100644
--- a/board/toradex/colibri-imx8x/colibri-imx8x.c
+++ b/board/toradex/colibri-imx8x/colibri-imx8x.c
@@ -101,11 +101,6 @@ int board_init(void)
return 0;
}
-void detail_board_ddr_info(void)
-{
- puts("\nDDR");
-}
-
/*
* Board specific reset that is system reset.
*/
--
2.17.1
[PATCH 4/5] apalis-imx8: Remove unused function detail_board_ddr_info()
detail_board_ddr_info() is not used anywhere, so simply remove it.
This function is only used by Layerscape, not by i.MX.
This was detected by the following sparse warning:
board/toradex/apalis-imx8/apalis-imx8.c:92:6: warning: no previous
prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes]
Signed-off-by: Alifer Moraes
---
board/toradex/apalis-imx8/apalis-imx8.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/toradex/apalis-imx8/apalis-imx8.c
b/board/toradex/apalis-imx8/apalis-imx8.c
index 0483041187..a42fbb722a 100644
--- a/board/toradex/apalis-imx8/apalis-imx8.c
+++ b/board/toradex/apalis-imx8/apalis-imx8.c
@@ -89,11 +89,6 @@ int board_init(void)
return 0;
}
-void detail_board_ddr_info(void)
-{
- puts("\nDDR");
-}
-
/*
* Board specific reset that is system reset.
*/
--
2.17.1
[PATCH 1/5] imx8qm_rom7720_a1: Remove unused function detail_board_ddr_info()
detail_board_ddr_info() is not used anywhere, so simply remove it.
This function is only used by Layerscape, not by i.MX.
This was detected by the following sparse warning:
board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c:110:6: warning: no
previous
prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes]
Signed-off-by: Alifer Moraes
---
board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
index 2f97d5ce96..8bcbcc0e3f 100644
--- a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
+++ b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
@@ -107,11 +107,6 @@ int board_init(void)
return 0;
}
-void detail_board_ddr_info(void)
-{
- puts("\nDDR");
-}
-
/*
* Board specific reset that is system reset.
*/
--
2.17.1
[PATCH 3/5] imx8qxp_mek: Remove unused function detail_board_ddr_info()
detail_board_ddr_info() is not used anywhere, so simply remove it.
This function is only used by Layerscape, not by i.MX.
This was detected by the following sparse warning:
board/freescale/imx8qxp_mek/imx8qxp_mek.c:115:6: warning: no previous
prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes]
Signed-off-by: Alifer Moraes
---
board/freescale/imx8qxp_mek/imx8qxp_mek.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
index 8e731ec32e..f8dd6d0bb0 100644
--- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
+++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
@@ -113,11 +113,6 @@ int board_init(void)
return 0;
}
-void detail_board_ddr_info(void)
-{
- puts("\nDDR");
-}
-
/*
* Board specific reset that is system reset.
*/
--
2.17.1
[PATCH 2/5] imx8qm_mek: Remove unused function detail_board_ddr_info()
detail_board_ddr_info() is not used anywhere, so simply remove it.
This function is only used by Layerscape, not by i.MX.
This was detected by the following sparse warning:
board/freescale/imx8qm_mek/imx8qm_mek.c:102:6: warning: no previous
prototype for ‘detail_board_ddr_info’ [-Wmissing-prototypes]
---
board/freescale/imx8qm_mek/imx8qm_mek.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/freescale/imx8qm_mek/imx8qm_mek.c
b/board/freescale/imx8qm_mek/imx8qm_mek.c
index 667a2743a6..36d9628853 100644
--- a/board/freescale/imx8qm_mek/imx8qm_mek.c
+++ b/board/freescale/imx8qm_mek/imx8qm_mek.c
@@ -99,11 +99,6 @@ int board_init(void)
return 0;
}
-void detail_board_ddr_info(void)
-{
- puts("\nDDR");
-}
-
/*
* Board specific reset that is system reset.
*/
--
2.17.1
[PATCH] imx8qm_mek: Include fdt_support.h header
Include fdt_support.h header file to fix the following sparse warning: board/freescale/imx8qm_mek/imx8qm_mek.c:116:5: warning: no previous prototype for ‘ft_board_setup’ [-Wmissing-prototypes] Signed-off-by: Alifer Moraes --- board/freescale/imx8qm_mek/imx8qm_mek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/imx8qm_mek/imx8qm_mek.c b/board/freescale/imx8qm_mek/imx8qm_mek.c index 667a2743a6..139f416d1f 100644 --- a/board/freescale/imx8qm_mek/imx8qm_mek.c +++ b/board/freescale/imx8qm_mek/imx8qm_mek.c @@ -8,6 +8,7 @@ #include #include #include +#include #include #include #include -- 2.17.1
[PATCH] imx8qxp_mek: Include fdt_support.h header
Include fdt_support.h header file to fix the following sparse warning: board/freescale/imx8qxp_mek/imx8qxp_mek.c:129:5: warning: no previous prototype for ‘ft_board_setup’ [-Wmissing-prototypes] Signed-off-by: Alifer Moraes --- board/freescale/imx8qxp_mek/imx8qxp_mek.c | 1 + 1 file changed, 1 insertion(+) diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c b/board/freescale/imx8qxp_mek/imx8qxp_mek.c index 194eb60cd3..8e731ec32e 100644 --- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c +++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c @@ -9,6 +9,7 @@ #include #include #include +#include #include #include #include -- 2.17.1
[PATCH 2/3] arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2
Card detect line for SD-card on Odroid U3/X2 boards are active low, so
add cd-inverted property to indicate this, as u-boot's GPIO driver doesn't
support specifying line polarity. This restores S5P_SDHCI driver operation
on Odroid U3/X2 boards.
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/exynos4412-odroid.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index cc8e0dd041..e6c7222755 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -236,6 +236,7 @@
{
samsung,bus-width = <4>;
samsung,timing = <1 2 3>;
+ cd-inverted;
cd-gpios = < 2 0>;
status = "okay";
};
--
2.17.1
[PATCH 0/3] Fix Odroid U3/X2 SD-card boot
Hi All This patchset restores booting from SD-card on Exynos4412-based Odroid U3/X2 boards. It relies on the Exynos MMC device id auto-dectection and PMIC device name fixes: https://patchwork.ozlabs.org/patch/1223558/ https://patchwork.ozlabs.org/patch/1224228/ Best regards Marek Szyprowski Samsung R Institute Poland Patch summary: Marek Szyprowski (3): mmc: s5p_sdhci: Read generic MMC properties from DT arm: dts: exynos: Fix card-detect polarity for SD card on Odroid U3/X2 arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card) arch/arm/dts/exynos4412-odroid.dts | 3 ++- drivers/mmc/s5p_sdhci.c| 5 + include/configs/odroid.h | 2 +- 3 files changed, 8 insertions(+), 2 deletions(-) -- 2.17.1
[PATCH 3/3] arm: dts: exynos: Use common alias for Odroid U3/X2 MMC2 (SD-card)
Use MMC0 for eMMC and MMC2 for SD-card as other Exynos-based boards do.
This allows to use common code to get MMC device id based on the XOM[7:5]
pins.
Signed-off-by: Marek Szyprowski
---
arch/arm/dts/exynos4412-odroid.dts | 2 +-
include/configs/odroid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/exynos4412-odroid.dts
b/arch/arm/dts/exynos4412-odroid.dts
index e6c7222755..ce08e8dc1e 100644
--- a/arch/arm/dts/exynos4412-odroid.dts
+++ b/arch/arm/dts/exynos4412-odroid.dts
@@ -17,7 +17,7 @@
serial0 = "/serial@1380";
console = "/serial@1381";
mmc0 = _0;
- mmc1 =
+ mmc2 =
};
serial@1381 {
diff --git a/include/configs/odroid.h b/include/configs/odroid.h
index 77fca32fca..7989fb29d1 100644
--- a/include/configs/odroid.h
+++ b/include/configs/odroid.h
@@ -80,7 +80,7 @@
"tzsw raw 0x83f 0x138\0"
#define BOOT_TARGET_DEVICES(func) \
- func(MMC, mmc, 1) \
+ func(MMC, mmc, 2) \
func(MMC, mmc, 0)
#include
--
2.17.1
[PATCH 1/3] mmc: s5p_sdhci: Read generic MMC properties from DT
Read generic MMC properties from device-tree. This allows to specify for example cd-inverted property and let MMC core to properly handle such case. Signed-off-by: Marek Szyprowski --- drivers/mmc/s5p_sdhci.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c index 53efa968cf..b5fe828dd6 100644 --- a/drivers/mmc/s5p_sdhci.c +++ b/drivers/mmc/s5p_sdhci.c @@ -204,8 +204,13 @@ static int s5p_sdhci_probe(struct udevice *dev) if (ret) return ret; + ret = mmc_of_parse(dev, >cfg); + if (ret) + return ret; + host->mmc = >mmc; host->mmc->dev = dev; + ret = sdhci_setup_cfg(>cfg, host, 0, 40); if (ret) return ret; -- 2.17.1
Re: [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
On Thu, Jan 16, 2020 at 03:46:15PM +0100, Giulio Benetti wrote: > Hi Tom, > > +Stefano B. > > On 1/16/20 3:40 PM, Tom Rini wrote: > > On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote: > > > > > At the moment entry_point is set to image_get_load(header) that sets it > > > to "load address" instead of "entry point", assuming entry_point is > > > equal to load_addr, but it's not true. Then load_addr is set to > > > "entry_point - header_size", but this is wrong too since load_addr is > > > not an entry point. > > > > > > So use image_get_ep() for entry_point assignment and image_get_load() > > > for load_addr assignment. > > > > > > Signed-off-by: Giulio Benetti > > > > Applied to u-boot/master, thanks! > > It's been already committed by Stefano Babic in imx and you've pulled from > him. > > Sorry that I've submitted it twice! Ah, I missed git saying there was nothing to do while applying that part of the mbox. No worries. -- Tom signature.asc Description: PGP signature
Re: [U-Boot] [PATCH] spl: fix entry_point equal to load_addr
Hi Tom, +Stefano B. On 1/16/20 3:40 PM, Tom Rini wrote: On Mon, Nov 25, 2019 at 05:18:20PM +0100, Giulio Benetti wrote: At the moment entry_point is set to image_get_load(header) that sets it to "load address" instead of "entry point", assuming entry_point is equal to load_addr, but it's not true. Then load_addr is set to "entry_point - header_size", but this is wrong too since load_addr is not an entry point. So use image_get_ep() for entry_point assignment and image_get_load() for load_addr assignment. Signed-off-by: Giulio Benetti Applied to u-boot/master, thanks! It's been already committed by Stefano Babic in imx and you've pulled from him. Sorry that I've submitted it twice! Best regards -- Giulio Benetti Benetti Engineering sas
Re: [RESEND v2 07/10] mmc: add mmc and sd support for MT7622
On Fri, Jan 10, 2020 at 04:30:32PM +0800, Sam Shih wrote: > This patch add mmc and sd support for Mediatek MT7622 SoCs > > Signed-off-by: Sam Shih > Reviewed-by: Ryder Lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] MAINTAINERS: Fix mail
On Tue, Jan 14, 2020 at 07:54:12PM +0200, Sam Protsenko wrote: > Sam doesn't work for Linaro anymore, so Linaro mail is not valid. Change > it to his home mail instead. > > Signed-off-by: Sam Protsenko Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND v2 10/10] configs: mediatek: fix mt7623n bpir2 defconfig
On Fri, Jan 10, 2020 at 04:30:35PM +0800, Sam Shih wrote: > This patch add CONFIG_TARGET_MT7623 into mt7623n_bpir2_defconfig > to fix the mt7623 compile error after building others mediatek target > platform > > Signed-off-by: Sam Shih > Reviewed-by: Ryder Lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND v2 09/10] arm: dts: mediatek: move u-boot properties to -u-boot.dtsi file
On Fri, Jan 10, 2020 at 04:30:34PM +0800, Sam Shih wrote: > This patch move u-boot properties to -u-boot.dtsi file. > > Signed-off-by: Sam Shih > Reviewed-by: Ryder Lee Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND v2 06/10] power: domain: add power domain support for MT7622
On Fri, Jan 10, 2020 at 04:30:31PM +0800, Sam Shih wrote: > This patch add power domain support for Mediatek MT7622 SoCs > > Signed-off-by: Ryder Lee > Signed-off-by: Sam Shih Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND v2 08/10] Add support for MT7622 reference board
On Fri, Jan 10, 2020 at 04:30:33PM +0800, Sam Shih wrote: > This adds a general board file based on MT7622 SoCs from MediaTek. > This commit is adding the basic boot support for the MT7622 rfb. > > Signed-off-by: Sam Shih > Reviewed-by: Ryder Lee > Tested-by: Frank Wunderlich Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND v2 04/10] clk: mediatek: add driver for MT7622
On Fri, Jan 10, 2020 at 04:30:29PM +0800, Sam Shih wrote: > This patch add clock driver for MediaTek MT7622 SoC. > > Signed-off-by: Ryder Lee > Signed-off-by: Sam Shih Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
