Re: [U-Boot] [EXT] [PATCH v2 2/2] arm: ls1028a: use the new flexspi driver
Hi Michael,
> -Original Message-
> From: U-Boot On Behalf Of Michael Walle
> Sent: Saturday, November 2, 2019 11:56 PM
> To: u-boot@lists.denx.de
> Subject: [EXT] [U-Boot] [PATCH v2 2/2] arm: ls1028a: use the new flexspi
> driver
>
> Caution: EXT Email
>
> Also align the fspi node with the kernel one. There is actually no driver
> which
> would match "nxp,dn-fspi".
>
> Signed-off-by: Michael Walle
> ---
> changes since v1:
> - none
>
> arch/arm/dts/fsl-ls1028a.dtsi | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index
> 43a154e8e7..774e477542 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -49,14 +49,16 @@
> <1 10 0x8>; /* Hypervisor PPI, active-low */
> };
>
> - fspi: flexspi@20C {
> - compatible = "nxp,dn-fspi";
> + fspi: flexspi@20c {
> + compatible = "nxp,lx2160a-fspi";
> #address-cells = <1>;
> #size-cells = <0>;
> - reg = <0x0 0x20C 0x0 0x1>,
> - <0x0 0x2000 0x0 0x1000>; /*64MB flash*/
> - reg-names = "FSPI", "FSPI-memory";
> - num-cs = <1>;
> + reg = <0x0 0x20c 0x0 0x1>,
> + <0x0 0x2000 0x0 0x1000>;
> + reg-names = "fspi_base", "fspi_mmap";
> + clocks = < 4 3>, < 4 3>;
> + clock-names = "fspi_en", "fspi";
> + interrupts = <0 25 0x4>;
Please change the interrupts to "" as it avoids
magic numbers.
Reviewed-by: Kuldeep Singh
> status = "disabled";
> };
>
> --
> 2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
On Tue, Nov 5, 2019 at 7:19 AM Rick Chen wrote: > > Hi Anup > > > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel wrote: > > > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > Thanks for the critics. Comments below. > > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > > Hi Rick, > > > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > > wrote: > > > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 fix? > > > > > > > > > > > > > > Yes, it include two fixs. But they will cause one negative result > > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot SPL > > > > > > > > > theoretically, but it still fail somewhere. After dig in > > > > > > > > > and found there is an assumption that hart 0 shall be > > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible issue. > > > > > > > There is a limitation that only hart 0 can be main hart in > > > > > > > OpenSBI. > > > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > > > > Please check the source. > > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are the > > > > > 1. get hart ID. > > > > > 2. determine which route to take based on their ID respectively. > > > > > > > > > > So, I do think OpenSBI has this signature, if you are not willing to > > > > > call it > > > > > a limitation. > > > > > > > > This dependency on hart id #0 was not there until we added > > > > self-relocation > > > > in OpenSBI for FW_DYNAMIC. > > > > > > > > I will try to fix this in OpenSBI but we might end-up having > > > > boot_lottery. > > > > > > I have send a patch to fix this OpenSBI: > > > "[PATCH] firmware: Introduce relocation lottery" > > > > > > Can you try above patch and see if that helps ? > > > > > > It will be great if you can provide Tested-by to my patch as well. > > > > > > > I can not find this patch in mailing list. > Can you provide a hyperlink ? You can try latest riscv/opensbi master. I have tested the patch on SiFive Unleashed multiple times. Regards, Anup > > Thanks > Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [NXP-IMX] please pull imx-master-11-4
Hi Stefano, Please pull imx-master-11-4. This pull request was based on imx/master commit ae8a53ece0ff CI build pass: https://travis-ci.org/MrVan/u-boot/builds/607065958 This pull request contains patches that you dropped from imx/next since blocking CI, and enabling enet for i.MX8MM. The CI was blocked because of Kconfig dependency issue, I squashed https://patchwork.ozlabs.org/patch/1188733/ into https://patchwork.ozlabs.org/patch/1162618/ Fabio, I tried to add your ulp patches, but it not build, so I leave it for now. Stefano could pick up your v3, or I could help later. i.MX8MN SoC support ROM API image download support i.MX8MM enet enabling Thanks, Peng. The following changes since commit ae8a53ece0ff3b1ed686c3e0af14e59973d25db8: imx: nandbcb: add support for writing BCB only (2019-11-03 21:49:49 +0100) are available in the Git repository at: https://github.com/MrVan/u-boot.git imx-master-11-4 for you to fetch changes up to 795f7a18c56da2250079db697d1ee3e130f5bde8: imx: imx8mm-evk: enable ethernet (2019-11-04 18:56:15 +0800) Peng Fan (30): imx8qm: mek: enable dm-spl for pm arm: dts: imx8qxp-mek: add u-boot, dm-spl for lpuart0 arm: dts: imx8qm-mek: add u-boot, dm-spl for lpuart0 misc: imx8: scu: simplify code to make it extendable power: domain: make imx8-power-domain.c legacy power: domain: add i.MX8 scu power domain driver imx: add i.MX8MN kconfig entry imx8mn: support get_cpu_rev imx8m: add clk support for i.MX8MN imx8mn: set BYPASS ID SWAP to avoid AXI bus errors imx: add i.MX8MN PE property imx8mn: add pin header imx: spl: use spl_board_boot_device for i.MX8MN imx: add rom api support imx: cpu: restrict get_boot_device imx8mn: add get_boot_device tools: imx8mimage: add ROM VERSION pinctrl: imx8m: support i.MX8MN tools: imx8m_image: support ddr4 firmware clk: imx: add i.MX8MN ccf driver imx8m: add i.MX8MN ddr4 image cfg file imx: add dtsi for i.MX8MN imx: add i.MX8MN DDR4 board support imx: imx8m: fix boot when CONFIG_$(SPL_)CLK not defined clk: imx8mm: add enet clk clk: imx: imx8mm: add set_parent callback arm: dts: imx8mm: drop assigned clocks for clk node net: Kconfig: FEC: Add dependency on i.MX8M net: fec_mxc: support i.MX8M with CLK_CCF imx: imx8mm-evk: enable ethernet arch/arm/dts/Makefile |1 + arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 13 ++ arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi|8 + arch/arm/dts/imx8mm-evk-u-boot.dtsi |7 + arch/arm/dts/imx8mm-evk.dts |6 +- arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi| 92 ++ arch/arm/dts/imx8mn-ddr4-evk.dts| 221 +++ arch/arm/dts/imx8mn-pinfunc.h | 646 + arch/arm/dts/imx8mn.dtsi| 712 +++ arch/arm/include/asm/arch-imx/cpu.h |1 + arch/arm/include/asm/arch-imx8m/clock.h |2 +- arch/arm/include/asm/arch-imx8m/clock_imx8mm.h | 78 arch/arm/include/asm/arch-imx8m/imx8mn_pins.h | 763 + arch/arm/include/asm/mach-imx/iomux-v3.h|2 +- arch/arm/include/asm/mach-imx/sys_proto.h | 35 arch/arm/mach-imx/Kconfig |4 + arch/arm/mach-imx/Makefile |2 + arch/arm/mach-imx/cpu.c |4 +- arch/arm/mach-imx/imx8m/Kconfig | 11 ++ arch/arm/mach-imx/imx8m/Makefile|2 +- arch/arm/mach-imx/imx8m/clock_slice.c |4 +- arch/arm/mach-imx/imx8m/imximage-8mn-ddr4.cfg | 17 ++ arch/arm/mach-imx/imx8m/soc.c | 68 ++- arch/arm/mach-imx/spl.c |2 +- arch/arm/mach-imx/spl_imx_romapi.c | 292 ++ board/freescale/imx8mm_evk/imx8mm_evk.c | 37 board/freescale/imx8mn_evk/Kconfig | 14 ++ board/freescale/imx8mn_evk/MAINTAINERS |6 + board/freescale/imx8mn_evk/Makefile | 12 ++ board/freescale/imx8mn_evk/ddr4_timing.c| 1214 ++ board/freescale/imx8mn_evk/imx8mn_evk.c | 29 +++ board/freescale/imx8mn_evk/spl.c| 123 + board/freescale/imx8qm_mek/spl.c| 16 -- configs/imx8mm_evk_defconfig
Re: [U-Boot] [PATCH v2 6/6] mx7ulp: Add support for Embedded Artists COM board
> Subject: [PATCH v2 6/6] mx7ulp: Add support for Embedded Artists COM > board Hi Fabio, Seems you not add dts files. CI build fail arm: + mx7ulp_com +make[3]: *** No rule to make target 'arch/arm/dts/imx7ulp-com.dtb', needed by 'dtbs'. Stop. +make[2]: *** [arch-dtbs] Error 2 +make[1]: *** [dts/dt.dtb] Error 2 +make: *** [sub-make] Error 2 Thanks, Peng. > > The Embedded Artists COM board is based on NXP i.MX7ULP. > > It has a BD70528 PMIC from Rohm with discrete DCDC powering option and > improved current observability (compared to the existing NXP i.MX7ULP EVK). > > Add the initial support for the board. > > Signed-off-by: Fabio Estevam > --- > Changes since v1: > - Lower the DDR frequency inside DCD as it is safer (Ye Li) > - Drop CONFIG_IMX7ULP_LOWER_DDR_FREQUENCY=y > > arch/arm/dts/Makefile| 3 +- > arch/arm/mach-imx/mx7ulp/Kconfig | 6 ++ > board/ea/mx7ulp_com/Kconfig | 12 +++ > board/ea/mx7ulp_com/MAINTAINERS | 6 ++ > board/ea/mx7ulp_com/Makefile | 6 ++ > board/ea/mx7ulp_com/imximage.cfg | 137 > +++ > board/ea/mx7ulp_com/mx7ulp_com.c | 48 +++ > configs/mx7ulp_com_defconfig | 58 + > include/configs/mx7ulp_com.h | 107 > 9 files changed, 382 insertions(+), 1 deletion(-) create mode 100644 > board/ea/mx7ulp_com/Kconfig create mode 100644 > board/ea/mx7ulp_com/MAINTAINERS create mode 100644 > board/ea/mx7ulp_com/Makefile create mode 100644 > board/ea/mx7ulp_com/imximage.cfg create mode 100644 > board/ea/mx7ulp_com/mx7ulp_com.c create mode 100644 > configs/mx7ulp_com_defconfig create mode 100644 > include/configs/mx7ulp_com.h > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index > 6a7dbb6309..c5c29dbcd0 100644 > --- a/arch/arm/dts/Makefile > +++ b/arch/arm/dts/Makefile > @@ -645,7 +645,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \ > imx7d-pico-hobbit.dtb > > > -dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb > +dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \ > + imx7ulp-evk.dtb > > dtb-$(CONFIG_ARCH_IMX8) += \ > fsl-imx8qm-apalis.dtb \ > diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig > b/arch/arm/mach-imx/mx7ulp/Kconfig > index 138c58363f..6680f856c5 100644 > --- a/arch/arm/mach-imx/mx7ulp/Kconfig > +++ b/arch/arm/mach-imx/mx7ulp/Kconfig > @@ -15,6 +15,11 @@ choice > prompt "MX7ULP board select" > optional > > +config TARGET_MX7ULP_COM > + bool "Support MX7ULP COM board" > + select MX7ULP > + select SYS_ARCH_TIMER > + > config TARGET_MX7ULP_EVK > bool "Support mx7ulp EVK board" > select MX7ULP > @@ -22,6 +27,7 @@ config TARGET_MX7ULP_EVK > > endchoice > > +source "board/ea/mx7ulp_com/Kconfig" > source "board/freescale/mx7ulp_evk/Kconfig" > > endif > diff --git a/board/ea/mx7ulp_com/Kconfig b/board/ea/mx7ulp_com/Kconfig > new file mode 100644 index 00..90883aced4 > --- /dev/null > +++ b/board/ea/mx7ulp_com/Kconfig > @@ -0,0 +1,12 @@ > +if TARGET_MX7ULP_COM > + > +config SYS_BOARD > + default "mx7ulp_com" > + > +config SYS_VENDOR > + default "ea" > + > +config SYS_CONFIG_NAME > + default "mx7ulp_com" > + > +endif > diff --git a/board/ea/mx7ulp_com/MAINTAINERS > b/board/ea/mx7ulp_com/MAINTAINERS new file mode 100644 index > 00..3f69511b1a > --- /dev/null > +++ b/board/ea/mx7ulp_com/MAINTAINERS > @@ -0,0 +1,6 @@ > +MX7ULPCOM BOARD > +M: Fabio Estevam > +S: Maintained > +F: board/ea/mx7ulp_com/ > +F: include/configs/mx7ulp_com.h > +F: configs/mx7ulp_com_defconfig > diff --git a/board/ea/mx7ulp_com/Makefile > b/board/ea/mx7ulp_com/Makefile new file mode 100644 index > 00..b3b230b172 > --- /dev/null > +++ b/board/ea/mx7ulp_com/Makefile > @@ -0,0 +1,6 @@ > +# (C) Copyright 2016 Freescale Semiconductor, Inc. > +# > +# SPDX-License-Identifier: GPL-2.0+ > +# > + > +obj-y := mx7ulp_com.o > diff --git a/board/ea/mx7ulp_com/imximage.cfg > b/board/ea/mx7ulp_com/imximage.cfg > new file mode 100644 > index 00..e405d758b5 > --- /dev/null > +++ b/board/ea/mx7ulp_com/imximage.cfg > @@ -0,0 +1,137 @@ > +/* > + * Copyright (C) 2016 Freescale Semiconductor, Inc. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + * > + * Refer docs/README.imxmage for more details about how-to configure > + * and create imximage boot image > + * > + * The syntax is taken as close as possible with the kwbimage */ > + > +#define __ASSEMBLY__ > +#include > + > +/* image version */ > + > +IMAGE_VERSION 2 > + > +/* > + * Boot Device : one of > + * spi/sd/nand/onenand, qspi/nor > + */ > + > +BOOT_FROMsd > + > +#ifdef CONFIG_USE_IMXIMG_PLUGIN > +/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/ > +PLUGIN board/freescale/mx7ulp_evk/plugin.bin 0x2F02 > +#else > + > +#ifdef CONFIG_SECURE_BOOT > +CSF CONFIG_CSF_SIZE > +#endif > +/* > + * Device Configuration Data (DCD) > + * > + * Each entry must have the format: > + * Addr-type AddressValue
Re: [U-Boot] [PATCH v3 00/18] misc: Add AVS class 0 support for AM6
On 24/10/19 3:45 PM, Lokesh Vutla wrote: On 24/10/19 3:00 PM, Keerthy wrote: Adaptive Voltage Scaling is a technology used in TI SoCs to optimize the operating voltage based on characterization data written to efuse during production. Add support for Adaptive Voltage scaling class 0 support for AM6 family of devices. Adaptive voltage scaling class 0 implies that optimized voltage values for a particular OPP of a particular voltage domain are read from Efuse and programmed on the pmic/regulator. Tested on AM654-EVM for MPU @800 MHz. Tested on J721e-evm for MPU. For the entire series: Reviewed-by: Lokesh Vutla Thanks and regards, Lokesh Tom, If no further comments can this series be pulled in? - Keerthy The series is based on top of the branch: https://github.com/lokeshvutla/u-boot/tree/devel/j721e-full-boot Changes in v3: * Extended the support for j721e-evm. * Moved vtm node under r5-board dts. Changes in v2: * Avoided creation of new uclass. AVS driver is now under misc. Keerthy (11): clk: clk-ti-sci: Notify AVS driver upon setting clock rate misc: k3_avs: Add j721e support power: pmic: tps65941: Add support for tps65941 family of PMICs power: regulator: tps65941: add regulator support arm: mach-k3: am6_init: Initialize AVS class 0 arm: mach-k3: j721e_init: Initialize avs class 0 arm: dts: k3-am654-r5-base-board: Add VTM node arm: dts: k3-j721e-r5-common-proc-board: Add VTM node arm: dts: k3-j721e-r5-common: Add tps65941 node and dependent wkup_i2c0 node arm: dts: k3-j721e-r5-common-proc-board: Hook buck12_reg to vtm supply configs: j721e_evm_r5_defconfig: Enable AVS Class 0 & dependent configs Tero Kristo (7): misc: k3_avs: add driver for K3 Adaptive Voltage Scaling Class 0 power: regulator: tps6236x: add support for tps6236x regulators arm: dts: k3-am654-r5-base-board: enable wkup_i2c0 driver for spl arm: dts: k3-am654-r5-base-board: add supply rail for MPU arm: dts: k3-am654-r5-base-board: enable wkup_vtm0 node and link in supplies configs: am65x_evm_r5_defconfig: Enable TPS62363 regulator support configs: am65x_evm_r5_defconfig: Enable AVS class 0 support arch/arm/dts/k3-am654-r5-base-board.dts | 27 ++ arch/arm/dts/k3-j721e-mcu-wakeup.dtsi | 11 + .../arm/dts/k3-j721e-r5-common-proc-board.dts | 44 ++ arch/arm/mach-k3/am6_init.c | 7 + arch/arm/mach-k3/j721e_init.c | 7 + configs/am65x_evm_r5_defconfig| 2 + configs/j721e_evm_r5_defconfig| 9 + drivers/clk/clk-ti-sci.c | 5 + drivers/misc/Kconfig | 9 + drivers/misc/Makefile | 1 + drivers/misc/k3_avs.c | 388 + drivers/power/pmic/Kconfig| 7 + drivers/power/pmic/Makefile | 1 + drivers/power/pmic/tps65941.c | 83 drivers/power/regulator/Kconfig | 20 + drivers/power/regulator/Makefile | 2 + drivers/power/regulator/tps62360_regulator.c | 123 ++ drivers/power/regulator/tps65941_regulator.c | 407 ++ include/k3-avs.h | 30 ++ include/power/tps65941.h | 26 ++ 20 files changed, 1209 insertions(+) create mode 100644 drivers/misc/k3_avs.c create mode 100644 drivers/power/pmic/tps65941.c create mode 100644 drivers/power/regulator/tps62360_regulator.c create mode 100644 drivers/power/regulator/tps65941_regulator.c create mode 100644 include/k3-avs.h create mode 100644 include/power/tps65941.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/19] efi_loader: non-volatile variables support
Wolfgang,
On Mon, Nov 04, 2019 at 05:00:03PM +0100, Wolfgang Denk wrote:
> Dear Takahiro,
>
> In message <20191101060434.gv10...@linaro.org> you wrote:
> >
> > > This is even worse, as instead of adding a single argument to a
> > > function call you are adding two full fucntion calls.
> > >
> > > But why would that be needed?
> > >
> > > U-Boot is strictly single tasking. You always know what the current
> > > context is, and nobody will change it behind your back.
> > >
> > > And UEFI functions are not being called in random places, they are
> > > limited to a small set of UEFI commands, right? So why do you not
> > > just enter UEFI context when you start executing UEFI code, and
> > > restore the rpevious state when returning to non-UEFI U-Boot?
> >
> > Can you elaborate What you mean by "entering UEFI context"?
>
> You wrote:
>
> | So do you always admit the following coding?
> | ===8<===
> | (in some UEFI function)
> | ...
> | old_ctx = env_set_context(ctx_uefi);
> | env_set(var, value);
> | env_set_context(old_ctx);
> | ...
> | ===>8===
>
> In this code, the function call ``env_set_context(ctx_uefi)'' would
> enter the UEFI context, right? This is what I mean.
My point is not there. See below.
> > What I'm thinking of here is that we would add one more member field, which
> > is a pointer to my "env_context," in GD and change it in env_set_context().
> > This can be defined even as an inline function.
>
> Yes, this is OK - I think I understood this already.
So we get one step closer.
> What I mean is that such a call of env_set_context() is not needed
> for each and every call of other env_*() functions.
>
> If I understand correctly, only the UEFI specific commands will
> actually care about UEFI contexts - most likely no code outside
> cmd/nvedit_efi.c ?
No. There are a couple of reasons:
1) Other commands include cmd/bootefi.c (and cmd/efidebug.c).
2) Any EFI application, once kicked off, can directly call EFI APIs.
3) Bunch of EFI features (either services or protocols) fundamentally
reply on U-Boot native functionality, including devices (disk,
network, console, ...), file systems and so on.
So calling such UEFI interfaces may eventually end up with invoking
env_*() *indirectly*. I don't come up with good examples (probably,
network is a candidate) now but such a situation will be quite likely
and we should not exclude such a possibility in the future.
> So you have pretty clear entry and exit points into and from the
> UEFI world, and it should be sufficient to set and restore this
> context only then.
My point is what entry or exit points are.
They cannot be at each command, but *each* API.
So, let me repeat this example:
===8<===
(in some UEFI function)
...
old_ctx = env_set_context(ctx_uefi);
env_set(var, value);
env_set_context(old_ctx);
...
===>8===
This can be at most relaxed to:
===8<===
some_efi_api(...)
{
old_ctx = env_set_context(ctx_uefi);
...
(env_get(var1);)
...
env_set(var2, value);
...
env_set_context(old_ctx);
return;
}
===>8===
It is merely a matter of optimization.
This is the reason that I want to introduce env_set_context().
Thanks,
-Takahiro Akashi
> > I don't see why you deny such a simple solution with lots of flexibility.
>
> I am concerned about code size and execution speed. So far, you did
> not provide any such numbers, even though I repeatedly asked for the
> size impact, especially for non-UEFI systems.
>
> Please keep in mind that there are many cases where we need access
> to the environment already in SPL, and on all systems where security
> plays any role we must have the same set of features enabled for the
> environment code in SPL and TPL (if these need access to the
> envronment) as in U-Boot proper, and memory is a precious resource
> there.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> You may call me by my name, Wirth, or by my value, Worth.
> - Nicklaus Wirth
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net/phy: Fix phy_connect() for phy addr 0
Fix 'mask' calculation in phy_connect() for phy addr '0'.
'mask' is getting set to '0x' for phy addr '0'
in phy_connect() whereas expected value is '0'.
Signed-off-by: Priyanka Jain
---
drivers/net/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index ae37dd6c1e..419e6869c0 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -952,7 +952,7 @@ struct phy_device *phy_connect(struct mii_dev *bus, int
addr,
#endif
{
struct phy_device *phydev = NULL;
- uint mask = (addr > 0) ? (1 << addr) : 0x;
+ uint mask = (addr >= 0) ? (1 << addr) : 0x;
#ifdef CONFIG_PHY_FIXED
phydev = phy_connect_fixed(bus, dev, interface);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Monday, November 4, 2019 9:22:16 AM PST Tom Rini wrote: > On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote: > > Hi Wolfgang, > > > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > > > Dear Aaron, > > > > > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > > > Currently we are using 39MB under arch/mips. I think I can easily cut > > > > this > > > > down to 15MB or smaller, especially by moving some code here to the > > > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > > > > > It will still be a large SoC, though. > > > > > > Have you already looked at formal requirements, like coding style > > > etc.? Did you ever run your additions through checkpatch.pl, for > > > example? > > > > We did follow the formal coding style. Everything will go through > > checkpatch. My biggest complaint about it is the 80 columns for debug and > > other print statements. > > checkpatch doesn't complain about those when they use standard logging > functions, however. It complains plenty about printf(), debug() and a number of other standard U- Boot logging calls. Regards, Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: Rename roc-rk3399-pc -> roc-pc-rk3399 defconfig【请注意，邮件由u-boot-boun...@lists.denx.de代发】
The mainline uses 'rk3399-*', so there're rk3399-firefly.dts,
rk3399-roc-pc.dts, rk3399-khadas-edge.dts, etc. Shall we follow the kernel
convention, or add another roc-pc-rk3399 to the matrix? I prefer to keep it as
it is.
"Jonathan A. Kollasch" writes:
> On Sat, Nov 02, 2019 at 10:19:02AM +0530, Jagan Teki wrote:
>> roc-rk3399-pc_defconfig is committed in below
>>
>> commit <8a681f4c5aa15db51ad0209734859c9fe7c29cfd> ("rockchip: rk3399:
>
>> Add ROC-RK3399-PC support")
>>
>> which doesn't follow the existing defconfigs on rk3399.
>>
>> So, rename as followed with other rk3399 defconfigs.
>>
>> Cc: Levin Du
>> Signed-off-by: Jagan Teki
>> ---
>
> This strikes me as wrong, as the existing name is the actual name of the
> board.
>
> https://libre.computer/products/boards/roc-rk3399-pc/
>
> Jonathan Kollasch
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
Levin Du
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Monday, November 4, 2019 8:23:08 AM PST Tom Rini wrote: > On Mon, Nov 04, 2019 at 04:44:18PM +0100, Wolfgang Denk wrote: > > Dear Aaron, > > > > In message <2710076.TiSPtmOvtb@flash> you wrote: > > > > What exactly do you need this for? Why don't you just link your > > > > code with the rest of U-Boot? > > > > > > We need it to obtain and modify the phy parameters. This is a custom 25G > > > gearbox that needs a lot of hand holding. This may end up being a low > > > priority (not the gearbox, but the API). It's only a few hundred lines > > > of code (the API). > > > > Again you don't answer my question. Why do you need a special new > > API for such code? Why do you not just link that code with the rest > > of U-Boot? > > > > It has been mentioned before, but just to be sure: this code which > > uses your new API is licensed under a GPLv2 conforming lincense? > > And, to be blunt, if it is not, handling your non-GPLv2 applications > via an EFI binary is the way forward, not extending the U-Boot binary > ABI, in my opinion. To be blunt, the current U-Boot EFI driver does not provide the required functionality. It would need to be extended in order to work. In addition, spinlocks would be required in order to handle the case of reentrancy. Also, how does the EFI loader deal with loading multiple applications across multiple cores? The block support is the least important part of it. There are several other services not related to block devices or network calls. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Wolfgang, On Monday, November 4, 2019 7:44:18 AM PST Wolfgang Denk wrote: > Dear Aaron, > > In message <2710076.TiSPtmOvtb@flash> you wrote: > > > What exactly do you need this for? Why don't you just link your > > > code with the rest of U-Boot? > > > > We need it to obtain and modify the phy parameters. This is a custom 25G > > gearbox that needs a lot of hand holding. This may end up being a low > > priority (not the gearbox, but the API). It's only a few hundred lines of > > code (the API). > > Again you don't answer my question. Why do you need a special new > API for such code? Why do you not just link that code with the rest > of U-Boot? The code in question that is calling the API is not GPL and hence cannot be linked with U-Boot though the phy code is GPL. The applications that are calling also have their own virtual memory configuration and there can be multiple applications running on multiple cores that can make simultaneous calls. Because of the way the phy must be maintained with a lot of state information, the code controlling it cannot be spread between the separate independent applications which run on their own dedicated cores and address spaces. The API I wrote takes care of the required context switching and provides the services for these applications, such as control of the phy, access to devices like eMMC, tuning our QLM interfaces (this code is required for U-Boot networking anyway), etc. There is no linking. Only a call table descriptor is published in a named block of memory. The API also provides the necessary spinlocks and switch stacks. The code in question adds around 36K in total, so it is fairly small. The main differences are the addition of a number of calls that are unique to our needs in addition to the method of calling since a context switch is required in addition to the spinlocks. The phy in question also does not fit in the normal phy framework. It doesn't even communicate with SMI. It is a complex gearbox where there needs to be interaction between applications and the gearbox where some code runs on the phy itself but a lot needs to be external. The API also provides a number of other services such as access to and saving environment variables as well as access to block devices and filesystems. It is centralized in U-Boot because 1) the functionality is already available in U-Boot which is in memory anyway and 2) it's centralized and accessible by all applications so it can safely provide services to multiple applications simultaneously. These applications are primarily bare-metal applications. It may be that this functionality isn't needed. I will try and remove it if I can. > > It has been mentioned before, but just to be sure: this code which > uses your new API is licensed under a GPLv2 conforming lincense? > There should be no need. None of the code is linked against U-Boot, either at compile time nor at runtime. The application doesn't even know where it is located except by looking for a named block of memory. This is another thing we make use of in Octeon. There is a concept of named blocks in memory. These named blocks are used by U-Boot, simple executive applications and the Linux kernel. This allows physical memory to be partitioned between Linux and Simple Executive applications as well as providing some blocks that are used by some hardware blocks. I believe this support is already in the upstream Linux kernel for Octeon. > Best regards, > > Wolfgang Denk Regards, Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Anup > > On Thu, Oct 31, 2019 at 1:42 PM Anup Patel wrote: > > > > > > On Thu, Oct 31, 2019 at 6:30 AM Alan Kao wrote: > > > > > > > > Hi Bin, > > > > > > > > Thanks for the critics. Comments below. > > > > On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote: > > > > > Hi Rick, > > > > > > > > > > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen > > > > > wrote: > > > > > > > > > > > > Hi Bin > > > > > > > > > > > > > > > > > > > > Hi Rick, > > > > > > > > > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote: > > > > > > > > > > > > > > > > From: Rick Chen > > > > > > > > > > > > > > > > It will work fine due to hart 0 always will be main > > > > > > > > hart coincidentally. When develop SPL flow, I try to > > > > > > > > force other harts to be main hart. And it will go > > > > > > > > wrong in sending IPI flow. So fix it. > > > > > > > > > > > > > > Fix what? Does this commit contain 2 fixes, or just 1 fix? > > > > > > > > > > > > Yes, it include two fixs. But they will cause one negative result > > > > > > that only hart 0 can send ipi to other harts. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Having this fix, any hart can be main hart in U-Boot SPL > > > > > > > > theoretically, but it still fail somewhere. After dig in > > > > > > > > and found there is an assumption that hart 0 shall be > > > > > > > > main hart in OpenSbi. > > > > > > > > > > > > > > So does this mean there is a bug in OpenSBI too? > > > > > > > > > > > > I am not sure if it is a bug. Maybe it is a compatible issue. > > > > > > There is a limitation that only hart 0 can be main hart in OpenSBI. > > > > > > > > > > I don't think OpenSBI has such limitation. > > > > > > > > > > > > > Please check the source. > > > > https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54 > > > > > > > > Apparently, the FIRST TWO LINEs of the initialization are the > > > > 1. get hart ID. > > > > 2. determine which route to take based on their ID respectively. > > > > > > > > So, I do think OpenSBI has this signature, if you are not willing to > > > > call it > > > > a limitation. > > > > > > This dependency on hart id #0 was not there until we added self-relocation > > > in OpenSBI for FW_DYNAMIC. > > > > > > I will try to fix this in OpenSBI but we might end-up having boot_lottery. > > > > I have send a patch to fix this OpenSBI: > > "[PATCH] firmware: Introduce relocation lottery" > > > > Can you try above patch and see if that helps ? > > > > It will be great if you can provide Tested-by to my patch as well. > > > I can not find this patch in mailing list. Can you provide a hyperlink ? Thanks Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] drivers: Add a new framework for multiplexer devices
+Alex who once worked in MUX on LS1028 IIRC. On Wed, Oct 2, 2019 at 8:47 PM Jean-Jacques Hiblot wrote: > > Add a new subsystem that handles multiplexer controllers. The API is the > same as in Linux. > > Signed-off-by: Jean-Jacques Hiblot > --- > > drivers/Kconfig | 2 + > drivers/Makefile | 1 + > drivers/mux/Kconfig | 7 + > drivers/mux/Makefile | 6 + > drivers/mux/mux-uclass.c | 296 ++ > include/dm/uclass-id.h| 1 + > include/dt-bindings/mux/mux.h | 17 ++ > include/mux-internal.h| 80 + > include/mux.h | 114 + > 9 files changed, 524 insertions(+) > create mode 100644 drivers/mux/Kconfig > create mode 100644 drivers/mux/Makefile > create mode 100644 drivers/mux/mux-uclass.c > create mode 100644 include/dt-bindings/mux/mux.h > create mode 100644 include/mux-internal.h > create mode 100644 include/mux.h > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: sync with kernel device tree for Phycore SoM
> Subject: [PATCH] imx: sync with kernel device tree for Phycore SoM
>
> Sync the Linux Kernel 5.4-rc6 device tree for Phytec Phycore SoM and Segin
> board based on imx6UL and imx6ULL.
>
> Changes includes Phytec naming convention for the devicetree files.
>
> Signed-off-by: Parthiban Nallathambi
Acked-by: Peng Fan
> ---
> arch/arm/dts/Makefile | 4 +-
> arch/arm/dts/imx6ul-phycore-segin.dts | 81
> ...on.dtsi => imx6ul-phytec-phycore-som.dtsi} | 130 +++
> .../dts/imx6ul-phytec-segin-ff-rdk-nand.dts | 93 +
> .../dts/imx6ul-phytec-segin-peb-eval-01.dtsi | 57 +++
> arch/arm/dts/imx6ul-phytec-segin.dtsi | 346
> ++
> arch/arm/dts/imx6ull-phycore-segin.dts| 70
> arch/arm/dts/imx6ull-phytec-phycore-som.dtsi | 24
> ++ .../dts/imx6ull-phytec-segin-ff-rdk-emmc.dts | 93
> + .../dts/imx6ull-phytec-segin-peb-eval-01.dtsi | 19 +
> arch/arm/dts/imx6ull-phytec-segin.dtsi| 38 ++
> board/phytec/pcl063/MAINTAINERS | 12 +-
> configs/phycore_pcl063_defconfig | 3 +-
> configs/phycore_pcl063_ull_defconfig | 2 +-
> 14 files changed, 732 insertions(+), 240 deletions(-) delete mode 100644
> arch/arm/dts/imx6ul-phycore-segin.dts
> rename arch/arm/dts/{pcl063-common.dtsi =>
> imx6ul-phytec-phycore-som.dtsi} (56%) create mode 100644
> arch/arm/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
> create mode 100644 arch/arm/dts/imx6ul-phytec-segin-peb-eval-01.dtsi
> create mode 100644 arch/arm/dts/imx6ul-phytec-segin.dtsi
> delete mode 100644 arch/arm/dts/imx6ull-phycore-segin.dts
> create mode 100644 arch/arm/dts/imx6ull-phytec-phycore-som.dtsi
> create mode 100644 arch/arm/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts
> create mode 100644 arch/arm/dts/imx6ull-phytec-segin-peb-eval-01.dtsi
> create mode 100644 arch/arm/dts/imx6ull-phytec-segin.dtsi
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 47978e7685..935b661284 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -621,14 +621,14 @@ dtb-$(CONFIG_MX6UL) += \
> imx6ul-9x9-evk.dtb \
> imx6ul-9x9-evk.dtb \
> imx6ul-liteboard.dtb \
> - imx6ul-phycore-segin.dtb \
> + imx6ul-phytec-segin-ff-rdk-nand.dtb \
> imx6ul-pico-hobbit.dtb \
> imx6ul-pico-pi.dtb
>
> dtb-$(CONFIG_MX6ULL) += \
> imx6ull-14x14-evk.dtb \
> imx6ull-colibri.dtb \
> - imx6ull-phycore-segin.dtb \
> + imx6ull-phytec-segin-ff-rdk-emmc.dtb \
> imx6ull-dart-6ul.dtb \
> imx6ulz-14x14-evk.dtb
>
> diff --git a/arch/arm/dts/imx6ul-phycore-segin.dts
> b/arch/arm/dts/imx6ul-phycore-segin.dts
> deleted file mode 100644
> index 7d68bf8430..00
> --- a/arch/arm/dts/imx6ul-phycore-segin.dts
> +++ /dev/null
> @@ -1,81 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2018 Collabora Ltd.
> - *
> - * Based on dts[i] from Phytec barebox port:
> - * Copyright (C) 2016 PHYTEC Messtechnik GmbH
> - * Author: Christian Hemp
> - *
> - * The code contained herein is licensed under the GNU General Public
> - * License. You may obtain a copy of the GNU General Public License
> - * Version 2 or later at the following locations:
> - *
> - *
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.o
> pensource.org%2Flicenses%2Fgpl-license.htmldata=02%7C01%7Cpeng
> .fan%40nxp.com%7Cb5436c55ac684a693cf308d76157d5a3%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C1%7C637084902183324601sdata
> =3jSUWElygGkm68v%2BnCz%2BoNJDlFgqGFQ5TtHXR3ZrkhE%3Dreser
> ved=0
> - *
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.g
> nu.org%2Fcopyleft%2Fgpl.htmldata=02%7C01%7Cpeng.fan%40nxp.co
> m%7Cb5436c55ac684a693cf308d76157d5a3%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C1%7C637084902183324601sdata=iUmn4qiL0Oyl
> PygYqMtZB2MNoToAhppXpwdHwFFBdyQ%3Dreserved=0
> - */
> -
> -/dts-v1/;
> -
> -#include "imx6ul.dtsi"
> -#include "pcl063-common.dtsi"
> -
> -/ {
> - model = "Phytec phyBOARD-i.MX6UL-Segin SBC";
> - compatible = "phytec,phyboard-imx6ul-segin", "phytec,imx6ul-pcl063",
> - "fsl,imx6ul";
> -};
> -
> - {
> - status = "okay";
> -};
> -
> - {
> - i2c_rtc: rtc@68 {
> - compatible = "microcrystal,rv4162";
> - reg = <0x68>;
> - status = "okay";
> - };
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_uart5>;
> - uart-has-rtscts;
> - status = "okay";
> -};
> -
> - {
> - pinctrl-names = "default";
> - pinctrl-0 = <_usb_otg1_id>;
> - dr_mode = "otg";
> - srp-disable;
> - hnp-disable;
> - adp-disable;
> - status = "okay";
> -};
> -
> - {
> - dr_mode = "host";
> - disable-over-current;
> - status = "okay";
> -};
> -
> - {
> - pinctrl-names = "default";
> -
> - pinctrl_uart5: uart5grp {
> - fsl,pins = <
> - MX6UL_PAD_UART5_TX_DATA__UART5_DCE_TX 0x1b0b1
>
Re: [U-Boot] [EXT] Re: [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX
Hi Tim, On Thursday, October 31, 2019 12:12:34 PM PST Tim Harvey wrote: > On Wed, Oct 30, 2019 at 5:04 PM Aaron Williams wrote: > > Hi Tim, > > > > I think I can answer some of your questions. > > > > On Wednesday, October 30, 2019 10:06:41 AM PDT Tim Harvey wrote: > > > External Email > > > > > > -- > > > > > > On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati > > > > wrote: > > > > This series will add support for OcteonTX and OcteonTX2 processsor > > > > based > > > > platforms. The Marvell/Cavium Octeon-TX 64-bit ARM based SoCs include > > > > the CN80XX, CN81XX and CN83XX while Octeon-TX2 64-bit ARM based SoCs > > > > include support for CN96XX and CN95XX. > > > > These SoC's have peripheral drivers based on PCI ECAM. > > > > > > > > Patches > > > > [1 -10] Add requied changes to PCI framework > > > > > > > > - [6] Add support for multi-memory region range > > > > - [7] EA in bridges > > > > - [8] SR-IOV > > > > > > > > [12] Add driver model support for RTC DS1337 driver > > > > [15 - 17] AHCI changes > > > > [18 - 27] Add OcteonTX drivers > > > > [28 - 29] Add OcteonTX/TX2 board files and configurations > > > > > > Suneel, > > > > > > Thanks for submitting this series! > > > > > > I've applied and built this and am testing on the Gateworks Newport > > > boards with the CN802x/CN803x (octeontx_81xx) and this is what I've > > > found: > > > - I get hung in the smc_call from smc_dram_size which your calling > > > with the function id of 0xc2000301. The older U-Boot from the Cavium > > > OcteonTX SDK-6.2.0-p3 used 0x43000301 and this works for me. Is there > > > a difference in our ATF version? > > > > ATF has indeed changed significantly. The current U-Boot requires an > > up-to- > > date ATF. I recall this was one of the changes we made with regards to > > getting the size of memory. > > What ATF should I be using? Is Marvell merging patches to the ATF > required for OcteonTX? > > > > - configs/octeontx_81xx_defconfig - I have several changes I want to > > > make here, but perhaps some of these would warrant a custom config for > > > my boards > > > > > > - you assume there is only a SPI NOR flash for env which we > > > > > > personally don't use. The env system supports multiple env types so we > > > could just enable MMC as well as SPI but then I find all the > > > hard-coded CONFIG_ENV_* defines restrictive. I wonder if anyone has > > > defined a way for these to come from device-tree? > > > > We have not tested loading the environment from eMMC. It would be nice if > > the environment location could come from the device tree. > > I tested it and it works fine. > > The mmc-env partition, offset, and offset-redundant can be set via dts > (doc/device-tree-bindings/config.txt and env/mmc.c) and I am setting > these in my dts. I'll look into expanding this if necessary so that > the defconfigs could just enable both SPI and MMC env and the dt will > be able to dictate the details. > > Does the 'Octeon' support your working on overlap with 'OcteonTX'? Some of the Octeon support will leverage OcteonTX since some of the drivers are mostly compatible, such as eMMC, SPI and I2C. There is also a lot in Octeon that in the case of OcteonTX is handled by ATF and our BDK bootloader. In these cases there is no overlap. > > Regards, > > Tim Regards, Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Kconfig: Make ZYNQMP_FIRMWARE depend on ARCH_ZYNQMP
There is a menu option to enable ZYNQMP_FIRMWARE even when ARCH_ZYNQMP is not enabled. This makes ZYNQMP_FIRMWARE depend on ARCH_ZYNQMP to help quiet unrelated options in menuconfig. Signed-off-by: Adam Ford diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig index b70a206355..a6227aa62d 100644 --- a/drivers/firmware/Kconfig +++ b/drivers/firmware/Kconfig @@ -30,6 +30,7 @@ config TI_SCI_PROTOCOL config ZYNQMP_FIRMWARE bool "ZynqMP Firmware interface" select FIRMWARE + depends on ARCH_ZYNQMP help Firmware interface driver is used by different drivers to communicate with the firmware for -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] net: ti: cpsw: add support for standard eth "max-speed" dt property
On Thu, Sep 19, 2019 at 11:16:39AM +0300, Grygorii Strashko wrote: > This patch adds support for standard Ethernet "max-speed" DT property to > allow PHY link speed limitation. > > Signed-off-by: Grygorii Strashko 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 5/6] net: ti: am65x-cpsw: fix mac tx internal delay for rgmii-rxid mode
On Thu, Sep 19, 2019 at 11:16:41AM +0300, Grygorii Strashko wrote: > Now AM65x CPSW2G driver will disable MAC TX internal delay for PHY > interface mode "rgmii-rxid" which is incorrect. Hence, fix it by keeping > default value (enabled) for MAC TX internal delay when "rgmii-rxid" > interface mode is selected. > > Signed-off-by: Grygorii Strashko 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 6/6] net: ti: cpsw: convert to use dev/ofnode api
On Thu, Sep 19, 2019 at 11:16:42AM +0300, Grygorii Strashko wrote: > Conver TI CPSW driver to use dev/ofnode api. > > Signed-off-by: Grygorii Strashko 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 1/3] arm: dts: dra7: sync cpsw/mdio/phy with latest linux - drop phy_id
On Sat, Aug 31, 2019 at 10:30:32AM +0300, Grygorii Strashko wrote: > Synchronize CPSW/MDIO/PHY DT nodes with latest linux - replace deprecated > phy_id property with phy-handle. > > Signed-off-by: Grygorii Strashko > Cc: Lokesh Vutla 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 4/6] net: ti: cpsw: fix mac tx internal delay for rgmii-rxid mode
On Thu, Sep 19, 2019 at 11:16:40AM +0300, Grygorii Strashko wrote: > Now TI CPSW driver will disable MAC TX internal delay for PHY interface > mode "rgmii-rxid" which is incorrect. > > Hence, fix it by keeping default value (enabled) for MAC TX internal delay > when "rgmii-rxid" interface mode is selected. > > Signed-off-by: Grygorii Strashko 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 1/6] net: ti: cpsw: enable 10Mbps link speed support in rgmii mode
On Thu, Sep 19, 2019 at 11:16:37AM +0300, Grygorii Strashko wrote:
> According to TRMs the 10Mbps link speed is supported in RGMII only when
> CPSW2G MAC SL is configured for External Control ("in band") mode
> CPSW_SL_MACCTRL.EXT_EN(18) = 1.
>
> Hence update cpsw_slave_update_link() to follow documentation.
>
> [1] https://patchwork.kernel.org/patch/10285239/
> Signed-off-by: Grygorii Strashko
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 3/3] arm: dts: am335x: sync cpsw/mdio/phy with latest linux - drop phy_id
On Sat, Aug 31, 2019 at 10:30:34AM +0300, Grygorii Strashko wrote: > Synchronize CPSW/MDIO/PHY DT nodes with latest linux - replace deprecated > phy_id property with phy-handle. > > Signed-off-by: Grygorii Strashko > Cc: Lokesh Vutla > Cc: Hannes Schmelzer > Cc: Heiko Schocher > Cc: Felix Brack > Cc: Jean-Jacques Hiblot 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 2/6] net: ti: cpsw: move parsing of dt port's parameters in separate func
On Thu, Sep 19, 2019 at 11:16:38AM +0300, Grygorii Strashko wrote: > Move parsing of dt port's parameters in separate func for better code > readability. > > Signed-off-by: Grygorii Strashko 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 2/3] arm: dts: am437x: sync cpsw/mdio/phy with latest linux - drop phy_id
On Sat, Aug 31, 2019 at 10:30:33AM +0300, Grygorii Strashko wrote: > Synchronize CPSW/MDIO/PHY DT nodes with latest linux - replace deprecated > phy_id property with phy-handle. > > Signed-off-by: Grygorii Strashko > Cc: Lokesh Vutla 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] [GIT PULL] Pull request: u-boot-imx u-boot-imx-20191104
On Mon, Nov 04, 2019 at 10:08:01AM +0100, Stefano Babic wrote: > Hi Tom, > > please pull from u-boot-imx, thanks ! > > The following changes since commit 5d6f05352b69d4858a2a9e9136ac3a734f0222bb: > > azure: Update the script to prepend PATH not override PATH (2019-11-01 > 13:59:14 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20191104 > > for you to fetch changes up to ae8a53ece0ff3b1ed686c3e0af14e59973d25db8: > > imx: nandbcb: add support for writing BCB only (2019-11-03 21:49:49 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Kconfig: ti: Make board detect EEPROM addresses depend BOARD_DETECT
There is an option to enable the board detection for TI platforms. If this is option is not set, there is no reason to set the EEPROM bus address or chip address. This patch makes both EEPROM_BUS_ADDRESS and EEPROM_CHIP_ADDRESS depend on TI_I2C_BOARD_DETECT. Signed-off-by: Adam Ford diff --git a/board/ti/common/Kconfig b/board/ti/common/Kconfig index b1956b8100..9ead7ca038 100644 --- a/board/ti/common/Kconfig +++ b/board/ti/common/Kconfig @@ -8,11 +8,13 @@ config EEPROM_BUS_ADDRESS int "Board EEPROM's I2C bus address" range 0 8 default 0 + depends on TI_I2C_BOARD_DETECT config EEPROM_CHIP_ADDRESS hex "Board EEPROM's I2C chip address" range 0 0xff default 0x50 + depends on TI_I2C_BOARD_DETECT config TI_COMMON_CMD_OPTIONS bool "Enable cmd options on TI platforms" -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.
On Mon, Nov 04, 2019 at 10:20:33PM +, Atish Patra wrote: > On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote: > > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote: > > > > > Add gz parsing logic so that booti can parse both Image > > > and Image.gz to boot Linux. Currently, it is difficult to calculate > > > a safe address for every board where the Image.gz can be > > > decompressed. > > > It is also not possible to figure out the size of the compressed > > > file > > > as well. Thus, user need to set two additional environment > > > variables > > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work. > > > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > > > Signed-off-by: Atish Patra > > > --- > > > I could not test this patch on any ARM64 devices due to lack of > > > access to any ARM64 board. If anybody can test it on ARM64, that > > > would be great. Oh, I missed this part before. You should be able to get fairly far with qemu :) > > Can we do the compression check more generally? I'd like to be able > > to > > see Image.xz/lz4/etc be able to be handled cleanly. > > This patch is intended only handle Image.gz which is a compressed > version of kernel "Image" file. That's why relevant code is only added > to booti command. Right. But the linux kernel will happily spit out a handful of other compressed Image files on arm64. I see riscv is only .gz today, but I want to be able to handle whatever the compression is, so long as we have it available. -- 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] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.
On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote: > On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote: > > > Add gz parsing logic so that booti can parse both Image > > and Image.gz to boot Linux. Currently, it is difficult to calculate > > a safe address for every board where the Image.gz can be > > decompressed. > > It is also not possible to figure out the size of the compressed > > file > > as well. Thus, user need to set two additional environment > > variables > > kernel_gz_addr_r and kernel_gz_size to make Image.gz work. > > > > Tested on HiFive Unleashed and Qemu for RISC-V. > > > > Signed-off-by: Atish Patra > > --- > > I could not test this patch on any ARM64 devices due to lack of > > access to any ARM64 board. If anybody can test it on ARM64, that > > would be great. > > Can we do the compression check more generally? I'd like to be able > to > see Image.xz/lz4/etc be able to be handled cleanly. This patch is intended only handle Image.gz which is a compressed version of kernel "Image" file. That's why relevant code is only added to booti command. > When you say the > compressed file, you do mean the Image.gz (for example) itself, > right? Yes. > I would suggest documenting using $filesize after loading the > compressed > image as that should always be set. Thanks! > ok. I will change the kernel_gz_size to filesize. -- Regards, Atish ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: avoid address-of-packed-member error
On Mon, Nov 04, 2019 at 10:21:14PM +0100, Simon Goldschmidt wrote: > Tom Rini schrieb am Mo., 4. Nov. 2019, 22:15: > > > On Mon, Nov 04, 2019 at 09:28:51PM +0100, Simon Goldschmidt wrote: > > > Am 04.11.2019 um 20:34 schrieb Heinrich Schuchardt: > > > > struct ip_udp_hdr is naturally packed. There is no point in adding a > > > > __packed attribute. With the attribute the network stack does not > > compile > > > > using GCC 9.2.1: > > > > > > Is this commit message correct? In lwIP, we *do* need to pack all these > > > network header structs as they can come in unaligned. Especially the IP > > > header is normally 16-bit aligned if the incoming Ethernet frame is > > 32-bit > > > aligned (which is a must for many DMA engines). > > > > > > This is also the reason why the below code works, I guess: it is rarely > > > totally unaligned, but nearly always at least 16-bit aligned, so > > > dereferencing the checksum pointer as aligned u16 just works. > > > > > > Nevertheless, the code is formally wrong and your patch is correct. I > > just > > > don't like the commit message saying 'packed' is not required. > > > > Perhaps we should fix the underlying code problem then? Or does that > > men "rewrite the whole file" ? > > > > This patch fixes the code problem. If there are more problems: any > assignment to an u16 pointer from an address of a packed struct issues a > warning (provided that appropriate warning settings are used). If we fix > all of these warnings (e.g. like we do here, by using alignment agnostic > byte accesses), we should be good. > > I just think the misleading commit message should be fixed before giving my > RB. Ah, I get it now I hope, 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 1/1] net: avoid address-of-packed-member error
Tom Rini schrieb am Mo., 4. Nov. 2019, 22:15: > On Mon, Nov 04, 2019 at 09:28:51PM +0100, Simon Goldschmidt wrote: > > Am 04.11.2019 um 20:34 schrieb Heinrich Schuchardt: > > > struct ip_udp_hdr is naturally packed. There is no point in adding a > > > __packed attribute. With the attribute the network stack does not > compile > > > using GCC 9.2.1: > > > > Is this commit message correct? In lwIP, we *do* need to pack all these > > network header structs as they can come in unaligned. Especially the IP > > header is normally 16-bit aligned if the incoming Ethernet frame is > 32-bit > > aligned (which is a must for many DMA engines). > > > > This is also the reason why the below code works, I guess: it is rarely > > totally unaligned, but nearly always at least 16-bit aligned, so > > dereferencing the checksum pointer as aligned u16 just works. > > > > Nevertheless, the code is formally wrong and your patch is correct. I > just > > don't like the commit message saying 'packed' is not required. > > Perhaps we should fix the underlying code problem then? Or does that > men "rewrite the whole file" ? > This patch fixes the code problem. If there are more problems: any assignment to an u16 pointer from an address of a packed struct issues a warning (provided that appropriate warning settings are used). If we fix all of these warnings (e.g. like we do here, by using alignment agnostic byte accesses), we should be good. I just think the misleading commit message should be fixed before giving my RB. Regards, Simon > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: avoid address-of-packed-member error
On Mon, Nov 04, 2019 at 09:28:51PM +0100, Simon Goldschmidt wrote: > Am 04.11.2019 um 20:34 schrieb Heinrich Schuchardt: > > struct ip_udp_hdr is naturally packed. There is no point in adding a > > __packed attribute. With the attribute the network stack does not compile > > using GCC 9.2.1: > > Is this commit message correct? In lwIP, we *do* need to pack all these > network header structs as they can come in unaligned. Especially the IP > header is normally 16-bit aligned if the incoming Ethernet frame is 32-bit > aligned (which is a must for many DMA engines). > > This is also the reason why the below code works, I guess: it is rarely > totally unaligned, but nearly always at least 16-bit aligned, so > dereferencing the checksum pointer as aligned u16 just works. > > Nevertheless, the code is formally wrong and your patch is correct. I just > don't like the commit message saying 'packed' is not required. Perhaps we should fix the underlying code problem then? Or does that men "rewrite the whole file" ? -- 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] [PATCHv2 0/4] support remote system update on Intel Stratix10 SoC
Am 30.10.2019 um 21:34 schrieb richard.g...@linux.intel.com: From: Richard Gong This is 2nd submission of Intel Remote System Update patches. Ok, so what has changed since v1? You'd normally add a changelog (ideally to both this cover-letter and to each patch). Have a look at patman in tools/patman, that allows you to create those changelogs more easily. The Intel Remote System Update (RSU) provides a way for users to update the QSPI configuration bitstream of a Intel Stratix10 SoC device with significantly reduced risk of corrupting the bitstream storage and bricking the system. The patchset adds RSU support which allows user to perform a complete set of RSU operations via provided console commands. The patches have reviewed by other colleagues at Intel. Richard Gong (4): arm: socfpga: stratix10: add RSU mailbox support drivers: firmware: add RSU support for Stratix10 SoC dirvers: firmware: add console commands for RSU support arm: socfpga: stratix10: add environment variables for RSU support arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 36 +- arch/arm/mach-socfpga/mailbox_s10.c | 79 ++ Do you have plans to move this code to drivers/mailbox? arch/arm/mach-socfpga/misc_s10.c |9 + drivers/firmware/Kconfig | 11 + drivers/firmware/Makefile|1 + drivers/firmware/rsu.c | 662 ++ drivers/firmware/rsu_ll_qspi.c | 1050 ++ drivers/firmware/rsu_misc.c | 817 + drivers/firmware/rsu_s10.c | 874 ++ Ok, so you started to add this "RSU" as a driver, that's probably fine (sorry I did not find the time to review that, yet). However, I think you'd need a more specific name, probably including 'intel' or something to make this more clear. I'll hope to find the time to review the rest this week. Regards, Simon include/intel/rsu.h | 291 ++ include/intel/rsu_ll.h | 72 ++ include/intel/rsu_misc.h | 60 ++ include/intel/rsu_s10.h | 46 + 13 files changed, 3998 insertions(+), 10 deletions(-) create mode 100644 drivers/firmware/rsu.c create mode 100644 drivers/firmware/rsu_ll_qspi.c create mode 100644 drivers/firmware/rsu_misc.c create mode 100644 drivers/firmware/rsu_s10.c create mode 100644 include/intel/rsu.h create mode 100644 include/intel/rsu_ll.h create mode 100644 include/intel/rsu_misc.h create mode 100644 include/intel/rsu_s10.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: avoid address-of-packed-member error
Am 04.11.2019 um 20:34 schrieb Heinrich Schuchardt:
struct ip_udp_hdr is naturally packed. There is no point in adding a
__packed attribute. With the attribute the network stack does not compile
using GCC 9.2.1:
Is this commit message correct? In lwIP, we *do* need to pack all these
network header structs as they can come in unaligned. Especially the IP
header is normally 16-bit aligned if the incoming Ethernet frame is
32-bit aligned (which is a must for many DMA engines).
This is also the reason why the below code works, I guess: it is rarely
totally unaligned, but nearly always at least 16-bit aligned, so
dereferencing the checksum pointer as aligned u16 just works.
Nevertheless, the code is formally wrong and your patch is correct. I
just don't like the commit message saying 'packed' is not required.
net/net.c: In function ‘net_process_received_packet’:
net/net.c:1288:23: error: taking address of packed member of ‘struct
ip_udp_hdr’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
1288 |sumptr = (ushort *)&(ip->udp_src);
| ^~
Unfortunately there was a bug in GCC 7.1 which required __packed here.
So let's avoid the error by using a uchar pointer instead of an u16
pointer.
Signed-off-by: Heinrich Schuchardt
---
net/net.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/net.c b/net/net.c
index ded86e7456..e6f6d2cb45 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1274,7 +1274,7 @@ void net_process_received_packet(uchar *in_packet, int
len)
#ifdef CONFIG_UDP_CHECKSUM
if (ip->udp_xsum != 0) {
ulong xsum;
- ushort *sumptr;
+ uchar *sumptr;
ushort sumlen;
xsum = ip->ip_p;
@@ -1285,13 +1285,11 @@ void net_process_received_packet(uchar *in_packet, int
len)
xsum += (ntohl(ip->ip_dst.s_addr) >> 0) & 0x;
sumlen = ntohs(ip->udp_len);
- sumptr = (ushort *)&(ip->udp_src);
+ sumptr = (uchar *)>udp_src;
while (sumlen > 1) {
- ushort sumdata;
-
- sumdata = *sumptr++;
- xsum += ntohs(sumdata);
+ xsum += (sumptr[0] << 8) + sumptr[1];
Do we need a comment here stating why we have an open-coded copy of
ntohs? That could keep us from getting this bug back in the future...
Regards,
Simon
+ sumptr += 2;
sumlen -= 2;
}
if (sumlen > 0) {
--
2.24.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] dm: board: complete the initialization of the muxes in initr_dm()
Hi Jean-Jacques, On Mon, 4 Nov 2019 at 11:07, Jean-Jacques Hiblot wrote: > > > On 30/10/2019 02:48, Simon Glass wrote: > > Hi Jean-Jacques, > > > > On Wed, 2 Oct 2019 at 06:47, Jean-Jacques Hiblot wrote: > >> This will probe the multiplexer devices that have a "u-boot,mux-autoprobe" > >> property. As a consequence they will be put in their idle state. > >> > >> Signed-off-by: Jean-Jacques Hiblot > >> --- > >> > >> common/board_r.c | 2 ++ > >> 1 file changed, 2 insertions(+) > > I worry this should happen later, or lazily, since at present we don't > > actually probe any devices at this point, right? > > It has to be done early to make sure that the platform is in the right > state before most of the drivers are initialized. Some devices may rely > on it without knowing it. In this way, it is similar to the gpio-hog > mechanism. > > Now, I have no strong opinion on when this should really take place. > Only it has to be after dm is initialized. Maybe it could be inserted in > init_sequence_r, after board_init() ? > > It should probably be before the serial port is used, just in case > someone multiplexed the serial port of the console. I hit a similar issue and created this patch, which I'll send soon. https://gitlab.denx.de/u-boot/custodians/u-boot-dm/commit/087f241416bf7a1b65575840e02a3d270d4fa440 (actually it looks a bit broken, but hopefully you get the idea) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] net: avoid address-of-packed-member error
struct ip_udp_hdr is naturally packed. There is no point in adding a
__packed attribute. With the attribute the network stack does not compile
using GCC 9.2.1:
net/net.c: In function ‘net_process_received_packet’:
net/net.c:1288:23: error: taking address of packed member of ‘struct
ip_udp_hdr’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
1288 |sumptr = (ushort *)&(ip->udp_src);
| ^~
Unfortunately there was a bug in GCC 7.1 which required __packed here.
So let's avoid the error by using a uchar pointer instead of an u16
pointer.
Signed-off-by: Heinrich Schuchardt
---
net/net.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/net/net.c b/net/net.c
index ded86e7456..e6f6d2cb45 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1274,7 +1274,7 @@ void net_process_received_packet(uchar *in_packet, int
len)
#ifdef CONFIG_UDP_CHECKSUM
if (ip->udp_xsum != 0) {
ulong xsum;
- ushort *sumptr;
+ uchar *sumptr;
ushort sumlen;
xsum = ip->ip_p;
@@ -1285,13 +1285,11 @@ void net_process_received_packet(uchar *in_packet, int
len)
xsum += (ntohl(ip->ip_dst.s_addr) >> 0) & 0x;
sumlen = ntohs(ip->udp_len);
- sumptr = (ushort *)&(ip->udp_src);
+ sumptr = (uchar *)>udp_src;
while (sumlen > 1) {
- ushort sumdata;
-
- sumdata = *sumptr++;
- xsum += ntohs(sumdata);
+ xsum += (sumptr[0] << 8) + sumptr[1];
+ sumptr += 2;
sumlen -= 2;
}
if (sumlen > 0) {
--
2.24.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] imx: sync with kernel device tree for Phycore SoM
Sync the Linux Kernel 5.4-rc6 device tree for Phytec Phycore
SoM and Segin board based on imx6UL and imx6ULL.
Changes includes Phytec naming convention for the devicetree files.
Signed-off-by: Parthiban Nallathambi
---
arch/arm/dts/Makefile | 4 +-
arch/arm/dts/imx6ul-phycore-segin.dts | 81
...on.dtsi => imx6ul-phytec-phycore-som.dtsi} | 130 +++
.../dts/imx6ul-phytec-segin-ff-rdk-nand.dts | 93 +
.../dts/imx6ul-phytec-segin-peb-eval-01.dtsi | 57 +++
arch/arm/dts/imx6ul-phytec-segin.dtsi | 346 ++
arch/arm/dts/imx6ull-phycore-segin.dts| 70
arch/arm/dts/imx6ull-phytec-phycore-som.dtsi | 24 ++
.../dts/imx6ull-phytec-segin-ff-rdk-emmc.dts | 93 +
.../dts/imx6ull-phytec-segin-peb-eval-01.dtsi | 19 +
arch/arm/dts/imx6ull-phytec-segin.dtsi| 38 ++
board/phytec/pcl063/MAINTAINERS | 12 +-
configs/phycore_pcl063_defconfig | 3 +-
configs/phycore_pcl063_ull_defconfig | 2 +-
14 files changed, 732 insertions(+), 240 deletions(-)
delete mode 100644 arch/arm/dts/imx6ul-phycore-segin.dts
rename arch/arm/dts/{pcl063-common.dtsi => imx6ul-phytec-phycore-som.dtsi}
(56%)
create mode 100644 arch/arm/dts/imx6ul-phytec-segin-ff-rdk-nand.dts
create mode 100644 arch/arm/dts/imx6ul-phytec-segin-peb-eval-01.dtsi
create mode 100644 arch/arm/dts/imx6ul-phytec-segin.dtsi
delete mode 100644 arch/arm/dts/imx6ull-phycore-segin.dts
create mode 100644 arch/arm/dts/imx6ull-phytec-phycore-som.dtsi
create mode 100644 arch/arm/dts/imx6ull-phytec-segin-ff-rdk-emmc.dts
create mode 100644 arch/arm/dts/imx6ull-phytec-segin-peb-eval-01.dtsi
create mode 100644 arch/arm/dts/imx6ull-phytec-segin.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 47978e7685..935b661284 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -621,14 +621,14 @@ dtb-$(CONFIG_MX6UL) += \
imx6ul-9x9-evk.dtb \
imx6ul-9x9-evk.dtb \
imx6ul-liteboard.dtb \
- imx6ul-phycore-segin.dtb \
+ imx6ul-phytec-segin-ff-rdk-nand.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-pico-pi.dtb
dtb-$(CONFIG_MX6ULL) += \
imx6ull-14x14-evk.dtb \
imx6ull-colibri.dtb \
- imx6ull-phycore-segin.dtb \
+ imx6ull-phytec-segin-ff-rdk-emmc.dtb \
imx6ull-dart-6ul.dtb \
imx6ulz-14x14-evk.dtb
diff --git a/arch/arm/dts/imx6ul-phycore-segin.dts
b/arch/arm/dts/imx6ul-phycore-segin.dts
deleted file mode 100644
index 7d68bf8430..00
--- a/arch/arm/dts/imx6ul-phycore-segin.dts
+++ /dev/null
@@ -1,81 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2018 Collabora Ltd.
- *
- * Based on dts[i] from Phytec barebox port:
- * Copyright (C) 2016 PHYTEC Messtechnik GmbH
- * Author: Christian Hemp
- *
- * The code contained herein is licensed under the GNU General Public
- * License. You may obtain a copy of the GNU General Public License
- * Version 2 or later at the following locations:
- *
- * http://www.opensource.org/licenses/gpl-license.html
- * http://www.gnu.org/copyleft/gpl.html
- */
-
-/dts-v1/;
-
-#include "imx6ul.dtsi"
-#include "pcl063-common.dtsi"
-
-/ {
- model = "Phytec phyBOARD-i.MX6UL-Segin SBC";
- compatible = "phytec,phyboard-imx6ul-segin", "phytec,imx6ul-pcl063",
-"fsl,imx6ul";
-};
-
- {
- status = "okay";
-};
-
- {
- i2c_rtc: rtc@68 {
- compatible = "microcrystal,rv4162";
- reg = <0x68>;
- status = "okay";
- };
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_uart5>;
- uart-has-rtscts;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
- pinctrl-0 = <_usb_otg1_id>;
- dr_mode = "otg";
- srp-disable;
- hnp-disable;
- adp-disable;
- status = "okay";
-};
-
- {
- dr_mode = "host";
- disable-over-current;
- status = "okay";
-};
-
- {
- pinctrl-names = "default";
-
- pinctrl_uart5: uart5grp {
- fsl,pins = <
- MX6UL_PAD_UART5_TX_DATA__UART5_DCE_TX 0x1b0b1
- MX6UL_PAD_UART5_RX_DATA__UART5_DCE_RX 0x1b0b1
- MX6UL_PAD_GPIO1_IO08__UART5_DCE_RTS 0x1b0b1
- MX6UL_PAD_GPIO1_IO09__UART5_DCE_CTS 0x1b0b1
- >;
- };
-
- pinctrl_usb_otg1_id: usbotg1idgrp {
- fsl,pins = <
- MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID0x17059
- >;
- };
-
-};
diff --git a/arch/arm/dts/pcl063-common.dtsi
b/arch/arm/dts/imx6ul-phytec-phycore-som.dtsi
similarity index 56%
rename from arch/arm/dts/pcl063-common.dtsi
rename to arch/arm/dts/imx6ul-phytec-phycore-som.dtsi
index b88dde2fb0..c2a7c78779 100644
--- a/arch/arm/dts/pcl063-common.dtsi
+++ b/arch/arm/dts/imx6ul-phytec-phycore-som.dtsi
@@ -1,22 +1,35 @@
-// SPDX-License-Identifier: GPL-2.0+
Re: [U-Boot] [PATCH v1 3/4] drivers: mux: mmio-based syscon mux controller
Simon, On 30/10/2019 02:48, Simon Glass wrote: On Wed, 2 Oct 2019 at 06:47, Jean-Jacques Hiblot wrote: This adds a driver for mmio-based syscon multiplexers controlled by bitfields in a syscon register range. This is heavily based on the linux mmio-mux driver. Signed-off-by: Jean-Jacques Hiblot --- drivers/mux/Kconfig | 15 + drivers/mux/Makefile | 1 + drivers/mux/mmio.c | 155 +++ 3 files changed, 171 insertions(+) create mode 100644 drivers/mux/mmio.c Reviewed-by: Simon Glass So much memory allocation! But I suppose it is unavoidable. No way to use DM's auto-alloc? I didn't try very hard to reduce the number of allocations to keep the code simple. Part of the trouble comes from the fact that the number of mux_controls is read from the DT making it not possible to use the auto-alloc. With other type of multiplexers (like a I2C or analog-lines multiplexer) the number of controls will be fixed and using auto-alloc will be possible. JJ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] net: remove superfluous __packed attribute
On Mon, Nov 04, 2019 at 07:07:46PM +0100, Heinrich Schuchardt wrote:
> On 10/12/19 3:29 PM, Heinrich Schuchardt wrote:
> > On 10/3/19 8:01 PM, Heinrich Schuchardt wrote:
> > > On 10/3/19 7:09 PM, Tom Rini wrote:
> > > > On Thu, Oct 03, 2019 at 07:01:22PM +0200, Heinrich Schuchardt wrote:
> > > >
> > > > > struct ip_udp_hdr is naturally packed. There is no point in adding a
> > > > > __packed attribute. With the attribute the network stack does not
> > > > > compile
> > > > > using GCC 9.2.1:
> > > > >
> > > > > net/net.c: In function ‘net_process_received_packet’:
> > > > > net/net.c:1288:23: error: taking address of packed member of ‘struct
> > > > > ip_udp_hdr’ may result in an unaligned pointer value
> > > > > [-Werror=address-of-packed-member]
> > > > > 1288 | sumptr = (ushort *)&(ip->udp_src);
> > > > > | ^~
> > > > >
> > > > > So let's remove the attribute.
> > > > >
> > > > > Signed-off-by: Heinrich Schuchardt
> > > > > ---
> > > > > include/net.h | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/net.h b/include/net.h
> > > > > index 75a16e4c8f..bd875b56f5 100644
> > > > > --- a/include/net.h
> > > > > +++ b/include/net.h
> > > > > @@ -390,7 +390,7 @@ struct ip_udp_hdr {
> > > > > u16 udp_dst; /* UDP destination port */
> > > > > u16 udp_len; /* Length of UDP packet */
> > > > > u16 udp_xsum; /* Checksum */
> > > > > -} __attribute__((packed));
> > > > > +};
> > > > >
> > > > > #define IP_UDP_HDR_SIZE (sizeof(struct ip_udp_hdr))
> > > > > #define UDP_HDR_SIZE (IP_UDP_HDR_SIZE - IP_HDR_SIZE)
> > > >
> > > > This came from:
> > > > commit 704f3acfcf55343043bbed01c5fb0a0094a68e8a
> > > > Author: Denis Pynkin
> > > > Date: Fri Jul 21 19:28:42 2017 +0300
> > > >
> > > > net: Use packed structures for networking
> > > >
> > > > PXE boot is broken with GCC 7.1 due option '-fstore-merging'
> > > > enabled
> > > > by default for '-O2':
> > > >
> > > > BOOTP broadcast 1
> > > > data abort
> > > > pc : [<8ff8bb30>] lr : [<4f1f>]
> > > > reloc pc : [<17832b30>] lr : [<878abf1f>]
> > > > sp : 8f558bc0 ip : fp : 8ffef5a4
> > > > r10: 8ffed248 r9 : 8f558ee0 r8 : 8ffef594
> > > > r7 : 000e r6 : 8ffed700 r5 : r4 : 8ffed74e
> > > > r3 : 00060101 r2 : 8ffed230 r1 : 8ffed706 r0 : 0ddd
> > > > Flags: nzcv IRQs off FIQs off Mode SVC_32
> > > > Resetting CPU ...
> > > >
> > > > Core reason is usage of structures for network headers without
> > > > packed
> > > > attribute.
> > > >
> > > > Reviewed-by: Yauheni Kaliuta
> > > > Signed-off-by: Denis Pynkin
> > > > Acked-by: Joe Hershberger
> > > >
> > > > ... so adding a few folks to the list and lets see if patchwork picks up
> > > > this tag:
> > > > Fixes: 704f3acfcf55 ("net: Use packed structures for networking")
> > > >
> > >
> > > Thanks for providing this background.
> > >
> > > -fstore-merging is enabled for O2 and Os. But it should not change the
> > > program behavior.
> > >
> > > The relevant code is in gcc/gimple-ssa-store-merging.c. It has been
> > > completely overhauled since GCC 7.1.
> > >
> > > I have seen no problems with DHCP, ping and tFTP on arm and arm64 with
> > > GCC 9.2.1.
> > >
> > > Best regards
> > >
> > > Heinrich
> > >
> > > Since GCC 7.1 some bugs have been fixed, e.g.
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492
> > >
> >
> > Hello Joe,
> >
> > how will we carry on, to get the issue resolved?
> >
> > Best regards
> >
> > Heinrich
> > ___
>
> Hello Tom, hello Joe,
>
> I still cannot build sandbox_defconfig. How will we resolve this issue?
We can't drop gcc-7.1 support at this point. Perhaps use an accessor
function of some sort?
--
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 1/1] net: remove superfluous __packed attribute
On 10/12/19 3:29 PM, Heinrich Schuchardt wrote:
On 10/3/19 8:01 PM, Heinrich Schuchardt wrote:
On 10/3/19 7:09 PM, Tom Rini wrote:
On Thu, Oct 03, 2019 at 07:01:22PM +0200, Heinrich Schuchardt wrote:
struct ip_udp_hdr is naturally packed. There is no point in adding a
__packed attribute. With the attribute the network stack does not
compile
using GCC 9.2.1:
net/net.c: In function ‘net_process_received_packet’:
net/net.c:1288:23: error: taking address of packed member of ‘struct
ip_udp_hdr’ may result in an unaligned pointer value
[-Werror=address-of-packed-member]
1288 | sumptr = (ushort *)&(ip->udp_src);
| ^~
So let's remove the attribute.
Signed-off-by: Heinrich Schuchardt
---
include/net.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net.h b/include/net.h
index 75a16e4c8f..bd875b56f5 100644
--- a/include/net.h
+++ b/include/net.h
@@ -390,7 +390,7 @@ struct ip_udp_hdr {
u16 udp_dst; /* UDP destination port */
u16 udp_len; /* Length of UDP packet */
u16 udp_xsum; /* Checksum */
-} __attribute__((packed));
+};
#define IP_UDP_HDR_SIZE (sizeof(struct ip_udp_hdr))
#define UDP_HDR_SIZE (IP_UDP_HDR_SIZE - IP_HDR_SIZE)
This came from:
commit 704f3acfcf55343043bbed01c5fb0a0094a68e8a
Author: Denis Pynkin
Date: Fri Jul 21 19:28:42 2017 +0300
net: Use packed structures for networking
PXE boot is broken with GCC 7.1 due option '-fstore-merging'
enabled
by default for '-O2':
BOOTP broadcast 1
data abort
pc : [<8ff8bb30>] lr : [<4f1f>]
reloc pc : [<17832b30>] lr : [<878abf1f>]
sp : 8f558bc0 ip : fp : 8ffef5a4
r10: 8ffed248 r9 : 8f558ee0 r8 : 8ffef594
r7 : 000e r6 : 8ffed700 r5 : r4 : 8ffed74e
r3 : 00060101 r2 : 8ffed230 r1 : 8ffed706 r0 : 0ddd
Flags: nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
Core reason is usage of structures for network headers without
packed
attribute.
Reviewed-by: Yauheni Kaliuta
Signed-off-by: Denis Pynkin
Acked-by: Joe Hershberger
... so adding a few folks to the list and lets see if patchwork picks up
this tag:
Fixes: 704f3acfcf55 ("net: Use packed structures for networking")
Thanks for providing this background.
-fstore-merging is enabled for O2 and Os. But it should not change the
program behavior.
The relevant code is in gcc/gimple-ssa-store-merging.c. It has been
completely overhauled since GCC 7.1.
I have seen no problems with DHCP, ping and tFTP on arm and arm64 with
GCC 9.2.1.
Best regards
Heinrich
Since GCC 7.1 some bugs have been fixed, e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86492
Hello Joe,
how will we carry on, to get the issue resolved?
Best regards
Heinrich
___
Hello Tom, hello Joe,
I still cannot build sandbox_defconfig. How will we resolve this issue?
Best regards
Heinrich
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] dm: board: complete the initialization of the muxes in initr_dm()
On 30/10/2019 02:48, Simon Glass wrote: Hi Jean-Jacques, On Wed, 2 Oct 2019 at 06:47, Jean-Jacques Hiblot wrote: This will probe the multiplexer devices that have a "u-boot,mux-autoprobe" property. As a consequence they will be put in their idle state. Signed-off-by: Jean-Jacques Hiblot --- common/board_r.c | 2 ++ 1 file changed, 2 insertions(+) I worry this should happen later, or lazily, since at present we don't actually probe any devices at this point, right? It has to be done early to make sure that the platform is in the right state before most of the drivers are initialized. Some devices may rely on it without knowing it. In this way, it is similar to the gpio-hog mechanism. Now, I have no strong opinion on when this should really take place. Only it has to be after dm is initialized. Maybe it could be inserted in init_sequence_r, after board_init() ? It should probably be before the serial port is used, just in case someone multiplexed the serial port of the console. JJ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/4] drivers: Add a new framework for multiplexer devices
Hi Simon,
Thank for the review.
On 30/10/2019 02:48, Simon Glass wrote:
Hi Jean-Jacques,
On Wed, 2 Oct 2019 at 06:47, Jean-Jacques Hiblot wrote:
Add a new subsystem that handles multiplexer controllers. The API is the
same as in Linux.
Signed-off-by: Jean-Jacques Hiblot
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/mux/Kconfig | 7 +
drivers/mux/Makefile | 6 +
drivers/mux/mux-uclass.c | 296 ++
include/dm/uclass-id.h| 1 +
include/dt-bindings/mux/mux.h | 17 ++
include/mux-internal.h| 80 +
include/mux.h | 114 +
9 files changed, 524 insertions(+)
create mode 100644 drivers/mux/Kconfig
create mode 100644 drivers/mux/Makefile
create mode 100644 drivers/mux/mux-uclass.c
create mode 100644 include/dt-bindings/mux/mux.h
create mode 100644 include/mux-internal.h
create mode 100644 include/mux.h
I feel this needs more documentation. What is a multiplexer?
I'll add a description of what a mux is in include/mux.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 350acf81f3..5334974ad4 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -60,6 +60,8 @@ source "drivers/mmc/Kconfig"
source "drivers/mtd/Kconfig"
+source "drivers/mux/Kconfig"
+
source "drivers/net/Kconfig"
source "drivers/nvme/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index a4bb5e4975..f4d71f3b3c 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_TPL_)INPUT) += input/
obj-$(CONFIG_$(SPL_TPL_)LED) += led/
obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += mmc/
obj-$(CONFIG_$(SPL_TPL_)NAND_SUPPORT) += mtd/nand/raw/
+obj-$(CONFIG_$(SPl_)MULTIPLEXER) += mux/
SPL?
good catch
obj-$(CONFIG_$(SPL_TPL_)PCH_SUPPORT) += pch/
obj-$(CONFIG_$(SPL_TPL_)PCI) += pci/
obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
new file mode 100644
index 00..ad0199c058
--- /dev/null
+++ b/drivers/mux/Kconfig
@@ -0,0 +1,7 @@
+menu "Multiplexer drivers"
+
+config MULTIPLEXER
+ bool "Multiplexer Support"
+ depends on DM
+
+endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
new file mode 100644
index 00..351e4363d3
--- /dev/null
+++ b/drivers/mux/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2019
+# Jean-Jacques Hiblot
+
+obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux-uclass.o
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
new file mode 100644
index 00..58998af29c
--- /dev/null
+++ b/drivers/mux/mux-uclass.c
@@ -0,0 +1,296 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Multiplexer subsystem
+ *
+ * Based on the linux multiplexer framework
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ * Author: Peter Rosin
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot
+ */
+
+#include
+#include
should go above the dm/device-internal
+#include
+#include
Shouldn't need this
+#include
Shouldn't need this
+#include
+#include
+#include
Shouldn't need this
I'll cleanup the headers in v2.
+#include
+
+/*
+ * The idle-as-is "state" is not an actual state that may be selected, it
+ * only implies that the state should not be changed. So, use that state
+ * as indication that the cached state of the multiplexer is unknown.
+ */
+#define MUX_CACHE_UNKNOWN MUX_IDLE_AS_IS
+
+static inline const struct mux_control_ops *mux_dev_ops(struct udevice *dev)
+{
+ return (const struct mux_control_ops *)dev->driver->ops;
+}
+
+static int mux_control_set(struct mux_control *mux, int state)
+{
+ int ret = mux_dev_ops(mux->dev)->set(mux, state);
+
+ mux->cached_state = ret < 0 ? MUX_CACHE_UNKNOWN : state;
+
+ return ret;
+}
+
+unsigned int mux_control_states(struct mux_control *mux)
+{
+ return mux->states;
+}
+
+static int __mux_control_select(struct mux_control *mux, int state)
+{
+ int ret;
+
+ if (WARN_ON(state < 0 || state >= mux->states))
+ return -EINVAL;
+
+ if (mux->cached_state == state)
+ return 0;
+
+ ret = mux_control_set(mux, state);
+ if (ret >= 0)
+ return 0;
+
+ /* The mux update failed, try to revert if appropriate... */
+ if (mux->idle_state != MUX_IDLE_AS_IS)
+ mux_control_set(mux, mux->idle_state);
+
+ return ret;
+}
+
+int mux_control_select(struct mux_control *mux, unsigned int state)
+{
+ int ret;
+
+ if (mux->in_use)
+ return -EBUSY;
+
+ ret = __mux_control_select(mux, state);
+
+ if (ret < 0)
+ return ret;
+
+ mux->in_use = true;
+
+ return 0;
+}
+
+int mux_control_deselect(struct mux_control *mux)
+{
+ int ret = 0;
+
+ if (mux->idle_state != MUX_IDLE_AS_IS &&
+ mux->idle_state !=
Re: [U-Boot] [PATCH 26/34] binman: Correct symbol calculation with non-zero image base
On 10/15/19 10:09 AM, Stephen Warren wrote: On 10/15/19 8:07 AM, Simon Glass wrote: Hi Stephen, On Mon, 14 Oct 2019 at 09:49, Stephen Warren wrote: On 9/26/19 6:38 PM, s...@google.com wrote: At present binman adds the image base address to the symbol value before it writes it to the binary. This is not correct since the symbol value itself (e.g. image position) has no relationship to the image base. Fix this and update the tests to cover this case. Signed-off-by: Simon Glass --- tools/binman/elf.py | 4 +--- tools/binman/test/u_boot_binman_syms.lds | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-) Applied to u-boot-dm, thanks! This seems to have only just been pushed. This patch breaks boot on Jetson TK1; u-boot-dm.git master hangs in SPL or before the main U-Boot prints anything, whereas after reverting this patch solves the issue. With this patch applied, all I get is: U-Boot SPL 2019.10-00490-g4f035abcde98 (Oct 14 2019 - 09:48:30 -0600) Trying to boot from RAM Yes, just pushed as I had to wait for u-boot-dm/testing to pass, and it has some flaky runs and then I went on holiday. This is unfortunate. It looks like we were missing test coverage. I'll see if I can look at it later in the week, but for now I think I might drop this patch. Thanks. The latest push to u-boot-dm/master solves/removes this issue. This patch has now shown in in u-boot/master and u-boot-video/master, so Jetson TK1 testing is broken there now. Reverting this patch fixes the issue (I only tested that in u-boot/master). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Thu, Oct 31, 2019 at 06:01:34PM +, Aaron Williams wrote: > Hi Wolfgang, > > On Thursday, October 31, 2019 3:40:27 AM PDT Wolfgang Denk wrote: > > Dear Aaron, > > > > In message <1889679.7FQr5zsBR1@flash> you wrote: > > > Currently we are using 39MB under arch/mips. I think I can easily cut this > > > down to 15MB or smaller, especially by moving some code here to the > > > appropriate driver directories (i.e. DRAM, pcie, watchdog, etc.) > > > > > > It will still be a large SoC, though. > > > > Have you already looked at formal requirements, like coding style > > etc.? Did you ever run your additions through checkpatch.pl, for > > example? > > We did follow the formal coding style. Everything will go through checkpatch. > My biggest complaint about it is the 80 columns for debug and other print > statements. checkpatch doesn't complain about those when they use standard logging functions, however. -- 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] [RFC PATCH 4/5] ram: add SDRAM driver for i.MXRT SoCs
On 11/4/19 5:33 PM, Fabio Estevam wrote: Hi Giulio, On Thu, Oct 31, 2019 at 9:11 AM Giulio Benetti wrote: ...in this register and the next one there are parameters like CKEOFF and ACT2PRE impossible to lead to classic tXXX sdram timing parameters. I've done this way inspired by stm32-sdram, but maybe U should go back using i.MXRT names(i.e. PRE2ACT instead of tRP) and list all possible useful registers in DM as I've done for tRP etc. What do you think? I think it is OK to use the i.MXRT names. Ok #define TWR_10x0 +#define TWR_20x1 +#define TWR_30x2 +#define TWR_40x3 +#define TWR_50x4 +#define TWR_60x5 +#define TWR_70x6 +#define TWR_80x7 +#define TWR_90x8 +#define TWR_10 0x9 +#define TWR_11 0xA +#define TWR_12 0xB +#define TWR_13 0xC +#define TWR_14 0xD +#define TWR_15 0xE +#define TWR_16 0xF + +#endif ...is it ok listing every possible value for DM parameter? I mean, some of them would be 8-bit, this would mean having 256 cases, that sound very ugly to me. It doesn't seem necessary to write all 256 cases. I would suggest to write the direct hex number. Well, thanks a lot! Best regards -- Giulio Benetti Benetti Engineering sas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 4/5] ram: add SDRAM driver for i.MXRT SoCs
Hi Giulio, On Thu, Oct 31, 2019 at 9:11 AM Giulio Benetti wrote: > ...in this register and the next one there are parameters like CKEOFF > and ACT2PRE impossible to lead to classic tXXX sdram timing parameters. > I've done this way inspired by stm32-sdram, but maybe U should go back > using i.MXRT names(i.e. PRE2ACT instead of tRP) and list all possible > useful registers in DM as I've done for tRP etc. > What do you think? I think it is OK to use the i.MXRT names. #define TWR_10x0 > > +#define TWR_20x1 > > +#define TWR_30x2 > > +#define TWR_40x3 > > +#define TWR_50x4 > > +#define TWR_60x5 > > +#define TWR_70x6 > > +#define TWR_80x7 > > +#define TWR_90x8 > > +#define TWR_10 0x9 > > +#define TWR_11 0xA > > +#define TWR_12 0xB > > +#define TWR_13 0xC > > +#define TWR_14 0xD > > +#define TWR_15 0xE > > +#define TWR_16 0xF > > + > > +#endif > > > > ...is it ok listing every possible value for DM parameter? > I mean, some of them would be 8-bit, this would mean having 256 cases, > that sound very ugly to me. It doesn't seem necessary to write all 256 cases. I would suggest to write the direct hex number. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 5/5] Add support for the NXP IMXRT1050-EVK board
Hi Fabio, On 11/1/19 1:40 PM, Fabio Estevam wrote: Hi Giulio, On Wed, Oct 30, 2019 at 6:09 PM Giulio Benetti wrote: Please add a commit log that briefly describes the board. Yes. Signed-off-by: Giulio Benetti --- arch/arm/dts/Makefile | 2 + arch/arm/dts/imxrt1050-evk.dts| 124 arch/arm/dts/imxrt1050.dtsi | 73 + arch/arm/mach-imx/imxrt/Kconfig | 11 + board/freescale/imxrt1050-evk/Kconfig | 19 ++ board/freescale/imxrt1050-evk/MAINTAINERS | 6 + board/freescale/imxrt1050-evk/Makefile| 6 + Please add a board/freescale/imxrt1050-evk/README that explains how to build, flash the U-Boot binary and boot. Right. board/freescale/imxrt1050-evk/imxrt1050-evk.c | 94 ++ configs/imxrt1050-evk_defconfig | 52 include/configs/imxrt1050-evk.h | 68 + include/dt-bindings/clock/imxrt-clock.h | 272 ++ 11 files changed, 727 insertions(+) create mode 100644 arch/arm/dts/imxrt1050-evk.dts create mode 100644 arch/arm/dts/imxrt1050.dtsi create mode 100644 board/freescale/imxrt1050-evk/Kconfig create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS create mode 100644 board/freescale/imxrt1050-evk/Makefile create mode 100644 board/freescale/imxrt1050-evk/imxrt1050-evk.c create mode 100644 configs/imxrt1050-evk_defconfig create mode 100644 include/configs/imxrt1050-evk.h create mode 100644 include/dt-bindings/clock/imxrt-clock.h This imxrt-clock.h header and the arch/arm/dts/imxrt1050.dts is common imxrt code and not related to the evk board, so better put them on a separate patch. Ok, already done since I'm working right on clock driver now. Thanks for reviewing my patches, can you also take a look at this [1]? Because I don't know how to proceed with sdram driver. Thanks in advance [1]: https://lists.denx.de/pipermail/u-boot/2019-October/388905.html Best regards -- Giulio Benetti Benetti Engineering sas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/5] WIP Add support for i.MXRT family
Hi Fabio, On 11/1/19 1:41 PM, Fabio Estevam wrote: Hi Giulio, On Wed, Oct 30, 2019 at 6:09 PM Giulio Benetti wrote: This patchset is a WIP for adding i.MXRT family. It provides: - soc family entry - pinctrl driver - serial driver tweaking - partial sdram controller driver - imxrt1050-evk board partial support Where do you store the U-Boot environment?Is there a eSDHC driver for it, for example? Yes, I want to use eSDHC to store there u-boot environment and I'm still working on it. -- Giulio Benetti Benetti Engineering sas ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Mon, Nov 04, 2019 at 04:44:18PM +0100, Wolfgang Denk wrote: > Dear Aaron, > > In message <2710076.TiSPtmOvtb@flash> you wrote: > > > > > What exactly do you need this for? Why don't you just link your > > > code with the rest of U-Boot? > > > > We need it to obtain and modify the phy parameters. This is a custom 25G > > gearbox that needs a lot of hand holding. This may end up being a low > > priority > > (not the gearbox, but the API). It's only a few hundred lines of code (the > > API). > > Again you don't answer my question. Why do you need a special new > API for such code? Why do you not just link that code with the rest > of U-Boot? > > It has been mentioned before, but just to be sure: this code which > uses your new API is licensed under a GPLv2 conforming lincense? And, to be blunt, if it is not, handling your non-GPLv2 applications via an EFI binary is the way forward, not extending the U-Boot binary ABI, in my opinion. -- 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 v5 00/19] efi_loader: non-volatile variables support
On Mon, Nov 04, 2019 at 05:00:03PM +0100, Wolfgang Denk wrote: > Dear Takahiro, > > In message <20191101060434.gv10...@linaro.org> you wrote: > > > > > This is even worse, as instead of adding a single argument to a > > > function call you are adding two full fucntion calls. > > > > > > But why would that be needed? > > > > > > U-Boot is strictly single tasking. You always know what the current > > > context is, and nobody will change it behind your back. > > > > > > And UEFI functions are not being called in random places, they are > > > limited to a small set of UEFI commands, right? So why do you not > > > just enter UEFI context when you start executing UEFI code, and > > > restore the rpevious state when returning to non-UEFI U-Boot? > > > > Can you elaborate What you mean by "entering UEFI context"? > > You wrote: > > | So do you always admit the following coding? > | ===8<=== > | (in some UEFI function) > | ... > | old_ctx = env_set_context(ctx_uefi); > | env_set(var, value); > | env_set_context(old_ctx); > | ... > | ===>8=== > > In this code, the function call ``env_set_context(ctx_uefi)'' would > enter the UEFI context, right? This is what I mean. > > > What I'm thinking of here is that we would add one more member field, which > > is a pointer to my "env_context," in GD and change it in env_set_context(). > > This can be defined even as an inline function. > > Yes, this is OK - I think I understood this already. > > What I mean is that such a call of env_set_context() is not needed > for each and every call of other env_*() functions. > > If I understand correctly, only the UEFI specific commands will > actually care about UEFI contexts - most likely no code outside > cmd/nvedit_efi.c ? > > So you have pretty clear entry and exit points into and from the > UEFI world, and it should be sufficient to set and restore this > context only then. > > > I don't see why you deny such a simple solution with lots of flexibility. > > I am concerned about code size and execution speed. So far, you did > not provide any such numbers, even though I repeatedly asked for the > size impact, especially for non-UEFI systems. > > Please keep in mind that there are many cases where we need access > to the environment already in SPL, and on all systems where security > plays any role we must have the same set of features enabled for the > environment code in SPL and TPL (if these need access to the > envronment) as in U-Boot proper, and memory is a precious resource > there. I too am very concerned that whatever we come up with here needs to have between zero and near-zero impact on the rest of the U-Boot world. We've once again hit the case where some boards don't build due to bugfixes increasing their binary size. And they aren't "no one uses these, we can drop them" boards either. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/5] regmap: Allow providing read/write callbacks through struct regmap_config
On 30/10/2019 02:48, Simon Glass wrote: Hi Jean-Jacques, On Fri, 27 Sep 2019 at 07:22, Jean-Jacques Hiblot wrote: Some linux drivers provide their own read/write functions to access data from/of the regmap. Adding support for it. Signed-off-by: Jean-Jacques Hiblot --- drivers/core/regmap.c | 12 include/regmap.h | 26 +++--- 2 files changed, 35 insertions(+), 3 deletions(-) This increases code size in SPL so should probably be controlled by a Kconfig. OK. Also I wonder if regmap should become a uclass if we are adding I don't see a real value in making a regmap a device. IMO It will just make things more complex than needed. JJ operations to it? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/19] efi_loader: non-volatile variables support
Dear Takahiro, In message <20191101060434.gv10...@linaro.org> you wrote: > > > This is even worse, as instead of adding a single argument to a > > function call you are adding two full fucntion calls. > > > > But why would that be needed? > > > > U-Boot is strictly single tasking. You always know what the current > > context is, and nobody will change it behind your back. > > > > And UEFI functions are not being called in random places, they are > > limited to a small set of UEFI commands, right? So why do you not > > just enter UEFI context when you start executing UEFI code, and > > restore the rpevious state when returning to non-UEFI U-Boot? > > Can you elaborate What you mean by "entering UEFI context"? You wrote: | So do you always admit the following coding? | ===8<=== | (in some UEFI function) | ... | old_ctx = env_set_context(ctx_uefi); | env_set(var, value); | env_set_context(old_ctx); | ... | ===>8=== In this code, the function call ``env_set_context(ctx_uefi)'' would enter the UEFI context, right? This is what I mean. > What I'm thinking of here is that we would add one more member field, which > is a pointer to my "env_context," in GD and change it in env_set_context(). > This can be defined even as an inline function. Yes, this is OK - I think I understood this already. What I mean is that such a call of env_set_context() is not needed for each and every call of other env_*() functions. If I understand correctly, only the UEFI specific commands will actually care about UEFI contexts - most likely no code outside cmd/nvedit_efi.c ? So you have pretty clear entry and exit points into and from the UEFI world, and it should be sufficient to set and restore this context only then. > I don't see why you deny such a simple solution with lots of flexibility. I am concerned about code size and execution speed. So far, you did not provide any such numbers, even though I repeatedly asked for the size impact, especially for non-UEFI systems. Please keep in mind that there are many cases where we need access to the environment already in SPL, and on all systems where security plays any role we must have the same set of features enabled for the environment code in SPL and TPL (if these need access to the envronment) as in U-Boot proper, and memory is a precious resource there. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You may call me by my name, Wirth, or by my value, Worth. - Nicklaus Wirth ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Aaron, In message <2710076.TiSPtmOvtb@flash> you wrote: > > > What exactly do you need this for? Why don't you just link your > > code with the rest of U-Boot? > > We need it to obtain and modify the phy parameters. This is a custom 25G > gearbox that needs a lot of hand holding. This may end up being a low > priority > (not the gearbox, but the API). It's only a few hundred lines of code (the > API). Again you don't answer my question. Why do you need a special new API for such code? Why do you not just link that code with the rest of U-Boot? It has been mentioned before, but just to be sure: this code which uses your new API is licensed under a GPLv2 conforming lincense? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you believe that feeling bad or worrying long enough will change a past or future event, then you are residing on another planet with a different reality system. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 16/17] binman: Move to use Python 3
On Thu, Oct 31, 2019 at 10:12:04AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 31 Oct 2019 at 09:50, Tom Rini wrote: > > > > On Thu, Oct 31, 2019 at 09:19:50AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 31 Oct 2019 at 07:55, Tom Rini wrote: > > > > > > > > On Thu, Oct 31, 2019 at 07:43:05AM -0600, Simon Glass wrote: > > > > > > > > > Update this tool to use Python 3 to meet the 2020 deadline. > > > > > > > > > > Unfortunately this introduces a test failure due to a problem in > > > > > pylibfdt > > > > > on Python 3. I will investigate. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Add a few more patches to correct remaining problems > > > > > > > > Is there still a failure or did you fix it? If there still is, what > > > > board(s) make use of that feature? Thanks! > > > > > > > > > > Everything works fine now, so far as I can tell. The pylibfdt fix was > > > accepted upstream, too. > > > > OK, so a v3 to fix the commit message :) Do you want to pull all of > > this together in the end and give me a PR or do you want me to (and kick > > Azure/Travis/GitLab as needed) ? > > Ooops, OK, will do. > > I am happy to do either. I got a successful run. The latest one is > going here, but only has commit-message changes: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1181 OK. Can you please put together a fdt PR with those changes and then I'll grab all of the rest of the Python stuff and make sure all the CIs pass? Thanks again! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 050/108] x86: Set the DRAM banks to reflect real location
On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > At present with fsp a single DRAM bank is added which extends to the > whole size of memory. However there is typically only 2GB of memory > available below the 4GB boundary, and this is what is used by U-Boot while > running in 32-bit mode. > > Scan the tables to set the banks correct. The first bank is set to memory > below 4GB, and the rest of memory is put into subsequent banks. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Move mtrr_add_request() call to next patch > > Changes in v2: None > > arch/x86/lib/fsp/fsp_dram.c | 30 +- > 1 file changed, 29 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 048/108] x86: Add mrccache support for a 'variable' cache
On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > Add support for a second cache type, for apollolake. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Move the mrccache_get_region() change into this patch > > Changes in v2: None > > arch/x86/include/asm/mrccache.h | 1 + > arch/x86/lib/mrccache.c | 3 ++- > 2 files changed, 3 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 047/108] x86: Update mrccache to support multiple caches
On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote: > > With apollolake we need to support a normal cache, which almost never > changes and a much smaller 'variable' cache which changes every time. > > Update the code to add a cache type, use an array for the caches and use a > for loop to iterate over the caches. > > Signed-off-by: Simon Glass > --- > > Changes in v3: > - Move line related to variable-cache into the next patch > > Changes in v2: None > > arch/x86/cpu/broadwell/sdram.c | 8 ++- > arch/x86/cpu/ivybridge/sdram.c | 8 ++- > arch/x86/cpu/quark/dram.c | 8 ++- > arch/x86/include/asm/global_data.h | 21 +-- > arch/x86/include/asm/mrccache.h| 11 +++- > arch/x86/lib/fsp/fsp_common.c | 2 +- > arch/x86/lib/fsp1/fsp_dram.c | 8 ++- > arch/x86/lib/mrccache.c| 88 -- > 8 files changed, 106 insertions(+), 48 deletions(-) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] drivers: reset: Add a managed API to get reset controllers from the DT
On 30/10/2019 02:48, Simon Glass wrote: On Mon, 30 Sep 2019 at 10:15, Jean-Jacques Hiblot wrote: Add managed functions to get a reset_ctl from the device-tree, based on a name or an index. Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl) from the device-tree. When the device is unbound, the reset controllers are automatically released and the data structure is freed. Signed-off-by: Jean-Jacques Hiblot --- drivers/reset/reset-uclass.c | 116 +- include/reset.h | 135 ++- 2 files changed, 247 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass I really don't like these ERR_PTR returns. I suppose they make the code easier to port, and we can be sure that pointers will not be in the last 4KB of address space? It seems rather unlikely because the returned pointer points to actual RAM allocated from the heap. On most platforms I've worked with, the top of the address space is not dedicated to memory. If ever the need to fix this arises it could done by tweaking the macros to use another unused address space. JJ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] MAINTAINERS: change colibri_imx6/imx6ull/t30/vf maintainers
On 2019-11-04 12:56, Igor Opaniuk wrote: > From: Igor Opaniuk > > Take over maintainership for colibri_imx6/imx6ull/t30/vf modules. > > Signed-off-by: Igor Opaniuk Acked-by: Stefan Agner Thanks for looking after those boards! -- Stefan > --- > > board/toradex/colibri-imx6ull/MAINTAINERS | 2 +- > board/toradex/colibri_imx7/MAINTAINERS| 2 +- > board/toradex/colibri_t30/MAINTAINERS | 2 +- > board/toradex/colibri_vf/MAINTAINERS | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS > b/board/toradex/colibri-imx6ull/MAINTAINERS > index c8199fa60a..4107d29876 100644 > --- a/board/toradex/colibri-imx6ull/MAINTAINERS > +++ b/board/toradex/colibri-imx6ull/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri iMX6ULL > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > diff --git a/board/toradex/colibri_imx7/MAINTAINERS > b/board/toradex/colibri_imx7/MAINTAINERS > index cd0f9c9b2d..178dece797 100644 > --- a/board/toradex/colibri_imx7/MAINTAINERS > +++ b/board/toradex/colibri_imx7/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri iMX7 > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained > diff --git a/board/toradex/colibri_t30/MAINTAINERS > b/board/toradex/colibri_t30/MAINTAINERS > index 73b8e5d099..00c03c89b8 100644 > --- a/board/toradex/colibri_t30/MAINTAINERS > +++ b/board/toradex/colibri_t30/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri T30 > -M: Stefan Agner > +M: Igor Opaniuk > S: Maintained > F: board/toradex/colibri_t30/ > F: include/configs/colibri_t30.h > diff --git a/board/toradex/colibri_vf/MAINTAINERS > b/board/toradex/colibri_vf/MAINTAINERS > index 66b2150986..f94cc0fbe2 100644 > --- a/board/toradex/colibri_vf/MAINTAINERS > +++ b/board/toradex/colibri_vf/MAINTAINERS > @@ -1,5 +1,5 @@ > Colibri VFxx > -M: Stefan Agner > +M: Igor Opaniuk > W: http://developer.toradex.com/software/linux/linux-software > W: https://www.toradex.com/community > S: Maintained ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 043/108] x86: Adjust mrccache_get_region() to use livetree
Hi Simon,
On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote:
>
> Change the algorithm to first find the flash device then read the
> properties using the livetree API. With this change the device is not
> probed so this needs to be done in mrccache_save().
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Update mrccache livetree patch to just convert to livetree
>
> Changes in v2: None
>
> arch/x86/lib/mrccache.c | 55 +++--
> 1 file changed, 26 insertions(+), 29 deletions(-)
>
> diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
> index 7292d1fe070..b8bc5de602c 100644
> --- a/arch/x86/lib/mrccache.c
> +++ b/arch/x86/lib/mrccache.c
> @@ -14,6 +14,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -201,45 +203,37 @@ int mrccache_reserve(void)
>
> int mrccache_get_region(struct udevice **devp, struct mrc_region *entry)
> {
> - const void *blob = gd->fdt_blob;
> - int node, mrc_node;
> + struct udevice *dev;
> + ofnode mrc_node;
> u32 reg[2];
> int ret;
>
> - /* Find the flash chip within the SPI controller node */
> - node = fdtdec_next_compatible(blob, 0, COMPAT_GENERIC_SPI_FLASH);
> - if (node < 0) {
> - debug("%s: Cannot find SPI flash\n", __func__);
> - return -ENOENT;
> - }
> -
> - if (fdtdec_get_int_array(blob, node, "memory-map", reg, 2)) {
> - debug("%s: Cannot find memory map\n", __func__);
> - return -EINVAL;
> - }
> + /*
> +* Find the flash chip within the SPI controller node. Avoid probing
> +* the device here since it may put it into a strange state where the
> +* memory map cannot be read.
> +*/
> + ret = uclass_find_first_device(UCLASS_SPI_FLASH, );
Adding probe of UCLASS_SPI_FLASH should be in the next patch:
[U-Boot,v3,044/108] x86: Adjust mrccache_get_region() to support get_mmap()
> + if (ret)
> + return log_msg_ret("Cannot find SPI flash\n", ret);
> + ret = dev_read_u32_array(dev, "memory-map", reg, 2);
> + if (ret)
> + return log_msg_ret("Cannot find memory map\n", ret);
> entry->base = reg[0];
>
> /* Find the place where we put the MRC cache */
> - mrc_node = fdt_subnode_offset(blob, node, "rw-mrc-cache");
> - if (mrc_node < 0) {
> - debug("%s: Cannot find node\n", __func__);
> - return -EPERM;
> - }
> + mrc_node = dev_read_subnode(dev, "rw-mrc-cache");
> + if (!ofnode_valid(mrc_node))
> + return log_msg_ret("Cannot find node", -EPERM);
>
> - if (fdtdec_get_int_array(blob, mrc_node, "reg", reg, 2)) {
> - debug("%s: Cannot find address\n", __func__);
> - return -EINVAL;
> - }
> + ret = ofnode_read_u32_array(mrc_node, "reg", reg, 2);
> + if (ret)
> + return log_msg_ret("Cannot find address", ret);
> entry->offset = reg[0];
> entry->length = reg[1];
>
> - if (devp) {
> - ret = uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node,
> -devp);
> - debug("ret = %d\n", ret);
> - if (ret)
> - return ret;
> - }
> + if (devp)
> + *devp = dev;
>
> return 0;
> }
> @@ -257,6 +251,9 @@ int mrccache_save(void)
> gd->arch.mrc_output_len);
>
> ret = mrccache_get_region(, );
> + if (ret)
> + goto err_entry;
> + ret = device_probe(sf);
This needs a comment as we discussed in v2, or maybe it should also go
into next patch?
> if (ret)
> goto err_entry;
> data = (struct mrc_data_container *)gd->arch.mrc_output;
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 042/108] x86: Correct mrccache find_next_mrc_cache() calculation
Hi Simon,
On Mon, Oct 21, 2019 at 11:40 AM Simon Glass wrote:
>
> This should take account of the end of the new cache record since a record
> cannot extend beyond the end of the flash region. This problem was not
> seen before due to the alignment of the relatively small amount of MRC
> data.
>
> But with apollolake the MRC data is about 45KB, even if most of it is
> zeroes.
>
> Fix this bug and update the parameter name to be less confusing.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v3:
> - Add an extra size parameter to the find_next_mrc_cache() function
>
> Changes in v2: None
>
> arch/x86/lib/mrccache.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/lib/mrccache.c b/arch/x86/lib/mrccache.c
> index 33bb52039bd..7292d1fe070 100644
> --- a/arch/x86/lib/mrccache.c
> +++ b/arch/x86/lib/mrccache.c
> @@ -80,21 +80,26 @@ struct mrc_data_container *mrccache_find_current(struct
> mrc_region *entry)
> /**
> * find_next_mrc_cache() - get next cache entry
> *
> + * This moves to the next cache entry in the region, making sure it has
> enough
> + * space to hold data of size @data_size.
> + *
> * @entry: MRC cache flash area
> * @cache: Entry to start from
> + * @data_size: Required data size of the new entry
> *
> * @return next cache entry if found, NULL if we got to the end
> */
> static struct mrc_data_container *find_next_mrc_cache(struct mrc_region
> *entry,
> - struct mrc_data_container *cache)
> + struct mrc_data_container *prev, int data_size)
> {
> + struct mrc_data_container *cache;
> ulong base_addr, end_addr;
>
> base_addr = entry->base + entry->offset;
> end_addr = base_addr + entry->length;
>
> - cache = next_mrc_block(cache);
> - if ((ulong)cache >= end_addr) {
> + cache = next_mrc_block(prev);
> + if ((ulong)cache + mrc_block_size(prev->data_size) > end_addr) {
It takes me another several minutes to understand this, as I was
confused by the v2 patch :)
So in v2 we agreed to add some comments here, as we assume the
data_size will be the same.
> /* Crossed the boundary */
> cache = NULL;
> debug("%s: no available entries found\n", __func__);
> @@ -131,7 +136,7 @@ int mrccache_update(struct udevice *sf, struct mrc_region
> *entry,
>
> /* Move to the next block, which will be the first unused block */
> if (cache)
> - cache = find_next_mrc_cache(entry, cache);
> + cache = find_next_mrc_cache(entry, cache, cur->data_size);
>
> /*
> * If we have got to the end, erase the entire mrc-cache area and
> start
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mx6: Allow configuring the NoC registers on i.MX6QP
On 04/11/19 13:44, Fabio Estevam wrote:
> The NoC registers on i.MX6QP needs to be configured, otherwise some
> usecases in the kernel behave incorrectly, such as rotation and resize.
>
> Currently the NoC registers are not configured in the kernel, so
> configure them in U-Boot like it is done in the NXP U-Boot tree.
>
> Signed-off-by: Fabio Estevam
> Reviewed-by: Peng Fan
> ---
> Changes since v1:
> - Fix the build on mx6sxsabresd_defconfig (Stefano)
>
> arch/arm/mach-imx/mx6/soc.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
> index 6dccee484c..3671d3182b 100644
> --- a/arch/arm/mach-imx/mx6/soc.c
> +++ b/arch/arm/mach-imx/mx6/soc.c
> @@ -374,6 +374,37 @@ static void init_bandgap(void)
> }
> }
>
> +#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6QDL)
> +static void noc_setup(void)
> +{
> + enable_ipu_clock();
> +
> + writel(0x8201, 0xbb0608);
> + /* Bypass IPU1 QoS generator */
> + writel(0x0002, 0x00bb048c);
> + /* Bypass IPU2 QoS generator */
> + writel(0x0002, 0x00bb050c);
> + /* Bandwidth THR for of PRE0 */
> + writel(0x0200, 0x00bb0690);
> + /* Bandwidth THR for of PRE1 */
> + writel(0x0200, 0x00bb0710);
> + /* Bandwidth THR for of PRE2 */
> + writel(0x0200, 0x00bb0790);
> + /* Bandwidth THR for of PRE3 */
> + writel(0x0200, 0x00bb0810);
> + /* Saturation THR for of PRE0 */
> + writel(0x0010, 0x00bb0694);
> + /* Saturation THR for of PRE1 */
> + writel(0x0010, 0x00bb0714);
> + /* Saturation THR for of PRE2 */
> + writel(0x0010, 0x00bb0794);
> + /* Saturation THR for of PRE */
> + writel(0x0010, 0x00bb0814);
> +
> + disable_ipu_clock();
> +}
> +#endif
> +
> int arch_cpu_init(void)
> {
> struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> @@ -451,6 +482,10 @@ int arch_cpu_init(void)
>
> init_src();
>
> +#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6QDL)
> + if (is_mx6dqp())
> + noc_setup();
> +#endif
> return 0;
> }
>
>
Reviewed-by: Stefano Babic
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] mx6: Allow configuring the NoC registers on i.MX6QP
Hi Stefano, On Sun, Nov 3, 2019 at 1:06 PM Stefano Babic wrote: > I found a good reason why they were out. Patch 4 breaks the build for > mx6sxsabresd because enable_[disable]ipu is called (of course, it should > not be). > > Could you take a look and repost ? Thanks ! Thanks for the feedback. I have fixed it and submitted a v2. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] mx6: Allow configuring the NoC registers on i.MX6QP
The NoC registers on i.MX6QP needs to be configured, otherwise some
usecases in the kernel behave incorrectly, such as rotation and resize.
Currently the NoC registers are not configured in the kernel, so
configure them in U-Boot like it is done in the NXP U-Boot tree.
Signed-off-by: Fabio Estevam
Reviewed-by: Peng Fan
---
Changes since v1:
- Fix the build on mx6sxsabresd_defconfig (Stefano)
arch/arm/mach-imx/mx6/soc.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 6dccee484c..3671d3182b 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -374,6 +374,37 @@ static void init_bandgap(void)
}
}
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6QDL)
+static void noc_setup(void)
+{
+ enable_ipu_clock();
+
+ writel(0x8201, 0xbb0608);
+ /* Bypass IPU1 QoS generator */
+ writel(0x0002, 0x00bb048c);
+ /* Bypass IPU2 QoS generator */
+ writel(0x0002, 0x00bb050c);
+ /* Bandwidth THR for of PRE0 */
+ writel(0x0200, 0x00bb0690);
+ /* Bandwidth THR for of PRE1 */
+ writel(0x0200, 0x00bb0710);
+ /* Bandwidth THR for of PRE2 */
+ writel(0x0200, 0x00bb0790);
+ /* Bandwidth THR for of PRE3 */
+ writel(0x0200, 0x00bb0810);
+ /* Saturation THR for of PRE0 */
+ writel(0x0010, 0x00bb0694);
+ /* Saturation THR for of PRE1 */
+ writel(0x0010, 0x00bb0714);
+ /* Saturation THR for of PRE2 */
+ writel(0x0010, 0x00bb0794);
+ /* Saturation THR for of PRE */
+ writel(0x0010, 0x00bb0814);
+
+ disable_ipu_clock();
+}
+#endif
+
int arch_cpu_init(void)
{
struct mxc_ccm_reg *ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
@@ -451,6 +482,10 @@ int arch_cpu_init(void)
init_src();
+#if defined(CONFIG_MX6Q) || defined(CONFIG_MX6QDL)
+ if (is_mx6dqp())
+ noc_setup();
+#endif
return 0;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] rockchip: make_fit_atf.py: allow inclusion of a tee binary
Hi Simon, Am Mittwoch, 30. Oktober 2019, 02:49:46 CET schrieb Simon Glass: > On Tue, 22 Oct 2019 at 03:45, Kever Yang wrote: > > On 2019/10/22 上午7:46, Simon Glass wrote: > > > On Mon, 14 Oct 2019 at 03:07, Kever Yang > > > wrote: > > >> > > >> On 2019/10/7 上午2:10, Heiko Stuebner wrote: > > >>> A trusted execution environment should also get loaded as loadable from > > >>> a fit image, so add the possibility to present a tee.elf to > > >>> make_fit_atf.py > > >>> that then gets included as additional loadable into the generated its. > > >>> > > >>> For ease of integration the additional loadable is created as atf_(x+1) > > >>> after all others to re-use core generation loops. > > >>> > > >>> Tested against the combinations of 1-part-atf and multi-part-atf each > > >>> time with and without a tee binary present. > > >>> > > >>> Signed-off-by: Heiko Stuebner > > >> Reviewed-by: Kever Yang > > >> > > >> > > >> Thanks, > > >> - Kever > > >>> --- > > >>> changes in v2: none > > >>> > > >>>arch/arm/mach-rockchip/make_fit_atf.py | 52 > > >>> +++--- > > >>>1 file changed, 46 insertions(+), 6 deletions(-) > > > I see there is an effort to move this to binman. To me that is a much > > > more productive approach! > > > > > > Do you mean the patch set from Jagan for rockchip platform to using binman? > > > > That patch is actually using the output of the u-boot.itb which is based > > on this script. > > > > > > > > Is there a feature or example missing in binman that you need to get > > > this over the hump? > > > > > > I think Heiko and you has a discussion about this in previous version > > thread. > > The U-Boot project build output is: tpl.bin, spl.bin, u-boot.bin > > For rockchip platform, package needs: > > - pack tpl.bin+spl.bin with mkimage -rksd/rkspi into idbloader.img > > - get ATF binaries from bl31.bin/optee.bin with a script > > - generate u-boot.its to describe the u-boot.itb > > - pack u-boot.bin and ATF/OPTEE binaries into u-boot.itb with mkimage -f > > u-boot.its > > > > Does the binman mainly target for pack the idbloader.img+u-boot.itb? > > I actually think binman could handle all of that. > > Is there something I could do that would help with that? I think the main sparse element is time here and maybe a voluteer with enough of time available to lay the groundwork. Like on my personal side, I really don't see me finding the time to actually look at binman and finding out how everything should translate from the current state to binman - soonish. Hooking up new small things into an existing infrastructure is somehow alway easier ;-) . Heiko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] MAINTAINERS: change colibri_imx6/imx6ull/t30/vf maintainers
On Mon, 2019-11-04 at 12:56 +0100, Igor Opaniuk wrote: > From: Igor Opaniuk > > Take over maintainership for colibri_imx6/imx6ull/t30/vf modules. > > Signed-off-by: Igor Opaniuk Acked-by: Max Krummenacher ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/2] MAINTAINERS: change apalis_imx6/colibri_imx6 maintainers
On Mon, 2019-11-04 at 12:56 +0100, Igor Opaniuk wrote: > From: Igor Opaniuk > > Take over maintainership for apalis_imx6 and colibri_imx6 modules. > > Signed-off-by: Igor Opaniuk Acked-by: Max Krummenacher ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] MAINTAINERS: change apalis_imx6/colibri_imx6 maintainers
From: Igor Opaniuk Take over maintainership for apalis_imx6 and colibri_imx6 modules. Signed-off-by: Igor Opaniuk --- board/toradex/apalis_imx6/MAINTAINERS | 2 +- board/toradex/colibri_imx6/MAINTAINERS | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/toradex/apalis_imx6/MAINTAINERS b/board/toradex/apalis_imx6/MAINTAINERS index 7efe816a78..4a2707e771 100644 --- a/board/toradex/apalis_imx6/MAINTAINERS +++ b/board/toradex/apalis_imx6/MAINTAINERS @@ -1,5 +1,5 @@ Apalis iMX6 -M: Max Krummenacher +M: Igor Opaniuk W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained diff --git a/board/toradex/colibri_imx6/MAINTAINERS b/board/toradex/colibri_imx6/MAINTAINERS index e25c07306c..76f9446bba 100644 --- a/board/toradex/colibri_imx6/MAINTAINERS +++ b/board/toradex/colibri_imx6/MAINTAINERS @@ -1,5 +1,5 @@ Colibri iMX6 -M: Max Krummenacher +M: Igor Opaniuk W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] MAINTAINERS: change colibri_imx6/imx6ull/t30/vf maintainers
From: Igor Opaniuk Take over maintainership for colibri_imx6/imx6ull/t30/vf modules. Signed-off-by: Igor Opaniuk --- board/toradex/colibri-imx6ull/MAINTAINERS | 2 +- board/toradex/colibri_imx7/MAINTAINERS| 2 +- board/toradex/colibri_t30/MAINTAINERS | 2 +- board/toradex/colibri_vf/MAINTAINERS | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/board/toradex/colibri-imx6ull/MAINTAINERS b/board/toradex/colibri-imx6ull/MAINTAINERS index c8199fa60a..4107d29876 100644 --- a/board/toradex/colibri-imx6ull/MAINTAINERS +++ b/board/toradex/colibri-imx6ull/MAINTAINERS @@ -1,5 +1,5 @@ Colibri iMX6ULL -M: Stefan Agner +M: Igor Opaniuk W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained diff --git a/board/toradex/colibri_imx7/MAINTAINERS b/board/toradex/colibri_imx7/MAINTAINERS index cd0f9c9b2d..178dece797 100644 --- a/board/toradex/colibri_imx7/MAINTAINERS +++ b/board/toradex/colibri_imx7/MAINTAINERS @@ -1,5 +1,5 @@ Colibri iMX7 -M: Stefan Agner +M: Igor Opaniuk W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained diff --git a/board/toradex/colibri_t30/MAINTAINERS b/board/toradex/colibri_t30/MAINTAINERS index 73b8e5d099..00c03c89b8 100644 --- a/board/toradex/colibri_t30/MAINTAINERS +++ b/board/toradex/colibri_t30/MAINTAINERS @@ -1,5 +1,5 @@ Colibri T30 -M: Stefan Agner +M: Igor Opaniuk S: Maintained F: board/toradex/colibri_t30/ F: include/configs/colibri_t30.h diff --git a/board/toradex/colibri_vf/MAINTAINERS b/board/toradex/colibri_vf/MAINTAINERS index 66b2150986..f94cc0fbe2 100644 --- a/board/toradex/colibri_vf/MAINTAINERS +++ b/board/toradex/colibri_vf/MAINTAINERS @@ -1,5 +1,5 @@ Colibri VFxx -M: Stefan Agner +M: Igor Opaniuk W: http://developer.toradex.com/software/linux/linux-software W: https://www.toradex.com/community S: Maintained -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 3/6] ARM: dts: imx6_apalis: introduce fec node
From: Igor Opaniuk
Sync DTS with the mainline Linux and introduce fec node.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx6-apalis.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/dts/imx6-apalis.dts b/arch/arm/dts/imx6-apalis.dts
index b2fdfa1af4..72f7439aed 100644
--- a/arch/arm/dts/imx6-apalis.dts
+++ b/arch/arm/dts/imx6-apalis.dts
@@ -22,6 +22,7 @@
mmc1 =
mmc2 =
usb0 = /* required for ums */
+ ethernet0 =
};
chosen {
@@ -197,6 +198,27 @@
status = "okay";
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet>;
+ phy-mode = "rgmii";
+ phy-handle = <>;
+ phy-reset-duration = <10>;
+ phy-reset-gpios = < 25 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy@7 {
+ interrupt-parent = <>;
+ interrupts = <30 IRQ_TYPE_LEVEL_LOW>;
+ reg = <7>;
+ };
+ };
+};
+
/* Apalis Serial ATA */
{
status = "okay";
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 6/6] colibri_imx7: migrate to DM_ETH
From: Igor Opaniuk
Migrate to DM_ETH and remove hardcoded pinmux configuration.
Signed-off-by: Igor Opaniuk
---
board/toradex/colibri_imx7/colibri_imx7.c | 44 ---
configs/colibri_imx7_defconfig| 5 ++-
configs/colibri_imx7_emmc_defconfig | 5 ++-
include/configs/colibri_imx7.h| 11 --
4 files changed, 8 insertions(+), 57 deletions(-)
diff --git a/board/toradex/colibri_imx7/colibri_imx7.c
b/board/toradex/colibri_imx7/colibri_imx7.c
index c001316591..3ef381da1a 100644
--- a/board/toradex/colibri_imx7/colibri_imx7.c
+++ b/board/toradex/colibri_imx7/colibri_imx7.c
@@ -159,50 +159,12 @@ void board_preboot_os(void)
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
- MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL) |
MUX_MODE_SION,
-#else
- MX7D_PAD_GPIO1_IO12__CCM_ENET_REF_CLK1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
-#endif
- MX7D_PAD_SD2_CD_B__ENET1_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
- MX7D_PAD_SD2_WP__ENET1_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL_MII),
- MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RXC__ENET1_RX_ER | MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL |
MUX_PAD_CTRL(ENET_RX_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD0__ENET1_RGMII_TD0 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TD1__ENET1_RGMII_TD1 | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX7D_PAD_ENET1_RGMII_TX_CTL__ENET1_RGMII_TX_CTL |
MUX_PAD_CTRL(ENET_PAD_CTRL),
-};
-
-static void setup_iomux_fec(void)
-{
- imx_iomux_v3_setup_multiple_pads(fec1_pads, ARRAY_SIZE(fec1_pads));
-}
-#endif
-
static void setup_iomux_uart(void)
{
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
}
#ifdef CONFIG_FEC_MXC
-int board_eth_init(bd_t *bis)
-{
- int ret;
-
- setup_iomux_fec();
-
- ret = fecmxc_initialize_multi(bis, 0,
- CONFIG_FEC_MXC_PHYADDR, IMX_FEC_BASE);
- if (ret)
- printf("FEC1 MXC: %s:failed\n", __func__);
-
- return ret;
-}
-
static int setup_fec(void)
{
struct iomuxc_gpr_base_regs *const iomuxc_gpr_regs
@@ -226,12 +188,6 @@ static int setup_fec(void)
return set_clk_enet(ENET_50MHZ);
}
-int board_phy_config(struct phy_device *phydev)
-{
- if (phydev->drv->config)
- phydev->drv->config(phydev);
- return 0;
-}
#endif
int board_early_init_f(void)
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index a6457d5054..504af04b7b 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -2,11 +2,11 @@ CONFIG_ARM=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MX7=y
CONFIG_SYS_TEXT_BASE=0x8780
-CONFIG_IMX_HAB=y
CONFIG_TARGET_COLIBRI_IMX7=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
+CONFIG_IMX_HAB=y
# CONFIG_CMD_DEKBLOB is not set
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
@@ -62,6 +62,9 @@ CONFIG_MTD_UBI_FASTMAP=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_FEC_MXC=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
diff --git a/configs/colibri_imx7_emmc_defconfig
b/configs/colibri_imx7_emmc_defconfig
index b4ca115f13..eee39c70d9 100644
--- a/configs/colibri_imx7_emmc_defconfig
+++ b/configs/colibri_imx7_emmc_defconfig
@@ -2,12 +2,12 @@ CONFIG_ARM=y
CONFIG_SYS_THUMB_BUILD=y
CONFIG_ARCH_MX7=y
CONFIG_SYS_TEXT_BASE=0x8780
-CONFIG_IMX_HAB=y
CONFIG_TARGET_COLIBRI_IMX7=y
CONFIG_TARGET_COLIBRI_IMX7_EMMC=y
CONFIG_ARMV7_BOOT_SEC_DEFAULT=y
CONFIG_IMX_RDC=y
CONFIG_IMX_BOOTAUX=y
+CONFIG_IMX_HAB=y
# CONFIG_CMD_DEKBLOB is not set
CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
@@ -58,6 +58,9 @@ CONFIG_FSL_USDHC=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_FEC_MXC=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX7=y
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index c2d98291b0..9cb07c08f3 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -16,17 +16,6 @@
/* Size of malloc() pool */
#define CONFIG_SYS_MALLOC_LEN (32 * SZ_1M)
-/* Network */
-#define CONFIG_FEC_MXC
-#define CONFIG_FEC_XCV_TYPE RMII
-#define CONFIG_ETHPRIME "FEC"
-#define CONFIG_FEC_MXC_PHYADDR 0
-
-#define CONFIG_TFTP_TSIZE
-
-/* ENET1 */
-#define IMX_FEC_BASE ENET_IPS_BASE_ADDR
-
/* MMC Config*/
#define CONFIG_SYS_FSL_ESDHC_ADDR 0
#ifdef CONFIG_TARGET_COLIBRI_IMX7_NAND
--
2.17.1
___
[U-Boot] [PATCH v1 2/6] colibri_imx6: migrate to DM_ETH
From: Igor Opaniuk
Migrate to DM_ETH and remove hardcoded pinmux configuration.
Signed-off-by: Igor Opaniuk
---
board/toradex/colibri_imx6/colibri_imx6.c | 59 ++-
configs/colibri_imx6_defconfig| 3 ++
include/configs/colibri_imx6.h| 8 ---
3 files changed, 7 insertions(+), 63 deletions(-)
diff --git a/board/toradex/colibri_imx6/colibri_imx6.c
b/board/toradex/colibri_imx6/colibri_imx6.c
index ad40b589c1..64295a42e5 100644
--- a/board/toradex/colibri_imx6/colibri_imx6.c
+++ b/board/toradex/colibri_imx6/colibri_imx6.c
@@ -51,9 +51,6 @@ DECLARE_GLOBAL_DATA_PTR;
PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
PAD_CTL_SRE_FAST | PAD_CTL_HYS)
-#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
- PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
-
#define WEAK_PULLUP(PAD_CTL_PUS_100K_UP | \
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \
PAD_CTL_SRE_SLOW)
@@ -112,24 +109,6 @@ iomux_v3_cfg_t const usdhc3_pads[] = {
};
#endif /* CONFIG_FSL_ESDHC_IMX & CONFIG_SPL_BUILD */
-iomux_v3_cfg_t const enet_pads[] = {
- MX6_PAD_ENET_MDC__ENET_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_MDIO__ENET_MDIO| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_RXD0__ENET_RX_DATA0| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_RXD1__ENET_RX_DATA1| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_RX_ER__ENET_RX_ER | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_TX_EN__ENET_TX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_TXD0__ENET_TX_DATA0| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_TXD1__ENET_TX_DATA1| MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_ENET_CRS_DV__ENET_RX_EN | MUX_PAD_CTRL(ENET_PAD_CTRL),
- MX6_PAD_GPIO_16__ENET_REF_CLK | MUX_PAD_CTRL(ENET_PAD_CTRL),
-};
-
-static void setup_iomux_enet(void)
-{
- imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
-}
-
/* mux auxiliary pins to GPIO, so they can be used from the U-Boot cmdline */
iomux_v3_cfg_t const gpio_pads[] = {
/* ADDRESS[17:18] [25] used as GPIO */
@@ -371,12 +350,8 @@ int board_phy_config(struct phy_device *phydev)
return 0;
}
-int board_eth_init(bd_t *bis)
+int setup_fec(void)
{
- struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
- uint32_t base = IMX_FEC_BASE;
- struct mii_dev *bus = NULL;
- struct phy_device *phydev = NULL;
int ret;
/* provide the PHY clock from the i.MX 6 */
@@ -384,34 +359,6 @@ int board_eth_init(bd_t *bis)
if (ret)
return ret;
- /* set gpr1[ENET_CLK_SEL] */
- setbits_le32(_regs->gpr[1], IOMUXC_GPR1_ENET_CLK_SEL_MASK);
-
- setup_iomux_enet();
-
-#ifdef CONFIG_FEC_MXC
- bus = fec_get_miibus(base, -1);
- if (!bus)
- return 0;
-
- /* scan PHY 1..7 */
- phydev = phy_find_by_mask(bus, 0xff, PHY_INTERFACE_MODE_RMII);
- if (!phydev) {
- free(bus);
- puts("no PHY found\n");
- return 0;
- }
-
- phy_reset(phydev);
- printf("using PHY at %d\n", phydev->addr);
- ret = fec_probe(bis, -1, base, bus, phydev);
- if (ret) {
- printf("FEC MXC: %s:failed\n", __func__);
- free(phydev);
- free(bus);
- }
-#endif /* CONFIG_FEC_MXC */
-
return 0;
}
@@ -633,7 +580,9 @@ int board_init(void)
{
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
-
+#if defined(CONFIG_FEC_MXC)
+ setup_fec();
+#endif
#if defined(CONFIG_VIDEO_IPUV3)
setup_display();
#endif
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 4f7ca7b91d..647564a03a 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -62,6 +62,9 @@ CONFIG_FSL_USDHC=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_FEC_MXC=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h
index 1f2b89e722..390052362b 100644
--- a/include/configs/colibri_imx6.h
+++ b/include/configs/colibri_imx6.h
@@ -43,14 +43,6 @@
#define CONFIG_SYS_FSL_ESDHC_ADDR 0
#define CONFIG_SYS_FSL_USDHC_NUM 2
-/* Network */
-#define CONFIG_FEC_MXC
-#define IMX_FEC_BASE ENET_BASE_ADDR
-#define CONFIG_FEC_XCV_TYPERMII
-#define CONFIG_ETHPRIME"FEC"
-#define CONFIG_FEC_MXC_PHYADDR 1
-#define CONFIG_TFTP_TSIZE
-
/* USB Configs */
/* Host */
#define CONFIG_USB_MAX_CONTROLLER_COUNT2
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
[U-Boot] [PATCH v1 5/6] ARM: dts: imx7: imx7_colibri: introduce fec node
From: Igor Opaniuk
Sync DTS with the mainline Linux and introduce fec node and
regulator configuration for rn5t567 PMU.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx7-colibri.dtsi | 116 +
arch/arm/dts/imx7d.dtsi| 3 +
arch/arm/dts/imx7s.dtsi| 1 +
3 files changed, 120 insertions(+)
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index 308e0b2a63..ec95f22a0c 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -18,6 +18,70 @@
rn5t567@33 {
compatible = "ricoh,rn5t567";
reg = <0x33>;
+
+ regulators {
+ reg_DCDC1: DCDC1 { /* V1.0_SOC */
+ regulator-min-microvolt = <100>;
+ regulator-max-microvolt = <110>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_DCDC2: DCDC2 { /* V1.1_ARM */
+ regulator-min-microvolt = <975000>;
+ regulator-max-microvolt = <110>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_DCDC3: DCDC3 { /* V1.8 */
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_DCDC4: DCDC4 { /* V1.35_DRAM */
+ regulator-min-microvolt = <135>;
+ regulator-max-microvolt = <135>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_LDO1: LDO1 { /* PWR_EN_+V3.3_ETH */
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ };
+
+ reg_LDO2: LDO2 { /* +V1.8_SD */
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_LDO3: LDO3 { /* PWR_EN_+V3.3_LPSR */
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_LDO4: LDO4 { /* V1.8_LPSR */
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ reg_LDO5: LDO5 { /* PWR_EN_+V3.3 */
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
};
};
@@ -30,6 +94,25 @@
status = "okay";
};
+ {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_enet1>;
+ pinctrl-1 = <_enet1_sleep>;
+ clocks = < IMX7D_ENET_AXI_ROOT_CLK>,
+ < IMX7D_ENET_AXI_ROOT_CLK>,
+ < IMX7D_ENET1_TIME_ROOT_CLK>,
+ < IMX7D_PLL_ENET_MAIN_50M_CLK>;
+ clock-names = "ipg", "ahb", "ptp", "enet_clk_ref";
+ assigned-clocks = < IMX7D_ENET1_TIME_ROOT_SRC>,
+ < IMX7D_ENET1_TIME_ROOT_CLK>;
+ assigned-clock-parents = < IMX7D_PLL_ENET_MAIN_100M_CLK>;
+ assigned-clock-rates = <0>, <1>;
+ phy-mode = "rmii";
+ phy-supply = <_LDO1>;
+ fsl,magic-packet;
+ status = "okay";
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_uart1 _uart1_ctrl1>;
@@ -88,6 +171,39 @@
MX7D_PAD_SD1_DATA3__SD1_DATA3 0x59
>;
};
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX7D_PAD_ENET1_CRS__GPIO7_IO14 0x14
+ MX7D_PAD_ENET1_RGMII_RX_CTL__ENET1_RGMII_RX_CTL 0x73
+ MX7D_PAD_ENET1_RGMII_RD0__ENET1_RGMII_RD0 0x73
+ MX7D_PAD_ENET1_RGMII_RD1__ENET1_RGMII_RD1 0x73
+
[U-Boot] [PATCH v1 4/6] apalis_imx6: migrate to DM_ETH
From: Igor Opaniuk
Migrate to DM_ETH and remove hardcoded pinmux configuration.
Signed-off-by: Igor Opaniuk
---
board/toradex/apalis_imx6/apalis_imx6.c | 51 -
configs/apalis_imx6_defconfig | 3 ++
include/configs/apalis_imx6.h | 6 ---
3 files changed, 3 insertions(+), 57 deletions(-)
diff --git a/board/toradex/apalis_imx6/apalis_imx6.c
b/board/toradex/apalis_imx6/apalis_imx6.c
index 51505b63e1..ec6a28104f 100644
--- a/board/toradex/apalis_imx6/apalis_imx6.c
+++ b/board/toradex/apalis_imx6/apalis_imx6.c
@@ -176,22 +176,6 @@ iomux_v3_cfg_t const enet_pads[] = {
# define GPIO_ENET_PHY_RESET IMX_GPIO_NR(1, 25)
};
-static void setup_iomux_enet(void)
-{
- imx_iomux_v3_setup_multiple_pads(enet_pads, ARRAY_SIZE(enet_pads));
-}
-
-static int reset_enet_phy(struct mii_dev *bus)
-{
- /* Reset KSZ9031 PHY */
- gpio_request(GPIO_ENET_PHY_RESET, "ETH_RESET#");
- gpio_direction_output(GPIO_ENET_PHY_RESET, 0);
- mdelay(10);
- gpio_set_value(GPIO_ENET_PHY_RESET, 1);
-
- return 0;
-}
-
/* mux the Apalis GPIO pins, so they can be used from the U-Boot cmdline */
iomux_v3_cfg_t const gpio_pads[] = {
/* Apalis GPIO1 - GPIO8 */
@@ -366,41 +350,6 @@ int board_phy_config(struct phy_device *phydev)
return 0;
}
-int board_eth_init(bd_t *bis)
-{
- uint32_t base = IMX_FEC_BASE;
- struct mii_dev *bus = NULL;
- struct phy_device *phydev = NULL;
- int ret;
-
- setup_iomux_enet();
-
-#ifdef CONFIG_FEC_MXC
- bus = fec_get_miibus(base, -1);
- if (!bus)
- return 0;
-
- bus->reset = reset_enet_phy;
- /* scan PHY 4,5,6,7 */
- phydev = phy_find_by_mask(bus, (0xf << 4), PHY_INTERFACE_MODE_RGMII);
- if (!phydev) {
- free(bus);
- puts("no PHY found\n");
- return 0;
- }
-
- printf("using PHY at %d\n", phydev->addr);
- ret = fec_probe(bis, -1, base, bus, phydev);
- if (ret) {
- printf("FEC MXC: %s:failed\n", __func__);
- free(phydev);
- free(bus);
- }
-#endif /* CONFIG_FEC_MXC */
-
- return 0;
-}
-
static iomux_v3_cfg_t const pwr_intb_pads[] = {
/*
* the bootrom sets the iomux to vselect, potentially connecting
diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig
index 797bbb0ed0..7c91ab9c58 100644
--- a/configs/apalis_imx6_defconfig
+++ b/configs/apalis_imx6_defconfig
@@ -63,6 +63,9 @@ CONFIG_FSL_USDHC=y
CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ90X1=y
+CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
+CONFIG_FEC_MXC=y
CONFIG_MII=y
CONFIG_PINCTRL=y
CONFIG_PINCTRL_IMX6=y
diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h
index a5f9a96732..a346b987a0 100644
--- a/include/configs/apalis_imx6.h
+++ b/include/configs/apalis_imx6.h
@@ -53,13 +53,7 @@
#endif
/* Network */
-#define CONFIG_FEC_MXC
-#define IMX_FEC_BASE ENET_BASE_ADDR
-#define CONFIG_FEC_XCV_TYPERGMII
-#define CONFIG_ETHPRIME"FEC"
#define PHY_ANEG_TIMEOUT 15000 /* PHY needs longer aneg time */
-#define CONFIG_FEC_MXC_PHYADDR 6
-#define CONFIG_TFTP_TSIZE
/* USB Configs */
/* Host */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 1/6] ARM: dts: imx6_colibri: introduce fec node
From: Igor Opaniuk
Sync DTS with the mainline Linux and introduce fec node.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx6-colibri.dts | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/dts/imx6-colibri.dts b/arch/arm/dts/imx6-colibri.dts
index 5c9f1f0d2b..387d6d5ca7 100644
--- a/arch/arm/dts/imx6-colibri.dts
+++ b/arch/arm/dts/imx6-colibri.dts
@@ -21,6 +21,7 @@
mmc0 =
mmc1 =
usb0 = /* required for ums */
+ ethernet0 =
};
chosen {
@@ -46,6 +47,25 @@
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_enet>;
+ phy-mode = "rmii";
+ phy-handle = <>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy: ethernet-phy@0 {
+ reg = <0>;
+ micrel,led-mode = <0>;
+ status = "okay";
+ };
+ };
+};
+
/*
* PWR_I2C: power I2C to audio codec, PMIC, temperature sensor and
* touch screen controller
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1 0/6] imx: colibri imx6/imx7: apalis imx6: migrate to DM_ETH
Migrate to DM_ETH and remove hardcoded pinmux configuration. Igor Opaniuk (6): ARM: dts: imx6_colibri: introduce fec node colibri_imx6: migrate to DM_ETH ARM: dts: imx6_apalis: introduce fec node apalis_imx6: migrate to DM_ETH ARM: dts: imx7: imx7_colibri: introduce fec node colibri_imx7: migrate to DM_ETH arch/arm/dts/imx6-apalis.dts | 22 arch/arm/dts/imx6-colibri.dts | 20 arch/arm/dts/imx7-colibri.dtsi| 116 ++ arch/arm/dts/imx7d.dtsi | 3 + arch/arm/dts/imx7s.dtsi | 1 + board/toradex/apalis_imx6/apalis_imx6.c | 51 -- board/toradex/colibri_imx6/colibri_imx6.c | 59 +-- board/toradex/colibri_imx7/colibri_imx7.c | 44 configs/apalis_imx6_defconfig | 3 + configs/colibri_imx6_defconfig| 3 + configs/colibri_imx7_defconfig| 5 +- configs/colibri_imx7_emmc_defconfig | 5 +- include/configs/apalis_imx6.h | 6 -- include/configs/colibri_imx6.h| 8 -- include/configs/colibri_imx7.h| 11 -- 15 files changed, 180 insertions(+), 177 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: composite: add BOS descriptor support to composite framework
On 25. 10. 19 12:28, Roger Quadros wrote: > > > On 24/10/2019 18:44, Jean-Jacques Hiblot wrote: >> + Vignesh and Roger >> >> On 24/10/2019 13:22, Michal Simek wrote: >>> po 14. 10. 2019 v 14:52 odesílatel Michal Simek >>> napsal: From: T Karthik Reddy To add usb-3.0 support to peripheral device add BOS & SS capability descriptors to gadget composite framework. Signed-off-by: T Karthik Reddy Signed-off-by: Siva Durga Prasad Paladugu Signed-off-by: Michal Simek > > Reviewed-by: Roger Quadros Lukasz: This patch is assigned to you in patchwork. Can you please comment it or take it via your tree? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] mmc: fsl_esdhc: clean up and shrink the driver
Here is the CI build result. https://travis-ci.org/yangbolu1991/u-boot-test/builds/605435128 I had verified both SD and eMMC with both DM_MMC and non-DM_MMC modes. Thanks a lot. Best regards, Yangbo Lu > -Original Message- > From: Yangbo Lu > Sent: Thursday, October 31, 2019 6:54 PM > To: u-boot@lists.denx.de; Peng Fan > Cc: Y.b. Lu > Subject: [PATCH 0/7] mmc: fsl_esdhc: clean up and shrink the driver > > This patch-set is to clean up and shrink the fsl_esdhc driver. > > Yangbo Lu (7): > mmc: fsl_esdhc: drop controller initialization in fsl_esdhc_init() > mmc: fsl_esdhc: fix voltage validation > mmc: fsl_esdhc: clean up bus width configuration code > mmc: fsl_esdhc: convert to use fsl_esdhc_get_cfg_common() > mmc: fsl_esdhc: drop redundant code for non-removable feature > mmc: fsl_esdhc: always check write protect state > mmc: fsl_esdhc: clean up DM and non-DM code > > drivers/mmc/fsl_esdhc.c | 370 > > include/fsl_esdhc.h | 14 +- > 2 files changed, 129 insertions(+), 255 deletions(-) > > -- > 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] net: sun8i_emac: Remove debug message
When booting with sun8i_emac driver, the user get output like this:
...
Net: phy interface7
eth0: ethernet@1c3
...
The first line doesn't provide any useful information except for the
developers. I guess this is some leftover debugging message. This
patch change it to such. The new output is:
...
Net: eth0: ethernet@1c3
...
Signed-off-by: Stefan Mavrodiev
---
drivers/net/sun8i_emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 0629b16e57..e6cb074bc4 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -968,7 +968,7 @@ static int sun8i_emac_eth_ofdata_to_platdata(struct udevice
*dev)
if (phy_mode)
pdata->phy_interface = phy_get_interface_by_name(phy_mode);
- printf("phy interface%d\n", pdata->phy_interface);
+ debug("phy interface%d\n", pdata->phy_interface);
if (pdata->phy_interface == -1) {
debug("%s: Invalid PHY interface '%s'\n", __func__, phy_mode);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] mmc: fsl_esdhc_imx: Update compatible string for imx8m
To enable HS400(ES) and UHS for imx8m platforms, update the driver data
to share with imx8qm esdhc_soc_data.
Signed-off-by: Peng Fan
---
drivers/mmc/fsl_esdhc_imx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 67549036d4..4099386313 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1647,6 +1647,9 @@ static const struct udevice_id fsl_esdhc_ids[] = {
{ .compatible = "fsl,imx7d-usdhc", .data = (ulong)_imx7d_data,},
{ .compatible = "fsl,imx7ulp-usdhc", },
{ .compatible = "fsl,imx8qm-usdhc", .data = (ulong)_imx8qm_data,},
+ { .compatible = "fsl,imx8mm-usdhc", .data = (ulong)_imx8qm_data,},
+ { .compatible = "fsl,imx8mn-usdhc", .data = (ulong)_imx8qm_data,},
+ { .compatible = "fsl,imx8mq-usdhc", .data = (ulong)_imx8qm_data,},
{ .compatible = "fsl,esdhc", },
{ /* sentinel */ }
};
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] mmc: fsl_esdhc_imx: drop redundant clock settings
During mmc initialization, there are several calls to mmc_set_clock
and mmc_set_ios. When mmc_power_off, the mmc->clock will be set,
but the imx driver will use 400KHz. So the following calls
to mmc_set_ios will set the clock several times which is redundant
in fsl_esdhc_imx driver. So let's simplify to remove redundant
clock settings.
Signed-off-by: Peng Fan
---
drivers/mmc/fsl_esdhc_imx.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 43106dec75..67549036d4 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -627,9 +627,6 @@ static void set_sysctl(struct fsl_esdhc_priv *priv, struct
mmc *mmc, uint clock)
int sdhc_clk = priv->sdhc_clk;
uint clk;
- if (clock < mmc->cfg->f_min)
- clock = mmc->cfg->f_min;
-
while (sdhc_clk / (16 * pre_div * ddr_pre_div) > clock && pre_div < 256)
pre_div *= 2;
@@ -958,6 +955,7 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
{
struct fsl_esdhc *regs = priv->esdhc_regs;
int ret __maybe_unused;
+ u32 clock;
#ifdef CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK
/* Select to use peripheral clock */
@@ -966,8 +964,12 @@ static int esdhc_set_ios_common(struct fsl_esdhc_priv
*priv, struct mmc *mmc)
esdhc_clock_control(priv, true);
#endif
/* Set the clock speed */
- if (priv->clock != mmc->clock)
- set_sysctl(priv, mmc, mmc->clock);
+ clock = mmc->clock;
+ if (clock < mmc->cfg->f_min)
+ clock = mmc->cfg->f_min;
+
+ if (priv->clock != clock)
+ set_sysctl(priv, mmc, clock);
#ifdef MMC_SUPPORTS_TUNING
if (mmc->clk_disable) {
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] power: regulator: support off-on-delay-us
off-on-delay-us has been supported by Linux, so let's use it.
Signed-off-by: Peng Fan
---
V1:
Linux Tree:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f7907e57aea2adcd0b57ebcca410e125412ab680
drivers/power/regulator/regulator_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/power/regulator/regulator_common.c
b/drivers/power/regulator/regulator_common.c
index 2041086567..939efb2c0d 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -37,7 +37,11 @@ int regulator_common_ofdata_to_platdata(struct udevice *dev,
dev_pdata->startup_delay_us = dev_read_u32_default(dev,
"startup-delay-us", 0);
dev_pdata->off_on_delay_us =
+ dev_read_u32_default(dev, "off-on-delay-us", 0);
+ if (!dev_pdata->off_on_delay_us) {
+ dev_pdata->off_on_delay_us =
dev_read_u32_default(dev, "u-boot,off-on-delay-us", 0);
+ }
return 0;
}
--
2.16.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx u-boot-imx-20191104
Hi Tom, please pull from u-boot-imx, thanks ! The following changes since commit 5d6f05352b69d4858a2a9e9136ac3a734f0222bb: azure: Update the script to prepend PATH not override PATH (2019-11-01 13:59:14 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20191104 for you to fetch changes up to ae8a53ece0ff3b1ed686c3e0af14e59973d25db8: imx: nandbcb: add support for writing BCB only (2019-11-03 21:49:49 +0100) u-boot-imx-20191104 --- - i.MX NAND: nandbcb support for MX6UL / i.MX7 - i.MX8: support for HAB - Convert to DM (opos6ul, mccmon6) - Toradex i.MX6ull colibri - sync DTS with kernel Travis : https://travis-ci.org/sbabic/u-boot-imx/builds/606853416 Anatolij Gustschin (1): imx8: output SECO-FW and ATF commit IDs Claudius Heine (5): ARM: imx: Fix bmode detection from grp10 ARM: imx: Use IMX6_SRC_GPR10_BMODE instead of magic number ARM: imx6: DHCOM i.MX6 PDK: fix board_boot_modes emmc entry ARM: imx6: DHCOM i.MX6 PDK: defconfig: Enable MMC support of SPL ARM: imx6: DHCOM i.MX6 PDK: spl: Add eMMC initialization to SPL code Fabio Estevam (2): mx6: clock: Use setbits_le32() mx6: clock: Introduce disable_ipu_clock() Hannes Schmelzer (1): board/BuR/brppt2: initial commit Igor Opaniuk (7): ARM: dts: imx6ull-colibri: change hierarchy of DTS files ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes imx: gpmi: add defines for hw randominizer nand: mxs_nand: add API for switching different BCH layouts imx: nandbcb: add support for i.MX7 imx: nandbcb: refactor update function imx: nandbcb: add support for writing BCB only Lukasz Majewski (7): imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT on display5 imx: Enable RTC (ds1307) support in the U-Boot proper on TPC70 board ARM: imx: Convert mccmon6 to use DM/DTS in the u-boot proper ARM: imx: Decouple mccmon6's SPL and u-boot proper code spl: nor: Provide falcon boot support for NOR memories ARM: imx: Convert mccmon6 to use fitImage instead of uImage+DTB mccmon6: defconfig: nor: Enable usage of *_TINY_* drivers in SPL Manivannan Sadhasivam (1): arm: dts: Add devicetree support for iMXQXP AI_ML board Marek Vasut (1): arm: mxs: Increase VDDD voltage to match specification Oliver Graute (1): imx: support i.MX8QM ROM 7720 a1 board Parthiban Nallathambi (1): i.MX6: nand: extend nandbcb command for imx6UL(L) Patrick Wildt (1): imx: update i.MX8MQ device trees Peng Fan (13): imx8m: imx8mq: get chip rev for B1 revision imx8m: clock: improve irq response latency imx: imx8mq: add init_nand_clk imx: spl: implement spl_boot_mode for i.MX7/8/8M dt-bindings: import usb pd pmic: bd71837: drop DEBUG macro power: pmic: Kconfig: add CONFIG_SPL_DM_PMIC_BD71837 imx8m: evk: spl: probe clk in spl early stage imx8mm: evk: enable bd71837 pmic imx8: Add AHAB secure boot support imx8qm: mek: add secure boot script imx8qxp: mek: add secure boot script arm: dts: imx8mm: sync dts from Linux Kernel Robert Hancock (2): watchdog: imx: Add DT ext-reset handling watchdog: imx: Use immediate reset bits for expire_now Sébastien Szymanski (3): imx6ul: opos6ul: migrate to DM_ETH opos6uldev: migrate to DM_VIDEO video: mxsfb: set gd->fb_base Tom Rini (1): tbs2910: Disable Plan9/RTEMS bootm support Ye Li (1): mach-imx: Adding new argument for SIP call interface arch/arm/cpu/arm926ejs/mxs/spl_power_init.c |4 +- arch/arm/dts/Makefile |9 +- arch/arm/dts/fsl-imx8mq-evk.dts | 414 arch/arm/dts/fsl-imx8mq.dtsi | 462 -- arch/arm/dts/fsl-imx8qxp-ai_ml-u-boot.dtsi| 117 + arch/arm/dts/fsl-imx8qxp-ai_ml.dts| 181 +++ arch/arm/dts/imx6dl-brppt2.dts| 278 +++ arch/arm/dts/imx6q-kp.dts |5 ++ arch/arm/dts/imx6q-mccmon6.dts| 382 + arch/arm/dts/imx6ul-opos6uldev-u-boot.dtsi| 10 +++ arch/arm/dts/imx6ul-opos6uldev.dts|4 +- arch/arm/dts/imx6ull-colibri-u-boot.dtsi | 12 +++ arch/arm/dts/imx6ull-colibri.dts |
[U-Boot] [PATCH] imx: update i.MX8MQ device trees
> This updates the i.MX8MQ device trees and, necessarily, also the > i.MX8MQ clock bindings. These are taken verbatim from from the > Linux kernel version v5.4-rc2, which three small changes which > were already part of the previous device tree: > * Keep the PSCI reserved memory range > * Keep the alias for ethernet, so that the MAC address can be set > * Keep the modified #include for the IOMUXC pins > Signed-off-by: Patrick Wildt > Acked-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/5] ARM: imx: Covnert mccmon6 to use DM/DTS in the u-boot proper
> This commit converts mccmon6's u-boot proper (in a single commit to avoid > build breaks) to use solely DM/DTS. > The DTS description of the mccmon6 has been ported from Linux kernel > (v4.20, SHA1: 8fe28cb58bcb235034b64cbbb7550a8a43fd88be) > Signed-off-by: Lukasz Majewski Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] ARM: imx6: DHCOM i.MX6 PDK: spl: Add eMMC initialization to SPL code
> In order for 'bmode emmc' to work, the eMMC needs to be initialized in the > SPL. This change initializes the eMMC as BOOT_DEVICE_MMC1 (index=0). > Signed-off-by: Claudius Heine Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/10] imx: spl: implement spl_boot_mode for i.MX7/8/8M
> It will be easy to separate SD/EMMC when booting in SPL stage, then > no need to bother which device is BOOT_DEVICE_MMC1/2. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/10] imx8m: evk: spl: probe clk in spl early stage
> We are going to add i2c pmic support before dram could be used. > So we need enable clk driver earlier, so use spl_early_init > and move clock controller probe eariler to board_init_f. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 RESEND 2/2] ARM: imx: Use IMX6_SRC_GPR10_BMODE instead of magic number
> Signed-off-by: Claudius Heine Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] watchdog: imx: Use immediate reset bits for expire_now
> The expire_now function was previously setting the watchdog timeout to > minimum and waiting for the watchdog to expire. However, this watchdog > also has bits to trigger immediate reset. Use those instead, like the > Linux imx2_wdt driver does. > Signed-off-by: Robert Hancock Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v5] imx: support i.MX8QM ROM 7720 a1 board
> Add i.MX8QM ROM 7720a1 board support > Boot log as below: > U-Boot 2019.10-rc3-4-gd073e0242f (Sep 20 2019 - 08:24:13 +0200) > CPU: NXP i.MX8QM RevB A53 at 1200 MHz > Model: Advantech iMX8QM Qseven series > Board: ROM-7720-A1 4GB > Build: SCFW 65afe5f6 > Boot: SD2 > DRAM: 4 GiB > MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... OK > In:serial@5a06 > Out: serial@5a06 > Err: serial@5a06 > Net: eth0: ethernet@5b04Could not get PHY for FEC1: addr 1 > , eth-1: ethernet@5b05 > Hit any key to stop autoboot: 0 > Signed-off-by: Oliver Graute > Cc: Stefano Babic > Cc: Fabio Estevam > Cc: Peng Fan > Cc: Simon Glass > Cc: Ye Li > Cc: uboot-imx Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] imx: defconfig: Enable CONFIG_SPL_FORCE_MMC_BOOT on display5
> After the following commit:
> commit 772b55723bcb ("imx: Introduce CONFIG_SPL_FORCE_MMC_BOOT to force MMC
> boot on falcon mode")
> it is possible to set the CONFIG_SPL_FORCE_MMC_BOOT flag, which allows
> using MMC device as boot device regardless of the device used by Boot ROM
> (FBL) as the first boot medium.
> Display5 board needs this flag set to allow falcon boot from eMMC device.
> Signed-off-by: Lukasz Majewski
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/10] imx8mm: evk: enable bd71837 pmic
> Enable bd71837 pmic for i.MX8MM EVK board, need to set voltage for > DRAM and linux suspend voltage requirement. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] watchdog: imx: Add DT ext-reset handling
> The Linux imx2_wdt driver uses a fsl,ext-reset-output boolean in the > device tree to specify whether the board design should use the external > reset instead of the internal reset. Use this boolean to determine which > mode to use rather than using external reset unconditionally. > For the legacy non-DM mode, the external reset is always used in order > to maintain the previous behavior. > Signed-off-by: Robert Hancock Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/10] pmic: bd71837: drop DEBUG macro
> Drop DEBUG macro definition which is used for debug purpose. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/10] imx8m: imx8mq: get chip rev for B1 revision
> The i.MX8MQ B1 uses OCOTP_HW_OCOTP_READ_FUSE_DATA register for chip id. > It returns a magic number 0xff0055aa. update get_cpu_rev to support it, > and enable ocotp clock to access ocotp. > Signed-off-by: Peng Fan Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] ARM: dts: imx6ull-colibri: change hierarchy of DTS files
> From: Igor Opaniuk > Introduce imx6ull-colibri-u-boot.dtsi for u-boot specific properties to > keep original imx6ull-colibri.dts in sync with Linux. > Move all contents of imx6ull-colibri.dts to imx6ull-colibri.dtsi + > additionally fix checkpatch warnings. > Reviewed-by: Oleksandr Suvorov > Reviewed-by: Fabio Estevam > Signed-off-by: Igor Opaniuk Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/5] ARM: imx: Convert mccmon6 to use fitImage instead of uImage+DTB
> This commit enabled support for fitImage on mccmon6 when we > switch to DT/DTS (including falcon mode). > Signed-off-by: Lukasz Majewski Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] ARM: imx6: DHCOM i.MX6 PDK: fix board_boot_modes emmc entry
> The board_boot_modes contained the wrong values for the emmc entry. > The eMMC here is connected over a 8-bit bus. > This change allows to use the 'bmode emmc' command to boot from emmc. > Signed-off-by: Claudius Heine Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] ARM: dts: imx6ull-colibri: pre-reloc for uart pinmux modes
> From: Igor Opaniuk
> Add u-boot,dm-pre-reloc properties for uart pinmux configuration
> nodes, which enables UART as early as possible (before relocation).
> Without this we miss almost the half of output (U-boot version,
> CPU defails, Reset cause, DRAM details etc.).
> Fixes: cd69e8ef9b ("colibri-imx6ull: migrate pinctrl and regulators to
> dtb/dm")
> Reviewed-by: Oleksandr Suvorov
> Reviewed-by: Fabio Estevam
> Signed-off-by: Igor Opaniuk
Applied to u-boot-imx, master, thanks !
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
