Re: [PATCH 09/14] lmb: riscv: Add arch_lmb_reserve()
> From: Marek Vasut > Sent: Monday, August 16, 2021 2:13 AM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Atish Patra > ; Leo Yu-Chi Liang(梁育齊) ; Rick > Jian-Zhi Chen(陳建志) ; Simon Goldschmidt > ; Tom Rini > Subject: [PATCH 09/14] lmb: riscv: Add arch_lmb_reserve() > > Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic(). > It is rather likely this architecture also needs to cover U-Boot with LMB > before booting Linux. > > Signed-off-by: Marek Vasut > Cc: Atish Patra > Cc: Leo > Cc: Rick Chen > Cc: Simon Goldschmidt > Cc: Tom Rini > --- > arch/riscv/lib/bootm.c | 13 + > 1 file changed, 13 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH 08/14] lmb: nds32: Add arch_lmb_reserve()
> From: Marek Vasut > Sent: Monday, August 16, 2021 2:13 AM > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Rick Jian-Zhi Chen(陳建志) > ; Simon Goldschmidt ; > Tom Rini > Subject: [PATCH 08/14] lmb: nds32: Add arch_lmb_reserve() > > Add arch_lmb_reserve() implemented using arch_lmb_reserve_generic(). > It is rather likely this architecture also needs to cover U-Boot with LMB > before booting Linux. > > Signed-off-by: Marek Vasut > Cc: Rick Chen > Cc: Simon Goldschmidt > Cc: Tom Rini > --- > arch/nds32/lib/bootm.c | 13 + > 1 file changed, 13 insertions(+) Reviewed-by: Rick Chen
Re: [PATCH v5 2/5] common: board_r: support enable_caches for RISC-V
> From: Zong Li > Sent: Wednesday, September 01, 2021 3:02 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; bmeng...@gmail.com; sean...@gmail.com; > green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; > u-boot@lists.denx.de > Cc: Zong Li > Subject: [PATCH v5 2/5] common: board_r: support enable_caches for RISC-V > > The enable_caches is a generic hook for architecture-implemented, we leverage > this function to enable caches for RISC-V > > Signed-off-by: Zong Li > --- > arch/riscv/lib/cache.c | 4 > common/board_r.c | 4 ++-- > 2 files changed, 6 insertions(+), 2 deletions(-) Reviewed-by: Rick Chen
Re: [PATCH v3 5/5] test/py: efi_capsule: align with the syntax change of mkeficapsule
On Tue, Aug 31, 2021 at 08:10:31AM +0200, Heinrich Schuchardt wrote:
> On 8/31/21 4:46 AM, AKASHI Takahiro wrote:
> > Modify command line arguments at mkeficapsule as the syntax was
> > a bit modified in the previous commit.
> >
> > Signed-off-by: AKASHI Takahiro
> > ---
> > test/py/tests/test_efi_capsule/conftest.py | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/test/py/tests/test_efi_capsule/conftest.py
> > b/test/py/tests/test_efi_capsule/conftest.py
> > index 6ad5608cd71c..8b5368c11abc 100644
> > --- a/test/py/tests/test_efi_capsule/conftest.py
> > +++ b/test/py/tests/test_efi_capsule/conftest.py
> > @@ -50,10 +50,10 @@ def efi_capsule_data(request, u_boot_config):
> > check_call('cd %s; %s/tools/mkimage -f uboot_bin_env.its
> > uboot_bin_env.itb' %
> > (data_dir, u_boot_config.build_dir),
> > shell=True)
> > -check_call('cd %s; %s/tools/mkeficapsule --fit uboot_bin_env.itb
> > --index 1 Test01' %
> > +check_call('cd %s; %s/tools/mkeficapsule --index 1 --fit
> > uboot_bin_env.itb Test01' %
> > (data_dir, u_boot_config.build_dir),
> > shell=True)
> > -check_call('cd %s; %s/tools/mkeficapsule --raw u-boot.bin.new
> > --index 1 Test02' %
> > +check_call('cd %s; %s/tools/mkeficapsule --index 1 --raw
> > u-boot.bin.new Test02' %
> > (data_dir, u_boot_config.build_dir),
> > shell=True)
> >
> >
>
> Should one of the tsts use a GUID (introduced in patch 4)?
Good point. After adding an extra test, I found a bug :)
uuid_parse() in libuuid is used to convert a string
into a guid value, but uuid and guid have different formats
of representation and we can't use the return value from
uuid_parse() as it is.
-Takahiro Akashi
> Best regards
>
> Heinrich
>
Re: [PATCH v2 2/2] tools: Handle PAGER containing arguments
On Fri, Aug 13, 2021 at 05:25:00PM +0100, Paul Barker wrote: > When printing full help output from a tool, we should be able to handle > a PAGER variable which includes arguments, e.g. PAGER='less -F'. > > Signed-off-by: Paul Barker This results in this CI failure: https://source.denx.de/u-boot/u-boot/-/jobs/316664 -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: rsa: Extract public key from private key if keyfile argument is used
On Wed, Jul 28, 2021 at 05:34:41PM -0700, Donald Chan wrote: > If the 'keyfile' (-G) argument is used, there is little value to require > 'keydir' (-k) argument since the public key can also be extracted from the > private key itself. > > Signed-off-by: Donald Chan This breaks the "vboot" tests run under sandbox, please investigate and fix, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 11:34:50PM +0200, Michael Walle wrote:
> Am 2021-09-01 12:29, schrieb Vladimir Oltean:
> > On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> > > - pcie1: pcie@340 {
> > > -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> > > "snps,dw-pcie";
> > > -reg = <0x00 0x0340 0x0 0x8
> > > -0x00 0x0348 0x0 0x4 /* lut
> > > registers */
> > > -0x00 0x034c 0x0 0x4 /* pf controls
> > > registers */
> > > -0x80 0x 0x0 0x2>; /*
> > > configuration space */
> > > -reg-names = "dbi", "lut", "ctrl", "config";
> > > -#address-cells = <3>;
> > > -#size-cells = <2>;
> > > -device_type = "pci";
> > > -num-lanes = <4>;
> > > -bus-range = <0x0 0xff>;
> > > -ranges = <0x8100 0x0 0x 0x80 0x0002
> > > 0x0
> > > 0x0001 /* downstream I/O */
> > > -0x8200 0x0 0x4000 0x80 0x4000
> > > 0x0 0x4000>;
> > > /* non-prefetchable memory */
> > > - };
> > > + pcie1: pcie@340 {
> > > + compatible = "fsl,ls1028a-pcie";
> > > + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> > > registers */
> > > + <0x80 0x 0x0 0x2000>; /*
> > > configuration space */
> >
> > This doesn't look good, the conversion is lossy. The Linux driver
> > (drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
> > compatible string, but the U-Boot driver
> > (drivers/pci/pcie_layerscape_rc.c)
> > calls fdt_get_named_resource("lut"). I don't think that the driver
> > works with a NULL pcie->lut pointer? The StreamID writes in
> > fdt_fixup_pcie_device_ls probably didn't explode because I don't have
> > any PCIe card plugged in.
>
> I guess it didn't probe anyway, because there is no driver for that
> compatible string ;)
omg, "ls1028" vs "ls1028a" :-/
> > Similar thing for the PEX PF control memory region. In the LS1028A RM,
> > technically this is part of the larger PEX_LUT memory map, just starting
> > from the 4_0014h offset.
> >
> > U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
> > but it seems that it needs to be extended to cover LS1028A:
>
> Only that one probably don't want to overwrite cfg_res.start and
> cfg_res.end.
My internal parser is broken by this phrase's syntax, but yes.
> > /*
> > * Fix the pcie memory map address and PF control registers address
> > * for LS2088A series SoCs
> > */
> > svr = get_svr();
> > svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
> > if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
> > svr == SVR_LS2048A || svr == SVR_LS2044A ||
> > svr == SVR_LS2081A || svr == SVR_LS2041A) {
> > pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
> > LS2088A_PCIE_PHYS_SIZE * pcie->idx;
> > pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
> > pcie->ctrl = pcie->lut + 0x4;
> > }
>
> Oh the horror! Why didn't one just change the config register value in
> the (u-boot) device tree instead of overwriting the value for some
> specific SoCs.
Code added in commit 3d8553f0a3ee ("pci: layerscape: add LS2088A series
SoC pcie support"). As to why the differentiation between LS2080A and
LS2088A/LS2084A and the 4-core variants is done through code rather than
through DT, Zhiqiang said:
| There isn't LS2088A DT file, actually it reuse LS2080A DT file
| under u-boot, while under kernel there are DT files for LS2080A
| and LS2088A respectively with different PCIe node compatible
| string.
https://u-boot.denx.narkive.com/XVDnIKG9/patchv3-1-2-pci-layerscape-add-ls2088a-series-soc-pcie-support
Again, as to why that is, no clue whatsoever.
>
> > As for pcie->lut itself, simplest would be to just default to what is
> > now the "dbi" reg value, plus a .lut_offset determined by compatible
> > string, in the case of "fsl,ls1028a-pcie" 0x8, just like Linux.
> >
> > Ah, and not to mention that the reg-names are not even the same between
> > U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
>
> Well and there is a big-endian property, which of course is set for any
> Layerscape but the LS1028A. linux has instead just one endianess, but
> use a shift offset.
You lost me here. How are registers accessed with the right endianness
in Linux and in U-Boot?
> Mh, I'm for sure not going to fix all these hacks in there. I'm thinking
> about bascially branching to a different probe for the ls1028a based on
> the compatible string (or rather if .data is set or not).
Makes sense to introduce a driver data structure for LS1028A.
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wed, Sep 01, 2021 at 11:44:52PM +0200, Pali Rohár wrote: > On Wednesday 01 September 2021 17:33:57 Tom Rini wrote: > > On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote: > > > On Wednesday 01 September 2021 17:17:06 Tom Rini wrote: > > > > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > > > > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > > > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > Including timestamp.h (either directly or transitionally) cause > > > > > > > build > > > > > > > system to recompile binaries at every 'make' run. This has > > > > > > > disadvantage > > > > > > > in U-Boot development as for every small change 'make' recompiles > > > > > > > lot of > > > > > > > other irrelevant files which were not touched / changed. > > > > > > > > > > > > > > This patch series eliminate transitional / indirect usage of > > > > > > > timestamp.h by removing unneeded inclusion of header files, moving > > > > > > > timestamp values from macros to global variables, etc... > > > > > > > > > > > > > > After these patches, U-Boot tools are not recompiled by every > > > > > > > 'make' run, > > > > > > > which decrease time for incremental U-Boot recompilation. > > > > > > > > > > > > > > Please test these patches, specially m68k and powerpc parts as I > > > > > > > do not > > > > > > > have any of these boards. > > > > > > > > > > > > > > Patch series depend on this patch (now marked as accepted): > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > > > > > > > > > Pali Rohár (11): > > > > > > > Remove #include from files which do not need it > > > > > > > Remove #include from files which do not need it > > > > > > > efi_loader: Use directly version_string variable > > > > > > > version: Move version_string[] from version.h to > > > > > > > version_string.h > > > > > > > m68k: mcf: Remove overloading version_string > > > > > > > version: Put version_string[] variable into section > > > > > > > .text_version_string > > > > > > > powerpc: mpc: Put U-Boot version string at correct place by > > > > > > > linker > > > > > > > script > > > > > > > version: Do not make version_string[] variable as a weak > > > > > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug > > > > > > > log > > > > > > > version: Remove global macro U_BOOT_VERSION_STRING from > > > > > > > version.h > > > > > > > Remove including timestamp.h in version.h > > > > > > > > > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > > > > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > > > > > doc/develop/ci_testing.rst we document how to run a world build. > > > > > > Please > > > > > > fix these build errors and re-submit, thanks. > > > > > > > > > > Already happened about month ago > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > > > > > > > > > As stated, following build command now passes: > > > > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > > > > > > > > OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... > > > > > > I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and > > > this should be fixed above patch. At least I got similar error for > > > MCR3000_defconfig with new gcc before that. > > > > > > But now after scrolling down I see that second xtfpga error > > > https://source.denx.de/u-boot/u-boot/-/jobs/316614 > > > But seems that in this UI is error log truncated. I see only > > > > > > +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA > > > [fe021584,fe0215c7] overlaps section .u_boot_list LMA > > > [fe021584,fe021e6b] > > > > > > Is there a way how to show full build log? And which defconfig and > > > compiler is used? Because that error does not help me what is wrong > > > here... > > > > That's the full error log, from the linker, I believe. It's the xtfpga > > config for the xtensa architecture. It's one of the few that buildman > > won't fetch a good toolchain for so you'll want to look at > > tools/docker/Dockerfile and see we get it from > > https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz > > if you don't have the CI builder container itself handy already. > > So this is the only other build which failed, right? I suspect that I don't know. The GitLab job is configured in three stages so if something early fails we don't wait forever to fail. The Azure job is over at https://dev.azure.com/u-boot/u-boot/_build/results?buildId=2792=results and hasn't completed but doesn't look like it's showing anything you haven't already fixed. > there is some other bug in xtfpga linker script, that it missed > specifying wildcard sections and this change
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wednesday 01 September 2021 23:44:52 Pali Rohár wrote: > On Wednesday 01 September 2021 17:33:57 Tom Rini wrote: > > On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote: > > > On Wednesday 01 September 2021 17:17:06 Tom Rini wrote: > > > > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > > > > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > > > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > > > > > > > > > Including timestamp.h (either directly or transitionally) cause > > > > > > > build > > > > > > > system to recompile binaries at every 'make' run. This has > > > > > > > disadvantage > > > > > > > in U-Boot development as for every small change 'make' recompiles > > > > > > > lot of > > > > > > > other irrelevant files which were not touched / changed. > > > > > > > > > > > > > > This patch series eliminate transitional / indirect usage of > > > > > > > timestamp.h by removing unneeded inclusion of header files, moving > > > > > > > timestamp values from macros to global variables, etc... > > > > > > > > > > > > > > After these patches, U-Boot tools are not recompiled by every > > > > > > > 'make' run, > > > > > > > which decrease time for incremental U-Boot recompilation. > > > > > > > > > > > > > > Please test these patches, specially m68k and powerpc parts as I > > > > > > > do not > > > > > > > have any of these boards. > > > > > > > > > > > > > > Patch series depend on this patch (now marked as accepted): > > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > > > > > > > > > Pali Rohár (11): > > > > > > > Remove #include from files which do not need it > > > > > > > Remove #include from files which do not need it > > > > > > > efi_loader: Use directly version_string variable > > > > > > > version: Move version_string[] from version.h to > > > > > > > version_string.h > > > > > > > m68k: mcf: Remove overloading version_string > > > > > > > version: Put version_string[] variable into section > > > > > > > .text_version_string > > > > > > > powerpc: mpc: Put U-Boot version string at correct place by > > > > > > > linker > > > > > > > script > > > > > > > version: Do not make version_string[] variable as a weak > > > > > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug > > > > > > > log > > > > > > > version: Remove global macro U_BOOT_VERSION_STRING from > > > > > > > version.h > > > > > > > Remove including timestamp.h in version.h > > > > > > > > > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > > > > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > > > > > doc/develop/ci_testing.rst we document how to run a world build. > > > > > > Please > > > > > > fix these build errors and re-submit, thanks. > > > > > > > > > > Already happened about month ago > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > > > > > > > > > As stated, following build command now passes: > > > > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > > > > > > > > OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... > > > > > > I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and > > > this should be fixed above patch. At least I got similar error for > > > MCR3000_defconfig with new gcc before that. > > > > > > But now after scrolling down I see that second xtfpga error > > > https://source.denx.de/u-boot/u-boot/-/jobs/316614 > > > But seems that in this UI is error log truncated. I see only > > > > > > +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA > > > [fe021584,fe0215c7] overlaps section .u_boot_list LMA > > > [fe021584,fe021e6b] > > > > > > Is there a way how to show full build log? And which defconfig and > > > compiler is used? Because that error does not help me what is wrong > > > here... > > > > That's the full error log, from the linker, I believe. It's the xtfpga > > config for the xtensa architecture. It's one of the few that buildman > > won't fetch a good toolchain for so you'll want to look at > > tools/docker/Dockerfile and see we get it from > > https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz > > if you don't have the CI builder container itself handy already. > > So this is the only other build which failed, right? I suspect that > there is some other bug in xtfpga linker script, that it missed > specifying wildcard sections and this change triggered it. > > I will try to look at it. Just a quick look... https://source.denx.de/u-boot/u-boot/-/blob/master/arch/xtensa/cpu/u-boot.lds#L78 Probably it is needed to specify .text_version_string section here, like is specified .text section there. > It is pity that in above gitlab build log is missing full
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wednesday 01 September 2021 17:33:57 Tom Rini wrote: > On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote: > > On Wednesday 01 September 2021 17:17:06 Tom Rini wrote: > > > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > > > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > > > > > > > Including timestamp.h (either directly or transitionally) cause > > > > > > build > > > > > > system to recompile binaries at every 'make' run. This has > > > > > > disadvantage > > > > > > in U-Boot development as for every small change 'make' recompiles > > > > > > lot of > > > > > > other irrelevant files which were not touched / changed. > > > > > > > > > > > > This patch series eliminate transitional / indirect usage of > > > > > > timestamp.h by removing unneeded inclusion of header files, moving > > > > > > timestamp values from macros to global variables, etc... > > > > > > > > > > > > After these patches, U-Boot tools are not recompiled by every > > > > > > 'make' run, > > > > > > which decrease time for incremental U-Boot recompilation. > > > > > > > > > > > > Please test these patches, specially m68k and powerpc parts as I do > > > > > > not > > > > > > have any of these boards. > > > > > > > > > > > > Patch series depend on this patch (now marked as accepted): > > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > > > > > > > Pali Rohár (11): > > > > > > Remove #include from files which do not need it > > > > > > Remove #include from files which do not need it > > > > > > efi_loader: Use directly version_string variable > > > > > > version: Move version_string[] from version.h to version_string.h > > > > > > m68k: mcf: Remove overloading version_string > > > > > > version: Put version_string[] variable into section > > > > > > .text_version_string > > > > > > powerpc: mpc: Put U-Boot version string at correct place by linker > > > > > > script > > > > > > version: Do not make version_string[] variable as a weak > > > > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > > > > > > version: Remove global macro U_BOOT_VERSION_STRING from version.h > > > > > > Remove including timestamp.h in version.h > > > > > > > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > > > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > > > > doc/develop/ci_testing.rst we document how to run a world build. > > > > > Please > > > > > fix these build errors and re-submit, thanks. > > > > > > > > Already happened about month ago > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > > > > > > > As stated, following build command now passes: > > > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > > > > > > OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... > > > > I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and > > this should be fixed above patch. At least I got similar error for > > MCR3000_defconfig with new gcc before that. > > > > But now after scrolling down I see that second xtfpga error > > https://source.denx.de/u-boot/u-boot/-/jobs/316614 > > But seems that in this UI is error log truncated. I see only > > > > +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA > > [fe021584,fe0215c7] overlaps section .u_boot_list LMA > > [fe021584,fe021e6b] > > > > Is there a way how to show full build log? And which defconfig and > > compiler is used? Because that error does not help me what is wrong > > here... > > That's the full error log, from the linker, I believe. It's the xtfpga > config for the xtensa architecture. It's one of the few that buildman > won't fetch a good toolchain for so you'll want to look at > tools/docker/Dockerfile and see we get it from > https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz > if you don't have the CI builder container itself handy already. So this is the only other build which failed, right? I suspect that there is some other bug in xtfpga linker script, that it missed specifying wildcard sections and this change triggered it. I will try to look at it. It is pity that in above gitlab build log is missing full command which produced that error as in its arguments could be something interesting, like path to linker script or compile flags...
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 03:30:59PM +0200, Michael Walle wrote: > Am 2021-09-01 14:57, schrieb Vladimir Oltean: > > On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote: > > > Am 2021-09-01 14:21, schrieb Vladimir Oltean: > > > > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: > > > > > Am 2021-09-01 13:55, schrieb Vladimir Oltean: > > > > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > > > > > > > Yes but that is on purpose. In the current u-boot device tree, it > > > > > > > was > > > > > > > disabled, but the boards reenabled them again. So it didn't > > > > > > > matter. > > > > > > > > > > > > > > I want to have a specific sync point (that is the v5.14 tag) for > > > > > > > the > > > > > > > .dtsi. At least where possible; for phy-mode and so on I needed > > > > > > > to to > > > > > > > take additional patches which weren't picked up in linux yet, but > > > > > > > these just affect the sl28 board device trees. > > > > > > > > > > > > Binary compatibility is one thing and I can understand it. > > > > > > Textual compatibility, down to label names, and where the device is > > > > > > being disabled from? H, I'm having a hard time saying yes to > > > > > > that. > > > > > > > > > > It's a step back, yes. But only until v5.16 (I don't think the changes > > > > > will make it during the merge window). I guess you are concerned > > > > > because > > > > > of your vendor fork? Mh, well actually I don't understand your > > > > > concert, > > > > > because your tree isn't compatible anyway if we change the labels. > > > > > > > > No, I don't care about "our vendor fork", it's been years since I've > > > > stopped using that. > > > > > > > > > We'd trade the clear information where the device tree is from for > > > > > something that - in my opinion - is not worth it. I mean the device > > > > > tree (source) is used just here in u-boot for these three boards and > > > > > all have the usb nodes enabled. > > > > > > > > My concern was actually much simpler: your v1 conversion of the label > > > > names was buggy (see the LS1028A-QDS build breakage). You deleted a > > > > bunch of comments which U-Boot had but Linux did not (luckily they did > > > > not provide a lot of useful information anyway). You introduced some > > > > comments which do not make sense for the U-Boot tree, because they were > > > > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader > > > > (you can instead say that "we will fix these up for the operating > > > > system"). > > > > Again, not big issues, but if it would boil down to my common sense, > > > > I'd focus more on the binary compatibility (after all, there will still > > > > be U-Boot specifics, which will constitute textual differences, but > > > > Linux will gladly ignore them, because this is what binary compatibility > > > > is about), and if it is preferable to have status = 'disabled' in the > > > > dtsi, and a patch was already sent to Linux but not yet accepted, I > > > > would have kept U-Boot the way it was, and follow a model of > > > > "eventual consistency". > > > > > > > > If you still care more about textual consistency, I went through the > > > > patches > > > > once already, so it's not like changing things now will make things > > > > easier, > > > > or matter. > > > > > > Ok, I see. But shouldn't be the goal to make things easy and just copy > > > the device tree to u-boot once in a while? Otherwise, we will > > > eventually > > > end up in the same mess as it is right now. Because well if they are > > > different anyway, then "we can just add another small thing right here > > > and there". > > > > So if we "just add another small thing here and there", where that thing > > is a comment, or a 'status = "disabled"' structured differently but to > > the same result, does that land us in the "same mess" where half of the > > peripherals, and networking, would not work in Linux with the U-Boot > > provided DT? > > I said eventually. My fear is that otherwise it will slowly diverge > again, because nobody really cares to keep them in sync. It doesn't have to, especially if we get things in proper sync now. There's a number of platforms that do regularly re-sync with the kernel. It's also something that with a bit of CI work, we could also make sure doesn't regress as well. But that'll take some binding documentation work to start with, along with updating / adding bindings upstream too. But again, just doing an every kernel release re-sync to keep things together is quite doable. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 12:29, schrieb Vladimir Oltean:
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
- pcie1: pcie@340 {
- compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
"snps,dw-pcie";
- reg = <0x00 0x0340 0x0 0x8
- 0x00 0x0348 0x0 0x4 /* lut
registers */
- 0x00 0x034c 0x0 0x4 /* pf controls
registers */
- 0x80 0x 0x0 0x2>; /*
configuration space */
- reg-names = "dbi", "lut", "ctrl", "config";
- #address-cells = <3>;
- #size-cells = <2>;
- device_type = "pci";
- num-lanes = <4>;
- bus-range = <0x0 0xff>;
- ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
0x0001 /* downstream I/O */
- 0x8200 0x0 0x4000 0x80 0x4000 0x0 0x4000>; /*
non-prefetchable memory */
- };
+ pcie1: pcie@340 {
+ compatible = "fsl,ls1028a-pcie";
+ reg = <0x00 0x0340 0x0 0x0010>, /* controller
registers */
+ <0x80 0x 0x0 0x2000>; /*
configuration space */
This doesn't look good, the conversion is lossy. The Linux driver
(drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
compatible string, but the U-Boot driver
(drivers/pci/pcie_layerscape_rc.c)
calls fdt_get_named_resource("lut"). I don't think that the driver
works with a NULL pcie->lut pointer? The StreamID writes in
fdt_fixup_pcie_device_ls probably didn't explode because I don't have
any PCIe card plugged in.
I guess it didn't probe anyway, because there is no driver for that
compatible string ;)
Similar thing for the PEX PF control memory region. In the LS1028A RM,
technically this is part of the larger PEX_LUT memory map, just
starting
from the 4_0014h offset.
U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
but it seems that it needs to be extended to cover LS1028A:
Only that one probably don't want to overwrite cfg_res.start and
cfg_res.end.
/*
* Fix the pcie memory map address and PF control registers address
* for LS2088A series SoCs
*/
svr = get_svr();
svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
svr == SVR_LS2048A || svr == SVR_LS2044A ||
svr == SVR_LS2081A || svr == SVR_LS2041A) {
pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
LS2088A_PCIE_PHYS_SIZE * pcie->idx;
pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
pcie->ctrl = pcie->lut + 0x4;
}
Oh the horror! Why didn't one just change the config register value in
the (u-boot) device tree instead of overwriting the value for some
specific SoCs.
As for pcie->lut itself, simplest would be to just default to what is
now the "dbi" reg value, plus a .lut_offset determined by compatible
string, in the case of "fsl,ls1028a-pcie" 0x8, just like Linux.
Ah, and not to mention that the reg-names are not even the same between
U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
Well and there is a big-endian property, which of course is set for any
Layerscape but the LS1028A. linux has instead just one endianess, but
use a shift offset.
Mh, I'm for sure not going to fix all these hacks in there. I'm thinking
about bascially branching to a different probe for the ls1028a based on
the compatible string (or rather if .data is set or not).
-michael
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wed, Sep 01, 2021 at 11:28:54PM +0200, Pali Rohár wrote: > On Wednesday 01 September 2021 17:17:06 Tom Rini wrote: > > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > > > > > Including timestamp.h (either directly or transitionally) cause build > > > > > system to recompile binaries at every 'make' run. This has > > > > > disadvantage > > > > > in U-Boot development as for every small change 'make' recompiles lot > > > > > of > > > > > other irrelevant files which were not touched / changed. > > > > > > > > > > This patch series eliminate transitional / indirect usage of > > > > > timestamp.h by removing unneeded inclusion of header files, moving > > > > > timestamp values from macros to global variables, etc... > > > > > > > > > > After these patches, U-Boot tools are not recompiled by every 'make' > > > > > run, > > > > > which decrease time for incremental U-Boot recompilation. > > > > > > > > > > Please test these patches, specially m68k and powerpc parts as I do > > > > > not > > > > > have any of these boards. > > > > > > > > > > Patch series depend on this patch (now marked as accepted): > > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > > > > > Pali Rohár (11): > > > > > Remove #include from files which do not need it > > > > > Remove #include from files which do not need it > > > > > efi_loader: Use directly version_string variable > > > > > version: Move version_string[] from version.h to version_string.h > > > > > m68k: mcf: Remove overloading version_string > > > > > version: Put version_string[] variable into section > > > > > .text_version_string > > > > > powerpc: mpc: Put U-Boot version string at correct place by linker > > > > > script > > > > > version: Do not make version_string[] variable as a weak > > > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > > > > > version: Remove global macro U_BOOT_VERSION_STRING from version.h > > > > > Remove including timestamp.h in version.h > > > > > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > > > doc/develop/ci_testing.rst we document how to run a world build. Please > > > > fix these build errors and re-submit, thanks. > > > > > > Already happened about month ago > > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > > > > > As stated, following build command now passes: > > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > > > > OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... > > I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and > this should be fixed above patch. At least I got similar error for > MCR3000_defconfig with new gcc before that. > > But now after scrolling down I see that second xtfpga error > https://source.denx.de/u-boot/u-boot/-/jobs/316614 > But seems that in this UI is error log truncated. I see only > > +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA > [fe021584,fe0215c7] overlaps section .u_boot_list LMA > [fe021584,fe021e6b] > > Is there a way how to show full build log? And which defconfig and > compiler is used? Because that error does not help me what is wrong > here... That's the full error log, from the linker, I believe. It's the xtfpga config for the xtensa architecture. It's one of the few that buildman won't fetch a good toolchain for so you'll want to look at tools/docker/Dockerfile and see we get it from https://github.com/foss-xtensa/toolchain/releases/download/2020.07/x86_64-2020.07-xtensa-dc233c-elf.tar.gz if you don't have the CI builder container itself handy already. -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wednesday 01 September 2021 17:17:06 Tom Rini wrote: > On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > > > Including timestamp.h (either directly or transitionally) cause build > > > > system to recompile binaries at every 'make' run. This has disadvantage > > > > in U-Boot development as for every small change 'make' recompiles lot of > > > > other irrelevant files which were not touched / changed. > > > > > > > > This patch series eliminate transitional / indirect usage of > > > > timestamp.h by removing unneeded inclusion of header files, moving > > > > timestamp values from macros to global variables, etc... > > > > > > > > After these patches, U-Boot tools are not recompiled by every 'make' > > > > run, > > > > which decrease time for incremental U-Boot recompilation. > > > > > > > > Please test these patches, specially m68k and powerpc parts as I do not > > > > have any of these boards. > > > > > > > > Patch series depend on this patch (now marked as accepted): > > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > > > Pali Rohár (11): > > > > Remove #include from files which do not need it > > > > Remove #include from files which do not need it > > > > efi_loader: Use directly version_string variable > > > > version: Move version_string[] from version.h to version_string.h > > > > m68k: mcf: Remove overloading version_string > > > > version: Put version_string[] variable into section > > > > .text_version_string > > > > powerpc: mpc: Put U-Boot version string at correct place by linker > > > > script > > > > version: Do not make version_string[] variable as a weak > > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > > > > version: Remove global macro U_BOOT_VERSION_STRING from version.h > > > > Remove including timestamp.h in version.h > > > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > > doc/develop/ci_testing.rst we document how to run a world build. Please > > > fix these build errors and re-submit, thanks. > > > > Already happened about month ago > > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > > > As stated, following build command now passes: > > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin > > OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... I saw only error https://source.denx.de/u-boot/u-boot/-/jobs/316601 and this should be fixed above patch. At least I got similar error for MCR3000_defconfig with new gcc before that. But now after scrolling down I see that second xtfpga error https://source.denx.de/u-boot/u-boot/-/jobs/316614 But seems that in this UI is error log truncated. I see only +xtensa-dc233c-elf-ld.bfd: section .text_version_string LMA [fe021584,fe0215c7] overlaps section .u_boot_list LMA [fe021584,fe021e6b] Is there a way how to show full build log? And which defconfig and compiler is used? Because that error does not help me what is wrong here...
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wed, Sep 01, 2021 at 11:05:45PM +0200, Pali Rohár wrote: > On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > > > Including timestamp.h (either directly or transitionally) cause build > > > system to recompile binaries at every 'make' run. This has disadvantage > > > in U-Boot development as for every small change 'make' recompiles lot of > > > other irrelevant files which were not touched / changed. > > > > > > This patch series eliminate transitional / indirect usage of > > > timestamp.h by removing unneeded inclusion of header files, moving > > > timestamp values from macros to global variables, etc... > > > > > > After these patches, U-Boot tools are not recompiled by every 'make' run, > > > which decrease time for incremental U-Boot recompilation. > > > > > > Please test these patches, specially m68k and powerpc parts as I do not > > > have any of these boards. > > > > > > Patch series depend on this patch (now marked as accepted): > > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > > > Pali Rohár (11): > > > Remove #include from files which do not need it > > > Remove #include from files which do not need it > > > efi_loader: Use directly version_string variable > > > version: Move version_string[] from version.h to version_string.h > > > m68k: mcf: Remove overloading version_string > > > version: Put version_string[] variable into section > > > .text_version_string > > > powerpc: mpc: Put U-Boot version string at correct place by linker > > > script > > > version: Do not make version_string[] variable as a weak > > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > > > version: Remove global macro U_BOOT_VERSION_STRING from version.h > > > Remove including timestamp.h in version.h > > > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > > this fails to build for at least qemu-ppce500 and xtfpga. Over in > > doc/develop/ci_testing.rst we document how to run a world build. Please > > fix these build errors and re-submit, thanks. > > Already happened about month ago > https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ > > As stated, following build command now passes: > make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin OK, I'll make sure to grab that. Note that xtfpga isn't PowerPC... -- Tom signature.asc Description: PGP signature
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Wednesday 01 September 2021 16:59:09 Tom Rini wrote: > On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > > > Including timestamp.h (either directly or transitionally) cause build > > system to recompile binaries at every 'make' run. This has disadvantage > > in U-Boot development as for every small change 'make' recompiles lot of > > other irrelevant files which were not touched / changed. > > > > This patch series eliminate transitional / indirect usage of > > timestamp.h by removing unneeded inclusion of header files, moving > > timestamp values from macros to global variables, etc... > > > > After these patches, U-Boot tools are not recompiled by every 'make' run, > > which decrease time for incremental U-Boot recompilation. > > > > Please test these patches, specially m68k and powerpc parts as I do not > > have any of these boards. > > > > Patch series depend on this patch (now marked as accepted): > > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > > > Pali Rohár (11): > > Remove #include from files which do not need it > > Remove #include from files which do not need it > > efi_loader: Use directly version_string variable > > version: Move version_string[] from version.h to version_string.h > > m68k: mcf: Remove overloading version_string > > version: Put version_string[] variable into section > > .text_version_string > > powerpc: mpc: Put U-Boot version string at correct place by linker > > script > > version: Do not make version_string[] variable as a weak > > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > > version: Remove global macro U_BOOT_VERSION_STRING from version.h > > Remove including timestamp.h in version.h > > So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 > this fails to build for at least qemu-ppce500 and xtfpga. Over in > doc/develop/ci_testing.rst we document how to run a world build. Please > fix these build errors and re-submit, thanks. Already happened about month ago https://patchwork.ozlabs.org/project/uboot/patch/20210808112038.7942-1-p...@kernel.org/ As stated, following build command now passes: make CROSS_COMPILE=powerpc-linux-gnu- MCR3000_defconfig u-boot.bin
Re: [PATCH 00/11] Reduce usage of timestamp macros
On Mon, Aug 02, 2021 at 03:18:27PM +0200, Pali Rohár wrote: > Including timestamp.h (either directly or transitionally) cause build > system to recompile binaries at every 'make' run. This has disadvantage > in U-Boot development as for every small change 'make' recompiles lot of > other irrelevant files which were not touched / changed. > > This patch series eliminate transitional / indirect usage of > timestamp.h by removing unneeded inclusion of header files, moving > timestamp values from macros to global variables, etc... > > After these patches, U-Boot tools are not recompiled by every 'make' run, > which decrease time for incremental U-Boot recompilation. > > Please test these patches, specially m68k and powerpc parts as I do not > have any of these boards. > > Patch series depend on this patch (now marked as accepted): > http://patchwork.ozlabs.org/project/uboot/patch/20210710111001.32325-1-p...@kernel.org/ > > Pali Rohár (11): > Remove #include from files which do not need it > Remove #include from files which do not need it > efi_loader: Use directly version_string variable > version: Move version_string[] from version.h to version_string.h > m68k: mcf: Remove overloading version_string > version: Put version_string[] variable into section > .text_version_string > powerpc: mpc: Put U-Boot version string at correct place by linker > script > version: Do not make version_string[] variable as a weak > x86: quark: MRC: Remove U_BOOT_DATE and U_BOOT_TIME from debug log > version: Remove global macro U_BOOT_VERSION_STRING from version.h > Remove including timestamp.h in version.h So, looking at https://source.denx.de/u-boot/u-boot/-/pipelines/8948 this fails to build for at least qemu-ppce500 and xtfpga. Over in doc/develop/ci_testing.rst we document how to run a world build. Please fix these build errors and re-submit, thanks. -- Tom signature.asc Description: PGP signature
[PATCH V2] colibri-imx7: move CONFIG_BOOTCOMMAND from header to defconfig
From: Ming Liu
Move CONFIG_BOOTCOMMAND definition from colibri_imx7.h to
colibri_imx7_defconfig, to be more flexible, for instance, it could
be overridden by merge_config.sh script.
Signed-off-by: Ming Liu
---
configs/colibri_imx7_defconfig | 3 ++-
include/configs/colibri_imx7.h | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 39149167e0..74d452246b 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -14,7 +14,8 @@ CONFIG_IMX_HAB=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
CONFIG_BOOTDELAY=1
-# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run ubiboot || run distro_bootcmd;"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="setenv fdtfile ${soc}-colibri-${fdt_board}.dtb "
# CONFIG_CONSOLE_MUX is not set
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index 2fffaa39c0..f663865156 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -117,8 +117,6 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
#if defined(CONFIG_TARGET_COLIBRI_IMX7_NAND)
-#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
- "run distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
UBI_BOOTCMD
--
2.29.0
[PATCH V2] colibri-imx6ull: move CONFIG_BOOTCOMMAND from header to defconfig
From: Ming Liu
Move CONFIG_BOOTCOMMAND definition from colibri-imx6ull.h to
colibri-imx6ull_defconfig, to be more flexible, for instance, it could
be overridden by merge_config.sh script.
Signed-off-by: Ming Liu
---
configs/colibri-imx6ull_defconfig | 3 ++-
include/configs/colibri-imx6ull.h | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/configs/colibri-imx6ull_defconfig
b/configs/colibri-imx6ull_defconfig
index 739eea7c07..7269e75a3d 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -14,7 +14,8 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri-imx6ull/imximage.cfg,IMX_NAND"
CONFIG_BOOTDELAY=1
-# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run ubiboot || run distro_bootcmd;"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="setenv fdtfile imx6ull-colibri${variant}-${fdt_board}.dtb"
# CONFIG_CONSOLE_MUX is not set
diff --git a/include/configs/colibri-imx6ull.h
b/include/configs/colibri-imx6ull.h
index 2fa3485173..304f88d8d7 100644
--- a/include/configs/colibri-imx6ull.h
+++ b/include/configs/colibri-imx6ull.h
@@ -66,9 +66,6 @@
"ubi read ${fdt_addr_r} dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
-/* Run Distro Boot script if ubiboot fails */
-#define CONFIG_BOOTCOMMAND "run ubiboot || run distro_bootcmd;"
-
#define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
func(USB, usb, 0) \
--
2.29.0
Re: [PATCH 10/10] stm32mp1: spl: Copy optee nodes to target FDT for OP-TEE payloads
Hi Patrick,
On 8/31/21 12:24 PM, Patrick DELAUNAY wrote:
Hi,
On 8/26/21 11:42 PM, Alexandru Gagniuc wrote:
OP-TEE does not take a devicetree for its own use. However, it does
pass the devicetree to the normal world OS. In most cases that will
be some other devicetree-bearing platform, such as linux.
As in other cases where there's an OPTEE payload (e.g. BOOTM_OPTEE),
it is required to copy the optee nodes to he target's FDT. Do this as
part of spl_board_prepare_for_optee().
Signed-off-by: Alexandru Gagniuc
---
arch/arm/mach-stm32mp/spl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
index d9fdc5926c..94fbb45cf9 100644
--- a/arch/arm/mach-stm32mp/spl.c
+++ b/arch/arm/mach-stm32mp/spl.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
u32 spl_boot_device(void)
{
@@ -182,6 +183,7 @@ void stm32_init_tzc_for_optee(void)
void spl_board_prepare_for_optee(void *fdt)
{
stm32_fdt_setup_mac_addr(fdt);
+ optee_copy_fdt_nodes(fdt);
stm32_init_tzc_for_optee();
}
NAK the OP-TEE nodes are ADDED by the OP-TEE firmware in the unsecure
device tree (when CFG_DT is activated)
before to jump to the kernel (that remove the need to have DT
allignement with U-Boot SPL device tree)
=> SPL should not copy the OP-TEE nodes in next stage DT
reference in optee_os = core/arch/arm/kernel/boot.c: add_optee_dt_node()
add_optee_dt_node() <= update_external_dt() <= paged_init_primary()
It is the expected configuration for OP-TEE on STM32MP15 platform.
I agree that if a component modifies the platform, it should be
responsible for updating the devicetree. Two issues though
1. Consistency
The STM32IMAGE boot path expects u-boot to add the optee nodes, while
the FIP path expects OP-TEE to add the nodes. Which one do we stick to?
2. Memory access
I don't understand is how OP-TEE would get past the TZC.
If we look at optee_os => plat-0stm32mp1/plat_tzc400:
"Early boot stage is in charge of configuring memory regions"
The following memory has been set up by SPL (or TF-A for that matter):
Nonsec: c000->ddff
Sec:de00->dfdf
SHMEM: dfe0->dfff
The external DTB will be in the nonsec region, which OP-TEE allegedly
can't access. So how would this get patched?
Alex
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 13:27, schrieb Vladimir Oltean:
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
sata: sata@320 {
compatible = "fsl,ls1028a-ahci";
- reg = <0x0 0x320 0x0 0x1 /* ccsr sata base
*/
- 0x7 0x100520 0x0 0x4>; /* ecc
sata addr*/
- reg-names = "sata-base", "ecc-addr";
+ reg = <0x0 0x320 0x0 0x1>,
+ <0x7 0x100520 0x0 0x4>;
+ reg-names = "ahci", "sata-ecc";
Again, same problem. The drivers/ata/sata_ceva.c driver calls
dev_read_resource_byname(dev, "ecc-addr") (but not for "sata-base",
apparently).
If you don't want to convert all occurrences of "ecc-addr" to
"sata-ecc", then at least add a fallback call to
dev_read_resource_byname.
This is also missing proper bindings documentation in linux :(
I guess it's safe to assume the current linux device tree binding
is the correct one.
-michael
Re: [PATCH v2] lib: fix typos in Kconfig
On 9/1/21 3:05 PM, Oleksandr Suvorov wrote:
There are trivial typos in the Kconfig file. Fixed them.
Also, fixed grammar in the descriptions with typos.
Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and
CMD_UBIFS")
Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
Signed-off-by: Oleksandr Suvorov
Reviewed-by: Bin Meng
Reviewed: Heinrich Schuchardt
---
Changes in v2:
- fix grammar as well (thanks to Heinrich Schuchardt )
lib/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index c535147aea..57be30661e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -478,7 +478,7 @@ config LZMA
config LZO
bool "Enable LZO decompression support"
help
- This enables support for LZO compression algorithm.r
+ This enables support for the LZO compression algorithm.
config GZIP
bool "Enable gzip decompression support"
@@ -537,7 +537,7 @@ config SPL_GZIP
bool "Enable gzip decompression support for SPL build"
select SPL_ZLIB
help
- This enables support for GZIP compression altorithm for SPL boot.
+ This enables support for the GZIP compression algorithm for SPL boot.
config SPL_ZLIB
bool
Re: [[PATCH] colibri-imx6ull: move CONFIG_BOOTCOMMAND from header to defconfig
On Wed, 2021-09-01 at 16:33 +0200, liu.min...@gmail.com wrote:
> From: Ming Liu
Please note that we do have a patch set introducing Colibri iMX6ULL 1GB (eMMC)
support [1] in-flight and you
likely would need to re-base on top of that one. Thanks!
[1] https://marc.info/?l=u-boot=162911970822560
> Move CONFIG_BOOTCOMMAND definition from colibri-imx6ull.h to
> colibri-imx6ull_defconfig, to be more flexible, for instance, it could
> be overridden by merge_config.sh script.
>
> Signed-off-by: Ming Liu
> ---
> configs/colibri-imx6ull_defconfig | 3 ++-
> include/configs/colibri-imx6ull.h | 3 ---
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/configs/colibri-imx6ull_defconfig
> b/configs/colibri-imx6ull_defconfig
> index 739eea7c07..17e3aa65f9 100644
> --- a/configs/colibri-imx6ull_defconfig
> +++ b/configs/colibri-imx6ull_defconfig
> @@ -14,7 +14,8 @@ CONFIG_DISTRO_DEFAULTS=y
> CONFIG_FIT=y
>
> CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri-imx6ull/imximage.cfg,IMX_NAND"
> CONFIG_BOOTDELAY=1
> -# CONFIG_USE_BOOTCOMMAND is not set
> +CONFIG_USE_BOOTCOMMAND=y
> +CONFIG_BOOTCOMMAND="run ubiboot; echo; echo ubiboot failed; run
> distro_bootcmd;"
> CONFIG_USE_PREBOOT=y
> CONFIG_PREBOOT="setenv fdtfile imx6ull-colibri${variant}-${fdt_board}.dtb"
> # CONFIG_CONSOLE_MUX is not set
> diff --git a/include/configs/colibri-imx6ull.h
> b/include/configs/colibri-imx6ull.h
> index 2fa3485173..304f88d8d7 100644
> --- a/include/configs/colibri-imx6ull.h
> +++ b/include/configs/colibri-imx6ull.h
> @@ -66,9 +66,6 @@
> "ubi read ${fdt_addr_r} dtb && " \
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
> -/* Run Distro Boot script if ubiboot fails */
> -#define CONFIG_BOOTCOMMAND "run ubiboot || run distro_bootcmd;"
> -
> #define BOOT_TARGET_DEVICES(func) \
> func(MMC, mmc, 0) \
> func(USB, usb, 0) \
[[PATCH] colibri-imx7: move CONFIG_BOOTCOMMAND from header to defconfig
From: Ming Liu
Move CONFIG_BOOTCOMMAND definition from colibri_imx7.h to
colibri_imx7_defconfig, to be more flexible, for instance, it could
be overridden by merge_config.sh script.
Signed-off-by: Ming Liu
---
configs/colibri_imx7_defconfig | 3 ++-
include/configs/colibri_imx7.h | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 39149167e0..03536b43f7 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -14,7 +14,8 @@ CONFIG_IMX_HAB=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri_imx7/imximage.cfg,MX7D"
CONFIG_BOOTDELAY=1
-# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run ubiboot; echo; echo ubiboot failed; run
distro_bootcmd;"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="setenv fdtfile ${soc}-colibri-${fdt_board}.dtb "
# CONFIG_CONSOLE_MUX is not set
diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h
index 2fffaa39c0..f663865156 100644
--- a/include/configs/colibri_imx7.h
+++ b/include/configs/colibri_imx7.h
@@ -117,8 +117,6 @@
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
#if defined(CONFIG_TARGET_COLIBRI_IMX7_NAND)
-#define CONFIG_BOOTCOMMAND "run ubiboot ; echo ; echo ubiboot failed ; " \
- "run distro_bootcmd;"
#define MODULE_EXTRA_ENV_SETTINGS \
"mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
UBI_BOOTCMD
--
2.29.0
[[PATCH] colibri-imx6ull: move CONFIG_BOOTCOMMAND from header to defconfig
From: Ming Liu
Move CONFIG_BOOTCOMMAND definition from colibri-imx6ull.h to
colibri-imx6ull_defconfig, to be more flexible, for instance, it could
be overridden by merge_config.sh script.
Signed-off-by: Ming Liu
---
configs/colibri-imx6ull_defconfig | 3 ++-
include/configs/colibri-imx6ull.h | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/configs/colibri-imx6ull_defconfig
b/configs/colibri-imx6ull_defconfig
index 739eea7c07..17e3aa65f9 100644
--- a/configs/colibri-imx6ull_defconfig
+++ b/configs/colibri-imx6ull_defconfig
@@ -14,7 +14,8 @@ CONFIG_DISTRO_DEFAULTS=y
CONFIG_FIT=y
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/toradex/colibri-imx6ull/imximage.cfg,IMX_NAND"
CONFIG_BOOTDELAY=1
-# CONFIG_USE_BOOTCOMMAND is not set
+CONFIG_USE_BOOTCOMMAND=y
+CONFIG_BOOTCOMMAND="run ubiboot; echo; echo ubiboot failed; run
distro_bootcmd;"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="setenv fdtfile imx6ull-colibri${variant}-${fdt_board}.dtb"
# CONFIG_CONSOLE_MUX is not set
diff --git a/include/configs/colibri-imx6ull.h
b/include/configs/colibri-imx6ull.h
index 2fa3485173..304f88d8d7 100644
--- a/include/configs/colibri-imx6ull.h
+++ b/include/configs/colibri-imx6ull.h
@@ -66,9 +66,6 @@
"ubi read ${fdt_addr_r} dtb && " \
"run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
-/* Run Distro Boot script if ubiboot fails */
-#define CONFIG_BOOTCOMMAND "run ubiboot || run distro_bootcmd;"
-
#define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
func(USB, usb, 0) \
--
2.29.0
Re: [PATCH 4/9] mvebu: ddr: Rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE
On 01.09.21 13:29, Tom Rini wrote: On Wed, Sep 01, 2021 at 07:27:54AM +0200, Stefan Roese wrote: Hi Tom, On 31.08.21 14:43, Tom Rini wrote: On Tue, Aug 31, 2021 at 07:51:29AM +0200, Stefan Roese wrote: Hi Tom, On 21.08.21 19:50, Tom Rini wrote: We have a number of CONFIG symbols to express the fixed size of system memory. For now, rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE and adjust usage to match that CONFIG_SYS_SDRAM_SIZE expects the entire size rather than MiB. Cc: Marek Behún Cc: Stefan Roese Signed-off-by: Tom Rini --- drivers/ddr/marvell/axp/ddr3_axp.h | 4 ++-- include/configs/maxbcm.h | 4 +++- include/configs/theadorable.h | 4 +++- 3 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/ddr/marvell/axp/ddr3_axp.h b/drivers/ddr/marvell/axp/ddr3_axp.h index 270691e9bcd3..970651f87029 100644 --- a/drivers/ddr/marvell/axp/ddr3_axp.h +++ b/drivers/ddr/marvell/axp/ddr3_axp.h @@ -19,10 +19,10 @@ #define FAR_END_DIMM_ADDR 0x50 #define MAX_DIMM_ADDR 0x60 -#ifndef CONFIG_DDR_FIXED_SIZE +#ifndef CONFIG_SYS_SDRAM_SIZE #define SDRAM_CS_SIZE 0xFFF #else -#define SDRAM_CS_SIZE (CONFIG_DDR_FIXED_SIZE - 1) +#define SDRAM_CS_SIZE ((CONFIG_SYS_SDRAM_SIZE >> 10) - 1) Why are you using ">> 10" (dividing by 1024) here? Thanks, Stefan #endif #define SDRAM_CS_BASE 0x0 #define SDRAM_DIMM_SIZE 0x8000 diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h index fc2393204bec..5098f12f5425 100644 --- a/include/configs/maxbcm.h +++ b/include/configs/maxbcm.h @@ -6,6 +6,8 @@ #ifndef _CONFIG_DB_MV7846MP_GP_H #define _CONFIG_DB_MV7846MP_GP_H +#include + /* * High Level Configuration Options (easy to change) */ @@ -65,7 +67,7 @@ /* SPL related SPI defines */ /* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */ -#define CONFIG_DDR_FIXED_SIZE (1 << 20) /* 1GiB */ +#define CONFIG_SYS_SDRAM_SIZE SZ_1G OK, so before my change, SDRAM_CS_SIZE = 0xf. After my change, SDRAM_CS_SIZE = 0xf, still. #define CONFIG_BOARD_ECC_SUPPORT/* this board supports ECC */ #endif /* _CONFIG_DB_MV7846MP_GP_H */ diff --git a/include/configs/theadorable.h b/include/configs/theadorable.h index 760713d3ef87..abc48ff44ca5 100644 --- a/include/configs/theadorable.h +++ b/include/configs/theadorable.h @@ -6,6 +6,8 @@ #ifndef _CONFIG_THEADORABLE_H #define _CONFIG_THEADORABLE_H +#include + /* * High Level Configuration Options (easy to change) */ @@ -93,6 +95,6 @@ #define CONFIG_SPL_BOOTROM_SAVE (CONFIG_SPL_STACK + 4) /* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */ -#define CONFIG_DDR_FIXED_SIZE (2 << 20) /* 2GiB */ +#define CONFIG_SYS_SDRAM_SIZE SZ_2G Here, before SDRAM_CS_SIZE = 0x1f and then after SDRAM_CS_SIZE = 0x1f. This is because CONFIG_DDR_FIXED_SIZE is kilobytes and CONFIG_SYS_SDRAM_SIZE is bytes, yes? Thanks. Only if CONFIG_DDR_FIXED_SIZE / CONFIG_SYS_SDRAM_SIZE is undefined. Please see e.g. theadorable.h above. Here we have: #define CONFIG_DDR_FIXED_SIZE (2 << 20) /* 2GiB */ With this, the following will happen in ddr3_axp.h: #ifndef CONFIG_DDR_FIXED_SIZE #define SDRAM_CS_SIZE 0xFFF #else #define SDRAM_CS_SIZE (CONFIG_DDR_FIXED_SIZE - 1) #endif So SDRAM_CS_SIZE will be set to "(2 << 20) - 1". AFAICT, on Armada XP CONFIG_DDR_FIXED_SIZE is bytes and not kilobytes. I'm not follow, sorry. There's exactly two defines of CONFIG_DDR_FIXED_SIZE before this patch, neither platform also set CONFIG_SYS_SDRAM_SIZE, and they're converted to CONFIG_SYS_SDRAM_SIZE now. I did the evaluations to confirm the code is unchanged. Ah, now I see my misunderstanding. "2 << 20" is of course 2MiB and not 2GiB. I was mislead by the comment in the header. But now I'm thinking that SDRAM_CS_SIZE might need to be set to the CS size in bytes and *not* in kilobytes for Armada XP. But this is a different issue which I need to investigate and perhaps follow up on. Thanks, Stefan
Re: Please pull u-boot-marvell/master
On Wed, Sep 01, 2021 at 11:24:13AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the next batch of Marvell MVEBU related patches. Here the > summary log of the most important parts: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] btrfs: Use default subvolume as filesystem root
On Sun, Aug 01, 2021 at 11:52:16PM +0300, Matwey V. Kornilov wrote: > BTRFS volume consists of a number of subvolumes which can be mounted > separately > from each other. The top-level subvolume always exists even if no subvolumes > were created manually. A subvolume can be denoted as the default subvolume > i.e. > the subvolume which is mounted by default. > > The default "default subvolume" is the top-level one, but this is far from the > common practices used in the wild. For instance, openSUSE provides an OS > snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root > filesystem is located into a separate subvolume which is "default" but not > "top-level". That means that the /boot/dtb/ directory is also located inside > this default subvolume instead of top-level one. > > However, the existing btrfs u-boot driver always uses the top-level subvolume > as the filesystem root. This behaviour 1) is inconsistent with > > mount /dev/sda1 /target > > command, which mount the default subvolume 2) leads to the issues when > /boot/dtb cannot be found properly (see the reference). > > This patch uses the default subvolume as the filesystem root to overcome > mentioned issues. > > Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656 > Signed-off-by: Matwey V. Kornilov > Reviewed-by: Qu Wenruo Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/next (watchdog related)
On Tue, Aug 31, 2021 at 05:07:33PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following watchdog related patches: > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] btrfs: Use default subvolume as filesystem root
On 2021/9/1 下午9:48, Matthias Brugger wrote:
On 01/09/2021 13:36, Tom Rini wrote:
On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote:
Hi Tom,
On 02/08/2021 01:06, Qu Wenruo wrote:
On 2021/8/2 上午4:52, Matwey V. Kornilov wrote:
BTRFS volume consists of a number of subvolumes which can be mounted separately
from each other. The top-level subvolume always exists even if no subvolumes
were created manually. A subvolume can be denoted as the default subvolume i.e.
the subvolume which is mounted by default.
The default "default subvolume" is the top-level one, but this is far from the
common practices used in the wild. For instance, openSUSE provides an OS
snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
filesystem is located into a separate subvolume which is "default" but not
"top-level". That means that the /boot/dtb/ directory is also located inside
this default subvolume instead of top-level one.
However, the existing btrfs u-boot driver always uses the top-level subvolume
as the filesystem root. This behaviour 1) is inconsistent with
mount /dev/sda1 /target
command, which mount the default subvolume 2) leads to the issues when
/boot/dtb cannot be found properly (see the reference).
I also noticed the problem in the past, but forgot to fix it
This patch uses the default subvolume as the filesystem root to overcome
mentioned issues.
Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
Signed-off-by: Matwey V. Kornilov
Reviewed-by: Qu Wenruo
I can see that this patch is marked in your patchwork queue as "Need Review /
ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart from
that we have it running on openSUSE on top of v2021.07 for some time without any
issues.
Ah, yup. Qu is one of the people I do look for to have reviewed a btrfs
patch before I apply it (and I throw things under Need Review / ACK as a
note-to-self to make sure a patch does have one, when I can expect one,
before applying, FWIW).
Would it be possible to merge this for v2021.10 or do you see any blocker here?
I think I had mentally filed it was feature not bugfix and was going to
hold off, but since you're asking, yes, I can grab it for this release.
Thanks!
It's a bugfix, as loading files from BTRFS, at least in openSUSE does not work
without it.
Just to be extra accurate, the original code always accesses subvol 5 as
the entrance point, thus for openSUSE or any other distros setting other
default subvolume, this will cause behavior difference between kernel
and u-boot, thus unable to find the correct /boot path.
This problem is cause by my rework using btrfs-progs code. All my fault.
Btrfs-progs never needs to bother the default subvolume, as it has no
way to "mount" the fs nor explore the directories/files structure.
Thus it's a regression, and I'm not sure if we should use Fixes: tag.
Just in case, the fixes tag is:
Fixes: f06bfcf54d0e ("fs: btrfs: Crossport open_ctree_fs_info() from
btrfs-progs")
Thank all guys involved in this case.
Qu
Thanks for the quick answer!
Matthias
Re: [PATCH] btrfs: Use default subvolume as filesystem root
On 01/09/2021 13:36, Tom Rini wrote: > On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote: >> Hi Tom, >> >> On 02/08/2021 01:06, Qu Wenruo wrote: >>> >>> >>> On 2021/8/2 上午4:52, Matwey V. Kornilov wrote: BTRFS volume consists of a number of subvolumes which can be mounted separately from each other. The top-level subvolume always exists even if no subvolumes were created manually. A subvolume can be denoted as the default subvolume i.e. the subvolume which is mounted by default. The default "default subvolume" is the top-level one, but this is far from the common practices used in the wild. For instance, openSUSE provides an OS snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root filesystem is located into a separate subvolume which is "default" but not "top-level". That means that the /boot/dtb/ directory is also located inside this default subvolume instead of top-level one. However, the existing btrfs u-boot driver always uses the top-level subvolume as the filesystem root. This behaviour 1) is inconsistent with mount /dev/sda1 /target command, which mount the default subvolume 2) leads to the issues when /boot/dtb cannot be found properly (see the reference). >>> >>> I also noticed the problem in the past, but forgot to fix it >>> This patch uses the default subvolume as the filesystem root to overcome mentioned issues. Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656 Signed-off-by: Matwey V. Kornilov >>> >>> Reviewed-by: Qu Wenruo >>> >> >> I can see that this patch is marked in your patchwork queue as "Need Review / >> ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart >> from >> that we have it running on openSUSE on top of v2021.07 for some time without >> any >> issues. > > Ah, yup. Qu is one of the people I do look for to have reviewed a btrfs > patch before I apply it (and I throw things under Need Review / ACK as a > note-to-self to make sure a patch does have one, when I can expect one, > before applying, FWIW). > >> Would it be possible to merge this for v2021.10 or do you see any blocker >> here? > > I think I had mentally filed it was feature not bugfix and was going to > hold off, but since you're asking, yes, I can grab it for this release. > Thanks! > It's a bugfix, as loading files from BTRFS, at least in openSUSE does not work without it. Thanks for the quick answer! Matthias
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 14:57, schrieb Vladimir Oltean: On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote: Am 2021-09-01 14:21, schrieb Vladimir Oltean: > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: > > Am 2021-09-01 13:55, schrieb Vladimir Oltean: > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > > > > Yes but that is on purpose. In the current u-boot device tree, it was > > > > disabled, but the boards reenabled them again. So it didn't matter. > > > > > > > > I want to have a specific sync point (that is the v5.14 tag) for the > > > > .dtsi. At least where possible; for phy-mode and so on I needed to to > > > > take additional patches which weren't picked up in linux yet, but > > > > these just affect the sl28 board device trees. > > > > > > Binary compatibility is one thing and I can understand it. > > > Textual compatibility, down to label names, and where the device is > > > being disabled from? H, I'm having a hard time saying yes to that. > > > > It's a step back, yes. But only until v5.16 (I don't think the changes > > will make it during the merge window). I guess you are concerned > > because > > of your vendor fork? Mh, well actually I don't understand your > > concert, > > because your tree isn't compatible anyway if we change the labels. > > No, I don't care about "our vendor fork", it's been years since I've > stopped using that. > > > We'd trade the clear information where the device tree is from for > > something that - in my opinion - is not worth it. I mean the device > > tree (source) is used just here in u-boot for these three boards and > > all have the usb nodes enabled. > > My concern was actually much simpler: your v1 conversion of the label > names was buggy (see the LS1028A-QDS build breakage). You deleted a > bunch of comments which U-Boot had but Linux did not (luckily they did > not provide a lot of useful information anyway). You introduced some > comments which do not make sense for the U-Boot tree, because they were > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader > (you can instead say that "we will fix these up for the operating > system"). > Again, not big issues, but if it would boil down to my common sense, > I'd focus more on the binary compatibility (after all, there will still > be U-Boot specifics, which will constitute textual differences, but > Linux will gladly ignore them, because this is what binary compatibility > is about), and if it is preferable to have status = 'disabled' in the > dtsi, and a patch was already sent to Linux but not yet accepted, I > would have kept U-Boot the way it was, and follow a model of > "eventual consistency". > > If you still care more about textual consistency, I went through the > patches > once already, so it's not like changing things now will make things > easier, > or matter. Ok, I see. But shouldn't be the goal to make things easy and just copy the device tree to u-boot once in a while? Otherwise, we will eventually end up in the same mess as it is right now. Because well if they are different anyway, then "we can just add another small thing right here and there". So if we "just add another small thing here and there", where that thing is a comment, or a 'status = "disabled"' structured differently but to the same result, does that land us in the "same mess" where half of the peripherals, and networking, would not work in Linux with the U-Boot provided DT? I said eventually. My fear is that otherwise it will slowly diverge again, because nobody really cares to keep them in sync. Like once, I've tried to make the sl28 board dts look the same in u-boot and linux, but as soon as I saw how different they were, I just changed it like u-boot was expecting it. IMHO it's the small things that get bigger and bigger. I suspect the device tree for the LS1028A looked very similar in linux and u-boot in the beginning. It's just that the main development was going on in linux and nobody cared to bring that back into u-boot. Until there is something severly different we should have a greater goal to keep things the same and for uboot specifics we have -u-boot.dtsi. It's not that device trees are changed very often once there is has binding documentation. My larger point was that if we now swing in the opposite direction, and can't make a common-sense decision before making it in Linux first, and then waiting for the next merge window, that's.. strange? That's not what I have in mind. No one is keeping you sending the patch to both. Or maybe just to u-boot but you'd have to keep in mind that it might be lost on a next sync if you didn't care to bring it into linux - or if changes were suggested in linux, you'd need to adapt u-boot afterwards. -michael
[PATCH v2] lib: fix typos in Kconfig
There are trivial typos in the Kconfig file. Fixed them.
Also, fixed grammar in the descriptions with typos.
Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and
CMD_UBIFS")
Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
Signed-off-by: Oleksandr Suvorov
Reviewed-by: Bin Meng
---
Changes in v2:
- fix grammar as well (thanks to Heinrich Schuchardt )
lib/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/Kconfig b/lib/Kconfig
index c535147aea..57be30661e 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -478,7 +478,7 @@ config LZMA
config LZO
bool "Enable LZO decompression support"
help
- This enables support for LZO compression algorithm.r
+ This enables support for the LZO compression algorithm.
config GZIP
bool "Enable gzip decompression support"
@@ -537,7 +537,7 @@ config SPL_GZIP
bool "Enable gzip decompression support for SPL build"
select SPL_ZLIB
help
- This enables support for GZIP compression altorithm for SPL boot.
+ This enables support for the GZIP compression algorithm for SPL boot.
config SPL_ZLIB
bool
--
2.31.1
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wed, Sep 01, 2021 at 02:46:09PM +0200, Pali Rohár wrote:
> On Wednesday 01 September 2021 08:41:10 Tom Rini wrote:
> > On Wed, Sep 01, 2021 at 02:40:21PM +0200, Pali Rohár wrote:
> > > On Wednesday 01 September 2021 08:35:33 Tom Rini wrote:
> > > > On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> > > > > On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > > > > > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> > > > > >
> > > > > > > Hi Pali,
> > > > > > >
> > > > > > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > > > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro,
> > > > > > > > define
> > > > > > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock
> > > > > > > > value which is
> > > > > > > > read from latched reset register.
> > > > > > > >
> > > > > > > > Replace all usages of get_ref_clk() function by this
> > > > > > > > CONFIG_SYS_REF_CLK
> > > > > > > > macro and completely remove get_ref_clk() function.
> > > > > > > >
> > > > > > > > Replace also custom open-coded implementation of determining
> > > > > > > > reference
> > > > > > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > > > > > >
> > > > > > > > The only difference is that macro CONFIG_SYS_REF_CLK returns
> > > > > > > > base reference
> > > > > > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > > > > > >
> > > > > > > > Signed-off-by: Pali Rohár
> > > > > > > >
> > > > > > > > ---
> > > > > > > > Changes in v2:
> > > > > > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK
> > > > > > > > macros
> > > > > > >
> > > > > > > This patch does not apply any more, with all the other patches
> > > > > > > applied.
> > > > > > > Please wait a bit until these patches are included in master and
> > > > > > > then
> > > > > > > send a new version.
> > > > > > >
> > > > > > > Sorry for the trouble.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Stefan
> > > > > > >
> > > > > > > > ---
> > > > > > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > > > > >
> > > > > > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > > > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > > > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > > > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > > > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > > > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > > > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > > index 7702028ba19b..bdf8dc377528 100644
> > > > > > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > > @@ -23,12 +23,6 @@
> > > > > > > > /* Armada 3700 */
> > > > > > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > > > > > (MVEBU_REGISTER(0x13800))
> > > > > > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE
> > > > > > > > + 0x8)
> > > > > > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > > > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > > > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > > > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > > > > > -
> > > > > > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE
> > > > > > > > + 0x40)
> > > > > > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > > > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > > > > > */
> > > > > > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM,
> > > > > > > > MVEBU_NB_WARM_RST_REG);
> > > > > > > > }
> > > > > > > > -
> > > > > > > > -/*
> > > > > > > > - * get_ref_clk
> > > > > > > > - *
> > > > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > > > - */
> > > > > > > > -u32 get_ref_clk(void)
> > > > > > > > -{
> > > > > > > > - u32 regval;
> > > > > > > > -
> > > > > > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) &
> > > > > > > > MVEBU_XTAL_MODE_MASK) >>
> > > > > > > > - MVEBU_XTAL_MODE_OFFS;
> > > > > > > > -
> > > > > > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > > > > > - return 25;
> > > > > > > > - else
> > > > > > > > - return 40;
> > > > > > > > -}
> > > > > > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > > index 79858858c259..9b8907e0fe55 100644
> > > > > > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > > > > > /* A3700 PCIe regions
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 02:38:15PM +0200, Michael Walle wrote: > Am 2021-09-01 14:21, schrieb Vladimir Oltean: > > On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: > > > Am 2021-09-01 13:55, schrieb Vladimir Oltean: > > > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > > > > > Yes but that is on purpose. In the current u-boot device tree, it was > > > > > disabled, but the boards reenabled them again. So it didn't matter. > > > > > > > > > > I want to have a specific sync point (that is the v5.14 tag) for the > > > > > .dtsi. At least where possible; for phy-mode and so on I needed to to > > > > > take additional patches which weren't picked up in linux yet, but > > > > > these just affect the sl28 board device trees. > > > > > > > > Binary compatibility is one thing and I can understand it. > > > > Textual compatibility, down to label names, and where the device is > > > > being disabled from? H, I'm having a hard time saying yes to that. > > > > > > It's a step back, yes. But only until v5.16 (I don't think the changes > > > will make it during the merge window). I guess you are concerned > > > because > > > of your vendor fork? Mh, well actually I don't understand your > > > concert, > > > because your tree isn't compatible anyway if we change the labels. > > > > No, I don't care about "our vendor fork", it's been years since I've > > stopped using that. > > > > > We'd trade the clear information where the device tree is from for > > > something that - in my opinion - is not worth it. I mean the device > > > tree (source) is used just here in u-boot for these three boards and > > > all have the usb nodes enabled. > > > > My concern was actually much simpler: your v1 conversion of the label > > names was buggy (see the LS1028A-QDS build breakage). You deleted a > > bunch of comments which U-Boot had but Linux did not (luckily they did > > not provide a lot of useful information anyway). You introduced some > > comments which do not make sense for the U-Boot tree, because they were > > in Linux: the ICIDs in the iommu-map being fixed up by the bootloader > > (you can instead say that "we will fix these up for the operating > > system"). > > Again, not big issues, but if it would boil down to my common sense, > > I'd focus more on the binary compatibility (after all, there will still > > be U-Boot specifics, which will constitute textual differences, but > > Linux will gladly ignore them, because this is what binary compatibility > > is about), and if it is preferable to have status = 'disabled' in the > > dtsi, and a patch was already sent to Linux but not yet accepted, I > > would have kept U-Boot the way it was, and follow a model of > > "eventual consistency". > > > > If you still care more about textual consistency, I went through the > > patches > > once already, so it's not like changing things now will make things > > easier, > > or matter. > > Ok, I see. But shouldn't be the goal to make things easy and just copy > the device tree to u-boot once in a while? Otherwise, we will eventually > end up in the same mess as it is right now. Because well if they are > different anyway, then "we can just add another small thing right here > and there". So if we "just add another small thing here and there", where that thing is a comment, or a 'status = "disabled"' structured differently but to the same result, does that land us in the "same mess" where half of the peripherals, and networking, would not work in Linux with the U-Boot provided DT? > So yes, if you mean that by textual consistency, I care about that. Okay. > And about the lost/wrong comments. We should "fix"/add/reword them in > linux, no? In the case of SMMU ICIDs, it is a matter of perspective (bootloader vs kernel). If the phrasing is generic enough to cover both perspectives, I've no problem. In this case, after the initial reaction, I might even be ok with the current phrasing of "/* fixed up by bootloader */". It is not very clarifying, but not outright wrong either. My larger point was that if we now swing in the opposite direction, and can't make a common-sense decision before making it in Linux first, and then waiting for the next merge window, that's.. strange? Anyway, quite a storm in a teacup.
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wed, Sep 01, 2021 at 08:41:10AM -0400, Tom Rini wrote:
> On Wed, Sep 01, 2021 at 02:40:21PM +0200, Pali Rohár wrote:
> > On Wednesday 01 September 2021 08:35:33 Tom Rini wrote:
> > > On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> > > > On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > > > > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> > > > >
> > > > > > Hi Pali,
> > > > > >
> > > > > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro,
> > > > > > > define
> > > > > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock
> > > > > > > value which is
> > > > > > > read from latched reset register.
> > > > > > >
> > > > > > > Replace all usages of get_ref_clk() function by this
> > > > > > > CONFIG_SYS_REF_CLK
> > > > > > > macro and completely remove get_ref_clk() function.
> > > > > > >
> > > > > > > Replace also custom open-coded implementation of determining
> > > > > > > reference
> > > > > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > > > > >
> > > > > > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > > > > > reference
> > > > > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > > > > >
> > > > > > > Signed-off-by: Pali Rohár
> > > > > > >
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK
> > > > > > > macros
> > > > > >
> > > > > > This patch does not apply any more, with all the other patches
> > > > > > applied.
> > > > > > Please wait a bit until these patches are included in master and
> > > > > > then
> > > > > > send a new version.
> > > > > >
> > > > > > Sorry for the trouble.
> > > > > >
> > > > > > Thanks,
> > > > > > Stefan
> > > > > >
> > > > > > > ---
> > > > > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > > > >
> > > > > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > index 7702028ba19b..bdf8dc377528 100644
> > > > > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > @@ -23,12 +23,6 @@
> > > > > > > /* Armada 3700 */
> > > > > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > > > > (MVEBU_REGISTER(0x13800))
> > > > > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE
> > > > > > > + 0x8)
> > > > > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > > > > -
> > > > > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE
> > > > > > > + 0x40)
> > > > > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > > > >*/
> > > > > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM,
> > > > > > > MVEBU_NB_WARM_RST_REG);
> > > > > > > }
> > > > > > > -
> > > > > > > -/*
> > > > > > > - * get_ref_clk
> > > > > > > - *
> > > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > > - */
> > > > > > > -u32 get_ref_clk(void)
> > > > > > > -{
> > > > > > > - u32 regval;
> > > > > > > -
> > > > > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK)
> > > > > > > >>
> > > > > > > - MVEBU_XTAL_MODE_OFFS;
> > > > > > > -
> > > > > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > > > > - return 25;
> > > > > > > - else
> > > > > > > - return 40;
> > > > > > > -}
> > > > > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > index 79858858c259..9b8907e0fe55 100644
> > > > > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > > > > /* A3700 PCIe regions fixer for device tree */
> > > > > > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > > > > > -/*
> > > > > > > - * get_ref_clk
> > > > > > > - *
> > > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > > - */
> > > > > > > -u32 get_ref_clk(void);
> > > > > > > -
> > > > > > > #endif
Re: [PATCH] lib: fix typos in Kconfig
Hello Heinrich,
On Tue, Aug 31, 2021 at 8:01 PM Heinrich Schuchardt wrote:
>
>
>
> On 8/31/21 1:58 PM, Oleksandr Suvorov wrote:
> > There are trivial typos in the Kconfig file. Fix them.
> >
> > Fixes: d56b4b1974 ("configs: Migrate RBTREE, LZO, CMD_MTDPARTS, CMD_UBI and
> > CMD_UBIFS")
> > Fixes: 7264f2928b ("spl: fit: Eanble GZIP support for image decompression")
> > Signed-off-by: Oleksandr Suvorov
> > ---
> >
> > lib/Kconfig | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index c535147aea..d8f312f37e 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -478,7 +478,7 @@ config LZMA
> > config LZO
> > bool "Enable LZO decompression support"
> > help
> > - This enables support for LZO compression algorithm.r
> > + This enables support for LZO compression algorithm.
>
> %s/for LZO/for the LZO/
>
> >
> > config GZIP
> > bool "Enable gzip decompression support"
> > @@ -537,7 +537,7 @@ config SPL_GZIP
> > bool "Enable gzip decompression support for SPL build"
> > select SPL_ZLIB
> > help
> > - This enables support for GZIP compression altorithm for SPL boot.
> > + This enables support for GZIP compression algorithm for SPL boot.
>
> %s/for GZIP/for the GZIP/
Thanks, you're right. If we change typos, we can fix grammar in these
strings as well :)
>
> Best regards
>
> Heinrich
>
> >
> > config SPL_ZLIB
> > bool
> >
--
Best regards
Oleksandr
Oleksandr Suvorov
cryo...@gmail.com
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wednesday 01 September 2021 08:41:10 Tom Rini wrote:
> On Wed, Sep 01, 2021 at 02:40:21PM +0200, Pali Rohár wrote:
> > On Wednesday 01 September 2021 08:35:33 Tom Rini wrote:
> > > On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> > > > On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > > > > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> > > > >
> > > > > > Hi Pali,
> > > > > >
> > > > > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro,
> > > > > > > define
> > > > > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock
> > > > > > > value which is
> > > > > > > read from latched reset register.
> > > > > > >
> > > > > > > Replace all usages of get_ref_clk() function by this
> > > > > > > CONFIG_SYS_REF_CLK
> > > > > > > macro and completely remove get_ref_clk() function.
> > > > > > >
> > > > > > > Replace also custom open-coded implementation of determining
> > > > > > > reference
> > > > > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > > > > >
> > > > > > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > > > > > reference
> > > > > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > > > > >
> > > > > > > Signed-off-by: Pali Rohár
> > > > > > >
> > > > > > > ---
> > > > > > > Changes in v2:
> > > > > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK
> > > > > > > macros
> > > > > >
> > > > > > This patch does not apply any more, with all the other patches
> > > > > > applied.
> > > > > > Please wait a bit until these patches are included in master and
> > > > > > then
> > > > > > send a new version.
> > > > > >
> > > > > > Sorry for the trouble.
> > > > > >
> > > > > > Thanks,
> > > > > > Stefan
> > > > > >
> > > > > > > ---
> > > > > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > > > >
> > > > > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > index 7702028ba19b..bdf8dc377528 100644
> > > > > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > > @@ -23,12 +23,6 @@
> > > > > > > /* Armada 3700 */
> > > > > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > > > > (MVEBU_REGISTER(0x13800))
> > > > > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE
> > > > > > > + 0x8)
> > > > > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > > > > -
> > > > > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE
> > > > > > > + 0x40)
> > > > > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > > > >*/
> > > > > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM,
> > > > > > > MVEBU_NB_WARM_RST_REG);
> > > > > > > }
> > > > > > > -
> > > > > > > -/*
> > > > > > > - * get_ref_clk
> > > > > > > - *
> > > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > > - */
> > > > > > > -u32 get_ref_clk(void)
> > > > > > > -{
> > > > > > > - u32 regval;
> > > > > > > -
> > > > > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK)
> > > > > > > >>
> > > > > > > - MVEBU_XTAL_MODE_OFFS;
> > > > > > > -
> > > > > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > > > > - return 25;
> > > > > > > - else
> > > > > > > - return 40;
> > > > > > > -}
> > > > > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > index 79858858c259..9b8907e0fe55 100644
> > > > > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > > > > /* A3700 PCIe regions fixer for device tree */
> > > > > > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > > > > > -/*
> > > > > > > - * get_ref_clk
> > > > > > > - *
> > > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > > - */
> > > > > > > -u32 get_ref_clk(void);
> > > > > > > -
> > > > > > > #endif /*
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wed, Sep 01, 2021 at 02:40:21PM +0200, Pali Rohár wrote:
> On Wednesday 01 September 2021 08:35:33 Tom Rini wrote:
> > On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> > > On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > > > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> > > >
> > > > > Hi Pali,
> > > > >
> > > > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro,
> > > > > > define
> > > > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value
> > > > > > which is
> > > > > > read from latched reset register.
> > > > > >
> > > > > > Replace all usages of get_ref_clk() function by this
> > > > > > CONFIG_SYS_REF_CLK
> > > > > > macro and completely remove get_ref_clk() function.
> > > > > >
> > > > > > Replace also custom open-coded implementation of determining
> > > > > > reference
> > > > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > > > >
> > > > > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > > > > reference
> > > > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > > > >
> > > > > > Signed-off-by: Pali Rohár
> > > > > >
> > > > > > ---
> > > > > > Changes in v2:
> > > > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK
> > > > > > macros
> > > > >
> > > > > This patch does not apply any more, with all the other patches
> > > > > applied.
> > > > > Please wait a bit until these patches are included in master and then
> > > > > send a new version.
> > > > >
> > > > > Sorry for the trouble.
> > > > >
> > > > > Thanks,
> > > > > Stefan
> > > > >
> > > > > > ---
> > > > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > > >
> > > > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > index 7702028ba19b..bdf8dc377528 100644
> > > > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > > @@ -23,12 +23,6 @@
> > > > > > /* Armada 3700 */
> > > > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > > > (MVEBU_REGISTER(0x13800))
> > > > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE
> > > > > > + 0x8)
> > > > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > > > -
> > > > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE
> > > > > > + 0x40)
> > > > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > > > */
> > > > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
> > > > > > }
> > > > > > -
> > > > > > -/*
> > > > > > - * get_ref_clk
> > > > > > - *
> > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > - */
> > > > > > -u32 get_ref_clk(void)
> > > > > > -{
> > > > > > - u32 regval;
> > > > > > -
> > > > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK)
> > > > > > >>
> > > > > > - MVEBU_XTAL_MODE_OFFS;
> > > > > > -
> > > > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > > > - return 25;
> > > > > > - else
> > > > > > - return 40;
> > > > > > -}
> > > > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > index 79858858c259..9b8907e0fe55 100644
> > > > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > > > /* A3700 PCIe regions fixer for device tree */
> > > > > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > > > > -/*
> > > > > > - * get_ref_clk
> > > > > > - *
> > > > > > - * return: reference clock in MHz (25 or 40)
> > > > > > - */
> > > > > > -u32 get_ref_clk(void);
> > > > > > -
> > > > > > #endif /* __ASSEMBLY__ */
> > > > > > #endif /* _MVEBU_CPU_H */
> > > > > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > > b/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > > index aab61f7c15cf..b03b6de3c6cd 100644
> > > > > > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > >
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wednesday 01 September 2021 08:35:33 Tom Rini wrote:
> On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> > On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> > >
> > > > Hi Pali,
> > > >
> > > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro, define
> > > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value
> > > > > which is
> > > > > read from latched reset register.
> > > > >
> > > > > Replace all usages of get_ref_clk() function by this
> > > > > CONFIG_SYS_REF_CLK
> > > > > macro and completely remove get_ref_clk() function.
> > > > >
> > > > > Replace also custom open-coded implementation of determining reference
> > > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > > >
> > > > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > > > reference
> > > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > > >
> > > > > Signed-off-by: Pali Rohár
> > > > >
> > > > > ---
> > > > > Changes in v2:
> > > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK macros
> > > >
> > > > This patch does not apply any more, with all the other patches applied.
> > > > Please wait a bit until these patches are included in master and then
> > > > send a new version.
> > > >
> > > > Sorry for the trouble.
> > > >
> > > > Thanks,
> > > > Stefan
> > > >
> > > > > ---
> > > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > index 7702028ba19b..bdf8dc377528 100644
> > > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > > @@ -23,12 +23,6 @@
> > > > > /* Armada 3700 */
> > > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > > (MVEBU_REGISTER(0x13800))
> > > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE
> > > > > + 0x8)
> > > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > > -
> > > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE
> > > > > + 0x40)
> > > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > >*/
> > > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
> > > > > }
> > > > > -
> > > > > -/*
> > > > > - * get_ref_clk
> > > > > - *
> > > > > - * return: reference clock in MHz (25 or 40)
> > > > > - */
> > > > > -u32 get_ref_clk(void)
> > > > > -{
> > > > > - u32 regval;
> > > > > -
> > > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK)
> > > > > >>
> > > > > - MVEBU_XTAL_MODE_OFFS;
> > > > > -
> > > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > > - return 25;
> > > > > - else
> > > > > - return 40;
> > > > > -}
> > > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > index 79858858c259..9b8907e0fe55 100644
> > > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > > /* A3700 PCIe regions fixer for device tree */
> > > > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > > > -/*
> > > > > - * get_ref_clk
> > > > > - *
> > > > > - * return: reference clock in MHz (25 or 40)
> > > > > - */
> > > > > -u32 get_ref_clk(void);
> > > > > -
> > > > > #endif /* __ASSEMBLY__ */
> > > > > #endif /* _MVEBU_CPU_H */
> > > > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > b/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > index aab61f7c15cf..b03b6de3c6cd 100644
> > > > > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> > > > > @@ -210,6 +210,12 @@
> > > > > #define BOOT_FROM_SPI 0x3
> > > > > #define CONFIG_SYS_TCLK 25000 /* 250MHz */
> > > > > +#elif defined(CONFIG_ARMADA_3700)
> > > > > +/* SAR values for Armada 3700 */
> > > > > +#define MVEBU_TEST_PIN_LATCH_N
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 14:21, schrieb Vladimir Oltean: On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: Am 2021-09-01 13:55, schrieb Vladimir Oltean: > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > > Yes but that is on purpose. In the current u-boot device tree, it was > > disabled, but the boards reenabled them again. So it didn't matter. > > > > I want to have a specific sync point (that is the v5.14 tag) for the > > .dtsi. At least where possible; for phy-mode and so on I needed to to > > take additional patches which weren't picked up in linux yet, but > > these just affect the sl28 board device trees. > > Binary compatibility is one thing and I can understand it. > Textual compatibility, down to label names, and where the device is > being disabled from? H, I'm having a hard time saying yes to that. It's a step back, yes. But only until v5.16 (I don't think the changes will make it during the merge window). I guess you are concerned because of your vendor fork? Mh, well actually I don't understand your concert, because your tree isn't compatible anyway if we change the labels. No, I don't care about "our vendor fork", it's been years since I've stopped using that. We'd trade the clear information where the device tree is from for something that - in my opinion - is not worth it. I mean the device tree (source) is used just here in u-boot for these three boards and all have the usb nodes enabled. My concern was actually much simpler: your v1 conversion of the label names was buggy (see the LS1028A-QDS build breakage). You deleted a bunch of comments which U-Boot had but Linux did not (luckily they did not provide a lot of useful information anyway). You introduced some comments which do not make sense for the U-Boot tree, because they were in Linux: the ICIDs in the iommu-map being fixed up by the bootloader (you can instead say that "we will fix these up for the operating system"). Again, not big issues, but if it would boil down to my common sense, I'd focus more on the binary compatibility (after all, there will still be U-Boot specifics, which will constitute textual differences, but Linux will gladly ignore them, because this is what binary compatibility is about), and if it is preferable to have status = 'disabled' in the dtsi, and a patch was already sent to Linux but not yet accepted, I would have kept U-Boot the way it was, and follow a model of "eventual consistency". If you still care more about textual consistency, I went through the patches once already, so it's not like changing things now will make things easier, or matter. Ok, I see. But shouldn't be the goal to make things easy and just copy the device tree to u-boot once in a while? Otherwise, we will eventually end up in the same mess as it is right now. Because well if they are different anyway, then "we can just add another small thing right here and there". So yes, if you mean that by textual consistency, I care about that. And about the lost/wrong comments. We should "fix"/add/reword them in linux, no? -michael
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wed, Sep 01, 2021 at 02:32:43PM +0200, Pali Rohár wrote:
> On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> > On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> >
> > > Hi Pali,
> > >
> > > On 16.08.21 12:02, Pali Rohár wrote:
> > > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro, define
> > > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value
> > > > which is
> > > > read from latched reset register.
> > > >
> > > > Replace all usages of get_ref_clk() function by this CONFIG_SYS_REF_CLK
> > > > macro and completely remove get_ref_clk() function.
> > > >
> > > > Replace also custom open-coded implementation of determining reference
> > > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > > >
> > > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > > reference
> > > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > > >
> > > > Signed-off-by: Pali Rohár
> > > >
> > > > ---
> > > > Changes in v2:
> > > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK macros
> > >
> > > This patch does not apply any more, with all the other patches applied.
> > > Please wait a bit until these patches are included in master and then
> > > send a new version.
> > >
> > > Sorry for the trouble.
> > >
> > > Thanks,
> > > Stefan
> > >
> > > > ---
> > > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > index 7702028ba19b..bdf8dc377528 100644
> > > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > > @@ -23,12 +23,6 @@
> > > > /* Armada 3700 */
> > > > #define MVEBU_GPIO_NB_REG_BASE
> > > > (MVEBU_REGISTER(0x13800))
> > > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE + 0x8)
> > > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > > -
> > > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE + 0x40)
> > > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > > > */
> > > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
> > > > }
> > > > -
> > > > -/*
> > > > - * get_ref_clk
> > > > - *
> > > > - * return: reference clock in MHz (25 or 40)
> > > > - */
> > > > -u32 get_ref_clk(void)
> > > > -{
> > > > - u32 regval;
> > > > -
> > > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK)
> > > > >>
> > > > - MVEBU_XTAL_MODE_OFFS;
> > > > -
> > > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > > - return 25;
> > > > - else
> > > > - return 40;
> > > > -}
> > > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > index 79858858c259..9b8907e0fe55 100644
> > > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > > /* A3700 PCIe regions fixer for device tree */
> > > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > > -/*
> > > > - * get_ref_clk
> > > > - *
> > > > - * return: reference clock in MHz (25 or 40)
> > > > - */
> > > > -u32 get_ref_clk(void);
> > > > -
> > > > #endif /* __ASSEMBLY__ */
> > > > #endif /* _MVEBU_CPU_H */
> > > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > b/arch/arm/mach-mvebu/include/mach/soc.h
> > > > index aab61f7c15cf..b03b6de3c6cd 100644
> > > > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > > > +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> > > > @@ -210,6 +210,12 @@
> > > > #define BOOT_FROM_SPI 0x3
> > > > #define CONFIG_SYS_TCLK 25000 /* 250MHz */
> > > > +#elif defined(CONFIG_ARMADA_3700)
> > > > +/* SAR values for Armada 3700 */
> > > > +#define MVEBU_TEST_PIN_LATCH_N MVEBU_REGISTER(0x13808)
> > > > +#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > > +#define CONFIG_SYS_REF_CLK ((readl(MVEBU_TEST_PIN_LATCH_N) &
> > > > MVEBU_XTAL_MODE_MASK) ? \
> > > > +4000 : 2500)
> >
> > NAK. CONFIG_xxx which evaluate out to a macro / function are the
> >
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wednesday 01 September 2021 08:14:10 Tom Rini wrote:
> On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
>
> > Hi Pali,
> >
> > On 16.08.21 12:02, Pali Rohár wrote:
> > > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro, define
> > > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value which
> > > is
> > > read from latched reset register.
> > >
> > > Replace all usages of get_ref_clk() function by this CONFIG_SYS_REF_CLK
> > > macro and completely remove get_ref_clk() function.
> > >
> > > Replace also custom open-coded implementation of determining reference
> > > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> > >
> > > The only difference is that macro CONFIG_SYS_REF_CLK returns base
> > > reference
> > > clock in Hz and old function get_ref_clk() returned it in MHz.
> > >
> > > Signed-off-by: Pali Rohár
> > >
> > > ---
> > > Changes in v2:
> > > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK macros
> >
> > This patch does not apply any more, with all the other patches applied.
> > Please wait a bit until these patches are included in master and then
> > send a new version.
> >
> > Sorry for the trouble.
> >
> > Thanks,
> > Stefan
> >
> > > ---
> > > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > > 8 files changed, 22 insertions(+), 50 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > index 7702028ba19b..bdf8dc377528 100644
> > > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > > @@ -23,12 +23,6 @@
> > > /* Armada 3700 */
> > > #define MVEBU_GPIO_NB_REG_BASE (MVEBU_REGISTER(0x13800))
> > > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE + 0x8)
> > > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > -#define MVEBU_XTAL_MODE_OFFS 9
> > > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > > -
> > > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE + 0x40)
> > > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > >*/
> > > writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
> > > }
> > > -
> > > -/*
> > > - * get_ref_clk
> > > - *
> > > - * return: reference clock in MHz (25 or 40)
> > > - */
> > > -u32 get_ref_clk(void)
> > > -{
> > > - u32 regval;
> > > -
> > > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK) >>
> > > - MVEBU_XTAL_MODE_OFFS;
> > > -
> > > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > > - return 25;
> > > - else
> > > - return 40;
> > > -}
> > > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > index 79858858c259..9b8907e0fe55 100644
> > > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > > /* A3700 PCIe regions fixer for device tree */
> > > int a3700_fdt_fix_pcie_regions(void *blob);
> > > -/*
> > > - * get_ref_clk
> > > - *
> > > - * return: reference clock in MHz (25 or 40)
> > > - */
> > > -u32 get_ref_clk(void);
> > > -
> > > #endif /* __ASSEMBLY__ */
> > > #endif /* _MVEBU_CPU_H */
> > > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > > b/arch/arm/mach-mvebu/include/mach/soc.h
> > > index aab61f7c15cf..b03b6de3c6cd 100644
> > > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > > +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> > > @@ -210,6 +210,12 @@
> > > #define BOOT_FROM_SPI 0x3
> > > #define CONFIG_SYS_TCLK 25000 /* 250MHz */
> > > +#elif defined(CONFIG_ARMADA_3700)
> > > +/* SAR values for Armada 3700 */
> > > +#define MVEBU_TEST_PIN_LATCH_N MVEBU_REGISTER(0x13808)
> > > +#define MVEBU_XTAL_MODE_MASK BIT(9)
> > > +#define CONFIG_SYS_REF_CLK ((readl(MVEBU_TEST_PIN_LATCH_N) &
> > > MVEBU_XTAL_MODE_MASK) ? \
> > > + 4000 : 2500)
>
> NAK. CONFIG_xxx which evaluate out to a macro / function are the
> hardest to convert to Kconfig. This patch is taking a step backwards.
> In fact, wait, how does patch apply and work? There are no
> CONFIG_SYS_REF_CLK instances today, so the build should blow up about
> adding a new non-Kconfig symbol.
So, could you please provide some other solution for this issue which
Marek and Stefan pointed?
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 02:05:34PM +0200, Michael Walle wrote: > Am 2021-09-01 13:55, schrieb Vladimir Oltean: > > On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > > > Yes but that is on purpose. In the current u-boot device tree, it was > > > disabled, but the boards reenabled them again. So it didn't matter. > > > > > > I want to have a specific sync point (that is the v5.14 tag) for the > > > .dtsi. At least where possible; for phy-mode and so on I needed to to > > > take additional patches which weren't picked up in linux yet, but > > > these just affect the sl28 board device trees. > > > > Binary compatibility is one thing and I can understand it. > > Textual compatibility, down to label names, and where the device is > > being disabled from? H, I'm having a hard time saying yes to that. > > It's a step back, yes. But only until v5.16 (I don't think the changes > will make it during the merge window). I guess you are concerned because > of your vendor fork? Mh, well actually I don't understand your concert, > because your tree isn't compatible anyway if we change the labels. No, I don't care about "our vendor fork", it's been years since I've stopped using that. > We'd trade the clear information where the device tree is from for > something that - in my opinion - is not worth it. I mean the device > tree (source) is used just here in u-boot for these three boards and > all have the usb nodes enabled. My concern was actually much simpler: your v1 conversion of the label names was buggy (see the LS1028A-QDS build breakage). You deleted a bunch of comments which U-Boot had but Linux did not (luckily they did not provide a lot of useful information anyway). You introduced some comments which do not make sense for the U-Boot tree, because they were in Linux: the ICIDs in the iommu-map being fixed up by the bootloader (you can instead say that "we will fix these up for the operating system"). Again, not big issues, but if it would boil down to my common sense, I'd focus more on the binary compatibility (after all, there will still be U-Boot specifics, which will constitute textual differences, but Linux will gladly ignore them, because this is what binary compatibility is about), and if it is preferable to have status = 'disabled' in the dtsi, and a patch was already sent to Linux but not yet accepted, I would have kept U-Boot the way it was, and follow a model of "eventual consistency". If you still care more about textual consistency, I went through the patches once already, so it's not like changing things now will make things easier, or matter.
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
On Wed, Sep 01, 2021 at 11:12:58AM +0200, Stefan Roese wrote:
> Hi Pali,
>
> On 16.08.21 12:02, Pali Rohár wrote:
> > Like for all other mvebu platforms with CONFIG_SYS_TCLK macro, define
> > CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value which is
> > read from latched reset register.
> >
> > Replace all usages of get_ref_clk() function by this CONFIG_SYS_REF_CLK
> > macro and completely remove get_ref_clk() function.
> >
> > Replace also custom open-coded implementation of determining reference
> > clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
> >
> > The only difference is that macro CONFIG_SYS_REF_CLK returns base reference
> > clock in Hz and old function get_ref_clk() returned it in MHz.
> >
> > Signed-off-by: Pali Rohár
> >
> > ---
> > Changes in v2:
> > * Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK macros
>
> This patch does not apply any more, with all the other patches applied.
> Please wait a bit until these patches are included in master and then
> send a new version.
>
> Sorry for the trouble.
>
> Thanks,
> Stefan
>
> > ---
> > arch/arm/mach-mvebu/armada3700/cpu.c | 24
> > arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
> > arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
> > drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
> > drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
> > drivers/phy/marvell/comphy_a3700.c | 12 ++--
> > drivers/serial/serial_mvebu_a3700.c| 11 ---
> > drivers/watchdog/armada-37xx-wdt.c | 2 +-
> > 8 files changed, 22 insertions(+), 50 deletions(-)
> >
> > diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
> > b/arch/arm/mach-mvebu/armada3700/cpu.c
> > index 7702028ba19b..bdf8dc377528 100644
> > --- a/arch/arm/mach-mvebu/armada3700/cpu.c
> > +++ b/arch/arm/mach-mvebu/armada3700/cpu.c
> > @@ -23,12 +23,6 @@
> > /* Armada 3700 */
> > #define MVEBU_GPIO_NB_REG_BASE(MVEBU_REGISTER(0x13800))
> > -#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE + 0x8)
> > -#define MVEBU_XTAL_MODE_MASK BIT(9)
> > -#define MVEBU_XTAL_MODE_OFFS 9
> > -#define MVEBU_XTAL_CLOCK_25MHZ 0x0
> > -#define MVEBU_XTAL_CLOCK_40MHZ 0x1
> > -
> > #define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE + 0x40)
> > #define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
> > @@ -370,21 +364,3 @@ void reset_cpu(void)
> > */
> > writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
> > }
> > -
> > -/*
> > - * get_ref_clk
> > - *
> > - * return: reference clock in MHz (25 or 40)
> > - */
> > -u32 get_ref_clk(void)
> > -{
> > - u32 regval;
> > -
> > - regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK) >>
> > - MVEBU_XTAL_MODE_OFFS;
> > -
> > - if (regval == MVEBU_XTAL_CLOCK_25MHZ)
> > - return 25;
> > - else
> > - return 40;
> > -}
> > diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> > b/arch/arm/mach-mvebu/include/mach/cpu.h
> > index 79858858c259..9b8907e0fe55 100644
> > --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> > +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> > @@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
> > /* A3700 PCIe regions fixer for device tree */
> > int a3700_fdt_fix_pcie_regions(void *blob);
> > -/*
> > - * get_ref_clk
> > - *
> > - * return: reference clock in MHz (25 or 40)
> > - */
> > -u32 get_ref_clk(void);
> > -
> > #endif /* __ASSEMBLY__ */
> > #endif /* _MVEBU_CPU_H */
> > diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
> > b/arch/arm/mach-mvebu/include/mach/soc.h
> > index aab61f7c15cf..b03b6de3c6cd 100644
> > --- a/arch/arm/mach-mvebu/include/mach/soc.h
> > +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> > @@ -210,6 +210,12 @@
> > #define BOOT_FROM_SPI 0x3
> > #define CONFIG_SYS_TCLK 25000 /* 250MHz */
> > +#elif defined(CONFIG_ARMADA_3700)
> > +/* SAR values for Armada 3700 */
> > +#define MVEBU_TEST_PIN_LATCH_N MVEBU_REGISTER(0x13808)
> > +#define MVEBU_XTAL_MODE_MASK BIT(9)
> > +#define CONFIG_SYS_REF_CLK ((readl(MVEBU_TEST_PIN_LATCH_N) &
> > MVEBU_XTAL_MODE_MASK) ? \
> > +4000 : 2500)
NAK. CONFIG_xxx which evaluate out to a macro / function are the
hardest to convert to Kconfig. This patch is taking a step backwards.
In fact, wait, how does patch apply and work? There are no
CONFIG_SYS_REF_CLK instances today, so the build should blow up about
adding a new non-Kconfig symbol.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 13:55, schrieb Vladimir Oltean: On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: Yes but that is on purpose. In the current u-boot device tree, it was disabled, but the boards reenabled them again. So it didn't matter. I want to have a specific sync point (that is the v5.14 tag) for the .dtsi. At least where possible; for phy-mode and so on I needed to to take additional patches which weren't picked up in linux yet, but these just affect the sl28 board device trees. Binary compatibility is one thing and I can understand it. Textual compatibility, down to label names, and where the device is being disabled from? H, I'm having a hard time saying yes to that. It's a step back, yes. But only until v5.16 (I don't think the changes will make it during the merge window). I guess you are concerned because of your vendor fork? Mh, well actually I don't understand your concert, because your tree isn't compatible anyway if we change the labels. We'd trade the clear information where the device tree is from for something that - in my opinion - is not worth it. I mean the device tree (source) is used just here in u-boot for these three boards and all have the usb nodes enabled. (btw I finished reviewing this patch, I have no other comments) thanks for the efforts! -michael
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 01:51:53PM +0200, Michael Walle wrote: > Yes but that is on purpose. In the current u-boot device tree, it was > disabled, but the boards reenabled them again. So it didn't matter. > > I want to have a specific sync point (that is the v5.14 tag) for the > .dtsi. At least where possible; for phy-mode and so on I needed to to > take additional patches which weren't picked up in linux yet, but > these just affect the sl28 board device trees. Binary compatibility is one thing and I can understand it. Textual compatibility, down to label names, and where the device is being disabled from? H, I'm having a hard time saying yes to that. (btw I finished reviewing this patch, I have no other comments)
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 13:24, schrieb Vladimir Oltean:
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
- usb0: usb3@310 {
- compatible = "fsl,layerscape-dwc3";
- reg = <0x0 0x310 0x0 0x1>;
- interrupts = ;
- dr_mode = "host";
- status = "disabled";
- };
-
- usb1: usb3@311 {
- compatible = "fsl,layerscape-dwc3";
- reg = <0x0 0x311 0x0 0x1>;
- interrupts = ;
- dr_mode = "host";
+ usb0: usb@310 {
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+ reg = <0x0 0x310 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ snps,dis_rxdet_inp3_quirk;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+ };
+
+ usb1: usb@311 {
+ compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
+ reg = <0x0 0x311 0x0 0x1>;
+ interrupts = ;
+ dr_mode = "host";
+ snps,dis_rxdet_inp3_quirk;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
+ };
I see the status = 'disabled' was lost in the new bindings? This is
strange considering that it is you who sent the patch to disable them
in
Linux, just yesterday:
https://lkml.org/lkml/2021/8/31/426
Yes but that is on purpose. In the current u-boot device tree, it was
disabled, but the boards reenabled them again. So it didn't matter.
I want to have a specific sync point (that is the v5.14 tag) for the
.dtsi. At least where possible; for phy-mode and so on I needed to to
take additional patches which weren't picked up in linux yet, but
these just affect the sl28 board device trees.
-michael
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Am 2021-09-01 13:43, schrieb Vladimir Oltean:
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
- pcie1: pcie@340 {
- ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
0x0001 /* downstream I/O */
- 0x8200 0x0 0x4000 0x80 0x4000 0x0 0x4000>; /*
non-prefetchable memory */
- };
- pcie2: pcie@350 {
- ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
0x0001 /* downstream I/O */
- 0x8200 0x0 0x4000 0x88 0x4000 0x0 0x4000>; /*
non-prefetchable memory */
- };
+ pcie1: pcie@340 {
+ ranges = <0x8100 0x0 0x 0x80 0x0001 0x0 0x0001
/* downstream I/O */
+ 0x8200 0x0 0x4000 0x80 0x4000 0x0 0x4000>; /*
non-prefetchable memory */
};
+ pcie2: pcie@350 {
+ ranges = <0x8100 0x0 0x 0x88 0x0001 0x0 0x0001
/* downstream I/O */
+ 0x8200 0x0 0x4000 0x88 0x4000 0x0 0x4000>; /*
non-prefetchable memory */
+ };
This change also makes an undocumented movement of the PCIe window in
the SoC memory space from 0x80_0002 to 0x80_0001 for pcie1, and
from 0x88_0002 to 0x88_0001 for pcie2.
It should probably work either way, considering that the SoC system
memory map lists the entire 32GB of address space starting from
0x0080__ as belonging to PEX1, and 0x0088__ belonging
to
PEX2, but either way, is there no better way to make these changes?!
It seems like a lot to go through. At the very least do document the
changes in the commit message, it makes you be aware of what you're
changing, and it makes people get an overview instead of needing to do
dumpster diving.
TBH, I haven't looked at PCI. Sorry. Shouldn't have rushed that patch
series.
I'll have a look at all your findinds and will make a patch for each one
so the uboot device tree and the linux device tree are similar, just
like i did for the other peripherals.
-michael
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> - pcie1: pcie@340 {
> -ranges = <0x8100 0x0 0x 0x80 0x0002
> 0x0 0x0001 /* downstream I/O */
> -0x8200 0x0 0x4000 0x80 0x4000
> 0x0 0x4000>; /* non-prefetchable memory */
> - };
>
> - pcie2: pcie@350 {
> -ranges = <0x8100 0x0 0x 0x88 0x0002
> 0x0 0x0001 /* downstream I/O */
> -0x8200 0x0 0x4000 0x88 0x4000
> 0x0 0x4000>; /* non-prefetchable memory */
> - };
> + pcie1: pcie@340 {
> + ranges = <0x8100 0x0 0x 0x80 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> };
>
> + pcie2: pcie@350 {
> + ranges = <0x8100 0x0 0x 0x88 0x0001 0x0
> 0x0001 /* downstream I/O */
> + 0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> + };
This change also makes an undocumented movement of the PCIe window in
the SoC memory space from 0x80_0002 to 0x80_0001 for pcie1, and
from 0x88_0002 to 0x88_0001 for pcie2.
It should probably work either way, considering that the SoC system
memory map lists the entire 32GB of address space starting from
0x0080__ as belonging to PEX1, and 0x0088__ belonging to
PEX2, but either way, is there no better way to make these changes?!
It seems like a lot to go through. At the very least do document the
changes in the commit message, it makes you be aware of what you're
changing, and it makes people get an overview instead of needing to do
dumpster diving.
Re: [PATCH] btrfs: Use default subvolume as filesystem root
On Wed, Sep 01, 2021 at 01:28:30PM +0200, Matthias Brugger wrote: > Hi Tom, > > On 02/08/2021 01:06, Qu Wenruo wrote: > > > > > > On 2021/8/2 上午4:52, Matwey V. Kornilov wrote: > >> BTRFS volume consists of a number of subvolumes which can be mounted > >> separately > >> from each other. The top-level subvolume always exists even if no > >> subvolumes > >> were created manually. A subvolume can be denoted as the default subvolume > >> i.e. > >> the subvolume which is mounted by default. > >> > >> The default "default subvolume" is the top-level one, but this is far from > >> the > >> common practices used in the wild. For instance, openSUSE provides an OS > >> snapshot/rollback feature based on BTRFS. To achieve this, the actual OS > >> root > >> filesystem is located into a separate subvolume which is "default" but not > >> "top-level". That means that the /boot/dtb/ directory is also located > >> inside > >> this default subvolume instead of top-level one. > >> > >> However, the existing btrfs u-boot driver always uses the top-level > >> subvolume > >> as the filesystem root. This behaviour 1) is inconsistent with > >> > >> mount /dev/sda1 /target > >> > >> command, which mount the default subvolume 2) leads to the issues when > >> /boot/dtb cannot be found properly (see the reference). > > > > I also noticed the problem in the past, but forgot to fix it > > > >> > >> This patch uses the default subvolume as the filesystem root to overcome > >> mentioned issues. > >> > >> Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656 > >> Signed-off-by: Matwey V. Kornilov > > > > Reviewed-by: Qu Wenruo > > > > I can see that this patch is marked in your patchwork queue as "Need Review / > ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart from > that we have it running on openSUSE on top of v2021.07 for some time without > any > issues. Ah, yup. Qu is one of the people I do look for to have reviewed a btrfs patch before I apply it (and I throw things under Need Review / ACK as a note-to-self to make sure a patch does have one, when I can expect one, before applying, FWIW). > Would it be possible to merge this for v2021.10 or do you see any blocker > here? I think I had mentally filed it was feature not bugfix and was going to hold off, but since you're asking, yes, I can grab it for this release. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 4/9] mvebu: ddr: Rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE
On Wed, Sep 01, 2021 at 07:27:54AM +0200, Stefan Roese wrote: > Hi Tom, > > On 31.08.21 14:43, Tom Rini wrote: > > On Tue, Aug 31, 2021 at 07:51:29AM +0200, Stefan Roese wrote: > > > Hi Tom, > > > > > > On 21.08.21 19:50, Tom Rini wrote: > > > > We have a number of CONFIG symbols to express the fixed size of system > > > > memory. For now, rename CONFIG_DDR_FIXED_SIZE to CONFIG_SYS_SDRAM_SIZE > > > > and adjust usage to match that CONFIG_SYS_SDRAM_SIZE expects the entire > > > > size rather than MiB. > > > > > > > > Cc: Marek Behún > > > > Cc: Stefan Roese > > > > Signed-off-by: Tom Rini > > > > --- > > > >drivers/ddr/marvell/axp/ddr3_axp.h | 4 ++-- > > > >include/configs/maxbcm.h | 4 +++- > > > >include/configs/theadorable.h | 4 +++- > > > >3 files changed, 8 insertions(+), 4 deletions(-) > > > > > > > > diff --git a/drivers/ddr/marvell/axp/ddr3_axp.h > > > > b/drivers/ddr/marvell/axp/ddr3_axp.h > > > > index 270691e9bcd3..970651f87029 100644 > > > > --- a/drivers/ddr/marvell/axp/ddr3_axp.h > > > > +++ b/drivers/ddr/marvell/axp/ddr3_axp.h > > > > @@ -19,10 +19,10 @@ > > > >#define FAR_END_DIMM_ADDR0x50 > > > >#define MAX_DIMM_ADDR0x60 > > > > -#ifndef CONFIG_DDR_FIXED_SIZE > > > > +#ifndef CONFIG_SYS_SDRAM_SIZE > > > >#define SDRAM_CS_SIZE0xFFF > > > >#else > > > > -#define SDRAM_CS_SIZE (CONFIG_DDR_FIXED_SIZE - 1) > > > > +#define SDRAM_CS_SIZE ((CONFIG_SYS_SDRAM_SIZE >> 10) > > > > - 1) > > > > > > Why are you using ">> 10" (dividing by 1024) here? > > > > > > Thanks, > > > Stefan > > > > > > >#endif > > > >#define SDRAM_CS_BASE0x0 > > > >#define SDRAM_DIMM_SIZE 0x8000 > > > > diff --git a/include/configs/maxbcm.h b/include/configs/maxbcm.h > > > > index fc2393204bec..5098f12f5425 100644 > > > > --- a/include/configs/maxbcm.h > > > > +++ b/include/configs/maxbcm.h > > > > @@ -6,6 +6,8 @@ > > > >#ifndef _CONFIG_DB_MV7846MP_GP_H > > > >#define _CONFIG_DB_MV7846MP_GP_H > > > > +#include > > > > + > > > >/* > > > > * High Level Configuration Options (easy to change) > > > > */ > > > > @@ -65,7 +67,7 @@ > > > >/* SPL related SPI defines */ > > > >/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */ > > > > -#define CONFIG_DDR_FIXED_SIZE (1 << 20) /* 1GiB */ > > > > +#define CONFIG_SYS_SDRAM_SIZE SZ_1G > > > > OK, so before my change, SDRAM_CS_SIZE = 0xf. After my change, > > SDRAM_CS_SIZE = 0xf, still. > > > > > >#define CONFIG_BOARD_ECC_SUPPORT /* this board supports ECC */ > > > >#endif /* _CONFIG_DB_MV7846MP_GP_H */ > > > > diff --git a/include/configs/theadorable.h > > > > b/include/configs/theadorable.h > > > > index 760713d3ef87..abc48ff44ca5 100644 > > > > --- a/include/configs/theadorable.h > > > > +++ b/include/configs/theadorable.h > > > > @@ -6,6 +6,8 @@ > > > >#ifndef _CONFIG_THEADORABLE_H > > > >#define _CONFIG_THEADORABLE_H > > > > +#include > > > > + > > > >/* > > > > * High Level Configuration Options (easy to change) > > > > */ > > > > @@ -93,6 +95,6 @@ > > > >#define CONFIG_SPL_BOOTROM_SAVE (CONFIG_SPL_STACK + 4) > > > >/* Enable DDR support in SPL (DDR3 training from Marvell bin_hdr) */ > > > > -#define CONFIG_DDR_FIXED_SIZE (2 << 20) /* 2GiB */ > > > > +#define CONFIG_SYS_SDRAM_SIZE SZ_2G > > > > Here, before SDRAM_CS_SIZE = 0x1f and then after SDRAM_CS_SIZE = > > 0x1f. > > > > This is because CONFIG_DDR_FIXED_SIZE is kilobytes and > > CONFIG_SYS_SDRAM_SIZE is bytes, yes? Thanks. > > Only if CONFIG_DDR_FIXED_SIZE / CONFIG_SYS_SDRAM_SIZE is undefined. > > Please see e.g. theadorable.h above. Here we have: > > #define CONFIG_DDR_FIXED_SIZE (2 << 20) /* 2GiB */ > > With this, the following will happen in ddr3_axp.h: > > #ifndef CONFIG_DDR_FIXED_SIZE > #define SDRAM_CS_SIZE 0xFFF > #else > #define SDRAM_CS_SIZE (CONFIG_DDR_FIXED_SIZE - 1) > #endif > > So SDRAM_CS_SIZE will be set to "(2 << 20) - 1". > > AFAICT, on Armada XP CONFIG_DDR_FIXED_SIZE is bytes and not > kilobytes. I'm not follow, sorry. There's exactly two defines of CONFIG_DDR_FIXED_SIZE before this patch, neither platform also set CONFIG_SYS_SDRAM_SIZE, and they're converted to CONFIG_SYS_SDRAM_SIZE now. I did the evaluations to confirm the code is unchanged. As an aside, I do need to get merging of Pali's series to finish reproducible builds as I could then do a before/after world build where I verify things by objdump before/after. -- Tom signature.asc Description: PGP signature
Re: [PATCH] btrfs: Use default subvolume as filesystem root
Hi Tom,
On 02/08/2021 01:06, Qu Wenruo wrote:
>
>
> On 2021/8/2 上午4:52, Matwey V. Kornilov wrote:
>> BTRFS volume consists of a number of subvolumes which can be mounted
>> separately
>> from each other. The top-level subvolume always exists even if no subvolumes
>> were created manually. A subvolume can be denoted as the default subvolume
>> i.e.
>> the subvolume which is mounted by default.
>>
>> The default "default subvolume" is the top-level one, but this is far from
>> the
>> common practices used in the wild. For instance, openSUSE provides an OS
>> snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
>> filesystem is located into a separate subvolume which is "default" but not
>> "top-level". That means that the /boot/dtb/ directory is also located inside
>> this default subvolume instead of top-level one.
>>
>> However, the existing btrfs u-boot driver always uses the top-level subvolume
>> as the filesystem root. This behaviour 1) is inconsistent with
>>
>> mount /dev/sda1 /target
>>
>> command, which mount the default subvolume 2) leads to the issues when
>> /boot/dtb cannot be found properly (see the reference).
>
> I also noticed the problem in the past, but forgot to fix it
>
>>
>> This patch uses the default subvolume as the filesystem root to overcome
>> mentioned issues.
>>
>> Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
>> Signed-off-by: Matwey V. Kornilov
>
> Reviewed-by: Qu Wenruo
>
I can see that this patch is marked in your patchwork queue as "Need Review /
ACK". Qu is one of our core btrfs developer who reviewed the patch. Apart from
that we have it running on openSUSE on top of v2021.07 for some time without any
issues.
Would it be possible to merge this for v2021.10 or do you see any blocker here?
Regards,
Matthias
> Thanks,
> Qu
>
>> ---
>> fs/btrfs/disk-io.c | 38 +++---
>> 1 file changed, 35 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>> index 349411c3cc..12f9579fcf 100644
>> --- a/fs/btrfs/disk-io.c
>> +++ b/fs/btrfs/disk-io.c
>> @@ -804,6 +804,30 @@ static int setup_root_or_create_block(struct
>> btrfs_fs_info *fs_info,
>> return 0;
>> }
>> +static int get_default_subvolume(struct btrfs_fs_info *fs_info,
>> + struct btrfs_key *key_ret)
>> +{
>> + struct btrfs_root *root = fs_info->tree_root;
>> + struct btrfs_dir_item *dir_item;
>> + struct btrfs_path path;
>> + int ret = 0;
>> +
>> + btrfs_init_path();
>> +
>> + dir_item = btrfs_lookup_dir_item(NULL, root, ,
>> + BTRFS_ROOT_TREE_DIR_OBJECTID,
>> + "default", 7, 0);
>> + if (IS_ERR(dir_item)) {
>> + ret = PTR_ERR(dir_item);
>> + goto out;
>> + }
>> +
>> + btrfs_dir_item_key_to_cpu(path.nodes[0], dir_item, key_ret);
>> +out:
>> + btrfs_release_path();
>> + return ret;
>> +}
>> +
>> int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info)
>> {
>> struct btrfs_super_block *sb = fs_info->super_copy;
>> @@ -833,9 +857,17 @@ int btrfs_setup_all_roots(struct btrfs_fs_info *fs_info)
>> fs_info->last_trans_committed = generation;
>> - key.objectid = BTRFS_FS_TREE_OBJECTID;
>> - key.type = BTRFS_ROOT_ITEM_KEY;
>> - key.offset = (u64)-1;
>> + ret = get_default_subvolume(fs_info, );
>> + if (ret) {
>> + /*
>> + * The default dir item isn't there. Linux kernel behaviour is
>> + * to silently use the top-level subvolume in this case.
>> + */
>> + key.objectid = BTRFS_FS_TREE_OBJECTID;
>> + key.type = BTRFS_ROOT_ITEM_KEY;
>> + key.offset = (u64)-1;
>> + }
>> +
>> fs_info->fs_root = btrfs_read_fs_root(fs_info, );
>> if (IS_ERR(fs_info->fs_root))
>>
>
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> sata: sata@320 {
> compatible = "fsl,ls1028a-ahci";
> - reg = <0x0 0x320 0x0 0x1/* ccsr sata
> base */
> -0x7 0x100520 0x0 0x4>; /* ecc
> sata addr*/
> - reg-names = "sata-base", "ecc-addr";
> + reg = <0x0 0x320 0x0 0x1>,
> + <0x7 0x100520 0x0 0x4>;
> + reg-names = "ahci", "sata-ecc";
Again, same problem. The drivers/ata/sata_ceva.c driver calls
dev_read_resource_byname(dev, "ecc-addr") (but not for "sata-base",
apparently).
If you don't want to convert all occurrences of "ecc-addr" to
"sata-ecc", then at least add a fallback call to dev_read_resource_byname.
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> - usb0: usb3@310 {
> - compatible = "fsl,layerscape-dwc3";
> - reg = <0x0 0x310 0x0 0x1>;
> - interrupts = ;
> - dr_mode = "host";
> - status = "disabled";
> - };
> -
> - usb1: usb3@311 {
> - compatible = "fsl,layerscape-dwc3";
> - reg = <0x0 0x311 0x0 0x1>;
> - interrupts = ;
> - dr_mode = "host";
> + usb0: usb@310 {
> + compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = ;
> + dr_mode = "host";
> + snps,dis_rxdet_inp3_quirk;
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> + };
> +
> + usb1: usb@311 {
> + compatible = "fsl,ls1028a-dwc3", "snps,dwc3";
> + reg = <0x0 0x311 0x0 0x1>;
> + interrupts = ;
> + dr_mode = "host";
> + snps,dis_rxdet_inp3_quirk;
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,incr-burst-type-adjustment = <1>, <4>, <8>, <16>;
> + };
I see the status = 'disabled' was lost in the new bindings? This is
strange considering that it is you who sent the patch to disable them in
Linux, just yesterday:
https://lkml.org/lkml/2021/8/31/426
Re: [PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
On Wed, Sep 01, 2021 at 10:55:21AM +0200, Michael Walle wrote:
> - pcie1: pcie@340 {
> -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie",
> "snps,dw-pcie";
> -reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4 /* lut
> registers */
> -0x00 0x034c 0x0 0x4 /* pf controls
> registers */
> -0x80 0x 0x0 0x2>; /*
> configuration space */
> -reg-names = "dbi", "lut", "ctrl", "config";
> -#address-cells = <3>;
> -#size-cells = <2>;
> -device_type = "pci";
> -num-lanes = <4>;
> -bus-range = <0x0 0xff>;
> -ranges = <0x8100 0x0 0x 0x80 0x0002
> 0x0 0x0001 /* downstream I/O */
> -0x8200 0x0 0x4000 0x80 0x4000
> 0x0 0x4000>; /* non-prefetchable memory */
> - };
> + pcie1: pcie@340 {
> + compatible = "fsl,ls1028a-pcie";
> + reg = <0x00 0x0340 0x0 0x0010>, /* controller
> registers */
> + <0x80 0x 0x0 0x2000>; /*
> configuration space */
This doesn't look good, the conversion is lossy. The Linux driver
(drivers/pci/controller/dwc/pci-layerscape.c) knows the lut_offset by
compatible string, but the U-Boot driver (drivers/pci/pcie_layerscape_rc.c)
calls fdt_get_named_resource("lut"). I don't think that the driver
works with a NULL pcie->lut pointer? The StreamID writes in
fdt_fixup_pcie_device_ls probably didn't explode because I don't have
any PCIe card plugged in.
Similar thing for the PEX PF control memory region. In the LS1028A RM,
technically this is part of the larger PEX_LUT memory map, just starting
from the 4_0014h offset.
U-Boot has this piece of logic to deduce pcie->ctrl based on pcie->lut,
but it seems that it needs to be extended to cover LS1028A:
/*
* Fix the pcie memory map address and PF control registers address
* for LS2088A series SoCs
*/
svr = get_svr();
svr = (svr >> SVR_VAR_PER_SHIFT) & 0xFE;
if (svr == SVR_LS2088A || svr == SVR_LS2084A ||
svr == SVR_LS2048A || svr == SVR_LS2044A ||
svr == SVR_LS2081A || svr == SVR_LS2041A) {
pcie_rc->cfg_res.start = LS2088A_PCIE1_PHYS_ADDR +
LS2088A_PCIE_PHYS_SIZE * pcie->idx;
pcie_rc->cfg_res.end = pcie_rc->cfg_res.start + cfg_size;
pcie->ctrl = pcie->lut + 0x4;
}
As for pcie->lut itself, simplest would be to just default to what is
now the "dbi" reg value, plus a .lut_offset determined by compatible
string, in the case of "fsl,ls1028a-pcie" 0x8, just like Linux.
Ah, and not to mention that the reg-names are not even the same between
U-Boot and Linux. What is "dbi" in U-Boot is "regs" in Linux :)
[PATCH 2/2] board: dh_stm32mp1: Remove gpio_hog_probe_all() from board
DM_GPIO_HOG flag has been replaced by GPIO_HOG flag since a while in
commit 49b10cb49262 ("gpio: fixes for gpio-hog support").
And furthermore, gpio_hog_probe_all() is already called in board_r.c.
So gpio_hog_probe() can be removed from stm32mp1.c.
Signed-off-by: Patrice Chotard
Cc: Marek Vasut
---
board/dhelectronics/dh_stm32mp1/board.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/dhelectronics/dh_stm32mp1/board.c
b/board/dhelectronics/dh_stm32mp1/board.c
index d7c1857c16..725b438d76 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -593,9 +593,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
- if (CONFIG_IS_ENABLED(DM_GPIO_HOG))
- gpio_hog_probe_all();
-
board_key_check();
#ifdef CONFIG_DM_REGULATOR
--
2.17.1
Re: [PATCH v2 4/9] arm: dts: ls1028a: update the labels
On Wed, Sep 01, 2021 at 10:55:17AM +0200, Michael Walle wrote: > Update the labels of the nodes to match the kernel ones. > > Signed-off-by: Michael Walle > --- Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean
Re: [PATCH v2 2/9] arm: dts: ls1028a: move devices into /soc
On Wed, Sep 01, 2021 at 10:55:15AM +0200, Michael Walle wrote:
> - fspi: flexspi@20c {
> - compatible = "nxp,lx2160a-fspi";
> - #address-cells = <1>;
> - #size-cells = <0>;
> - reg = <0x0 0x20c 0x0 0x1>,
> - <0x0 0x2000 0x0 0x1000>;
> - reg-names = "fspi_base", "fspi_mmap";
> - clocks = < 4 3>, < 4 3>;
> - clock-names = "fspi_en", "fspi";
> - interrupts = ;
> - status = "disabled";
> - };
> -
> - serial0: serial@21c0500 {
> - device_type = "serial";
> - compatible = "fsl,ns16550", "ns16550a";
> - reg = <0x0 0x21c0500 0x0 0x100>;
> - interrupts = ;
> - status = "disabled";
> - };
> -
> - serial1: serial@21c0600 {
> - device_type = "serial";
> - compatible = "fsl,ns16550", "ns16550a";
> - reg = <0x0 0x21c0600 0x0 0x100>;
> - interrupts = ;
> - status = "disabled";
> - };
> -
> - pcie1: pcie@340 {
> -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> -reg = <0x00 0x0340 0x0 0x8
> -0x00 0x0348 0x0 0x4 /* lut registers */
> -0x00 0x034c 0x0 0x4 /* pf controls registers */
> -0x80 0x 0x0 0x2>; /* configuration space */
> -reg-names = "dbi", "lut", "ctrl", "config";
> -#address-cells = <3>;
> -#size-cells = <2>;
> -device_type = "pci";
> -num-lanes = <4>;
> -bus-range = <0x0 0xff>;
> -ranges = <0x8100 0x0 0x 0x80 0x0002 0x0
> 0x0001 /* downstream I/O */
> -0x8200 0x0 0x4000 0x80 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> - };
> + soc: soc {
> + compatible = "simple-bus";
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
>
> - pcie2: pcie@350 {
> -compatible = "fsl,ls-pcie", "fsl,ls1028-pcie", "snps,dw-pcie";
> -reg = <0x00 0x0350 0x0 0x8
> -0x00 0x0358 0x0 0x4 /* lut registers */
> -0x00 0x035c 0x0 0x4 /* pf controls registers */
> -0x88 0x 0x0 0x2>; /* configuration space */
> -reg-names = "dbi", "lut", "ctrl", "config";
> -#address-cells = <3>;
> -#size-cells = <2>;
> -device_type = "pci";
> -num-lanes = <4>;
> -bus-range = <0x0 0xff>;
> -ranges = <0x8100 0x0 0x 0x88 0x0002 0x0
> 0x0001 /* downstream I/O */
> -0x8200 0x0 0x4000 0x88 0x4000 0x0
> 0x4000>; /* non-prefetchable memory */
> - };
> + clockgen: clocking@130 {
> + compatible = "fsl,ls1028a-clockgen";
> + reg = <0x0 0x130 0x0 0xa>;
> + #clock-cells = <2>;
> + clocks = <>;
> + };
>
> - pcie@1f000 {
> - compatible = "pci-host-ecam-generic";
> - /* ECAM bus 0, HW has more space reserved but not populated */
> - bus-range = <0x0 0x0>;
> - reg = <0x01 0xf000 0x0 0x10>;
> - #address-cells = <3>;
> - #size-cells = <2>;
> - device_type = "pci";
> - ranges= <0x8200 0x0 0x 0x1 0xf800 0x0 0x16>;
> - enetc0: pci@0,0 {
> - reg = <0x00 0 0 0 0>;
> + fspi: flexspi@20c {
> + compatible = "nxp,lx2160a-fspi";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x0 0x20c 0x0 0x1>,
> + <0x0 0x2000 0x0 0x1000>;
This is indented worse than where you took it from.
> + reg-names = "fspi_base", "fspi_mmap";
> + clocks = < 4 3>, < 4 3>;
> + clock-names = "fspi_en", "fspi";
> + interrupts = ;
> status = "disabled";
> };
> - enetc1: pci@0,1 {
> - reg = <0x000100 0 0 0 0>;
> +
> + serial0: serial@21c0500 {
> + device_type = "serial";
> + compatible = "fsl,ns16550", "ns16550a";
> + reg = <0x0 0x21c0500 0x0 0x100>;
> + interrupts = ;
> status = "disabled";
> };
> - enetc2: pci@0,2 {
> - reg = <0x000200 0 0 0 0>;
> - status = "disabled";
> - phy-mode = "internal";
>
> -
[PATCH 1/2] board: stm32mp1: Remove gpio_hog_probe_all() from board
DM_GPIO_HOG flag has been replaced by GPIO_HOG flag since a while in
commit 49b10cb49262 ("gpio: fixes for gpio-hog support").
And furthermore, gpio_hog_probe_all() is already called in board_r.c.
So gpio_hog_probe() can be removed from stm32mp1.c.
Signed-off-by: Patrice Chotard
---
board/st/stm32mp1/stm32mp1.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 032f08d795..b5500399e6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -649,9 +649,6 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = STM32_DDR_BASE + 0x100;
- if (CONFIG_IS_ENABLED(DM_GPIO_HOG))
- gpio_hog_probe_all();
-
board_key_check();
if (board_is_ev1())
--
2.17.1
Please pull u-boot-marvell/master
Hi Tom, please pull the next batch of Marvell MVEBU related patches. Here the summary log of the most important parts: - mvebu: a38x: Define supported UART baudrates (Pali) - kwbimage: Misc improvements (Pali) - espressobin/turris_mox/turris_omnia: Enable some more devices like SATA via PCIe, SATA & NVMe (Pali) - a37xx: Remove unused CONFIG_DEBUG_UART_SHIFT options (Pali) - turris_omnia: Disable MCU watchdog in SPL when booting over UART (Marek) - kwbimage: Fix some Coverity issue (Heinrich) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=112=results Thanks, Stefan The following changes since commit b15a17be0c75238e7bdb2c9baf0c375040d95952: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sh (2021-08-31 18:37:25 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 4116a0f38a8ba6bc5e762cd291a65df4946216e7: tools: kwbimage: Remove comment about unimplemented register headers in v1 images (2021-09-01 08:09:24 +0200) Heinrich Schuchardt (2): kwbimage: check fopen() return value kwbimage: check return value of image_get_csk_index Marek Behún (4): arm: mvebu: Move get_boot_device() to cpu.c and make visible arm: mvebu: turris_omnia: don't guard by CONFIG_SPL_BUILD macro arm: mvebu: turris_omnia: disable MCU watchdog in SPL when booting over UART arm: mvebu: turris_omnia: disable MCU watchdog in board_late_init() Pali Rohár (11): arm: mvebu: a38x: Define supported UART baudrates tools: kwbimage: Verify supported image version tools: kwbimage: Verify size of v0 image header tools: kwbimage: Verify size of image data tools: kwbimage: Use IBR_HDR_* constants instead of raw numbers arm: mvebu: axp: Properly check for Armada XP in mach/soc.h arm: mvebu: espressobin: Enable also SATA support via PCIe arm: mvebu: turris_mox: Enable SATA support arm: mvebu: turris_omnia: Enable NVMe support serial: a37xx: Remove CONFIG_DEBUG_UART_SHIFT options tools: kwbimage: Remove comment about unimplemented register headers in v1 images arch/arm/mach-mvebu/cpu.c | 60 ++ arch/arm/mach-mvebu/include/mach/cpu.h | 2 + arch/arm/mach-mvebu/include/mach/soc.h | 2 +- arch/arm/mach-mvebu/spl.c | 77 - board/CZ.NIC/turris_omnia/turris_omnia.c| 27 ++ configs/mvebu_db-88f3720_defconfig | 1 - configs/mvebu_espressobin-88f3720_defconfig | 3 +- configs/turris_mox_defconfig| 7 ++- configs/turris_omnia_defconfig | 2 + configs/uDPU_defconfig | 1 - include/configs/mv-common.h | 9 tools/kwbimage.c| 48 +++--- 12 files changed, 138 insertions(+), 101 deletions(-)
Re: [PATCH 0/3] common: Add fdt network helper
Hey Simon, On Thu, Aug 26, 2021 at 9:00 PM Tony Dinh wrote: > > Hi Simon, > > On Tue, Aug 17, 2021 at 9:09 AM Simon Glass wrote: > > > > Hi Tony, > > > > On Sun, 15 Aug 2021 at 15:28, Tony Dinh wrote: > > > > > > Hi Simon, > > > > > > On Sun, Aug 15, 2021 at 7:10 AM Simon Glass wrote: > > > > > > > > Hi Tony, > > > > > > > > On Thu, 5 Aug 2021 at 22:49, Tony Dinh wrote: > > > > > > > > > > > > > > > At the moment, there is no common fdt helper function specific to > > > > > decoding network related > > > > > information from FDTs. This new helper functional group > > > > > fdt_support_net is intended to be used > > > > > by board-specific code within U-Boot for various network related > > > > > chores. > > > > > > > > > > In this patch, create the 1st function fdt_get_phy_addr to parse the > > > > > device tree to find > > > > > the PHY addess of a specific ethernet device. > > > > > > > > > > > > > > > Tony Dinh (3): > > > > > Add fdt network helper header file > > > > > Add fdt network helper functions > > > > > Add fdt network helper to Makefile > > > > > > > > > > common/Makefile | 2 +- > > > > > common/fdt_support_net.c | 46 > > > > > +++ > > > > > include/fdt_support_net.h | 39 + > > > > > 3 files changed, 86 insertions(+), 1 deletion(-) > > > > > create mode 100644 common/fdt_support_net.c > > > > > create mode 100644 include/fdt_support_net.h > > > > > > > > Can this use livetre and also have some tests? > > > > > > I have not enabled livetree for any of the boards I have. So I just > > > modeled this using the existing ./common/fdt_support.c! > > > > > > I do agree we should start using livetree in fdt helpers, if I > > > understood it correctly, it should work for both flattree and > > > > OK good, yes that's right. > > > > > livetree. Perhaps we could have another patch series after this? I am > > > preparing another Kirkwood board support patch that I could hold off > > > submitting and enable livetree to use that as a vehicle for testing. > > > > I think it is better to use livetree in this patch. For testing, you > > can use sandbox for testing (see for example test/dm/ofnode.c) > > > > Regards, > > Simon > > It seems it is too time consuming to implement this using livetree > calls (with my limited understanding about livetree). I spent a few > hours reading ./include/dm/read.h and ./include/dm/ofnode.h, and it is > not apparent to me which functions to use. I see that we have > eth_get_dev_by_name(), that's a start. > > Do you have any objection if I submit this function as a patch to > ./common/fdt_support.c? fdt_support.c file is all flatree > implementation. And by the way, this new function fdt_get_phy_addr() > has been tested with several Kirkwood boards that I have been > converting to DM Ethernet. > > When the time comes that it's mandatory to convert all to livetree > calls, I'll be glad to help. I know you're as busy as always ;) But I would appreciate either an ACK or NACK on my proposal to submit this as a patch to ./common/fdt_support.c. Thanks, Tony
Re: [PATCH] tools: kwbimage: Remove comment about unimplemented register headers in v1 images
On 22.08.21 12:31, Pali Rohár wrote:
Support for register headers in v1 images was implemented in commit
02ba70ad6822 ("tools: kwbimage: Add support for DATA command also for v1
images"). So remove old comment.
Signed-off-by: Pali Rohár
Fixes: 02ba70ad6822 ("tools: kwbimage: Add support for DATA command also for v1
images")
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index c1269fb6633a..0b5d0e735a27 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -5,8 +5,6 @@
*
* (C) Copyright 2013 Thomas Petazzoni
*
- *
- * Not implemented: support for the register headers in v1 images
*/
#include "imagetool.h"
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/1] kwbimage: check return value of image_get_csk_index
On 17.08.21 07:11, Heinrich Schuchardt wrote:
image_get_csk_index() may return -1 in case of an error. Don't use this
value as index.
This resolves Coverity CID 338488
Memory - illegal accesses (NEGATIVE_RETURNS)
Signed-off-by: Heinrich Schuchardt
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 2a10df773b..bf7fd135ac 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1087,7 +1087,7 @@ int kwb_sign_csk_with_kak(struct image_tool_params
*params,
int csk_idx = image_get_csk_index();
struct sig_v1 tmp_sig;
- if (csk_idx >= 16) {
+ if (csk_idx < 0 || csk_idx > 15) {
fprintf(stderr, "Invalid CSK index %d\n", csk_idx);
return 1;
}
--
2.30.2
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/1] kwbimage: check fopen() return value
On 17.08.21 07:03, Heinrich Schuchardt wrote:
Always check the return value of fopen().
This resolves Coverity CID 338491:
Null pointer dereferences (NULL_RETURNS)
Signed-off-by: Heinrich Schuchardt
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 00cb338d64..2a10df773b 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -832,6 +832,12 @@ static int kwb_dump_fuse_cmds(struct secure_hdr_v1
*sec_hdr)
if (!strcmp(e->name, "a38x")) {
FILE *out = fopen("kwb_fuses_a38x.txt", "w+");
+ if (!out) {
+ fprintf(stderr, "Couldn't open eFuse settings: '%s':
%s\n",
+ "kwb_fuses_a38x.txt", strerror(errno));
+ return -ENOENT;
+ }
+
kwb_dump_fuse_cmds_38x(out, sec_hdr);
fclose(out);
goto done;
@@ -1060,6 +1066,11 @@ int export_pub_kak_hash(RSA *kak, struct secure_hdr_v1
*secure_hdr)
int res;
hashf = fopen("pub_kak_hash.txt", "w");
+ if (!hashf) {
+ fprintf(stderr, "Couldn't open hash file: '%s': %s\n",
+ "pub_kak_hash.txt", strerror(errno));
+ return 1;
+ }
res = kwb_export_pubkey(kak, _hdr->kak, hashf, "KAK");
--
2.30.2
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-mvebu v2 4/4] arm: mvebu: turris_omnia: disable MCU watchdog in board_late_init()
On 16.08.21 15:19, Marek Behún wrote:
Disable MCU watchdog in board_late_init() instead of board_init(), so
that it is disabled after U-Boot enables SOC watchdog instead of before.
This way there is no window when the board is vulnerable.
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index b0391c973d..bac78af04e 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -434,6 +434,11 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
+ return 0;
+}
+
+int board_late_init(void)
+{
/*
* If not booting from UART, MCU watchdog was not disabled in SPL,
* disable it now.
@@ -441,11 +446,6 @@ int board_init(void)
if (get_boot_device() != BOOT_DEVICE_UART)
disable_mcu_watchdog();
- return 0;
-}
-
-int board_late_init(void)
-{
set_regdomain();
handle_reset_button();
pci_init();
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-mvebu v2 3/4] arm: mvebu: turris_omnia: disable MCU watchdog in SPL when booting over UART
On 16.08.21 15:19, Marek Behún wrote:
When booting over UART, sending U-Boot proper may take too much time and
MCU watchdog will reset the board before U-Boot proper is loaded.
Better disable MCU watchdog in SPL when booting over UART.
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 17 -
configs/turris_omnia_defconfig | 1 +
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index a84a409f43..b0391c973d 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -419,12 +419,27 @@ int board_early_init_f(void)
return 0;
}
+void spl_board_init(void)
+{
+ /*
+* If booting from UART, disable MCU watchdog in SPL, since uploading
+* U-Boot proper can take too much time and trigger it.
+*/
+ if (get_boot_device() == BOOT_DEVICE_UART)
+ disable_mcu_watchdog();
+}
+
int board_init(void)
{
/* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
- disable_mcu_watchdog();
+ /*
+* If not booting from UART, MCU watchdog was not disabled in SPL,
+* disable it now.
+*/
+ if (get_boot_device() != BOOT_DEVICE_UART)
+ disable_mcu_watchdog();
return 0;
}
diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig
index cd443ceb30..67f8bdadaf 100644
--- a/configs/turris_omnia_defconfig
+++ b/configs/turris_omnia_defconfig
@@ -33,6 +33,7 @@ CONFIG_SYS_CONSOLE_INFO_QUIET=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_DISPLAY_BOARDINFO_LATE=y
CONFIG_MISC_INIT_R=y
+CONFIG_SPL_BOARD_INIT=y
CONFIG_SPL_I2C=y
CONFIG_CMD_MEMTEST=y
CONFIG_SYS_ALT_MEMTEST=y
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-mvebu v2 2/4] arm: mvebu: turris_omnia: don't guard by CONFIG_SPL_BUILD macro
On 16.08.21 15:19, Marek Behún wrote:
We do not need to guard code in board_init() and board_late_init()
functions with the CONFIG_SPL_BUILD macro, since these functions are not
called in SPL.
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 8
1 file changed, 8 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index a7e5f56eed..a84a409f43 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -129,7 +129,6 @@ static int omnia_mcu_read(u8 cmd, void *buf, int len)
return dm_i2c_read(chip, cmd, buf, len);
}
-#ifndef CONFIG_SPL_BUILD
static int omnia_mcu_write(u8 cmd, const void *buf, int len)
{
struct udevice *chip;
@@ -158,7 +157,6 @@ static bool disable_mcu_watchdog(void)
return true;
}
-#endif
static bool omnia_detect_sata(void)
{
@@ -325,7 +323,6 @@ struct mv_ddr_topology_map *mv_ddr_topology_map_get(void)
return _topology_map_1g;
}
-#ifndef CONFIG_SPL_BUILD
static int set_regdomain(void)
{
struct omnia_eeprom oep;
@@ -394,7 +391,6 @@ static void handle_reset_button(void)
}
}
}
-#endif
int board_early_init_f(void)
{
@@ -428,19 +424,15 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = mvebu_sdram_bar(0) + 0x100;
-#ifndef CONFIG_SPL_BUILD
disable_mcu_watchdog();
-#endif
return 0;
}
int board_late_init(void)
{
-#ifndef CONFIG_SPL_BUILD
set_regdomain();
handle_reset_button();
-#endif
pci_init();
return 0;
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH u-boot-mvebu v2 1/4] arm: mvebu: Move get_boot_device() to cpu.c and make visible
On 16.08.21 15:19, Marek Behún wrote:
Move the function get_boot_device() from spl.c to cpu.c.
Make it visible, so that it may be used from other files.
Signed-off-by: Marek Behún
Applied to u-boot-marvell/master
Thanks,
Stefan
---
arch/arm/mach-mvebu/cpu.c | 60
arch/arm/mach-mvebu/include/mach/cpu.h | 2 +
arch/arm/mach-mvebu/spl.c | 77 +++---
3 files changed, 71 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index 0b935c46fb..daf8bd66a0 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#define DDR_BASE_CS_OFF(n) (0x + ((n) << 3))
@@ -80,6 +81,65 @@ int mvebu_soc_family(void)
return MVEBU_SOC_UNKNOWN;
}
+u32 get_boot_device(void)
+{
+ u32 val;
+ u32 boot_device;
+
+ /*
+ * First check, if UART boot-mode is active. This can only
+ * be done, via the bootrom error register. Here the
+ * MSB marks if the UART mode is active.
+ */
+ val = readl(CONFIG_BOOTROM_ERR_REG);
+ boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
+ debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
+ if (boot_device == BOOTROM_ERR_MODE_UART)
+ return BOOT_DEVICE_UART;
+
+#ifdef CONFIG_ARMADA_38X
+ /*
+ * If the bootrom error code contains any other than zeros it's an
+ * error condition and the bootROM has fallen back to UART boot
+ */
+ boot_device = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
+ if (boot_device)
+ return BOOT_DEVICE_UART;
+#endif
+
+ /*
+ * Now check the SAR register for the strapped boot-device
+ */
+ val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
+ boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
+ debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
+ switch (boot_device) {
+#ifdef BOOT_FROM_NAND
+ case BOOT_FROM_NAND:
+ return BOOT_DEVICE_NAND;
+#endif
+#ifdef BOOT_FROM_MMC
+ case BOOT_FROM_MMC:
+ case BOOT_FROM_MMC_ALT:
+ return BOOT_DEVICE_MMC1;
+#endif
+ case BOOT_FROM_UART:
+#ifdef BOOT_FROM_UART_ALT
+ case BOOT_FROM_UART_ALT:
+#endif
+ return BOOT_DEVICE_UART;
+#ifdef BOOT_FROM_SATA
+ case BOOT_FROM_SATA:
+ case BOOT_FROM_SATA_ALT:
+ return BOOT_DEVICE_SATA;
+#endif
+ case BOOT_FROM_SPI:
+ return BOOT_DEVICE_SPI;
+ default:
+ return BOOT_DEVICE_BOOTROM;
+ };
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
#if defined(CONFIG_ARMADA_375)
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 79858858c2..a7a62c7e7d 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -148,6 +148,8 @@ void __noreturn return_to_bootrom(void);
int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 min_clk, u32 quirks);
#endif
+u32 get_boot_device(void);
+
void get_sar_freq(struct sar_freq_modes *sar_freq);
/*
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index f0cf60bb14..8d6d4902f6 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -171,74 +171,6 @@ int spl_parse_board_header(struct spl_image_info
*spl_image,
return 0;
}
-static u32 get_boot_device(void)
-{
- u32 val;
- u32 boot_device;
-
- /*
-* First check, if UART boot-mode is active. This can only
-* be done, via the bootrom error register. Here the
-* MSB marks if the UART mode is active.
-*/
- val = readl(CONFIG_BOOTROM_ERR_REG);
- boot_device = (val & BOOTROM_ERR_MODE_MASK) >> BOOTROM_ERR_MODE_OFFS;
- debug("BOOTROM_REG=0x%08x boot_device=0x%x\n", val, boot_device);
- if (boot_device == BOOTROM_ERR_MODE_UART)
- return BOOT_DEVICE_UART;
-
-#ifdef CONFIG_ARMADA_38X
- /*
-* If the bootrom error code contains any other than zeros it's an
-* error condition and the bootROM has fallen back to UART boot
-*/
- boot_device = (val & BOOTROM_ERR_CODE_MASK) >> BOOTROM_ERR_CODE_OFFS;
- if (boot_device)
- return BOOT_DEVICE_UART;
-#endif
-
- /*
-* Now check the SAR register for the strapped boot-device
-*/
- val = readl(CONFIG_SAR_REG);/* SAR - Sample At Reset */
- boot_device = (val & BOOT_DEV_SEL_MASK) >> BOOT_DEV_SEL_OFFS;
- debug("SAR_REG=0x%08x boot_device=0x%x\n", val, boot_device);
- switch (boot_device) {
-#ifdef BOOT_FROM_NAND
- case BOOT_FROM_NAND:
- return BOOT_DEVICE_NAND;
-#endif
-#ifdef BOOT_FROM_MMC
- case BOOT_FROM_MMC:
-
Re: [PATCH v2 2/5] usb: gadget: Add bcdDevice for the DWC2 USB Gadget Controller
Hi Lukasz
Can you add your reviewed-by on this patch ?
This patch, and the other 4 patches of this serie, are still blocked on
patchwork since April.
Thanks ;-)
Patrice
On 4/19/21 11:45 AM, Patrice Chotard wrote:
> Add an entry in usb_gadget_controller_number() for the DWC2
> gadget controller. It is used to bind the USB Ethernet driver.
>
> Signed-off-by: Patrice Chotard
> Reported-by: Herbert Poetzl
> Cc: Marek Vasut
> Cc: Herbert Poetzl
> ---
>
> (no changes since v1)
>
> drivers/usb/gadget/gadget_chips.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/usb/gadget/gadget_chips.h
> b/drivers/usb/gadget/gadget_chips.h
> index 0cdf47c2dd..06e6a48949 100644
> --- a/drivers/usb/gadget/gadget_chips.h
> +++ b/drivers/usb/gadget/gadget_chips.h
> @@ -167,6 +167,12 @@
> #define gadget_is_mtu3(g)0
> #endif
>
> +#ifdef CONFIG_USB_GADGET_DWC2_OTG
> +#define gadget_is_dwc2(g)(!strcmp("dwc2-udc", (g)->name))
> +#else
> +#define gadget_is_dwc2(g)0
> +#endif
> +
> /**
> * usb_gadget_controller_number - support bcdDevice id convention
> * @gadget: the controller being driven
> @@ -232,5 +238,7 @@ static inline int usb_gadget_controller_number(struct
> usb_gadget *gadget)
> return 0x25;
> else if (gadget_is_mtu3(gadget))
> return 0x26;
> + else if (gadget_is_dwc2(gadget))
> + return 0x27;
> return -ENOENT;
> }
>
Re: [PATCH v2] arm: mvebu: a37xx: Define CONFIG_SYS_REF_CLK and use it instead of get_ref_clk()
Hi Pali,
On 16.08.21 12:02, Pali Rohár wrote:
Like for all other mvebu platforms with CONFIG_SYS_TCLK macro, define
CONFIG_SYS_REF_CLK macro for a37xx with base reference clock value which is
read from latched reset register.
Replace all usages of get_ref_clk() function by this CONFIG_SYS_REF_CLK
macro and completely remove get_ref_clk() function.
Replace also custom open-coded implementation of determining reference
clock by CONFIG_SYS_REF_CLK in a37xx serial driver.
The only difference is that macro CONFIG_SYS_REF_CLK returns base reference
clock in Hz and old function get_ref_clk() returned it in MHz.
Signed-off-by: Pali Rohár
---
Changes in v2:
* Do not remove MVEBU_TEST_PIN_LATCH_N and MVEBU_XTAL_MODE_MASK macros
This patch does not apply any more, with all the other patches applied.
Please wait a bit until these patches are included in master and then
send a new version.
Sorry for the trouble.
Thanks,
Stefan
---
arch/arm/mach-mvebu/armada3700/cpu.c | 24
arch/arm/mach-mvebu/include/mach/cpu.h | 7 ---
arch/arm/mach-mvebu/include/mach/soc.h | 6 ++
drivers/clk/mvebu/armada-37xx-periph.c | 6 +++---
drivers/clk/mvebu/armada-37xx-tbg.c| 4 ++--
drivers/phy/marvell/comphy_a3700.c | 12 ++--
drivers/serial/serial_mvebu_a3700.c| 11 ---
drivers/watchdog/armada-37xx-wdt.c | 2 +-
8 files changed, 22 insertions(+), 50 deletions(-)
diff --git a/arch/arm/mach-mvebu/armada3700/cpu.c
b/arch/arm/mach-mvebu/armada3700/cpu.c
index 7702028ba19b..bdf8dc377528 100644
--- a/arch/arm/mach-mvebu/armada3700/cpu.c
+++ b/arch/arm/mach-mvebu/armada3700/cpu.c
@@ -23,12 +23,6 @@
/* Armada 3700 */
#define MVEBU_GPIO_NB_REG_BASE(MVEBU_REGISTER(0x13800))
-#define MVEBU_TEST_PIN_LATCH_N (MVEBU_GPIO_NB_REG_BASE + 0x8)
-#define MVEBU_XTAL_MODE_MASK BIT(9)
-#define MVEBU_XTAL_MODE_OFFS 9
-#define MVEBU_XTAL_CLOCK_25MHZ 0x0
-#define MVEBU_XTAL_CLOCK_40MHZ 0x1
-
#define MVEBU_NB_WARM_RST_REG (MVEBU_GPIO_NB_REG_BASE + 0x40)
#define MVEBU_NB_WARM_RST_MAGIC_NUM 0x1d1e
@@ -370,21 +364,3 @@ void reset_cpu(void)
*/
writel(MVEBU_NB_WARM_RST_MAGIC_NUM, MVEBU_NB_WARM_RST_REG);
}
-
-/*
- * get_ref_clk
- *
- * return: reference clock in MHz (25 or 40)
- */
-u32 get_ref_clk(void)
-{
- u32 regval;
-
- regval = (readl(MVEBU_TEST_PIN_LATCH_N) & MVEBU_XTAL_MODE_MASK) >>
- MVEBU_XTAL_MODE_OFFS;
-
- if (regval == MVEBU_XTAL_CLOCK_25MHZ)
- return 25;
- else
- return 40;
-}
diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
b/arch/arm/mach-mvebu/include/mach/cpu.h
index 79858858c259..9b8907e0fe55 100644
--- a/arch/arm/mach-mvebu/include/mach/cpu.h
+++ b/arch/arm/mach-mvebu/include/mach/cpu.h
@@ -183,12 +183,5 @@ int a3700_dram_init_banksize(void);
/* A3700 PCIe regions fixer for device tree */
int a3700_fdt_fix_pcie_regions(void *blob);
-/*
- * get_ref_clk
- *
- * return: reference clock in MHz (25 or 40)
- */
-u32 get_ref_clk(void);
-
#endif /* __ASSEMBLY__ */
#endif /* _MVEBU_CPU_H */
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h
b/arch/arm/mach-mvebu/include/mach/soc.h
index aab61f7c15cf..b03b6de3c6cd 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -210,6 +210,12 @@
#define BOOT_FROM_SPI 0x3
#define CONFIG_SYS_TCLK 25000 /* 250MHz */
+#elif defined(CONFIG_ARMADA_3700)
+/* SAR values for Armada 3700 */
+#define MVEBU_TEST_PIN_LATCH_N MVEBU_REGISTER(0x13808)
+#define MVEBU_XTAL_MODE_MASK BIT(9)
+#define CONFIG_SYS_REF_CLK ((readl(MVEBU_TEST_PIN_LATCH_N) &
MVEBU_XTAL_MODE_MASK) ? \
+4000 : 2500)
#endif
#endif /* _MVEBU_SOC_H */
diff --git a/drivers/clk/mvebu/armada-37xx-periph.c
b/drivers/clk/mvebu/armada-37xx-periph.c
index 3b767d706009..f5b3f5a78414 100644
--- a/drivers/clk/mvebu/armada-37xx-periph.c
+++ b/drivers/clk/mvebu/armada-37xx-periph.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -501,7 +501,7 @@ int armada_37xx_tbg_clk_dump(struct udevice *);
int soc_clk_dump(void)
{
- printf(" xtal at %u00 Hz\n\n", get_ref_clk());
+ printf(" xtal at %u Hz\n\n", CONFIG_SYS_REF_CLK);
if (clk_dump("tbg@13200", armada_37xx_tbg_clk_dump))
return 1;
@@ -581,7 +581,7 @@ static int armada_37xx_periph_clk_probe(struct udevice *dev)
struct clk clk;
if (i == XTAL) {
- priv->parents[i] = get_ref_clk() * 100;
+ priv->parents[i] = CONFIG_SYS_REF_CLK;
continue;
}
diff --git a/drivers/clk/mvebu/armada-37xx-tbg.c b/drivers/clk/mvebu/armada-37xx-tbg.c
index 054aff5e6aca..2ec60b15a6af 100644
--- a/drivers/clk/mvebu/armada-37xx-tbg.c
+++
Re: [PATCH] serial: a37xx: Remove CONFIG_DEBUG_UART_SHIFT options
On 13.08.21 13:58, Pali Rohár wrote: Armada 37xx serial driver does not use CONFIG_DEBUG_UART_SHIFT. So do not define any bogus value for CONFIG_DEBUG_UART_SHIFT option in any Armada 37xx defconfig file. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- configs/mvebu_db-88f3720_defconfig | 1 - configs/mvebu_espressobin-88f3720_defconfig | 1 - configs/turris_mox_defconfig| 1 - configs/uDPU_defconfig | 1 - 4 files changed, 4 deletions(-) diff --git a/configs/mvebu_db-88f3720_defconfig b/configs/mvebu_db-88f3720_defconfig index bc92fdb8ee8c..eb50afc0f381 100644 --- a/configs/mvebu_db-88f3720_defconfig +++ b/configs/mvebu_db-88f3720_defconfig @@ -63,7 +63,6 @@ CONFIG_PHY=y CONFIG_MVEBU_COMPHY_SUPPORT=y CONFIG_PINCTRL=y CONFIG_PINCTRL_ARMADA_37XX=y -CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_MVEBU_A3700_UART=y CONFIG_MVEBU_A3700_SPI=y diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index 4003a25346ce..9641c02d9317 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -79,7 +79,6 @@ CONFIG_MVEBU_COMPHY_SUPPORT=y CONFIG_PINCTRL=y CONFIG_PINCTRL_ARMADA_37XX=y CONFIG_DM_REGULATOR_GPIO=y -CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_MVEBU_A3700_UART=y CONFIG_MVEBU_A3700_SPI=y diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig index fc5e1fc3766f..40f975ead314 100644 --- a/configs/turris_mox_defconfig +++ b/configs/turris_mox_defconfig @@ -87,7 +87,6 @@ CONFIG_DM_RTC=y CONFIG_RTC_DS1307=y CONFIG_SCSI=y CONFIG_DM_SCSI=y -CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_MVEBU_A3700_UART=y CONFIG_MVEBU_A3700_SPI=y diff --git a/configs/uDPU_defconfig b/configs/uDPU_defconfig index 3e6bb32cb88b..1ea3aad5ff2a 100644 --- a/configs/uDPU_defconfig +++ b/configs/uDPU_defconfig @@ -79,7 +79,6 @@ CONFIG_PINCTRL=y CONFIG_PINCTRL_ARMADA_37XX=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y -CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_MVEBU_A3700_UART=y CONFIG_MVEBU_A3700_SPI=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 3/3] arm: mvebu: turris_omnia: Enable NVMe support
On 13.08.21 13:56, Pali Rohár wrote: PCIe-based NVMe SSD disks in M.2 2230/2242/2260 form-factor can be connected to Turris Omnia mPCIe slot via passive M.2 <--> mPCIe adapter. So enable PCIe NVMe drivers. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- configs/turris_omnia_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/turris_omnia_defconfig b/configs/turris_omnia_defconfig index cd443ceb300f..2acc4ada4123 100644 --- a/configs/turris_omnia_defconfig +++ b/configs/turris_omnia_defconfig @@ -77,6 +77,7 @@ CONFIG_PHY_MARVELL=y CONFIG_PHY_GIGE=y CONFIG_MVNETA=y CONFIG_MII=y +CONFIG_NVME=y CONFIG_PCI=y CONFIG_PCI_MVEBU=y CONFIG_DM_RTC=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 2/3] arm: mvebu: turris_mox: Enable SATA support
On 13.08.21 13:56, Pali Rohár wrote: SATA disks could be connected via mPCIe add-in card with PCIe-SATA controller into Mox-B or Mox-G module. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- configs/turris_mox_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/turris_mox_defconfig b/configs/turris_mox_defconfig index c19b8379c32a..fc5e1fc3766f 100644 --- a/configs/turris_mox_defconfig +++ b/configs/turris_mox_defconfig @@ -12,6 +12,7 @@ CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="armada-3720-turris-mox" CONFIG_DEBUG_UART_BASE=0xd0012000 CONFIG_DEBUG_UART=y +CONFIG_AHCI=y CONFIG_OF_BOARD_FIXUP=y CONFIG_DISTRO_DEFAULTS=y # CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set @@ -32,6 +33,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_MTD=y CONFIG_CMD_PCI=y +CONFIG_CMD_SATA=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y CONFIG_CMD_WDT=y @@ -47,6 +49,8 @@ CONFIG_MAC_PARTITION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_SCSI_AHCI=y +CONFIG_AHCI_PCI=y CONFIG_BUTTON=y CONFIG_BUTTON_GPIO=y CONFIG_CLK=y @@ -81,6 +85,8 @@ CONFIG_PINCTRL_ARMADA_37XX=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_RTC=y CONFIG_RTC_DS1307=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y CONFIG_DEBUG_UART_SHIFT=2 CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_MVEBU_A3700_UART=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/3] arm: mvebu: espressobin: Enable also SATA support via PCIe
On 13.08.21 13:56, Pali Rohár wrote: Espressobin has one on-board SATA port which is connected directly to CPU. More SATA disks can be connected via mPCIe add-in card with PCIe-SATA controller. So enable required SATA AHCI PCIe drivers in defconfig file. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- configs/mvebu_espressobin-88f3720_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/mvebu_espressobin-88f3720_defconfig b/configs/mvebu_espressobin-88f3720_defconfig index c8ae0cf6109a..4003a25346ce 100644 --- a/configs/mvebu_espressobin-88f3720_defconfig +++ b/configs/mvebu_espressobin-88f3720_defconfig @@ -30,6 +30,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_MTD=y CONFIG_CMD_PCI=y +CONFIG_CMD_SATA=y CONFIG_CMD_SPI=y CONFIG_CMD_USB=y CONFIG_CMD_WDT=y @@ -46,6 +47,7 @@ CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_AHCI_PCI=y CONFIG_AHCI_MVEBU=y CONFIG_CLK=y CONFIG_CLK_MVEBU=y Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/2] arm: mvebu: axp: Properly check for Armada XP in mach/soc.h
On 11.08.21 20:53, Pali Rohár wrote: File mach/soc.h is included also in 64-bit mvebu processors, so define Armada XP related macros only when compiling for Armada XP. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- arch/arm/mach-mvebu/include/mach/soc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-mvebu/include/mach/soc.h b/arch/arm/mach-mvebu/include/mach/soc.h index 8e8a4058550e..aab61f7c15cf 100644 --- a/arch/arm/mach-mvebu/include/mach/soc.h +++ b/arch/arm/mach-mvebu/include/mach/soc.h @@ -189,7 +189,7 @@ #define BOOT_FROM_SPI 0x3 #define CONFIG_SYS_TCLK 2 /* 200MHz */ -#else +#elif defined(CONFIG_ARMADA_XP) /* SAR values for Armada XP */ #define CONFIG_SAR_REG(MVEBU_REGISTER(0x18230)) #define CONFIG_SAR2_REG (MVEBU_REGISTER(0x18234)) Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 4/4] tools: kwbimage: Use IBR_HDR_* constants instead of raw numbers
On 11.08.21 10:14, Pali Rohár wrote:
There are already IBR_HDR_* constants for these numbers, so use them.
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 5ac34ac5e9c8..c1269fb6633a 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -59,13 +59,13 @@ struct hash_v1 {
};
struct boot_mode boot_modes[] = {
- { 0x4D, "i2c" },
- { 0x5A, "spi" },
- { 0x8B, "nand" },
- { 0x78, "sata" },
- { 0x9C, "pex" },
- { 0x69, "uart" },
- { 0xAE, "sdio" },
+ { IBR_HDR_I2C_ID, "i2c" },
+ { IBR_HDR_SPI_ID, "spi" },
+ { IBR_HDR_NAND_ID, "nand" },
+ { IBR_HDR_SATA_ID, "sata" },
+ { IBR_HDR_PEX_ID, "pex" },
+ { IBR_HDR_UART_ID, "uart" },
+ { IBR_HDR_SDIO_ID, "sdio" },
{},
};
@@ -75,10 +75,10 @@ struct nand_ecc_mode {
};
struct nand_ecc_mode nand_ecc_modes[] = {
- { 0x00, "default" },
- { 0x01, "hamming" },
- { 0x02, "rs" },
- { 0x03, "disabled" },
+ { IBR_HDR_ECC_DEFAULT, "default" },
+ { IBR_HDR_ECC_FORCED_HAMMING, "hamming" },
+ { IBR_HDR_ECC_FORCED_RS, "rs" },
+ { IBR_HDR_ECC_DISABLED, "disabled" },
{},
};
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 3/4] tools: kwbimage: Verify size of image data
On 11.08.21 10:14, Pali Rohár wrote: Part of image data is 4 byte checksum, so every image must contain at least 4 bytes. Verify it to prevent memory corruptions. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- tools/kwbimage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/kwbimage.c b/tools/kwbimage.c index 84c41210e39e..5ac34ac5e9c8 100644 --- a/tools/kwbimage.c +++ b/tools/kwbimage.c @@ -1757,7 +1757,7 @@ static int kwbimage_verify_header(unsigned char *ptr, int image_size, return -FDT_ERR_BADSTRUCTURE; size = le32_to_cpu(mhdr->blocksize); - if (offset + size > image_size || size % 4 != 0) + if (size < 4 || offset + size > image_size || size % 4 != 0) return -FDT_ERR_BADSTRUCTURE; if (image_checksum32(ptr + offset, size - 4) != Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 2/4] tools: kwbimage: Verify size of v0 image header
On 11.08.21 10:14, Pali Rohár wrote:
Check that extended image header size is not larger than file size.
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 80aae8a6b619..84c41210e39e 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1682,6 +1682,9 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
if (mhdr->ext & 0x1) {
struct ext_hdr_v0 *ext_hdr;
+ if (header_size + sizeof(*ext_hdr) > image_size)
+ return -FDT_ERR_BADSTRUCTURE;
+
ext_hdr = (struct ext_hdr_v0 *)
(ptr + sizeof(struct main_hdr_v0));
checksum = image_checksum8(ext_hdr,
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH 1/4] tools: kwbimage: Verify supported image version
On 11.08.21 10:14, Pali Rohár wrote:
Only image versions 0 and 1 are supported. Verify it in
kwbimage_verify_header() function.
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
tools/kwbimage.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 4bff02bb3fb5..80aae8a6b619 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1690,9 +1690,7 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
if (checksum != ext_hdr->checksum)
return -FDT_ERR_BADSTRUCTURE;
}
- }
-
- if (image_version((void *)ptr) == 1) {
+ } else if (image_version((void *)ptr) == 1) {
struct main_hdr_v1 *mhdr = (struct main_hdr_v1 *)ptr;
uint32_t offset;
uint32_t size;
@@ -1762,6 +1760,8 @@ static int kwbimage_verify_header(unsigned char *ptr, int
image_size,
if (image_checksum32(ptr + offset, size - 4) !=
*(uint32_t *)(ptr + offset + size - 4))
return -FDT_ERR_BADSTRUCTURE;
+ } else {
+ return -FDT_ERR_BADSTRUCTURE;
}
return 0;
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [RFC PATCH] stm32mp1: Replace STM32IMAGE config with TFABOOT_FIP
Hi Marek, On 8/31/21 6:42 PM, Marek Vasut wrote: On 8/31/21 4:54 PM, Patrick DELAUNAY wrote: Hi Alexandru, Hi, On 8/26/21 11:47 PM, Alexandru Gagniuc wrote: Hi Patrick, I proposing a better fix fir the issues I outlined earlier, I made a classification of the currently supported boot modes. 1) BL1 -> SPL -> U-Boot 2) BL1 -> SPL -> OP-TEE - | 3) BL1 -> TF-A -> U-Boot | | 4) BL1 -> TF-A -> OP-TEE | | _ | || 5) BL1 -> TF-A -> FIP container || || CONFIG_TFABOOT_FIP || ||_|| | | | CONFIG_TFABOOT | - Here, I'm looking at FIP as a new boot mode. In order to avoid breakage, any changes to support FIP it should naturally be done only to this new path. This proposal contains several changes, but I've squashed them into one for ease of discussion. This better matches the boot mode classification above. 1) is supported but with many constraint for security part and low power management it is not recommended for real product / it will be not supported by STMicroelectronics Does this mean ST will be cutting off their own customers who use this boot mode because they do not need/want additional complex problematically licensed components in their boot chain and/or ST will be forcing those customers into adding such unneeded/unwanted components unconditionally ? I am strongly opposed to that. Our concerns is not a licensing issue (BSD vs GPL) but firmware complexity to manage Cortex A (Linux) + Cortex M (RTOS) and shared ressources. To guarantee the Cortex M security, the shared resource (as root clock or regulator for example) need to be managed by a centralized element. It is the same for low power mode = to manage each possible step for Cortex M + Cortex A and PMIC security, the low power sequence are executed in secure side. => it is done in our ecosystem for STM32MP15x platform in secure monitor (OP-TEE - the preferred one - or SPMin) based on SCMI and PSCI api called by Linux kernel generic driver. These API are NOT supported by SPL / U-Boot, it is the reason of the restrictions = I have only implement a limited PSCI support to start the kernel You can continue to use SPL on STM32MP15 (at the current upstream level) but with limited features. but only the boot with TF-A is supported / promoted by STMicroelectronics on the STM32MP family. These restriction are already announced to STMicroelectronics customers since OpenSTLinux v1.2 I think. For example in https://wiki.st.com/stm32mpu-ecosystem-v2/wiki/STM32MP15_ecosystem_release_note_-_v2.1.0 Basic boot has been removed since STM32MP15-ecosystem-v2.0.0, if you were using basic boot with U-BOOT-SPL to load U-BOOT and the Kernel, then you need to use now the ST reference boot scheme in replacing U-BOOT-SPL by TF-A as FSBL as explained in Boot chain overview. I would argue that the U-Boot crypto code went through multiple independent security reviews, personally I trust that more than code fully controlled and maintained by any one single company, so I am not buying the security constraint argument here. When I talk about security, it is not crypto code, but some security features as isolation between cortex A and Cortex M, key infractructure, trusted environment execution, secure update. Regarding power management and low power modes, there is literally nothing preventing Linux from implementing those low power modes, so there is no reason to hide all that code in firmware, so I am not buying the low power argument either. Some part is already done in Linux with call SCMI / PSCI api. Some part is done in secured firmware: DDR self refresh entry sequence / root clock deactivation / PMIC access on secured I2C. Finally, the argument that the component that is being forced upon everyone is "open source" is really turning any design with such a SoC into a huge risk. There have been SoCs where the vendor took "open source" bootloader code, compiled a blob, released a blob and never gave out the sources, because it is "open source" and not "free software", the BSD license permits such practice, GPL does not. Whoever wanted to design a board or SoM with such a SoC, had to adjust their design to match that one blob. Of course, that also implies that any security problems were not fixable in that blob. TF-A in OpenSTLinux is delivered as source, you can recompile it => no blob delivery for STMicroelectronics https://github.com/STMicroelectronics/arm-trusted-firmware And we upstream all the
Re: [PATCH] arm: mvebu: a38x: Define supported UART baudrates
On 11.08.21 10:08, Pali Rohár wrote:
Define all standard baudrates plus 3 non-standard high speed:
3125000 400 515
3125000 matches divisor 5 with 250 MHz TCLK and divisor 4 with 200 MHz TCLK.
400 is the rounded value for divisor 4 with 250 MHz TCLK (3906250) and
divisor 3 with 200 MHz TCLK (416).
515 is the rounded value (5208333) for divisor 3 with 250 MHz TCLK.
Testing showed that rounded value is more stable then exactly calculated.
And it is the highest possible baudrate which is stable on A38x platform.
Any other baudrate values above 250 are unstable, which is reason why
e.g. standard value 300 is not defined, and it is needed to use
non-standard value 3125000.
Tested all defined UART baudrates on Turris Omnia (A38x with 250 MHz TCLK).
Signed-off-by: Pali Rohár
Applied to u-boot-marvell/master
Thanks,
Stefan
---
include/configs/mv-common.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/configs/mv-common.h b/include/configs/mv-common.h
index d61c90a43156..53d7acbb1034 100644
--- a/include/configs/mv-common.h
+++ b/include/configs/mv-common.h
@@ -39,6 +39,15 @@
#define CONFIG_SYS_NS16550_COM1 MV_UART_CONSOLE_BASE
#endif
+#if defined(CONFIG_ARMADA_38X) && !defined(CONFIG_SYS_BAUDRATE_TABLE)
+#define CONFIG_SYS_BAUDRATE_TABLE { 300, 600, 1200, 1800, 2400, 4800, \
+ 9600, 19200, 38400, 57600, 115200, \
+ 230400, 460800, 50, 576000, \
+ 921600, 100, 1152000, 150, \
+ 200, 250, 3125000, 400, \
+ 515 }
+#endif
+
/* auto boot */
/*
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH v2 8/9] arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux
Now that everything is prepared, copy the fsl-ls1028a.dtsi from the
linux kernel v5.14.
Signed-off-by: Michael Walle
---
changes since v1:
- none
arch/arm/dts/fsl-ls1028a.dtsi | 1212 +
.../dt-bindings/clock/fsl,qoriq-clockgen.h| 15 +
2 files changed, 958 insertions(+), 269 deletions(-)
create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 69850fe7f2..343ecf0e89 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -1,12 +1,16 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * NXP ls1028a SOC common device tree source
+ * Device Tree Include file for NXP Layerscape-1028A family SoC.
*
- * Copyright 2019-2020 NXP
+ * Copyright 2018-2020 NXP
+ *
+ * Harninder Rai
*
*/
+#include
#include
+#include
/ {
compatible = "fsl,ls1028a";
@@ -14,6 +18,54 @@
#address-cells = <2>;
#size-cells = <2>;
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x0>;
+ enable-method = "psci";
+ clocks = < QORIQ_CLK_CMUX 0>;
+ next-level-cache = <>;
+ cpu-idle-states = <_PW20>;
+ #cooling-cells = <2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x1>;
+ enable-method = "psci";
+ clocks = < QORIQ_CLK_CMUX 0>;
+ next-level-cache = <>;
+ cpu-idle-states = <_PW20>;
+ #cooling-cells = <2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ idle-states {
+ /*
+* PSCI node is not added default, U-boot will add missing
+* parts if it determines to use PSCI.
+*/
+ entry-method = "psci";
+
+ CPU_PW20: cpu-pw20 {
+ compatible = "arm,idle-state";
+ idle-state-name = "PW20";
+ arm,psci-suspend-param = <0x0>;
+ entry-latency-us = <2000>;
+ exit-latency-us = <2000>;
+ min-residency-us = <6000>;
+ };
+ };
+
sysclk: sysclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -21,14 +73,33 @@
clock-output-names = "sysclk";
};
- gic: interrupt-controller@600 {
- compatible = "arm,gic-v3";
- reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
- <0x0 0x0604 0 0x4>;
- #interrupt-cells = <3>;
- interrupt-controller;
- interrupts = ;
+ osc_27m: clock-osc-27m {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2700>;
+ clock-output-names = "phy_27m";
+ };
+
+ dpclk: clock-controller@f1f {
+ compatible = "fsl,ls1028a-plldig";
+ reg = <0x0 0xf1f 0x0 0x>;
+ #clock-cells = <0>;
+ clocks = <_27m>;
+ };
+
+ firmware {
+ optee: optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ status = "disabled";
+ };
+ };
+
+ reboot {
+ compatible ="syscon-reboot";
+ regmap = <>;
+ offset = <0>;
+ mask = <0x02>;
};
timer {
@@ -43,177 +114,127 @@
IRQ_TYPE_LEVEL_LOW)>;
};
- soc: soc {
- compatible = "simple-bus";
+ pmu {
+ compatible = "arm,cortex-a72-pmu";
+ interrupts = ;
+ };
+
+ gic: interrupt-controller@600 {
+ compatible= "arm,gic-v3";
#address-cells = <2>;
#size-cells = <2>;
ranges;
-
- clockgen: clocking@130 {
- compatible = "fsl,ls1028a-clockgen";
- reg = <0x0 0x130 0x0 0xa>;
- #clock-cells = <2>;
- clocks = <>;
+ reg= <0x0 0x0600 0 0x1>, /* GIC Dist */
+ <0x0 0x0604 0 0x4>; /* GIC Redistributor */
+ #interrupt-cells= <3>;
+
[PATCH v2 9/9] arm: dts: sl28: sync dtbs
Copy the board device tree files from linux v5.14. On top of the v5.14
dtbs the changes of these two patches are included here which are needed
for u-boot:
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-7-mich...@walle.cc/
https://lore.kernel.org/linux-devicetree/20210831134013.1625527-8-mich...@walle.cc/
At the time of this writing the patches are still pending but already
have Reviewed-by tags.
Signed-off-by: Michael Walle
---
changes since v1:
- none
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 12 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 31 +--
.../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi | 8 +
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 40 +--
.../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 16 +-
arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 250 +++---
6 files changed, 265 insertions(+), 92 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index 42bd3138b2..f80c699a3c 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -4,12 +4,9 @@
/ {
aliases {
- mmc0 =
- mmc1 =
i2c0 =
i2c1 =
i2c2 =
- rtc0 =
ethernet2 = _port2;
ethernet3 = _port3;
};
@@ -234,11 +231,6 @@
};
#endif
- {
- rtc: rtc@32 {
- };
-};
-
{
u-boot,dm-pre-reloc;
flash@0 {
@@ -266,6 +258,10 @@
u-boot,dm-pre-reloc;
};
+ {
+ status = "okay";
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index ba2e4de96d..7cd29ab970 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -8,7 +8,7 @@
* None of the four SerDes lanes are used by the module, instead they are
* all led out to the carrier for customer use.
*
- * Copyright (C) 2020 Michael Walle
+ * Copyright (C) 2021 Michael Walle
*
*/
@@ -21,28 +21,17 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
};
-_port0 {
- status = "disabled";
- /delete-property/ phy-handle;
-};
-
-_port1 {
- phy-handle = <>;
- phy-mode = "rgmii-id";
- status = "okay";
-};
-
-/delete-node/
_mdio_pf3 {
+ /* Delete unused phy node */
+ /delete-node/ ethernet-phy@5;
+
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
eee-broken-100tx;
-
qca,clk-out-frequency = <12500>;
qca,clk-out-strength = ;
qca,keep-pll-enabled;
-
vddio-supply = <>;
vddio: vddio-regulator {
@@ -56,3 +45,15 @@
};
};
};
+
+_port0 {
+ status = "disabled";
+ /* Delete the phy-handle to the old phy0 label */
+ /delete-property/ phy-handle;
+};
+
+_port1 {
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
index 4e0ce3f77d..c010ea0dc7 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
@@ -7,3 +7,11 @@
ethernet1 = _felix_port1;
};
};
+
+_felix_port0 {
+ label = "gbe0";
+};
+
+_felix_port1 {
+ label = "gbe1";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index db80874f4e..330e34f933 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -2,10 +2,10 @@
/*
* Device Tree file for the Kontron SMARC-sAL28 board.
*
- * This is for the network variant 2 which has no ethernet support in the
- * bootloader.
+ * This is for the network variant 2 which has two ethernet ports. These
+ * ports are connected to the internal switch.
*
- * Copyright (C) 2020 Michael Walle
+ * Copyright (C) 2021 Michael Walle
*
*/
@@ -17,8 +17,21 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
};
+_mdio_pf3 {
+ phy1: ethernet-phy@4 {
+ reg = <0x4>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+};
+
_port0 {
status = "disabled";
+ /*
+* In the base device tree the PHY at address 5 was assigned for
+* this port. On this module this PHY is connected to a switch
+* port instead. Therefore, delete the phy-handle property here.
+*/
/delete-property/ phy-handle;
};
@@ -31,14 +44,16 @@
};
_felix_port0 {
- label = "gbe0";
+ label = "swp0";
+ managed = "in-band-status";
phy-handle =
[PATCH v2 4/9] arm: dts: ls1028a: update the labels
Update the labels of the nodes to match the kernel ones.
Signed-off-by: Michael Walle
---
changes since v1:
- fix enetc0 and enetc2 labels
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 10 +++
.../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi | 2 +-
.../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 6 ++---
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 8 +++---
.../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi | 2 +-
.../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi | 4 +--
.../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 4 +--
arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 22
.../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds--sch-30841.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 2 +-
.../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 +--
.../dts/fsl-ls1028a-qds--sch-24801.dtsi | 4 +--
arch/arm/dts/fsl-ls1028a-qds-duart.dts| 2 +-
.../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 +--
.../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 4 +--
.../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 4 +--
arch/arm/dts/fsl-ls1028a-qds.dtsi | 16 ++--
arch/arm/dts/fsl-ls1028a-rdb.dts | 22
arch/arm/dts/fsl-ls1028a.dtsi | 26 +--
23 files changed, 81 insertions(+), 81 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index fa4c05212a..42bd3138b2 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -5,13 +5,13 @@
/ {
aliases {
mmc0 =
- mmc1 =
+ mmc1 =
i2c0 =
i2c1 =
i2c2 =
rtc0 =
- ethernet2 =
- ethernet3 =
+ ethernet2 = _port2;
+ ethernet3 = _port3;
};
binman: binman {
@@ -250,7 +250,7 @@
u-boot,dm-pre-reloc;
};
- {
+ {
u-boot,dm-pre-reloc;
};
@@ -262,7 +262,7 @@
u-boot,dm-pre-reloc;
};
- {
+ {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
index 98e8939369..a46e07dc6b 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi
@@ -3,6 +3,6 @@
/ {
aliases {
- ethernet0 =
+ ethernet0 = _port1;
};
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
index 33d85ed83a..ba2e4de96d 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts
@@ -21,19 +21,19 @@
compatible = "kontron,sl28-var1", "kontron,sl28", "fsl,ls1028a";
};
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
};
- {
+_port1 {
phy-handle = <>;
phy-mode = "rgmii-id";
status = "okay";
};
/delete-node/
- {
+_mdio_pf3 {
phy0: ethernet-phy@4 {
reg = <0x4>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 7a3aa21408..db80874f4e 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -17,12 +17,12 @@
compatible = "kontron,sl28-var2", "kontron,sl28", "fsl,ls1028a";
};
- {
+_port0 {
status = "disabled";
/delete-property/ phy-handle;
};
- {
+_port2 {
status = "okay";
};
@@ -45,12 +45,12 @@
};
_felix_port4 {
- ethernet = <>;
+ ethernet = <_port2>;
status = "okay";
};
/delete-node/
- {
+_mdio_pf3 {
phy0: ethernet-phy@5 {
reg = <0x5>;
eee-broken-1000t;
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
index 879a76415b..3d6bf5a0bd 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi
@@ -3,6 +3,6 @@
/ {
aliases {
- ethernet0 =
+ ethernet0 = _port0;
};
};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
index fce4694682..5d82973bba 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi
@@ -3,7 +3,7 @@
/ {
aliases {
- ethernet0 =
- ethernet1 =
+ ethernet0 =
[PATCH v2 2/9] arm: dts: ls1028a: move devices into /soc
Move all the CCSR related device nodes into /soc similiar to the linux
device tree.
Signed-off-by: Michael Walle
---
changes since v1:
- remove u-boot,dm-pre-reloc from rdb and qds boards
.../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 4 +
.../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds--sch-30841.dtsi | 8 +-
.../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 4 +-
.../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 2 +-
.../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 8 +-
.../dts/fsl-ls1028a-qds--sch-24801.dtsi | 8 +-
.../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 8 +-
.../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 8 +-
.../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 2 +-
.../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 2 +-
arch/arm/dts/fsl-ls1028a-qds.dtsi | 1 -
arch/arm/dts/fsl-ls1028a-rdb.dts | 1 -
arch/arm/dts/fsl-ls1028a.dtsi | 767 +-
15 files changed, 418 insertions(+), 409 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
index b3861ed98c..fa4c05212a 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi
@@ -266,6 +266,10 @@
u-boot,dm-pre-reloc;
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
{
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index 23816da8ee..181fd2ddcb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -16,5 +16,5 @@
{
status = "okay";
phy-mode = "usxgmii";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
index c6558ae2e0..67b68f1b3d 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi
@@ -15,5 +15,5 @@
{
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index 5a0f060c16..433731df0e 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -31,25 +31,25 @@
_felix_port0 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@00}>;
};
_felix_port1 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@01}>;
};
_felix_port2 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
_felix_port3 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
_felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index 39a83e10c4..cb74c8b371 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -20,13 +20,13 @@
_felix_port0 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
_felix_port3 {
status = "okay";
phy-mode = "sgmii-2500";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
_felix_port4 {
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 7d4702e4ff..979c0ddd48 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -15,5 +15,5 @@
{
status = "okay";
phy-mode = "sgmii";
- phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
+ phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
diff --git
[PATCH v2 5/9] watchdog: sp805_wdt: use correct compatible string
According to the linux device tree specification the compatible string
is:
compatible = "arm,sp805", "arm,primecell";
Fix all users in u-boot.
Signed-off-by: Michael Walle
---
changes since v1:
- none
arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
arch/arm/dts/hi3660.dtsi | 4 ++--
drivers/watchdog/sp805_wdt.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index beee59e95c..09d748c4d0 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -481,7 +481,7 @@
};
cluster1_core0_watchdog: wdt@c00 {
- compatible = "arm,sp805-wdt";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xc00 0x0 0x1000>;
};
};
diff --git a/arch/arm/dts/hi3660.dtsi b/arch/arm/dts/hi3660.dtsi
index 65a45b0e80..028f4db60d 100644
--- a/arch/arm/dts/hi3660.dtsi
+++ b/arch/arm/dts/hi3660.dtsi
@@ -1087,7 +1087,7 @@
};
watchdog0: watchdog@e8a06000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a06000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
@@ -1095,7 +1095,7 @@
};
watchdog1: watchdog@e8a07000 {
- compatible = "arm,sp805-wdt", "arm,primecell";
+ compatible = "arm,sp805", "arm,primecell";
reg = <0x0 0xe8a07000 0x0 0x1000>;
interrupts = ;
clocks = <_ctrl HI3660_OSC32K>;
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index bec8827ceb..0d6fb12065 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -134,7 +134,7 @@ static const struct wdt_ops sp805_wdt_ops = {
};
static const struct udevice_id sp805_wdt_ids[] = {
- { .compatible = "arm,sp805-wdt" },
+ { .compatible = "arm,sp805" },
{}
};
--
2.30.2
[PATCH v2 6/9] spi: fsl_dspi: add new compatible fsl, ls1021a-v1.0-dspi
The official ls1028a binding of the driver uses the following as
compatibles:
compatible = "fsl,ls1028a-dspi", "fsl,ls1021a-v1.0-dspi";
Add the missing compatible to the driver and update the device tree.
We can use the fallback "fsl,ls1021a-v1.0-dspi", because the endianness
is determined by the little-endian property and not by the compatible
string itself. Further, we won't need and specific details on the DMA
configuration (which is different on the LS1021A). If it's ever needed,
we can later add the more specific "fsl,ls1028a-dspi" compatible to the
driver.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
changes since v1:
- add more information to the commit message
- fix typo
arch/arm/dts/fsl-ls1028a.dtsi | 6 +++---
drivers/spi/fsl_dspi.c| 1 +
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 09d748c4d0..4186df17e1 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -381,7 +381,7 @@
};
dspi0: dspi@210 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
@@ -394,7 +394,7 @@
};
dspi1: dspi@211 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x211 0x0 0x1>;
@@ -407,7 +407,7 @@
};
dspi2: dspi@212 {
- compatible = "fsl,vf610-dspi";
+ compatible = "fsl,ls1028a-dspi",
"fsl,ls1021a-v1.0-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x212 0x0 0x1>;
diff --git a/drivers/spi/fsl_dspi.c b/drivers/spi/fsl_dspi.c
index 8fe3508c64..23d812f476 100644
--- a/drivers/spi/fsl_dspi.c
+++ b/drivers/spi/fsl_dspi.c
@@ -654,6 +654,7 @@ static const struct dm_spi_ops fsl_dspi_ops = {
static const struct udevice_id fsl_dspi_ids[] = {
{ .compatible = "fsl,vf610-dspi" },
+ { .compatible = "fsl,ls1021a-v1.0-dspi" },
{ }
};
--
2.30.2
[PATCH v2 7/9] serial: lpuart: add new compatible fsl,ls1028a-lpuart
The official ls1028a binding of the driver uses the following as
compatibles:
compatible = "fsl,ls1028a-lpuart";
Add the missing compatible to the driver and update the device tree.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
---
changes since v1:
- fix typo
arch/arm/dts/fsl-ls1028a.dtsi | 12 ++--
drivers/serial/serial_lpuart.c | 2 ++
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 4186df17e1..69850fe7f2 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -305,7 +305,7 @@
};
lpuart0: serial@226 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x226 0x0 0x1000>;
interrupts = <0 232 0x4>;
clocks = <>;
@@ -315,7 +315,7 @@
};
lpuart1: serial@227 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x227 0x0 0x1000>;
interrupts = <0 233 0x4>;
clocks = <>;
@@ -325,7 +325,7 @@
};
lpuart2: serial@228 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x228 0x0 0x1000>;
interrupts = <0 234 0x4>;
clocks = <>;
@@ -335,7 +335,7 @@
};
lpuart3: serial@229 {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x229 0x0 0x1000>;
interrupts = <0 235 0x4>;
clocks = <>;
@@ -345,7 +345,7 @@
};
lpuart4: serial@22a {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22a 0x0 0x1000>;
interrupts = <0 236 0x4>;
clocks = <>;
@@ -355,7 +355,7 @@
};
lpuart5: serial@22b {
- compatible = "fsl,ls1021a-lpuart";
+ compatible = "fsl,ls1028a-lpuart";
reg = <0x0 0x22b 0x0 0x1000>;
interrupts = <0 237 0x4>;
clocks = <>;
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index 2b473d70f6..3c9a69598a 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -553,6 +553,8 @@ static const struct dm_serial_ops lpuart_serial_ops = {
static const struct udevice_id lpuart_serial_ids[] = {
{ .compatible = "fsl,ls1021a-lpuart", .data =
LPUART_FLAG_REGMAP_32BIT_REG | LPUART_FLAG_REGMAP_ENDIAN_BIG },
+ { .compatible = "fsl,ls1028a-lpuart",
+ .data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,imx7ulp-lpuart",
.data = LPUART_FLAG_REGMAP_32BIT_REG },
{ .compatible = "fsl,vf610-lpuart"},
--
2.30.2
[PATCH v2 3/9] arm: dts: ls1028a: remove /memory node
This node is some hodgepodge between the ddr controller node at SoC
offset 0x108 and some static memory size of 2GiB. Remove this bogus
node because it doesn't seem to be used at all.
Signed-off-by: Michael Walle
Reviewed-by: Vladimir Oltean
Tested-by: Vladimir Oltean
---
changes since v1:
- none
arch/arm/dts/fsl-ls1028a.dtsi | 6 --
1 file changed, 6 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index b3b497218f..8559562803 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -21,12 +21,6 @@
clock-output-names = "sysclk";
};
- memory@0108 {
- device_type = "memory";
- reg = <0x 0x0108 0 0x8000>;
- /* DRAM space - 1, size : 2 GB DRAM */
- };
-
gic: interrupt-controller@600 {
compatible = "arm,gic-v3";
reg = <0x0 0x0600 0 0x1>, /* GIC Dist */
--
2.30.2
[PATCH v2 1/9] armv8: ls1028a: add IOMMU stream ID to vivante node
The fixup is done for the "fsl,ls1028a-gpu" which isn't any official
device tree binding. Don't break it, but instead add a fixup for another
compatible "vivante,gc" which is the offical one for the GPU on the
LS1028A.
Signed-off-by: Michael Walle
---
changes since v1:
- none
arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
index 49df8b3790..d93a793f39 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1028_ids.c
@@ -18,6 +18,7 @@ struct icid_id_table icid_tbl[] = {
SET_SATA_ICID(1, "fsl,ls1028a-ahci", FSL_SATA1_STREAM_ID),
SET_EDMA_ICID(FSL_EDMA_STREAM_ID),
SET_QDMA_ICID("fsl,ls1028a-qdma", FSL_DMA_STREAM_ID),
+ SET_GPU_ICID("vivante,gc", FSL_GPU_STREAM_ID),
SET_GPU_ICID("fsl,ls1028a-gpu", FSL_GPU_STREAM_ID),
SET_DISPLAY_ICID(FSL_DISPLAY_STREAM_ID),
#ifdef CONFIG_FSL_CAAM
--
2.30.2
[PATCH v2 0/9] arm: dts: ls1028a: sync device tree with linux
This series sync the device tree of the LS1028A SoC with the linux one. To ease future debugging and reviewing, we first clean up the existing one, removing bogus nodes, moving all CCSR related nodes in /soc and update the drivers to accept the offical compatible strings. This was tested on a sl28 board, but the ls1028a.dtsi sync also affects the LS1028A-RDB and -QDS. It would be nice if someone could actually test it on such a board. I didn't sync the device trees for the NXP boards because u-boot related things aren't split into its own -u-boot.dtsi file. So I'll leave that task to NXP :) The following patch is a prerequisite for this series: https://patchwork.ozlabs.org/project/uboot/patch/20210825210510.24766-1-tr...@konsulko.com/ Michael Walle (9): armv8: ls1028a: add IOMMU stream ID to vivante node arm: dts: ls1028a: move devices into /soc arm: dts: ls1028a: remove /memory node arm: dts: ls1028a: update the labels watchdog: sp805_wdt: use correct compatible string spi: fsl_dspi: add new compatible fsl,ls1021a-v1.0-dspi serial: lpuart: add new compatible fsl,ls1028a-lpuart arm: dts: ls1028a: sync the fsl-ls1028a.dtsi with linux arm: dts: sl28: sync dtbs .../arm/cpu/armv8/fsl-layerscape/ls1028_ids.c |1 + .../dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 24 +- .../fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi |2 +- .../arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 31 +- .../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi |8 + .../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 46 +- .../fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi |2 +- .../fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi |4 +- .../arm/dts/fsl-ls1028a-kontron-sl28-var4.dts | 18 +- arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 256 ++- .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi |4 +- .../dts/fsl-ls1028a-qds-6xxx-sch-30842.dtsi |4 +- .../dts/fsl-ls1028a-qds--sch-30841.dtsi | 12 +- .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi |8 +- .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi |4 +- .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 12 +- .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 12 +- arch/arm/dts/fsl-ls1028a-qds-duart.dts|2 +- .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 12 +- .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 12 +- .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi |6 +- .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi |6 +- arch/arm/dts/fsl-ls1028a-qds.dtsi | 17 +- arch/arm/dts/fsl-ls1028a-rdb.dts | 23 +- arch/arm/dts/fsl-ls1028a.dtsi | 1443 - arch/arm/dts/hi3660.dtsi |4 +- drivers/serial/serial_lpuart.c|2 + drivers/spi/fsl_dspi.c|1 + drivers/watchdog/sp805_wdt.c |2 +- .../dt-bindings/clock/fsl,qoriq-clockgen.h| 15 + 30 files changed, 1431 insertions(+), 562 deletions(-) create mode 100644 include/dt-bindings/clock/fsl,qoriq-clockgen.h -- 2.30.2
Re: [PATCH v5 5/5] riscv: lib: modify the indent
> From: Zong Li > Sent: Wednesday, September 01, 2021 3:02 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; bmeng...@gmail.com; sean...@gmail.com; > green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; > u-boot@lists.denx.de > Cc: Zong Li > Subject: [PATCH v5 5/5] riscv: lib: modify the indent > > We usually use a space in function declaration, rather than a tab. > > Signed-off-by: Zong Li > Reviewed-by: Sean Anderson > --- > arch/riscv/include/asm/cache.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Rick Chen
Re: [PATCH v5 4/5] board: sifive: use ccache driver instead of helper function
> From: Zong Li > Sent: Wednesday, September 01, 2021 3:02 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; bmeng...@gmail.com; sean...@gmail.com; > green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; > u-boot@lists.denx.de > Cc: Zong Li > Subject: [PATCH v5 4/5] board: sifive: use ccache driver instead of helper > function > > Invokes the common cache_init function to initialize ccache. > > Signed-off-by: Zong Li > Reviewed-by: Sean Anderson > --- > arch/riscv/cpu/fu540/Kconfig | 2 + > arch/riscv/cpu/fu540/Makefile | 1 - > arch/riscv/cpu/fu540/cache.c | 55 --- > arch/riscv/cpu/fu740/Kconfig | 2 + > arch/riscv/cpu/fu740/Makefile | 1 - > arch/riscv/cpu/fu740/cache.c | 55 --- > arch/riscv/include/asm/arch-fu540/cache.h | 14 -- > arch/riscv/include/asm/arch-fu740/cache.h | 14 -- > board/sifive/unleashed/unleashed.c| 10 + > board/sifive/unmatched/unmatched.c| 11 ++--- Reviewed-by: Rick Chen
Re: [PATCH v5 3/5] riscv: lib: implement enable_caches for sifive cache
> From: Zong Li > Sent: Wednesday, September 01, 2021 3:02 PM > To: Rick Jian-Zhi Chen(陳建志) ; Leo Yu-Chi Liang(梁育齊) > ; bmeng...@gmail.com; sean...@gmail.com; > green@sifive.com; paul.walms...@sifive.com; s...@chromium.org; > u-boot@lists.denx.de > Cc: Zong Li > Subject: [PATCH v5 3/5] riscv: lib: implement enable_caches for sifive cache > > The enable_caches is a generic hook for architecture-implemented, we define > this function to enable composable cache of sifive platforms. > > In sifive_cache, it invokes the generic cache_enable interface of cache > uclass to execute the relative implementation in SiFive ccache driver. > > Signed-off-by: Zong Li > --- > arch/riscv/Kconfig| 5 + > arch/riscv/lib/Makefile | 1 + > arch/riscv/lib/sifive_cache.c | 27 +++ > 3 files changed, 33 insertions(+) Reviewed-by: Rick Chen
[PATCH] stm32mp: Fix board_get_usable_ram_top()
When booting in EFI, lib/efi_loader/efi_memory.c calls
board_get_usable_ram_top(0) which returns by default
gd->ram_base + gd->ram_size which is the top of DDR.
In case of OPTEE boot, the top of DDR is currently reserved by OPTEE,
board_get_usable_ram_top(0) must return an address outside OPTEE
reserved memory.
gd->ram_top matches this constraint as it has already been initialized
by substracting all DT reserved-memory (included OPTEE memory area).
Fixes: 92b611e8b003 ("stm32mp: correctly handle board_get_usable_ram_top(0)")
Signed-off-by: Patrice Chotard
---
arch/arm/mach-stm32mp/dram_init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-stm32mp/dram_init.c
b/arch/arm/mach-stm32mp/dram_init.c
index 94f25f34e0..920b99bb68 100644
--- a/arch/arm/mach-stm32mp/dram_init.c
+++ b/arch/arm/mach-stm32mp/dram_init.c
@@ -47,7 +47,7 @@ ulong board_get_usable_ram_top(ulong total_size)
struct lmb lmb;
if (!total_size)
- return gd->ram_base + gd->ram_size;
+ return gd->ram_top;
/* found enough not-reserved memory to relocated U-Boot */
lmb_init();
--
2.17.1
Re: [PATCH 0/9] arm: dts: ls1028a: sync device tree with linux
Hi, Am 2021-09-01 00:03, schrieb Vladimir Oltean: On Tue, Aug 31, 2021 at 11:19:20PM +0200, Michael Walle wrote: > So this needs a v2, but in general, who do you expect to pick up your > patches? Mh, I haven't found a rule how patches are picked up in u-boot but most of the time they go through the qoriq git tree. Why do you ask? Just curious. > After reviewing the patches I noticed further cleanup to be done, we > need to replace >phy-mode = "sgmii-2500"; > with >phy-mode = "2500base-x"; > > and >phy-mode = "xfi"; > with >phy-mode = "10gbase-r"; > > and then delete the fsl_enetc.c driver's support for > PHY_INTERFACE_MODE_XFI and PHY_INTERFACE_MODE_XGMII, that's completely > bogus. Ok, that sounds easy enough. Will pick that up. "Will pick that up" means that you intend to do it? There are many device trees and drivers that use the non-standard "sgmii-2500" and "xfi" compatibles, not just LS1028A stuff. Mh, I leave this up to NXP, "10gbase-r" doesn't exist in phy_interface_strings[]. -michael
[PATCH v1 1/2] colibri-imx6ull: improve env badblock management
Use the complete 512kb (4 blocks) nand partition reserved for u-boot environment instead of just the first block, this allows the module to have a working environment even if 3 blocks are bad. Signed-off-by: Francesco Dolcini --- include/configs/colibri-imx6ull.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/colibri-imx6ull.h b/include/configs/colibri-imx6ull.h index 2fa3485173..a2753f8840 100644 --- a/include/configs/colibri-imx6ull.h +++ b/include/configs/colibri-imx6ull.h @@ -124,6 +124,11 @@ #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) +/* environment organization */ +#if defined(CONFIG_ENV_IS_IN_NAND) +#define CONFIG_ENV_RANGE (4 * CONFIG_ENV_SIZE) +#endif + /* NAND stuff */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 /* used to initialize CONFIG_SYS_NAND_BASE_LIST which is unused */ -- 2.25.1
[PATCH v1 2/2] colibri-imx7: improve env badblock management
Use the complete 512kb (4 blocks) nand partition reserved for u-boot environment instead of just the first block, this allows the module to have a working environment even if 3 blocks are bad. Signed-off-by: Francesco Dolcini --- include/configs/colibri_imx7.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/colibri_imx7.h b/include/configs/colibri_imx7.h index 2fffaa39c0..c3e12c81c9 100644 --- a/include/configs/colibri_imx7.h +++ b/include/configs/colibri_imx7.h @@ -192,6 +192,11 @@ #define CONFIG_SYS_INIT_SP_ADDR \ (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET) +/* environment organization */ +#if defined(CONFIG_ENV_IS_IN_NAND) +#define CONFIG_ENV_RANGE (4 * CONFIG_ENV_SIZE) +#endif + #ifdef CONFIG_TARGET_COLIBRI_IMX7_NAND /* NAND stuff */ #define CONFIG_SYS_MAX_NAND_DEVICE 1 -- 2.25.1
[PATCH v1 0/2] board: toradex: improve env badblock management for NAND variant boards
Use the complete 512kb (4 blocks) nand partition reserved for u-boot environment instead of just the first block, this allows the module to have a working environment even if 3 blocks are bad. Francesco Dolcini (2): colibri-imx6ull: improve env badblock management colibri-imx7: improve env badblock management include/configs/colibri-imx6ull.h | 5 + include/configs/colibri_imx7.h| 5 + 2 files changed, 10 insertions(+) -- 2.25.1
