Re: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings
On Fri, Mar 15, 2019 at 06:39:23PM +0100, Marek Vasut wrote:
> On 3/14/19 2:01 AM, Tom Rini wrote:
> > On Thu, Mar 14, 2019 at 01:20:09AM +0100, Marek Vasut wrote:
> >> On 3/13/19 8:42 PM, Tom Rini wrote:
> >>> On Wed, Mar 13, 2019 at 07:23:15PM +0100, Marek Vasut wrote:
> On 3/13/19 5:01 PM, Tom Rini wrote:
> > On Wed, Mar 13, 2019 at 12:30:59PM +0100, Marek Vasut wrote:
> >> On 3/13/19 12:29 PM, Tom Rini wrote:
> >>> On Wed, Mar 13, 2019 at 12:27:38PM +0100, Marek Vasut wrote:
> On 3/13/19 12:25 PM, Tom Rini wrote:
> > On Wed, Mar 13, 2019 at 12:20:49PM +0100, Marek Vasut wrote:
> >> On 3/13/19 12:19 PM, Tom Rini wrote:
> >>> On Wed, Mar 13, 2019 at 05:08:14AM +0100, Marek Vasut wrote:
> >>>
> Fix the following spit from pytest:
>
> u-boot/test/py/conftest.py:438: RemovedInPytest4Warning:
> MarkInfo objects are deprecated as they contain merged marks
> which are hard to deal with correctly.
> Please use node.get_closest_marker(name) or
> node.iter_markers(name).
> Docs: https://docs.pytest.org/en/latest/mark.html#updating-code
> for board in mark.args:
>
> In both cases, the later suggestion is applicable.
>
> Signed-off-by: Marek Vasut
> Cc: Igor Opaniuk
> Cc: Tom Rini
> Cc: Simon Glass
> >>>
> >>> Deferred, for now we don't support newer pytest than 2.8.7 and
> >>> you'll
> >>> need to use virtualenv to set that up if needed. There is not,
> >>> AFAICT,
> >>> a way to support both versions.
> >>
> >> That's what's in debian testing though, so maybe we need to
> >> support it
> >> somehow.
> >
> > Yes, I'm _very_ frustrated at the speed at which pytest went from
> > "this
> > is the API" to "this API is deprecated" to "this API doesn't work
> > and
> > here's the new, incompatible API". Debian/testing needs to use
> > virtualenv to setup a python area with older pytest installed, just
> > like
> > we do in .travis.yml.
>
> Can't we rather have people use the new APIs and virtualenv new
> python?
> >>>
> >>> Not as easily, no. Debian/testing may have something much newer but
> >>> Debian/stable doesn't, and I don't know what Ubuntu/18.04 has off-hand
> >>> but it's probably inbetween and so on.
> >>
> >> While I'm not a python expert, shouldn't virtualenv help with that ?
> >
> > Yes, and breaking old setups is usually frowned upon and making new
> > setups conform to the existing ways is how things are usually done.
>
> If you use venv with old setup, won't that give you the new python you
> need ?
> >>>
> >>> No, you don't need to. Travis is special in that it's based on Ubuntu
> >>> 14.04 () and so we needed to use pip there to setup anything, and
> >>> have for forever. That in turn lead to us hitting this problem a while
> >>> back, when "pip install pytest" first gave us something where the old
> >>> behavior became a fatal error. That leads to installing the last
> >>> version before pytest starts to complain about changing APIs. Normally
> >>> old distributions however ship with 2.8.7 anyways and don't need
> >>> virtaulenv.
> >>
> >> I don't think I get your point here. Sure, old distros might need to
> >> change and start using virtualenv because the software is just too old.
> >> We cannot support all kinds of old stuff. If the API we're using is
> >> getting deprecated, let's just switch to the new one and ask the users
> >> of old software to upgrade (?).
> >
> > My point is that "pin to a newer pytest version" is not something I want
> > right now. It will break existing setups and provide nothing in return.
>
> Besides, using latest code instead of old stuff, as we should ?
We should? What's the reason we need to upgrade? What problem we have
is being fixed?
> If your existing setup breaks, maybe you should update your existing setup.
No, we don't break existing setups.
> > There's not some new feature of pytest we're missing out on. My take
> > away from all of this is that we need to move the whole thing into being
> > wrapped up, for everyone, as we cannot expect random community python
> > modules to remove an API in an extremely quick fashion. If you're
> > motivated enough over this to go off and do that, yes, sure. But I will
> > not take a patch this patch as-is, as it breaks travis-ci.
>
> Cool, and without this patch, all the tests fail on debian testing.
Everyone else is using virtualenv.
> So maybe travis needs an update ?
Please go ${search_engine} the problem. TL;DR, sure, just as soon as
that's possible!
> > I will not
> > take a v2 of
Re: [U-Boot] [PATCH] usb: host: Print device name when scanning
On 3/15/19 8:50 PM, Ismael Luceno Cortes wrote:
> On 15/Mar/2019 18:34, Marek Vasut wrote:
>> On 3/14/19 5:19 PM, Ismael Luceno Cortes wrote:
>>> On 14/Mar/2019 16:09, Marek Vasut wrote:
On 3/14/19 1:57 PM, Ismael Luceno Cortes wrote:
> On 14/Mar/2019 12:55, Marek Vasut wrote:
>> On 3/14/19 12:44 PM, Ismael Luceno Cortes wrote:
>>> On 18/Feb/2019 09:23, Ismael Luceno Cortes wrote:
Signed-off-by: Ismael Luceno
---
drivers/usb/host/usb-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/usb-uclass.c
b/drivers/usb/host/usb-uclass.c
index 611ea97a72..0575f5393b 100644
--- a/drivers/usb/host/usb-uclass.c
+++ b/drivers/usb/host/usb-uclass.c
@@ -255,7 +255,7 @@ int usb_init(void)
uclass_foreach_dev(bus, uc) {
/* init low_level USB */
- printf("USB%d: ", count);
+ printf("USB%d(%s): ", count, bus->name);
count++;
#ifdef CONFIG_SANDBOX
--
2.19.1
>>>
>>> Ping.
>>
>> What is this patch doing ? The commit description doesn't explain
>> anything about it.
>
> It prints the host device name. I'm not sure the count is at all useful
> given there's a name...
If you could share the log before and after to better illustrate the
difference, that'd be nice.
>>>
>>> unpatched:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0: USB EHCI 1.10
>>> scanning bus 0 for devices... 2 USB Device(s) found
>>>scanning usb for storage devices... 1 Storage Device(s) found
>>>
>>> patched:
>>>
>>> => usb reset
>>> resetting USB...
>>> USB0(usb@ee080100): USB EHCI 1.10
>>> scanning bus 0 for devices... 2 USB Device(s) found
>>>scanning usb for storage devices... 1 Storage Device(s) found
>>>
However, shouldn't the same approach be applied to 'usb tree' subcommand
and possibly others ?
>>>
>>> The number shown during usb scanning is not used nor saved anywhere
>>> else, so seems pretty useless and a special case.
>>
>> What about usb part ? That one uses the number somehow I think ?
>
> Not this number.
Lovely.
Anyway, this looks good, can you repost this patch with proper commit
message, ideally with the example output above so I can pick it for next ?
>>> OTOH the number used in the usb tree command is taken from struct
>>> usb_device, and is used for lookups.
>>
>> Maybe it's time to clean that numbering mess up a bit , and make it
>> consistent ?
>
> Maybe implement it like a vfs? It would force some consistency into the
> drivers and commands.
Do you want to take that one up ? :)
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable
On 3/15/19 8:44 PM, Simon Goldschmidt wrote: > To boot from fpga on socfpga gen5, we need to set CONFIG_SPL_TEXT_BASE to > 0xC000 (hps2fpgaslaves base address). > > Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been successful so > far, let's make this value overridable in socfpga_common.h, so that we can > have different board configs override this in socfpga_common.h. > > Signed-off-by: Simon Goldschmidt Is this a fix for current release or new feature for next ? > --- > > include/configs/socfpga_common.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/include/configs/socfpga_common.h > b/include/configs/socfpga_common.h > index 181af9b646..191204b27b 100644 > --- a/include/configs/socfpga_common.h > +++ b/include/configs/socfpga_common.h > @@ -248,8 +248,10 @@ unsigned int cm_get_qspi_controller_clk_hz(void); > * 0xFFEz_ .. Malloc area (grows up to top) > * 0xFFE3_ .. End of SRAM (top) > */ > +#ifndef CONFIG_SPL_TEXT_BASE > #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR > #define CONFIG_SPL_MAX_SIZE CONFIG_SYS_INIT_RAM_SIZE > +#endif > > #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) > /* SPL memory allocation configuration, this is for FAT implementation */ > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] test/py: Fix pytest4 deprecation warnings
On 3/14/19 2:01 AM, Tom Rini wrote: > On Thu, Mar 14, 2019 at 01:20:09AM +0100, Marek Vasut wrote: >> On 3/13/19 8:42 PM, Tom Rini wrote: >>> On Wed, Mar 13, 2019 at 07:23:15PM +0100, Marek Vasut wrote: On 3/13/19 5:01 PM, Tom Rini wrote: > On Wed, Mar 13, 2019 at 12:30:59PM +0100, Marek Vasut wrote: >> On 3/13/19 12:29 PM, Tom Rini wrote: >>> On Wed, Mar 13, 2019 at 12:27:38PM +0100, Marek Vasut wrote: On 3/13/19 12:25 PM, Tom Rini wrote: > On Wed, Mar 13, 2019 at 12:20:49PM +0100, Marek Vasut wrote: >> On 3/13/19 12:19 PM, Tom Rini wrote: >>> On Wed, Mar 13, 2019 at 05:08:14AM +0100, Marek Vasut wrote: >>> Fix the following spit from pytest: u-boot/test/py/conftest.py:438: RemovedInPytest4Warning: MarkInfo objects are deprecated as they contain merged marks which are hard to deal with correctly. Please use node.get_closest_marker(name) or node.iter_markers(name). Docs: https://docs.pytest.org/en/latest/mark.html#updating-code for board in mark.args: In both cases, the later suggestion is applicable. Signed-off-by: Marek Vasut Cc: Igor Opaniuk Cc: Tom Rini Cc: Simon Glass >>> >>> Deferred, for now we don't support newer pytest than 2.8.7 and >>> you'll >>> need to use virtualenv to set that up if needed. There is not, >>> AFAICT, >>> a way to support both versions. >> >> That's what's in debian testing though, so maybe we need to support >> it >> somehow. > > Yes, I'm _very_ frustrated at the speed at which pytest went from > "this > is the API" to "this API is deprecated" to "this API doesn't work and > here's the new, incompatible API". Debian/testing needs to use > virtualenv to setup a python area with older pytest installed, just > like > we do in .travis.yml. Can't we rather have people use the new APIs and virtualenv new python? >>> >>> Not as easily, no. Debian/testing may have something much newer but >>> Debian/stable doesn't, and I don't know what Ubuntu/18.04 has off-hand >>> but it's probably inbetween and so on. >> >> While I'm not a python expert, shouldn't virtualenv help with that ? > > Yes, and breaking old setups is usually frowned upon and making new > setups conform to the existing ways is how things are usually done. If you use venv with old setup, won't that give you the new python you need ? >>> >>> No, you don't need to. Travis is special in that it's based on Ubuntu >>> 14.04 () and so we needed to use pip there to setup anything, and >>> have for forever. That in turn lead to us hitting this problem a while >>> back, when "pip install pytest" first gave us something where the old >>> behavior became a fatal error. That leads to installing the last >>> version before pytest starts to complain about changing APIs. Normally >>> old distributions however ship with 2.8.7 anyways and don't need >>> virtaulenv. >> >> I don't think I get your point here. Sure, old distros might need to >> change and start using virtualenv because the software is just too old. >> We cannot support all kinds of old stuff. If the API we're using is >> getting deprecated, let's just switch to the new one and ask the users >> of old software to upgrade (?). > > My point is that "pin to a newer pytest version" is not something I want > right now. It will break existing setups and provide nothing in return. Besides, using latest code instead of old stuff, as we should ? If your existing setup breaks, maybe you should update your existing setup. > There's not some new feature of pytest we're missing out on. My take > away from all of this is that we need to move the whole thing into being > wrapped up, for everyone, as we cannot expect random community python > modules to remove an API in an extremely quick fashion. If you're > motivated enough over this to go off and do that, yes, sure. But I will > not take a patch this patch as-is, as it breaks travis-ci. Cool, and without this patch, all the tests fail on debian testing. So maybe travis needs an update ? > I will not > take a v2 of this patch that is the above plus pinning to a new pytest > as that's just going to push the problem from "Debian/Buster and others > people need to continue to setup virtualenv" to "Ubuntu 16.04 and other > people now need to setup virtualenv". That's just pushing the problem > around and not making anything better. I think everyone should just setup virtualenv if their setup is too old? >>> So no, I'm not going to change the setup that's working for existing >>> installs today. Frankly, the whole thing has me
[U-Boot] [U-Boot, V5, PATCH 3/3] ag7xxx: add initial support for s17
From: Rosy Song
S17 ethernet support is for QCA8337N, which used on
AP152 (QCA9563) board. It is a 7 ports GbE switch.
Signed-off-by: Rosy Song
Changes for v2-v3:
- add more commit message for s17
Changes for v4-v5:
- coding style cleanup
---
drivers/net/ag7xxx.c | 139 ++-
1 file changed, 123 insertions(+), 16 deletions(-)
diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
index 403eb64895..7f1dee4b3e 100644
--- a/drivers/net/ag7xxx.c
+++ b/drivers/net/ag7xxx.c
@@ -3,6 +3,7 @@
* Atheros AR71xx / AR9xxx GMAC driver
*
* Copyright (C) 2016 Marek Vasut
+ * Copyright (C) 2019 Rosy Song
*/
#include
@@ -23,7 +24,8 @@ DECLARE_GLOBAL_DATA_PTR;
enum ag7xxx_model {
AG7XXX_MODEL_AG933X,
AG7XXX_MODEL_AG934X,
- AG7XXX_MODEL_AG953X
+ AG7XXX_MODEL_AG953X,
+ AG7XXX_MODEL_AG956X
};
/* MAC Configuration 1 */
@@ -219,6 +221,7 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int
reg, u32 *val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+ u32 reg_temp_w = (reg & 0xfffc) >> 1;
u16 rv = 0;
int ret;
@@ -226,18 +229,25 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus,
int reg, u32 *val)
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
- } else if (priv->model == AG7XXX_MODEL_AG934X) {
+ } else if (priv->model == AG7XXX_MODEL_AG934X ||
+ priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
- ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+ if (priv->model == AG7XXX_MODEL_AG956X)
+ ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) &
0x1ff);
+ else
+ ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
phy_temp = ((reg >> 6) & 0x7) | 0x10;
- reg_temp = (reg >> 1) & 0x1e;
+ if (priv->model == AG7XXX_MODEL_AG956X)
+ reg_temp = reg_temp_w & 0x1f;
+ else
+ reg_temp = (reg >> 1) & 0x1e;
*val = 0;
ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 0, );
@@ -245,7 +255,13 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int
reg, u32 *val)
return ret;
*val |= rv;
- ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+ if (priv->model == AG7XXX_MODEL_AG956X) {
+ phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+ reg_temp = (reg_temp_w + 1) & 0x1f;
+ ret = ag7xxx_switch_read(bus, phy_temp, reg_temp, );
+ } else {
+ ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+ }
if (ret < 0)
return ret;
*val |= (rv << 16);
@@ -260,24 +276,34 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus,
int reg, u32 val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+ u32 reg_temp_w = (reg & 0xfffc) >> 1;
int ret;
if (priv->model == AG7XXX_MODEL_AG933X ||
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
- } else if (priv->model == AG7XXX_MODEL_AG934X) {
+ } else if (priv->model == AG7XXX_MODEL_AG934X ||
+ priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
- ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+ if (priv->model == AG7XXX_MODEL_AG956X)
+ ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) &
0x1ff);
+ else
+ ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
- phy_temp = ((reg >> 6) & 0x7) | 0x10;
- reg_temp = (reg >> 1) & 0x1e;
+ if (priv->model == AG7XXX_MODEL_AG956X) {
+ reg_temp = (reg_temp_w + 1) & 0x1f;
+ phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+ } else {
+ phy_temp = ((reg >> 6) & 0x7) | 0x10;
+ reg_temp = (reg >> 1) & 0x1e;
+ }
/*
* The switch on AR933x has some special register behavior, which
@@ -296,10 +322,18 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus,
int reg, u32 val)
if (ret < 0)
return ret;
} else {
- ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, val >>
16);
+ if (priv->model == AG7XXX_MODEL_AG956X)
+ ret = ag7xxx_switch_write(bus, phy_temp, reg_temp, val
>> 16);
+ else
+ ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1,
val >> 16);
if (ret <
[U-Boot] [U-Boot, V5, PATCH 2/3] mips: add initial support for qca956x referenced board
From: Rosy Song
QCA9563 is CPU used on AP152 board :
Clock speed : 750 MHz ,
Arch : Mips 74Kc,
Eth : SGMII interface,
MIMO config : 3 * 3 450M,
2 * USB 2.0,
Signed-off-by: Rosy Song
Changes for v2:
- coding style cleanup
- remove ununsed flash chip in defconfig
- enable automatic icache / dcache size in defconfig
Changes for v3:
- add detailed information for qca956x in commit message
Changes for v4:
- remove pre-configured network settings in ap152.h
Changes for v5:
- coding style cleanup
---
arch/mips/dts/Makefile| 1 +
arch/mips/dts/ap152.dts | 48 ++
arch/mips/dts/qca956x.dtsi| 87
arch/mips/mach-ath79/Kconfig | 14 +
arch/mips/mach-ath79/Makefile | 1 +
.../mach-ath79/include/mach/ar71xx_regs.h | 73 +++
arch/mips/mach-ath79/include/mach/ath79.h | 3 +
arch/mips/mach-ath79/qca956x/Makefile | 5 +
arch/mips/mach-ath79/qca956x/clk.c| 419 ++
arch/mips/mach-ath79/qca956x/cpu.c| 9 +
arch/mips/mach-ath79/qca956x/ddr.c| 308 +
.../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 193
arch/mips/mach-ath79/reset.c | 271 +++
board/qca/ap152/Kconfig | 15 +
board/qca/ap152/MAINTAINERS | 6 +
board/qca/ap152/Makefile | 3 +
board/qca/ap152/ap152.c | 81
configs/ap152_defconfig | 49 ++
include/configs/ap152.h | 50 +++
19 files changed, 1636 insertions(+)
create mode 100644 arch/mips/dts/ap152.dts
create mode 100644 arch/mips/dts/qca956x.dtsi
create mode 100644 arch/mips/mach-ath79/qca956x/Makefile
create mode 100644 arch/mips/mach-ath79/qca956x/clk.c
create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c
create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c
create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S
create mode 100644 board/qca/ap152/Kconfig
create mode 100644 board/qca/ap152/MAINTAINERS
create mode 100644 board/qca/ap152/Makefile
create mode 100644 board/qca/ap152/ap152.c
create mode 100644 configs/ap152_defconfig
create mode 100644 include/configs/ap152.h
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index b94b582837..621c35f0ef 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -2,6 +2,7 @@
dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
+dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
diff --git a/arch/mips/dts/ap152.dts b/arch/mips/dts/ap152.dts
new file mode 100644
index 00..1722290c73
--- /dev/null
+++ b/arch/mips/dts/ap152.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song
+ */
+
+/dts-v1/;
+#include "qca956x.dtsi"
+
+/ {
+ model = "AP152 Reference Board";
+ compatible = "qca,ap152", "qca,qca956x";
+
+ aliases {
+ spi0 =
+ serial0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+};
+
+ {
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ clock-frequency = <2500>;
+ status = "okay";
+};
+
+ {
+ spi-max-frequency = <2500>;
+ status = "okay";
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-flash";
+ memory-map = <0x9f00 0x0100>;
+ spi-max-frequency = <2500>;
+ reg = <0>;
+ };
+};
diff --git a/arch/mips/dts/qca956x.dtsi b/arch/mips/dts/qca956x.dtsi
new file mode 100644
index 00..6cb360b3f8
--- /dev/null
+++ b/arch/mips/dts/qca956x.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+ compatible = "qca,qca956x";
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "mips,mips74Kc";
+ reg = <0>;
+ };
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ xtal: xtal {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-output-names = "xtal";
+ };
+ };
+
+ ahb {
+ compatible = "simple-bus";
+ ranges;
+
+ #address-cells = <1>;
+
[U-Boot] [U-Boot, V5, PATCH 1/3] mips: fix erros on registers macros of pll-ddr-config1-nfrac for QCA956X
From: Rosy Song See details in chapter 8.6.2 and 8.6.4 (page 140-141) of qca9563 datasheet, NFRAC[17:0] So the mask of [17:5] is 0x1fff not 0x3fff. Signed-off-by: Rosy Song Changes for v2-v3: - add more information for this commit Changes for v4-v5: - coding style cleanup --- arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h index 5d371bb582..3506ed1da4 100644 --- a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h +++ b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h @@ -528,7 +528,7 @@ #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_SHIFT 0 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_MASK 0x1f #define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_SHIFT 5 -#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK 0x3fff +#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK 0x1fff #define QCA956X_PLL_CPU_CONFIG1_NINT_SHIFT 18 #define QCA956X_PLL_CPU_CONFIG1_NINT_MASK 0x1ff @@ -540,7 +540,7 @@ #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_SHIFT 0 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_MASK 0x1f #define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_SHIFT 5 -#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK 0x3fff +#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK 0x1fff #define QCA956X_PLL_DDR_CONFIG1_NINT_SHIFT 18 #define QCA956X_PLL_DDR_CONFIG1_NINT_MASK 0x1ff -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC/RESEND 01/22] arm: introduce ARCH_THUNDERX
Tim Harvey - Principal Software EngineerGateworks Corporation - http://www.gateworks.com/3026 S. Higuera St. San Luis Obispo CA 93401805-781-2000 On Mon, Mar 4, 2019 at 12:07 PM Tim Harvey wrote: > > On Mon, Mar 4, 2019 at 11:05 AM Chandrakala Chavva > wrote: > > > > We will be submitting OcteonTX/OcteonTX2 support soon to mainline, these > > are very old changes, please wait till then. > > > > > > Chandra > > Chandra, > > Thanks for the reply. Can you elaborate on what 'soon' might be... > weeks or months? > Chandra, Any response with regards to what 'soon' means? We have SUSE users wanting to the UEFI support/fixes in modern U-Boot and the U-Boot from your latest SDK is based on U-Boot 2017.07. Tim ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] UCLASS_MISC bug
I would like to point that this was not a very good idea:
=== Cut ===
--- uboot-imx-next/drivers/misc/misc-uclass.c 2018-12-20 20:35:22.505180339
-0800
+++ u-boot-imx/drivers/misc/misc-uclass.c 2019-03-13 11:50:19.408982814
-0700
@@ -68,4 +68,7 @@ int misc_set_enabled(struct udevice *dev
UCLASS_DRIVER(misc) = {
.id = UCLASS_MISC,
.name = "misc",
+#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
+ .post_bind = dm_scan_fdt_dev,
+#endif
};
=== Cut ===
The problem comes up with all those "glue" layers like e.g. in usb/dwc3 and
everywhere else.
Those "glues" primarily bind drivers to e.g. USB interfaces like e.g.
dwc3-generic does. That is where it should stop because glue knows better
what to bind. However, after glue has bound appropriate drivers to their
interfaces that post_bind scans FDT again and finds yet another bunch of
drivers that it binds on top of what glue already bound. This happens e.g.
with DWC3 drivers that glues bind to interfaces depending on their declared
roles. However both peripheral and XHCI drivers are compatible with
"snps,dwc3" so they are bound on top creating a huge mess. Here is a dm tree
fragment of its action:
=== Cut ===
phy 0 [ + ] imx8mq_usb_phy|-- phy@381f0040
misc 0 [ + ] imx8m_dwc3_glue |-- usb@3810
usb 0 [ ] imx8m_dwc3_periphera | |-- dwc3
usb 0 [ ] xhci-dwc3 | `-- dwc3
phy 1 [ ] imx8mq_usb_phy|-- phy@382f0040
misc 1 [ ] imx8m_dwc3_glue |-- usb@3820
usb 1 [ ] xhci-dwc3 | |-- dwc3
usb 2 [ ] xhci-dwc3 | `-- dwc3
=== Cut ===
The glue bound imx8m_dwc3_peripheral to USB0 then post_bind found yet
another "compatible" driver, xhci-dwc3 and bound it to the same interface.
Then glue bound xhci-dwc3 to USB1 but post_bind found yet another
"compatible" driver, xhci-dwc3 and bound it again so there are TWO xhci
drivers bound to the same interface.
This is simplified picture -- I removed "compatible" from my peripheral
driver so it only comes up once, under USB0. If I leave that "compatible"
with "snps,dwc3" there everything gets even weirder :(
That diff above is the latest 2019.04-rc3 u-boot-imx-next vs 2019.01-rc
something release.
We either need some additional special flag to disable that post_bind where
it is not needed or create a special new class for those binding "glues" or
this change should be reverted.
P.S. I'm going to post imx8m USB glue, USB PHY, USB peripheral initial
drivers probably Monday late night as they still need some cleanup. It all
works with full Linux Kernel DTS files, picks power domains from there.
Don't know what to do with my board-specific DTS as there is (and probably
will not be) our board submitted -- it is not secret but used in our devices
only and not available to the public -- so it doesn't make sense to post a
full DTS. Will probably send a fragment.
---
**
* KSI@homeKOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
**
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] arm: socfpga: imply/default common config options
Am 05.03.2019 um 21:58 schrieb Marek Vasut: On 3/5/19 9:28 PM, Simon Goldschmidt wrote: Am 04.03.2019 um 22:34 schrieb Marek Vasut: On 3/4/19 10:23 PM, Simon Goldschmidt wrote: Marek Vasut mailto:ma...@denx.de>> schrieb am Mo., 4. März 2019, 22:19: On 3/4/19 9:53 PM, Simon Goldschmidt wrote: > This commit moves common config options used in all socfpga boards > to select/imply in Kconfig. This both cleans up the defconfig files > as well as makes future changes easier. > > Options implied/defaulted for all sub-arches: > - SPL, SPL_DM, USE_TINY_PRINTF, NR_DRAM_BANKS > > Options implied/defaulted for implied for A10 & gen5: > - FPGA_SOCFPGA, SYS_MALLOC_F_LEN, SYS_TEXT_BASE > > Options implied/defaulted for A10: > - SPL_SYS_MALLOC_F_LEN > > Options implied/defaulted for gen5: > - SPL_STACK_R, SPL_SYS_MALLOC_SIMPLE, SPL_STACK_R_ADDR > > Signed-off-by: Simon Goldschmidt mailto:simon.k.r.goldschm...@gmail.com>> > --- > > Changes in v2: > - added patch to imply/default common config options > > arch/arm/Kconfig | 3 +++ > arch/arm/mach-socfpga/Kconfig | 21 + > configs/socfpga_arria10_defconfig | 8 > configs/socfpga_arria5_defconfig | 10 -- > configs/socfpga_cyclone5_defconfig | 10 -- > configs/socfpga_dbm_soc1_defconfig | 10 -- > configs/socfpga_de0_nano_soc_defconfig | 10 -- > configs/socfpga_de10_nano_defconfig | 10 -- > configs/socfpga_de1_soc_defconfig | 10 -- > configs/socfpga_is1_defconfig | 8 > configs/socfpga_sockit_defconfig | 10 -- > configs/socfpga_socrates_defconfig | 10 -- > configs/socfpga_sr1500_defconfig | 10 -- > configs/socfpga_stratix10_defconfig | 4 > configs/socfpga_vining_fpga_defconfig | 10 -- > 15 files changed, 24 insertions(+), 120 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index ded7c11a4c..71bb14acce 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -839,12 +839,15 @@ config ARCH_SOCFPGA > imply DM_SPI > imply DM_SPI_FLASH > imply FAT_WRITE > + imply SPL > + imply SPL_DM > imply SPL_LIBDISK_SUPPORT > imply SPL_MMC_SUPPORT > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION > imply SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION_TYPE > imply SPL_SPI_FLASH_SUPPORT > imply SPL_SPI_SUPPORT > + imply USE_TINY_PRINTF > > config ARCH_SUNXI > bool "Support sunxi (Allwinner) SoCs" > diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig > index 5e87371f8c..da801eb660 100644 > --- a/arch/arm/mach-socfpga/Kconfig > +++ b/arch/arm/mach-socfpga/Kconfig > @@ -1,8 +1,25 @@ > if ARCH_SOCFPGA > > +config NR_DRAM_BANKS > + default 1 > + > +config SPL_STACK_R_ADDR > + default 0x0080 if TARGET_SOCFPGA_GEN5 > + > +config SPL_SYS_MALLOC_F_LEN > + default 0x1 if TARGET_SOCFPGA_ARRIA10 > + This is already defined in /Kconfig, won't you end up with duplicate/redefined symbols this way ? I did not get errors. I copied the handling from SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION_TYPE in the same file. Plus it seems like it's done like this in other Kconfig files, too. I know it is done. I am not convinced it's right. Would it be better acceptable if I moved the defaults to the Kconfig files where these settings are defined? I always thought it to be strange to clutter those with arch-specific settings, but I don't really have a strong preference... I agree with you on this. I'd really like some reply from Yamada-san. So without a reply from Yamada-san for 10 days, how do we continue here? In the next version (v3), Patch 2/5 should be fixed for a10. I'd also extend that next version with further cleanup patches from an earlier series [1] since I have I2C EEPROM finally running with DM (tested on the socfpga_socrates board by using the "Phy1" daughter board and a matching FPGA configuration). [1] https://patchwork.ozlabs.org/project/uboot/list/?series=85229 Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] spl: support using full malloc with SYS_MALLOC_F_LEN
Some platforms (like socfpga A10) need a big hep before SDRAM is available (e.g. because FAT is used). For such platforms, simple_malloc is often not a good option as it does not support freeing memory. These platforms often use the non-Kconfig defines CONFIG_SYS_SPL_MALLOC_START (and its SIZE). This patch allows enabling CONFIG_SPL_SYS_MALLOC_F_LEN while leaving CONFIG_SPL_SYS_MALLOC_SIMPLE disabled. In this case, the full malloc heap is made available as early as the simple_malloc heap would be normally. This way, platforms can drop the non-Kconfig options to set up the full heap and rely on the same automatically calculated heap allocation used for simple heap. Signed-off-by: Simon Goldschmidt --- Changes in v2: None common/spl/spl.c | 5 + 1 file changed, 5 insertions(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index 88d4b8a9bf..b89340eb27 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -383,8 +383,13 @@ static int spl_common_init(bool setup_malloc) #ifdef CONFIG_MALLOC_F_ADDR gd->malloc_base = CONFIG_MALLOC_F_ADDR; #endif +#if CONFIG_IS_ENABLED(SYS_MALLOC_SIMPLE) gd->malloc_limit = CONFIG_VAL(SYS_MALLOC_F_LEN); gd->malloc_ptr = 0; +#else + mem_malloc_init(gd->malloc_base, CONFIG_VAL(SYS_MALLOC_F_LEN)); + gd->flags |= GD_FLG_FULL_MALLOC_INIT; +#endif } #endif ret = bootstage_init(true); -- 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] arm: socfpga: a10: move SPL stack size to Kconfig
Instead of fixing the SPL stack to 64 KiB in the board config header via CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN in the defconfig. This also has the advandage that it removes sub-mach specific ifdefs in socfpga_common.h. Signed-off-by: Simon Goldschmidt --- Changes in v2: None configs/socfpga_arria10_defconfig | 1 + include/configs/socfpga_common.h | 14 -- 2 files changed, 1 insertion(+), 14 deletions(-) diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index f321a0ac3b..8d0479cc05 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -2,6 +2,7 @@ CONFIG_ARM=y CONFIG_ARCH_SOCFPGA=y CONFIG_SYS_TEXT_BASE=0x0140 CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x1 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y CONFIG_SPL=y CONFIG_IDENT_STRING="socfpga_arria10" diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 181af9b646..16c83900c3 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -251,16 +251,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE -#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) -/* SPL memory allocation configuration, this is for FAT implementation */ -#ifndef CONFIG_SYS_SPL_MALLOC_START -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001 -#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \ -CONFIG_SYS_SPL_MALLOC_SIZE + \ -CONFIG_SYS_INIT_RAM_ADDR) -#endif -#endif - /* SPL SDMMC boot support */ #ifdef CONFIG_SPL_MMC_SUPPORT #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4) @@ -294,11 +284,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void); /* * Stack setup */ -#if defined(CONFIG_TARGET_SOCFPGA_GEN5) #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10) -#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START -#endif /* Extra Environment */ #ifndef CONFIG_SPL_BUILD -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] dlmalloc: be compatible to tiny printf
Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny
printf used in SPL.
Signed-off-by: Simon Goldschmidt
---
Changes in v2: None
common/dlmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 51d3bd671a..af6f43dcc9 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -608,7 +608,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end--;
}
- debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
+ debug("using memory 0x%lx-0x%lx for malloc()\n", mem_malloc_start,
mem_malloc_end);
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
memset((void *)mem_malloc_start, 0x0, size);
--
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] spl: arm: implement SPL_CLEAR_BSS_F
This implements the new option to clear BSS early in SPL for standard arm and arm64 crt0. BSS is cleared before calling board_init_f() and thus not cleared before calling board_init_r() as it is not relocated in SPL. Signed-off-by: Simon Goldschmidt --- Changes in v2: - add CONFIG_SPL_CLEAR_BSS_F implementation for arm64 also arch/arm/lib/crt0.S| 22 ++ arch/arm/lib/crt0_64.S | 14 ++ 2 files changed, 36 insertions(+) diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S index fe312db690..b06e54e144 100644 --- a/arch/arm/lib/crt0.S +++ b/arch/arm/lib/crt0.S @@ -80,6 +80,26 @@ ENTRY(_main) mov r9, r0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_CLEAR_BSS_F) + ldr r0, =__bss_start + +#ifdef CONFIG_USE_ARCH_MEMSET + ldr r3, =__bss_end + mov r1, #0x /* prepare zero to clear BSS */ + + subsr2, r3, r0 /* r2 = memset len */ + bl memset +#else + ldr r1, =__bss_end + mov r2, #0x /* prepare zero to clear BSS */ + +clbss_l:cmpr0, r1 /* while not at end of BSS */ + strlo r2, [r0]/* clear 32-bit BSS word */ + addlo r0, r0, #4 /* move to next */ + blo clbss_l +#endif +#endif + mov r0, #0 bl board_init_f @@ -124,6 +144,7 @@ here: movne sp, r0 movne r9, r0 # endif +#if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_CLEAR_BSS_F) ldr r0, =__bss_start/* this is auto-relocated! */ #ifdef CONFIG_USE_ARCH_MEMSET @@ -141,6 +162,7 @@ clbss_l:cmp r0, r1 /* while not at end of BSS */ addlo r0, r0, #4 /* move to next */ blo clbss_l #endif +#endif #if ! defined(CONFIG_SPL_BUILD) bl coloured_LED_init diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S index d6b632aa87..82f643f737 100644 --- a/arch/arm/lib/crt0_64.S +++ b/arch/arm/lib/crt0_64.S @@ -86,6 +86,18 @@ ENTRY(_main) mov x18, x0 bl board_init_f_init_reserve +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_CLEAR_BSS_F) +/* + * Clear BSS section + */ + ldr x0, =__bss_start + ldr x1, =__bss_end +clear_loop: + str xzr, [x0], #8 + cmp x0, x1 + b.loclear_loop +#endif + mov x0, #0 bl board_init_f @@ -136,6 +148,7 @@ relocation_return: mov sp, x0 #endif +#if !defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL_CLEAR_BSS_F) /* * Clear BSS section */ @@ -145,6 +158,7 @@ clear_loop: str xzr, [x0], #8 cmp x0, x1 b.loclear_loop +#endif /* call board_init_r(gd_t *id, ulong dest_addr) */ mov x0, x18 /* gd_t */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] dlmalloc: fix malloc range at end of ram
If the malloc range passed to mem_malloc_init() is at the end of address
range and 'start + size' overflows to 0, following allocations fail as
mem_malloc_end is zero (which looks like uninitialized).
Fix this by subtracting 1 of 'start + size' overflows to zero.
Signed-off-by: Simon Goldschmidt
---
Changes in v2: None
common/dlmalloc.c | 4
1 file changed, 4 insertions(+)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index edaad299bb..51d3bd671a 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -603,6 +603,10 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_start = start;
mem_malloc_end = start + size;
mem_malloc_brk = start;
+ if (start && size && !mem_malloc_end) {
+ /* overflow: malloc area is at end of address range */
+ mem_malloc_end--;
+ }
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
mem_malloc_end);
--
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] spl: add Kconfig option to clear bss early
This introduces a new Kconfig option SPL_CLEAR_BSS_F. If enabled, it clears the bss before calling board_init_f() instead of clearing it before calling board_init_r(). This also ensures that variables placed in BSS can be shared between board_init_f() and board_init_r() in SPL. Make the new option depend on ARM for now until more implementations follow. Signed-off-by: Simon Goldschmidt --- Changes in v2: - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now common/spl/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 206c24076d..6a4270516a 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -156,6 +156,18 @@ config SPL_STACK_R_MALLOC_SIMPLE_LEN to give board_init_r() a larger heap then the initial heap in SRAM which is limited to SYS_MALLOC_F_LEN bytes. +config SPL_CLEAR_BSS_F + bool "Clear BSS section before calling board_init_f" + depends on ARM + help + The BSS section is initialized to zero. In SPL, this is normally done + before calling board_init_r(). + For platforms using BSS in board_init_f() already, enable this to + clear the BSS section before calling board_init_f() instead of + clearing it before calling board_init_r(). This also ensures that + variables placed in BSS can be shared between board_init_f() and + board_init_r(). + config SPL_SEPARATE_BSS bool "BSS section is in a different memory region from text" help -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/6] spl: full-featured heap cleanups
Some platforms cannot use simple malloc even in very early stages, e.g. when using FAT before DRAM is available. Such platforms currently often use non-Kconfig defines to initialize full malloc and rely on simple heap before that. This series makes some adjustments to ensure SPL behaves the same with simple or full malloc: when CONFIG_SPL_SYS_MALLOC_F_LEN is != 0, both heap types can be used (by changing CONFIG_SPL_SYS_MALLOC_SIMPLE), without manually supplying an address range for the full heap. Changes in v2: - make CONFIG_SPL_CLEAR_BSS_F depend on ARM for now - add CONFIG_SPL_CLEAR_BSS_F implementation for arm64 also Simon Goldschmidt (6): spl: add Kconfig option to clear bss early spl: arm: implement SPL_CLEAR_BSS_F dlmalloc: fix malloc range at end of ram dlmalloc: be compatible to tiny printf spl: support using full malloc with SYS_MALLOC_F_LEN arm: socfpga: a10: move SPL stack size to Kconfig arch/arm/lib/crt0.S | 22 ++ arch/arm/lib/crt0_64.S| 14 ++ common/dlmalloc.c | 6 +- common/spl/Kconfig| 12 common/spl/spl.c | 5 + configs/socfpga_arria10_defconfig | 1 + include/configs/socfpga_common.h | 14 -- 7 files changed, 59 insertions(+), 15 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [ANN] No montly community call this month
Hey all, While I had scheduled this coming Monday for another community call, I'm canceling the March one. While I had hoped to have made more progress on being able to message everyone and then in turn try and find a time that perhaps works best to allow more people to participate, that's a little behind schedule right now. 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] usb: host: Print device name when scanning
On 15/Mar/2019 18:34, Marek Vasut wrote:
> On 3/14/19 5:19 PM, Ismael Luceno Cortes wrote:
> > On 14/Mar/2019 16:09, Marek Vasut wrote:
> >> On 3/14/19 1:57 PM, Ismael Luceno Cortes wrote:
> >>> On 14/Mar/2019 12:55, Marek Vasut wrote:
> On 3/14/19 12:44 PM, Ismael Luceno Cortes wrote:
> > On 18/Feb/2019 09:23, Ismael Luceno Cortes wrote:
> >> Signed-off-by: Ismael Luceno
> >> ---
> >> drivers/usb/host/usb-uclass.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/usb/host/usb-uclass.c
> >> b/drivers/usb/host/usb-uclass.c
> >> index 611ea97a72..0575f5393b 100644
> >> --- a/drivers/usb/host/usb-uclass.c
> >> +++ b/drivers/usb/host/usb-uclass.c
> >> @@ -255,7 +255,7 @@ int usb_init(void)
> >>
> >>uclass_foreach_dev(bus, uc) {
> >>/* init low_level USB */
> >> - printf("USB%d: ", count);
> >> + printf("USB%d(%s): ", count, bus->name);
> >>count++;
> >>
> >> #ifdef CONFIG_SANDBOX
> >> --
> >> 2.19.1
> >
> > Ping.
>
> What is this patch doing ? The commit description doesn't explain
> anything about it.
> >>>
> >>> It prints the host device name. I'm not sure the count is at all useful
> >>> given there's a name...
> >>
> >> If you could share the log before and after to better illustrate the
> >> difference, that'd be nice.
> >
> > unpatched:
> >
> > => usb reset
> > resetting USB...
> > USB0: USB EHCI 1.10
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> >
> > patched:
> >
> > => usb reset
> > resetting USB...
> > USB0(usb@ee080100): USB EHCI 1.10
> > scanning bus 0 for devices... 2 USB Device(s) found
> >scanning usb for storage devices... 1 Storage Device(s) found
> >
> >> However, shouldn't the same approach be applied to 'usb tree' subcommand
> >> and possibly others ?
> >
> > The number shown during usb scanning is not used nor saved anywhere
> > else, so seems pretty useless and a special case.
>
> What about usb part ? That one uses the number somehow I think ?
Not this number.
> > OTOH the number used in the usb tree command is taken from struct
> > usb_device, and is used for lookups.
>
> Maybe it's time to clean that numbering mess up a bit , and make it
> consistent ?
Maybe implement it like a vfs? It would force some consistency into the
drivers and commands.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: make SPL_TEXT_BASE overridable
To boot from fpga on socfpga gen5, we need to set CONFIG_SPL_TEXT_BASE to 0xC000 (hps2fpgaslaves base address). Since converting CONFIG_SPL_TEXT_BASE to Kconfig hasn't been successful so far, let's make this value overridable in socfpga_common.h, so that we can have different board configs override this in socfpga_common.h. Signed-off-by: Simon Goldschmidt --- include/configs/socfpga_common.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 181af9b646..191204b27b 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -248,8 +248,10 @@ unsigned int cm_get_qspi_controller_clk_hz(void); * 0xFFEz_ .. Malloc area (grows up to top) * 0xFFE3_ .. End of SRAM (top) */ +#ifndef CONFIG_SPL_TEXT_BASE #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE +#endif #if defined(CONFIG_TARGET_SOCFPGA_ARRIA10) /* SPL memory allocation configuration, this is for FAT implementation */ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: da850evm: Remove legacy MMC code
With the migration to DM in SPL and the DT support, the
old legacy code is no longer neaded, so this patch removes it
Signed-off-by: Adam Ford
diff --git a/board/davinci/da8xxevm/da850evm.c
b/board/davinci/da8xxevm/da850evm.c
index e8ec553f99..1bc26828bf 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -204,25 +204,6 @@ int misc_init_r(void)
return 0;
}
-#ifndef CONFIG_DM_MMC
-#ifdef CONFIG_MMC_DAVINCI
-static struct davinci_mmc mmc_sd0 = {
- .reg_base = (struct davinci_mmc_regs *)DAVINCI_MMC_SD0_BASE,
- .host_caps = MMC_MODE_4BIT, /* DA850 supports only 4-bit SD/MMC */
- .voltages = MMC_VDD_32_33 | MMC_VDD_33_34,
- .version = MMC_CTLR_VERSION_2,
-};
-
-int board_mmc_init(bd_t *bis)
-{
- mmc_sd0.input_clk = clk_get(DAVINCI_MMCSD_CLKID);
-
- /* Add slot-0 to mmc subsystem */
- return davinci_mmc_init(bis, _sd0);
-}
-#endif
-#endif
-
static const struct pinmux_config gpio_pins[] = {
#ifdef CONFIG_USE_NOR
/* GP0[11] is required for NOR to work on Rev 3 EVMs */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
Tom,
(adding Lukasz as he authored the DM fix 0c07a9b4078d)
Am 14.03.2019 um 21:57 schrieb Simon Goldschmidt:
This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51.
The 'eeprom' command has been converted to work with DM_I2C in a patch
submitted around the same time as this commit:
commit 0c07a9b4078d ("eeprom: Add device model based I2C support to eeprom
command")
Signed-off-by: Simon Goldschmidt
I know it's late in the release cycle, but is there a chance to get this
in for v2019.04?
That would allow me to convert I2C and EEPROM access for socfpga in the
socfpga-next tree...
Also, I guess adding this now shouldn't be a great risk since it is
default off and removing the dependency shouldn't harm.
Thanks,
Simon
---
cmd/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4bcc5c4557..74c5a1a6ed 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -455,7 +455,6 @@ config CRC32_VERIFY
config CMD_EEPROM
bool "eeprom - EEPROM subsystem"
- depends on !DM_I2C || DM_I2C_COMPAT
help
(deprecated, needs conversion to driver model)
Provides commands to read and write EEPROM (Electrically Erasable
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: host: Print device name when scanning
On 3/14/19 5:19 PM, Ismael Luceno Cortes wrote:
> On 14/Mar/2019 16:09, Marek Vasut wrote:
>> On 3/14/19 1:57 PM, Ismael Luceno Cortes wrote:
>>> On 14/Mar/2019 12:55, Marek Vasut wrote:
On 3/14/19 12:44 PM, Ismael Luceno Cortes wrote:
> On 18/Feb/2019 09:23, Ismael Luceno Cortes wrote:
>> Signed-off-by: Ismael Luceno
>> ---
>> drivers/usb/host/usb-uclass.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/host/usb-uclass.c
>> b/drivers/usb/host/usb-uclass.c
>> index 611ea97a72..0575f5393b 100644
>> --- a/drivers/usb/host/usb-uclass.c
>> +++ b/drivers/usb/host/usb-uclass.c
>> @@ -255,7 +255,7 @@ int usb_init(void)
>>
>> uclass_foreach_dev(bus, uc) {
>> /* init low_level USB */
>> -printf("USB%d: ", count);
>> +printf("USB%d(%s): ", count, bus->name);
>> count++;
>>
>> #ifdef CONFIG_SANDBOX
>> --
>> 2.19.1
>
> Ping.
What is this patch doing ? The commit description doesn't explain
anything about it.
>>>
>>> It prints the host device name. I'm not sure the count is at all useful
>>> given there's a name...
>>
>> If you could share the log before and after to better illustrate the
>> difference, that'd be nice.
>
> unpatched:
>
> => usb reset
> resetting USB...
> USB0: USB EHCI 1.10
> scanning bus 0 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
> patched:
>
> => usb reset
> resetting USB...
> USB0(usb@ee080100): USB EHCI 1.10
> scanning bus 0 for devices... 2 USB Device(s) found
>scanning usb for storage devices... 1 Storage Device(s) found
>
>> However, shouldn't the same approach be applied to 'usb tree' subcommand
>> and possibly others ?
>
> The number shown during usb scanning is not used nor saved anywhere
> else, so seems pretty useless and a special case.
What about usb part ? That one uses the number somehow I think ?
> OTOH the number used in the usb tree command is taken from struct
> usb_device, and is used for lookups.
Maybe it's time to clean that numbering mess up a bit , and make it
consistent ?
> The name is only relevant to non-discoverable devices at the moment.
>
> dm tree shows:
> ... ehci_generic | |-- usb@ee080100
> ... usb_hub | | `-- usb_hub
> ... usb_mass_storage | | `-- usb_mass_storage
> ... usb_storage_blk | | `-- usb_mass_storage.lun0
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] arm: exynos: arndale: Remove unused CONFIG_POWER and CONFIG_POWER_I2C
The CONFIG_POWER and CONFIG_POWER_I2C were introduced in
include/configs/exynos5-common.h in commit 19bd3aaa5991 ("exynos5: fix
build break by adding CONFIG_POWER") and then it propagated up to
include/configs/arndale.h. However before that commit, there was no
build break at all on Arndale and SMDK5250 boards. It seems the commit
fixed nothing and just added unused defines.
In fact, the Arndale board is not configuring its PMIC (S5M8767) which
uses I2C bus.
Signed-off-by: Krzysztof Kozlowski
---
Not tested on Arndale board. Testing is welcomed.
---
include/configs/arndale.h | 8
1 file changed, 8 deletions(-)
diff --git a/include/configs/arndale.h b/include/configs/arndale.h
index 06b02ce90a94..3d0ce471a42c 100644
--- a/include/configs/arndale.h
+++ b/include/configs/arndale.h
@@ -32,10 +32,6 @@
#define CONFIG_SYS_INIT_SP_ADDRCONFIG_IRAM_STACK
-/* PMIC */
-#define CONFIG_POWER
-#define CONFIG_POWER_I2C
-
#define CONFIG_PREBOOT
#define CONFIG_S5P_PA_SYSRAM 0x0202
@@ -44,8 +40,4 @@
/* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override it
*/
#define CONFIG_ARM_GIC_BASE_ADDRESS0x1048
-/* Power */
-#define CONFIG_POWER
-#define CONFIG_POWER_I2C
-
#endif /* __CONFIG_H */
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT
The CONFIG_DM_I2C_COMPAT was introduced in
include/configs/exynos5-common.h in commit 189d80166b31 ("exynos5:
enable dm i2c") and then it propagated up to configs/arndale_defconfig.
However since beginning the Arndale board (Exynos5250) was not using
I2C.
In fact, the Arndale board is not configuring its PMIC (S5M8767) which
uses I2C bus. This setting can be thus safely removed to fix build
warning:
This board uses CONFIG_DM_I2C_COMPAT. Please remove
(possibly in a subsequent patch in your series)
before sending patches to the mailing list.
Signed-off-by: Krzysztof Kozlowski
---
Not tested on Arndale board. Testing is welcomed.
---
configs/arndale_defconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
index 24422645cbac..2f218e8bb64c 100644
--- a/configs/arndale_defconfig
+++ b/configs/arndale_defconfig
@@ -24,7 +24,6 @@ CONFIG_CMD_SOUND=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_DEFAULT_DEVICE_TREE="exynos5250-arndale"
CONFIG_ENV_IS_IN_MMC=y
-CONFIG_DM_I2C_COMPAT=y
CONFIG_MMC_DW=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_S5P=y
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/2] Load splash from FIT image (internal, external, offset)
Hi, > We store a splash screen in SPI-NOR. We chose to use a FIT image as a > container because we want to > - store more than just the splash screen in SPI-NOR, > - do not create a bunch of MTD partitions, > - do not waste storage space, and > - avoid the overhead of a real file system. > > In general U-Boot already supports this. But there were some ripples we > had to smooth out. The following patches resolve these. > > Changes since v1: > - Document default name in README.splashprepare > - Use ALIGN() macro > - Reviewed by Simon Glass > > Changes since v2: > - Reviewed by Stefano Babic and Tomas Melin > > Leo Ruan (2): > splash: Use splashfile instead of location->name > splash: Load internal and external data from FIT > > common/splash_source.c | 65 > +++- > doc/README.splashprepare | 9 --- > 2 files changed, 48 insertions(+), 26 deletions(-) > > -- > 2.7.4 Gentle ping. Ready to apply? Greetings, Mark Building Technologies, Panel Software Fire (BT-FIR/ENG1) Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118 Aufsichtsratsvorsitzender: Christian Fischer; Geschäftsführung: Tanja Rückert, Andreas Bartz, Thomas Quante, Bernhard Schuster ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] passing info from SPL to U-Boot
On Fri, Mar 15, 2019 at 05:41:36AM +0100, Heiko Schocher wrote: > Hello Tom, > > Am 13.03.2019 um 19:19 schrieb Tom Rini: > >On Wed, Mar 13, 2019 at 10:18:06AM +0100, Heiko Schocher wrote: > >>Hello Stefano, > >> > >>Am 13.03.2019 um 09:51 schrieb Stefano Babic: > >>>Hi Heiko, > >>> > >>>On 13/03/19 08:44, Heiko Schocher wrote: > Hello Wolfgang, > > Am 12.03.2019 um 18:46 schrieb Wolfgang Denk: > >Dear Tom, > > > >In message <20190312173125.GP4690@bill-the-cat> you wrote: > >> > >>>I think you were misled by Heiko's description. What he really ment > >>>was just that the addresses where the boot ROM stored the > >>>information about the boot device etc. gets overwriteen when the SPL > >> > >>For clarity, that's not _quite_ it. The ROM passes the value in a > >>register and we move that to scratch space, see > >>arch/arm/mach-omap2/lowlevel_init.S and save_boot_params. This is done > >>on every 32bit Cortex-A TI platform. > >... > >>OK, but here's the problem. We define off, iirc, 1KiB of that SRAM > >>space as not-stack but scratch space to store stuff in. The first > >>problem you will hit, if something else touches that scratch space is > >>what Heiko found, the boot value got blown away. > > > >I see. Well, I think it's best if Heiko explains in detail; what he > >has observed, and what when which part of the information got lost. > >I was just interpreting his mail, so I may easily have misunderstood > >this. > > > >@ Heiko: Can you please elucidate? > > arch/arm/include/asm/arch-am33xx/omap.h > > 19 #ifdef CONFIG_AM33XX > 20 #define NON_SECURE_SRAM_START 0x402F0400 > 21 #define NON_SECURE_SRAM_END 0x4031 > 22 #define NON_SECURE_SRAM_IMG_END 0x4030B800 > 23 #elif defined(CONFIG_TI816X) || defined(CONFIG_TI814X) > 24 #define NON_SECURE_SRAM_START 0x4030 > 25 #define NON_SECURE_SRAM_END 0x4032 > 26 #define NON_SECURE_SRAM_IMG_END 0x4031B800 > 27 #elif defined(CONFIG_AM43XX) > 28 #define NON_SECURE_SRAM_START 0x402F0400 > 29 #define NON_SECURE_SRAM_END 0x4034 > 30 #define NON_SECURE_SRAM_IMG_END 0x40337DE0 > 31 #define QSPI_BASE 0x4790 > 32 #endif > 33 #define SRAM_SCRATCH_SPACE_ADDR (NON_SECURE_SRAM_IMG_END - SZ_1K) > 34 > > > and with ./include/configs/ti_armv7_common.h > > 69 #ifndef CONFIG_SYS_INIT_SP_ADDR > 70 #define CONFIG_SYS_INIT_SP_ADDR (NON_SECURE_SRAM_END - \ > 71 > GENERATED_GBL_DATA_SIZE) > 72 #endif > 73 > > include/generated/generic-asm-offsets.h > > 9 #define GENERATED_GBL_DATA_SIZE 224 /* (sizeof(struct global_data) + > 15) & ~15 @ */ > 10 #define GENERATED_BD_INFO_SIZE 112 /* (sizeof(struct bd_info) + 15) > & ~15 @ */ > 11 #define GD_SIZE 224 /* sizeof(struct global_data) @ */ > > > -> CONFIG_SYS_INIT_SP_ADDR = 0x4034 - 0xe0 = 0x4033ff20 > -> SRAM_SCRATCH_SPACE_ADDR = 0x40337DE0 - 0x400 = 0x403379e0 > > ./arch/arm/include/asm/omap_common.h: > 816 #define OMAP_SRAM_SCRATCH_BOOT_PARAMS (SRAM_SCRATCH_SPACE_ADDR + > 0x24) > > OMAP_SRAM_SCRATCH_BOOT_PARAMS = 0x40337a04 > > So stack is on a higher address than the scratch space. Stack > addresses decrement on usage, so may they overwrite scratch > space, as SPL functionality grows more and more ... > >>> > >>>What about to move this area after the initial SP ? This is the same way > >>>we do with GENERATED_GBL_DATA_SIZE to avoid to be overwritten. > >> > >>If I am not wrong, the value of SRAM_SCRATCH_SPACE_ADDR is not changeable > >>as it comes from the ROM bootloader. > > > >No, we define the scratch space, but there's important restrictions. > > Ah, with ./arch/arm/mach-omap2/lowlevel_init.S > > 20 #ifdef CONFIG_SPL > 21 ENTRY(save_boot_params) > 22 ldr r1, =OMAP_SRAM_SCRATCH_BOOT_PARAMS > 23 str r0, [r1] > 24 b save_boot_params_ret > 25 ENDPROC(save_boot_params) > > and in the AM437x TRM "5.2.5.1 Overview" I read: > """ > When ROM transfers control to the ISW, it passes a parameter to a > Boot Parameter Structure in R0. The Boot Parameter Structure can > be used to determine the boot device, reset reason, etc. The fields > of this structure are described in Table 5-9 > """ Yup. And please bear in mind that what you see there has been true since OMAP2 days, iirc, and is true for all 32bit Cortex-A TI platforms, basically. It's possible that the keystone platforms are the exception to the rule here, actually. But lots and lots of SoCs with a large age range on them. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de
Re: [U-Boot] [PATCH v2] arm: fix hvc call
On Fri, Mar 15, 2019 at 12:13:11PM +, Ibai Erkiaga Elorza wrote: > Hi Alex, > > > -Original Message- > > From: Alexander Graf > > Sent: 25 February 2019 13:09 > > To: Ibai Erkiaga Elorza > > Cc: u-boot@lists.denx.de; Sumit Garg ; Heinrich > > Schuchardt ; Tom Rini ; Albert > > Aribaud > > Subject: Re: [U-Boot][PATCH v2] arm: fix hvc call > > > > > > > > > Am 25.02.2019 um 02:11 schrieb Ibai Erkiaga > elo...@xilinx.com>: > > > > > > HVC call makes use of 6 mandatory arguments rather than 7 in the same > > > way as SMC calls. The 7th argument is optional (Client ID) for both > > > HVC and SMC but is implemented as 16-bit parameter and register R7 or > > > W7. The aim of this patch is just fix compilation error due to an > > > invalid asm code in the HVC call so that's why the 7th argument is > > > removed. > > > > > > The issue does not report any error in a normal build as hvc_call is > > > not used at all and is optimized by the compiler. Using -O0 triggers > > > the error so the patch is intended to fix issues on a ongoing effor to > > > build U-Boot with -O0. > > > > > > Signed-off-by: Ibai Erkiaga > > > > Reviewed-by: Alexander Graf > > Thanks for the review. Do I need to CC somebody else to the patch be accepted? No, but I'm inclined currently to take for for the next release rather than right now, unless there's an important argument I'm missing? Which happens more than I'd care to admit ;) -- 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] mpc85xx, mpc86xx: device tree model
On Fri, Mar 15, 2019 at 05:05:06AM +, Prabhakar Kushwaha wrote: > Hi Tom, > > I am seeing following type of build warnings for MMC. > > += WARNING == > +This board does not use CONFIG_DM_MMC. Please update > +the board to use CONFIG_DM_MMC before the v2019.04 release. > +Failure to update by the deadline may result in board removal. > +See doc/driver-model/MIGRATION.txt for more info. > > Considering "number" of powerpc platform are not migrated to deice > tree. They can not be migrated to CONFIG_DM_MMC withing v2019.04 > time-frame (considering rc4 is on 18th march). > v2019.07 looks feasible for removing all warning which includes > CONFIG_DM_USB, CONFIG_DM_SCSI, CONFIG_DM_PCI, CONFIG_DM_SPI_FLASH and > CONFIG_DM_MMC. > > is there any plan of removing boards which don't have CONFIG_DM_MMC > for v2019.04? Good question. Where exactly are we with getting more of PowerPC brought up to date with these requirements? I've mentioned before and will say it again, I'm inclined to start marking stuff as 'depends on BROKEN' for a release and then pulling the underlying code (so in this case, non-DM code from drivers/mmc/mmc.c and other MMC-core) for the release following. -- 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] [v2] please pull u-boot-samsung master
On Thu, Mar 14, 2019 at 01:12:41PM +0900, Minkyu Kang wrote: > Hi Tom, > > The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993: > > Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500) > > are available in the git repository at: > > > git://git.denx.de/u-boot-samsung master > > for you to fetch changes up to 1411298cbca83a8527d2c1b5c4d299871fc34cf1: > > arndale: fix unknown status (2019-03-14 09:38:41 +0900) > 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] MAINTAINERS: Remove unsupported statuses - Odd Fixes and Obsolete
On Thu, Mar 14, 2019 at 10:53:10AM +0100, Krzysztof Kozlowski wrote: > The MAINTAINERS file was copied from Linux Kernel along with all its > statuses of maintainership. However tools/genboardscfg.py accepts only > Maintained, Supported and Orphan. Remove then the Odd Fixes and > Obsolete from MAINTAINERS file to avoid confusion. > > Signed-off-by: Krzysztof Kozlowski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2] pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS
From: Thierry Reding If a platform defines CONFIG_NR_DRAM_BANKS, each DRAM bank will be added as a PCI region. The number of MAX_PCI_REGIONS therefore needs to scale with the number of DRAM banks, otherwise we will end up with too little space in the hose->regions array to store all system memory regions. Signed-off-by: Thierry Reding --- include/pci.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/include/pci.h b/include/pci.h index 936cfe975cbe..82ef2dbc6640 100644 --- a/include/pci.h +++ b/include/pci.h @@ -534,7 +534,11 @@ extern void pci_cfgfunc_do_nothing(struct pci_controller* hose, pci_dev_t dev, extern void pci_cfgfunc_config_device(struct pci_controller* hose, pci_dev_t dev, struct pci_config_table *); -#define MAX_PCI_REGIONS7 +#ifdef CONFIG_NR_DRAM_BANKS +#define MAX_PCI_REGIONS (CONFIG_NR_DRAM_BANKS + 7) +#else +#define MAX_PCI_REGIONS 7 +#endif #define INDIRECT_TYPE_NO_PCIE_LINK 1 -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] pci: Add boundary check for hose->regions
From: Thierry Reding
Make sure that we don't overflow the hose->regions array, otherwise we
would end up overwriting the hose->region_count field and cause mayhem
to ensue. Also print an error message when we'd be overflowing because
it indicates that there aren't enough regions available and the number
needs to be increased.
Signed-off-by: Thierry Reding
---
drivers/pci/pci-uclass.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 824fa1190747..cf1e7617ae35 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -918,6 +918,11 @@ static void decode_regions(struct pci_controller *hose,
ofnode parent_node,
return;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; ++i) {
+ if (hose->region_count == MAX_PCI_REGIONS) {
+ pr_err("maximum number of regions parsed, aborting\n");
+ break;
+ }
+
if (bd->bi_dram[i].size) {
pci_set_region(hose->regions + hose->region_count++,
bd->bi_dram[i].start,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 5/5] ARM: board: meson: add p201 board
This adds the p201 reference board Signed-off-by: Mohammad Rasim Acked-by: Neil Armstrong --- board/amlogic/p201/MAINTAINERS | 5 ++ board/amlogic/p201/Makefile| 5 ++ board/amlogic/p201/README.p201 | 103 + board/amlogic/p201/p201.c | 43 ++ configs/p201_defconfig | 41 + 5 files changed, 197 insertions(+) create mode 100644 board/amlogic/p201/MAINTAINERS create mode 100644 board/amlogic/p201/Makefile create mode 100644 board/amlogic/p201/README.p201 create mode 100644 board/amlogic/p201/p201.c create mode 100644 configs/p201_defconfig diff --git a/board/amlogic/p201/MAINTAINERS b/board/amlogic/p201/MAINTAINERS new file mode 100644 index ..3e84a8e2a2af --- /dev/null +++ b/board/amlogic/p201/MAINTAINERS @@ -0,0 +1,5 @@ +P201 +M: Neil Armstrong +S: Maintained +F: board/amlogic/p201/ +F: configs/p201_defconfig diff --git a/board/amlogic/p201/Makefile b/board/amlogic/p201/Makefile new file mode 100644 index ..11de5396ab4c --- /dev/null +++ b/board/amlogic/p201/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0+ +# +# (C) Copyright 2016 Beniamino Galvani + +obj-y := p201.o diff --git a/board/amlogic/p201/README.p201 b/board/amlogic/p201/README.p201 new file mode 100644 index ..c251096ce142 --- /dev/null +++ b/board/amlogic/p201/README.p201 @@ -0,0 +1,103 @@ +U-Boot for Amlogic P201 +=== + +P201 is a reference board manufactured by Amlogic with the following +specifications: + + - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz + - ARM Mali 450 GPU + - 2GB DDR3 SDRAM + - 10/100 Ethernet + - HDMI 2.0 4K/60Hz display + - 2 x USB 2.0 Host + - eMMC, microSD + - Infrared receiver + - SDIO WiFi Module + - CVBS+Stereo Audio Jack + +Schematics are available from Amlogic on demand. + +Currently the u-boot port supports the following devices: + - serial + - eMMC, microSD + - Ethernet + - I2C + - Regulators + - Reset controller + - Clock controller + - USB Host + - ADC + +u-boot compilation +== + + > export ARCH=arm + > export CROSS_COMPILE=aarch64-none-elf- + > make p201_defconfig + > make + +Image creation +== + +Amlogic doesn't provide sources for the firmware and for tools needed +to create the bootloader image, so it is necessary to obtain them from +the git tree published by the board vendor: + + > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz + > wget https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz + > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz + > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz + > export PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH + > git clone https://github.com/BayLibre/u-boot.git -b n-amlogic-openlinux-20170606 amlogic-u-boot + > cd amlogic-u-boot + > make gxb_p201_v1_defconfig + > make + > export FIPDIR=$PWD/fip + +Go back to mainline U-boot source tree then : + > mkdir fip + + > cp $FIPDIR/gxl/bl2.bin fip/ + > cp $FIPDIR/gxl/acs.bin fip/ + > cp $FIPDIR/gxl/bl21.bin fip/ + > cp $FIPDIR/gxl/bl30.bin fip/ + > cp $FIPDIR/gxl/bl301.bin fip/ + > cp $FIPDIR/gxl/bl31.img fip/ + > cp u-boot.bin fip/bl33.bin + + > $FIPDIR/blx_fix.sh \ + fip/bl30.bin \ + fip/zero_tmp \ + fip/bl30_zero.bin \ + fip/bl301.bin \ + fip/bl301_zero.bin \ + fip/bl30_new.bin \ + bl30 + + > $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0 + + > $FIPDIR/blx_fix.sh \ + fip/bl2_acs.bin \ + fip/zero_tmp \ + fip/bl2_zero.bin \ + fip/bl21.bin \ + fip/bl21_zero.bin \ + fip/bl2_new.bin \ + bl2 + + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl30_new.bin + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl31.img + > $FIPDIR/gxl/aml_encrypt_gxl --bl3enc --input fip/bl33.bin + > $FIPDIR/gxl/aml_encrypt_gxl --bl2sig --input fip/bl2_new.bin --output fip/bl2.n.bin.sig + > $FIPDIR/gxl/aml_encrypt_gxl --bootmk \ + --output fip/u-boot.bin \ + --bl2 fip/bl2.n.bin.sig \ + --bl30 fip/bl30_new.bin.enc \ + --bl31 fip/bl31.img.enc \ + --bl33 fip/bl33.bin.enc + +and then write the image to SD with: + + > DEV=/dev/your_sd_device + > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=512 skip=1 seek=1 + > dd if=fip/u-boot.bin.sd.bin of=$DEV conv=fsync,notrunc bs=1 count=444 diff --git a/board/amlogic/p201/p201.c b/board/amlogic/p201/p201.c new file mode 100644 index ..ef0c65cd9f89 --- /dev/null +++ b/board/amlogic/p201/p201.c @@ -0,0 +1,43 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * (C) Copyright 2016 Beniamino Galvani + */ + +#include +#include +#include +#include +#include +#include
[U-Boot] [PATCH v4 4/5] ARM: board: meson: add p200 board
This adds the p200 defconfig Signed-off-by: Mohammad Rasim --- configs/p200_defconfig | 41 + 1 file changed, 41 insertions(+) create mode 100644 configs/p200_defconfig diff --git a/configs/p200_defconfig b/configs/p200_defconfig new file mode 100644 index ..3980e4eb5f1d --- /dev/null +++ b/configs/p200_defconfig @@ -0,0 +1,41 @@ +CONFIG_ARM=y +CONFIG_ARCH_MESON=y +CONFIG_SYS_TEXT_BASE=0x0100 +CONFIG_DEBUG_UART_BASE=0xc81004c0 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_IDENT_STRING=" p200" +CONFIG_DEBUG_UART=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_OF_BOARD_SETUP=y +CONFIG_MISC_INIT_R=y +# CONFIG_DISPLAY_CPUINFO is not set +# CONFIG_DISPLAY_BOARDINFO is not set +# CONFIG_CMD_BDI is not set +# CONFIG_CMD_IMI is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +# CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_REGULATOR=y +CONFIG_OF_CONTROL=y +CONFIG_DEFAULT_DEVICE_TREE="meson-gxbb-p200" +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_DM_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_MESON=y +CONFIG_DM_MMC=y +CONFIG_MMC_MESON_GX=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_MESON_GXBB=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_DM_RESET=y +CONFIG_DEBUG_UART_MESON=y +CONFIG_DEBUG_UART_ANNOUNCE=y +CONFIG_DEBUG_UART_SKIP_INIT=y +CONFIG_MESON_SERIAL=y +CONFIG_OF_LIBFDT_OVERLAY=y +CONFIG_SYS_BOARD="p200" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 2/5] ARM: dts: meson: add p200 and p201 boards
This adds the device trees for p200 and p201 boards.
Synced from kernel 5.0.0
Commit a667cb7a94d4 ("Merge branch 'akpm' (patches from Andrew)")
Signed-off-by: Mohammad Rasim
Acked-by: Neil Armstrong
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/meson-gxbb-p200.dts | 99
arch/arm/dts/meson-gxbb-p201.dts | 26
arch/arm/dts/meson-gxbb-p20x.dtsi | 247 ++
4 files changed, 374 insertions(+)
create mode 100644 arch/arm/dts/meson-gxbb-p200.dts
create mode 100644 arch/arm/dts/meson-gxbb-p201.dts
create mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2a040b20a539..adf5f26facc1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -60,6 +60,8 @@ dtb-$(CONFIG_ARCH_MESON) += \
meson-gxbb-nanopi-k2.dtb \
meson-gxbb-odroidc2.dtb \
meson-gxbb-nanopi-k2.dtb \
+ meson-gxbb-p200.dtb \
+ meson-gxbb-p201.dtb \
meson-gxl-s905x-p212.dtb \
meson-gxl-s905x-libretech-cc.dtb \
meson-gxl-s905x-khadas-vim.dtb \
diff --git a/arch/arm/dts/meson-gxbb-p200.dts b/arch/arm/dts/meson-gxbb-p200.dts
new file mode 100644
index ..9d2406a7c4fa
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-p200.dts
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Andreas Färber
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Kevin Hilman
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+#include
+
+/ {
+ compatible = "amlogic,p200", "amlogic,meson-gxbb";
+ model = "Amlogic Meson GXBB P200 Development Board";
+
+ avdd18_usb_adc: regulator-avdd18_usb_adc {
+ compatible = "regulator-fixed";
+ regulator-name = "AVDD18_USB_ADC";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ };
+
+ adc_keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+
+ button-home {
+ label = "Home";
+ linux,code = ;
+ press-threshold-microvolt = <90>; /* 50% */
+ };
+
+ button-esc {
+ label = "Esc";
+ linux,code = ;
+ press-threshold-microvolt = <684000>; /* 38% */
+ };
+
+ button-up {
+ label = "Volume Up";
+ linux,code = ;
+ press-threshold-microvolt = <468000>; /* 26% */
+ };
+
+ button-down {
+ label = "Volume Down";
+ linux,code = ;
+ press-threshold-microvolt = <252000>; /* 14% */
+ };
+
+ button-menu {
+ label = "Menu";
+ linux,code = ;
+ press-threshold-microvolt = <0>; /* 0% */
+ };
+ };
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_rgmii_pins>;
+ pinctrl-names = "default";
+ phy-handle = <_phy0>;
+ phy-mode = "rgmii";
+
+ amlogic,tx-delay-ns = <2>;
+
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@3 {
+ /* Micrel KSZ9031 (0x00221620) */
+ reg = <3>;
+ interrupt-parent = <_intc>;
+ /* MAC_INTR on GPIOZ_15 */
+ interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+};
+
+_B {
+ status = "okay";
+ pinctrl-0 = <_b_pins>;
+ pinctrl-names = "default";
+};
+
+ {
+ status = "okay";
+ vref-supply = <_usb_adc>;
+};
diff --git a/arch/arm/dts/meson-gxbb-p201.dts b/arch/arm/dts/meson-gxbb-p201.dts
new file mode 100644
index ..56e0dd1ff55c
--- /dev/null
+++ b/arch/arm/dts/meson-gxbb-p201.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Andreas Färber
+ * Copyright (c) 2016 BayLibre, Inc.
+ * Author: Kevin Hilman
+ */
+
+/dts-v1/;
+
+#include "meson-gxbb-p20x.dtsi"
+
+/ {
+ compatible = "amlogic,p201", "amlogic,meson-gxbb";
+ model = "Amlogic Meson GXBB P201 Development Board";
+};
+
+ {
+ status = "okay";
+ pinctrl-0 = <_rmii_pins>;
+ pinctrl-names = "default";
+ phy-mode = "rmii";
+
+ snps,reset-gpio = < GPIOZ_14 0>;
+ snps,reset-delays-us = <0 1 100>;
+ snps,reset-active-low;
+};
diff --git a/arch/arm/dts/meson-gxbb-p20x.dtsi
b/arch/arm/dts/meson-gxbb-p20x.dtsi
[U-Boot] [PATCH v4 3/5] Arm: dts: meson: add u-boot.dtsi for p200 and p201
This adds *-u-boot.dtsi files for p200 and p201 boards These are just copies of arch/arm/dts/meson-gxbb-odroidc2-u-boot.dtsi Signed-off-by: Mohammad Rasim --- arch/arm/dts/meson-gxbb-p200-u-boot.dtsi | 7 +++ arch/arm/dts/meson-gxbb-p201-u-boot.dtsi | 7 +++ 2 files changed, 14 insertions(+) create mode 100644 arch/arm/dts/meson-gxbb-p200-u-boot.dtsi create mode 100644 arch/arm/dts/meson-gxbb-p201-u-boot.dtsi diff --git a/arch/arm/dts/meson-gxbb-p200-u-boot.dtsi b/arch/arm/dts/meson-gxbb-p200-u-boot.dtsi new file mode 100644 index ..c35158d7e9ee --- /dev/null +++ b/arch/arm/dts/meson-gxbb-p200-u-boot.dtsi @@ -0,0 +1,7 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2019 BayLibre, SAS. + * Author: Neil Armstrong + */ + +#include "meson-gx-u-boot.dtsi" diff --git a/arch/arm/dts/meson-gxbb-p201-u-boot.dtsi b/arch/arm/dts/meson-gxbb-p201-u-boot.dtsi new file mode 100644 index ..c35158d7e9ee --- /dev/null +++ b/arch/arm/dts/meson-gxbb-p201-u-boot.dtsi @@ -0,0 +1,7 @@ +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) +/* + * Copyright (c) 2019 BayLibre, SAS. + * Author: Neil Armstrong + */ + +#include "meson-gx-u-boot.dtsi" -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v4 1/5] ARM: board: meson: rename odroid-c2 to p200
This renames the odroid-c2 to p200 and set it as the default GXBB board
Other boards (odroid-c2 and nanopi-k2) will inherit from p200
Signed-off-by: Mohammad Rasim
---
arch/arm/mach-meson/Kconfig | 2 +-
board/amlogic/{odroid-c2 => p200}/MAINTAINERS | 6 +-
board/amlogic/{odroid-c2 => p200}/Makefile| 2 +-
.../{odroid-c2 => p200}/README.nanopi-k2 | 0
.../{odroid-c2 => p200}/README.odroid-c2 | 0
board/amlogic/p200/README.p200| 103 ++
.../{odroid-c2/odroid-c2.c => p200/p200.c}| 0
configs/nanopi-k2_defconfig | 1 +
configs/odroid-c2_defconfig | 1 +
9 files changed, 110 insertions(+), 5 deletions(-)
rename board/amlogic/{odroid-c2 => p200}/MAINTAINERS (70%)
rename board/amlogic/{odroid-c2 => p200}/Makefile (82%)
rename board/amlogic/{odroid-c2 => p200}/README.nanopi-k2 (100%)
rename board/amlogic/{odroid-c2 => p200}/README.odroid-c2 (100%)
create mode 100644 board/amlogic/p200/README.p200
rename board/amlogic/{odroid-c2/odroid-c2.c => p200/p200.c} (100%)
diff --git a/arch/arm/mach-meson/Kconfig b/arch/arm/mach-meson/Kconfig
index 11077bc6cc24..1b1d0aef0d22 100644
--- a/arch/arm/mach-meson/Kconfig
+++ b/arch/arm/mach-meson/Kconfig
@@ -61,7 +61,7 @@ config SYS_VENDOR
config SYS_BOARD
string "Board name"
- default "odroid-c2" if MESON_GXBB
+ default "p200" if MESON_GXBB
default "p212" if MESON_GXL
default "q200" if MESON_GXM
default "s400" if MESON_AXG
diff --git a/board/amlogic/odroid-c2/MAINTAINERS
b/board/amlogic/p200/MAINTAINERS
similarity index 70%
rename from board/amlogic/odroid-c2/MAINTAINERS
rename to board/amlogic/p200/MAINTAINERS
index 6a853066d781..96fe92dd0874 100644
--- a/board/amlogic/odroid-c2/MAINTAINERS
+++ b/board/amlogic/p200/MAINTAINERS
@@ -1,8 +1,8 @@
-ODROID-C2
+P200
M: Beniamino Galvani
M: Neil Armstrong
S: Maintained
-F: board/amlogic/odroid-c2/
-F: include/configs/odroid-c2.h
+F: board/amlogic/p200/
F: configs/nanopi-k2_defconfig
F: configs/odroid-c2_defconfig
+F: configs/p200_defconfig
diff --git a/board/amlogic/odroid-c2/Makefile b/board/amlogic/p200/Makefile
similarity index 82%
rename from board/amlogic/odroid-c2/Makefile
rename to board/amlogic/p200/Makefile
index a6a3db755f21..f82a7ea9ca6b 100644
--- a/board/amlogic/odroid-c2/Makefile
+++ b/board/amlogic/p200/Makefile
@@ -2,4 +2,4 @@
#
# (C) Copyright 2016 Beniamino Galvani
-obj-y := odroid-c2.o
+obj-y := p200.o
diff --git a/board/amlogic/odroid-c2/README.nanopi-k2
b/board/amlogic/p200/README.nanopi-k2
similarity index 100%
rename from board/amlogic/odroid-c2/README.nanopi-k2
rename to board/amlogic/p200/README.nanopi-k2
diff --git a/board/amlogic/odroid-c2/README.odroid-c2
b/board/amlogic/p200/README.odroid-c2
similarity index 100%
rename from board/amlogic/odroid-c2/README.odroid-c2
rename to board/amlogic/p200/README.odroid-c2
diff --git a/board/amlogic/p200/README.p200 b/board/amlogic/p200/README.p200
new file mode 100644
index ..01d82d1e79e3
--- /dev/null
+++ b/board/amlogic/p200/README.p200
@@ -0,0 +1,103 @@
+U-Boot for Amlogic P200
+===
+
+P200 is a reference board manufactured by Amlogic with the following
+specifications:
+
+ - Amlogic S905 ARM Cortex-A53 quad-core SoC @ 1.5GHz
+ - ARM Mali 450 GPU
+ - 2GB DDR3 SDRAM
+ - Gigabit Ethernet
+ - HDMI 2.0 4K/60Hz display
+ - 2 x USB 2.0 Host
+ - eMMC, microSD
+ - Infrared receiver
+ - SDIO WiFi Module
+ - CVBS+Stereo Audio Jack
+
+Schematics are available from Amlogic on demand.
+
+Currently the u-boot port supports the following devices:
+ - serial
+ - eMMC, microSD
+ - Ethernet
+ - I2C
+ - Regulators
+ - Reset controller
+ - Clock controller
+ - USB Host
+ - ADC
+
+u-boot compilation
+==
+
+ > export ARCH=arm
+ > export CROSS_COMPILE=aarch64-none-elf-
+ > make p200_defconfig
+ > make
+
+Image creation
+==
+
+Amlogic doesn't provide sources for the firmware and for tools needed
+to create the bootloader image, so it is necessary to obtain them from
+the git tree published by the board vendor:
+
+ > wget
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ > wget
https://releases.linaro.org/archive/13.11/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ > tar xvfJ gcc-linaro-aarch64-none-elf-4.8-2013.11_linux.tar.xz
+ > tar xvfJ gcc-linaro-arm-none-eabi-4.8-2013.11_linux.tar.xz
+ > export
PATH=$PWD/gcc-linaro-aarch64-none-elf-4.8-2013.11_linux/bin:$PWD/gcc-linaro-arm-none-eabi-4.8-2013.11_linux/bin:$PATH
+ > git clone https://github.com/BayLibre/u-boot.git -b
n-amlogic-openlinux-20170606 amlogic-u-boot
+ > cd amlogic-u-boot
+ > make gxb_p200_v1_defconfig
+ > make
+ > export FIPDIR=$PWD/fip
+
+Go back to mainline U-boot source tree then :
+ > mkdir fip
+
+ > cp $FIPDIR/gxl/bl2.bin
[U-Boot] [PATCH v4 0/5] Arm: meson: add support for p200 and p201 boards
This adds support for p200 and p201 reference boards from amlogic
Mohammad Rasim (5):
ARM: board: meson: rename odroid-c2 to p200
ARM: dts: meson: add p200 and p201 boards
Arm: dts: meson: add u-boot.dtsi for p200 and p201
ARM: board: meson: add p200 board
ARM: board: meson: add p201 board
arch/arm/dts/Makefile | 2 +
arch/arm/dts/meson-gxbb-p200-u-boot.dtsi | 7 +
arch/arm/dts/meson-gxbb-p200.dts | 99 +++
arch/arm/dts/meson-gxbb-p201-u-boot.dtsi | 7 +
arch/arm/dts/meson-gxbb-p201.dts | 26 ++
arch/arm/dts/meson-gxbb-p20x.dtsi | 247 ++
arch/arm/mach-meson/Kconfig | 2 +-
board/amlogic/{odroid-c2 => p200}/MAINTAINERS | 6 +-
board/amlogic/{odroid-c2 => p200}/Makefile| 2 +-
.../{odroid-c2 => p200}/README.nanopi-k2 | 0
.../{odroid-c2 => p200}/README.odroid-c2 | 0
board/amlogic/p200/README.p200| 103
.../{odroid-c2/odroid-c2.c => p200/p200.c}| 0
board/amlogic/p201/MAINTAINERS| 5 +
board/amlogic/p201/Makefile | 5 +
board/amlogic/p201/README.p201| 103
board/amlogic/p201/p201.c | 43 +++
configs/nanopi-k2_defconfig | 1 +
configs/odroid-c2_defconfig | 1 +
configs/p200_defconfig| 41 +++
configs/p201_defconfig| 41 +++
21 files changed, 736 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/dts/meson-gxbb-p200-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-p200.dts
create mode 100644 arch/arm/dts/meson-gxbb-p201-u-boot.dtsi
create mode 100644 arch/arm/dts/meson-gxbb-p201.dts
create mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi
rename board/amlogic/{odroid-c2 => p200}/MAINTAINERS (70%)
rename board/amlogic/{odroid-c2 => p200}/Makefile (82%)
rename board/amlogic/{odroid-c2 => p200}/README.nanopi-k2 (100%)
rename board/amlogic/{odroid-c2 => p200}/README.odroid-c2 (100%)
create mode 100644 board/amlogic/p200/README.p200
rename board/amlogic/{odroid-c2/odroid-c2.c => p200/p200.c} (100%)
create mode 100644 board/amlogic/p201/MAINTAINERS
create mode 100644 board/amlogic/p201/Makefile
create mode 100644 board/amlogic/p201/README.p201
create mode 100644 board/amlogic/p201/p201.c
create mode 100644 configs/p200_defconfig
create mode 100644 configs/p201_defconfig
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/18] mtd: nand: import nand_hw_control_init()
From: Marc Gonzalez
Linux commit d45bc58dd3b ("mtd: nand: import nand_hw_control_init()")
The code to initialize a struct nand_hw_control is duplicated across
several drivers. Factorize it using an inline function.
Signed-off-by: Marc Gonzalez
Signed-off-by: Boris Brezillon
[Philippe Reynes: adapt code to u-boot and only keep new function]
Signed-off-by: Philippe Reynes
---
include/linux/mtd/rawnand.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index e2bd598..96b5847 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -499,6 +499,13 @@ struct nand_hw_control {
struct nand_chip *active;
};
+static inline void nand_hw_control_init(struct nand_hw_control *nfc)
+{
+ nfc->active = NULL;
+ spin_lock_init(>lock);
+ init_waitqueue_head(>wq);
+}
+
/**
* struct nand_ecc_step_info - ECC step information of ECC engine
* @stepsize: data bytes per ECC step
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 03/18] mtd: nand: provide several helpers to do common NAND operations
From: Boris Brezillon
Linux commit 97d90da8a88 ("mtd: nand: provide several helpers
to do common NAND operations")
This is part of the process of removing direct calls to ->cmdfunc()
outside of the core in order to introduce a better interface to execute
NAND operations.
Here we provide several helpers and make use of them to remove all
direct calls to ->cmdfunc(). This way, we can easily modify those
helpers to make use of the new ->exec_op() interface when available.
Signed-off-by: Boris Brezillon
[miquel.ray...@free-electrons.com: rebased and fixed some conflicts]
Signed-off-by: Miquel Raynal
Acked-by: Masahiro Yamada
[Philippe Reynes: adapt code to u-boot and only keep new function]
Signed-off-by: Philippe Reynes
---
drivers/mtd/nand/raw/nand_base.c | 1013 --
include/linux/mtd/rawnand.h | 30 ++
2 files changed, 883 insertions(+), 160 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index 6d2ff58..e07bd6b 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -486,14 +486,19 @@ static int nand_block_markbad_lowlevel(struct mtd_info
*mtd, loff_t ofs)
static int nand_check_wp(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd_to_nand(mtd);
+ u8 status;
+ int ret;
/* Broken xD cards report WP despite being writable */
if (chip->options & NAND_BROKEN_XD)
return 0;
/* Check the WP bit */
- chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
- return (chip->read_byte(mtd) & NAND_STATUS_WP) ? 0 : 1;
+ ret = nand_status_op(chip, );
+ if (ret)
+ return ret;
+
+ return status & NAND_STATUS_WP ? 0 : 1;
}
/**
@@ -575,11 +580,18 @@ static void nand_wait_status_ready(struct mtd_info *mtd,
unsigned long timeo)
{
register struct nand_chip *chip = mtd_to_nand(mtd);
u32 time_start;
+ int ret;
timeo = (CONFIG_SYS_HZ * timeo) / 1000;
time_start = get_timer(0);
while (get_timer(time_start) < timeo) {
- if ((chip->read_byte(mtd) & NAND_STATUS_READY))
+ u8 status;
+
+ ret = nand_read_data_op(chip, , sizeof(status), true);
+ if (ret)
+ return;
+
+ if (status & NAND_STATUS_READY)
break;
WATCHDOG_RESET();
}
@@ -851,7 +863,15 @@ static void panic_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip,
if (chip->dev_ready(mtd))
break;
} else {
- if (chip->read_byte(mtd) & NAND_STATUS_READY)
+ int ret;
+ u8 status;
+
+ ret = nand_read_data_op(chip, , sizeof(status),
+ true);
+ if (ret)
+ return;
+
+ if (status & NAND_STATUS_READY)
break;
}
mdelay(1);
@@ -867,8 +887,9 @@ static void panic_nand_wait(struct mtd_info *mtd, struct
nand_chip *chip,
*/
static int nand_wait(struct mtd_info *mtd, struct nand_chip *chip)
{
- int status;
unsigned long timeo = 400;
+ u8 status;
+ int ret;
led_trigger_event(nand_led_trigger, LED_FULL);
@@ -878,7 +899,9 @@ static int nand_wait(struct mtd_info *mtd, struct nand_chip
*chip)
*/
ndelay(100);
- chip->cmdfunc(mtd, NAND_CMD_STATUS, -1, -1);
+ ret = nand_status_op(chip, NULL);
+ if (ret)
+ return ret;
u32 timer = (CONFIG_SYS_HZ * timeo) / 1000;
u32 time_start;
@@ -889,13 +912,21 @@ static int nand_wait(struct mtd_info *mtd, struct
nand_chip *chip)
if (chip->dev_ready(mtd))
break;
} else {
- if (chip->read_byte(mtd) & NAND_STATUS_READY)
+ ret = nand_read_data_op(chip, ,
+ sizeof(status), true);
+ if (ret)
+ return ret;
+
+ if (status & NAND_STATUS_READY)
break;
}
}
led_trigger_event(nand_led_trigger, LED_OFF);
- status = (int)chip->read_byte(mtd);
+ ret = nand_read_data_op(chip, , sizeof(status), true);
+ if (ret)
+ return ret;
+
/* This can happen if in case of timeout or buggy dev_ready */
WARN_ON(!(status & NAND_STATUS_READY));
return status;
@@ -1048,6 +1079,516 @@ static void __maybe_unused
nand_release_data_interface(struct nand_chip *chip)
}
/**
+ * nand_read_page_op - Do a READ PAGE operation
+ * @chip: The NAND chip
+ * @page: page to read
+ * @offset_in_page:
[U-Boot] [PATCH 15/18] bcm968580xref: add nand support
Enable the nand support (driver and command) in the configuration of the board bcm968580xref. Signed-off-by: Philippe Reynes --- configs/bcm968580xref_ram_defconfig | 7 +++ include/configs/broadcom_bcm968580xref.h | 7 +++ 2 files changed, 14 insertions(+) diff --git a/configs/bcm968580xref_ram_defconfig b/configs/bcm968580xref_ram_defconfig index e8cb3a0..737d726 100644 --- a/configs/bcm968580xref_ram_defconfig +++ b/configs/bcm968580xref_ram_defconfig @@ -15,6 +15,9 @@ CONFIG_SUPPORT_RAW_INITRD=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTEFI_SELFTEST=y +CONFIG_CMD_MTD=y +CONFIG_CMD_NAND=y +CONFIG_CMD_PART=y CONFIG_DOS_PARTITION=y CONFIG_ISO_PARTITION=y CONFIG_EFI_PARTITION=y @@ -23,6 +26,10 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm968580xref" CONFIG_BLK=y CONFIG_CLK=y # CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_NAND=y +CONFIG_NAND_BRCMNAND=y +CONFIG_NAND_BRCMNAND_6858=y CONFIG_SPECIFY_CONSOLE_INDEX=y # CONFIG_SPL_SERIAL_PRESENT is not set CONFIG_CONS_INDEX=0 diff --git a/include/configs/broadcom_bcm968580xref.h b/include/configs/broadcom_bcm968580xref.h index 1c0945e..52b4f55 100644 --- a/include/configs/broadcom_bcm968580xref.h +++ b/include/configs/broadcom_bcm968580xref.h @@ -29,6 +29,13 @@ #define CONFIG_SKIP_LOWLEVEL_INIT +#ifdef CONFIG_NAND +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +#define CONFIG_SYS_NAND_SELF_INIT +#define CONFIG_SYS_NAND_ONFI_DETECTION +#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT +#endif /* CONFIG_NAND */ + /* * 968580xref */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 16/18] dt: bcm63158: add nand controller
Add the nand controller in the bcm63158 device tree.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm63158.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/bcm63158.dtsi b/arch/arm/dts/bcm63158.dtsi
index 6a3fbc9..12ade2a 100644
--- a/arch/arm/dts/bcm63158.dtsi
+++ b/arch/arm/dts/bcm63158.dtsi
@@ -98,5 +98,18 @@
compatible = "wdt-reboot";
wdt = <>;
};
+
+ nand: nand-controller@ff801800 {
+ compatible = "brcm,nand-bcm63158",
+"brcm,brcmnand-v5.0",
+"brcm,brcmnand";
+ reg-names = "nand", "nand-int-base", "nand-cache";
+ reg = <0x0 0xff801800 0x0 0x180>,
+ <0x0 0xff802000 0x0 0x10>,
+ <0x0 0xff801c00 0x0 0x200>;
+ parameter-page-big-endian = <0>;
+
+ status = "disabled";
+ };
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 18/18] bcm963158: add nand support
Enable the nand support (driver and command) in the configuration of the board bcm963158. Signed-off-by: Philippe Reynes --- configs/bcm963158_ram_defconfig | 6 ++ include/configs/broadcom_bcm963158.h | 7 +++ 2 files changed, 13 insertions(+) diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig index fc55e98..248044a 100644 --- a/configs/bcm963158_ram_defconfig +++ b/configs/bcm963158_ram_defconfig @@ -20,6 +20,8 @@ CONFIG_CMD_BOOTEFI_SELFTEST=y # CONFIG_CMD_LZMADEC is not set # CONFIG_CMD_UNZIP is not set # CONFIG_CMD_FLASH is not set +CONFIG_CMD_MTD=y +CONFIG_CMD_NAND=y CONFIG_CMD_CACHE=y CONFIG_DOS_PARTITION=y CONFIG_ISO_PARTITION=y @@ -29,6 +31,10 @@ CONFIG_DEFAULT_DEVICE_TREE="bcm963158" CONFIG_BLK=y CONFIG_CLK=y # CONFIG_MMC is not set +CONFIG_MTD=y +CONFIG_NAND=y +CONFIG_NAND_BRCMNAND=y +CONFIG_NAND_BRCMNAND_63158=y CONFIG_SPECIFY_CONSOLE_INDEX=y # CONFIG_SPL_SERIAL_PRESENT is not set CONFIG_CONS_INDEX=0 diff --git a/include/configs/broadcom_bcm963158.h b/include/configs/broadcom_bcm963158.h index 5834e1e..2de6f21 100644 --- a/include/configs/broadcom_bcm963158.h +++ b/include/configs/broadcom_bcm963158.h @@ -30,6 +30,13 @@ #define CONFIG_SKIP_LOWLEVEL_INIT +#ifdef CONFIG_NAND +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +#define CONFIG_SYS_NAND_SELF_INIT +#define CONFIG_SYS_NAND_ONFI_DETECTION +#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT +#endif /* CONFIG_NAND */ + /* * bcm963158 */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 17/18] dt: bcm963158: enable nand controller
Enable the nand controller in the device tree
of the board bcm963158.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm963158.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/dts/bcm963158.dts b/arch/arm/dts/bcm963158.dts
index dc5afb5..abb44a6 100644
--- a/arch/arm/dts/bcm963158.dts
+++ b/arch/arm/dts/bcm963158.dts
@@ -29,3 +29,18 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ status = "okay";
+ write-protect = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ brcm,nand-oob-sector-size = <16>;
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 14/18] dt: bcm968580xref: enable nand controller
Enable the nand controller in the device tree
of the board bcm968580xref.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm968580xref.dts | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/dts/bcm968580xref.dts b/arch/arm/dts/bcm968580xref.dts
index 0c59f94..2085c18 100644
--- a/arch/arm/dts/bcm968580xref.dts
+++ b/arch/arm/dts/bcm968580xref.dts
@@ -29,3 +29,18 @@
u-boot,dm-pre-reloc;
status = "okay";
};
+
+ {
+ status = "okay";
+ write-protect = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ brcm,nand-oob-sector-size = <16>;
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/18] drivers: nand: brcmnand: add an option to read the write-protect from device tree
The option write-protect may only change on the kernel command line,
we add a property in the device tree to be more flexible.
Signed-off-by: Philippe Reynes
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index e20..faa6da4 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -2671,6 +2671,9 @@ int brcmnand_probe(struct udevice *dev, struct
brcmnand_soc *soc)
/* Disable XOR addressing */
brcmnand_rmw_reg(ctrl, BRCMNAND_CS_XOR, 0xff, 0, 0);
+ /* Read the write-protect configuration in the device tree */
+ wp_on = dev_read_u32_default(dev, "write-protect", wp_on);
+
if (ctrl->features & BRCMNAND_HAS_WP) {
/* Permanently disable write protection */
if (wp_on == 2)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 13/18] dt: bcm6858: add nand controller
Add the nand controller in the bcm6858 device tree.
Signed-off-by: Philippe Reynes
---
arch/arm/dts/bcm6858.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/dts/bcm6858.dtsi b/arch/arm/dts/bcm6858.dtsi
index 23b80c6..f48f93b 100644
--- a/arch/arm/dts/bcm6858.dtsi
+++ b/arch/arm/dts/bcm6858.dtsi
@@ -98,5 +98,18 @@
compatible = "wdt-reboot";
wdt = <>;
};
+
+ nand: nand-controller@ff801800 {
+ compatible = "brcm,nand-bcm6858",
+"brcm,brcmnand-v5.0",
+"brcm,brcmnand";
+ reg-names = "nand", "nand-int-base", "nand-cache";
+ reg = <0x0 0xff801800 0x0 0x180>,
+ <0x0 0xff802000 0x0 0x10>,
+ <0x0 0xff801c00 0x0 0x200>;
+ parameter-page-big-endian = <0>;
+
+ status = "disabled";
+ };
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/18] dt: bcm968380gerg: enable nand controller
Enable the nand controller in the device tree
of the board bcm96838gerg.
Signed-off-by: Philippe Reynes
---
arch/mips/dts/brcm,bcm968380gerg.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/mips/dts/brcm,bcm968380gerg.dts
b/arch/mips/dts/brcm,bcm968380gerg.dts
index 513045e..a070adf 100644
--- a/arch/mips/dts/brcm,bcm968380gerg.dts
+++ b/arch/mips/dts/brcm,bcm968380gerg.dts
@@ -38,3 +38,15 @@
label = "bcm968380gerg:green:usb";
};
};
+
+ {
+ status = "okay";
+
+ nandcs@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ brcm,nand-oob-sector-size = <16>;
+ };
+};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/18] bcm968380gerg: add nand support
Enable the nand support (driver and command) in the configuration of the board bcm96838gerg. Signed-off-by: Philippe Reynes --- configs/bcm968380gerg_ram_defconfig | 7 +++ include/configs/broadcom_bcm968380gerg.h | 7 +++ 2 files changed, 14 insertions(+) diff --git a/configs/bcm968380gerg_ram_defconfig b/configs/bcm968380gerg_ram_defconfig index 61661bd..9d42d59 100644 --- a/configs/bcm968380gerg_ram_defconfig +++ b/configs/bcm968380gerg_ram_defconfig @@ -25,6 +25,7 @@ CONFIG_CMD_LICENSE=y CONFIG_CMD_MEMINFO=y # CONFIG_CMD_FLASH is not set # CONFIG_CMD_LOADS is not set +CONFIG_CMD_NAND=y # CONFIG_CMD_MISC is not set CONFIG_DEFAULT_DEVICE_TREE="brcm,bcm968380gerg" # CONFIG_NET is not set @@ -34,6 +35,12 @@ CONFIG_DM_GPIO=y CONFIG_LED=y CONFIG_LED_BCM6328=y CONFIG_LED_BLINK=y +CONFIG_MTD=y +CONFIG_NAND=y +CONFIG_NAND_BRCMNAND=y +CONFIG_NAND_BRCMNAND_6838=y +CONFIG_SPI_FLASH=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY=y CONFIG_BCM6368_USBH_PHY=y CONFIG_PINCTRL=y diff --git a/include/configs/broadcom_bcm968380gerg.h b/include/configs/broadcom_bcm968380gerg.h index 6126a88..355f3ef 100644 --- a/include/configs/broadcom_bcm968380gerg.h +++ b/include/configs/broadcom_bcm968380gerg.h @@ -7,3 +7,10 @@ #include #define CONFIG_ENV_SIZE(8 * 1024) + +#ifdef CONFIG_NAND +#define CONFIG_SYS_MAX_NAND_DEVICE 1 +#define CONFIG_SYS_NAND_SELF_INIT +#define CONFIG_SYS_NAND_ONFI_DETECTION +#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT +#endif /* CONFIG_NAND */ -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/18] drivers: nand: brcmnand: add initial support
The driver brcmnand come from linux kernel 4.18.
Only SoC bcm6838 and bcm6858 are supported.
Signed-off-by: Philippe Reynes
---
drivers/mtd/nand/raw/Kconfig| 25 +
drivers/mtd/nand/raw/Makefile |1 +
drivers/mtd/nand/raw/brcmnand/Makefile |7 +
drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c | 123 +
drivers/mtd/nand/raw/brcmnand/bcm6838_nand.c| 122 +
drivers/mtd/nand/raw/brcmnand/bcm6858_nand.c| 123 +
drivers/mtd/nand/raw/brcmnand/brcmnand.c| 2789 +++
drivers/mtd/nand/raw/brcmnand/brcmnand.h| 63 +
drivers/mtd/nand/raw/brcmnand/brcmnand_compat.c | 66 +
drivers/mtd/nand/raw/brcmnand/brcmnand_compat.h | 15 +
10 files changed, 3334 insertions(+)
create mode 100644 drivers/mtd/nand/raw/brcmnand/Makefile
create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c
create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6838_nand.c
create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6858_nand.c
create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand.c
create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand.h
create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand_compat.c
create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand_compat.h
diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig
index 7f76e5e..92fadeb 100644
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -60,6 +60,31 @@ config SPL_GENERATE_ATMEL_PMECC_HEADER
endif
+config NAND_BRCMNAND
+ bool "Support Broadcom NAND controller"
+ depends on OF_CONTROL && DM && MTD
+ help
+ Enable the driver for NAND flash on platforms using a Broadcom NAND
+ controller.
+
+config NAND_BRCMNAND_6838
+ bool "Support Broadcom NAND controller on bcm6838"
+ depends on NAND_BRCMNAND && ARCH_BMIPS && SOC_BMIPS_BCM6838
+ help
+ Enable support for broadcom nand driver on bcm6838.
+
+config NAND_BRCMNAND_6858
+ bool "Support Broadcom NAND controller on bcm6858"
+ depends on NAND_BRCMNAND && ARCH_BCM6858
+ help
+ Enable support for broadcom nand driver on bcm6858.
+
+config NAND_BRCMNAND_63158
+ bool "Support Broadcom NAND controller on bcm63158"
+ depends on NAND_BRCMNAND && ARCH_BCM63158
+ help
+ Enable support for broadcom nand driver on bcm63158.
+
config NAND_DAVINCI
bool "Support TI Davinci NAND controller"
help
diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile
index c61e3f3..7e50206 100644
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o
obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_NAND_ARASAN) += arasan_nfc.o
+obj-$(CONFIG_NAND_BRCMNAND) += brcmnand/
obj-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
obj-$(CONFIG_NAND_DENALI) += denali.o
obj-$(CONFIG_NAND_DENALI_DT) += denali_dt.o
diff --git a/drivers/mtd/nand/raw/brcmnand/Makefile
b/drivers/mtd/nand/raw/brcmnand/Makefile
new file mode 100644
index 000..a2363cc
--- /dev/null
+++ b/drivers/mtd/nand/raw/brcmnand/Makefile
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_NAND_BRCMNAND_63158) += bcm63158_nand.o
+obj-$(CONFIG_NAND_BRCMNAND_6838) += bcm6838_nand.o
+obj-$(CONFIG_NAND_BRCMNAND_6858) += bcm6858_nand.o
+obj-$(CONFIG_NAND_BRCMNAND) += brcmnand.o
+obj-$(CONFIG_NAND_BRCMNAND) += brcmnand_compat.o
diff --git a/drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c
b/drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c
new file mode 100644
index 000..16b0d44
--- /dev/null
+++ b/drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "brcmnand.h"
+
+struct bcm63158_nand_soc {
+ struct brcmnand_soc soc;
+ void __iomem *base;
+};
+
+#define BCM63158_NAND_INT 0x00
+#define BCM63158_NAND_STATUS_SHIFT 0
+#define BCM63158_NAND_STATUS_MASK (0xfff << BCM63158_NAND_STATUS_SHIFT)
+
+#define BCM63158_NAND_INT_EN 0x04
+#define BCM63158_NAND_ENABLE_SHIFT 0
+#define BCM63158_NAND_ENABLE_MASK (0x << BCM63158_NAND_ENABLE_SHIFT)
+
+enum {
+ BCM63158_NP_READ= BIT(0),
+ BCM63158_BLOCK_ERASE= BIT(1),
+ BCM63158_COPY_BACK = BIT(2),
+ BCM63158_PAGE_PGM = BIT(3),
+ BCM63158_CTRL_READY = BIT(4),
+ BCM63158_DEV_RBPIN = BIT(5),
+ BCM63158_ECC_ERR_UNC= BIT(6),
+ BCM63158_ECC_ERR_CORR = BIT(7),
+};
+
+static bool bcm63158_nand_intc_ack(struct brcmnand_soc *soc)
+{
+ struct bcm63158_nand_soc *priv =
+ container_of(soc, struct bcm63158_nand_soc, soc);
+ void __iomem *mmio = priv->base + BCM63158_NAND_INT;
+ u32 val = brcmnand_readl(mmio);
+
+ if (val & (BCM63158_CTRL_READY <<
[U-Boot] [PATCH 10/18] dt: bcm6838: add nand controller
Add the nand controller in the bcm6838 device tree.
Signed-off-by: Philippe Reynes
---
arch/mips/dts/brcm,bcm6838.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/mips/dts/brcm,bcm6838.dtsi b/arch/mips/dts/brcm,bcm6838.dtsi
index b6f9559..2b7baf9 100644
--- a/arch/mips/dts/brcm,bcm6838.dtsi
+++ b/arch/mips/dts/brcm,bcm6838.dtsi
@@ -98,5 +98,18 @@
status = "disabled";
};
+
+ nand: nand-controller@14e02200 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm6838",
+"brcm,brcmnand-v5.0",
+"brcm,brcmnand";
+ reg-names = "nand", "nand-int-base", "nand-cache";
+ reg = <0x14e02200 0x180>,
+ <0x14e000f0 0x10>,
+ <0x14e02600 0x180>;
+ status = "disabled";
+ };
};
};
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/18] arm: asm: io.h: define readX_relaxed and writeX_relaxed
This patch port the function readX_relaxed and
writeX_relaxed from kernel 4.18.
Signed-off-by: Philippe Reynes
---
arch/arm/include/asm/io.h | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 12bc7fb..e6d27b6 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -123,6 +123,27 @@ static inline void __raw_readsl(unsigned long addr, void
*data, int longlen)
#define readq(c) ({ u64 __v = __arch_getq(c); __iormb(); __v; })
/*
+ * Relaxed I/O memory access primitives. These follow the Device memory
+ * ordering rules but do not guarantee any ordering relative to Normal memory
+ * accesses.
+ */
+#define readb_relaxed(c) ({ u8 __r = __raw_readb(c); __r; })
+#define readw_relaxed(c) ({ u16 __r = le16_to_cpu((__force __le16) \
+ __raw_readw(c)); __r; })
+#define readl_relaxed(c) ({ u32 __r = le32_to_cpu((__force __le32) \
+ __raw_readl(c)); __r; })
+#define readq_relaxed(c) ({ u64 __r = le64_to_cpu((__force __le64) \
+ __raw_readq(c)); __r; })
+
+#define writeb_relaxed(v, c) ((void)__raw_writeb((v), (c)))
+#define writew_relaxed(v, c) ((void)__raw_writew((__force u16) \
+ cpu_to_le16(v), (c)))
+#define writel_relaxed(v, c) ((void)__raw_writel((__force u32) \
+ cpu_to_le32(v), (c)))
+#define writeq_relaxed(v, c) ((void)__raw_writeq((__force u64) \
+ cpu_to_le64(v), (c)))
+
+/*
* The compiler seems to be incapable of optimising constants
* properly. Spell it out to the compiler in some cases.
* These are only valid for small values of "off" (< 1<<12)
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 05/18] include: linux: io: define devm_ioremap on board with ioremap
The macro devm_ioremap is only defined for configuration
that doesn't have ioremap. But this macro may also be
defined on configuration with ioremap.
This patch remove the condition for the macro devm_ioremap,
so it's always defined.
Signed-off-by: Philippe Reynes
---
include/linux/io.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/io.h b/include/linux/io.h
index 9badab4..7984788 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -65,8 +65,8 @@ static inline void __iomem *ioremap(resource_size_t offset,
static inline void iounmap(void __iomem *addr)
{
}
+#endif
#define devm_ioremap(dev, offset, size)ioremap(offset, size)
-#endif
#endif /* _LINUX_IO_H */
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/18] drivers: nand: brcmnand: add parameter parameter-page-big-endian
The parameter page isn't always in big endian, so we add
an option to choose the endiannes of the parameter page.
Signed-off-by: Philippe Reynes
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
index 7791077..e20 100644
--- a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/raw/brcmnand/brcmnand.c
@@ -113,6 +113,7 @@ struct brcmnand_controller {
unsigned intirq;
unsigned intdma_irq;
int nand_version;
+ int parameter_page_big_endian;
/* Some SoCs provide custom interrupt status register(s) */
struct brcmnand_soc *soc;
@@ -1439,12 +1440,20 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd,
unsigned command,
* Must cache the FLASH_CACHE now, since changes in
* SECTOR_SIZE_1K may invalidate it
*/
- for (i = 0; i < FC_WORDS; i++)
+ for (i = 0; i < FC_WORDS; i++) {
+ u32 fc;
+
+ fc = brcmnand_read_fc(ctrl, i);
+
/*
* Flash cache is big endian for parameter pages, at
* least on STB SoCs
*/
- flash_cache[i] = be32_to_cpu(brcmnand_read_fc(ctrl, i));
+ if (ctrl->parameter_page_big_endian)
+ flash_cache[i] = be32_to_cpu(fc);
+ else
+ flash_cache[i] = le32_to_cpu(fc);
+ }
brcmnand_soc_data_bus_unprepare(ctrl->soc, true);
@@ -2550,6 +2559,10 @@ int brcmnand_probe(struct udevice *dev, struct
brcmnand_soc *soc)
nand_hw_control_init(>controller);
INIT_LIST_HEAD(>host_list);
+ /* Is parameter page in big endian ? */
+ ctrl->parameter_page_big_endian =
+ dev_read_u32_default(dev, "parameter-page-big-endian", 1);
+
/* NAND register range */
#ifndef __UBOOT__
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 06/18] compat linux: import completion from linux 4.18
This patch port the file include/linux/completion.h
from linux 4.18 to u-boot. It define the structure
but all the function are stubbed.
Signed-off-by: Philippe Reynes
---
include/linux/completion.h | 173 +
1 file changed, 173 insertions(+)
create mode 100644 include/linux/completion.h
diff --git a/include/linux/completion.h b/include/linux/completion.h
new file mode 100644
index 000..9835826
--- /dev/null
+++ b/include/linux/completion.h
@@ -0,0 +1,173 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __LINUX_COMPLETION_H
+#define __LINUX_COMPLETION_H
+
+/*
+ * (C) Copyright 2001 Linus Torvalds
+ *
+ * Atomic wait-for-completion handler data structures.
+ * See kernel/sched/completion.c for details.
+ */
+#ifndef __UBOOT__
+#include
+#endif /* __UBOOT__ */
+
+/*
+ * struct completion - structure used to maintain state for a "completion"
+ *
+ * This is the opaque structure used to maintain the state for a "completion".
+ * Completions currently use a FIFO to queue threads that have to wait for
+ * the "completion" event.
+ *
+ * See also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable), init_completion(),
+ * reinit_completion(), and macros DECLARE_COMPLETION(),
+ * DECLARE_COMPLETION_ONSTACK().
+ */
+struct completion {
+ unsigned int done;
+#ifndef __UBOOT__
+ wait_queue_head_t wait;
+#endif /* __UBOOT__ */
+};
+
+#define init_completion_map(x, m) __init_completion(x)
+#define init_completion(x) __init_completion(x)
+static inline void complete_acquire(struct completion *x) {}
+static inline void complete_release(struct completion *x) {}
+
+#define COMPLETION_INITIALIZER(work) \
+ { 0, __WAIT_QUEUE_HEAD_INITIALIZER((work).wait) }
+
+#define COMPLETION_INITIALIZER_ONSTACK_MAP(work, map) \
+ (*({ init_completion_map(&(work), &(map)); &(work); }))
+
+#define COMPLETION_INITIALIZER_ONSTACK(work) \
+ (*({ init_completion(); }))
+
+/**
+ * DECLARE_COMPLETION - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure. Generally used
+ * for static declarations. You should use the _ONSTACK variant for automatic
+ * variables.
+ */
+#define DECLARE_COMPLETION(work) \
+ struct completion work = COMPLETION_INITIALIZER(work)
+
+/*
+ * Lockdep needs to run a non-constant initializer for on-stack
+ * completions - so we use the _ONSTACK() variant for those that
+ * are on the kernel stack:
+ */
+/**
+ * DECLARE_COMPLETION_ONSTACK - declare and initialize a completion structure
+ * @work: identifier for the completion structure
+ *
+ * This macro declares and initializes a completion structure on the kernel
+ * stack.
+ */
+#ifdef CONFIG_LOCKDEP
+# define DECLARE_COMPLETION_ONSTACK(work) \
+ struct completion work = COMPLETION_INITIALIZER_ONSTACK(work)
+# define DECLARE_COMPLETION_ONSTACK_MAP(work, map) \
+ struct completion work = COMPLETION_INITIALIZER_ONSTACK_MAP(work, map)
+#else
+# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
+# define DECLARE_COMPLETION_ONSTACK_MAP(work, map) DECLARE_COMPLETION(work)
+#endif
+
+/**
+ * init_completion - Initialize a dynamically allocated completion
+ * @x: pointer to completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
+static inline void __init_completion(struct completion *x)
+{
+ x->done = 0;
+#ifndef __UBOOT__
+ init_waitqueue_head(>wait);
+#endif /* __UBOOT__ */
+}
+
+/**
+ * reinit_completion - reinitialize a completion structure
+ * @x: pointer to completion structure that is to be reinitialized
+ *
+ * This inline function should be used to reinitialize a completion structure
so it can
+ * be reused. This is especially important after complete_all() is used.
+ */
+static inline void reinit_completion(struct completion *x)
+{
+ x->done = 0;
+}
+
+#ifndef __UBOOT__
+extern void wait_for_completion(struct completion *);
+extern void wait_for_completion_io(struct completion *);
+extern int wait_for_completion_interruptible(struct completion *x);
+extern int wait_for_completion_killable(struct completion *x);
+extern unsigned long wait_for_completion_timeout(struct completion *x,
+ unsigned long timeout);
+extern unsigned long wait_for_completion_io_timeout(struct completion *x,
+ unsigned long timeout);
+extern long wait_for_completion_interruptible_timeout(
+ struct completion *x, unsigned long timeout);
+extern long wait_for_completion_killable_timeout(
+ struct completion *x, unsigned long timeout);
+extern bool try_wait_for_completion(struct completion *x);
+extern bool completion_done(struct completion *x);
+
+extern void complete(struct completion
[U-Boot] [PATCH 00/18] Initial support of driver brcmnand (from kernel 4.18)
This serie is a port the support of driver brcmnand from kernel 4.18 to u-boot. I've tried to stay as close as possible to the kernel. In this first port, I haven't ported the support of DMA, it's not mandatory in the first step and it could be added later. This code has been tested on bcm6838 (mips), bcm63158 (arm) and bcm6858 (arm64). In the code, I've used "#ifndef __UBOOT__" to show the difference between the kernel code. I've also added a file brcmnand_compat.[hc] to compat function with the kernel (for example devm_clk_get). Changes in v1: - define less function in brcmnand_compat.c/h and add more #ifndef __UBOOT__ - port completion.h (function stubbed) from kernel 4.18 - define devm_ioremap for everybody - remove duplicate SoB - update text commit - add support of bcm63158 Boris Brezillon (1): mtd: nand: provide several helpers to do common NAND operations Brian Norris (1): mtd: add get/set of_node/flash_node helpers Marc Gonzalez (1): mtd: nand: import nand_hw_control_init() Philippe Reynes (15): arm: asm: io.h: define readX_relaxed and writeX_relaxed include: linux: io: define devm_ioremap on board with ioremap compat linux: import completion from linux 4.18 drivers: nand: brcmnand: add initial support drivers: nand: brcmnand: add parameter parameter-page-big-endian drivers: nand: brcmnand: add an option to read the write-protect from device tree dt: bcm6838: add nand controller dt: bcm968380gerg: enable nand controller bcm968380gerg: add nand support dt: bcm6858: add nand controller dt: bcm968580xref: enable nand controller bcm968580xref: add nand support dt: bcm63158: add nand controller dt: bcm963158: enable nand controller bcm963158: add nand support arch/arm/dts/bcm63158.dtsi | 13 + arch/arm/dts/bcm6858.dtsi | 13 + arch/arm/dts/bcm963158.dts | 15 + arch/arm/dts/bcm968580xref.dts | 15 + arch/arm/include/asm/io.h | 21 + arch/mips/dts/brcm,bcm6838.dtsi | 13 + arch/mips/dts/brcm,bcm968380gerg.dts| 12 + configs/bcm963158_ram_defconfig |6 + configs/bcm968380gerg_ram_defconfig |7 + configs/bcm968580xref_ram_defconfig |7 + drivers/mtd/nand/raw/Kconfig| 25 + drivers/mtd/nand/raw/Makefile |1 + drivers/mtd/nand/raw/brcmnand/Makefile |7 + drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c | 123 + drivers/mtd/nand/raw/brcmnand/bcm6838_nand.c| 122 + drivers/mtd/nand/raw/brcmnand/bcm6858_nand.c| 123 + drivers/mtd/nand/raw/brcmnand/brcmnand.c| 2805 +++ drivers/mtd/nand/raw/brcmnand/brcmnand.h| 63 + drivers/mtd/nand/raw/brcmnand/brcmnand_compat.c | 66 + drivers/mtd/nand/raw/brcmnand/brcmnand_compat.h | 15 + drivers/mtd/nand/raw/nand_base.c| 1013 ++-- include/configs/broadcom_bcm963158.h|7 + include/configs/broadcom_bcm968380gerg.h|7 + include/configs/broadcom_bcm968580xref.h|7 + include/linux/completion.h | 173 ++ include/linux/io.h |2 +- include/linux/mtd/rawnand.h | 49 + 27 files changed, 4569 insertions(+), 161 deletions(-) create mode 100644 drivers/mtd/nand/raw/brcmnand/Makefile create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm63158_nand.c create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6838_nand.c create mode 100644 drivers/mtd/nand/raw/brcmnand/bcm6858_nand.c create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand.c create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand.h create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand_compat.c create mode 100644 drivers/mtd/nand/raw/brcmnand/brcmnand_compat.h create mode 100644 include/linux/completion.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/18] mtd: add get/set of_node/flash_node helpers
From: Brian Norris
Linux commit 28b8b26b308 ("mtd: add get/set of_node/flash_node helpers")
We are going to begin using the mtd->dev.of_node field for MTD device
nodes, so let's add helpers for it. Also, we'll be making some
conversions on spi_nor (and nand_chip eventually) too, so get that ready
with their own helpers.
Signed-off-by: Brian Norris
Reviewed-by: Boris Brezillon
[Philippe Reynes: only add function nand_set_flash_node and
nand_get_flash_node because others were already backported]
Signed-off-by: Philippe Reynes
---
include/linux/mtd/rawnand.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/mtd/rawnand.h b/include/linux/mtd/rawnand.h
index 9f5dc81..e2bd598 100644
--- a/include/linux/mtd/rawnand.h
+++ b/include/linux/mtd/rawnand.h
@@ -15,6 +15,7 @@
#include
+#include
#include
#include
#include
@@ -961,6 +962,17 @@ struct nand_chip {
void *priv;
};
+static inline void nand_set_flash_node(struct nand_chip *chip,
+ ofnode node)
+{
+ chip->flash_node = ofnode_to_offset(node);
+}
+
+static inline ofnode nand_get_flash_node(struct nand_chip *chip)
+{
+ return offset_to_ofnode(chip->flash_node);
+}
+
static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
{
return container_of(mtd, struct nand_chip, mtd);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arndale: fix unknown status
On Fri, Mar 15, 2019 at 02:52:12PM +0100, Krzysztof Kozlowski wrote: > On Thu, 14 Mar 2019 at 20:24, Tom Rini wrote: > > I'm taking your patch to the MAINTAINERS file now. That said, generally > > "odd fixes" are what's required of board maintainers, once the port is > > in. However, as we push forward on moving to various frameworks that > > should make life easier overall, over the long term, changes are needed > > that may be more than just an occasional fix. Looking at arndale right > > now for example: > >arm: w+ arndale > > +(arndale) = WARNING == > > +(arndale) This board uses CONFIG_DM_I2C_COMPAT. Please remove > > +(arndale) (possibly in a subsequent patch in your series) > > +(arndale) before sending patches to the mailing list. > > +(arndale) > > > > So, do you have time to look into that build time warning? Thanks! > > Sure, let me 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] arndale: fix unknown status
On Thu, 14 Mar 2019 at 20:24, Tom Rini wrote: > I'm taking your patch to the MAINTAINERS file now. That said, generally > "odd fixes" are what's required of board maintainers, once the port is > in. However, as we push forward on moving to various frameworks that > should make life easier overall, over the long term, changes are needed > that may be more than just an occasional fix. Looking at arndale right > now for example: >arm: w+ arndale > +(arndale) = WARNING == > +(arndale) This board uses CONFIG_DM_I2C_COMPAT. Please remove > +(arndale) (possibly in a subsequent patch in your series) > +(arndale) before sending patches to the mailing list. > +(arndale) > > So, do you have time to look into that build time warning? Thanks! Sure, let me take a look. Best regards, Krzysztof ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: ls102xa: Add workaround for DDR erratum A-008850
> -Original Message- > From: Alison Wang > Sent: Wednesday, March 6, 2019 12:19 PM > To: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Cc: Alison Wang ; Shengzhou Liu > > Subject: [PATCH] armv7: ls102xa: Add workaround for DDR erratum A-008850 > > Barrier transactions from CCI400 need to be disabled till the DDR is > configured, > otherwise it may lead to system hang. > The patch adds workaround to fix the erratum. > > Signed-off-by: Shengzhou Liu > Signed-off-by: Alison Wang > --- Applied u-boot-fsl-qoriq, awaiting upstream --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] board: fsl: lx2160aqds: modify the phy fixup code
> -Original Message- > From: Joe Hershberger > Sent: Tuesday, March 5, 2019 3:58 AM > To: Pankaj Bansal > Cc: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Subject: Re: [U-Boot] [PATCH] board: fsl: lx2160aqds: modify the phy fixup > code > > On Thu, Feb 28, 2019 at 2:13 AM Pankaj Bansal > wrote: > > > > Now that we are representing the MDIO mux in LX2160AQDS board in > > producer/consumer terms, the consumer nodes' has been changed. > > > > Therefore, modify the device tree fixups according to change in device > > tree. > > > > Signed-off-by: Pankaj Bansal > > Acked-by: Joe Hershberger Applied u-boot-fsl-qoriq, awaiting upstream --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: net: ls1088ardb: Fix EC1 and EC2 RCW offset
> -Original Message- > From: U-Boot On Behalf Of Joe Hershberger > Sent: Tuesday, March 5, 2019 12:51 AM > To: Pramod Kumar > Cc: u-boot@lists.denx.de; York Sun > Subject: Re: [U-Boot] [PATCH] drivers: net: ls1088ardb: Fix EC1 and EC2 RCW > offset > > On Thu, Feb 28, 2019 at 3:06 AM Pramod Kumar > wrote: > > > > Fix EC1 and EC2 read from correct offset 26, instead of 25 > > > > Signed-off-by: Pramod Kumar > > Acked-by: Joe Hershberger Applied to u-boot-fsl-qoriq, awating upstream --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] mc : Reduce MC memory size to 128M
> -Original Message- > From: Joe Hershberger > Sent: Saturday, March 2, 2019 2:56 AM > To: Meenakshi Aggarwal > Cc: u-boot ; Prabhakar Kushwaha > > Subject: Re: [U-Boot] [PATCH 2/2] mc : Reduce MC memory size to 128M > > On Tue, Feb 26, 2019 at 9:26 PM Meenakshi Aggarwal > wrote: > > > > ls2088, ls1088 : minimum MC Memory size is 128 MB > > lx2 : minimum MC memory size is 256 MB > > > > Signed-off-by: Meenakshi Aggarwal > > Acked-by: Joe Hershberger Applied u-boot-fsl-qoriq, awaiting upstream --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] driver: net: fsl-mc: Fix DPC MAC address fixup
> -Original Message-
> From: Joe Hershberger
> Sent: Tuesday, March 5, 2019 12:48 AM
> To: Ioana Ciocoi Radulescu
> Cc: u-boot@lists.denx.de; Prabhakar Kushwaha
>
> Subject: Re: [U-Boot] [PATCH] driver: net: fsl-mc: Fix DPC MAC address fixup
>
> On Tue, Feb 26, 2019 at 9:51 AM Ioana Ciocoi Radulescu
> wrote:
> >
> > If node /board_info/ports does not exist in the DPC file, function
> > mc_fixup_dpc() will skip not only MAC address fixup, but also the
> > cache flush at the end. This may cause the other fixup changes (e.g.
> > ICID relatd ones) to be ignored by MC.
>
> Typo in commit log.
>
> >
> > Fixes: 1161dbcc0a36 ("drivers: net: fsl-mc: Include MAC addr fixup to
> > DPL")
> >
> > Signed-off-by: Ioana Radulescu
>
> Acked-by: Joe Hershberger
Applied to u-boot-fsl-qoriq, awaiting upstream
--pk
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] drivers: net: ldpaa_eth: check if the dpmac is enabled
> -Original Message- > From: Joe Hershberger > Sent: Saturday, March 2, 2019 3:00 AM > To: Pankaj Bansal > Cc: Prabhakar Kushwaha ; u- > b...@lists.denx.de > Subject: Re: [U-Boot] [PATCH] drivers: net: ldpaa_eth: check if the dpmac is > enabled > > On Fri, Feb 8, 2019 at 2:59 AM Pankaj Bansal wrote: > > > > some dpmacs in armv8a based freescale layerscape SOCs can be > > configured via both serdes(sgmii, xfi, xlaui etc) bits and via > > EC*_PMUX(rgmii) bits in RCW. > > e.g. dpmac 17 and 18 in LX2160A can be configured as SGMII from serdes > > bits and as RGMII via EC1_PMUX/EC2_PMUX bits Now if a dpmac is enabled > > by serdes bits then it takes precedence over EC*_PMUX bits. i.e. in > > LX2160A if we select serdes protocol that configures dpmac17 as SGMII > > and set the EC1_PMUX as RGMII, then the dpmac is SGMII and not RGMII. > > > > Therefore, in fsl_rgmii_init function of SOC, we will check if the > > dpmac is enabled or not? if it is (fsl_serdes_init has already enabled > > the dpmac), then don't enable it. > > > > Signed-off-by: Pankaj Bansal > > Acked-by: Joe Hershberger Applied fsl-qoriq, awaiting upstream --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-fsl-qoriq master
Hi Tom, The following changes since commit 9ba5e5bc261a16f51662490da0cf620dc7f29013: Revert "env: add spi_flash_read_env function" (2019-03-13 20:32:09 -0400) are available in the git repository at: git://git.denx.de/u-boot-fsl-qoriq.git HEAD for you to fetch changes up to 158097052a6a528408e05d2345ff2ccdbb46036e: armv7: ls102xa: Add workaround for DDR erratum A-008850 (2019-03-15 11:52:01 +0530) Travis build log is https://travis-ci.org/prabhukush/u-boot/builds/506626436 Changes from rc4 tag - DPAA2 fixes and DDR errata workaround for LS1021A Alison Wang (1): armv7: ls102xa: Add workaround for DDR erratum A-008850 Ioana Ciocoi Radulescu (1): driver: net: fsl-mc: Fix DPC MAC address fixup Meenakshi Aggarwal (1): mc : Reduce MC memory size to 128M Pankaj Bansal (2): drivers: net: ldpaa_eth: check if the dpmac is enabled board: fsl: lx2160aqds: modify the phy fixup code Pramod Kumar (1): drivers: net: ls1088ardb: Fix EC1 and EC2 RCW offset arch/arm/cpu/armv7/ls102xa/Kconfig | 6 arch/arm/cpu/armv7/ls102xa/soc.c| 44 + arch/arm/include/asm/arch-ls102xa/ls102xa_soc.h | 2 ++ board/freescale/ls1021aiot/ls1021aiot.c | 2 ++ board/freescale/ls1021aqds/ddr.c| 2 ++ board/freescale/ls1021aqds/ddr.h| 3 ++ board/freescale/ls1021aqds/ls1021aqds.c | 30 - board/freescale/ls1021atwr/ls1021atwr.c | 2 ++ board/freescale/lx2160a/eth_lx2160aqds.c| 38 + drivers/net/fsl-mc/mc.c | 26 --- drivers/net/ldpaa_eth/ls1088a.c | 4 +-- drivers/net/ldpaa_eth/lx2160a.c | 4 +-- include/configs/ls1021aiot.h| 2 ++ include/configs/ls1021atwr.h| 2 ++ include/configs/ls1088a_common.h| 2 +- include/configs/ls2080a_common.h| 2 +- include/configs/lx2160a_common.h| 2 +- 17 files changed, 117 insertions(+), 56 deletions(-) --prabhakar (pk) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Add dfu command entry to MAINTAINERS
On Fri, Mar 15, 2019 at 11:47 AM Anatolij Gustschin wrote: > > get_maintainer.pl doesn't report the maintainer for dfu command > code since its entry is not in the database file. Add it. > Thanks! Reviewed-by: Andy Shevchenko > Signed-off-by: Anatolij Gustschin > Cc: Lukasz Majewski > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4fabb75eda..f205d66155 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -441,6 +441,7 @@ DFU > M: Lukasz Majewski > S: Maintained > T: git git://git.denx.de/u-boot-dfu.git > +F: cmd/dfu.c > F: drivers/dfu/ > F: drivers/usb/gadget/ > > -- > 2.17.1 > > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Add dfu command entry to MAINTAINERS
On Fri, 15 Mar 2019 10:47:20 +0100 Anatolij Gustschin wrote: > get_maintainer.pl doesn't report the maintainer for dfu command > code since its entry is not in the database file. Add it. > > Signed-off-by: Anatolij Gustschin > Cc: Lukasz Majewski > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 4fabb75eda..f205d66155 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -441,6 +441,7 @@ DFU > M: Lukasz Majewski > S: Maintained > T: git git://git.denx.de/u-boot-dfu.git > +F: cmd/dfu.c > F: drivers/dfu/ > F: drivers/usb/gadget/ > Thanks Anatolij, I was not aware of this. Acked-by: Lukasz Majewski Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpcmX5BfBKEk.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] arm: arm64 32bit address relocation
Current relocation code is limited to 21bit PC-relative addressing which might not be enough for bigger code sizes. The following patch increases the addressing to 32bit PC-relative. This feature is specially interesting if U-Boot is build without optimiation (-O0) as the text section is increased significativelly. Signed-off-by: Ibai Erkiaga --- Changes in v2: - Fixed register name on comments arch/arm/lib/relocate_64.S | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index 7603f52..26d29c5 100644 --- a/arch/arm/lib/relocate_64.S +++ b/arch/arm/lib/relocate_64.S @@ -26,9 +26,10 @@ ENTRY(relocate_code) /* * Copy u-boot from flash to RAM */ - adr x1, __image_copy_start /* x1 <- Run &__image_copy_start */ - subsx9, x0, x1 /* x8 <- Run to copy offset */ - b.eqrelocate_done /* skip relocation */ + adrpx1, __image_copy_start /* x1 <- address bits [31:12] */ + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] */ + subsx9, x0, x1 /* x9 <- Run to copy offset */ + b.eqrelocate_done /* skip relocation */ /* * Don't ldr x1, __image_copy_start here, since if the code is already * running at an address other than it was linked to, that instruction @@ -42,8 +43,10 @@ ENTRY(relocate_code) ldr x1, _TEXT_BASE /* x1 <- Linked &__image_copy_start */ subsx9, x0, x1 /* x9 <- Link to copy offset */ - adr x1, __image_copy_start /* x1 <- Run &__image_copy_start */ - adr x2, __image_copy_end/* x2 <- Run &__image_copy_end */ + adrpx1, __image_copy_start /* x1 <- address bits [31:12] */ + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00] */ + adrpx2, __image_copy_end/* x2 <- address bits [31:12] */ + add x2, x2, :lo12:__image_copy_end /* x2 <- address bits [11:00] */ copy_loop: ldp x10, x11, [x1], #16 /* copy from source address [x1] */ stp x10, x11, [x0], #16 /* copy to target address [x0] */ @@ -54,8 +57,10 @@ copy_loop: /* * Fix .rela.dyn relocations */ - adr x2, __rel_dyn_start /* x2 <- Run &__rel_dyn_start */ - adr x3, __rel_dyn_end /* x3 <- Run &__rel_dyn_end */ + adrpx2, __rel_dyn_start /* x2 <- address bits [31:12] */ + add x2, x2, :lo12:__rel_dyn_start /* x2 <- address bits [11:00] */ + adrpx3, __rel_dyn_end /* x3 <- address bits [31:12] */ + add x3, x3, :lo12:__rel_dyn_end /* x3 <- address bits [11:00] */ fixloop: ldp x0, x1, [x2], #16 /* (x0,x1) <- (SRC location, fixup) */ ldr x4, [x2], #8/* x4 <- addend */ -- 1.8.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] arm: fix hvc call
Hi Alex, > -Original Message- > From: Alexander Graf > Sent: 25 February 2019 13:09 > To: Ibai Erkiaga Elorza > Cc: u-boot@lists.denx.de; Sumit Garg ; Heinrich > Schuchardt ; Tom Rini ; Albert > Aribaud > Subject: Re: [U-Boot][PATCH v2] arm: fix hvc call > > > > > Am 25.02.2019 um 02:11 schrieb Ibai Erkiaga elo...@xilinx.com>: > > > > HVC call makes use of 6 mandatory arguments rather than 7 in the same > > way as SMC calls. The 7th argument is optional (Client ID) for both > > HVC and SMC but is implemented as 16-bit parameter and register R7 or > > W7. The aim of this patch is just fix compilation error due to an > > invalid asm code in the HVC call so that's why the 7th argument is removed. > > > > The issue does not report any error in a normal build as hvc_call is > > not used at all and is optimized by the compiler. Using -O0 triggers > > the error so the patch is intended to fix issues on a ongoing effor to > > build U-Boot with -O0. > > > > Signed-off-by: Ibai Erkiaga > > Reviewed-by: Alexander Graf > Thanks for the review. Do I need to CC somebody else to the patch be accepted? > Alex > > > --- > > > > Changes in v2: > > - More comprehensive commit message > > > > arch/arm/cpu/armv8/fwcall.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/arch/arm/cpu/armv8/fwcall.c b/arch/arm/cpu/armv8/fwcall.c > > index 9957c29..b0aca1b 100644 > > --- a/arch/arm/cpu/armv8/fwcall.c > > +++ b/arch/arm/cpu/armv8/fwcall.c > > @@ -28,7 +28,6 @@ static void hvc_call(struct pt_regs *args) > >"ldr x4, %4\n" > >"ldr x5, %5\n" > >"ldr x6, %6\n" > > -"ldr x7, %7\n" > >"hvc#0\n" > >"str x0, %0\n" > >"str x1, %1\n" > > @@ -37,7 +36,7 @@ static void hvc_call(struct pt_regs *args) > >: "+m" (args->regs[0]), "+m" (args->regs[1]), > > "+m" (args->regs[2]), "+m" (args->regs[3]) > >: "m" (args->regs[4]), "m" (args->regs[5]), > > - "m" (args->regs[6]), "m" (args->regs[7]) > > + "m" (args->regs[6]) > >: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", > > "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", > > "x16", "x17"); > > -- > > 1.8.3.1 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] env: Update env addr for mmc environment driver
Signed-off-by: Pankit Garg --- env/mmc.c | 5 + 1 file changed, 5 insertions(+) diff --git a/env/mmc.c b/env/mmc.c index c3cf35d..f5d16cf 100644 --- a/env/mmc.c +++ b/env/mmc.c @@ -313,6 +313,7 @@ static int env_mmc_load(void) int ret; int dev = mmc_get_env_dev(); const char *errmsg; + env_t *ep = NULL; mmc = find_mmc_device(dev); @@ -333,6 +334,10 @@ static int env_mmc_load(void) goto fini; } + ep = (env_t *)buf; + if (crc32(0, ep->data, ENV_SIZE) == ep->crc) + gd->env_addr= (ulong)&(ep->data); + ret = env_import(buf, 1); fini: -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] board: mscc: jr2: Update MSCC Jaguar2 boards
Hi Horatio, Am 06.03.19 um 23:11 schrieb Horatiu Vultur: > Hi Daniel, > > The 03/06/2019 14:19, Daniel Schwierzeck wrote: >> >> >> Am 05.03.19 um 12:57 schrieb Horatiu Vultur: >>> In Jaguar2 SoC family there are 3 different pcb. Each of this needs >>> to configure the SerDes and the phys in different ways. >>> Therefore implement the function board_phy_config and serdes_cfg >>> and based on pcb configure them accordingly. >> >> what are the differences between all boards? Can't you model the >> different register values somehow as custom DT properties? This method >> looks like a lot of code duplication and doesn't scale well when adding >> new boards. > > So there are following boards: > - pcb110: it has viper phys that are connected to serdes1g using the >interface sgmii > - pcb111: it has atom phys that are connected to serdes6g using the >interface qsgmii > - pcb112: it has viper phys that are connected to serdes6g using the >interface sgmii. > > Do you have an example where I can look, how to add this custom > properties? > > Yes, it looks like a lot code duplication, but there are only few > differences between them. I was thinking maybe I can create 2 functions > that configure the serdes1g and serdes6g which will get as a paramenter > the interface mode. In this way I think it would scale better, because > then each new board it would just call these new functions. > > /Horatiu but this code belongs to the ethernet driver. Board specific differences like PHY interface or Serdes type could be configured via appropiate device-tree bindings (PHY interface already exists as generic binding). How do you plan to do it in Linux? I've found Documentation/devicetree/bindings/phy/phy-ocelot-serdes.txt which looks very similar to what you want to achieve here. Maybe the Bootlin guys can give you some more hints ;) > >> >>> >>> Signed-off-by: Horatiu Vultur >>> --- >>> board/mscc/jr2/jr2.c | 542 >>> +++ >>> 1 file changed, 542 insertions(+) >>> >>> diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c >>> index 58a4a04..94e0c5d 100644 >>> --- a/board/mscc/jr2/jr2.c >>> +++ b/board/mscc/jr2/jr2.c >>> @@ -6,6 +6,140 @@ >>> #include >>> #include >>> #include >>> +#include >>> + >>> +#define HSIO_ANA_SERDES1G_DES_CFG 0xac >>> +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_HYST(x)((x) << >>> 1) >>> +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_ANA(x) ((x) << >>> 5) >>> +#defineHSIO_ANA_SERDES1G_DES_CFG_MBTR_CTRL(x) ((x) << >>> 8) >>> +#defineHSIO_ANA_SERDES1G_DES_CFG_PHS_CTRL(x) ((x) << >>> 13) >>> +#define HSIO_ANA_SERDES1G_IB_CFG 0xb0 >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_RESISTOR_CTRL(x) (x) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_EQ_GAIN(x) ((x) << >>> 6) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_OFFSET_COMPBIT(9) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_DETLEV BIT(11) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_CMV_TERM BIT(13) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_DET_LEV(x) ((x) << >>> 19) >>> +#defineHSIO_ANA_SERDES1G_IB_CFG_ACJTAG_HYST(x) ((x) << >>> 24) >>> +#define HSIO_ANA_SERDES1G_OB_CFG 0xb4 >>> +#defineHSIO_ANA_SERDES1G_OB_CFG_RESISTOR_CTRL(x) (x) >>> +#defineHSIO_ANA_SERDES1G_OB_CFG_VCM_CTRL(x)((x) << >>> 4) >>> +#defineHSIO_ANA_SERDES1G_OB_CFG_CMM_BIAS_CTRL(x) ((x) << >>> 10) >>> +#defineHSIO_ANA_SERDES1G_OB_CFG_AMP_CTRL(x)((x) << >>> 13) >>> +#defineHSIO_ANA_SERDES1G_OB_CFG_SLP(x) ((x) << >>> 17) >>> +#define HSIO_ANA_SERDES1G_SER_CFG 0xb8 >>> +#define HSIO_ANA_SERDES1G_COMMON_CFG 0xbc >>> +#defineHSIO_ANA_SERDES1G_COMMON_CFG_IF_MODEBIT(0) >>> +#defineHSIO_ANA_SERDES1G_COMMON_CFG_ENA_LANE BIT(18) >>> +#defineHSIO_ANA_SERDES1G_COMMON_CFG_SYS_RSTBIT(31) >>> +#define HSIO_ANA_SERDES1G_PLL_CFG 0xc0 >>> +#defineHSIO_ANA_SERDES1G_PLL_CFG_FSM_ENA BIT(7) >>> +#defineHSIO_ANA_SERDES1G_PLL_CFG_FSM_CTRL_DATA(x) ((x) << >>> 8) >>> +#defineHSIO_ANA_SERDES1G_PLL_CFG_ENA_RC_DIV2 BIT(21) >>> +#define HSIO_DIG_SERDES1G_DFT_CFG0 0xc8 >>> +#define HSIO_DIG_SERDES1G_TP_CFG 0xd4 >>> +#define HSIO_DIG_SERDES1G_MISC_CFG 0xdc >>> +#defineHSIO_DIG_SERDES1G_MISC_CFG_LANE_RST BIT(0) >>> +#define HSIO_MCB_SERDES1G_CFG 0xe8 >>> +#defineHSIO_MCB_SERDES1G_CFG_WR_ONE_SHOT BIT(31) >>> +#defineHSIO_MCB_SERDES1G_CFG_ADDR(x) (x) >>> + >>> +#define HSIO_ANA_SERDES6G_DES_CFG 0x11c >>>
Re: [U-Boot] [U-Boot, V4, PATCH 1/1] mips: add initial support for qca956x referenced board
Am 08.03.19 um 02:24 schrieb rosys...@rosinson.com: > From: Rosy Song > > QCA9563 is CPU used on AP152 board : > > Clock speed : 750 MHz , > Arch : Mips 74Kc, > Eth : SGMII interface, > MIMO config : 3 * 3 450M, > 2 * USB 2.0, > > Signed-off-by: Rosy Song > > Changes for v2: >- coding Style cleanup >- remove ununsed flash chip in defconfig >- enable automatic icache / dcache size in defconfig > > Changes for v3: >- add detailed information for qca956x in commit message > > Changes for v4: >- remove pre-configured network settings in ap152.h > --- this series still has to much checkpatch.pl issues, please fix. total: 2 errors, 156 warnings, 22 checks, 3776 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: mips: Remove boot_reloc_ramdisk
Am 07.03.19 um 16:49 schrieb Horatiu Vultur:
> Remove the function boot_reloc_ramdisk in the file arch/mips/lib/bootm
> because it is relocating again the ramdisk. The function do_bootm_states()
> already relocates the ramdisk even if it is a legacy uImage or a FIT image.
>
> The relocation in the function do_bootm_states() was introduce in the
> commit c2e7e72bb9f0cb47d024997b381cb64786eb5402 ("bootm: relocate ramdisk
> if CONFIG_SYS_BOOT_RAMDISK_HIGH set")
>
> Signed-off-by: Horatiu Vultur
> ---
> arch/mips/lib/bootm.c | 19 ---
> 1 file changed, 19 deletions(-)
>
applied to u-boot-mips/next, thanks.
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] Short Mailing List statistics
Hi, for those interested in statistical data here some numbers about the U-Boot mailing list. This is a quick and dirty result basing on my local archive, so there may be a few (minimal) differences like single-digit differences in the number ot messages per year or so. YearTotal numberMessagesTrend compared of messages per day to prev. year --- 2002 497 1.4+0.00% 20035621 15.4 +1030.99% 20047141 19.6 +27.04% 20055572 15.3 -21.97% 20066274 17.2 +12.60% 20079548 26.2 +52.18% 2008 18446 50.5 +93.19% 2009 21358 58.5 +15.79% 2010 18963 52.0 -11.21% 2011 28839 79.0 +52.08% 2012 29518 80.9+2.35% 2013 27110 74.3-8.16% 2014 30339 83.1 +11.91% 2015 40101 109.9 +32.18% 2016 37785 103.5-5.78% 2017 38698 106.0+2.42% 2018 38022 104.2-1.75% It would be interesting to analyze what happened in 2007, 2008, 2011 and 2015 to result in such a jump of messages... 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 Making files is easy under the UNIX operating system. Therefore, users tend to create numerous files using large amounts of file space. It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files. - System V.2 administrator's guide ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] mips: mt76xx: gardena-smart-gateway: Correct spelling of GARDENA
Am 15.03.19 um 09:09 schrieb Stefan Roese: > This patch changes Gardena to the correct GARDENA spelling. Also the > platform name is "GARDENA smart Gateway". This patch changes the > incorrect occurrances. > > Signed-off-by: Stefan Roese > Cc: Daniel Schwierzeck > --- > arch/mips/dts/gardena-smart-gateway-mt7688.dts | 2 +- > arch/mips/mach-mt7620/Kconfig | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > applied to u-boot-mips/next, thanks. -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, V4, PATCH 1/1] mips: add initial support for qca956x referenced board
Am 08.03.19 um 02:24 schrieb rosys...@rosinson.com: > From: Rosy Song > > QCA9563 is CPU used on AP152 board : > > Clock speed : 750 MHz , > Arch : Mips 74Kc, > Eth : SGMII interface, > MIMO config : 3 * 3 450M, > 2 * USB 2.0, > > Signed-off-by: Rosy Song > > Changes for v2: >- coding Style cleanup >- remove ununsed flash chip in defconfig >- enable automatic icache / dcache size in defconfig > > Changes for v3: >- add detailed information for qca956x in commit message > > Changes for v4: >- remove pre-configured network settings in ap152.h > --- > arch/mips/dts/Makefile| 1 + > arch/mips/dts/ap152.dts | 48 ++ > arch/mips/dts/qca956x.dtsi| 87 > arch/mips/mach-ath79/Kconfig | 14 + > arch/mips/mach-ath79/Makefile | 1 + > .../mach-ath79/include/mach/ar71xx_regs.h | 73 +++ > arch/mips/mach-ath79/include/mach/ath79.h | 3 + > arch/mips/mach-ath79/qca956x/Makefile | 5 + > arch/mips/mach-ath79/qca956x/clk.c| 419 ++ > arch/mips/mach-ath79/qca956x/cpu.c| 9 + > arch/mips/mach-ath79/qca956x/ddr.c| 308 + > .../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 193 > arch/mips/mach-ath79/reset.c | 271 +++ > board/qca/ap152/Kconfig | 15 + > board/qca/ap152/MAINTAINERS | 6 + > board/qca/ap152/Makefile | 3 + > board/qca/ap152/ap152.c | 81 > configs/ap152_defconfig | 49 ++ > include/configs/ap152.h | 50 +++ > 19 files changed, 1636 insertions(+) > create mode 100644 arch/mips/dts/ap152.dts > create mode 100644 arch/mips/dts/qca956x.dtsi > create mode 100644 arch/mips/mach-ath79/qca956x/Makefile > create mode 100644 arch/mips/mach-ath79/qca956x/clk.c > create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c > create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c > create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S > create mode 100644 board/qca/ap152/Kconfig > create mode 100644 board/qca/ap152/MAINTAINERS > create mode 100644 board/qca/ap152/Makefile > create mode 100644 board/qca/ap152/ap152.c > create mode 100644 configs/ap152_defconfig > create mode 100644 include/configs/ap152.h > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] bootm: mips: Remove boot_reloc_ramdisk
Am 08.03.19 um 13:30 schrieb Horatiu Vultur:
> Hi Daniel,
>
> The 03/07/2019 18:33, Daniel Schwierzeck wrote:
>> Am Do., 7. März 2019 um 16:49 Uhr schrieb Horatiu Vultur
>> :
>>>
>>> Remove the function boot_reloc_ramdisk in the file arch/mips/lib/bootm
>>> because it is relocating again the ramdisk. The function do_bootm_states()
>>> already relocates the ramdisk even if it is a legacy uImage or a FIT image.
>>>
>>> The relocation in the function do_bootm_states() was introduce in the
>>> commit c2e7e72bb9f0cb47d024997b381cb64786eb5402 ("bootm: relocate ramdisk
>>> if CONFIG_SYS_BOOT_RAMDISK_HIGH set")
>>>
>>> Signed-off-by: Horatiu Vultur
>>> ---
>>> arch/mips/lib/bootm.c | 19 ---
>>> 1 file changed, 19 deletions(-)
Reviewed-by: Daniel Schwierzeck
>>>
>>> diff --git a/arch/mips/lib/bootm.c b/arch/mips/lib/bootm.c
>>> index deca518..35152cb 100644
>>> --- a/arch/mips/lib/bootm.c
>>> +++ b/arch/mips/lib/bootm.c
>>> @@ -215,23 +215,6 @@ static void linux_env_legacy(bootm_headers_t *images)
>>> }
>>> }
>>>
>>> -static int boot_reloc_ramdisk(bootm_headers_t *images)
>>> -{
>>> - ulong rd_len = images->rd_end - images->rd_start;
>>> -
>>> - /*
>>> -* In case of legacy uImage's, relocation of ramdisk is already done
>>> -* by do_bootm_states() and should not repeated in 'bootm prep'.
>>> -*/
>>> - if (images->state & BOOTM_STATE_RAMDISK) {
>>> - debug("## Ramdisk already relocated\n");
>>> - return 0;
>>> - }
>>> -
>>> - return boot_ramdisk_high(>lmb, images->rd_start,
>>> - rd_len, >initrd_start, >initrd_end);
>>> -}
>>> -
>>> static int boot_reloc_fdt(bootm_headers_t *images)
>>> {
>>> /*
>>> @@ -270,8 +253,6 @@ static int boot_setup_fdt(bootm_headers_t *images)
>>>
>>> static void boot_prep_linux(bootm_headers_t *images)
>>> {
>>> - boot_reloc_ramdisk(images);
>>> -
>>> if (CONFIG_IS_ENABLED(MIPS_BOOT_FDT) && images->ft_len) {
>>> boot_reloc_fdt(images);
>>> boot_setup_fdt(images);
>>> --
>>> 2.7.4
>>>
>>
>> Combined with c2e7e72bb9f0cb47d024997b381cb64786eb5402 it looks right.
>> But could you please verify that following scenarios still work?
>>
>> - bootm uImage_legacy_addr initrd_addr
>> - bootm start uImage_legacy_addr initrd_addr + bootm loados ramdisk
>> fdt prep go (single step)
>> - bootm uImage_fit_addr
>> - bootm start uImage_fit_addr (single step) + bootm loados ramdisk fdt
>> prep go (single step)
>
> I tried all the above cases and all seems to work fine. I managed to
> start the linux kernel and it found the ramdisk. One observation
> in my case I used also a DT, but I don't see how this can influence the
> tests.
>
thanks for testing
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: mscc: ocelot: Fix reset of the phys
Am 12.03.19 um 10:23 schrieb Horatiu Vultur: > The function mscc_miim_reset resets all the phys, but it is called for > each phy separetely. One consequence of this is that the boot time > is increased by 2 seconds. > > The fix consists for calling the mscc_miim_reset function only once for > all phys. > > Signed-off-by: Horatiu Vultur > --- > drivers/net/mscc_eswitch/ocelot_switch.c | 27 ++- > 1 file changed, 10 insertions(+), 17 deletions(-) > Reviewed-by: Daniel Schwierzeck -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] mips: add missing dtb-y to arch/mips/dts/Makefile
Am 14.03.19 um 06:58 schrieb Masahiro Yamada:
> Since commit 27cb7300ffda ("Ensure device tree DTS is compiled"),
> build succeeds irrespective of the correctness of Makefile.
>
> In fact, you can compile any defconfig without adding any entry in
> arch/*/dts/Makefile.
>
> I am going to revert that commit, so device tree must be explicitly
> listed in Makefile.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> arch/mips/dts/Makefile | 5 +
> 1 file changed, 5 insertions(+)
>
Reviewed-by: Daniel Schwierzeck
--
- Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] Enable expression support for CONFIG_BOARD_SIZE_LIMIT
On 08/Mar/2019 18:28, Martin Husemann wrote: > On Fri, Mar 08, 2019 at 12:17:09PM -0500, Tom Rini wrote: > > OK, so a few thoughts here. > > - What's the portable way to do hex-based math? If we really need it? > > Use printf(3) to convert to/from hex, and standard shell arithmetic > with $(( )). > > Looks horrible, but something like: > > v=$(( $( printf "%d\n" 0xa0 ) + $( printf "%d\n" 0x10 ) )) > printf "v = %d (%x)\n" $v $v > > > ... maybe arranged into some sh helper functions. dash, bash, mksh, zsh, all ksh-compatible shells in fact, support hex numbers on arithmetic expressions, no need for conversion. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] ARM: meson: add p200 and p201 boards
Hi, Thanks for the reactivity ! On 14/03/2019 22:09, Mohammad Rasim wrote: > This adds support for p200 and p201 reference boards from amlogic > > Mohammad Rasim (3): > ARM: dts: meson: add p200 and p201 boards > ARM: board: meson: add p201 board > ARM: board: meson: add p200 board > > arch/arm/dts/Makefile | 2 + > arch/arm/dts/meson-gxbb-p200.dts| 99 +++ > arch/arm/dts/meson-gxbb-p201.dts| 26 +++ > arch/arm/dts/meson-gxbb-p20x.dtsi | 247 > board/amlogic/odroid-c2/MAINTAINERS | 1 + > board/amlogic/odroid-c2/README.p200 | 103 > board/amlogic/p201/MAINTAINERS | 5 + > board/amlogic/p201/Makefile | 5 + > board/amlogic/p201/README.p201 | 103 > board/amlogic/p201/p201.c | 43 + > configs/p200_defconfig | 41 + > configs/p201_defconfig | 41 + > 12 files changed, 716 insertions(+) > create mode 100644 arch/arm/dts/meson-gxbb-p200.dts > create mode 100644 arch/arm/dts/meson-gxbb-p201.dts > create mode 100644 arch/arm/dts/meson-gxbb-p20x.dtsi > create mode 100644 board/amlogic/odroid-c2/README.p200 > create mode 100644 board/amlogic/p201/MAINTAINERS > create mode 100644 board/amlogic/p201/Makefile > create mode 100644 board/amlogic/p201/README.p201 > create mode 100644 board/amlogic/p201/p201.c > create mode 100644 configs/p200_defconfig > create mode 100644 configs/p201_defconfig > > -- > 2.21.0 > Nearly perfect, but : - can you add a small text in the commits logs of patches 2 & 3 ? - can you add a patch adding arch/arm/dts/meson-gxbb-p200-u-boot.dtsi and arch/arm/dts/meson-gxbb-p201-u-boot.dtsi based on arch/arm/dts/meson-gx-u-boot.dtsi ? With these I'll take them ! Thanks, Neil ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [U-BOOT][PATCH V3] sunxi: Use clrsetbits_le32 instead of multiple instruction
From: Michael Trimarchi This will improve code readabilty Signed-off-by: Michael Trimarchi --- Changelogs: V1->V2: None V2->V3: Fix use of clrsetbits_le32 and setbits_le32 functions --- arch/arm/mach-sunxi/dram_sun8i_a33.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/arm/mach-sunxi/dram_sun8i_a33.c b/arch/arm/mach-sunxi/dram_sun8i_a33.c index 1da2727f9874..09742cbc2b55 100644 --- a/arch/arm/mach-sunxi/dram_sun8i_a33.c +++ b/arch/arm/mach-sunxi/dram_sun8i_a33.c @@ -148,11 +148,8 @@ static void auto_set_timing_para(struct dram_para *para) reg_val = (tcksrx << 24) | (tcksre << 16) | (tckesr << 8) | (tcke << 0); writel(reg_val, _ctl->dramtmg5); /* Set two rank timing and exit self-refresh timing */ - reg_val = readl(_ctl->dramtmg8); - reg_val &= ~(0xff << 8); - reg_val &= ~(0xff << 0); - reg_val |= (0x33 << 8); - reg_val |= (0x8 << 0); + clrsetbits_le32(_ctl->dramtmg8, (0xff << 8) | (0xff << 0)); + setbits_le32(_ctl->dramtmg8, (0x33 << 8) | (0x8 << 0)); writel(reg_val, _ctl->dramtmg8); /* Set phy interface time */ reg_val = (0x2 << 24) | (t_rdata_en << 16) | (0x1 << 8) -- 2.11.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] dfu: Avoid declaring unused variables and absent parameters
On Fri, 15 Mar 2019 11:23:38 +0200 Andy Shevchenko andy.shevche...@gmail.com wrote: ... > > I can only recommend using patman, which shall link the dfu: in topic > > with my e-mail address, > > It's pity that different projects based on Kbuild infra are using > different type of accessing to maintainers data base. > I have used get_maintainer.pl. get_maintainer.pl failed to report e-mail address since the dfu command code entry is not in the data base file. I've just sent a patch to fix it. -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Add dfu command entry to MAINTAINERS
get_maintainer.pl doesn't report the maintainer for dfu command code since its entry is not in the database file. Add it. Signed-off-by: Anatolij Gustschin Cc: Lukasz Majewski --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 4fabb75eda..f205d66155 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -441,6 +441,7 @@ DFU M: Lukasz Majewski S: Maintained T: git git://git.denx.de/u-boot-dfu.git +F: cmd/dfu.c F: drivers/dfu/ F: drivers/usb/gadget/ -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] passing info from SPL to U-Boot
Dear Simon, In message you wrote: > > I think it is a reasonable idea to allow the gd region to pass from > TPL -> SPL -> U-Boot. But we'll need to remove use of > CONFIG_IS_ENABLED(), or put shared things at the beginning of the > structure. Indeed. And/or split things up in "common" stuff and optional / config dependent things. > We need the concept of 'am I the first thing to run'. This is > implemented in bloblist as u_boot_first_phase() - see spl.h. If this > is true, we must set up the data structure. If false we must find one > set up by a previous phase and use it. Bloblist handles this, but > perhaps gd could as well? I wonder why we need 4 different ways of doing basically the same thing. First, we have GD, which exists since the dawn of U-Boot, which was intended to pass data between boot stages (by then, before and after relocation), but apparently it has never been used for passing information between SPL and U-Boot proper. Then you added the bloblist thingy. It's not really clear what it's intentions are - I see the commits, but I can't find what you want to use it for or what design you have in mind. It's too complicated for passing just a few data, but apparently you find it necessary to make it secure enough that you add version, magic and checksum (which makes it necessary to have CRC32 in SPL...). Also, I wonder how the search mechanism effects boot time... An then there is commit b0edea3c27 with the spl_handoff thing. I can't decide whether this is intended as a general feature or a separate, SPL specific mechanism. And more questions - if we pass the handoff pointer in GD, why all the effort - why don't we just make sure GD is passed properly? The fact that there is no use case at all in mainline U-Boot makes it really hard to understand your intentions. And finally there is bootstage with it's own mechanism of information passing. Can we not unify these, and use one common method, please? > Also consider the scenario where there is a read-only TPL programmed > in manufacture that never changes, and a read-write SPL + U-Boot that > can be upgraded in the field. In this case they may eventually end up > being built with different versions of U-Boot. The bloblist structure > is intended to handle this by at least checking that the size matches. You also have the version field there, right? Who not (also) checking this? > Related, I feel that we should figure out how to use registers to pass > addresses from SPL to U-Boot. On ARM we could use r0 to pass the value > of gd, perhaps. There is no need to. GD already has a well-defined register which has been reserved exclusively for this use - on ARM, it's R9. 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 Little known fact about Middle Earth: The Hobbits had a very sophi- sticated computer network! It was a Tolkien Ring... ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] dfu: Avoid declaring unused variables and absent parameters
On Fri, Mar 15, 2019 at 12:28 AM Lukasz Majewski wrote: > > On Thu, Mar 14, 2019 at 10:19:58PM +0200, Andy Shevchenko wrote: > > > Any comments on this? > > > > > > I don't know who is the right person to push this forward, please, > > > feel free to Cc to the right one, or tell me to resend with proper > > > Cc list. > > I can only recommend using patman, which shall link the dfu: in topic > with my e-mail address, It's pity that different projects based on Kbuild infra are using different type of accessing to maintainers data base. I have used get_maintainer.pl. > > Lukasz? > Regarding the patch, > > Acked-by: Lukasz Majewski > > If the travis doesn't complain, feel free to apply it. Thanks! -- With Best Regards, Andy Shevchenko ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] mips: mt76xx: gardena-smart-gateway: Correct spelling of GARDENA
This patch changes Gardena to the correct GARDENA spelling. Also the
platform name is "GARDENA smart Gateway". This patch changes the
incorrect occurrances.
Signed-off-by: Stefan Roese
Cc: Daniel Schwierzeck
---
arch/mips/dts/gardena-smart-gateway-mt7688.dts | 2 +-
arch/mips/mach-mt7620/Kconfig | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/mips/dts/gardena-smart-gateway-mt7688.dts
b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
index 75f6037e96..897064dd9c 100644
--- a/arch/mips/dts/gardena-smart-gateway-mt7688.dts
+++ b/arch/mips/dts/gardena-smart-gateway-mt7688.dts
@@ -10,7 +10,7 @@
/ {
compatible = "gardena,smart-gateway-mt7688", "ralink,mt7628a-soc";
- model = "Gardena smart-Gateway-MT7688";
+ model = "GARDENA smart Gateway (MT7688)";
aliases {
serial0 =
diff --git a/arch/mips/mach-mt7620/Kconfig b/arch/mips/mach-mt7620/Kconfig
index 4ebcb4b053..a983443999 100644
--- a/arch/mips/mach-mt7620/Kconfig
+++ b/arch/mips/mach-mt7620/Kconfig
@@ -22,12 +22,12 @@ choice
prompt "Board select"
config BOARD_GARDENA_SMART_GATEWAY_MT7688
- bool "Gardena Smart Gateway"
+ bool "GARDENA smart Gateway"
depends on SOC_MT7620
select BOARD_LATE_INIT
select SUPPORTS_BOOT_RAM
help
- Gardena Smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
+ GARDENA smart Gateway boards have a MT7688 SoC with 128 MiB of RAM
and 8 MiB of flash (SPI NOR) and additional SPI NAND storage.
config BOARD_LINKIT_SMART_7688
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq
Hi Christian, On Wed, Mar 13, 2019 at 5:27 PM Christian Gmeiner wrote: > > Hi all, > > Am Mo., 11. März 2019 um 15:41 Uhr schrieb Bin Meng : > > > > Hi Andy, > > > > On Wed, Mar 6, 2019 at 7:09 PM Andy Shevchenko > > wrote: > > > > > > On Thu, Feb 28, 2019 at 11:29:50AM +0800, Bin Meng wrote: > > > > On Thu, May 24, 2018 at 12:00 PM Bin Meng wrote: > > > > > On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner > > > > > wrote: > > > > > > > So to me this seems to match my understanding about EIST. If this is > > > > true, then I can't explain why Christian's patch is needed since the > > > > EIST is disabled on TunnelCreek by default and the processor should > > > > already run at the highest performance. > > > > > > The some internal documents I found suggesting that first what one needs > > > to do > > > is to be sure that EIST is enabled / disabled by reading a bit from CPUID. > > > > > > > Correct. This is documented in the public Intel SDM too. > > > > > (There is no mention of the exact bit, I'm guessing it might be > > > X86_FEATURE_EST) > > > > > > It also refers to IA32_MISC_ENABLE MSR, i.e. bit 20 > > > (MSR_IA32_MISC_ENABLE_SPEEDSTEP_LOCK_BIT) and bit 16 > > > (MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP_BIT), that firmware can set up > > > accordingly. > > > > > > Hope this helps. > > > > > > > Thanks for the help. But I was looking for clarification on what > > frequency the CPU is running at if EIST is disabled (the default > > power-up state). Especially I suspect the Intel CPU is running at the > > highest frequency when ESIT is disabled hence the highest performance. > > Such details are not documented in the public Intel SDM. :( > > > > > P.S. All names are implying Linux kernel source code. > > > > I think I need to clarify how I came to this patch. > > Back in the days when we used an Intel BLDK based BIOS solution we did > some performance > measurements and found out that the same device with an vendor BIOS is > much faster. So we started > to dig into the issue and used bandwidth to do our measurements. We > contacted Intel to get support > and after lot of ping-pong mails we got a solution. > > We need to set these two msr registers to the values they provided to us. > These msr register should be described in #29324. Could you please provide details about these 2 MSR registers? And is there any official document from Intel about what is the behavior of having EIST disabled? > > Bin do you have hardware to reproduce this issue I have and what gets > fixed with this patch? Yes, I have the hardware to test. Is the test case able to run in U-Boot? I can have a test. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
On 15. 03. 19 7:51, Simon Goldschmidt wrote: > On Fri, Mar 15, 2019 at 7:44 AM Michal Simek wrote: >> >> On 14. 03. 19 21:57, Simon Goldschmidt wrote: >>> This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51. >> >> You should also put subject of that patch here. It is much easier to >> check what was that. > > The subject of the commit is in the patch's subject line, isn't that enough? I missed that - it is fine. :-) It is Friday. Cheers, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
On Fri, Mar 15, 2019 at 7:44 AM Michal Simek wrote: > > On 14. 03. 19 21:57, Simon Goldschmidt wrote: > > This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51. > > You should also put subject of that patch here. It is much easier to > check what was that. The subject of the commit is in the patch's subject line, isn't that enough? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for UEFI system for v2019.04-rc4
The following changes since commit e8e3f2d2d48f97b2c79b698eccedce8f4f880993: Merge branch '2019-03-08-master-imports' (2019-03-08 18:04:13 -0500) are available in the Git repository at: https://github.com/xypron2/u-boot tag efi-2019-04-rc4-3 for you to fetch changes up to e616100eab84464f09baa93b3fe5c15087a385c1: efi_loader: fix build error for freestanding.o (2019-03-14 21:03:14 +0100) Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Fix an error with the serial communication on boards with a very small UART buffer which leads to a stalled system. Provide an X86 reset driver for the UEFI runtime. Fix a problem with parallel builds. Travis CI looks fine: https://travis-ci.org/xypron2/u-boot/builds/506462986 Alexander Graf (1): x86: Add efi runtime reset Heinrich Schuchardt (1): efi_loader: fix build error for freestanding.o Matthias Brugger (1): efi_loader: Fix serial console size detection drivers/sysreset/sysreset_x86.c | 23 ++- lib/efi_loader/efi_console.c| 62 +++--- lib/efi_selftest/efi_freestanding.c | 11 +++ scripts/Makefile.lib| 2 +- 4 files changed, 69 insertions(+), 29 deletions(-) create mode 100644 lib/efi_selftest/efi_freestanding.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT"
On 14. 03. 19 21:57, Simon Goldschmidt wrote: > This reverts commit 65a97e7fcf54feb7c4ebe1aee8a572830af4cf51. You should also put subject of that patch here. It is much easier to check what was that. M ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
