Re: [U-Boot] [PATCH 8/8] riscv: dts: Support four cores SMP
Hi Bin
>
> Hi Rick,
>
> On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > Add CPU2 and CPU3 informations in cpus node
>
> nits: information
OK
>
> > to support four cores SMP booting.
> >
> > Signed-off-by: Rick Chen
> > Cc: KC Lin
> > Cc: Alan Kao
> > ---
> > arch/riscv/dts/ae350_32.dts | 51
> > ++---
> > arch/riscv/dts/ae350_64.dts | 51
> > ++---
> > 2 files changed, 96 insertions(+), 6 deletions(-)
> >
> > diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> > index 97b7cee..c794a7f 100644
> > --- a/arch/riscv/dts/ae350_32.dts
> > +++ b/arch/riscv/dts/ae350_32.dts
> > @@ -62,6 +62,48 @@
> > compatible = "riscv,cpu-intc";
> > };
> > };
> > + CPU2: cpu@2 {
> > + device_type = "cpu";
> > + reg = <2>;
> > + status = "okay";
> > + compatible = "riscv";
> > + riscv,isa = "rv32imafdc";
> > + riscv,priv-major = <1>;
> > + riscv,priv-minor = <10>;
> > + mmu-type = "riscv,sv32";
> > + clock-frequency = <6000>;
> > + i-cache-size = <0x8000>;
> > + i-cache-line-size = <32>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <32>;
> > + next-level-cache = <>;
> > + CPU2_intc: interrupt-controller {
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + compatible = "riscv,cpu-intc";
> > + };
> > + };
> > + CPU3: cpu@3 {
> > + device_type = "cpu";
> > + reg = <3>;
> > + status = "okay";
> > + compatible = "riscv";
> > + riscv,isa = "rv32imafdc";
> > + riscv,priv-major = <1>;
> > + riscv,priv-minor = <10>;
> > + mmu-type = "riscv,sv32";
> > + clock-frequency = <6000>;
> > + i-cache-size = <0x8000>;
> > + i-cache-line-size = <32>;
> > + d-cache-size = <0x8000>;
> > + d-cache-line-size = <32>;
> > + next-level-cache = <>;
> > + CPU3_intc: interrupt-controller {
> > + #interrupt-cells = <1>;
> > + interrupt-controller;
> > + compatible = "riscv,cpu-intc";
> > + };
> > + };
> > };
> >
> > L2: l2-cache@e050 {
> > @@ -94,7 +136,8 @@
> > interrupt-controller;
> > reg = <0xe400 0x200>;
> > riscv,ndev=<71>;
> > - interrupts-extended = <_intc 11 _intc 9
> > _intc 11 _intc 9>;
> > + interrupts-extended = <_intc 11 _intc 9
> > _intc 11 _intc 9
> > +
> > _intc 11 _intc 9 _intc
> > 11 _intc 9>;
>
> The indentation looks wrong.
OK. I will fix it.
Thanks
Rick
>
> > };
> >
> > plic1: interrupt-controller@e640 {
> > @@ -104,12 +147,14 @@
> > interrupt-controller;
> > reg = <0xe640 0x40>;
> > riscv,ndev=<2>;
> > - interrupts-extended = <_intc 3 _intc 3>;
> > + interrupts-extended = <_intc 3 _intc 3
> > +
> > _intc 3 _intc 3>;
> > };
> >
> > plmt0@e600 {
> > compatible = "riscv,plmt0";
> > - interrupts-extended = <_intc 7 _intc 7>;
> > + interrupts-extended = <_intc 7 _intc 7
> > +
> > _intc 7 _intc 7>;
> > reg = <0xe600 0x10>;
> > };
> > };
>
> [snip]
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] armv8: fsl-layerscape: fix warning if no hwconfig is defined
if no hwconfig variable is defined for a platform and we try to get the
subarg of hwconfig, we receive a warning:
WARNING: Calling __hwconfig without a buffer and before environment is ready
Therefore, if hwconfig is not found return without further processing.
Signed-off-by: Pankaj Bansal
---
Notes:
V2:
- Add copyright year in file that has been updated
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index 8fd6c751c6..b42beca6e1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017 NXP
+ * Copyright 2017, 2019 NXP
* Copyright 2014-2015 Freescale Semiconductor, Inc.
*/
@@ -1072,6 +1072,8 @@ static void config_core_prefetch(void)
if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
buf = buffer;
+ else
+ return;
prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
, buf);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: fsl-layerscape: fix warning if no hwconfig is defined
if no hwconfig variable is defined for a platform and we try to get the
subarg of hwconfig, we receive a warning:
WARNING: Calling __hwconfig without a buffer and before environment is ready
Therefore, if hwconfig is not found return without further processing.
Signed-off-by: Pankaj Bansal
---
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
index dee96afe2d..46e4b290ad 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/cpu.c
@@ -1065,6 +1065,8 @@ static void config_core_prefetch(void)
if (env_get_f("hwconfig", buffer, sizeof(buffer)) > 0)
buf = buffer;
+ else
+ return;
prefetch_arg = hwconfig_subarg_f("core_prefetch", "disable",
, buf);
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] dm: rtc: random Gitlab results for dm_test_rtc_dual()
Hello Simon, the gitlab 'sandbox test.py' job seems to be kind of a lottery: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/25678 Job succeeded https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/25499 /u-boot-efi/test/dm/rtc.c:167, dm_test_rtc_dual(): -EINVAL == cmp_times(, , false): Expected -22, got 0\r\r\nFailures: 1'.endswith dm_test_rtc_dual() fails or succeeds for the same code. @Tom: Did you also see such spurious results? At first sight I could not anything wrong in the dm_test_rtc_dual() test assuming that the Gitlab environment provides a monotonic clock for the time() function. The findings below do not explain the problem: now2 is read but never used. We are testing that we can get the time from emul2 later on. So I think this line is not needed. The offset of emul1 is not set before reading now1. If it were -2 (but I would not know why it should get to that value), than setting offset + 1 for emul2 would be a NOP. So shouldn't we set the offset of emul1 to a well defined value before reading now1? Shouldn't dm_test_rtc_dual() reset the offset of emul2 to 0 before returning? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Alan,
On Thu, Oct 31, 2019 at 9:00 AM Alan Kao wrote:
>
> Hi Bin,
>
> Thanks for the critics. Comments below.
> On Wed, Oct 30, 2019 at 06:38:00PM +0800, Bin Meng wrote:
> > Hi Rick,
> >
> > On Wed, Oct 30, 2019 at 10:50 AM Rick Chen wrote:
> > >
> > > Hi Bin
> > >
> > > >
> > > > Hi Rick,
> > > >
> > > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> > > > >
> > > > > From: Rick Chen
> > > > >
> > > > > It will work fine due to hart 0 always will be main
> > > > > hart coincidentally. When develop SPL flow, I try to
> > > > > force other harts to be main hart. And it will go
> > > > > wrong in sending IPI flow. So fix it.
> > > >
> > > > Fix what? Does this commit contain 2 fixes, or just 1 fix?
> > >
> > > Yes, it include two fixs. But they will cause one negative result
> > > that only hart 0 can send ipi to other harts.
> > >
> > > >
> > > > >
> > > > > Having this fix, any hart can be main hart in U-Boot SPL
> > > > > theoretically, but it still fail somewhere. After dig in
> > > > > and found there is an assumption that hart 0 shall be
> > > > > main hart in OpenSbi.
> > > >
> > > > So does this mean there is a bug in OpenSBI too?
> > >
> > > I am not sure if it is a bug. Maybe it is a compatible issue.
> > > There is a limitation that only hart 0 can be main hart in OpenSBI.
> >
> > I don't think OpenSBI has such limitation.
> >
>
> Please check the source.
> https://github.com/riscv/opensbi/blob/master/firmware/fw_base.S#L54
>
> Apparently, the FIRST TWO LINEs of the initialization are the
> 1. get hart ID.
> 2. determine which route to take based on their ID respectively.
>
This is true only for the very first a few instructions when OpenSBI
boots. Later OpenSBI main initialization does not require hart to be
zero.
> So, I do think OpenSBI has this signature, if you are not willing to call it
> a limitation.
>
> > > But any hart can be main hart in U-Boot.
> > >
> > > In general case, hart 0 will be main and it is fine when U-Boot jump ot
> > > OpenSBI.
> > > But if we force hart 1 to be main hart, when hart 0 jump to OPenSBI from
> > > U-Boot,
> > > It will do relocation flow in OpenSBI which willcorrupt U-Boot SPL,
> > > but hart 0 still in U-Boot SPL.
> > >
> > > >
> > > > >
> > > > > After some work-arounds, it can pass the verifications
> > > > > that any hart can be main hart and boots U-Boot SPL ->
> > > > > OpenSbi -> U-Boot proper -> Linux Kernel successfully.
> > > > >
> > > >
> > > > It's a bit hard for me to understand what was described here in the
> > > > commit message. Maybe you need rewrite something.
> > >
> > > OK. I will rewrite this commit message.
> > >
> > > >
> > > > > Signed-off-by: Rick Chen
> > > > > Cc: KC Lin
> > > > > Cc: Alan Kao
> > > > > ---
> > > > > arch/riscv/lib/andes_plic.c | 11 +++
> > > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> > > > > index 28568e4..42394b9 100644
> > > > > --- a/arch/riscv/lib/andes_plic.c
> > > > > +++ b/arch/riscv/lib/andes_plic.c
> > > > > @@ -19,7 +19,7 @@
> > > > > #include
> > > > >
> > > > > /* pending register */
> > > > > -#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 +
> > > > > (hart) * 8)
> > > > > +#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 +
> > > > > ((hart) / 4) * 4)
> > > > > /* enable register */
> > > > > #define ENABLE_REG(base, hart) ((ulong)(base) + 0x2000 + (hart) *
> > > > > 0x80)
> > > > > /* claim register */
> > > > > @@ -46,7 +46,7 @@ static int init_plic(void);
> > > > >
> > > > > static int enable_ipi(int hart)
> > > > > {
> > > > > - int en;
> > > > > + unsigned int en;
> > > >
> > > > Is this for some compiler warning fix?
> > >
> > > No, it is not a warning fix. It is a bug fix.
> > > I hope en can be 0x80808080 instead of 0x80808080,
> >
> > But it is int, which is only 32-bit. The example you gave was a 64-bit
> > number.
> >
>
> Please consider the following simple program:
>
> > #define MASK 0x80808080
> >int main(){
> >int en;
> >en = MASK;
> >printf("%x, shifted %x\n", en, en >> 1);
> >return 0;
> >}
>
> Would you mind sharing what you get after running this on your x86_64
> (if you have one) computer? Really appreiciate that.
>
> The almost identical episode is in the patch, specifically,
> > en = ENABLE_HART_IPI >> hart
Yes, this is a bug. But I was confused by Rick's comments as he was
using a 64-bit number as int is never to be a 64-bit for both 32-bit
and 64-bit.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] spl: cache: Allow cache drivers in SPL
Hi Bin Bin Meng 於 2019年10月31日 週四 上午11:02寫道： > > Hi Rick, > > On Thu, Oct 31, 2019 at 10:53 AM Rick Chen wrote: > > > > Hi Bin > > > > > > > > Hi Rick, > > > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote: > > > > > > > > From: Rick Chen > > > > > > > > When ax25-ae350 try to enable v5l2 cache > > > > driver in SPL configuration, it need this > > > > option for cache support in SPL. > > > > > > > > Signed-off-by: Rick Chen > > > > Cc: KC Lin > > > > Cc: Alan Kao > > > > --- > > > > common/spl/Kconfig | 7 +++ > > > > drivers/Makefile | 1 + > > > > 2 files changed, 8 insertions(+) > > > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > > index 86d7edf..4c4023a 100644 > > > > --- a/common/spl/Kconfig > > > > +++ b/common/spl/Kconfig > > > > @@ -456,6 +456,13 @@ config SPL_CRYPTO_SUPPORT > > > > this option to build the drivers in drivers/crypto as part of > > > > an > > > > SPL build. > > > > > > > > +config SPL_CACHE_SUPPORT > > > > > > nits: please insert this option per alphabetical order, so it should > > > come before SPL_CPU > > > > OK > > > > > > > > > + bool "Support CACHE drivers" > > > > + help > > > > + Enable CACHE drivers in SPL. These drivers can store data so > > > > that > > > > + future requests for that data can be served faster. Enable > > > > this option > > > > > > The description here "store data so that ..." does not apply to cache > > > drivers > > > > Do you have any suggestions about how to describe it more precisely ? > > > > The descriptions says drivers can store data, but cache driver does > not store data at all. I think you enabled it just for boot time > performance? Yes, so the description mention about "served faster", it can represent improve boot time performance widely. Maybe you think store data is that kind of store data in flash. Cache will store data in it, so CPU can execute more faster. > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
On Wed, Oct 30, 2019 at 09:07:05PM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 30 Oct 2019 at 10:15, Simon Glass wrote: > > > > Hi Tom, > > > > On Wed, 30 Oct 2019 at 09:58, Tom Rini wrote: > > > > > > On Wed, Oct 30, 2019 at 09:12:39AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Wed, 30 Oct 2019 at 07:15, Tom Rini wrote: > > > > > > > > > > On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > > > > > > > > > > > Convert buildman to Python 3 and make it use that, to meet the > > > > > > > 2020 > > > > > > > deadline. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > --- > > > > > > > > > > > > > > Changes in v2: None > > > > > > > > > > > > > > tools/buildman/board.py | 7 +-- > > > > > > > tools/buildman/bsettings.py | 20 +++ > > > > > > > tools/buildman/builder.py | 45 > > > > > > > tools/buildman/builderthread.py | 24 - > > > > > > > tools/buildman/buildman.py | 10 ++-- > > > > > > > tools/buildman/control.py | 40 +++--- > > > > > > > tools/buildman/func_test.py | 16 +++--- > > > > > > > tools/buildman/test.py | 22 > > > > > > > tools/buildman/toolchain.py | 93 > > > > > > > + > > > > > > > 9 files changed, 139 insertions(+), 138 deletions(-) > > > > > > > > > > > > I am a bit mystified by this: > > > > > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > > > > > > > > > > > It runs locally and I cannot see why it is not using unicode. Are > > > > > > there instructions on how to get to the same Python version as > > > > > > gitlab? > > > > > > I fear a steep learning curve coming. > > > > > > > > > > First, I think the problem is this series will also need the test.py > > > > > python3 series as that does a few more things to get and provide a > > > > > python3 environment to use. I'll try and throw something together to > > > > > test that shortly. > > > > > > > > > > Second, to have the same environment locally: > > > > > $ sudo docker pull > > > > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 > > > > > > > > > > And change the tag to whatever .gitlab-ci.yml says we use. That one > > > > > is > > > > > what the test.py series brings us up to, and is newer than your > > > > > failing > > > > > job. > > > > > > > > > > $ sudo docker run --rm -it -v > > > > > /your/local/u-boot/clone/..:/build/u-boot \ > > > > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash > > > > > > > > > > And don't pass --rm if you don't want the image deleted once you exit. > > > > > That will put you in a bash prompt as the user we run everything as. > > > > > Follow the steps in the job as described in .gitlab-ci.yml to do a > > > > > build > > > > > by hand. > > > > > > > > > > And yes, you want to pass in one level before your clone so that in > > > > > the > > > > > container you have /build/u-boot/u-boot > > > > > > > > Thank you, that is very helpful! > > > > > > > > It seems like the default file encoding for open() is different. I'll > > > > try again and hopefully send a v2 series soon. > > > > > > Ah, yeah. That reminded me of > > > http://patchwork.ozlabs.org/patch/1183213/ which ends up with telling > > > open to use utf-8 and then possibly some other places we need to > > > decode() and allow for errors to replace characters as needed rather > > > than be fatal. I think you might have a case of the latter where it's > > > found 'ä' or similar in the log and can't just turn it to ascii without > > > being allowed to replace. > > > > I think I have that patch. My tree is building here: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1158 > > > > But perhaps I picked up an earlier version? Is it close to being applied? > > Good news is that I got a passing build on gitlab. I should be able > send the series out tomorrow. The last patch is RFC but everything > else should be ready for review. Great, thanks. I'm testing the test.py series to merge currently. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] riscv: Fix clear bss loop in the start-up code
Hi Bin > > Hi Rick, > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote: > > > > From: Rick Chen > > > > For RV64, it will use sd instruction to clear t0 > > register, and the increament will be 8 bytes. So > > if the difference between__bss_strat and __bss_end > > was not 8 bytes aligned, the clear bss loop will > > overflow and acks like system hang. > > > > Signed-off-by: Rick Chen > > Cc: KC Lin > > Cc: Alan Kao > > --- > > arch/riscv/cpu/start.S | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S > > index 0a2ce6d..ee6d471 100644 > > --- a/arch/riscv/cpu/start.S > > +++ b/arch/riscv/cpu/start.S > > @@ -174,7 +174,7 @@ spl_clear_bss: > > spl_clear_bss_loop: > > SREGzero, 0(t0) > > addit0, t0, REGBYTES > > - bne t0, t1, spl_clear_bss_loop > > + blt t0, t1, spl_clear_bss_loop > > This leaves bss section not completely zeroed. I don't think this will clear bss section incompletely. Can you check it again ? Or explain more details why you think so ? Thanks Rick > > > > > spl_stack_gd_setup: > > jal spl_relocate_stack_gd > > @@ -324,7 +324,7 @@ clear_bss: > > clbss_l: > > SREGzero, 0(t0) /* clear loop... */ > > addit0, t0, REGBYTES > > - bne t0, t1, clbss_l > > + blt t0, t1, clbss_l > > > > relocate_secondary_harts: > > #ifdef CONFIG_SMP > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] ARM: MediaTek: Add support for MediaTek MT8518 SoC
On Mon, Oct 21, 2019 at 02:59:04PM +0800, mingming lee wrote:
> Add support for MediaTek MT8518 SoC. This include the file
> that will initialize the SoC after boot and its device tree.
>
> Signed-off-by: mingming lee
> ---
> Changes for v2:
>-drop unused 'device' in dtsi to keep it simple
Please fix problems such as:
+drivers/clk/mediatek/clk-mt8518.c:1294:35: error: 'top7_cg_regs'
defined but not used [-Werror=unused-const-variable=]
+ static const struct mtk_gate_regs top7_cg_regs = {
+ ^~~~
+drivers/clk/mediatek/clk-mt8518.c:1288:35: error: 'top6_cg_regs'
defined but not used [-Werror=unused-const-variable=]
+ static const struct mtk_gate_regs top6_cg_regs = {
+cc1: all warnings being treated as errors
+make[4]: *** [drivers/clk/mediatek/clk-mt8518.o] Error 1
+make[3]: *** [drivers/clk/mediatek] Error 2
+make[2]: *** [drivers/clk] Error 2
+make[1]: *** [drivers] Error 2
and ensure everything builds without warning, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
Hi Tom, On Wed, 30 Oct 2019 at 10:15, Simon Glass wrote: > > Hi Tom, > > On Wed, 30 Oct 2019 at 09:58, Tom Rini wrote: > > > > On Wed, Oct 30, 2019 at 09:12:39AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 30 Oct 2019 at 07:15, Tom Rini wrote: > > > > > > > > On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > > > > > > > > > Convert buildman to Python 3 and make it use that, to meet the 2020 > > > > > > deadline. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > Changes in v2: None > > > > > > > > > > > > tools/buildman/board.py | 7 +-- > > > > > > tools/buildman/bsettings.py | 20 +++ > > > > > > tools/buildman/builder.py | 45 > > > > > > tools/buildman/builderthread.py | 24 - > > > > > > tools/buildman/buildman.py | 10 ++-- > > > > > > tools/buildman/control.py | 40 +++--- > > > > > > tools/buildman/func_test.py | 16 +++--- > > > > > > tools/buildman/test.py | 22 > > > > > > tools/buildman/toolchain.py | 93 > > > > > > + > > > > > > 9 files changed, 139 insertions(+), 138 deletions(-) > > > > > > > > > > I am a bit mystified by this: > > > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > > > > > > > > > It runs locally and I cannot see why it is not using unicode. Are > > > > > there instructions on how to get to the same Python version as gitlab? > > > > > I fear a steep learning curve coming. > > > > > > > > First, I think the problem is this series will also need the test.py > > > > python3 series as that does a few more things to get and provide a > > > > python3 environment to use. I'll try and throw something together to > > > > test that shortly. > > > > > > > > Second, to have the same environment locally: > > > > $ sudo docker pull > > > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 > > > > > > > > And change the tag to whatever .gitlab-ci.yml says we use. That one is > > > > what the test.py series brings us up to, and is newer than your failing > > > > job. > > > > > > > > $ sudo docker run --rm -it -v /your/local/u-boot/clone/..:/build/u-boot > > > > \ > > > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash > > > > > > > > And don't pass --rm if you don't want the image deleted once you exit. > > > > That will put you in a bash prompt as the user we run everything as. > > > > Follow the steps in the job as described in .gitlab-ci.yml to do a build > > > > by hand. > > > > > > > > And yes, you want to pass in one level before your clone so that in the > > > > container you have /build/u-boot/u-boot > > > > > > Thank you, that is very helpful! > > > > > > It seems like the default file encoding for open() is different. I'll > > > try again and hopefully send a v2 series soon. > > > > Ah, yeah. That reminded me of > > http://patchwork.ozlabs.org/patch/1183213/ which ends up with telling > > open to use utf-8 and then possibly some other places we need to > > decode() and allow for errors to replace characters as needed rather > > than be fatal. I think you might have a case of the latter where it's > > found 'ä' or similar in the log and can't just turn it to ascii without > > being allowed to replace. > > I think I have that patch. My tree is building here: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1158 > > But perhaps I picked up an earlier version? Is it close to being applied? Good news is that I got a passing build on gitlab. I should be able send the series out tomorrow. The last patch is RFC but everything else should be ready for review. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] spl: cache: Allow cache drivers in SPL
Hi Rick, On Thu, Oct 31, 2019 at 10:53 AM Rick Chen wrote: > > Hi Bin > > > > > Hi Rick, > > > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote: > > > > > > From: Rick Chen > > > > > > When ax25-ae350 try to enable v5l2 cache > > > driver in SPL configuration, it need this > > > option for cache support in SPL. > > > > > > Signed-off-by: Rick Chen > > > Cc: KC Lin > > > Cc: Alan Kao > > > --- > > > common/spl/Kconfig | 7 +++ > > > drivers/Makefile | 1 + > > > 2 files changed, 8 insertions(+) > > > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > > index 86d7edf..4c4023a 100644 > > > --- a/common/spl/Kconfig > > > +++ b/common/spl/Kconfig > > > @@ -456,6 +456,13 @@ config SPL_CRYPTO_SUPPORT > > > this option to build the drivers in drivers/crypto as part of an > > > SPL build. > > > > > > +config SPL_CACHE_SUPPORT > > > > nits: please insert this option per alphabetical order, so it should > > come before SPL_CPU > > OK > > > > > > + bool "Support CACHE drivers" > > > + help > > > + Enable CACHE drivers in SPL. These drivers can store data so > > > that > > > + future requests for that data can be served faster. Enable this > > > option > > > > The description here "store data so that ..." does not apply to cache > > drivers > > Do you have any suggestions about how to describe it more precisely ? > The descriptions says drivers can store data, but cache driver does not store data at all. I think you enabled it just for boot time performance? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] riscv: ax25: cache: Add SPL_RISCV_MMODE for SPL
Hi Rick,
On Thu, Oct 31, 2019 at 10:31 AM Rick Chen wrote:
>
> Hi Bin
>
> >
> > Hi Rick,
> >
> > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> > >
> > > From: Rick Chen
> > >
> > > The mcache_ctl csr only can be manipulated in M mode.
> > > Add SPL_RISCV_MMODE for U-Boot SPL to control cache
> > > operation.
> > >
> > > Signed-off-by: Rick Chen
> > > Cc: KC Lin
> > > Cc: Alan Kao
> > > ---
> > > arch/riscv/cpu/ax25/cache.c | 60
> > > ++---
> > > 1 file changed, 46 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> > > index 41de30c..9437e81 100644
> > > --- a/arch/riscv/cpu/ax25/cache.c
> > > +++ b/arch/riscv/cpu/ax25/cache.c
> > > @@ -11,18 +11,46 @@
> > > #include
> > >
> > > #ifdef CONFIG_RISCV_NDS_CACHE
> > > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> >
> > Use CONFIG_IS_ENABLED(RISCV_MMODE)
> >
> > > /* mcctlcommand */
> > > #define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> > >
> > > /* D-cache operation */
> > > #define CCTL_L1D_WBINVAL_ALL 6
> > > #endif
> > > +#endif
> > > +
> > > +#ifdef CONFIG_V5L2_CACHE
> > > +static void _cache_enable(void)
> > > +{
> > > + struct udevice *dev = NULL;
> > > +
> > > + uclass_find_first_device(UCLASS_CACHE, );
> > > +
> > > + if (dev)
> > > + cache_enable(dev);
> > > +}
> > > +
> > > +static void _cache_disable(void)
> > > +{
> > > + struct udevice *dev = NULL;
> > > +
> > > + uclass_find_first_device(UCLASS_CACHE, );
> > > +
> > > + if (dev)
> > > + cache_disable(dev);
> > > +}
> > > +#endif
> > >
> > > void flush_dcache_all(void)
> > > {
> > > +#if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > > #ifdef CONFIG_RISCV_NDS_CACHE
> > > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > > csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> > > #endif
> > > +#endif
> > > +#endif
> > > }
> > >
> > > void flush_dcache_range(unsigned long start, unsigned long end)
> > > @@ -39,6 +67,7 @@ void icache_enable(void)
> > > {
> > > #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > > #ifdef CONFIG_RISCV_NDS_CACHE
> > > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > > asm volatile (
> > > "csrr t1, mcache_ctl\n\t"
> > > "ori t0, t1, 0x1\n\t"
> > > @@ -46,12 +75,14 @@ void icache_enable(void)
> > > );
> > > #endif
> > > #endif
> > > +#endif
> > > }
> > >
> > > void icache_disable(void)
> > > {
> > > #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > > #ifdef CONFIG_RISCV_NDS_CACHE
> > > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > > asm volatile (
> > > "fence.i\n\t"
> > > "csrr t1, mcache_ctl\n\t"
> >
> > Could you please add a patch to replace the CSR name with CSR number?
> > This way an upstream GCC to build this code without any issue.
>
> Thanks for your suggestions.
> But I prefer not modify it in this patchs for SPL.
>
Yes, I was saying an additional patch. Definitely not this patch.
> I will send another patch to modify as your suggestions.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] spl: cache: Allow cache drivers in SPL
Hi Bin > > Hi Rick, > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote: > > > > From: Rick Chen > > > > When ax25-ae350 try to enable v5l2 cache > > driver in SPL configuration, it need this > > option for cache support in SPL. > > > > Signed-off-by: Rick Chen > > Cc: KC Lin > > Cc: Alan Kao > > --- > > common/spl/Kconfig | 7 +++ > > drivers/Makefile | 1 + > > 2 files changed, 8 insertions(+) > > > > diff --git a/common/spl/Kconfig b/common/spl/Kconfig > > index 86d7edf..4c4023a 100644 > > --- a/common/spl/Kconfig > > +++ b/common/spl/Kconfig > > @@ -456,6 +456,13 @@ config SPL_CRYPTO_SUPPORT > > this option to build the drivers in drivers/crypto as part of an > > SPL build. > > > > +config SPL_CACHE_SUPPORT > > nits: please insert this option per alphabetical order, so it should > come before SPL_CPU OK > > > + bool "Support CACHE drivers" > > + help > > + Enable CACHE drivers in SPL. These drivers can store data so that > > + future requests for that data can be served faster. Enable this > > option > > The description here "store data so that ..." does not apply to cache drivers Do you have any suggestions about how to describe it more precisely ? Thanks Rick > > > + to build the drivers in drivers/cache as part of an SPL build. > > + > > config SPL_HASH_SUPPORT > > bool "Support hashing drivers" > > select SHA1 > > diff --git a/drivers/Makefile b/drivers/Makefile > > index a4bb5e4..5d300df 100644 > > --- a/drivers/Makefile > > +++ b/drivers/Makefile > > @@ -33,6 +33,7 @@ ifdef CONFIG_SPL_BUILD > > obj-$(CONFIG_SPL_BOOTCOUNT_LIMIT) += bootcount/ > > obj-$(CONFIG_SPL_CPU_SUPPORT) += cpu/ > > obj-$(CONFIG_SPL_CRYPTO_SUPPORT) += crypto/ > > +obj-$(CONFIG_SPL_CACHE_SUPPORT) += cache/ > > ditto OK > > > obj-$(CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT) += ddr/fsl/ > > obj-$(CONFIG_ARMADA_38X) += ddr/marvell/a38x/ > > obj-$(CONFIG_ARMADA_XP) += ddr/marvell/axp/ > > -- > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8] riscv: ax25: cache: Add SPL_RISCV_MMODE for SPL
Hi Bin
>
> Hi Rick,
>
> On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> >
> > From: Rick Chen
> >
> > The mcache_ctl csr only can be manipulated in M mode.
> > Add SPL_RISCV_MMODE for U-Boot SPL to control cache
> > operation.
> >
> > Signed-off-by: Rick Chen
> > Cc: KC Lin
> > Cc: Alan Kao
> > ---
> > arch/riscv/cpu/ax25/cache.c | 60
> > ++---
> > 1 file changed, 46 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> > index 41de30c..9437e81 100644
> > --- a/arch/riscv/cpu/ax25/cache.c
> > +++ b/arch/riscv/cpu/ax25/cache.c
> > @@ -11,18 +11,46 @@
> > #include
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
>
> Use CONFIG_IS_ENABLED(RISCV_MMODE)
>
> > /* mcctlcommand */
> > #define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> >
> > /* D-cache operation */
> > #define CCTL_L1D_WBINVAL_ALL 6
> > #endif
> > +#endif
> > +
> > +#ifdef CONFIG_V5L2_CACHE
> > +static void _cache_enable(void)
> > +{
> > + struct udevice *dev = NULL;
> > +
> > + uclass_find_first_device(UCLASS_CACHE, );
> > +
> > + if (dev)
> > + cache_enable(dev);
> > +}
> > +
> > +static void _cache_disable(void)
> > +{
> > + struct udevice *dev = NULL;
> > +
> > + uclass_find_first_device(UCLASS_CACHE, );
> > +
> > + if (dev)
> > + cache_disable(dev);
> > +}
> > +#endif
> >
> > void flush_dcache_all(void)
> > {
> > +#if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> > #endif
> > +#endif
> > +#endif
> > }
> >
> > void flush_dcache_range(unsigned long start, unsigned long end)
> > @@ -39,6 +67,7 @@ void icache_enable(void)
> > {
> > #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "ori t0, t1, 0x1\n\t"
> > @@ -46,12 +75,14 @@ void icache_enable(void)
> > );
> > #endif
> > #endif
> > +#endif
> > }
> >
> > void icache_disable(void)
> > {
> > #if !CONFIG_IS_ENABLED(SYS_ICACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > asm volatile (
> > "fence.i\n\t"
> > "csrr t1, mcache_ctl\n\t"
>
> Could you please add a patch to replace the CSR name with CSR number?
> This way an upstream GCC to build this code without any issue.
Thanks for your suggestions.
But I prefer not modify it in this patchs for SPL.
I will send another patch to modify as your suggestions.
Thanks
Rick
>
> > @@ -60,24 +91,23 @@ void icache_disable(void)
> > );
> > #endif
> > #endif
> > +#endif
> > }
> >
> > void dcache_enable(void)
> > {
> > #if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > - struct udevice *dev = NULL;
> > -
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "ori t0, t1, 0x2\n\t"
> > "csrw mcache_ctl, t0\n\t"
> > );
> > -
> > - uclass_find_first_device(UCLASS_CACHE, );
> > -
> > - if (dev)
> > - cache_enable(dev);
> > +#endif
> > +#ifdef CONFIG_V5L2_CACHE
> > + _cache_enable();
> > +#endif
> > #endif
> > #endif
> > }
> > @@ -86,19 +116,17 @@ void dcache_disable(void)
> > {
> > #if !CONFIG_IS_ENABLED(SYS_DCACHE_OFF)
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > - struct udevice *dev = NULL;
> > -
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "andi t0, t1, ~0x2\n\t"
> > "csrw mcache_ctl, t0\n\t"
> > );
> > -
> > - uclass_find_first_device(UCLASS_CACHE, );
> > -
> > - if (dev)
> > - cache_disable(dev);
> > +#endif
> > +#ifdef CONFIG_V5L2_CACHE
> > + _cache_disable();
> > +#endif
> > #endif
> > #endif
> > }
> > @@ -108,6 +136,7 @@ int icache_status(void)
> > int ret = 0;
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if defined(CONFIG_RISCV_MMODE) || defined(CONFIG_SPL_RISCV_MMODE)
> > asm volatile (
> > "csrr t1, mcache_ctl\n\t"
> > "andi %0, t1, 0x01\n\t"
> > @@ -116,6 +145,7 @@ int icache_status(void)
> > : "memory"
> > );
> > #endif
> > +#endif
> >
> > return ret;
> > }
> > @@ -125,6 +155,7 @@ int dcache_status(void)
> > int ret = 0;
> >
> > #ifdef CONFIG_RISCV_NDS_CACHE
> > +#if
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Bin
>
> Hi Rick,
>
> On Wed, Oct 30, 2019 at 10:50 AM Rick Chen wrote:
> >
> > Hi Bin
> >
> > >
> > > Hi Rick,
> > >
> > > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> > > >
> > > > From: Rick Chen
> > > >
> > > > It will work fine due to hart 0 always will be main
> > > > hart coincidentally. When develop SPL flow, I try to
> > > > force other harts to be main hart. And it will go
> > > > wrong in sending IPI flow. So fix it.
> > >
> > > Fix what? Does this commit contain 2 fixes, or just 1 fix?
> >
> > Yes, it include two fixs. But they will cause one negative result
> > that only hart 0 can send ipi to other harts.
> >
> > >
> > > >
> > > > Having this fix, any hart can be main hart in U-Boot SPL
> > > > theoretically, but it still fail somewhere. After dig in
> > > > and found there is an assumption that hart 0 shall be
> > > > main hart in OpenSbi.
> > >
> > > So does this mean there is a bug in OpenSBI too?
> >
> > I am not sure if it is a bug. Maybe it is a compatible issue.
> > There is a limitation that only hart 0 can be main hart in OpenSBI.
>
> I don't think OpenSBI has such limitation.
OK.
But there is a hint in OpenSBI indeed.
Maybe it is just different interpretation each other.
/*
* Jump to warm-boot if this is not the first core booting,
* that is, for mhartid != 0
*/
>
> > But any hart can be main hart in U-Boot.
> >
> > In general case, hart 0 will be main and it is fine when U-Boot jump ot
> > OpenSBI.
> > But if we force hart 1 to be main hart, when hart 0 jump to OPenSBI from
> > U-Boot,
> > It will do relocation flow in OpenSBI which willcorrupt U-Boot SPL,
> > but hart 0 still in U-Boot SPL.
> >
> > >
> > > >
> > > > After some work-arounds, it can pass the verifications
> > > > that any hart can be main hart and boots U-Boot SPL ->
> > > > OpenSbi -> U-Boot proper -> Linux Kernel successfully.
> > > >
> > >
> > > It's a bit hard for me to understand what was described here in the
> > > commit message. Maybe you need rewrite something.
> >
> > OK. I will rewrite this commit message.
> >
> > >
> > > > Signed-off-by: Rick Chen
> > > > Cc: KC Lin
> > > > Cc: Alan Kao
> > > > ---
> > > > arch/riscv/lib/andes_plic.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> > > > index 28568e4..42394b9 100644
> > > > --- a/arch/riscv/lib/andes_plic.c
> > > > +++ b/arch/riscv/lib/andes_plic.c
> > > > @@ -19,7 +19,7 @@
> > > > #include
> > > >
> > > > /* pending register */
> > > > -#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 +
> > > > (hart) * 8)
> > > > +#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 +
> > > > ((hart) / 4) * 4)
> > > > /* enable register */
> > > > #define ENABLE_REG(base, hart) ((ulong)(base) + 0x2000 + (hart) * 0x80)
> > > > /* claim register */
> > > > @@ -46,7 +46,7 @@ static int init_plic(void);
> > > >
> > > > static int enable_ipi(int hart)
> > > > {
> > > > - int en;
> > > > + unsigned int en;
> > >
> > > Is this for some compiler warning fix?
> >
> > No, it is not a warning fix. It is a bug fix.
> > I hope en can be 0x80808080 instead of 0x80808080,
>
> But it is int, which is only 32-bit. The example you gave was a 64-bit number.
The verification runs on RV64, so it is a 64-bit number example.
Thanks
Rick
>
> > or it will cause IPI sending errors.
> >
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] riscv: ax25: add SPL support
Hi Bin > > Hi Rick, > > On Wed, Oct 30, 2019 at 8:42 AM Rick Chen wrote: > > > > Hi Bin > > > > > > > > Hi Rick, > > > > > > On Fri, Oct 25, 2019 at 2:17 PM Andes wrote: > > > > > > > > From: Rick Chen > > > > > > > > The U-Boot SPL will boot in M mode and load the > > > > FIT image which include OpenSbi and U-Boot proper > > > > > > nits: OpenSBI > > > > OK > > > > > > > > > images. After loading progress, it will jump to > > > > OpenSbi first and then U-Boot proper which will > > > > > > ditto > > > > OK > > > > > > > > > run in S mode. > > > > > > > > Signed-off-by: Rick Chen > > > > Cc: KC Lin > > > > Cc: Alan Kao > > > > --- > > > > arch/riscv/cpu/ax25/Kconfig | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/ax25/Kconfig > > > > index d411a79..8d8d71d 100644 > > > > --- a/arch/riscv/cpu/ax25/Kconfig > > > > +++ b/arch/riscv/cpu/ax25/Kconfig > > > > @@ -6,7 +6,9 @@ config RISCV_NDS > > > > imply RISCV_TIMER > > > > imply ANDES_PLIC if (RISCV_MMODE || SPL_RISCV_MMODE) > > > > imply ANDES_PLMT if (RISCV_MMODE || SPL_RISCV_MMODE) > > > > - imply V5L2_CACHE > > > > > > Why this is removed? > > > > Without CACHE_SUPPORT, the compiling will fail while enable V5l2_CACHE. > > That is why I remove it. I hope it can be enable manually. > > Because it will enlarge U-Boot SPL size. > > > > Could you please describe it in the commit message? OK. I will add it. Thanks Rick > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX
Hi Tim, I think I can answer some of your questions. On Wednesday, October 30, 2019 10:06:41 AM PDT Tim Harvey wrote: > External Email > > -- > > On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati wrote: > > This series will add support for OcteonTX and OcteonTX2 processsor based > > platforms. The Marvell/Cavium Octeon-TX 64-bit ARM based SoCs include > > the CN80XX, CN81XX and CN83XX while Octeon-TX2 64-bit ARM based SoCs > > include support for CN96XX and CN95XX. > > These SoC's have peripheral drivers based on PCI ECAM. > > > > Patches > > [1 -10] Add requied changes to PCI framework > > > > - [6] Add support for multi-memory region range > > - [7] EA in bridges > > - [8] SR-IOV > > > > [12] Add driver model support for RTC DS1337 driver > > [15 - 17] AHCI changes > > [18 - 27] Add OcteonTX drivers > > [28 - 29] Add OcteonTX/TX2 board files and configurations > > Suneel, > > Thanks for submitting this series! > > I've applied and built this and am testing on the Gateworks Newport > boards with the CN802x/CN803x (octeontx_81xx) and this is what I've > found: > - I get hung in the smc_call from smc_dram_size which your calling > with the function id of 0xc2000301. The older U-Boot from the Cavium > OcteonTX SDK-6.2.0-p3 used 0x43000301 and this works for me. Is there > a difference in our ATF version? ATF has indeed changed significantly. The current U-Boot requires an up-to- date ATF. I recall this was one of the changes we made with regards to getting the size of memory. > - configs/octeontx_81xx_defconfig - I have several changes I want to > make here, but perhaps some of these would warrant a custom config for > my boards > - you assume there is only a SPI NOR flash for env which we > personally don't use. The env system supports multiple env types so we > could just enable MMC as well as SPI but then I find all the > hard-coded CONFIG_ENV_* defines restrictive. I wonder if anyone has > defined a way for these to come from device-tree? We have not tested loading the environment from eMMC. It would be nice if the environment location could come from the device tree. > - you set loadaddr=04008 which only makes sense for systems with > over 1GiB of DRAM... perhaps we should lower that to > loadaddr=02008 for 1GiB systems (I don't think you can have less > than 1GiB?) > - I use DISTRO_DEFAULTS for a standard distro-friendly boot env... > I'm not sure why any board wouldn't do this these days and I think > that should be added > > I was able to functionally test mmc/i2c/gpio/pci/nic(BGX/RGX) and they > were all functioning well. > > When I enable SATA I find that it crashes on init: > GW6300-D1> sata info > Target spinup took 0 ms. > AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode > flags: 64bit ncq ilck stag pm led clo only pmp fbss pio slum part ccc apst > "Synchronous Abort" handler, esr 0x9606 > elr: 0052c240 lr : 005101bc (reloc) > elr: 3fecb240 lr : 3feaf1bc > x0 : 3be91380 x1 : > x2 : x3 : 3be9c100 > x4 : 0120 x5 : 3be9b800 > x6 : 0001 x7 : > x8 : 3ff46998 x9 : 0008 > x10: 3ff2e8c4 x11: 3ff2e8ca > x12: 3ff2e8cf x13: 3ff2e8d5 > x14: 3ff2e8da x15: 3ff2e8e0 > x16: 3ff2e8e6 x17: 3ff43362 > x18: 3be8ede0 x19: > x20: 3be9ab30 x21: 0002 > x22: 3be9ab30 x23: 0002 > x24: 3ff63aa4 x25: 3be9ab90 > x26: x27: > x28: x29: 3be881f0 > > Code: 928004a0 d65f03c0 f947 f94034e7 (f94008e7) > Resetting CPU ... > > I don't have NAND or SPI flash so can't test those. > > Best Regards, > > Tim NAND is not very common any more. Most boards use SPI flash, however. -Aaron ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
On Wednesday, October 30, 2019 3:05:25 PM PDT Tom Rini wrote: > External Email > > -- > > On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote: > > Hi all, > > > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > > and merging it upstream. > > [snip] > > I want to jump back up back to the top of this thread. And first I want > to say that I am glad that there is official desire to upstream support. > This is good. My concern is that the plan seems to be, at a very high > level, "get everything we have for every feature upstream". But as been > said elsewhere this would roughly double the total LOC for the project, > and it's not like we're a new project with a small handful of things :) > It's impossible for the community to review that much code in any > meaningful way over anything less than a period of several years. I > know you've said that to support various customer use cases you need all > sorts of other things, and while I'm certain that's true, I believe the > plan needs to be to step back and pick the smallest possible testable > unit, and upstream it. And add to it, small pieces at a time. Thanks! It might be easier if I were a maintainer for our SOC to limit the needed review of a fair bit of the code. I have already found I can cut out a large chunk of our code by removing support for our older models. Much of the code has been very well tested, for example our serdes initialization and DRAM initialization code. That's not to say I can't do some cleanup. The changes to U-Boot itself should be relatively small as long as I can keep much of our code under arch/mips/arch-octeon and arch/mips/cpu/octeon much like how our ARM code is. For anything that is applicable to other architectures I will place it in the appropriate locations. Our ARM code is quite a bit simpler than MIPS because on ARM most of the heavy lifting is done by our "BDK" bootloader as well as ATF. On ARM, U-Boot doesn't need to deal with SFPs, serdes initialization, DRAM initialization, hot plug or a myriad of other issues. I noticed the same with X86. If it weren't for these other layers the X86 code would also be quite large. I have already identified quite a few very large files that will be removed, such as the error handling code for or Octeon2 and earlier CPUs. Additionally I have identified a number of register definition files I can get rid of, including one that's 2.3MB in size! These files tend to be huge because they contain definitions for every single chip and revision as well as big and little endian definitions. On top of that, there are a huge number of comments. Each field contains all of the text that is in our hardware reference manuals. There is no dearth of comments. I should be able to cut the size of the remaining files to 1/4th their current size or even smaller. Some files will still remain quite large, however, such as our serdes initialization and DRAM initialization code (which I plan to re-architect because the original author didn't believe in functions due to stack limitations. (it is well commented though). If you ever want to learn all the gory details of DDR4 link training and finding trends and so-forth it's all in there. The current memory initialization code is over 1MB in size. I plan to cut this down and break it up in a clean manner. The initialization code has grown in complexity and size over the years as various instabilities have been identified and fixed. The DRAM initialization code for our OcteonTX2 CPU is almost as large, though this code has been cleaned up and re-written. There really is no way to avoid this. The OcteonTX and OcteonTX2 DDR initialization code is similar to that for Octeon. In the case of U-Boot on our ARM SoCs, though, initialization is done before U-Boot is loaded. I'll move the init code to drivers/ram/marvell/octeon. It will be about twice as large as the AXP driver (which only handles DDR3). The serdes init code I figure could go under drivers/soc/marvell/octeon. I noticed that there are several directories under drivers for memory. There's drivers/ram, drivers/memory and drivers/ddr. These should be consolidated. I think some code might be able to be common, such as the SPD decoding code. It's even possible that some algorithms might be able to be made common such as deskew training and read/write leveling. In terms of Octeon specific features, there really aren't too many of those but most of the ones we have are essential in the bootloader. There's no avoiding the Serdes and low-level network initialization. The serdes init code works across all networking interface types (SGMII, 1000Base-X, XAUI, RXAUI, XFI, XLAUI, 25G (XLAUI), SATA, PCIe, SRIO plus all the variants (i.e. KR). It also configures all the clocks and equalization. It's not like a simple gigabit NIC nor is it offloaded to some
Re: [U-Boot] Cavium/Marvell Octeon Support
On Wed, Oct 23, 2019 at 03:50:00AM +, Aaron Williams wrote: > Hi all, > > I have been tasked with porting our Octeon U-Boot to the latest U-Boot > and merging it upstream. [snip] I want to jump back up back to the top of this thread. And first I want to say that I am glad that there is official desire to upstream support. This is good. My concern is that the plan seems to be, at a very high level, "get everything we have for every feature upstream". But as been said elsewhere this would roughly double the total LOC for the project, and it's not like we're a new project with a small handful of things :) It's impossible for the community to review that much code in any meaningful way over anything less than a period of several years. I know you've said that to support various customer use cases you need all sorts of other things, and while I'm certain that's true, I believe the plan needs to be to step back and pick the smallest possible testable unit, and upstream it. And add to it, small pieces at a time. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT] Pull request: u-boot-clk (23.10.2019)
On Wed, Oct 23, 2019 at 12:38:47AM +0200, Lukasz Majewski wrote: > Dear Tom, > > Please find a PR for u-boot-clk branch: > > The following changes since commit 44510daea4d07fee736dd90411c4b503340b449e: > > dm: pinctrl: fix for introduce PINCONF_RECURSIVE option (2019-10-21 > 09:40:54 -0400) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-clk.git (branch master - > link below) > > for you to fetch changes up to 9a52be129c5b159269ac69a7ae0197eb02612f1d: > > test: clk: test clock self assignment (2019-10-22 16:14:05 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 5/5] Add support for the NXP IMXRT1050-EVK board
Signed-off-by: Giulio Benetti
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/imxrt1050-evk.dts| 124
arch/arm/dts/imxrt1050.dtsi | 73 +
arch/arm/mach-imx/imxrt/Kconfig | 11 +
board/freescale/imxrt1050-evk/Kconfig | 19 ++
board/freescale/imxrt1050-evk/MAINTAINERS | 6 +
board/freescale/imxrt1050-evk/Makefile| 6 +
board/freescale/imxrt1050-evk/imxrt1050-evk.c | 94 ++
configs/imxrt1050-evk_defconfig | 52
include/configs/imxrt1050-evk.h | 68 +
include/dt-bindings/clock/imxrt-clock.h | 272 ++
11 files changed, 727 insertions(+)
create mode 100644 arch/arm/dts/imxrt1050-evk.dts
create mode 100644 arch/arm/dts/imxrt1050.dtsi
create mode 100644 board/freescale/imxrt1050-evk/Kconfig
create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS
create mode 100644 board/freescale/imxrt1050-evk/Makefile
create mode 100644 board/freescale/imxrt1050-evk/imxrt1050-evk.c
create mode 100644 configs/imxrt1050-evk_defconfig
create mode 100644 include/configs/imxrt1050-evk.h
create mode 100644 include/dt-bindings/clock/imxrt-clock.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 62da168ef8..5ac490fa5e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -631,6 +631,8 @@ dtb-$(CONFIG_ARCH_IMX8) += \
dtb-$(CONFIG_ARCH_IMX8M) += fsl-imx8mq-evk.dtb
+dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb
+
dtb-$(CONFIG_RCAR_GEN2) += \
r8a7790-lager-u-boot.dtb \
r8a7790-stout-u-boot.dtb \
diff --git a/arch/arm/dts/imxrt1050-evk.dts b/arch/arm/dts/imxrt1050-evk.dts
new file mode 100644
index 00..8b5ec7fe9f
--- /dev/null
+++ b/arch/arm/dts/imxrt1050-evk.dts
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+/dts-v1/;
+#include "imxrt1050.dtsi"
+#include
+
+/ {
+ model = "NXP IMXRT1050-evk board";
+ compatible = "fsl,imxrt1050-evk", "fsl,imxrt1050";
+
+ chosen {
+ u-boot,dm-spl;
+ bootargs = "root=/dev/ram";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x8000 0x200>;
+ };
+
+ aliases {
+ serial0 =
+ };
+};
+
+ { /* console */
+ u-boot,dm-spl;
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart1>;
+ status = "okay";
+};
+
+ {
+ /*
+* Memory configuration from sdram datasheet IS42S32800G-6BLI
+*/
+ fsl,sdram-mux = /bits/ 8 ;
+ fsl,sdram-control = /bits/ 8 ;
+ fsl,sdram-timing = /bits/ 8 ;
+
+ bank1: bank@0 {
+ u-boot,dm-spl;
+ fsl,base-address = <0x8000>;
+ fsl,memory-size = ;
+ };
+};
+
+ {
+ u-boot,dm-spl;
+ pinctrl-names = "default";
+ pinctrl-0 = <_lpuart1>;
+
+ imxrt1050-evk {
+ u-boot,dm-spl;
+ pinctrl_lpuart1: lpuart1grp {
+ u-boot,dm-spl;
+ fsl,pins = <
+ MXRT1050_IOMUXC_GPIO_AD_B0_12_LPUART1_TXD
0xf1
+ MXRT1050_IOMUXC_GPIO_AD_B0_13_LPUART1_RXD
0xf1
+ >;
+ };
+
+ pinctrl_semc: semcgrp {
+ u-boot,dm-spl;
+ fsl,pins = <
+ MXRT1050_IOMUXC_GPIO_EMC_00_SEMC_DA00
0xf1/* SEMC_D0 */
+ MXRT1050_IOMUXC_GPIO_EMC_01_SEMC_DA01
0xf1/* SEMC_D1 */
+ MXRT1050_IOMUXC_GPIO_EMC_02_SEMC_DA02
0xf1/* SEMC_D2 */
+ MXRT1050_IOMUXC_GPIO_EMC_03_SEMC_DA03
0xf1/* SEMC_D3 */
+ MXRT1050_IOMUXC_GPIO_EMC_04_SEMC_DA04
0xf1/* SEMC_D4 */
+ MXRT1050_IOMUXC_GPIO_EMC_05_SEMC_DA05
0xf1/* SEMC_D5 */
+ MXRT1050_IOMUXC_GPIO_EMC_06_SEMC_DA06
0xf1/* SEMC_D6 */
+ MXRT1050_IOMUXC_GPIO_EMC_07_SEMC_DA07
0xf1/* SEMC_D7 */
+ MXRT1050_IOMUXC_GPIO_EMC_08_SEMC_DM00
0xf1/* SEMC_DM0 */
+ MXRT1050_IOMUXC_GPIO_EMC_09_SEMC_ADDR00
0xf1/* SEMC_A0 */
+ MXRT1050_IOMUXC_GPIO_EMC_10_SEMC_ADDR01
0xf1/* SEMC_A1 */
+ MXRT1050_IOMUXC_GPIO_EMC_11_SEMC_ADDR02
0xf1/* SEMC_A2 */
+ MXRT1050_IOMUXC_GPIO_EMC_12_SEMC_ADDR03
0xf1/* SEMC_A3 */
+ MXRT1050_IOMUXC_GPIO_EMC_13_SEMC_ADDR04
0xf1/* SEMC_A4 */
+
[U-Boot] [RFC PATCH 3/5] serial_lpuart: add support for i.MXRT
Add i.MXRT compatible string and cpu type support to lpuart driver,
to use little endian 32 bits configurations.
Also according to RM, the Receive RX FIFO Enable (RXFE) field in LPUART
FIFO register is bit 3, so this definition should change to 0x08 as done
for i.MX8. It needs also to set baudrate the same way as i.MX8 does.
Signed-off-by: Giulio Benetti
---
drivers/serial/serial_lpuart.c | 15 +++
include/fsl_lpuart.h | 3 ++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/serial_lpuart.c b/drivers/serial/serial_lpuart.c
index 4b0a964d1b..52b561b627 100644
--- a/drivers/serial/serial_lpuart.c
+++ b/drivers/serial/serial_lpuart.c
@@ -49,7 +49,7 @@
#define FIFO_RXSIZE_MASK 0x7
#define FIFO_RXSIZE_OFF0
#define FIFO_TXFE 0x80
-#ifdef CONFIG_ARCH_IMX8
+#if defined(CONFIG_ARCH_IMX8) || defined(CONFIG_ARCH_IMXRT)
#define FIFO_RXFE 0x08
#else
#define FIFO_RXFE 0x40
@@ -67,7 +67,8 @@ enum lpuart_devtype {
DEV_VF610 = 1,
DEV_LS1021A,
DEV_MX7ULP,
- DEV_IMX8
+ DEV_IMX8,
+ DEV_IMXRT,
};
struct lpuart_serial_platdata {
@@ -409,7 +410,8 @@ static int _lpuart32_serial_init(struct udevice *dev)
lpuart_write32(plat->flags, >match, 0);
- if (plat->devtype == DEV_MX7ULP || plat->devtype == DEV_IMX8) {
+ if (plat->devtype == DEV_MX7ULP || plat->devtype == DEV_IMX8 ||
+ plat->devtype == DEV_IMXRT) {
_lpuart32_serial_setbrg_7ulp(dev, gd->baudrate);
} else {
/* provide data bits, parity, stop bit, etc */
@@ -426,7 +428,8 @@ static int lpuart_serial_setbrg(struct udevice *dev, int
baudrate)
struct lpuart_serial_platdata *plat = dev_get_platdata(dev);
if (is_lpuart32(dev)) {
- if (plat->devtype == DEV_MX7ULP || plat->devtype == DEV_IMX8)
+ if (plat->devtype == DEV_MX7ULP || plat->devtype == DEV_IMX8 ||
+ plat->devtype == DEV_IMXRT)
_lpuart32_serial_setbrg_7ulp(dev, baudrate);
else
_lpuart32_serial_setbrg(dev, baudrate);
@@ -514,6 +517,8 @@ static int lpuart_serial_ofdata_to_platdata(struct udevice
*dev)
plat->devtype = DEV_VF610;
else if (!fdt_node_check_compatible(blob, node, "fsl,imx8qm-lpuart"))
plat->devtype = DEV_IMX8;
+ else if (!fdt_node_check_compatible(blob, node, "fsl,imxrt-lpuart"))
+ plat->devtype = DEV_IMXRT;
return 0;
}
@@ -533,6 +538,8 @@ static const struct udevice_id lpuart_serial_ids[] = {
{ .compatible = "fsl,vf610-lpuart"},
{ .compatible = "fsl,imx8qm-lpuart",
.data = LPUART_FLAG_REGMAP_32BIT_REG },
+ { .compatible = "fsl,imxrt-lpuart",
+ .data = LPUART_FLAG_REGMAP_32BIT_REG },
{ }
};
diff --git a/include/fsl_lpuart.h b/include/fsl_lpuart.h
index fc517d4b7f..511fb84367 100644
--- a/include/fsl_lpuart.h
+++ b/include/fsl_lpuart.h
@@ -4,7 +4,8 @@
*
*/
-#if defined(CONFIG_ARCH_MX7ULP) || defined(CONFIG_ARCH_IMX8)
+#if defined(CONFIG_ARCH_MX7ULP) || defined(CONFIG_ARCH_IMX8) || \
+ defined(CONFIG_ARCH_IMXRT)
struct lpuart_fsl_reg32 {
u32 verid;
u32 param;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 4/5] ram: add SDRAM driver for i.MXRT SoCs
Signed-off-by: Giulio Benetti
---
drivers/ram/Kconfig | 8 +
drivers/ram/Makefile | 2 +
drivers/ram/imxrt_sdram.c| 406 +++
include/dt-bindings/memory/imxrt-sdram.h | 168 ++
4 files changed, 584 insertions(+)
create mode 100644 drivers/ram/imxrt_sdram.c
create mode 100644 include/dt-bindings/memory/imxrt-sdram.h
diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig
index 568d8f2c6a..69b0233a48 100644
--- a/drivers/ram/Kconfig
+++ b/drivers/ram/Kconfig
@@ -54,5 +54,13 @@ config K3_AM654_DDRSS
config add support for the initialization of the external
SDRAM devices connected to DDR subsystem.
+config IMXRT_SDRAM
+ bool "Enable i.MXRT SDRAM support"
+ depends on RAM
+ help
+ i.MXRT family devices support smart external memory controller(SEMC)
+ to support external memories like sdram, psram & nand.
+ This driver is for the sdram memory interface with the SEMC.
+
source "drivers/ram/rockchip/Kconfig"
source "drivers/ram/stm32mp1/Kconfig"
diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile
index 976ec66df7..d3813e37e4 100644
--- a/drivers/ram/Makefile
+++ b/drivers/ram/Makefile
@@ -14,3 +14,5 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
obj-$(CONFIG_K3_AM654_DDRSS) += k3-am654-ddrss.o
obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
+
+obj-$(CONFIG_IMXRT_SDRAM) += imxrt_sdram.o
diff --git a/drivers/ram/imxrt_sdram.c b/drivers/ram/imxrt_sdram.c
new file mode 100644
index 00..7c157f60e2
--- /dev/null
+++ b/drivers/ram/imxrt_sdram.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* SDRAM Command Code */
+#define SD_CC_ARD 0x0 /* Master Bus (AXI) command - Read */
+#define SD_CC_AWR 0x1 /* Master Bus (AXI) command - Write */
+#define SD_CC_IRD 0x8 /* IP command - Read */
+#define SD_CC_IWR 0x9 /* IP command - Write */
+#define SD_CC_IMS 0xA /* IP command - Set Mode Register */
+#define SD_CC_IACT 0xB /* IP command - ACTIVE */
+#define SD_CC_IAF 0xC /* IP command - Auto Refresh */
+#define SD_CC_ISF 0xD /* IP Command - Self Refresh */
+#define SD_CC_IPRE 0xE /* IP command - Precharge */
+#define SD_CC_IPREA0xF /* IP command - Precharge ALL */
+
+#define SEMC_MCR_MDIS BIT(1)
+#define SEMC_MCR_DQSMD BIT(2)
+
+struct imxrt_semc_regs {
+ /* 0x0 */
+ u32 mcr;
+ u32 iocr;
+ u32 bmcr0;
+ u32 bmcr1;
+ u32 br[9];
+
+ /* 0x34 */
+ u32 res1;
+ u32 inten;
+ u32 intr;
+ /* 0x40 */
+ u32 sdramcr0;
+ u32 sdramcr1;
+ u32 sdramcr2;
+ u32 sdramcr3;
+ /* 0x50 */
+ u32 nandcr0;
+ u32 nandcr1;
+ u32 nandcr2;
+ u32 nandcr3;
+ /* 0x60 */
+ u32 norcr0;
+ u32 norcr1;
+ u32 norcr2;
+ u32 norcr3;
+ /* 0x70 */
+ u32 sramcr0;
+ u32 sramcr1;
+ u32 sramcr2;
+ u32 sramcr3;
+ /* 0x80 */
+ u32 dbicr0;
+ u32 dbicr1;
+ u32 res2[2];
+ /* 0x90 */
+ u32 ipcr0;
+ u32 ipcr1;
+ u32 ipcr2;
+ u32 ipcmd;
+ /* 0xA0 */
+ u32 iptxdat;
+ u32 res3[3];
+ /* 0xB0 */
+ u32 iprxdat;
+ u32 res4[3];
+ /* 0xC0 */
+ u32 sts[16];
+};
+
+#define SEMC_IOCR_MUX_A8_SHIFT 0
+#define SEMC_IOCR_MUX_CSX0_SHIFT 1
+#define SEMC_IOCR_MUX_CSX1_SHIFT 2
+#define SEMC_IOCR_MUX_CSX2_SHIFT 3
+#define SEMC_IOCR_MUX_CSX3_SHIFT 4
+#define SEMC_IOCR_MUX_RDY_SHIFT5
+
+struct imxrt_sdram_mux {
+ u8 a8;
+ u8 csx0;
+ u8 csx1;
+ u8 csx2;
+ u8 csx3;
+ u8 rdy;
+};
+
+#define SEMC_SDRAMCR0_PS_SHIFT 0
+#define SEMC_SDRAMCR0_BL_SHIFT 4
+#define SEMC_SDRAMCR0_COL_SHIFT8
+#define SEMC_SDRAMCR0_CL_SHIFT 10
+
+struct imxrt_sdram_control {
+ u8 memory_width;
+ u8 burst_len;
+ u8 no_columns;
+ u8 cas_latency;
+};
+
+#define SEMC_SDRAMCR1_PRE2ACT_SHIFT0
+#define SEMC_SDRAMCR1_ACT2RW_SHIFT 4
+#define SEMC_SDRAMCR1_RFRC_SHIFT 8
+#define SEMC_SDRAMCR1_WRC_SHIFT12
+
+struct imxrt_sdram_timing {
+ u8 trp;
+ u8 trcd;
+ u8 trfc;
+ u8 twr;
+#if TODO
+ u8 tmrd;
+ u8 txsr;
+ u8 tras;
+ u8 trc;
+#endif
+};
+
+enum imxrt_semc_bank {
+ SDRAM_BANK1,
+ SDRAM_BANK2,
+ SDRAM_BANK3,
+ SDRAM_BANK4,
+ MAX_SDRAM_BANK,
+};
+
+#define SEMC_BR_VLD_MASK 1
+#define SEMC_BR_MS_SHIFT 1
+
+struct bank_params {
+ enum imxrt_semc_bank target_bank;
+ u32 base_address;
+ u32 memory_size;
+};
+
[U-Boot] [RFC PATCH 2/5] pinctrl: add i.MXRT driver
Add i.MXRT pinctrl driver.
Signed-off-by: Giulio Benetti
---
drivers/pinctrl/nxp/Kconfig | 14 +
drivers/pinctrl/nxp/Makefile | 1 +
drivers/pinctrl/nxp/pinctrl-imxrt.c | 40 +
include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 +++
4 files changed, 1048 insertions(+)
create mode 100644 drivers/pinctrl/nxp/pinctrl-imxrt.c
create mode 100644 include/dt-bindings/pinctrl/pins-imxrt1050.h
diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
index f2e67ca231..ec55351e61 100644
--- a/drivers/pinctrl/nxp/Kconfig
+++ b/drivers/pinctrl/nxp/Kconfig
@@ -99,6 +99,20 @@ config PINCTRL_MXS
familiy, e.g. i.MX28. This feature depends on device tree
configuration.
+config PINCTRL_IMXRT
+ bool "IMXRT pinctrl driver"
+ depends on ARCH_IMXRT && PINCTRL_FULL
+ select DEVRES
+ select PINCTRL_IMX
+ help
+ Say Y here to enable the imxrt pinctrl driver
+
+ This provides a simple pinctrl driver for i.MXRT SoC familiy.
+ This feature depends on device tree configuration. This driver
+ is different from the linux one, this is a simple implementation,
+ only parses the 'fsl,pins' property and configure related
+ registers.
+
config PINCTRL_VYBRID
bool "Vybrid (vf610) pinctrl driver"
depends on ARCH_VF610 && PINCTRL_FULL
diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
index b86448aac9..066ca75b65 100644
--- a/drivers/pinctrl/nxp/Makefile
+++ b/drivers/pinctrl/nxp/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_IMX8) += pinctrl-imx8.o
obj-$(CONFIG_PINCTRL_IMX8M)+= pinctrl-imx8m.o
obj-$(CONFIG_PINCTRL_MXS) += pinctrl-mxs.o
obj-$(CONFIG_PINCTRL_VYBRID) += pinctrl-vf610.o
+obj-$(CONFIG_PINCTRL_IMXRT)+= pinctrl-imxrt.o
diff --git a/drivers/pinctrl/nxp/pinctrl-imxrt.c
b/drivers/pinctrl/nxp/pinctrl-imxrt.c
new file mode 100644
index 00..4a93941927
--- /dev/null
+++ b/drivers/pinctrl/nxp/pinctrl-imxrt.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+#include
+#include
+#include
+
+#include "pinctrl-imx.h"
+
+static struct imx_pinctrl_soc_info imxrt_pinctrl_soc_info = {
+ .flags = ZERO_OFFSET_VALID,
+};
+
+static int imxrt_pinctrl_probe(struct udevice *dev)
+{
+ struct imx_pinctrl_soc_info *info =
+ (struct imx_pinctrl_soc_info *)dev_get_driver_data(dev);
+
+ return imx_pinctrl_probe(dev, info);
+}
+
+static const struct udevice_id imxrt_pinctrl_match[] = {
+ { .compatible = "fsl,imxrt-iomuxc",
+ .data = (ulong)_pinctrl_soc_info },
+ { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(imxrt_pinctrl) = {
+ .name = "imxrt-pinctrl",
+ .id = UCLASS_PINCTRL,
+ .of_match = of_match_ptr(imxrt_pinctrl_match),
+ .probe = imxrt_pinctrl_probe,
+ .remove = imx_pinctrl_remove,
+ .priv_auto_alloc_size = sizeof(struct imx_pinctrl_priv),
+ .ops = _pinctrl_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
diff --git a/include/dt-bindings/pinctrl/pins-imxrt1050.h
b/include/dt-bindings/pinctrl/pins-imxrt1050.h
new file mode 100644
index 00..e664f977c4
--- /dev/null
+++ b/include/dt-bindings/pinctrl/pins-imxrt1050.h
@@ -0,0 +1,993 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019
+ * Author(s): Giulio Benetti
+ */
+
+#ifndef _DT_BINDINGS_PINCTRL_IMXRT1050_PINFUNC_H
+#define _DT_BINDINGS_PINCTRL_IMXRT1050_PINFUNC_H
+
+#define IMX_PAD_SION 0x4000
+
+/*
+ * The pin function ID is a tuple of
+ *
+ */
+
+#define MXRT1050_IOMUXC_GPIO_EMC_00_SEMC_DA00 0x014
0x204 0x000 0x0 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_00_FLEXPWM4_PWM0_A0x014
0x204 0x000 0x1 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_00_LPSPI2_SCK 0x014
0x204 0x000 0x2 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_00_XBAR_INOUT2
0x014 0x204 0x000 0x3 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_00_FLEXIO1_D00
0x014 0x204 0x000 0x4 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_00_GPIO4_IO00 0x014
0x204 0x000 0x5 0x0
+
+#define MXRT1050_IOMUXC_GPIO_EMC_01_SEMC_DA01 0x018
0x208 0x000 0x0 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_01_FLEXPWM4_PWM0_B0x018
0x208 0x000 0x1 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_01_LPSPI2_PCS0
0x018 0x208 0x000 0x2 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_01_XBAR_INOUT3
0x018 0x208 0x000 0x3 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_01_FLEXIO1_D01
0x018 0x208 0x000 0x4 0x0
+#define MXRT1050_IOMUXC_GPIO_EMC_01_GPIO4_IO01 0x018
0x208 0x000 0x5 0x0
+
+#define MXRT1050_IOMUXC_GPIO_EMC_02_SEMC_DA02 0x01C
[U-Boot] [RFC PATCH 0/5] WIP Add support for i.MXRT family
This patchset is a WIP for adding i.MXRT family. It provides: - soc family entry - pinctrl driver - serial driver tweaking - partial sdram controller driver - imxrt1050-evk board partial support To get it working as at least SPL and Falcon mode it still needs sdram controller driver to be finished and clock driver to be done. I would like to receive some comment from you all since this is my first big contribution(at least for me it is). Giulio Benetti (5): Add support for the NXP IMXRT10xx SoC family pinctrl: add i.MXRT driver serial_lpuart: add support for i.MXRT ram: add SDRAM driver for i.MXRT SoCs Add support for the NXP IMXRT1050-EVK board arch/arm/Kconfig | 10 + arch/arm/Makefile | 4 +- arch/arm/dts/Makefile | 2 + arch/arm/dts/imxrt1050-evk.dts| 124 +++ arch/arm/dts/imxrt1050.dtsi | 73 ++ arch/arm/include/asm/arch-imxrt/clock.h | 10 + arch/arm/include/asm/arch-imxrt/gpio.h| 10 + arch/arm/include/asm/arch-imxrt/imx-regs.h| 10 + arch/arm/include/asm/arch-imxrt/imxrt.h | 11 + arch/arm/mach-imx/Makefile| 1 + arch/arm/mach-imx/imxrt/Kconfig | 17 + arch/arm/mach-imx/imxrt/Makefile | 7 + arch/arm/mach-imx/imxrt/soc.c | 29 + board/freescale/imxrt1050-evk/Kconfig | 19 + board/freescale/imxrt1050-evk/MAINTAINERS | 6 + board/freescale/imxrt1050-evk/Makefile| 6 + board/freescale/imxrt1050-evk/imxrt1050-evk.c | 94 ++ configs/imxrt1050-evk_defconfig | 52 + drivers/pinctrl/nxp/Kconfig | 14 + drivers/pinctrl/nxp/Makefile | 1 + drivers/pinctrl/nxp/pinctrl-imxrt.c | 40 + drivers/ram/Kconfig | 8 + drivers/ram/Makefile | 2 + drivers/ram/imxrt_sdram.c | 406 +++ drivers/serial/serial_lpuart.c| 15 +- include/configs/imxrt1050-evk.h | 68 ++ include/dt-bindings/clock/imxrt-clock.h | 272 + include/dt-bindings/memory/imxrt-sdram.h | 168 +++ include/dt-bindings/pinctrl/pins-imxrt1050.h | 993 ++ include/fsl_lpuart.h | 3 +- 30 files changed, 2468 insertions(+), 7 deletions(-) create mode 100644 arch/arm/dts/imxrt1050-evk.dts create mode 100644 arch/arm/dts/imxrt1050.dtsi create mode 100644 arch/arm/include/asm/arch-imxrt/clock.h create mode 100644 arch/arm/include/asm/arch-imxrt/gpio.h create mode 100644 arch/arm/include/asm/arch-imxrt/imx-regs.h create mode 100644 arch/arm/include/asm/arch-imxrt/imxrt.h create mode 100644 arch/arm/mach-imx/imxrt/Kconfig create mode 100644 arch/arm/mach-imx/imxrt/Makefile create mode 100644 arch/arm/mach-imx/imxrt/soc.c create mode 100644 board/freescale/imxrt1050-evk/Kconfig create mode 100644 board/freescale/imxrt1050-evk/MAINTAINERS create mode 100644 board/freescale/imxrt1050-evk/Makefile create mode 100644 board/freescale/imxrt1050-evk/imxrt1050-evk.c create mode 100644 configs/imxrt1050-evk_defconfig create mode 100644 drivers/pinctrl/nxp/pinctrl-imxrt.c create mode 100644 drivers/ram/imxrt_sdram.c create mode 100644 include/configs/imxrt1050-evk.h create mode 100644 include/dt-bindings/clock/imxrt-clock.h create mode 100644 include/dt-bindings/memory/imxrt-sdram.h create mode 100644 include/dt-bindings/pinctrl/pins-imxrt1050.h -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH 1/5] Add support for the NXP IMXRT10xx SoC family
TODO... Signed-off-by: Giulio Benetti --- arch/arm/Kconfig | 10 arch/arm/Makefile | 4 +-- arch/arm/include/asm/arch-imxrt/clock.h| 10 arch/arm/include/asm/arch-imxrt/gpio.h | 10 arch/arm/include/asm/arch-imxrt/imx-regs.h | 10 arch/arm/include/asm/arch-imxrt/imxrt.h| 11 arch/arm/mach-imx/Makefile | 1 + arch/arm/mach-imx/imxrt/Kconfig| 6 + arch/arm/mach-imx/imxrt/Makefile | 7 ++ arch/arm/mach-imx/imxrt/soc.c | 29 ++ 10 files changed, 96 insertions(+), 2 deletions(-) create mode 100644 arch/arm/include/asm/arch-imxrt/clock.h create mode 100644 arch/arm/include/asm/arch-imxrt/gpio.h create mode 100644 arch/arm/include/asm/arch-imxrt/imx-regs.h create mode 100644 arch/arm/include/asm/arch-imxrt/imxrt.h create mode 100644 arch/arm/mach-imx/imxrt/Kconfig create mode 100644 arch/arm/mach-imx/imxrt/Makefile create mode 100644 arch/arm/mach-imx/imxrt/soc.c diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3b0e315061..672a2a1fe3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -780,6 +780,14 @@ config ARCH_IMX8M select SUPPORT_SPL imply CMD_DM +config ARCH_IMXRT + bool "NXP i.MXRT platform" + select CPU_V7M + select DM + select DM_SERIAL + select SUPPORT_SPL + imply CMD_DM + config ARCH_MX23 bool "NXP i.MX23 family" select CPU_ARM926EJS @@ -1694,6 +1702,8 @@ source "arch/arm/mach-imx/imx8/Kconfig" source "arch/arm/mach-imx/imx8m/Kconfig" +source "arch/arm/mach-imx/imxrt/Kconfig" + source "arch/arm/mach-imx/mxs/Kconfig" source "arch/arm/mach-omap2/Kconfig" diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 5384981c17..5dd9f5b1f6 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -104,11 +104,11 @@ libs-y += arch/arm/cpu/ libs-y += arch/arm/lib/ ifeq ($(CONFIG_SPL_BUILD),y) -ifneq (,$(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_MX35)$(filter $(SOC), mx25 mx5 mx6 mx7 mx35 imx8m imx8)) +ifneq (,$(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_MX35)$(filter $(SOC), mx25 mx5 mx6 mx7 mx35 imx8m imx8 imxrt)) libs-y += arch/arm/mach-imx/ endif else -ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx7 mx7ulp mx31 mx35 mxs imx8m imx8 vf610)) +ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx7 mx7ulp mx31 mx35 mxs imx8m imx8 imxrt vf610)) libs-y += arch/arm/mach-imx/ endif endif diff --git a/arch/arm/include/asm/arch-imxrt/clock.h b/arch/arm/include/asm/arch-imxrt/clock.h new file mode 100644 index 00..7409028b9a --- /dev/null +++ b/arch/arm/include/asm/arch-imxrt/clock.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 + * Author(s): Giulio Benetti + */ + +#ifndef __ASM_ARCH_CLOCK_H +#define __ASM_ARCH_CLOCK_H + +#endif /* __ASM_ARCH_CLOCK_H */ diff --git a/arch/arm/include/asm/arch-imxrt/gpio.h b/arch/arm/include/asm/arch-imxrt/gpio.h new file mode 100644 index 00..973ab1da61 --- /dev/null +++ b/arch/arm/include/asm/arch-imxrt/gpio.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 + * Author(s): Giulio Benetti + */ + +#ifndef _GPIO_H_ +#define _GPIO_H_ + +#endif /* _GPIO_H_ */ diff --git a/arch/arm/include/asm/arch-imxrt/imx-regs.h b/arch/arm/include/asm/arch-imxrt/imx-regs.h new file mode 100644 index 00..4ca7f6bed3 --- /dev/null +++ b/arch/arm/include/asm/arch-imxrt/imx-regs.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright(C) 2019 + * Author(s): Giulio Benetti + */ + +#ifndef __ASM_ARCH_IMX_REGS_H__ +#define __ASM_ARCH_IMX_REGS_H__ + +#endif /* __ASM_ARCH_IMX_REGS_H__ */ diff --git a/arch/arm/include/asm/arch-imxrt/imxrt.h b/arch/arm/include/asm/arch-imxrt/imxrt.h new file mode 100644 index 00..1cb2c57d31 --- /dev/null +++ b/arch/arm/include/asm/arch-imxrt/imxrt.h @@ -0,0 +1,11 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (C) 2019 + * Author(s): Giulio Benetti + */ + +#ifndef _ASM_ARCH_IMXRT_H +#define _ASM_ARCH_IMXRT_H + +#endif /* _ASM_ARCH_IMXRT_H */ + diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile index 08ee52edbf..4b0e12c1b2 100644 --- a/arch/arm/mach-imx/Makefile +++ b/arch/arm/mach-imx/Makefile @@ -208,3 +208,4 @@ obj-$(CONFIG_MX7) += mx7/ obj-$(CONFIG_ARCH_MX7ULP) += mx7ulp/ obj-$(CONFIG_IMX8M) += imx8m/ obj-$(CONFIG_ARCH_IMX8) += imx8/ +obj-$(CONFIG_ARCH_IMXRT) += imxrt/ diff --git a/arch/arm/mach-imx/imxrt/Kconfig b/arch/arm/mach-imx/imxrt/Kconfig new file mode 100644 index 00..1da002336b --- /dev/null +++ b/arch/arm/mach-imx/imxrt/Kconfig @@ -0,0 +1,6 @@ +if ARCH_IMXRT + +config SYS_SOC + default "imxrt" + +endif diff --git a/arch/arm/mach-imx/imxrt/Makefile b/arch/arm/mach-imx/imxrt/Makefile new file mode 100644 index 00..9621a8335a --- /dev/null +++ b/arch/arm/mach-imx/imxrt/Makefile @@ -0,0 +1,7 @@ +#
[U-Boot] [PATCHv2 4/4] arm: socfpga: stratix10: add environment variables for RSU support
From: Richard Gong
Add two RSU environment variables:
1. rsu_log_level
the variable is unsigned integer and its default value is
RSU_DEBUG (7), which only show log with RSU_INFO,RSU_WARNING and
RSU_ERR.
To enable all logs (RSU_ERR, RSU_WARNING, RSU_INFO and RSU_DEBUG),
you need set log level to 8 or above via “setenv rsu_log_level 8”.
To disable all logs, you need set log level to 3 or below.
2. rsu_protected_slot
by default there is no protected RSU slot, you need run
"setenv rsu_protected_slot ” to set a slot protected,
and “setenv rsu_protected_slot ” to unset a protected
slot.
Signed-off-by: Richard Gong
---
arch/arm/mach-socfpga/misc_s10.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 0a5fab1..c9a6f00 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -21,6 +21,8 @@
#include
+#define RSU_DEFAULT_LOG_LEVEL 7
+
DECLARE_GLOBAL_DATA_PTR;
static struct socfpga_system_manager *sysmgr_regs =
@@ -136,10 +138,17 @@ int print_cpuinfo(void)
int arch_misc_init(void)
{
char qspi_string[13];
+ char level[4];
+
+ snprintf(level, sizeof(level), "%u", RSU_DEFAULT_LOG_LEVEL);
sprintf(qspi_string, "<0x%08x>", cm_get_qspi_controller_clk_hz());
env_set("qspi_clock", qspi_string);
+ /* setup for RSU */
+ env_set("rsu_protected_slot", "");
+ env_set("rsu_log_level", level);
+
socfpga_set_phymode();
return 0;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCHv2 2/4] drivers: firmware: add RSU support for Stratix10 SoC
From: Richard Gong
The Intel Remote System Update (RSU) provides a way for users to update
the QSPI configuration bitstream of an Intel Stratix 10 SoC device with
significantly reduced risk of corrupting the bitstream storage and
bricking the system.
This patch adds RSU support which allows user to perform a complete set
of RSU operations:
1. Provides support for creating the initial flash images for a
system to support RSU.
2. Allows several production images to be tried in a specific
order until one of them is successful.
3. Loads a factory image if no production image is available, or
all production images failed.
4. Provides users with the ability to add and remove production
images.
5. Provides user with the ability to change the order in which
production images are loaded.
6. Provides user with the ability to load a specific image from
flash. The image is a production or factory image.
7. Provides user with information on which image is currently
running, and what errors were encountered by RSU.
Signed-off-by: Radu Bacrau
Signed-off-by: Richard Gong
---
drivers/firmware/Kconfig | 11 +
drivers/firmware/Makefile |1 +
drivers/firmware/rsu.c | 662 +
drivers/firmware/rsu_ll_qspi.c | 1050
drivers/firmware/rsu_misc.c| 817 +++
include/intel/rsu.h| 291 +++
include/intel/rsu_ll.h | 72 +++
include/intel/rsu_misc.h | 60 +++
8 files changed, 2964 insertions(+)
create mode 100644 drivers/firmware/rsu.c
create mode 100644 drivers/firmware/rsu_ll_qspi.c
create mode 100644 drivers/firmware/rsu_misc.c
create mode 100644 include/intel/rsu.h
create mode 100644 include/intel/rsu_ll.h
create mode 100644 include/intel/rsu_misc.h
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 873bc8c..3a13405 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -26,3 +26,14 @@ config TI_SCI_PROTOCOL
This protocol library is used by client drivers to use the features
provided by the system controller.
+
+config INTEL_RSU
+ bool "Intel Stratix10/Agilex Remote System Update"
+ depends on TARGET_SOCFPGA_STRATIX10
+ help
+ The Intel Remote System Update (RSU) provides a way for users
+ to update the QSPI configuration bitstream of an Intel Stratix10
+ or Agilex SoC device with significantly reduced risk of
+ corrupting the bitstream storage and bricking the system.
+
+ Say Y here if you want Intel RSU support.
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 6c3e129..97912ea 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_FIRMWARE) += firmware-uclass.o
obj-$(CONFIG_$(SPL_)ARM_PSCI_FW) += psci.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_SANDBOX) += firmware-sandbox.o
+obj-$(CONFIG_INTEL_RSU) += rsu.o rsu_ll_qspi.o rsu_misc.o
diff --git a/drivers/firmware/rsu.c b/drivers/firmware/rsu.c
new file mode 100644
index 000..bcae9dc
--- /dev/null
+++ b/drivers/firmware/rsu.c
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+/* RSU Notify Bitmasks */
+#define RSU_NOTIFY_IGNORE_STAGE BIT(18)
+#define RSU_NOTIFY_CLEAR_ERROR_STATUS BIT(17)
+#define RSU_NOTIFY_RESET_RETRY_COUNTER BIT(16)
+
+struct rsu_ll_intf *ll_intf;
+
+/**
+ * rsu_init() - initialize flash driver, SPT and CPB data
+ * @filename: NULL for qspi
+ *
+ * Returns: 0 on success, or error code
+ */
+int rsu_init(char *filename)
+{
+ int ret;
+
+ if (ll_intf) {
+ rsu_log(RSU_ERR, "ll_intf initialized\n");
+ return -EINTF;
+ }
+
+ ret = rsu_ll_qspi_init(_intf);
+ if (ret) {
+ rsu_exit();
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/**
+ * rsu_exit() - free flash driver, clean SPT and CPB data
+ */
+void rsu_exit(void)
+{
+ if (ll_intf && ll_intf->exit)
+ ll_intf->exit();
+
+ ll_intf = NULL;
+}
+
+/**
+ * rsu_slot_count() - get the number of slots defined
+ *
+ * Returns: the number of defined slots
+ */
+int rsu_slot_count(void)
+{
+ int partitions;
+ int cnt = 0;
+ int x;
+
+ if (!ll_intf)
+ return -EINTF;
+
+ partitions = ll_intf->partition.count();
+
+ for (x = 0; x < partitions; x++) {
+ if (rsu_misc_is_slot(ll_intf, x))
+ cnt++;
+ }
+
+ return cnt;
+}
+
+/**
+ * rsu_slot_by_name() - get slot number based on name
+ * @name: name of slot
+ *
+ * Return: slot number on success, or error code
+ */
+int
[U-Boot] [PATCHv2 3/4] dirvers: firmware: add console commands for RSU support
From: Richard Gong
The Intel Remote System Update (RSU) provides a way for users to update
the QSPI configuration bitstream of a Intel Stratix 10 SoC device with
significantly reduced risk of corrupting the bitstream storage and
bricking the system.
This patch provides console commands to exercises the RSU APIs at
Intel Stratix10 SoC. The commands use the term "slot" to refer to a
sub-partition which is intended to contain a production image, and the
term "priority" to refer to the fact that the images are loaded by
firmware in the defined order.
The provided console commands are below, you can also refer to the
header file rsu.h for the details of RSU APIs:
slot_count
slot_by_name
slot_get_info
slot_size
slot_priority
slot_erase
slot_program_buf
slot_program_buf_raw
slot_verify_buf
slot_verify_buf_raw
slot_enable
slot_disable
slot_load
slot_load_factory
slot_rename
status_log
list
dtb
update
notify
clear_error_status
reset_retry_counter
Signed-off-by: Chin Liang See
Signed-off-by: Radu Bacrau
Signed-off-by: Richard Gong
---
drivers/firmware/Makefile | 2 +-
drivers/firmware/rsu_s10.c | 874 +
include/intel/rsu_s10.h| 46 +++
3 files changed, 921 insertions(+), 1 deletion(-)
create mode 100644 drivers/firmware/rsu_s10.c
create mode 100644 include/intel/rsu_s10.h
diff --git a/drivers/firmware/Makefile b/drivers/firmware/Makefile
index 97912ea..0b915c5 100644
--- a/drivers/firmware/Makefile
+++ b/drivers/firmware/Makefile
@@ -2,4 +2,4 @@ obj-$(CONFIG_FIRMWARE) += firmware-uclass.o
obj-$(CONFIG_$(SPL_)ARM_PSCI_FW) += psci.o
obj-$(CONFIG_TI_SCI_PROTOCOL) += ti_sci.o
obj-$(CONFIG_SANDBOX) += firmware-sandbox.o
-obj-$(CONFIG_INTEL_RSU) += rsu.o rsu_ll_qspi.o rsu_misc.o
+obj-$(CONFIG_INTEL_RSU) += rsu.o rsu_ll_qspi.o rsu_misc.o rsu_s10.o
diff --git a/drivers/firmware/rsu_s10.c b/drivers/firmware/rsu_s10.c
new file mode 100644
index 000..2e508c1
--- /dev/null
+++ b/drivers/firmware/rsu_s10.c
@@ -0,0 +1,874 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct socfpga_rsu_s10_cpb rsu_cpb = {0};
+struct socfpga_rsu_s10_spt rsu_spt = {0};
+u32 rsu_spt0_offset = 0, rsu_spt1_offset = 0;
+
+static int initialized;
+
+static int rsu_print_status(void)
+{
+ struct rsu_status_info status_info;
+
+ if (mbox_rsu_status((u32 *)_info, sizeof(status_info) / 4)) {
+ puts("RSU: Firmware or flash content not supporting RSU\n");
+ return -ENOTSUPP;
+ }
+ puts("RSU: Remote System Update Status\n");
+ printf("Current Image\t: 0x%08llx\n", status_info.current_image);
+ printf("Last Fail Image\t: 0x%08llx\n", status_info.fail_image);
+ printf("State\t\t: 0x%08x\n", status_info.state);
+ printf("Version\t\t: 0x%08x\n", status_info.version);
+ printf("Error location\t: 0x%08x\n", status_info.error_location);
+ printf("Error details\t: 0x%08x\n", status_info.error_details);
+ if (RSU_VERSION_ACMF_VERSION(status_info.version) &&
+ RSU_VERSION_DCMF_VERSION(status_info.version))
+ printf("Retry counter\t: 0x%08x\n", status_info.retry_counter);
+
+ return 0;
+}
+
+static void rsu_print_spt_slot(void)
+{
+ int i;
+
+ puts("RSU: Sub-partition table content\n");
+ for (i = 0; i < rsu_spt.entries; i++) {
+ printf("%16s\tOffset:0x%08x%08x\tLength:0x%08x\tFlag:0x%08x\n",
+ rsu_spt.spt_slot[i].name,
+ rsu_spt.spt_slot[i].offset[1],
+ rsu_spt.spt_slot[i].offset[0],
+ rsu_spt.spt_slot[i].length,
+ rsu_spt.spt_slot[i].flag);
+ }
+}
+
+static void rsu_print_cpb_slot(void)
+{
+ int i, j = 1;
+
+ puts("RSU: CMF pointer block's image pointer list\n");
+ for (i = rsu_cpb.nslots - 1; i >= 0; i--) {
+ if (rsu_cpb.pointer_slot[i] != ~0 &&
+ rsu_cpb.pointer_slot[i] != 0) {
+ printf("Priority %d Offset: 0x%016llx nslot: %d\n",
+ j, rsu_cpb.pointer_slot[i], i);
+ j++;
+ }
+ }
+}
+
+static u32 rsu_spt_slot_find_cpb(void)
+{
+ int i;
+
+ for (i = 0; i < rsu_spt.entries; i++) {
+ if (strstr(rsu_spt.spt_slot[i].name, "CPB0"))
+ return rsu_spt.spt_slot[i].offset[0];
+ }
+ puts("RSU: Cannot find SPT0 entry from sub-partition table\n");
+ return 0;
+}
+
+static u32 rsu_get_boot_part_len(void)
+{
+ int i;
+ u32 offset = 0, len = 0;
+
+ /*
[U-Boot] [PATCHv2 1/4] arm: socfpga: stratix10: add RSU mailbox support
From: Richard Gong
Add Remote System Update (RSU) related mailbox support. This includes
RSU_STATUS which reports status of bitstream loaded by Configuration
Management Firmware (CMF), RSU_UPDATE which will invokes CMF to load new
bitstream, GET_SUBPARTITION_TABLE which will query CMF on the start
address of sub-partition table, HPS_STAGE_NOTIFY which notifies firmware
the stage of HPS code execution and related functions to support Secure
Monitor Call (SMC).
Signed-off-by: Ley Foon Tan
Signed-off-by: Chin Liang See
Signed-off-by: Radu Bacrau
Signed-off-by: Richard Gong
---
arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 36 ---
arch/arm/mach-socfpga/mailbox_s10.c | 79
2 files changed, 105 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
index ae728a5..979fd06 100644
--- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
@@ -77,16 +77,20 @@ enum ALT_SDM_MBOX_RESP_CODE {
};
/* Mailbox command list */
-#define MBOX_RESTART 2
-#define MBOX_CONFIG_STATUS 4
-#define MBOX_RECONFIG 6
-#define MBOX_RECONFIG_MSEL 7
-#define MBOX_RECONFIG_DATA 8
-#define MBOX_RECONFIG_STATUS 9
-#define MBOX_QSPI_OPEN 50
-#define MBOX_QSPI_CLOSE51
-#define MBOX_QSPI_DIRECT 59
-#define MBOX_REBOOT_HPS71
+#define MBOX_RESTART 2
+#define MBOX_CONFIG_STATUS 4
+#define MBOX_RECONFIG 6
+#define MBOX_RECONFIG_MSEL 7
+#define MBOX_RECONFIG_DATA 8
+#define MBOX_RECONFIG_STATUS 9
+#define MBOX_QSPI_OPEN 50
+#define MBOX_QSPI_CLOSE51
+#define MBOX_QSPI_DIRECT 59
+#define MBOX_REBOOT_HPS71
+#define MBOX_GET_SUBPARTITION_TABLE90
+#define MBOX_RSU_STATUS91
+#define MBOX_RSU_UPDATE92
+#define MBOX_HPS_STAGE_NOTIFY 93
/* Mailbox registers */
#define MBOX_CIN 0 /* command valid offset */
@@ -130,6 +134,11 @@ enum ALT_SDM_MBOX_RESP_CODE {
#define RCF_SOFTFUNC_STATUS_SEU_ERROR BIT(3)
#define RCF_PIN_STATUS_NSTATUS BIT(31)
+/* Defines for HPS_STAGE_NOTIFY */
+#define HPS_EXECUTION_STATE_FSBL 0
+#define HPS_EXECUTION_STATE_SSBL 1
+#define HPS_EXECUTION_STATE_OS 2
+
int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg, u8 urgent,
u32 *resp_buf_len, u32 *resp_buf);
int mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
@@ -146,6 +155,13 @@ int mbox_qspi_open(void);
#endif
int mbox_reset_cold(void);
+int mbox_rsu_get_spt_offset(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_status(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_status_psci(u32 *resp_buf, u32 resp_buf_len);
+int mbox_rsu_update(u32 *flash_offset);
+int mbox_rsu_update_psci(u32 *flash_offset);
+int mbox_hps_stage_notify(u32 execution_stage);
+int mbox_hps_stage_notify_psci(u32 execution_stage);
int mbox_get_fpga_config_status(u32 cmd);
int mbox_get_fpga_config_status_psci(u32 cmd);
#endif /* _MAILBOX_S10_H_ */
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index 4498ab5..f7c0f1b 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -342,6 +343,72 @@ int mbox_reset_cold(void)
return 0;
}
+int mbox_rsu_get_spt_offset(u32 *resp_buf, u32 resp_buf_len)
+{
+ return mbox_send_cmd(MBOX_ID_UBOOT, MBOX_GET_SUBPARTITION_TABLE,
+MBOX_CMD_DIRECT, 0, NULL, 0, (u32 *)_buf_len,
+(u32 *)resp_buf);
+}
+
+int mbox_rsu_status(u32 *resp_buf, u32 resp_buf_len)
+{
+ int ret;
+ struct rsu_status_info *info = (struct rsu_status_info *)resp_buf;
+
+ info->retry_counter = -1;
+
+ ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RSU_STATUS, MBOX_CMD_DIRECT, 0,
+ NULL, 0, (u32 *)_buf_len, (u32 *)resp_buf);
+
+ if (ret)
+ return ret;
+
+ if (info->retry_counter != -1)
+ if (!RSU_VERSION_ACMF_VERSION(info->version))
+ info->version |= FIELD_PREP(RSU_VERSION_ACMF_MASK, 1);
+
+ return ret;
+}
+
+int __secure mbox_rsu_status_psci(u32 *resp_buf, u32 resp_buf_len)
+{
+ int ret;
+ struct rsu_status_info *info = (struct rsu_status_info *)resp_buf;
+ int adjust = (resp_buf_len >= 9);
+
+ if (adjust)
+ info->retry_counter = -1;
+
+ ret = mbox_send_cmd_psci(MBOX_ID_UBOOT, MBOX_RSU_STATUS,
+MBOX_CMD_DIRECT, 0, NULL, 0,
+
[U-Boot] [PATCHv2 0/4] support remote system update on Intel Stratix10 SoC
From: Richard Gong This is 2nd submission of Intel Remote System Update patches. The Intel Remote System Update (RSU) provides a way for users to update the QSPI configuration bitstream of a Intel Stratix10 SoC device with significantly reduced risk of corrupting the bitstream storage and bricking the system. The patchset adds RSU support which allows user to perform a complete set of RSU operations via provided console commands. The patches have reviewed by other colleagues at Intel. Richard Gong (4): arm: socfpga: stratix10: add RSU mailbox support drivers: firmware: add RSU support for Stratix10 SoC dirvers: firmware: add console commands for RSU support arm: socfpga: stratix10: add environment variables for RSU support arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 36 +- arch/arm/mach-socfpga/mailbox_s10.c | 79 ++ arch/arm/mach-socfpga/misc_s10.c |9 + drivers/firmware/Kconfig | 11 + drivers/firmware/Makefile|1 + drivers/firmware/rsu.c | 662 ++ drivers/firmware/rsu_ll_qspi.c | 1050 ++ drivers/firmware/rsu_misc.c | 817 + drivers/firmware/rsu_s10.c | 874 ++ include/intel/rsu.h | 291 ++ include/intel/rsu_ll.h | 72 ++ include/intel/rsu_misc.h | 60 ++ include/intel/rsu_s10.h | 46 + 13 files changed, 3998 insertions(+), 10 deletions(-) create mode 100644 drivers/firmware/rsu.c create mode 100644 drivers/firmware/rsu_ll_qspi.c create mode 100644 drivers/firmware/rsu_misc.c create mode 100644 drivers/firmware/rsu_s10.c create mode 100644 include/intel/rsu.h create mode 100644 include/intel/rsu_ll.h create mode 100644 include/intel/rsu_misc.h create mode 100644 include/intel/rsu_s10.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: dts: imx6qdl: Add U-Boot specific device tree files for Cubox-i
Hi Fabio, On 30/10/19 15:43, Fabio Estevam wrote: Hi Walter, On Wed, Oct 30, 2019 at 11:22 AM Walter Lozano wrote: Thanks for your comments. My intention was to initially send the device tree patches and in a different patchset update the configuration, as it requires to run different tests (i.e. boot from SATA). Also I felt that this patch has meaning by itself, as it could be useful for people willing to test DM on this board. It is preferred that you resend the dts pieces only when the cubox board is really converted to DM, otherwise you are only adding "dead code". Thanks for the suggestion. I will wait for some SATA tests before re sending these patches. Also the imx6dl-cubox-i-u-boot.dtb does not need to be explicitly added in the Makefile. It gets built automatically by the core U-Boot Makefile logic. Thanks for the information. I was confused by entries like "r8a7790-lager-u-boot.dtb" in the Makefile but you are right. I will take this into account for v2. Thanks Regards ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] efi_loader: fix efi_dp_from_name()
Correctly check the return value of efi_dp_from_file().
If we can determine device path for the file, should not depend on the
device path for the device being requested.
Provide a function description for efi_dp_from_name().
Reported-by: Coverity CID 273159, CID 273158
Fixes: 08c51fff30cc ("efi_loader: device_path: check against file path length")
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index ac5e6f7e14..17a0c5bb45 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1032,6 +1032,16 @@ out:
return EFI_SUCCESS;
}
+/**
+ * efi_dp_from_name() - convert U-Boot device and file path to device path
+ *
+ * @dev: U-Boot device, e.g. 'mmc'
+ * @devnr: U-Boot device number, e.g. 1 for 'mmc:1'
+ * @path: file path relative to U-Boot device, may be NULL
+ * @device:pointer to receive device path of the device
+ * @file: pointer to receive device path for the file
+ * Return: status code
+ */
efi_status_t efi_dp_from_name(const char *dev, const char *devnr,
const char *path,
struct efi_device_path **device,
@@ -1071,10 +1081,9 @@ efi_status_t efi_dp_from_name(const char *dev, const
char *devnr,
s = filename;
while ((s = strchr(s, '/')))
*s++ = '\\';
- *file = efi_dp_from_file(((!is_net && device) ? desc : NULL),
-part, filename);
+ *file = efi_dp_from_file(is_net ? NULL : desc, part, filename);
- if (!file)
+ if (!*file)
return EFI_INVALID_PARAMETER;
return EFI_SUCCESS;
--
2.24.0.rc1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2020.01-rc1 released
On Wed, Oct 30, 2019 at 02:11:28PM -0500, Adam Ford wrote: > On Wed, Oct 30, 2019 at 12:13 PM Tom Rini wrote: > > > > Hey all, > > > > It's a few days past release day, and here finally is v2020.01-rc1. The > > delay was over hoping to be able to pull in one more big clean up series > > that we need, and I want to take, but needs a little more work. Doing > > that has also put me behind on grabbing a number of outstanding patches > > here and there, which I'm going to get on with next. > > > > In terms of a changelog, > > git log --merges v2019.10..v2020.01-rc1 > > looks pretty good but the content there varies based on what was given > > to me in the PR. So please, the more details in the request the better! > > > > A few things to call out. As I've said before, we need to get off of > > python2 with this release and we're on track I believe. Simon has > > posted a series for almost everything that's not converted other than > > test.py and I have a series for test.py. I plan to merge the test.py > > stuff shortly. Next, Bin Meng added support for Azure Pipelines. One > > reason I'm calling this out is that it is noticeably faster than > > Travis-CI. For everything I pushed now, GitLab CI took 2 hours, Azure > > took 2 hours 20 minutes and Travis is still going (3 hours 34 minutes as > > I write). It may be worth considering setting this up and trying it, if > > you're currently using Travis-CI before posting patches / PRs. > > > > I'm planning on doing -rc2 on the 11th and -rc3 on the 25th of September > > with > > Do you mean November? ;-) At this point I prefer to think of it as tradition that I forget at least one place to update the previous schedule. Yes, thanks :) -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2020.01-rc1 released
On Wed, Oct 30, 2019 at 12:13 PM Tom Rini wrote: > > Hey all, > > It's a few days past release day, and here finally is v2020.01-rc1. The > delay was over hoping to be able to pull in one more big clean up series > that we need, and I want to take, but needs a little more work. Doing > that has also put me behind on grabbing a number of outstanding patches > here and there, which I'm going to get on with next. > > In terms of a changelog, > git log --merges v2019.10..v2020.01-rc1 > looks pretty good but the content there varies based on what was given > to me in the PR. So please, the more details in the request the better! > > A few things to call out. As I've said before, we need to get off of > python2 with this release and we're on track I believe. Simon has > posted a series for almost everything that's not converted other than > test.py and I have a series for test.py. I plan to merge the test.py > stuff shortly. Next, Bin Meng added support for Azure Pipelines. One > reason I'm calling this out is that it is noticeably faster than > Travis-CI. For everything I pushed now, GitLab CI took 2 hours, Azure > took 2 hours 20 minutes and Travis is still going (3 hours 34 minutes as > I write). It may be worth considering setting this up and trying it, if > you're currently using Travis-CI before posting patches / PRs. > > I'm planning on doing -rc2 on the 11th and -rc3 on the 25th of September with Do you mean November? ;-) > -rc4 on December 9th and -rc5 on December 23rd with the release scheduled on > January 6th. Thanks all! Thanks for the update! adam > > -- > Tom > ___ > U-Boot-Board-Maintainers mailing list > u-boot-board-maintain...@lists.denx.de > https://lists.denx.de/listinfo/u-boot-board-maintainers ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Drop "" Subject tag and footer?
On Wed, Oct 30, 2019 at 06:31:03PM +0100, Wolfgang Denk wrote: > Dear Tom, > > a number of mailing lists have recently been re-organized, > especially those run by the the FSF. The background is increased > adoption of the DMARC email standard (see details below). > > The changes implement what they call the "unmodified message fix." > IN short this means they are dropping both a subject prefix (in our > case here the "[U-Boot]" in the Subject: header), and the footer, in > our case the trailing > > | ___ > | U-Boot mailing list > | U-Boot@lists.denx.de > | https://lists.denx.de/listinfo/u-boot > > that gets added to all postings. > > > My feeling is that there is indeed little value in both of these, > and to help support DMARC complicance we should change our mailing > list configuration to drop these. > > What are your thoughs on this? Sounds like it would make things easier and perhaps stop the mass bouncing we get from Google as well. I'm fine with dropping it. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: dts: imx6qdl: Add U-Boot specific device tree files for Cubox-i
Hi Walter, On Wed, Oct 30, 2019 at 11:22 AM Walter Lozano wrote: > Thanks for your comments. My intention was to initially send the device tree > patches and in a different patchset update the configuration, as it requires > to run different tests (i.e. boot from SATA). Also I felt that this patch has > meaning by itself, as it could be useful for people willing to test DM on > this board. It is preferred that you resend the dts pieces only when the cubox board is really converted to DM, otherwise you are only adding "dead code". Also the imx6dl-cubox-i-u-boot.dtb does not need to be explicitly added in the Makefile. It gets built automatically by the core U-Boot Makefile logic. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Drop "" Subject tag and footer?
Dear Tom, a number of mailing lists have recently been re-organized, especially those run by the the FSF. The background is increased adoption of the DMARC email standard (see details below). The changes implement what they call the "unmodified message fix." IN short this means they are dropping both a subject prefix (in our case here the "[U-Boot]" in the Subject: header), and the footer, in our case the trailing | ___ | U-Boot mailing list | U-Boot@lists.denx.de | https://lists.denx.de/listinfo/u-boot that gets added to all postings. My feeling is that there is indeed little value in both of these, and to help support DMARC complicance we should change our mailing list configuration to drop these. What are your thoughs on this? SFS explanation of changes: ___ The Free Software Foundation has changed the GNU Mailman settings on this list. The short version is that any subject prefix or message footer has been removed, allowing us to turn off DMARC from munging. Any list administrator for this list is free to change these settings back, instructions are below. The change is to better deal with increased adoption of the DMARC email standard. The default Mailman settings were causing messages sent from users with strict DMARC policy domains like yahoo.com to be rejected when sent to list subscribers by Mailman. See the end of this email for a technical overview of DMARC and DKIM. There are two main ways to fix the issue by changing Mailman list settings. The first option, and the preferable way for discussion lists, is what we call the "unmodified message fix." There are Mailman list settings which modify the messages by adding a subject prefix (e.g. [list-name]) or a footer. Modifying the message breaks DKIM message signatures and thus DMARC, so we just turn those off. Many lists are already this way and there is no change for them. Instead of using the subject prefix to identify a list, subscribers should use the List-Id, To, and Cc headers. List footer information can also be be put in the welcome email to subscribers and the list information page by list administrators. We changed the default for new lists to send unmodified messages, and are now updating existing discussion lists to the new default. We emailed all list administrators and moderators and Savannah group admins to allow them to opt in to the alternate fix before we made this change. However, not all lists had a valid administrator contact. The second option is for lists which want or need to continue to modify the message, for example with subject prefix or footer settings. In this case we turn on a Mailman list setting called dmarc_moderation_action: "Munge From". With this, if a strict DMARC sender sends to the list, we alter the headers of that message like so: A message sent to the list: From: Anne Example Person Is modified by Mailman and sent to subscribers as: From: Anne Example Person via Alist Reply-To: Anne Example Person Without going into all of the details, here's a few points about why we concluded the unmodified message fix is better for discussion lists. Email clients don't all treat munged messages the same way as unmunged, and humans read these headers so it can confuse people, causing messages not to be sent to the expected recipients. GNU Mailman has an option to do "Munge From" always, but does not recommend using it[1]. While we're not bound by what others do, it's worth noting that other very large free software communities like Debian GNU/Linux have adopted the unmodified message fix[2]. The unmodified messages fix avoids breaking DKIM cryptographic signatures, which show the message was authorized by the signing domain and seems like a generally good security practice. Tools to manage patches, for example patchew, use the from field and are tripped up by from munging. For any Mailman list administrator who wants to change or look over the relevant settings: The dmarc_moderation_action setting is under "Privacy Options" subsection "Sender Filters". The only options that should be selected are "Accept" or "Munge From", along with corresponding changes to the subject_prefix option under "General Options", and msg_footer is under "Non-digest options". If no list administrators or moderators are around for this list, anyone should feel free to try to track them down or figure out who should become one and explain in detail by replying to sysad...@gnu.org. Please be patient, this process may take several weeks. Please send any questions that should be public to mail...@gnu.org. For private ones, just reply to sysad...@gnu.org. For the general announcement of these changes, please read https://lists.gnu.org/archive/html/savannah-hackers-public/2019-06/msg00018.html and https://lists.gnu.org/archive/html/savannah-hackers-public/2019-09/msg00016.html A short DMARC technical overview:
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Dear Daniel & Aaron, In message <7fdf93f6-412e-5fcf-da5e-17665daad...@gmail.com> you wrote: > > > Some other things we have included are a native API that allows Simple > > Executive applications to make calls into U-Boot for such things as > > environment variable access as well as access to block devices and > > filesystems. > > This is one of the parts that shouldn't be needed for basic upstream > support. It your API is a parallel and independent implementation of the > API that U-Boot already has for standalone applications, than I'm afraid > this won't be accepted and should be kept in a downstream fork. The big question here is what these are intended for. If they are indeed thought as standalone applications, especially containing code that shall not be disclosed unter GPL, then there is a licensing issue - the pretty hard restrictions of the API for standalone applications is intentional, and attempts to work around it are license violations. But if it's just normal GPL code that is somehow dependent on U-Boot services, then why is it not linked against U-Boot? Or this might be something ike dynamically loadable modules - well, then a close look is needed because such an approach has to be generic enough (end probably borrow much from Linux). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There you go man, Keep as cool as you can. It riles them to believe that you perceive the web they weave. Keep on being free! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 00/29] arm: Introduce Marvell/Cavium OcteonTX
On Tue, Oct 29, 2019 at 2:08 PM Suneel Garapati wrote: > > This series will add support for OcteonTX and OcteonTX2 processsor based > platforms. The Marvell/Cavium Octeon-TX 64-bit ARM based SoCs include > the CN80XX, CN81XX and CN83XX while Octeon-TX2 64-bit ARM based SoCs include > support for CN96XX and CN95XX. > These SoC's have peripheral drivers based on PCI ECAM. > > Patches > [1 -10] Add requied changes to PCI framework > - [6] Add support for multi-memory region range > - [7] EA in bridges > - [8] SR-IOV > [12] Add driver model support for RTC DS1337 driver > [15 - 17] AHCI changes > [18 - 27] Add OcteonTX drivers > [28 - 29] Add OcteonTX/TX2 board files and configurations > Suneel, Thanks for submitting this series! I've applied and built this and am testing on the Gateworks Newport boards with the CN802x/CN803x (octeontx_81xx) and this is what I've found: - I get hung in the smc_call from smc_dram_size which your calling with the function id of 0xc2000301. The older U-Boot from the Cavium OcteonTX SDK-6.2.0-p3 used 0x43000301 and this works for me. Is there a difference in our ATF version? - configs/octeontx_81xx_defconfig - I have several changes I want to make here, but perhaps some of these would warrant a custom config for my boards - you assume there is only a SPI NOR flash for env which we personally don't use. The env system supports multiple env types so we could just enable MMC as well as SPI but then I find all the hard-coded CONFIG_ENV_* defines restrictive. I wonder if anyone has defined a way for these to come from device-tree? - you set loadaddr=04008 which only makes sense for systems with over 1GiB of DRAM... perhaps we should lower that to loadaddr=02008 for 1GiB systems (I don't think you can have less than 1GiB?) - I use DISTRO_DEFAULTS for a standard distro-friendly boot env... I'm not sure why any board wouldn't do this these days and I think that should be added I was able to functionally test mmc/i2c/gpio/pci/nic(BGX/RGX) and they were all functioning well. When I enable SATA I find that it crashes on init: GW6300-D1> sata info Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: 64bit ncq ilck stag pm led clo only pmp fbss pio slum part ccc apst "Synchronous Abort" handler, esr 0x9606 elr: 0052c240 lr : 005101bc (reloc) elr: 3fecb240 lr : 3feaf1bc x0 : 3be91380 x1 : x2 : x3 : 3be9c100 x4 : 0120 x5 : 3be9b800 x6 : 0001 x7 : x8 : 3ff46998 x9 : 0008 x10: 3ff2e8c4 x11: 3ff2e8ca x12: 3ff2e8cf x13: 3ff2e8d5 x14: 3ff2e8da x15: 3ff2e8e0 x16: 3ff2e8e6 x17: 3ff43362 x18: 3be8ede0 x19: x20: 3be9ab30 x21: 0002 x22: 3be9ab30 x23: 0002 x24: 3ff63aa4 x25: 3be9ab90 x26: x27: x28: x29: 3be881f0 Code: 928004a0 d65f03c0 f947 f94034e7 (f94008e7) Resetting CPU ... I don't have NAND or SPI flash so can't test those. Best Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2020.01-rc1 released
Hey all, It's a few days past release day, and here finally is v2020.01-rc1. The delay was over hoping to be able to pull in one more big clean up series that we need, and I want to take, but needs a little more work. Doing that has also put me behind on grabbing a number of outstanding patches here and there, which I'm going to get on with next. In terms of a changelog, git log --merges v2019.10..v2020.01-rc1 looks pretty good but the content there varies based on what was given to me in the PR. So please, the more details in the request the better! A few things to call out. As I've said before, we need to get off of python2 with this release and we're on track I believe. Simon has posted a series for almost everything that's not converted other than test.py and I have a series for test.py. I plan to merge the test.py stuff shortly. Next, Bin Meng added support for Azure Pipelines. One reason I'm calling this out is that it is noticeably faster than Travis-CI. For everything I pushed now, GitLab CI took 2 hours, Azure took 2 hours 20 minutes and Travis is still going (3 hours 34 minutes as I write). It may be worth considering setting this up and trying it, if you're currently using Travis-CI before posting patches / PRs. I'm planning on doing -rc2 on the 11th and -rc3 on the 25th of September with -rc4 on December 9th and -rc5 on December 23rd with the release scheduled on January 6th. Thanks all! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] tools: buildman: Remove useless mkdir() in Make() in test.py
On Mon, Oct 28, 2019 at 07:25:00AM -0700, Bin Meng wrote: > In the 'Make' function, the codes tries to create a directory > if current stage is 'build'. But the directory isn't used at > all anywhere. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] arm: mvebu: Avoid generating kwbimage.cfg in the source tree
On Mon, Oct 28, 2019 at 07:25:01AM -0700, Bin Meng wrote: > At present some boards generate kwbimage.cfg in the source tree > during the build. This breaks buildman testing on some systems > where the source tree is read-only. Update makefile rules to > generate it in the build tree instead. > > Note some other boards have the kwbimage.cfg file written in > advance, hence we need check if the file exists in the build > tree first, otherwise we fall back to one in the source tree. > > Signed-off-by: Bin Meng > Reviewed-by: Chris Packham > Reviewed-by: Stefan Roese Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] Bring all testings in gitlab and travis CI to Azure Pipelines
On Mon, Oct 28, 2019 at 07:25:03AM -0700, Bin Meng wrote: > This expands current Azure Pipelines Windows host tools build > testing to cover all the CI testing in gitlab and travis CI. > > Note for some unknown reason, the 'container' cannot be used for > any jobs that have buildman, for buildman does not exit properly > and hangs the job forever. As a workaround, we manually call > docker to run the image to perform the CI tasks. > > A complete run on Azure Pipelines takes about 2 hours and 10 > minutes. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/9] tools: ifwitool: Define __packed when it is not defined
On Sun, Oct 27, 2019 at 05:19:44AM -0700, Bin Meng wrote: > Some compilers may provide __packed define for us. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/9] tools: zynqmpbif: Use compiler builtin instead of linux-specific __swab32
On Sun, Oct 27, 2019 at 05:19:42AM -0700, Bin Meng wrote: > __swab32() is a Linux specific macro defined in linux/swab.h. Let's > use the compiler equivalent builtin function __builtin_bswap32() for > better portability. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] splash: fix build breakage with newer llvm-7
On Wed, Oct 30, 2019 at 03:04:10PM +0100, Anatolij Gustschin wrote:
> Some configurations (i.e. sandbox) result in unused
> splash_display_banner() and we get build errors like:
>
> common/splash.c:148:20: error: unused function 'splash_display_banner'
> [-Werror,-Wunused-function]
> static inline void splash_display_banner(void) { }
>
> Drop empty inline function and add guards around the call.
>
> Fixes: d2a8271c8851 ("splash: fix splash banner output")
> Signed-off-by: Anatolij Gustschin
> Reported-by: Tom Rini
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] tools: buildman: Honor output directory when generating boards.cfg
On Mon, Oct 28, 2019 at 07:24:59AM -0700, Bin Meng wrote: > buildman always generates boards.cfg in the U-Boot source tree. > When '-o' is given, we should generate boards.cfg to the given > output directory. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/9] tools: mtk_image.h: Use portable uintXX_t instead of linux-specific __leXX
On Sun, Oct 27, 2019 at 05:19:41AM -0700, Bin Meng wrote: > __leXX has Linux kernel specific __attribute__((bitwise)) which is > not portable. Use corresponding uintXX_t instead. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] doc: Add documentation for how to build U-Boot host tools
On Sun, Oct 27, 2019 at 05:19:45AM -0700, Bin Meng wrote: > This adds a reST document for how to build U-Boot host tools, > including information for both Linux and Windows. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/9] tools: image.h: Use portable uint32_t instead of linux-specific __be32
On Sun, Oct 27, 2019 at 05:19:40AM -0700, Bin Meng wrote: > __be32 has Linux kernel specific __attribute__((bitwise)) which is > not portable. Use uint32_t instead. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/9] linux/types.h: Surround 'struct ustat' with __linux__
On Sun, Oct 27, 2019 at 05:19:43AM -0700, Bin Meng wrote: > 'struct ustat' uses linux-specific typedefs to declare its memebers: > __kernel_daddr_t and __kernel_ino_t. It is currently not used by any > U-Boot codes, but when we build U-Boot tools for other platform like > Windows, this becomes a problem. > > Let's surround it with __linux__. > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-mmc mmc-10-29-2019
On Tue, Oct 29, 2019 at 09:57:26AM +, Peng Fan wrote: > Hi Tom, > > Please pull u-boot-mmc mmc-10-29-2019 > > CI: https://travis-ci.org/MrVan/u-boot/jobs/604226362 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] .travis.yml: Remove the unneeded '&' for ls20xx buildman
On Mon, Oct 28, 2019 at 07:25:02AM -0700, Bin Meng wrote: > Signed-off-by: Bin Meng > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 8/9] tools: Avoid creating symbolic links for tools/version.h
On Sun, Oct 27, 2019 at 05:19:47AM -0700, Bin Meng wrote:
> When building U-Boot host tools for Windows from Microsoft Azure
> Pipelines, the following errors were seen:
>
> HOSTCC tools/mkenvimage.o
> In file included from tools/mkenvimage.c:25:
> ./tools/version.h:1:1: error: expected identifier or ‘(’ before ‘.’ token
> 1 | ../include/version.h
>| ^
> tools/mkenvimage.c: In function ‘main’:
> tools/mkenvimage.c:117:4: warning: implicit declaration of function ‘usage’
> [-Wimplicit-function-declaration]
>117 |usage(prg);
>|^
> tools/mkenvimage.c:120:35: error: ‘PLAIN_VERSION’ undeclared (first use in
> this function)
>120 |printf("%s version %s\n", prg, PLAIN_VERSION);
>| ^
> tools/mkenvimage.c:120:35: note: each undeclared identifier is reported
> only once for each function it appears in
> make[2]: *** [scripts/Makefile.host:114: tools/mkenvimage.o] Error 1
>
> It turns out tools/version.h is a symbolic link and with Windows
> default settings it is unsupported hence the actual content of
> tools/version.h is not what file include/version.h has, but the
> the linked file path, which breaks the build.
>
> To fix this, remove the symbolic links for tools/version.h. Instead
> we perform a copy from include/version.h during the build.
>
> Signed-off-by: Bin Meng
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 7/9] Add .gitattributes for line endings
On Sun, Oct 27, 2019 at 05:19:46AM -0700, Bin Meng wrote: > When building U-Boot host tools for Windows from Microsoft Azure > Pipelines, we see tons of weird warnings and errors emitted from > every Kconfig files: > > Kconfig:6:warning: ignoring unsupported character '' > Kconfig:6:warning: ignoring unsupported character '' > Kconfig:8:warning: ignoring unsupported character '' > Kconfig:9:warning: ignoring unsupported character '' > Kconfig:10:warning: ignoring unsupported character '' > Kconfig:10:warning: ignoring unsupported character '' > Kconfig:13:warning: ignoring unsupported character '' > arch/Kconfig:1:warning: ignoring unsupported character '' > arch/Kconfig:2:warning: ignoring unsupported character '' > arch/Kconfig:2:warning: ignoring unsupported character '' > arch/Kconfig:4:warning: ignoring unsupported character '' > ... > > After several rounds of experiments, it turns out this is caused > by line endings. Historically, Linux and macOS used linefeed (LF) > characters while Windows used a carriage return plus a linefeed > (CRLF). When Azure Pipelines checks out the U-Boot repo, Git tries > to compensate for the difference by automatically making lines end > in CRLF in the working directory on Windows, which confuses the > Kconfig file parsing logic. > > Fortunately Git provides a way for repos to tell Git not to do such > automatical line endings conversion via .gitattributes file below: > > * text eol=lf > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 9/9] Add Microsoft Azure Pipelines configuration
On Sun, Oct 27, 2019 at 05:19:48AM -0700, Bin Meng wrote: > Microsoft Azure Pipelines [1] provides unlimited CI/CD minutes and > 10 parallel jobs to every open source project for free. > > This adds a configuration file for Azure Pipelines to utilize the > free Windows VM hosted by Microsoft to ensure no build broken in > building U-Boot host tools for Windows. > > [1] > https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/ > > Signed-off-by: Bin Meng Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] fdt: Add Kconfig options to control code size
On Sun, Oct 27, 2019 at 09:47:40AM -0600, Simon Glass wrote: > For better or worse libfdt recent grew a lot of code that checks the > validity of the device tree in great detail. When using unsigned or > unverified data this makes things safer, but it does add to code size. > > Add some controls to select the trade-off between safety and code size. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Dockerfile: Update to latest bionic tag
On Thu, Oct 24, 2019 at 12:01:56PM -0400, Tom Rini wrote: > Move up to the latest tag to get the usual related security fixes that > brings in. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Dockerfile: Add python3-pip
On Thu, Oct 24, 2019 at 12:01:57PM -0400, Tom Rini wrote: > In order to be able to use pip within a virtualenv of python3 we need to > have python3-pip installed as well. > > Signed-off-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] fdt: Add INT32_MAX to kernel.h for libfdt
On Sun, Oct 27, 2019 at 09:47:39AM -0600, Simon Glass wrote: > Unfortunately libfdt needs this value now, which is present in the > stdint.h header. That file is just a placeholder in U-Boot and these sorts > of constants appear in the linux/kernel.h header instead. > > To keep libfdt happy, add INT32_MAX too. > > Signed-off-by: Simon Glass Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] dlmalloc: calloc: fix zeroing early allocations
On Fri, Oct 25, 2019 at 09:23:35PM +0200, Simon Goldschmidt wrote: > When full malloc is enabled and SYS_MALLOC_F is also enabled, the simple > pre-reloc heap is used before relocation. In this case, calloc() uses > the MALLOC_ZERO macro to zero out the allocated memory. However, since > this macro is specially crafted for the dlmalloc implementation, it > does not always work for simple malloc. > > For example, when allocating 16 bytes via simple malloc, only the first > 12 bytes get zeroed out. The last 4 bytes will remain untouched. > > This is a problem for DM drivers that are allocated before relocation: > memory allocated via 'platdata_auto_alloc_size' might not be set to > zero, resulting in bogus behaviour. > > To fix this, use 'memset' instead of 'MALLOC_ZERO' to zero out memory > that compes from simple malloc. > > Signed-off-by: Simon Goldschmidt Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sunxi/master
On Sat, Oct 26, 2019 at 11:18:47PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR. > > Summary: > - H6 dts(i) sync (Clément) > - H6 PIO (Icenowy) > - Fix pll1 clock calculation (Stefan) > - H6 dram, half DQ (Jernej) > - A64 OLinuXino eMMC (Sunil) > > Travis-CI: > https://travis-ci.org/openedev/u-boot-amarula/builds/602715052 > > Thanks, > Jagan. > > The following changes since commit 395ec7418695e5ce23f8b48c01a1dbffd2e52d3f: > > spi-nor-ids: Add support for Adesto AT25SL321 (2019-10-25 00:48:32 +0530) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-sunxi master > > for you to fetch changes up to 5f19c9302133cda54d5d1a6b1caa400260de9192: > > sunxi: set PIO voltage to hardware-detected value on startup on H6 > (2019-10-25 14:40:34 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT] Pull request: u-boot-dfu (30.10.2019)
Hi Marek, The following changes since commit 7f0d5fa97074690dcbfcbc902f99c8dab0bff24d: dwc3-generic: Don't fail probe if clk/reset entries are absent (2019-10-28 23:47:45 +0100) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-dfu.git BRANCH: master https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/commits/master Merge TAG: https://gitlab.denx.de/u-boot/custodians/u-boot-dfu/-/tags/u-boot-dfu-30Oct2019 for you to fetch changes up to 60af9f0fc2e94d105c617cfa32a32ec411e23192: dfu: add callback for flush and initiated operation (2019-10-30 10:00:29 +0100) Marek Szyprowski (5): gadget: f_thor: properly enable 3rd endpoint defined by the protocol cmd: thor: select DFU subsystem also for 'thor' download tool dfu: mmc: add support for in-partition offset dwc3: flush cache only if there is a buffer attached to a request thor: fix error path after g_dnl_register() failure Patrick Delaunay (10): dfu: cosmetic: cleanup sf to avoid checkpatch error doc: dfu: Add dfu documentation dfu: sf: add partition support for nor backend dfu: prepare the support of multiple interface dfu: allow to manage DFU on several devices dfu: allow read with no data without error for EOF indication dfu: add backend for MTD device dfu: add partition support for MTD backend dfu: add DFU virtual backend dfu: add callback for flush and initiated operation Ralph Siemsen (1): dfu: dfu_nand: reduce verbosity Travis-CI: https://travis-ci.org/lmajewski/u-boot-dfu/builds/604863805 Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpEyMyJiHfOI.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: Cavium/Marvell Octeon Support
Hi Aaron, Am 27.10.19 um 03:34 schrieb Aaron Williams: > Hi Daniel, > > On Friday, October 25, 2019 8:13:57 AM PDT Daniel Schwierzeck wrote: >> External Email >> >> -- >> Hi Aaron, >> >> Am 23.10.19 um 05:50 schrieb Aaron Williams: >>> Hi all, >>> >>> I have been tasked with porting our Octeon U-Boot to the latest U-Boot >>> and merging it upstream. This will involve a very significant amount of >>> code that generally will not be compatible with other MIPS processors >>> due to our needs and requirements. For example, the start.S will need to >>> be completely different than what is present. For example, our existing >>> start.S is 3577 lines of code in order to deal with things like RAS, >>> exceptions, virtual memory and more. We need to use virtual memory since >>> U-Boot can be loaded at any 4MB boundary in memory, not just 0xbfc0. >>> A number of drivers will need to be updated in order to properly map >>> pointers to physical addresses. This is needed anyway, since I see >>> numerous drivers that assume that a pointer is a DMA address. For MIPS >>> this is never the case (I'm looking at XHCI). >> >> Good to see some progress in mainline Octeon support. Could you briefly >> describe the differences and commonalities in booting an Octeon CPU >> compared to other "generic" MIPS cores? Or could you point me to a >> public Git tree? It can't be that different because Linux kernel is also >> able to share most of the code ;) >> > > Actually the low level code is significantly different. First of all, we need > the U-Boot bootloader to be able to boot from different memory locations. > Because of this, we use mapped memory for U-Boot. A side effect of this is > that it eliminates the need for relocation when it is shifted to the top of > memory. All we need to do is just set a couple of TLB entries. Understood. but still U-Boot relocates itself from its initial entry memory address to its destination memory address based on gd->ram_top. Maybe this is ineffective nowadays with various SPL/TPL boot methods because U-Boot proper is already loaded to an executable memory location by SPL, but you have to initially deal with that design. Feel free to suggest/submit a patch for the generic board init code to make the reloaction configurable. > > The assembly code is significantly different and is far more extensive. > > Additionally, the way Octeon Linux is booted is different. > > The generic start.S is not usable in our case. > > We have a significant amount of code for dealing with the cache and for > things > like copying U-Boot from flash into the L2 cache. We also have to deal with > taking other cores out of reset in our start.S. Our exception handler has > also > been extended to handle multiple cores. it's hard to discuss this without example code but I still think the basic principles of cache and exception handling can't be that different from generic MIPS cores. Locking cache lines and loading code to it could be useful for other MIPS platforms and should be added as generic feature. BTW the exception handler code is a port of the Linux one, I only skipped the stack trace output because of the complicated stack unwinding code. I think the current dump of general and CP0 and EPC registers is more than feasible for a bootloader. It already helped me multiple times to quickly locate code locations with e.g. null pointer dereferencing. > > Some other things we have included are a native API that allows Simple > Executive applications to make calls into U-Boot for such things as > environment variable access as well as access to block devices and > filesystems. This is one of the parts that shouldn't be needed for basic upstream support. It your API is a parallel and independent implementation of the API that U-Boot already has for standalone applications, than I'm afraid this won't be accepted and should be kept in a downstream fork. > > > We used to have our Octeon SDK available for download but it seems this has > been taken down :( I'm trying to find out how I can make it available but I'm > getting pushback in sharing our GPLed U-Boot even though it is GPL. > >> In principle you could compile an own start.S in your mach-octeon >> directory, but you should try to use the generic start.S which is >> already customisable and extensible. If needed, we could add more >> extension points to it. Booting from any custom memory address is >> already supported and very common for other MIPS based SoC's. Exception >> support is also already there. >> > > The bootloader needs to be able to start from multiple memory locations > without recompiling. Our existing bootloader can run from any 4MB boundary > without recompiling or relocation. It can start out of flash (from any sector > boundary, not just 0) or L2 cache. Starting by L2 cache is supported by eMMC, > SPI and PCI target bootloaders. Additionally
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
Hi Tom, On Wed, 30 Oct 2019 at 09:58, Tom Rini wrote: > > On Wed, Oct 30, 2019 at 09:12:39AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Wed, 30 Oct 2019 at 07:15, Tom Rini wrote: > > > > > > On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > > > > > > > Convert buildman to Python 3 and make it use that, to meet the 2020 > > > > > deadline. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > Changes in v2: None > > > > > > > > > > tools/buildman/board.py | 7 +-- > > > > > tools/buildman/bsettings.py | 20 +++ > > > > > tools/buildman/builder.py | 45 > > > > > tools/buildman/builderthread.py | 24 - > > > > > tools/buildman/buildman.py | 10 ++-- > > > > > tools/buildman/control.py | 40 +++--- > > > > > tools/buildman/func_test.py | 16 +++--- > > > > > tools/buildman/test.py | 22 > > > > > tools/buildman/toolchain.py | 93 > > > > > + > > > > > 9 files changed, 139 insertions(+), 138 deletions(-) > > > > > > > > I am a bit mystified by this: > > > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > > > > > > > It runs locally and I cannot see why it is not using unicode. Are > > > > there instructions on how to get to the same Python version as gitlab? > > > > I fear a steep learning curve coming. > > > > > > First, I think the problem is this series will also need the test.py > > > python3 series as that does a few more things to get and provide a > > > python3 environment to use. I'll try and throw something together to > > > test that shortly. > > > > > > Second, to have the same environment locally: > > > $ sudo docker pull trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 > > > > > > And change the tag to whatever .gitlab-ci.yml says we use. That one is > > > what the test.py series brings us up to, and is newer than your failing > > > job. > > > > > > $ sudo docker run --rm -it -v /your/local/u-boot/clone/..:/build/u-boot \ > > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash > > > > > > And don't pass --rm if you don't want the image deleted once you exit. > > > That will put you in a bash prompt as the user we run everything as. > > > Follow the steps in the job as described in .gitlab-ci.yml to do a build > > > by hand. > > > > > > And yes, you want to pass in one level before your clone so that in the > > > container you have /build/u-boot/u-boot > > > > Thank you, that is very helpful! > > > > It seems like the default file encoding for open() is different. I'll > > try again and hopefully send a v2 series soon. > > Ah, yeah. That reminded me of > http://patchwork.ozlabs.org/patch/1183213/ which ends up with telling > open to use utf-8 and then possibly some other places we need to > decode() and allow for errors to replace characters as needed rather > than be fatal. I think you might have a case of the latter where it's > found 'ä' or similar in the log and can't just turn it to ascii without > being allowed to replace. I think I have that patch. My tree is building here: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/1158 But perhaps I picked up an earlier version? Is it close to being applied? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
On Wed, Oct 30, 2019 at 09:12:39AM -0600, Simon Glass wrote: > Hi Tom, > > On Wed, 30 Oct 2019 at 07:15, Tom Rini wrote: > > > > On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > > > > > Convert buildman to Python 3 and make it use that, to meet the 2020 > > > > deadline. > > > > > > > > Signed-off-by: Simon Glass > > > > --- > > > > > > > > Changes in v2: None > > > > > > > > tools/buildman/board.py | 7 +-- > > > > tools/buildman/bsettings.py | 20 +++ > > > > tools/buildman/builder.py | 45 > > > > tools/buildman/builderthread.py | 24 - > > > > tools/buildman/buildman.py | 10 ++-- > > > > tools/buildman/control.py | 40 +++--- > > > > tools/buildman/func_test.py | 16 +++--- > > > > tools/buildman/test.py | 22 > > > > tools/buildman/toolchain.py | 93 + > > > > 9 files changed, 139 insertions(+), 138 deletions(-) > > > > > > I am a bit mystified by this: > > > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > > > > > It runs locally and I cannot see why it is not using unicode. Are > > > there instructions on how to get to the same Python version as gitlab? > > > I fear a steep learning curve coming. > > > > First, I think the problem is this series will also need the test.py > > python3 series as that does a few more things to get and provide a > > python3 environment to use. I'll try and throw something together to > > test that shortly. > > > > Second, to have the same environment locally: > > $ sudo docker pull trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 > > > > And change the tag to whatever .gitlab-ci.yml says we use. That one is > > what the test.py series brings us up to, and is newer than your failing > > job. > > > > $ sudo docker run --rm -it -v /your/local/u-boot/clone/..:/build/u-boot \ > > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash > > > > And don't pass --rm if you don't want the image deleted once you exit. > > That will put you in a bash prompt as the user we run everything as. > > Follow the steps in the job as described in .gitlab-ci.yml to do a build > > by hand. > > > > And yes, you want to pass in one level before your clone so that in the > > container you have /build/u-boot/u-boot > > Thank you, that is very helpful! > > It seems like the default file encoding for open() is different. I'll > try again and hopefully send a v2 series soon. Ah, yeah. That reminded me of http://patchwork.ozlabs.org/patch/1183213/ which ends up with telling open to use utf-8 and then possibly some other places we need to decode() and allow for errors to replace characters as needed rather than be fatal. I think you might have a case of the latter where it's found 'ä' or similar in the log and can't just turn it to ascii without being allowed to replace. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd: nand: Remove not used declaration
This declaration is not used anywhere in the whole tree. There is a
function 'mtd_id_parse()' which was renamed from 'id_parse()' in
commit 68d7d65100e8 ("Separate mtdparts command from jffs2"), but that
function is not used (anymore?) in cmd nand and build is fine without
that declaration, so it's probably just safe to remove.
Signed-off-by: Alexander Dahl
---
cmd/nand.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/cmd/nand.c b/cmd/nand.c
index 27efef20bc..24c9df89c1 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -34,7 +34,6 @@
/* partition handling routines */
int mtdparts_init(void);
-int id_parse(const char *id, const char **ret_id, u8 *dev_type, u8 *dev_num);
int find_dev_and_part(const char *id, struct mtd_device **dev,
u8 *part_num, struct part_info **part);
#endif
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/2] cmd: Minor fixes for commands 'mtdparts' and 'nand'
Hei hei, I reviewed some code today to explore possibilities and came across two minor issues. See the two patches. Greets Alex Alexander Dahl (2): cmd: nand: Remove not used declaration cmd: mtdparts: Fix build with option ..._SHOW_NET_SIZES cmd/Kconfig| 8 cmd/mtdparts.c | 6 +++--- cmd/nand.c | 1 - 3 files changed, 11 insertions(+), 4 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] cmd: mtdparts: Fix build with option ..._SHOW_NET_SIZES
That option is currently not used by any defconfig and could not be set
anymore since it became mandatory to used Kconfig when introducing new
options with U-Boot v2016.11 or commit eed921d92348 ("Kconfig: Add a
whitelist of ad-hoc CONFIG options") and commit 371244cb19f9 ("Makefile:
Give a build error if ad-hoc CONFIG options are added").
It was also not considered when fixing build warnings in
commit 39ac34473f3c ("cmd_mtdparts: use 64 bits for flash size,
partition size & offset") and could probably not be compiled anyway
after commit dfe64e2c8973 ("mtd: resync with Linux-3.7.1"), which
renamed some members of struct mtd_info … so it was probably broken
since then, which was U-Boot v2013.07-rc1.
However it still seems to work, see example output below:
U-Boot 2019.10-00035-g06a9b259ca-dirty (Oct 30 2019 - 14:03:44 +0100)
CPU: SAMA5D27 1G bits DDR2 SDRAM
Crystal frequency: 24 MHz
CPU clock: 492 MHz
Master clock : 164 MHz
Model: ***
DRAM: 128 MiB
NAND: 256 MiB
Loading Environment from NAND... OK
In:serial@f802
Out: serial@f802
Err: serial@f802
Net: eth0: ethernet@f8008000
Hit keys 'tt' to stop autoboot (3 seconds).
U-Boot> mtdparts
device nand0 , # parts = 8
#: namesizenet sizeoffset
mask_flags
0: bootstrap 0x0004 0x0004 0x 1
1: uboot 0x000c 0x000c 0x0004 1
2: env10x0004 0x0004 0x0010 0
3: env20x0004 0x0004 0x0014 0
4: fpga_led0x0004 0x0004 0x0018 1
5: reserved0x0004 0x0004 0x001c 1
6: rootfs_rec 0x0320 0x0320 0x0020 1
7: filesystem 0x0cc0 0x0cb8 (!) 0x0340 0
active partition: nand0,0 - (bootstrap) 0x0004 @ 0x
defaults:
mtdids : nand0=atmel_nand
mtdparts:
mtdparts=atmel_nand:256k(bootstrap)ro,768k(uboot)ro,256k(env1),256k(env2),256k(fpga_led)ro,256k(reserved)ro,50M(rootfs_rec)ro,-(filesystem)
Signed-off-by: Alexander Dahl
---
cmd/Kconfig| 8
cmd/mtdparts.c | 6 +++---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 82b5d300d2..07cb85e08c 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1984,6 +1984,14 @@ config CMD_MTDPARTS_SPREAD
at least as large as the size specified in the mtdparts variable and
2) each partition starts on a good block.
+config CMD_MTDPARTS_SHOW_NET_SIZES
+ bool "Show net size (w/o bad blocks) of partitions"
+ depends on CMD_MTDPARTS
+ help
+ Adds two columns to the printed partition table showing the
+ effective usable size of a partition, if bad blocks are taken
+ into account.
+
config CMD_REISER
bool "reiser - Access to reiserfs filesystems"
help
diff --git a/cmd/mtdparts.c b/cmd/mtdparts.c
index 46155cabf6..b40c2afadd 100644
--- a/cmd/mtdparts.c
+++ b/cmd/mtdparts.c
@@ -1233,11 +1233,11 @@ static uint64_t net_part_size(struct mtd_info *mtd,
struct part_info *part)
{
uint64_t i, net_size = 0;
- if (!mtd->block_isbad)
+ if (!mtd->_block_isbad)
return part->size;
for (i = 0; i < part->size; i += mtd->erasesize) {
- if (!mtd->block_isbad(mtd, part->offset + i))
+ if (!mtd->_block_isbad(mtd, part->offset + i))
net_size += mtd->erasesize;
}
@@ -1274,7 +1274,7 @@ static void print_partition_table(void)
part = list_entry(pentry, struct part_info, link);
net_size = net_part_size(mtd, part);
size_note = part->size == net_size ? " " : " (!)";
- printf("%2d: %-20s0x%08x\t0x%08x%s\t0x%08x\t%d\n",
+ printf("%2d: %-20s0x%08llx\t0x%08x%s\t0x%08llx\t%d\n",
part_num, part->name, part->size,
net_size, size_note, part->offset,
part->mask_flags);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MIPS: remove Micronas VCT boards
On Fri, Oct 18, 2019 at 03:13:26PM +0200, Daniel Schwierzeck wrote: > The deadline for migration to CONFIG_DM is v2020.01. The VCT > baords would need an almost complete rewrite of all drivers to > support driver model. > > Unless someone has access to the hardware and volunteers to do the migration, > the board should be scheduled for removal. > > Signed-off-by: Daniel Schwierzeck Sad, but please apply this soon. This brings down, AFAICT, the users of embedded-within-U-Boot environment to just an MPC8xx board and I have some questions/concerns about that and how functional it is/isn't right now. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
Hi Tom, On Wed, 30 Oct 2019 at 07:15, Tom Rini wrote: > > On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > > > Convert buildman to Python 3 and make it use that, to meet the 2020 > > > deadline. > > > > > > Signed-off-by: Simon Glass > > > --- > > > > > > Changes in v2: None > > > > > > tools/buildman/board.py | 7 +-- > > > tools/buildman/bsettings.py | 20 +++ > > > tools/buildman/builder.py | 45 > > > tools/buildman/builderthread.py | 24 - > > > tools/buildman/buildman.py | 10 ++-- > > > tools/buildman/control.py | 40 +++--- > > > tools/buildman/func_test.py | 16 +++--- > > > tools/buildman/test.py | 22 > > > tools/buildman/toolchain.py | 93 + > > > 9 files changed, 139 insertions(+), 138 deletions(-) > > > > I am a bit mystified by this: > > > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > > > It runs locally and I cannot see why it is not using unicode. Are > > there instructions on how to get to the same Python version as gitlab? > > I fear a steep learning curve coming. > > First, I think the problem is this series will also need the test.py > python3 series as that does a few more things to get and provide a > python3 environment to use. I'll try and throw something together to > test that shortly. > > Second, to have the same environment locally: > $ sudo docker pull trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 > > And change the tag to whatever .gitlab-ci.yml says we use. That one is > what the test.py series brings us up to, and is newer than your failing > job. > > $ sudo docker run --rm -it -v /your/local/u-boot/clone/..:/build/u-boot \ > trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash > > And don't pass --rm if you don't want the image deleted once you exit. > That will put you in a bash prompt as the user we run everything as. > Follow the steps in the job as described in .gitlab-ci.yml to do a build > by hand. > > And yes, you want to pass in one level before your clone so that in the > container you have /build/u-boot/u-boot Thank you, that is very helpful! It seems like the default file encoding for open() is different. I'll try again and hopefully send a v2 series soon. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 40/41] power: regulator: add driver for Dialog DA9063 PMIC
On Wed, 2019-10-30 at 14:15 +, Schrempf Frieder wrote:
> Hi Robert,
>
> On 23.10.19 20:22, Robert Beckett wrote:
> > From: Martin Fuzzey
> >
> > Add a driver for the regulators in the the DA9063 PMIC.
> >
> > Robert Beckett: move regulator modes to header so board code can
> > set
> > modes. Correct mode mask used in ldo_set_mode.
> >
> > Signed-off-by: Martin Fuzzey
> > Signed-off-by: Robert Beckett
> > ---
> > drivers/power/regulator/Kconfig | 10 +
> > drivers/power/regulator/Makefile | 1 +
> > drivers/power/regulator/da9063.c | 388
> > +++
> > include/power/da9063_pmic.h | 12 +
> > 4 files changed, 411 insertions(+)
> > create mode 100644 drivers/power/regulator/da9063.c
> >
> > diff --git a/drivers/power/regulator/Kconfig
> > b/drivers/power/regulator/Kconfig
> > index 9aa00fad42..ab58e2eb56 100644
> > --- a/drivers/power/regulator/Kconfig
> > +++ b/drivers/power/regulator/Kconfig
> > @@ -60,6 +60,16 @@ config SPL_DM_REGULATOR_BD71837
> > This config enables implementation of driver-model regulator
> > uclass
> > features for regulators on ROHM BD71837 and BD71847 in SPL.
> >
> > +config DM_REGULATOR_DA9063
> > + bool "Enable Driver Model for REGULATOR DA9063"
> > + depends on DM_REGULATOR && DM_PMIC_DA9063
> > + help
> > + This config enables implementation of driver-model regulator
> > uclass
> > + features for REGULATOR DA9063.
> > + The driver implements get/set api for value, enable and mode
> > for all
> > + regulators. It also implements the get/set api for current
> > for the
> > + buck regulators.
> > +
> > config DM_REGULATOR_PFUZE100
> > bool "Enable Driver Model for REGULATOR PFUZE100"
> > depends on DM_REGULATOR && DM_PMIC_PFUZE100
> > diff --git a/drivers/power/regulator/Makefile
> > b/drivers/power/regulator/Makefile
> > index 6a3d4bbee4..b05a71562c 100644
> > --- a/drivers/power/regulator/Makefile
> > +++ b/drivers/power/regulator/Makefile
> > @@ -7,6 +7,7 @@
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
> > obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> > obj-$(CONFIG_REGULATOR_AS3722)+= as3722_regulator.o
> > +obj-$(CONFIG_DM_REGULATOR_DA9063) += da9063.o
>
> Can you please change this to "obj-
> $(CONFIG_$(SPL_)DM_REGULATOR_DA9063)"
> and add an option CONFIG_SPL_DM_REGULATOR_DA9063 to Kconfig?
> This will allow us to enable the driver for SPL and U-Boot proper
> separately.
>
> Thanks,
> Frieder
>
Thanks for the review Frieder.
I was asked to split this series in to multiple smaller series, which I
have done.
The resend of this PMIC driver is currently queued for sending behind
the i2c addressing mode changes in a different series, so Ill make this
update in my queue and send it out once the prerequisites are accepted.
> > obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> > obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> > obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> > diff --git a/drivers/power/regulator/da9063.c
> > b/drivers/power/regulator/da9063.c
> > new file mode 100644
> > index 00..8990be113e
> > --- /dev/null
> > +++ b/drivers/power/regulator/da9063.c
> > @@ -0,0 +1,388 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018 Flowbird
> > + * Martin Fuzzey
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#defineDA9063_BUCK_EN 0x01
> > +#defineDA9063_LDO_EN 0x01
> > +#define DA9063_VBUCK_MASK 0x7F
> > +#define DA9063_BUCK_SL 0x80
> > +#define DA9063_LDO_SL 0x80
> > +
> > +#define DA9063_VLDO1_MASK 0x3F
> > +#define DA9063_VLDO2_MASK 0x3F
> > +#define DA9063_VLDO3_MASK 0x7F
> > +#define DA9063_VLDO4_MASK 0x7F
> > +#define DA9063_VLDO5_MASK 0x3F
> > +#define DA9063_VLDO6_MASK 0x3F
> > +#define DA9063_VLDO7_MASK 0x3F
> > +#define DA9063_VLDO8_MASK 0x3F
> > +#define DA9063_VLDO9_MASK 0x3F
> > +#define DA9063_VLDO10_MASK 0x3F
> > +#define DA9063_VLDO11_MASK 0x3F
> > +
> > +#define DA9063_BUCK_MODE_MASK 0xC0
> > +#defineDA9063_BUCK_MODE_MANUAL 0x00
> > +#defineDA9063_BUCK_MODE_SLEEP 0x40
> > +#defineDA9063_BUCK_MODE_SYNC 0x80
> > +#defineDA9063_BUCK_MODE_AUTO 0xC0
> > +
> > +#define DA9063_BIO_ILIM_MASK 0x0F
> > +#define DA9063_BMEM_ILIM_MASK 0xF0
> > +#define DA9063_BPRO_ILIM_MASK 0x0F
> > +#define DA9063_BPERI_ILIM_MASK 0xF0
> > +#define DA9063_BCORE1_ILIM_MASK0x0F
> > +#define DA9063_BCORE2_ILIM_MASK0xF0
> > +
> > +struct da9063_reg_info {
> > + uint min_uV;
> > + uint step_uV;
> > + uint max_uV;
> > + uint min_uA;
> > + uint step_uA;
> > + uint max_uA;
> > + uint en_reg;
> > + uint vsel_reg;
> > + uint mode_reg;
> > + uint ilim_reg;
> > + u8 en_mask;
> > + u8 vsel_mask;
> > + u8 ilim_mask;
> > + const char *dt_node_name;
> > + const int *current_limits;
> > +};
> > +
> > +struct
Re: [U-Boot] ?==?utf-8?q? ?==?utf-8?q? [PATCH 2/2]?==?utf-8?q? ARM:?==?utf-8?q? dts: imx6qdl: Add U-Boot specific device tree files for Cubox-i
Hi Fabio, On Monday, October 28, 2019 11:11 -03, Fabio Estevam wrote: > Hi Walter, > > On Mon, Oct 28, 2019 at 11:01 AM Walter Lozano > wrote: > > > > To make it easier to sync dts files with Linux add specific tweaks > > for U-Boot in separate files, specifically allowing SPL to make use > > of MMC. > > > > Signed-off-by: Walter Lozano > > It seems you missed to add CONFIG_OF_CONTROL=y and CONFIG_DM_MMC=y in > the defconfig so that Cubox could be really converted to DM. Thanks for your comments. My intention was to initially send the device tree patches and in a different patchset update the configuration, as it requires to run different tests (i.e. boot from SATA). Also I felt that this patch has meaning by itself, as it could be useful for people willing to test DM on this board. Please let me know you think my approach is not the correct one. Regards, ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 40/41] power: regulator: add driver for Dialog DA9063 PMIC
Hi Robert,
On 23.10.19 20:22, Robert Beckett wrote:
> From: Martin Fuzzey
>
> Add a driver for the regulators in the the DA9063 PMIC.
>
> Robert Beckett: move regulator modes to header so board code can set
> modes. Correct mode mask used in ldo_set_mode.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
> ---
> drivers/power/regulator/Kconfig | 10 +
> drivers/power/regulator/Makefile | 1 +
> drivers/power/regulator/da9063.c | 388 +++
> include/power/da9063_pmic.h | 12 +
> 4 files changed, 411 insertions(+)
> create mode 100644 drivers/power/regulator/da9063.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index 9aa00fad42..ab58e2eb56 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -60,6 +60,16 @@ config SPL_DM_REGULATOR_BD71837
> This config enables implementation of driver-model regulator uclass
> features for regulators on ROHM BD71837 and BD71847 in SPL.
>
> +config DM_REGULATOR_DA9063
> + bool "Enable Driver Model for REGULATOR DA9063"
> + depends on DM_REGULATOR && DM_PMIC_DA9063
> + help
> + This config enables implementation of driver-model regulator uclass
> + features for REGULATOR DA9063.
> + The driver implements get/set api for value, enable and mode for all
> + regulators. It also implements the get/set api for current for the
> + buck regulators.
> +
> config DM_REGULATOR_PFUZE100
> bool "Enable Driver Model for REGULATOR PFUZE100"
> depends on DM_REGULATOR && DM_PMIC_PFUZE100
> diff --git a/drivers/power/regulator/Makefile
> b/drivers/power/regulator/Makefile
> index 6a3d4bbee4..b05a71562c 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -7,6 +7,7 @@
> obj-$(CONFIG_$(SPL_)DM_REGULATOR) += regulator-uclass.o
> obj-$(CONFIG_REGULATOR_ACT8846) += act8846.o
> obj-$(CONFIG_REGULATOR_AS3722) += as3722_regulator.o
> +obj-$(CONFIG_DM_REGULATOR_DA9063) += da9063.o
Can you please change this to "obj-$(CONFIG_$(SPL_)DM_REGULATOR_DA9063)"
and add an option CONFIG_SPL_DM_REGULATOR_DA9063 to Kconfig?
This will allow us to enable the driver for SPL and U-Boot proper
separately.
Thanks,
Frieder
> obj-$(CONFIG_DM_REGULATOR_MAX77686) += max77686.o
> obj-$(CONFIG_$(SPL_)DM_PMIC_PFUZE100) += pfuze100.o
> obj-$(CONFIG_$(SPL_)DM_REGULATOR_BD71837) += bd71837.o
> diff --git a/drivers/power/regulator/da9063.c
> b/drivers/power/regulator/da9063.c
> new file mode 100644
> index 00..8990be113e
> --- /dev/null
> +++ b/drivers/power/regulator/da9063.c
> @@ -0,0 +1,388 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Flowbird
> + * Martin Fuzzey
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DA9063_BUCK_EN 0x01
> +#define DA9063_LDO_EN 0x01
> +#define DA9063_VBUCK_MASK0x7F
> +#define DA9063_BUCK_SL 0x80
> +#define DA9063_LDO_SL0x80
> +
> +#define DA9063_VLDO1_MASK0x3F
> +#define DA9063_VLDO2_MASK0x3F
> +#define DA9063_VLDO3_MASK0x7F
> +#define DA9063_VLDO4_MASK0x7F
> +#define DA9063_VLDO5_MASK0x3F
> +#define DA9063_VLDO6_MASK0x3F
> +#define DA9063_VLDO7_MASK0x3F
> +#define DA9063_VLDO8_MASK0x3F
> +#define DA9063_VLDO9_MASK0x3F
> +#define DA9063_VLDO10_MASK 0x3F
> +#define DA9063_VLDO11_MASK 0x3F
> +
> +#define DA9063_BUCK_MODE_MASK0xC0
> +#define DA9063_BUCK_MODE_MANUAL 0x00
> +#define DA9063_BUCK_MODE_SLEEP 0x40
> +#define DA9063_BUCK_MODE_SYNC 0x80
> +#define DA9063_BUCK_MODE_AUTO 0xC0
> +
> +#define DA9063_BIO_ILIM_MASK 0x0F
> +#define DA9063_BMEM_ILIM_MASK0xF0
> +#define DA9063_BPRO_ILIM_MASK0x0F
> +#define DA9063_BPERI_ILIM_MASK 0xF0
> +#define DA9063_BCORE1_ILIM_MASK 0x0F
> +#define DA9063_BCORE2_ILIM_MASK 0xF0
> +
> +struct da9063_reg_info {
> + uint min_uV;
> + uint step_uV;
> + uint max_uV;
> + uint min_uA;
> + uint step_uA;
> + uint max_uA;
> + uint en_reg;
> + uint vsel_reg;
> + uint mode_reg;
> + uint ilim_reg;
> + u8 en_mask;
> + u8 vsel_mask;
> + u8 ilim_mask;
> + const char *dt_node_name;
> + const int *current_limits;
> +};
> +
> +struct da9063_priv {
> + const struct da9063_reg_info *reg_info;
> +};
> +
> +static struct dm_regulator_mode da9063_ldo_modes[] = {
> + { .id = DA9063_LDOMODE_SLEEP,
> + .register_value = DA9063_LDO_SL, .name = "SLEEP" },
> + { .id = DA9063_LDOMODE_NORMAL,
> + .register_value = 0, .name = "NORMAL" },
> +};
> +
> +#define DA9063_LDO(regl_name, min_mV, step_mV, max_mV) \
> + .min_uV = (min_mV) * 1000, \
> + .step_uV = (step_mV) * 1000, \
> + .max_uV = (max_mV) * 1000, \
> + .en_reg = DA9063_REG_##regl_name##_CONT, \
> + .en_mask =
Re: [U-Boot] [PATCH v2 39/41] power: pmic: add driver for Dialog DA9063 PMIC
Hi Robert,
On 23.10.19 20:22, Robert Beckett wrote:
> From: Martin Fuzzey
>
> This adds the basic register access operations and child regulator
> binding (if a regulator driver exists).
>
> Robert Beckett: simplify accesses by using bottom bit of address as
> offset overflow. This avoids the need to track which page we are on.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
> ---
> drivers/power/pmic/Kconfig | 7 +
> drivers/power/pmic/Makefile | 1 +
> drivers/power/pmic/da9063.c | 130 +++
> include/power/da9063_pmic.h | 308
> 4 files changed, 446 insertions(+)
> create mode 100644 drivers/power/pmic/da9063.c
> create mode 100644 include/power/da9063_pmic.h
>
> diff --git a/drivers/power/pmic/Kconfig b/drivers/power/pmic/Kconfig
> index 586772fdec..ea3977b4cb 100644
> --- a/drivers/power/pmic/Kconfig
> +++ b/drivers/power/pmic/Kconfig
> @@ -40,6 +40,13 @@ config PMIC_ACT8846
> functions. It uses an I2C interface and is designed for use with
> tablets and smartphones.
>
> +config DM_PMIC_DA9063
> + bool "Enable Driver Model for the Dialog DA9063 PMIC"
> + depends on DM_PMIC
> + help
> + This config enables implementation of driver-model pmic uclass
> features
> + for PMIC DA9063. The driver implements read/write operations.
> +
> config PMIC_AS3722
> bool "Enable support for the Austria Micro Systems (AMS) AS7322 PMIC"
> help
> diff --git a/drivers/power/pmic/Makefile b/drivers/power/pmic/Makefile
> index 888dbb2857..6d9de2efb1 100644
> --- a/drivers/power/pmic/Makefile
> +++ b/drivers/power/pmic/Makefile
> @@ -5,6 +5,7 @@
>
> obj-$(CONFIG_DM_PMIC) += pmic-uclass.o
> obj-$(CONFIG_DM_PMIC_FAN53555) += fan53555.o
> +obj-$(CONFIG_DM_PMIC_DA9063) += da9063.o
Can you please change this to "obj-$(CONFIG_$(SPL_)DM_PMIC_DA9063)" and
add an option CONFIG_SPL_DM_PMIC_DA9063 to Kconfig?
This will allow us to enable the driver for SPL and U-Boot proper
separately.
Thanks,
Frieder
> obj-$(CONFIG_DM_PMIC_MAX77686) += max77686.o
> obj-$(CONFIG_DM_PMIC_MAX8998) += max8998.o
> obj-$(CONFIG_DM_PMIC_MC34708) += mc34708.o
> diff --git a/drivers/power/pmic/da9063.c b/drivers/power/pmic/da9063.c
> new file mode 100644
> index 00..abda7a5a40
> --- /dev/null
> +++ b/drivers/power/pmic/da9063.c
> @@ -0,0 +1,130 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Flowbird
> + * Martin Fuzzey
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct pmic_child_info pmic_children_info[] = {
> + { .prefix = "ldo", .driver = DA9063_LDO_DRIVER },
> + { .prefix = "b", .driver = DA9063_BUCK_DRIVER },
> + { },
> +};
> +
> +/*
> + * The register map is non contiguous and attempts to read in the holes fail.
> + * But "pmic dump" tries to dump the full register map.
> + * So define the holes here so we can fix that.
> + */
> +struct da9063_reg_hole {
> + u16 first;
> + u16 last;
> +};
> +
> +static const struct da9063_reg_hole da9063_reg_holes[] = {
> + DA9063_REG_HOLE_1,
> + DA9063_REG_HOLE_2,
> + DA9063_REG_HOLE_3,
> + /* These aren't readable. I can't see why from the datasheet but
> + * attempts to read fail and the kernel marks them unreadable too,
> + */
> + {DA9063_REG_OTP_COUNT, DA9063_REG_OTP_DATA},
> +};
> +
> +static int da9063_reg_count(struct udevice *dev)
> +{
> + return DA9063_NUM_OF_REGS;
> +}
> +
> +static bool da9063_reg_valid(uint reg)
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(da9063_reg_holes); i++) {
> + const struct da9063_reg_hole *hole = _reg_holes[i];
> +
> + if (reg >= hole->first && reg <= hole->last)
> + return false;
> + }
> +
> + return true;
> +}
> +
> +static int da9063_write(struct udevice *dev, uint reg, const uint8_t *buff,
> + int len)
> +{
> + if (dm_i2c_write(dev, reg, buff, len)) {
> + pr_err("write error to device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int da9063_read(struct udevice *dev, uint reg, uint8_t *buff, int len)
> +{
> + if (!da9063_reg_valid(reg))
> + return -ENODATA;
> +
> + if (dm_i2c_read(dev, reg, buff, len)) {
> + pr_err("read error from device: %p register: %#x!", dev, reg);
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static int da9063_bind(struct udevice *dev)
> +{
> + ofnode regulators_node;
> + int children;
> +
> + regulators_node = dev_read_subnode(dev, "regulators");
> + if (!ofnode_valid(regulators_node)) {
> + debug("%s: %s regulators subnode not found!", __func__,
> + dev->name);
> + return -ENXIO;
> + }
> +
> + debug("%s: '%s' - found
[U-Boot] [PATCH] splash: fix build breakage with newer llvm-7
Some configurations (i.e. sandbox) result in unused
splash_display_banner() and we get build errors like:
common/splash.c:148:20: error: unused function 'splash_display_banner'
[-Werror,-Wunused-function]
static inline void splash_display_banner(void) { }
Drop empty inline function and add guards around the call.
Fixes: d2a8271c8851 ("splash: fix splash banner output")
Signed-off-by: Anatolij Gustschin
Reported-by: Tom Rini
---
common/splash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/splash.c b/common/splash.c
index 0bcedbb0ba..e7d847726d 100644
--- a/common/splash.c
+++ b/common/splash.c
@@ -144,8 +144,6 @@ void splash_display_banner(void)
vidconsole_put_string(dev, buf);
vidconsole_position_cursor(dev, 0, row);
}
-#else
-static inline void splash_display_banner(void) { }
#endif /* CONFIG_DM_VIDEO && !CONFIG_HIDE_LOGO_VERSION */
/*
@@ -177,7 +175,9 @@ int splash_display(void)
if (x || y)
goto end;
+#if defined(CONFIG_DM_VIDEO) && !defined(CONFIG_HIDE_LOGO_VERSION)
splash_display_banner();
+#endif
end:
return ret;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 38/41] pmic: allow dump command for non contiguous register maps
On 23.10.19 20:21, Robert Beckett wrote:
> From: Martin Fuzzey
>
> Some PMICs (such as the DA9063) have non-contiguous register maps.
> Attempting to read the non implemented registers returns an error
> rather than a dummy value which causes 'pmic dump' to terminate
> prematurely.
>
> Fix this by allowing the PMIC driver to return -ENODATA for such
> registers, which will then be displayed as '--' by pmic dump.
>
> Use a single error code rather than any error code so that
> we can distinguish between a hardware failure reading the PMIC
> and a non implemented register known to the driver.
>
> Signed-off-by: Martin Fuzzey
> Signed-off-by: Robert Beckett
Reviewed-by: Frieder Schrempf
Tested-by: Frieder Schrempf
> ---
> cmd/pmic.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/pmic.c b/cmd/pmic.c
> index e46d813a70..2400bfb601 100644
> --- a/cmd/pmic.c
> +++ b/cmd/pmic.c
> @@ -95,7 +95,7 @@ static int do_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
>
> for (reg = 0; reg < pmic_reg_count(dev); reg++) {
> ret = pmic_reg_read(dev, reg);
> - if (ret < 0) {
> + if (ret < 0 && ret != -ENODATA) {
> printf("Can't read register: %d\n", reg);
> return failure(ret);
> }
> @@ -103,7 +103,15 @@ static int do_dump(cmd_tbl_t *cmdtp, int flag, int argc,
> char * const argv[])
> if (!(reg % 16))
> printf("\n0x%02x: ", reg);
>
> - printf(fmt, ret);
> + if (ret == -ENODATA) {
> + int i;
> +
> + for (i = 0; i < priv->trans_len; i++)
> + puts("--");
> + puts(" ");
> + } else {
> + printf(fmt, ret);
> + }
> }
> printf("\n");
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 00/26]MTD defconfigs/Kconfigs/Makefiles heavy cleanup
On Thu, Oct 03, 2019 at 07:50:02PM +0200, Miquel Raynal wrote: > Hello, > > A year ago, while working on SPI-NAND support in U-Boot, I discovered > when modifying Makefiles a confusing organization where: > * Sub-directories/files are compiled from the root Makefile > * Commands are at the root of everything > > First I sent a series to move Makefile entries in their respective > directories. Then, I decided to continue working on the clarification > of the Makefile hierarchy in MTD and I sent four iterations of this > series which did not got merge at that time. Anyway, I revived this > series by rebasing all my work and updating everything that needed an > update. > > Here are the main points of the re-organization: > * Rename CONFIG_MTD into CONFIG_DM_MTD to reserve CONFIG_MTD to what > is called today CONFIG_MTD_DEVICE. > * Fix build dependencies in defconfigs, like: "UBI and NAND depend on MTD". > * Fix the Kconfig files to reflect these dependencies (as defconfigs > have been updated, nothing should break). > * Simplify the Makefiles: compiling the drivers/mtd/nand/raw/ > sub-directory should just depend on MTD being compiled and the NAND > core as well, there is absolutely no logic to make it depend on > CMD_NAND. > > The New green Travis CI build for the fifth version of this series is > there (yes, 53 iterations): > > Please note that the only red test fails because of timeout, not an > actual error (at least I could not spot it). It is possible that this > series will produce noticeable changes for the users. The only reason > for that is because their configuration file was wrong. I have done my > best to fix them one by one, but I am not omniscient. OK, so I want to grab this series, and I intend to do my best to do so. But the problem this exposes is just how complex the uses of CONFIG_NAND got and in turn symbol re-use, on PowerPC. This (+ v6) showed a few minor migration problems when I size compared, and those are easily fixed. What isn't so easily fixed is that it was also changing how/where the environment is found on some PowerPC boards. Fixing that in turn requires finally finishing off the migration of the main CONFIG_ENV_xxx symbols to Kconfig. I have this done outside of about 20 boards. I'm going to get that finished up as soon as I can and posted, then make this series depend on that. Thanks again for doing the hard work here, we really need this particular migration and clean up! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] mx7ulp: scg: Remove unnused scg_a7_apll_init()
scg_a7_apll_init() is not called anywhere, so remove such dead code
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
arch/arm/include/asm/arch-mx7ulp/scg.h | 1 -
arch/arm/mach-imx/mx7ulp/scg.c | 61 --
2 files changed, 62 deletions(-)
diff --git a/arch/arm/include/asm/arch-mx7ulp/scg.h
b/arch/arm/include/asm/arch-mx7ulp/scg.h
index 531d8f3a95..b79bde338f 100644
--- a/arch/arm/include/asm/arch-mx7ulp/scg.h
+++ b/arch/arm/include/asm/arch-mx7ulp/scg.h
@@ -331,7 +331,6 @@ u32 decode_pll(enum pll_clocks pll);
void scg_a7_rccr_init(void);
void scg_a7_spll_init(void);
void scg_a7_ddrclk_init(void);
-void scg_a7_apll_init(void);
void scg_a7_firc_init(void);
void scg_a7_nicclk_init(void);
void scg_a7_sys_clk_sel(enum scg_sys_src clk);
diff --git a/arch/arm/mach-imx/mx7ulp/scg.c b/arch/arm/mach-imx/mx7ulp/scg.c
index 819c90af6c..c7bb7a1c66 100644
--- a/arch/arm/mach-imx/mx7ulp/scg.c
+++ b/arch/arm/mach-imx/mx7ulp/scg.c
@@ -949,67 +949,6 @@ void scg_a7_ddrclk_init(void)
/* Clock source is System OSC <<0 */
#define SCG1_APLL_CFG_CLKSRC_NUM((0x0) << SCG_PLL_CFG_CLKSRC_SHIFT)
-/*
- * A7 APLL = 24MHz / 1 * 22 / 1 / 1 = 528MHz,
- * system PLL is sourced from APLL,
- * APLL clock source is system OSC (24MHz)
- */
-#define SCG1_APLL_CFG_NUM_24M_OSC (SCG1_APLL_CFG_POSTDIV2_NUM | \
- SCG1_APLL_CFG_POSTDIV1_NUM | \
- (22 << SCG_PLL_CFG_MULT_SHIFT) | \
- SCG1_APLL_CFG_PFDSEL_NUM | \
- SCG1_APLL_CFG_PREDIV_NUM | \
- SCG1_APLL_CFG_BYPASS_NUM | \
- SCG1_APLL_CFG_PLLSEL_NUM | \
- SCG1_APLL_CFG_CLKSRC_NUM)
-
-/* PFD0 Freq = A7 APLL(528MHz) * 18 / 27 = 352MHz */
-#define SCG1_APLL_PFD0_FRAC_NUM (27)
-
-
-void scg_a7_apll_init(void)
-{
- u32 val = 0;
-
- /* Disable A7 Auxiliary PLL */
- val = readl(_regs->apllcsr);
- val &= ~SCG_APLL_CSR_APLLEN_MASK;
- writel(val, _regs->apllcsr);
-
- /* Gate off A7 APLL PFD0 ~ PDF4 */
- val = readl(_regs->apllpfd);
- val |= 0x80808080;
- writel(val, _regs->apllpfd);
-
- /* A7 APLL Configuration Start == */
- /* Configure A7 Auxiliary PLL */
- writel(SCG1_APLL_CFG_NUM_24M_OSC, _regs->apllcfg);
-
- /* Enable A7 Auxiliary PLL */
- val = readl(_regs->apllcsr);
- val |= SCG_APLL_CSR_APLLEN_MASK;
- writel(val, _regs->apllcsr);
-
- /* Wait for A7 APLL clock ready */
- while (!(readl(_regs->apllcsr) & SCG_APLL_CSR_APLLVLD_MASK))
- ;
-
- /* Configure A7 APLL PFD0 */
- val = readl(_regs->apllpfd);
- val &= ~SCG_PLL_PFD0_FRAC_MASK;
- val |= SCG1_APLL_PFD0_FRAC_NUM;
- writel(val, _regs->apllpfd);
-
- /* Un-gate A7 APLL PFD0 */
- val = readl(_regs->apllpfd);
- val &= ~SCG_PLL_PFD0_GATE_MASK;
- writel(val, _regs->apllpfd);
-
- /* Wait for A7 APLL PFD0 clock being valid */
- while (!(readl(_regs->apllpfd) & SCG_PLL_PFD0_VALID_MASK))
- ;
-}
-
/* SCG1(A7) FIRC DIV configurations */
/* Disable FIRC DIV3 */
#define SCG1_FIRCDIV_DIV3_NUM ((0x0) << SCG_FIRCDIV_DIV3_SHIFT)
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] mx7ulp: Print the LDO mode status
As per the i.MX7ULP datasheet, it can boot in LDO enabled mode
or LDO bypass mode.
Print the LDO mode status in the U-Boot log for convenience.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
arch/arm/mach-imx/mx7ulp/soc.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index 127fcfeea1..b9a108a514 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -131,6 +131,21 @@ const char *get_imx_type(u32 imxtype)
return "7ULP";
}
+#define PMC0_BASE_ADDR 0x410a1000
+#define PMC0_CTRL 0x28
+#define PMC0_CTRL_LDOENBIT(31)
+
+static bool ldo_mode_is_enabled(void)
+{
+ unsigned int reg;
+
+ reg = readl(PMC0_BASE_ADDR + PMC0_CTRL);
+ if (reg & PMC0_CTRL_LDOEN)
+ return true;
+ else
+ return false;
+}
+
int print_cpuinfo(void)
{
u32 cpurev;
@@ -159,6 +174,11 @@ int print_cpuinfo(void)
break;
}
+ if (ldo_mode_is_enabled())
+ printf("PMC1: LDO enabled mode\n");
+ else
+ printf("PMC1: LDO bypass mode\n");
+
return 0;
}
#endif
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] mx7ulp: Introduce the CONFIG_LDO_ENABLED_MODE option
Introduce the CONFIG_LDO_ENABLED_MODE option so that i.MX7ULP boards
designed to operate with LDO enabled mode can work with 0.95V at LDO
output in RUN mode as per the datasheet.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- None
arch/arm/mach-imx/mx7ulp/Kconfig | 5 +++
arch/arm/mach-imx/mx7ulp/soc.c | 58
2 files changed, 63 insertions(+)
diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index ed5f0aeb2d..138c58363f 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -3,6 +3,11 @@ if ARCH_MX7ULP
config SYS_SOC
default "mx7ulp"
+config LDO_ENABLED_MODE
+ bool "i.MX7ULP LDO Enabled Mode"
+ help
+ Select this option to enable the PMC1 LDO.
+
config MX7ULP
bool
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index b9a108a514..751575c95e 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -9,6 +9,22 @@
#include
#include
+#define PMC0_BASE_ADDR 0x410a1000
+#define PMC0_CTRL 0x28
+#define PMC0_CTRL_LDOENBIT(31)
+#define PMC0_CTRL_LDOOKDIS BIT(30)
+#define PMC0_CTRL_PMC1ON BIT(24)
+#define PMC1_BASE_ADDR 0x4040
+#define PMC1_RUN 0x8
+#define PMC1_STOP 0x10
+#define PMC1_VLPS 0x14
+#define PMC1_RUN_LDOVL_SHIFT 16
+#define PMC1_RUN_LDOVL_MASK(0x3f << PMC1_RUN_LDOVL_SHIFT)
+#define PMC1_RUN_LDOVL_900 0x1e
+#define PMC1_RUN_LDOVL_950 0x23
+#define PMC1_STATUS0x20
+#define PMC1_STATUS_LDOVLF BIT(8)
+
static char *get_reset_cause(char *);
#if defined(CONFIG_IMX_HAB)
@@ -100,6 +116,44 @@ void init_wdog(void)
disable_wdog(WDG2_RBASE);
}
+#if defined(CONFIG_LDO_ENABLED_MODE)
+static void init_ldo_mode(void)
+{
+ unsigned int reg;
+
+ /* Set LDOOKDIS */
+ setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOOKDIS);
+
+ /* Set LDOVL to 0.95V in PMC1_RUN */
+ reg = readl(PMC1_BASE_ADDR + PMC1_RUN);
+ reg &= ~PMC1_RUN_LDOVL_MASK;
+ reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+ writel(PMC1_BASE_ADDR + PMC1_RUN, reg);
+
+ /* Wait for LDOVLF to be cleared */
+ reg = readl(PMC1_BASE_ADDR + PMC1_STATUS);
+ while (reg & PMC1_STATUS_LDOVLF)
+ ;
+
+ /* Set LDOVL to 0.95V in PMC1_STOP */
+ reg = readl(PMC1_BASE_ADDR + PMC1_STOP);
+ reg &= ~PMC1_RUN_LDOVL_MASK;
+ reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT);
+ writel(PMC1_BASE_ADDR + PMC1_STOP, reg);
+
+ /* Set LDOVL to 0.90V in PMC1_VLPS */
+ reg = readl(PMC1_BASE_ADDR + PMC1_VLPS);
+ reg &= ~PMC1_RUN_LDOVL_MASK;
+ reg |= (PMC1_RUN_LDOVL_900 << PMC1_RUN_LDOVL_SHIFT);
+ writel(PMC1_BASE_ADDR + PMC1_VLPS, reg);
+
+ /* Set LDOEN bit */
+ setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_LDOEN);
+
+ /* Set the PMC1ON bit */
+ setbits_le32(PMC0_BASE_ADDR + PMC0_CTRL, PMC0_CTRL_PMC1ON);
+}
+#endif
void s_init(void)
{
@@ -113,6 +167,10 @@ void s_init(void)
/* enable dumb pmic */
writel((readl(SNVS_LP_LPCR) | SNVS_LPCR_DPEN), SNVS_LP_LPCR);
}
+
+#if defined(CONFIG_LDO_ENABLED_MODE)
+ init_ldo_mode();
+#endif
return;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] mx7ulp: Add support for Embedded Artists COM board
The Embedded Artists COM board is based on NXP i.MX7ULP. It has a BD70528 PMIC from Rohm with discrete DCDC powering option and improved current observability (compared to the existing NXP i.MX7ULP EVK). Add the initial support for the board. Signed-off-by: Fabio Estevam --- Changes since v1: - Lower the DDR frequency inside DCD as it is safer (Ye Li) - Drop CONFIG_IMX7ULP_LOWER_DDR_FREQUENCY=y arch/arm/dts/Makefile| 3 +- arch/arm/mach-imx/mx7ulp/Kconfig | 6 ++ board/ea/mx7ulp_com/Kconfig | 12 +++ board/ea/mx7ulp_com/MAINTAINERS | 6 ++ board/ea/mx7ulp_com/Makefile | 6 ++ board/ea/mx7ulp_com/imximage.cfg | 137 +++ board/ea/mx7ulp_com/mx7ulp_com.c | 48 +++ configs/mx7ulp_com_defconfig | 58 + include/configs/mx7ulp_com.h | 107 9 files changed, 382 insertions(+), 1 deletion(-) create mode 100644 board/ea/mx7ulp_com/Kconfig create mode 100644 board/ea/mx7ulp_com/MAINTAINERS create mode 100644 board/ea/mx7ulp_com/Makefile create mode 100644 board/ea/mx7ulp_com/imximage.cfg create mode 100644 board/ea/mx7ulp_com/mx7ulp_com.c create mode 100644 configs/mx7ulp_com_defconfig create mode 100644 include/configs/mx7ulp_com.h diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 6a7dbb6309..c5c29dbcd0 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -645,7 +645,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \ imx7d-pico-hobbit.dtb -dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-evk.dtb +dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \ + imx7ulp-evk.dtb dtb-$(CONFIG_ARCH_IMX8) += \ fsl-imx8qm-apalis.dtb \ diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig index 138c58363f..6680f856c5 100644 --- a/arch/arm/mach-imx/mx7ulp/Kconfig +++ b/arch/arm/mach-imx/mx7ulp/Kconfig @@ -15,6 +15,11 @@ choice prompt "MX7ULP board select" optional +config TARGET_MX7ULP_COM + bool "Support MX7ULP COM board" + select MX7ULP + select SYS_ARCH_TIMER + config TARGET_MX7ULP_EVK bool "Support mx7ulp EVK board" select MX7ULP @@ -22,6 +27,7 @@ config TARGET_MX7ULP_EVK endchoice +source "board/ea/mx7ulp_com/Kconfig" source "board/freescale/mx7ulp_evk/Kconfig" endif diff --git a/board/ea/mx7ulp_com/Kconfig b/board/ea/mx7ulp_com/Kconfig new file mode 100644 index 00..90883aced4 --- /dev/null +++ b/board/ea/mx7ulp_com/Kconfig @@ -0,0 +1,12 @@ +if TARGET_MX7ULP_COM + +config SYS_BOARD + default "mx7ulp_com" + +config SYS_VENDOR + default "ea" + +config SYS_CONFIG_NAME + default "mx7ulp_com" + +endif diff --git a/board/ea/mx7ulp_com/MAINTAINERS b/board/ea/mx7ulp_com/MAINTAINERS new file mode 100644 index 00..3f69511b1a --- /dev/null +++ b/board/ea/mx7ulp_com/MAINTAINERS @@ -0,0 +1,6 @@ +MX7ULPCOM BOARD +M: Fabio Estevam +S: Maintained +F: board/ea/mx7ulp_com/ +F: include/configs/mx7ulp_com.h +F: configs/mx7ulp_com_defconfig diff --git a/board/ea/mx7ulp_com/Makefile b/board/ea/mx7ulp_com/Makefile new file mode 100644 index 00..b3b230b172 --- /dev/null +++ b/board/ea/mx7ulp_com/Makefile @@ -0,0 +1,6 @@ +# (C) Copyright 2016 Freescale Semiconductor, Inc. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y := mx7ulp_com.o diff --git a/board/ea/mx7ulp_com/imximage.cfg b/board/ea/mx7ulp_com/imximage.cfg new file mode 100644 index 00..e405d758b5 --- /dev/null +++ b/board/ea/mx7ulp_com/imximage.cfg @@ -0,0 +1,137 @@ +/* + * Copyright (C) 2016 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + * + * Refer docs/README.imxmage for more details about how-to configure + * and create imximage boot image + * + * The syntax is taken as close as possible with the kwbimage + */ + +#define __ASSEMBLY__ +#include + +/* image version */ + +IMAGE_VERSION 2 + +/* + * Boot Device : one of + * spi/sd/nand/onenand, qspi/nor + */ + +BOOT_FROM sd + +#ifdef CONFIG_USE_IMXIMG_PLUGIN +/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/ +PLUGIN board/freescale/mx7ulp_evk/plugin.bin 0x2F02 +#else + +#ifdef CONFIG_SECURE_BOOT +CSF CONFIG_CSF_SIZE +#endif +/* + * Device Configuration Data (DCD) + * + * Each entry must have the format: + * Addr-type AddressValue + * + * where: + * Addr-type register length (1,2 or 4 bytes) + * Address absolute address of the register + * value value to be stored in the register + */ +DATA 4 0x403f00dc 0x +DATA 4 0x403e0040 0x0120 +DATA 4 0x403e0500 0x0100 +DATA 4 0x403e050c 0x80808080 +DATA 4 0x403e0508 0x00160002 +DATA 4 0x403E0510 0x0001 +DATA 4 0x403E0514 0x0014 +DATA 4 0x403e0500 0x0001 +CHECK_BITS_SET 4 0x403e0500 0x0100 +/* + * Default PFD0 divide is 27, which generates: + * PFD0 Freq = A7 APLL(528MHz) * 18 / 27 = 352MHz + * + * i.MX7ULP COM board can not run DDR at 352MHz, so + * use a
[U-Boot] [PATCH v2 3/6] mx7ulp: Remove the _RUN notation from the PMC1 LDOVL definitions
The LDOVL definitions is common to all the modes, not only RUN mode, so in order to avoid confusion, remove the _RUN notation from the PMC1 LDOVL definitions. Signed-off-by: Fabio Estevam --- Changes since v1: - None arch/arm/mach-imx/mx7ulp/soc.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c index 751575c95e..4487fa61c0 100644 --- a/arch/arm/mach-imx/mx7ulp/soc.c +++ b/arch/arm/mach-imx/mx7ulp/soc.c @@ -18,10 +18,10 @@ #define PMC1_RUN 0x8 #define PMC1_STOP 0x10 #define PMC1_VLPS 0x14 -#define PMC1_RUN_LDOVL_SHIFT 16 -#define PMC1_RUN_LDOVL_MASK(0x3f << PMC1_RUN_LDOVL_SHIFT) -#define PMC1_RUN_LDOVL_900 0x1e -#define PMC1_RUN_LDOVL_950 0x23 +#define PMC1_LDOVL_SHIFT 16 +#define PMC1_LDOVL_MASK(0x3f << PMC1_LDOVL_SHIFT) +#define PMC1_LDOVL_900 0x1e +#define PMC1_LDOVL_950 0x23 #define PMC1_STATUS0x20 #define PMC1_STATUS_LDOVLF BIT(8) @@ -126,8 +126,8 @@ static void init_ldo_mode(void) /* Set LDOVL to 0.95V in PMC1_RUN */ reg = readl(PMC1_BASE_ADDR + PMC1_RUN); - reg &= ~PMC1_RUN_LDOVL_MASK; - reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT); + reg &= ~PMC1_LDOVL_MASK; + reg |= (PMC1_LDOVL_950 << PMC1_LDOVL_SHIFT); writel(PMC1_BASE_ADDR + PMC1_RUN, reg); /* Wait for LDOVLF to be cleared */ @@ -137,14 +137,14 @@ static void init_ldo_mode(void) /* Set LDOVL to 0.95V in PMC1_STOP */ reg = readl(PMC1_BASE_ADDR + PMC1_STOP); - reg &= ~PMC1_RUN_LDOVL_MASK; - reg |= (PMC1_RUN_LDOVL_950 << PMC1_RUN_LDOVL_SHIFT); + reg &= ~PMC1_LDOVL_MASK; + reg |= (PMC1_LDOVL_950 << PMC1_LDOVL_SHIFT); writel(PMC1_BASE_ADDR + PMC1_STOP, reg); /* Set LDOVL to 0.90V in PMC1_VLPS */ reg = readl(PMC1_BASE_ADDR + PMC1_VLPS); - reg &= ~PMC1_RUN_LDOVL_MASK; - reg |= (PMC1_RUN_LDOVL_900 << PMC1_RUN_LDOVL_SHIFT); + reg &= ~PMC1_LDOVL_MASK; + reg |= (PMC1_LDOVL_900 << PMC1_LDOVL_SHIFT); writel(PMC1_BASE_ADDR + PMC1_VLPS, reg); /* Set LDOEN bit */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] stm32mp1: remove copro_state environment variable
Since the coprocessor state is tracked in a backup register, there is
no more need for tracking it in an environment variable : remove it.
Signed-off-by: Fabien Dessenne
---
board/st/stm32mp1/stm32mp1.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
index 126af30..ea9afb6 100644
--- a/board/st/stm32mp1/stm32mp1.c
+++ b/board/st/stm32mp1/stm32mp1.c
@@ -935,10 +935,8 @@ static void board_copro_image_process(ulong fw_image,
size_t fw_size)
printf("Load Remote Processor %d with data@addr=0x%08lx %u bytes:%s\n",
id, fw_image, fw_size, ret ? " Failed!" : " Success!");
- if (!ret) {
+ if (!ret)
rproc_start(id);
- env_set("copro_state", "booted");
- }
}
U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_COPRO, board_copro_image_process);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] remoteproc: stm32: load resource table from firmware
Load the optional resource table from the firmware, and write its
address in the dedicated backup register.
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/stm32_copro.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index dcafa54..c25488f 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -22,12 +22,14 @@
* @hold_boot_regmap: regmap for remote processor reset hold boot
* @hold_boot_offset: offset of the register controlling the hold boot setting
* @hold_boot_mask:bitmask of the register for the hold boot field
+ * @rsc_table_addr:resource table address
*/
struct stm32_copro_privdata {
struct reset_ctl reset_ctl;
struct regmap *hold_boot_regmap;
uint hold_boot_offset;
uint hold_boot_mask;
+ ulong rsc_table_addr;
};
/**
@@ -139,6 +141,7 @@ static void *stm32_copro_device_to_virt(struct udevice
*dev, ulong da,
static int stm32_copro_load(struct udevice *dev, ulong addr, ulong size)
{
struct stm32_copro_privdata *priv;
+ ulong rsc_table_size;
int ret;
priv = dev_get_priv(dev);
@@ -153,6 +156,12 @@ static int stm32_copro_load(struct udevice *dev, ulong
addr, ulong size)
return ret;
}
+ if (rproc_elf32_load_rsc_table(dev, addr, size, >rsc_table_addr,
+ _table_size)) {
+ priv->rsc_table_addr = 0;
+ dev_warn(dev, "No valid resource table for this firmware\n");
+ }
+
return rproc_elf32_load_image(dev, addr, size);
}
@@ -163,8 +172,11 @@ static int stm32_copro_load(struct udevice *dev, ulong
addr, ulong size)
*/
static int stm32_copro_start(struct udevice *dev)
{
+ struct stm32_copro_privdata *priv;
int ret;
+ priv = dev_get_priv(dev);
+
/* move hold boot from true to false start the copro */
ret = stm32_copro_set_hold_boot(dev, false);
if (ret)
@@ -177,6 +189,10 @@ static int stm32_copro_start(struct udevice *dev)
ret = stm32_copro_set_hold_boot(dev, true);
writel(ret ? TAMP_COPRO_STATE_OFF : TAMP_COPRO_STATE_CRUN,
TAMP_COPRO_STATE);
+ if (!ret)
+ /* Store rsc_address in bkp register */
+ writel(priv->rsc_table_addr, TAMP_COPRO_RSC_TBL_ADDRESS);
+
return ret;
}
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] remoteproc: stm32: track the coprocessor state in a backup register
Update the dedicated backup register to track the coprocessor state and
rely on that register to compute the .is_running() value (which expects
a return value of 0 -not 1- if the processor is running).
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/stm32_copro.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/remoteproc/stm32_copro.c b/drivers/remoteproc/stm32_copro.c
index 40bba37..dcafa54 100644
--- a/drivers/remoteproc/stm32_copro.c
+++ b/drivers/remoteproc/stm32_copro.c
@@ -22,14 +22,12 @@
* @hold_boot_regmap: regmap for remote processor reset hold boot
* @hold_boot_offset: offset of the register controlling the hold boot setting
* @hold_boot_mask:bitmask of the register for the hold boot field
- * @is_running:is the remote processor running
*/
struct stm32_copro_privdata {
struct reset_ctl reset_ctl;
struct regmap *hold_boot_regmap;
uint hold_boot_offset;
uint hold_boot_mask;
- bool is_running;
};
/**
@@ -165,11 +163,8 @@ static int stm32_copro_load(struct udevice *dev, ulong
addr, ulong size)
*/
static int stm32_copro_start(struct udevice *dev)
{
- struct stm32_copro_privdata *priv;
int ret;
- priv = dev_get_priv(dev);
-
/* move hold boot from true to false start the copro */
ret = stm32_copro_set_hold_boot(dev, false);
if (ret)
@@ -180,7 +175,8 @@ static int stm32_copro_start(struct udevice *dev)
* rebooting autonomously
*/
ret = stm32_copro_set_hold_boot(dev, true);
- priv->is_running = !ret;
+ writel(ret ? TAMP_COPRO_STATE_OFF : TAMP_COPRO_STATE_CRUN,
+ TAMP_COPRO_STATE);
return ret;
}
@@ -206,7 +202,7 @@ static int stm32_copro_reset(struct udevice *dev)
return ret;
}
- priv->is_running = false;
+ writel(TAMP_COPRO_STATE_OFF, TAMP_COPRO_STATE);
return 0;
}
@@ -224,14 +220,11 @@ static int stm32_copro_stop(struct udevice *dev)
/**
* stm32_copro_is_running() - Is the STM32 remote processor running
* @dev: corresponding STM32 remote processor device
- * @return 1 if the remote processor is running, 0 otherwise
+ * @return 0 if the remote processor is running, 1 otherwise
*/
static int stm32_copro_is_running(struct udevice *dev)
{
- struct stm32_copro_privdata *priv;
-
- priv = dev_get_priv(dev);
- return priv->is_running;
+ return (readl(TAMP_COPRO_STATE) == TAMP_COPRO_STATE_OFF);
}
static const struct dm_rproc_ops stm32_copro_ops = {
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] stm32mp1: reset coprocessor status at cold boot
Reset ResourceTableAddress and CoprocessorState at cold boot, preserve
these values at standby wakeup.
Signed-off-by: Fabien Dessenne
---
arch/arm/mach-stm32mp/cpu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index a46e843..e24abf5 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -34,7 +34,9 @@
#define TAMP_CR1 (STM32_TAMP_BASE + 0x00)
#define PWR_CR1(STM32_PWR_BASE + 0x00)
+#define PWR_MCUCR (STM32_PWR_BASE + 0x14)
#define PWR_CR1_DBPBIT(8)
+#define PWR_MCUCR_SBF BIT(6)
/* DBGMCU register */
#define DBGMCU_IDC (STM32_DBGMCU_BASE + 0x00)
@@ -205,6 +207,11 @@ int arch_cpu_init(void)
security_init();
update_bootmode();
#endif
+ /* Reset Coprocessor state unless it wakes up from Standby power mode */
+ if (!(readl(PWR_MCUCR) & PWR_MCUCR_SBF)) {
+ writel(TAMP_COPRO_STATE_OFF, TAMP_COPRO_STATE);
+ writel(0, TAMP_COPRO_RSC_TBL_ADDRESS);
+ }
#endif
boot_mode = get_bootmode();
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] stm32mp1: declare backup registers for coprocessor
Use the backup register #17 as coprocessor resource table address and
backup register #18 as coprocessor state.
Signed-off-by: Fabien Dessenne
---
arch/arm/mach-stm32mp/include/mach/stm32.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h
b/arch/arm/mach-stm32mp/include/mach/stm32.h
index b3e9ccc..88126b8 100644
--- a/arch/arm/mach-stm32mp/include/mach/stm32.h
+++ b/arch/arm/mach-stm32mp/include/mach/stm32.h
@@ -86,9 +86,18 @@ enum boot_device {
#define TAMP_BACKUP_REGISTER(x)(STM32_TAMP_BASE + 0x100 + 4 *
x)
#define TAMP_BACKUP_MAGIC_NUMBER TAMP_BACKUP_REGISTER(4)
#define TAMP_BACKUP_BRANCH_ADDRESS TAMP_BACKUP_REGISTER(5)
+#define TAMP_COPRO_RSC_TBL_ADDRESS TAMP_BACKUP_REGISTER(17)
+#define TAMP_COPRO_STATE TAMP_BACKUP_REGISTER(18)
#define TAMP_BOOT_CONTEXT TAMP_BACKUP_REGISTER(20)
#define TAMP_BOOTCOUNT TAMP_BACKUP_REGISTER(21)
+#define TAMP_COPRO_STATE_OFF 0
+#define TAMP_COPRO_STATE_INIT 1
+#define TAMP_COPRO_STATE_CRUN 2
+#define TAMP_COPRO_STATE_CSTOP 3
+#define TAMP_COPRO_STATE_STANDBY 4
+#define TAMP_COPRO_STATE_CRASH 5
+
#define TAMP_BOOT_MODE_MASKGENMASK(15, 8)
#define TAMP_BOOT_MODE_SHIFT 8
#define TAMP_BOOT_DEVICE_MASK GENMASK(7, 4)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/6] remoteproc: elf_loader: Add elf resource table load support
Add rproc_elf_load_rsc_table(), which searches for a resource table in
an elf64/elf32 image, and if found, copies it to device memory.
Add also the elf32 and elf64 variants of this API.
Add a test for this.
Signed-off-by: Fabien Dessenne
---
drivers/remoteproc/rproc-elf-loader.c | 269 ++
include/remoteproc.h | 70 +
test/dm/remoteproc.c | 91 ++--
3 files changed, 419 insertions(+), 11 deletions(-)
diff --git a/drivers/remoteproc/rproc-elf-loader.c
b/drivers/remoteproc/rproc-elf-loader.c
index b38a226..9127ea5 100644
--- a/drivers/remoteproc/rproc-elf-loader.c
+++ b/drivers/remoteproc/rproc-elf-loader.c
@@ -7,6 +7,39 @@
#include
#include
+/**
+ * struct resource_table - firmware resource table header
+ * @ver: version number
+ * @num: number of resource entries
+ * @reserved: reserved (must be zero)
+ * @offset: array of offsets pointing at the various resource entries
+ *
+ * A resource table is essentially a list of system resources required
+ * by the remote processor. It may also include configuration entries.
+ * If needed, the remote processor firmware should contain this table
+ * as a dedicated ".resource_table" ELF section.
+ *
+ * Some resources entries are mere announcements, where the host is informed
+ * of specific remoteproc configuration. Other entries require the host to
+ * do something (e.g. allocate a system resource). Sometimes a negotiation
+ * is expected, where the firmware requests a resource, and once allocated,
+ * the host should provide back its details (e.g. address of an allocated
+ * memory region).
+ *
+ * The header of the resource table, as expressed by this structure,
+ * contains a version number (should we need to change this format in the
+ * future), the number of available resource entries, and their offsets
+ * in the table.
+ *
+ * Immediately following this header are the resource entries themselves.
+ */
+struct resource_table {
+ u32 ver;
+ u32 num;
+ u32 reserved[2];
+ u32 offset[0];
+} __packed;
+
/* Basic function to verify ELF32 image format */
int rproc_elf32_sanity_check(ulong addr, ulong size)
{
@@ -275,3 +308,239 @@ ulong rproc_elf_get_boot_addr(struct udevice *dev, ulong
addr)
else
return rproc_elf32_get_boot_addr(addr);
}
+
+/*
+ * Search for the resource table in an ELF32 image.
+ * Returns the address of the resource table section if found, NULL if there is
+ * no resource table section, or error pointer.
+ */
+static Elf32_Shdr *rproc_elf32_find_rsc_table(struct udevice *dev,
+ ulong fw_addr, ulong fw_size)
+{
+ int ret;
+ unsigned int i;
+ const char *name_table;
+ struct resource_table *table;
+ const u8 *elf_data = (void *)fw_addr;
+ Elf32_Ehdr *ehdr = (Elf32_Ehdr *)fw_addr;
+ Elf32_Shdr *shdr;
+
+ ret = rproc_elf32_sanity_check(fw_addr, fw_size);
+ if (ret) {
+ pr_debug("Invalid ELF32 Image %d\n", ret);
+ return ERR_PTR(ret);
+ }
+
+ /* look for the resource table and handle it */
+ shdr = (Elf32_Shdr *)(elf_data + ehdr->e_shoff);
+ name_table = (const char *)(elf_data +
+ shdr[ehdr->e_shstrndx].sh_offset);
+
+ for (i = 0; i < ehdr->e_shnum; i++, shdr++) {
+ u32 size = shdr->sh_size;
+ u32 offset = shdr->sh_offset;
+
+ if (strcmp(name_table + shdr->sh_name, ".resource_table"))
+ continue;
+
+ table = (struct resource_table *)(elf_data + offset);
+
+ /* make sure we have the entire table */
+ if (offset + size > fw_size) {
+ pr_debug("resource table truncated\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
+ /* make sure table has at least the header */
+ if (sizeof(*table) > size) {
+ pr_debug("header-less resource table\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
+ /* we don't support any version beyond the first */
+ if (table->ver != 1) {
+ pr_debug("unsupported fw ver: %d\n", table->ver);
+ return ERR_PTR(-EPROTONOSUPPORT);
+ }
+
+ /* make sure reserved bytes are zeroes */
+ if (table->reserved[0] || table->reserved[1]) {
+ pr_debug("non zero reserved bytes\n");
+ return ERR_PTR(-EBADF);
+ }
+
+ /* make sure the offsets array isn't truncated */
+ if (table->num * sizeof(table->offset[0]) +
+sizeof(*table) > size) {
+ pr_debug("resource table incomplete\n");
+ return ERR_PTR(-ENOSPC);
+ }
+
+
[U-Boot] [PATCH v2 0/6] remoteproc: add elf resource table loader
Add some helpers that can be called by the drivers to load the firmware resource table from an elf32 / elf64 image. The stm32 remoteproc driver makes use of it, to load the resource table before the elf image itself. Changes since v1: -Do not fixup the DeviceTree to track the stm32 coprocessor state. Instead of this, use a dedicated register. Fabien Dessenne (6): remoteproc: elf_loader: Add elf resource table load support stm32mp1: declare backup registers for coprocessor stm32mp1: reset coprocessor status at cold boot remoteproc: stm32: track the coprocessor state in a backup register stm32mp1: remove copro_state environment variable remoteproc: stm32: load resource table from firmware arch/arm/mach-stm32mp/cpu.c| 7 + arch/arm/mach-stm32mp/include/mach/stm32.h | 9 + board/st/stm32mp1/stm32mp1.c | 4 +- drivers/remoteproc/rproc-elf-loader.c | 269 + drivers/remoteproc/stm32_copro.c | 27 ++- include/remoteproc.h | 70 test/dm/remoteproc.c | 91 -- 7 files changed, 454 insertions(+), 23 deletions(-) -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] "splash: fix splash banner output" and newer llvm-7
Hi Tom,
On Wed, 30 Oct 2019 09:01:37 -0400
Tom Rini tr...@konsulko.com wrote:
...
> +common/splash.c:148:20: error: unused function 'splash_display_banner'
> [-Werror,-Wunused-function]
> +static inline void splash_display_banner(void) { }
> + ^
> +1 error generated.
> +make[2]: *** [common/splash.o] Error 1
> +make[1]: *** [common] Error 2
> +make: *** [sub-make] Error 2
>
> Can you please take a look? Thanks!
I'll send a fix soon.
Thanks,
--
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] common/console.c: Fix unused warning with console_doenv()
Newer versions of LLVM-7 will provide an unused function warning over
console_doenv() in the case of SYS_CONSOLE_IS_IN_ENV not being enabled
as can be the case in SPL. Add guards around this function.
Signed-off-by: Tom Rini
---
common/console.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/console.c b/common/console.c
index 89b1e9590cad..168ba60d0d9e 100644
--- a/common/console.c
+++ b/common/console.c
@@ -252,10 +252,12 @@ static void console_puts(int file, const char *s)
}
}
+#if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)
static inline void console_doenv(int file, struct stdio_dev *dev)
{
iomux_doenv(file, dev->name);
}
+#endif
#else
static inline int console_getc(int file)
{
@@ -283,10 +285,12 @@ static inline void console_puts(int file, const char *s)
stdio_devices[file]->puts(stdio_devices[file], s);
}
+#if CONFIG_IS_ENABLED(SYS_CONSOLE_IS_IN_ENV)
static inline void console_doenv(int file, struct stdio_dev *dev)
{
console_setfile(file, dev);
}
+#endif
#endif /* CONIFIG_IS_ENABLED(CONSOLE_MUX) */
/** U-Boot INITIAL CONSOLE-NOT COMPATIBLE FUNCTIONS */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/15] buildman: Convert to Python 3
On Tue, Oct 29, 2019 at 07:47:55PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 24 Oct 2019 at 19:04, Simon Glass wrote: > > > > Convert buildman to Python 3 and make it use that, to meet the 2020 > > deadline. > > > > Signed-off-by: Simon Glass > > --- > > > > Changes in v2: None > > > > tools/buildman/board.py | 7 +-- > > tools/buildman/bsettings.py | 20 +++ > > tools/buildman/builder.py | 45 > > tools/buildman/builderthread.py | 24 - > > tools/buildman/buildman.py | 10 ++-- > > tools/buildman/control.py | 40 +++--- > > tools/buildman/func_test.py | 16 +++--- > > tools/buildman/test.py | 22 > > tools/buildman/toolchain.py | 93 + > > 9 files changed, 139 insertions(+), 138 deletions(-) > > I am a bit mystified by this: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/jobs/25186 > > It runs locally and I cannot see why it is not using unicode. Are > there instructions on how to get to the same Python version as gitlab? > I fear a steep learning curve coming. First, I think the problem is this series will also need the test.py python3 series as that does a few more things to get and provide a python3 environment to use. I'll try and throw something together to test that shortly. Second, to have the same environment locally: $ sudo docker pull trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 And change the tag to whatever .gitlab-ci.yml says we use. That one is what the test.py series brings us up to, and is newer than your failing job. $ sudo docker run --rm -it -v /your/local/u-boot/clone/..:/build/u-boot \ trini/u-boot-gitlab-ci-runner:bionic-20191010-20Oct2019 /bin/bash And don't pass --rm if you don't want the image deleted once you exit. That will put you in a bash prompt as the user we run everything as. Follow the steps in the job as described in .gitlab-ci.yml to do a build by hand. And yes, you want to pass in one level before your clone so that in the container you have /build/u-boot/u-boot -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] "splash: fix splash banner output" and newer llvm-7
Hey,
With a patch to fix Travis-CI so that it actually uses LLVM-7 to build,
I see I've let in a problem (the LLVM-7 I use locally is older and
didn't catch it) with:
commit d2a8271c88514f30c2fe00d2584401348f39c3d4
Author: Anatolij Gustschin
Date: Fri Sep 20 17:23:41 2019 +0200
splash: fix splash banner output
Old splash code in cfb_console driver displayed U-Boot version
string by default. Restore this behaviour for DM_VIDEO enabled
configurations.
Signed-off-by: Anatolij Gustschin
Reported-by: Fabio Estevam
which from https://travis-ci.org/trini/u-boot/jobs/604644412
is:
+common/splash.c:148:20: error: unused function 'splash_display_banner'
[-Werror,-Wunused-function]
+static inline void splash_display_banner(void) { }
+ ^
+1 error generated.
+make[2]: *** [common/splash.o] Error 1
+make[1]: *** [common] Error 2
+make: *** [sub-make] Error 2
Can you please take a look? Thanks!
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/9] mpc85xx, socrates: add DM support
Hello Priyanka Jain,
Am 28.10.2019 um 06:49 schrieb Heiko Schocher:
Am 28.10.2019 um 06:02 schrieb Heiko Schocher:
Hello Priyanka Jain,
Am 23.10.2019 um 13:18 schrieb Priyanka Jain:
-Original Message-
From: U-Boot On Behalf Of Heiko Schocher
Sent: Wednesday, October 16, 2019 9:26 AM
To: U-Boot Mailing List
Subject: [U-Boot] [PATCH v2 4/9] mpc85xx, socrates: add DM support
enable CONFIG_DM for the socrates board.
Signed-off-by: Heiko Schocher
---
Changes in v2: None
board/socrates/socrates.c | 15 +++ configs/socrates_defconfig
| 6 +- include/configs/socrates.h | 13 +++--
3 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/board/socrates/socrates.c b/board/socrates/socrates.c index
da9ae5bebb..8f9583360b 100644
--- a/board/socrates/socrates.c
+++ b/board/socrates/socrates.c
@@ -432,3 +432,18 @@ void video_get_info_str (int line_number, char *info)
}
}
#endif
+
+#if defined(CONFIG_OF_SEPARATE)
+void *board_fdt_blob_setup(void)
+{
+ void *fw_dtb;
+
+ fw_dtb = (void *)(CONFIG_SYS_TEXT_BASE - CONFIG_ENV_SECT_SIZE);
+ if (fdt_magic(fw_dtb) != FDT_MAGIC) {
+ printf("DTB is not passed via %x\n", (u32)fw_dtb);
+ return NULL;
+ }
+
+ return fw_dtb;
+}
+#endif
diff --git a/configs/socrates_defconfig b/configs/socrates_defconfig index
58d135b907..1730d5793b 100644
--- a/configs/socrates_defconfig
+++ b/configs/socrates_defconfig
@@ -3,6 +3,7 @@ CONFIG_SYS_TEXT_BASE=0xfff8 CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set CONFIG_TARGET_SOCRATES=y
+# CONFIG_SYS_MALLOC_F is not set
CONFIG_FIT=y
CONFIG_FIT_VERBOSE=y
CONFIG_OF_BOARD_SETUP=y
@@ -15,6 +16,7 @@ CONFIG_BOARD_EARLY_INIT_R=y
CONFIG_HUSH_PARSER=y CONFIG_CMD_REGINFO=y CONFIG_CMD_IMLS=y
+CONFIG_CMD_DM=y
CONFIG_CMD_I2C=y
CONFIG_CMD_NAND=y
CONFIG_CMD_PCI=y
@@ -31,7 +33,10 @@ CONFIG_CMD_DATE=y
# CONFIG_CMD_HASH is not set
CONFIG_CMD_EXT2=y
# CONFIG_CMD_IRQ is not set
+CONFIG_OF_CONTROL=y
+CONFIG_DEFAULT_DEVICE_TREE="socrates"
CONFIG_ENV_IS_IN_FLASH=y
+CONFIG_DM=y
# CONFIG_MMC is not set
CONFIG_MTD_NOR_FLASH=y
CONFIG_FLASH_CFI_DRIVER=y
@@ -46,4 +51,3 @@ CONFIG_USB=y
CONFIG_USB_STORAGE=y
CONFIG_VIDEO=y
CONFIG_CONSOLE_EXTRA_INFO=y
-CONFIG_OF_LIBFDT=y
diff --git a/include/configs/socrates.h b/include/configs/socrates.h index
4192148b52..4e10786ed8 100644
--- a/include/configs/socrates.h
+++ b/include/configs/socrates.h
@@ -238,9 +238,10 @@
* Environment
*/
#define CONFIG_ENV_SECT_SIZE 0x2 /* 128K(one sector) for env
*/
-#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE -
CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - \
+ CONFIG_ENV_SECT_SIZE -
CONFIG_ENV_SECT_SIZE)
#define CONFIG_ENV_SIZE 0x4000
-#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR-
CONFIG_ENV_SECT_SIZE)
+#define CONFIG_ENV_ADDR_REDUND (CONFIG_ENV_ADDR -
CONFIG_ENV_SECT_SIZE)
#define CONFIG_ENV_SIZE_REDUND (CONFIG_ENV_SIZE)
#define CONFIG_LOADS_ECHO 1 /* echo on for serial download */
@@ -280,7 +281,7 @@
"bootfile=/home/tftp/syscon3/uImage\0"
\
"fdt_file=/home/tftp/syscon3/socrates.dtb\0" \
"initrd_file=/home/tftp/syscon3/uinitrd.gz\0" \
- "uboot_addr=FFFA\0"
\
+ "uboot_addr=FFF6\0"
\
"kernel_addr=FE00\0" \
"fdt_addr=FE1E\0" \
"ramdisk_addr=FE20\0" \
@@ -303,9 +304,9 @@
"run nfsargs addip addcons;" \
"bootm ${kernel_addr_r} - ${fdt_addr_r}\0" \
"update_uboot=tftp 10 ${uboot_file};" \
- "protect off fffa ;" \
- "era fffa ;" \
- "cp.b 10 fffa ${filesize};" \
+ "protect off fff6 ;" \
+ "era fff6 ;" \
+ "cp.b 10 fff6 ${filesize};" \
"setenv filesize;saveenv\0" \
"update_kernel=tftp 10 ${bootfile};" \
"era fe00 fe1d;" \
--
2.21.0
__
Travis build error. Please check
https://travis-ci.org/p-priyanka-jain/u-boot-fsl-qoriq/jobs/601663817
I could not open this webpage, I get in my brwoser the error:
We couldn't find the repository
p-priyanka-jain/u-boot-fsl-qoriq
+This board does use CONFIG_LIBATA but has CONFIG_AHCI not
1481
+enabled. Please update the storage controller driver to use
1482
+CONFIG_AHCI before the v2019.07 release.
1483
+Error: arch/powerpc/dts/.socrates.dtb.pre.tmp:235.9-21 syntax error
1484
+FATAL ERROR: Unable to parse input tree
1485
+make[3]: *** [arch/powerpc/dts/socrates.dtb] Error 1
1486
+make[2]: *** [arch-dtbs] Error 2
1487
+make[1]: *** [dts/dt.dtb] Error 2
1488
+make: *** [sub-make] Error 2
1489
--priyankajain
Hmm, I did a travis buld before posting, see:
https://travis-ci.org/hsdenx/u-boot-test/builds/597488733
Based on which tree,
Re: [U-Boot] required host packages on Travis CI
On Wed, Oct 30, 2019 at 03:30:58PM +0900, AKASHI Takahiro wrote: > Hi Tom, > > In test/py/README.md, all the required host packages and their > versions to be used on 14.04(Trusty) are listed. On the other hand, > ".travis.yml" names a similar but different list of packages. > The latter also specifies the distribution to be used, which is > xenial(16.04). > > * How would like to sync those two different lists? > * Do you still think it appropriate to mention the "tested versions" > in README.md at all? The README is woefully out of date and I addressed that as part of: http://patchwork.ozlabs.org/project/uboot/list/?series=138421 Please note that moving forward, the GitLab and Azure CI files need to be kept up to date as well, but with at least one of them being updated I can help with the other two. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] riscv: andes_plic: Fix some wrong configurations
Hi Rick,
On Wed, Oct 30, 2019 at 10:50 AM Rick Chen wrote:
>
> Hi Bin
>
> >
> > Hi Rick,
> >
> > On Fri, Oct 25, 2019 at 2:18 PM Andes wrote:
> > >
> > > From: Rick Chen
> > >
> > > It will work fine due to hart 0 always will be main
> > > hart coincidentally. When develop SPL flow, I try to
> > > force other harts to be main hart. And it will go
> > > wrong in sending IPI flow. So fix it.
> >
> > Fix what? Does this commit contain 2 fixes, or just 1 fix?
>
> Yes, it include two fixs. But they will cause one negative result
> that only hart 0 can send ipi to other harts.
>
> >
> > >
> > > Having this fix, any hart can be main hart in U-Boot SPL
> > > theoretically, but it still fail somewhere. After dig in
> > > and found there is an assumption that hart 0 shall be
> > > main hart in OpenSbi.
> >
> > So does this mean there is a bug in OpenSBI too?
>
> I am not sure if it is a bug. Maybe it is a compatible issue.
> There is a limitation that only hart 0 can be main hart in OpenSBI.
I don't think OpenSBI has such limitation.
> But any hart can be main hart in U-Boot.
>
> In general case, hart 0 will be main and it is fine when U-Boot jump ot
> OpenSBI.
> But if we force hart 1 to be main hart, when hart 0 jump to OPenSBI from
> U-Boot,
> It will do relocation flow in OpenSBI which willcorrupt U-Boot SPL,
> but hart 0 still in U-Boot SPL.
>
> >
> > >
> > > After some work-arounds, it can pass the verifications
> > > that any hart can be main hart and boots U-Boot SPL ->
> > > OpenSbi -> U-Boot proper -> Linux Kernel successfully.
> > >
> >
> > It's a bit hard for me to understand what was described here in the
> > commit message. Maybe you need rewrite something.
>
> OK. I will rewrite this commit message.
>
> >
> > > Signed-off-by: Rick Chen
> > > Cc: KC Lin
> > > Cc: Alan Kao
> > > ---
> > > arch/riscv/lib/andes_plic.c | 11 +++
> > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/arch/riscv/lib/andes_plic.c b/arch/riscv/lib/andes_plic.c
> > > index 28568e4..42394b9 100644
> > > --- a/arch/riscv/lib/andes_plic.c
> > > +++ b/arch/riscv/lib/andes_plic.c
> > > @@ -19,7 +19,7 @@
> > > #include
> > >
> > > /* pending register */
> > > -#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 + (hart)
> > > * 8)
> > > +#define PENDING_REG(base, hart)((ulong)(base) + 0x1000 + ((hart)
> > > / 4) * 4)
> > > /* enable register */
> > > #define ENABLE_REG(base, hart) ((ulong)(base) + 0x2000 + (hart) * 0x80)
> > > /* claim register */
> > > @@ -46,7 +46,7 @@ static int init_plic(void);
> > >
> > > static int enable_ipi(int hart)
> > > {
> > > - int en;
> > > + unsigned int en;
> >
> > Is this for some compiler warning fix?
>
> No, it is not a warning fix. It is a bug fix.
> I hope en can be 0x80808080 instead of 0x80808080,
But it is int, which is only 32-bit. The example you gave was a 64-bit number.
> or it will cause IPI sending errors.
>
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] gpio: search for gpio label if gpio is not found through bank name
dm_gpio_lookup_name() searches for a gpio through
the bank name. But we have also gpio labels, and it
makes sense to search for a gpio also in the labels
we have defined, if no gpio is found through the
bank name definition.
This is useful for example if you have a wp pin on
different gpios on different board versions.
If dm_gpio_lookup_name() searches also for the gpio labels,
you can give the gpio an unique label name and search
for this label, and do not need to differ between
board revisions.
Signed-off-by: Heiko Schocher
---
Example on the aristainetos board:
=> gpio clear wp_spi_nor.gpio-hog
gpio: pin wp_spi_nor.gpio-hog (gpio 47) value is 0
=>
before this patch, you need to know where your
pin is:
=> gpio clear GPIO2_15
gpio: pin GPIO2_15 (gpio 47) value is 0
=>
travis build:
https://travis-ci.org/hsdenx/u-boot-test/builds/604290746
drivers/gpio/gpio-uclass.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 90fbed455b..755744bc00 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -79,6 +79,26 @@ int dm_gpio_lookup_name(const char *name, struct gpio_desc
*desc)
if (!strncasecmp(name, uc_priv->bank_name, len)) {
if (!strict_strtoul(name + len, 10, ))
break;
+ } else {
+ /*
+* if we did not found a gpio through its bank
+* name, we search for a valid gpio label.
+*/
+ bool found = 0;
+
+ len = strlen(name);
+ for (offset = 0; offset < uc_priv->gpio_count;
+offset++) {
+ if (!uc_priv->name[offset])
+ continue;
+ if (!strncmp(name, uc_priv->name[offset],
+len)) {
+ found = 1;
+ break;
+ }
+ }
+ if (found)
+ break;
}
}
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: caches: Disable mmu only if mmu is available
As part of disabling caches MMU as well gets disabled. But MMU is not available on all armv7 cores like R5F. So disable MMU only if it is available. Signed-off-by: Lokesh Vutla --- arch/arm/lib/cache-cp15.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c index b2913e8165..47c223917a 100644 --- a/arch/arm/lib/cache-cp15.c +++ b/arch/arm/lib/cache-cp15.c @@ -235,12 +235,18 @@ static void cache_disable(uint32_t cache_bit) /* if cache isn;t enabled no need to disable */ if ((reg & CR_C) != CR_C) return; +#ifdef CONFIG_SYS_ARM_MMU /* if disabling data cache, disable mmu too */ cache_bit |= CR_M; +#endif } reg = get_cr(); +#ifdef CONFIG_SYS_ARM_MMU if (cache_bit == (CR_C | CR_M)) +#elif defined(CONFIG_SYS_ARM_MPU) + if (cache_bit == CR_C) +#endif flush_dcache_all(); set_cr(reg & ~cache_bit); } -- 2.23.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
