[PATCH] cmd: add clone command
From: John Chau
This patch adds a feature for block device cloning similar to dd
command, this should be useful for boot-strapping a device where
usb gadget or networking is not available. For instance one can
clone a factory image into a blank emmc from an external sd card.
Signed-off-by: John Chau
---
cmd/Kconfig | 9 +
cmd/Makefile | 1 +
cmd/clone.c | 112 +++
3 files changed, 122 insertions(+)
create mode 100644 cmd/clone.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 6403bc45a5..44f96dedcd 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1067,6 +1067,15 @@ config CMD_MMC_SWRITE
Enable support for the "mmc swrite" command to write Android sparse
images to eMMC.
+config CMD_CLONE
+ bool "clone"
+ depends on BLK
+ select CLONE
+ help
+ Enable storage cloning over block devices, useful for
+ initial flashing by external block device without network
+ or usb gadget support.
+
config CMD_MTD
bool "mtd"
depends on MTD
diff --git a/cmd/Makefile b/cmd/Makefile
index f1dd513a4b..02663a1c73 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_CMD_MMC) += mmc.o
obj-$(CONFIG_MP) += mp.o
obj-$(CONFIG_CMD_MTD) += mtd.o
obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
+obj-$(CONFIG_CMD_CLONE) += clone.o
ifneq ($(CONFIG_CMD_NAND)$(CONFIG_CMD_SF),)
obj-y += legacy-mtd-utils.o
endif
diff --git a/cmd/clone.c b/cmd/clone.c
new file mode 100644
index 00..ee36c7698c
--- /dev/null
+++ b/cmd/clone.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 John Chau
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+//FIXME: we assume blk size of both devices can be divided by 1M, which should
be normal
+#define BUFSIZE (1 * 1024 * 1024)
+static int do_clone(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
+ int srcdev, destdev;
+ struct blk_desc *srcdesc, *destdesc;
+ int srcbz, destbz, ret;
+ char *unit, *buf;
+ unsigned long wrcnt, rdcnt, requested, srcblk, destblk;
+ unsigned long timer;
+
+ if (argc < 6) {
+ return CMD_RET_USAGE;
+ }
+ printf("\n");
+ srcdev = blk_get_device_by_str(argv[1], argv[2], &srcdesc);
+ destdev = blk_get_device_by_str(argv[3], argv[4], &destdesc);
+ if (srcdev < 0) {
+ printf("Unable to open source device\n");
+ return 1;
+ } else if (destdev < 0) {
+ printf("Unable to open destination device\n");
+ return 1;
+ }
+ requested = simple_strtoul(argv[5], &unit, 10);
+ srcbz = srcdesc->blksz;
+ destbz = destdesc->blksz;
+ if (requested == 0) {
+ unsigned long a = srcdesc->lba * srcdesc->blksz;
+ unsigned long b = destdesc->lba * destdesc->blksz;
+ if (a > b) requested = a;
+ else requested = b;
+ } else {
+ switch (unit[0]) {
+ case 'g':
+ case 'G':
+ requested *= 1024;
+ case 'm':
+ case 'M':
+ requested *= 1024;
+ case 'k':
+ case 'K':
+ requested *= 1024;
+ break;
+ }
+ }
+ wrcnt = 0;
+ rdcnt = 0;
+ buf = (char*)malloc(BUFSIZE);
+ srcblk = 0;
+ destblk = 0;
+ timer = get_timer(0);
+ while (wrcnt < requested) {
+ unsigned long toRead = BUFSIZE / srcbz;
+ unsigned long offset = 0;
+read:
+ ret = blk_dread(srcdesc, srcblk, toRead, buf + offset);
+ if (ret < 0) {
+ printf("Src read error @blk %ld\n", srcblk);
+ goto exit;
+ }
+ rdcnt += ret * srcbz;
+ srcblk += ret;
+ if (ret < toRead) {
+ toRead -= ret;
+ offset += ret * srcbz;
+ goto read;
+ }
+ unsigned long toWrite = BUFSIZE / destbz;
+ offset = 0;
+write:
+ ret = blk_dwrite(destdesc, destblk, toWrite, buf + offset);
+ if (ret < 0) {
+ printf("Dest write error @blk %ld\n", srcblk);
+ goto exit;
+ }
+ wrcnt += ret * destbz;
+ destblk += ret;
+ if (ret < toWrite) {
+ toWrite -= ret;
+ offset += ret * destbz;
+ goto write;
+ }
+ }
+
+exit:
+ timer = get_timer(timer);
+ timer = 1000 * timer / CONFIG_SYS_HZ;
+ printf("%ld read \n", rdcnt);
+ printf("%ld written\n", wrcnt);
+ printf("%ldms, %ldkB/s\n", timer, wrcnt /
Re: [PATCH v3 07/14] cmd: env: add env load command
On Thu, Jun 25, 2020 at 09:59:51AM +0200, Patrick Delaunay wrote: > Add the new command env load to load the environment from > the current location gd->env_load_prio. > > Signed-off-by: Patrick Delaunay Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 06/14] env: the ops driver load becomes mandatory in struct env_driver
On Thu, Jun 25, 2020 at 09:59:50AM +0200, Patrick Delaunay wrote: > The ops driver load becomes mandatory in struct env_drive, > change the comment for this ops and remove unnecessary test. > > Signed-off-by: Patrick Delaunay Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 05/14] env: nowhere: add .load ops
On Thu, Jun 25, 2020 at 09:59:49AM +0200, Patrick Delaunay wrote: > Add the ops .load for nowhere ENV backend to load the > default environment. > > This ops is needed for the command 'env load' > > > > Signed-off-by: Patrick Delaunay Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 03/14] env: sf: avoid space in backend name
On Thu, Jun 25, 2020 at 09:59:47AM +0200, Patrick Delaunay wrote: > Remove space in ENV backend name for SPI Flash (SF) > to avoid issue with env select command. > > Signed-off-by: Patrick Delaunay Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 04/14] env: correctly handle env_load_prio
On Thu, Jun 25, 2020 at 09:59:48AM +0200, Patrick Delaunay wrote: > Only update gd->env_load_prio in generic function env_load() > and no more in the weak function env_get_location() which is > called in many place (for example in env_driver_lookup, even > for ENVOP_SAVE operation). > > This patch is a preliminary step to use env_driver_lookup()/ > env_get_location() in new function env_select() without > updating gd->env_load_prio. > > Signed-off-by: Patrick Delaunay Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 08/14] cmd: env: add env select command
On Thu, Jun 25, 2020 at 09:59:52AM +0200, Patrick Delaunay wrote:
> Add the new command 'env select' to force the persistent storage
> of environment, saved in gd->env_load_prio.
>
> Signed-off-by: Patrick Delaunay
[snip]
> + /* search priority by driver */
> + for (prio = 0; (drv = env_driver_lookup(ENVOP_INIT, prio)); prio++) {
> + if (entry->location == env_get_location(ENVOP_LOAD, prio)) {
> + /* when priority change, reset the ENV flags */
> + if (gd->env_load_prio != prio) {
> + gd->env_load_prio = prio;
> + gd->env_valid = ENV_INVALID;
> + gd->flags &= ~GD_FLG_ENV_DEFAULT;
> + }
> + printf("OK\n");
> + return 0;
> + }
> + }
So, after we do this, is some follow up env command required to
initialize the environment to now exist somewhere else? Or will we have
initialized all configured locations during boot, and don't have to?
But what will happen if we select say "nand" but it's not present so
didn't init. Will things fail gracefully (not panic) ? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: microSD Breakout Port
On Thu, Jun 25, 2020 at 08:13:08PM +, Faruk Kılavuz wrote:
> Hello
>
> This is my first mail. I tried running uart-0 with microsd breakout method. I
> have added the following codes to open the F port.
>
> diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
> b/arch/arm/include/asm/arch-sunxi/gpio.h
> index 40a3f845d0..9140b35450 100644
> --- a/arch/arm/include/asm/arch-sunxi/gpio.h
> +++ b/arch/arm/include/asm/arch-sunxi/gpio.h
> @@ -181,6 +181,7 @@ enum sunxi_gpio_number {
> #define SUNXI_GPF_SDC0 2
> #define SUNXI_GPF_UART0 4
> #define SUN8I_GPF_UART03
> +#define SUN50I_GPF_UART0 3
>
> #define SUN4I_GPG_SDC1 4
> #define SUN5I_GPG_SDC1 2
> diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
> index b74eaf2a0e..019c9b9296 100644
> --- a/arch/arm/mach-sunxi/board.c
> +++ b/arch/arm/mach-sunxi/board.c
> @@ -76,6 +76,9 @@ static int gpio_init(void)
> #if defined(CONFIG_MACH_SUN8I) && !defined(CONFIG_MACH_SUN8I_R40)
> sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN8I_GPF_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN8I_GPF_UART0);
> +#elif defined(CONFIG_MACH_SUN50I)
> + sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUN50I_GPF_UART0);
> + sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUN50I_GPF_UART0);
> #else
> sunxi_gpio_set_cfgpin(SUNXI_GPF(2), SUNXI_GPF_UART0);
> sunxi_gpio_set_cfgpin(SUNXI_GPF(4), SUNXI_GPF_UART0);
>
>
> Should I send this code as a u-boot patch? Thanks
Thanks for your patch. I've cc'd the sunxi maintainer for their
thoughts.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] rk3399: Add BOOTENV_SF command
On Thu, Jun 25, 2020 at 08:32:10PM +0530, Jagan Teki wrote:
> On Mon, Jun 8, 2020 at 7:47 PM Jagan Teki wrote:
> >
> > Add missing BOOTENV_SF command in rk3399 config.
> >
> > Fix it.
> >
> > Fixes: f263b860acf8 ("rk3399: Enable SF distro bootcmd")
> > Signed-off-by: Jagan Teki
> > Reported-by: Suniel Mahesh
> > Tested-by: Suniel Mahesh
> > ---
>
> Can someone push this fix patch to master?
Kever, do you want me to pick this up? Do you have some objection?
FWIW, include/configs/rk3399_common.h should get listed under some
MAINTAINER entry directly. Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] gitlab: show skipped Python tests
On Wed, Jun 24, 2020 at 02:04:37PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 24 Jun 2020 at 09:53, Tom Rini wrote:
> >
> > On Wed, Jun 24, 2020 at 09:17:51AM -0600, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Wed, 24 Jun 2020 at 07:56, Heinrich Schuchardt
> > > wrote:
> > > >
> > > > On 24.06.20 15:49, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Mon, 22 Jun 2020 at 12:46, Tom Rini wrote:
> > > > >>
> > > > >> On Mon, Jun 22, 2020 at 12:23:35PM -0600, Simon Glass wrote:
> > > > >>> Hi Heinrich,
> > > > >>>
> > > > >>> On Mon, 22 Jun 2020 at 10:40, Heinrich Schuchardt
> > > > >>> wrote:
> > > >
> > > > On 22.06.20 18:17, Simon Glass wrote:
> > > > > Hi Heinrich,
> > > > >
> > > > > On Mon, 22 Jun 2020 at 10:07, Heinrich Schuchardt
> > > > > wrote:
> > > > >>
> > > > >> Call pytest3 with argument -ra to display reason why Python
> > > > >> tests are
> > > > >> skipped.
> > > > >>
> > > > >> Signed-off-by: Heinrich Schuchardt
> > > > >> ---
> > > > >> .gitlab-ci.yml | 2 +-
> > > > >> 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >>
> > > > >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > >> index f2e491c117..f53098ea5f 100644
> > > > >> --- a/.gitlab-ci.yml
> > > > >> +++ b/.gitlab-ci.yml
> > > > >> @@ -46,7 +46,7 @@ stages:
> > > > >> # "${var:+"-k $var"}" expands to "" if $var is empty, "-k
> > > > >> $var" if not
> > > > >> - export
> > > > >> PATH=/opt/qemu/bin:/tmp/uboot-test-hooks/bin:${PATH};
> > > > >>export PYTHONPATH=/tmp/uboot-test-hooks/py/travis-ci;
> > > > >> - ./test/py/test.py --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > > > >> + ./test/py/test.py -ra --bd ${TEST_PY_BD} ${TEST_PY_ID}
> > > > >> ${TEST_PY_TEST_SPEC:+"-k ${TEST_PY_TEST_SPEC}"}
> > > > >> --build-dir "$UBOOT_TRAVIS_BUILD_DIR"
> > > > >
> > > > > Do you have a link showing the current output with this patch?
> > > >
> > > > Hello Simon,
> > > >
> > > > here is an example output:
> > > >
> > > > https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112385
> > > > >>>
> > > > >>> That's what I was afraid of. The skip output is more than the normal
> > > > >>> output, and if we don't intend to fix it, I'd rather not have
> > > > >>> unactionable warnings in the output.
> > > > >>>
> > > > >>> Having said that, we need to enable SPI flash, FPGA and MMC
> > > > >>> environment tests by the look of it.
> > > > >>
> > > > >> On a different note, I think we should look at:
> > > > >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112376
> > > > >> and:
> > > > >> https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/jobs/112380
> > > > >>
> > > > >> as it shows that the reason we probably skip the
> > > > >> test_fs/test_mkdir.py
> > > > >> tests is that since board is literal, we don't match sandbox on
> > > > >> sandbox_flattree. That answers one outstanding question about why we
> > > > >> skip some tests and not others at least.
> > > > >
> > > > > Hmm yes.
> > > > >
> > > > > It is definitely good to have this output so we can figure out what
> > > > > should not be skipped.
> > > > >
> > > > > But outputting things which we know should be skipped just means we
> > > > > won't notice those that are not supposed to be skipped. How do we
> > > > > handle that?
> > > > >
> > > > > Regards,
> > > > > Simon
> > > > >
> > > > If you have a lines like:
> > > >
> > > > .config feature "cmd_fpga_loadbp" not enabled
> > > > board "qemu_arm64" not supported
> > > >
> > > > you know the test is skipped due to configuration.
> > >
> > > OK then can we avoid printing this useless information by default?
> >
> > It's not useless information. It's what I pointed to in another part of
> > the thread as to why we're skipping tests we didn't expect to skip.
>
> I thought these ones were intended to be skipped? I'm perhaps just
> confused about what is going on here.
We have a number of "sandbox" targets which should be running the FS
tests, but do not. Figuring out why has been low on my TODO list, but
is very clear with this extra information.
Still haven't however figured out why we do see this:
https://travis-ci.org/github/u-boot/u-boot/jobs/702114991 (which is, all
FS tests run).
> > > > Other messages clearly tell you that something is not correctly set up:
> > > >
> > > > No env__efi_loader_grub_file binary specified in environment
> > > > got empty parameter set ['env__mmc_dev_config']
> > >
> > > OK then this is what we should display.
> >
> > This one is actually one I dug in to a bit, and I don't like how pytest
> > handles. You can't add a custom parameter checker, AFAICT, you can only
> > have empty params be skip or xfail.
> >
> > I think we could condense the output a little bit as @pytest.mark things
> > get condensed, but pytest.skip in a test do not (as it coun
Re: [PATCH v3 1/1] phy: add support for stingray PAXB PHY controller
On Thu, Jun 25, 2020 at 10:57:09PM +0530, Rayagonda Kokatanur wrote: > Hi Tom, > > > On Sun, Apr 12, 2020 at 8:46 PM Rayagonda Kokatanur > wrote: > > > > On Thu, Apr 9, 2020 at 7:11 PM Tom Rini wrote: > > > > > > On Thu, Apr 02, 2020 at 04:08:12PM +0530, Rayagonda Kokatanur wrote: > > > > > > > From: Srinath Mannam > > > > > > > > Add support for stingray PAXB PHY controller driver. > > > > This driver supports maximum 8 PAXB phys using pipemux data. > > > > > > > > Signed-off-by: Srinath Mannam > > > > Signed-off-by: Rayagonda Kokatanur > > > > Reviewed-by: Stefan Roese > > > > --- > > > > Changes from v2: > > > > -Address review comments from Stefan Roese, > > > > Rearrange the include files. > > > > Remove dm/device.h as its included part of dm.h. > > > > > > > > Changes from v1: > > > > -Address review comments from Stefan Roese, > > > > Use GENMASK() instead of hard code value. > > > > Remove unwanted struct declaration. > > > > Get pr_err() into single line. > > > > > > > > drivers/phy/Kconfig | 7 ++ > > > > drivers/phy/Makefile | 1 + > > > > drivers/phy/phy-bcm-sr-pcie.c | 177 ++ > > > > > > The patch itself is fine but I think shows another problem. Can you > > > please add a patch that lists something relevant in the top-level > > > MAINTAINERS file and list this and all of the other drivers, etc, that > > > wouldn't just be listed in the board MAINATINERS file? Thanks! > > I have a plan to update the top level MAINTAINER file with all new > driver and board files in a separate patch. > Hope this is fine, please let me know. OK, thanks. I'll be picking up more patches again soon for -next. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/4] arm: kirkwood: convert LaCie boards to DM_SPI_FLASH
On Thu, Jun 25, 2020 at 12:28:56AM +0200, Simon Guinot wrote: > This patch converts the following Kirkwood-based LaCie boards to DM, > DM_SPI and DM_SPI_FLASH: > > - d2 Network v2 > - Internet Space v2 > - 2Big Network v2 > - Network Space v2 > - Network Space Lite v2 > - Network Space Max v2 > - Network Space Mini v2 > > Signed-off-by: Simon Guinot > --- > arch/arm/dts/kirkwood-netxbig.dtsi| 4 > arch/arm/dts/kirkwood-ns2-common.dtsi | 4 These files come from the kernel and need to be kept in sync as-is with the kernel. Both of these aliases should be easy to push upstream but if not that's also why we have the -u-boot.dtsi auto-include mechanism that keys off of CONFIG_SYS_SOC/CPU/VENDOR. The entire rest of the series looks good, thanks for updating these platforms! -- Tom signature.asc Description: PGP signature
Re: [RFC 0/4] drivers: footprint reduction proposal
Hi Tom, On 22/6/20 12:25, Walter Lozano wrote: Hi Tom, On 22/6/20 11:20, Tom Rini wrote: On Mon, Jun 22, 2020 at 11:12:40AM -0300, Walter Lozano wrote: Hi Tom, On 19/6/20 18:48, Tom Rini wrote: On Fri, Jun 19, 2020 at 06:11:36PM -0300, Walter Lozano wrote: Based on several reports and discussions it is clear that U-Boot's footprint is always a concern, and any kind of reduction is an improvement. This series is a proposal to help reducing the footprint by parsing information provided in DT and drivers in different ways and adding additional intelligence to dtoc. The current version implements the basic functionality in dtoc but this is no fully integrated, however it will allow us to discuss this approach. Firstly, based on the compatible strings found in drivers, include only DT nodes which are supported by any driver present in U-Boot. Secondly, generate struct udevice_id entries only for nodes present in DT, which will allow to avoid including additional data. These are the first steps for further improvements as proposed in the specific patches in this series. This work is based on the work of Simon Glass present in [1] which adds support to dtoc for parsing compatible strings. [1] https://gitlab.denx.de/u-boot/custodians/u-boot-dm/-/tree/dtoc-working I applied this series on top of the above tree, but there's no rule for so is something missing? Thanks! Thanks for taking the time to check this RFC. As you pointed, the Makefile needs to be tweaked in order to be able to run a build, that is what I meant by "not fully integrated", also some additional stuff are missing. However, I thought that sending this RFC explaining the idea will be nice in order to confirm if the approaches proposed make sense for the community and at least the one to handle compatible strings is different from the linker list suggestion. I think I like the idea, but I need to give a build a spin and poke things harder. What do I need to do to manually have this build+link? Thanks! Well, I don't think this version will give you something to fully test, as there are several pieces missing, but the fact you think you like the idea is good starting point. Just to do some testing you can try Shrink a dtb with ./tools/dtoc/dtoc shrink -d u-boot.dtb this will shrink u-boot.dtb and create u-boot-shrink.dtb by only include nodes with compatible strings present in drivers Generate include/generated/compatible.h ./tools/dtoc/dtoc compatible -d u-boot.dtb -o include/generated/compatible.h this will generate compatible.h but the code does not yet support struct udevice_id with data in struct udevice_id and does not filter anything. I will continue working on these features but any early feedback is welcome. To be able to test this a bit more I reworked and back ported the patches and add a bit more of work on top, such as - Add Makefile rules (need to be improved) - Add support for checking enabled drivers for dtb shrink (need to be improved as parsing probably does not take into account no common situations) - Add support for defining constants based on compatible strings enabled This work can be found in https://gitlab.collabora.com/wlozano/u-boot/-/tree/wip The drawback is that this implementation doesn't take advantage of the new abstractions found in the Simon's work, but I think it could still be useful to test the idea, and discuss if it makes sense. I have done some testing in my iMX6 Hummingboard but I have found some issues not related to this work in MMC, which I need to debug. Regards, Walter
Re: [PATCH v3 13/15] include/configs: ns3: add env variables for Linux boot
On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote: > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur > wrote: > > > > From: Bharat Gooty > > > > Add env variables and commands for booting Linux. > > > > Signed-off-by: Bharat Gooty > > Signed-off-by: Rayagonda Kokatanur > > --- > > include/configs/bcm_ns3.h | 366 ++ > > 1 file changed, 366 insertions(+) > > Reviewed-by: Simon Glass > > Are you using binman to create your images? No. > > It seems like you should put your documentation somewhere in doc/ > instead of in this header file. Okay, I will create one readme file under doc ( /doc/README.bcmns3-qpsi) and move the documentation there. Best regards, Rayagonda
[PATCH 1/1] ARM: mx6: make CAAM usable on the i.MX6 boards
Even if the HAB fuse is not set we want to be able to use the Cryptographic
Accelerator and Assurance Module (CAAM) for generating random numbers. So
SYS_FSL_HAS_SEC should be selected even if IMX_HAB is not set.
arch_misc_init() has to be called to initialize the CAAM.
Signed-off-by: Heinrich Schuchardt
---
arch/arm/Kconfig| 2 +-
arch/arm/mach-imx/mx6/soc.c | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 54d65f8488..9a957f63c7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -884,7 +884,7 @@ config ARCH_MX7
config ARCH_MX6
bool "Freescale MX6"
select CPU_V7A
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
imply MXC_GPIO
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index 19ca382649..e129286065 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -691,6 +692,15 @@ void imx_setup_hdmi(void)
}
#endif
+#ifdef CONFIG_ARCH_MISC_INIT
+int arch_misc_init(void)
+{
+#ifdef CONFIG_FSL_CAAM
+ sec_init();
+#endif
+ return 0;
+}
+#endif
/*
* gpr_init() function is common for boards using MX6S, MX6DL, MX6D,
--
2.20.1
Re: [PATCH v3 6/6] crypto/fsl: add RNG support
On 6/25/20 2:19 PM, Michael Walle wrote:
> Register the random number generator with the rng subsystem in u-boot.
> This way it can be used by EFI as well as for the 'rng' command.
>
> Signed-off-by: Michael Walle
> ---
> drivers/crypto/fsl/Kconfig | 14 ++
> drivers/crypto/fsl/Makefile | 1 +
> drivers/crypto/fsl/jobdesc.c | 10 +
> drivers/crypto/fsl/jobdesc.h | 3 ++
> drivers/crypto/fsl/jr.c | 9
> drivers/crypto/fsl/rng.c | 86
> 6 files changed, 123 insertions(+)
> create mode 100644 drivers/crypto/fsl/rng.c
>
> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
> index 181a1e5e99..5ed6140da3 100644
> --- a/drivers/crypto/fsl/Kconfig
> +++ b/drivers/crypto/fsl/Kconfig
> @@ -45,3 +45,17 @@ config SYS_FSL_SEC_COMPAT
>
> config SYS_FSL_SEC_LE
> bool "Little-endian access to Freescale Secure Boot"
> +
> +if FSL_CAAM
> +
> +config FSL_CAAM_RNG
> + bool "Enable Random Number Generator support"
> + depends on DM_RNG
> + default y
> + help
> + Enable support for the hardware based random number generator
> + module of the CAAM. The random data is fetched from the DRGB
> + using the prediction resistance flag which means the DRGB is
> + reseeded from the TRNG every time random data is generated.
> +
> +endif
> diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
> index cfb36f3bb9..a5e8d38e38 100644
> --- a/drivers/crypto/fsl/Makefile
> +++ b/drivers/crypto/fsl/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
> obj-$(CONFIG_CMD_BLOB) += fsl_blob.o
> obj-$(CONFIG_CMD_DEKBLOB) += fsl_blob.o
> obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
> +obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
> diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
> index d9554c550b..decde64078 100644
> --- a/drivers/crypto/fsl/jobdesc.c
> +++ b/drivers/crypto/fsl/jobdesc.c
> @@ -296,6 +296,16 @@ void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc,
> int handle)
>(handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INITFINAL);
> }
>
> +void inline_cnstr_jobdesc_rng(u32 *desc, void *data_out, u32 size)
> +{
> + dma_addr_t dma_data_out = virt_to_phys(data_out);
> +
> + init_job_desc(desc, 0);
> + append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
> + OP_ALG_PR_ON);
> + append_fifo_store(desc, dma_data_out, size, FIFOST_TYPE_RNGSTORE);
> +}
> +
> /* Change key size to bytes form bits in calling function*/
> void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
> struct pk_in_params *pkin, uint8_t *out,
> diff --git a/drivers/crypto/fsl/jobdesc.h b/drivers/crypto/fsl/jobdesc.h
> index 5185ddd535..c4501abd26 100644
> --- a/drivers/crypto/fsl/jobdesc.h
> +++ b/drivers/crypto/fsl/jobdesc.h
> @@ -43,7 +43,10 @@ void inline_cnstr_jobdesc_rng_instantiation(u32 *desc, int
> handle, int do_sk);
>
> void inline_cnstr_jobdesc_rng_deinstantiation(u32 *desc, int handle);
>
> +void inline_cnstr_jobdesc_rng(u32 *desc, void *data_out, u32 size);
> +
> void inline_cnstr_jobdesc_pkha_rsaexp(uint32_t *desc,
> struct pk_in_params *pkin, uint8_t *out,
> uint32_t out_siz);
> +
> #endif
> diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
> index 00a3244b18..9ada1d625b 100644
> --- a/drivers/crypto/fsl/jr.c
> +++ b/drivers/crypto/fsl/jr.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #endif
> +#include
>
> #define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
> #define CIRC_SPACE(head, tail, size) CIRC_CNT((tail), (head) + 1, (size))
> @@ -721,6 +722,14 @@ int sec_init_idx(uint8_t sec_idx)
> printf("SEC%u: RNG instantiation failed\n", sec_idx);
> return -1;
> }
> +
> + if (IS_ENABLED(CONFIG_DM_RNG)) {
> + ret = device_bind_driver(NULL, "caam-rng", "caam-rng",
> + NULL);
> + if (ret)
> + printf("Couldn't bind rng driver (%d)\n", ret);
> + }
> +
> printf("SEC%u: RNG instantiated\n", sec_idx);
> }
> #endif
> diff --git a/drivers/crypto/fsl/rng.c b/drivers/crypto/fsl/rng.c
> new file mode 100644
> index 00..136b2cdcd7
> --- /dev/null
> +++ b/drivers/crypto/fsl/rng.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (c) 2020 Michael Walle
> + *
> + * Driver for Freescale Cryptographic Accelerator and Assurance
> + * Module (CAAM) hardware random number generator.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "desc_constr.h"
> +#include "jobdesc.h"
> +#include "jr.h"
> +
> +#define CAAM_RNG_MAX_FIFO_STORE_SIZE 16
> +#define CAAM_RNG_DESC_LEN (3 * CAAM_CMD_
Re: [PATCH v3 05/15] board: ns3: add api to save boot parameters passed from BL31
On Fri, Jun 26, 2020 at 6:41 AM Simon Glass wrote:
>
> On Wed, 10 Jun 2020 at 04:41, Rayagonda Kokatanur
> wrote:
> >
> > From: Abhishek Shah
> >
> > Add API to save boot parameters passed from BL31
> >
> > Use assembly implementation of save_boot_params instead of c function.
> > Because generally ATF does not set up SP_EL2 on exiting.
> > Thus, usage of a C function immediately after exiting with no stack
> > setup done by ATF explicitly, may cause SP_EL2 to be not sane,
> > which in turn causes a crash if this boot was not lucky to get
> > an SP_EL2 in valid range. Replace C implementation with assembly one
> > which does not use stack this early, and let u-boot to set up its stack
> > later.
>
> Can this be fixed in ATF?
We are passing boot parameters for uboot using arm cpu x0, x1, x2 and
x3 registers.
>
> >
> > Signed-off-by: Abhishek Shah
> > Signed-off-by: Rajesh Ravi
> > Signed-off-by: Vladimir Olovyannikov
> > Signed-off-by: Rayagonda Kokatanur
> > ---
> > arch/arm/cpu/armv8/bcmns3/lowlevel.S | 9 +++
> > arch/arm/include/asm/arch-bcmns3/bl33_info.h | 26
> > board/broadcom/bcmns3/ns3.c | 10
> > 3 files changed, 45 insertions(+)
> > create mode 100644 arch/arm/include/asm/arch-bcmns3/bl33_info.h
> >
>
> Reviewed-by: Simon Glass
>
> > diff --git a/board/broadcom/bcmns3/ns3.c b/board/broadcom/bcmns3/ns3.c
> > index e38156723c..5e644bd466 100644
> > --- a/board/broadcom/bcmns3/ns3.c
> > +++ b/board/broadcom/bcmns3/ns3.c
> > @@ -8,6 +8,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static struct mm_region ns3_mem_map[] = {
> > {
> > @@ -33,8 +34,17 @@ struct mm_region *mem_map = ns3_mem_map;
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +/*
> > + * Force the bl33_info to the data-section, as .bss will not be valid
> > + * when save_boot_params is invoked.
> > + */
> > +struct bl33_info *bl33_info __section(".data");
> > +
> > int board_init(void)
> > {
> > + if (bl33_info->version != BL33_INFO_VERSION)
> > + printf("*** warning: ATF BL31 and u-boot not in sync!
> > ***\n");
>
> Shouldn't this be a fatal error?
It's not a fatal error.
Its warning message for the user indicates that BL31 and BL33 are out of sync.
By knowing this warning message, users can upgrade the binarie from
uboot prompt.
Best regards,
Rayagonda
>
>
> > +
> > return 0;
> > }
> >
> > --
> > 2.17.1
> >
Re: [PATCH v3 0/6] crypto/fsl: add RNG support
On 6/25/20 11:01 PM, Michael Walle wrote:
> Am 2020-06-25 18:03, schrieb Heinrich Schuchardt:
>> On 25.06.20 16:36, Heinrich Schuchardt wrote:
>>> On 25.06.20 14:18, Michael Walle wrote:
First, improve the compatibility on newer Era CAAMs. These
introduced new
version registers. Secondly, add RNG support for the CAAM. This way
we get
random number generator support for EFI for free and KASLR will work
with
ARM64 kernels booted with bootefi.
>>>
>>> It seems that a Kconfig dependency at least on CONFIG_SYS_FSL_HAS_SEC
>>> which itself depends on CONFIG_IMX_HAB is missing:
>>>
>>> wandboard_defconfig + FSL_CAAM + DM_RNG gives me a bunch of errors
>>>
>>> drivers/crypto/fsl/jr.c: In function ‘start_jr0’:
>>> drivers/crypto/fsl/jr.c:47:2: error: unknown type name ‘ccsr_sec_t’; did
>>> you mean ‘pci_dev_t’?
>>> ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
>>> ^~
>>> pci_dev_t
>>> In file included from ./arch/arm/include/asm/byteorder.h:29,
>>> from include/linux/libfdt_env.h:15,
>>> from include/linux/libfdt.h:6,
>>> from include/fdtdec.h:17,
>>> from include/asm-generic/global_data.h:23,
>>> from ./arch/arm/include/asm/global_data.h:87,
>>> from include/common.h:26,
>>> from drivers/crypto/fsl/jr.c:8:
>>> drivers/crypto/fsl/jr.c:48:29: error: request for member ‘ctpr_ms’ in
>>> something not a structure or union
>>> u32 ctpr_ms = sec_in32(&sec->ctpr_ms);
>>> ^~
>>>
>>> But if I enable IMX_HAB booting fails with: "hab fuse not enabled".
>>>
>>> Why should I need to enable the HAB fuse to use the random number
>>> generator on the i.MX6?
>>>
>>
>> With this change I can build the RNG driver for the i.MX6 Wandboard:
>>
>> diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
>> index 5ed6140da3..84783ea987 100644
>> --- a/drivers/crypto/fsl/Kconfig
>> +++ b/drivers/crypto/fsl/Kconfig
>> @@ -37,7 +37,6 @@ config SYS_FSL_SEC_BE
>>
>> config SYS_FSL_SEC_COMPAT
>> int "Freescale Secure Boot compatibility"
>> - depends on SYS_FSL_HAS_SEC
>> default 2 if SYS_FSL_SEC_COMPAT_2
>> default 4 if SYS_FSL_SEC_COMPAT_4
>> default 5 if SYS_FSL_SEC_COMPAT_5
>>
>> Even if you do not plan to support the i.MX6, I would recommend this
>> change to separate HAB and RNG.
>
> I don't think this is the correct place. Rather the architecture should
> set SYS_FSL_HAS_SEC if it actually has the SEC. I mean it already sets
> the COMPAT level but not the actual config which indicates it has one.
> At the moment it depends on IMX_HAB; I don't know the reasoning behind
> this. But I don't see how this would be part of this series.
ARCH_MX7 (arch/arm/Kconfig) has:
select SYS_FSL_HAS_SEC if IMX_HAB
So according to your suggestion this should be changed to
select SYS_FSL_HAS_SEC ?
And the same added to ARCH_MX6?
Best regards
Heinrich
>
>> With the following additional change the RNG driver is loaded on the
>> Wandboard:
>>
>> diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
>> index 19ca382649..e129286065 100644
>> --- a/arch/arm/mach-imx/mx6/soc.c
>> +++ b/arch/arm/mach-imx/mx6/soc.c
>> @@ -22,6 +22,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>>
>> @@ -691,6 +692,15 @@ void imx_setup_hdmi(void)
>> }
>> #endif
>>
>> +#ifdef CONFIG_ARCH_MISC_INIT
>> +int arch_misc_init(void)
>> +{
>> +#ifdef CONFIG_FSL_CAAM
>> + sec_init();
>> +#endif
>> + return 0;
>> +}
>> +#endif
>>
>> /*
>> * gpr_init() function is common for boards using MX6S, MX6DL, MX6D,
>>
>>
>> But the RNG driver seems to require some changes to work on the i.MX6:
>>
>> => rng
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x8e596f68
>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>> 0x8e596f78
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x8e596f68
>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>> 0x8e596f78
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x8e596f68
>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>> 0x8e596f78
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> CACHE: Misaligned operation at range [8e596f68, 8e596f78]
>> ERROR: v7_outer_cache_inval_range - start address is not aligned -
>> 0x8e596f68
>> ERROR: v7_outer_cache_inval_range - stop address is not aligned -
>> 0x8e596f78
>> : 00 00 00 00 00 00 00 00
Re: [PATCH v3 15/15] MAINTAINERS: update maintainers for broadcom ns3 platform
Hi Peter, On Fri, Jun 26, 2020 at 7:57 PM Peter Tyser wrote: > > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 1fd975c72f..0c72deaa44 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -11,7 +11,7 @@ Descriptions of section entries: > > Type is one of: git, hg, quilt, stgit, topgit > > S: Status, one of the following: > > Supported: Someone is actually paid to look after this. > > -Maintained: Someone actually looks after it. > > +Mne actually looks after it. > > Orphan: No current maintainer [but maybe you could take the > > role as you write your new code]. > > F: Files and directories with wildcard patterns. > > This looks to be an accidental change that should be fixed? Thank you so much, I will fix it. Regards, Rayagonda > > Regards, > Peter
Re: [PATCH v3 15/15] MAINTAINERS: update maintainers for broadcom ns3 platform
> diff --git a/MAINTAINERS b/MAINTAINERS > index 1fd975c72f..0c72deaa44 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -11,7 +11,7 @@ Descriptions of section entries: > Type is one of: git, hg, quilt, stgit, topgit > S: Status, one of the following: > Supported: Someone is actually paid to look after this. > -Maintained: Someone actually looks after it. > +Mne actually looks after it. > Orphan: No current maintainer [but maybe you could take the > role as you write your new code]. > F: Files and directories with wildcard patterns. This looks to be an accidental change that should be fixed? Regards, Peter
Re: [PATCH U-BOOT v3 00/30] PLEASE TEST fs: btrfs: Re-implement btrfs support using code from btrfs-progs
On Thu, Jun 25, 2020 at 07:43:20PM -0600, Simon Glass wrote: > Hi Marek, > > On Wed, 24 Jun 2020 at 10:03, Marek Behún wrote: > > > > Hello, > > > > this is a cleaned up version of Qu's patches that reimplements U-Boot's > > btrfs driver with code from btrfs-progs. > > > > I have tested this series, found and corrected one bug (failure when > > accesing files via symlinks), and it looks it is working now, but I > > would like more people to do some testing. > > > > There are a lot of checkpatch warnings and errors left, I shall fix > > this in the future. > > > > Marek > > Please can you add a test for this one? See fs-test.sh Not more fs-test.sh tests, test/py/tests/test_fs/ tests please, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 3/4] riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
On Fri, Jun 26, 2020 at 8:41 PM Sagar Shrikant Kadam wrote: > > The conditional check to read "mmu-type" from the device tree > is not rightly handled due to which the cpu feature doesn't include > CPU_FEAT_MMU even if it's corresponding entry is present in the device > tree. > > The initialization of cpu features is now taken care in cpu-uclass > driver, so no need to zero out cpu_freq in riscv_cpu driver and can be > removed. > > Signed-off-by: Sagar Shrikant Kadam > Reviewed-by: Pragnesh Patel > --- > drivers/cpu/riscv_cpu.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
Hi Sagar,
On Fri, Jun 26, 2020 at 8:40 PM Sagar Shrikant Kadam
wrote:
>
> The cmd "cpu detail" fetches uninitialized cpu feature information
> and thus displays wrong / inconsitent details as below.
> For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it.
>
> => cpu detail
> 1: cpu@1 rv64imafdc
> ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> Microcode version 0x0
> Device ID 0x0
> 2: cpu@2 rv64imafdc
> ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> Microcode version 0x0
> Device ID 0x0
> 3: cpu@3 rv64imafdc
> ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> Microcode version 0x0
> Device ID 0x0
> 4: cpu@4 rv64imafdc
> ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
> Microcode version 0x0
> Device ID 0x0
>
> The L1 cache or MMU entry seen above is also displayed inconsistently.
> So initialize cpu information to zero into cpu-uclass itself so that
> similar issues can be avoided for other CPU drivers.
>
> We now see correct features as:
> => cpu detail
> 1: cpu@1 rv64imafdc
> ID = 1, freq = 999.100 MHz
> 2: cpu@2 rv64imafdc
> ID = 2, freq = 999.100 MHz
> 3: cpu@3 rv64imafdc
> ID = 3, freq = 999.100 MHz
> 4: cpu@4 rv64imafdc
> ID = 4, freq = 999.100 MHz
>
> Signed-off-by: Sagar Shrikant Kadam
> Reviewed-by: Pragnesh Patel
> ---
> drivers/cpu/cpu-uclass.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
> index 7418c26..9f4a8fd 100644
> --- a/drivers/cpu/cpu-uclass.c
> +++ b/drivers/cpu/cpu-uclass.c
> @@ -83,6 +83,9 @@ int cpu_get_info(struct udevice *dev, struct cpu_info *info)
> {
> struct cpu_ops *ops = cpu_get_ops(dev);
>
> + /* Init cpu_info to 0 */
> + memset(info, 0, sizeof(struct cpu_info));
> +
nits: this should be put after the if() test logic below
> if (!ops->get_info)
> return -ENOSYS;
>
> --
Other than that,
Reviewed-by: Bin Meng
Regards,
Bin
Re: [PATCH v4 02/14] dtoc: add missing code comments
Hi Simon, On 25/6/20 22:42, Simon Glass wrote: On Wed, 24 Jun 2020 at 22:10, Walter Lozano wrote: Add missing information about internal class members in order to make the code easier to follow. Signed-off-by: Walter Lozano --- tools/dtoc/dtb_platdata.py | 3 +++ 1 file changed, 3 insertions(+) Reviewed-by: Simon Glass BTW if there was a review tag from last version, please add it to your commit. Thanks for pointing that, I'll take you advice for those commit that doesn't change at all. Also thank you for all the time you spent reviewing this series and sharing suggestions. Regards, Walter
Re: [PATCH v4 12/14] arm: dts: include gpio nodes for card detect
Hi Adam,
On 26/6/20 09:26, Adam Ford wrote:
On Thu, Jun 25, 2020 at 11:37 PM Adam Ford wrote:
On Wed, Jun 24, 2020 at 11:11 PM Walter Lozano
wrote:
Several MMC drivers use GPIO for card detection with cd-gpios property in
the MMC node pointing to a GPIO node. However, as U-Boot tries to save
space by keeping only required nodes using u-boot* properties, several
devices tree result in having only in the MMC node but not the GPIO node
associated to cd-gpios.
This patch, fixes several ocurrence of this issue.
Signed-off-by: Walter Lozano
---
arch/arm/dts/da850-evm-u-boot.dtsi| 4
arch/arm/dts/da850-lcdk-u-boot.dtsi | 4
arch/arm/dts/rk3288-u-boot.dtsi | 4
arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 2 +-
arch/arm/dts/rk3288-veyron-u-boot.dtsi| 11 +++
5 files changed, 24 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/rk3288-veyron-u-boot.dtsi
diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi
b/arch/arm/dts/da850-evm-u-boot.dtsi
index d9afc5edf4..d588628641 100644
--- a/arch/arm/dts/da850-evm-u-boot.dtsi
+++ b/arch/arm/dts/da850-evm-u-boot.dtsi
@@ -39,3 +39,7 @@
&spi1 {
u-boot,dm-spl;
};
+
+&gpio {
+ u-boot,dm-spl;
+};
I don't know that this is needed for the da850-evm since it doesn't
boot from sd/mmc. It can boot from SPI, NAND or NOR Flash depending
on the config option selected, but none of them need the gpio during
SPL. The gpio is loaded during normal U-Boot. I will try to run some
tests to make sure it still boots in the next few days. I know space
is getting tight in SPL.
I applied your patches and built.
FYI, "git am" didn't let them apply nicely, but there could be some
missing dependent patches I was missing. I was able to patch with
"patch"
The board booted as expected.
Thanks for your feedback and testing.
I examined the generated dtb for SPL since this board doesn't use
OF_PLATDATA. It looks like we could remove both the GPIO and the MMC
modes from SPL, but I'm not going to worry about it unless we can't
boot any more. If/when that happens, I'll spend more time trying to
free up space in SPL.
For now,, for the series...
Tested-by: Adam Ford #da850-evm
I found this possible issue while testing different configurations, but
it is more related to omapl138_lcdk_defconfig (da850-lcdk) which seems
to use OF_PLATDATA. In the case of da850-evm, if there are issue with
space in SPL, maybe we can consider removing both MMC and GPIO node and
also enable OF_PLATDATA, hopefully if omapl138_lcdk_defconfig works as
expected the effort would be little.
Regards,
Walter
diff --git a/arch/arm/dts/da850-lcdk-u-boot.dtsi
b/arch/arm/dts/da850-lcdk-u-boot.dtsi
index b372d06ca9..d50775c173 100644
--- a/arch/arm/dts/da850-lcdk-u-boot.dtsi
+++ b/arch/arm/dts/da850-lcdk-u-boot.dtsi
@@ -28,3 +28,7 @@
&serial2 {
u-boot,dm-spl;
};
+
+&gpio {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3288-u-boot.dtsi b/arch/arm/dts/rk3288-u-boot.dtsi
index 6d31735362..51b6e018bd 100644
--- a/arch/arm/dts/rk3288-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-u-boot.dtsi
@@ -43,3 +43,7 @@
&noc {
u-boot,dm-pre-reloc;
};
+
+&gpio7 {
+ u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
index eccc069368..251fbdee71 100644
--- a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
+++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
@@ -3,7 +3,7 @@
* Copyright 2015 Google, Inc
*/
-#include "rk3288-u-boot.dtsi"
+#include "rk3288-veyron-u-boot.dtsi"
&dmc {
rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
diff --git a/arch/arm/dts/rk3288-veyron-u-boot.dtsi
b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
new file mode 100644
index 00..899fe6e7a0
--- /dev/null
+++ b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2015 Google, Inc
+ */
+
+#include "rk3288-u-boot.dtsi"
+
+&gpio7 {
+ u-boot,dm-pre-reloc;
+};
+
--
2.20.1
Re: [PATCH v3 7/7] configs: ns3: enable sp805 watchdog driver
On 25.06.20 10:15, Rayagonda Kokatanur wrote: Enable sp805 watchdog driver for ns3. Signed-off-by: Rayagonda Kokatanur Reviewed-by: Simon Glass Reviewed-by: Stefan Roese Thanks, Stefan
[PATCH v6 2/4] uclass: cpu: fix to display proper CPU features
The cmd "cpu detail" fetches uninitialized cpu feature information
and thus displays wrong / inconsitent details as below.
For eg: FU540-C000 doesn't have any microcode, yet the cmd display's it.
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
Microcode version 0x0
Device ID 0x0
2: cpu@2 rv64imafdc
ID = 2, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
Microcode version 0x0
Device ID 0x0
3: cpu@3 rv64imafdc
ID = 3, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
Microcode version 0x0
Device ID 0x0
4: cpu@4 rv64imafdc
ID = 4, freq = 999.100 MHz: L1 cache, MMU, Microcode, Device ID
Microcode version 0x0
Device ID 0x0
The L1 cache or MMU entry seen above is also displayed inconsistently.
So initialize cpu information to zero into cpu-uclass itself so that
similar issues can be avoided for other CPU drivers.
We now see correct features as:
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz
2: cpu@2 rv64imafdc
ID = 2, freq = 999.100 MHz
3: cpu@3 rv64imafdc
ID = 3, freq = 999.100 MHz
4: cpu@4 rv64imafdc
ID = 4, freq = 999.100 MHz
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
---
drivers/cpu/cpu-uclass.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpu/cpu-uclass.c b/drivers/cpu/cpu-uclass.c
index 7418c26..9f4a8fd 100644
--- a/drivers/cpu/cpu-uclass.c
+++ b/drivers/cpu/cpu-uclass.c
@@ -83,6 +83,9 @@ int cpu_get_info(struct udevice *dev, struct cpu_info *info)
{
struct cpu_ops *ops = cpu_get_ops(dev);
+ /* Init cpu_info to 0 */
+ memset(info, 0, sizeof(struct cpu_info));
+
if (!ops->get_info)
return -ENOSYS;
--
2.7.4
[PATCH v6 4/4] riscv: cpu: check and append L1 cache to cpu features
All cpu cores within FU540-C000 having split I/D caches. Set the L1 cache feature bit using the i-cache-size or d-cache-size as one of the property from device tree indicating that L1 cache is present on the cpu core. => cpu detail 1: cpu@1 rv64imafdc ID = 1, freq = 999.100 MHz: L1 cache, MMU 2: cpu@2 rv64imafdc ID = 2, freq = 999.100 MHz: L1 cache, MMU 3: cpu@3 rv64imafdc ID = 3, freq = 999.100 MHz: L1 cache, MMU 4: cpu@4 rv64imafdc ID = 4, freq = 999.100 MHz: L1 cache, MMU Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Pragnesh Patel Reviewed-by: Bin Meng --- drivers/cpu/riscv_cpu.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c index 112690f..100fe55 100644 --- a/drivers/cpu/riscv_cpu.c +++ b/drivers/cpu/riscv_cpu.c @@ -35,6 +35,8 @@ static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info) int ret; struct clk clk; const char *mmu; + u32 i_cache_size; + u32 d_cache_size; /* First try getting the frequency from the assigned clock */ ret = clk_get_by_index(dev, 0, &clk); @@ -52,6 +54,16 @@ static int riscv_cpu_get_info(struct udevice *dev, struct cpu_info *info) if (mmu) info->features |= BIT(CPU_FEAT_MMU); + /* check if I cache is present */ + ret = dev_read_u32(dev, "i-cache-size", &i_cache_size); + if (ret) + /* if not found check if d-cache is present */ + ret = dev_read_u32(dev, "d-cache-size", &d_cache_size); + + /* if either I or D cache is present set L1 cache feature */ + if (!ret) + info->features |= BIT(CPU_FEAT_L1_CACHE); + return 0; } -- 2.7.4
[PATCH v6 3/4] riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
The conditional check to read "mmu-type" from the device tree
is not rightly handled due to which the cpu feature doesn't include
CPU_FEAT_MMU even if it's corresponding entry is present in the device
tree.
The initialization of cpu features is now taken care in cpu-uclass
driver, so no need to zero out cpu_freq in riscv_cpu driver and can be
removed.
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
---
drivers/cpu/riscv_cpu.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/cpu/riscv_cpu.c b/drivers/cpu/riscv_cpu.c
index 76b0489..112690f 100644
--- a/drivers/cpu/riscv_cpu.c
+++ b/drivers/cpu/riscv_cpu.c
@@ -36,9 +36,6 @@ static int riscv_cpu_get_info(struct udevice *dev, struct
cpu_info *info)
struct clk clk;
const char *mmu;
- /* Zero out the frequency, in case sizeof(ulong) != sizeof(u32) */
- info->cpu_freq = 0;
-
/* First try getting the frequency from the assigned clock */
ret = clk_get_by_index(dev, 0, &clk);
if (!ret) {
@@ -52,7 +49,7 @@ static int riscv_cpu_get_info(struct udevice *dev, struct
cpu_info *info)
dev_read_u32(dev, "clock-frequency", (u32 *)&info->cpu_freq);
mmu = dev_read_string(dev, "mmu-type");
- if (!mmu)
+ if (mmu)
info->features |= BIT(CPU_FEAT_MMU);
return 0;
--
2.7.4
[PATCH v6 0/4] update clock handler and proper cpu features
U-Boot cmd "cpu detail" shows inconsistent CPU features.
The current "cpu detail" sometimes shows "Microcode" as a feature, which
is not the case with FU540-C000 on HiFive Unleashed board.
Patch 1: add cpu node aliases.
Patch 2: Init CPU information to avoid inconsistent cpu information.
Patch 3: Correctly parse and update mmu-type.
Patch 4: Set L1 Cache feature if either i-cache or d-cache is present
I have picked few dependent patches from Sean's series from here [1]
and [2].
These have applied on mainline U-Boot commit eae62ae8de18 ("Merge tag
'efi-2020-07-rc6' of https://gitlab.denx.de/u-boot/custodians/u-boot-efi";)
Patch history:
=
V6:
-Rebase series with master
-Split patch 2 from v5 as suggested i.e init cpu feature in cpu-class.c
as one patch and handle mmu-type check into another.
-Updated Reviewed-by tags
V5:
-Addressed review comments on v4.
1. Removed patch 1 which was for debug message.
2. Updated commit logs with proper information on number of cpu's
3. Additionally used d-cache to set the L1 feature bit.
V4:
1. Rebased the series to mainline commit.
2. Updated dependency list as few patches are now merged.
3. Added U-Boot log of the flow i.e fsbl + fw_payload.bin (Opensbi+U-Boot)
V3:
1. Included the cosmetic change as suggested
s/L1 feature/L1 cache feature/
2. Added Reviewed-By tags
V2:
1. Incorporate review comments from Bin and Sean Anderson.
and dropped 2nd patch as similar work was already done in [1] and [2]
2 Add cpu node aliases to display cpu node's in sequence.
3. Add fix to show mmu as available cpu feature.
4. Check and append L1 cache feature.
V1: Base version
Thanks to Vincent Chen for testing the V1
version of this series.
[1] https://patchwork.ozlabs.org/patch/1316066
[2] https://patchwork.ozlabs.org/patch/1316067
All these together is available here:
https://github.com/sagsifive/u-boot/commits/dev/sagark/clk-v6
U-Boot log:
===
U-Boot SPL 2020.07-rc5-00063-g515541f (Jun 26 2020 - 04:44:08 -0700)
Trying to boot from MMC1
U-Boot 2020.07-rc5-00063-g515541f (Jun 26 2020 - 04:44:08 -0700)
CPU: rv64imafdc
Model: SiFive HiFive Unleashed A00
DRAM: 8 GiB
MMC: spi@1005:mmc@0: 0
In:serial@1001
Out: serial@1001
Err: serial@1001
Net: eth0: ethernet@1009
Hit any key to stop autoboot: 0
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
4: cpu@4 rv64imafdc
=> cpu detail
1: cpu@1 rv64imafdc
ID = 1, freq = 999.100 MHz: L1 cache, MMU
2: cpu@2 rv64imafdc
ID = 2, freq = 999.100 MHz: L1 cache, MMU
3: cpu@3 rv64imafdc
ID = 3, freq = 999.100 MHz: L1 cache, MMU
4: cpu@4 rv64imafdc
ID = 4, freq = 999.100 MHz: L1 cache, MMU
Sagar Shrikant Kadam (4):
riscv: dts: hifive-unleashed-a00: add cpu aliases
uclass: cpu: fix to display proper CPU features
riscv: cpu: correctly handle the setting of CPU_FEAT_MMU bit
riscv: cpu: check and append L1 cache to cpu features
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
drivers/cpu/cpu-uclass.c| 3 +++
drivers/cpu/riscv_cpu.c | 17 +
3 files changed, 20 insertions(+), 4 deletions(-)
--
2.7.4
[PATCH v6 1/4] riscv: dts: hifive-unleashed-a00: add cpu aliases
Add cpu aliases to U-Boot specific dtsi for hifive-unleashed.
Without aliases we see that the CPU device sequence numbers are set
randomly and the cpu list/detail command will show it as follows:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
0: cpu@4 rv64imafdc
Seems like CPU probing with dm-model also relies on aliases as observed
in case spi. The fu540-c000-u-boot.dtsi has cpu nodes and so adding
corresponding aliases we can ensure that cpu devices are assigned
proper sequence as follows:
=> cpu list
1: cpu@1 rv64imafdc
2: cpu@2 rv64imafdc
3: cpu@3 rv64imafdc
4: cpu@4 rv64imafdc
Signed-off-by: Sagar Shrikant Kadam
Reviewed-by: Pragnesh Patel
Reviewed-by: Bin Meng
---
arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
index 3038064..e037150 100644
--- a/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
+++ b/arch/riscv/dts/hifive-unleashed-a00-u-boot.dtsi
@@ -8,6 +8,10 @@
/ {
aliases {
+ cpu1 = &cpu1;
+ cpu2 = &cpu2;
+ cpu3 = &cpu3;
+ cpu4 = &cpu4;
spi0 = &qspi0;
spi2 = &qspi2;
};
--
2.7.4
Re: [PATCH v4 12/14] arm: dts: include gpio nodes for card detect
On Thu, Jun 25, 2020 at 11:37 PM Adam Ford wrote:
>
> On Wed, Jun 24, 2020 at 11:11 PM Walter Lozano
> wrote:
> >
> > Several MMC drivers use GPIO for card detection with cd-gpios property in
> > the MMC node pointing to a GPIO node. However, as U-Boot tries to save
> > space by keeping only required nodes using u-boot* properties, several
> > devices tree result in having only in the MMC node but not the GPIO node
> > associated to cd-gpios.
> >
> > This patch, fixes several ocurrence of this issue.
> >
> > Signed-off-by: Walter Lozano
> > ---
> >
> > arch/arm/dts/da850-evm-u-boot.dtsi| 4
> > arch/arm/dts/da850-lcdk-u-boot.dtsi | 4
> > arch/arm/dts/rk3288-u-boot.dtsi | 4
> > arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi | 2 +-
> > arch/arm/dts/rk3288-veyron-u-boot.dtsi| 11 +++
> > 5 files changed, 24 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/rk3288-veyron-u-boot.dtsi
> >
> > diff --git a/arch/arm/dts/da850-evm-u-boot.dtsi
> > b/arch/arm/dts/da850-evm-u-boot.dtsi
> > index d9afc5edf4..d588628641 100644
> > --- a/arch/arm/dts/da850-evm-u-boot.dtsi
> > +++ b/arch/arm/dts/da850-evm-u-boot.dtsi
> > @@ -39,3 +39,7 @@
> > &spi1 {
> > u-boot,dm-spl;
> > };
> > +
> > +&gpio {
> > + u-boot,dm-spl;
> > +};
>
> I don't know that this is needed for the da850-evm since it doesn't
> boot from sd/mmc. It can boot from SPI, NAND or NOR Flash depending
> on the config option selected, but none of them need the gpio during
> SPL. The gpio is loaded during normal U-Boot. I will try to run some
> tests to make sure it still boots in the next few days. I know space
> is getting tight in SPL.
I applied your patches and built.
FYI, "git am" didn't let them apply nicely, but there could be some
missing dependent patches I was missing. I was able to patch with
"patch"
The board booted as expected.
I examined the generated dtb for SPL since this board doesn't use
OF_PLATDATA. It looks like we could remove both the GPIO and the MMC
modes from SPL, but I'm not going to worry about it unless we can't
boot any more. If/when that happens, I'll spend more time trying to
free up space in SPL.
For now,, for the series...
Tested-by: Adam Ford #da850-evm
adam
>
> > diff --git a/arch/arm/dts/da850-lcdk-u-boot.dtsi
> > b/arch/arm/dts/da850-lcdk-u-boot.dtsi
> > index b372d06ca9..d50775c173 100644
> > --- a/arch/arm/dts/da850-lcdk-u-boot.dtsi
> > +++ b/arch/arm/dts/da850-lcdk-u-boot.dtsi
> > @@ -28,3 +28,7 @@
> > &serial2 {
> > u-boot,dm-spl;
> > };
> > +
> > +&gpio {
> > + u-boot,dm-spl;
> > +};
> > diff --git a/arch/arm/dts/rk3288-u-boot.dtsi
> > b/arch/arm/dts/rk3288-u-boot.dtsi
> > index 6d31735362..51b6e018bd 100644
> > --- a/arch/arm/dts/rk3288-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3288-u-boot.dtsi
> > @@ -43,3 +43,7 @@
> > &noc {
> > u-boot,dm-pre-reloc;
> > };
> > +
> > +&gpio7 {
> > + u-boot,dm-pre-reloc;
> > +};
> > diff --git a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> > b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> > index eccc069368..251fbdee71 100644
> > --- a/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> > +++ b/arch/arm/dts/rk3288-veyron-speedy-u-boot.dtsi
> > @@ -3,7 +3,7 @@
> > * Copyright 2015 Google, Inc
> > */
> >
> > -#include "rk3288-u-boot.dtsi"
> > +#include "rk3288-veyron-u-boot.dtsi"
> >
> > &dmc {
> > rockchip,pctl-timing = <0x215 0xc8 0x0 0x35 0x26 0x2 0x70 0x2000d
> > diff --git a/arch/arm/dts/rk3288-veyron-u-boot.dtsi
> > b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
> > new file mode 100644
> > index 00..899fe6e7a0
> > --- /dev/null
> > +++ b/arch/arm/dts/rk3288-veyron-u-boot.dtsi
> > @@ -0,0 +1,11 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Copyright 2015 Google, Inc
> > + */
> > +
> > +#include "rk3288-u-boot.dtsi"
> > +
> > +&gpio7 {
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > --
> > 2.20.1
> >
RE: [PATCH v5 3/3] riscv: cpu: check and append L1 cache to cpu features
Hi Bin, > -Original Message- > From: Bin Meng > Sent: Friday, June 26, 2020 5:51 PM > To: Sagar Kadam ; U-Boot Mailing List b...@lists.denx.de> > Cc: Rick Chen ; Jagan Teki > ; Pragnesh Patel > ; Anup Patel ; Simon > Glass ; Ye Li ; Peng Fan > ; Sean Anderson > Subject: Re: [PATCH v5 3/3] riscv: cpu: check and append L1 cache to cpu > features > > [External Email] Do not click links or attachments unless you recognize the > sender and know the content is safe > > Hi Sagar, > > On Thu, Jun 25, 2020 at 7:11 PM Bin Meng wrote: > > > > On Thu, Jun 25, 2020 at 4:12 PM Sagar Shrikant Kadam > > wrote: > > > > > > All cpu cores within FU540-C000 having split I/D caches. > > > Set the L1 cache feature bit using the i-cache-size or d-cache-size > > > as one of the property from device tree indicating that L1 cache is > > > present on the cpu core. > > > > > > => cpu detail > > > 1: cpu@1 rv64imafdc > > > ID = 1, freq = 999.100 MHz: L1 cache, MMU > > > 2: cpu@2 rv64imafdc > > > ID = 2, freq = 999.100 MHz: L1 cache, MMU > > > 3: cpu@3 rv64imafdc > > > ID = 3, freq = 999.100 MHz: L1 cache, MMU > > > 4: cpu@4 rv64imafdc > > > ID = 4, freq = 999.100 MHz: L1 cache, MMU > > > > > > Signed-off-by: Sagar Shrikant Kadam > > > Reviewed-by: Pragnesh Patel > > > --- > > > drivers/cpu/riscv_cpu.c | 12 > > > 1 file changed, 12 insertions(+) > > > > > > > Reviewed-by: Bin Meng > > Just noticed that you sent to the wrong U-Boot ML address. Please resend > this series to the ML. Thanks! > Yeah Bin, thanks for pointing it out. I received Undelivered notification about it. It was a mistake on my part. I am sending the v6 now Thanks & BR, Sagar > Regards, > Bin
Re: [PATCH v5 3/3] riscv: cpu: check and append L1 cache to cpu features
Hi Sagar, On Thu, Jun 25, 2020 at 7:11 PM Bin Meng wrote: > > On Thu, Jun 25, 2020 at 4:12 PM Sagar Shrikant Kadam > wrote: > > > > All cpu cores within FU540-C000 having split I/D caches. > > Set the L1 cache feature bit using the i-cache-size or d-cache-size > > as one of the property from device tree indicating that L1 cache is > > present on the cpu core. > > > > => cpu detail > > 1: cpu@1 rv64imafdc > > ID = 1, freq = 999.100 MHz: L1 cache, MMU > > 2: cpu@2 rv64imafdc > > ID = 2, freq = 999.100 MHz: L1 cache, MMU > > 3: cpu@3 rv64imafdc > > ID = 3, freq = 999.100 MHz: L1 cache, MMU > > 4: cpu@4 rv64imafdc > > ID = 4, freq = 999.100 MHz: L1 cache, MMU > > > > Signed-off-by: Sagar Shrikant Kadam > > Reviewed-by: Pragnesh Patel > > --- > > drivers/cpu/riscv_cpu.c | 12 > > 1 file changed, 12 insertions(+) > > > > Reviewed-by: Bin Meng Just noticed that you sent to the wrong U-Boot ML address. Please resend this series to the ML. Thanks! Regards, Bin
[PATCH] cmd: add a panic command
From: Heiko Stuebner
Even in boot scripts it may be needed to "panic" when all options
are exhausted and the device specification specifies hanging
instead of resetting the board.
So add a new panic command that just wraps around the core panic
call in uboot and can take an optional message.
Signed-off-by: Heiko Stuebner
---
cmd/Makefile | 1 +
cmd/panic.c | 22 ++
2 files changed, 23 insertions(+)
create mode 100644 cmd/panic.c
diff --git a/cmd/Makefile b/cmd/Makefile
index ac843b4b16..027fa9083a 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -8,6 +8,7 @@ ifndef CONFIG_SPL_BUILD
obj-y += boot.o
obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-y += help.o
+obj-y += panic.o
obj-y += version.o
# command
diff --git a/cmd/panic.c b/cmd/panic.c
new file mode 100644
index 00..696b4c73a3
--- /dev/null
+++ b/cmd/panic.c
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020 Theobroma Systems Design und Consulting GmbH
+ */
+
+#include
+#include
+
+static int do_panic(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ char *text = (argc < 2) ? "" : argv[1];
+
+ panic(text);
+ return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+ panic, 2, 1, do_panic,
+ "Panic with optional message",
+ "[message]"
+);
--
2.26.2
Re: [PATCH v3 12/15] board: ns3: limit U-boot relocation within 16MB memory
On Fri, Jun 26, 2020 at 6:42 AM Simon Glass wrote: > > On Wed, 10 Jun 2020 at 04:42, Rayagonda Kokatanur > wrote: > > > > From: Bharat Kumar Reddy Gooty > > > > By default re-location happens to higher address of DDR, > > relocation happens to a higher address Thank you, will fix it. > > > i.e, DDR start + DDR size. > > > > Limit re-location to happen within 16MB memory, > > start 0xFF00_ and end 0x1__ > > Please add the motivation for this patch. Why? We use u-boot to collect the ramdump. We are restricting the u-boot to use only 16MB. So that we can reserve only 16MB DDR Thanks, Rayagonda > > > > > Signed-off-by: Bharat Kumar Reddy Gooty > > Signed-off-by: Rayagonda Kokatanur > > --- > > board/broadcom/bcmns3/ns3.c | 22 +++--- > > 1 file changed, 19 insertions(+), 3 deletions(-) > > > > Reviewed-by: Simon Glass
Re: [RFC PATCH 1/3] xhci: Add polling support for USB keyboards
On 25/06/2020 17:10, Jason Wessel wrote:
> The xhci driver was causing intermittent 5 second delays from the USB
> keyboard polling hook. Executing something like a "sleep 1" for
> example would sleep for 5 seconds, unless an event occurred on
> the USB bus to shorten the delay.
>
> Modeled after the code in the DWC2 driver, a nonblock state was added
> to quickly return instead of blocking for up to 5 seconds waiting for
> an event before timing out.
>
> Signed-off-by: Jason Wessel
> ---
> drivers/usb/host/xhci-ring.c | 24 +++-
> drivers/usb/host/xhci.c | 10 +-
> include/usb/xhci.h | 5 +++--
> 3 files changed, 23 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> index 86aeaab412..1f7b3a8e0b 100644
> --- a/drivers/usb/host/xhci-ring.c
> +++ b/drivers/usb/host/xhci-ring.c
> @@ -434,7 +434,8 @@ static int event_ready(struct xhci_ctrl *ctrl)
> * @param expected TRB type expected from Event TRB
> * @return pointer to event trb
> */
> -union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type
> expected)
> +union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type
> expected,
> + bool nonblock)
> {
> trb_type type;
> unsigned long ts = get_timer(0);
> @@ -442,8 +443,11 @@ union xhci_trb *xhci_wait_for_event(struct xhci_ctrl
> *ctrl, trb_type expected)
> do {
> union xhci_trb *event = ctrl->event_ring->dequeue;
>
> - if (!event_ready(ctrl))
> + if (!event_ready(ctrl)) {
> + if (nonblock)
> + return NULL;
> continue;
> + }
>
> type = TRB_FIELD_TO_TYPE(le32_to_cpu(event->event_cmd.flags));
> if (type == expected)
> @@ -493,7 +497,7 @@ static void abort_td(struct usb_device *udev, int
> ep_index)
>
> xhci_queue_command(ctrl, NULL, udev->slot_id, ep_index, TRB_STOP_RING);
>
> - event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> + event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
> field = le32_to_cpu(event->trans_event.flags);
> BUG_ON(TRB_TO_SLOT_ID(field) != udev->slot_id);
> BUG_ON(TRB_TO_EP_INDEX(field) != ep_index);
> @@ -501,7 +505,7 @@ static void abort_td(struct usb_device *udev, int
> ep_index)
> != COMP_STOP)));
> xhci_acknowledge_event(ctrl);
>
> - event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
> + event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
> BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
> != udev->slot_id || GET_COMP_CODE(le32_to_cpu(
> event->event_cmd.status)) != COMP_SUCCESS);
> @@ -509,7 +513,7 @@ static void abort_td(struct usb_device *udev, int
> ep_index)
>
> xhci_queue_command(ctrl, (void *)((uintptr_t)ring->enqueue |
> ring->cycle_state), udev->slot_id, ep_index, TRB_SET_DEQ);
> - event = xhci_wait_for_event(ctrl, TRB_COMPLETION);
> + event = xhci_wait_for_event(ctrl, TRB_COMPLETION, false);
> BUG_ON(TRB_TO_SLOT_ID(le32_to_cpu(event->event_cmd.flags))
> != udev->slot_id || GET_COMP_CODE(le32_to_cpu(
> event->event_cmd.status)) != COMP_SUCCESS);
> @@ -555,7 +559,7 @@ static void record_transfer_result(struct usb_device
> *udev,
> * @return returns 0 if successful else -1 on failure
> */
> int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
> - int length, void *buffer)
> + int length, void *buffer, bool nonblock)
> {
> int num_trbs = 0;
> struct xhci_generic_trb *start_trb;
> @@ -714,8 +718,10 @@ int xhci_bulk_tx(struct usb_device *udev, unsigned long
> pipe,
>
> giveback_first_trb(udev, ep_index, start_cycle, start_trb);
>
> - event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> + event = xhci_wait_for_event(ctrl, TRB_TRANSFER, nonblock);
> if (!event) {
> + if (nonblock)
> + return -EINVAL;
> debug("XHCI bulk transfer timed out, aborting...\n");
> abort_td(udev, ep_index);
> udev->status = USB_ST_NAK_REC; /* closest thing to a timeout */
> @@ -911,7 +917,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
> pipe,
>
> giveback_first_trb(udev, ep_index, start_cycle, start_trb);
>
> - event = xhci_wait_for_event(ctrl, TRB_TRANSFER);
> + event = xhci_wait_for_event(ctrl, TRB_TRANSFER, false);
> if (!event)
> goto abort;
> field = le32_to_cpu(event->trans_event.flags);
> @@ -929,7 +935,7 @@ int xhci_ctrl_tx(struct usb_device *udev, unsigned long
> pipe,
> if (GET_COMP_CODE(le32_to_cpu(event->trans_event.transfer_len))
> == COMP_SHORT_TX) {
> /* Short data stage, clear up additional status stage
Re: [RFC PATCH 3/3] common/usb.c: Work around keyboard reporting "USB device not accepting new address"
On 25/06/2020 17:10, Jason Wessel wrote:
> When resetting the rpi3 board sometimes it will display:
> USB device not accepting new address (error=0)
>
> After the message appears, the usb keyboard will not work. It seems
> that the configuration actually did succeed however. Checking the
> device status for a return code of zero and continuing allows the usb
> keyboard and other usb devices to work function.
>
> Signed-off-by: Jason Wessel
> ---
> common/usb.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/common/usb.c b/common/usb.c
> index aad13fd9c5..2f7f205444 100644
> --- a/common/usb.c
> +++ b/common/usb.c
> @@ -1054,11 +1054,13 @@ static int usb_prepare_device(struct usb_device *dev,
> int addr, bool do_read,
> dev->devnum = addr;
>
> err = usb_set_address(dev); /* set address */
> -
> - if (err < 0) {
> - printf("\n USB device not accepting new address " \
> + if (err < 0)
> + debug("\n usb_set_address return < 0\n");
> + if (err < 0 && dev->status != 0) {
> + printf("\n USB device not accepting new address " \
> "(error=%lX)\n", dev->status);
> - return err;
> + if (dev->status != 0)
Always true as you already checked "dev->status != 0" in the first if.
Regards,
Matthias
> + return err;
> }
>
> mdelay(10); /* Let the SET_ADDRESS settle */
>
Re: [PATCH] video: check hardware version of DSI
Hi Yannick,
Many thanks for your patch,
Reviewed-by: Philippe Cornu
Philippe :-)
On 6/24/20 10:43 AM, Yannick Fertre wrote:
> Check the hardware version of DSI. Versions 1.30 & 1.31 are only
> supported.
>
> Signed-off-by: Yannick Fertre
> ---
> drivers/video/stm32/stm32_dsi.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/stm32/stm32_dsi.c b/drivers/video/stm32/stm32_dsi.c
> index 04796435f1..31ab8ebec7 100644
> --- a/drivers/video/stm32/stm32_dsi.c
> +++ b/drivers/video/stm32/stm32_dsi.c
> @@ -271,7 +271,6 @@ static int dsi_get_lane_mbps(void *priv_data, struct
> display_timing *timings,
> u32 val;
>
> /* Update lane capabilities according to hw version */
> - dsi->hw_version = dsi_read(dsi, DSI_VERSION) & VERSION;
> dsi->lane_min_kbps = LANE_MIN_KBPS;
> dsi->lane_max_kbps = LANE_MAX_KBPS;
> if (dsi->hw_version == HWVER_131) {
> @@ -475,6 +474,15 @@ static int stm32_dsi_probe(struct udevice *dev)
> /* Reset */
> reset_deassert(&rst);
>
> + /* check hardware version */
> + priv->hw_version = dsi_read(priv, DSI_VERSION) & VERSION;
> + if (priv->hw_version != HWVER_130 &&
> + priv->hw_version != HWVER_131) {
> + dev_err(dev, "DSI version 0x%x not supported\n",
> priv->hw_version);
> + ret = -ENODEV;
> + goto err_clk;
> + }
> +
> return 0;
> err_clk:
> clk_disable(&clk);
>
Re: [PATCH v3 02/15] arm: cpu: armv8: add L3 memory flush support
Hi Simon, On Fri, Jun 26, 2020 at 7:13 AM Simon Glass wrote: > > Hi Rayagonda, > > On Fri, 19 Jun 2020 at 10:55, Rayagonda Kokatanur > wrote: > > > > Hi Simon, > > > > On Wed, Jun 17, 2020 at 8:42 AM Simon Glass wrote: > > > > > > On Wed, 10 Jun 2020 at 04:41, Rayagonda Kokatanur > > > wrote: > > > > > > > > Add L3 memory flush support for NS3. > > > > > > > > Signed-off-by: Rayagonda Kokatanur > > > > --- > > > > arch/arm/cpu/armv8/Makefile | 1 + > > > > arch/arm/cpu/armv8/bcmns3/Makefile | 5 ++ > > > > arch/arm/cpu/armv8/bcmns3/lowlevel.S | 90 > > > > 3 files changed, 96 insertions(+) > > > > create mode 100644 arch/arm/cpu/armv8/bcmns3/Makefile > > > > create mode 100644 arch/arm/cpu/armv8/bcmns3/lowlevel.S > > > > > > > > diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile > > > > index 2e48df0eb9..7e33a183d5 100644 > > > > --- a/arch/arm/cpu/armv8/Makefile > > > > +++ b/arch/arm/cpu/armv8/Makefile > > > > @@ -39,3 +39,4 @@ obj-$(CONFIG_S32V234) += s32v234/ > > > > obj-$(CONFIG_TARGET_HIKEY) += hisilicon/ > > > > obj-$(CONFIG_ARMV8_PSCI) += psci.o > > > > obj-$(CONFIG_ARCH_SUNXI) += lowlevel_init.o > > > > +obj-$(CONFIG_TARGET_BCMNS3) += bcmns3/ > > > > diff --git a/arch/arm/cpu/armv8/bcmns3/Makefile > > > > b/arch/arm/cpu/armv8/bcmns3/Makefile > > > > new file mode 100644 > > > > index 00..a35e29d11a > > > > --- /dev/null > > > > +++ b/arch/arm/cpu/armv8/bcmns3/Makefile > > > > @@ -0,0 +1,5 @@ > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > +# > > > > +# Copyright 2020 Broadcom. > > > > + > > > > +obj-y += lowlevel.o > > > > diff --git a/arch/arm/cpu/armv8/bcmns3/lowlevel.S > > > > b/arch/arm/cpu/armv8/bcmns3/lowlevel.S > > > > new file mode 100644 > > > > index 00..202286248e > > > > --- /dev/null > > > > +++ b/arch/arm/cpu/armv8/bcmns3/lowlevel.S > > > > @@ -0,0 +1,90 @@ > > > > +/* SPDX-License-Identifier: GPL-2.0+ */ > > > > +/* > > > > + * Copyright 2020 Broadcom > > > > + * > > > > + * Extracted from fsl-layerscape/lowlevel.S > > > > > > Should this file be common, then? Is the (c) correct? > > > > Do you mean, file "arch/arm/cpu/armv8/bcmns3/lowlevel.S" should be > > common and for common file copyright tag should be "(C) Copyright > > 2020" instead of "Copyright 2020 Broadcom". > > > > The comment suggests it was copied from another file, in which case > you should keep the (c) from that file, perhaps adding your own. > > But if the two files are the same, can you just have one file and move > it to a common location? The comment is misleading. Though it is copied from another file but both files are not same. Let me remove that comment. Thank you, Rayagonda > > > Please let me know. > > Consider yourself let. > > Regards, > Simon
RE: [PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support
>-Original Message- >From: Bin Meng >Sent: 23 June 2020 11:00 >To: Rick Chen ; Simon Glass ; >Pragnesh Patel ; Sagar Kadam >; U-Boot Mailing List >Cc: Bin Meng >Subject: [PATCH 5/5] riscv: sifive: fu540: Add gpio-restart support > >[External Email] Do not click links or attachments unless you recognize the >sender and know the content is safe > >From: Bin Meng > >The HiFive Unleashed board wires GPIO pin#10 to the input of the system >reset signal. This adds gpio reboot support. > >Signed-off-by: Bin Meng >--- > > board/sifive/fu540/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Pragnesh Patel
RE: [PATCH 4/5] riscv: qemu: Add syscon reboot and poweroff support
>-Original Message- >From: Bin Meng >Sent: 23 June 2020 11:00 >To: Rick Chen ; Simon Glass ; >Pragnesh Patel ; Sagar Kadam >; U-Boot Mailing List >Cc: Bin Meng >Subject: [PATCH 4/5] riscv: qemu: Add syscon reboot and poweroff support > >[External Email] Do not click links or attachments unless you recognize the >sender and know the content is safe > >From: Bin Meng > >This adds syscon reboot and poweroff support to QEMU RISC-V. > >Signed-off-by: Bin Meng >--- > > board/emulation/qemu-riscv/Kconfig | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Pragnesh Patel
