Re: [PATCH v2 1/6] efi_loader: add RAM disk device path
On Tue, 18 Jul 2023 at 14:57, Heinrich Schuchardt wrote:
>
>
>
> Am 18. Juli 2023 03:31:30 MESZ schrieb Masahisa Kojima
> :
> >Hi Heinrich,
> >
> >On Fri, 14 Jul 2023 at 22:44, Heinrich Schuchardt wrote:
> >>
> >> On 14.07.23 07:44, Masahisa Kojima wrote:
> >> > This is a preparation to add the EFI_RAM_DISK_PROTOCOL.
> >> > This commit adds the RAM disk device path structure
> >> > and text conversion to Device Path to Text Protocol.
> >> >
> >> > Signed-off-by: Masahisa Kojima
> >> > ---
> >> > No update since v1
> >> >
> >> > include/efi_api.h| 19 +++
> >> > lib/efi_loader/efi_device_path_to_text.c | 14 ++
> >> > 2 files changed, 33 insertions(+)
> >> >
> >> > diff --git a/include/efi_api.h b/include/efi_api.h
> >> > index 55a4c989fc..4ee4a1b5e9 100644
> >> > --- a/include/efi_api.h
> >> > +++ b/include/efi_api.h
> >> > @@ -682,6 +682,7 @@ struct efi_device_path_uri {
> >> > # define DEVICE_PATH_SUB_TYPE_CDROM_PATH 0x02
> >> > # define DEVICE_PATH_SUB_TYPE_VENDOR_PATH 0x03
> >> > # define DEVICE_PATH_SUB_TYPE_FILE_PATH0x04
> >> > +# define DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH 0x09
> >> >
> >> > struct efi_device_path_hard_drive_path {
> >> > struct efi_device_path dp;
> >> > @@ -705,6 +706,24 @@ struct efi_device_path_file_path {
> >> > u16 str[];
> >> > } __packed;
> >> >
> >> > +/* This GUID defines a RAM Disk supporting a raw disk format in
> >> > volatile memory */
> >> > +#define EFI_VIRTUAL_DISK_GUID \
> >> > + EFI_GUID(0x77ab535a, 0x45fc, 0x624b, \
> >> > + 0x55, 0x60, 0xf7, 0xb2, 0x81, 0xd1, 0xf9, 0x6e)
> >> > +
> >> > +/* This GUID defines a RAM Disk supporting an ISO image in volatile
> >> > memory */
> >> > +#define EFI_VIRTUAL_CD_GUID \
> >> > + EFI_GUID(0x3d5abd30, 0x4175, 0x87ce, \
> >> > + 0x6d, 0x64, 0xd2, 0xad, 0xe5, 0x23, 0xc4, 0xbb)
> >> > +
> >> > +struct efi_device_path_ram_disk_path {
> >> > + struct efi_device_path dp;
> >> > + u64 starting_address;
> >> > + u64 ending_address;
> >> > + efi_guid_t disk_type_guid;
> >> > + u16 disk_instance;
> >> > +} __packed;
> >> > +
> >> > #define EFI_BLOCK_IO_PROTOCOL_GUID \
> >> > EFI_GUID(0x964e5b21, 0x6459, 0x11d2, \
> >> >0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
> >> > diff --git a/lib/efi_loader/efi_device_path_to_text.c
> >> > b/lib/efi_loader/efi_device_path_to_text.c
> >> > index 8c76d8be60..4395e79f33 100644
> >> > --- a/lib/efi_loader/efi_device_path_to_text.c
> >> > +++ b/lib/efi_loader/efi_device_path_to_text.c
> >> > @@ -324,6 +324,20 @@ static char *dp_media(char *s, struct
> >> > efi_device_path *dp)
> >> > free(buffer);
> >> > break;
> >> > }
> >> > + case DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH: {
> >> > + struct efi_device_path_ram_disk_path *rddp =
> >> > + (struct efi_device_path_ram_disk_path *)dp;
> >> > + u64 start;
> >> > + u64 end;
> >> > +
> >> > + /* Copy from packed structure to aligned memory */
> >> > + memcpy(&start, &rddp->starting_address, sizeof(start));
> >> > + memcpy(&end, &rddp->ending_address, sizeof(end));
> >> > +
> >> > + s += sprintf(s, "RamDisk(0x%llx,%llx,%pUl,0x%x)", start,
> >> > end,
> >> > + &rddp->disk_type_guid, rddp->disk_instance);
> >>
> >> If there is no alignment guarantee for starting_address, then the same
> >> is true for disk_instance which may spread over two u64 blocks.
> >
> >disk_instance is a u16 field, so it is aligned.
>
> A preceding node, e.g. VenHw(), may have an uneven length?
>
> >
> >>
> >> In case of DEVICE_PATH_SUB_TYPE_MEMORY we don't use memcpy() to align u64.
> >>
> >> I don't think we call device_path_to_text before allow_unaligned().
> >>
> >> There is a family of functions like get_unaligned_le64() if we should
> >> ever need to a align a value. Or we could copy the whole device path node.
> >
> >OK, I will use get_unaligned_le64().
>
> Why do you think this is necessary?
Sorry, I misunderstood your comment.
allow_unaligned() is called in efi_init_early(), device_path_to_text
will not be called
before allow_unaligned(). So we don't need to care about alignment in
device_path_to_text
like DEVICE_PATH_SUB_TYPE_MEMORY is doing.
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> >
> >Thanks,
> >Masahisa Kojima
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >> > + break;
> >> > + }
> >> > default:
> >> > s = dp_unknown(s, dp);
> >> > break;
> >>
Re: [PATCH v2 0/2] power: pmic: add TPS65913 support
Problems which were faced with this patchset exceed just TPS65913 support.
TPS65913 support commits will be moved into different patchset
dedicated exclusively to PMICs bringup. Power uclasses commits will be
sent as separate patchset with proper title.
Best regards,
Svyatoslav R.
пн, 17 лип. 2023 р. о 21:52 Jonas Karlman пише:
>
> On 2023-07-16 20:57, Svyatoslav Ryhel wrote:
> > 16 липня 2023 р. 16:07:55 GMT+03:00, Simon Glass
> > написав(-ла):
> >> Hi Svyatoslav,
> >>
> >> On Sun, 16 Jul 2023 at 07:04, Svyatoslav Ryhel wrote:
> >>>
> >>>
> >>>
> >>> 16 липня 2023 р. 11:07:15 GMT+03:00, Jonas Karlman
> >>> написав(-ла):
> On 2023-07-16 05:57, Svyatoslav Ryhel wrote:
> >
> >
> > 16 липня 2023 р. 02:37:39 GMT+03:00, Jonas Karlman
> > написав(-ла):
> >> On 2023-07-15 20:34, Svyatoslav Ryhel wrote:
> >>> Existing PALMAS PMIC driver is fully compatible with TI TPS65913
> >>> PMIC found in many Tegra 4 devices, like Tegra Note 7 and ASUS
> >>> TF701T. Add TPS65913 dts compatible with TPS659038 data.
> >>>
> >>> Issue with regulators is more general then I though initially.
> >>> It touches all pmic regulators.
> >>>
> >>> Currently device tree entries of regulators are completely
> >>> ignored and regulators are probed only if they are called
> >>> by the device which uses it. This results into two issues:
> >>> regulators which must run under boot-on or always-on mode
> >>> are ignored and not enabled; dts props like voltage are
> >>> not applied to the regulator so the regulator may be enabled
> >>> with random actual voltage, which may have unexpected
> >>> consequences.
> >>
> >> This sounds like something a call to regulators_enable_boot_on like is
> >> done on other platforms/boards could solve?
> >
> > Yes, regulators_enable_boot_on can solve this if called from the board,
> > but why should every device call this from the board if this should be
> > done automatically? What should do devices without board? Isn't u-boot
> > moving towards all in device tree setup?
>
> Main diff is that regulators_enable_boot_on covers all regulators,
> including fixed/gpio/pwm regulators, not just regulators that are
> children of a pmic. Meaning platforms/boards would still need to somehow
> autoset non-pmic regulators.
> >>>
> >>> This is a good point. Non pmic regulators are not probed/set.
> >>>
> Maybe regulators_enable_boot_on could be called from the default
> power_init_board or similar, when a Kconfig is enabled, to cover more
> platforms/boards.
> >>>
> >>> Since u-boot is moving towards device trees this should be undesireable
> >>> approach. What is possible is to set all non pmic regulators to probe on
> >>> post bind and on post probe call regulator_autoset.
> >>
> >> Yes we should handle this automatically without board-specific C code,
> >> where possible.
> >
> > Commit, Jonas Karlman refers to 4fcba5d556b4 ("regulator: implement
> > basic reference counter") introduces too much conflicting.
> >
> > 1. It should not have been merged in the current state and instead expanded
> > for all uclass. Counting regulator users is not fixed/gpio regulator
> > specific and can be beneficial for all devices.
>
> I think it was limited to fixed/gpio regulators just to not affect too
> many arch/boards. And can always be extended to core regulator uclass in
> the future.
>
> There is also drivers that do not currently keep enable/disable balanced,
> will shortly send a series with fixes for a few I have discovered.
>
> >
> > 2. Usage of board and device tree call to set up regulators will not work
> > well with counting enables/disables. The correct solution should be to
> > remove board calls for regulator setup but it will involve rework of many
> > boards.
>
> This was main reason why I mentioned this commit, it currently works, but
> if you introduce new code that call regulator_autoset from post probe,
> existing code must be adjusted or removed.
>
> E.g. regulators_enable_boot_on called in a rockchip arch shared
> board_init could be removed. Or logic in regulator_autoset can be
> changed to only run code once for each regulator. Or add a Kconfig to
> enable post probe autoset and disable autoset in regulators_enable_boot_on.
>
> Regards,
> Jonas
>
> >
> >> Regards,
> >> Simon
>
Re: [PATCH v2 1/6] efi_loader: add RAM disk device path
Am 18. Juli 2023 03:31:30 MESZ schrieb Masahisa Kojima
:
>Hi Heinrich,
>
>On Fri, 14 Jul 2023 at 22:44, Heinrich Schuchardt wrote:
>>
>> On 14.07.23 07:44, Masahisa Kojima wrote:
>> > This is a preparation to add the EFI_RAM_DISK_PROTOCOL.
>> > This commit adds the RAM disk device path structure
>> > and text conversion to Device Path to Text Protocol.
>> >
>> > Signed-off-by: Masahisa Kojima
>> > ---
>> > No update since v1
>> >
>> > include/efi_api.h| 19 +++
>> > lib/efi_loader/efi_device_path_to_text.c | 14 ++
>> > 2 files changed, 33 insertions(+)
>> >
>> > diff --git a/include/efi_api.h b/include/efi_api.h
>> > index 55a4c989fc..4ee4a1b5e9 100644
>> > --- a/include/efi_api.h
>> > +++ b/include/efi_api.h
>> > @@ -682,6 +682,7 @@ struct efi_device_path_uri {
>> > # define DEVICE_PATH_SUB_TYPE_CDROM_PATH 0x02
>> > # define DEVICE_PATH_SUB_TYPE_VENDOR_PATH 0x03
>> > # define DEVICE_PATH_SUB_TYPE_FILE_PATH0x04
>> > +# define DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH 0x09
>> >
>> > struct efi_device_path_hard_drive_path {
>> > struct efi_device_path dp;
>> > @@ -705,6 +706,24 @@ struct efi_device_path_file_path {
>> > u16 str[];
>> > } __packed;
>> >
>> > +/* This GUID defines a RAM Disk supporting a raw disk format in volatile
>> > memory */
>> > +#define EFI_VIRTUAL_DISK_GUID \
>> > + EFI_GUID(0x77ab535a, 0x45fc, 0x624b, \
>> > + 0x55, 0x60, 0xf7, 0xb2, 0x81, 0xd1, 0xf9, 0x6e)
>> > +
>> > +/* This GUID defines a RAM Disk supporting an ISO image in volatile
>> > memory */
>> > +#define EFI_VIRTUAL_CD_GUID \
>> > + EFI_GUID(0x3d5abd30, 0x4175, 0x87ce, \
>> > + 0x6d, 0x64, 0xd2, 0xad, 0xe5, 0x23, 0xc4, 0xbb)
>> > +
>> > +struct efi_device_path_ram_disk_path {
>> > + struct efi_device_path dp;
>> > + u64 starting_address;
>> > + u64 ending_address;
>> > + efi_guid_t disk_type_guid;
>> > + u16 disk_instance;
>> > +} __packed;
>> > +
>> > #define EFI_BLOCK_IO_PROTOCOL_GUID \
>> > EFI_GUID(0x964e5b21, 0x6459, 0x11d2, \
>> >0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
>> > diff --git a/lib/efi_loader/efi_device_path_to_text.c
>> > b/lib/efi_loader/efi_device_path_to_text.c
>> > index 8c76d8be60..4395e79f33 100644
>> > --- a/lib/efi_loader/efi_device_path_to_text.c
>> > +++ b/lib/efi_loader/efi_device_path_to_text.c
>> > @@ -324,6 +324,20 @@ static char *dp_media(char *s, struct efi_device_path
>> > *dp)
>> > free(buffer);
>> > break;
>> > }
>> > + case DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH: {
>> > + struct efi_device_path_ram_disk_path *rddp =
>> > + (struct efi_device_path_ram_disk_path *)dp;
>> > + u64 start;
>> > + u64 end;
>> > +
>> > + /* Copy from packed structure to aligned memory */
>> > + memcpy(&start, &rddp->starting_address, sizeof(start));
>> > + memcpy(&end, &rddp->ending_address, sizeof(end));
>> > +
>> > + s += sprintf(s, "RamDisk(0x%llx,%llx,%pUl,0x%x)", start, end,
>> > + &rddp->disk_type_guid, rddp->disk_instance);
>>
>> If there is no alignment guarantee for starting_address, then the same
>> is true for disk_instance which may spread over two u64 blocks.
>
>disk_instance is a u16 field, so it is aligned.
A preceding node, e.g. VenHw(), may have an uneven length?
>
>>
>> In case of DEVICE_PATH_SUB_TYPE_MEMORY we don't use memcpy() to align u64.
>>
>> I don't think we call device_path_to_text before allow_unaligned().
>>
>> There is a family of functions like get_unaligned_le64() if we should
>> ever need to a align a value. Or we could copy the whole device path node.
>
>OK, I will use get_unaligned_le64().
Why do you think this is necessary?
Best regards
Heinrich
>
>Thanks,
>Masahisa Kojima
>
>>
>> Best regards
>>
>> Heinrich
>>
>> > + break;
>> > + }
>> > default:
>> > s = dp_unknown(s, dp);
>> > break;
>>
Re: [PATCH v2 0/6] introduce EFI_RAM_DISK_PROTOCOL
Hi Tobias, On Sat, 15 Jul 2023 at 07:01, Tobias Waldekranz wrote: > > > Hi Masahisa, > > On fre, jul 14, 2023 at 14:44, Masahisa Kojima > wrote: > > This series introduces the EFI_RAM_DISK_PROTOCOL implementation. > > The major purpose of this series is a preparation for EFI HTTP(S) boot. > > > > Now U-Boot can download the distro installer ISO image > > via wget or tftpboot commands, but U-Boot can not mount > > the downloaded ISO image. > > A while back, I added the blkmap command and backend to U-Boot, which > is, among other things, capable of creating ramdisks. What exactly does > this series add that can't be supported by a block map? There is some > documentation available here: > > https://u-boot.readthedocs.io/en/latest/usage/blkmap.html Thank you for your comment. I am not aware of the blkmap feature. Yes, I can use blkmap for creating ramdisk. Thanks, Masahisa Kojima
Re: [PATCH v2 1/6] efi_loader: add RAM disk device path
Hi Heinrich,
On Fri, 14 Jul 2023 at 22:44, Heinrich Schuchardt wrote:
>
> On 14.07.23 07:44, Masahisa Kojima wrote:
> > This is a preparation to add the EFI_RAM_DISK_PROTOCOL.
> > This commit adds the RAM disk device path structure
> > and text conversion to Device Path to Text Protocol.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > No update since v1
> >
> > include/efi_api.h| 19 +++
> > lib/efi_loader/efi_device_path_to_text.c | 14 ++
> > 2 files changed, 33 insertions(+)
> >
> > diff --git a/include/efi_api.h b/include/efi_api.h
> > index 55a4c989fc..4ee4a1b5e9 100644
> > --- a/include/efi_api.h
> > +++ b/include/efi_api.h
> > @@ -682,6 +682,7 @@ struct efi_device_path_uri {
> > # define DEVICE_PATH_SUB_TYPE_CDROM_PATH 0x02
> > # define DEVICE_PATH_SUB_TYPE_VENDOR_PATH 0x03
> > # define DEVICE_PATH_SUB_TYPE_FILE_PATH0x04
> > +# define DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH 0x09
> >
> > struct efi_device_path_hard_drive_path {
> > struct efi_device_path dp;
> > @@ -705,6 +706,24 @@ struct efi_device_path_file_path {
> > u16 str[];
> > } __packed;
> >
> > +/* This GUID defines a RAM Disk supporting a raw disk format in volatile
> > memory */
> > +#define EFI_VIRTUAL_DISK_GUID \
> > + EFI_GUID(0x77ab535a, 0x45fc, 0x624b, \
> > + 0x55, 0x60, 0xf7, 0xb2, 0x81, 0xd1, 0xf9, 0x6e)
> > +
> > +/* This GUID defines a RAM Disk supporting an ISO image in volatile memory
> > */
> > +#define EFI_VIRTUAL_CD_GUID \
> > + EFI_GUID(0x3d5abd30, 0x4175, 0x87ce, \
> > + 0x6d, 0x64, 0xd2, 0xad, 0xe5, 0x23, 0xc4, 0xbb)
> > +
> > +struct efi_device_path_ram_disk_path {
> > + struct efi_device_path dp;
> > + u64 starting_address;
> > + u64 ending_address;
> > + efi_guid_t disk_type_guid;
> > + u16 disk_instance;
> > +} __packed;
> > +
> > #define EFI_BLOCK_IO_PROTOCOL_GUID \
> > EFI_GUID(0x964e5b21, 0x6459, 0x11d2, \
> >0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
> > diff --git a/lib/efi_loader/efi_device_path_to_text.c
> > b/lib/efi_loader/efi_device_path_to_text.c
> > index 8c76d8be60..4395e79f33 100644
> > --- a/lib/efi_loader/efi_device_path_to_text.c
> > +++ b/lib/efi_loader/efi_device_path_to_text.c
> > @@ -324,6 +324,20 @@ static char *dp_media(char *s, struct efi_device_path
> > *dp)
> > free(buffer);
> > break;
> > }
> > + case DEVICE_PATH_SUB_TYPE_RAM_DISK_PATH: {
> > + struct efi_device_path_ram_disk_path *rddp =
> > + (struct efi_device_path_ram_disk_path *)dp;
> > + u64 start;
> > + u64 end;
> > +
> > + /* Copy from packed structure to aligned memory */
> > + memcpy(&start, &rddp->starting_address, sizeof(start));
> > + memcpy(&end, &rddp->ending_address, sizeof(end));
> > +
> > + s += sprintf(s, "RamDisk(0x%llx,%llx,%pUl,0x%x)", start, end,
> > + &rddp->disk_type_guid, rddp->disk_instance);
>
> If there is no alignment guarantee for starting_address, then the same
> is true for disk_instance which may spread over two u64 blocks.
disk_instance is a u16 field, so it is aligned.
>
> In case of DEVICE_PATH_SUB_TYPE_MEMORY we don't use memcpy() to align u64.
>
> I don't think we call device_path_to_text before allow_unaligned().
>
> There is a family of functions like get_unaligned_le64() if we should
> ever need to a align a value. Or we could copy the whole device path node.
OK, I will use get_unaligned_le64().
Thanks,
Masahisa Kojima
>
> Best regards
>
> Heinrich
>
> > + break;
> > + }
> > default:
> > s = dp_unknown(s, dp);
> > break;
>
Re: [PATCH 3/3] usb: xhci-pci: Load ASMedia XHCI controller firmware
On 7/15/23 14:51, Mark Kettenis wrote: Date: Fri, 14 Jul 2023 23:30:43 +0200 From: Marek Vasut Hi Marek, Hi, Your suggestions are reasonable, but would make the driver deviate further from its Linux equivalent: https://github.com/AsahiLinux/linux/blob/asahi/drivers/usb/host/xhci-pci-asmedia.c Can the changes be upstreamed to Linux, if they sound reasonable ? Right now I can actually easily diff the two drivers to pick up improvements. Changing things the way you suggest would make that harder. [...]
Re: [PATCH 1/3] apple: Set up file system firmware loader
On 7/15/23 14:47, Mark Kettenis wrote:
Date: Fri, 14 Jul 2023 23:27:42 +0200
From: Marek Vasut
On 7/14/23 22:43, Mark Kettenis wrote:
Find the appropriate EFI system partition on the internal NVMe
storage and set the U-Boot environment variables such that
the file system firmware loader can load firmware from it.
Signed-off-by: Mark Kettenis
---
arch/arm/mach-apple/board.c | 60 +
1 file changed, 60 insertions(+)
diff --git a/arch/arm/mach-apple/board.c b/arch/arm/mach-apple/board.c
index d501948118..7799a0f916 100644
--- a/arch/arm/mach-apple/board.c
+++ b/arch/arm/mach-apple/board.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -539,6 +541,60 @@ u64 get_page_table_size(void)
return SZ_256K;
}
+static char *asahi_esp_devpart(void)
+{
+ struct disk_partition info;
+ struct blk_desc *nvme_blk;
+ const char *uuid = NULL;
+ int devnum, len, p, part, ret;
+ static char devpart[64];
+ struct udevice *dev;
+ ofnode node;
+
+ if (devpart[0])
+ return devpart;
+
+ node = ofnode_path("/chosen");
+ if (ofnode_valid(node)) {
+ uuid = ofnode_get_property(node, "asahi,efi-system-partition",
+ &len);
+ }
+
+ nvme_scan_namespace();
+ for (devnum = 0, part = 0;; devnum++) {
+ nvme_blk = blk_get_devnum_by_uclass_id(UCLASS_NVME, devnum);
+ if (nvme_blk == NULL)
+ break;
+
+ dev = dev_get_parent(nvme_blk->bdev);
+ if (!device_is_compatible(dev, "apple,nvme-ans2"))
Can we somehow use ofnode_for_each_compatible_node() here ?
That might simplify this code.
I don't really see how that would simplify things. I'm iterating over
all NVMe devices here and then checking the compatible of the parent
to make sure I pick the on-board one. I could do the inverse and
lookup the node first and then use that to find the NVMe block device,
but it will still involve a loop and several function calls.
What about:
"
struct blk_desc *desc;
ofnode_for_each_compatible_node(node, "apple,nvme-ans2") {
uclass_get_device_by_ofnode(UCLASS_NVME, node, &blk_dev);
desc = dev_get_uclass_plat(blk_dev);
for (count = 0, part = 1; part <= MAX_SEARCH_PARTITIONS; part++) {
part_get_info(desc, part, &info);
...
}
}
"
I'm _not_ sure anymore whether this is actually easier though.
What do you think ?
+ continue;
+
+ for (p = 1; p <= MAX_SEARCH_PARTITIONS; p++) {
+ ret = part_get_info(nvme_blk, p, &info);
+ if (ret < 0)
+ break;
+
+ if (info.bootable & PART_EFI_SYSTEM_PARTITION) {
+ if (uuid && strcasecmp(uuid, info.uuid) == 0) {
+ part = p;
+ break;
+ }
+ if (part == 0)
+ part = p;
+ }
+ }
+
+ if (part > 0)
+ break;
+ }
+
+ if (part > 0)
+ snprintf(devpart, sizeof(devpart), "%d:%d", devnum, part);
+
+ return devpart;
+}
+
#define KERNEL_COMP_SIZE SZ_128M
int board_late_init(void)
@@ -546,6 +602,10 @@ int board_late_init(void)
struct lmb lmb;
u32 status = 0;
+ status |= env_set("storage_interface",
+ blk_get_uclass_name(UCLASS_NVME));
+ status |= env_set("fw_dev_part", asahi_esp_devpart());
I think env_set() returns integer (and this could be negative too), so
you might want to check the return value instead of casting it to
unsigned integer.
I'm just using the existing idiom. But maybe I should just check the
return value and throw a warning instead? Not having the firmware
loader available isn't fatal. It just means some of the USB ports
won't work.
That's better, yeah. I don't think you can safely do bitwise operations
on signed types.
[PATCH] arm: mach-k3: am62a7: change some prints to debug prints
There is little need to print the devstat information or when we exit a
function during a typical boot. Remove them to reduce the noise during
typical operation
Signed-off-by: Bryan Brattlof
---
arch/arm/mach-k3/am62a7_init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-k3/am62a7_init.c b/arch/arm/mach-k3/am62a7_init.c
index 1f51b04089696..8dd00f018d21d 100644
--- a/arch/arm/mach-k3/am62a7_init.c
+++ b/arch/arm/mach-k3/am62a7_init.c
@@ -174,7 +174,7 @@ void board_init_f(ulong dummy)
setup_qos();
- printf("am62a_init: %s done\n", __func__);
+ debug("am62a_init: %s done\n", __func__);
}
static u32 __get_backup_bootmedia(u32 devstat)
@@ -272,7 +272,7 @@ u32 spl_boot_device(void)
else
bootmedia = __get_backup_bootmedia(devstat);
- printf("am62a_init: %s: devstat = 0x%x bootmedia = 0x%x bootindex =
%d\n",
+ debug("am62a_init: %s: devstat = 0x%x bootmedia = 0x%x bootindex =
%d\n",
__func__, devstat, bootmedia, bootindex);
return bootmedia;
}
base-commit: 13aa090b87a0fbdfe690011669b9fdb96bb1ccc7
--
2.41.0
[PATCH] ram: k3-ddrss: do not touch ctrl regs during training
During LPDDR initialization we will loop through a series of frequency
changes in order to train at the various operating frequencies. During
this training, accessing the DRAM_CLASS bitfield could happen during a
frequency change and cause the read to hang.
Store the DRAM type into the main structure to avoid multiple readings
while the independent phy is training.
Signed-off-by: Bryan Brattlof
---
drivers/ram/k3-ddrss/k3-ddrss.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/ram/k3-ddrss/k3-ddrss.c b/drivers/ram/k3-ddrss/k3-ddrss.c
index 7e445d2b737b3..b54557f02cce1 100644
--- a/drivers/ram/k3-ddrss/k3-ddrss.c
+++ b/drivers/ram/k3-ddrss/k3-ddrss.c
@@ -138,6 +138,7 @@ struct k3_ddrss_desc {
u32 ddr_freq1;
u32 ddr_freq2;
u32 ddr_fhs_cnt;
+ u32 dram_class;
struct udevice *vtt_supply;
u32 instance;
lpddr4_obj *driverdt;
@@ -243,14 +244,11 @@ static void k3_lpddr4_freq_update(struct k3_ddrss_desc
*ddrss)
static void k3_lpddr4_ack_freq_upd_req(const lpddr4_privatedata *pd)
{
- u32 dram_class;
struct k3_ddrss_desc *ddrss = (struct k3_ddrss_desc *)pd->ddr_instance;
debug("--->>> LPDDR4 Initialization is in progress ... <<<---\n");
- dram_class = k3_lpddr4_read_ddr_type(pd);
-
- switch (dram_class) {
+ switch (ddrss->dram_class) {
case DENALI_CTL_0_DRAM_CLASS_DDR4:
break;
case DENALI_CTL_0_DRAM_CLASS_LPDDR4:
@@ -263,13 +261,12 @@ static void k3_lpddr4_ack_freq_upd_req(const
lpddr4_privatedata *pd)
static int k3_ddrss_init_freq(struct k3_ddrss_desc *ddrss)
{
- u32 dram_class;
int ret;
lpddr4_privatedata *pd = &ddrss->pd;
- dram_class = k3_lpddr4_read_ddr_type(pd);
+ ddrss->dram_class = k3_lpddr4_read_ddr_type(pd);
- switch (dram_class) {
+ switch (ddrss->dram_class) {
case DENALI_CTL_0_DRAM_CLASS_DDR4:
/* Set to ddr_freq1 from DT for DDR4 */
ret = clk_set_rate(&ddrss->ddr_clk, ddrss->ddr_freq1);
base-commit: 13aa090b87a0fbdfe690011669b9fdb96bb1ccc7
--
2.41.0
Re: [PATCH 1/2] arm64: dts: rockchip: Sync DT from linux-next
On 7/17/23 18:42, Jagan Teki wrote:
Sync the linux-next from below commit,
commit <1642bf66e270> ("arm64: dts: rockchip: add USB2 to
rk3588s-rock5a")
Also rops the duplicate usb nodes from rk3588s-u-boot.dtsi
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3588-edgeble-neu6a.dtsi | 1 -
arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 66 +++
arch/arm/dts/rk3588-edgeble-neu6b.dtsi | 359 ++-
arch/arm/dts/rk3588-evb1-v10.dts | 720 ++-
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 13 -
arch/arm/dts/rk3588-rock-5b.dts | 578 +-
arch/arm/dts/rk3588.dtsi | 112
arch/arm/dts/rk3588s-u-boot.dtsi | 119
arch/arm/dts/rk3588s.dtsi| 499 +++-
include/dt-bindings/ata/ahci.h | 20 +
10 files changed, 2346 insertions(+), 141 deletions(-)
create mode 100644 include/dt-bindings/ata/ahci.h
[...]
};
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index c703e41802..f8c10227b0 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -13,103 +13,12 @@
status = "okay";
};
- usb_host0_ehci: usb@fc80 {
- compatible = "generic-ehci";
- reg = <0x0 0xfc80 0x0 0x4>;
- interrupts = ;
- clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST_ARB0>;
- clock-names = "usbhost", "arbiter";
- power-domains = <&power RK3588_PD_USB>;
- status = "disabled";
- };
No, this has to stay, the new nodes in kernel break usb2 on rk3588
platforms in U-boot.
In u-boot, the PHY is not a clock provider. Hence the breakage.
Only when the PHY becomes a clock provider you can remove these nodes here.
Check below the difference which I highlighted:
-
- usb_host0_ohci: usb@fc84 {
- compatible = "generic-ohci";
- reg = <0x0 0xfc84 0x0 0x4>;
- interrupts = ;
- clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST_ARB0>;
- clock-names = "usbhost", "arbiter";
- power-domains = <&power RK3588_PD_USB>;
- status = "disabled";
- };
-
- usb_host1_ehci: usb@fc88 {
- compatible = "generic-ehci";
- reg = <0x0 0xfc88 0x0 0x4>;
- interrupts = ;
- clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST_ARB1>;
- clock-names = "usbhost", "arbiter";
- power-domains = <&power RK3588_PD_USB>;
- status = "disabled";
- };
-
- usb_host1_ohci: usb@fc8c {
- compatible = "generic-ohci";
- reg = <0x0 0xfc8c 0x0 0x4>;
- interrupts = ;
- clocks = <&cru HCLK_HOST1>, <&cru HCLK_HOST_ARB1>;
- clock-names = "usbhost", "arbiter";
- power-domains = <&power RK3588_PD_USB>;
- status = "disabled";
- };
-
pmu1_grf: syscon@fd58a000 {
bootph-all;
compatible = "rockchip,rk3588-pmu1-grf", "syscon";
reg = <0x0 0xfd58a000 0x0 0x2000>;
};
- pipe_phy0_grf: syscon@fd5bc000 {
- compatible = "rockchip,pipe-phy-grf", "syscon";
- reg = <0x0 0xfd5bc000 0x0 0x100>;
- };
-
- usb2phy2_grf: syscon@fd5d8000 {
- compatible = "rockchip,rk3588-usb2phy-grf", "syscon",
-"simple-mfd";
- reg = <0x0 0xfd5d8000 0x0 0x4000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- u2phy2: usb2-phy@8000 {
- compatible = "rockchip,rk3588-usb2phy";
- reg = <0x8000 0x10>;
- interrupts = ;
- clocks = <&cru CLK_USB2PHY_HDPTXRXPHY_REF>;
- clock-names = "phyclk";
- #clock-cells = <0>;
- status = "disabled";
-
- u2phy2_host: host-port {
- #phy-cells = <0>;
- status = "disabled";
- };
- };
- };
-
- usb2phy3_grf: syscon@fd5dc000 {
- compatible = "rockchip,rk3588-usb2phy-grf", "syscon",
-"simple-mfd";
- reg = <0x0 0xfd5dc000 0x0 0x4000>;
- #address-cells = <1>;
- #size-cells = <1>;
-
- u2phy3: usb2-phy@c000 {
- compatible = "rockchip,rk3588-usb2phy";
- reg = <0xc000 0x10>;
- interrupts = ;
- clocks = <&cru CLK_USB2PHY_HDPTXRXPHY_REF>;
- clock-names = "phyclk";
- #clock-cells = <0>;
- status = "disabled";
-
-
Re: [PATCH 0/2] arm: dts: k3-am6: Sync DT with Linux
On 17:56-20230710, Roger Quadros wrote: > Hi, > > This series syncs AM64/AM62 DT files with Linux. > > cheeers, > -roger > > Roger Quadros (2): > arm: dts: k3-am64: Sync DT with Linux > board: ti: am64x: Recognize AM64-HSEVM Roger, We need to base on binman stuff. I already posted am62x sync, but as you notice - there is a bunch more cleanups to do there. https://lore.kernel.org/all/20230713072019.3153871-1...@ti.com/ If you don'nt mind syncing with me on irc, we can work through the details needed. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v10 3/4] Boot var automatic management for removable medias
Hi Heinrich,
I run 'make tests' with the patches locally but no errors observed from
'test_signed.py', below are few lines from the output console:
```
test/py/tests/test_efi_secboot/test_signed.py
[ 90%]
```
Regards,
Raymond
On Sat, 15 Jul 2023 at 05:19, Heinrich Schuchardt
wrote:
> On 7/9/23 10:56, Heinrich Schuchardt wrote:
> > On 6/19/23 23:23, Raymond Mao wrote:
> >> Changes for complying to EFI spec §3.5.1.1
> >> 'Removable Media Boot Behavior'.
> >> Boot variables can be automatically generated during a removable
> >> media is probed. At the same time, unused boot variables will be
> >> detected and removed.
> >>
> >> Please note that currently the function 'efi_disk_remove' has no
> >> ability to distinguish below two scenarios
> >> a) Unplugging of a removable media under U-Boot
> >> b) U-Boot exiting and booting an OS
> >> Thus currently the boot variables management is not added into
> >> 'efi_disk_remove' to avoid boot options being added/erased
> >> repeatedly under scenario b) during power cycles
> >> See TODO comments under function 'efi_disk_remove' for more details
> >>
> >> Signed-off-by: Raymond Mao
> >> ---
> >> Changes in v3
> >> - Split the patch into moving and renaming functions and
> >>individual patches for each changed functionality
> >> Changes in v5
> >> - Move function call of efi_bootmgr_update_media_device_boot_option()
> >>from efi_init_variables() to efi_init_obj_list()
> >> Changes in v6
> >> - Revert unrelated changes
> >> Changes in v7
> >> - adapt the return code of function
> >>efi_bootmgr_update_media_device_boot_option()
> >> Changes in v8
> >> - add a note in the commit message for future reference
> >> Changes in v9
> >> - amend the note text in the commit message
> >> - add a TODO comment in 'efi_disk_remove'
> >> Changes in v10
> >> - fix typo and build failures with 'CONFIG_CMD_BOOTEFI_BOOTMGR=n'
> >>
> >> lib/efi_loader/efi_disk.c | 18 ++
> >> lib/efi_loader/efi_setup.c | 7 +++
> >> 2 files changed, 25 insertions(+)
> >>
> >> diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
> >> index d2256713a8..911a4adfb1 100644
> >> --- a/lib/efi_loader/efi_disk.c
> >> +++ b/lib/efi_loader/efi_disk.c
> >> @@ -687,6 +687,13 @@ int efi_disk_probe(void *ctx, struct event *event)
> >> return -1;
> >> }
> >> +/* only do the boot option management when UEFI sub-system is
> >> initialized */
> >> +if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR) &&
> >> efi_obj_list_initialized == EFI_SUCCESS) {
> >> +ret = efi_bootmgr_update_media_device_boot_option();
> >> +if (ret != EFI_SUCCESS)
> >> +return -1;
> >> +}
> >> +
> >> return 0;
> >> }
> >> @@ -773,6 +780,17 @@ int efi_disk_remove(void *ctx, struct event *event)
> >> return efi_disk_delete_part(dev);
> >> else
> >> return 0;
> >> +
> >> +/*
> >> + * TODO A flag to distinguish below 2 different scenarios of this
> >> + * function call is needed:
> >> + * a) Unplugging of a removable media under U-Boot
> >> + * b) U-Boot exiting and booting an OS
> >> + * In case of scenario a),
> >> efi_bootmgr_update_media_device_boot_option()
> >> + * needs to be invoked here to update the boot options and remove
> >> the
> >> + * unnecessary ones.
> >> + */
> >
> > As in future we want to integrate more EFI drivers with the driver model
> > such a status should be in a global variable. It will have to be set in
> > ExitBootServices() before invoking dm_remove_devices_flags().
> >
> > Reviewed-by: Heinrich Schuchardt
> >
> >> +
> >> }
> >> /**
> >> diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
> >> index 58d4e13402..69c8b27730 100644
> >> --- a/lib/efi_loader/efi_setup.c
> >> +++ b/lib/efi_loader/efi_setup.c
> >> @@ -245,6 +245,13 @@ efi_status_t efi_init_obj_list(void)
> >> if (ret != EFI_SUCCESS)
> >> goto out;
> >> +if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
> >> +/* update boot option after variable service initialized */
> >> +ret = efi_bootmgr_update_media_device_boot_option();
> >> +if (ret != EFI_SUCCESS)
> >> +goto out;
> >> +}
> >> +
> >> /* Define supported languages */
> >> ret = efi_init_platform_lang();
> >> if (ret != EFI_SUCCESS)
> >
>
> This patch leads to a test failure in
>
>
> test/py/tests/test_efi_secboot/test_signed.py::TestEfiSignedImage::test_efi_signed_image_auth2
>
> No EFI system partition
> Failed to persist EFI variables
>
> Please, run 'make tests' before resubmitting.
>
> Best regards
>
> Heinrich
>
[PATCH] arm: sunxi: Correct warning in board_fit_config_name_match
When building this with clang, we get a warning about having excess
parenthesis here, or that we're incorrectly using "==" when we want "=".
Correct these by using parenthesis around our multiplication of
constants as this is what was likely intended originally, even if not
strictly required.
Signed-off-by: Tom Rini
---
Cc: Andre Przywara
---
board/sunxi/board.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index f321cd58a6e6..643e8db185b4 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -957,7 +957,7 @@ int board_fit_config_name_match(const char *name)
#ifdef CONFIG_PINE64_DT_SELECTION
if (strstr(best_dt_name, "-pine64-plus")) {
/* Differentiate the Pine A64 boards by their DRAM size. */
- if ((gd->ram_size == 512 * 1024 * 1024))
+ if (gd->ram_size == (512 * 1024 * 1024))
best_dt_name = "sun50i-a64-pine64";
}
#endif
--
2.34.1
[PATCH] arm: omap2: Fix warning in force_emif_self_refresh
The function declaration for force_emif_self_refresh takes no parameters
but does not specify this, only the prototype in the headers do. As
clang will warn about this, correct it.
Signed-off-by: Tom Rini
---
arch/arm/mach-omap2/emif-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/emif-common.c
b/arch/arm/mach-omap2/emif-common.c
index a6a97af37d7b..9daaeef73190 100644
--- a/arch/arm/mach-omap2/emif-common.c
+++ b/arch/arm/mach-omap2/emif-common.c
@@ -40,7 +40,7 @@ void set_lpmode_selfrefresh(u32 base)
readl(&emif->emif_pwr_mgmt_ctrl);
}
-void force_emif_self_refresh()
+void force_emif_self_refresh(void)
{
set_lpmode_selfrefresh(EMIF1_BASE);
if (!is_dra72x())
--
2.34.1
Re: [PATCH v2 0/2] power: pmic: add TPS65913 support
17 липня 2023 р. 21:52:58 GMT+03:00, Jonas Karlman
написав(-ла):
>On 2023-07-16 20:57, Svyatoslav Ryhel wrote:
>> 16 липня 2023 р. 16:07:55 GMT+03:00, Simon Glass
>> написав(-ла):
>>> Hi Svyatoslav,
>>>
>>> On Sun, 16 Jul 2023 at 07:04, Svyatoslav Ryhel wrote:
16 липня 2023 р. 11:07:15 GMT+03:00, Jonas Karlman
написав(-ла):
> On 2023-07-16 05:57, Svyatoslav Ryhel wrote:
>>
>>
>> 16 липня 2023 р. 02:37:39 GMT+03:00, Jonas Karlman
>> написав(-ла):
>>> On 2023-07-15 20:34, Svyatoslav Ryhel wrote:
Existing PALMAS PMIC driver is fully compatible with TI TPS65913
PMIC found in many Tegra 4 devices, like Tegra Note 7 and ASUS
TF701T. Add TPS65913 dts compatible with TPS659038 data.
Issue with regulators is more general then I though initially.
It touches all pmic regulators.
Currently device tree entries of regulators are completely
ignored and regulators are probed only if they are called
by the device which uses it. This results into two issues:
regulators which must run under boot-on or always-on mode
are ignored and not enabled; dts props like voltage are
not applied to the regulator so the regulator may be enabled
with random actual voltage, which may have unexpected
consequences.
>>>
>>> This sounds like something a call to regulators_enable_boot_on like is
>>> done on other platforms/boards could solve?
>>
>> Yes, regulators_enable_boot_on can solve this if called from the board,
>> but why should every device call this from the board if this should be
>> done automatically? What should do devices without board? Isn't u-boot
>> moving towards all in device tree setup?
>
> Main diff is that regulators_enable_boot_on covers all regulators,
> including fixed/gpio/pwm regulators, not just regulators that are
> children of a pmic. Meaning platforms/boards would still need to somehow
> autoset non-pmic regulators.
This is a good point. Non pmic regulators are not probed/set.
> Maybe regulators_enable_boot_on could be called from the default
> power_init_board or similar, when a Kconfig is enabled, to cover more
> platforms/boards.
Since u-boot is moving towards device trees this should be undesireable
approach. What is possible is to set all non pmic regulators to probe on
post bind and on post probe call regulator_autoset.
>>>
>>> Yes we should handle this automatically without board-specific C code,
>>> where possible.
>>
>> Commit, Jonas Karlman refers to 4fcba5d556b4 ("regulator: implement
>> basic reference counter") introduces too much conflicting.
>>
>> 1. It should not have been merged in the current state and instead expanded
>> for all uclass. Counting regulator users is not fixed/gpio regulator
>> specific and can be beneficial for all devices.
>
>I think it was limited to fixed/gpio regulators just to not affect too
>many arch/boards. And can always be extended to core regulator uclass in
>the future.
I have spent the entire day on this stuff. I will load my propositions tomorrow.
>There is also drivers that do not currently keep enable/disable balanced,
>will shortly send a series with fixes for a few I have discovered.
Well, iirc all devices without remove have imbalanced calls. It should not be
as critical as it is for linux.
>>
>> 2. Usage of board and device tree call to set up regulators will not work
>> well with counting enables/disables. The correct solution should be to
>> remove board calls for regulator setup but it will involve rework of many
>> boards.
>
>This was main reason why I mentioned this commit, it currently works, but
>if you introduce new code that call regulator_autoset from post probe,
>existing code must be adjusted or removed.
Removed.
>E.g. regulators_enable_boot_on called in a rockchip arch shared
>board_init could be removed. Or logic in regulator_autoset can be
>changed to only run code once for each regulator. Or add a Kconfig to
>enable post probe autoset and disable autoset in regulators_enable_boot_on.
I will load tomorrow what I have found. But it is not complete and I would need
all possible help and assist I can get from community.
Jonas, Simon, thank you for your responces. Those are highly appresiated.
Best regards,
Svyatoslav R.
>Regards,
>Jonas
>
>>
>>> Regards,
>>> Simon
>
Re: Please pull u-boot-x86
On Mon, Jul 17, 2023 at 08:44:03PM +0800, Bin Meng wrote: > Hi Tom, > > This PR includes the following x86 related changes for v2023.10 release: > > - bootstd: Add a bootmeth for ChromiumOS on x86 > - x86: Use qemu-x86_64 to boot EFI installers > > Azure results: PASS > https://dev.azure.com/bmeng/GitHub/_build/results?buildId=494&view=results > > The following changes since commit e6e67bb9e0a40f3eb3c87d16935192821987c3e0: > > Merge branch '2023-07-14-assorted-general-updates' (2023-07-14 15:21:48 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86 > > for you to fetch changes up to b8956425d525c3c25fd218f252f89a5e44df6a9f: > > x86: Switch QEMU over to use the bochs driver (2023-07-17 17:23:15 +0800) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 0/2] power: pmic: add TPS65913 support
On 2023-07-16 20:57, Svyatoslav Ryhel wrote:
> 16 липня 2023 р. 16:07:55 GMT+03:00, Simon Glass
> написав(-ла):
>> Hi Svyatoslav,
>>
>> On Sun, 16 Jul 2023 at 07:04, Svyatoslav Ryhel wrote:
>>>
>>>
>>>
>>> 16 липня 2023 р. 11:07:15 GMT+03:00, Jonas Karlman
>>> написав(-ла):
On 2023-07-16 05:57, Svyatoslav Ryhel wrote:
>
>
> 16 липня 2023 р. 02:37:39 GMT+03:00, Jonas Karlman
> написав(-ла):
>> On 2023-07-15 20:34, Svyatoslav Ryhel wrote:
>>> Existing PALMAS PMIC driver is fully compatible with TI TPS65913
>>> PMIC found in many Tegra 4 devices, like Tegra Note 7 and ASUS
>>> TF701T. Add TPS65913 dts compatible with TPS659038 data.
>>>
>>> Issue with regulators is more general then I though initially.
>>> It touches all pmic regulators.
>>>
>>> Currently device tree entries of regulators are completely
>>> ignored and regulators are probed only if they are called
>>> by the device which uses it. This results into two issues:
>>> regulators which must run under boot-on or always-on mode
>>> are ignored and not enabled; dts props like voltage are
>>> not applied to the regulator so the regulator may be enabled
>>> with random actual voltage, which may have unexpected
>>> consequences.
>>
>> This sounds like something a call to regulators_enable_boot_on like is
>> done on other platforms/boards could solve?
>
> Yes, regulators_enable_boot_on can solve this if called from the board,
> but why should every device call this from the board if this should be
> done automatically? What should do devices without board? Isn't u-boot
> moving towards all in device tree setup?
Main diff is that regulators_enable_boot_on covers all regulators,
including fixed/gpio/pwm regulators, not just regulators that are
children of a pmic. Meaning platforms/boards would still need to somehow
autoset non-pmic regulators.
>>>
>>> This is a good point. Non pmic regulators are not probed/set.
>>>
Maybe regulators_enable_boot_on could be called from the default
power_init_board or similar, when a Kconfig is enabled, to cover more
platforms/boards.
>>>
>>> Since u-boot is moving towards device trees this should be undesireable
>>> approach. What is possible is to set all non pmic regulators to probe on
>>> post bind and on post probe call regulator_autoset.
>>
>> Yes we should handle this automatically without board-specific C code,
>> where possible.
>
> Commit, Jonas Karlman refers to 4fcba5d556b4 ("regulator: implement
> basic reference counter") introduces too much conflicting.
>
> 1. It should not have been merged in the current state and instead expanded
> for all uclass. Counting regulator users is not fixed/gpio regulator specific
> and can be beneficial for all devices.
I think it was limited to fixed/gpio regulators just to not affect too
many arch/boards. And can always be extended to core regulator uclass in
the future.
There is also drivers that do not currently keep enable/disable balanced,
will shortly send a series with fixes for a few I have discovered.
>
> 2. Usage of board and device tree call to set up regulators will not work
> well with counting enables/disables. The correct solution should be to remove
> board calls for regulator setup but it will involve rework of many boards.
This was main reason why I mentioned this commit, it currently works, but
if you introduce new code that call regulator_autoset from post probe,
existing code must be adjusted or removed.
E.g. regulators_enable_boot_on called in a rockchip arch shared
board_init could be removed. Or logic in regulator_autoset can be
changed to only run code once for each regulator. Or add a Kconfig to
enable post probe autoset and disable autoset in regulators_enable_boot_on.
Regards,
Jonas
>
>> Regards,
>> Simon
Re: [PATCH] pci: Fix device_find_first_child() return value handling
On 7/17/23 09:42, Michal Suchánek wrote:
Hello,
On Sun, Jul 16, 2023 at 05:53:24PM +0200, Marek Vasut wrote:
This function only ever returns 0, but may not assign the second
parameter. Same thing for device_find_next_child(). Do not assign
ret to stop proliferation of this misuse.
Reported-by: Jonas Karlman
Signed-off-by: Marek Vasut
---
Cc: "Pali Rohár"
Cc: Bin Meng
Cc: Marek Vasut
Cc: Michal Suchanek
Cc: Simon Glass
---
drivers/pci/pci-uclass.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 8d27e40338c..6421eda7721 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -545,9 +545,9 @@ int pci_auto_config_devices(struct udevice *bus)
sub_bus = dev_seq(bus);
debug("%s: start\n", __func__);
pciauto_config_init(hose);
- for (ret = device_find_first_child(bus, &dev);
-!ret && dev;
-ret = device_find_next_child(&dev)) {
+ for (device_find_first_child(bus, &dev);
+dev;
+device_find_next_child(&dev)) {
Sounds like you will need to remove the declaration of the now unused ret
variable as well.
More generally, what is the overall vision for these functions returning
always zero?
Should the return value be kept in case the underlying implementation
changes and errors can happen in the future, and consequently checked?
Should the return value be removed when meaningless making these
useless assignments and checks an error?
I already elimimnated a return value where using it lead to incorrect
behavior but here using it or not is equally correct with the current
implementation.
Probably a question for Simon, really. Personally I would be tempted to
switch the function to return void.
Re: [PATCH 1/2] arm64: dts: rockchip: Sync DT from linux-next
Hi Jagan,
On 2023-07-17 17:42, Jagan Teki wrote:
> Sync the linux-next from below commit,
> commit <1642bf66e270> ("arm64: dts: rockchip: add USB2 to
> rk3588s-rock5a")
Eugen sent a sync patch earlier, guess this contains a newer sync with
more features/nodes :-)
See
https://patchwork.ozlabs.org/project/uboot/patch/20230529073423.24371-1-eugen.hris...@collabora.com/
>
> Also rops the duplicate usb nodes from rk3588s-u-boot.dtsi
nit: drops
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm/dts/rk3588-edgeble-neu6a.dtsi | 1 -
> arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 66 +++
> arch/arm/dts/rk3588-edgeble-neu6b.dtsi | 359 ++-
> arch/arm/dts/rk3588-evb1-v10.dts | 720 ++-
> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 13 -
> arch/arm/dts/rk3588-rock-5b.dts | 578 +-
> arch/arm/dts/rk3588.dtsi | 112
> arch/arm/dts/rk3588s-u-boot.dtsi | 119
> arch/arm/dts/rk3588s.dtsi| 499 +++-
> include/dt-bindings/ata/ahci.h | 20 +
> 10 files changed, 2346 insertions(+), 141 deletions(-)
> create mode 100644 include/dt-bindings/ata/ahci.h
>
[...]
> diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> index 1cd8a57a6f..03d1560564 100644
> --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
> @@ -99,11 +99,6 @@
> bootph-all;
> };
>
> -&sdmmc {
> - bus-width = <4>;
> - status = "okay";
> -};
> -
> &sdmmc_bus4 {
> bootph-all;
> };
> @@ -120,14 +115,6 @@
> bootph-all;
> };
>
> -&sdhci {
> - cap-mmc-highspeed;
> - mmc-ddr-1_8v;
> - mmc-hs200-1_8v;
> - pinctrl-names = "default";
> - pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_data_strobe
> &emmc_rstnout>;
> -};
This should not be removed, the missing modes and pinctrl has still not been
sent upstream, please leave this node.
Regards,
Jonas
> -
> &sfc {
> bootph-pre-ram;
> u-boot,spl-sfc-no-dma;
[...]
Re: [PATCH] android_ab: Add option to skip decrementing tries
Ping?
On Fri, Jun 23, 2023 at 4:06 PM Joshua Watt wrote:
>
> It is is sometimes desired to be able to skip decrementing the number of
> tries remaining in an Android A/B boot, and instead just check which
> slot will be tried later. This can commonly be be the case for platforms
> that want to A/B u-boot itself, but are required to boot from a FAT MBR
> partition. In these cases, u-boot must do an early check that the MBR
> points to the correct A/B boot partition, and if not rewrite the MBR to
> point to the correct one and reboot. Decrementing the try count in this
> case is not desired because it means that each u-boot might constantly
> ping-pong overwriting the MBR and rebooting until all the retries are
> used up.
>
> Signed-off-by: Joshua Watt
> ---
> boot/android_ab.c| 9 ++---
> cmd/ab_select.c | 20
> include/android_ab.h | 3 ++-
> 3 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/boot/android_ab.c b/boot/android_ab.c
> index 2d7b392666..60ae002978 100644
> --- a/boot/android_ab.c
> +++ b/boot/android_ab.c
> @@ -181,7 +181,8 @@ static int ab_compare_slots(const struct slot_metadata *a,
> return 0;
> }
>
> -int ab_select_slot(struct blk_desc *dev_desc, struct disk_partition
> *part_info)
> +int ab_select_slot(struct blk_desc *dev_desc, struct disk_partition
> *part_info,
> + bool dec_tries)
> {
> struct bootloader_control *abc = NULL;
> u32 crc32_le;
> @@ -272,8 +273,10 @@ int ab_select_slot(struct blk_desc *dev_desc, struct
> disk_partition *part_info)
> log_err("ANDROID: Attempting slot %c, tries remaining %d\n",
> BOOT_SLOT_NAME(slot),
> abc->slot_info[slot].tries_remaining);
> - abc->slot_info[slot].tries_remaining--;
> - store_needed = true;
> + if (dec_tries) {
> + abc->slot_info[slot].tries_remaining--;
> + store_needed = true;
> + }
> }
>
> if (slot >= 0) {
> diff --git a/cmd/ab_select.c b/cmd/ab_select.c
> index 3e46663d6e..bfb67b8236 100644
> --- a/cmd/ab_select.c
> +++ b/cmd/ab_select.c
> @@ -16,10 +16,19 @@ static int do_ab_select(struct cmd_tbl *cmdtp, int flag,
> int argc,
> struct blk_desc *dev_desc;
> struct disk_partition part_info;
> char slot[2];
> + bool dec_tries = true;
>
> - if (argc != 4)
> + if (argc < 4)
> return CMD_RET_USAGE;
>
> + for (int i = 4; i < argc; i++) {
> + if (strcmp(argv[i], "--no-dec") == 0) {
> + dec_tries = false;
> + } else {
> + return CMD_RET_USAGE;
> + }
> + }
> +
> /* Lookup the "misc" partition from argv[2] and argv[3] */
> if (part_get_info_by_dev_and_name_or_num(argv[2], argv[3],
> &dev_desc, &part_info,
> @@ -27,7 +36,8 @@ static int do_ab_select(struct cmd_tbl *cmdtp, int flag,
> int argc,
> return CMD_RET_FAILURE;
> }
>
> - ret = ab_select_slot(dev_desc, &part_info);
> +
> + ret = ab_select_slot(dev_desc, &part_info, dec_tries);
> if (ret < 0) {
> printf("Android boot failed, error %d.\n", ret);
> return CMD_RET_FAILURE;
> @@ -41,9 +51,9 @@ static int do_ab_select(struct cmd_tbl *cmdtp, int flag,
> int argc,
> return CMD_RET_SUCCESS;
> }
>
> -U_BOOT_CMD(ab_select, 4, 0, do_ab_select,
> +U_BOOT_CMD(ab_select, 5, 0, do_ab_select,
>"Select the slot used to boot from and register the boot attempt.",
> - " \n"
> + " [--no-dec]\n"
>"- Load the slot metadata from the partition 'part' on\n"
>" device type 'interface' instance 'dev' and store the
> active\n"
>" slot in the 'slot_var_name' variable. This also updates
> the\n"
> @@ -53,4 +63,6 @@ U_BOOT_CMD(ab_select, 4, 0, do_ab_select,
>"- If 'part_name' is passed, preceded with a # instead of :,
> the\n"
>" partition name whose label is 'part_name' will be looked up
> in\n"
>" the partition table. This is commonly the \"misc\"
> partition.\n"
> + "- If '--no-dec' is set, the number of tries remaining will
> not\n"
> + " decremented for the selected boot slot\n"
> );
> diff --git a/include/android_ab.h b/include/android_ab.h
> index 3eb61125c6..1fee7582b9 100644
> --- a/include/android_ab.h
> +++ b/include/android_ab.h
> @@ -30,6 +30,7 @@ struct disk_partition;
> * @param[in] part_info Place to store the partition information
> * Return: The slot number (>= 0) on success, or a negative on error
> */
> -int ab_select_slot(struct blk_desc *dev_desc, struct disk_partition
> *part_info);
> +int ab_select_slot(struct blk_desc *dev_desc, struct disk_part
Re: [PATCH v1 4/5] rockchip: evb_rk3229: Update/fix README
Hi Jerome, Am 17.07.23 um 15:42 schrieb Jerome Forissier: On 7/16/23 10:10, Alex Bee wrote: This updates the evb_rk3229's README on howto create / use the FIT image created by binman. Also fix some wrong paths and update filenames which have changed in recent upstream optee-os versions. Signed-off-by: Alex Bee --- board/rockchip/evb_rk3229/README | 72 +--- 1 file changed, 48 insertions(+), 24 deletions(-) diff --git a/board/rockchip/evb_rk3229/README b/board/rockchip/evb_rk3229/README index 9068225e27..e4c88bac06 100644 --- a/board/rockchip/evb_rk3229/README +++ b/board/rockchip/evb_rk3229/README @@ -13,25 +13,23 @@ Compile the OP-TEE > cd optee_os > make clean - > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x - Get tee.bin in this step, copy it to U-Boot root dir: - > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin + > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x + Get tee-pager_v2.bin in this step, copy it to U-Boot root dir: + > cp out/arm-plat-rockchip/core/tee-pager_v2.bin ../u-boot/tee.bin Since OP-TEE 3.21.0, there is a tee-raw.bin file. I recommend using it instead of tee-pager_v2.bin. Technically they are identical when the OP-TEE "pager" feature is disabled, but the name makes more sense. Thanks for the hint. I'll change that in v2. Regards, Alex
Re: [PATCH 0/8] Some fixes for the rockchip dw_mipi_dsi driver
On Mon, Jul 17, 2023 at 06:01:47PM +0200, Anatolij Gustschin wrote: > > On Thu, 13 Jul 2023 18:03:48 +0200 > Ondřej Jirman m...@xff.cz wrote: > > > On Thu, Jul 13, 2023 at 05:47:47PM +0200, Anatolij Gustschin wrote: > > > > > > On Thu, 13 Jul 2023 16:51:36 +0200 > > > Ondřej Jirman m...@xff.cz wrote: > > > > > > > Hi, > > > > > > > > On Mon, May 22, 2023 at 11:47:00PM +0200, megi xff wrote: > > > > > > > > > > > > > > > From: Ondrej Jirman > > > > > > > > > > These are just random fixes for bugs I found while eyeballing the > > > > > code and porting > > > > > it to work with RK3399. > > > > > > > > It would be nice if somebody merged this. I'd like to add display > > > > support for > > > > a few boards, and these patches are just fairly obvious bugfixes in new > > > > code > > > > added in 2023.07 that I hoped would get merged in the bugfix part of > > > > the merge > > > > window. > > > > > > I hoped to get a Tested-by for this series to make sure it does not break > > > current users. > > > > It's a miracle it even works for the current users, given the wrong > > way the current code writes to GRF registers, which makes it to have > > no intended effect, etc. > > > > Anyway, is there some upper limit to wait for Tested-by? 2 months seems > > excessive. Just so I can remind myself sooner next time. :) > > > > I can understand a few weeks, but 2 months just deters contributions. > > I usually apply new patches during the merge window (we have three months > release cycle) and this patch series was sent when the merge window was > closed. If patches are bug fixes (like in this case) I prefer to get them > tested by someone who has the actual hardware. When there is an Acked-by > or Tested-by, then I apply the fixes for -rcX. We already had several cases > in the past where simple and obvious timing fixes in the driver broke > display support for in tree boards, therefore I'm somewhat reluctant to > apply fixes for -rcX without Tested-by. Thanks for explanation and for applying the patches. kind regards, Ondrej > -- > Anatolij
Re: [PATCH 1/5] imx: imx8mm-beacon: Move environment definition to env file
On Mon, Jun 12, 2023 at 11:27 AM Tom Rini wrote: > > On Mon, Jun 12, 2023 at 07:53:53AM -0500, Adam Ford wrote: > > On Sun, May 28, 2023 at 2:18 PM Adam Ford wrote: > > > > > > Instead of cluttering up a header file with a bunch of defines, > > > move the default environmental variables to a file called > > > imx8mm_beacon.env and reference it from the defconfig. > > > > > > > Stefano / Tom, > > > > Is this series OK? If so, I'll continue to do this to other Beacon > > and Logic PD boards. > > Yes, this all looked good to me, thanks! thanks adam Are you able to merge this in now that the July release is behind us? I haven't seen it get any traction. > > -- > Tom
[PATCH 2/2] rockchip: edgeble-neu6: Append eMMC into spl-boot-order
Now, edgeble-neu6 NCM IO boards support eMMC and SDMMC.
So, Update the spl-boot-order to include both.
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi | 10 ++
arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi | 10 ++
2 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
index 373f369c65..7ddfd98770 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
@@ -7,16 +7,10 @@
/ {
aliases {
- mmc0 = &sdmmc;
+ mmc1 = &sdmmc;
};
chosen {
- stdout-path = &uart2;
- u-boot,spl-boot-order = &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
};
};
-
-&sdmmc {
- bus-width = <4>;
- status = "okay";
-};
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
index cd7626b24b..2bc1a98ff8 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
@@ -7,16 +7,10 @@
/ {
aliases {
- mmc0 = &sdmmc;
+ mmc1 = &sdmmc;
};
chosen {
- stdout-path = &uart2;
- u-boot,spl-boot-order = &sdmmc;
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
};
};
-
-&sdmmc {
- bus-width = <4>;
- status = "okay";
-};
--
2.25.1
[PATCH 1/2] arm64: dts: rockchip: Sync DT from linux-next
Sync the linux-next from below commit,
commit <1642bf66e270> ("arm64: dts: rockchip: add USB2 to
rk3588s-rock5a")
Also rops the duplicate usb nodes from rk3588s-u-boot.dtsi
Signed-off-by: Jagan Teki
---
arch/arm/dts/rk3588-edgeble-neu6a.dtsi | 1 -
arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 66 +++
arch/arm/dts/rk3588-edgeble-neu6b.dtsi | 359 ++-
arch/arm/dts/rk3588-evb1-v10.dts | 720 ++-
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 13 -
arch/arm/dts/rk3588-rock-5b.dts | 578 +-
arch/arm/dts/rk3588.dtsi | 112
arch/arm/dts/rk3588s-u-boot.dtsi | 119
arch/arm/dts/rk3588s.dtsi| 499 +++-
include/dt-bindings/ata/ahci.h | 20 +
10 files changed, 2346 insertions(+), 141 deletions(-)
create mode 100644 include/dt-bindings/ata/ahci.h
diff --git a/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
index 38e1a1e25f..727580aaa1 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
@@ -25,7 +25,6 @@
no-sdio;
no-sd;
non-removable;
- max-frequency = <2>;
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
status = "okay";
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
b/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
index e9d5a8bab5..9933765e40 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
+++ b/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
@@ -21,7 +21,73 @@
};
};
+&combphy0_ps {
+ status = "okay";
+};
+
+&i2c6 {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ interrupt-parent = <&gpio0>;
+ interrupts = ;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hym8563_int>;
+ wakeup-source;
+ };
+};
+
+&pinctrl {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+/* FAN */
+&pwm2 {
+ pinctrl-0 = <&pwm2m1_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&sata0 {
+ status = "okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ no-sdio;
+ no-mmc;
+ sd-uhs-sdr104;
+ vmmc-supply = <&vcc_3v3_s3>;
+ vqmmc-supply = <&vccio_sd_s0>;
+ status = "okay";
+};
+
&uart2 {
pinctrl-0 = <&uart2m0_xfer>;
status = "okay";
};
+
+/* RS232 */
+&uart6 {
+ pinctrl-0 = <&uart6m0_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* RS485 */
+&uart7 {
+ pinctrl-0 = <&uart7m2_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
index 1c5bcf1280..017559bba3 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
@@ -18,6 +18,42 @@
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <&vcc12v_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&cpu_l0 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l1 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+ cpu-supply = <&vdd_cpu_lit_s0>;
};
&sdhci {
@@ -25,8 +61,329 @@
no-sdio;
no-sd;
non-removable;
- max-frequency = <2>;
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
status = "okay";
};
+
+&spi2 {
+ status = "okay";
+ assigned-clocks = <&cru CLK_SPI2>;
+ assigned-clock-rates = <2>;
+ num-cs = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2m2_cs0 &spi2m2_pins>;
+
+ pmic@0 {
+ compatible = "rockchip,rk806";
+ spi-max-frequency = <100>;
+ reg = <0x0>;
+ interrupt-parent = <&gpio0>;
+ interrup
Re: [PATCH] video: rockchip: Add support for RK3399 to dw-mipi-dsi bridge
On Thu, 25 May 2023 14:29:03 +0200 Ondřej Jirman m...@xff.cz wrote: > From: Ondrej Jirman > > This just needs some extra clocks enabled, and different registers > configured. Copied from Linux, just like the original submitter > of this driver did for rk3568. > > Tested on Pinephone Pro. > > Signed-off-by: Ondrej Jirman > Cc: Anatolij Gustschin > Cc: Simon Glass > Cc: Philipp Tomsich > Cc: Kever Yang > Cc: Chris Morgan > --- > drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 99 +++ > 1 file changed, 99 insertions(+) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
On 2023/7/17 23:12, Tom Rini wrote: On Mon, Jul 17, 2023 at 01:27:39PM +0800, Gao Xiang wrote: Hi Tom, On 2023/7/7 23:52, Yifan Zhao wrote: This patch updates erofs driver code to catch up with the latest code of erofs_utils (commit e4939f9eaa177e05d697ace85d8dc283e25dc2ed). LZMA will be supported in the separate patch later. Signed-off-by: Yifan Zhao --- CI result here: https://github.com/u-boot/u-boot/pull/344 Could you consider this patch for this merge window? LZMA support needs further work, we will address it separately. Yes, but I'm waiting a little bit longer for anyone else to provide feedback, thanks. Thank you! glad to hear that. :-) Thanks, Gao Xiang
Re: [PATCH 0/8] Some fixes for the rockchip dw_mipi_dsi driver
On Mon, 22 May 2023 23:47:00 +0200 m...@xff.cz m...@xff.cz wrote: ... > Ondrej Jirman (8): > video: rockchip: vop: Fix whitespace > video: dw_mipi_dsi: Fix hsync/vsync settings > video: rockchip: dw_mipi_dsi: Fix external phy existnece check > video: rockchip: dw_mipi_dsi: Fix error path checks in probe function > video: rockchip: dw_mipi_dsi: Return 0 from dsi_phy_init on success > video: rockchip: dw_mipi_dsi: Fix best_rate calculation > video: rockchip: dw_mipi_dsi: Correct check for lacking phy phandle > video: rockchip: dw_mipi_dsi: Fix GRF access > > drivers/video/dw_mipi_dsi.c | 4 +- > drivers/video/rockchip/dw_mipi_dsi_rockchip.c | 38 +++ > drivers/video/rockchip/rk_vop.c | 2 +- > 3 files changed, 25 insertions(+), 19 deletions(- Series applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] video: console: Fix default font selection
On Thu, 25 May 2023 14:17:15 +0200 Ondřej Jirman m...@xff.cz wrote: > From: Ondrej Jirman > > Some callers expect to call this with NULL font name to select the > default font (eg. boot/scene.c). Without handling the NULL condition > U-Boot crashes instead of displaying a bootflow GUI menu. > > Signed-off-by: Ondrej Jirman > Cc: Anatolij Gustschin > --- > drivers/video/console_core.c | 6 ++ > 1 file changed, 6 insertions(+) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] video: hx8394: Add panel driver for hannstar,hsd060bhw4
On Thu, 25 May 2023 14:34:35 +0200 Ondřej Jirman m...@xff.cz wrote: > From: Ondrej Jirman > > The driver is for panels based on the Himax HX8394 controller, such as the > HannStar HSD060BHW4 720x1440 TFT LCD panel that uses a MIPI-DSI interface. > This panel is used in Pinephone Pro. > > Signed-off-by: Ondrej Jirman > Cc: Anatolij Gustschin > --- > drivers/video/Kconfig| 8 ++ > drivers/video/Makefile | 1 + > drivers/video/himax-hx8394.c | 237 +++ > 3 files changed, 246 insertions(+) > create mode 100644 drivers/video/himax-hx8394.c applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] video: backlight: pwm: avoid integer overflow in duty cycle calculation
On Fri, 30 Jun 2023 14:30:07 +0200 Matthias Schiffer matthias.schif...@ew.tq-group.com wrote: > The intermediate value could overflow for large periods and levels. > > Signed-off-by: Matthias Schiffer > --- applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH] fs/erofs: Introduce new features including ztailpacking, fragments and dedupe
On Mon, Jul 17, 2023 at 01:27:39PM +0800, Gao Xiang wrote: > Hi Tom, > > On 2023/7/7 23:52, Yifan Zhao wrote: > > This patch updates erofs driver code to catch up with the latest code of > > erofs_utils (commit e4939f9eaa177e05d697ace85d8dc283e25dc2ed). > > > > LZMA will be supported in the separate patch later. > > > > Signed-off-by: Yifan Zhao > > --- > > CI result here: > > https://github.com/u-boot/u-boot/pull/344 > > Could you consider this patch for this merge window? > LZMA support needs further work, we will address it separately. Yes, but I'm waiting a little bit longer for anyone else to provide feedback, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 0/4] SPL NVMe support
On Mon, Jul 17, 2023 at 01:39:52PM +0530, mchit...@ventanamicro.com wrote:
> On Wed, 2023-07-12 at 13:12 -0400, Tom Rini wrote:
> > On Wed, Jul 12, 2023 at 03:27:45PM +0200, Heinrich Schuchardt wrote:
> > > On 12.07.23 15:06, mchit...@ventanamicro.com wrote:
> > > > Hi Tom,
> > > >
> > > > On Tue, 2023-06-20 at 09:37 -0400, Tom Rini wrote:
> > > > > On Sat, 03 Jun 2023 19:32:52 +0530, Mayuresh Chitale wrote:
> > > > >
> > > > > > This patchset adds support to load images of the SPL's next
> > > > > > booting
> > > > > > stage from a NVMe device.
> > > > > >
> > > > > > Changes in v4:
> > > > > > - Drop patch 4
> > > > > > - Modify patch 2 to use generic fs.h APIs
> > > > > >
> > > > > > [...]
> > > > >
> > > > > With one change, which is that the "disk/part.c" in 4/4 were
> > > > > not
> > > > > required for
> > > > > any platform in tree and also broke testcases, and so was
> > > > > dropped,
> > > > > this has now
> > > > > been applied to u-boot/next. If you can explain a bit more what
> > > > > the
> > > > > problem you
> > > > > had was, we can look in to it. I suspect you need to test for
> > > > > not
> > > > > SPL_ENV_SUPPORT but ENV_SUPPORT itself.
> > > > >
> > > > Thanks.
> > > > When SPL_NVME is enabled the build breaks with the following
> > > > error:
> > > > riscv64-unknown-linux-gnu-ld.bfd: disk/part.o: in function
> > > > `blk_get_device_part_str':
> > > > u-boot/disk/part.c:473: undefined reference to `env_get'
> > > > make[2]: *** [u-boot/scripts/Makefile.spl:527: spl/u-boot-spl]
> > > > Error 1
> > > > make[1]: *** [/u-boot/Makefile:2053: spl/u-boot-spl] Error 2
> > > >
> > > > One possible fix is:
> > > >
> > > > if ((!IS_ENABLED(CONFIG_SPL) && IS_ENABLED(CONFIG_ENV_SUPPORT))
> > > > ||
> > > > (IS_ENABLED(CONFIG_SPL) &&
> > > > IS_ENABLED(CONFIG_SPL_ENV_SUPPORT)))
> > > > if (!dev_part_str || !strlen(dev_part_str)
> > > > > > !strcmp(dev_part_str, "-"))
> > > > dev_part_str = env_get("bootdevice");
> > > >
> > > >
> > >
> > > I think CONFIG_SPL_ENV_SUPPORT should depend on CONFIG_ENV_SUPPORT
> > > in
> > > common/spl/Kconfig.
> >
> > Not strictly, but checking for CONFIG_IS_ENABLED(ENV_SUPPORT) should
> > do
> > what's desired here?
>
> When SPL_NVME & SPL_BLK_FS is enabled, the spl_blk_fs driver calls
> fs_set_blk_dev to the set the device & partition before accessing it
> and fs_set_blk_dev internally tries to get the device & partition from
> the bootdevice env variable if it was not passed by the caller. However
> for SPL build, when SPL_ENV_SUPPORT is not enabled nothing provides
> env_get and hence the build fails.
OK. So in the code we should be able to test with
CONFIG_IS_ENABLED(ENV_SUPPORT) is that will be true for ((SPL and
SPL environment support) or (Main U-Boot and environment support) or
(TPL and TPL env)).
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 12/18] include: armv7: Enable distroboot across all configs
On July 17, 2023 thus sayeth Nishanth Menon: > On 13:39-20230717, Manorit Chawdhry wrote: > > [...] > > > > > + > > > > +#define BOOT_TARGET_DEVICES(func) \ > > > > + BOOT_TARGET_MMC(func) \ > > > > + BOOT_TARGET_USB(func) \ > > > > + BOOT_TARGET_PXE(func) \ > > > > + BOOT_TARGET_DHCP(func) > > > > + > > > > +#include > > > > > > With standard boot you should be able to drop all of the above, since > > > the normal order is mmc, usb, pxe, dhcp by default. But you can add a > > > "boot_targets" env var if you like. > > > > > > The one exception is TI_MMC. What is that, exactly? > > > > > > > TI_MMC is our custom boot mechanism that we actually support as a part > > of our SDK, we had been using this in am62ax like the way I have done > > here, am not really sure why we hooked it into the distroboot if that is > > the question that you are asking, maybe Nishanth/Bryan can help with > > that as Bryan had done it for am62ax [0] but we do this boot mechanism > > for sure. > > > > [0]: https://lore.kernel.org/u-boot/20221224011525.4696-5...@ti.com/ > > > > 2 cents: > There is no reason for us to have our own TI_MMC option. we should just > go standard_boot. all the SDK stuff really should be fixed if they dont > work with standard_boot. > I Agree. I put that in with the hopes we could just add a CFG_* or CONFIG_* option to compile our scripts out once we have everything in the SDK ready. But I agree with Nishanth, we should be looking at standard_boot now. ~Bryan
Re: Please pull u-boot-video
On Sun, Jul 16, 2023 at 10:04:36PM +0200, Anatolij Gustschin wrote: > Hi Tom, > > please pull new video patches for v2023.10. > > CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/16923 > > Thanks, > Anatolij > > The following changes since commit 8e21064cb3452950b09301baec06d86e37342471: > > Merge tag 'efi-2023-07-rc7' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-07-11 13:27:32 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-video.git > tags/video-20230714 > > for you to fetch changes up to bd6375c5511c3b96ce91ea66084d27afe2bbc43b: > > video: rockchip: dw_mipi_dsi: Fix GRF access (2023-07-14 18:30:58 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request efi-2023-10-rc1
On Sat, Jul 15, 2023 at 12:29:00PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit b3bbad816e97538c8c3b8acad7c7e134261cf3a3: > > Merge branch '2023-07-14-expo-initial-config-editor' (2023-07-14 > 13:26:42 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2023-10-rc1 > > for you to fetch changes up to 345a8b15acf228c4a429f6569c34cbc0232e76eb: > > doc: uefi: enhance anti-rollback documentation (2023-07-15 11:20:41 > +0200) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/16909 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v7 00/23] Migration to using binman for bootloader
On Mon, Jul 17, 2023 at 06:38:22PM +0530, Neha Malcom Francis wrote: > Hi Maxime > > On 17/07/23 18:19, Maxime Ripard wrote: > > Hi, > > > > On Fri, Jul 14, 2023 at 07:20:47PM +0530, Neha Malcom Francis wrote: > > > This series aims to eliminate the use of additional custom repositories > > > such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 > > > Security Development Tools) that was plumbed into the U-Boot build flow > > > to generate boot images for TI K3 platform devices. And instead, we move > > > towards using binman that aligns better with the community standard build > > > flow. > > > > > > This series uses binman for all K3 platforms supported on U-Boot > > > currently; > > > both HS (High Security, both SE and FS) and GP (General Purpose) devices. > > > > > > Background on using k3-image-gen: > > > * TI K3 devices require a SYSFW (System Firmware) image consisting > > > of a signed system firmware image and board configuration binaries, > > > this is needed to bring up system firmware during U-Boot R5 SPL > > > startup. > > > * Board configuration data contain board-specific information > > > such as resource management, power management and security. > > > > > > Background on using core-secdev-k3: > > > * Contains resources to sign x509 certificates for HS devices > > > > > > Series intends to use binman to take over the packaging and signing for > > > the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined > > > boot flow) instead of k3-image-gen. > > > > > > Series also packages the A72/A53 bootloader images (tispl.bin and > > > u-boot.img) using ATF, OPTEE and DM (Device Manager) > > > > Tested-by: Maxime Ripard > > > > Thanks for testing! > > > It took a while to figure out that the tiboot3.bin file was for the > > HS-FS variant now, while I was using a GP board. > > Depends on the board, based on the commonly available boards tiboot3.bin is > symlinked to either GP or HS-FS. Sure, I guess that my point was that prior to your patches we would specify the firmware that match our board and thus tiboot3.bin was always the right one. Now, it can be the wrong one and we have, most likely, to use the proper image instead of following the symlink. But the doc still says we should pick the symlink. > > Maybe we should clarify that in the doc? > > But yes, I will factor this into the docs. Thanks :) Maxime signature.asc Description: PGP signature
Re: [PATCH v7 00/23] Migration to using binman for bootloader
Hi, On Fri, Jul 14, 2023 at 07:20:47PM +0530, Neha Malcom Francis wrote: > This series aims to eliminate the use of additional custom repositories > such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 > Security Development Tools) that was plumbed into the U-Boot build flow > to generate boot images for TI K3 platform devices. And instead, we move > towards using binman that aligns better with the community standard build > flow. > > This series uses binman for all K3 platforms supported on U-Boot currently; > both HS (High Security, both SE and FS) and GP (General Purpose) devices. > > Background on using k3-image-gen: > * TI K3 devices require a SYSFW (System Firmware) image consisting > of a signed system firmware image and board configuration binaries, > this is needed to bring up system firmware during U-Boot R5 SPL > startup. > * Board configuration data contain board-specific information > such as resource management, power management and security. > > Background on using core-secdev-k3: > * Contains resources to sign x509 certificates for HS devices > > Series intends to use binman to take over the packaging and signing for > the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined > boot flow) instead of k3-image-gen. > > Series also packages the A72/A53 bootloader images (tispl.bin and > u-boot.img) using ATF, OPTEE and DM (Device Manager) Tested-by: Maxime Ripard It took a while to figure out that the tiboot3.bin file was for the HS-FS variant now, while I was using a GP board. Maybe we should clarify that in the doc? Maxime signature.asc Description: PGP signature
Re: [RFC PATCH 0/4] arm: dts: Sync k3-am62 with upstream
Hi, On Thu, Jul 13, 2023 at 02:20:15AM -0500, Nishanth Menon wrote: > This series depends on Neha's binman series[1] and is intended for > review and I will repost once binman series is merged in. > > I have picked up part of Sjoerd's series[2] to keep it constrained just > to dts sync at this point rather than adding newer functionality on top. > > You can find the full series in [3]. > > Attempting am625 as a start of a series of clean ups for device tree for > u-boot, but will love to get any review comments to improve this series > up. Tested-by: Maxime Ripard This also fixes an MMC issue when booting Linux with the U-Boot device tree. Maxime signature.asc Description: PGP signature
Re: [PATCH 12/18] include: armv7: Enable distroboot across all configs
On 13:39-20230717, Manorit Chawdhry wrote: [...] > > > + > > > +#define BOOT_TARGET_DEVICES(func) \ > > > + BOOT_TARGET_MMC(func) \ > > > + BOOT_TARGET_USB(func) \ > > > + BOOT_TARGET_PXE(func) \ > > > + BOOT_TARGET_DHCP(func) > > > + > > > +#include > > > > With standard boot you should be able to drop all of the above, since > > the normal order is mmc, usb, pxe, dhcp by default. But you can add a > > "boot_targets" env var if you like. > > > > The one exception is TI_MMC. What is that, exactly? > > > > TI_MMC is our custom boot mechanism that we actually support as a part > of our SDK, we had been using this in am62ax like the way I have done > here, am not really sure why we hooked it into the distroboot if that is > the question that you are asking, maybe Nishanth/Bryan can help with > that as Bryan had done it for am62ax [0] but we do this boot mechanism > for sure. > > [0]: https://lore.kernel.org/u-boot/20221224011525.4696-5...@ti.com/ > 2 cents: There is no reason for us to have our own TI_MMC option. we should just go standard_boot. all the SDK stuff really should be fixed if they dont work with standard_boot. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v1 4/5] rockchip: evb_rk3229: Update/fix README
On 7/16/23 10:10, Alex Bee wrote: > This updates the evb_rk3229's README on howto create / use the FIT image > created by binman. > Also fix some wrong paths and update filenames which have changed in recent > upstream optee-os versions. > > Signed-off-by: Alex Bee > --- > board/rockchip/evb_rk3229/README | 72 +--- > 1 file changed, 48 insertions(+), 24 deletions(-) > > diff --git a/board/rockchip/evb_rk3229/README > b/board/rockchip/evb_rk3229/README > index 9068225e27..e4c88bac06 100644 > --- a/board/rockchip/evb_rk3229/README > +++ b/board/rockchip/evb_rk3229/README > @@ -13,25 +13,23 @@ Compile the OP-TEE > >> cd optee_os >> make clean > - > make CROSS_COMPILE_ta_arm32=arm-none-eabi- PLATFORM=rockchip-rk322x > - Get tee.bin in this step, copy it to U-Boot root dir: > - > cp out/arm-plat-rockchip/core/tee-pager.bin ../u-boot/tee.bin > + > make CROSS_COMPILE=arm-none-eabi- PLATFORM=rockchip-rk322x > + Get tee-pager_v2.bin in this step, copy it to U-Boot root dir: > + > cp out/arm-plat-rockchip/core/tee-pager_v2.bin ../u-boot/tee.bin Since OP-TEE 3.21.0, there is a tee-raw.bin file. I recommend using it instead of tee-pager_v2.bin. Technically they are identical when the OP-TEE "pager" feature is disabled, but the name makes more sense. -- Jerome
Re: [PATCH v7 05/23] j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
On 13:21-20230717, Neha Malcom Francis wrote: > Hi Nishanth > > On 17/07/23 11:41, Neha Malcom Francis wrote: > > Hi Nishanth, > > > > On 15/07/23 12:00, Neha Malcom Francis wrote: > > > Hi Nishanth > > > > > > On 15/07/23 11:44, Nishanth Menon wrote: > > > > On 19:20-20230714, Neha Malcom Francis wrote: > > > > > > > > Since you are going to respin anyways, I will complain about this: > > > > > > > > > +#ifdef CONFIG_TARGET_J721E_A72_EVM > > > > > + > > > > > +#define SPL_NODTB "spl/u-boot-spl-nodtb.bin" > > > > > +#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb" > > > > > +#define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb" > > > > > + > > > > > +#define UBOOT_NODTB "u-boot-nodtb.bin" > > > > > +#define J721E_EVM_DTB "arch/arm/dts/k3-j721e-common-proc-board.dtb" > > > > > +#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb" > > > > > + > > > > > > > > I was trying to add beaglebone-ai64 support and discovered that this > > > > messes the reuse of j721e-binman.dtsi for ai64. I am forced to introduce > > > > j721e-sk.dtb - so why not just use SPL_NODTB SPL_J721E_BOARD_DTB, > > > > UBOOT_NODTB J721E_EVM_BOARD_DTB (generic names) and drop the specific sk > > > > stuff? And define the macros in the board.dtsi prior to including the > > > > files? > > > > > > > I can do that, yes. Thanks for catching this. > > > > > > > I'd like to just bring up that this would mean that the same A72 build > > and binaries will no longer work for both EVM and SK, rather will have > > to modify the CONFIG_DEFAULT_DEVICE_TREE for each. I am okay with this, > > but just putting it out there. > > > > An even better way would be to use the binman substitutions feature in FIT > [1] to resolve both the beaglebone-ai64 not needing to have j721e-sk.dtb as > well as continue having the same defconfig build supporting both J721E EVM > as well as SK. I will work on this approach first. > > [1] > https://u-boot.readthedocs.io/en/latest/develop/package/entries.html#substitutions > Thanks for pointing this out - will follow your lead once the new rev is posted and will try to add beagles behind the same. -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[PATCH v3] fpga: add inline stub for fpga_load
In case CC_OPTIMIZE_FOR_DEBUG is set, unused code will not be optimized out,
hence the reference to fpga_load will be compiled.
if DM_FPGA and SPL_FPGA are not set, the build will fail with :
aarch64-none-linux-gnu-ld.bfd: common/spl/spl_fit.o: in function
`spl_fit_upload_fpga':
u-boot/common/spl/spl_fit.c:595: undefined reference to `fpga_load'
To solve this, added an inline empty stub in the header if
CC_OPTIMIZE_FOR_DEBUG is set such that the build will succeed.
Signed-off-by: Eugen Hristev
---
Changes in v3:
- return -ENOSYS
Changes in v2:
- this is a rework as suggested by Simon of this previous patch :
https://patchwork.ozlabs.org/project/uboot/patch/20230619102839.277902-1-eugen.hris...@collabora.com/
include/fpga.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/fpga.h b/include/fpga.h
index ed688cc0fa3b..33d0dbbe2ba4 100644
--- a/include/fpga.h
+++ b/include/fpga.h
@@ -60,8 +60,17 @@ int fpga_add(fpga_type devtype, void *desc);
int fpga_count(void);
const fpga_desc *const fpga_get_desc(int devnum);
int fpga_is_partial_data(int devnum, size_t img_len);
+#if defined(CONFIG_CC_OPTIMIZE_FOR_DEBUG)
+static inline int fpga_load(int devnum, const void *buf, size_t bsize,
+ bitstream_type bstype, int flags)
+{
+ return -ENOSYS;
+}
+#else
int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype, int flags);
+#endif
+
int fpga_fsload(int devnum, const void *buf, size_t size,
fpga_fs_info *fpga_fsinfo);
int fpga_loads(int devnum, const void *buf, size_t size,
--
2.34.1
Re: [PATCH v7 00/23] Migration to using binman for bootloader
Hi Maxime On 17/07/23 18:19, Maxime Ripard wrote: Hi, On Fri, Jul 14, 2023 at 07:20:47PM +0530, Neha Malcom Francis wrote: This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) Tested-by: Maxime Ripard Thanks for testing! It took a while to figure out that the tiboot3.bin file was for the HS-FS variant now, while I was using a GP board. Depends on the board, based on the commonly available boards tiboot3.bin is symlinked to either GP or HS-FS. Maybe we should clarify that in the doc? But yes, I will factor this into the docs. Maxime -- Thanking You Neha Malcom Francis
Please pull u-boot-x86
Hi Tom, This PR includes the following x86 related changes for v2023.10 release: - bootstd: Add a bootmeth for ChromiumOS on x86 - x86: Use qemu-x86_64 to boot EFI installers Azure results: PASS https://dev.azure.com/bmeng/GitHub/_build/results?buildId=494&view=results The following changes since commit e6e67bb9e0a40f3eb3c87d16935192821987c3e0: Merge branch '2023-07-14-assorted-general-updates' (2023-07-14 15:21:48 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86 for you to fetch changes up to b8956425d525c3c25fd218f252f89a5e44df6a9f: x86: Switch QEMU over to use the bochs driver (2023-07-17 17:23:15 +0800) Simon Glass (60): test: Skip flat-tree tests if devicetree is not used bootstd: Correct the name of the QEMU bootmeth bootstd: Use bootdev instead of bootdevice bootstd: Correct baudrate typo bootstd: Allow storing the OS command line in the bootflow bootstd: Use the bootargs env var for changing the cmdline bootstd: Allow storing x86 setup information bdinfo: Show information about the serial port bootstd: Add a function to update a command line bootstd: Add support for updating elements of the cmdline x86: qemu: Create a little more room for U-Boot x86: qemu: Switch to standard boot bootstd: Support automatically setting Linux parameters x86: Add a function to boot a zimage x86: zimage: Export the function to obtain the cmdline bootstd: Add a simple bootmeth for ChromiumOS x86: coreboot: Adjust various config options x86: coral: Adjust various config options x86: Allow listing MTRRs in SPL x86: mtrr: Add documentation bios_emulator: Add Kconfig and adjust Makefile for SPL bios_emulator: Drop VIDEO_IO_OFFSET x86: Tidy up EFI code in interrupt_init() x86: Add a comment for board_init_f_r_trampoline() x86: Show the CPU physical address size with bdinfo x86: Correct get_sp() implementation for 64-bit x86: Show an error when a BIOS exception occurs acpi: Add a comment to set the acpi tables bdinfo: Show the RAM top and approximate stack pointer part: Allow setting the partition-table type qfw: Show the file address if available log: Tidy up an ambiguous comment qfw: Set the address of the ACPI tables efi: Show all known UUIDs with CONFIG_CMD_EFIDEBUG x86: Improve the trampoline in 64-bit mode bdinfo: Show the malloc base with the bdinfo command nvme: Provide more useful debugging messages pci: Support autoconfig in SPL pci: Tidy up logging and reporting for video BIOS x86: Allow video-BIOS code to be built for SPL x86: Pass video settings from SPL to U-Boot proper x86: Ensure SPL banner is only shown once x86: Init video in SPL if enabled pci: Adjust video BIOS debugging to be SPL-friendly pci: Mask the ROM address in case it is already enabled x86: Enable display for QEMU 64-bit x86: Allow logging to be used in SPL reliably fs: fat: Shrink the size of a few strings x86: Enable useful options for qemu-86_64 x86: Refactor table-writing code a little x86: Record the start and end of the tables x86: Convert some debug statements to use logging x86: link: Support Micron memory x86: Make sure that the LPC is active before SDRAM init log: Support outputing function names in SPL sandbox: Correct header order in board file sandbox: Install ACPI tables on startup efi: Use the installed ACPI tables x86: video: Add a driver for QEMU bochs emulation x86: Switch QEMU over to use the bochs driver arch/sandbox/include/asm/global_data.h| 4 ++ arch/x86/cpu/i386/interrupt.c | 17 +++- arch/x86/cpu/intel_common/mrc.c | 10 ++--- arch/x86/cpu/ivybridge/sdram.c| 4 +- arch/x86/cpu/mtrr.c | 61 + arch/x86/cpu/qemu/Kconfig | 2 +- arch/x86/cpu/start64.S| 19 + arch/x86/dts/chromebook_link.dts | 1 + arch/x86/include/asm/global_data.h| 4 ++ arch/x86/include/asm/mtrr.h | 20 ++ arch/x86/include/asm/u-boot-x86.h | 27 - arch/x86/include/asm/zimage.h | 27 + arch/x86/lib/Makefile | 7 ++-- arch/x86/lib/bdinfo.c | 5 +++ arch/x86/lib/bios.c | 4 +- arch/x86/lib/bootm.c | 2 +- arch/x86/lib/mrccache.c | 6 ++- arch/x86/lib/spl.c| 68 +++- arch/x86/lib/tables.c | 46 +++--- arch/x86/lib/zimage.c | 93
Re: [PATCH v3 4/6] sysinfo: Add documentation
On Friday, July 14, 2023 1:31:00 P.M. EDT Marek Vasut wrote: > On 7/14/23 18:43, Detlev Casanova wrote: > > [...] > > > +Return value > > + > > + > > +The return value $? is set to 0 (true) if the command succededd > > succeeded -- typo > > . If an > > > +error occurs, the return value $? is set to 1 (false). > > With that fixed: > > Reviewed-by: Marek Vasut Do you need me to make a patch v4 to fix this ?
[PATCH v2 4/4] usb: gadget: ether: Handle gadget driver registration in probe and remove
Move the ethernet gadget driver registration and removal from ethernet
bind and unbind callbacks into driver DM probe and remove callbacks.
This way, when the driver is bound, which is triggered deliberately
using 'bind' command, the USB ethernet gadget driver is instantiated
and bound to the matching UDC. In reverse, when the driver is unbound,
which is again triggered deliberately using 'unbind' command, the USB
ethernet gadget driver instance is removed.
Effectively, this now behaves like running either 'ums' or 'dfu' or
any other commands utilizing USB gadget functionality.
This also drops use of usb_gadget_initialize()/usb_gadget_release(),
which are helper functions implemented in the UDC uclass to bind and
unbind UDC drivers to controllers from U-Boot command line. Those have
no place in drivers.
Signed-off-by: Marek Vasut
---
NOTE: This must be thoroughly tested.
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
V2: Fix up return value handling in probe
---
drivers/usb/gadget/ether.c | 87 +++---
1 file changed, 43 insertions(+), 44 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 2040b5b5081..9e1a45ad9df 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2281,49 +2281,8 @@ static int usb_eth_start(struct udevice *udev)
struct eth_dev *dev = &priv->ethdev;
struct usb_gadget *gadget;
unsigned long ts;
- int ret;
unsigned long timeout = USB_CONNECT_TIMEOUT;
- ret = usb_gadget_initialize(0);
- if (ret)
- return ret;
-
- /* Configure default mac-addresses for the USB ethernet device */
-#ifdef CONFIG_USBNET_DEV_ADDR
- strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
-#endif
-#ifdef CONFIG_USBNET_HOST_ADDR
- strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
-#endif
- /* Check if the user overruled the MAC addresses */
- if (env_get("usbnet_devaddr"))
- strlcpy(dev_addr, env_get("usbnet_devaddr"),
- sizeof(dev_addr));
-
- if (env_get("usbnet_hostaddr"))
- strlcpy(host_addr, env_get("usbnet_hostaddr"),
- sizeof(host_addr));
-
- if (!is_eth_addr_valid(dev_addr)) {
- pr_err("Need valid 'usbnet_devaddr' to be set");
- goto fail;
- }
- if (!is_eth_addr_valid(host_addr)) {
- pr_err("Need valid 'usbnet_hostaddr' to be set");
- goto fail;
- }
-
- priv->eth_driver.speed = DEVSPEED;
- priv->eth_driver.bind = eth_bind;
- priv->eth_driver.unbind = eth_unbind;
- priv->eth_driver.setup = eth_setup;
- priv->eth_driver.reset = eth_disconnect;
- priv->eth_driver.disconnect = eth_disconnect;
- priv->eth_driver.suspend= eth_suspend;
- priv->eth_driver.resume = eth_resume;
- if (usb_gadget_register_driver(&priv->eth_driver) < 0)
- goto fail;
-
dev->network_started = 0;
packet_received = 0;
@@ -2450,9 +2409,6 @@ static void usb_eth_stop(struct udevice *udev)
usb_gadget_handle_interrupts(0);
dev->network_started = 0;
}
-
- usb_gadget_unregister_driver(&priv->eth_driver);
- usb_gadget_release(0);
}
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
@@ -2525,6 +2481,48 @@ static int usb_eth_probe(struct udevice *dev)
get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+ /* Configure default mac-addresses for the USB ethernet device */
+#ifdef CONFIG_USBNET_DEV_ADDR
+ strlcpy(dev_addr, CONFIG_USBNET_DEV_ADDR, sizeof(dev_addr));
+#endif
+#ifdef CONFIG_USBNET_HOST_ADDR
+ strlcpy(host_addr, CONFIG_USBNET_HOST_ADDR, sizeof(host_addr));
+#endif
+ /* Check if the user overruled the MAC addresses */
+ if (env_get("usbnet_devaddr"))
+ strlcpy(dev_addr, env_get("usbnet_devaddr"),
+ sizeof(dev_addr));
+
+ if (env_get("usbnet_hostaddr"))
+ strlcpy(host_addr, env_get("usbnet_hostaddr"),
+ sizeof(host_addr));
+
+ if (!is_eth_addr_valid(dev_addr)) {
+ pr_err("Need valid 'usbnet_devaddr' to be set");
+ return -EINVAL;
+ }
+ if (!is_eth_addr_valid(host_addr)) {
+ pr_err("Need valid 'usbnet_hostaddr' to be set");
+ return -EINVAL;
+ }
+
+ priv->eth_driver.speed = DEVSPEED;
+ priv->eth_driver.bind = eth_bind;
+ priv->eth_driver.unbind = eth_unbind;
+ priv->eth_driver.setup = eth_setup;
+ priv->eth_driver.reset = eth_disconnect;
+ priv->eth_driver.disconnect = eth_discon
[PATCH v2 3/4] usb: gadget: ether: Move probe function above driver structure
Move the driver probe function above the driver structure, so it
can be placed alongside other related functions, like upcoming
remove function. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
V2: No change
---
drivers/usb/gadget/ether.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 88c656c4dc0..2040b5b5081 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2486,20 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static int usb_eth_probe(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
- struct eth_pdata *pdata = dev_get_plat(dev);
-
- priv->netdev = dev;
- l_priv = priv;
-
- get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
- eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
-
- return 0;
-}
-
static const struct eth_ops usb_eth_ops = {
.start = usb_eth_start,
.send = usb_eth_send,
@@ -2528,6 +2514,20 @@ int usb_ether_init(void)
return 0;
}
+static int usb_eth_probe(struct udevice *dev)
+{
+ struct ether_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *pdata = dev_get_plat(dev);
+
+ priv->netdev = dev;
+ l_priv = priv;
+
+ get_ether_addr(CONFIG_USBNET_DEV_ADDR, pdata->enetaddr);
+ eth_env_set_enetaddr("usbnet_devaddr", pdata->enetaddr);
+
+ return 0;
+}
+
U_BOOT_DRIVER(eth_usb) = {
.name = "usb_ether",
.id = UCLASS_ETH,
--
2.40.1
[PATCH v2 2/4] usb: gadget: ether: Inline functions used once
These functions here are only ever called once since drop of non-DM
networking code. Inline them. No functional change.
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
V2: No change
---
drivers/usb/gadget/ether.c | 48 +++---
1 file changed, 9 insertions(+), 39 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 85c971e4c43..88c656c4dc0 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -2273,10 +2273,11 @@ fail:
}
/*-*/
-static void _usb_eth_halt(struct ether_priv *priv);
+static void usb_eth_stop(struct udevice *dev);
-static int _usb_eth_init(struct ether_priv *priv)
+static int usb_eth_start(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = &priv->ethdev;
struct usb_gadget *gadget;
unsigned long ts;
@@ -2347,12 +2348,13 @@ static int _usb_eth_init(struct ether_priv *priv)
rx_submit(dev, dev->rx_req, 0);
return 0;
fail:
- _usb_eth_halt(priv);
+ usb_eth_stop(udev);
return -1;
}
-static int _usb_eth_send(struct ether_priv *priv, void *packet, int length)
+static int usb_eth_send(struct udevice *udev, void *packet, int length)
{
+ struct ether_priv *priv = dev_get_priv(udev);
int retval;
void*rndis_pkt = NULL;
struct eth_dev *dev = &priv->ethdev;
@@ -2419,15 +2421,9 @@ drop:
return -ENOMEM;
}
-static int _usb_eth_recv(struct ether_priv *priv)
-{
- usb_gadget_handle_interrupts(0);
-
- return 0;
-}
-
-static void _usb_eth_halt(struct ether_priv *priv)
+static void usb_eth_stop(struct udevice *udev)
{
+ struct ether_priv *priv = dev_get_priv(udev);
struct eth_dev *dev = &priv->ethdev;
/* If the gadget not registered, simple return */
@@ -2459,31 +2455,12 @@ static void _usb_eth_halt(struct ether_priv *priv)
usb_gadget_release(0);
}
-static int usb_eth_start(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_init(priv);
-}
-
-static int usb_eth_send(struct udevice *dev, void *packet, int length)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- return _usb_eth_send(priv, packet, length);
-}
-
static int usb_eth_recv(struct udevice *dev, int flags, uchar **packetp)
{
struct ether_priv *priv = dev_get_priv(dev);
struct eth_dev *ethdev = &priv->ethdev;
- int ret;
- ret = _usb_eth_recv(priv);
- if (ret) {
- pr_err("error packet receive\n");
- return ret;
- }
+ usb_gadget_handle_interrupts(0);
if (packet_received) {
if (ethdev->rx_req) {
@@ -2509,13 +2486,6 @@ static int usb_eth_free_pkt(struct udevice *dev, uchar
*packet,
return rx_submit(ethdev, ethdev->rx_req, 0);
}
-static void usb_eth_stop(struct udevice *dev)
-{
- struct ether_priv *priv = dev_get_priv(dev);
-
- _usb_eth_halt(priv);
-}
-
static int usb_eth_probe(struct udevice *dev)
{
struct ether_priv *priv = dev_get_priv(dev);
--
2.40.1
[PATCH v2 1/4] cmd: bind: Add unbind command with driver filter
Extend the driver core to perform lookup by both OF node and driver
bound to the node. Use this to look up specific device instances to
unbind from nodes in the unbind command. One example where this is
needed is USB peripheral controller, which may have multiple gadget
drivers bound to it. The unbind command has to select that specific
gadget driver instance to unbind from the controller, not unbind the
controller driver itself from the controller.
USB ethernet gadget usage looks as follows with this change. Notice
the extra 'usb_ether' addition in the 'unbind' command at the end.
"
bind /soc/usb-otg@4900 usb_ether
setenv ethact usb_ether
setenv loadaddr 0xc200
setenv ipaddr 10.0.0.2
setenv serverip 10.0.0.1
setenv netmask 255.255.255.0
tftpboot 0xc200 10.0.0.1:test.file
unbind /soc/usb-otg@4900 usb_ether
"
Signed-off-by: Marek Vasut
---
Cc: Kevin Hilman
Cc: Lukasz Majewski
Cc: Marek Vasut
Cc: Simon Glass
---
V2: No change
---
cmd/bind.c| 10 +-
drivers/core/device.c | 20 +++-
include/dm/device.h | 17 +
3 files changed, 37 insertions(+), 10 deletions(-)
diff --git a/cmd/bind.c b/cmd/bind.c
index 4d1b7885e60..3137cdf6cb5 100644
--- a/cmd/bind.c
+++ b/cmd/bind.c
@@ -162,7 +162,7 @@ static int bind_by_node_path(const char *path, const char
*drv_name)
return 0;
}
-static int unbind_by_node_path(const char *path)
+static int unbind_by_node_path(const char *path, const char *drv_name)
{
struct udevice *dev;
int ret;
@@ -174,7 +174,7 @@ static int unbind_by_node_path(const char *path)
return -EINVAL;
}
- ret = device_find_global_by_ofnode(ofnode, &dev);
+ ret = device_find_global_by_ofnode_driver(ofnode, drv_name, &dev);
if (!dev || ret) {
printf("Cannot find a device with path %s\n", path);
@@ -214,9 +214,9 @@ static int do_bind_unbind(struct cmd_tbl *cmdtp, int flag,
int argc,
return CMD_RET_USAGE;
ret = bind_by_node_path(argv[1], argv[2]);
} else if (by_node && !bind) {
- if (argc != 2)
+ if (argc != 2 && argc != 3)
return CMD_RET_USAGE;
- ret = unbind_by_node_path(argv[1]);
+ ret = unbind_by_node_path(argv[1], argv[2]);
} else if (!by_node && bind) {
int index = (argc > 2) ? dectoul(argv[2], NULL) : 0;
@@ -251,7 +251,7 @@ U_BOOT_CMD(
U_BOOT_CMD(
unbind, 4, 0, do_bind_unbind,
"Unbind a device from a driver",
- "\n"
+ " []\n"
"unbind \n"
"unbind \n"
);
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 6e26b64fb81..52fceb69341 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -877,15 +877,17 @@ int device_get_child_by_of_offset(const struct udevice
*parent, int node,
}
static struct udevice *_device_find_global_by_ofnode(struct udevice *parent,
-ofnode ofnode)
+ofnode ofnode,
+const char *drv)
{
struct udevice *dev, *found;
- if (ofnode_equal(dev_ofnode(parent), ofnode))
+ if (ofnode_equal(dev_ofnode(parent), ofnode) &&
+ (!drv || (drv && !strcmp(parent->driver->name, drv
return parent;
device_foreach_child(dev, parent) {
- found = _device_find_global_by_ofnode(dev, ofnode);
+ found = _device_find_global_by_ofnode(dev, ofnode, drv);
if (found)
return found;
}
@@ -895,7 +897,15 @@ static struct udevice
*_device_find_global_by_ofnode(struct udevice *parent,
int device_find_global_by_ofnode(ofnode ofnode, struct udevice **devp)
{
- *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode);
+ *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode, NULL);
+
+ return *devp ? 0 : -ENOENT;
+}
+
+int device_find_global_by_ofnode_driver(ofnode ofnode, const char *drv,
+ struct udevice **devp)
+{
+ *devp = _device_find_global_by_ofnode(gd->dm_root, ofnode, drv);
return *devp ? 0 : -ENOENT;
}
@@ -904,7 +914,7 @@ int device_get_global_by_ofnode(ofnode ofnode, struct
udevice **devp)
{
struct udevice *dev;
- dev = _device_find_global_by_ofnode(gd->dm_root, ofnode);
+ dev = _device_find_global_by_ofnode(gd->dm_root, ofnode, NULL);
return device_get_device_tail(dev, dev ? 0 : -ENOENT, devp);
}
diff --git a/include/dm/device.h b/include/dm/device.h
index b86bf90609b..5f05ae0924f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -748,6 +748,23 @@ int device_get_child_by_of_offset(const struct udevice
*parent, int of_offset,
int device_find_global_by_ofnode(ofnode node, struct udevice **devp);
Re: [PATCH v4 08/12] CI: capsule: Setup the files needed for capsule update testing
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Support has being added through earlier commits to build capsules
> > and embed the public key needed for capsule authentication as part of
> > u-boot build.
> >
> > From the testing point-of-view, this means the input files needed for
> > generating the above have to be setup before invoking the build. Set
> > this up in the CI configuration files for testing the capsule update
> > feature.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Remove whitespace in the command to generate capsule keys.
> >
> > .azure-pipelines.yml | 24
> > .gitlab-ci.yml | 22 ++
>
> Can you add this to the Dockerfile instead? It looks like this will
> run on each build.
Okay. Let me try this out.
-sughosh
>
> > 2 files changed, 46 insertions(+)
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index 06c46b681c..d732ba443d 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -398,6 +398,17 @@ stages:
> >wget -O -
> > https://github.com/riscv-software-src/opensbi/releases/download/v1.2/opensbi-1.2-rv-bin.tar.xz
> > | tar -C /tmp -xJ;
> >export
> > OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
> >fi
> > + mkdir -p /tmp/capsules/;
> > + echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
> > + echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > + echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > + echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > + cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
> > /tmp/capsules/SIGNER.esl;
> > + fi
> > +
> ># the below corresponds to .gitlab-ci.yml "script"
> >cd ${WORK_DIR}
> >export UBOOT_TRAVIS_BUILD_DIR=/tmp/${TEST_PY_BD};
> > @@ -582,6 +593,19 @@ stages:
> >cd ${WORK_DIR}
> ># make environment variables available as tests are running
> > inside a container
> >export BUILDMAN="${BUILDMAN}"
> > + if [[ "${BUILDMAN}" == "sandbox" ]] || [[ "${BUILDMAN}" ==
> > "sandbox x86" ]]; then
> > + if [ ! -d "/tmp/capsules/" ]; then
> > + mkdir -p /tmp/capsules/;
> > + echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
> > + echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > + echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > + echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > + cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
> > /tmp/capsules/SIGNER.esl;
> > + fi
> > + fi
> >git config --global --add safe.directory ${WORK_DIR}
> >EOF
> >cat << "EOF" >> build.sh
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index cfd58513c3..aec6ffaf1c 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -37,6 +37,17 @@ stages:
> > export
> > OPENSBI=/tmp/opensbi-1.2-rv-bin/share/opensbi/lp64/generic/firmware/fw_dynamic.bin;
> >fi
> >
> > +- mkdir -p /tmp/capsules/;
> > +- echo -n "u-boot:Old" >/tmp/capsules/u-boot.bin.old;
> > +- echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > +- echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > +- echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +- if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > + openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes
> > -days 365;
> > + cert-to-efi-sig-list /tmp/capsules/SIGNER.crt
> > /tmp/capsules/SIGNER.esl;
> > + fi
> > +
>
Re: [PATCH v4 12/12] sandbox: capsule: Generate capsule related files through binman
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > The EFI capsule files can now be generated as part of u-boot
> > build. This is done through binman. Add capsule entry nodes in the
> > u-boot.dtsi for the sandbox architecture for generating the
> > capsules. Remove the corresponding generation of capsules from the
> > capsule update conftest file.
> >
> > The capsules are generated through the config file for the sandbox
> > variant, and through explicit parameters for the sandbox_flattree
> > variant.
> >
> > Also generate the FIT image used for testing the capsule update
> > feature on the sandbox_flattree variant through binman. Remove the now
> > superfluous its file which was used for generating this FIT image.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Use blob nodes instead of incbin for including the binaries in FIT
> > image.
> > * Enable generation of capsules with versioning support.
> >
> > arch/sandbox/dts/u-boot.dtsi | 265 ++
> > test/py/tests/test_efi_capsule/conftest.py| 127 -
> > .../tests/test_efi_capsule/uboot_bin_env.its | 36 ---
> > 3 files changed, 265 insertions(+), 163 deletions(-)
> > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
> >
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > index 60bd004937..7b0250ac81 100644
> > --- a/arch/sandbox/dts/u-boot.dtsi
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -13,5 +13,270 @@
> > capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > };
> > #endif
> > +
> > + binman: binman {
> > + multiple-images;
> > + };
> > +};
> > +
> > +&binman {
> > + itb {
> > + filename = "/tmp/capsules/uboot_bin_env.itb";
> > +
> > + fit {
> > + description = "Automatic U-Boot environment update";
> > + #address-cells = <2>;
> > +
> > + images {
> > + u-boot-bin {
> > + description = "U-Boot binary on SPI
> > Flash";
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + blob {
> > + filename =
> > "/tmp/capsules/u-boot.bin.new";
> > + };
> > +
> > + hash-1 {
> > + algo = "sha1";
> > + };
> > + };
> > + u-boot-env {
> > + description = "U-Boot environment
> > on SPI Flash";
> > + compression = "none";
> > + type = "firmware";
> > + arch = "sandbox";
> > + load = <0>;
> > + blob {
> > + filename =
> > "/tmp/capsules/u-boot.env.new";
> > + };
> > +
> > + hash-1 {
> > + algo = "sha1";
> > + };
> > + };
> > + };
> > + };
> > + };
> > +
> > +#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
> > + capsule1 {
> > + capsule {
> > + cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;
> > + };
> > + };
> > +#else
> > + capsule2 {
> > + capsule {
> > + image-index = <0x1>;
> > + image-type-id =
> > "09D7CF52-0720-4710-91D1-08469B7FE9C8";
>
> We seem to have a persistent problem with these appearing in the source code.
>
> Perhaps you could add them to a header file and use
> GUID_MEANINGFUL_NAME here instead (also below).
>
> In general, GUIDs should not be open-coded.
Okay. Will it be okay if I add these to a sandbox_capule.h. Earlier, I
had similar GUID macros in the sandbox config header, and you had
asked me to move them to the board file.
>
>
> > + filename = "/tmp/capsules/u-boot.bin.new";
> > + capsule = "/tmp/capsules/Test01";
>
> There is something odd here. You should not need to specify an
> absolute pathname and should not use /tmp
The /tmp/capsules/ directory is being used for collating all the
capsule testing related files. Both the input files as well as the
output capsule files
Re: [PATCH 08/18] environment: ti: Make get_fdt_mmc common
Hi Manorit,
On 14/07/23 11:22, Manorit Chawdhry wrote:
From: Andrew Davis
Since get_fdt_mmc is common, factor it out into mmc.env and remove
it from each platform env file along with changing the directory path to
reflect the standards. Use it in mmcloados but keep loadfdt
defined in case it is still used by some external uEnv.txt script.
Signed-off-by: Andrew Davis
Signed-off-by: Manorit Chawdhry
---
board/ti/am62ax/am62ax.env | 1 -
board/ti/am62x/am62x.env | 1 -
board/ti/am64x/am64x.env | 1 -
board/ti/am65x/am65x.env | 1 -
board/ti/j721e/j721e.env | 1 -
board/ti/j721s2/j721s2.env | 1 -
include/environment/ti/mmc.env | 5 +++--
7 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/board/ti/am62ax/am62ax.env b/board/ti/am62ax/am62ax.env
index 95401756e20a..491ec973bbc6 100644
--- a/board/ti/am62ax/am62ax.env
+++ b/board/ti/am62ax/am62ax.env
@@ -17,7 +17,6 @@ bootpart=1:2
bootdir=/boot
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
get_overlay_mmc and init_mmc are also common, these can also be moved to
mmc.env file.
diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
index 37af69199167..0901a8536da5 100644
--- a/board/ti/am62x/am62x.env
+++ b/board/ti/am62x/am62x.env
@@ -17,7 +17,6 @@ bootpart=1:2
bootdir=/boot
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
diff --git a/board/ti/am64x/am64x.env b/board/ti/am64x/am64x.env
index 4d27f16e8ca9..015f63a66c71 100644
--- a/board/ti/am64x/am64x.env
+++ b/board/ti/am64x/am64x.env
@@ -21,7 +21,6 @@ bootpart=1:2
bootdir=/boot
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
diff --git a/board/ti/am65x/am65x.env b/board/ti/am65x/am65x.env
index 3c583b77fd1e..d7130cc3f7df 100644
--- a/board/ti/am65x/am65x.env
+++ b/board/ti/am65x/am65x.env
@@ -20,7 +20,6 @@ bootpart=1:2
bootdir=/boot
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
diff --git a/board/ti/j721e/j721e.env b/board/ti/j721e/j721e.env
index 12b5610b3e47..23ce7e1af746 100644
--- a/board/ti/j721e/j721e.env
+++ b/board/ti/j721e/j721e.env
@@ -37,7 +37,6 @@ bootpart=1:2
bootdir=/boot
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
diff --git a/board/ti/j721s2/j721s2.env b/board/ti/j721s2/j721s2.env
index 67953d3f5984..9464fe499037 100644
--- a/board/ti/j721s2/j721s2.env
+++ b/board/ti/j721s2/j721s2.env
@@ -31,7 +31,6 @@ name_mcur5f0_0fw=/lib/firmware/j7-mcu-r5f0_0-fw
#endif
rd_spec=-
init_mmc=run args_all args_mmc
-get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_overlay_mmc=
fdt address ${fdtaddr};
fdt resize 0x10;
diff --git a/include/environment/ti/mmc.env b/include/environment/ti/mmc.env
index 5677d057d864..a052d288535e 100644
--- a/include/environment/ti/mmc.env
+++ b/include/environment/ti/mmc.env
@@ -13,7 +13,8 @@ importbootenv=echo Importing environment from mmc${mmcdev}
...;
env import -t ${loadaddr} ${filesize}
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
-loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
+loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/dtb/${fdtfile}
+get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/dtb/${name_fdt}
envboot=mmc dev ${mmcdev};
if mmc rescan; then
echo SD/MMC found on device ${mmcdev};
@@ -32,7 +33,7 @@ envboot=mmc dev ${mmcdev};
fi;
mmcloados=
if test ${boot_fdt} = yes || test ${boot_fdt} = try; then
- if run loadfdt; then
+ if run get_fdt_mmc; then
bootz ${loadaddr} - ${fdtaddr};
else
if test ${boot_fdt} = try; then
Thanks,
Nikhil
Re: [PATCH 07/18] environment: ti: Prefix ARM64 DTB names with directory
On 14/07/23 11:22, Manorit Chawdhry wrote: From: Andrew Davis In Linux the ARM64 DTSs are stored in vendor directories to help organize the files and prevent naming collisions. The deployed DTBs will mirror this and so the vendor prefix should be added to the variable used to locate these files. Suggested-by: Ryan Eatmon Signed-off-by: Andrew Davis Signed-off-by: Manorit Chawdhry --- board/ti/am62ax/am62ax.env | 2 +- board/ti/am62x/am62x.env | 2 +- board/ti/am64x/am64x.env | 4 ++-- board/ti/am65x/am65x.env | 2 +- board/ti/j721e/j721e.env | 8 board/ti/j721s2/j721s2.env | 6 +++--- include/configs/am62ax_evm.h | 2 +- 7 files changed, 13 insertions(+), 13 deletions(-) Reviewed-by: Nikhil M Jain
Re: [PATCH v4 01/12] binman: bintool: Build a tool from a list of commands
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Add support to build a tool from source with a list of commands. This
> > is useful when a tool can be built with multiple commands instead of a
> > single command.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * New patch to support passing multiple commands to the build_from_git
> > function to build the tool.
> >
> > tools/binman/bintool.py| 19 +++
> > tools/binman/btool/_testing.py | 3 ++-
> > tools/binman/btool/fiptool.py | 4 +++-
> > tools/binman/btool/futility.py | 4 +++-
> > 4 files changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
> > index 81629683df..279bf2fec4 100644
> > --- a/tools/binman/bintool.py
> > +++ b/tools/binman/bintool.py
> > @@ -328,7 +328,7 @@ class Bintool:
> > return result.stdout
> >
> > @classmethod
> > -def build_from_git(cls, git_repo, make_target, bintool_path,
> > flags=None):
> > +def build_from_git(cls, git_repo, make_targets, bintool_path,
> > flags=None):
> > """Build a bintool from a git repo
> >
> > This clones the repo in a temporary directory, builds it with
> > 'make',
> > @@ -336,7 +336,8 @@ class Bintool:
> >
> > Args:
> > git_repo (str): URL of git repo
> > -make_target (str): Target to pass to 'make' to build the tool
> > +make_targets (list of str): List of targets to pass to 'make'
> > to build
> > +the tool
> > bintool_path (str): Relative path of the tool in the repo,
> > after
> > build is complete
> > flags (list of str): Flags or variables to pass to make, or
> > None
> > @@ -350,12 +351,14 @@ class Bintool:
> > tmpdir = tempfile.mkdtemp(prefix='binmanf.')
> > print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
> > tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
> > -print(f"- build target '{make_target}'")
> > -cmd = ['make', '-C', tmpdir, '-j',
> > f'{multiprocessing.cpu_count()}',
> > - make_target]
> > -if flags:
> > -cmd += flags
> > -tools.run(*cmd)
> > +for target in make_targets:
> > +print(f"- build target '{target}'")
> > +cmd = ['make', '-C', tmpdir, '-j',
> > f'{multiprocessing.cpu_count()}',
> > + target]
> > +if flags:
> > +cmd += flags
> > +tools.run(*cmd)
> > +
> > fname = os.path.join(tmpdir, bintool_path)
> > if not os.path.exists(fname):
> > print(f"- File '{fname}' was not produced")
> > diff --git a/tools/binman/btool/_testing.py b/tools/binman/btool/_testing.py
> > index 4005e8a8a5..c0109c76bf 100644
> > --- a/tools/binman/btool/_testing.py
> > +++ b/tools/binman/btool/_testing.py
> > @@ -32,5 +32,6 @@ class Bintool_testing(bintool.Bintool):
> > return self.apt_install('package')
> > return self.fetch_from_drive('junk')
> > if method == bintool.FETCH_BUILD:
> > -return self.build_from_git('url', 'target', 'pathname')
> > +cmd = ['target']
> > +return self.build_from_git('url', cmd, 'pathname')
>
> Instead of the 'cmd' variable here, can you just put ['target'] as the
> function arg? Same below. It doesn't really add anything.
Okay. Will change.
-sughosh
>
> > return None
> > diff --git a/tools/binman/btool/fiptool.py b/tools/binman/btool/fiptool.py
> > index c80f8275c4..b275fee43b 100644
> > --- a/tools/binman/btool/fiptool.py
> > +++ b/tools/binman/btool/fiptool.py
> > @@ -107,8 +107,10 @@ class Bintoolfiptool(bintool.Bintool):
> > """
> > if method != bintool.FETCH_BUILD:
> > return None
> > +
> > +cmd = ['fiptool']
> > result = self.build_from_git(
> > 'https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git',
> > -'fiptool',
> > +cmd,
> > 'tools/fiptool/fiptool')
> > return result
> > diff --git a/tools/binman/btool/futility.py b/tools/binman/btool/futility.py
> > index 04c9aefe9b..4b22547368 100644
> > --- a/tools/binman/btool/futility.py
> > +++ b/tools/binman/btool/futility.py
> > @@ -168,9 +168,11 @@ class Bintoolfutility(bintool.Bintool):
> > #
> > # Unfortunately this requires logging in and obtaining a line for
> > the
> > # .gitcookies file. So use a mirror instead.
> > +
> > +cmd = ['all']
> > result = self.build_from_git(
> > 'https://github.com/sjg20/vboot_reference.git',
> > -'all',
> > +cmd,
> > 'build/futility/futility',
> > flags=['USE_FLASHROM=0'])
> > return result
> > --
>
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > Hi Sughosh, > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote: > > > > Add support in binman for generating capsules. The capsule parameters > > can be specified either through a config file or through the capsule > > binman entry. Also add test cases in binman for capsule generation, > > and enable this testing on the sandbox_spl variant. > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is really for > SPL testing. Er, I am actually using the sandbox_spl variant. > > > > > Signed-off-by: Sughosh Ganu > > --- > > Changes since V3: > > * Add test cases for covering the various capsule generation > > scenarios. > > * Add function comments in the mkeficapsule bintool. > > * Fix the fetch method of the mkeficapsule bintool to enable building > > the tool. > > * Add more details about the capsule parameters in the documentation > > as well as the code. > > * Fix order of module imports, and addition of blank lines in the > > capsule.py file. > > * Use SetContents in the ObtainContents method. > > > > configs/sandbox_spl_defconfig | 1 + > > tools/binman/btool/mkeficapsule.py| 158 ++ > > tools/binman/entries.rst | 37 > > tools/binman/etype/capsule.py | 132 +++ > > tools/binman/ftest.py | 127 ++ > > tools/binman/test/282_capsule.dts | 18 ++ > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > .../test/288_capsule_missing_payload.dts | 17 ++ > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > tools/binman/test/290_capsule_version.dts | 19 +++ > > tools/binman/test/capsule_cfg.txt | 6 + > > 15 files changed, 619 insertions(+) > > create mode 100644 tools/binman/btool/mkeficapsule.py > > create mode 100644 tools/binman/etype/capsule.py > > create mode 100644 tools/binman/test/282_capsule.dts > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > create mode 100644 tools/binman/test/285_capsule_missing_key.dts > > create mode 100644 tools/binman/test/286_capsule_missing_index.dts > > create mode 100644 tools/binman/test/287_capsule_missing_guid.dts > > create mode 100644 tools/binman/test/288_capsule_missing_payload.dts > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > create mode 100644 tools/binman/test/290_capsule_version.dts > > create mode 100644 tools/binman/test/capsule_cfg.txt > > This looks pretty good to me. Some nits below > > > > > diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig > > index dd848c57c6..2fcc789347 100644 > > --- a/configs/sandbox_spl_defconfig > > +++ b/configs/sandbox_spl_defconfig > > @@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y > > CONFIG_SPL_UNIT_TEST=y > > CONFIG_UT_TIME=y > > CONFIG_UT_DM=y > > +CONFIG_TOOLS_MKEFICAPSULE=y > > Why enabling this here? I don't think it is needed in sandbox_spl, but > in any case it should be in a different patch if needed. The binman tests run on the sandbox_spl variant. When running the capsule generation tests, the mkeficapsule tool should be present on the board variant no? > > > diff --git a/tools/binman/btool/mkeficapsule.py > > b/tools/binman/btool/mkeficapsule.py > > new file mode 100644 > > index 00..ba6b666714 > > --- /dev/null > > +++ b/tools/binman/btool/mkeficapsule.py > > @@ -0,0 +1,158 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# Copyright 2023 Linaro Limited > > +# > > +"""Bintool implementation for mkeficapsule tool > > + > > +mkeficapsule is a tool used for generating EFI capsules. > > + > > +The following are the command-line options to be provided > > +to the tool > > +Usage: mkeficapsule [options] > > +Options: > > + -g, --guid guid for image blob type > > + -i, --index update image index > > + -I, --instanceupdate hardware instance > > + -v, --fw-version firmware version > > + -p, --private-key private key file > > + -c, --certificate signer's certificate file > > + -m, --monotonic-count monotonic count > > + -d, --dump_sig dump signature (*.p7) > > + -A, --fw-accept firmware accept capsule, requires GUID, no image > > blob > > + -R, --fw-revert firmware revert capsule, takes no GUID, no image > > blob > > + -o, --capoemflag Capsule OEM Flag, an integer between 0x and > > 0x > > + -f, --cfg-file config file with capsule parameters > > + -h, --help print a help message > > + > > +""" > > + > > +from binman i
Re: [PATCH v3] event: Add fpga load event
On 7/12/23 13:39, christian.taedcke-...@weidmueller.com wrote:
From: Christian Taedcke
This enables implementing custom logic after a bitstream was loaded
into the fpga.
Signed-off-by: Christian Taedcke
---
Changes in v3:
- replace #if with if
- remove previously added printf
- return notification error from fpga_load()
- fix static_assert checking event name list
Changes in v2:
- replace __weak function with a new event
common/event.c | 3 +++
drivers/fpga/fpga.c | 20
include/event.h | 16
3 files changed, 39 insertions(+)
diff --git a/common/event.c b/common/event.c
index 164c95f8f5..20720c5283 100644
--- a/common/event.c
+++ b/common/event.c
@@ -36,6 +36,9 @@ const char *const type_name[] = {
/* init hooks */
"misc_init_f",
+ /* Fpga load hook */
+ "fpga_load",
+
/* fdt hooks */
"ft_fixup",
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 7f6b6bc73a..81e6d8ffc0 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -244,6 +244,21 @@ int fpga_loads(int devnum, const void *buf, size_t size,
}
#endif
+static int fpga_load_event_notify(const void *buf, size_t bsize, int result)
+{
+ if (CONFIG_IS_ENABLED(EVENT)) {
+ struct event_fpga_load load = {
+ .buf = buf,
+ .bsize = bsize,
+ .result = result
+ };
+
+ return event_notify(EVT_FPGA_LOAD, &load, sizeof(load));
+ }
+
+ return 0;
+}
+
/*
* Generic multiplexing code
*/
@@ -251,6 +266,7 @@ int fpga_load(int devnum, const void *buf, size_t bsize,
bitstream_type bstype,
int flags)
{
int ret_val = FPGA_FAIL; /* assume failure */
+ int ret_notify;
const fpga_desc *desc = fpga_validate(devnum, buf, bsize,
(char *)__func__);
@@ -284,6 +300,10 @@ int fpga_load(int devnum, const void *buf, size_t bsize, bitstream_type bstype,
}
}
+ ret_notify = fpga_load_event_notify(buf, bsize, ret_val);
+ if (ret_notify)
+ return ret_notify;
+
return ret_val;
}
diff --git a/include/event.h b/include/event.h
index fe41080fa6..77124c2e73 100644
--- a/include/event.h
+++ b/include/event.h
@@ -31,6 +31,9 @@ enum event_t {
/* Init hooks */
EVT_MISC_INIT_F,
+ /* Fpga load hook */
+ EVT_FPGA_LOAD,
+
/* Device tree fixups before booting */
EVT_FT_FIXUP,
@@ -59,6 +62,19 @@ union event_data {
struct udevice *dev;
} dm;
+ /**
+* struct event_fpga_load - fpga load event
+*
+* @buf: The buffer that was loaded into the fpga
+* @bsize: The size of the buffer that was loaded into the fpga
+* @result: Result of the load operation
+*/
+ struct event_fpga_load {
+ const void *buf;
+ size_t bsize;
+ int result;
+ } fpga_load;
+
/**
* struct event_ft_fixup - FDT fixup before booting
*
There is the error generated for kmcent2_defconfig.
Please fix.
For more information please take a look at
https://source.denx.de/u-boot/custodians/u-boot-microblaze/-/jobs/657127
+In file included from board/keymile/kmcent2/kmcent2.c:9:
+include/event.h:74:17: error: unknown type name 'size_t'
+ 74 | size_t bsize;
+ | ^~
+make[2]: *** [scripts/Makefile.build:257: board/keymile/kmcent2/kmcent2.o]
Error 1
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH v4 11/12] sandbox: capsule: Add a config file for generating capsules
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > Support has been added to the mkeficapsule tool to generate capsules
> > by parsing the capsule parameters through a config file. Add a config
> > file for generating capsules. These capsules will be used for testing
> > the capsule update feature on sandbox platform.
> >
> > Enable generation of capsules through the config file on the sandbox
> > variant.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Use fstrings for format specifiers.
> > * Add entries for generating capsules with version parameter.
> >
> > .azure-pipelines.yml | 2 +
> > .gitlab-ci.yml| 2 +
> > configs/sandbox_defconfig | 2 +
> > test/py/conftest.py | 5 +
> > .../test_efi_capsule/sandbox_capsule_cfg.txt | 162 ++
> > 5 files changed, 173 insertions(+)
> > create mode 100644 test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> >
> > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > index d732ba443d..240ee4f692 100644
> > --- a/.azure-pipelines.yml
> > +++ b/.azure-pipelines.yml
> > @@ -403,6 +403,7 @@ stages:
> >echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> >echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> >echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> >if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > @@ -600,6 +601,7 @@ stages:
> >echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> >echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> >echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > + cp
> > test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt /tmp/capsules/;
> >
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER.key -out
> > /tmp/capsules/SIGNER.crt -nodes -days 365;
> >openssl req -x509 -sha256 -newkey rsa:2048 -subj
> > /CN=TEST_SIGNER/ -keyout /tmp/capsules/SIGNER2.key -out
> > /tmp/capsules/SIGNER2.crt -nodes -days 365;
> > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > index aec6ffaf1c..42456e5f3f 100644
> > --- a/.gitlab-ci.yml
> > +++ b/.gitlab-ci.yml
> > @@ -42,6 +42,7 @@ stages:
> > - echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > - echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > - echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +- cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> > - if [[ "${TEST_PY_BD}" == "sandbox" ]] || [[ "${TEST_PY_BD}" ==
> > "sandbox_flattree" ]]; then
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes
> > -days 365;
> > @@ -148,6 +149,7 @@ build all other platforms:
> > echo -n "u-boot:New" >/tmp/capsules/u-boot.bin.new;
> > echo -n "u-boot-env:Old" >/tmp/capsules/u-boot.env.old;
> > echo -n "u-boot-env:New" >/tmp/capsules/u-boot.env.new;
> > +cp test/py/tests/test_efi_capsule/sandbox_capsule_cfg.txt
> > /tmp/capsules/;
> >
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER.key -out /tmp/capsules/SIGNER.crt -nodes -days
> > 365;
> > openssl req -x509 -sha256 -newkey rsa:2048 -subj /CN=TEST_SIGNER/
> > -keyout /tmp/capsules/SIGNER2.key -out /tmp/capsules/SIGNER2.crt -nodes
> > -days 365;
> > diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> > index 560f3317d9..f3c09f845a 100644
> > --- a/configs/sandbox_defconfig
> > +++ b/configs/sandbox_defconfig
> > @@ -341,6 +341,8 @@ CONFIG_EFI_CAPSULE_ON_DISK=y
> > CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
> > CONFIG_EFI_CAPSULE_AUTHENTICATE=y
> > CONFIG_EFI_CAPSULE_ESL_FILE="/tmp/capsules/SIGNER.esl"
> > +CONFIG_EFI_CAPSULE_CFG_FILE="/tmp/capsules/sandbox_capsule_cfg.txt"
> > +CONFIG_EFI_USE_CAPSULE_CFG_FILE=y
> > CONFIG_EFI_SECURE_BOOT=y
> > CONFIG_TEST_FDTDEC=y
> > CONFIG_UNIT_TEST=y
> > diff --git a/test/py/conftest.py
Re: [PATCH v4 03/12] capsule: authenticate: Add capsule public key in platform's dtb
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu wrote:
> >
> > The EFI capsule authentication logic in u-boot expects the public key
> > in the form of an EFI Signature List(ESL) to be provided as part of
> > the platform's dtb. Currently, the embedding of the ESL file into the
> > dtb needs to be done manually.
> >
> > Add a signature node in the u-boot dtsi file and include the public
> > key through the capsule-key property. This file is per architecture,
> > and is currently being added for sandbox and arm architectures. It
> > will have to be added for other architectures which need to enable
> > capsule authentication support.
> >
> > The path to the ESL file is specified through the
> > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > Changes since V3:
> > * Put the two ifdef statements together in arm architecture's
> > u-boot.dtsi file.
> > * Remove the extra blank line in the Kconfig.
> >
> > arch/arm/dts/u-boot.dtsi | 17 +
> > arch/sandbox/dts/u-boot.dtsi | 17 +
> > lib/efi_loader/Kconfig | 10 ++
> > lib/efi_loader/Makefile | 7 +++
> > 4 files changed, 51 insertions(+)
> > create mode 100644 arch/arm/dts/u-boot.dtsi
> > create mode 100644 arch/sandbox/dts/u-boot.dtsi
>
> This approach seems OK to me for now. It is a bit strange to specify a
> CONFIG option to add something to the DT, but we can always adjust it
> later if needed.
>
> >
> > diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
> > new file mode 100644
> > index 00..2a9359c43c
> > --- /dev/null
> > +++ b/arch/arm/dts/u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
>
> /**
>
> for multi-line comments
Okay
>
> > + * Devicetree file with miscellaneous nodes that will be included
> > + * at build time into the DTB. Currently being used for including
> > + * capsule related information.
> > + *
>
> drop blank line
Okay
>
> > + */
> > +
> > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
>
> Can you combine these, or can you omit the first one?
I will drop the first line. Should build for all platforms I believe.
>
> > +/ {
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +};
> > +#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
> > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > new file mode 100644
> > index 00..60bd004937
> > --- /dev/null
> > +++ b/arch/sandbox/dts/u-boot.dtsi
> > @@ -0,0 +1,17 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Devicetree file with miscellaneous nodes that will be included
> > + * at build time into the DTB. Currently being used for including
> > + * capsule related information.
> > + *
> > + */
> > +
> > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > +/ {
> > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > + signature {
> > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > + };
> > +#endif
> > +};
> > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index a22e47616f..9abb9a4db3 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -235,6 +235,16 @@ config EFI_CAPSULE_MAX
> > Select the max capsule index value used for capsule report
> > variables. This value is used to create CapsuleMax variable.
> >
> > +config EFI_CAPSULE_ESL_FILE
> > + string "Path to the EFI Signature List File"
> > + default ""
> > + depends on EFI_CAPSULE_AUTHENTICATE
> > + help
> > + Provides the absolute path to the EFI Signature List
> > + file which will be embedded in the platform's device
> > + tree and used for capsule authentication at the time
> > + of capsule update.
>
> Can you wrap to 72 chars or so?
Okay
-sughosh
>
> > +
> > config EFI_DEVICE_PATH_TO_TEXT
> > bool "Device path to text protocol"
> > default y
> > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > index 1a8c8d7cab..c52c9d27bd 100644
> > --- a/lib/efi_loader/Makefile
> > +++ b/lib/efi_loader/Makefile
> > @@ -89,3 +89,10 @@ obj-$(CONFIG_EFI_ECPT) += efi_conformance.o
> >
> > EFI_VAR_SEED_FILE := $(subst $\",,$(CONFIG_EFI_VAR_SEED_FILE))
> > $(obj)/efi_var_seed.o: $(srctree)/$(EFI_VAR_SEED_FILE)
> > +
> > +ifeq ($(CONFIG_EFI_CAPSULE_AUTHENTICATE),y)
> > +EFI_CAPSULE_KEY_PATH := $(subst $\",,$(CONFIG_EFI_CAPSULE_ESL_FILE))
> > +ifeq ("$(wildcard $(EFI_CAPSULE_KEY_PATH))","")
> > +$(error .esl cerificate not found. Configure your
> > CONFIG_EFI_CAPSULE_ESL_FILE)
> > +endif
> > +endif
> > --
> > 2.34.1
> >
>
> REgards,
> Simon
Re: [PATCH 13/18] configs: k3: make consistent bootcmd across all k3 socs
Hi Manorit,
On 14/07/23 11:22, Manorit Chawdhry wrote:
From: Kamlesh Gurudasani
Default to common bootcmd that is set across all k3 devices.
Signed-off-by: Manorit Chawdhry
Signed-off-by: Kamlesh Gurudasani
---
configs/am62ax_evm_a53_defconfig | 1 +
configs/am62x_evm_a53_defconfig | 3 +--
configs/am64x_evm_a53_defconfig | 2 +-
configs/j7200_evm_a72_defconfig | 2 +-
configs/j721e_evm_a72_defconfig | 2 +-
configs/j721s2_evm_a72_defconfig | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 76ec5ed40463..773cf3a591c6 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_PAD_TO=0x0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 7c3bc184cf73..de90663383ec 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -29,8 +29,7 @@ CONFIG_SPL_SPI=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern; setenv
fdtfile ti/${name_fdt}; run distro_bootcmd"
-CONFIG_SPL_MAX_SIZE=0x58000
Please add this config back.
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
CONFIG_SPL_BSS_MAX_SIZE=0x8
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 123a70049aeb..f792b5859e94 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_SPI=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x18
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 0abc865cb5d5..c68d52537e54 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 825dbd865cd9..525f150e91d9 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index 13c1a0cdbe9b..d59f3156d105 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -32,7 +32,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; if
test ${boot_fit} -eq 1; then run get_fit_${boot}; run get_overlaystring; run run_fit;
else; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
Thanks,
Nikhil
Re: [PATCH 13/18] configs: k3: make consistent bootcmd across all k3 socs
Hi Manorit,
On 14/07/23 11:22, Manorit Chawdhry wrote:
From: Kamlesh Gurudasani
Default to common bootcmd that is set across all k3 devices.
Signed-off-by: Manorit Chawdhry
Signed-off-by: Kamlesh Gurudasani
---
configs/am62ax_evm_a53_defconfig | 1 +
configs/am62x_evm_a53_defconfig | 3 +--
configs/am64x_evm_a53_defconfig | 2 +-
configs/j7200_evm_a72_defconfig | 2 +-
configs/j721e_evm_a72_defconfig | 2 +-
configs/j721s2_evm_a72_defconfig | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configs/am62ax_evm_a53_defconfig b/configs/am62ax_evm_a53_defconfig
index 76ec5ed40463..773cf3a591c6 100644
--- a/configs/am62ax_evm_a53_defconfig
+++ b/configs/am62ax_evm_a53_defconfig
@@ -23,6 +23,7 @@ CONFIG_SPL_LIBDISK_SUPPORT=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_SPL_MAX_SIZE=0x58000
CONFIG_SPL_PAD_TO=0x0
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
index 7c3bc184cf73..de90663383ec 100644
--- a/configs/am62x_evm_a53_defconfig
+++ b/configs/am62x_evm_a53_defconfig
@@ -29,8 +29,7 @@ CONFIG_SPL_SPI=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern; setenv
fdtfile ti/${name_fdt}; run distro_bootcmd"
-CONFIG_SPL_MAX_SIZE=0x58000
Please add this config back.
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
CONFIG_SPL_BSS_START_ADDR=0x80c8
CONFIG_SPL_BSS_MAX_SIZE=0x8
diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig
index 123a70049aeb..f792b5859e94 100644
--- a/configs/am64x_evm_a53_defconfig
+++ b/configs/am64x_evm_a53_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_SPI=y
CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run run_kern"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_MAX_SIZE=0x18
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j7200_evm_a72_defconfig b/configs/j7200_evm_a72_defconfig
index 0abc865cb5d5..c68d52537e54 100644
--- a/configs/j7200_evm_a72_defconfig
+++ b/configs/j7200_evm_a72_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721e_evm_a72_defconfig b/configs/j721e_evm_a72_defconfig
index 825dbd865cd9..525f150e91d9 100644
--- a/configs/j721e_evm_a72_defconfig
+++ b/configs/j721e_evm_a72_defconfig
@@ -33,7 +33,7 @@ CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_BOARD_SETUP=y
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run distro_bootcmd; run init_${boot}; run
main_cpsw0_qsgmii_phyinit; run boot_rprocs; if test ${boot_fit} -eq 1; then run
get_fit_${boot}; run get_overlaystring; run run_fit; else; run get_kern_${boot}; run
get_fdt_${boot}; run get_overlay_${boot}; run run_kern; fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
diff --git a/configs/j721s2_evm_a72_defconfig b/configs/j721s2_evm_a72_defconfig
index 13c1a0cdbe9b..d59f3156d105 100644
--- a/configs/j721s2_evm_a72_defconfig
+++ b/configs/j721s2_evm_a72_defconfig
@@ -32,7 +32,7 @@ CONFIG_SPL_LOAD_FIT=y
CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
CONFIG_OF_SYSTEM_SETUP=y
CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run boot_rprocs; if
test ${boot_fit} -eq 1; then run get_fit_${boot}; run get_overlaystring; run run_fit;
else; run get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern;
fi;"
+CONFIG_BOOTCOMMAND="run envboot; run distro_bootcmd;"
CONFIG_LOGLEVEL=7
CONFIG_SPL_MAX_SIZE=0xc
CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
Thanks,
Nikhil
Re: [PATCH v2] x86: Update docs link in bootparam header
On Sun, Jul 9, 2023 at 5:48 PM Heinrich Schuchardt wrote:
>
> On 7/9/23 11:44, Paul Barker wrote:
> > After Linux commit ff61f0791ce9, x86 documentation was moved to
> > arch/x86 and the link in bootparam.h was broken.
> >
> > Signed-off-by: Paul Barker
>
> Reviewed-by: Heinrich Schuchardt
>
> > ---
> > arch/x86/include/asm/bootparam.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/bootparam.h
> > b/arch/x86/include/asm/bootparam.h
> > index ea816ca74698..ac4865300f1b 100644
> > --- a/arch/x86/include/asm/bootparam.h
> > +++ b/arch/x86/include/asm/bootparam.h
> > @@ -62,7 +62,7 @@ struct setup_indirect {
> > /**
> >* struct setup_header - Information needed by Linux to boot
> >*
> > - * See https://www.kernel.org/doc/html/latest/x86/boot.html
> > + * See https://www.kernel.org/doc/html/latest/arch/x86/boot.html
> >*/
> > struct setup_header {
> > __u8setup_sects;
> >
> > base-commit: 0beb649053b86b2cfd5cf55a0fc68bc2fe91a430
>
applied to u-boot-x86, thanks!
Re: [PATCH 00/17] arm64: zynqmp: Sync DTs was [Hi,]
On 7/10/23 14:37, Michal Simek wrote: sending couple of DT patches to be in sync with Linux repository. There are still some changes but we are working on it to get them fully in sync for SystemReady IR certification. Thanks, Michal Harini Katakam (3): arm64: zynqmp: Assign TSU clock frequency for KR260 arm64: zynqmp: Increase reset assert time for TI SGMII PHY arm64: zynqmp: Assign TSU clock frequency for KV and KD boards Manikanta Guntupalli (1): xilinx: dts: Fix open drain warning on Zynq, ZynqMP and Versal Michal Simek (8): arm64: zynqmp: Fix gpio comment about No of gpios arm64: zynqmp: Record compatible string for kv260 rev2 arm64: zynqmp: Cover K24 revB/1 SOM arm64: zynqmp: Fix usb reset over bootmode pins on zcu100 arm64: zynqmp: Sync node name address with reg (mailbox) arm64: zynqmp: Remove interrupt/reg-names for AMS arm64: zynqmp: Rename ams_ps/pl node names arm64: zynqmp: Remove clock-names from pcap node Parth Gajjar (1): arm64: zynqmp: Update MALI 400 interrupt and clock names Piyush Mehta (1): arm64: zynqmp: remove snps,enable_guctl1_resume_quirk quirk for usb Radhey Shyam Pandey (2): arm64: zynqmp: Add L2 cache nodes arm64: zynqmp: add pmu interrupt-affinity Varalaxmi Bingi (1): arm: xilinx: Setting default i2c clock frequency to 400kHz arch/arm/dts/zynq-7000.dtsi | 2 ++ arch/arm/dts/zynq-zc702.dts | 5 ++-- arch/arm/dts/zynqmp-clk-ccf.dtsi | 10 +++ arch/arm/dts/zynqmp-dlc21-revA.dts | 2 +- arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 2 +- arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 6 ++--- arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 2 +- arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 2 +- arch/arm/dts/zynqmp-sck-kr-g-revA.dts| 8 +++--- arch/arm/dts/zynqmp-sck-kr-g-revB.dts| 8 +++--- arch/arm/dts/zynqmp-sck-kv-g-revA.dts| 5 ++-- arch/arm/dts/zynqmp-sck-kv-g-revB.dts| 8 +++--- arch/arm/dts/zynqmp-sm-k24-revA.dts | 5 ++-- arch/arm/dts/zynqmp-sm-k26-revA.dts | 6 ++--- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 4 +-- arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 4 +-- arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 8 +++--- arch/arm/dts/zynqmp-zcu100-revC.dts | 6 +++-- arch/arm/dts/zynqmp-zcu102-revA.dts | 8 +++--- arch/arm/dts/zynqmp-zcu104-revA.dts | 4 +-- arch/arm/dts/zynqmp-zcu104-revC.dts | 4 +-- arch/arm/dts/zynqmp-zcu106-revA.dts | 8 +++--- arch/arm/dts/zynqmp-zcu111-revA.dts | 8 +++--- arch/arm/dts/zynqmp-zcu208-revA.dts | 10 +++ arch/arm/dts/zynqmp-zcu216-revA.dts | 10 +++ arch/arm/dts/zynqmp.dtsi | 33 28 files changed, 103 insertions(+), 79 deletions(-) Applied and also fix subject for this cover letter just in reply. M
Re: [PATCH v5 00/46] x86: Use qemu-x86_64 to boot EFI installers
Hi Simon, On Sun, Jul 16, 2023 at 11:39 AM Simon Glass wrote: > > This series adds various minor features so that qemu-x86_64 can boot the > Ubuntu 2022.04 installer using a virtio device: > > qemu-system-x86_64 -M pc -drive format=raw,file=root.img > -bios /tmp/b/qemu-x86_64/u-boot.rom > -drive if=virtio,file=ubuntu-22.04.2-desktop-amd64.iso > -smp 4 -m 4G -serial mon:stdio > > The main changes include: > - Enable video in SPL while running in 32-bit mode > - Drop the duplicate ACPI tables with EFI > - Support PCI autoconfig in SPL > - Support FAT on a CDROM filesystem > - Improved bootstd rules around device tree and efi_set_bootdev() > > There are also quite a number of minor tweaks and fixes to make things > easier to use. > > This series is based on an older version of the SPL-video series from > Nikhil M Jain. It is available at u-boot-dm/bryc-working > > Changes in v5: > - Make mtrr_type_name[] static > - Fix 'abrievated' typo > - Drop extra space in penultimate example > - Drop unnecessary 'it' in commit message > - Adjust the prompt for clarity (although it is now >12 chars) > - Reword commit message > - Drop unnecessary 'allow' word > - Add tests for bdinfo additions > - Drop extra 'qfw list' line > - Update commit message to explain 'md' reference > - Drop period at end of commit subject > - Drop extra 'a' in commit message > - Add 'bdinfo' tag to commit subject > - Use the existing QEMU code instead > - Use u16 instead of ushort > - Split out banner code into a separate patch > - Drop code to ensure the SPL banner is only shown once > - Fix 'litlle' typo in subject > - Correct indentation > - Add a comment about QFW putting its tables up high > - Add a comment that the bloblist is always in high memory > - Use "gpio" for log return > - Use QEMU instead of qemu > - Drop patch 'Show the number of physical address bits' > Except the following patches: [v5,02/46] x86: Return mtrr_add_request() to its old purpose [v5,23/46] pci: Allow the video BIOS to work in SPL with QEMU [v5,34/46] fs: fat: Support reading from a larger block size series applied to u-boot-x86, thanks! I will take a look at the MTRR one. Regards, Bin
Re: [PATCH v5 37/46] x86: Record the start and end of the tables
On Sun, Jul 16, 2023 at 11:40 AM Simon Glass wrote: > > The ACPI tables are special in that they are passed to EFI as a separate > piece, independent of other tables. > > Also they can be spread over two areas of memory, e.g. with QEMU we end > up with tables kept in high memory as well. > > Add new global_data fields to hold this information and update the bdinfo > command to show the table areas. > > Move the rom_table_end variable into the loop that uses it. > > Signed-off-by: Simon Glass > --- > > Changes in v5: > - Add a comment about QFW putting its tables up high > - Add a comment that the bloblist is always in high memory > > Changes in v3: > - Adjust the code to handle qemu writing a pointer to tables in memory > > Changes in v2: > - Handle the case where the tables are in the bloblist > > arch/sandbox/include/asm/global_data.h | 4 > arch/x86/include/asm/global_data.h | 4 > arch/x86/lib/bdinfo.c | 4 > arch/x86/lib/tables.c | 20 +++- > drivers/misc/qfw.c | 9 + > 5 files changed, 40 insertions(+), 1 deletion(-) > Reviewed-by: Bin Meng
Re: [PATCH] mtd: Add missing MTD dependency for cfi_mtd
On 7/4/23 14:04, Michal Simek wrote: cfi_mtd requires add_mtd_device() which is available only when MTD is enabled that's why record this dependency. Signed-off-by: Michal Simek --- drivers/mtd/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 5fa88dae5f33..c56840c84975 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -128,7 +128,7 @@ config FLASH_SPANSION_S29WS_N config FLASH_CFI_MTD bool "Enable CFI MTD driver" - depends on FLASH_CFI_DRIVER + depends on FLASH_CFI_DRIVER && MTD help This option enables the building of the cfi_mtd driver in the drivers directory. The driver exports CFI flash Applied. M
Re: [PATCH] mmc: zynq_sdhci: Dll reset only for ZynqMP platform
On 7/10/23 14:11, Michal Simek wrote: From: Ashok Reddy Soma Dll reset is needed only for ZynqMP platforms, add condition in tuning to call arasan_zynqmp_dll_reset() just for ZynqMP platforms. On other platforms like Versal NET, If this condition is not added, we see PLM error messages when dll reset smc is called. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- drivers/mmc/zynq_sdhci.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index e779251ce34f..935540d17194 100644 --- a/drivers/mmc/zynq_sdhci.c +++ b/drivers/mmc/zynq_sdhci.c @@ -422,7 +422,8 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 opcode) mdelay(1); - arasan_zynqmp_dll_reset(host, priv->node_id); + if (device_is_compatible(mmc->dev, "xlnx,zynqmp-8.9a")) + arasan_zynqmp_dll_reset(host, priv->node_id); sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_INT_ENABLE); sdhci_writel(host, SDHCI_INT_DATA_AVAIL, SDHCI_SIGNAL_ENABLE); @@ -468,7 +469,9 @@ static int arasan_sdhci_execute_tuning(struct mmc *mmc, u8 opcode) } udelay(1); - arasan_zynqmp_dll_reset(host, priv->node_id); + + if (device_is_compatible(mmc->dev, "xlnx,zynqmp-8.9a")) + arasan_zynqmp_dll_reset(host, priv->node_id); /* Enable only interrupts served by the SD controller */ sdhci_writel(host, SDHCI_INT_DATA_MASK | SDHCI_INT_CMD_MASK, Applied. M
Re: [PATCH] mtd: spi-nor: Add support for w25q256jwm
On 6/26/23 05:32, Venkatesh Yadav Abbarapu wrote:
Add support for Winbond 256M-bit flash w25q256jwm.
Performed basic erase/write/readback operations on
ZynqMP zc1751+dc1 board.
Signed-off-by: Venkatesh Yadav Abbarapu
---
drivers/mtd/spi/spi-nor-ids.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 3f8b796789..53a743a038 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -446,6 +446,11 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
},
+ {
+ INFO("w25q256jwm", 0xef8019, 0, 64 * 1024, 512,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+ SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
{ INFO("w25x64", 0xef3017, 0, 64 * 1024, 128, SECT_4K) },
{
INFO("w25q64dw", 0xef6017, 0, 64 * 1024, 128,
Applied.
M
Re: [PATCH v2] xilinx: zynqmp: Extract aes operation into new file
On 7/10/23 16:09, christian.taedcke-...@weidmueller.com wrote:
From: Christian Taedcke
This moves the aes operation that is performed by the pmu into a
separate file. This way it can be called not just from the shell
command, but also e.g. from board initialization code.
Signed-off-by: Christian Taedcke
---
Changes in v2:
- convert doxygen comments to kernel-doc
- fix typos
- fix header license
- fix do_zynqmp_aes() return value
arch/arm/mach-zynqmp/Makefile | 3 +-
arch/arm/mach-zynqmp/aes.c| 58 +++
.../arm/mach-zynqmp/include/mach/zynqmp_aes.h | 32 ++
board/xilinx/zynqmp/cmds.c| 43 +-
4 files changed, 94 insertions(+), 42 deletions(-)
create mode 100644 arch/arm/mach-zynqmp/aes.c
create mode 100644 arch/arm/mach-zynqmp/include/mach/zynqmp_aes.h
diff --git a/arch/arm/mach-zynqmp/Makefile b/arch/arm/mach-zynqmp/Makefile
index bb1830c846..1a76493bef 100644
--- a/arch/arm/mach-zynqmp/Makefile
+++ b/arch/arm/mach-zynqmp/Makefile
@@ -3,8 +3,7 @@
# (C) Copyright 2014 - 2015 Xilinx, Inc.
# Michal Simek
-obj-y += clk.o
-obj-y += cpu.o
+obj-y += aes.o clk.o cpu.o
obj-$(CONFIG_MP) += mp.o
obj-$(CONFIG_SPL_BUILD) += spl.o handoff.o psu_spl_init.o
obj-$(CONFIG_SPL_ZYNQMP_DRAM_ECC_INIT) += ecc_spl_init.o
diff --git a/arch/arm/mach-zynqmp/aes.c b/arch/arm/mach-zynqmp/aes.c
new file mode 100644
index 00..115bca8338
--- /dev/null
+++ b/arch/arm/mach-zynqmp/aes.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2018 Xilinx, Inc.
+ * Siva Durga Prasad Paladugu
+ *
+ * Copyright (C) 2023 Weidmueller Interface GmbH & Co. KG
+ * Christian Taedcke
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+int zynqmp_aes_operation(struct zynqmp_aes *aes)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (zynqmp_firmware_version() <= PMUFW_V1_0)
+ return -ENOENT;
+
+ if (aes->srcaddr && aes->ivaddr && aes->dstaddr) {
+ flush_dcache_range(aes->srcaddr,
+ (aes->srcaddr +
+ roundup(aes->len, ARCH_DMA_MINALIGN)));
+ flush_dcache_range(aes->ivaddr,
+ (aes->ivaddr +
+ roundup(IV_SIZE, ARCH_DMA_MINALIGN)));
+ flush_dcache_range(aes->dstaddr,
+ (aes->dstaddr +
+ roundup(aes->len, ARCH_DMA_MINALIGN)));
+ }
+
+ if (aes->keysrc == 0) {
+ if (aes->keyaddr == 0)
+ return -EINVAL;
+
+ flush_dcache_range(aes->keyaddr, (aes->keyaddr +
+ roundup(KEY_PTR_LEN,
ARCH_DMA_MINALIGN)));
+ }
+
+ flush_dcache_range((ulong)aes, (ulong)(aes) +
+ roundup(sizeof(struct zynqmp_aes),
ARCH_DMA_MINALIGN));
+
+ ret = xilinx_pm_request(PM_SECURE_AES, upper_32_bits((ulong)aes),
+ lower_32_bits((ulong)aes), 0, 0, ret_payload);
+ if (ret || ret_payload[1]) {
+ printf("Failed: AES op status:0x%x, errcode:0x%x\n",
+ ret, ret_payload[1]);
+ return -EIO;
+ }
+
+ return 0;
+}
diff --git a/arch/arm/mach-zynqmp/include/mach/zynqmp_aes.h
b/arch/arm/mach-zynqmp/include/mach/zynqmp_aes.h
new file mode 100644
index 00..5bffb6b64c
--- /dev/null
+++ b/arch/arm/mach-zynqmp/include/mach/zynqmp_aes.h
@@ -0,0 +1,32 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2023 Weidmueller Interface GmbH & Co. KG
+ * Christian Taedcke
+ *
+ * Declaration of AES operation functionality for ZynqMP.
+ */
+
+#ifndef ZYNQMP_AES_H
+#define ZYNQMP_AES_H
+
+struct zynqmp_aes {
+ u64 srcaddr;
+ u64 ivaddr;
+ u64 keyaddr;
+ u64 dstaddr;
+ u64 len;
+ u64 op;
+ u64 keysrc;
+};
+
+/*
Should start with /**
+ * Performs an aes operation using the pmu firmware
+ *
+ * @aes The aes operation buffer that must have been allocated using
+ * ALLOC_CACHE_ALIGN_BUFFER(struct zynqmp_aes, aes, 1).
+ *
+ * Return: 0 in case of success, in case of an error any other value
+ */
Not a kernel-doc format.
./scripts/kernel-doc -man -v 2>/dev/null
arch/arm/mach-zynqmp/include/mach/zynqmp_aes.h
The rest looks good.
M
Re: [PATCH] arm64: zynqmp: Switch to amd.com emails
On 7/10/23 14:35, Michal Simek wrote: Update my and DPs email address to match current setup. Signed-off-by: Michal Simek --- The same changes have been done in Linux. Link: https://lore.kernel.org/r/108cbbbab29e13d386d38a779fd582f10844a030.1685443337.git.michal.si...@amd.com --- arch/arm/dts/avnet-ultra96-rev1.dts | 2 +- arch/arm/dts/versal-mini-emmc0.dts| 4 ++-- arch/arm/dts/versal-mini-emmc1.dts| 4 ++-- arch/arm/dts/versal-mini-ospi.dtsi| 4 ++-- arch/arm/dts/versal-mini-qspi.dtsi| 4 ++-- arch/arm/dts/versal-mini.dts | 2 +- arch/arm/dts/zynq-dlc20-rev1.0.dts| 2 +- arch/arm/dts/zynq-minized.dts | 2 +- arch/arm/dts/zynqmp-a2197-revA.dts| 2 +- arch/arm/dts/zynqmp-clk-ccf.dtsi | 2 +- arch/arm/dts/zynqmp-dlc21-revA.dts| 2 +- arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 2 +- arch/arm/dts/zynqmp-g-a2197-00-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 2 +- arch/arm/dts/zynqmp-mini-emmc0.dts| 2 +- arch/arm/dts/zynqmp-mini-emmc1.dts| 2 +- arch/arm/dts/zynqmp-mini-nand.dts | 4 ++-- arch/arm/dts/zynqmp-mini-qspi.dts | 4 ++-- arch/arm/dts/zynqmp-mini.dts | 2 +- arch/arm/dts/zynqmp-p-a2197-00-revA.dts | 2 +- arch/arm/dts/zynqmp-r5.dts| 2 +- arch/arm/dts/zynqmp-sck-kr-g-revA.dts | 2 +- arch/arm/dts/zynqmp-sck-kr-g-revB.dts | 2 +- arch/arm/dts/zynqmp-sck-kv-g-revA.dts | 2 +- arch/arm/dts/zynqmp-sck-kv-g-revB.dts | 2 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 2 +- arch/arm/dts/zynqmp-smk-k26-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1232-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1254-revA.dts | 4 ++-- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm017-dc3.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm019-dc5.dts | 4 ++-- arch/arm/dts/zynqmp-zcu100-revC.dts | 2 +- arch/arm/dts/zynqmp-zcu102-rev1.0.dts | 2 +- arch/arm/dts/zynqmp-zcu102-rev1.1.dts | 2 +- arch/arm/dts/zynqmp-zcu102-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu102-revB.dts | 2 +- arch/arm/dts/zynqmp-zcu104-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu104-revC.dts | 2 +- arch/arm/dts/zynqmp-zcu106-rev1.0.dts | 2 +- arch/arm/dts/zynqmp-zcu106-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu111-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu1275-revA.dts | 4 ++-- arch/arm/dts/zynqmp-zcu1275-revB.dts | 4 ++-- arch/arm/dts/zynqmp-zcu1285-revA.dts | 4 ++-- arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +- arch/arm/dts/zynqmp.dtsi | 2 +- arch/arm/mach-tegra/arm64-mmu.c | 2 +- arch/arm/mach-versal/Makefile | 2 +- arch/arm/mach-versal/clk.c| 2 +- arch/arm/mach-versal/cpu.c| 2 +- arch/arm/mach-versal/mp.c | 2 +- arch/arm/mach-zynqmp/Makefile | 2 +- arch/arm/mach-zynqmp/clk.c| 2 +- arch/arm/mach-zynqmp/cpu.c| 2 +- arch/arm/mach-zynqmp/handoff.c| 2 +- arch/arm/mach-zynqmp/include/mach/clk.h | 2 +- arch/arm/mach-zynqmp/include/mach/hardware.h | 2 +- arch/arm/mach-zynqmp/include/mach/sys_proto.h | 2 +- arch/arm/mach-zynqmp/mp.c | 2 +- arch/arm/mach-zynqmp/psu_spl_init.c | 2 +- arch/arm/mach-zynqmp/spl.c| 2 +- arch/microblaze/cpu/spl.c | 2 +- arch/microblaze/cpu/u-boot-spl.lds| 2 +- arch/microblaze/include/asm/spl.h | 2 +- board/xilinx/common/Makefile | 2 +- board/xilinx/common/board.h | 2 +- board/xilinx/common/cpu-info.c| 2 +- board/xilinx/common/fru.h | 2 +- board/xilinx/versal/Makefile | 2 +- board/xilinx/versal/board.c | 2 +- board/xilinx/versal/cmds.c| 2 +- board/xilinx/zynqmp/Makefile | 2 +- board/xilinx/zynqmp/cmds.c| 2 +- board/xilinx/zynqmp/zynqmp.c | 2 +- common/spl/spl_ram.c | 2 +- drivers/ata/sata_ceva.c | 2 +- drivers/clk/clk_versal.c | 2 +- drivers/fpga/versalpl.c | 2 +- drivers/fpga/zynqmppl.c | 4 ++-- drivers
Re: [PATCH] xilinx: zynq: Enable fdt apply utility for zynq
On 7/10/23 13:56, Michal Simek wrote: From: Raju Kumar Pothuraju Enables the FDT library (libfdt) overlay support for zynq platforms to be able to use fdt apply command. Signed-off-by: Raju Kumar Pothuraju Signed-off-by: Michal Simek --- configs/xilinx_zynq_virt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynq_virt_defconfig b/configs/xilinx_zynq_virt_defconfig index 474abc7f6b0b..990057734595 100644 --- a/configs/xilinx_zynq_virt_defconfig +++ b/configs/xilinx_zynq_virt_defconfig @@ -7,6 +7,7 @@ CONFIG_SF_DEFAULT_SPEED=3000 CONFIG_ENV_OFFSET=0xE0 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="zynq-zc706" +CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_SPL_STACK_R_ADDR=0x20 CONFIG_SPL_STACK=0xfe00 CONFIG_SPL=y Applied. M
Re: [PATCH 14/18] board: ti: keys: add .key and .crt for fit signature signing
On 09:32-20230714, Andrew Davis wrote: > On 7/14/23 12:52 AM, Manorit Chawdhry wrote: > > Fit signature mechanism through the standards require the presence of > > .key and .crt in the folder with the same name, since we are using our > > custMpk only for the signing, update the format to that of standards to > > be compatible for packaging easily. > > > > Signed-off-by: Manorit Chawdhry > > --- > > board/ti/keys/custMpk.crt | 33 ++ > > board/ti/keys/custMpk.key | 51 > > +++ > > The key file should be the same as board/ti/keys/custMpk.pem, right? > If so why do we need this new name? > > Also the crt contains information about the person signing the > images, it should be generated at build time from a template, > not provided here in binary format. Certs also have an expiration > data, so this would become invalid at some point. > Yeah, I agree to that, we had to do this initially as there was no other way of packaging it through Yocto but it is better that we clean all this up and keep U-boot as it should be and Yocto part be handled separately. Yocto can generate the cert and the keys as it requires itself so we don't require this patch anymore and will be dropping it so that Yocto can clean that when required to integrate this. > This whole series needs split up, the first half seems like mostly > reasonable cleanups. But the second half I'm not so sure about and > depends on the binman patches. > I am thinking of keeping the FIT_SIGNATURE series on hold as I believe binman is having some changes in that, I can re-roll the other part of the series later, wasn't expecting a lot of changes in binman so had posted this also but will wait till it stabilizes. Manorit > Andrew > > > 2 files changed, 84 insertions(+) > > > > diff --git a/board/ti/keys/custMpk.crt b/board/ti/keys/custMpk.crt > > new file mode 100644 > > index ..01bd64aae577 > > --- /dev/null > > +++ b/board/ti/keys/custMpk.crt > > @@ -0,0 +1,33 @@ > > +-BEGIN CERTIFICATE- > > +MIIFwzCCA6sCFHKW0ueol0+vsilVaZyqKhppo9ryMA0GCSqGSIb3DQEBCwUAMIGd > > +MQswCQYDVQQGEwJVUzELMAkGA1UECAwCVFgxDzANBgNVBAcMBkRhbGxhczEnMCUG > > +A1UECgweVGV4YXMgSW5zdHJ1bWVudHMgSW5jb3Jwb3JhdGVkMRMwEQYDVQQLDApQ > > +cm9jZXNzb3JzMRMwEQYDVQQDDApUSSBTdXBwb3J0MR0wGwYJKoZIhvcNAQkBFg5z > > +dXBwb3J0QHRpLmNvbTAeFw0yMzA2MDEwNTIxMTZaFw0zMzA1MjkwNTIxMTZaMIGd > > +MQswCQYDVQQGEwJVUzELMAkGA1UECAwCVFgxDzANBgNVBAcMBkRhbGxhczEnMCUG > > +A1UECgweVGV4YXMgSW5zdHJ1bWVudHMgSW5jb3Jwb3JhdGVkMRMwEQYDVQQLDApQ > > +cm9jZXNzb3JzMRMwEQYDVQQDDApUSSBTdXBwb3J0MR0wGwYJKoZIhvcNAQkBFg5z > > +dXBwb3J0QHRpLmNvbTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAL8U > > +rknYf3LTayPN60gOZdwiTfIOT4L27bXy3dt8kfpuWf/V97beBB2KzNKV2dHgxMH4 > > +UL//SAyRIlCaTHuL85YKKCazpNngqVVBGvs+Wydsv8rAca8vciLuRgElYq0+xwT2 > > +sRi2LMASbg/imz7lpqCoBkUDQRdOFh+pdNaETtZ5pxC4EakOkh8l3X+x8tG58mjY > > +M1lLgn13zNGc+iO0+1iI8s3q1RbyLHUt+mLDwQlu4AZw4LUHCZli2dbk52xtyIIH > > +UJP34tjt0V/j0J7Pk1TZX91dzjdg8asUigR7Zae6f99FRXxLoVuuTsaUPYxOh9KU > > +PKTzn9r88jZ85w2tWkI38SqB0G6hp2cDHoftALtzSmgoMaKCmqMEweiH/0V+qsGf > > +1DsFx4P9IXH+vX84yRYZUg7mAzONHR7JNhzNTp2CKYjNmyq+bF97srI6eQBqffWt > > +Gp0ezVgqz170ToCrO0/d+NTeNKLEINlZGS2FAl4faLFMjbkRBuktdrVYjFCoN25m > > +eG+DMEZNNJ+0GEq5u/p7xa7WMhCEhGw/moAzNfxNvNVuYFRQz35tgJcE+o8LIP29 > > +mCuhN71Z/UrsRaEJixfJchQztwVeEl3iWh3OIVT24erVVaon600J3xlAgi5miRdl > > +2W6z1jhOjWEW1nTU3hZfURnVQriD0sjeS6lpl7aNAgMBAAEwDQYJKoZIhvcNAQEL > > +BQADggIBAHy+h1FQKedFTJWgqGJkTwtcym5LyXD6ig8LyhJpVEbXmqK7ZKY2F2hB > > +PqVbfCZNogszIvl8q3ykz+tcGbfBk3rq+KMUwbk5E29mSMmAJ9DNNozudgKkKq9w > > +RmcO1bXCEspFgNvNEkYAQCBvMOyH/nCyFu9QzOzN35XIzf0fI3jM6rueLxSXq3xO > > +7yHUZ3mzAZp6e1Qo6cuABAw1q6KqKYJCnJ3Nq6F42bmGp8mSD+2AuGV8cU+7Z3sh > > +k/ooFMCsulj1R5+TlKgEfqspQXbefEsvRW3n3ZD8bcQF0ytiX7XVmDMFVpQkTzps > > +92fjZ08Zcj7bCZQsFXXACIQkMiTiiMW6NwLFZDyq11/B1oe1bhjFUuqqUkHC/PKx > > +gdWRwluGRt+onFRD5/upXnugKT99j/hQ7sy80a64A1xoCcKVbwcHU7YBQG1vLk6D > > +idg0vI3gj7v+/jZEPkv/KrqAI6YuvpplkcHkEKuAUFAkozvVJ5pPK3K0xHBJGNMK > > +kJ9FMAakFj6jfZaR5Ay3ZuOAn5oPMwd6RaauNOzVpBll6DFOyw2rU6fbId/gi841 > > +drmBfM6ufue6ecslkp9zSOpPLXhjt2g9NRVKPE20CmRetVSDLcMFet7ZImbxqggw > > +yjDxA7oR+Px+o+xr+djcDlfj6500Rys6W1SNHe99HXOCcpQqivX0 > > +-END CERTIFICATE- > > diff --git a/board/ti/keys/custMpk.key b/board/ti/keys/custMpk.key > > new file mode 100644 > > index ..adba378c8008 > > --- /dev/null > > +++ b/board/ti/keys/custMpk.key > > @@ -0,0 +1,51 @@ > > +-BEGIN RSA PRIVATE KEY- > > +MIIJKQIBAAKCAgEAvxSuSdh/ctNrI83rSA5l3CJN8g5PgvbttfLd23yR+m5Z/9X3 > > +tt4EHYrM0pXZ0eDEwfhQv/9IDJEiUJpMe4vzlgooJrOk2eCpVUEa+z5bJ2y/ysBx > > +ry9yIu5GASVirT7HBPaxGLYswBJuD+KbPuWmoKgGRQNBF04WH6l01oRO1nmnELgR > > +qQ6SHyXdf7Hy0bnyaNgzWUuCfXfM0Zz6I7T7WIjyzerVFvIsdS36YsPBCW7gBnDg > > +tQcJmWLZ1uTnbG3IggdQk/fi2O3RX+PQns+TVNlf3V3ON2DxqxSKBHtlp7p/30VF > > +fEuhW65OxpQ9jE6H0pQ8pPOf2vzyNnznDa1aQjfxKoHQbqGnZwMeh+0Au3NKaCgx > > +ooKaowTB6If/RX6qwZ/UOwXHg/0hcf69fzjJFhlSDuYDM40dHsk2HM1OnYI
Re: [PATCH v4 0/4] SPL NVMe support
On Wed, 2023-07-12 at 13:12 -0400, Tom Rini wrote:
> On Wed, Jul 12, 2023 at 03:27:45PM +0200, Heinrich Schuchardt wrote:
> > On 12.07.23 15:06, mchit...@ventanamicro.com wrote:
> > > Hi Tom,
> > >
> > > On Tue, 2023-06-20 at 09:37 -0400, Tom Rini wrote:
> > > > On Sat, 03 Jun 2023 19:32:52 +0530, Mayuresh Chitale wrote:
> > > >
> > > > > This patchset adds support to load images of the SPL's next
> > > > > booting
> > > > > stage from a NVMe device.
> > > > >
> > > > > Changes in v4:
> > > > > - Drop patch 4
> > > > > - Modify patch 2 to use generic fs.h APIs
> > > > >
> > > > > [...]
> > > >
> > > > With one change, which is that the "disk/part.c" in 4/4 were
> > > > not
> > > > required for
> > > > any platform in tree and also broke testcases, and so was
> > > > dropped,
> > > > this has now
> > > > been applied to u-boot/next. If you can explain a bit more what
> > > > the
> > > > problem you
> > > > had was, we can look in to it. I suspect you need to test for
> > > > not
> > > > SPL_ENV_SUPPORT but ENV_SUPPORT itself.
> > > >
> > > Thanks.
> > > When SPL_NVME is enabled the build breaks with the following
> > > error:
> > > riscv64-unknown-linux-gnu-ld.bfd: disk/part.o: in function
> > > `blk_get_device_part_str':
> > > u-boot/disk/part.c:473: undefined reference to `env_get'
> > > make[2]: *** [u-boot/scripts/Makefile.spl:527: spl/u-boot-spl]
> > > Error 1
> > > make[1]: *** [/u-boot/Makefile:2053: spl/u-boot-spl] Error 2
> > >
> > > One possible fix is:
> > >
> > > if ((!IS_ENABLED(CONFIG_SPL) && IS_ENABLED(CONFIG_ENV_SUPPORT))
> > > ||
> > > (IS_ENABLED(CONFIG_SPL) &&
> > > IS_ENABLED(CONFIG_SPL_ENV_SUPPORT)))
> > > if (!dev_part_str || !strlen(dev_part_str)
> > > > > !strcmp(dev_part_str, "-"))
> > > dev_part_str = env_get("bootdevice");
> > >
> > >
> >
> > I think CONFIG_SPL_ENV_SUPPORT should depend on CONFIG_ENV_SUPPORT
> > in
> > common/spl/Kconfig.
>
> Not strictly, but checking for CONFIG_IS_ENABLED(ENV_SUPPORT) should
> do
> what's desired here?
When SPL_NVME & SPL_BLK_FS is enabled, the spl_blk_fs driver calls
fs_set_blk_dev to the set the device & partition before accessing it
and fs_set_blk_dev internally tries to get the device & partition from
the bootdevice env variable if it was not passed by the caller. However
for SPL build, when SPL_ENV_SUPPORT is not enabled nothing provides
env_get and hence the build fails.
Re: [PATCH 12/18] include: armv7: Enable distroboot across all configs
Hi Simon, On 17:40-20230715, Simon Glass wrote: > Hi Manorit, > > On Thu, 13 Jul 2023 at 23:54, Manorit Chawdhry wrote: > > > > Since K3 devices are moving towards distroboot, remove duplicates and > > add it in common file to import from. > > > > Signed-off-by: Manorit Chawdhry > > --- > > include/configs/am62ax_evm.h | 71 > > --- > > include/configs/am62x_evm.h | 27 --- > > include/configs/j721e_evm.h | 31 - > > include/configs/j721s2_evm.h | 3 -- > > include/configs/ti_armv7_common.h | 50 +++ > > 5 files changed, 50 insertions(+), 132 deletions(-) > > Can you use standard boot instead? > > [..] > > > diff --git a/include/configs/ti_armv7_common.h > > b/include/configs/ti_armv7_common.h > > index 149a74d98e8a..dbbeff34ba82 100644 > > --- a/include/configs/ti_armv7_common.h > > +++ b/include/configs/ti_armv7_common.h > > @@ -154,4 +154,54 @@ > > #define NETARGS "" > > #endif > > > > +#ifdef CONFIG_ARM64 > > +#ifdef CONFIG_DISTRO_DEFAULTS > > +#ifdef CONFIG_CMD_PXE > > +# define BOOT_TARGET_PXE(func) func(PXE, pxe, na) > > +#else > > +# define BOOT_TARGET_PXE(func) > > +#endif > > + > > +#ifdef CONFIG_CMD_DHCP > > +# define BOOT_TARGET_DHCP(func) func(DHCP, dhcp, na) > > +#else > > +# define BOOT_TARGET_DHCP(func) > > +#endif > > + > > +#ifdef CONFIG_CMD_MMC > > +#define BOOT_TARGET_MMC(func) \ > > + func(TI_MMC, ti_mmc, na) \ > > + func(MMC, mmc, 0) \ > > + func(MMC, mmc, 1) > > +#else > > +#define BOOT_TARGET_MMC(func) > > +#endif > > + > > +#define BOOTENV_DEV_TI_MMC(devtypeu, devtypel, instance) > > + > > +#define BOOTENV_DEV_NAME_TI_MMC(devtyeu, devtypel, instance) \ > > + "ti_mmc " > > + > > +#ifdef CONFIG_CMD_USB > > +# define BOOT_TARGET_USB(func) func(USB, usb, 0) > > +#else > > +# define BOOT_TARGET_USB(func) > > +#endif > > + > > +#define BOOT_TARGET_DEVICES(func) \ > > + BOOT_TARGET_MMC(func) \ > > + BOOT_TARGET_USB(func) \ > > + BOOT_TARGET_PXE(func) \ > > + BOOT_TARGET_DHCP(func) > > + > > +#include > > With standard boot you should be able to drop all of the above, since > the normal order is mmc, usb, pxe, dhcp by default. But you can add a > "boot_targets" env var if you like. > > The one exception is TI_MMC. What is that, exactly? > TI_MMC is our custom boot mechanism that we actually support as a part of our SDK, we had been using this in am62ax like the way I have done here, am not really sure why we hooked it into the distroboot if that is the question that you are asking, maybe Nishanth/Bryan can help with that as Bryan had done it for am62ax [0] but we do this boot mechanism for sure. [0]: https://lore.kernel.org/u-boot/20221224011525.4696-5...@ti.com/ Regards, Manorit > > + > > +/* Incorporate settings into the U-Boot environment */ > > +#define CFG_EXTRA_ENV_SETTINGS \ > > + BOOTENV > > + > > +#endif > > + > > +#endif /* CONFIG_ARM64 */ > > + > > #endif /* __CONFIG_TI_ARMV7_COMMON_H__ */ > > > > -- > > 2.40.1 > > > > Regards, > Simon
Re: [PATCH 03/18] board: ti: am64x: am64x.env: set fdtfile env variable
On 14/07/23 11:22, Manorit Chawdhry wrote: From: Kamlesh Gurudasani Set fdtfile env variable similar to other k3 socs. Signed-off-by: Kamlesh Gurudasani Signed-off-by: Manorit Chawdhry --- board/ti/am64x/am64x.env | 1 + 1 file changed, 1 insertion(+) Reviewed-by: Nikhil M Jain
Re: [PATCH v7 05/23] j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
Hi Nishanth On 17/07/23 11:41, Neha Malcom Francis wrote: Hi Nishanth, On 15/07/23 12:00, Neha Malcom Francis wrote: Hi Nishanth On 15/07/23 11:44, Nishanth Menon wrote: On 19:20-20230714, Neha Malcom Francis wrote: Since you are going to respin anyways, I will complain about this: +#ifdef CONFIG_TARGET_J721E_A72_EVM + +#define SPL_NODTB "spl/u-boot-spl-nodtb.bin" +#define SPL_J721E_EVM_DTB "spl/dts/k3-j721e-common-proc-board.dtb" +#define SPL_J721E_SK_DTB "spl/dts/k3-j721e-sk.dtb" + +#define UBOOT_NODTB "u-boot-nodtb.bin" +#define J721E_EVM_DTB "arch/arm/dts/k3-j721e-common-proc-board.dtb" +#define J721E_SK_DTB "arch/arm/dts/k3-j721e-sk.dtb" + I was trying to add beaglebone-ai64 support and discovered that this messes the reuse of j721e-binman.dtsi for ai64. I am forced to introduce j721e-sk.dtb - so why not just use SPL_NODTB SPL_J721E_BOARD_DTB, UBOOT_NODTB J721E_EVM_BOARD_DTB (generic names) and drop the specific sk stuff? And define the macros in the board.dtsi prior to including the files? I can do that, yes. Thanks for catching this. I'd like to just bring up that this would mean that the same A72 build and binaries will no longer work for both EVM and SK, rather will have to modify the CONFIG_DEFAULT_DEVICE_TREE for each. I am okay with this, but just putting it out there. An even better way would be to use the binman substitutions feature in FIT [1] to resolve both the beaglebone-ai64 not needing to have j721e-sk.dtb as well as continue having the same defconfig build supporting both J721E EVM as well as SK. I will work on this approach first. [1] https://u-boot.readthedocs.io/en/latest/develop/package/entries.html#substitutions -- Thanking You Neha Malcom Francis
Re: [PATCH] pci: Fix device_find_first_child() return value handling
Hello,
On Sun, Jul 16, 2023 at 05:53:24PM +0200, Marek Vasut wrote:
> This function only ever returns 0, but may not assign the second
> parameter. Same thing for device_find_next_child(). Do not assign
> ret to stop proliferation of this misuse.
>
> Reported-by: Jonas Karlman
> Signed-off-by: Marek Vasut
> ---
> Cc: "Pali Rohár"
> Cc: Bin Meng
> Cc: Marek Vasut
> Cc: Michal Suchanek
> Cc: Simon Glass
> ---
> drivers/pci/pci-uclass.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> index 8d27e40338c..6421eda7721 100644
> --- a/drivers/pci/pci-uclass.c
> +++ b/drivers/pci/pci-uclass.c
> @@ -545,9 +545,9 @@ int pci_auto_config_devices(struct udevice *bus)
> sub_bus = dev_seq(bus);
> debug("%s: start\n", __func__);
> pciauto_config_init(hose);
> - for (ret = device_find_first_child(bus, &dev);
> - !ret && dev;
> - ret = device_find_next_child(&dev)) {
> + for (device_find_first_child(bus, &dev);
> + dev;
> + device_find_next_child(&dev)) {
Sounds like you will need to remove the declaration of the now unused ret
variable as well.
More generally, what is the overall vision for these functions returning
always zero?
Should the return value be kept in case the underlying implementation
changes and errors can happen in the future, and consequently checked?
Should the return value be removed when meaningless making these
useless assignments and checks an error?
I already elimimnated a return value where using it lead to incorrect
behavior but here using it or not is equally correct with the current
implementation.
Thanks
Michal
[PATCH v6 3/3] binman: Add tests for etype encrypted
From: Christian Taedcke
Add tests to reach 100% code coverage for the added etype encrypted.
Signed-off-by: Christian Taedcke
---
(no changes since v5)
Changes in v5:
- add comments to test functions
Changes in v4:
- fix failing test testEncryptedKeyFile
Changes in v3:
- rebase on u-boot-dm/mkim-working
- remove unnecessary test testEncryptedNoContent
- wrap some lines at 80 cols
Changes in v2:
- adapt tests for changed entry implementation
tools/binman/ftest.py | 58 +++
tools/binman/test/291_encrypted_no_algo.dts | 15 +
.../test/292_encrypted_invalid_iv_file.dts| 18 ++
.../binman/test/293_encrypted_missing_key.dts | 23
.../binman/test/294_encrypted_key_source.dts | 24
tools/binman/test/295_encrypted_key_file.dts | 24
6 files changed, 162 insertions(+)
create mode 100644 tools/binman/test/291_encrypted_no_algo.dts
create mode 100644 tools/binman/test/292_encrypted_invalid_iv_file.dts
create mode 100644 tools/binman/test/293_encrypted_missing_key.dts
create mode 100644 tools/binman/test/294_encrypted_key_source.dts
create mode 100644 tools/binman/test/295_encrypted_key_file.dts
diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index e53181afb7..f1757ec21f 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -94,6 +94,8 @@ ROCKCHIP_TPL_DATA = b'rockchip-tpl'
TEST_FDT1_DATA= b'fdt1'
TEST_FDT2_DATA= b'test-fdt2'
ENV_DATA = b'var1=1\nvar2="2"'
+ENCRYPTED_IV_DATA = b'123456'
+ENCRYPTED_KEY_DATA= b'abcde'
PRE_LOAD_MAGIC= b'UBSH'
PRE_LOAD_VERSION = 0x11223344.to_bytes(4, 'big')
PRE_LOAD_HDR_SIZE = 0x1000.to_bytes(4, 'big')
@@ -226,6 +228,10 @@ class TestFunctional(unittest.TestCase):
# Newer OP_TEE file in v1 binary format
cls.make_tee_bin('tee.bin')
+# test files for encrypted tests
+TestFunctional._MakeInputFile('encrypted-file.iv', ENCRYPTED_IV_DATA)
+TestFunctional._MakeInputFile('encrypted-file.key', ENCRYPTED_KEY_DATA)
+
cls.comp_bintools = {}
for name in COMP_BINTOOLS:
cls.comp_bintools[name] = bintool.Bintool.create(name)
@@ -6884,6 +6890,58 @@ fdt fdtmapExtract the devicetree
blob from the fdtmap
# Move to next
spl_data = content[:0x18]
+def testEncryptedNoAlgo(self):
+"""Test encrypted node with missing required properties"""
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('291_encrypted_no_algo.dts')
+self.assertIn(
+"Node '/binman/fit/images/u-boot/encrypted': 'encrypted' entry is
missing properties: algo iv-filename",
+str(e.exception))
+
+def testEncryptedInvalidIvfile(self):
+"""Test encrypted node with invalid iv file"""
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('292_encrypted_invalid_iv_file.dts')
+self.assertIn("Filename 'invalid-iv-file' not found in input path",
+ str(e.exception))
+
+def testEncryptedMissingKey(self):
+"""Test encrypted node with missing key properties"""
+with self.assertRaises(ValueError) as e:
+self._DoReadFileDtb('293_encrypted_missing_key.dts')
+self.assertIn(
+"Node '/binman/fit/images/u-boot/encrypted': Provide either
'key-filename' or 'key-source'",
+str(e.exception))
+
+def testEncryptedKeySource(self):
+"""Test encrypted node with key-source property"""
+data = self._DoReadFileDtb('294_encrypted_key_source.dts')[0]
+
+dtb = fdt.Fdt.FromData(data)
+dtb.Scan()
+
+node = dtb.GetNode('/images/u-boot/cipher')
+self.assertEqual('algo-name', node.props['algo'].value)
+self.assertEqual('key-source-value', node.props['key-source'].value)
+self.assertEqual(ENCRYPTED_IV_DATA,
+ tools.to_bytes(''.join(node.props['iv'].value)))
+self.assertNotIn('key', node.props)
+
+def testEncryptedKeyFile(self):
+"""Test encrypted node with key-filename property"""
+data = self._DoReadFileDtb('295_encrypted_key_file.dts')[0]
+
+dtb = fdt.Fdt.FromData(data)
+dtb.Scan()
+
+node = dtb.GetNode('/images/u-boot/cipher')
+self.assertEqual('algo-name', node.props['algo'].value)
+self.assertEqual(ENCRYPTED_IV_DATA,
+ tools.to_bytes(''.join(node.props['iv'].value)))
+self.assertEqual(ENCRYPTED_KEY_DATA,
+ tools.to_bytes(''.join(node.props['key'].value)))
+self.assertNotIn('key-source', node.props)
+
if __name__ == "__main__":
unittest.main()
diff --git a/tools/binman/test/291_encrypted_no_algo.dts
b/tools/binman/test/291_encrypted_no_algo.dts
new file mode 100644
index 00..03f7ffee90
--- /dev/null
+++ b/tools/binman/test/291_e
[PATCH v6 1/3] binman: Add support for externally encrypted blobs
From: Christian Taedcke
This adds a new etype encrypted.
It creates a new cipher node in the related image similar to the
cipher node used by u-boot, see boot/image-cipher.c.
Signed-off-by: Christian Taedcke
---
Changes in v6:
- fix documentation of encrypted etype
Changes in v5:
- encrypted entry now inherits from Entry
- remove unnecessary methods ObtainContents and ProcessContents
Changes in v3:
- rebase on u-boot-dm/mkim-working
- update doc for functions ObtainContents and ProcessContents
- update entries.rst
Changes in v2:
- add entry documentation
- remove global /cipher node
- replace key-name-hint with key-source property
tools/binman/entries.rst| 86
tools/binman/etype/encrypted.py | 138
2 files changed, 224 insertions(+)
create mode 100644 tools/binman/etype/encrypted.py
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b55f424620..cb4bdab613 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -468,6 +468,92 @@ updating the EC on startup via software sync.
+.. _etype_encrypted:
+
+Entry: encrypted: Externally built encrypted binary blob
+
+
+This entry provides the functionality to include information about how to
+decrypt an encrypted binary. This information is added to the
+resulting device tree by adding a new cipher node in the entry's parent
+node (i.e. the binary).
+
+The key that must be used to decrypt the binary is either directly embedded
+in the device tree or indirectly by specifying a key source. The key source
+can be used as an id of a key that is stored in an external device.
+
+Using an embedded key
+~
+
+This is an example using an embedded key::
+
+blob-ext {
+filename = "encrypted-blob.bin";
+};
+
+encrypted {
+algo = "aes256-gcm";
+iv-filename = "encrypted-blob.bin.iv";
+key-filename = "encrypted-blob.bin.key";
+};
+
+This entry generates the following device tree structure form the example
+above::
+
+data = [...]
+cipher {
+algo = "aes256-gcm";
+key = <0x...>;
+iv = <0x...>;
+};
+
+The data property is generated by the blob-ext etype, the cipher node and
+its content is generated by this etype.
+
+Using an external key
+~
+
+Instead of embedding the key itself into the device tree, it is also
+possible to address an externally stored key by specifying a 'key-source'
+instead of the 'key'::
+
+blob-ext {
+filename = "encrypted-blob.bin";
+};
+
+encrypted {
+algo = "aes256-gcm";
+iv-filename = "encrypted-blob.bin.iv";
+key-source = "external-key-id";
+};
+
+This entry generates the following device tree structure form the example
+above::
+
+data = [...]
+cipher {
+algo = "aes256-gcm";
+key-source = "external-key-id";
+iv = <0x...>;
+};
+
+Properties
+~~
+
+Properties / Entry arguments:
+- algo: The encryption algorithm. Currently no algorithm is supported
+out-of-the-box. Certain algorithms will be added in future
+patches.
+- iv-filename: The name of the file containing the initialization
+ vector (in short iv). See
+ https://en.wikipedia.org/wiki/Initialization_vector
+- key-filename: The name of the file containing the key. Either
+key-filename or key-source must be provided.
+- key-source: The key that should be used. Either key-filename or
+ key-source must be provided.
+
+
+
.. _etype_fdtmap:
Entry: fdtmap: An entry which contains an FDT map
diff --git a/tools/binman/etype/encrypted.py b/tools/binman/etype/encrypted.py
new file mode 100644
index 00..53d0e76bab
--- /dev/null
+++ b/tools/binman/etype/encrypted.py
@@ -0,0 +1,138 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright 2023 Weidmüller Interface GmbH & Co. KG
+# Written by Christian Taedcke
+#
+# Entry-type module for cipher information of encrypted blobs/binaries
+#
+
+from binman.etype.collection import Entry
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+# This is imported if needed
+state = None
+
+
+class Entry_encrypted(Entry):
+"""Externally built encrypted binary blob
+
+This entry provides the functionality to include information about how to
+decrypt an encrypted binary. This information is added to the
+resulting device tree by adding a new cipher node in the entry's parent
+node (i.e. the binary).
+
+The key that must be used to decrypt the binary is either directly embedded
+in the device tree or indirectly by specifying a key source. The key source
+can be used as an id of a key that is stored in an external device.
+
+Using an embedded key
+~
+
+This is an example using an embedded key::
+
+blob-e
[PATCH v6 2/3] binman: Allow cipher node as special section
From: Christian Taedcke
The new encrypted etype generates a cipher node in the device tree
that should not be evaluated by binman, but still be kept in the
output device tree.
Signed-off-by: Christian Taedcke
---
(no changes since v3)
Changes in v3:
- rebase on u-boot-dm/mkim-working
tools/binman/etype/section.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index 7c4d312c16..fb49e85a76 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -179,7 +179,7 @@ class Entry_section(Entry):
Returns:
bool: True if the node is a special one, else False
"""
-start_list = ('hash', 'signature', 'template')
+start_list = ('cipher', 'hash', 'signature', 'template')
return any(node.name.startswith(name) for name in start_list)
def ReadNode(self):
--
2.34.1
[PATCH v6 0/3] binman: Add support for externally encrypted blobs
From: Christian Taedcke
This series adds the functionality to handle externally encrypted
blobs to binman. It includes the functionality itself and the
corresponding unit tests.
The following block shows an example on how to use this functionality.
In the device tree that is parsed by binman a new node encrypted is
used:
/ {
binman {
filename = "u-boot.itb";
fit {
...
images {
some-bitstream {
...
image_bitstream: blob-ext {
filename = "bitstream.bin";
};
encrypted {
content = <&image_bitstream>;
algo = "aes256-gcm";
iv-filename =
"bitstream.bin.iv";
key-filename =
"bitstream.bin.key";
};
...
This results in an generated fit image containing the following
information:
\ {
images {
...
some-bitstream {
...
data = [...]
cipher {
algo = "aes256-gcm";
key = <0x...>;
iv = <0x...>;
};
};
...
I tried to rename the added entry to cipher or ciphered, but it did
not work. The issue is that the 'cipher' node is added as a special
section, so it appears in the created device tree.
So any etype that starts with 'cipher' is not evaluated at all,
because it is a special section, see etype/section.py methods
IsSpecialSubnode() and ReadEntries().
Changes in v6:
- fix documentation of encrypted etype
Changes in v5:
- add comments to test functions
- encrypted entry now inherits from Entry
- remove unnecessary methods ObtainContents and ProcessContents
Changes in v4:
- fix failing test testEncryptedKeyFile
Changes in v3:
- rebase on u-boot-dm/mkim-working
- remove unnecessary test testEncryptedNoContent
- update doc for functions ObtainContents and ProcessContents
- update entries.rst
- wrap some lines at 80 cols
Changes in v2:
- adapt tests for changed entry implementation
- add entry documentation
- remove global /cipher node
- replace key-name-hint with key-source property
Christian Taedcke (3):
binman: Add support for externally encrypted blobs
binman: Allow cipher node as special section
binman: Add tests for etype encrypted
tools/binman/entries.rst | 86 +++
tools/binman/etype/encrypted.py | 138 ++
tools/binman/etype/section.py | 2 +-
tools/binman/ftest.py | 58
tools/binman/test/291_encrypted_no_algo.dts | 15 ++
.../test/292_encrypted_invalid_iv_file.dts| 18 +++
.../binman/test/293_encrypted_missing_key.dts | 23 +++
.../binman/test/294_encrypted_key_source.dts | 24 +++
tools/binman/test/295_encrypted_key_file.dts | 24 +++
9 files changed, 387 insertions(+), 1 deletion(-)
create mode 100644 tools/binman/etype/encrypted.py
create mode 100644 tools/binman/test/291_encrypted_no_algo.dts
create mode 100644 tools/binman/test/292_encrypted_invalid_iv_file.dts
create mode 100644 tools/binman/test/293_encrypted_missing_key.dts
create mode 100644 tools/binman/test/294_encrypted_key_source.dts
create mode 100644 tools/binman/test/295_encrypted_key_file.dts
--
2.34.1
