Re: EFI from usb HDD
On 7/30/21 7:33 AM, AKASHI Takahiro wrote: > On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: >> >> >> On 7/30/21 4:35 AM, AKASHI Takahiro wrote: >>> On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: Hi, On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: >> >> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: >>> On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working fine >> as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? > This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 they >> are >> the same. SOM doesn't have usb enabled by default (but I enabled it) >> but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to menu >> and on others there is an issue to get all partitions even u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > could > be that the USB sub-system is simply not initialized yet when the boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is enough > to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers are hexadecimal > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > Block devices are enumerated in efi_disk_register(). Please, try to > add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. >>> >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>> >>> Why is USB initialized later then MMC? >>
Re: EFI from usb HDD
On Fri, Jul 30, 2021 at 06:41:01AM +0200, Michal Simek wrote: > > > On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > > > On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > > On 6/10/21 12:04 PM, Michal Simek wrote: > >> Hi, > >> > >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > >>> On 6/10/21 10:44 AM, Michal Simek wrote: > Hi, > > I am playing with booting from USB via EFI. And I see very weird > behavior. I have burnt image with grub to USB flashdisk and I have > tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > On zcu102 grub is going to boot menu and everything is working fine > as > expected. > On zcu104 and SOM Kria I am able to get grub not to menu. When I list > partitions in grub I see that only SDs are listed: > grub> ls > (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > >>> > >>> Hello Michal, > >>> > >>> thanks for sharing your observations. > >>> > >>> What devices do hd0 and hd1 relate to? > >>> > > On zcu102(working board) I also see usb(gpt) partitions and SD. > grub> ls > (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > > >>> > >>> GPT and MBR partitioning are independent of the device type. > >>> > > On zcu104 I see one more error message > "PE image measurement failed" > >>> > >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? > >>> This > >>> will not stop disk enumeration. > >>> > But I can't see it on SOM. > > U-Boot image is just the same for all boards. I am using generic > xilinx_zynqmp_virt_defconfig. > > When I compare DT description for USB between zcu102 and zcu104 they > are > the same. SOM doesn't have usb enabled by default (but I enabled it) > but > grub starts which means that communication with USB is fine. > > It is based on my latest patches available here. > u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > > Also when I list usb I see all partitions just fine. > ZynqMP> part list usb 0 > > Partition Map for USB device 0 -- Partition Type: EFI > > Part Start LBA End LBA Name > Attributes > Type GUID > Partition GUID > 1 0x0800 0x001007fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > 2 0x00100800 0x001197fe "Microsoft basic data" > attrs: 0x > type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > type: data > guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > > > Do you have any idea why on one system is working fine to get to menu > and on others there is an issue to get all partitions even u-boot is > able to see them and can work with them. > > Thanks, > Michal > > >>> > >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it > >>> could > >>> be that the USB sub-system is simply not initialized yet when the boot > >>> manager is called by distroboot. > >>> > >>> For testing partition detection in the UEFI sub-system it is enough > >>> to run > >>> > >>> efidebug devices > >>> > >>> Until yesterday we had a problem with partition numbers >= 10, cf. > >>> > >>> efi_loader: partition numbers are hexadecimal > >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > >>> > >>> > >>> > >>> Block devices are enumerated in efi_disk_register(). Please, try to > >>> add > >>> debug output there to elucidate the problem. > >> > >> I found where the problem is. First of all zcu102 didn't use the same > >> image as others (it wasn't updated properly). > >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > >> is called before usb block devices are detected and registered that's > >> why grub doesn't see them. > > > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > > > Why is USB initialized later then MMC? > > It is not just usb. SCSI/sata are behavin
RE: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
HI Aswath,
> -Original Message-
> From: Aswath Govindraju
> Sent: Friday, July 30, 2021 10:41 AM
> To: Ashok Reddy Soma
> Cc: Lokesh Vutla ; Vignesh Raghavendra
> ; Kishon Vijay Abraham I ; Peng Fan
> ; Jaehoon Chung ; Simon
> Glass ; Heinrich Schuchardt ; Bin
> Meng ; Patrick Delaunay
> ; Pragnesh Patel ;
> Frédéric Danis ; Reuben Dowle
> ; Yangbo Lu ; Stefan Bosch
> ; Nicolas Saenz Julienne ; Pali
> Rohár ; u-boot@lists.denx.de
> Subject: Re: [PATCH] mmc: Add support for enumerating MMC card in a given
> mode using mmc command
>
> Hi Ashok,
>
> On 30/07/21 10:17 am, Ashok Reddy Soma wrote:
> > Hi Aswath,
> >
> >> -Original Message-
> >> From: Aswath Govindraju
> >> Sent: Thursday, July 29, 2021 8:25 PM
> >> Cc: Lokesh Vutla ; Vignesh Raghavendra
> >> ; Kishon Vijay Abraham I ; Aswath
> >> Govindraju ; Peng Fan ;
> >> Jaehoon Chung ; Simon Glass
> >> ; Heinrich Schuchardt ; Bin
> >> Meng ; Patrick Delaunay
> >> ; Pragnesh Patel
> >> ; Frédéric Danis
> >> ; Reuben Dowle
> >> ; Yangbo Lu ; Stefan
> Bosch
> >> ; Ashok Reddy Soma ;
> >> Nicolas Saenz Julienne ; Pali Rohár
> >> ; u-boot@lists.denx.de
> >> Subject: [PATCH] mmc: Add support for enumerating MMC card in a given
> >> mode using mmc command
> >>
> >> Add support for enumerating MMC card in a given mode using mmc rescan
> >> and mmc dev commands. The speed mode is provided as the last argument
> >> in these commands and is indicated using the index from enum bus_mode
> >> in include/mmc.h. A speed mode can be set only if it has already been
> >> enabled in the device tree.
> >>
> >> Signed-off-by: Aswath Govindraju
> >> ---
> >> cmd/Kconfig | 10 ++
> >> cmd/mmc.c| 71
> >> drivers/mmc/mmc-uclass.c | 3 ++
> >> drivers/mmc/mmc.c| 18 ++
> >> include/mmc.h| 4 +++
> >> 5 files changed, 85 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/cmd/Kconfig b/cmd/Kconfig index
> >> ffef3cc76ca4..3a857b3f6e2e 100644
> >> --- a/cmd/Kconfig
> >> +++ b/cmd/Kconfig
> >> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
> >>help
> >> UBIFS is a file system for flash devices which works on top of UBI.
> >>
> >> +config MMC_SPEED_MODE_SET
> >> + bool "set speed mode using mmc command"
> >> + depends on CMD_MMC
> >> + default n
> >> + help
> >> +Enable setting speed mode using mmc rescan and mmc dev
> >> commands.
> >> +The speed mode is provided as the last argument in these commands
> >> +and is indicated using the index from enum bus_mode in
> >> +include/mmc.h. A speed mode can be set only if it has already
> >> +been enabled in the device tree.
> >> endmenu
> >> diff --git a/cmd/mmc.c b/cmd/mmc.c
> >> index b942576b58ac..073e87d69634 100644
> >> --- a/cmd/mmc.c
> >> +++ b/cmd/mmc.c
> >> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
> >>}
> >>}
> >> }
> >> -static struct mmc *init_mmc_device(int dev, bool force_init)
> >> +
> >> +static struct mmc *init_mmc_device(int dev, bool force_init,
> >> + enum bus_mode speed_mode)
> >> {
> >>struct mmc *mmc;
> >>mmc = find_mmc_device(dev);
> >> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
> >> force_init)
> >>
> >>if (force_init)
> >>mmc->has_init = 0;
> >> +
> >> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
> >> + mmc->user_speed_mode = speed_mode;
> >> +#endif
> >> +
> > Can you please use if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET)
> >
> >>if (mmc_init(mmc))
> >>return NULL;
> >>
> >> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int
> >> flag, int argc,
> >>}
> >>}
> >>
> >> - mmc = init_mmc_device(curr_device, false);
> >> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> >>if (!mmc)
> >>return CMD_RET_FAILURE;
> >>
> >> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int
> flag,
> >>if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
> >>return CMD_RET_SUCCESS;
> >>
> >> - mmc = init_mmc_device(curr_device, false);
> >> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> >>if (!mmc)
> >>return CMD_RET_FAILURE;
> >>
> >> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int
> >> flag,
> >>blk = simple_strtoul(argv[2], NULL, 16);
> >>cnt = simple_strtoul(argv[3], NULL, 16);
> >>
> >> - mmc = init_mmc_device(curr_device, false);
> >> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> >>if (!mmc)
> >>return CMD_RET_FAILURE;
> >>
> >> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl
> >> *cmdtp, int flag,
> >>return CMD_RET_FAILURE;
> >>}
> >>
> >> - mmc = init_mmc_device(curr_device, false);
> >> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> >>if (!mmc)
> >>return CMD_RET_FAILURE;
> >>
> >> @@ -431,7
Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Jaehoon,
On 30/07/21 4:00 am, Jaehoon Chung wrote:
> Hi Aswath,
>
> On 7/29/21 11:55 PM, Aswath Govindraju wrote:
>> Add support for enumerating MMC card in a given mode using mmc rescan and
>> mmc dev commands. The speed mode is provided as the last argument in these
>> commands and is indicated using the index from enum bus_mode in
>> include/mmc.h. A speed mode can be set only if it has already been enabled
>> in the device tree.
>
> Thanks for this patch. It seems that it's useful to develope and debug.
> I will test with this patch.
>
> Could you also update doc/usage/mmc.rst file?
>
Sure, I'll update it in the respin.
Thanks,
Aswath
> Best Regards,
> Jaehoo Chung
>
>>
>> Signed-off-by: Aswath Govindraju
>> ---
>> cmd/Kconfig | 10 ++
>> cmd/mmc.c| 71
>> drivers/mmc/mmc-uclass.c | 3 ++
>> drivers/mmc/mmc.c| 18 ++
>> include/mmc.h| 4 +++
>> 5 files changed, 85 insertions(+), 21 deletions(-)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index ffef3cc76ca4..3a857b3f6e2e 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>> help
>>UBIFS is a file system for flash devices which works on top of UBI.
>>
>> +config MMC_SPEED_MODE_SET
>> +bool "set speed mode using mmc command"
>> +depends on CMD_MMC
>> +default n
>> +help
>> + Enable setting speed mode using mmc rescan and mmc dev commands.
>> + The speed mode is provided as the last argument in these commands
>> + and is indicated using the index from enum bus_mode in
>> + include/mmc.h. A speed mode can be set only if it has already
>> + been enabled in the device tree.
>> endmenu
>> diff --git a/cmd/mmc.c b/cmd/mmc.c
>> index b942576b58ac..073e87d69634 100644
>> --- a/cmd/mmc.c
>> +++ b/cmd/mmc.c
>> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>> }
>> }
>> }
>> -static struct mmc *init_mmc_device(int dev, bool force_init)
>> +
>> +static struct mmc *init_mmc_device(int dev, bool force_init,
>> + enum bus_mode speed_mode)
>> {
>> struct mmc *mmc;
>> mmc = find_mmc_device(dev);
>> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
>> force_init)
>>
>> if (force_init)
>> mmc->has_init = 0;
>> +
>> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
>> +mmc->user_speed_mode = speed_mode;
>> +#endif
>> +
>> if (mmc_init(mmc))
>> return NULL;
>>
>> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag,
>> int argc,
>> }
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
>> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>> return CMD_RET_SUCCESS;
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp,
>> int flag,
>> return CMD_RET_FAILURE;
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int flag,
>> blk = simple_strtoul(argv[1], NULL, 16);
>> cnt = simple_strtoul(argv[2], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -482,8 +489,19 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int
>> flag,
>> int argc, char *const argv[])
>> {
>> struct mmc *mmc;
>> +enum bus_mode speed_mode = MMC_MODES_END;
>> +
>> +if (argc == 1) {
>> +mmc = init_mmc_device(curr_device, true, MMC_MODES_END);
>> +
Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Ashok,
On 30/07/21 10:17 am, Ashok Reddy Soma wrote:
> Hi Aswath,
>
>> -Original Message-
>> From: Aswath Govindraju
>> Sent: Thursday, July 29, 2021 8:25 PM
>> Cc: Lokesh Vutla ; Vignesh Raghavendra
>> ; Kishon Vijay Abraham I ; Aswath
>> Govindraju ; Peng Fan ; Jaehoon
>> Chung ; Simon Glass ;
>> Heinrich Schuchardt ; Bin Meng
>> ; Patrick Delaunay ;
>> Pragnesh Patel ; Frédéric Danis
>> ; Reuben Dowle ;
>> Yangbo Lu ; Stefan Bosch ; Ashok
>> Reddy Soma ; Nicolas Saenz Julienne
>> ; Pali Rohár ; u-boot@lists.denx.de
>> Subject: [PATCH] mmc: Add support for enumerating MMC card in a given
>> mode using mmc command
>>
>> Add support for enumerating MMC card in a given mode using mmc rescan
>> and mmc dev commands. The speed mode is provided as the last argument in
>> these commands and is indicated using the index from enum bus_mode in
>> include/mmc.h. A speed mode can be set only if it has already been enabled in
>> the device tree.
>>
>> Signed-off-by: Aswath Govindraju
>> ---
>> cmd/Kconfig | 10 ++
>> cmd/mmc.c| 71
>> drivers/mmc/mmc-uclass.c | 3 ++
>> drivers/mmc/mmc.c| 18 ++
>> include/mmc.h| 4 +++
>> 5 files changed, 85 insertions(+), 21 deletions(-)
>>
>> diff --git a/cmd/Kconfig b/cmd/Kconfig
>> index ffef3cc76ca4..3a857b3f6e2e 100644
>> --- a/cmd/Kconfig
>> +++ b/cmd/Kconfig
>> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
>> help
>>UBIFS is a file system for flash devices which works on top of UBI.
>>
>> +config MMC_SPEED_MODE_SET
>> +bool "set speed mode using mmc command"
>> +depends on CMD_MMC
>> +default n
>> +help
>> + Enable setting speed mode using mmc rescan and mmc dev
>> commands.
>> + The speed mode is provided as the last argument in these commands
>> + and is indicated using the index from enum bus_mode in
>> + include/mmc.h. A speed mode can be set only if it has already
>> + been enabled in the device tree.
>> endmenu
>> diff --git a/cmd/mmc.c b/cmd/mmc.c
>> index b942576b58ac..073e87d69634 100644
>> --- a/cmd/mmc.c
>> +++ b/cmd/mmc.c
>> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
>> }
>> }
>> }
>> -static struct mmc *init_mmc_device(int dev, bool force_init)
>> +
>> +static struct mmc *init_mmc_device(int dev, bool force_init,
>> + enum bus_mode speed_mode)
>> {
>> struct mmc *mmc;
>> mmc = find_mmc_device(dev);
>> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
>> force_init)
>>
>> if (force_init)
>> mmc->has_init = 0;
>> +
>> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
>> +mmc->user_speed_mode = speed_mode;
>> +#endif
>> +
> Can you please use if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET)
>
>> if (mmc_init(mmc))
>> return NULL;
>>
>> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag,
>> int argc,
>> }
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
>> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
>> return CMD_RET_SUCCESS;
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int
>> flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl
>> *cmdtp, int flag,
>> return CMD_RET_FAILURE;
>> }
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int
>> flag,
>> blk = simple_strtoul(argv[2], NULL, 16);
>> cnt = simple_strtoul(argv[3], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int
>> flag,
>> blk = simple_strtoul(argv[1], NULL, 16);
>> cnt = simple_strtoul(argv[2], NULL, 16);
>>
>> -mmc = init_mmc_device(curr_device, false);
>> +mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
>> if (!mmc)
>> return CMD_RET_FAILURE;
>>
>> @@ -482,8
Re: [PATCH v2 3/3] snow: Enable unit tests
Dear Simon Glass, On Mon, 19 Jul 2021 at 10:03, Simon Glass wrote: > It is useful to have a board with unit tests enabled, to check that this > does not break. > > Let's choose snow, since it is not under active development and it is > glorious. > > Signed-off-by: Simon Glass > Reviewed-by: Jaehoon Chung > --- > > (no changes since v1) > > configs/snow_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/snow_defconfig b/configs/snow_defconfig > index 6090fea2b8f..63a5713a602 100644 > --- a/configs/snow_defconfig > +++ b/configs/snow_defconfig > @@ -92,3 +92,5 @@ CONFIG_VIDEO_BRIDGE_NXP_PTN3460=y > CONFIG_LCD=y > CONFIG_TPM=y > CONFIG_ERRNO_STR=y > +CONFIG_UNIT_TEST=y > +# CONFIG_UT_LIB_ASN1 is not set > -- > 2.32.0.402.g57bb445576-goog > > applied to u-boot-samsung. -- Thanks, Minkyu Kang.
Re: [PATCH v2 2/3] test: Fix size_t formats in strlcat test
Dear Simon Glass,
On Mon, 19 Jul 2021 at 10:02, Simon Glass wrote:
> Some of the printf() formats do not match their types. Fix this.
>
> Reported-by: Minkyu Kang
>
I modified email address to mk7.k...@samsung.com : )
Signed-off-by: Simon Glass
> ---
>
> Changes in v2:
> - Fix some size_t warnings with recent compilers
>
> test/lib/strlcat.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/test/lib/strlcat.c b/test/lib/strlcat.c
> index ee61684c405..a0ec037388b 100644
> --- a/test/lib/strlcat.c
> +++ b/test/lib/strlcat.c
> @@ -48,7 +48,7 @@ static int do_test_strlcat(struct unit_test_state *uts,
> int line, size_t align1,
> if (expected != actual) {
> ut_failf(uts, __FILE__, line, __func__,
> "strlcat(s2, s1, 2) == len2 < n ? min(len1 +
> len2, n) : n",
> -"Expected %#lx (%ld), got %#lx (%ld)",
> +"Expected %#zx (%zd), got %#zx (%zd)",
> expected, expected, actual, actual);
> return CMD_RET_FAILURE;
> }
> @@ -66,7 +66,7 @@ static int do_test_strlcat(struct unit_test_state *uts,
> int line, size_t align1,
> if (len2 < n && s2[i] != '\0') {
> ut_failf(uts, __FILE__, line, __func__,
> "n < len1 && s2[len2 + n] == '\\0'",
> -"Expected s2[%ld] = '\\0', got %d ('%c')",
> +"Expected s2[%zd] = '\\0', got %d ('%c')",
> i, s2[i], s2[i]);
> return CMD_RET_FAILURE;
> }
> --
> 2.32.0.402.g57bb445576-goog
>
>
applied to u-boot-samsung.
--
Thanks,
Minkyu Kang.
Re: [PATCH v2 1/3] samsung: exynos: Convert SROMC interface to a driver
Dear Simon Glass, On Mon, 19 Jul 2021 at 10:03, Simon Glass wrote: > Add a bus driver for this and use it to configure the bus parameters for > the Ethernet interface. Drop the old pre-driver-model code. > > Switch over to use driver model for Ethernet. > > Signed-off-by: Simon Glass > Reviewed-by: Jaehoon Chung > --- > > (no changes since v1) > > arch/arm/Kconfig | 1 + > arch/arm/dts/exynos5250-smdk5250.dts | 1 + > arch/arm/mach-exynos/include/mach/sromc.h | 18 -- > board/samsung/common/Makefile | 2 +- > board/samsung/common/board.c | 78 --- > board/samsung/common/sromc.c | 76 ++ > board/samsung/smdkv310/smdkv310.c | 9 --- > configs/arndale_defconfig | 1 - > configs/odroid-xu3_defconfig | 1 - > configs/peach-pi_defconfig| 1 - > configs/peach-pit_defconfig | 1 - > configs/smdk5250_defconfig| 1 - > configs/smdk5420_defconfig| 1 - > configs/smdkv310_defconfig| 1 - > configs/snow_defconfig| 1 - > configs/spring_defconfig | 1 - > include/fdtdec.h | 2 - > lib/fdtdec.c | 2 - > 18 files changed, 79 insertions(+), 119 deletions(-) > create mode 100644 board/samsung/common/sromc.c > > applied to u-boot-samsung. -- Thanks, Minkyu Kang.
RE: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Aswath,
> -Original Message-
> From: Aswath Govindraju
> Sent: Thursday, July 29, 2021 8:25 PM
> Cc: Lokesh Vutla ; Vignesh Raghavendra
> ; Kishon Vijay Abraham I ; Aswath
> Govindraju ; Peng Fan ; Jaehoon
> Chung ; Simon Glass ;
> Heinrich Schuchardt ; Bin Meng
> ; Patrick Delaunay ;
> Pragnesh Patel ; Frédéric Danis
> ; Reuben Dowle ;
> Yangbo Lu ; Stefan Bosch ; Ashok
> Reddy Soma ; Nicolas Saenz Julienne
> ; Pali Rohár ; u-boot@lists.denx.de
> Subject: [PATCH] mmc: Add support for enumerating MMC card in a given
> mode using mmc command
>
> Add support for enumerating MMC card in a given mode using mmc rescan
> and mmc dev commands. The speed mode is provided as the last argument in
> these commands and is indicated using the index from enum bus_mode in
> include/mmc.h. A speed mode can be set only if it has already been enabled in
> the device tree.
>
> Signed-off-by: Aswath Govindraju
> ---
> cmd/Kconfig | 10 ++
> cmd/mmc.c| 71
> drivers/mmc/mmc-uclass.c | 3 ++
> drivers/mmc/mmc.c| 18 ++
> include/mmc.h| 4 +++
> 5 files changed, 85 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ffef3cc76ca4..3a857b3f6e2e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
> help
> UBIFS is a file system for flash devices which works on top of UBI.
>
> +config MMC_SPEED_MODE_SET
> + bool "set speed mode using mmc command"
> + depends on CMD_MMC
> + default n
> + help
> + Enable setting speed mode using mmc rescan and mmc dev
> commands.
> + The speed mode is provided as the last argument in these commands
> + and is indicated using the index from enum bus_mode in
> + include/mmc.h. A speed mode can be set only if it has already
> + been enabled in the device tree.
> endmenu
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index b942576b58ac..073e87d69634 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
> }
> }
> }
> -static struct mmc *init_mmc_device(int dev, bool force_init)
> +
> +static struct mmc *init_mmc_device(int dev, bool force_init,
> +enum bus_mode speed_mode)
> {
> struct mmc *mmc;
> mmc = find_mmc_device(dev);
> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
> force_init)
>
> if (force_init)
> mmc->has_init = 0;
> +
> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
> + mmc->user_speed_mode = speed_mode;
> +#endif
> +
Can you please use if (IS_ENABLED(CONFIG_MMC_SPEED_MODE_SET)
> if (mmc_init(mmc))
> return NULL;
>
> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag,
> int argc,
> }
> }
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
> return CMD_RET_SUCCESS;
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int
> flag,
> blk = simple_strtoul(argv[2], NULL, 16);
> cnt = simple_strtoul(argv[3], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl
> *cmdtp, int flag,
> return CMD_RET_FAILURE;
> }
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int
> flag,
> blk = simple_strtoul(argv[2], NULL, 16);
> cnt = simple_strtoul(argv[3], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int
> flag,
> blk = simple_strtoul(argv[1], NULL, 16);
> cnt = simple_strtoul(argv[2], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -482,8 +489,19 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int
> flag,
>int argc, char *const argv[])
>
Re: EFI from usb HDD
On 7/30/21 4:35 AM, AKASHI Takahiro wrote: > On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: >> Hi, >> >> On 6/10/21 2:59 PM, AKASHI Takahiro wrote: >>> On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > On 6/10/21 12:04 PM, Michal Simek wrote: >> Hi, >> >> On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: >>> On 6/10/21 10:44 AM, Michal Simek wrote: Hi, I am playing with booting from USB via EFI. And I see very weird behavior. I have burnt image with grub to USB flashdisk and I have tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. On zcu102 grub is going to boot menu and everything is working fine as expected. On zcu104 and SOM Kria I am able to get grub not to menu. When I list partitions in grub I see that only SDs are listed: grub> ls (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) >>> >>> Hello Michal, >>> >>> thanks for sharing your observations. >>> >>> What devices do hd0 and hd1 relate to? >>> On zcu102(working board) I also see usb(gpt) partitions and SD. grub> ls (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >>> >>> GPT and MBR partitioning are independent of the device type. >>> On zcu104 I see one more error message "PE image measurement failed" >>> >>> This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This >>> will not stop disk enumeration. >>> But I can't see it on SOM. U-Boot image is just the same for all boards. I am using generic xilinx_zynqmp_virt_defconfig. When I compare DT description for USB between zcu102 and zcu104 they are the same. SOM doesn't have usb enabled by default (but I enabled it) but grub starts which means that communication with USB is fine. It is based on my latest patches available here. u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) Also when I list usb I see all partitions just fine. ZynqMP> part list usb 0 Partition Map for USB device 0 -- Partition Type: EFI Part Start LBA End LBA Name Attributes Type GUID Partition GUID 1 0x0800 0x001007fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 2 0x00100800 0x001197fe "Microsoft basic data" attrs: 0x type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 type: data guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 Do you have any idea why on one system is working fine to get to menu and on others there is an issue to get all partitions even u-boot is able to see them and can work with them. Thanks, Michal >>> >>> Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could >>> be that the USB sub-system is simply not initialized yet when the boot >>> manager is called by distroboot. >>> >>> For testing partition detection in the UEFI sub-system it is enough >>> to run >>> >>> efidebug devices >>> >>> Until yesterday we had a problem with partition numbers >= 10, cf. >>> >>> efi_loader: partition numbers are hexadecimal >>> https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f >>> >>> >>> >>> Block devices are enumerated in efi_disk_register(). Please, try to add >>> debug output there to elucidate the problem. >> >> I found where the problem is. First of all zcu102 didn't use the same >> image as others (it wasn't updated properly). >> When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() >> is called before usb block devices are detected and registered that's >> why grub doesn't see them. > > The problem is CONFIG_EFI_SETUP_EARLY=y required by > CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > > Why is USB initialized later then MMC? It is not just usb. SCSI/sata are behaving in the same way too. > > Overall we have a deficiency in the UEFI implementation in that we > cannot deal with block devices added or removed after initialization. > > Here integration with the driver model is missing. Right. And also there are commands which can create MBR partitions and I expect when you wr
[PATCH 3/3] arm: kirkwood: GoFlex Home: Use Ethernet PHY name and address from device tree
In DM Ethernet, the old "egiga0" name is no longer valid,
so replace these with Ethernet PHY names from device tree. Also, read
Ethernet PHY address from device tree.
Signed-off-by: Tony Dinh
---
board/Seagate/goflexhome/goflexhome.c | 57 +--
1 file changed, 45 insertions(+), 12 deletions(-)
diff --git a/board/Seagate/goflexhome/goflexhome.c
b/board/Seagate/goflexhome/goflexhome.c
index af8cab7bdc..52be64fb8c 100644
--- a/board/Seagate/goflexhome/goflexhome.c
+++ b/board/Seagate/goflexhome/goflexhome.c
@@ -1,5 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
/*
+ * Copyright (C) 2021
+ * Tony Dinh
+ * Suriyan Ramasami
+ *
* Copyright (C) 2013 Suriyan Ramasami
*
* Based on dockstar.c originally written by
@@ -107,36 +111,65 @@ int board_init(void)
return 0;
}
+static int fdt_get_phy_addr(const char *path)
+{
+ const void *fdt = gd->fdt_blob;
+ const u32 *reg;
+ const u32 *val;
+ int node, phandle, addr;
+
+ /* Find the node by its full path */
+ node = fdt_path_offset(fdt, path);
+ if (node >= 0) {
+ /* Look up phy-handle */
+ val = fdt_getprop(fdt, node, "phy-handle", NULL);
+ if (val) {
+ phandle = fdt32_to_cpu(*val);
+ if (!phandle)
+ return -1;
+ /* Follow it to its node */
+ node = fdt_node_offset_by_phandle(fdt, phandle);
+ if (node) {
+ /* Look up reg */
+ reg = fdt_getprop(fdt, node, "reg", NULL);
+ if (reg) {
+ addr = fdt32_to_cpu(*reg);
+ return addr;
+ }
+ }
+ }
+ }
+ return -1;
+}
+
#ifdef CONFIG_RESET_PHY_R
/* Configure and enable MV88E1116 PHY */
void reset_phy(void)
{
u16 reg;
- u16 devadr;
- char *name = "egiga0";
+ int phyaddr;
+ char *name = "ethernet-controller@72000";
+ char *eth0_path =
"/ocp@f100/ethernet-controller@72000/ethernet0-port@0";
if (miiphy_set_current_dev(name))
return;
- /* command to read PHY dev address */
- if (miiphy_read(name, 0xEE, 0xEE, (u16 *)&devadr)) {
- printf("Err..%s could not read PHY dev address\n",
- __func__);
+ phyaddr = fdt_get_phy_addr(eth0_path);
+ if (phyaddr < 0)
return;
- }
/*
* Enable RGMII delay on Tx and Rx for CPU port
* Ref: sec 4.7.2 of chip datasheet
*/
- miiphy_write(name, devadr, MV88E1116_PGADR_REG, 2);
- miiphy_read(name, devadr, MV88E1116_MAC_CTRL_REG, ®);
+ miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 2);
+ miiphy_read(name, phyaddr, MV88E1116_MAC_CTRL_REG, ®);
reg |= (MV88E1116_RGMII_RXTM_CTRL | MV88E1116_RGMII_TXTM_CTRL);
- miiphy_write(name, devadr, MV88E1116_MAC_CTRL_REG, reg);
- miiphy_write(name, devadr, MV88E1116_PGADR_REG, 0);
+ miiphy_write(name, phyaddr, MV88E1116_MAC_CTRL_REG, reg);
+ miiphy_write(name, phyaddr, MV88E1116_PGADR_REG, 0);
/* reset the phy */
- miiphy_reset(name, devadr);
+ miiphy_reset(name, phyaddr);
printf("88E1116 Initialized on %s\n", name);
}
--
2.20.1
[PATCH 2/3] arm: kirkwood: GoFlex Home: Add DM SATA configs
Enable DM SATA in board file. Signed-off-by: Tony Dinh --- include/configs/goflexhome.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/goflexhome.h b/include/configs/goflexhome.h index a18e7869b0..2e89d72285 100644 --- a/include/configs/goflexhome.h +++ b/include/configs/goflexhome.h @@ -72,4 +72,10 @@ #define CONFIG_PHY_BASE_ADR0 #endif /* CONFIG_CMD_NET */ +/* SATA driver configuration */ +#ifdef CONFIG_SATA +#define CONFIG_SYS_SATA_MAX_DEVICE 1 +#define CONFIG_LBA48 +#endif /* CONFIG_SATA */ + #endif /* _CONFIG_GOFLEXHOME_H */ -- 2.20.1
[PATCH 1/3] arm: kirkwood: GoFlex Home: Add DM Ethernet, remove IDE, and add DM SATA configs
Add DM_ETH, SATA_MV and associated configs to goflexhome_defconfig. Signed-off-by: Tony Dinh --- configs/goflexhome_defconfig | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/goflexhome_defconfig b/configs/goflexhome_defconfig index 7207fa27e0..17adeca92f 100644 --- a/configs/goflexhome_defconfig +++ b/configs/goflexhome_defconfig @@ -16,7 +16,6 @@ CONFIG_CONSOLE_MUX=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_SYS_PROMPT="GoFlexHome> " # CONFIG_CMD_FLASH is not set -CONFIG_CMD_IDE=y CONFIG_CMD_NAND=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set @@ -48,3 +47,7 @@ CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_STORAGE=y +CONFIG_CMD_SATA=y +CONFIG_SATA_MV=y +CONFIG_DM_ETH=y +CONFIG_NET_RANDOM_ETHADDR=y -- 2.20.1
[PATCH 0/3] arm: kirkwood: Convert the GoFlex Home board Ethernet and SATA to Driver Model.
- Enable DM SATA and SATA MV driver - Enable DM Ethernet. - Use Ethernet PHY names from device tree. - Replace the old Ethernet PHY addr lookup with a device tree parsing lookup function. Tony Dinh (3): arm: kirkwood: GoFlex Home: Add DM Ethernet, remove IDE, and add DM SATA configs arm: kirkwood: GoFlex Home: Add DM SATA configs arm: kirkwood: GoFlex Home: Use Ethernet PHY name and address from device tree board/Seagate/goflexhome/goflexhome.c | 57 +-- configs/goflexhome_defconfig | 5 ++- include/configs/goflexhome.h | 6 +++ 3 files changed, 55 insertions(+), 13 deletions(-) -- 2.20.1
Re: EFI from usb HDD
On Thu, Jul 29, 2021 at 04:09:32PM +0200, Michal Simek wrote: > Hi, > > On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: > >> > >> > >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: > >>> On 6/10/21 12:04 PM, Michal Simek wrote: > Hi, > > On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > > On 6/10/21 10:44 AM, Michal Simek wrote: > >> Hi, > >> > >> I am playing with booting from USB via EFI. And I see very weird > >> behavior. I have burnt image with grub to USB flashdisk and I have > >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. > >> On zcu102 grub is going to boot menu and everything is working fine as > >> expected. > >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list > >> partitions in grub I see that only SDs are listed: > >> grub> ls > >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > > > Hello Michal, > > > > thanks for sharing your observations. > > > > What devices do hd0 and hd1 relate to? > > > >> > >> On zcu102(working board) I also see usb(gpt) partitions and SD. > >> grub> ls > >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) > >> > > > > GPT and MBR partitioning are independent of the device type. > > > >> > >> On zcu104 I see one more error message > >> "PE image measurement failed" > > > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > > will not stop disk enumeration. > > > >> But I can't see it on SOM. > >> > >> U-Boot image is just the same for all boards. I am using generic > >> xilinx_zynqmp_virt_defconfig. > >> > >> When I compare DT description for USB between zcu102 and zcu104 they > >> are > >> the same. SOM doesn't have usb enabled by default (but I enabled it) > >> but > >> grub starts which means that communication with USB is fine. > >> > >> It is based on my latest patches available here. > >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) > >> > >> Also when I list usb I see all partitions just fine. > >> ZynqMP> part list usb 0 > >> > >> Partition Map for USB device 0 -- Partition Type: EFI > >> > >> Part Start LBA End LBA Name > >> Attributes > >> Type GUID > >> Partition GUID > >> 1 0x0800 0x001007fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 > >> 2 0x00100800 0x001197fe "Microsoft basic data" > >> attrs: 0x > >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 > >> type: data > >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 > >> > >> > >> Do you have any idea why on one system is working fine to get to menu > >> and on others there is an issue to get all partitions even u-boot is > >> able to see them and can work with them. > >> > >> Thanks, > >> Michal > >> > > > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > > be that the USB sub-system is simply not initialized yet when the boot > > manager is called by distroboot. > > > > For testing partition detection in the UEFI sub-system it is enough > > to run > > > > efidebug devices > > > > Until yesterday we had a problem with partition numbers >= 10, cf. > > > > efi_loader: partition numbers are hexadecimal > > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > > > > > Block devices are enumerated in efi_disk_register(). Please, try to add > > debug output there to elucidate the problem. > > I found where the problem is. First of all zcu102 didn't use the same > image as others (it wasn't updated properly). > When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() > is called before usb block devices are detected and registered that's > why grub doesn't see them. > >>> > >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by > >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. > >>> > >>> Why is USB initialized later then MMC? > >> > >> It is not just usb. SCSI/sata are behaving in the same way too. > >> > >>> > >>> Overall we have a deficiency in the UEFI implementation in that we > >>> cannot deal with block devices added or removed after initialization. > >>> > >>> Here integration with the driver model is missing. > >> > >> Right. And also there are commands which can create MBR partitions and I > >> expect when you write image to SD and then run rescan or so you coul
[PATCH] Rname CONFIG_SPL_FIT_SHAxxx to CONFIG_SPL_SHAxxx
Rename these options to align the use in common/image-fit.c else if (CONFIG_IS_ENABLED(SHA1) && strcmp(algo, "sha1") == 0) ... else if (CONFIG_IS_ENABLED(SHA256) && strcmp(algo, "sha256") == 0) ... else if (CONFIG_IS_ENABLED(SHA384) && strcmp(algo, "sha384") == 0) ... else if (CONFIG_IS_ENABLED(SHA512) && strcmp(algo, "sha512") == 0) ... Signed-off-by: Chia-Wei Wang --- common/spl/Kconfig | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/spl/Kconfig b/common/spl/Kconfig index 9552ed4911..67e0345906 100644 --- a/common/spl/Kconfig +++ b/common/spl/Kconfig @@ -439,7 +439,7 @@ config SPL_MD5 applications where images may be changed maliciously, you should consider SHA256 or SHA384. -config SPL_FIT_SHA1 +config SPL_SHA1 bool "Support SHA1" depends on SPL_FIT select SHA1 @@ -451,7 +451,7 @@ config SPL_FIT_SHA1 due to the expanding computing power available to brute-force attacks. For more security, consider SHA256 or SHA384. -config SPL_FIT_SHA256 +config SPL_SHA256 bool "Support SHA256" depends on SPL_FIT select SHA256 @@ -460,7 +460,7 @@ config SPL_FIT_SHA256 checksum is a 256-bit (32-byte) hash value used to check that the image contents have not been corrupted. -config SPL_FIT_SHA384 +config SPL_SHA384 bool "Support SHA384" depends on SPL_FIT select SHA384 @@ -471,7 +471,7 @@ config SPL_FIT_SHA384 image contents have not been corrupted. Use this for the highest security. -config SPL_FIT_SHA512 +config SPL_SHA512 bool "Support SHA512" depends on SPL_FIT select SHA512 -- 2.17.1
[PATCH 4/4] fit: Use DM hash driver if supported
Calculate hash using DM driver if supported.
For backward compatibility, the call to legacy
hash functions is reserved.
Signed-off-by: Chia-Wei Wang
---
common/image-fit.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/common/image-fit.c b/common/image-fit.c
index d6b2c3c7ec..ec2e526356 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -25,6 +25,10 @@
#include
#include
#include
+#ifdef CONFIG_DM_HASH
+#include
+#include
+#endif
DECLARE_GLOBAL_DATA_PTR;
#endif /* !USE_HOSTCC*/
@@ -1214,6 +1218,31 @@ int fit_set_timestamp(void *fit, int noffset, time_t
timestamp)
int calculate_hash(const void *data, int data_len, const char *algo,
uint8_t *value, int *value_len)
{
+#if !defined(USE_HOSTCC) && defined(CONFIG_DM_HASH)
+ int rc;
+ enum HASH_ALGO hash_algo;
+ struct udevice *dev;
+
+ rc = uclass_get_device(UCLASS_HASH, 0, &dev);
+ if (rc) {
+ debug("failed to get hash device, rc=%d\n", rc);
+ return -1;
+ }
+
+ hash_algo = hash_algo_lookup_by_name(algo);
+ if (hash_algo == HASH_ALGO_INVALID) {
+ debug("Unsupported hash algorithm\n");
+ return -1;
+ };
+
+ rc = hash_digest_wd(dev, hash_algo, data, data_len, value, CHUNKSZ);
+ if (rc) {
+ debug("failed to get hash value, rc=%d\n", rc);
+ return -1;
+ }
+
+ *value_len = hash_algo_digest_size(hash_algo);
+#else
if (IMAGE_ENABLE_CRC32 && strcmp(algo, "crc32") == 0) {
*((uint32_t *)value) = crc32_wd(0, data, data_len,
CHUNKSZ_CRC32);
@@ -1242,6 +1271,7 @@ int calculate_hash(const void *data, int data_len, const
char *algo,
debug("Unsupported hash alogrithm\n");
return -1;
}
+#endif
return 0;
}
--
2.17.1
[PATCH 2/4] dm: hash: Add new UCLASS_HASH support
Add UCLASS_HASH for hash driver development. Thus the
hash drivers (SW or HW-accelerated) can be developed
in the DM-based fashion.
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/Kconfig| 2 +
drivers/crypto/Makefile | 1 +
drivers/crypto/hash/Kconfig | 5 ++
drivers/crypto/hash/Makefile | 5 ++
drivers/crypto/hash/hash-uclass.c | 121 ++
include/dm/uclass-id.h| 1 +
include/u-boot/hash.h | 61 +++
7 files changed, 196 insertions(+)
create mode 100644 drivers/crypto/hash/Kconfig
create mode 100644 drivers/crypto/hash/Makefile
create mode 100644 drivers/crypto/hash/hash-uclass.c
create mode 100644 include/u-boot/hash.h
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1ea116be75..0082177c21 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -1,5 +1,7 @@
menu "Hardware crypto devices"
+source drivers/crypto/hash/Kconfig
+
source drivers/crypto/fsl/Kconfig
endmenu
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index efbd1d3fca..4a12b56be6 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,3 +6,4 @@
obj-$(CONFIG_EXYNOS_ACE_SHA) += ace_sha.o
obj-y += rsa_mod_exp/
obj-y += fsl/
+obj-y += hash/
diff --git a/drivers/crypto/hash/Kconfig b/drivers/crypto/hash/Kconfig
new file mode 100644
index 00..e226144b9b
--- /dev/null
+++ b/drivers/crypto/hash/Kconfig
@@ -0,0 +1,5 @@
+config DM_HASH
+ bool "Enable Driver Model for Hash"
+ depends on DM
+ help
+ If you want to use driver model for Hash, say Y.
diff --git a/drivers/crypto/hash/Makefile b/drivers/crypto/hash/Makefile
new file mode 100644
index 00..83acf3d47b
--- /dev/null
+++ b/drivers/crypto/hash/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (c) 2021 ASPEED Technology Inc.
+
+obj-$(CONFIG_DM_HASH) += hash-uclass.o
diff --git a/drivers/crypto/hash/hash-uclass.c
b/drivers/crypto/hash/hash-uclass.c
new file mode 100644
index 00..446eb9e56a
--- /dev/null
+++ b/drivers/crypto/hash/hash-uclass.c
@@ -0,0 +1,121 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 ASPEED Technology Inc.
+ * Author: ChiaWei Wang
+ */
+
+#define LOG_CATEGORY UCLASS_HASH
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct hash_info {
+ char *name;
+ uint32_t digest_size;
+};
+
+static const struct hash_info hash_info[HASH_ALGO_NUM] = {
+ [HASH_ALGO_CRC16_CCITT] = { "crc16-ccitt", 2 },
+ [HASH_ALGO_CRC32] = { "crc32", 4 },
+ [HASH_ALGO_MD5] = { "md5", 16 },
+ [HASH_ALGO_SHA1] = { "sha1", 20 },
+ [HASH_ALGO_SHA256] = { "sha256", 32 },
+ [HASH_ALGO_SHA384] = { "sha384", 48 },
+ [HASH_ALGO_SHA512] = { "sha512", 64},
+};
+
+enum HASH_ALGO hash_algo_lookup_by_name(const char *name)
+{
+ int i;
+
+ if (!name)
+ return HASH_ALGO_INVALID;
+
+ for (i = 0; i < HASH_ALGO_NUM; ++i)
+ if (!strcmp(name, hash_info[i].name))
+ return i;
+
+ return HASH_ALGO_INVALID;
+}
+
+ssize_t hash_algo_digest_size(enum HASH_ALGO algo)
+{
+ if (algo >= HASH_ALGO_NUM)
+ return -EINVAL;
+
+ return hash_info[algo].digest_size;
+}
+
+const char *hash_algo_name(enum HASH_ALGO algo)
+{
+ if (algo >= HASH_ALGO_NUM)
+ return NULL;
+
+ return hash_info[algo].name;
+}
+
+int hash_digest(struct udevice *dev, enum HASH_ALGO algo,
+ const void *ibuf, const uint32_t ilen,
+ void *obuf)
+{
+ struct hash_ops *ops = (struct hash_ops *)device_get_ops(dev);
+
+ if (!ops->hash_digest)
+ return -ENOSYS;
+
+ return ops->hash_digest(dev, algo, ibuf, ilen, obuf);
+}
+
+int hash_digest_wd(struct udevice *dev, enum HASH_ALGO algo,
+ const void *ibuf, const uint32_t ilen,
+ void *obuf, uint32_t chunk_sz)
+{
+ struct hash_ops *ops = (struct hash_ops *)device_get_ops(dev);
+
+ if (!ops->hash_digest_wd)
+ return -ENOSYS;
+
+ return ops->hash_digest_wd(dev, algo, ibuf, ilen, obuf, chunk_sz);
+}
+
+int hash_init(struct udevice *dev, enum HASH_ALGO algo, void **ctxp)
+{
+ struct hash_ops *ops = (struct hash_ops *)device_get_ops(dev);
+
+ if (!ops->hash_init)
+ return -ENOSYS;
+
+ return ops->hash_init(dev, algo, ctxp);
+}
+
+int hash_update(struct udevice *dev, void *ctx, const void *ibuf, const
uint32_t ilen)
+{
+ struct hash_ops *ops = (struct hash_ops *)device_get_ops(dev);
+
+ if (!ops->hash_update)
+ return -ENOSYS;
+
+ return ops->hash_update(dev, ctx, ibuf, ilen);
+}
+
+int hash_finish(struct udevice *dev, void *ctx, void *obuf)
+{
+ struct hash_ops *ops = (struct hash_ops *)device_get_ops(dev);
+
+ if (!ops->hash_finis
[PATCH 3/4] crypto: hash: Add software hash DM driver
Add purely software-implmented drivers to support multiple
hash operations including CRC, MD5, and SHA family.
This driver is based on the new hash uclass.
Signed-off-by: Chia-Wei Wang
---
drivers/crypto/hash/Kconfig | 11 ++
drivers/crypto/hash/Makefile | 1 +
drivers/crypto/hash/hash_sw.c | 301 ++
3 files changed, 313 insertions(+)
create mode 100644 drivers/crypto/hash/hash_sw.c
diff --git a/drivers/crypto/hash/Kconfig b/drivers/crypto/hash/Kconfig
index e226144b9b..cd29a5c6a4 100644
--- a/drivers/crypto/hash/Kconfig
+++ b/drivers/crypto/hash/Kconfig
@@ -3,3 +3,14 @@ config DM_HASH
depends on DM
help
If you want to use driver model for Hash, say Y.
+
+config HASH_SOFTWARE
+ bool "Enable driver for Hash in software"
+ depends on DM_HASH
+ depends on MD5
+ depends on SHA1
+ depends on SHA256
+ depends on SHA512_ALGO
+ help
+ Enable driver for hashing operations in software. Currently
+ it support multiple hash algorithm including CRC/MD5/SHA.
diff --git a/drivers/crypto/hash/Makefile b/drivers/crypto/hash/Makefile
index 83acf3d47b..33d88161ed 100644
--- a/drivers/crypto/hash/Makefile
+++ b/drivers/crypto/hash/Makefile
@@ -3,3 +3,4 @@
# Copyright (c) 2021 ASPEED Technology Inc.
obj-$(CONFIG_DM_HASH) += hash-uclass.o
+obj-$(CONFIG_HASH_SOFTWARE) += hash_sw.o
diff --git a/drivers/crypto/hash/hash_sw.c b/drivers/crypto/hash/hash_sw.c
new file mode 100644
index 00..fea9d12609
--- /dev/null
+++ b/drivers/crypto/hash/hash_sw.c
@@ -0,0 +1,301 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2021 ASPEED Technology Inc.
+ * Author: ChiaWei Wang
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* CRC16-CCITT */
+static void hash_init_crc16_ccitt(void *ctx)
+{
+ *((uint16_t *)ctx) = 0;
+}
+
+static void hash_update_crc16_ccitt(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ *((uint16_t *)ctx) = crc16_ccitt(*((uint16_t *)ctx), ibuf, ilen);
+}
+
+static void hash_finish_crc16_ccitt(void *ctx, void *obuf)
+{
+ *((uint16_t *)obuf) = *((uint16_t *)ctx);
+}
+
+/* CRC32 */
+static void hash_init_crc32(void *ctx)
+{
+ *((uint32_t *)ctx) = 0;
+}
+
+static void hash_update_crc32(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ *((uint32_t *)ctx) = crc32(*((uint32_t *)ctx), ibuf, ilen);
+}
+
+static void hash_finish_crc32(void *ctx, void *obuf)
+{
+ *((uint32_t *)obuf) = *((uint32_t *)ctx);
+}
+
+/* MD5 */
+static void hash_init_md5(void *ctx)
+{
+ MD5Init((struct MD5Context *)ctx);
+}
+
+static void hash_update_md5(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ MD5Update((struct MD5Context *)ctx, ibuf, ilen);
+}
+
+static void hash_finish_md5(void *ctx, void *obuf)
+{
+ MD5Final(obuf, (struct MD5Context *)ctx);
+}
+
+/* SHA1 */
+static void hash_init_sha1(void *ctx)
+{
+ sha1_starts((sha1_context *)ctx);
+}
+
+static void hash_update_sha1(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ sha1_update((sha1_context *)ctx, ibuf, ilen);
+}
+
+static void hash_finish_sha1(void *ctx, void *obuf)
+{
+ sha1_finish((sha1_context *)ctx, obuf);
+}
+
+/* SHA256 */
+static void hash_init_sha256(void *ctx)
+{
+ sha256_starts((sha256_context *)ctx);
+}
+
+static void hash_update_sha256(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ sha256_update((sha256_context *)ctx, ibuf, ilen);
+}
+
+static void hash_finish_sha256(void *ctx, void *obuf)
+{
+ sha256_finish((sha256_context *)ctx, obuf);
+}
+
+/* SHA384 */
+static void hash_init_sha384(void *ctx)
+{
+ sha384_starts((sha512_context *)ctx);
+}
+
+static void hash_update_sha384(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ sha384_update((sha512_context *)ctx, ibuf, ilen);
+}
+
+static void hash_finish_sha384(void *ctx, void *obuf)
+{
+ sha384_finish((sha512_context *)ctx, obuf);
+}
+
+/* SHA512 */
+static void hash_init_sha512(void *ctx)
+{
+ sha512_starts((sha512_context *)ctx);
+}
+
+static void hash_update_sha512(void *ctx, const void *ibuf, uint32_t ilen)
+{
+ sha512_update((sha512_context *)ctx, ibuf, ilen);
+}
+
+static void hash_finish_sha512(void *ctx, void *obuf)
+{
+ sha512_finish((sha512_context *)ctx, obuf);
+}
+
+struct sw_hash_ctx {
+ enum HASH_ALGO algo;
+ uint8_t algo_ctx[];
+};
+
+struct sw_hash_impl {
+ void (*init)(void *ctx);
+ void (*update)(void *ctx, const void *ibuf, uint32_t ilen);
+ void (*finish)(void *ctx, void *obuf);
+ uint32_t ctx_alloc_sz;
+};
+
+static struct sw_hash_impl sw_hash_impl[HASH_ALGO_NUM] = {
+ [HASH_ALGO_CRC16_CCITT] = {
+ .init = hash_init_crc16_ccitt,
+ .update = hash_update_crc16_ccitt,
+ .finish = hash_finish_crc16_ccitt,
+ .ctx_alloc_sz = sizeof(uint16_t),
+ },
+
+
[PATCH 1/4] lib/md5: Export progressive APIs
Export the MD5 hash init/update/finish progressive APIs
for better flexibility.
Signed-off-by: Chia-Wei Wang
---
include/u-boot/md5.h | 4
lib/md5.c| 6 +++---
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/u-boot/md5.h b/include/u-boot/md5.h
index e09c16a6e3..e5cb923d77 100644
--- a/include/u-boot/md5.h
+++ b/include/u-boot/md5.h
@@ -17,6 +17,10 @@ struct MD5Context {
};
};
+void MD5Init(struct MD5Context *ctx);
+void MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len);
+void MD5Final(unsigned char digest[16], struct MD5Context *ctx);
+
/*
* Calculate and store in 'output' the MD5 digest of 'len' bytes at
* 'input'. 'output' must have enough space to hold 16 bytes.
diff --git a/lib/md5.c b/lib/md5.c
index 2ae4a06319..688b7254c6 100644
--- a/lib/md5.c
+++ b/lib/md5.c
@@ -55,7 +55,7 @@ byteReverse(unsigned char *buf, unsigned longs)
* Start MD5 accumulation. Set bit count to 0 and buffer to mysterious
* initialization constants.
*/
-static void
+void
MD5Init(struct MD5Context *ctx)
{
ctx->buf[0] = 0x67452301;
@@ -71,7 +71,7 @@ MD5Init(struct MD5Context *ctx)
* Update context to reflect the concatenation of another buffer full
* of bytes.
*/
-static void
+void
MD5Update(struct MD5Context *ctx, unsigned char const *buf, unsigned len)
{
register __u32 t;
@@ -120,7 +120,7 @@ MD5Update(struct MD5Context *ctx, unsigned char const *buf,
unsigned len)
* Final wrapup - pad to 64-byte boundary with the bit pattern
* 1 0* (64-bit count of bits processed, MSB-first)
*/
-static void
+void
MD5Final(unsigned char digest[16], struct MD5Context *ctx)
{
unsigned int count;
--
2.17.1
[PATCH 0/4] crypto: Add new UCLASS_HASH
This patch series proposes new UCLASS_HASH for hash devices. Thus the hash drivers (SW or HW-accelerated) can be developed in the DM-based fashion. A purely software implemented hash driver is also added under the newly added UCLASS_HASH uclass. In addition, the FIT image hash verification is also updated to leverage the UCLASS_HASH driver if configured. As there is widly spread use of non-DM hash functions (common/hash.c), this patch does not remove them. More patches are needed if UCLASS_HASH is established. Chia-Wei Wang (4): lib/md5: Export progressive APIs dm: hash: Add new UCLASS_HASH support crypto: hash: Add software hash DM driver fit: Use DM hash driver if supported common/image-fit.c| 30 +++ drivers/crypto/Kconfig| 2 + drivers/crypto/Makefile | 1 + drivers/crypto/hash/Kconfig | 16 ++ drivers/crypto/hash/Makefile | 6 + drivers/crypto/hash/hash-uclass.c | 121 drivers/crypto/hash/hash_sw.c | 301 ++ include/dm/uclass-id.h| 1 + include/u-boot/hash.h | 61 ++ include/u-boot/md5.h | 4 + lib/md5.c | 6 +- 11 files changed, 546 insertions(+), 3 deletions(-) create mode 100644 drivers/crypto/hash/Kconfig create mode 100644 drivers/crypto/hash/Makefile create mode 100644 drivers/crypto/hash/hash-uclass.c create mode 100644 drivers/crypto/hash/hash_sw.c create mode 100644 include/u-boot/hash.h -- 2.17.1
[PATCH] mx7dsabresd: Select CONFIG_IMX_HAB
Select CONFIG_IMX_HAB so that the "hab_status" command becomes available, which is useful for checking if the chip has been correctly setup to run in secure boot mode. Signed-off-by: Fabio Estevam --- configs/mx7dsabresd_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mx7dsabresd_defconfig b/configs/mx7dsabresd_defconfig index d3079c1d9e42..39e73042bfb9 100644 --- a/configs/mx7dsabresd_defconfig +++ b/configs/mx7dsabresd_defconfig @@ -11,6 +11,7 @@ CONFIG_TARGET_MX7DSABRESD=y # CONFIG_ARMV7_VIRT is not set CONFIG_IMX_RDC=y CONFIG_IMX_BOOTAUX=y +CONFIG_IMX_HAB=y CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=board/freescale/mx7dsabresd/imximage.cfg" CONFIG_BOOTCOMMAND="run finduuid; run distro_bootcmd" -- 2.25.1
Re: [PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
Hi Aswath,
On 7/29/21 11:55 PM, Aswath Govindraju wrote:
> Add support for enumerating MMC card in a given mode using mmc rescan and
> mmc dev commands. The speed mode is provided as the last argument in these
> commands and is indicated using the index from enum bus_mode in
> include/mmc.h. A speed mode can be set only if it has already been enabled
> in the device tree.
Thanks for this patch. It seems that it's useful to develope and debug.
I will test with this patch.
Could you also update doc/usage/mmc.rst file?
Best Regards,
Jaehoo Chung
>
> Signed-off-by: Aswath Govindraju
> ---
> cmd/Kconfig | 10 ++
> cmd/mmc.c| 71
> drivers/mmc/mmc-uclass.c | 3 ++
> drivers/mmc/mmc.c| 18 ++
> include/mmc.h| 4 +++
> 5 files changed, 85 insertions(+), 21 deletions(-)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index ffef3cc76ca4..3a857b3f6e2e 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2389,4 +2389,14 @@ config CMD_UBIFS
> help
> UBIFS is a file system for flash devices which works on top of UBI.
>
> +config MMC_SPEED_MODE_SET
> + bool "set speed mode using mmc command"
> + depends on CMD_MMC
> + default n
> + help
> + Enable setting speed mode using mmc rescan and mmc dev commands.
> + The speed mode is provided as the last argument in these commands
> + and is indicated using the index from enum bus_mode in
> + include/mmc.h. A speed mode can be set only if it has already
> + been enabled in the device tree.
> endmenu
> diff --git a/cmd/mmc.c b/cmd/mmc.c
> index b942576b58ac..073e87d69634 100644
> --- a/cmd/mmc.c
> +++ b/cmd/mmc.c
> @@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
> }
> }
> }
> -static struct mmc *init_mmc_device(int dev, bool force_init)
> +
> +static struct mmc *init_mmc_device(int dev, bool force_init,
> +enum bus_mode speed_mode)
> {
> struct mmc *mmc;
> mmc = find_mmc_device(dev);
> @@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
> force_init)
>
> if (force_init)
> mmc->has_init = 0;
> +
> +#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
> + mmc->user_speed_mode = speed_mode;
> +#endif
> +
> if (mmc_init(mmc))
> return NULL;
>
> @@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag,
> int argc,
> }
> }
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
> if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
> return CMD_RET_SUCCESS;
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
> blk = simple_strtoul(argv[2], NULL, 16);
> cnt = simple_strtoul(argv[3], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, int
> flag,
> return CMD_RET_FAILURE;
> }
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
> blk = simple_strtoul(argv[2], NULL, 16);
> cnt = simple_strtoul(argv[3], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int flag,
> blk = simple_strtoul(argv[1], NULL, 16);
> cnt = simple_strtoul(argv[2], NULL, 16);
>
> - mmc = init_mmc_device(curr_device, false);
> + mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
> if (!mmc)
> return CMD_RET_FAILURE;
>
> @@ -482,8 +489,19 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
>int argc, char *const argv[])
> {
> struct mmc *mmc;
> + enum bus_mode speed_mode = MMC_MODES_END;
> +
> + if (argc == 1) {
> + mmc = init_mmc_device(curr_device, true, MMC_MODES_END);
> + } else if (argc == 2) {
> + /* parse the mode */
> + speed_mode = simple_strtoul(argv[1], NULL, 10);
> + /* Need to pass the the speed mode required too */
> +
Re: Help with u-boot when using the eMMC card in DDR mode
Hi On 7/28/21 1:57 AM, Abder wrote: > The previously mentioned commit didn't resolve the issue. When testing I > made a mistake. > > The workaround I'm using to resolve the issue is by disabling the DDR mode > juste before re-init happens (DDR mode will be automatically enabled later > in the init process). > > Now I don't know if this is really a bug in the mmc driver, or I'm just > missing some additional configuration to work with the eMMC in DDR mode ! > It seems that it has a bug in fsl_esdhc_imx.c. I don't have any boards to use its driver. But when i have checked a code, there is a bit relevant to DDR enable bit in esdhc_set_timing(). If it doesn't clear its bit when it's re-initializing, it's possible to fail. Best Regards, Jaehoon Chung > > > > Le mar. 27 juil. 2021 à 15:14, Abder a écrit : > >> Hi Jaehoon, >> yes, DDR mode works fine before executing "mmc dev 2" command. >> However, for "mmc rescan" command or "mmc info" to work, I need to first >> select the correct mmc device using the "mmc dev 2" command, cuz the >> default one is device 0 in my case which is empty. >> >> OTOH, after hours of debugging I found the origin of the issue. In fact, >> the "mmc dev 2" command forces a reinitialization of the emmc, and if the >> emmc was already initialized in DDR mode at boot up, the implemented >> re-init flow leads to bad clock settings. >> (basicly the host tries to set the clock of the emmc to 400KHz >> (identification mode), but as the DDR mode is still enabled, the >> configured clock corresponds to the half of that = 200KHz). The mismatch in >> frequency is what caused the -70 ECOM error. >> and as the command fails, the emmc stays at 200KHz, which leads any >> attempt to interact with the emmc afterwards to failure. >> >> I found out that this bug was patched recently in >> 390f9bddb9c84f75649024b41b8cf2a766379ce0 in the main u-boot. >> >> Anyhow.. Thanks for your replies. >> >> Best regards, >> Abder >> >> >> Le mar. 27 juil. 2021 à 04:03, Jaehoon Chung a >> écrit : >> >>> On 7/26/21 5:36 PM, Abder wrote: Hi Jaehoon, This is the output with MMC_TRACE enabled U-Boot >mmc dev 2 blk_find_device: if_type=6, devnum=2: us...@02198000.blk, 6, 2 ofnode_read_u32: vmmc-supply: 0x33 (51) ofnode_read_u32: vqmmc-supply: 0x33 (51) clock is disabled (0Hz) fixed_regulator_set_enable: dev='3p3v', enable=1, delay=0, has_gpio=0 clock is enabled (40Hz) CMD_SEND:0 ARG 0x MMC_RSP_NONE CMD_SEND:8 ARG 0x01aa RET -110 CMD_SEND:55 ARG 0x RET -110 CMD_SEND:0 ARG 0x MMC_RSP_NONE CMD_SEND:1 ARG 0x MMC_RSP_R3,4 0x00ff8080 CMD_SEND:1 ARG 0x4030 MMC_RSP_R3,4 0x00ff8080 CMD_SEND:0 ARG 0x MMC_RSP_NONE CMD_SEND:1 ARG 0x4030 MMC_RSP_R3,4 0x00ff8080 CMD_SEND:1 ARG 0x4030 MMC_RSP_R3,4 0x00ff8080 CMD_SEND:1 ARG 0x4030 MMC_RSP_R3,4 0x00ff8080 CMD_SEND:1 ARG 0x4030 MMC_RSP_R3,4 0xc0ff8080 CMD_SEND:2 ARG 0x RET -70 CMD_SEND:2 ARG 0x RET -70 CMD_SEND:2 ARG 0x RET -70 CMD_SEND:2 ARG 0x RET -70 CMD_SEND:2 ARG 0x RET -70 CMD_SEND:2 ARG 0x RET -70 Command failed, result=1 U-Boot > I believe the -70 error is an ECOM error (Communication error on send). However this does not occur when eMMC is in HS mode for example. and even in DDR mode, before executing the "mmc dev 2" cmd, the communication with the emmc with "load" works without a hitch. >>> >>> Sorry. I didn't understand clearly. >>> Does DDR mode work fine before "mmc dev 2" command? >>> Did you try to
[PATCH] lib/rsa: Remove support for OpenSSL < 1.1.0 and libressl < 2.7.0
Older OpenSSL and libressl versions have a slightly different API.
This require #ifdefs to support. However, we still can't support it
because the ECDSA path does not compile with these older versions.
These #ifdefs are truly a vestigial appendage.
Alternatively, the ECDSA path could be updated for older libraries,
but this requires significant extra code, and #ifdefs. Those libraries
are over three years old, and there concerns whether it makes sense to
build modern software for real world use against such old libraries.
Thusly, remove #ifdefs and code for old OpenSSL and LibreSSL support.
Signed-off-by: Alexandru Gagniuc
---
I would appreciate if somebody tested the RSA signing functionality
with this patch applied, as I am not equipped to test this
comprehensively.
lib/rsa/rsa-sign.c | 76 +++---
1 file changed, 4 insertions(+), 72 deletions(-)
diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c
index deff936fef..e6527c2610 100644
--- a/lib/rsa/rsa-sign.c
+++ b/lib/rsa/rsa-sign.c
@@ -19,24 +19,6 @@
#include
#include
-#if OPENSSL_VERSION_NUMBER >= 0x1000L
-#define HAVE_ERR_REMOVE_THREAD_STATE
-#endif
-
-#if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
-static void RSA_get0_key(const RSA *r,
- const BIGNUM **n, const BIGNUM **e, const BIGNUM **d)
-{
- if (n != NULL)
- *n = r->n;
- if (e != NULL)
- *e = r->e;
- if (d != NULL)
- *d = r->d;
-}
-#endif
-
static int rsa_err(const char *msg)
{
unsigned long sslErr = ERR_get_error();
@@ -314,24 +296,11 @@ static int rsa_init(void)
{
int ret;
-#if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
- ret = SSL_library_init();
-#else
ret = OPENSSL_init_ssl(0, NULL);
-#endif
if (!ret) {
fprintf(stderr, "Failure to init SSL library\n");
return -1;
}
-#if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
- SSL_load_error_strings();
-
- OpenSSL_add_all_algorithms();
- OpenSSL_add_all_digests();
- OpenSSL_add_all_ciphers();
-#endif
return 0;
}
@@ -346,8 +315,7 @@ static int rsa_engine_init(const char *engine_id, ENGINE
**pe)
e = ENGINE_by_id(engine_id);
if (!e) {
fprintf(stderr, "Engine isn't available\n");
- ret = -1;
- goto err_engine_by_id;
+ return -1;
}
if (!ENGINE_init(e)) {
@@ -370,29 +338,9 @@ err_set_rsa:
ENGINE_finish(e);
err_engine_init:
ENGINE_free(e);
-err_engine_by_id:
-#if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
- ENGINE_cleanup();
-#endif
return ret;
}
-static void rsa_remove(void)
-{
-#if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
- CRYPTO_cleanup_all_ex_data();
- ERR_free_strings();
-#ifdef HAVE_ERR_REMOVE_THREAD_STATE
- ERR_remove_thread_state(NULL);
-#else
- ERR_remove_state(0);
-#endif
- EVP_cleanup();
-#endif
-}
-
static void rsa_engine_remove(ENGINE *e)
{
if (e) {
@@ -465,12 +413,7 @@ static int rsa_sign_with_key(EVP_PKEY *pkey, struct
padding_algo *padding_algo,
goto err_sign;
}
- #if OPENSSL_VERSION_NUMBER < 0x1010L || \
- (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER <
0x0207fL)
- EVP_MD_CTX_cleanup(context);
- #else
- EVP_MD_CTX_reset(context);
- #endif
+ EVP_MD_CTX_reset(context);
EVP_MD_CTX_destroy(context);
debug("Got signature: %d bytes, expected %zu\n", *sig_size, size);
@@ -502,7 +445,7 @@ int rsa_sign(struct image_sign_info *info,
if (info->engine_id) {
ret = rsa_engine_init(info->engine_id, &e);
if (ret)
- goto err_engine;
+ return ret;
}
ret = rsa_get_priv_key(info->keydir, info->keyname, info->keyfile,
@@ -517,7 +460,6 @@ int rsa_sign(struct image_sign_info *info,
EVP_PKEY_free(pkey);
if (info->engine_id)
rsa_engine_remove(e);
- rsa_remove();
return ret;
@@ -526,8 +468,6 @@ err_sign:
err_priv:
if (info->engine_id)
rsa_engine_remove(e);
-err_engine:
- rsa_remove();
return ret;
}
@@ -675,12 +615,8 @@ int rsa_add_verify_data(struct image_sign_info *info, void
*keydest)
ret = rsa_get_pub_key(info->keydir, info->keyname, e, &pkey);
if (ret)
goto err_get_pub_key;
-#if OPENSSL_VERSION_NUMBER < 0x1010L |
[PATCH 1/1] config: MPC8548CDS: eliminate symbol CONFIG_SYS_ID_EEPROM
Symbol CONFIG_SYS_ID_EEPROM is defined in include/configs/MPC8548CDS.h but never used. Remove it here and from the whitelist. Signed-off-by: Heinrich Schuchardt --- include/configs/MPC8548CDS.h | 1 - scripts/config_whitelist.txt | 1 - 2 files changed, 2 deletions(-) diff --git a/include/configs/MPC8548CDS.h b/include/configs/MPC8548CDS.h index 9f83931bed..b395bdb5ef 100644 --- a/include/configs/MPC8548CDS.h +++ b/include/configs/MPC8548CDS.h @@ -310,7 +310,6 @@ extern unsigned long get_clock_freq(void); /* EEPROM */ #define CONFIG_ID_EEPROM #define CONFIG_SYS_I2C_EEPROM_CCID -#define CONFIG_SYS_ID_EEPROM #define CONFIG_SYS_I2C_EEPROM_ADDR 0x57 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 2 diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index 042ca116e9..111f004b5f 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -2458,7 +2458,6 @@ CONFIG_SYS_ICACHE_INV CONFIG_SYS_ICS8N3QV01_I2C CONFIG_SYS_IDE_MAXBUS CONFIG_SYS_IDE_MAXDEVICE -CONFIG_SYS_ID_EEPROM CONFIG_SYS_IFC_ADDR CONFIG_SYS_IFC_CCR CONFIG_SYS_INIT_DBCR -- 2.30.2
Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
On Thu, Jul 29, 2021 at 06:47:02PM +0200, Marek Vasut wrote:
> On 7/29/21 5:23 PM, Tom Rini wrote:
> > On Thu, Jul 29, 2021 at 05:01:09PM +0200, Marek Vasut wrote:
> > > On 7/29/21 9:22 AM, Jan Kiszka wrote:
> > > > From: Jan Kiszka
> > > >
> > > > This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
> > > >
> > > > While the goal is valid and there is surely unused memory in that area,
> > > > we also have a lot of crucial things still located at the top-of-memory
> > > > while running lmb_alloc_base. Such things are the page table (tlb_addr),
> > > > relocated U-Boot and the active stack. Possibly more. So this patch was
> > > > premature, we will need relocations of those things first if we want to
> > > > use the range.
> > > >
> > > > Fixes booting on the IOT2050, but likely also on other boards. It got
> > > > stuck on relocating the FDT - over the relocated U-Boot code.
> > > >
> > > > Signed-off-by: Jan Kiszka
> > > > ---
> > > >
> > > > Practically,
> > > >
> > > > void arch_lmb_reserve(struct lmb *lmb)
> > > > {
> > > > lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
> > > > }
> > >
> > > So this is wrong and breaks a use case on rcar3, where there is more stuff
> > > which should not be reserved until the ram top.
> > >
> > > I suspect the real fix here is to protect only the stack and tlb on arm64,
> > > not just everything from current stack bottom to ram top ?
> >
> > Wait, what? There's never been a U-Boot release that didn't reserve
> > that area
>
> That does not mean such a huge reservation is correct.
> I apologize for not being overly clear in my answer, I already told Jan I am
> highly overloaded and simply lack the capacity to analyze this problem
> thoroughly on a short notice.
I understand.
> > so when did rcar3 introduce something there that shouldn't be
> > reserved? And you had phrased this to me on IRC as about reserving spot
> > for ATAGS, and that not being needed of course on arm64. But that's not
> > what's going on. Perhaps the answer is that rcar3 needs to introduce a
> > board_lmb_reserve to free the normal arch one and provide whatever more
> > narrow scope it needs.
>
> Based on the commit message 2359fa7a878 ("arm: bootm: Disable LMB
> reservation for command line and board info on arm64") , this is about ATAGS
> and we really don't need to reserve those on arm64.
Commit 2359fa7a878 disables the entire arch_lmb_reserve function on
aarch64, yes. I assumed when we had talked that it was a small area
being set aside and perhaps mis-recalled that ATAGS tended to live at
DDR_BASE + 0x800 or so. This reservation is not at that spot, and a lot
more than that. That commit is also only present in v2021.10-rc1 so
it's not a great idea for another project to depend on it and can also
revert their changes until someone is able to analyze the entire
situation again.
> I didn't hit the tlb reservation issue Jan has in my tests on rcar3, so I
> suspect that is the real problem here, i.e. we need some more fine grained
> lmb reservation on arm64 ?
Yes, some further analysis is needed here. But due to a lack of time I
suspect the best answer for now is for rcar3 to add board_lmb_reserve()
and lmb_free what's not needed there.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] mkimage: use environment variable MKIMAGE_SIGN_PIN to set pin for OpenSSL Engine
On Fri, Jul 23, 2021 at 10:17:50PM +0200, Marc Kleine-Budde wrote:
> This patch adds the possibility to pass the PIN the OpenSSL Engine
> used during signing via the environment variable MKIMAGE_SIGN_PIN.
> This follows the approach used during kernel module
> signing ("KBUILD_SIGN_PIN") or UBIFS image
> signing ("MKIMAGE_SIGN_PIN").
>
> Signed-off-by: Marc Kleine-Budde
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] test/py: Improve check for mksquashfs version
On Thu, Jul 22, 2021 at 10:52:05PM +0200, Marek Behún wrote: > Some builds of squashfs-tools append version string with "-git" or > similar. The float() conversion will fail in this case. > > Improve the code to only convert to float() the string before the '-' > character. > > Signed-off-by: Marek Behún > Reviewed-by: Simon Glass > Reviewed-by: Joao Marcos Costa Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH] build: remove the variable NM in gen_ll_addressable_symbols.sh
On Wed, Jul 21, 2021 at 09:56:07AM +0200, Patrick Delaunay wrote: > With LTO activated, the buildman tools failed with an error on my > configuration (Ubuntu 20.04, stm32mp15_trusted_defconfig) with the error: > > ../arm-linux-gnueabi/bin/nm: > scripts/gen_ll_addressable_symbols.sh: file format not recognized > > It seems the shell variable initialization NM=$(NM) is not correctly > interpreted when shell is started in the Makefile, but I have not this > issue when I compile the same target without buildman. > > I don't found the root reason of the problem but I solve it by > providing $(NM) as script parameter instead using a shell variable. > > The command executed is identical: > > cmd_keep-syms-lto.c := NM=arm-none-linux-gnueabihf-gcc-nm \ > u-boot/scripts/gen_ll_addressable_symbols.sh arch/arm/cpu/built-in.o \ > net/built-in.o >keep-syms-lto.c > > cmd_keep-syms-lto.c := u-boot/scripts/gen_ll_addressable_symbols.sh \ > arm-none-linux-gnueabihf-gcc-nm arch/arm/cpu/built-in.o \ > ... net/built-in.o > keep-syms-lto.c > > Reviewed-by: Simon Glass > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: rsa: rsa-sign: Minor bug in debug message
On Mon, Jul 19, 2021 at 09:18:54AM -0700, Chan, Donald wrote: > *sig_size isn't set until later so use the correct variables. > > Signed-off-by: Donald Chan > Reviewed-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] lib: rsa: rsa-verify: Fix a typo in a debug message
On Mon, Jul 19, 2021 at 04:04:44PM +0200, Thomas Perrot wrote: > Signed-off-by: Thomas Perrot Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] arm64: Update memcpy_{from, to}io() helpers
On Mon, Jul 19, 2021 at 11:21:51AM +0200, Patrick Delaunay wrote:
> From: Patrice Chotard
>
> At early U-Boot stage, before relocation, MMU is not yet configured
> and disabled. DDR may not be configured with the correct memory
> attributes (can be configured in MT_DEVICE instead of MT_MEMORY).
>
> In this case, usage of memcpy_{from, to}io() may leads to synchronous
> abort in AARCH64 in case the normal memory address is not 64Bits aligned.
>
> To avoid such situation, forbid usage of normal memory cast to (u64 *) in
> case MMU is not enabled.
>
> Signed-off-by: Patrice Chotard
> Reviewed-by: Patrick Delaunay
> Cc: mark.kette...@xs4all.nl
> Signed-off-by: Patrick Delaunay
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] arm: use the correct prototype for reset_cpu function
On Mon, Jul 19, 2021 at 11:21:50AM +0200, Patrick Delaunay wrote: > Align reset_cpu function with the next prototypes in > sysreset.h or in cpu_func.h to solve compilation issue: > > void reset_cpu(void); > > This patch solves the prototype conflict when cpu_func.h is > included. > > Signed-off-by: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 3/5] doc: sandbox: Fix up dependencies
On Sun, Jul 18, 2021 at 02:14:24PM -0600, Simon Glass wrote: > These are out of date. Update them and point to the existing build > instructions to avoid duplication. Add a few that are missing. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/5] pci: swap_case: Allow compilation on 32-bit machines
On Sun, Jul 18, 2021 at 02:14:23PM -0600, Simon Glass wrote: > At present this driver assumes that ulong is 64-bits long. On 32-bit > machines it is not. Use the 64-bit code only on 64-bit machines. > > This makes things work correctly on 32-bit machines. > > Signed-off-by: Simon Glass Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] TI changes for v2021.10-rc2
On Thu, Jul 29, 2021 at 11:36:38AM +0530, Lokesh Vutla wrote: > Hi Tom, > Please find the PR for master branch targeted for v2021.10-rc2 tag. > Details about the PR are updated in the tag message. > > Gitlab CI report: > https://source.denx.de/u-boot/custodians/u-boot-ti/-/pipelines/8468 > > > The following changes since commit b70b9b07463db2f6937c7ea6d7fb5122feb7ba1b: > > Prepare v2021.10-rc1 (2021-07-26 20:57:18 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-ti.git tags/ti-v2021.10-rc2 > > for you to fetch changes up to a6c64d255e5117bcf78aec6911d7c034fbfe46f7: > > board: ti: k2g: Program PadConfig_202 before locking RSTMUX8 (2021-07-29 > 10:42:22 +0530) > Please note that this brings in a number of warnings like: Warning (interrupts_extended_property): /ocp/usb@4740/usb@47401000: Missing property '#interrupt-cells' in node /ocp/i2c@44e0b000/tps@24 or bad phandle (referred from interrupts-extended[2]) which should be resolved, and may need to be resolved upstream as well. Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 5/5] test: dm: Add test for ECDSA UCLASS support
This test verifies that ECDSA_UCLASS is implemented, and that
ecdsa_verify() works as expected. The definition of "expected" is
"does not find a device, and returns -ENODEV".
The lack of a hardware-independent ECDSA implementation prevents us
from having one in the sandbox, for now.
Signed-off-by: Alexandru Gagniuc
Reviewed-by: Simon Glass
---
configs/sandbox_defconfig | 2 ++
test/dm/Makefile | 1 +
test/dm/ecdsa.c | 38 ++
3 files changed, 41 insertions(+)
create mode 100644 test/dm/ecdsa.c
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index bcd82f76ff..8bb981d6f5 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -299,3 +299,5 @@ CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
+CONFIG_ECDSA=y
+CONFIG_ECDSA_VERIFY=y
diff --git a/test/dm/Makefile b/test/dm/Makefile
index d5c42e7643..516f69d61c 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_DEVRES) += devres.o
obj-$(CONFIG_DMA) += dma.o
obj-$(CONFIG_VIDEO_MIPI_DSI) += dsi_host.o
obj-$(CONFIG_DM_DSA) += dsa.o
+obj-$(CONFIG_ECDSA_VERIFY) += ecdsa.o
obj-$(CONFIG_DM_ETH) += eth.o
ifneq ($(CONFIG_EFI_PARTITION),)
obj-$(CONFIG_FASTBOOT_FLASH_MMC) += fastboot.o
diff --git a/test/dm/ecdsa.c b/test/dm/ecdsa.c
new file mode 100644
index 00..da535c98b5
--- /dev/null
+++ b/test/dm/ecdsa.c
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Basic test of the ECDSA uclass and ecdsa_verify()
+ *
+ * ECDSA implementations in u-boot are hardware-dependent. Until we have a
+ * software implementation that can be compiled into the sandbox, all we can
+ * test is the uclass support.
+ *
+ * The uclass_get() test is redundant since ecdsa_verify() would also fail. We
+ * run both functions in order to isolate the cause more clearly. i.e. is
+ * ecdsa_verify() failing because the UCLASS is absent/broken?
+ */
+static int dm_test_ecdsa_verify(struct unit_test_state *uts)
+{
+ struct uclass *ucp;
+
+ struct checksum_algo algo = {
+ .checksum_len = 256,
+ };
+
+ struct image_sign_info info = {
+ .checksum = &algo,
+ };
+
+ ut_assertok(uclass_get(UCLASS_ECDSA, &ucp));
+ ut_assertnonnull(ucp);
+ ut_asserteq(-ENODEV, ecdsa_verify(&info, NULL, 0, NULL, 0));
+
+ return 0;
+}
+DM_TEST(dm_test_ecdsa_verify, UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.31.1
[PATCH 4/5] Kconfig: FIT_SIGNATURE should not select RSA_VERIFY
FIT signatures can now be implemented with ECDSA. The assumption that all FIT images are signed with RSA is no longer valid. Thus, instead of 'select'ing RSA, only 'imply' it. This doesn't change the defaults, but allows one to explicitly disable RSA support. Signed-off-by: Alexandru Gagniuc Reviewed-by: Simon Glass Reviewed-by: Igor Opaniuk --- common/Kconfig.boot | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/common/Kconfig.boot b/common/Kconfig.boot index f39df04bbf..0d4c38402c 100644 --- a/common/Kconfig.boot +++ b/common/Kconfig.boot @@ -76,8 +76,8 @@ config FIT_SIGNATURE bool "Enable signature verification of FIT uImages" depends on DM select HASH - select RSA - select RSA_VERIFY + imply RSA + imply RSA_VERIFY select IMAGE_SIGN_INFO select FIT_FULL_CHECK help @@ -186,8 +186,8 @@ config SPL_FIT_SIGNATURE select SPL_FIT select SPL_CRYPTO select SPL_HASH_SUPPORT - select SPL_RSA - select SPL_RSA_VERIFY + imply SPL_RSA + imply SPL_RSA_VERIFY select SPL_IMAGE_SIGN_INFO select SPL_FIT_FULL_CHECK -- 2.31.1
[PATCH 2/5] lib: ecdsa: Implement UCLASS_ECDSA verification on target
Implement the crypto_algo .verify() function for ecdsa256. Because
it backends on UCLASS_ECDSA, this change is focused on parsing the
keys from devicetree and passing this information to the specific
UCLASS driver.
Signed-off-by: Alexandru Gagniuc
Reviewed-by: Simon Glass
---
lib/Kconfig | 1 +
lib/Makefile | 1 +
lib/ecdsa/Kconfig| 23 +++
lib/ecdsa/Makefile | 1 +
lib/ecdsa/ecdsa-verify.c | 134 +++
5 files changed, 160 insertions(+)
create mode 100644 lib/ecdsa/Kconfig
create mode 100644 lib/ecdsa/Makefile
create mode 100644 lib/ecdsa/ecdsa-verify.c
diff --git a/lib/Kconfig b/lib/Kconfig
index fdcf7ea405..014a2f7f77 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -303,6 +303,7 @@ config AES
supported by the algorithm but only a 128-bit key is supported at
present.
+source lib/ecdsa/Kconfig
source lib/rsa/Kconfig
source lib/crypto/Kconfig
source lib/crypt/Kconfig
diff --git a/lib/Makefile b/lib/Makefile
index 07c2ccd7cf..8ba745faa0 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -60,6 +60,7 @@ endif
obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi/
obj-$(CONFIG_$(SPL_)MD5) += md5.o
+obj-$(CONFIG_ECDSA) += ecdsa/
obj-$(CONFIG_$(SPL_)RSA) += rsa/
obj-$(CONFIG_HASH) += hash-checksum.o
obj-$(CONFIG_SHA1) += sha1.o
diff --git a/lib/ecdsa/Kconfig b/lib/ecdsa/Kconfig
new file mode 100644
index 00..a95c4ff581
--- /dev/null
+++ b/lib/ecdsa/Kconfig
@@ -0,0 +1,23 @@
+config ECDSA
+ bool "Enable ECDSA support"
+ depends on DM
+ help
+ This enables the ECDSA (elliptic curve signature) algorithm for FIT
+ image verification in U-Boot. The ECDSA algorithm is implemented
+ using the driver model, so CONFIG_DM is required by this library.
+ See doc/uImage.FIT/signature.txt for more details.
+ ECDSA is enabled for mkimage regardless of this option.
+
+if ECDSA
+
+config ECDSA_VERIFY
+ bool "Enable ECDSA verification support in U-Boot."
+ help
+ Allow ECDSA signatures to be recognized and verified in U-Boot.
+
+config SPL_ECDSA_VERIFY
+ bool "Enable ECDSA verification support in SPL"
+ help
+ Allow ECDSA signatures to be recognized and verified in SPL.
+
+endif
diff --git a/lib/ecdsa/Makefile b/lib/ecdsa/Makefile
new file mode 100644
index 00..771d6d3135
--- /dev/null
+++ b/lib/ecdsa/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_$(SPL_)ECDSA_VERIFY) += ecdsa-verify.o
diff --git a/lib/ecdsa/ecdsa-verify.c b/lib/ecdsa/ecdsa-verify.c
new file mode 100644
index 00..0601700c4f
--- /dev/null
+++ b/lib/ecdsa/ecdsa-verify.c
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * ECDSA signature verification for u-boot
+ *
+ * This implements the firmware-side wrapper for ECDSA verification. It bridges
+ * the struct crypto_algo API to the ECDSA uclass implementations.
+ *
+ * Copyright (c) 2020, Alexandru Gagniuc
+ */
+
+#include
+#include
+#include
+
+/*
+ * Derive size of an ECDSA key from the curve name
+ *
+ * While it's possible to extract the key size by using string manipulation,
+ * use a list of known curves for the time being.
+ */
+static int ecdsa_key_size(const char *curve_name)
+{
+ if (!strcmp(curve_name, "prime256v1"))
+ return 256;
+ else
+ return 0;
+}
+
+static int fdt_get_key(struct ecdsa_public_key *key, const void *fdt, int node)
+{
+ int x_len, y_len;
+
+ key->curve_name = fdt_getprop(fdt, node, "ecdsa,curve", NULL);
+ key->size_bits = ecdsa_key_size(key->curve_name);
+ if (key->size_bits == 0) {
+ debug("Unknown ECDSA curve '%s'", key->curve_name);
+ return -EINVAL;
+ }
+
+ key->x = fdt_getprop(fdt, node, "ecdsa,x-point", &x_len);
+ key->y = fdt_getprop(fdt, node, "ecdsa,y-point", &y_len);
+
+ if (!key->x || !key->y)
+ return -EINVAL;
+
+ if (x_len != (key->size_bits / 8) || y_len != (key->size_bits / 8)) {
+ printf("%s: node=%d, curve@%p x@%p+%i y@%p+%i\n", __func__,
+ node, key->curve_name, key->x, x_len, key->y, y_len);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int ecdsa_verify_hash(struct udevice *dev,
+const struct image_sign_info *info,
+const void *hash, const void *sig, uint sig_len)
+{
+ const struct ecdsa_ops *ops = device_get_ops(dev);
+ const struct checksum_algo *algo = info->checksum;
+ struct ecdsa_public_key key;
+ int sig_node, key_node, ret;
+
+ if (!ops || !ops->verify)
+ return -ENODEV;
+
+ if (info->required_keynode > 0) {
+ ret = fdt_get_key(&key, info->fdt_blob, info->required_keynode);
+ if (ret < 0)
+ return ret;
+
+ return ops->verify(dev, &key, hash, algo->checksum_len,
+
[PATCH 3/5] arm: stm32mp1: Implement ECDSA signature verification
The STM32MP ROM provides several service. One of them is the ability
to verify ecdsa256 signatures. Hook the ROM API into the ECDSA uclass.
Signed-off-by: Alexandru Gagniuc
---
arch/arm/mach-stm32mp/Kconfig| 9 +++
arch/arm/mach-stm32mp/Makefile | 1 +
arch/arm/mach-stm32mp/ecdsa_romapi.c | 102 +++
3 files changed, 112 insertions(+)
create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c
diff --git a/arch/arm/mach-stm32mp/Kconfig b/arch/arm/mach-stm32mp/Kconfig
index ace07fd70f..4c1eeef165 100644
--- a/arch/arm/mach-stm32mp/Kconfig
+++ b/arch/arm/mach-stm32mp/Kconfig
@@ -172,6 +172,15 @@ config STM32_ETZPC
help
Say y to enable STM32 Extended TrustZone Protection
+config STM32_ECDSA_VERIFY
+ bool "STM32 ECDSA verification via the ROM API"
+ depends on SPL_ECDSA_VERIFY
+ default y
+ help
+ Say y to enable the uclass driver for ECDSA verification using the
+ ROM API provided on STM32MP.
+ The ROM API is only available during SPL for now.
+
config CMD_STM32KEY
bool "command stm32key to fuse public key hash"
default n
diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile
index 879c1961fe..391b47cf13 100644
--- a/arch/arm/mach-stm32mp/Makefile
+++ b/arch/arm/mach-stm32mp/Makefile
@@ -11,6 +11,7 @@ obj-y += bsec.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
obj-y += tzc400.o
+obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o
else
obj-y += cmd_stm32prog/
obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o
diff --git a/arch/arm/mach-stm32mp/ecdsa_romapi.c
b/arch/arm/mach-stm32mp/ecdsa_romapi.c
new file mode 100644
index 00..a2f63ff879
--- /dev/null
+++ b/arch/arm/mach-stm32mp/ecdsa_romapi.c
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * STM32MP ECDSA verification via the ROM API
+ *
+ * Implements ECDSA signature verification via the STM32MP ROM.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ROM_API_SUCCESS0x77
+#define ROM_API_ECDSA_ALGO_PRIME_256V1 1
+#define ROM_API_ECDSA_ALGO_BRAINPOOL_256 2
+
+#define ROM_API_OFFSET_ECDSA_VERIFY0x60
+
+struct ecdsa_rom_api {
+ uint32_t (*ecdsa_verify_signature)(const void *hash, const void *pubkey,
+ const void *signature,
+ uint32_t ecc_algo);
+};
+
+/*
+ * Without forcing the ".data" section, this would get saved in ".bss". BSS
+ * will be cleared soon after, so it's not suitable.
+ */
+static uintptr_t rom_api_loc __section(".data");
+
+/*
+ * The ROM gives us the API location in r0 when starting. This is only
available
+ * during SPL, as there isn't (yet) a mechanism to pass this on to u-boot.
+ */
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
+ unsigned long r3)
+{
+ rom_api_loc = r0;
+ save_boot_params_ret();
+}
+
+static void stm32mp_rom_get_ecdsa_functions(struct ecdsa_rom_api *rom)
+{
+ uintptr_t verify_ptr = rom_api_loc + ROM_API_OFFSET_ECDSA_VERIFY;
+
+ rom->ecdsa_verify_signature = *(void **)verify_ptr;
+}
+
+static int ecdsa_key_algo(const char *curve_name)
+{
+ if (!strcmp(curve_name, "prime256v1"))
+ return ROM_API_ECDSA_ALGO_PRIME_256V1;
+ else if (!strcmp(curve_name, "brainpool256"))
+ return ROM_API_ECDSA_ALGO_BRAINPOOL_256;
+ else
+ return -ENOPROTOOPT;
+}
+
+static int romapi_ecdsa_verify(struct udevice *dev,
+ const struct ecdsa_public_key *pubkey,
+ const void *hash, size_t hash_len,
+ const void *signature, size_t sig_len)
+{
+ struct ecdsa_rom_api rom;
+ uint8_t raw_key[64];
+ uint32_t rom_ret;
+ int algo;
+
+ /* The ROM API can only handle 256-bit ECDSA keys. */
+ if (sig_len != 64 || hash_len != 32 || pubkey->size_bits != 256)
+ return -EINVAL;
+
+ algo = ecdsa_key_algo(pubkey->curve_name);
+ if (algo < 0)
+ return algo;
+
+ /* The ROM API wants the (X, Y) coordinates concatenated. */
+ memcpy(raw_key, pubkey->x, 32);
+ memcpy(raw_key + 32, pubkey->y, 32);
+
+ stm32mp_rom_get_ecdsa_functions(&rom);
+ rom_ret = rom.ecdsa_verify_signature(hash, raw_key, signature, algo);
+
+ return rom_ret == ROM_API_SUCCESS ? 0 : -EPERM;
+}
+
+static const struct ecdsa_ops rom_api_ops = {
+ .verify = romapi_ecdsa_verify,
+};
+
+U_BOOT_DRIVER(stm32mp_rom_api_ecdsa) = {
+ .name = "stm32mp_rom_api_ecdsa",
+ .id = UCLASS_ECDSA,
+ .ops= &rom_api_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+
+U_BOOT_DRVINFO(stm32mp_rom_api_ecdsa) = {
+ .name = "stm32mp_rom_api_ecdsa",
+};
--
2.31.1
[PATCH 1/5] dm: crypto: Define UCLASS API for ECDSA signature verification
Define a UCLASS API for verifying ECDSA signatures. Unlike
UCLASS_MOD_EXP, which focuses strictly on modular exponentiation,
the ECDSA class focuses on verification. This is done so that it
better aligns with mach-specific implementations, such as stm32mp.
Signed-off-by: Alexandru Gagniuc
---
include/crypto/ecdsa-uclass.h | 39 +++
include/dm/uclass-id.h| 1 +
2 files changed, 40 insertions(+)
create mode 100644 include/crypto/ecdsa-uclass.h
diff --git a/include/crypto/ecdsa-uclass.h b/include/crypto/ecdsa-uclass.h
new file mode 100644
index 00..189843820a
--- /dev/null
+++ b/include/crypto/ecdsa-uclass.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (c) 2020, Alexandru Gagniuc
+ */
+
+#include
+
+/**
+ * struct ecdsa_public_key - ECDSA public key properties
+ *
+ * The struct has pointers to the (x, y) curve coordinates to an ECDSA public
+ * key, as well as the name of the ECDSA curve. The size of the key is inferred
+ * from the 'curve_name'
+ */
+struct ecdsa_public_key {
+ const char *curve_name; /* Name of curve, e.g. "prime256v1" */
+ const void *x; /* x coordinate of public key */
+ const void *y; /* y coordinate of public key */
+ unsigned int size_bits; /* key size in bits, derived from curve name */
+};
+
+struct ecdsa_ops {
+ /**
+* Verify signature of hash against given public key
+*
+* @dev:ECDSA Device
+* @pubkey: ECDSA public key
+* @hash: Hash of binary image
+* @hash_len: Length of hash in bytes
+* @signature: Signature in a raw (R, S) point pair
+* @sig_len:Length of signature in bytes
+*
+* This function verifies that the 'signature' of the given 'hash' was
+* signed by the private key corresponding to 'pubkey'.
+*/
+ int (*verify)(struct udevice *dev, const struct ecdsa_public_key
*pubkey,
+ const void *hash, size_t hash_len,
+ const void *signature, size_t sig_len);
+};
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 9d474533ba..e7edd409f3 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -47,6 +47,7 @@ enum uclass_id {
UCLASS_DSI_HOST,/* Display Serial Interface host */
UCLASS_DMA, /* Direct Memory Access */
UCLASS_DSA, /* Distributed (Ethernet) Switch Architecture */
+ UCLASS_ECDSA, /* Elliptic curve cryptographic device */
UCLASS_EFI, /* EFI managed devices */
UCLASS_ETH, /* Ethernet device */
UCLASS_ETH_PHY, /* Ethernet PHY device */
--
2.31.1
[PATCH 0/5] Enable ECDSA FIT verification for stm32mp
This series is based on the latest master, so no patch dependencies. Q: Will there be a software-only implementation of ECDSA ? A: That is the goal, so that we can have more extensive testing with the sandbox. I don not have the bandwidth to implement it. There has been an initial poer of software ecdsa here: https://github.com/timr11/u-boot/tree/ecdsa-vrf-1 Q: Can more code be shared with the RSA verification path? A: Probably yes. Mostly having to do with parsing the "/signature" node and "key-name-hint"s in the u-boot FDT. Although there isn't any copypasted RSA code, or code with substantial similarity. Changes since v5: - Fixed clang warning stemming from test/dm/ecdsa.c Changes since v4: - Use U_BOOT_CRYPTO_ALGO() to add ECDSA to .u_boot_list - No need to #define IMAGE_ENABLE_VERIFY_ECDSA - Use ut_asserteq(x, -ENODEV) instead of ut_assert(x == -ENODEV) Changes since v3: - Remove unused ecdsa_check_key() function Changes since v2: - Spell out "elliptic curve" in Kconfig (Although RSA isn't spelled out) Changes since v1: - Add test to make sure the UCLASS is enabled - Fix check against wrong sig_len in ecdsa_romapi.c - s/U_BOOT_DEVICE/U_BOOT_DRVINFO/ - Use "if(!ret)" instead of "if (ret == 0)" - Use uclass_first_device_err() instead of uclass_fi Alexandru Gagniuc (5): dm: crypto: Define UCLASS API for ECDSA signature verification lib: ecdsa: Implement UCLASS_ECDSA verification on target arm: stm32mp1: Implement ECDSA signature verification Kconfig: FIT_SIGNATURE should not select RSA_VERIFY test: dm: Add test for ECDSA UCLASS support arch/arm/mach-stm32mp/Kconfig| 9 ++ arch/arm/mach-stm32mp/Makefile | 1 + arch/arm/mach-stm32mp/ecdsa_romapi.c | 102 common/Kconfig.boot | 8 +- configs/sandbox_defconfig| 2 + include/crypto/ecdsa-uclass.h| 39 include/dm/uclass-id.h | 1 + lib/Kconfig | 1 + lib/Makefile | 1 + lib/ecdsa/Kconfig| 23 + lib/ecdsa/Makefile | 1 + lib/ecdsa/ecdsa-verify.c | 134 +++ test/dm/Makefile | 1 + test/dm/ecdsa.c | 38 14 files changed, 357 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c create mode 100644 include/crypto/ecdsa-uclass.h create mode 100644 lib/ecdsa/Kconfig create mode 100644 lib/ecdsa/Makefile create mode 100644 lib/ecdsa/ecdsa-verify.c create mode 100644 test/dm/ecdsa.c -- 2.31.1
Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
On 7/29/21 5:23 PM, Tom Rini wrote:
On Thu, Jul 29, 2021 at 05:01:09PM +0200, Marek Vasut wrote:
On 7/29/21 9:22 AM, Jan Kiszka wrote:
From: Jan Kiszka
This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
While the goal is valid and there is surely unused memory in that area,
we also have a lot of crucial things still located at the top-of-memory
while running lmb_alloc_base. Such things are the page table (tlb_addr),
relocated U-Boot and the active stack. Possibly more. So this patch was
premature, we will need relocations of those things first if we want to
use the range.
Fixes booting on the IOT2050, but likely also on other boards. It got
stuck on relocating the FDT - over the relocated U-Boot code.
Signed-off-by: Jan Kiszka
---
Practically,
void arch_lmb_reserve(struct lmb *lmb)
{
lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
}
So this is wrong and breaks a use case on rcar3, where there is more stuff
which should not be reserved until the ram top.
I suspect the real fix here is to protect only the stack and tlb on arm64,
not just everything from current stack bottom to ram top ?
Wait, what? There's never been a U-Boot release that didn't reserve
that area
That does not mean such a huge reservation is correct.
I apologize for not being overly clear in my answer, I already told Jan
I am highly overloaded and simply lack the capacity to analyze this
problem thoroughly on a short notice.
so when did rcar3 introduce something there that shouldn't be
reserved? And you had phrased this to me on IRC as about reserving spot
for ATAGS, and that not being needed of course on arm64. But that's not
what's going on. Perhaps the answer is that rcar3 needs to introduce a
board_lmb_reserve to free the normal arch one and provide whatever more
narrow scope it needs.
Based on the commit message 2359fa7a878 ("arm: bootm: Disable LMB
reservation for command line and board info on arm64") , this is about
ATAGS and we really don't need to reserve those on arm64.
I didn't hit the tlb reservation issue Jan has in my tests on rcar3, so
I suspect that is the real problem here, i.e. we need some more fine
grained lmb reservation on arm64 ?
[PATCH] board: freescale: t208xrdb: enable Power-On Reset for rev D boards
From: Camelia Groza
Starting with board revision D, the MISCCSR CPLD register needs to be
configured to enable Power-on Reset for software reset commands.
Signed-off-by: Camelia Groza
---
board/freescale/t208xrdb/cpld.h | 4
board/freescale/t208xrdb/t208xrdb.c | 7 +++
2 files changed, 11 insertions(+)
diff --git a/board/freescale/t208xrdb/cpld.h b/board/freescale/t208xrdb/cpld.h
index a623b1811faf..3139c2b85fd1 100644
--- a/board/freescale/t208xrdb/cpld.h
+++ b/board/freescale/t208xrdb/cpld.h
@@ -1,6 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* Copyright 2014 Freescale Semiconductor
+ * Copyright 2021 NXP
*/
/*
@@ -42,3 +43,6 @@ void cpld_write(unsigned int reg, u8 value);
/* RSTCON Register */
#define CPLD_RSTCON_EDC_RST0x04
+
+/* MISCCSR Register */
+#define CPLD_MISC_POR_EN 0x30
diff --git a/board/freescale/t208xrdb/t208xrdb.c
b/board/freescale/t208xrdb/t208xrdb.c
index 1f0cdee0b863..947dd6aa9f3a 100644
--- a/board/freescale/t208xrdb/t208xrdb.c
+++ b/board/freescale/t208xrdb/t208xrdb.c
@@ -128,6 +128,13 @@ int misc_init_r(void)
reg |= CPLD_RSTCON_EDC_RST;
CPLD_WRITE(reset_ctl, reg);
+ /* Enable POR for boards revisions D and up */
+ if (get_hw_revision() >= 'D') {
+ reg = CPLD_READ(misc_csr);
+ reg |= CPLD_MISC_POR_EN;
+ CPLD_WRITE(misc_csr, reg);
+ }
+
return 0;
}
--
2.17.1
Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
Hi Artem On 7/29/21 9:52 AM, Artem Panfilov wrote: On 29.07.2021 15:59, Tom Rini wrote: Well yes, this is part of the question now, is there enough interest in the old version to bother with? The other part of the question is what's being built now that wasn't being built before, and is that a bug or a feature (a less CONFIG-dependent set of tools is good for generic distributions). OK, if someone else will report the same issue after u-boot release, then it should be fixed. Currently, I am okay with my local fix by disabling the CONFIG_TOOLS_LIBCRYPTO option. ECDSA signing was not verified against a libcrypto that old. Given that signatures are non-deterministic, I doubt we could have a CI test that says old-libcrypto, known block must equal known signature. When we added ECDSA, there was not a need to consider old libcrypto versions, but I also did not pay attention to the #ifdefs in the much older RSA path. I'm sorry that you had to go through the frustrations of getting a patch rejected which does something the codebase already does. I am going to take a look at cleaning up the RSA path. There's no point in maintaining backwards compatibility if we're not doing it across the board. Alex
Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
On Thu, Jul 29, 2021 at 05:01:09PM +0200, Marek Vasut wrote:
> On 7/29/21 9:22 AM, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
> >
> > While the goal is valid and there is surely unused memory in that area,
> > we also have a lot of crucial things still located at the top-of-memory
> > while running lmb_alloc_base. Such things are the page table (tlb_addr),
> > relocated U-Boot and the active stack. Possibly more. So this patch was
> > premature, we will need relocations of those things first if we want to
> > use the range.
> >
> > Fixes booting on the IOT2050, but likely also on other boards. It got
> > stuck on relocating the FDT - over the relocated U-Boot code.
> >
> > Signed-off-by: Jan Kiszka
> > ---
> >
> > Practically,
> >
> > void arch_lmb_reserve(struct lmb *lmb)
> > {
> > lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
> > }
>
> So this is wrong and breaks a use case on rcar3, where there is more stuff
> which should not be reserved until the ram top.
>
> I suspect the real fix here is to protect only the stack and tlb on arm64,
> not just everything from current stack bottom to ram top ?
Wait, what? There's never been a U-Boot release that didn't reserve
that area so when did rcar3 introduce something there that shouldn't be
reserved? And you had phrased this to me on IRC as about reserving spot
for ATAGS, and that not being needed of course on arm64. But that's not
what's going on. Perhaps the answer is that rcar3 needs to introduce a
board_lmb_reserve to free the normal arch one and provide whatever more
narrow scope it needs.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
On 7/29/21 9:22 AM, Jan Kiszka wrote:
From: Jan Kiszka
This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
While the goal is valid and there is surely unused memory in that area,
we also have a lot of crucial things still located at the top-of-memory
while running lmb_alloc_base. Such things are the page table (tlb_addr),
relocated U-Boot and the active stack. Possibly more. So this patch was
premature, we will need relocations of those things first if we want to
use the range.
Fixes booting on the IOT2050, but likely also on other boards. It got
stuck on relocating the FDT - over the relocated U-Boot code.
Signed-off-by: Jan Kiszka
---
Practically,
void arch_lmb_reserve(struct lmb *lmb)
{
lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
}
So this is wrong and breaks a use case on rcar3, where there is more
stuff which should not be reserved until the ram top.
I suspect the real fix here is to protect only the stack and tlb on
arm64, not just everything from current stack bottom to ram top ?
[PATCH] mmc: Add support for enumerating MMC card in a given mode using mmc command
Add support for enumerating MMC card in a given mode using mmc rescan and
mmc dev commands. The speed mode is provided as the last argument in these
commands and is indicated using the index from enum bus_mode in
include/mmc.h. A speed mode can be set only if it has already been enabled
in the device tree.
Signed-off-by: Aswath Govindraju
---
cmd/Kconfig | 10 ++
cmd/mmc.c| 71
drivers/mmc/mmc-uclass.c | 3 ++
drivers/mmc/mmc.c| 18 ++
include/mmc.h| 4 +++
5 files changed, 85 insertions(+), 21 deletions(-)
diff --git a/cmd/Kconfig b/cmd/Kconfig
index ffef3cc76ca4..3a857b3f6e2e 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2389,4 +2389,14 @@ config CMD_UBIFS
help
UBIFS is a file system for flash devices which works on top of UBI.
+config MMC_SPEED_MODE_SET
+ bool "set speed mode using mmc command"
+ depends on CMD_MMC
+ default n
+ help
+ Enable setting speed mode using mmc rescan and mmc dev commands.
+ The speed mode is provided as the last argument in these commands
+ and is indicated using the index from enum bus_mode in
+ include/mmc.h. A speed mode can be set only if it has already
+ been enabled in the device tree.
endmenu
diff --git a/cmd/mmc.c b/cmd/mmc.c
index b942576b58ac..073e87d69634 100644
--- a/cmd/mmc.c
+++ b/cmd/mmc.c
@@ -120,7 +120,9 @@ static void print_mmcinfo(struct mmc *mmc)
}
}
}
-static struct mmc *init_mmc_device(int dev, bool force_init)
+
+static struct mmc *init_mmc_device(int dev, bool force_init,
+ enum bus_mode speed_mode)
{
struct mmc *mmc;
mmc = find_mmc_device(dev);
@@ -134,6 +136,11 @@ static struct mmc *init_mmc_device(int dev, bool
force_init)
if (force_init)
mmc->has_init = 0;
+
+#if CONFIG_IS_ENABLED(MMC_SPEED_MODE_SET)
+ mmc->user_speed_mode = speed_mode;
+#endif
+
if (mmc_init(mmc))
return NULL;
@@ -159,7 +166,7 @@ static int do_mmcinfo(struct cmd_tbl *cmdtp, int flag, int
argc,
}
}
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -293,7 +300,7 @@ static int do_mmcrpmb(struct cmd_tbl *cmdtp, int flag,
if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
return CMD_RET_SUCCESS;
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -338,7 +345,7 @@ static int do_mmc_read(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -387,7 +394,7 @@ static int do_mmc_sparse_write(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_FAILURE;
}
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -431,7 +438,7 @@ static int do_mmc_write(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[2], NULL, 16);
cnt = simple_strtoul(argv[3], NULL, 16);
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -460,7 +467,7 @@ static int do_mmc_erase(struct cmd_tbl *cmdtp, int flag,
blk = simple_strtoul(argv[1], NULL, 16);
cnt = simple_strtoul(argv[2], NULL, 16);
- mmc = init_mmc_device(curr_device, false);
+ mmc = init_mmc_device(curr_device, false, MMC_MODES_END);
if (!mmc)
return CMD_RET_FAILURE;
@@ -482,8 +489,19 @@ static int do_mmc_rescan(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
struct mmc *mmc;
+ enum bus_mode speed_mode = MMC_MODES_END;
+
+ if (argc == 1) {
+ mmc = init_mmc_device(curr_device, true, MMC_MODES_END);
+ } else if (argc == 2) {
+ /* parse the mode */
+ speed_mode = simple_strtoul(argv[1], NULL, 10);
+ /* Need to pass the the speed mode required too */
+ mmc = init_mmc_device(curr_device, true, speed_mode);
+ } else {
+ return CMD_RET_USAGE;
+ }
- mmc = init_mmc_device(curr_device, true);
if (!mmc)
return CMD_RET_FAILURE;
@@ -496,7 +514,7 @@ static int do_mmc_part(struct cmd_tbl *cmdtp, int flag,
struct blk_desc *mmc_dev;
str
Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
On 29.07.2021 15:59, Tom Rini wrote: > Well yes, this is part of the question now, is there enough interest in > the old version to bother with? The other part of the question is > what's being built now that wasn't being built before, and is that a bug > or a feature (a less CONFIG-dependent set of tools is good for generic > distributions). OK, if someone else will report the same issue after u-boot release, then it should be fixed. Currently, I am okay with my local fix by disabling the CONFIG_TOOLS_LIBCRYPTO option. --- Artem
Re: EFI from usb HDD
Hi, On 6/10/21 2:59 PM, AKASHI Takahiro wrote: > On Thu, Jun 10, 2021 at 02:31:46PM +0200, Michal Simek wrote: >> >> >> On 6/10/21 12:51 PM, Heinrich Schuchardt wrote: >>> On 6/10/21 12:04 PM, Michal Simek wrote: Hi, On 6/10/21 11:47 AM, Heinrich Schuchardt wrote: > On 6/10/21 10:44 AM, Michal Simek wrote: >> Hi, >> >> I am playing with booting from USB via EFI. And I see very weird >> behavior. I have burnt image with grub to USB flashdisk and I have >> tested it on 3 zynqmp boards. zcu102, zcu104 and SOM Kria board. >> On zcu102 grub is going to boot menu and everything is working fine as >> expected. >> On zcu104 and SOM Kria I am able to get grub not to menu. When I list >> partitions in grub I see that only SDs are listed: >> grub> ls >> (hd0) (hd0,msdos1) (hd1) (hd1,msdos1) > > Hello Michal, > > thanks for sharing your observations. > > What devices do hd0 and hd1 relate to? > >> >> On zcu102(working board) I also see usb(gpt) partitions and SD. >> grub> ls >> (hd0) (hd0,gpt2) (hd0,gpt1) (hd1) (hd1,msdos1) >> > > GPT and MBR partitioning are independent of the device type. > >> >> On zcu104 I see one more error message >> "PE image measurement failed" > > This is related to CONFIG_EFI_TCG2_PROTOCOL=y. Do you have a TPMv2? This > will not stop disk enumeration. > >> But I can't see it on SOM. >> >> U-Boot image is just the same for all boards. I am using generic >> xilinx_zynqmp_virt_defconfig. >> >> When I compare DT description for USB between zcu102 and zcu104 they >> are >> the same. SOM doesn't have usb enabled by default (but I enabled it) >> but >> grub starts which means that communication with USB is fine. >> >> It is based on my latest patches available here. >> u-boot/custodians/u-boot-microblaze.git (usb-efi-issue branch) >> >> Also when I list usb I see all partitions just fine. >> ZynqMP> part list usb 0 >> >> Partition Map for USB device 0 -- Partition Type: EFI >> >> Part Start LBA End LBA Name >> Attributes >> Type GUID >> Partition GUID >> 1 0x0800 0x001007fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 0e7f8b3d-296b-4720-be9d-c4687d3c4a77 >> 2 0x00100800 0x001197fe "Microsoft basic data" >> attrs: 0x >> type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 >> type: data >> guid: 8892eddc-231a-4e6e-a5e1-c310f4482fb7 >> >> >> Do you have any idea why on one system is working fine to get to menu >> and on others there is an issue to get all partitions even u-boot is >> able to see them and can work with them. >> >> Thanks, >> Michal >> > > Where is the GRUB binary? - If it is in EFI/boot/bootaa64.efi, it could > be that the USB sub-system is simply not initialized yet when the boot > manager is called by distroboot. > > For testing partition detection in the UEFI sub-system it is enough > to run > > efidebug devices > > Until yesterday we had a problem with partition numbers >= 10, cf. > > efi_loader: partition numbers are hexadecimal > https://source.denx.de/u-boot/u-boot/-/commit/3dca77b1dc1b6dbf9c8b51572fe4b0553cef009f > > > > Block devices are enumerated in efi_disk_register(). Please, try to add > debug output there to elucidate the problem. I found where the problem is. First of all zcu102 didn't use the same image as others (it wasn't updated properly). When you have CONFIG_EFI_CAPSULE_ON_DISK_EARLY that efi_disk_register() is called before usb block devices are detected and registered that's why grub doesn't see them. >>> >>> The problem is CONFIG_EFI_SETUP_EARLY=y required by >>> CONFIG_EFI_CAPSULE_ON_DISK_EARLY. >>> >>> Why is USB initialized later then MMC? >> >> It is not just usb. SCSI/sata are behaving in the same way too. >> >>> >>> Overall we have a deficiency in the UEFI implementation in that we >>> cannot deal with block devices added or removed after initialization. >>> >>> Here integration with the driver model is missing. >> >> Right. And also there are commands which can create MBR partitions and I >> expect when you write image to SD and then run rescan or so you could >> get other partitions too. >> Maybe hook via part_init()? with removing efi_disk_register. > > For the record, I have proposed my ideas several times[1], [2]. > I'm, however, no longer working on this issue as I have shifted > my focus to UEFI secure boot and capsule update. > > -Takahiro Akashi > > [1] https:
Re: [PATCH v2 7/9] Make EFI_LOADER depend on DM and OF_CONTROL
On Wed, Jul 28, 2021 at 07:44:37PM -0600, Simon Glass wrote: > Hi, > > On Wed, 28 Jul 2021 at 17:55, Tom Rini wrote: > > > > On Thu, Jul 29, 2021 at 01:45:49AM +0200, Heinrich Schuchardt wrote: > > > > > > > > > On 7/27/21 12:07 AM, Tom Rini wrote: > > > > On Fri, Jul 02, 2021 at 12:36:18PM -0600, Simon Glass wrote: > > > > > > > > > This feature should never have been made available when driver model > > > > > or devicetree are disabled. Add these as conditions, so that we don't > > > > > create even more barriers to migration. > > > > > > > > > > Add a note about the substantial size increment associated with this > > > > > option. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > --- > > > > > > > > > > Changes in v2: > > > > > - Split out new patch to make EFI_LOADER depend on DM and OF_CONTROL > > > > > - Note the approximate size of this feature in the help > > > > > > > > > > lib/efi_loader/Kconfig | 4 +++- > > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > index 6242caceb7f..466abfed300 100644 > > > > > --- a/lib/efi_loader/Kconfig > > > > > +++ b/lib/efi_loader/Kconfig > > > > > @@ -1,6 +1,6 @@ > > > > > config EFI_LOADER > > > > > bool "Support running UEFI applications" > > > > > - depends on OF_LIBFDT && ( \ > > > > > + depends on OF_LIBFDT && DM && OF_CONTROL && ( \ > > > > > > Didn't Tom eliminate all boards without CONFIG_DM? Shouldn't we get rid > > > of this symbol? > > > > No, but I did send out a message about that today as we're very close. > > Much closer than I had expected us to be. > > Note we will still have SPL_DM, I think. Right. > > > Are there boards using DM and not OF_CONTROL or OF_CONTROL and not DM? > > > > Yes, a few. It's vexpress_aemv8a_semi, warp (fixed by > > https://patchwork.ozlabs.org/project/uboot/patch/20210402180552.1075997-2-pbrobin...@gmail.com/ > > so false positive), cm_t335, devkit8000, armadillo-800eva, kzm9g and sniper. > > > > > Why are these separate symbols? Isn't this symbol to be eliminated, too? > > > > Simon? > > If we do eliminate DM it will be in a separate series. Like Tom I am > pleasantly surprised at how close we are. > > But please let's consider patches on their merits. It is fine to reply > with a wishlist but even better to reply with a follow-up patch. OK. So, build-wise, EFI_LOADER does not require OF_CONTROL. > Somewhat related, I think we need to create a separate symbol which > means (OF_CONTROL && !OF_PLATDATA) so we can just check one thing. > > Also I think we should push of-platdata, since otherwise we're going > to hit the same problem of migrating SPL boards to DM one day. Note that we don't have CONFIG_OF_PLATDATA just CONFIG_(SPL|TPL)_OF_PLATDATA. > > > lib/efi_loader/efi_disk.c is the only place where we maintain duplicate > > > code for DM and non-DM. A dependency on CONFIG_BLK (which itself depends > > > on CONFIG_DM) would make more sense to me. But only in a patch > > > eliminating the non-BLK code. > > > > I just know that off-hand, partition + disk + block has some corner > > case, but maybe that corner case is unintentional in terms of usage > > today. > > > > > > > ARM && (SYS_CPU = arm1136 || \ > > > > > SYS_CPU = arm1176 || \ > > > > > SYS_CPU = armv7 || \ > > > > > @@ -25,6 +25,8 @@ config EFI_LOADER > > > > > will expose the UEFI API to a loaded application, > > > > > enabling it to > > > > > reuse U-Boot's device drivers. > > > > > > > > > > + For ARM 32-bit, this adds about 90KB to the size of U-Boot. > > > > > + > > > > > > There is no unit ISO prefix K. Do you mean KiB? > > > > > > 90 KiB may be the value today. Will you update it regularly? Otherwise > > > don't put a number here. > > > > > > I can't see that the effect on size is truly architecture specific. Why > > > do you refer to 32bit ARM? > > > > > > Such a comment would better fit into a documentation chapter on > > > downsizing U-Boot. > > > > Yes, we should probably drop that specific note. > > From my POV I really like these notes in Kconfig. They appear in a few > places and provide people with rough guidance. I'd like to see more of > them. I don't know how we can keep them up-to-date, although I'd argue > that they should stay constant, if we are holding to our no-bloat > ideal. I feel like EFI gets a bit of an undeserved reputation here. It's not growing any worse than the rest of the world is over fixes and error correction (which is to say, 16/32/40 bytes here and there). And there's not "big" new default features coming in. -- Tom signature.asc Description: PGP signature
Re: Debugging dtoc?
On Wed, Jul 28, 2021 at 07:27:08PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Wed, 28 Jul 2021 at 17:28, Simon Glass wrote:
> >
> > Hi again,
> >
> > On Mon, 26 Jul 2021 at 08:06, Simon Glass wrote:
> > >
> > > Hi Tom,
> > >
> > > On Sun, 25 Jul 2021 at 15:10, Tom Rini wrote:
> > > >
> > > > So, I'm trying to fix the problem on am335x_evm (and some family
> > > > configs) with needing SPL_OF_CONTROL enabled. This is mostly fine just
> > > > enabling the option, except on am335x_evm itself, which is the
> > > > kitchen-sink config and overflows memory. I've gone with switching to
> > > > SPL_OF_PLATDATA there as am335x in general has all of the U_BOOT_DRVINFO
> > > > entries it needs I believe. But, with the following patch:
> > > >
> > > > diff --git a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > index 4cf5f9928d58..514f682cac99 100644
> > > > --- a/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > +++ b/arch/arm/dts/am335x-evm-u-boot.dtsi
> > > > @@ -8,6 +8,7 @@
> > > > &l4_per {
> > > >
> > > > segment@30 {
> > > > + u-boot,dm-pre-reloc;
> > > >
> > > > target-module@e000 {
> > > > u-boot,dm-pre-reloc;
> > > > diff --git a/configs/am335x_boneblack_vboot_defconfig
> > > > b/configs/am335x_boneblack_vboot_defconfig
> > > > index a0baeec79edd..ffeefd1a0087 100644
> > > > --- a/configs/am335x_boneblack_vboot_defconfig
> > > > +++ b/configs/am335x_boneblack_vboot_defconfig
> > > > @@ -31,6 +31,7 @@ CONFIG_CMD_SPL=y
> > > > # CONFIG_CMD_SETEXPR is not set
> > > > CONFIG_BOOTP_DNS2=y
> > > > CONFIG_OF_CONTROL=y
> > > > +CONFIG_SPL_OF_CONTROL=y
> > > > CONFIG_ENV_OVERWRITE=y
> > > > CONFIG_ENV_IS_IN_MMC=y
> > > > CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
> > > > diff --git a/configs/am335x_evm_defconfig b/configs/am335x_evm_defconfig
> > > > index a33efff42a74..f35b2a02f56b 100644
> > > > --- a/configs/am335x_evm_defconfig
> > > > +++ b/configs/am335x_evm_defconfig
> > > > @@ -37,13 +37,16 @@ CONFIG_MTDIDS_DEFAULT="nand0=nand.0"
> > > >
> > > > CONFIG_MTDPARTS_DEFAULT="mtdparts=nand.0:128k(NAND.SPL),128k(NAND.SPL.backup1),128k(NAND.SPL.backup2),128k(NAND.SPL.backup3),256k(NAND.u-boot-spl-os),1m(NAND.u-boot),128k(NAND.u-boot-env),128k(NAND.u-boot-env.backup1),8m(NAND.kernel),-(NAND.file-system)"
> > > > # CONFIG_SPL_EFI_PARTITION is not set
> > > > CONFIG_OF_CONTROL=y
> > > > +CONFIG_SPL_OF_CONTROL=y
> > > > CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk
> > > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > +CONFIG_SPL_OF_PLATDATA=y
> > > > CONFIG_ENV_OVERWRITE=y
> > > > CONFIG_SYS_RELOC_GD_ENV_ADDR=y
> > > > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
> > > > CONFIG_SPL_ENV_IS_NOWHERE=y
> > > > CONFIG_VERSION_VARIABLE=y
> > > > CONFIG_BOOTP_SEND_HOSTNAME=y
> > > > +# CONFIG_SPL_SIMPLE_BUS is not set
> > > > CONFIG_BOOTCOUNT_LIMIT=y
> > > > CONFIG_CLK=y
> > > > CONFIG_CLK_CDCE9XX=y
> > > > diff --git a/configs/am335x_evm_spiboot_defconfig
> > > > b/configs/am335x_evm_spiboot_defconfig
> > > > index 8f0c330674a9..4a2a56a9af9e 100644
> > > > --- a/configs/am335x_evm_spiboot_defconfig
> > > > +++ b/configs/am335x_evm_spiboot_defconfig
> > > > @@ -32,6 +32,7 @@ CONFIG_BOOTP_DNS2=y
> > > > CONFIG_CMD_MTDPARTS=y
> > > > # CONFIG_SPL_EFI_PARTITION is not set
> > > > CONFIG_OF_CONTROL=y
> > > > +CONFIG_SPL_OF_CONTROL=y
> > > > CONFIG_OF_LIST="am335x-evm am335x-bone am335x-boneblack am335x-evmsk
> > > > am335x-bonegreen am335x-icev2 am335x-pocketbeagle"
> > > > CONFIG_ENV_OVERWRITE=y
> > > > # CONFIG_ENV_IS_IN_FAT is not set
> > > >
> > > > I get the following failure and I don't see how to debug this:
> > > > DTOCspl/dts/dt-plat.c
> > > > Traceback (most recent call last):
> > > > File "./tools/dtoc/dtoc", line 115, in
> > > > args.phase, instantiate=args.instantiate)
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 1223, in run_steps
> > > > outfile.method(plat)
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 1081, in generate_plat
> > > > self.output_node_plat(node)
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 1023, in output_node_plat
> > > > self._output_values(node)
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 812, in _output_values
> > > > self._output_prop(node, node.props[pname])
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 798, in _output_prop
> > > > self._output_list(node, prop)
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/dtoc/../dtoc/dtb_platdata.py",
> > > > line 628, in _output_list
> > > > vals.append(get_value(prop.type, val))
> > > > File
> > > > "/home/trini/work/u-boot/u-boot/tools/d
Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
On Thu, Jul 29, 2021 at 01:40:41PM +0300, Artem Panfilov wrote: > On 29.07.2021 02:43, Tom Rini wrote: > > > > Yes, true. And that's two 1-line if/else. That's a reasonable to me > > level of effort to keep supporting older hosts. Your patch is adding in > > 60 lines. I really do want to dig a bit more here. > > For me, it doesn't matter how many lines of code were added if I can't > build host tools with older OpenSSL versions. So what's the point > of keeping OpenSSL backward compatibility? Well yes, this is part of the question now, is there enough interest in the old version to bother with? The other part of the question is what's being built now that wasn't being built before, and is that a bug or a feature (a less CONFIG-dependent set of tools is good for generic distributions). > > And honestly, part of my concerns also go around "who is going to > > maintain / test this area?". We don't have these older versions in CI > > (or we would have seen the problem before merging). Are you > > volunteering to support the relevant code areas here but on older > > openssl/libressl ? > > We already have a nightly Jenkins CI job that tracks u-boot master > and sends internal reports. > > The best way would be to testing in the upstream azure pipeline. > > You could add the following steps in your trini/u-boot-gitlab-ci-runner > docker image: > wget -O - https://www.openssl.org/source/old/1.0.2/openssl-1.0.2k.tar.gz | > tar -C /opt -xz && \ > cd /opt/openssl-1.0.2k/ && ./config shared && \ > make && \ > make install > > In azure pipeline add new job for testing with old OpenSSL: > make tools-only_config tools-only NO_SDL=1 \ > HOSTLDFLAGS="-ldl -L/usr/local/ssl/lib" \ > HOSTCFLAGS="-I/usr/local/ssl/include" And the next time something breaks, are you going to be available to fix it? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] mtd: spi-nor: Respect flash's hwcaps in spi_nor_adjust_hwcaps()
Hi Pratyush,
On Thu, Jul 29, 2021 at 8:08 PM Pratyush Yadav wrote:
>
> Hi Bin,
>
> On 29/07/21 07:58PM, Bin Meng wrote:
> > The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
> > hwcaps, and only looks to the controller on what can be supported.
> >
> > The flash's hwcaps needs to be AND'ed before checking.
> >
> > Fixes: 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/mtd/spi/spi-nor-core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 99e2f16349..2883d092fc 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -2861,7 +2861,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
> >* Enable all caps by default. We will mask them after checking what's
> >* really supported using spi_mem_supports_op().
> >*/
>
> Please update the comment above. Maybe:
>
> Start by assuming the controller supports every cap. We will mask
> them...
>
> > - *hwcaps = SNOR_HWCAPS_ALL;
> > + *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
>
> This is practically equivalent to *hwcaps = params->hwcaps.mask but I
> think having SNOR_HWCAPS_ALL here to signify that we are assuming
> controller supports everything is not a bad idea IMO.
>
> With the above comment updated,
>
> Reviewed-by: Pratyush Yadav
>
Thanks for the review! Will update comments in v2.
Regards,
Bin
Re: [PATCH 2/2] board: sifive: use ccache driver instead of helper function
On Wed, Jul 28, 2021 at 11:18 PM Sean Anderson wrote:
>
> On 7/28/21 3:25 AM, Zong Li wrote:
> > On Wed, Jul 28, 2021 at 12:29 PM Sean Anderson wrote:
> >>
> >> On 7/27/21 4:54 AM, Zong Li wrote:
> >>> Invokes the generic cache_enable interface to execute the relative
> >>> implementation in SiFive ccache driver.
> >>>
> >>> Signed-off-by: Zong Li
> >>> ---
> >>>arch/riscv/cpu/fu540/Kconfig | 1 +
> >>>arch/riscv/cpu/fu540/cache.c | 62 ---
> >>>arch/riscv/cpu/fu740/Kconfig | 1 +
> >>>arch/riscv/cpu/fu740/cache.c | 60 +++---
> >>>arch/riscv/include/asm/arch-fu540/cache.h | 2 +-
> >>>arch/riscv/include/asm/arch-fu740/cache.h | 2 +-
> >>>board/sifive/unleashed/unleashed.c| 10 +---
> >>>board/sifive/unmatched/unmatched.c| 9 +---
> >>>8 files changed, 45 insertions(+), 102 deletions(-)
> >>>
> >>> diff --git a/arch/riscv/cpu/fu540/Kconfig b/arch/riscv/cpu/fu540/Kconfig
> >>> index 05463b2625..1f50b823ed 100644
> >>> --- a/arch/riscv/cpu/fu540/Kconfig
> >>> +++ b/arch/riscv/cpu/fu540/Kconfig
> >>> @@ -19,6 +19,7 @@ config SIFIVE_FU540
> >>>imply SMP
> >>>imply CLK_SIFIVE
> >>>imply CLK_SIFIVE_PRCI
> >>> + imply SIFIVE_CACHE_CCACHE
> >>>imply SIFIVE_SERIAL
> >>>imply MACB
> >>>imply MII
> >>> diff --git a/arch/riscv/cpu/fu540/cache.c b/arch/riscv/cpu/fu540/cache.c
> >>> index 0fc4ef6c00..3c754c4614 100644
> >>> --- a/arch/riscv/cpu/fu540/cache.c
> >>> +++ b/arch/riscv/cpu/fu540/cache.c
> >>> @@ -1,55 +1,33 @@
> >>>// SPDX-License-Identifier: GPL-2.0+
> >>>/*
> >>> - * Copyright (C) 2020 SiFive, Inc
> >>> + * Copyright (C) 2020 - 2021 SiFive, Inc
> >>> *
> >>> * Authors:
> >>> * Pragnesh Patel
> >>> */
> >>>
> >>>#include
> >>> -#include
> >>> -#include
> >>> -#include
> >>> +#include
> >>> +#include
> >>>
> >>> -/* Register offsets */
> >>> -#define L2_CACHE_CONFIG 0x000
> >>> -#define L2_CACHE_ENABLE 0x008
> >>> -
> >>> -#define MASK_NUM_WAYSGENMASK(15, 8)
> >>> -#define NUM_WAYS_SHIFT 8
> >>> -
> >>> -DECLARE_GLOBAL_DATA_PTR;
> >>> -
> >>> -int cache_enable_ways(void)
> >>> +int sifive_ccache_enable_ways(void)
> >>>{
> >>
> >> Is there any reason this function is duplicated? See below for further
> >> comments.
> >
> > Sorry, I don't completely understand about duplication here. Do you
> > mean why we need this function? or why is it present in both unleashed
> > and unmatched?
>
> Why it is present in both. Shouldn't it be present in some shared file?
>
I considered that before, the places to put this ccache function might
be either 'arch/riscv/lib/' or 'arch/riscv/cpu/generic', these two
folders put some common stuff for all riscv platforms, but this ccache
function is actually used in sifive platform only, I'm not sure if it
is suitable to put the function into them, so I just followed the
original tree. OTOH, the compiler will drop the unused code, so it
might be OK to put it into the folders above, and not influence other
platforms. Do you have any preference or any recommendation?
> >
> >>
> >>> - const void *blob = gd->fdt_blob;
> >>> - int node;
> >>> - fdt_addr_t base;
> >>> - u32 config;
> >>> - u32 ways;
> >>> -
> >>> - volatile u32 *enable;
> >>> -
> >>> - node = fdt_node_offset_by_compatible(blob, -1,
> >>> - "sifive,fu540-c000-ccache");
> >>> -
> >>> - if (node < 0)
> >>> - return node;
> >>> -
> >>> - base = fdtdec_get_addr_size_auto_parent(blob, 0, node, "reg", 0,
> >>> - NULL, false);
> >>> - if (base == FDT_ADDR_T_NONE)
> >>> - return FDT_ADDR_T_NONE;
> >>> -
> >>> - config = readl((volatile u32 *)base + L2_CACHE_CONFIG);
> >>> - ways = (config & MASK_NUM_WAYS) >> NUM_WAYS_SHIFT;
> >>> -
> >>> - enable = (volatile u32 *)(base + L2_CACHE_ENABLE);
> >>> + struct udevice *dev;
> >>> + int ret;
> >>> +
> >>> + ret = uclass_get_device_by_driver(UCLASS_CACHE,
> >>> + DM_DRIVER_GET(sifive_ccache),
> >>> + &dev);
> >>> + if (ret) {
> >>> + pr_debug("%s: could not enable cache ways\n", __func__);
> >>> + return ret;
> >>> + }
> >>> +
> >>> + ret = cache_enable(dev);
> >>> + if (ret) {
> >>> + pr_debug("%s: ccache enable filed\n", __func__);
> >>> + return ret;
> >>> + }
> >>>
> >>> - /* memory barrier */
> >>> - mb();
> >>> - (*enable) = ways - 1;
> >>> - /* memory barrier */
> >>> - mb();
> >>>return 0;
> >>>}
> >>> diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
> >>> index 8e54310b9c..87d8016c88 100644
> >>> --- a/arch/riscv/cpu/fu740/Kconfig
> >>> +++ b/arch/riscv/cpu/f
[PATCH] x86: dts: Add "m25p,fast-read" to SPI flash node
Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should
have "m25p,fast-read" property present in their DT nodes.
Signed-off-by: Bin Meng
---
arch/x86/dts/bayleybay.dts| 1 +
arch/x86/dts/baytrail_som-db5800-som-6867.dts | 1 +
arch/x86/dts/cherryhill.dts | 1 +
arch/x86/dts/chromebook_coral.dts | 1 +
arch/x86/dts/chromebook_link.dts | 1 +
arch/x86/dts/chromebook_samus.dts | 1 +
arch/x86/dts/chromebox_panther.dts| 1 +
arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 +
arch/x86/dts/cougarcanyon2.dts| 1 +
arch/x86/dts/dfi-bt700.dtsi | 1 +
arch/x86/dts/minnowmax.dts| 1 +
11 files changed, 11 insertions(+)
diff --git a/arch/x86/dts/bayleybay.dts b/arch/x86/dts/bayleybay.dts
index 828b851773..b92729dd0b 100644
--- a/arch/x86/dts/bayleybay.dts
+++ b/arch/x86/dts/bayleybay.dts
@@ -176,6 +176,7 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0>;
+ m25p,fast-read;
compatible = "winbond,w25q64dw",
"jedec,spi-nor";
memory-map = <0xff80 0x0080>;
diff --git a/arch/x86/dts/baytrail_som-db5800-som-6867.dts
b/arch/x86/dts/baytrail_som-db5800-som-6867.dts
index f5d1a28c09..e9b56de792 100644
--- a/arch/x86/dts/baytrail_som-db5800-som-6867.dts
+++ b/arch/x86/dts/baytrail_som-db5800-som-6867.dts
@@ -200,6 +200,7 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0>;
+ m25p,fast-read;
compatible = "macronix,mx25l6405d",
"jedec,spi-nor";
memory-map = <0xff80 0x0080>;
diff --git a/arch/x86/dts/cherryhill.dts b/arch/x86/dts/cherryhill.dts
index 99d137e321..7a273670bd 100644
--- a/arch/x86/dts/cherryhill.dts
+++ b/arch/x86/dts/cherryhill.dts
@@ -149,6 +149,7 @@
#address-cells = <1>;
#size-cells = <1>;
reg = <0>;
+ m25p,fast-read;
compatible = "macronix,mx25u6435f",
"jedec,spi-nor";
memory-map = <0xff80 0x0080>;
rw-mrc-cache {
diff --git a/arch/x86/dts/chromebook_coral.dts
b/arch/x86/dts/chromebook_coral.dts
index ea879c0300..f0caaacfee 100644
--- a/arch/x86/dts/chromebook_coral.dts
+++ b/arch/x86/dts/chromebook_coral.dts
@@ -363,6 +363,7 @@
u-boot,dm-pre-proper;
u-boot,dm-spl;
reg = <0>;
+ m25p,fast-read;
compatible = "winbond,w25q128fw",
"jedec,spi-nor";
rw-mrc-cache {
diff --git a/arch/x86/dts/chromebook_link.dts b/arch/x86/dts/chromebook_link.dts
index 4367fab651..11ff520ac2 100644
--- a/arch/x86/dts/chromebook_link.dts
+++ b/arch/x86/dts/chromebook_link.dts
@@ -430,6 +430,7 @@
#address-cells = <1>;
u-boot,dm-pre-reloc;
reg = <0>;
+ m25p,fast-read;
compatible = "winbond,w25q64",
"jedec,spi-nor";
memory-map = <0xff80 0x0080>;
diff --git a/arch/x86/dts/chromebook_samus.dts
b/arch/x86/dts/chromebook_samus.dts
index 0f0dcdcc5f..930ec1ace0 100644
--- a/arch/x86/dts/chromebook_samus.dts
+++ b/arch/x86/dts/chromebook_samus.dts
@@ -594,6 +594,7 @@
#size-cells = <1>;
#address-cells = <1>;
reg = <0>;
+ m25p,fast-read;
compatible = "winbond,w25q64",
"jedec,spi-nor";
memory-map = <0xff80 0x0080>;
diff --git a/arch/x86/dts/chromebox_panther.dts
b/arch/x86/dts/chromebox_panther.dts
index 0169c427a1..b25f759c79 100644
--- a/arch/x86/dts/chromebox_panther.dts
+++ b/arch/x86/dts/chromebox_panther.dts
@@ -48,6 +48,7 @@
#size-cells = <1>;
Re: U-Boot boards needing CONFIG_DM migration
On Thu, Jul 29, 2021 at 12:30:27PM +0200, Stefano Babic wrote: > On 28.07.21 21:21, Tom Rini wrote: > > On Wed, Jul 28, 2021 at 04:09:48PM -0300, Fabio Estevam wrote: > > > Hi Stefano, > > > > > > On Wed, Jul 28, 2021 at 3:58 PM Stefano Babic wrote: > > > > > > > Its status was erroneously set in patchwork - I'll pick it up. > > > > > > Thanks. Peter Robinson's series to convert warp is also missing in > > > master: > > > https://www.mail-archive.com/u-boot@lists.denx.de/msg403736.html > > > > I thought I had seen something about warp too. Any idea what happened > > in the imx tree? > > For Fabio's patch, status was set to "Changes requested" and not assigned to > me, so I have not taken his patch at all. That might have been me asking for the other defconfigs to be removed. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] mtd: spi-nor: Respect flash's hwcaps in spi_nor_adjust_hwcaps()
Hi Bin,
On 29/07/21 07:58PM, Bin Meng wrote:
> The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
> hwcaps, and only looks to the controller on what can be supported.
>
> The flash's hwcaps needs to be AND'ed before checking.
>
> Fixes: 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
> Signed-off-by: Bin Meng
> ---
>
> drivers/mtd/spi/spi-nor-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 99e2f16349..2883d092fc 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2861,7 +2861,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
>* Enable all caps by default. We will mask them after checking what's
>* really supported using spi_mem_supports_op().
>*/
Please update the comment above. Maybe:
Start by assuming the controller supports every cap. We will mask
them...
> - *hwcaps = SNOR_HWCAPS_ALL;
> + *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
This is practically equivalent to *hwcaps = params->hwcaps.mask but I
think having SNOR_HWCAPS_ALL here to signify that we are assuming
controller supports everything is not a bad idea IMO.
With the above comment updated,
Reviewed-by: Pratyush Yadav
Thanks.
>
> /* X-X-X modes are not supported yet, mask them all. */
> *hwcaps &= ~SNOR_HWCAPS_X_X_X;
> --
> 2.25.1
>
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
Re: [PATCH 2/2] x86: crownbay: Disable CONFIG_SPI_FLASH_SMART_HWCAPS
On Thu, Jul 29, 2021 at 9:45 AM Simon Glass wrote:
>
> On Wed, 28 Jul 2021 at 04:29, Bin Meng wrote:
> >
> > Since commit 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
> > SPI flash on Intel Crown Bay board does not work anymore.
> >
> > Disable CONFIG_SPI_FLASH_SMART_HWCAPS until a proper fix is made to
> > the spi-nor core.
> >
> > Signed-off-by: Bin Meng
> > ---
> >
> > configs/crownbay_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
>
> Reviewed-by: Simon Glass
applied to u-boot-x86, thanks!
Re: [PATCH 1/2] spi: ich: Limit slave->max_read_size
On Thu, Jul 29, 2021 at 9:32 AM Simon Glass wrote:
>
> On Wed, 28 Jul 2021 at 04:29, Bin Meng wrote:
> >
> > Since commit 43c145b8b3ee ("spi: ich: Correct max-size bug in
> > ich_spi_adjust_size()")
> > (in v2020.04-rc1), SPI flash read no longer works with ICH SPI controller
> > in software sequencer mode.
> >
> > ICH controller can only transfer a small number of bytes at once.
> > Before commit 43c145b8b3ee, the logic happens to make sure data.nbytes
> > is limited to slave->max_write_size but after commit 43c145b8b3ee
> > data.nbytes is no longer limited because slave->max_read_size is not
> > initialized with a valid number.
> >
> > Fixes: 43c145b8b3ee ("spi: ich: Correct max-size bug in
> > ich_spi_adjust_size()")
> > Signed-off-by: Bin Meng
> > ---
> >
> > drivers/spi/ich.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Reviewed-by: Simon Glass
applied to u-boot-x86, thanks!
[PATCH 6/6] configs: meson64_android: don't set console bootargs
The console bootargs are already set from the kernel commandline.
On Android, this is done in yukawa at [1]
Don't set it in the bootloader since it's overridden by the kernel anyways.
[1] https://android-review.googlesource.com/c/device/amlogic/yukawa/+/1112994
Signed-off-by: Guillaume La Roque
Signed-off-by: Mattijs Korpershoek
---
include/configs/meson64_android.h | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/include/configs/meson64_android.h
b/include/configs/meson64_android.h
index 56545a72f8..3b61d5f703 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -86,7 +86,7 @@
"bootcmd_system=" \
"echo Loading Android " BOOT_PARTITION " partition...;" \
"mmc dev ${mmcdev};" \
- "setenv bootargs ${bootargs} console=${console}
androidboot.serialno=${serial#};" \
+ "setenv bootargs ${bootargs} androidboot.serialno=${serial#};" \
"part start mmc ${mmcdev} " BOOT_PARTITION " boot_start;" \
"part size mmc ${mmcdev} " BOOT_PARTITION " boot_size;" \
"if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
@@ -121,8 +121,6 @@
"gpio_recovery=88\0" \
"check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
"load_logo=" PREBOOT_LOAD_LOGO "\0" \
- "console=/dev/ttyAML0\0" \
- "bootargs=no_console_suspend\0" \
"stdin=" STDIN_CFG "\0" \
"stdout=" STDOUT_CFG "\0" \
"stderr=" STDOUT_CFG "\0" \
--
2.30.2
[PATCH 3/6] configs: meson64_android: use CONFIG_FASTBOOT_USB_DEV
Right now, when running fastboot we use a hard-coded "0" for the
device number.
Use the Kconfig option named CONFIG_FASTBOOT_USB_DEV instead.
Signed-off-by: Guillaume La Roque
Signed-off-by: Mattijs Korpershoek
---
include/configs/meson64_android.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/configs/meson64_android.h
b/include/configs/meson64_android.h
index 661de76fd7..4027a7fe0d 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -38,7 +38,7 @@
"fi;" \
"if test \"${run_fastboot}\" -eq 1; then " \
"echo Running Fastboot...;" \
- "fastboot 0;" \
+ "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
"fi\0"
#define BOOTENV_DEV_NAME_FASTBOOT(devtypeu, devtypel, instance)\
@@ -69,7 +69,7 @@
"fi;" \
"if test \"${run_recovery}\" -eq 1; then " \
"echo Running Recovery...;" \
- "fastboot 0;" \
+ "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
"fi\0"
#define BOOTENV_DEV_NAME_RECOVERY(devtypeu, devtypel, instance)\
--
2.30.2
[PATCH 5/6] configs: meson64_android: use logo part label instead of index
To display the bootup logo, we read the gpt and assume that the
partition with index "2" will be the "logo" partition.
This might not always be the case, and it's very error-prone.
Load the logo partition by label instead of by index.
Signed-off-by: Guillaume La Roque
Signed-off-by: Mattijs Korpershoek
---
include/configs/meson64_android.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/configs/meson64_android.h
b/include/configs/meson64_android.h
index e22f05c889..56545a72f8 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -13,6 +13,10 @@
#define BOOT_PARTITION "boot"
#endif
+#ifndef LOGO_PARTITION
+#define LOGO_PARTITION "logo"
+#endif
+
#define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
"sm reboot_reason reason;" \
@@ -104,8 +108,8 @@
"if test \"${boot_source}\" != \"usb\" && " \
"gpt verify mmc ${mmcdev} ${partitions}; then; " \
"mmc dev ${mmcdev};" \
- "part start mmc ${mmcdev} ${logopart} boot_start;" \
- "part size mmc ${mmcdev} ${logopart} boot_size;" \
+ "part start mmc ${mmcdev} " LOGO_PARTITION " boot_start;" \
+ "part size mmc ${mmcdev} " LOGO_PARTITION " boot_size;" \
"if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
"bmp display ${loadaddr} m m;" \
"fi;" \
@@ -114,7 +118,6 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"partitions=" PARTS_DEFAULT "\0" \
"mmcdev=2\0" \
- "logopart=2\0"\
"gpio_recovery=88\0" \
"check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
"load_logo=" PREBOOT_LOAD_LOGO "\0" \
--
2.30.2
[PATCH 4/6] configs: meson64_android: use boot part label instead of index
To boot Android, we read the gpt and assume that the partition with
index "1" will be the "boot" partition.
This might not always be the case, as there are no requirements from
Android on the partition order.
However, Android does seem to use the "boot" label quite a lot on their
public documentation [1]
Load the boot partition by label instead of by index
[1] https://source.android.com/devices/bootloader/partitions
Signed-off-by: Guillaume La Roque
Signed-off-by: Mattijs Korpershoek
---
include/configs/meson64_android.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/configs/meson64_android.h
b/include/configs/meson64_android.h
index 4027a7fe0d..e22f05c889 100644
--- a/include/configs/meson64_android.h
+++ b/include/configs/meson64_android.h
@@ -9,6 +9,9 @@
#ifndef __MESON64_ANDROID_CONFIG_H
#define __MESON64_ANDROID_CONFIG_H
+#ifndef BOOT_PARTITION
+#define BOOT_PARTITION "boot"
+#endif
#define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
"bootcmd_fastboot=" \
@@ -77,11 +80,11 @@
#define BOOTENV_DEV_SYSTEM(devtypeu, devtypel, instance) \
"bootcmd_system=" \
- "echo Loading Android boot partition...;" \
+ "echo Loading Android " BOOT_PARTITION " partition...;" \
"mmc dev ${mmcdev};" \
"setenv bootargs ${bootargs} console=${console}
androidboot.serialno=${serial#};" \
- "part start mmc ${mmcdev} ${bootpart} boot_start;" \
- "part size mmc ${mmcdev} ${bootpart} boot_size;" \
+ "part start mmc ${mmcdev} " BOOT_PARTITION " boot_start;" \
+ "part size mmc ${mmcdev} " BOOT_PARTITION " boot_size;" \
"if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
"echo Running Android...;" \
"bootm ${loadaddr};" \
@@ -111,7 +114,6 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
"partitions=" PARTS_DEFAULT "\0" \
"mmcdev=2\0" \
- "bootpart=1\0"\
"logopart=2\0"\
"gpio_recovery=88\0" \
"check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
--
2.30.2
[PATCH 2/6] configs: meson64_android: fix bad indent in EXTRA_ENV_SETTINGS
both lines seem to be joined together which is not the case for the meson64.h EXTRA_ENV_SETTINGS. Add a newline for consistency. Signed-off-by: Guillaume La Roque Signed-off-by: Mattijs Korpershoek --- include/configs/meson64_android.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/configs/meson64_android.h b/include/configs/meson64_android.h index c47d51c853..661de76fd7 100644 --- a/include/configs/meson64_android.h +++ b/include/configs/meson64_android.h @@ -127,7 +127,8 @@ "kernel_addr_r=0x0108\0" \ "pxefile_addr_r=0x0108\0" \ "ramdisk_addr_r=0x1300\0" \ - "fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" BOOTENV + "fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"\ + BOOTENV #include -- 2.30.2
[PATCH 1/6] configs: sei610: fix typo in header comment
s/510/610/ Signed-off-by: Guillaume La Roque Signed-off-by: Mattijs Korpershoek --- include/configs/sei610.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/sei610.h b/include/configs/sei610.h index 6d093161c9..9eeffdd72c 100644 --- a/include/configs/sei610.h +++ b/include/configs/sei610.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Configuration for the SEI510 + * Configuration for the SEI610 * * Copyright (C) 2019 Baylibre, SAS * Author: Jerome Brunet -- 2.30.2
[PATCH 0/6] VIM3: misc cleanups to prepare android support
The Khadas VIM3 and VIM3L boards are well supported in the Android Open Source project via the yukawa[1] platform. Their U-Boot version, despite being public [2] is not in mainline. These series a couple of cleanups to prepare to add mainline U-Boot support for vim3 / vim3l so that we can boot Android. [1] https://source.android.com/setup/build/devices#vim3_and_vim3l_boards [2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ Mattijs Korpershoek (6): configs: sei610: fix typo in header comment configs: meson64_android: fix bad indent in EXTRA_ENV_SETTINGS configs: meson64_android: use CONFIG_FASTBOOT_USB_DEV configs: meson64_android: use boot part label instead of index configs: meson64_android: use logo part label instead of index configs: meson64_android: don't set console bootargs include/configs/meson64_android.h | 30 +- include/configs/sei610.h | 2 +- 2 files changed, 18 insertions(+), 14 deletions(-) -- 2.30.2
[PATCH 1/2] mtd: spi-nor: Respect flash's hwcaps in spi_nor_adjust_hwcaps()
The smart spi_nor_adjust_hwcaps() does not respect the SPI flash's
hwcaps, and only looks to the controller on what can be supported.
The flash's hwcaps needs to be AND'ed before checking.
Fixes: 71025f013ccb ("mtd: spi-nor-core: Rework hwcaps selection")
Signed-off-by: Bin Meng
---
drivers/mtd/spi/spi-nor-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 99e2f16349..2883d092fc 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2861,7 +2861,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
* Enable all caps by default. We will mask them after checking what's
* really supported using spi_mem_supports_op().
*/
- *hwcaps = SNOR_HWCAPS_ALL;
+ *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
/* X-X-X modes are not supported yet, mask them all. */
*hwcaps &= ~SNOR_HWCAPS_X_X_X;
--
2.25.1
[PATCH 2/2] mtd: spi-nor: Mask out fast read if not requested in DT
The DT bindings of "jedec,spi-nor" [1] defines "m25p,fast-read" property
to indicate that "fast read" opcode can be used to read data from the
chip instead of the usual "read" opcode.
If this property is not present in DT, mask out fast read in
spi_nor_init_params(). This change mirrors the same logic in
spi_nor_info_init_params() in drivers/mtd/spi-nor/core.c in
the Linux kernel v5.14-rc3.
[1] Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml in the kernel tree
Signed-off-by: Bin Meng
---
drivers/mtd/spi/spi-nor-core.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 2883d092fc..d6a0ed39c5 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -2597,6 +2597,8 @@ static int spi_nor_init_params(struct spi_nor *nor,
const struct flash_info *info,
struct spi_nor_flash_parameter *params)
{
+ struct spi_slave *spi = nor->spi;
+
/* Set legacy flash parameters as default. */
memset(params, 0, sizeof(*params));
@@ -2604,18 +2606,25 @@ static int spi_nor_init_params(struct spi_nor *nor,
params->size = info->sector_size * info->n_sectors;
params->page_size = info->page_size;
+ if (!(info->flags & SPI_NOR_NO_FR)) {
+ /* Default to Fast Read for DT and non-DT platform devices. */
+ params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+
+ /* Mask out Fast Read if not requested at DT instantiation. */
+ if (!ofnode_read_bool(dev_ofnode(spi->dev), "m25p,fast-read"))
+ params->hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
+ }
+
/* (Fast) Read settings. */
params->hwcaps.mask |= SNOR_HWCAPS_READ;
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ],
0, 0, SPINOR_OP_READ,
SNOR_PROTO_1_1_1);
- if (!(info->flags & SPI_NOR_NO_FR)) {
- params->hwcaps.mask |= SNOR_HWCAPS_READ_FAST;
+ if (params->hwcaps.mask & SNOR_HWCAPS_READ_FAST)
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_FAST],
0, 8, SPINOR_OP_READ_FAST,
SNOR_PROTO_1_1_1);
- }
if (info->flags & SPI_NOR_DUAL_READ) {
params->hwcaps.mask |= SNOR_HWCAPS_READ_1_1_2;
--
2.25.1
[PATCH 4/4] xilinx: zynqmp: Enable CMD_RTC command with Zynqmp RTC driver
Enable RTC command to be able to check available. And also enable ZynqMP RTC driver to be possible to use by default. Here is the list when both drivers are enabled: ZynqMP> rtc list RTC #0 - rtc_emul RTC #1 - rtc@ffa6 Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_virt_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index a1a3526f3c5f..9a45ccb5287c 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -62,6 +62,7 @@ CONFIG_CMD_TFTPPUT=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y +CONFIG_CMD_RTC=y CONFIG_CMD_TIME=y CONFIG_CMD_GETTIME=y CONFIG_CMD_TIMER=y @@ -153,6 +154,7 @@ CONFIG_DM_REGULATOR=y CONFIG_DM_REGULATOR_FIXED=y CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y +CONFIG_RTC_ZYNQMP=y CONFIG_SCSI=y CONFIG_DM_SCSI=y CONFIG_ARM_DCC=y -- 2.32.0
[PATCH 3/4] rtc: zynqmp: Add support for ZynqMP RTC
The whole driver logic is taken from Linux kernel but only set/get/reset
functions are implemented. When device is power off RTC is power out of
battery.
Signed-off-by: Michal Simek
---
MAINTAINERS | 1 +
drivers/rtc/Kconfig | 7 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/zynqmp_rtc.c | 158 +++
4 files changed, 167 insertions(+)
create mode 100644 drivers/rtc/zynqmp_rtc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a18b3b6d939..5734ebb80363 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -600,6 +600,7 @@ F: drivers/mtd/nand/raw/zynq_nand.c
F: drivers/net/phy/xilinx_phy.c
F: drivers/net/zynq_gem.c
F: drivers/serial/serial_zynq.c
+F: drivers/rtc/zynqmp_rtc.c
F: drivers/spi/zynq_qspi.c
F: drivers/spi/zynq_spi.c
F: drivers/timer/cadence-ttc.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index cbdfddb80f66..b6692e62df1c 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -195,4 +195,11 @@ config RTC_DAVINCI
Say "yes" here to support the on chip real time clock
present on TI OMAP1, AM33xx, DA8xx/OMAP-L13x, AM43xx and DRA7xx.
+config RTC_ZYNQMP
+ bool "Enable ZynqMP RTC driver"
+ depends on ARCH_ZYNQMP
+ help
+ Say "yes" here to support the on chip real time clock
+ present on Xilinx ZynqMP SoC.
+
endmenu
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 331a49ab599a..d621be622848 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -57,3 +57,4 @@ obj-$(CONFIG_RTC_STM32) += stm32_rtc.o
obj-$(CONFIG_SANDBOX) += sandbox_rtc.o
obj-$(CONFIG_RTC_X1205) += x1205.o
obj-$(CONFIG_RTC_ABX80X) += abx80x.o
+obj-$(CONFIG_RTC_ZYNQMP) += zynqmp_rtc.o
diff --git a/drivers/rtc/zynqmp_rtc.c b/drivers/rtc/zynqmp_rtc.c
new file mode 100644
index ..ab9b93ca9793
--- /dev/null
+++ b/drivers/rtc/zynqmp_rtc.c
@@ -0,0 +1,158 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021, Xilinx, Inc.
+ */
+
+#define LOG_CATEGORY UCLASS_RTC
+
+#include
+#include
+#include
+#include
+
+/* RTC Registers */
+#define RTC_SET_TM_WR 0x00
+#define RTC_SET_TM_RD 0x04
+#define RTC_CALIB_WR 0x08
+#define RTC_CUR_TM 0x10
+#define RTC_INT_STS0x20
+#define RTC_CTRL 0x40
+
+#define RTC_INT_SECBIT(0)
+#define RTC_BATT_ENBIT(31)
+#define RTC_CALIB_DEF 0x198233
+#define RTC_CALIB_MASK 0x1F
+
+struct zynqmp_rtc_priv {
+ fdt_addr_t base;
+ unsigned intcalibval;
+};
+
+static int zynqmp_rtc_get(struct udevice *dev, struct rtc_time *tm)
+{
+ struct zynqmp_rtc_priv *priv = dev_get_priv(dev);
+ u32 status;
+ unsigned long read_time;
+
+ status = readl(priv->base + RTC_INT_STS);
+
+ if (status & RTC_INT_SEC) {
+ /*
+* RTC has updated the CURRENT_TIME with the time written into
+* SET_TIME_WRITE register.
+*/
+ read_time = readl(priv->base + RTC_CUR_TM);
+ } else {
+ /*
+* Time written in SET_TIME_WRITE has not yet updated into
+* the seconds read register, so read the time from the
+* SET_TIME_WRITE instead of CURRENT_TIME register.
+* Since we add +1 sec while writing, we need to -1 sec while
+* reading.
+*/
+ read_time = readl(priv->base + RTC_SET_TM_RD) - 1;
+ }
+
+ rtc_to_tm(read_time, tm);
+
+ return 0;
+}
+
+static int zynqmp_rtc_set(struct udevice *dev, const struct rtc_time *tm)
+{
+ struct zynqmp_rtc_priv *priv = dev_get_priv(dev);
+ unsigned long new_time = 0;
+
+ if (tm)
+ /*
+* The value written will be updated after 1 sec into the
+* seconds read register, so we need to program time +1 sec
+* to get the correct time on read.
+*/
+ new_time = rtc_mktime(tm) + 1;
+
+ /*
+* Writing into calibration register will clear the Tick Counter and
+* force the next second to be signaled exactly in 1 second period
+*/
+ priv->calibval &= RTC_CALIB_MASK;
+ writel(priv->calibval, (priv->base + RTC_CALIB_WR));
+
+ writel(new_time, priv->base + RTC_SET_TM_WR);
+
+ /*
+* Clear the rtc interrupt status register after setting the
+* time. During a read_time function, the code should read the
+* RTC_INT_STATUS register and if bit 0 is still 0, it means
+* that one second has not elapsed yet since RTC was set and
+* the current time should be read from SET_TIME_READ register;
+* otherwise, CURRENT_TIME register is read to report the time
+*/
+ writel(RTC_INT_SEC, priv->base + RTC_INT_STS);
+
+ return 0;
+}
+
+static int zynqmp_rtc_reset(str
[PATCH 1/4] dm: rtc: uclass: Add flag to control sequence numbering
RTCs are using aliases for sequences. That's why enable
DM_UC_FLAG_SEQ_ALIAS for exact RTC indentification.
The same flag is used by a lot of other uclasses like mmc, pci, serial,
spi, timer, tpm, etc.
Signed-off-by: Michal Simek
---
drivers/rtc/rtc-uclass.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-uclass.c b/drivers/rtc/rtc-uclass.c
index be6a2ddb6671..321b8732ed9a 100644
--- a/drivers/rtc/rtc-uclass.c
+++ b/drivers/rtc/rtc-uclass.c
@@ -176,6 +176,7 @@ int rtc_write32(struct udevice *dev, unsigned int reg, u32
value)
UCLASS_DRIVER(rtc) = {
.name = "rtc",
.id = UCLASS_RTC,
+ .flags = DM_UC_FLAG_SEQ_ALIAS,
#if !CONFIG_IS_ENABLED(OF_PLATDATA)
.post_bind = dm_scan_fdt_dev,
#endif
--
2.32.0
[PATCH 0/4] xilinx: Add RTC support for Xilinx ZynqMP
Hi, this series is correcting RTC uclass behavior to match RTC aliases to enable RTC_EMULATION driver with ZYNQMP driver. If DT node is present ZynqMP RTC is used. If not RTC emaulation is used. The driver has been tested on Xilinx zcu104 also with booting to Linux to make sure that U-Boot format match with Linux format. Thanks, Michal Michal Simek (4): dm: rtc: uclass: Add flag to control sequence numbering cmd: date: rtc: Update command to read the first RTC with seq 0 rtc: zynqmp: Add support for ZynqMP RTC xilinx: zynqmp: Enable CMD_RTC command with Zynqmp RTC driver MAINTAINERS | 1 + cmd/date.c | 9 +- configs/xilinx_zynqmp_virt_defconfig | 2 + drivers/rtc/Kconfig | 7 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-uclass.c | 1 + drivers/rtc/zynqmp_rtc.c | 158 +++ 7 files changed, 176 insertions(+), 3 deletions(-) create mode 100644 drivers/rtc/zynqmp_rtc.c -- 2.32.0
[PATCH 2/4] cmd: date: rtc: Update command to read the first RTC with seq 0
RTCs are using sequence number defined in aliases node. Date command with
DM_RTC enabled is looking for the first RTC with index 0. But when
RTC_EMULATION is enabled it gets likely most of the time index 0 even when
system has rtc0 device via aliases node and gets sequence number 0.
That's why extend the code to look for sequence 0 number first. If this
fails continue to use existing device with index 0.
Signed-off-by: Michal Simek
---
cmd/date.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/cmd/date.c b/cmd/date.c
index 0e1189475313..5d5c20a59af9 100644
--- a/cmd/date.c
+++ b/cmd/date.c
@@ -41,10 +41,13 @@ static int do_date(struct cmd_tbl *cmdtp, int flag, int
argc,
#ifdef CONFIG_DM_RTC
struct udevice *dev;
- rcode = uclass_get_device(UCLASS_RTC, 0, &dev);
+ rcode = uclass_get_device_by_seq(UCLASS_RTC, 0, &dev);
if (rcode) {
- printf("Cannot find RTC: err=%d\n", rcode);
- return CMD_RET_FAILURE;
+ rcode = uclass_get_device(UCLASS_RTC, 0, &dev);
+ if (rcode) {
+ printf("Cannot find RTC: err=%d\n", rcode);
+ return CMD_RET_FAILURE;
+ }
}
#elif defined(CONFIG_SYS_I2C)
old_bus = i2c_get_bus_num();
--
2.32.0
Re: [PATCH 1/1] lib/ecdsa: Fix LibreSSL before v2.7.0
On 29.07.2021 02:43, Tom Rini wrote: > > Yes, true. And that's two 1-line if/else. That's a reasonable to me > level of effort to keep supporting older hosts. Your patch is adding in > 60 lines. I really do want to dig a bit more here. For me, it doesn't matter how many lines of code were added if I can't build host tools with older OpenSSL versions. So what's the point of keeping OpenSSL backward compatibility? > And honestly, part of my concerns also go around "who is going to > maintain / test this area?". We don't have these older versions in CI > (or we would have seen the problem before merging). Are you > volunteering to support the relevant code areas here but on older > openssl/libressl ? We already have a nightly Jenkins CI job that tracks u-boot master and sends internal reports. The best way would be to testing in the upstream azure pipeline. You could add the following steps in your trini/u-boot-gitlab-ci-runner docker image: wget -O - https://www.openssl.org/source/old/1.0.2/openssl-1.0.2k.tar.gz | tar -C /opt -xz && \ cd /opt/openssl-1.0.2k/ && ./config shared && \ make && \ make install In azure pipeline add new job for testing with old OpenSSL: make tools-only_config tools-only NO_SDL=1 \ HOSTLDFLAGS="-ldl -L/usr/local/ssl/lib" \ HOSTCFLAGS="-I/usr/local/ssl/include" --- Artem
Re: U-Boot boards needing CONFIG_DM migration
On 28.07.21 21:21, Tom Rini wrote: On Wed, Jul 28, 2021 at 04:09:48PM -0300, Fabio Estevam wrote: Hi Stefano, On Wed, Jul 28, 2021 at 3:58 PM Stefano Babic wrote: Its status was erroneously set in patchwork - I'll pick it up. Thanks. Peter Robinson's series to convert warp is also missing in master: https://www.mail-archive.com/u-boot@lists.denx.de/msg403736.html I thought I had seen something about warp too. Any idea what happened in the imx tree? For Fabio's patch, status was set to "Changes requested" and not assigned to me, so I have not taken his patch at all. But with Peter's set is weird : I see they are in "Awaiting upstream", so that seems they were merged by me in u-boot-imx, so I do not really know. I check them again if I can apply on TOT. Stefano -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 4/4] xilinx: zynqmp: Add support for runtime dfu_alt_info setup
The main reason for this to be implemented is capsule update.
Two memories are supported and tested which is MMC FAT based and QSPI
based.
For creating capsule these commands are used:
./tools/mkeficapsule --raw spl/boot.bin --index 1 capsule1.bin
./tools/mkeficapsule --raw u-boot.itb --index 2 capsule2.bin
Then transfer to SD card where these commands run:
load mmc 0 1000 capsule1.bin
efidebug capsule update -v 1000
load mmc 0 1000 capsule2.bin
efidebug capsule update -v 1000
Depends on the boot device used are binaries loaded to qspi or mmc fat
partition.
Also multiboot register is handled to make sure that the same location(id)
is used as image which is upgraded.
Two locations are used by purpose for SPL flow. If only boot.bin is used
create only one capsule.
Signed-off-by: Michal Simek
---
Changes in v2:
- no need to free local buf variable
board/xilinx/zynqmp/zynqmp.c | 54
configs/xilinx_zynqmp_virt_defconfig | 1 +
2 files changed, 55 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 1b0356c84c5c..27bb2b056c58 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -19,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -818,3 +820,55 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_NOWHERE;
}
}
+
+#if defined(CONFIG_SET_DFU_ALT_INFO)
+
+#define DFU_ALT_BUF_LENSZ_1K
+
+void set_dfu_alt_info(char *interface, char *devstr)
+{
+ u8 multiboot;
+ int bootseq = 0;
+
+ ALLOC_CACHE_ALIGN_BUFFER(char, buf, DFU_ALT_BUF_LEN);
+
+ if (env_get("dfu_alt_info"))
+ return;
+
+ memset(buf, 0, sizeof(buf));
+
+ multiboot = multi_boot();
+ debug("Multiboot: %d\n", multiboot);
+
+ switch (zynqmp_get_bootmode()) {
+ case EMMC_MODE:
+ case SD_MODE:
+ case SD1_LSHFT_MODE:
+ case SD_MODE1:
+ bootseq = mmc_get_env_dev();
+ if (!multiboot)
+ snprintf(buf, DFU_ALT_BUF_LEN,
+"mmc %d:1=boot.bin fat %d 1;"
+"u-boot.itb fat %d 1",
+bootseq, bootseq, bootseq);
+ else
+ snprintf(buf, DFU_ALT_BUF_LEN,
+"mmc %d:1=boot%04d.bin fat %d 1;"
+"u-boot.itb fat %d 1",
+bootseq, multiboot, bootseq, bootseq);
+ break;
+ case QSPI_MODE_24BIT:
+ case QSPI_MODE_32BIT:
+ snprintf(buf, DFU_ALT_BUF_LEN,
+"sf 0:0=boot.bin raw %x 0x150;"
+"u-boot.itb raw 0x%x 0x50",
+multiboot * SZ_32K, CONFIG_SYS_SPI_U_BOOT_OFFS);
+ break;
+ default:
+ return;
+ }
+
+ env_set("dfu_alt_info", buf);
+ puts("DFU alt info setting: done\n");
+}
+#endif
diff --git a/configs/xilinx_zynqmp_virt_defconfig
b/configs/xilinx_zynqmp_virt_defconfig
index 095260403d95..2b80292fb687 100644
--- a/configs/xilinx_zynqmp_virt_defconfig
+++ b/configs/xilinx_zynqmp_virt_defconfig
@@ -94,6 +94,7 @@ CONFIG_DFU_NAND=y
CONFIG_DFU_RAM=y
CONFIG_DFU_SF=y
CONFIG_DFU_MTD=y
+CONFIG_SET_DFU_ALT_INFO=y
CONFIG_SYS_DFU_DATA_BUF_SIZE=0x180
CONFIG_USB_FUNCTION_FASTBOOT=y
CONFIG_FASTBOOT_FLASH=y
--
2.32.0
[PATCH v2 1/4] xilinx: zynqmp: Change multi_boot() to return value
Change multi_boot() to return multiboot value and move print out of this
function and let this function to be used by other functions without
duplicating message.
Signed-off-by: Michal Simek
---
Changes in v2: None
board/xilinx/zynqmp/zynqmp.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 2cb97f42bec3..eb67116d5b44 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -350,9 +350,7 @@ static int multi_boot(void)
multiboot = readl(&csu_base->multi_boot);
- printf("Multiboot:\t%d\n", multiboot);
-
- return 0;
+ return multiboot;
}
#define PS_SYSMON_ANALOG_BUS_VAL 0x3210
@@ -392,7 +390,7 @@ int board_init(void)
#endif
if (current_el() == 3)
- multi_boot();
+ printf("Multiboot:\t%d\n", multi_boot());
return 0;
}
--
2.32.0
[PATCH v2 3/4] xilinx: zynqmp: Config non zero SYS_SPI_U_BOOT_OFFS
This variable is pointing to offset is qspi where u-boot image is placed. In our case it is location of u-boot.itb file. Offset is the same as is used by Xilinx Zynq SoC. Signed-off-by: Michal Simek --- Changes in v2: None configs/xilinx_zynqmp_virt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index bac1e181d265..095260403d95 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -5,6 +5,7 @@ CONFIG_SYS_TEXT_BASE=0x800 CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SYS_MEMTEST_START=0x CONFIG_SYS_MEMTEST_END=0x1000 +CONFIG_SYS_SPI_U_BOOT_OFFS=0x10 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="zynqmp-zcu100-revC" CONFIG_SPL=y -- 2.32.0
[PATCH v2 2/4] xilinx: zynqmp: use zynqmp_mmio_read() in multi_boot()
When U-Boot runs in EL2 there is no access to csu_base registers that's why
this has to be done via firmware interface to find out multi boot register
value. Till now this function is called only from SPL in EL3.
Signed-off-by: Michal Simek
---
Changes in v2: None
board/xilinx/zynqmp/zynqmp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index eb67116d5b44..1b0356c84c5c 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -346,9 +346,12 @@ int board_early_init_f(void)
static int multi_boot(void)
{
- u32 multiboot;
+ u32 multiboot = 0;
+ int ret;
- multiboot = readl(&csu_base->multi_boot);
+ ret = zynqmp_mmio_read((ulong)&csu_base->multi_boot, &multiboot);
+ if (ret)
+ return -EINVAL;
return multiboot;
}
--
2.32.0
[PATCH v2 0/4] xilinx: zynqmp: Add support for dfu_alt_info setup at runtime
Hi, this series is just for composing dfu_alt_info string for capsule update to work automatically based on current setup. QSPI/MMC FAT bootmodes are handled and supported. Other bootmodes are ignored for now. Thanks, Michal Changes in v2: - no need to free local buf variable Michal Simek (4): xilinx: zynqmp: Change multi_boot() to return value xilinx: zynqmp: use zynqmp_mmio_read() in multi_boot() xilinx: zynqmp: Config non zero SYS_SPI_U_BOOT_OFFS xilinx: zynqmp: Add support for runtime dfu_alt_info setup board/xilinx/zynqmp/zynqmp.c | 67 +--- configs/xilinx_zynqmp_virt_defconfig | 2 + 2 files changed, 63 insertions(+), 6 deletions(-) -- 2.32.0
Re: qemu-kvm doesn't work with qemu-x86_64_defconfig
чт, 29 июл. 2021 г. в 08:22, Bin Meng : > > +Simon > > On Wed, Jul 28, 2021 at 11:22 PM Matwey V. Kornilov > wrote: > > > > Hello, > > > > I am trying to build master for qemu-x86_64_defconfig. When I try to > > boot u-boot.rom as the following everything works fine: > > > > > qemu-system-x86_64 -nographic -bios u-boot.rom > > > > U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) > > Trying to boot from SPI > > Jumping to 64-bit U-Boot: Note many features are missing > > > > > > U-Boot 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) > > > > CPU: QEMU Virtual CPU version 2.5+ > > DRAM: 128 MiB > > Loading Environment from nowhere... OK > > Incorrect expansion ROM header signature 4daa > > Model: QEMU x86 (I440FX) > > Net: e1000: 52:54:00:12:34:56 > >eth0: e1000#0 > > Hit any key to stop autoboot: 0 > > > > > > When I try to enable KVM as the following, the boot process hangs: > > > > > qemu-system-x86_64 -enable-kvm -cpu host -nographic -bios u-boot.rom > > > > U-Boot SPL 2021.10-rc1-00027-g22ecb12132 (Jul 28 2021 - 18:18:37 +0300) > > Trying to boot from SPI > > Jumping to 64-bit U-Boot: Note many features are missing > > > > > > What have I missed? Maybe KVM is just not supported? > > > > Yep, at least I did not test u-boot with KVM. Thanks for confirmation. In any case, u-boot works very quickly even without KVM. > > Regards, > Bin -- With best regards, Matwey V. Kornilov
Re: [PATCH 0/6] VIM3: misc cleanups to prepare android support
On 29/07/2021 09:21, Mattijs Korpershoek wrote: > The Khadas VIM3 and VIM3L boards are well supported in the > Android Open Source project via the yukawa[1] platform. > > Their U-Boot version, despite being public [2] is not in mainline. > > These series a couple of cleanups to prepare to add mainline U-Boot support > for vim3 / vim3l so that we can boot Android. > > [1] https://source.android.com/setup/build/devices#vim3_and_vim3l_boards > [2] > https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ > > Mattijs Korpershoek (6): > configs: sei610: fix typo in header comment > configs: meson64_android: fix bad indent in EXTRA_ENV_SETTINGS > configs: meson64_android: use CONFIG_FASTBOOT_USB_DEV > configs: meson64_android: use boot part label instead of index > configs: meson64_android: use logo part label instead of index > configs: meson64_android: don't set console bootargs > > include/configs/meson64_android.h | 30 +- > include/configs/sei610.h | 2 +- > 2 files changed, 18 insertions(+), 14 deletions(-) > Applied to u-boot-amlogic Thanks, Neil
Re: [PATCH 6/6] configs: meson64_android: don't set console bootargs
On 29/07/2021 09:21, Mattijs Korpershoek wrote:
> The console bootargs are already set from the kernel commandline.
> On Android, this is done in yukawa at [1]
>
> Don't set it in the bootloader since it's overridden by the kernel anyways.
>
> [1] https://android-review.googlesource.com/c/device/amlogic/yukawa/+/1112994
> Signed-off-by: Guillaume La Roque
> Signed-off-by: Mattijs Korpershoek
> ---
> include/configs/meson64_android.h | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/include/configs/meson64_android.h
> b/include/configs/meson64_android.h
> index 56545a72f8..3b61d5f703 100644
> --- a/include/configs/meson64_android.h
> +++ b/include/configs/meson64_android.h
> @@ -86,7 +86,7 @@
> "bootcmd_system=" \
> "echo Loading Android " BOOT_PARTITION " partition...;" \
> "mmc dev ${mmcdev};" \
> - "setenv bootargs ${bootargs} console=${console}
> androidboot.serialno=${serial#};" \
> + "setenv bootargs ${bootargs} androidboot.serialno=${serial#};" \
> "part start mmc ${mmcdev} " BOOT_PARTITION " boot_start;" \
> "part size mmc ${mmcdev} " BOOT_PARTITION " boot_size;" \
> "if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
> @@ -121,8 +121,6 @@
> "gpio_recovery=88\0" \
> "check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
> "load_logo=" PREBOOT_LOAD_LOGO "\0" \
> - "console=/dev/ttyAML0\0" \
> - "bootargs=no_console_suspend\0" \
> "stdin=" STDIN_CFG "\0" \
> "stdout=" STDOUT_CFG "\0" \
> "stderr=" STDOUT_CFG "\0" \
>
Acked-by: Neil Armstrong
Re: [PATCH 5/6] configs: meson64_android: use logo part label instead of index
On 29/07/2021 09:21, Mattijs Korpershoek wrote:
> To display the bootup logo, we read the gpt and assume that the
> partition with index "2" will be the "logo" partition.
>
> This might not always be the case, and it's very error-prone.
>
> Load the logo partition by label instead of by index.
>
> Signed-off-by: Guillaume La Roque
> Signed-off-by: Mattijs Korpershoek
> ---
> include/configs/meson64_android.h | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/meson64_android.h
> b/include/configs/meson64_android.h
> index e22f05c889..56545a72f8 100644
> --- a/include/configs/meson64_android.h
> +++ b/include/configs/meson64_android.h
> @@ -13,6 +13,10 @@
> #define BOOT_PARTITION "boot"
> #endif
>
> +#ifndef LOGO_PARTITION
> +#define LOGO_PARTITION "logo"
> +#endif
> +
> #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
> "bootcmd_fastboot=" \
> "sm reboot_reason reason;" \
> @@ -104,8 +108,8 @@
> "if test \"${boot_source}\" != \"usb\" && " \
> "gpt verify mmc ${mmcdev} ${partitions}; then; " \
> "mmc dev ${mmcdev};" \
> - "part start mmc ${mmcdev} ${logopart} boot_start;" \
> - "part size mmc ${mmcdev} ${logopart} boot_size;" \
> + "part start mmc ${mmcdev} " LOGO_PARTITION " boot_start;" \
> + "part size mmc ${mmcdev} " LOGO_PARTITION " boot_size;" \
> "if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
> "bmp display ${loadaddr} m m;" \
> "fi;" \
> @@ -114,7 +118,6 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "partitions=" PARTS_DEFAULT "\0" \
> "mmcdev=2\0" \
> - "logopart=2\0"\
> "gpio_recovery=88\0" \
> "check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
> "load_logo=" PREBOOT_LOAD_LOGO "\0" \
>
Acked-by: Neil Armstrong
Re: [PATCH 4/6] configs: meson64_android: use boot part label instead of index
On 29/07/2021 09:21, Mattijs Korpershoek wrote:
> To boot Android, we read the gpt and assume that the partition with
> index "1" will be the "boot" partition.
>
> This might not always be the case, as there are no requirements from
> Android on the partition order.
>
> However, Android does seem to use the "boot" label quite a lot on their
> public documentation [1]
>
> Load the boot partition by label instead of by index
>
> [1] https://source.android.com/devices/bootloader/partitions
> Signed-off-by: Guillaume La Roque
> Signed-off-by: Mattijs Korpershoek
> ---
> include/configs/meson64_android.h | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/include/configs/meson64_android.h
> b/include/configs/meson64_android.h
> index 4027a7fe0d..e22f05c889 100644
> --- a/include/configs/meson64_android.h
> +++ b/include/configs/meson64_android.h
> @@ -9,6 +9,9 @@
> #ifndef __MESON64_ANDROID_CONFIG_H
> #define __MESON64_ANDROID_CONFIG_H
>
> +#ifndef BOOT_PARTITION
> +#define BOOT_PARTITION "boot"
> +#endif
>
> #define BOOTENV_DEV_FASTBOOT(devtypeu, devtypel, instance) \
> "bootcmd_fastboot=" \
> @@ -77,11 +80,11 @@
>
> #define BOOTENV_DEV_SYSTEM(devtypeu, devtypel, instance) \
> "bootcmd_system=" \
> - "echo Loading Android boot partition...;" \
> + "echo Loading Android " BOOT_PARTITION " partition...;" \
> "mmc dev ${mmcdev};" \
> "setenv bootargs ${bootargs} console=${console}
> androidboot.serialno=${serial#};" \
> - "part start mmc ${mmcdev} ${bootpart} boot_start;" \
> - "part size mmc ${mmcdev} ${bootpart} boot_size;" \
> + "part start mmc ${mmcdev} " BOOT_PARTITION " boot_start;" \
> + "part size mmc ${mmcdev} " BOOT_PARTITION " boot_size;" \
> "if mmc read ${loadaddr} ${boot_start} ${boot_size}; then " \
> "echo Running Android...;" \
> "bootm ${loadaddr};" \
> @@ -111,7 +114,6 @@
> #define CONFIG_EXTRA_ENV_SETTINGS \
> "partitions=" PARTS_DEFAULT "\0" \
> "mmcdev=2\0" \
> - "bootpart=1\0"\
> "logopart=2\0"\
> "gpio_recovery=88\0" \
> "check_button=gpio input ${gpio_recovery};test $? -eq 0;\0" \
>
Acked-by: Neil Armstrong
Re: [PATCH 3/6] configs: meson64_android: use CONFIG_FASTBOOT_USB_DEV
On 29/07/2021 09:21, Mattijs Korpershoek wrote:
> Right now, when running fastboot we use a hard-coded "0" for the
> device number.
>
> Use the Kconfig option named CONFIG_FASTBOOT_USB_DEV instead.
>
> Signed-off-by: Guillaume La Roque
> Signed-off-by: Mattijs Korpershoek
> ---
> include/configs/meson64_android.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/meson64_android.h
> b/include/configs/meson64_android.h
> index 661de76fd7..4027a7fe0d 100644
> --- a/include/configs/meson64_android.h
> +++ b/include/configs/meson64_android.h
> @@ -38,7 +38,7 @@
> "fi;" \
> "if test \"${run_fastboot}\" -eq 1; then " \
> "echo Running Fastboot...;" \
> - "fastboot 0;" \
> + "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
> "fi\0"
>
> #define BOOTENV_DEV_NAME_FASTBOOT(devtypeu, devtypel, instance) \
> @@ -69,7 +69,7 @@
> "fi;" \
> "if test \"${run_recovery}\" -eq 1; then " \
> "echo Running Recovery...;" \
> - "fastboot 0;" \
> + "fastboot " __stringify(CONFIG_FASTBOOT_USB_DEV) "; " \
> "fi\0"
>
> #define BOOTENV_DEV_NAME_RECOVERY(devtypeu, devtypel, instance) \
>
Acked-by: Neil Armstrong
Re: [PATCH 2/6] configs: meson64_android: fix bad indent in EXTRA_ENV_SETTINGS
On 29/07/2021 09:21, Mattijs Korpershoek wrote: > both lines seem to be joined together which is not the case for the > meson64.h EXTRA_ENV_SETTINGS. > > Add a newline for consistency. > > Signed-off-by: Guillaume La Roque > Signed-off-by: Mattijs Korpershoek > --- > include/configs/meson64_android.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/include/configs/meson64_android.h > b/include/configs/meson64_android.h > index c47d51c853..661de76fd7 100644 > --- a/include/configs/meson64_android.h > +++ b/include/configs/meson64_android.h > @@ -127,7 +127,8 @@ > "kernel_addr_r=0x0108\0" \ > "pxefile_addr_r=0x0108\0" \ > "ramdisk_addr_r=0x1300\0" \ > - "fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" BOOTENV > + "fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"\ > + BOOTENV > > #include > > Acked-by: Neil Armstrong
Re: [PATCH 1/6] configs: sei610: fix typo in header comment
On 29/07/2021 09:21, Mattijs Korpershoek wrote: > s/510/610/ > > Signed-off-by: Guillaume La Roque > Signed-off-by: Mattijs Korpershoek > --- > include/configs/sei610.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/configs/sei610.h b/include/configs/sei610.h > index 6d093161c9..9eeffdd72c 100644 > --- a/include/configs/sei610.h > +++ b/include/configs/sei610.h > @@ -1,6 +1,6 @@ > /* SPDX-License-Identifier: GPL-2.0+ */ > /* > - * Configuration for the SEI510 > + * Configuration for the SEI610 > * > * Copyright (C) 2019 Baylibre, SAS > * Author: Jerome Brunet > Acked-by: Neil Armstrong
Re: [RFC PATCH] mtd: spi-nor-core: Handle SPI_RX_SLOW in spi_nor_adjust_hwcaps()
On Thu, Jul 29, 2021 at 1:42 AM Pratyush Yadav wrote:
>
> On 28/07/21 11:56PM, Bin Meng wrote:
> > When CONFIG_SPI_FLASH_SMART_HWCAPS is on, SPI_RX_SLOW flag of the
> > SPI controller is not honored. This adds the missing logic there.
> >
> > With this patch, SPI flash read works again with ICH SPI controller
> > on Intel Crown Bay board.
> >
> > Signed-off-by: Bin Meng
> >
> > ---
> > The quirky stuff of ICH SPI controller is that it only supports normal
> > read (opcode 3) but not fast read (opcode 11), so that's why SPI_RX_SLOW
> > was introduced before.
> >
> > At present the ICH SPI driver does not implement the supports_op() hook.
> > I can add a check against opcode 11 there, however I see a comment in
> > spi_nor_check_op() saying that SPI controller implementation should not
> > check the opcode.
> >
> > /*
> > * First test with 4 address bytes. The opcode itself might be a 3B
> > * addressing opcode but we don't care, because SPI controller
> > * implementation should not check the opcode, but just the sequence.
> > */
> >
> > drivers/mtd/spi/spi-nor-core.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> > index 99e2f16349..e9b46c39b5 100644
> > --- a/drivers/mtd/spi/spi-nor-core.c
> > +++ b/drivers/mtd/spi/spi-nor-core.c
> > @@ -2855,6 +2855,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
> > const struct spi_nor_flash_parameter *params,
> > u32 *hwcaps)
> > {
> > + struct spi_slave *spi = nor->spi;
> > unsigned int cap;
> >
> > /*
> > @@ -2879,6 +2880,10 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
> > if (!(*hwcaps & BIT(cap)))
> > continue;
> >
> > + if ((spi->mode & SPI_RX_SLOW) &&
> > + (BIT(cap) == SNOR_HWCAPS_READ_FAST))
> > + *hwcaps &= ~BIT(cap);
> > +
>
> NACK.
>
> We already check for SPI_RX_SLOW in spi_nor_scan():
>
> /* Some devices cannot do fast-read, no matter what DT tells us */
> if ((info->flags & SPI_NOR_NO_FR) || (spi->mode & SPI_RX_SLOW))
> params.hwcaps.mask &= ~SNOR_HWCAPS_READ_FAST;
>
> I think the real bug here is that the smart spi_nor_adjust_hwcaps() does
> not respect the flash's hwcaps, and only looks to the controller on what
> can be supported. Doing the below should fix this:
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 8dd44c0f1e..4323b49651 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -2741,7 +2741,7 @@ spi_nor_adjust_hwcaps(struct spi_nor *nor,
> * Enable all caps by default. We will mask them after checking what's
> * really supported using spi_mem_supports_op().
> */
> - *hwcaps = SNOR_HWCAPS_ALL;
> + *hwcaps = SNOR_HWCAPS_ALL & params->hwcaps.mask;
>
> /* X-X-X modes are not supported yet, mask them all. */
> *hwcaps &= ~SNOR_HWCAPS_X_X_X;
>
> Can you please test and confirm if it does indeed fix the issue for you?
Yes, this also fixed the issue.
In fact, we should update spi-nor to honor the DT property
"m25p,fast-read" instead of the SPI_RX_SLOW flag which was set by the
ICH SPI driver.
I will prepare patches soon.
>
> > rdidx = spi_nor_hwcaps_read2cmd(BIT(cap));
> > if (rdidx >= 0 &&
> > spi_nor_check_readop(nor, ¶ms->reads[rdidx]))
Regards,
Bin
[PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64"
From: Jan Kiszka
This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7.
While the goal is valid and there is surely unused memory in that area,
we also have a lot of crucial things still located at the top-of-memory
while running lmb_alloc_base. Such things are the page table (tlb_addr),
relocated U-Boot and the active stack. Possibly more. So this patch was
premature, we will need relocations of those things first if we want to
use the range.
Fixes booting on the IOT2050, but likely also on other boards. It got
stuck on relocating the FDT - over the relocated U-Boot code.
Signed-off-by: Jan Kiszka
---
Practically,
void arch_lmb_reserve(struct lmb *lmb)
{
lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr);
}
worked as well for me - but it left the stack in danger.
arch/arm/lib/bootm.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 23b99a541c..f60ee3a7e6 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -43,7 +43,6 @@ DECLARE_GLOBAL_DATA_PTR;
static struct tag *params;
-#ifndef CONFIG_ARM64
static ulong get_sp(void)
{
ulong ret;
@@ -87,7 +86,6 @@ void arch_lmb_reserve(struct lmb *lmb)
break;
}
}
-#endif
__weak void board_quiesce_devices(void)
{
--
2.26.2
