Re: [U-Boot] [PATCH v8 17/19] arm: dts: agilex: Add base dtsi and devkit dts
On Thu, Nov 28, 2019 at 8:31 AM Ley Foon Tan wrote:
>
> On Thu, Nov 28, 2019 at 3:21 PM Ley Foon Tan wrote:
> >
> > On Wed, Nov 27, 2019 at 6:24 PM Simon Goldschmidt
> > wrote:
> > >
> > > On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan
> > > wrote:
> > > >
> > > > Add device tree files for Agilex SoC platform.
> > > >
> > > > socfpga_agilex-u-boot.dtsi and socfpga_agilex_socdk-u-boot.dts contains
> > > > Uboot specific DT properties.
> > > >
> > > > socfpga_agilex.dtsi and socfpga_agilex_socdk.dts are from Linux
> > > > (kernel/git/dinguyen/linux.git, commit 6f0bf971bacacc)
> > > >
> > > > Signed-off-by: Ley Foon Tan
> > > >
> > > > ---
> > > > v8:
> > > > - Include socfpga_agilex-u-boot.dtsi in
> > > > socfpga_agilex_socdk-u-boot.dtsi,
> > > > instead of include it in socfpga_agilex_socdk.dts.
> > > >
> > > > v7:
> > > > - Update socfpga_agilex.dtsi and socfpga_agilex_socdk.dts from Linux.
> > > > - Add new socfpga_agilex_socdk-u-boot.dts file for Uboot specific DT
> > > > properties.
> > > >
> > > > v6:
> > > > - Use new macro names from agilex-clock.h.
> > > >
> > > > v5:
> > > > - Add CCU DT node.
> > > >
> > > > v4:
> > > > - Add u-boot,dm-pre-reloc to sysmgr node.
> > > >
> > > > v3:
> > > > - Fixed bank 1 memory alias base address to 0x28000.
> > > > - Rename STRATIX10_*_CLK to SOCFPGA_SOC64_*_CLK.
> > > > - Include socfpga-soc64-clock.h
> > > > - Change to "intel,sdr-ctl-agilex" for SDRAM node.
> > > >
> > > > v2:
> > > > - Add clock property to device node.
> > > > - Change memory size to 8GB
> > > > - Enable i2c1
> > > > ---
> > > > arch/arm/dts/Makefile | 1 +
> > > > arch/arm/dts/socfpga_agilex-u-boot.dtsi | 96 +++
> > > > arch/arm/dts/socfpga_agilex.dtsi | 622 ++
> > > > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
> > > > arch/arm/dts/socfpga_agilex_socdk.dts | 141
> > > > 5 files changed, 899 insertions(+)
> > > > create mode 100644 arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
> > > >
> > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > index d8846df1bd..e76f7c1407 100644
> > > > --- a/arch/arm/dts/Makefile
> > > > +++ b/arch/arm/dts/Makefile
> > > > @@ -328,6 +328,7 @@ dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
> > > > dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
> > > >
> > > > dtb-$(CONFIG_ARCH_SOCFPGA) += \
> > > > + socfpga_agilex_socdk.dtb\
> > > > socfpga_arria5_socdk.dtb\
> > > > socfpga_arria10_socdk_sdmmc.dtb \
> > > > socfpga_cyclone5_mcvevk.dtb \
> > > > diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > new file mode 100644
> > > > index 00..f0528a9ad9
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > @@ -0,0 +1,96 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * U-Boot additions
> > > > + *
> > > > + * Copyright (C) 2019 Intel Corporation
> > > > + */
> > > > +
> > > > +/{
> > > > + memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + u-boot,dm-pre-reloc;
> > > > + };
> > > > +
> > > > + soc {
> > > > + u-boot,dm-pre-reloc;
> > > > +
> > > > + ccu: cache-controller@f700 {
> > > > + compatible = "arteris,ncore-ccu";
> > > > + reg = <0xf700 0x100900>;
> > > > + u-boot,dm-pre-reloc;
> > > > + };
> > > > + };
> > > > +};
> > > > +
> > > > + {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > + altr,sysmgr-syscon = < 0x48 0>;
> > > > +};
> > > > +
> > > > + {
> > > > + altr,sysmgr-syscon = < 0x4c 0>;
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> > > > +};
> > > > +
> > > > + {
> > > > + bank-name = "porta";
> > > > +};
> > > > +
> > > > + {
> > > > + bank-name = "portb";
> > > > +};
> > > > +
> > > > + {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > + compatible = "altr,rst-mgr";
> > >
> > > This and other compatible-changing lines in this file should be synced to
> > > the
> > > correct string in all DTs, so please fix this in the upstream Linux DTs.
> > Linux uses "altr,rst-mgr"
Re: [U-Boot] [PATCH v8 17/19] arm: dts: agilex: Add base dtsi and devkit dts
On Thu, Nov 28, 2019 at 3:28 PM Simon Goldschmidt
wrote:
>
> On Thu, Nov 28, 2019 at 8:22 AM Ley Foon Tan wrote:
> >
> > On Wed, Nov 27, 2019 at 6:24 PM Simon Goldschmidt
> > wrote:
> > >
> > > On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan
> > > wrote:
> > > >
> > > > Add device tree files for Agilex SoC platform.
> > > >
> > > > socfpga_agilex-u-boot.dtsi and socfpga_agilex_socdk-u-boot.dts contains
> > > > Uboot specific DT properties.
> > > >
> > > > socfpga_agilex.dtsi and socfpga_agilex_socdk.dts are from Linux
> > > > (kernel/git/dinguyen/linux.git, commit 6f0bf971bacacc)
> > > >
> > > > Signed-off-by: Ley Foon Tan
> > > >
> > > > ---
> > > > v8:
> > > > - Include socfpga_agilex-u-boot.dtsi in
> > > > socfpga_agilex_socdk-u-boot.dtsi,
> > > > instead of include it in socfpga_agilex_socdk.dts.
> > > >
> > > > v7:
> > > > - Update socfpga_agilex.dtsi and socfpga_agilex_socdk.dts from Linux.
> > > > - Add new socfpga_agilex_socdk-u-boot.dts file for Uboot specific DT
> > > > properties.
> > > >
> > > > v6:
> > > > - Use new macro names from agilex-clock.h.
> > > >
> > > > v5:
> > > > - Add CCU DT node.
> > > >
> > > > v4:
> > > > - Add u-boot,dm-pre-reloc to sysmgr node.
> > > >
> > > > v3:
> > > > - Fixed bank 1 memory alias base address to 0x28000.
> > > > - Rename STRATIX10_*_CLK to SOCFPGA_SOC64_*_CLK.
> > > > - Include socfpga-soc64-clock.h
> > > > - Change to "intel,sdr-ctl-agilex" for SDRAM node.
> > > >
> > > > v2:
> > > > - Add clock property to device node.
> > > > - Change memory size to 8GB
> > > > - Enable i2c1
> > > > ---
> > > > arch/arm/dts/Makefile | 1 +
> > > > arch/arm/dts/socfpga_agilex-u-boot.dtsi | 96 +++
> > > > arch/arm/dts/socfpga_agilex.dtsi | 622 ++
> > > > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
> > > > arch/arm/dts/socfpga_agilex_socdk.dts | 141
> > > > 5 files changed, 899 insertions(+)
> > > > create mode 100644 arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
> > > >
> > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > > index d8846df1bd..e76f7c1407 100644
> > > > --- a/arch/arm/dts/Makefile
> > > > +++ b/arch/arm/dts/Makefile
> > > > @@ -328,6 +328,7 @@ dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
> > > > dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
> > > >
> > > > dtb-$(CONFIG_ARCH_SOCFPGA) += \
> > > > + socfpga_agilex_socdk.dtb\
> > > > socfpga_arria5_socdk.dtb\
> > > > socfpga_arria10_socdk_sdmmc.dtb \
> > > > socfpga_cyclone5_mcvevk.dtb \
> > > > diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > new file mode 100644
> > > > index 00..f0528a9ad9
> > > > --- /dev/null
> > > > +++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > > @@ -0,0 +1,96 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * U-Boot additions
> > > > + *
> > > > + * Copyright (C) 2019 Intel Corporation
> > > > + */
> > > > +
> > > > +/{
> > > > + memory {
> > > > + #address-cells = <2>;
> > > > + #size-cells = <2>;
> > > > + u-boot,dm-pre-reloc;
> > > > + };
> > > > +
> > > > + soc {
> > > > + u-boot,dm-pre-reloc;
> > > > +
> > > > + ccu: cache-controller@f700 {
> > > > + compatible = "arteris,ncore-ccu";
> > > > + reg = <0xf700 0x100900>;
> > > > + u-boot,dm-pre-reloc;
> > > > + };
> > > > + };
> > > > +};
> > > > +
> > > > + {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > + altr,sysmgr-syscon = < 0x48 0>;
> > > > +};
> > > > +
> > > > + {
> > > > + altr,sysmgr-syscon = < 0x4c 0>;
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + reset-names = "i2c";
> > > > +};
> > > > +
> > > > + {
> > > > + resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> > > > +};
> > > > +
> > > > + {
> > > > + bank-name = "porta";
> > > > +};
> > > > +
> > > > + {
> > > > + bank-name = "portb";
> > > > +};
> > > > +
> > > > + {
> > > > + u-boot,dm-pre-reloc;
> > > > +};
> > > > +
> > > > + {
> > > > + compatible = "altr,rst-mgr";
> > >
> > > This and other compatible-changing lines in this file should be synced to
> > > the
> > > correct string in all DTs, so please fix this in the upstream Linux DTs.
> > Linux uses
Re: [U-Boot] [PATCH v8 17/19] arm: dts: agilex: Add base dtsi and devkit dts
On Thu, Nov 28, 2019 at 3:21 PM Ley Foon Tan wrote:
>
> On Wed, Nov 27, 2019 at 6:24 PM Simon Goldschmidt
> wrote:
> >
> > On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan wrote:
> > >
> > > Add device tree files for Agilex SoC platform.
> > >
> > > socfpga_agilex-u-boot.dtsi and socfpga_agilex_socdk-u-boot.dts contains
> > > Uboot specific DT properties.
> > >
> > > socfpga_agilex.dtsi and socfpga_agilex_socdk.dts are from Linux
> > > (kernel/git/dinguyen/linux.git, commit 6f0bf971bacacc)
> > >
> > > Signed-off-by: Ley Foon Tan
> > >
> > > ---
> > > v8:
> > > - Include socfpga_agilex-u-boot.dtsi in socfpga_agilex_socdk-u-boot.dtsi,
> > > instead of include it in socfpga_agilex_socdk.dts.
> > >
> > > v7:
> > > - Update socfpga_agilex.dtsi and socfpga_agilex_socdk.dts from Linux.
> > > - Add new socfpga_agilex_socdk-u-boot.dts file for Uboot specific DT
> > > properties.
> > >
> > > v6:
> > > - Use new macro names from agilex-clock.h.
> > >
> > > v5:
> > > - Add CCU DT node.
> > >
> > > v4:
> > > - Add u-boot,dm-pre-reloc to sysmgr node.
> > >
> > > v3:
> > > - Fixed bank 1 memory alias base address to 0x28000.
> > > - Rename STRATIX10_*_CLK to SOCFPGA_SOC64_*_CLK.
> > > - Include socfpga-soc64-clock.h
> > > - Change to "intel,sdr-ctl-agilex" for SDRAM node.
> > >
> > > v2:
> > > - Add clock property to device node.
> > > - Change memory size to 8GB
> > > - Enable i2c1
> > > ---
> > > arch/arm/dts/Makefile | 1 +
> > > arch/arm/dts/socfpga_agilex-u-boot.dtsi | 96 +++
> > > arch/arm/dts/socfpga_agilex.dtsi | 622 ++
> > > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
> > > arch/arm/dts/socfpga_agilex_socdk.dts | 141
> > > 5 files changed, 899 insertions(+)
> > > create mode 100644 arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
> > >
> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index d8846df1bd..e76f7c1407 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -328,6 +328,7 @@ dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
> > > dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
> > >
> > > dtb-$(CONFIG_ARCH_SOCFPGA) += \
> > > + socfpga_agilex_socdk.dtb\
> > > socfpga_arria5_socdk.dtb\
> > > socfpga_arria10_socdk_sdmmc.dtb \
> > > socfpga_cyclone5_mcvevk.dtb \
> > > diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > new file mode 100644
> > > index 00..f0528a9ad9
> > > --- /dev/null
> > > +++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > @@ -0,0 +1,96 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * U-Boot additions
> > > + *
> > > + * Copyright (C) 2019 Intel Corporation
> > > + */
> > > +
> > > +/{
> > > + memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + u-boot,dm-pre-reloc;
> > > + };
> > > +
> > > + soc {
> > > + u-boot,dm-pre-reloc;
> > > +
> > > + ccu: cache-controller@f700 {
> > > + compatible = "arteris,ncore-ccu";
> > > + reg = <0xf700 0x100900>;
> > > + u-boot,dm-pre-reloc;
> > > + };
> > > + };
> > > +};
> > > +
> > > + {
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > + {
> > > + altr,sysmgr-syscon = < 0x48 0>;
> > > +};
> > > +
> > > + {
> > > + altr,sysmgr-syscon = < 0x4c 0>;
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> > > +};
> > > +
> > > + {
> > > + bank-name = "porta";
> > > +};
> > > +
> > > + {
> > > + bank-name = "portb";
> > > +};
> > > +
> > > + {
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > + {
> > > + compatible = "altr,rst-mgr";
> >
> > This and other compatible-changing lines in this file should be synced to
> > the
> > correct string in all DTs, so please fix this in the upstream Linux DTs.
> Linux uses "altr,rst-mgr" for Gen5 and Arria10,
> "altr,stratix10-rst-mgr" for S10 and Agilex.
> But, Uboot uses "altr,rst-mgr" for all Gen5/Arria10/S10/Agilex platforms.
>
> >
> > > + altr,modrst-offset = <0x20>;
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > + {
> > > + compatible = "intel,sdr-ctl-agilex";
> >
> > See above.
> Linux doesn't have DDR device tree node. DDR
Re: [U-Boot] [PATCH v8 17/19] arm: dts: agilex: Add base dtsi and devkit dts
On Thu, Nov 28, 2019 at 8:22 AM Ley Foon Tan wrote:
>
> On Wed, Nov 27, 2019 at 6:24 PM Simon Goldschmidt
> wrote:
> >
> > On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan wrote:
> > >
> > > Add device tree files for Agilex SoC platform.
> > >
> > > socfpga_agilex-u-boot.dtsi and socfpga_agilex_socdk-u-boot.dts contains
> > > Uboot specific DT properties.
> > >
> > > socfpga_agilex.dtsi and socfpga_agilex_socdk.dts are from Linux
> > > (kernel/git/dinguyen/linux.git, commit 6f0bf971bacacc)
> > >
> > > Signed-off-by: Ley Foon Tan
> > >
> > > ---
> > > v8:
> > > - Include socfpga_agilex-u-boot.dtsi in socfpga_agilex_socdk-u-boot.dtsi,
> > > instead of include it in socfpga_agilex_socdk.dts.
> > >
> > > v7:
> > > - Update socfpga_agilex.dtsi and socfpga_agilex_socdk.dts from Linux.
> > > - Add new socfpga_agilex_socdk-u-boot.dts file for Uboot specific DT
> > > properties.
> > >
> > > v6:
> > > - Use new macro names from agilex-clock.h.
> > >
> > > v5:
> > > - Add CCU DT node.
> > >
> > > v4:
> > > - Add u-boot,dm-pre-reloc to sysmgr node.
> > >
> > > v3:
> > > - Fixed bank 1 memory alias base address to 0x28000.
> > > - Rename STRATIX10_*_CLK to SOCFPGA_SOC64_*_CLK.
> > > - Include socfpga-soc64-clock.h
> > > - Change to "intel,sdr-ctl-agilex" for SDRAM node.
> > >
> > > v2:
> > > - Add clock property to device node.
> > > - Change memory size to 8GB
> > > - Enable i2c1
> > > ---
> > > arch/arm/dts/Makefile | 1 +
> > > arch/arm/dts/socfpga_agilex-u-boot.dtsi | 96 +++
> > > arch/arm/dts/socfpga_agilex.dtsi | 622 ++
> > > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
> > > arch/arm/dts/socfpga_agilex_socdk.dts | 141
> > > 5 files changed, 899 insertions(+)
> > > create mode 100644 arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > > create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
> > >
> > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > > index d8846df1bd..e76f7c1407 100644
> > > --- a/arch/arm/dts/Makefile
> > > +++ b/arch/arm/dts/Makefile
> > > @@ -328,6 +328,7 @@ dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
> > > dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
> > >
> > > dtb-$(CONFIG_ARCH_SOCFPGA) += \
> > > + socfpga_agilex_socdk.dtb\
> > > socfpga_arria5_socdk.dtb\
> > > socfpga_arria10_socdk_sdmmc.dtb \
> > > socfpga_cyclone5_mcvevk.dtb \
> > > diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > new file mode 100644
> > > index 00..f0528a9ad9
> > > --- /dev/null
> > > +++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > > @@ -0,0 +1,96 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * U-Boot additions
> > > + *
> > > + * Copyright (C) 2019 Intel Corporation
> > > + */
> > > +
> > > +/{
> > > + memory {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > + u-boot,dm-pre-reloc;
> > > + };
> > > +
> > > + soc {
> > > + u-boot,dm-pre-reloc;
> > > +
> > > + ccu: cache-controller@f700 {
> > > + compatible = "arteris,ncore-ccu";
> > > + reg = <0xf700 0x100900>;
> > > + u-boot,dm-pre-reloc;
> > > + };
> > > + };
> > > +};
> > > +
> > > + {
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > + {
> > > + altr,sysmgr-syscon = < 0x48 0>;
> > > +};
> > > +
> > > + {
> > > + altr,sysmgr-syscon = < 0x4c 0>;
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + reset-names = "i2c";
> > > +};
> > > +
> > > + {
> > > + resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> > > +};
> > > +
> > > + {
> > > + bank-name = "porta";
> > > +};
> > > +
> > > + {
> > > + bank-name = "portb";
> > > +};
> > > +
> > > + {
> > > + u-boot,dm-pre-reloc;
> > > +};
> > > +
> > > + {
> > > + compatible = "altr,rst-mgr";
> >
> > This and other compatible-changing lines in this file should be synced to
> > the
> > correct string in all DTs, so please fix this in the upstream Linux DTs.
> Linux uses "altr,rst-mgr" for Gen5 and Arria10,
> "altr,stratix10-rst-mgr" for S10 and Agilex.
> But, Uboot uses "altr,rst-mgr" for all Gen5/Arria10/S10/Agilex platforms.
What prevents you from fixing the Linux drivers to use
"altr,stratix10-rst-mgr", too?
A devicetree should describe the hardware in a generic, OS-agnostic way
as much as possible.
>
> >
> > > + altr,modrst-offset = <0x20>;
>
Re: [U-Boot] [PATCH v8 17/19] arm: dts: agilex: Add base dtsi and devkit dts
On Wed, Nov 27, 2019 at 6:24 PM Simon Goldschmidt
wrote:
>
> On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan wrote:
> >
> > Add device tree files for Agilex SoC platform.
> >
> > socfpga_agilex-u-boot.dtsi and socfpga_agilex_socdk-u-boot.dts contains
> > Uboot specific DT properties.
> >
> > socfpga_agilex.dtsi and socfpga_agilex_socdk.dts are from Linux
> > (kernel/git/dinguyen/linux.git, commit 6f0bf971bacacc)
> >
> > Signed-off-by: Ley Foon Tan
> >
> > ---
> > v8:
> > - Include socfpga_agilex-u-boot.dtsi in socfpga_agilex_socdk-u-boot.dtsi,
> > instead of include it in socfpga_agilex_socdk.dts.
> >
> > v7:
> > - Update socfpga_agilex.dtsi and socfpga_agilex_socdk.dts from Linux.
> > - Add new socfpga_agilex_socdk-u-boot.dts file for Uboot specific DT
> > properties.
> >
> > v6:
> > - Use new macro names from agilex-clock.h.
> >
> > v5:
> > - Add CCU DT node.
> >
> > v4:
> > - Add u-boot,dm-pre-reloc to sysmgr node.
> >
> > v3:
> > - Fixed bank 1 memory alias base address to 0x28000.
> > - Rename STRATIX10_*_CLK to SOCFPGA_SOC64_*_CLK.
> > - Include socfpga-soc64-clock.h
> > - Change to "intel,sdr-ctl-agilex" for SDRAM node.
> >
> > v2:
> > - Add clock property to device node.
> > - Change memory size to 8GB
> > - Enable i2c1
> > ---
> > arch/arm/dts/Makefile | 1 +
> > arch/arm/dts/socfpga_agilex-u-boot.dtsi | 96 +++
> > arch/arm/dts/socfpga_agilex.dtsi | 622 ++
> > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 39 ++
> > arch/arm/dts/socfpga_agilex_socdk.dts | 141
> > 5 files changed, 899 insertions(+)
> > create mode 100644 arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
> > create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index d8846df1bd..e76f7c1407 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -328,6 +328,7 @@ dtb-$(CONFIG_TI816X) += dm8168-evm.dtb
> > dtb-$(CONFIG_THUNDERX) += thunderx-88xx.dtb
> >
> > dtb-$(CONFIG_ARCH_SOCFPGA) += \
> > + socfpga_agilex_socdk.dtb\
> > socfpga_arria5_socdk.dtb\
> > socfpga_arria10_socdk_sdmmc.dtb \
> > socfpga_cyclone5_mcvevk.dtb \
> > diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > new file mode 100644
> > index 00..f0528a9ad9
> > --- /dev/null
> > +++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
> > @@ -0,0 +1,96 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * U-Boot additions
> > + *
> > + * Copyright (C) 2019 Intel Corporation
> > + */
> > +
> > +/{
> > + memory {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > + u-boot,dm-pre-reloc;
> > + };
> > +
> > + soc {
> > + u-boot,dm-pre-reloc;
> > +
> > + ccu: cache-controller@f700 {
> > + compatible = "arteris,ncore-ccu";
> > + reg = <0xf700 0x100900>;
> > + u-boot,dm-pre-reloc;
> > + };
> > + };
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + altr,sysmgr-syscon = < 0x48 0>;
> > +};
> > +
> > + {
> > + altr,sysmgr-syscon = < 0x4c 0>;
> > +};
> > +
> > + {
> > + reset-names = "i2c";
> > +};
> > +
> > + {
> > + reset-names = "i2c";
> > +};
> > +
> > + {
> > + reset-names = "i2c";
> > +};
> > +
> > + {
> > + reset-names = "i2c";
> > +};
> > +
> > + {
> > + resets = < SDMMC_RESET>, < SDMMC_OCP_RESET>;
> > +};
> > +
> > + {
> > + bank-name = "porta";
> > +};
> > +
> > + {
> > + bank-name = "portb";
> > +};
> > +
> > + {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + compatible = "altr,rst-mgr";
>
> This and other compatible-changing lines in this file should be synced to the
> correct string in all DTs, so please fix this in the upstream Linux DTs.
Linux uses "altr,rst-mgr" for Gen5 and Arria10,
"altr,stratix10-rst-mgr" for S10 and Agilex.
But, Uboot uses "altr,rst-mgr" for all Gen5/Arria10/S10/Agilex platforms.
>
> > + altr,modrst-offset = <0x20>;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + compatible = "intel,sdr-ctl-agilex";
>
> See above.
Linux doesn't have DDR device tree node. DDR driver is only needed in Uboot.
>
> > + reg = <0xf8000400 0x80>,
> > + <0xf801 0x190>,
> > + <0xf8011000 0x500>;
> > + resets = < DDRSCH_RESET>;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > + {
> > + compatible = "altr,sys-mgr", "syscon";
>
> See above.
Linux dts just removed "syscon" recently. But, Uboot needs it.
Regards
Ley Foon
Re: [U-Boot] [PATCH 0/2] Add support for booting EFI FIT images
On 11/27/19 8:45 PM, Cristian Ciocaltea wrote:
On Tue, Nov 26, 2019 at 07:31:39PM +0100, Heinrich Schuchardt wrote:
On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:
Currently the only way to run an EFI binary like GRUB2 is via the
'bootefi' command, which cannot be used in a verified boot scenario.
The obvious solution to this limitation is to add support for
booting FIT images containing those EFI binaries.
The implementation relies on a new image type - IH_OS_EFI - which
can be created by using 'os = "efi"' inside an ITS file:
/ {
#address-cells = <1>;
images {
efi-grub {
description = "GRUB EFI";
data = /incbin/("EFI/BOOT/bootarm.efi");
type = "kernel_noload";
arch = "arm";
os = "efi";
compression = "none";
load = <0x0>;
entry = <0x0>;
hash-1 {
algo = "sha256";
};
};
};
configurations {
default = "config-grub";
config-grub {
kernel = "efi-grub";
signature-1 {
algo = "sha256,rsa2048";
sign-images = "kernel";
};
};
};
};
The bootm command has been extended to handle the IH_OS_EFI images.
To enable this feature, a new configuration option has been added:
BOOTM_EFI
I tested the solution using the 'qemu_arm' board:
=> load scsi 0:1 ${kernel_addr_r} efi-image.fit
=> bootm ${kernel_addr_r}#config-grub
Thanks a lot for the patch series which makes good sense to me.
I think we should pass addresses and not strings to cmd/bootefi.c. This
will need a bit of refactoring as already addressed in a comment to
patch 2/2.
Additionally the documentation in doc/uefi/u-boot_on_efi.rst and
doc/uImage.FIT/howto.txt should be updated.
I cc the contributors given by
scripts/get_maintainer.pl -f common/bootm_os.c
Best regards
Heinrich
Thanks for the feedback, Heinrich!
Instead of creating new function(s), I think we could simply extend
int do_bootefi_image(const char *image_opt)
with a new parameter to hold the fdt address and move here the call
to 'efi_install_fdt()', which is now performed by 'do_bootefi()'.
efi_install_fdt() has to be called for the 'bootefi bootmgr' command too
so the refactoring is a bit more complicated. I have started on that.
The first step is to change efi_install_fdt() to expect the argument as
address instead of a string.
https://github.com/xypron/u-boot-patches/blob/efi-next/0001-efi_loader-pass-address-to-efi_install_fdt.patch
fdt_addr==NULL indicates no device tree supplied by user.
Best regards
Heinrich
However, I'm not sure about changing the data types, i.e. from
'char *' to ulong, for the following reasons:
1. image_opt may have a different meaning in addition to efi address
2. fdt address may not be provided, so we need somehow to detect an
invalid value
Kind regards,
Cristian
Cristian Ciocaltea (2):
image: Add IH_OS_EFI for EFI chain-load boot
bootm: Add a bootm command for type IH_OS_EFI
cmd/Kconfig| 9 -
cmd/bootefi.c | 2 +-
common/bootm_os.c | 44
common/image-fit.c | 3 ++-
common/image.c | 1 +
include/bootm.h| 2 ++
include/image.h| 1 +
7 files changed, 59 insertions(+), 3 deletions(-)
___
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] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [RFC] Eliminate boards not using CONFIG_DM=y
On 11/26/19 6:07 PM, Marek Vasut wrote: On 11/26/19 5:52 PM, Tom Rini wrote: On Tue, Nov 26, 2019 at 05:47:48PM +0100, Marek Vasut wrote: On 11/26/19 5:26 PM, Tom Rini wrote: On Tue, Nov 26, 2019 at 09:11:51AM +0100, Marek Vasut wrote: On 11/26/19 12:16 AM, Heinrich Schuchardt wrote: Dear maintainers, Hi, we have been trying to move to the driver model for several years now. Starting in 2018 we have added warnings to the Makefile that boards not supporting the driver model will be eliminated. Still 24 % of the configuration files have not been converted and do not even use CONFIG_DM=y. If we want to get rid of legacy drivers, at some point we have to remove the 347 configuration files in the list below not using the driver model. I suggest to do this directly after the release of v2020.01 scheduled January 6th. This should not stop the maintainers from reinserting the boards after conversion to the driver model. Some boards just cannot accommodate this DM stuff. For those boards, it's just bloat without any useful added value. Hence, these boards would be removed because they cannot accommodate arbitrary bloat. This makes U-Boot not-so-universal bootloader anymore, but rather a bloated one. I don't think we can force boards out or impose DM on everyone unless we can solve this bloat issue first. As someone who was involved in creating this DM stuff, do you have some ideas on addressing things? Given that you're responsible for a number of these platforms and can test out some ideas on them, what are you suggesting? How about directly calling driver functions for drivers which have single instance only ? Then we could optimize out all the DM overhead for that. And when are you hoping to post an RFC / example? Currently I have zero time available. Maybe someone else can look into this option? Dear Marex, DM drivers make use of the DM infrastructure for instance for the allocation of the private data area. The uclass files often include common logic needed for accessing all drivers (see for example tpm_xfer()). So which drivers do you think of that could be simplified? I would also be interested to learn which of the 347 boards not using CONFIG_DM=y are still actively maintained. Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] rockchip: rk3399: rockpro64: enable force power on reset workaround
Rockpro64 doesn't boot reliably after soft reset, so let's force power on
reset by asserting sysreset pin if we detected soft reset.
Signed-off-by: Vasily Khoruzhick
---
arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 8
configs/rockpro64-rk3399_defconfig| 1 +
2 files changed, 9 insertions(+)
diff --git a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
index 4648513ea9..bb94bcf7be 100644
--- a/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
+++ b/arch/arm/dts/rk3399-rockpro64-u-boot.dtsi
@@ -6,11 +6,19 @@
#include "rk3399-u-boot.dtsi"
#include "rk3399-sdram-lpddr4-100.dtsi"
/ {
+ config {
+ sysreset-gpio = < RK_PA6 GPIO_ACTIVE_HIGH>;
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", ,
};
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
_center {
regulator-min-microvolt = <95>;
regulator-max-microvolt = <95>;
diff --git a/configs/rockpro64-rk3399_defconfig
b/configs/rockpro64-rk3399_defconfig
index 49e27c91cb..d153ac5485 100644
--- a/configs/rockpro64-rk3399_defconfig
+++ b/configs/rockpro64-rk3399_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
CONFIG_ARCH_ROCKCHIP=y
CONFIG_SYS_TEXT_BASE=0x0020
+CONFIG_SPL_GPIO_SUPPORT=y
CONFIG_ROCKCHIP_RK3399=y
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_TARGET_ROCKPRO64_RK3399=y
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] rockchip: rk3399: fix force power on reset
Currently code doesn't even compile since it uses wrong
define for ifdef. Fix that and also add missing include
Fixes: 07586ee4322a ("rockchip: rk3399: Support common spl_board_init")
Signed-off-by: Vasily Khoruzhick
---
arch/arm/mach-rockchip/rk3399/rk3399.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
b/arch/arm/mach-rockchip/rk3399/rk3399.c
index 863024d071..eeb99dd11b 100644
--- a/arch/arm/mach-rockchip/rk3399/rk3399.c
+++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -213,7 +214,7 @@ void spl_perform_fixups(struct spl_image_info *spl_image)
"u-boot,spl-boot-device", boot_ofpath);
}
-#if defined(SPL_GPIO_SUPPORT)
+#if defined(CONFIG_SPL_GPIO_SUPPORT)
static void rk3399_force_power_on_reset(void)
{
ofnode node;
@@ -239,7 +240,7 @@ static void rk3399_force_power_on_reset(void)
void spl_board_init(void)
{
-#if defined(SPL_GPIO_SUPPORT)
+#if defined(CONFIG_SPL_GPIO_SUPPORT)
struct rk3399_cru *cru = rockchip_get_cru();
/*
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GPT overlap on i.MX6
Hi Lukasz, On Wed, Nov 27, 2019 at 9:47 PM Lukasz Majewski wrote: > > Hi Jagan, > > > Hi Lukasz, > > > > On Wed, Nov 27, 2019 at 4:15 PM Lukasz Majewski wrote: > > > > > > Hi Jagan, > > > > > > > Hi, > > > > > > > > I have created GPT table start from 8MB for kernel, roots etc. > > > > something like > > > > > > > > PartStart LBA End LBA Name > > > > Attributes > > > > Type GUID > > > > Partition GUID > > > > 1 0x4000 0x00023fff "boota" > > > > attrs: 0x0004 > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > 2 0x00024000 0x00043fff "bootb" > > > > attrs: 0x0004 > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > > 3 0x00044000 0x00243fff "rootfsa" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > > 4 0x00244000 0x00443fff "rootfsb" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > > 5 0x00444000 0x0070bfde "data" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > > > I have not included SPL, U-Boot to the partition list since it > > > > start from 0x400 in i.MX6. So > > > > I'm writing SPL separately using fastboot(with offset) or ums. > > > > > > > > But by doing this, the partition header seems overlapped so the > > > > output looks > > > > > > > > GUID Partition Table Entry Array CRC is wrong: 0x6a1aba0a != > > > > 0x8e4fd548 find_valid_gpt: *** ERROR: Invalid GPT *** > > > > find_valid_gpt: ***Using Backup GPT *** > > > > PartStart LBA End LBA Name > > > > Attributes > > > > Type GUID > > > > Partition GUID > > > > 1 0x4000 0x00023fff "boota" > > > > attrs: 0x0004 > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > > 2 0x00024000 0x00043fff "bootb" > > > > attrs: 0x0004 > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > > 3 0x00044000 0x00243fff "rootfsa" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > > 4 0x00244000 0x00443fff "rootfsb" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > > 5 0x00444000 0x0070bfde "data" > > > > attrs: 0x > > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > > > So, what I understand is If I create the GPT first and then write > > > > the SPL, the SPL writing process will destroy the GPT Table and > > > > if I write SPL first and then create GPT, the GPT creation > > > > process will destroy the SPL. > > > > > > > > Is there any way to fix this? I remember we can prevent this > > > > overlap by preserving GPT Table som other or boot partition > > > > instead of having them at the beginning by default. > > > > > > > > Any inputs? > > > > > > On the diagram of GPT description [1] there is the info that > > > partitions can start from LBA 34 (0x200 * 34) = 0x4400 > > > > > > From the above it seems like you starts from 0x4000 your boota > > > partition, which then overwrites the "Entries 5-128" which shall be > > > 0 and are protected by CRC written in the Primary GPT Header. > > > > > > Please try to adjust your partition scheme to start from 0x4400. > > > > I still see the overlap. I have created boota at 0x4400 and the write > > the SPL at 0x400 > ^^ - this overwrites the GPT header IMHO. True, this overlap GPT. and we don't have an option since ROM expecting the SPL at 0x400. > > You may dump the eMMC and check if this is the case (even with u-boot's > md.l utility) > > > I had similar problem on some Beagle Bone Black (AM33x) board. > > The ROM wanted to boot from the fixed eMMC LBA offset which was clashing > with GPT. > > Fortunately, it was also possible to boot from FAT (it was checked > before the raw offset from eMMC case) partition, so I used this option > instead. You mean create FAT partition and copy SPL/U-Boot binaries on the directory? > > > But hey, isn't it possible to store SPL/u-boot to
Re: [U-Boot] [PATCH v2 2/8] rockchip: rk3399: Support common spl_board_init
On Thu, Jun 20, 2019 at 11:57 AM Jagan Teki wrote:
>
> Support common spl_board_init by moving code from puma
> board file into, common rk3399-board-spl.c.
>
> Part of the code has sysreset-gpio, regulators_enable_boot_on
> but right now only puma board is using this with relevant
> config options rest remains common for all targets.
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm/mach-rockchip/rk3399-board-spl.c | 63 +++
> board/rockchip/evb_rk3399/evb-rk3399.c| 8 ---
> .../puma_rk3399/puma-rk3399.c | 58 -
> board/vamrs/rock960_rk3399/rock960-rk3399.c | 8 ---
> 4 files changed, 63 insertions(+), 74 deletions(-)
>
> diff --git a/arch/arm/mach-rockchip/rk3399-board-spl.c
> b/arch/arm/mach-rockchip/rk3399-board-spl.c
> index 800ca80022..65c98b697d 100644
> --- a/arch/arm/mach-rockchip/rk3399-board-spl.c
> +++ b/arch/arm/mach-rockchip/rk3399-board-spl.c
> @@ -11,13 +11,16 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> void board_return_to_bootrom(void)
> @@ -202,6 +205,66 @@ void board_init_f(ulong dummy)
> }
> }
>
> +#if defined(SPL_GPIO_SUPPORT)
That hasn't been compile tested since "defined(SPL_GPIO_SUPPORT)"
ensures that this code never compiles.
It should be CONFIG_SPL_GPIO_SUPPORT instead, and it won't compile due
to missing header in this case.
Unfortunately code won't work even with missing include added since
something else is broken and it fails to request gpio.
> +static void rk3399_force_power_on_reset(void)
> +{
> + ofnode node;
> + struct gpio_desc sysreset_gpio;
> +
> + debug("%s: trying to force a power-on reset\n", __func__);
> +
> + node = ofnode_path("/config");
> + if (!ofnode_valid(node)) {
> + debug("%s: no /config node?\n", __func__);
> + return;
> + }
> +
> + if (gpio_request_by_name_nodev(node, "sysreset-gpio", 0,
> + _gpio, GPIOD_IS_OUT)) {
> + debug("%s: could not find a /config/sysreset-gpio\n",
> __func__);
> + return;
> + }
> +
> + dm_gpio_set_value(_gpio, 1);
> +}
> +#endif
> +
> +void spl_board_init(void)
> +{
> +#if defined(SPL_GPIO_SUPPORT)
> + struct rk3399_cru *cru = rockchip_get_cru();
> +
> + /*
> +* The RK3399 resets only 'almost all logic' (see also in the TRM
> +* "3.9.4 Global software reset"), when issuing a software reset.
> +* This may cause issues during boot-up for some configurations of
> +* the application software stack.
> +*
> +* To work around this, we test whether the last reset reason was
> +* a power-on reset and (if not) issue an overtemp-reset to reset
> +* the entire module.
> +*
> +* While this was previously fixed by modifying the various places
> +* that could generate a software reset (e.g. U-Boot's sysreset
> +* driver, the ATF or Linux), we now have it here to ensure that
> +* we no longer have to track this through the various components.
> +*/
> + if (cru->glb_rst_st != 0)
> + rk3399_force_power_on_reset();
> +#endif
> +
> +#if defined(SPL_DM_REGULATOR)
> + /*
> +* Turning the eMMC and SPI back on (if disabled via the Qseven
> +* BIOS_ENABLE) signal is done through a always-on regulator).
> +*/
> + if (regulators_enable_boot_on(false))
> + debug("%s: Cannot enable boot on regulator\n", __func__);
> +#endif
> +
> + preloader_console_init();
> +}
> +
> #ifdef CONFIG_SPL_LOAD_FIT
> int board_fit_config_name_match(const char *name)
> {
> diff --git a/board/rockchip/evb_rk3399/evb-rk3399.c
> b/board/rockchip/evb_rk3399/evb-rk3399.c
> index 769b5d146f..c600553ff6 100644
> --- a/board/rockchip/evb_rk3399/evb-rk3399.c
> +++ b/board/rockchip/evb_rk3399/evb-rk3399.c
> @@ -8,7 +8,6 @@
> #include
> #include
> #include
> -#include
>
> int board_init(void)
> {
> @@ -64,10 +63,3 @@ int board_init(void)
> out:
> return 0;
> }
> -
> -void spl_board_init(void)
> -{
> - preloader_console_init();
> -
> - return;
> -}
> diff --git a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> index c6b509c109..251cd2d566 100644
> --- a/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> +++ b/board/theobroma-systems/puma_rk3399/puma-rk3399.c
> @@ -13,10 +13,8 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -38,62 +36,6 @@ int board_init(void)
> return 0;
> }
>
> -static void rk3399_force_power_on_reset(void)
> -{
> - ofnode node;
> - struct gpio_desc sysreset_gpio;
> -
> - debug("%s: trying to force a
[U-Boot] [PATCH v1] configs: ls1028ardb: enable ugreen usb network card AX88179 and AX8817X drvier
enable ls1028ardb ugreen usb network card AX88179 and AX8817X driver Signed-off-by: Yinbo Zhu --- configs/ls1028ardb_tfa_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/ls1028ardb_tfa_defconfig b/configs/ls1028ardb_tfa_defconfig index 0664014..fc6d2ec 100644 --- a/configs/ls1028ardb_tfa_defconfig +++ b/configs/ls1028ardb_tfa_defconfig @@ -78,4 +78,6 @@ CONFIG_WDT_SP805=y CONFIG_MMC_IO_VOLTAGE=y CONFIG_USB_HOST_ETHER=y CONFIG_USB_ETHER_RTL8152=y +CONFIG_USB_ETHER_ASIX=y +CONFIG_USB_ETHER_ASIX88179=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 073/101] spi: ich: Support hardware sequencing
Hi Simon,
On Thu, Nov 28, 2019 at 11:19 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Wed, 27 Nov 2019 at 20:08, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Thu, Nov 28, 2019 at 10:23 AM Simon Glass wrote:
> > >
> > > Hi Bin,
> > >
> > > On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> > > > >
> > > > > Apollo Lake (APL) only supports hardware sequencing. Add support for
> > > > > this
> > > > > into the SPI driver, as an option.
> > > > >
> > > > > Signed-off-by: Simon Glass
> > > > >
> > > > > ---
> > > > >
> > > > > Changes in v5: None
> > > > > Changes in v4:
> > > > > - Fix comment for exec_sync_hwseq_xfer()
> > > > > - apollolake -> Apollo Lake
> > > > >
> > > > > Changes in v3: None
> > > > > Changes in v2: None
> > > > >
> > > > > drivers/spi/ich.c | 205
> > > > > +-
> > > > > drivers/spi/ich.h | 39 +
> > > > > 2 files changed, 241 insertions(+), 3 deletions(-)
> > > > >
> > > >
> > > > [snip]
> > > >
> > > > > +static int ich_spi_exec_op(struct spi_slave *slave, const struct
> > > > > spi_mem_op *op)
> > > > > +{
> > > > > + struct udevice *bus = dev_get_parent(slave->dev);
> > > > > + struct ich_spi_platdata *plat = dev_get_platdata(bus);
> > > > > + int ret;
> > > > > +
> > > > > + bootstage_start(BOOTSTAGE_ID_ACCUM_SPI, "fast_spi");
> > > > > + if (plat->hwseq)
> > > > > + ret = ich_spi_exec_op_hwseq(slave, op);
> > > > > + else
> > > > > + ret = ich_spi_exec_op_swseq(slave, op);
> > > > > + bootstage_accum(BOOTSTAGE_ID_ACCUM_SPI);
> > > > > +
> > > > > + return ret;
> > > > > +}
> > > > > +
> > > > > static int ich_spi_adjust_size(struct spi_slave *slave, struct
> > > > > spi_mem_op *op)
> > > > > {
> > > > > unsigned int page_offset;
> > > > > @@ -583,9 +778,11 @@ static int ich_spi_child_pre_probe(struct
> > > > > udevice *dev)
> > > > >
> > > > > /*
> > > > > * Yes this controller can only write a small number of bytes
> > > > > at
> > > > > -* once! The limit is typically 64 bytes.
> > > > > +* once! The limit is typically 64 bytes. For hardware
> > > > > sequencing a
> > > > > +* a loop is used to get around this.
> > > > > */
> > > > > - slave->max_write_size = priv->databytes;
> > > > > + if (!plat->hwseq)
> > > > > + slave->max_write_size = priv->databytes;
> > > > > /*
> > > > > * ICH 7 SPI controller only supports array read command
> > > > > * and byte program command for SST flash
> > > > > @@ -611,10 +808,12 @@ static int ich_spi_ofdata_to_platdata(struct
> > > > > udevice *dev)
> > > > > plat->ich_version = dev_get_driver_data(dev);
> > > > > plat->lockdown = dev_read_bool(dev, "intel,spi-lock-down");
> > > > > pch_get_spi_base(priv->pch, >mmio_base);
> > > > > + plat->hwseq = dev_read_u32_default(dev, "intel,hardware-seq",
> > > > > 0);
> > > >
> > > > I believe dev_read_bool() is enough for now, unless we have different
> > > > types of hardware sequencer to support?
> > >
> > > Yes I remember this...unfortunately dtoc does not generate a struct
> > > member for a bool if it is not present (since it has no way of knowing
> > > it *might* be there.
> > >
> >
> > OK, could you please put a comment here?
>
> Yes, will do.
>
> I'll hold off sending any updates for now. I'll redo the cr50/tpm
> series after that. I am playing around with ACPI too, but best to send
> that one we have this one sorted out.
>
OK. I plan to continue reviewing the remaining patches. But if you can
hold on sending more ACPI patches, that will be helpful. I will see if
I can selectively pick up patches that look good to save both our
time.
> >
> > > So to keep of-platdata happy I made this a 0/1 value.
> > >
> > > We probably need a better solution but I don't have one right now.
> > >
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 073/101] spi: ich: Support hardware sequencing
Hi Bin,
On Wed, 27 Nov 2019 at 20:08, Bin Meng wrote:
>
> Hi Simon,
>
> On Thu, Nov 28, 2019 at 10:23 AM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
> > >
> > > Hi Simon,
> > >
> > > On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> > > >
> > > > Apollo Lake (APL) only supports hardware sequencing. Add support for
> > > > this
> > > > into the SPI driver, as an option.
> > > >
> > > > Signed-off-by: Simon Glass
> > > >
> > > > ---
> > > >
> > > > Changes in v5: None
> > > > Changes in v4:
> > > > - Fix comment for exec_sync_hwseq_xfer()
> > > > - apollolake -> Apollo Lake
> > > >
> > > > Changes in v3: None
> > > > Changes in v2: None
> > > >
> > > > drivers/spi/ich.c | 205 +-
> > > > drivers/spi/ich.h | 39 +
> > > > 2 files changed, 241 insertions(+), 3 deletions(-)
> > > >
> > >
> > > [snip]
> > >
> > > > +static int ich_spi_exec_op(struct spi_slave *slave, const struct
> > > > spi_mem_op *op)
> > > > +{
> > > > + struct udevice *bus = dev_get_parent(slave->dev);
> > > > + struct ich_spi_platdata *plat = dev_get_platdata(bus);
> > > > + int ret;
> > > > +
> > > > + bootstage_start(BOOTSTAGE_ID_ACCUM_SPI, "fast_spi");
> > > > + if (plat->hwseq)
> > > > + ret = ich_spi_exec_op_hwseq(slave, op);
> > > > + else
> > > > + ret = ich_spi_exec_op_swseq(slave, op);
> > > > + bootstage_accum(BOOTSTAGE_ID_ACCUM_SPI);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > static int ich_spi_adjust_size(struct spi_slave *slave, struct
> > > > spi_mem_op *op)
> > > > {
> > > > unsigned int page_offset;
> > > > @@ -583,9 +778,11 @@ static int ich_spi_child_pre_probe(struct udevice
> > > > *dev)
> > > >
> > > > /*
> > > > * Yes this controller can only write a small number of bytes at
> > > > -* once! The limit is typically 64 bytes.
> > > > +* once! The limit is typically 64 bytes. For hardware
> > > > sequencing a
> > > > +* a loop is used to get around this.
> > > > */
> > > > - slave->max_write_size = priv->databytes;
> > > > + if (!plat->hwseq)
> > > > + slave->max_write_size = priv->databytes;
> > > > /*
> > > > * ICH 7 SPI controller only supports array read command
> > > > * and byte program command for SST flash
> > > > @@ -611,10 +808,12 @@ static int ich_spi_ofdata_to_platdata(struct
> > > > udevice *dev)
> > > > plat->ich_version = dev_get_driver_data(dev);
> > > > plat->lockdown = dev_read_bool(dev, "intel,spi-lock-down");
> > > > pch_get_spi_base(priv->pch, >mmio_base);
> > > > + plat->hwseq = dev_read_u32_default(dev, "intel,hardware-seq",
> > > > 0);
> > >
> > > I believe dev_read_bool() is enough for now, unless we have different
> > > types of hardware sequencer to support?
> >
> > Yes I remember this...unfortunately dtoc does not generate a struct
> > member for a bool if it is not present (since it has no way of knowing
> > it *might* be there.
> >
>
> OK, could you please put a comment here?
Yes, will do.
I'll hold off sending any updates for now. I'll redo the cr50/tpm
series after that. I am playing around with ACPI too, but best to send
that one we have this one sorted out.
>
> > So to keep of-platdata happy I made this a 0/1 value.
> >
> > We probably need a better solution but I don't have one right now.
> >
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/2] part: always enable part_get_info_ptr() for driver
Hi Tom, Simon,
Is there anything I need to update for this patch?
Thanks,
- Kever
Kever Yang 于2019年8月15日周四 下午4:32写道：
> The partition driver has its Kconfig option, and the part_get_info_prt()
> interface are mendatory interface for partition drivers, always enable the
> macro to make partition driver works correctly.
>
> Signed-off-by: Kever Yang
> ---
>
> Changes in v4:
> - formate commit message to ~75 columns
>
> Changes in v3: None
> Changes in v2:
> - add patch to use SPL_PARTITIONS so that we don't add disk driver for
> boards who don't need it.
>
> include/part.h | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/include/part.h b/include/part.h
> index ebca546db5..7d00fae56f 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -241,22 +241,15 @@ static inline int blk_get_device_part_str(const char
> *ifname,
> #endif
>
> /*
> - * We don't support printing partition information in SPL and only support
> - * getting partition information in a few cases.
> + * We don't support printing partition information in SPL
> */
> #ifdef CONFIG_SPL_BUILD
> # define part_print_ptr(x) NULL
> -# if defined(CONFIG_SPL_FS_EXT4) || defined(CONFIG_SPL_FS_FAT) || \
> - defined(CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION)
> -# define part_get_info_ptr(x) x
> -# else
> -# define part_get_info_ptr(x) NULL
> -# endif
> #else
> #define part_print_ptr(x) x
> -#define part_get_info_ptr(x) x
> #endif
>
> +#define part_get_info_ptr(x) x
>
> struct part_driver {
> const char *name;
> --
> 2.17.1
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 073/101] spi: ich: Support hardware sequencing
Hi Simon,
On Thu, Nov 28, 2019 at 10:23 AM Simon Glass wrote:
>
> Hi Bin,
>
> On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
> >
> > Hi Simon,
> >
> > On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> > >
> > > Apollo Lake (APL) only supports hardware sequencing. Add support for this
> > > into the SPI driver, as an option.
> > >
> > > Signed-off-by: Simon Glass
> > >
> > > ---
> > >
> > > Changes in v5: None
> > > Changes in v4:
> > > - Fix comment for exec_sync_hwseq_xfer()
> > > - apollolake -> Apollo Lake
> > >
> > > Changes in v3: None
> > > Changes in v2: None
> > >
> > > drivers/spi/ich.c | 205 +-
> > > drivers/spi/ich.h | 39 +
> > > 2 files changed, 241 insertions(+), 3 deletions(-)
> > >
> >
> > [snip]
> >
> > > +static int ich_spi_exec_op(struct spi_slave *slave, const struct
> > > spi_mem_op *op)
> > > +{
> > > + struct udevice *bus = dev_get_parent(slave->dev);
> > > + struct ich_spi_platdata *plat = dev_get_platdata(bus);
> > > + int ret;
> > > +
> > > + bootstage_start(BOOTSTAGE_ID_ACCUM_SPI, "fast_spi");
> > > + if (plat->hwseq)
> > > + ret = ich_spi_exec_op_hwseq(slave, op);
> > > + else
> > > + ret = ich_spi_exec_op_swseq(slave, op);
> > > + bootstage_accum(BOOTSTAGE_ID_ACCUM_SPI);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > static int ich_spi_adjust_size(struct spi_slave *slave, struct
> > > spi_mem_op *op)
> > > {
> > > unsigned int page_offset;
> > > @@ -583,9 +778,11 @@ static int ich_spi_child_pre_probe(struct udevice
> > > *dev)
> > >
> > > /*
> > > * Yes this controller can only write a small number of bytes at
> > > -* once! The limit is typically 64 bytes.
> > > +* once! The limit is typically 64 bytes. For hardware sequencing
> > > a
> > > +* a loop is used to get around this.
> > > */
> > > - slave->max_write_size = priv->databytes;
> > > + if (!plat->hwseq)
> > > + slave->max_write_size = priv->databytes;
> > > /*
> > > * ICH 7 SPI controller only supports array read command
> > > * and byte program command for SST flash
> > > @@ -611,10 +808,12 @@ static int ich_spi_ofdata_to_platdata(struct
> > > udevice *dev)
> > > plat->ich_version = dev_get_driver_data(dev);
> > > plat->lockdown = dev_read_bool(dev, "intel,spi-lock-down");
> > > pch_get_spi_base(priv->pch, >mmio_base);
> > > + plat->hwseq = dev_read_u32_default(dev, "intel,hardware-seq", 0);
> >
> > I believe dev_read_bool() is enough for now, unless we have different
> > types of hardware sequencer to support?
>
> Yes I remember this...unfortunately dtoc does not generate a struct
> member for a bool if it is not present (since it has no way of knowing
> it *might* be there.
>
OK, could you please put a comment here?
> So to keep of-platdata happy I made this a 0/1 value.
>
> We probably need a better solution but I don't have one right now.
>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/2] disk: update to use SPL_PARTITIONS for SPL
Hi Tom, Simon
ping...
Is it OK to merge this patch?
Thanks
- Kever
Kever Yang 于2019年8月15日周四 下午4:32写道：
> The SPL disk driver can not depends on SPL_FRAMEWORK & PARTITIONS, which
> will enable the disk driver when we actually not need it. Use a separate
> Kconfig to control the partition driver in SPL and fix the issue caused by:
> Fixes: 91ff686562 ("blk: Rework guard around part_init call")
>
> Signed-off-by: Kever Yang
> Reviewed-by: Simon Glass
> ---
>
> Changes in v4:
> - format the commit message to ~75 columns.
>
> Changes in v3:
> - update code in blk-uclass.c
>
> Changes in v2:
> - add this patch
>
> common/spl/Kconfig | 2 +-
> disk/Kconfig | 20
> disk/Makefile | 2 +-
> drivers/block/blk-uclass.c | 2 +-
> scripts/Makefile.spl | 2 +-
> 5 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/common/spl/Kconfig b/common/spl/Kconfig
> index 5978fb2934..094680e54d 100644
> --- a/common/spl/Kconfig
> +++ b/common/spl/Kconfig
> @@ -544,7 +544,7 @@ config SPL_LIBCOMMON_SUPPORT
>
> config SPL_LIBDISK_SUPPORT
> bool "Support disk partitions"
> - select PARTITIONS
> + select SPL_PARTITIONS
> help
> Enable support for disk partitions within SPL. 'Disk' is
> something
> of a misnomer as it includes non-spinning media such as flash (as
> diff --git a/disk/Kconfig b/disk/Kconfig
> index 28fb81c2ee..43e76cb49d 100644
> --- a/disk/Kconfig
> +++ b/disk/Kconfig
> @@ -4,9 +4,7 @@ menu "Partition Types"
> config PARTITIONS
> bool "Enable Partition Labels (disklabels) support"
> default y
> - select SPL_SPRINTF if SPL
> select TPL_SPRINTF if TPL
> - select SPL_STRTO if SPL
> select TPL_STRTO if TPL
> help
> Partition Labels (disklabels) Supported:
> @@ -23,6 +21,12 @@ config PARTITIONS
> you must configure support for at least one non-MTD partition
> type
> as well.
>
> +config SPL_PARTITIONS
> + select SPL_SPRINTF
> + select SPL_STRTO
> + bool "Enable Partition Labels (disklabels) support for SPL"
> + depends on SPL
> +
> config MAC_PARTITION
> bool "Enable Apple's MacOS partition table"
> depends on PARTITIONS
> @@ -32,7 +36,7 @@ config MAC_PARTITION
>
> config SPL_MAC_PARTITION
> bool "Enable Apple's MacOS partition table for SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
> default y if MAC_PARTITION
>
> config DOS_PARTITION
> @@ -45,7 +49,7 @@ config DOS_PARTITION
>
> config SPL_DOS_PARTITION
> bool "Enable MS Dos partition table for SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
> default y if DOS_PARTITION
>
> config ISO_PARTITION
> @@ -56,7 +60,7 @@ config ISO_PARTITION
>
> config SPL_ISO_PARTITION
> bool "Enable ISO partition table for SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
>
> config AMIGA_PARTITION
> bool "Enable AMIGA partition table"
> @@ -67,7 +71,7 @@ config AMIGA_PARTITION
>
> config SPL_AMIGA_PARTITION
> bool "Enable AMIGA partition table for SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
> default y if AMIGA_PARTITION
>
> config EFI_PARTITION
> @@ -111,7 +115,7 @@ config EFI_PARTITION_ENTRIES_OFF
>
> config SPL_EFI_PARTITION
> bool "Enable EFI GPT partition table for SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
> default y if EFI_PARTITION
>
> config PARTITION_UUIDS
> @@ -125,7 +129,7 @@ config PARTITION_UUIDS
>
> config SPL_PARTITION_UUIDS
> bool "Enable support of UUID for partition in SPL"
> - depends on SPL && PARTITIONS
> + depends on SPL_PARTITIONS
> default y if SPL_EFI_PARTITION
>
> config PARTITION_TYPE_GUID
> diff --git a/disk/Makefile b/disk/Makefile
> index ccd0335959..92fcc2b4ac 100644
> --- a/disk/Makefile
> +++ b/disk/Makefile
> @@ -5,7 +5,7 @@
>
> #ccflags-y += -DET_DEBUG -DDEBUG
>
> -obj-$(CONFIG_PARTITIONS) += part.o
> +obj-$(CONFIG_$(SPL_)PARTITIONS) += part.o
> obj-$(CONFIG_$(SPL_)MAC_PARTITION) += part_mac.o
> obj-$(CONFIG_$(SPL_)DOS_PARTITION) += part_dos.o
> obj-$(CONFIG_$(SPL_)ISO_PARTITION) += part_iso.o
> diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
> index c23b6682a6..425ec3259f 100644
> --- a/drivers/block/blk-uclass.c
> +++ b/drivers/block/blk-uclass.c
> @@ -649,7 +649,7 @@ int blk_unbind_all(int if_type)
>
> static int blk_post_probe(struct udevice *dev)
> {
> -#if defined(CONFIG_PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
> +#if CONFIG_IS_ENABLED(PARTITIONS) && defined(CONFIG_HAVE_BLOCK_DEVICE)
> struct blk_desc *desc = dev_get_uclass_platdata(dev);
>
> part_init(desc);
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index
Re: [U-Boot] [PATCH v5 045/101] x86: fsp: Add FSP2 base support
Hi Simon, On Thu, Nov 28, 2019 at 10:22 AM Simon Glass wrote: > > HI Bin, > > On Tue, 26 Nov 2019 at 23:11, Bin Meng wrote: > > > > Hi Simon, > > > > On Wed, Nov 27, 2019 at 1:08 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Tue, 26 Nov 2019 at 01:36, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Mon, Nov 25, 2019 at 12:11 PM Simon Glass wrote: > > > > > > > > > > Add support for some important configuration options and FSP memory > > > > > init. > > > > > The memory init uses swizzle tables from the device tree. > > > > > > > > > > Support for the FSP_S binary is also included. > > > > > > > > > > Bootstage timing is used for both FSP_M and FSP_S and memory-mapped > > > > > SPI > > > > > reads. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > Changes in v5: > > > > > - Drop SAFETY_MARGIN > > > > > > > > > > Changes in v4: > > > > > - Add a LOG_CATEGORY for silicon init > > > > > - Drop duplicate VBT file CONFIG > > > > > - Enable HAVE_VBT for FSP2 also > > > > > - Explain the 'twisty headers' comment > > > > > - Fix FSP_M reference to refer to FSP_S in commit message > > > > > - Fix comment on fsp_silicon_init() > > > > > - Rename arch_fsp_s_preinit() to arch_fsps_preinit() > > > > > - Rename get_coreboot_fsp() and add comments > > > > > - Switch over to use pinctrl for pad init/config > > > > > - Use lower-case pinctrl in arch_cpu_init_dm() > > > > > > > > > > Changes in v3: > > > > > - Add a proper implementation of fsp_notify > > > > > - Add an fsp: tag > > > > > - Add bootstage timing for memory-mapped reads > > > > > - Add fsp_locate_fsp to locate an fsp component > > > > > - Add fspm_done() hook > > > > > - Add support for FSP-S component and VBT > > > > > - Simplify types for fsp_locate_fsp() > > > > > - Switch mmap to use SPI instead of SPI flash > > > > > > > > > > Changes in v2: None > > > > > > > > > > arch/x86/Kconfig | 54 ++- > > > > > arch/x86/include/asm/fsp2/fsp_api.h | 63 > > > > > arch/x86/include/asm/fsp2/fsp_internal.h | 97 + > > > > > arch/x86/lib/fsp2/Makefile | 10 ++ > > > > > arch/x86/lib/fsp2/fsp_common.c | 13 ++ > > > > > arch/x86/lib/fsp2/fsp_dram.c | 77 ++ > > > > > arch/x86/lib/fsp2/fsp_init.c | 174 > > > > > +++ > > > > > arch/x86/lib/fsp2/fsp_meminit.c | 97 + > > > > > arch/x86/lib/fsp2/fsp_silicon_init.c | 54 +++ > > > > > arch/x86/lib/fsp2/fsp_support.c | 131 + > > > > > include/bootstage.h | 3 + > > > > > 11 files changed, 770 insertions(+), 3 deletions(-) > > > > > create mode 100644 arch/x86/include/asm/fsp2/fsp_api.h > > > > > create mode 100644 arch/x86/include/asm/fsp2/fsp_internal.h > > > > > create mode 100644 arch/x86/lib/fsp2/Makefile > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_common.c > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_dram.c > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_init.c > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_meminit.c > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_silicon_init.c > > > > > create mode 100644 arch/x86/lib/fsp2/fsp_support.c > > > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > > index 17a6fe6d3d..6bac5d5fe8 100644 > > > > > --- a/arch/x86/Kconfig > > > > > +++ b/arch/x86/Kconfig > > > > > @@ -326,7 +326,7 @@ config X86_RAMTEST > > > > > > > > > > config FLASH_DESCRIPTOR_FILE > > > > > string "Flash descriptor binary filename" > > > > > - depends on HAVE_INTEL_ME > > > > > + depends on HAVE_INTEL_ME || FSP_VERSION2 > > > > > default "descriptor.bin" > > > > > help > > > > > The filename of the file to use as flash descriptor in the > > > > > @@ -411,6 +411,54 @@ config FSP_ADDR > > > > > The default base address of 0xfffc indicates that the > > > > > binary must > > > > > be located at offset 0xc from the beginning of a 1MB > > > > > flash device. > > > > > > > > > > +if FSP_VERSION2 > > > > > + > > > > > +config FSP_FILE_T > > > > > + string "Firmware-Support-Package binary filename (Temp RAM)" > > > > > + default "fsp_t.bin" > > > > > + help > > > > > + The filename of the file to use for the temporary-RAM init > > > > > phase from > > > > > + the Firmware-Support-Package binary. Put this in the board > > > > > directory. > > > > > > > > nits: Firmware Support Package (drop -) > > > > > > OK...the hyphens are actually correct I think, but perhaps make it > > > hard to search for. > > > > > > [..] > > > > > > > > config VIDEO_FSP > > > > > bool "Enable FSP framebuffer driver support" > > > > > - depends on HAVE_VBT && DM_VIDEO > > > > > + depends on (HAVE_VBT || FSP_VERSION2) && DM_VIDEO > > > > > > > > I think the original logic already
Re: [U-Boot] [EXT] Re: [PATCH 2/5] Revert "ata: fsl_ahci: Add sata DM support for Freescale powerpc socs"
>-Original Message-
>From: Stefan Roese
>Sent: 2019年11月27日 18:31
>To: Peng Ma ; Priyanka Jain ;
>w...@denx.de; Ruchika Gupta ; Shengzhou Liu
>
>Cc: Yinbo Zhu ; Z.q. Hou ;
>s...@chromium.org; ja...@openedev.com; andre.przyw...@arm.com;
>sm...@web.de; Andy Tang ; u-boot@lists.denx.de
>Subject: [EXT] Re: [PATCH 2/5] Revert "ata: fsl_ahci: Add sata DM support for
>Freescale powerpc socs"
>
>Caution: EXT Email
>
>Hi Peng,
>
>On 27.11.19 11:02, Peng Ma wrote:
>> This reverts commit 1ee494291880fd51ef0c5f7342e072bdb069d7ff.
>
>I'm missing an explanation for this revert (or even better for this whole
>patch-set). Why are you doing this? Is the new DM driver causing problems?
>
Hi, Stefan,
I will refresh these series patches for v2.
Thanks very much for your points.
Best Regards,
Peng
>Thanks,
>Stefan
>
>> Signed-off-by: Peng Ma
>> ---
>> drivers/ata/Kconfig| 10 -
>> drivers/ata/Makefile |1 -
>> drivers/ata/fsl_ahci.c | 1030
>> drivers/ata/fsl_sata.h |1 -
>> 4 files changed, 1042 deletions(-)
>> delete mode 100644 drivers/ata/fsl_ahci.c
>>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index
>> fe589d3aa8..d8c9756c2a 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -59,16 +59,6 @@ config DWC_AHCI
>> Enable this driver to support Sata devices through
>> Synopsys DWC AHCI module.
>>
>> -config FSL_AHCI
>> - bool "Enable Freescale AHCI driver support"
>> - select SCSI_AHCI
>> - depends on AHCI
>> - depends on DM_SCSI
>> - help
>> - Enable this driver to support Sata devices found in
>> - some Freescale PowerPC SoCs.
>> -
>> -
>> config DWC_AHSATA
>> bool "Enable DWC AHSATA driver support"
>> select LIBATA
>> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index
>> 6e03384f81..a69edb10f7 100644
>> --- a/drivers/ata/Makefile
>> +++ b/drivers/ata/Makefile
>> @@ -4,7 +4,6 @@
>> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>
>> obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
>> -obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
>> obj-$(CONFIG_AHCI) += ahci-uclass.o
>> obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
>> obj-$(CONFIG_SCSI_AHCI) += ahci.o
>> diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c deleted
>> file mode 100644 index d04cff3ee7..00
>> --- a/drivers/ata/fsl_ahci.c
>> +++ /dev/null
>> @@ -1,1030 +0,0 @@
>> -// SPDX-License-Identifier: GPL-2.0+
>> -/*
>> - * NXP PPC SATA platform driver
>> - *
>> - * (C) Copyright 2019 NXP, Inc.
>> - *
>> - */
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include "fsl_sata.h"
>> -
>> -struct fsl_ahci_priv {
>> - u32 base;
>> - u32 flag;
>> - u32 number;
>> - fsl_sata_t *fsl_sata;
>> -};
>> -
>> -static int fsl_ahci_bind(struct udevice *dev) -{
>> - return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
>> -}
>> -
>> -static int fsl_ahci_ofdata_to_platdata(struct udevice *dev) -{
>> - struct fsl_ahci_priv *priv = dev_get_priv(dev);
>> -
>> - priv->number = dev_read_u32_default(dev, "sata-number", -1);
>> - priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
>> -
>> - priv->base = dev_read_addr(dev);
>> - if (priv->base == FDT_ADDR_T_NONE)
>> - return -EINVAL;
>> -
>> - return 0;
>> -}
>> -
>> -static int ata_wait_register(unsigned __iomem *addr, u32 mask,
>> - u32 val, u32 timeout_msec)
>> -{
>> - int i;
>> -
>> - for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
>> - mdelay(1);
>> -
>> - return (i < timeout_msec) ? 0 : -1;
>> -}
>> -
>> -static void fsl_sata_dump_sfis(struct sata_fis_d2h *s) -{
>> - printf("Status FIS dump:\n\r");
>> - printf("fis_type: %02x\n\r", s->fis_type);
>> - printf("pm_port_i: %02x\n\r", s->pm_port_i);
>> - printf("status: %02x\n\r", s->status);
>> - printf("error: %02x\n\r", s->error);
>> - printf("lba_low:%02x\n\r", s->lba_low);
>> - printf("lba_mid:%02x\n\r", s->lba_mid);
>> - printf("lba_high: %02x\n\r", s->lba_high);
>> - printf("device: %02x\n\r", s->device);
>> - printf("lba_low_exp:%02x\n\r", s->lba_low_exp);
>> - printf("lba_mid_exp:%02x\n\r", s->lba_mid_exp);
>> - printf("lba_high_exp: %02x\n\r", s->lba_high_exp);
>> - printf("res1: %02x\n\r", s->res1);
>> - printf("sector_count: %02x\n\r", s->sector_count);
>> - printf("sector_count_exp: %02x\n\r", s->sector_count_exp);
>> -}
>> -
>> -static void fsl_sata_dump_regs(fsl_sata_reg_t __iomem *reg) -{
>> - printf("\n\rSATA: %08x\n\r", (u32)reg);
>> - printf("CQR:
Re: [U-Boot] [EXT] Re: [PATCH 1/5] Revert "powerpc: mpc85xx: delete FSL_SATA for T2080QDS board."
>-Original Message- >From: Wolfgang Denk >Sent: 2019年11月28日 0:08 >To: Peng Ma >Cc: Priyanka Jain ; Ruchika Gupta >; Shengzhou Liu ; Yinbo >Zhu ; Z.q. Hou ; >s...@chromium.org; ja...@openedev.com; andre.przyw...@arm.com; >s...@denx.de; sm...@web.de; Andy Tang ; >u-boot@lists.denx.de >Subject: [EXT] Re: [PATCH 1/5] Revert "powerpc: mpc85xx: delete FSL_SATA for >T2080QDS board." > >Caution: EXT Email > >Dear Peng Ma, > >In message <20191127100145.44346-1-peng...@nxp.com> you wrote: >> This reverts commit 856b9cdb53f0e6c8d98f81cf71ef363c16b0aa0e. >> >> Signed-off-by: Peng Ma > >Why? > >A commit message should always explain why such an action is taking place. > Hi, Wolfgang, I am so sorry to send these series patches(revert patches not to explain why), I will refresh them and send V2. Best Regards, Peng >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 >The high cost of living hasn't affected its popularity. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 2/5] Revert "ata: fsl_ahci: Add sata DM support for Freescale powerpc socs"
>-Original Message-
>From: Stefan Roese
>Sent: 2019年11月27日 18:31
>To: Peng Ma ; Priyanka Jain ;
>w...@denx.de; Ruchika Gupta ; Shengzhou Liu
>
>Cc: Yinbo Zhu ; Z.q. Hou ;
>s...@chromium.org; ja...@openedev.com; andre.przyw...@arm.com;
>sm...@web.de; Andy Tang ; u-boot@lists.denx.de
>Subject: [EXT] Re: [PATCH 2/5] Revert "ata: fsl_ahci: Add sata DM support for
>Freescale powerpc socs"
>
>Caution: EXT Email
>
>Hi Peng,
>
>On 27.11.19 11:02, Peng Ma wrote:
>> This reverts commit 1ee494291880fd51ef0c5f7342e072bdb069d7ff.
>
>I'm missing an explanation for this revert (or even better for this whole
>patch-set). Why are you doing this? Is the new DM driver causing problems?
>
[Peng Ma] The new driver work well but that's not the best way to do it. I make
some changes
in fsl_sata.c, please see /drivers/ata/fsl_sata.c.
Thanks,
Peng
>Thanks,
>Stefan
>
>> Signed-off-by: Peng Ma
>> ---
>> drivers/ata/Kconfig| 10 -
>> drivers/ata/Makefile |1 -
>> drivers/ata/fsl_ahci.c | 1030
>> drivers/ata/fsl_sata.h |1 -
>> 4 files changed, 1042 deletions(-)
>> delete mode 100644 drivers/ata/fsl_ahci.c
>>
>> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index
>> fe589d3aa8..d8c9756c2a 100644
>> --- a/drivers/ata/Kconfig
>> +++ b/drivers/ata/Kconfig
>> @@ -59,16 +59,6 @@ config DWC_AHCI
>> Enable this driver to support Sata devices through
>> Synopsys DWC AHCI module.
>>
>> -config FSL_AHCI
>> - bool "Enable Freescale AHCI driver support"
>> - select SCSI_AHCI
>> - depends on AHCI
>> - depends on DM_SCSI
>> - help
>> - Enable this driver to support Sata devices found in
>> - some Freescale PowerPC SoCs.
>> -
>> -
>> config DWC_AHSATA
>> bool "Enable DWC AHSATA driver support"
>> select LIBATA
>> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile index
>> 6e03384f81..a69edb10f7 100644
>> --- a/drivers/ata/Makefile
>> +++ b/drivers/ata/Makefile
>> @@ -4,7 +4,6 @@
>> # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
>>
>> obj-$(CONFIG_DWC_AHCI) += dwc_ahci.o
>> -obj-$(CONFIG_FSL_AHCI) += fsl_ahci.o
>> obj-$(CONFIG_AHCI) += ahci-uclass.o
>> obj-$(CONFIG_AHCI_PCI) += ahci-pci.o
>> obj-$(CONFIG_SCSI_AHCI) += ahci.o
>> diff --git a/drivers/ata/fsl_ahci.c b/drivers/ata/fsl_ahci.c deleted
>> file mode 100644 index d04cff3ee7..00
>> --- a/drivers/ata/fsl_ahci.c
>> +++ /dev/null
>> @@ -1,1030 +0,0 @@
>> -// SPDX-License-Identifier: GPL-2.0+
>> -/*
>> - * NXP PPC SATA platform driver
>> - *
>> - * (C) Copyright 2019 NXP, Inc.
>> - *
>> - */
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -#include
>> -
>> -#include "fsl_sata.h"
>> -
>> -struct fsl_ahci_priv {
>> - u32 base;
>> - u32 flag;
>> - u32 number;
>> - fsl_sata_t *fsl_sata;
>> -};
>> -
>> -static int fsl_ahci_bind(struct udevice *dev) -{
>> - return device_bind_driver(dev, "fsl_ahci_scsi", "fsl_ahci_scsi", NULL);
>> -}
>> -
>> -static int fsl_ahci_ofdata_to_platdata(struct udevice *dev) -{
>> - struct fsl_ahci_priv *priv = dev_get_priv(dev);
>> -
>> - priv->number = dev_read_u32_default(dev, "sata-number", -1);
>> - priv->flag = dev_read_u32_default(dev, "sata-fpdma", -1);
>> -
>> - priv->base = dev_read_addr(dev);
>> - if (priv->base == FDT_ADDR_T_NONE)
>> - return -EINVAL;
>> -
>> - return 0;
>> -}
>> -
>> -static int ata_wait_register(unsigned __iomem *addr, u32 mask,
>> - u32 val, u32 timeout_msec)
>> -{
>> - int i;
>> -
>> - for (i = 0; ((in_le32(addr) & mask) != val) && i < timeout_msec; i++)
>> - mdelay(1);
>> -
>> - return (i < timeout_msec) ? 0 : -1;
>> -}
>> -
>> -static void fsl_sata_dump_sfis(struct sata_fis_d2h *s) -{
>> - printf("Status FIS dump:\n\r");
>> - printf("fis_type: %02x\n\r", s->fis_type);
>> - printf("pm_port_i: %02x\n\r", s->pm_port_i);
>> - printf("status: %02x\n\r", s->status);
>> - printf("error: %02x\n\r", s->error);
>> - printf("lba_low:%02x\n\r", s->lba_low);
>> - printf("lba_mid:%02x\n\r", s->lba_mid);
>> - printf("lba_high: %02x\n\r", s->lba_high);
>> - printf("device: %02x\n\r", s->device);
>> - printf("lba_low_exp:%02x\n\r", s->lba_low_exp);
>> - printf("lba_mid_exp:%02x\n\r", s->lba_mid_exp);
>> - printf("lba_high_exp: %02x\n\r", s->lba_high_exp);
>> - printf("res1: %02x\n\r", s->res1);
>> - printf("sector_count: %02x\n\r", s->sector_count);
>> - printf("sector_count_exp: %02x\n\r", s->sector_count_exp);
>> -}
>> -
>> -static void fsl_sata_dump_regs(fsl_sata_reg_t __iomem *reg) -{
>> - printf("\n\rSATA:
Re: [U-Boot] [PATCH v5 075/101] spi: ich: Add TPL support
Hi Bin,
On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> >
> > In TPL we want to reduce code size and support running with CONFIG_PCI
> > disabled. Add special code to handle this using a fixed BAR programmed
> > into the SPI on boot. Also cache the SPI flash to speed up boot.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> > drivers/spi/ich.c | 46 ++
> > 1 file changed, 42 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> > index ebf369f215..02601e9125 100644
> > --- a/drivers/spi/ich.c
> > +++ b/drivers/spi/ich.c
> > @@ -19,8 +19,10 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > +#include
> >
> > #include "ich.h"
> >
> > @@ -115,6 +117,8 @@ static bool ich9_can_do_33mhz(struct udevice *dev)
> > struct ich_spi_priv *priv = dev_get_priv(dev);
> > u32 fdod, speed;
> >
> > + if (!CONFIG_IS_ENABLED(PCI))
> > + return false;
> > /* Observe SPI Descriptor Component Section 0 */
> > dm_pci_write_config32(priv->pch, 0xb0, 0x1000);
> >
> > @@ -706,6 +710,15 @@ static int ich_init_controller(struct udevice *dev,
> >struct ich_spi_platdata *plat,
> >struct ich_spi_priv *ctlr)
> > {
> > + if (spl_phase() == PHASE_TPL) {
> > + struct ich_spi_platdata *plat = dev_get_platdata(dev);
> > + int ret;
> > +
> > + ret = fast_spi_early_init(plat->bdf, plat->mmio_base);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > ctlr->base = (void *)plat->mmio_base;
> > if (plat->ich_version == ICHV_7) {
> > struct ich7_spi_regs *ich7_spi = ctlr->base;
> > @@ -754,6 +767,25 @@ static int ich_init_controller(struct udevice *dev,
> > return 0;
> > }
> >
> > +static int ich_cache_bios_region(struct udevice *dev)
> > +{
> > + ulong map_base;
> > + uint map_size;
> > + uint offset;
> > + ulong base;
> > + int ret;
> > +
> > + ret = ich_get_mmap_bus(dev, _base, _size, );
> > + if (ret)
> > + return ret;
> > +
> > + base = (4ULL << 30) - map_size;
>
> Can we define a macro for this? MEM_4G?
OK.
>
> > + mtrr_set_next_var(MTRR_TYPE_WRPROT, base, map_size);
>
> Should this be MTRR_TYPE_WRBACK?
Well you are not supposed to write to SPI flash, at least not in these
early stages. I think the hardware sequencer supports it though.
>
> > + log_debug("BIOS cache base=%lx, size=%x\n", base, (uint)map_size);
> > +
> > + return 0;
> > +}
> > +
> > static int ich_spi_probe(struct udevice *dev)
> > {
> > struct ich_spi_platdata *plat = dev_get_platdata(dev);
> > @@ -764,10 +796,16 @@ static int ich_spi_probe(struct udevice *dev)
> > if (ret)
> > return ret;
> >
> > - ret = ich_protect_lockdown(dev);
> > - if (ret)
> > - return ret;
> > -
> > + if (spl_phase() == PHASE_TPL) {
> > + /* Cache the BIOS to speed things up */
> > + ret = ich_cache_bios_region(dev);
> > + if (ret)
> > + return ret;
> > + } else {
> > + ret = ich_protect_lockdown(dev);
> > + if (ret)
> > + return ret;
> > + }
> > priv->cur_speed = priv->max_speed;
> >
> > return 0;
> > --
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 078/101] x86: Enable pinctrl in SPL and TPL
Hi Bin, On Wed, 27 Nov 2019 at 02:08, Bin Meng wrote: > > Hi Simon, > > On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote: > > > > If these phases are used we typically want to enable pinctrl in then, so > > that pad setup and GPIO access are possible. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v5: > > - Correct build error in chromebook_samus_tpl > > > > Changes in v4: None > > Changes in v3: None > > Changes in v2: None > > > > arch/Kconfig | 2 ++ > > configs/chromebook_samus_tpl_defconfig | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/arch/Kconfig b/arch/Kconfig > > index 54de91afb3..ae9c93ed7b 100644 > > --- a/arch/Kconfig > > +++ b/arch/Kconfig > > @@ -193,6 +193,7 @@ config X86 > > imply SPL_OF_LIBFDT > > imply SPL_DRIVERS_MISC_SUPPORT > > imply SPL_GPIO_SUPPORT > > + imply SPL_PINCTRL > > imply SPL_LIBCOMMON_SUPPORT > > imply SPL_LIBGENERIC_SUPPORT > > imply SPL_SERIAL_SUPPORT > > @@ -206,6 +207,7 @@ config X86 > > imply TPL_DM > > imply TPL_DRIVERS_MISC_SUPPORT > > imply TPL_GPIO_SUPPORT > > + imply TPL_PINCTRL > > imply TPL_LIBCOMMON_SUPPORT > > imply TPL_LIBGENERIC_SUPPORT > > imply TPL_SERIAL_SUPPORT > > diff --git a/configs/chromebook_samus_tpl_defconfig > > b/configs/chromebook_samus_tpl_defconfig > > index fc6ceeac70..44e6d33181 100644 > > --- a/configs/chromebook_samus_tpl_defconfig > > +++ b/configs/chromebook_samus_tpl_defconfig > > @@ -73,6 +73,8 @@ CONFIG_SYS_I2C_DW=y > > CONFIG_TPL_MISC=y > > CONFIG_CROS_EC=y > > CONFIG_CROS_EC_LPC=y > > +# CONFIG_SPL_PINCTRL is not set > > +# CONFIG_TPL_PINCTRL is not set > > If we have to disable these 2 options for Samus, I wonder why we imply > these 2 options in arch/Kconfig for x86? It's the only x86 board that uses TPL. I think it might be the only one that uses SPL. Typically it is OK to enable them, but it just adds code size. > > And how about other x86 boards? Do they need unset these 2 options, > eg: QEMU x86_64? That does use SPL but it doesn't seem to matter. > > > CONFIG_SYS_NS16550=y > > CONFIG_SOUND=y > > CONFIG_SOUND_I8254=y > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 071/101] spi: ich: Correct max-size bug in ich_spi_adjust_size()
Hi Bin,
On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> >
> > This incorrectly shortens read operations if there is a maximum write size
> > but no maximum read size. Fix it.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v5: None
> > Changes in v4: None
> > Changes in v3: None
> > Changes in v2: None
> >
> > drivers/spi/ich.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
> > index 08c37ca4ab..17b7a0ba0b 100644
> > --- a/drivers/spi/ich.c
> > +++ b/drivers/spi/ich.c
> > @@ -425,9 +425,11 @@ static int ich_spi_adjust_size(struct spi_slave
> > *slave, struct spi_mem_op *op)
> > page_offset = do_div(aux, ICH_BOUNDARY);
> > }
> >
> > - if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size) {
> > - op->data.nbytes = min(ICH_BOUNDARY - page_offset,
> > - slave->max_read_size);
> > + if (op->data.dir == SPI_MEM_DATA_IN) {
> > + if (slave->max_read_size) {
> > + op->data.nbytes = min(ICH_BOUNDARY - page_offset,
> > + slave->max_read_size);
> > + }
>
> I wrote the following comments in v3, but looks did not get clarified?
>
> I still don't get this. Based on your description, it seems that your
> logic works if we remove the } before the else if.
>
> > } else if (slave->max_write_size) {
> > op->data.nbytes = min(ICH_BOUNDARY - page_offset,
> > slave->max_write_size);
> > --
You can try out a dry run...
Say:
max_read_size = 0
max_write_size = 64
Say we are doing a read...
> if (op->data.dir == SPI_MEM_DATA_IN && slave->max_read_size) {
This branch will not be taken. data.dir is ...IN but because the
max_read_size is 0, we skip this bit.
> op->data.nbytes = min(ICH_BOUNDARY - page_offset,
> slave->max_read_size);
>} else if (slave->max_write_size) {
This branch is taken. Even though we are not doing a write, we set nbytes to 64:
> op->data.nbytes = min(ICH_BOUNDARY - page_offset,
> slave->max_write_size);
> }
So now we are doing a read but using the max_write_size. This is incorrect.
So we need to separate these two things, since otherwise reads get
limited when they should not be.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 073/101] spi: ich: Support hardware sequencing
Hi Bin,
On Wed, 27 Nov 2019 at 00:16, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Nov 25, 2019 at 12:12 PM Simon Glass wrote:
> >
> > Apollo Lake (APL) only supports hardware sequencing. Add support for this
> > into the SPI driver, as an option.
> >
> > Signed-off-by: Simon Glass
> >
> > ---
> >
> > Changes in v5: None
> > Changes in v4:
> > - Fix comment for exec_sync_hwseq_xfer()
> > - apollolake -> Apollo Lake
> >
> > Changes in v3: None
> > Changes in v2: None
> >
> > drivers/spi/ich.c | 205 +-
> > drivers/spi/ich.h | 39 +
> > 2 files changed, 241 insertions(+), 3 deletions(-)
> >
>
> [snip]
>
> > +static int ich_spi_exec_op(struct spi_slave *slave, const struct
> > spi_mem_op *op)
> > +{
> > + struct udevice *bus = dev_get_parent(slave->dev);
> > + struct ich_spi_platdata *plat = dev_get_platdata(bus);
> > + int ret;
> > +
> > + bootstage_start(BOOTSTAGE_ID_ACCUM_SPI, "fast_spi");
> > + if (plat->hwseq)
> > + ret = ich_spi_exec_op_hwseq(slave, op);
> > + else
> > + ret = ich_spi_exec_op_swseq(slave, op);
> > + bootstage_accum(BOOTSTAGE_ID_ACCUM_SPI);
> > +
> > + return ret;
> > +}
> > +
> > static int ich_spi_adjust_size(struct spi_slave *slave, struct spi_mem_op
> > *op)
> > {
> > unsigned int page_offset;
> > @@ -583,9 +778,11 @@ static int ich_spi_child_pre_probe(struct udevice *dev)
> >
> > /*
> > * Yes this controller can only write a small number of bytes at
> > -* once! The limit is typically 64 bytes.
> > +* once! The limit is typically 64 bytes. For hardware sequencing a
> > +* a loop is used to get around this.
> > */
> > - slave->max_write_size = priv->databytes;
> > + if (!plat->hwseq)
> > + slave->max_write_size = priv->databytes;
> > /*
> > * ICH 7 SPI controller only supports array read command
> > * and byte program command for SST flash
> > @@ -611,10 +808,12 @@ static int ich_spi_ofdata_to_platdata(struct udevice
> > *dev)
> > plat->ich_version = dev_get_driver_data(dev);
> > plat->lockdown = dev_read_bool(dev, "intel,spi-lock-down");
> > pch_get_spi_base(priv->pch, >mmio_base);
> > + plat->hwseq = dev_read_u32_default(dev, "intel,hardware-seq", 0);
>
> I believe dev_read_bool() is enough for now, unless we have different
> types of hardware sequencer to support?
Yes I remember this...unfortunately dtoc does not generate a struct
member for a bool if it is not present (since it has no way of knowing
it *might* be there.
So to keep of-platdata happy I made this a 0/1 value.
We probably need a better solution but I don't have one right now.
>
> > #else
> > plat->ich_version = ICHV_APL;
> > plat->mmio_base = plat->dtplat.early_regs[0];
> > plat->bdf = pci_ofplat_get_devfn(plat->dtplat.reg[0]);
> > + plat->hwseq = plat->dtplat.intel_hardware_seq;
> > #endif
> > debug("%s: mmio_base=%lx\n", __func__, plat->mmio_base);
> >
>
> [snip]
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 045/101] x86: fsp: Add FSP2 base support
HI Bin, On Tue, 26 Nov 2019 at 23:11, Bin Meng wrote: > > Hi Simon, > > On Wed, Nov 27, 2019 at 1:08 AM Simon Glass wrote: > > > > Hi Bin, > > > > On Tue, 26 Nov 2019 at 01:36, Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Mon, Nov 25, 2019 at 12:11 PM Simon Glass wrote: > > > > > > > > Add support for some important configuration options and FSP memory > > > > init. > > > > The memory init uses swizzle tables from the device tree. > > > > > > > > Support for the FSP_S binary is also included. > > > > > > > > Bootstage timing is used for both FSP_M and FSP_S and memory-mapped SPI > > > > reads. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > Changes in v5: > > > > - Drop SAFETY_MARGIN > > > > > > > > Changes in v4: > > > > - Add a LOG_CATEGORY for silicon init > > > > - Drop duplicate VBT file CONFIG > > > > - Enable HAVE_VBT for FSP2 also > > > > - Explain the 'twisty headers' comment > > > > - Fix FSP_M reference to refer to FSP_S in commit message > > > > - Fix comment on fsp_silicon_init() > > > > - Rename arch_fsp_s_preinit() to arch_fsps_preinit() > > > > - Rename get_coreboot_fsp() and add comments > > > > - Switch over to use pinctrl for pad init/config > > > > - Use lower-case pinctrl in arch_cpu_init_dm() > > > > > > > > Changes in v3: > > > > - Add a proper implementation of fsp_notify > > > > - Add an fsp: tag > > > > - Add bootstage timing for memory-mapped reads > > > > - Add fsp_locate_fsp to locate an fsp component > > > > - Add fspm_done() hook > > > > - Add support for FSP-S component and VBT > > > > - Simplify types for fsp_locate_fsp() > > > > - Switch mmap to use SPI instead of SPI flash > > > > > > > > Changes in v2: None > > > > > > > > arch/x86/Kconfig | 54 ++- > > > > arch/x86/include/asm/fsp2/fsp_api.h | 63 > > > > arch/x86/include/asm/fsp2/fsp_internal.h | 97 + > > > > arch/x86/lib/fsp2/Makefile | 10 ++ > > > > arch/x86/lib/fsp2/fsp_common.c | 13 ++ > > > > arch/x86/lib/fsp2/fsp_dram.c | 77 ++ > > > > arch/x86/lib/fsp2/fsp_init.c | 174 +++ > > > > arch/x86/lib/fsp2/fsp_meminit.c | 97 + > > > > arch/x86/lib/fsp2/fsp_silicon_init.c | 54 +++ > > > > arch/x86/lib/fsp2/fsp_support.c | 131 + > > > > include/bootstage.h | 3 + > > > > 11 files changed, 770 insertions(+), 3 deletions(-) > > > > create mode 100644 arch/x86/include/asm/fsp2/fsp_api.h > > > > create mode 100644 arch/x86/include/asm/fsp2/fsp_internal.h > > > > create mode 100644 arch/x86/lib/fsp2/Makefile > > > > create mode 100644 arch/x86/lib/fsp2/fsp_common.c > > > > create mode 100644 arch/x86/lib/fsp2/fsp_dram.c > > > > create mode 100644 arch/x86/lib/fsp2/fsp_init.c > > > > create mode 100644 arch/x86/lib/fsp2/fsp_meminit.c > > > > create mode 100644 arch/x86/lib/fsp2/fsp_silicon_init.c > > > > create mode 100644 arch/x86/lib/fsp2/fsp_support.c > > > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > > index 17a6fe6d3d..6bac5d5fe8 100644 > > > > --- a/arch/x86/Kconfig > > > > +++ b/arch/x86/Kconfig > > > > @@ -326,7 +326,7 @@ config X86_RAMTEST > > > > > > > > config FLASH_DESCRIPTOR_FILE > > > > string "Flash descriptor binary filename" > > > > - depends on HAVE_INTEL_ME > > > > + depends on HAVE_INTEL_ME || FSP_VERSION2 > > > > default "descriptor.bin" > > > > help > > > > The filename of the file to use as flash descriptor in the > > > > @@ -411,6 +411,54 @@ config FSP_ADDR > > > > The default base address of 0xfffc indicates that the > > > > binary must > > > > be located at offset 0xc from the beginning of a 1MB > > > > flash device. > > > > > > > > +if FSP_VERSION2 > > > > + > > > > +config FSP_FILE_T > > > > + string "Firmware-Support-Package binary filename (Temp RAM)" > > > > + default "fsp_t.bin" > > > > + help > > > > + The filename of the file to use for the temporary-RAM init > > > > phase from > > > > + the Firmware-Support-Package binary. Put this in the board > > > > directory. > > > > > > nits: Firmware Support Package (drop -) > > > > OK...the hyphens are actually correct I think, but perhaps make it > > hard to search for. > > > > [..] > > > > > > config VIDEO_FSP > > > > bool "Enable FSP framebuffer driver support" > > > > - depends on HAVE_VBT && DM_VIDEO > > > > + depends on (HAVE_VBT || FSP_VERSION2) && DM_VIDEO > > > > > > I think the original logic already satisfies the dependency > > > requirement, that we don't need explicitly list FSP_VERSION2 here. > > > > Yes, now that I don't need to add a new Kconfig I can drop this. > > > > [..] > > > > > > diff --git a/arch/x86/lib/fsp2/fsp_init.c b/arch/x86/lib/fsp2/fsp_init.c > > > > new file mode 100644 > > > > index
[U-Boot] Please pull mmc-11-27-2019
Hi Tom, Please pull mmc-11-27-2019 CI: https://travis-ci.org/MrVan/u-boot/builds/617615361 -- fsl_esdhc update and some cleanup in ls1021a/mpc83xx code mmc tmio sdhi update for hs400 -- Thanks, Peng. The following changes since commit 4b19b89ca4a866b7baa642533e6dbd67cd832d27: Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot (2019-11-25 12:56:27 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git tags/mmc-11-27-2019 for you to fetch changes up to 56b0bb96befdaf0a63b0d17914c5e4402360b6b3: mmc: tmio: sdhi: Add calibration tables (2019-11-27 16:56:46 +0800) Baruch Siach (1): mmc: sdhci: make sdhci_get_cd static Marek Vasut (9): mmc: tmio: sdhi: Track current tap number in private data mmc: tmio: sdhi: Track SMPCMP valu in private data mmc: tmio: sdhi: Use 4 tuning taps on M3W up to ES1.2 mmc: tmio: sdhi: Adjust DT2FF settings for HS400 mode mmc: tmio: sdhi: Adjust HS400 calibration offsets mmc: tmio: sdhi: Disable auto-retuning in HS400 mmc: tmio: sdhi: Add SCC error checking mmc: tmio: sdhi: Skip bad taps mmc: tmio: sdhi: Add calibration tables Yangbo Lu (4): mmc: fsl_esdhc: get clock directly from global data arm: ls1021a: drop redundant board_mmc_init() arm: drop eSDHC clock getting in mxc_get_clock() for layerscape mpc83xx: remove unused clock.h arch/arm/cpu/armv7/ls102xa/clock.c | 2 - arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 15 -- arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch3_speed.c | 15 -- arch/arm/include/asm/arch-fsl-layerscape/clock.h| 2 - arch/arm/include/asm/arch-ls102xa/clock.h | 1 - arch/powerpc/include/asm/arch-mpc83xx/clock.h | 22 - board/freescale/ls1021aiot/ls1021aiot.c | 15 -- board/freescale/ls1021aqds/ls1021aqds.c | 14 -- board/freescale/ls1021atwr/ls1021atwr.c | 14 -- drivers/mmc/fsl_esdhc.c | 34 ++ drivers/mmc/renesas-sdhi.c | 305 drivers/mmc/sdhci.c | 2 +- drivers/mmc/tmio-common.h | 4 ++ 13 files changed, 265 insertions(+), 180 deletions(-) delete mode 100644 arch/powerpc/include/asm/arch-mpc83xx/clock.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: Allow cache drivers to be used in SPL
On Thu, Nov 28, 2019 at 4:33 AM Simon Goldschmidt wrote: > > Ley, Tom, > > Am 26.11.2019 um 10:26 schrieb Ley Foon Tan: > > On Fri, Nov 8, 2019 at 10:53 AM Ley Foon Tan wrote: > >> > >> Add an option for building cache drivers in SPL. > > Ley: > > What's the actual problem here? Can you further describe your change? > Why do you need to change drivers/cache/Makefile? That seems to only > make sense if you enable the new SPL_CACHE without (non-SPL) CACHE. > > However, the series this was pulled out from adds a new cache driver and > makes it select CACHE, not SPL_CACHE, so how would this be activated anyway? > > Maybe it would be better to always dive down into drivers/cache/ if > CACHE is y? Hi Simon The existing drivers/cache is only build when compile for Uboot proper, but not SPL build. So, this patch mainly is to allow drivers/cache to compile in SPL build. User can enable CONFIG_SPL_CACHE if they need to include drivers/cache in SPL, eg: Agilex platform. Regards Ley Foon > > Tom: > > As drivers/cache is rather new and initiated via the socfpga tree, would > you be OK for us to take this via the socfpga/next tree once it's sorted > out? > > Regards, > Simon > > >> > >> Signed-off-by: Ley Foon Tan > >> --- > >> common/spl/Kconfig | 5 + > >> drivers/Makefile | 1 + > >> drivers/cache/Makefile | 2 +- > >> 3 files changed, 7 insertions(+), 1 deletion(-) > >> > >> diff --git a/common/spl/Kconfig b/common/spl/Kconfig > >> index c661809923..6e095c33e1 100644 > >> --- a/common/spl/Kconfig > >> +++ b/common/spl/Kconfig > >> @@ -714,6 +714,11 @@ config SPL_UBI > >>README.ubispl for more info. > >> > >> if SPL_DM > >> +config SPL_CACHE > >> + bool "Support cache drivers in SPL" > >> + help > >> + Enable support for cache drivers in SPL. > >> + > >> config SPL_DM_SPI > >> bool "Support SPI DM drivers in SPL" > >> help > >> diff --git a/drivers/Makefile b/drivers/Makefile > >> index 0befeddfcb..0e42d006b9 100644 > >> --- a/drivers/Makefile > >> +++ b/drivers/Makefile > >> @@ -31,6 +31,7 @@ ifndef CONFIG_TPL_BUILD > >> ifdef CONFIG_SPL_BUILD > >> > >> obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/ > >> +obj-$(CONFIG_SPL_CACHE) += cache/ > >> obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/ > >> obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/ > >> obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/ > >> diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile > >> index 4a6458c602..c1f766cfca 100644 > >> --- a/drivers/cache/Makefile > >> +++ b/drivers/cache/Makefile > >> @@ -1,5 +1,5 @@ > >> > >> -obj-$(CONFIG_CACHE) += cache-uclass.o > >> +obj-$(CONFIG_$(SPL_)CACHE) += cache-uclass.o > >> obj-$(CONFIG_SANDBOX) += sandbox_cache.o > >> obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o > >> obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o > >> -- > >> 2.19.0 > > Hi Tom > > > > Any comment on this patch? > > > > Regards > > > > Ley Foon > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] rockchip: px30: enable spl-fifo-mode for both emmc and sdmmc on evb
On Tue, Nov 19, 2019 at 12:04:02PM +0100, Heiko Stuebner wrote: > From: Heiko Stuebner > > As part of loading trustedfirmware, the SPL is required to place portions > of code into the socs sram but the mmc controllers can only do dma > transfers into the regular memory, not sram. > > The results of this are not directly visible in u-boot itself, but > manifest as security-relate cpu aborts during boot of for example Linux. > > There were a number of attempts to solve this elegantly but so far > discussion is still ongoing, so to make the board at least boot correctly > put both mmc controllers into fifo-mode, which also circumvents the > issue for now. > > Signed-off-by: Heiko Stuebner Hi, is this also needed on RK3399 based machines? I have a NanoPC-T4, where the eMMC is on the Arasan controller and the SD card on the dwmmc. So if I boot from SD card I need this as well? Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: Allow cache drivers to be used in SPL
On Wed, Nov 27, 2019 at 09:33:19PM +0100, Simon Goldschmidt wrote: > Ley, Tom, > > Am 26.11.2019 um 10:26 schrieb Ley Foon Tan: > > On Fri, Nov 8, 2019 at 10:53 AM Ley Foon Tan wrote: > > > > > > Add an option for building cache drivers in SPL. > > Ley: > > What's the actual problem here? Can you further describe your change? Why do > you need to change drivers/cache/Makefile? That seems to only make sense if > you enable the new SPL_CACHE without (non-SPL) CACHE. > > However, the series this was pulled out from adds a new cache driver and > makes it select CACHE, not SPL_CACHE, so how would this be activated anyway? > > Maybe it would be better to always dive down into drivers/cache/ if CACHE is > y? > > Tom: > > As drivers/cache is rather new and initiated via the socfpga tree, would you > be OK for us to take this via the socfpga/next tree once it's sorted out? Sounds good, 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] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
Am 2019-11-27 16:19, schrieb Alex Marginean:
Hardware comes out of reset with implicit values, but these are outside
the accepted range for Layerscape gen 3 chassis spec used on LS1028A.
Allocate different IDs and fix up Linux DT to use them.
Signed-off-by: Alex Marginean
Reviewed-by: Bin Meng
finally networking in linux, yay ;)
Tested-by: Michael Walle
---
Changes in v2:
- moved code under arm/cpu from board as it's in fact SoC related
Replaces v1 and this earlier patch:
https://patchwork.ozlabs.org/patch/1144486/
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 9 ++
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++
.../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 93 +++
.../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++
4 files changed, 119 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 83a3319321..c6490556e6 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1098,6 +1098,12 @@ static void config_core_prefetch(void)
}
}
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void set_ecam_icids(void)
+{
+}
+#endif
+
int arch_early_init_r(void)
{
#ifdef CONFIG_SYS_FSL_ERRATUM_A009635
@@ -1149,6 +1155,9 @@ int arch_early_init_r(void)
#endif
#ifdef CONFIG_SYS_DPAA_QBMAN
setup_qbman_portals();
+#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ set_ecam_icids();
#endif
return 0;
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index e993209593..1e7e46e88a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -421,6 +421,12 @@ static void fdt_disable_multimedia(void *blob,
unsigned int svr)
}
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void fdt_fixup_ecam(void *blob)
+{
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -485,4 +491,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_ARCH_LS1028A
fdt_disable_multimedia(blob, svr);
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ fdt_fixup_ecam(blob);
+#endif
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index 9462298fbf..8110412da6 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -33,3 +33,96 @@ struct icid_id_table icid_tbl[] = {
};
int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
+
+/* integrated PCI is handled separately as it's not part of CCSR/SCFG
*/
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+#define ECAM_IERB_BASE 0x1f080ULL
+#define ECAM_IERB_OFFSET_NA-1
+#define ECAM_IERB_FUNC_CNT ARRAY_SIZE(ierb_offset)
+/* cache related transaction attributes for PCIe functions */
+#define ECAM_IERB_MSICAR (ECAM_IERB_BASE + 0xa400)
+#define ECAM_IERB_MSICAR_VALUE 0x30
+
+/* offset of IERB config register per PCI function */
+static int ierb_offset[] = {
+ 0x0800,
+ 0x1800,
+ 0x2800,
+ 0x3800,
+ 0x4800,
+ 0x5800,
+ 0x6800,
+ ECAM_IERB_OFFSET_NA,
+ 0x0804,
+ 0x0808,
+ 0x1804,
+ 0x1808,
+};
+
+/*
+ * Use a custom function for LS1028A, for now this is the only SoC
with IERB
+ * and we're currently considering reorganizing IERB for future SoCs.
+ */
+void set_ecam_icids(void)
+{
+ int i;
+
+ out_le32(ECAM_IERB_MSICAR, ECAM_IERB_MSICAR_VALUE);
+
+ for (i = 0; i < ECAM_IERB_FUNC_CNT; i++) {
+ if (ierb_offset[i] == ECAM_IERB_OFFSET_NA)
+ continue;
+
+ out_le32(ECAM_IERB_BASE + ierb_offset[i],
+FSL_ECAM_STREAM_ID_START + i);
+ }
+}
+
+static int fdt_setprop_inplace_idx_u32(void *fdt, int nodeoffset,
+ const char *name, uint32_t idx, u32 val)
+{
+ val = cpu_to_be32(val);
+ return fdt_setprop_inplace_namelen_partial(fdt, nodeoffset, name,
+ strlen(name),
+ idx * sizeof(val), ,
+ sizeof(val));
+}
+
+static int fdt_getprop_len(void *fdt, int nodeoffset, const char
*name)
+{
+ int len;
+
+ if (fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), ))
+ return len;
+
+ return 0;
+}
+
+void fdt_fixup_ecam(void *blob)
+{
+ int off;
+
+ off = fdt_node_offset_by_compatible(blob, 0,
"pci-host-ecam-generic");
+ if (off < 0) {
+ debug("ECAM node not found\n");
+ return;
+ }
+
+ if (fdt_getprop_len(blob, off, "msi-map") != 16 ||
+ fdt_getprop_len(blob, off, "iommu-map") != 16) {
+ log_err("invalid msi/iommu-map propertly size in ECAM node\n");
+ return;
+ }
+
+
Re: [U-Boot] [PATCH] spl: Allow cache drivers to be used in SPL
Ley, Tom, Am 26.11.2019 um 10:26 schrieb Ley Foon Tan: On Fri, Nov 8, 2019 at 10:53 AM Ley Foon Tan wrote: Add an option for building cache drivers in SPL. Ley: What's the actual problem here? Can you further describe your change? Why do you need to change drivers/cache/Makefile? That seems to only make sense if you enable the new SPL_CACHE without (non-SPL) CACHE. However, the series this was pulled out from adds a new cache driver and makes it select CACHE, not SPL_CACHE, so how would this be activated anyway? Maybe it would be better to always dive down into drivers/cache/ if CACHE is y? Tom: As drivers/cache is rather new and initiated via the socfpga tree, would you be OK for us to take this via the socfpga/next tree once it's sorted out? Regards, Simon Signed-off-by: Ley Foon Tan --- common/spl/Kconfig | 5 + drivers/Makefile | 1 + drivers/cache/Makefile | 2 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index c661809923..6e095c33e1 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -714,6 +714,11 @@ config SPL_UBI README.ubispl for more info. if SPL_DM +config SPL_CACHE + bool "Support cache drivers in SPL" + help + Enable support for cache drivers in SPL. + config SPL_DM_SPI bool "Support SPI DM drivers in SPL" help diff --git a/drivers/Makefile b/drivers/Makefile index 0befeddfcb..0e42d006b9 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -31,6 +31,7 @@ ifndef CONFIG_TPL_BUILD ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/ +obj-$(CONFIG_SPL_CACHE) += cache/ obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/ obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/ obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/ diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile index 4a6458c602..c1f766cfca 100644 --- a/drivers/cache/Makefile +++ b/drivers/cache/Makefile @@ -1,5 +1,5 @@ -obj-$(CONFIG_CACHE) += cache-uclass.o +obj-$(CONFIG_$(SPL_)CACHE) += cache-uclass.o obj-$(CONFIG_SANDBOX) += sandbox_cache.o obj-$(CONFIG_L2X0_CACHE) += cache-l2x0.o obj-$(CONFIG_V5L2_CACHE) += cache-v5l2.o -- 2.19.0 Hi Tom Any comment on this patch? Regards Ley Foon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] armv8: fsl-layerscape: LS1044A/1048A: enable Only 1x 10GE port
Hi Pramod,
On 11/25/2019 11:42 AM, Pramod Kumar wrote:
LS1044A, LS1048A are LS1088A personalities, which support only one
1x 10GE port.
There's probably a mix-up, and unfortunately we have an issue in the
LS1088A reference manual available on the website too.
- LS1088A is documented as 2x 10G, no issue there.
- LS1044A is documented as 1x 10G, no AIOP, no issue there.
- LS1048A I thought is a LS1088A with 4 cores but same DPAA, is it not?
That's what the numbering scheme should mean at least.
Appending B of the RM has a nice picture of LS1048A which shows 4 cores
(as expected), 2x 10G ports, AIOP, so the same DPAA as LS1088A.
But the table below mentions '1x 10GE and 8x 1GE'. One of the two has
to be wrong. I place my bet on a copy paste error and on LS1048A having
2x 10G ports.
- LS1084A, which you did not mention, based on the numbering scheme
should be a 8 core device with the same DPAA as LS1044A, so 1x 10G.
Appendix C has a picture that shows a LS1084A device with no AIOP, but
2x 10G ports. The table below mentions no AIOP but '2x 10GE and 8x
1GE'. I would guess that if LS1044A has just one 10G port then LS1084A
has just one too.
Can you please double-check and confirm? It would be nice to open a
ticket for documentation too, there are definitely some inconsistencies
there.
And also make sure the patch works for all 4 personalities.
Alex
MAC1 and MAC2 are associated with 1G SGMII, 2.5G SGMII, and XFI.
Disable MAC1 to have only one 1x 10GE port for LS1044A, LS1048A.
Signed-off-by: Pramod Kumar
---
Changes for v2:
- incorporated review comment's
arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c | 27 --
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
index 8e8b45a..7b465e1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1088a_serdes.c
@@ -1,10 +1,12 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017 NXP
+ * Copyright 2017-2019 NXP
*/
#include
#include
+#include
+#include
struct serdes_config {
u8 ip_protocol;
@@ -32,6 +34,7 @@ static struct serdes_config serdes1_cfg_tbl[] = {
{0x3A, {SGMII3, PCIE1, SGMII1, SGMII2 }, {3, 5, 3, 3 } },
{}
};
+ > static struct serdes_config serdes2_cfg_tbl[] = {
/* SerDes 2 */
{0x0C, {PCIE1, PCIE1, PCIE1, PCIE1 }, {8, 8, 8, 8 } },
@@ -48,6 +51,19 @@ static struct serdes_config *serdes_cfg_tbl[] = {
serdes2_cfg_tbl,
};
+bool soc_has_mac1(void)
+{
+ struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
+ unsigned int svr, ver;
+
+ svr = gur_in32(>svr);
+ ver = SVR_SOC_VER(svr);
+ if (ver == SVR_LS1088A)
+ return true;
+ else
+ return false;
+}
+
int serdes_get_number(int serdes, int cfg)
{
struct serdes_config *ptr;
@@ -87,7 +103,14 @@ enum srds_prtcl serdes_get_prtcl(int serdes, int cfg, int
lane)
if (serdes >= ARRAY_SIZE(serdes_cfg_tbl))
return 0;
-
+ /*
+* LS1044A/1048A support only one XFI port
+* Disable MAC1 for LS1044A/1048A
+*/
+ if (!serdes && lane == 2) {
+ if (!soc_has_mac1())
+ return 0;
+ }
ptr = serdes_cfg_tbl[serdes];
while (ptr->ip_protocol) {
if (ptr->ip_protocol == cfg)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Using sspi for hardware detection?
On Wed, Nov 27, 2019 at 1:58 PM Romain Naour wrote: > > Hello, > > I'm working on a modular socfpga based system with several optional boards. > Each optional board contain a board ID that can be read through a SPI bus. > > Since we want just read the board ID, we used manually the sspi command, > something like: > > => sspi 1:1.0 8 0 > 42 > > But it seems that the sspi command can't be used in a uboot script. sspi seems > only used to manually test spi drivers. > > > If we compare with i2c command, we have a i2c read to memory: > > i2c read chip address[.0, .1, .2] length memaddress - read to memory > > Why there is no such feature for spi ? Probably because noone has needed it so far. > Is there an interest to evolve the sspi command to add a read to memory? > > sspi : . If you need it and provide a decent patch, I could probable get accepted... > > By looking at existing code, it seems that hardware detection in uboot is > handled by architecture/board specific code to set custom environment variable > like "fpgatype" [1] or "unit_ident" "unit_serial" [2] (misc_init_r). > > What do you recommend? > Implement a custom misc_init_r() for hardware detection? How is that related? How does reading to memory help you with knowing the hw type in scripts? Anyway, I think board_late_init is a better fit than misc_init_r, which is rather meant to be a platform thing and vining can only use it because socfpga doesn't need it otherwise. Regards, Simon > > [1] > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/misc_gen5.c#L139 > [2] > https://gitlab.denx.de/u-boot/u-boot/blob/master/board/softing/vining_fpga/socfpga.c#L48 > > Best regards, > Romain > ___ > 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 0/2] Add support for booting EFI FIT images
On Tue, Nov 26, 2019 at 07:31:39PM +0100, Heinrich Schuchardt wrote:
> On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:
> > Currently the only way to run an EFI binary like GRUB2 is via the
> > 'bootefi' command, which cannot be used in a verified boot scenario.
> >
> > The obvious solution to this limitation is to add support for
> > booting FIT images containing those EFI binaries.
> >
> > The implementation relies on a new image type - IH_OS_EFI - which
> > can be created by using 'os = "efi"' inside an ITS file:
> >
> > / {
> > #address-cells = <1>;
> >
> > images {
> > efi-grub {
> > description = "GRUB EFI";
> > data = /incbin/("EFI/BOOT/bootarm.efi");
> > type = "kernel_noload";
> > arch = "arm";
> > os = "efi";
> > compression = "none";
> > load = <0x0>;
> > entry = <0x0>;
> > hash-1 {
> > algo = "sha256";
> > };
> > };
> > };
> >
> > configurations {
> > default = "config-grub";
> > config-grub {
> > kernel = "efi-grub";
> > signature-1 {
> > algo = "sha256,rsa2048";
> > sign-images = "kernel";
> > };
> > };
> > };
> > };
> >
> > The bootm command has been extended to handle the IH_OS_EFI images.
> > To enable this feature, a new configuration option has been added:
> > BOOTM_EFI
> >
> > I tested the solution using the 'qemu_arm' board:
> >
> > => load scsi 0:1 ${kernel_addr_r} efi-image.fit
> > => bootm ${kernel_addr_r}#config-grub
>
> Thanks a lot for the patch series which makes good sense to me.
>
> I think we should pass addresses and not strings to cmd/bootefi.c. This
> will need a bit of refactoring as already addressed in a comment to
> patch 2/2.
>
> Additionally the documentation in doc/uefi/u-boot_on_efi.rst and
> doc/uImage.FIT/howto.txt should be updated.
>
> I cc the contributors given by
> scripts/get_maintainer.pl -f common/bootm_os.c
>
> Best regards
>
> Heinrich
>
Thanks for the feedback, Heinrich!
Instead of creating new function(s), I think we could simply extend
int do_bootefi_image(const char *image_opt)
with a new parameter to hold the fdt address and move here the call
to 'efi_install_fdt()', which is now performed by 'do_bootefi()'.
However, I'm not sure about changing the data types, i.e. from
'char *' to ulong, for the following reasons:
1. image_opt may have a different meaning in addition to efi address
2. fdt address may not be provided, so we need somehow to detect an
invalid value
Kind regards,
Cristian
> >
> >
> > Cristian Ciocaltea (2):
> >image: Add IH_OS_EFI for EFI chain-load boot
> >bootm: Add a bootm command for type IH_OS_EFI
> >
> > cmd/Kconfig| 9 -
> > cmd/bootefi.c | 2 +-
> > common/bootm_os.c | 44
> > common/image-fit.c | 3 ++-
> > common/image.c | 1 +
> > include/bootm.h| 2 ++
> > include/image.h| 1 +
> > 7 files changed, 59 insertions(+), 3 deletions(-)
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] warp7: Fix U-Boot corruption after saving the environment
On 26/11/19 23:38, Fabio Estevam wrote: > Hi Stefano, > > On Mon, Oct 21, 2019 at 11:23 AM Fabio Estevam wrote: >> >> U-Boot binary has grown in such a way that it goes beyond the reserved >> area for the environment variables. >> >> Running "saveenv" followed by a "reset" causes U-Boot to hang because >> of this overlap. >> >> Fix this problem by increasing the CONFIG_ENV_OFFSET size. >> >> Also, in order to prevent this same problem in the future, use >> CONFIG_BOARD_SIZE_LIMIT, which will detect the overlap in build-time. >> >> CONFIG_BOARD_SIZE_LIMIT does not accept math expressions, so declare >> CONFIG_ENV_OFFSET with its direct value instead. >> >> Signed-off-by: Fabio Estevam > > Can we get this one for 2020.01? > I'll pick up it. Stefano > Thanks > -- = 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 v8 18/19] configs: socfpga: Move Stratix10 and Agilex common CONFIGs
On Wed, Nov 27, 2019 at 8:56 AM Ley Foon Tan wrote:
>
> Move Stratix10 and Agilex common CONFIGs to socfpga_soc64_common.h.
>
> Signed-off-by: Ley Foon Tan
Reviewed-by: Simon Goldschmidt
> ---
> ...ratix10_socdk.h => socfpga_soc64_common.h} | 8 +-
> include/configs/socfpga_stratix10_socdk.h | 193 +-
> 2 files changed, 7 insertions(+), 194 deletions(-)
> copy include/configs/{socfpga_stratix10_socdk.h => socfpga_soc64_common.h}
> (96%)
>
> diff --git a/include/configs/socfpga_stratix10_socdk.h
> b/include/configs/socfpga_soc64_common.h
> similarity index 96%
> copy from include/configs/socfpga_stratix10_socdk.h
> copy to include/configs/socfpga_soc64_common.h
> index e8e66fa4ae..f69a55c191 100644
> --- a/include/configs/socfpga_stratix10_socdk.h
> +++ b/include/configs/socfpga_soc64_common.h
> @@ -1,11 +1,11 @@
> /* SPDX-License-Identifier: GPL-2.0
> *
> - * Copyright (C) 2017-2018 Intel Corporation
> + * Copyright (C) 2017-2019 Intel Corporation
> *
> */
>
> -#ifndef __CONFIG_SOCFGPA_STRATIX10_H__
> -#define __CONFIG_SOCFGPA_STRATIX10_H__
> +#ifndef __CONFIG_SOCFPGA_SOC64_COMMON_H__
> +#define __CONFIG_SOCFPGA_SOC64_COMMON_H__
>
> #include
> #include
> @@ -196,4 +196,4 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
> #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
> #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
>
> -#endif /* __CONFIG_H */
> +#endif /* __CONFIG_SOCFPGA_SOC64_COMMON_H__ */
> diff --git a/include/configs/socfpga_stratix10_socdk.h
> b/include/configs/socfpga_stratix10_socdk.h
> index e8e66fa4ae..09b46ba013 100644
> --- a/include/configs/socfpga_stratix10_socdk.h
> +++ b/include/configs/socfpga_stratix10_socdk.h
> @@ -1,199 +1,12 @@
> /* SPDX-License-Identifier: GPL-2.0
> *
> - * Copyright (C) 2017-2018 Intel Corporation
> + * Copyright (C) 2017-2019 Intel Corporation
> *
> */
>
> #ifndef __CONFIG_SOCFGPA_STRATIX10_H__
> #define __CONFIG_SOCFGPA_STRATIX10_H__
>
> -#include
> -#include
> +#include
>
> -/*
> - * U-Boot general configurations
> - */
> -#define CONFIG_SYS_MONITOR_BASECONFIG_SYS_TEXT_BASE
> -#define CONFIG_LOADADDR0x200
> -#define CONFIG_SYS_LOAD_ADDR CONFIG_LOADADDR
> -#define CONFIG_REMAKE_ELF
> -/* sysmgr.boot_scratch_cold4 & 5 (64bit) will be used for PSCI_CPU_ON call */
> -#define CPU_RELEASE_ADDR 0xFFD12210
> -#define CONFIG_SYS_CACHELINE_SIZE 64
> -#define CONFIG_SYS_MEM_RESERVE_SECURE 0 /* using OCRAM, not DDR */
> -
> -/*
> - * U-Boot console configurations
> - */
> -#define CONFIG_SYS_MAXARGS 64
> -#define CONFIG_SYS_CBSIZE 2048
> -#define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \
> - sizeof(CONFIG_SYS_PROMPT) + 16)
> -#define CONFIG_SYS_BARGSIZECONFIG_SYS_CBSIZE
> -
> -/* Extend size of kernel image for uncompression */
> -#define CONFIG_SYS_BOOTM_LEN (32 * 1024 * 1024)
> -
> -/*
> - * U-Boot run time memory configurations
> - */
> -#define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0
> -#define CONFIG_SYS_INIT_RAM_SIZE 0x4
> -#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR \
> - + CONFIG_SYS_INIT_RAM_SIZE \
> - - S10_HANDOFF_SIZE)
> -#define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_SP_ADDR)
> -#define CONFIG_SYS_MALLOC_LEN (5 * 1024 * 1024)
> -
> -/*
> - * U-Boot environment configurations
> - */
> -#define CONFIG_SYS_MMC_ENV_DEV 0 /* device 0 */
> -
> -/*
> - * QSPI support
> - */
> - #ifdef CONFIG_CADENCE_QSPI
> -/* Enable it if you want to use dual-stacked mode */
> -/*#define CONFIG_QSPI_RBF_ADDR 0x72*/
> -
> -/* Flash device info */
> -
> -/*#define CONFIG_ENV_IS_IN_SPI_FLASH*/
> -
> -#ifndef CONFIG_SPL_BUILD
> -#define CONFIG_MTD_DEVICE
> -#define CONFIG_MTD_PARTITIONS
> -#define MTDIDS_DEFAULT "nor0=ff705000.spi.0"
> -#endif /* CONFIG_SPL_BUILD */
> -
> -#ifndef __ASSEMBLY__
> -unsigned int cm_get_qspi_controller_clk_hz(void);
> -#define CONFIG_CQSPI_REF_CLK cm_get_qspi_controller_clk_hz()
> -#endif
> -
> -#endif /* CONFIG_CADENCE_QSPI */
> -
> -/*
> - * Boot arguments passed to the boot command. The value of
> - * CONFIG_BOOTARGS goes into the environment value "bootargs".
> - * Do note the value will override also the chosen node in FDT blob.
> - */
> -#define CONFIG_BOOTARGS "earlycon"
> -#define CONFIG_BOOTCOMMAND "run fatscript; run mmcload;run
> linux_qspi_enable;" \
> - "run mmcboot"
> -
> -#define CONFIG_EXTRA_ENV_SETTINGS \
> - "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
> - "bootfile=Image\0" \
> - "fdt_addr=800\0" \
> - "fdtimage=socfpga_stratix10_socdk.dtb\0" \
> - "mmcroot=/dev/mmcblk0p2\0" \
> - "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
>
Re: [U-Boot] [PATCH v2 3/8] cmd: bootimg: Add bootimg command
Hi Sam,
On Wed, Oct 23, 2019 at 05:34:22PM +0300, Sam Protsenko wrote:
> +static int do_bootimg_get_dtb_file(cmd_tbl_t *cmdtp, int flag, int argc,
> +char * const argv[])
> +{
> + char *endp;
> + char buf[65];
> + u32 index;
> + ulong addr;
> + u32 size;
> +
> + if (argc < 3 || argc > 4)
> + return CMD_RET_USAGE;
> +
> + index = simple_strtoul(argv[1], , 0);
> + if (*endp != '\0') {
> + printf("Error: Wrong index\n");
> + return CMD_RET_FAILURE;
> + }
> +
> + if (!android_image_get_dtb_by_index(bootimg_addr(), index, ,
> + ))
As discussed in https://patchwork.ozlabs.org/patch/958594/#2302310, we
try to enhance the "dtimg" U-Boot command to be able to identify DT
blobs by "id" or "rev" [*] field value.
It's quite challenging in this context to avoid conflicting with your
recently proposed "bootimg" command, since the latter makes use of the
android_image_get_dtb_by_index API, which is subject of modification
and/or renaming.
I am willing to cooperate to entirely avoid or reconcile the conflict
in the best possible way, but for that I need your feedback.
[*] https://source.android.google.cn/devices/architecture/dto/partitions
--
Best Regards,
Eugeniu
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Reboot is broken on RockPro64 with mainline u-boot and ATF
On Wed, Nov 27, 2019 at 9:53 AM Jagan Teki wrote: > > Hi, > > On Mon, Nov 25, 2019 at 10:56 PM Vasily Khoruzhick wrote: > > > > Hey guys, > > > > Looks like reboot is broken on RockPro64 (RK3399-based) with mainline > > u-boot and ATF (ATF already has a fix [1]). > > > > When I type 'reboot' in linux I get back to u-boot, but subsequent > > linux boot hangs in most cases. Sometimes I get this warning: > > > > [ 62.400363] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > > [ 62.418095] rcu: 4-...!: (3 ticks this GP) > > idle=332/1/0x4000 softirq=23/24 fqs=13 > > [ 62.444137] Task dump for CPU 4: > > [ 62.453791] kworker/4:1 R running task042 2 > > 0x002a > > [ 62.474907] Workqueue: pm genpd_power_off_work_fn > > [ 62.489013] rcu: rcu_sched kthread starved for 5976 jiffies! g-1147 > > f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 > > [ 62.519205] rcu: RCU grace-period kthread stack dump: > > [ 62.534316] rcu_sched R running task010 2 > > 0x0028 > > > > I already checked that regulators are configured correctly, also I > > tried to disable big CPU cluster in linux and re-initializing CPU > > voltages in u-boot but unfortunately nothing helps. > > > > There were other reports on #linux-rockchip at freenode that reboot is > > broken. > > > > Any ideas how to debug it or what could be wrong? > > I did see it was hang in SPL when I reboot from Linux. But nothing > seen with rkbin. Can you have a quick check with rkbin flow if you > haven't tried yet? (I mean idbloader.img, trust.img and uboot.img) It gets to u-boot console and it hangs in Linux before it even starts init for me. I can check with rkbin and it'll likely work, but it won't help much since we don't have sources for these blobs. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: ddr: Always start DDR RAM in Self Refresh mode
Some of our t1042 boards fails DDR init with an Automatic calibration error
every now and then. Investigations revealed that true Warm boots
newer failed. Warm boots has some extra steps performed, one being
to start DDRC in Self Refresh and then clearing SR right after.
Applying this SR method unconditionally made all our boards
stable again, regardless of Cold/Warm boot.
Signed-off-by: Joakim Tjernlund
---
drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
index a9b085db8c..952b296dd8 100644
--- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
+++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c
@@ -370,6 +370,8 @@ step2:
debug("Setting DEBUG_3[21] to 0x%08x\n", in_be32(>debug[2]));
#endif /* part 1 of the workaound */
+ /* Always start in self-refresh, clear after MEM_EN */
+ setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
/*
* 500 painful micro-seconds must elapse between
@@ -382,8 +384,6 @@ step2:
#ifdef CONFIG_DEEP_SLEEP
if (is_warm_boot()) {
- /* enter self-refresh */
- setbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
/* do board specific memory setup */
board_mem_sleep_setup();
temp_sdram_cfg = (in_be32(>sdram_cfg) | SDRAM_CFG_BI);
@@ -395,6 +395,10 @@ step2:
out_be32(>sdram_cfg, temp_sdram_cfg | SDRAM_CFG_MEM_EN);
asm volatile("sync;isync");
+ /* Exit self-refresh after DDR conf as some ddr memories can fail. */
+ clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
+ asm volatile("sync;isync");
+
total_gb_size_per_controller = 0;
for (i = 0; i < CONFIG_CHIP_SELECTS_PER_CTRL; i++) {
if (!(regs->cs[i].config & 0x8000))
@@ -544,9 +548,4 @@ step2:
clrbits_be32(>sdram_cfg, 0x2);
}
#endif /* CONFIG_SYS_FSL_ERRATUM_DDR111_DDR134 */
-#ifdef CONFIG_DEEP_SLEEP
- if (is_warm_boot())
- /* exit self-refresh */
- clrbits_be32(>sdram_cfg_2, SDRAM_CFG2_FRC_SR);
-#endif
}
--
2.23.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Reboot is broken on RockPro64 with mainline u-boot and ATF
Hi, On Mon, Nov 25, 2019 at 10:56 PM Vasily Khoruzhick wrote: > > Hey guys, > > Looks like reboot is broken on RockPro64 (RK3399-based) with mainline > u-boot and ATF (ATF already has a fix [1]). > > When I type 'reboot' in linux I get back to u-boot, but subsequent > linux boot hangs in most cases. Sometimes I get this warning: > > [ 62.400363] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > [ 62.418095] rcu: 4-...!: (3 ticks this GP) > idle=332/1/0x4000 softirq=23/24 fqs=13 > [ 62.444137] Task dump for CPU 4: > [ 62.453791] kworker/4:1 R running task042 2 > 0x002a > [ 62.474907] Workqueue: pm genpd_power_off_work_fn > [ 62.489013] rcu: rcu_sched kthread starved for 5976 jiffies! g-1147 > f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 > [ 62.519205] rcu: RCU grace-period kthread stack dump: > [ 62.534316] rcu_sched R running task010 2 > 0x0028 > > I already checked that regulators are configured correctly, also I > tried to disable big CPU cluster in linux and re-initializing CPU > voltages in u-boot but unfortunately nothing helps. > > There were other reports on #linux-rockchip at freenode that reboot is broken. > > Any ideas how to debug it or what could be wrong? I did see it was hang in SPL when I reboot from Linux. But nothing seen with rkbin. Can you have a quick check with rkbin flow if you haven't tried yet? (I mean idbloader.img, trust.img and uboot.img) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Reboot is broken on RockPro64 with mainline u-boot and ATF
On Mon, Nov 25, 2019 at 9:25 AM Vasily Khoruzhick wrote: > > Hey guys, > > Looks like reboot is broken on RockPro64 (RK3399-based) with mainline > u-boot and ATF (ATF already has a fix [1]). Added Philipp and Simon to CC. Can anyone please help me with this issue? > When I type 'reboot' in linux I get back to u-boot, but subsequent > linux boot hangs in most cases. Sometimes I get this warning: > > [ 62.400363] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > [ 62.418095] rcu: 4-...!: (3 ticks this GP) > idle=332/1/0x4000 softirq=23/24 fqs=13 > [ 62.444137] Task dump for CPU 4: > [ 62.453791] kworker/4:1 R running task042 2 > 0x002a > [ 62.474907] Workqueue: pm genpd_power_off_work_fn > [ 62.489013] rcu: rcu_sched kthread starved for 5976 jiffies! g-1147 > f0x0 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=1 > [ 62.519205] rcu: RCU grace-period kthread stack dump: > [ 62.534316] rcu_sched R running task010 2 > 0x0028 > > I already checked that regulators are configured correctly, also I > tried to disable big CPU cluster in linux and re-initializing CPU > voltages in u-boot but unfortunately nothing helps. > > There were other reports on #linux-rockchip at freenode that reboot is broken. > > Any ideas how to debug it or what could be wrong? > > Regards, > Vasily > > [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2512 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
On Wed, 27 Nov 2019 18:45:43 +0200 Andy Shevchenko wrote: > On Wed, Nov 27, 2019 at 05:10:22PM +0100, Lukasz Majewski wrote: > > > On Wed, Nov 27, 2019 at 11:57:53AM +0100, Lukasz Majewski wrote: > > > > I base my patches on official releases / release candidates. It > > > applies very well on top of 2020.01-rc3 as of today. Does DFU has > > > a separate repository / branch to track? > > > > > > > I'm using u-boot-usb as a base: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-usb/commits/next > > > > as I'm sending PRs to Marek. > > I see, thanks. I have added it to my remote list. > > Note, I sent v2 based on origin/master, but later I have tested > against usb/next and everything can be applied well. > Ok. Great :-) Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpQCk3jlT3Qj.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
On Wed, Nov 27, 2019 at 05:10:22PM +0100, Lukasz Majewski wrote: > > On Wed, Nov 27, 2019 at 11:57:53AM +0100, Lukasz Majewski wrote: > > I base my patches on official releases / release candidates. It > > applies very well on top of 2020.01-rc3 as of today. Does DFU has a > > separate repository / branch to track? > > > > I'm using u-boot-usb as a base: > > https://gitlab.denx.de/u-boot/custodians/u-boot-usb/commits/next > > as I'm sending PRs to Marek. I see, thanks. I have added it to my remote list. Note, I sent v2 based on origin/master, but later I have tested against usb/next and everything can be applied well. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v1] MAINTAINERS: Add info for bcm283x
From: Matthias Brugger The bcm283x has grown in files, which was not reflected in the MAINTAINERS file. Fix this by adding the missing entries. Signed-off-by: Matthias Brugger --- MAINTAINERS | 3 +++ 1 file changed, 3 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 332fd9d74c..8d588b7d64 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -150,7 +150,9 @@ N: meson ARM BROADCOM BCM283X M: Matthias Brugger S: Maintained +F: arch/arm/dts/bcm283* F: arch/arm/mach-bcm283x/ +F: board/raspberrypi/ F: drivers/gpio/bcm2835_gpio.c F: drivers/mmc/bcm2835_sdhci.c F: drivers/mmc/bcm2835_sdhost.c @@ -158,6 +160,7 @@ F: drivers/serial/serial_bcm283x_mu.c F: drivers/serial/serial_bcm283x_pl011.c F: drivers/video/bcm2835.c F: include/dm/platform_data/serial_bcm283x_mu.h +F: include/dt-bindings/pinctrl/bcm2835.h F: drivers/pinctrl/broadcom/ ARM BROADCOM BCMSTB -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GPT overlap on i.MX6
Hi Jagan, > Hi Lukasz, > > On Wed, Nov 27, 2019 at 4:15 PM Lukasz Majewski wrote: > > > > Hi Jagan, > > > > > Hi, > > > > > > I have created GPT table start from 8MB for kernel, roots etc. > > > something like > > > > > > PartStart LBA End LBA Name > > > Attributes > > > Type GUID > > > Partition GUID > > > 1 0x4000 0x00023fff "boota" > > > attrs: 0x0004 > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > 2 0x00024000 0x00043fff "bootb" > > > attrs: 0x0004 > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > 3 0x00044000 0x00243fff "rootfsa" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > 4 0x00244000 0x00443fff "rootfsb" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > 5 0x00444000 0x0070bfde "data" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > I have not included SPL, U-Boot to the partition list since it > > > start from 0x400 in i.MX6. So > > > I'm writing SPL separately using fastboot(with offset) or ums. > > > > > > But by doing this, the partition header seems overlapped so the > > > output looks > > > > > > GUID Partition Table Entry Array CRC is wrong: 0x6a1aba0a != > > > 0x8e4fd548 find_valid_gpt: *** ERROR: Invalid GPT *** > > > find_valid_gpt: ***Using Backup GPT *** > > > PartStart LBA End LBA Name > > > Attributes > > > Type GUID > > > Partition GUID > > > 1 0x4000 0x00023fff "boota" > > > attrs: 0x0004 > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > > 2 0x00024000 0x00043fff "bootb" > > > attrs: 0x0004 > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 21686148-6449-6e6f-744e-656564454649 > > > 3 0x00044000 0x00243fff "rootfsa" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > > 4 0x00244000 0x00443fff "rootfsb" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > > 5 0x00444000 0x0070bfde "data" > > > attrs: 0x > > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > > > So, what I understand is If I create the GPT first and then write > > > the SPL, the SPL writing process will destroy the GPT Table and > > > if I write SPL first and then create GPT, the GPT creation > > > process will destroy the SPL. > > > > > > Is there any way to fix this? I remember we can prevent this > > > overlap by preserving GPT Table som other or boot partition > > > instead of having them at the beginning by default. > > > > > > Any inputs? > > > > On the diagram of GPT description [1] there is the info that > > partitions can start from LBA 34 (0x200 * 34) = 0x4400 > > > > From the above it seems like you starts from 0x4000 your boota > > partition, which then overwrites the "Entries 5-128" which shall be > > 0 and are protected by CRC written in the Primary GPT Header. > > > > Please try to adjust your partition scheme to start from 0x4400. > > I still see the overlap. I have created boota at 0x4400 and the write > the SPL at 0x400 ^^ - this overwrites the GPT header IMHO. You may dump the eMMC and check if this is the case (even with u-boot's md.l utility) I had similar problem on some Beagle Bone Black (AM33x) board. The ROM wanted to boot from the fixed eMMC LBA offset which was clashing with GPT. Fortunately, it was also possible to boot from FAT (it was checked before the raw offset from eMMC case) partition, so I used this option instead. But hey, isn't it possible to store SPL/u-boot to the eMMC's boot (the separate HW partition) partition and store GPT to the user accessible one (the large one - e.g. 4 GiB)? > > icorem6qdl-rqs> mmc part > > Partition Map for MMC device 2 -- Partition Type: EFI > > GUID Partition Table Entry Array CRC is wrong: 0xfca8e0bf != > 0xc10fdc7b find_valid_gpt: *** ERROR: Invalid GPT *** > find_valid_gpt: ***Using Backup GPT *** > PartStart LBA End LBA Name >
[U-Boot] [PATCH v2 4/4] x86: edison: Enable DFU timeout
The stock U-Boot on Intel Edison has timeout parameter for DFU command. Enable it here to be compatible with the original U-Boot configuration. Signed-off-by: Andy Shevchenko --- v2: - rebase on top of origin/master as of today (Lukasz) configs/edison_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/edison_defconfig b/configs/edison_defconfig index 29bc96aa60..056521a571 100644 --- a/configs/edison_defconfig +++ b/configs/edison_defconfig @@ -34,6 +34,7 @@ CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_ENV_OFFSET_REDUND=0x60 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_CPU=y +CONFIG_DFU_TIMEOUT=y CONFIG_DFU_MMC=y CONFIG_DFU_RAM=y CONFIG_SUPPORT_EMMC_BOOT=y -- 2.24.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/4] dfu: Drop unused prototype of dfu_trigger_reset()
After the commit 1cc03c5c53c0 ("dfu: Provide means to find difference between
dfu-util -e and -R") the dangling ptototype appeared. Remove it here.
Fixes: 1cc03c5c53c0 ("dfu: Provide means to find difference between dfu-util -e
and -R")
Cc: Lukasz Majewski
Cc: Stephen Warren
Signed-off-by: Andy Shevchenko
Acked-by: Lukasz Majewski
---
include/dfu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/dfu.h b/include/dfu.h
index 564966333f..2e3e91c8d2 100644
--- a/include/dfu.h
+++ b/include/dfu.h
@@ -171,7 +171,6 @@ const char *dfu_get_dev_type(enum dfu_device_type t);
const char *dfu_get_layout(enum dfu_layout l);
struct dfu_entity *dfu_get_entity(int alt);
char *dfu_extract_token(char** e, int *n);
-void dfu_trigger_reset(void);
int dfu_get_alt(char *name);
int dfu_init_env_entities(char *interface, char *devstr);
unsigned char *dfu_get_buf(struct dfu_entity *dfu);
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/4] dfu: Add optional timeout parameter
When the `dfu` command is called from the U-Boot environment,
it now accepts an optional parameter that specifies a timeout (in seconds).
If a DFU connection is not made within that time the `dfu` command exits
(as it would if Ctrl+C was pressed). If the timeout is left empty or being
zero the `dfu` command behaves as it does now.
This is useful for allowing U-Boot to check to see if anything wants to
upload new firmware before continuing to boot.
The patch is based on the commit
https://github.com/01org/edison-u-boot/commit/5e966ccc3c65c18c9783741fa04e0c45e021780c
by Sebastien Colleur, which has been heavily reworked due to U-Boot changes
in the past.
Signed-off-by: Brad Campbell
Signed-off-by: Andy Shevchenko
---
v2:
- add documentation part (Lukasz)
- drop original author's SoB due to bouncing email, give credit
in the commit message anyway
cmd/dfu.c | 15 +--
common/dfu.c| 17 +
doc/README.dfu | 8 ++--
drivers/dfu/Kconfig | 6 ++
drivers/dfu/dfu.c | 15 +++
include/dfu.h | 5 +
6 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/cmd/dfu.c b/cmd/dfu.c
index 14a8ec879e..b30f8a5667 100644
--- a/cmd/dfu.c
+++ b/cmd/dfu.c
@@ -30,7 +30,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
#if defined(CONFIG_DFU_OVER_USB) || defined(CONFIG_DFU_OVER_TFTP)
char *interface = NULL;
char *devstring = NULL;
-#if defined(CONFIG_DFU_OVER_TFTP)
+#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
unsigned long value = 0;
#endif
@@ -39,7 +39,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
devstring = argv[3];
}
-#if defined(CONFIG_DFU_OVER_TFTP)
+#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
if (argc == 5 || argc == 3)
value = simple_strtoul(argv[argc - 1], NULL, 0);
#endif
@@ -55,6 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
if (ret)
goto done;
+#ifdef CONFIG_DFU_TIMEOUT
+ dfu_set_timeout(value * 1000);
+#endif
+
ret = CMD_RET_SUCCESS;
if (strcmp(argv[argc - 1], "list") == 0) {
dfu_show_entities();
@@ -75,10 +79,17 @@ U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
"Device Firmware Upgrade",
""
#ifdef CONFIG_DFU_OVER_USB
+#ifdef CONFIG_DFU_TIMEOUT
+ " [ ] [] [list]\n"
+#else
" [ ] [list]\n"
+#endif
" - device firmware upgrade via \n"
"on device , attached to interface\n"
"\n"
+#ifdef CONFIG_DFU_TIMEOUT
+ "[] - specify inactivity timeout in seconds\n"
+#endif
"[list] - list available alt settings\n"
#endif
#ifdef CONFIG_DFU_OVER_TFTP
diff --git a/common/dfu.c b/common/dfu.c
index 44d1484d3d..da6289b218 100644
--- a/common/dfu.c
+++ b/common/dfu.c
@@ -35,6 +35,10 @@ int run_usb_dnl_gadget(int usbctrl_index, char
*usb_dnl_gadget)
return CMD_RET_FAILURE;
}
+#ifdef CONFIG_DFU_TIMEOUT
+ unsigned long start_time = get_timer(0);
+#endif
+
while (1) {
if (g_dnl_detach()) {
/*
@@ -79,6 +83,19 @@ int run_usb_dnl_gadget(int usbctrl_index, char
*usb_dnl_gadget)
}
}
+#ifdef CONFIG_DFU_TIMEOUT
+ unsigned long wait_time = dfu_get_timeout();
+
+ if (wait_time) {
+ unsigned long current_time = get_timer(start_time);
+
+ if (current_time > wait_time) {
+ debug("Inactivity timeout, abort DFU\n");
+ goto exit;
+ }
+ }
+#endif
+
WATCHDOG_RESET();
usb_gadget_handle_interrupts(usbctrl_index);
}
diff --git a/doc/README.dfu b/doc/README.dfu
index 558d347c26..caf1c9998c 100644
--- a/doc/README.dfu
+++ b/doc/README.dfu
@@ -43,6 +43,7 @@ Configuration Options:
CONFIG_DFU_RAM
CONFIG_DFU_SF
CONFIG_DFU_SF_PART
+ CONFIG_DFU_TIMEOUT
CONFIG_DFU_VIRTUAL
CONFIG_CMD_DFU
@@ -70,12 +71,15 @@ Commands:
dfu [ ] list
list the alternate device defined in "dfu_alt_info"
- dfu [ ]
+ dfu [ ] []
start the dfu stack on the USB instance with the selected medium
backend and use the "dfu_alt_info" variable to configure the
alternate setting and link each one with the medium
The dfu command continue until receive a ^C in console or
-a DFU detach transaction from HOST.
+a DFU detach transaction from HOST. If CONFIG_DFU_TIMEOUT option
+is enabled and parameter is present in the command line,
+the DFU operation will be aborted automatically after
+seconds of waiting remote to initiate DFU session.
The possible values of are :
(with = 0 in the dfu command example)
diff --git
[U-Boot] [PATCH v2 2/4] dfu: Refactor do_dfu() to handle optional argument
In the future we may utilize optional argument in 'dfu' command line.
As a preparation for this, refactor do_dfu().
Signed-off-by: Andy Shevchenko
Acked-by: Lukasz Majewski
---
cmd/dfu.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/cmd/dfu.c b/cmd/dfu.c
index 33491d0bc9..14a8ec879e 100644
--- a/cmd/dfu.c
+++ b/cmd/dfu.c
@@ -30,22 +30,25 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#if defined(CONFIG_DFU_OVER_USB) || defined(CONFIG_DFU_OVER_TFTP)
char *interface = NULL;
char *devstring = NULL;
+#if defined(CONFIG_DFU_OVER_TFTP)
+ unsigned long value = 0;
+#endif
if (argc >= 4) {
interface = argv[2];
devstring = argv[3];
}
+
+#if defined(CONFIG_DFU_OVER_TFTP)
+ if (argc == 5 || argc == 3)
+ value = simple_strtoul(argv[argc - 1], NULL, 0);
+#endif
#endif
int ret = 0;
#ifdef CONFIG_DFU_OVER_TFTP
- unsigned long addr = 0;
- if (!strcmp(argv[1], "tftp")) {
- if (argc == 5 || argc == 3)
- addr = simple_strtoul(argv[argc - 1], NULL, 0);
-
- return update_tftp(addr, interface, devstring);
- }
+ if (!strcmp(argv[1], "tftp"))
+ return update_tftp(value, interface, devstring);
#endif
#ifdef CONFIG_DFU_OVER_USB
ret = dfu_init_env_entities(interface, devstring);
--
2.24.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
Hi Andy, > On Wed, Nov 27, 2019 at 11:57:53AM +0100, Lukasz Majewski wrote: > > Hi Andy, > > > > > The stock U-Boot on Intel Edison has timeout parameter for DFU > > > command. Enable it here to be compatible with the original U-Boot > > > configuration. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > configs/edison_defconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/configs/edison_defconfig b/configs/edison_defconfig > > > index 1c74ee9709..227e2f750c 100644 > > > --- a/configs/edison_defconfig > > > +++ b/configs/edison_defconfig > > > @@ -29,6 +29,7 @@ CONFIG_CMD_FS_GENERIC=y > > > CONFIG_DEFAULT_DEVICE_TREE="edison" > > > CONFIG_ENV_IS_IN_MMC=y > > > CONFIG_CPU=y > > > +CONFIG_DFU_TIMEOUT=y > > > CONFIG_DFU_MMC=y > > > CONFIG_DFU_RAM=y > > > CONFIG_SUPPORT_EMMC_BOOT=y > > > > This patch doesn't apply now. > > I base my patches on official releases / release candidates. It > applies very well on top of 2020.01-rc3 as of today. Does DFU has a > separate repository / branch to track? > I'm using u-boot-usb as a base: https://gitlab.denx.de/u-boot/custodians/u-boot-usb/commits/next as I'm sending PRs to Marek. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgp10oObMxbH0.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Revert "powerpc: mpc85xx: delete FSL_SATA for T2080QDS board."
Dear Peng Ma, In message <20191127100145.44346-1-peng...@nxp.com> you wrote: > This reverts commit 856b9cdb53f0e6c8d98f81cf71ef363c16b0aa0e. > > Signed-off-by: Peng Ma Why? A commit message should always explain why such an action is taking place. 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 The high cost of living hasn't affected its popularity. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 11/27/19 4:40 PM, Claudius Heine wrote:
> On 27/11/2019 16.21, Marek Vasut wrote:
>> On 11/27/19 4:17 PM, Claudius Heine wrote:
>>> On 27/11/2019 16.12, Marek Vasut wrote:
On 11/27/19 4:09 PM, Claudius Heine wrote:
> Hi Marek,
>
> On 27/11/2019 15.47, Marek Vasut wrote:
>> On 11/27/19 3:20 PM, Claudius Heine wrote:
>>> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be
>>> available
>>> anywere, even if SYSRESET is disabled for SPL in the board specific
>>> header
>>> file like this:
>>>
>>> #if defined(CONFIG_SPL_BUILD)
>>> #undef CONFIG_WDT
>>> #undef CONFIG_WATCHDOG
>>> #undef CONFIG_SYSRESET
>>> #define CONFIG_HW_WATCHDOG
>>> #endif
>>>
>>> 'do_reset' is called from SPL for instance from the panic handler in
>>> case
>>> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>>>
>>> Setting PANIC_HANG would solve this issue, but it also changes the
>>> behavior
>>> in case a panic occurs.
>>>
>>> Signed-off-by: Claudius Heine
>>> ---
>>> arch/arm/lib/Makefile | 2 --
>>> arch/arm/lib/reset.c | 2 ++
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>>> index 9de9a9acee..763eb4498f 100644
>>> --- a/arch/arm/lib/Makefile
>>> +++ b/arch/arm/lib/Makefile
>>> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
>>> else
>>> obj-y += interrupts.o
>>> endif
>>> -ifndef CONFIG_SYSRESET
>>> obj-y += reset.o
>>> -endif
>>>
>>> obj-y += cache.o
>>> obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
>>> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
>>> index f3ea116e87..11e680be1d 100644
>>> --- a/arch/arm/lib/reset.c
>>> +++ b/arch/arm/lib/reset.c
>>> @@ -22,6 +22,7 @@
>>>
>>> #include
>>>
>>> +#if !defined(CONFIG_SYSRESET)
>>> __weak void reset_misc(void)
>>> {
>>> }
>>> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc,
>>> char * const argv[])
>>> /*NOTREACHED*/
>>> return 0;
>>> }
>>> +#endif
>>
>> Does this mean there's now one huge ifdef around the entire source file?
>> That's odd.
>
> Right. Other suggestions?
>
> Maybe having 'do_reset' here as a weak instead, so that sysreset can
> overwrite it? But then the other definitions in arch/*/lib/reset.c
> should probably be the same for consistency sake?
>
> I tried with this patch not to change anything in case SYSRESET is
> enabled too much and since the file isn't too large I thought that would
> be ok for now.
What if sysreset implemented do_reset ? Wouldn't that solve the issue ?
>>>
>>> Not sure what you mean... sysreset implements do_reset:
>>>
>>> https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112
>>>
>>> But the SPL does not have sysreset in this case, so it needs something
>>> different.
>>
>> Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ?
>
> Well that would probably not enough. I would also need settings for the
> watchdog, because the SPL does not have DM support, so while u-boot uses
> CONFIG_WATCHDOG the SPL uses CONFIG_HW_WATCHDOG.
>
> Easier that changing all this is something like this in the board header
> file (as I described in the commit description):
>
> #if defined(CONFIG_SPL_BUILD)
> #undef CONFIG_WDT
> #undef CONFIG_WATCHDOG
> #undef CONFIG_SYSRESET
> #define CONFIG_HW_WATCHDOG
> #endif
Can't we add DM watchdog to SPL instead ?
> In case of imx6, that way the SPL uses the hw_watchdog_reset from the
> imx watchdog driver instead of the 'watchdog_reset'.
>
> 'watchdog_reset' is not available since that is implemented in
> wdt-uclass.c and CONFIG_SPL_WDT depends on SPL_DM.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] GPT overlap on i.MX6
Hi Lukasz, On Wed, Nov 27, 2019 at 4:15 PM Lukasz Majewski wrote: > > Hi Jagan, > > > Hi, > > > > I have created GPT table start from 8MB for kernel, roots etc. > > something like > > > > PartStart LBA End LBA Name > > Attributes > > Type GUID > > Partition GUID > > 1 0x4000 0x00023fff "boota" > > attrs: 0x0004 > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > 2 0x00024000 0x00043fff "bootb" > > attrs: 0x0004 > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 21686148-6449-6e6f-744e-656564454649 > > 3 0x00044000 0x00243fff "rootfsa" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > 4 0x00244000 0x00443fff "rootfsb" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > 5 0x00444000 0x0070bfde "data" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > I have not included SPL, U-Boot to the partition list since it start > > from 0x400 in i.MX6. So > > I'm writing SPL separately using fastboot(with offset) or ums. > > > > But by doing this, the partition header seems overlapped so the > > output looks > > > > GUID Partition Table Entry Array CRC is wrong: 0x6a1aba0a != > > 0x8e4fd548 find_valid_gpt: *** ERROR: Invalid GPT *** > > find_valid_gpt: ***Using Backup GPT *** > > PartStart LBA End LBA Name > > Attributes > > Type GUID > > Partition GUID > > 1 0x4000 0x00023fff "boota" > > attrs: 0x0004 > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b > > 2 0x00024000 0x00043fff "bootb" > > attrs: 0x0004 > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 21686148-6449-6e6f-744e-656564454649 > > 3 0x00044000 0x00243fff "rootfsa" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: b921b045-1df0-41c3-af44-4c6f280d3fae > > 4 0x00244000 0x00443fff "rootfsb" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 8da63339-0007-60c0-c436-083ac8230908 > > 5 0x00444000 0x0070bfde "data" > > attrs: 0x > > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > > guid: 4f72ab70-69be-5948-81ff-4fc3daf24faa > > > > So, what I understand is If I create the GPT first and then write the > > SPL, the SPL writing process will destroy the GPT Table and if I write > > SPL first and then create GPT, the GPT creation process will destroy > > the SPL. > > > > Is there any way to fix this? I remember we can prevent this overlap > > by preserving GPT Table som other or boot partition instead of having > > them at the beginning by default. > > > > Any inputs? > > On the diagram of GPT description [1] there is the info that partitions > can start from LBA 34 (0x200 * 34) = 0x4400 > > From the above it seems like you starts from 0x4000 your boota > partition, which then overwrites the "Entries 5-128" which shall be 0 > and are protected by CRC written in the Primary GPT Header. > > Please try to adjust your partition scheme to start from 0x4400. I still see the overlap. I have created boota at 0x4400 and the write the SPL at 0x400 icorem6qdl-rqs> mmc part Partition Map for MMC device 2 -- Partition Type: EFI GUID Partition Table Entry Array CRC is wrong: 0xfca8e0bf != 0xc10fdc7b find_valid_gpt: *** ERROR: Invalid GPT *** find_valid_gpt: ***Using Backup GPT *** PartStart LBA End LBA Name Attributes Type GUID Partition GUID 1 0x4400 0x000243ff "bootA" attrs: 0x0004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: c12a7328-f81f-11d2-ba4b-00a0c93ec93b 2 0x00024400 0x000443ff "bootB" attrs: 0x0004 type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 21686148-6449-6e6f-744e-656564454649 3 0x00044400 0x002443ff "rootfsA" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: b921b045-1df0-41c3-af44-4c6f280d3fae 4 0x00244400 0x004443ff "rootfsB" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 guid: 8da63339-0007-60c0-c436-083ac8230908 5 0x0000
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 27/11/2019 16.21, Marek Vasut wrote:
> On 11/27/19 4:17 PM, Claudius Heine wrote:
>> On 27/11/2019 16.12, Marek Vasut wrote:
>>> On 11/27/19 4:09 PM, Claudius Heine wrote:
Hi Marek,
On 27/11/2019 15.47, Marek Vasut wrote:
> On 11/27/19 3:20 PM, Claudius Heine wrote:
>> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be
>> available
>> anywere, even if SYSRESET is disabled for SPL in the board specific
>> header
>> file like this:
>>
>> #if defined(CONFIG_SPL_BUILD)
>> #undef CONFIG_WDT
>> #undef CONFIG_WATCHDOG
>> #undef CONFIG_SYSRESET
>> #define CONFIG_HW_WATCHDOG
>> #endif
>>
>> 'do_reset' is called from SPL for instance from the panic handler in case
>> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>>
>> Setting PANIC_HANG would solve this issue, but it also changes the
>> behavior
>> in case a panic occurs.
>>
>> Signed-off-by: Claudius Heine
>> ---
>> arch/arm/lib/Makefile | 2 --
>> arch/arm/lib/reset.c | 2 ++
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>> index 9de9a9acee..763eb4498f 100644
>> --- a/arch/arm/lib/Makefile
>> +++ b/arch/arm/lib/Makefile
>> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
>> else
>> obj-y += interrupts.o
>> endif
>> -ifndef CONFIG_SYSRESET
>> obj-y += reset.o
>> -endif
>>
>> obj-y += cache.o
>> obj-$(CONFIG_SYS_ARM_CACHE_CP15)+= cache-cp15.o
>> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
>> index f3ea116e87..11e680be1d 100644
>> --- a/arch/arm/lib/reset.c
>> +++ b/arch/arm/lib/reset.c
>> @@ -22,6 +22,7 @@
>>
>> #include
>>
>> +#if !defined(CONFIG_SYSRESET)
>> __weak void reset_misc(void)
>> {
>> }
>> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc,
>> char * const argv[])
>> /*NOTREACHED*/
>> return 0;
>> }
>> +#endif
>
> Does this mean there's now one huge ifdef around the entire source file?
> That's odd.
Right. Other suggestions?
Maybe having 'do_reset' here as a weak instead, so that sysreset can
overwrite it? But then the other definitions in arch/*/lib/reset.c
should probably be the same for consistency sake?
I tried with this patch not to change anything in case SYSRESET is
enabled too much and since the file isn't too large I thought that would
be ok for now.
>>>
>>> What if sysreset implemented do_reset ? Wouldn't that solve the issue ?
>>
>> Not sure what you mean... sysreset implements do_reset:
>>
>> https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112
>>
>> But the SPL does not have sysreset in this case, so it needs something
>> different.
>
> Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ?
Well that would probably not enough. I would also need settings for the
watchdog, because the SPL does not have DM support, so while u-boot uses
CONFIG_WATCHDOG the SPL uses CONFIG_HW_WATCHDOG.
Easier that changing all this is something like this in the board header
file (as I described in the commit description):
#if defined(CONFIG_SPL_BUILD)
#undef CONFIG_WDT
#undef CONFIG_WATCHDOG
#undef CONFIG_SYSRESET
#define CONFIG_HW_WATCHDOG
#endif
In case of imx6, that way the SPL uses the hw_watchdog_reset from the
imx watchdog driver instead of the 'watchdog_reset'.
'watchdog_reset' is not available since that is implemented in
wdt-uclass.c and CONFIG_SPL_WDT depends on SPL_DM.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
On Wed, Nov 27, 2019 at 05:21:32PM +0200, Andy Shevchenko wrote: > On Wed, Nov 27, 2019 at 11:57:53AM +0100, Lukasz Majewski wrote: > > Hi Andy, > > > > > The stock U-Boot on Intel Edison has timeout parameter for DFU > > > command. Enable it here to be compatible with the original U-Boot > > > configuration. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > configs/edison_defconfig | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/configs/edison_defconfig b/configs/edison_defconfig > > > index 1c74ee9709..227e2f750c 100644 > > > --- a/configs/edison_defconfig > > > +++ b/configs/edison_defconfig > > > @@ -29,6 +29,7 @@ CONFIG_CMD_FS_GENERIC=y > > > CONFIG_DEFAULT_DEVICE_TREE="edison" > > > CONFIG_ENV_IS_IN_MMC=y > > > CONFIG_CPU=y > > > +CONFIG_DFU_TIMEOUT=y > > > CONFIG_DFU_MMC=y > > > CONFIG_DFU_RAM=y > > > CONFIG_SUPPORT_EMMC_BOOT=y > > > > This patch doesn't apply now. > > I base my patches on official releases / release candidates. It applies very > well on top of 2020.01-rc3 as of today. Does DFU has a separate repository / > branch to track? I see few patches in mainstream touching areas nearby. Though, this one can be still applied with a reduced context. -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 11/27/19 4:17 PM, Claudius Heine wrote:
> On 27/11/2019 16.12, Marek Vasut wrote:
>> On 11/27/19 4:09 PM, Claudius Heine wrote:
>>> Hi Marek,
>>>
>>> On 27/11/2019 15.47, Marek Vasut wrote:
On 11/27/19 3:20 PM, Claudius Heine wrote:
> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be
> available
> anywere, even if SYSRESET is disabled for SPL in the board specific header
> file like this:
>
> #if defined(CONFIG_SPL_BUILD)
> #undef CONFIG_WDT
> #undef CONFIG_WATCHDOG
> #undef CONFIG_SYSRESET
> #define CONFIG_HW_WATCHDOG
> #endif
>
> 'do_reset' is called from SPL for instance from the panic handler in case
> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>
> Setting PANIC_HANG would solve this issue, but it also changes the
> behavior
> in case a panic occurs.
>
> Signed-off-by: Claudius Heine
> ---
> arch/arm/lib/Makefile | 2 --
> arch/arm/lib/reset.c | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 9de9a9acee..763eb4498f 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
> else
> obj-y+= interrupts.o
> endif
> -ifndef CONFIG_SYSRESET
> obj-y+= reset.o
> -endif
>
> obj-y+= cache.o
> obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
> index f3ea116e87..11e680be1d 100644
> --- a/arch/arm/lib/reset.c
> +++ b/arch/arm/lib/reset.c
> @@ -22,6 +22,7 @@
>
> #include
>
> +#if !defined(CONFIG_SYSRESET)
> __weak void reset_misc(void)
> {
> }
> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char
> * const argv[])
> /*NOTREACHED*/
> return 0;
> }
> +#endif
Does this mean there's now one huge ifdef around the entire source file?
That's odd.
>>>
>>> Right. Other suggestions?
>>>
>>> Maybe having 'do_reset' here as a weak instead, so that sysreset can
>>> overwrite it? But then the other definitions in arch/*/lib/reset.c
>>> should probably be the same for consistency sake?
>>>
>>> I tried with this patch not to change anything in case SYSRESET is
>>> enabled too much and since the file isn't too large I thought that would
>>> be ok for now.
>>
>> What if sysreset implemented do_reset ? Wouldn't that solve the issue ?
>
> Not sure what you mean... sysreset implements do_reset:
>
> https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112
>
> But the SPL does not have sysreset in this case, so it needs something
> different.
Oh, so you need CONFIG_$(SPL_TPL_)SYSRESET then ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
On Wed, Nov 27, 2019 at 11:57:53AM +0100, Lukasz Majewski wrote: > Hi Andy, > > > The stock U-Boot on Intel Edison has timeout parameter for DFU > > command. Enable it here to be compatible with the original U-Boot > > configuration. > > > > Signed-off-by: Andy Shevchenko > > --- > > configs/edison_defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configs/edison_defconfig b/configs/edison_defconfig > > index 1c74ee9709..227e2f750c 100644 > > --- a/configs/edison_defconfig > > +++ b/configs/edison_defconfig > > @@ -29,6 +29,7 @@ CONFIG_CMD_FS_GENERIC=y > > CONFIG_DEFAULT_DEVICE_TREE="edison" > > CONFIG_ENV_IS_IN_MMC=y > > CONFIG_CPU=y > > +CONFIG_DFU_TIMEOUT=y > > CONFIG_DFU_MMC=y > > CONFIG_DFU_RAM=y > > CONFIG_SUPPORT_EMMC_BOOT=y > > This patch doesn't apply now. I base my patches on official releases / release candidates. It applies very well on top of 2020.01-rc3 as of today. Does DFU has a separate repository / branch to track? -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
Hardware comes out of reset with implicit values, but these are outside
the accepted range for Layerscape gen 3 chassis spec used on LS1028A.
Allocate different IDs and fix up Linux DT to use them.
Signed-off-by: Alex Marginean
Reviewed-by: Bin Meng
---
Changes in v2:
- moved code under arm/cpu from board as it's in fact SoC related
Replaces v1 and this earlier patch:
https://patchwork.ozlabs.org/patch/1144486/
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 9 ++
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++
.../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 93 +++
.../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++
4 files changed, 119 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 83a3319321..c6490556e6 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1098,6 +1098,12 @@ static void config_core_prefetch(void)
}
}
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void set_ecam_icids(void)
+{
+}
+#endif
+
int arch_early_init_r(void)
{
#ifdef CONFIG_SYS_FSL_ERRATUM_A009635
@@ -1149,6 +1155,9 @@ int arch_early_init_r(void)
#endif
#ifdef CONFIG_SYS_DPAA_QBMAN
setup_qbman_portals();
+#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ set_ecam_icids();
#endif
return 0;
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index e993209593..1e7e46e88a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -421,6 +421,12 @@ static void fdt_disable_multimedia(void *blob, unsigned
int svr)
}
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void fdt_fixup_ecam(void *blob)
+{
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -485,4 +491,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_ARCH_LS1028A
fdt_disable_multimedia(blob, svr);
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ fdt_fixup_ecam(blob);
+#endif
}
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index 9462298fbf..8110412da6 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -33,3 +33,96 @@ struct icid_id_table icid_tbl[] = {
};
int icid_tbl_sz = ARRAY_SIZE(icid_tbl);
+
+/* integrated PCI is handled separately as it's not part of CCSR/SCFG */
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+#define ECAM_IERB_BASE 0x1f080ULL
+#define ECAM_IERB_OFFSET_NA-1
+#define ECAM_IERB_FUNC_CNT ARRAY_SIZE(ierb_offset)
+/* cache related transaction attributes for PCIe functions */
+#define ECAM_IERB_MSICAR (ECAM_IERB_BASE + 0xa400)
+#define ECAM_IERB_MSICAR_VALUE 0x30
+
+/* offset of IERB config register per PCI function */
+static int ierb_offset[] = {
+ 0x0800,
+ 0x1800,
+ 0x2800,
+ 0x3800,
+ 0x4800,
+ 0x5800,
+ 0x6800,
+ ECAM_IERB_OFFSET_NA,
+ 0x0804,
+ 0x0808,
+ 0x1804,
+ 0x1808,
+};
+
+/*
+ * Use a custom function for LS1028A, for now this is the only SoC with IERB
+ * and we're currently considering reorganizing IERB for future SoCs.
+ */
+void set_ecam_icids(void)
+{
+ int i;
+
+ out_le32(ECAM_IERB_MSICAR, ECAM_IERB_MSICAR_VALUE);
+
+ for (i = 0; i < ECAM_IERB_FUNC_CNT; i++) {
+ if (ierb_offset[i] == ECAM_IERB_OFFSET_NA)
+ continue;
+
+ out_le32(ECAM_IERB_BASE + ierb_offset[i],
+FSL_ECAM_STREAM_ID_START + i);
+ }
+}
+
+static int fdt_setprop_inplace_idx_u32(void *fdt, int nodeoffset,
+ const char *name, uint32_t idx, u32 val)
+{
+ val = cpu_to_be32(val);
+ return fdt_setprop_inplace_namelen_partial(fdt, nodeoffset, name,
+ strlen(name),
+ idx * sizeof(val), ,
+ sizeof(val));
+}
+
+static int fdt_getprop_len(void *fdt, int nodeoffset, const char *name)
+{
+ int len;
+
+ if (fdt_getprop_namelen(fdt, nodeoffset, name, strlen(name), ))
+ return len;
+
+ return 0;
+}
+
+void fdt_fixup_ecam(void *blob)
+{
+ int off;
+
+ off = fdt_node_offset_by_compatible(blob, 0, "pci-host-ecam-generic");
+ if (off < 0) {
+ debug("ECAM node not found\n");
+ return;
+ }
+
+ if (fdt_getprop_len(blob, off, "msi-map") != 16 ||
+ fdt_getprop_len(blob, off, "iommu-map") != 16) {
+ log_err("invalid msi/iommu-map propertly size in ECAM node\n");
+ return;
+ }
+
+ fdt_setprop_inplace_idx_u32(blob, off, "msi-map", 2,
+
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 27/11/2019 16.12, Marek Vasut wrote:
> On 11/27/19 4:09 PM, Claudius Heine wrote:
>> Hi Marek,
>>
>> On 27/11/2019 15.47, Marek Vasut wrote:
>>> On 11/27/19 3:20 PM, Claudius Heine wrote:
In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
anywere, even if SYSRESET is disabled for SPL in the board specific header
file like this:
#if defined(CONFIG_SPL_BUILD)
#undef CONFIG_WDT
#undef CONFIG_WATCHDOG
#undef CONFIG_SYSRESET
#define CONFIG_HW_WATCHDOG
#endif
'do_reset' is called from SPL for instance from the panic handler in case
SPL_USB_SDP is enabled and PANIC_HANG is not set.
Setting PANIC_HANG would solve this issue, but it also changes the behavior
in case a panic occurs.
Signed-off-by: Claudius Heine
---
arch/arm/lib/Makefile | 2 --
arch/arm/lib/reset.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 9de9a9acee..763eb4498f 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -56,9 +56,7 @@ obj-y+= interrupts_64.o
else
obj-y += interrupts.o
endif
-ifndef CONFIG_SYSRESET
obj-y += reset.o
-endif
obj-y += cache.o
obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index f3ea116e87..11e680be1d 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -22,6 +22,7 @@
#include
+#if !defined(CONFIG_SYSRESET)
__weak void reset_misc(void)
{
}
@@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
/*NOTREACHED*/
return 0;
}
+#endif
>>>
>>> Does this mean there's now one huge ifdef around the entire source file?
>>> That's odd.
>>
>> Right. Other suggestions?
>>
>> Maybe having 'do_reset' here as a weak instead, so that sysreset can
>> overwrite it? But then the other definitions in arch/*/lib/reset.c
>> should probably be the same for consistency sake?
>>
>> I tried with this patch not to change anything in case SYSRESET is
>> enabled too much and since the file isn't too large I thought that would
>> be ok for now.
>
> What if sysreset implemented do_reset ? Wouldn't that solve the issue ?
Not sure what you mean... sysreset implements do_reset:
https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/sysreset/sysreset-uclass.c#L112
But the SPL does not have sysreset in this case, so it needs something
different.
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
Keyserver: hkp://pool.sks-keyservers.net
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 11/27/19 4:09 PM, Claudius Heine wrote:
> Hi Marek,
>
> On 27/11/2019 15.47, Marek Vasut wrote:
>> On 11/27/19 3:20 PM, Claudius Heine wrote:
>>> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
>>> anywere, even if SYSRESET is disabled for SPL in the board specific header
>>> file like this:
>>>
>>> #if defined(CONFIG_SPL_BUILD)
>>> #undef CONFIG_WDT
>>> #undef CONFIG_WATCHDOG
>>> #undef CONFIG_SYSRESET
>>> #define CONFIG_HW_WATCHDOG
>>> #endif
>>>
>>> 'do_reset' is called from SPL for instance from the panic handler in case
>>> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>>>
>>> Setting PANIC_HANG would solve this issue, but it also changes the behavior
>>> in case a panic occurs.
>>>
>>> Signed-off-by: Claudius Heine
>>> ---
>>> arch/arm/lib/Makefile | 2 --
>>> arch/arm/lib/reset.c | 2 ++
>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>>> index 9de9a9acee..763eb4498f 100644
>>> --- a/arch/arm/lib/Makefile
>>> +++ b/arch/arm/lib/Makefile
>>> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
>>> else
>>> obj-y += interrupts.o
>>> endif
>>> -ifndef CONFIG_SYSRESET
>>> obj-y += reset.o
>>> -endif
>>>
>>> obj-y += cache.o
>>> obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
>>> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
>>> index f3ea116e87..11e680be1d 100644
>>> --- a/arch/arm/lib/reset.c
>>> +++ b/arch/arm/lib/reset.c
>>> @@ -22,6 +22,7 @@
>>>
>>> #include
>>>
>>> +#if !defined(CONFIG_SYSRESET)
>>> __weak void reset_misc(void)
>>> {
>>> }
>>> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
>>> const argv[])
>>> /*NOTREACHED*/
>>> return 0;
>>> }
>>> +#endif
>>
>> Does this mean there's now one huge ifdef around the entire source file?
>> That's odd.
>
> Right. Other suggestions?
>
> Maybe having 'do_reset' here as a weak instead, so that sysreset can
> overwrite it? But then the other definitions in arch/*/lib/reset.c
> should probably be the same for consistency sake?
>
> I tried with this patch not to change anything in case SYSRESET is
> enabled too much and since the file isn't too large I thought that would
> be ok for now.
What if sysreset implemented do_reset ? Wouldn't that solve the issue ?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
Hi Marek,
On 27/11/2019 15.47, Marek Vasut wrote:
> On 11/27/19 3:20 PM, Claudius Heine wrote:
>> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
>> anywere, even if SYSRESET is disabled for SPL in the board specific header
>> file like this:
>>
>> #if defined(CONFIG_SPL_BUILD)
>> #undef CONFIG_WDT
>> #undef CONFIG_WATCHDOG
>> #undef CONFIG_SYSRESET
>> #define CONFIG_HW_WATCHDOG
>> #endif
>>
>> 'do_reset' is called from SPL for instance from the panic handler in case
>> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>>
>> Setting PANIC_HANG would solve this issue, but it also changes the behavior
>> in case a panic occurs.
>>
>> Signed-off-by: Claudius Heine
>> ---
>> arch/arm/lib/Makefile | 2 --
>> arch/arm/lib/reset.c | 2 ++
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
>> index 9de9a9acee..763eb4498f 100644
>> --- a/arch/arm/lib/Makefile
>> +++ b/arch/arm/lib/Makefile
>> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
>> else
>> obj-y += interrupts.o
>> endif
>> -ifndef CONFIG_SYSRESET
>> obj-y += reset.o
>> -endif
>>
>> obj-y += cache.o
>> obj-$(CONFIG_SYS_ARM_CACHE_CP15)+= cache-cp15.o
>> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
>> index f3ea116e87..11e680be1d 100644
>> --- a/arch/arm/lib/reset.c
>> +++ b/arch/arm/lib/reset.c
>> @@ -22,6 +22,7 @@
>>
>> #include
>>
>> +#if !defined(CONFIG_SYSRESET)
>> __weak void reset_misc(void)
>> {
>> }
>> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
>> const argv[])
>> /*NOTREACHED*/
>> return 0;
>> }
>> +#endif
>
> Does this mean there's now one huge ifdef around the entire source file?
> That's odd.
Right. Other suggestions?
Maybe having 'do_reset' here as a weak instead, so that sysreset can
overwrite it? But then the other definitions in arch/*/lib/reset.c
should probably be the same for consistency sake?
I tried with this patch not to change anything in case SYSRESET is
enabled too much and since the file isn't too large I thought that would
be ok for now.
regards
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: c...@denx.de
PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153
Keyserver: hkp://pool.sks-keyservers.net
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] dfu: Add optional timeout parameter
Hi Andy,
> On Wed, Nov 27, 2019 at 11:56:15AM +0100, Lukasz Majewski wrote:
>
> > Thank you for your work on enhancing DFU. The patch series is
> > generally Ok.
> >
> > Please find some minor comments/requests below.
>
> Thank you for review, my answers below.
>
> > > +#ifdef CONFIG_DFU_TIMEOUT
> > > + dfu_set_timeout(value * 1000);
> > > +#endif
>
> (1)
>
> > > +#ifdef CONFIG_DFU_TIMEOUT
> > > +void dfu_set_timeout(unsigned long timeout)
> > > +{
> > > + dfu_timeout = timeout;
> > > +}
> >
> > I do guess that dfu_set_timeout() is not yet used in this patch
> > series?
>
> I think you missed (1) by some reason.
Right. Thanks for pointing this out.
>
> > Please add some description and example of this new option /
> > feature to ./doc/README.dfu file.
>
> Will do for v2.
>
Thanks, appreciated.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpdoOkIWdjhV.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
On 11/27/19 3:20 PM, Claudius Heine wrote:
> In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
> anywere, even if SYSRESET is disabled for SPL in the board specific header
> file like this:
>
> #if defined(CONFIG_SPL_BUILD)
> #undef CONFIG_WDT
> #undef CONFIG_WATCHDOG
> #undef CONFIG_SYSRESET
> #define CONFIG_HW_WATCHDOG
> #endif
>
> 'do_reset' is called from SPL for instance from the panic handler in case
> SPL_USB_SDP is enabled and PANIC_HANG is not set.
>
> Setting PANIC_HANG would solve this issue, but it also changes the behavior
> in case a panic occurs.
>
> Signed-off-by: Claudius Heine
> ---
> arch/arm/lib/Makefile | 2 --
> arch/arm/lib/reset.c | 2 ++
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
> index 9de9a9acee..763eb4498f 100644
> --- a/arch/arm/lib/Makefile
> +++ b/arch/arm/lib/Makefile
> @@ -56,9 +56,7 @@ obj-y += interrupts_64.o
> else
> obj-y+= interrupts.o
> endif
> -ifndef CONFIG_SYSRESET
> obj-y+= reset.o
> -endif
>
> obj-y+= cache.o
> obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
> diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
> index f3ea116e87..11e680be1d 100644
> --- a/arch/arm/lib/reset.c
> +++ b/arch/arm/lib/reset.c
> @@ -22,6 +22,7 @@
>
> #include
>
> +#if !defined(CONFIG_SYSRESET)
> __weak void reset_misc(void)
> {
> }
> @@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
> /*NOTREACHED*/
> return 0;
> }
> +#endif
Does this mean there's now one huge ifdef around the entire source file?
That's odd.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
Hi Michael,
On 11/27/2019 3:33 PM, Michael Walle wrote:
Hi Alex,
Am 2019-11-27 14:57, schrieb Alex Marginean:
Hardware comes out of reset with implicit values, but these are outside
the accepted range for Layerscape gen 3 chassis spec used on LS1028A.
Allocate different IDs and fix up Linux DT to use them.
Signed-off-by: Alex Marginean
---
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++
.../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++
board/freescale/ls1028a/ls1028a.c | 106 ++
Doh :( is there no other place where to put this fixup? That would mean I
have to replicate this code for our custom board and so does every board
which uses the LS1028A. Shouldn't this be in the SoC LS1028A architecture
specific code?
Yeah, you're right about that.
It should probably go into armv8/fsl-layerscape/icid.c or somewhere
around there.
I'll send a v2.
Thanks!
Alex
3 files changed, 123 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index e993209593..1e7e46e88a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -421,6 +421,12 @@ static void fdt_disable_multimedia(void *blob,
unsigned int svr)
}
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void fdt_fixup_ecam(void *blob)
+{
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -485,4 +491,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_ARCH_LS1028A
fdt_disable_multimedia(blob, svr);
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ fdt_fixup_ecam(blob);
+#endif
}
diff --git
a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
index 94ea99a349..01d362d183 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
@@ -42,6 +42,10 @@
* -the MC is responsible for allocating and setting up
'isolation context
* IDs (ICIDs) based on the allocated stream IDs for all DPAA2
devices.
*
+ * - ECAM (integrated PCI)
+ * - U-Boot applies the value here to HW and does DT fix-up for both
+ * 'iommu-map' and 'msi-map'
+ *
mhh this is not entirely true, because it is the board code which
does the fixup, which may lead to some confusion. >
* On Chasis-3 SoCs stream IDs are programmed in AMQ registers
(32-bits) for
* each of the different bus masters. The relationship between
* the AMQ registers and stream IDs is defined in the table below:
@@ -98,6 +102,10 @@
#define FSL_DPAA2_STREAM_ID_START 23
#define FSL_DPAA2_STREAM_ID_END 63
+/* PCI IEPs, this overlaps DPAA2 but these two are exclusive at least
for now */
+#define FSL_ECAM_STREAM_ID_START 32
+#define FSL_ECAM_STREAM_ID_END 63
+
#define FSL_SEC_STREAM_ID 64
#define FSL_SEC_JR1_STREAM_ID 65
#define FSL_SEC_JR2_STREAM_ID 66
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index a9606b8865..1f5dc0d0b2 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -28,6 +28,52 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+#define ECAM_IERB_BASE 0x1f080ULL
+#define ECAM_IERB_OFFSET_NA -1
+#define ECAM_IERB_FUNC_CNT ARRAY_SIZE(ierb_offset)
+/* cache related transaction attributes for PCIe functions */
+#define ECAM_IERB_MSICAR (ECAM_IERB_BASE + 0xa400)
+#define ECAM_IERB_MSICAR_VALUE 0x30
+
+/* offset of IERB config register per PCI function */
+static int ierb_offset[] = {
+ 0x0800,
+ 0x1800,
+ 0x2800,
+ 0x3800,
+ 0x4800,
+ 0x5800,
+ 0x6800,
+ ECAM_IERB_OFFSET_NA,
+ 0x0804,
+ 0x0808,
+ 0x1804,
+ 0x1808,
+};
+
+/*
+ * Use a custom function for LS1028A, for now this is the only SoC
with IERB
+ * and we're currently considering reorganizing IERB for future SoCs.
+ */
+static void set_ecam_icids(void)
+{
+ int i;
+
+ out_le32(ECAM_IERB_MSICAR, ECAM_IERB_MSICAR_VALUE);
+
+ for (i = 0; i < ECAM_IERB_FUNC_CNT; i++) {
+ if (ierb_offset[i] == ECAM_IERB_OFFSET_NA)
+ continue;
+
+ out_le32(ECAM_IERB_BASE + ierb_offset[i],
+ FSL_ECAM_STREAM_ID_START + i);
+ }
+}
+
+#endif /* CONFIG_PCIE_ECAM_GENERIC */
+
int config_board_mux(void)
{
#if defined(CONFIG_TARGET_LS1028AQDS) && defined(CONFIG_FSL_QIXIS)
@@ -88,6 +134,16 @@ int board_init(void)
#endif
#endif
+
+ /*
+ * ICIDs for other hardware blocks are set really early on,
before MMU
+ * is set up. For integrated PCI we need access to IERB which is
not
+ * part of CCSR, so we have to wait for MMU mappings to be applied
+ */
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ set_ecam_icids();
+#endif
+
return 0;
}
@@ -244,3 +300,53 @@ int checkboard(void)
return 0;
}
#endif
+
+#ifdef
Re: [U-Boot] [PATCH 4/4] board: amlogic: Add missing config option
Hi Neil, On Wed, 27 Nov 2019 at 18:25, Neil Armstrong wrote: > > Hi, > > On 26/11/2019 22:12, Anand Moon wrote: > > Add missing config option CONFIG_MESON_GXBB and CONFIG_SYS_BOARD, > > for odroid-c2 and nanopi k2 board > > > > Signed-off-by: Anand Moon > > --- > > configs/nanopi-k2_defconfig | 2 ++ > > configs/odroid-c2_defconfig | 2 ++ > > 2 files changed, 4 insertions(+) > > > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > > index 7bdeb7906a..3d6265c587 100644 > > --- a/configs/nanopi-k2_defconfig > > +++ b/configs/nanopi-k2_defconfig > > @@ -1,6 +1,8 @@ > > CONFIG_ARM=y > > +CONFIG_SYS_BOARD="p200" > > CONFIG_ARCH_MESON=y > > CONFIG_SYS_TEXT_BASE=0x0100 > > +CONFIG_MESON_GXBB=y > > CONFIG_ENV_SIZE=0x2000 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig > > index 1f5a52c57c..700c871918 100644 > > --- a/configs/odroid-c2_defconfig > > +++ b/configs/odroid-c2_defconfig > > @@ -1,6 +1,8 @@ > > CONFIG_ARM=y > > +CONFIG_SYS_BOARD="p200" > > CONFIG_ARCH_MESON=y > > CONFIG_SYS_TEXT_BASE=0x0100 > > +CONFIG_MESON_GXBB=y > > CONFIG_ENV_SIZE=0x2000 > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_DEBUG_UART_BASE=0xc81004c0 > > > > These are not present since they are the default values, thus not exported in > savedefconfig. > > Neil You can ignore and drop this changes. -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: meson-gx: Fix tx phase in the tuning process
Hi Neil, On Wed, 27 Nov 2019 at 18:30, Neil Armstrong wrote: > > Hi, > > On 26/11/2019 22:12, Anand Moon wrote: > > odroid n2 eMMC module would failed to boot up, > > because of TX phase clk failure, fix the typo in > > TX phase macro to help tune correct clk freqency. > > > > Before these changes. > > clock is enabled (380953Hz) > > clock is enabled (2500Hz) > > after these changes > > clock is enabled (380953Hz) > > clock is enabled (2500Hz) > > clock is enabled (5200Hz) > > clock is enabled (5200Hz) > > clock is enabled (5200Hz) > > > > Signed-off-by: Anand Moon > > --- > > Tested on > > new orange - eMMC AJNB4R 14.6 GiB MMC 5.1 > > old back - eMMC CGND3R 58.2 GiB MMC 5.0 > > --- > > drivers/mmc/meson_gx_mmc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > > index 031cc79ccb..87bea2888b 100644 > > --- a/drivers/mmc/meson_gx_mmc.c > > +++ b/drivers/mmc/meson_gx_mmc.c > > @@ -53,7 +53,7 @@ static void meson_mmc_config_clock(struct mmc *mmc) > > meson_mmc_clk |= CLK_CO_PHASE_180; > > > > /* 180 phase tx clock */ > > - meson_mmc_clk |= CLK_TX_PHASE_000; > > + meson_mmc_clk |= CLK_TX_PHASE_180; > > > > /* clock settings */ > > meson_mmc_clk |= clk_src; > > > > I don't understand what this change helps, the linux driver sets the TX phase > to 0, > why 180 would help here ? > > Neil I narrow down to this small changes, without this small change it fails to detect the eMMC module. See the below log. U-Boot 2020.01-rc3-00082-g4b19b89ca4-dirty (Nov 27 2019 - 18:56:37 +0530) odroid-n2 Model: Hardkernel ODROID-N2 SoC: Amlogic Meson G12B (S922X) Revision 29:a (40:2) DRAM: 3.8 GiB mmc_bind: alias ret=-2, devnum=-1 mmc_bind: alias ret=-2, devnum=-1 MMC: clock is enabled (380953Hz) clock is enabled (380953Hz) sd@ffe05000: 0, mmc@ffe07000: 1 In:serial@3000 Out: serial@3000 Err: serial@3000 Net: gpio_request_tail: Node 'ethernet@ff3f', property 'snps,reset-gpio', failed to request GPIO index 0: -2 Warning: ethernet@ff3f (eth0) using random MAC address - 26:1e:2a:2a:67:d6 eth0: ethernet@ff3f Hit any key to stop autoboot: 0 clock is disabled (0Hz) regulator_common_set_enable: dev='regulator-tflash_vdd', enable=1, delay=0, has_gpio=1 regulator_common_set_enable: done clock is enabled (380953Hz) Card did not respond to voltage select! gpio_request_tail: Node 'regulator-vcc_3v3', property 'gpio', failed to request GPIO index 0: -2 Regulator 'regulator-vcc_3v3' optional enable GPIO - not found! Error: -2 gpio_request_tail: Node 'regulator-flash_1v8', property 'gpio', failed to request GPIO index 0: -2 Regulator 'regulator-flash_1v8' optional enable GPIO - not found! Error: -2 clock is disabled (0Hz) regulator_common_set_enable: dev='regulator-vcc_3v3', enable=1, delay=0, has_gpio=0 clock is enabled (380953Hz) clock is enabled (2500Hz) unable to select a mode switch to partitions #0, OK mmc1(part 0) is current device ** No partition table - mmc 1 ** MMC Device 2 not found no mmc device at slot 2 starting USB... Bus usb@ff50: gpio_request_tail: Node 'regulator-vcc_5v', property 'gpio', failed to request GPIO index 0: -2 Regulator 'regulator-vcc_5v' optional enable GPIO - not found! Error: -2 regulator_common_set_enable: dev='regulator-usb_pwr_en', enable=1, delay=0, has_gpio=1 regulator_common_set_enable: done Register 3000140 NbrPorts 3 Starting the controller USB XHCI 1.10 scanning bus usb@ff50 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found -Anand ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] SPDX header might be wrong in 4 files from Android Open Source Project
Le lun. 25 nov. 2019 à 17:20, Igor Opaniuk a écrit : > + Alex Deymo > > Hi Zdenek > > On Mon, Nov 25, 2019 at 6:05 PM zdenek.bou...@siemens.com > wrote: > > > > Hello, > > > > SPDX-License-Identifier: BSD-3-Clause might be wrong in the following 4 > files from Android Open Source Project (AOSP): > > > > include/android_bootloader_message.h > > include/sparse_format.h > > include/dt_table.h > > include/android_image.h > > they were re-licensed by one of the Google employees specifically for > U-boot [1]. > That's correct, I tried to make this re-licensing step explicit in the commit message. I sent the patches to add these headers re-licensed to BSD-3 after checking with our Opensource Releasing Team and they were OK with it in these particular cases. The original headers were Copyright "The Android Open Source Project". If you need help importing other AOSP headers with BSD-3 license instead of the one we normally use in AOSP (Apache 2) I might be able to help with that, but I do need to check with the team first. Best regards, deymo@ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] dfu: Add optional timeout parameter
On Wed, Nov 27, 2019 at 11:56:15AM +0100, Lukasz Majewski wrote:
> Thank you for your work on enhancing DFU. The patch series is generally
> Ok.
>
> Please find some minor comments/requests below.
Thank you for review, my answers below.
> > +#ifdef CONFIG_DFU_TIMEOUT
> > + dfu_set_timeout(value * 1000);
> > +#endif
(1)
> > +#ifdef CONFIG_DFU_TIMEOUT
> > +void dfu_set_timeout(unsigned long timeout)
> > +{
> > + dfu_timeout = timeout;
> > +}
>
> I do guess that dfu_set_timeout() is not yet used in this patch series?
I think you missed (1) by some reason.
> Please add some description and example of this new option / feature to
> ./doc/README.dfu file.
Will do for v2.
--
With Best Regards,
Andy Shevchenko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
Hi Alex,
Am 2019-11-27 14:57, schrieb Alex Marginean:
Hardware comes out of reset with implicit values, but these are outside
the accepted range for Layerscape gen 3 chassis spec used on LS1028A.
Allocate different IDs and fix up Linux DT to use them.
Signed-off-by: Alex Marginean
---
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++
.../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++
board/freescale/ls1028a/ls1028a.c | 106 ++
Doh :( is there no other place where to put this fixup? That would mean
I
have to replicate this code for our custom board and so does every board
which uses the LS1028A. Shouldn't this be in the SoC LS1028A
architecture
specific code?
3 files changed, 123 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index e993209593..1e7e46e88a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -421,6 +421,12 @@ static void fdt_disable_multimedia(void *blob,
unsigned int svr)
}
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void fdt_fixup_ecam(void *blob)
+{
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -485,4 +491,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_ARCH_LS1028A
fdt_disable_multimedia(blob, svr);
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ fdt_fixup_ecam(blob);
+#endif
}
diff --git
a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
index 94ea99a349..01d362d183 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
@@ -42,6 +42,10 @@
* -the MC is responsible for allocating and setting up 'isolation
context
* IDs (ICIDs) based on the allocated stream IDs for all DPAA2
devices.
*
+ * - ECAM (integrated PCI)
+ * - U-Boot applies the value here to HW and does DT fix-up for
both
+ * 'iommu-map' and 'msi-map'
+ *
mhh this is not entirely true, because it is the board code which does
the fixup,
which may lead to some confusion.
* On Chasis-3 SoCs stream IDs are programmed in AMQ registers
(32-bits) for
* each of the different bus masters. The relationship between
* the AMQ registers and stream IDs is defined in the table below:
@@ -98,6 +102,10 @@
#define FSL_DPAA2_STREAM_ID_START 23
#define FSL_DPAA2_STREAM_ID_END63
+/* PCI IEPs, this overlaps DPAA2 but these two are exclusive at least
for now */
+#define FSL_ECAM_STREAM_ID_START 32
+#define FSL_ECAM_STREAM_ID_END 63
+
#define FSL_SEC_STREAM_ID 64
#define FSL_SEC_JR1_STREAM_ID 65
#define FSL_SEC_JR2_STREAM_ID 66
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index a9606b8865..1f5dc0d0b2 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -28,6 +28,52 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+#define ECAM_IERB_BASE 0x1f080ULL
+#define ECAM_IERB_OFFSET_NA-1
+#define ECAM_IERB_FUNC_CNT ARRAY_SIZE(ierb_offset)
+/* cache related transaction attributes for PCIe functions */
+#define ECAM_IERB_MSICAR (ECAM_IERB_BASE + 0xa400)
+#define ECAM_IERB_MSICAR_VALUE 0x30
+
+/* offset of IERB config register per PCI function */
+static int ierb_offset[] = {
+ 0x0800,
+ 0x1800,
+ 0x2800,
+ 0x3800,
+ 0x4800,
+ 0x5800,
+ 0x6800,
+ ECAM_IERB_OFFSET_NA,
+ 0x0804,
+ 0x0808,
+ 0x1804,
+ 0x1808,
+};
+
+/*
+ * Use a custom function for LS1028A, for now this is the only SoC
with IERB
+ * and we're currently considering reorganizing IERB for future SoCs.
+ */
+static void set_ecam_icids(void)
+{
+ int i;
+
+ out_le32(ECAM_IERB_MSICAR, ECAM_IERB_MSICAR_VALUE);
+
+ for (i = 0; i < ECAM_IERB_FUNC_CNT; i++) {
+ if (ierb_offset[i] == ECAM_IERB_OFFSET_NA)
+ continue;
+
+ out_le32(ECAM_IERB_BASE + ierb_offset[i],
+FSL_ECAM_STREAM_ID_START + i);
+ }
+}
+
+#endif /* CONFIG_PCIE_ECAM_GENERIC */
+
int config_board_mux(void)
{
#if defined(CONFIG_TARGET_LS1028AQDS) && defined(CONFIG_FSL_QIXIS)
@@ -88,6 +134,16 @@ int board_init(void)
#endif
#endif
+
+ /*
+ * ICIDs for other hardware blocks are set really early on, before
MMU
+* is set up. For integrated PCI we need access to IERB which is not
+* part of CCSR, so we have to wait for MMU mappings to be applied
+*/
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ set_ecam_icids();
+#endif
+
return 0;
}
@@ -244,3 +300,53 @@ int checkboard(void)
return 0;
}
#endif
+
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+static int
Re: [U-Boot] [PATCH] tbs2910: Disable VxWorks image booting support
On 27.11.19 15:23, Tom Rini wrote: > There are currently no known users of this functionality on this > platform, disable it to prepare for additional VxWorks functionality > that would cause this platform to fail to link. > > Cc: Soeren Moch > Signed-off-by: Tom Rini Acked-by: Soeren Moch Thanks, Soeren > --- > configs/tbs2910_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig > index ffe043678cdf..22fa0e138441 100644 > --- a/configs/tbs2910_defconfig > +++ b/configs/tbs2910_defconfig > @@ -21,6 +21,7 @@ CONFIG_SYS_PROMPT="Matrix U-Boot> " > CONFIG_CMD_BOOTZ=y > # CONFIG_BOOTM_PLAN9 is not set > # CONFIG_BOOTM_RTEMS is not set > +# CONFIG_BOOTM_VXWORKS is not set > # CONFIG_CMD_FDT is not set > CONFIG_CMD_MEMTEST=y > # CONFIG_CMD_FLASH is not set ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] tbs2910: Disable VxWorks image booting support
There are currently no known users of this functionality on this platform, disable it to prepare for additional VxWorks functionality that would cause this platform to fail to link. Cc: Soeren Moch Signed-off-by: Tom Rini --- configs/tbs2910_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/tbs2910_defconfig b/configs/tbs2910_defconfig index ffe043678cdf..22fa0e138441 100644 --- a/configs/tbs2910_defconfig +++ b/configs/tbs2910_defconfig @@ -21,6 +21,7 @@ CONFIG_SYS_PROMPT="Matrix U-Boot> " CONFIG_CMD_BOOTZ=y # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set +# CONFIG_BOOTM_VXWORKS is not set # CONFIG_CMD_FDT is not set CONFIG_CMD_MEMTEST=y # CONFIG_CMD_FLASH is not set -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] ARM: reset: Move SYSRESET condition from Makefile into source file
In case CONFIG_SYSRESET is set, do_reset from reset.c will not be available
anywere, even if SYSRESET is disabled for SPL in the board specific header
file like this:
#if defined(CONFIG_SPL_BUILD)
#undef CONFIG_WDT
#undef CONFIG_WATCHDOG
#undef CONFIG_SYSRESET
#define CONFIG_HW_WATCHDOG
#endif
'do_reset' is called from SPL for instance from the panic handler in case
SPL_USB_SDP is enabled and PANIC_HANG is not set.
Setting PANIC_HANG would solve this issue, but it also changes the behavior
in case a panic occurs.
Signed-off-by: Claudius Heine
---
arch/arm/lib/Makefile | 2 --
arch/arm/lib/reset.c | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 9de9a9acee..763eb4498f 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -56,9 +56,7 @@ obj-y += interrupts_64.o
else
obj-y += interrupts.o
endif
-ifndef CONFIG_SYSRESET
obj-y += reset.o
-endif
obj-y += cache.o
obj-$(CONFIG_SYS_ARM_CACHE_CP15) += cache-cp15.o
diff --git a/arch/arm/lib/reset.c b/arch/arm/lib/reset.c
index f3ea116e87..11e680be1d 100644
--- a/arch/arm/lib/reset.c
+++ b/arch/arm/lib/reset.c
@@ -22,6 +22,7 @@
#include
+#if !defined(CONFIG_SYSRESET)
__weak void reset_misc(void)
{
}
@@ -40,3 +41,4 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
/*NOTREACHED*/
return 0;
}
+#endif
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: vxworks: Support Linux compatible standard DTB for ARM and PPC
On Wed, Nov 27, 2019 at 02:34:14PM +0100, Soeren Moch wrote: > On 27.11.19 13:55, Tom Rini wrote: > > On Wed, Nov 27, 2019 at 02:03:03PM +0800, Bin Meng wrote: > >> Hi Tom, > >> > >> On Wed, Nov 20, 2019 at 10:22 PM Tom Rini wrote: > >>> On Wed, Nov 20, 2019 at 10:11:00AM +0800, Bin Meng wrote: > Hi Tom, > > On Fri, Nov 15, 2019 at 4:21 PM Bin Meng wrote: > > From: Lihua Zhao > > > > Enhance do_bootm_vxworks() to support Linux compatible standard DTB > > for ARM and PPC, when the least significant bit of flags in VxWorks > > bootargs is set. Otherwise it falls back to the existing bootm flow > > which is now legacy. > > > > Signed-off-by: Lihua Zhao > > Signed-off-by: Bin Meng > > Reviewed-by: Bin Meng > > --- > > > > common/bootm_os.c | 39 +-- > > doc/README.vxworks | 13 + > > include/vxworks.h | 3 +++ > > 3 files changed, 53 insertions(+), 2 deletions(-) > It would be good if you pick this up for v2020.01. Thanks! > >>> OK, thanks. I'll put this on my TODO list for soon. > >> A gentle ping? > > So the issue now is that this causes size growth and then link failure > > on tbs2910. And I don't think "boot modern VxWorks kernels" is a new > > CONFIG option I want to see. So I'm not quite sure what to do here yet. > > Soeren, do you care about VxWorks support on this platform? Thanks! > > > I'm not aware of any user of VxWorks on tbs2910. So would be OK for me > to disable CONFIG_BOOTM_VXWORKS in tbs2910_defconfig. > > Do you want me to send a patch for this? Has this to go through the imx > tree? I'm also happy to send an Acked-by instead, if this makes things > easier. Thanks. I'll post a patch shortly and you can ack it. -- 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] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
On Wed, Nov 27, 2019 at 9:58 PM Alex Marginean wrote: > > Hardware comes out of reset with implicit values, but these are outside > the accepted range for Layerscape gen 3 chassis spec used on LS1028A. > Allocate different IDs and fix up Linux DT to use them. > > Signed-off-by: Alex Marginean > --- > arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++ > .../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++ > board/freescale/ls1028a/ls1028a.c | 106 ++ > 3 files changed, 123 insertions(+) > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ls1028a: Configure stream IDs for integrated PCI and fix up Linux DT
Hardware comes out of reset with implicit values, but these are outside
the accepted range for Layerscape gen 3 chassis spec used on LS1028A.
Allocate different IDs and fix up Linux DT to use them.
Signed-off-by: Alex Marginean
---
arch/arm/cpu/armv8/fsl-layerscape/fdt.c | 9 ++
.../asm/arch-fsl-layerscape/stream_id_lsch3.h | 8 ++
board/freescale/ls1028a/ls1028a.c | 106 ++
3 files changed, 123 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
index e993209593..1e7e46e88a 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fdt.c
@@ -421,6 +421,12 @@ static void fdt_disable_multimedia(void *blob, unsigned
int svr)
}
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+__weak void fdt_fixup_ecam(void *blob)
+{
+}
+#endif
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
@@ -485,4 +491,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#ifdef CONFIG_ARCH_LS1028A
fdt_disable_multimedia(blob, svr);
#endif
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ fdt_fixup_ecam(blob);
+#endif
}
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
index 94ea99a349..01d362d183 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/stream_id_lsch3.h
@@ -42,6 +42,10 @@
* -the MC is responsible for allocating and setting up 'isolation context
* IDs (ICIDs) based on the allocated stream IDs for all DPAA2 devices.
*
+ * - ECAM (integrated PCI)
+ * - U-Boot applies the value here to HW and does DT fix-up for both
+ * 'iommu-map' and 'msi-map'
+ *
* On Chasis-3 SoCs stream IDs are programmed in AMQ registers (32-bits) for
* each of the different bus masters. The relationship between
* the AMQ registers and stream IDs is defined in the table below:
@@ -98,6 +102,10 @@
#define FSL_DPAA2_STREAM_ID_START 23
#define FSL_DPAA2_STREAM_ID_END63
+/* PCI IEPs, this overlaps DPAA2 but these two are exclusive at least for now
*/
+#define FSL_ECAM_STREAM_ID_START 32
+#define FSL_ECAM_STREAM_ID_END 63
+
#define FSL_SEC_STREAM_ID 64
#define FSL_SEC_JR1_STREAM_ID 65
#define FSL_SEC_JR2_STREAM_ID 66
diff --git a/board/freescale/ls1028a/ls1028a.c
b/board/freescale/ls1028a/ls1028a.c
index a9606b8865..1f5dc0d0b2 100644
--- a/board/freescale/ls1028a/ls1028a.c
+++ b/board/freescale/ls1028a/ls1028a.c
@@ -28,6 +28,52 @@
DECLARE_GLOBAL_DATA_PTR;
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+#define ECAM_IERB_BASE 0x1f080ULL
+#define ECAM_IERB_OFFSET_NA-1
+#define ECAM_IERB_FUNC_CNT ARRAY_SIZE(ierb_offset)
+/* cache related transaction attributes for PCIe functions */
+#define ECAM_IERB_MSICAR (ECAM_IERB_BASE + 0xa400)
+#define ECAM_IERB_MSICAR_VALUE 0x30
+
+/* offset of IERB config register per PCI function */
+static int ierb_offset[] = {
+ 0x0800,
+ 0x1800,
+ 0x2800,
+ 0x3800,
+ 0x4800,
+ 0x5800,
+ 0x6800,
+ ECAM_IERB_OFFSET_NA,
+ 0x0804,
+ 0x0808,
+ 0x1804,
+ 0x1808,
+};
+
+/*
+ * Use a custom function for LS1028A, for now this is the only SoC with IERB
+ * and we're currently considering reorganizing IERB for future SoCs.
+ */
+static void set_ecam_icids(void)
+{
+ int i;
+
+ out_le32(ECAM_IERB_MSICAR, ECAM_IERB_MSICAR_VALUE);
+
+ for (i = 0; i < ECAM_IERB_FUNC_CNT; i++) {
+ if (ierb_offset[i] == ECAM_IERB_OFFSET_NA)
+ continue;
+
+ out_le32(ECAM_IERB_BASE + ierb_offset[i],
+FSL_ECAM_STREAM_ID_START + i);
+ }
+}
+
+#endif /* CONFIG_PCIE_ECAM_GENERIC */
+
int config_board_mux(void)
{
#if defined(CONFIG_TARGET_LS1028AQDS) && defined(CONFIG_FSL_QIXIS)
@@ -88,6 +134,16 @@ int board_init(void)
#endif
#endif
+
+ /*
+* ICIDs for other hardware blocks are set really early on, before MMU
+* is set up. For integrated PCI we need access to IERB which is not
+* part of CCSR, so we have to wait for MMU mappings to be applied
+*/
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+ set_ecam_icids();
+#endif
+
return 0;
}
@@ -244,3 +300,53 @@ int checkboard(void)
return 0;
}
#endif
+
+#ifdef CONFIG_PCIE_ECAM_GENERIC
+
+static int fdt_setprop_inplace_idx_u32(void *fdt, int nodeoffset,
+ const char *name, uint32_t idx, u32 val)
+{
+ val = cpu_to_be32(val);
+ return fdt_setprop_inplace_namelen_partial(fdt, nodeoffset, name,
+ strlen(name),
+ idx * sizeof(val), ,
+
[U-Boot] [PULL] Pull request: u-boot-stm32 u-boot-stm32-20191126
Hi Tom Please pull the STM32 related patches for u-boot-stm32-20191126 With the following changes: - Solve warning for stih410-b2260 - Device tree alignment on v5.4-rc4 for all stm32 boards - Correct the eMMC pin configuration on stm32mp157c-ev1 - Add DFU and SPI-NAND support for stm32mp1 board Travis CI status: https://travis-ci.org/patrickdelaunay/u-boot/builds/617166580 Thanks, Patrick The following changes since commit 4b19b89ca4a866b7baa642533e6dbd67cd832d27: Merge tag 'rpi-next-2020.01' of https://github.com/mbgg/u-boot (2019-11-25 12:56:27 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20191126 for you to fetch changes up to b4fee1610864036c8363e552f8547e99b1100f0b: stm32mp1: add support for virtual partition read (2019-11-26 10:14:35 +0100) - Solve warning for stih410-b2260 - Device tree alignment on v5.4-rc4 for all stm32 boards - Correct the eMMC pin configuration on stm32mp157c-ev1 - Add DFU and SPI-NAND support for stm32mp1 board Patrice Chotard (1): configs: stih410-b2260: Enable DM_ETH flag Patrick Delaunay (8): ARM: dts: stm32: DT alignment with kernel v5.3 ARM: dts: stm32: DT alignment with kernel v5.4-rc4 ARM: dts: stm32: update eMMC configuration for stm32mp157c-ev1 stm32mp1: activate DFU support and command MTD stm32mp1: activate SET_DFU_ALT_INFO stm32mp1: configs: activate CONFIG_MTD_SPI_NAND stm32mp1: board: add spi nand support stm32mp1: add support for virtual partition read arch/arm/dts/st-pincfg.h | 1 + arch/arm/dts/stm32429i-eval.dts| 29 -- arch/arm/dts/stm32746g-eval.dts| 105 + arch/arm/dts/stm32f4-pinctrl.dtsi | 38 +--- arch/arm/dts/stm32f429-disco.dts | 40 ++ arch/arm/dts/stm32f429-pinctrl.dtsi| 38 +--- arch/arm/dts/stm32f429.dtsi| 127 + arch/arm/dts/stm32f469-disco.dts | 39 ++--- arch/arm/dts/stm32f469-pinctrl.dtsi| 39 + arch/arm/dts/stm32f469.dtsi| 2 +- arch/arm/dts/stm32f746-disco.dts | 39 ++--- arch/arm/dts/stm32f746.dtsi| 54 arch/arm/dts/stm32f769-disco.dts | 43 +--- arch/arm/dts/stm32h7-u-boot.dtsi | 41 +++ arch/arm/dts/stm32h743-pinctrl.dtsi| 83 + arch/arm/dts/stm32h743.dtsi| 69 +++ arch/arm/dts/stm32h743i-disco-u-boot.dtsi | 8 -- arch/arm/dts/stm32h743i-disco.dts | 76 arch/arm/dts/stm32h743i-eval-u-boot.dtsi | 9 --- arch/arm/dts/stm32h743i-eval.dts | 42 ++- arch/arm/dts/stm32mp157-pinctrl.dtsi | 59 arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 5 +++- arch/arm/dts/stm32mp157a-dk1.dts | 129 +++ arch/arm/dts/stm32mp157c-ed1-u-boot.dtsi | 5 +++- arch/arm/dts/stm32mp157c-ed1.dts | 51 +++--- arch/arm/dts/stm32mp157c-ev1.dts | 3 ++- arch/arm/dts/stm32mp157c.dtsi | 26 board/st/stm32mp1/README | 111 ++ board/st/stm32mp1/stm32mp1.c | 164 +++-- configs/stih410-b2260_defconfig| 1 + configs/stm32mp15_basic_defconfig | 6 + configs/stm32mp15_optee_defconfig | 6 + configs/stm32mp15_trusted_defconfig| 6 + include/configs/stm32mp1.h | 42 +-- include/dt-bindings/clock/stm32fx-clock.h | 9 --- include/dt-bindings/mfd/st,stpmic1.h | 4 +++ include/dt-bindings/mfd/stm32f7-rcc.h | 1 + include/dt-bindings/mfd/stm32h7-rcc.h | 2 +- 38 files changed, 1014
Re: [U-Boot] [PATCH v3 15/15] stm32mp1: add support for virtual partition read
Hi, > From: Patrick DELAUNAY > Sent: lundi 14 octobre 2019 09:28 > > Add read for OTP and PMIC NVM with alternates on virtual DFU device. > > Serie-cc: Boris Brezillon > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 14/15] stm32mp1: board: add spi nand support
Hi, > From: Patrick DELAUNAY > Sent: lundi 14 octobre 2019 09:28 > > This patch adds the support of the spi nand device in mtdparts command and in > dfu_alt_info. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/15] stm32mp1: configs: activate CONFIG_MTD_SPI_NAND
Hi, > From: Patrick DELAUNAY > Sent: lundi 14 octobre 2019 09:28 > > Activate the support of SPI NAND in stm32mp1 U-Boot. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/15] stm32mp1: activate SET_DFU_ALT_INFO
Hi, > From: Patrick DELAUNAY > Sent: lundi 14 octobre 2019 09:28 > > Generate automatically dfu_alt_info for the supported device. > The simple command "dfu 0" allows to start the dfu stack on usb 0 for the > supported devices: > - dfu mtd for nand0 > - dfu mtd for nor0 > - dfu mmc for SDCard > - dfu mmc for eMMC > - dfu ram for images in DDR > > The DUF alternate use the "part", "partubi" and "mmcpart" options to select > the > correct MTD or GPT partition or the eMMC hw boot partition. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/15] stm32mp1: activate DFU support and command MTD
Hi, > From: Patrick DELAUNAY > Sent: lundi 14 octobre 2019 09:28 > > Add support of DFU for MMC, MTD, RAM and MTD command. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: dts: stm32: update eMMC configuration for stm32mp157c-ev1
Hi > From: Patrick DELAUNAY > Sent: mercredi 6 novembre 2019 16:17 > > Update the sdmmc2 node for eMMC support on eval board stm32mp157c-ev1. > - update slew-rate for pin configuration > - update "vqmmc-supply" > - remove "st,sig-dir" > - add mandatory "pinctrl-names" > - add "mmc-ddr-3_3v" > > This patch solve the eMMC detection issue for command "mmc dev 1". > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] ARM: dts: stm32: DT alignment with kernel v5.4-rc4
Hi, > From: Patrick DELAUNAY > Sent: mercredi 6 novembre 2019 16:17 > > Device tree and binding alignment with kernel v5.4-rc4 > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] ARM: dts: stm32: DT alignment with kernel v5.3
Hi, > From: Patrick DELAUNAY > Sent: mercredi 6 novembre 2019 16:17 > > Device tree and binding alignment with kernel v5.3 and converted to SPDX. > > Signed-off-by: Patrick Delaunay > --- Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] configs: stih410-b2260: Enable DM_ETH flag
Hi > From: Patrice CHOTARD > Sent: vendredi 15 novembre 2019 11:57 > > This patch allows to fix the following compilation warning: > > = WARNING == This board > does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please > update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to > update by the deadline may result in board removal. > See doc/driver-model/migration.rst for more info. > > > Signed-off-by: Patrice Chotard Applied to u-boot-stm32/master, thanks! -- Patrick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/6] fat: write: fix broken write at non-zero file offset
Hi
On 27.11.2019 04:13, AKASHI Takahiro wrote:
> # I still need to understand the issues reported here.
>
> On Tue, Nov 26, 2019 at 11:57:34AM -0500, Tom Rini wrote:
>> On Tue, Nov 26, 2019 at 09:15:08AM +0100, Marek Szyprowski wrote:
>>
>>> Handling of the start file offset was broken in the current code. Although
>>> the code skipped the needed clusters, it then tried to continue write with
>>> current cluster set to EOF, what caused assertion. It also lacked adjusting
>>> filesize in case of writing at the end of file and adjusting in-cluster
>>> offset for partial overwrite.
>>>
>>> This patch fixes all those issues.
> If those issues are logically independent from each other,
> it would be nice to split this patch into small ones.
>
> I would like to expect you to add more test cases, especially
> against corner cases that you mentioned above, to test/py/tests/est_fs
> as I did in test_ext.py.
> Or at least please add more assertion checks.
Okay, I will try to prepare some tests which show bugs fixed by this
patch. I'm not sure I will manage to split this patch into patches
fixing each single issue I've observed, because at least some of them
were related.
I'm not familiar with py_test, but I will try to prepare some simple
scripts for sandbox to reproduce the observed issues.
>>> Signed-off-by: Marek Szyprowski
>>> ---
>>> fs/fat/fat_write.c | 13 ++---
>>> 1 file changed, 6 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
>>> index 6cfa5b4565..7fb373589d 100644
>>> --- a/fs/fat/fat_write.c
>>> +++ b/fs/fat/fat_write.c
>>> @@ -756,14 +756,12 @@ set_contents(fsdata *mydata, dir_entry *dentptr,
>>> loff_t pos, __u8 *buffer,
>>> /* go to cluster at pos */
>>> cur_pos = bytesperclust;
>>> while (1) {
>>> + newclust = get_fatent(mydata, curclust);
>>> if (pos <= cur_pos)
> I think that we should change this condition as
> if (pos < cur_pos)
> break;
> then modify the following code accordingly as well.
>
> In this way, 'curclust' points to [cur_pos - bytesperclust, cur_pos)
> and 'pos' is ensured to be in the middle after this 'while' unless
> (pos == cur_pos) && IS_LAST_CLUST(curclust,...).
>
> Then the code will be expected to look better understandable.
>
> Thanks,
> -Takahiro Akashi
>
>
>>> break;
>>> - if (IS_LAST_CLUST(curclust, mydata->fatsize))
>>> + if (IS_LAST_CLUST(newclust, mydata->fatsize))
>>> break;
>>> -
>>> - newclust = get_fatent(mydata, curclust);
>>> - if (!IS_LAST_CLUST(newclust, mydata->fatsize) &&
>>> - CHECK_CLUST(newclust, mydata->fatsize)) {
>>> + if (CHECK_CLUST(newclust, mydata->fatsize)) {
>>> debug("curclust: 0x%x\n", curclust);
>>> debug("Invalid FAT entry\n");
>>> return -1;
>>> @@ -772,8 +770,8 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
>>> pos, __u8 *buffer,
>>> cur_pos += bytesperclust;
>>> curclust = newclust;
>>> }
>>> - if (IS_LAST_CLUST(curclust, mydata->fatsize)) {
>>> - assert(pos == cur_pos);
>>> + if (pos == cur_pos && IS_LAST_CLUST(newclust, mydata->fatsize)) {
>>> + filesize -= pos;
>>> goto set_clusters;
>>> }
>>>
>>> @@ -814,6 +812,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
>>> pos, __u8 *buffer,
>>> else
>>> offset = pos - cur_pos;
>>> wsize = min_t(unsigned long long, actsize, filesize - cur_pos);
>>> + wsize -= offset;
>>> if (get_set_cluster(mydata, curclust, offset,
>>> buffer, wsize, )) {
>>> printf("Error get-and-setting cluster\n");
>> Adding in Heinrich and Akashi-san for more review on this, thanks!
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: vxworks: Support Linux compatible standard DTB for ARM and PPC
On 27.11.19 13:55, Tom Rini wrote: > On Wed, Nov 27, 2019 at 02:03:03PM +0800, Bin Meng wrote: >> Hi Tom, >> >> On Wed, Nov 20, 2019 at 10:22 PM Tom Rini wrote: >>> On Wed, Nov 20, 2019 at 10:11:00AM +0800, Bin Meng wrote: Hi Tom, On Fri, Nov 15, 2019 at 4:21 PM Bin Meng wrote: > From: Lihua Zhao > > Enhance do_bootm_vxworks() to support Linux compatible standard DTB > for ARM and PPC, when the least significant bit of flags in VxWorks > bootargs is set. Otherwise it falls back to the existing bootm flow > which is now legacy. > > Signed-off-by: Lihua Zhao > Signed-off-by: Bin Meng > Reviewed-by: Bin Meng > --- > > common/bootm_os.c | 39 +-- > doc/README.vxworks | 13 + > include/vxworks.h | 3 +++ > 3 files changed, 53 insertions(+), 2 deletions(-) It would be good if you pick this up for v2020.01. Thanks! >>> OK, thanks. I'll put this on my TODO list for soon. >> A gentle ping? > So the issue now is that this causes size growth and then link failure > on tbs2910. And I don't think "boot modern VxWorks kernels" is a new > CONFIG option I want to see. So I'm not quite sure what to do here yet. > Soeren, do you care about VxWorks support on this platform? Thanks! > I'm not aware of any user of VxWorks on tbs2910. So would be OK for me to disable CONFIG_BOOTM_VXWORKS in tbs2910_defconfig. Do you want me to send a patch for this? Has this to go through the imx tree? I'm also happy to send an Acked-by instead, if this makes things easier. Regards, Soeren ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] mmc: meson-gx: Fix tx phase in the tuning process
Hi, On 26/11/2019 22:12, Anand Moon wrote: > odroid n2 eMMC module would failed to boot up, > because of TX phase clk failure, fix the typo in > TX phase macro to help tune correct clk freqency. > > Before these changes. > clock is enabled (380953Hz) > clock is enabled (2500Hz) > after these changes > clock is enabled (380953Hz) > clock is enabled (2500Hz) > clock is enabled (5200Hz) > clock is enabled (5200Hz) > clock is enabled (5200Hz) > > Signed-off-by: Anand Moon > --- > Tested on > new orange - eMMC AJNB4R 14.6 GiB MMC 5.1 > old back - eMMC CGND3R 58.2 GiB MMC 5.0 > --- > drivers/mmc/meson_gx_mmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/mmc/meson_gx_mmc.c b/drivers/mmc/meson_gx_mmc.c > index 031cc79ccb..87bea2888b 100644 > --- a/drivers/mmc/meson_gx_mmc.c > +++ b/drivers/mmc/meson_gx_mmc.c > @@ -53,7 +53,7 @@ static void meson_mmc_config_clock(struct mmc *mmc) > meson_mmc_clk |= CLK_CO_PHASE_180; > > /* 180 phase tx clock */ > - meson_mmc_clk |= CLK_TX_PHASE_000; > + meson_mmc_clk |= CLK_TX_PHASE_180; > > /* clock settings */ > meson_mmc_clk |= clk_src; > I don't understand what this change helps, the linux driver sets the TX phase to 0, why 180 would help here ? Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Using sspi for hardware detection?
Hello, I'm working on a modular socfpga based system with several optional boards. Each optional board contain a board ID that can be read through a SPI bus. Since we want just read the board ID, we used manually the sspi command, something like: => sspi 1:1.0 8 0 42 But it seems that the sspi command can't be used in a uboot script. sspi seems only used to manually test spi drivers. If we compare with i2c command, we have a i2c read to memory: i2c read chip address[.0, .1, .2] length memaddress - read to memory Why there is no such feature for spi ? Is there an interest to evolve the sspi command to add a read to memory? sspi : . By looking at existing code, it seems that hardware detection in uboot is handled by architecture/board specific code to set custom environment variable like "fpgatype" [1] or "unit_ident" "unit_serial" [2] (misc_init_r). What do you recommend? Implement a custom misc_init_r() for hardware detection? [1] https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/misc_gen5.c#L139 [2] https://gitlab.denx.de/u-boot/u-boot/blob/master/board/softing/vining_fpga/socfpga.c#L48 Best regards, Romain ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] configs: meson64: enable GIC support for G12A/G12B
On 26/11/2019 22:12, Anand Moon wrote: > Enable GIC support for G12A/G12B platform. > > Signed-off-by: Anand Moon > --- > include/configs/meson64.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/meson64.h b/include/configs/meson64.h > index 736081277d..50707a3197 100644 > --- a/include/configs/meson64.h > +++ b/include/configs/meson64.h > @@ -8,7 +8,7 @@ > #define __MESON64_CONFIG_H > > /* Generic Interrupt Controller Definitions */ > -#if defined(CONFIG_MESON_AXG) > +#if (defined(CONFIG_MESON_AXG) || defined(CONFIG_MESON_G12A)) > #define GICD_BASE0xffc01000 > #define GICC_BASE0xffc02000 > #else /* MESON GXL and GXBB */ > Thanks for spotting this ! Reviewed-by: Neil Armstrong ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] board: amlogic: select PWRSEQ for all amlogic platform
On 26/11/2019 22:12, Anand Moon wrote:
> commit a10388dc6982 ("mmc: meson-gx: add support for mmc-pwrseq-emmc")
> introduce CONFIG_PWESEQ for power sequence for eMMC module on
> amlogic platform, so enable this to all amlogic boards.
>
> Signed-off-by: Anand Moon
> ---
> arch/arm/mach-meson/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
> index e29e4c0acc..513a33dae2 100644
> --- a/arch/arm/mach-meson/Kconfig
> +++ b/arch/arm/mach-meson/Kconfig
> @@ -8,6 +8,7 @@ config MESON64_COMMON
> select DM_SERIAL
> select SYSCON
> select REGMAP
> + select PWRSEQ
> select BOARD_LATE_INIT
> imply CMD_DM
>
>
Reviewed-by: Neil Armstrong
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: vxworks: Support Linux compatible standard DTB for ARM and PPC
On Wed, Nov 27, 2019 at 02:03:03PM +0800, Bin Meng wrote: > Hi Tom, > > On Wed, Nov 20, 2019 at 10:22 PM Tom Rini wrote: > > > > On Wed, Nov 20, 2019 at 10:11:00AM +0800, Bin Meng wrote: > > > Hi Tom, > > > > > > On Fri, Nov 15, 2019 at 4:21 PM Bin Meng wrote: > > > > > > > > From: Lihua Zhao > > > > > > > > Enhance do_bootm_vxworks() to support Linux compatible standard DTB > > > > for ARM and PPC, when the least significant bit of flags in VxWorks > > > > bootargs is set. Otherwise it falls back to the existing bootm flow > > > > which is now legacy. > > > > > > > > Signed-off-by: Lihua Zhao > > > > Signed-off-by: Bin Meng > > > > Reviewed-by: Bin Meng > > > > --- > > > > > > > > common/bootm_os.c | 39 +-- > > > > doc/README.vxworks | 13 + > > > > include/vxworks.h | 3 +++ > > > > 3 files changed, 53 insertions(+), 2 deletions(-) > > > > > > It would be good if you pick this up for v2020.01. Thanks! > > > > OK, thanks. I'll put this on my TODO list for soon. > > A gentle ping? So the issue now is that this causes size growth and then link failure on tbs2910. And I don't think "boot modern VxWorks kernels" is a new CONFIG option I want to see. So I'm not quite sure what to do here yet. Soeren, do you care about VxWorks support on this platform? 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 4/4] board: amlogic: Add missing config option
Hi, On 26/11/2019 22:12, Anand Moon wrote: > Add missing config option CONFIG_MESON_GXBB and CONFIG_SYS_BOARD, > for odroid-c2 and nanopi k2 board > > Signed-off-by: Anand Moon > --- > configs/nanopi-k2_defconfig | 2 ++ > configs/odroid-c2_defconfig | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/configs/nanopi-k2_defconfig b/configs/nanopi-k2_defconfig > index 7bdeb7906a..3d6265c587 100644 > --- a/configs/nanopi-k2_defconfig > +++ b/configs/nanopi-k2_defconfig > @@ -1,6 +1,8 @@ > CONFIG_ARM=y > +CONFIG_SYS_BOARD="p200" > CONFIG_ARCH_MESON=y > CONFIG_SYS_TEXT_BASE=0x0100 > +CONFIG_MESON_GXBB=y > CONFIG_ENV_SIZE=0x2000 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_DEBUG_UART_BASE=0xc81004c0 > diff --git a/configs/odroid-c2_defconfig b/configs/odroid-c2_defconfig > index 1f5a52c57c..700c871918 100644 > --- a/configs/odroid-c2_defconfig > +++ b/configs/odroid-c2_defconfig > @@ -1,6 +1,8 @@ > CONFIG_ARM=y > +CONFIG_SYS_BOARD="p200" > CONFIG_ARCH_MESON=y > CONFIG_SYS_TEXT_BASE=0x0100 > +CONFIG_MESON_GXBB=y > CONFIG_ENV_SIZE=0x2000 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_DEBUG_UART_BASE=0xc81004c0 > These are not present since they are the default values, thus not exported in savedefconfig. Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH] ARM: at91: Print CPU serial number in cpuinfo
The SAMA5D2 and SAMA5D4 series SoCs have a 64-bit Serial Number (unique
ID) burned in, which is displayed with 'print_cpuinfo()' now (in the
same format the SAM-BA applet prints it).
Example output:
CPU: SAMA5D27 1G bits DDR2 SDRAM
Serial number 0: 0x4630394b
1: 0x190d2750
Crystal frequency: 24 MHz
CPU clock: 492 MHz
Master clock : 164 MHz
Signed-off-by: Alexander Dahl
---
I looked over lots of other 'print_cpuinfo()' implementations for
different SoCs and found none printing a unique ID at all. Is there
another place for this? Is it just few SoCs have such a serial number
at all? Or is it not desired to print those along with the other CPU
info?
Greets
Alex
---
arch/arm/mach-at91/armv7/cpu.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-at91/armv7/cpu.c b/arch/arm/mach-at91/armv7/cpu.c
index 5da067cda1..6d50e1aea4 100644
--- a/arch/arm/mach-at91/armv7/cpu.c
+++ b/arch/arm/mach-at91/armv7/cpu.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#ifndef CONFIG_SYS_AT91_MAIN_CLOCK
@@ -42,9 +43,16 @@ void arch_preboot_os(void)
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
+ struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
char buf[32];
printf("CPU: %s\n", get_cpu_name());
+
+#if defined(CONFIG_SAMA5D2) || defined(CONFIG_SAMA5D4)
+ printf("Serial number 0: 0x%08x\n", sfr->sn0);
+ printf(" 1: 0x%08x\n", sfr->sn1);
+#endif
+
printf("Crystal frequency: %8s MHz\n",
strmhz(buf, get_main_clk_rate()));
printf("CPU clock: %8s MHz\n",
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/6] fat: write: fix broken write to fragmented files
Hi,
On 27.11.2019 03:26, AKASHI Takahiro wrote:
> Thank you for the heads-up.
>
> On Tue, Nov 26, 2019 at 11:57:29AM -0500, Tom Rini wrote:
>> On Tue, Nov 26, 2019 at 09:15:07AM +0100, Marek Szyprowski wrote:
>>
>>> The code for handing file overwrite incorrectly assumed that the file on
>>> disk is always contiguous. This resulted in corrupting disk structure
>>> every time when write to existing fragmented file happened. Fix this
>>> by adding proper check for cluster discontinuity and adjust chunk size
>>> on each partial write.
>>>
>>> Signed-off-by: Marek Szyprowski
>>> Reviewed-by: Oleksandr Suvorov
>>> Reviewed-by: Lukasz Majewski
>>> ---
>>> fs/fat/fat_write.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
>>> index 729cf39630..6cfa5b4565 100644
>>> --- a/fs/fat/fat_write.c
>>> +++ b/fs/fat/fat_write.c
>>> @@ -794,6 +794,8 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
>>> pos, __u8 *buffer,
>>>
>>> newclust = get_fatent(mydata, endclust);
>>>
>>> + if ((newclust - 1) != endclust)
> "newclust != (endclust + 1)" would be more intuitive?
> But it's just my preference.
Indeed.
>>> + break;
>>> if (IS_LAST_CLUST(newclust, mydata->fatsize))
>>> break;
>>> if (CHECK_CLUST(newclust, mydata->fatsize)) {
>>> @@ -811,7 +813,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
>>> pos, __u8 *buffer,
>>> offset = 0;
>>> else
>>> offset = pos - cur_pos;
>>> - wsize = min(cur_pos + actsize, filesize) - pos;
>>> + wsize = min_t(unsigned long long, actsize, filesize - cur_pos);
> This hunk is not directly related to the issue, is it?
It is partially related. I remember that it was not calculated correctly
for the fragmented files and then discovered that there was one more
case in which the current formula failed.
>>> if (get_set_cluster(mydata, curclust, offset,
>>> buffer, wsize, )) {
>>> printf("Error get-and-setting cluster\n");
>>> @@ -824,8 +826,6 @@ set_contents(fsdata *mydata, dir_entry *dentptr, loff_t
>>> pos, __u8 *buffer,
>>> if (filesize <= cur_pos)
>>> break;
>>>
>>> - /* CHECK: newclust = get_fatent(mydata, endclust); */
>>> -
>>> if (IS_LAST_CLUST(newclust, mydata->fatsize))
>>> /* no more clusters */
>>> break;
>> Adding in Heinrich and Akashi-san for more review on this, thanks!
> Otherwise, it looks good.
> Reviewed-by: AKASHI Takahiro
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 4/4] x86: edison: Enable DFU timeout
Hi Andy, > The stock U-Boot on Intel Edison has timeout parameter for DFU > command. Enable it here to be compatible with the original U-Boot > configuration. > > Signed-off-by: Andy Shevchenko > --- > configs/edison_defconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configs/edison_defconfig b/configs/edison_defconfig > index 1c74ee9709..227e2f750c 100644 > --- a/configs/edison_defconfig > +++ b/configs/edison_defconfig > @@ -29,6 +29,7 @@ CONFIG_CMD_FS_GENERIC=y > CONFIG_DEFAULT_DEVICE_TREE="edison" > CONFIG_ENV_IS_IN_MMC=y > CONFIG_CPU=y > +CONFIG_DFU_TIMEOUT=y > CONFIG_DFU_MMC=y > CONFIG_DFU_RAM=y > CONFIG_SUPPORT_EMMC_BOOT=y This patch doesn't apply now. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpDGjhfZ0N_v.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 3/4] dfu: Add optional timeout parameter
Hi Andy,
Thank you for your work on enhancing DFU. The patch series is generally
Ok.
Please find some minor comments/requests below.
> When the `dfu` command is called from the U-Boot environment,
> it now accepts an optional parameter that specifies a timeout (in
> seconds). If a DFU connection is not made within that time the `dfu`
> command exits (as it would if Ctrl+C was pressed). If the timeout is
> left empty or being zero the `dfu` command behaves as it does now.
>
> This is useful for allowing U-Boot to check to see if anything wants
> to upload new firmware before continuing to boot.
>
> The patch is based on the commit
> https://github.com/01org/edison-u-boot/commit/5e966ccc3c65c18c9783741fa04e0c45e021780c
> which has been heavily reworked due to U-Boot changes in the past.
>
> Signed-off-by: Sebastien Colleur
> Signed-off-by: Brad Campbell
> Signed-off-by: Andy Shevchenko
> ---
> cmd/dfu.c | 15 +--
> common/dfu.c| 17 +
> drivers/dfu/Kconfig | 6 ++
> drivers/dfu/dfu.c | 15 +++
> include/dfu.h | 5 +
> 5 files changed, 56 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/dfu.c b/cmd/dfu.c
> index 14a8ec879e..b30f8a5667 100644
> --- a/cmd/dfu.c
> +++ b/cmd/dfu.c
> @@ -30,7 +30,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) #if defined(CONFIG_DFU_OVER_USB) ||
> defined(CONFIG_DFU_OVER_TFTP) char *interface = NULL;
> char *devstring = NULL;
> -#if defined(CONFIG_DFU_OVER_TFTP)
> +#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
> unsigned long value = 0;
> #endif
>
> @@ -39,7 +39,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) devstring = argv[3];
> }
>
> -#if defined(CONFIG_DFU_OVER_TFTP)
> +#if defined(CONFIG_DFU_TIMEOUT) || defined(CONFIG_DFU_OVER_TFTP)
> if (argc == 5 || argc == 3)
> value = simple_strtoul(argv[argc - 1], NULL, 0);
> #endif
> @@ -55,6 +55,10 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) if (ret)
> goto done;
>
> +#ifdef CONFIG_DFU_TIMEOUT
> + dfu_set_timeout(value * 1000);
> +#endif
> +
> ret = CMD_RET_SUCCESS;
> if (strcmp(argv[argc - 1], "list") == 0) {
> dfu_show_entities();
> @@ -75,10 +79,17 @@ U_BOOT_CMD(dfu, CONFIG_SYS_MAXARGS, 1, do_dfu,
> "Device Firmware Upgrade",
> ""
> #ifdef CONFIG_DFU_OVER_USB
> +#ifdef CONFIG_DFU_TIMEOUT
> + " [ ] [] [list]\n"
> +#else
> " [ ] [list]\n"
> +#endif
> " - device firmware upgrade via \n"
> "on device , attached to interface\n"
> "\n"
> +#ifdef CONFIG_DFU_TIMEOUT
> + "[] - specify inactivity timeout in seconds\n"
> +#endif
> "[list] - list available alt settings\n"
> #endif
> #ifdef CONFIG_DFU_OVER_TFTP
> diff --git a/common/dfu.c b/common/dfu.c
> index 44d1484d3d..da6289b218 100644
> --- a/common/dfu.c
> +++ b/common/dfu.c
> @@ -35,6 +35,10 @@ int run_usb_dnl_gadget(int usbctrl_index, char
> *usb_dnl_gadget) return CMD_RET_FAILURE;
> }
>
> +#ifdef CONFIG_DFU_TIMEOUT
> + unsigned long start_time = get_timer(0);
> +#endif
> +
> while (1) {
> if (g_dnl_detach()) {
> /*
> @@ -79,6 +83,19 @@ int run_usb_dnl_gadget(int usbctrl_index, char
> *usb_dnl_gadget) }
> }
>
> +#ifdef CONFIG_DFU_TIMEOUT
> + unsigned long wait_time = dfu_get_timeout();
> +
> + if (wait_time) {
> + unsigned long current_time =
> get_timer(start_time); +
> + if (current_time > wait_time) {
> + debug("Inactivity timeout, abort
> DFU\n");
> + goto exit;
> + }
> + }
> +#endif
> +
> WATCHDOG_RESET();
> usb_gadget_handle_interrupts(usbctrl_index);
> }
> diff --git a/drivers/dfu/Kconfig b/drivers/dfu/Kconfig
> index 9fe5bc0f58..e070130b5a 100644
> --- a/drivers/dfu/Kconfig
> +++ b/drivers/dfu/Kconfig
> @@ -23,6 +23,12 @@ config DFU_TFTP
>
> Detailed description of this feature can be found at
> ./doc/README.dfutftp
> +config DFU_TIMEOUT
> + bool "Timeout waiting for DFU"
> + help
> + This option adds an optional timeout parameter for DFU
> which, if set,
> + will cause DFU to only wait for that many seconds before
> exiting. +
> config DFU_MMC
> bool "MMC back end for DFU"
> help
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index 38aecd3a05..df50196dfd 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -21,6 +21,9 @@ static LIST_HEAD(dfu_list);
> static int dfu_alt_num;
> static int alt_num_cnt;
> static struct hash_algo *dfu_hash_algo;
> +#ifdef CONFIG_DFU_TIMEOUT
> +static unsigned long dfu_timeout = 0;
> +#endif
>
> /*
> * The purpose of the dfu_flush_callback() function is to
Re: [U-Boot] [PATCH v1 1/4] dfu: Drop unused prototype of dfu_trigger_reset()
On Wed, 13 Nov 2019 19:43:41 +0200
Andy Shevchenko wrote:
> After the commit 1cc03c5c53c0 ("dfu: Provide means to find difference
> between dfu-util -e and -R") the dangling ptototype appeared. Remove
> it here.
>
> Fixes: 1cc03c5c53c0 ("dfu: Provide means to find difference between
> dfu-util -e and -R") Cc: Lukasz Majewski
> Cc: Stephen Warren
> Signed-off-by: Andy Shevchenko
> ---
> include/dfu.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/dfu.h b/include/dfu.h
> index 564966333f..2e3e91c8d2 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -171,7 +171,6 @@ const char *dfu_get_dev_type(enum dfu_device_type
> t); const char *dfu_get_layout(enum dfu_layout l);
> struct dfu_entity *dfu_get_entity(int alt);
> char *dfu_extract_token(char** e, int *n);
> -void dfu_trigger_reset(void);
> int dfu_get_alt(char *name);
> int dfu_init_env_entities(char *interface, char *devstr);
> unsigned char *dfu_get_buf(struct dfu_entity *dfu);
Acked-by: Lukasz Majewski
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpM4CIyd5o67.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/4] dfu: Refactor do_dfu() to handle optional argument
On Wed, 13 Nov 2019 19:43:42 +0200
Andy Shevchenko wrote:
> In the future we may utilize optional argument in 'dfu' command line.
> As a preparation for this, refactor do_dfu().
>
> Signed-off-by: Andy Shevchenko
> ---
> cmd/dfu.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/cmd/dfu.c b/cmd/dfu.c
> index 33491d0bc9..14a8ec879e 100644
> --- a/cmd/dfu.c
> +++ b/cmd/dfu.c
> @@ -30,22 +30,25 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[]) #if defined(CONFIG_DFU_OVER_USB) ||
> defined(CONFIG_DFU_OVER_TFTP) char *interface = NULL;
> char *devstring = NULL;
> +#if defined(CONFIG_DFU_OVER_TFTP)
> + unsigned long value = 0;
> +#endif
>
> if (argc >= 4) {
> interface = argv[2];
> devstring = argv[3];
> }
> +
> +#if defined(CONFIG_DFU_OVER_TFTP)
> + if (argc == 5 || argc == 3)
> + value = simple_strtoul(argv[argc - 1], NULL, 0);
> +#endif
> #endif
>
> int ret = 0;
> #ifdef CONFIG_DFU_OVER_TFTP
> - unsigned long addr = 0;
> - if (!strcmp(argv[1], "tftp")) {
> - if (argc == 5 || argc == 3)
> - addr = simple_strtoul(argv[argc - 1], NULL,
> 0); -
> - return update_tftp(addr, interface, devstring);
> - }
> + if (!strcmp(argv[1], "tftp"))
> + return update_tftp(value, interface, devstring);
> #endif
> #ifdef CONFIG_DFU_OVER_USB
> ret = dfu_init_env_entities(interface, devstring);
Acked-by: Lukasz Majewski
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp1pnb7c_YHO.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
