Re: [PATCH v2] usb: xhci-brcm: Include header file needed for dev_err
On 10/6/21 8:05 AM, Stefan Agner wrote:
dev_err seems to be moved to different header file. Include
dm/device_compat.h file to compile properly.
Fixes: 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
Signed-off-by: Stefan Agner
---
Changes in v2:
- Correctly place include
drivers/usb/host/xhci-brcm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci-brcm.c b/drivers/usb/host/xhci-brcm.c
index 27c4bbfcba..fe17924028 100644
--- a/drivers/usb/host/xhci-brcm.c
+++ b/drivers/usb/host/xhci-brcm.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#define DRD2U3H_XHC_REGS_AXIWRA 0xC08
Does no defconfig compile this module? How was this include missing for so long?
--Sean
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 20:48, Pali Rohár wrote:
On Tuesday 26 October 2021 16:21:02 Stefan Roese wrote:
On 26.10.21 14:40, Pali Rohár wrote:
My another guess there could be a problem is usage of stack. Maybe it is
possible that register with stack pointer is not initialized after the
full transfer when going to execute main image. Same arm baudrate change
code is used after the SPL and before main U-Boot, and the first
instruction is "push". Maybe modifying the arm code to not use stack
when switching the baudrate back to 115200 could also help. I will look
at it.
Thanks.
Here is dirty hack patch which completely disable calling code for
changing baudrate back to 115200 on ARM side:
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 5f4ff673972e..00d58a239c71 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1070,17 +1070,17 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
int baudrate)
return rc;
if (baudrate) {
- char buf[sizeof(kwb_baud_magic)];
-
- kwboot_printv("Waiting 1s for baudrate change magic\n");
- rc = kwboot_tty_recv(tty, buf, sizeof(buf), 1000);
- if (rc)
- return rc;
-
- if (memcmp(buf, kwb_baud_magic, sizeof(buf))) {
- errno = EPROTO;
- return -1;
- }
+// char buf[sizeof(kwb_baud_magic)];
+//
+// kwboot_printv("Waiting 1s for baudrate change magic\n");
+// rc = kwboot_tty_recv(tty, buf, sizeof(buf), 1000);
+// if (rc)
+// return rc;
+//
+// if (memcmp(buf, kwb_baud_magic, sizeof(buf))) {
+// errno = EPROTO;
+// return -1;
+// }
kwboot_printv("\nChanging baudrate back to 115200 Bd\n\n");
rc = kwboot_tty_change_baudrate(tty, 115200);
@@ -1551,8 +1551,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
* This code is appended after the data part of the image and
* execaddr is changed to execute this code before U-Boot
proper.
*/
- kwboot_printv("Injecting code for changing baudrate back\n");
- _copy_baudrate_change_code(hdr, size, 1, baudrate, 115200);
+// kwboot_printv("Injecting code for changing baudrate back\n");
+// _copy_baudrate_change_code(hdr, size, 1, baudrate, 115200);
I do have this here in my version as well:
/* Update the 32-bit data checksum */
*kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img);
/* recompute header size */
hdrsz = kwbheader_size(hdr);
So I'm using the newer version, just to be sure.
/* recompute header size */
hdrsz = kwbheader_size(hdr);
As main U-Boot binary on ARM resets UART, it means that baudrate is
properly set to 115200. Probably beginning of the U-Boot output could be
lost but at least console should start.
Could you try this patch if it starts working now?
Okay, applied this patch and and booting with different baudrates works
on this board again (tested with 230400):
96 %
[..]
98 %
[..]
99 % [
]
Done
Finishing transfer
Changing baudrate back to 115200 Bd
[Type Ctrl-\ + c to quit]
U-Boot 2021.10-00908-gc129aa2f173a-dirty (Oct 27 2021 - 07:05:39 +0200)
SoC: MV78260-B0 at 1333 MHz
I2C: ready
DRAM: 2 GiB (667 MHz, 64-bit, ECC not enabled)
Loading Environment from SPIFlash... SF: Detected m25p128 with page size
256 Bytes, erase size 256 KiB, total 16 MiB
OK
Model: Marvell Armada XP theadorable
...
Thanks,
Stefan
an off-by-one error in dm_test_rtc_set_get()?
Hi Simon,
gitlab reported the following test error below:
=== FAILURES ===
__ test_ut[ut_dm_rtc_set_get] __
test/py/tests/test_ut.py:43: in test_ut
assert output.endswith('Failures: 0')
E AssertionError: assert False
E + where False = ('Failures: 0')
E + where =
'Test: dm_test_rtc_set_get: rtc.c\r\r\nexpected: 27/10/2021
03:38:15\r\r\nactual: 27/10/2021 03:38:14\r\r\ntest/dm/rtc...w, ,
1): Expected 0x0 (0), got 0xffea (-22)\r\r\nTest:
dm_test_rtc_set_get: rtc.c (flat tree)\r\r\nFailures: 1'.endswith
- Captured stdout call -
=>
See https://source.denx.de/u-boot/custodians/u-boot-x86/-/jobs/341905
But the same branch same commit, azure test results passed:
https://dev.azure.com/bmeng/GitHub/_build/results?buildId=460=results
It looks like the error is an off-by-one where actual time is 1 second
behind the expected time?
expected: 27/10/2021 03:38:15
actual: 27/10/2021 03:38:14
Is this a known issue?
Regards,
Bin
Re: [PATCH v2] usb: xhci-brcm: Include header file needed for dev_err
On Wed, Oct 6, 2021 at 8:05 PM Stefan Agner wrote:
>
> dev_err seems to be moved to different header file. Include
> dm/device_compat.h file to compile properly.
>
> Fixes: 69dae8902b16 ("linux/compat.h: Remove redefinition of dev_xxx macros")
> Signed-off-by: Stefan Agner
> ---
>
> Changes in v2:
> - Correctly place include
>
Reviewed-by: Bin Meng
Re: [PATCH] x86: Fix i8254 ifdef include guard
On Wed, Oct 27, 2021 at 11:08 AM Bin Meng wrote: > > On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva wrote: > > > > When building U-Boot with clang, it notices that the i8254.h include > > guard does not work correctly due to a typo. Fix it. > > > > Signed-off-by: Alistair Delva > > Cc: Simon Glass > > Cc: Bin Meng > > --- > > arch/x86/include/asm/i8254.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h > > index d769daf85d..bb8930338b 100644 > > --- a/arch/x86/include/asm/i8254.h > > +++ b/arch/x86/include/asm/i8254.h > > @@ -7,7 +7,7 @@ > > /* i8254.h Intel 8254 PIT registers */ > > > > #ifndef _ASMI386_I8254_H_ > > -#define _ASMI386_I8954_H_ > > +#define _ASMI386_I8254_H_ > > There is another I8954 at the end of this file. I can fix it when applying. > > > > > #define PIT_T0 0x00/* PIT channel 0 count/status */ > > #define PIT_T1 0x01/* PIT channel 1 count/status */ > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH] x86: chromebook_coral: fix C block comment
On Wed, Oct 27, 2021 at 11:07 AM Bin Meng wrote: > > On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva wrote: > > > > Fix a warning seen when compiling this dts file. > > > > Signed-off-by: Alistair Delva > > Cc: Simon Glass > > Cc: Bin Meng > > --- > > arch/x86/dts/chromebook_coral.dts | 1 + > > 1 file changed, 1 insertion(+) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object
On Wed, Oct 27, 2021 at 11:05 AM Bin Meng wrote: > > On Wed, Oct 20, 2021 at 8:51 PM Andy Shevchenko > wrote: > > > > There is no point to use Method() for the constant. > > Replace it with Name() defined object. For the _STA > > case it saves 3 bytes per each entry. > > > > Before: 2881 > > After: 2833 > > > > Signed-off-by: Andy Shevchenko > > --- > > .../asm/arch-tangier/acpi/southcluster.asl| 81 --- > > 1 file changed, 17 insertions(+), 64 deletions(-) > > > > Reviewed-by: Bin Meng applied to u-boot-x86, thanks!
Re: [PATCH v2 0/2] pxe_utils: Fix arguments to x86 zboot
On Wed, Oct 20, 2021 at 3:18 PM Zhaofeng Li wrote:
>
> Hi Simon,
>
> Thanks for your review! I have added a second patch to perform the
> cleanup that you mentioned in the review, so the actual "fix" patch
> stays minimal and easy to review.
>
> I agree that calling the bootm and zboot code directly is the real
> solution to go. The current method is inherently error-prone, and
> I wonder how many cases of "kinda works but not really" [1] like
> this are there in U-Boot.
>
> Thanks,
> Zhaofeng Li
>
> [1] Without the patch, the kernel would boot with the U-Boot log
> showing initrd being loaded. However, the kernel wouldn't
> actually get the initrd.
>
> ---
>
> This patch series fixes the issue that incorrect arguments are
> passed to x86 zboot in pxe_utils (pxe/extlinux-like config). See
> the commit message of the first patch for details.
>
> Changes since v1:
> - Added patch to clean up argv generation
>
> Zhaofeng Li (2):
> pxe_utils: Fix arguments to x86 zboot
> pxe_utils: Clean up {bootm,zboot}_argv generation
>
> cmd/pxe_utils.c | 45 -
> 1 file changed, 32 insertions(+), 13 deletions(-)
>
series applied to u-boot-x86, thanks!
Re: [PATCH] x86: Fix i8254 ifdef include guard
On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva wrote: > > When building U-Boot with clang, it notices that the i8254.h include > guard does not work correctly due to a typo. Fix it. > > Signed-off-by: Alistair Delva > Cc: Simon Glass > Cc: Bin Meng > --- > arch/x86/include/asm/i8254.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/include/asm/i8254.h b/arch/x86/include/asm/i8254.h > index d769daf85d..bb8930338b 100644 > --- a/arch/x86/include/asm/i8254.h > +++ b/arch/x86/include/asm/i8254.h > @@ -7,7 +7,7 @@ > /* i8254.h Intel 8254 PIT registers */ > > #ifndef _ASMI386_I8254_H_ > -#define _ASMI386_I8954_H_ > +#define _ASMI386_I8254_H_ There is another I8954 at the end of this file. I can fix it when applying. > > #define PIT_T0 0x00/* PIT channel 0 count/status */ > #define PIT_T1 0x01/* PIT channel 1 count/status */ Reviewed-by: Bin Meng
Re: [PATCH] x86: chromebook_coral: fix C block comment
On Thu, Oct 21, 2021 at 5:31 AM Alistair Delva wrote: > > Fix a warning seen when compiling this dts file. > > Signed-off-by: Alistair Delva > Cc: Simon Glass > Cc: Bin Meng > --- > arch/x86/dts/chromebook_coral.dts | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Bin Meng
Re: [PATCH v1 1/1] x86: tangier: Replace Method() by Name() for _STA object
On Wed, Oct 20, 2021 at 8:51 PM Andy Shevchenko wrote: > > There is no point to use Method() for the constant. > Replace it with Name() defined object. For the _STA > case it saves 3 bytes per each entry. > > Before: 2881 > After: 2833 > > Signed-off-by: Andy Shevchenko > --- > .../asm/arch-tangier/acpi/southcluster.asl| 81 --- > 1 file changed, 17 insertions(+), 64 deletions(-) > Reviewed-by: Bin Meng
Re: [PATCH v1 2/2] x86: edison: Don't take SD card detect pin into consideration
Hi Andy,
On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
wrote:
>
> There are two PCB designs in the wild which use the opposite
> signaling for SD card detect. This makes U-Boot working in one case
> and failing in the other. Quirk this out by disconnecting SD card
> detect pin from the PCB by switching to mode 3.
>
> BugLink: https://github.com/edison-fw/meta-intel-edison/issues/136
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/dts/edison.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
> index 2c8cf6c07102..04e8a4e457c8 100644
> --- a/arch/x86/dts/edison.dts
> +++ b/arch/x86/dts/edison.dts
> @@ -94,6 +94,7 @@
> sdcard: mmc@ff3fa000 {
> compatible = "intel,sdhci-tangier";
> reg = <0xff3fa000 0x1000>;
> + cd-inverted;
So I wonder how sd card ever worked without the "cd-inverted" property?
> };
>
> pmu: power@ff00b000 {
> @@ -131,6 +132,17 @@
> compatible = "intel,pinctrl-tangier";
> reg = <0xff0c 0x8000>;
>
> + /*
> +* Disconnect SD card detect, so it won't affect the reality
> +* on two different PCB designs where it's using the opposite
> +* signaling: Edison/Arduino uses Active Low, while SparkFun
> +* went with Active High.
> +*/
> + sd_cd@0 {
> + pad-offset = <37>;
> + mode-func = <3>;
> + };
> +
> /*
> * Initial configuration came from the firmware.
> * Which quite likely has been used in the phones, where I2C
> #8,
> --
Regards,
Bin
Re: [PATCH v1 1/2] x86: tangier: Enable support for SD/SDIO family in the pinmux driver
Hi Andy,
On Sat, Oct 16, 2021 at 1:27 AM Andy Shevchenko
wrote:
>
> We would need to quirk out Card Detect case and for that we allow
> configuring SD/SDIO family of pins.
>
> Signed-off-by: Andy Shevchenko
> ---
> arch/x86/cpu/tangier/pinmux.c | 39 ++-
> 1 file changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/cpu/tangier/pinmux.c b/arch/x86/cpu/tangier/pinmux.c
> index acf97e3af51d..8385167b2b6b 100644
> --- a/arch/x86/cpu/tangier/pinmux.c
> +++ b/arch/x86/cpu/tangier/pinmux.c
> @@ -37,8 +37,9 @@ struct mrfld_family {
> .npins = (e) - (s) + 1, \
> }
>
> -/* Now we only support I2C family of pins */
> +/* Now we only support SD/SDIO and I2C families of pins */
> static struct mrfld_family mrfld_families[] = {
> + MRFLD_FAMILY(3, 37, 56),
> MRFLD_FAMILY(7, 101, 114),
> };
>
> @@ -125,6 +126,34 @@ static int mrfld_pinconfig_protected(unsigned int pin,
> u32 mask, u32 bits)
> return ret;
> }
>
> +static int mrfld_pinconfig(unsigned int pin, u32 mask, u32 bits)
> +{
> + struct mrfld_pinctrl *pinctrl;
> + struct udevice *dev;
> + void __iomem *bufcfg;
> + u32 v, value;
> + int ret;
> +
> + ret = syscon_get_by_driver_data(X86_SYSCON_PINCONF, );
> + if (ret)
> + return ret;
> +
> + pinctrl = dev_get_priv(dev);
> +
> + bufcfg = mrfld_get_bufcfg(pinctrl, pin);
> + if (!bufcfg)
> + return -EINVAL;
> +
> + value = readl(bufcfg);
> + v = (value & ~mask) | (bits & mask);
> + writel(v, bufcfg);
> +
> + debug("v: 0x%x p: 0x%x bits: %d, mask: %d bufcfg: 0x%p\n",
> + v, (u32)bufcfg, bits, mask, bufcfg);
> +
> + return 0;
This function can be consolidated with mrfld_pinconfig_protected(),
ie: updating mrfld_pinconfig_protected() to call mrfld_pinconfig().
> +}
> +
> static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
> {
> bool is_protected;
> @@ -133,10 +162,7 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
> u32 mask;
> int ret;
>
> - /* For now we only support just protected Family of pins */
> is_protected = ofnode_read_bool(pin_node, "protected");
> - if (!is_protected)
> - return -ENOTSUPP;
>
> pad_offset = ofnode_read_s32_default(pin_node, "pad-offset", -1);
> if (pad_offset == -1)
> @@ -152,7 +178,10 @@ static int mrfld_pinctrl_cfg_pin(ofnode pin_node)
> if (mode & ~mask)
> return -ENOTSUPP;
>
> - ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
> + if (is_protected)
> + ret = mrfld_pinconfig_protected(pad_offset, mask, mode);
> + else
> + ret = mrfld_pinconfig(pad_offset, mask, mode);
>
> return ret;
> }
Regards,
Bin
Re: [PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
On Sun, Oct 24, 2021 at 9:39 AM Simon Glass wrote: > > Hi Mark, > > On Thu, 21 Oct 2021 at 02:51, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Wed, 20 Oct 2021 16:44:41 -0600 > > > > > > Hi Rob, > > > > > > On Mon, 18 Oct 2021 at 16:26, Rob Herring wrote: > > > > > > > > On Wed, Oct 13, 2021 at 11:33 AM Simon Glass wrote: > > > > > > > > > > " > > > > > Hi Rob, > > > > > > > > > > On Tue, 12 Oct 2021 at 09:05, Rob Herring wrote: > > > > > > > > > > > > On Tue, Oct 12, 2021 at 8:41 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Hi Rob, > > > > > > > > > > > > > > On Mon, 4 Oct 2021 at 13:30, Rob Herring wrote: > > > > > > > > > > > > > > > > On Sun, Oct 03, 2021 at 12:51:53PM -0600, Simon Glass wrote: > > > > > > > > > U-Boot makes use of the devicetree for its driver model. > > > > > > > > > Devices are bound > > > > > > > > > based on the hardware description in the devicetree. > > > > > > > > > > > > > > > > > > Since U-Boot is not an operating system, it has no command > > > > > > > > > line or user > > > > > > > > > space to provide configuration and policy information. This > > > > > > > > > must be made > > > > > > > > > available in some other way. > > > > > > > > > > > > > > > > > > Therefore U-Boot uses devicetree for configuration and > > > > > > > > > run-time control > > > > > > > > > and has done for approximately 9 years. This works extremely > > > > > > > > > well in the > > > > > > > > > project and is very flexible. However the bindings have never > > > > > > > > > been > > > > > > > > > incorporated in the devicetree bindings in the Linux tree. > > > > > > > > > This could be > > > > > > > > > a good time to start this work as we try to create standard > > > > > > > > > bindings for > > > > > > > > > communicating between firmware components. > > > > > > > > > > > > > > > > > > Add an initial binding for this node, covering just the > > > > > > > > > config node, which > > > > > > > > > is the main requirement. It is similar in concept to the > > > > > > > > > chosen node, but > > > > > > > > > used for passing information between firmware components, > > > > > > > > > instead of from > > > > > > > > > firmware to operating system. > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > --- > > > > > > > > > Please be kind in your review. Some words about why this is > > > > > > > > > needed are > > > > > > > > > included in the description in config.yaml file. > > > > > > > > > > > > > > > > > > The last attempt to add just one property needed by U-Boot > > > > > > > > > went into the > > > > > > > > > weeds 6 years ago, with what I see as confusion about the > > > > > > > > > role of the > > > > > > > > > chosen node in devicetree[1]. > > > > > > > > > > > > > > > > > > I am trying again in the hope of reaching resolution rather > > > > > > > > > than just > > > > > > > > > going around in circles with the 'devicetree is a hardware > > > > > > > > > description' > > > > > > > > > argument :-) > > > > > > > > > > > > > > > > > > Quoting from the introduction to latest devicetree spec[2]: > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > To initialize and boot a computer system, various software > > > > > > > > > components > > > > > > > > > interact. Firmware might perform low-level initialization of > > > > > > > > > the system > > > > > > > > > hardware before passing control to software such as an > > > > > > > > > operating system, > > > > > > > > > bootloader, or hypervisor. Bootloaders and hypervisors can, > > > > > > > > > in turn, > > > > > > > > > load and transfer control to operating systems. Standard, > > > > > > > > > consistent > > > > > > > > > interfaces and conventions facilitate the interactions > > > > > > > > > between these > > > > > > > > > software components. In this document the term boot program > > > > > > > > > is used to > > > > > > > > > generically refer to a software component that initializes > > > > > > > > > the system > > > > > > > > > state and executes another software component referred to as > > > > > > > > > a client > > > > > > > > > program. > > > > > > > > > <<< > > > > > > > > > > > > > > > > > > This clearly envisages multiple software components in the > > > > > > > > > firmware > > > > > > > > > domain and in fact that is the case today. They need some way > > > > > > > > > to > > > > > > > > > communicate configuration data such as memory setup, > > > > > > > > > runtime-feature > > > > > > > > > selection and developer conveniences. Devicetree seems ideal, > > > > > > > > > at least for > > > > > > > > > components where the performance / memory requirements of > > > > > > > > > devicetree are > > > > > > > > > affordable. > > > > > > > > > > > > > > > > > > I hope that the Linux community (which owns the devicetree > > > > > > > > > bindings) finds > > > > > > > > > this initiative valuable and acceptable. > > > > > > > > > > > > >
Re: [PATCH 1/3] net: dsa: Use true instead of 1 in the set_promisc() call
On Sun, Oct 17, 2021 at 2:26 AM Ramon Fried wrote: > > On Wed, Sep 29, 2021 at 4:32 PM Vladimir Oltean > wrote: > > > > On Wed, Sep 29, 2021 at 01:50:44PM +0800, Bin Meng wrote: > > > set_promisc() call accepts the parameter of a bool type. Make it > > > clear by using true instead of 1. > > > > > > Signed-off-by: Bin Meng > > > --- > > > > > > net/dsa-uclass.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c > > > index 694664d81b..dcefec03f4 100644 > > > --- a/net/dsa-uclass.c > > > +++ b/net/dsa-uclass.c > > > @@ -282,7 +282,7 @@ static int dsa_port_probe(struct udevice *pdev) > > > struct eth_ops *eth_ops = eth_get_ops(master); > > > > > > if (eth_ops->set_promisc) > > > - eth_ops->set_promisc(master, 1); > > > + eth_ops->set_promisc(master, true); > > > > > > return 0; > > > } > > > -- > > > 2.25.1 > > > > > > > Reviewed-by: Vladimir Oltean > Reviewed-by: Ramon Fried Ping for apply?
Re: [PATCH 1/1] env: superfluous check before free()
On Tue, Oct 26, 2021 at 12:41:59AM +0200, Heinrich Schuchardt wrote: > Free() checks if its argument in NULL. There is no need for the caller to > do the same. > > Signed-off-by: Heinrich Schuchardt Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] dfu: Sort Kconfig entries alphabetically
On Tue, Oct 26, 2021 at 12:37:05AM +0200, Marek Vasut wrote: > The DFU_MTD Kconfig entry is in the wrong position, move it into the > correct alphabetically sorted position. No functional change. > > Signed-off-by: Marek Vasut > Cc: Lukasz Majewski > Cc: Patrice Chotard > Cc: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: uuid: fix the test on RNG device presence
On Fri, Oct 22, 2021 at 05:05:47PM +0200, Patrick Delaunay wrote:
> Correct the test on RNG device presence,when ret is equal to 0,
> before to call dm_rng_read function.
>
> Without this patch the RNG device is not used when present (when ret == 0)
> or a data abort occurs in dm_rng_read when CONFIG_DM_RNG is activated but
> the RNG device is not present in device tree (ret != 0 and devp = NULL).
>
> Fixes: 92fdad28cfdf ("lib: uuid: use RNG device if present")
> CC: Matthias Brugger
> CC: Torsten Duwe
> Signed-off-by: Patrick Delaunay
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] common: Kconfig.boot: add config SPL_FIT_RSASSA_PSS
On Fri, Oct 15, 2021 at 11:35:03AM +0200, Philippe Reynes wrote:
> The padding pss is only supported on u-boot and tools since
> commit 2bbed3ff8c7f ("image: Use Kconfig to enable FIT_RSASSA_PSS on host")
>
> This commit adds the config SPL_FIT_RSASSA_PSS to support
> the padding pss in the SPL.
>
> Signed-off-by: Philippe Reynes
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] lib: rsa: rsa-verify: also check that padding is not NULL
On Fri, Oct 15, 2021 at 11:28:47AM +0200, Philippe Reynes wrote: > This commit adds a check on the padding in the function rsa_verify_key > to avoid using a NULL pointer. > > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] firmware: scmi: fix struct layout for scmi_clk_rate_set_in
On Wed, Oct 13, 2021 at 04:00:04PM +0200, Clément Léger wrote:
> First two fields are reversed compared to what is expected by the SCMI
> specification.
>
> Signed-off-by: Clément Léger
> Fixes: 60388844836 ("clk: add clock driver for SCMI agents")
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] cmd: nand biterr - Add support for nand biterr command
On Tue, Jun 29, 2021 at 12:46:11PM +0530, Balamanikandan Gunasundar wrote: > The command shall be used to induce bit errors in the nand page > manually. The code flips a bit in the specified offset without > changing the ECC. This helps to see how the software handles the > error. > > The patch is ported from > https://patchwork.ozlabs.org/project/uboot/patch/\ > 1325691123-19565-1-git-send-email-holger.bru...@keymile.com > > The implementation is inspired from > 'mtd-utils/nand-utils/nandflipbits.c' > > Signed-off-by: Balamanikandan Gunasundar > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Pull request for efi-2022-01-rc1-2
The following changes since commit 397b35f09794e40d62d5e4f53992e2a711dc8be1: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sunxi (2021-10-25 12:09:57 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2022-01-rc1-2 for you to fetch changes up to 65aa259aa723793f394abf81b7b0d639826e35b7: efi_loader: add DeployedMode and AuditMode variable measurement (2021-10-26 21:33:19 +0200) Gitlab CI showed no problems: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/9619 Pull request for efi-2022-01-rc1-2 doc: Remove obsolete PPC4XX references UEFI: Implement missing TCG2 measurements Code clean up AKASHI Takahiro (3): Revert "Revert "mkeficapsule: Remove dtb related options"" Revert "Revert "doc: Update CapsuleUpdate READMEs"" efi_loader: capsule: add back efi_get_public_key_data() Heinrich Schuchardt (6): doc: remove AMCC PPC405 processor references .mailmap: add Heinrich Schuchardt efi_loader: treat UEFI variable name as const efi_loader: function to get GUID for variable name efi_loader: simplify efi_sigstore_parse_sigdb() efi_loader: simplify tcg2_measure_secure_boot_variable() Masahisa Kojima (5): efi_loader: add missing const qualifier efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: simplify tcg2_measure_secure_boot_variable() efi_loader: add DeployedMode and AuditMode variable measurement Thomas Huth (1): doc: Remove the obsolete README.mpc74xx file .mailmap | 1 + doc/README.bedbug | 22 --- doc/README.mpc74xx| 22 --- doc/develop/uefi/uefi.rst | 124 +++ include/blk.h | 3 + include/efi_api.h | 2 +- include/efi_loader.h | 7 +- include/efi_tcg2.h| 27 include/efi_variable.h| 24 ++- include/smbios.h | 17 ++- lib/efi_loader/Kconfig| 1 + lib/efi_loader/efi_boottime.c | 9 +- lib/efi_loader/efi_capsule.c | 36 + lib/efi_loader/efi_device_path.c | 27 lib/efi_loader/efi_signature.c| 38 + lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c | 314 -- lib/efi_loader/efi_var_common.c | 14 +- lib/efi_loader/efi_var_mem.c | 7 +- lib/efi_loader/efi_variable.c | 9 +- lib/efi_loader/efi_variable_tee.c | 16 +- lib/smbios-parser.c | 152 -- tools/mkeficapsule.c | 229 +-- 23 files changed, 715 insertions(+), 388 deletions(-) delete mode 100644 doc/README.mpc74xx
[BUG] binman does not check signature of toolchain
Downloading binaries and executing without checking the authenticity is at least unwise. When binman downloads GCC it should also download and verify the GPG signatures. Additionally binman could hold a list of the SHA256 hashes of all binaries in question for a further check. Best regards Heinrich
Re: [PATCH1/1]sqfs: sqfs_tokenize() should fill the tokens list instead of free items
On Sat, Oct 16, 2021 at 10:19:48AM +0800, Jincheng Wang wrote:
> We can delete two lines of code to avoid double free bug, but still a wild
> pointers bug.
>
> A test for wild pointers:
> sqfsls host 0 1//2/3//4/5
>
> Fill the tokens list can solve it well.
>
>
> Signed-off-by: Jincheng Wang
> ---
> fs/squashfs/sqfs.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> }
>
> diff --git a/fs/squashfs/sqfs.c b/fs/squashfs/sqfs.c
> index e2d91c654c..50d3f8b71e 100644
> --- a/fs/squashfs/sqfs.c
> +++ b/fs/squashfs/sqfs.c
> @@ -303,8 +303,9 @@ static int sqfs_tokenize(char **tokens, int count,
> const char *str)
> aux = strtok(!j ? strc : NULL, "/");
> tokens[j] = strdup(aux);
> if (!tokens[j]) {
> - for (i = 0; i < j; i++)
> - free(tokens[i]);
> + /* fill tokens list to avoid wild pointers being freed*/
> + for (i = j + 1; i < count; i++)
> + tokens[i] = 0;
> ret = -ENOMEM;
> goto free_strc;
Aside from the whitespace having been destroyed, any comments from the
maintainers / reviewers? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 13/41] dm: core: Add a way to obtain a string list
On Sun, 24 Oct 2021 at 02:26, Simon Glass wrote:
>
> At present we support reading a string list a string at a time. Apart
> from being inefficient, this makes it impossible to separate reading of
> the devicetree into the of_to_plat() method where it belongs, since any
> code which needs access to the string must read it from the devicetree.
>
> Add a function which returns the string property as an array of pointers
> to the strings, which is easily used by clients.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> drivers/core/ofnode.c | 26 ++
> drivers/core/read.c | 6 ++
> include/dm/ofnode.h | 20
> include/dm/read.h | 28
> test/dm/ofnode.c | 20
> 5 files changed, 100 insertions(+)
>
> diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
> index 08705ef8d99..709bea272a6 100644
> --- a/drivers/core/ofnode.c
> +++ b/drivers/core/ofnode.c
> @@ -456,6 +456,32 @@ int ofnode_read_string_count(ofnode node, const char
> *property)
> }
> }
>
> +int ofnode_read_string_list(ofnode node, const char *property,
> + const char ***listp)
> +{
> + const char **prop;
> + int count;
> + int i;
> +
> + *listp = NULL;
> + count = ofnode_read_string_count(node, property);
> + if (count < 0)
> + return count;
> + if (!count)
> + return 0;
Those can fold into a single if and always return 'count'.
if (count <= 0)
return count;
> +
> + prop = calloc(count + 1, sizeof(char *));
[...]
Regards
/Ilias
Re: [PATCH v4 2/4] efi_loader: add UEFI GPT measurement
On 10/26/21 10:27, Masahisa Kojima wrote:
This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client Platform Firmware
Profile Specification
Signed-off-by: Masahisa Kojima
---
Changes in v4:
- update commit message
- return EFI_SUCCESS if device path is NULL
- use memalign()
Changes in v3:
- EV_EFI_GPT_EVENT is measured before EV_SEPARATOR, same as
other PCRs
- use PTR_ARRAY instead of ARRAY
- create sub-function of allocating io_aligned buffer
- move search_gpt_dp_node() into efi_device_path.c
include/blk.h| 3 +
include/efi_loader.h | 3 +-
include/efi_tcg2.h | 12 +++
lib/efi_loader/efi_boottime.c| 2 +-
lib/efi_loader/efi_device_path.c | 27 ++
lib/efi_loader/efi_tcg2.c| 146 ++-
6 files changed, 190 insertions(+), 3 deletions(-)
diff --git a/include/blk.h b/include/blk.h
index 19bab081c2..f0cc7ca1a2 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -45,6 +45,9 @@ enum if_type {
#define BLK_PRD_SIZE 20
#define BLK_REV_SIZE 8
+#define PART_FORMAT_PCAT 0x1
+#define PART_FORMAT_GPT0x2
+
/*
* Identifies the partition table type (ie. MBR vs GPT GUID) signature
*/
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d0433ea52e..d52e399841 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
void efi_variables_boot_exit_notify(void);
efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
/* Measure efi application invocation */
-efi_status_t efi_tcg2_measure_efi_app_invocation(void);
+efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj
*handle);
/* Measure efi application exit */
efi_status_t efi_tcg2_measure_efi_app_exit(void);
/* Called by bootefi to initialize root node */
@@ -847,6 +847,7 @@ struct efi_device_path *efi_dp_from_lo(struct
efi_load_option *lo,
const efi_guid_t *guid);
struct efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2);
+struct efi_device_path *search_gpt_dp_node(struct efi_device_path
*device_path);
efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
efi_uintn_t *size);
unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8
**data);
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index ca66695b39..50a59f9263 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -225,6 +225,18 @@ struct smbios_handoff_table_pointers2 {
struct efi_configuration_table table_entry[];
} __packed;
+/**
+ * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
+ * @uefi_partition_header: gpt partition header
+ * @number_of_partitions: the number of partition
+ * @partitions:partition entries
+ */
+struct efi_gpt_data {
+ gpt_header uefi_partition_header;
+ u64 number_of_partitions;
+ gpt_entry partitions[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 973134b12d..1823990d9b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3004,7 +3004,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) {
- ret = efi_tcg2_measure_efi_app_invocation();
+ ret = efi_tcg2_measure_efi_app_invocation(image_obj);
if (ret != EFI_SUCCESS) {
log_warning("tcg2 measurement fails(0x%lx)\n",
ret);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index c04439d16d..735ed0bd0f 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1239,3 +1239,30 @@ efi_device_path *efi_dp_from_lo(struct efi_load_option
*lo,
return NULL;
}
+
+/**
+ * search_gpt_dp_node() - search gpt device path node
+ *
+ * @device_path: device path
+ *
+ * Return: pointer to the gpt device path node
+ */
+struct efi_device_path *search_gpt_dp_node(struct efi_device_path *device_path)
+{
+ struct efi_device_path *dp = device_path;
+
+ while (dp) {
+ if (dp->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+ dp->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+ struct efi_device_path_hard_drive_path *hd_dp =
+
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tuesday 26 October 2021 16:21:02 Stefan Roese wrote:
> On 26.10.21 14:40, Pali Rohár wrote:
> > My another guess there could be a problem is usage of stack. Maybe it is
> > possible that register with stack pointer is not initialized after the
> > full transfer when going to execute main image. Same arm baudrate change
> > code is used after the SPL and before main U-Boot, and the first
> > instruction is "push". Maybe modifying the arm code to not use stack
> > when switching the baudrate back to 115200 could also help. I will look
> > at it.
>
> Thanks.
Here is dirty hack patch which completely disable calling code for
changing baudrate back to 115200 on ARM side:
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 5f4ff673972e..00d58a239c71 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1070,17 +1070,17 @@ kwboot_xmodem(int tty, const void *_img, size_t size,
int baudrate)
return rc;
if (baudrate) {
- char buf[sizeof(kwb_baud_magic)];
-
- kwboot_printv("Waiting 1s for baudrate change magic\n");
- rc = kwboot_tty_recv(tty, buf, sizeof(buf), 1000);
- if (rc)
- return rc;
-
- if (memcmp(buf, kwb_baud_magic, sizeof(buf))) {
- errno = EPROTO;
- return -1;
- }
+// char buf[sizeof(kwb_baud_magic)];
+//
+// kwboot_printv("Waiting 1s for baudrate change magic\n");
+// rc = kwboot_tty_recv(tty, buf, sizeof(buf), 1000);
+// if (rc)
+// return rc;
+//
+// if (memcmp(buf, kwb_baud_magic, sizeof(buf))) {
+// errno = EPROTO;
+// return -1;
+// }
kwboot_printv("\nChanging baudrate back to 115200 Bd\n\n");
rc = kwboot_tty_change_baudrate(tty, 115200);
@@ -1551,8 +1551,8 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
* This code is appended after the data part of the image and
* execaddr is changed to execute this code before U-Boot
proper.
*/
- kwboot_printv("Injecting code for changing baudrate back\n");
- _copy_baudrate_change_code(hdr, size, 1, baudrate, 115200);
+// kwboot_printv("Injecting code for changing baudrate back\n");
+// _copy_baudrate_change_code(hdr, size, 1, baudrate, 115200);
/* recompute header size */
hdrsz = kwbheader_size(hdr);
As main U-Boot binary on ARM resets UART, it means that baudrate is
properly set to 115200. Probably beginning of the U-Boot output could be
lost but at least console should start.
Could you try this patch if it starts working now?
patch for rpi3 on FreeBSD
Hi, I have volunteered to coordinate a patch to u-boot for the Raspberry Pi 3 on FreeBSD. The problem is that with u-boot-2021.07 and the current MMC overlay, the SD card slot is renumbered. The SD card does not configure, and the installation card doesn't boot. The following patch to include/configs/rpi.h fixes the problem. Let me know if you need any additional information. Thanks, Mike --- rpi.h.orig 2021-10-25 23:02:36.92852 -0500 +++ rpi.h 2021-10-25 16:05:16.140924000 -0500 @@ -173,7 +173,8 @@ #if CONFIG_IS_ENABLED(CMD_MMC) #define BOOT_TARGET_MMC(func) \ func(MMC, mmc, 0) \ - func(MMC, mmc, 1) + func(MMC, mmc, 1) \ + func(MMC, mmc, 2) #else #define BOOT_TARGET_MMC(func) #endif
[PATCH] configs: sama5d2 boards: add DM and GPIO commands
From: Mihai Sain Add dm command for driver model low level access and gpio command for query and control gpio pins. Signed-off-by: Mihai Sain --- configs/sama5d27_som1_ek_mmc1_defconfig| 2 ++ configs/sama5d27_som1_ek_mmc_defconfig | 2 ++ configs/sama5d27_som1_ek_qspiflash_defconfig | 2 ++ configs/sama5d27_wlsom1_ek_mmc_defconfig | 2 ++ configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 2 ++ configs/sama5d2_icp_mmc_defconfig | 2 ++ configs/sama5d2_ptc_ek_mmc_defconfig | 2 ++ configs/sama5d2_ptc_ek_nandflash_defconfig | 2 ++ configs/sama5d2_xplained_emmc_defconfig| 2 ++ configs/sama5d2_xplained_mmc_defconfig | 2 ++ configs/sama5d2_xplained_qspiflash_defconfig | 2 ++ configs/sama5d2_xplained_spiflash_defconfig| 2 ++ 12 files changed, 24 insertions(+) diff --git a/configs/sama5d27_som1_ek_mmc1_defconfig b/configs/sama5d27_som1_ek_mmc1_defconfig index 023758c634..1a405b500e 100644 --- a/configs/sama5d27_som1_ek_mmc1_defconfig +++ b/configs/sama5d27_som1_ek_mmc1_defconfig @@ -32,6 +32,8 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk1p2 rw rootwai CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d27_som1_ek_mmc_defconfig b/configs/sama5d27_som1_ek_mmc_defconfig index 70ecec3481..52be7e105d 100644 --- a/configs/sama5d27_som1_ek_mmc_defconfig +++ b/configs/sama5d27_som1_ek_mmc_defconfig @@ -33,6 +33,8 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwai CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d27_som1_ek_qspiflash_defconfig b/configs/sama5d27_som1_ek_qspiflash_defconfig index 95d3186c5c..3ca9deacaf 100644 --- a/configs/sama5d27_som1_ek_qspiflash_defconfig +++ b/configs/sama5d27_som1_ek_qspiflash_defconfig @@ -33,6 +33,8 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwai CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d27_wlsom1_ek_mmc_defconfig b/configs/sama5d27_wlsom1_ek_mmc_defconfig index 9dde22f313..ef756a78c0 100644 --- a/configs/sama5d27_wlsom1_ek_mmc_defconfig +++ b/configs/sama5d27_wlsom1_ek_mmc_defconfig @@ -35,6 +35,8 @@ CONFIG_SPL_DISPLAY_PRINT=y CONFIG_SPL_AT91_MCK_BYPASS=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig index 5ee5a5aefa..1f4192aa98 100644 --- a/configs/sama5d27_wlsom1_ek_qspiflash_defconfig +++ b/configs/sama5d27_wlsom1_ek_qspiflash_defconfig @@ -38,6 +38,8 @@ CONFIG_SPL_SPI_LOAD=y CONFIG_SPL_AT91_MCK_BYPASS=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d2_icp_mmc_defconfig b/configs/sama5d2_icp_mmc_defconfig index f4f4134dc9..70ced6dc88 100644 --- a/configs/sama5d2_icp_mmc_defconfig +++ b/configs/sama5d2_icp_mmc_defconfig @@ -35,6 +35,8 @@ CONFIG_SPL_RAM_DEVICE=y CONFIG_SPL_AT91_MCK_BYPASS=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_IMI is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d2_ptc_ek_mmc_defconfig b/configs/sama5d2_ptc_ek_mmc_defconfig index 978b4b2cd1..a84c888cf1 100644 --- a/configs/sama5d2_ptc_ek_mmc_defconfig +++ b/configs/sama5d2_ptc_ek_mmc_defconfig @@ -24,6 +24,8 @@ CONFIG_CONSOLE_MUX=y CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d2_ptc_ek_nandflash_defconfig b/configs/sama5d2_ptc_ek_nandflash_defconfig index 9017e9d7c3..aab409851d 100644 --- a/configs/sama5d2_ptc_ek_nandflash_defconfig +++ b/configs/sama5d2_ptc_ek_nandflash_defconfig @@ -24,6 +24,8 @@ CONFIG_CONSOLE_MUX=y CONFIG_MISC_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y +CONFIG_CMD_DM=y +CONFIG_CMD_GPIO=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_I2C=y # CONFIG_CMD_LOADS is not set diff --git a/configs/sama5d2_xplained_emmc_defconfig b/configs/sama5d2_xplained_emmc_defconfig index f1ecf72d89..2b535b1f3d 100644 --- a/configs/sama5d2_xplained_emmc_defconfig +++ b/configs/sama5d2_xplained_emmc_defconfig @@ -31,6 +31,8 @@ CONFIG_BOOTARGS="console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rw rootwai # CONFIG_DISPLAY_BOARDINFO is not set
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, Oct 26, 2021 at 9:52 AM Marek Behún wrote:
>
> On Tue, 26 Oct 2021 09:40:44 -0700
> Roman Bacik wrote:
>
> > On Tue, Oct 26, 2021 at 9:02 AM Roman Bacik
> > wrote:
> > >
> > > On Tue, Oct 26, 2021 at 8:55 AM Marek Behún wrote:
> > > >
> > > > On Tue, 26 Oct 2021 08:14:28 -0700
> > > > Roman Bacik wrote:
> > > >
> > > > > Hi Marek,
> > > > >
> > > > > We do not want this driver to be automatically probed. It is not
> > > > > needed
> > > > > all the time and also slows down the boot time. We have stripped down
> > > > > everything else to bare minimum.
> > > > > Thanks,
> > > > >
> > > > > Roman
> > > >
> > > > Hi Roman,
> > > >
> > > > OK, that is reasonable, but not reasonable enough to introduce a new
> > > > vendor specific command.
> > > >
> > > > Still NAK.
> > > >
> > > > So you have the bnxt_drv_probe method defined in the driver, but you
> > > > don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> > > > you call this method when "brcm probe" command is called.
> > > >
> > > > I think this introduction of another vendor specific command is wrong.
> > > >
> > > > If probing takes too much time and should be done only when the device
> > > > is needed, there are 2 things you could do:
> > > >
> > > > - you can create new driver flag saying that the device should be
> > > > probeb only when needed, wire necessary code and add this flag to your
> > > > driver (this could get very complicated, though)
> > > > - you can do minimum stuff in probe method, and move the stuff that
> > > > takes long time into bnxt_start(), which is called only when network
> > > > via this ethernet controller is requested for by U-Boot commands.
> > >
> > > So renaming bnxt probe/remove to bnxt start/stop will do, right?
> > >
> > > >
> > > > Also, you're still doing
> > > >
> > > > + if (env_get("ethaddr"))
> > > > + secondary = 1;
> > >
> > > Why can't we access the env variable from our "bnxt start" method? Is
> > > there a blacklist of env variables one must not access from a driver?
> >
> > Marek,
> >
> > Sometimes we can have two ethernet devices. One is 10/100/1000M rgmii and
> > another is chip internal 10/100G bnxt. If rgmii is there as eth0, we
> > are incrementing eth number for bnxt:
> >
> > if (env_get("ethaddr"))
> > secondary = 1;
> > eth_env_get_enetaddr_by_index("eth",bp->cardnum+secondary,bp->mac_set);
> >
> > This way the driver can find that rmii has already taken eth0 so it
> > will use eth1 instead. Do you have a suggestion to work around this?
> > Thanks,
>
> I just replied to your first reply:
>
> Every ethernet controller should use a specific ethNaddr, where
> N = dev_seq(dev) of that controller (and if N=0, it is omitted
> entirely).
>
> So no magical things such as
> bp->cardnum+secondary
>
> instead you use dev_seq(dev), which gives you the correct number, i.e.
> for N-th UCLASS_ETH device bound it return the number N.
>
> Marek
Marek,
Thank you very much for your suggestion, we will try it.
Roman
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, 26 Oct 2021 09:40:44 -0700
Roman Bacik wrote:
> On Tue, Oct 26, 2021 at 9:02 AM Roman Bacik wrote:
> >
> > On Tue, Oct 26, 2021 at 8:55 AM Marek Behún wrote:
> > >
> > > On Tue, 26 Oct 2021 08:14:28 -0700
> > > Roman Bacik wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > We do not want this driver to be automatically probed. It is not needed
> > > > all the time and also slows down the boot time. We have stripped down
> > > > everything else to bare minimum.
> > > > Thanks,
> > > >
> > > > Roman
> > >
> > > Hi Roman,
> > >
> > > OK, that is reasonable, but not reasonable enough to introduce a new
> > > vendor specific command.
> > >
> > > Still NAK.
> > >
> > > So you have the bnxt_drv_probe method defined in the driver, but you
> > > don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> > > you call this method when "brcm probe" command is called.
> > >
> > > I think this introduction of another vendor specific command is wrong.
> > >
> > > If probing takes too much time and should be done only when the device
> > > is needed, there are 2 things you could do:
> > >
> > > - you can create new driver flag saying that the device should be
> > > probeb only when needed, wire necessary code and add this flag to your
> > > driver (this could get very complicated, though)
> > > - you can do minimum stuff in probe method, and move the stuff that
> > > takes long time into bnxt_start(), which is called only when network
> > > via this ethernet controller is requested for by U-Boot commands.
> >
> > So renaming bnxt probe/remove to bnxt start/stop will do, right?
> >
> > >
> > > Also, you're still doing
> > >
> > > + if (env_get("ethaddr"))
> > > + secondary = 1;
> >
> > Why can't we access the env variable from our "bnxt start" method? Is
> > there a blacklist of env variables one must not access from a driver?
>
> Marek,
>
> Sometimes we can have two ethernet devices. One is 10/100/1000M rgmii and
> another is chip internal 10/100G bnxt. If rgmii is there as eth0, we
> are incrementing eth number for bnxt:
>
> if (env_get("ethaddr"))
> secondary = 1;
> eth_env_get_enetaddr_by_index("eth",bp->cardnum+secondary,bp->mac_set);
>
> This way the driver can find that rmii has already taken eth0 so it
> will use eth1 instead. Do you have a suggestion to work around this?
> Thanks,
I just replied to your first reply:
Every ethernet controller should use a specific ethNaddr, where
N = dev_seq(dev) of that controller (and if N=0, it is omitted
entirely).
So no magical things such as
bp->cardnum+secondary
instead you use dev_seq(dev), which gives you the correct number, i.e.
for N-th UCLASS_ETH device bound it return the number N.
Marek
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, 26 Oct 2021 09:02:54 -0700
Roman Bacik wrote:
> On Tue, Oct 26, 2021 at 8:55 AM Marek Behún wrote:
> >
> > On Tue, 26 Oct 2021 08:14:28 -0700
> > Roman Bacik wrote:
> >
> > > Hi Marek,
> > >
> > > We do not want this driver to be automatically probed. It is not needed
> > > all the time and also slows down the boot time. We have stripped down
> > > everything else to bare minimum.
> > > Thanks,
> > >
> > > Roman
> >
> > Hi Roman,
> >
> > OK, that is reasonable, but not reasonable enough to introduce a new
> > vendor specific command.
> >
> > Still NAK.
> >
> > So you have the bnxt_drv_probe method defined in the driver, but you
> > don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> > you call this method when "brcm probe" command is called.
> >
> > I think this introduction of another vendor specific command is wrong.
> >
> > If probing takes too much time and should be done only when the device
> > is needed, there are 2 things you could do:
> >
> > - you can create new driver flag saying that the device should be
> > probeb only when needed, wire necessary code and add this flag to your
> > driver (this could get very complicated, though)
> > - you can do minimum stuff in probe method, and move the stuff that
> > takes long time into bnxt_start(), which is called only when network
> > via this ethernet controller is requested for by U-Boot commands.
>
> So renaming bnxt probe/remove to bnxt start/stop will do, right?
No. The whole idea of adding the new "bnxt" command is wrong, because
the command is *vendor specific*. The ethernet controller should work
out of the box with standard U-Boot commands, i.e. it if I use the
dhcp
command, it should work, without needing to call the "bnxt" command.
> >
> > Also, you're still doing
> >
> > + if (env_get("ethaddr"))
> > + secondary = 1;
>
> Why can't we access the env variable from our "bnxt start" method? Is
> there a blacklist of env variables one must not access from a driver?
Because the "ethaddr" variable is the MAC address of the 0-th ethernet
controller on the board, which does not have anything to do with yout
broadcom netXtreme controller, unless your broadcom netXtreme
controller is the zero-th ethernet controller on the board.
For example if I connect you controller to the PCIe slot on Turris
Omnia, where there are 3 ethernet controllers already, and their MAC
addresses are stored in
ethaddr
eth1addr
eth2addr
the MAC address of the netXtreme controller would be stored in variable
eth3addr
So in your UCLASS_ETH driver, you should only look at
dev_seq(dev)
ethaddr, by using
eth_env_get/set_enetaddr_by_index("eth", dev_seq(dev), ...);
Marek
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, Oct 26, 2021 at 9:02 AM Roman Bacik wrote:
>
> On Tue, Oct 26, 2021 at 8:55 AM Marek Behún wrote:
> >
> > On Tue, 26 Oct 2021 08:14:28 -0700
> > Roman Bacik wrote:
> >
> > > Hi Marek,
> > >
> > > We do not want this driver to be automatically probed. It is not needed
> > > all the time and also slows down the boot time. We have stripped down
> > > everything else to bare minimum.
> > > Thanks,
> > >
> > > Roman
> >
> > Hi Roman,
> >
> > OK, that is reasonable, but not reasonable enough to introduce a new
> > vendor specific command.
> >
> > Still NAK.
> >
> > So you have the bnxt_drv_probe method defined in the driver, but you
> > don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> > you call this method when "brcm probe" command is called.
> >
> > I think this introduction of another vendor specific command is wrong.
> >
> > If probing takes too much time and should be done only when the device
> > is needed, there are 2 things you could do:
> >
> > - you can create new driver flag saying that the device should be
> > probeb only when needed, wire necessary code and add this flag to your
> > driver (this could get very complicated, though)
> > - you can do minimum stuff in probe method, and move the stuff that
> > takes long time into bnxt_start(), which is called only when network
> > via this ethernet controller is requested for by U-Boot commands.
>
> So renaming bnxt probe/remove to bnxt start/stop will do, right?
>
> >
> > Also, you're still doing
> >
> > + if (env_get("ethaddr"))
> > + secondary = 1;
>
> Why can't we access the env variable from our "bnxt start" method? Is
> there a blacklist of env variables one must not access from a driver?
Marek,
Sometimes we can have two ethernet devices. One is 10/100/1000M rgmii and
another is chip internal 10/100G bnxt. If rgmii is there as eth0, we
are incrementing eth number for bnxt:
if (env_get("ethaddr"))
secondary = 1;
eth_env_get_enetaddr_by_index("eth",bp->cardnum+secondary,bp->mac_set);
This way the driver can find that rmii has already taken eth0 so it
will use eth1 instead. Do you have a suggestion to work around this?
Thanks,
Roman
>
>
> >
> > in your driver, which is completely against DM.
> >
> > Marek
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, Oct 26, 2021 at 8:55 AM Marek Behún wrote:
>
> On Tue, 26 Oct 2021 08:14:28 -0700
> Roman Bacik wrote:
>
> > Hi Marek,
> >
> > We do not want this driver to be automatically probed. It is not needed
> > all the time and also slows down the boot time. We have stripped down
> > everything else to bare minimum.
> > Thanks,
> >
> > Roman
>
> Hi Roman,
>
> OK, that is reasonable, but not reasonable enough to introduce a new
> vendor specific command.
>
> Still NAK.
>
> So you have the bnxt_drv_probe method defined in the driver, but you
> don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
> you call this method when "brcm probe" command is called.
>
> I think this introduction of another vendor specific command is wrong.
>
> If probing takes too much time and should be done only when the device
> is needed, there are 2 things you could do:
>
> - you can create new driver flag saying that the device should be
> probeb only when needed, wire necessary code and add this flag to your
> driver (this could get very complicated, though)
> - you can do minimum stuff in probe method, and move the stuff that
> takes long time into bnxt_start(), which is called only when network
> via this ethernet controller is requested for by U-Boot commands.
So renaming bnxt probe/remove to bnxt start/stop will do, right?
>
> Also, you're still doing
>
> + if (env_get("ethaddr"))
> + secondary = 1;
Why can't we access the env variable from our "bnxt start" method? Is
there a blacklist of env variables one must not access from a driver?
>
> in your driver, which is completely against DM.
>
> Marek
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 08:31, François Ozog > wrote: > > > > Hi Simon, > > > > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> > >> At present some of the ideas and techniques behind devicetree in U-Boot > >> are assumed, implied or unsaid. Add some documentation to cover how > >> devicetree is build, how it can be modified and the rules about using > >> the various CONFIG_OF_... options. > >> > >> Signed-off-by: Simon Glass > >> Reviewed-by: Marcel Ziswiler > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> > >> I have not included the text suggested by François. While I agree that > >> it would be useful to have an introduction in this space, I do not agree > >> that we should have two devicetrees or that U-Boot should not have its > own > >> things in the devicetree, so it is not clear to me what we should > actually > >> write. > >> > >> The 'Devicetree Control in U-Boot' docs were recently merged and these > >> provide some base info, for now. > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> doc/develop/devicetree/dt_update.rst | 556 +++ > >> doc/develop/devicetree/index.rst | 1 + > >> 2 files changed, 557 insertions(+) > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > >> new file mode 100644 > >> index 000..3d4902e3592 > >> --- /dev/null > >> +++ b/doc/develop/devicetree/dt_update.rst > >> @@ -0,0 +1,556 @@ > >> +.. SPDX-License-Identifier: GPL-2.0+ > >> + > >> +Updating the devicetree > >> +=== > >> + > >> +U-Boot uses devicetree for runtime configuration and storing required > blobs or > >> +any other information it needs to operate. This is called the 'control' > >> +devicetree since it controls U-Boot. It is possible to update the > control > >> +devicetree separately from actually building U-Boot. This provides a > good degree > >> +of control and flexibility for firmware that uses U-Boot in > conjunction with > >> +other project. > >> + > >> +There are many reasons why it is useful to modify the devicetree after > building > >> +it: > >> + > >> +- Configuration can be changed, e.g. which UART to use > >> +- A serial number can be added > >> +- Public keys can be added to allow image verification > >> +- Console output can be changed (e.g. to select serial or vidconsole) > >> + > >> +This section describes how to work with devicetree to accomplish your > goals. > >> + > >> +See also :doc:`../devicetree/control` for a basic summary of the > available > >> +features. > >> + > >> + > >> +Devicetree source > >> +- > >> + > >> +Every board in U-Boot must include a devicetree sufficient to build > and boot > >> +that board on suitable hardware (or emulation). This is specified > using the > >> +`CONFIG DEFAULT_DEVICE_TREE` option. > >> + > >> + > >> +Current situation (October 2021) > >> +~~ > >> + > >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to > be empty, > >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > >> +amount of confusion and some wasted effort. This was not intended. > Support for > >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > >> + > >> +Some of the problems created are: > >> + > >> +- It is not obvious that the devicetree is
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Tue, 26 Oct 2021 08:14:28 -0700
Roman Bacik wrote:
> Hi Marek,
>
> We do not want this driver to be automatically probed. It is not needed
> all the time and also slows down the boot time. We have stripped down
> everything else to bare minimum.
> Thanks,
>
> Roman
Hi Roman,
OK, that is reasonable, but not reasonable enough to introduce a new
vendor specific command.
Still NAK.
So you have the bnxt_drv_probe method defined in the driver, but you
don't set a pointer to it into the U_BOOT_DRIVER structure, and instead
you call this method when "brcm probe" command is called.
I think this introduction of another vendor specific command is wrong.
If probing takes too much time and should be done only when the device
is needed, there are 2 things you could do:
- you can create new driver flag saying that the device should be
probeb only when needed, wire necessary code and add this flag to your
driver (this could get very complicated, though)
- you can do minimum stuff in probe method, and move the stuff that
takes long time into bnxt_start(), which is called only when network
via this ethernet controller is requested for by U-Boot commands.
Also, you're still doing
+ if (env_get("ethaddr"))
+ secondary = 1;
in your driver, which is completely against DM.
Marek
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 17:34, Marek Behún wrote: On Tue, 26 Oct 2021 17:25:10 +0200 Stefan Roese wrote: On 26.10.21 17:20, Marek Behún wrote: On Tue, 26 Oct 2021 17:13:05 +0200 Stefan Roese wrote: Here is now just hangs forever. No output from main U-Boot proper at all. This happed every time, when the baudrate is changed, meaning a non 115200 -B is passed to kwboot. I checked with 115201 and here no U-Boot proper output is printed as well. If there are timeout errors related to "Waiting 1s for baudrate change magic" then increasing 1s (1000 ms value) to e.g. 10s could help. I changed the timeout to 10s without any change. It did not help. At what address is the image being sent to? Please send dumpimage output for the kwb image. [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/dumpimage -l u-boot-spl.kwb Image Type: MVEBU Boot from spi Image Image version:1 BIN Hdr Size: 89196 Bytes = 87.11 KiB = 0.09 MiB Data Size:548604 Bytes = 535.75 KiB = 0.52 MiB Load Address: 0080 Entry Point: 0080 I think the baudrate changing code is not the problem, because it executes correctly in the binhdr when increasing the baudrate. Otherwise Changing baudrate to 230400 Bd wouldn't be printed. Okay. Still it's unclear, why I don't see any speedup in the download time here. Stefan, did it previously work on this board? No... I mean at the time the patches were first merged into u-boot-marvell Did the problem start occuring only now, when the code is merged in u-boot master? ... Meaning, it still works when the baudrate is not changed at all. I never tried with a baudrate != 115200 until your work in this area here. Is it possible to connect JTAG to the board? It is. But this would be a bit difficult for me, to dig all these old tools out and find the correct configuration of the BDI. Yes, lets keep that as last resort. Agreed. Thanks, Stefan
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tue, 26 Oct 2021 17:25:10 +0200 Stefan Roese wrote: > On 26.10.21 17:20, Marek Behún wrote: > > On Tue, 26 Oct 2021 17:13:05 +0200 > > Stefan Roese wrote: > > > >> Here is now just hangs forever. No output from main U-Boot proper at > >> all. This happed every time, when the baudrate is changed, meaning a > >> non 115200 -B is passed to kwboot. I checked with 115201 and here no > >> U-Boot proper output is printed as well. > >> > >>> If there are timeout errors related to "Waiting 1s for baudrate change > >>> magic" then increasing 1s (1000 ms value) to e.g. 10s could help. > >> > >> I changed the timeout to 10s without any change. It did not help. > > > > At what address is the image being sent to? Please send dumpimage > > output for the kwb image. > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/dumpimage -l > u-boot-spl.kwb > Image Type: MVEBU Boot from spi Image > Image version:1 > BIN Hdr Size: 89196 Bytes = 87.11 KiB = 0.09 MiB > Data Size:548604 Bytes = 535.75 KiB = 0.52 MiB > Load Address: 0080 > Entry Point: 0080 I think the baudrate changing code is not the problem, because it executes correctly in the binhdr when increasing the baudrate. Otherwise Changing baudrate to 230400 Bd wouldn't be printed. Stefan, did it previously work on this board? I mean at the time the patches were first merged into u-boot-marvell Did the problem start occuring only now, when the code is merged in u-boot master? > > Is it possible to connect JTAG to the board? > > It is. But this would be a bit difficult for me, to dig all these old > tools out and find the correct configuration of the BDI. Yes, lets keep that as last resort. Marek
Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Hi Ilias,
On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> As I said here [1], this is moving on an entirely different direction I had
> in mind. I'd much prefer starting the discussions for a solution that
> allows us to scale.
I am missing the point here. Is there something in the plans that I
don't know about?
> FWIW I think the current code is still not clean for my taste. Commit
> 3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE")
> allowed this function to be used regardless of the config options. IMHO we
> should have 2 clear options:
> - U-Boot provides the DTB
Supported with: OF_SEPARATE
> - It's somehow passed over to U-Boot
Supported with: OF_SEPARATE + OF_BOARD
I actually hit this problem with my qemu testing, in that it is
actually not possible to use U-Boot's devicetree without hacking the
code. We need to be able to select this feature explicitly, or turn it
off, at least for development.
Regards,
Simon
>
> On Mon, Oct 25, 2021 at 06:23:44PM -0600, Simon Glass wrote:
> > At present this override function is called even when OF_BOARD Is not
> > enabled. This makes it impossible to disable this feature and in fact
> > makes the OF_BOARD option useless.
> >
> > Reinstate its intended purpose, so that it is possible to switch between
> > the appended devicetree and one provided by the board's custom function.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > Changes in v5:
> > - Add new patches to clean up fdtdec_setup() and surrounds
> >
> > include/fdtdec.h | 7 +--
> > lib/fdtdec.c | 17 +++--
> > 2 files changed, 16 insertions(+), 8 deletions(-)
> >
> > diff --git a/include/fdtdec.h b/include/fdtdec.h
> > index 386f6611294..b2faa84008e 100644
> > --- a/include/fdtdec.h
> > +++ b/include/fdtdec.h
> > @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
> >
> > /**
> > * Board-specific FDT initialization. Returns the address to a device tree
> > blob.
> > - * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is
> > defined
> > - * and the board implements it.
> > + * Called when CONFIG_OF_BOARD is defined.
> > + *
> > + * The existing devicetree is available at gd->fdt_blob
> > + *
> > + * @returns new devicetree blob pointer
> > */
> > void *board_fdt_blob_setup(void);
> >
> > diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> > index 067c27d0aa3..da36dffec62 100644
> > --- a/lib/fdtdec.c
> > +++ b/lib/fdtdec.c
> > @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong
> > sz_src, void **dstp)
> > return 0;
> > }
> >
> > -/*
> > - * For CONFIG_OF_SEPARATE, the board may optionally implement this to
> > - * provide and/or fixup the fdt.
> > +/**
> > + * fdt_find_separate() - Find a devicetree at the end of the image
> > + *
> > + * @return pointer to FDT blob
> > */
> > -__weak void *board_fdt_blob_setup(void)
> > +static void *fdt_find_separate(void)
> > {
> > void *fdt_blob = NULL;
> > #ifdef CONFIG_SPL_BUILD
> > @@ -1623,11 +1624,15 @@ int fdtdec_setup(void)
> > int ret;
> >
> > /* The devicetree is typically appended to U-Boot */
> > - if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD))
> > - gd->fdt_blob = board_fdt_blob_setup();
> > + if (IS_ENABLED(CONFIG_OF_SEPARATE))
> > + gd->fdt_blob = fdt_find_separate();
> > else /* embed dtb in ELF file for testing / development */
> > gd->fdt_blob = dtb_dt_embedded();
> >
> > + /* Allow the board to override the fdt address. */
> > + if (IS_ENABLED(CONFIG_OF_BOARD))
> > + gd->fdt_blob = board_fdt_blob_setup();
> > +
> > if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
> > /* Allow the early environment to override the fdt address */
> > gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
> > --
> > 2.33.0.1079.g6e70778dc9-goog
> >
>
> [1] https://lore.kernel.org/u-boot/yxektkel73nm0...@apalos.home/
>
> Regards
> /Ilias
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi François, On Tue, 26 Oct 2021 at 08:31, François Ozog wrote: > > Hi Simon, > > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: >> >> At present some of the ideas and techniques behind devicetree in U-Boot >> are assumed, implied or unsaid. Add some documentation to cover how >> devicetree is build, how it can be modified and the rules about using >> the various CONFIG_OF_... options. >> >> Signed-off-by: Simon Glass >> Reviewed-by: Marcel Ziswiler >> --- >> This patch attracted quite a bit of discussion here: >> >> https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ >> >> I have not included the text suggested by François. While I agree that >> it would be useful to have an introduction in this space, I do not agree >> that we should have two devicetrees or that U-Boot should not have its own >> things in the devicetree, so it is not clear to me what we should actually >> write. >> >> The 'Devicetree Control in U-Boot' docs were recently merged and these >> provide some base info, for now. >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetrees?' >> >> doc/develop/devicetree/dt_update.rst | 556 +++ >> doc/develop/devicetree/index.rst | 1 + >> 2 files changed, 557 insertions(+) >> create mode 100644 doc/develop/devicetree/dt_update.rst >> >> diff --git a/doc/develop/devicetree/dt_update.rst >> b/doc/develop/devicetree/dt_update.rst >> new file mode 100644 >> index 000..3d4902e3592 >> --- /dev/null >> +++ b/doc/develop/devicetree/dt_update.rst >> @@ -0,0 +1,556 @@ >> +.. SPDX-License-Identifier: GPL-2.0+ >> + >> +Updating the devicetree >> +=== >> + >> +U-Boot uses devicetree for runtime configuration and storing required blobs >> or >> +any other information it needs to operate. This is called the 'control' >> +devicetree since it controls U-Boot. It is possible to update the control >> +devicetree separately from actually building U-Boot. This provides a good >> degree >> +of control and flexibility for firmware that uses U-Boot in conjunction with >> +other project. >> + >> +There are many reasons why it is useful to modify the devicetree after >> building >> +it: >> + >> +- Configuration can be changed, e.g. which UART to use >> +- A serial number can be added >> +- Public keys can be added to allow image verification >> +- Console output can be changed (e.g. to select serial or vidconsole) >> + >> +This section describes how to work with devicetree to accomplish your goals. >> + >> +See also :doc:`../devicetree/control` for a basic summary of the available >> +features. >> + >> + >> +Devicetree source >> +- >> + >> +Every board in U-Boot must include a devicetree sufficient to build and boot >> +that board on suitable hardware (or emulation). This is specified using the >> +`CONFIG DEFAULT_DEVICE_TREE` option. >> + >> + >> +Current situation (October 2021) >> +~~ >> + >> +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be >> empty, >> +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an >> enormous >> +amount of confusion and some wasted effort. This was not intended. Support >> for >> +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. >> + >> +Some of the problems created are: >> + >> +- It is not obvious that the devicetree is coming from another project >> + >> +- There is no way to see even a sample devicetree for these platform in >> U-Boot, >> + so it is hard to know what is going on, e.g. which devices are typically >> + present >> + >> +- The other project may not provide a way to support U-Boot's
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Ilias, On Tue, 26 Oct 2021 at 08:06, Ilias Apalodimas wrote: > > Hi Simon, > > > + > > [...] > > > +This is why `CONFIG_OF_SEPARATE` should always be used when building > > U-Boot. > > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot > > ELF > > +image as rodata, meaning that it is hard to find it and it cannot increase > > in > > +size. > > + > > +When modifying the devicetree, the different cases to consider are as > > follows: > > + > > +- CONFIG_OF_SEPARATE > > +This is easy, described above. Just change, replace or rebuild the > > +devicetree so it suits your needs, then rerun binman or redo the `cat` > > +operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > > + > > +- CONFIG_OF_EMBED > > +This is tricky, since the devicetree cannot easily be located. If the > > EFL > > +file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can > > be > > +examined to find it. While it is possible to contract the file, it is > > not > > +possible to expand the file since that would involve re-linking > > + > > +- CONFIG_OF_BOARD > > +This is a board-specific situation, so needs to be considered on a > > +case-by-case base. The devicetree must be modified so that the correct > > +one is provided to U-Boot. How this is done depends entirely on the > > +implementation of this option for the board. It might require > > injecting the > > +changes into a different project somehow using tooling available > > there, or > > +it might involve merging an overlay file at runtime to obtain the > > desired > > +result. > > I thought this document was trying to describe the current situation in > U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have > here. Can you be more specific? What is the difference here? Also see the doc update later in the series, after OF_BOARD becomes a bool option. Regards, SImon
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 17:20, Marek Behún wrote: On Tue, 26 Oct 2021 17:13:05 +0200 Stefan Roese wrote: Here is now just hangs forever. No output from main U-Boot proper at all. This happed every time, when the baudrate is changed, meaning a non 115200 -B is passed to kwboot. I checked with 115201 and here no U-Boot proper output is printed as well. If there are timeout errors related to "Waiting 1s for baudrate change magic" then increasing 1s (1000 ms value) to e.g. 10s could help. I changed the timeout to 10s without any change. It did not help. At what address is the image being sent to? Please send dumpimage output for the kwb image. [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/dumpimage -l u-boot-spl.kwb Image Type: MVEBU Boot from spi Image Image version:1 BIN Hdr Size: 89196 Bytes = 87.11 KiB = 0.09 MiB Data Size:548604 Bytes = 535.75 KiB = 0.52 MiB Load Address: 0080 Entry Point: 0080 Is it possible to connect JTAG to the board? It is. But this would be a bit difficult for me, to dig all these old tools out and find the correct configuration of the BDI. Thanks, Stefan
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tue, 26 Oct 2021 17:13:05 +0200 Stefan Roese wrote: > Here is now just hangs forever. No output from main U-Boot proper at > all. This happed every time, when the baudrate is changed, meaning a > non 115200 -B is passed to kwboot. I checked with 115201 and here no > U-Boot proper output is printed as well. > > > If there are timeout errors related to "Waiting 1s for baudrate change > > magic" then increasing 1s (1000 ms value) to e.g. 10s could help. > > I changed the timeout to 10s without any change. It did not help. At what address is the image being sent to? Please send dumpimage output for the kwb image. Is it possible to connect JTAG to the board? Marek
RE: [PATCH v3 2/2] cmd: brcm: netXtreme commands
> -Original Message- > From: Marek Behún > Sent: Tuesday, October 26, 2021 6:18 AM > To: Roman Bacik > Cc: U-Boot Mailing List ; Bharat Gooty > ; Aswath Govindraju govindr...@ti.com>; Bin Meng ; Franck > LENORMAND ; Heinrich Schuchardt > ; Kory Maincent ; > Michal Simek ; Patrick Delaunay > ; Peng Fan ; Priyanka > Jain ; Rayagonda Kokatanur > ; Sean Anderson > ; Simon Glass > Subject: Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands > > On Mon, 25 Oct 2021 16:44:44 -0700 > Roman Bacik wrote: > > > From: Bharat Gooty > > > > Following netXtreme commands are supported: > > probe, remove. > > > > Signed-off-by: Bharat Gooty > > > > Signed-off-by: Roman Bacik > > Hi Roman, > > why do you need to have custom command for probing / removing the > driver? > > U-Boot PCI code should probe the driver automatically upon recognizing > PCI vendor / device ID. > > Even if not, adding custom command for such a thing isn't nice, when we > have the `dm` command for communicating with driver model. > > Marek Hi Marek, We do not want this driver to be automatically probed. It is not needed all the time and also slows down the boot time. We have stripped down everything else to bare minimum. Thanks, Roman -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 16:48, Pali Rohár wrote:
On Tuesday 26 October 2021 16:21:02 Stefan Roese wrote:
On 26.10.21 14:40, Pali Rohár wrote:
On Tuesday 26 October 2021 13:09:42 Stefan Roese wrote:
On 26.10.21 11:06, Pali Rohár wrote:
Now I found logical error in kwboot code which handles retransmission of
the last header packet. State of "baudrate change" is cleared on every
retransmission. Please apply following diff, so state variables are
initialized only once.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index d38ee0065177..835ccc8c113a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -859,11 +859,6 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
uint64_t recv_until = _now() + timeout;
int rc;
- if (non_xm_print)
- *non_xm_print = 0;
- if (baud_changed)
- *baud_changed = 0;
-
while (1) {
rc = kwboot_tty_recv(fd, c, 1, timeout);
if (rc) {
@@ -929,6 +924,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
char c;
*done_print = 0;
+ non_xm_print = 0;
+ baud_changed = 0;
retries = 0;
do {
This definitely helps (a bit). Now I get this:
Perfect! So this fixes issue with retransmission of the last header
packet.
But there is still issue with starting main U-Boot binary.
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b
u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
Injecting code for changing baudrate back
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (90112 bytes)...
0 %
[..]
10 %
[..]
20 %
[..]
29 %
[..]
39 %
[..]
49 %
[..]
59 %
[..]
69 %
[..]
79 %
[..]
89 %
[..]
99 % [ ]
Done
U-Boot SPL 2021.10-00908-gc129aa2f173a-dirty (Oct 26 2021 - 12:48:11 +0200)
High speed PHY - Version: 2.1.5 (COM-PHY-V20)
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.4
DDR3 Training Sequence - Ended Successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0x0aa0)...
Changing baudrate to 230400 Bd
Sending boot image data (549892 bytes)...
0 %
[..]
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
BTW: The baudrate change does not seem to work or have any effect on
the image download speed. Comparing 230400 and 921600 baud speeds, I can
spot no real time difference here:
230400 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 230400
-b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
[2]+ Doneemacs tools/kwboot.c
real1m27,279s
user0m2,313s
sys 0m0,337s
921600 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 921600
-b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 921600 Bd
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
real1m27,839s
user0m0,224s
sys 0m0,194s
Any idea why this is the case?
UARTs at both sides must be configured to 921600 speed, otherwise they
would not be able to communicate.
I'm also surpised here.
What is happening here? I do not know. But as Marek told me that
observed same issue and replacing USB-UART cable by another decreased
transfer time. So I think that issue is somewhere in USB-UART
transmitter. My guess is that USB-UART transmitter send at 921600 speed:
start bit, 8 bits of data, stop bit and then lng idle pause (logical
one). After that sends another 10 bits.
Maybe kernel is not filling
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tuesday 26 October 2021 16:21:02 Stefan Roese wrote:
> On 26.10.21 14:40, Pali Rohár wrote:
> > On Tuesday 26 October 2021 13:09:42 Stefan Roese wrote:
> > > On 26.10.21 11:06, Pali Rohár wrote:
> > >
> > >
> > >
> > > > Now I found logical error in kwboot code which handles retransmission of
> > > > the last header packet. State of "baudrate change" is cleared on every
> > > > retransmission. Please apply following diff, so state variables are
> > > > initialized only once.
> > > >
> > > > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > > > index d38ee0065177..835ccc8c113a 100644
> > > > --- a/tools/kwboot.c
> > > > +++ b/tools/kwboot.c
> > > > @@ -859,11 +859,6 @@ kwboot_xm_recv_reply(int fd, char *c, int
> > > > nak_on_non_xm,
> > > > uint64_t recv_until = _now() + timeout;
> > > > int rc;
> > > > - if (non_xm_print)
> > > > - *non_xm_print = 0;
> > > > - if (baud_changed)
> > > > - *baud_changed = 0;
> > > > -
> > > > while (1) {
> > > > rc = kwboot_tty_recv(fd, c, 1, timeout);
> > > > if (rc) {
> > > > @@ -929,6 +924,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block
> > > > *block, int allow_non_xm,
> > > > char c;
> > > > *done_print = 0;
> > > > + non_xm_print = 0;
> > > > + baud_changed = 0;
> > > > retries = 0;
> > > > do {
> > >
> > > This definitely helps (a bit). Now I get this:
> >
> > Perfect! So this fixes issue with retransmission of the last header
> > packet.
> >
> > But there is still issue with starting main U-Boot binary.
> >
> > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b
> > > u-boot-spl.kwb -t
> > > /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> > > Patching image boot signature to UART
> > > Injecting binary header code for changing baudrate to 230400 Bd
> > > Injecting code for changing baudrate back
> > > Sending boot message. Please reboot the target...|
> > > Waiting 2s and flushing tty
> > > Sending boot image header (90112 bytes)...
> > >0 %
> > > [..]
> > > 10 %
> > > [..]
> > > 20 %
> > > [..]
> > > 29 %
> > > [..]
> > > 39 %
> > > [..]
> > > 49 %
> > > [..]
> > > 59 %
> > > [..]
> > > 69 %
> > > [..]
> > > 79 %
> > > [..]
> > > 89 %
> > > [..]
> > > 99 % [ ]
> > > Done
> > >
> > > U-Boot SPL 2021.10-00908-gc129aa2f173a-dirty (Oct 26 2021 - 12:48:11
> > > +0200)
> > > High speed PHY - Version: 2.1.5 (COM-PHY-V20)
> > > High speed PHY - Ended Successfully
> > > DDR3 Training Sequence - Ver 5.7.4
> > > DDR3 Training Sequence - Ended Successfully
> > > Trying to boot from BOOTROM
> > > Returning to BootROM (return address 0x0aa0)...
> > >
> > > Changing baudrate to 230400 Bd
> > >
> > > Sending boot image data (549892 bytes)...
> > >0 %
> > > [..]
> > >
> > > ...
> > >
> > > 99 % [... ]
> > > Done
> > > Finishing transfer
> > > Waiting 1s for baudrate change magic
> > > xmodem: Connection timed out
> > >
> > >
> > > BTW: The baudrate change does not seem to work or have any effect on
> > > the image download speed. Comparing 230400 and 921600 baud speeds, I can
> > > spot no real time difference here:
> > >
> > > 230400 baud:
> > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B
> > > 230400
> > > -b u-boot-spl.kwb -t
> > > /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> > > Patching image boot signature to UART
> > > Injecting binary header code for changing baudrate to 230400 Bd
> > >
> > > ...
> > >
> > > 99 % [... ]
> > > Done
> > > Finishing transfer
> > > Waiting 1s for baudrate change magic
> > > xmodem: Connection timed out
> > > [2]+ Doneemacs tools/kwboot.c
> > >
> > > real1m27,279s
> > > user0m2,313s
> > > sys 0m0,337s
> > >
> > > 921600 baud:
> > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B
> > > 921600
> > > -b u-boot-spl.kwb -t
> > > /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> > > Patching image boot signature to UART
> > > Injecting binary header code for changing baudrate to 921600 Bd
> >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > Reviewed-by: Marcel Ziswiler > --- > This patch attracted quite a bit of discussion here: > > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > > I have not included the text suggested by François. While I agree that > it would be useful to have an introduction in this space, I do not agree > that we should have two devicetrees or that U-Boot should not have its own > things in the devicetree, so it is not clear to me what we should actually > write. > > The 'Devicetree Control in U-Boot' docs were recently merged and these > provide some base info, for now. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > doc/develop/devicetree/dt_update.rst | 556 +++ > doc/develop/devicetree/index.rst | 1 + > 2 files changed, 557 insertions(+) > create mode 100644 doc/develop/devicetree/dt_update.rst > > diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > new file mode 100644 > index 000..3d4902e3592 > --- /dev/null > +++ b/doc/develop/devicetree/dt_update.rst > @@ -0,0 +1,556 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +=== > + > +U-Boot uses devicetree for runtime configuration and storing required > blobs or > +any other information it needs to operate. This is called the 'control' > +devicetree since it controls U-Boot. It is possible to update the control > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction > with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your > goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +- > + > +Every board in U-Boot must include a devicetree sufficient to build and > boot > +that board on suitable hardware (or emulation). This is specified using > the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (October 2021) > +~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > +amount of confusion and some wasted effort. This was not intended. > Support for > +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > + > +Some of the problems created are: > + > +- It is not obvious that the devicetree is coming from another project > + > +- There is no way to see even a sample devicetree for these platform in > U-Boot, > + so it is hard to know what is going on, e.g. which devices are typically > + present > + > +- The other project may not provide a way to support U-Boot's > requirements for > + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > + was only discovered after weeks of discussion and confusion > + > +- For QEMU
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 14:40, Pali Rohár wrote:
On Tuesday 26 October 2021 13:09:42 Stefan Roese wrote:
On 26.10.21 11:06, Pali Rohár wrote:
Now I found logical error in kwboot code which handles retransmission of
the last header packet. State of "baudrate change" is cleared on every
retransmission. Please apply following diff, so state variables are
initialized only once.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index d38ee0065177..835ccc8c113a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -859,11 +859,6 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
uint64_t recv_until = _now() + timeout;
int rc;
- if (non_xm_print)
- *non_xm_print = 0;
- if (baud_changed)
- *baud_changed = 0;
-
while (1) {
rc = kwboot_tty_recv(fd, c, 1, timeout);
if (rc) {
@@ -929,6 +924,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
char c;
*done_print = 0;
+ non_xm_print = 0;
+ baud_changed = 0;
retries = 0;
do {
This definitely helps (a bit). Now I get this:
Perfect! So this fixes issue with retransmission of the last header
packet.
But there is still issue with starting main U-Boot binary.
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b
u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
Injecting code for changing baudrate back
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (90112 bytes)...
0 %
[..]
10 %
[..]
20 %
[..]
29 %
[..]
39 %
[..]
49 %
[..]
59 %
[..]
69 %
[..]
79 %
[..]
89 %
[..]
99 % [ ]
Done
U-Boot SPL 2021.10-00908-gc129aa2f173a-dirty (Oct 26 2021 - 12:48:11 +0200)
High speed PHY - Version: 2.1.5 (COM-PHY-V20)
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.4
DDR3 Training Sequence - Ended Successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0x0aa0)...
Changing baudrate to 230400 Bd
Sending boot image data (549892 bytes)...
0 %
[..]
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
BTW: The baudrate change does not seem to work or have any effect on
the image download speed. Comparing 230400 and 921600 baud speeds, I can
spot no real time difference here:
230400 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 230400
-b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
[2]+ Doneemacs tools/kwboot.c
real1m27,279s
user0m2,313s
sys 0m0,337s
921600 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 921600
-b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 921600 Bd
...
99 % [... ]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
real1m27,839s
user0m0,224s
sys 0m0,194s
Any idea why this is the case?
UARTs at both sides must be configured to 921600 speed, otherwise they
would not be able to communicate.
I'm also surpised here.
What is happening here? I do not know. But as Marek told me that
observed same issue and replacing USB-UART cable by another decreased
transfer time. So I think that issue is somewhere in USB-UART
transmitter. My guess is that USB-UART transmitter send at 921600 speed:
start bit, 8 bits of data, stop bit and then lng idle pause (logical
one). After that sends another 10 bits.
Maybe kernel is not filling next byte into USB-UART hw queue? Or USB-UART
cannot send more bytes faster and inserts those long idle pauses?
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, > + [...] > +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. > +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot > ELF > +image as rodata, meaning that it is hard to find it and it cannot increase in > +size. > + > +When modifying the devicetree, the different cases to consider are as > follows: > + > +- CONFIG_OF_SEPARATE > +This is easy, described above. Just change, replace or rebuild the > +devicetree so it suits your needs, then rerun binman or redo the `cat` > +operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` > + > +- CONFIG_OF_EMBED > +This is tricky, since the devicetree cannot easily be located. If the EFL > +file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be > +examined to find it. While it is possible to contract the file, it is not > +possible to expand the file since that would involve re-linking > + > +- CONFIG_OF_BOARD > +This is a board-specific situation, so needs to be considered on a > +case-by-case base. The devicetree must be modified so that the correct > +one is provided to U-Boot. How this is done depends entirely on the > +implementation of this option for the board. It might require injecting > the > +changes into a different project somehow using tooling available there, > or > +it might involve merging an overlay file at runtime to obtain the desired > +result. I thought this document was trying to describe the current situation in U-Boot. If so, the current CONFIG_OF_BOARD usage is far from what we have here. [...] Regards /Ilias
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 15:06, Marek Behún wrote: On Tue, 26 Oct 2021 14:40:48 +0200 Pali Rohár wrote: What is happening here? I do not know. But as Marek told me that observed same issue and replacing USB-UART cable by another decreased transfer time. So I think that issue is somewhere in USB-UART transmitter. My guess is that USB-UART transmitter send at 921600 speed: start bit, 8 bits of data, stop bit and then lng idle pause (logical one). After that sends another 10 bits. Yes, my FT232RL USB-UART converters do not send at higher speeds, although they report baudrate change. I do not really know what is going on. Maybe the ftdi-sio driver needs to be looked at. (It definitely needs to be looked at, because of other things. Last I looked into it the baudrate change code seemed okay.) Using pl2303 converter works like a charm. Note that I have another FT232RL converter for MOX, which works at 1.8V, and on MOX higher speeds work correctly. Maybe some of the FT232RL chips are those fake ones? Maybe. Unfortunately, on this Armada XP board this FTDI chip is soldered on the target, so I can't easily switch adapters. Stefan, could you check in a different way whether your converter can transfer at higher speed? For example with another device, or in U-Boot via kermit / ymodem, or whatnot. Connecting with 230400 baud and booting into U-Boot etc shows this: $ cu -s 230400 -l /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 Connected. �▒�`�▒3��▒�▒�▒�▒30�▒0`f憞~�▒�f�` So it seems, that baudrate change seems to work fine with the chip. Thanks, Stefan
Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Hi Simon,
As I said here [1], this is moving on an entirely different direction I had
in mind. I'd much prefer starting the discussions for a solution that
allows us to scale.
FWIW I think the current code is still not clean for my taste. Commit
3b595da441cf ("fdtdec: allow board to provide fdt for CONFIG_OF_SEPARATE")
allowed this function to be used regardless of the config options. IMHO we
should have 2 clear options:
- U-Boot provides the DTB
- It's somehow passed over to U-Boot
On Mon, Oct 25, 2021 at 06:23:44PM -0600, Simon Glass wrote:
> At present this override function is called even when OF_BOARD Is not
> enabled. This makes it impossible to disable this feature and in fact
> makes the OF_BOARD option useless.
>
> Reinstate its intended purpose, so that it is possible to switch between
> the appended devicetree and one provided by the board's custom function.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5:
> - Add new patches to clean up fdtdec_setup() and surrounds
>
> include/fdtdec.h | 7 +--
> lib/fdtdec.c | 17 +++--
> 2 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 386f6611294..b2faa84008e 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -1170,8 +1170,11 @@ int fdtdec_resetup(int *rescan);
>
> /**
> * Board-specific FDT initialization. Returns the address to a device tree
> blob.
> - * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is
> defined
> - * and the board implements it.
> + * Called when CONFIG_OF_BOARD is defined.
> + *
> + * The existing devicetree is available at gd->fdt_blob
> + *
> + * @returns new devicetree blob pointer
> */
> void *board_fdt_blob_setup(void);
>
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 067c27d0aa3..da36dffec62 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -1203,11 +1203,12 @@ static int uncompress_blob(const void *src, ulong
> sz_src, void **dstp)
> return 0;
> }
>
> -/*
> - * For CONFIG_OF_SEPARATE, the board may optionally implement this to
> - * provide and/or fixup the fdt.
> +/**
> + * fdt_find_separate() - Find a devicetree at the end of the image
> + *
> + * @return pointer to FDT blob
> */
> -__weak void *board_fdt_blob_setup(void)
> +static void *fdt_find_separate(void)
> {
> void *fdt_blob = NULL;
> #ifdef CONFIG_SPL_BUILD
> @@ -1623,11 +1624,15 @@ int fdtdec_setup(void)
> int ret;
>
> /* The devicetree is typically appended to U-Boot */
> - if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD))
> - gd->fdt_blob = board_fdt_blob_setup();
> + if (IS_ENABLED(CONFIG_OF_SEPARATE))
> + gd->fdt_blob = fdt_find_separate();
> else /* embed dtb in ELF file for testing / development */
> gd->fdt_blob = dtb_dt_embedded();
>
> + /* Allow the board to override the fdt address. */
> + if (IS_ENABLED(CONFIG_OF_BOARD))
> + gd->fdt_blob = board_fdt_blob_setup();
> +
> if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
> /* Allow the early environment to override the fdt address */
> gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
> --
> 2.33.0.1079.g6e70778dc9-goog
>
[1] https://lore.kernel.org/u-boot/yxektkel73nm0...@apalos.home/
Regards
/Ilias
Re: [PATCH v3 1/1] arm: spl: prepare for jumping to OPTEE
On Wed, Oct 20, 2021 at 03:12:06PM +0300, Oleksandr Suvorov wrote: > From: Ricardo Salveti > > Make sure to (if applicable) flush the D-cache, invalidate I-cache, > and disable MMU and caches before jumping to OPTEE. > This fixes the SDP->SPL->OPTEE boot flow on iMX6Q and most likely on > some other ARM SoCs. > > Signed-off-by: Ricardo Salveti > Co-developed-by: Oleksandr Suvorov > Signed-off-by: Oleksandr Suvorov Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] loads: Block writes into LMB reserved areas of U-Boot
On Sun, Oct 10, 2021 at 11:52:41PM +0200, marek.va...@gmail.com wrote: > From: Marek Vasut > > The loads srec loading may overwrite piece of U-Boot accidentally. > Prevent that by using LMB to detect whether upcoming write would > overwrite piece of reserved U-Boot code, and if that is the case, > abort the srec loading. > > Signed-off-by: Marek Vasut > Cc: Simon Glass > Cc: Tom Rini > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] env: mmc: Add support for redundant env in both eMMC boot partitions
On Sun, Oct 17, 2021 at 07:23:36PM +0200, Marek Vasut wrote: > Currently the MMC environment driver supports storing redundant environment > only in one eMMC partition at different offsets. This is sub-optimal, since > if this one boot partition is erased, both copies of environment are lost. > Since the eMMC has two boot partitions, add support for storing one copy of > environment in each of the two boot partitions. > > To enable this functionality, select CONFIG_SYS_REDUNDAND_ENVIRONMENT to > indicate redundant environment should be used. Set CONFIG_SYS_MMC_ENV_PART > to 1 to indicate environment should be stored in eMMC boot partition. Set > CONFIG_ENV_OFFSET equal to CONFIG_ENV_OFFSET_REDUND, and both to the offset > from start of eMMC boot partition where the environment should be located. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Jaehoon Chung > Cc: Peng Fan > Cc: Stefano Babic Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] env: mmc: Add missing eMMC bootpart restoration to env erase
On Wed, Oct 06, 2021 at 06:29:53PM +0200, Marek Vasut wrote: > If the environment is stored in eMMC hardware boot partition, the environment > driver first stores the currently selected eMMC boot partition, then does the > requested operation, and then restores the original boot partition settings. > In case the environment operation fails, the boot partition settings are also > restored. > > The 'env erase' implementation in the MMC environment driver lacks the path > which restores the boot partition. This could lead to various failure modes, > like the system boots the wrong copy of bootloader etc. Fix this by filling > in the missing restoration path. > > Signed-off-by: Marek Vasut > Cc: Fabio Estevam > Cc: Jaehoon Chung > Cc: Peng Fan > Cc: Stefano Babic Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] dfu: dfu_sf: Read the SPI flash in 16 MiB chunks
On Tue, Sep 14, 2021 at 05:26:51AM +0200, Marek Vasut wrote: > Not all SPI flashes and controllers can do continuous transfer longer > than 16 MiB, so perform the DFU read in 16 MiB chunks. > > Signed-off-by: Marek Vasut > Cc: Lukasz Majewski > Reviewed-by: Lukasz Majewski Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 0/3] Add SPL build support for RK3568
Hi Peter, This add SPL support for RK3568, and the ATF support is a function support int the ATF in rockchip platform, so if this chip works, them it will of course support ATF like other rockchip SoCs. Thanks, - Kever On 2021/10/26 下午4:09, Peter Robinson wrote: Hi Nico, Is this expected to work with Arm Trusted Firmware or some other TF? Could we have some docs/details for how to test this? Peter This series adds support for the rk3568 SOC, SPL load next-stage image from eMMC will be supported after this series of patches. Changes in v3: Replace configuration parameters of SGRF_SOC_CON4 with macro definitions. Changes in v2: We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to secure. Modify comments to make them more explicit. Nico Cheng (3): rockchip: Kconfig: Enable SPL support for rk3568 arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node rockchip: rk3568: add arch_cpu_init() arch/arm/dts/rk3568-u-boot.dtsi| 17 arch/arm/mach-rockchip/Kconfig | 2 ++ arch/arm/mach-rockchip/rk3568/rk3568.c | 27 +++--- configs/evb-rk3568_defconfig | 25 +++- include/configs/rk3568_common.h| 4 5 files changed, 71 insertions(+), 4 deletions(-) -- 2.17.1
Re: [PATCH v3 2/2] cmd: brcm: netXtreme commands
On Mon, 25 Oct 2021 16:44:44 -0700 Roman Bacik wrote: > From: Bharat Gooty > > Following netXtreme commands are supported: > probe, remove. > > Signed-off-by: Bharat Gooty > > Signed-off-by: Roman Bacik Hi Roman, why do you need to have custom command for probing / removing the driver? U-Boot PCI code should probe the driver automatically upon recognizing PCI vendor / device ID. Even if not, adding custom command for such a thing isn't nice, when we have the `dm` command for communicating with driver model. Marek
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tue, 26 Oct 2021 14:40:48 +0200 Pali Rohár wrote: > What is happening here? I do not know. But as Marek told me that > observed same issue and replacing USB-UART cable by another decreased > transfer time. So I think that issue is somewhere in USB-UART > transmitter. My guess is that USB-UART transmitter send at 921600 speed: > start bit, 8 bits of data, stop bit and then lng idle pause (logical > one). After that sends another 10 bits. Yes, my FT232RL USB-UART converters do not send at higher speeds, although they report baudrate change. I do not really know what is going on. Maybe the ftdi-sio driver needs to be looked at. (It definitely needs to be looked at, because of other things. Last I looked into it the baudrate change code seemed okay.) Using pl2303 converter works like a charm. Note that I have another FT232RL converter for MOX, which works at 1.8V, and on MOX higher speeds work correctly. Maybe some of the FT232RL chips are those fake ones? Stefan, could you check in a different way whether your converter can transfer at higher speed? For example with another device, or in U-Boot via kermit / ymodem, or whatnot. Marek
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tuesday 26 October 2021 13:09:42 Stefan Roese wrote:
> On 26.10.21 11:06, Pali Rohár wrote:
>
>
>
> > Now I found logical error in kwboot code which handles retransmission of
> > the last header packet. State of "baudrate change" is cleared on every
> > retransmission. Please apply following diff, so state variables are
> > initialized only once.
> >
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index d38ee0065177..835ccc8c113a 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -859,11 +859,6 @@ kwboot_xm_recv_reply(int fd, char *c, int
> > nak_on_non_xm,
> > uint64_t recv_until = _now() + timeout;
> > int rc;
> > - if (non_xm_print)
> > - *non_xm_print = 0;
> > - if (baud_changed)
> > - *baud_changed = 0;
> > -
> > while (1) {
> > rc = kwboot_tty_recv(fd, c, 1, timeout);
> > if (rc) {
> > @@ -929,6 +924,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block,
> > int allow_non_xm,
> > char c;
> > *done_print = 0;
> > + non_xm_print = 0;
> > + baud_changed = 0;
> > retries = 0;
> > do {
>
> This definitely helps (a bit). Now I get this:
Perfect! So this fixes issue with retransmission of the last header
packet.
But there is still issue with starting main U-Boot binary.
> [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b
> u-boot-spl.kwb -t
> /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> Patching image boot signature to UART
> Injecting binary header code for changing baudrate to 230400 Bd
> Injecting code for changing baudrate back
> Sending boot message. Please reboot the target...|
> Waiting 2s and flushing tty
> Sending boot image header (90112 bytes)...
> 0 %
> [..]
> 10 %
> [..]
> 20 %
> [..]
> 29 %
> [..]
> 39 %
> [..]
> 49 %
> [..]
> 59 %
> [..]
> 69 %
> [..]
> 79 %
> [..]
> 89 %
> [..]
> 99 % [ ]
> Done
>
> U-Boot SPL 2021.10-00908-gc129aa2f173a-dirty (Oct 26 2021 - 12:48:11 +0200)
> High speed PHY - Version: 2.1.5 (COM-PHY-V20)
> High speed PHY - Ended Successfully
> DDR3 Training Sequence - Ver 5.7.4
> DDR3 Training Sequence - Ended Successfully
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0x0aa0)...
>
> Changing baudrate to 230400 Bd
>
> Sending boot image data (549892 bytes)...
> 0 %
> [..]
>
> ...
>
> 99 % [... ]
> Done
> Finishing transfer
> Waiting 1s for baudrate change magic
> xmodem: Connection timed out
>
>
> BTW: The baudrate change does not seem to work or have any effect on
> the image download speed. Comparing 230400 and 921600 baud speeds, I can
> spot no real time difference here:
>
> 230400 baud:
> [stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 230400
> -b u-boot-spl.kwb -t
> /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> Patching image boot signature to UART
> Injecting binary header code for changing baudrate to 230400 Bd
>
> ...
>
> 99 % [... ]
> Done
> Finishing transfer
> Waiting 1s for baudrate change magic
> xmodem: Connection timed out
> [2]+ Doneemacs tools/kwboot.c
>
> real1m27,279s
> user0m2,313s
> sys 0m0,337s
>
> 921600 baud:
> [stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B 921600
> -b u-boot-spl.kwb -t
> /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
> Patching image boot signature to UART
> Injecting binary header code for changing baudrate to 921600 Bd
>
> ...
>
> 99 % [... ]
> Done
> Finishing transfer
> Waiting 1s for baudrate change magic
> xmodem: Connection timed out
>
> real1m27,839s
> user0m0,224s
> sys 0m0,194s
>
> Any idea why this is the case?
UARTs at both sides must be configured to 921600 speed, otherwise they
would not be able to communicate.
What is happening here? I do not know. But as Marek told me that
observed same issue and replacing USB-UART cable by another decreased
transfer time. So I think that issue is somewhere in USB-UART
transmitter. My guess is that USB-UART transmitter send at 921600 speed:
start bit, 8 bits of data, stop bit and then lng idle pause (logical
[PATCH] Remove LYNX KDI remainders
The last board that used to set CONFIG_LYNXKDI has been removed in
commit 242836a893ae ("powerpc: ppc4xx: remove pcs440ep support"),
doc/README.lynxkdi only talks about a MPC8260 board being supported,
and the mpc8260 support has been removed four years ago in commit
2eb48ff7a210d ("powerpc, 8260: remove support for mpc8260") already,
and common/lynxkdi.c only consists of an "#error" statement these
days, so it seems like the LYNX KDI code is dead code nowadays.
Let's remove it now.
Signed-off-by: Thomas Huth
---
common/Makefile | 1 -
common/bootm_os.c| 25
common/image.c | 2 +-
common/lynxkdi.c | 23 ---
doc/README.lynxkdi | 57
include/bootm.h | 1 -
include/lynxkdi.h| 24 ---
scripts/config_whitelist.txt | 1 -
8 files changed, 1 insertion(+), 133 deletions(-)
delete mode 100644 common/lynxkdi.c
delete mode 100644 doc/README.lynxkdi
delete mode 100644 include/lynxkdi.h
diff --git a/common/Makefile b/common/Makefile
index e7839027b6..44baf04572 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -50,7 +50,6 @@ obj-$(CONFIG_LCD) += lcd.o lcd_console.o
endif
obj-$(CONFIG_LCD_ROTATION) += lcd_console_rotation.o
obj-$(CONFIG_LCD_DT_SIMPLEFB) += lcd_simplefb.o
-obj-$(CONFIG_LYNXKDI) += lynxkdi.o
obj-$(CONFIG_MENU) += menu.o
obj-$(CONFIG_UPDATE_COMMON) += update.o
obj-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
diff --git a/common/bootm_os.c b/common/bootm_os.c
index 39623f9126..e635c72709 100644
--- a/common/bootm_os.c
+++ b/common/bootm_os.c
@@ -138,28 +138,6 @@ static int do_bootm_netbsd(int flag, int argc, char *const
argv[],
}
#endif /* CONFIG_BOOTM_NETBSD*/
-#ifdef CONFIG_LYNXKDI
-static int do_bootm_lynxkdi(int flag, int argc, char *const argv[],
- bootm_headers_t *images)
-{
- image_header_t *hdr = >legacy_hdr_os_copy;
-
- if (flag != BOOTM_STATE_OS_GO)
- return 0;
-
-#if defined(CONFIG_FIT)
- if (!images->legacy_hdr_valid) {
- fit_unsupported_reset("Lynx");
- return 1;
- }
-#endif
-
- lynxkdi_boot((image_header_t *)hdr);
-
- return 1;
-}
-#endif /* CONFIG_LYNXKDI */
-
#ifdef CONFIG_BOOTM_RTEMS
static int do_bootm_rtems(int flag, int argc, char *const argv[],
bootm_headers_t *images)
@@ -570,9 +548,6 @@ static boot_os_fn *boot_os[] = {
#ifdef CONFIG_BOOTM_NETBSD
[IH_OS_NETBSD] = do_bootm_netbsd,
#endif
-#ifdef CONFIG_LYNXKDI
- [IH_OS_LYNXOS] = do_bootm_lynxkdi,
-#endif
#ifdef CONFIG_BOOTM_RTEMS
[IH_OS_RTEMS] = do_bootm_rtems,
#endif
diff --git a/common/image.c b/common/image.c
index 3fa60b5827..992e72991d 100644
--- a/common/image.c
+++ b/common/image.c
@@ -106,7 +106,7 @@ static const table_entry_t uimage_os[] = {
{ IH_OS_INVALID, "invalid", "Invalid OS", },
{ IH_OS_ARM_TRUSTED_FIRMWARE, "arm-trusted-firmware", "ARM
Trusted Firmware" },
{ IH_OS_LINUX,"linux","Linux",},
-#if defined(CONFIG_LYNXKDI) || defined(USE_HOSTCC)
+#if defined(USE_HOSTCC)
{ IH_OS_LYNXOS, "lynxos", "LynxOS", },
#endif
{ IH_OS_NETBSD, "netbsd", "NetBSD", },
diff --git a/common/lynxkdi.c b/common/lynxkdi.c
deleted file mode 100644
index 1c8e122c32..00
--- a/common/lynxkdi.c
+++ /dev/null
@@ -1,23 +0,0 @@
-/*
- * Copyright (c) Orbacom Systems, Inc
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms are freely
- * permitted provided that the above copyright notice and this
- * paragraph and the following disclaimer are duplicated in all
- * such forms.
- *
- * This software is provided "AS IS" and without any express or
- * implied warranties, including, without limitation, the implied
- * warranties of merchantability and fitness for a particular
- * purpose.
- */
-
-#include
-#include
-#include
-#include
-
-#include
-
-#error "Lynx KDI support not implemented for configured CPU"
diff --git a/doc/README.lynxkdi b/doc/README.lynxkdi
deleted file mode 100644
index 076f01862a..00
--- a/doc/README.lynxkdi
+++ /dev/null
@@ -1,57 +0,0 @@
- LYNX KDI SUPPORT
-
- Last Update: July 20, 2003
-===
-
-This file describes support for LynuxWorks KDI within U-Boot. Support
-is enabled by defining CONFIG_LYNXKDI.
-
-
-LYNXOS AND BLUECAT SUPPORTED
-
-Both LynxOS and BlueCat linux KDIs are supported. The implementation
-automatically detects which is being booted. When you use mkimage
-you should specify "lynxos" for both (see target-specific notes).
-
-
-SUPPORTED ARCHITECTURE/TARGETS
-==
-The following targets have been tested:
-
--PowerPC
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon,
A bit late to the party, sorry!
[...]
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
>
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.
>
> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
>
> Anyway, here are the mental steps that I've gone through over the past
> two months:
>
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying
> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.
>
> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
Having U-Boot keep it's *internal* config state in DTs is fine. Adding
that to the DTs that are copied over from linux isn't imho. There are
various reasons for that. First of all syncing device trees is a huge pain
and that's probably one of the main reasons our DTs are out of sync for a
large number of boards.
The point is this was fine in 2011 were we had SPL only, but the reality
today is completely different. There's previous stage boot loaders (and
enough cases were vendors prefer those over SPL). If that bootloader needs
to use it's own device tree for whatever reason, imposing restrictions on
it wrt to the device tree it has to include, and require them to have
knowledge of U-Boot and it's internal config mechanism makes no sense not
to mention it doesn't scale at all.
>
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
Again, the board might decide for it's own reason to provide it's own DT.
IMHO U-Boot must be able to cope with that and asking DTs to be included in
U-Boot source is not the right way to do that, not to mention cases were
that's completely unrealistic (e.g QEMU or a board that reads the DTB from
it's flash).
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
>
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business.
And that's exactly why we have to come up with something that scales, without
having to add a bunch of unusable DTs in U-Boot.
> We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can
[PATCH v5] sandbox: Remove OF_HOSTFILE
OF_HOSTFILE is used on sandbox configs only. Although it's pretty
unique and not causing any confusions, we are better of having simpler
config options for the DTB.
So let's replace that with the existing OF_BOARD. U-Boot would then
have only three config options for the DTB origin.
- OF_SEPARATE, build separately from U-Boot
- OF_BOARD, board specific way of providing the DTB
- OF_EMBED embedded in the u-boot binary(should not be used in production
Signed-off-by: Ilias Apalodimas
Reviewed-by: Simon Glass
---
Note that this must be applied on top of
https://lore.kernel.org/u-boot/20211011210016.135929-1-ilias.apalodi...@linaro.org/
changes since v4:
- Fixed AndesTech compilation
- rebased on top of master
changes since v3:
- fix xilinx platforms based on xilinx_zynq_virt_defconfig
changes since v2:
- Rebased on top of the updated OF_BOARD patchset
Changes since v1:
- Added internal error value on board_fdt_blob_setup(). Arguably
we can just check against NULL and simplify this even more if we
don't care about the errno
- OF_BOARD is now default for sandbox builds
Makefile| 6 ++---
arch/arm/mach-stm32mp/boot_params.c | 3 ++-
arch/sandbox/cpu/cpu.c | 27 +
arch/sandbox/include/asm/u-boot-sandbox.h | 8 --
board/AndesTech/ax25-ae350/ax25-ae350.c | 4 ++-
board/Marvell/octeontx/board-fdt.c | 3 ++-
board/Marvell/octeontx2/board-fdt.c | 3 ++-
board/Marvell/octeontx2/board.c | 3 ++-
board/armltd/vexpress64/vexpress64.c| 7 --
board/broadcom/bcmstb/bcmstb.c | 3 ++-
board/emulation/qemu-arm/qemu-arm.c | 3 ++-
board/emulation/qemu-ppce500/qemu-ppce500.c | 3 ++-
board/emulation/qemu-riscv/qemu-riscv.c | 3 ++-
board/highbank/highbank.c | 3 ++-
board/raspberrypi/rpi/rpi.c | 8 --
board/sifive/unleashed/unleashed.c | 3 ++-
board/sifive/unmatched/unmatched.c | 3 ++-
board/socrates/socrates.c | 4 ++-
board/xen/xenguest_arm64/xenguest_arm64.c | 7 --
board/xilinx/common/board.c | 3 ++-
configs/sandbox64_defconfig | 1 -
configs/sandbox_defconfig | 1 -
configs/sandbox_flattree_defconfig | 1 -
configs/sandbox_noinst_defconfig| 1 -
configs/sandbox_spl_defconfig | 1 -
configs/tools-only_defconfig| 1 -
doc/develop/devicetree/control.rst | 7 +++---
dts/Kconfig | 10 +---
include/fdtdec.h| 4 ++-
lib/fdtdec.c| 14 +--
scripts/Makefile.spl| 2 +-
31 files changed, 81 insertions(+), 69 deletions(-)
diff --git a/Makefile b/Makefile
index 5194e4dc7829..c0ea933cb636 100644
--- a/Makefile
+++ b/Makefile
@@ -947,7 +947,7 @@ INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb
ifeq ($(CONFIG_SPL_FRAMEWORK),y)
INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img
endif
-INPUTS-$(CONFIG_OF_HOSTFILE) += u-boot.dtb
+INPUTS-$(CONFIG_SANDBOX) += u-boot.dtb
ifneq ($(CONFIG_SPL_TARGET),)
INPUTS-$(CONFIG_SPL) += $(CONFIG_SPL_TARGET:"%"=%)
endif
@@ -1407,7 +1407,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE
u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \
$(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \
- $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
\
+ $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb)
\
,$(UBOOT_BIN)) FORCE
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
@@ -1421,7 +1421,7 @@ MKIMAGEFLAGS_u-boot.itb += -B 0x8
ifdef U_BOOT_ITS
u-boot.itb: u-boot-nodtb.bin \
- $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_OF_HOSTFILE),dts/dt.dtb) \
+ $(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \
$(U_BOOT_ITS) FORCE
$(call if_changed,mkfitimage)
$(BOARD_SIZE_CHECK)
diff --git a/arch/arm/mach-stm32mp/boot_params.c
b/arch/arm/mach-stm32mp/boot_params.c
index 84647e70398b..e91ef1b2fc70 100644
--- a/arch/arm/mach-stm32mp/boot_params.c
+++ b/arch/arm/mach-stm32mp/boot_params.c
@@ -33,10 +33,11 @@ void save_boot_params(unsigned long r0, unsigned long r1,
unsigned long r2,
* Use the saved FDT address provided by TF-A at boot time (NT_FW_CONFIG =
* Non Trusted Firmware configuration file) when the pointer is valid
*/
-void *board_fdt_blob_setup(void)
+void *board_fdt_blob_setup(int *err)
{
log_debug("%s: nt_fw_dtb=%lx\n", __func__, nt_fw_dtb);
+ *err = 0;
/* use external device tree only if address is valid */
if (nt_fw_dtb >= STM32_DDR_BASE) {
Re: [PATCH v4] sandbox: Remove OF_HOSTFILE
On Tue, 26 Oct 2021 at 00:17, Tom Rini wrote: > > On Tue, Oct 19, 2021 at 04:07:21PM +0300, Ilias Apalodimas wrote: > > > OF_HOSTFILE is used on sandbox configs only. Although it's pretty > > unique and not causing any confusions, we are better of having simpler > > config options for the DTB. > > > > So let's replace that with the existing OF_BOARD. U-Boot would then > > have only three config options for the DTB origin. > > - OF_SEPARATE, build separately from U-Boot > > - OF_BOARD, board specific way of providing the DTB > > - OF_EMBED embedded in the u-boot binary(should not be used in production > > > > Signed-off-by: Ilias Apalodimas > > Reviewed-by: Simon Glass > > > This doesn't build on riscv: > +(ae350_rv64) board/AndesTech/ax25-ae350/ax25-ae350.c:57:7: error: > conflicting types for 'board_fdt_blob_setup'; have 'void *(void)' > +(ae350_rv64)57 | void *board_fdt_blob_setup(void) > +(ae350_rv64) | ^~~~ > +(ae350_rv64) In file included from include/asm-generic/global_data.h:23, > +(ae350_rv64) from arch/riscv/include/asm/global_data.h:35, > +(ae350_rv64) from include/init.h:21, > +(ae350_rv64) from > board/AndesTech/ax25-ae350/ax25-ae350.c:10: > +(ae350_rv64) include/fdtdec.h:1164:7: note: previous declaration of > 'board_fdt_blob_setup' with type 'void *(int *)' > +(ae350_rv64) 1164 | void *board_fdt_blob_setup(int *err); > +(ae350_rv64) board/AndesTech/ax25-ae350/ax25-ae350.c: In function > 'board_fdt_blob_setup': > +(ae350_rv64) board/AndesTech/ax25-ae350/ax25-ae350.c:59:10: error: 'err' > undeclared (first use in this function); did you mean 'errno'? > +(ae350_rv64)59 | *err = 0; > +(ae350_rv64) | ^~~ > +(ae350_rv64) | errno > +(ae350_rv64) board/AndesTech/ax25-ae350/ax25-ae350.c:59:10: note: each > undeclared identifier is reported only once for each function it appears in > +(ae350_rv64) make[2]: *** [scripts/Makefile.build:254: > board/AndesTech/ax25-ae350/ax25-ae350.o] Error 1 > +(ae350_rv64) make[1]: *** [Makefile:1801: board/AndesTech/ax25-ae350] Error 2 > +(ae350_rv64) make: *** [Makefile:177: sub-make] Error 2 Yea I somehow managed to mess up my merges. Apologies for the noise, I'll send a v5 Cheers /Ilias > > -- > Tom
[PATCH v3 1/2] net: brcm: netXtreme driver
From: Bharat Gooty
Broadcom bnxt L2 driver support. Used by the Broadcom
iproc platforms.
Signed-off-by: Bharat Gooty
Reviewed-by: Ramon Fried
Signed-off-by: Roman Bacik
---
Changes in v3:
- change printf to debug in display_banner
- remove get/set/print mac/speed
- remove bnxt_hwrm_set_nvmem
Changes in v2:
- rebase and remove DM_PCI dependency from BNXT_ETH
- remove tautology assignment from debug_resp()
drivers/net/Kconfig |1 +
drivers/net/Makefile|1 +
drivers/net/bnxt/Kconfig|6 +
drivers/net/bnxt/Makefile |5 +
drivers/net/bnxt/bnxt.c | 1841 +++
drivers/net/bnxt/bnxt_dbg.h | 537 ++
drivers/net/bnxt/pci_ids.h | 17 +
include/broadcom/bnxt.h | 407
include/broadcom/bnxt_hsi.h | 889 +
include/broadcom/bnxt_ver.h | 22 +
10 files changed, 3726 insertions(+)
create mode 100644 drivers/net/bnxt/Kconfig
create mode 100644 drivers/net/bnxt/Makefile
create mode 100644 drivers/net/bnxt/bnxt.c
create mode 100644 drivers/net/bnxt/bnxt_dbg.h
create mode 100644 drivers/net/bnxt/pci_ids.h
create mode 100644 include/broadcom/bnxt.h
create mode 100644 include/broadcom/bnxt_hsi.h
create mode 100644 include/broadcom/bnxt_ver.h
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6c12959f3794..8dc81a3d6cf9 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1,6 +1,7 @@
source "drivers/net/phy/Kconfig"
source "drivers/net/pfe_eth/Kconfig"
source "drivers/net/fsl-mc/Kconfig"
+source "drivers/net/bnxt/Kconfig"
config ETH
def_bool y
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index e4078d15a99f..1d9fbd6693cc 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
+obj-$(CONFIG_BNXT_ETH) += bnxt/
diff --git a/drivers/net/bnxt/Kconfig b/drivers/net/bnxt/Kconfig
new file mode 100644
index ..edc319a10625
--- /dev/null
+++ b/drivers/net/bnxt/Kconfig
@@ -0,0 +1,6 @@
+config BNXT_ETH
+ bool "BNXT PCI support"
+ depends on DM_ETH
+ help
+ This driver implements support for bnxt pci controller
+ driver of ethernet class.
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
new file mode 100644
index ..a9d6ce00d5e0
--- /dev/null
+++ b/drivers/net/bnxt/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2019-2021 Broadcom.
+
+# Broadcom nxe Ethernet driver
+obj-y += bnxt.o
diff --git a/drivers/net/bnxt/bnxt.c b/drivers/net/bnxt/bnxt.c
new file mode 100644
index ..d3663042aba2
--- /dev/null
+++ b/drivers/net/bnxt/bnxt.c
@@ -0,0 +1,1841 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019-2021 Broadcom.
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "bnxt_dbg.h"
+#include "pci_ids.h"
+
+#define bnxt_down_chip(bp) bnxt_hwrm_run(down_chip, bp, 0)
+#define bnxt_bring_chip(bp)bnxt_hwrm_run(bring_chip, bp, 1)
+
+static const char banner[] = DRV_MODULE_DESC " v" UBOOT_MODULE_VER ",";
+static const char fw_ver[] = " FW v";
+
+static int num_cards; /* Number of bnxt devices seen so far */
+
+static void display_banner(struct bnxt *bp)
+{
+ int i;
+
+ debug(banner);
+ debug(fw_ver);
+ debug("%d.%d.", bp->fw_maj, bp->fw_min);
+ debug("%d.%d\n", bp->fw_bld, bp->fw_rsvd);
+ debug("ETH MAC: ");
+ for (i = 0; i < ETH_ALEN; i++) {
+ debug("%02x", bp->mac_set[i]);
+ if (i != (ETH_ALEN - 1))
+ debug(":");
+ }
+
+ debug(", Port(%d), PF(%d)\n", bp->port_idx, bp->ordinal_value);
+}
+
+/* Broadcom ethernet driver PCI APIs. */
+static void bnxt_bring_pci(struct bnxt *bp)
+{
+ u16 cmd_reg = 0;
+
+ pci_read_word16(bp->pdev, PCI_VENDOR_ID, >vendor_id);
+ pci_read_word16(bp->pdev, PCI_DEVICE_ID, >device_id);
+ pci_read_word16(bp->pdev,
+ PCI_SUBSYSTEM_VENDOR_ID,
+ >subsystem_vendor);
+ pci_read_word16(bp->pdev, PCI_SUBSYSTEM_ID, >subsystem_device);
+ pci_read_word16(bp->pdev, PCI_COMMAND, >cmd_reg);
+ pci_read_byte(bp->pdev, PCICFG_ME_REGISTER, >pf_num);
+ pci_read_byte(bp->pdev, PCI_INTERRUPT_LINE, >irq);
+ bp->bar0 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_0, PCI_REGION_MEM);
+ bp->bar1 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_2, PCI_REGION_MEM);
+ bp->bar2 = pci_map_bar(bp->pdev, PCI_BASE_ADDRESS_4, PCI_REGION_MEM);
+ cmd_reg = bp->cmd_reg | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER;
+ cmd_reg |= PCI_COMMAND_INTX_DISABLE; /* disable intr */
+ pci_write_word(bp->pdev, PCI_COMMAND,
Re: Re: [PATCH v3 0/3] Add SPL build support for RK3568
Hi Peter, The scripts that package the ATF and other components are subject to further updates to the patch, which is not currently available in the submitted patch. Nico -- nico.ch...@rock-chips.com >Hi Nico, > >Is this expected to work with Arm Trusted Firmware or some other TF? > >Could we have some docs/details for how to test this? > >Peter > >> This series adds support for the rk3568 SOC, SPL load next-stage image from >> eMMC will be supported after this series of patches. >> >> Changes in v3: >> Replace configuration parameters of SGRF_SOC_CON4 with macro >> definitions. >> >> Changes in v2: >> We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to >> secure. >> Modify comments to make them more explicit. >> >> Nico Cheng (3): >> rockchip: Kconfig: Enable SPL support for rk3568 >> arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node >> rockchip: rk3568: add arch_cpu_init() >> >> arch/arm/dts/rk3568-u-boot.dtsi | 17 >> arch/arm/mach-rockchip/Kconfig | 2 ++ >> arch/arm/mach-rockchip/rk3568/rk3568.c | 27 +++--- >> configs/evb-rk3568_defconfig | 25 +++- >> include/configs/rk3568_common.h | 4 >> 5 files changed, 71 insertions(+), 4 deletions(-) >> >> -- >> 2.17.1 >> >> >> > >
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 11:06, Pali Rohár wrote:
Now I found logical error in kwboot code which handles retransmission of
the last header packet. State of "baudrate change" is cleared on every
retransmission. Please apply following diff, so state variables are
initialized only once.
diff --git a/tools/kwboot.c b/tools/kwboot.c
index d38ee0065177..835ccc8c113a 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -859,11 +859,6 @@ kwboot_xm_recv_reply(int fd, char *c, int nak_on_non_xm,
uint64_t recv_until = _now() + timeout;
int rc;
- if (non_xm_print)
- *non_xm_print = 0;
- if (baud_changed)
- *baud_changed = 0;
-
while (1) {
rc = kwboot_tty_recv(fd, c, 1, timeout);
if (rc) {
@@ -929,6 +924,8 @@ kwboot_xm_sendblock(int fd, struct kwboot_block *block, int
allow_non_xm,
char c;
*done_print = 0;
+ non_xm_print = 0;
+ baud_changed = 0;
retries = 0;
do {
This definitely helps (a bit). Now I get this:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400
-b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
Injecting code for changing baudrate back
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (90112 bytes)...
0 %
[..]
10 %
[..]
20 %
[..]
29 %
[..]
39 %
[..]
49 %
[..]
59 %
[..]
69 %
[..]
79 %
[..]
89 %
[..]
99 % [
]
Done
U-Boot SPL 2021.10-00908-gc129aa2f173a-dirty (Oct 26 2021 - 12:48:11 +0200)
High speed PHY - Version: 2.1.5 (COM-PHY-V20)
High speed PHY - Ended Successfully
DDR3 Training Sequence - Ver 5.7.4
DDR3 Training Sequence - Ended Successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0x0aa0)...
Changing baudrate to 230400 Bd
Sending boot image data (549892 bytes)...
0 %
[..]
...
99 % [...
]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
BTW: The baudrate change does not seem to work or have any effect on
the image download speed. Comparing 230400 and 921600 baud speeds, I can
spot no real time difference here:
230400 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B
230400 -b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 230400 Bd
...
99 % [...
]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
[2]+ Doneemacs tools/kwboot.c
real1m27,279s
user0m2,313s
sys 0m0,337s
921600 baud:
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ time ./tools/kwboot -B
921600 -b u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 921600 Bd
...
99 % [...
]
Done
Finishing transfer
Waiting 1s for baudrate change magic
xmodem: Connection timed out
real1m27,839s
user0m0,224s
sys 0m0,194s
Any idea why this is the case?
Ok. This seems to work at least partly (SPL):
[stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 115201 -b
u-boot-spl.kwb -t
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0
Patching image boot signature to UART
Injecting binary header code for changing baudrate to 115201 Bd
Injecting code for changing baudrate back
Sending boot message. Please reboot the target...|
Waiting 2s and flushing tty
Sending boot image header (90112 bytes)...
0 %
[..]
10 %
[..]
20 %
[..]
29 %
[..]
39 %
[..]
49 %
Re: [PATCH v9 3/7] env: Allow U-Boot scripts to be placed in a .env file
Dear Simon, In message you wrote: > > > > We need the space between the bootargs. > > > > Exactly like that, and for the case where you want to append something > > _without_ an extra space there's the .=3D operator I also suggested. > > Do you have a link to the docs for that? > > Perhaps we should get this initial thing in and we can take it from > there. I expect that as we start to convert more environments we'll > find more things we need. I think it is not a good idea to use two different operators for the same appand operation, just to add a space in one case. So assume I want to start the appended part with a TAB character, would we define another operator then? We have problems with escaping characters for the variable _name_ part, but not for the value. We can for example use standard shell escape rules, like: foo += bar foo += \ bar foo += ' bar' Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "There is no statute of limitations on stupidity." - Randomly produced by a computer program called Markov3.
RE: breakpoint not working in do_mmc_read (using qemu)
Hi, (for those who don't know how to stop at breakpoints after relocation..) I came back to this problem today and found https://shenki.github.io/debugging-u-boot-after-relocation/. So by doing in gdb, b relocation_done (after you stop at relocation_done), print /x ((gd_t *)$r9)->relocaddr $1 = 0x67f6b000 Add-symbo-file u-boot $1 (type y) c (continue) Now you can stop at board_init_r or do_mmc_read! Hope that helps. Thanks Chan Kim > -Original Message- > From: U-Boot On Behalf Of Chan Kim > Sent: Friday, October 22, 2021 5:19 PM > To: U-Boot Mailing List > Subject: breakpoint not working in do_mmc_read (using qemu) > > Hello, u-boot experts, > > > > I need to modify a proprietary SD card host controller driver to be used > in u-boot and I wanted to see the driver interface with the u-boot using > qemu. > > Trying to run u-boot on qemu with SD card, I found this nice question : > https://stackoverflow.com/questions/46239926/booting-kernel-from-sd-in- > qemu-arm-with-u-boot > > So I followed it and saw ‘mmc rescan’, ‘mmc read’ command works. > > Using debugger (arm-none-eabi-gdb), I can follow the code from _start and > can set breakpoint at board_init_f and etc. > > But even if I set breakpoint at do_mmc_read or do_mmc_rescan, the > breakpoint for those functions are not working. > > Could anyone tell me what I’m doing wrong? (Are there things I should set > in the config?) > > The qemu command is this : > > qemu-system-arm -machine vexpress-a9 -cpu cortex-a9 -m 128M -dtb > ~/prj/abdsn/ab21sim/ab21tsim/LinuxDevDrv/linux- > 5.4.21/arch/arm/boot/dts/vexpress-v2p-ca9.dtb -kernel u-boot -sd sd.img - > nographic -s -S > > and the u-boot (ELF file) contains debug_info. > > Any help will be deeply appreciated. > > Thanks, > > Chan Kim > > p.s. BTW, this email list contains mostly PATCH emails between u-boot > developers, so I feel a little sorry to ask questions here. > >
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Tuesday 26 October 2021 10:45:09 Stefan Roese wrote: > On 26.10.21 10:33, Pali Rohár wrote: > > On Monday 25 October 2021 17:15:14 Stefan Roese wrote: > > > Hi Pali, > > > > > > On 25.10.21 16:42, Pali Rohár wrote: > > > > On Monday 25 October 2021 16:39:44 Stefan Roese wrote: > > > > > Hi Marek, > > > > > > > > > > On 25.10.21 15:12, Marek Behún wrote: > > > > > > From: Marek Behún > > > > > > > > > > > > Hello Stefan, > > > > > > > > > > > > these are another improvements for kwboot, please apply only after > > > > > > series > > > > > > arm: mvebu: nandpagesize support for kwbimage v1 > > > > > > > > > > I'm checking right now and have applied the 3 NAND patches on current > > > > > master. But this patchset fails at this one: > > > > > > > > > > tools: kwboot: Do not modify kwbimage header before increasing its > > > > > size > > > > > > > > > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 > > > > > ~/tmp/kwboot2/* > > > > > Applying: tools: kwboot: Initialize rfds to zero > > > > > Applying: tools: kwboot: Fix initialization of tty device > > > > > Applying: tools: kwboot: Reserve enough space for patching kwbimage in > > > > > memory > > > > > Applying: tools: kwboot: Validate 4-byte image data checksum > > > > > Applying: tools: kwboot: Inject baudrate change back code after data > > > > > part > > > > > Applying: tools: kwboot: Recalculate 4-byte data checksum after > > > > > injecting > > > > > baudrate code > > > > > Applying: tools: kwboot: Correctly set configuration of UART for > > > > > BootROM > > > > > messages > > > > > Applying: tools: kwboot: Show verbose message when waiting for > > > > > baudrate > > > > > change magic > > > > > Applying: tools: kwboot: Simplify code for aligning image header > > > > > Applying: tools: kwboot: Do not modify kwbimage header before > > > > > increasing its > > > > > size > > > > > error: sha1 information is lacking or useless (tools/kwboot.c). > > > > > error: could not build fake ancestor > > > > > Patch failed at 0010 tools: kwboot: Do not modify kwbimage header > > > > > before > > > > > increasing its size > > > > > hint: Use 'git am --show-current-patch=diff' to see the failed patch > > > > > When you have resolved this problem, run "git am --continue". > > > > > If you prefer to skip this patch, run "git am --skip" instead. > > > > > To restore the original branch and stop patching, run "git am > > > > > --abort". > > > > > > > > > > Any idea what's missing here? > > > > > > > > Hello! I'm using also this patch: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211021144609.9319-2-p...@kernel.org/ > > > > > > Ah, yes. That does the trick. Now all patches apply clean. Thanks. > > > > > > Testing with all these patches on my AXP target does show, it still > > > does not work with baudrate > 115k: > > > > > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b > > > u-boot-spl.kwb -t > > > /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 > > > Patching image boot signature to UART > > > Injecting binary header code for changing baudrate to 230400 Bd > > > Injecting code for changing baudrate back > > > Sending boot message. Please reboot the target...| > > > Waiting 2s and flushing tty > > > Sending boot image header (90112 bytes)... > > >0 % > > > [..] > > > 10 % > > > [..] > > > 20 % > > > [..] > > > 29 % > > > [..] > > > 39 % > > > [..] > > > 49 % > > > [..] > > > 59 % > > > [..] > > > 69 % > > > [..] > > > 79 % > > > [..] > > > 89 % > > > [..] > > > 99 % [ ] > > > Done > > > > > > U-Boot SPL 2021.10-00908-gc129aa2f173a (Oct 25 2021 - 17:10:55 +0200) > > > High speed PHY - Version: 2.1.5 (COM-PHY-V20) > > > High speed PHY - Ended Successfully > > > DDR3 Training Sequence - Ver 5.7.4 > > > DDR3 Training Sequence - Ended Successfully > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0x0aa0)... > > > > > > Changing baudrate to 230400 Bd > > > Baudrate was not changed > > > > > > > > > xmodem: Protocol error > > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ > > > > > > > > > Not changing the baudrate still works. Any idea what I should test? Or > > > do you have further changes in the queue that I should wait upon? > > > >
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On 26.10.21 10:33, Pali Rohár wrote: On Monday 25 October 2021 17:15:14 Stefan Roese wrote: Hi Pali, On 25.10.21 16:42, Pali Rohár wrote: On Monday 25 October 2021 16:39:44 Stefan Roese wrote: Hi Marek, On 25.10.21 15:12, Marek Behún wrote: From: Marek Behún Hello Stefan, these are another improvements for kwboot, please apply only after series arm: mvebu: nandpagesize support for kwbimage v1 I'm checking right now and have applied the 3 NAND patches on current master. But this patchset fails at this one: tools: kwboot: Do not modify kwbimage header before increasing its size [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 ~/tmp/kwboot2/* Applying: tools: kwboot: Initialize rfds to zero Applying: tools: kwboot: Fix initialization of tty device Applying: tools: kwboot: Reserve enough space for patching kwbimage in memory Applying: tools: kwboot: Validate 4-byte image data checksum Applying: tools: kwboot: Inject baudrate change back code after data part Applying: tools: kwboot: Recalculate 4-byte data checksum after injecting baudrate code Applying: tools: kwboot: Correctly set configuration of UART for BootROM messages Applying: tools: kwboot: Show verbose message when waiting for baudrate change magic Applying: tools: kwboot: Simplify code for aligning image header Applying: tools: kwboot: Do not modify kwbimage header before increasing its size error: sha1 information is lacking or useless (tools/kwboot.c). error: could not build fake ancestor Patch failed at 0010 tools: kwboot: Do not modify kwbimage header before increasing its size hint: Use 'git am --show-current-patch=diff' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Any idea what's missing here? Hello! I'm using also this patch: https://patchwork.ozlabs.org/project/uboot/patch/20211021144609.9319-2-p...@kernel.org/ Ah, yes. That does the trick. Now all patches apply clean. Thanks. Testing with all these patches on my AXP target does show, it still does not work with baudrate > 115k: [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b u-boot-spl.kwb -t /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 Patching image boot signature to UART Injecting binary header code for changing baudrate to 230400 Bd Injecting code for changing baudrate back Sending boot message. Please reboot the target...| Waiting 2s and flushing tty Sending boot image header (90112 bytes)... 0 % [..] 10 % [..] 20 % [..] 29 % [..] 39 % [..] 49 % [..] 59 % [..] 69 % [..] 79 % [..] 89 % [..] 99 % [ ] Done U-Boot SPL 2021.10-00908-gc129aa2f173a (Oct 25 2021 - 17:10:55 +0200) High speed PHY - Version: 2.1.5 (COM-PHY-V20) High speed PHY - Ended Successfully DDR3 Training Sequence - Ver 5.7.4 DDR3 Training Sequence - Ended Successfully Trying to boot from BOOTROM Returning to BootROM (return address 0x0aa0)... Changing baudrate to 230400 Bd Baudrate was not changed xmodem: Protocol error [stefan@ryzen u-boot-marvell (kwboot-test1)]$ Not changing the baudrate still works. Any idea what I should test? Or do you have further changes in the queue that I should wait upon? Could you try to boot with baudrate 115201? This value would trigger to use baudrate change code and because it is too close to standard 115200 there would be no real change. Ok. This seems to work at least partly (SPL): [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 115201 -b u-boot-spl.kwb -t /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 Patching image boot signature to UART Injecting binary header code for changing baudrate to 115201 Bd Injecting code for changing baudrate back Sending boot message. Please reboot the target...| Waiting 2s and flushing tty Sending boot image header (90112 bytes)... 0 % [..] 10 % [..] 20 % [..] 29 % [..] 39 %
Re: [PATCH u-boot-marvell 00/13] Yet another kwboot improvements
On Monday 25 October 2021 17:15:14 Stefan Roese wrote: > Hi Pali, > > On 25.10.21 16:42, Pali Rohár wrote: > > On Monday 25 October 2021 16:39:44 Stefan Roese wrote: > > > Hi Marek, > > > > > > On 25.10.21 15:12, Marek Behún wrote: > > > > From: Marek Behún > > > > > > > > Hello Stefan, > > > > > > > > these are another improvements for kwboot, please apply only after > > > > series > > > > arm: mvebu: nandpagesize support for kwbimage v1 > > > > > > I'm checking right now and have applied the 3 NAND patches on current > > > master. But this patchset fails at this one: > > > > > > tools: kwboot: Do not modify kwbimage header before increasing its size > > > > > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ git am -3 ~/tmp/kwboot2/* > > > Applying: tools: kwboot: Initialize rfds to zero > > > Applying: tools: kwboot: Fix initialization of tty device > > > Applying: tools: kwboot: Reserve enough space for patching kwbimage in > > > memory > > > Applying: tools: kwboot: Validate 4-byte image data checksum > > > Applying: tools: kwboot: Inject baudrate change back code after data part > > > Applying: tools: kwboot: Recalculate 4-byte data checksum after injecting > > > baudrate code > > > Applying: tools: kwboot: Correctly set configuration of UART for BootROM > > > messages > > > Applying: tools: kwboot: Show verbose message when waiting for baudrate > > > change magic > > > Applying: tools: kwboot: Simplify code for aligning image header > > > Applying: tools: kwboot: Do not modify kwbimage header before increasing > > > its > > > size > > > error: sha1 information is lacking or useless (tools/kwboot.c). > > > error: could not build fake ancestor > > > Patch failed at 0010 tools: kwboot: Do not modify kwbimage header before > > > increasing its size > > > hint: Use 'git am --show-current-patch=diff' to see the failed patch > > > When you have resolved this problem, run "git am --continue". > > > If you prefer to skip this patch, run "git am --skip" instead. > > > To restore the original branch and stop patching, run "git am --abort". > > > > > > Any idea what's missing here? > > > > Hello! I'm using also this patch: > > https://patchwork.ozlabs.org/project/uboot/patch/20211021144609.9319-2-p...@kernel.org/ > > Ah, yes. That does the trick. Now all patches apply clean. Thanks. > > Testing with all these patches on my AXP target does show, it still > does not work with baudrate > 115k: > > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ ./tools/kwboot -B 230400 -b > u-boot-spl.kwb -t > /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 > Patching image boot signature to UART > Injecting binary header code for changing baudrate to 230400 Bd > Injecting code for changing baudrate back > Sending boot message. Please reboot the target...| > Waiting 2s and flushing tty > Sending boot image header (90112 bytes)... > 0 % > [..] > 10 % > [..] > 20 % > [..] > 29 % > [..] > 39 % > [..] > 49 % > [..] > 59 % > [..] > 69 % > [..] > 79 % > [..] > 89 % > [..] > 99 % [ ] > Done > > U-Boot SPL 2021.10-00908-gc129aa2f173a (Oct 25 2021 - 17:10:55 +0200) > High speed PHY - Version: 2.1.5 (COM-PHY-V20) > High speed PHY - Ended Successfully > DDR3 Training Sequence - Ver 5.7.4 > DDR3 Training Sequence - Ended Successfully > Trying to boot from BOOTROM > Returning to BootROM (return address 0x0aa0)... > > Changing baudrate to 230400 Bd > Baudrate was not changed > > > xmodem: Protocol error > [stefan@ryzen u-boot-marvell (kwboot-test1)]$ > > > Not changing the baudrate still works. Any idea what I should test? Or > do you have further changes in the queue that I should wait upon? Could you try to boot with baudrate 115201? This value would trigger to use baudrate change code and because it is too close to standard 115200 there would be no real change. And what is the output of following command immediately after kwboot? stty -F /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1019EGY-if00-port0 Also, could try to catch whole strace log and send it to me?
[PATCH v4 4/4] efi_loader: add DeployedMode and AuditMode variable measurement
This commit adds the DeployedMode and AuditMode variable
measurement required in TCG PC Client Platform Firmware
Profile Specification.
Signed-off-by: Masahisa Kojima
---
Changes in v4:
- use table and loop
- update commit message
Changes in v3:
- read variable first, then mesure the variable
lib/efi_loader/efi_tcg2.c | 33 +
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 6545ec9e79..6f0f36394a 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -84,16 +84,19 @@ static const struct digest_info hash_algo_list[] = {
struct variable_info {
const u16 *name;
boolaccept_empty;
+ u32 pcr_index;
};
static struct variable_info secure_variables[] = {
- {u"SecureBoot", true},
- {u"PK", true},
- {u"KEK",true},
- {u"db", true},
- {u"dbx",true},
- {u"dbt",false},
- {u"dbr",false},
+ {u"SecureBoot", true, 7},
+ {u"PK", true, 7},
+ {u"KEK",true, 7},
+ {u"db", true, 7},
+ {u"dbx",true, 7},
+ {u"dbt",false, 7},
+ {u"dbr",false, 7},
+ {u"DeployedMode", false, 1},
+ {u"AuditMode", false, 1},
};
#define MAX_HASH_COUNT ARRAY_SIZE(hash_algo_list)
@@ -1822,6 +1825,15 @@ static efi_status_t
tcg2_measure_secure_boot_variable(struct udevice *dev)
efi_uintn_t data_size;
u32 count, i;
efi_status_t ret;
+ u8 deployed_mode;
+ efi_uintn_t size;
+ u32 deployed_audit_pcr_index = 1;
+
+ size = sizeof(deployed_mode);
+ ret = efi_get_variable_int(u"DeployedMode", _global_variable_guid,
+ NULL, , _mode, NULL);
+ if (ret != EFI_SUCCESS || !deployed_mode)
+ deployed_audit_pcr_index = 7;
count = ARRAY_SIZE(secure_variables);
for (i = 0; i < count; i++) {
@@ -1833,7 +1845,12 @@ static efi_status_t
tcg2_measure_secure_boot_variable(struct udevice *dev)
if (!data && !secure_variables[i].accept_empty)
continue;
- ret = tcg2_measure_variable(dev, 7,
+ if (u16_strcmp(u"DeployedMode", secure_variables[i].name))
+ secure_variables[i].pcr_index =
deployed_audit_pcr_index;
+ if (u16_strcmp(u"AuditMode", secure_variables[i].name))
+ secure_variables[i].pcr_index =
deployed_audit_pcr_index;
+
+ ret = tcg2_measure_variable(dev, secure_variables[i].pcr_index,
EV_EFI_VARIABLE_DRIVER_CONFIG,
secure_variables[i].name, guid,
data_size, data);
--
2.17.1
[PATCH v4 3/4] efi_loader: simplify tcg2_measure_secure_boot_variable()
This commit simplifies tcg2_measure_secure_boot_variable()
using secure_variables table.
Signed-off-by: Masahisa Kojima
---
Newly added in v4
lib/efi_loader/efi_tcg2.c | 60 ---
1 file changed, 18 insertions(+), 42 deletions(-)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 377b138855..6545ec9e79 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -81,12 +81,19 @@ static const struct digest_info hash_algo_list[] = {
},
};
-static const u16 *secure_variables[] = {
- u"SecureBoot",
- u"PK",
- u"KEK",
- u"db",
- u"dbx",
+struct variable_info {
+ const u16 *name;
+ boolaccept_empty;
+};
+
+static struct variable_info secure_variables[] = {
+ {u"SecureBoot", true},
+ {u"PK", true},
+ {u"KEK",true},
+ {u"db", true},
+ {u"dbx",true},
+ {u"dbt",false},
+ {u"dbr",false},
};
#define MAX_HASH_COUNT ARRAY_SIZE(hash_algo_list)
@@ -1820,52 +1827,21 @@ static efi_status_t
tcg2_measure_secure_boot_variable(struct udevice *dev)
for (i = 0; i < count; i++) {
const efi_guid_t *guid;
- guid = efi_auth_var_get_guid(secure_variables[i]);
+ guid = efi_auth_var_get_guid(secure_variables[i].name);
- /*
-* According to the TCG2 PC Client PFP spec, "SecureBoot",
-* "PK", "KEK", "db" and "dbx" variables must be measured
-* even if they are empty.
-*/
- data = efi_get_var(secure_variables[i], guid, _size);
+ data = efi_get_var(secure_variables[i].name, guid, _size);
+ if (!data && !secure_variables[i].accept_empty)
+ continue;
ret = tcg2_measure_variable(dev, 7,
EV_EFI_VARIABLE_DRIVER_CONFIG,
- secure_variables[i], guid,
+ secure_variables[i].name, guid,
data_size, data);
free(data);
if (ret != EFI_SUCCESS)
goto error;
}
- /*
-* TCG2 PC Client PFP spec says "dbt" and "dbr" are
-* measured if present and not empty.
-*/
- data = efi_get_var(L"dbt",
- _guid_image_security_database,
- _size);
- if (data) {
- ret = tcg2_measure_variable(dev, 7,
- EV_EFI_VARIABLE_DRIVER_CONFIG,
- L"dbt",
- _guid_image_security_database,
- data_size, data);
- free(data);
- }
-
- data = efi_get_var(L"dbr",
- _guid_image_security_database,
- _size);
- if (data) {
- ret = tcg2_measure_variable(dev, 7,
- EV_EFI_VARIABLE_DRIVER_CONFIG,
- L"dbr",
- _guid_image_security_database,
- data_size, data);
- free(data);
- }
-
error:
return ret;
}
--
2.17.1
[PATCH v4 2/4] efi_loader: add UEFI GPT measurement
This commit adds the UEFI GPT disk partition topology
measurement required in TCG PC Client Platform Firmware
Profile Specification
Signed-off-by: Masahisa Kojima
---
Changes in v4:
- update commit message
- return EFI_SUCCESS if device path is NULL
- use memalign()
Changes in v3:
- EV_EFI_GPT_EVENT is measured before EV_SEPARATOR, same as
other PCRs
- use PTR_ARRAY instead of ARRAY
- create sub-function of allocating io_aligned buffer
- move search_gpt_dp_node() into efi_device_path.c
include/blk.h| 3 +
include/efi_loader.h | 3 +-
include/efi_tcg2.h | 12 +++
lib/efi_loader/efi_boottime.c| 2 +-
lib/efi_loader/efi_device_path.c | 27 ++
lib/efi_loader/efi_tcg2.c| 146 ++-
6 files changed, 190 insertions(+), 3 deletions(-)
diff --git a/include/blk.h b/include/blk.h
index 19bab081c2..f0cc7ca1a2 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -45,6 +45,9 @@ enum if_type {
#define BLK_PRD_SIZE 20
#define BLK_REV_SIZE 8
+#define PART_FORMAT_PCAT 0x1
+#define PART_FORMAT_GPT0x2
+
/*
* Identifies the partition table type (ie. MBR vs GPT GUID) signature
*/
diff --git a/include/efi_loader.h b/include/efi_loader.h
index d0433ea52e..d52e399841 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -503,7 +503,7 @@ efi_status_t efi_init_variables(void);
void efi_variables_boot_exit_notify(void);
efi_status_t efi_tcg2_notify_exit_boot_services_failed(void);
/* Measure efi application invocation */
-efi_status_t efi_tcg2_measure_efi_app_invocation(void);
+efi_status_t efi_tcg2_measure_efi_app_invocation(struct efi_loaded_image_obj
*handle);
/* Measure efi application exit */
efi_status_t efi_tcg2_measure_efi_app_exit(void);
/* Called by bootefi to initialize root node */
@@ -847,6 +847,7 @@ struct efi_device_path *efi_dp_from_lo(struct
efi_load_option *lo,
const efi_guid_t *guid);
struct efi_device_path *efi_dp_concat(const struct efi_device_path *dp1,
const struct efi_device_path *dp2);
+struct efi_device_path *search_gpt_dp_node(struct efi_device_path
*device_path);
efi_status_t efi_deserialize_load_option(struct efi_load_option *lo, u8 *data,
efi_uintn_t *size);
unsigned long efi_serialize_load_option(struct efi_load_option *lo, u8 **data);
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index ca66695b39..50a59f9263 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -225,6 +225,18 @@ struct smbios_handoff_table_pointers2 {
struct efi_configuration_table table_entry[];
} __packed;
+/**
+ * struct tdUEFI_GPT_DATA - event log structure of industry standard tables
+ * @uefi_partition_header: gpt partition header
+ * @number_of_partitions: the number of partition
+ * @partitions:partition entries
+ */
+struct efi_gpt_data {
+ gpt_header uefi_partition_header;
+ u64 number_of_partitions;
+ gpt_entry partitions[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index 973134b12d..1823990d9b 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -3004,7 +3004,7 @@ efi_status_t EFIAPI efi_start_image(efi_handle_t
image_handle,
if (IS_ENABLED(CONFIG_EFI_TCG2_PROTOCOL)) {
if (image_obj->image_type == IMAGE_SUBSYSTEM_EFI_APPLICATION) {
- ret = efi_tcg2_measure_efi_app_invocation();
+ ret = efi_tcg2_measure_efi_app_invocation(image_obj);
if (ret != EFI_SUCCESS) {
log_warning("tcg2 measurement fails(0x%lx)\n",
ret);
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index c04439d16d..735ed0bd0f 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1239,3 +1239,30 @@ efi_device_path *efi_dp_from_lo(struct efi_load_option
*lo,
return NULL;
}
+
+/**
+ * search_gpt_dp_node() - search gpt device path node
+ *
+ * @device_path: device path
+ *
+ * Return: pointer to the gpt device path node
+ */
+struct efi_device_path *search_gpt_dp_node(struct efi_device_path *device_path)
+{
+ struct efi_device_path *dp = device_path;
+
+ while (dp) {
+ if (dp->type == DEVICE_PATH_TYPE_MEDIA_DEVICE &&
+ dp->sub_type == DEVICE_PATH_SUB_TYPE_HARD_DRIVE_PATH) {
+ struct efi_device_path_hard_drive_path *hd_dp =
+ (struct efi_device_path_hard_drive_path *)dp;
+
+
[PATCH v4 1/4] efi_loader: add SMBIOS table measurement
TCG PC Client Platform Firmware Profile Specification
requires to measure the SMBIOS table that contains static
configuration information (e.g. Platform Manufacturer
Enterprise Number assigned by IANA, platform model number,
Vendor and Device IDs for each SMBIOS table).
The device- and environment-dependent information such as
serial number is cleared to zero or space character for
the measurement.
Existing smbios_string() function returns pointer to the string
with const qualifier, but exisintg use case is updating version
string and const qualifier must be removed.
This commit removes const qualifier from smbios_string()
return value and reuses to clear the strings for the measurement.
This commit also fixes the following compiler warning:
lib/smbios-parser.c:59:39: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
const struct smbios_header *header = (struct smbios_header
*)entry->struct_table_address;
Signed-off-by: Masahisa Kojima
---
Changes in v4:
- update commit message
Changes in v3:
- TCG spec says EV_SEPARATOR must be the last,
swap the order of measurement
Changes in v2:
- use flexible array for table_entry field
- modify funtion name to find_smbios_table()
- remove unnecessary const qualifier from smbios_string()
- create non-const version of next_header()
include/efi_loader.h | 2 +
include/efi_tcg2.h| 15
include/smbios.h | 17 +++-
lib/efi_loader/Kconfig| 1 +
lib/efi_loader/efi_boottime.c | 2 +
lib/efi_loader/efi_smbios.c | 2 -
lib/efi_loader/efi_tcg2.c | 84 +++
lib/smbios-parser.c | 152 +++---
8 files changed, 261 insertions(+), 14 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f6d65a6c0c..d0433ea52e 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -308,6 +308,8 @@ extern const efi_guid_t efi_guid_capsule_report;
extern const efi_guid_t efi_guid_firmware_management_protocol;
/* GUID for the ESRT */
extern const efi_guid_t efi_esrt_guid;
+/* GUID of the SMBIOS table */
+extern const efi_guid_t smbios_guid;
extern char __efi_runtime_start[], __efi_runtime_stop[];
extern char __efi_runtime_rel_start[], __efi_runtime_rel_stop[];
diff --git a/include/efi_tcg2.h b/include/efi_tcg2.h
index 8f02d4fb0b..ca66695b39 100644
--- a/include/efi_tcg2.h
+++ b/include/efi_tcg2.h
@@ -210,6 +210,21 @@ struct efi_tcg2_uefi_variable_data {
u8 variable_data[1];
};
+/**
+ * struct tdUEFI_HANDOFF_TABLE_POINTERS2 - event log structure of SMBOIS tables
+ * @table_description_size:size of table description
+ * @table_description: table description
+ * @number_of_tables: number of uefi configuration table
+ * @table_entry: uefi configuration table entry
+ */
+#define SMBIOS_HANDOFF_TABLE_DESC "SmbiosTable"
+struct smbios_handoff_table_pointers2 {
+ u8 table_description_size;
+ u8 table_description[sizeof(SMBIOS_HANDOFF_TABLE_DESC)];
+ u64 number_of_tables;
+ struct efi_configuration_table table_entry[];
+} __packed;
+
struct efi_tcg2_protocol {
efi_status_t (EFIAPI * get_capability)(struct efi_tcg2_protocol *this,
struct
efi_tcg2_boot_service_capability *capability);
diff --git a/include/smbios.h b/include/smbios.h
index aa6b6f3849..acfcbfe2ca 100644
--- a/include/smbios.h
+++ b/include/smbios.h
@@ -260,9 +260,9 @@ const struct smbios_header *smbios_header(const struct
smbios_entry *entry, int
*
* @header:pointer to struct smbios_header
* @index: string index
- * @return:NULL or a valid const char pointer
+ * @return:NULL or a valid char pointer
*/
-const char *smbios_string(const struct smbios_header *header, int index);
+char *smbios_string(const struct smbios_header *header, int index);
/**
* smbios_update_version() - Update the version string
@@ -292,4 +292,17 @@ int smbios_update_version(const char *version);
*/
int smbios_update_version_full(void *smbios_tab, const char *version);
+/**
+ * smbios_prepare_measurement() - Update smbios table for the measurement
+ *
+ * TCG specification requires to measure static configuration information.
+ * This function clear the device dependent parameters such as
+ * serial number for the measurement.
+ *
+ * @entry: pointer to a struct smbios_entry
+ * @header: pointer to a struct smbios_header
+ */
+void smbios_prepare_measurement(const struct smbios_entry *entry,
+ struct smbios_header *header);
+
#endif /* _SMBIOS_H_ */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 06633e90a1..52f71c07c9 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -312,6 +312,7 @@ config EFI_TCG2_PROTOCOL
select SHA384
select SHA512
select HASH
+ select SMBIOS_PARSER
help
Provide a EFI_TCG2_PROTOCOL
[PATCH v4 0/4] Enhance Measured Boot
This patch series add the following measurement mandated in the TCG PC Client PFP Specification. - SMBIOS tables - GPT disk partition topology - AuditMode and Deployed mode Masahisa Kojima (4): efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: simplify tcg2_measure_secure_boot_variable() efi_loader: add DeployedMode and AuditMode variable measurement include/blk.h| 3 + include/efi_loader.h | 5 +- include/efi_tcg2.h | 27 +++ include/smbios.h | 17 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_boottime.c| 4 +- lib/efi_loader/efi_device_path.c | 27 +++ lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c| 309 ++- lib/smbios-parser.c | 152 ++- 10 files changed, 487 insertions(+), 60 deletions(-) -- 2.17.1
Re: [PATCH v3 0/3] Add SPL build support for RK3568
Hi Nico, Is this expected to work with Arm Trusted Firmware or some other TF? Could we have some docs/details for how to test this? Peter > This series adds support for the rk3568 SOC, SPL load next-stage image from > eMMC will be supported after this series of patches. > > Changes in v3: > Replace configuration parameters of SGRF_SOC_CON4 with macro > definitions. > > Changes in v2: > We use the rk_clrreg function instead of the writel to set eMMC sdmmc0 to > secure. > Modify comments to make them more explicit. > > Nico Cheng (3): > rockchip: Kconfig: Enable SPL support for rk3568 > arm: dts: rockchip: rk3568: Enable sdhci and sdmmc0 node > rockchip: rk3568: add arch_cpu_init() > > arch/arm/dts/rk3568-u-boot.dtsi| 17 > arch/arm/mach-rockchip/Kconfig | 2 ++ > arch/arm/mach-rockchip/rk3568/rk3568.c | 27 +++--- > configs/evb-rk3568_defconfig | 25 +++- > include/configs/rk3568_common.h| 4 > 5 files changed, 71 insertions(+), 4 deletions(-) > > -- > 2.17.1 > > >
Re: [PATCH] introduce CONFIG_DEVICE_TREE_INCLUDES
On 26/10/2021 03.28, Simon Glass wrote:
> Hi Rasmus,
>
> On Tue, 28 Sept 2021 at 02:57, Rasmus Villemoes
> wrote:
>>
>> The build system already automatically looks for and includes an
>> in-tree *-u-boot.dtsi when building the control .dtb. However, there
>> are some things that are awkward to maintain in such an in-tree file,
>> most notably the metadata associated to public keys used for verified
>> boot.
>>
>> The only "official" API to get that metadata into the .dtb is via
>> mkimage, as a side effect of building an actual signed image. But
>> there are multiple problems with that. First of all, the final U-Boot
>> (be it U-Boot proper or an SPL) image is built based on a binary
>> image, the .dtb, and possibly some other binary artifacts. So
>> modifying the .dtb after the build requires the meta-buildsystem
>> (Yocto, buildroot, whatnot) to know about and repeat some of the steps
>> that are already known to and handled by U-Boot's build system,
>> resulting in needless duplication of code. It's also somewhat annoying
>> and inconsistent to have a .dtb file in the build folder which is not
>> generated by the command listed in the corresponding .cmd file (that
>> of course applies to any generated file).
>>
>> So the contents of the /signature node really needs to be baked into
>> the .dtb file when it is first created, which means providing the
>> relevant data in the form of a .dtsi file. One could in theory put
>> that data into the *-u-boot.dtsi file, but it's more convenient to be
>> able to provide it externally: For example, when developing for a
>> customer, it's common to use a set of dummy keys for development,
>> while the consultants do not (and should not) have access to the
>> actual keys used in production. For such a setup, it's easier if the
>> keys used are chosen via the meta-buildsystem and the path(s) patched
>> in during the configure step. And of course, nothing prevents anybody
>> from having DEVICE_TREE_INCLUDES point at files maintained in git, or
>> for that matter from including the public key metadata in the
>> *-u-boot.dtsi directly and ignore this feature.
>>
>> There are other uses for this, e.g. in combination with ENV_IMPORT_FDT
>> it can be used for providing the contents of the /config/environment
>> node, so I don't want to tie this exclusively to use for verified
>> boot.
>>
>> Signed-off-by: Rasmus Villemoes
>> ---
>>
>> Getting the public key metadata into .dtsi form can be done with a
>> little scripting (roughly 'mkimage -K' of a dummy image followed by
>> 'dtc -I dtb -O dts'). I have a script that does that, along with
>> options to set 'required' and 'required-mode' properties, include
>> u-boot,dm-spl properties in case one wants to check U-Boot proper from
>> SPL with the verified boot mechanism, etc. I'm happy to share that
>> script if this gets accepted, but it's moot if this is rejected.
>>
>> I have previously tried to get an fdt_add_pubkey tool accepted [1,2]
>> to disentangle the kernel and u-boot builds (or u-boot and SPL builds
>> for that matter!), but as I've since realized, that isn't quite enough
>> - the above points re modifying the .dtb after it is created but
>> before that is used to create further build artifacts still
>> stand. However, such a tool could still be useful for creating the
>> .dtsi info without the private keys being present, and my key2dtsi.sh
>> script could easily be modified to use a tool like that should it ever
>> appear.
>>
>> [1]
>> https://lore.kernel.org/u-boot/20200211094818.14219-3-rasmus.villem...@prevas.dk/
>> [2]
>> https://lore.kernel.org/u-boot/2184f1e6dd6247e48133c76205fee...@kaspersky.com/
>>
>> dts/Kconfig | 9 +
>> scripts/Makefile.lib | 2 ++
>> 2 files changed, 11 insertions(+)
>
> Reviewed-by: Simon Glass
>
> I suggest adding this to the documentation somewhere in
> doc/develop/devicetree/
Will do.
> Getting the key into the U-Boot .dtb is normally done with mkimage, as
> you say. I don't really understand why this approach is easier.
I think I explained that in the commit message, but let me try with a
more concrete example. I'm building, using Yocto as the umbrella build
system, for a SOC that needs an SPL + U-Boot proper.
So I have a U-Boot recipe that handles the configuration and
compilation. That's mostly a matter of "make foo_defconfig" followed by
"make ${UBOOT_TARGETS}" where UBOOT_TARGETS is something set in the
machine config. That results in two artifacts, say SPL and u-boot.itb
(the names don't really matter) that are almost ready to be written to
whatever storage is used for them. Most likely, the SPL binary is built
from a u-boot-spl-nodtb.bin and a spl.dtb and perhaps there's some
SOC-specific header in front of it all that the hardware/firmware needs,
those details are hidden by U-Boot's build system invoking the right
flavour of mkimage with the right parameters. If I really want to know,
I can look in spl/.SPL.cmd to see just how it was made
Re: [PATCH] arm: dts: stm32mp15: alignment with v5.15-rc6
Hi Patrick
On 10/21/21 11:54 AM, Patrick Delaunay wrote:
> Device tree alignment with Linux kernel v5.15-rc6
> - Set {bitclock,frame}-master phandles on ST DKx
> - Add coprocessor detach mbox on stm32mp15x-dkx boards
> - Add coprocessor detach mbox on stm32mp157c-ed1 board
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp157c-ed1.dts | 4 ++--
> arch/arm/dts/stm32mp15xx-dkx.dtsi | 12 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index 6e89f88a17..f62b46b8dd 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -321,8 +321,8 @@
> _rproc {
> memory-region = <>, <>, <>, <>,
> <>, <>;
> - mboxes = < 0>, < 1>, < 2>;
> - mbox-names = "vq0", "vq1", "shutdown";
> + mboxes = < 0>, < 1>, < 2>, < 3>;
> + mbox-names = "vq0", "vq1", "shutdown", "detach";
> interrupt-parent = <>;
> interrupts = <68 1>;
> status = "okay";
> diff --git a/arch/arm/dts/stm32mp15xx-dkx.dtsi
> b/arch/arm/dts/stm32mp15xx-dkx.dtsi
> index 68987f64c5..8fc93b0f94 100644
> --- a/arch/arm/dts/stm32mp15xx-dkx.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dkx.dtsi
> @@ -228,15 +228,15 @@
> cs42l51_tx_endpoint: endpoint@0 {
> reg = <0>;
> remote-endpoint = <_endpoint>;
> - frame-master;
> - bitclock-master;
> + frame-master = <_tx_endpoint>;
> + bitclock-master = <_tx_endpoint>;
> };
>
> cs42l51_rx_endpoint: endpoint@1 {
> reg = <1>;
> remote-endpoint = <_endpoint>;
> - frame-master;
> - bitclock-master;
> + frame-master = <_rx_endpoint>;
> + bitclock-master = <_rx_endpoint>;
> };
> };
> };
> @@ -478,8 +478,8 @@
> _rproc {
> memory-region = <>, <>, <>, <>,
> <>, <>;
> - mboxes = < 0>, < 1>, < 2>;
> - mbox-names = "vq0", "vq1", "shutdown";
> + mboxes = < 0>, < 1>, < 2>, < 3>;
> + mbox-names = "vq0", "vq1", "shutdown", "detach";
> interrupt-parent = <>;
> interrupts = <68 1>;
> status = "okay";
>
Reviewed-by: Patrice Chotard
Thanks
Patrice
Re: [PATCH v4 2/4] mtd: spi-nor-core: Adding different type of command extension in Soft Reset
>
> On 25/10/21 12:30PM, Jagan Teki wrote:
> > On Mon, Oct 18, 2021 at 11:54 AM JaimeLiao wrote:
> > >
> > > Power-on-Reset is a method to restore flash back to 1S-1S-1S mode from
> > > 8D-8D-8D
> > > in the begging of probe.
> > >
> > > Command extension type is not standardized across flash vendors in DTR
> > > mode.
> > >
> > > For suiting different vendor flash devices, adding a flag to seperate
> > > types for
> > > soft reset on boot.
> > >
> > > Signed-off-by: JaimeLiao
> > > ---
> > > drivers/mtd/spi/Kconfig| 7 +++
> > > drivers/mtd/spi/spi-nor-core.c | 7 ++-
> > > 2 files changed, 13 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
> > > index 67599b32c9..8304d6c973 100644
> > > --- a/drivers/mtd/spi/Kconfig
> > > +++ b/drivers/mtd/spi/Kconfig
> > > @@ -97,6 +97,13 @@ config SPI_FLASH_SMART_HWCAPS
> > > can support a type of operation in a much more refined way
> > > compared
> > > to using flags like SPI_RX_DUAL, SPI_TX_QUAD, etc.
> > >
> > > +config SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT
> > > + bool "Command extension type is INVERT for Software Reset on boot"
> > > + default n
> > > + help
> > > +Because of SFDP information can not be get before boot.
> > > +So define command extension type is INVERT when Software Reset
> > > on boot only.
> > > +
> > > config SPI_FLASH_SOFT_RESET
> > > bool "Software Reset support for SPI NOR flashes"
> > > default n
> > > diff --git a/drivers/mtd/spi/spi-nor-core.c
> > > b/drivers/mtd/spi/spi-nor-core.c
> > > index fdaca0a0d3..87a7de7d60 100644
> > > --- a/drivers/mtd/spi/spi-nor-core.c
> > > +++ b/drivers/mtd/spi/spi-nor-core.c
> > > @@ -3661,7 +3661,12 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> > > enum spi_nor_cmd_ext ext;
> > >
> > > ext = nor->cmd_ext_type;
> > > - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > + if (nor->cmd_ext_type == SPI_NOR_EXT_NONE) {
> > > + nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
> > > +#if CONFIG_IS_ENABLED(SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT)
> > > + nor->cmd_ext_type = SPI_NOR_EXT_INVERT;
> > > +#endif /* SPI_NOR_BOOT_SOFT_RESET_EXT_INVERT */
> >
> > I think we can get the SPI_NOR_EXT_INVERT by parsing bfpt, can you try
> > it that way instead of new macro?
>
> The problem is that for OSPI boot mode the ROM can often leave the flash
> in 8D-8D-8D mode. So when U-Boot first starts executing the flash is
> already in 8D-8D-8D mode and there is no easy and reliable way to detect
> this mode. So we must blindly perform a soft reset before probing the
> flash and reading SFDP so that it is reset back to a usable state.
>
> This is why we can't detect the extension via BFPT since the flash is in
> an unknown state. This is not the case when resetting before booting the
> OS since at that point we have fully probed the flash. So I think this
> config must only be used for the reset at boot time. For later resets we
> should indeed use the extension provided by BFPT.
>
> This is a kinda hacky but I can't come up with a better alternative.
>
> Jamie,
>
> Below diff is what I have been suggesting you in my earlier replies.
> Note that this is just a quick and dirty implementation, I have not
> tested this at all. That is up to you to do. Please also test soft reset
> _after_ the probe is finished so we know that it works correctly when
> using data from BFPT as well.
>
> -- 8< --
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 4388a08a90..b0f22e0ce5 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -3616,10 +3616,6 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> {
> struct spi_mem_op op;
> int ret;
> - enum spi_nor_cmd_ext ext;
> -
> - ext = nor->cmd_ext_type;
> - nor->cmd_ext_type = SPI_NOR_EXT_REPEAT;
>
> op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRSTEN,
> 0),
> SPI_MEM_OP_NO_DUMMY,
> @@ -3629,7 +3625,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, );
> if (ret) {
> dev_warn(nor->dev, "Software reset enable failed: %d\n", ret);
> - goto out;
> + return ret;
> }
>
> op = (struct spi_mem_op)SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_SRST, 0),
> @@ -3640,7 +3636,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> ret = spi_mem_exec_op(nor->spi, );
> if (ret) {
> dev_warn(nor->dev, "Software reset failed: %d\n", ret);
> - goto out;
> + return ret;
> }
>
> /*
> @@ -3650,9 +3646,7 @@ static int spi_nor_soft_reset(struct spi_nor *nor)
> */
> udelay(SPI_NOR_SRST_SLEEP_LEN);
>
> -out:
> - nor->cmd_ext_type = ext;
> - return ret;
> +
Re: [PATCH v4 4/4] mtd: spi-nor-core: Add support for Macronix Octal flash
>
> On 18/10/21 02:24PM, JaimeLiao wrote:
> > Adding Macronix Octal flash for Octal DTR support.
> >
> > The octaflash series can be divided into the following types:
> >
> > MX25 series : Serial NOR Flash.
> > MX66 series : Serial NOR Flash with stacked die.(Size larger than 1Gb)
> > LM/UM series : Up to 250MHz clock frequency with both DTR/STR operation.
> > LW/UW series : Support simultaneous Read-while-Write operation in multiple
> >bank architecture. Read-while-write feature which means read
> >data one bank while another bank is programing or erasing.
> >
> > MX25LM : 3.0V Octal I/O
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7841/MX25LM51245G,%203V,%20512Mb,%20v1.1.pdf
> >
> > MX25UM : 1.8V Octal I/O
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7525/MX25UM51245G%20Extreme%20Speed,%201.8V,%20512Mb,%20v1.0.pdf
> >
> > MX66LM : 3.0V Octal I/O with stacked die
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7929/MX66LM1G45G,%203V,%201Gb,%20v1.1.pdf
> >
> > MX66UM : 1.8V Octal I/O with stacked die
> >
> > -https://www.mxic.com.tw/Lists/Datasheet/Attachments/7721/MX66UM1G45G,%201.8V,%201Gb,%20v1.1.pdf
> >
> > MX25LW : 3.0V Octal I/O with Read-while-Write
> > MX25UW : 1.8V Octal I/O with Read-while-Write
> > MX66LW : 3.0V Octal I/O with Read-while-Write and stack die
> > MX66UW : 1.8V Octal I/O with Read-while-Write and stack die
> >
> > About LW/UW series, please contact us freely if you have any
> > questions. For adding Octal NOR Flash IDs, we have validated
> > each Flash on plateform zynq-picozed.
> >
> > Signed-off-by: JaimeLiao
> > ---
> > drivers/mtd/spi/spi-nor-ids.c | 22 +-
> > 1 file changed, 21 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index cb3a08872d..5c13ea3a78 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -169,7 +169,27 @@ const struct flash_info spi_nor_ids[] = {
> > { INFO("mx66l1g45g", 0xc2201b, 0, 64 * 1024, 2048, SECT_4K |
> > SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
> > { INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ
> > | SPI_NOR_4B_OPCODES | SECT_4K) },
> > { INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
> > - { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
>
> Why are you changing the name of this flash?
>
> Other than this, the patch looks good to me.
MX66UW2G345G is similar to MX66UW2G345GX0 and MX66UW2G345G's device ID
is 0xc2843c actually.
So that I correct it and add MX66UW2G345GX0 in IDs table.
>
> > + { INFO("mx66lm1g45g",0xc2853b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm51245g", 0xc2853a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lw51245g", 0xc2863a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25lm25645g", 0xc28539, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um2g45g",0xc2803c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw2g345g", 0xc2843c, 0, 64 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66um1g45g",0xc2803b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx66uw1g45g",0xc2813b, 0, 32 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um51245g", 0xc2803a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51245g", 0xc2813a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw51345g", 0xc2843a, 0, 16 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25645g", 0xc28039, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25645g", 0xc28139, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25um25345g", 0xc28339, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw25345g", 0xc28439, 0, 8 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12845g", 0xc28138, 0, 4 * 1024, 4096, SECT_4K |
> > SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
> > + { INFO("mx25uw12a45g", 0xc28938, 0, 4 * 1024, 4096, SECT_4K |
> >
Re: [PATCH v4 3/4] mtd: spi-nor-core: set 4byte opcode when possible
> > On 18/10/21 02:24PM, JaimeLiao wrote: > > Following linux kernel to check address width and 4byte flag to enable > > 4byte opcode setting. > > > > Signed-off-by: JaimeLiao > > --- > > drivers/mtd/spi/spi-nor-core.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c > > index 87a7de7d60..7d6671ade2 100644 > > --- a/drivers/mtd/spi/spi-nor-core.c > > +++ b/drivers/mtd/spi/spi-nor-core.c > > @@ -3902,6 +3902,10 @@ int spi_nor_scan(struct spi_nor *nor) > > return -EINVAL; > > } > > > > + /* Set 4byte opcodes when possible. */ > > + if (nor->addr_width == 4 && info->flags & SPI_NOR_4B_OPCODES) > > + spi_nor_set_4byte_opcodes(nor, info); > > + > > I still don't think this is the right thing to do. You should rework the > previous check for SPI_NOR_4B_OPCODES to fit whatever your flash needs > instead of adding it again. You are right, 3 byte command can be accepted after SPINOR_OP_EN4B. I will remove this part in patch next revision. > > > /* Send all the required SPI flash commands to initialize device */ > > ret = spi_nor_init(nor); > > if (ret) > > -- > > 2.17.1 > > > > -- > Regards, > Pratyush Yadav > Texas Instruments Inc.
[PATCH v4 16/16] update CAAM MAINTAINER
Signed-off-by: Gaurav Jain --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5069f18806..12a304bcb6 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1276,3 +1276,10 @@ T: git https://source.denx.de/u-boot/u-boot.git F: configs/tools-only_defconfig F: * F: */ + +CAAM +M: Gaurav Jain +S: Maintained +F: drivers/crypto/fsl/ +F: include/fsl_sec.h +F: cmd/blob.c -- 2.17.1
[PATCH v4 15/16] PPC: Enable Job ring driver model in U-Boot
removed sec_init() call and CONFIG_FSL_CAAM from defconfig. sec is initialized based on job ring information processed from device tree. Signed-off-by: Gaurav Jain Reviewed-by: Priyanka Jain --- arch/powerpc/cpu/mpc85xx/Kconfig | 44 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 17 +-- arch/powerpc/include/asm/u-boot-ppc.h | 17 +++ arch/powerpc/include/asm/u-boot.h | 1 + configs/P2041RDB_defconfig| 1 - configs/P3041DS_defconfig | 1 - configs/P4080DS_defconfig | 1 - configs/P5040DS_defconfig | 1 - configs/T1024RDB_defconfig| 1 - configs/T1042D4RDB_defconfig | 1 - configs/T2080QDS_defconfig| 1 - configs/T2080RDB_defconfig| 1 - configs/T4240RDB_defconfig| 1 - 13 files changed, 77 insertions(+), 11 deletions(-) create mode 100644 arch/powerpc/include/asm/u-boot-ppc.h diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig index 836aeddbe2..aaf599f616 100644 --- a/arch/powerpc/cpu/mpc85xx/Kconfig +++ b/arch/powerpc/cpu/mpc85xx/Kconfig @@ -25,6 +25,10 @@ config TARGET_P3041DS select PHYS_64BIT select ARCH_P3041 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -33,6 +37,10 @@ config TARGET_P4080DS select PHYS_64BIT select ARCH_P4080 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -41,6 +49,10 @@ config TARGET_P5040DS select PHYS_64BIT select ARCH_P5040 select BOARD_LATE_INIT if CHAIN_OF_TRUST + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -102,6 +114,10 @@ config TARGET_P2041RDB select ARCH_P2041 select BOARD_LATE_INIT if CHAIN_OF_TRUST select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply FSL_SATA @@ -117,6 +133,10 @@ config TARGET_T1024RDB select SUPPORT_SPL select PHYS_64BIT select FSL_DDR_INTERACTIVE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_EEPROM imply PANIC_HANG @@ -126,6 +146,10 @@ config TARGET_T1042RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT config TARGET_T1042D4RDB bool "Support T1042D4RDB" @@ -133,6 +157,10 @@ config TARGET_T1042D4RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply PANIC_HANG config TARGET_T1042RDB_PI @@ -141,6 +169,10 @@ config TARGET_T1042RDB_PI select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply PANIC_HANG config TARGET_T2080QDS @@ -151,6 +183,10 @@ config TARGET_T2080QDS select PHYS_64BIT select FSL_DDR_FIRST_SLOT_QUAD_CAPABLE select FSL_DDR_INTERACTIVE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA config TARGET_T2080RDB @@ -159,6 +195,10 @@ config TARGET_T2080RDB select BOARD_LATE_INIT if CHAIN_OF_TRUST select SUPPORT_SPL select PHYS_64BIT + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG @@ -168,6 +208,10 @@ config TARGET_T4240RDB select SUPPORT_SPL select PHYS_64BIT select FSL_DDR_FIRST_SLOT_QUAD_CAPABLE + select FSL_CAAM + select FSL_BLOB + select MISC + select ARCH_MISC_INIT imply CMD_SATA imply PANIC_HANG diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index e920e01b25..728c6447a8 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -56,6 +56,7 @@ #ifdef CONFIG_U_QE #include #endif +#include #ifdef CONFIG_SYS_FSL_SINGLE_SOURCE_CLK /* @@ -974,8 +975,6 @@ int cpu_init_r(void) #endif #ifdef CONFIG_FSL_CAAM - sec_init(); - #if defined(CONFIG_ARCH_C29X) if ((SVR_SOC_VER(svr) == SVR_C292) || (SVR_SOC_VER(svr) == SVR_C293)) @@ -1014,6 +1013,20 @@ int cpu_init_r(void) return 0; } +#ifdef
[PATCH v4 14/16] PPC: Add crypto node in device tree
device tree imported from linux kernel.
c500bee1c5b2 (tag: v5.14-rc4) Linux 5.14-rc4
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/powerpc/dts/p2041si-post.dtsi | 1 +
arch/powerpc/dts/p3041si-post.dtsi | 1 +
arch/powerpc/dts/p4080si-post.dtsi | 1 +
arch/powerpc/dts/p5040si-post.dtsi | 1 +
arch/powerpc/dts/qoriq-sec4.0-0.dtsi | 74 ++
arch/powerpc/dts/qoriq-sec4.2-0.dtsi | 83 +
arch/powerpc/dts/qoriq-sec5.2-0.dtsi | 92
arch/powerpc/dts/t1023si-post.dtsi | 1 +
arch/powerpc/dts/t1042si-post.dtsi | 1 +
arch/powerpc/dts/t2080si-post.dtsi | 1 +
arch/powerpc/dts/t4240si-post.dtsi | 1 +
11 files changed, 257 insertions(+)
create mode 100644 arch/powerpc/dts/qoriq-sec4.0-0.dtsi
create mode 100644 arch/powerpc/dts/qoriq-sec4.2-0.dtsi
create mode 100644 arch/powerpc/dts/qoriq-sec5.2-0.dtsi
diff --git a/arch/powerpc/dts/p2041si-post.dtsi
b/arch/powerpc/dts/p2041si-post.dtsi
index 01ab395950..8819199646 100644
--- a/arch/powerpc/dts/p2041si-post.dtsi
+++ b/arch/powerpc/dts/p2041si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p3041si-post.dtsi
b/arch/powerpc/dts/p3041si-post.dtsi
index 21f322f06f..a3e8088d25 100644
--- a/arch/powerpc/dts/p3041si-post.dtsi
+++ b/arch/powerpc/dts/p3041si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p4080si-post.dtsi
b/arch/powerpc/dts/p4080si-post.dtsi
index 7c3f2fb92e..56b79b14f4 100644
--- a/arch/powerpc/dts/p4080si-post.dtsi
+++ b/arch/powerpc/dts/p4080si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec4.0-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/p5040si-post.dtsi
b/arch/powerpc/dts/p5040si-post.dtsi
index 1efad2d017..fae3ed31a5 100644
--- a/arch/powerpc/dts/p5040si-post.dtsi
+++ b/arch/powerpc/dts/p5040si-post.dtsi
@@ -11,6 +11,7 @@
/include/ "qoriq-clockgen1.dtsi"
/include/ "qoriq-gpio-0.dtsi"
+/include/ "qoriq-sec5.2-0.dtsi"
/* include used FMan blocks */
/include/ "qoriq-fman-0.dtsi"
diff --git a/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
b/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
new file mode 100644
index 00..ff348d70f1
--- /dev/null
+++ b/arch/powerpc/dts/qoriq-sec4.0-0.dtsi
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-3-Clause)
+/*
+ * QorIQ Sec/Crypto 4.0 device tree stub [ controller @ offset 0x30 ]
+ *
+ * Copyright 2011 Freescale Semiconductor Inc.
+ */
+
+crypto: crypto@30 {
+ compatible = "fsl,sec-v4.0";
+ fsl,sec-era = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x30 0x1>;
+ ranges = <0 0x30 0x1>;
+ interrupts = <92 2 0 0>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <88 2 0 0>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <89 2 0 0>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <90 2 0 0>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <91 2 0 0>;
+ };
+
+ rtic@6000 {
+ compatible = "fsl,sec-v4.0-rtic";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6000 0x100>;
+ ranges = <0x0 0x6100 0xe00>;
+
+ rtic_a: rtic-a@0 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x00 0x20 0x100 0x80>;
+ };
+
+ rtic_b: rtic-b@20 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x20 0x20 0x200 0x80>;
+ };
+
+ rtic_c: rtic-c@40 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x40 0x20 0x300 0x80>;
+ };
+
+ rtic_d: rtic-d@60 {
+ compatible = "fsl,sec-v4.0-rtic-memory";
+ reg = <0x60 0x20 0x500 0x80>;
+ };
+ };
+};
+
+sec_mon: sec_mon@314000 {
+ compatible = "fsl,sec-v4.0-mon";
+ reg = <0x314000 0x1000>;
+ interrupts = <93 2 0 0>;
+};
diff --git a/arch/powerpc/dts/qoriq-sec4.2-0.dtsi
[PATCH v4 13/16] Layerscape: Enable Job ring driver model in U-Boot.
LS(1021/1012/1028/1043/1046/1088/2088), LX2160, LX2162
platforms are enabled with JR driver model.
removed sec_init() call from board files.
removed CONFIG_FSL_CAAM from defconfig files.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/arm/cpu/armv7/ls102xa/Kconfig| 4 +++
arch/arm/cpu/armv7/ls102xa/cpu.c | 16 +++
arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 27 +++
arch/arm/cpu/armv8/fsl-layerscape/cpu.c | 10 ++-
board/freescale/ls1012afrdm/ls1012afrdm.c | 7 +
board/freescale/ls1012aqds/ls1012aqds.c | 6 +
board/freescale/ls1012ardb/ls1012ardb.c | 6 +
board/freescale/ls1021aiot/ls1021aiot.c | 6 ++---
board/freescale/ls1021aqds/ls1021aqds.c | 6 +
board/freescale/ls1021atsn/ls1021atsn.c | 7 ++---
board/freescale/ls1021atwr/ls1021atwr.c | 8 ++
board/freescale/ls1028a/ls1028a.c | 6 +
board/freescale/ls1043ardb/ls1043ardb.c | 6 +
board/freescale/ls1046afrwy/ls1046afrwy.c | 7 +
board/freescale/ls1046aqds/ls1046aqds.c | 7 +
board/freescale/ls1046ardb/ls1046ardb.c | 6 +
board/freescale/ls1088a/ls1088a.c | 6 +
board/freescale/ls2080aqds/ls2080aqds.c | 6 +
board/freescale/ls2080ardb/ls2080ardb.c | 9 +--
board/freescale/lx2160a/lx2160a.c | 5
configs/ls1021aiot_qspi_defconfig | 1 -
configs/ls1021aqds_nor_defconfig | 1 -
configs/ls1021aqds_qspi_defconfig | 1 -
configs/ls1021atsn_qspi_defconfig | 1 -
configs/ls1021atwr_nor_defconfig | 1 -
...s1021atwr_sdcard_ifc_SECURE_BOOT_defconfig | 1 +
configs/ls1028ardb_tfa_defconfig | 1 -
configs/ls1043ardb_tfa_defconfig | 1 -
configs/ls1046afrwy_tfa_defconfig | 1 -
configs/ls1046aqds_tfa_defconfig | 1 -
configs/ls1046ardb_tfa_defconfig | 1 -
configs/ls2088aqds_tfa_defconfig | 1 -
configs/ls2088ardb_tfa_defconfig | 1 -
configs/lx2160aqds_tfa_defconfig | 1 -
configs/lx2160ardb_tfa_defconfig | 1 -
configs/lx2162aqds_tfa_defconfig | 1 -
36 files changed, 75 insertions(+), 102 deletions(-)
diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index f919d02db4..8e8fb4e9db 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -21,6 +21,10 @@ config ARCH_LS1021A
select SYS_FSL_SRDS_1
select SYS_HAS_SERDES
select SYS_I2C_MXC
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply CMD_PCI
imply SCSI
imply SCSI_AHCI
diff --git a/arch/arm/cpu/armv7/ls102xa/cpu.c b/arch/arm/cpu/armv7/ls102xa/cpu.c
index d863c9625a..4904592703 100644
--- a/arch/arm/cpu/armv7/ls102xa/cpu.c
+++ b/arch/arm/cpu/armv7/ls102xa/cpu.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -20,6 +21,7 @@
#include
#include
#include
+#include
#include "fsl_epu.h"
@@ -397,3 +399,17 @@ void arch_preboot_os(void)
ctrl &= ~ARCH_TIMER_CTRL_ENABLE;
asm("mcr p15, 0, %0, c14, c2, 1" : : "r" (ctrl));
}
+
+#ifdef CONFIG_ARCH_MISC_INIT
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 1e166c73e4..2531a9fa0d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -20,6 +20,10 @@ config ARCH_LS1012A
select SYS_I2C_MXC
select SYS_I2C_MXC_I2C1 if !DM_I2C
select SYS_I2C_MXC_I2C2 if !DM_I2C
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply PANIC_HANG
config ARCH_LS1028A
@@ -53,6 +57,9 @@ config ARCH_LS1028A
select SYS_FSL_ERRATUM_A011334
select SYS_FSL_ESDHC_UNRELIABLE_PULSE_DETECTION_WORKAROUND
select RESV_RAM if GIC_V3_ITS
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
imply PANIC_HANG
config ARCH_LS1043A
@@ -88,6 +95,10 @@ config ARCH_LS1043A
select SYS_I2C_MXC_I2C2 if !DM_I2C
select SYS_I2C_MXC_I2C3 if !DM_I2C
select SYS_I2C_MXC_I2C4 if !DM_I2C
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
imply CMD_PCI
imply ID_EEPROM
@@ -125,6 +136,10 @@ config ARCH_LS1046A
[PATCH v4 12/16] Layerscape: Add crypto node in device tree
LS(1021/1012/1028/1043/1046/1088/2088), LX2160 - updated device tree
Signed-off-by: Gaurav Jain
Reviewed-by: Priyanka Jain
---
arch/arm/dts/fsl-ls1012a.dtsi | 46 ++-
arch/arm/dts/fsl-ls1043a.dtsi | 45 +-
arch/arm/dts/fsl-ls1046a.dtsi | 44 +
arch/arm/dts/fsl-ls1088a.dtsi | 39 +
arch/arm/dts/fsl-ls2080a.dtsi | 39 +
arch/arm/dts/fsl-lx2160a.dtsi | 41 ++-
arch/arm/dts/ls1021a.dtsi | 40 ++
7 files changed, 291 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1012a.dtsi b/arch/arm/dts/fsl-ls1012a.dtsi
index 2894842cf2..20ef111d27 100644
--- a/arch/arm/dts/fsl-ls1012a.dtsi
+++ b/arch/arm/dts/fsl-ls1012a.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+ OR X11
/*
- * Copyright 2020 NXP
+ * Copyright 2020-2021 NXP
* Copyright 2016 Freescale Semiconductor
*/
@@ -71,6 +71,50 @@
bus-width = <4>;
};
+ crypto: crypto@170 {
+ compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
+"fsl,sec-v4.0";
+ fsl,sec-era = <8>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x170 0x10>;
+ reg = <0x00 0x170 0x0 0x10>;
+ interrupts = <0 75 0x4>;
+ dma-coherent;
+
+ sec_jr0: jr@1 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x1 0x1>;
+ interrupts = <0 71 0x4>;
+ };
+
+ sec_jr1: jr@2 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x2 0x1>;
+ interrupts = <0 72 0x4>;
+ };
+
+ sec_jr2: jr@3 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x3 0x1>;
+ interrupts = <0 73 0x4>;
+ };
+
+ sec_jr3: jr@4 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x4 0x1>;
+ interrupts = <0 74 0x4>;
+ };
+ };
+
gpio0: gpio@230 {
compatible = "fsl,qoriq-gpio";
reg = <0x0 0x230 0x0 0x1>;
diff --git a/arch/arm/dts/fsl-ls1043a.dtsi b/arch/arm/dts/fsl-ls1043a.dtsi
index d8171bd03b..51d556e43d 100644
--- a/arch/arm/dts/fsl-ls1043a.dtsi
+++ b/arch/arm/dts/fsl-ls1043a.dtsi
@@ -2,7 +2,7 @@
/*
* Device Tree Include file for NXP Layerscape-1043A family SoC.
*
- * Copyright 2020 NXP
+ * Copyright 2020-2021 NXP
* Copyright (C) 2014-2015, Freescale Semiconductor
*
* Mingkai Hu
@@ -125,6 +125,49 @@
interrupts = <0 43 0x4>;
};
+ crypto: crypto@170 {
+ compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
+"fsl,sec-v4.0";
+ fsl,sec-era = <3>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x170 0x10>;
+ reg = <0x00 0x170 0x0 0x10>;
+ interrupts = <0 75 0x4>;
+
+ sec_jr0: jr@1 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+"fsl,sec-v4.0-job-ring";
+ reg= <0x1 0x1>;
+ interrupts = <0 71 0x4>;
+ };
+
+ sec_jr1: jr@2 {
+ compatible = "fsl,sec-v5.4-job-ring",
+"fsl,sec-v5.0-job-ring",
+
[PATCH v4 09/16] i.MX8: Add crypto node in device tree
i.MX8(QM/QXP) - updated device tree for supporting DM in SPL.
disabled use of JR1 in SPL and uboot, as JR1 is reserved
for SECO FW.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/dts/fsl-imx8dx.dtsi | 61 +++-
arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi | 34 -
arch/arm/dts/fsl-imx8qm.dtsi | 61 +++-
arch/arm/dts/fsl-imx8qxp-mek-u-boot.dtsi | 34 -
4 files changed, 186 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/fsl-imx8dx.dtsi b/arch/arm/dts/fsl-imx8dx.dtsi
index 7d95cf0b7d..63a56699b5 100644
--- a/arch/arm/dts/fsl-imx8dx.dtsi
+++ b/arch/arm/dts/fsl-imx8dx.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -261,6 +261,30 @@
power-domains = <_dma>;
};
};
+
+ pd_caam: PD_CAAM {
+ compatible = "nxp,imx8-pd";
+ reg = ;
+ #power-domain-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_caam_jr1: PD_CAAM_JR1 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <_caam>;
+ };
+ pd_caam_jr2: PD_CAAM_JR2 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <_caam>;
+ };
+ pd_caam_jr3: PD_CAAM_JR3 {
+ reg = ;
+ #power-domain-cells = <0>;
+ power-domains = <_caam>;
+ };
+ };
};
i2c0: i2c@5a80 {
@@ -609,6 +633,41 @@
};
};
};
+
+ crypto: caam@0x3140 {
+ compatible = "fsl,sec-v4.0";
+ reg = <0 0x3140 0 0x40>;
+ interrupts = ;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0 0x3140 0x40>;
+ fsl,first-jr-index = <2>;
+ fsl,sec-era = <9>;
+
+ sec_jr1: jr1@0x2 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2 0x1000>;
+ interrupts = ;
+ power-domains = <_caam_jr1>;
+ status = "disabled";
+ };
+
+ sec_jr2: jr2@3 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3 0x1000>;
+ interrupts = ;
+ power-domains = <_caam_jr2>;
+ status = "okay";
+ };
+
+ sec_jr3: jr3@4 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4 0x1000>;
+ interrupts = ;
+ power-domains = <_caam_jr3>;
+ status = "okay";
+ };
+ };
};
_0 {
diff --git a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
index 9e0d264b71..a95209e141 100644
--- a/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
+++ b/arch/arm/dts/fsl-imx8qm-mek-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
&{/imx8qm-pm} {
@@ -80,6 +80,22 @@
u-boot,dm-spl;
};
+_caam {
+ u-boot,dm-spl;
+};
+
+_caam_jr1 {
+ u-boot,dm-spl;
+};
+
+_caam_jr2 {
+ u-boot,dm-spl;
+};
+
+_caam_jr3 {
+ u-boot,dm-spl;
+};
+
{
u-boot,dm-spl;
};
@@ -126,3 +142,19 @@
sd-uhs-sdr104;
sd-uhs-ddr50;
};
+
+ {
+ u-boot,dm-spl;
+};
+
+_jr1 {
+ u-boot,dm-spl;
+};
+
+_jr2 {
+ u-boot,dm-spl;
+};
+
+_jr3 {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/fsl-imx8qm.dtsi b/arch/arm/dts/fsl-imx8qm.dtsi
index 88aeaf65b3..517fb13cad 100644
--- a/arch/arm/dts/fsl-imx8qm.dtsi
+++ b/arch/arm/dts/fsl-imx8qm.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -235,6 +235,30 @@
wakeup-irq = <349>;
};
};
+
+ pd_caam: PD_CAAM {
+ compatible = "nxp,imx8-pd";
+ reg = ;
+ #power-domain-cells = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_caam_jr1: PD_CAAM_JR1 {
+ reg = ;
+ #power-domain-cells = <0>;
+
[PATCH v4 11/16] crypto/fsl: Fix kick_trng
From: Ye Li
fix hwrng performance issue in kernel.
Signed-off-by: Ye Li
Acked-by: Gaurav Jain >
---
drivers/crypto/fsl/jr.c | 109 ++--
include/fsl_sec.h | 1 +
2 files changed, 94 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 0bfdf9070f..72f09a1d8b 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -602,30 +602,107 @@ static u8 get_rng_vid(ccsr_sec_t *sec)
*/
static void kick_trng(int ent_delay, ccsr_sec_t *sec)
{
+ u32 samples = 512; /* number of bits to generate and test */
+ u32 mono_min = 195;
+ u32 mono_max = 317;
+ u32 mono_range = mono_max - mono_min;
+ u32 poker_min = 1031;
+ u32 poker_max = 1600;
+ u32 poker_range = poker_max - poker_min + 1;
+ u32 retries= 2;
+ u32 lrun_max = 32;
+ s32 run_1_min = 27;
+ s32 run_1_max = 107;
+ s32 run_1_range = run_1_max - run_1_min;
+ s32 run_2_min = 7;
+ s32 run_2_max = 62;
+ s32 run_2_range = run_2_max - run_2_min;
+ s32 run_3_min = 0;
+ s32 run_3_max = 39;
+ s32 run_3_range = run_3_max - run_3_min;
+ s32 run_4_min = -1;
+ s32 run_4_max = 26;
+ s32 run_4_range = run_4_max - run_4_min;
+ s32 run_5_min = -1;
+ s32 run_5_max = 18;
+ s32 run_5_range = run_5_max - run_5_min;
+ s32 run_6_min = -1;
+ s32 run_6_max = 17;
+ s32 run_6_range = run_6_max - run_6_min;
+ u32 val;
+
struct rng4tst __iomem *rng =
(struct rng4tst __iomem *)>rng;
- u32 val;
- /* put RNG4 into program mode */
- sec_setbits32(>rtmctl, RTMCTL_PRGM);
- /* rtsdctl bits 0-15 contain "Entropy Delay, which defines the
-* length (in system clocks) of each Entropy sample taken
-* */
+ /* Put RNG in program mode */
+ /* Setting both RTMCTL:PRGM and RTMCTL:TRNG_ACC causes TRNG to
+* properly invalidate the entropy in the entropy register and
+* force re-generation.
+*/
+ sec_setbits32(>rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
+
+ /* Configure the RNG Entropy Delay
+* Performance-wise, it does not make sense to
+* set the delay to a value that is lower
+* than the last one that worked (i.e. the state handles
+* were instantiated properly. Thus, instead of wasting
+* time trying to set the values controlling the sample
+* frequency, the function simply returns.
+*/
val = sec_in32(>rtsdctl);
- val = (val & ~RTSDCTL_ENT_DLY_MASK) |
- (ent_delay << RTSDCTL_ENT_DLY_SHIFT);
+ val &= RTSDCTL_ENT_DLY_MASK;
+ val >>= RTSDCTL_ENT_DLY_SHIFT;
+ if (ent_delay < val) {
+ /* Put RNG4 into run mode */
+ sec_clrbits32(>rtmctl, RTMCTL_PRGM | RTMCTL_ACC);
+ return;
+ }
+
+ val = (ent_delay << RTSDCTL_ENT_DLY_SHIFT) | samples;
sec_out32(>rtsdctl, val);
- /* min. freq. count, equal to 1/4 of the entropy sample length */
- sec_out32(>rtfreqmin, ent_delay >> 2);
- /* disable maximum frequency count */
- sec_out32(>rtfreqmax, RTFRQMAX_DISABLE);
+
/*
-* select raw sampling in both entropy shifter
+* Recommended margins (min,max) for freq. count:
+* freq_mul = RO_freq / TRNG_clk_freq
+* rtfrqmin = (ent_delay x freq_mul) >> 1;
+* rtfrqmax = (ent_delay x freq_mul) << 3;
+* Given current deployments of CAAM in i.MX SoCs, and to simplify
+* the configuration, we consider [1,16] to be a safe interval
+* for the freq_mul and the limits of the interval are used to compute
+* rtfrqmin, rtfrqmax
+*/
+ sec_out32(>rtfreqmin, ent_delay >> 1);
+ sec_out32(>rtfreqmax, ent_delay << 7);
+
+ sec_out32(>rtscmisc, (retries << 16) | lrun_max);
+ sec_out32(>rtpkrmax, poker_max);
+ sec_out32(>rtpkrrng, poker_range);
+ sec_out32(>rsvd1[0], (mono_range << 16) | mono_max);
+ sec_out32(>rsvd1[1], (run_1_range << 16) | run_1_max);
+ sec_out32(>rsvd1[2], (run_2_range << 16) | run_2_max);
+ sec_out32(>rsvd1[3], (run_3_range << 16) | run_3_max);
+ sec_out32(>rsvd1[4], (run_4_range << 16) | run_4_max);
+ sec_out32(>rsvd1[5], (run_5_range << 16) | run_5_max);
+ sec_out32(>rsvd1[6], (run_6_range << 16) | run_6_max);
+
+ val = sec_in32(>rtmctl);
+ /*
+* Select raw sampling in both entropy shifter
* and statistical checker
*/
- sec_setbits32(>rtmctl, RTMCTL_SAMP_MODE_RAW_ES_SC);
- /* put RNG4 into run mode */
- sec_clrbits32(>rtmctl, RTMCTL_PRGM);
+ val &= ~RTMCTL_SAMP_MODE_INVALID;
+ val |= RTMCTL_SAMP_MODE_RAW_ES_SC;
+ /* Put RNG4 into run mode */
+ val &= ~(RTMCTL_PRGM | RTMCTL_ACC);
+ /*test with
[PATCH v4 10/16] crypto/fsl: i.MX8: Enable Job ring driver model in SPL and U-Boot.
i.MX8(QM/QXP) - added support for JR driver model.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Signed-off-by: Horia Geantă
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 3 +++
arch/arm/include/asm/arch-imx8/imx-regs.h | 5 -
arch/arm/mach-imx/cmd_dek.c | 1 +
arch/arm/mach-imx/imx8/Kconfig| 9 +
arch/arm/mach-imx/imx8/cpu.c | 16 ++-
board/freescale/imx8qm_mek/spl.c | 6 --
board/freescale/imx8qxp_mek/spl.c | 6 --
drivers/crypto/fsl/Kconfig| 2 +-
drivers/crypto/fsl/jr.c | 24 +++
include/fsl_sec.h | 12 +---
10 files changed, 70 insertions(+), 14 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 314e770931..9458ed7eb0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -806,6 +806,9 @@ config ARCH_LPC32XX
config ARCH_IMX8
bool "NXP i.MX8 platform"
select ARM64
+ select SYS_FSL_HAS_SEC
+ select SYS_FSL_SEC_COMPAT_4
+ select SYS_FSL_SEC_LE
select DM
select GPIO_EXTRA_HEADER
select MACH_IMX
diff --git a/arch/arm/include/asm/arch-imx8/imx-regs.h
b/arch/arm/include/asm/arch-imx8/imx-regs.h
index ed6e05e556..2d64b0604b 100644
--- a/arch/arm/include/asm/arch-imx8/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8/imx-regs.h
@@ -1,6 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#ifndef __ASM_ARCH_IMX8_REGS_H__
@@ -47,4 +47,7 @@
#define USB_BASE_ADDR 0x5b0d
#define USB_PHY0_BASE_ADDR 0x5b10
+#define CONFIG_SYS_FSL_SEC_ADDR (0x3140)
+#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 1
+
#endif /* __ASM_ARCH_IMX8_REGS_H__ */
diff --git a/arch/arm/mach-imx/cmd_dek.c b/arch/arm/mach-imx/cmd_dek.c
index 89da89c51d..04c4b20a84 100644
--- a/arch/arm/mach-imx/cmd_dek.c
+++ b/arch/arm/mach-imx/cmd_dek.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/arch/arm/mach-imx/imx8/Kconfig b/arch/arm/mach-imx/imx8/Kconfig
index b43739e5c6..9a20ebe84e 100644
--- a/arch/arm/mach-imx/imx8/Kconfig
+++ b/arch/arm/mach-imx/imx8/Kconfig
@@ -8,6 +8,7 @@ config AHAB_BOOT
config IMX8
bool
+ select HAS_CAAM
config MU_BASE_SPL
hex "MU base address used in SPL"
@@ -72,6 +73,10 @@ config TARGET_IMX8QM_MEK
bool "Support i.MX8QM MEK board"
select BOARD_LATE_INIT
select IMX8QM
+ select FSL_CAAM
+ select FSL_BLOB
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_CONGA_QMX8
bool "Support congatec conga-QMX8 board"
@@ -89,6 +94,10 @@ config TARGET_IMX8QXP_MEK
bool "Support i.MX8QXP MEK board"
select BOARD_LATE_INIT
select IMX8QXP
+ select FSL_CAAM
+ select FSL_BLOB
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
endchoice
diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index ee5cc47903..5140c93a37 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*/
#include
@@ -89,6 +89,20 @@ int arch_cpu_init_dm(void)
return 0;
}
+#if defined(CONFIG_ARCH_MISC_INIT)
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
+
int print_bootinfo(void)
{
enum boot_device bt_dev = get_boot_device();
diff --git a/board/freescale/imx8qm_mek/spl.c b/board/freescale/imx8qm_mek/spl.c
index 944ba745c0..332a662dee 100644
--- a/board/freescale/imx8qm_mek/spl.c
+++ b/board/freescale/imx8qm_mek/spl.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
- * SPDX-License-Identifier:GPL-2.0+
*/
#include
@@ -24,6 +24,8 @@ void spl_board_init(void)
{
struct udevice *dev;
+ uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(imx8_scu), );
+
uclass_find_first_device(UCLASS_MISC, );
for (; dev; uclass_find_next_device()) {
diff --git a/board/freescale/imx8qxp_mek/spl.c
b/board/freescale/imx8qxp_mek/spl.c
index ae6b64ff6e..2fa6840056 100644
--- a/board/freescale/imx8qxp_mek/spl.c
+++ b/board/freescale/imx8qxp_mek/spl.c
@@ -1,7 +1,7 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
- * SPDX-License-Identifier:GPL-2.0+
*/
#include
@@ -39,6 +39,8 @@ void spl_board_init(void)
{
struct udevice *dev;
+ uclass_get_device_by_driver(UCLASS_MISC,
[PATCH v4 08/16] i.MX7ULP: Enable Job ring driver model in U-Boot.
added crypto node in device tree.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/dts/imx7ulp.dtsi| 24
arch/arm/mach-imx/mx7ulp/Kconfig | 4
arch/arm/mach-imx/mx7ulp/soc.c | 16
4 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f73789a4f5..314e770931 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -872,7 +872,7 @@ config ARCH_MX7ULP
select CPU_V7A
select GPIO_EXTRA_HEADER
select MACH_IMX
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
select ROM_UNIFIED_SECTIONS
diff --git a/arch/arm/dts/imx7ulp.dtsi b/arch/arm/dts/imx7ulp.dtsi
index 7bcd2cc346..494b9d98b2 100644
--- a/arch/arm/dts/imx7ulp.dtsi
+++ b/arch/arm/dts/imx7ulp.dtsi
@@ -1,5 +1,6 @@
/*
* Copyright 2015-2016 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -198,6 +199,29 @@
};
};
+ crypto: crypto@4024 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x4024 0x1>;
+ ranges = <0 0x4024 0x1>;
+ clocks = < IMX7ULP_CLK_CAAM>,
+< IMX7ULP_CLK_NIC1_BUS_DIV>;
+ clock-names = "aclk", "ipg";
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = ;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = ;
+ };
+ };
+
tpm5: tpm@4026 {
compatible = "fsl,imx7ulp-tpm";
reg = <0x4026 0x1000>;
diff --git a/arch/arm/mach-imx/mx7ulp/Kconfig b/arch/arm/mach-imx/mx7ulp/Kconfig
index 2ffac9cf7c..0d9f8ffed9 100644
--- a/arch/arm/mach-imx/mx7ulp/Kconfig
+++ b/arch/arm/mach-imx/mx7ulp/Kconfig
@@ -25,6 +25,10 @@ config TARGET_MX7ULP_EVK
bool "Support mx7ulp EVK board"
select MX7ULP
select SYS_ARCH_TIMER
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
endchoice
diff --git a/arch/arm/mach-imx/mx7ulp/soc.c b/arch/arm/mach-imx/mx7ulp/soc.c
index c90ce22404..c1e55e7260 100644
--- a/arch/arm/mach-imx/mx7ulp/soc.c
+++ b/arch/arm/mach-imx/mx7ulp/soc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2016 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -15,6 +16,7 @@
#include
#include
#include
+#include
#define PMC0_BASE_ADDR 0x410a1000
#define PMC0_CTRL 0x28
@@ -80,6 +82,20 @@ int arch_cpu_init(void)
return 0;
}
+#if defined(CONFIG_ARCH_MISC_INIT)
+int arch_misc_init(void)
+{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_BOARD_POSTCLK_INIT
int board_postclk_init(void)
{
--
2.17.1
[PATCH v4 07/16] i.MX7: Enable Job ring driver model in U-Boot.
i.MX7D - added support for JR driver model.
removed sec_init() call, sec is initialized based on
job ring information processed from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/mach-imx/mx7/Kconfig | 3 +++
arch/arm/mach-imx/mx7/soc.c | 11 +++
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5791d7c293..f73789a4f5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -885,7 +885,7 @@ config ARCH_MX7
select CPU_V7A
select GPIO_EXTRA_HEADER
select MACH_IMX
- 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 BOARD_EARLY_INIT_F
diff --git a/arch/arm/mach-imx/mx7/Kconfig b/arch/arm/mach-imx/mx7/Kconfig
index 0cad825287..d8f748a544 100644
--- a/arch/arm/mach-imx/mx7/Kconfig
+++ b/arch/arm/mach-imx/mx7/Kconfig
@@ -68,6 +68,9 @@ config TARGET_MX7DSABRESD
select DM_THERMAL
select MX7D
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
config TARGET_PICO_IMX7D
bool "pico-imx7d"
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 21690072e1..6c991a6cb1 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright (C) 2015 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -19,7 +20,6 @@
#include
#include
#include
-#include
#include
#include
@@ -337,6 +337,9 @@ int arch_cpu_init(void)
#ifdef CONFIG_ARCH_MISC_INIT
int arch_misc_init(void)
{
+ struct udevice *dev;
+ int ret;
+
#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
struct tag_serialnr serialnr;
char serial_string[0x20];
@@ -353,9 +356,9 @@ int arch_misc_init(void)
env_set("serial#", serial_string);
#endif
-#ifdef CONFIG_FSL_CAAM
- sec_init();
-#endif
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
return 0;
}
--
2.17.1
[PATCH v4 06/16] i.MX6: Enable Job ring driver model in U-Boot.
i.MX6,i.MX6SX,i.MX6UL - added support for JR driver model.
removed sec_init() call, sec is initialized based on
job ring information processed from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/mach-imx/mx6/Kconfig | 20
arch/arm/mach-imx/mx6/soc.c | 12
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-imx/mx6/Kconfig b/arch/arm/mach-imx/mx6/Kconfig
index b4c8511cb8..0f40e84915 100644
--- a/arch/arm/mach-imx/mx6/Kconfig
+++ b/arch/arm/mach-imx/mx6/Kconfig
@@ -354,6 +354,10 @@ config TARGET_MX6SABREAUTO
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SABRESD
bool "mx6sabresd"
@@ -364,6 +368,10 @@ config TARGET_MX6SABRESD
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SLEVK
bool "mx6slevk"
@@ -386,6 +394,10 @@ config TARGET_MX6SXSABRESD
select DM
select DM_THERMAL
select SUPPORT_SPL
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6SXSABREAUTO
bool "mx6sxsabreauto"
@@ -404,6 +416,10 @@ config TARGET_MX6UL_9X9_EVK
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6UL_14X14_EVK
bool "mx6ul_14x14_evk"
@@ -413,6 +429,10 @@ config TARGET_MX6UL_14X14_EVK
select DM_THERMAL
select SUPPORT_SPL
imply CMD_DM
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
config TARGET_MX6UL_ENGICAM
bool "Support Engicam GEAM6UL/Is.IoT"
diff --git a/arch/arm/mach-imx/mx6/soc.c b/arch/arm/mach-imx/mx6/soc.c
index aacfc854a2..fa6c3778bb 100644
--- a/arch/arm/mach-imx/mx6/soc.c
+++ b/arch/arm/mach-imx/mx6/soc.c
@@ -4,6 +4,7 @@
* Sascha Hauer, Pengutronix
*
* (C) Copyright 2009 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*/
#include
@@ -23,7 +24,6 @@
#include
#include
#include
-#include
#include
#include
@@ -734,9 +734,13 @@ static void setup_serial_number(void)
int arch_misc_init(void)
{
-#ifdef CONFIG_FSL_CAAM
- sec_init();
-#endif
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
setup_serial_number();
return 0;
}
--
2.17.1
[PATCH v4 05/16] mx6sabre: Remove unnecessary SPL configs
From: Ye Li Because we don't use SPL_DM on mx6sabresd and mx6sabreauto, so it is unnecessary to have SPL DTB related configs and SPL_OF_CONTROL enabled. Signed-off-by: Ye Li Reviewed-by: Fabio Estevam Reviewed-by: Gaurav Jain --- configs/mx6sabreauto_defconfig | 2 -- configs/mx6sabresd_defconfig | 4 2 files changed, 6 deletions(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index 5fd0dee170..f2f9ffe0d8 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -60,10 +60,8 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="imx6dl-sabreauto imx6q-sabreauto imx6qp-sabreauto" CONFIG_MULTI_DTB_FIT=y -CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig index 676e8a928b..85668e6691 100644 --- a/configs/mx6sabresd_defconfig +++ b/configs/mx6sabresd_defconfig @@ -63,12 +63,8 @@ CONFIG_CMD_FS_GENERIC=y CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_OF_CONTROL=y -CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIST="imx6q-sabresd imx6qp-sabresd imx6dl-sabresd" CONFIG_MULTI_DTB_FIT=y -CONFIG_SPL_MULTI_DTB_FIT=y -CONFIG_SPL_OF_LIST="imx6dl-sabresd imx6q-sabresd imx6qp-sabresd" -CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y -- 2.17.1
[PATCH v4 04/16] crypto/fsl: i.MX8M: Enable Job ring driver model in SPL and U-Boot.
i.MX8MM/MN/MP/MQ - added support for JR driver model.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/Kconfig | 2 +-
arch/arm/include/asm/arch-imx8m/imx-regs.h | 1 +
arch/arm/mach-imx/imx8m/Kconfig| 23 ++
arch/arm/mach-imx/imx8m/soc.c | 10 +-
board/freescale/imx8mm_evk/spl.c | 9 -
board/freescale/imx8mn_evk/spl.c | 8 ++--
board/freescale/imx8mp_evk/spl.c | 13 ++--
board/freescale/imx8mq_evk/spl.c | 9 +++--
drivers/crypto/fsl/jr.c| 14 ++---
scripts/config_whitelist.txt | 1 +
10 files changed, 78 insertions(+), 12 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 02f8306f15..5791d7c293 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -817,7 +817,7 @@ config ARCH_IMX8M
select ARM64
select GPIO_EXTRA_HEADER
select MACH_IMX
- select SYS_FSL_HAS_SEC if IMX_HAB
+ select SYS_FSL_HAS_SEC
select SYS_FSL_SEC_COMPAT_4
select SYS_FSL_SEC_LE
select SYS_I2C_MXC
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index b800da13a1..ff8de53f67 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -72,6 +72,7 @@
#define CONFIG_SYS_FSL_SEC_ADDR (CAAM_IPS_BASE_ADDR + \
CONFIG_SYS_FSL_SEC_OFFSET)
#define CONFIG_SYS_FSL_JR0_OFFSET (0x1000)
+#define CONFIG_SYS_FSL_JR1_OFFSET (0x2000)
#define CONFIG_SYS_FSL_JR0_ADDR (CONFIG_SYS_FSL_SEC_ADDR + \
CONFIG_SYS_FSL_JR0_OFFSET)
#define CONFIG_SYS_FSL_MAX_NUM_OF_SEC 1
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 276b8bd974..4988171d2b 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -38,6 +38,11 @@ config TARGET_IMX8MQ_EVK
bool "imx8mq_evk"
select IMX8MQ
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MQ_PHANBELL
bool "imx8mq_phanbell"
@@ -50,6 +55,11 @@ config TARGET_IMX8MM_EVK
select IMX8MM
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MM_ICORE_MX8MM
bool "Engicam i.Core MX8M Mini SOM"
@@ -88,6 +98,10 @@ config TARGET_IMX8MN_EVK
select IMX8MN
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MN_DDR4_EVK
bool "imx8mn DDR4 EVK board"
@@ -95,6 +109,10 @@ config TARGET_IMX8MN_DDR4_EVK
select IMX8MN
select SUPPORT_SPL
select IMX8M_DDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select SPL_CRYPTO if SPL
config TARGET_IMX8MP_EVK
bool "imx8mp LPDDR4 EVK board"
@@ -102,6 +120,11 @@ config TARGET_IMX8MP_EVK
select IMX8MP
select SUPPORT_SPL
select IMX8M_LPDDR4
+ select FSL_CAAM
+ select FSL_BLOB
+ select MISC
+ select ARCH_MISC_INIT
+ select SPL_CRYPTO if SPL
config TARGET_PICO_IMX8MQ
bool "Support Technexion Pico iMX8MQ"
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 863508776d..0f9bd77354 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2017-2019 NXP
+ * Copyright 2017-2019, 2021 NXP
*
* Peng Fan
*/
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1197,6 +1198,13 @@ static void acquire_buildinfo(void)
int arch_misc_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+ printf("Failed to initialize %s: %d\n", dev->name, ret);
+
acquire_buildinfo();
return 0;
diff --git a/board/freescale/imx8mm_evk/spl.c b/board/freescale/imx8mm_evk/spl.c
index 4ef7f6f180..c81128f442 100644
--- a/board/freescale/imx8mm_evk/spl.c
+++ b/board/freescale/imx8mm_evk/spl.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include
@@ -51,6 +51,13 @@ static void spl_dram_init(void)
void spl_board_init(void)
{
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(caam_jr),
);
+ if (ret)
+
[PATCH v4 03/16] i.MX8M: crypto: updated device tree for supporting DM in SPL
disabled use of JR0 in SPL and uboot, as JR0 is reserved
for secure boot.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
arch/arm/dts/imx8mm-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mm.dtsi | 1 +
arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mn.dtsi | 1 +
arch/arm/dts/imx8mp-evk-u-boot.dtsi | 18 +-
arch/arm/dts/imx8mp.dtsi | 1 +
arch/arm/dts/imx8mq.dtsi | 1 +
7 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
index 3c75415e8f..40f5cfda9a 100644
--- a/arch/arm/dts/imx8mm-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include "imx8mm-u-boot.dtsi"
@@ -72,6 +72,22 @@
u-boot,dm-spl;
};
+ {
+ u-boot,dm-spl;
+};
+
+_jr0 {
+ u-boot,dm-spl;
+};
+
+_jr1 {
+ u-boot,dm-spl;
+};
+
+_jr2 {
+ u-boot,dm-spl;
+};
+
{
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mm.dtsi b/arch/arm/dts/imx8mm.dtsi
index b142b80734..00bf3a 100644
--- a/arch/arm/dts/imx8mm.dtsi
+++ b/arch/arm/dts/imx8mm.dtsi
@@ -824,6 +824,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
index 1d3844437d..b462d24eb2 100644
--- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
/ {
@@ -104,6 +104,22 @@
u-boot,dm-spl;
};
+ {
+ u-boot,dm-spl;
+};
+
+_jr0 {
+ u-boot,dm-spl;
+};
+
+_jr1 {
+ u-boot,dm-spl;
+};
+
+_jr2 {
+ u-boot,dm-spl;
+};
+
{
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mn.dtsi b/arch/arm/dts/imx8mn.dtsi
index edcb415b53..1820a5af37 100644
--- a/arch/arm/dts/imx8mn.dtsi
+++ b/arch/arm/dts/imx8mn.dtsi
@@ -822,6 +822,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index ab849ebaac..52f473dc52 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
- * Copyright 2019 NXP
+ * Copyright 2019, 2021 NXP
*/
#include "imx8mp-u-boot.dtsi"
@@ -67,6 +67,22 @@
u-boot,dm-spl;
};
+ {
+ u-boot,dm-spl;
+};
+
+_jr0 {
+ u-boot,dm-spl;
+};
+
+_jr1 {
+ u-boot,dm-spl;
+};
+
+_jr2 {
+ u-boot,dm-spl;
+};
+
{
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mp.dtsi b/arch/arm/dts/imx8mp.dtsi
index c2d51a46cb..57b01c3a57 100644
--- a/arch/arm/dts/imx8mp.dtsi
+++ b/arch/arm/dts/imx8mp.dtsi
@@ -624,6 +624,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
diff --git a/arch/arm/dts/imx8mq.dtsi b/arch/arm/dts/imx8mq.dtsi
index a44f729d0e..ecab44ca13 100644
--- a/arch/arm/dts/imx8mq.dtsi
+++ b/arch/arm/dts/imx8mq.dtsi
@@ -955,6 +955,7 @@
compatible = "fsl,sec-v4.0-job-ring";
reg = <0x1000 0x1000>;
interrupts = ;
+ status = "disabled";
};
sec_jr1: jr@2000 {
--
2.17.1
[PATCH v4 02/16] crypto/fsl: Add CAAM support for bkek, random number generation
added api and descriptor for blob key encryption key(bkek) generation.
added api for random number generation.
Signed-off-by: Gaurav Jain
Signed-off-by: Ji Luo
Reviewed-by: Ye Li
---
drivers/crypto/fsl/desc.h | 5 +++
drivers/crypto/fsl/fsl_blob.c | 82 +++
drivers/crypto/fsl/jobdesc.c | 20 +++--
drivers/crypto/fsl/jobdesc.h | 4 ++
4 files changed, 108 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/fsl/desc.h b/drivers/crypto/fsl/desc.h
index 5705c4f944..5958ebd3ac 100644
--- a/drivers/crypto/fsl/desc.h
+++ b/drivers/crypto/fsl/desc.h
@@ -4,6 +4,7 @@
* Definitions to support CAAM descriptor instruction generation
*
* Copyright 2008-2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
* Based on desc.h file in linux drivers/crypto/caam
*/
@@ -15,6 +16,7 @@
#define KEY_BLOB_SIZE 32
#define MAC_SIZE 16
+#define BKEK_SIZE 32
/* Max size of any CAAM descriptor in 32-bit words, inclusive of header */
#define MAX_CAAM_DESCSIZE 64
@@ -463,6 +465,9 @@
#define OP_PROTINFO_HASH_SHA3840x0200
#define OP_PROTINFO_HASH_SHA5120x0280
+/* PROTINFO fields for Blob Operations */
+#define OP_PROTINFO_MKVB 0x0002
+
/* For non-protocol/alg-only op commands */
#define OP_ALG_TYPE_SHIFT 24
#define OP_ALG_TYPE_MASK (0x7 << OP_ALG_TYPE_SHIFT)
diff --git a/drivers/crypto/fsl/fsl_blob.c b/drivers/crypto/fsl/fsl_blob.c
index e8202cc569..e8bc009daf 100644
--- a/drivers/crypto/fsl/fsl_blob.c
+++ b/drivers/crypto/fsl/fsl_blob.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2021 NXP
*
*/
@@ -152,6 +153,87 @@ int blob_encap(u8 *key_mod, u8 *src, u8 *dst, u32 len)
return ret;
}
+int derive_blob_kek(u8 *bkek_buf, u8 *key_mod, u32 key_sz)
+{
+ int ret, size;
+ u32 *desc;
+
+ if (!IS_ALIGNED((uintptr_t)bkek_buf, ARCH_DMA_MINALIGN) ||
+ !IS_ALIGNED((uintptr_t)key_mod, ARCH_DMA_MINALIGN)) {
+ puts("Error: derive_bkek: Address arguments are not
aligned!\n");
+ return -EINVAL;
+ }
+
+ printf("\nBlob key encryption key(bkek)\n");
+ desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
+ if (!desc) {
+ printf("Not enough memory for descriptor allocation\n");
+ return -ENOMEM;
+ }
+
+ size = ALIGN(key_sz, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)key_mod, (unsigned long)key_mod +
size);
+
+ /* construct blob key encryption key(bkek) derive descriptor */
+ inline_cnstr_jobdesc_derive_bkek(desc, bkek_buf, key_mod, key_sz);
+
+ size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
+ size = ALIGN(BKEK_SIZE, ARCH_DMA_MINALIGN);
+ invalidate_dcache_range((unsigned long)bkek_buf,
+ (unsigned long)bkek_buf + size);
+
+ /* run descriptor */
+ ret = run_descriptor_jr(desc);
+ if (ret < 0) {
+ printf("Error: %s failed 0x%x\n", __func__, ret);
+ } else {
+ invalidate_dcache_range((unsigned long)bkek_buf,
+ (unsigned long)bkek_buf + size);
+ puts("derive bkek successful.\n");
+ }
+
+ free(desc);
+ return ret;
+}
+
+int hwrng_generate(u8 *dst, u32 len)
+{
+ int ret, size;
+ u32 *desc;
+
+ if (!IS_ALIGNED((uintptr_t)dst, ARCH_DMA_MINALIGN)) {
+ puts("Error: caam_hwrng_test: Address arguments are not
aligned!\n");
+ return -EINVAL;
+ }
+
+ printf("\nRNG generate\n");
+ desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE);
+ if (!desc) {
+ printf("Not enough memory for descriptor allocation\n");
+ return -ENOMEM;
+ }
+
+ inline_cnstr_jobdesc_rng(desc, dst, len);
+
+ size = ALIGN(sizeof(int) * MAX_CAAM_DESCSIZE, ARCH_DMA_MINALIGN);
+ flush_dcache_range((unsigned long)desc, (unsigned long)desc + size);
+ size = ALIGN(len, ARCH_DMA_MINALIGN);
+ invalidate_dcache_range((unsigned long)dst, (unsigned long)dst + size);
+
+ ret = run_descriptor_jr(desc);
+ if (ret < 0) {
+ printf("Error: RNG generate failed 0x%x\n", ret);
+ } else {
+ invalidate_dcache_range((unsigned long)dst,
+ (unsigned long)dst + size);
+ puts("RNG generation successful.\n");
+ }
+
+ free(desc);
+ return ret;
+}
+
#ifdef CONFIG_CMD_DEKBLOB
int blob_dek(const u8 *src, u8 *dst, u8 len)
{
diff --git a/drivers/crypto/fsl/jobdesc.c b/drivers/crypto/fsl/jobdesc.c
index c350b32856..d58937c284 100644
--- a/drivers/crypto/fsl/jobdesc.c
+++
[PATCH v4 01/16] crypto/fsl: Add support for CAAM Job ring driver model
added device tree support for job ring driver.
sec is initialized based on job ring information processed
from device tree.
Signed-off-by: Gaurav Jain
Reviewed-by: Ye Li
---
cmd/Kconfig | 1 +
drivers/crypto/fsl/Kconfig | 7 +
drivers/crypto/fsl/Makefile | 4 +-
drivers/crypto/fsl/jr.c | 318
drivers/crypto/fsl/jr.h | 14 ++
5 files changed, 234 insertions(+), 110 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 5b30b13e43..2b24672505 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2009,6 +2009,7 @@ config CMD_AES
config CMD_BLOB
bool "Enable the 'blob' command"
+ select FSL_BLOB
depends on !MX6ULL && !MX6SLL && !MX6SL
select IMX_HAB if ARCH_MX6 || ARCH_MX7 || ARCH_MX7ULP || ARCH_IMX8M
help
diff --git a/drivers/crypto/fsl/Kconfig b/drivers/crypto/fsl/Kconfig
index 94ff540111..ab59d516f8 100644
--- a/drivers/crypto/fsl/Kconfig
+++ b/drivers/crypto/fsl/Kconfig
@@ -66,4 +66,11 @@ config FSL_CAAM_RNG
using the prediction resistance flag which means the DRGB is
reseeded from the TRNG every time random data is generated.
+config FSL_BLOB
+bool "Enable Blob Encap/Decap, Blob KEK support"
+ help
+ Enable support for the hardware based crytographic blob encap/decap
+ module of the CAAM. blobs can be safely placed into non-volatile
+ storage. blobs can only be decapsulated by the SoC that created it.
+ Enable support for blob key encryption key generation.
endif
diff --git a/drivers/crypto/fsl/Makefile b/drivers/crypto/fsl/Makefile
index f9c3ccecfc..738535b8e4 100644
--- a/drivers/crypto/fsl/Makefile
+++ b/drivers/crypto/fsl/Makefile
@@ -1,10 +1,12 @@
# SPDX-License-Identifier: GPL-2.0+
#
# Copyright 2014 Freescale Semiconductor, Inc.
+# Copyright 2021 NXP
obj-y += sec.o
obj-$(CONFIG_FSL_CAAM) += jr.o fsl_hash.o jobdesc.o error.o
-obj-$(CONFIG_CMD_BLOB)$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
+obj-$(CONFIG_FSL_BLOB) += fsl_blob.o
+obj-$(CONFIG_IMX_CAAM_DEK_ENCAP) += fsl_blob.o
obj-$(CONFIG_RSA_FREESCALE_EXP) += fsl_rsa.o
obj-$(CONFIG_FSL_CAAM_RNG) += rng.o
obj-$(CONFIG_FSL_MFGPROT) += fsl_mfgprot.o
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index 22b649219e..bec4953f6d 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2008-2014 Freescale Semiconductor, Inc.
- * Copyright 2018 NXP
+ * Copyright 2018, 2021 NXP
*
* Based on CAAM driver in drivers/crypto/caam in Linux
*/
@@ -11,7 +11,6 @@
#include
#include
#include
-#include "fsl_sec.h"
#include "jr.h"
#include "jobdesc.h"
#include "desc_constr.h"
@@ -21,8 +20,11 @@
#include
#include
#endif
+#include
#include
#include
+#include
+#include
#define CIRC_CNT(head, tail, size) (((head) - (tail)) & (size - 1))
#define CIRC_SPACE(head, tail, size) CIRC_CNT((tail), (head) + 1, (size))
@@ -35,20 +37,30 @@ uint32_t sec_offset[CONFIG_SYS_FSL_MAX_NUM_OF_SEC] = {
#endif
};
+#if CONFIG_IS_ENABLED(DM)
+struct udevice *caam_dev;
+#else
#define SEC_ADDR(idx) \
(ulong)((CONFIG_SYS_FSL_SEC_ADDR + sec_offset[idx]))
#define SEC_JR0_ADDR(idx) \
(ulong)(SEC_ADDR(idx) + \
(CONFIG_SYS_FSL_JR0_OFFSET - CONFIG_SYS_FSL_SEC_OFFSET))
+struct caam_regs caam_st;
+#endif
-struct jobring jr0[CONFIG_SYS_FSL_MAX_NUM_OF_SEC];
+static inline u32 jr_start_reg(u8 jrid)
+{
+ return (1 << jrid);
+}
-static inline void start_jr0(uint8_t sec_idx)
+#ifndef CONFIG_ARCH_IMX8
+static inline void start_jr(struct caam_regs *caam)
{
- ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
+ ccsr_sec_t *sec = caam->sec;
u32 ctpr_ms = sec_in32(>ctpr_ms);
u32 scfgr = sec_in32(>scfgr);
+ u32 jrstart = jr_start_reg(caam->jrid);
if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_INCL) {
/* VIRT_EN_INCL = 1 & VIRT_EN_POR = 1 or
@@ -56,23 +68,17 @@ static inline void start_jr0(uint8_t sec_idx)
*/
if ((ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR) ||
(scfgr & SEC_SCFGR_VIRT_EN))
- sec_out32(>jrstartr, CONFIG_JRSTARTR_JR0);
+ sec_out32(>jrstartr, jrstart);
} else {
/* VIRT_EN_INCL = 0 && VIRT_EN_POR_VALUE = 1 */
if (ctpr_ms & SEC_CTPR_MS_VIRT_EN_POR)
- sec_out32(>jrstartr, CONFIG_JRSTARTR_JR0);
+ sec_out32(>jrstartr, jrstart);
}
}
+#endif
-static inline void jr_reset_liodn(uint8_t sec_idx)
-{
- ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
- sec_out32(>jrliodnr[0].ls, 0);
-}
-
-static inline void jr_disable_irq(uint8_t sec_idx)
+static inline void jr_disable_irq(struct jr_regs *regs)
{
- struct jr_regs *regs = (struct jr_regs *)SEC_JR0_ADDR(sec_idx);
uint32_t jrcfg = sec_in32(>jrcfg1);
jrcfg
