[U-Boot] [PATCH v3] tools: kwbimage: don't adjust for image_header for Armada MSYS
For the time being the Armada MSYS SoCs need to use the bin_hdr from the
Marvell U-Boot. Because of this the binary.0 does not contain the image
header that a proper u-boot SPL would so the adjustment introduced by
commit 94084eea3bd3 ("tools: kwbimage: Fix dest addr") does not apply.
Signed-off-by: Chris Packham
---
I'm just sending a v3 of this patch since the rest of the DB-XC3-24G4XG
series is unchanged.
Changes in v3:
- use the filename binary.0 to determine if the destaddr needs to match
execaddr.
Changes in v2:
- new, split out from Add DB-XC3-24G4XG board with a better explanation
tools/kwbimage.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index a88a3830c0c8..dffaf9043a04 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1273,6 +1273,13 @@ static void *image_create_v1(size_t *imagesz, struct
image_tool_params *params,
e = image_find_option(IMAGE_CFG_DEBUG);
if (e)
main_hdr->flags = e->debug ? 0x1 : 0;
+ e = image_find_option(IMAGE_CFG_BINARY);
+ if (e) {
+ char *s = strrchr(e->binary.file, '/');
+
+ if (strcmp(s, "/binary.0") == 0)
+ main_hdr->destaddr = cpu_to_le32(params->addr);
+ }
#if defined(CONFIG_KWB_SECURE)
if (image_get_csk_index() >= 0) {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
Hi "Y.b. Lu",
> Hi Lukasz,
>
> > -Original Message-
> > From: Lukasz Majewski
> > Sent: Monday, February 18, 2019 7:12 AM
> > To: Y.b. Lu
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
> >
> > Dear "Y.b. Lu",
> >
> > > The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
> > > initially. The later QoriQ series processors (which were
> > > evolutions of MPC83XX/MPC85XX) and i.MX series processors were
> > > using this driver for their eSDHCs too.
> > >
> > > So there are two evolution directions for eSDHC now. For the two
> > > series processors, the eSDHCs are becoming more and more
> > > different. We should have split it into two drivers, like them
> > > (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
> >
> > Why we cannot do it right just from the very beginning?
> >
> > In the end of the day we will try to mimic Linux kernel anyway,
> > IMHO it is better to start the split now and save some effort on a
> > half-step solution.
>
> [Y.b. Lu] I understand. The perfect way is to split them.
> However, if you grep 'CONFIG_FSL_ESDHC' in the whole u-boot source,
> you would find there are 607 results.
Those are boards, which use the driver. The modification would be done
in one or two files (fsl_esdhc.c|h).
> There will be so many companies
> boards affected.
I guess that the task of your patch set is to separate imx6q and ppc
specific code for those IP blocks.
> I just don't know who could make all of these boards
> tested.
Your patch set also makes some changes in the generic driver depending
on the priv->esdhc_imx flag. Those changes also need to be tested on
all before mentioned boards.
In the end you logically split the driver,
having it in a single file, which IMHO is not proper long-term solution.
>
> My current patch-set is also to cleaning up the driver waiting for
> splitting them someday on the other hand. After you check
> CONFIG_FSL_ESDHC in u-boot source, if you think it's better we should
> split them right now, I could work on the driver splitting.
You can think about having common part (in one file - fsl_esdhc.c) and
then separate files with code specific to imx and ppc. This would
reduce the number of changes needed.
>
> Thanks a lot.
>
> > > But it seemed
> > > to be a lot of work now. So let's keep as it is. Be very careful
> > > to change the driver if the changes are not common for all
> > > eSDHCs, and clarify i.MX eSDHC specific things to distingush them
> > > with QorIQ eSDHC.
> > >
> > > This patch is to added an esdhc_imx flag for the development of
> > > i.MX eSDHC, to distinguish it with QoriQ eSDHC.
> > >
> > > Signed-off-by: Yangbo Lu
> > > ---
> > > Changes for v2:
> > > - Converted to use device_is_compatible().
> > > ---
> > > drivers/mmc/fsl_esdhc.c | 11 +++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
> > > index 21fa2ab1d4..a647bc7f1c 100644
> > > --- a/drivers/mmc/fsl_esdhc.c
> > > +++ b/drivers/mmc/fsl_esdhc.c
> > > @@ -147,6 +147,7 @@ struct fsl_esdhc_priv {
> > > struct gpio_desc cd_gpio;
> > > struct gpio_desc wp_gpio;
> > > #endif
> > > + bool esdhc_imx;
> > > };
> > >
> > > /* Return the XFERTYP flags for a given command and data packet
> > > */ @@ -1462,6 +1463,16 @@ static int fsl_esdhc_probe(struct
> > > udevice *dev) priv->caps = data->caps;
> > > }
> > >
> > > + /*
> > > + * This is to specify whether current eSDHC is an i.MX
> > > eSDHC,
> > > + * since the i.MX eSDHC has been becoming more and more
> > > different
> > > + * with QorIQ eSDHC and initial MPC83XX/MPC85XX.
> > > + */
> > > + if (!device_is_compatible(dev, "fsl,esdhc"))
> > > + priv->esdhc_imx = true;
> > > + else
> > > + priv->esdhc_imx = false;
> > > +
> > > val = dev_read_u32_default(dev, "bus-width", -1);
> > > if (val == 8)
> > > priv->bus_width = 8;
> >
> >
> >
> >
> > 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
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
pgpBL2nsKmIlp.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] February community conf call minutes
Hello Tom, Am 19.02.2019 um 00:53 schrieb Tom Rini: Hey all, While I'm not the best at taking notes, and for next time I'll see how badly the record function slows down my connection, here's my notes / action items from the call: - Attendees: Myself, Philipp Tomsich, Michal Simek, Stefano Babic, Vignesh R, Jagan Teki, Lokesh Vutla, Matthias Brugger, Masahiro Yamada. - Talked about more automated testing, ala kernelci. I noted that we have travis-ci setup, and with test.py that runs on on qemu on a number of platforms. With respect to real hardware, I run mine on a handful of TI platforms and RPi 3 (I've tried sunxi before, but had power vampire problems, and imx6, but my platform wasn't supported in SPL at the time). Michal noted he has a setup for some of his platforms. I also have/had a running testsetup with tbot, see: http://xeidos.ddns.net/tests/test_db_auslesen.php#987 But as you see, dead for newer tests, as I had no time to fixup the at91 boards for example, for which wdt is broken. Yeah, testing *is* a time consuming task, as you always find something, which does not work. I just can vote for using tbot, added Harald Seiler to cc, as he rewrote tbot completly in python 3.6, see [1] and [2], feel free to take a look at it. I really like the interactive testcases for U-Boot and linux ... you start tbot and you are on the boards U-Boot or linux commandline ... I start for example test/py with tbot, or on the U-Boot commandline the "ut all" command if enabled (or enable the ut command with tbot before compiling U-Boot). You do not need to have the boards you want to test near you, it could be around the world (in my case I run tbot and the above webpage on a raspberry pi in hungary, while the boards I test are in munich/germany) The "problem" with tbot is, that it activly opens a ssh connection to a so called Lab Host see [3] and a lot of customers do not allow to use this for automated testing purposes ... But I talked with Kevin Hillman some months ago, and he mentioned that it should be possible to run kernelci without LAVA, so may it is worth to look into kernelci and use it for "ubootci" purposes. Than we would have an API for reporting testresults, and can start for example tbot locally without the need of an ssh connection. It should be easy than to generate a testreport for kernelci with a tbot generator, see [4] for generator examples. I am sorry that I did not found time yet, for more investigations... And customers are more willing to send testresults to us instead to allow ssh access for testing... hopefully. bye, Heiko [1] https://github.com/Rahix/tbot [2] https://rahix.de/tbot/getting-started.html [3] https://rahix.de/tbot/index.html [4] https://github.com/Rahix/tbot/tree/master/generators -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] arm: mvebu: Add DB-XC3-24G4XG board
On 15.02.19 23:49, Chris Packham wrote: From: Chris Packham The DB-XC3-24G4XG is a switch development board from Marvell. It can either use and external CPU card such as the db-88f6820-amc or the internal CPU that is integrated into the switch. Add support for running U-Boot on the internal CPU and enable the USB, SPI and NAND peripherals. For now this needs the bin_hdr from the Marvell U-Boot for this board. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] arm: mvebu: NAND clock support for MSYS devices
On 15.02.19 23:49, Chris Packham wrote: One difference with the integrated CPUs is that they use a different clock control block to the Armada devices. Update mvebu_get_nand_clock() accordingly. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] arm: mvebu: Add Marvell's integrated CPUs
On 15.02.19 23:48, Chris Packham wrote: Marvell's switch chips with integrated CPUs (collectively referred to as MSYS) share common ancestry with the Armada SoCs. Some of the IP blocks (e.g. xor) are located at different addresses and DFX server exists as a separate target on the MBUS (on Armada-38x it's just part of the core complex registers). Signed-off-by: Chris Packham Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] arm: sync armada-xp dts files from Linux 5.0
On 15.02.19 23:48, Chris Packham wrote: Bring in the Armada 370/XP dts/dtsi files from Linux. As U-Boot hasn't got the new NAND driver the updating binding has not been included. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] tools: kwbimage: don't adjust for image_header for Armada MSYS
Hi Chris,
On 18.02.19 23:23, Chris Packham wrote:
On Mon, Feb 18, 2019 at 8:13 PM Stefan Roese wrote:
Hi Chris,
On 15.02.19 23:49, Chris Packham wrote:
For the time being the Armada MSYS SoCs need to use the bin_hdr from the
Marvell U-Boot. Because of this the binary.0 does not contain the image
header that a proper u-boot SPL would so the adjustment introduced by
commit 94084eea3bd3 ("tools: kwbimage: Fix dest addr") does not apply.
Thanks for the explanation. I'm wondering if it would be better (if
possible) to auto detect this situation of using a bin_hdr from Marvell
vs U-Boot SPL instead in this tool. This would help especially if we
have full DDR init support in mainline U-Boot for this SoC at some
time, as we then need to differentiate between those two options for
this SoC.
Would this be possible?
One way would be to check the filename, binary.0 means don't adjust it
whereas u-boot-spl.img does. I also considered modifying the process
to create binary.0 to prepend sizeof(image_header_t) bytes to allow it
to work but I went with the quickest option for me to implement.
If it's an acceptable solution the filename thing would be quite easy
to implement. Adding a flag or parameter in the kwbimage.cfg would
also be relatively easy.
I'm okay with using the filename to decide here. Please go ahead with
this change and perhaps add a warning / error, if none of the standard
names is provided (u-boot-spl.* vs binary.0).
Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Convert Gen2 Stout, Porter, Silk to DM_SPI{, _FLASH}
Enable DM_SPI and DM_SPI_FLASH in U-Boot on H2 Stout, M2W Porter and E3 Silk. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- configs/porter_defconfig | 2 ++ configs/silk_defconfig | 2 ++ configs/stout_defconfig | 2 ++ 3 files changed, 6 insertions(+) diff --git a/configs/porter_defconfig b/configs/porter_defconfig index ce309b6d86..826f78bb42 100644 --- a/configs/porter_defconfig +++ b/configs/porter_defconfig @@ -62,6 +62,7 @@ CONFIG_DM_MMC=y CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y @@ -79,6 +80,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_SCIF_CONSOLE=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_SH_QSPI=y CONFIG_USB=y CONFIG_DM_USB=y diff --git a/configs/silk_defconfig b/configs/silk_defconfig index 0291a7c981..09196d7bb8 100644 --- a/configs/silk_defconfig +++ b/configs/silk_defconfig @@ -64,6 +64,7 @@ CONFIG_SH_MMCIF=y CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y @@ -81,6 +82,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_SCIF_CONSOLE=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_SH_QSPI=y CONFIG_USB=y CONFIG_DM_USB=y diff --git a/configs/stout_defconfig b/configs/stout_defconfig index 1c92cb6117..552cf55df5 100644 --- a/configs/stout_defconfig +++ b/configs/stout_defconfig @@ -62,6 +62,7 @@ CONFIG_DM_MMC=y CONFIG_RENESAS_SDHI=y CONFIG_MTD=y CONFIG_MTD_DEVICE=y +CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_SPANSION=y CONFIG_SPI_FLASH_MTD=y @@ -79,6 +80,7 @@ CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_REGULATOR_GPIO=y CONFIG_SCIF_CONSOLE=y CONFIG_SPI=y +CONFIG_DM_SPI=y CONFIG_SH_QSPI=y CONFIG_USB=y CONFIG_DM_USB=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: dts: rmobile: Force 1-bit bus width on Gen2 QSPI
U-Boot currently uses Gen2 QSPI in 1-bit mode, enforce it until
we can do better using the new SPI NOR framework.
Signed-off-by: Marek Vasut
Cc: Nobuhiro Iwamatsu
---
arch/arm/dts/r8a7790-lager-u-boot.dts | 7 +++
arch/arm/dts/r8a7790-stout-u-boot.dts | 7 +++
arch/arm/dts/r8a7791-koelsch-u-boot.dts | 7 +++
arch/arm/dts/r8a7791-porter-u-boot.dts | 7 +++
arch/arm/dts/r8a7793-gose-u-boot.dts| 7 +++
arch/arm/dts/r8a7794-alt-u-boot.dts | 7 +++
arch/arm/dts/r8a7794-silk-u-boot.dts| 7 +++
7 files changed, 49 insertions(+)
diff --git a/arch/arm/dts/r8a7790-lager-u-boot.dts
b/arch/arm/dts/r8a7790-lager-u-boot.dts
index 8a37cb9d9a..fecf7e77ae 100644
--- a/arch/arm/dts/r8a7790-lager-u-boot.dts
+++ b/arch/arm/dts/r8a7790-lager-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7790-stout-u-boot.dts
b/arch/arm/dts/r8a7790-stout-u-boot.dts
index 47982652e8..1396764d32 100644
--- a/arch/arm/dts/r8a7790-stout-u-boot.dts
+++ b/arch/arm/dts/r8a7790-stout-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7791-koelsch-u-boot.dts
b/arch/arm/dts/r8a7791-koelsch-u-boot.dts
index 85a5290079..4a98528099 100644
--- a/arch/arm/dts/r8a7791-koelsch-u-boot.dts
+++ b/arch/arm/dts/r8a7791-koelsch-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7791-porter-u-boot.dts
b/arch/arm/dts/r8a7791-porter-u-boot.dts
index 275f6b4375..82051be824 100644
--- a/arch/arm/dts/r8a7791-porter-u-boot.dts
+++ b/arch/arm/dts/r8a7791-porter-u-boot.dts
@@ -16,3 +16,10 @@
status = "okay";
clock-frequency = <40>;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7793-gose-u-boot.dts
b/arch/arm/dts/r8a7793-gose-u-boot.dts
index d8e072c36b..a35d35c335 100644
--- a/arch/arm/dts/r8a7793-gose-u-boot.dts
+++ b/arch/arm/dts/r8a7793-gose-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7794-alt-u-boot.dts
b/arch/arm/dts/r8a7794-alt-u-boot.dts
index e6ef23dda3..593a418c3b 100644
--- a/arch/arm/dts/r8a7794-alt-u-boot.dts
+++ b/arch/arm/dts/r8a7794-alt-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
diff --git a/arch/arm/dts/r8a7794-silk-u-boot.dts
b/arch/arm/dts/r8a7794-silk-u-boot.dts
index 0e104aa139..179753d7cf 100644
--- a/arch/arm/dts/r8a7794-silk-u-boot.dts
+++ b/arch/arm/dts/r8a7794-silk-u-boot.dts
@@ -11,3 +11,10 @@
{
u-boot,dm-pre-reloc;
};
+
+ {
+ flash@0 {
+ spi-tx-bus-width = <1>;
+ spi-rx-bus-width = <1>;
+ };
+};
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] spi: sh_qspi: Replace CONFIG_DM_SPI with CONFIG_IS_ENABLED(DM_SPI)
Perform the replacement to allow platforms use non-DM SPI flash access
in SPL/TPL. This is thus far needed on platforms with size constraints.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Nobuhiro Iwamatsu
---
drivers/spi/sh_qspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
index 5ae203d8d4..549881f386 100644
--- a/drivers/spi/sh_qspi.c
+++ b/drivers/spi/sh_qspi.c
@@ -222,7 +222,7 @@ static int sh_qspi_xfer_common(struct sh_qspi_slave *ss,
unsigned int bitlen,
return ret;
}
-#ifndef CONFIG_DM_SPI
+#if !CONFIG_IS_ENABLED(DM_SPI)
static inline struct sh_qspi_slave *to_sh_qspi(struct spi_slave *slave)
{
return container_of(slave, struct sh_qspi_slave, slave);
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] treewide: Replace CONFIG_DM_SPI_FLASH with CONFIG_IS_ENABLED(DM_SPI_FLASH)
Perform the replacement to allow platforms use non-DM SPI flash access
in SPL/TPL. This is thus far needed on platforms with size constraints.
Signed-off-by: Marek Vasut
Cc: Jagan Teki
Cc: Vignesh R
---
cmd/sf.c | 4 ++--
drivers/mtd/spi/sf_probe.c | 2 +-
drivers/net/fm/fm.c| 4 ++--
env/sf.c | 2 +-
include/spi_flash.h| 2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/cmd/sf.c b/cmd/sf.c
index 738ef0e46d..7e92a43b2c 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -84,7 +84,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
struct udevice *new, *bus_dev;
int ret;
/* In DM mode defaults will be taken from DT */
@@ -119,7 +119,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
return -1;
}
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
/* Remove the old device, otherwise probe will just be a nop */
ret = spi_find_bus_and_cs(bus, cs, _dev, );
if (!ret) {
diff --git a/drivers/mtd/spi/sf_probe.c b/drivers/mtd/spi/sf_probe.c
index 7f1378f494..4282d48f26 100644
--- a/drivers/mtd/spi/sf_probe.c
+++ b/drivers/mtd/spi/sf_probe.c
@@ -53,7 +53,7 @@ err_read_id:
return ret;
}
-#ifndef CONFIG_DM_SPI_FLASH
+#if !CONFIG_IS_ENABLED(DM_SPI_FLASH)
struct spi_flash *spi_flash_probe(unsigned int busnum, unsigned int cs,
unsigned int max_hz, unsigned int spi_mode)
{
diff --git a/drivers/net/fm/fm.c b/drivers/net/fm/fm.c
index e19ddc..6a5c9bbc9d 100644
--- a/drivers/net/fm/fm.c
+++ b/drivers/net/fm/fm.c
@@ -377,7 +377,7 @@ int fm_init_common(int index, struct ccsr_fman *reg)
addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
int ret = 0;
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
struct udevice *new;
/* speed and mode will be read from DT */
@@ -464,7 +464,7 @@ int fm_init_common(int index, struct ccsr_fman *reg)
void *addr = malloc(CONFIG_SYS_QE_FMAN_FW_LENGTH);
int ret = 0;
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
struct udevice *new;
/* speed and mode will be read from DT */
diff --git a/env/sf.c b/env/sf.c
index b3dec82c35..ee639b90fc 100644
--- a/env/sf.c
+++ b/env/sf.c
@@ -52,7 +52,7 @@ static struct spi_flash *env_flash;
static int setup_flash_device(void)
{
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
struct udevice *new;
int ret;
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 7f691e8559..09f3896fb9 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -51,7 +51,7 @@ struct dm_spi_flash_ops {
/* Access the serial operations for a device */
#define sf_get_ops(dev) ((struct dm_spi_flash_ops *)(dev)->driver->ops)
-#ifdef CONFIG_DM_SPI_FLASH
+#if CONFIG_IS_ENABLED(DM_SPI_FLASH)
/**
* spi_flash_read_dm() - Read data from SPI flash
*
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
Hi Lukasz,
> -Original Message-
> From: Lukasz Majewski
> Sent: Monday, February 18, 2019 7:12 AM
> To: Y.b. Lu
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [v2, 1/3] mmc: fsl_esdhc: add esdhc_imx flag
>
> Dear "Y.b. Lu",
>
> > The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
> > initially. The later QoriQ series processors (which were evolutions of
> > MPC83XX/MPC85XX) and i.MX series processors were using this driver for
> > their eSDHCs too.
> >
> > So there are two evolution directions for eSDHC now. For the two
> > series processors, the eSDHCs are becoming more and more different.
> > We should have split it into two drivers, like them
> > (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
>
> Why we cannot do it right just from the very beginning?
>
> In the end of the day we will try to mimic Linux kernel anyway, IMHO it is
> better to start the split now and save some effort on a half-step solution.
>
[Y.b. Lu] I understand. The perfect way is to split them.
However, if you grep 'CONFIG_FSL_ESDHC' in the whole u-boot source, you would
find there are 607 results.
There will be so many companies boards affected. I just don't know who could
make all of these boards tested.
My current patch-set is also to cleaning up the driver waiting for splitting
them someday on the other hand.
After you check CONFIG_FSL_ESDHC in u-boot source, if you think it's better we
should split them right now, I could work on the driver splitting.
Thanks a lot.
> > But it seemed
> > to be a lot of work now. So let's keep as it is. Be very careful to
> > change the driver if the changes are not common for all eSDHCs, and
> > clarify i.MX eSDHC specific things to distingush them with QorIQ
> > eSDHC.
> >
> > This patch is to added an esdhc_imx flag for the development of i.MX
> > eSDHC, to distinguish it with QoriQ eSDHC.
> >
> > Signed-off-by: Yangbo Lu
> > ---
> > Changes for v2:
> > - Converted to use device_is_compatible().
> > ---
> > drivers/mmc/fsl_esdhc.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index
> > 21fa2ab1d4..a647bc7f1c 100644
> > --- a/drivers/mmc/fsl_esdhc.c
> > +++ b/drivers/mmc/fsl_esdhc.c
> > @@ -147,6 +147,7 @@ struct fsl_esdhc_priv {
> > struct gpio_desc cd_gpio;
> > struct gpio_desc wp_gpio;
> > #endif
> > + bool esdhc_imx;
> > };
> >
> > /* Return the XFERTYP flags for a given command and data packet */ @@
> > -1462,6 +1463,16 @@ static int fsl_esdhc_probe(struct udevice *dev)
> > priv->caps = data->caps;
> > }
> >
> > + /*
> > +* This is to specify whether current eSDHC is an i.MX eSDHC,
> > +* since the i.MX eSDHC has been becoming more and more
> > different
> > +* with QorIQ eSDHC and initial MPC83XX/MPC85XX.
> > +*/
> > + if (!device_is_compatible(dev, "fsl,esdhc"))
> > + priv->esdhc_imx = true;
> > + else
> > + priv->esdhc_imx = false;
> > +
> > val = dev_read_u32_default(dev, "bus-width", -1);
> > if (val == 8)
> > priv->bus_width = 8;
>
>
>
>
> 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
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 6/7] ARM: socfpga: Synchronize the configuration for A10 SoCDK
From: Tien Fong Chee Update the default configuration file to enable the necessary functionality the get the kit working. Signed-off-by: Tien Fong Chee --- changes for v8 - Moved the FIT related configs to the patch of configuration for FPGA SoCFPGA A10 SoCDK. changes for v7 - Keep minimal configs. --- configs/socfpga_arria10_defconfig | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index c870543..bdbf90e 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -10,10 +10,13 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="console=ttyS0,115200" # CONFIG_USE_BOOTCOMMAND is not set +CONFIG_SYS_CONSOLE_IS_IN_ENV=y +CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y +CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y CONFIG_DEFAULT_FDT_FILE="socfpga_arria10_socdk_sdmmc.dtb" +CONFIG_VERSION_VARIABLE=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_SPL_FPGA_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_CMD_ASKENV=y CONFIG_CMD_GREPENV=y # CONFIG_CMD_FLASH is not set @@ -22,9 +25,7 @@ CONFIG_CMD_MMC=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" -# CONFIG_SPL_DOS_PARTITION is not set -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set +CONFIG_OF_SPL_REMOVE_PROPS="interrupts interrupt-parent dmas dma-names" CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y CONFIG_SPL_ENV_SUPPORT=y @@ -32,7 +33,6 @@ CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_DM_MMC=y CONFIG_SPL_MMC_SUPPORT=y -CONFIG_SPL_EXT_SUPPORT=y CONFIG_SPL_FS_FAT=y CONFIG_SPL_DRIVERS_MISC_SUPPORT=y CONFIG_FS_LOADER=y @@ -43,11 +43,14 @@ CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y CONFIG_DM_MMC=y CONFIG_MTD_DEVICE=y +CONFIG_MMC_DW=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y CONFIG_DM_ETH=y CONFIG_ETH_DESIGNWARE=y CONFIG_MII=y +CONFIG_SYS_NS16550=y CONFIG_SPI=y CONFIG_TIMER=y CONFIG_SPL_TIMER=y CONFIG_DESIGNWARE_APB_TIMER=y -CONFIG_USE_TINY_PRINTF=y -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 5/7] spl : socfpga: Implement fpga bitstream loading with socfpga loadfs
From: Tien Fong Chee
Add support for loading FPGA bitstream to get DDR up running before
U-Boot is loaded into DDR. Boot device initialization, generic firmware
loader and SPL FAT support are required for this whole mechanism to work.
Signed-off-by: Tien Fong Chee
---
changes for v9
- Used ALLOC_CACHE_ALIGN_BUFFER
- De-duplicated the same chunks of codes
changes for v7
- Removed casting for get_fpga_filename
- Removed hard coding DDR address for loading core bistream, using loadable
property from FIT.
- Added checking for config_pins, return if error.
---
arch/arm/mach-socfpga/spl_a10.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index c97eacb..4b658c8 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright (C) 2012 Altera Corporation
+ * Copyright (C) 2012-2019 Altera Corporation
*/
#include
@@ -23,6 +23,11 @@
#include
#include
#include
+#include
+#include
+#include
+
+#define FPGA_BUFSIZ16 * 1024
DECLARE_GLOBAL_DATA_PTR;
@@ -68,11 +73,35 @@ u32 spl_boot_mode(const u32 boot_device)
void spl_board_init(void)
{
+ ALLOC_CACHE_ALIGN_BUFFER(char, buf, FPGA_BUFSIZ);
+
/* enable console uart printing */
preloader_console_init();
WATCHDOG_RESET();
arch_early_init_r();
+
+ /* If the full FPGA is already loaded, ie.from EPCQ, config fpga pins */
+ if (is_fpgamgr_user_mode()) {
+ int ret = config_pins(gd->fdt_blob, "shared");
+
+ if (ret)
+ return;
+
+ ret = config_pins(gd->fdt_blob, "fpga");
+ if (ret)
+ return;
+ } else if (!is_fpgamgr_early_user_mode()) {
+ /* Program IOSSM(early IO release) or full FPGA */
+ fpgamgr_program(buf, FPGA_BUFSIZ, 0);
+ }
+
+ /* If the IOSSM/full FPGA is already loaded, start DDR */
+ if (is_fpgamgr_early_user_mode() || is_fpgamgr_user_mode())
+ ddr_calibration_sequence();
+
+ if (!is_fpgamgr_user_mode())
+ fpgamgr_program(buf, FPGA_BUFSIZ, 0);
}
void board_init_f(ulong dummy)
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 7/7] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL
From: Tien Fong Chee After some series of patches to maximise reusable of memory pool, here come to result of reasonable size required for whole SDMMC boot working on A10 SoCDK. Size required come from default max cluster(0x1) + others(0x2000) + additional memory for headroom(0x3000). Signed-off-by: Tien Fong Chee --- changes for v7 - Added 0x3000 for memory headroom. --- include/configs/socfpga_common.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h index 4551cb2..548b458 100644 --- a/include/configs/socfpga_common.h +++ b/include/configs/socfpga_common.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2012 Altera Corporation + * Copyright (C) 2012-2019 Altera Corporation */ #ifndef __CONFIG_SOCFPGA_COMMON_H__ #define __CONFIG_SOCFPGA_COMMON_H__ @@ -258,7 +258,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void); #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_SIZE 0x00015000 #define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \ CONFIG_SYS_SPL_MALLOC_SIZE + \ CONFIG_SYS_INIT_RAM_ADDR) -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 3/7] ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading
From: Tien Fong Chee
Add FPGA driver to support program FPGA with FPGA bitstream loading from
filesystem. The driver are designed based on generic firmware loader
framework. The driver can handle FPGA program operation from loading FPGA
bitstream in flash to memory and then to program FPGA.
Signed-off-by: Tien Fong Chee
---
changes for v9
- Support data offset
- Added default DDR load address
- Squashed the image.h
- Changed to phandle
- Ensure the DDR is fully up running by checking the gd->ram
changes for v8
- Added codes to discern bitstream type based on fpga node name.
changes for v7
- Restructure the FPGA driver to support both peripheral bitstream and core
bitstream bundled into FIT image.
- Support loadable property for core bitstream. User can set loadable
in DDR for better performance. This loading would be done in one large
chunk instead of chunk by chunk loading with small memory buffer.
---
arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 +
.../include/mach/fpga_manager_arria10.h| 40 +-
drivers/fpga/socfpga_arria10.c | 533 -
include/image.h| 4 +
4 files changed, 571 insertions(+), 23 deletions(-)
diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
index 998d811..9d43111 100644
--- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
+++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
@@ -18,6 +18,23 @@
/dts-v1/;
#include "socfpga_arria10_socdk.dtsi"
+/ {
+ chosen {
+ firmware-loader = <_loader0>;
+ };
+
+ fs_loader0: fs-loader@0 {
+ u-boot,dm-pre-reloc;
+ compatible = "u-boot,fs-loader";
+ phandlepart = < 1>;
+ };
+};
+
+_mgr {
+ u-boot,dm-pre-reloc;
+ altr,bitstream = "fit_spl_fpga.itb";
+};
+
{
u-boot,dm-pre-reloc;
status = "okay";
diff --git a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
index 09d13f6..7a4f723 100644
--- a/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/fpga_manager_arria10.h
@@ -1,9 +1,13 @@
/* SPDX-License-Identifier: GPL-2.0 */
/*
- * Copyright (C) 2017 Intel Corporation
+ * Copyright (C) 2017-2019 Intel Corporation
* All rights reserved.
*/
+#include
+#include
+#include
+
#ifndef _FPGA_MANAGER_ARRIA10_H_
#define _FPGA_MANAGER_ARRIA10_H_
@@ -51,6 +55,10 @@
#define ALT_FPGAMGR_IMGCFG_CTL_02_CFGWIDTH_SET_MSK BIT(24)
#define ALT_FPGAMGR_IMGCFG_CTL_02_CDRATIO_LSB 16
+#define FPGA_SOCFPGA_A10_RBF_UNENCRYPTED 0xa65c
+#define FPGA_SOCFPGA_A10_RBF_ENCRYPTED 0xa65d
+#define FPGA_SOCFPGA_A10_RBF_PERIPH0x0001
+#define FPGA_SOCFPGA_A10_RBF_CORE 0x8001
#ifndef __ASSEMBLY__
struct socfpga_fpga_manager {
@@ -88,12 +96,40 @@ struct socfpga_fpga_manager {
u32 imgcfg_fifo_status;
};
+enum rbf_type {
+ unknown,
+ periph_section,
+ core_section
+};
+
+enum rbf_security {
+ invalid,
+ unencrypted,
+ encrypted
+};
+
+struct rbf_info {
+ enum rbf_type section;
+ enum rbf_security security;
+};
+
+struct fpga_loadfs_info {
+ fpga_fs_info *fpga_fsinfo;
+ u32 remaining;
+ u32 offset;
+ struct rbf_info rbfinfo;
+};
+
/* Functions */
int fpgamgr_program_init(u32 * rbf_data, size_t rbf_size);
int fpgamgr_program_finish(void);
int is_fpgamgr_user_mode(void);
int fpgamgr_wait_early_user_mode(void);
-
+int is_fpgamgr_early_user_mode(void);
+const char *get_fpga_filename(const void *fdt, int *len);
+int socfpga_loadfs(fpga_fs_info *fpga_fsinfo, const void *buf, size_t bsize,
+ u32 offset);
+void fpgamgr_program(const void *buf, size_t bsize, u32 offset);
#endif /* __ASSEMBLY__ */
#endif /* _FPGA_MANAGER_ARRIA10_H_ */
diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c
index 114dd91..9936b69 100644
--- a/drivers/fpga/socfpga_arria10.c
+++ b/drivers/fpga/socfpga_arria10.c
@@ -1,8 +1,7 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2017 Intel Corporation
+ * Copyright (C) 2017-2019 Intel Corporation
*/
-
#include
#include
#include
@@ -10,8 +9,11 @@
#include
#include
#include
+#include
#include
+#include
#include
+#include
#include
#include
@@ -21,6 +23,9 @@
#define COMPRESSION_OFFSET 229
#define FPGA_TIMEOUT_MSEC 1000 /* timeout in ms */
#define FPGA_TIMEOUT_CNT 0x100
+#define DEFAULT_DDR_LOAD_ADDRESS 0x400
+
+DECLARE_GLOBAL_DATA_PTR;
static const struct socfpga_fpga_manager *fpga_manager_base =
(void *)SOCFPGA_FPGAMGRREGS_ADDRESS;
@@ -64,7 +69,7 @@ static int wait_for_user_mode(void)
1, FPGA_TIMEOUT_MSEC, false);
}
-static int is_fpgamgr_early_user_mode(void)
+int
[U-Boot] [PATCH v9 4/7] ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK
From: Tien Fong Chee Update the default configuration file to enable the necessary functionality to get the SoCFPGA loadfs driver support. This would enable the implementation of programming bitstream into FPGA from MMC. Signed-off-by: Tien Fong Chee --- changes for v8 - Added FIT related configs changes for v7 - Removed limit set for CONFIG_FS_FAT_MAX_CLUSTSIZE --- configs/socfpga_arria10_defconfig | 8 1 file changed, 8 insertions(+) diff --git a/configs/socfpga_arria10_defconfig b/configs/socfpga_arria10_defconfig index 0554f1b..c870543 100644 --- a/configs/socfpga_arria10_defconfig +++ b/configs/socfpga_arria10_defconfig @@ -27,10 +27,18 @@ CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0" # CONFIG_EFI_PARTITION is not set CONFIG_DEFAULT_DEVICE_TREE="socfpga_arria10_socdk_sdmmc" CONFIG_ENV_IS_IN_MMC=y +CONFIG_SPL_ENV_SUPPORT=y CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_DM_MMC=y +CONFIG_SPL_MMC_SUPPORT=y +CONFIG_SPL_EXT_SUPPORT=y CONFIG_SPL_FS_FAT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_FS_LOADER=y CONFIG_FPGA_SOCFPGA=y +CONFIG_SPL_FIT=y +CONFIG_FIT=y CONFIG_DM_GPIO=y CONFIG_DWAPB_GPIO=y CONFIG_DM_MMC=y -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 2/7] ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK
From: Tien Fong Chee
Add default fitImage file bundling FPGA bitstreams for Arria10.
Signed-off-by: Tien Fong Chee
---
changes for v8
- Reordered the images and fpga configurations.
- Removed the load property at core image.
changes for v8
- Changed the FPGA node name to fpga-core and fpga-periph for both core and
periph bitstreams respectively.
---
board/altera/arria10-socdk/fit_spl_fpga.its | 38 +
1 file changed, 38 insertions(+)
create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its
diff --git a/board/altera/arria10-socdk/fit_spl_fpga.its
b/board/altera/arria10-socdk/fit_spl_fpga.its
new file mode 100644
index 000..df84562
--- /dev/null
+++ b/board/altera/arria10-socdk/fit_spl_fpga.its
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0
+ /*
+ * Copyright (C) 2019 Intel Corporation
+ *
+ */
+
+/dts-v1/;
+
+/ {
+ description = "FIT image with FPGA bistream";
+ #address-cells = <1>;
+
+ images {
+ fpga-periph@1 {
+ description = "FPGA peripheral bitstream";
+ data = /incbin/("../../../ghrd_10as066n2.periph.rbf");
+ type = "fpga";
+ arch = "arm";
+ compression = "none";
+ };
+
+ fpga-core@2 {
+ description = "FPGA core bitstream";
+ data = /incbin/("../../../ghrd_10as066n2.core.rbf");
+ type = "fpga";
+ arch = "arm";
+ compression = "none";
+ };
+ };
+
+ configurations {
+ default = "config-1";
+ config-1 {
+ description = "Boot with FPGA early IO release config";
+ fpga = "fpga-periph@1", "fpga-core@2";
+ };
+ };
+};
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 1/7] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10
From: Tien Fong Chee
This patch adds description on properties about file name used for both
peripheral bitstream and core bitstream.
Signed-off-by: Tien Fong Chee
---
changes for v8
- Removed explanation about support for altr,bitstream-core
changes for v7
- Provided example of setting FPGA FIT image for both early IO release
and full release FPGA configuration.
---
.../fpga/altera-socfpga-a10-fpga-mgr.txt | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
index 2fd8e7a..da210bf 100644
--- a/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
+++ b/doc/device-tree-bindings/fpga/altera-socfpga-a10-fpga-mgr.txt
@@ -7,8 +7,31 @@ Required properties:
- The second index is for writing FPGA configuration data.
- resets : Phandle and reset specifier for the device's reset.
- clocks : Clocks used by the device.
+- altr,bitstream : Fit image file name for both FPGA peripheral bitstream,
+ FPGA core bitstream and full bitstream.
-Example:
+ Full bitstream, consist of peripheral bitstream and core
+ bitstream.
+
+ FPGA peripheral bitstream is used to initialize FPGA IOs,
+ PLL, IO48 and DDR. This bitstream is required to get DDR up
+ running.
+
+ FPGA core bitstream contains FPGA design which is used to
+ program FPGA CRAM and ERAM.
+
+Example: Bundles both peripheral bitstream and core bitstream into FIT image
+called fit_spl_fpga.itb. This FIT image can be created through running
+this command: tools/mkimage
+ -E -p 400
+ -f board/altera/arria10-socdk/fit_spl_fpga.its
+ fit_spl_fpga.itb
+
+For details of describing structure and contents of the FIT image,
+please refer board/altera/arria10-socdk/fit_spl_fpga.its
+
+- Examples for booting with full release or booting with early IO release, then
+ follow by entering early user mode:
fpga_mgr: fpga-mgr@ffd03000 {
compatible = "altr,socfpga-a10-fpga-mgr";
@@ -16,4 +39,5 @@ Example:
0xffcfe400 0x20>;
clocks = <_mp_clk>;
resets = < FPGAMGR_RESET>;
+ altr,bitstream = "fit_spl_fpga.itb";
};
--
2.2.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v9 0/7] Add support for loading FPGA bitstream
From: Tien Fong Chee This version mainly resolved comments from Marek in [v8]. This series is working on top of u-boot.git - http://git.denx.de/u-boot.git . These patches are required before applying this series of patches 1. [U-Boot,v4] misc: fs_loader: Add support for initializing block device https://patchwork.ozlabs.org/project/uboot/list/?series=89282 (done review) 2 a. [U-Boot,v3,1/2] fs: fat: dynamically allocate memory for temporary buffer b. [U-Boot,v3,2/2] fs: fat: Reduce default max clustersize 64KiB from malloc pool https://patchwork.ozlabs.org/project/uboot/list/?series=91135 (under review) 3. [U-Boot] misc: fs_loader: Replace label with DT phandle https://patchwork.ozlabs.org/project/uboot/list/?series=92167 (under review) [v8]: https://www.mail-archive.com/u-boot@lists.denx.de/msg316086.html [v7]: https://www.mail-archive.com/u-boot@lists.denx.de/msg314511.html Tien Fong Chee (7): ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10 ARM: socfpga: Add default FPGA bitstream fitImage for Arria10 SoCDK ARM: socfpga: Add FPGA drivers for Arria 10 FPGA bitstream loading ARM: socfpga: Add the configuration for FPGA SoCFPGA A10 SoCDK spl : socfpga: Implement fpga bitstream loading with socfpga loadfs ARM: socfpga: Synchronize the configuration for A10 SoCDK ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 17 + .../include/mach/fpga_manager_arria10.h| 40 +- arch/arm/mach-socfpga/spl_a10.c| 31 +- board/altera/arria10-socdk/fit_spl_fpga.its| 38 ++ configs/socfpga_arria10_defconfig | 21 +- .../fpga/altera-socfpga-a10-fpga-mgr.txt | 26 +- drivers/fpga/socfpga_arria10.c | 533 - include/configs/socfpga_common.h | 4 +- include/image.h| 4 + 9 files changed, 682 insertions(+), 32 deletions(-) create mode 100644 board/altera/arria10-socdk/fit_spl_fpga.its -- 2.2.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: rmobile: Convert Gen2 to OF_SEPARATE
Convert R-Car Gen2 from OF_EMBED to OF_SEPARATE, thus getting rid of one of the deprecation warnings. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- configs/alt_defconfig | 1 - configs/blanche_defconfig | 1 - configs/gose_defconfig| 1 - configs/koelsch_defconfig | 1 - configs/lager_defconfig | 1 - configs/porter_defconfig | 1 - configs/silk_defconfig| 1 - configs/stout_defconfig | 1 - 8 files changed, 8 deletions(-) diff --git a/configs/alt_defconfig b/configs/alt_defconfig index 44f1e1c51a..c4ece79507 100644 --- a/configs/alt_defconfig +++ b/configs/alt_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7794-alt-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/blanche_defconfig b/configs/blanche_defconfig index c5042d885f..c2d53a3d11 100644 --- a/configs/blanche_defconfig +++ b/configs/blanche_defconfig @@ -32,7 +32,6 @@ CONFIG_CMD_EXT4=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7792-blanche-u-boot" CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_IS_IN_SPI_FLASH=y diff --git a/configs/gose_defconfig b/configs/gose_defconfig index a5afb3c569..39e4cfdfc2 100644 --- a/configs/gose_defconfig +++ b/configs/gose_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7793-gose-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/koelsch_defconfig b/configs/koelsch_defconfig index 1ff14ac4ab..75beab4cce 100644 --- a/configs/koelsch_defconfig +++ b/configs/koelsch_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7791-koelsch-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/lager_defconfig b/configs/lager_defconfig index d924d76911..686aa2c171 100644 --- a/configs/lager_defconfig +++ b/configs/lager_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7790-lager-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/porter_defconfig b/configs/porter_defconfig index 7c54a54638..ce309b6d86 100644 --- a/configs/porter_defconfig +++ b/configs/porter_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7791-porter-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/silk_defconfig b/configs/silk_defconfig index 3cb4f6e005..0291a7c981 100644 --- a/configs/silk_defconfig +++ b/configs/silk_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7794-silk-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y diff --git a/configs/stout_defconfig b/configs/stout_defconfig index 1b1ed8d3ac..1c92cb6117 100644 --- a/configs/stout_defconfig +++ b/configs/stout_defconfig @@ -50,7 +50,6 @@ CONFIG_CMD_MTDPARTS=y CONFIG_MTDIDS_DEFAULT="nor0=spi0.0" CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:256k(u-boot-spl),512k(u-boot-env1),512k(u-boot-env2),768k(u-boot),-(user)" CONFIG_OF_CONTROL=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="r8a7790-stout-u-boot" CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_CLK=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On 2/18/19 3:51 PM, Ang, Chee Hong wrote:
> On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote:
>> On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
>>>
>>> From: "Ang, Chee Hong"
>>>
>>> 'SET_BLOCKLEN' may occasionally fail on first attempt.
>> Why ?
> This is part of the workaround of mmc driver which is enabled with
> 'CONFIG_MMC_QUIRKS' config.
> https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d82952e05a591
> efd0683/drivers/mmc/mmc.c#L272
OK, let's take a step back. What problem do you observe, that you're
trying to fix ?
>>> This patch enable a small delay in dwmci_send_cmd() on
>>> busy, I/O or CRC error to allow the MMC controller recovers
>>> from the failure/error on subsequent retries.
>> Why 100 uS ?
> This is a good question. Perhaps the driver's authors can explain this.
> The driver delay 100us after dwmci_send_cmd() success with the command
> sent. But it never delay 100us whenever mmc controller response to the
> command sent with I/O or CRC errors. MMC drivers expect the first
> 'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail
> intermittently so it will retry up to 4 times before it gave up and
> return error. Without this 100us delay after error response,
> 'SET_BLOCKEN' may sometime fail in 4 attempts in a row. Therefore, we
> encountered intermittent failure in loading u-boot (SSBL) from MMC.
Can you be more specific about the failure you saw ?
>> Can we rather detect whether the controller recovered by polling some
>> bit?
> Hmmm...I can take a look at the databook of this controller and dig
> further. Probably this is the limitation of the controller itself. The
> mmc driver code which introduce 100us delay after every command sent in
> dwmci_send_cmd() looks iffy.
If you have access to it, please do.
btw do you have the same problem if you disable caches ?
>>> Signed-off-by: Ang, Chee Hong
>>> ---
>>> drivers/mmc/dw_mmc.c | 14 ++
>>> 1 file changed, 10 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
>>> index 7544b84..8dcc518 100644
>>> --- a/drivers/mmc/dw_mmc.c
>>> +++ b/drivers/mmc/dw_mmc.c
>>> @@ -266,8 +266,11 @@ static int dwmci_send_cmd(struct mmc *mmc,
>>> struct mmc_cmd *cmd,
>>> if (data)
>>> flags = dwmci_set_transfer_mode(host, data);
>>>
>>> - if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type &
>>> MMC_RSP_BUSY))
>>> - return -1;
>>> + if ((cmd->resp_type & MMC_RSP_136) &&
>>> + (cmd->resp_type & MMC_RSP_BUSY)) {
>>> + ret = -1;
>>> + goto delay_ret;
>>> + }
>>>
>>> if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
>>> flags |= DWMCI_CMD_ABORT_STOP;
>>> @@ -316,11 +319,13 @@ static int dwmci_send_cmd(struct mmc *mmc,
>>> struct mmc_cmd *cmd,
>>> return -ETIMEDOUT;
>>> } else if (mask & DWMCI_INTMSK_RE) {
>>> debug("%s: Response Error.\n", __func__);
>>> - return -EIO;
>>> + ret = -EIO;
>>> + goto delay_ret;
>>> } else if ((cmd->resp_type & MMC_RSP_CRC) &&
>>> (mask & DWMCI_INTMSK_RCRC)) {
>>> debug("%s: Response CRC Error.\n", __func__);
>>> - return -EIO;
>>> + ret = -EIO;
>>> + goto delay_ret;
>>> }
>>>
>>>
>>> @@ -347,6 +352,7 @@ static int dwmci_send_cmd(struct mmc *mmc,
>>> struct mmc_cmd *cmd,
>>> }
>>> }
>>>
>>> +delay_ret:
>>> udelay(100);
>>>
>>> return ret;
>>>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL] u-boot-socfpga/master
The following changes since commit b89074f65047c4058741ed2bf3e6ff0c5af4c5bc: Merge tag 'u-boot-imx-2019-02-16' of git://git.denx.de/u-boot-imx (2019-02-16 08:31:05 -0500) are available in the Git repository at: git://git.denx.de/u-boot-socfpga.git master for you to fetch changes up to 5097ba6177bad8c7e09b50149cacd6fd5020f0c8: ARM: socfpga: stratix10: Return valid error code from FPGA driver (2019-02-18 13:00:54 +0100) Ang, Chee Hong (1): ARM: socfpga: stratix10: Return valid error code from FPGA driver Ley Foon Tan (1): mmc: dwmmc: Poll for iDMAC TX/RX interrupt Simon Goldschmidt (3): net: designware: socfpga: adapt to Gen5 arm: socfpga: gen5 enable designware_socfpga arm: socfpga: gen5: remove hacked ETH RST handling arch/arm/mach-socfpga/include/mach/reset_manager.h | 2 -- arch/arm/mach-socfpga/misc.c | 65 - arch/arm/mach-socfpga/misc_gen5.c | 44 +--- drivers/fpga/stratix10.c | 17 ++--- drivers/mmc/dw_mmc.c | 19 +++ drivers/net/Kconfig| 3 +++ drivers/net/dwmac_socfpga.c| 87 +-- include/dwmmc.h| 7 +++ 8 files changed, 69 insertions(+), 175 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] board/BuR/brppt1: fix ethernet support on brppt1 boards
On Fri, Feb 15, 2019 at 11:15:05AM +0100, Hannes Schmelzer wrote:
> The commit 1bac199e8c87 ("configs: Resync with savedefconfig")
> did remove ethernet driver from following boards defconfig:
>
> - brppt1_mmc
> - brppt1_nand
> - brppt1_spi
>
> With this commit we add ethernet and responsible phy support again.
>
> Signed-off-by: Hannes Schmelzer
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] [ANN] U-Boot v2019.04-rc2 released
Hey all, So it's release day and I've put up v2019.04-rc2, I've updated git and the tarballs are also up now. Thanks again to having signed tags, between -rc1 and -rc2 we have a good changelog under 'git log --merges v2019.04-rc1..v2019.04-rc2' I'm still looking to pickup more DM enablement patches and Kconfig conversions at this point. We're looking at release on April 8th, 2019. 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] efi_loader: Swap roles with Heinrich
On Thu, Feb 14, 2019 at 02:35:17PM +0100, Alexander Graf wrote: > Heinrich is going to take over maintainership of the efi_loader tree > going forward. > > To ensure that I will still receive review mails at least, add me as > reviewer with a stable email address. > > Signed-off-by: Alexander Graf > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] rpi: Make Matthias maintainer
On Thu, Feb 14, 2019 at 02:37:59PM +0100, Alexander Graf wrote: > Matthias Brugger agreed to take over maintainership from me for the > Raspberry Pi tree. Add him to the MAINTAINERS file instead. > > Signed-off-by: Alexander Graf > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot,v1,1/2] configs: k2g_evm: Enable CONFIG_BLK
On Fri, Feb 08, 2019 at 10:55:05AM +0100, Jean-Jacques Hiblot wrote: > CONFIG_BLK can be safely enabled as DM_MMC and DM_USB are already enabled. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Lokesh Vutla > Tested-by: Vignesh R Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for EFI subsystem in U-Boot v2019.04-rc2
On Mon, Feb 18, 2019 at 07:57:00PM +0100, Heinrich Schuchardt wrote: > Hello Tom, > > the following changes since commit d391c13c99a2b48c98cef6df4479247cd4e62f9d: > > Merge tag 'xilinx-for-v2019.04-rc2' of > git://git.denx.de/u-boot-microblaze (2019-02-15 21:21:28 -0500) > > are available in the Git repository at: > > https://github.com/xypron2/u-boot tag efi-2019-04-rc2 > > for you to fetch changes up to 997fc12ec91eccf6b7485565864f3eb8ce74def2: > > efi_loader: do not miss last relocation block (2019-02-16 15:51:14 +0100) > > Primary key fingerprint: > 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 > > Travis results look fine: > https://travis-ci.org/xypron2/u-boot/builds/494229312 > > The patches fix multiple errors. Mentionable are: > - EFI unit tests (bootefi selftest) can run on i386. > - `make tests` executes the Unicode unit tests. > > The LoadImage patch is preparing for further rework to be delivered > in v2019.07. For future reference, this is the content to put into the tag commit message (as that auto-populates the merge commit). 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] [U-Boot, v1, 2/2] configs: Enable CONFIG_BLK in am57xx_evm and am57xx_hs_evm
On Fri, Feb 08, 2019 at 10:55:06AM +0100, Jean-Jacques Hiblot wrote: > Enable CONFIG_DM_SCSI and CONFIG_BLK. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Lokesh Vutla Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: add exception command
On Mon, Feb 18, 2019 at 08:38:52PM +0100, Heinrich Schuchardt wrote: > On 1/5/19 2:56 AM, Simon Glass wrote: > > Hi Heinrich, > > > > On Sun, 30 Dec 2018 at 01:33, Heinrich Schuchardt > > wrote: > >> > >> On 12/29/18 2:39 PM, Simon Glass wrote: > >>> Hi Heinrich, > >>> > >>> On Wed, 26 Dec 2018 at 09:20, Heinrich Schuchardt > >>> wrote: > > The 'exception' command allows to test exception handling. > > This implementation supports ARM, x86, RISC-V and the following > exceptions: > * 'breakpoint' - prefetch abort exception (ARM 32bit only) > * 'unaligned' - data abort exception (ARM only) > * 'undefined' - undefined instruction exception > > Signed-off-by: Heinrich Schuchardt > --- > v2: > Split architecture specific code into separate files. > Provide include for common code. > Update MAINTAINERS file. > --- > MAINTAINERS | 3 +++ > cmd/Kconfig | 6 + > cmd/Makefile | 2 ++ > cmd/arm/Makefile | 7 + > cmd/arm/exception.c | 61 +++ > cmd/arm/exception64.c | 33 +++ > cmd/riscv/Makefile| 3 +++ > cmd/riscv/exception.c | 29 > cmd/x86/Makefile | 1 + > cmd/x86/exception.c | 29 > include/exception.h | 58 > 11 files changed, 232 insertions(+) > create mode 100644 cmd/arm/Makefile > create mode 100644 cmd/arm/exception.c > create mode 100644 cmd/arm/exception64.c > create mode 100644 cmd/riscv/Makefile > create mode 100644 cmd/riscv/exception.c > create mode 100644 cmd/x86/exception.c > create mode 100644 include/exception.h > >>> > >>> This needs something like Series-version: 2 (if you use patman) to set > >>> the version number in the header. > >> > >> Sorry for the mishap. > >> > >>> > >>> Did you look at using a uclass and driver, like sysreset? > >> > >> Yes I have considered using a u-class. But I could not see how adding a > >> separate u-class file would save lines, make the coding less complex, or > >> make the coding easier to maintain. A u-class would make sense if there > >> were other consumers for exceptions but the exception command. But I > >> cannot imagine any. > > > > In some sense driver model matches consumers and producers. There are > > clearly multiple producers - you have effectively implemented an API > > in a few places. We even have multiple impls for each arch. > > > > So I still favour a uclass, but since you are pretty adamant that we > > should not do it, I'm not going to insist. > > Hello Tom, > > in patchwork this patch is still in status 'NEW'. > > It is unclear to me if you are going to merge it as is or if I should > rework it. I guess I hadn't made a decision here. I guess if you're really sure it doesn't need what Simon is suggesting, then yes, I'll pick this up as-is. 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] spi: omap3: fix set_wordlen() reading from incorrect address for CHCONF
From: David Rivshin
_omap3_spi_set_wordlen() indexed the regs->channel[] array with the
old wordlen (instead of the chipselect number) when reading the current
CHCONF register value. This meant it read from the wrong memory location,
modified that value, and then wrote it back to the correct CHCONF
register. The end result is that most slave configuration settings would
be lost, such as clock divisor, clock/chipselect polarities, etc.
Fixes: 77b8d04854f4 ("spi: omap3: Convert to driver model")
Signed-off-by: David Rivshin
---
drivers/spi/omap3_spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index c7fcf050a5..ff4c700645 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -415,7 +415,7 @@ static void _omap3_spi_set_wordlen(struct omap3_spi_priv
*priv)
unsigned int confr;
/* McSPI individual channel configuration */
- confr = readl(>regs->channel[priv->wordlen].chconf);
+ confr = readl(>regs->channel[priv->cs].chconf);
/* wordlength */
confr &= ~OMAP3_MCSPI_CHCONF_WL_MASK;
base-commit: d3689267f92c5956e09cc7d1baa4700141662bff
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: fix hvc call
HVC call makes use of 6 arguments rather than 7 in the same way as SMC calls. The 7th argument is optional for both HVC and SMC but is implemented as 16-bit parameter and register R7 or W7. Signed-off-by: Ibai Erkiaga --- 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. 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 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] regulator: Add support for ramp delay
On Sat, Feb 16, 2019 at 10:45:45AM +0100, Krzysztof Kozlowski wrote: > Changing voltage and enabling regulator might require delays so the > regulator stabilizes at expected level. > > Add support for "regulator-ramp-delay" binding which can introduce > required time to both enabling the regulator and to changing the > voltage. I'm surprised that such a thing doesn't exist already. > Signed-off-by: Krzysztof Kozlowski > --- a/doc/device-tree-bindings/regulator/regulator.txt > +++ b/doc/device-tree-bindings/regulator/regulator.txt > @@ -35,6 +35,7 @@ Optional properties: > - regulator-max-microamp: a maximum allowed Current value > - regulator-always-on: regulator should never be disabled > - regulator-boot-on: enabled by bootloader/firmware > +- regulator-ramp-delay: ramp delay for regulator (in uV/us) I guess you mean s/V, not V/s; at least the code suggests so. But my main point is: is the required delay always a linear function of the voltage jump? Depending on the dampening and load on the rail this could be an overshoot and settle, no? So I suggest to make that an array with 2 elements: a fixed part and a time per voltage change. Does that make sense? Torsten ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] regulator: Add support for ramp delay
On Mon, Feb 18, 2019 at 03:28:46PM +0100, Krzysztof Kozlowski wrote: > On Mon, 18 Feb 2019 at 15:03, Torsten Duwe wrote: > > > > > --- a/doc/device-tree-bindings/regulator/regulator.txt > > > +++ b/doc/device-tree-bindings/regulator/regulator.txt > > > @@ -35,6 +35,7 @@ Optional properties: > > > - regulator-max-microamp: a maximum allowed Current value > > > - regulator-always-on: regulator should never be disabled > > > - regulator-boot-on: enabled by bootloader/firmware > > > +- regulator-ramp-delay: ramp delay for regulator (in uV/us) > > > > I guess you mean s/V, not V/s; at least the code suggests so. > > uV/uS. It is correct in the code: > int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay); > delay = (uV - uV) / (uV / uS) = uS You're right. _divide_ by that value; somhow this has escaped me. Sorry for the noise. nit: "s" is for seconds, "S" is for conductance. > > But my main point is: is the required delay always a linear > > function of the voltage jump? Depending on the dampening and > > load on the rail this could be an overshoot and settle, no? > > > > So I suggest to make that an array with 2 elements: a fixed part > > and a time per voltage change. Does that make sense? > > Just to make it clear - then we do not follow Linux kernel DT bindings. > The voltage change might have exponential characteristic and/or have > additional fixed delay time (see patch 7 here). We could re-use some > properties from Linux bindings for that purpose: > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L19 > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L24 I see. But then "static void regulator_set_value_delay(...)" should either at least have a "ramp" somewhere in its name or it should discover the device properties on its own, in order to be able to handle regulator-settling-time* and regulator-enable-ramp-delay as well in the future. (i.e. pass it uc_pdata instead of uc_pdata->ramp_delay and also let it handle the condition). Torsten ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] k2g: config enable ti phy dp83867 for k2g
On Mon, Feb 18, 2019 at 11:28:02AM -0500, Murali Karicheri wrote: > Enable ti phy driver dp83867 for k2g based boards. > > Signed-off-by: Murali Karicheri > --- > include/configs/k2g_evm.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h > index 90f9a9922c..9fe5411619 100644 > --- a/include/configs/k2g_evm.h > +++ b/include/configs/k2g_evm.h > @@ -98,4 +98,5 @@ > > #include > > +#define CONFIG_PHY_TI > #endif /* __CONFIG_K2G_EVM_H */ Lets migrate to Kconfig while were here please, 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] ARM: socfpga: Configure PL310 latencies
Configure the PL310 tag and data latency registers, which slightly improves performance and aligns the behavior with Linux. Signed-off-by: Marek Vasut Cc: Dalon Westergreen Cc: Dinh Nguyen --- arch/arm/mach-socfpga/misc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c index 78fbe28724..1ea4e32c11 100644 --- a/arch/arm/mach-socfpga/misc.c +++ b/arch/arm/mach-socfpga/misc.c @@ -62,6 +62,9 @@ void v7_outer_cache_enable(void) /* Disable the L2 cache */ clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN); + writel(0x111, >pl310_tag_latency_ctrl); + writel(0x121, >pl310_data_latency_ctrl); + /* enable BRESP, instruction and data prefetch, full line of zeroes */ setbits_le32(>pl310_aux_ctrl, L310_AUX_CTRL_DATA_PREFETCH_MASK | -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] ARM: cache: Fix incorrect bitwise operation
The loop implemented in the code is supposed to check whether the
PL310 operation register has any bit from the mask set. Currently,
the code checks whether the PL310 operation register has any bit
set AND whether the mask is non-zero, which is incorrect. Fix the
conditional.
Signed-off-by: Marek Vasut
Cc: Dalon Westergreen
Cc: Dinh Nguyen
Cc: Tom Rini
Fixes: 93bc21930a1b ("armv7: add PL310 support to u-boot")
---
arch/arm/lib/cache-pl310.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/lib/cache-pl310.c b/arch/arm/lib/cache-pl310.c
index 1296ba6efd..bb4157 100644
--- a/arch/arm/lib/cache-pl310.c
+++ b/arch/arm/lib/cache-pl310.c
@@ -33,7 +33,7 @@ static void pl310_background_op_all_ways(u32 *op_reg)
/* Invalidate all ways */
writel(way_mask, op_reg);
/* Wait for all ways to be invalidated */
- while (readl(op_reg) && way_mask)
+ while (readl(op_reg) & way_mask)
;
pl310_cache_sync();
}
--
2.19.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] MTD: mxs_nand_spl: Redo the way nand_init initializes
Currently the spl system calls nand_init which does nothing.
It isn't until an attempt to load from NAND that it gets initialized.
Subsequent attempts to load just skip the initialization because
NAND is already initialized.
This moves the contents of mxs_nand_init to nand_init. In the event
of an error, it clears the number of nand chips found. Any
attempts to use nand will check if there are nand chips available
instead of actually doing the initialization at that time. If there
are none, it will return an error to the higher level calls.
Signed-off-by: Adam Ford
diff --git a/drivers/mtd/nand/raw/mxs_nand_spl.c
b/drivers/mtd/nand/raw/mxs_nand_spl.c
index ba85baac60..ee7d9cb957 100644
--- a/drivers/mtd/nand/raw/mxs_nand_spl.c
+++ b/drivers/mtd/nand/raw/mxs_nand_spl.c
@@ -174,11 +174,11 @@ static int is_badblock(struct mtd_info *mtd, loff_t offs,
int allowbbt)
}
/* setup mtd and nand structs and init mxs_nand driver */
-static int mxs_nand_init(void)
+void nand_init(void)
{
/* return if already initalized */
if (nand_chip.numchips)
- return 0;
+ return;
/* init mxs nand driver */
mxs_nand_init_spl(_chip);
@@ -191,7 +191,8 @@ static int mxs_nand_init(void)
/* identify flash device */
if (mxs_flash_ident(mtd)) {
printf("Failed to identify\n");
- return -1;
+ nand_chip.numchips = 0; /* If fail, don't use nand */
+ return;
}
/* allocate and initialize buffers */
@@ -202,8 +203,6 @@ static int mxs_nand_init(void)
mtd->size = nand_chip.chipsize;
nand_chip.scan_bbt(mtd);
mxs_nand_setup_ecc(mtd);
-
- return 0;
}
int nand_spl_load_image(uint32_t offs, unsigned int size, void *buf)
@@ -213,9 +212,9 @@ int nand_spl_load_image(uint32_t offs, unsigned int size,
void *buf)
unsigned int nand_page_per_block;
unsigned int sz = 0;
- if (mxs_nand_init())
- return -ENODEV;
chip = mtd_to_nand(mtd);
+ if (!chip->numchips)
+ return -ENODEV;
page = offs >> chip->page_shift;
nand_page_per_block = mtd->erasesize / mtd->writesize;
@@ -256,10 +255,6 @@ int nand_default_bbt(struct mtd_info *mtd)
return 0;
}
-void nand_init(void)
-{
-}
-
void nand_deselect(void)
{
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] February community conf call minutes
Hey all, While I'm not the best at taking notes, and for next time I'll see how badly the record function slows down my connection, here's my notes / action items from the call: - Attendees: Myself, Philipp Tomsich, Michal Simek, Stefano Babic, Vignesh R, Jagan Teki, Lokesh Vutla, Matthias Brugger, Masahiro Yamada. - Talked about more automated testing, ala kernelci. I noted that we have travis-ci setup, and with test.py that runs on on qemu on a number of platforms. With respect to real hardware, I run mine on a handful of TI platforms and RPi 3 (I've tried sunxi before, but had power vampire problems, and imx6, but my platform wasn't supported in SPL at the time). Michal noted he has a setup for some of his platforms. - A main next branch for testing / integration? I don't know if I have resources to maintain one, but can evaluate again with this longer release cycle. I do continue to encourage custodians to have a next branch if that helps them. - Communication. A lot of people didn't see the notice about this meeting until very late. A lot of people in general have missed a lot of things (see for example, the fallout from the DM deadlines). It has been suggested that we have a custodians and/or board maintainers only list to better help people filter emails and see very important things. - I've asked Wolfgang to set these up, and I'll be asking people to sign up. - As part of the "didn't see this until very late", I need to poll again about when to do these calls. - Some talk in general about the DM deadlines and what to do about missed deadlines. In general, and looking at immediately post-v2019.04, I am not in favor of just dropping every platform that hasn't converted. I think in some cases it will make sense to mark drivers as depending on BROKEN so that we can then remove the driver in question. I also agreed that if platforms don't see the value in migration for legacy platforms, it's OK for them to also say they don't see value in being upstream for that platform anymore. And removing a feature that wasn't really used (but was instead carried over from the "kitchen sink evm" config) is fine too. - One thing I do need to do from this is make a build (or several) where, after I apply all of the "migrate to ..." things in my queue I see what's still where with these warnings. We have things ranging from for example TI platforms that we've converted some of the family over to, but not all, and should be able to mechanically convert, to PowerPC platforms where I've seen nothing happen in a while. For the latter we'll end up with BROKEN and for the former after I can test one I might blind-convert the rest. Thanks again 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 3/3] logos: Add the TechNexion's logo
Hi Stefano, On Tue, Dec 11, 2018 at 4:41 PM Otavio Salvador wrote: > > From: Fabio Estevam > > Add the TechNexion's logo from their internal U-Boot tree. > > Signed-off-by: Fabio Estevam > Signed-off-by: Otavio Salvador > --- > > tools/logos/technexion.bmp | Bin 0 -> 22390 bytes > 1 file changed, 0 insertions(+), 0 deletions(-) > create mode 100644 tools/logos/technexion.bmp I noticed this patch has not been applied. Maybe a patchwork bug? Could you please consider applying it? Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] tools: kwbimage: don't adjust for image_header for Armada MSYS
On Mon, Feb 18, 2019 at 8:13 PM Stefan Roese wrote:
>
> Hi Chris,
>
> On 15.02.19 23:49, Chris Packham wrote:
> > For the time being the Armada MSYS SoCs need to use the bin_hdr from the
> > Marvell U-Boot. Because of this the binary.0 does not contain the image
> > header that a proper u-boot SPL would so the adjustment introduced by
> > commit 94084eea3bd3 ("tools: kwbimage: Fix dest addr") does not apply.
>
> Thanks for the explanation. I'm wondering if it would be better (if
> possible) to auto detect this situation of using a bin_hdr from Marvell
> vs U-Boot SPL instead in this tool. This would help especially if we
> have full DDR init support in mainline U-Boot for this SoC at some
> time, as we then need to differentiate between those two options for
> this SoC.
>
> Would this be possible?
One way would be to check the filename, binary.0 means don't adjust it
whereas u-boot-spl.img does. I also considered modifying the process
to create binary.0 to prepend sizeof(image_header_t) bytes to allow it
to work but I went with the quickest option for me to implement.
If it's an acceptable solution the filename thing would be quite easy
to implement. Adding a flag or parameter in the kwbimage.cfg would
also be relatively easy.
>
> Thanks,
> Stefan
>
> > Signed-off-by: Chris Packham
> > ---
> >
> > Changes in v2:
> > - new, split out from Add DB-XC3-24G4XG board with a better explanation
> >
> > tools/Makefile | 4
> > tools/kwbimage.c | 4
> > 2 files changed, 8 insertions(+)
> >
> > diff --git a/tools/Makefile b/tools/Makefile
> > index 081383d7a790..d99098d6167a 100644
> > --- a/tools/Makefile
> > +++ b/tools/Makefile
> > @@ -148,6 +148,10 @@ ifneq ($(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X),)
> > HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_SECURE
> > endif
> >
> > +ifneq ($(CONFIG_ARMADA_MSYS),)
> > +HOSTCFLAGS_kwbimage.o += -DCONFIG_KWB_DESTADDR_COMPAT
> > +endif
> > +
> > # MXSImage needs LibSSL
> > ifneq
> > ($(CONFIG_MX23)$(CONFIG_MX28)$(CONFIG_ARMADA_38X)$(CONFIG_ARMADA_39X)$(CONFIG_FIT_SIGNATURE),)
> > HOSTLOADLIBES_mkimage += \
> > diff --git a/tools/kwbimage.c b/tools/kwbimage.c
> > index a88a3830c0c8..4c60679fbb53 100644
> > --- a/tools/kwbimage.c
> > +++ b/tools/kwbimage.c
> > @@ -1252,8 +1252,12 @@ static void *image_create_v1(size_t *imagesz, struct
> > image_tool_params *params,
> > cpu_to_le32(payloadsz - headersz + sizeof(uint32_t));
> > main_hdr->headersz_lsb = cpu_to_le16(headersz & 0x);
> > main_hdr->headersz_msb = (headersz & 0x) >> 16;
> > +#ifdef CONFIG_KWB_DESTADDR_COMPAT
> > + main_hdr->destaddr = cpu_to_le32(params->addr);
> > +#else
> > main_hdr->destaddr = cpu_to_le32(params->addr)
> >- sizeof(image_header_t);
> > +#endif
> > main_hdr->execaddr = cpu_to_le32(params->ep);
> > main_hdr->srcaddr = cpu_to_le32(headersz);
> > main_hdr->ext = hasext;
> >
>
> Viele Grüße,
> Stefan
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] cmd: add exception command
On 1/5/19 2:56 AM, Simon Glass wrote: > Hi Heinrich, > > On Sun, 30 Dec 2018 at 01:33, Heinrich Schuchardt wrote: >> >> On 12/29/18 2:39 PM, Simon Glass wrote: >>> Hi Heinrich, >>> >>> On Wed, 26 Dec 2018 at 09:20, Heinrich Schuchardt >>> wrote: The 'exception' command allows to test exception handling. This implementation supports ARM, x86, RISC-V and the following exceptions: * 'breakpoint' - prefetch abort exception (ARM 32bit only) * 'unaligned' - data abort exception (ARM only) * 'undefined' - undefined instruction exception Signed-off-by: Heinrich Schuchardt --- v2: Split architecture specific code into separate files. Provide include for common code. Update MAINTAINERS file. --- MAINTAINERS | 3 +++ cmd/Kconfig | 6 + cmd/Makefile | 2 ++ cmd/arm/Makefile | 7 + cmd/arm/exception.c | 61 +++ cmd/arm/exception64.c | 33 +++ cmd/riscv/Makefile| 3 +++ cmd/riscv/exception.c | 29 cmd/x86/Makefile | 1 + cmd/x86/exception.c | 29 include/exception.h | 58 11 files changed, 232 insertions(+) create mode 100644 cmd/arm/Makefile create mode 100644 cmd/arm/exception.c create mode 100644 cmd/arm/exception64.c create mode 100644 cmd/riscv/Makefile create mode 100644 cmd/riscv/exception.c create mode 100644 cmd/x86/exception.c create mode 100644 include/exception.h >>> >>> This needs something like Series-version: 2 (if you use patman) to set >>> the version number in the header. >> >> Sorry for the mishap. >> >>> >>> Did you look at using a uclass and driver, like sysreset? >> >> Yes I have considered using a u-class. But I could not see how adding a >> separate u-class file would save lines, make the coding less complex, or >> make the coding easier to maintain. A u-class would make sense if there >> were other consumers for exceptions but the exception command. But I >> cannot imagine any. > > In some sense driver model matches consumers and producers. There are > clearly multiple producers - you have effectively implemented an API > in a few places. We even have multiple impls for each arch. > > So I still favour a uclass, but since you are pretty adamant that we > should not do it, I'm not going to insist. Hello Tom, in patchwork this patch is still in status 'NEW'. It is unclear to me if you are going to merge it as is or if I should rework it. Best regards Heinrich > >> >> There are better places to apply u-classes, e.g. I am really missing a >> u-class for file systems. >> >> Best regards >> >> Heinrich >> >>> >>> Regards, >>> Simon >>> > > Regards, > Simon > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request for EFI subsystem in U-Boot v2019.04-rc2
Hello Tom, the following changes since commit d391c13c99a2b48c98cef6df4479247cd4e62f9d: Merge tag 'xilinx-for-v2019.04-rc2' of git://git.denx.de/u-boot-microblaze (2019-02-15 21:21:28 -0500) are available in the Git repository at: https://github.com/xypron2/u-boot tag efi-2019-04-rc2 for you to fetch changes up to 997fc12ec91eccf6b7485565864f3eb8ce74def2: efi_loader: do not miss last relocation block (2019-02-16 15:51:14 +0100) Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC 2C05 1AC4 Travis results look fine: https://travis-ci.org/xypron2/u-boot/builds/494229312 The patches fix multiple errors. Mentionable are: - EFI unit tests (bootefi selftest) can run on i386. - `make tests` executes the Unicode unit tests. The LoadImage patch is preparing for further rework to be delivered in v2019.07. Best regards Heinrich Heinrich Schuchardt (15): efi_selftest: do not use efi_free_pool() efi_selftest: fix memory allocation in HII tests efi_loader: efi_dp_split_file_path() error handling efi_loader: comments for efi_file_from_path() efi_selftest: LoadImage from file device path lib/vsprintf: print '?' for illegal Unicode sequence test: adjust names of Unicode test functions efi_loader: error handling in efi_setup_loaded_image() efi_loader: LoadImage: always allocate new pages efi_loader: set entry point in efi_load_pe() efi_loader: use efi_start_image() for bootefi efi_loader: fix EFI entry counting efi_loader: clean up bootefi_test_prepare() efi_loader: documentation of image loader efi_loader: do not miss last relocation block Documentation/efi.rst | 6 + cmd/bootefi.c | 93 ++-- include/efi_loader.h | 10 +- lib/efi_loader/efi_bootmgr.c | 2 +- lib/efi_loader/efi_boottime.c | 148 -- lib/efi_loader/efi_device_path.c | 16 +- lib/efi_loader/efi_file.c | 12 +- lib/efi_loader/efi_image_loader.c | 67 +-- lib/efi_selftest/Makefile | 3 + lib/efi_selftest/efi_selftest_block_device.c | 2 +- lib/efi_selftest/efi_selftest_hii.c | 102 +++-- lib/efi_selftest/efi_selftest_loadimage.c | 529 ++ lib/efi_selftest/efi_selftest_startimage_exit.c | 2 +- lib/efi_selftest/efi_selftest_startimage_return.c | 2 +- lib/vsprintf.c| 2 + test/unicode_ut.c | 98 ++-- 16 files changed, 868 insertions(+), 226 deletions(-) create mode 100644 lib/efi_selftest/efi_selftest_loadimage.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] net: netcp: add support for phy with rgmii ids
Enhance the netcp driver to support phys that can be configured
for internal delay (rgmii-id, rgmii-rxid, rgmii-txid)
Signed-off-by: Murali Karicheri
---
drivers/net/ti/keystone_net.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ti/keystone_net.c b/drivers/net/ti/keystone_net.c
index a3ba91cc3f..defc57b29f 100644
--- a/drivers/net/ti/keystone_net.c
+++ b/drivers/net/ti/keystone_net.c
@@ -88,6 +88,7 @@ struct ks2_eth_priv {
struct mii_dev *mdio_bus;
int phy_addr;
phy_interface_t phy_if;
+ int phy_of_handle;
int sgmii_link_type;
void*mdio_base;
struct rx_buff_desc net_rx_buffs;
@@ -588,6 +589,10 @@ static int ks2_eth_probe(struct udevice *dev)
if (priv->has_mdio) {
priv->phydev = phy_connect(priv->mdio_bus, priv->phy_addr,
dev, priv->phy_if);
+#ifdef CONFIG_DM_ETH
+ if (priv->phy_of_handle)
+ dev_set_of_offset(priv->phydev->dev, priv->phy_of_handle);
+#endif
phy_config(priv->phydev);
}
@@ -679,6 +684,7 @@ static int ks2_eth_parse_slave_interface(int netcp, int
slave,
int phy;
int dma_count;
u32 dma_channel[8];
+ const char *phy_mode;
priv->slave_port = fdtdec_get_int(fdt, slave, "slave-port", -1);
priv->net_rx_buffs.rx_flow = priv->slave_port * 8;
@@ -700,7 +706,9 @@ static int ks2_eth_parse_slave_interface(int netcp, int
slave,
priv->link_type = fdtdec_get_int(fdt, slave, "link-interface", -1);
phy = fdtdec_lookup_phandle(fdt, slave, "phy-handle");
+
if (phy >= 0) {
+ priv->phy_of_handle = phy;
priv->phy_addr = fdtdec_get_int(fdt, phy, "reg", -1);
mdio = fdt_parent_offset(fdt, phy);
@@ -717,7 +725,19 @@ static int ks2_eth_parse_slave_interface(int netcp, int
slave,
priv->sgmii_link_type = SGMII_LINK_MAC_PHY;
priv->has_mdio = true;
} else if (priv->link_type == LINK_TYPE_RGMII_LINK_MAC_PHY) {
- priv->phy_if = PHY_INTERFACE_MODE_RGMII;
+ phy_mode = fdt_getprop(fdt, slave, "phy-mode", NULL);
+ if (phy_mode) {
+ priv->phy_if = phy_get_interface_by_name(phy_mode);
+ if (priv->phy_if != PHY_INTERFACE_MODE_RGMII &&
+ priv->phy_if != PHY_INTERFACE_MODE_RGMII_ID &&
+ priv->phy_if != PHY_INTERFACE_MODE_RGMII_RXID &&
+ priv->phy_if != PHY_INTERFACE_MODE_RGMII_TXID) {
+ pr_err("invalid phy-mode\n");
+ return -EINVAL;
+ }
+ } else {
+ priv->phy_if = PHY_INTERFACE_MODE_RGMII;
+ }
pdata->phy_interface = priv->phy_if;
priv->has_mdio = true;
}
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Add netcp networking support on K2G ICE EVM
This patch series add networking capability to K2G ICE EVM based on netcp driver. Networking function has been tested using the latest master branch from u-boot repo. Following boot mode has been tested for networking. Net boot (tftp images over ethernet interface and boot kernel) log at https://pastebin.ubuntu.com/p/b3nyCXPhWc/ MMC boot: (load images from boot folder of rootfs and boot kernel) log at https://pastebin.ubuntu.com/p/FWycmKd9KB/ Used Linux upstream linux kernel version 4.19.9 for the tests. Please review and apply if this looks good. Thanks Revision history: v2: Collected Reviewed-by for patch 1 and 2. Rebased to latest on master Murali Karicheri (7): ARM: k2g-ice: Add pinmux support for rgmii interface ARM: k2g-gp-evm: update to rgmii pinmux configuration net: netcp: add support for phy with rgmii ids ARM: k2g: add a workaround to reset the phy k2g: config enable ti phy dp83867 for k2g ARM: dts: k2g-evm: remove unused phy-mode property from phy node ARM: dts: k2g-ice: add dt node for netcp arch/arm/dts/keystone-k2g-evm.dts | 1 - arch/arm/dts/keystone-k2g-ice.dts | 35 + .../mach-keystone/include/mach/hardware-k2g.h | 3 ++ arch/arm/mach-keystone/include/mach/mux-k2g.h | 5 ++ board/ti/ks2_evm/board_k2g.c | 15 ++ board/ti/ks2_evm/mux-k2g.h| 51 +-- drivers/net/ti/keystone_net.c | 22 +++- include/configs/k2g_evm.h | 1 + 8 files changed, 116 insertions(+), 17 deletions(-) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] ARM: k2g: add a workaround to reset the phy
This patch adds a workaround to reset the phy one time during boot
using GPIO0 pin 10 to make sure, the Phy latches the configuration
from the input pins correctly.
Signed-off-by: Murali Karicheri
---
.../arm/mach-keystone/include/mach/hardware-k2g.h | 3 +++
board/ti/ks2_evm/board_k2g.c | 15 +++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
index 8b902641ec..971c081bb3 100644
--- a/arch/arm/mach-keystone/include/mach/hardware-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/hardware-k2g.h
@@ -69,9 +69,12 @@
#define K2G_GPIO0_BASE 0X02603000
#define K2G_GPIO1_BASE 0X0260a000
+#define K2G_GPIO0_BANK0_BASE K2G_GPIO0_BASE + 0x10
#define K2G_GPIO1_BANK2_BASE K2G_GPIO1_BASE + 0x38
#define K2G_GPIO_DIR_OFFSET0x0
+#define K2G_GPIO_OUTDATA_OFFSET0x4
#define K2G_GPIO_SETDATA_OFFSET0x8
+#define K2G_GPIO_CLRDATA_OFFSET0xC
/* BOOTCFG RESETMUX8 */
#define KS2_RSTMUX8(KS2_DEVICE_STATE_CTRL_BASE + 0x328)
diff --git a/board/ti/ks2_evm/board_k2g.c b/board/ti/ks2_evm/board_k2g.c
index 39a782e479..6d0fc21c67 100644
--- a/board/ti/ks2_evm/board_k2g.c
+++ b/board/ti/ks2_evm/board_k2g.c
@@ -315,6 +315,21 @@ int embedded_dtb_select(void)
BIT(9));
setbits_le32(K2G_GPIO1_BANK2_BASE + K2G_GPIO_SETDATA_OFFSET,
BIT(9));
+ } else if (board_is_k2g_ice()) {
+ /* GBE Phy workaround. For Phy to latch the input
+* configuration, a GPIO reset is asserted at the
+* Phy reset pin to latch configuration correctly after SoC
+* reset. GPIO0 Pin 10 (Ball AA20) is used for this on ICE
+* board. Just do a low to high transition.
+*/
+ clrbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_DIR_OFFSET,
+BIT(10));
+ setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_CLRDATA_OFFSET,
+BIT(10));
+ /* Delay just to get a transition to high */
+ udelay(100);
+ setbits_le32(K2G_GPIO0_BANK0_BASE + K2G_GPIO_SETDATA_OFFSET,
+BIT(10));
}
return 0;
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 7/7] ARM: dts: k2g-ice: add dt node for netcp
This patch adds dt node for DP83867 phy used on K2G ICE board and
also enable netcp device nodes for the board.
EVM hardware spec recommends to add 0.25 nsec delay in the tx
direction and 2.25 nsec delay in the rx direction for internal
delay in the clock path to be on the safer side.
The board straps RX_DV/RX_CTRL pin of on board DP83867 phy in mode
1. Unfortunately, the phy data manual disallows this. Add
ti,dp83867-rxctrl-strap-quirk in the phy node to allow software to
enable workaround suggested for this incorrect strap setting. This
ensures proper operation of this PHY.
The dts bindings are kept in sync with that from 4.14.y linux
kernel. This required the pinmux device related bindings to be
commented out to allow for compilation.
Signed-off-by: Murali Karicheri
---
arch/arm/dts/keystone-k2g-ice.dts | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/dts/keystone-k2g-ice.dts
b/arch/arm/dts/keystone-k2g-ice.dts
index 698338b93d..b67332fed5 100644
--- a/arch/arm/dts/keystone-k2g-ice.dts
+++ b/arch/arm/dts/keystone-k2g-ice.dts
@@ -7,6 +7,7 @@
/dts-v1/;
#include "keystone-k2g.dtsi"
+#include
/ {
compatible = "ti,k2g-ice", "ti,k2g", "ti,keystone";
@@ -81,3 +82,37 @@
};
};
};
+
+ {
+ status = "okay";
+};
+
+_dmas {
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ //pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
+ {
+ pinctrl-names = "default";
+ //pinctrl-0 = <_pins>;
+ status = "okay";
+ ethphy0: ethernet-phy@0 {
+ reg = <0>;
+ ti,rx-internal-delay = ;
+ ti,tx-internal-delay = ;
+ ti,fifo-depth = ;
+ ti,min-output-impedance;
+ ti,dp83867-rxctrl-strap-quirk;
+ };
+};
+
+ {
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+ status = "okay";
+};
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] ARM: k2g-ice: Add pinmux support for rgmii interface
This add pinmux configuration for rgmii interface so that network
driver can be supported on K2G ICE boards. The pinmux configurations
for this are generated using the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default
As this required some BUFFER_CLASS definitions, same is re-used
from the linux defnitions in include/dt-bindings/pinctrl/keystone.h
Signed-off-by: Murali Karicheri
Reviewed-by: Lokesh Vutla
---
arch/arm/mach-keystone/include/mach/mux-k2g.h | 5 +
board/ti/ks2_evm/mux-k2g.h| 19 +++
2 files changed, 24 insertions(+)
diff --git a/arch/arm/mach-keystone/include/mach/mux-k2g.h
b/arch/arm/mach-keystone/include/mach/mux-k2g.h
index 809b72d5bf..67d47f8172 100644
--- a/arch/arm/mach-keystone/include/mach/mux-k2g.h
+++ b/arch/arm/mach-keystone/include/mach/mux-k2g.h
@@ -27,6 +27,11 @@
#define PIN_PTU(1 << 17) /* pull up */
#define PIN_PTD(0 << 17) /* pull down */
+#define BUFFER_CLASS_B (0 << 19)
+#define BUFFER_CLASS_C (1 << 19)
+#define BUFFER_CLASS_D (2 << 19)
+#define BUFFER_CLASS_E (3 << 19)
+
#define MODE(m)((m) & 0x7)
#define MAX_PIN_N 260
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 706fb7e838..8c184a85ae 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -346,6 +346,25 @@ struct pin_cfg k2g_ice_evm_pin_cfg[] = {
{ 133, MODE(0) }, /* SOC_QSPI_D2 */
{ 134, MODE(0) }, /* SOC_QSPI_D3 */
{ 135, MODE(0) }, /* SOC_QSPI_CSN0 */
+
+ /* EMAC */
+ { 79, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD1 */
+ { 78, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD2 */
+ { 77, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD3 */
+ { 80, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD0 */
+ { 94, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD0 */
+ { 93, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD1 */
+ { 92, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD2 */
+ { 91, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD3 */
+ { 85, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXC */
+ { 95, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXCTL */
+ { 72, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXC */
+ { 81, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXCTL */
+
+ /* MDIO */
+ { 99, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_CLK */
+ { 98, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_DATA */
+
{ MAX_PIN_N, }
};
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] k2g: config enable ti phy dp83867 for k2g
Enable ti phy driver dp83867 for k2g based boards. Signed-off-by: Murali Karicheri --- include/configs/k2g_evm.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/k2g_evm.h b/include/configs/k2g_evm.h index 90f9a9922c..9fe5411619 100644 --- a/include/configs/k2g_evm.h +++ b/include/configs/k2g_evm.h @@ -98,4 +98,5 @@ #include +#define CONFIG_PHY_TI #endif /* __CONFIG_K2G_EVM_H */ -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] ARM: dts: k2g-evm: remove unused phy-mode property from phy node
This patch removes the unused phy-mode property from the phy dt node. On
K2G, currently link-interface determines if phy is used or not and is
already set to use rgmii. So this is not needed. Besides phy-mode should
be added to slave interface configuration of the cpsw driver, not in the
phy node.
Signed-off-by: Murali Karicheri
---
arch/arm/dts/keystone-k2g-evm.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/keystone-k2g-evm.dts
b/arch/arm/dts/keystone-k2g-evm.dts
index 6c9de25b94..4820c7e50d 100644
--- a/arch/arm/dts/keystone-k2g-evm.dts
+++ b/arch/arm/dts/keystone-k2g-evm.dts
@@ -29,7 +29,6 @@
status = "okay";
ethphy0: ethernet-phy@0 {
reg = <0>;
- phy-mode = "rgmii-id";
};
};
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] ARM: k2g-gp-evm: update to rgmii pinmux configuration
This patch updates pinmux configuration for K2G GP EVM based on
data generated by the pinmux tool at
https://dev.ti.com/pinmux/app.html#/default
Signed-off-by: Murali Karicheri
Reviewed-by: Lokesh Vutla
---
board/ti/ks2_evm/mux-k2g.h | 32 +---
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/board/ti/ks2_evm/mux-k2g.h b/board/ti/ks2_evm/mux-k2g.h
index 8c184a85ae..89c49f9e4f 100644
--- a/board/ti/ks2_evm/mux-k2g.h
+++ b/board/ti/ks2_evm/mux-k2g.h
@@ -125,21 +125,23 @@ struct pin_cfg k2g_evm_pin_cfg[] = {
{ 70, MODE(0) }, /* SOC_MMC1_SDWP */
{ 71, MODE(0) }, /* MMC1POW TP124 */
- /* RGMII */
- { 72, MODE(1) | PIN_IEN },/* SOC_RGMII_RXCLK */
- { 77, MODE(1) | PIN_IEN },/* SOC_RGMII_RXD3 */
- { 78, MODE(1) | PIN_IEN },/* SOC_RGMII_RXD2 */
- { 79, MODE(1) | PIN_IEN },/* SOC_RGMII_RXD1 */
- { 80, MODE(1) | PIN_IEN },/* SOC_RGMII_RXD0 */
- { 81, MODE(1) | PIN_IEN },/* SOC_RGMII_RXCTL */
- { 85, MODE(1) }, /* SOC_RGMII_TXCLK */
- { 91, MODE(1) }, /* SOC_RGMII_TXD3 */
- { 92, MODE(1) }, /* SOC_RGMII_TXD2 */
- { 93, MODE(1) }, /* SOC_RGMII_TXD1 */
- { 94, MODE(1) }, /* SOC_RGMII_TXD0 */
- { 95, MODE(1) }, /* SOC_RGMII_TXCTL */
- { 98, MODE(0) }, /* SOC_MDIO_DATA */
- { 99, MODE(0) }, /* SOC_MDIO_CLK */
+ /* EMAC */
+ { 79, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD1 */
+ { 78, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD2 */
+ { 77, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD3 */
+ { 80, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXD0 */
+ { 94, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD0 */
+ { 93, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD1 */
+ { 92, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD2 */
+ { 91, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXD3 */
+ { 85, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXC */
+ { 95, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_TXCTL */
+ { 72, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXC */
+ { 81, BUFFER_CLASS_D | PIN_PDIS | MODE(1) }, /* RGMII_RXCTL */
+
+ /* MDIO */
+ { 99, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_CLK */
+ { 98, BUFFER_CLASS_B | PIN_PDIS | MODE(0) }, /* MDIO_DATA */
/* PWM */
{ 73, MODE(4) }, /* SOC_EHRPWM3A */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 7/7] env: am57xx: Implement A/B boot process
From: Ruslan Trofymenko
Add support for A/B boot process on AM57xx based boards:
1. Define 'slot_suffix' variable (using 'ab_select' command)
2. Extend 'emmc_android_boot' boot command (add commands for A/B boot
process)
'ab_select' command is used to decide which slot should be used for
booting up. A/B metadata resides in 'misc' partition.
To activate the A/B boot process, the following config options must be
set:
CONFIG_ANDROID_AB=y
CONFIG_CMD_AB_SELECT=y
For successful A/B boot, the corresponding A/B infrastructure must be
involved on Android side [1] (including mounting system as root), and
disk must be partitioned accordingly.
When A/B boot is enabled, there are some known limitations currently
exist (not related to A/B patches, need to be implemented later):
1. The 'Verified Boot' sequence is not supported
2. dev path to system partition (system_a or system_b) is passed via
'bootargs' as 'root=' argument like 'root=/dev/mmcblk1p12', but
further we'll need to rework it with respect to dm-verity
requirements [2]
In case when A/B partitions are not present in system (and A/B boot is
enabled), boot up process will be terminated and next message will be
shown:
"boot_a(b) partition not found"
[1] https://source.android.com/devices/tech/ota/ab
[2] https://source.android.com/devices/tech/ota/ab/ab_implement#kernel
Signed-off-by: Ruslan Trofymenko
Signed-off-by: Igor Opaniuk
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v3: None
Changes in v2:
* Add changes related to command renaming (android_ab_select -> ab_select).
* Slotted sections (e.g. system_a and system_b) are added to the
default sections if CONFIG_CMD_AB_SELECT flag is defined
* Rebased on top of master
* system partitions sizes increased to 1024 MiB (to be consistent with
recent changes to boot.h file)
include/environment/ti/boot.h | 58 ++-
1 file changed, 52 insertions(+), 6 deletions(-)
diff --git a/include/environment/ti/boot.h b/include/environment/ti/boot.h
index 05bdbbc..bc05bca 100644
--- a/include/environment/ti/boot.h
+++ b/include/environment/ti/boot.h
@@ -23,6 +23,18 @@
#define VBMETA_PART""
#endif
+#if defined(CONFIG_CMD_AB_SELECT)
+#define COMMON_PARTS \
+ "name=boot_a,size=10M,uuid=${uuid_gpt_boot_a};" \
+ "name=boot_b,size=10M,uuid=${uuid_gpt_boot_b};" \
+ "name=system_a,size=1024M,uuid=${uuid_gpt_system_a};" \
+ "name=system_b,size=1024M,uuid=${uuid_gpt_system_b};"
+#else
+#define COMMON_PARTS \
+ "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
+ "name=system,size=1024M,uuid=${uuid_gpt_system};"
+#endif
+
#ifndef PARTS_DEFAULT
/* Define the default GPT table for eMMC */
#define PARTS_DEFAULT \
@@ -38,8 +50,7 @@
"name=uboot-env,start=2432K,size=256K,uuid=${uuid_gpt_reserved};" \
"name=misc,size=128K,uuid=${uuid_gpt_misc};" \
"name=recovery,size=40M,uuid=${uuid_gpt_recovery};" \
- "name=boot,size=10M,uuid=${uuid_gpt_boot};" \
- "name=system,size=1024M,uuid=${uuid_gpt_system};" \
+ COMMON_PARTS \
"name=vendor,size=256M,uuid=${uuid_gpt_vendor};" \
VBMETA_PART \
"name=userdata,size=-,uuid=${uuid_gpt_userdata}"
@@ -58,6 +69,35 @@
#define AVB_VERIFY_CMD ""
#endif
+#define CONTROL_PARTITION "misc"
+
+#if defined(CONFIG_CMD_AB_SELECT)
+#define AB_SELECT \
+ "if part number mmc 1 " CONTROL_PARTITION " control_part_number; " \
+ "then " \
+ "echo " CONTROL_PARTITION \
+ " partition number:${control_part_number};" \
+ "ab_select slot_name mmc ${mmcdev}:${control_part_number};" \
+ "else " \
+ "echo " CONTROL_PARTITION " partition not found;" \
+ "exit;" \
+ "fi;" \
+ "setenv slot_suffix _${slot_name};" \
+ "if part number mmc ${mmcdev} system${slot_suffix} " \
+ "system_part_number; then " \
+ "setenv bootargs_ab " \
+ "ro root=/dev/mmcblk${mmcdev}p${system_part_number} " \
+ "rootwait init=/init skip_initramfs " \
+ "androidboot.slot_suffix=${slot_suffix};" \
+ "echo A/B cmdline addition: ${bootargs_ab};" \
+ "setenv bootargs ${bootargs} ${bootargs_ab};" \
+ "else " \
+ "echo system${slot_suffix} partition not found;" \
+ "fi;"
+#else
+#define AB_SELECT ""
+#endif
+
#define DEFAULT_COMMON_BOOT_TI_ARGS \
"console=" CONSOLEDEV ",115200n8\0" \
"fdtfile=undefined\0" \
@@ -86,10 +126,16 @@
"mmc dev $mmcdev; " \
"mmc rescan; " \
AVB_VERIFY_CHECK \
- "part start mmc ${mmcdev} boot boot_start; " \
- "part size mmc ${mmcdev} boot boot_size; " \
- "mmc read ${loadaddr} ${boot_start} ${boot_size}; " \
- "bootm ${loadaddr}#${fdtfile};\0 "
+
[U-Boot] [PATCH v3 6/7] doc: android: Add simple guide for A/B updates
From: Ruslan Trofymenko Add a short documentation for A/B enablement and 'ab_select' command usage. Signed-off-by: Ruslan Trofymenko Signed-off-by: Igor Opaniuk Reviewed-by: Alistair Strachan Reviewed-by: Sam Protsenko Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: * Changes related to command renaming doc/README.android-ab | 67 +++ 1 file changed, 67 insertions(+) create mode 100644 doc/README.android-ab diff --git a/doc/README.android-ab b/doc/README.android-ab new file mode 100644 index 000..9f37ed5 --- /dev/null +++ b/doc/README.android-ab @@ -0,0 +1,67 @@ +Android A/B updates +=== + +Overview + + +A/B system updates ensures modern approach for system update. This feature +allows one to use two sets (or more) of partitions referred to as slots +(normally slot A and slot B). The system runs from the current slot while the +partitions in the unused slot can be updated [1]. + +A/B enablement +-- + +The A/B updates support can be activated by specifying next options in +your board configuration file: + +CONFIG_ANDROID_AB=y +CONFIG_CMD_AB_SELECT=y + +The disk space on target device must be partitioned in a way so that each +partition which needs to be updated has two or more instances. The name of +each instance must be formed by adding suffixes: _a, _b, _c, etc. +For example: boot_a, boot_b, system_a, system_b, vendor_a, vendor_b. + +As a result you can use 'ab_select' command to ensure A/B boot process in your +boot script. This command analyzes and processes A/B metadata stored on a +special partition (e.g. "misc") and determines which slot should be used for +booting up. + +Command usage +- + +ab_select + +for example: + +=> ab_select slot_name mmc 1:4 + +or + +=> ab_select slot_name mmc 1#misc + +Result: + +=> printenv slot_name +slot_name=a + +Based on this slot information, the current boot partition should be defined, +and next kernel command line parameters should be generated: + + - androidboot.slot_suffix= + - root= + +For example: + +androidboot.slot_suffix=_a root=/dev/mmcblk1p12 + +A/B metadata is organized according to AOSP reference [2]. On the first system +start with A/B enabled, when 'misc' partition doesn't contain required data, +the default A/B metadata will be created and written to 'misc' partition. + +References +-- + +[1] https://source.android.com/devices/tech/ota/ab +[2] bootable/recovery/bootloader_message/include/bootloader_message/bootloader_message.h -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/7] common: Implement A/B metadata
From: Ruslan Trofymenko
This patch determines the A/B-specific bootloader message structure
that is the basis for implementation of recovery and A/B update
functions. A/B metadata is stored in this structure and used to decide
which slot should we use to boot the device. Also some basic functions
for A/B metadata manipulation are implemented (like slot selection).
The patch was extracted from commits [1], [2] with some coding style
fixes.
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729878/2
[2]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Signed-off-by: Igor Opaniuk
Reviewed-by: Sam Protsenko
---
Changes in v3:
* Add multiple sanity checks
* Fix mix. minor code formatting issues
Changes in v2:
* Function return codes are clarified
* Some types and constants are renamed (for compactness)
* android_bootloader_message.h is renamed to android_bl_msg.h
* 'debug' calls are changed to 'log_debug'
* Order of headers is changed
* android_bl_msg.h was synced with AOSP master counterpart
common/Kconfig | 10 ++
common/Makefile | 1 +
common/android_ab.c | 290 +++
include/android_ab.h | 34 ++
include/android_bl_msg.h | 169 +++
5 files changed, 504 insertions(+)
create mode 100644 common/android_ab.c
create mode 100644 include/android_ab.h
create mode 100644 include/android_bl_msg.h
diff --git a/common/Kconfig b/common/Kconfig
index 0a14bde..fc08e31 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -767,6 +767,16 @@ config UPDATE_TFTP_MSEC_MAX
default 100
depends on UPDATE_TFTP
+config ANDROID_AB
+ bool "Android A/B updates"
+ default n
+ help
+ If enabled, adds support for the new Android A/B update model. This
+ allows the bootloader to select which slot to boot from based on the
+ information provided by userspace via the Android boot_ctrl HAL. This
+ allows a bootloader to try a new version of the system but roll back
+ to previous version if the new one didn't boot all the way.
+
endmenu
menu "Blob list"
diff --git a/common/Makefile b/common/Makefile
index ad390d0..dfa348c 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -106,6 +106,7 @@ endif
endif
obj-y += image.o
+obj-$(CONFIG_ANDROID_AB) += android_ab.o
obj-$(CONFIG_ANDROID_BOOT_IMAGE) += image-android.o
obj-$(CONFIG_$(SPL_TPL_)OF_LIBFDT) += image-fdt.o
obj-$(CONFIG_$(SPL_TPL_)FIT) += image-fit.o
diff --git a/common/android_ab.c b/common/android_ab.c
new file mode 100644
index 000..3a6a52c
--- /dev/null
+++ b/common/android_ab.c
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (C) 2017 The Android Open Source Project
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * Compute the CRC-32 of the bootloader control struct.
+ *
+ * Only the bytes up to the crc32_le field are considered for the CRC-32
+ * calculation.
+ */
+static uint32_t ab_control_compute_crc(struct andr_bl_control *abc)
+{
+ return crc32(0, (void *)abc, offsetof(typeof(*abc), crc32_le));
+}
+
+/**
+ * Initialize andr_bl_control to the default value.
+ *
+ * It allows us to boot all slots in order from the first one. This value
+ * should be used when the bootloader message is corrupted, but not when
+ * a valid message indicates that all slots are unbootable.
+ */
+static int ab_control_default(struct andr_bl_control *abc)
+{
+ int i;
+ const struct andr_slot_metadata metadata = {
+ .priority = 15,
+ .tries_remaining = 7,
+ .successful_boot = 0,
+ .verity_corrupted = 0,
+ .reserved = 0
+ };
+
+ if (!abc)
+ return -EINVAL;
+
+ memcpy(abc->slot_suffix, "a\0\0\0", 4);
+ abc->magic = ANDROID_BOOT_CTRL_MAGIC;
+ abc->version = ANDROID_BOOT_CTRL_VERSION;
+ abc->nb_slot = ANDROID_NUM_SLOTS;
+ memset(abc->reserved0, 0, sizeof(abc->reserved0));
+ for (i = 0; i < abc->nb_slot; ++i)
+ abc->slot_info[i] = metadata;
+
+ memset(abc->reserved1, 0, sizeof(abc->reserved1));
+ abc->crc32_le = ab_control_compute_crc(abc);
+
+ return 0;
+}
+
+/**
+ * Load the boot_control struct from disk into newly allocated memory.
+ *
+ * This function allocates and returns an integer number of disk blocks,
+ * based on the block size of the passed device to help performing a
+ * read-modify-write operation on the boot_control struct.
+ * The boot_control struct offset (2 KiB) must be a multiple of the device
+ * block size, for simplicity.
+ *
+ * @param[in] dev_desc Device where to read the boot_control struct from
+ * @param[in] part_info Partition in 'dev_desc' where to read from, normally
+ * the "misc" partition should be used
+ * @param[out]
[U-Boot] [PATCH v3 4/7] cmd: Add 'ab_select' command
From: Ruslan Trofymenko
For A/B system update support the Android boot process requires to send
'androidboot.slot_suffix' parameter as a command line argument. This
patch implementes 'ab_select' command which allows us to obtain current
slot by processing the A/B metadata.
The patch was extracted from commit [1] with one modification: the
separator for specifying the name of metadata partition was changed
from ';' to '#', because ';' is used for commands separation.
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Signed-off-by: Igor Opaniuk
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
---
Changes in v3: None
Changes in v2:
* 'android_ab_select' command is renamed to 'ab_select' command
* command is moved to the separate 'Android support commands' menu
cmd/Kconfig | 15 +++
cmd/Makefile| 1 +
cmd/ab_select.c | 52
3 files changed, 68 insertions(+)
create mode 100644 cmd/ab_select.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 3ea42e4..290a570 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1123,6 +1123,21 @@ config CMD_SETEXPR
endmenu
+menu "Android support commands"
+
+config CMD_AB_SELECT
+ bool "ab_select"
+ default n
+ depends on ANDROID_AB
+ help
+ On Android devices with more than one boot slot (multiple copies of
+ the kernel and system images) this provides a command to select which
+ slot should be used to boot from and register the boot attempt. This
+ is used by the new A/B update model where one slot is updated in the
+ background while running from the other slot.
+
+endmenu
+
if NET
menuconfig CMD_NET
diff --git a/cmd/Makefile b/cmd/Makefile
index 15ae4d2..ea03eb0 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -12,6 +12,7 @@ obj-y += version.o
# command
obj-$(CONFIG_CMD_AES) += aes.o
+obj-$(CONFIG_CMD_AB_SELECT) += ab_select.o
obj-$(CONFIG_CMD_ADC) += adc.o
obj-$(CONFIG_CMD_ARMFLASH) += armflash.o
obj-y += blk_common.o
diff --git a/cmd/ab_select.c b/cmd/ab_select.c
new file mode 100644
index 000..2a9e524
--- /dev/null
+++ b/cmd/ab_select.c
@@ -0,0 +1,52 @@
+// SPDX-License-Identifier: BSD-2-Clause
+/*
+ * Copyright (C) 2017 The Android Open Source Project
+ */
+
+#include
+#include
+
+static int do_ab_select(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ int ret;
+ struct blk_desc *dev_desc;
+ disk_partition_t part_info;
+ char slot[2];
+
+ if (argc != 4)
+ return CMD_RET_USAGE;
+
+ /* Lookup the "misc" partition from argv[2] and argv[3] */
+ if (part_get_info_by_dev_and_name_or_num(argv[2], argv[3],
+_desc, _info) < 0) {
+ return CMD_RET_FAILURE;
+ }
+
+ ret = ab_select_slot(dev_desc, _info);
+ if (ret < 0) {
+ printf("Android boot failed, error %d.\n", ret);
+ return CMD_RET_FAILURE;
+ }
+
+ /* Android standard slot names are 'a', 'b', ... */
+ slot[0] = ANDROID_BOOT_SLOT_NAME(ret);
+ slot[1] = '\0';
+ env_set(argv[1], slot);
+ printf("ANDROID: Booting slot: %s\n", slot);
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(ab_select, 4, 0, do_ab_select,
+ "Select the slot used to boot from and register the boot attempt.",
+ " \n"
+ "- Load the slot metadata from the partition 'part' on\n"
+ " device type 'interface' instance 'dev' and store the active\n"
+ " slot in the 'slot_var_name' variable. This also updates the\n"
+ " Android slot metadata with a boot attempt, which can cause\n"
+ " successive calls to this function to return a different
result\n"
+ " if the returned slot runs out of boot attempts.\n"
+ "- If 'part_name' is passed, preceded with a # instead of :,
the\n"
+ " partition name whose label is 'part_name' will be looked up
in\n"
+ " the partition table. This is commonly the \"misc\"
partition.\n"
+);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 5/7] test/py: Add base test case for A/B updates
From: Ruslan Trofymenko
Add sandbox test for 'ab_select' command.
Test: ./test/py/test.py --bd sandbox --build -k test_ab
Signed-off-by: Ruslan Trofymenko
Signed-off-by: Igor Opaniuk
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2:
* Changes related to command renaming (android_ab_select->ab_select).
* Assertion condition was clarified. Full command output is controlled.
configs/sandbox_defconfig | 2 ++
test/py/tests/test_ab.py | 74 +++
2 files changed, 76 insertions(+)
create mode 100644 test/py/tests/test_ab.py
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 193e418..31c18ad 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -20,6 +20,7 @@ CONFIG_PRE_CON_BUF_ADDR=0x10
CONFIG_LOG_MAX_LEVEL=6
CONFIG_LOG_ERROR_RETURN=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
CONFIG_CMD_LICENSE=y
CONFIG_CMD_BOOTZ=y
@@ -48,6 +49,7 @@ CONFIG_CMD_SF=y
CONFIG_CMD_SPI=y
CONFIG_CMD_USB=y
CONFIG_CMD_AXI=y
+CONFIG_CMD_AB_SELECT=y
CONFIG_CMD_TFTPPUT=y
CONFIG_CMD_TFTPSRV=y
CONFIG_CMD_RARP=y
diff --git a/test/py/tests/test_ab.py b/test/py/tests/test_ab.py
new file mode 100644
index 000..b90ca87
--- /dev/null
+++ b/test/py/tests/test_ab.py
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2018 Texas Instruments,
+
+# Test A/B update commands.
+
+import os
+import pytest
+import u_boot_utils
+
+class ABTestDiskImage(object):
+"""Disk Image used by the A/B tests."""
+
+def __init__(self, u_boot_console):
+"""Initialize a new ABTestDiskImage object.
+
+Args:
+u_boot_console: A U-Boot console.
+
+Returns:
+Nothing.
+"""
+
+filename = 'test_ab_disk_image.bin'
+
+persistent = u_boot_console.config.persistent_data_dir + '/' + filename
+self.path = u_boot_console.config.result_dir + '/' + filename
+
+with u_boot_utils.persistent_file_helper(u_boot_console.log,
persistent):
+if os.path.exists(persistent):
+u_boot_console.log.action('Disk image file ' + persistent +
+' already exists')
+else:
+u_boot_console.log.action('Generating ' + persistent)
+fd = os.open(persistent, os.O_RDWR | os.O_CREAT)
+os.ftruncate(fd, 524288)
+os.close(fd)
+cmd = ('sgdisk', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+cmd = ('sgdisk', '--new=1:64:512', '-c 1:misc', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+cmd = ('sgdisk', '-l', persistent)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+cmd = ('cp', persistent, self.path)
+u_boot_utils.run_and_log(u_boot_console, cmd)
+
+di = None
+@pytest.fixture(scope='function')
+def ab_disk_image(u_boot_console):
+global di
+if not di:
+di = ABTestDiskImage(u_boot_console)
+return di
+
+@pytest.mark.boardspec('sandbox')
+@pytest.mark.buildconfigspec('android_ab')
+@pytest.mark.buildconfigspec('cmd_ab_select')
+@pytest.mark.requiredtool('sgdisk')
+def test_ab(ab_disk_image, u_boot_console):
+"""Test the 'ab_select' command."""
+
+u_boot_console.run_command('host bind 0 ' + ab_disk_image.path)
+
+output = u_boot_console.run_command('ab_select slot_name host 0#misc')
+assert 're-initializing A/B metadata' in output
+assert 'Attempting slot a, tries remaining 7' in output
+output = u_boot_console.run_command('printenv slot_name')
+assert 'slot_name=a' in output
+
+output = u_boot_console.run_command('ab_select slot_name host 0:1')
+assert 'Attempting slot b, tries remaining 7' in output
+output = u_boot_console.run_command('printenv slot_name')
+assert 'slot_name=b' in output
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/7] disk: part: Extend API to get partition info
From: Ruslan Trofymenko
This patch adds part_get_info_by_dev_and_name_or_num() function which
allows us to get partition info from its number or name. Partition of
interest is specified by string like "device_num:partition_number" or
"device_num#partition_name".
The patch was extracted from [1].
[1]
https://android-review.googlesource.com/c/platform/external/u-boot/+/729880/2
Signed-off-by: Ruslan Trofymenko
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2:
* Error codes are changed to -EINVAL instead of -1
disk/part.c| 68 ++
include/part.h | 21 ++
2 files changed, 89 insertions(+)
diff --git a/disk/part.c b/disk/part.c
index f30f9e9..7b739ad 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -675,6 +675,74 @@ int part_get_info_by_name(struct blk_desc *dev_desc, const
char *name,
return part_get_info_by_name_type(dev_desc, name, info, PART_TYPE_ALL);
}
+/**
+ * Get partition info from device number and partition name.
+ *
+ * Parse a device number and partition name string in the form of
+ * "device_num#partition_name", for example "0#misc". If the partition
+ * is found, sets dev_desc and part_info accordingly with the information
+ * of the partition with the given partition_name.
+ *
+ * @param[in] dev_iface Device interface
+ * @param[in] dev_part_str Input string argument, like "0#misc"
+ * @param[out] dev_desc Place to store the device description pointer
+ * @param[out] part_info Place to store the partition information
+ * @return 0 on success, or a negative on error
+ */
+static int part_get_info_by_dev_and_name(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+ char *ep;
+ const char *part_str;
+ int dev_num;
+
+ part_str = strchr(dev_part_str, '#');
+ if (!part_str || part_str == dev_part_str)
+ return -EINVAL;
+
+ dev_num = simple_strtoul(dev_part_str, , 16);
+ if (ep != part_str) {
+ /* Not all the first part before the # was parsed. */
+ return -EINVAL;
+ }
+ part_str++;
+
+ *dev_desc = blk_get_dev(dev_iface, dev_num);
+ if (!*dev_desc) {
+ printf("Could not find %s %d\n", dev_iface, dev_num);
+ return -EINVAL;
+ }
+ if (part_get_info_by_name(*dev_desc, part_str, part_info) < 0) {
+ printf("Could not find \"%s\" partition\n", part_str);
+ return -EINVAL;
+ }
+ return 0;
+}
+
+int part_get_info_by_dev_and_name_or_num(const char *dev_iface,
+const char *dev_part_str,
+struct blk_desc **dev_desc,
+disk_partition_t *part_info)
+{
+ /* Split the part_name if passed as "$dev_num#part_name". */
+ if (!part_get_info_by_dev_and_name(dev_iface, dev_part_str,
+ dev_desc, part_info))
+ return 0;
+ /*
+* Couldn't lookup by name, try looking up the partition description
+* directly.
+*/
+ if (blk_get_device_part_str(dev_iface, dev_part_str,
+ dev_desc, part_info, 1) < 0) {
+ printf("Couldn't find partition %s %s\n",
+ dev_iface, dev_part_str);
+ return -EINVAL;
+ }
+ return 0;
+}
+
void part_set_generic_name(const struct blk_desc *dev_desc,
int part_num, char *name)
{
diff --git a/include/part.h b/include/part.h
index ebca546..0b5cf3d 100644
--- a/include/part.h
+++ b/include/part.h
@@ -202,6 +202,27 @@ int part_get_info_by_name(struct blk_desc *dev_desc,
const char *name, disk_partition_t *info);
/**
+ * Get partition info from dev number + part name, or dev number + part number.
+ *
+ * Parse a device number and partition description (either name or number)
+ * in the form of device number plus partition name separated by a "#"
+ * (like "device_num#partition_name") or a device number plus a partition
number
+ * separated by a ":". For example both "0#misc" and "0:1" can be valid
+ * partition descriptions for a given interface. If the partition is found,
sets
+ * dev_desc and part_info accordingly with the information of the partition.
+ *
+ * @param[in] dev_ifaceDevice interface
+ * @param[in] dev_part_str Input partition description, like "0#misc" or "0:1"
+ * @param[out] dev_descPlace to store the device description pointer
+ * @param[out] part_info Place to store the partition information
+ * @return 0 on success, or a negative on error
+ */
+int part_get_info_by_dev_and_name_or_num(const char
[U-Boot] [PATCH v3 0/7] android: implement A/B boot process
This patch series adds support for Android A/B boot process [1]. Main steps of A/B boot process are: - A/B metadata integrity check - looking for the current slot (where the system should be booting from) - getting the name of the current boot partition (boot_a or boot_b) and loading the corresponding Android boot image - getting the name of the current system partition (system_a or system_b) and passing of its full name via kernel command line (like 'root=/dev/mmcblk1p11') - passing current slot via kernel command line (like 'androidboot.slot_suffix=_a') and via A/B metadata (e.g. via misc partition) - A/B metadata processing: setting the boot success flag for current slot, handling the retry counter, etc A/B metadata is organized according to Android reference [2] and stored on 'misc' partition. On the first A/B boot process, when 'misc' partition doesn't contain required data, default A/B metadata will be created and stored in 'misc' partition. In the end of the Android boot, 'update_verifier' and 'update_engine' services are processing the A/B metadata through the Boot Control HAL. To confirm the boot was successful using current slot, "boot success" flag must be set on Android side. To enable Android A/B support in U-Boot: 1. Set the following config options: CONFIG_ANDROID_AB=y CONFIG_CMD_AB_SELECT=y 2. Change the disk layout so that it has sloted boot partitions. E.g. instead of 'boot' and 'system' partitions there should be 'boot_a', 'boot_b', 'system_a' and 'system_b' partitions. To be able to actually test this patch series, the A/B features must be implemented and enabled in Android as well (see [1] for details). Documentation and corresponding test for A/B boot is present here. The last patch in this series integrates A/B boot support on AM57xx based boards (though it's not enabled by default). Future users of A/B boot feature can use it as a reference. This series is a part of previous submission [3] by Alex Deymo. It contains only A/B feature that was stripped out from there with some modifications for using with "bootm" command preferred in upstream. Changes in v3: * Minor fixes in the ab metadata handling (added additional sanity checks). * As Ruslan Trofymenko left Linaro and won't address comments anymore, continue (added my S-b tag) upstreaming patches on my own. Changes in v2: * 'android_ab_select' command is renamed to 'ab_select' command and moved to separate 'Android support commands' menu * For am57xx boards slotted sections (e.g. system_a and system_b) are added to the default sections if CONFIG_CMD_AB_SELECT flag is defined * Returned function error codes are clarified (errno using) * Some types constants and files are renamed * Assertion condition is clarified in test case * 'debug' calls are changed to 'log_debug' * The Guide is clarified by the results of changes [1] https://source.android.com/devices/tech/ota/ab/ab_implement [2] bootable/recovery/bootloader_message/include/bootloader_message/bootloader_message.h [3] https://lists.denx.de/pipermail/u-boot/2017-April/285841.html Ruslan Trofymenko (7): cmd: part: Add 'number' sub-command disk: part: Extend API to get partition info common: Implement A/B metadata cmd: Add 'ab_select' command test/py: Add base test case for A/B updates doc: android: Add simple guide for A/B updates env: am57xx: Implement A/B boot process cmd/Kconfig | 15 +++ cmd/Makefile | 1 + cmd/ab_select.c | 52 cmd/part.c| 16 ++- common/Kconfig| 10 ++ common/Makefile | 1 + common/android_ab.c | 290 ++ configs/sandbox_defconfig | 2 + disk/part.c | 68 ++ doc/README.android-ab | 67 ++ include/android_ab.h | 34 + include/android_bl_msg.h | 169 include/environment/ti/boot.h | 58 - include/part.h| 21 +++ test/py/tests/test_ab.py | 74 +++ 15 files changed, 871 insertions(+), 7 deletions(-) create mode 100644 cmd/ab_select.c create mode 100644 common/android_ab.c create mode 100644 doc/README.android-ab create mode 100644 include/android_ab.h create mode 100644 include/android_bl_msg.h create mode 100644 test/py/tests/test_ab.py -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/7] cmd: part: Add 'number' sub-command
From: Ruslan Trofymenko
This sub-command serves for getting the partition index from
partition name. Also it can be used to test the existence of specified
partition.
Signed-off-by: Ruslan Trofymenko
Signed-off-by: Igor Opaniuk
Reviewed-by: Alistair Strachan
Reviewed-by: Sam Protsenko
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
cmd/part.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/cmd/part.c b/cmd/part.c
index bfb6488..653e13c 100644
--- a/cmd/part.c
+++ b/cmd/part.c
@@ -24,6 +24,7 @@
enum cmd_part_info {
CMD_PART_INFO_START = 0,
CMD_PART_INFO_SIZE,
+ CMD_PART_INFO_NUMBER
};
static int do_part_uuid(int argc, char * const argv[])
@@ -149,6 +150,9 @@ static int do_part_info(int argc, char * const argv[], enum
cmd_part_info param)
case CMD_PART_INFO_SIZE:
snprintf(buf, sizeof(buf), LBAF, info.size);
break;
+ case CMD_PART_INFO_NUMBER:
+ snprintf(buf, sizeof(buf), "%d", part);
+ break;
default:
printf("** Unknown cmd_part_info value: %d\n", param);
return 1;
@@ -172,6 +176,11 @@ static int do_part_size(int argc, char * const argv[])
return do_part_info(argc, argv, CMD_PART_INFO_SIZE);
}
+static int do_part_number(int argc, char * const argv[])
+{
+ return do_part_info(argc, argv, CMD_PART_INFO_NUMBER);
+}
+
static int do_part(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
if (argc < 2)
@@ -185,6 +194,8 @@ static int do_part(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
return do_part_start(argc - 2, argv + 2);
else if (!strcmp(argv[1], "size"))
return do_part_size(argc - 2, argv + 2);
+ else if (!strcmp(argv[1], "number"))
+ return do_part_number(argc - 2, argv + 2);
return CMD_RET_USAGE;
}
@@ -206,5 +217,8 @@ U_BOOT_CMD(
" part can be either partition number or partition name\n"
"part size\n"
"- set environment variable to the size of the partition (in
blocks)\n"
- " part can be either partition number or partition name"
+ " part can be either partition number or partition name\n"
+ "part number\n"
+ "- set environment variable to the partition number using the
partition name\n"
+ " part must be specified as partition name"
);
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 0/7] Add netcp networking support on K2G ICE EVM
Hi, On 02/11/2019 12:20 PM, Murali Karicheri wrote: - Resending this as I was not subscribed to u-boot mailing list when the initial patch series was sent. Sorry for the trouble. This patch series add networking capability to K2G ICE EVM based on netcp driver. Networking function has been tested using the latest master branch from u-boot repo. Following boot mode has been tested for networking. Net boot (tftp images over ethernet interface and boot kernel) log at https://pastebin.ubuntu.com/p/b3nyCXPhWc/ MMC boot: (load images from boot folder of rootfs and boot kernel) log at https://pastebin.ubuntu.com/p/FWycmKd9KB/ Used Linux upstream linux kernel version 4.19.9 for the tests. Please review and apply if this looks good. A gentle reminder to review and apply. Thanks and regards, Murali Thanks Murali Karicheri (7): ARM: k2g-ice: Add pinmux support for rgmii interface ARM: k2g-gp-evm: update to rgmii pinmux configuration net: netcp: add support for phy with rgmii ids ARM: k2g: add a workaround to reset the phy k2g: config enable ti phy dp83867 for k2g ARM: dts: k2g-evm: remove unused phy-mode property from phy node ARM: dts: k2g-ice: add dt node for netcp arch/arm/dts/keystone-k2g-evm.dts | 1 - arch/arm/dts/keystone-k2g-ice.dts | 35 + .../mach-keystone/include/mach/hardware-k2g.h | 3 ++ arch/arm/mach-keystone/include/mach/mux-k2g.h | 5 ++ board/ti/ks2_evm/board_k2g.c | 15 ++ board/ti/ks2_evm/mux-k2g.h| 51 +-- drivers/net/ti/keystone_net.c | 22 +++- include/configs/k2g_evm.h | 1 + 8 files changed, 116 insertions(+), 17 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts
On Mon, 2019-02-18 at 18:46 +0530, Anup Patel wrote:
> On Mon, Feb 18, 2019 at 5:11 PM Auer, Lukas
> wrote:
> > On Mon, 2019-02-18 at 10:01 +, Auer, Lukas wrote:
> > > On Mon, 2019-02-18 at 10:28 +0530, Anup Patel wrote:
> > > > On Tue, Feb 12, 2019 at 3:44 AM Lukas Auer
> > > > wrote:
> > > > > Harts on RISC-V boot independently and U-Boot is responsible
> > > > > for
> > > > > managing them. Functions are called on other harts with
> > > > > smp_call_function(), which sends inter-processor interrupts
> > > > > (IPIs)
> > > > > to
> > > > > all other harts. Functions are specified with their address
> > > > > and
> > > > > two
> > > > > function arguments (argument 2 and 3). The first function
> > > > > argument
> > > > > is
> > > > > always the hart ID of the hart calling the function. On the
> > > > > other
> > > > > harts,
> > > > > the IPI interrupt handler handle_ipi() must be called on
> > > > > software
> > > > > interrupts to handle the request and call the specified
> > > > > function.
> > > > >
> > > > > Functions are stored in the ipi_data data structure. Every
> > > > > hart
> > > > > has
> > > > > its
> > > > > own data structure in global data. While this is not required
> > > > > at
> > > > > the
> > > > > moment (all harts are expected to boot Linux), this does
> > > > > allow
> > > > > future
> > > > > expansion, where other harts may be used for monitoring or
> > > > > other
> > > > > tasks.
> > > > >
> > > > > Signed-off-by: Lukas Auer
> > > > > ---
> > > > >
> > > > > arch/riscv/Kconfig | 19 +
> > > > > arch/riscv/include/asm/global_data.h | 5 ++
> > > > > arch/riscv/include/asm/smp.h | 53 +
> > > > > arch/riscv/lib/Makefile | 1 +
> > > > > arch/riscv/lib/smp.c | 110
> > > > > +++
> > > > > 5 files changed, 188 insertions(+)
> > > > > create mode 100644 arch/riscv/include/asm/smp.h
> > > > > create mode 100644 arch/riscv/lib/smp.c
> > > > >
> > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > > index c45e4d73a8..c0842178dd 100644
> > > > > --- a/arch/riscv/Kconfig
> > > > > +++ b/arch/riscv/Kconfig
> > > > > @@ -116,4 +116,23 @@ config RISCV_RDTIME
> > > > > config SYS_MALLOC_F_LEN
> > > > > default 0x1000
> > > > >
> > > > > +config SMP
> > > > > + bool "Symmetric Multi-Processing"
> > > > > + help
> > > > > + This enables support for systems with more than one
> > > > > CPU.
> > > > > If
> > > > > + you say N here, U-Boot will run on single and
> > > > > multiprocessor
> > > > > + machines, but will use only one CPU of a
> > > > > multiprocessor
> > > > > + machine. If you say Y here, U-Boot will run on
> > > > > many,
> > > > > but
> > > > > not
> > > > > + all, single processor machines.
> > > > > +
> > > > > +config NR_CPUS
> > > > > + int "Maximum number of CPUs (2-32)"
> > > > > + range 2 32
> > > > > + depends on SMP
> > > > > + default "8"
> > > > > + help
> > > > > + On multiprocessor machines, U-Boot sets up a stack
> > > > > for
> > > > > each CPU.
> > > > > + Stack memory is pre-allocated. U-Boot must
> > > > > therefore
> > > > > know
> > > > > the
> > > > > + maximum number of CPUs that may be present.
> > > > > +
> > > > > endmenu
> > > > > diff --git a/arch/riscv/include/asm/global_data.h
> > > > > b/arch/riscv/include/asm/global_data.h
> > > > > index a3a342c6e1..23a5f35af5 100644
> > > > > --- a/arch/riscv/include/asm/global_data.h
> > > > > +++ b/arch/riscv/include/asm/global_data.h
> > > > > @@ -10,12 +10,17 @@
> > > > > #ifndef__ASM_GBL_DATA_H
> > > > > #define __ASM_GBL_DATA_H
> > > > >
> > > > > +#include
> > > > > +
> > > > > /* Architecture-specific global data */
> > > > > struct arch_global_data {
> > > > > long boot_hart; /* boot hart id */
> > > > > #ifdef CONFIG_SIFIVE_CLINT
> > > > > void __iomem *clint;/* clint base address */
> > > > > #endif
> > > > > +#ifdef CONFIG_SMP
> > > > > + struct ipi_data ipi[CONFIG_NR_CPUS];
> > > >
> > > > The data passed by "main HART" via global data to other HARTs
> > > > is not visible reliably and randomly few HARTs fail to enter
> > > > Linux
> > > > kernel on my board. I am suspecting per-HART "ipi" data in
> > > > global
> > > > data not being cache-line aligned as the cause of behavior but
> > > > there
> > > > could be other issue too.
> > > >
> > > > I have a hack which works reliable for me. As-per this hack, we
> > > > add
> > > > "mdelay(10)" just before calling riscv_send_ipi() in
> > > > send_ipi_many().
> > > > This hack helped me conclude that there is some sync issue in
> > > > per-
> > > > HART
> > > > "ipi" data.
> > > >
> > > > The above issue is not seen on QEMU so we are fine there.
> > > >
> > > > I would suggest to make per-HART "ipi" data cache-line aligned
> > > > (just like Linux kernel).
>
Re: [U-Boot] configs: move CONFIG_SPL_TEXT_BASE to Kconfig
On Thu, Feb 14, 2019 at 07:28:18PM +0100, Simon Goldschmidt wrote: > Am 19.01.2019 um 17:57 schrieb Tom Rini: > >On Sat, Jan 19, 2019 at 05:52:46PM +0100, Simon Goldschmidt wrote: > >>Hi Tom, > >> > >>Am Fr., 18. Jan. 2019, 23:02 hat Tom Rini geschrieben: > >> > >>>On Mon, Jan 07, 2019 at 10:12:42AM +0100, Simon Goldschmidt wrote: > On Wed, Jan 2, 2019 at 9:13 PM Simon Goldschmidt > wrote: > > > >Hi Marek, > > > >Am 14.11.2018 um 19:51 schrieb Simon Goldschmidt: > >>On 07.10.2018 02:49, Tom Rini wrote: > >>>On Sun, Sep 30, 2018 at 02:31:53PM +0200, Simon Goldschmidt wrote: > >>> > Moved CONFIG_SPL_TEXT_BASE to common/spl/Kconfig with > help from moveconfig.py (only had to prepare socfpga, > stm32f746 and am33x/43x manually) > > Signed-off-by: Simon Goldschmidt > --- > > This patch is in preparation for boot-from-FPGA for > socfpga cyclone5, where we need a different SPL_TEXT_BASE. > By moving this to Kconfig, this can then be done via > defconfig. > > I did notice that some defconfig files change more than > necessary, it seems like they are out of sync? > >>>So, I see at least one set of problems with the conversion, the > >>>am33* > >>>family gets put to 0x0 which isn't right. I'm going to pull out the > >>>print tool I made and posted a while back and use that for > >>>conversion. > >>>Thanks for the starting point! > >> > >>Tom, what's the status on this? I still can't build an SPL for > >>>socfpga > >>gen5 boot from FPGA because I can't change SPL_TEXT_BASE. > >> > >>Marek, if getting CONFIG_SPL_TEXT_BASE into 2019.01 won't work, can > >>>we > >>have a separate (k)config option for socfpga only? That might be > >>>useful > >>anyway as when booting from fpga, there is no 64 KByte size limit and > >>the "magic value into magic register to unlock support for issuing > >>>warm > >>reset" must not be written as the SPL is not in SRAM. But that might > >>have its separate config option, too... > >> > >>Anyway, I just need input to know in which direction I should > >>>continue. > >>I'm waiting to get all our versions of SPL and U-Boot running from > >>mainline (with only board configs added for our private boards). > > > >I still cannot build an SPL to boot from FPGA since > >>>CONFIG_SPL_TEXT_BASE > >is hard-coded to OnChip RAM (while when booting from FPGA, it has to be > >placed into the FPGA bridge). > > > >Since both Tom and myself did not seem to have immediate luck with > >bringing CONFIG_SPL_TEXT_BASE to Kconfig, may I suggest to add a > >>>Kconfig > >option 'Boot from FPGA' for socfpga_gen5? > > > >Or do you have another idea at hand of how to proceed here? > > > >Please note that there might be other settings that may change when > >booting from FPGA, e.g. the maximum code size for SPL is not limited > >>>any > >more. > > Gentle ping? > > I'd really like to get boot-from-FPGA finally working in the next > >>>release! > >>> > >>>So, migrating CONFIG_SPL_TEXT_BASE. A problem is that we don't get the > >>>value for CONFIG_SPL_TEXT_BASE, only CONFIG_TEXT_BASE, once we move it > >>>to Kconfig and are building non-SPL. This is a problem for the TI K2 > >>>boards. This however can be fixed by leveraging Andrew's patch[1] as > >>>"ISW" is just a generic term and we can set that on the K2 platforms and > >>>adjust CONFIG_SYS_INIT_SP_ADDR to use that. Next, rockchip rk3368 needs > >>>to be updated to make use of CONFIG_TPL_TEXT_BASE via Kconfig, which > >>>exists already, rather than the workaround it's doing. Finally, some > >>>PowerPC boards that are using TPL are in a similar spot where they also > >>>need to use CONFIG_TPL_TEXT_BASE and are using the mechanic where we'll > >>>pass SPL_TEXT_BASE in TPL, if TPL_TEXT_BASE isn't set. > >>> > >>>So, what's all this mean? Well, the rockchip issue looks pretty easy to > >>>deal with and verify, so I'll tackle that first and post something > >>>shortly. The PowerPC thing also doesn't look too terrible (it's only a > >>>few headers) so I'll tackle that second. And then the TI one I'll work > >>>on 3rd, after I get Andrew's patch merged in, which should be fairly > >>>soon (v3 fixed a small issue I found when merging v2). > >>> > >>>[1]: https://patchwork.ozlabs.org/patch/1026946/ > >> > >> > >>So I'm still kind of waiting for this to get socfpga booting from fpga (at > >>least gen5 needs a special linker address for spl to boot from fpga). > >> > >>Do you think this will make it for 2019.04? Because if not, I'll try to > >>convince Marek to add an socfpga-specific kconfig option "boot from fpga" > >>to finally get this working... > > > >Good question. I kicked this around, harder, after posting. I have a > >re-work of how we generate
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote:
> On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > 'SET_BLOCKLEN' may occasionally fail on first attempt.
> Why ?
This is part of the workaround of mmc driver which is enabled with
'CONFIG_MMC_QUIRKS' config.
https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d82952e05a591
efd0683/drivers/mmc/mmc.c#L272
>
> >
> > This patch enable a small delay in dwmci_send_cmd() on
> > busy, I/O or CRC error to allow the MMC controller recovers
> > from the failure/error on subsequent retries.
> Why 100 uS ?
This is a good question. Perhaps the driver's authors can explain this.
The driver delay 100us after dwmci_send_cmd() success with the command
sent. But it never delay 100us whenever mmc controller response to the
command sent with I/O or CRC errors. MMC drivers expect the first
'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail
intermittently so it will retry up to 4 times before it gave up and
return error. Without this 100us delay after error response,
'SET_BLOCKEN' may sometime fail in 4 attempts in a row. Therefore, we
encountered intermittent failure in loading u-boot (SSBL) from MMC.
>
> Can we rather detect whether the controller recovered by polling some
> bit?
Hmmm...I can take a look at the databook of this controller and dig
further. Probably this is the limitation of the controller itself. The
mmc driver code which introduce 100us delay after every command sent in
dwmci_send_cmd() looks iffy.
>
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > drivers/mmc/dw_mmc.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> > index 7544b84..8dcc518 100644
> > --- a/drivers/mmc/dw_mmc.c
> > +++ b/drivers/mmc/dw_mmc.c
> > @@ -266,8 +266,11 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > if (data)
> > flags = dwmci_set_transfer_mode(host, data);
> >
> > - if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type &
> > MMC_RSP_BUSY))
> > - return -1;
> > + if ((cmd->resp_type & MMC_RSP_136) &&
> > + (cmd->resp_type & MMC_RSP_BUSY)) {
> > + ret = -1;
> > + goto delay_ret;
> > + }
> >
> > if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
> > flags |= DWMCI_CMD_ABORT_STOP;
> > @@ -316,11 +319,13 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > return -ETIMEDOUT;
> > } else if (mask & DWMCI_INTMSK_RE) {
> > debug("%s: Response Error.\n", __func__);
> > - return -EIO;
> > + ret = -EIO;
> > + goto delay_ret;
> > } else if ((cmd->resp_type & MMC_RSP_CRC) &&
> > (mask & DWMCI_INTMSK_RCRC)) {
> > debug("%s: Response CRC Error.\n", __func__);
> > - return -EIO;
> > + ret = -EIO;
> > + goto delay_ret;
> > }
> >
> >
> > @@ -347,6 +352,7 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > }
> > }
> >
> > +delay_ret:
> > udelay(100);
> >
> > return ret;
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-video
On Sat, Feb 16, 2019 at 11:57:04PM +0100, Anatolij Gustschin wrote: > Hi Tom, > > please pull some video updates for v2019.04-rc2. > > Travis CI: https://travis-ci.org/vdsao/u-boot-video/builds/493827675 > > Thanks, > Anatolij > > The following changes since commit 63f7e3fca391a50a499fed828fe16325fdee45f3: > > Merge tag 'signed-efi-next' of git://github.com/agraf/u-boot (2019-02-13 > 07:12:29 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-video.git tags/video-for-2019.04-rc2 > > for you to fetch changes up to e25710305da0f087a374ad41d5fa1f244469f6f2: > > video: bmp: Add support for 24bpp BMP files on 16bpp displays (2019-02-15 > 16:51:12 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-sh/master
On Sat, Feb 16, 2019 at 06:12:38PM +0100, Marek Vasut wrote: > The following changes since commit d391c13c99a2b48c98cef6df4479247cd4e62f9d: > > Merge tag 'xilinx-for-v2019.04-rc2' of > git://git.denx.de/u-boot-microblaze (2019-02-15 21:21:28 -0500) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to 261445dfafdce252f91fea16517aba5830dd1930: > > mmc: tmio: sdhi: Configure DT2FF register for HS400 mode (2019-02-16 > 18:12:17 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/9] regulator: Add support for ramp delay
On Mon, 18 Feb 2019 at 15:03, Torsten Duwe wrote: > > On Sat, Feb 16, 2019 at 10:45:45AM +0100, Krzysztof Kozlowski wrote: > > Changing voltage and enabling regulator might require delays so the > > regulator stabilizes at expected level. > > > > Add support for "regulator-ramp-delay" binding which can introduce > > required time to both enabling the regulator and to changing the > > voltage. > > I'm surprised that such a thing doesn't exist already. > > > Signed-off-by: Krzysztof Kozlowski > > > --- a/doc/device-tree-bindings/regulator/regulator.txt > > +++ b/doc/device-tree-bindings/regulator/regulator.txt > > @@ -35,6 +35,7 @@ Optional properties: > > - regulator-max-microamp: a maximum allowed Current value > > - regulator-always-on: regulator should never be disabled > > - regulator-boot-on: enabled by bootloader/firmware > > +- regulator-ramp-delay: ramp delay for regulator (in uV/us) > > I guess you mean s/V, not V/s; at least the code suggests so. uV/uS. It is correct in the code: int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay); delay = (uV - uV) / (uV / uS) = uS > But my main point is: is the required delay always a linear > function of the voltage jump? Depending on the dampening and > load on the rail this could be an overshoot and settle, no? > > So I suggest to make that an array with 2 elements: a fixed part > and a time per voltage change. Does that make sense? Just to make it clear - then we do not follow Linux kernel DT bindings. The voltage change might have exponential characteristic and/or have additional fixed delay time (see patch 7 here). We could re-use some properties from Linux bindings for that purpose: https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L19 https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/regulator/regulator.txt#L24 Best regards, Krzysztof ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation
Hi Prabhakar, On 18.02.19 14:56, Prabhakar Kushwaha wrote: Hi Prafulla, Luka, Stefan, Tom and Albert -Original Message- From: Meenakshi Aggarwal Sent: Monday, February 18, 2019 7:16 PM To: Prabhakar Kushwaha ; u- b...@lists.denx.de; York Sun Cc: Udit Kumar Subject: RE: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation -Original Message- From: Prabhakar Kushwaha Sent: Monday, February 18, 2019 6:37 PM To: Meenakshi Aggarwal ; u- b...@lists.denx.de; York Sun Cc: Meenakshi Aggarwal ; Udit Kumar Subject: RE: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation -Original Message- From: Meenakshi Aggarwal Sent: Tuesday, February 19, 2019 12:09 AM To: u-boot@lists.denx.de; Prabhakar Kushwaha ; York Sun Cc: Meenakshi Aggarwal ; Udit Kumar Subject: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation Flush L3 cache after uboot relocated to DDR. Signed-off-by: Meenakshi Aggarwal Signed-off-by: Udit Kumar --- arch/arm/lib/relocate_64.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index 171d094..7603f52 100644 --- a/arch/arm/lib/relocate_64.S +++ b/arch/arm/lib/relocate_64.S @@ -85,6 +85,7 @@ relocate_done: isb sy 4:ldp x0, x1, [sp, #16] bl __asm_flush_dcache_range + bl __asm_flush_l3_dcache This change is happening for every arm platform. There can be platform not having l3 cache. How It is taken care? This function is defined as weak in arch/arm/cpu/armv8/cache.S for all other platforms except arch/arm/mach-mvebu/armada8k/cache_llc.S arch/arm/mach-tegra/tegra186/cache.S Considering __asm_flush_l3_dcache is a weak function and only defined for armada, tegra and NXP. This patch logically looks fine as after relocation to DDR, all cache should be flushed. Do you foresee any issue with this patch. Looks fine to me as well (without testing). So: Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation
Hi Prafulla, Luka, Stefan, Tom and Albert > -Original Message- > From: Meenakshi Aggarwal > Sent: Monday, February 18, 2019 7:16 PM > To: Prabhakar Kushwaha ; u- > b...@lists.denx.de; York Sun > Cc: Udit Kumar > Subject: RE: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation > > > > > -Original Message- > > From: Prabhakar Kushwaha > > Sent: Monday, February 18, 2019 6:37 PM > > To: Meenakshi Aggarwal ; u- > > b...@lists.denx.de; York Sun > > Cc: Meenakshi Aggarwal ; Udit Kumar > > > > Subject: RE: [PATCH] L3 cache : arch : arm : lib : Flush L3 after > > relocation > > > > > > > -Original Message- > > > From: Meenakshi Aggarwal > > > Sent: Tuesday, February 19, 2019 12:09 AM > > > To: u-boot@lists.denx.de; Prabhakar Kushwaha > > > ; York Sun > > > Cc: Meenakshi Aggarwal ; Udit Kumar > > > > > > Subject: [PATCH] L3 cache : arch : arm : lib : Flush L3 after > > > relocation > > > > > > Flush L3 cache after uboot relocated to DDR. > > > > > > Signed-off-by: Meenakshi Aggarwal > > > Signed-off-by: Udit Kumar > > > --- > > > arch/arm/lib/relocate_64.S | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S > > > index > > > 171d094..7603f52 100644 > > > --- a/arch/arm/lib/relocate_64.S > > > +++ b/arch/arm/lib/relocate_64.S > > > @@ -85,6 +85,7 @@ relocate_done: > > > isb sy > > > 4: ldp x0, x1, [sp, #16] > > > bl __asm_flush_dcache_range > > > + bl __asm_flush_l3_dcache > > > > This change is happening for every arm platform. > > > > There can be platform not having l3 cache. How It is taken care? > > > This function is defined as weak in arch/arm/cpu/armv8/cache.S for all other > platforms except > > arch/arm/mach-mvebu/armada8k/cache_llc.S > arch/arm/mach-tegra/tegra186/cache.S Considering __asm_flush_l3_dcache is a weak function and only defined for armada, tegra and NXP. This patch logically looks fine as after relocation to DDR, all cache should be flushed. Do you foresee any issue with this patch. --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: fix hvc call
On 18.02.19 14:10, Ibai Erkiaga wrote: > HVC call makes use of 6 arguments rather than 7 in the same way as SMC > calls. The 7th argument is optional for both HVC and SMC but is > implemented as 16-bit parameter and register R7 or W7. The patch description is lacking a bit more context. Why not change SMC to also include x7? > > Signed-off-by: Ibai Erkiaga > --- > 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. This should definitely not go below the --- line as it's critical information for anyone who later on reads the commit message in the log. Alex > > 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 > > This email and any attachments are intended for the sole use of the named > recipient(s) and contain(s) confidential information that may be proprietary, > privileged or copyrighted under applicable law. If you are not the intended > recipient, do not read, copy, or forward this email message or any > attachments. Delete this email message and any attachments immediately. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation
> -Original Message- > From: Prabhakar Kushwaha > Sent: Monday, February 18, 2019 6:37 PM > To: Meenakshi Aggarwal ; u- > b...@lists.denx.de; York Sun > Cc: Meenakshi Aggarwal ; Udit Kumar > > Subject: RE: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation > > > > -Original Message- > > From: Meenakshi Aggarwal > > Sent: Tuesday, February 19, 2019 12:09 AM > > To: u-boot@lists.denx.de; Prabhakar Kushwaha > > ; York Sun > > Cc: Meenakshi Aggarwal ; Udit Kumar > > > > Subject: [PATCH] L3 cache : arch : arm : lib : Flush L3 after > > relocation > > > > Flush L3 cache after uboot relocated to DDR. > > > > Signed-off-by: Meenakshi Aggarwal > > Signed-off-by: Udit Kumar > > --- > > arch/arm/lib/relocate_64.S | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S > > index > > 171d094..7603f52 100644 > > --- a/arch/arm/lib/relocate_64.S > > +++ b/arch/arm/lib/relocate_64.S > > @@ -85,6 +85,7 @@ relocate_done: > > isb sy > > 4: ldp x0, x1, [sp, #16] > > bl __asm_flush_dcache_range > > + bl __asm_flush_l3_dcache > > This change is happening for every arm platform. > > There can be platform not having l3 cache. How It is taken care? > This function is defined as weak in arch/arm/cpu/armv8/cache.S for all other platforms except arch/arm/mach-mvebu/armada8k/cache_llc.S arch/arm/mach-tegra/tegra186/cache.S > --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts
On Mon, Feb 18, 2019 at 5:11 PM Auer, Lukas
wrote:
>
> On Mon, 2019-02-18 at 10:01 +, Auer, Lukas wrote:
> > On Mon, 2019-02-18 at 10:28 +0530, Anup Patel wrote:
> > > On Tue, Feb 12, 2019 at 3:44 AM Lukas Auer
> > > wrote:
> > > > Harts on RISC-V boot independently and U-Boot is responsible for
> > > > managing them. Functions are called on other harts with
> > > > smp_call_function(), which sends inter-processor interrupts
> > > > (IPIs)
> > > > to
> > > > all other harts. Functions are specified with their address and
> > > > two
> > > > function arguments (argument 2 and 3). The first function
> > > > argument
> > > > is
> > > > always the hart ID of the hart calling the function. On the other
> > > > harts,
> > > > the IPI interrupt handler handle_ipi() must be called on software
> > > > interrupts to handle the request and call the specified function.
> > > >
> > > > Functions are stored in the ipi_data data structure. Every hart
> > > > has
> > > > its
> > > > own data structure in global data. While this is not required at
> > > > the
> > > > moment (all harts are expected to boot Linux), this does allow
> > > > future
> > > > expansion, where other harts may be used for monitoring or other
> > > > tasks.
> > > >
> > > > Signed-off-by: Lukas Auer
> > > > ---
> > > >
> > > > arch/riscv/Kconfig | 19 +
> > > > arch/riscv/include/asm/global_data.h | 5 ++
> > > > arch/riscv/include/asm/smp.h | 53 +
> > > > arch/riscv/lib/Makefile | 1 +
> > > > arch/riscv/lib/smp.c | 110
> > > > +++
> > > > 5 files changed, 188 insertions(+)
> > > > create mode 100644 arch/riscv/include/asm/smp.h
> > > > create mode 100644 arch/riscv/lib/smp.c
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > index c45e4d73a8..c0842178dd 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -116,4 +116,23 @@ config RISCV_RDTIME
> > > > config SYS_MALLOC_F_LEN
> > > > default 0x1000
> > > >
> > > > +config SMP
> > > > + bool "Symmetric Multi-Processing"
> > > > + help
> > > > + This enables support for systems with more than one
> > > > CPU.
> > > > If
> > > > + you say N here, U-Boot will run on single and
> > > > multiprocessor
> > > > + machines, but will use only one CPU of a multiprocessor
> > > > + machine. If you say Y here, U-Boot will run on many,
> > > > but
> > > > not
> > > > + all, single processor machines.
> > > > +
> > > > +config NR_CPUS
> > > > + int "Maximum number of CPUs (2-32)"
> > > > + range 2 32
> > > > + depends on SMP
> > > > + default "8"
> > > > + help
> > > > + On multiprocessor machines, U-Boot sets up a stack for
> > > > each CPU.
> > > > + Stack memory is pre-allocated. U-Boot must therefore
> > > > know
> > > > the
> > > > + maximum number of CPUs that may be present.
> > > > +
> > > > endmenu
> > > > diff --git a/arch/riscv/include/asm/global_data.h
> > > > b/arch/riscv/include/asm/global_data.h
> > > > index a3a342c6e1..23a5f35af5 100644
> > > > --- a/arch/riscv/include/asm/global_data.h
> > > > +++ b/arch/riscv/include/asm/global_data.h
> > > > @@ -10,12 +10,17 @@
> > > > #ifndef__ASM_GBL_DATA_H
> > > > #define __ASM_GBL_DATA_H
> > > >
> > > > +#include
> > > > +
> > > > /* Architecture-specific global data */
> > > > struct arch_global_data {
> > > > long boot_hart; /* boot hart id */
> > > > #ifdef CONFIG_SIFIVE_CLINT
> > > > void __iomem *clint;/* clint base address */
> > > > #endif
> > > > +#ifdef CONFIG_SMP
> > > > + struct ipi_data ipi[CONFIG_NR_CPUS];
> > >
> > > The data passed by "main HART" via global data to other HARTs
> > > is not visible reliably and randomly few HARTs fail to enter Linux
> > > kernel on my board. I am suspecting per-HART "ipi" data in global
> > > data not being cache-line aligned as the cause of behavior but
> > > there
> > > could be other issue too.
> > >
> > > I have a hack which works reliable for me. As-per this hack, we add
> > > "mdelay(10)" just before calling riscv_send_ipi() in
> > > send_ipi_many().
> > > This hack helped me conclude that there is some sync issue in per-
> > > HART
> > > "ipi" data.
> > >
> > > The above issue is not seen on QEMU so we are fine there.
> > >
> > > I would suggest to make per-HART "ipi" data cache-line aligned
> > > (just like Linux kernel).
> > >
> >
> > Interesting, this is definitely a memory coherency issue, probably
> > inadequate fences. I am not sure if making the ipi data structure
> > cache-line aligned will reliably fix it. I'll try to replicate the
> > issue and get it fixed. Thanks for reporting it!
> >
>
> Not sure if it is connected, but I have noticed a regression with the
> current OpenSBI. Testing U-Boot with the SMP patches applied on QEMU
> with 4 harts, hart 4 will not
Re: [U-Boot] [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation
> -Original Message- > From: Meenakshi Aggarwal > Sent: Tuesday, February 19, 2019 12:09 AM > To: u-boot@lists.denx.de; Prabhakar Kushwaha > ; York Sun > Cc: Meenakshi Aggarwal ; Udit Kumar > > Subject: [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation > > Flush L3 cache after uboot relocated to DDR. > > Signed-off-by: Meenakshi Aggarwal > Signed-off-by: Udit Kumar > --- > arch/arm/lib/relocate_64.S | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index > 171d094..7603f52 100644 > --- a/arch/arm/lib/relocate_64.S > +++ b/arch/arm/lib/relocate_64.S > @@ -85,6 +85,7 @@ relocate_done: > isb sy > 4: ldp x0, x1, [sp, #16] > bl __asm_flush_dcache_range > + bl __asm_flush_l3_dcache This change is happening for every arm platform. There can be platform not having l3 cache. How It is taken care? --pk ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] pinctrl: renesas: Drop def_bool per SoC
Drop per SoC def_bool on each driver, since this is now implied by SoC Kconfig option instead. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- drivers/pinctrl/renesas/Kconfig | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/pinctrl/renesas/Kconfig b/drivers/pinctrl/renesas/Kconfig index 1baab9088a..0cb577037c 100644 --- a/drivers/pinctrl/renesas/Kconfig +++ b/drivers/pinctrl/renesas/Kconfig @@ -8,7 +8,6 @@ config PINCTRL_PFC config PINCTRL_PFC_R8A7790 bool "Renesas RCar Gen2 R8A7790 pin control driver" - def_bool y if R8A7790 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7790 SoCs. @@ -19,7 +18,6 @@ config PINCTRL_PFC_R8A7790 config PINCTRL_PFC_R8A7791 bool "Renesas RCar Gen2 R8A7791 pin control driver" - def_bool y if R8A7791 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7791 SoCs. @@ -30,7 +28,6 @@ config PINCTRL_PFC_R8A7791 config PINCTRL_PFC_R8A7792 bool "Renesas RCar Gen2 R8A7792 pin control driver" - def_bool y if R8A7792 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7792 SoCs. @@ -41,7 +38,6 @@ config PINCTRL_PFC_R8A7792 config PINCTRL_PFC_R8A7793 bool "Renesas RCar Gen2 R8A7793 pin control driver" - def_bool y if R8A7793 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7793 SoCs. @@ -52,7 +48,6 @@ config PINCTRL_PFC_R8A7793 config PINCTRL_PFC_R8A7794 bool "Renesas RCar Gen2 R8A7794 pin control driver" - def_bool y if R8A7794 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7794 SoCs. @@ -63,7 +58,6 @@ config PINCTRL_PFC_R8A7794 config PINCTRL_PFC_R8A7795 bool "Renesas RCar Gen3 R8A7795 pin control driver" - def_bool y if R8A7795 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7795 SoCs. @@ -74,7 +68,6 @@ config PINCTRL_PFC_R8A7795 config PINCTRL_PFC_R8A7796 bool "Renesas RCar Gen3 R8A7796 pin control driver" - def_bool y if R8A7796 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A7796 SoCs. @@ -85,7 +78,6 @@ config PINCTRL_PFC_R8A7796 config PINCTRL_PFC_R8A77970 bool "Renesas RCar Gen3 R8A77970 pin control driver" - def_bool y if R8A77970 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77970 SoCs. @@ -96,7 +88,6 @@ config PINCTRL_PFC_R8A77970 config PINCTRL_PFC_R8A77990 bool "Renesas RCar Gen3 R8A77990 pin control driver" - def_bool y if R8A77990 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77990 SoCs. @@ -107,7 +98,6 @@ config PINCTRL_PFC_R8A77990 config PINCTRL_PFC_R8A77995 bool "Renesas RCar Gen3 R8A77995 pin control driver" - def_bool y if R8A77995 depends on PINCTRL_PFC help Support pin multiplexing control on Renesas RCar Gen3 R8A77995 SoCs. -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] ARM: rmobile: Sync Gen3 defconfigs
Synchronize Gen3 defconfigs in wake of the Kconfig option changes. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- configs/r8a77965_salvator-x_defconfig | 1 - configs/r8a7796_salvator-x_defconfig | 1 - configs/r8a7796_ulcb_defconfig| 1 - 3 files changed, 3 deletions(-) diff --git a/configs/r8a77965_salvator-x_defconfig b/configs/r8a77965_salvator-x_defconfig index 82ebab06c3..9965036123 100644 --- a/configs/r8a77965_salvator-x_defconfig +++ b/configs/r8a77965_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_salvator-x_defconfig b/configs/r8a7796_salvator-x_defconfig index ae0555cd85..09626bf8b6 100644 --- a/configs/r8a7796_salvator-x_defconfig +++ b/configs/r8a7796_salvator-x_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_SALVATOR_X=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y diff --git a/configs/r8a7796_ulcb_defconfig b/configs/r8a7796_ulcb_defconfig index f3781a57e2..1f2de9d71b 100644 --- a/configs/r8a7796_ulcb_defconfig +++ b/configs/r8a7796_ulcb_defconfig @@ -3,7 +3,6 @@ CONFIG_ARCH_RMOBILE=y CONFIG_SYS_TEXT_BASE=0x5000 CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_RCAR_GEN3=y -CONFIG_R8A7796=y CONFIG_TARGET_ULCB=y CONFIG_SMBIOS_PRODUCT_NAME="" CONFIG_FIT=y -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] ARM: rmobile: Imply SoC per board
Imply all SoCs supported by a given board. This allows building single U-Boot binary for boards which can have multiple SoCs. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- arch/arm/mach-rmobile/Kconfig.64 | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index d231263574..b2ac1cdad7 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -1,7 +1,6 @@ if RCAR_GEN3 -choice - prompt "Select Target SoC" +menu "Select Target SoC" config R8A7795 bool "Renesas SoC R8A7795" @@ -28,34 +27,41 @@ config R8A77995 imply CLK_R8A77995 imply PINCTRL_PFC_R8A77995 -endchoice +endmenu choice - prompt "Renesus ARM64 SoCs board select" + prompt "Renesas ARM64 SoCs board select" optional config TARGET_DRAAK bool "Draak board" + imply R8A77995 help Support for Renesas R-Car Gen3 Draak platform config TARGET_EAGLE bool "Eagle board" + imply R8A77970 help Support for Renesas R-Car Gen3 Eagle platform config TARGET_EBISU bool "Ebisu board" + imply R8A77990 help Support for Renesas R-Car Gen3 Ebisu platform config TARGET_SALVATOR_X bool "Salvator-X board" + imply R8A7795 + imply R8A7796 help Support for Renesas R-Car Gen3 platform config TARGET_ULCB bool "ULCB board" + imply R8A7795 + imply R8A7796 help Support for Renesas R-Car Gen3 ULCB platform -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] clk: rmobile: Drop def_bool per SoC
Drop per SoC def_bool on each driver, since this is now implied by SoC Kconfig option instead. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- drivers/clk/renesas/Kconfig | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig index 578e6a8049..e062eccdae 100644 --- a/drivers/clk/renesas/Kconfig +++ b/drivers/clk/renesas/Kconfig @@ -13,35 +13,30 @@ config CLK_RCAR_GEN2 config CLK_R8A7790 bool "Renesas R8A7790 clock driver" - def_bool y if R8A7790 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7790 SoC. config CLK_R8A7791 bool "Renesas R8A7791 clock driver" - def_bool y if R8A7791 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7791 SoC. config CLK_R8A7792 bool "Renesas R8A7792 clock driver" - def_bool y if R8A7792 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7792 SoC. config CLK_R8A7793 bool "Renesas R8A7793 clock driver" - def_bool y if R8A7793 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7793 SoC. config CLK_R8A7794 bool "Renesas R8A7794 clock driver" - def_bool y if R8A7794 depends on CLK_RCAR_GEN2 help Enable this to support the clocks on Renesas R8A7794 SoC. @@ -55,35 +50,30 @@ config CLK_RCAR_GEN3 config CLK_R8A7795 bool "Renesas R8A7795 clock driver" - def_bool y if R8A7795 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A7795 SoC. config CLK_R8A7796 bool "Renesas R8A7796 clock driver" - def_bool y if R8A7796 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A7796 SoC. config CLK_R8A77970 bool "Renesas R8A77970 clock driver" - def_bool y if R8A77970 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77970 SoC. config CLK_R8A77990 bool "Renesas R8A77990 clock driver" - def_bool y if R8A77990 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77990 SoC. config CLK_R8A77995 bool "Renesas R8A77995 clock driver" - def_bool y if R8A77995 depends on CLK_RCAR_GEN3 help Enable this to support the clocks on Renesas R8A77995 SoC. -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] ARM: rmobile: Imply pinctrl drivers per SoC
Imply preferred pin control driver per SoC, no functional change. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- arch/arm/mach-rmobile/Kconfig.32 | 5 + arch/arm/mach-rmobile/Kconfig.64 | 5 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32 index 5d9da49c92..67f669a6fc 100644 --- a/arch/arm/mach-rmobile/Kconfig.32 +++ b/arch/arm/mach-rmobile/Kconfig.32 @@ -17,29 +17,34 @@ config R8A7790 select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7790 + imply PINCTRL_PFC_R8A7790 config R8A7791 bool "Renesas SoC R8A7791" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7791 + imply PINCTRL_PFC_R8A7791 config R8A7792 bool "Renesas SoC R8A7792" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7792 + imply PINCTRL_PFC_R8A7792 config R8A7793 bool "Renesas SoC R8A7793" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 imply CLK_R8A7793 + imply PINCTRL_PFC_R8A7793 config R8A7794 bool "Renesas SoC R8A7794" select RCAR_GEN2 imply CLK_R8A7794 + imply PINCTRL_PFC_R8A7794 choice prompt "Renesas ARM SoCs board select" diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index d84c0617d1..d231263574 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -6,22 +6,27 @@ choice config R8A7795 bool "Renesas SoC R8A7795" imply CLK_R8A7795 + imply PINCTRL_PFC_R8A7795 config R8A7796 bool "Renesas SoC R8A7796" imply CLK_R8A7796 + imply PINCTRL_PFC_R8A7796 config R8A77970 bool "Renesas SoC R8A77970" imply CLK_R8A77970 + imply PINCTRL_PFC_R8A77970 config R8A77990 bool "Renesas SoC R8A77990" imply CLK_R8A77990 + imply PINCTRL_PFC_R8A77990 config R8A77995 bool "Renesas SoC R8A77995" imply CLK_R8A77995 + imply PINCTRL_PFC_R8A77995 endchoice -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] ARM: rmobile: Imply clock drivers per SoC
Imply preferred clock driver per SoC, no functional change. Signed-off-by: Marek Vasut Cc: Nobuhiro Iwamatsu --- arch/arm/mach-rmobile/Kconfig.32 | 5 + arch/arm/mach-rmobile/Kconfig.64 | 5 + 2 files changed, 10 insertions(+) diff --git a/arch/arm/mach-rmobile/Kconfig.32 b/arch/arm/mach-rmobile/Kconfig.32 index 076a019135..5d9da49c92 100644 --- a/arch/arm/mach-rmobile/Kconfig.32 +++ b/arch/arm/mach-rmobile/Kconfig.32 @@ -16,25 +16,30 @@ config R8A7790 bool "Renesas SoC R8A7790" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7790 config R8A7791 bool "Renesas SoC R8A7791" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7791 config R8A7792 bool "Renesas SoC R8A7792" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7792 config R8A7793 bool "Renesas SoC R8A7793" select RCAR_GEN2 select ARM_CORTEX_A15_CVE_2017_5715 + imply CLK_R8A7793 config R8A7794 bool "Renesas SoC R8A7794" select RCAR_GEN2 + imply CLK_R8A7794 choice prompt "Renesas ARM SoCs board select" diff --git a/arch/arm/mach-rmobile/Kconfig.64 b/arch/arm/mach-rmobile/Kconfig.64 index cb9f569e5f..d84c0617d1 100644 --- a/arch/arm/mach-rmobile/Kconfig.64 +++ b/arch/arm/mach-rmobile/Kconfig.64 @@ -5,18 +5,23 @@ choice config R8A7795 bool "Renesas SoC R8A7795" + imply CLK_R8A7795 config R8A7796 bool "Renesas SoC R8A7796" + imply CLK_R8A7796 config R8A77970 bool "Renesas SoC R8A77970" + imply CLK_R8A77970 config R8A77990 bool "Renesas SoC R8A77990" + imply CLK_R8A77990 config R8A77995 bool "Renesas SoC R8A77995" + imply CLK_R8A77995 endchoice -- 2.19.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/7] arm: mach-k3: Add secure device build support
On 2/16/19 4:18 PM, Tom Rini wrote: > On Fri, Feb 15, 2019 at 05:43:32PM +0530, Lokesh Vutla wrote: >> >> >> On 2/15/2019 4:25 AM, Andrew F. Davis wrote: >>> On 2/13/19 9:46 PM, Lokesh Vutla wrote: On 14/02/19 12:07 AM, Andrew F. Davis wrote: > K3 HS devices require signed binaries for boot, use the SECDEV tools > to sign the boot artifacts during build. > > Signed-off-by: Andrew F. Davis > --- > MAINTAINERS | 1 + > arch/arm/mach-k3/config.mk| 25 ++ > arch/arm/mach-k3/config_secure.mk | 44 +++ > tools/k3_fit_atf.sh | 8 -- > 4 files changed, 76 insertions(+), 2 deletions(-) > create mode 100644 arch/arm/mach-k3/config_secure.mk > > diff --git a/MAINTAINERS b/MAINTAINERS > index 18cdca9447..ac6bd8cfca 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -717,6 +717,7 @@ F:arch/arm/mach-omap2/omap5/sec_entry_cpu1.S > F: arch/arm/mach-omap2/sec-common.c > F: arch/arm/mach-omap2/config_secure.mk > F: arch/arm/mach-k3/security.c > +F: arch/arm/mach-k3/config_secure.mk > F: configs/am335x_hs_evm_defconfig > F: configs/am335x_hs_evm_uart_defconfig > F: configs/am43xx_hs_evm_defconfig > diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk > index be00d79fb0..2d8f61f9db 100644 > --- a/arch/arm/mach-k3/config.mk > +++ b/arch/arm/mach-k3/config.mk > @@ -36,6 +36,14 @@ cmd_gencert = cat $(srctree)/tools/k3_x509template.txt > | sed $(SED_OPTS) > u-boo > # If external key is not provided, generate key using openssl. > ifeq ($(CONFIG_SYS_K3_KEY), "") > KEY=u-boot-spl-eckey.pem > +# On HS use real key or warn if not available > +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),) > +KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem > +else > +$(warning "WARNING: signing key not found. Random key will NOT work on > HS hardware!") > +endif > +endif > else > KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY)) > endif > @@ -65,6 +73,15 @@ ALL-y += tiboot3.bin > endif > > ifdef CONFIG_ARM64 > +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > +SPL_ITS := u-boot-spl-k3_HS.its > +$(SPL_ITS): FORCE > + IS_HS=1 \ > + $(srctree)/tools/k3_fit_atf.sh \ > + $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(CONFIG_SPL_OF_LIST))) > $@ > + > +ALL-y+= tispl.bin_HS > +else > SPL_ITS := u-boot-spl-k3.its > $(SPL_ITS): FORCE > $(srctree)/tools/k3_fit_atf.sh \ > @@ -72,7 +89,15 @@ $(SPL_ITS): FORCE > > ALL-y+= tispl.bin > endif > +endif > + > +else > > +ifeq ($(CONFIG_TI_SECURE_DEVICE),y) > +ALL-y+= u-boot.img_HS > else > ALL-y+= u-boot.img > endif > +endif > + > +include $(srctree)/arch/arm/mach-k3/config_secure.mk > diff --git a/arch/arm/mach-k3/config_secure.mk > b/arch/arm/mach-k3/config_secure.mk > new file mode 100644 > index 00..6d63c57665 > --- /dev/null > +++ b/arch/arm/mach-k3/config_secure.mk > @@ -0,0 +1,44 @@ > +# SPDX-License-Identifier: GPL-2.0 > +# > +# Copyright (C) 2018 Texas Instruments, Incorporated - http://www.ti.com/ > +#Andrew F. Davis > + > +quiet_cmd_k3secureimg = SECURE $@ > +ifneq ($(TI_SECURE_DEV_PKG),) > +ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh),) > +cmd_k3secureimg = $(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh \ > + $< $@ \ > + $(if $(KBUILD_VERBOSE:1=), >/dev/null) > +else > +cmd_k3secureimg = echo "WARNING:" \ > + "$(TI_SECURE_DEV_PKG)/scripts/secure-binary-image.sh not found." \ > + "$@ was NOT secured!"; cp $< $@ > +endif > +else > +cmd_k3secureimg = echo "WARNING: TI_SECURE_DEV_PKG environment" \ > + "variable must be defined for TI secure devices." \ > + "$@ was NOT secured!"; cp $< $@ > +endif > + > +%.dtb_HS: %.dtb FORCE > + $(call if_changed,k3secureimg) > + > +$(obj)/u-boot-spl-nodtb.bin_HS: $(obj)/u-boot-spl-nodtb.bin FORCE > + $(call if_changed,k3secureimg) > + > +tispl.bin_HS: $(obj)/u-boot-spl-nodtb.bin_HS $(patsubst > %,$(obj)/dts/%.dtb_HS,$(subst ",,$(CONFIG_SPL_OF_LIST))) $(SPL_ITS) FORCE > + $(call if_changed,mkfitimage) > + > +MKIMAGEFLAGS_u-boot.img_HS = -f auto -A $(ARCH) -T firmware -C none -O > u-boot \ > + -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_UBOOT_START) \ > + -n "U-Boot $(UBOOTRELEASE) for $(BOARD) board" -E \ > + $(patsubst %,-b arch/$(ARCH)/dts/%.dtb_HS,$(subst ",,$(CONFIG_OF_LIST))) I guess these HS postfixed dtbs will never get cleaned. I see the same issue with other TI secure
[U-Boot] [PATCH] L3 cache : arch : arm : lib : Flush L3 after relocation
Flush L3 cache after uboot relocated to DDR. Signed-off-by: Meenakshi Aggarwal Signed-off-by: Udit Kumar --- arch/arm/lib/relocate_64.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S index 171d094..7603f52 100644 --- a/arch/arm/lib/relocate_64.S +++ b/arch/arm/lib/relocate_64.S @@ -85,6 +85,7 @@ relocate_done: isb sy 4: ldp x0, x1, [sp, #16] bl __asm_flush_dcache_range + bl __asm_flush_l3_dcache 5: ldp x29, x30, [sp],#32 ret ENDPROC(relocate_code) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/2] dm: pinctrl: Skip gpio-controller node in pinconfig_post_bind()
Hi,
> From: Simon Glass
> Sent: vendredi 15 février 2019 18:12
>
> On Fri, 15 Feb 2019 at 15:31, Patrice Chotard wrote:
> >
> > From: Patrick Delaunay
> >
> > Some binding define child node gpio-controller without compatible property.
> > This patch avoid to bind the pinconfig uclass to these node.
>
> Some bindings define a child node gpio-controller without a compatible
> property.
> Avoid binding the pinconfig uclass to these node since ...(add explanation
> here)
Ok , we will add more explanation in v2.
For example, the binding for st,stm32-pinctrl
(./device-tree-bindings/pinctrl/st,stm32-pinctrl.txt)
defines the GPIO controller/bank node as sub-node of pincontrol (for example
st,stm32f429-pinctrl)
but without compatible (as it is not mandatory).
Without the added check, the gpio node with " gpio-controller" parameter is
bounded as pinconfig.
This patch remove the need to add a compatible in u-boot device tree.
As example ./arch/arm/dts/stm32f429-disco-u-boot.dtsi
{
compatible = "st,stm32-gpio";
u-boot,dm-pre-reloc;
};
{
compatible = "st,stm32-gpio";
u-boot,dm-pre-reloc;
};
{
compatible = "st,stm32-gpio";
u-boot,dm-pre-reloc;
};
PS: today "st,stm32-gpio" is still needing to bind the driver
drivers/gpio/stm32f7_gpio.c
To gpio-controller node...
But we are expecting to remove this modification of kernel device tree
by directly
bind sub-node to UCLASS_GPIO "gpio_stm32" in pincontrol driver.
static int stm32_pinctrl_bind(struct udevice *dev)
{
const void *blob = gd->fdt_blob;
int offset = dev_of_offset(dev);
const char *name;
int ret;
for (offset = fdt_first_subnode(blob, offset);
offset > 0;
offset = fdt_next_subnode(blob, offset)) {
fdt_get_property(blob, offset, "gpio-controller", );
if (ret < 0)
continue;
/* Get the name of each gpio node */
name = fdt_get_name(blob, offset, NULL);
if (!name)
return -EINVAL;
/* Bind each gpio node */
ret = device_bind_driver_to_node(dev, "stm32mp-gpio",
name, offset, NULL);
if (ret)
return ret;
debug("%s: bind %s\n", __func__, name);
}
return 0;
}
> >
> > Signed-off-by: Patrick Delaunay
> > Signed-off-by: Patrice Chotard
> > ---
> >
> > drivers/pinctrl/pinctrl-uclass.c | 3 +++
> > 1 file changed, 3 insertions(+)
>
> Reviewed-by: Simon Glass
>
>
> >
> > diff --git a/drivers/pinctrl/pinctrl-uclass.c
> > b/drivers/pinctrl/pinctrl-uclass.c
> > index abb622cfe79e..9df06a262cd5 100644
> > --- a/drivers/pinctrl/pinctrl-uclass.c
> > +++ b/drivers/pinctrl/pinctrl-uclass.c
> > @@ -149,6 +149,9 @@ static int pinconfig_post_bind(struct udevice *dev)
> > ofnode_get_property(node, "compatible", );
> > if (ret >= 0)
> > continue;
> > + /* If this node has "gpio-controller" property, skip */
> > + if (ofnode_read_bool(node, "gpio-controller"))
> > + continue;
> >
> > if (ret != -FDT_ERR_NOTFOUND)
> > return ret;
> > --
> > 1.9.1
> >
Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] test: py: Extend fpga test with fit image with external data
Images are created
mkimage -f fit.its -E download-fit-external.ub
and test expects these entries.
env__fpga_under_test = {
...
"mkimage_fit_external": download-fit-external.ub",
"mkimage_fit_external_size": x,
...
}
Test download file and loads it to fpga.
Signed-off-by: Michal Simek
---
test/py/tests/test_fpga.py | 13 +
1 file changed, 13 insertions(+)
diff --git a/test/py/tests/test_fpga.py b/test/py/tests/test_fpga.py
index 798f6eed3dc9..e3bb7b41c749 100644
--- a/test/py/tests/test_fpga.py
+++ b/test/py/tests/test_fpga.py
@@ -357,6 +357,19 @@ def test_fpga_loadmk_legacy_gz(u_boot_console):
@pytest.mark.buildconfigspec('cmd_fpga_loadmk')
@pytest.mark.buildconfigspec('fit')
@pytest.mark.buildconfigspec('cmd_echo')
+def test_fpga_loadmk_fit_external(u_boot_console):
+f, dev, addr, bit, bit_size = load_file_from_var(u_boot_console,
'mkimage_fit_external')
+
+u_boot_console.run_command('imi %x' % (addr))
+
+expected_text = 'FPGA loaded successfully'
+output = u_boot_console.run_command('fpga loadmk %x %x:fpga && echo %s' %
(dev, addr, expected_text))
+assert expected_text in output
+
+@pytest.mark.buildconfigspec('cmd_fpga')
+@pytest.mark.buildconfigspec('cmd_fpga_loadmk')
+@pytest.mark.buildconfigspec('fit')
+@pytest.mark.buildconfigspec('cmd_echo')
def test_fpga_loadmk_fit(u_boot_console):
f, dev, addr, bit, bit_size = load_file_from_var(u_boot_console,
'mkimage_fit')
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] hsdk: readme: Suggest getting pyelftools with pip
Signed-off-by: Alexey Brodkin Suggested-by: Yunir Salimzyanov --- board/synopsys/hsdk/README | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/board/synopsys/hsdk/README b/board/synopsys/hsdk/README index e29a6a1727..9155f17c6e 100644 --- a/board/synopsys/hsdk/README +++ b/board/synopsys/hsdk/README @@ -83,10 +83,11 @@ Useful notes on bulding and using of U-Boot on ARC HS Development Kit (AKA HSDK) HSDK board. Note that Python3 script is used for generation of a header, thus - to get that done it's required to have Python3 with elftools installed. - On CentOS/RHEL/Fedora this could be installed with: + to get that done it's required to have Python3 with "pyelftools" installed. + + "pyelftools" could be installed with help of "pip" even w/o root rights: ->8-- - sudo dnf install python3-pyelftools + python3 -m pip install --user pyelftools ->8-- EXECUTING U-BOOT -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: Replace char * with const char * for filename
On 15. 02. 19 8:57, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> Ensure the string for filename is always constant, otherwise it can be
> corrupted by the writing.
Have you reach any issue with it?
>
> Signed-off-by: Tien Fong Chee
> ---
> drivers/fpga/zynqpl.c |3 ++-
> include/fpga.h|2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/zynqpl.c b/drivers/fpga/zynqpl.c
> index 499310d..683cf14 100644
> --- a/drivers/fpga/zynqpl.c
> +++ b/drivers/fpga/zynqpl.c
> @@ -421,7 +421,8 @@ static int zynq_loadfs(xilinx_desc *desc, const void
> *buf, size_t bsize,
> loff_t blocksize, actread;
> loff_t pos = 0;
> int fstype;
> - char *interface, *dev_part, *filename;
> + char *interface, *dev_part;
> + const char *filename;
>
> blocksize = fsinfo->blocksize;
> interface = fsinfo->interface;
> diff --git a/include/fpga.h b/include/fpga.h
> index 195f0bd..51de5c5 100644
> --- a/include/fpga.h
> +++ b/include/fpga.h
> @@ -41,7 +41,7 @@ typedef struct {/* typedef fpga_desc */
> unsigned int blocksize;
> char *interface;
> char *dev_part;
> - char *filename;
> + const char *filename;
> int fstype;
> } fpga_fs_info;
>
>
Anyway looks good applied.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] MAINTAINERS: Update u-boot-marvell entry
On Fri, Feb 15, 2019 at 01:56:56PM +0100, Stefan Roese wrote: > This patch does the following changes to the u-boot-marvell maintainers > entry: > > - Add Armada-7k/8k to the list > - Remove Prafulla and Luka since they have been silent on the list for > a long time. Please speak up, if you would like to continue or better > start maintaining. > - Add multiple Marvell / MVEBU related driver directories and files > > Signed-off-by: Stefan Roese > Cc: Prafulla Wadaskar > Cc: Luka Perkov > Cc: Tom Rini Acked-by: Luka Perkov > --- > MAINTAINERS | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 29449ffed6..7fa3e059f6 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -166,16 +166,19 @@ S: Maintained > F: arch/arm/cpu/armv8/hisilicon > F: arch/arm/include/asm/arch-hi6220/ > > -ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX > -M: Prafulla Wadaskar > -M: Luka Perkov > +ARM MARVELL KIRKWOOD ARMADA-XP ARMADA-38X ARMADA-37XX ARMADA-7K/8K > M: Stefan Roese > S: Maintained > T: git git://git.denx.de/u-boot-marvell.git > F: arch/arm/mach-kirkwood/ > F: arch/arm/mach-mvebu/ > F: drivers/ata/ahci_mvebu.c > -F: drivers/phy/marvell/ > +F: drivers/ddr/marvell/ > +F: drivers/gpio/mvebu_gpio.c > +F: drivers/spi/kirkwood_spi.c > +F: drivers/pci/pci_mvebu.c > +F: drivers/pci/pcie_dw_mvebu.c > +F: drivers/watchdog/orion_wdt.c > > ARM MARVELL PXA > M: Marek Vasut > -- > 2.20.1 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fpga: Add support for getting external data address and length
On 12. 02. 19 13:41, tien.fong.c...@intel.com wrote:
> From: Tien Fong Chee
>
> This function supports getting both data address and length for
> existing FPGA subimage and FPGA external data.
>
> Signed-off-by: Tien Fong Chee
> ---
> cmd/fpga.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cmd/fpga.c b/cmd/fpga.c
> index 88a8e3f..b1f224b 100644
> --- a/cmd/fpga.c
> +++ b/cmd/fpga.c
> @@ -343,9 +343,9 @@ static int do_fpga_loadmk(cmd_tbl_t *cmdtp, int flag, int
> argc,
> return CMD_RET_FAILURE;
> }
>
> - /* get fpga subimage data address and length */
> - if (fit_image_get_data(fit_hdr, noffset, _data,
> -_size)) {
> + /* get fpga subimage/external data address and length */
> + if (fit_image_get_data_and_size(fit_hdr, noffset,
> +_data, _size)) {
> puts("Fpga subimage data not found\n");
> return CMD_RET_FAILURE;
> }
>
Reviewed-by: Michal Simek
also applied to my tree.
Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/1] mtd: added missing GigaDevice chips
in kernel tree are additional 2 chips from GigaDevice, which i need for Vocore2 (MT7688) Jiri Kastner (1): mtd: added missing GigaDevice chips drivers/mtd/spi/spi-nor-ids.c | 10 ++ 1 file changed, 10 insertions(+) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/1] mtd: added missing GigaDevice chips
Vocore2 (mt7688 based device) has g25q128 chip
from GigaDevice, which i've found in kernel tree.
added chips are gd25q128 and gd25q256.
Cc: Jagan Teki
Cc: Vignesh R
---
drivers/mtd/spi/spi-nor-ids.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3215e2431d..c1f84df64f 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -106,6 +106,16 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+ {
+ INFO("gd25q128", 0xc84018, 0, 64 * 1024, 256,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
+ {
+ INFO("gd25q256", 0xc84019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
#endif
#ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */
/* ISSI */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] added missing GigaDevice chips
---
drivers/mtd/spi/spi-nor-ids.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3215e2431d..e4d05433a2 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -106,6 +106,16 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+ {
+ INFO("gd25q128", 0xc84018, 0, 64 * 1024, 128,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
+ {
+ INFO("gd25q256", 0xc84019, 0, 64 * 1024, 128,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
#endif
#ifdef CONFIG_SPI_FLASH_ISSI /* ISSI */
/* ISSI */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/1] GigaDevice id update
Vocore2 (mt76x8 device) has g25q128 flash, which is already in kernel's spi-nor.c Jiri Kastner (1): added missing GigaDevice chips drivers/mtd/spi/spi-nor-ids.c | 10 ++ 1 file changed, 10 insertions(+) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mtd: ubi debug: Remove the pid print from ubi_assert
Hello Eran, Am 18.02.2019 um 08:44 schrieb Eran Matityahu: Hi Heiko. On Mon, Feb 18, 2019 at 7:06 AM Heiko Schocher wrote: Hello Eran, Am 13.02.2019 um 19:55 schrieb Eran Matityahu: Add a new definition for ubi_assert and keep the original one in an ifndef __UBOOT__. Signed-off-by: Eran Matityahu --- drivers/mtd/ubi/debug.h | 10 ++ 1 file changed, 10 insertions(+) Is there any reason for this change? If I see it correct, pid is for U-Boot always set to one in ./lib/linux_compat.c ... so I see no reason for introducing here an U-Boot specific version of ubi_assert() ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de Sure, it works with the pid print, however: 1. The pid print is useless in U-Boot. 2. I wanted to align it with ubifs_assert() and the rest of the macros in fs/ubifs/debug.h, which also have U-Boot specific versions without the pid print. 3. If you agree with the next patch I sent (using pr_debug), then it's probably best to have a U-Boot specific version for ubi_assert() anyway. Ah, I see. Ok, I have no objections. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
>
> 'SET_BLOCKLEN' may occasionally fail on first attempt.
Why ?
> This patch enable a small delay in dwmci_send_cmd() on
> busy, I/O or CRC error to allow the MMC controller recovers
> from the failure/error on subsequent retries.
Why 100 uS ?
Can we rather detect whether the controller recovered by polling some bit?
> Signed-off-by: Ang, Chee Hong
> ---
> drivers/mmc/dw_mmc.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> index 7544b84..8dcc518 100644
> --- a/drivers/mmc/dw_mmc.c
> +++ b/drivers/mmc/dw_mmc.c
> @@ -266,8 +266,11 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
> mmc_cmd *cmd,
> if (data)
> flags = dwmci_set_transfer_mode(host, data);
>
> - if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type & MMC_RSP_BUSY))
> - return -1;
> + if ((cmd->resp_type & MMC_RSP_136) &&
> + (cmd->resp_type & MMC_RSP_BUSY)) {
> + ret = -1;
> + goto delay_ret;
> + }
>
> if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
> flags |= DWMCI_CMD_ABORT_STOP;
> @@ -316,11 +319,13 @@ static int dwmci_send_cmd(struct mmc *mmc, struct
> mmc_cmd *cmd,
> return -ETIMEDOUT;
> } else if (mask & DWMCI_INTMSK_RE) {
> debug("%s: Response Error.\n", __func__);
> - return -EIO;
> + ret = -EIO;
> + goto delay_ret;
> } else if ((cmd->resp_type & MMC_RSP_CRC) &&
> (mask & DWMCI_INTMSK_RCRC)) {
> debug("%s: Response CRC Error.\n", __func__);
> - return -EIO;
> + ret = -EIO;
> + goto delay_ret;
> }
>
>
> @@ -347,6 +352,7 @@ static int dwmci_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> }
> }
>
> +delay_ret:
> udelay(100);
>
> return ret;
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Return valid error code from FPGA driver
On 2/18/19 5:07 AM, chee.hong@intel.com wrote: > From: "Ang, Chee Hong" > > This patch prevent the Stratix 10 FPGA driver incorrectly return the > transaction ID as the mailbox error code. It should always return the > actual mailbox error code from SDM firmware. > > Signed-off-by: Ang, Chee Hong [...] Applied, thanks -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] coreboot: add support fot CB_TAG_BOOT_MEDIA_PARAMS
Change-Id: I7a2e320f2296bc20e1ac2f10cc2297697c50e097
Signed-off-by: Christian Gmeiner
---
arch/x86/cpu/coreboot/tables.c | 13 +
arch/x86/include/asm/arch-coreboot/sysinfo.h | 6 +-
arch/x86/include/asm/coreboot_tables.h | 11 +++
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c
index bc18b710c9..fa26b66f24 100644
--- a/arch/x86/cpu/coreboot/tables.c
+++ b/arch/x86/cpu/coreboot/tables.c
@@ -109,6 +109,16 @@ static void cb_parse_string(unsigned char *ptr, char
**info)
*info = (char *)((struct cb_string *)ptr)->string;
}
+static void cb_parse_boot_meda_params(unsigned char *ptr, struct sysinfo_t
*info)
+{
+ struct cb_boot_media_params *params = (struct cb_boot_media_params
*)ptr;
+
+ info->fmap_offset = params->fmap_offset;
+ info->cbfs_offset = params->cbfs_offset;
+ info->cbfs_size = params->cbfs_size;
+ info->boot_media_size = params->boot_media_size;
+}
+
static int cb_parse_header(void *addr, int len, struct sysinfo_t *info)
{
struct cb_header *header;
@@ -211,6 +221,9 @@ static int cb_parse_header(void *addr, int len, struct
sysinfo_t *info)
case CB_TAG_VBNV:
cb_parse_vbnv(ptr, info);
break;
+ case CB_TAG_BOOT_MEDIA_PARAMS:
+ cb_parse_boot_meda_params(ptr, info);
+ break;
}
ptr += rec->size;
diff --git a/arch/x86/include/asm/arch-coreboot/sysinfo.h
b/arch/x86/include/asm/arch-coreboot/sysinfo.h
index dd8d1cba92..0969bf946b 100644
--- a/arch/x86/include/asm/arch-coreboot/sysinfo.h
+++ b/arch/x86/include/asm/arch-coreboot/sysinfo.h
@@ -51,8 +51,12 @@ struct sysinfo_t {
void*cbmem_cons;
struct cb_serial *serial;
-};
+ u64 fmap_offset;
+ u64 cbfs_offset;
+ u64 cbfs_size;
+ u64 boot_media_size;
+};
extern struct sysinfo_t lib_sysinfo;
int get_coreboot_info(struct sysinfo_t *info);
diff --git a/arch/x86/include/asm/coreboot_tables.h
b/arch/x86/include/asm/coreboot_tables.h
index c42175b94d..be752fc726 100644
--- a/arch/x86/include/asm/coreboot_tables.h
+++ b/arch/x86/include/asm/coreboot_tables.h
@@ -193,6 +193,17 @@ struct cb_vbnv {
uint32_t vbnv_size;
};
+#define CB_TAG_BOOT_MEDIA_PARAMS 0x0030
+struct cb_boot_media_params {
+ uint32_t tag;
+ uint32_t size;
+ /* offsets are relative to start of boot media */
+ uint64_t fmap_offset;
+ uint64_t cbfs_offset;
+ uint64_t cbfs_size;
+ uint64_t boot_media_size;
+};
+
#define CB_TAG_CMOS_OPTION_TABLE 0x00c8
struct cb_cmos_option_table {
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] riscv: add infrastructure for calling functions on other harts
On Mon, 2019-02-18 at 10:01 +, Auer, Lukas wrote:
> On Mon, 2019-02-18 at 10:28 +0530, Anup Patel wrote:
> > On Tue, Feb 12, 2019 at 3:44 AM Lukas Auer
> > wrote:
> > > Harts on RISC-V boot independently and U-Boot is responsible for
> > > managing them. Functions are called on other harts with
> > > smp_call_function(), which sends inter-processor interrupts
> > > (IPIs)
> > > to
> > > all other harts. Functions are specified with their address and
> > > two
> > > function arguments (argument 2 and 3). The first function
> > > argument
> > > is
> > > always the hart ID of the hart calling the function. On the other
> > > harts,
> > > the IPI interrupt handler handle_ipi() must be called on software
> > > interrupts to handle the request and call the specified function.
> > >
> > > Functions are stored in the ipi_data data structure. Every hart
> > > has
> > > its
> > > own data structure in global data. While this is not required at
> > > the
> > > moment (all harts are expected to boot Linux), this does allow
> > > future
> > > expansion, where other harts may be used for monitoring or other
> > > tasks.
> > >
> > > Signed-off-by: Lukas Auer
> > > ---
> > >
> > > arch/riscv/Kconfig | 19 +
> > > arch/riscv/include/asm/global_data.h | 5 ++
> > > arch/riscv/include/asm/smp.h | 53 +
> > > arch/riscv/lib/Makefile | 1 +
> > > arch/riscv/lib/smp.c | 110
> > > +++
> > > 5 files changed, 188 insertions(+)
> > > create mode 100644 arch/riscv/include/asm/smp.h
> > > create mode 100644 arch/riscv/lib/smp.c
> > >
> > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > index c45e4d73a8..c0842178dd 100644
> > > --- a/arch/riscv/Kconfig
> > > +++ b/arch/riscv/Kconfig
> > > @@ -116,4 +116,23 @@ config RISCV_RDTIME
> > > config SYS_MALLOC_F_LEN
> > > default 0x1000
> > >
> > > +config SMP
> > > + bool "Symmetric Multi-Processing"
> > > + help
> > > + This enables support for systems with more than one
> > > CPU.
> > > If
> > > + you say N here, U-Boot will run on single and
> > > multiprocessor
> > > + machines, but will use only one CPU of a multiprocessor
> > > + machine. If you say Y here, U-Boot will run on many,
> > > but
> > > not
> > > + all, single processor machines.
> > > +
> > > +config NR_CPUS
> > > + int "Maximum number of CPUs (2-32)"
> > > + range 2 32
> > > + depends on SMP
> > > + default "8"
> > > + help
> > > + On multiprocessor machines, U-Boot sets up a stack for
> > > each CPU.
> > > + Stack memory is pre-allocated. U-Boot must therefore
> > > know
> > > the
> > > + maximum number of CPUs that may be present.
> > > +
> > > endmenu
> > > diff --git a/arch/riscv/include/asm/global_data.h
> > > b/arch/riscv/include/asm/global_data.h
> > > index a3a342c6e1..23a5f35af5 100644
> > > --- a/arch/riscv/include/asm/global_data.h
> > > +++ b/arch/riscv/include/asm/global_data.h
> > > @@ -10,12 +10,17 @@
> > > #ifndef__ASM_GBL_DATA_H
> > > #define __ASM_GBL_DATA_H
> > >
> > > +#include
> > > +
> > > /* Architecture-specific global data */
> > > struct arch_global_data {
> > > long boot_hart; /* boot hart id */
> > > #ifdef CONFIG_SIFIVE_CLINT
> > > void __iomem *clint;/* clint base address */
> > > #endif
> > > +#ifdef CONFIG_SMP
> > > + struct ipi_data ipi[CONFIG_NR_CPUS];
> >
> > The data passed by "main HART" via global data to other HARTs
> > is not visible reliably and randomly few HARTs fail to enter Linux
> > kernel on my board. I am suspecting per-HART "ipi" data in global
> > data not being cache-line aligned as the cause of behavior but
> > there
> > could be other issue too.
> >
> > I have a hack which works reliable for me. As-per this hack, we add
> > "mdelay(10)" just before calling riscv_send_ipi() in
> > send_ipi_many().
> > This hack helped me conclude that there is some sync issue in per-
> > HART
> > "ipi" data.
> >
> > The above issue is not seen on QEMU so we are fine there.
> >
> > I would suggest to make per-HART "ipi" data cache-line aligned
> > (just like Linux kernel).
> >
>
> Interesting, this is definitely a memory coherency issue, probably
> inadequate fences. I am not sure if making the ipi data structure
> cache-line aligned will reliably fix it. I'll try to replicate the
> issue and get it fixed. Thanks for reporting it!
>
Not sure if it is connected, but I have noticed a regression with the
current OpenSBI. Testing U-Boot with the SMP patches applied on QEMU
with 4 harts, hart 4 will not receive software interrupts. I have
bisected the issue to the following commit.
918c1354b75c74b62f67c4e929551d643f035443 is the first bad commit
commit 918c1354b75c74b62f67c4e929551d643f035443
Author: Nick Kossifidis
Date: Sun Feb 17 09:00:20 2019 +0200
lib: Improve delivery of
Re: [U-Boot] [PATCH] dtbo: Fix dtbo generation rules
Hi,
On 11. 02. 19 14:51, Michal Simek wrote:
> Take the first prerequisite (dts overlay file) instead of standard
> input.
>
> Signed-off-by: Michal Simek
> ---
>
> Not sure how this was designed to take overlay as input.
> What I have done was simply add overlay to arch/arm/dts folder and add
> target with .dtbo suffix.
>
> ---
> scripts/Makefile.lib | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index a5b57fc6b98a..34b3fed6a0ba 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -317,7 +317,7 @@ quiet_cmd_dtco = DTCO$@
> # No generation of assembly file either
> # Modified for U-Boot
> cmd_dtco = mkdir -p $(dir ${dtc-tmp}) ; \
> - $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) - ; \
> + $(CPP) $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp) $< ; \
> $(DTC) -@ -O dtb -o $@ -b 0 \
> -i $(dir $<) $(DTC_FLAGS) \
> -d $(depfile).dtc.tmp $(dtc-tmp) ; \
>
Any issue with this?
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [ANN] Monthly developer call
On 2/18/19 5:00 AM, Tom Rini wrote: > On Mon, Feb 18, 2019 at 03:48:58AM +0100, Marek Vasut wrote: >> On 2/13/19 9:36 PM, Tom Rini wrote: >>> On Thu, Feb 14, 2019 at 02:01:02AM +0530, Jagan Teki wrote: On Mon, Feb 11, 2019 at 10:28 PM Tom Rini wrote: > > Hey all, > > So as I mentioned back in December[1], I was thinking of doing a > recurring community conference call. I've gone ahead and scheduled one > now with Zoom (https://zoom.us/) as they work well enough with Linux as > a host. For now, the time is 4PM UTC, which is 11AM US Eastern, 8AM US > Pacific. > > The meeting URL is: https://zoom.us/j/203089062 (and so the meeting > number is 203089062) > > For dial-in: +1 (646) 876-9923 and world-wide local dial-in numbers are > found on: https://zoom.us/u/acnOQeSN Is this call scheduled? I'm trying zoom but unable to join. >>> >>> I can't believe I forgot that part in the plain text of the message and >>> not just the ics part. The call is the 3rd Monday of every month at 4PM >>> UTC / 11AM US Eastern / 8AM US Pacific. >> >> That, sadly, excludes me from each and every one of those calls. >> >> Will there be any transcript for people who cannot join ? > > I don't plan to transcribe them, no. I plan to treat these like the > in-person meetings we've had before, so there won't be any final > decisions made on the call. But hopefully some topics to bring back to > the ML with more clarity. This doesn't help, I'd certainly like to know what was said in the meeting. >> I think we should postpone the call, advertise it more first and decide >> on a suitable time _before_ scheduling it again. > > I was hoping for more feedback, but we'll see who shows up tomorrow. > There's no good time for everyone, but as I've stated before if we get > interest in a more Asia-friendly time, we can do that. Maybe CCing some of the active contributors would help with that. And awareness, I talked to some and they were seldom aware of this call. >> btw the zoom dial-in numbers link doesn't work, but I think this one >> https://zoom.us/zoomconference should work. > > The meeting link won't work until closer to the call, yes. > -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/8] spi: sun4i: Access registers and bits via enum offsets
On 2/18/19 12:38 PM, Jagan Teki wrote:
Hi Stefan,
On Fri, Feb 15, 2019 at 12:12 PM Stefan Mavrodiev wrote:
[snip]
+static const unsigned long sun4i_spi_bits[] = {
Same here, make it uint32_t, since it describes register masks in 32 bit
registers.
+[SPI_GCR_TP]= BIT(18),
+[SPI_TCR_CPHA] = BIT(2),
+[SPI_TCR_CPOL] = BIT(3),
+[SPI_TCR_CS_ACTIVE_LOW] = BIT(4),
+[SPI_TCR_XCH] = BIT(10),
+[SPI_TCR_CS_SEL]= 12,
+[SPI_TCR_CS_MASK] = 0x3000,
+[SPI_TCR_CS_MANUAL] = BIT(16),
+[SPI_TCR_CS_LEVEL] = BIT(17),
+[SPI_FCR_TF_RST]= BIT(8),
+[SPI_FCR_RF_RST]= BIT(9),
+[SPI_FSR_RF_CNT_MASK] = GENMASK(6, 0),
+};
+
+static const struct sun4i_spi_variant sun4i_a10_spi_variant = {
+.regs = sun4i_spi_regs,
+.bits = sun4i_spi_bits,
+};
+
static const struct udevice_id sun4i_spi_ids[] = {
-{ .compatible = "allwinner,sun4i-a10-spi" },
+{
+ .compatible = "allwinner,sun4i-a10-spi",
+ .data = (ulong)_a10_spi_variant,
+},
{ }
};
I checked the rest as good as my brain allows me at 11pm, but it's still
quite a change with a lot of bits here and there :-(
Stefan, can you please test that this still works for you on the A20? If
I find some time I can try to hook up some SPI chip to my BananaPi, but
I guess it's easier for you to test.
Here are some test results:
=> sf probe 0:0
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total
16 MiB
=> sf test 0 10
SPI flash test:
0 erase: 11363 ticks, 90 KiB/s 0.720 Mbps
1 check: 825 ticks, 1241 KiB/s 9.928 Mbps
2 write: 2472 ticks, 414 KiB/s 3.312 Mbps
3 read: 815 ticks, 1256 KiB/s 10.048 Mbps
Test passed
0 erase: 11363 ticks, 90 KiB/s 0.720 Mbps
1 check: 825 ticks, 1241 KiB/s 9.928 Mbps
2 write: 2472 ticks, 414 KiB/s 3.312 Mbps
3 read: 815 ticks, 1256 KiB/s 10.048 Mbps
The original tests can be seen here [1].
Apparently the patch works and it can be seen some
speed improvement.
Thanks for testing this.
Can I add your Tested-by credit?
Sure.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
