Re: [PATCH v2] net: mv88e6xxx: fix missing SMI address initialization
Hi Ramon,
On 1/9/24 10:37, Stefan Roese wrote:
On 12/18/23 17:09, Marek Behún wrote:
On Wed, 6 Dec 2023 15:35:56 +0100
Marek Mojík wrote:
The mv88e6xxx driver does not currently initialize the smi_addr
field, but
instead keeps the default zero value. This leads to driver being
unusable
on devices where the switch is not on address zero of the mdio bus. Fix
this problem by reading the SMI address from device tree.
Signed-off-by: Marek Mojík
---
drivers/net/mv88e6xxx.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/mv88e6xxx.c b/drivers/net/mv88e6xxx.c
index c073f81e72..8fbbc1cacc 100644
--- a/drivers/net/mv88e6xxx.c
+++ b/drivers/net/mv88e6xxx.c
@@ -745,6 +745,7 @@ static int mv88e6xxx_probe(struct udevice *dev)
{
struct dsa_pdata *dsa_pdata = dev_get_uclass_plat(dev);
struct mv88e6xxx_priv *priv = dev_get_priv(dev);
+ fdt_addr_t smi_addr;
int val, ret;
if (ofnode_valid(dev_ofnode(dev)) &&
@@ -753,6 +754,13 @@ static int mv88e6xxx_probe(struct udevice *dev)
return -ENODEV;
}
+ smi_addr = dev_read_addr(dev);
+ if (smi_addr == FDT_ADDR_T_NONE) {
+ dev_err(dev, "Missing SMI address\n");
+ return -EINVAL;
+ }
+ priv->smi_addr = smi_addr;
+
/* probe internal mdio bus */
ret = mv88e6xxx_probe_mdio(dev);
if (ret)
Reviewed-by: Marek Behún
Reviewed-by: Stefan Roese
Ramon, this patch was assigned to me as an Marvell MVEBU patch
depends on it. I've assigned it to you now. Or if it's okay that
I pull it with the Marvell tree, just let me know.
Any updates on this?
Thanks,
Stefan
Re: [PATCH 1/1] efi_loader: simplify error message in efi_disk_create_raw()
On Fri, 2 Feb 2024 at 16:13, Heinrich Schuchardt
wrote:
>
> The error message
>
> Adding disk for usb_mass_storage.lun0 failed
> (err=-9223372036854775788/0x8014)
>
> provides a decimal and a hexadecimal notation of the EFI status code
> EFI_ALREADY_STARTED which is defined as (EFI_ERROR_MASK | 20).
> The decimal output does not convey the value 20 clearly.
>
> With the patch we write
>
> Adding block device usb_mass_storage.lun0 failed, r = 20
>
> similar to other EFI error messages.
>
> Fixes: 952018117ab4 ("dm: sandbox: Switch over to using the new host uclass")
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_disk.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> index b1739d99201..2fefd05fbdc 100644
> --- a/lib/efi_loader/efi_disk.c
> +++ b/lib/efi_loader/efi_disk.c
> @@ -574,7 +574,8 @@ static int efi_disk_create_raw(struct udevice *dev,
> efi_handle_t agent_handle)
> log_notice("Disk %s not ready\n", dev->name);
> ret = -EBUSY;
> } else {
> - log_err("Adding disk for %s failed (err=%ld/%#lx)\n",
> dev->name, ret, ret);
> + log_err("Adding block device %s failed, r = %lu\n",
> + dev->name, ret & ~EFI_ERROR_MASK);
> ret = -ENOENT;
> }
>
> --
> 2.43.0
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2] scripts: dtc-version: Don't show error messages
On 2024-02-06 12:00, Dragan Simic wrote:
Prevent the error messages produced by which(1), such as the one quoted
below, from being visible in the build outputs.
which: no dtc in (./scripts/dtc)
This makes the build outputs look a tiny bit cleaner.
Just checking, is there something that prevents this patch from
becoming merged?
Signed-off-by: Dragan Simic
Reviewed-by: Quentin Schulz
---
Notes:
Version 2 incorporates the suggestion from Quentin to use a more
compact
version of the redirection, which is already used in multiple
places.
The original motivation to use the more verbose version was to
prevent
possible issues with some shells, or with some older shell
versions, which
may not recognize the compact version.
scripts/dtc-version.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/dtc-version.sh b/scripts/dtc-version.sh
index 53ff868bcdce..18c59ac1e255 100755
--- a/scripts/dtc-version.sh
+++ b/scripts/dtc-version.sh
@@ -15,7 +15,7 @@ if [ ${#dtc} -eq 0 ]; then
exit 1
fi
-if ! which $dtc >/dev/null ; then
+if ! which $dtc > /dev/null 2>&1 ; then
echo "Error: Cannot find dtc: $dtc"
exit 1
fi
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
Hello Shantur and Marek,
On 2024-02-14 04:18, Dragan Simic wrote:
On 2024-02-14 03:04, Andre Przywara wrote:
On Mon, 12 Feb 2024 21:19:13 +0100 Marek Vasut wrote:
On 2/12/24 14:41, Shantur Rathore wrote:
> On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore wrote:
>> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic wrote:
>>> On 2024-02-08 15:17, Dragan Simic wrote:
On 2024-02-08 15:10, Shantur Rathore wrote:
> On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> wrote:
>> On 2024-02-08 14:33, Marek Vasut wrote:
>>> On 2/8/24 12:30, Shantur Rathore wrote:
On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut wrote:
> On 2/7/24 11:23, Shantur Rathore wrote:
>> USB 3.0 spec requires hub to reset device while
>> enumeration. Some USB 2.0 hubs / devices don't
>> handle this well and after implementation of
>> reset some USB 2.0 disks weren't detected on
>> Allwinner based boards.
>>
>> Resetting only when hub is USB 3.0 fixes it.
>
> It would be good to include as many details about the faulty hardware
> in
> the commit message as possible, so that when someone else runs into
> this, they would have all that information available.
>
>> Tested-by: Andre Przywara
>>
>> Signed-off-by: Shantur Rathore
>> ---
>>
>> common/usb_hub.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 3fb7e14d10..2e054eb935 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
>> usb_hub_device *hub)
>>
>> debug("enabling power on all ports\n");
>> for (i = 0; i < dev->maxchild; i++) {
>> - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
>> - debug("Reset : port %d returns %lX\n", i + 1,
>> dev->status);
>> + if (usb_hub_is_superspeed(dev)) {
>
> Should this condition be "all which are lower than superspeed"
> instead ,
> so when the next generation of USB comes, this problem won't trigger
> ?
>
> What does Linux do btw ?
As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
which is
return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3
This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
We can change the check to be bDeviceProtocol > 2 but who knows if
things change in the newer version of spec.
I am open to suggestions.
>>>
>>> Please just include the ^ in the commit description. Use link to
>>> git.kernel.org , not some mirror . This is extremely useful
>>> information and, well, you already wrote the V2 commit message
>>> addition in this answer.
>>
>> Shantur, if that would be easier or quicker for you, I can write
>> a quite detailed patch description for you, in exchange for a
>> "Helped-by" tag in the v2 patch submission. :)
>
> That would be really kind of you Dragan.
Sure, I'll write the summary and send it over.
> I am down with the flu so that would really help me as my brain is
> working at 15% capacity.
Oh, I'm really sorry to hear that. :( I hope you'll get better
soon, and I know very well what's it like; I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity. I'm still not back to
exactly 100%. :/
I really hope you'll recover much faster.
>>>
>>> I hope you're feeling better.
>>>
>>> Below are the patch subject and description that I prepared for you,
>>> please have a look.
>>>
>>> --- >8 - >8 - >8 - >8 ---
>>> [PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
>>>
>>> Additional testing of the changes introduced in commit 33e06dcbe57a
>>> ("common:
>>> usb-hub: Reset hub port before scanning") revealed that some USB 3.0
>>> flash
>>
>> I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.
>>
>>> drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
>>> only.
>>> More precisely, some tested USB 3.0 flash drives failed to be detected
>>> and
>>> work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
>>> 2.0
>>> only, while the same USB flash drives worked just fine on a Pine64 H64
>>> with
>>> Allwinner H6 SoC, which supports both
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
Hello Andre,
On 2024-02-14 03:04, Andre Przywara wrote:
On Mon, 12 Feb 2024 21:19:13 +0100 Marek Vasut wrote:
On 2/12/24 14:41, Shantur Rathore wrote:
> On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore wrote:
>> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic wrote:
>>> On 2024-02-08 15:17, Dragan Simic wrote:
On 2024-02-08 15:10, Shantur Rathore wrote:
> On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> wrote:
>> On 2024-02-08 14:33, Marek Vasut wrote:
>>> On 2/8/24 12:30, Shantur Rathore wrote:
On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut wrote:
> On 2/7/24 11:23, Shantur Rathore wrote:
>> USB 3.0 spec requires hub to reset device while
>> enumeration. Some USB 2.0 hubs / devices don't
>> handle this well and after implementation of
>> reset some USB 2.0 disks weren't detected on
>> Allwinner based boards.
>>
>> Resetting only when hub is USB 3.0 fixes it.
>
> It would be good to include as many details about the faulty hardware
> in
> the commit message as possible, so that when someone else runs into
> this, they would have all that information available.
>
>> Tested-by: Andre Przywara
>>
>> Signed-off-by: Shantur Rathore
>> ---
>>
>> common/usb_hub.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>> index 3fb7e14d10..2e054eb935 100644
>> --- a/common/usb_hub.c
>> +++ b/common/usb_hub.c
>> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
>> usb_hub_device *hub)
>>
>> debug("enabling power on all ports\n");
>> for (i = 0; i < dev->maxchild; i++) {
>> - usb_set_port_feature(dev, i + 1, USB_PORT_FEAT_RESET);
>> - debug("Reset : port %d returns %lX\n", i + 1,
>> dev->status);
>> + if (usb_hub_is_superspeed(dev)) {
>
> Should this condition be "all which are lower than superspeed"
> instead ,
> so when the next generation of USB comes, this problem won't trigger
> ?
>
> What does Linux do btw ?
As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
which is
return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3
This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
We can change the check to be bDeviceProtocol > 2 but who knows if
things change in the newer version of spec.
I am open to suggestions.
>>>
>>> Please just include the ^ in the commit description. Use link to
>>> git.kernel.org , not some mirror . This is extremely useful
>>> information and, well, you already wrote the V2 commit message
>>> addition in this answer.
>>
>> Shantur, if that would be easier or quicker for you, I can write
>> a quite detailed patch description for you, in exchange for a
>> "Helped-by" tag in the v2 patch submission. :)
>
> That would be really kind of you Dragan.
Sure, I'll write the summary and send it over.
> I am down with the flu so that would really help me as my brain is
> working at 15% capacity.
Oh, I'm really sorry to hear that. :( I hope you'll get better
soon, and I know very well what's it like; I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity. I'm still not back to
exactly 100%. :/
I really hope you'll recover much faster.
>>>
>>> I hope you're feeling better.
>>>
>>> Below are the patch subject and description that I prepared for you,
>>> please have a look.
>>>
>>> --- >8 - >8 - >8 - >8 ---
>>> [PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
>>>
>>> Additional testing of the changes introduced in commit 33e06dcbe57a
>>> ("common:
>>> usb-hub: Reset hub port before scanning") revealed that some USB 3.0
>>> flash
>>
>> I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.
>>
>>> drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
>>> only.
>>> More precisely, some tested USB 3.0 flash drives failed to be detected
>>> and
>>> work on an OrangePi Zero 3 with Allwinner H616 SoC, which supports USB
>>> 2.0
>>> only, while the same USB flash drives worked just fine on a Pine64 H64
>>> with
>>> Allwinner H6 SoC, which supports both USB 2.0 and 3.0.
>>>
>>> Resetting USB 3.0 hubs only
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On Mon, 12 Feb 2024 21:19:13 +0100
Marek Vasut wrote:
> On 2/12/24 14:41, Shantur Rathore wrote:
> > On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore wrote:
> >>
> >> Thanks Dragan,
> >>
> >> On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic wrote:
> >>>
> >>> Hello Shantur,
> >>>
> >>> On 2024-02-08 15:17, Dragan Simic wrote:
> On 2024-02-08 15:10, Shantur Rathore wrote:
> > On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
> > wrote:
> >> On 2024-02-08 14:33, Marek Vasut wrote:
> >>> On 2/8/24 12:30, Shantur Rathore wrote:
> On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut wrote:
> > On 2/7/24 11:23, Shantur Rathore wrote:
> >> USB 3.0 spec requires hub to reset device while
> >> enumeration. Some USB 2.0 hubs / devices don't
> >> handle this well and after implementation of
> >> reset some USB 2.0 disks weren't detected on
> >> Allwinner based boards.
> >>
> >> Resetting only when hub is USB 3.0 fixes it.
> >
> > It would be good to include as many details about the faulty
> > hardware
> > in
> > the commit message as possible, so that when someone else runs into
> > this, they would have all that information available.
> >
> >> Tested-by: Andre Przywara
> >>
> >> Signed-off-by: Shantur Rathore
> >> ---
> >>
> >> common/usb_hub.c | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/common/usb_hub.c b/common/usb_hub.c
> >> index 3fb7e14d10..2e054eb935 100644
> >> --- a/common/usb_hub.c
> >> +++ b/common/usb_hub.c
> >> @@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
> >> usb_hub_device *hub)
> >>
> >> debug("enabling power on all ports\n");
> >> for (i = 0; i < dev->maxchild; i++) {
> >> - usb_set_port_feature(dev, i + 1,
> >> USB_PORT_FEAT_RESET);
> >> - debug("Reset : port %d returns %lX\n", i + 1,
> >> dev->status);
> >> + if (usb_hub_is_superspeed(dev)) {
> >
> > Should this condition be "all which are lower than superspeed"
> > instead ,
> > so when the next generation of USB comes, this problem won't trigger
> > ?
> >
> > What does Linux do btw ?
>
> As of now Linux checks if the hub is superspeed
> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
>
> which is
> return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
> USB_HUB_PR_SS = 3
>
> This holds true for newer SuperSpeedPlus hubs as well.
> https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
>
> We can change the check to be bDeviceProtocol > 2 but who knows if
> things change in the newer version of spec.
> I am open to suggestions.
> >>>
> >>> Please just include the ^ in the commit description. Use link to
> >>> git.kernel.org , not some mirror . This is extremely useful
> >>> information and, well, you already wrote the V2 commit message
> >>> addition in this answer.
> >>
> >> Shantur, if that would be easier or quicker for you, I can write
> >> a quite detailed patch description for you, in exchange for a
> >> "Helped-by" tag in the v2 patch submission. :)
> >
> > That would be really kind of you Dragan.
>
> Sure, I'll write the summary and send it over.
>
> > I am down with the flu so that would really help me as my brain is
> > working at 15% capacity.
>
> Oh, I'm really sorry to hear that. :( I hope you'll get better
> soon, and I know very well what's it like; I've also been sick
> recently, as a result of some kind of flu that unfortunately found
> its way into my lungs, and it took me about a month to get back
> to about 90% of my usual mental capacity. I'm still not back to
> exactly 100%. :/
>
> I really hope you'll recover much faster.
> >>>
> >>> I hope you're feeling better.
> >>>
> >>> Below are the patch subject and description that I prepared for you,
> >>> please have a look.
> >>>
> >>> --- >8 - >8 - >8 - >8 ---
> >>> [PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
> >>>
> >>> Additional testing of the changes introduced in commit 33e06dcbe57a
> >>> ("common:
> >>> usb-hub: Reset hub port before scanning") revealed that some USB 3.0
> >>> flash
> >>
> >> I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.
> >>
> >>> drives didn't work in U-Boot on some Allwinner SoCs that support USB 2.0
> >>> only.
> >>> More precisely, some tested USB 3.0 flash
[ANN] U-Boot v2024.04-rc2 released
Hey all, I'm a day late as I missed my calendar reminder, but here's -rc2 now. I am hopeful really just about everything that needs to come in, is now in, but I also know I have at least one more series to grab for TI platforms. And I'll grab the series I posted today that should fix the current CI failure that's related to not being able to download a file from Google drive. In terms of a changelog, git log --merges v2024.01-rc1..v2024.04-rc2 contains what I've pulled but as always, better PR messages and tags will provide better results here. I hope to get back on schedule and that means the rest of the rcs every other Monday, and with final release on Tuesday, April 2nd, 2024. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] Revert "board: verdin-am62: set cpu core voltage depending on speed grade"
On Tue, Feb 13, 2024 at 05:00:03PM +0100, Francesco Dolcini wrote:
> From: Francesco Dolcini
>
> This reverts commit d2099587d661c6ca2309256c0e04c06e26c8d34c.
>
> According to TI changing the VDD_CORE while the SoC is running is not
> allowed, the voltage must be set before the AM62 device reset is
> released, revert this change therefore.
>
> The correct solution would be to program the PMIC during manufactoring
> according to the speed grade of the SoC.
>
> Link:
> https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1318338/am623-booting-from-mmc-failed-after-lowering-vdd_core-to-0-75v/5036508#5036508
> Fixes: d2099587d661 ("board: verdin-am62: set cpu core voltage depending on
> speed grade")
> Signed-off-by: Francesco Dolcini
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] memory: ti-gpmc: Fix lock up at A53 SPL during NAND boot on AM64-EVM
On Tue, Feb 06, 2024 at 04:02:51PM +0200, Roger Quadros wrote: > AM64 ES2.0 bootrom seems to enable WAIT0EDGEDETECTION interrupt. > This causes a lockup at A53 SPL when accessing NAND controller > or ELM registers. > > A good option would be to softrest GPMC block at probe > but this cannot be done for AM64 as SOFTRESET bit is marked > as reserved in SYSCONFIG register. > > Fix the issue by disabling all IRQs at probe. > > Signed-off-by: Roger Quadros Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v1] cmd: hash: fix param count check
On Wed, Feb 07, 2024 at 01:01:32AM +0100, Igor Opaniuk wrote: > From: Igor Opaniuk > > Add correct check for parameter count. > > This fixes this issue when `hash` cmd is invoked without params: > > => hash > data abort > pc : []lr : [] > reloc pc : [<60019204>] lr : [<5afcffa8>] > sp : ba6dd9c8 ip : bf7391f0 fp : bf74ec14 > r10: 0001 r9 : ba6dfea0 r8 : bf7ea030 > r7 : r6 : ba6effa8 r5 : r4 : > r3 : bf7c257c r2 : 0001 r1 : r0 : bf7e6e34 > Flags: nZCv IRQs off FIQs on Mode SVC_32 > Code: e5934004 e1a0e003 e59f3050 e2444001 (e5f4c001) > Resetting CPU ... > > resetting ... > > Signed-off-by: Igor Opaniuk Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] boot: add support for button commands
On Tue, Jan 09, 2024 at 11:51:09AM +, Caleb Connolly wrote: > With the relatively new button API in U-Boot, it's now much easier to > model the common usecase of mapping arbitrary actions to different > buttons during boot - for example entering fastboot mode, setting some > additional kernel cmdline arguments, or booting with a custom recovery > ramdisk, to name a few. > > Historically, this functionality has been implemented in board code, > making it fixed for a given U-Boot binary and requiring the code be > duplicated and modified for every board. > > Implement a generic abstraction to run an arbitrary command during boot > when a specific button is pressed. The button -> command mapping is > configured via environment variables with the following format: > > button_cmd_N_name= > button_cmd_N= > > Where N is the mapping number starting from 0. For example: > > button_cmd_0_name=vol_down > button_cmd_0=fastboot usb 0 > > This will cause the device to enter fastboot mode if volume down is held > during boot. > > After we enter the cli loop the button commands are no longer valid, > this allows the buttons to additionally be used for navigating a boot > menu. > > Tested-by: Svyatoslav Ryhel # Tegra30 > Signed-off-by: Caleb Connolly Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] poplar: add myself as co-maintainer
On Fri, Feb 02, 2024 at 10:44:29PM +0100, Igor Opaniuk wrote: > Add myself as co-maintainer for Poplar board, as I'm currently > working on it (re-testing releases, addressing issues etc). > > CC: Jorge Ramirez-Ortiz > CC: Shawn Guo > Signed-off-by: Igor Opaniuk > Acked-by: Shawn Guo > Acked-by: Jorge Ramirez-Ortiz Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 08/11] doc: devicetree: Updates for devicetree-rebasing subtree
On 02/02/2024 13:05, Sumit Garg wrote: > Encourage SoC/board maintainers to migrate to using devicetree-rebasing > subtree and maintain a regular sync with Linux kernel devicetree files > and bindings. > > Along with that add documentation regarding how to run DT bindings > schema checks. > > Signed-off-by: Sumit Garg > --- > > Changes in v5: > - Document how to cherry-pick fixes from devicetree-rebasing tree. > > Changes in v4: > - Switched subtree to be imported as dts/upstream sub-directory rather > than devicetree-rebasing sub-directory to better suite U-Boot > directory structure. > - Since we now have v6.7-dts tag available now, so switch subtree to > that from its beginning. > - Clarify subtree uprev schedule as a separate documentation section. > Also, fixed documentation typos. > > Changes in v3: > - Replace CONFIG_* with Kconfig options > > Changes in v2: > - s/U-boot/U-Boot/ > > doc/develop/devicetree/control.rst | 117 - > 1 file changed, 97 insertions(+), 20 deletions(-) > > diff --git a/doc/develop/devicetree/control.rst > b/doc/develop/devicetree/control.rst > index 9a0cb90336df..4440d4b82c6a 100644 > --- a/doc/develop/devicetree/control.rst > +++ b/doc/develop/devicetree/control.rst > @@ -1,5 +1,6 @@ > .. SPDX-License-Identifier: GPL-2.0+ > .. sectionauthor:: Copyright 2011 The Chromium OS Authors > +.. Copyright 2023-2024 Linaro Ltd. > > Devicetree Control in U-Boot > > @@ -22,12 +23,11 @@ for three reasons: >hierarchical format > - It is fairly efficient to read incrementally > > -The arch//dts directories contains a Makefile for building the > devicetree > -blob and embedding it in the U-Boot image. This is useful since it allows > -U-Boot to configure itself according to what it finds there. If you have > -a number of similar boards with different peripherals, you can describe > -the features of each board in the devicetree file, and have a single > -generic source base. > +The U-Boot Makefile infrastructure allows for building the devicetree blob > +and embedding it in the U-Boot image. This is useful since it allows U-Boot > +to configure itself according to what it finds there. If you have a number > +of similar boards with different peripherals, you can describe the features > +of each board in the devicetree file, and have a single generic source base. > > To enable this feature, select `OF_CONTROL` via Kconfig. > > @@ -68,8 +68,14 @@ a binary file. U-Boot adds its own `fdtgrep` for creating > subsets of the file. > Where do I get a devicetree file for my board? > -- > > -You may find that the Linux kernel has a suitable file. Look in the > -kernel source in arch//boot/dts. > +Linux kernel Git repository has been the place where devicetree files along > +with devicetree bindings are stored and maintained. There is > devicetee-rebasing > +(dtrepo_) which maintains a forked copy of devicetree files along with > bindings > +at every Linux kernel major release or intermediate release candidates. This can be written more clearly, we can steal what you wrote later and expand it to say what was wrong with the previous situation: "The devicetree files and devicetree bindings are maintained as part of the Linux kernel git repository. Traditionally, U-Boot placed copies of devicetree source files from the Linux kernel into `arch//dts/.dts`. However, this required each board maintainer to manually keep their device tree in sync with Linux and often led to divergence between these copies." We can then introduce the `dts/upstream` directory and tell developers why it is a better solution. I think the docs should talk about the `dts/upstream` directory first, then the devicetree-rebasing repository afterwards. The directory in the u-boot source tree is what most developers will see and interact with, use of the devicetree-rebasing repository is an implementation detail of how that subtree is sync'd with Linux. I don't think we need to mention the devicetree-rebasing repository until the "Resyncing with devicetree-rebasing" section below. Also, is devicetree-rebasing a "forked copy"? A fork would imply some difference from upstream. I would guess this is more like a mirror. > + > +U-Boot maintains a Git subtree for devicetee-rebasing repo as `dts/upstream/` > +sub-directory. You may find that the `dts/upstream/` sub-directory has a > +suitable devicetree file for your board. Look in `dts/upstream/src//`. > > If not you might find other boards with suitable files that you can > modify to your needs. Look in the board directories for files with a > @@ -78,17 +84,38 @@ modify to your needs. Look in the board directories for > files with a > Failing that, you could write one from scratch yourself! > > > +Resyncing with devicetree-rebasing > +-- > + > +U-Boot regularly sync `dts/upstream/` subtree whenever the
[PATCH] log: fixup log_head after relocating global data
When `gd` is relocated during `spl_relocate_stack_gd()` the
doubly-linked circular list in the `log_head` member is broken.
The last element of the list should point back to the initial
`list_head`, but as the initial `list_head` is moved the pointer becomes
stale. As a result the loop in `log_dispatch` would never finish.
Signed-off-by: Thomas Weißschuh
---
This patch is a simpler alternative to
https://lore.kernel.org/u-boot/20240212-spl-logging-v1-1-051cde837...@linutronix.de/
This patch should also remove the special handling introduced in
commit e7595aa350ae ("x86: Allow logging to be used in SPL reliably").
---
common/log.c | 4
common/spl/spl.c | 3 +++
include/log.h| 12
3 files changed, 19 insertions(+)
diff --git a/common/log.c b/common/log.c
index b2de57fcb3b8..0ca2d1b4c8bc 100644
--- a/common/log.c
+++ b/common/log.c
@@ -428,6 +428,10 @@ int log_device_set_enable(struct log_driver *drv, bool
enable)
return 0;
}
+void log_fixup_for_gd_move(struct global_data *new_gd) {
+ new_gd->log_head.prev->next = _gd->log_head;
+}
+
int log_init(void)
{
struct log_driver *drv = ll_entry_start(struct log_driver, log_driver);
diff --git a/common/spl/spl.c b/common/spl/spl.c
index b65c439e7aa9..e06bc75d36b2 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -909,6 +909,9 @@ ulong spl_relocate_stack_gd(void)
#if CONFIG_IS_ENABLED(DM)
dm_fixup_for_gd_move(new_gd);
#endif
+#if CONFIG_IS_ENABLED(LOG)
+ log_fixup_for_gd_move(new_gd);
+#endif
#if !defined(CONFIG_ARM) && !defined(CONFIG_RISCV)
gd = new_gd;
#endif
diff --git a/include/log.h b/include/log.h
index 6e84f080ef3d..fc0d59844728 100644
--- a/include/log.h
+++ b/include/log.h
@@ -688,4 +688,16 @@ static inline int log_get_default_format(void)
(IS_ENABLED(CONFIG_LOGF_FUNC) ? BIT(LOGF_FUNC) : 0);
}
+struct global_data;
+/**
+ * log_fixup_for_gd_move() - Handle global_data moving to a new place
+ *
+ * @new_gd: Pointer to the new global data
+ *
+ * The log_head list is part of global_data. Due to the way lists work, moving
+ * the list will cause it to become invalid. This function fixes that up so
+ * that the log_head list will work correctly.
+ */
+void log_fixup_for_gd_move(struct global_data *new_gd);
+
#endif
---
base-commit: 73b5b47dd5b546d0b9106bcca54c72815380e6d3
change-id: 20240213-spl-logging-2-43a81ae0f147
Best regards,
--
Thomas Weißschuh
Re: Booting from NFSv4 file system?
On Tue, 13 Feb 2024 at 13:32, Peter Robinson wrote: > > On Tue, 13 Feb 2024 at 12:18, Cedric Blancher > wrote: > > > > Good morning! > > > > Does U-Boot support booting from a NFSv4 file system? Explicitly > > neither NFSv2 or NFSv3 will work in our case, as both protocol > > versions are depreciated and no longer allowed by our IT department. > > Not that I am aware of, at least not upstream, there is work being > done to support booting using UEFI HTTP boot if HTTP is more straight > forward for network booting. HTTP is *USELESS* in this context, and comes with huge complications (HTTP protocol diversity, absurd requirements, which are incompatible to filesystem requirements, and security requirements like TLS, as no IT department will deploy a bare HTTP server, only HTTPS). So NFSv4 is the better bet. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
[PATCH v2 2/3] board: Add support for Sielaff i.MX6 Solo board
From: Frieder Schrempf
The Sielaff i.MX6 Solo board is a control and HMI board for vending
machines. Add support for this board.
The devicetree files are taken from pending changes in the Linux
kernel that are available from linux-next and will likely be
part of Linux v6.9.
Signed-off-by: Frieder Schrempf
---
Changes in v2:
* Implement changes suggested by Fabio (Thanks!)
* Fix system reset and remove unneeded cpu_reset()
* Add 'static const' to nfc_pads[]
* Remove hostname from env
* Remove options to disable caches
* Enable watchdog and wdt command
* Enable LTO
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/imx6dl-sielaff-u-boot.dtsi | 38 ++
arch/arm/dts/imx6dl-sielaff.dts | 533 ++
arch/arm/mach-imx/mx6/Kconfig | 10 +
board/sielaff/imx6dl-sielaff/Kconfig | 15 +
board/sielaff/imx6dl-sielaff/Makefile | 8 +
board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c | 111
.../sielaff/imx6dl-sielaff/imx6dl-sielaff.env | 114
board/sielaff/imx6dl-sielaff/spl.c| 273 +
configs/imx6dl_sielaff_defconfig | 120
include/configs/imx6dl-sielaff.h | 25 +
11 files changed, 1248 insertions(+)
create mode 100644 arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
create mode 100644 arch/arm/dts/imx6dl-sielaff.dts
create mode 100644 board/sielaff/imx6dl-sielaff/Kconfig
create mode 100644 board/sielaff/imx6dl-sielaff/Makefile
create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.c
create mode 100644 board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
create mode 100644 board/sielaff/imx6dl-sielaff/spl.c
create mode 100644 configs/imx6dl_sielaff_defconfig
create mode 100644 include/configs/imx6dl-sielaff.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0fcae77cefe..d60fa1179af 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -930,6 +930,7 @@ dtb-y += \
imx6dl-riotboard.dtb \
imx6dl-sabreauto.dtb \
imx6dl-sabresd.dtb \
+ imx6dl-sielaff.dtb \
imx6dl-wandboard-revd1.dtb \
imx6s-dhcom-drc02.dtb
diff --git a/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
new file mode 100644
index 000..8f5a70ccb85
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff-u-boot.dtsi
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+#include "imx6qdl-u-boot.dtsi"
+
+/ {
+ binman: binman {
+ filename = "flash.bin";
+ pad-byte = <0x00>;
+
+ spl: blob-ext@1 {
+ offset = <0x0>;
+ filename = "SPL";
+ };
+
+ uboot: blob-ext@2 {
+ offset = <0x11000>;
+ filename = "u-boot.img";
+ };
+ };
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ };
+};
+
+ {
+ phy-mode = "rmii";
+ phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <100>;
+};
+
+ {
+ fsl,legacy-bch-geometry;
+};
diff --git a/arch/arm/dts/imx6dl-sielaff.dts b/arch/arm/dts/imx6dl-sielaff.dts
new file mode 100644
index 000..7de8d5f2651
--- /dev/null
+++ b/arch/arm/dts/imx6dl-sielaff.dts
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Copyright (C) 2022 Kontron Electronics GmbH
+ */
+
+/dts-v1/;
+
+#include "imx6dl.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "Sielaff i.MX6 Solo";
+ compatible = "sielaff,imx6dl-board", "fsl,imx6dl";
+
+ chosen {
+ stdout-path =
+ };
+
+ backlight: pwm-backlight {
+ compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <_backlight>;
+ pwms = < 0 5 0>;
+ brightness-levels = <0 0 64 88 112 136 184 232 255>;
+ default-brightness-level = <4>;
+ enable-gpios = < 16 GPIO_ACTIVE_HIGH>;
+ power-supply = <_backlight>;
+ };
+
+ cec {
+ compatible = "cec-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <_hdmi_cec>;
+ cec-gpios = < 7 GPIO_ACTIVE_HIGH>;
+ hdmi-phandle = <>;
+ };
+
+ enet_ref: clock-enet-ref {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <5000>;
+ clock-output-names = "enet-ref";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio_keys>;
+
+ key-0 {
+ gpios = < 16 0>;
+ debounce-interval = <10>;
+ linux,code = <1>;
+ };
+
+ key-1 {
+
[PATCH v2 3/3] doc: board: Add minimal documentation for Sielaff i.MX6 Solo board
From: Frieder Schrempf Describe how to build and boot for the Sielaff i.MX6 Solo board. Signed-off-by: Frieder Schrempf --- Changes in v2: * none --- doc/board/sielaff/imx6dl-sielaff.rst | 32 doc/board/sielaff/index.rst | 9 2 files changed, 41 insertions(+) create mode 100644 doc/board/sielaff/imx6dl-sielaff.rst create mode 100644 doc/board/sielaff/index.rst diff --git a/doc/board/sielaff/imx6dl-sielaff.rst b/doc/board/sielaff/imx6dl-sielaff.rst new file mode 100644 index 000..24dd67ccaef --- /dev/null +++ b/doc/board/sielaff/imx6dl-sielaff.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Sielaff i.MX6 Solo Board + + +The Sielaff i.MX6 Solo board is a control and HMI board for vending +machines. + +Quick Start +--- + +- Build U-Boot +- Boot + +Build U-Boot + + +.. code-block:: bash + + $ make imx6dl_sielaff_defconfig + $ make CROSS_COMPILE=arm-none-linux-gnueabihf- + +Burn the flash.bin to SD card at an offset of 1 KiB: + +.. code-block:: bash + + $ dd if=flash.bin of=/dev/sd[x] bs=1K seek=1 conv=notrunc + +Boot + + +Put the SD card in the slot on the board and apply power. diff --git a/doc/board/sielaff/index.rst b/doc/board/sielaff/index.rst new file mode 100644 index 000..a8376484d88 --- /dev/null +++ b/doc/board/sielaff/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Sielaff +=== + +.. toctree:: + :maxdepth: 2 + + imx6dl-sielaff -- 2.43.0
[PATCH v2 1/3] mtd: spi-nor-ids: Add support for ESMT/EON EN25Q80B
From: Frieder Schrempf
The datasheet can be found here:
https://www.esmt.com.tw/upload/pdf/ESMT/datasheets/EN25Q80B_Ver.E.pdf
Signed-off-by: Frieder Schrempf
Reviewed-by: Fabio Estevam
---
Changes in v2:
* Add R-b tag from Fabio (Thanks!)
---
drivers/mtd/spi/spi-nor-ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 38a287487ed..4e83b8c94c9 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -80,6 +80,7 @@ const struct flash_info spi_nor_ids[] = {
#endif
#ifdef CONFIG_SPI_FLASH_EON/* EON */
/* EON -- en25xxx */
+ { INFO("en25q80b", 0x1c3014, 0, 64 * 1024, 16, SECT_4K) },
{ INFO("en25q32b", 0x1c3016, 0, 64 * 1024, 64, 0) },
{ INFO("en25q64",0x1c3017, 0, 64 * 1024, 128, SECT_4K) },
{ INFO("en25q128b", 0x1c3018, 0, 64 * 1024, 256, 0) },
--
2.43.0
Re: [PATCH 2/3] board: Add support for Sielaff i.MX6 Solo board
Hi Frieder, On Tue, Feb 13, 2024 at 1:58 PM Frieder Schrempf wrote: > I understand the reasoning and I can change that if you insist. But I'm > not really happy about it as we already use the flash.bin as common name > for the binary across all platforms downstream. Also in our upstream > config for the i.MX6UL/ULL SoMs we already use this pattern (see [1]). Ok, I just wanted to point out that there was an alternative, but if you prefer to go with the binman approach in your platforms, I am OK with that. > > Does the 'reset' command work on this board? > > No, I will fix it. Here is an example of how to fix it: https://gitlab.com/u-boot/u-boot/-/commit/dbc4814515d37a3d1c4bb237f4e1c16d1f9e3736
Re: [PATCH 2/3] board: Add support for Sielaff i.MX6 Solo board
Hi Fabio,
thanks for reviewing!
On 10.02.24 19:12, Fabio Estevam wrote:
> Hi Frieder,
>
> On Thu, Feb 8, 2024 at 1:59 PM Frieder Schrempf wrote:
>
>> +/ {
>> + binman: binman {
>> + filename = "flash.bin";
>> + pad-byte = <0x00>;
>> +
>> + spl: blob-ext@1 {
>> + offset = <0x0>;
>> + filename = "SPL";
>> + };
>> +
>> + uboot: blob-ext@2 {
>> + offset = <0x11000>;
>> + filename = "u-boot.img";
>> + };
>> + };
>
> As mentioned in patch 3/3, please remove the binman entry and use
> u-boot-with-spl.imx instead.
I understand the reasoning and I can change that if you insist. But I'm
not really happy about it as we already use the flash.bin as common name
for the binary across all platforms downstream. Also in our upstream
config for the i.MX6UL/ULL SoMs we already use this pattern (see [1]).
>
>> +config TARGET_MX6S_SIELAFF
>> + bool "Sielaff i.MX6 Solo Board"
>> + depends on MX6S
>> + select BINMAN
>
> Please drop it.
>
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +iomux_v3_cfg_t nfc_pads[] = {
>
> Make it static.
OK
>
>> --- /dev/null
>> +++ b/board/sielaff/imx6dl-sielaff/imx6dl-sielaff.env
>> @@ -0,0 +1,115 @@
>> +blkloadfdt=fatload ${device} ${devnum}:${partnum} ${fdt_addr}
>> ${load_fdt_file}
>> +blkloadimage=fatload ${device} ${devnum}:${partnum} ${loadaddr}
>> ${load_image}
>> +boot_devices=usb mmc ubi
>> +bootargs_base=vt.global_cursor_default=0 consoleblank=0 cma=200M
>> fbcon=rotate:1
>> +bootdelay=3
>> +bootdir=
>> +console=ttymxc1,115200
>> +ethact=FEC0
>> +fdt_addr=0x1800
>> +fdt_file_legacy=imx6dl_sielaff.dtb
>> +fdt_file=imx6dl-sielaff.dtb
>> +fdt_high=0x
>> +hostname=mx6s-siline-hmi
>
> Please remove it.
OK
>
>> +void reset_cpu(void)
>> +{
>> +}
>
> Is this needed?
No, I will drop it.
> Does the 'reset' command work on this board?
No, I will fix it.
>> +++ b/configs/imx6dl_sielaff_defconfig
>> @@ -0,0 +1,117 @@
>> +CONFIG_ARM=y
>> +CONFIG_SPL_SYS_ICACHE_OFF=y
>> +CONFIG_SPL_SYS_DCACHE_OFF=y
>
> These options should be dropped.
OK
>
>> +#include
>> +#include
>> +#include "mx6_common.h"
>> +
>> +#define CFG_MXC_UART_BASE UART2_BASE
>
> As you use DM_SERIAL, this can be dropped.
This is still needed as SPL runs without DM due to internal RAM size
constraints.
Thanks
Frieder
[1]
https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/imx6ul-kontron-bl-common-u-boot.dtsi#L10
[PATCH v1] Revert "board: verdin-am62: set cpu core voltage depending on speed grade"
From: Francesco Dolcini
This reverts commit d2099587d661c6ca2309256c0e04c06e26c8d34c.
According to TI changing the VDD_CORE while the SoC is running is not
allowed, the voltage must be set before the AM62 device reset is
released, revert this change therefore.
The correct solution would be to program the PMIC during manufactoring
according to the speed grade of the SoC.
Link:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1318338/am623-booting-from-mmc-failed-after-lowering-vdd_core-to-0-75v/5036508#5036508
Fixes: d2099587d661 ("board: verdin-am62: set cpu core voltage depending on
speed grade")
Signed-off-by: Francesco Dolcini
---
board/toradex/verdin-am62/verdin-am62.c | 47 -
1 file changed, 47 deletions(-)
diff --git a/board/toradex/verdin-am62/verdin-am62.c
b/board/toradex/verdin-am62/verdin-am62.c
index 395eb365a0bf..e948fc16ba99 100644
--- a/board/toradex/verdin-am62/verdin-am62.c
+++ b/board/toradex/verdin-am62/verdin-am62.c
@@ -14,13 +14,10 @@
#include
#include
#include
-#include
#include
#include "../common/tdx-cfg-block.h"
-#define VDD_CORE_REG "buck1"
-
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -53,37 +50,9 @@ int board_fit_config_name_match(const char *name)
}
#endif
-static u32 get_vdd_core_nominal(void)
-{
- int core_uvolt;
-
- switch (k3_get_speed_grade()) {
- case 'G':
- case 'K':
- case 'S':
- core_uvolt = 75;
- break;
- case 'T':
- default:
- core_uvolt = 85;
- break;
- }
- return core_uvolt;
-}
-
#if IS_ENABLED(CONFIG_OF_LIBFDT) && IS_ENABLED(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
- int core_uvolt;
-
- core_uvolt = get_vdd_core_nominal();
- if (core_uvolt != 85) {
- do_fixup_by_path_u32(blob,
"/bus@f/i2c@2000/pmic@30/regulators/buck1",
-"regulator-max-microvolt", core_uvolt, 0);
- do_fixup_by_path_u32(blob,
"/bus@f/i2c@2000/pmic@30/regulators/buck1",
-"regulator-min-microvolt", core_uvolt, 0);
- }
-
return ft_common_board_setup(blob, bd);
}
#endif
@@ -118,22 +87,6 @@ static void select_dt_from_module_version(void)
int board_late_init(void)
{
- int ret;
- int core_uvolt;
- struct udevice *dev = NULL;
-
- core_uvolt = get_vdd_core_nominal();
- if (core_uvolt != 85) {
- /* Set CPU core voltage to 0.75V for slower speed grades */
- ret = regulator_get_by_devname(VDD_CORE_REG, );
- if (ret)
- pr_err("VDD CORE Regulator get error: %d\n", ret);
-
- ret = regulator_set_value_force(dev, core_uvolt);
- if (ret)
- pr_err("VDD CORE Regulator value setting error: %d\n",
ret);
- }
-
select_dt_from_module_version();
return 0;
--
2.39.2
Re: [PATCH 1/3] Dockerfile: Build coreboot from source
On Tue, Feb 13, 2024 at 09:39:26AM -0500, Tom Rini wrote: > To make CI runs rely less on external servers, build a coreboot release > from source and populate /opt/coreboot with the output. > > Signed-off-by: Tom Rini > --- > tools/docker/Dockerfile | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile > index 6122776bc64d..3d044657406e 100644 > --- a/tools/docker/Dockerfile > +++ b/tools/docker/Dockerfile > @@ -231,6 +231,17 @@ RUN mkdir /tmp/trace && \ > sudo make install && \ > rm -rf /tmp/trace > > +# Build coreboot > +RUN wget -O - https://coreboot.org/releases/coreboot-4.22.01.tar.xz | tar -C > /tmp -xJ && \ > +cd /tmp/coreboot-4.22.01 && \ > +make crossgcc-i386 CPUS=$(nproc) && \ > +make -C payloads/coreinfo olddefconfig && \ > +make -C payloads/coreinfo && \ > +make olddefconfig && \ > +make -j $(nproc) && \ > +sudo mkdir /opt/coreboot && \ > +sudo cp build/coreboot.rom build/cbfstool /opt/coreboot/ And I forgot an "rm -rf /tmp/coreboot-4.22.01" at the end here which I'll add while merging if there's no further comments. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/7] AVB: cosmetic adjustments/improvements
Hi, On Fri, 09 Feb 2024 20:20:38 +0100, Igor Opaniuk wrote: > This is the first patch series for incoming major > improvements for AVB implementation, that include: > - Simplify and add more context for debug/error prints where it's needed. > - Move SPDX license identifiers to the first line, so it conforms > to license placement rule. > - Use mmc_switch_part() only for eMMC. > - Rework do_avb_verify_part, take into account device lock state for setting > correct > androidboot.verifiedbootstate. > - Adjust AVB documentation, sync usage info with the one cmd/avb.c. > > [...] Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu (u-boot-dfu) [1/7] common: avb_verify: don't call mmc_switch_part for SD https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/dbde93c12616bd6ba22e6bcb76363a6a3f253087 [2/7] avb: move SPDX license identifiers to the first line https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/bf7d47b4274568927adadeff8c9d1aaf2bd45ca6 [3/7] common: avb_verify: rework error/debug prints https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/bdcc8f8c8fd3dfb053cea7a0f62b34ef062411e0 [4/7] cmd: avb: rework prints https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/055462005fcc48a12a86edf2cbd3f7aa8712788b [5/7] common: avb_verify: add str_avb_io_error/str_avb_slot_error https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/63736ddd4fc357768e31a6f10c10b1a28a10ccbc [6/7] cmd: avb: rework do_avb_verify_part https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/07caf5febcfcfb5f2cdaade124ed8d11735a6029 [7/7] doc: android: avb: sync usage details https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/85af871dcca7e9cae074e3a635706052a57629a4 -- Mattijs
Re: [RESEND PATCH v1] MAINTAINERS: add custodian tree info for AVB/AB
Hi, On Tue, 13 Feb 2024 08:36:38 +0100, Igor Opaniuk wrote: > Add information about a custodian tree [1] for AVB/AB, which is > maintained by Mattijs Korpershoek. > > [1] https://source.denx.de/u-boot/custodians/u-boot-dfu > > Thanks, Applied to https://source.denx.de/u-boot/custodians/u-boot-dfu (u-boot-dfu) [1/1] MAINTAINERS: add custodian tree info for AVB/AB https://source.denx.de/u-boot/custodians/u-boot-dfu/-/commit/71b37060bc59a0a49a18b7c7003c54cac7e1e6b7 -- Mattijs
[PATCH 2/3] CI: Switch to using coreboot from our image
Instead of downloading coreboot binaries from a Google drive location,
use the ones we have built ourselves.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml | 7 +++
.gitlab-ci.yml | 11 +++
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index e2646783ee62..aebcc8908687 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -236,10 +236,9 @@ stages:
cp images/spi-nor.img \${UBOOT_TRAVIS_BUILD_DIR}/;
fi
if [[ "\${TEST_PY_BD}" == "coreboot" ]]; then
- wget -O -
"https://drive.google.com/uc?id=1uJ2VkUQ8czWFZmhJQ90Tp8V_zrJ6BrBH=download;
|xz -dc >\${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
- wget -O -
"https://drive.google.com/uc?id=149Cz-5SZXHNKpi9xg6R_5XITWohu348y=download;
>cbfstool;
- chmod a+x cbfstool;
- ./cbfstool \${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom
add-flat-binary -f \${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c
LZMA -l 0x111 -e 0x111;
+ cp /opt/coreboot/coreboot.rom
\${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
+ /opt/coreboot/cbfstool \${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom
remove -n fallback/payload;
+ /opt/coreboot/cbfstool \${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom
add-flat-binary -f \${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c
LZMA -l 0x111 -e 0x111;
fi
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 278a2e2bbf31..66f3cb14b03a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -70,14 +70,9 @@ stages:
cp images/spi-nor.img ${UBOOT_TRAVIS_BUILD_DIR}/;
fi
- if [[ "${TEST_PY_BD}" == "coreboot" ]]; then
-wget -O -
-
"https://drive.google.com/uc?id=1uJ2VkUQ8czWFZmhJQ90Tp8V_zrJ6BrBH=download;
|
- xz -dc >${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
-wget -O -
-
"https://drive.google.com/uc?id=149Cz-5SZXHNKpi9xg6R_5XITWohu348y=download;
>
- cbfstool;
-chmod a+x cbfstool;
-./cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom add-flat-binary -f
${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c LZMA -l 0x111
-e 0x111;
+cp /opt/coreboot/coreboot.rom ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom;
+/opt/coreboot/cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom remove
-n fallback/payload;
+/opt/coreboot/cbfstool ${UBOOT_TRAVIS_BUILD_DIR}/coreboot.rom
add-flat-binary -f ${UBOOT_TRAVIS_BUILD_DIR}/u-boot.bin -n fallback/payload -c
LZMA -l 0x111 -e 0x111;
fi
- virtualenv -p /usr/bin/python3 /tmp/venv
- . /tmp/venv/bin/activate
--
2.34.1
[PATCH 3/3] CI: Move to latest container image
This moves us to our latest container image, which is now based on the
current "Jammy" tag.
Signed-off-by: Tom Rini
---
.azure-pipelines.yml| 2 +-
.gitlab-ci.yml | 2 +-
tools/docker/Dockerfile | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index aebcc8908687..7c3172610ee6 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -2,7 +2,7 @@ variables:
windows_vm: windows-2019
ubuntu_vm: ubuntu-22.04
macos_vm: macOS-12
- ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20240111-17Jan2024
+ ci_runner_image: trini/u-boot-gitlab-ci-runner:jammy-20240125-12Feb2024
# Add '-u 0' options for Azure pipelines, otherwise we get "permission
# denied" error when it tries to "useradd -m -u 1001 vsts_azpcontainer",
# since our $(ci_runner_image) user is not root.
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 66f3cb14b03a..6ab3bb5ec2aa 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -10,7 +10,7 @@ default:
# Grab our configured image. The source for this is found
# in the u-boot tree at tools/docker/Dockerfile
-image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20240111-17Jan2024
+image: ${MIRROR_DOCKER}/trini/u-boot-gitlab-ci-runner:jammy-20240125-12Feb2024
# We run some tests in different order, to catch some failures quicker.
stages:
diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile
index 3d044657406e..274255456619 100644
--- a/tools/docker/Dockerfile
+++ b/tools/docker/Dockerfile
@@ -2,7 +2,7 @@
# This Dockerfile is used to build an image containing basic stuff to be used
# to build U-Boot and run our test suites.
-FROM ubuntu:jammy-20240111
+FROM ubuntu:jammy-20240125
MAINTAINER Tom Rini
LABEL Description=" This image is for building U-Boot inside a container"
--
2.34.1
[PATCH 1/3] Dockerfile: Build coreboot from source
To make CI runs rely less on external servers, build a coreboot release from source and populate /opt/coreboot with the output. Signed-off-by: Tom Rini --- tools/docker/Dockerfile | 11 +++ 1 file changed, 11 insertions(+) diff --git a/tools/docker/Dockerfile b/tools/docker/Dockerfile index 6122776bc64d..3d044657406e 100644 --- a/tools/docker/Dockerfile +++ b/tools/docker/Dockerfile @@ -231,6 +231,17 @@ RUN mkdir /tmp/trace && \ sudo make install && \ rm -rf /tmp/trace +# Build coreboot +RUN wget -O - https://coreboot.org/releases/coreboot-4.22.01.tar.xz | tar -C /tmp -xJ && \ +cd /tmp/coreboot-4.22.01 && \ +make crossgcc-i386 CPUS=$(nproc) && \ +make -C payloads/coreinfo olddefconfig && \ +make -C payloads/coreinfo && \ +make olddefconfig && \ +make -j $(nproc) && \ +sudo mkdir /opt/coreboot && \ +sudo cp build/coreboot.rom build/cbfstool /opt/coreboot/ + # Create our user/group RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot RUN useradd -m -U uboot -- 2.34.1
Re: [PATCH 3/3] smbios: correctly name Structure Table Maximum Size field
On Thu, 1 Feb 2024 at 02:20, Heinrich Schuchardt
wrote:
>
> In the SMBIOS 3 entry point the Structure Table Maximum Size field was
> incorrectly named max_struct_size. A Maximum Structure Size field only
> exists in the SMBIOS 2.1 entry point and has a different meaning.
>
> Call the Structure Table Length field table_maximum_size.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/smbios.c| 2 +-
> drivers/misc/qfw_smbios.c | 2 +-
> include/smbios.h| 2 +-
> lib/efi_loader/efi_tcg2.c | 4 ++--
> lib/efi_loader/smbiosdump.c | 6 +++---
> lib/smbios-parser.c | 2 +-
> lib/smbios.c| 2 +-
> 7 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/cmd/smbios.c b/cmd/smbios.c
> index e2d82be163..66f6b76137 100644
> --- a/cmd/smbios.c
> +++ b/cmd/smbios.c
> @@ -142,7 +142,7 @@ static int do_smbios(struct cmd_tbl *cmdtp, int flag, int
> argc,
> entry3->major_ver, entry3->minor_ver,
> entry3->doc_rev);
> table = (void *)(uintptr_t)entry3->struct_table_address;
> size = entry3->length;
> - table_maximum_size = entry3->max_struct_size;
> + table_maximum_size = entry3->table_maximum_size;
> } else if (!memcmp(entry, smbios_sig, sizeof(smbios_sig) - 1)) {
> struct smbios_entry *entry2 = entry;
>
> diff --git a/drivers/misc/qfw_smbios.c b/drivers/misc/qfw_smbios.c
> index a898cb4eea..c3e8c310d0 100644
> --- a/drivers/misc/qfw_smbios.c
> +++ b/drivers/misc/qfw_smbios.c
> @@ -90,7 +90,7 @@ static int qfw_parse_smbios_anchor(struct udevice *dev,
> entry->length = sizeof(struct smbios3_entry);
> entry->major_ver = entry2->major_ver;
> entry->minor_ver = entry2->minor_ver;
> - entry->max_struct_size = entry2->struct_table_length;
> + entry->table_maximum_size = entry2->struct_table_length;
> } else {
> ret = -ENOENT;
> goto out;
> diff --git a/include/smbios.h b/include/smbios.h
> index e2b7f69584..3df8827b60 100644
> --- a/include/smbios.h
> +++ b/include/smbios.h
> @@ -75,7 +75,7 @@ struct __packed smbios3_entry {
> /** @reserved: reserved */
> u8 reserved;
> /** maximum size of SMBIOS table */
> - u32 max_struct_size;
> + u32 table_maximum_size;
> /** @struct_table_address: 64-bit physical starting address */
> u64 struct_table_address;
> };
> diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
> index b5d4aa7be5..b07e0099c2 100644
> --- a/lib/efi_loader/efi_tcg2.c
> +++ b/lib/efi_loader/efi_tcg2.c
> @@ -1098,7 +1098,7 @@ tcg2_measure_smbios(struct udevice *dev,
> */
> event_size = sizeof(struct smbios_handoff_table_pointers2) +
> FIELD_SIZEOF(struct efi_configuration_table, guid) +
> -entry->max_struct_size;
> +entry->table_maximum_size;
> event = calloc(1, event_size);
> if (!event) {
> ret = EFI_OUT_OF_RESOURCES;
> @@ -1113,7 +1113,7 @@ tcg2_measure_smbios(struct udevice *dev,
> smbios_copy = (struct smbios_header
> *)((uintptr_t)>table_entry[0].table);
> memcpy(>table_entry[0].table,
>(void *)((uintptr_t)entry->struct_table_address),
> - entry->max_struct_size);
> + entry->table_maximum_size);
>
> smbios_prepare_measurement(entry, smbios_copy);
>
> diff --git a/lib/efi_loader/smbiosdump.c b/lib/efi_loader/smbiosdump.c
> index f0b901897e..2f0b91a353 100644
> --- a/lib/efi_loader/smbiosdump.c
> +++ b/lib/efi_loader/smbiosdump.c
> @@ -329,7 +329,7 @@ efi_status_t do_check(void)
> return EFI_LOAD_ERROR;
> }
> table = (void
> *)(uintptr_t)smbios3_anchor->struct_table_address;
> - len = smbios3_anchor->max_struct_size;
> + len = smbios3_anchor->table_maximum_size;
> } else {
> struct smbios_entry *smbios_anchor;
> int r;
> @@ -469,7 +469,7 @@ static efi_status_t do_save(u16 *filename)
>
> smbios3_anchor = get_config_table(_guid);
> if (smbios3_anchor) {
> - size = 0x20 + smbios3_anchor->max_struct_size;
> + size = 0x20 + smbios3_anchor->table_maximum_size;
> ret = bs->allocate_pool(EFI_LOADER_DATA, size, (void **));
> if (ret != EFI_SUCCESS) {
> error(u"Out of memory\n");
> @@ -480,7 +480,7 @@ static efi_status_t do_save(u16 *filename)
> memcpy(buf, smbios3_anchor, smbios3_anchor->length);
> memcpy(buf + 0x20,
>(void
> *)(uintptr_t)smbios3_anchor->struct_table_address,
> - smbios3_anchor->max_struct_size);
> + smbios3_anchor->table_maximum_size);
>
>
Re: [PATCH 1/3] cmd: smbios: show correct table size for SMBIOS2.1 entry point
On Thu, 1 Feb 2024 at 02:20, Heinrich Schuchardt
wrote:
>
> The SMBIOS table size for SMBIOS2.1 entry points is in field 'Structure
> Table Length' (offset 0x16) and not in field 'Maximum Structure Size'
> (offset 0x08).
>
> Rename the receiving variable max_struct_size to table_maximum_size
> to avoid future confusion.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/smbios.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/cmd/smbios.c b/cmd/smbios.c
> index 95bdff6026..e2d82be163 100644
> --- a/cmd/smbios.c
> +++ b/cmd/smbios.c
> @@ -126,7 +126,7 @@ static int do_smbios(struct cmd_tbl *cmdtp, int flag, int
> argc,
> static const char smbios_sig[] = "_SM_";
> static const char smbios3_sig[] = "_SM3_";
> size_t count = 0;
> - u32 max_struct_size;
> + u32 table_maximum_size;
>
> addr = gd_smbios_start();
> if (!addr) {
> @@ -142,7 +142,7 @@ static int do_smbios(struct cmd_tbl *cmdtp, int flag, int
> argc,
> entry3->major_ver, entry3->minor_ver,
> entry3->doc_rev);
> table = (void *)(uintptr_t)entry3->struct_table_address;
> size = entry3->length;
> - max_struct_size = entry3->max_struct_size;
> + table_maximum_size = entry3->max_struct_size;
> } else if (!memcmp(entry, smbios_sig, sizeof(smbios_sig) - 1)) {
> struct smbios_entry *entry2 = entry;
>
> @@ -150,7 +150,7 @@ static int do_smbios(struct cmd_tbl *cmdtp, int flag, int
> argc,
> entry2->major_ver, entry2->minor_ver);
> table = (void *)(uintptr_t)entry2->struct_table_address;
> size = entry2->length;
> - max_struct_size = entry2->max_struct_size;
> + table_maximum_size = entry2->struct_table_length;
> } else {
> log_err("Unknown SMBIOS anchor format\n");
> return CMD_RET_FAILURE;
> @@ -163,7 +163,7 @@ static int do_smbios(struct cmd_tbl *cmdtp, int flag, int
> argc,
>
> for (struct smbios_header *pos = table; pos; pos = next_table(pos))
> ++count;
> - printf("%zd structures occupying %d bytes\n", count, max_struct_size);
> + printf("%zd structures occupying %d bytes\n", count,
> table_maximum_size);
> printf("Table at 0x%llx\n", (unsigned long long)map_to_sysmem(table));
>
> for (struct smbios_header *pos = table; pos; pos = next_table(pos)) {
> --
> 2.43.0
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH v2] test/py: reset: Add a test for reset command
On Tue, Feb 13, 2024 at 06:26:56PM +0530, Love Kumar wrote:
> Add a test for reset commands which performs resetting of CPU, It does
> COLD reset by default and WARM reset with -w option.
>
> Signed-off-by: Love Kumar
> ---
> Changes in v2:
> - Set bootmode through boardenv if modeboot is not defined
Still fails on sandbox:
test/py/tests/test_reset.py F
== FAILURES
===
_ test_reset
__
test/py/tests/test_reset.py:49: in test_reset
setup_reset_env(u_boot_console)
test/py/tests/test_reset.py:32: in setup_reset_env
output = u_boot_console.run_command('print modeboot')
test/py/u_boot_console_base.py:269: in run_command
raise Exception('Bad pattern found on console: ' +
E Exception: Bad pattern found on console: error_notification
Captured stdout call
-
=> print modeboot
## Error: "modeboot" not defined
Please note that
https://docs.u-boot.org/en/latest/develop/py_testing.html talks about
how to run the pytests on sandbox as well, for next time.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] test/py: saveenv: Add a test for saveenv command
On Tue, Feb 13, 2024 at 06:26:44PM +0530, Love Kumar wrote:
> Add test case for saveenv command in non-JTAG bootmode which saves the
> u-boot environment variables in persistent storage.
>
> Signed-off-by: Love Kumar
> ---
> Changes in v2:
> - Set bootmode through boardenv if modeboot is not defined
Please fix:
== warnings summary
===
test/py/tests/test_saveenv.py:115
/home/uboot/work/u-boot/u-boot/test/py/tests/test_saveenv.py:115:
DeprecationWarning: invalid escape sequence '\('
sc = "!#%&\()*+,-./:;<=>?@[\\]^_`{|}~"
-- Docs: https://docs.pytest.org/en/stable/warnings.html
Thanks.
--
Tom
signature.asc
Description: PGP signature
[PATCH] MAINTAINERS: Update after GEHC spin-off
Update our email addresses, from @ge.com to @gehealthcare.com, after GE HealthCare was spun-off from GE. Remove Antti, who no longer works on the project. Signed-off-by: Ian Ray --- MAINTAINERS | 2 +- board/ge/b1x5v2/MAINTAINERS | 4 ++-- board/ge/bx50v3/MAINTAINERS | 2 +- board/ge/mx53ppd/MAINTAINERS | 3 +-- 4 files changed, 5 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 46ba17647f..338b7b6348 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -453,7 +453,7 @@ F: drivers/timer/mchp-pit64b-timer.c ARM MSC SM2S IMX8MP SOM M: Martyn Welch -M: Ian Ray +M: Ian Ray S: Maintained F: arch/arm/dts/imx8mp-msc-sm2s* F: board/msc/sm2s_imx8mp/ diff --git a/board/ge/b1x5v2/MAINTAINERS b/board/ge/b1x5v2/MAINTAINERS index 3196ddbb51..7312f4be1a 100644 --- a/board/ge/b1x5v2/MAINTAINERS +++ b/board/ge/b1x5v2/MAINTAINERS @@ -1,6 +1,6 @@ GE B1X5V2 BOARD -M: Huan 'Kitty' Wang -M: Ian Ray +M: Huan 'Kitty' Wang +M: Ian Ray M: Martyn Welch S: Maintained F: arch/arm/dts/imx6dl-b1x5v2.dts diff --git a/board/ge/bx50v3/MAINTAINERS b/board/ge/bx50v3/MAINTAINERS index c165048336..53a8d88a90 100644 --- a/board/ge/bx50v3/MAINTAINERS +++ b/board/ge/bx50v3/MAINTAINERS @@ -1,5 +1,5 @@ GE BX50V3 BOARD -M: Ian Ray +M: Ian Ray M: Martyn Welch S: Maintained F: arch/arm/dts/imx6q-b450v3.dts diff --git a/board/ge/mx53ppd/MAINTAINERS b/board/ge/mx53ppd/MAINTAINERS index 146a460e7e..19e4ea7593 100644 --- a/board/ge/mx53ppd/MAINTAINERS +++ b/board/ge/mx53ppd/MAINTAINERS @@ -1,6 +1,5 @@ GE PPD BOARD -M: Antti Mäentausta -M: Ian Ray +M: Ian Ray M: Martyn Welch S: Maintained F: arch/arm/dts/imx53-ppd* -- 2.39.2
Re: [PATCH v2 1/7] common: avb_verify: don't call mmc_switch_part for SD
Hi Igor, On mar., févr. 13, 2024 at 12:19, Igor Opaniuk wrote: > Hi Mattijs, > > On Tue, Feb 13, 2024 at 9:13 AM Mattijs Korpershoek > wrote: >> >> Hi Igor, >> >> On lun., févr. 12, 2024 at 09:05, Igor Opaniuk >> wrote: >> >> > Hi Dan, >> > >> > On Mon, Feb 12, 2024 at 8:05 AM Dan Carpenter >> > wrote: >> >> >> >> On Fri, Feb 09, 2024 at 08:20:39PM +0100, Igor Opaniuk wrote: >> >> > From: Igor Opaniuk >> >> > >> >> > mmc_switch_part() is used for switching between hw partitions >> >> > on eMMC (boot0, boot1, user, rpmb). >> >> > There is no need to do that for SD card. >> >> > >> >> >> >> Is this a clean up or a bugfix? What are the visible effects for the >> >> user? >> > avb cmd fails for SD cards, as mmc_switch_part() fails after trying to >> > access >> > EXT_CSD register, which obviously is not available. >> >> Does this means that we only need this patch to fix AVB commands when >> booting from SD cards? >> >> If yes, I propose adding the following note to the commit message: >> >> "This fixes the avb command usage on on SD cards." >> >> If you agree, I can do this while applying. > Yes, could you please add to the commit message so I don't > send v3 for that (if there are no any additional objections/comments) There are no additional objections, comments on my end. I will add this to the commit message when applying. > > Thanks >> >> If not, we can keep the message as is. >> >> >> >> >> regards, >> >> dan carpenter >> >> >> > >> > >> > -- >> > Best regards - Atentamente - Meilleures salutations >> > >> > Igor Opaniuk >> > >> > mailto: igor.opan...@gmail.com >> > skype: igor.opanyuk >> > http://ua.linkedin.com/in/iopaniuk > > > > -- > Best regards - Atentamente - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > http://ua.linkedin.com/in/iopaniuk
Re: [PATCH v1] MAINTAINERS: add custodian tree info for AV/AVB
Hi Marek, Thank you for your review. On mar., févr. 13, 2024 at 12:55, Marek Vasut wrote: > On 2/13/24 08:32, Igor Opaniuk wrote: >> From: Igor Opaniuk >> >> Add information about a custodian tree [1] for AVB/AB, which is >> maintained by Mattijs Korpershoek. >> >> [1] https://source.denx.de/u-boot/custodians/u-boot-dfu >> Signed-off-by: Igor Opaniuk > > Reviewed-by: Marek Vasut As this patch has a typo in the title (AV->AB), I will instead apply your R-b to: https://lore.kernel.org/r/all/20240213073638.1125429-1-igor.opan...@foundries.io/ Thanks! Mattijs
Re: [PATCH v2 2/3] arm: mvebu: helios4_defconfig: enable setexpr command
Hi Dennis,
Use-case is with separate boot and rootfs partitions to calculate
next partition number as argument for further commands:
setexpr openwrt_rootpart ${distro_bootpart} + 1
part uuid ${devtype} ${devnum}:${openwrt_rootpart} uuid
setenv bootargs ${bootargs} root=PARTUUID=${uuid} rootfstype=auto rootwait
- Josua Mayer
Am 12.02.24 um 21:40 schrieb Dennis Gilmore:
> I am curious about your use cases for this. as ideally all systems use the
> generic distro boot paths and it is not needed for them.
>
> Dennis
>
> On Fri, Feb 2, 2024 at 9:13 AM Josua Mayer wrote:
>
> Update the helios4 defconfig to enable the 'setexpr' command, which is a
> default and useful for various complex boot-scripts.
>
> Signed-off-by: Josua Mayer
> ---
> configs/helios4_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/configs/helios4_defconfig b/configs/helios4_defconfig
> index 04194004f0..73f0638344 100644
> --- a/configs/helios4_defconfig
> +++ b/configs/helios4_defconfig
> @@ -44,7 +44,6 @@ CONFIG_CMD_MMC=y
> CONFIG_CMD_PCI=y
> CONFIG_CMD_SPI=y
> CONFIG_CMD_USB=y
> -# CONFIG_CMD_SETEXPR is not set
> CONFIG_CMD_TFTPPUT=y
> CONFIG_CMD_CACHE=y
> CONFIG_CMD_TIME=y
>
> --
> 2.35.3
>
>
>
> --
> Dennis Gilmore
> Senior Manager Systems Enablement OpenShift Development
[PATCH v2] test/py: reset: Add a test for reset command
Add a test for reset commands which performs resetting of CPU, It does
COLD reset by default and WARM reset with -w option.
Signed-off-by: Love Kumar
---
Changes in v2:
- Set bootmode through boardenv if modeboot is not defined
---
test/py/tests/test_reset.py | 63 +
1 file changed, 63 insertions(+)
create mode 100644 test/py/tests/test_reset.py
diff --git a/test/py/tests/test_reset.py b/test/py/tests/test_reset.py
new file mode 100644
index ..6153a6d3e4d2
--- /dev/null
+++ b/test/py/tests/test_reset.py
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+"""
+Note: This test doesn't rely on boardenv_* configuration value but they can
+change test behavior.
+
+For example:
+
+# Setup env__reset_test_skip to True if reset test is not possible or desired
+# and should be skipped.
+env__reset_test_skip = True
+
+# Setup env__reset_test to set the bootmode if 'modeboot' u-boot environment
+# variable is not set. Test will be skipped if bootmode is not set in both
+# places i.e, boardenv and modeboot u-boot environment variable
+env__reset_test = {
+'bootmode': 'qspiboot',
+}
+
+# This test will be also skipped if the bootmode is detected to JTAG.
+"""
+
+import pytest
+import re
+import test_000_version
+
+def setup_reset_env(u_boot_console):
+if u_boot_console.config.env.get('env__reset_test_skip', False):
+pytest.skip('reset test is not enabled')
+
+output = u_boot_console.run_command('print modeboot')
+if 'not defined' in output:
+f = u_boot_console.config.env.get('env__reset_test', None)
+if not f:
+pytest.skip('bootmode cannot be determined')
+bootmode = f.get('bootmode', 'jtagboot')
+else:
+m = re.search('modeboot=(.+)', output)
+bootmode = m.group(1)
+
+if 'jtag' in bootmode:
+pytest.skip('skipping reset test due to jtag bootmode')
+
+def test_reset(u_boot_console):
+"""Test the reset command in non-JTAG bootmode.
+It does COLD reset, which resets CPU, DDR and peripherals
+"""
+setup_reset_env(u_boot_console)
+u_boot_console.run_command('reset', wait_for_reboot=True)
+
+# Checks the u-boot command prompt's functionality after reset
+test_000_version.test_version(u_boot_console)
+
+def test_reset_w(u_boot_console):
+"""Test the reset -w command in non-JTAG bootmode.
+It does WARM reset, which resets CPU but keep DDR/peripherals active.
+"""
+setup_reset_env(u_boot_console)
+u_boot_console.run_command('reset -w', wait_for_reboot=True)
+
+# Checks the u-boot command prompt's functionality after reset
+test_000_version.test_version(u_boot_console)
--
2.25.1
[PATCH v2] test/py: saveenv: Add a test for saveenv command
Add test case for saveenv command in non-JTAG bootmode which saves the
u-boot environment variables in persistent storage.
Signed-off-by: Love Kumar
---
Changes in v2:
- Set bootmode through boardenv if modeboot is not defined
---
test/py/tests/test_saveenv.py | 138 ++
1 file changed, 138 insertions(+)
create mode 100644 test/py/tests/test_saveenv.py
diff --git a/test/py/tests/test_saveenv.py b/test/py/tests/test_saveenv.py
new file mode 100644
index ..cac854d82bab
--- /dev/null
+++ b/test/py/tests/test_saveenv.py
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: GPL-2.0
+# (C) Copyright 2023, Advanced Micro Devices, Inc.
+
+"""
+Note: This test doesn't rely on boardenv_* configuration value but they can
+change test behavior.
+
+For example:
+
+# Setup env__saveenv_test_skip to True if saveenv test is not possible or
+# desired and should be skipped.
+env__saveenv_test_skip = True
+
+# Setup env__saveenv_test to set the bootmode if 'modeboot' u-boot environment
+# variable is not set. Test will be skipped if bootmode is not set in both
+# places i.e, boardenv and modeboot u-boot environment variable
+env__saveenv_test = {
+'bootmode': 'qspiboot',
+}
+
+# This test will be also skipped if the bootmode is detected to JTAG.
+"""
+
+import pytest
+import re
+import random
+import ipaddress
+import string
+import uuid
+
+# Setup the env
+def setup_saveenv_env(u_boot_console):
+if u_boot_console.config.env.get('env__saveenv_test_skip', False):
+pytest.skip('saveenv test is not enabled')
+
+output = u_boot_console.run_command('print modeboot')
+if 'not defined' in output:
+f = u_boot_console.config.env.get('env__saveenv_test', None)
+if not f:
+pytest.skip('bootmode cannot be determined')
+bootmode = f.get('bootmode', 'jtagboot')
+else:
+m = re.search('modeboot=(.+)', output)
+bootmode = m.group(1)
+
+if 'jtag' in bootmode:
+pytest.skip('skipping saveenv test due to jtag bootmode')
+
+# Check return code
+def ret_code(u_boot_console):
+return u_boot_console.run_command('echo $?')
+
+# Verify env variable
+def check_env(u_boot_console, var_name, var_value):
+if var_value:
+output = u_boot_console.run_command(f'printenv {var_name}')
+var_value = str(var_value)
+if (var_value.startswith("'") and var_value.endswith("'")) or (
+var_value.startswith('"') and var_value.endswith('"')
+):
+var_value = var_value.split(var_value[-1])[1]
+assert var_value in output
+assert ret_code(u_boot_console).endswith('0')
+else:
+u_boot_console.p.send(f'printenv {var_name}\n')
+output = u_boot_console.p.expect(['not defined'])
+assert output == 0
+assert ret_code(u_boot_console).endswith('1')
+
+# Set env variable
+def set_env(u_boot_console, var_name, var_value):
+u_boot_console.run_command(f'setenv {var_name} {var_value}')
+assert ret_code(u_boot_console).endswith('0')
+check_env(u_boot_console, var_name, var_value)
+
+@pytest.mark.buildconfigspec('cmd_saveenv')
+def test_saveenv(u_boot_console):
+"""Test the saveenv command in non-JTAG bootmode.
+It saves the U-Boot environment in persistent storage.
+"""
+setup_saveenv_env(u_boot_console)
+
+# Set env for random mac address
+rand_mac = '%02x:%02x:%02x:%02x:%02x:%02x' % (
+random.randint(0, 255),
+random.randint(0, 255),
+random.randint(0, 255),
+random.randint(0, 255),
+random.randint(0, 255),
+random.randint(0, 255),
+)
+set_env(u_boot_console, 'mac_addr', rand_mac)
+
+# Set env for random IPv4 address
+rand_ipv4 = ipaddress.IPv4Address._string_from_ip_int(
+random.randint(0, ipaddress.IPv4Address._ALL_ONES)
+)
+set_env(u_boot_console, 'ipv4_addr', rand_ipv4)
+
+# Set env for random IPv6 address
+rand_ipv6 = ipaddress.IPv6Address._string_from_ip_int(
+random.randint(0, ipaddress.IPv6Address._ALL_ONES)
+)
+set_env(u_boot_console, 'ipv6_addr', rand_ipv6)
+
+# Set env for random number
+rand_num = random.randrange(1, 10**9)
+set_env(u_boot_console, 'num_var', rand_num)
+
+# Set env for uuid
+uuid_str = uuid.uuid4().hex.lower()
+set_env(u_boot_console, 'uuid_var', uuid_str)
+
+# Set env for random string including special characters
+sc = "!#%&\()*+,-./:;<=>?@[\\]^_`{|}~"
+rand_str = ''.join(
+random.choices(' ' + string.ascii_letters + sc + string.digits, k=300)
+)
+set_env(u_boot_console, 'str_var', f'"{rand_str}"')
+
+# Set env for empty string
+set_env(u_boot_console, 'empty_var', '')
+
+# Save the env variables
+u_boot_console.run_command('saveenv')
+assert ret_code(u_boot_console).endswith('0')
+
+# Reboot
+u_boot_console.run_command('reset', wait_for_reboot=True)
+
+# Verify the saved env variables
+
Re: [PATCH v5 00/11] An effort to bring DT bindings compliance within U-Boot
On Tue, 6 Feb 2024 at 18:30, Tom Rini wrote: > > On Tue, Feb 06, 2024 at 10:57:12AM +0530, Sumit Garg wrote: > > Hi Tom, > > > > On Fri, 2 Feb 2024 at 23:32, Tom Rini wrote: > > > > > > On Fri, Feb 02, 2024 at 06:35:23PM +0530, Sumit Garg wrote: > > > > > > > Changes in v5: > > > > -- > > > > - Rebased on tip of master (050a9b981d6a835133521b599be3ae189ce70f41) > > > > - Created v5_dt branch for testing purposes: > > > > https://github.com/b49020/u-boot/tree/v5_dt > > > > - Patch #6: Added support to cherry-pick fixes in subtree update script. > > > > Also, used https:// instead of git://. > > > > - Patch #7: Fixed inappropriate documentation update. > > > > - Patch #8: Document how to cherry-pick fixes from devicetree-rebasing > > > > tree. > > > > > > OK, for v6 please push this through CI. I've started a run now to check > > > other things, but just sandbox currently fails to build right now. > > > > Yeah it looks like patch#3 rework in v4 has broken EFI capsule .dtsi > > file generation logic which should be fixed by add-on fix [1] for > > patch#3. The github CI passes [2] with that included. I suppose the > > gitlab CI should be fine too. If its fine for your testing as well > > then I will incorporate it in v6. > > > > [1] > > https://github.com/u-boot/u-boot/pull/484/commits/d796c34307cd363674e0d0d2e31618643ac8e76c > > [2] https://github.com/u-boot/u-boot/pull/484 > > Yup, if Azure passes GitLab should pass too. I think you should wait to > repost v6 until you and Marek agree about how we are (and perhaps > aren't) handling fixes to dts files. > Although I haven't received any further feedback/comments but will wait for a few more days before posting v6. -Sumit > -- > Tom
Re: Booting from NFSv4 file system?
On Tue, 13 Feb 2024 at 12:18, Cedric Blancher wrote: > > Good morning! > > Does U-Boot support booting from a NFSv4 file system? Explicitly > neither NFSv2 or NFSv3 will work in our case, as both protocol > versions are depreciated and no longer allowed by our IT department. Not that I am aware of, at least not upstream, there is work being done to support booting using UEFI HTTP boot if HTTP is more straight forward for network booting.
Booting from NFSv4 file system?
Good morning! Does U-Boot support booting from a NFSv4 file system? Explicitly neither NFSv2 or NFSv3 will work in our case, as both protocol versions are depreciated and no longer allowed by our IT department. Ced -- Cedric Blancher [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
Warning: eth0 MAC addresses don't match:
We are trying to move a board from QSDK to OpenWRT, however, once we had the image built and flashed bootipq exited with Net: MAC0 addr:44:d1:fa:a4:f1:66 PHY ID1: 0x4d PHY ID2: 0xd101 EDMA ver 1 hw init Num rings - TxDesc:1 (0-0) TxCmpl:1 (0-0) RxDesc:1 (15-15) RxFill:1 (7-7) ipq6018_edma_alloc_rings: successfull ipq6018_edma_setup_ring_resources: successfull ipq6018_edma_configure_rings: successfull ipq6018_edma_hw_init: successfull , eth0 Warning: eth0 MAC addresses don't match: Address in SROM is 44:d1:fa:a4:f1:66 Address in environment is 44:d1:fa:a4:f1:67 and printenv shows IPQ6018# printenv baudrate=115200 bootargs=console=ttyMSM0,115200n8 ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs rootwait ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs rootwait ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squt bootcmd=bootipq bootdelay=2 eth1addr=44:d1:fa:a4:f1:67 eth2addr=44:d1:fa:a4:f1:68 eth3addr=44:d1:fa:a4:f1:69 eth4addr=44:d1:fa:a4:f1:6a ethact=eth0 ethaddr=44:d1:fa:a4:f1:66 fdt_high=0x4850 fdtcontroladdr=4a46e7d0 flash_type=7 fsbootargs=ubi.mtd=rootfs root=mtd:ubi_rootfs rootfstype=squashfs ipaddr=192.168.10.10 machid=803 mtddevname=fs mtddevnum=0 mtdids=nand0=nand0 mtdparts=mtdparts=nand0:0x3c0@0x0(fs), netmask=255.255.255.0 partition=nand0,0 serverip=192.168.10.1 soc_version_major=1 soc_version_minor=0 stderr=serial@78B1000 stdin=serial@78B1000 stdout=serial@78B1000 Environment size: 887/65532 bytes SO how can i resolve booting this device? -- Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
Re: [PATCH v1] MAINTAINERS: add custodian tree info for AV/AVB
On 2/13/24 08:32, Igor Opaniuk wrote: From: Igor Opaniuk Add information about a custodian tree [1] for AVB/AB, which is maintained by Mattijs Korpershoek. [1] https://source.denx.de/u-boot/custodians/u-boot-dfu Signed-off-by: Igor Opaniuk Reviewed-by: Marek Vasut
Re: [FIX PATCH v1] Fix: common: usb_hub: Reset only USB3.0 hub
On 2/13/24 04:59, Dragan Simic wrote:
On 2024-02-13 00:33, Marek Vasut wrote:
On 2/12/24 22:10, Dragan Simic wrote:
On 2024-02-12 21:19, Marek Vasut wrote:
On 2/12/24 14:41, Shantur Rathore wrote:
On Mon, Feb 12, 2024 at 1:40 PM Shantur Rathore wrote:
On Sat, Feb 10, 2024 at 7:13 AM Dragan Simic
wrote:
On 2024-02-08 15:17, Dragan Simic wrote:
On 2024-02-08 15:10, Shantur Rathore wrote:
On Thu, Feb 8, 2024 at 1:44 PM Dragan Simic
wrote:
On 2024-02-08 14:33, Marek Vasut wrote:
On 2/8/24 12:30, Shantur Rathore wrote:
On Wed, Feb 7, 2024 at 1:07 PM Marek Vasut
wrote:
On 2/7/24 11:23, Shantur Rathore wrote:
USB 3.0 spec requires hub to reset device while
enumeration. Some USB 2.0 hubs / devices don't
handle this well and after implementation of
reset some USB 2.0 disks weren't detected on
Allwinner based boards.
Resetting only when hub is USB 3.0 fixes it.
It would be good to include as many details about the
faulty hardware
in
the commit message as possible, so that when someone else
runs into
this, they would have all that information available.
Tested-by: Andre Przywara
Signed-off-by: Shantur Rathore
---
common/usb_hub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/common/usb_hub.c b/common/usb_hub.c
index 3fb7e14d10..2e054eb935 100644
--- a/common/usb_hub.c
+++ b/common/usb_hub.c
@@ -174,8 +174,10 @@ static void usb_hub_power_on(struct
usb_hub_device *hub)
debug("enabling power on all ports\n");
for (i = 0; i < dev->maxchild; i++) {
- usb_set_port_feature(dev, i + 1,
USB_PORT_FEAT_RESET);
- debug("Reset : port %d returns %lX\n", i + 1,
dev->status);
+ if (usb_hub_is_superspeed(dev)) {
Should this condition be "all which are lower than superspeed"
instead ,
so when the next generation of USB comes, this problem
won't trigger
?
What does Linux do btw ?
As of now Linux checks if the hub is superspeed
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.c#L2859
which is
return hdev->descriptor.bDeviceProtocol == USB_HUB_PR_SS; //
USB_HUB_PR_SS = 3
This holds true for newer SuperSpeedPlus hubs as well.
https://github.com/torvalds/linux/blob/master/drivers/usb/core/hub.h#L155
We can change the check to be bDeviceProtocol > 2 but who
knows if
things change in the newer version of spec.
I am open to suggestions.
Please just include the ^ in the commit description. Use link to
git.kernel.org , not some mirror . This is extremely useful
information and, well, you already wrote the V2 commit message
addition in this answer.
Shantur, if that would be easier or quicker for you, I can write
a quite detailed patch description for you, in exchange for a
"Helped-by" tag in the v2 patch submission. :)
That would be really kind of you Dragan.
Sure, I'll write the summary and send it over.
I am down with the flu so that would really help me as my brain is
working at 15% capacity.
Oh, I'm really sorry to hear that. :( I hope you'll get better
soon, and I know very well what's it like; I've also been sick
recently, as a result of some kind of flu that unfortunately found
its way into my lungs, and it took me about a month to get back
to about 90% of my usual mental capacity. I'm still not back to
exactly 100%. :/
I really hope you'll recover much faster.
I hope you're feeling better.
Below are the patch subject and description that I prepared for you,
please have a look.
--- >8 - >8 - >8 - >8
---
[PATCH v2] common: usb-hub: Reset USB 3.0 hubs only
Additional testing of the changes introduced in commit 33e06dcbe57a
("common:
usb-hub: Reset hub port before scanning") revealed that some USB 3.0
flash
I think it was a USB 2.0 drive that didn't work on the USB 2.0 port.
drives didn't work in U-Boot on some Allwinner SoCs that support
USB 2.0
only.
More precisely, some tested USB 3.0 flash drives failed to be
detected
and
work on an OrangePi Zero 3 with Allwinner H616 SoC, which
supports USB
2.0
only, while the same USB flash drives worked just fine on a
Pine64 H64
with
Allwinner H6 SoC, which supports both USB 2.0 and 3.0.
Resetting USB 3.0 hubs only has been tested to work as expected,
resolving
the previous issues on the Allwinner H616, while not introducing
any new
issues on other Allwinner SoCs. Thus, let's fix it that way.
According to the USB 3.0 specification, resetting a USB 3.0 port is
required
when an attached USB device transitions between different states,
such
as
when it resumes from suspend. Though, the Linux kernel performs
additional
USB 3.0 port resets upon initial USB device attachment,
presumably to
ensure
proper state of the USB 3.0 hub port and proper USB mode negotiation
during
the initial USB device attachment and enumeration.
Such USB port resets don't seem to exist for USB 2.0 hubs,
according the
USB
2.0 specification. The resets seem to be added to the USB 3.0
[PATCH 5/5] msc_sm2s_imx8mp: Fix CONFIG_DEFAULT_FDT_FILE
From: Fabio Estevam There is no imx8mp-msc-sm2s.dtb file in upstream Linux. Change it to imx8mp-msc-sm2s-ep1.dtb. Signed-off-by: Fabio Estevam --- configs/msc_sm2s_imx8mp_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/msc_sm2s_imx8mp_defconfig b/configs/msc_sm2s_imx8mp_defconfig index 3a49b7d55c..5688c7a64d 100644 --- a/configs/msc_sm2s_imx8mp_defconfig +++ b/configs/msc_sm2s_imx8mp_defconfig @@ -28,7 +28,7 @@ CONFIG_SPL_LOAD_FIT=y CONFIG_SYS_BOOTM_LEN=0x200 CONFIG_DISTRO_DEFAULTS=y CONFIG_OF_SYSTEM_SETUP=y -CONFIG_DEFAULT_FDT_FILE="imx8mp-msc-sm2s.dtb" +CONFIG_DEFAULT_FDT_FILE="imx8mp-msc-sm2s-ep1.dtb" CONFIG_SYS_CBSIZE=2048 CONFIG_SYS_PBSIZE=2074 CONFIG_SPL_MAX_SIZE=0x26000 -- 2.34.1
[PATCH 4/5] msc_sm2s_imx8mp: Add redundant environment support
From: Fabio Estevam Redundant environment support is required for software updates. Add support for it. Signed-off-by: Fabio Estevam --- configs/msc_sm2s_imx8mp_defconfig | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/msc_sm2s_imx8mp_defconfig b/configs/msc_sm2s_imx8mp_defconfig index a190c1ea22..3a49b7d55c 100644 --- a/configs/msc_sm2s_imx8mp_defconfig +++ b/configs/msc_sm2s_imx8mp_defconfig @@ -5,7 +5,8 @@ CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SPL_GPIO=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y -CONFIG_ENV_SIZE=0x1000 +CONFIG_ENV_SIZE=0x4000 +CONFIG_ENV_OFFSET=0x20 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="imx8mp-msc-sm2s" CONFIG_SPL_TEXT_BASE=0x92 @@ -16,6 +17,7 @@ CONFIG_SPL_SERIAL=y CONFIG_SPL_DRIVERS_MISC=y CONFIG_SPL_STACK=0x96 CONFIG_SPL=y +CONFIG_ENV_OFFSET_REDUND=0x204000 CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 CONFIG_SYS_LOAD_ADDR=0x4048 CONFIG_SYS_BOOT_GET_CMDLINE=y @@ -62,6 +64,8 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y CONFIG_SPL_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_REDUNDAND_ENVIRONMENT=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y CONFIG_USE_ETHPRIME=y -- 2.34.1
[PATCH 2/5] msc_sm2s_imx8mp: Make Ethernet functional
From: Fabio Estevam Currently, the Ethernet ports are not working. The Ethernet PHY reset lines are controlled by the TCA6424 I2C GPIO expander. The TCA6424 I2C GPIO expander is supported by the CONFIG_DM_PCA953X driver. Select the CONFIG_DM_PCA953X option so that the Ethernet PHYs can go through a proper reset making Ethernet to be functional. Signed-off-by: Fabio Estevam --- configs/msc_sm2s_imx8mp_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/msc_sm2s_imx8mp_defconfig b/configs/msc_sm2s_imx8mp_defconfig index 9c27a72f8a..a190c1ea22 100644 --- a/configs/msc_sm2s_imx8mp_defconfig +++ b/configs/msc_sm2s_imx8mp_defconfig @@ -72,6 +72,7 @@ CONFIG_CLK_COMPOSITE_CCF=y CONFIG_SPL_CLK_IMX8MP=y CONFIG_CLK_IMX8MP=y CONFIG_MXC_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_LED=y CONFIG_LED_GPIO=y -- 2.34.1
[PATCH 3/5] imx8mp-msc-sm2s: Add mmc aliases
From: Fabio Estevam
Add mmc alias so that the eMMC is mmc0 and the SD card
is mmc1 to have a well defined device numbering scheme.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
index 1a7b530d9f..ce61ca6671 100644
--- a/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
@@ -9,6 +9,11 @@
model = "MSC SM2S-IMX8MPLUS";
compatible = "avnet,sm2s-imx8mp", "fsl,imx8mp";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
wdt-reboot {
compatible = "wdt-reboot";
wdt = <>;
--
2.34.1
[PATCH 1/5] msc_sm2s_imx8mp: Convert to DM_SERIAL
From: Fabio Estevam
The conversion to DM_SERIAL is mandatory, so do the conversion.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi | 8
board/msc/sm2s_imx8mp/spl.c | 9 -
configs/msc_sm2s_imx8mp_defconfig| 1 +
include/configs/msc_sm2s_imx8mp.h| 2 --
4 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
index c398a743f7..1a7b530d9f 100644
--- a/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-msc-sm2s-u-boot.dtsi
@@ -63,3 +63,11 @@
{
bootph-pre-ram;
};
+
+ {
+ bootph-pre-ram;
+};
+
+_uart2 {
+ bootph-pre-ram;
+};
diff --git a/board/msc/sm2s_imx8mp/spl.c b/board/msc/sm2s_imx8mp/spl.c
index fed0fbcba1..ed7a1b7d3d 100644
--- a/board/msc/sm2s_imx8mp/spl.c
+++ b/board/msc/sm2s_imx8mp/spl.c
@@ -168,13 +168,6 @@ static const iomux_v3_cfg_t wdog_pads[] = {
MX8MP_PAD_GPIO1_IO02__WDOG1_WDOG_B | MUX_PAD_CTRL(WDOG_PAD_CTRL),
};
-#define UART_PAD_CTRL (PAD_CTL_DSE6 | PAD_CTL_FSEL1)
-
-static const iomux_v3_cfg_t ser0_pads[] = {
- MX8MP_PAD_UART2_RXD__UART2_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
- MX8MP_PAD_UART2_TXD__UART2_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
int board_early_init_f(void)
{
struct wdog_regs *wdog = (struct wdog_regs *)WDOG1_BASE_ADDR;
@@ -182,8 +175,6 @@ int board_early_init_f(void)
imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads));
set_wdog_reset(wdog);
- imx_iomux_v3_setup_multiple_pads(ser0_pads, ARRAY_SIZE(ser0_pads));
-
return 0;
}
diff --git a/configs/msc_sm2s_imx8mp_defconfig
b/configs/msc_sm2s_imx8mp_defconfig
index bf1052db6f..9c27a72f8a 100644
--- a/configs/msc_sm2s_imx8mp_defconfig
+++ b/configs/msc_sm2s_imx8mp_defconfig
@@ -97,6 +97,7 @@ CONFIG_SPL_PMIC_RN5T567=y
CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
CONFIG_SYSRESET=y
CONFIG_SPL_SYSRESET=y
diff --git a/include/configs/msc_sm2s_imx8mp.h
b/include/configs/msc_sm2s_imx8mp.h
index c1c1fd5a78..3c7d96cb3c 100644
--- a/include/configs/msc_sm2s_imx8mp.h
+++ b/include/configs/msc_sm2s_imx8mp.h
@@ -55,8 +55,6 @@
#define PHYS_SDRAM_2 0xc000
#define PHYS_SDRAM_2_SIZE 0x0
-#define CFG_MXC_UART_BASE UART2_BASE_ADDR
-
#define CFG_SYS_FSL_USDHC_NUM 2
#define CFG_SYS_FSL_ESDHC_ADDR 0
--
2.34.1
Re: [PATCH v2 1/7] common: avb_verify: don't call mmc_switch_part for SD
Hi Mattijs, On Tue, Feb 13, 2024 at 9:13 AM Mattijs Korpershoek wrote: > > Hi Igor, > > On lun., févr. 12, 2024 at 09:05, Igor Opaniuk wrote: > > > Hi Dan, > > > > On Mon, Feb 12, 2024 at 8:05 AM Dan Carpenter > > wrote: > >> > >> On Fri, Feb 09, 2024 at 08:20:39PM +0100, Igor Opaniuk wrote: > >> > From: Igor Opaniuk > >> > > >> > mmc_switch_part() is used for switching between hw partitions > >> > on eMMC (boot0, boot1, user, rpmb). > >> > There is no need to do that for SD card. > >> > > >> > >> Is this a clean up or a bugfix? What are the visible effects for the > >> user? > > avb cmd fails for SD cards, as mmc_switch_part() fails after trying to > > access > > EXT_CSD register, which obviously is not available. > > Does this means that we only need this patch to fix AVB commands when > booting from SD cards? > > If yes, I propose adding the following note to the commit message: > > "This fixes the avb command usage on on SD cards." > > If you agree, I can do this while applying. Yes, could you please add to the commit message so I don't send v3 for that (if there are no any additional objections/comments) Thanks > > If not, we can keep the message as is. > > >> > >> regards, > >> dan carpenter > >> > > > > > > -- > > Best regards - Atentamente - Meilleures salutations > > > > Igor Opaniuk > > > > mailto: igor.opan...@gmail.com > > skype: igor.opanyuk > > http://ua.linkedin.com/in/iopaniuk -- Best regards - Atentamente - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk http://ua.linkedin.com/in/iopaniuk
Re: [PATCH v2] imx: imx8mp: Add support for Polyhex Debix Model A SBC
Hi Gilles,
Gilles Talis writes:
> Hi Milan,
>
>
> Le mar. 30 janv. 2024 à 15:55, Milan Zamazal a écrit :
>>
>> Fabio Estevam writes:
>>
>> > Hi Milan,
>> >
>> > On Tue, Jan 30, 2024 at 9:22 AM Milan Zamazal wrote:
>> >
>> >> Well, after trying both the SD cards again with fresh reinstallations, it
>> >> works
>> >> with a 32 GB card and I get the error above with a 64 GB card. Is it
>> >> possible
>> >> that there is something wrong with SDXC cards?
>> >
>> > Does the change below help?
>> >
>> > --- a/arch/arm/dts/imx8mp-debix-model-a-u-boot.dtsi
>> > +++ b/arch/arm/dts/imx8mp-debix-model-a-u-boot.dtsi
>> > @@ -128,6 +128,9 @@
>> > bootph-pre-ram;
>> > sd-uhs-sdr104;
>> > sd-uhs-ddr50;
>> > + assigned-clocks = < IMX8MP_CLK_USDHC2>;
>> > + assigned-clock-rates = <4>;
>> > + assigned-clock-parents = < IMX8MP_SYS_PLL1_400M>;
>> > };
>> >
>> > {
>>
>> No, the same error. :-(
>>
>> Regards,
>> Milan
>>
> I tried with a 32GB Sandisk high endurance SD and a 64GB Sandisk
> Ultra SDXC UHS-I and both worked.
> Can you tell me which 64GB sd cards you tried booting with?
Sandisk SDXC Extreme 64 GB UHS-I U3
> And also, which steps you followed to get the errors (which image to download,
> etc...)?
wget
https://download.fedoraproject.org/pub/fedora/linux/releases/39/Server/aarch64/images/Fedora-Server-39-1.5.aarch64.raw.xz
unxz Fedora-Server-39-1.5.aarch64.raw.xz
sudo dd if=Fedora-Server-39-1.5.aarch64.raw of=/dev/mmcblk0 bs=1M
sudo -E gparted /dev/mmcblk0
# move / resize the first partition by 8 MB / to 592 MB
sudo dd if=flash.bin of=/dev/mmcblk0 bs=1k seek=32 conv=fsync
sync
When I do the same with some older Kingston 32 GB, it boots fine.
Regards,
Milan
Re: [PATCH v4] rng: Add Turris Mox rTWM RNG driver
On Tue, 13 Feb 2024 10:49:43 +0100
Heinrich Schuchardt wrote:
> On 2/13/24 10:16, Stefan Roese wrote:
> > Hi Max,
> >
> > mostly some nitpicking comments below.
> >
> > On 2/11/24 14:04, Max Resch wrote:
> >> A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
> >> from CZ.NIC in the secure processor.
> >>
> >> Signed-off-by: Max Resch
> >> ---
> >>
> >> Changes in v4:
> >> - wrongful/missing git rebase
> >>
> >> Changes in v3:
> >> - More meaningful variable names in accordance with review
> >>
> >> Changes in v2:
> >> - Removed ring buffer implementation
> >>
> >> drivers/rng/Kconfig | 8 +++
> >> drivers/rng/Makefile | 1 +
> >> drivers/rng/turris_rwtm_rng.c | 122 ++
> >> 3 files changed, 131 insertions(+)
> >> create mode 100644 drivers/rng/turris_rwtm_rng.c
> >>
> >> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> >> index a89c899568..cd72852a47 100644
> >> --- a/drivers/rng/Kconfig
> >> +++ b/drivers/rng/Kconfig
> >> @@ -105,4 +105,12 @@ config RNG_JH7110
> >> help
> >> Enable True Random Number Generator in StarFive JH7110 SoCs.
> >> +config RNG_TURRIS_RWTM
> >> + bool "Turris Mox TRNG in Secure Processor"
> >> + depends on DM_RNG && ARMADA_3700
> >> + help
> >> + Use TRNG in Turris Mox Secure Processor Firmware. Can be used
> >> + on other Armada-3700 devices (like EspressoBin) if Secure
> >> + Firmware from CZ.NIC is used.
> >> +
> >> endif
> >> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> >> index 7e64c4cdfc..ecae1a3da3 100644
> >> --- a/drivers/rng/Makefile
> >> +++ b/drivers/rng/Makefile
> >> @@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
> >> obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
> >> obj-$(CONFIG_TPM_RNG) += tpm_rng.o
> >> obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
> >> +obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
> >> diff --git a/drivers/rng/turris_rwtm_rng.c
> >> b/drivers/rng/turris_rwtm_rng.c
> >> new file mode 100644
> >> index 00..ec2cb0bca3
> >> --- /dev/null
> >> +++ b/drivers/rng/turris_rwtm_rng.c
> >> @@ -0,0 +1,122 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
> >> +/*
> >> + * Copyright (c) 2024, Max Resch
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +/* size of entropy buffer */
> >> +#define RNG_BUFFER_SIZE 128U
> >> +
> >> +struct turris_rwtm_rng_priv {
> >> + phys_addr_t buffer;
> >> +};
> >> +
> >> +static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t
> >> size)
> >> +{
> >> + u32 args[3] = { 1, (u32)entropy, size };
>
> On a device with memory above 4 GiB this (u32) conversion may point to a
> different location than rwtm_rng_priv.
>
> Is the Armada 3700 family restricted to below 4 GiB?
Indeed it is. Only virtual memory can be mapped to higher locations,
all physical resources (DDR, registers, PCIe, DMA, rWTM) can only be
confiured with 32 bits.
> Should we add a check in the probe function?
No need.
Re: [PATCH v4] rng: Add Turris Mox rTWM RNG driver
On 2/13/24 10:16, Stefan Roese wrote:
Hi Max,
mostly some nitpicking comments below.
On 2/11/24 14:04, Max Resch wrote:
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
from CZ.NIC in the secure processor.
Signed-off-by: Max Resch
---
Changes in v4:
- wrongful/missing git rebase
Changes in v3:
- More meaningful variable names in accordance with review
Changes in v2:
- Removed ring buffer implementation
drivers/rng/Kconfig | 8 +++
drivers/rng/Makefile | 1 +
drivers/rng/turris_rwtm_rng.c | 122 ++
3 files changed, 131 insertions(+)
create mode 100644 drivers/rng/turris_rwtm_rng.c
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index a89c899568..cd72852a47 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -105,4 +105,12 @@ config RNG_JH7110
help
Enable True Random Number Generator in StarFive JH7110 SoCs.
+config RNG_TURRIS_RWTM
+ bool "Turris Mox TRNG in Secure Processor"
+ depends on DM_RNG && ARMADA_3700
+ help
+ Use TRNG in Turris Mox Secure Processor Firmware. Can be used
+ on other Armada-3700 devices (like EspressoBin) if Secure
+ Firmware from CZ.NIC is used.
+
endif
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 7e64c4cdfc..ecae1a3da3 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
obj-$(CONFIG_TPM_RNG) += tpm_rng.o
obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
+obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
diff --git a/drivers/rng/turris_rwtm_rng.c
b/drivers/rng/turris_rwtm_rng.c
new file mode 100644
index 00..ec2cb0bca3
--- /dev/null
+++ b/drivers/rng/turris_rwtm_rng.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (c) 2024, Max Resch
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* size of entropy buffer */
+#define RNG_BUFFER_SIZE 128U
+
+struct turris_rwtm_rng_priv {
+ phys_addr_t buffer;
+};
+
+static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t
size)
+{
+ u32 args[3] = { 1, (u32)entropy, size };
On a device with memory above 4 GiB this (u32) conversion may point to a
different location than rwtm_rng_priv.
Is the Armada 3700 family restricted to below 4 GiB?
Should we add a check in the probe function?
Best regards
Heinrich
+ int ret;
+
+ /* flush data cache */
+ flush_dcache_range(entropy, entropy + size);
+
+ /*
+ * get entropy
+ * args[0] = 1 copies BYTES array in args[1] of length args[2]
+ */
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, 3, NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ /* invalidate data cache */
+ invalidate_dcache_range(entropy, entropy + size);
+
+ return 0;
+}
+
+static int turris_rwtm_rng_random_read(struct udevice *dev, void
*data, size_t count)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys;
+ size_t size;
+ int ret;
+
+ phys = priv->buffer;
+
+ while (count) {
+ size = min_t(size_t, RNG_BUFFER_SIZE, count);
+
+ ret = turris_rwtm_rng_fill_entropy(phys, size);
Return code check missing here.
+
+ memcpy(data, (void *)phys, size);
+ count -= size;
+ data = (u8 *)data + size;
+ }
+
+ return 0;
+}
+
+static int turris_rwtm_rng_probe(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ u32 args[] = { 0 };
+ int ret;
+
+ /*
+ * check if the random command is supported
+ * args[0] = 0 would copy 16 DWORDS entropy to out but we ignore
them
+ */
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, ARRAY_SIZE(args),
NULL, 0);
+
Please drop this empty line before the ret check.
+ if (ret < 0)
+ return ret;
+
+ /* entropy buffer */
+ priv->buffer = 0;
+
+ /* buffer address need to be aligned */
+ dma_alloc_coherent(RNG_BUFFER_SIZE, (unsigned long *)>buffer);
+ if (!priv->buffer)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int turris_rwtm_rng_remove(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys = priv->buffer;
+
+ dma_free_coherent((void *)phys);
+
+ return 0;
+}
+
+static const struct dm_rng_ops turris_rwtm_rng_ops = {
+ .read = turris_rwtm_rng_random_read,
+};
+
+/*
+ * only Turris MOX firmware has the RNG but allow all probable
devices to be
+ * probed the default firmware will just reject the probe
+ */
+static const struct udevice_id turris_rwtm_rng_match[] = {
+ { .compatible = "cznic,turris-mox-rwtm" },
+ { .compatible = "marvell,armada-3700-rwtm-firmware" },
+ {},
+};
+
+U_BOOT_DRIVER(turris_rwtm_rng) = {
+ .name = "turris-rwtm-rng",
+ .id = UCLASS_RNG,
+ .of_match = turris_rwtm_rng_match,
+ .ops = _rwtm_rng_ops,
+ .probe =
Re: [PATCH v4] rng: Add Turris Mox rTWM RNG driver
Hi Max,
mostly some nitpicking comments below.
On 2/11/24 14:04, Max Resch wrote:
A RNG driver for Armada 3720 boards running the Turris Mox rWTM firmware
from CZ.NIC in the secure processor.
Signed-off-by: Max Resch
---
Changes in v4:
- wrongful/missing git rebase
Changes in v3:
- More meaningful variable names in accordance with review
Changes in v2:
- Removed ring buffer implementation
drivers/rng/Kconfig | 8 +++
drivers/rng/Makefile | 1 +
drivers/rng/turris_rwtm_rng.c | 122 ++
3 files changed, 131 insertions(+)
create mode 100644 drivers/rng/turris_rwtm_rng.c
diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
index a89c899568..cd72852a47 100644
--- a/drivers/rng/Kconfig
+++ b/drivers/rng/Kconfig
@@ -105,4 +105,12 @@ config RNG_JH7110
help
Enable True Random Number Generator in StarFive JH7110 SoCs.
+config RNG_TURRIS_RWTM
+ bool "Turris Mox TRNG in Secure Processor"
+ depends on DM_RNG && ARMADA_3700
+ help
+ Use TRNG in Turris Mox Secure Processor Firmware. Can be used
+ on other Armada-3700 devices (like EspressoBin) if Secure
+ Firmware from CZ.NIC is used.
+
endif
diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
index 7e64c4cdfc..ecae1a3da3 100644
--- a/drivers/rng/Makefile
+++ b/drivers/rng/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_RNG_SMCCC_TRNG) += smccc_trng.o
obj-$(CONFIG_RNG_ARM_RNDR) += arm_rndr.o
obj-$(CONFIG_TPM_RNG) += tpm_rng.o
obj-$(CONFIG_RNG_JH7110) += jh7110_rng.o
+obj-$(CONFIG_RNG_TURRIS_RWTM) += turris_rwtm_rng.o
diff --git a/drivers/rng/turris_rwtm_rng.c b/drivers/rng/turris_rwtm_rng.c
new file mode 100644
index 00..ec2cb0bca3
--- /dev/null
+++ b/drivers/rng/turris_rwtm_rng.c
@@ -0,0 +1,122 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR BSD-3-Clause
+/*
+ * Copyright (c) 2024, Max Resch
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* size of entropy buffer */
+#define RNG_BUFFER_SIZE128U
+
+struct turris_rwtm_rng_priv {
+ phys_addr_t buffer;
+};
+
+static int turris_rwtm_rng_fill_entropy(phys_addr_t entropy, size_t size)
+{
+ u32 args[3] = { 1, (u32)entropy, size };
+ int ret;
+
+ /* flush data cache */
+ flush_dcache_range(entropy, entropy + size);
+
+ /*
+* get entropy
+* args[0] = 1 copies BYTES array in args[1] of length args[2]
+*/
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, 3, NULL, 0);
+ if (ret < 0)
+ return ret;
+
+ /* invalidate data cache */
+ invalidate_dcache_range(entropy, entropy + size);
+
+ return 0;
+}
+
+static int turris_rwtm_rng_random_read(struct udevice *dev, void *data, size_t
count)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys;
+ size_t size;
+ int ret;
+
+ phys = priv->buffer;
+
+ while (count) {
+ size = min_t(size_t, RNG_BUFFER_SIZE, count);
+
+ ret = turris_rwtm_rng_fill_entropy(phys, size);
Return code check missing here.
+
+ memcpy(data, (void *)phys, size);
+ count -= size;
+ data = (u8 *)data + size;
+ }
+
+ return 0;
+}
+
+static int turris_rwtm_rng_probe(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ u32 args[] = { 0 };
+ int ret;
+
+ /*
+* check if the random command is supported
+* args[0] = 0 would copy 16 DWORDS entropy to out but we ignore them
+*/
+ ret = mbox_do_cmd(MBOX_CMD_GET_RANDOM, args, ARRAY_SIZE(args), NULL, 0);
+
Please drop this empty line before the ret check.
+ if (ret < 0)
+ return ret;
+
+ /* entropy buffer */
+ priv->buffer = 0;
+
+ /* buffer address need to be aligned */
+ dma_alloc_coherent(RNG_BUFFER_SIZE, (unsigned long *)>buffer);
+ if (!priv->buffer)
+ return -ENOMEM;
+
+ return 0;
+}
+
+static int turris_rwtm_rng_remove(struct udevice *dev)
+{
+ struct turris_rwtm_rng_priv *priv = dev_get_priv(dev);
+ phys_addr_t phys = priv->buffer;
+
+ dma_free_coherent((void *)phys);
+
+ return 0;
+}
+
+static const struct dm_rng_ops turris_rwtm_rng_ops = {
+ .read = turris_rwtm_rng_random_read,
+};
+
+/*
+ * only Turris MOX firmware has the RNG but allow all probable devices to be
+ * probed the default firmware will just reject the probe
+ */
+static const struct udevice_id turris_rwtm_rng_match[] = {
+ { .compatible = "cznic,turris-mox-rwtm" },
+ { .compatible = "marvell,armada-3700-rwtm-firmware" },
+ {},
+};
+
+U_BOOT_DRIVER(turris_rwtm_rng) = {
+ .name = "turris-rwtm-rng",
+ .id = UCLASS_RNG,
+ .of_match = turris_rwtm_rng_match,
+ .ops= _rwtm_rng_ops,
+ .probe = turris_rwtm_rng_probe,
+ .remove =
[PATCH v3] cmd: add FDT setup for bootelf by flag
Added the ability to use FDT for ELF applications, required to run some OS. To
make FDT setup, you need to set the -d fdt_addr_r cmd option for bootelf command
Signed-off-by: Maxim Moskalets
Cc: Tom Rini
---
cmd/elf.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/cmd/elf.c b/cmd/elf.c
index b7b9f506a5..c525618a39 100644
--- a/cmd/elf.c
+++ b/cmd/elf.c
@@ -38,6 +38,8 @@ static unsigned long do_bootelf_exec(ulong (*entry)(int, char
* const[]),
/* Interpreter command to boot an arbitrary ELF image from memory */
int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
{
+ struct bootm_headers img = {0};
+ unsigned long fdt_addr = 0; /* Address of the FDT */
unsigned long addr; /* Address of the ELF image */
unsigned long rc; /* Return value from user code */
char *sload = NULL;
@@ -46,13 +48,23 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
/* Consume 'bootelf' */
argc--; argv++;
- /* Check for flag. */
+ /* Check for [-p|-s] flag. */
if (argc >= 1 && (argv[0][0] == '-' && \
(argv[0][1] == 'p' || argv[0][1] == 's'))) {
sload = argv[0];
/* Consume flag. */
argc--; argv++;
}
+
+ /* Check for [-d fdt_addr_r] option. */
+ if ((argc >= 2) && (argv[0][0] == '-') && (argv[0][1] == 'd')) {
+ if (strict_strtoul(argv[1], 16, _addr) != 0)
+ return CMD_RET_USAGE;
+ /* Consume option. */
+ argc -= 2;
+ argv += 2;
+ }
+
/* Check for address. */
if (argc >= 1 && strict_strtoul(argv[0], 16, ) != -EINVAL) {
/* Consume address */
@@ -68,6 +80,14 @@ int do_bootelf(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
else
addr = load_elf_image_shdr(addr);
+ if (fdt_addr) {
+ printf("## Setting up FDT at 0x%08lx ...\n", fdt_addr);
+ flush();
+
+ if (image_setup_libfdt(, (void *)fdt_addr, NULL))
+ return 1;
+ }
+
if (!env_get_autostart())
return rcode;
@@ -298,7 +318,7 @@ int do_bootvx(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
U_BOOT_CMD(
bootelf, CONFIG_SYS_MAXARGS, 0, do_bootelf,
"Boot from an ELF image in memory",
- "[-p|-s] [address]\n"
+ "[-p|-s] [-d fdt_addr_r] [address]\n"
"\t- load ELF image at [address] via program headers (-p)\n"
"\t or via section headers (-s)"
);
--
2.39.2
Re: [RESEND PATCH v1] MAINTAINERS: add custodian tree info for AVB/AB
Hi Igor, Thank you for the patch. On mar., févr. 13, 2024 at 08:36, Igor Opaniuk wrote: > From: Igor Opaniuk > > Add information about a custodian tree [1] for AVB/AB, which is > maintained by Mattijs Korpershoek. > > [1] https://source.denx.de/u-boot/custodians/u-boot-dfu > Signed-off-by: Igor Opaniuk Reviewed-by: Mattijs Korpershoek > --- > > MAINTAINERS | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 46ba17647f3..32f3ee30710 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -62,6 +62,7 @@ M: Igor Opaniuk > M: Mattijs Korpershoek > R: Sam Protsenko > S: Maintained > +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git > F: boot/android_ab.c > F: cmd/ab_select.c > F: doc/android/ab.rst > @@ -72,6 +73,7 @@ ANDROID AVB > M: Igor Opaniuk > M: Mattijs Korpershoek > S: Maintained > +T: git https://source.denx.de/u-boot/custodians/u-boot-dfu.git > F: cmd/avb.c > F: common/avb_verify.c > F: doc/android/avb2.rst > -- > 2.34.1
Re: [PATCH v2 7/7] doc: android: avb: sync usage details
Hi Igor, Thank you for the patch. On ven., févr. 09, 2024 at 20:20, Igor Opaniuk wrote: > From: Igor Opaniuk > > Sync usage info with the one cmd/avb.c. > > Signed-off-by: Igor Opaniuk Reviewed-by: Mattijs Korpershoek > --- > > Changes in v2: > - Address Mattijs comment about usage info, sync with cmd/avb.c > > doc/android/avb2.rst | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/doc/android/avb2.rst b/doc/android/avb2.rst > index a072119574f..4aca7a5c660 100644 > --- a/doc/android/avb2.rst > +++ b/doc/android/avb2.rst > @@ -38,16 +38,22 @@ AVB 2.0 U-Boot shell commands > Provides CLI interface to invoke AVB 2.0 verification + misc. commands for > different testing purposes:: > > -avb init - initialize avb 2.0 for > -avb verify - run verification process using hash data from vbmeta > structure > +avb init - initialize avb 2 for > avb read_rb - read rollback index at location > avb write_rb - write rollback index to > avb is_unlocked - returns unlock status of the device > -avb get_uuid - read and print uuid of partition > +avb get_uuid - read and print uuid of partition > avb read_part - read bytes from > -partition to buffer > +partition to buffer > +avb read_part_hex- read bytes from > +partition and print to stdout > avb write_part - write bytes to > - by using data from > + by using data from > +avb read_pvalue - read a persistent value > +avb write_pvalue - write a persistent value > +avb verify [slot_suffix] - run verification process using hash data > +from vbmeta structure > +[slot_suffix] - _a, _b, etc (if vbmeta partition is slotted) > > Partitions tampering (example) > -- > -- > 2.34.1
Re: [PATCH v2 4/7] cmd: avb: rework prints
Hi Igor,
Thank you for the patch.
On ven., févr. 09, 2024 at 20:20, Igor Opaniuk
wrote:
> From: Igor Opaniuk
>
> Simplify and add more context for prints where it's needed.
>
> Signed-off-by: Igor Opaniuk
Reviewed-by: Mattijs Korpershoek
> ---
>
> Changes in v2:
> - Drop AVB_OPS_CHECK macro and leave previous check
>
> cmd/avb.c | 123 +-
> 1 file changed, 75 insertions(+), 48 deletions(-)
>
> diff --git a/cmd/avb.c b/cmd/avb.c
> index ce8b63873f2..62a3ee18e7f 100644
> --- a/cmd/avb.c
> +++ b/cmd/avb.c
> @@ -11,6 +11,7 @@
> #include
>
> #define AVB_BOOTARGS "avb_bootargs"
> +
> static struct AvbOps *avb_ops;
>
> int do_avb_init(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> @@ -28,8 +29,10 @@ int do_avb_init(struct cmd_tbl *cmdtp, int flag, int argc,
> char *const argv[])
> avb_ops = avb_ops_alloc(mmc_dev);
> if (avb_ops)
> return CMD_RET_SUCCESS;
> + else
> + printf("Can't allocate AvbOps");
>
> - printf("Failed to initialize avb2\n");
> + printf("Failed to initialize AVB\n");
>
> return CMD_RET_FAILURE;
> }
> @@ -41,10 +44,11 @@ int do_avb_read_part(struct cmd_tbl *cmdtp, int flag, int
> argc,
> s64 offset;
> size_t bytes, bytes_read = 0;
> void *buffer;
> + int ret;
>
> if (!avb_ops) {
> - printf("AVB 2.0 is not initialized, please run 'avb init'\n");
> - return CMD_RET_USAGE;
> + printf("AVB is not initialized, please run 'avb init '\n");
> + return CMD_RET_FAILURE;
> }
>
> if (argc != 5)
> @@ -55,14 +59,15 @@ int do_avb_read_part(struct cmd_tbl *cmdtp, int flag, int
> argc,
> bytes = hextoul(argv[3], NULL);
> buffer = (void *)hextoul(argv[4], NULL);
>
> - if (avb_ops->read_from_partition(avb_ops, part, offset, bytes,
> - buffer, _read) ==
> - AVB_IO_RESULT_OK) {
> + ret = avb_ops->read_from_partition(avb_ops, part, offset,
> +bytes, buffer, _read);
> + if (ret == AVB_IO_RESULT_OK) {
> printf("Read %zu bytes\n", bytes_read);
> return CMD_RET_SUCCESS;
> }
>
> - printf("Failed to read from partition\n");
> + printf("Failed to read from partition '%s', err = %d\n",
> +part, ret);
>
> return CMD_RET_FAILURE;
> }
> @@ -74,10 +79,11 @@ int do_avb_read_part_hex(struct cmd_tbl *cmdtp, int flag,
> int argc,
> s64 offset;
> size_t bytes, bytes_read = 0;
> char *buffer;
> + int ret;
>
> if (!avb_ops) {
> - printf("AVB 2.0 is not initialized, please run 'avb init'\n");
> - return CMD_RET_USAGE;
> + printf("AVB is not initialized, please run 'avb init '\n");
> + return CMD_RET_FAILURE;
> }
>
> if (argc != 4)
> @@ -94,8 +100,9 @@ int do_avb_read_part_hex(struct cmd_tbl *cmdtp, int flag,
> int argc,
> }
> memset(buffer, 0, bytes);
>
> - if (avb_ops->read_from_partition(avb_ops, part, offset, bytes, buffer,
> - _read) == AVB_IO_RESULT_OK) {
> + ret = avb_ops->read_from_partition(avb_ops, part, offset,
> +bytes, buffer, _read);
> + if (ret == AVB_IO_RESULT_OK) {
> printf("Requested %zu, read %zu bytes\n", bytes, bytes_read);
> printf("Data: ");
> for (int i = 0; i < bytes_read; i++)
> @@ -107,7 +114,8 @@ int do_avb_read_part_hex(struct cmd_tbl *cmdtp, int flag,
> int argc,
> return CMD_RET_SUCCESS;
> }
>
> - printf("Failed to read from partition\n");
> + printf("Failed to read from partition '%s', err = %d\n",
> +part, ret);
>
> free(buffer);
> return CMD_RET_FAILURE;
> @@ -120,9 +128,10 @@ int do_avb_write_part(struct cmd_tbl *cmdtp, int flag,
> int argc,
> s64 offset;
> size_t bytes;
> void *buffer;
> + int ret;
>
> if (!avb_ops) {
> - printf("AVB 2.0 is not initialized, run 'avb init' first\n");
> + printf("AVB is not initialized, please run 'avb init '\n");
> return CMD_RET_FAILURE;
> }
>
> @@ -134,13 +143,15 @@ int do_avb_write_part(struct cmd_tbl *cmdtp, int flag,
> int argc,
> bytes = hextoul(argv[3], NULL);
> buffer = (void *)hextoul(argv[4], NULL);
>
> - if (avb_ops->write_to_partition(avb_ops, part, offset, bytes, buffer) ==
> - AVB_IO_RESULT_OK) {
> + ret = avb_ops->write_to_partition(avb_ops, part, offset,
> + bytes, buffer);
> + if (ret == AVB_IO_RESULT_OK) {
> printf("Wrote %zu bytes\n", bytes);
> return CMD_RET_SUCCESS;
> }
>
> - printf("Failed to write in partition\n");
> +
Re: [PATCH v2 1/7] common: avb_verify: don't call mmc_switch_part for SD
Hi Igor, On lun., févr. 12, 2024 at 09:05, Igor Opaniuk wrote: > Hi Dan, > > On Mon, Feb 12, 2024 at 8:05 AM Dan Carpenter > wrote: >> >> On Fri, Feb 09, 2024 at 08:20:39PM +0100, Igor Opaniuk wrote: >> > From: Igor Opaniuk >> > >> > mmc_switch_part() is used for switching between hw partitions >> > on eMMC (boot0, boot1, user, rpmb). >> > There is no need to do that for SD card. >> > >> >> Is this a clean up or a bugfix? What are the visible effects for the >> user? > avb cmd fails for SD cards, as mmc_switch_part() fails after trying to access > EXT_CSD register, which obviously is not available. Does this means that we only need this patch to fix AVB commands when booting from SD cards? If yes, I propose adding the following note to the commit message: "This fixes the avb command usage on on SD cards." If you agree, I can do this while applying. If not, we can keep the message as is. >> >> regards, >> dan carpenter >> > > > -- > Best regards - Atentamente - Meilleures salutations > > Igor Opaniuk > > mailto: igor.opan...@gmail.com > skype: igor.opanyuk > http://ua.linkedin.com/in/iopaniuk
