Re: [U-Boot] [PATCH 3/4] binman: Add support for Intel reference code
On Tue, Sep 4, 2018 at 5:06 PM Bin Meng wrote: > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: > > > > Some platforms use this instead of FSP to set up the platform, including > > memory. Add support for this in binman. This is needed for > > chromebook_samus, for example. > > > > Signed-off-by: Simon Glass > > --- > > > > tools/binman/etype/intel_refcode.py | 27 +++ > > 1 file changed, 27 insertions(+) > > create mode 100644 tools/binman/etype/intel_refcode.py > > > > Reviewed-by: Bin Meng > > Although I was a bit surprised that we missed this before. applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] chromebook_samus: Increase pre-relocation memory
On Tue, Sep 4, 2018 at 5:06 PM Bin Meng wrote: > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: > > > > With bootstage now allocating pre-relocation memory the current amount > > available is insufficient. Increase it a little. > > > > Signed-off-by: Simon Glass > > --- > > > > configs/chromebook_samus_defconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Revert "x86: galileo: Fix boot failure"
Hi Simon, On Wed, Sep 26, 2018 at 1:42 PM Simon Glass wrote: > > Hi Bin, > > On 4 September 2018 at 03:07, Bin Meng wrote: > > Hi Simon, > > > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: > >> > >> The root cause of this problem should now be fixed. Renable bootstage. > >> > >> (Note, if this does not fix it, and instead a -ENOMEM error is produced, > >> then we probably need to increase CONFIG_SYS_MALLOC_F_LEN a bit). > >> > >> This reverts commit 7995dd3782f90e1939969a4ead800a5e98e2d197. > >> > >> Signed-off-by: Simon Glass > >> --- > >> > >> configs/galileo_defconfig | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > > > > I think this breaks Galileo, though I do not have a board to test right now. > > > > If you look at galileo.dts, it explicitly describes TSC frequency in > > the DT, but current TSC timer early support codes does not support > > reading TSC frequency in the DT. Maybe we need a config option for > > such hardware that can't calibrate TSC frequency? > > Yes we could. Until then perhaps we can park this patch. Thanks. Then I will apply patch 2 and 3 in this series. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Enable CONFIG_TIMER_EARLY with bootstage
Hi Simon, On Wed, Sep 26, 2018 at 1:42 PM Simon Glass wrote: > > Hi Bin, > > On 4 September 2018 at 03:06, Bin Meng wrote: > > Hi Simon, > > > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: > >> > >> In initr_bootstage() we call bootstage_mark_name() which ends up calling > >> timer_get_us(). This call happens before initr_dm(), which inits driver > >> model. > >> > >> On x86 we set gd->timer to NULL in the transition from board_init_f() > > > > It's not just x86 we set gd->timer to NULL. It applied to all > > architectures when CONFIG_TIMER is on. > > > >> to board_init_r(). See board_init_f_r() for this assignment. So U-Boot > >> knows there is no timer available in the period immediately after > >> relocation. > >> > >> On x86 the timer_get_us() call is implemented as calls to get_ticks() and > >> get_tbclk(). Both of these call dm_timer_init() to set up the timer, if > >> gd->timer is NULL and the early timer is not available. > >> > >> However dm_timer_init() cannot succeed before initr_dm() is called. > >> > >> So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable > >> CONFIG_TIMER_EARLY. Update the Kconfig to handle this. > >> > >> Note: On most architectures we can rely on the pre-relocation memory still > >> being available, so that gd->timer pointers to a valid timer device and > >> everything works correctly. Admittedly this is not strictly correct since > >> the timer device is set up by pre-relocation U-Boot, but normally this is > >> fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot > >> disappears in board_init_f_r() and any attempt to access it will hang. > >> This is the reason why we must mark the timer as invalid when we get to > >> board_init_f_r(). > >> > >> Signed-off-by: Simon Glass > >> --- > >> > >> drivers/timer/Kconfig | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig > >> index 5ab6749193c..ff434de6f7c 100644 > >> --- a/drivers/timer/Kconfig > >> +++ b/drivers/timer/Kconfig > >> @@ -30,6 +30,9 @@ config TPL_TIMER > >> config TIMER_EARLY > >> bool "Allow timer to be used early in U-Boot" > >> depends on TIMER > >> + # initr_bootstage() requires a timer and is called before > >> initr_dm() > >> + # so only the early timer is available > >> + default y if X86 && BOOTSTAGE > > > > Since this applies not only on x86, and given without TIMER_EARLY > > BOOTSTAGE is broken, shouldn't we do this in BOOTSTAGE config instead: > > > > config BOOTSTAGE > > select TIMER_EARLY > > Well we could, but I suspect that would break things since the early > timer is not supported by many boards. Also for most boards this > doesn't actually work fine. x86 is really quite awful in that it has > no SRAM and the CAR becomes inaccessible as soon as you turn on the > cache! It's true that early timer is supported by some limited boards, but that's a different issue. For now that patch does not fix anything. If we add BOOTSTAGE from either defconfig or 'menuconfig' for a board, without adding TIMER_EARLY, it will for sure break. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/4] dm: core: Scan "/firmware" node by default
Hi Simon, On 19.9.2018 12:43, Rajan Vaja wrote: > All Linux firmware drivers are put under "/firmware" node > and it has support to populate "/firmware" node by default. > > u-boot and Linux can share same DTB. In this case, driver > probe for devices under "/firmware" will not be invoked > as "/firmware" does not have its own "compatible" property. > > This patch series scans "/firmware" node by default like "/clocks". > To avoid duplication of code, first patch moves, node scan code > into separate function. > > This series also test to make sure "/firmware" nodes are scanned > properly. > > Rajan Vaja (4): > firmware: Add FIRMWARE config prompt string > dm: core: Move "/clock" node scan into function > dm: core: Scan "/firmware" node by default > dm: test: Add "/firmware" node scan test > > arch/sandbox/dts/test.dts | 7 +++ > drivers/core/root.c | 35 ++- > drivers/firmware/Kconfig| 2 +- > drivers/firmware/Makefile | 1 + > drivers/firmware/firmware-sandbox.c | 20 > test/dm/Makefile| 1 + > test/dm/firmware.c | 22 ++ > 7 files changed, 74 insertions(+), 14 deletions(-) > create mode 100644 drivers/firmware/firmware-sandbox.c > create mode 100644 test/dm/firmware.c > Can you please take it via your tree? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] efi patch queue 2018-09-23
Alex, On Sun, Sep 23, 2018 at 10:03:18PM +0200, Alexander Graf wrote: > Hi Tom, > > This is my current patch queue for efi. Please pull. > > Alex > > > The following changes since commit 9dc8d155d4e88563f572ee79aab758eb4272f3fd: > > Merge git://git.denx.de/u-boot-imx (2018-09-19 20:35:27 -0400) > > are available in the git repository at: > > git://github.com/agraf/u-boot.git tags/signed-efi-next > > for you to fetch changes up to c982874e930d5d673501cd94df07bcbd215d5883: > > efi_loader: refactor efi_setup_loaded_image() (2018-09-23 21:55:31 +0200) > > > Patch queue for efi - 2018-09-23 > > A lot of goodness in this release. We're *very* close to running the > UEFI Shell and SCT natively. The only missing piece are HII protocols. > > - FAT write support (needed for SCT) > - improved FAT directory support (needed for SCT) I have some updates here: * add a comment to each helper function in test_fs/conftest.py after Simon's comment * remove fs_type parameter from umount_fs() as it's not used at all. None of those changes doesn't affect the functionality. Should I submit the whole patch set with them as v4, or just post a separate patch(diff) on top of the v3? Sorry for this inconvenience. -Takahiro Akashi > - RTC support with QEMU -M virt > - Sandbox support (run UEFI binaries in Linux - yay) > - Proper UTF-16 support > - EFI_UNICODE_COLLATION_PROTOCOL support (for UEFI Shell) > - EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL support (for UEFI Shell) > - Fix window size determination > - Fix Tegra by explicitly unmapping RAM > - Clean up handle entanglement > - Lots of generic code cleanup > > > AKASHI Takahiro (26): > fs: fat: extend get_fs_info() for write use > fs: fat: handle "." and ".." of root dir correctly with > fat_itr_resolve() > fs: fat: assure iterator's ->dent belongs to ->clust > Revert "fs: fat: cannot write to subdirectories" > fs: fat: check and normalize file name > fs: fat: write returns error code instead of -1 > fs: fat: support write with sub-directory path > fs: fat: refactor write interface for a file offset > fs: fat: support write with non-zero offset > cmd: fat: add offset parameter to fatwrite > fs: add mkdir interface > fs: fat: remember the starting cluster number of directory > fs: fat: support mkdir > cmd: fat: add fatmkdir command > efi_loader: file: support creating a directory > fs: add unlink interface > fs: fat: support unlink > cmd: fat: add fatrm command > efi_loader: implement a file delete > fs-test: fix false positive error at Test Case 12 > fs-test: update the test result as of v2018.09 > test/py: convert fs-test.sh to pytest > test/py: fs: add extended write operation test > test/py: fs: add fstest/mkdir test > rtc: pl031: convert the driver to driver model > arm: qemu-arm: enable RTC (PL031) by default > > Akashi, Takahiro (1): > test/py: fs: add fstest/unlink test > > Alexander Graf (7): > efi_loader: Pass address to fs_read() > efi_loader: Add console handle references to in/out/err > sandbox: Fix setjmp/longjmp > sandbox: Allow to execute from RAM > efi_loader: Merge memory map entries > efi_loader: Disable efi selftest on sandbox for now > efi_loader: Fix loaded_image handle passing from EL3 > > Heinrich Schuchardt (62): > efi_selftest: memory leak testing manage protocols > efi_loader: pass system table in loaded image protocol > efi_selftest: test for loaded image protocol > vsprintf.c: use #if CONFIG_IS_ENABLED(EFI_LOADER) > test: print_ut.c use #if CONFIG_IS_ENABLED(EFI_LOADER) > lib: build charset.o only if needed > efi_loader: rename utf16_strlen, utf16_strnlen > lib: charset: utility functions for Unicode > test: unit tests for Unicode functions > lib: vsprintf: correct printing of Unicode strings > test: test printing Unicode > efi_loader: remove limit on variable length > efi_loader: don't use unlimited stack as buffer > efi_loader: buffer size for load options > lib: charset: remove obsolete functions > efi_loader: fix typos in efi_boottime.c > efi_loader: fix typos in efi_runtime.c > efi_loader: description efi_update_capsule() > efi_loader: use correct documentation style > efi_loader: capitalization table > lib: charset: upper/lower case conversion > test: tests for utf_to_lower() utf_to_upper(). > efi_loader: EFI_UNICODE_COLLATION_PROTOCOL > efi_selftest: EFI_UNICODE_COLLATION_PROTOCOL > test/py: test EFI_SIMPLE_TEXT_INPUT_PROTOCOL > test/py: typo occured > efi_loader: struct efi_simple_text_input_protocol > efi_
Re: [U-Boot] [BUG] U-Boot generates unusable x86_64 EFI binaries
Hi Heinrich, On Tue, Sep 25, 2018 at 3:40 AM Heinrich Schuchardt wrote: > > Hello > > neither the helloworld.efi of qemu-x86_64_defconfig nor the > u-boot-payload.efi of efi-x86_payload64_defconfig can be started from > the firmware of my Thinkpad 585 while grubx64.efi works fine. > > Looking at the generated PE header I found the following abnormality: > > coff.PointerToSymbolTable != 0 > coff.NumberOfSymbols != 0 > > (using https://github.com/xypron/efi_analyzer) > > According to the Microsoft Portable Executable and Common Object File > Format Specification - rev 11 - 2017-01-17 these fields should be 0. > > The U-Boot executables have these sections which do not exist in > grubx64.efi, the EFI shell, and the Windows loader: > > Section[3] .dynamic > Section[4] .dynsym > > So I think we have to change something in the linking to get usable EFI > binaries. Can you please try http://patchwork.ozlabs.org/project/uboot/list/?series=67541 and let me know if that solves your problem? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-lsch3: soc: Enable AHB support flexspi controller
Hello York,
> -Original Message-
> From: York Sun
> Sent: Tuesday, September 25, 2018 10:20 PM
> To: Ashish Kumar ; u-boot@lists.denx.de
> Cc: Rajat Srivastava ; Yogesh Narayan Gaur
>
> Subject: Re: [PATCH] fsl-lsch3: soc: Enable AHB support flexspi controller
>
> On 09/25/2018 01:44 AM, Ashish Kumar wrote:
> > Enable AHB support for flexspi controller interface meaning memory can
> > be accessed via md command using absolute addresses
> >
> > Signed-off-by: Yogesh Gaur
> > Signed-off-by: Rajat Srivastava
> > Signed-off-by: Ashish Kumar
> > ---
> > arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 ++
> > arch/arm/cpu/armv8/fsl-layerscape/soc.c | 42 +++
> > 2 files changed, 52 insertions(+)
> >
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > index 5280d33ec8..8d66783b7c 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> > @@ -327,6 +327,16 @@ config SYS_FSPI_AHB_INIT
> > performed. Default LUT programmed in AHB mode is Fast Read
> command
> > with 4-byte addressing enabled.
> >
> > +config FSPI_AHB_EN_4BYTE
> > + bool "Enable 4-byte Fast Read cmd for AHB mode"
>
> s/cmd/command
While take care in v2
>
> > + depends on NXP_FSPI
> > + default n
> > + help
> > + The default setting for FSPI AHB bus just supports 3-byte addressing.
> > + But some FSPI flash sizes are up to 64MBytes.
> > + This flag enables fast read cmd for AHB mode and modifies required
> > + LUT to support full FSPI flash.
> > +
>
> It is FlexSPI, not FSPI, nor flexspi. Please use consistent term for FlexSPI
> in
> subject, commit message, document and comment. If you have to use FSPI in
> macro names, make sure it it has clear meaning.
In description and comment it will be replaced by FlexSPI, but in
macro/config/variables names can I use FSPI and fspi ?
>
> > config SYS_CCI400_OFFSET
> > hex "Offset for CCI400 base"
> > depends on SYS_FSL_HAS_CCI400
> > diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > index 3f15cb08ff..60beb0dc96 100644
> > --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> > @@ -640,6 +640,45 @@ void fsl_lsch2_early_init_f(void) } #endif
> >
> > +#ifdef CONFIG_FSPI_AHB_EN_4BYTE
> > +int fspi_ahb_init(void)
> > +{
> > + /* Enable 4bytes address support and fast read */
> > + u32 *fspi_lut, lut_key, *fspi_key;
> > +
> > + fspi_key = (void *)SYS_FSL_FSPI_ADDR + 0x18;
> > + fspi_lut = (void *)SYS_FSL_FSPI_ADDR + 0x200;
> > +
> > + lut_key = in_be32(fspi_key);
> > +
> > + if (lut_key == 0x5af05af0) {
> > + /* That means the register is BE */
> > + out_be32(fspi_key, 0x5af05af0);
> > + /* Unlock the lut table */
> > + out_be32(fspi_key + 1, 0x0002);
> > + out_be32(fspi_lut, 0x0820040c);
> > + out_be32(fspi_lut + 1, 0x24003008);
> > + out_be32(fspi_lut + 2, 0x);
> > + /* Lock the lut table */
> > + out_be32(fspi_key, 0x5af05af0);
> > + out_be32(fspi_key + 1, 0x0001);
> > + } else {
> > + /* That means the register is LE */
> > + out_le32(fspi_key, 0x5af05af0);
> > + /* Unlock the lut table */
> > + out_le32(fspi_key + 1, 0x0002);
> > + out_le32(fspi_lut, 0x0820040c);
> > + out_le32(fspi_lut + 1, 0x24003008);
> > + out_le32(fspi_lut + 2, 0x);
> > + /* Lock the lut table */
> > + out_le32(fspi_key, 0x5af05af0);
> > + out_le32(fspi_key + 1, 0x0001);
>
> Is there anyway you can make the magic numbers more meaningful?
How about adding comments above each magic number, explaining meaning?
Regards
Ashish
>
> York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] x86: efi: app: Generate Microsoft PE format complaint image
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently U-Boot is generating u-boot-app.efi in which these two members are not zero. This updates the build rules to tell linker to remove the symbol table completely so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Signed-off-by: Bin Meng --- arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 483ff95..0e50e18 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -65,7 +65,7 @@ CPPFLAGS_crt0-efi-$(EFIARCH).o += $(CFLAGS_EFI) ifeq ($(CONFIG_EFI_APP),y) PLATFORM_CPPFLAGS += $(CFLAGS_EFI) -LDFLAGS_FINAL += -znocombreloc -shared +LDFLAGS_FINAL += -znocombreloc -shared -s LDSCRIPT := $(LDSCRIPT_EFI) else -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] arm: efi: Generate Microsoft PE format complaint images
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently the COFF file header is hardcoded on ARM and these two members are not zero. This updates the hardcoded structure to clear these two members, as well as setting the flag IMAGE_FILE_LOCAL_SYMS_STRIPPED so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Signed-off-by: Bin Meng --- arch/arm/lib/crt0_aarch64_efi.S | 7 --- arch/arm/lib/crt0_arm_efi.S | 6 +++--- 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/arm/lib/crt0_aarch64_efi.S b/arch/arm/lib/crt0_aarch64_efi.S index 0db4360..a489d05 100644 --- a/arch/arm/lib/crt0_aarch64_efi.S +++ b/arch/arm/lib/crt0_aarch64_efi.S @@ -28,13 +28,14 @@ coff_header: .short 2 /* nr_sections */ .long 0 /* TimeDateStamp */ .long 0 /* PointerToSymbolTable */ - .long 1 /* NumberOfSymbols */ + .long 0 /* NumberOfSymbols */ .short section_table - optional_header /* SizeOfOptionalHeader */ /* * Characteristics: IMAGE_FILE_DEBUG_STRIPPED | -* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED +* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED | +* IMAGE_FILE_LOCAL_SYMS_STRIPPED */ - .short 0x206 + .short 0x20e optional_header: .short 0x20b /* PE32+ format */ .byte 0x02/* MajorLinkerVersion */ diff --git a/arch/arm/lib/crt0_arm_efi.S b/arch/arm/lib/crt0_arm_efi.S index 23db49f..5330578 100644 --- a/arch/arm/lib/crt0_arm_efi.S +++ b/arch/arm/lib/crt0_arm_efi.S @@ -27,14 +27,14 @@ coff_header: .short 2 /* nr_sections */ .long 0 /* TimeDateStamp */ .long 0 /* PointerToSymbolTable */ - .long 1 /* NumberOfSymbols */ + .long 0 /* NumberOfSymbols */ .short section_table - optional_header /* SizeOfOptionalHeader */ /* * Characteristics: IMAGE_FILE_32BIT_MACHINE | * IMAGE_FILE_DEBUG_STRIPPED | IMAGE_FILE_EXECUTABLE_IMAGE | -* IMAGE_FILE_LINE_NUMS_STRIPPED +* IMAGE_FILE_LINE_NUMS_STRIPPED | IMAGE_FILE_LOCAL_SYMS_STRIPPED */ - .short 0x306 + .short 0x30e optional_header: .short 0x10b /* PE32+ format */ .byte 0x02/* MajorLinkerVersion */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] riscv: efi: Generate Microsoft PE format complaint images
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently the COFF file header is hardcoded on RISC-V and these two members are not zero. This updates the hardcoded structure to clear these two members, as well as setting the flag IMAGE_FILE_LOCAL_SYMS_STRIPPED so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Signed-off-by: Bin Meng --- arch/riscv/lib/crt0_riscv_efi.S | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/riscv/lib/crt0_riscv_efi.S b/arch/riscv/lib/crt0_riscv_efi.S index 18f61f5..6d61b3a 100644 --- a/arch/riscv/lib/crt0_riscv_efi.S +++ b/arch/riscv/lib/crt0_riscv_efi.S @@ -41,13 +41,14 @@ coff_header: .short 2 /* nr_sections */ .long 0 /* TimeDateStamp */ .long 0 /* PointerToSymbolTable */ - .long 1 /* NumberOfSymbols */ + .long 0 /* NumberOfSymbols */ .short section_table - optional_header /* SizeOfOptionalHeader */ /* * Characteristics: IMAGE_FILE_DEBUG_STRIPPED | -* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED +* IMAGE_FILE_EXECUTABLE_IMAGE | IMAGE_FILE_LINE_NUMS_STRIPPED | +* IMAGE_FILE_LOCAL_SYMS_STRIPPED */ - .short 0x206 + .short 0x20e optional_header: .short 0x20b /* PE32+ format */ .byte 0x02/* MajorLinkerVersion */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] x86: efi: payload: Generate Microsoft PE format complaint image
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently U-Boot is generating u-boot-payload.efi image in which these two members are not zero. This updates the build rules to tell linker to remove the symbol table completely so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Reported-by: Heinrich Schuchardt Signed-off-by: Bin Meng --- arch/x86/config.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 5b04feb..483ff95 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -34,7 +34,7 @@ PLATFORM_LDFLAGS += -m $(if $(IS_32BIT),elf_i386,elf_x86_64) # This is used in the top-level Makefile which does not include # PLATFORM_LDFLAGS -LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared --no-undefined +LDFLAGS_EFI_PAYLOAD := -Bsymbolic -Bsymbolic-functions -shared --no-undefined -s OBJCOPYFLAGS_EFI := -j .text -j .sdata -j .data -j .dynamic -j .dynsym \ -j .rel -j .rela -j .reloc -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] efi_loader: Generate Microsoft PE format complaint images
Per Microsoft PE Format documentation [1], PointerToSymbolTable and NumberOfSymbols should be zero for an image in the COFF file header. Currently U-Boot is generating *.efi images (eg: helloworld.efi) in which these two members are not zero. This updates the build rules to tell linker to remove the symbol table completely so that we can generate compliant *.efi images. [1] https://docs.microsoft.com/zh-cn/windows/desktop/Debug/pe-format Reported-by: Heinrich Schuchardt Signed-off-by: Bin Meng --- scripts/Makefile.lib | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index f8c3fff..91f0b20 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -381,7 +381,7 @@ $(obj)/%.efi: $(obj)/%_efi.so quiet_cmd_efi_ld = LD $@ cmd_efi_ld = $(LD) -nostdlib -znocombreloc -T $(EFI_LDS_PATH) -shared \ - -Bsymbolic $^ -o $@ + -Bsymbolic -s $^ -o $@ EFI_LDS_PATH = $(srctree)/arch/$(ARCH)/lib/$(EFI_LDS) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/7] m68k: add stmark2 fdt support
On 20 September 2018 at 15:07, Angelo Dureghello wrote: > This patch adds stmark2 board fdt support to the m68k arch. > > Signed-off-by: Angelo Dureghello > --- > arch/m68k/dts/Makefile| 12 > arch/m68k/dts/stmark2.dts | 34 ++ > 2 files changed, 46 insertions(+) > create mode 100644 arch/m68k/dts/Makefile > create mode 100644 arch/m68k/dts/stmark2.dts Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] armv7: ls102xa: Disable QE before enter deep sleep
Otherwise system will hang after executing wfi.
Signed-off-by: Ran Wang
---
Change in v3:
Actually this is the same to 3/3 patch of v2
Change in v2:
None
arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c | 4
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
index af413f8622..bb169aaaf4 100644
--- a/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
+++ b/arch/arm/cpu/armv7/ls102xa/ls102xa_psci.c
@@ -73,6 +73,7 @@ static void __secure ls1_deepsleep_irq_cfg(void)
* read, that is why we don't read it from register ippdexpcr1 itself.
*/
ippdexpcr1 = in_le32(&scfg->sparecr[7]);
+ out_be32(&rcpm->ippdexpcr1, ippdexpcr1);
if (ippdexpcr0 & RCPM_IPPDEXPCR0_ETSEC)
pmcintecr |= SCFG_PMCINTECR_ETSECRXG0 |
@@ -192,6 +193,9 @@ static void __secure ls1_deep_sleep(u32 entry_point)
setbits_be32(&scfg->dpslpcr, SCFG_DPSLPCR_WDRR_EN);
setbits_be32(&gur->crstsr, DCFG_CRSTSR_WDRFR);
+ /* Disable QE */
+ setbits_be32(&gur->devdisr, CCSR_DEVDISR1_QE);
+
ls1_deepsleep_irq_cfg();
psci_v7_flush_dcache_all();
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index 13a282ffe1..a3d1171aa9 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -86,6 +86,8 @@ struct sys_info {
unsigned long freq_localbus;
};
+#define CCSR_DEVDISR1_QE 0x0001
+
/* Device Configuration and Pin Control */
struct ccsr_gur {
u32 porsr1; /* POR status 1 */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] qe: Kconfig: Move CONFIG_U_QE to Kconfig
This patch moves CONFIG_U_QE to Kconfig Signed-off-by: Ran Wang --- Change in v3: - Combine 1/3 and 2/3 patch of v2 - Remove unnecessary space in front of U-QE in drivers/qe/Kconfig - Remove CONFIG_U_QE in scripts/config_whitelist.txt Change in v2: Add more conditional define to support more platforms. drivers/Kconfig | 2 ++ drivers/qe/Kconfig | 12 include/configs/T102xQDS.h | 1 - include/configs/T102xRDB.h | 1 - include/configs/T1040QDS.h | 1 - include/configs/ls1021aqds.h | 1 - include/configs/ls1021atwr.h | 1 - include/configs/ls1043ardb.h | 7 --- scripts/config_whitelist.txt | 1 - 9 files changed, 14 insertions(+), 13 deletions(-) create mode 100644 drivers/qe/Kconfig diff --git a/drivers/Kconfig b/drivers/Kconfig index 56536c4b19..884a945a19 100644 --- a/drivers/Kconfig +++ b/drivers/Kconfig @@ -74,6 +74,8 @@ source "drivers/power/Kconfig" source "drivers/pwm/Kconfig" +source "drivers/qe/Kconfig" + source "drivers/ram/Kconfig" source "drivers/remoteproc/Kconfig" diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig new file mode 100644 index 00..49a6e32b16 --- /dev/null +++ b/drivers/qe/Kconfig @@ -0,0 +1,12 @@ +# +# QUICC Engine Drivers +# +config U_QE + bool "Enable support for U QUICC Engine" + default y if (ARCH_LS1021A && !SD_BOOT && !NAND_BOOT && !QSPI_BOOT) \ + || (TARGET_T1024QDS) \ + || (TARGET_T1024RDB) \ + || (TARGET_T1040QDS && !NOBQFMAN) \ + || (TARGET_LS1043ARDB && !SPL_NO_QE && !NAND_BOOT && !QSPI_BOOT) + help + Choose this option to add support for U QUICC Engine. diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h index 8a38c5e19c..191616b8b0 100644 --- a/include/configs/T102xQDS.h +++ b/include/configs/T102xQDS.h @@ -659,7 +659,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_DPAA_FMAN #define CONFIG_QE -#define CONFIG_U_QE /* Default address of microcode for the Linux FMan driver */ #if defined(CONFIG_SPIFLASH) /* diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h index f7a54f7a97..ac5de8d164 100644 --- a/include/configs/T102xRDB.h +++ b/include/configs/T102xRDB.h @@ -669,7 +669,6 @@ unsigned long get_board_ddr_clk(void); #ifdef CONFIG_TARGET_T1024RDB #define CONFIG_QE -#define CONFIG_U_QE #endif /* Default address of microcode for the Linux FMan driver */ #if defined(CONFIG_SPIFLASH) diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index e890860b7e..25615be40e 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -549,7 +549,6 @@ unsigned long get_board_ddr_clk(void); #define CONFIG_SYS_DPAA_PME #define CONFIG_QE -#define CONFIG_U_QE /* Default address of microcode for the Linux Fman driver */ #if defined(CONFIG_SPIFLASH) /* diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h index 994e6ca362..7f7ffdede1 100644 --- a/include/configs/ls1021aqds.h +++ b/include/configs/ls1021aqds.h @@ -107,7 +107,6 @@ unsigned long get_board_ddr_clk(void); #if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_NAND_BOOT) && \ !defined(CONFIG_QSPI_BOOT) -#define CONFIG_U_QE #define CONFIG_SYS_QE_FMAN_FW_IN_NOR #endif diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h index 75b2e2fbbd..ddd024e8c0 100644 --- a/include/configs/ls1021atwr.h +++ b/include/configs/ls1021atwr.h @@ -106,7 +106,6 @@ #if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_NAND_BOOT) && \ !defined(CONFIG_QSPI_BOOT) -#define CONFIG_U_QE #define CONFIG_SYS_QE_FMAN_FW_IN_NOR #endif diff --git a/include/configs/ls1043ardb.h b/include/configs/ls1043ardb.h index bc639e586f..ffd92dbb43 100644 --- a/include/configs/ls1043ardb.h +++ b/include/configs/ls1043ardb.h @@ -268,13 +268,6 @@ #endif #endif -/* QE */ -#ifndef SPL_NO_QE -#if !defined(CONFIG_NAND_BOOT) && !defined(CONFIG_QSPI_BOOT) -#define CONFIG_U_QE -#endif -#endif - /* SATA */ #ifndef SPL_NO_SATA #ifndef CONFIG_CMD_EXT2 diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 94953d8738..cf97b64296 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -4635,7 +4635,6 @@ CONFIG_USE_SPIFLASH CONFIG_UTBIPAR_INIT_TBIPA CONFIG_U_BOOT_HDR_ADDR CONFIG_U_BOOT_HDR_SIZE -CONFIG_U_QE CONFIG_VAL CONFIG_VAR_SIZE_SPL CONFIG_VCT_NOR -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] drivers: serial: mcfuart: add DT support
On 20 September 2018 at 15:07, Angelo Dureghello wrote: > This patch adds devicetree support to the mcfuart.c driver. > > Signed-off-by: Angelo Dureghello > --- > drivers/serial/mcfuart.c | 28 > 1 file changed, 28 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] pci: Check ops before using them for config space access
Hi Marek, On 21 September 2018 at 16:59, Marek Vasut wrote: > The code fails to check if ops is non-NULL before using it's members. > Add the missing check and while at it, flip the condition to make it > more obvious what is actually happening. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > --- > drivers/pci/pci-uclass.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index eb118f3496..de523a76ad 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -241,9 +241,9 @@ int pci_bus_write_config(struct udevice *bus, pci_dev_t > bdf, int offset, > struct dm_pci_ops *ops; > > ops = pci_get_ops(bus); > - if (!ops->write_config) > - return -ENOSYS; > - return ops->write_config(bus, bdf, offset, value, size); > + if (ops && ops->write_config) > + return ops->write_config(bus, bdf, offset, value, size); I'd like to avoid this if possible, since it bloats code. If you don't provide operations you are on your own! Ideas: - add it behind DEBUG - check it once in the uclass when binding - e.g. in uclass_add() - and print a warning? I have pushed back pretty hard against people adding checks for things which should not be true in normal systems. Partly it is just for the confusion it adds, partly for efficiency. Perhaps we should document the pre-conditions that DM guarantees somewhere? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] drivers: spi: cf_spi: migrate to DM and DT
Hi Angelo,
On 20 September 2018 at 15:07, Angelo Dureghello wrote:
> This patch converts cf_spi.c to DM and to read driver
> platform data from flat devicetree.
>
> ---
> Changes from v1:
> - split into 2 patches
>
> Signed-off-by: Angelo Dureghello
> ---
> drivers/spi/Kconfig | 18 +-
> drivers/spi/cf_spi.c| 495
> include/dm/platform_data/spi_coldfire.h | 25 ++
> 3 files changed, 369 insertions(+), 169 deletions(-)
> create mode 100644 include/dm/platform_data/spi_coldfire.h
>
Good to see this.
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index dcd719ff0a..974c5bbed8 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -80,6 +80,12 @@ config CADENCE_QSPI
> used to access the SPI NOR flash on platforms embedding this
> Cadence IP core.
>
> +config CF_SPI
> +bool "ColdFire SPI driver"
> +help
> + Enable the ColdFire SPI driver. This driver can be used on
> + some m68k SoCs.
> +
> config DESIGNWARE_SPI
> bool "Designware SPI driver"
> help
> @@ -244,18 +250,18 @@ config ZYNQMP_GQSPI
>
> endif # if DM_SPI
>
> -config SOFT_SPI
> - bool "Soft SPI driver"
> - help
> -Enable Soft SPI driver. This driver is to use GPIO simulate
> -the SPI protocol.
How come this is changing? That should be a separate patch.
> -
> config CF_SPI
> bool "ColdFire SPI driver"
> help
> Enable the ColdFire SPI driver. This driver can be used on
> some m68k SoCs.
>
> +config SOFT_SPI
> + bool "Soft SPI driver"
> + help
> +Enable Soft SPI driver. This driver is to use GPIO simulate
> +the SPI protocol.
> +
> config FSL_ESPI
> bool "Freescale eSPI driver"
> help
> diff --git a/drivers/spi/cf_spi.c b/drivers/spi/cf_spi.c
> index 522631cbbf..11a11f79c4 100644
> --- a/drivers/spi/cf_spi.c
> +++ b/drivers/spi/cf_spi.c
> @@ -6,16 +6,27 @@
> *
> * Copyright (C) 2004-2009 Freescale Semiconductor, Inc.
> * TsiChung Liew (tsi-chung.l...@freescale.com)
> + *
> + * Support for device model:
> + * Copyright (C) 2018 Angelo Dureghello
> + *
> */
>
> #include
> +#include
> +#include
> #include
> #include
> #include
> +#include
>
> -struct cf_spi_slave {
> +struct coldfire_spi_priv {
> +#ifndef CONFIG_DM_SPI
> struct spi_slave slave;
> +#endif
> + struct dspi *regs;
> uint baudrate;
> + int mode;
> int charbit;
> };
>
> @@ -38,14 +49,14 @@ DECLARE_GLOBAL_DATA_PTR;
> #define SPI_MODE_MOD 0x0020
> #define SPI_DBLRATE0x0010
>
> -static inline struct cf_spi_slave *to_cf_spi_slave(struct spi_slave *slave)
> -{
> - return container_of(slave, struct cf_spi_slave, slave);
> -}
> +/* Default values */
> +#define MCF_DSPI_DEFAULT_SCK_FREQ 1000
> +#define MCF_DSPI_MAX_CHIPSELECTS 4
> +#define MCF_DSPI_MODE 0
>
> -static void cfspi_init(void)
> +static void __spi_init(struct coldfire_spi_priv *cfspi)
> {
> - volatile dspi_t *dspi = (dspi_t *) MMAP_DSPI;
> + struct dspi *dspi = cfspi->regs;
>
> cfspi_port_conf(); /* port configuration */
>
> @@ -56,125 +67,32 @@ static void cfspi_init(void)
>
> /* Default setting in platform configuration */
> #ifdef CONFIG_SYS_DSPI_CTAR0
> - dspi->ctar[0] = CONFIG_SYS_DSPI_CTAR0;
> + writel(CONFIG_SYS_DSPI_CTAR0, &dspi->ctar[0]);
What is going on here? I think these CONFIG options are addresses? If
so, they should be read from the DT, not a CONFIG.
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR1
> - dspi->ctar[1] = CONFIG_SYS_DSPI_CTAR1;
> + writel(CONFIG_SYS_DSPI_CTAR1, &dspi->ctar[1]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR2
> - dspi->ctar[2] = CONFIG_SYS_DSPI_CTAR2;
> + writel(CONFIG_SYS_DSPI_CTAR2, &dspi->ctar[2]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR3
> - dspi->ctar[3] = CONFIG_SYS_DSPI_CTAR3;
> + writel(CONFIG_SYS_DSPI_CTAR3, &dspi->ctar[3]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR4
> - dspi->ctar[4] = CONFIG_SYS_DSPI_CTAR4;
> + writel(CONFIG_SYS_DSPI_CTAR4, &dspi->ctar[4]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR5
> - dspi->ctar[5] = CONFIG_SYS_DSPI_CTAR5;
> + writel(CONFIG_SYS_DSPI_CTAR5, &dspi->ctar[5]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR6
> - dspi->ctar[6] = CONFIG_SYS_DSPI_CTAR6;
> + writel(CONFIG_SYS_DSPI_CTAR6, &dspi->ctar[6]);
> #endif
> #ifdef CONFIG_SYS_DSPI_CTAR7
> - dspi->ctar[7] = CONFIG_SYS_DSPI_CTAR7;
> + writel(CONFIG_SYS_DSPI_CTAR7, &dspi->ctar[7]);
> #endif
> }
>
[..]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] m68k: architecture changes to support fdt
On 20 September 2018 at 15:07, Angelo Dureghello wrote: > This patch adds ftd support to the m68k architecture. > > Signed-off-by: Angelo Dureghello > --- > arch/Kconfig | 1 + > arch/m68k/Kconfig| 2 ++ > arch/m68k/cpu/u-boot.lds | 2 ++ > 3 files changed, 5 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/2] pci: Support parsing PCI controller DT subnodes
Hi Marek, On 20 September 2018 at 17:56, Marek Vasut wrote: > On 09/20/2018 03:47 AM, Bin Meng wrote: > [...] > I suspect the best answer is to move the emulator so it is a direct child of the bus. You would need to update sandbox_pci_get_emul() to call device_find_first_child() on 'bus' instead of 'dev'. >>> >>> Sounds to me _way_ out of scope for this patchset. >> >> Dynamic binding is already supported on Sandbox. I guess Simon may >> have missed the part. > > Well, where is an example of that ? Because I am not seeing one. > I already pointed out in the previous email. In arch/sandbox/dts/test.dts, the 2nd PCI controller has two swap_case devices and the 3rd controller has one. >>> >>> By "second" you mean pci1: or pci2: ? Because pci1: is second , after >>> pci0 . It'd really help if you were clearer in what you refer to. >>> >> >> It's pci1. You can see there is no subnode under pci1 there yet if you >> type 'pci 1' from the U-Boot shell you see two PCI devices. > > I'd really appreciate it if you could be more precise when referring to > things. > In swap_case.c, U_BOOT_PCI_DEVICE() is there which is also a clear sign that the driver supports dynamic binding. Of course, the driver supports "compatible" too as you noticed. >>> >>> Are you talking about sandbox,dev-info DT property here ? >> >> This is the property Sandbox uses to make the dynamic binding work. >> You can bypass this. > > Why would I want to bypass this ? > >> The key here is that swap_case driver supports >> both "compatible" and dynamic binding, so you can write test cases to >> cover this newly added ofnode scenario. > > That's great, and after spending even more time on this (probably days > by now), I just keep finding more and more limitations of the virtual > PCI subsystem which makes writing this testcase really hard. And none of > that really helps fixing the real problem on my real hardware, which > really stays broken. You could fix that with a 5-minute patch to add a compatible string :-) The problem is that you want to do it a certain way. Yes the test system has limitations but it is better than what we had before (no tests). We should expand its capability as we add new functionality. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4] firmware: Add FIRMWARE config prompt string
On 19 September 2018 at 04:43, Rajan Vaja wrote: > There is no prompt string for FIRMWARE config. Without this, > FIRMWARE config cannot be enabled through menuconfing or > config file. Fix this by adding prompt summary. > > Signed-off-by: Rajan Vaja > --- > Changes in v2: > * New patch > --- > drivers/firmware/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] arm: dts: rockchip: add some common pin-settings to rk3399
On 19 September 2018 at 16:58, Manivannan Sadhasivam
wrote:
> From: Randy Li
>
> Those pins would be used by many boards.
>
> Commit grabbed from Linux:
>
> commit b41023282d07b61a53e2c9b9508912b1e7ce7b4f
> Author: Randy Li
> Date: Thu Jun 21 21:32:10 2018 +0800
>
> arm64: dts: rockchip: add some common pin-settings to rk3399
>
> Those pins would be used by many boards.
>
> Signed-off-by: Randy Li
> Signed-off-by: Heiko Stuebner
>
> Acked-by: Philipp Tomsich
> Signed-off-by: Randy Li
> Signed-off-by: Heiko Stuebner
> Signed-off-by: Ezequiel Garcia
> ---
> arch/arm/dts/rk3399.dtsi | 55 +++-
> 1 file changed, 49 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399.dtsi b/arch/arm/dts/rk3399.dtsi
> index 83c257b1228..8349451b03d 100644
> --- a/arch/arm/dts/rk3399.dtsi
> +++ b/arch/arm/dts/rk3399.dtsi
> @@ -1602,19 +1602,49 @@
> drive-strength = <12>;
> };
>
> + pcfg_pull_none_13ma: pcfg-pull-none-13ma {
> + bias-disable;
> + drive-strength = <13>;
> + };
> +
> + pcfg_pull_none_18ma: pcfg-pull-none-18ma {
> + bias-disable;
> + drive-strength = <18>;
> + };
> +
> + pcfg_pull_none_20ma: pcfg-pull-none-20ma {
> + bias-disable;
> + drive-strength = <20>;
> + };
> +
> + pcfg_pull_up_2ma: pcfg-pull-up-2ma {
> + bias-pull-up;
> + drive-strength = <2>;
> + };
> +
> pcfg_pull_up_8ma: pcfg-pull-up-8ma {
> bias-pull-up;
> drive-strength = <8>;
> };
>
> + pcfg_pull_up_18ma: pcfg-pull-up-18ma {
> + bias-pull-up;
> + drive-strength = <18>;
> + };
> +
> + pcfg_pull_up_20ma: pcfg-pull-up-20ma {
> + bias-pull-up;
> + drive-strength = <20>;
> + };
> +
> pcfg_pull_down_4ma: pcfg-pull-down-4ma {
> bias-pull-down;
> drive-strength = <4>;
> };
>
> - pcfg_pull_up_2ma: pcfg-pull-up-2ma {
> - bias-pull-up;
> - drive-strength = <2>;
> + pcfg_pull_down_8ma: pcfg-pull-down-8ma {
> + bias-pull-down;
> + drive-strength = <8>;
> };
>
> pcfg_pull_down_12ma: pcfg-pull-down-12ma {
> @@ -1622,9 +1652,22 @@
> drive-strength = <12>;
> };
>
> - pcfg_pull_none_13ma: pcfg-pull-none-13ma {
> - bias-disable;
> - drive-strength = <13>;
> + pcfg_pull_down_18ma: pcfg-pull-down-18ma {
> + bias-pull-down;
> + drive-strength = <18>;
> + };
> +
> + pcfg_pull_down_20ma: pcfg-pull-down-20ma {
> + bias-pull-down;
> + drive-strength = <20>;
> + };
> +
> + pcfg_output_high: pcfg-output-high {
> + output-high;
> + };
> +
> + pcfg_output_low: pcfg-output-low {
> + output-low;
> };
>
> clock {
> --
> 2.17.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/5] pinctrl: stm32: Add pinmux_show() ops
Hi Patrice,
On 20 September 2018 at 07:37, Patrice Chotard wrote:
> pinmux_show allows to display the muxing of all pins
> belonging to pin-controller.
>
> Signed-off-by: Patrice Chotard
> ---
>
> drivers/pinctrl/pinctrl_stm32.c | 79
> +
> 1 file changed, 79 insertions(+)
>
The only thing I don't like about this is that it is quite
SoC-specific. I am hoping we can make it more generic.
> diff --git a/drivers/pinctrl/pinctrl_stm32.c b/drivers/pinctrl/pinctrl_stm32.c
> index 31285cdd5784..a477035bf420 100644
> --- a/drivers/pinctrl/pinctrl_stm32.c
> +++ b/drivers/pinctrl/pinctrl_stm32.c
> @@ -14,6 +14,16 @@ DECLARE_GLOBAL_DATA_PTR;
> #define OTYPE_MSK 1
> #define AFR_MASK 0xF
>
> +#define PINMUX_MODE_COUNT 5
> +
> +static const char * const pinmux_mode[PINMUX_MODE_COUNT] = {
> + "gpio input",
> + "gpio output",
> + "analog",
> + "unknown",
> + "alt function",
> +};
> +
> static int stm32_gpio_config(struct gpio_desc *desc,
> const struct stm32_gpio_ctl *ctl)
> {
> @@ -176,12 +186,81 @@ static int stm32_pinctrl_set_state_simple(struct
> udevice *dev,
> }
> #endif /* PINCTRL_FULL */
>
> +static int stm32_pinctrl_get_af(struct udevice *dev, unsigned int offset)
> +{
> + struct stm32_gpio_priv *priv = dev_get_priv(dev);
> + struct stm32_gpio_regs *regs = priv->regs;
> + u32 af;
> + u32 alt_shift = (offset % 8) * 4;
> + u32 alt_index = offset / 8;
> +
> + af = (readl(®s->afr[alt_index]) &
> + GENMASK(alt_shift + 3, alt_shift)) >> alt_shift;
> +
> + return af;
> +}
> +
> +static int stm32_pinmux_show(struct udevice *dev)
> +{
> + struct udevice *child;
> + struct udevice *dev_gpio;
> + const char *bank_name;
> + const char *label;
> + int offset;
> + int ret;
> + int num_bits;
> + int mode;
> + int af_num;
> +
> + /* parse pin-controller sub-nodes, ie gpio bank nodes */
> + list_for_each_entry(child, &dev->child_head, sibling_node) {
> + ret = uclass_get_device_by_name(UCLASS_GPIO, child->name,
> + &dev_gpio);
I wonder to what extend this is actually different from 'gpio status'?
> +
> + if (ret < 0 && ret != -ENODEV) {
> + dev_err(dev, "Failed to find %s device ret = %d\n",
> + child->name, ret);
> + return ret;
> + }
> +
> + if (!ret) {
> + bank_name = gpio_get_bank_info(dev_gpio, &num_bits);
> +
> + printf("\nBank %s:\n", bank_name);
> + for (offset = 0; offset < num_bits; offset++) {
> + mode = gpio_get_raw_function(dev_gpio,
> +offset, &label);
> + printf("%s%d: %s", bank_name, offset,
> + pinmux_mode[mode]);
> + switch (mode) {
> + case GPIOF_FUNC:
> + af_num =
> stm32_pinctrl_get_af(dev_gpio,
> + offset);
> + printf(" %d", af_num);
> + break;
> + case STM32_GPIO_MODE_OUT:
How come you cannot use GPIOF_OUTPUT here?
> + case STM32_GPIO_MODE_IN:
> + printf(" %s", label ? label : "");
> + break;
> + }
> + printf("\n");
> + }
> + }
> +
> + if (!child)
> + break;
> + }
> +
> + return 0;
> +}
> +
> static struct pinctrl_ops stm32_pinctrl_ops = {
> #if CONFIG_IS_ENABLED(PINCTRL_FULL)
> .set_state = stm32_pinctrl_set_state,
> #else /* PINCTRL_FULL */
> .set_state_simple = stm32_pinctrl_set_state_simple,
> #endif /* PINCTRL_FULL */
> + .pinmux_show= stm32_pinmux_show,
> };
>
> static const struct udevice_id stm32_pinctrl_ids[] = {
> --
> 1.9.1
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MAINTAINERS: assign include/video*.h
On 19 September 2018 at 12:16, Heinrich Schuchardt wrote: > The include/video*.h files are part of the drivers in drivers/video. So it > makes sense to assign them to the same maintainer. > > Signed-off-by: Heinrich Schuchardt > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] m68k: add basic set of devicetrees
On 20 September 2018 at 15:07, Angelo Dureghello wrote: > This patch adds a basic group of devicetrees, one for each > cpu, including actually just uart and dspi devices, since > these are the drivers supporting devicetree (support added > in this patch). > > Signed-off-by: Angelo Dureghello > --- > arch/m68k/dts/mcf5208.dtsi| 36 > arch/m68k/dts/mcf5227x.dtsi | 48 ++ > arch/m68k/dts/mcf523x.dtsi| 44 ++ > arch/m68k/dts/mcf5249.dtsi| 38 > arch/m68k/dts/mcf5253.dtsi| 44 ++ > arch/m68k/dts/mcf5271.dtsi| 44 ++ > arch/m68k/dts/mcf5272.dtsi| 38 > arch/m68k/dts/mcf5275.dtsi| 44 ++ > arch/m68k/dts/mcf5282.dtsi| 44 ++ > arch/m68k/dts/mcf5301x.dtsi | 48 ++ > arch/m68k/dts/mcf5307.dtsi| 39 + > arch/m68k/dts/mcf5329.dtsi| 36 > arch/m68k/dts/mcf5441x.dtsi | 87 +++ > arch/m68k/dts/mcf5445x.dtsi | 48 ++ > doc/device-tree-bindings/serial/mcf-uart.txt | 19 > doc/device-tree-bindings/spi/spi-mcf-dspi.txt | 22 + > 16 files changed, 679 insertions(+) > create mode 100644 arch/m68k/dts/mcf5208.dtsi > create mode 100644 arch/m68k/dts/mcf5227x.dtsi > create mode 100644 arch/m68k/dts/mcf523x.dtsi > create mode 100644 arch/m68k/dts/mcf5249.dtsi > create mode 100644 arch/m68k/dts/mcf5253.dtsi > create mode 100644 arch/m68k/dts/mcf5271.dtsi > create mode 100644 arch/m68k/dts/mcf5272.dtsi > create mode 100644 arch/m68k/dts/mcf5275.dtsi > create mode 100644 arch/m68k/dts/mcf5282.dtsi > create mode 100644 arch/m68k/dts/mcf5301x.dtsi > create mode 100644 arch/m68k/dts/mcf5307.dtsi > create mode 100644 arch/m68k/dts/mcf5329.dtsi > create mode 100644 arch/m68k/dts/mcf5441x.dtsi > create mode 100644 arch/m68k/dts/mcf5445x.dtsi > create mode 100644 doc/device-tree-bindings/serial/mcf-uart.txt > create mode 100644 doc/device-tree-bindings/spi/spi-mcf-dspi.txt Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/7] drivers: serial: mcfuart: add Kconfig option
On 20 September 2018 at 15:07, Angelo Dureghello wrote: > This patch adds missing CONFIG_MCFUART to Kconfig. > > Signed-off-by: Angelo Dureghello > --- > drivers/serial/Kconfig | 7 +++ > 1 file changed, 7 insertions(+) > Reviewed-by: Simon Glass Suggest you expand the help to mention what features the driver supports (baud rates, serial format?) > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig > index 5fa27254e3..dcbe999776 100644 > --- a/drivers/serial/Kconfig > +++ b/drivers/serial/Kconfig > @@ -499,6 +499,13 @@ config MVEBU_A3700_UART > Choose this option to add support for UART driver on the Marvell > Armada 3700 SoC. The base address is configured via DT. > > +config MCFUART > + bool "Freescale ColdFire UART support" > +default n > +help > + Choose this option to add support for UART driver on the ColFfire > + SoC's family. > + > config MXC_UART > bool "IMX serial port support" > depends on MX5 || MX6 > -- > 2.19.0 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/5] cmd: pinmux: Add pinmux command
Hi Patrice,
On 20 September 2018 at 07:37, Patrice Chotard wrote:
> pinmux command allows to :
> - list all pin-controllers available on platforms
> - select a pin-controller
> - display the muxing of all pins of the current pin-controller
>or all pin-controllers depending of given options
>
> Signed-off-by: Patrice Chotard
> ---
>
> cmd/Kconfig | 8 +
> cmd/Makefile | 3 ++
> cmd/pinmux.c | 115
> +++
> 3 files changed, 126 insertions(+)
> create mode 100644 cmd/pinmux.c
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 13d4c991bf8b..2c687ceecf49 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -937,6 +937,14 @@ config CMD_PCMCIA
> about 1990. These devices are typically removable memory or network
> cards using a standard 68-pin connector.
>
> +config CMD_PINMUX
> + bool "pinmux - show pins muxing"
> + depends on PINCTRL
Should this be default y? It seems that we should normally enable
commands like this which provide useful info.
[..]
> diff --git a/cmd/pinmux.c b/cmd/pinmux.c
> new file mode 100644
> index ..1442d6ef63d2
> --- /dev/null
> +++ b/cmd/pinmux.c
> @@ -0,0 +1,115 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#ifdef CONFIG_PINCTRL
> +
> +#define LIMIT_DEVNAME 30
> +#define LIMIT_OFNAME 32
> +
> +static struct udevice *currdev;
> +
> +static int do_dev(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + const char *name;
> + int ret;
> +
> + switch (argc) {
> + case 2:
> + name = argv[1];
> + ret = uclass_get_device_by_name(UCLASS_PINCTRL, name,
> &currdev);
> + if (ret) {
> + printf("Can't get the pin-controller: %s!\n", name);
> + return CMD_RET_FAILURE;
> + }
> + case 1:
> + if (!currdev) {
> + printf("Pin-controller device is not set!\n\n");
Did you intend to have two \n ?
[..]
> +
> + for (uclass_first_device(UCLASS_PINCTRL, &dev); dev;
> +uclass_next_device(&dev)) {
Can you please add a macro a bit like uclass_foreach_dev() for this
pattern? It seems to come up a lot.
I'm not sure what to call it. Perhaps uclass_foreach_dev_probe()?
> + /* insert a separator between each pin-controller display */
> + printf("--\n");
> + printf("%s:\n", dev->name);
> + ret = pinctrl_pinmux_show(dev);
> + if (ret)
> + return ret;
> + }
> + return CMD_RET_SUCCESS;
Or just 0. It will always be 0.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] dm: test: Add "/firmware" node scan test
On 19 September 2018 at 04:43, Rajan Vaja wrote: > Add a test which verifies that all subnodes under "/firmware" > nodes are scanned. > > Signed-off-by: Rajan Vaja > --- > Changes in v2: > * New patch > --- > arch/sandbox/dts/test.dts | 7 +++ > drivers/firmware/Makefile | 1 + > drivers/firmware/firmware-sandbox.c | 20 > test/dm/Makefile| 1 + > test/dm/firmware.c | 22 ++ > 5 files changed, 51 insertions(+) > create mode 100644 drivers/firmware/firmware-sandbox.c > create mode 100644 test/dm/firmware.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/5] dm: pinctrl: Add pinmux_show() ops
Hi Patrice, On 20 September 2018 at 07:37, Patrice Chotard wrote: > pinmux_show() allows to display the muxing of all pins > belonging to a pin-controller > > Signed-off-by: Patrice Chotard > --- > > drivers/pinctrl/pinctrl-uclass.c | 10 ++ > include/dm/pinctrl.h | 29 + > 2 files changed, 39 insertions(+) > If you look at this pinctrl method: const char *(*get_pin_name)(struct udevice *dev, unsigned selector); you can see that we can specify particular pins. Can we have the command discover what pins are available and iterate over them? Then we can have a function which returns the status of a particular pin as a string, and the command can output it. Perhaps like cpu_get_desc()? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] uclass: Use uclass_foreach_dev() macro instead of open coding
Hi Livu,
On 19 September 2018 at 10:37, Liviu Dudau wrote:
> On Wed, Sep 19, 2018 at 09:30:37AM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 18 September 2018 at 02:08, Liviu Dudau wrote:
>> >
>> > On Tue, Sep 18, 2018 at 04:06:13AM +0200, Simon Glass wrote:
>> > > On 17 September 2018 at 10:44, Liviu Dudau
>> > > wrote:
>> > > > Use the uclass_foreach_dev() macro instead of the open coded version.
>> > > >
>> > > > Signed-off-by: Liviu Dudau
>> > > > ---
>> > > > drivers/core/uclass.c | 2 +-
>> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > >
>> > > Reviewed-by: Simon Glass
>> > >
>> > > Perhaps you could also convert a few usages?
>> >
>> > Not sure what you mean. Are you suggesting that I should convert more of
>> > the code that uses the open coded version into uclass_foreach_dev() ?
>>
>> Yes. After all, at present your macro is just dead code :-)
>
> I think there is some confusion here. I didn't write the macro, it is
> present in include/dm/uclass.h since you have introduced it in commit
> 6494d708bfc630ac0
> ("dm: Add base driver model support"). All I have done was to notice
> that in uclass.c the list_for_each_entry() line can be replaced by the
> macro with the same effect.
>
> I also didn't get what you meant by "your macro is just dead code".
Sorry I completely missed the purpose of your patch!
Yes I think it would be good to convert other code to use this
function, if you can find some.
Reviewed-by: Simon Glass
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] Revert "x86: galileo: Fix boot failure"
Hi Bin, On 4 September 2018 at 03:07, Bin Meng wrote: > Hi Simon, > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: >> >> The root cause of this problem should now be fixed. Renable bootstage. >> >> (Note, if this does not fix it, and instead a -ENOMEM error is produced, >> then we probably need to increase CONFIG_SYS_MALLOC_F_LEN a bit). >> >> This reverts commit 7995dd3782f90e1939969a4ead800a5e98e2d197. >> >> Signed-off-by: Simon Glass >> --- >> >> configs/galileo_defconfig | 3 +++ >> 1 file changed, 3 insertions(+) >> > > I think this breaks Galileo, though I do not have a board to test right now. > > If you look at galileo.dts, it explicitly describes TSC frequency in > the DT, but current TSC timer early support codes does not support > reading TSC frequency in the DT. Maybe we need a config option for > such hardware that can't calibrate TSC frequency? Yes we could. Until then perhaps we can park this patch. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] Enable CONFIG_TIMER_EARLY with bootstage
Hi Bin, On 4 September 2018 at 03:06, Bin Meng wrote: > Hi Simon, > > On Mon, Sep 3, 2018 at 7:02 AM Simon Glass wrote: >> >> In initr_bootstage() we call bootstage_mark_name() which ends up calling >> timer_get_us(). This call happens before initr_dm(), which inits driver >> model. >> >> On x86 we set gd->timer to NULL in the transition from board_init_f() > > It's not just x86 we set gd->timer to NULL. It applied to all > architectures when CONFIG_TIMER is on. > >> to board_init_r(). See board_init_f_r() for this assignment. So U-Boot >> knows there is no timer available in the period immediately after >> relocation. >> >> On x86 the timer_get_us() call is implemented as calls to get_ticks() and >> get_tbclk(). Both of these call dm_timer_init() to set up the timer, if >> gd->timer is NULL and the early timer is not available. >> >> However dm_timer_init() cannot succeed before initr_dm() is called. >> >> So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable >> CONFIG_TIMER_EARLY. Update the Kconfig to handle this. >> >> Note: On most architectures we can rely on the pre-relocation memory still >> being available, so that gd->timer pointers to a valid timer device and >> everything works correctly. Admittedly this is not strictly correct since >> the timer device is set up by pre-relocation U-Boot, but normally this is >> fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot >> disappears in board_init_f_r() and any attempt to access it will hang. >> This is the reason why we must mark the timer as invalid when we get to >> board_init_f_r(). >> >> Signed-off-by: Simon Glass >> --- >> >> drivers/timer/Kconfig | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig >> index 5ab6749193c..ff434de6f7c 100644 >> --- a/drivers/timer/Kconfig >> +++ b/drivers/timer/Kconfig >> @@ -30,6 +30,9 @@ config TPL_TIMER >> config TIMER_EARLY >> bool "Allow timer to be used early in U-Boot" >> depends on TIMER >> + # initr_bootstage() requires a timer and is called before initr_dm() >> + # so only the early timer is available >> + default y if X86 && BOOTSTAGE > > Since this applies not only on x86, and given without TIMER_EARLY > BOOTSTAGE is broken, shouldn't we do this in BOOTSTAGE config instead: > > config BOOTSTAGE > select TIMER_EARLY Well we could, but I suspect that would break things since the early timer is not supported by many boards. Also for most boards this doesn't actually work fine. x86 is really quite awful in that it has no SRAM and the CAR becomes inaccessible as soon as you turn on the cache! Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/15] tee: optee: support AVB trusted application
Hi Jens, On 31 August 2018 at 06:10, Jens Wiklander wrote: > > Hi Simon, > > On Wed, Aug 29, 2018 at 06:29:09PM -0600, Simon Glass wrote: > > Hi Jens, > > > > On 23 August 2018 at 04:43, Jens Wiklander > > wrote: > > > Adds configuration option OPTEE_TA_AVB and a header file describing the > > > interface to the AVB trusted application provided by OP-TEE. > > > > What is AVB? Can you please write it out in full? > > AVB stands for Android Verified Boot 2.0. However, Google is a bit picky > about how the name Android is used so I'm trying to avoid using it as > much as possible to stay out of trouble. I'll write it out in the commit > message. I think it should be somewhere in the docs at least. It looks like this is what you need to follow: https://developer.android.com/distribute/marketing-tools/brand-guidelines Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] sandbox: fix phys_to_virt()
Allow for pointers not created by map_to_sysmem().
This fixes the fit image and vboot test.
Fixes: 8b79c294ec57 ("sandbox: Enhance map_to_sysmem() to handle foreign
pointers")
Signed-off-by: Heinrich Schuchardt
---
Alex, this should fix the issues with the efi-next pull request. Would
you add it to your queue?
https://travis-ci.org/xypron2/u-boot/builds/433278595
---
arch/sandbox/cpu/cpu.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
index 6098945049..4e28d06e43 100644
--- a/arch/sandbox/cpu/cpu.c
+++ b/arch/sandbox/cpu/cpu.c
@@ -111,12 +111,8 @@ void *phys_to_virt(phys_addr_t paddr)
}
}
- printf("%s: Cannot map sandbox address %lx (SDRAM from 0 to %lx)\n",
- __func__, (ulong)paddr, (ulong)gd->ram_size);
- os_abort();
-
- /* Not reached */
- return NULL;
+ /* Allow for pointers not created by map_to_sysmem() */
+ return (void *)(gd->arch.ram_buf + paddr);
}
struct sandbox_mapmem_entry *find_tag(const void *ptr)
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/3] efi_loader: eliminate handle member
A pointer to a struct efi_object is a handle. We do not need any handle
member in this structure. Let's eliminate it.
Signed-off-by: Heinrich Schuchardt
---
v3
no change
v2
replace remaining parent.handle in efi_disk.c
---
include/efi_loader.h | 26 +-
lib/efi_loader/efi_boottime.c| 59
lib/efi_loader/efi_console.c | 20 +--
lib/efi_loader/efi_device_path.c | 2 +-
lib/efi_loader/efi_disk.c| 14
lib/efi_loader/efi_gop.c | 2 +-
lib/efi_loader/efi_net.c | 6 ++--
7 files changed, 68 insertions(+), 61 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 74df070316..6846bb03f3 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -173,20 +173,28 @@ struct efi_handler {
struct list_head open_infos;
};
-/*
- * UEFI has a poor man's OO model where one "object" can be polymorphic and
have
- * multiple different protocols (classes) attached to it.
+/**
+ * struct efi_object - dereferenced EFI handle
+ *
+ * @link: pointers to put the handle into a linked list
+ * @protocols: linked list with the protocol interfaces installed on this
+ * handle
+ *
+ * UEFI offers a flexible and expandable object model. The objects in the UEFI
+ * API are devices, drivers, and loaded images. struct efi_object is our
storage
+ * structure for these objects.
+ *
+ * When including this structure into a larger structure always put it first so
+ * that when deleting a handle the whole encompassing structure can be freed.
*
- * This struct is the parent struct for all of our actual implementation
objects
- * that can include it to make themselves an EFI object
+ * A pointer to this structure is referred to as a handle. Typedef efi_handle_t
+ * has been created for such pointers.
*/
struct efi_object {
/* Every UEFI object is part of a global object list */
struct list_head link;
/* The list of protocols */
struct list_head protocols;
- /* The object spawner can either use this for data or as identifier */
- void *handle;
};
/**
@@ -296,11 +304,11 @@ void efi_runtime_relocate(ulong offset, struct
efi_mem_desc *map);
/* Call this to set the current device name */
void efi_set_bootdev(const char *dev, const char *devnr, const char *path);
/* Add a new object to the object list. */
-void efi_add_handle(struct efi_object *obj);
+void efi_add_handle(efi_handle_t obj);
/* Create handle */
efi_status_t efi_create_handle(efi_handle_t *handle);
/* Delete handle */
-void efi_delete_handle(struct efi_object *obj);
+void efi_delete_handle(efi_handle_t obj);
/* Call this to validate a handle and find the EFI object for it */
struct efi_object *efi_search_obj(const efi_handle_t handle);
/* Find a protocol on a handle */
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index bc6ad84495..f7d63a3178 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -416,13 +416,12 @@ static efi_status_t EFIAPI efi_free_pool_ext(void *buffer)
*
* The protocols list is initialized. The object handle is set.
*/
-void efi_add_handle(struct efi_object *obj)
+void efi_add_handle(efi_handle_t handle)
{
- if (!obj)
+ if (!handle)
return;
- INIT_LIST_HEAD(&obj->protocols);
- obj->handle = obj;
- list_add_tail(&obj->link, &efi_obj_list);
+ INIT_LIST_HEAD(&handle->protocols);
+ list_add_tail(&handle->link, &efi_obj_list);
}
/**
@@ -440,7 +439,7 @@ efi_status_t efi_create_handle(efi_handle_t *handle)
return EFI_OUT_OF_RESOURCES;
efi_add_handle(obj);
- *handle = obj->handle;
+ *handle = obj;
return EFI_SUCCESS;
}
@@ -536,13 +535,13 @@ efi_status_t efi_remove_all_protocols(const efi_handle_t
handle)
*
* @obj: handle to delete
*/
-void efi_delete_handle(struct efi_object *obj)
+void efi_delete_handle(efi_handle_t handle)
{
- if (!obj)
+ if (!handle)
return;
- efi_remove_all_protocols(obj->handle);
- list_del(&obj->link);
- free(obj);
+ efi_remove_all_protocols(handle);
+ list_del(&handle->link);
+ free(handle);
}
/**
@@ -927,7 +926,7 @@ struct efi_object *efi_search_obj(const efi_handle_t handle)
struct efi_object *efiobj;
list_for_each_entry(efiobj, &efi_obj_list, link) {
- if (efiobj->handle == handle)
+ if (efiobj == handle)
return efiobj;
}
@@ -1052,7 +1051,7 @@ out:
/**
* efi_get_drivers() - get all drivers associated to a controller
- * @efiobj: handle of the controller
+ * @handle: handle of the controller
* @protocol: protocol GUID (optional)
* @number_of_drivers:number of child controllers
* @driver_handle_buffer: handles of the the drivers
@@ -1
[U-Boot] [PATCH v3 0/3] efi_loader: eliminate handle member
Up to now we have treated handles as separate objects to EFI objects. This confusion has lead to hidden bugs like those corrected by the first patch. By changing the efi_handle_t typedef we can avoid this problem in future. As handles are pointers to EFI objects there is no need for a handle member in struct efi_object. This allows to simplify our coding. v3 rename parent to header rename image_handle to image_obj v2 replace remaining parent.handle in efi_disk.c Heinrich Schuchardt (3): efi_loader: typedef struct efi_object *efi_handle_t efi_loader: eliminate handle member efi_loader: rename parent to header cmd/bootefi.c | 28 include/efi.h | 2 +- include/efi_api.h | 8 +-- include/efi_loader.h | 35 +++--- lib/efi/efi.c | 2 +- lib/efi_loader/efi_boottime.c | 79 +++--- lib/efi_loader/efi_console.c | 20 +++--- lib/efi_loader/efi_device_path.c | 2 +- lib/efi_loader/efi_disk.c | 42 ++-- lib/efi_loader/efi_gop.c | 21 -- lib/efi_loader/efi_net.c | 22 +++--- lib/efi_selftest/efi_selftest_devicepath.c | 2 +- 12 files changed, 146 insertions(+), 117 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/3] efi_loader: rename parent to header
Rename the component parent of some EFI objects to header. This avoids
misunderstandings.
Signed-off-by: Heinrich Schuchardt
---
v3
new patch
---
cmd/bootefi.c | 12 +--
include/efi_loader.h | 9 +++--
lib/efi_loader/efi_boottime.c | 6 +++---
lib/efi_loader/efi_disk.c | 38 +++
lib/efi_loader/efi_gop.c | 21 ---
lib/efi_loader/efi_net.c | 22
6 files changed, 65 insertions(+), 43 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index b3d507a0d8..a4c3844c31 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -422,7 +422,7 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
- (ulong)&image_obj->parent,
+ (ulong)&image_obj->header,
(ulong)&systab, 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
@@ -439,7 +439,7 @@ static efi_status_t do_bootefi_exec(void *efi,
secure_ram_addr(_do_nonsec_entry)(
efi_run_in_hyp,
(uintptr_t)entry,
- (uintptr_t)&image_obj->parent,
+ (uintptr_t)&image_obj->header,
(uintptr_t)&systab);
/* Should never reach here, efi exits with longjmp */
@@ -447,12 +447,12 @@ static efi_status_t do_bootefi_exec(void *efi,
}
#endif
- ret = efi_do_enter(&image_obj->parent, &systab, entry);
+ ret = efi_do_enter(&image_obj->header, &systab, entry);
exit:
/* image has returned, loaded-image obj goes *poof*: */
if (image_obj)
- efi_delete_handle(&image_obj->parent);
+ efi_delete_handle(&image_obj->header);
if (mem_handle)
efi_delete_handle(mem_handle);
@@ -561,10 +561,10 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
/* Transfer environment variable efi_selftest as load options */
set_load_options(loaded_image_info, "efi_selftest");
/* Execute the test */
- r = efi_selftest(&image_obj->parent, &systab);
+ r = efi_selftest(&image_obj->header, &systab);
efi_restore_gd();
free(loaded_image_info->load_options);
- efi_delete_handle(&image_obj->parent);
+ efi_delete_handle(&image_obj->header);
return r != EFI_SUCCESS;
} else
#endif
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 6846bb03f3..04899a137b 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -199,10 +199,15 @@ struct efi_object {
/**
* struct efi_loaded_image_obj - handle of a loaded image
+ *
+ * @header:EFI object header
+ * @reloc_base:base address for the relocated image
+ * @reloc_size:size of the relocated image
+ * @exit_jmp: long jump buffer for returning form started image
+ * @entry: entry address of the relocated image
*/
struct efi_loaded_image_obj {
- /* Generic EFI object parent class data */
- struct efi_object parent;
+ struct efi_object header;
void *reloc_base;
aligned_u64 reloc_size;
efi_status_t exit_status;
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index f7d63a3178..5acd04b384 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1488,7 +1488,7 @@ efi_status_t efi_setup_loaded_image(struct
efi_device_path *device_path,
}
/* Add internal object to object list */
- efi_add_handle(&obj->parent);
+ efi_add_handle(&obj->header);
if (info_ptr)
*info_ptr = info;
@@ -1505,7 +1505,7 @@ efi_status_t efi_setup_loaded_image(struct
efi_device_path *device_path,
* When asking for the device path interface, return
* bootefi_device_path
*/
- ret = efi_add_protocol(&obj->parent,
+ ret = efi_add_protocol(&obj->header,
&efi_guid_device_path, device_path);
if (ret != EFI_SUCCESS)
goto failure;
@@ -1515,7 +1515,7 @@ efi_status_t efi_setup_loaded_image(struct
efi_device_path *device_path,
* When asking for the loaded_image interface, just
* return handle which points to loaded_image_info
*/
- ret = efi_add_protocol(&obj->parent,
+ ret = efi_add_protocol(&obj->header,
&efi_guid_loaded_image, info);
if (ret != EFI_SUCCESS)
goto failure;
diff --git a/lib/
[U-Boot] [PATCH v3 1/3] efi_loader: typedef struct efi_object *efi_handle_t
All our handles point to a struct efi_object. So let's define the
efi_handle_t accordingly. This helps us to discover coding errors much
more easily. This becomes evident by the corrections to the usage of
handles in this patch.
Rename variable image_handle to image_obj where applicable.
Signed-off-by: Heinrich Schuchardt
---
v3
rename image_handle to image_obj
v2
no change
---
cmd/bootefi.c | 28 +++---
include/efi.h | 2 +-
include/efi_api.h | 8 +++
lib/efi/efi.c | 2 +-
lib/efi_loader/efi_boottime.c | 18 +++---
lib/efi_selftest/efi_selftest_devicepath.c | 2 +-
6 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 9c51a2cbd1..b3d507a0d8 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -343,7 +343,7 @@ static efi_status_t do_bootefi_exec(void *efi,
efi_handle_t mem_handle = NULL;
struct efi_device_path *memdp = NULL;
efi_status_t ret;
- struct efi_loaded_image_obj *image_handle = NULL;
+ struct efi_loaded_image_obj *image_obj = NULL;
struct efi_loaded_image *loaded_image_info = NULL;
EFIAPI efi_status_t (*entry)(efi_handle_t image_handle,
@@ -374,7 +374,7 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
- ret = efi_setup_loaded_image(device_path, image_path, &image_handle,
+ ret = efi_setup_loaded_image(device_path, image_path, &image_obj,
&loaded_image_info);
if (ret != EFI_SUCCESS)
goto exit;
@@ -388,7 +388,7 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Transfer environment variable bootargs as load options */
set_load_options(loaded_image_info, "bootargs");
/* Load the EFI payload */
- entry = efi_load_pe(image_handle, efi, loaded_image_info);
+ entry = efi_load_pe(image_obj, efi, loaded_image_info);
if (!entry) {
ret = EFI_LOAD_ERROR;
goto exit;
@@ -409,8 +409,8 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Call our payload! */
debug("%s:%d Jumping to 0x%lx\n", __func__, __LINE__, (long)entry);
- if (setjmp(&image_handle->exit_jmp)) {
- ret = image_handle->exit_status;
+ if (setjmp(&image_obj->exit_jmp)) {
+ ret = image_obj->exit_status;
goto exit;
}
@@ -422,7 +422,7 @@ static efi_status_t do_bootefi_exec(void *efi,
/* Move into EL2 and keep running there */
armv8_switch_to_el2((ulong)entry,
- (ulong)image_handle,
+ (ulong)&image_obj->parent,
(ulong)&systab, 0, (ulong)efi_run_in_el2,
ES_TO_AARCH64);
@@ -439,7 +439,7 @@ static efi_status_t do_bootefi_exec(void *efi,
secure_ram_addr(_do_nonsec_entry)(
efi_run_in_hyp,
(uintptr_t)entry,
- (uintptr_t)image_handle,
+ (uintptr_t)&image_obj->parent,
(uintptr_t)&systab);
/* Should never reach here, efi exits with longjmp */
@@ -447,12 +447,12 @@ static efi_status_t do_bootefi_exec(void *efi,
}
#endif
- ret = efi_do_enter(image_handle, &systab, entry);
+ ret = efi_do_enter(&image_obj->parent, &systab, entry);
exit:
/* image has returned, loaded-image obj goes *poof*: */
- if (image_handle)
- efi_delete_handle(&image_handle->parent);
+ if (image_obj)
+ efi_delete_handle(&image_obj->parent);
if (mem_handle)
efi_delete_handle(mem_handle);
@@ -537,7 +537,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#endif
#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
if (!strcmp(argv[1], "selftest")) {
- struct efi_loaded_image_obj *image_handle;
+ struct efi_loaded_image_obj *image_obj;
struct efi_loaded_image *loaded_image_info;
/* Construct a dummy device path. */
@@ -547,7 +547,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
r = efi_setup_loaded_image(bootefi_device_path,
- bootefi_image_path, &image_handle,
+ bootefi_image_path, &image_obj,
&loaded_image_info);
if (r != EFI_SUCCESS)
return CMD_RET_FAILU
Re: [U-Boot] [PATCH v2 2/3] arm: layerscape: Remove CONFIG_U_QE define in head files
Hi York, > -Original Message- > From: York Sun > Sent: Wednesday, September 26, 2018 01:02 > To: Ran Wang ; Alison Wang > Cc: Qiang Zhao ; u-boot@lists.denx.de > Subject: Re: [PATCH v2 2/3] arm: layerscape: Remove CONFIG_U_QE define in > head files > > On 09/24/2018 11:45 PM, Ran Wang wrote: > > Because it has been moved to drivers/qe/Kconfig instead. > > Following platforms are involved: > > T102xQDS, T102xRDB, T1040QDS, ls1021aqds, ls1021atwr, ls1043ardb > > > > Signed-off-by: Ran Wang > > --- > > Change in v2: > > Remove CONFIG_U_QE from more platforms besides ls1021a > > > > include/configs/T102xQDS.h | 1 - > > include/configs/T102xRDB.h | 1 - > > include/configs/T1040QDS.h | 1 - > > include/configs/ls1021aqds.h | 1 - > > include/configs/ls1021atwr.h | 1 - > > include/configs/ls1043ardb.h | 7 --- > > 6 files changed, 12 deletions(-) > > After removing all defines, please remove it from config_whitelist.txt. Got it, will add it in next version. Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] qe: kconfig: U QE kconfig
Hi York, > -Original Message- > From: York Sun > Sent: Wednesday, September 26, 2018 01:02 > To: Ran Wang ; Alison Wang > Cc: Qiang Zhao ; u-boot@lists.denx.de > Subject: Re: [PATCH v2 1/3] qe: kconfig: U QE kconfig > > On 09/24/2018 11:45 PM, Ran Wang wrote: > > add Kconfig option for U QUICC Engine. > > > > Signed-off-by: Ran Wang > > --- > > Change in v2: > > Add more conditional define to support more platforms. > > > > drivers/Kconfig| 2 ++ > > drivers/qe/Kconfig | 12 > > 2 files changed, 14 insertions(+) > > create mode 100644 drivers/qe/Kconfig > > > > diff --git a/drivers/Kconfig b/drivers/Kconfig index > > 56536c4b19..884a945a19 100644 > > --- a/drivers/Kconfig > > +++ b/drivers/Kconfig > > @@ -74,6 +74,8 @@ source "drivers/power/Kconfig" > > > > source "drivers/pwm/Kconfig" > > > > +source "drivers/qe/Kconfig" > > + > > source "drivers/ram/Kconfig" > > > > source "drivers/remoteproc/Kconfig" > > diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig new file mode > > 100644 index 00..c47b54ab12 > > --- /dev/null > > +++ b/drivers/qe/Kconfig > > @@ -0,0 +1,12 @@ > > +# > > +# QUICC Engine Drivers > > +# > > +config U_QE > > Did you notice you have extra space here? My bad, will correct it, thanks for point out. Ran ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Fixes the load command return code under btrfs
On Thu, Sep 13, 2018 at 06:48:41PM +, Stephane Gilbert wrote:
> Hi,
>
> I am submitting the following patch to resolve issue below:
> When using the load command with a btrfs filesystem, the return code of
> that command if always success even if the command failed. The problem
> is the do_load command in fs.c who assume any positive return code from
> fs_read as success. However the brtfs read function returns positive
> error code in case of failure. Other fs read fonction like fat and ext4
> returns negative error codes on failure. So this patch change the
> return code of the btrfs read function to be consistent with other read
> functions. This way it will be possible to use the return code in the
> Hush shell with btrfs file systems as with other filesystems.
>
> >From 8b8141dbdfc43456b85585e99a2dfa4340800a95 Mon Sep 17 00:00:00 2001
> From: Stephane Gilbert
> Date: Thu, 13 Sep 2018 14:47:16 -0400
> Subject: [PATCH] Fixes the load command return code under btrfs
> filesystem
> ---
> fs/btrfs/btrfs.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> if (!len)
> @@ -200,7 +200,7 @@ int btrfs_read(const char *file, void *buf, loff_t
> offset, loff_t len,
> rd = btrfs_file_read(&root, inr, offset, len, buf);
> if (rd == -1ULL) {
> printf("An error occured while reading file %s\n",
> file);
> - return 1;
> + return -5;
> }
>
> *actread = rd;
>
> diff --git a/fs/btrfs/btrfs.c b/fs/btrfs/btrfs.c
> index 6f35854823..64ec1af5a9 100644
> --- a/fs/btrfs/btrfs.c
> +++ b/fs/btrfs/btrfs.c
> @@ -183,12 +183,12 @@ int btrfs_read(const char *file, void *buf,
> loff_t offset, loff_t len,
>
> if (inr == -1ULL) {
> printf("Cannot lookup file %s\n", file);
> - return 1;
> + return -2;
> }
>
> if (type != BTRFS_FT_REG_FILE) {
> printf("Not a regular file: %s\n", file);
> - return 1;
> + return -2;
> }
>
Your patch itself seems to have been garbled, please resubmit as v2,
thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
Hi, On 25 September 2018 at 01:02, Chee, Tien Fong wrote: > On Thu, 2018-09-20 at 21:42 -0700, Chee, Tien Fong wrote: >> > > If everybody agree with current framework, then the next version i will > include the fixes: > 1. Adding DM_FLAG_PRE_RELOC, this would allow runtime to choose the > right fs_loader if the chosen node u-boot, fs-loader is not defined. > > 2. Let driver model handles all memory allocation > > 3. Using local variable instead of messy casts. Sounds good. Can you please give an example of this? If you just mean within a function, that's fine. We try to avoid static variables with driver model. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/6] common: Generic loader for file system
On Tue, Sep 25, 2018 at 07:02:42AM +, Chee, Tien Fong wrote: > On Thu, 2018-09-20 at 21:42 -0700, Chee, Tien Fong wrote: > > > > If everybody agree with current framework, then the next version i will > include the fixes: > 1. Adding DM_FLAG_PRE_RELOC, this would allow runtime to choose the > right fs_loader if the chosen node u-boot, fs-loader is not defined. > > 2. Let driver model handles all memory allocation > > 3. Using local variable instead of messy casts. A new version of this series, or a follow up series? Thanks again! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/8] powerpc: mpc85xx: Use binman to embed dtb inside U-Boot
On 09/02/2018 10:08 PM, Jagdish Gediya wrote:
> Below is the sequence to embed dtb inside U-Boot,
> 1. Remove bootpg and resetvec section if needed
> 2. Append dtb
> 3. Append bootpg and resetvec section back if removed in step 1
>
> Above procedure is required only when CONFIG_MPC85xx and
> CONFIG_OF_SEPARATE are defined.
>
> Add new config CONFIG_MPC85XX_HAVE_RESET_VECTOR to indicate that
> image has resetvec section. Step 1 and step 3 described above are
> required only if this config is y.
>
> Signed-off-by: Jagdish Gediya
> ---
> Changes for v2:
> - Don't change the generic target
> - Add new config option to use binman
>
> Changes for v3:
> - Commit message change('u-boot' -> 'U-Boot')
>
> Makefile | 23 ++-
> arch/powerpc/cpu/mpc85xx/Kconfig | 4
> 2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index b5bf8ab..03baa74 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -861,6 +861,10 @@ ifneq ($(CONFIG_SYS_INIT_SP_BSS_OFFSET),)
> ALL-y += init_sp_bss_offset_check
> endif
>
> +ifeq ($(CONFIG_MPC85xx)$(CONFIG_OF_SEPARATE),yy)
> +ALL-y += u-boot-with-dtb.bin
> +endif
> +
One thing confuses me is the output file. My understand is we will use
u-boot-with-dtb.bin file. Other files are intermediate files. It would
be helpful to explain each output file, especially for debugging, and
let other know we switch from one file to another after this patch set.
CONFIG_OF_SEPARATE seems not be selected explicitly anywhere. Are we
relying on the first choice to be selected automatically? Is it guaranteed?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: add TSE PCS support to dwmac-socfpga
On 09/25/2018 10:00 AM, Dinh Nguyen wrote: > > > On 09/25/2018 01:24 AM, Ooi, Joyce wrote: >> This adds support for TSE PCS that uses SGMII adapter when the >> phy-mode in device tree is set to sgmii. > > Can you add a bit more description to your commit message? TSE(Triple > Speed Ethernet), but what is PCS? > >> >> Signed-off-by: Ooi, Joyce >> --- >> drivers/net/Makefile | 3 +- >> drivers/net/designware.c | 5 ++ >> drivers/net/designware.h | 1 + >> drivers/net/dwmac_socfpga.c| 121 + >> drivers/net/phy/altr_tse_pcs.c | 197 >> + >> drivers/net/phy/altr_tse_pcs.h | 59 >> 6 files changed, 385 insertions(+), 1 deletion(-) >> create mode 100644 drivers/net/phy/altr_tse_pcs.c >> create mode 100644 drivers/net/phy/altr_tse_pcs.h >> >> diff --git a/drivers/net/Makefile b/drivers/net/Makefile >> index 48a2878..c2333b5 100644 >> --- a/drivers/net/Makefile >> +++ b/drivers/net/Makefile >> @@ -14,7 +14,7 @@ obj-$(CONFIG_CALXEDA_XGMAC) += calxedaxgmac.o >> obj-$(CONFIG_CS8900) += cs8900.o >> obj-$(CONFIG_TULIP) += dc2114x.o >> obj-$(CONFIG_ETH_DESIGNWARE) += designware.o >> -obj-$(CONFIG_ETH_DESIGNWARE_SOCFPGA) += dwmac_socfpga.o >> +obj-$(CONFIG_ETH_DESIGNWARE_SOCFPGA) += dwmac-socfpga.o > > Huh? What's this change for? > > Also, I'm getting these compile errors against the latest U-Boot, top > commit = "284b27cf81da10d55 Merge branch 'master' of > git://git.denx.de/u-boot-mips" : > > drivers/net/dwmac_socfpga.c: In function ‘socfpga_dw_tse_pcs_init’: > drivers/net/dwmac_socfpga.c:67:9: warning: implicit declaration of > function ‘mbox_get_fpga_config_status’ [-Wimplicit-function-declaration] >ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS); > ^~~ > LD common/built-in.o > LD drivers/net/dwmac-socfpga.o > LD drivers/net/built-in.o > LD cmd/built-in.o > CC lib/smbios.o > CC lib/display_options.o > CC lib/efi_loader/efi_reloc.o > CC lib/efi_loader/helloworld.o > LD lib/efi_loader/helloworld_efi.so > OBJCOPY lib/efi_loader/helloworld.efi > rm lib/efi_loader/helloworld_efi.so lib/efi_loader/helloworld.o > LD lib/built-in.o > LD u-boot > drivers/net/built-in.o: In function `dwmac_socfpga_ofdata_to_platdata': > /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:170: > undefined reference to `syscon_node_to_regmap' > /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:177: > undefined reference to `regmap_get_range' > drivers/net/built-in.o: In function `socfpga_dw_tse_pcs_init': > /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:67: > undefined reference to `mbox_get_fpga_config_status' > > > In the future, please test before submitting patches. > For the arria10 defconfig, I get the following compile error: drivers/net/dwmac_socfpga.c: In function ‘socfpga_dw_tse_pcs_init’: drivers/net/dwmac_socfpga.c:67:9: warning: implicit declaration of function ‘mbox_get_fpga_config_status’ [-Wimplicit-function-declaration] ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS); ^~~ drivers/net/dwmac_socfpga.c:74:3: error: too many arguments to function ‘socfpga_bridges_reset’ socfpga_bridges_reset(1); ^ In file included from ./arch/arm/include/asm/arch/reset_manager.h:44:0, from drivers/net/dwmac_socfpga.c:21: ./arch/arm/include/asm/arch/reset_manager_arria10.h:15:5: note: declared here int socfpga_bridges_reset(void); Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] arm: layerscape: Remove CONFIG_U_QE define in head files
On 09/24/2018 11:45 PM, Ran Wang wrote: > Because it has been moved to drivers/qe/Kconfig instead. > Following platforms are involved: > T102xQDS, T102xRDB, T1040QDS, ls1021aqds, ls1021atwr, ls1043ardb > > Signed-off-by: Ran Wang > --- > Change in v2: > Remove CONFIG_U_QE from more platforms besides ls1021a > > include/configs/T102xQDS.h | 1 - > include/configs/T102xRDB.h | 1 - > include/configs/T1040QDS.h | 1 - > include/configs/ls1021aqds.h | 1 - > include/configs/ls1021atwr.h | 1 - > include/configs/ls1043ardb.h | 7 --- > 6 files changed, 12 deletions(-) After removing all defines, please remove it from config_whitelist.txt. York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] qe: kconfig: U QE kconfig
On 09/24/2018 11:45 PM, Ran Wang wrote: > add Kconfig option for U QUICC Engine. > > Signed-off-by: Ran Wang > --- > Change in v2: > Add more conditional define to support more platforms. > > drivers/Kconfig| 2 ++ > drivers/qe/Kconfig | 12 > 2 files changed, 14 insertions(+) > create mode 100644 drivers/qe/Kconfig > > diff --git a/drivers/Kconfig b/drivers/Kconfig > index 56536c4b19..884a945a19 100644 > --- a/drivers/Kconfig > +++ b/drivers/Kconfig > @@ -74,6 +74,8 @@ source "drivers/power/Kconfig" > > source "drivers/pwm/Kconfig" > > +source "drivers/qe/Kconfig" > + > source "drivers/ram/Kconfig" > > source "drivers/remoteproc/Kconfig" > diff --git a/drivers/qe/Kconfig b/drivers/qe/Kconfig > new file mode 100644 > index 00..c47b54ab12 > --- /dev/null > +++ b/drivers/qe/Kconfig > @@ -0,0 +1,12 @@ > +# > +# QUICC Engine Drivers > +# > +config U_QE Did you notice you have extra space here? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v9 8/8] Enable CONFIG_BLK and CONFIG_DM_MMC to Kconfig
On 09/24/2018 11:51 PM, Yinbo Zhu wrote: > This enables the folowing to Kconfig: > CONFIG_BLK > CONFIG_DM_MMC > > Signed-off-by: Yinbo Zhu > --- > Change in v9: > fix ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig compiling errors You didn't "fix" it. You simply dropped the change to ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig. Do you know why ls1021atwr_nor_SECURE_BOOT_defconfig and ls1021atwr_sdcard_ifc_defconfig work, but not ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig? York ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl-lsch3: soc: Enable AHB support flexspi controller
On 09/25/2018 01:44 AM, Ashish Kumar wrote:
> Enable AHB support for flexspi controller interface meaning
> memory can be accessed via md command using absolute addresses
>
> Signed-off-by: Yogesh Gaur
> Signed-off-by: Rajat Srivastava
> Signed-off-by: Ashish Kumar
> ---
> arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 10 ++
> arch/arm/cpu/armv8/fsl-layerscape/soc.c | 42 +++
> 2 files changed, 52 insertions(+)
>
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> index 5280d33ec8..8d66783b7c 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
> @@ -327,6 +327,16 @@ config SYS_FSPI_AHB_INIT
> performed. Default LUT programmed in AHB mode is Fast Read command
> with 4-byte addressing enabled.
>
> +config FSPI_AHB_EN_4BYTE
> + bool "Enable 4-byte Fast Read cmd for AHB mode"
s/cmd/command
> + depends on NXP_FSPI
> + default n
> + help
> + The default setting for FSPI AHB bus just supports 3-byte addressing.
> + But some FSPI flash sizes are up to 64MBytes.
> + This flag enables fast read cmd for AHB mode and modifies required
> + LUT to support full FSPI flash.
> +
It is FlexSPI, not FSPI, nor flexspi. Please use consistent term for
FlexSPI in subject, commit message, document and comment. If you have to
use FSPI in macro names, make sure it it has clear meaning.
> config SYS_CCI400_OFFSET
> hex "Offset for CCI400 base"
> depends on SYS_FSL_HAS_CCI400
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> index 3f15cb08ff..60beb0dc96 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> @@ -640,6 +640,45 @@ void fsl_lsch2_early_init_f(void)
> }
> #endif
>
> +#ifdef CONFIG_FSPI_AHB_EN_4BYTE
> +int fspi_ahb_init(void)
> +{
> + /* Enable 4bytes address support and fast read */
> + u32 *fspi_lut, lut_key, *fspi_key;
> +
> + fspi_key = (void *)SYS_FSL_FSPI_ADDR + 0x18;
> + fspi_lut = (void *)SYS_FSL_FSPI_ADDR + 0x200;
> +
> + lut_key = in_be32(fspi_key);
> +
> + if (lut_key == 0x5af05af0) {
> + /* That means the register is BE */
> + out_be32(fspi_key, 0x5af05af0);
> + /* Unlock the lut table */
> + out_be32(fspi_key + 1, 0x0002);
> + out_be32(fspi_lut, 0x0820040c);
> + out_be32(fspi_lut + 1, 0x24003008);
> + out_be32(fspi_lut + 2, 0x);
> + /* Lock the lut table */
> + out_be32(fspi_key, 0x5af05af0);
> + out_be32(fspi_key + 1, 0x0001);
> + } else {
> + /* That means the register is LE */
> + out_le32(fspi_key, 0x5af05af0);
> + /* Unlock the lut table */
> + out_le32(fspi_key + 1, 0x0002);
> + out_le32(fspi_lut, 0x0820040c);
> + out_le32(fspi_lut + 1, 0x24003008);
> + out_le32(fspi_lut + 2, 0x);
> + /* Lock the lut table */
> + out_le32(fspi_key, 0x5af05af0);
> + out_le32(fspi_key + 1, 0x0001);
Is there anyway you can make the magic numbers more meaningful?
York
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/4] Add USB EHCI and gadget support for STM32MP1
Hi It's a gentle reminder to not forget thise series for U-boot 2018.11 release. Thanks Patrice On 08/10/2018 05:12 PM, Patrice Chotard wrote: > > This series : > - Adds DT nodes to add usb gadget support for stm32mp157-ev1 board > - Adds DT nodes to add EHCI support for stm32mp157-ev1 board > - Enables all USB relative flags needed for USB EHCI, DWC2 gadget and > mass storage support > - Update stm32mp1 board by populating board_usb_init() to initialize > USB gadget driver > > > Patrice Chotard (4): > ARM: dts: stm32mp1: Add usb gadget support for stm32mp157c-ev1 board > ARM: dts: stm32mp1: Add EHCI support for stm32mp157c-ev1 board > configs: stm32mp15: Enable USB relative flags > board: st: stm32mp1: Add usb gadget support > > arch/arm/dts/stm32mp157-pinctrl.dtsi | 6 ++ > arch/arm/dts/stm32mp157c-ev1-u-boot.dtsi | 5 + > arch/arm/dts/stm32mp157c-ev1.dts | 15 +++ > arch/arm/dts/stm32mp157c.dtsi| 36 +++ > board/st/stm32mp1/stm32mp1.c | 168 > +++ > configs/stm32mp15_basic_defconfig| 16 +++ > 6 files changed, 246 insertions(+) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] chain-loading u-boot from u-boot?
colleague just asked me how to (if possible) chain-load a modified
u-boot from a u-boot currently stored in flash, and from having done
this once *years* ago, i'm fairly sure i can make this happen, i just
want to confirm my plan. (the current running version is based off of
u-boot v2015.07 -- i have no freedom to change that.)
the newer u-boot will do nothing more than add a couple commands
("mii" and "mdio"), and i've already tweaked the configuration to
add those commands to the configuration, compiled and verified that
those commands are now listed in the u-boot.map file, so that part
seems fine.
at this point, i've been told that there is a proprietary pre-boot
loader in ROM which, among other things, loads u-boot from flash
into RAM and jumps to that address -- i assume, at that point, i
just need to download my new u-boot binary from the server to
some address in RAM currently *not* occupied by u-boot, and "go"
to that new address.
my only question is, what do i change in the configuration to
identify where i will load the enhanced u-boot? i vaguely recall
that i need to change the text base, and load the new binary at
precisely that address, is that correct?
finally (as an aside), i've read a number of pieces online
that describe how the second u-boot should try to avoid doing
low-level H/W initialization that the first has already done,
but for now, i'm just going to assume idempotency for all of
that early initialization unless proven wrong.
so ... what must i change in the config to support loading
the new version of u-boot at a different address? thanks.
rday
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] pico-imx6ul, pico-imx7d: Enable USB and PXE boot support
On Tue, Sep 25, 2018 at 11:41 AM, Otavio Salvador wrote: > #include > diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h > index 614be99d93..2bc42a04a0 100644 > --- a/include/configs/pico-imx7d.h > +++ b/include/configs/pico-imx7d.h > @@ -92,6 +92,8 @@ > > #define BOOT_TARGET_DEVICES(func) \ > func(MMC, mmc, 0) \ > + func(USB, usb, 0) \ We still need to add USB host suport for this board, but this can be done in a separate patch: Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] pci: Support parsing PCI controller DT subnodes
Hi Marek,
On Sat, Sep 22, 2018 at 7:00 AM Marek Vasut wrote:
>
> The PCI controller can have DT subnodes describing extra properties
> of particular PCI devices, ie. a PHY attached to an EHCI controller
> on a PCI bus. This patch parses those DT subnodes and assigns a node
> to the PCI device instance, so that the driver can extract details
> from that node and ie. configure the PHY using the PHY subsystem.
>
> Signed-off-by: Marek Vasut
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> drivers/pci/pci-uclass.c | 30 +++---
> 1 file changed, 27 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index de523a76ad..e274632428 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -90,6 +90,25 @@ int pci_get_ff(enum pci_size_t size)
> }
> }
>
> +static void pci_dev_find_ofnode(struct udevice *bus, phys_addr_t bdf,
> + ofnode *rnode)
> +{
> + ofnode node;
> +
> + dev_for_each_subnode(node, bus) {
> + phys_addr_t df, size;
> + df = ofnode_get_addr_size(node, "reg", &size);
Using API ofnode_get_addr_size() is wrong. It cannot handle
PCI-specific address formats. I understand why you added "0x8000 0
0x 0x8000 0 0x2000" to the bus ranges property in patch 5,
is to make ofnode_get_addr_size() work, but that's the wrong approach.
The correct API should be ofnode_read_pci_addr(). To call it like
this:
ret = ofnode_read_pci_addr(node, FDT_PCI_SPACE_CONFIG, "reg", &addr);
if (!ret)
df = addr.phys_hi & 0xff00;
> + if (df == FDT_ADDR_T_NONE)
> + continue;
> +
> + if (PCI_MASK_BUS(df) != PCI_MASK_BUS(bdf))
> + continue;
> +
> + *rnode = node;
> + break;
> + }
> +};
> +
> int pci_bus_find_devfn(struct udevice *bus, pci_dev_t find_devfn,
>struct udevice **devp)
> {
> @@ -641,6 +660,7 @@ static int pci_find_and_bind_driver(struct udevice
> *parent,
> pci_dev_t bdf, struct udevice **devp)
> {
> struct pci_driver_entry *start, *entry;
> + ofnode node = ofnode_null();
> const char *drv;
> int n_ents;
> int ret;
> @@ -651,6 +671,10 @@ static int pci_find_and_bind_driver(struct udevice
> *parent,
>
> debug("%s: Searching for driver: vendor=%x, device=%x\n", __func__,
> find_id->vendor, find_id->device);
> +
> + /* Determine optional OF node */
> + pci_dev_find_ofnode(parent, bdf, &node);
> +
> start = ll_entry_start(struct pci_driver_entry, pci_driver_entry);
> n_ents = ll_entry_count(struct pci_driver_entry, pci_driver_entry);
> for (entry = start; entry != start + n_ents; entry++) {
> @@ -684,8 +708,8 @@ static int pci_find_and_bind_driver(struct udevice
> *parent,
> * find another driver. For now this doesn't seem
> * necesssary, so just bind the first match.
> */
> - ret = device_bind(parent, drv, drv->name, NULL, -1,
> - &dev);
> + ret = device_bind_ofnode(parent, drv, drv->name, NULL,
> +node, &dev);
> if (ret)
> goto error;
> debug("%s: Match found: %s\n", __func__, drv->name);
> @@ -712,7 +736,7 @@ static int pci_find_and_bind_driver(struct udevice
> *parent,
> return -ENOMEM;
> drv = bridge ? "pci_bridge_drv" : "pci_generic_drv";
>
> - ret = device_bind_driver(parent, drv, str, devp);
> + ret = device_bind_driver_to_node(parent, drv, str, node, devp);
> if (ret) {
> debug("%s: Failed to bind generic driver: %d\n", __func__,
> ret);
> free(str);
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] test: Add test for PCI device without compat string and with DT node
On Sat, Sep 22, 2018 at 7:02 AM Marek Vasut wrote: > > Add test which checks if a PCI device described in DT with an > entry and reg = <...> property, but without compatible string > results in a valid U-Boot PCI udevice with the udevice.node > populated with reference to this DT node. Also check if the > other PCI device without a DT node does not contain any bogus > udevice.node. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > --- > test/dm/pci.c | 5 + > 1 file changed, 5 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] test: Add PCI device entry without compat string and with DT node
Hi Marek,
On Sat, Sep 22, 2018 at 7:02 AM Marek Vasut wrote:
>
> Add PCI entry without compatible string and with a DT node only with
> reg = <...> property into the DT. This is needed for the tests to
> verify whether such a setup creates an U-Boot PCI device with the
> DT node associated with it in udevice.node.
>
> Signed-off-by: Marek Vasut
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> arch/sandbox/dts/test.dts | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index b8524e3b7d..c13a270c2e 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -354,9 +354,14 @@
> #address-cells = <3>;
> #size-cells = <2>;
> ranges = <0x0200 0 0x3000 0x3000 0 0x2000
> - 0x0100 0 0x4000 0x4000 0 0x2000>;
> + 0x0100 0 0x4000 0x4000 0 0x2000
> + 0x8000 0 0x 0x8000 0 0x2000>;
Adding this line makes no sense. You can't translate a PCI bus
configuration space address (0x8000) to something in its parent bus's
(MMIO) address space. See my related comments in patch 1 and 3.
> sandbox,dev-info = <0x08 0x00 0x1234 0x5678
> - 0x0c 0x00 0x1234 0x5678>;
> + 0x0c 0x00 0x1234 0x5678
> + 0x10 0x00 0x1234 0x5678>;
> + pci@10,0 {
> + reg = <0x8000 0 0 0 0>;
> + };
> };
>
> pci2: pci-controller2 {
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] pci: Update documentation to make 'compatible' string optional
On Sat, Sep 22, 2018 at 7:02 AM Marek Vasut wrote: > > Reword the documentation to make it clear the compatible string is now > optional, yet still matching on it takes precedence over PCI IDs and > PCI classes. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > --- > doc/driver-model/pci-info.txt | 14 +- > 1 file changed, 9 insertions(+), 5 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] pci: Check ops before using them for config space access
Hi Marek, On Sat, Sep 22, 2018 at 7:00 AM Marek Vasut wrote: > > The code fails to check if ops is non-NULL before using it's members. > Add the missing check and while at it, flip the condition to make it > more obvious what is actually happening. > Though adding the NULL pointer check makes the codes more robust, I would like to know with what calling sequence current codes are broken? I did a grep and looks every PCI controller driver registers a non-NULL dm_pci_ops so the ops can't be NULL, which means adding the check seems unnecessary. > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > --- > drivers/pci/pci-uclass.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c > index eb118f3496..de523a76ad 100644 > --- a/drivers/pci/pci-uclass.c > +++ b/drivers/pci/pci-uclass.c > @@ -241,9 +241,9 @@ int pci_bus_write_config(struct udevice *bus, pci_dev_t > bdf, int offset, > struct dm_pci_ops *ops; > > ops = pci_get_ops(bus); > - if (!ops->write_config) > - return -ENOSYS; > - return ops->write_config(bus, bdf, offset, value, size); > + if (ops && ops->write_config) > + return ops->write_config(bus, bdf, offset, value, size); > + return -ENOSYS; > } > > int pci_bus_clrset_config32(struct udevice *bus, pci_dev_t bdf, int offset, > @@ -321,9 +321,9 @@ int pci_bus_read_config(struct udevice *bus, pci_dev_t > bdf, int offset, > struct dm_pci_ops *ops; > > ops = pci_get_ops(bus); > - if (!ops->read_config) > - return -ENOSYS; > - return ops->read_config(bus, bdf, offset, valuep, size); > + if (ops && ops->read_config) > + return ops->read_config(bus, bdf, offset, valuep, size); > + return -ENOSYS; > } > > int pci_read_config(pci_dev_t bdf, int offset, unsigned long *valuep, > -- Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ofnode: Add missing address translation into ofnode_get_addr_size()
Hi Marek,
On Sat, Sep 22, 2018 at 6:59 AM Marek Vasut wrote:
>
> Of CONFIG_OF_TRANSLATE is enabled, this function still returns
> untranslated bogus results. Add the missing translation.
>
> Signed-off-by: Marek Vasut
> Cc: Simon Glass
> Cc: Tom Rini
> ---
> drivers/core/ofnode.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> index a7e1927723..035023ca91 100644
> --- a/drivers/core/ofnode.c
> +++ b/drivers/core/ofnode.c
> @@ -542,8 +542,15 @@ fdt_addr_t ofnode_get_addr_size(ofnode node, const char
> *property,
> return FDT_ADDR_T_NONE;
> na = of_n_addr_cells(np);
> ns = of_n_addr_cells(np);
There is an unrelated bug. It should be:
ns = of_n_size_cells(np);
> +
> *sizep = of_read_number(prop + na, ns);
> - return of_read_number(prop, na);
> +
> + if (IS_ENABLED(CONFIG_OF_TRANSLATE) && ns > 0) {
> + return of_translate_address(ofnode_to_np(node), prop);
Just use np instead of ofnode_to_np(node)
> + } else {
> + na = of_n_addr_cells(ofnode_to_np(node));
This line is unnecessary.
> + return of_read_number(prop, na);
> + }
> } else {
> return fdtdec_get_addr_size(gd->fdt_blob,
> ofnode_to_offset(node), property,
> --
However, I have to point out that this patch (along with the unrelated
bug I pointed out above) is not related to "support parsing PCI
controller DT subnodes". Both of_translate_address() and
of_read_number() are not designed to handle PCI-specific address
formats. See my comments in patch 3 and 5.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] MSCC: add support for VCoreIII SoCs
These families of SoCs are found in the Microsemi Switches solution. Currently the support for two families support is added: - Ocelot (VSC7513, VSC7514) already supported in Linux - Luton (Luton10: VSC7423, VSC7424, VSC7428 and Luton26: VSC7425, VSC7426, VSC7426, VSC7427, VSC7429) Signed-off-by: Gregory CLEMENT --- Hi, Actually this is the second version of this patch. Compared to the previous version which did not reach the mailing list, I remove a lot of unused defines in the header. They can be add later when needed. Sorry for the noise Gregory arch/mips/Kconfig | 6 + arch/mips/Makefile| 1 + arch/mips/mach-mscc/Kconfig | 101 +++ arch/mips/mach-mscc/Makefile | 6 + arch/mips/mach-mscc/cpu.c | 72 ++ arch/mips/mach-mscc/dram.c| 62 ++ arch/mips/mach-mscc/include/ioremap.h | 49 ++ arch/mips/mach-mscc/include/mach/cache.h | 36 + arch/mips/mach-mscc/include/mach/common.h | 31 + arch/mips/mach-mscc/include/mach/ddr.h| 753 ++ .../mips/mach-mscc/include/mach/luton/luton.h | 37 + .../include/mach/luton/luton_devcpu_gcb.h | 16 + .../include/mach/luton/luton_icpu_cfg.h | 247 ++ .../mach-mscc/include/mach/ocelot/ocelot.h| 35 + .../include/mach/ocelot/ocelot_devcpu_gcb.h | 49 ++ .../include/mach/ocelot/ocelot_icpu_cfg.h | 278 +++ arch/mips/mach-mscc/include/mach/tlb.h| 65 ++ arch/mips/mach-mscc/lowlevel_init.S | 29 + arch/mips/mach-mscc/lowlevel_init_luton.S | 63 ++ arch/mips/mach-mscc/reset.c | 37 + 20 files changed, 1973 insertions(+) create mode 100644 arch/mips/mach-mscc/Kconfig create mode 100644 arch/mips/mach-mscc/Makefile create mode 100644 arch/mips/mach-mscc/cpu.c create mode 100644 arch/mips/mach-mscc/dram.c create mode 100644 arch/mips/mach-mscc/include/ioremap.h create mode 100644 arch/mips/mach-mscc/include/mach/cache.h create mode 100644 arch/mips/mach-mscc/include/mach/common.h create mode 100644 arch/mips/mach-mscc/include/mach/ddr.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/tlb.h create mode 100644 arch/mips/mach-mscc/lowlevel_init.S create mode 100644 arch/mips/mach-mscc/lowlevel_init_luton.S create mode 100644 arch/mips/mach-mscc/reset.c diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 6e5e0ffe65..c4fc3d077b 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -58,6 +58,11 @@ config ARCH_ATH79 select OF_CONTROL imply CMD_DM +config ARCH_MSCC + bool "Support MSCC VCore-III" + select OF_CONTROL + select DM + config ARCH_BMIPS bool "Support BMIPS SoCs" select CLK @@ -118,6 +123,7 @@ source "board/imgtec/xilfpga/Kconfig" source "board/micronas/vct/Kconfig" source "board/qemu-mips/Kconfig" source "arch/mips/mach-ath79/Kconfig" +source "arch/mips/mach-mscc/Kconfig" source "arch/mips/mach-bmips/Kconfig" source "arch/mips/mach-pic32/Kconfig" diff --git a/arch/mips/Makefile b/arch/mips/Makefile index a36f5f1fb6..acb1340942 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -14,6 +14,7 @@ libs-y += arch/mips/lib/ machine-$(CONFIG_ARCH_ATH79) += ath79 machine-$(CONFIG_ARCH_BMIPS) += bmips machine-$(CONFIG_MACH_PIC32) += pic32 +machine-$(CONFIG_ARCH_MSCC) += mscc machdirs := $(patsubst %,arch/mips/mach-%/,$(machine-y)) libs-y += $(machdirs) diff --git a/arch/mips/mach-mscc/Kconfig b/arch/mips/mach-mscc/Kconfig new file mode 100644 index 00..20148bfe15 --- /dev/null +++ b/arch/mips/mach-mscc/Kconfig @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +if ARCH_MSCC + +config SYS_DCACHE_SIZE + default 32768 + +config SYS_DCACHE_LINE_SIZE + default 32 + +config SYS_ICACHE_SIZE + default 32768 + +config SYS_ICACHE_LINE_SIZE + default 32 + +endif + +menu "MSCC VCore-III platforms" + depends on ARCH_MSCC + +config SOC_VCOREIII + select SUPPORTS_LITTLE_ENDIAN + select SUPPORTS_BIG_ENDIAN + select SUPPORTS_CPU_MIPS32_R1 + select SUPPORTS_CPU_MIPS32_R2 + select ROM_EXCEPTION_VECTORS + select MIPS_TUNE_24KC + bool + +config SYS_SOC + default "mscc" + +config SOC_OCELOT + bool + select SOC_VCOREIII + help + This supports MSCC Ocelot family of SOCs. + +config SOC_LUTON + bool + select SOC_VCOREIII + help + This supports MSCC Luton famil
Re: [U-Boot] [PATCH 0/6] Add support for VCore III SoCs found in Microsemi switches
Hi, On mar., sept. 25 2018, Gregory CLEMENT wrote: > Hello, > > This series add the support of 2 SoCs: Ocelot and Luton from > Microsemi. Both of them belongs to the same family Vcore III. > > We found them on various advanced switches product. > > The support for Ocelot already have been submit to Linux, but not yet > the Luton support. > > Besides this series 3 others patches are needed but they are driver > related: > DW SPI: Allow to overload the management of the external CS > gpio: mscc-bitbang-spi: Add a simple gpio driver for bitbgang spi > pinctrl: mscc: Add gpio and pinctrl driver for MSCC MIPS SoCs (VcoreIII based) > > They will be submitted separately. > > Thanks, > > Gregory > > > Gregory CLEMENT (6): > MIPS: move create_tlb() in an proper header: mipsregs.h > MSCC: add support for VCoreIII SoCs This patch didn't reach the mailing because it was too large. Actually, many defined were not used, so I removed then, and I am going to send the missing patch now. Gregory > MSCC: add board support for the VCoreIII based evaluation boards > MSCC: add device tree for Ocelot and Luton (boards and SoCs) > MSCC: add configuration for Ocelot and Luton based boards > MIPS: bootm: Add support for Vcore III linux kernel > > arch/mips/Kconfig | 6 + > arch/mips/Makefile| 1 + > arch/mips/cpu/cpu.c | 10 - > arch/mips/dts/luton_pcb091.dts| 36 + > arch/mips/dts/mscc,luton.dtsi | 87 ++ > arch/mips/dts/mscc,ocelot.dtsi| 132 +++ > arch/mips/dts/mscc,ocelot_pcb.dtsi| 37 + > arch/mips/dts/ocelot_pcb120.dts | 12 + > arch/mips/dts/ocelot_pcb123.dts | 12 + > arch/mips/include/asm/mipsregs.h | 11 + > arch/mips/lib/bootm.c | 62 +- > arch/mips/mach-mscc/Kconfig | 101 ++ > arch/mips/mach-mscc/Makefile | 6 + > arch/mips/mach-mscc/cpu.c | 72 ++ > arch/mips/mach-mscc/dram.c| 62 ++ > arch/mips/mach-mscc/include/ioremap.h | 49 + > arch/mips/mach-mscc/include/mach/cache.h | 36 + > arch/mips/mach-mscc/include/mach/common.h | 31 + > arch/mips/mach-mscc/include/mach/ddr.h| 753 +++ > .../mips/mach-mscc/include/mach/luton/luton.h | 37 + > .../include/mach/luton/luton_devcpu_gcb.h | 16 + > .../include/mach/luton/luton_icpu_cfg-ref.h | 884 ++ > .../include/mach/luton/luton_icpu_cfg.h | 247 + > .../mach-mscc/include/mach/ocelot/ocelot.h| 35 + > .../include/mach/ocelot/ocelot_devcpu_gcb.h | 353 +++ > .../include/mach/ocelot/ocelot_icpu_cfg.h | 884 ++ > arch/mips/mach-mscc/include/mach/tlb.h| 65 ++ > arch/mips/mach-mscc/lowlevel_init.S | 29 + > arch/mips/mach-mscc/lowlevel_init_luton.S | 63 ++ > arch/mips/mach-mscc/reset.c | 37 + > board/mscc/common/board.c | 29 + > board/mscc/luton/Kconfig | 14 + > board/mscc/luton/Makefile | 4 + > board/mscc/luton/luton.c | 14 + > board/mscc/ocelot/Kconfig | 24 + > board/mscc/ocelot/Makefile| 5 + > board/mscc/ocelot/ocelot.c| 38 + > configs/mscc_luton_defconfig | 66 ++ > configs/mscc_ocelot_defconfig | 57 ++ > configs/mscc_ocelot_pcb120_defconfig | 56 ++ > include/configs/vcoreiii.h| 72 ++ > 41 files changed, 4515 insertions(+), 30 deletions(-) > create mode 100644 arch/mips/dts/luton_pcb091.dts > create mode 100644 arch/mips/dts/mscc,luton.dtsi > create mode 100644 arch/mips/dts/mscc,ocelot.dtsi > create mode 100644 arch/mips/dts/mscc,ocelot_pcb.dtsi > create mode 100644 arch/mips/dts/ocelot_pcb120.dts > create mode 100644 arch/mips/dts/ocelot_pcb123.dts > create mode 100644 arch/mips/mach-mscc/Kconfig > create mode 100644 arch/mips/mach-mscc/Makefile > create mode 100644 arch/mips/mach-mscc/cpu.c > create mode 100644 arch/mips/mach-mscc/dram.c > create mode 100644 arch/mips/mach-mscc/include/ioremap.h > create mode 100644 arch/mips/mach-mscc/include/mach/cache.h > create mode 100644 arch/mips/mach-mscc/include/mach/common.h > create mode 100644 arch/mips/mach-mscc/include/mach/ddr.h > create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton.h > create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_devcpu_gcb.h > create mode 100644 > arch/mips/mach-mscc/include/mach/luton/luton_icpu_cfg-ref.h > create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_icpu_cfg.h > create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot.h > create mode 100644 > arch/mips/mach-mscc/include/mach/ocelot/ocelot_devcpu_gcb.h > create mode 100644 arch/mips/mach-
Re: [U-Boot] [PATCH] DW SPI: Allow to overload the management of the external CS
Hi,
On 25/09/2018 15:17:31+0200, Gregory CLEMENT wrote:
> On some platforms, as the Ocelot ones, when wanting to control the CS
> through software, it is not possible to do it through the GPIO
> controller. Indeed, this signal is managed through a dedicated range of
> registers inside the SoC..
>
> By declaring the external_cs_manage function as weak, it is possible to
> manage the CS at platform level and then using the appropriate registers.
>
> Signed-off-by: Gregory CLEMENT
> ---
> drivers/spi/designware_spi.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
> index d8b73ea326..fe6e753bff 100644
> --- a/drivers/spi/designware_spi.c
> +++ b/drivers/spi/designware_spi.c
> @@ -334,7 +334,13 @@ static int poll_transfer(struct dw_spi_priv *priv)
> return 0;
> }
>
> -static void external_cs_manage(struct udevice *dev, bool on)
> +/*
> + * We define external_cs_manage function as 'weak' as some targets
> + * (like OCELOT) don't control the external CS pin using a GPIO
MSCC Ocelot maybe?
> + * controller. These SoCs use specific registers to controll by
^ control
> + * software the SPI pins (and especially the CS).
> + */
> +__weak void external_cs_manage(struct udevice *dev, bool on)
> {
> #if defined(CONFIG_DM_GPIO) && !defined(CONFIG_SPL_BUILD)
> struct dw_spi_priv *priv = dev_get_priv(dev->parent);
> --
> 2.19.0
>
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: phy: add TSE PCS support to dwmac-socfpga
On 09/25/2018 01:24 AM, Ooi, Joyce wrote: > This adds support for TSE PCS that uses SGMII adapter when the > phy-mode in device tree is set to sgmii. Can you add a bit more description to your commit message? TSE(Triple Speed Ethernet), but what is PCS? > > Signed-off-by: Ooi, Joyce > --- > drivers/net/Makefile | 3 +- > drivers/net/designware.c | 5 ++ > drivers/net/designware.h | 1 + > drivers/net/dwmac_socfpga.c| 121 + > drivers/net/phy/altr_tse_pcs.c | 197 > + > drivers/net/phy/altr_tse_pcs.h | 59 > 6 files changed, 385 insertions(+), 1 deletion(-) > create mode 100644 drivers/net/phy/altr_tse_pcs.c > create mode 100644 drivers/net/phy/altr_tse_pcs.h > > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index 48a2878..c2333b5 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -14,7 +14,7 @@ obj-$(CONFIG_CALXEDA_XGMAC) += calxedaxgmac.o > obj-$(CONFIG_CS8900) += cs8900.o > obj-$(CONFIG_TULIP) += dc2114x.o > obj-$(CONFIG_ETH_DESIGNWARE) += designware.o > -obj-$(CONFIG_ETH_DESIGNWARE_SOCFPGA) += dwmac_socfpga.o > +obj-$(CONFIG_ETH_DESIGNWARE_SOCFPGA) += dwmac-socfpga.o Huh? What's this change for? Also, I'm getting these compile errors against the latest U-Boot, top commit = "284b27cf81da10d55 Merge branch 'master' of git://git.denx.de/u-boot-mips" : drivers/net/dwmac_socfpga.c: In function ‘socfpga_dw_tse_pcs_init’: drivers/net/dwmac_socfpga.c:67:9: warning: implicit declaration of function ‘mbox_get_fpga_config_status’ [-Wimplicit-function-declaration] ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS); ^~~ LD common/built-in.o LD drivers/net/dwmac-socfpga.o LD drivers/net/built-in.o LD cmd/built-in.o CC lib/smbios.o CC lib/display_options.o CC lib/efi_loader/efi_reloc.o CC lib/efi_loader/helloworld.o LD lib/efi_loader/helloworld_efi.so OBJCOPY lib/efi_loader/helloworld.efi rm lib/efi_loader/helloworld_efi.so lib/efi_loader/helloworld.o LD lib/built-in.o LD u-boot drivers/net/built-in.o: In function `dwmac_socfpga_ofdata_to_platdata': /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:170: undefined reference to `syscon_node_to_regmap' /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:177: undefined reference to `regmap_get_range' drivers/net/built-in.o: In function `socfpga_dw_tse_pcs_init': /home/dinguyen/linux_dev/u-boot/drivers/net/dwmac_socfpga.c:67: undefined reference to `mbox_get_fpga_config_status' In the future, please test before submitting patches. Thanks, Dinh ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 19/19] Kconfig: sandbox: enable cmd_avb and dependencies
Enables cmd_avb and its dependencies need to run the AVB tests. Reviewed-by: Simon Glass Signed-off-by: Jens Wiklander --- arch/Kconfig | 4 drivers/fastboot/Kconfig | 2 ++ 2 files changed, 6 insertions(+) diff --git a/arch/Kconfig b/arch/Kconfig index 8f10f3fc06e8..543362578f50 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -92,6 +92,10 @@ config SANDBOX imply LZMA imply SCSI imply TEE + imply AVB_VERIFY + imply LIBAVB + imply CMD_AVB + imply UDP_FUNCTION_FASTBOOT config SH bool "SuperH architecture" diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig index bc25ea1d9c7a..d63ecdd27e4b 100644 --- a/drivers/fastboot/Kconfig +++ b/drivers/fastboot/Kconfig @@ -35,6 +35,7 @@ config FASTBOOT_BUF_ADDR ROCKCHIP_RK3399 default 0x28 if ROCKCHIP_RK3368 default 0x10 if ARCH_ZYNQMP + default 0 if SANDBOX help The fastboot protocol requires a large memory buffer for downloads. Define this to the starting RAM address to use for @@ -45,6 +46,7 @@ config FASTBOOT_BUF_SIZE default 0x800 if ARCH_ROCKCHIP default 0x600 if ARCH_ZYNQMP default 0x200 if ARCH_SUNXI + default 0x8192 if SANDBOX default 0x700 help The fastboot protocol requires a large memory buffer for -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] pico-imx6ul, pico-imx7d: Use eMMC user partition by default
After discussing with TechNexion about how its default setting, it is better to install on the eMMC user partition by default, when using DFU, so it works out of box for majority of users. Reviewed-by: Fabio Estevam Signed-off-by: Otavio Salvador --- Changes in v2: None include/configs/pico-imx6ul.h | 4 ++-- include/configs/pico-imx7d.h | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h index 3d93205535..0fea2d65dd 100644 --- a/include/configs/pico-imx6ul.h +++ b/include/configs/pico-imx6ul.h @@ -56,8 +56,8 @@ #define CONFIG_DFU_ENV_SETTINGS \ "dfu_alt_info=" \ - "spl raw 0x2 0x400 mmcpart 1;" \ - "u-boot raw 0x8a 0x400 mmcpart 1;" \ + "spl raw 0x2 0x400;" \ + "u-boot raw 0x8a 0x400;" \ "/boot/zImage ext4 0 1;" \ "/boot/imx6ul-pico-hobbit.dtb ext4 0 1;" \ "/boot/imx6ul-pico-pi.dtb ext4 0 1;" \ diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h index 0e770bf41f..614be99d93 100644 --- a/include/configs/pico-imx7d.h +++ b/include/configs/pico-imx7d.h @@ -45,8 +45,8 @@ #define CONFIG_DFU_ENV_SETTINGS \ "dfu_alt_info=" \ - "spl raw 0x2 0x400 mmcpart 1;" \ - "u-boot raw 0x8a 0x400 mmcpart 1;" \ + "spl raw 0x2 0x400;" \ + "u-boot raw 0x8a 0x400;" \ "/boot/zImage ext4 0 1;" \ "/boot/imx7d-pico-hobbit.dtb ext4 0 1;" \ "/boot/imx7d-pico-pi.dtb ext4 0 1;" \ -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 17/19] test_avb: Update pymark.buildconfigspec information for the AVB tests
Update the pymark.buildconfigspec to depend on 'cmd_mmc' in addition to
'cmd_avb' for those tests that needs more a more complete MMC
implementation or the "mmc" command.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
test/py/tests/test_avb.py | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index 7996e4845db3..9683fd80d074 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -23,7 +23,7 @@ mmc_dev = 1
temp_addr = 0x9000
temp_addr2 = 0x90002000
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
def test_avb_verify(u_boot_console):
"""Run AVB 2.0 boot verification chain with avb subset of commands
"""
@@ -36,7 +36,7 @@ def test_avb_verify(u_boot_console):
assert response.find(success_str)
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
def test_avb_mmc_uuid(u_boot_console):
"""Check if 'avb get_uuid' works, compare results with
'part list mmc 1' output
@@ -78,6 +78,7 @@ def test_avb_read_rb(u_boot_console):
assert response == ''
response = u_boot_console.run_command('avb read_rb 1')
+assert response == 'Rollback index: 0'
@pytest.mark.buildconfigspec('cmd_avb')
@@ -89,9 +90,10 @@ def test_avb_is_unlocked(u_boot_console):
assert response == ''
response = u_boot_console.run_command('avb is_unlocked')
+assert response == 'Unlocked = 1'
-@pytest.mark.buildconfigspec('cmd_avb')
+@pytest.mark.buildconfigspec('cmd_avb', 'cmd_mmc')
def test_avb_mmc_read(u_boot_console):
"""Test mmc read operation
"""
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] pico-imx6ul, pico-imx7d: Enable USB and PXE boot support
This allow the use of a USB storage or PXE network booting as fallback, allowing for example for manufacturing installation of eMMC storage in an easy way. Signed-off-by: Otavio Salvador --- Changes in v2: - improve commit log (fabio) include/configs/pico-imx6ul.h | 2 ++ include/configs/pico-imx7d.h | 2 ++ 2 files changed, 4 insertions(+) diff --git a/include/configs/pico-imx6ul.h b/include/configs/pico-imx6ul.h index 0fea2d65dd..8082b74c9c 100644 --- a/include/configs/pico-imx6ul.h +++ b/include/configs/pico-imx6ul.h @@ -103,6 +103,8 @@ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ func(DHCP, dhcp, na) #include diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h index 614be99d93..2bc42a04a0 100644 --- a/include/configs/pico-imx7d.h +++ b/include/configs/pico-imx7d.h @@ -92,6 +92,8 @@ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ + func(USB, usb, 0) \ + func(PXE, pxe, na) \ func(DHCP, dhcp, na) #include -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 15/19] test: tee: test TEE uclass
Tests the TEE uclass with a sandbox tee driver.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
test/dm/Makefile | 1 +
test/dm/tee.c| 98
2 files changed, 99 insertions(+)
create mode 100644 test/dm/tee.c
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 67c1fe6d0142..b1eedf4a6ee2 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -46,4 +46,5 @@ obj-$(CONFIG_SPMI) += spmi.o
obj-$(CONFIG_WDT) += wdt.o
obj-$(CONFIG_AXI) += axi.o
obj-$(CONFIG_MISC) += misc.o
+obj-$(CONFIG_TEE) += tee.o
endif
diff --git a/test/dm/tee.c b/test/dm/tee.c
new file mode 100644
index ..ab1c7da9d2d3
--- /dev/null
+++ b/test/dm/tee.c
@@ -0,0 +1,98 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int open_session(struct udevice *dev, u32 *session)
+{
+ struct tee_open_session_arg arg;
+ const struct tee_optee_ta_uuid uuid = TA_AVB_UUID;
+ int rc;
+
+ memset(&arg, 0, sizeof(arg));
+ tee_optee_ta_uuid_to_octets(arg.uuid, &uuid);
+ rc = tee_open_session(dev, &arg, 0, NULL);
+ if (rc)
+ return rc;
+ if (arg.ret)
+ return -EIO;
+ *session = arg.session;
+
+ return 0;
+}
+
+static int invoke_func(struct udevice *dev, u32 session)
+{
+ struct tee_param param = { .attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT };
+ struct tee_invoke_arg arg;
+
+ memset(&arg, 0, sizeof(arg));
+ arg.session = session;
+ arg.func = TA_AVB_CMD_READ_LOCK_STATE;
+
+ if (tee_invoke_func(dev, &arg, 1, ¶m) || arg.ret)
+ return -1;
+
+ return 0;
+}
+
+static int match(struct tee_version_data *vers, const void *data)
+{
+ return vers->gen_caps & TEE_GEN_CAP_GP;
+}
+
+static int dm_test_tee(struct unit_test_state *uts)
+{
+ struct tee_version_data vers;
+ struct udevice *dev;
+ struct sandbox_tee_state *state;
+ u32 session;
+ int rc;
+ u8 data[128];
+ struct tee_shm *reg_shm;
+ struct tee_shm *alloc_shm;
+
+ dev = tee_find_device(NULL, match, NULL, &vers);
+ ut_assert(dev);
+ state = dev_get_priv(dev);
+ ut_assert(!state->session);
+
+ rc = open_session(dev, &session);
+ ut_assert(!rc);
+ ut_assert(session == state->session);
+
+ rc = invoke_func(dev, session);
+ ut_assert(!rc);
+
+ rc = tee_close_session(dev, session);
+ ut_assert(!rc);
+ ut_assert(!state->session);
+
+ ut_assert(!state->num_shms);
+ rc = tee_shm_register(dev, data, sizeof(data), 0, ®_shm);
+ ut_assert(!rc);
+ ut_assert(state->num_shms == 1);
+
+ rc = tee_shm_alloc(dev, 256, 0, &alloc_shm);
+ ut_assert(!rc);
+ ut_assert(state->num_shms == 2);
+
+ ut_assert(tee_shm_is_registered(reg_shm, dev));
+ ut_assert(tee_shm_is_registered(alloc_shm, dev));
+
+ tee_shm_free(reg_shm);
+ tee_shm_free(alloc_shm);
+ ut_assert(!state->num_shms);
+
+ return 0;
+}
+
+DM_TEST(dm_test_tee, DM_TESTF_SCAN_FDT);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 16/19] avb_verify: support using OP-TEE TA AVB
With CONFIG_OPTEE_TA_AVB use the trusted application AVB provided by
OP-TEE to manage rollback indexes and device-lock status.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
common/avb_verify.c | 118 ++-
doc/README.avb2 | 13 +
include/avb_verify.h | 4 ++
3 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/common/avb_verify.c b/common/avb_verify.c
index f8c6ae5566ae..a8c5a3e7db36 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -10,6 +10,8 @@
#include
#include
#include
+#include
+#include
static const unsigned char avb_root_pub[1032] = {
0x0, 0x0, 0x10, 0x0, 0x55, 0xd9, 0x4, 0xad, 0xd8, 0x4,
@@ -600,6 +602,65 @@ static AvbIOResult validate_vbmeta_public_key(AvbOps *ops,
return AVB_IO_RESULT_OK;
}
+#ifdef CONFIG_OPTEE_TA_AVB
+static int get_open_session(struct AvbOpsData *ops_data)
+{
+ struct udevice *tee = NULL;
+
+ while (!ops_data->tee) {
+ const struct tee_optee_ta_uuid uuid = TA_AVB_UUID;
+ struct tee_open_session_arg arg;
+ int rc;
+
+ tee = tee_find_device(tee, NULL, NULL, NULL);
+ if (!tee)
+ return -ENODEV;
+
+ memset(&arg, 0, sizeof(arg));
+ tee_optee_ta_uuid_to_octets(arg.uuid, &uuid);
+ rc = tee_open_session(tee, &arg, 0, NULL);
+ if (!rc) {
+ ops_data->tee = tee;
+ ops_data->session = arg.session;
+ }
+ }
+
+ return 0;
+}
+
+static AvbIOResult invoke_func(struct AvbOpsData *ops_data, u32 func,
+ ulong num_param, struct tee_param *param)
+{
+ struct tee_invoke_arg arg;
+
+ if (get_open_session(ops_data))
+ return AVB_IO_RESULT_ERROR_IO;
+
+ memset(&arg, 0, sizeof(arg));
+ arg.func = func;
+ arg.session = ops_data->session;
+
+ if (tee_invoke_func(ops_data->tee, &arg, num_param, param))
+ return AVB_IO_RESULT_ERROR_IO;
+ switch (arg.ret) {
+ case TEE_SUCCESS:
+ return AVB_IO_RESULT_OK;
+ case TEE_ERROR_OUT_OF_MEMORY:
+ return AVB_IO_RESULT_ERROR_OOM;
+ case TEE_ERROR_TARGET_DEAD:
+ /*
+* The TA has paniced, close the session to reload the TA
+* for the next request.
+*/
+ tee_close_session(ops_data->tee, ops_data->session);
+ ops_data->tee = NULL;
+ return AVB_IO_RESULT_ERROR_IO;
+ default:
+ return AVB_IO_RESULT_ERROR_IO;
+ }
+}
+#endif
+
/**
* read_rollback_index() - gets the rollback index corresponding to the
* location of given by @out_rollback_index.
@@ -615,6 +676,7 @@ static AvbIOResult read_rollback_index(AvbOps *ops,
size_t rollback_index_slot,
u64 *out_rollback_index)
{
+#ifndef CONFIG_OPTEE_TA_AVB
/* For now we always return 0 as the stored rollback index. */
printf("%s not supported yet\n", __func__);
@@ -622,6 +684,27 @@ static AvbIOResult read_rollback_index(AvbOps *ops,
*out_rollback_index = 0;
return AVB_IO_RESULT_OK;
+#else
+ AvbIOResult rc;
+ struct tee_param param[2];
+
+ if (rollback_index_slot >= TA_AVB_MAX_ROLLBACK_LOCATIONS)
+ return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+
+ memset(param, 0, sizeof(param));
+ param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+ param[0].u.value.a = rollback_index_slot;
+ param[1].attr = TEE_PARAM_ATTR_TYPE_VALUE_OUTPUT;
+
+ rc = invoke_func(ops->user_data, TA_AVB_CMD_READ_ROLLBACK_INDEX,
+ARRAY_SIZE(param), param);
+ if (rc)
+ return rc;
+
+ *out_rollback_index = (u64)param[1].u.value.a << 32 |
+ (u32)param[1].u.value.b;
+ return AVB_IO_RESULT_OK;
+#endif
}
/**
@@ -639,10 +722,27 @@ static AvbIOResult write_rollback_index(AvbOps *ops,
size_t rollback_index_slot,
u64 rollback_index)
{
+#ifndef CONFIG_OPTEE_TA_AVB
/* For now this is a no-op. */
printf("%s not supported yet\n", __func__);
return AVB_IO_RESULT_OK;
+#else
+ struct tee_param param[2];
+
+ if (rollback_index_slot >= TA_AVB_MAX_ROLLBACK_LOCATIONS)
+ return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+
+ memset(param, 0, sizeof(param));
+ param[0].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+ param[0].u.value.a = rollback_index_slot;
+ param[1].attr = TEE_PARAM_ATTR_TYPE_VALUE_INPUT;
+ param[1].u.value.a = (u32)(rollback_index >> 32);
+ param[1].u.value.b = (u32)rollback_index;
+
+ return invoke_func(ops->user_data, TA_AVB_CMD_WRITE_RO
[U-Boot] [PATCH v4 18/19] avb_verify: support sandbox configuration
Change get_sector_buf() to use map_sysmem() to get a pointer to the
CONFIG_FASTBOOT_BUF_ADDR in memory.
Signed-off-by: Jens Wiklander
---
include/avb_verify.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/avb_verify.h b/include/avb_verify.h
index a532a2331aea..18278f829e41 100644
--- a/include/avb_verify.h
+++ b/include/avb_verify.h
@@ -9,6 +9,7 @@
#define _AVB_VERIFY_H
#include <../lib/libavb/libavb.h>
+#include
#include
#define AVB_MAX_ARGS 1024
@@ -76,7 +77,7 @@ static inline size_t get_sector_buf_size(void)
static inline void *get_sector_buf(void)
{
- return (void *)CONFIG_FASTBOOT_BUF_ADDR;
+ return map_sysmem(CONFIG_FASTBOOT_BUF_ADDR, CONFIG_FASTBOOT_BUF_SIZE);
}
static inline bool is_buf_unaligned(void *buffer)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 13/19] sandbox: imply CONFIG_TEE (TEE uclass)
Reviewed-by: Simon Glass Signed-off-by: Jens Wiklander --- arch/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/Kconfig b/arch/Kconfig index bf1b4a9afac6..8f10f3fc06e8 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -91,6 +91,7 @@ config SANDBOX imply HASH_VERIFY imply LZMA imply SCSI + imply TEE config SH bool "SuperH architecture" -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 12/19] sandbox: dt: add sandbox_tee node
Adds a sandbox_tee node to enable the sandbox tee driver in all the
sandbox dts files.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
arch/sandbox/dts/sandbox.dts | 4
arch/sandbox/dts/sandbox64.dts | 4
arch/sandbox/dts/test.dts | 4
3 files changed, 12 insertions(+)
diff --git a/arch/sandbox/dts/sandbox.dts b/arch/sandbox/dts/sandbox.dts
index 6ac37f1ed7be..af7f12aa5889 100644
--- a/arch/sandbox/dts/sandbox.dts
+++ b/arch/sandbox/dts/sandbox.dts
@@ -322,6 +322,10 @@
reg = <0x0 0x400>;
};
};
+
+ sandbox_tee {
+ compatible = "sandbox,tee";
+ };
};
#include "cros-ec-keyboard.dtsi"
diff --git a/arch/sandbox/dts/sandbox64.dts b/arch/sandbox/dts/sandbox64.dts
index 9e65d2fda3d3..0e32fdad9d81 100644
--- a/arch/sandbox/dts/sandbox64.dts
+++ b/arch/sandbox/dts/sandbox64.dts
@@ -311,6 +311,10 @@
};
};
};
+
+ sandbox_tee {
+ compatible = "sandbox,tee";
+ };
};
#include "cros-ec-keyboard.dtsi"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 366826333181..997f8f996f23 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -630,6 +630,10 @@
};
};
};
+
+ sandbox_tee {
+ compatible = "sandbox,tee";
+ };
};
#include "sandbox_pmic.dtsi"
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 11/19] tee: optee: support AVB trusted application
Adds configuration option OPTEE_TA_AVB and a header file describing the
interface to the Android Verified Boot 2.0 (AVB) trusted application
provided by OP-TEE.
Tested-by: Igor Opaniuk
Reviewed-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
MAINTAINERS| 1 +
drivers/tee/optee/Kconfig | 16 +
drivers/tee/tee-uclass.c | 24 +++
include/tee.h | 38 ++
include/tee/optee_ta_avb.h | 48 ++
5 files changed, 127 insertions(+)
create mode 100644 include/tee/optee_ta_avb.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 5b085ad3acd6..1c96ece8cc9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -590,6 +590,7 @@ M: Jens Wiklander
S: Maintained
F: drivers/tee/
F: include/tee.h
+F: include/tee/
UBI
M: Kyungmin Park
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index 7484e6fea114..dbfa7846a30f 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -9,3 +9,19 @@ config OPTEE
mechanism. This driver can request services from OP-TEE, but also
handle Remote Procedure Calls (RPC) from OP-TEE needed to
execute a service. For more information see: https://www.op-tee.org
+
+if OPTEE
+
+menu "OP-TEE options"
+
+config OPTEE_TA_AVB
+ bool "Support AVB TA"
+ default y
+ help
+ Enables support for the AVB Trusted Application (TA) in OP-TEE.
+ The TA can support the "avb" subcommands "read_rb", "write"rb"
+ and "is_unlocked".
+
+endmenu
+
+endif
diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
index 1bee54ebf4af..abb88c0fee53 100644
--- a/drivers/tee/tee-uclass.c
+++ b/drivers/tee/tee-uclass.c
@@ -207,3 +207,27 @@ UCLASS_DRIVER(tee) = {
.pre_probe = tee_pre_probe,
.pre_remove = tee_pre_remove,
};
+
+void tee_optee_ta_uuid_from_octets(struct tee_optee_ta_uuid *d,
+ const u8 s[TEE_UUID_LEN])
+{
+ d->time_low = ((u32)s[0] << 24) | ((u32)s[1] << 16) |
+ ((u32)s[2] << 8) | s[3],
+ d->time_mid = ((u32)s[4] << 8) | s[5];
+ d->time_hi_and_version = ((u32)s[6] << 8) | s[7];
+ memcpy(d->clock_seq_and_node, s + 8, sizeof(d->clock_seq_and_node));
+}
+
+void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
+const struct tee_optee_ta_uuid *s)
+{
+ d[0] = s->time_low >> 24;
+ d[1] = s->time_low >> 16;
+ d[2] = s->time_low >> 8;
+ d[3] = s->time_low;
+ d[4] = s->time_mid >> 8;
+ d[5] = s->time_mid;
+ d[6] = s->time_hi_and_version >> 8;
+ d[7] = s->time_hi_and_version;
+ memcpy(d + 8, s->clock_seq_and_node, sizeof(s->clock_seq_and_node));
+}
diff --git a/include/tee.h b/include/tee.h
index b86dbec257b4..98b1c9cc693a 100644
--- a/include/tee.h
+++ b/include/tee.h
@@ -49,6 +49,22 @@
#define TEE_ORIGIN_TRUSTED_APP 0x0004
struct udevice;
+
+/**
+ * struct tee_optee_ta_uuid - OP-TEE Trusted Application (TA) UUID format
+ *
+ * Used to identify an OP-TEE TA and define suitable to initialize structs
+ * of this format is distributed with the interface of the TA. The
+ * individual fields of this struct doesn't have any special meaning in
+ * OP-TEE. See RFC4122 for details on the format.
+ */
+struct tee_optee_ta_uuid {
+ u32 time_low;
+ u16 time_mid;
+ u16 time_hi_and_version;
+ u8 clock_seq_and_node[8];
+};
+
/**
* struct tee_shm - memory shared with the TEE
* @dev: The TEE device
@@ -333,4 +349,26 @@ int tee_close_session(struct udevice *dev, u32 session);
int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
uint num_param, struct tee_param *param);
+/**
+ * tee_optee_ta_uuid_from_octets() - Converts to struct tee_optee_ta_uuid
+ * @d: Destination struct
+ * @s: Source UUID octets
+ *
+ * Conversion to a struct tee_optee_ta_uuid represantion from binary octet
+ * representation.
+ */
+void tee_optee_ta_uuid_from_octets(struct tee_optee_ta_uuid *d,
+ const u8 s[TEE_UUID_LEN]);
+
+/**
+ * tee_optee_ta_uuid_to_octets() - Converts from struct tee_optee_ta_uuid
+ * @d: Destination UUID octets
+ * @s: Source struct
+ *
+ * Conversion from a struct tee_optee_ta_uuid represantion to binary octet
+ * representation.
+ */
+void tee_optee_ta_uuid_to_octets(u8 d[TEE_UUID_LEN],
+const struct tee_optee_ta_uuid *s);
+
#endif /* __TEE_H */
diff --git a/include/tee/optee_ta_avb.h b/include/tee/optee_ta_avb.h
new file mode 100644
index ..074386af19a1
--- /dev/null
+++ b/include/tee/optee_ta_avb.h
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+/* Copyright (c) 2018, Linaro Limited */
+
+#ifndef __TA_AVB_H
+#define __TA_AVB_H
+
+#define TA_AVB_UUID { 0x023f8f1a, 0x292a, 0x432b, \
+ { 0x8f, 0xc4, 0xde, 0x84, 0x71, 0x
[U-Boot] [PATCH v4 10/19] optee: support routing of rpmb data frames to mmc
Adds support in optee supplicant to route signed (MACed) RPMB frames
from OP-TEE Secure OS to MMC and vice versa to manipulate the RPMB
partition.
Tested-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
drivers/tee/optee/Makefile| 1 +
drivers/tee/optee/core.c | 8 ++
drivers/tee/optee/optee_private.h | 55 -
drivers/tee/optee/rpmb.c | 181 ++
drivers/tee/optee/supplicant.c| 3 +
5 files changed, 247 insertions(+), 1 deletion(-)
create mode 100644 drivers/tee/optee/rpmb.c
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
index 6148feb474a5..928d3f80027f 100644
--- a/drivers/tee/optee/Makefile
+++ b/drivers/tee/optee/Makefile
@@ -2,3 +2,4 @@
obj-y += core.o
obj-y += supplicant.o
+obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 726382da9bb8..7f870f2f735d 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -315,6 +315,13 @@ static u32 do_call_with_arg(struct udevice *dev, struct
optee_msg_arg *arg)
param.a3 = res.a3;
handle_rpc(dev, ¶m, &page_list);
} else {
+ /*
+* In case we've accessed RPMB to serve an RPC
+* request we need to restore the previously
+* selected partition as the caller may expect it
+* to remain unchanged.
+*/
+ optee_suppl_rpmb_release(dev);
return call_err_to_res(res.a0);
}
}
@@ -651,4 +658,5 @@ U_BOOT_DRIVER(optee) = {
.probe = optee_probe,
.ops = &optee_ops,
.platdata_auto_alloc_size = sizeof(struct optee_pdata),
+ .priv_auto_alloc_size = sizeof(struct optee_private),
};
diff --git a/drivers/tee/optee/optee_private.h
b/drivers/tee/optee/optee_private.h
index 35adb83afcc7..9442d1c176bc 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -6,7 +6,60 @@
#ifndef __OPTEE_PRIVATE_H
#define __OPTEE_PRIVATE_H
+#include
+#include
+
+/**
+ * struct optee_private - OP-TEE driver private data
+ * @rpmb_mmc: mmc device for the RPMB partition
+ * @rpmb_dev_id: mmc device id matching @rpmb_mmc
+ * @rpmb_original_part:the previosly active partition on the mmc
device,
+ * used to restore active the partition when the RPMB
+ * accesses are finished
+ */
+struct optee_private {
+ struct mmc *rpmb_mmc;
+ int rpmb_dev_id;
+ int rpmb_original_part;
+};
+
+struct optee_msg_arg;
+
+void optee_suppl_cmd(struct udevice *dev, struct tee_shm *shm_arg,
+void **page_list);
+
+#ifdef CONFIG_SUPPORT_EMMC_RPMB
+/**
+ * optee_suppl_cmd_rpmb() - route RPMB frames to mmc
+ * @dev: device with the selected RPMB partition
+ * @arg: OP-TEE message holding the frames to transmit to the mmc
+ * and space for the response frames.
+ *
+ * Routes signed (MACed) RPMB frames from OP-TEE Secure OS to MMC and vice
+ * versa to manipulate the RPMB partition.
+ */
+void optee_suppl_cmd_rpmb(struct udevice *dev, struct optee_msg_arg *arg);
+
+/**
+ * optee_suppl_rpmb_release() - release mmc device
+ * @dev: mmc device
+ *
+ * Releases the mmc device and restores the previously selected partition.
+ */
+void optee_suppl_rpmb_release(struct udevice *dev);
+#else
+static inline void optee_suppl_cmd_rpmb(struct udevice *dev,
+ struct optee_msg_arg *arg)
+{
+ debug("OPTEE_MSG_RPC_CMD_RPMB not implemented\n");
+ arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
+}
+
+static inline void optee_suppl_rpmb_release(struct udevice *dev)
+{
+}
+#endif
+
void *optee_alloc_and_init_page_list(void *buf, ulong len, u64 *phys_buf_ptr);
-void optee_suppl_cmd(struct udevice *dev, void *shm, void **page_list);
#endif /* __OPTEE_PRIVATE_H */
diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
new file mode 100644
index ..955155b3f8b1
--- /dev/null
+++ b/drivers/tee/optee/rpmb.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "optee_msg.h"
+#include "optee_private.h"
+
+/*
+ * Request and response definitions must be in sync with the secure side of
+ * OP-TEE.
+ */
+
+/* Request */
+struct rpmb_req {
+ u16 cmd;
+#define RPMB_CMD_DATA_REQ 0x00
+#define RPMB_CMD_GET_DEV_INFO 0x01
+ u16 dev_id;
+ u16 block_count;
+ /* Optional data frames (rpmb_data_frame) follow */
+};
+
+#define RPMB_REQ_DATA(req) ((void *)((struct rpmb_req *)(req) + 1))
+
+/* Response to device info request */
+struct rpmb_dev_info {
+ u8 cid[16];
+ u8 rpmb_size_mult; /* EXT CSD-slice 168: RPMB
[U-Boot] [PATCH v4 14/19] tee: add sandbox driver
Adds a sandbox tee driver which emulates a generic TEE with the OP-TEE
AVB TA.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
drivers/tee/Kconfig | 18 ++-
drivers/tee/Makefile | 1 +
drivers/tee/optee/Kconfig | 2 +-
drivers/tee/sandbox.c | 308 ++
include/sandboxtee.h | 21 +++
5 files changed, 347 insertions(+), 3 deletions(-)
create mode 100644 drivers/tee/sandbox.c
create mode 100644 include/sandboxtee.h
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index 835c256e9239..5c0c89043fac 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -1,8 +1,8 @@
# Generic Trusted Execution Environment Configuration
config TEE
bool "Trusted Execution Environment support"
- depends on ARM && (ARM64 || CPU_V7A)
- select ARM_SMCCC
+ depends on (ARM && (ARM64 || CPU_V7A)) || SANDBOX
+ select ARM_SMCCC if ARM
help
This implements a generic interface towards a Trusted Execution
Environment (TEE). A TEE is a trusted OS running in some secure
@@ -14,6 +14,20 @@ if TEE
menu "TEE drivers"
+config SANDBOX_TEE
+ bool "Sandbox TEE emulator"
+ depends on SANDBOX
+ default y
+ help
+ This emulates a generic TEE needed for testing including the AVB
+ TA. The emulation provides all callbacks of a regular TEE and
+ supports session and shared memory management. The AVB TA is
+ emulated with rollback indexes and device lock-state, the state
+ of the TA is only kept in RAM and will be reset on each boot.
+ The emulation only supports one open session at a time.
+ Interaction from the U-Boot command line in possible via the
+ "avb" commands.
+
source "drivers/tee/optee/Kconfig"
endmenu
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index 19633b60f235..f72c68c09f33 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += tee-uclass.o
+obj-$(CONFIG_SANDBOX) += sandbox.o
obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
index dbfa7846a30f..d489834df926 100644
--- a/drivers/tee/optee/Kconfig
+++ b/drivers/tee/optee/Kconfig
@@ -10,7 +10,7 @@ config OPTEE
handle Remote Procedure Calls (RPC) from OP-TEE needed to
execute a service. For more information see: https://www.op-tee.org
-if OPTEE
+if OPTEE || SANDBOX
menu "OP-TEE options"
diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
new file mode 100644
index ..10a1e8dffa69
--- /dev/null
+++ b/drivers/tee/sandbox.c
@@ -0,0 +1,308 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Linaro Limited
+ */
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The sandbox tee driver tries to emulate a generic Trusted Exectution
+ * Environment (TEE) with the Trusted Application (TA) OPTEE_TA_AVB
+ * available.
+ */
+
+/**
+ * struct ta_entry - TA entries
+ * @uuid: UUID of an emulated TA
+ * @open_session Called when a session is openened to the TA
+ * @invoke_funcCalled when a function in the TA is to be
invoked
+ *
+ * This struct is used to register TAs in this sandbox emulation of a TEE.
+ */
+struct ta_entry {
+ struct tee_optee_ta_uuid uuid;
+ u32 (*open_session)(uint num_params, struct tee_param *params);
+ u32 (*invoke_func)(u32 func, uint num_params, struct tee_param *params);
+};
+
+#ifdef CONFIG_OPTEE_TA_AVB
+static u32 get_attr(uint n, uint num_params, struct tee_param *params)
+{
+ if (n >= num_params)
+ return TEE_PARAM_ATTR_TYPE_NONE;
+
+ return params[n].attr;
+}
+
+static u32 check_params(u8 p0, u8 p1, u8 p2, u8 p3, uint num_params,
+ struct tee_param *params)
+{
+ u8 p[] = { p0, p1, p2, p3};
+ uint n;
+
+ for (n = 0; n < ARRAY_SIZE(p); n++)
+ if (p[n] != get_attr(n, num_params, params))
+ goto bad_params;
+
+ for (; n < num_params; n++)
+ if (get_attr(n, num_params, params))
+ goto bad_params;
+
+ return TEE_SUCCESS;
+
+bad_params:
+ printf("Bad param attrs\n");
+
+ return TEE_ERROR_BAD_PARAMETERS;
+}
+
+static u64 ta_avb_rollback_indexes[TA_AVB_MAX_ROLLBACK_LOCATIONS];
+static u32 ta_avb_lock_state;
+
+static u32 ta_avb_open_session(uint num_params, struct tee_param *params)
+{
+ /*
+* We don't expect additional parameters when opening a session to
+* this TA.
+*/
+ return check_params(TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+ TEE_PARAM_ATTR_TYPE_NONE, TEE_PARAM_ATTR_TYPE_NONE,
+ num_params, params);
+}
+
+static u32 ta_avb_invoke_func(u32 func, uint num_params,
+ struct tee_param *params)
+{
+
[U-Boot] [PATCH v4 07/19] tee: add OP-TEE driver
Adds a OP-TEE driver.
* Targets ARM and ARM64
* Supports using any U-Boot memory as shared memory
* Probes OP-TEE version using SMCs
* Uses OPTEE message protocol version 2 to communicate with secure world
Reviewed-by: Simon Glass
Tested-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
drivers/tee/Kconfig | 10 +
drivers/tee/Makefile | 1 +
drivers/tee/optee/Kconfig| 11 +
drivers/tee/optee/Makefile | 4 +
drivers/tee/optee/core.c | 654 +++
drivers/tee/optee/optee_msg.h| 425 +++
drivers/tee/optee/optee_msg_supplicant.h | 240 +
drivers/tee/optee/optee_private.h| 12 +
drivers/tee/optee/optee_smc.h| 450
drivers/tee/optee/supplicant.c | 93
10 files changed, 1900 insertions(+)
create mode 100644 drivers/tee/optee/Kconfig
create mode 100644 drivers/tee/optee/Makefile
create mode 100644 drivers/tee/optee/core.c
create mode 100644 drivers/tee/optee/optee_msg.h
create mode 100644 drivers/tee/optee/optee_msg_supplicant.h
create mode 100644 drivers/tee/optee/optee_private.h
create mode 100644 drivers/tee/optee/optee_smc.h
create mode 100644 drivers/tee/optee/supplicant.c
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
index f3fc3c2ca790..835c256e9239 100644
--- a/drivers/tee/Kconfig
+++ b/drivers/tee/Kconfig
@@ -9,3 +9,13 @@ config TEE
environment, for example, TrustZone on ARM cpus, or a separate
secure co-processor etc. See also:
https://en.wikipedia.org/wiki/Trusted_execution_environment
+
+if TEE
+
+menu "TEE drivers"
+
+source "drivers/tee/optee/Kconfig"
+
+endmenu
+
+endif
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
index b6d8e16e6211..19633b60f235 100644
--- a/drivers/tee/Makefile
+++ b/drivers/tee/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += tee-uclass.o
+obj-$(CONFIG_OPTEE) += optee/
diff --git a/drivers/tee/optee/Kconfig b/drivers/tee/optee/Kconfig
new file mode 100644
index ..7484e6fea114
--- /dev/null
+++ b/drivers/tee/optee/Kconfig
@@ -0,0 +1,11 @@
+# OP-TEE Trusted Execution Environment Configuration
+config OPTEE
+ bool "OP-TEE"
+ depends on ARM_SMCCC
+ help
+ This implements the OP-TEE Trusted Execution Environment (TEE)
+ driver. OP-TEE is a Trusted OS designed primarily to rely on the
+ ARM TrustZone(R) technology as the underlying hardware isolation
+ mechanism. This driver can request services from OP-TEE, but also
+ handle Remote Procedure Calls (RPC) from OP-TEE needed to
+ execute a service. For more information see: https://www.op-tee.org
diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
new file mode 100644
index ..6148feb474a5
--- /dev/null
+++ b/drivers/tee/optee/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += core.o
+obj-y += supplicant.o
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
new file mode 100644
index ..726382da9bb8
--- /dev/null
+++ b/drivers/tee/optee/core.c
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "optee_smc.h"
+#include "optee_msg.h"
+#include "optee_private.h"
+
+#define PAGELIST_ENTRIES_PER_PAGE \
+ ((OPTEE_MSG_NONCONTIG_PAGE_SIZE / sizeof(u64)) - 1)
+
+typedef void (optee_invoke_fn)(unsigned long, unsigned long, unsigned long,
+ unsigned long, unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ struct arm_smccc_res *);
+
+struct optee_pdata {
+ optee_invoke_fn *invoke_fn;
+};
+
+struct rpc_param {
+ u32 a0;
+ u32 a1;
+ u32 a2;
+ u32 a3;
+ u32 a4;
+ u32 a5;
+ u32 a6;
+ u32 a7;
+};
+
+/**
+ * reg_pair_to_ptr() - Make a pointer of 2 32-bit values
+ * @reg0: High bits of the pointer
+ * @reg1: Low bits of the pointer
+ *
+ * Returns the combined result, note that if a pointer is 32-bit wide @reg0
+ * will be discarded.
+ */
+static void *reg_pair_to_ptr(u32 reg0, u32 reg1)
+{
+ return (void *)(ulong)(((u64)reg0 << 32) | reg1);
+}
+
+/**
+ * reg_pair_from_64() - Split a 64-bit value into two 32-bit values
+ * @reg0: High bits of @val
+ * @reg1: Low bits of @val
+ * @val: The value to split
+ */
+static void reg_pair_from_64(u32 *reg0, u32 *reg1, u64 val)
+{
+ *reg0 = val >> 32;
+ *reg1 = val;
+}
+
+/**
+ * optee_alloc_and_init_page_list() - Provide page list of memory buffer
+ * @buf: Start of buffer
+ * @len: Length of buffer
+ * @phys_buf_ptr Physical pointer with coded offset to page list
+ *
+ * Secure world doesn
[U-Boot] [PATCH v4 08/19] Documentation: tee uclass and op-tee driver
Reviewed-by: Simon Glass Signed-off-by: Jens Wiklander --- doc/README.tee | 112 + 1 file changed, 112 insertions(+) create mode 100644 doc/README.tee diff --git a/doc/README.tee b/doc/README.tee new file mode 100644 index ..79e7996a6f5f --- /dev/null +++ b/doc/README.tee @@ -0,0 +1,112 @@ += +TEE uclass += + +This document describes the TEE uclass in U-Boot + +A TEE (Trusted Execution Environment) is a trusted OS running in some +secure environment, for example, TrustZone on ARM CPUs, or a separate +secure co-processor etc. A TEE driver handles the details needed to +communicate with the TEE. + +This uclass deals with: + +- Registration of TEE drivers + +- Managing shared memory between U-Boot and the TEE + +- Providing a generic API to the TEE + +The TEE interface += + +include/tee.h defines the generic interface to a TEE. + +A client finds the TEE device via tee_find_device(). Other important functions +when interfacing with a TEE are: + +- tee_shm_alloc(), tee_shm_register() and tee_shm_free() to manage shared + memory objects often needed when communicating with the TEE. + +- tee_get_version() lets the client know which the capabilities of the TEE + device. + +- tee_open_session() opens a session to a Trusted Application + +- tee_invoke_func() invokes a function in a Trusted Application + +- tee_close_session() closes a session to a Trusted Application + +Much of the communication between clients and the TEE is opaque to the +driver. The main job for the driver is to receive requests from the +clients, forward them to the TEE and send back the results. + +OP-TEE driver += + +The OP-TEE driver handles OP-TEE [1] based TEEs. Currently it is only the ARM +TrustZone based OP-TEE solution that is supported. + +Lowest level of communication with OP-TEE builds on ARM SMC Calling +Convention (SMCCC) [2], which is the foundation for OP-TEE's SMC interface +[3] used internally by the driver. Stacked on top of that is OP-TEE Message +Protocol [4]. + +OP-TEE SMC interface provides the basic functions required by SMCCC and some +additional functions specific for OP-TEE. The most interesting functions are: + +- OPTEE_SMC_FUNCID_CALLS_UID (part of SMCCC) returns the version information + which is then returned by TEE_IOC_VERSION + +- OPTEE_SMC_CALL_GET_OS_UUID returns the particular OP-TEE implementation, used + to tell, for instance, a TrustZone OP-TEE apart from an OP-TEE running on a + separate secure co-processor. + +- OPTEE_SMC_CALL_WITH_ARG drives the OP-TEE message protocol + +- OPTEE_SMC_GET_SHM_CONFIG lets the driver and OP-TEE agree on which memory + range to used for shared memory between Linux and OP-TEE. + +The GlobalPlatform TEE Client API [5] is implemented on top of the generic +TEE API. + +Picture of the relationship between the different components in the +OP-TEE architecture: + + U-Boot Secure world + ~~ + ++ +-+ + | Client | | Trusted | + || | Application | + ++ +-+ + /\ /\ + || || + \/ \/ + ++ +-+ + | TEE| | TEE Internal| + | uclass | | API | + ++ +-+ + | OP-TEE | | OP-TEE | + | driver | | Trusted OS | + ++---+-+ + | OP-TEE MSG | + | SMCCC (OPTEE_SMC_CALL_*)| + +--+ + +RPC (Remote Procedure Call) are requests from secure world to the driver. +An RPC is identified by a special range of SMCCC return values from +OPTEE_SMC_CALL_WITH_ARG. + +References +== + +[1] https://github.com/OP-TEE/optee_os + +[2] http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html + +[3] drivers/tee/optee/optee_smc.h + +[4] drivers/tee/optee/optee_msg.h + +[5] http://www.globalplatform.org/specificationsdevice.asp look for +"TEE Client API Specification v1.0" and click download. -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 09/19] arm: dt: hikey: Add optee node
Sync with 14e21cb8f811 ("arm64: dt: hikey: Add optee node"
from Linux kernel.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
arch/arm/dts/hi6220-hikey.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/hi6220-hikey.dts b/arch/arm/dts/hi6220-hikey.dts
index 818525197508..24f09257af00 100644
--- a/arch/arm/dts/hi6220-hikey.dts
+++ b/arch/arm/dts/hi6220-hikey.dts
@@ -31,6 +31,13 @@
device_type = "memory";
reg = <0x0 0x0 0x0 0x4000>;
};
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
};
&uart2 {
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 05/19] Add UCLASS_TEE for Trusted Execution Environment
Adds a uclass to interface with a TEE (Trusted Execution Environment).
A TEE driver is a driver that interfaces with a trusted OS running in
some secure environment, for example, TrustZone on ARM cpus, or a
separate secure co-processor etc.
The TEE subsystem can serve a TEE driver for a Global Platform compliant
TEE, but it's not limited to only Global Platform TEEs.
The over all design is based on the TEE subsystem in the Linux kernel,
tailored for U-Boot.
Reviewed-by: Simon Glass
Tested-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
MAINTAINERS | 6 +
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/tee/Kconfig | 11 ++
drivers/tee/Makefile | 3 +
drivers/tee/tee-uclass.c | 209
include/dm/uclass-id.h | 1 +
include/tee.h| 336 +++
8 files changed, 569 insertions(+)
create mode 100644 drivers/tee/Kconfig
create mode 100644 drivers/tee/Makefile
create mode 100644 drivers/tee/tee-uclass.c
create mode 100644 include/tee.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8f237128b241..5b085ad3acd6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -585,6 +585,12 @@ TQ GROUP
S: Orphaned (Since 2016-02)
T: git git://git.denx.de/u-boot-tq-group.git
+TEE
+M: Jens Wiklander
+S: Maintained
+F: drivers/tee/
+F: include/tee.h
+
UBI
M: Kyungmin Park
M: Heiko Schocher
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 56536c4b1915..1e44acb4835f 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -96,6 +96,8 @@ source "drivers/spmi/Kconfig"
source "drivers/sysreset/Kconfig"
+source "drivers/tee/Kconfig"
+
source "drivers/thermal/Kconfig"
source "drivers/timer/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index d296354b3c01..17d6c0947a2f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -103,6 +103,7 @@ obj-y += smem/
obj-y += soc/
obj-$(CONFIG_REMOTEPROC) += remoteproc/
obj-y += thermal/
+obj-$(CONFIG_TEE) += tee/
obj-y += axi/
obj-$(CONFIG_MACH_PIC32) += ddr/microchip/
diff --git a/drivers/tee/Kconfig b/drivers/tee/Kconfig
new file mode 100644
index ..f3fc3c2ca790
--- /dev/null
+++ b/drivers/tee/Kconfig
@@ -0,0 +1,11 @@
+# Generic Trusted Execution Environment Configuration
+config TEE
+ bool "Trusted Execution Environment support"
+ depends on ARM && (ARM64 || CPU_V7A)
+ select ARM_SMCCC
+ help
+ This implements a generic interface towards a Trusted Execution
+ Environment (TEE). A TEE is a trusted OS running in some secure
+ environment, for example, TrustZone on ARM cpus, or a separate
+ secure co-processor etc. See also:
+ https://en.wikipedia.org/wiki/Trusted_execution_environment
diff --git a/drivers/tee/Makefile b/drivers/tee/Makefile
new file mode 100644
index ..b6d8e16e6211
--- /dev/null
+++ b/drivers/tee/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-y += tee-uclass.o
diff --git a/drivers/tee/tee-uclass.c b/drivers/tee/tee-uclass.c
new file mode 100644
index ..1bee54ebf4af
--- /dev/null
+++ b/drivers/tee/tee-uclass.c
@@ -0,0 +1,209 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Linaro Limited
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct tee_uclass_priv - information of a TEE, stored by the uclass
+ *
+ * @list_shm: list of structe tee_shm representing memory blocks shared
+ * with the TEE.
+ */
+struct tee_uclass_priv {
+ struct list_head list_shm;
+};
+
+static const struct tee_driver_ops *tee_get_ops(struct udevice *dev)
+{
+ return device_get_ops(dev);
+}
+
+void tee_get_version(struct udevice *dev, struct tee_version_data *vers)
+{
+ tee_get_ops(dev)->get_version(dev, vers);
+}
+
+int tee_open_session(struct udevice *dev, struct tee_open_session_arg *arg,
+uint num_param, struct tee_param *param)
+{
+ return tee_get_ops(dev)->open_session(dev, arg, num_param, param);
+}
+
+int tee_close_session(struct udevice *dev, u32 session)
+{
+ return tee_get_ops(dev)->close_session(dev, session);
+}
+
+int tee_invoke_func(struct udevice *dev, struct tee_invoke_arg *arg,
+ uint num_param, struct tee_param *param)
+{
+ return tee_get_ops(dev)->invoke_func(dev, arg, num_param, param);
+}
+
+int __tee_shm_add(struct udevice *dev, ulong align, void *addr, ulong size,
+ u32 flags, struct tee_shm **shmp)
+{
+ struct tee_shm *shm;
+ void *p = addr;
+ int rc;
+
+ if (flags & TEE_SHM_ALLOC) {
+ if (align)
+ p = memalign(align, size);
+ else
+ p = malloc(size);
+ }
+ if (!p)
+ return -ENOMEM;
+
+ shm = calloc(1, sizeof(*shm));
+ if (!shm) {
+ rc = -ENOMEM;
+ goto err;
+
[U-Boot] [PATCH v4 06/19] dt/bindings: add bindings for optee
Sync with c8bfafb15944 ("dt/bindings: add bindings for optee")
from Linux kernel.
Introduces linaro prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
.../firmware/linaro,optee-tz.txt | 31 +++
1 file changed, 31 insertions(+)
create mode 100644 doc/device-tree-bindings/firmware/linaro,optee-tz.txt
diff --git a/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
b/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
new file mode 100644
index ..d38834c67dff
--- /dev/null
+++ b/doc/device-tree-bindings/firmware/linaro,optee-tz.txt
@@ -0,0 +1,31 @@
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip.
+
+We're using "linaro" as the first part of the compatible property for
+the reference implementation maintained by Linaro.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible : should contain "linaro,optee-tz"
+
+- method : The method of calling the OP-TEE Trusted OS. Permitted
+ values are:
+
+ "smc" : SMC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+
+ "hvc" : HVC #0, with the register assignments specified
+ in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 04/19] mmc: rpmb: add mmc_rpmb_route_frames()
Adds mmc_rpmb_route_frames() to route RPMB data frames from/to an
external entity.
Tested-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
drivers/mmc/rpmb.c | 160 +
include/mmc.h | 19 ++
2 files changed, 179 insertions(+)
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index dfbdb0deb107..908f19208955 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -321,3 +321,163 @@ int mmc_rpmb_write(struct mmc *mmc, void *addr, unsigned
short blk,
}
return i;
}
+
+static int send_write_mult_block(struct mmc *mmc, const struct s_rpmb *frm,
+unsigned short cnt)
+{
+ struct mmc_cmd cmd = {
+ .cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK,
+ .resp_type = MMC_RSP_R1b,
+ };
+ struct mmc_data data = {
+ .src = (const void *)frm,
+ .blocks = cnt,
+ .blocksize = sizeof(*frm),
+ .flags = MMC_DATA_WRITE,
+ };
+
+ return mmc_send_cmd(mmc, &cmd, &data);
+}
+
+static int send_read_mult_block(struct mmc *mmc, struct s_rpmb *frm,
+ unsigned short cnt)
+{
+ struct mmc_cmd cmd = {
+ .cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK,
+ .resp_type = MMC_RSP_R1,
+ };
+ struct mmc_data data = {
+ .dest = (void *)frm,
+ .blocks = cnt,
+ .blocksize = sizeof(*frm),
+ .flags = MMC_DATA_READ,
+ };
+
+ return mmc_send_cmd(mmc, &cmd, &data);
+}
+
+static int rpmb_route_write_req(struct mmc *mmc, struct s_rpmb *req,
+ unsigned short req_cnt, struct s_rpmb *rsp,
+ unsigned short rsp_cnt)
+{
+ int ret;
+
+ /*
+* Send the write request.
+*/
+ ret = mmc_set_blockcount(mmc, req_cnt, true);
+ if (ret)
+ return ret;
+
+ ret = send_write_mult_block(mmc, req, req_cnt);
+ if (ret)
+ return ret;
+
+ /*
+* Read the result of the request.
+*/
+ ret = mmc_set_blockcount(mmc, 1, false);
+ if (ret)
+ return ret;
+
+ memset(rsp, 0, sizeof(*rsp));
+ rsp->request = cpu_to_be16(RPMB_REQ_STATUS);
+ ret = send_write_mult_block(mmc, rsp, 1);
+ if (ret)
+ return ret;
+
+ ret = mmc_set_blockcount(mmc, 1, false);
+ if (ret)
+ return ret;
+
+ return send_read_mult_block(mmc, rsp, 1);
+}
+
+static int rpmb_route_read_req(struct mmc *mmc, struct s_rpmb *req,
+ unsigned short req_cnt, struct s_rpmb *rsp,
+ unsigned short rsp_cnt)
+{
+ int ret;
+
+ /*
+* Send the read request.
+*/
+ ret = mmc_set_blockcount(mmc, 1, false);
+ if (ret)
+ return ret;
+
+ ret = send_write_mult_block(mmc, req, 1);
+ if (ret)
+ return ret;
+
+ /*
+* Read the result of the request.
+*/
+
+ ret = mmc_set_blockcount(mmc, rsp_cnt, false);
+ if (ret)
+ return ret;
+
+ return send_read_mult_block(mmc, rsp, rsp_cnt);
+}
+
+static int rpmb_route_frames(struct mmc *mmc, struct s_rpmb *req,
+unsigned short req_cnt, struct s_rpmb *rsp,
+unsigned short rsp_cnt)
+{
+ unsigned short n;
+
+ /*
+* If multiple request frames are provided, make sure that all are
+* of the same type.
+*/
+ for (n = 1; n < req_cnt; n++)
+ if (req[n].request != req->request)
+ return -EINVAL;
+
+ switch (be16_to_cpu(req->request)) {
+ case RPMB_REQ_KEY:
+ if (req_cnt != 1 || rsp_cnt != 1)
+ return -EINVAL;
+ return rpmb_route_write_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+ case RPMB_REQ_WRITE_DATA:
+ if (!req_cnt || rsp_cnt != 1)
+ return -EINVAL;
+ return rpmb_route_write_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+ case RPMB_REQ_WCOUNTER:
+ if (req_cnt != 1 || rsp_cnt != 1)
+ return -EINVAL;
+ return rpmb_route_read_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+ case RPMB_REQ_READ_DATA:
+ if (req_cnt != 1 || !req_cnt)
+ return -EINVAL;
+ return rpmb_route_read_req(mmc, req, req_cnt, rsp, rsp_cnt);
+
+ default:
+ debug("Unsupported message type: %d\n",
+ be16_to_cpu(req->request));
+ return -EINVAL;
+ }
+}
+
+int mmc_rpmb_route_frames(struct mmc *mmc, void *req, unsigned long reqlen,
+ void *rsp, unsigned long rsplen)
+{
+ /*
+* Whoever crafted the data supplied to this function knows how t
[U-Boot] [PATCH v4 03/19] cmd: avb: print error message if command fails
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
cmd/avb.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/cmd/avb.c b/cmd/avb.c
index ca4b26d5d7b3..ff00be4cee38 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -35,6 +35,8 @@ int do_avb_init(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
if (avb_ops)
return CMD_RET_SUCCESS;
+ printf("Failed to initialize avb2\n");
+
return CMD_RET_FAILURE;
}
@@ -65,6 +67,8 @@ int do_avb_read_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return CMD_RET_SUCCESS;
}
+ printf("Failed to read from partition\n");
+
return CMD_RET_FAILURE;
}
@@ -108,6 +112,8 @@ int do_avb_read_part_hex(cmd_tbl_t *cmdtp, int flag, int
argc,
return CMD_RET_SUCCESS;
}
+ printf("Failed to read from partition\n");
+
free(buffer);
return CMD_RET_FAILURE;
}
@@ -138,6 +144,8 @@ int do_avb_write_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return CMD_RET_SUCCESS;
}
+ printf("Failed to write in partition\n");
+
return CMD_RET_FAILURE;
}
@@ -161,6 +169,9 @@ int do_avb_read_rb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
printf("Rollback index: %llx\n", rb_idx);
return CMD_RET_SUCCESS;
}
+
+ printf("Failed to read rollback index\n");
+
return CMD_RET_FAILURE;
}
@@ -184,6 +195,8 @@ int do_avb_write_rb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
AVB_IO_RESULT_OK)
return CMD_RET_SUCCESS;
+ printf("Failed to write rollback index\n");
+
return CMD_RET_FAILURE;
}
@@ -210,6 +223,8 @@ int do_avb_get_uuid(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_SUCCESS;
}
+ printf("Failed to read UUID\n");
+
return CMD_RET_FAILURE;
}
@@ -320,6 +335,8 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_SUCCESS;
}
+ printf("Can't determine device lock state.\n");
+
return CMD_RET_FAILURE;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 02/19] cmd: avb read_rb: print rb_idx in hexadecimal
Prior to this patch was do_avb_write_rb() reading supplied rb_idx as a
hexadecimal number while do_avb_read_rb() printed the read out rb_idx as
decimal number. For consistency change do_avb_read_rb() to print rb_idx
as a hexadecimal number too.
Reviewed-by: Simon Glass
Reviewed-by: Igor Opaniuk
Signed-off-by: Jens Wiklander
---
cmd/avb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/avb.c b/cmd/avb.c
index f045a0c64c4a..ca4b26d5d7b3 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -158,7 +158,7 @@ int do_avb_read_rb(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (avb_ops->read_rollback_index(avb_ops, index, &rb_idx) ==
AVB_IO_RESULT_OK) {
- printf("Rollback index: %llu\n", rb_idx);
+ printf("Rollback index: %llx\n", rb_idx);
return CMD_RET_SUCCESS;
}
return CMD_RET_FAILURE;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 01/19] dm: fdt: scan for devices under /firmware too
Just as /chosen may contain devices /firmware may contain devices, scan
for devices under /firmware too.
Reviewed-by: Simon Glass
Signed-off-by: Jens Wiklander
---
drivers/core/root.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 72bcc7d7f2a3..0dca507e1187 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -265,9 +265,15 @@ static int dm_scan_fdt_node(struct udevice *parent, const
void *blob,
for (offset = fdt_first_subnode(blob, offset);
offset > 0;
offset = fdt_next_subnode(blob, offset)) {
- /* "chosen" node isn't a device itself but may contain some: */
- if (!strcmp(fdt_get_name(blob, offset, NULL), "chosen")) {
- pr_debug("parsing subnodes of \"chosen\"\n");
+ const char *node_name = fdt_get_name(blob, offset, NULL);
+
+ /*
+* The "chosen" and "firmware" nodes aren't devices
+* themselves but may contain some:
+*/
+ if (!strcmp(node_name, "chosen") ||
+ !strcmp(node_name, "firmware")) {
+ pr_debug("parsing subnodes of \"%s\"\n", node_name);
err = dm_scan_fdt_node(parent, blob, offset,
pre_reloc_only);
@@ -286,8 +292,7 @@ static int dm_scan_fdt_node(struct udevice *parent, const
void *blob,
err = lists_bind_fdt(parent, offset_to_ofnode(offset), NULL);
if (err && !ret) {
ret = err;
- debug("%s: ret=%d\n", fdt_get_name(blob, offset, NULL),
- ret);
+ debug("%s: ret=%d\n", node_name, ret);
}
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 00/19] AVB using OP-TEE
Hi,
This adds support for storing AVB rollback indexes in the RPMB partition.
The RPMB partition (content and key) is managed by OP-TEE
(https://www.op-tee.org/) which is a secure OS leveraging ARM TrustZone.
The Linux kernel can already support OP-TEE with reading and updating
rollback indexes in the RPMB partition, the catch is that this is needed
before the kernel has booted.
The design here is the same as what is in the Linux kernel, with the
exception that the user space daemon tee-supplicant is integrated in the
OP-TEE driver here (drivers/tee/optee/supplicant.c) instead. A new uclass
(UCLASS_TEE) is introduced to provide an abstraction for interfacing with a
Trusted Execution Environment (TEE). There's also the OP-TEE driver using
UCLASS_TEE for registration.
A Trusted Application (TA) interface is added to be used by the AVB verify
functions which are updated accordingly. The TA is managed by OP-TEE and is
executed in a secure TrustZone protected environment.
The header files drivers/tee/optee/optee_{msg,msg_supplicant,smc}.h and
include/tee/optee_ta_avb.h are copied from
https://github.com/OP-TEE/optee_os/tree/master more or less unmodified.
They may need to be updated from time to time in order to support new
features.
In MMC there's a new function, mmc_rpmb_route_frames(), which as the name
suggests is used to route RPMB frames to/from the MMC. This saves OP-TEE
from implementing an MMC driver which would need to share resources with
its counterpart here in U-Boot.
This was tested on a Hikey (Kirin 620) board.
I've added myself as maintainer of the TEE stuff.
changes in v4:
* Addressed review comments from Simon Glass
* Rebased on v2018.09
* "avb_verify: bugfix avb_ops_free() skipping free" removed due to the rebase
* Commits "dt/bindings: add bindings for optee",
"sandbox: imply CONFIG_TEE (TEE uclass)",
"tee: add sandbox driver",
"avb_verify: support using OP-TEE TA AVB",
"test_avb: Update pymark.buildconfigspec information for the AVB tests",
"Kconfig: sandbox: enable cmd_avb and dependencies",
Reviewed-by: Simon Glass
* Added descriptions of additional structs and functions
* In commit "avb_verify: support sandbox configuration" avoid the
#ifdef CONFIG_SANDBOX in get_sector_buf() as suggested by Simon.
changes in v3:
* Addressed review comments from Simon Glass
* A few new patches
- "avb_verify: bugfix avb_ops_free() skipping free"
- "tee: add sandbox driver"
- "test_avb: Update pymark.buildconfigspec information for the AVB tests"
- "avb_verify: support sandbox configuration"
- "Kconfig: sandbox: enable cmd_avb and dependencies"
* "sandbox: imply CONFIG_TEE (TEE uclass)", replacing
"configs: sandbox: enable CONFIG_TEE (TEE uclass)"
* Moved sandbox driver to drivers/tee and added code to emulate the AVB TA
* Enabled a few AVB tests (test/py/tests/test_avb.py) for sandbox
* Bugfix tee_find_device()
* Commits "dm: fdt: scan for devices under /firmware too",
"cmd: avb read_rb: print rb_idx in hexadecimal",
"cmd: avb: print error message if command fails",
"Add UCLASS_TEE for Trusted Execution Environment",
"tee: add OP-TEE driver",
"Documentation: tee uclass and op-tee driver",
"test: tee: test TEE uclass",
"arm: dt: hikey: Add optee node" and
"sandbox: dt: add sandbox_tee node"
Reviewed-by: Simon Glass
changes in v2:
* Added sandbox driver and a test in test/dm for the new TEE uclass:
Commit ("test: tee: test TEE uclass") and the enabling commits
("sandbox: dt: add sandbox_tee node") and
("configs: sandbox: enable CONFIG_TEE (TEE uclass)")
* Added descriptions of exported structs and functions
* Added documentation for the TEE uclass and the OP-TEE driver with
the new commit ("Documentation: tee uclass and op-tee driver")
* Added documentation for the changes in avb_verify
* Addressed review comments from Simon Glass
* Added the commit ("cmd: avb: print error message if command fails")
* Made a few functions static in the OP-TEE driver
* Commit ("cmd: avb read_rb: print rb_idx in hexadecimal") and
("tee: optee: support AVB trusted application");
Reviewed-by: Igor Opaniuk
Thanks,
Jens
Jens Wiklander (19):
dm: fdt: scan for devices under /firmware too
cmd: avb read_rb: print rb_idx in hexadecimal
cmd: avb: print error message if command fails
mmc: rpmb: add mmc_rpmb_route_frames()
Add UCLASS_TEE for Trusted Execution Environment
dt/bindings: add bindings for optee
tee: add OP-TEE driver
Documentation: tee uclass and op-tee driver
arm: dt: hikey: Add optee node
optee: support routing of rpmb data frames to mmc
tee: optee: support AVB trusted application
sandbox: dt: add sandbox_tee node
sandbox: imply CONFIG_TEE (TEE uclass)
tee: add sandbox driver
test: tee: test TEE uclass
avb_verify: support using OP-TEE TA AVB
test_avb: Update pymark.buildconfigspec information for the AVB tests
avb_verify: support sandbox configuration
Kconfig: sandbox: enable cmd_avb and dependencies
MAINTAINERS
[U-Boot] [PATCH v2 1/1] ARM: meson: Extend mem_map to support 3GiB of RAM
The current mem_map definition for Meson SoCs has support for up
to 2GiB of RAM. According to S905, S905X, S912 and S805X datasheets
the DDR region is set from 0x to 0xBFFF, so mem_map's
definition should be changed accordingly.
It is also needed to be able to boot Khadas VIM2 board with S912
SoC.
Signed-off-by: Loic Devulder
---
v2: set the correct size for devices memory map
arch/arm/mach-meson/board.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index 1ef7e5a6d1..48096ca7cf 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -111,13 +111,13 @@ static struct mm_region gx_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
- .size = 0x8000UL,
+ .size = 0xc000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
- .virt = 0x8000UL,
- .phys = 0x8000UL,
- .size = 0x8000UL,
+ .virt = 0xc000UL,
+ .phys = 0xc000UL,
+ .size = 0x3000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] pico-imx6ul, pico-imx7d: Enable USB and PXE boot support
On Sat, Sep 22, 2018 at 3:23 AM, Otavio Salvador wrote: > Signed-off-by: Otavio Salvador Please provide a commit log stating the motivation for doing this. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pico-imx6ul, pico-imx7d: Use eMMC user partition by default
On Sat, Sep 22, 2018 at 3:23 AM, Otavio Salvador wrote: > After discussing with TechNexion about how its default setting, it is > better to install on the eMMC user partition by default, when using > DFU, so it works out of box for majority of users. > > Signed-off-by: Otavio Salvador Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] ARM: meson: Extend mem_map to support 3GiB of RAM
The current mem_map definition for Meson SoCs has support for up
to 2GiB of RAM. According to S905, S905X, S912 and S805X datasheets
the DDR region is set from 0x to 0xBFFF, so mem_map's
definition should be changed accordingly.
It is also needed to be able to boot Khadas VIM2 board with S912
SoC.
Signed-off-by: Loic Devulder
---
arch/arm/mach-meson/board.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-meson/board.c b/arch/arm/mach-meson/board.c
index 1ef7e5a6d1..48096ca7cf 100644
--- a/arch/arm/mach-meson/board.c
+++ b/arch/arm/mach-meson/board.c
@@ -111,13 +111,13 @@ static struct mm_region gx_mem_map[] = {
{
.virt = 0x0UL,
.phys = 0x0UL,
- .size = 0x8000UL,
+ .size = 0xc000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_INNER_SHARE
}, {
- .virt = 0x8000UL,
- .phys = 0x8000UL,
- .size = 0x8000UL,
+ .virt = 0xc000UL,
+ .phys = 0xc000UL,
+ .size = 0xf000UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] DW SPI: Allow to overload the management of the external CS
On some platforms, as the Ocelot ones, when wanting to control the CS
through software, it is not possible to do it through the GPIO
controller. Indeed, this signal is managed through a dedicated range of
registers inside the SoC..
By declaring the external_cs_manage function as weak, it is possible to
manage the CS at platform level and then using the appropriate registers.
Signed-off-by: Gregory CLEMENT
---
drivers/spi/designware_spi.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index d8b73ea326..fe6e753bff 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -334,7 +334,13 @@ static int poll_transfer(struct dw_spi_priv *priv)
return 0;
}
-static void external_cs_manage(struct udevice *dev, bool on)
+/*
+ * We define external_cs_manage function as 'weak' as some targets
+ * (like OCELOT) don't control the external CS pin using a GPIO
+ * controller. These SoCs use specific registers to controll by
+ * software the SPI pins (and especially the CS).
+ */
+__weak void external_cs_manage(struct udevice *dev, bool on)
{
#if defined(CONFIG_DM_GPIO) && !defined(CONFIG_SPL_BUILD)
struct dw_spi_priv *priv = dev_get_priv(dev->parent);
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] gpio: mscc-bitbang-spi: Add a simple gpio driver for bitbgang spi
The VCore III SoCs such as the Luton but also the Ocelot can remap an SPI
flash directly in memory. However, for writing in the flash the
communication has to be done by software.
Each of the signal used for the SPI are exposed in a single register. In
order to be able to use the soft-spi driver, the management of this pin
is done through this simple gpio driver.
Even if the main purpose of this driver is to be used by soft-spi, it can
still be used as a normal gpio driver but with limitation: for example
the first pin can't be used as output.
Signed-off-by: Gregory CLEMENT
---
drivers/gpio/Kconfig | 7 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-mscc-bitbang-spi.c | 126 +++
3 files changed, 134 insertions(+)
create mode 100644 drivers/gpio/gpio-mscc-bitbang-spi.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 5cd8b34400..947a59cce3 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -99,6 +99,13 @@ config LPC32XX_GPIO
help
Support for the LPC32XX GPIO driver.
+config MSCC_BITBANG_SPI_GPIO
+ bool "Microsemi bitbang spi GPIO driver"
+ depends on DM_GPIO && SOC_VCOREIII
+ help
+ Support controlling the GPIO used for SPI bitbang by software. Can
+ be used by the VCoreIII SoCs, but it was mainly useful for Luton.
+
config MSM_GPIO
bool "Qualcomm GPIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f186120684..2085dd3cba 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -58,3 +58,4 @@ obj-$(CONFIG_MVEBU_GPIO) += mvebu_gpio.o
obj-$(CONFIG_MSM_GPIO) += msm_gpio.o
obj-$(CONFIG_$(SPL_)PCF8575_GPIO) += pcf8575_gpio.o
obj-$(CONFIG_PM8916_GPIO) += pm8916_gpio.o
+obj-$(CONFIG_MSCC_BITBANG_SPI_GPIO)+= gpio-mscc-bitbang-spi.o
diff --git a/drivers/gpio/gpio-mscc-bitbang-spi.c
b/drivers/gpio/gpio-mscc-bitbang-spi.c
new file mode 100644
index 00..572107d010
--- /dev/null
+++ b/drivers/gpio/gpio-mscc-bitbang-spi.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Microsemi SoCs pinctrl driver
+ *
+ * Author:
+ * License: Dual MIT/GPL
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+enum {
+ SDI,
+ CS0,
+ CS1,
+ CS2,
+ CS3,
+ SDO,
+ SCK
+};
+
+int pinmap[] = {0, 5, 6, 7, 8, 10, 12};
+
+#define SW_SPI_CSn_OE 0x1E /* bits 1 to 4 */
+#define SW_SPI_CS0_OE BIT(1)
+#define SW_SPI_SDO_OE BIT(9)
+#define SW_SPI_SCK_OE BIT(11)
+#define SW_PIN_CTRL_MODE BIT(13)
+
+struct mscc_bb_spi_gpio {
+ u32 *regs;
+ u32 cache_val;
+};
+
+static int mscc_bb_spi_gpio_set(struct udevice *dev, unsigned oft, int val)
+{
+ struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
+
+ if (val)
+ gpio->cache_val |= BIT(pinmap[oft]);
+ else
+ gpio->cache_val &= ~BIT(pinmap[oft]);
+
+ writel(gpio->cache_val, gpio->regs);
+
+ return 0;
+}
+
+static int mscc_bb_spi_gpio_direction_output(struct udevice *dev, unsigned oft,
+ int val)
+{
+ if (oft == 0) {
+ pr_err("SW_SPI_DSI can't be used as output\n");
+ return -ENOTSUPP;
+ }
+
+ mscc_bb_spi_gpio_set(dev, oft, val);
+
+ return 0;
+}
+
+static int mscc_bb_spi_gpio_direction_input(struct udevice *dev, unsigned oft)
+{
+ return 0;
+}
+
+static int mscc_bb_spi_gpio_get(struct udevice *dev, unsigned int oft)
+{
+ struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
+ u32 val = readl(gpio->regs);
+
+ return !!(val & BIT(pinmap[oft]));
+}
+
+static const struct dm_gpio_ops mscc_bb_spi_gpio_ops = {
+ .direction_output = mscc_bb_spi_gpio_direction_output,
+ .direction_input= mscc_bb_spi_gpio_direction_input,
+ .set_value = mscc_bb_spi_gpio_set,
+ .get_value = mscc_bb_spi_gpio_get,
+};
+
+static int mscc_bb_spi_gpio_probe(struct udevice *dev)
+{
+ struct mscc_bb_spi_gpio *gpio = dev_get_priv(dev);
+ struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ fdt_addr_t addr;
+ fdt_size_t size;
+
+ addr = devfdt_get_addr_size_index(dev, 0, &size);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ gpio->regs = ioremap(addr, size);
+
+ uc_priv->bank_name = dev->name;
+ uc_priv->gpio_count = ARRAY_SIZE(pinmap);
+ /*
+* Enable software mode to control the SPI pin, enables the
+* output mode for most of the pin and initialize the cache
+* value in the same time
+*/
+
+ gpio->cache_val = SW_PIN_CTRL_MODE | SW_SPI_SCK_OE | SW_SPI_SDO_OE |
+ SW_SPI_CS0_OE;
+ writel(gpio->cache_val, gpio->regs);
+
+ return 0;
+}
+
+static const struct udevice_id ms
[U-Boot] [PATCH] pinctrl: mscc: Add gpio and pinctrl driver for MSCC MIPS SoCs (VcoreIII based)
This driver supports the pin and gpio controller found in the Ocelot and
Luton SoCs.
The driver was inspired from the pinctrl driver in Linux, but was
simplified and was modified to allow supporting an other SoCs (Luton).
For Ocelot and Luton the controller is the same, only the pins to program
differ.
Signed-off-by: Gregory CLEMENT
---
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/mscc/Kconfig | 22 +++
drivers/pinctrl/mscc/Makefile | 5 +
drivers/pinctrl/mscc/mscc-common.c| 258 ++
drivers/pinctrl/mscc/mscc-common.h| 51 +
drivers/pinctrl/mscc/pinctrl-luton.c | 176 ++
drivers/pinctrl/mscc/pinctrl-ocelot.c | 190 +++
8 files changed, 704 insertions(+)
create mode 100644 drivers/pinctrl/mscc/Kconfig
create mode 100644 drivers/pinctrl/mscc/Makefile
create mode 100644 drivers/pinctrl/mscc/mscc-common.c
create mode 100644 drivers/pinctrl/mscc/mscc-common.h
create mode 100644 drivers/pinctrl/mscc/pinctrl-luton.c
create mode 100644 drivers/pinctrl/mscc/pinctrl-ocelot.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ad0b8daba6..cc82f91579 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -305,6 +305,7 @@ source "drivers/pinctrl/nxp/Kconfig"
source "drivers/pinctrl/renesas/Kconfig"
source "drivers/pinctrl/uniphier/Kconfig"
source "drivers/pinctrl/exynos/Kconfig"
+source "drivers/pinctrl/mscc/Kconfig"
source "drivers/pinctrl/mvebu/Kconfig"
source "drivers/pinctrl/broadcom/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a3a6c6d163..2461dba293 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_PINCTRL_UNIPHIER)+= uniphier/
obj-$(CONFIG_PINCTRL_PIC32)+= pinctrl_pic32.o
obj-$(CONFIG_PINCTRL_EXYNOS) += exynos/
obj-$(CONFIG_PINCTRL_MESON)+= meson/
+obj-y += mscc/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_STI) += pinctrl-sti.o
diff --git a/drivers/pinctrl/mscc/Kconfig b/drivers/pinctrl/mscc/Kconfig
new file mode 100644
index 00..cfc6c06076
--- /dev/null
+++ b/drivers/pinctrl/mscc/Kconfig
@@ -0,0 +1,22 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+config PINCTRL_MSCC
+ bool
+
+config PINCTRL_MSCC_OCELOT
+ depends on SOC_OCELOT && PINCTRL_FULL && OF_CONTROL
+ select PINCTRL_MSCC
+ default y
+ bool "Microsemi ocelot family pin control driver"
+ help
+ Support pin multiplexing and pin configuration control on
+ Microsemi ocelot SoCs.
+
+config PINCTRL_MSCC_LUTON
+ depends on SOC_LUTON && PINCTRL_FULL && OF_CONTROL
+ select PINCTRL_MSCC
+ default y
+ bool "Microsemi luton family pin control driver"
+ help
+ Support pin multiplexing and pin configuration control on
+ Microsemi luton SoCs.
diff --git a/drivers/pinctrl/mscc/Makefile b/drivers/pinctrl/mscc/Makefile
new file mode 100644
index 00..941f418ff9
--- /dev/null
+++ b/drivers/pinctrl/mscc/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+obj-$(CONFIG_PINCTRL_MSCC) += mscc-common.o
+obj-$(CONFIG_PINCTRL_MSCC_OCELOT) += pinctrl-ocelot.o
+obj-$(CONFIG_PINCTRL_MSCC_LUTON) += pinctrl-luton.o
diff --git a/drivers/pinctrl/mscc/mscc-common.c
b/drivers/pinctrl/mscc/mscc-common.c
new file mode 100644
index 00..84b6844daa
--- /dev/null
+++ b/drivers/pinctrl/mscc/mscc-common.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Microsemi SoCs pinctrl driver
+ *
+ * Author:
+ * License: Dual MIT/GPL
+ * Copyright (c) 2017 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "mscc-common.h"
+
+#define clrbits(addr, clear) writel(readl(addr) & ~(clear), (addr))
+
+#define setbits(addr, set) writel(readl(addr) | (set), (addr))
+
+#define MSCC_GPIO_OUT_SET 0x0
+#define MSCC_GPIO_OUT_CLR 0x4
+#define MSCC_GPIO_OUT 0x8
+#define MSCC_GPIO_IN 0xc
+#define MSCC_GPIO_OE 0x10
+#define MSCC_GPIO_INTR 0x14
+#define MSCC_GPIO_INTR_ENA 0x18
+#define MSCC_GPIO_INTR_IDENT 0x1c
+#define MSCC_GPIO_ALT0 0x20
+#define MSCC_GPIO_ALT1 0x24
+
+static int mscc_get_functions_count(struct udevice *dev)
+{
+ struct mscc_pinctrl *info = dev_get_priv(dev);
+
+ return info->num_func;
+}
+
+static const char *mscc_get_function_name(struct udevice *dev,
+ unsigned int function)
+{
+ struct mscc_pinctrl *info = dev_get_priv(dev);
+
+ return info->function_names[function];
+}
+
+static int mscc_pin_function_idx(unsigned int pin, unsigned int function,
+const struct mscc_pin_
[U-Boot] [PATCH 5/6] MSCC: add configuration for Ocelot and Luton based boards
Add common configuration header for the VCore III SoCs (currently Ocelot and Luton), but also the defconfig for the evaluation boards of these SoCs. Signed-off-by: Gregory CLEMENT --- configs/mscc_luton_defconfig | 66 + configs/mscc_ocelot_defconfig| 57 ++ configs/mscc_ocelot_pcb120_defconfig | 56 ++ include/configs/vcoreiii.h | 72 4 files changed, 251 insertions(+) create mode 100644 configs/mscc_luton_defconfig create mode 100644 configs/mscc_ocelot_defconfig create mode 100644 configs/mscc_ocelot_pcb120_defconfig create mode 100644 include/configs/vcoreiii.h diff --git a/configs/mscc_luton_defconfig b/configs/mscc_luton_defconfig new file mode 100644 index 00..47fe12b6ee --- /dev/null +++ b/configs/mscc_luton_defconfig @@ -0,0 +1,66 @@ +CONFIG_MIPS=y +CONFIG_SYS_TEXT_BASE=0x4000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_DEBUG_UART_BOARD_INIT=y +CONFIG_DEBUG_UART_BASE=0x7010 +CONFIG_DEBUG_UART_CLOCK=20833 +CONFIG_ARCH_MSCC=y +CONFIG_TARGET_LUTON_PCB091=y +CONFIG_DDRTYPE_MT47H128M8HQ=y +CONFIG_SYS_LITTLE_ENDIAN=y +CONFIG_MIPS_BOOT_FDT=y +CONFIG_DEFAULT_DEVICE_TREE="luton_pcb091" +CONFIG_DEBUG_UART=y +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200" +CONFIG_LOGLEVEL=7 +CONFIG_DISPLAY_CPUINFO=y +CONFIG_SYS_PROMPT="pcb091 # " +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_CONSOLE is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_EXPORTENV is not set +# CONFIG_CMD_IMPORTENV is not set +# CONFIG_CMD_CRC32 is not set +CONFIG_CMD_MD5SUM=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEMTEST=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_DHCP=y +# CONFIG_NET_TFTP_VARS is not set +# CONFIG_CMD_NFS is not set +CONFIG_CMD_PING=y +CONFIG_CMD_MTDPARTS=y +CONFIG_MTDIDS_DEFAULT="nor0=spi_flash" +CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:512k(UBoot),256k(Env),256k(conf),6m@1m(linux)" +# CONFIG_ISO_PARTITION is not set +CONFIG_OF_EMBED=y +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_CLK=y +CONFIG_DM_GPIO=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y +CONFIG_DM_ETH=y +CONFIG_PINCTRL=y +CONFIG_PINCONF=y +CONFIG_DM_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_SOFT_SPI=y +CONFIG_LZMA=y +CONFIG_XZ=y diff --git a/configs/mscc_ocelot_defconfig b/configs/mscc_ocelot_defconfig new file mode 100644 index 00..eb0566189a --- /dev/null +++ b/configs/mscc_ocelot_defconfig @@ -0,0 +1,57 @@ +CONFIG_MIPS=y +CONFIG_SYS_TEXT_BASE=0x4000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ARCH_MSCC=y +CONFIG_TARGET_OCELOT_PCB123=y +CONFIG_SYS_LITTLE_ENDIAN=y +CONFIG_DEFAULT_DEVICE_TREE="ocelot_pcb123" +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200" +CONFIG_LOGLEVEL=7 +CONFIG_DISPLAY_CPUINFO=y +CONFIG_SYS_PROMPT="pcb123 # " +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_CONSOLE is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_EXPORTENV is not set +# CONFIG_CMD_IMPORTENV is not set +# CONFIG_CMD_CRC32 is not set +CONFIG_CMD_MD5SUM=y +CONFIG_CMD_MEMINFO=y +CONFIG_CMD_MEMTEST=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_SF=y +CONFIG_CMD_SPI=y +CONFIG_CMD_DHCP=y +# CONFIG_NET_TFTP_VARS is not set +# CONFIG_CMD_NFS is not set +CONFIG_CMD_PING=y +CONFIG_CMD_MTDPARTS=y +CONFIG_MTDIDS_DEFAULT="nor0=spi_flash" +CONFIG_MTDPARTS_DEFAULT="mtdparts=spi_flash:512k(UBoot),256k(Env),256k(conf),15m(linux),15m(linux.bk)" +# CONFIG_ISO_PARTITION is not set +CONFIG_OF_EMBED=y +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_CLK=y +CONFIG_DM_GPIO=y +CONFIG_DM_SPI_FLASH=y +CONFIG_SPI_FLASH=y +CONFIG_SPI_FLASH_BAR=y +CONFIG_SPI_FLASH_GIGADEVICE=y +CONFIG_SPI_FLASH_MACRONIX=y +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_WINBOND=y +CONFIG_SPI_FLASH_MTD=y +CONFIG_DM_ETH=y +CONFIG_PINCTRL=y +CONFIG_PINCONF=y +CONFIG_DM_SERIAL=y +CONFIG_SYS_NS16550=y +CONFIG_SPI=y +CONFIG_DM_SPI=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_LZMA=y diff --git a/configs/mscc_ocelot_pcb120_defconfig b/configs/mscc_ocelot_pcb120_defconfig new file mode 100644 index 00..40cdec45f1 --- /dev/null +++ b/configs/mscc_ocelot_pcb120_defconfig @@ -0,0 +1,56 @@ +CONFIG_MIPS=y +CONFIG_SYS_TEXT_BASE=0x4000 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ARCH_MSCC=y +CONFIG_SYS_LITTLE_ENDIAN=y +CONFIG_DEFAULT_DEVICE_TREE="ocelot_pcb120" +CONFIG_FIT=y +CONFIG_BOOTDELAY=3 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="console=ttyS0,115200" +CONFIG_LOGLEVEL=7 +CONFIG_DISPLAY_CPUINFO=y +CONFIG_SYS_PROMPT="pcb120 # " +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_CONSOLE is not set +# CONFIG_CMD_ELF is not set +# CONFIG_CMD_EXPORTENV is not
[U-Boot] [PATCH 6/6] MIPS: bootm: Add support for Vcore III linux kernel
The kernels built for the Vcore III linux kernel have different
expectation in the way the data were passed.
Unlike with yamon, the command line is expected to be a single string
passed in argv[1]. An other expectation is that the arguments are located
in the cached address space.
However, like yamon, they expect that rd_start and rd_size was passed by
the bootloader in the command line of the kernel, and besides that it
also wait for the root=/dev/ram0.
Signed-off-by: Gregory CLEMENT
---
arch/mips/lib/bootm.c | 62 +--
1 file changed, 42 insertions(+), 20 deletions(-)
diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
index deca5189e3..417f5ce452 100644
--- a/arch/mips/lib/bootm.c
+++ b/arch/mips/lib/bootm.c
@@ -44,22 +44,38 @@ void arch_lmb_reserve(struct lmb *lmb)
lmb_reserve(lmb, sp, gd->ram_top - sp);
}
-static void linux_cmdline_init(void)
+static void linux_cmdline_init(int vcoreiii)
{
+ if (!vcoreiii) {
+ linux_argv = (char **)UNCACHED_SDRAM(gd->bd->bi_boot_params);
+ linux_argp = (char *)(linux_argv + LINUX_MAX_ARGS);
+ } else {
+ /*
+* Vcore III linux kernels expect arguments in the cached
+* address space. They also expect the command line being a
+* single string in the first argument
+*/
+ linux_argv = (char **)(gd->bd->bi_boot_params);
+ linux_argp = (char *)(linux_argv + LINUX_MAX_ARGS);
+ linux_argv[1] = linux_argp;
+ }
linux_argc = 1;
- linux_argv = (char **)UNCACHED_SDRAM(gd->bd->bi_boot_params);
linux_argv[0] = 0;
- linux_argp = (char *)(linux_argv + LINUX_MAX_ARGS);
}
-static void linux_cmdline_set(const char *value, size_t len)
+static void linux_cmdline_set(const char *value, size_t len, int vcoreiii)
{
- linux_argv[linux_argc] = linux_argp;
memcpy(linux_argp, value, len);
- linux_argp[len] = 0;
-
+ if (!vcoreiii) {
+ linux_argv[linux_argc] = linux_argp;
+ linux_argp[len] = 0;
+ linux_argc++;
+ } else {
+ linux_argp[len] = ' ';
+ linux_argp[len + 1] = 0;
+ linux_argc = 2;
+ }
linux_argp += len + 1;
- linux_argc++;
}
static void linux_cmdline_dump(void)
@@ -73,12 +89,10 @@ static void linux_cmdline_dump(void)
debug(" arg %03d: %s\n", i, linux_argv[i]);
}
-static void linux_cmdline_legacy(bootm_headers_t *images)
+static void linux_cmdline_legacy(bootm_headers_t *images, int vcoreiii)
{
const char *bootargs, *next, *quote;
-
- linux_cmdline_init();
-
+ linux_cmdline_init(vcoreiii);
bootargs = env_get("bootargs");
if (!bootargs)
return;
@@ -104,7 +118,7 @@ static void linux_cmdline_legacy(bootm_headers_t *images)
if (!next)
next = bootargs + strlen(bootargs);
- linux_cmdline_set(bootargs, next - bootargs);
+ linux_cmdline_set(bootargs, next - bootargs, vcoreiii);
if (*next)
next++;
@@ -113,7 +127,7 @@ static void linux_cmdline_legacy(bootm_headers_t *images)
}
}
-static void linux_cmdline_append(bootm_headers_t *images)
+static void linux_cmdline_append(bootm_headers_t *images, int vcoreiii)
{
char buf[24];
ulong mem, rd_start, rd_size;
@@ -121,7 +135,7 @@ static void linux_cmdline_append(bootm_headers_t *images)
/* append mem */
mem = gd->ram_size >> 20;
sprintf(buf, "mem=%luM", mem);
- linux_cmdline_set(buf, strlen(buf));
+ linux_cmdline_set(buf, strlen(buf), vcoreiii);
/* append rd_start and rd_size */
rd_start = images->initrd_start;
@@ -129,9 +143,13 @@ static void linux_cmdline_append(bootm_headers_t *images)
if (rd_size) {
sprintf(buf, "rd_start=0x%08lX", rd_start);
- linux_cmdline_set(buf, strlen(buf));
+ linux_cmdline_set(buf, strlen(buf), vcoreiii);
sprintf(buf, "rd_size=0x%lX", rd_size);
- linux_cmdline_set(buf, strlen(buf));
+ linux_cmdline_set(buf, strlen(buf), vcoreiii);
+ if (vcoreiii) {
+ sprintf(buf, "root=/dev/ram0");
+ linux_cmdline_set(buf, strlen(buf), vcoreiii);
+ }
}
}
@@ -276,11 +294,15 @@ static void boot_prep_linux(bootm_headers_t *images)
boot_reloc_fdt(images);
boot_setup_fdt(images);
} else {
- if (CONFIG_IS_ENABLED(MIPS_BOOT_CMDLINE_LEGACY)) {
- linux_cmdline_legacy(images);
+ if (CONFIG_IS_ENABLED(SOC_VCOREIII)) {
+ linux_cmdline_legacy(images, 1);
+ linux_cmdline_append(images, 1);
+
[U-Boot] [PATCH 4/6] MSCC: add device tree for Ocelot and Luton (boards and SoCs)
Adding device tree for Ocelot SoC (extract from Linux) and the 2
evaluation boards using this SoC: PCB120 and PCB132.
Adding device tree for Luton SoC (not yet in Linux) and the evaluation
boards using this SoC: PCB91.
Signed-off-by: Gregory CLEMENT
---
arch/mips/dts/luton_pcb091.dts | 36
arch/mips/dts/mscc,luton.dtsi | 87 +++
arch/mips/dts/mscc,ocelot.dtsi | 132 +
arch/mips/dts/mscc,ocelot_pcb.dtsi | 37
arch/mips/dts/ocelot_pcb120.dts| 12 +++
arch/mips/dts/ocelot_pcb123.dts| 12 +++
6 files changed, 316 insertions(+)
create mode 100644 arch/mips/dts/luton_pcb091.dts
create mode 100644 arch/mips/dts/mscc,luton.dtsi
create mode 100644 arch/mips/dts/mscc,ocelot.dtsi
create mode 100644 arch/mips/dts/mscc,ocelot_pcb.dtsi
create mode 100644 arch/mips/dts/ocelot_pcb120.dts
create mode 100644 arch/mips/dts/ocelot_pcb123.dts
diff --git a/arch/mips/dts/luton_pcb091.dts b/arch/mips/dts/luton_pcb091.dts
new file mode 100644
index 00..b5e0df8d04
--- /dev/null
+++ b/arch/mips/dts/luton_pcb091.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+/dts-v1/;
+#include "mscc,luton.dtsi"
+
+/ {
+ model = "Luton PCB091 Reference Board";
+ compatible = "mscc,luton-pcb091", "mscc,luton";
+
+ aliases {
+ serial0 = &uart0;
+ spi0 = &spi0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&spi0 {
+ status = "okay";
+ spi-flash@0 {
+ compatible = "spi-flash";
+spi-max-frequency = <1800>; /* input clock */
+reg = <0>; /* CS0 */
+ };
+};
+
diff --git a/arch/mips/dts/mscc,luton.dtsi b/arch/mips/dts/mscc,luton.dtsi
new file mode 100644
index 00..6a4ad2a5be
--- /dev/null
+++ b/arch/mips/dts/mscc,luton.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mscc,luton";
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "mips,mips24KEc";
+ device_type = "cpu";
+ reg = <0>;
+ };
+ };
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ ahb_clk: ahb-clk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <20833>;
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x6000 0x1020>;
+
+ uart0: serial@1010 {
+ pinctrl-0 = <&uart_pins>;
+ pinctrl-names = "default";
+
+ compatible = "ns16550a";
+ reg = <0x1010 0x20>;
+ clocks = <&ahb_clk>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+
+ status = "disabled";
+ };
+
+ gpio: pinctrl@70068 {
+ compatible = "mscc,luton-pinctrl";
+ reg = <0x70068 0x68>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&gpio 0 0 32>;
+
+ uart_pins: uart-pins {
+ pins = "GPIO_30", "GPIO_31";
+ function = "uart";
+ };
+
+ };
+
+ gpio_spi_bitbang: gpio@1064 {
+ compatible = "mscc,spi-bitbang-gpio";
+ reg = <0x1064 0x4>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ };
+
+ spi0: spi-bitbang {
+ compatible = "spi-gpio";
+ status = "okay";
+ gpio-sck = <&gpio_spi_bitbang 6 0>;
+ gpio-miso = <&gpio_spi_bitbang 0 0>;
+ gpio-mosi = <&gpio_spi_bitbang 5 0>;
+ cs-gpios = <&gpio_spi_bitbang 1 0>;
+ num-chipselects = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+};
diff --git a/arch/mips/dts/mscc,ocelot.dtsi b/arch/mips/dts/mscc,ocelot.dtsi
new file mode 100644
index 00..81afdffd4b
--- /dev/null
+++ b/arch/mips/dts/mscc,ocelot.dtsi
@@ -0,0 +1,132 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+/ {
+ #address-cells = <1>;
[U-Boot] [PATCH 3/6] MSCC: add board support for the VCoreIII based evaluation boards
Adding the support for 3 boards sharing common code:
- PCB120 and PCB 123 for Ocelot chip
- PCB 91 for Luton chip
Signed-off-by: Gregory CLEMENT
---
board/mscc/common/board.c | 29 +
board/mscc/luton/Kconfig | 14 ++
board/mscc/luton/Makefile | 4
board/mscc/luton/luton.c | 14 ++
board/mscc/ocelot/Kconfig | 24
board/mscc/ocelot/Makefile | 5 +
board/mscc/ocelot/ocelot.c | 38 ++
7 files changed, 128 insertions(+)
create mode 100644 board/mscc/common/board.c
create mode 100644 board/mscc/luton/Kconfig
create mode 100644 board/mscc/luton/Makefile
create mode 100644 board/mscc/luton/luton.c
create mode 100644 board/mscc/ocelot/Kconfig
create mode 100644 board/mscc/ocelot/Makefile
create mode 100644 board/mscc/ocelot/ocelot.c
diff --git a/board/mscc/common/board.c b/board/mscc/common/board.c
new file mode 100644
index 00..86e7bf3353
--- /dev/null
+++ b/board/mscc/common/board.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_early_init_r(void)
+{
+ u32 ctrl;
+
+ /* Prepare SPI controller to be used in master mode */
+ writel(0, REG_CFG(ICPU_SW_MODE));
+ ctrl = readl(REG_CFG(ICPU_GENERAL_CTRL));
+
+ writel((ctrl & ~ICPU_GENERAL_CTRL_IF_SI_OWNER_M) |
+ ICPU_GENERAL_CTRL_IF_SI_OWNER(2),
+ REG_CFG(ICPU_GENERAL_CTRL));
+
+ /* Address of boot parameters */
+ gd->bd->bi_boot_params = CONFIG_SYS_SDRAM_BASE;
+ return 0;
+}
diff --git a/board/mscc/luton/Kconfig b/board/mscc/luton/Kconfig
new file mode 100644
index 00..e1199808d5
--- /dev/null
+++ b/board/mscc/luton/Kconfig
@@ -0,0 +1,14 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+if SOC_LUTON
+
+config SYS_VENDOR
+ default "mscc"
+
+config SYS_BOARD
+ default "luton"
+
+config SYS_CONFIG_NAME
+ default "luton"
+
+endif
diff --git a/board/mscc/luton/Makefile b/board/mscc/luton/Makefile
new file mode 100644
index 00..98bc47ba82
--- /dev/null
+++ b/board/mscc/luton/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+obj-$(CONFIG_SOC_LUTON):= luton.o
+obj-y += ../common/board.o
diff --git a/board/mscc/luton/luton.c b/board/mscc/luton/luton.c
new file mode 100644
index 00..8c31bbb12a
--- /dev/null
+++ b/board/mscc/luton/luton.c
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+#include
+
+void board_debug_uart_init(void)
+{
+ /* too early for the pinctrl driver, so configure the UART pins here */
+ writel(BIT(30)|BIT(31), REG_GCB((0x68+8*4)));
+ writel(~(BIT(30)|BIT(31)), REG_GCB((0x68+9*4)));
+}
diff --git a/board/mscc/ocelot/Kconfig b/board/mscc/ocelot/Kconfig
new file mode 100644
index 00..0804f5081d
--- /dev/null
+++ b/board/mscc/ocelot/Kconfig
@@ -0,0 +1,24 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+config SYS_VENDOR
+ default "mscc"
+
+if SOC_OCELOT
+
+config SYS_BOARD
+ default "ocelot"
+
+config SYS_CONFIG_NAME
+ default "ocelot"
+
+endif
+
+if SOC_LUTON
+
+config SYS_BOARD
+ default "luton"
+
+config SYS_CONFIG_NAME
+ default "luton"
+
+endif
diff --git a/board/mscc/ocelot/Makefile b/board/mscc/ocelot/Makefile
new file mode 100644
index 00..f6a665ca83
--- /dev/null
+++ b/board/mscc/ocelot/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+obj-$(CONFIG_SOC_OCELOT) := ocelot.o
+obj-y += ../common/board.o
+
diff --git a/board/mscc/ocelot/ocelot.c b/board/mscc/ocelot/ocelot.c
new file mode 100644
index 00..971fa93d07
--- /dev/null
+++ b/board/mscc/ocelot/ocelot.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2018 Microsemi Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void external_cs_manage(struct udevice *dev, bool enable)
+{
+ u32 cs = spi_chip_select(dev);
+/* IF_SI0_OWNER, select the owner of the SI interface
+ * Encoding: 0: SI Slave
+ * 1: SI Boot Master
+ * 2: SI Master Controller
+ */
+if (!enable) {
+writel(ICPU_SW_MODE_SW_PIN_CTRL_MODE |
+ ICPU_SW_MODE_SW_SPI_CS(BIT(cs)),
+ REG_CFG(ICPU_SW_MODE));
+writel((readl(REG_CFG(ICPU_GENERAL_CTRL))
+ & ~ICPU_GENERAL_CTRL_IF_SI_OWNER_M) |
+ ICPU_GENERAL_CTRL_IF_SI_OWNER(2),
+ REG_CFG(ICPU_GENERAL_CTRL));
+} else {
+writel(0, REG_CFG(ICPU_SW_MODE));
+writel((readl(REG_CFG(ICPU_GENERAL_CTRL)) &
+
[U-Boot] [PATCH 1/6] MIPS: move create_tlb() in an proper header: mipsregs.h
Export create_tlb() as an inline function in mipsregs.h. It allows to
remove the declaration of the function from the board files.
Then it will allow also to use this function very early in the boot when
the stack is not usable.
Signed-off-by: Gregory CLEMENT
---
arch/mips/cpu/cpu.c | 10 --
arch/mips/include/asm/mipsregs.h | 11 +++
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/arch/mips/cpu/cpu.c b/arch/mips/cpu/cpu.c
index 5c56ab0289..a403ff729b 100644
--- a/arch/mips/cpu/cpu.c
+++ b/arch/mips/cpu/cpu.c
@@ -28,16 +28,6 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
}
#endif
-void write_one_tlb(int index, u32 pagemask, u32 hi, u32 low0, u32 low1)
-{
- write_c0_entrylo0(low0);
- write_c0_pagemask(pagemask);
- write_c0_entrylo1(low1);
- write_c0_entryhi(hi);
- write_c0_index(index);
- tlb_write_indexed();
-}
-
int arch_cpu_init(void)
{
mips_cache_probe();
diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 48fa1f1f7f..930562ebb2 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -2005,6 +2005,17 @@ static inline unsigned int get_ebase_cpunum(void)
return read_c0_ebase() & 0x3ff;
}
+static inline void write_one_tlb(int index, u32 pagemask, u32 hi, u32 low0,
+u32 low1)
+{
+ write_c0_entrylo0(low0);
+ write_c0_pagemask(pagemask);
+ write_c0_entrylo1(low1);
+ write_c0_entryhi(hi);
+ write_c0_index(index);
+ tlb_write_indexed();
+}
+
#endif /* !__ASSEMBLY__ */
#endif /* _ASM_MIPSREGS_H */
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/6] Add support for VCore III SoCs found in Microsemi switches
Hello, This series add the support of 2 SoCs: Ocelot and Luton from Microsemi. Both of them belongs to the same family Vcore III. We found them on various advanced switches product. The support for Ocelot already have been submit to Linux, but not yet the Luton support. Besides this series 3 others patches are needed but they are driver related: DW SPI: Allow to overload the management of the external CS gpio: mscc-bitbang-spi: Add a simple gpio driver for bitbgang spi pinctrl: mscc: Add gpio and pinctrl driver for MSCC MIPS SoCs (VcoreIII based) They will be submitted separately. Thanks, Gregory Gregory CLEMENT (6): MIPS: move create_tlb() in an proper header: mipsregs.h MSCC: add support for VCoreIII SoCs MSCC: add board support for the VCoreIII based evaluation boards MSCC: add device tree for Ocelot and Luton (boards and SoCs) MSCC: add configuration for Ocelot and Luton based boards MIPS: bootm: Add support for Vcore III linux kernel arch/mips/Kconfig | 6 + arch/mips/Makefile| 1 + arch/mips/cpu/cpu.c | 10 - arch/mips/dts/luton_pcb091.dts| 36 + arch/mips/dts/mscc,luton.dtsi | 87 ++ arch/mips/dts/mscc,ocelot.dtsi| 132 +++ arch/mips/dts/mscc,ocelot_pcb.dtsi| 37 + arch/mips/dts/ocelot_pcb120.dts | 12 + arch/mips/dts/ocelot_pcb123.dts | 12 + arch/mips/include/asm/mipsregs.h | 11 + arch/mips/lib/bootm.c | 62 +- arch/mips/mach-mscc/Kconfig | 101 ++ arch/mips/mach-mscc/Makefile | 6 + arch/mips/mach-mscc/cpu.c | 72 ++ arch/mips/mach-mscc/dram.c| 62 ++ arch/mips/mach-mscc/include/ioremap.h | 49 + arch/mips/mach-mscc/include/mach/cache.h | 36 + arch/mips/mach-mscc/include/mach/common.h | 31 + arch/mips/mach-mscc/include/mach/ddr.h| 753 +++ .../mips/mach-mscc/include/mach/luton/luton.h | 37 + .../include/mach/luton/luton_devcpu_gcb.h | 16 + .../include/mach/luton/luton_icpu_cfg-ref.h | 884 ++ .../include/mach/luton/luton_icpu_cfg.h | 247 + .../mach-mscc/include/mach/ocelot/ocelot.h| 35 + .../include/mach/ocelot/ocelot_devcpu_gcb.h | 353 +++ .../include/mach/ocelot/ocelot_icpu_cfg.h | 884 ++ arch/mips/mach-mscc/include/mach/tlb.h| 65 ++ arch/mips/mach-mscc/lowlevel_init.S | 29 + arch/mips/mach-mscc/lowlevel_init_luton.S | 63 ++ arch/mips/mach-mscc/reset.c | 37 + board/mscc/common/board.c | 29 + board/mscc/luton/Kconfig | 14 + board/mscc/luton/Makefile | 4 + board/mscc/luton/luton.c | 14 + board/mscc/ocelot/Kconfig | 24 + board/mscc/ocelot/Makefile| 5 + board/mscc/ocelot/ocelot.c| 38 + configs/mscc_luton_defconfig | 66 ++ configs/mscc_ocelot_defconfig | 57 ++ configs/mscc_ocelot_pcb120_defconfig | 56 ++ include/configs/vcoreiii.h| 72 ++ 41 files changed, 4515 insertions(+), 30 deletions(-) create mode 100644 arch/mips/dts/luton_pcb091.dts create mode 100644 arch/mips/dts/mscc,luton.dtsi create mode 100644 arch/mips/dts/mscc,ocelot.dtsi create mode 100644 arch/mips/dts/mscc,ocelot_pcb.dtsi create mode 100644 arch/mips/dts/ocelot_pcb120.dts create mode 100644 arch/mips/dts/ocelot_pcb123.dts create mode 100644 arch/mips/mach-mscc/Kconfig create mode 100644 arch/mips/mach-mscc/Makefile create mode 100644 arch/mips/mach-mscc/cpu.c create mode 100644 arch/mips/mach-mscc/dram.c create mode 100644 arch/mips/mach-mscc/include/ioremap.h create mode 100644 arch/mips/mach-mscc/include/mach/cache.h create mode 100644 arch/mips/mach-mscc/include/mach/common.h create mode 100644 arch/mips/mach-mscc/include/mach/ddr.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_icpu_cfg-ref.h create mode 100644 arch/mips/mach-mscc/include/mach/luton/luton_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/tlb.h create mode 100644 arch/mips/mach-mscc/lowlevel_init.S create mode 100644 arch/mips/mach-mscc/lowlevel_init_luton.S create mode 100644 arch/mips/mach-mscc/reset.c create mode 100644 board/mscc/common/board.c create mode 100644 board/mscc/luton/Kconfig create mode 100644 board/mscc/luton/Makefile create mode
Re: [U-Boot] [PATCH v2 1/2] efi_loader: typedef struct efi_object *efi_handle_t
On 09/25/2018 01:15 PM, Mark Kettenis wrote: >> From: Heinrich Schuchardt >> Date: Tue, 25 Sep 2018 12:19:17 +0200 >> >> All our handles point to a struct efi_object. So let's define the >> efi_handle_t accordingly. This helps us to discover coding errors much >> more easily. This becomes evident by the corrections to the usage of >> handles in this patch. >> >> Signed-off-by: Heinrich Schuchardt >> --- >> v2 >> no change >> --- >> cmd/bootefi.c | 4 ++-- >> include/efi.h | 2 +- >> include/efi_api.h | 8 >> lib/efi/efi.c | 2 +- >> lib/efi_loader/efi_boottime.c | 18 +- >> lib/efi_selftest/efi_selftest_devicepath.c | 2 +- >> 6 files changed, 18 insertions(+), 18 deletions(-) >> >> diff --git a/cmd/bootefi.c b/cmd/bootefi.c >> index 9c51a2cbd1..05eb168e4a 100644 >> --- a/cmd/bootefi.c >> +++ b/cmd/bootefi.c >> @@ -447,7 +447,7 @@ static efi_status_t do_bootefi_exec(void *efi, >> } >> #endif >> >> -ret = efi_do_enter(image_handle, &systab, entry); >> +ret = efi_do_enter(&image_handle->parent, &systab, entry); > This bit makes absolutely no sense to me :(. What about the other > efi_do_enter() calls? And why is the variable called image_handle if > it isn't a handle? > >> Thanks for pointing to this misnomer. We should rename image_handle to image_obj in this function. And we should be consistent about how we pass the address. Regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/8] Improvements for the dwc3_generic driver
Dear All, > This series aims at bringing improvements to the dwc3_generic driver > so that it can be used by most of the platforms using the dwc3 > controller. > > I tested this on with DRA7 and AM57x platforms for both Peripheral > and Host operations. The code to enable DM USB host & dev support for > those platforms will be submitted in a separate series. > > Michal Simek has tested this series: > " I have tested it on zcu100 with usb stick, usb to ethernet > converter and also dfu. > Tested-by: Michal Simek " > > Enhancements: > - use separate Kconfig option for DM USB Periphal and DM USB Host. > This allow platforms to keep their non-DM USB peripheral code and use > the DM USB host. > - fixes the bind/probe confusion in dwc3_generic. The probe is done > when the USB device is first needed. > - handles PHYs when in the peripheral mode. The code to handle the > PHYs is shared with the host side > - handles clock and reset > - bind host controller to the more generic driver 'xhci-dwc3' > > > Changes in v3: > - fixes bug dwc3_setup_phy(): the phy arrays wasn't returned. This was > visible only when the device is removed. > - Stub the DWC3 PHY operations if CONFIG_IS_ENABLED(PHY) is false. > This fixes all build issues but one (evb-rk3328). > - Fix build issue with evb-rk3328 by enabling CONFIG_USB_DWC3. This > has little impact on the footprint and should not break the runtime > as the xhci-rockchip driver has its own probe function. > Nevertheless this was !!! NOT TESTED !!! by lack of hw Can somebody test this patch set on rk3328 and provide Tested-by tag? > > Changes in v2: > - Updated commit log > - Fixed typo in thordown.c > - select DM_USB_DEV by default for zynqmp platforms > > Jean-Jacques Hiblot (8): > usb: gadget: Do not call board_usb_xxx() directly in USB gadget > drivers > usb: introduce a separate config option for DM USB device > usb: udc: implement DM versions of > usb_gadget_initialize()/_release()/_handle_interrupt() > dwc3_generic: do not probe the USB device driver when it's bound > dwc3: move phy operation to core.c > configs: evb-rk3328: Enable CONFIG_USB_DWC3 > dwc3-generic: Handle the PHYs, the clocks and the reset lines > dwc3-generic: Add select_dr_mode operation > > arch/arm/Kconfig | 2 + > cmd/fastboot.c| 4 +- > cmd/rockusb.c | 4 +- > cmd/thordown.c| 4 +- > cmd/usb_gadget_sdp.c | 4 +- > cmd/usb_mass_storage.c| 4 +- > common/dfu.c | 6 +- > configs/evb-rk3328_defconfig | 1 + > drivers/usb/Kconfig | 6 ++ > drivers/usb/dwc3/Kconfig | 7 +- > drivers/usb/dwc3/core.c | 89 +++- > drivers/usb/dwc3/dwc3-generic.c | 207 > +- > drivers/usb/dwc3/ep0.c| 1 - > drivers/usb/gadget/ether.c| 38 +-- > drivers/usb/gadget/udc/udc-core.c | 44 +++- > drivers/usb/host/xhci-dwc3.c | 95 ++--- > include/dwc3-uboot.h | 19 > include/linux/usb/gadget.h| 18 18 files changed, 367 > insertions(+), 186 deletions(-) > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de pgpbiboLNPIAZ.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
