Re: [U-Boot] [PATCH v3 6/6] spi: kirkwood: Full dm conversion
Am 2018-11-05 10:58, schrieb Jagan Teki: On Mon, May 7, 2018 at 2:40 PM Jagan Teki wrote: kirkwood now support dt along with platform data, respective boards need to switch into dm for the same. Signed-off-by: Jagan Teki --- Changes for v3: - rebased master - Move kconfig option if DM_SPI drivers/spi/Kconfig | 12 +- drivers/spi/kirkwood_spi.c | 240 ++-- include/dm/platform_data/spi_kirkwood.h | 15 ++ 3 files changed, 62 insertions(+), 205 deletions(-) create mode 100644 include/dm/platform_data/spi_kirkwood.h Any update from the board maintainers about this changes, I would like to push this sooner as possible. Hi, oh isn't this merged yet? Because my change [1] which depends on that made it already into the main tree [2]. [1] http://git.denx.de/?p=u-boot.git;a=commit;h=134a6b6884c1faa893256ac5b02a301d0be863c8 [2] https://patchwork.ozlabs.org/patch/922392/ -michael ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Wed, 2018-11-14 at 12:52 +0100, Marek Vasut wrote:
> On 11/14/2018 08:09 AM, Ang, Chee Hong wrote:
> >
> > On Thu, 2018-10-11 at 10:03 +, Marek Vasut wrote:
> > >
> > > On 10/11/2018 08:21 AM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Enable 'fpga' command in u-boot. User will be
> > > > > > > > > > > > able
> > > > > > > > > > > > to
> > > > > > > > > > > > use
> > > > > > > > > > > > the
> > > > > > > > > > > > fpga
> > > > > > > > > > > > command to program the FPGA on Stratix10 SoC.
> > > > > > > > > > > >
> > > > > > > > > > > > Signed-off-by: Ang, Chee Hong > > > > > > > > > > > tel.
> > > > > > > > > > > > com>
> > > > > > > > > > > > ---
> > > > > > > > > > > > arch/arm/mach-socfpga/misc.c | 29
> > > > > > > > > > > > +
> > > > > > > > > > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > > > > > > > > > > drivers/fpga/altera.c| 6 ++
> > > > > > > > > > > > include/altera.h | 4
> > > > > > > > > > > > 4 files changed, 41 insertions(+)
> > > > > > > > > > > >
> > > > > > > > > > > > diff --git a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > > > socfpga/misc.c
> > > > > > > > > > > > index a4f6d5c..7986b58 100644
> > > > > > > > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > > > > > > > > > #endif
> > > > > > > > > > > >
> > > > > > > > > > > > #ifdef CONFIG_FPGA
> > > > > > > > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > > > > > > > > +/*
> > > > > > > > > > > > + * FPGA programming support for SoC FPGA
> > > > > > > > > > > > Stratix
> > > > > > > > > > > > 10
> > > > > > > > > > > > + */
> > > > > > > > > > > > +static Altera_desc altera_fpga[] = {
> > > > > > > > > > > > + {
> > > > > > > > > > > > + /* Family */
> > > > > > > > > > > > + Intel_FPGA_Stratix10,
> > > > > > > > > > > > + /* Interface type */
> > > > > > > > > > > > + secure_device_manager_mailbox,
> > > > > > > > > > > > + /* No limitation as additional
> > > > > > > > > > > > data
> > > > > > > > > > > > will
> > > > > > > > > > > > be
> > > > > > > > > > > > ignored */
> > > > > > > > > > > > + -1,
> > > > > > > > > > > > + /* No device function table */
> > > > > > > > > > > > + NULL,
> > > > > > > > > > > > + /* Base interface address
> > > > > > > > > > > > specified in
> > > > > > > > > > > > driver
> > > > > > > > > > > > */
> > > > > > > > > > > > + NULL,
> > > > > > > > > > > > + /* No cookie implementation */
> > > > > > > > > > > > + 0
> > > > > > > > > > > > + },
> > > > > > > > > > > > +};
> > > > > > > > > > > > +#else
> > > > > > > > > > > > /*
> > > > > > > > > > > > * FPGA programming support for SoC FPGA
> > > > > > > > > > > > Cyclone V
> > > > > > > > > > > > */
> > > > > > > > > > > > @@ -107,6 +128,7 @@ static Altera_desc
> > > > > > > > > > > > altera_fpga[] =
> > > > > > > > > > > > {
> > > > > > > > > > > > 0
> > > > > > > > > > > > },
> > > > > > > > > > > > };
> > > > > > > > > > > > +#endif
> > > > > > > > > > > >
> > > > > > > > > > > > /* add device descriptor to FPGA device table
> > > > > > > > > > > > */
> > > > > > > > > > > > void socfpga_fpga_add(void)
> > > > > > > > > > > > @@ -116,6 +138,13 @@ void
> > > > > > > > > > > > socfpga_fpga_add(void)
> > > > > > > > > > > > for (i = 0; i <
> > > > > > > > > > > >
Re: [U-Boot] [PATCH 15/15] imx: add i.MX8MQ EVK support
*snip*
> --- /dev/null
> +++ b/board/freescale/imx8mq_evk/lpddr4_timing.c
> @@ -0,0 +1,2104 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 NXP
> + */
> +
> +#include
> +#include
> +#include
> +
> +#define LPDDR4_HDT_CTL_2D 0xC8 /* stage completion */
> +#define LPDDR4_HDT_CTL_3200_1D 0xC8 /* stage completion */
> +#define LPDDR4_HDT_CTL_400_1D 0xC8 /* stage completion */
> +#define LPDDR4_HDT_CTL_100_1D 0xC8 /* stage completion */
> +
> +// 400/100 training seq
> +#define LPDDR4_TRAIN_SEQ_100 0x121f
> +#define LPDDR4_TRAIN_SEQ_400 0x121f
> +
> +//2D share & weight
> +#define LPDDR4_2D_WEIGHT 0x1f7f
> +#define LPDDR4_2D_SHARE1
> +#define LPDDR4_CATRAIN_3200_1d 0
> +#define LPDDR4_CATRAIN_400 0
> +#define LPDDR4_CATRAIN_100 0
> +#define LPDDR4_CATRAIN_3200_2d 0
> +
> +#define WR_POST_EXT_3200 /* recommened to define */
> +
> +/* for LPDDR4 Rtt */
> +#define LPDDR4_RTT40 6
> +#define LPDDR4_RTT48 5
> +#define LPDDR4_RTT60 4
> +#define LPDDR4_RTT80 3
> +#define LPDDR4_RTT120 2
> +#define LPDDR4_RTT240 1
> +#define LPDDR4_RTT_DIS 0
Are these board specific? They seem like they should be defined in ddr.h
> +
> +/* for LPDDR4 Ron */
> +#define LPDDR4_RON34 7
> +#define LPDDR4_RON40 6
> +#define LPDDR4_RON48 5
> +#define LPDDR4_RON60 4
> +#define LPDDR4_RON80 3
ditto.
> +
> +#define LPDDR4_PHY_ADDR_RON60 0x1
> +#define LPDDR4_PHY_ADDR_RON40 0x3
> +#define LPDDR4_PHY_ADDR_RON30 0x7
> +#define LPDDR4_PHY_ADDR_RON24 0xf
> +#define LPDDR4_PHY_ADDR_RON20 0x1f
> +
> +/* for read channel */
> +#define LPDDR4_RON LPDDR4_RON40 /* MR3[5:3] */
> +#define LPDDR4_PHY_RTT 30
> +#define LPDDR4_PHY_VREF_VALUE 17
> +
> +/* for write channel */
> +#define LPDDR4_PHY_RON 30
> +#define LPDDR4_PHY_ADDR_RONLPDDR4_PHY_ADDR_RON40
> +#define LPDDR4_RTT_DQ LPDDR4_RTT40 /* MR11[2:0] */
> +#define LPDDR4_RTT_CA LPDDR4_RTT40 /* MR11[6:4] */
> +#define LPDDR4_RTT_CA_BANK0LPDDR4_RTT40 /* MR11[6:4] */
> +#define LPDDR4_RTT_CA_BANK1LPDDR4_RTT40 /* LPDDR4_RTT_DIS */
do these values ever differ? seems like it would be better to use
LPDDR_RTT and then have the board file #define LPDRR4_RTT to
LPDDR4_RTT40
> +#define LPDDR4_VREF_VALUE_CA ((1 << 6) | (0xd)) /* MR12 */
> +#define LPDDR4_VREF_VALUE_DQ_RANK0 ((1 << 6) | (0xd)) /* MR14 */
> +#define LPDDR4_VREF_VALUE_DQ_RANK1 ((1 << 6) | (0xd)) /* MR14 */
> +#define LPDDR4_MR22_RANK0 ((0 << 5) | (1 << 4) | (0 << 3) | \
> + (LPDDR4_RTT40)) /* MR22: OP[5:3]ODTD-CA,CS,CK */
> +#define LPDDR4_MR22_RANK1 ((0 << 5) | (1 << 4) | (0 << 3) | \
> + (LPDDR4_RTT40)) /* MR22: OP[5:3]ODTD-CA,CS,CK */
> +#define LPDDR4_MR3_PU_CAL 1 /* MR3[0] */
> +
*snip*
> +
> +/* PHY Initialize Configuration */
> +struct dram_cfg_param lpddr4_ddrphy_cfg[] = {
> + { 0x213149, 0xfbe },
> +
> + { 0x43, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x1043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x2043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x3043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x4043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x5043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x6043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x7043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x8043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
> + { 0x9043, ((LPDDR4_PHY_ADDR_RON << 5) | LPDDR4_PHY_ADDR_RON) },
Are there any benefits to not just using the register writes here?
> +
> + { 0x20018, 0x3 },
*snip*
> +
> +/* ddr phy trained csr */
> +struct dram_cfg_param lpddr4_ddrphy_trained_csr[] = {
> + { 0x200b2, 0x0 },
> + { 0x1200b2, 0x0 },
> + { 0x2200b2, 0x0 },
> + { 0x200cb, 0x0 },
> + { 0x10043, 0x0 },
> + { 0x110043, 0x0 },
> + { 0x210043, 0x0 },
> + { 0x10143, 0x0 },
> + { 0x110143, 0x0 },
> + { 0x210143, 0x0 },
> + { 0x11043, 0x0 },
> + { 0x111043, 0x0 },
> + { 0x211043, 0x0 },
> + { 0x11143, 0x0 },
> + { 0x43, 0x0 },
> + { 0x211143, 0x0 },
> + { 0x12043, 0x0 },
> + { 0x112043, 0x0 },
> + { 0x212043, 0x0 },
> + { 0x12143, 0x0 },
> + { 0x112143, 0x0 },
> + { 0x212143, 0x0 },
> + { 0x13043, 0x0 },
> + { 0x113043, 0x0 },
> + { 0x213043, 0x0 },
> + { 0x13143, 0x0 },
> + { 0x113143, 0x0 },
> + { 0x213143, 0x0 },
> + { 0x80, 0x0 },
> + { 0x100080, 0x0 },
> + { 0x200080, 0x0 },
> + { 0x1080, 0x0 },
> + { 0x101080, 0x0 },
> + { 0x201080, 0x0 },
> + { 0x2080, 0x0 },
> + { 0x102080,
Re: [U-Boot] efi disks in u-boot
Hi Simon,
On Wed, 14 Nov 2018 at 03:52, Simon Glass wrote:
>
> Hi Akahsi,
>
> On 5 November 2018 at 20:15, AKASHI Takahiro
> wrote:
> > Hello Simon,
> >
> > You said, in efi/lib_loader/efi_disk.c,
> >
> > ===8<===
> > * TODO(s...@chromium.org): Actually with CONFIG_BLK, U-Boot does have this.
> > * Consider converting the code to look up devices as needed. The EFI device
> > * could be a child of the UCLASS_BLK block device, perhaps.
> > *
> > * This gets called from do_bootefi_exec().
> > */
> > efi_status_t efi_disk_register(void)
> > {
> > ===>8===
> >
> > What do you mean by this statement?
> > Is it different from the code under "#if CONFIG_BLK"?
> >
> > I guess that you would suggest that some hook function be called
> > in blk_create_device() and blk_unbind_all(). No?
>
> I would actually like EFI to use the U-Boot DM devices directly, with
> just the minimal amount of plumbing.
Under the current implementation, any u-boot disk device is statically
associated with device path proctocol as well as block io protocol & file
system protocol only once in efi_init_obj_list().
If I understand you correctly, you're suggesting that, for example,
efi_disk_from_path() should directly search for a u-boot device
instead of look into a pre-created list of device path protocol objects
with efi_search_protocol(). Right?
It sounds reasonable and quite straight forward, but I wonder why Alex
and Rob didn't take this approach. Was there any discussion in the past?
Thanks,
-Takahiro Akashi
> Perhaps an EFI child device that
> gets created for each block device?
>
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv7r: K3: Allow SPL to run only on core 0
Based on the MCU R5 efuse settings, R5F cores in MCU domain either work in split mode or in lock step mode. If efuse settings are in lockstep mode: ROM release R5 cores and SPL continues to run on the R5 core is lockstep mode. If efuse settings are in split mode: ROM releases both the R5 cores simultaneously and allow SPL to run on both the cores. In this case it is bootloader's responsibility to detect core 1 and park it. Else both the core will be running bootloader independently which might result in an unexpected behaviour. Signed-off-by: Lokesh Vutla --- - Depends on the series: https://patchwork.ozlabs.org/project/uboot/list/?series=73801 arch/arm/mach-k3/Makefile| 2 +- arch/arm/mach-k3/lowlevel_init.S | 20 include/configs/am65x_evm.h | 2 ++ 3 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-k3/lowlevel_init.S diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index 406dda3b02..bd4ab361b2 100644 --- a/arch/arm/mach-k3/Makefile +++ b/arch/arm/mach-k3/Makefile @@ -5,5 +5,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o obj-$(CONFIG_ARM64) += arm64-mmu.o -obj-$(CONFIG_CPU_V7R) += r5_mpu.o +obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o obj-y += common.o diff --git a/arch/arm/mach-k3/lowlevel_init.S b/arch/arm/mach-k3/lowlevel_init.S new file mode 100644 index 00..70c5d1cade --- /dev/null +++ b/arch/arm/mach-k3/lowlevel_init.S @@ -0,0 +1,20 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/ + * Lokesh Vutla + */ + +#include + +ENTRY(lowlevel_init) + + mrc p15, 0, r0, c0, c0, 5 @ Read MPIDR + and r0, #0xff + cmp r0, #0x0 + bne park_cpu + bx lr +park_cpu: + wfi + b park_cpu + +ENDPROC(lowlevel_init) diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h index 484c5ef2fe..31749c6d06 100644 --- a/include/configs/am65x_evm.h +++ b/include/configs/am65x_evm.h @@ -29,7 +29,9 @@ #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"tispl.bin" #endif +#ifndef CONFIG_CPU_V7R #define CONFIG_SKIP_LOWLEVEL_INIT +#endif #define CONFIG_SPL_MAX_SIZECONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SPL_TEXT_BASE +\ -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_loader: remove efi_exit_caches()
On Sun, Sep 23, 2018 at 02:33:47PM +0200, Heinrich Schuchardt wrote:
> Since GRUB patch d0c070179d4d ("arm/efi: Switch to arm64 linux loader",
> 2018-07-09) we do not need a workaround for GRUB on 32bit ARM anymore.
>
> So let's eliminate function efi_exit_caches().
>
> This will require Linux distributions to update grub-efi-arm to the GRUB
> git HEAD (a tag containing the aforementioned GRUB patch is not available
> yet).
OpenBSD/armv7 can no longer boot with U-Boot after this commit as
it currently does not explicitly invalidate/flush caches in efiboot.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_boottime.c | 28
> 1 file changed, 28 deletions(-)
>
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index 2496608981..97eb19cd14 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -26,14 +26,6 @@ LIST_HEAD(efi_obj_list);
> /* List of all events */
> LIST_HEAD(efi_events);
>
> -/*
> - * If we're running on nasty systems (32bit ARM booting into non-EFI Linux)
> - * we need to do trickery with caches. Since we don't want to break the EFI
> - * aware boot path, only apply hacks when loading exiting directly (breaking
> - * direct Linux EFI booting along the way - oh well).
> - */
> -static bool efi_is_direct_boot = true;
> -
> #ifdef CONFIG_ARM
> /*
> * The "gd" pointer lives in a register on ARM and AArch64 that we declare
> @@ -1686,8 +1678,6 @@ static efi_status_t EFIAPI efi_start_image(efi_handle_t
> image_handle,
>
> EFI_ENTRY("%p, %p, %p", image_handle, exit_data_size, exit_data);
>
> - efi_is_direct_boot = false;
> -
> /* call the image! */
> if (setjmp(_obj->exit_jmp)) {
> /*
> @@ -1795,21 +1785,6 @@ static efi_status_t EFIAPI
> efi_unload_image(efi_handle_t image_handle)
> return EFI_EXIT(EFI_SUCCESS);
> }
>
> -/**
> - * efi_exit_caches() - fix up caches for EFI payloads if necessary
> - */
> -static void efi_exit_caches(void)
> -{
> -#if defined(CONFIG_ARM) && !defined(CONFIG_ARM64)
> - /*
> - * Grub on 32bit ARM needs to have caches disabled before jumping into
> - * a zImage, but does not know of all cache layers. Give it a hand.
> - */
> - if (efi_is_direct_boot)
> - cleanup_before_linux();
> -#endif
> -}
> -
> /**
> * efi_exit_boot_services() - stop all boot services
> * @image_handle: handle of the loaded image
> @@ -1863,9 +1838,6 @@ static efi_status_t EFIAPI
> efi_exit_boot_services(efi_handle_t image_handle,
>
> board_quiesce_devices();
>
> - /* Fix up caches for EFI payloads if necessary */
> - efi_exit_caches();
> -
> /* This stops all lingering devices */
> bootm_disable_interrupts();
>
> --
> 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
[U-Boot] [PATCH v3] cmd, fdt: add subcommand "get" to fdt header
store fdt header member with name in U-Boot
Environment variable with name .
for example to get the total length of the fdt and store
it in filesize, call:
fdt header get filesize totalsize
For membernames look into fdt header definition at
scripts/dtc/libfdt/libfdt.h
Signed-off-by: Heiko Schocher
---
Changes in v3:
- add comments from Marek
simplify for loop, use fdtp[i] -> drop ftdip++
Changes in v2:
- add obviously missing "static const char *"
cmd/fdt.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index 8a19a3fdbf..8bfa731a9e 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -73,6 +73,40 @@ static int fdt_value_env_set(const void *nodep, int len,
const char *var)
return 0;
}
+static const char * const fdt_member_table[] = {
+ "magic",
+ "totalsize",
+ "off_dt_struct",
+ "off_dt_strings",
+ "off_mem_rsvmap",
+ "version",
+ "last_comp_version",
+ "boot_cpuid_phys",
+ "size_dt_strings",
+ "size_dt_struct",
+};
+
+static int fdt_get_header_value(int argc, char * const argv[])
+{
+ fdt32_t *fdtp = (fdt32_t *)working_fdt;
+ ulong val;
+ int i;
+
+ if (argv[2][0] != 'g')
+ return CMD_RET_FAILURE;
+
+ for (i = 0; i < ARRAY_SIZE(fdt_member_table); i++) {
+ if (strcmp(fdt_member_table[i], argv[4]))
+ continue;
+
+ val = fdt32_to_cpu(fdtp[i]);
+ env_set_hex(argv[3], val);
+ return CMD_RET_SUCCESS;
+ }
+
+ return CMD_RET_FAILURE;
+}
+
/*
* Flattened Device Tree command, see the help for parameter definitions.
*/
@@ -491,6 +525,9 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
* Display header info
*/
} else if (argv[1][0] == 'h') {
+ if (argc == 5)
+ return fdt_get_header_value(argc, argv);
+
u32 version = fdt_version(working_fdt);
printf("magic:\t\t\t0x%x\n", fdt_magic(working_fdt));
printf("totalsize:\t\t0x%x (%d)\n", fdt_totalsize(working_fdt),
@@ -1090,7 +1127,8 @@ static char fdt_help_text[] =
"fdt set []- Set [to ]\n"
"fdt mknode - Create a new node after \n"
"fdt rm [] - Delete the node or \n"
- "fdt header - Display header info\n"
+ "fdt header [get ] - Display header info\n"
+ " get - get header member
and store it in \n"
"fdt bootcpu - Set boot cpuid\n"
"fdt memory - Add/Update memory node\n"
"fdt rsvmem print- Show current mem reserves\n"
--
2.17.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] efi_loader: remove block device details from efi file
Logically, details on u-boot block device used to implement efi file
protocol are mostly unnecessary, as well as being duplicated, in
efi_file structure.
Moreover, a newly introduced flag, _EFI_DISK_FLAG_INVALID, should be
honored in any file operations via efi file protocol.
These observation suggests that those internal details be set behind
efi_disk object.
So rework in this patch addresses all those issues above although
there is little change in its functionality.
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 6 +-
lib/efi_loader/efi_disk.c | 38 --
lib/efi_loader/efi_file.c | 21 -
3 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 3bae1844befb..108ef3fe52ee 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -264,6 +264,10 @@ efi_status_t efi_disk_register(void);
bool efi_disk_is_valid(efi_handle_t handle);
/* Called by bootefi to find and update disk storage information */
efi_status_t efi_disk_update(void);
+/* Called by file protocol to set internal block io device */
+int efi_disk_set_blk_dev(efi_handle_t disk);
+/* Called by file protocol to get disk/partition information */
+int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part);
/* Create handles and protocols for the partitions of a block device */
int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
const char *if_typename, int diskid,
@@ -355,7 +359,7 @@ void efi_signal_event(struct efi_event *event, bool
check_tpl);
/* open file system: */
struct efi_simple_file_system_protocol *efi_simple_file_system(
- struct blk_desc *desc, int part, struct efi_device_path *dp);
+ efi_handle_t disk);
/* open file from device-path: */
struct efi_file_handle *efi_file_from_path(struct efi_device_path *fp);
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 0c4d79ee3fc9..180e8e10bb28 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -254,6 +255,40 @@ efi_fs_from_path(struct efi_device_path *full_path)
return handler->protocol_interface;
}
+/*
+ * Set block device for later block io's from file system protocol
+ *
+ * @disk handle to uefi disk device
+ * @return 0 for success, -1 for failure
+ */
+int efi_disk_set_blk_dev(efi_handle_t disk)
+{
+ struct efi_disk_obj *diskobj;
+
+ diskobj = container_of(disk, struct efi_disk_obj, header);
+
+ return fs_set_blk_dev_with_part(diskobj->desc, diskobj->part);
+}
+
+/*
+ * Get disk/partition information
+ *
+ * @disk handle to uefi disk device
+ * @part pointer to disk/partition information to be returned
+ * @return 0 for success, -1 for failure
+ */
+int efi_disk_get_info(efi_handle_t disk, disk_partition_t *part)
+{
+ struct efi_disk_obj *diskobj;
+
+ diskobj = container_of(disk, struct efi_disk_obj, header);
+
+ if (diskobj->part >= 1)
+ return part_get_info(diskobj->desc, diskobj->part, part);
+ else
+ return part_get_info_whole_disk(diskobj->desc, part);
+}
+
/*
* Create a handle for a partition or disk
*
@@ -308,8 +343,7 @@ static efi_status_t efi_disk_add_dev(
if (ret != EFI_SUCCESS)
return ret;
if (part >= 1) {
- diskobj->volume = efi_simple_file_system(desc, part,
-diskobj->dp);
+ diskobj->volume = efi_simple_file_system(>header);
ret = efi_add_protocol(>header,
_simple_file_system_protocol_guid,
diskobj->volume);
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index beb4fba917d8..944383224f30 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -17,9 +17,7 @@ const efi_guid_t efi_file_system_info_guid =
EFI_FILE_SYSTEM_INFO_GUID;
struct file_system {
struct efi_simple_file_system_protocol base;
- struct efi_device_path *dp;
- struct blk_desc *desc;
- int part;
+ efi_handle_t disk;
};
#define to_fs(x) container_of(x, struct file_system, base)
@@ -49,7 +47,10 @@ static char *basename(struct file_handle *fh)
static int set_blk_dev(struct file_handle *fh)
{
- return fs_set_blk_dev_with_part(fh->fs->desc, fh->fs->part);
+ if (!efi_disk_is_valid(fh->fs->disk))
+ return -1;
+
+ return efi_disk_set_blk_dev(fh->fs->disk);
}
/**
@@ -570,10 +571,7 @@ static efi_status_t EFIAPI efi_file_getinfo(struct
efi_file_handle *file,
efi_uintn_t required_size;
int r;
- if (fh->fs->part >= 1)
- r = part_get_info(fh->fs->desc,
[U-Boot] [PATCH v2 2/3] efi_loader: enumerate disk devices every time
Currently, efi_init_obj_list() scan disk devices only once, and never
change a list of efi disk devices. This will possibly result in failing
to find a removable storage which may be added later on. See [1].
In this patch, called is efi_disk_update() which is responsible for
re-scanning UCLASS_BLK devices and removing/adding efi disks if necessary.
For example,
=> efishell devices
Scanning disk pci_mmc.blk...
Found 3 disks
Device Name
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
=> usb start
starting USB...
USB0: USB EHCI 1.00
scanning bus 0 for devices... 3 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
=> efishell devices
Scanning disk usb_mass_storage.lun0...
Device Name
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/SD(0)/SD(0)/HD(2,MBR,0x086246ba,0x40800,0x3f800)
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/USBClass(0,0,9,0,1)/USBClass(46f4,1,0,0,0)/HD(1,0x01,0,0x40,0x14fe4c)
Without this patch, the last device, USB mass storage, won't show up.
[1] https://lists.denx.de/pipermail/u-boot/2018-October/345307.html
Signed-off-by: AKASHI Takahiro
---
cmd/bootefi.c | 17 +++-
include/efi_loader.h | 4 +
lib/efi_loader/efi_disk.c | 191 ++
3 files changed, 210 insertions(+), 2 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3cefb4d0ecaa..82649e211fda 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -56,9 +56,22 @@ efi_status_t efi_init_obj_list(void)
*/
efi_save_gd();
- /* Initialize once only */
- if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED)
+ if (efi_obj_list_initialized == EFI_SUCCESS) {
+#ifdef CONFIG_PARTITIONS
+ ret = efi_disk_update();
+ if (ret != EFI_SUCCESS)
+ printf("+++ updating disks list failed\n");
+
+ /*
+* It may sound odd, but most part of EFI should
+* yet work.
+*/
+#endif
return efi_obj_list_initialized;
+ } else if (efi_obj_list_initialized != OBJ_LIST_NOT_INITIALIZED) {
+ /* Initialize once only */
+ return efi_obj_list_initialized;
+ }
/* Initialize system table */
ret = efi_initialize_system_table();
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 5cc3bded03fa..3bae1844befb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -260,6 +260,10 @@ efi_status_t efi_initialize_system_table(void);
efi_status_t efi_console_register(void);
/* Called by bootefi to make all disk storage accessible as EFI objects */
efi_status_t efi_disk_register(void);
+/* Check validity of efi disk */
+bool efi_disk_is_valid(efi_handle_t handle);
+/* Called by bootefi to find and update disk storage information */
+efi_status_t efi_disk_update(void);
/* Create handles and protocols for the partitions of a block device */
int efi_disk_create_partitions(efi_handle_t parent, struct blk_desc *desc,
const char *if_typename, int diskid,
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index c037526ad2d0..0c4d79ee3fc9 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -14,10 +14,14 @@
const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
+#define _EFI_DISK_FLAG_DELETED 0x1 /* to be removed */
+#define _EFI_DISK_FLAG_INVALID 0x8000 /* in stale state */
+
/**
* struct efi_disk_obj - EFI disk object
*
* @header:EFI object header
+ * @flags: control flags
* @ops: EFI disk I/O protocol interface
* @ifname:interface name for block device
* @dev_index: device index of block device
@@ -30,6 +34,7 @@ const efi_guid_t efi_block_io_guid = BLOCK_IO_GUID;
*/
struct efi_disk_obj {
struct efi_object header;
+ int flags;
struct efi_block_io ops;
const char *ifname;
int dev_index;
@@ -41,6 +46,35 @@ struct efi_disk_obj {
struct blk_desc *desc;
};
+static void efi_disk_mark_deleted(struct efi_disk_obj *disk)
+{
+ disk->flags |= _EFI_DISK_FLAG_DELETED;
+}
+
+static void efi_disk_clear_deleted(struct efi_disk_obj *disk)
+{
+ disk->flags &= ~_EFI_DISK_FLAG_DELETED;
+}
+
+static bool efi_disk_deleted_marked(struct efi_disk_obj *disk)
+{
+ return disk->flags & _EFI_DISK_FLAG_DELETED;
+}
+
+static void efi_disk_mark_invalid(struct efi_disk_obj *disk)
+{
+ disk->flags |= _EFI_DISK_FLAG_INVALID;
+}
+
+bool efi_disk_is_valid(efi_handle_t handle)
+{
+ struct efi_disk_obj *disk;
+
+ disk = container_of(handle,
[U-Boot] [PATCH v2 1/3] efi_loader: export efi_locate_handle() function
This function will be used later to implement efi_disk_update().
Signed-off-by: AKASHI Takahiro
---
include/efi_loader.h | 4
lib/efi_loader/efi_boottime.c | 7 +++
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index ce0f420b5004..5cc3bded03fa 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -318,6 +318,10 @@ efi_status_t efi_create_handle(efi_handle_t *handle);
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);
+/* locate handles */
+efi_status_t efi_locate_handle(enum efi_locate_search_type search_type,
+ const efi_guid_t *protocol, void *search_key,
+ efi_uintn_t *buffer_size, efi_handle_t *buffer);
/* Find a protocol on a handle */
efi_status_t efi_search_protocol(const efi_handle_t handle,
const efi_guid_t *protocol_guid,
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 8a43a5a84091..a3c56bbab552 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1309,10 +1309,9 @@ static int efi_search(enum efi_locate_search_type
search_type,
*
* Return: status code
*/
-static efi_status_t efi_locate_handle(
- enum efi_locate_search_type search_type,
- const efi_guid_t *protocol, void *search_key,
- efi_uintn_t *buffer_size, efi_handle_t *buffer)
+efi_status_t efi_locate_handle(enum efi_locate_search_type search_type,
+ const efi_guid_t *protocol, void *search_key,
+ efi_uintn_t *buffer_size, efi_handle_t *buffer)
{
struct efi_object *efiobj;
efi_uintn_t size = 0;
--
2.19.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/3] efi_loader: add removable device support
Under the current implementation, any removable device which is attached to the platform will not be recognized after any efi-related command, in particular bootefi, is once executed. This patch set resolves this problem by re-scanning and recreating a disk device list for efi operations. # I didn't run selftest "block device" as I don't know how we can # create a test disk image. # Heinrich, can you provide a script? -Takahiro Akashi Changes in v2 (Nov 15, 2018) * efi_init_obj_list() will never return an error once it has succeeded * add "invalid" flag to efi_disk to indicate that a given device is now in stale state * modify block io protocol and file protocol to honor invalid flag * simplify efi simple file system protocol/file procotol by removing details of an u-boot block device * some function were renamed after Heinrich's comment AKASHI Takahiro (3): efi_loader: export efi_locate_handle() function efi_loader: enumerate disk devices every time efi_loader: remove block device details from efi file cmd/bootefi.c | 17 ++- include/efi_loader.h | 14 ++- lib/efi_loader/efi_boottime.c | 7 +- lib/efi_loader/efi_disk.c | 229 +- lib/efi_loader/efi_file.c | 21 ++-- 5 files changed, 266 insertions(+), 22 deletions(-) -- 2.19.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 04/18] arm: MediaTek: add basic support for MT7629 boards
This adds a general board file based on MT7629 SoCs from MediaTek. Apart from the generic parts (cpu) we add some low level init codes and initialize the early clocks. Signed-off-by: Ryder Lee Signed-off-by: Weijie Gao Reviewed-by: Simon Glass --- Changes since v5: None Changes since v4: -Add gd->bd->bi_boot_params for legacy method - ATAGs. --- arch/arm/Kconfig | 16 arch/arm/Makefile | 1 + arch/arm/include/asm/arch-mediatek/misc.h | 17 arch/arm/mach-mediatek/Kconfig| 26 ++ arch/arm/mach-mediatek/Makefile | 6 ++ arch/arm/mach-mediatek/cpu.c | 34 +++ arch/arm/mach-mediatek/init.h | 11 +++ arch/arm/mach-mediatek/mt7629/Makefile| 4 + arch/arm/mach-mediatek/mt7629/init.c | 128 ++ arch/arm/mach-mediatek/mt7629/lowlevel_init.S | 50 ++ arch/arm/mach-mediatek/spl.c | 43 + board/mediatek/mt7629/Kconfig | 17 board/mediatek/mt7629/MAINTAINERS | 7 ++ board/mediatek/mt7629/Makefile| 3 + board/mediatek/mt7629/mt7629_rfb.c| 16 configs/mt7629_rfb_defconfig | 73 +++ include/configs/mt7629.h | 57 17 files changed, 509 insertions(+) create mode 100644 arch/arm/include/asm/arch-mediatek/misc.h create mode 100644 arch/arm/mach-mediatek/Kconfig create mode 100644 arch/arm/mach-mediatek/Makefile create mode 100644 arch/arm/mach-mediatek/cpu.c create mode 100644 arch/arm/mach-mediatek/init.h create mode 100644 arch/arm/mach-mediatek/mt7629/Makefile create mode 100644 arch/arm/mach-mediatek/mt7629/init.c create mode 100644 arch/arm/mach-mediatek/mt7629/lowlevel_init.S create mode 100644 arch/arm/mach-mediatek/spl.c create mode 100644 board/mediatek/mt7629/Kconfig create mode 100644 board/mediatek/mt7629/MAINTAINERS create mode 100644 board/mediatek/mt7629/Makefile create mode 100644 board/mediatek/mt7629/mt7629_rfb.c create mode 100644 configs/mt7629_rfb_defconfig create mode 100644 include/configs/mt7629.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 1f3fa15..96cd41c 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -658,6 +658,20 @@ config ARCH_MESON targeted at media players and tablet computers. We currently support the S905 (GXBaby) 64-bit SoC. +config ARCH_MEDIATEK + bool "MediaTek SoCs" + select BINMAN + select DM + select OF_CONTROL + select SPL_DM if SPL + select SPL_LIBCOMMON_SUPPORT if SPL + select SPL_LIBGENERIC_SUPPORT if SPL + select SPL_OF_CONTROL if SPL + select SUPPORT_SPL + help + Support for the MediaTek SoCs family developed by MediaTek Inc. + Please refer to doc/README.mediatek for more information. + config ARCH_LPC32XX bool "NXP LPC32xx platform" select CPU_ARM926EJS @@ -1442,6 +1456,8 @@ source "arch/arm/mach-rmobile/Kconfig" source "arch/arm/mach-meson/Kconfig" +source "arch/arm/mach-mediatek/Kconfig" + source "arch/arm/mach-qemu/Kconfig" source "arch/arm/mach-rockchip/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 4b6c5e1..c38ef3c 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -62,6 +62,7 @@ machine-$(CONFIG_ARCH_K3) += k3 machine-$(CONFIG_ARCH_KEYSTONE)+= keystone # TODO: rename CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD machine-$(CONFIG_KIRKWOOD) += kirkwood +machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek machine-$(CONFIG_ARCH_MESON) += meson machine-$(CONFIG_ARCH_MVEBU) += mvebu # TODO: rename CONFIG_TEGRA -> CONFIG_ARCH_TEGRA diff --git a/arch/arm/include/asm/arch-mediatek/misc.h b/arch/arm/include/asm/arch-mediatek/misc.h new file mode 100644 index 000..2530e78 --- /dev/null +++ b/arch/arm/include/asm/arch-mediatek/misc.h @@ -0,0 +1,17 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2018 MediaTek Inc. + */ + +#ifndef __MEDIATEK_MISC_H_ +#define __MEDIATEK_MISC_H_ + +#define VER_BASE 0x0800 +#define VER_SIZE 0x10 + +#define APHW_CODE 0x00 +#define APHW_SUBCODE 0x04 +#define APHW_VER 0x08 +#define APSW_VER 0x0c + +#endif /* __MEDIATEK_MISC_H_ */ diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig new file mode 100644 index 000..d2ada97 --- /dev/null +++ b/arch/arm/mach-mediatek/Kconfig @@ -0,0 +1,26 @@ +if ARCH_MEDIATEK + +config SYS_SOC + default "mediatek" + +config SYS_VENDOR + default "mediatek" + +choice + prompt "MediaTek board select" + +config TARGET_MT7629 + bool "MediaTek MT7629 SoC" + select CPU_V7A + select SPL + select ARCH_MISC_INIT + help + The MediaTek MT7629 is
[U-Boot] [PATCH v5 17/18] doc: README.mediatek: Add a simple README for MediaTek
Add a few notes on how to try out the MediaTek support so far. Signed-off-by: Ryder Lee Tested-by: Frank Wunderlich --- Changes since v5: -Fix Whitespace-Error. Changes since v4: -Add instructions on how to prepare SD card and write to SNOR flash. -Fix typo. --- doc/README.mediatek | 221 1 file changed, 221 insertions(+) create mode 100644 doc/README.mediatek diff --git a/doc/README.mediatek b/doc/README.mediatek new file mode 100644 index 000..246579d --- /dev/null +++ b/doc/README.mediatek @@ -0,0 +1,221 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# Copyright (C) 2018 MediaTek Inc. +# Ryder Lee + + +This document describes how to compile the U-Boot and how to change U-Boot +configuration about the MediaTek SoCs. + + +Build Procedure +=== + -Set the cross compiler: + + # export CROSS_COMPILE=/path/to/toolchain/arm-linux-gnueabi- + + -Clean-up old residuals: + + # make mrproper + + -Configure the U-Boot: + + # make + # make + + - For the MT7623n bananapi R2 board use "mt7623n_bpir2_defconfig" + - For the MT7629 reference board use "mt7629_rfb_defconfig" + + +Boot sequence += + -Bootrom -> MTK preloader -> U-Boot + + - MT7623n + + This version of U-Boot doesn't implement SPL. So, MTK preloader binary + is needed to boot up: + + https://github.com/BPI-SINOVOIP/BPI-R2-bsp/tree/master/mt-pack/mtk/bpi-r2/bin + + + -Bootrom -> SPL -> U-Boot + + - MT7629 + + +Configuration update + + To update the U-Boot configuration, please refer to doc/README.kconfig + + +MediaTek image header += +Currently there are two image headers used for MediaTek chips: + + - BootROM image header. This header is used by the first stage bootloader. It records + the desired compatible boot device, integrity information and its load address. + + The on-chip BootROM will firstly verify integrity and compatibility of the bootloader. + + If verification passed, the BootROM will then load the bootloader into on-chip SRAM, + and pass control to it. + + Note that this header is actually a combination of three independent headers: + Device header, BRLYT header and GFH header. + + Used by U-Boot SPL of MT7629 and preloader of MT7623. + + + - MediaTek legacy image header. This header was originally used by the legacy image. It + basically records the load address, image size and image name. + + After all low level initializations passed, the preloader will locate the LK image and + load it into DRAM, and pass control to it. + + Now this header is used by U-Boot of MT7623. + + +To generate these two headers with mkimage: + + # mkimage -T mtk_image -a -n -d + + - mtk_image means using MediaTek's header generation method. + + + - load_addr is the load address of this image. + For first stage bootloader like U-Boot SPL or preloader, it usually points to the + on-chip SRAM. + + For second stage bootloader like U-Boot, it usually points to the DRAM. + + + - option_string contains options to generate the header. + + The option string is using the follow format: + key1=value1;key2=value2;... + + The following key names are valid: + lk: If lk=1, LK image header is used. Otherwise BootROM image header is used. + + lkname: The name of the LK image header. The maximum length is 32. + The default value is "U-Boot". + + media: Desired boot device. The valid values are: + nand : Parallel NAND + snand: Serial NAND + nor : Serial NOR + emmc : eMMC + sdmmc: SD + + nandinfo: Desired NAND device type, a combination of page size, oob size and +optional device capacity. Valid types are: + 2k+64: for Serial NAND, 2KiB page size + 64B oob size + 2k+120 : for Serial NAND, 2KiB page size + 120B oob size + 2k+128 : for Serial NAND, 2KiB page size + 128B oob size + 4k+256 : for Serial NAND, 4KiB page size + 256B oob size + 1g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 1Gbit size + 2g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 2Gbit size + 4g:2k+64 : for Parallel NAND, 2KiB page size + 64B oob size, total 4Gbit size + 2g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 2Gbit size + 4g:2k+128: for Parallel NAND, 2KiB page size + 128B oob size, total 4Gbit size + + +MT7629 partitions on Serial NOR +=== + +
[U-Boot] [PATCH v5 07/18] clk: MediaTek: add clock driver for MT7623 SoC.
This patch adds a driver for MT7623 clock blocks.
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4: None
---
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt7623.c | 870 ++
2 files changed, 871 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt7623.c
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 297f99d..0632dc8 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -3,4 +3,5 @@
obj-$(CONFIG_ARCH_MEDIATEK) += clk-mtk.o
# SoC Drivers
+obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
diff --git a/drivers/clk/mediatek/clk-mt7623.c
b/drivers/clk/mediatek/clk-mt7623.c
new file mode 100644
index 000..c6b09d8
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7623.c
@@ -0,0 +1,870 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT7623 SoC
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+#define MT7623_CLKSQ_STB_CON0 0x18
+#define MT7623_PLL_ISO_CON00x24
+#define MT7623_PLL_FMAX(2000UL * MHZ)
+#define MT7623_CON0_RST_BARBIT(27)
+
+#define MCU_AXI_DIV0x60
+#define AXI_DIV_MSKGENMASK(4, 0)
+#define AXI_DIV_SEL(x) (x)
+
+/* apmixedsys */
+#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg, \
+ _pd_shift, _pcw_reg, _pcw_shift) { \
+ .id = _id, \
+ .reg = _reg,\
+ .pwr_reg = _pwr_reg,\
+ .en_mask = _en_mask,\
+ .rst_bar_mask = MT7623_CON0_RST_BAR,\
+ .fmax = MT7623_PLL_FMAX,\
+ .flags = _flags,\
+ .pcwbits = _pcwbits,\
+ .pd_reg = _pd_reg, \
+ .pd_shift = _pd_shift, \
+ .pcw_reg = _pcw_reg,\
+ .pcw_shift = _pcw_shift,\
+ }
+
+static const struct mtk_pll_data apmixed_plls[] = {
+ PLL(CLK_APMIXED_ARMPLL, 0x200, 0x20c, 0x8001, 0,
+ 21, 0x204, 24, 0x204, 0),
+ PLL(CLK_APMIXED_MAINPLL, 0x210, 0x21c, 0xf001, HAVE_RST_BAR,
+ 21, 0x210, 4, 0x214, 0),
+ PLL(CLK_APMIXED_UNIVPLL, 0x220, 0x22c, 0xf301, HAVE_RST_BAR,
+ 7, 0x220, 4, 0x224, 14),
+ PLL(CLK_APMIXED_MMPLL, 0x230, 0x23c, 0x0001, 0,
+ 21, 0x230, 4, 0x234, 0),
+ PLL(CLK_APMIXED_MSDCPLL, 0x240, 0x24c, 0x0001, 0,
+ 21, 0x240, 4, 0x244, 0),
+ PLL(CLK_APMIXED_TVDPLL, 0x250, 0x25c, 0x0001, 0,
+ 21, 0x250, 4, 0x254, 0),
+ PLL(CLK_APMIXED_AUD1PLL, 0x270, 0x27c, 0x0001, 0,
+ 31, 0x270, 4, 0x274, 0),
+ PLL(CLK_APMIXED_TRGPLL, 0x280, 0x28c, 0x0001, 0,
+ 31, 0x280, 4, 0x284, 0),
+ PLL(CLK_APMIXED_ETHPLL, 0x290, 0x29c, 0x0001, 0,
+ 31, 0x290, 4, 0x294, 0),
+ PLL(CLK_APMIXED_VDECPLL, 0x2a0, 0x2ac, 0x0001, 0,
+ 31, 0x2a0, 4, 0x2a4, 0),
+ PLL(CLK_APMIXED_HADDS2PLL, 0x2b0, 0x2bc, 0x0001, 0,
+ 31, 0x2b0, 4, 0x2b4, 0),
+ PLL(CLK_APMIXED_AUD2PLL, 0x2c0, 0x2cc, 0x0001, 0,
+ 31, 0x2c0, 4, 0x2c4, 0),
+ PLL(CLK_APMIXED_TVD2PLL, 0x2d0, 0x2dc, 0x0001, 0,
+ 21, 0x2d0, 4, 0x2d4, 0),
+};
+
+/* topckgen */
+#define FACTOR0(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
+
+#define FACTOR1(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
+
+#define FACTOR2(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, 0)
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+ FIXED_CLK(CLK_TOP_DPI, CLK_XTAL, 108 * MHZ),
+ FIXED_CLK(CLK_TOP_DMPLL, CLK_XTAL, 400 * MHZ),
+ FIXED_CLK(CLK_TOP_VENCPLL, CLK_XTAL, 295.75 * MHZ),
+ FIXED_CLK(CLK_TOP_HDMI_0_PIX340M, CLK_XTAL, 340 * MHZ),
+ FIXED_CLK(CLK_TOP_HDMI_0_DEEP340M, CLK_XTAL, 340 * MHZ),
+ FIXED_CLK(CLK_TOP_HDMI_0_PLL340M, CLK_XTAL, 340 * MHZ),
+ FIXED_CLK(CLK_TOP_HADDS2_FB, CLK_XTAL, 27 * MHZ),
+ FIXED_CLK(CLK_TOP_WBG_DIG_416M, CLK_XTAL, 416 * MHZ),
+ FIXED_CLK(CLK_TOP_DSI0_LNTC_DSI, CLK_XTAL, 143 * MHZ),
+ FIXED_CLK(CLK_TOP_HDMI_SCL_RX, CLK_XTAL, 27 * MHZ),
+
[U-Boot] [PATCH v5 12/18] power domain: MediaTek: add power domain driver for MT7629 SoC
This adds a power domain driver for the Mediatek SCPSYS unit.
The System Control Processor System (SCPSYS) has several power
management related tasks in the system. The tasks include thermal
measurement, dynamic voltage frequency scaling (DVFS), interrupt
filter and lowlevel sleep control. The System Power Manager (SPM)
inside the SCPSYS is for the MTCMOS power domain control.
For now this driver only adds power domain support.
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4: None
---
drivers/power/domain/Kconfig| 7 +
drivers/power/domain/Makefile | 1 +
drivers/power/domain/mtk-power-domain.c | 326
3 files changed, 334 insertions(+)
create mode 100644 drivers/power/domain/mtk-power-domain.c
diff --git a/drivers/power/domain/Kconfig b/drivers/power/domain/Kconfig
index a08b428..93deaef 100644
--- a/drivers/power/domain/Kconfig
+++ b/drivers/power/domain/Kconfig
@@ -23,6 +23,13 @@ config IMX8_POWER_DOMAIN
Enable support for manipulating NXP i.MX8 on-SoC power domains via
IPC
requests to the SCU.
+config MTK_POWER_DOMAIN
+ bool "Enable the MediaTek power domain driver"
+ depends on POWER_DOMAIN && ARCH_MEDIATEK
+ help
+ Enable support for manipulating MediaTek power domains via MMIO
+ mapped registers.
+
config MESON_GX_VPU_POWER_DOMAIN
bool "Enable Amlogic Meson GX VPU power domain driver"
depends on ARCH_MESON
diff --git a/drivers/power/domain/Makefile b/drivers/power/domain/Makefile
index b08d18f..695aafe 100644
--- a/drivers/power/domain/Makefile
+++ b/drivers/power/domain/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_$(SPL_)POWER_DOMAIN) += power-domain-uclass.o
obj-$(CONFIG_BCM6328_POWER_DOMAIN) += bcm6328-power-domain.o
obj-$(CONFIG_IMX8_POWER_DOMAIN) += imx8-power-domain.o
+obj-$(CONFIG_MTK_POWER_DOMAIN) += mtk-power-domain.o
obj-$(CONFIG_MESON_GX_VPU_POWER_DOMAIN) += meson-gx-pwrc-vpu.o
obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain.o
obj-$(CONFIG_SANDBOX_POWER_DOMAIN) += sandbox-power-domain-test.o
diff --git a/drivers/power/domain/mtk-power-domain.c
b/drivers/power/domain/mtk-power-domain.c
new file mode 100644
index 000..ed4a718
--- /dev/null
+++ b/drivers/power/domain/mtk-power-domain.c
@@ -0,0 +1,326 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define SPM_EN (0xb16 << 16 | 0x1)
+#define SPM_ETHSYS_PWR_CON 0x2e0
+#define SPM_HIF0_PWR_CON 0x2e4
+#define SPM_HIF1_PWR_CON 0x2e8
+#define SPM_PWR_STATUS 0x60c
+#define SPM_PWR_STATUS_2ND 0x610
+
+#define PWR_RST_B_BIT BIT(0)
+#define PWR_ISO_BITBIT(1)
+#define PWR_ON_BIT BIT(2)
+#define PWR_ON_2ND_BIT BIT(3)
+#define PWR_CLK_DIS_BITBIT(4)
+
+#define PWR_STATUS_ETHSYS BIT(24)
+#define PWR_STATUS_HIF0BIT(25)
+#define PWR_STATUS_HIF1BIT(26)
+
+/* Infrasys configuration */
+#define INFRA_TOPDCM_CTRL 0x10
+#define INFRA_TOPAXI_PROT_EN 0x220
+#define INFRA_TOPAXI_PROT_STA1 0x228
+
+#define DCM_TOP_EN BIT(0)
+
+enum scp_domain_type {
+ SCPSYS_MT7629,
+};
+
+struct scp_domain;
+
+struct scp_domain_data {
+ struct scp_domain *scpd;
+ u32 sta_mask;
+ int ctl_offs;
+ u32 sram_pdn_bits;
+ u32 sram_pdn_ack_bits;
+ u32 bus_prot_mask;
+};
+
+struct scp_domain {
+ void __iomem *base;
+ void __iomem *infracfg;
+ enum scp_domain_type type;
+ struct scp_domain_data *data;
+};
+
+static struct scp_domain_data scp_domain_mt7629[] = {
+ [MT7629_POWER_DOMAIN_ETHSYS] = {
+ .sta_mask = PWR_STATUS_ETHSYS,
+ .ctl_offs = SPM_ETHSYS_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .bus_prot_mask = (BIT(3) | BIT(17)),
+ },
+ [MT7629_POWER_DOMAIN_HIF0] = {
+ .sta_mask = PWR_STATUS_HIF0,
+ .ctl_offs = SPM_HIF0_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .bus_prot_mask = GENMASK(25, 24),
+ },
+ [MT7629_POWER_DOMAIN_HIF1] = {
+ .sta_mask = PWR_STATUS_HIF1,
+ .ctl_offs = SPM_HIF1_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ .bus_prot_mask = GENMASK(28, 26),
+ },
+};
+
+/**
+ * This function enables the bus protection bits for disabled power
+ * domains so that the system does not hang when some unit accesses the
+ * bus while in power down.
+ */
+static int mtk_infracfg_set_bus_protection(void __iomem *infracfg,
+
[U-Boot] [PATCH v5 18/18] MAINTAINERS: add an entry for MediaTek
This patch adds an entry for MediaTek. Signed-off-by: Ryder Lee Reviewed-by: Simon Glass --- Changes since v5: None Changes since v4: None --- MAINTAINERS | 20 1 file changed, 20 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index abdb6dc..214629e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -158,6 +158,26 @@ T: git git://git.denx.de/u-boot-pxa.git F: arch/arm/cpu/pxa/ F: arch/arm/include/asm/arch-pxa/ +ARM MEDIATEK +M: Ryder Lee +M: Weijie Gao +S: Maintained +F: arch/arm/mach-mediatek/ +F: arch/arm/include/asm/arch-mediatek/ +F: board/mediatek/ +F: doc/README.mediatek +F: drivers/clk/mediatek/ +F: drivers/mmc/mtk-sd.c +F: drivers/pinctrl/mediatek/ +F: drivers/power/domain/mtk-power-domain.c +F: drivers/ram/mediatek/ +F: drivers/spi/mtk_qspi.c +F: drivers/timer/mtk_timer.c +F: drivers/watchdog/mtk_wdt.c +F: tools/mtk_image.c +F: tools/mtk_image.h +N: mediatek + ARM OWL M: Manivannan Sadhasivam S: Maintained -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 14/18] serial: MediaTek: add high-speed uart driver for MediaTek SoCs
Many SoCs from MediaTek have a high-speed uart. This UART is compatible
with the ns16550 in legacy mode. It has extra registers for high-speed
mode which can reach a maximum baudrate at 921600.
However this UART will no longer be compatible if it's in high-speed mode.
Some BootROM of MediaTek's SoCs will change the UART into high-speed mode
and the U-Boot must use this driver to initialize the UART.
Signed-off-by: Weijie Gao
Tested-by: Ryder Lee
---
Changes since v5: Add a specific driver for MTK UART
Changes since v4: None
---
drivers/serial/Kconfig | 20
drivers/serial/Makefile | 1 +
drivers/serial/serial_mtk.c | 268
3 files changed, 289 insertions(+)
create mode 100644 drivers/serial/serial_mtk.c
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 597db4b..7ab38b7 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -368,6 +368,16 @@ config DEBUG_UART_OMAP
You will need to provide parameters to make this work. The driver
will be available until the real driver model serial is running.
+config DEBUG_UART_MTK
+ bool "MediaTek High-speed UART"
+ depends on MTK_SERIAL
+ help
+ Select this to enable a debug UART using the MediaTek High-speed
+ UART driver.
+ You will need to provide parameters to make this work. The
+ driver will be available until the real driver model serial is
+ running.
+
endchoice
config DEBUG_UART_BASE
@@ -692,6 +702,16 @@ config ZYNQ_SERIAL
This driver supports the Cadence UART. It is found e.g. in Xilinx
Zynq/ZynqMP.
+config MTK_SERIAL
+ bool "MediaTek High-speed UART support"
+ depends on DM_SERIAL
+ help
+ Select this to enable UART support for MediaTek High-speed UART
+ devices. This driver uses driver model and requires a device
+ tree binding to operate.
+ The High-speed UART is compatible with the ns16550a UART and have
+ its own high-speed registers.
+
config MPC8XX_CONS
bool "Console driver for MPC8XX"
depends on MPC8xx
diff --git a/drivers/serial/Makefile b/drivers/serial/Makefile
index 03dc29e..2f8d065 100644
--- a/drivers/serial/Makefile
+++ b/drivers/serial/Makefile
@@ -66,6 +66,7 @@ obj-$(CONFIG_MPC8XX_CONS) += serial_mpc8xx.o
obj-$(CONFIG_NULLDEV_SERIAL) += serial_nulldev.o
obj-$(CONFIG_OWL_SERIAL) += serial_owl.o
obj-$(CONFIG_OMAP_SERIAL) += serial_omap.o
+obj-$(CONFIG_MTK_SERIAL) += serial_mtk.o
ifndef CONFIG_SPL_BUILD
obj-$(CONFIG_USB_TTY) += usbtty.o
diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
new file mode 100644
index 000..bce1be8
--- /dev/null
+++ b/drivers/serial/serial_mtk.c
@@ -0,0 +1,268 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek High-speed UART driver
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Weijie Gao
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct mtk_serial_regs {
+ u32 rbr;
+ u32 ier;
+ u32 fcr;
+ u32 lcr;
+ u32 mcr;
+ u32 lsr;
+ u32 msr;
+ u32 spr;
+ u32 mdr1;
+ u32 highspeed;
+ u32 sample_count;
+ u32 sample_point;
+ u32 fracdiv_l;
+ u32 fracdiv_m;
+ u32 escape_en;
+ u32 guard;
+ u32 rx_sel;
+};
+
+#define thr rbr
+#define iir fcr
+#define dll rbr
+#define dlm ier
+
+#define UART_LCR_WLS_8 0x03/* 8 bit character length */
+#define UART_LCR_DLAB 0x80/* Divisor latch access bit */
+
+#define UART_LSR_DR0x01/* Data ready */
+#define UART_LSR_THRE 0x20/* Xmit holding register empty */
+
+/* the data is correct if the real baud is within 3%. */
+#define BAUD_ALLOW_MAX(baud) ((baud) + (baud) * 3 / 100)
+#define BAUD_ALLOW_MIX(baud) ((baud) - (baud) * 3 / 100)
+
+struct mtk_serial_priv {
+ struct mtk_serial_regs __iomem *regs;
+ u32 clock;
+};
+
+static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud)
+{
+ bool support_clk12m_baud115200;
+ u32 quot, samplecount, realbaud;
+
+ if ((baud <= 115200) && (priv->clock == 1200))
+ support_clk12m_baud115200 = true;
+ else
+ support_clk12m_baud115200 = false;
+
+ if (baud <= 115200) {
+ writel(0, >regs->highspeed);
+ quot = DIV_ROUND_CLOSEST(priv->clock, 16 * baud);
+
+ if (support_clk12m_baud115200) {
+ writel(3, >regs->highspeed);
+ quot = DIV_ROUND_CLOSEST(priv->clock, 256 * baud);
+ if (quot == 0)
+ quot = 1;
+
+ samplecount = DIV_ROUND_CLOSEST(priv->clock,
+ quot * baud);
+ if (samplecount != 0) {
+
[U-Boot] [PATCH v5 00/18] Add U-Boot support for MediaTek SoCs - MT7623n & MT7629
Hello, This is the new round to add U-Boot support for MediaTek SoCs - MT7623n & MT7629, and the most of the drivers are based on mainline Linux, such as clock, timer, mmc, pinctrl, UART, watchdog, power domain and device tree. Ryder Ryder Lee (16): tools: MediaTek: add MTK boot header generation to mkimage arm: dts: MediaTek: add device tree for MT7629 arm: dts: MediaTek: add device tree for MT7623 arm: MediaTek: add basic support for MT7629 boards clk: MediaTek: add clock driver for MT7629 SoC. clk: MediaTek: add clock driver for MT7623 SoC. timer: MediaTek: add timer driver for MediaTek SoCs watchdog: MediaTek: add watchdog driver for MediaTek SoCs pinctrl: MediaTek: add pinctrl driver for MT7629 SoC pinctrl: MediaTek: add pinctrl driver for MT7623 SoC power domain: MediaTek: add power domain driver for MT7629 SoC power domain: MediaTek: add power domain driver for MT7623 SoC serial: MediaTek: add high-speed uart driver for MediaTek SoCs ram: MediaTek: add DDR3 driver for MT7629 SoC doc: README.mediatek: Add a simple README for MediaTek MAINTAINERS: add an entry for MediaTek Weijie Gao (2): arm: MediaTek: add basic support for MT7623 boards mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC MAINTAINERS | 20 + Makefile | 20 + arch/arm/Kconfig | 16 + arch/arm/Makefile |1 + arch/arm/dts/Makefile |4 + arch/arm/dts/mt7623.dtsi | 255 + arch/arm/dts/mt7623n-bananapi-bpi-r2.dts | 207 arch/arm/dts/mt7629-rfb-u-boot.dtsi | 24 + arch/arm/dts/mt7629-rfb.dts | 70 ++ arch/arm/dts/mt7629.dtsi | 244 + arch/arm/include/asm/arch-mediatek/gpio.h |9 + arch/arm/include/asm/arch-mediatek/misc.h | 17 + arch/arm/mach-mediatek/Kconfig| 39 + arch/arm/mach-mediatek/Makefile |7 + arch/arm/mach-mediatek/cpu.c | 34 + arch/arm/mach-mediatek/init.h | 11 + arch/arm/mach-mediatek/mt7623/Makefile|4 + arch/arm/mach-mediatek/mt7623/init.c | 54 + arch/arm/mach-mediatek/mt7623/lowlevel_init.S | 22 + arch/arm/mach-mediatek/mt7623/preloader.h | 99 ++ arch/arm/mach-mediatek/mt7629/Makefile|4 + arch/arm/mach-mediatek/mt7629/init.c | 128 +++ arch/arm/mach-mediatek/mt7629/lowlevel_init.S | 50 + arch/arm/mach-mediatek/spl.c | 43 + board/mediatek/mt7623/Kconfig | 13 + board/mediatek/mt7623/MAINTAINERS |7 + board/mediatek/mt7623/Makefile|3 + board/mediatek/mt7623/mt7623_rfb.c| 16 + board/mediatek/mt7629/Kconfig | 17 + board/mediatek/mt7629/MAINTAINERS |7 + board/mediatek/mt7629/Makefile|3 + board/mediatek/mt7629/mt7629_rfb.c| 16 + common/image.c|1 + configs/mt7623n_bpir2_defconfig | 54 + configs/mt7629_rfb_defconfig | 73 ++ doc/README.mediatek | 221 drivers/clk/Makefile |1 + drivers/clk/mediatek/Makefile |7 + drivers/clk/mediatek/clk-mt7623.c | 870 +++ drivers/clk/mediatek/clk-mt7629.c | 709 + drivers/clk/mediatek/clk-mtk.c| 493 + drivers/clk/mediatek/clk-mtk.h| 194 drivers/mmc/Kconfig | 11 + drivers/mmc/Makefile |1 + drivers/mmc/mtk-sd.c | 1394 + drivers/pinctrl/Kconfig |1 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/mediatek/Kconfig | 15 + drivers/pinctrl/mediatek/Makefile |7 + drivers/pinctrl/mediatek/pinctrl-mt7623.c | 1284 +++ drivers/pinctrl/mediatek/pinctrl-mt7629.c | 409 drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 553 ++ drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 184 drivers/power/domain/Kconfig |7 + drivers/power/domain/Makefile |1 + drivers/power/domain/mtk-power-domain.c | 406 +++ drivers/ram/Makefile |1 + drivers/ram/mediatek/Makefile |7 + drivers/ram/mediatek/ddr3-mt7629.c| 766 ++ drivers/serial/Kconfig| 20 + drivers/serial/Makefile |1 + drivers/serial/serial_mtk.c | 268 + drivers/timer/Kconfig |7 + drivers/timer/Makefile|1 +
[U-Boot] [PATCH v5 16/18] mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC
From: Weijie Gao This patch adds MT7623 host controller driver for accessing SD/MMC. Cc: Jaehoon Chung Signed-off-by: Weijie Gao Signed-off-by: Ryder Lee Tested-by: Matthias Brugger Reviewed-by: Simon Glass --- Changes since v5: None Changes since v4: None --- drivers/mmc/Kconfig | 11 + drivers/mmc/Makefile |1 + drivers/mmc/mtk-sd.c | 1394 ++ 3 files changed, 1406 insertions(+) create mode 100644 drivers/mmc/mtk-sd.c diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index 27246ee..ea60ed5 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -598,6 +598,17 @@ config FTSDC010_SDIO help This can enable ftsdc010 sdio function. +config MMC_MTK + bool "MediaTek SD/MMC Card Interface support" + depends on ARCH_MEDIATEK + depends on BLK && DM_MMC + depends on OF_CONTROL + help + This selects the MediaTek(R) Secure digital and Multimedia card Interface. + If you have a machine with a integrated SD/MMC card reader, say Y or M here. + This is needed if support for any SD/SDIO/MMC devices is required. + If unsure, say N. + endif config TEGRA124_MMC_DISABLE_EXT_LOOPBACK diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 23c5b0d..801a26d 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -65,3 +65,4 @@ obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o +obj-$(CONFIG_MMC_MTK) += mtk-sd.o diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c new file mode 100644 index 000..0741a52 --- /dev/null +++ b/drivers/mmc/mtk-sd.c @@ -0,0 +1,1394 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * MediaTek SD/MMC Card Interface driver + * + * Copyright (C) 2018 MediaTek Inc. + * Author: Weijie Gao + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* MSDC_CFG */ +#define MSDC_CFG_HS400_CK_MODE_EXT BIT(22) +#define MSDC_CFG_CKMOD_EXT_M 0x30 +#define MSDC_CFG_CKMOD_EXT_S 20 +#define MSDC_CFG_CKDIV_EXT_M 0xfff00 +#define MSDC_CFG_CKDIV_EXT_S 8 +#define MSDC_CFG_HS400_CK_MODE BIT(18) +#define MSDC_CFG_CKMOD_M 0x3 +#define MSDC_CFG_CKMOD_S 16 +#define MSDC_CFG_CKDIV_M 0xff00 +#define MSDC_CFG_CKDIV_S 8 +#define MSDC_CFG_CKSTB BIT(7) +#define MSDC_CFG_PIO BIT(3) +#define MSDC_CFG_RST BIT(2) +#define MSDC_CFG_CKPDN BIT(1) +#define MSDC_CFG_MODE BIT(0) + +/* MSDC_IOCON */ +#define MSDC_IOCON_W_DSPL BIT(8) +#define MSDC_IOCON_DSPLBIT(2) +#define MSDC_IOCON_RSPLBIT(1) + +/* MSDC_PS */ +#define MSDC_PS_DAT0 BIT(16) +#define MSDC_PS_CDDBCE_M 0xf000 +#define MSDC_PS_CDDBCE_S 12 +#define MSDC_PS_CDSTS BIT(1) +#define MSDC_PS_CDEN BIT(0) + +/* #define MSDC_INT(EN) */ +#define MSDC_INT_ACMDRDY BIT(3) +#define MSDC_INT_ACMDTMO BIT(4) +#define MSDC_INT_ACMDCRCERRBIT(5) +#define MSDC_INT_CMDRDYBIT(8) +#define MSDC_INT_CMDTMOBIT(9) +#define MSDC_INT_RSPCRCERR BIT(10) +#define MSDC_INT_XFER_COMPLBIT(12) +#define MSDC_INT_DATTMOBIT(14) +#define MSDC_INT_DATCRCERR BIT(15) + +/* MSDC_FIFOCS */ +#define MSDC_FIFOCS_CLRBIT(31) +#define MSDC_FIFOCS_TXCNT_M0xff +#define MSDC_FIFOCS_TXCNT_S16 +#define MSDC_FIFOCS_RXCNT_M0xff +#define MSDC_FIFOCS_RXCNT_S0 + +/* #define SDC_CFG */ +#define SDC_CFG_DTOC_M 0xff00 +#define SDC_CFG_DTOC_S 24 +#define SDC_CFG_SDIOIDEBIT(20) +#define SDC_CFG_SDIO BIT(19) +#define SDC_CFG_BUSWIDTH_M 0x3 +#define SDC_CFG_BUSWIDTH_S 16 + +/* SDC_CMD */ +#define SDC_CMD_BLK_LEN_M 0xfff +#define SDC_CMD_BLK_LEN_S 16 +#define SDC_CMD_STOP BIT(14) +#define SDC_CMD_WR BIT(13) +#define SDC_CMD_DTYPE_M0x1800 +#define SDC_CMD_DTYPE_S11 +#define SDC_CMD_RSPTYP_M 0x380 +#define SDC_CMD_RSPTYP_S 7 +#define SDC_CMD_CMD_M 0x3f +#define SDC_CMD_CMD_S 0 + +/* SDC_STS */ +#define SDC_STS_CMDBUSYBIT(1) +#define SDC_STS_SDCBUSYBIT(0) + +/* SDC_ADV_CFG0 */
[U-Boot] [PATCH v5 15/18] ram: MediaTek: add DDR3 driver for MT7629 SoC
This patch adds a DDR3 driver for MT7629 SoC. Signed-off-by: Wu Zou Signed-off-by: Ryder Lee Reviewed-by: Simon Glass --- Changes since v5: None Changes since v4: None --- drivers/ram/Makefile | 1 + drivers/ram/mediatek/Makefile | 7 + drivers/ram/mediatek/ddr3-mt7629.c | 766 + 3 files changed, 774 insertions(+) create mode 100644 drivers/ram/mediatek/Makefile create mode 100644 drivers/ram/mediatek/ddr3-mt7629.c diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile index cfba57f..92ea715 100644 --- a/drivers/ram/Makefile +++ b/drivers/ram/Makefile @@ -11,3 +11,4 @@ obj-$(CONFIG_STM32_SDRAM) += stm32_sdram.o obj-$(CONFIG_ARCH_BMIPS) += bmips_ram.o obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/ +obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/ diff --git a/drivers/ram/mediatek/Makefile b/drivers/ram/mediatek/Makefile new file mode 100644 index 000..95507b5 --- /dev/null +++ b/drivers/ram/mediatek/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (c) 2018 MediaTek Inc. +# +# SPDX-License-Identifier: GPL-2.0 +# + +obj-$(CONFIG_TARGET_MT7629) = ddr3-mt7629.o diff --git a/drivers/ram/mediatek/ddr3-mt7629.c b/drivers/ram/mediatek/ddr3-mt7629.c new file mode 100644 index 000..b413f49 --- /dev/null +++ b/drivers/ram/mediatek/ddr3-mt7629.c @@ -0,0 +1,766 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * MediaTek DDR3 driver for MT7629 SoC + * + * Copyright (C) 2018 MediaTek Inc. + * Author: Wu Zou + *Ryder Lee + */ + +#include +#include +#include +#include +#include + +/* EMI */ +#define EMI_CONA 0x000 +#define EMI_CONF 0x028 +#define EMI_CONM 0x060 + +/* DDR PHY */ +#define DDRPHY_PLL10x +#define DDRPHY_PLL20x0004 +#define DDRPHY_PLL30x0008 +#define DDRPHY_PLL40x000c +#define DDRPHY_PLL50x0010 +#define DDRPHY_PLL70x0018 +#define DDRPHY_B0_DLL_ARPI00x0080 +#define DDRPHY_B0_DLL_ARPI10x0084 +#define DDRPHY_B0_DLL_ARPI20x0088 +#define DDRPHY_B0_DLL_ARPI30x008c +#define DDRPHY_B0_DLL_ARPI40x0090 +#define DDRPHY_B0_DLL_ARPI50x0094 +#define DDRPHY_B0_DQ2 0x00a0 +#define DDRPHY_B0_DQ3 0x00a4 +#define DDRPHY_B0_DQ4 0x00a8 +#define DDRPHY_B0_DQ5 0x00ac +#define DDRPHY_B0_DQ6 0x00b0 +#define DDRPHY_B0_DQ7 0x00b4 +#define DDRPHY_B0_DQ8 0x00b8 +#define DDRPHY_B1_DLL_ARPI00x0100 +#define DDRPHY_B1_DLL_ARPI10x0104 +#define DDRPHY_B1_DLL_ARPI20x0108 +#define DDRPHY_B1_DLL_ARPI30x010c +#define DDRPHY_B1_DLL_ARPI40x0110 +#define DDRPHY_B1_DLL_ARPI50x0114 +#define DDRPHY_B1_DQ2 0x0120 +#define DDRPHY_B1_DQ3 0x0124 +#define DDRPHY_B1_DQ4 0x0128 +#define DDRPHY_B1_DQ5 0x012c +#define DDRPHY_B1_DQ6 0x0130 +#define DDRPHY_B1_DQ7 0x0134 +#define DDRPHY_B1_DQ8 0x0138 +#define DDRPHY_CA_DLL_ARPI00x0180 +#define DDRPHY_CA_DLL_ARPI10x0184 +#define DDRPHY_CA_DLL_ARPI20x0188 +#define DDRPHY_CA_DLL_ARPI30x018c +#define DDRPHY_CA_DLL_ARPI40x0190 +#define DDRPHY_CA_DLL_ARPI50x0194 +#define DDRPHY_CA_CMD2 0x01a0 +#define DDRPHY_CA_CMD3 0x01a4 +#define DDRPHY_CA_CMD5 0x01ac +#define DDRPHY_CA_CMD6 0x01b0 +#define DDRPHY_CA_CMD7 0x01b4 +#define DDRPHY_CA_CMD8 0x01b8 +#define DDRPHY_MISC_VREF_CTRL 0x0264 +#define DDRPHY_MISC_IMP_CTRL0 0x0268 +#define DDRPHY_MISC_IMP_CTRL1 0x026c +#define DDRPHY_MISC_SHU_OPT0x0270 +#define DDRPHY_MISC_SPM_CTRL0 0x0274 +#define DDRPHY_MISC_SPM_CTRL1 0x0278 +#define DDRPHY_MISC_SPM_CTRL2 0x027c +#define DDRPHY_MISC_CG_CTRL0 0x0284 +#define DDRPHY_MISC_CG_CTRL1 0x0288 +#define DDRPHY_MISC_CG_CTRL2 0x028c +#define DDRPHY_MISC_CG_CTRL4 0x0294 +#define DDRPHY_MISC_CTRL0 0x029c +#define DDRPHY_MISC_CTRL1 0x02a0 +#define DDRPHY_MISC_CTRL3 0x02a8 +#define DDRPHY_MISC_RXDVS1 0x05e4 +#define DDRPHY_SHU1_B0_DQ4 0x0c10 +#define DDRPHY_SHU1_B0_DQ5 0x0c14 +#define DDRPHY_SHU1_B0_DQ6 0x0c18 +#define DDRPHY_SHU1_B0_DQ7 0x0c1c +#define DDRPHY_SHU1_B1_DQ4 0x0c90 +#define DDRPHY_SHU1_B1_DQ5 0x0c94 +#define DDRPHY_SHU1_B1_DQ6 0x0c98 +#define DDRPHY_SHU1_B1_DQ7 0x0c9c +#define DDRPHY_SHU1_CA_CMD20x0d08 +#define DDRPHY_SHU1_CA_CMD40x0d10 +#define
[U-Boot] [PATCH v5 11/18] pinctrl: MediaTek: add pinctrl driver for MT7623 SoC
This patch adds pinctrl support for MT7623 SoC. And most of the
structures are used to hold the hardware configuration for each
pin.
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4:
-Add a comment to the exported function - mtk_rmw()
---
drivers/pinctrl/mediatek/Kconfig |4 +
drivers/pinctrl/mediatek/Makefile |1 +
drivers/pinctrl/mediatek/pinctrl-mt7623.c | 1284 +
drivers/pinctrl/mediatek/pinctrl-mtk-common.h |2 +
4 files changed, 1291 insertions(+)
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index e0145b1..1bd9a92 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -4,6 +4,10 @@ config PINCTRL_MTK
depends on PINCTRL_GENERIC
bool
+config PINCTRL_MT7623
+ bool "MT7623 SoC pinctrl driver"
+ select PINCTRL_MTK
+
config PINCTRL_MT7629
bool "MT7629 SoC pinctrl driver"
select PINCTRL_MTK
diff --git a/drivers/pinctrl/mediatek/Makefile
b/drivers/pinctrl/mediatek/Makefile
index cbf0765..f6ef362 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -3,4 +3,5 @@
obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
# SoC Drivers
+obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7623.c
b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
new file mode 100644
index 000..fd37dfa
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7623.c
@@ -0,0 +1,1284 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+
+#include "pinctrl-mtk-common.h"
+
+#define PIN_BOND_REG0 0xb10
+#define PIN_BOND_REG1 0xf20
+#define PIN_BOND_REG2 0xef0
+#define BOND_PCIE_CLR (0x77 << 3)
+#define BOND_I2S_CLR 0x3
+#define BOND_MSDC0E_CLR0x1
+
+#define PIN_FIELD15(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)
\
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 15, false)
+
+#define PIN_FIELD16(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)
\
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 16, false)
+
+#define PINS_FIELD16(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)\
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 16, true)
+
+static const struct mtk_pin_field_calc mt7623_pin_mode_range[] = {
+ PIN_FIELD15(0, 278, 0x760, 0x10, 0, 3),
+};
+
+static const struct mtk_pin_field_calc mt7623_pin_dir_range[] = {
+ PIN_FIELD16(0, 175, 0x0, 0x10, 0, 1),
+ PIN_FIELD16(176, 278, 0xc0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7623_pin_di_range[] = {
+ PIN_FIELD16(0, 278, 0x630, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7623_pin_do_range[] = {
+ PIN_FIELD16(0, 278, 0x500, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7623_pin_ies_range[] = {
+ PINS_FIELD16(0, 6, 0xb20, 0x10, 0, 1),
+ PINS_FIELD16(7, 9, 0xb20, 0x10, 1, 1),
+ PINS_FIELD16(10, 13, 0xb30, 0x10, 3, 1),
+ PINS_FIELD16(14, 15, 0xb30, 0x10, 13, 1),
+ PINS_FIELD16(16, 17, 0xb40, 0x10, 7, 1),
+ PINS_FIELD16(18, 29, 0xb40, 0x10, 13, 1),
+ PINS_FIELD16(30, 32, 0xb40, 0x10, 7, 1),
+ PINS_FIELD16(33, 37, 0xb40, 0x10, 13, 1),
+ PIN_FIELD16(38, 38, 0xb20, 0x10, 13, 1),
+ PINS_FIELD16(39, 42, 0xb40, 0x10, 13, 1),
+ PINS_FIELD16(43, 45, 0xb20, 0x10, 10, 1),
+ PINS_FIELD16(47, 48, 0xb20, 0x10, 11, 1),
+ PIN_FIELD16(49, 49, 0xb20, 0x10, 12, 1),
+ PINS_FIELD16(50, 52, 0xb20, 0x10, 13, 1),
+ PINS_FIELD16(53, 56, 0xb20, 0x10, 14, 1),
+ PINS_FIELD16(57, 58, 0xb20, 0x10, 15, 1),
+ PIN_FIELD16(59, 59, 0xb30, 0x10, 10, 1),
+ PINS_FIELD16(60, 62, 0xb30, 0x10, 0, 1),
+ PINS_FIELD16(63, 65, 0xb30, 0x10, 1, 1),
+ PINS_FIELD16(66, 71, 0xb30, 0x10, 2, 1),
+ PINS_FIELD16(72, 74, 0xb20, 0x10, 12, 1),
+ PINS_FIELD16(75, 76, 0xb30, 0x10, 3, 1),
+ PINS_FIELD16(77, 78, 0xb30, 0x10, 4, 1),
+ PINS_FIELD16(79, 82, 0xb30, 0x10, 5, 1),
+ PINS_FIELD16(83, 84, 0xb30, 0x10, 2, 1),
+ PIN_FIELD16(85, 85, 0xda0, 0x10, 4, 1),
+ PIN_FIELD16(86, 86, 0xd90, 0x10, 4, 1),
+ PINS_FIELD16(87, 90, 0xdb0, 0x10, 4, 1),
+ PINS_FIELD16(101, 104, 0xb30, 0x10, 6, 1),
+ PIN_FIELD16(105, 105, 0xd40, 0x10, 4, 1),
+ PIN_FIELD16(106, 106, 0xd30, 0x10, 4, 1),
+ PINS_FIELD16(107, 110, 0xd50, 0x10, 4, 1),
+ PINS_FIELD16(111, 115, 0xce0, 0x10, 4, 1),
+ PIN_FIELD16(116, 116, 0xcd0, 0x10, 4, 1),
+
[U-Boot] [PATCH v5 08/18] timer: MediaTek: add timer driver for MediaTek SoCs
This patch adds clock source and clock event for the timer found
on the Mediatek SoCs.
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4: None
---
drivers/timer/Kconfig | 7
drivers/timer/Makefile| 1 +
drivers/timer/mtk_timer.c | 85 +++
3 files changed, 93 insertions(+)
create mode 100644 drivers/timer/mtk_timer.c
diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
index d012cf7..229c3a2 100644
--- a/drivers/timer/Kconfig
+++ b/drivers/timer/Kconfig
@@ -160,4 +160,11 @@ config MPC83XX_TIMER
Select this to enable support for the timer found on
devices based on the MPC83xx family of SoCs.
+config MTK_TIMER
+ bool "MediaTek timer support"
+ depends on TIMER
+ help
+ Select this to enable support for the timer found on
+ MediaTek devices.
+
endmenu
diff --git a/drivers/timer/Makefile b/drivers/timer/Makefile
index 7f19c49..c4fbab2 100644
--- a/drivers/timer/Makefile
+++ b/drivers/timer/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_SANDBOX_TIMER) += sandbox_timer.o
obj-$(CONFIG_STI_TIMER)+= sti-timer.o
obj-$(CONFIG_STM32_TIMER) += stm32_timer.o
obj-$(CONFIG_X86_TSC_TIMER)+= tsc_timer.o
+obj-$(CONFIG_MTK_TIMER)+= mtk_timer.o
diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c
new file mode 100644
index 000..b5e76bd
--- /dev/null
+++ b/drivers/timer/mtk_timer.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek timer driver
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#define MTK_GPT4_CTRL 0x40
+#define MTK_GPT4_CLK 0x44
+#define MTK_GPT4_CNT 0x48
+
+#define GPT4_ENABLEBIT(0)
+#define GPT4_CLEAR BIT(1)
+#define GPT4_FREERUN GENMASK(5, 4)
+#define GPT4_CLK_SYS 0x0
+#define GPT4_CLK_DIV1 0x0
+
+struct mtk_timer_priv {
+ void __iomem *base;
+};
+
+static int mtk_timer_get_count(struct udevice *dev, u64 *count)
+{
+ struct mtk_timer_priv *priv = dev_get_priv(dev);
+ u32 val = readl(priv->base + MTK_GPT4_CNT);
+
+ *count = timer_conv_64(val);
+
+ return 0;
+}
+
+static int mtk_timer_probe(struct udevice *dev)
+{
+ struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+ struct mtk_timer_priv *priv = dev_get_priv(dev);
+ struct clk clk, parent;
+ int ret;
+
+ priv->base = dev_read_addr_ptr(dev);
+ if (!priv->base)
+ return -ENOENT;
+
+ ret = clk_get_by_index(dev, 0, );
+ if (ret)
+ return ret;
+
+ ret = clk_get_by_index(dev, 1, );
+ if (!ret) {
+ ret = clk_set_parent(, );
+ if (ret)
+ return ret;
+ }
+
+ uc_priv->clock_rate = clk_get_rate();
+ if (!uc_priv->clock_rate)
+ return -EINVAL;
+
+ return 0;
+}
+
+static const struct timer_ops mtk_timer_ops = {
+ .get_count = mtk_timer_get_count,
+};
+
+static const struct udevice_id mtk_timer_ids[] = {
+ { .compatible = "mediatek,timer" },
+ { }
+};
+
+U_BOOT_DRIVER(mtk_timer) = {
+ .name = "mtk_timer",
+ .id = UCLASS_TIMER,
+ .of_match = mtk_timer_ids,
+ .priv_auto_alloc_size = sizeof(struct mtk_timer_priv),
+ .probe = mtk_timer_probe,
+ .ops = _timer_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5 13/18] power domain: MediaTek: add power domain driver for MT7623 SoC
This adds power domain (scpsys) support for MT7623 SoC.
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4: None
---
drivers/power/domain/mtk-power-domain.c | 80 +
1 file changed, 80 insertions(+)
diff --git a/drivers/power/domain/mtk-power-domain.c
b/drivers/power/domain/mtk-power-domain.c
index ed4a718..c67e880 100644
--- a/drivers/power/domain/mtk-power-domain.c
+++ b/drivers/power/domain/mtk-power-domain.c
@@ -14,9 +14,19 @@
#include
#include
+#include
#include
#define SPM_EN (0xb16 << 16 | 0x1)
+#define SPM_VDE_PWR_CON0x0210
+#define SPM_MFG_PWR_CON0x0214
+#define SPM_ISP_PWR_CON0x0238
+#define SPM_DIS_PWR_CON0x023c
+#define SPM_CONN_PWR_CON 0x0280
+#define SPM_BDP_PWR_CON0x029c
+#define SPM_ETH_PWR_CON0x02a0
+#define SPM_HIF_PWR_CON0x02a4
+#define SPM_IFR_MSC_PWR_CON0x02a8
#define SPM_ETHSYS_PWR_CON 0x2e0
#define SPM_HIF0_PWR_CON 0x2e4
#define SPM_HIF1_PWR_CON 0x2e8
@@ -29,6 +39,15 @@
#define PWR_ON_2ND_BIT BIT(3)
#define PWR_CLK_DIS_BITBIT(4)
+#define PWR_STATUS_CONNBIT(1)
+#define PWR_STATUS_DISPBIT(3)
+#define PWR_STATUS_MFG BIT(4)
+#define PWR_STATUS_ISP BIT(5)
+#define PWR_STATUS_VDECBIT(7)
+#define PWR_STATUS_BDP BIT(14)
+#define PWR_STATUS_ETH BIT(15)
+#define PWR_STATUS_HIF BIT(16)
+#define PWR_STATUS_IFR_MSC BIT(17)
#define PWR_STATUS_ETHSYS BIT(24)
#define PWR_STATUS_HIF0BIT(25)
#define PWR_STATUS_HIF1BIT(26)
@@ -41,6 +60,7 @@
#define DCM_TOP_EN BIT(0)
enum scp_domain_type {
+ SCPSYS_MT7623,
SCPSYS_MT7629,
};
@@ -62,6 +82,59 @@ struct scp_domain {
struct scp_domain_data *data;
};
+static struct scp_domain_data scp_domain_mt7623[] = {
+ [MT7623_POWER_DOMAIN_CONN] = {
+ .sta_mask = PWR_STATUS_CONN,
+ .ctl_offs = SPM_CONN_PWR_CON,
+ .bus_prot_mask = BIT(8) | BIT(2),
+ },
+ [MT7623_POWER_DOMAIN_DISP] = {
+ .sta_mask = PWR_STATUS_DISP,
+ .ctl_offs = SPM_DIS_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .bus_prot_mask = BIT(2),
+ },
+ [MT7623_POWER_DOMAIN_MFG] = {
+ .sta_mask = PWR_STATUS_MFG,
+ .ctl_offs = SPM_MFG_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT7623_POWER_DOMAIN_VDEC] = {
+ .sta_mask = PWR_STATUS_VDEC,
+ .ctl_offs = SPM_VDE_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(12, 12),
+ },
+ [MT7623_POWER_DOMAIN_ISP] = {
+ .sta_mask = PWR_STATUS_ISP,
+ .ctl_offs = SPM_ISP_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(13, 12),
+ },
+ [MT7623_POWER_DOMAIN_BDP] = {
+ .sta_mask = PWR_STATUS_BDP,
+ .ctl_offs = SPM_BDP_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ },
+ [MT7623_POWER_DOMAIN_ETH] = {
+ .sta_mask = PWR_STATUS_ETH,
+ .ctl_offs = SPM_ETH_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ },
+ [MT7623_POWER_DOMAIN_HIF] = {
+ .sta_mask = PWR_STATUS_HIF,
+ .ctl_offs = SPM_HIF_PWR_CON,
+ .sram_pdn_bits = GENMASK(11, 8),
+ .sram_pdn_ack_bits = GENMASK(15, 12),
+ },
+ [MT7623_POWER_DOMAIN_IFR_MSC] = {
+ .sta_mask = PWR_STATUS_IFR_MSC,
+ .ctl_offs = SPM_IFR_MSC_PWR_CON,
+ },
+};
+
static struct scp_domain_data scp_domain_mt7629[] = {
[MT7629_POWER_DOMAIN_ETHSYS] = {
.sta_mask = PWR_STATUS_ETHSYS,
@@ -252,6 +325,9 @@ static int mtk_power_domain_hook(struct udevice *dev)
scpd->type = (enum scp_domain_type)dev_get_driver_data(dev);
switch (scpd->type) {
+ case SCPSYS_MT7623:
+ scpd->data = scp_domain_mt7623;
+ break;
case SCPSYS_MT7629:
scpd->data = scp_domain_mt7629;
break;
@@ -303,6 +379,10 @@ static int mtk_power_domain_probe(struct udevice *dev)
static const struct udevice_id mtk_power_domain_ids[] = {
{
+ .compatible = "mediatek,mt7623-scpsys",
+ .data = SCPSYS_MT7623,
+ },
+ {
.compatible = "mediatek,mt7629-scpsys",
.data = SCPSYS_MT7629,
},
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH v5 10/18] pinctrl: MediaTek: add pinctrl driver for MT7629 SoC
This patch adds pinctrl support for MT7629 SoC. The IO core found on
the SoC has the registers for pinctrl, pinconf and gpio mixed up in
the same register range. Hence the driver also implements the gpio
functionality through UCLASS_GPIO.
This also creates a common file as there might be other chips that use
the same binding and driver, then being a little more abstract could
help in the long run.
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5:
- remove unused pin macros
Changes since v4:
-mtk_pinctrl_probe() is a common function called by all probe functions,
so rename it to mtk_pinctrl_common_probe().
---
arch/arm/include/asm/arch-mediatek/gpio.h | 9 +
drivers/pinctrl/Kconfig | 1 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/mediatek/Kconfig | 11 +
drivers/pinctrl/mediatek/Makefile | 6 +
drivers/pinctrl/mediatek/pinctrl-mt7629.c | 409 +++
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 553 ++
drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 182 +
8 files changed, 1172 insertions(+)
create mode 100644 arch/arm/include/asm/arch-mediatek/gpio.h
create mode 100644 drivers/pinctrl/mediatek/Kconfig
create mode 100644 drivers/pinctrl/mediatek/Makefile
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7629.c
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-common.c
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-common.h
diff --git a/arch/arm/include/asm/arch-mediatek/gpio.h
b/arch/arm/include/asm/arch-mediatek/gpio.h
new file mode 100644
index 000..4ea1020
--- /dev/null
+++ b/arch/arm/include/asm/arch-mediatek/gpio.h
@@ -0,0 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ */
+
+#ifndef __MEDIATEK_GPIO_H
+#define __MEDIATEK_GPIO_H
+
+#endif /* __MEDIATEK_GPIO_H */
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ad0b8da..7e6fad3 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -301,6 +301,7 @@ config ASPEED_AST2500_PINCTRL
endif
source "drivers/pinctrl/meson/Kconfig"
+source "drivers/pinctrl/mediatek/Kconfig"
source "drivers/pinctrl/nxp/Kconfig"
source "drivers/pinctrl/renesas/Kconfig"
source "drivers/pinctrl/uniphier/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index a3a6c6d..293bad3 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-$(CONFIG_PINCTRL_MTK) += mediatek/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_STI) += pinctrl-sti.o
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
new file mode 100644
index 000..e0145b1
--- /dev/null
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -0,0 +1,11 @@
+if ARCH_MEDIATEK
+
+config PINCTRL_MTK
+ depends on PINCTRL_GENERIC
+ bool
+
+config PINCTRL_MT7629
+ bool "MT7629 SoC pinctrl driver"
+ select PINCTRL_MTK
+
+endif
diff --git a/drivers/pinctrl/mediatek/Makefile
b/drivers/pinctrl/mediatek/Makefile
new file mode 100644
index 000..cbf0765
--- /dev/null
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+# Core
+obj-$(CONFIG_PINCTRL_MTK) += pinctrl-mtk-common.o
+
+# SoC Drivers
+obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7629.c
b/drivers/pinctrl/mediatek/pinctrl-mt7629.c
new file mode 100644
index 000..aa6d1c2
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt7629.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+
+#include "pinctrl-mtk-common.h"
+
+#define PIN_FIELD(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits) \
+ PIN_FIELD_CALC(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, \
+ _x_bits, 32, false)
+
+#define MT7629_PIN(_number, _name) MTK_PIN(_number, _name, DRV_GRP1)
+
+static const struct mtk_pin_field_calc mt7629_pin_mode_range[] = {
+ PIN_FIELD(0, 78, 0x300, 0x10, 0, 4),
+};
+
+static const struct mtk_pin_field_calc mt7629_pin_dir_range[] = {
+ PIN_FIELD(0, 78, 0x0, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7629_pin_di_range[] = {
+ PIN_FIELD(0, 78, 0x200, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7629_pin_do_range[] = {
+ PIN_FIELD(0, 78, 0x100, 0x10, 0, 1),
+};
+
+static const struct mtk_pin_field_calc mt7629_pin_ies_range[] = {
+ PIN_FIELD(0, 10, 0x1000, 0x10, 0, 1),
+ PIN_FIELD(11, 18, 0x2000, 0x10, 0, 1),
+ PIN_FIELD(19, 32, 0x3000, 0x10, 0, 1),
+ PIN_FIELD(33, 48,
[U-Boot] [PATCH v5 09/18] watchdog: MediaTek: add watchdog driver for MediaTek SoCs
This patch adds a common driver for the Mediatek SoC integrated
watchdog.
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4: None
---
drivers/watchdog/Kconfig | 8 +++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/mtk_wdt.c | 135 +
3 files changed, 144 insertions(+)
create mode 100644 drivers/watchdog/mtk_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 02f4e1e..b919ef6 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -103,6 +103,14 @@ config WDT_CDNS
Select this to enable Cadence watchdog timer, which can be found on
some
Xilinx Microzed Platform.
+config WDT_MTK
+ bool "MediaTek watchdog timer support"
+ depends on WDT && ARCH_MEDIATEK
+ help
+ Select this to enable watchdog timer for MediaTek SoCs.
+ The watchdog timer is stopped when initialized.
+ It performs full SoC reset.
+
config XILINX_TB_WATCHDOG
bool "Xilinx Axi watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 08406ca..04fa4a6 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -23,3 +23,4 @@ obj-$(CONFIG_BCM2835_WDT) += bcm2835_wdt.o
obj-$(CONFIG_WDT_ORION) += orion_wdt.o
obj-$(CONFIG_WDT_CDNS) += cdns_wdt.o
obj-$(CONFIG_MPC8xx_WATCHDOG) += mpc8xx_wdt.o
+obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
new file mode 100644
index 000..0b50173
--- /dev/null
+++ b/drivers/watchdog/mtk_wdt.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Watchdog driver for MediaTek SoCs
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+
+#define MTK_WDT_MODE 0x00
+#define MTK_WDT_LENGTH 0x04
+#define MTK_WDT_RESTART0x08
+#define MTK_WDT_STATUS 0x0c
+#define MTK_WDT_INTERVAL 0x10
+#define MTK_WDT_SWRST 0x14
+#define MTK_WDT_REQ_MODE 0x30
+#define MTK_WDT_DEBUG_CTL 0x40
+
+#define WDT_MODE_KEY (0x22 << 24)
+#define WDT_MODE_ENBIT(0)
+#define WDT_MODE_EXTPOLBIT(1)
+#define WDT_MODE_EXTEN BIT(2)
+#define WDT_MODE_IRQ_ENBIT(3)
+#define WDT_MODE_DUAL_EN BIT(6)
+
+#define WDT_LENGTH_KEY 0x8
+#define WDT_LENGTH_TIMEOUT(n) ((n) << 5)
+
+#define WDT_RESTART_KEY0x1971
+#define WDT_SWRST_KEY 0x1209
+
+struct mtk_wdt_priv {
+ void __iomem *base;
+};
+
+static int mtk_wdt_reset(struct udevice *dev)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ /* Reload watchdog duration */
+ writel(WDT_RESTART_KEY, priv->base + MTK_WDT_RESTART);
+
+ return 0;
+}
+
+static int mtk_wdt_stop(struct udevice *dev)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ clrsetbits_le32(priv->base + MTK_WDT_MODE, WDT_MODE_EN, WDT_MODE_KEY);
+
+ return 0;
+}
+
+static int mtk_wdt_expire_now(struct udevice *dev, ulong flags)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ /* Kick watchdog to prevent counter == 0 */
+ writel(WDT_RESTART_KEY, priv->base + MTK_WDT_RESTART);
+
+ /* Reset */
+ writel(WDT_SWRST_KEY, priv->base + MTK_WDT_SWRST);
+ hang();
+
+ return 0;
+}
+
+static void mtk_wdt_set_timeout(struct udevice *dev, unsigned int timeout)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ /*
+* One bit is the value of 512 ticks
+* The clock has 32 KHz
+*/
+ timeout = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+ writel(timeout, priv->base + MTK_WDT_LENGTH);
+
+ mtk_wdt_reset(dev);
+}
+
+static int mtk_wdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ mtk_wdt_set_timeout(dev, timeout);
+
+ /* Enable watchdog reset signal */
+ setbits_le32(priv->base + MTK_WDT_MODE,
+WDT_MODE_EN | WDT_MODE_KEY | WDT_MODE_EXTEN);
+
+ return 0;
+}
+
+static int mtk_wdt_probe(struct udevice *dev)
+{
+ struct mtk_wdt_priv *priv = dev_get_priv(dev);
+
+ priv->base = dev_read_addr_ptr(dev);
+ if (!priv->base)
+ return -ENOENT;
+
+ /* Clear status */
+ clrsetbits_le32(priv->base + MTK_WDT_MODE,
+ WDT_MODE_IRQ_EN | WDT_MODE_EXTPOL, WDT_MODE_KEY);
+
+ return mtk_wdt_stop(dev);
+}
+
+static const struct wdt_ops mtk_wdt_ops = {
+ .start = mtk_wdt_start,
+ .reset = mtk_wdt_reset,
+ .stop = mtk_wdt_stop,
+ .expire_now = mtk_wdt_expire_now,
+};
+
[U-Boot] [PATCH v5 01/18] tools: MediaTek: add MTK boot header generation to mkimage
This patch adds support for MTK boot image generation.
Signed-off-by: Weijie Gao
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5: Fix typo
Changes since v4: None
---
Makefile | 20 ++
common/image.c | 1 +
include/image.h | 1 +
scripts/Makefile.spl | 11 +
tools/Makefile | 1 +
tools/mtk_image.c| 749 +++
tools/mtk_image.h| 199 ++
7 files changed, 982 insertions(+)
create mode 100644 tools/mtk_image.c
create mode 100644 tools/mtk_image.h
diff --git a/Makefile b/Makefile
index 552687d..a5d0c1b 100644
--- a/Makefile
+++ b/Makefile
@@ -852,6 +852,8 @@ ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
endif
+ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
+
# Add optional build target if defined in board/cpu/soc headers
ifneq ($(CONFIG_BUILD_TARGET),)
ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
@@ -1359,6 +1361,24 @@ u-boot.elf: u-boot.bin
$(Q)$(OBJCOPY) -I binary $(PLATFORM_ELFFLAGS) $< u-boot-elf.o
$(call if_changed,u-boot-elf)
+# MediaTek's ARM-based u-boot needs a header to contains its load address
+# which is parsed by the BootROM.
+# If the SPL build is enabled, the header will be added to the spl binary,
+# and the spl binary and the u-boot.img will be combined into one file.
+# Otherwise the header will be added to the u-boot.bin directly.
+
+ifeq ($(CONFIG_SPL),y)
+u-boot-mtk.bin: u-boot.dtb u-boot.img spl/u-boot-spl-mtk.bin FORCE
+ $(call if_changed,binman)
+else
+MKIMAGEFLAGS_u-boot-mtk.bin = -T mtk_image \
+ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
+ -n "$(patsubst "%",%,$(CONFIG_MTK_BROM_HEADER_INFO))"
+
+u-boot-mtk.bin: u-boot.bin FORCE
+ $(call if_changed,mkimage)
+endif
+
ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
# Rule to link u-boot
diff --git a/common/image.c b/common/image.c
index 1c3a772..0659133 100644
--- a/common/image.c
+++ b/common/image.c
@@ -166,6 +166,7 @@ static const table_entry_t uimage_type[] = {
{ IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4 IVT"
},
{ IH_TYPE_PMMC,"pmmc","TI Power Management
Micro-Controller Firmware",},
{ IH_TYPE_STM32IMAGE, "stm32image", "STMicroelectronics STM32
Image" },
+ { IH_TYPE_MTKIMAGE, "mtk_image", "MediaTek BootROM loadable
Image" },
{ -1, "", "", },
};
diff --git a/include/image.h b/include/image.h
index 031c355..f67502e 100644
--- a/include/image.h
+++ b/include/image.h
@@ -278,6 +278,7 @@ enum {
IH_TYPE_PMMC,/* TI Power Management Micro-Controller
Firmware */
IH_TYPE_STM32IMAGE, /* STMicroelectronics STM32 Image */
IH_TYPE_SOCFPGAIMAGE_V1,/* Altera SOCFPGA A10 Preloader */
+ IH_TYPE_MTKIMAGE, /* MediaTek BootROM loadable Image */
IH_TYPE_COUNT, /* Number of image types */
};
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 7416abe..22bd8f7 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -219,6 +219,8 @@ ALL-$(CONFIG_SPL_X86_16BIT_INIT) +=
$(obj)/u-boot-x86-16bit-spl.bin
ALL-$(CONFIG_ARCH_ZYNQ)+= $(obj)/boot.bin
ALL-$(CONFIG_ARCH_ZYNQMP) += $(obj)/boot.bin
+ALL-$(CONFIG_ARCH_MEDIATEK)+= $(obj)/u-boot-spl-mtk.bin
+
all: $(ALL-y)
quiet_cmd_cat = CAT $@
@@ -349,6 +351,15 @@ cmd_sunxi_spl_image_builder =
$(objtree)/tools/sunxi-spl-image-builder \
$(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
$(call if_changed,sunxi_spl_image_builder)
+
+# MediaTek's specific SPL build
+MKIMAGEFLAGS_u-boot-spl-mtk.bin = -T mtk_image \
+ -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) \
+ -n "$(patsubst "%",%,$(CONFIG_MTK_BROM_HEADER_INFO))"
+
+$(obj)/u-boot-spl-mtk.bin: $(obj)/u-boot-spl.bin FORCE
+ $(call if_changed,mkimage)
+
# Rule to link u-boot-spl
# May be overridden by arch/$(ARCH)/config.mk
quiet_cmd_u-boot-spl ?= LD $@
diff --git a/tools/Makefile b/tools/Makefile
index 3c0521f..c93d17a 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -116,6 +116,7 @@ dumpimage-mkimage-objs := aisimage.o \
$(LIBFDT_OBJS) \
gpimage.o \
gpimage-common.o \
+ mtk_image.o \
$(RSA_OBJS-y)
dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
diff --git a/tools/mtk_image.c b/tools/mtk_image.c
new file mode 100644
index 000..2706d2d
--- /dev/null
+++ b/tools/mtk_image.c
@@ -0,0 +1,749 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Generate MediaTek BootROM header for SPL/U-Boot images
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Weijie Gao
+ */
+
+#include
+#include
+#include "imagetool.h"
+#include
[U-Boot] [PATCH v5 06/18] clk: MediaTek: add clock driver for MT7629 SoC.
This patch adds clock modules for MediaTek SoCs:
- Shared part: a common driver which contains the general operations
for plls, muxes, dividers and gates so that we can reuse it in future.
- Specific SoC part: the group of structures used to hold the hardware
configuration for each SoC.
We take MT7629 as an example to demonstrate how to implement driver if
any other MediaTek chips would like to use it.
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5: None
Changes since v4
-Add a __common_ infix on the shared funcitons to make them clear.
(i.e., mtk_clk_init() -> mtk_common_clk_init())
---
drivers/clk/Makefile | 1 +
drivers/clk/mediatek/Makefile | 6 +
drivers/clk/mediatek/clk-mt7629.c | 709 ++
drivers/clk/mediatek/clk-mtk.c| 493 ++
drivers/clk/mediatek/clk-mtk.h| 194 +++
5 files changed, 1403 insertions(+)
create mode 100644 drivers/clk/mediatek/Makefile
create mode 100644 drivers/clk/mediatek/clk-mt7629.c
create mode 100644 drivers/clk/mediatek/clk-mtk.c
create mode 100644 drivers/clk/mediatek/clk-mtk.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 821b586..c128538 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -10,6 +10,7 @@ obj-y += imx/
obj-y += tegra/
obj-$(CONFIG_ARCH_ASPEED) += aspeed/
obj-$(CONFIG_ARCH_MESON) += clk_meson.o
+obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_ARCH_SOCFPGA) += altera/
obj-$(CONFIG_CLK_AT91) += at91/
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
new file mode 100644
index 000..297f99d
--- /dev/null
+++ b/drivers/clk/mediatek/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+# Core
+obj-$(CONFIG_ARCH_MEDIATEK) += clk-mtk.o
+
+# SoC Drivers
+obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
diff --git a/drivers/clk/mediatek/clk-mt7629.c
b/drivers/clk/mediatek/clk-mt7629.c
new file mode 100644
index 000..2601b6c
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt7629.c
@@ -0,0 +1,709 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MediaTek clock driver for MT7629 SoC
+ *
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ */
+
+#include
+#include
+#include
+#include
+
+#include "clk-mtk.h"
+
+#define MT7629_CLKSQ_STB_CON0 0x20
+#define MT7629_PLL_ISO_CON00x2c
+#define MT7629_PLL_FMAX(2500UL * MHZ)
+#define MT7629_CON0_RST_BARBIT(24)
+
+#define MCU_AXI_DIV0x640
+#define AXI_DIV_MSKGENMASK(4, 0)
+#define AXI_DIV_SEL(x) (x)
+
+#define MCU_BUS_MUX0x7c0
+#define MCU_BUS_MSKGENMASK(10, 9)
+#define MCU_BUS_SEL(x) ((x) << 9)
+
+/* apmixedsys */
+#define PLL(_id, _reg, _pwr_reg, _en_mask, _flags, _pcwbits, _pd_reg, \
+ _pd_shift, _pcw_reg, _pcw_shift) { \
+ .id = _id, \
+ .reg = _reg,\
+ .pwr_reg = _pwr_reg,\
+ .en_mask = _en_mask,\
+ .rst_bar_mask = MT7629_CON0_RST_BAR,\
+ .fmax = MT7629_PLL_FMAX,\
+ .flags = _flags,\
+ .pcwbits = _pcwbits,\
+ .pd_reg = _pd_reg, \
+ .pd_shift = _pd_shift, \
+ .pcw_reg = _pcw_reg,\
+ .pcw_shift = _pcw_shift,\
+ }
+
+static const struct mtk_pll_data apmixed_plls[] = {
+ PLL(CLK_APMIXED_ARMPLL, 0x200, 0x20c, 0x1, 0,
+ 21, 0x204, 24, 0x204, 0),
+ PLL(CLK_APMIXED_MAINPLL, 0x210, 0x21c, 0x1, HAVE_RST_BAR,
+ 21, 0x214, 24, 0x214, 0),
+ PLL(CLK_APMIXED_UNIV2PLL, 0x220, 0x22c, 0x1, HAVE_RST_BAR,
+ 7, 0x224, 24, 0x224, 14),
+ PLL(CLK_APMIXED_ETH1PLL, 0x300, 0x310, 0x1, 0,
+ 21, 0x300, 1, 0x304, 0),
+ PLL(CLK_APMIXED_ETH2PLL, 0x314, 0x320, 0x1, 0,
+ 21, 0x314, 1, 0x318, 0),
+ PLL(CLK_APMIXED_SGMIPLL, 0x358, 0x368, 0x1, 0,
+ 21, 0x358, 1, 0x35c, 0),
+};
+
+/* topckgen */
+#define FACTOR0(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
+
+#define FACTOR1(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
+
+#define FACTOR2(_id, _parent, _mult, _div) \
+ FACTOR(_id, _parent, _mult, _div, 0)
+
+static const struct mtk_fixed_clk top_fixed_clks[] = {
+
[U-Boot] [PATCH v5 03/18] arm: dts: MediaTek: add device tree for MT7623
This adds device tree for MT7623 development board - Bananapi R2
Detailed hardware information for BPI-R2 which could be found on
http://wiki.banana-pi.org/Banana_Pi_BPI-R2.
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
Reviewed-by: Simon Glass
---
Changes since v5: Use new compatible 'mediatek,hsuart' for MTK UART
Changes since v4: None
---
arch/arm/dts/Makefile| 1 +
arch/arm/dts/mt7623.dtsi | 255 +++
arch/arm/dts/mt7623n-bananapi-bpi-r2.dts | 207
include/dt-bindings/clock/mt7623-clk.h | 413 +++
include/dt-bindings/power/mt7623-power.h | 19 ++
5 files changed, 895 insertions(+)
create mode 100644 arch/arm/dts/mt7623.dtsi
create mode 100644 arch/arm/dts/mt7623n-bananapi-bpi-r2.dts
create mode 100644 include/dt-bindings/clock/mt7623-clk.h
create mode 100644 include/dt-bindings/power/mt7623-power.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2001e63..4b30ef9 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -559,6 +559,7 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb
dtb-$(CONFIG_ARCH_MEDIATEK) += \
+ mt7623n-bananapi-bpi-r2.dtb \
mt7629-rfb.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/mt7623.dtsi b/arch/arm/dts/mt7623.dtsi
new file mode 100644
index 000..f50f4ef
--- /dev/null
+++ b/arch/arm/dts/mt7623.dtsi
@@ -0,0 +1,255 @@
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "mediatek,mt7623";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "mediatek,mt6589-smp";
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ clocks = < CLK_INFRA_CPUSEL>,
+< CLK_APMIXED_MAINPLL>;
+ clock-names = "cpu", "intermediate";
+ clock-frequency = <13>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ clocks = < CLK_INFRA_CPUSEL>,
+< CLK_APMIXED_MAINPLL>;
+ clock-names = "cpu", "intermediate";
+ clock-frequency = <13>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x2>;
+ clocks = < CLK_INFRA_CPUSEL>,
+< CLK_APMIXED_MAINPLL>;
+ clock-names = "cpu", "intermediate";
+ clock-frequency = <13>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x3>;
+ clocks = < CLK_INFRA_CPUSEL>,
+< CLK_APMIXED_MAINPLL>;
+ clock-names = "cpu", "intermediate";
+ clock-frequency = <13>;
+ };
+ };
+
+ system_clk: dummy13m {
+ compatible = "fixed-clock";
+ clock-frequency = <1300>;
+ #clock-cells = <0>;
+ };
+
+ rtc32k: oscillator-1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32000>;
+ clock-output-names = "rtc32k";
+ };
+
+ clk26m: oscillator-0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2600>;
+ clock-output-names = "clk26m";
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupt-parent = <>;
+ interrupts = ,
+,
+,
+;
+ clock-frequency = <1300>;
+ arm,cpu-registers-not-fw-configured;
+ };
+
+ topckgen: clock-controller@1000 {
+ compatible = "mediatek,mt7623-topckgen";
+ reg = <0x1000 0x1000>;
+ #clock-cells = <1>;
+ u-boot,dm-pre-reloc;
+ };
+
+ infracfg: syscon@10001000 {
+ compatible = "mediatek,mt7623-infracfg", "syscon";
+ reg = <0x10001000 0x1000>;
+ #clock-cells = <1>;
+
[U-Boot] [PATCH v5 05/18] arm: MediaTek: add basic support for MT7623 boards
From: Weijie Gao
This adds a general board file based on MT7623 SoCs from MediaTek.
As this u-boot is loaded by MTK proprietary preloader, there is no
low level initializtion codes.
Signed-off-by: Weijie Gao
Signed-off-by: Ryder Lee
Tested-by: Matthias Brugger
---
Changes since v5: None
Changes since v4:
-Add gd->bd->bi_boot_params for legacy method - ATAGs.
---
arch/arm/mach-mediatek/Kconfig| 13
arch/arm/mach-mediatek/Makefile | 1 +
arch/arm/mach-mediatek/mt7623/Makefile| 4 ++
arch/arm/mach-mediatek/mt7623/init.c | 54 +++
arch/arm/mach-mediatek/mt7623/lowlevel_init.S | 22 ++
arch/arm/mach-mediatek/mt7623/preloader.h | 99 +++
board/mediatek/mt7623/Kconfig | 13
board/mediatek/mt7623/MAINTAINERS | 7 ++
board/mediatek/mt7623/Makefile| 3 +
board/mediatek/mt7623/mt7623_rfb.c| 16 +
configs/mt7623n_bpir2_defconfig | 54 +++
include/configs/mt7623.h | 56 +++
12 files changed, 342 insertions(+)
create mode 100644 arch/arm/mach-mediatek/mt7623/Makefile
create mode 100644 arch/arm/mach-mediatek/mt7623/init.c
create mode 100644 arch/arm/mach-mediatek/mt7623/lowlevel_init.S
create mode 100644 arch/arm/mach-mediatek/mt7623/preloader.h
create mode 100644 board/mediatek/mt7623/Kconfig
create mode 100644 board/mediatek/mt7623/MAINTAINERS
create mode 100644 board/mediatek/mt7623/Makefile
create mode 100644 board/mediatek/mt7623/mt7623_rfb.c
create mode 100644 configs/mt7623n_bpir2_defconfig
create mode 100644 include/configs/mt7623.h
diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index d2ada97..7a733e9 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -9,6 +9,18 @@ config SYS_VENDOR
choice
prompt "MediaTek board select"
+config TARGET_MT7623
+ bool "MediaTek MT7623 SoC"
+ select CPU_V7A
+ select ARCH_MISC_INIT
+ help
+ The MediaTek MT7623 is a ARM-based SoC with a quad-core Cortex-A7
+ including NEON and GPU, Mali-450 graphics, several DDR3 options,
+ crypto engine, built-in Wi-Fi / Bluetooth combo chip, JPEG decoder,
+ video interfaces supporting HDMI and MIPI, and video codec support.
+ Peripherals include Gigabit Ethernet, switch, USB3.0 and OTG, PCIe,
+ I2S, PCM, S/PDIF, UART, SPI, I2C, IR TX/RX, and PWM.
+
config TARGET_MT7629
bool "MediaTek MT7629 SoC"
select CPU_V7A
@@ -21,6 +33,7 @@ config TARGET_MT7629
endchoice
+source "board/mediatek/mt7623/Kconfig"
source "board/mediatek/mt7629/Kconfig"
endif
diff --git a/arch/arm/mach-mediatek/Makefile b/arch/arm/mach-mediatek/Makefile
index 852d330..b5d3a37 100644
--- a/arch/arm/mach-mediatek/Makefile
+++ b/arch/arm/mach-mediatek/Makefile
@@ -3,4 +3,5 @@
obj-y += cpu.o
obj-$(CONFIG_SPL_BUILD)+= spl.o
+obj-$(CONFIG_TARGET_MT7623) += mt7623/
obj-$(CONFIG_TARGET_MT7629) += mt7629/
diff --git a/arch/arm/mach-mediatek/mt7623/Makefile
b/arch/arm/mach-mediatek/mt7623/Makefile
new file mode 100644
index 000..007eb4a
--- /dev/null
+++ b/arch/arm/mach-mediatek/mt7623/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-y += init.o
+obj-y += lowlevel_init.o
diff --git a/arch/arm/mach-mediatek/mt7623/init.c
b/arch/arm/mach-mediatek/mt7623/init.c
new file mode 100644
index 000..0ee8c66
--- /dev/null
+++ b/arch/arm/mach-mediatek/mt7623/init.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "preloader.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct boot_argument *preloader_param;
+
+int mtk_soc_early_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ u32 i;
+
+ if (((size_t)preloader_param >= CONFIG_SYS_SDRAM_BASE) &&
+ ((size_t)preloader_param % sizeof(size_t) == 0) &&
+ preloader_param->magic == BOOT_ARGUMENT_MAGIC &&
+ preloader_param->dram_rank_num <=
+ ARRAY_SIZE(preloader_param->dram_rank_size)) {
+ gd->ram_size = 0;
+
+ for (i = 0; i < preloader_param->dram_rank_num; i++)
+ gd->ram_size += preloader_param->dram_rank_size[i];
+ } else {
+ gd->ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+ SZ_2G);
+ }
+
+ return 0;
+}
+
+int print_cpuinfo(void)
+{
+ void __iomem *chipid;
+ u32 swver;
+
+ chipid = ioremap(VER_BASE, VER_SIZE);
+ swver = readl(chipid + APSW_VER);
+
+ printf("CPU: MediaTek MT7623 E%d\n", (swver & 0xf) + 1);
+
+ return 0;
+}
diff --git a/arch/arm/mach-mediatek/mt7623/lowlevel_init.S
b/arch/arm/mach-mediatek/mt7623/lowlevel_init.S
new file mode 100644
index 000..afb9476
---
[U-Boot] [PATCH v5 02/18] arm: dts: MediaTek: add device tree for MT7629
This patch adds MT7629 device tree and the includes it needs.
Signed-off-by: Ryder Lee
Reviewed-by: Simon Glass
---
Changes since v5: Use new compatible 'mediatek,hsuart' for MTK UART
Changes since v4: None
---
arch/arm/dts/Makefile| 3 +
arch/arm/dts/mt7629-rfb-u-boot.dtsi | 24 +++
arch/arm/dts/mt7629-rfb.dts | 70 +
arch/arm/dts/mt7629.dtsi | 244 +++
include/dt-bindings/clock/mt7629-clk.h | 206 ++
include/dt-bindings/power/mt7629-power.h | 13 ++
6 files changed, 560 insertions(+)
create mode 100644 arch/arm/dts/mt7629-rfb-u-boot.dtsi
create mode 100644 arch/arm/dts/mt7629-rfb.dts
create mode 100644 arch/arm/dts/mt7629.dtsi
create mode 100644 include/dt-bindings/clock/mt7629-clk.h
create mode 100644 include/dt-bindings/power/mt7629-power.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d36447d..2001e63 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -558,6 +558,9 @@ dtb-$(CONFIG_TARGET_STM32MP1) += \
dtb-$(CONFIG_SOC_K3_AM6) += k3-am654-base-board.dtb
+dtb-$(CONFIG_ARCH_MEDIATEK) += \
+ mt7629-rfb.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/mt7629-rfb-u-boot.dtsi
b/arch/arm/dts/mt7629-rfb-u-boot.dtsi
new file mode 100644
index 000..1ef5568
--- /dev/null
+++ b/arch/arm/dts/mt7629-rfb-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author: Weijie Gao
+ */
+
+#include
+/ {
+ binman {
+ filename = "u-boot-mtk.bin";
+ pad-byte = <0xff>;
+
+#ifdef CONFIG_SPL
+ blob {
+ filename = "spl/u-boot-spl-mtk.bin";
+ size = ;
+ };
+
+ u-boot-img {
+ };
+#endif
+ };
+};
diff --git a/arch/arm/dts/mt7629-rfb.dts b/arch/arm/dts/mt7629-rfb.dts
new file mode 100644
index 000..a6d28a0
--- /dev/null
+++ b/arch/arm/dts/mt7629-rfb.dts
@@ -0,0 +1,70 @@
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+/dts-v1/;
+#include "mt7629.dtsi"
+
+/ {
+ model = "MediaTek MT7629 RFB";
+ compatible = "mediatek,mt7629-rfb", "mediatek,mt7629";
+
+ aliases {
+ spi0 =
+ };
+
+ chosen {
+ stdout-path =
+ tick-timer =
+ };
+};
+
+ {
+ qspi_pins: qspi-pins {
+ mux {
+ function = "flash";
+ groups = "spi_nor";
+ };
+ };
+
+ uart0_pins: uart0-default {
+ mux {
+ function = "uart";
+ groups = "uart0_txd_rxd";
+ };
+ };
+
+ watchdog_pins: watchdog-default {
+ mux {
+ function = "watchdog";
+ groups = "watchdog";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+
+ spi-flash@0{
+ compatible = "spi-flash";
+ reg = <0>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/mt7629.dtsi b/arch/arm/dts/mt7629.dtsi
new file mode 100644
index 000..e6052bb
--- /dev/null
+++ b/arch/arm/dts/mt7629.dtsi
@@ -0,0 +1,244 @@
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ * Author: Ryder Lee
+ *
+ * SPDX-License-Identifier: (GPL-2.0 OR MIT)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "mediatek,mt7629";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "mediatek,mt6589-smp";
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x0>;
+ clock-frequency = <125000>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0x1>;
+ clock-frequency = <125000>;
+ };
+ };
+
+ clk20m: oscillator@0 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2000>;
+ clock-output-names = "clk20m";
+ };
+
+ clk40m: oscillator@1 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+
Re: [U-Boot] [PATCH] imx: Add PHYTEC phyBOARD-i.MX6UL-Segin
Hi Martyn, > Port for the PHYTEC phyBOARD-i.MX6UL-Segin single board computer. > Based on the PHYTEC phyCORE-i.MX6UL SOM (PCL063). This port provides > both SPL and DCD based boot options (hence the two defconfigs). > > CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz) > CPU: Industrial temperature grade (-40C to 105C) at 44C > Reset cause: POR > Board: PHYTEC phyCORE-i.MX6UL > I2C: ready > DRAM: 256 MiB > NAND: 512 MiB > MMC: FSL_SDHC: 0 > In:serial > Out: serial > Err: serial > Net: FEC0 > > Working: > - Eth0 > - Eth1 > - i2C > - MMC/SD > - NAND > - UART (1 & 5) > - USB (host & otg) Could you double check if maybe you could use Driver Model versions of some drivers? To be more specific - the ETH interfaces, I2C, eMMC, etc. > > Signed-off-by: Martyn Welch > > --- > > arch/arm/mach-imx/mx6/Kconfig| 8 + > board/phytec/pcl063/Kconfig | 12 + > board/phytec/pcl063/MAINTAINERS | 7 + > board/phytec/pcl063/Makefile | 7 + > board/phytec/pcl063/README | 43 +++ > board/phytec/pcl063/imximage.cfg | 177 + > board/phytec/pcl063/pcl063.c | 379 > +++ board/phytec/pcl063/spl.c| > 118 + configs/phycore_pcl063_defconfig | 47 > configs/phycore_pcl063_spl_defconfig | 55 > include/configs/pcl063.h | 107 > 11 files changed, 960 insertions(+) > create mode 100644 board/phytec/pcl063/Kconfig > create mode 100644 board/phytec/pcl063/MAINTAINERS > create mode 100644 board/phytec/pcl063/Makefile > create mode 100644 board/phytec/pcl063/README > create mode 100644 board/phytec/pcl063/imximage.cfg > create mode 100644 board/phytec/pcl063/pcl063.c > create mode 100644 board/phytec/pcl063/spl.c > create mode 100644 configs/phycore_pcl063_defconfig > create mode 100644 configs/phycore_pcl063_spl_defconfig > create mode 100644 include/configs/pcl063.h > > diff --git a/arch/arm/mach-imx/mx6/Kconfig > b/arch/arm/mach-imx/mx6/Kconfig index 06c25bae36..22aea99f8f 100644 > --- a/arch/arm/mach-imx/mx6/Kconfig > +++ b/arch/arm/mach-imx/mx6/Kconfig > @@ -428,6 +428,13 @@ config TARGET_PFLA02 > select MX6QDL > select SUPPORT_SPL > > +config TARGET_PCL063 > + bool "PHYTEC PCL063 (phyCORE-i.MX6UL)" > + select MX6UL > + select DM > + select DM_THERMAL > + select SUPPORT_SPL Your board is only selecting DM_THERMAL. One good way to check the list of DM aware (used) blocks is to run "dm list" > + > config TARGET_SECOMX6 > bool "secomx6 boards" > > @@ -550,6 +557,7 @@ source "board/freescale/mx6ullevk/Kconfig" > source "board/grinn/liteboard/Kconfig" > source "board/phytec/pcm058/Kconfig" > source "board/phytec/pfla02/Kconfig" > +source "board/phytec/pcl063/Kconfig" > source "board/gateworks/gw_ventana/Kconfig" > source "board/kosagi/novena/Kconfig" > source "board/samtec/vining_2000/Kconfig" > diff --git a/board/phytec/pcl063/Kconfig b/board/phytec/pcl063/Kconfig > new file mode 100644 > index 00..977db70f64 > --- /dev/null > +++ b/board/phytec/pcl063/Kconfig > @@ -0,0 +1,12 @@ > +if TARGET_PCL063 > + > +config SYS_BOARD > + default "pcl063" > + > +config SYS_VENDOR > + default "phytec" > + > +config SYS_CONFIG_NAME > + default "pcl063" > + > +endif > diff --git a/board/phytec/pcl063/MAINTAINERS > b/board/phytec/pcl063/MAINTAINERS new file mode 100644 > index 00..8edc45827c > --- /dev/null > +++ b/board/phytec/pcl063/MAINTAINERS > @@ -0,0 +1,7 @@ > +PCL063 BOARD > +M: Martyn Welch > +S: Maintained > +F: board/phytec/pcl063/ > +F: configs/phycore_pcl063_defconfig > +F: configs/phycore_pcl063_spl_defconfig > +F: include/configs/pcl063.h > diff --git a/board/phytec/pcl063/Makefile > b/board/phytec/pcl063/Makefile new file mode 100644 > index 00..53c73c9b08 > --- /dev/null > +++ b/board/phytec/pcl063/Makefile > @@ -0,0 +1,7 @@ > +# Copyright (C) 2018 Collabora Ltd. > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +obj-y := pcl063.o > +obj-$(CONFIG_SPL_BUILD) += spl.o > diff --git a/board/phytec/pcl063/README b/board/phytec/pcl063/README > new file mode 100644 > index 00..d73e90e83d > --- /dev/null > +++ b/board/phytec/pcl063/README > @@ -0,0 +1,43 @@ > +How to use U-Boot on PHYTEC phyBOARD-i.MX6UL-Segin > +-- > + > +- Clean U-Boot tree: > + > +$ make mrproper > + > +- Configure U-Boot for phyCORE-i.MX6UL (using DCD): > + > +$ make phycore_pcl063_defconfig > + > + Or for build with SPL: > + > +$ make phycore_pcl063_spl_defconfig > + > +- Build U-Boot > + > +$ make > + > + This will either generate an u-boot.imx image or SPL and > u-boot-dtb.img > + images depending on the config chosen. > + > +- When an u-boot.imx image has been built, flash this into a micro > SD card as > + follows: > + > +$ sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1k seek=1; sync > + >
Re: [U-Boot] [U-Boot, v2, 2/2] rockchip: fix incorrect detection of ram size
> Taken from coreboot's src/soc/rockchip/rk3288/sdram.c > > Without this change, my u-boot build for the asus c201 chromebook (4GiB) > is incorrectly detected as 0 Bytes of ram. > > Signed-off-by: Marty E. Plummer > --- > arch/arm/mach-rockchip/sdram_common.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2, 1/2] rockchip: add support for veyron-speedy (ASUS Chromebook C201)
> This adds support for the ASUS C201, a RK3288-based clamshell > device. The device tree comes from linus's linux tree at > 3f16503b7d2274ac8cbab11163047ac0b4c66cfe. The SDRAM parameters > are for 4GB Samsung LPDDR3, decoded from coreboot's > src/mainboard/google/veyron/sdram_inf/sdram-lpddr3-samsung-4GB.inc > > Signed-off-by: Marty E. Plummer > Reviewed-by: Simon Glass > --- > arch/arm/dts/Makefile | 1 + > arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 31 > arch/arm/dts/rk3288-veyron-speedy.dts | 143 ++ > arch/arm/mach-rockchip/rk3288-board-spl.c | 3 +- > arch/arm/mach-rockchip/rk3288/Kconfig | 11 ++ > board/google/veyron/Kconfig | 16 ++ > configs/chromebook_speedy_defconfig | 98 > 7 files changed, 302 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3288-veyron-speedy.dts > create mode 100644 configs/chromebook_speedy_defconfig > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
Hi Simon,
On Wed, Nov 14, 2018 at 1:07 PM Simon Goldschmidt
wrote:
>
> On 14.11.2018 16:51, Simon Goldschmidt wrote:
> > On 14.11.2018 16:35, Daniele Bianco wrote:
> >> On Wed, Nov 14, 2018 at 04:26:17PM +0100, Andrea Barisani wrote:
> >>> On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
> On 14.11.2018 15:45, Andrea Barisani wrote:
> > On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
> >> On 14.11.2018 12:52, Andrea Barisani wrote:
> >>> On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
> On 06.11.2018 15:51, Andrea Barisani wrote:
> > [..]
> > The issue can be exploited by several means:
> >
> >- An excessively large crafted boot image file is parsed by
> > the
> > `tftp_handler` function which lacks any size checks,
> > allowing the memory
> > overwrite.
> >
> >- A malicious server can manipulate TFTP packet sequence
> > numbers to store
> > downloaded file chunks at arbitrary memory locations,
> > given that the
> > sequence number is directly used by the `tftp_handler`
> > function to calculate
> > the destination address for downloaded file chunks.
> >
> > Additionally the `store_block` function, used to store
> > downloaded file
> > chunks in memory, when invoked by `tftp_handler` with a
> > `tftp_cur_block`
> > value of 0, triggers an unchecked integer underflow.
> >
> > This allows to potentially erase memory located before the
> > `loadAddr` when
> > a packet is sent with a null, following at least one valid
> > packet.
> Do you happen to have more details on this suggested integer
> underflow? I
> have tried to reproduce it, but I failed to get a memory write
> address
> before 'load_addr'. This is because the 'store_block' function does
> not
> directly use the underflowed integer as a block counter, but adds
> 'tcp_block_wrap_offset' to this offset.
>
> To me it seems like alternating between '0' and 'not 0' for the block
> counter could increase memory overwrites, but I fail to see how you
> can use
> this to store chunks at arbitrary memory locations. All you can do is
> subtract one block size from 'tftp_block_wrap_offset'...
>
> Simon
>
> >>> Hello Simon,
> >>>
> >>> the integer underflow can happen if a malicious TFTP server, able to
> >>> control
> >>> the TFTP packets sequence number, sends a crafted packet with
> >>> sequence number
> >>> set to 0 during a flow.
> >>>
> >>> This happens because, within the store_block() function, the 'block'
> >>> argument
> >>> is declared as 'int' and when it is invoked inside tftp_handler()
> >>> (case
> >>> TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
> >>> tftp_cur_block is the sequence number extracted from the tftp packet
> >>> without
> >>> any previous check):
> >>>
> >>> static inline void store_block(int block, uchar *src, unsigned len)
> >>>^ can have negative values
> >>> (e.g. -1)
> >>> {
> >>> ulong offset = block * tftp_block_size +
> >>> tftp_block_wrap_offset;
> >>> ^
> >>> here if block is -1 the result stored onto offset would
> >>> be a very
> >>> large unsigned number, due to type conversions
> >> And this is exatclty my point. This might be bad coding style, but for
> >> me it
> >> works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
> >> '-512'. Now from the code flow in tftp_handler(), it's clear that if
> >> we come
> >> here with tftp_cur_block == 0 (so 'block' is -1),
> >> 'tftp_block_wrap_offset'
> >> is not 0 but some positive value 'x * tftp_block_size' (see function
> >> 'update_block_number').
> >>
> >> So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still
> >> fail
> >> to see how this can be a very large positive number resulting in an
> >> effective negative offset or arbitrary write.
> >>
> > I understand your point, however what does happen when we enter the
> > 'case
> > TFTP_DATA' and we are in the first block received, so we trigger
> > new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
> > tftp_mcast_active is set?
> >
> > I don't see any protection for this case for the underflow, am I wrong?
> >
> > static void new_transfer(void)
> > {
> >
Re: [U-Boot] [U-Boot, 1/2] rockchip: rk3188: add support for usb-uart functionality
> Rockchip socs can route the debug uart pins through the d+ and d- pins > of one specific usbphy per soc. Add a config option and implement the > setting on the rk3188. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich > --- > .../include/asm/arch-rockchip/grf_rk3188.h| 42 +++ > arch/arm/mach-rockchip/Kconfig| 8 > arch/arm/mach-rockchip/rk3188-board-spl.c | 27 ++-- > 3 files changed, 73 insertions(+), 4 deletions(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: video: mipi: Do not write to the version register
> There was a copy and paste error where the data > enable setting was written to the version register. > > Signed-off-by: Richard Röjfors > --- > drivers/video/rockchip/rk_mipi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] rockchip: rk3188: fix early uart setup
> Commit 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions
> into pinctrl-driver") moved the iomux settings out of the grf header
> to prevent conflicts with the iomux definitions of other rockchip socs.
>
> This also breaks the early uart setup, as the iomux for uart2 are needed.
> To fix that just put the tiny amount of needed iomux definitions next to
> the early uart code.
>
> Fixes: 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions
> into pinctrl-driver")
> Signed-off-by: Heiko Stuebner
> Reviewed-by: Philipp Tomsich
> ---
> arch/arm/mach-rockchip/rk3188-board-spl.c | 10 ++
> 1 file changed, 10 insertions(+)
>
Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: video: mipi: Fix phy frequency setting
> There was an incorrect check when looping and finding the first > fast enough frequency in the freq_rang table. The code did > actually return the first that was either exactly correct or > too slow. > > Signed-off-by: Richard Röjfors > Reviewed-by: Philipp Tomsich > --- > drivers/video/rockchip/rk_mipi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-rockchip, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v13 1/4] sandbox: smbios: Update to support sandbox
Hi Alex,
On 14 November 2018 at 02:18, Alexander Graf wrote:
>
> On 11/14/2018 07:50 AM, Simon Glass wrote:
>>
>> At present this code casts addresses to pointers so cannot be used with
>> sandbox. Update it to use mapmem instead.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v13:
>> - Update code to deal with the struct_table_address member
>>
>> Changes in v12: None
>> Changes in v11:
>> - Fix the EFI code that has since been added and relies on broken behaviour
>>
>> Changes in v9: None
>> Changes in v7: None
>> Changes in v5: None
>> Changes in v4: None
>> Changes in v3:
>> - Drop incorrect map_sysmem() in write_smbios_table()
>>
>> lib/efi_loader/efi_smbios.c | 20 +-
>> lib/smbios.c| 52 ++---
>> 2 files changed, 56 insertions(+), 16 deletions(-)
>>
[..]
>> +
>> + /*
>> +* We must use a pointer here so things work correctly on sandbox.
>> The
>> +* user of this table is not aware of the mapping of addresses to
>> +* sandbox's DRAM buffer.
>> +*/
>> + table_addr = (ulong)map_sysmem(tables, 0);
>> + if (sizeof(table_addr) >= sizeof(u32) && table_addr >= (1ULL << 32))
>> {
>
>
> sizeof(long) >= sizeof(u32) will always be true on any platform U-Boot
> supports, no?
>
> How about
>
> if (sizeof(table_addr) > sizeof(u32) && table_addr > (ulong)UINT_MAX)
Yes that seems right, thanks.
>
>> + /*
>> +* We need to put this >32-bit pointer into the table but the
>> +* field is only 32 bits wide.
>> +*/
>> + printf("WARNING: SMBIOS table_address overflow %llx\n",
>> + (unsigned long long)table_addr);
>> + table_addr = 0;
>
>
> I'm also not sure what to do about the error case. IMHO ideally we should
> propagate the error to the upper layers, but consider it non-fatal.
Yes agreed, but it involves changing the function signature of this
and everything else in table_write_funcs[] so I decided to leave it
alone for now, since the effect is the same.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v14 2/4] efi: Split out test init/uninit into functions
The functions in bootefi are very long because they mix high-level code
and control with the low-level implementation. To help with this, create
functions which handle preparing for running the test and cleaning up
afterwards.
Also shorten the awfully long variable names here.
Signed-off-by: Simon Glass
---
Changes in v14:
- Go back to the horrible long variable names
Changes in v13:
- Rebase to efi/efi-next
Changes in v12:
- Rename image to image_prot
Changes in v11: None
Changes in v9:
- Add comments to bootefi_test_prepare() about the memset()s
Changes in v7: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
Changes in v4: None
Changes in v3:
- Add new patch to split out test init/uninit into functions
cmd/bootefi.c | 81 +--
1 file changed, 65 insertions(+), 16 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 3e37805ea13..b633e956c23 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -453,6 +453,67 @@ exit:
return ret;
}
+#ifdef CONFIG_CMD_BOOTEFI_SELFTEST
+/**
+ * bootefi_test_prepare() - prepare to run an EFI test
+ *
+ * This sets things up so we can call EFI functions. This involves preparing
+ * the 'gd' pointer and setting up the load ed image data structures.
+ *
+ * @image_objp: loaded_image_infop: Pointer to a struct which will hold the
+ *loaded image object. This struct will be inited by this function before
+ *use.
+ * @loaded_image_infop: Pointer to a struct which will hold the loaded image
+ *info. This struct will be inited by this function before use.
+ * @path: File path to the test being run (often just the test name with a
+ *backslash before it
+ * @test_func: Address of the test function that is being run
+ * @return 0 if OK, -ve on error
+ */
+static efi_status_t bootefi_test_prepare(
+ struct efi_loaded_image_obj **image_objp,
+ struct efi_loaded_image **loaded_image_infop,
+ const char *path,
+ ulong test_func)
+{
+ efi_status_t r;
+
+ /* Construct a dummy device path */
+ bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
+ (uintptr_t)test_func,
+ (uintptr_t)test_func);
+ bootefi_image_path = efi_dp_from_file(NULL, 0, path);
+ r = efi_setup_loaded_image(bootefi_device_path, bootefi_image_path,
+ image_objp, loaded_image_infop);
+ if (r)
+ return r;
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable efi_selftest as load options */
+ set_load_options(*loaded_image_infop, "efi_selftest");
+
+ return 0;
+}
+
+/**
+ * bootefi_test_finish() - finish up after running an EFI test
+ *
+ * @image_obj: Pointer to a struct which holds the loaded image object
+ * @loaded_image_info: Pointer to a struct which holds the loaded image info
+ */
+static void bootefi_test_finish(struct efi_loaded_image_obj *image_obj,
+ struct efi_loaded_image *loaded_image_info)
+{
+ efi_restore_gd();
+ free(loaded_image_info->load_options);
+ efi_delete_handle(_obj->header);
+}
+#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
+
static int do_bootefi_bootmgr_exec(void)
{
struct efi_device_path *device_path, *file_path;
@@ -528,26 +589,14 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv[])
struct efi_loaded_image_obj *image_obj;
struct efi_loaded_image *loaded_image_info;
- /* Construct a dummy device path. */
- bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
- (uintptr_t)_selftest,
- (uintptr_t)_selftest);
- bootefi_image_path = efi_dp_from_file(NULL, 0, "\\selftest");
-
- r = efi_setup_loaded_image(bootefi_device_path,
- bootefi_image_path, _obj,
- _image_info);
- if (r != EFI_SUCCESS)
+ if (bootefi_test_prepare(_obj, _image_info,
+"\\selftest",
+(uintptr_t)_selftest))
return CMD_RET_FAILURE;
- efi_save_gd();
- /* Transfer environment variable efi_selftest as load options */
- set_load_options(loaded_image_info, "efi_selftest");
/* Execute the test */
r = efi_selftest(_obj->header, );
- efi_restore_gd();
-
Re: [U-Boot] [PATCH v13 4/4] efi: Rename bootefi_test_finish() to bootefi_run_finish()
Hi Alex,
On 14 November 2018 at 02:22, Alexander Graf wrote:
> On 11/14/2018 07:50 AM, Simon Glass wrote:
>>
>> This function can be used from do_bootefi_exec() so that we use mostly the
>> same code for a normal EFI application and an EFI test.
>>
>> Rename the function and use it in both places.
>>
>> Signed-off-by: Simon Glass
>> ---
>>
>> Changes in v13:
>> - Drop 'efi_loader: Drop setup_ok' as we have an existing patch for that
>> - Drop patches previously applied
>>
>> Changes in v12: None
>> Changes in v11:
>> - Drop patches previously applied
>>
>> Changes in v9: None
>> Changes in v7:
>> - Drop patch "efi: Init the 'rows' and 'cols' variables"
>> - Drop patches previous applied
>>
>> Changes in v5:
>> - Rebase to master
>>
>> Changes in v4:
>> - Rebase to master
>>
>> Changes in v3:
>> - Add new patch to rename bootefi_test_finish() to bootefi_run_finish()
>>
>> cmd/bootefi.c | 32
>> 1 file changed, 16 insertions(+), 16 deletions(-)
>>
>> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
>> index 492052d827a..317c7feb0a5 100644
>> --- a/cmd/bootefi.c
>> +++ b/cmd/bootefi.c
>> @@ -349,6 +349,20 @@ static efi_status_t bootefi_run_prepare(const char
>> *load_options_path,
>> return 0;
>> }
>> +/**
>> + * bootefi_run_finish() - finish up after running an EFI test
>> + *
>> + * @image: Pointer to a struct which holds the loaded image info
>> + * @obj: Pointer to a struct which holds the loaded image object
>> + */
>> +static void bootefi_run_finish(struct efi_loaded_image *image,
>> + struct efi_loaded_image_obj *obj)
>> +{
>> + efi_restore_gd();
>> + free(image->load_options);
>> + efi_delete_handle(>header);
>> +}
>> +
>> /**
>>* do_bootefi_exec() - execute EFI binary
>>*
>> @@ -466,8 +480,7 @@ static efi_status_t do_bootefi_exec(void *efi,
>> exit:
>> /* image has returned, loaded-image obj goes *poof*: */
>> - if (obj)
>> - efi_delete_handle(>header);
>
>
> What about the conditional dereference? The new bootefi_run_finish()
> function is dropping that.
Hmm yes. Actually it looks like the error handling in this function is
a bit broken. I'll rework it, hopefully without breaking it further.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v14 4/4] efi: Rename bootefi_test_finish() to bootefi_run_finish()
This function can be used from do_bootefi_exec() so that we use mostly the
same code for a normal EFI application and an EFI test.
Rename the function and use it in both places.
Signed-off-by: Simon Glass
---
Changes in v14:
- Go back to the horrible long variable names
- Hopefully correct error paths in do_bootefi_exec()
Changes in v13:
- Drop 'efi_loader: Drop setup_ok' as we have an existing patch for that
- Drop patches previously applied
Changes in v12: None
Changes in v11:
- Drop patches previously applied
Changes in v9: None
Changes in v7:
- Drop patch "efi: Init the 'rows' and 'cols' variables"
- Drop patches previous applied
Changes in v5:
- Rebase to master
Changes in v4:
- Rebase to master
Changes in v3:
- Add new patch to rename bootefi_test_finish() to bootefi_run_finish()
cmd/bootefi.c | 46 --
1 file changed, 24 insertions(+), 22 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index ab7ada9f2d6..a627f689f95 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -350,6 +350,20 @@ static efi_status_t bootefi_run_prepare(const char
*load_options_path,
return 0;
}
+/**
+ * bootefi_run_finish() - finish up after running an EFI test
+ *
+ * @loaded_image_info: Pointer to a struct which holds the loaded image info
+ * @image_objj: Pointer to a struct which holds the loaded image object
+ */
+static void bootefi_run_finish(struct efi_loaded_image_obj *image_obj,
+ struct efi_loaded_image *loaded_image_info)
+{
+ efi_restore_gd();
+ free(loaded_image_info->load_options);
+ efi_delete_handle(_obj->header);
+}
+
/**
* do_bootefi_exec() - execute EFI binary
*
@@ -390,11 +404,11 @@ static efi_status_t do_bootefi_exec(void *efi,
*/
ret = efi_create_handle(_handle);
if (ret != EFI_SUCCESS)
- goto exit;
+ return ret;
ret = efi_add_protocol(mem_handle, _guid_device_path,
device_path);
if (ret != EFI_SUCCESS)
- goto exit;
+ goto err_add_protocol;
} else {
assert(device_path && image_path);
}
@@ -402,13 +416,13 @@ static efi_status_t do_bootefi_exec(void *efi,
ret = bootefi_run_prepare("bootargs", device_path, image_path,
_obj, _image_info);
if (ret)
- return ret;
+ goto err_prepare;
/* Load the EFI payload */
entry = efi_load_pe(image_obj, efi, loaded_image_info);
if (!entry) {
ret = EFI_LOAD_ERROR;
- goto exit;
+ goto err_prepare;
}
if (memdp) {
@@ -428,7 +442,7 @@ static efi_status_t do_bootefi_exec(void *efi,
if (setjmp(_obj->exit_jmp)) {
ret = image_obj->exit_status;
- goto exit;
+ goto err_prepare;
}
#ifdef CONFIG_ARM64
@@ -466,10 +480,11 @@ static efi_status_t do_bootefi_exec(void *efi,
ret = efi_do_enter(_obj->header, , entry);
-exit:
+err_prepare:
/* image has returned, loaded-image obj goes *poof*: */
- if (image_obj)
- efi_delete_handle(_obj->header);
+ bootefi_run_finish(image_obj, loaded_image_info);
+
+err_add_protocol:
if (mem_handle)
efi_delete_handle(mem_handle);
@@ -510,19 +525,6 @@ static efi_status_t bootefi_test_prepare(
loaded_image_infop);
}
-/**
- * bootefi_test_finish() - finish up after running an EFI test
- *
- * @image_obj: Pointer to a struct which holds the loaded image object
- * @loaded_image_info: Pointer to a struct which holds the loaded image info
- */
-static void bootefi_test_finish(struct efi_loaded_image_obj *image_obj,
- struct efi_loaded_image *loaded_image_info)
-{
- efi_restore_gd();
- free(loaded_image_info->load_options);
- efi_delete_handle(_obj->header);
-}
#endif /* CONFIG_CMD_BOOTEFI_SELFTEST */
static int do_bootefi_bootmgr_exec(void)
@@ -607,7 +609,7 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
/* Execute the test */
r = efi_selftest(_obj->header, );
- bootefi_test_finish(image_obj, loaded_image_info);
+ bootefi_run_finish(image_obj, loaded_image_info);
return r != EFI_SUCCESS;
} else
#endif
--
2.19.1.1215.g8438c0b245-goog
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v14 1/4] sandbox: smbios: Update to support sandbox
At present this code casts addresses to pointers so cannot be used with
sandbox. Update it to use mapmem instead.
Signed-off-by: Simon Glass
---
Changes in v14:
- Fix condition for invalid pointer
Changes in v13:
- Update code to deal with the struct_table_address member
Changes in v12: None
Changes in v11:
- Fix the EFI code that has since been added and relies on broken behaviour
Changes in v9: None
Changes in v7: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Drop incorrect map_sysmem() in write_smbios_table()
lib/efi_loader/efi_smbios.c | 20 +-
lib/smbios.c| 52 ++---
2 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
index 38e42fa2432..a81488495e2 100644
--- a/lib/efi_loader/efi_smbios.c
+++ b/lib/efi_loader/efi_smbios.c
@@ -7,6 +7,7 @@
#include
#include
+#include
#include
static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
@@ -19,17 +20,19 @@ static const efi_guid_t smbios_guid = SMBIOS_TABLE_GUID;
efi_status_t efi_smbios_register(void)
{
/* Map within the low 32 bits, to allow for 32bit SMBIOS tables */
- u64 dmi = U32_MAX;
+ u64 dmi_addr = U32_MAX;
efi_status_t ret;
+ void *dmi;
/* Reserve 4kiB page for SMBIOS */
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_RUNTIME_SERVICES_DATA, 1, );
+EFI_RUNTIME_SERVICES_DATA, 1, _addr);
if (ret != EFI_SUCCESS) {
/* Could not find space in lowmem, use highmem instead */
ret = efi_allocate_pages(EFI_ALLOCATE_ANY_PAGES,
-EFI_RUNTIME_SERVICES_DATA, 1, );
+EFI_RUNTIME_SERVICES_DATA, 1,
+_addr);
if (ret != EFI_SUCCESS)
return ret;
@@ -39,11 +42,14 @@ efi_status_t efi_smbios_register(void)
* Generate SMBIOS tables - we know that efi_allocate_pages() returns
* a 4k-aligned address, so it is safe to assume that
* write_smbios_table() will write the table at that address.
+*
+* Note that on sandbox, efi_allocate_pages() unfortunately returns a
+* pointer even though it uses a uint64_t type. Convert it.
*/
- assert(!(dmi & 0xf));
- write_smbios_table(dmi);
+ assert(!(dmi_addr & 0xf));
+ dmi = (void *)(uintptr_t)dmi_addr;
+ write_smbios_table(map_to_sysmem(dmi));
/* And expose them to our EFI payload */
- return efi_install_configuration_table(_guid,
- (void *)(uintptr_t)dmi);
+ return efi_install_configuration_table(_guid, dmi);
}
diff --git a/lib/smbios.c b/lib/smbios.c
index 326eb00230d..e8ee55c4aeb 100644
--- a/lib/smbios.c
+++ b/lib/smbios.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -72,9 +73,10 @@ static int smbios_string_table_len(char *start)
static int smbios_write_type0(ulong *current, int handle)
{
- struct smbios_type0 *t = (struct smbios_type0 *)*current;
+ struct smbios_type0 *t;
int len = sizeof(struct smbios_type0);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type0));
fill_smbios_header(t, SMBIOS_BIOS_INFORMATION, len, handle);
t->vendor = smbios_add_string(t->eos, "U-Boot");
@@ -101,16 +103,18 @@ static int smbios_write_type0(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type1(ulong *current, int handle)
{
- struct smbios_type1 *t = (struct smbios_type1 *)*current;
+ struct smbios_type1 *t;
int len = sizeof(struct smbios_type1);
char *serial_str = env_get("serial#");
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type1));
fill_smbios_header(t, SMBIOS_SYSTEM_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -122,15 +126,17 @@ static int smbios_write_type1(ulong *current, int handle)
len = t->length + smbios_string_table_len(t->eos);
*current += len;
+ unmap_sysmem(t);
return len;
}
static int smbios_write_type2(ulong *current, int handle)
{
- struct smbios_type2 *t = (struct smbios_type2 *)*current;
+ struct smbios_type2 *t;
int len = sizeof(struct smbios_type2);
+ t = map_sysmem(*current, len);
memset(t, 0, sizeof(struct smbios_type2));
fill_smbios_header(t, SMBIOS_BOARD_INFORMATION, len, handle);
t->manufacturer = smbios_add_string(t->eos, CONFIG_SMBIOS_MANUFACTURER);
@@ -140,15 +146,17 @@ static int smbios_write_type2(ulong
[U-Boot] [PATCH v14 0/4] efi_loader: Code refactoring and improvement
This collects the patches previously sent to break up the very large functions in efi_loader into smaller pieces. Now that the other sandbox stuff is applied, perhaps it is time to apply these patches. This also adds a few new patches to fix more recent breakages. Unfortunately we still cannot enable the efi loader tests since one of the tests fails. Thus we should expect additional failures to appear until that is resolved. Changes in v14: - Fix condition for invalid pointer - Go back to the horrible long variable names - Hopefully correct error paths in do_bootefi_exec() Changes in v13: - Drop 'efi_loader: Drop setup_ok' as we have an existing patch for that - Drop patches previously applied - Rebase to efi/efi-next - Update code to deal with the struct_table_address member Changes in v12: - Rename image to image_prot Changes in v11: - Drop patches previously applied - Fix the EFI code that has since been added and relies on broken behaviour Changes in v9: - Add comments to bootefi_test_prepare() about the memset()s Changes in v7: - Drop patch "efi: Init the 'rows' and 'cols' variables" - Drop patches previous applied Changes in v5: - Drop call to efi_init_obj_list() which is now done in do_bootefi() - Introduce load_options_path to specifyc U-Boot env var for load_options_path - Rebase to master Changes in v4: - Rebase to master Changes in v3: - Add new patch to rename bootefi_test_finish() to bootefi_run_finish() - Add new patch to split out test init/uninit into functions - Add patch to create a function to set up for running EFI code - Drop incorrect map_sysmem() in write_smbios_table() Simon Glass (4): sandbox: smbios: Update to support sandbox efi: Split out test init/uninit into functions efi: Create a function to set up for running EFI code efi: Rename bootefi_test_finish() to bootefi_run_finish() cmd/bootefi.c | 120 +++- lib/efi_loader/efi_smbios.c | 20 +++--- lib/smbios.c| 52 +--- 3 files changed, 147 insertions(+), 45 deletions(-) -- 2.19.1.1215.g8438c0b245-goog ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v14 3/4] efi: Create a function to set up for running EFI code
There is still duplicated code in efi_loader for tests and normal
operation.
Add a new bootefi_run_prepare() function which holds common code used to
set up U-Boot to run EFI code. Make use of this from the existing
bootefi_test_prepare() function, as well as do_bootefi_exec().
Also shorten a few variable names.
Signed-off-by: Simon Glass
---
Changes in v14:
- Go back to the horrible long variable names
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v9: None
Changes in v7: None
Changes in v5:
- Drop call to efi_init_obj_list() which is now done in do_bootefi()
- Introduce load_options_path to specifyc U-Boot env var for load_options_path
Changes in v4:
- Rebase to master
Changes in v3:
- Add patch to create a function to set up for running EFI code
cmd/bootefi.c | 63 ++-
1 file changed, 37 insertions(+), 26 deletions(-)
diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index b633e956c23..ab7ada9f2d6 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -325,6 +325,31 @@ static efi_status_t efi_install_fdt(ulong fdt_addr)
return ret;
}
+static efi_status_t bootefi_run_prepare(const char *load_options_path,
+ struct efi_device_path *device_path,
+ struct efi_device_path *image_path,
+ struct efi_loaded_image_obj **image_objp,
+ struct efi_loaded_image **loaded_image_infop)
+{
+ efi_status_t ret;
+
+ ret = efi_setup_loaded_image(device_path, image_path, image_objp,
+loaded_image_infop);
+ if (ret != EFI_SUCCESS)
+ return ret;
+
+ /*
+* gd lives in a fixed register which may get clobbered while we execute
+* the payload. So save it here and restore it on every callback entry
+*/
+ efi_save_gd();
+
+ /* Transfer environment variable as load options */
+ set_load_options(*loaded_image_infop, load_options_path);
+
+ return 0;
+}
+
/**
* do_bootefi_exec() - execute EFI binary
*
@@ -374,13 +399,11 @@ static efi_status_t do_bootefi_exec(void *efi,
assert(device_path && image_path);
}
- ret = efi_setup_loaded_image(device_path, image_path, _obj,
-_image_info);
- if (ret != EFI_SUCCESS)
- goto exit;
+ ret = bootefi_run_prepare("bootargs", device_path, image_path,
+ _obj, _image_info);
+ if (ret)
+ return ret;
- /* Transfer environment variable bootargs as load options */
- set_load_options(loaded_image_info, "bootargs");
/* Load the EFI payload */
entry = efi_load_pe(image_obj, efi, loaded_image_info);
if (!entry) {
@@ -468,35 +491,23 @@ exit:
* @path: File path to the test being run (often just the test name with a
*backslash before it
* @test_func: Address of the test function that is being run
+ * @load_options_path: U-Boot environment variable to use as load options
* @return 0 if OK, -ve on error
*/
static efi_status_t bootefi_test_prepare(
struct efi_loaded_image_obj **image_objp,
- struct efi_loaded_image **loaded_image_infop,
- const char *path,
- ulong test_func)
+ struct efi_loaded_image **loaded_image_infop, const char *path,
+ ulong test_func, const char *load_options_path)
{
- efi_status_t r;
-
/* Construct a dummy device path */
bootefi_device_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
(uintptr_t)test_func,
(uintptr_t)test_func);
bootefi_image_path = efi_dp_from_file(NULL, 0, path);
- r = efi_setup_loaded_image(bootefi_device_path, bootefi_image_path,
- image_objp, loaded_image_infop);
- if (r)
- return r;
- /*
-* gd lives in a fixed register which may get clobbered while we execute
-* the payload. So save it here and restore it on every callback entry
-*/
- efi_save_gd();
-
- /* Transfer environment variable efi_selftest as load options */
- set_load_options(*loaded_image_infop, "efi_selftest");
- return 0;
+ return bootefi_run_prepare(load_options_path, bootefi_device_path,
+ bootefi_image_path, image_objp,
+ loaded_image_infop);
}
/**
@@ -590,8 +601,8 @@ static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
struct efi_loaded_image *loaded_image_info;
if (bootefi_test_prepare(_obj, _image_info,
-"\\selftest",
-(uintptr_t)_selftest))
+"\\selftest",
Re: [U-Boot] arm: socfpga gen5: warm reboot reliability
On 11/14/2018 10:04 PM, Simon Goldschmidt wrote: > On 14.11.2018 21:51, Marek Vasut wrote: >> On 11/14/2018 09:30 PM, Simon Goldschmidt wrote: >>> Hi, >> Hi, >> >>> [This whole description is not qspi specific but qspi happens to be my >>> boot source. It should be the same when booting from mmc or nand.] >>> >>> On my socfgpa gen5 board, I was a little surprised that a soft reboot >>> did not start the SPL from qspi after updating it from a running Linux >>> (via swupdate writing to qspi). >>> >>> When debugging this, I found that this is because SPL and U-Boot set the >>> magic value 0xae9efebc to the sysmgr_regs->romcodegrp_warmramgrp_enable >>> register, which tells the boot ROM that it can jump to SPL in OnChip RAM >>> on next warm reboot. >>> >>> Now this is a problem for me specifically because I want to run the SPL >>> stored in qspi after updating it. I don't know if I'm the only one >>> wanting to do that, but I could implement this for my own board by just >>> resetting the magic value in the warmramgrp_enable register. >> Yes, that's Alteras' workaround for broken systems which do not connect >> SPI NOR reset and thus leave SPI NOR in undefined state (ie. 4B mode). > > I remember being somewhat shocked to see some of the SPI NOR chips don't > even have a reset input... Yep, which is sad. Those probably need some sort of switch on the Vcc, although I'd rather go for one which has a reset line. >> When the bootrom tries to load from it, it fails and the system hangs. >> >> You can do cold reset instead of warm reset to force the bootrom to >> reload the preloader from SPI NOR, it's another bit in the reset >> register. >> >>> What surprised me more is that the boot ROM provides the ability to >>> check the CRC of SPL, but it doesn't check the CRC since the related >>> registers tellt it to not do that (to enable this, SPL would have to >>> write its length + CRC to sysmgr registers). I would have suspected this >>> bad design since maybe we were rebooted by the watchdog because some >>> driver wrote bad data somewhere, so it might well be the SPL in OnChip >>> RAM is not intact any more. >> IIRC the BootROM only checks CRC of the header, no ? > > That would have been good, but from reading the documentation ([1]), it > seems to be different: it's a offset/length range that is CRC checked. > And if the 'length' register is 0, "the Boot ROM won't perform CRC > calculation and CRC check to avoid overhead caused by CRC validation." We should definitely do the CRC check, unless it has side effects :-) >>> Now should we: >>> a) calculate and set a CRC for SPL's text / rodata segments (what about >>> initialized rwdata?) or >>> b) set the warmramgrp_enable register to always load SPL from boot >>> source or >>> c) make it configurable? >> a) would be ideal, if it really is possible and works :) > > Well, for someone in the need of updating SPL and using the updated SPL, > b) would be best, but you can always just reset the magic after such an > update to ensure the updated SPL is loaded. Can't you invalidate the OCRAM (memset it to 0) and do cold-reset after such an update ? > I guess I'll try the CRC mechanism. > >> >>> Writing the code for any of the 3 choices is easy, so I wanted to get an >>> opinion first before sending a patch. Personally, I'd favour always >>> loading SPL from boot source, but the comment (in misc_gen5.c >>> arch_early_init_r()) suggests I'd break ancient kernels with that (I >>> assume the problem is the problem I have with 4.9: Linux sets qspi into >>> 4-byte mode and the boot rom can then not load SPL since it uses 3-byte >>> mode without switching mode in the qspi chip). >> You'd break broken boards some more , that's all. It has nothing to do >> with kernel version. > > I thought newer kernels use 4-byte opcodes that don't set the chip into > 4-byte mode, thus not breaking the boot ROM. That would make it > depending on the kernel version. But I haven't found the time to prove > this theory, yet. It depends on the chip. Some chips don't have dedicated 4byte opcodes. But even page program, which is interrupted in the middle of it, can cause the bootrom to fail to boot, since the SPI NOR may not respond. Worse yet, it may store some of the communication as actual data in the SPI NOR, thus corrupting the content. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 19/19] riscv: Allow U-Boot to run on hart 0 only
Hi Bin, On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > Allow U-Boot to run on hart 0 only, and suspend other harts. > > With this change, '-smp n' works on QEMU RISC-V board. > > Signed-off-by: Bin Meng > > --- > > arch/riscv/cpu/start.S | 4 > 1 file changed, 4 insertions(+) > Reviewed-by: Lukas Auer I'll try to send my patch series with multi-hart support soon, so I hope we won't need this patch for long :) > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > index 9858058..fcb0466 100644 > --- a/arch/riscv/cpu/start.S > +++ b/arch/riscv/cpu/start.S > @@ -46,6 +46,10 @@ _start: > /* mask all interrupts */ > csrwmie, zero > > + csrr t0, mhartid > + beqz t0, call_board_init_f > +1: j 1b > + To suspend the other harts, you can also add a WFI instruction before the jump instruction. Thanks, Lukas > /* > * Set stackpointer in internal/ex RAM to call board_init_f > */ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 18/19] riscv: Refactor handle_trap() a little for future extension
Hi Bin,
On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote:
> Use a variable 'code' to store the exception code to simplify the
> codes in handle_trap().
>
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/lib/interrupts.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
Reviewed-by: Lukas Auer
> diff --git a/arch/riscv/lib/interrupts.c
> b/arch/riscv/lib/interrupts.c
> index 5e09196..0c13588 100644
> --- a/arch/riscv/lib/interrupts.c
> +++ b/arch/riscv/lib/interrupts.c
> @@ -66,14 +66,18 @@ int disable_interrupts(void)
> ulong handle_trap(ulong mcause, ulong epc, struct pt_regs *regs)
> {
> ulong is_int;
> + ulong code;
>
> is_int = (mcause & MCAUSE_INT);
> - if ((is_int) && ((mcause & MCAUSE_CAUSE) == IRQ_M_EXT))
> - external_interrupt(0); /* handle_m_ext_interrupt */
> - else if ((is_int) && ((mcause & MCAUSE_CAUSE) == IRQ_M_TIMER))
> - timer_interrupt(0); /* handle_m_timer_interrupt
> */
> - else
> - _exit_trap(mcause & MCAUSE_CAUSE, epc, regs);
> + code = mcause & MCAUSE_CAUSE;
> + if (is_int) {
> + if (code == IRQ_M_EXT)
> + external_interrupt(0); /*
> handle_m_ext_interrupt */
> + else if (code == IRQ_M_TIMER)
> + timer_interrupt(0); /*
> handle_m_timer_interrupt */
> + } else {
> + _exit_trap(code, epc, regs);\
This should use mcause instead of code (see my comments on your
previous patch).
Thanks,
Lukas
> + }
>
> return epc;
> }
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] common: add board specific hook for os preboot config
I see this got superseded by fd3d1212a2cb ("bootm: Add board specific
OS preboot hook") which does the exact same thing. Thanks!
On Mon, 2018-08-13 at 09:30 +0200, Gerard Salvatella wrote:
> Some boards require specific configuration prior to booting the
> kernel.
> For instance, our boards require shutting down the display to avoid
> fading transitions before the drivers are reloaded by the kernel.
> This
> could be facilitated by adding an extra hook during the os booting
> process.
>
> Signed-off-by: Gerard Salvatella
> ---
> common/bootm_os.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/common/bootm_os.c b/common/bootm_os.c
> index f4bd905909..1e7af56b64 100644
> --- a/common/bootm_os.c
> +++ b/common/bootm_os.c
> @@ -505,9 +505,16 @@ __weak void arch_preboot_os(void)
> /* please define platform specific arch_preboot_os() */
> }
>
> +/* Allow for board specific config before we boot */
> +__weak void board_preboot_os(void)
> +{
> + /* please define board specific board_preboot_os() */
> +}
> +
> int boot_selected_os(int argc, char * const argv[], int state,
> bootm_headers_t *images, boot_os_fn *boot_fn)
> {
> + board_preboot_os();
> arch_preboot_os();
> boot_fn(state, argc, argv, images);
>
> --
> 2.18.0
>
>
> [Toradex Logo] Global Leader in Arm
> Embedded Computer Modules
>
> Choose Us dule-partner> | Products |
> Developer Center: radex.com/events>
> - Linux Developer Conference, Brazil, Aug 25-26, 2018
> - NXP Technology Days 2018, United States, Aug 28, 2018
> - IoT Latin America, Brazil, Aug 29-30, 2018
>
>
> ___
> 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 17/19] riscv: Pass correct exception code to _exit_trap()
Hi Bin, On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > The most significant bit in mcause register should be masked to > form the exception code for _exit_trap(). > > Signed-off-by: Bin Meng > --- > > arch/riscv/lib/interrupts.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/riscv/lib/interrupts.c > b/arch/riscv/lib/interrupts.c > index c568706..5e09196 100644 > --- a/arch/riscv/lib/interrupts.c > +++ b/arch/riscv/lib/interrupts.c > @@ -73,7 +73,7 @@ ulong handle_trap(ulong mcause, ulong epc, struct > pt_regs *regs) > else if ((is_int) && ((mcause & MCAUSE_CAUSE) == IRQ_M_TIMER)) > timer_interrupt(0); /* handle_m_timer_interrupt > */ > else > - _exit_trap(mcause, epc, regs); > + _exit_trap(mcause & MCAUSE_CAUSE, epc, regs); The exception codes differ between traps caused by an interrupt (MSB set) and those that are not. Besides software interrupts, the handle_trap already checks for all possible machine-mode interrupts. Thanks, Lukas > > return epc; > } ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: toradex: turn off lcd backlight before OS handover
On Fri, 2018-10-26 at 14:29 +0200, Philippe Schenker wrote:
> From: Gerard Salvatella
>
> U-Boot typically tears down the display controller before handing
> control over to Linux. On LCD displays disabling pixel clock leads to
> a
> fading out effect with vertical/horizontal lines. Make sure to
> disable
> back light before booting Linux.
>
> Signed-off-by: Gerard Salvatella
> Signed-off-by: Philippe Schenker
Acked-by: Marcel Ziswiler
> ---
> board/toradex/apalis-tk1/apalis-tk1.c | 9 +
> board/toradex/apalis_imx6/apalis_imx6.c | 9 +
> board/toradex/apalis_t30/apalis_t30.c | 9 +
> board/toradex/colibri_imx6/colibri_imx6.c | 9 +
> board/toradex/colibri_imx7/colibri_imx7.c | 9 +
> board/toradex/colibri_t20/colibri_t20.c | 9 +
> board/toradex/colibri_t30/colibri_t30.c | 9 +
> board/toradex/colibri_vf/colibri_vf.c | 12 +++-
> 8 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/board/toradex/apalis-tk1/apalis-tk1.c
> b/board/toradex/apalis-tk1/apalis-tk1.c
> index d6a736d8aa..b87e9e7a3e 100644
> --- a/board/toradex/apalis-tk1/apalis-tk1.c
> +++ b/board/toradex/apalis-tk1/apalis-tk1.c
> @@ -240,3 +240,12 @@ void tegra_pcie_board_port_reset(struct
> tegra_pcie_port *port)
> }
> }
> #endif /* CONFIG_PCI_TEGRA */
> +
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_request(TEGRA_GPIO(BB, 5), "BL_ON");
> + gpio_direction_output(TEGRA_GPIO(BB, 5), 0);
> +}
> diff --git a/board/toradex/apalis_imx6/apalis_imx6.c
> b/board/toradex/apalis_imx6/apalis_imx6.c
> index 368db9c488..d11207c7f4 100644
> --- a/board/toradex/apalis_imx6/apalis_imx6.c
> +++ b/board/toradex/apalis_imx6/apalis_imx6.c
> @@ -745,6 +745,15 @@ static void setup_display(void)
> gpio_direction_output(RGB_BACKLIGHTPWM_OE, 0);
> gpio_direction_output(RGB_BACKLIGHT_GP, 1);
> }
> +
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_direction_output(RGB_BACKLIGHTPWM_GP, 1);
> + gpio_direction_output(RGB_BACKLIGHT_GP, 0);
> +}
> #endif /* defined(CONFIG_VIDEO_IPUV3) */
>
> int board_early_init_f(void)
> diff --git a/board/toradex/apalis_t30/apalis_t30.c
> b/board/toradex/apalis_t30/apalis_t30.c
> index ace9c5b168..df9bc8e707 100644
> --- a/board/toradex/apalis_t30/apalis_t30.c
> +++ b/board/toradex/apalis_t30/apalis_t30.c
> @@ -164,3 +164,12 @@ void tegra_pcie_board_port_reset(struct
> tegra_pcie_port *port)
> #endif /* CONFIG_APALIS_T30_PCIE_EVALBOARD_INIT */
> }
> #endif /* CONFIG_PCI_TEGRA */
> +
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_request(TEGRA_GPIO(V, 2), "BKL1_ON");
> + gpio_direction_output(TEGRA_GPIO(V, 2), 0);
> +}
> diff --git a/board/toradex/colibri_imx6/colibri_imx6.c
> b/board/toradex/colibri_imx6/colibri_imx6.c
> index 68c0c02a8a..17876f27e9 100644
> --- a/board/toradex/colibri_imx6/colibri_imx6.c
> +++ b/board/toradex/colibri_imx6/colibri_imx6.c
> @@ -622,6 +622,15 @@ static void setup_display(void)
> gpio_direction_output(RGB_BACKLIGHTPWM_GP, 0);
> gpio_direction_output(RGB_BACKLIGHT_GP, 1);
> }
> +
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_direction_output(RGB_BACKLIGHTPWM_GP, 1);
> + gpio_direction_output(RGB_BACKLIGHT_GP, 0);
> +}
> #endif /* defined(CONFIG_VIDEO_IPUV3) */
>
> int board_early_init_f(void)
> diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
> b/board/toradex/colibri_imx7/colibri_imx7.c
> index a4c99626b4..be027afd10 100644
> --- a/board/toradex/colibri_imx7/colibri_imx7.c
> +++ b/board/toradex/colibri_imx7/colibri_imx7.c
> @@ -182,6 +182,15 @@ static int setup_lcd(void)
> }
> #endif
>
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_direction_output(GPIO_PWM_A, 1);
> + gpio_direction_output(GPIO_BL_ON, 0);
> +}
> +
> #ifdef CONFIG_FEC_MXC
> static iomux_v3_cfg_t const fec1_pads[] = {
> #ifndef CONFIG_COLIBRI_IMX7_EXT_PHYCLK
> diff --git a/board/toradex/colibri_t20/colibri_t20.c
> b/board/toradex/colibri_t20/colibri_t20.c
> index 5dd0f288ed..e0b27e92f8 100644
> --- a/board/toradex/colibri_t20/colibri_t20.c
> +++ b/board/toradex/colibri_t20/colibri_t20.c
> @@ -150,4 +150,13 @@ void pin_mux_display(void)
> pinmux_set_func(PMUX_PINGRP_SDC, PMUX_FUNC_PWM);
> pinmux_tristate_disable(PMUX_PINGRP_SDC);
> }
> +
> +/*
> + * Backlight off before OS handover
> + */
> +void board_preboot_os(void)
> +{
> + gpio_request(TEGRA_GPIO(T, 4), "BL_ON");
> + gpio_direction_output(TEGRA_GPIO(T, 4), 0);
> +}
> #endif
> diff --git a/board/toradex/colibri_t30/colibri_t30.c
> b/board/toradex/colibri_t30/colibri_t30.c
> index 8ea96188f6..b6b00e3860 100644
> --- a/board/toradex/colibri_t30/colibri_t30.c
> +++ b/board/toradex/colibri_t30/colibri_t30.c
> @@ -66,3
Re: [U-Boot] [PATCH 16/19] riscv: Adjust the _exit_trap() position to come before handle_trap()
On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > With this change, we can avoid a forward declaration. > > Signed-off-by: Bin Meng > --- > > arch/riscv/lib/interrupts.c | 62 ++- > -- > 1 file changed, 30 insertions(+), 32 deletions(-) > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 15/19] riscv: Return to previous privilege level after trap handling
On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > At present the trap handler returns to M-mode only. Change to > returning to previous privilege level instead. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/mtrap.S | 3 --- > 1 file changed, 3 deletions(-) > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 14/19] riscv: Fix context restore before returning from trap handler
On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > sp cannot be loaded before restoring other registers. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/mtrap.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Lukas Auer Good catch! > diff --git a/arch/riscv/cpu/mtrap.S b/arch/riscv/cpu/mtrap.S > index ba6462f..6c0eac6 100644 > --- a/arch/riscv/cpu/mtrap.S > +++ b/arch/riscv/cpu/mtrap.S > @@ -72,7 +72,6 @@ trap_entry: > li t0, MSTATUS_MPP > csrs mstatus, t0 > LREG x1, 1 * REGBYTES(sp) > - LREG x2, 2 * REGBYTES(sp) > LREG x3, 3 * REGBYTES(sp) > LREG x4, 4 * REGBYTES(sp) > LREG x5, 5 * REGBYTES(sp) > @@ -102,5 +101,6 @@ trap_entry: > LREG x29, 29 * REGBYTES(sp) > LREG x30, 30 * REGBYTES(sp) > LREG x31, 31 * REGBYTES(sp) > + LREG x2, 2 * REGBYTES(sp) > addi sp, sp, 32 * REGBYTES > mret ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/19] riscv: Move trap handler codes to mtrap.S
On Tue, 2018-11-13 at 00:22 -0800, Bin Meng wrote: > Currently the M-mode trap handler codes are in start.S. For future > extension, move them to a separate file mtrap.S. > > Signed-off-by: Bin Meng > --- > > arch/riscv/cpu/Makefile | 2 +- > arch/riscv/cpu/mtrap.S | 106 > > arch/riscv/cpu/start.S | 82 - > 3 files changed, 107 insertions(+), 83 deletions(-) > create mode 100644 arch/riscv/cpu/mtrap.S > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/19] riscv: Add CSR numbers
Hi Bin, On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote: > The standard RISC-V ISA sets aside a 12-bit encoding space for up > to 4096 CSRs. This adds all known CSR numbers as defined in the > RISC-V Privileged Architecture Version 1.10. > > Signed-off-by: Bin Meng > --- > > arch/riscv/include/asm/encoding.h | 219 > ++ > 1 file changed, 219 insertions(+) > What is the reason for adding these and also the exception code definitions in the next patch? Thanks, Lukas > diff --git a/arch/riscv/include/asm/encoding.h > b/arch/riscv/include/asm/encoding.h > index 9ea50ce..0c47c53 100644 > --- a/arch/riscv/include/asm/encoding.h > +++ b/arch/riscv/include/asm/encoding.h > @@ -146,6 +146,225 @@ > #define RISCV_PGSHIFT 12 > #define RISCV_PGSIZE BIT(RISCV_PGSHIFT) > > +/* CSR numbers */ > +#define CSR_FFLAGS 0x1 > +#define CSR_FRM 0x2 > +#define CSR_FCSR 0x3 > + > +#define CSR_SSTATUS 0x100 > +#define CSR_SIE 0x104 > +#define CSR_STVEC0x105 > +#define CSR_SCOUNTEREN 0x106 > +#define CSR_SSCRATCH 0x140 > +#define CSR_SEPC 0x141 > +#define CSR_SCAUSE 0x142 > +#define CSR_STVAL0x143 > +#define CSR_SIP 0x144 > +#define CSR_SATP 0x180 > + > +#define CSR_MSTATUS 0x300 > +#define CSR_MISA 0x301 > +#define CSR_MEDELEG 0x302 > +#define CSR_MIDELEG 0x303 > +#define CSR_MIE 0x304 > +#define CSR_MTVEC0x305 > +#define CSR_MCOUNTEREN 0x306 > +#define CSR_MHPMEVENT3 0x323 > +#define CSR_MHPMEVENT4 0x324 > +#define CSR_MHPMEVENT5 0x325 > +#define CSR_MHPMEVENT6 0x326 > +#define CSR_MHPMEVENT7 0x327 > +#define CSR_MHPMEVENT8 0x328 > +#define CSR_MHPMEVENT9 0x329 > +#define CSR_MHPMEVENT10 0x32a > +#define CSR_MHPMEVENT11 0x32b > +#define CSR_MHPMEVENT12 0x32c > +#define CSR_MHPMEVENT13 0x32d > +#define CSR_MHPMEVENT14 0x32e > +#define CSR_MHPMEVENT15 0x32f > +#define CSR_MHPMEVENT16 0x330 > +#define CSR_MHPMEVENT17 0x331 > +#define CSR_MHPMEVENT18 0x332 > +#define CSR_MHPMEVENT19 0x333 > +#define CSR_MHPMEVENT20 0x334 > +#define CSR_MHPMEVENT21 0x335 > +#define CSR_MHPMEVENT22 0x336 > +#define CSR_MHPMEVENT23 0x337 > +#define CSR_MHPMEVENT24 0x338 > +#define CSR_MHPMEVENT25 0x339 > +#define CSR_MHPMEVENT26 0x33a > +#define CSR_MHPMEVENT27 0x33b > +#define CSR_MHPMEVENT28 0x33c > +#define CSR_MHPMEVENT29 0x33d > +#define CSR_MHPMEVENT30 0x33e > +#define CSR_MHPMEVENT31 0x33f > +#define CSR_MSCRATCH 0x340 > +#define CSR_MEPC 0x341 > +#define CSR_MCAUSE 0x342 > +#define CSR_MTVAL0x343 > +#define CSR_MIP 0x344 > +#define CSR_PMPCFG0 0x3a0 > +#define CSR_PMPCFG1 0x3a1 > +#define CSR_PMPCFG2 0x3a2 > +#define CSR_PMPCFG3 0x3a3 > +#define CSR_PMPADDR0 0x3b0 > +#define CSR_PMPADDR1 0x3b1 > +#define CSR_PMPADDR2 0x3b2 > +#define CSR_PMPADDR3 0x3b3 > +#define CSR_PMPADDR4 0x3b4 > +#define CSR_PMPADDR5 0x3b5 > +#define CSR_PMPADDR6 0x3b6 > +#define CSR_PMPADDR7 0x3b7 > +#define CSR_PMPADDR8 0x3b8 > +#define CSR_PMPADDR9 0x3b9 > +#define CSR_PMPADDR100x3ba > +#define CSR_PMPADDR110x3bb > +#define CSR_PMPADDR120x3bc > +#define CSR_PMPADDR130x3bd > +#define CSR_PMPADDR140x3be > +#define CSR_PMPADDR150x3bf > + > +#define CSR_TSELECT 0x7a0 > +#define CSR_TDATA1 0x7a1 > +#define CSR_TDATA2 0x7a2 > +#define CSR_TDATA3 0x7a3 > +#define CSR_DCSR 0x7b0 > +#define CSR_DPC 0x7b1 > +#define CSR_DSCRATCH 0x7b2 > + > +#define CSR_MCYCLE 0xb00 > +#define CSR_MINSTRET 0xb02 > +#define CSR_MHPMCOUNTER3 0xb03 > +#define CSR_MHPMCOUNTER4 0xb04 > +#define CSR_MHPMCOUNTER5 0xb05 > +#define CSR_MHPMCOUNTER6 0xb06 > +#define CSR_MHPMCOUNTER7 0xb07 > +#define CSR_MHPMCOUNTER8 0xb08 > +#define CSR_MHPMCOUNTER9 0xb09 > +#define CSR_MHPMCOUNTER100xb0a > +#define CSR_MHPMCOUNTER110xb0b > +#define CSR_MHPMCOUNTER120xb0c > +#define CSR_MHPMCOUNTER130xb0d > +#define CSR_MHPMCOUNTER140xb0e > +#define CSR_MHPMCOUNTER150xb0f > +#define CSR_MHPMCOUNTER160xb10 > +#define CSR_MHPMCOUNTER170xb11 > +#define CSR_MHPMCOUNTER180xb12 > +#define CSR_MHPMCOUNTER190xb13 >
Re: [U-Boot] [PATCH 09/19] riscv: qemu: Probe cpus during boot
Hi Bin,
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> This calls cpu_probe_all() to probe all available cpus.
>
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/cpu/qemu/Kconfig | 1 +
> arch/riscv/cpu/qemu/cpu.c | 14 ++
> 2 files changed, 15 insertions(+)
>
Reviewed-by: Lukas Auer
This could also go into the generic cpu/cpu.c, what do you think?
> diff --git a/arch/riscv/cpu/qemu/Kconfig
> b/arch/riscv/cpu/qemu/Kconfig
> index ec5d934..e91cff5 100644
> --- a/arch/riscv/cpu/qemu/Kconfig
> +++ b/arch/riscv/cpu/qemu/Kconfig
> @@ -4,6 +4,7 @@
>
> config QEMU_RISCV
> bool
> + select ARCH_EARLY_INIT_R
> imply CPU
> imply CPU_RISCV
> imply RISCV_TIMER
> diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/qemu/cpu.c
> index 221f3a8..e98f624 100644
> --- a/arch/riscv/cpu/qemu/cpu.c
> +++ b/arch/riscv/cpu/qemu/cpu.c
> @@ -4,7 +4,9 @@
> */
>
> #include
> +#include
> #include
> +#include
>
> /*
> * cleanup_before_linux() is called just before we call linux
> @@ -21,6 +23,18 @@ int cleanup_before_linux(void)
> return 0;
> }
>
> +int arch_early_init_r(void)
> +{
> + int ret;
> +
> + /* probe cpus so that risc-v timer can be bound */
> + ret = cpu_probe_all();
> + if (ret)
> + return log_msg_ret("risc-v cpus probe fails\n", ret);
nit: RISC-V (here and in the comment above), failed instead of fails
Thanks,
Lukas
> +
> + return 0;
> +}
> +
> /* To enumerate devices on the /soc/ node, create a "simple-bus"
> driver */
> static const struct udevice_id riscv_virtio_soc_ids[] = {
> { .compatible = "riscv-virtio-soc" },
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/19] riscv: Enlarge the default SYS_MALLOC_F_LEN
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote: > Increase the heap size for the pre-relocation stage, so that CPU > driver can be loaded. > > Signed-off-by: Bin Meng > --- > > arch/riscv/Kconfig | 3 +++ > 1 file changed, 3 insertions(+) > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/19] riscv: kconfig: Allow platform to specify Kconfig options
Hi Bin, On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote: > At present there are just two levels of Kconfig option hierarchy in > RISC-V. This adds a new level for platform to specify additional > options. It is organized in a way that platform-specific options > followed by board-specific ones, so that when it comes to the same > Kconfig option, board-specific one takes take the highest precedence, nit: you have an extra take here > then platform-specific one, and finally architecture-specific one. > > As an example, add the QEMU RISC-V platform-specific Kconfig options. > > Signed-off-by: Bin Meng > --- > > arch/riscv/Kconfig | 6 ++ > arch/riscv/cpu/qemu/Kconfig| 9 + > board/emulation/qemu-riscv/Kconfig | 1 + > 3 files changed, 16 insertions(+) > create mode 100644 arch/riscv/cpu/qemu/Kconfig > Reviewed-by: Lukas Auer ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/19] cpu: Add a RISC-V CPU driver
Hi Bin,
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> This adds a driver for RISC-V CPU. Note the driver will bind
> a RISC-V timer driver if "timebase-frequency" property is
> present in the device tree.
>
> Signed-off-by: Bin Meng
> ---
>
Since we have the CPU driver, we could also enable CMD_CPU.
> drivers/cpu/Kconfig | 6 +++
> drivers/cpu/Makefile| 1 +
> drivers/cpu/riscv_cpu.c | 117
>
> 3 files changed, 124 insertions(+)
> create mode 100644 drivers/cpu/riscv_cpu.c
>
> diff --git a/drivers/cpu/Kconfig b/drivers/cpu/Kconfig
> index d405200..3d5729f 100644
> --- a/drivers/cpu/Kconfig
> +++ b/drivers/cpu/Kconfig
> @@ -13,3 +13,9 @@ config CPU_MPC83XX
> select CLK_MPC83XX
> help
> Support CPU cores for SoCs of the MPC83xx series.
> +
> +config CPU_RISCV
> + bool "Enable RISC-V CPU driver"
> + depends on CPU && RISCV
> + help
> + Support CPU cores for RISC-V architecture.
> diff --git a/drivers/cpu/Makefile b/drivers/cpu/Makefile
> index 858b037..be0300c 100644
> --- a/drivers/cpu/Makefile
> +++ b/drivers/cpu/Makefile
> @@ -8,4 +8,5 @@ obj-$(CONFIG_CPU) += cpu-uclass.o
>
> obj-$(CONFIG_ARCH_BMIPS) += bmips_cpu.o
> obj-$(CONFIG_CPU_MPC83XX) += mpc83xx_cpu.o
> +obj-$(CONFIG_CPU_RISCV) += riscv_cpu.o
> obj-$(CONFIG_SANDBOX) += cpu_sandbox.o
> diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
> new file mode 100644
> index 000..23917db
> --- /dev/null
> +++ b/drivers/cpu/riscv_cpu.c
> @@ -0,0 +1,117 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018, Bin Meng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int riscv_cpu_get_desc(struct udevice *dev, char *buf, int
> size)
> +{
> + const char *isa;
> +
> + isa = dev_read_string(dev, "riscv,isa");
> + if (size < (strlen(isa) + 1))
> + return -ENOSPC;
> +
> + strcpy(buf, isa);
> +
> + return 0;
> +}
> +
> +static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info
> *info)
> +{
> + const char *mmu;
> +
> + dev_read_u32(dev, "clock-frequency", (u32 *)>cpu_freq);
> +
> + mmu = dev_read_string(dev, "mmu-type");
> + if (!mmu)
> + info->features |= BIT(CPU_FEAT_MMU);
> +
BBL also disables CPUs without an MMU, so it is good to have this
information. Where would you disable the CPU in U-Boot? Maybe in
arch_fixup_fdt() or in the CPU driver?
> + return 0;
> +}
> +
> +static int riscv_cpu_get_count(struct udevice *dev)
> +{
> + ofnode node;
> + int num = 0;
> +
> + ofnode_for_each_subnode(node, dev_ofnode(dev->parent)) {
> + const char *device_type;
> +
> + device_type = ofnode_read_string(node, "device_type");
> + if (!device_type)
> + continue;
> + if (strcmp(device_type, "cpu") == 0)
> + num++;
> + }
> +
> + return num;
> +}
> +
> +static int riscv_cpu_bind(struct udevice *dev)
> +{
> + struct cpu_platdata *plat = dev_get_parent_platdata(dev);
> + struct driver *drv;
> + struct udevice *timer;
> + int ret;
> +
> + /* save the hart id */
> + plat->cpu_id = dev_read_addr(dev);
> +
> + /* first examine the property in current cpu node */
> + ret = dev_read_u32(dev, "timebase-frequency",
> >timebase_freq);
> + /* if not found, then look at the parent /cpus node */
> + if (ret)
> + dev_read_u32(dev->parent, "timebase-frequency",
> + >timebase_freq);
> +
> + /*
> + * Bind riscv-timer driver on hart 0
> + *
> + * We only instantiate one timer device which is enough for U-
> Boot.
> + * Pass the "timebase-frequency" value as the driver data for
> the
> + * timer device.
> + *
> + * Return value is not checked since it's possible that the
> timer
> + * driver is not included.
> + */
> + if (!plat->cpu_id && plat->timebase_freq) {
> + drv = lists_driver_lookup_name("riscv_timer");
> + if (!drv) {
> + debug("Cannot find the timer driver, not
> included?\n");
> + return 0;
> + }
> +
> + device_bind_with_driver_data(dev, drv, "riscv_timer",
> + plat->timebase_freq,
> ofnode_null(),
> + );
You don't need the timer variable here, you can just pass NULL.
I did not see that you are not checking the return value here, when I
wrote my previous email regarding the syscon driver. So it is not
actually a problem if two different device implement the functionality
for the syscon APIs. I think it is still worth considering to implement
something like the misc driver I suggested, however.
Thanks,
Lukas
> + }
> +
> + return 0;
> +}
> +
> +static const struct cpu_ops riscv_cpu_ops = {
> +
Re: [U-Boot] [PATCH 03/19] riscv: qemu: Create a simple-bus driver for the soc node
Hi Bin,
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> To enumerate devices on the /soc/ node, create a "simple-bus"
> driver to match "riscv-virtio-soc".
>
> Signed-off-by: Bin Meng
> ---
>
> arch/riscv/cpu/qemu/cpu.c | 13 +
> 1 file changed, 13 insertions(+)
>
Reviewed-by: Lukas Auer
Would it makes sense to move this to cpu/ to make this driver available
to all RISC-V CPUs? I think most CPUs will need this driver to make
devices under the soc/ node available before relocation.
> diff --git a/arch/riscv/cpu/qemu/cpu.c b/arch/riscv/cpu/qemu/cpu.c
> index 6c7a327..221f3a8 100644
> --- a/arch/riscv/cpu/qemu/cpu.c
> +++ b/arch/riscv/cpu/qemu/cpu.c
> @@ -4,6 +4,7 @@
> */
>
> #include
> +#include
>
> /*
> * cleanup_before_linux() is called just before we call linux
> @@ -19,3 +20,15 @@ int cleanup_before_linux(void)
>
> return 0;
> }
> +
> +/* To enumerate devices on the /soc/ node, create a "simple-bus"
> driver */
> +static const struct udevice_id riscv_virtio_soc_ids[] = {
> + { .compatible = "riscv-virtio-soc" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(riscv_virtio_soc) = {
> + .name = "riscv_virtio_soc",
> + .id = UCLASS_SIMPLE_BUS,
> + .of_match = riscv_virtio_soc_ids,
> +};
I think the DM_FLAG_PRE_RELOC flag should be set, since it is set for
the syscon driver for the clint0.
Thanks,
Lukas
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/19] dm: cpu: Add timebase frequency to the platdata
Hi Bin,
On Tue, 2018-11-13 at 00:21 -0800, Bin Meng wrote:
> This adds a timebase_freq member to the 'struct cpu_platdata', to
> hold the "timebase-frequency" value in the cpu or /cpus node.
>
> Signed-off-by: Bin Meng
> ---
>
> include/cpu.h | 3 +++
> 1 file changed, 3 insertions(+)
>
Reviewed-by: Lukas Auer
> diff --git a/include/cpu.h b/include/cpu.h
> index 367c5f4..176a276 100644
> --- a/include/cpu.h
> +++ b/include/cpu.h
> @@ -14,6 +14,8 @@
> * @device_id: Driver-defined device identifier
> * @family:DMTF CPU Family identifier
> * @id:DMTF CPU Processor identifier
> + * @timebase_freq: the current frequency at which the cpu timer
> timebase
> + * registers are updated (in HZ)
nit: Hz
Thanks,
Lukas
> *
> * This can be accessed with dev_get_parent_platdata() for any
> UCLASS_CPU
> * device.
> @@ -24,6 +26,7 @@ struct cpu_platdata {
> ulong device_id;
> u16 family;
> u32 id[2];
> + u32 timebase_freq;
> };
>
> /* CPU features - mostly just a placeholder for now */
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga gen5: warm reboot reliability
On 14.11.2018 21:51, Marek Vasut wrote: On 11/14/2018 09:30 PM, Simon Goldschmidt wrote: Hi, Hi, [This whole description is not qspi specific but qspi happens to be my boot source. It should be the same when booting from mmc or nand.] On my socfgpa gen5 board, I was a little surprised that a soft reboot did not start the SPL from qspi after updating it from a running Linux (via swupdate writing to qspi). When debugging this, I found that this is because SPL and U-Boot set the magic value 0xae9efebc to the sysmgr_regs->romcodegrp_warmramgrp_enable register, which tells the boot ROM that it can jump to SPL in OnChip RAM on next warm reboot. Now this is a problem for me specifically because I want to run the SPL stored in qspi after updating it. I don't know if I'm the only one wanting to do that, but I could implement this for my own board by just resetting the magic value in the warmramgrp_enable register. Yes, that's Alteras' workaround for broken systems which do not connect SPI NOR reset and thus leave SPI NOR in undefined state (ie. 4B mode). I remember being somewhat shocked to see some of the SPI NOR chips don't even have a reset input... When the bootrom tries to load from it, it fails and the system hangs. You can do cold reset instead of warm reset to force the bootrom to reload the preloader from SPI NOR, it's another bit in the reset register. What surprised me more is that the boot ROM provides the ability to check the CRC of SPL, but it doesn't check the CRC since the related registers tellt it to not do that (to enable this, SPL would have to write its length + CRC to sysmgr registers). I would have suspected this bad design since maybe we were rebooted by the watchdog because some driver wrote bad data somewhere, so it might well be the SPL in OnChip RAM is not intact any more. IIRC the BootROM only checks CRC of the header, no ? That would have been good, but from reading the documentation ([1]), it seems to be different: it's a offset/length range that is CRC checked. And if the 'length' register is 0, "the Boot ROM won't perform CRC calculation and CRC check to avoid overhead caused by CRC validation." Now should we: a) calculate and set a CRC for SPL's text / rodata segments (what about initialized rwdata?) or b) set the warmramgrp_enable register to always load SPL from boot source or c) make it configurable? a) would be ideal, if it really is possible and works :) Well, for someone in the need of updating SPL and using the updated SPL, b) would be best, but you can always just reset the magic after such an update to ensure the updated SPL is loaded. I guess I'll try the CRC mechanism. Writing the code for any of the 3 choices is easy, so I wanted to get an opinion first before sending a patch. Personally, I'd favour always loading SPL from boot source, but the comment (in misc_gen5.c arch_early_init_r()) suggests I'd break ancient kernels with that (I assume the problem is the problem I have with 4.9: Linux sets qspi into 4-byte mode and the boot rom can then not load SPL since it uses 3-byte mode without switching mode in the qspi chip). You'd break broken boards some more , that's all. It has nothing to do with kernel version. I thought newer kernels use 4-byte opcodes that don't set the chip into 4-byte mode, thus not breaking the boot ROM. That would make it depending on the kernel version. But I haven't found the time to prove this theory, yet. Simon [1] https://www.intel.com/content/www/us/en/programmable/hps/cyclone-v/hps.html -> sysmgr -> Warm Boot from On-Chip RAM Group ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] arm: socfpga gen5: warm reboot reliability
On 11/14/2018 09:30 PM, Simon Goldschmidt wrote: > Hi, Hi, > [This whole description is not qspi specific but qspi happens to be my > boot source. It should be the same when booting from mmc or nand.] > > On my socfgpa gen5 board, I was a little surprised that a soft reboot > did not start the SPL from qspi after updating it from a running Linux > (via swupdate writing to qspi). > > When debugging this, I found that this is because SPL and U-Boot set the > magic value 0xae9efebc to the sysmgr_regs->romcodegrp_warmramgrp_enable > register, which tells the boot ROM that it can jump to SPL in OnChip RAM > on next warm reboot. > > Now this is a problem for me specifically because I want to run the SPL > stored in qspi after updating it. I don't know if I'm the only one > wanting to do that, but I could implement this for my own board by just > resetting the magic value in the warmramgrp_enable register. Yes, that's Alteras' workaround for broken systems which do not connect SPI NOR reset and thus leave SPI NOR in undefined state (ie. 4B mode). When the bootrom tries to load from it, it fails and the system hangs. You can do cold reset instead of warm reset to force the bootrom to reload the preloader from SPI NOR, it's another bit in the reset register. > What surprised me more is that the boot ROM provides the ability to > check the CRC of SPL, but it doesn't check the CRC since the related > registers tellt it to not do that (to enable this, SPL would have to > write its length + CRC to sysmgr registers). I would have suspected this > bad design since maybe we were rebooted by the watchdog because some > driver wrote bad data somewhere, so it might well be the SPL in OnChip > RAM is not intact any more. IIRC the BootROM only checks CRC of the header, no ? > Now should we: > a) calculate and set a CRC for SPL's text / rodata segments (what about > initialized rwdata?) or > b) set the warmramgrp_enable register to always load SPL from boot > source or > c) make it configurable? a) would be ideal, if it really is possible and works :) > Writing the code for any of the 3 choices is easy, so I wanted to get an > opinion first before sending a patch. Personally, I'd favour always > loading SPL from boot source, but the comment (in misc_gen5.c > arch_early_init_r()) suggests I'd break ancient kernels with that (I > assume the problem is the problem I have with 4.9: Linux sets qspi into > 4-byte mode and the boot rom can then not load SPL since it uses 3-byte > mode without switching mode in the qspi chip). You'd break broken boards some more , that's all. It has nothing to do with kernel version. > Any thoughts? > > Simon -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/2] rockchip: rk3188: fix early uart setup
> Commit 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions
> into pinctrl-driver") moved the iomux settings out of the grf header
> to prevent conflicts with the iomux definitions of other rockchip socs.
>
> This also breaks the early uart setup, as the iomux for uart2 are needed.
> To fix that just put the tiny amount of needed iomux definitions next to
> the early uart code.
>
> Fixes: 7a6d7d3e1279 ("rockchip: pinctrl: rk3188: Move the iomux definitions
> into pinctrl-driver")
> Signed-off-by: Heiko Stuebner
> ---
> arch/arm/mach-rockchip/rk3188-board-spl.c | 10 ++
> 1 file changed, 10 insertions(+)
>
Reviewed-by: Philipp Tomsich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] rockchip: rk3188: add support for usb-uart functionality
> Rockchip socs can route the debug uart pins through the d+ and d- pins > of one specific usbphy per soc. Add a config option and implement the > setting on the rk3188. > > Signed-off-by: Heiko Stuebner > --- > .../include/asm/arch-rockchip/grf_rk3188.h| 42 +++ > arch/arm/mach-rockchip/Kconfig| 8 > arch/arm/mach-rockchip/rk3188-board-spl.c | 27 ++-- > 3 files changed, 73 insertions(+), 4 deletions(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rockchip: video: mipi: Do not write to the version register
> There was a copy and paste error where the data > enable setting was written to the version register. > > Signed-off-by: Richard Röjfors > --- > drivers/video/rockchip/rk_mipi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Philipp Tomsich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] arm: socfpga gen5: warm reboot reliability
Hi, [This whole description is not qspi specific but qspi happens to be my boot source. It should be the same when booting from mmc or nand.] On my socfgpa gen5 board, I was a little surprised that a soft reboot did not start the SPL from qspi after updating it from a running Linux (via swupdate writing to qspi). When debugging this, I found that this is because SPL and U-Boot set the magic value 0xae9efebc to the sysmgr_regs->romcodegrp_warmramgrp_enable register, which tells the boot ROM that it can jump to SPL in OnChip RAM on next warm reboot. Now this is a problem for me specifically because I want to run the SPL stored in qspi after updating it. I don't know if I'm the only one wanting to do that, but I could implement this for my own board by just resetting the magic value in the warmramgrp_enable register. What surprised me more is that the boot ROM provides the ability to check the CRC of SPL, but it doesn't check the CRC since the related registers tellt it to not do that (to enable this, SPL would have to write its length + CRC to sysmgr registers). I would have suspected this bad design since maybe we were rebooted by the watchdog because some driver wrote bad data somewhere, so it might well be the SPL in OnChip RAM is not intact any more. Now should we: a) calculate and set a CRC for SPL's text / rodata segments (what about initialized rwdata?) or b) set the warmramgrp_enable register to always load SPL from boot source or c) make it configurable? Writing the code for any of the 3 choices is easy, so I wanted to get an opinion first before sending a patch. Personally, I'd favour always loading SPL from boot source, but the comment (in misc_gen5.c arch_early_init_r()) suggests I'd break ancient kernels with that (I assume the problem is the problem I have with 4.9: Linux sets qspi into 4-byte mode and the boot rom can then not load SPL since it uses 3-byte mode without switching mode in the qspi chip). Any thoughts? Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make config structs const
On 11/14/2018 09:05 PM, Simon Goldschmidt wrote:
> There are two config structs left in wrap_sdram_config.c that can
> be made const.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> arch/arm/mach-socfpga/wrap_sdram_config.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-socfpga/wrap_sdram_config.c
> b/arch/arm/mach-socfpga/wrap_sdram_config.c
> index 8cfacc7a13..2b072cc65e 100644
> --- a/arch/arm/mach-socfpga/wrap_sdram_config.c
> +++ b/arch/arm/mach-socfpga/wrap_sdram_config.c
> @@ -251,7 +251,7 @@ static const struct socfpga_sdram_rw_mgr_config
> rw_mgr_config = {
> RW_MGR_MEM_VIRTUAL_GROUPS_PER_WRITE_DQS,
> };
>
> -struct socfpga_sdram_io_config io_config = {
> +static const struct socfpga_sdram_io_config io_config = {
> .delay_per_dchain_tap = IO_DELAY_PER_DCHAIN_TAP,
> .delay_per_dqs_en_dchain_tap= IO_DELAY_PER_DQS_EN_DCHAIN_TAP,
> .delay_per_opa_tap = IO_DELAY_PER_OPA_TAP,
> @@ -269,7 +269,7 @@ struct socfpga_sdram_io_config io_config = {
> .shift_dqs_en_when_shift_dqs= IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS,
> };
>
> -struct socfpga_sdram_misc_config misc_config = {
> +static const struct socfpga_sdram_misc_config misc_config = {
> .afi_rate_ratio = AFI_RATE_RATIO,
> .calib_lfifo_offset = CALIB_LFIFO_OFFSET,
> .calib_vfifo_offset = CALIB_VFIFO_OFFSET,
>
Applied, thanks
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: make config structs const
There are two config structs left in wrap_sdram_config.c that can
be made const.
Signed-off-by: Simon Goldschmidt
---
arch/arm/mach-socfpga/wrap_sdram_config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-socfpga/wrap_sdram_config.c
b/arch/arm/mach-socfpga/wrap_sdram_config.c
index 8cfacc7a13..2b072cc65e 100644
--- a/arch/arm/mach-socfpga/wrap_sdram_config.c
+++ b/arch/arm/mach-socfpga/wrap_sdram_config.c
@@ -251,7 +251,7 @@ static const struct socfpga_sdram_rw_mgr_config
rw_mgr_config = {
RW_MGR_MEM_VIRTUAL_GROUPS_PER_WRITE_DQS,
};
-struct socfpga_sdram_io_config io_config = {
+static const struct socfpga_sdram_io_config io_config = {
.delay_per_dchain_tap = IO_DELAY_PER_DCHAIN_TAP,
.delay_per_dqs_en_dchain_tap= IO_DELAY_PER_DQS_EN_DCHAIN_TAP,
.delay_per_opa_tap = IO_DELAY_PER_OPA_TAP,
@@ -269,7 +269,7 @@ struct socfpga_sdram_io_config io_config = {
.shift_dqs_en_when_shift_dqs= IO_SHIFT_DQS_EN_WHEN_SHIFT_DQS,
};
-struct socfpga_sdram_misc_config misc_config = {
+static const struct socfpga_sdram_misc_config misc_config = {
.afi_rate_ratio = AFI_RATE_RATIO,
.calib_lfifo_offset = CALIB_LFIFO_OFFSET,
.calib_vfifo_offset = CALIB_VFIFO_OFFSET,
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On 14.11.2018 16:51, Simon Goldschmidt wrote:
On 14.11.2018 16:35, Daniele Bianco wrote:
On Wed, Nov 14, 2018 at 04:26:17PM +0100, Andrea Barisani wrote:
On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
On 14.11.2018 15:45, Andrea Barisani wrote:
On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
On 14.11.2018 12:52, Andrea Barisani wrote:
On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
On 06.11.2018 15:51, Andrea Barisani wrote:
[..]
The issue can be exploited by several means:
- An excessively large crafted boot image file is parsed by the
`tftp_handler` function which lacks any size checks, allowing the
memory
overwrite.
- A malicious server can manipulate TFTP packet sequence numbers to store
downloaded file chunks at arbitrary memory locations, given that the
sequence number is directly used by the `tftp_handler` function to
calculate
the destination address for downloaded file chunks.
Additionally the `store_block` function, used to store downloaded file
chunks in memory, when invoked by `tftp_handler` with a
`tftp_cur_block`
value of 0, triggers an unchecked integer underflow.
This allows to potentially erase memory located before the `loadAddr`
when
a packet is sent with a null, following at least one valid packet.
Do you happen to have more details on this suggested integer underflow? I
have tried to reproduce it, but I failed to get a memory write address
before 'load_addr'. This is because the 'store_block' function does not
directly use the underflowed integer as a block counter, but adds
'tcp_block_wrap_offset' to this offset.
To me it seems like alternating between '0' and 'not 0' for the block
counter could increase memory overwrites, but I fail to see how you can use
this to store chunks at arbitrary memory locations. All you can do is
subtract one block size from 'tftp_block_wrap_offset'...
Simon
Hello Simon,
the integer underflow can happen if a malicious TFTP server, able to control
the TFTP packets sequence number, sends a crafted packet with sequence number
set to 0 during a flow.
This happens because, within the store_block() function, the 'block' argument
is declared as 'int' and when it is invoked inside tftp_handler() (case
TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
tftp_cur_block is the sequence number extracted from the tftp packet without
any previous check):
static inline void store_block(int block, uchar *src, unsigned len)
^ can have negative values (e.g. -1)
{
ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
^
here if block is -1 the result stored onto offset would be a very
large unsigned number, due to type conversions
And this is exatclty my point. This might be bad coding style, but for me it
works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
'-512'. Now from the code flow in tftp_handler(), it's clear that if we come
here with tftp_cur_block == 0 (so 'block' is -1), 'tftp_block_wrap_offset'
is not 0 but some positive value 'x * tftp_block_size' (see function
'update_block_number').
So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still fail
to see how this can be a very large positive number resulting in an
effective negative offset or arbitrary write.
I understand your point, however what does happen when we enter the 'case
TFTP_DATA' and we are in the first block received, so we trigger
new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
tftp_mcast_active is set?
I don't see any protection for this case for the underflow, am I wrong?
static void new_transfer(void)
{
tftp_prev_block = 0;
tftp_block_wrap = 0;
tftp_block_wrap_offset = 0;
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
}
...
case TFTP_DATA:
if (tftp_state == STATE_SEND_RRQ || tftp_state == STATE_OACK
||
tftp_state == STATE_RECV_WRQ) {
/* first block received */
tftp_state = STATE_DATA;
tftp_remote_port = src;
new_transfer();
^^^
See some lines below...
#ifdef CONFIG_MCAST_TFTP
if (tftp_mcast_active) { /* start!=1 common if mcast */
HERE
tftp_prev_block = tftp_cur_block - 1;
} else
#endif
if (tftp_cur_block != 1) { /* Assertion */
If tftp_cur_block is 0 for the first block, we stop right away. No chance to
reach store_block() at that time.
CC'ing my colleague Daniele whom can better reply further on this.
Hi Simon,
the 'if (tftp_cur_block != 1)' is not
Re: [U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig
On 07.10.2018 02:49, Tom Rini wrote: On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote: Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with help from moveconfig.py (only had to prepare socfpga, stm32f746 and am33x/43x manually) Signed-off-by: Simon Goldschmidt --- This patch is in preparation for boot-from-FPGA for socfpga cyclone5, where we need a different SPL_TEXT_BASE. By moving this to Kconfig, this can then be done via defconfig. I did notice that some defconfig files change more than necessary, it seems like they are out of sync? So, I see at least one set of problems with the conversion, the am33* family gets put to 0x0 which isn't right. I'm going to pull out the print tool I made and posted a while back and use that for conversion. Thanks for the starting point! Tom, what's the status on this? I still can't build an SPL for socfpga gen5 boot from FPGA because I can't change SPL_TEXT_BASE. Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can we have a separate (k)config option for socfpga only? That might be useful anyway as when booting from fpga, there is no 64 KByte size limit and the "magic value into magic register to unlock support for issuing warm reset" must not be written as the SPL is not in SRAM. But that might have its separate config option, too... Anyway, I just need input to know in which direction I should continue. I'm waiting to get all our versions of SPL and U-Boot running from mainline (with only board configs added for our private boards). Thanks, Simon Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: Add PHYTEC phyBOARD-i.MX6UL-Segin
Port for the PHYTEC phyBOARD-i.MX6UL-Segin single board computer. Based on the PHYTEC phyCORE-i.MX6UL SOM (PCL063). This port provides both SPL and DCD based boot options (hence the two defconfigs). CPU: Freescale i.MX6UL rev1.2 528 MHz (running at 396 MHz) CPU: Industrial temperature grade (-40C to 105C) at 44C Reset cause: POR Board: PHYTEC phyCORE-i.MX6UL I2C: ready DRAM: 256 MiB NAND: 512 MiB MMC: FSL_SDHC: 0 In:serial Out: serial Err: serial Net: FEC0 Working: - Eth0 - Eth1 - i2C - MMC/SD - NAND - UART (1 & 5) - USB (host & otg) Signed-off-by: Martyn Welch --- arch/arm/mach-imx/mx6/Kconfig| 8 + board/phytec/pcl063/Kconfig | 12 + board/phytec/pcl063/MAINTAINERS | 7 + board/phytec/pcl063/Makefile | 7 + board/phytec/pcl063/README | 43 +++ board/phytec/pcl063/imximage.cfg | 177 + board/phytec/pcl063/pcl063.c | 379 +++ board/phytec/pcl063/spl.c| 118 + configs/phycore_pcl063_defconfig | 47 configs/phycore_pcl063_spl_defconfig | 55 include/configs/pcl063.h | 107 11 files changed, 960 insertions(+) create mode 100644 board/phytec/pcl063/Kconfig create mode 100644 board/phytec/pcl063/MAINTAINERS create mode 100644 board/phytec/pcl063/Makefile create mode 100644 board/phytec/pcl063/README create mode 100644 board/phytec/pcl063/imximage.cfg create mode 100644 board/phytec/pcl063/pcl063.c create mode 100644 board/phytec/pcl063/spl.c create mode 100644 configs/phycore_pcl063_defconfig create mode 100644 configs/phycore_pcl063_spl_defconfig create mode 100644 include/configs/pcl063.h diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig index 06c25bae36..22aea99f8f 100644 --- a/arch/arm/mach-imx/mx6/Kconfig +++ b/arch/arm/mach-imx/mx6/Kconfig @@ -428,6 +428,13 @@ config TARGET_PFLA02 select MX6QDL select SUPPORT_SPL +config TARGET_PCL063 + bool "PHYTEC PCL063 (phyCORE-i.MX6UL)" + select MX6UL + select DM + select DM_THERMAL + select SUPPORT_SPL + config TARGET_SECOMX6 bool "secomx6 boards" @@ -550,6 +557,7 @@ source "board/freescale/mx6ullevk/Kconfig" source "board/grinn/liteboard/Kconfig" source "board/phytec/pcm058/Kconfig" source "board/phytec/pfla02/Kconfig" +source "board/phytec/pcl063/Kconfig" source "board/gateworks/gw_ventana/Kconfig" source "board/kosagi/novena/Kconfig" source "board/samtec/vining_2000/Kconfig" diff --git a/board/phytec/pcl063/Kconfig b/board/phytec/pcl063/Kconfig new file mode 100644 index 00..977db70f64 --- /dev/null +++ b/board/phytec/pcl063/Kconfig @@ -0,0 +1,12 @@ +if TARGET_PCL063 + +config SYS_BOARD + default "pcl063" + +config SYS_VENDOR + default "phytec" + +config SYS_CONFIG_NAME + default "pcl063" + +endif diff --git a/board/phytec/pcl063/MAINTAINERS b/board/phytec/pcl063/MAINTAINERS new file mode 100644 index 00..8edc45827c --- /dev/null +++ b/board/phytec/pcl063/MAINTAINERS @@ -0,0 +1,7 @@ +PCL063 BOARD +M: Martyn Welch +S: Maintained +F: board/phytec/pcl063/ +F: configs/phycore_pcl063_defconfig +F: configs/phycore_pcl063_spl_defconfig +F: include/configs/pcl063.h diff --git a/board/phytec/pcl063/Makefile b/board/phytec/pcl063/Makefile new file mode 100644 index 00..53c73c9b08 --- /dev/null +++ b/board/phytec/pcl063/Makefile @@ -0,0 +1,7 @@ +# Copyright (C) 2018 Collabora Ltd. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := pcl063.o +obj-$(CONFIG_SPL_BUILD) += spl.o diff --git a/board/phytec/pcl063/README b/board/phytec/pcl063/README new file mode 100644 index 00..d73e90e83d --- /dev/null +++ b/board/phytec/pcl063/README @@ -0,0 +1,43 @@ +How to use U-Boot on PHYTEC phyBOARD-i.MX6UL-Segin +-- + +- Clean U-Boot tree: + +$ make mrproper + +- Configure U-Boot for phyCORE-i.MX6UL (using DCD): + +$ make phycore_pcl063_defconfig + + Or for build with SPL: + +$ make phycore_pcl063_spl_defconfig + +- Build U-Boot + +$ make + + This will either generate an u-boot.imx image or SPL and u-boot-dtb.img + images depending on the config chosen. + +- When an u-boot.imx image has been built, flash this into a micro SD card as + follows: + +$ sudo dd if=u-boot.imx of=/dev/mmcblk0 bs=1k seek=1; sync + +- If the SPL and u-boot-dtb.img image have been built both need to be flashed + into the micro SD card: + +$ sudo dd if=SPL of=/dev/mmcblk0 bs=1k seek=1; sync +$ sudo dd if=u-boot-dtb.img of=/dev/mmcblk0 bs=1k seek=69; sync + +- Jumper settings: + + JP1: Open: Boot from NAND + Closed: Boot from SD/MMC1 + +- Connect the Serial cable to UART0 and the PC for the console. + +- Insert the micro SD card in the board and power it up. + +- U-Boot messages should come up. diff --git a/board/phytec/pcl063/imximage.cfg
Re: [U-Boot] [PATCH v4 01/18] tools: MediaTek: add MTK boot header generation to mkimage
Hi Ryder,
On Tue, Nov 6, 2018 at 9:50 AM Ryder Lee wrote:
>
> This patch adds support for MTK boot image generation.
>
> Signed-off-by: Weijie Gao
> Signed-off-by: Ryder Lee
> Reviewed-by: Simon Glass
> ---
> Changes since v4: None
> ---
> Makefile | 20 ++
> common/image.c | 1 +
> include/image.h | 1 +
> scripts/Makefile.spl | 11 +
> tools/Makefile | 1 +
> tools/mtk_image.c| 749
> +++
> tools/mtk_image.h| 199 ++
> 7 files changed, 982 insertions(+)
> create mode 100644 tools/mtk_image.c
> create mode 100644 tools/mtk_image.h
>
> diff --git a/Makefile b/Makefile
> index 250eb6c..5a384c8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -852,6 +852,8 @@ ALL-y += u-boot-tegra.bin u-boot-nodtb-tegra.bin
> ALL-$(CONFIG_OF_SEPARATE) += u-boot-dtb-tegra.bin
> endif
>
> +ALL-$(CONFIG_ARCH_MEDIATEK) += u-boot-mtk.bin
> +
> # Add optional build target if defined in board/cpu/soc headers
> ifneq ($(CONFIG_BUILD_TARGET),)
> ALL-y += $(CONFIG_BUILD_TARGET:"%"=%)
> @@ -1359,6 +1361,24 @@ u-boot.elf: u-boot.bin
> $(Q)$(OBJCOPY) -I binary $(PLATFORM_ELFFLAGS) $< u-boot-elf.o
> $(call if_changed,u-boot-elf)
>
> +# MediaTek's ARM-based u-boot needs a header to contains its load address
> +# which is parsed by the BootROM.
> +# If the SPL build is enabled, the header will be added to the spl binary,
> +# and the spl binary and the u-boot.img will be combined into one file.
> +# Otherwise the header will be added to the u-boot.bin directly.
> +
> +ifeq ($(CONFIG_SPL),y)
> +u-boot-mtk.bin: u-boot.dtb u-boot.img spl/u-boot-spl-mtk.bin FORCE
> + $(call if_changed,binman)
> +else
> +MKIMAGEFLAGS_u-boot-mtk.bin = -T mtk_image \
> + -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \
> + -n "$(patsubst "%",%,$(CONFIG_MTK_BROM_HEADER_INFO))"
> +
> +u-boot-mtk.bin: u-boot.bin FORCE
> + $(call if_changed,mkimage)
> +endif
> +
> ARCH_POSTLINK := $(wildcard $(srctree)/arch/$(ARCH)/Makefile.postlink)
>
> # Rule to link u-boot
> diff --git a/common/image.c b/common/image.c
> index 1c3a772..d3f9914 100644
> --- a/common/image.c
> +++ b/common/image.c
> @@ -166,6 +166,7 @@ static const table_entry_t uimage_type[] = {
> { IH_TYPE_FIRMWARE_IVT, "firmware_ivt", "Firmware with HABv4
> IVT" },
> { IH_TYPE_PMMC,"pmmc","TI Power Management
> Micro-Controller Firmware",},
> { IH_TYPE_STM32IMAGE, "stm32image", "STMicroelectronics STM32
> Image" },
> + { IH_TYPE_MTKIMAGE, "mtk_image", "MeidaTek BootROM loadable
> Image" },
typo: MeidaTek -> MediaTek
> { -1, "", "", },
> };
>
> diff --git a/include/image.h b/include/image.h
> index 031c355..8dd7247 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -278,6 +278,7 @@ enum {
> IH_TYPE_PMMC,/* TI Power Management Micro-Controller
> Firmware */
> IH_TYPE_STM32IMAGE, /* STMicroelectronics STM32 Image */
> IH_TYPE_SOCFPGAIMAGE_V1,/* Altera SOCFPGA A10 Preloader */
> + IH_TYPE_MTKIMAGE, /* MeidaTek BootROM loadable Image */
typo: MeidaTek -> MediaTek
>
> IH_TYPE_COUNT, /* Number of image types */
> };
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index 7416abe..22bd8f7 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -219,6 +219,8 @@ ALL-$(CONFIG_SPL_X86_16BIT_INIT) +=
> $(obj)/u-boot-x86-16bit-spl.bin
> ALL-$(CONFIG_ARCH_ZYNQ)+= $(obj)/boot.bin
> ALL-$(CONFIG_ARCH_ZYNQMP) += $(obj)/boot.bin
>
> +ALL-$(CONFIG_ARCH_MEDIATEK)+= $(obj)/u-boot-spl-mtk.bin
> +
> all: $(ALL-y)
>
> quiet_cmd_cat = CAT $@
> @@ -349,6 +351,15 @@ cmd_sunxi_spl_image_builder =
> $(objtree)/tools/sunxi-spl-image-builder \
> $(obj)/sunxi-spl-with-ecc.bin: $(obj)/sunxi-spl.bin
> $(call if_changed,sunxi_spl_image_builder)
>
> +
> +# MediaTek's specific SPL build
> +MKIMAGEFLAGS_u-boot-spl-mtk.bin = -T mtk_image \
> + -a $(CONFIG_SPL_TEXT_BASE) -e $(CONFIG_SPL_TEXT_BASE) \
> + -n "$(patsubst "%",%,$(CONFIG_MTK_BROM_HEADER_INFO))"
> +
> +$(obj)/u-boot-spl-mtk.bin: $(obj)/u-boot-spl.bin FORCE
> + $(call if_changed,mkimage)
> +
> # Rule to link u-boot-spl
> # May be overridden by arch/$(ARCH)/config.mk
> quiet_cmd_u-boot-spl ?= LD $@
> diff --git a/tools/Makefile b/tools/Makefile
> index 3c0521f..c93d17a 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -116,6 +116,7 @@ dumpimage-mkimage-objs := aisimage.o \
> $(LIBFDT_OBJS) \
> gpimage.o \
> gpimage-common.o \
> + mtk_image.o \
> $(RSA_OBJS-y)
>
> dumpimage-objs := $(dumpimage-mkimage-objs) dumpimage.o
> diff --git a/tools/mtk_image.c
[U-Boot] [PATCH 2/2] imx: bootaux: fix stack and pc assignment on 64-bit platforms
Using ulong is wrong as its size depends on the Host CPU architecture (32-bit vs. 64-bit) although the Cortex-M4 is always 32-bit. Without this patch, the stack and PC are obviously wrong and it generates an abort when used on 64-bit processors such as the i.MX8MQ. Signed-off-by: Gary Bisson --- arch/arm/mach-imx/imx_bootaux.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-imx/imx_bootaux.c b/arch/arm/mach-imx/imx_bootaux.c index a1ea5c13f1..3103001b7c 100644 --- a/arch/arm/mach-imx/imx_bootaux.c +++ b/arch/arm/mach-imx/imx_bootaux.c @@ -17,8 +17,8 @@ int arch_auxiliary_core_up(u32 core_id, ulong boot_private_data) if (!boot_private_data) return -EINVAL; - stack = *(ulong *)boot_private_data; - pc = *(ulong *)(boot_private_data + 4); + stack = *(u32 *)boot_private_data; + pc = *(u32 *)(boot_private_data + 4); /* Set the stack and pc to M4 bootROM */ writel(stack, M4_BOOTROM_BASE_ADDR); -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] imx: fix M4 boot on i.MX8MQ processors
Hi, This series fixes loading a M4 firmware into memory and start that M4 core using bootaux on i.MX8MQ platforms. There were two issues: 1- the memory where the firmware is loaded (TCM) wasn't mapped 2- the bootaux code relied on ulong instead of u32 (M4 core is 32-bit) This was tested on Nitrogen8M platform. Regards, Gary Gary Bisson (2): imx: mx8m: add memory mapping for CAAM and TCM imx: bootaux: fix stack and pc assignment on 64-bit platforms arch/arm/mach-imx/imx_bootaux.c | 4 ++-- arch/arm/mach-imx/mx8m/soc.c| 16 2 files changed, 18 insertions(+), 2 deletions(-) -- 2.19.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] imx: mx8m: add memory mapping for CAAM and TCM
Otherwise can't boot the M4 core as it is impossible to load its
firmware into the TCM memory.
Signed-off-by: Gary Bisson
---
arch/arm/mach-imx/mx8m/soc.c | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/mach-imx/mx8m/soc.c b/arch/arm/mach-imx/mx8m/soc.c
index 46873aa8dd..11251c5f9a 100644
--- a/arch/arm/mach-imx/mx8m/soc.c
+++ b/arch/arm/mach-imx/mx8m/soc.c
@@ -77,6 +77,22 @@ static struct mm_region imx8m_mem_map[] = {
.size = 0x10UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
PTE_BLOCK_OUTER_SHARE
+ }, {
+ /* CAAM */
+ .virt = 0x10UL,
+ .phys = 0x10UL,
+ .size = 0x8000UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ }, {
+ /* TCM */
+ .virt = 0x7CUL,
+ .phys = 0x7CUL,
+ .size = 0x8UL,
+ .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
+PTE_BLOCK_NON_SHARE |
+PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
/* OCRAM */
.virt = 0x90UL,
--
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2018.11 released
Hey all, It's a few days past the scheduled release day, but we're here now and I'm happy enough with the last minute SPI changes that we're releasing now. The release is live on git (I hope) and FTP and ACD (along with the PGP sig file). As I've been asking for, and receiving now more PRs with signed tags that include a summary of changes in them, I can point to: https://lists.denx.de/pipermail/u-boot/2018-October/342659.html https://lists.denx.de/pipermail/u-boot/2018-October/344567.html for a brief summary of what's gone in. After -rc2 we've mainly gone with additional fixes in: - i.MX, Xilinx, EFI Loader, R-Mobile, x86, sunxi, and Marvell platforms - Added i.MX8 support. Yes, this should have come in sooner or waited, but, well, here it is now instead. I'm going to mention here as well that both CVE-2018-18439 and CVE-2018-18440 exist and are issues. As a community we're still working on more robust fixes to them, but I want to thank Simon Goldschmidt for taking the lead on coming up with code changes for them. In the immediate term (and for older releases) note that the filesystem-based attack can be mitigated by passing a maximum size to the load command. I also want to highlight here that we're going to change up the release cycle again. There's a few more words on it here: https://lists.denx.de/pipermail/u-boot/2018-November/347209.html But in short, we're still doing v2019.01 on a 2-month cycle and after that we'll do two 3-month cycle releases, v2019.04 and v2019.07 and see where things are at towards the end of v2019.07. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Migrate and re-enabled CONFIG_CMD_MTDPARTS
On Wed, Nov 14, 2018 at 10:58:24AM -0500, Tom Rini wrote:
> Now that CMD_UBI does not select CMD_MTDPARTS we need to make platforms
> that had been enabling it turn it on by hand. This exposed that we had
> not yet migrated CMD_MTDPARTS fully, so do so now.
>
> Fixes: 86dfa556d927 ("cmd: ubi: Remove useless call to mtdparts_init()")
> Signed-off-by: Tom Rini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] gpio: pca953x_gpio: fix DT GPIO flags translation
On Thu, Oct 18, 2018 at 04:15:39PM +0200, Anatolij Gustschin wrote: > Commit fb01e07a95 accidentally broke initialisation of GPIO > descriptor flags from device tree: currently the active low > flag from gpio-specifier is always ignored. Fix it. > > Signed-off-by: Anatolij Gustschin > Cc: Mario Six Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: Zap fsl_espi driver-related code
On 11/14/18 7:46 AM, Jagan Teki wrote: > + Simon > > On Wed, Nov 14, 2018 at 9:00 PM York Sun wrote: >> >> On 11/14/18 6:57 AM, Jagan Teki wrote: >>> Dropped >>> - fsl_espi driver >>> - SPI, SPI flash CONFIG-items >>> - CMD_SF..etc >>> >>> Dropped becuase >>> - No proper changes related to since from 2015 >>> - no dm conversion. >>> >>> Cc: Tom Rini >>> Cc: York Sun >>> Signed-off-by: Jagan Teki >>> --- >>> Note: >>> - This certainly break many board, but it's too late >>> - I have seen spi is using in net, mmc [1] will remove those >>> as well if none can answer this patch. >>> >>> [1] >>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fopenedev%2Fu-boot-amarula%2Fbuilds%2F454923826data=02%7C01%7Cyork.sun%40nxp.com%7C5783a0a22ff84433058e08d64a485bb5%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636778071970654553sdata=q%2FXUyAdc6rvwSSOlTyxR2%2BlITFQn67EP9K1X5f6iM5o%3Dreserved=0 >>> >>> arch/powerpc/include/asm/config.h | 2 +- >>> configs/B4420QDS_NAND_defconfig | 5 - >>> configs/B4420QDS_SPIFLASH_defconfig | 8 +- >>> configs/B4420QDS_defconfig| 5 - >>> configs/B4860QDS_NAND_defconfig | 5 - >>> configs/B4860QDS_SECURE_BOOT_defconfig| 5 - >>> configs/B4860QDS_SPIFLASH_defconfig | 7 - >>> configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 5 - >>> configs/B4860QDS_defconfig| 5 - >>> configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 5 - >>> configs/BSC9131RDB_NAND_defconfig | 5 - >>> .../BSC9131RDB_SPIFLASH_SYSCLK100_defconfig | 7 - >>> configs/BSC9131RDB_SPIFLASH_defconfig | 7 - >>> ...BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 4 - >>> configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 5 - >>> ...BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 5 - >>> configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 5 - >>> .../BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 5 - >>> configs/BSC9132QDS_NOR_DDRCLK100_defconfig| 5 - >>> .../BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 5 - >>> configs/BSC9132QDS_NOR_DDRCLK133_defconfig| 5 - >>> ...C9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 5 - >>> configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig | 5 - >>> ...C9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 5 - >>> configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig | 5 - >>> ...132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 6 - >>> .../BSC9132QDS_SPIFLASH_DDRCLK100_defconfig | 7 - >>> ...132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 6 - >>> .../BSC9132QDS_SPIFLASH_DDRCLK133_defconfig | 7 - >>> configs/C29XPCIE_NAND_defconfig | 6 - >>> configs/C29XPCIE_NOR_SECBOOT_defconfig| 6 - >>> configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig | 7 - >>> configs/C29XPCIE_SPIFLASH_defconfig | 8 - >>> configs/C29XPCIE_defconfig| 6 - >>> configs/Cyrus_P5020_defconfig | 2 - >>> configs/Cyrus_P5040_defconfig | 2 - >>> configs/MPC8536DS_36BIT_defconfig | 5 - >>> configs/MPC8536DS_SDCARD_defconfig| 5 - >>> configs/MPC8536DS_SPIFLASH_defconfig | 7 - >>> configs/MPC8536DS_defconfig | 5 - >>> .../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PA_36BIT_NAND_defconfig | 5 - >>> .../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PA_36BIT_NOR_defconfig | 5 - >>> configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 5 - >>> ...010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - >>> configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 9 - >>> configs/P1010RDB-PA_NAND_SECBOOT_defconfig| 5 - >>> configs/P1010RDB-PA_NAND_defconfig| 5 - >>> configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PA_NOR_defconfig | 5 - >>> configs/P1010RDB-PA_SDCARD_defconfig | 5 - >>> .../P1010RDB-PA_SPIFLASH_SECBOOT_defconfig| 6 - >>> configs/P1010RDB-PA_SPIFLASH_defconfig| 9 - >>> .../P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PB_36BIT_NAND_defconfig | 5 - >>> .../P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PB_36BIT_NOR_defconfig | 5 - >>> configs/P1010RDB-PB_36BIT_SDCARD_defconfig| 5 - >>> ...010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - >>> configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 9 - >>> configs/P1010RDB-PB_NAND_SECBOOT_defconfig| 5 - >>> configs/P1010RDB-PB_NAND_defconfig| 5 - >>> configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 5 - >>> configs/P1010RDB-PB_NOR_defconfig | 5 - >>> configs/P1010RDB-PB_SDCARD_defconfig | 5 - >>> .../P1010RDB-PB_SPIFLASH_SECBOOT_defconfig| 6 - >>> configs/P1010RDB-PB_SPIFLASH_defconfig| 9 - >>>
Re: [U-Boot] list files on tftp / large kernel-image
Hi Simon, thanks for fast answer i hope mediatek release ethernet soon (i know it's a more complex driver for r2 than the other 18 patches ), than i can drop the old uboot ;) for list tftp, it seems to be a protocol limitation. here https://unix.stackexchange.com/questions/76400/download-directory-structure-from-a-tftp-server the server creates a textfile...this can be a workaround can i download (to memory) and display it (without writing it)? i only have loaded kernel and executed it's address. I don't know how to print a "Textfile" (if it's in memory i need to know it's size and print this "data block"). maybe there is a way to load the data directly to an env-var regards Frank > Gesendet: Mittwoch, 14. November 2018 um 16:34 Uhr > Von: "Simon Goldschmidt" > An: "Frank Wunderlich" , u-boot@lists.denx.de > Betreff: Re: [U-Boot] list files on tftp / large kernel-image > > is it possible to list files on tftp so i can write a script to let user > > select kernel-image to load? > > Unless I'm mistaken, the tftp protocol does not support file listing. > > > have anybody tried to load a kernelimage larger than 20MB? > > We are successfully loading FIT images of > ~26 MByte via tftp > (containing Kernel, FPGA and Initrd) without problems. > > > i use dnsmasq as tftp and uboot 2014-version (because 2018-11 für mt7623 > > currently has no ethernetdriver). > > I'm using current mainline, of course. Things might have changed in the > last 4 years... ;-) > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On 14.11.2018 16:35, Daniele Bianco wrote:
On Wed, Nov 14, 2018 at 04:26:17PM +0100, Andrea Barisani wrote:
On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
On 14.11.2018 15:45, Andrea Barisani wrote:
On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
On 14.11.2018 12:52, Andrea Barisani wrote:
On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
On 06.11.2018 15:51, Andrea Barisani wrote:
[..]
The issue can be exploited by several means:
- An excessively large crafted boot image file is parsed by the
`tftp_handler` function which lacks any size checks, allowing the memory
overwrite.
- A malicious server can manipulate TFTP packet sequence numbers to store
downloaded file chunks at arbitrary memory locations, given that the
sequence number is directly used by the `tftp_handler` function to
calculate
the destination address for downloaded file chunks.
Additionally the `store_block` function, used to store downloaded file
chunks in memory, when invoked by `tftp_handler` with a `tftp_cur_block`
value of 0, triggers an unchecked integer underflow.
This allows to potentially erase memory located before the `loadAddr`
when
a packet is sent with a null, following at least one valid packet.
Do you happen to have more details on this suggested integer underflow? I
have tried to reproduce it, but I failed to get a memory write address
before 'load_addr'. This is because the 'store_block' function does not
directly use the underflowed integer as a block counter, but adds
'tcp_block_wrap_offset' to this offset.
To me it seems like alternating between '0' and 'not 0' for the block
counter could increase memory overwrites, but I fail to see how you can use
this to store chunks at arbitrary memory locations. All you can do is
subtract one block size from 'tftp_block_wrap_offset'...
Simon
Hello Simon,
the integer underflow can happen if a malicious TFTP server, able to control
the TFTP packets sequence number, sends a crafted packet with sequence number
set to 0 during a flow.
This happens because, within the store_block() function, the 'block' argument
is declared as 'int' and when it is invoked inside tftp_handler() (case
TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
tftp_cur_block is the sequence number extracted from the tftp packet without
any previous check):
static inline void store_block(int block, uchar *src, unsigned len)
^ can have negative values (e.g. -1)
{
ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
^
here if block is -1 the result stored onto offset would be a very
large unsigned number, due to type conversions
And this is exatclty my point. This might be bad coding style, but for me it
works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
'-512'. Now from the code flow in tftp_handler(), it's clear that if we come
here with tftp_cur_block == 0 (so 'block' is -1), 'tftp_block_wrap_offset'
is not 0 but some positive value 'x * tftp_block_size' (see function
'update_block_number').
So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still fail
to see how this can be a very large positive number resulting in an
effective negative offset or arbitrary write.
I understand your point, however what does happen when we enter the 'case
TFTP_DATA' and we are in the first block received, so we trigger
new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
tftp_mcast_active is set?
I don't see any protection for this case for the underflow, am I wrong?
static void new_transfer(void)
{
tftp_prev_block = 0;
tftp_block_wrap = 0;
tftp_block_wrap_offset = 0;
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
}
...
case TFTP_DATA:
if (tftp_state == STATE_SEND_RRQ || tftp_state == STATE_OACK
||
tftp_state == STATE_RECV_WRQ) {
/* first block received */
tftp_state = STATE_DATA;
tftp_remote_port = src;
new_transfer();
^^^
See some lines below...
#ifdef CONFIG_MCAST_TFTP
if (tftp_mcast_active) { /* start!=1 common if mcast */
HERE
tftp_prev_block = tftp_cur_block - 1;
} else
#endif
if (tftp_cur_block != 1) { /* Assertion */
If tftp_cur_block is 0 for the first block, we stop right away. No chance to
reach store_block() at that time.
CC'ing my colleague Daniele whom can better reply further on this.
Hi Simon,
the 'if (tftp_cur_block != 1)' is not triggered if 'tftp_mcast_active'
is set (and the CONFIG_MCAST_TFTP is defined).
Re: [U-Boot] [PATCH v2] spi: Zap fsl_espi driver-related code
+ Simon On Wed, Nov 14, 2018 at 9:00 PM York Sun wrote: > > On 11/14/18 6:57 AM, Jagan Teki wrote: > > Dropped > > - fsl_espi driver > > - SPI, SPI flash CONFIG-items > > - CMD_SF..etc > > > > Dropped becuase > > - No proper changes related to since from 2015 > > - no dm conversion. > > > > Cc: Tom Rini > > Cc: York Sun > > Signed-off-by: Jagan Teki > > --- > > Note: > > - This certainly break many board, but it's too late > > - I have seen spi is using in net, mmc [1] will remove those > > as well if none can answer this patch. > > > > [1] > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fopenedev%2Fu-boot-amarula%2Fbuilds%2F454923826data=02%7C01%7Cyork.sun%40nxp.com%7Ccc76c039ad8e45f6705908d64a41860c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636778042646476028sdata=RZwMInnXsCeR6whjXMTsb9uRX7l1lDjySgh8wB0eMTU%3Dreserved=0 > > > > arch/powerpc/include/asm/config.h | 2 +- > > configs/B4420QDS_NAND_defconfig | 5 - > > configs/B4420QDS_SPIFLASH_defconfig | 8 +- > > configs/B4420QDS_defconfig| 5 - > > configs/B4860QDS_NAND_defconfig | 5 - > > configs/B4860QDS_SECURE_BOOT_defconfig| 5 - > > configs/B4860QDS_SPIFLASH_defconfig | 7 - > > configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 5 - > > configs/B4860QDS_defconfig| 5 - > > configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 5 - > > configs/BSC9131RDB_NAND_defconfig | 5 - > > .../BSC9131RDB_SPIFLASH_SYSCLK100_defconfig | 7 - > > configs/BSC9131RDB_SPIFLASH_defconfig | 7 - > > ...BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 4 - > > configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 5 - > > ...BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 5 - > > configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 5 - > > .../BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 5 - > > configs/BSC9132QDS_NOR_DDRCLK100_defconfig| 5 - > > .../BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 5 - > > configs/BSC9132QDS_NOR_DDRCLK133_defconfig| 5 - > > ...C9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 5 - > > configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig | 5 - > > ...C9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 5 - > > configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig | 5 - > > ...132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 6 - > > .../BSC9132QDS_SPIFLASH_DDRCLK100_defconfig | 7 - > > ...132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 6 - > > .../BSC9132QDS_SPIFLASH_DDRCLK133_defconfig | 7 - > > configs/C29XPCIE_NAND_defconfig | 6 - > > configs/C29XPCIE_NOR_SECBOOT_defconfig| 6 - > > configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig | 7 - > > configs/C29XPCIE_SPIFLASH_defconfig | 8 - > > configs/C29XPCIE_defconfig| 6 - > > configs/Cyrus_P5020_defconfig | 2 - > > configs/Cyrus_P5040_defconfig | 2 - > > configs/MPC8536DS_36BIT_defconfig | 5 - > > configs/MPC8536DS_SDCARD_defconfig| 5 - > > configs/MPC8536DS_SPIFLASH_defconfig | 7 - > > configs/MPC8536DS_defconfig | 5 - > > .../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PA_36BIT_NAND_defconfig | 5 - > > .../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PA_36BIT_NOR_defconfig | 5 - > > configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 5 - > > ...010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - > > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 9 - > > configs/P1010RDB-PA_NAND_SECBOOT_defconfig| 5 - > > configs/P1010RDB-PA_NAND_defconfig| 5 - > > configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PA_NOR_defconfig | 5 - > > configs/P1010RDB-PA_SDCARD_defconfig | 5 - > > .../P1010RDB-PA_SPIFLASH_SECBOOT_defconfig| 6 - > > configs/P1010RDB-PA_SPIFLASH_defconfig| 9 - > > .../P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PB_36BIT_NAND_defconfig | 5 - > > .../P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PB_36BIT_NOR_defconfig | 5 - > > configs/P1010RDB-PB_36BIT_SDCARD_defconfig| 5 - > > ...010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - > > configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 9 - > > configs/P1010RDB-PB_NAND_SECBOOT_defconfig| 5 - > > configs/P1010RDB-PB_NAND_defconfig| 5 - > > configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 5 - > > configs/P1010RDB-PB_NOR_defconfig | 5 - > > configs/P1010RDB-PB_SDCARD_defconfig | 5 - > > .../P1010RDB-PB_SPIFLASH_SECBOOT_defconfig| 6 - > > configs/P1010RDB-PB_SPIFLASH_defconfig| 9 - > > configs/P1020MBG-PC_36BIT_SDCARD_defconfig| 2 - > >
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On Wed, Nov 14, 2018 at 04:26:17PM +0100, Andrea Barisani wrote:
> On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
> > On 14.11.2018 15:45, Andrea Barisani wrote:
> > > On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
> > > > On 14.11.2018 12:52, Andrea Barisani wrote:
> > > > > On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
> > > > > > On 06.11.2018 15:51, Andrea Barisani wrote:
> > > > > > > [..]
> > > > > > > The issue can be exploited by several means:
> > > > > > >
> > > > > > > - An excessively large crafted boot image file is parsed by
> > > > > > > the
> > > > > > >`tftp_handler` function which lacks any size checks,
> > > > > > > allowing the memory
> > > > > > >overwrite.
> > > > > > >
> > > > > > > - A malicious server can manipulate TFTP packet sequence
> > > > > > > numbers to store
> > > > > > >downloaded file chunks at arbitrary memory locations,
> > > > > > > given that the
> > > > > > >sequence number is directly used by the `tftp_handler`
> > > > > > > function to calculate
> > > > > > >the destination address for downloaded file chunks.
> > > > > > >
> > > > > > >Additionally the `store_block` function, used to store
> > > > > > > downloaded file
> > > > > > >chunks in memory, when invoked by `tftp_handler` with a
> > > > > > > `tftp_cur_block`
> > > > > > >value of 0, triggers an unchecked integer underflow.
> > > > > > >
> > > > > > >This allows to potentially erase memory located before the
> > > > > > > `loadAddr` when
> > > > > > >a packet is sent with a null, following at least one valid
> > > > > > > packet.
> > > > > > Do you happen to have more details on this suggested integer
> > > > > > underflow? I
> > > > > > have tried to reproduce it, but I failed to get a memory write
> > > > > > address
> > > > > > before 'load_addr'. This is because the 'store_block' function does
> > > > > > not
> > > > > > directly use the underflowed integer as a block counter, but adds
> > > > > > 'tcp_block_wrap_offset' to this offset.
> > > > > >
> > > > > > To me it seems like alternating between '0' and 'not 0' for the
> > > > > > block
> > > > > > counter could increase memory overwrites, but I fail to see how you
> > > > > > can use
> > > > > > this to store chunks at arbitrary memory locations. All you can do
> > > > > > is
> > > > > > subtract one block size from 'tftp_block_wrap_offset'...
> > > > > >
> > > > > > Simon
> > > > > >
> > > > > Hello Simon,
> > > > >
> > > > > the integer underflow can happen if a malicious TFTP server, able to
> > > > > control
> > > > > the TFTP packets sequence number, sends a crafted packet with
> > > > > sequence number
> > > > > set to 0 during a flow.
> > > > >
> > > > > This happens because, within the store_block() function, the 'block'
> > > > > argument
> > > > > is declared as 'int' and when it is invoked inside tftp_handler()
> > > > > (case
> > > > > TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
> > > > > tftp_cur_block is the sequence number extracted from the tftp packet
> > > > > without
> > > > > any previous check):
> > > > >
> > > > > static inline void store_block(int block, uchar *src, unsigned len)
> > > > > ^ can have negative values
> > > > > (e.g. -1)
> > > > > {
> > > > > ulong offset = block * tftp_block_size +
> > > > > tftp_block_wrap_offset;
> > > > > ^
> > > > > here if block is -1 the result stored onto offset would be
> > > > > a very
> > > > > large unsigned number, due to type conversions
> > > > And this is exatclty my point. This might be bad coding style, but for
> > > > me it
> > > > works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
> > > > '-512'. Now from the code flow in tftp_handler(), it's clear that if we
> > > > come
> > > > here with tftp_cur_block == 0 (so 'block' is -1),
> > > > 'tftp_block_wrap_offset'
> > > > is not 0 but some positive value 'x * tftp_block_size' (see function
> > > > 'update_block_number').
> > > >
> > > > So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still
> > > > fail
> > > > to see how this can be a very large positive number resulting in an
> > > > effective negative offset or arbitrary write.
> > > >
> > > I understand your point, however what does happen when we enter the 'case
> > > TFTP_DATA' and we are in the first block received, so we trigger
> > > new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
> > > tftp_mcast_active is set?
> > >
> > > I don't see any protection for this case for the underflow, am I wrong?
> > >
> > > static void new_transfer(void)
> > > {
> > > tftp_prev_block = 0;
> > > tftp_block_wrap = 0;
> > > tftp_block_wrap_offset = 0;
> > > #ifdef CONFIG_CMD_TFTPPUT
> > >
Re: [U-Boot] [PATCH] configs: at91: add CONFIG_OF_EMBED=y in all defconfigs
On Wed, 2018-11-14 at 07:18 +, eugen.hris...@microchip.com wrote: > > On 13.11.2018 17:04, Radu Pirea wrote: > > U-boot must have dtb built in because at91bootstrap can not load > > it. > > Hello,v > > The DTB is already appended in the image with the current defconfigs. > This has been in place for our boards for a long time, and I do not > see > any reason for change. > Anyway, not because our proprietary bootstrap cannot load it - the > u-boot DTB is inside the bin as it is configured now, single file > with a > both (binary+DTB) (there is a u-boot-nodtb.bin without the DTB if > required). > Perhaps you have other reason for this change ? Hi Eugen, I know dtb is appended to the u-boot binary and I thought that something has been changed in current u-boot source and dtb will not be appended to the u-boot binary. Anyway, the problem was with bootstrap. My version of bootstrap was old and didn't read enough bytes from NAND. After a bootstrap upgrade everything is ok. This patch can be ignored. > > Thanks, > Eugen > > > Signed-off-by: Radu Pirea > > --- > > configs/at91rm9200ek_defconfig | 1 + > > configs/at91rm9200ek_ram_defconfig | 1 + > > configs/at91sam9260ek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9260ek_dataflash_cs1_defconfig | 1 + > > configs/at91sam9260ek_nandflash_defconfig | 1 + > > configs/at91sam9261ek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9261ek_dataflash_cs3_defconfig | 1 + > > configs/at91sam9261ek_nandflash_defconfig | 1 + > > configs/at91sam9263ek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9263ek_dataflash_defconfig | 1 + > > configs/at91sam9263ek_nandflash_defconfig | 1 + > > configs/at91sam9263ek_norflash_boot_defconfig | 1 + > > configs/at91sam9263ek_norflash_defconfig | 1 + > > configs/at91sam9g10ek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9g10ek_dataflash_cs3_defconfig | 1 + > > configs/at91sam9g10ek_nandflash_defconfig | 1 + > > configs/at91sam9g20ek_2mmc_defconfig | 1 + > > configs/at91sam9g20ek_2mmc_nandflash_defconfig | 1 + > > configs/at91sam9g20ek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9g20ek_dataflash_cs1_defconfig | 1 + > > configs/at91sam9g20ek_nandflash_defconfig | 1 + > > configs/at91sam9m10g45ek_mmc_defconfig | 1 + > > configs/at91sam9m10g45ek_nandflash_defconfig | 1 + > > configs/at91sam9n12ek_mmc_defconfig| 1 + > > configs/at91sam9n12ek_nandflash_defconfig | 1 + > > configs/at91sam9n12ek_spiflash_defconfig | 1 + > > configs/at91sam9rlek_dataflash_defconfig | 1 + > > configs/at91sam9rlek_mmc_defconfig | 1 + > > configs/at91sam9rlek_nandflash_defconfig | 1 + > > configs/at91sam9x5ek_dataflash_defconfig | 1 + > > configs/at91sam9x5ek_mmc_defconfig | 1 + > > configs/at91sam9x5ek_nandflash_defconfig | 1 + > > configs/at91sam9x5ek_spiflash_defconfig| 1 + > > configs/at91sam9xeek_dataflash_cs0_defconfig | 1 + > > configs/at91sam9xeek_dataflash_cs1_defconfig | 1 + > > configs/at91sam9xeek_nandflash_defconfig | 1 + > > configs/sama5d27_som1_ek_mmc_defconfig | 1 + > > configs/sama5d2_ptc_ek_mmc_defconfig | 1 + > > configs/sama5d2_ptc_ek_nandflash_defconfig | 1 + > > configs/sama5d2_xplained_mmc_defconfig | 1 + > > configs/sama5d2_xplained_spiflash_defconfig| 1 + > > configs/sama5d36ek_cmp_mmc_defconfig | 1 + > > configs/sama5d36ek_cmp_nandflash_defconfig | 1 + > > configs/sama5d36ek_cmp_spiflash_defconfig | 1 + > > configs/sama5d3_xplained_mmc_defconfig | 1 + > > configs/sama5d3_xplained_nandflash_defconfig | 1 + > > configs/sama5d3xek_mmc_defconfig | 1 + > > configs/sama5d3xek_nandflash_defconfig | 1 + > > configs/sama5d3xek_spiflash_defconfig | 1 + > > configs/sama5d4_xplained_mmc_defconfig | 1 + > > configs/sama5d4_xplained_nandflash_defconfig | 1 + > > configs/sama5d4_xplained_spiflash_defconfig| 1 + > > configs/sama5d4ek_mmc_defconfig| 1 + > > configs/sama5d4ek_nandflash_defconfig | 1 + > > configs/sama5d4ek_spiflash_defconfig | 1 + > > 55 files changed, 55 insertions(+) > > > > diff --git a/configs/at91rm9200ek_defconfig > > b/configs/at91rm9200ek_defconfig > > index 6af0118cf5..a2387801f7 100644 > > --- a/configs/at91rm9200ek_defconfig > > +++ b/configs/at91rm9200ek_defconfig > > @@ -25,3 +25,4 @@ CONFIG_USB=y > > CONFIG_USB_STORAGE=y > > CONFIG_USB_KEYBOARD=y > > CONFIG_OF_LIBFDT=y > > +CONFIG_OF_EMBED=y > > diff --git a/configs/at91rm9200ek_ram_defconfig > > b/configs/at91rm9200ek_ram_defconfig > > index 2688299db1..4889a8da52 100644 > > --- a/configs/at91rm9200ek_ram_defconfig > > +++ b/configs/at91rm9200ek_ram_defconfig > > @@ -26,3 +26,4 @@ CONFIG_USB=y > >
Re: [U-Boot] list files on tftp / large kernel-image
On 14.11.2018 16:24, Frank Wunderlich wrote: Hi, is it possible to list files on tftp so i can write a script to let user select kernel-image to load? Unless I'm mistaken, the tftp protocol does not support file listing. have anybody tried to load a kernelimage larger than 20MB? We are successfully loading FIT images of > ~26 MByte via tftp (containing Kernel, FPGA and Initrd) without problems. i use dnsmasq as tftp and uboot 2014-version (because 2018-11 für mt7623 currently has no ethernetdriver). I'm using current mainline, of course. Things might have changed in the last 4 years... ;-) Simon If kernelimage is larger than ~20MB loading file hangs...tried setting blocksize, but it's the same behaviour, only more/less #-symbols. I don't know how much data is loaded, because there is loadedbytes-counter (i only can count the # and multiply with blocksize if i know it). do i have any chance to debug that or is this already known/fixed? regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] spi: Zap fsl_espi driver-related code
On 11/14/18 6:57 AM, Jagan Teki wrote: > Dropped > - fsl_espi driver > - SPI, SPI flash CONFIG-items > - CMD_SF..etc > > Dropped becuase > - No proper changes related to since from 2015 > - no dm conversion. > > Cc: Tom Rini > Cc: York Sun > Signed-off-by: Jagan Teki > --- > Note: > - This certainly break many board, but it's too late > - I have seen spi is using in net, mmc [1] will remove those > as well if none can answer this patch. > > [1] > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftravis-ci.org%2Fopenedev%2Fu-boot-amarula%2Fbuilds%2F454923826data=02%7C01%7Cyork.sun%40nxp.com%7Ccc76c039ad8e45f6705908d64a41860c%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636778042646476028sdata=RZwMInnXsCeR6whjXMTsb9uRX7l1lDjySgh8wB0eMTU%3Dreserved=0 > > arch/powerpc/include/asm/config.h | 2 +- > configs/B4420QDS_NAND_defconfig | 5 - > configs/B4420QDS_SPIFLASH_defconfig | 8 +- > configs/B4420QDS_defconfig| 5 - > configs/B4860QDS_NAND_defconfig | 5 - > configs/B4860QDS_SECURE_BOOT_defconfig| 5 - > configs/B4860QDS_SPIFLASH_defconfig | 7 - > configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 5 - > configs/B4860QDS_defconfig| 5 - > configs/BSC9131RDB_NAND_SYSCLK100_defconfig | 5 - > configs/BSC9131RDB_NAND_defconfig | 5 - > .../BSC9131RDB_SPIFLASH_SYSCLK100_defconfig | 7 - > configs/BSC9131RDB_SPIFLASH_defconfig | 7 - > ...BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 4 - > configs/BSC9132QDS_NAND_DDRCLK100_defconfig | 5 - > ...BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 5 - > configs/BSC9132QDS_NAND_DDRCLK133_defconfig | 5 - > .../BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig | 5 - > configs/BSC9132QDS_NOR_DDRCLK100_defconfig| 5 - > .../BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig | 5 - > configs/BSC9132QDS_NOR_DDRCLK133_defconfig| 5 - > ...C9132QDS_SDCARD_DDRCLK100_SECURE_defconfig | 5 - > configs/BSC9132QDS_SDCARD_DDRCLK100_defconfig | 5 - > ...C9132QDS_SDCARD_DDRCLK133_SECURE_defconfig | 5 - > configs/BSC9132QDS_SDCARD_DDRCLK133_defconfig | 5 - > ...132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 6 - > .../BSC9132QDS_SPIFLASH_DDRCLK100_defconfig | 7 - > ...132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 6 - > .../BSC9132QDS_SPIFLASH_DDRCLK133_defconfig | 7 - > configs/C29XPCIE_NAND_defconfig | 6 - > configs/C29XPCIE_NOR_SECBOOT_defconfig| 6 - > configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig | 7 - > configs/C29XPCIE_SPIFLASH_defconfig | 8 - > configs/C29XPCIE_defconfig| 6 - > configs/Cyrus_P5020_defconfig | 2 - > configs/Cyrus_P5040_defconfig | 2 - > configs/MPC8536DS_36BIT_defconfig | 5 - > configs/MPC8536DS_SDCARD_defconfig| 5 - > configs/MPC8536DS_SPIFLASH_defconfig | 7 - > configs/MPC8536DS_defconfig | 5 - > .../P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 5 - > configs/P1010RDB-PA_36BIT_NAND_defconfig | 5 - > .../P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig | 5 - > configs/P1010RDB-PA_36BIT_NOR_defconfig | 5 - > configs/P1010RDB-PA_36BIT_SDCARD_defconfig| 5 - > ...010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 9 - > configs/P1010RDB-PA_NAND_SECBOOT_defconfig| 5 - > configs/P1010RDB-PA_NAND_defconfig| 5 - > configs/P1010RDB-PA_NOR_SECBOOT_defconfig | 5 - > configs/P1010RDB-PA_NOR_defconfig | 5 - > configs/P1010RDB-PA_SDCARD_defconfig | 5 - > .../P1010RDB-PA_SPIFLASH_SECBOOT_defconfig| 6 - > configs/P1010RDB-PA_SPIFLASH_defconfig| 9 - > .../P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 5 - > configs/P1010RDB-PB_36BIT_NAND_defconfig | 5 - > .../P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig | 5 - > configs/P1010RDB-PB_36BIT_NOR_defconfig | 5 - > configs/P1010RDB-PB_36BIT_SDCARD_defconfig| 5 - > ...010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 6 - > configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 9 - > configs/P1010RDB-PB_NAND_SECBOOT_defconfig| 5 - > configs/P1010RDB-PB_NAND_defconfig| 5 - > configs/P1010RDB-PB_NOR_SECBOOT_defconfig | 5 - > configs/P1010RDB-PB_NOR_defconfig | 5 - > configs/P1010RDB-PB_SDCARD_defconfig | 5 - > .../P1010RDB-PB_SPIFLASH_SECBOOT_defconfig| 6 - > configs/P1010RDB-PB_SPIFLASH_defconfig| 9 - > configs/P1020MBG-PC_36BIT_SDCARD_defconfig| 2 - > configs/P1020MBG-PC_36BIT_defconfig | 2 - > configs/P1020MBG-PC_SDCARD_defconfig | 2 - > configs/P1020MBG-PC_defconfig | 2 - > configs/P1020RDB-PC_36BIT_NAND_defconfig | 5 - > configs/P1020RDB-PC_36BIT_SDCARD_defconfig
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On Wed, Nov 14, 2018 at 04:13:00PM +0100, Simon Goldschmidt wrote:
> On 14.11.2018 15:45, Andrea Barisani wrote:
> > On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
> > > On 14.11.2018 12:52, Andrea Barisani wrote:
> > > > On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
> > > > > On 06.11.2018 15:51, Andrea Barisani wrote:
> > > > > > [..]
> > > > > > The issue can be exploited by several means:
> > > > > >
> > > > > > - An excessively large crafted boot image file is parsed by the
> > > > > >`tftp_handler` function which lacks any size checks,
> > > > > > allowing the memory
> > > > > >overwrite.
> > > > > >
> > > > > > - A malicious server can manipulate TFTP packet sequence
> > > > > > numbers to store
> > > > > >downloaded file chunks at arbitrary memory locations, given
> > > > > > that the
> > > > > >sequence number is directly used by the `tftp_handler`
> > > > > > function to calculate
> > > > > >the destination address for downloaded file chunks.
> > > > > >
> > > > > >Additionally the `store_block` function, used to store
> > > > > > downloaded file
> > > > > >chunks in memory, when invoked by `tftp_handler` with a
> > > > > > `tftp_cur_block`
> > > > > >value of 0, triggers an unchecked integer underflow.
> > > > > >
> > > > > >This allows to potentially erase memory located before the
> > > > > > `loadAddr` when
> > > > > >a packet is sent with a null, following at least one valid
> > > > > > packet.
> > > > > Do you happen to have more details on this suggested integer
> > > > > underflow? I
> > > > > have tried to reproduce it, but I failed to get a memory write address
> > > > > before 'load_addr'. This is because the 'store_block' function does
> > > > > not
> > > > > directly use the underflowed integer as a block counter, but adds
> > > > > 'tcp_block_wrap_offset' to this offset.
> > > > >
> > > > > To me it seems like alternating between '0' and 'not 0' for the block
> > > > > counter could increase memory overwrites, but I fail to see how you
> > > > > can use
> > > > > this to store chunks at arbitrary memory locations. All you can do is
> > > > > subtract one block size from 'tftp_block_wrap_offset'...
> > > > >
> > > > > Simon
> > > > >
> > > > Hello Simon,
> > > >
> > > > the integer underflow can happen if a malicious TFTP server, able to
> > > > control
> > > > the TFTP packets sequence number, sends a crafted packet with sequence
> > > > number
> > > > set to 0 during a flow.
> > > >
> > > > This happens because, within the store_block() function, the 'block'
> > > > argument
> > > > is declared as 'int' and when it is invoked inside tftp_handler() (case
> > > > TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
> > > > tftp_cur_block is the sequence number extracted from the tftp packet
> > > > without
> > > > any previous check):
> > > >
> > > > static inline void store_block(int block, uchar *src, unsigned len)
> > > > ^ can have negative values
> > > > (e.g. -1)
> > > > {
> > > > ulong offset = block * tftp_block_size +
> > > > tftp_block_wrap_offset;
> > > > ^
> > > > here if block is -1 the result stored onto offset would be a
> > > > very
> > > > large unsigned number, due to type conversions
> > > And this is exatclty my point. This might be bad coding style, but for me
> > > it
> > > works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
> > > '-512'. Now from the code flow in tftp_handler(), it's clear that if we
> > > come
> > > here with tftp_cur_block == 0 (so 'block' is -1), 'tftp_block_wrap_offset'
> > > is not 0 but some positive value 'x * tftp_block_size' (see function
> > > 'update_block_number').
> > >
> > > So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still
> > > fail
> > > to see how this can be a very large positive number resulting in an
> > > effective negative offset or arbitrary write.
> > >
> > I understand your point, however what does happen when we enter the 'case
> > TFTP_DATA' and we are in the first block received, so we trigger
> > new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
> > tftp_mcast_active is set?
> >
> > I don't see any protection for this case for the underflow, am I wrong?
> >
> > static void new_transfer(void)
> > {
> > tftp_prev_block = 0;
> > tftp_block_wrap = 0;
> > tftp_block_wrap_offset = 0;
> > #ifdef CONFIG_CMD_TFTPPUT
> > tftp_put_final_block_sent = 0;
> > #endif
> > }
> >
> > ...
> > case TFTP_DATA:
> >
> > if (tftp_state == STATE_SEND_RRQ || tftp_state ==
> > STATE_OACK ||
> > tftp_state == STATE_RECV_WRQ) {
> > /* first block received */
> > tftp_state = STATE_DATA;
> >
[U-Boot] list files on tftp / large kernel-image
Hi, is it possible to list files on tftp so i can write a script to let user select kernel-image to load? have anybody tried to load a kernelimage larger than 20MB? i use dnsmasq as tftp and uboot 2014-version (because 2018-11 für mt7623 currently has no ethernetdriver). If kernelimage is larger than ~20MB loading file hangs...tried setting blocksize, but it's the same behaviour, only more/less #-symbols. I don't know how much data is loaded, because there is loadedbytes-counter (i only can count the # and multiply with blocksize if i know it). do i have any chance to debug that or is this already known/fixed? regards Frank ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] cmd, fdt: add subcommand "get" to fdt header
On 11/14/2018 04:17 PM, Heiko Schocher wrote:
> store fdt header member with name in U-Boot
> Environment variable with name .
>
> for example to get the total length of the fdt and store
> it in filesize, call:
>
> fdt header get filesize totalsize
>
> For membernames look into fdt header definition at
> scripts/dtc/libfdt/libfdt.h
>
> Signed-off-by: Heiko Schocher
> ---
>
> Changes in v2:
> - add obviously missing "static const char *"
>
> cmd/fdt.c | 40 +++-
> 1 file changed, 39 insertions(+), 1 deletion(-)
>
> diff --git a/cmd/fdt.c b/cmd/fdt.c
> index 8a19a3fdbf..501aa7c887 100644
> --- a/cmd/fdt.c
> +++ b/cmd/fdt.c
> @@ -73,6 +73,40 @@ static int fdt_value_env_set(const void *nodep, int
> len, const char *var)
> return 0;
> }
>
> +static const char * const fdt_member_table[] = {
> + "magic",
> + "totalsize",
> + "off_dt_struct",
> + "off_dt_strings",
> + "off_mem_rsvmap",
> + "version",
> + "last_comp_version",
> + "boot_cpuid_phys",
> + "size_dt_strings",
> + "size_dt_struct",
> +};
> +
> +static int fdt_get_header_value(int argc, char * const argv[])
> +{
> + fdt32_t *fdtp = (fdt32_t *)working_fdt;
> + ulong val;
> + int i;
> +
> + if (argv[2][0] != 'g')
> + return CMD_RET_FAILURE;
> +
> + for (i = 0; i < ARRAY_SIZE(fdt_member_table); i++) {
> + if (strcmp(fdt_member_table[i], argv[4]) == 0) {
if (strcmp...)
continue;
> + val = fdt32_to_cpu(*fdtp);
You can use fdtp[i]
> + env_set_hex(argv[3], val);
> + return CMD_RET_SUCCESS;
> + }
> + fdtp++;
And drop this
> + }
Looks great otherwise
> + return CMD_RET_FAILURE;
> +}
> +
> /*
> * Flattened Device Tree command, see the help for parameter definitions.
> */
> @@ -491,6 +525,9 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
> * Display header info
> */
> } else if (argv[1][0] == 'h') {
> + if (argc == 5)
> + return fdt_get_header_value(argc, argv);
> +
> u32 version = fdt_version(working_fdt);
> printf("magic:\t\t\t0x%x\n", fdt_magic(working_fdt));
> printf("totalsize:\t\t0x%x (%d)\n", fdt_totalsize(working_fdt),
> @@ -1090,7 +1127,8 @@ static char fdt_help_text[] =
> "fdt set [] - Set [to ]\n"
> "fdt mknode - Create a new node after
> \n"
> "fdt rm [] - Delete the node or
> \n"
> - "fdt header - Display header info\n"
> + "fdt header [get ] - Display header info\n"
> + " get - get header member
> and store it in \n"
> "fdt bootcpu - Set boot cpuid\n"
> "fdt memory - Add/Update memory node\n"
> "fdt rsvmem print - Show current mem reserves\n"
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] cmd, fdt: add subcommand "get" to fdt header
store fdt header member with name in U-Boot
Environment variable with name .
for example to get the total length of the fdt and store
it in filesize, call:
fdt header get filesize totalsize
For membernames look into fdt header definition at
scripts/dtc/libfdt/libfdt.h
Signed-off-by: Heiko Schocher
---
Changes in v2:
- add obviously missing "static const char *"
cmd/fdt.c | 40 +++-
1 file changed, 39 insertions(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index 8a19a3fdbf..501aa7c887 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -73,6 +73,40 @@ static int fdt_value_env_set(const void *nodep, int len,
const char *var)
return 0;
}
+static const char * const fdt_member_table[] = {
+ "magic",
+ "totalsize",
+ "off_dt_struct",
+ "off_dt_strings",
+ "off_mem_rsvmap",
+ "version",
+ "last_comp_version",
+ "boot_cpuid_phys",
+ "size_dt_strings",
+ "size_dt_struct",
+};
+
+static int fdt_get_header_value(int argc, char * const argv[])
+{
+ fdt32_t *fdtp = (fdt32_t *)working_fdt;
+ ulong val;
+ int i;
+
+ if (argv[2][0] != 'g')
+ return CMD_RET_FAILURE;
+
+ for (i = 0; i < ARRAY_SIZE(fdt_member_table); i++) {
+ if (strcmp(fdt_member_table[i], argv[4]) == 0) {
+ val = fdt32_to_cpu(*fdtp);
+ env_set_hex(argv[3], val);
+ return CMD_RET_SUCCESS;
+ }
+ fdtp++;
+ }
+
+ return CMD_RET_FAILURE;
+}
+
/*
* Flattened Device Tree command, see the help for parameter definitions.
*/
@@ -491,6 +525,9 @@ static int do_fdt(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
* Display header info
*/
} else if (argv[1][0] == 'h') {
+ if (argc == 5)
+ return fdt_get_header_value(argc, argv);
+
u32 version = fdt_version(working_fdt);
printf("magic:\t\t\t0x%x\n", fdt_magic(working_fdt));
printf("totalsize:\t\t0x%x (%d)\n", fdt_totalsize(working_fdt),
@@ -1090,7 +1127,8 @@ static char fdt_help_text[] =
"fdt set []- Set [to ]\n"
"fdt mknode - Create a new node after \n"
"fdt rm [] - Delete the node or \n"
- "fdt header - Display header info\n"
+ "fdt header [get ] - Display header info\n"
+ " get - get header member and store
it in \n"
"fdt bootcpu - Set boot cpuid\n"
"fdt memory - Add/Update memory node\n"
"fdt rsvmem print- Show current mem reserves\n"
--
2.13.6
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On 14.11.2018 15:45, Andrea Barisani wrote:
On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
On 14.11.2018 12:52, Andrea Barisani wrote:
On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
On 06.11.2018 15:51, Andrea Barisani wrote:
[..]
The issue can be exploited by several means:
- An excessively large crafted boot image file is parsed by the
`tftp_handler` function which lacks any size checks, allowing the memory
overwrite.
- A malicious server can manipulate TFTP packet sequence numbers to store
downloaded file chunks at arbitrary memory locations, given that the
sequence number is directly used by the `tftp_handler` function to
calculate
the destination address for downloaded file chunks.
Additionally the `store_block` function, used to store downloaded file
chunks in memory, when invoked by `tftp_handler` with a `tftp_cur_block`
value of 0, triggers an unchecked integer underflow.
This allows to potentially erase memory located before the `loadAddr`
when
a packet is sent with a null, following at least one valid packet.
Do you happen to have more details on this suggested integer underflow? I
have tried to reproduce it, but I failed to get a memory write address
before 'load_addr'. This is because the 'store_block' function does not
directly use the underflowed integer as a block counter, but adds
'tcp_block_wrap_offset' to this offset.
To me it seems like alternating between '0' and 'not 0' for the block
counter could increase memory overwrites, but I fail to see how you can use
this to store chunks at arbitrary memory locations. All you can do is
subtract one block size from 'tftp_block_wrap_offset'...
Simon
Hello Simon,
the integer underflow can happen if a malicious TFTP server, able to control
the TFTP packets sequence number, sends a crafted packet with sequence number
set to 0 during a flow.
This happens because, within the store_block() function, the 'block' argument
is declared as 'int' and when it is invoked inside tftp_handler() (case
TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
tftp_cur_block is the sequence number extracted from the tftp packet without
any previous check):
static inline void store_block(int block, uchar *src, unsigned len)
^ can have negative values (e.g. -1)
{
ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
^
here if block is -1 the result stored onto offset would be a very
large unsigned number, due to type conversions
And this is exatclty my point. This might be bad coding style, but for me it
works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
'-512'. Now from the code flow in tftp_handler(), it's clear that if we come
here with tftp_cur_block == 0 (so 'block' is -1), 'tftp_block_wrap_offset'
is not 0 but some positive value 'x * tftp_block_size' (see function
'update_block_number').
So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still fail
to see how this can be a very large positive number resulting in an
effective negative offset or arbitrary write.
I understand your point, however what does happen when we enter the 'case
TFTP_DATA' and we are in the first block received, so we trigger
new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
tftp_mcast_active is set?
I don't see any protection for this case for the underflow, am I wrong?
static void new_transfer(void)
{
tftp_prev_block = 0;
tftp_block_wrap = 0;
tftp_block_wrap_offset = 0;
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
}
...
case TFTP_DATA:
if (tftp_state == STATE_SEND_RRQ || tftp_state == STATE_OACK ||
tftp_state == STATE_RECV_WRQ) {
/* first block received */
tftp_state = STATE_DATA;
tftp_remote_port = src;
new_transfer();
^^^
See some lines below...
#ifdef CONFIG_MCAST_TFTP
if (tftp_mcast_active) { /* start!=1 common if mcast */
HERE
tftp_prev_block = tftp_cur_block - 1;
} else
#endif
if (tftp_cur_block != 1) { /* Assertion */
If tftp_cur_block is 0 for the first block, we stop right away. No
chance to reach store_block() at that time.
puts("\nTFTP error: ");
printf("First block is not block 1 (%ld)\n",
tftp_cur_block);
puts("Starting again\n\n");
net_start_again();
break;
}
}
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On 11/14/2018 08:09 AM, Ang, Chee Hong wrote:
> On Thu, 2018-10-11 at 10:03 +, Marek Vasut wrote:
>> On 10/11/2018 08:21 AM, Ang, Chee Hong wrote:
>>>
>>> On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
>
>
> On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
>>
>>
>> On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
>>>
>>>
>>>
>>> On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
>
>
>
>
> On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
>>
>>
>>
>>
>> On 10/08/2018 11:48 AM, chee.hong@intel.com
>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> From: "Ang, Chee Hong"
>>>
>>> Enable 'fpga' command in u-boot. User will be able
>>> to
>>> use
>>> the
>>> fpga
>>> command to program the FPGA on Stratix10 SoC.
>>>
>>> Signed-off-by: Ang, Chee Hong >> com>
>>> ---
>>> arch/arm/mach-socfpga/misc.c | 29
>>> +
>>> arch/arm/mach-socfpga/misc_s10.c | 2 ++
>>> drivers/fpga/altera.c| 6 ++
>>> include/altera.h | 4
>>> 4 files changed, 41 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-socfpga/misc.c
>>> b/arch/arm/mach-
>>> socfpga/misc.c
>>> index a4f6d5c..7986b58 100644
>>> --- a/arch/arm/mach-socfpga/misc.c
>>> +++ b/arch/arm/mach-socfpga/misc.c
>>> @@ -88,6 +88,27 @@ int overwrite_console(void)
>>> #endif
>>>
>>> #ifdef CONFIG_FPGA
>>> +#ifdef CONFIG_FPGA_STRATIX10
>>> +/*
>>> + * FPGA programming support for SoC FPGA Stratix
>>> 10
>>> + */
>>> +static Altera_desc altera_fpga[] = {
>>> + {
>>> + /* Family */
>>> + Intel_FPGA_Stratix10,
>>> + /* Interface type */
>>> + secure_device_manager_mailbox,
>>> + /* No limitation as additional
>>> data
>>> will
>>> be
>>> ignored */
>>> + -1,
>>> + /* No device function table */
>>> + NULL,
>>> + /* Base interface address
>>> specified in
>>> driver
>>> */
>>> + NULL,
>>> + /* No cookie implementation */
>>> + 0
>>> + },
>>> +};
>>> +#else
>>> /*
>>> * FPGA programming support for SoC FPGA Cyclone V
>>> */
>>> @@ -107,6 +128,7 @@ static Altera_desc
>>> altera_fpga[] =
>>> {
>>> 0
>>> },
>>> };
>>> +#endif
>>>
>>> /* add device descriptor to FPGA device table */
>>> void socfpga_fpga_add(void)
>>> @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
>>> for (i = 0; i < ARRAY_SIZE(altera_fpga);
>>> i++)
>>> fpga_add(fpga_altera,
>>> _fpga[i]);
>>> }
>>> +
>>> +#else
>>> +
>>> +__weak void socfpga_fpga_add(void)
>>> +{
>>> +}
>> Why is a __weak function defined only in else-
>> statement ?
>>
>> It should be defined always, with a sane default
>> implementation.
> I will remove the empty function in #else-statement and
> define
> the
> default function like this :
>
> /* add device descriptor to FPGA device table */
> void socfpga_fpga_add(void)
> {
> #ifdef CONFIG_FPGA
> int i;
> fpga_init();
> for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> fpga_add(fpga_altera, _fpga[i]);
> #endif
> }
>
> Is that OK?
Can't you have __weak empty implementation of
socfpga_fpga_add()
and
implement a version per platform ? Would that work and
make
sense
?
>>> socfpga_fpga_add() as shown above is a generic function for
>>> adding
>>> FPGA
>>> devices to FPGA driver which applies to all our platforms.
>>> This
>>> is
>>> the
>>> reason why it is defined in misc.c instead of
>>> misc_.c.
>>>
>>> It turned out we already have this defined in misc.h:
>>> #ifdef CONFIG_FPGA
>>> void socfpga_fpga_add(void);
>>> #else
>>> static inline void socfpga_fpga_add(void) {}
>>> #endif
>> Right, if you had one socfpga_fpga_add() per platform +
>> generic
>> empty
>>
Re: [U-Boot] CVE-2018-18439, CVE-2018-18440 - U-Boot verified boot bypass vulnerabilities
On Wed, Nov 14, 2018 at 01:03:12PM +0100, Simon Goldschmidt wrote:
> On 14.11.2018 12:52, Andrea Barisani wrote:
> > On Tue, Nov 13, 2018 at 09:57:23PM +0100, Simon Goldschmidt wrote:
> > > On 06.11.2018 15:51, Andrea Barisani wrote:
> > > > [..]
> > > > The issue can be exploited by several means:
> > > >
> > > > - An excessively large crafted boot image file is parsed by the
> > > > `tftp_handler` function which lacks any size checks, allowing the
> > > > memory
> > > > overwrite.
> > > >
> > > > - A malicious server can manipulate TFTP packet sequence numbers to
> > > > store
> > > > downloaded file chunks at arbitrary memory locations, given that
> > > > the
> > > > sequence number is directly used by the `tftp_handler` function
> > > > to calculate
> > > > the destination address for downloaded file chunks.
> > > >
> > > > Additionally the `store_block` function, used to store downloaded
> > > > file
> > > > chunks in memory, when invoked by `tftp_handler` with a
> > > > `tftp_cur_block`
> > > > value of 0, triggers an unchecked integer underflow.
> > > >
> > > > This allows to potentially erase memory located before the
> > > > `loadAddr` when
> > > > a packet is sent with a null, following at least one valid packet.
> > > Do you happen to have more details on this suggested integer underflow? I
> > > have tried to reproduce it, but I failed to get a memory write address
> > > before 'load_addr'. This is because the 'store_block' function does not
> > > directly use the underflowed integer as a block counter, but adds
> > > 'tcp_block_wrap_offset' to this offset.
> > >
> > > To me it seems like alternating between '0' and 'not 0' for the block
> > > counter could increase memory overwrites, but I fail to see how you can
> > > use
> > > this to store chunks at arbitrary memory locations. All you can do is
> > > subtract one block size from 'tftp_block_wrap_offset'...
> > >
> > > Simon
> > >
> > Hello Simon,
> >
> > the integer underflow can happen if a malicious TFTP server, able to control
> > the TFTP packets sequence number, sends a crafted packet with sequence
> > number
> > set to 0 during a flow.
> >
> > This happens because, within the store_block() function, the 'block'
> > argument
> > is declared as 'int' and when it is invoked inside tftp_handler() (case
> > TFTP_DATA) this value is passed by doing 'tftp_cur_block - 1' (where
> > tftp_cur_block is the sequence number extracted from the tftp packet without
> > any previous check):
> >
> > static inline void store_block(int block, uchar *src, unsigned len)
> > ^ can have negative values (e.g.
> > -1)
> > {
> > ulong offset = block * tftp_block_size + tftp_block_wrap_offset;
> > ^
> > here if block is -1 the result stored onto offset would be a very
> > large unsigned number, due to type conversions
>
> And this is exatclty my point. This might be bad coding style, but for me it
> works: 'block' is an 'int' and is '-1', so 'block * tftp_block_size' is
> '-512'. Now from the code flow in tftp_handler(), it's clear that if we come
> here with tftp_cur_block == 0 (so 'block' is -1), 'tftp_block_wrap_offset'
> is not 0 but some positive value 'x * tftp_block_size' (see function
> 'update_block_number').
>
> So the resulting 'offset' is '-512 + (x * 512)' where 'x > 0'. I still fail
> to see how this can be a very large positive number resulting in an
> effective negative offset or arbitrary write.
>
I understand your point, however what does happen when we enter the 'case
TFTP_DATA' and we are in the first block received, so we trigger
new_transfer() that sets the tftp_block_wrap_offset to 0 *and*
tftp_mcast_active is set?
I don't see any protection for this case for the underflow, am I wrong?
static void new_transfer(void)
{
tftp_prev_block = 0;
tftp_block_wrap = 0;
tftp_block_wrap_offset = 0;
#ifdef CONFIG_CMD_TFTPPUT
tftp_put_final_block_sent = 0;
#endif
}
...
case TFTP_DATA:
if (tftp_state == STATE_SEND_RRQ || tftp_state == STATE_OACK ||
tftp_state == STATE_RECV_WRQ) {
/* first block received */
tftp_state = STATE_DATA;
tftp_remote_port = src;
new_transfer();
^^^
#ifdef CONFIG_MCAST_TFTP
if (tftp_mcast_active) { /* start!=1 common if mcast */
HERE
tftp_prev_block = tftp_cur_block - 1;
} else
#endif
if (tftp_cur_block != 1) { /* Assertion */
puts("\nTFTP error: ");
printf("First block is not block 1 (%ld)\n",
tftp_cur_block);
Re: [U-Boot] [PATCH] rpi: Do not use dtb loaded by firmware
On 11/08/2018 10:05 AM, Jun Nie wrote: Alexander Graf 于2018年11月8日周四 下午4:59写道： On 11/08/2018 09:36 AM, Jun Nie wrote: Do not use dtb loaded by firmware if fit image signature is enabled. So that u-boot.dtb can be used. The u-boot.dtb contains the pulibc key that is to verify Linux kernel FIT image blob. The u-boot.dtb can be loaded by Arm Trusted Firmware(ATF) together with u-boot.bin to make sure the key is protected by ATF. I don't think I fully understand what you're trying to do here. If ATF loads U-Boot as well as the DT, ATF can pass the DT to U-Boot which then ends up as $fdtaddr. If you enable CONFIG_OF_BOARD, it even becomes the input DT for U-Boot. Current usage is that pack u-boot.dtb to u-boot-nodtb.bin so that u-boot can find device tree in the end if u-boot binary. This saves separate signing to u-boot.dtb in ATF. Do you see any benefit to load u-boot.dtb separately and feed $fdtaddr to u-boot? The main reason that is a useful scenario is that you can do modifications in upper layers that propagate. We use it for example to allow people to add dt overlays via config.txt, but you could as well use it to expose changes from ATF into U-Boot (and Linux from there). Alex ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/18] spi: mtk_qspi: add qspi driver for MT7629 SoC
On Wed, 2018-11-14 at 14:34 +0530, Jagan Teki wrote:
> On Fri, Oct 12, 2018 at 12:46 PM Ryder Lee wrote:
> >
> > From: Guochun Mao
> >
> > This patch adds MT7629 qspi driver for accessing SPI NOR flash.
> >
> > Cc: Jagan Teki
> > Signed-off-by: Guochun Mao
> > ---
> > change since v2:
> > - Drop flash commands in the driver.
> > ---
> > drivers/spi/Kconfig| 7 +
> > drivers/spi/Makefile | 1 +
> > drivers/spi/mtk_qspi.c | 359
> > +
> > 3 files changed, 367 insertions(+)
> > create mode 100644 drivers/spi/mtk_qspi.c
> >
> > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> > index 1df6876..f9cf4ba 100644
> > --- a/drivers/spi/Kconfig
> > +++ b/drivers/spi/Kconfig
> > @@ -124,6 +124,13 @@ config MT7621_SPI
> > the SPI NOR flash on platforms embedding this Ralink / MediaTek
> > SPI core, like MT7621/7628/7688.
> >
> > +config MTK_QSPI
> > + bool "Mediatek QSPI driver"
> > + help
> > + Enable the Mediatek QSPI driver. This driver can be
> > + used to access the SPI NOR flash on platforms embedding this
> > + Mediatek QSPI IP core.
> > +
> > config MVEBU_A3700_SPI
> > bool "Marvell Armada 3700 SPI driver"
> > select CLK_ARMADA_3720
> > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
> > index 7242ea7..e5a78f5 100644
> > --- a/drivers/spi/Makefile
> > +++ b/drivers/spi/Makefile
> > @@ -33,6 +33,7 @@ obj-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
> > obj-$(CONFIG_LPC32XX_SSP) += lpc32xx_ssp.o
> > obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o
> > obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
> > +obj-$(CONFIG_MTK_QSPI) += mtk_qspi.o
> > obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o
> > obj-$(CONFIG_MVEBU_A3700_SPI) += mvebu_a3700_spi.o
> > obj-$(CONFIG_MXC_SPI) += mxc_spi.o
> > diff --git a/drivers/spi/mtk_qspi.c b/drivers/spi/mtk_qspi.c
> > new file mode 100644
> > index 000..b510733
> > --- /dev/null
> > +++ b/drivers/spi/mtk_qspi.c
> > @@ -0,0 +1,359 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (c) 2018 MediaTek, Inc.
> > + * Author : guochun@mediatek.com
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* Register Offset */
> > +struct mtk_qspi_regs {
> > + u32 cmd;
> > + u32 cnt;
> > + u32 rdsr;
> > + u32 rdata;
> > + u32 radr[3];
> > + u32 wdata;
> > + u32 prgdata[6];
> > + u32 shreg[10];
> > + u32 cfg[2];
> > + u32 shreg10;
> > + u32 mode_mon;
> > + u32 status[4];
> > + u32 flash_time;
> > + u32 flash_cfg;
> > + u32 reserved_0[3];
> > + u32 sf_time;
> > + u32 pp_dw_data;
> > + u32 reserved_1;
> > + u32 delsel_0[2];
> > + u32 intrstus;
> > + u32 intren;
> > + u32 reserved_2;
> > + u32 cfg3;
> > + u32 reserved_3;
> > + u32 chksum;
> > + u32 aaicmd;
> > + u32 wrprot;
> > + u32 radr3;
> > + u32 dual;
> > + u32 delsel_1[3];
> > +};
> > +
> > +struct mtk_qspi_platdata {
> > + fdt_addr_t reg_base;
> > + fdt_addr_t mem_base;
> > +};
> > +
> > +struct mtk_qspi_priv {
> > + struct mtk_qspi_regs *regs;
> > + unsigned long *mem_base;
> > + u8 op;
> > + u8 tx[3]; /* only record max 3 bytes paras, when it's address. */
> > + u32 txlen; /* dout buffer length - op code length */
> > + u8 *rx;
> > + u32 rxlen;
> > +};
> > +
> > +#define MTK_QSPI_CMD_POLLINGREG_US 50
> > +#define MTK_QSPI_WRBUF_SIZE256
> > +#define MTK_QSPI_COMMAND_ENABLE0x30
> > +
> > +/* NOR flash controller commands */
> > +#define MTK_QSPI_RD_TRIGGERBIT(0)
> > +#define MTK_QSPI_READSTATUSBIT(1)
> > +#define MTK_QSPI_PRG_CMD BIT(2)
> > +#define MTK_QSPI_WR_TRIGGERBIT(4)
> > +#define MTK_QSPI_WRITESTATUS BIT(5)
> > +#define MTK_QSPI_AUTOINC BIT(7)
> > +
> > +#define MTK_QSPI_MAX_RX_TX_SHIFT 0x6
> > +#define MTK_QSPI_MAX_SHIFT 0x8
> > +
> > +#define MTK_QSPI_WR_BUF_ENABLE 0x1
> > +#define MTK_QSPI_WR_BUF_DISABLE0x0
>
> All these bits look flash handling bit's , aren't ?
>
> > +
> > +static int mtk_qspi_execute_cmd(struct mtk_qspi_priv *priv, u8 cmd)
> > +{
> > + u8 tmp;
> > + u8 val = cmd & ~MTK_QSPI_AUTOINC;
> > +
> > + writeb(cmd, >regs->cmd);
> > +
> > + return readb_poll_timeout(>regs->cmd, tmp, !(val & tmp),
> > + MTK_QSPI_CMD_POLLINGREG_US);
> > +}
> > +
> > +static int mtk_qspi_tx_rx(struct mtk_qspi_priv *priv)
> > +{
> > + int len = 1 + priv->txlen + priv->rxlen;
> > + int i, ret, idx;
> > +
> > + if (len > MTK_QSPI_MAX_SHIFT)
> > + return -ERR_INVAL;
> > +
> > + writeb(len * 8, >regs->cnt);
> > +
> > + /* start at PRGDATA5, go down to PRGDATA0 */
> > + idx =
Re: [U-Boot] [PATCH] board: rockchip: rk3399: add Rockpro64 board support
Hi Alexander Graf,
On 11/14/2018 1:17 AM, Alexander Graf wrote:
On 03.11.18 12:28, Akash Gajjar wrote:
Rockpro64 is rk3399 based board from pine64.org. add initial board support for
Rockpro64. complete board support will be added later in upcoming patchsets.
Signed-off-by: Akash Gajjar
---
[...]
diff --git a/board/rockchip/rockpro64/rockpro64.c
b/board/rockchip/rockpro64/rockpro64.c
new file mode 100644
index 00..74c7a56bd5
--- /dev/null
+++ b/board/rockchip/rockpro64/rockpro64.c
@@ -0,0 +1,94 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2018 Akash Gajjar
Given the file is copied from another copyrighted file, you can not just
go and replace the (c) with yours.
Thanks for correction, will add original copyrights.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int board_init(void)
+{
+ struct udevice *pinctrl, *regulator;
+ int ret;
+
+ /*
+* The PWM do not have decicated interrupt number in dts and can
dedicated?
This whole file seems to just be a copy of
board/rockchip/evb_rk3399/evb-rk3399.c. Maybe you can abstract and share
code?
But please double check if what they do is actually necessary on
RockPro64 first.
yes, we have taken evb rk3399 bsp support for reference.
will add only necessary support in v2 patch-sets and submit in couple of
days.
Alex
+* not get periph_id by pinctrl framework, so let's init them here.
+* The PWM2 and PWM3 are for pwm regulater.
+*/
+ ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+ if (ret) {
+ debug("%s: Cannot find pinctrl device\n", __func__);
+ goto out;
+ }
+
+ /* Enable pwm0 for panel backlight */
+ ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM0);
+ if (ret) {
+ debug("%s PWM0 pinctrl init fail! (ret=%d)\n", __func__, ret);
+ goto out;
+ }
+
+ ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM2);
+ if (ret) {
+ debug("%s PWM2 pinctrl init fail!\n", __func__);
+ goto out;
+ }
+
+ ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_PWM3);
+ if (ret) {
+ debug("%s PWM3 pinctrl init fail!\n", __func__);
+ goto out;
+ }
+
+ ret = regulators_enable_boot_on(false);
+ if (ret)
+ debug("%s: Cannot enable boot on regulator\n", __func__);
+
+ ret = regulator_get_by_platname("vcc5v0_host", );
+ if (ret) {
+ debug("%s vcc5v0_host init fail! ret %d\n", __func__, ret);
+ goto out;
+ }
+
+ ret = regulator_set_enable(regulator, true);
+ if (ret) {
+ debug("%s vcc5v0-host-en set fail!\n", __func__);
+ goto out;
+ }
+
+out:
+ return 0;
+}
+
+void spl_board_init(void)
+{
+ struct udevice *pinctrl;
+ int ret;
+
+ ret = uclass_get_device(UCLASS_PINCTRL, 0, );
+ if (ret) {
+ debug("%s: Cannot find pinctrl device\n", __func__);
+ goto err;
+ }
+
+ /* Enable debug UART */
+ ret = pinctrl_request_noflags(pinctrl, PERIPH_ID_UART_DBG);
+ if (ret) {
+ debug("%s: Failed to set up console UART\n", __func__);
+ goto err;
+ }
+
+ preloader_console_init();
+ return;
+err:
+ printf("%s: Error %d\n", __func__, ret);
+
+ /* No way to report error here */
+ hang();
+}
diff --git a/configs/rockpro64-rk3399_defconfig
b/configs/rockpro64-rk3399_defconfig
new file mode 100644
index 00..88422f2db4
--- /dev/null
+++ b/configs/rockpro64-rk3399_defconfig
@@ -0,0 +1,78 @@
+CONFIG_ARM=y
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x4000
+CONFIG_ROCKCHIP_RK3399=y
+CONFIG_TARGET_ROCKPRO64_RK3399=y
+CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000
+CONFIG_DEBUG_UART_BASE=0xFF1A
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_STACK_R_ADDR=0x8
+CONFIG_DEBUG_UART=y
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-rockpro64.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
+CONFIG_CMD_BOOTZ=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_SF=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64"
+CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent
assigned-clocks assigned-clock-rates assigned-clock-parents"
+CONFIG_ENV_IS_IN_MMC=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SYSCON=y
+CONFIG_SPL_SYSCON=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
[U-Boot] [PATCH] configs: at91: add CONFIG_OF_EMBED=y in all defconfigs
U-boot must have dtb built in because at91bootstrap can not load it. Signed-off-by: Radu Pirea --- configs/at91rm9200ek_defconfig | 1 + configs/at91rm9200ek_ram_defconfig | 1 + configs/at91sam9260ek_dataflash_cs0_defconfig | 1 + configs/at91sam9260ek_dataflash_cs1_defconfig | 1 + configs/at91sam9260ek_nandflash_defconfig | 1 + configs/at91sam9261ek_dataflash_cs0_defconfig | 1 + configs/at91sam9261ek_dataflash_cs3_defconfig | 1 + configs/at91sam9261ek_nandflash_defconfig | 1 + configs/at91sam9263ek_dataflash_cs0_defconfig | 1 + configs/at91sam9263ek_dataflash_defconfig | 1 + configs/at91sam9263ek_nandflash_defconfig | 1 + configs/at91sam9263ek_norflash_boot_defconfig | 1 + configs/at91sam9263ek_norflash_defconfig | 1 + configs/at91sam9g10ek_dataflash_cs0_defconfig | 1 + configs/at91sam9g10ek_dataflash_cs3_defconfig | 1 + configs/at91sam9g10ek_nandflash_defconfig | 1 + configs/at91sam9g20ek_2mmc_defconfig | 1 + configs/at91sam9g20ek_2mmc_nandflash_defconfig | 1 + configs/at91sam9g20ek_dataflash_cs0_defconfig | 1 + configs/at91sam9g20ek_dataflash_cs1_defconfig | 1 + configs/at91sam9g20ek_nandflash_defconfig | 1 + configs/at91sam9m10g45ek_mmc_defconfig | 1 + configs/at91sam9m10g45ek_nandflash_defconfig | 1 + configs/at91sam9n12ek_mmc_defconfig| 1 + configs/at91sam9n12ek_nandflash_defconfig | 1 + configs/at91sam9n12ek_spiflash_defconfig | 1 + configs/at91sam9rlek_dataflash_defconfig | 1 + configs/at91sam9rlek_mmc_defconfig | 1 + configs/at91sam9rlek_nandflash_defconfig | 1 + configs/at91sam9x5ek_dataflash_defconfig | 1 + configs/at91sam9x5ek_mmc_defconfig | 1 + configs/at91sam9x5ek_nandflash_defconfig | 1 + configs/at91sam9x5ek_spiflash_defconfig| 1 + configs/at91sam9xeek_dataflash_cs0_defconfig | 1 + configs/at91sam9xeek_dataflash_cs1_defconfig | 1 + configs/at91sam9xeek_nandflash_defconfig | 1 + configs/sama5d27_som1_ek_mmc_defconfig | 1 + configs/sama5d2_ptc_ek_mmc_defconfig | 1 + configs/sama5d2_ptc_ek_nandflash_defconfig | 1 + configs/sama5d2_xplained_mmc_defconfig | 1 + configs/sama5d2_xplained_spiflash_defconfig| 1 + configs/sama5d36ek_cmp_mmc_defconfig | 1 + configs/sama5d36ek_cmp_nandflash_defconfig | 1 + configs/sama5d36ek_cmp_spiflash_defconfig | 1 + configs/sama5d3_xplained_mmc_defconfig | 1 + configs/sama5d3_xplained_nandflash_defconfig | 1 + configs/sama5d3xek_mmc_defconfig | 1 + configs/sama5d3xek_nandflash_defconfig | 1 + configs/sama5d3xek_spiflash_defconfig | 1 + configs/sama5d4_xplained_mmc_defconfig | 1 + configs/sama5d4_xplained_nandflash_defconfig | 1 + configs/sama5d4_xplained_spiflash_defconfig| 1 + configs/sama5d4ek_mmc_defconfig| 1 + configs/sama5d4ek_nandflash_defconfig | 1 + configs/sama5d4ek_spiflash_defconfig | 1 + 55 files changed, 55 insertions(+) diff --git a/configs/at91rm9200ek_defconfig b/configs/at91rm9200ek_defconfig index 6af0118cf5..a2387801f7 100644 --- a/configs/at91rm9200ek_defconfig +++ b/configs/at91rm9200ek_defconfig @@ -25,3 +25,4 @@ CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_KEYBOARD=y CONFIG_OF_LIBFDT=y +CONFIG_OF_EMBED=y diff --git a/configs/at91rm9200ek_ram_defconfig b/configs/at91rm9200ek_ram_defconfig index 2688299db1..4889a8da52 100644 --- a/configs/at91rm9200ek_ram_defconfig +++ b/configs/at91rm9200ek_ram_defconfig @@ -26,3 +26,4 @@ CONFIG_USB=y CONFIG_USB_STORAGE=y CONFIG_USB_KEYBOARD=y CONFIG_OF_LIBFDT=y +CONFIG_OF_EMBED=y diff --git a/configs/at91sam9260ek_dataflash_cs0_defconfig b/configs/at91sam9260ek_dataflash_cs0_defconfig index 7fd844c94b..f756f47fc4 100644 --- a/configs/at91sam9260ek_dataflash_cs0_defconfig +++ b/configs/at91sam9260ek_dataflash_cs0_defconfig @@ -55,3 +55,4 @@ CONFIG_TIMER=y CONFIG_ATMEL_PIT_TIMER=y CONFIG_USB=y CONFIG_USB_STORAGE=y +CONFIG_OF_EMBED=y diff --git a/configs/at91sam9260ek_dataflash_cs1_defconfig b/configs/at91sam9260ek_dataflash_cs1_defconfig index c2fc77d78c..ea844f3cc9 100644 --- a/configs/at91sam9260ek_dataflash_cs1_defconfig +++ b/configs/at91sam9260ek_dataflash_cs1_defconfig @@ -55,3 +55,4 @@ CONFIG_TIMER=y CONFIG_ATMEL_PIT_TIMER=y CONFIG_USB=y CONFIG_USB_STORAGE=y +CONFIG_OF_EMBED=y diff --git a/configs/at91sam9260ek_nandflash_defconfig b/configs/at91sam9260ek_nandflash_defconfig index 19995ab369..e3c305a90f 100644 --- a/configs/at91sam9260ek_nandflash_defconfig +++ b/configs/at91sam9260ek_nandflash_defconfig @@ -55,3 +55,4 @@ CONFIG_TIMER=y CONFIG_ATMEL_PIT_TIMER=y CONFIG_USB=y CONFIG_USB_STORAGE=y +CONFIG_OF_EMBED=y diff --git a/configs/at91sam9261ek_dataflash_cs0_defconfig b/configs/at91sam9261ek_dataflash_cs0_defconfig index 431cf280eb..09e9fc0f47 100644 --- a/configs/at91sam9261ek_dataflash_cs0_defconfig +++
[U-Boot] error: Invalid register name for 'gd'
Hi all,
I am trying to cross-compile the U-boot on my Ubuntu pc cloned from
git clone git://git.denx.de/u-boot.git
with gcc-linaro-6.2.1-2016.11-x86_64_arm-linux-gnueabi compiler. But while
compiling I am getting following error:
./arch/arm/include/asm/global_data.h:110:58: error: invalid register name
for 'gd'
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("x18")
^
cmd/bdinfo.c:14:1: note: in expansion of macro 'DECLARE_GLOBAL_DATA_PTR'
DECLARE_GLOBAL_DATA_PTR;
^~~
scripts/Makefile.build:278: recipe for target 'cmd/bdinfo.o' failed
make[1]: *** [cmd/bdinfo.o] Error 1
Makefile:1408: recipe for target 'cmd' failed
make: *** [cmd] Error 2
Suggest me a way to resolve this error.
Thanks & Regards,
Manoj
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
