Re: [PATCH 2/2] part: efi: Treat unused partition type GUID as a valid case
On 3/28/24 23:29, Sam Protsenko wrote:
Some platforms use the "unused" (all-zero) GUID as a partition type GUID
to make some partitions hidden from the OS. For example, Samsung phones
and other devices often have GPT partition tables like that, created by
their "gpt_builder" tool [1]. All partitions with FILESYS=0 value
(second column in [2] file) will be created in a way that:
1. Partition type GUID will be all-zero ("unused")
2. Attributes[48:49] bits will be set to 0 (whereas non-zero values
mean the partition is visible to the OS: 1=raw, 2=ext4, 3=f2fs)
The UEFI specification is defining what a GPT partition table has to
look like.
According the specification partition type GUID
---- marks an "unused entry" in the
partition table.
An unused partition table entry cannot define a partition. It is one of
the entries, that you skip over when enumerating via your patch 1/2.
With this patch 128 partition table entries are printed for an image
having a single partition.
=> part list host 0
Partition Map for HOST device 0 -- Partition Type: EFI
PartStart LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x0800 0x0001f7ff "EFI system partition"
attrs: 0x0005
type: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
(system)
guid: ee474198-4601-4d5c-81f0-54acf904dd40
2 0x 0x ""
attrs: 0x
type: ----
(----)
guid: ----
...
128 0x 0x ""
attrs: 0x
type: ----
(----)
guid: ----
This is definitively wrong.
Although it's true that Linux kernel verifies the partition type GUID to
be non-zero (in block/partitions/efi.c, is_pte_valid() function), where
its U-Boot counterpart code was borrowed from originally, in case of
U-Boot we want to handle partitions with "unused" GUIDs the same way as
any other valid partitions, to allow the user to interact with those
(e.g. list partitions using "part list", be able to flash those via
fastboot, etc).
You cannot interact with a non-existing partition.
You may create a new partition in any empty slot that Samsung's tool has
left in the partition table and then write to it. No patch is needed for
this.
Best regards
Heinrich
[1] https://gitlab.com/Linaro/96boards/e850-96/tools/gpt/
[2]
https://gitlab.com/Linaro/96boards/e850-96/tools/gpt/-/blob/master/gpt_layout
Fixes: 07f3d789b9be ("Add support for CONFIG_EFI_PARTITION (GUID Partition
Table)")
Signed-off-by: Sam Protsenko
---
disk/part_efi.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 4ce9243ef25c..6b138abae0a6 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -1166,28 +1166,17 @@ static gpt_entry *alloc_read_gpt_entries(struct
blk_desc *desc,
*/
static int is_pte_valid(gpt_entry * pte)
{
- efi_guid_t unused_guid;
+ /*
+* NOTE: Do not check unused (zero) GUIDs here, it's considered a valid
+* case in U-Boot.
+*/
if (!pte) {
log_debug("Invalid Argument(s)\n");
return 0;
}
- /* Only one validation for now:
-* The GUID Partition Type != Unused Entry (ALL-ZERO)
-*/
- memset(unused_guid.b, 0, sizeof(unused_guid.b));
-
- if (memcmp(pte->partition_type_guid.b, unused_guid.b,
- sizeof(unused_guid.b)) == 0) {
-
- log_debug("Found an unused PTE GUID at 0x%08X\n",
- (unsigned int)(uintptr_t)pte);
-
- return 0;
- } else {
- return 1;
- }
+ return 1;
}
/*
Re: [PATCH v2] arm: dts: kirkwood: Enable upstream DT on Kirkwood boards
Hi Michael, Hi Stefan, It seems either the Denx server or Gmail has failed to send/deliver Stefan's response to my Inbox. Luckily, I also monitored lore.kernel.org and I saw the response. So I'd like to answer that below. On Thu, Mar 28, 2024 at 12:41 AM Michael Walle wrote: > > Hi, > > On Thu Mar 28, 2024 at 3:18 AM CET, Tony Dinh wrote: > > Enable OF_UPSTREAM to use upstream DT and add marvell/ prefix to the > > DEFAULT_DEVICE_TREE for Kirkwood boards. And so we can directly build > > DTBs from dts/upstream/src/arm/marvell, and including *-u-boot.dtsi > > files from arch/arm/dts/ directory. > > > > Background: > > > > Hi Stefan, > > Hi Michael, > > > > I did a survey and we currently have 28 Kirkwood boards. Using some > > commands and filters, here are the finding. > > > > git grep -li arch_kirkwood configs | xargs grep DEVICE_TREE | cut -d '"' > > -f2 | xargs -n1 sh -c 'diff -qs arch/arm/dts/$1.dts > > dts/upstream/src/arm/marvell/$1.dts' sh | grep differ > > > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifkw.dts: No such > > file or directory > > diff: dts/upstream/src/arm/marvell/kirkwood-atl-sbx81lifxcat.dts: No such > > file or directory > > ... > > Are you sure you want to have all this text in the commit log? > Please see my response to you and Stefan below. > You seem to have forgotten my tag: > Tested-by: Michael Walle # on lschv2 My bad! Stefan's comment (about the large commit text): "This is also my concern. Even though I love descriptive commit messages, this seems to be a bit too much IMHO. Not sure if and how to get these findings of yours archived otherwise." I can send a V3 patch. I will cut out the Background stuff and point it to: https://lore.kernel.org/u-boot/55229181-3aff-4bff-afb5-df778f5f1...@denx.de/T/#t And also I will collect Michael's Test-by tag and your Review-by tag in the commit description. Does that sound OK? Stefan's comment: "Tony, many thanks to work on this consolidation. Very impressive results. I can't test anything of this though, but my plan would be to pull this in the upcoming merge window, if nobody complains." Reviewed-by: Stefan Roese " I think between Michael and I, we've tested 3 representative Kirkwood boards. Time permitted, I will update u-boot for a few of my other Kirkwood boards, and will send patches if I see any regression. All the best, Tony
Re: [PATCH] mtd: spi-nor: Add support to exit 4-byte mode
Hi Tejas,
+ Ian Roberts, my coworker has the following comments:
I do not think it is appropriate to put what appears to be use-case
specific logic into the core functionality.
Your problem statement sounds like the chip is stuck in a stateful
mode after a reset. As alternatives, I would suggest:
1) Toggle the hardware reset line for the chip.
2) If one does not exist, use SPI_FLASH_SOFT_RESET_ON_BOOT
3) Alter your recovery application set the chip back to 3B mode on exit.
As is, I also think this would cause problems for chips with existing
support. set_4byte() sends commands to the chip, which may be
unrecognized or overlap with a manufacturer's custom command and cause
unintended side effects.
On Thu, Mar 28, 2024 at 11:37 AM Tejas Bhumkar
wrote:
>
> The Kria board features a recovery application that activates
> when the FW_EN button is pressed.
> Upon power-up flash operates in 3B mode, However, the recovery
> application changes it back to 4B mode.
> Following a reset, u-boot activates the CONFIG_SPI_FLASH_BAR
> and expects the flash to be in 3B mode. However, there's no
> code to handle this configuration. to address this issue, changes
> were made to disable the 4B mode when the CONFIG_SPI_FLASH_BAR
> is enabled.
>
> Additionally, spi_nor_wait_till_ready() was included because there is
> operation that places the device in a busy state before performing
> a nor read.
>
> Signed-off-by: Tejas Bhumkar
> ---
> drivers/mtd/spi/spi-nor-core.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index f86003ca8c..47f65a4f5e 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -1464,6 +1464,9 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
> from, size_t len,
> else
> read_len = remain_len;
> #endif
> + ret = spi_nor_wait_till_ready(nor);
> + if (ret)
> + goto read_err;
Can you elaborate on the purpose of this wait_till_ready?
>
> ret = nor->read(nor, addr, read_len, buf);
> if (ret == 0) {
> @@ -4161,6 +4164,7 @@ int spi_nor_scan(struct spi_nor *nor)
> #else
> /* Configure the BAR - discover bank cmds and read current bank */
> nor->addr_width = 3;
> + set_4byte(nor, info, 0);
> ret = read_bar(nor, info);
> if (ret < 0)
> return ret;
> --
> 2.37.6
>
Thanks,
Greg
--
Greg Malysa
Timesys Corporation
Re: [PATCH 1/2] part: Check all partitions in part_get_info_by_name()
On 3/28/24 23:29, Sam Protsenko wrote:
In part_get_info_by_name() the inability to get some partition info
shouldn't be a reason for dropping out of the loop. That might happen
e.g. if the partition is hidden or unused. An example of such case are
Samsung devices, where they use the "unused" GUID type
(----) to indicate that the partition
should be hidden from the OS. Such partitions might not be seen in
"part list" output, which creates "gaps" in numbering in between of the
visible partitions:
PartStart LBA End LBA Name
1 0x0400 0xa3ff "efs"
5 0x00026420 0x00026c1f "dtbo"
12 0x0003f390 0x0074738f "super"
In that case, the loop in part_get_info_by_name() would break after
partition #1, so any attempt to obtain "dtbo" or "super" partition will
fail. Fix that by continuing to iterate over the remaining partitions to
make sure none of the visible ones is missed. That makes "part" command
(e.g. "part start", "part size") able to work with such tables.
Fixes: 87b8530fe244 ("disk: part: implement generic function
part_get_info_by_name()")
Signed-off-by: Sam Protsenko
Reviewed-by: Heinrich Schuchardt
---
disk/part.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 36b88205eca7..08c9331e059c 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -717,8 +717,11 @@ int part_get_info_by_name(struct blk_desc *desc, const
char *name,
for (i = 1; i < part_drv->max_entries; i++) {
ret = part_drv->get_info(desc, i, info);
if (ret != 0) {
- /* no more entries in table */
- break;
+ /*
+* Partition with this index can't be obtained, but
+* further partitions might be, so keep checking.
+*/
+ continue;
}
if (strcmp(name, (const char *)info->name) == 0) {
/* matched */
Re: [PATCH 1/2] rockchip: rk3588: Add support for ATAG parsing
On Thu, Mar 28, 2024 at 04:02:09PM -0400, Tom Rini wrote: > On Wed, Mar 27, 2024 at 10:03:11AM -0500, Chris Morgan wrote: > > On Wed, Mar 27, 2024 at 04:21:49PM +0200, Eugen Hristev wrote: > > > On 3/27/24 15:32, Chris Morgan wrote: > > > > On Wed, Mar 27, 2024 at 06:32:06PM +0800, Kever Yang wrote: > > > >> Hi Chris, > > > >> > > > >> The ATAGS is used for passing parameter from bootloader to kernel > > > >> at > > > >> first, which has been replaced by DTB now for ARM platform. > > > >> > > > >> And Rockchip using ATAGs for passing parameter like dram memory > > > >> size/board uart in different boot process like DRAM init binary/ > > > >> TPL/SPL to > > > >> U-Boot since 2018. > > > >> > > > >> And almost at the same time, Simon add bloblist for mainline U-Boot > > > >> which for similar purpose. > > > >> > > > >> So I'm not sure if this ATAGS should be accept in mainline U-Boot > > > >> or > > > >> not, even for rockchip platform only seems some kind of regression for > > > >> this > > > >> feature support. > > > >> > > > >> > > > >> Hi Simon and Tom, > > > >> > > > >> Could you help to give some suggestion for this? > > > >> > > > > > > > > I really meant to do this as an "RFC", so I apologize in advance for > > > > possibly causing more work in treating this as a full-fledged patch. > > > > > > > > The problem I'm trying to solve is that I've got 2 boards, a Rock 5B > > > > as well as an Indiedroid Nova both with 16GB of RAM. I noticed that > > > > without the memory holes the Rock 5B defined in my Indiedroid it would > > > > also fail to boot. I've got 2 other boards as well with less than 16GB > > > > of RAM which seem to work fine without any holes (a 4GB Indiedroid Nova > > > > prototype and a GameForce Ace with 12GB of RAM). > > > > > > Hi, > > > > > > When I initially added these holes in the memory, I tried to ask Rockchip > > > what are > > > the holes for. I didn't get any answer, however the patches to reserve > > > the holes > > > were accepted. > > > If we could get more information about why the holes are there, if that > > > area is > > > specific to something, or that it's fixed in a per-SoC basis, we could > > > reserve it > > > by hardcoding in the Linux DT, without the need for ATAGs. > > > Without real information, we cannot be sure that for other variants of > > > the SoC or > > > some other bootrom configuration, the holes will not change/move. > > > > > > Eugen > > > > It's not *just* about the holes, but also making sure we use the full > > extent of the RAM. For example on my 4GB Indiedroid Nova the existing > > logic ignores about 256MB of RAM that's otherwise present. When we > > use the existing code the RAM map reported by Linux is as follows: > > > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x0020-0xefff] > > > > Whereas when we do ATAGS parsing to set the banks we get the following: > > > > [0.00] Early memory node ranges > > [0.00] node 0: [mem 0x0020-0xefff] > > [0.00] node 0: [mem 0x0001f000-0x0001] > > > > So basically the issue is two-fold... one we need to create the memory > > holes when necessary, and two the current method of defining memory > > banks leaves some RAM unallocated. Parsing the ATAGS does both of these, > > I'm just curious if it's the RIGHT way or there's something else I'm > > missing... > > It's unfortunate that all of this is in the wild, from the Rockchip > side. The best answer is that the platform should be passing all of this > along via bloblist. I would hope that future platforms will do that. For > now yes, I guess we need to constrain this ATAG parsing to rockchip as > much as we can and use it. Any thought/benefit of trying to force the ATAGS into a bloblist after the fact (instead of expecting it to be passed that way)? Otherwise yes I'll work on simplified ATAGS parsing for the memory info and constrain it to the rk3588 specific board code/wrap it around ROCKCHIP_TPL present. Thank you, Chris > > -- > Tom
[PATCH 2/2] part: efi: Treat unused partition type GUID as a valid case
Some platforms use the "unused" (all-zero) GUID as a partition type GUID
to make some partitions hidden from the OS. For example, Samsung phones
and other devices often have GPT partition tables like that, created by
their "gpt_builder" tool [1]. All partitions with FILESYS=0 value
(second column in [2] file) will be created in a way that:
1. Partition type GUID will be all-zero ("unused")
2. Attributes[48:49] bits will be set to 0 (whereas non-zero values
mean the partition is visible to the OS: 1=raw, 2=ext4, 3=f2fs)
Although it's true that Linux kernel verifies the partition type GUID to
be non-zero (in block/partitions/efi.c, is_pte_valid() function), where
its U-Boot counterpart code was borrowed from originally, in case of
U-Boot we want to handle partitions with "unused" GUIDs the same way as
any other valid partitions, to allow the user to interact with those
(e.g. list partitions using "part list", be able to flash those via
fastboot, etc).
[1] https://gitlab.com/Linaro/96boards/e850-96/tools/gpt/
[2]
https://gitlab.com/Linaro/96boards/e850-96/tools/gpt/-/blob/master/gpt_layout
Fixes: 07f3d789b9be ("Add support for CONFIG_EFI_PARTITION (GUID Partition
Table)")
Signed-off-by: Sam Protsenko
---
disk/part_efi.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index 4ce9243ef25c..6b138abae0a6 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -1166,28 +1166,17 @@ static gpt_entry *alloc_read_gpt_entries(struct
blk_desc *desc,
*/
static int is_pte_valid(gpt_entry * pte)
{
- efi_guid_t unused_guid;
+ /*
+* NOTE: Do not check unused (zero) GUIDs here, it's considered a valid
+* case in U-Boot.
+*/
if (!pte) {
log_debug("Invalid Argument(s)\n");
return 0;
}
- /* Only one validation for now:
-* The GUID Partition Type != Unused Entry (ALL-ZERO)
-*/
- memset(unused_guid.b, 0, sizeof(unused_guid.b));
-
- if (memcmp(pte->partition_type_guid.b, unused_guid.b,
- sizeof(unused_guid.b)) == 0) {
-
- log_debug("Found an unused PTE GUID at 0x%08X\n",
- (unsigned int)(uintptr_t)pte);
-
- return 0;
- } else {
- return 1;
- }
+ return 1;
}
/*
--
2.39.2
[PATCH 1/2] part: Check all partitions in part_get_info_by_name()
In part_get_info_by_name() the inability to get some partition info
shouldn't be a reason for dropping out of the loop. That might happen
e.g. if the partition is hidden or unused. An example of such case are
Samsung devices, where they use the "unused" GUID type
(----) to indicate that the partition
should be hidden from the OS. Such partitions might not be seen in
"part list" output, which creates "gaps" in numbering in between of the
visible partitions:
PartStart LBA End LBA Name
1 0x0400 0xa3ff "efs"
5 0x00026420 0x00026c1f "dtbo"
12 0x0003f390 0x0074738f "super"
In that case, the loop in part_get_info_by_name() would break after
partition #1, so any attempt to obtain "dtbo" or "super" partition will
fail. Fix that by continuing to iterate over the remaining partitions to
make sure none of the visible ones is missed. That makes "part" command
(e.g. "part start", "part size") able to work with such tables.
Fixes: 87b8530fe244 ("disk: part: implement generic function
part_get_info_by_name()")
Signed-off-by: Sam Protsenko
---
disk/part.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/disk/part.c b/disk/part.c
index 36b88205eca7..08c9331e059c 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -717,8 +717,11 @@ int part_get_info_by_name(struct blk_desc *desc, const
char *name,
for (i = 1; i < part_drv->max_entries; i++) {
ret = part_drv->get_info(desc, i, info);
if (ret != 0) {
- /* no more entries in table */
- break;
+ /*
+* Partition with this index can't be obtained, but
+* further partitions might be, so keep checking.
+*/
+ continue;
}
if (strcmp(name, (const char *)info->name) == 0) {
/* matched */
--
2.39.2
Re: [PATCH 1/2] rockchip: rk3588: Add support for ATAG parsing
On Thu, Mar 28, 2024 at 04:58:53PM -0500, Chris Morgan wrote: > On Thu, Mar 28, 2024 at 04:02:09PM -0400, Tom Rini wrote: > > On Wed, Mar 27, 2024 at 10:03:11AM -0500, Chris Morgan wrote: > > > On Wed, Mar 27, 2024 at 04:21:49PM +0200, Eugen Hristev wrote: > > > > On 3/27/24 15:32, Chris Morgan wrote: > > > > > On Wed, Mar 27, 2024 at 06:32:06PM +0800, Kever Yang wrote: > > > > >> Hi Chris, > > > > >> > > > > >> The ATAGS is used for passing parameter from bootloader to > > > > >> kernel at > > > > >> first, which has been replaced by DTB now for ARM platform. > > > > >> > > > > >> And Rockchip using ATAGs for passing parameter like dram memory > > > > >> size/board uart in different boot process like DRAM init binary/ > > > > >> TPL/SPL to > > > > >> U-Boot since 2018. > > > > >> > > > > >> And almost at the same time, Simon add bloblist for mainline > > > > >> U-Boot > > > > >> which for similar purpose. > > > > >> > > > > >> So I'm not sure if this ATAGS should be accept in mainline > > > > >> U-Boot or > > > > >> not, even for rockchip platform only seems some kind of regression > > > > >> for this > > > > >> feature support. > > > > >> > > > > >> > > > > >> Hi Simon and Tom, > > > > >> > > > > >> Could you help to give some suggestion for this? > > > > >> > > > > > > > > > > I really meant to do this as an "RFC", so I apologize in advance for > > > > > possibly causing more work in treating this as a full-fledged patch. > > > > > > > > > > The problem I'm trying to solve is that I've got 2 boards, a Rock 5B > > > > > as well as an Indiedroid Nova both with 16GB of RAM. I noticed that > > > > > without the memory holes the Rock 5B defined in my Indiedroid it would > > > > > also fail to boot. I've got 2 other boards as well with less than 16GB > > > > > of RAM which seem to work fine without any holes (a 4GB Indiedroid > > > > > Nova > > > > > prototype and a GameForce Ace with 12GB of RAM). > > > > > > > > Hi, > > > > > > > > When I initially added these holes in the memory, I tried to ask > > > > Rockchip what are > > > > the holes for. I didn't get any answer, however the patches to reserve > > > > the holes > > > > were accepted. > > > > If we could get more information about why the holes are there, if that > > > > area is > > > > specific to something, or that it's fixed in a per-SoC basis, we could > > > > reserve it > > > > by hardcoding in the Linux DT, without the need for ATAGs. > > > > Without real information, we cannot be sure that for other variants of > > > > the SoC or > > > > some other bootrom configuration, the holes will not change/move. > > > > > > > > Eugen > > > > > > It's not *just* about the holes, but also making sure we use the full > > > extent of the RAM. For example on my 4GB Indiedroid Nova the existing > > > logic ignores about 256MB of RAM that's otherwise present. When we > > > use the existing code the RAM map reported by Linux is as follows: > > > > > > [0.00] Early memory node ranges > > > [0.00] node 0: [mem 0x0020-0xefff] > > > > > > Whereas when we do ATAGS parsing to set the banks we get the following: > > > > > > [0.00] Early memory node ranges > > > [0.00] node 0: [mem 0x0020-0xefff] > > > [0.00] node 0: [mem 0x0001f000-0x0001] > > > > > > So basically the issue is two-fold... one we need to create the memory > > > holes when necessary, and two the current method of defining memory > > > banks leaves some RAM unallocated. Parsing the ATAGS does both of these, > > > I'm just curious if it's the RIGHT way or there's something else I'm > > > missing... > > > > It's unfortunate that all of this is in the wild, from the Rockchip > > side. The best answer is that the platform should be passing all of this > > along via bloblist. I would hope that future platforms will do that. For > > now yes, I guess we need to constrain this ATAG parsing to rockchip as > > much as we can and use it. > > Any thought/benefit of trying to force the ATAGS into a bloblist after the > fact (instead of expecting it to be passed that way)? Otherwise yes I'll > work on simplified ATAGS parsing for the memory info and constrain it to > the rk3588 specific board code/wrap it around ROCKCHIP_TPL present. I don't think it's worth the code size to convert the ATAGS to bloblist at this time. In the future when we have rockchip platforms that pass bloblist natively at that point it might make sense to convert the ATAGS instead. -- Tom signature.asc Description: PGP signature
[PATCH 1/1] riscv: starfive: MMC card detect
The VisionFive 2 board uses GPIO 41 as card detect as documented in https://doc-en.rvspace.org/VisionFive2/PDF/SCH_RV002_V1.2A_20221216.pdf. Signed-off-by: Heinrich Schuchardt --- arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi index f2c6bec9298..e11babc1cde 100644 --- a/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi +++ b/arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi @@ -298,7 +298,7 @@ pinctrl-0 = <_pins>; no-sdio; no-mmc; - broken-cd; + cd-gpios = < 41 GPIO_ACTIVE_LOW>; cap-sd-highspeed; post-power-on-delay-ms = <200>; status = "okay"; -- 2.43.0
Re: Upcoming Analog Devices SoC Support Submission
On Mon, Mar 25, 2024 at 10:47:30PM -0400, Greg Malysa wrote: > Hi Tom, > > I wanted to get a little bit of guidance before dumping some patches > on the mailing list. I've been preparing to submit support we've > developed for the Analog Devices SC5xx SoCs including both core SoC > support and specific device trees and defconfigs for the eval kits > available from ADI. I've submitted several small patches to touch > various shared parts of U-Boot that we needed to extend to get this > hardware running and to get some familiarity with using patman to > format and submit things, but now I have a roughly 15k line changeset > consisting of a new mach type and all of the required drivers for the > system. It's broken down into a bunch of commits: one for the mach > type support, one per driver we've added, and one per target board > supported. > > What is the best way to submit this? Ideally I'd love to get feedback > on individual drivers from the respective subsystem maintainers, but > it seems rude to have a 20-element patch series that gets resubmitted > each time feedback comes in for one component. If we break it down > into separate patches for each piece, what would be the best way to > ensure that all of the dependencies are merged in order? Well, I would first make sure that CI passes for your tree. Then, make sure that you're using OF_UPSTREAM to get your device trees as well. Then just submit the SoC core + board (and make sure it's using plain text environment and standard boot and so on), then start with the additional drivers. -- Tom signature.asc Description: PGP signature
Re: [PATCH v10 2/2] dt-bindings: mtd: fixed-partition: Add binman compatibles
On Tue, 26 Mar 2024 14:06:45 -0600, Simon Glass wrote: > Add two compatibles for binman entries, as a starting point for the > schema. > > Note that, after discussion on v2, we decided to keep the existing > meaning of label so as not to require changes to existing userspace > software when moving to use binman nodes to specify the firmware > layout. > > Note also that, after discussion on v6, we decided to use the same > 'fixed-partition' schema for the binman features, so this version > adds a new 'binman.yaml' file providing the new compatibles to the > existing partition.yaml binding. > > Signed-off-by: Simon Glass > --- > > Changes in v10: > - Drop binman,entry since it is likely not necessary > - Put the description back > > Changes in v8: > - Switch the patch ordering so the partition change comes first > > Changes in v7: > - Adjust MAINTAINERS entry > - Put compatible strings into the 'fixed-partition' binding > > Changes in v5: > - Add mention of why 'binman' is the vendor > - Drop 'select: false' > - Tidy up the compatible setings > - Use 'tfa-bl31' instead of 'atf-bl31' > > Changes in v4: > - Correct selection of multiple compatible strings > > Changes in v3: > - Drop fixed-partitions from the example > - Use compatible instead of label > > Changes in v2: > - Use plain partition@xxx for the node name > > .../bindings/mtd/partitions/binman.yaml | 53 +++ > .../bindings/mtd/partitions/partition.yaml| 21 > MAINTAINERS | 5 ++ > 3 files changed, 79 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/mtd/partitions/binman.yaml > Reviewed-by: Rob Herring
[PATCH 1/1] doc: missing :: in doc/usage/cmd/itest.rst
Add :: for correct formatting of example. Signed-off-by: Heinrich Schuchardt --- doc/usage/cmd/itest.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/usage/cmd/itest.rst b/doc/usage/cmd/itest.rst index ab933db760d..9c307fb4bf4 100644 --- a/doc/usage/cmd/itest.rst +++ b/doc/usage/cmd/itest.rst @@ -86,6 +86,8 @@ Numbers will be truncated according to the postfix before comparing: Postfix .s causes a string compare. The string '0xa1234' is alphabetically smaller than '0xb'. +:: + => if itest.s 0xa1234 < 0xb; then echo true; else echo false; fi true -- 2.43.0
Re: Pull request doc-2024-04-rc6
On Thu, Mar 28, 2024 at 08:56:54PM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit dde373bde392c38649c8c4420e0c98ef8d38d9dc: > > Prepare v2024.04-rc5 (2024-03-25 21:56:50 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/doc-2024-04-rc6 > > for you to fetch changes up to d2fbe1fa29190fc1209364b3d5e33294009da9bd: > > doc: add reference to itest in if man-page (2024-03-27 09:30:07 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/20082 > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] rockchip: rk3588: Add support for ATAG parsing
On Wed, Mar 27, 2024 at 10:03:11AM -0500, Chris Morgan wrote: > On Wed, Mar 27, 2024 at 04:21:49PM +0200, Eugen Hristev wrote: > > On 3/27/24 15:32, Chris Morgan wrote: > > > On Wed, Mar 27, 2024 at 06:32:06PM +0800, Kever Yang wrote: > > >> Hi Chris, > > >> > > >> The ATAGS is used for passing parameter from bootloader to kernel at > > >> first, which has been replaced by DTB now for ARM platform. > > >> > > >> And Rockchip using ATAGs for passing parameter like dram memory > > >> size/board uart in different boot process like DRAM init binary/ TPL/SPL > > >> to > > >> U-Boot since 2018. > > >> > > >> And almost at the same time, Simon add bloblist for mainline U-Boot > > >> which for similar purpose. > > >> > > >> So I'm not sure if this ATAGS should be accept in mainline U-Boot or > > >> not, even for rockchip platform only seems some kind of regression for > > >> this > > >> feature support. > > >> > > >> > > >> Hi Simon and Tom, > > >> > > >> Could you help to give some suggestion for this? > > >> > > > > > > I really meant to do this as an "RFC", so I apologize in advance for > > > possibly causing more work in treating this as a full-fledged patch. > > > > > > The problem I'm trying to solve is that I've got 2 boards, a Rock 5B > > > as well as an Indiedroid Nova both with 16GB of RAM. I noticed that > > > without the memory holes the Rock 5B defined in my Indiedroid it would > > > also fail to boot. I've got 2 other boards as well with less than 16GB > > > of RAM which seem to work fine without any holes (a 4GB Indiedroid Nova > > > prototype and a GameForce Ace with 12GB of RAM). > > > > Hi, > > > > When I initially added these holes in the memory, I tried to ask Rockchip > > what are > > the holes for. I didn't get any answer, however the patches to reserve the > > holes > > were accepted. > > If we could get more information about why the holes are there, if that > > area is > > specific to something, or that it's fixed in a per-SoC basis, we could > > reserve it > > by hardcoding in the Linux DT, without the need for ATAGs. > > Without real information, we cannot be sure that for other variants of the > > SoC or > > some other bootrom configuration, the holes will not change/move. > > > > Eugen > > It's not *just* about the holes, but also making sure we use the full > extent of the RAM. For example on my 4GB Indiedroid Nova the existing > logic ignores about 256MB of RAM that's otherwise present. When we > use the existing code the RAM map reported by Linux is as follows: > > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x0020-0xefff] > > Whereas when we do ATAGS parsing to set the banks we get the following: > > [0.00] Early memory node ranges > [0.00] node 0: [mem 0x0020-0xefff] > [0.00] node 0: [mem 0x0001f000-0x0001] > > So basically the issue is two-fold... one we need to create the memory > holes when necessary, and two the current method of defining memory > banks leaves some RAM unallocated. Parsing the ATAGS does both of these, > I'm just curious if it's the RIGHT way or there's something else I'm > missing... It's unfortunate that all of this is in the wild, from the Rockchip side. The best answer is that the platform should be passing all of this along via bloblist. I would hope that future platforms will do that. For now yes, I guess we need to constrain this ATAG parsing to rockchip as much as we can and use it. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/4] zlib: Address CVE-2016-9841
On Wed, Mar 27, 2024 at 03:14:49PM +0100, Michal Simek wrote: > Hi, > > it looks like that only CVE-2016-9841 is not fixed and this series is > trying to address it. The first two patches are just preparation based on > changes which happened in past. The third one is actual fix and the last > one is following what has been done in Linux kernel long time ago and don't > use incorrect zlib version string. > > I tested it with and I can't see any issue. > ./test/py/test.py --bd sandbox --build -s > > And gitlab CI is also not showing any issue. Thanks for taking this on. I've given it a quick spin on some Pi platforms as well as before/after and I see that it's also reducing the overall binary size everywhere as well. -- Tom signature.asc Description: PGP signature
Pull request doc-2024-04-rc6
Dear Tom, The following changes since commit dde373bde392c38649c8c4420e0c98ef8d38d9dc: Prepare v2024.04-rc5 (2024-03-25 21:56:50 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git tags/doc-2024-04-rc6 for you to fetch changes up to d2fbe1fa29190fc1209364b3d5e33294009da9bd: doc: add reference to itest in if man-page (2024-03-27 09:30:07 +0100) Gitlab CI showed no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/20082 Pull request doc-2024-04-rc6 Documentation: * man page of 'itest' * tee: sandbox: fix spelling errors in function documentation Heinrich Schuchardt (2): doc: man-page for itest doc: add reference to itest in if man-page Igor Opaniuk (1): tee: sandbox: fix spelling errors doc/usage/cmd/if.rst| 6 +-- doc/usage/cmd/itest.rst | 113 doc/usage/index.rst | 1 + drivers/tee/sandbox.c | 8 ++-- 4 files changed, 121 insertions(+), 7 deletions(-) create mode 100644 doc/usage/cmd/itest.rst
[PATCH] imx8mq_evk: Remove FEC and Ethernet PHY board code
With Ethernet DM in place, there is no longer the need for having
the board_phy_config() and setup_fec() functions anymore.
Remove them.
Successfully tested a TFTP transfer after these changes.
Signed-off-by: Fabio Estevam
---
board/freescale/imx8mq_evk/imx8mq_evk.c | 30 -
1 file changed, 30 deletions(-)
diff --git a/board/freescale/imx8mq_evk/imx8mq_evk.c
b/board/freescale/imx8mq_evk/imx8mq_evk.c
index e39480585609..e577e4d9ccaa 100644
--- a/board/freescale/imx8mq_evk/imx8mq_evk.c
+++ b/board/freescale/imx8mq_evk/imx8mq_evk.c
@@ -54,38 +54,8 @@ int board_early_init_f(void)
return 0;
}
-#ifdef CONFIG_FEC_MXC
-static int setup_fec(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
- /* Use 125M anatop REF_CLK1 for ENET1, not from external */
- clrsetbits_le32(>gpr[1], BIT(13) | BIT(17), 0);
- return set_clk_enet(ENET_125MHZ);
-}
-
-int board_phy_config(struct phy_device *phydev)
-{
- /* enable rgmii rxc skew and phy mode select to RGMII copper */
- phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x1f);
- phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x8);
-
- phy_write(phydev, MDIO_DEVAD_NONE, 0x1d, 0x05);
- phy_write(phydev, MDIO_DEVAD_NONE, 0x1e, 0x100);
-
- if (phydev->drv->config)
- phydev->drv->config(phydev);
- return 0;
-}
-#endif
-
int board_init(void)
{
-#ifdef CONFIG_FEC_MXC
- setup_fec();
-#endif
-
#if defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_XHCI_DWC3)
init_usb_clk();
#endif
--
2.34.1
[PATCH v5 16/16] usb: gadget: UMS: fix 64-bit division on ARM32
The patch introducing support for dynamic sector sizes changed the types
used in some divisions, resulting in the compiler attempting to use
libgcc helpers (__aeabi_ldivmod). Replace these divisions with calls to
lldiv() to handle this correctly.
Fixes: 74e56e0c5065 ("usb: gadget: UMS: support multiple sector sizes")
Signed-off-by: Caleb Connolly
---
Cc: Mattijs Korpershoek
---
drivers/usb/gadget/f_mass_storage.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index d880928044f4..ef90c7ec7fb5 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -239,8 +239,9 @@
/* #define VERBOSE_DEBUG */
/* #define DUMP_MSGS */
#include
+#include
#include
#include
#include
#include
@@ -768,10 +769,10 @@ static int do_read(struct fsg_common *common)
}
/* Perform the read */
rc = ums[common->lun].read_sector([common->lun],
- file_offset / curlun->blksize,
- amount / curlun->blksize,
+ lldiv(file_offset, curlun->blksize),
+ lldiv(amount, curlun->blksize),
(char __user *)bh->buf);
if (!rc)
return -EIO;
@@ -942,10 +943,10 @@ static int do_write(struct fsg_common *common)
amount = bh->outreq->actual;
/* Perform the write */
rc = ums[common->lun].write_sector([common->lun],
- file_offset / curlun->blksize,
- amount / curlun->blksize,
+ lldiv(file_offset,
curlun->blksize),
+ lldiv(amount, curlun->blksize),
(char __user *)bh->buf);
if (!rc)
return -EIO;
nwritten = rc * curlun->blksize;
@@ -1058,10 +1059,10 @@ static int do_verify(struct fsg_common *common)
}
/* Perform the read */
rc = ums[common->lun].read_sector([common->lun],
- file_offset / curlun->blksize,
- amount / curlun->blksize,
+ lldiv(file_offset, curlun->blksize),
+ lldiv(amount, curlun->blksize),
(char __user *)bh->buf);
if (!rc)
return -EIO;
nread = rc * curlun->blksize;
--
2.44.0
[PATCH v5 15/16] qcom_defconfig: enable USB
Enable support for the DWC3 USB controller and required dependencies for Qualcomm boards, specifically the DB845c: * IOMMU / SMMU * USB high-speed PHYs * Mass storage and ACM gadgets Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 52 -- 1 file changed, 29 insertions(+), 23 deletions(-) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index 8c4402e8f780..1abb57345ff1 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -17,10 +17,16 @@ CONFIG_LOG_MAX_LEVEL=9 CONFIG_LOG_DEFAULT_LEVEL=4 # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_CMD_BOOTMENU=y +CONFIG_CMD_EEPROM=y +CONFIG_SYS_I2C_EEPROM_BUS=2 +CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 +CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5 +# CONFIG_CMD_BIND is not set CONFIG_CMD_CLK=y CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_CAT=y @@ -32,20 +38,39 @@ CONFIG_CLK=y CONFIG_CLK_QCOM_QCS404=y CONFIG_CLK_QCOM_SDM845=y CONFIG_MSM_GPIO=y CONFIG_QCOM_PMIC_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_QUP=y +CONFIG_I2C_MUX=y CONFIG_DM_KEYBOARD=y CONFIG_BUTTON_KEYBOARD=y +CONFIG_IOMMU=y +CONFIG_QCOM_HYP_SMMU=y +CONFIG_MISC=y +CONFIG_NVMEM=y +CONFIG_I2C_EEPROM=y CONFIG_MMC_HS200_SUPPORT=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_ADMA=y CONFIG_MMC_SDHCI_MSM=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_DM_MDIO=y +CONFIG_DM_ETH_PHY=y +CONFIG_DWC_ETH_QOS=y +CONFIG_DWC_ETH_QOS_QCOM=y +CONFIG_RGMII=y CONFIG_PHY=y +CONFIG_PHY_QCOM_QUSB2=y +CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2=y CONFIG_PINCTRL=y CONFIG_PINCTRL_QCOM_QCS404=y CONFIG_PINCTRL_QCOM_SDM845=y CONFIG_DM_PMIC=y CONFIG_PMIC_QCOM=y +CONFIG_DM_REGULATOR=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_SCSI=y CONFIG_MSM_SERIAL=y CONFIG_MSM_GENI_SERIAL=y CONFIG_SPMI_MSM=y @@ -54,8 +79,12 @@ CONFIG_SYSINFO_SMBIOS=y CONFIG_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_USB_FUNCTION_MASS_STORAGE=y CONFIG_UFS=y CONFIG_VIDEO=y # CONFIG_VIDEO_FONT_8X16 is not set CONFIG_VIDEO_FONT_16X32=y @@ -64,27 +93,4 @@ CONFIG_NO_FB_CLEAR=y CONFIG_VIDEO_SIMPLE=y CONFIG_HEXDUMP=y # CONFIG_GENERATE_SMBIOS_TABLE is not set CONFIG_LMB_MAX_REGIONS=64 -CONFIG_CMD_DHCP=y -CONFIG_CMD_EEPROM=y -CONFIG_CMD_I2C=y -CONFIG_CMD_PING=y -CONFIG_DM_ETH=y -CONFIG_DM_ETH_PHY=y -CONFIG_DM_MDIO=y -CONFIG_DWC_ETH_QOS=y -CONFIG_DWC_ETH_QOS_QCOM=y -CONFIG_RGMII=y -CONFIG_PHY_MICREL=y -CONFIG_PHY_MICREL_KSZ90X1=y -CONFIG_MISC=y -CONFIG_NVMEM=y -CONFIG_DM_I2C=y -CONFIG_I2C_SUPPORT=y -CONFIG_I2C_MUX=y -CONFIG_I2C_EEPROM=y -CONFIG_SYS_I2C=y -CONFIG_SYS_I2C_QUP=y -CONFIG_SYS_I2C_EEPROM_BUS=2 -CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2 -CONFIG_SYS_EEPROM_PAGE_WRITE_BITS=5 -- 2.44.0
[PATCH v5 14/16] qcom_defconfig: enable livetree
Qualcomm FDTs are on the larger size, and with the addition of DT modifications during board_init() it makes sense to enable OF_LIVE globally. The cost of building the tree should be offset by the increased efficiency at which we can walk it. Some rough measurements with CONFIG_BOOTSTAGE suggests that this might add 0.1-0.2ms to the boot-to-console time. However the reset-to-reset timer difference is in the range of 0.5ms so this could just be noise. Suffice to say, no significant slow down. Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly --- configs/qcom_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qcom_defconfig b/configs/qcom_defconfig index cbc612b44bd9..8c4402e8f780 100644 --- a/configs/qcom_defconfig +++ b/configs/qcom_defconfig @@ -25,8 +25,9 @@ CONFIG_CMD_UFS=y CONFIG_CMD_USB=y CONFIG_CMD_CAT=y CONFIG_CMD_BMP=y CONFIG_CMD_LOG=y +CONFIG_OF_LIVE=y CONFIG_BUTTON_QCOM_PMIC=y CONFIG_CLK=y CONFIG_CLK_QCOM_QCS404=y CONFIG_CLK_QCOM_SDM845=y -- 2.44.0
[PATCH v5 13/16] dts: sdm845-db845c: add u-boot fixups
The USB VBUS supply for the type-A port is enabled via a GPIO regulator.
This is incorrectly modelled in Linux where only the PCIe dependency is
expressed. The correct way to handle this will be through a
usb-connector node, but for now we'll just mark the regulator as
always-on so that it will be enabled automatically during boot.
Signed-off-by: Caleb Connolly
---
arch/arm/dts/sdm845-db845c-u-boot.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/sdm845-db845c-u-boot.dtsi
b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
new file mode 100644
index ..906f9faa5451
--- /dev/null
+++ b/arch/arm/dts/sdm845-db845c-u-boot.dtsi
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0
+
+/* Needed for Linux to boot from USB, otherwise if PCIe driver is not in
initramfs
+ * the VBUS supply will never get turned on.
+ *
https://lore.kernel.org/linux-arm-msm/20240320122515.3243711-1-caleb.conno...@linaro.org/
+ */
+_3p3v_dual {
+ regulator-always-on;
+};
--
2.44.0
[PATCH v5 12/16] mach-snapdragon: call regulators_enable_boot_on()
Make sure we power on any boot-on or always-on regulators. These are
used for peripherals like USB on some platforms.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/board.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 65e4c61e866a..3d5994c87886 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -15,8 +15,9 @@
#include
#include
#include
#include
+#include
#include
#include
#include
#include
@@ -160,8 +161,9 @@ void __weak qcom_board_init(void)
}
int board_init(void)
{
+ regulators_enable_boot_on(false);
show_psci_version();
qcom_of_fixup_nodes();
qcom_board_init();
return 0;
--
2.44.0
[PATCH v5 11/16] mach-snapdragon: fixup power-domains
We don't support the RPM(h)PD power domains in U-Boot, and we don't need
to - the necessary resources are on, and we aren't going to enter any
low power modes.
We could try using a no-op device, but this requires adding a compatible
for every platform, and just pollutes the driver model. So instead let's
just remove every "power-domains" property that references the RPM(h)pd
power controller. This takes <1ms as we're using OF_LIVE.
Of note, this only applies to drivers which are loading post-relocation.
Drivers loaded pre-reloc that reference the rpm(h)pd still need
DM_FLAG_DEFAULT_PD_CTRL_OFF in their flags.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/of_fixup.c | 32
1 file changed, 32 insertions(+)
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
index 4fdfed2dff16..3f7ac227bd09 100644
--- a/arch/arm/mach-snapdragon/of_fixup.c
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -21,8 +21,9 @@
#include
#include
#include
#include
+#include
#include
/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
* USB controllers. Rather than requiring source level DT changes, we fix up
@@ -109,8 +110,38 @@ static void fixup_usb_nodes(void)
log_warning("Failed to fixup node %s: %d\n",
glue_np->name, ret);
}
}
+/* Remove all references to the rpmhpd device */
+static void fixup_power_domains(void)
+{
+ struct device_node *pd = NULL, *np = NULL;
+ struct property *prop;
+ const __be32 *val;
+
+ /* All Qualcomm platforms name the rpm(h)pd "power-controller" */
+ for_each_of_allnodes(pd) {
+ if (pd->name && !strcmp("power-controller", pd->name))
+ break;
+ }
+
+ /* Sanity check that this is indeed a power domain controller */
+ if (!of_find_property(pd, "#power-domain-cells", NULL)) {
+ log_err("Found power-controller but it doesn't have
#power-domain-cells\n");
+ return;
+ }
+
+ /* Remove all references to the power domain controller */
+ for_each_of_allnodes(np) {
+ if (!(prop = of_find_property(np, "power-domains", NULL)))
+ continue;
+
+ val = prop->value;
+ if (val[0] == cpu_to_fdt32(pd->phandle))
+ of_remove_property(np, prop);
+ }
+}
+
#define time_call(func, ...) \
do { \
u64 start = timer_get_us(); \
func(__VA_ARGS__); \
@@ -119,5 +150,6 @@ static void fixup_usb_nodes(void)
void qcom_of_fixup_nodes(void)
{
time_call(fixup_usb_nodes);
+ time_call(fixup_power_domains);
}
--
2.44.0
[PATCH v5 10/16] mach-snapdragon: fixup USB nodes
We don't support USB super-speed in U-Boot yet, we lack the SS PHY
drivers, however from my testing even with a PHY driver there seem to be
other issues when talking to super-speed peripherals.
In pursuit of maintaining upstream DT compatibility, and simplifying
porting for new devices, let's implement the DT fixups necessary to
configure USB in high-speed only mode at runtime. The pattern is
identical for all Qualcomm boards that use the Synaptics DWC3
controller:
* Add an additional property on the Qualcomm wrapper node
* Remove the super-speed phy phandle and phy-name entries.
Signed-off-by: Caleb Connolly
---
arch/arm/mach-snapdragon/Makefile| 1 +
arch/arm/mach-snapdragon/board.c | 3 +
arch/arm/mach-snapdragon/of_fixup.c | 123 +++
arch/arm/mach-snapdragon/qcom-priv.h | 20 ++
4 files changed, 147 insertions(+)
diff --git a/arch/arm/mach-snapdragon/Makefile
b/arch/arm/mach-snapdragon/Makefile
index 857171e593da..7a4495c8108f 100644
--- a/arch/arm/mach-snapdragon/Makefile
+++ b/arch/arm/mach-snapdragon/Makefile
@@ -2,4 +2,5 @@
#
# (C) Copyright 2015 Mateusz Kulikowski
obj-y += board.o
+obj-$(CONFIG_OF_LIVE) += of_fixup.o
diff --git a/arch/arm/mach-snapdragon/board.c b/arch/arm/mach-snapdragon/board.c
index 6f762fc948bf..65e4c61e866a 100644
--- a/arch/arm/mach-snapdragon/board.c
+++ b/arch/arm/mach-snapdragon/board.c
@@ -27,8 +27,10 @@
#include
#include
#include
+#include "qcom-priv.h"
+
DECLARE_GLOBAL_DATA_PTR;
static struct mm_region rbx_mem_map[CONFIG_NR_DRAM_BANKS + 2] = { { 0 } };
@@ -159,8 +161,9 @@ void __weak qcom_board_init(void)
int board_init(void)
{
show_psci_version();
+ qcom_of_fixup_nodes();
qcom_board_init();
return 0;
}
diff --git a/arch/arm/mach-snapdragon/of_fixup.c
b/arch/arm/mach-snapdragon/of_fixup.c
new file mode 100644
index ..4fdfed2dff16
--- /dev/null
+++ b/arch/arm/mach-snapdragon/of_fixup.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * OF_LIVE devicetree fixup.
+ *
+ * This file implements runtime fixups for Qualcomm DT to improve
+ * compatibility with U-Boot. This includes adjusting the USB nodes
+ * to only use USB high-speed, as well as remapping volume buttons
+ * to behave as up/down for navigating U-Boot.
+ *
+ * We use OF_LIVE for this rather than early FDT fixup for a couple
+ * of reasons: it has a much nicer API, is most likely more efficient,
+ * and our changes are only applied to U-Boot. This allows us to use a
+ * DT designed for Linux, run U-Boot with a modified version, and then
+ * boot Linux with the original FDT.
+ *
+ * Copyright (c) 2024 Linaro Ltd.
+ * Author: Caleb Connolly
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* U-Boot only supports USB high-speed mode on Qualcomm platforms with DWC3
+ * USB controllers. Rather than requiring source level DT changes, we fix up
+ * DT here. This improves compatibility with upstream DT and simplifies the
+ * porting process for new devices.
+ */
+static int fixup_qcom_dwc3(struct device_node *glue_np)
+{
+ struct device_node *dwc3;
+ int ret, len, hsphy_idx = 1;
+ const __be32 *phandles;
+ const char *second_phy_name;
+
+ debug("Fixing up %s\n", glue_np->name);
+
+ /* Tell the glue driver to configure the wrapper for high-speed only
operation */
+ ret = of_write_prop(glue_np, "qcom,select-utmi-as-pipe-clk", 0, NULL);
+ if (ret) {
+ log_err("Failed to add property 'qcom,select-utmi-as-pipe-clk':
%d\n", ret);
+ return ret;
+ }
+
+ /* Find the DWC3 node itself */
+ dwc3 = of_find_compatible_node(glue_np, NULL, "snps,dwc3");
+ if (!dwc3) {
+ log_err("Failed to find dwc3 node\n");
+ return -ENOENT;
+ }
+
+ phandles = of_get_property(dwc3, "phys", );
+ len /= sizeof(*phandles);
+ if (len == 1) {
+ log_debug("Only one phy, not a superspeed controller\n");
+ return 0;
+ }
+
+ /* Figure out if the superspeed phy is present and if so then which phy
is it? */
+ ret = of_property_read_string_index(dwc3, "phy-names", 1,
_phy_name);
+ if (ret == -ENODATA) {
+ log_debug("Only one phy, not a super-speed controller\n");
+ return 0;
+ } else if (ret) {
+ log_err("Failed to read second phy name: %d\n", ret);
+ return ret;
+ }
+
+ if (!strncmp("usb3-phy", second_phy_name, strlen("usb3-phy"))) {
+ log_debug("Second phy isn't superspeed (is '%s') assuming first
phy is SS\n",
+ second_phy_name);
+ hsphy_idx = 0;
+ }
+
+ /* Overwrite the "phys" property to only contain the high-speed phy */
+ ret = of_write_prop(dwc3, "phys", sizeof(*phandles), phandles +
hsphy_idx);
+ if (ret) {
+
[PATCH v5 08/16] gpio: msm_gpio: add .set_flags op
The .direction_input and .direction_output ops are deprecated, and don't
seem to behave properly for us. Implement our own .set_flags op to
handle this correctly.
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/gpio/msm_gpio.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpio/msm_gpio.c b/drivers/gpio/msm_gpio.c
index 5e57b0cbde75..f5d9ab54e817 100644
--- a/drivers/gpio/msm_gpio.c
+++ b/drivers/gpio/msm_gpio.c
@@ -34,21 +34,21 @@ struct msm_gpio_bank {
#define GPIO_IN_OUT_REG(dev, x) \
(GPIO_CONFIG_REG(dev, x) + 0x4)
-static int msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
+static void msm_gpio_direction_input(struct udevice *dev, unsigned int gpio)
{
struct msm_gpio_bank *priv = dev_get_priv(dev);
/* Always NOP for special pins, assume they're in the correct state */
if (qcom_is_special_pin(priv->pin_data, gpio))
- return 0;
+ return;
/* Disable OE bit */
clrsetbits_le32(priv->base + GPIO_CONFIG_REG(dev, gpio),
GPIO_OE_MASK, GPIO_OE_DISABLE);
- return 0;
+ return;
}
static int msm_gpio_set_value(struct udevice *dev, unsigned int gpio, int
value)
{
@@ -83,8 +83,25 @@ static int msm_gpio_direction_output(struct udevice *dev,
unsigned int gpio,
return 0;
}
+static int msm_gpio_set_flags(struct udevice *dev, unsigned int gpio, ulong
flags)
+{
+ if (flags & GPIOD_IS_OUT_ACTIVE) {
+ return msm_gpio_direction_output(dev, gpio, 1);
+ } else if (flags & GPIOD_IS_OUT) {
+ return msm_gpio_direction_output(dev, gpio, 0);
+ } else if (flags & GPIOD_IS_IN) {
+ msm_gpio_direction_input(dev, gpio);
+ if (flags & GPIOD_PULL_UP)
+ return msm_gpio_set_value(dev, gpio, 1);
+ else if (flags & GPIOD_PULL_DOWN)
+ return msm_gpio_set_value(dev, gpio, 0);
+ }
+
+ return 0;
+}
+
static int msm_gpio_get_value(struct udevice *dev, unsigned int gpio)
{
struct msm_gpio_bank *priv = dev_get_priv(dev);
@@ -109,12 +126,10 @@ static int msm_gpio_get_function(struct udevice *dev,
unsigned int gpio)
return GPIOF_INPUT;
}
static const struct dm_gpio_ops gpio_msm_ops = {
- .direction_input= msm_gpio_direction_input,
- .direction_output = msm_gpio_direction_output,
+ .set_flags = msm_gpio_set_flags,
.get_value = msm_gpio_get_value,
- .set_value = msm_gpio_set_value,
.get_function = msm_gpio_get_function,
};
static int msm_gpio_probe(struct udevice *dev)
--
2.44.0
[PATCH v5 09/16] serial: msm-geni: support livetree
When using OF_LIVE, the debug UART driver won't be probed if it's a
subnode of the geni-se-qup controller. Add a NOP driver for the
controller to correctly discover its child nodes.
Reviewed-by: Neil Armstrong
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/serial/serial_msm_geni.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/serial/serial_msm_geni.c b/drivers/serial/serial_msm_geni.c
index 4aa0bc8c72bc..5260474fb9a4 100644
--- a/drivers/serial/serial_msm_geni.c
+++ b/drivers/serial/serial_msm_geni.c
@@ -605,8 +605,21 @@ U_BOOT_DRIVER(serial_msm_geni) = {
.ops = _serial_ops,
.flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
};
+static const struct udevice_id geniqup_ids[] = {
+ { .compatible = "qcom,geni-se-qup" },
+ { }
+};
+
+U_BOOT_DRIVER(geni_se_qup) = {
+ .name = "geni-se-qup",
+ .id = UCLASS_NOP,
+ .of_match = geniqup_ids,
+ .bind = dm_scan_fdt_dev,
+ .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
+};
+
#ifdef CONFIG_DEBUG_UART_MSM_GENI
static struct msm_serial_data init_serial_data = {
.base = CONFIG_VAL(DEBUG_UART_BASE)
--
2.44.0
[PATCH v5 06/16] clk/qcom: sdm845: add gdscs
Define the GDSC power domains for SDM845.
Reviewed-by: Neil Armstrong
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sdm845.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index ccb0cf245d33..b7154360894a 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -145,13 +145,31 @@ static const struct qcom_reset_map sdm845_gcc_resets[] = {
[GCC_USB3_DP_PHY_SEC_BCR] = { 0x50014 },
[GCC_USB_PHY_CFG_AHB2PHY_BCR] = { 0x6a000 },
};
+static const struct qcom_power_map sdm845_gdscs[] = {
+ [PCIE_0_GDSC] = { 0x6b004 },
+ [PCIE_1_GDSC] = { 0x8d004 },
+ [UFS_CARD_GDSC] = { 0x75004 },
+ [UFS_PHY_GDSC] = { 0x77004 },
+ [USB30_PRIM_GDSC] = { 0xf004 },
+ [USB30_SEC_GDSC] = { 0x10004 },
+ [HLOS1_VOTE_AGGRE_NOC_MMU_AUDIO_TBU_GDSC] = { 0x7d030 },
+ [HLOS1_VOTE_AGGRE_NOC_MMU_PCIE_TBU_GDSC] = { 0x7d03c },
+ [HLOS1_VOTE_AGGRE_NOC_MMU_TBU1_GDSC] = { 0x7d034 },
+ [HLOS1_VOTE_AGGRE_NOC_MMU_TBU2_GDSC] = { 0x7d038 },
+ [HLOS1_VOTE_MMNOC_MMU_TBU_HF0_GDSC] = { 0x7d040 },
+ [HLOS1_VOTE_MMNOC_MMU_TBU_HF1_GDSC] = { 0x7d048 },
+ [HLOS1_VOTE_MMNOC_MMU_TBU_SF_GDSC] = { 0x7d044 },
+};
+
static struct msm_clk_data sdm845_clk_data = {
.resets = sdm845_gcc_resets,
.num_resets = ARRAY_SIZE(sdm845_gcc_resets),
.clks = sdm845_clks,
.num_clks = ARRAY_SIZE(sdm845_clks),
+ .power_domains = sdm845_gdscs,
+ .num_power_domains = ARRAY_SIZE(sdm845_gdscs),
.enable = sdm845_clk_enable,
.set_rate = sdm845_clk_set_rate,
};
--
2.44.0
[PATCH v5 07/16] clk/qcom: sdm845: add USB clocks
Most devices only initialise the USB clocks for us if we boot via
"fastboot boot", add the missing clock configuration to get both USB
ports working regardless of the bootloader state.
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-sdm845.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index b7154360894a..e9c61eb480de 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -20,8 +20,12 @@
#include "clock-qcom.h"
#define SE9_UART_APPS_CMD_RCGR 0x18148
+#define USB30_PRIM_MASTER_CLK_CMD_RCGR 0xf018
+#define USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR 0xf030
+#define USB3_PRIM_PHY_AUX_CMD_RCGR 0xf05c
+
static const struct freq_tbl ftbl_gcc_qupv3_wrap0_s0_clk_src[] = {
F(7372800, CFG_CLK_SRC_GPLL0_EVEN, 1, 384, 15625),
F(14745600, CFG_CLK_SRC_GPLL0_EVEN, 1, 768, 15625),
F(1920, CFG_CLK_SRC_CXO, 1, 0, 0),
@@ -56,8 +60,10 @@ static ulong sdm845_clk_set_rate(struct clk *clk, ulong rate)
}
}
static const struct gate_clk sdm845_clks[] = {
+ GATE_CLK(GCC_AGGRE_USB3_SEC_AXI_CLK,0x82020, 0x0001),
+ GATE_CLK(GCC_CFG_NOC_USB3_SEC_AXI_CLK, 0x05030, 0x0001),
GATE_CLK(GCC_QUPV3_WRAP0_S0_CLK,0x5200c, 0x0400),
GATE_CLK(GCC_QUPV3_WRAP0_S1_CLK,0x5200c, 0x0800),
GATE_CLK(GCC_QUPV3_WRAP0_S2_CLK,0x5200c, 0x1000),
GATE_CLK(GCC_QUPV3_WRAP0_S3_CLK,0x5200c, 0x2000),
@@ -120,8 +126,27 @@ static int sdm845_clk_enable(struct clk *clk)
struct msm_clk_priv *priv = dev_get_priv(clk->dev);
debug("%s: clk %s\n", __func__, sdm845_clks[clk->id].name);
+ switch (clk->id) {
+ case GCC_USB30_PRIM_MASTER_CLK:
+ qcom_gate_clk_en(priv, GCC_USB_PHY_CFG_AHB2PHY_CLK);
+ /* These numbers are just pulled from the frequency tables in
the Linux driver */
+ clk_rcg_set_rate_mnd(priv->base, USB30_PRIM_MASTER_CLK_CMD_RCGR,
+(4.5 * 2) - 1, 0, 0, 1 << 8, 8);
+ clk_rcg_set_rate_mnd(priv->base,
USB30_PRIM_MOCK_UTMI_CLK_CMD_RCGR,
+1, 0, 0, 0, 8);
+ clk_rcg_set_rate_mnd(priv->base, USB3_PRIM_PHY_AUX_CMD_RCGR,
+1, 0, 0, 0, 8);
+ break;
+ case GCC_USB30_SEC_MASTER_CLK:
+ qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_AUX_CLK);
+
+ qcom_gate_clk_en(priv, GCC_USB3_SEC_CLKREF_CLK);
+ qcom_gate_clk_en(priv, GCC_USB3_SEC_PHY_COM_AUX_CLK);
+ break;
+ }
+
qcom_gate_clk_en(priv, clk->id);
return 0;
}
--
2.44.0
[PATCH v5 05/16] clk/qcom: use offsets for RCG registers
The RCG registers always have the same offsets, so only store the base
CMD register address and calculate the others relative to that.
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-apq8016.c | 39 +
drivers/clk/qcom/clock-apq8096.c | 28 +
drivers/clk/qcom/clock-qcom.c| 22 +++
drivers/clk/qcom/clock-qcom.h| 16 +++--
drivers/clk/qcom/clock-qcs404.c | 122 +--
drivers/clk/qcom/clock-sdm845.c | 16 +
6 files changed, 39 insertions(+), 204 deletions(-)
diff --git a/drivers/clk/qcom/clock-apq8016.c b/drivers/clk/qcom/clock-apq8016.c
index e6647f7c41dd..5a5868169c89 100644
--- a/drivers/clk/qcom/clock-apq8016.c
+++ b/drivers/clk/qcom/clock-apq8016.c
@@ -22,13 +22,9 @@
#define APCS_GPLL_ENA_VOTE (0x45000)
#define APCS_CLOCK_BRANCH_ENA_VOTE (0x45004)
#define SDCC_BCR(n)((n * 0x1000) + 0x41000)
-#define SDCC_CMD_RCGR(n) ((n * 0x1000) + 0x41004)
-#define SDCC_CFG_RCGR(n) ((n * 0x1000) + 0x41008)
-#define SDCC_M(n) ((n * 0x1000) + 0x4100C)
-#define SDCC_N(n) ((n * 0x1000) + 0x41010)
-#define SDCC_D(n) ((n * 0x1000) + 0x41014)
+#define SDCC_CMD_RCGR(n) (((n + 1) * 0x1000) + 0x41004)
#define SDCC_APPS_CBCR(n) ((n * 0x1000) + 0x41018)
#define SDCC_AHB_CBCR(n) ((n * 0x1000) + 0x4101C)
/* BLSP1 AHB clock (root clock for BLSP) */
@@ -37,33 +33,12 @@
/* Uart clock control registers */
#define BLSP1_UART2_BCR(0x3028)
#define BLSP1_UART2_APPS_CBCR (0x302C)
#define BLSP1_UART2_APPS_CMD_RCGR (0x3034)
-#define BLSP1_UART2_APPS_CFG_RCGR (0x3038)
-#define BLSP1_UART2_APPS_M (0x303C)
-#define BLSP1_UART2_APPS_N (0x3040)
-#define BLSP1_UART2_APPS_D (0x3044)
/* GPLL0 clock control registers */
#define GPLL0_STATUS_ACTIVE BIT(17)
-static const struct bcr_regs sdc_regs[] = {
- {
- .cfg_rcgr = SDCC_CFG_RCGR(1),
- .cmd_rcgr = SDCC_CMD_RCGR(1),
- .M = SDCC_M(1),
- .N = SDCC_N(1),
- .D = SDCC_D(1),
- },
- {
- .cfg_rcgr = SDCC_CFG_RCGR(2),
- .cmd_rcgr = SDCC_CMD_RCGR(2),
- .M = SDCC_M(2),
- .N = SDCC_N(2),
- .D = SDCC_D(2),
- }
-};
-
static struct pll_vote_clk gpll0_vote_clk = {
.status = GPLL0_STATUS,
.status_bit = GPLL0_STATUS_ACTIVE,
.ena_vote = APCS_GPLL_ENA_VOTE,
@@ -85,32 +60,24 @@ static int clk_init_sdc(struct msm_clk_priv *priv, int
slot, uint rate)
div = 4;
clk_enable_cbc(priv->base + SDCC_AHB_CBCR(slot));
/* 800Mhz/div, gpll0 */
- clk_rcg_set_rate_mnd(priv->base, _regs[slot], div, 0, 0,
+ clk_rcg_set_rate_mnd(priv->base, SDCC_CMD_RCGR(slot), div, 0, 0,
CFG_CLK_SRC_GPLL0, 8);
clk_enable_gpll0(priv->base, _vote_clk);
clk_enable_cbc(priv->base + SDCC_APPS_CBCR(slot));
return rate;
}
-static const struct bcr_regs uart2_regs = {
- .cfg_rcgr = BLSP1_UART2_APPS_CFG_RCGR,
- .cmd_rcgr = BLSP1_UART2_APPS_CMD_RCGR,
- .M = BLSP1_UART2_APPS_M,
- .N = BLSP1_UART2_APPS_N,
- .D = BLSP1_UART2_APPS_D,
-};
-
/* UART: 115200 */
int apq8016_clk_init_uart(phys_addr_t base)
{
/* Enable AHB clock */
clk_enable_vote_clk(base, _blsp1_ahb_clk);
/* 7372800 uart block clock @ GPLL0 */
- clk_rcg_set_rate_mnd(base, _regs, 1, 144, 15625,
+ clk_rcg_set_rate_mnd(base, BLSP1_UART2_APPS_CMD_RCGR, 1, 144, 15625,
CFG_CLK_SRC_GPLL0, 16);
/* Vote for gpll0 clock */
clk_enable_gpll0(base, _vote_clk);
diff --git a/drivers/clk/qcom/clock-apq8096.c b/drivers/clk/qcom/clock-apq8096.c
index a4731613c5e0..479f9771a464 100644
--- a/drivers/clk/qcom/clock-apq8096.c
+++ b/drivers/clk/qcom/clock-apq8096.c
@@ -25,33 +25,17 @@
#define SDCC2_BCR (0x14000) /* block reset */
#define SDCC2_APPS_CBCR(0x14004) /* branch control */
#define SDCC2_AHB_CBCR (0x14008)
#define SDCC2_CMD_RCGR (0x14010)
-#define SDCC2_CFG_RCGR (0x14014)
-#define SDCC2_M(0x14018)
-#define SDCC2_N(0x1401C)
-#define SDCC2_D(0x14020)
#define BLSP2_AHB_CBCR (0x25004)
#define BLSP2_UART2_APPS_CBCR (0x29004)
#define BLSP2_UART2_APPS_CMD_RCGR (0x2900C)
-#define BLSP2_UART2_APPS_CFG_RCGR (0x29010)
-#define BLSP2_UART2_APPS_M (0x29014)
-#define BLSP2_UART2_APPS_N (0x29018)
-#define BLSP2_UART2_APPS_D (0x2901C)
/* GPLL0 clock control registers */
#define GPLL0_STATUS_ACTIVEBIT(30)
#define APCS_GPLL_ENA_VOTE_GPLL0 BIT(0)
-static
[PATCH v5 04/16] mach-snapdragon: disable power-domains for pre-reloc drivers
Some devices like the UART and clock controller reference an RPM(h)
power domain. We don't support this device in U-Boot, so add
DM_FLAG_DEFAULT_PD_CTRL_OFF to tell DM core not to try and enable the
power domain.
Reviewed-by: Sumit Garg
Signed-off-by: Caleb Connolly
---
drivers/clk/qcom/clock-qcom.c| 2 ++
drivers/clk/qcom/clock-sdm845.c | 2 +-
drivers/serial/serial_msm_geni.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/clock-qcom.c b/drivers/clk/qcom/clock-qcom.c
index 7a5938a06a34..6303dcbf8461 100644
--- a/drivers/clk/qcom/clock-qcom.c
+++ b/drivers/clk/qcom/clock-qcom.c
@@ -226,8 +226,9 @@ U_BOOT_DRIVER(qcom_clk) = {
.id = UCLASS_CLK,
.ops= _clk_ops,
.priv_auto = sizeof(struct msm_clk_priv),
.probe = msm_clk_probe,
+ .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
};
int qcom_cc_bind(struct udevice *parent)
{
@@ -410,5 +411,6 @@ U_BOOT_DRIVER(qcom_power) = {
.name = "qcom_power",
.id = UCLASS_POWER_DOMAIN,
.ops = _power_ops,
.probe = qcom_power_probe,
+ .flags = DM_FLAG_PRE_RELOC,
};
diff --git a/drivers/clk/qcom/clock-sdm845.c b/drivers/clk/qcom/clock-sdm845.c
index 36ffee79d966..babd83119e2c 100644
--- a/drivers/clk/qcom/clock-sdm845.c
+++ b/drivers/clk/qcom/clock-sdm845.c
@@ -182,6 +182,6 @@ U_BOOT_DRIVER(gcc_sdm845) = {
.name = "gcc_sdm845",
.id = UCLASS_NOP,
.of_match = gcc_sdm845_of_match,
.bind = qcom_cc_bind,
- .flags = DM_FLAG_PRE_RELOC,
+ .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
};
diff --git a/drivers/serial/serial_msm_geni.c b/drivers/serial/serial_msm_geni.c
index e5c3dcffc1c6..4aa0bc8c72bc 100644
--- a/drivers/serial/serial_msm_geni.c
+++ b/drivers/serial/serial_msm_geni.c
@@ -602,9 +602,9 @@ U_BOOT_DRIVER(serial_msm_geni) = {
.of_to_plat = msm_serial_ofdata_to_platdata,
.priv_auto = sizeof(struct msm_serial_data),
.probe = msm_serial_probe,
.ops = _serial_ops,
- .flags = DM_FLAG_PRE_RELOC,
+ .flags = DM_FLAG_PRE_RELOC | DM_FLAG_DEFAULT_PD_CTRL_OFF,
};
#ifdef CONFIG_DEBUG_UART_MSM_GENI
--
2.44.0
[PATCH v5 03/16] phy: qcom: Add SNPS femto v2 USB HS phy
From: Bhupesh Sharma
Some Qualcomm SoCs newer than SDM845 feature a so-called "7nm phy"
driver, notable the SM8250 SoC which will gain U-Boot support in
upcoming patches.
Introduce a driver based on the Linux driver.
Signed-off-by: Bhupesh Sharma
[code cleanup, align symbol names with Linux, switch to clk/reset_bulk APIs]
Signed-off-by: Caleb Connolly
---
drivers/phy/qcom/Kconfig | 8 ++
drivers/phy/qcom/Makefile | 1 +
drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 207 ++
3 files changed, 216 insertions(+)
diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
index 361dfb6e1126..b9fe608c2798 100644
--- a/drivers/phy/qcom/Kconfig
+++ b/drivers/phy/qcom/Kconfig
@@ -18,8 +18,16 @@ config PHY_QCOM_QUSB2
help
Enable this to support the Super-Speed USB transceiver on various
Qualcomm chipsets.
+config PHY_QCOM_USB_SNPS_FEMTO_V2
+ tristate "Qualcomm SNPS FEMTO USB HS PHY v2"
+ depends on PHY && ARCH_SNAPDRAGON
+ help
+ Enable this to support the Qualcomm Synopsys DesignWare Core 7nm
+ High-Speed PHY driver. This driver supports the Hi-Speed PHY which
+ is usually paired with Synopsys DWC3 USB IPs on MSM SOCs.
+
config PHY_QCOM_USB_HS_28NM
tristate "Qualcomm 28nm High-Speed PHY"
depends on PHY && ARCH_SNAPDRAGON
help
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
index f6af985666a4..5f4db4a53788 100644
--- a/drivers/phy/qcom/Makefile
+++ b/drivers/phy/qcom/Makefile
@@ -1,5 +1,6 @@
obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
+obj-$(CONFIG_PHY_QCOM_USB_SNPS_FEMTO_V2) += phy-qcom-snps-femto-v2.o
obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
diff --git a/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
new file mode 100644
index ..58eb01972402
--- /dev/null
+++ b/drivers/phy/qcom/phy-qcom-snps-femto-v2.c
@@ -0,0 +1,207 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ * Copyright (C) 2023 Bhupesh Sharma
+ *
+ * Based on Linux driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL0 (0x3c)
+#define SLEEPM BIT(0)
+#define OPMODE_MASK GENMASK(4, 3)
+#define OPMODE_NORMAL (0x00)
+#define OPMODE_NONDRIVING BIT(3)
+#define TERMSEL BIT(5)
+
+#define USB2_PHY_USB_PHY_UTMI_CTRL5 (0x50)
+#define POR BIT(1)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 (0x54)
+#define SIDDQ BIT(2)
+#define RETENABLEN BIT(3)
+#define FSEL_MASK GENMASK(6, 4)
+#define FSEL_DEFAULT (0x3 << 4)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1 (0x58)
+#define VBUSVLDEXTSEL0 BIT(4)
+#define PLLBTUNE BIT(5)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2 (0x5c)
+#define VREGBYPASS BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL1 (0x60)
+#define VBUSVLDEXT0 BIT(0)
+
+#define USB2_PHY_USB_PHY_HS_PHY_CTRL2 (0x64)
+#define USB2_AUTO_RESUME BIT(0)
+#define USB2_SUSPEND_N BIT(2)
+#define USB2_SUSPEND_N_SEL BIT(3)
+
+#define USB2_PHY_USB_PHY_CFG0 (0x94)
+#define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
+#define UTMI_PHY_CMN_CTRL_OVERRIDE_EN BIT(1)
+
+#define USB2_PHY_USB_PHY_REFCLK_CTRL (0xa0)
+#define REFCLK_SEL_MASK GENMASK(1, 0)
+#define REFCLK_SEL_DEFAULT (0x2 << 0)
+
+struct qcom_snps_hsphy {
+ void __iomem *base;
+ struct clk_bulk clks;
+ struct reset_ctl_bulk resets;
+};
+
+static inline void qcom_snps_hsphy_write_mask(void __iomem *base, u32 offset,
+ u32 mask, u32 val)
+{
+ u32 reg;
+
+ reg = readl_relaxed(base + offset);
+
+ reg &= ~mask;
+ reg |= val & mask;
+ writel_relaxed(reg, base + offset);
+
+ /* Ensure above write is completed */
+ readl_relaxed(base + offset);
+}
+
+static int qcom_snps_hsphy_usb_init(struct phy *phy)
+{
+ struct qcom_snps_hsphy *priv = dev_get_priv(phy->dev);
+
+ qcom_snps_hsphy_write_mask(priv->base, USB2_PHY_USB_PHY_CFG0,
+ UTMI_PHY_CMN_CTRL_OVERRIDE_EN,
+ UTMI_PHY_CMN_CTRL_OVERRIDE_EN);
+ qcom_snps_hsphy_write_mask(priv->base, USB2_PHY_USB_PHY_UTMI_CTRL5, POR,
+ POR);
+ qcom_snps_hsphy_write_mask(priv->base,
+ USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0,
FSEL_MASK, 0);
+ qcom_snps_hsphy_write_mask(priv->base,
+ USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON1,
+ PLLBTUNE, PLLBTUNE);
+ qcom_snps_hsphy_write_mask(priv->base, USB2_PHY_USB_PHY_REFCLK_CTRL,
+
[PATCH v5 02/16] phy: qcom: add Qualcomm QUSB2 USB PHY driver
From: Bhupesh Sharma
The Snapdragon 845 and several other Qualcomm SoCs feature this
USB high-speed phy. Add a driver for it based on the Linux driver, with
support for the SDM845, and the QCM2290 and SM6115 SoCs which will gain
support in U-Boot in future patches.
Signed-off-by: Bhupesh Sharma
[code cleanup, switch to clk_bulk]
Signed-off-by: Caleb Connolly
---
drivers/phy/qcom/Kconfig | 7 +
drivers/phy/qcom/Makefile | 1 +
drivers/phy/qcom/phy-qcom-qusb2.c | 429 ++
3 files changed, 437 insertions(+)
diff --git a/drivers/phy/qcom/Kconfig b/drivers/phy/qcom/Kconfig
index f4ca174805a4..361dfb6e1126 100644
--- a/drivers/phy/qcom/Kconfig
+++ b/drivers/phy/qcom/Kconfig
@@ -11,8 +11,15 @@ config PHY_QCOM_IPQ4019_USB
depends on PHY && ARCH_IPQ40XX
help
Support for the USB PHY-s on Qualcomm IPQ40xx SoC-s.
+config PHY_QCOM_QUSB2
+ tristate "Qualcomm USB QUSB2 PHY driver"
+ depends on PHY && ARCH_SNAPDRAGON
+ help
+ Enable this to support the Super-Speed USB transceiver on various
+ Qualcomm chipsets.
+
config PHY_QCOM_USB_HS_28NM
tristate "Qualcomm 28nm High-Speed PHY"
depends on PHY && ARCH_SNAPDRAGON
help
diff --git a/drivers/phy/qcom/Makefile b/drivers/phy/qcom/Makefile
index 2113f178c0c7..f6af985666a4 100644
--- a/drivers/phy/qcom/Makefile
+++ b/drivers/phy/qcom/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_PHY_QCOM_IPQ4019_USB) += phy-qcom-ipq4019-usb.o
obj-$(CONFIG_MSM8916_USB_PHY) += msm8916-usbh-phy.o
+obj-$(CONFIG_PHY_QCOM_QUSB2) += phy-qcom-qusb2.o
obj-$(CONFIG_PHY_QCOM_USB_HS_28NM) += phy-qcom-usb-hs-28nm.o
obj-$(CONFIG_PHY_QCOM_USB_SS) += phy-qcom-usb-ss.o
diff --git a/drivers/phy/qcom/phy-qcom-qusb2.c
b/drivers/phy/qcom/phy-qcom-qusb2.c
new file mode 100644
index ..c91ba18c4ab1
--- /dev/null
+++ b/drivers/phy/qcom/phy-qcom-qusb2.c
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Bhupesh Sharma
+ *
+ * Based on Linux driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define QUSB2PHY_PLL 0x0
+#define QUSB2PHY_PLL_TEST 0x04
+#define CLK_REF_SEL BIT(7)
+
+#define QUSB2PHY_PLL_TUNE 0x08
+#define QUSB2PHY_PLL_USER_CTL1 0x0c
+#define QUSB2PHY_PLL_USER_CTL2 0x10
+#define QUSB2PHY_PLL_AUTOPGM_CTL1 0x1c
+#define QUSB2PHY_PLL_PWR_CTRL 0x18
+
+/* QUSB2PHY_PLL_STATUS register bits */
+#define PLL_LOCKED BIT(5)
+
+/* QUSB2PHY_PLL_COMMON_STATUS_ONE register bits */
+#define CORE_READY_STATUS BIT(0)
+
+/* QUSB2PHY_PORT_POWERDOWN register bits */
+#define CLAMP_N_EN BIT(5)
+#define FREEZIO_N BIT(1)
+#define POWER_DOWN BIT(0)
+
+/* QUSB2PHY_PWR_CTRL1 register bits */
+#define PWR_CTRL1_VREF_SUPPLY_TRIM BIT(5)
+#define PWR_CTRL1_CLAMP_N_EN BIT(1)
+
+#define QUSB2PHY_REFCLK_ENABLE BIT(0)
+
+#define PHY_CLK_SCHEME_SEL BIT(0)
+
+/* QUSB2PHY_INTR_CTRL register bits */
+#define DMSE_INTR_HIGH_SEL BIT(4)
+#define DPSE_INTR_HIGH_SEL BIT(3)
+#define CHG_DET_INTR_EN BIT(2)
+#define DMSE_INTR_EN BIT(1)
+#define DPSE_INTR_EN BIT(0)
+
+/* QUSB2PHY_PLL_CORE_INPUT_OVERRIDE register bits */
+#define CORE_PLL_EN_FROM_RESET BIT(4)
+#define CORE_RESET BIT(5)
+#define CORE_RESET_MUX BIT(6)
+
+/* QUSB2PHY_IMP_CTRL1 register bits */
+#define IMP_RES_OFFSET_MASK GENMASK(5, 0)
+#define IMP_RES_OFFSET_SHIFT 0x0
+
+/* QUSB2PHY_PLL_BIAS_CONTROL_2 register bits */
+#define BIAS_CTRL2_RES_OFFSET_MASK GENMASK(5, 0)
+#define BIAS_CTRL2_RES_OFFSET_SHIFT 0x0
+
+/* QUSB2PHY_CHG_CONTROL_2 register bits */
+#define CHG_CTRL2_OFFSET_MASK GENMASK(5, 4)
+#define CHG_CTRL2_OFFSET_SHIFT 0x4
+
+/* QUSB2PHY_PORT_TUNE1 register bits */
+#define HSTX_TRIM_MASK GENMASK(7, 4)
+#define HSTX_TRIM_SHIFT 0x4
+#define PREEMPH_WIDTH_HALF_BIT BIT(2)
+#define PREEMPHASIS_EN_MASK GENMASK(1, 0)
+#define PREEMPHASIS_EN_SHIFT 0x0
+
+/* QUSB2PHY_PORT_TUNE2 register bits */
+#define HSDISC_TRIM_MASK GENMASK(1, 0)
+#define HSDISC_TRIM_SHIFT 0x0
+
+#define QUSB2PHY_PLL_ANALOG_CONTROLS_TWO 0x04
+#define QUSB2PHY_PLL_CLOCK_INVERTERS 0x18c
+#define QUSB2PHY_PLL_CMODE 0x2c
+#define QUSB2PHY_PLL_LOCK_DELAY 0x184
+#define QUSB2PHY_PLL_DIGITAL_TIMERS_TWO 0xb4
+#define QUSB2PHY_PLL_BIAS_CONTROL_1 0x194
+#define QUSB2PHY_PLL_BIAS_CONTROL_2 0x198
+#define QUSB2PHY_PWR_CTRL2 0x214
+#define QUSB2PHY_IMP_CTRL1 0x220
+#define QUSB2PHY_IMP_CTRL2 0x224
+#define QUSB2PHY_CHG_CTRL2 0x23c
+
+struct qusb2_phy_init_tbl {
+ unsigned int offset;
+ unsigned int val;
+ /*
+* register part of layout ?
+* if yes, then offset gives index in the reg-layout
+*/
+ int in_layout;
+};
+
+struct qusb2_phy_cfg {
+ const struct qusb2_phy_init_tbl *tbl;
+ /* number of entries in the table */
+ unsigned int tbl_num;
+ /* offset to PHY_CLK_SCHEME register in TCSR map */
+ unsigned int clk_scheme_offset;
+
+ /* array of registers with different offsets */
+ const unsigned int
[PATCH v5 01/16] mailmap: update Bhupesh's email address
Update Bhupesh's email to his new one. Reviewed-by: Neil Armstrong Signed-off-by: Caleb Connolly --- Cc: Bhupesh Sharma --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index d1f08f3eca8a..f6e0847b2168 100644 --- a/.mailmap +++ b/.mailmap @@ -29,8 +29,9 @@ Ashok Reddy Soma Atish Patra Bharat Kumar Gogada Bharat Kumar Gogada Bhargava Sreekantappa Gayathri +Bhupesh Sharma Bin Meng Boris Brezillon Boris Brezillon Christian Kohn -- 2.44.0
[PATCH v5 00/16] Qualcomm platform USB support
This series enables USB on Qualcomm SDM845 platforms and lays the
foundation for future SoCs as well.
It introduces two new high-speed PHY drivers, one for SDM845 and one for
an upcoming platform. The SDM845 clock driver gains support for
configuring the USB clocks, and the GPIO driver is updated to use .set_flags
which fixes a strange bug where GPIOs would also be configured as input.
Support for super-speed USB modes is not currently available, however
configuring the device to be high-speed only requires modifications to
DT.
To improve compatibility with upstream DT, we switch Qualcomm platforms
over to OF_LIVE and apply fixups to the tree to remove references to the
super-speed phy, as well as configure the Qualcomm glue for high-speed
only mode.
The db845c requires a vbus-supply to be hooked up for its usb type-A
port. A U-Boot dtsi file is added to configure this.
With these patches, it is now also possible to run U-Boot on some SDM845
phones like the OnePlus 6 using a dtb from Linux, and access the U-Boot
shell via the CDC ACM USB serial gadget.
This series depends on the ("Qualcomm DWC3 USB support") series [1], as
well as Volodymyrs patches enabling power domain support [2].
A feature branch based on qcom-next with the necessary dependencies
for testing the Dragonboard845c can be found at [3].
[1]:
https://lore.kernel.org/u-boot/20240320-b4-qcom-usb-v4-0-41be48017...@linaro.org
[2]:
https://lore.kernel.org/u-boot/20240311213334.3567389-1-volodymyr_babc...@epam.com
[3]: https://git.codelinaro.org/linaro/qcomlt/u-boot/-/tree/b4/qcom-livetree
---
Changes in v5:
- Call regulators_enable_boot_on() during board_init() and don't use
the vbus-supply property anymore. This is slightly more aligned with
upstream.
- Minor checkpatch fixes
- Link to v4:
https://lore.kernel.org/r/20240320-b4-qcom-livetree-v4-0-d867ab1f0...@linaro.org
Changes in v4:
- Fix defconfig.
- Mark db845c vbus regulator always-on to fix a bug in Linux.
- Add a timer in qcom_of_fixup_nodes() so the boot time impact can
be easily measured.
- Drop unused macros from femto v2 phy, general cleanup, remove custom
set/clrbits impl.
- Rename "7nm" phy driver to "femto-v2" to match Linux, also fix
copyright.
- Use set/clrbits() in qusb2 phy driver.
- Link to v3:
https://lore.kernel.org/r/20240319-b4-qcom-livetree-v3-0-e1b38d9b4...@linaro.org
Changes in v3:
- Add back missing gadget options to qcom_defconfig (thanks Neil)
- Link to v2:
https://lore.kernel.org/r/20240315-b4-qcom-livetree-v2-0-ab635774b...@linaro.org
Changes in v2:
- Fix incorrect order of NULL/0 parameters to of_write_prob() in
fixup_qcom_dwc3()
- Move fixup_usb_nodes() to a separate file in preparation for future
additions.
- Add missing break to switch case in sdm845_clk_enable()
- Remove rogue return statement in msm_gpio_set_flags()
- Rebase on Volodymyrs power domain patches.
- Link to v1:
https://lore.kernel.org/r/20240131-b4-qcom-livetree-v1-0-4071c0787...@linaro.org
---
Bhupesh Sharma (2):
phy: qcom: add Qualcomm QUSB2 USB PHY driver
phy: qcom: Add SNPS femto v2 USB HS phy
Caleb Connolly (14):
mailmap: update Bhupesh's email address
mach-snapdragon: disable power-domains for pre-reloc drivers
clk/qcom: use offsets for RCG registers
clk/qcom: sdm845: add gdscs
clk/qcom: sdm845: add USB clocks
gpio: msm_gpio: add .set_flags op
serial: msm-geni: support livetree
mach-snapdragon: fixup USB nodes
mach-snapdragon: fixup power-domains
mach-snapdragon: call regulators_enable_boot_on()
dts: sdm845-db845c: add u-boot fixups
qcom_defconfig: enable livetree
qcom_defconfig: enable USB
usb: gadget: UMS: fix 64-bit division on ARM32
.mailmap | 1 +
arch/arm/dts/sdm845-db845c-u-boot.dtsi| 9 +
arch/arm/mach-snapdragon/Makefile | 1 +
arch/arm/mach-snapdragon/board.c | 5 +
arch/arm/mach-snapdragon/of_fixup.c | 155 +++
arch/arm/mach-snapdragon/qcom-priv.h | 20 ++
configs/qcom_defconfig| 53 ++--
drivers/clk/qcom/clock-apq8016.c | 39 +--
drivers/clk/qcom/clock-apq8096.c | 28 +-
drivers/clk/qcom/clock-qcom.c | 24 +-
drivers/clk/qcom/clock-qcom.h | 16 +-
drivers/clk/qcom/clock-qcs404.c | 122 ++---
drivers/clk/qcom/clock-sdm845.c | 61 +++--
drivers/gpio/msm_gpio.c | 27 +-
drivers/phy/qcom/Kconfig | 15 ++
drivers/phy/qcom/Makefile | 2 +
drivers/phy/qcom/phy-qcom-qusb2.c | 429 ++
drivers/phy/qcom/phy-qcom-snps-femto-v2.c | 207 ++
drivers/serial/serial_msm_geni.c | 15 +-
drivers/usb/gadget/f_mass_storage.c | 13 +-
20 files changed, 1001 insertions(+), 241 deletions(-)
---
base-commit: 0d08018d01afaddcee8dd1f1929a48577684110c
// Caleb (they/them)
[PATCH v2] tpm-v2: allow algoirthm name to be configured for pcr_read and pcr_extend
For pcr_read and pcr_extend commands allow the digest algorithm to be
specified by an additional argument. If not specified it will default to
SHA256 for backwards compatibility.
A follow-on to this could be to extend all PCR banks with the detected
algo when the argument is 'auto'.
Signed-off-by: Tim Harvey
---
v2:
- use tpm2_algorithm_to_len
- use enum tpm2_algorithms
- make function names and parameter names more consistent with existing
tpm-v2 functions
- fix various spelling errors
---
cmd/tpm-v2.c | 49 ++--
include/tpm-v2.h | 18 ++
lib/tpm-v2.c | 34 +
3 files changed, 87 insertions(+), 14 deletions(-)
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 7e479b9dfe36..2343b4d9cb9e 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -99,11 +99,19 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
struct tpm_chip_priv *priv;
u32 index = simple_strtoul(argv[1], NULL, 0);
void *digest = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
+ int algo = TPM2_ALG_SHA256;
+ int algo_len;
int ret;
u32 rc;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -116,8 +124,12 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
if (index >= priv->pcr_count)
return -EINVAL;
- rc = tpm2_pcr_extend(dev, index, TPM2_ALG_SHA256, digest,
-TPM2_DIGEST_LEN);
+ rc = tpm2_pcr_extend(dev, index, algo, digest, algo_len);
+ if (!rc) {
+ printf("PCR #%u extended with %d byte %s digest\n", index,
+ algo_len, tpm2_algorithm_name(algo));
+ print_byte_string(digest, algo_len);
+ }
unmap_sysmem(digest);
@@ -127,15 +139,23 @@ static int do_tpm2_pcr_extend(struct cmd_tbl *cmdtp, int
flag, int argc,
static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
{
+ enum tpm2_algorithms algo = TPM2_ALG_SHA256;
struct udevice *dev;
struct tpm_chip_priv *priv;
u32 index, rc;
+ int algo_len;
unsigned int updates;
void *data;
int ret;
- if (argc != 3)
+ if (argc < 3 || argc > 4)
return CMD_RET_USAGE;
+ if (argc == 4) {
+ algo = tpm2_name_to_algorithm(argv[3]);
+ if (algo < 0)
+ return CMD_RET_FAILURE;
+ }
+ algo_len = tpm2_algorithm_to_len(algo);
ret = get_tpm();
if (ret)
@@ -151,11 +171,12 @@ static int do_tpm_pcr_read(struct cmd_tbl *cmdtp, int
flag, int argc,
data = map_sysmem(simple_strtoul(argv[2], NULL, 0), 0);
- rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, TPM2_ALG_SHA256,
- data, TPM2_DIGEST_LEN, );
+ rc = tpm2_pcr_read(dev, index, priv->pcr_select_min, algo,
+ data, algo_len, );
if (!rc) {
- printf("PCR #%u content (%u known updates):\n", index, updates);
- print_byte_string(data, TPM2_DIGEST_LEN);
+ printf("PCR #%u %s %d byte content (%u known updates):\n",
index,
+ tpm2_algorithm_name(algo), algo_len, updates);
+ print_byte_string(data, algo_len);
}
unmap_sysmem(data);
@@ -415,14 +436,14 @@ U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a
TPMv2.x command",
" is one of:\n"
"* TPM2_RH_LOCKOUT\n"
"* TPM2_RH_PLATFORM\n"
-"pcr_extend \n"
-"Extend PCR # with digest at .\n"
+"pcr_extend []\n"
+"Extend PCR # with digest at with digest_algo.\n"
": index of the PCR\n"
-": address of a 32-byte SHA256 digest\n"
-"pcr_read \n"
-"Read PCR # to memory address .\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
+"pcr_read []\n"
+"Read PCR # to memory address with .\n"
": index of the PCR\n"
-": address to store the a 32-byte SHA256 digest\n"
+": address of digest of digest_algo type (defaults to
SHA256)\n"
"get_capability\n"
"Read and display entries indexed by /.\n"
"Values are 4 bytes long and are written at .\n"
diff --git a/include/tpm-v2.h b/include/tpm-v2.h
index 33dd103767c4..933882fcbf97 100644
--- a/include/tpm-v2.h
+++ b/include/tpm-v2.h
@@ -965,4 +965,22 @@ u32 tpm2_enable_nvcommits(struct udevice *dev, uint
vendor_cmd,
*/
u32 tpm2_auto_start(struct udevice *dev);
+/**
+ * tpm2_name_to_algorithm() - Return an algorithm id given a supported
+ *
Re: [PATCH 2/6] arm: xea: Add support for reading SoM (CPU) and base board HW revision
Hi Lukasz, On Thu, Mar 28, 2024 at 12:34 PM Lukasz Majewski wrote: > +static inline u8 get_som_rev(void) There is no need for 'inline' here. Also, get_som_rev() is only used 5/6, so I suggest to squash this patch with 5/6. Besides that, the series looks good.
Re: [PATCH] tpm-v2: allow algo name to be conigured for pcr_read and pcr_extend
On Thu, 28 Mar 2024 at 17:33, Tim Harvey wrote:
>
> On Thu, Mar 28, 2024 at 12:37 AM Ilias Apalodimas
> wrote:
> >
> > Hi Tim,
> >
> > [...]
> >
> > >
> > > +/**
> > > + * tpm2_algo_len() - Return an algo value and length given a algorithm
> > > name
> > > + *
> > > + * @name: algorithm name
> > > + * @rwlen: pointer to integer to populate with algorithm length if
> > > non-null
> > > + * Return: algorithm value
> > > + */
> > > +int tpm2_algo_len(const char *name, int *rwlen);
> > > +
> > > +/**
> > > + * tpm2_algo_len() - Return an algoithm name string
> > > + *
> > > + * @algo: algorithm value
> > > + * Return: algorithm string
> > > + */
> > > +const char *tpm2_algo_name(int algo);
> > > +
> > > #endif /* __TPM_V2_H */
> > > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > > index 68eaaa639f89..6a090ce5810c 100644
> > > --- a/lib/tpm-v2.c
> > > +++ b/lib/tpm-v2.c
> > > @@ -1555,3 +1555,49 @@ u32 tpm2_enable_nvcommits(struct udevice *dev,
> > > uint vendor_cmd,
> > >
> > > return 0;
> > > }
> > > +
> > > +int tpm2_algo_len(const char *name, int *rwlen)
> > > +{
> > > + int algo = -EINVAL;
> > > + int len = 0;
> > > +
> > > + if (!strcasecmp("sha1", name)) {
> > > + algo = TPM2_ALG_SHA1;
> > > + len = TPM2_SHA1_DIGEST_SIZE;
> > > + } else if (!strcasecmp("sha256", name)) {
> > > + algo = TPM2_ALG_SHA256;
> > > + len = TPM2_SHA256_DIGEST_SIZE;
> > > + } else if (!strcasecmp("sha384", name)) {
> > > + algo = TPM2_ALG_SHA384;
> > > + len = TPM2_SHA384_DIGEST_SIZE;
> > > + } else if (!strcasecmp("sha512", name)) {
> > > + algo = TPM2_ALG_SHA512;
> > > + len = TPM2_SHA512_DIGEST_SIZE;
> > > + } else if (!strcasecmp("sm3_256", name)) {
> > > + algo = TPM2_ALG_SM3_256;
> > > + len = TPM2_SM3_256_DIGEST_SIZE;
> > > + }
> > > +
> > > + if (*rwlen)
> > > + *rwlen = len;
> > > +
> > > + return algo;
> > > +}
> > > +
> >
> > We already have tpm2_algorithm_to_len(). Instead of defining a new
> > function, can we convert strings to 'enum tpm2_algorithms'? We can
> > then reuse the existing function.
> >
>
> Hi Ilias,
>
> Thanks - I didn't see tpm2_algorithm_to_len. Yes, I can use it but I
> still need to add a new function to turn the name into an algo.
Yep, that's fine,
> I also
> didn't see tpm2_supported_algorithms; should I only support
> name-to-algorithm and algorithm-to-name for that subset?
>
Yea, that would be good, we can at least have a reference of what we
currently support.
Cheers
/Ilias
> Best Regards,
>
> Tim
>
> > > +const char *tpm2_algo_name(int algo)
> > > +{
> > > + switch (algo) {
> > > + case TPM2_ALG_SHA1:
> > > + return "sha1";
> > > + case TPM2_ALG_SHA256:
> > > + return "sha256";
> > > + case TPM2_ALG_SHA384:
> > > + return "sha384";
> > > + case TPM2_ALG_SHA512:
> > > + return "sha512";
> > > + case TPM2_ALG_SM3_256:
> > > + return "sm3_256";
> > > + }
> > > +
> > > + return "";
> > > +}
> > > --
> > > 2.25.1
> > >
> >
> > Thanks
> > /Ilias
Re: [PATCH v2 4/6] board: starfive: support Milk-V Mars board
On 24.03.24 16:00, Aurelien Jarno wrote: On 2024-03-21 19:11, Heinrich Schuchardt wrote: The differences between the Milk-V Mars board and the VisionFive 2 board are small enough that we can support both using the same U-Boot build. * The model and compatible property are taken from proposed Linux patches. * The EEPROM is atmel,24c02 according to the vendor U-Boot. * The second Ethernet port is not available. From the device tree that have been submitted to the kernel [1] it seems another difference is that there is a CD gpio for mmc1. Thank you for reviewing. On all of Milk-V Mars, VisionFive 2 1.2B, and 1.3A I see GPIO 41 level changing when removing or inserting an SD card using U-Boot command 'gpio status -a'. So this seems not to be Milk-V specific. Could you, please, check. From the schematics, it also seems that the usb0 port is not in peripheral mode, but in host mode. That said on the submitted kernel device tree it seems simply disabled. All three blue-colored USB 3.0 ports are able to read an SD-card in U-Boot. The black port provides 5V but I could not make it work. On the schema I found: USB20: Do not support OTG mode and AVSS_USB0-AVSS_USB2 attached to ground. Could you, please, specify which node in the device-tree you want to disable. I cannot see anything disabled for usb@1010 and usb@0 in the kernel device-tree. Best regards Heinrich Aurelien [1] https://lore.kernel.org/linux-kernel/20240131132600.4067-2-jszh...@kernel.org/T/
Re: [PATCH] net: phy: ncsi: reslove the unaligned access issue
On 3/28/24 4:08 PM, Tom Rini wrote: On Mon, Feb 05, 2024 at 04:13:23PM +0800, Jacky Chou wrote: From the ethernet header is not on aligned, because the length of the ethernet header is 14 bytes. Therefore, unaligned access must be done here. Signed-off-by: Jacky Chou Applied to u-boot/next, thanks! Typo in subject, reslove->resolve .
[PATCH] mtd: spi-nor: Add support to exit 4-byte mode
The Kria board features a recovery application that activates
when the FW_EN button is pressed.
Upon power-up flash operates in 3B mode, However, the recovery
application changes it back to 4B mode.
Following a reset, u-boot activates the CONFIG_SPI_FLASH_BAR
and expects the flash to be in 3B mode. However, there's no
code to handle this configuration. to address this issue, changes
were made to disable the 4B mode when the CONFIG_SPI_FLASH_BAR
is enabled.
Additionally, spi_nor_wait_till_ready() was included because there is
operation that places the device in a busy state before performing
a nor read.
Signed-off-by: Tejas Bhumkar
---
drivers/mtd/spi/spi-nor-core.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index f86003ca8c..47f65a4f5e 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -1464,6 +1464,9 @@ static int spi_nor_read(struct mtd_info *mtd, loff_t
from, size_t len,
else
read_len = remain_len;
#endif
+ ret = spi_nor_wait_till_ready(nor);
+ if (ret)
+ goto read_err;
ret = nor->read(nor, addr, read_len, buf);
if (ret == 0) {
@@ -4161,6 +4164,7 @@ int spi_nor_scan(struct spi_nor *nor)
#else
/* Configure the BAR - discover bank cmds and read current bank */
nor->addr_width = 3;
+ set_4byte(nor, info, 0);
ret = read_bar(nor, info);
if (ret < 0)
return ret;
--
2.37.6
[PATCH 6/6] config: xea: Add limits for SPL and u-boot proper sizes
The XEA board has following hard constraints regarding size of binaries: - u-boot.sb < 48 KiB - u-boot.img < 448 KiB Added values are supposed to avoid exceeding size of binaries during future u-boot development. Signed-off-by: Lukasz Majewski --- configs/imx28_xea_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig index 6098c1f3be..822a329187 100644 --- a/configs/imx28_xea_defconfig +++ b/configs/imx28_xea_defconfig @@ -21,12 +21,15 @@ CONFIG_SPL_MMC=y CONFIG_SPL_SERIAL=y CONFIG_SPL_STACK=0x2 CONFIG_SPL_SYS_MALLOC_F_LEN=0x1000 +CONFIG_SPL_SIZE_LIMIT=0xa000 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x9 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x4200 CONFIG_SPL_PAYLOAD="u-boot.img" +CONFIG_HAS_BOARD_SIZE_LIMIT=y +CONFIG_BOARD_SIZE_LIMIT=458752 CONFIG_TIMESTAMP=y CONFIG_FIT=y # CONFIG_BOOTMETH_EXTLINUX is not set -- 2.39.2
[PATCH 5/6] arm: xea: Print information about XEA's SoM HW revision
As now XEA has its second HW revision - this information is printed
when u-boot proper starts.
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/xea.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index 90a1e03077..c117a8cb19 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -294,6 +294,15 @@ int board_late_init(void)
}
#endif
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+int checkboard(void)
+{
+ printf("Board: LWE XEA SoM HW rev %d\n", get_som_rev());
+
+ return 0;
+}
+#endif
+
int dram_init(void)
{
return mxs_dram_init();
--
2.39.2
[PATCH 4/6] config: xea: Enable late board initialization to set revision variable
The 'board_som_rev' environment variable will be used to point correct
configuration from the Linux FIT file.
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/xea.c | 12
configs/imx28_xea_defconfig| 1 +
configs/imx28_xea_sb_defconfig | 1 +
3 files changed, 14 insertions(+)
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index d9cf27c81b..90a1e03077 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -282,6 +282,18 @@ int board_init(void)
return 0;
}
+#if defined(CONFIG_BOARD_LATE_INIT)
+int board_late_init(void)
+{
+ int ret = env_set_ulong("board_som_rev", get_som_rev());
+
+ if (ret)
+ printf("Cannot set XEA's SoM revision env variable!\n");
+
+ return 0;
+}
+#endif
+
int dram_init(void)
{
return mxs_dram_init();
diff --git a/configs/imx28_xea_defconfig b/configs/imx28_xea_defconfig
index 64a0561a34..6098c1f3be 100644
--- a/configs/imx28_xea_defconfig
+++ b/configs/imx28_xea_defconfig
@@ -39,6 +39,7 @@ CONFIG_BOOTCOMMAND="run ${bootpri} ; run ${bootsec}"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="run prebootcmd"
CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
CONFIG_SPL_NO_BSS_LIMIT=y
CONFIG_SPL_BOARD_INIT=y
# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
diff --git a/configs/imx28_xea_sb_defconfig b/configs/imx28_xea_sb_defconfig
index 9872d35c1b..8d48d8c507 100644
--- a/configs/imx28_xea_sb_defconfig
+++ b/configs/imx28_xea_sb_defconfig
@@ -23,6 +23,7 @@ CONFIG_BOOTARGS="console=ttyAMA0,115200n8"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="run prebootcmd"
CONFIG_BOARD_EARLY_INIT_F=y
+CONFIG_BOARD_LATE_INIT=y
# CONFIG_SPL_FRAMEWORK is not set
CONFIG_SPL_NO_BSS_LIMIT=y
CONFIG_SPL_BOARD_INIT=y
--
2.39.2
[PATCH 3/6] arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2
The imx287 based XEA board's revision 2 uses GPIO_3_21 for PHY reset
It is safe to keep the GPIO_2_13 as well, as in the SPL SPI1 is not
used for transmission. This simplifies the code, as the proper
configuration is performed either in falcon boot's read DTB or in
u-boot proper (with correct FIT configuration chosen).
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/spl_xea.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 71194db235..6cf8f8390e 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -225,7 +225,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_ENET0_TXD0__ENET0_TXD0 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD1__ENET0_TXD1 | MUX_CONFIG_ENET,
MX28_PAD_ENET0_TXD3__ENET1_TXD1 | MUX_CONFIG_ENET,
- MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset */
+ MX28_PAD_SSP1_CMD__GPIO_2_13, /* PHY reset HW Rev. 1*/
+ MX28_PAD_SAIF0_LRCLK__GPIO_3_21, /* PHY reset HW Rev. 2*/
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
--
2.39.2
[PATCH 2/6] arm: xea: Add support for reading SoM (CPU) and base board HW revision
The XEA board now has several HW revisions for both SoM and base boards.
This patch provides support for reading those revision ID values in SPL
(u-boot.sb) and then pass this information to u-boot proper, as the
maximal SPL size (~55KiB) is not allowing for having FIT support in it.
It was necessary to handle reading GPIOs values solely in u-boot proper
as one configuration (i.e. 'single binary' - imx28_xea_sb_defconfig)
is not using SPL framework.
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/spl_xea.c | 11 +++
board/liebherr/xea/xea.c | 29 +
2 files changed, 40 insertions(+)
diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index 551ed6fbae..71194db235 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -230,6 +230,17 @@ const iomux_cfg_t iomux_setup[] = {
/* TIVA boot control */
MX28_PAD_GPMI_RDY3__GPIO_0_23 | MUX_CONFIG_BOOT, /* TIVA0 */
MX28_PAD_GPMI_WRN__GPIO_0_25 | MUX_CONFIG_BOOT, /* TIVA1 */
+
+ /* HW revision ID Base Board */
+ MX28_PAD_LCD_D12__GPIO_1_12,
+ MX28_PAD_LCD_D13__GPIO_1_13,
+ MX28_PAD_LCD_D14__GPIO_1_14,
+
+ /* HW revision ID (SoM) */
+ MX28_PAD_LCD_D15__GPIO_1_15,
+ MX28_PAD_LCD_D16__GPIO_1_16,
+ MX28_PAD_LCD_D17__GPIO_1_17,
+ MX28_PAD_LCD_D18__GPIO_1_18,
};
u32 mxs_dram_vals[] = {
diff --git a/board/liebherr/xea/xea.c b/board/liebherr/xea/xea.c
index c8ac526cb4..d9cf27c81b 100644
--- a/board/liebherr/xea/xea.c
+++ b/board/liebherr/xea/xea.c
@@ -48,6 +48,35 @@ DECLARE_GLOBAL_DATA_PTR;
* Functions
*/
+/*
+ * Reading the HW ID number for XEA SoM module
+ *
+ * GPIOs from Port 1 (GPIO1_15, GPIO1_16, GPIO1_17 and GPIO1_18)
+ * are used to store HW revision information.
+ * Reading of GPIOs values is performed before the Device Model is
+ * bring up as the proper DTB needs to be chosen first.
+ *
+ * Moreover, this approach is required as "single binary" configuration
+ * of U-Boot (imx28_xea_sb_defconfig) is NOT using SPL framework, so
+ * only minimal subset of functionality is provided when ID is read.
+ *
+ * Hence, the direct registers' access.
+ */
+#define XEA_SOM_HW_ID_GPIO_PORT (MXS_PINCTRL_BASE + (0x0900 + ((1) * 0x10)))
+#define XEA_SOM_REV_MASK GENMASK(18, 15)
+#define XEA_SOM_REV_SHIFT 15
+
+static inline u8 get_som_rev(void)
+{
+ struct mxs_register_32 *reg =
+ (struct mxs_register_32 *)XEA_SOM_HW_ID_GPIO_PORT;
+
+ u32 tmp = ~readl(>reg);
+ u8 id = (tmp & XEA_SOM_REV_MASK) >> XEA_SOM_REV_SHIFT;
+
+ return id;
+}
+
static void init_clocks(void)
{
/* IO0 clock at 480MHz */
--
2.39.2
[PATCH 1/6] arm: spl: xea: Remove I2S pins configuration from early initialization
XEA is not supporting and using I2S codec, so there is no need to
configure pins for it.
Signed-off-by: Lukasz Majewski
---
board/liebherr/xea/spl_xea.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/board/liebherr/xea/spl_xea.c b/board/liebherr/xea/spl_xea.c
index df354cac64..551ed6fbae 100644
--- a/board/liebherr/xea/spl_xea.c
+++ b/board/liebherr/xea/spl_xea.c
@@ -112,13 +112,6 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_I2C0_SCL__I2C0_SCL,
MX28_PAD_I2C0_SDA__I2C0_SDA,
- /* I2S Codec */
- MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK,
- MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK,
- MX28_PAD_SAIF0_MCLK__SAIF0_MCLK,
- MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0,
- MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0,
-
/* PWR-Hold */
MX28_PAD_SPDIF__GPIO_3_27,
--
2.39.2
[PATCH 0/6] arm: xea: Provide enhancements for XEA board
This patch series is a preparatory patch for supporting different versions of XEA board HW (until problem with Linux kernel support for multiple revisions is resorted). Moreover, limits for u-boot.sb and u-boot.img has been set to avoid binary sizes exceeding in the future. Lukasz Majewski (6): arm: spl: xea: Remove I2S pins configuration from early initialization arm: xea: Add support for reading SoM (CPU) and base board HW revision arm: spl: Add definition for PHY reset GPIO for XEA HW rev. 2 config: xea: Enable late board initialization to set revision variable arm: xea: Print information about XEA's SoM HW revision config: xea: Add limits for SPL and u-boot proper sizes board/liebherr/xea/spl_xea.c | 21 -- board/liebherr/xea/xea.c | 50 ++ configs/imx28_xea_defconfig| 4 +++ configs/imx28_xea_sb_defconfig | 1 + 4 files changed, 68 insertions(+), 8 deletions(-) -- 2.39.2
Re: [PATCH] tpm-v2: allow algo name to be conigured for pcr_read and pcr_extend
On Thu, Mar 28, 2024 at 12:37 AM Ilias Apalodimas
wrote:
>
> Hi Tim,
>
> [...]
>
> >
> > +/**
> > + * tpm2_algo_len() - Return an algo value and length given a algorithm name
> > + *
> > + * @name: algorithm name
> > + * @rwlen: pointer to integer to populate with algorithm length if non-null
> > + * Return: algorithm value
> > + */
> > +int tpm2_algo_len(const char *name, int *rwlen);
> > +
> > +/**
> > + * tpm2_algo_len() - Return an algoithm name string
> > + *
> > + * @algo: algorithm value
> > + * Return: algorithm string
> > + */
> > +const char *tpm2_algo_name(int algo);
> > +
> > #endif /* __TPM_V2_H */
> > diff --git a/lib/tpm-v2.c b/lib/tpm-v2.c
> > index 68eaaa639f89..6a090ce5810c 100644
> > --- a/lib/tpm-v2.c
> > +++ b/lib/tpm-v2.c
> > @@ -1555,3 +1555,49 @@ u32 tpm2_enable_nvcommits(struct udevice *dev, uint
> > vendor_cmd,
> >
> > return 0;
> > }
> > +
> > +int tpm2_algo_len(const char *name, int *rwlen)
> > +{
> > + int algo = -EINVAL;
> > + int len = 0;
> > +
> > + if (!strcasecmp("sha1", name)) {
> > + algo = TPM2_ALG_SHA1;
> > + len = TPM2_SHA1_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha256", name)) {
> > + algo = TPM2_ALG_SHA256;
> > + len = TPM2_SHA256_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha384", name)) {
> > + algo = TPM2_ALG_SHA384;
> > + len = TPM2_SHA384_DIGEST_SIZE;
> > + } else if (!strcasecmp("sha512", name)) {
> > + algo = TPM2_ALG_SHA512;
> > + len = TPM2_SHA512_DIGEST_SIZE;
> > + } else if (!strcasecmp("sm3_256", name)) {
> > + algo = TPM2_ALG_SM3_256;
> > + len = TPM2_SM3_256_DIGEST_SIZE;
> > + }
> > +
> > + if (*rwlen)
> > + *rwlen = len;
> > +
> > + return algo;
> > +}
> > +
>
> We already have tpm2_algorithm_to_len(). Instead of defining a new
> function, can we convert strings to 'enum tpm2_algorithms'? We can
> then reuse the existing function.
>
Hi Ilias,
Thanks - I didn't see tpm2_algorithm_to_len. Yes, I can use it but I
still need to add a new function to turn the name into an algo. I also
didn't see tpm2_supported_algorithms; should I only support
name-to-algorithm and algorithm-to-name for that subset?
Best Regards,
Tim
> > +const char *tpm2_algo_name(int algo)
> > +{
> > + switch (algo) {
> > + case TPM2_ALG_SHA1:
> > + return "sha1";
> > + case TPM2_ALG_SHA256:
> > + return "sha256";
> > + case TPM2_ALG_SHA384:
> > + return "sha384";
> > + case TPM2_ALG_SHA512:
> > + return "sha512";
> > + case TPM2_ALG_SM3_256:
> > + return "sm3_256";
> > + }
> > +
> > + return "";
> > +}
> > --
> > 2.25.1
> >
>
> Thanks
> /Ilias
Re: [PATCH 2/5] configs/am62x_beagleplay_a53_defconfig: enable DM_ETH_PHY
On Tue, Mar 05, 2024 at 03:24:54PM +0200, Roger Quadros wrote: > Reset GPIO handling is done in ETH PHY Class driver. > Enable DM_ETH_PHY. > > We don't use Fixed PHY so disable PHY_FIXED. > > Signed-off-by: Roger Quadros Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/5] net: mdio-uclass: Bind and probe generic Ethernet PHY driver
On Tue, Mar 05, 2024 at 03:24:53PM +0200, Roger Quadros wrote: > If DM_ETH_PHY is enabled then try to bind and probe the > generic Ethernet PHY driver for each child of MDIO bus. > > This is to ensure that GPIO reset handling is done if available > before MDIO bus driver scans for the PHYs. > > Signed-off-by: Roger Quadros Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] e1000: add support for i225-IT
On Mon, Mar 04, 2024 at 04:23:38PM +0100, Marjolaine Amate wrote: > This patch adds support for i225-IT in e1000 driver. > Add e1000_phy_igc. > > Signed-off-by: Marjolaine Amate Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/5] net: hifemac_mdio: use log_msg_ret() correctly, report error by dev_err()
On Mon, Jan 22, 2024 at 10:33:20PM +0800, Yang Xiwen via B4 Relay wrote:
> From: Yang Xiwen
>
> The initial commit used log_msg_ret() wrongly. Fix that by moving error
> report to a separate dev_err() call and shrink the first argument of
> log_msg_ret() to no more than 4 chars.
>
> Fixes: 6b5c8d98e204 ("net: add hifemac_mdio MDIO bus driver for HiSilicon
> platform")
>
> Signed-off-by: Yang Xiwen
For the series, applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] net: phy: the NC-SI phy device do not require mdio bus
On Mon, Jan 15, 2024 at 06:34:47PM +0800, Jacky Chou wrote: > As with fixed-link phy device, the NC-SI phy devive does not > require an mdio bus. So, a condition is added to check the > NC-SI phy id to avoid accessing the bus pointer that is NULL. > > Signed-off-by: Jacky Chou Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] net: phy: Fix signed shift overflow
On Thu, Jan 04, 2024 at 05:26:23AM +0100, Heinrich Schuchardt wrote:
> From: Eugeniu Rosca
>
> Booting R-Car Gen3 arm64 U-Boot with CONFIG_UBSAN=y resulted in:
>
> =
> UBSAN: Undefined behaviour in drivers/net/phy/phy.c:728:19
> left shift of 1 by 31 places cannot be represented in type 'int'
> =
>
> Fix it by appending the UL suffix to the numeric literal. While at it,
> convert the type of "addr" variable from signed to unsigned, to protect
> against shifting the numeric literal by a negative value (which would
> lead to yet another undefined behavior).
>
> Fixes: 1adb406b0141 ("phy: add phy_find_by_mask/phy_connect_dev")
> Signed-off-by: Eugeniu Rosca
>
> * Using U-suffix for integer is sufficient.
> * ffs() of non-zero value cannot be 0. But addr being unsigned is
> * preferable.
> Signed-off-by: Heinrich Schuchardt
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] net: phy: broadcom: Configure LEDs on BCM54210E
On Mon, Jan 01, 2024 at 10:07:47PM +0100, Marek Vasut wrote: > Configure LEDs on BCM54210E so they would blink on activity > and indicate link speed. Without this the LEDs are always on > if cable is plugged in. > > Signed-off-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] net: phy: Factor out PHY GPIO reset code
On Mon, Mar 18, 2024 at 03:57:01PM +0100, Marek Vasut wrote: > Pull the PHY GPIO reset code into separate function, since > this is and will be reused multiple times. Set up default > reset assert and deassert timing to generous 20ms and 1ms > for maximum compatibility in case those DT properties are > missing. > > Reviewed-by: Ramon Fried > Signed-off-by: Marek Vasut Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: phy: ncsi: reslove the unaligned access issue
On Mon, Feb 05, 2024 at 04:13:23PM +0800, Jacky Chou wrote: > From the ethernet header is not on aligned, because the length > of the ethernet header is 14 bytes. > Therefore, unaligned access must be done here. > > Signed-off-by: Jacky Chou Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: phy: ncsi: Correct the endian of the checksum
On Mon, Feb 05, 2024 at 04:02:28PM +0800, Jacky Chou wrote: > There is no need to perform the endian twice here. > > Signed-off-by: Jacky Chou > Reviewed-by: Dan Carpenter Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: phy: ncsi: fixed not nullify the pointers after free
On Fri, Dec 29, 2023 at 09:45:55AM +0800, Jacky Chou wrote: > The issue occurs the UAF (use-after-free) to cause double free > when do the realloc function for the pointers during the > reinitialization NC-SI process, and it will cause the memory > management occurs error. > So, nullify these pointers after free. > > Signed-off-by: Jacky Chou Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [NEXT] Pull request acpi-next-20240328
On Thu, Mar 28, 2024 at 11:16:56AM +0100, Heinrich Schuchardt wrote: > Dear Tom, > > The following changes since commit ab8d9ca3044acf51d8ff3bf3c4718c48f30ad606: > > Merge tag 'v2024.04-rc5' into next (2024-03-25 22:15:47 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/acpi-next-20240328 > > for you to fetch changes up to 6eca28b61af1835e70a6feb86f86a0b18b1708c6: > > smbios: fill wake-up type (2024-03-27 09:23:30 +0100) > > Gitlab CI showed no issues: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/20081 > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [RFC] Makefile.lib: find capsule ESL dtsi file when CONFIG_OF_UPSTREAM=y
On Thu, 28 Mar 2024 at 09:34, Jon Humphreys wrote:
>
> Sughosh Ganu writes:
>
> > hi Jonathan,
> >
> > On Wed, 27 Mar 2024 at 08:05, Jonathan Humphreys wrote:
> >>
> >> When CONFIG_OF_UPSTREAM is enabled, DTS files are in SOC subdirectories
> >> (vs the
> >> top level dts directory), but when CONFIG_EFI_CAPSULE_AUTHENTICATE is
> >> enabled,
> >> the dynamically created dtsi file containing the capsule ESL DT node is in
> >> the
> >> parent directory. This results in a build failure because the #include
> >> inserted
> >> in the DTS file is local to the current directory. Update Makefile to
> >> have the
> >> DT preprocessing of #includes search in the parent (dts top level)
> >> directory
> >> too.
> >>
> >> I'm not sure if this is the best solution.
> >>
> >> I was also tempted to just manually include the capsule-key property in the
> >> board dts, and avoid the Makefile implicit inclusion trickery. I would
> >> actually
> >> prefer this approach as everything is more explicit. But this isn't an
> >> option
> >> because if CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled, the implicit
> >> inclusion of
> >> the dtsi file happens. It would be better, IMO, if we only included the
> >> generated dtsi file if CONFIG_EFI_CAPSULE_ESL_FILE is defined. Was only
> >> supporting the implicit inclusiong approach an intentional design choice?
> >
> > I was not sure if users would want to manually insert the contents of
> > the ESL file, which is a binary file(a few hundred bytes at least)
> > into the DTS. If you prefer having such an option, we can change the
> > logic to what you propose. Thanks.
>
> What I was thinking is that one would explictly add the capsule-key
> property to the board dts but do it just as the generated dtsi does
> where it references the .esl file.
Okay. In any case, that can be done by having the addition of the
capsule_esl_dtsi to the dtsi_include_list under the
CONFIG_EFI_CAPSULE_ESL_FILE conditional, isn't it? That way, we have
both solutions. Users can then define the config flag to automate the
inclusion of the capsule-key. Those who prefer to explicitly include
the node to the board dts can do so on similar lines to how it is
defined in the lib/efi_loader/capsule_esl.dtsi.in file.
-sughosh
>
>
> Jon
>
> >
> > -sughosh
> >
> >>
> >> Thanks
> >> Jon
> >>
> >> Signed-off-by: Jonathan Humphreys
> >> ---
> >> scripts/Makefile.lib | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> >> index 12857316c58..62f87517c09 100644
> >> --- a/scripts/Makefile.lib
> >> +++ b/scripts/Makefile.lib
> >> @@ -334,7 +334,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
> >> (cat $< > $(pre-tmp)); \
> >> $(foreach f,$(subst $(quote),,$(dtsi_include_list)), \
> >> echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
> >> - $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp)
> >> $(pre-tmp) ; \
> >> + $(HOSTCC) -E $(dtc_cpp_flags) -I$(obj) -x assembler-with-cpp -o
> >> $(dtc-tmp) $(pre-tmp) ; \
> >> $(DTC) -O dtb -o $@ -b 0 \
> >> -i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
> >> -d $(depfile).dtc.tmp $(dtc-tmp) || \
> >> --
> >> 2.34.1
> >>
Re: [PATCH u-boot-mvebu v3 11/18] arm: mvebu: system-controller: Add support for SYSRESET
On Thu, 28 Mar 2024 14:01:22 +0100
Stefan Roese wrote:
> On 3/28/24 12:21, Marek Behún wrote:
> > On Thu, 28 Mar 2024 11:04:45 +0100
> > Stefan Roese wrote:
> >
> >>> +static int mvebu_sysreset_request(struct udevice *dev, enum sysreset_t
> >>> type)
> >>> +{
> >>> + struct regmap *regmap = syscon_get_regmap(dev->parent);
> >>> + uint bit;
> >>> +
> >>> + if (type != SYSRESET_COLD)
> >>> + return -EPROTONOSUPPORT;
> >>> +
> >>> + bit = MVEBU_GLOBAL_SOFT_RST_BIT;
> >>> +
> >>> + regmap_update_bits(regmap, MVEBU_RSTOUTN_MASK_REG, bit, bit);
> >>> + regmap_update_bits(regmap, MVEBU_SYS_SOFT_RST_REG, bit, bit);
> >>> +
> >>> + while (1)
> >>> + ;
> >>
> >> A comment before this endless loop might be helpful here.
> >
> > The code does the same as reset_cpu() in cpu.c, and the while() cycle
> > is not commented there.
>
> Sure, other code might suffer this undocumented endless loop as well.
> And again, this is more a nitpicking comment than a real requirement.
>
> > But we can add something like
> >/* something has gone wrong if we reach here, so we may as well stay
> > * here */
> >
> > What do you think? Could you amend the patch?
>
> More something like this:
>
> /* Loop while waiting for the reset */
> while (1)
> ;
As of now I don't see a need for v4.
I may sent another patches regarding DDR training, but it will be
made on top of this series.
Marek
Re: [PATCH v4 0/5] imx93: Conver to OF_UPSTREAM
Hello, > Mathieu: please help test the boards you maintain when you have time. I have tried both imx93_var_som and imx93-phyboard-segin configurations. Compilation works but I only get garbage on the UART on those two different boards. I will try to conduct further investigations later on, but the booting test is KO here. Thanks, Mathieu
Re: [PATCH] mx6cuboxi: Do not print devicetree model
Hi Christian,
On Thu, Mar 28, 2024 at 4:18 AM Christian Gmeiner wrote:
> This is not what this patch is doing. show_board_info() is the only
> caller of checkboard()
> so we end with the following output:
You're right. The attached patch should do what we want.
From b74a410127cabc100a8993840a3b00d403a316ad Mon Sep 17 00:00:00 2001
From: Fabio Estevam
Date: Thu, 28 Mar 2024 10:39:29 -0300
Subject: [PATCH v2] mx6cuboxi: Do not print devicetree model
The mx6cuboxi_defconfig target supports several board
variants. All of these variants use the hummingboard devicetree in U-Boot.
Currently, the devicetree model as well as the board variant name
are shown:
...
Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc)
Board: MX6 Cubox-i
...
Printing the devicetree model that is used internally by U-Boot
may confuse users.
Unselect the CONFIG_DISPLAY_BOARDINFO option so that only the
board name is printed in board_late_init() instead.
Signed-off-by: Fabio Estevam
---
Changes since v1:
- Remove checkboard and print the board name in board_late_init().
board/solidrun/mx6cuboxi/mx6cuboxi.c | 40 ++--
configs/mx6cuboxi_defconfig | 1 +
2 files changed, 9 insertions(+), 32 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 8edabf4404c2..31d30cfbbd7b 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -381,37 +381,6 @@ static bool has_emmc(void)
return (mmc_get_op_cond(mmc, true) < 0) ? 0 : 1;
}
-/* Override the default implementation, DT model is not accurate */
-int checkboard(void)
-{
- request_detect_gpios();
-
- switch (board_type()) {
- case CUBOXI:
- puts("Board: MX6 Cubox-i");
- break;
- case HUMMINGBOARD:
- puts("Board: MX6 HummingBoard");
- break;
- case HUMMINGBOARD2:
- puts("Board: MX6 HummingBoard2");
- break;
- case UNKNOWN:
- default:
- puts("Board: Unknown\n");
- goto out;
- }
-
- if (is_rev_15_som())
- puts(" (som rev 1.5)\n");
- else
- puts("\n");
-
- free_detect_gpios();
-out:
- return 0;
-}
-
static int find_ethernet_phy(void)
{
struct mii_dev *bus = NULL;
@@ -505,12 +474,15 @@ int board_late_init(void)
switch (board_type()) {
case CUBOXI:
env_set("board_name", "CUBOXI");
+ puts("Board: MX6 Cubox-i");
break;
case HUMMINGBOARD:
env_set("board_name", "HUMMINGBOARD");
+ puts("Board: MX6 HummingBoard");
break;
case HUMMINGBOARD2:
env_set("board_name", "HUMMINGBOARD2");
+ puts("Board: MX6 HummingBoard2");
break;
case UNKNOWN:
default:
@@ -522,8 +494,12 @@ int board_late_init(void)
else
env_set("board_rev", "MX6DL");
- if (is_rev_15_som())
+ if (is_rev_15_som()) {
env_set("som_rev", "V15");
+ puts(" (som rev 1.5)\n");
+ } else {
+ puts("\n");
+ }
if (has_emmc())
env_set("has_emmc", "yes");
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 27ceb22599a6..e3aba715aa58 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -28,6 +28,7 @@ CONFIG_BOOTCOMMAND="run findfdt; run finduuid; run distro_bootcmd"
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="if hdmidet; then usb start; setenv stdin serial,usbkbd; setenv stdout serial,vidconsole; setenv stderr serial,vidconsole; else setenv stdin serial; setenv stdout serial; setenv stderr serial; fi;"
CONFIG_SYS_PBSIZE=532
+# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_BOARD_EARLY_INIT_F=y
CONFIG_SPL_SYS_MALLOC=y
CONFIG_SPL_FS_EXT4=y
--
2.34.1
[PATCH] usb: dwc2: update reset method for host and device mode
Starting from version 4.20a, there has been a change in the reset method.
A new bit, GRSTCTL_CSFTRST_DONE, has been introduced in the GRSTCTL
register to indicate whether the reset has been completed.
Signed-off-by: Kongyang Liu
---
drivers/usb/gadget/dwc2_udc_otg.c | 18 --
drivers/usb/gadget/dwc2_udc_otg_regs.h | 19 +--
drivers/usb/host/dwc2.c| 19 ---
drivers/usb/host/dwc2.h| 6 ++
4 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/gadget/dwc2_udc_otg.c
b/drivers/usb/gadget/dwc2_udc_otg.c
index 27082f5152..d1dd469a0f 100644
--- a/drivers/usb/gadget/dwc2_udc_otg.c
+++ b/drivers/usb/gadget/dwc2_udc_otg.c
@@ -42,7 +42,7 @@
#include
#include
-#include
+#include
#include
@@ -464,12 +464,26 @@ static void reconfig_usbd(struct dwc2_udc *dev)
{
/* 2. Soft-reset OTG Core and then unreset again. */
int i;
- unsigned int uTemp = writel(CORE_SOFT_RESET, >grstctl);
+ unsigned int uTemp;
uint32_t dflt_gusbcfg;
uint32_t rx_fifo_sz, tx_fifo_sz, np_tx_fifo_sz;
u32 max_hw_ep;
int pdata_hw_ep;
+ u32 snpsid, greset;
+
+ snpsid = readl(>gsnpsid);
+ writel(CORE_SOFT_RESET, >grstctl);
+ if ((snpsid & SNPSID_VER_MASK) < (SNPSID_VER_420a & SNPSID_VER_MASK)) {
+ wait_for_bit_le32(>grstctl, CORE_SOFT_RESET, false, 1000,
false);
+ } else {
+ wait_for_bit_le32(>grstctl, CORE_SOFT_RESET_DONE, true,
1000, false);
+ greset = readl(>grstctl);
+ greset &= ~CORE_SOFT_RESET;
+ greset |= CORE_SOFT_RESET_DONE;
+ writel(greset, >grstctl);
+ }
+
debug("Resetting OTG controller\n");
dflt_gusbcfg =
diff --git a/drivers/usb/gadget/dwc2_udc_otg_regs.h
b/drivers/usb/gadget/dwc2_udc_otg_regs.h
index 9ca6f42375..b3d9117033 100644
--- a/drivers/usb/gadget/dwc2_udc_otg_regs.h
+++ b/drivers/usb/gadget/dwc2_udc_otg_regs.h
@@ -63,24 +63,26 @@ struct dwc2_usbotg_reg {
u32 gnptxfsiz; /* Non-Periodic Transmit FIFO Size */
u8 res0[12];
u32 ggpio; /* 0x038 */
- u8 res1[20];
+ u8 res1[4];
+ u32 gsnpsid;
+ u8 res2[12];
u32 ghwcfg4; /* User HW Config4 */
- u8 res2[176];
+ u8 res3[176];
u32 dieptxf[15]; /* Device Periodic Transmit FIFO size register */
- u8 res3[1728];
+ u8 res4[1728];
/* Device Configuration */
u32 dcfg; /* Device Configuration Register */
u32 dctl; /* Device Control */
u32 dsts; /* Device Status */
- u8 res4[4];
+ u8 res5[4];
u32 diepmsk; /* Device IN Endpoint Common Interrupt Mask */
u32 doepmsk; /* Device OUT Endpoint Common Interrupt Mask */
u32 daint; /* Device All Endpoints Interrupt */
u32 daintmsk; /* Device All Endpoints Interrupt Mask */
- u8 res5[224];
+ u8 res6[224];
struct dwc2_dev_in_endp in_endp[16];
struct dwc2_dev_out_endp out_endp[16];
- u8 res6[768];
+ u8 res7[768];
struct ep_fifo ep[16];
};
@@ -118,6 +120,7 @@ struct dwc2_usbotg_reg {
/* DWC2_UDC_OTG_GRSTCTL */
#define AHB_MASTER_IDLE(1u<<31)
#define CORE_SOFT_RESET(0x1<<0)
+#define CORE_SOFT_RESET_DONE (0x1<<29)
/* DWC2_UDC_OTG_GINTSTS/DWC2_UDC_OTG_GINTMSK core interrupt register */
#define INT_RESUME (1u<<31)
@@ -285,6 +288,10 @@ struct dwc2_usbotg_reg {
#define DAINT_IN_EP_INT(x)(x << 0)
#define DAINT_OUT_EP_INT(x) (x << 16)
+/* DWC2_UDC_OTG_GSNPSID */
+#define SNPSID_VER_420a0x4f54420a
+#define SNPSID_VER_MASK0x
+
/* User HW Config4 */
#define GHWCFG4_NUM_IN_EPS_MASK(0xf << 26)
#define GHWCFG4_NUM_IN_EPS_SHIFT 26
diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index 637eb2dd06..1baeff96ee 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -159,6 +159,7 @@ static void dwc_otg_core_reset(struct udevice *dev,
struct dwc2_core_regs *regs)
{
int ret;
+ u32 snpsid, greset;
/* Wait for AHB master IDLE state. */
ret = wait_for_bit_le32(>grstctl, DWC2_GRSTCTL_AHBIDLE,
@@ -167,9 +168,20 @@ static void dwc_otg_core_reset(struct udevice *dev,
dev_info(dev, "%s: Timeout!\n", __func__);
/* Core Soft Reset */
+ snpsid = readl(>gsnpsid);
writel(DWC2_GRSTCTL_CSFTRST, >grstctl);
- ret = wait_for_bit_le32(>grstctl, DWC2_GRSTCTL_CSFTRST,
- false, 1000, false);
+ if ((snpsid & DWC2_SNPSID_VER_MASK) < (DWC2_SNPSID_DEVID_VER_420a &
DWC2_SNPSID_VER_MASK)) {
+ ret = wait_for_bit_le32(>grstctl, DWC2_GRSTCTL_CSFTRST,
+
Re: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
Hi Josua,
On Thu, Mar 28, 2024 at 10:03 AM Josua Mayer wrote:
> I suggest changing their status to disabled, and keeping the nodes.
> >> +
> >> +phy: ethernet-phy@0 {
> > This node name is shared with upstream imx6qdl-sr-som.dtsi
> Give this one a u-boot-only internal name, maybe ethernet-phy@ff
...
> Just disable the u-boot-internal phy node unconditionally, or delete it.
> Because u-boot DTB is synced with upstream, the code below will update status
> properties
> for the standard etherent-phy@[0,1,4] nodes used by Linux.
Thanks for the suggestions.
My imx6-cuboxi board does not turn on anymore, unfortunately.
As I cannot test it, I am not comfortable doing the changes.
I hope you or Christian can submit a proper fix.
Re: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
Am 28.03.24 um 13:51 schrieb Josua Mayer:
> Am 28.03.24 um 13:21 schrieb Fabio Estevam:
>> From: Josua Mayer
>>
>> The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying
>> addresses. U-Boot needs to auto-detect which phy is actually present,
>> and at which address it is responding.
>>
>> Auto-detection from multiple phy nodes specified in device-tree does not
>> currently work correct. As a work-around merge all three possible phys
>> into one node with the special address 0x which indicates to the
>> generic phy driver to probe all addresses.
>> Also fixup this fake address before booting Linux, *if* booting with
>> U-Boot's internal dtb.
>>
>> Signed-off-by: Josua Mayer
>> [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.]
>> Signed-off-by: Fabio Estevam
>> Tested-by: Christian Gmeiner
>> ---
>> ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 +
>> arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 40 +++
>> board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +++-
>> 3 files changed, 48 insertions(+), 1 deletion(-)
>> create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
>>
>> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> index e9b188ed6587..358cf8abc4ff 100644
>> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
>> @@ -1,6 +1,7 @@
>> // SPDX-License-Identifier: GPL-2.0+
>>
>> #include "imx6qdl-u-boot.dtsi"
>> +#include "imx6qdl-sr-som-u-boot.dtsi"
>>
>> / {
>> board-detect {
>> diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
>> b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
>> new file mode 100644
>> index ..4c5f043ea92a
>> --- /dev/null
>> +++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
>> @@ -0,0 +1,40 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +
>> +#include
>> +
>> + {
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_microsom_enet_ar8035>;
>> +phy-handle = <>;
>> +phy-mode = "rgmii-id";
>> +
>> +/*
>> + * The PHY seems to require a long-enough reset duration to avoid
>> + * some rare issues where the PHY gets stuck in an inconsistent and
>> + * non-functional state at boot-up. 10ms proved to be fine .
>> + */
>> +phy-reset-duration = <10>;
>> +phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
>> +status = "okay";
>> +
>> +mdio {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +/delete-node/ ethernet-phy@1;
>> +/delete-node/ ethernet-phy@4;
I suggest changing their status to disabled, and keeping the nodes.
>> +
>> +phy: ethernet-phy@0 {
> This node name is shared with upstream imx6qdl-sr-som.dtsi
Give this one a u-boot-only internal name, maybe ethernet-phy@ff
>> +/*
>> + * The PHY can appear either:
>> + * - AR8035: at address 0 or 4
>> + * - ADIN1300: at address 1
>> + * Actual address being detected at runtime.
>> + */
>> +reg = <0x>;
>> +qca,clk-out-frequency = <12500>;
>> +qca,smarteee-tw-us-1g = <24>;
>> +adi,phy-output-clock = "125mhz-free-running";
>> +};
>> +};
>> +};
>> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
>> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
>> index 8edabf4404c2..fbab39e800a6 100644
>> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
>> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
>> @@ -447,7 +447,7 @@ static int find_ethernet_phy(void)
>> */
>> int ft_board_setup(void *fdt, struct bd_info *bd)
>> {
>> -int node_phy0, node_phy1, node_phy4;
>> +int node_phy, node_phy0, node_phy1, node_phy4;
>> int ret, phy;
>> bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false;
>> enum board_type board;
>> @@ -479,6 +479,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
>> return 0;
>> }
>>
>> +// update U-Boot's own unified phy node phy address, if present
>> +node_phy = fdt_path_offset(fdt,
>> "/soc/bus@210/ethernet@2188000/mdio/phy");
> This node no longer exists, unless you rename the u-boot-specific one.
> The u-boot node should probably have its own separate name, to ensure
> we do not find the upstream linux dtb ethernet-phy@0 node by mistake.
Look-up the u-boot-internal phy node name here
>> +ret = fdt_setprop_u32(fdt, node_phy, "reg", phy);
>> +if (ret < 0)
>> +pr_err("%s: failed to update unified PHY node address\n",
>> __func__);
>> +
>> // update all phy nodes status
>> node_phy0 = fdt_path_offset(fdt,
>> "/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0");
>> ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay"
>> : "disabled");
Re: Thoughts about U-boot binary size increase
Hi Tom, > On Thu, Mar 28, 2024 at 01:55:22PM +0100, Lukasz Majewski wrote: > > Hi Tom, > > > > > On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote: > > > > Dear Community, > > > > > > > > I'd like to share with you some thoughts about growth of > > > > u-boot's binary size for SPL and u-boot proper. > > > > > > > > Board: XEA > > > > SoC : imx287 (still in active production) > > > > Problem: SPL size constrained to ~55 KiB (This cannot be > > > > exceeded). Board design constraints u-boot proper size to less > > > > than ~448 KiB > > > > > > > > > > > > When XEA was added (2019.07): > > > > - u-boot.sb (SPL): 37 KiB > > > > - u-boot.img : 401 KiB > > > > > > > > Now (2024.04): > > > > - u-boot.sb (SPL): 40 KiB > > > > - u-boot.img : 427 KiB > > > > > > > > (With a _lot_ of effort put to reduce the size) > > > > > > > > Hence, the question - would it be possible to take more concern > > > > about the binary size growth? > > > > > > > > Maybe CI could catch patches, which enable by default some > > > > features and the size is unintentionally increased? > > > > > > > > I'm open for any feedback and thoughts on "stopping" the binary > > > > size increase. > > > > > > I think that's pretty amazingly small growth for nearly 5 years > > > of bug fixes and feature enhancements that it's likely minor to > > > make granular. > > > > Those results are after using OF_PLATDATA in SPL and other tricks - > > like compression of DTB in u-boot proper, so this caused some extra > > effort to keep small. > > Yes, and I'm still pretty happy with that. Ok :-) > I would encourage you to do > what I suggested, before turning on LTO (as that makes it hard to see > symbol size changes due to the nature of LTO) as what you asked for in > your original email is what I do, and have done for a very long time > now, with 99% of every pull request / branch merge. I'm not saying I > didn't miss anything, but I am saying it's a matter of specific > changes and not a general problem. Ok. I will check binman's output for symbol sizes changes. > And if you hadn't previously set > the options to enforce failure to build if hard size constraints are > missed, please do so. > I will. Thanks for input and help. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpWXlCv80mUZ.pgp Description: OpenPGP digital signature
Re: [PATCH u-boot-mvebu v3 11/18] arm: mvebu: system-controller: Add support for SYSRESET
On 3/28/24 12:21, Marek Behún wrote:
On Thu, 28 Mar 2024 11:04:45 +0100
Stefan Roese wrote:
+static int mvebu_sysreset_request(struct udevice *dev, enum sysreset_t type)
+{
+ struct regmap *regmap = syscon_get_regmap(dev->parent);
+ uint bit;
+
+ if (type != SYSRESET_COLD)
+ return -EPROTONOSUPPORT;
+
+ bit = MVEBU_GLOBAL_SOFT_RST_BIT;
+
+ regmap_update_bits(regmap, MVEBU_RSTOUTN_MASK_REG, bit, bit);
+ regmap_update_bits(regmap, MVEBU_SYS_SOFT_RST_REG, bit, bit);
+
+ while (1)
+ ;
A comment before this endless loop might be helpful here.
The code does the same as reset_cpu() in cpu.c, and the while() cycle
is not commented there.
Sure, other code might suffer this undocumented endless loop as well.
And again, this is more a nitpicking comment than a real requirement.
But we can add something like
/* something has gone wrong if we reach here, so we may as well stay
* here */
What do you think? Could you amend the patch?
More something like this:
/* Loop while waiting for the reset */
while (1)
;
And yes, I can fold this into your patchset, if I don't forget about
this. Still, if there is need for a v4, then please add it yourself.
Thanks,
Stefan
Re: Thoughts about U-boot binary size increase
On Thu, Mar 28, 2024 at 01:55:22PM +0100, Lukasz Majewski wrote: > Hi Tom, > > > On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote: > > > Dear Community, > > > > > > I'd like to share with you some thoughts about growth of u-boot's > > > binary size for SPL and u-boot proper. > > > > > > Board: XEA > > > SoC : imx287 (still in active production) > > > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). > > >Board design constraints u-boot proper size to less than > > > ~448 KiB > > > > > > > > > When XEA was added (2019.07): > > > - u-boot.sb (SPL): 37 KiB > > > - u-boot.img : 401 KiB > > > > > > Now (2024.04): > > > - u-boot.sb (SPL): 40 KiB > > > - u-boot.img : 427 KiB > > > > > > (With a _lot_ of effort put to reduce the size) > > > > > > Hence, the question - would it be possible to take more concern > > > about the binary size growth? > > > > > > Maybe CI could catch patches, which enable by default some features > > > and the size is unintentionally increased? > > > > > > I'm open for any feedback and thoughts on "stopping" the binary size > > > increase. > > > > I think that's pretty amazingly small growth for nearly 5 years of bug > > fixes and feature enhancements that it's likely minor to make > > granular. > > Those results are after using OF_PLATDATA in SPL and other tricks - like > compression of DTB in u-boot proper, so this caused some extra effort > to keep small. Yes, and I'm still pretty happy with that. I would encourage you to do what I suggested, before turning on LTO (as that makes it hard to see symbol size changes due to the nature of LTO) as what you asked for in your original email is what I do, and have done for a very long time now, with 99% of every pull request / branch merge. I'm not saying I didn't miss anything, but I am saying it's a matter of specific changes and not a general problem. And if you hadn't previously set the options to enforce failure to build if hard size constraints are missed, please do so. -- Tom signature.asc Description: PGP signature
Re: Thoughts about U-boot binary size increase
Hi Tom, > On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote: > > Dear Community, > > > > I'd like to share with you some thoughts about growth of u-boot's > > binary size for SPL and u-boot proper. > > > > Board: XEA > > SoC : imx287 (still in active production) > > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). > > Board design constraints u-boot proper size to less than > > ~448 KiB > > > > > > When XEA was added (2019.07): > > - u-boot.sb (SPL): 37 KiB > > - u-boot.img : 401 KiB > > > > Now (2024.04): > > - u-boot.sb (SPL): 40 KiB > > - u-boot.img : 427 KiB > > > > (With a _lot_ of effort put to reduce the size) > > > > Hence, the question - would it be possible to take more concern > > about the binary size growth? > > > > Maybe CI could catch patches, which enable by default some features > > and the size is unintentionally increased? > > > > I'm open for any feedback and thoughts on "stopping" the binary size > > increase. > > I think that's pretty amazingly small growth for nearly 5 years of bug > fixes and feature enhancements that it's likely minor to make > granular. Those results are after using OF_PLATDATA in SPL and other tricks - like compression of DTB in u-boot proper, so this caused some extra effort to keep small. > If LTO is not enabled on this platform As Fabio pointed out - I shall check if LTO can be (safely) enabled for imx287. > you should be able > to use buildman to give you a "bloat" list from v2019.07 to v2024.04 > and see if anything sticks out as being something that can be > addressed. But that little growth seems pretty good to me at first > glance. > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpqnWS2bWKxx.pgp Description: OpenPGP digital signature
Re: [PATCH u-boot-mvebu v3 05/18] arm: mvebu: turris_omnia: Implement getting board information from MCU
On 3/28/24 12:17, Marek Behún wrote:
On Thu, 28 Mar 2024 10:56:01 +0100
Stefan Roese wrote:
On 3/27/24 17:23, Marek Behún wrote:
Implement reading board serial number, first MAC address and board
version from MCU. MCU supports board information if the FEAT_BOARD_INFO
feature bit is set in MCU features.
Prefer getting board information from MCU if supported, fallback to
Atmel SHA chip.
Signed-off-by: Marek Behún
Minor comment below. Other than this:
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
board/CZ.NIC/turris_atsha_otp.c | 27 +--
board/CZ.NIC/turris_omnia/Makefile | 2 +-
board/CZ.NIC/turris_omnia/turris_omnia.c | 94 +++-
3 files changed, 93 insertions(+), 30 deletions(-)
diff --git a/board/CZ.NIC/turris_atsha_otp.c b/board/CZ.NIC/turris_atsha_otp.c
index a29fe36231..85eebcdf18 100644
--- a/board/CZ.NIC/turris_atsha_otp.c
+++ b/board/CZ.NIC/turris_atsha_otp.c
@@ -11,6 +11,7 @@
#include
#include "turris_atsha_otp.h"
+#include "turris_common.h"
#define TURRIS_ATSHA_OTP_VERSION 0
#define TURRIS_ATSHA_OTP_SERIAL 1
@@ -32,26 +33,6 @@ static struct udevice *get_atsha204a_dev(void)
return dev;
}
-static void increment_mac(u8 *mac)
-{
- int i;
-
- for (i = 5; i >= 3; i--) {
- mac[i] += 1;
- if (mac[i])
- break;
- }
-}
-
-static void set_mac_if_invalid(int i, u8 *mac)
-{
- u8 oldmac[6];
-
- if (is_valid_ethaddr(mac) &&
- !eth_env_get_enetaddr_by_index("eth", i, oldmac))
- eth_env_set_enetaddr_by_index("eth", i, mac);
-}
-
int turris_atsha_otp_init_mac_addresses(int first_idx)
{
struct udevice *dev = get_atsha204a_dev();
@@ -84,11 +65,7 @@ int turris_atsha_otp_init_mac_addresses(int first_idx)
mac[4] = mac1[2];
mac[5] = mac1[3];
- set_mac_if_invalid((first_idx + 0) % 3, mac);
- increment_mac(mac);
- set_mac_if_invalid((first_idx + 1) % 3, mac);
- increment_mac(mac);
- set_mac_if_invalid((first_idx + 2) % 3, mac);
+ turris_init_mac_addresses(first_idx, mac);
return 0;
}
diff --git a/board/CZ.NIC/turris_omnia/Makefile
b/board/CZ.NIC/turris_omnia/Makefile
index dc39b44ae1..341378b4e5 100644
--- a/board/CZ.NIC/turris_omnia/Makefile
+++ b/board/CZ.NIC/turris_omnia/Makefile
@@ -2,4 +2,4 @@
#
# Copyright (C) 2017 Marek Behún
-obj-y := turris_omnia.o ../turris_atsha_otp.o
+obj-y := turris_omnia.o ../turris_atsha_otp.o ../turris_common.o
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 6dfde5ee7a..f63640ad64 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -25,12 +26,14 @@
#include
#include
#include
+#include
#include
#include
#include "../drivers/ddr/marvell/a38x/ddr3_init.h"
#include <../serdes/a38x/high_speed_env_spec.h>
#include "../turris_atsha_otp.h"
+#include "../turris_common.h"
DECLARE_GLOBAL_DATA_PTR;
@@ -186,6 +189,70 @@ static bool omnia_mcu_has_feature(u32 feature)
return feature & features;
}
+static u32 omnia_mcu_crc32(const void *p, size_t len)
+{
+ u32 val, crc = 0;
+
+ compiletime_assert(!(len % 4), "length has to be a multiple of 4");
+
+ while (len) {
+ val = bitrev32(get_unaligned_le32(p));
+ crc = crc32(crc, (void *), 4);
+ p += 4;
+ len -= 4;
+ }
+
+ return ~bitrev32(crc);
+}
+
+/* Can only be called after relocation, since it needs cleared BSS */
+static int omnia_mcu_board_info(char *serial, u8 *mac, char *version)
+{
+ static u8 reply[17];
+ static bool cached;
+
+ if (!cached) {
+ u8 csum;
+ int ret;
+
+ ret = omnia_mcu_read(CMD_BOARD_INFO_GET, reply, sizeof(reply));
+ if (ret)
+ return ret;
+
+ if (reply[0] != 16)
+ return -EBADMSG;
+
+ csum = reply[16];
+ reply[16] = 0;
+
+ if ((omnia_mcu_crc32([1], 16) & 0xff) != csum)
+ return -EBADMSG;
+
+ cached = true;
+ }
+
+ if (serial) {
+ const char *serial_env;
+
+ serial_env = env_get("serial#");
+ if (serial_env && strlen(serial_env) == 16) {
+ strcpy(serial, serial_env);
Usage of strcpy() is discouraged AFAIK.
Yeah, it would make sense to use strncpy, but the potential leak is
prevented by strlen() check.
strncpy is also not optimal. Please see here if you are interested:
https://www.geeksforgeeks.org/why-strcpy-and-strncpy-are-not-safe-to-use/
AFAIU, there is no pressing need to change
Re: Thoughts about U-boot binary size increase
Hi Fabio, > Hi Lukasz, > > On Thu, Mar 28, 2024 at 6:20 AM Lukasz Majewski wrote: > > > > Dear Community, > > > > I'd like to share with you some thoughts about growth of u-boot's > > binary size for SPL and u-boot proper. > > > > Board: XEA > > SoC : imx287 (still in active production) > > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). > > Board design constraints u-boot proper size to less than > > ~448 KiB > > > > > > When XEA was added (2019.07): > > - u-boot.sb (SPL): 37 KiB > > - u-boot.img : 401 KiB > > > > Now (2024.04): > > - u-boot.sb (SPL): 40 KiB > > - u-boot.img : 427 KiB > > > > (With a _lot_ of effort put to reduce the size) > > > > Hence, the question - would it be possible to take more concern > > about the binary size growth? > > > > Maybe CI could catch patches, which enable by default some features > > and the size is unintentionally increased? > > > > I'm open for any feedback and thoughts on "stopping" the binary size > > increase. > > In addition to adding CONFIG_BOARD_SIZE_LIMIT and > CONFIG_SPL_SIZE_LIMIT checks, could you try the change below? > > diff --git a/arch/arm/mach-imx/mxs/Kconfig > b/arch/arm/mach-imx/mxs/Kconfig index d2e4205c5ce5..ee8c23d0e04f > 100644 --- a/arch/arm/mach-imx/mxs/Kconfig > +++ b/arch/arm/mach-imx/mxs/Kconfig > @@ -32,6 +32,7 @@ if ARCH_MX28 > > config MX28 > bool > + select LTO > default y > > I did a quick imx28_xea_defconfig build test here: > > U-Boot mainline > --- > > $ ls -al u-boot.img > -rw-rw-r-- 1 fabio fabio 444128 mar 28 09:11 u-boot.img > > $ ls -al spl/u-boot-spl.bin > -rwxrwxr-x 1 fabio fabio 39800 mar 28 09:12 spl/u-boot-spl.bin > > > U-Boot mainline + LTO > - > > $ ls -al u-boot.img > -rw-rw-r-- 1 fabio fabio 424144 mar 28 09:14 u-boot.img > > $ ls -al spl/u-boot-spl.bin > -rw-rw-r-- 1 fabio fabio 37664 mar 28 09:14 spl/u-boot-spl.bin Thanks for the tip - I will check if enabling LTO is not causing any regressions. Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpZann_E8uo3.pgp Description: OpenPGP digital signature
Re: [PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
Am 28.03.24 um 13:21 schrieb Fabio Estevam:
> From: Josua Mayer
>
> The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying
> addresses. U-Boot needs to auto-detect which phy is actually present,
> and at which address it is responding.
>
> Auto-detection from multiple phy nodes specified in device-tree does not
> currently work correct. As a work-around merge all three possible phys
> into one node with the special address 0x which indicates to the
> generic phy driver to probe all addresses.
> Also fixup this fake address before booting Linux, *if* booting with
> U-Boot's internal dtb.
>
> Signed-off-by: Josua Mayer
> [fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.]
> Signed-off-by: Fabio Estevam
> Tested-by: Christian Gmeiner
> ---
> ...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 +
> arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 40 +++
> board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +++-
> 3 files changed, 48 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
>
> diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> index e9b188ed6587..358cf8abc4ff 100644
> --- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> +++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
>
> #include "imx6qdl-u-boot.dtsi"
> +#include "imx6qdl-sr-som-u-boot.dtsi"
>
> / {
> board-detect {
> diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
> b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
> new file mode 100644
> index ..4c5f043ea92a
> --- /dev/null
> +++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
> @@ -0,0 +1,40 @@
> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
> +
> +#include
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_microsom_enet_ar8035>;
> + phy-handle = <>;
> + phy-mode = "rgmii-id";
> +
> + /*
> + * The PHY seems to require a long-enough reset duration to avoid
> + * some rare issues where the PHY gets stuck in an inconsistent and
> + * non-functional state at boot-up. 10ms proved to be fine .
> + */
> + phy-reset-duration = <10>;
> + phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +
> + mdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /delete-node/ ethernet-phy@1;
> + /delete-node/ ethernet-phy@4;
> +
> + phy: ethernet-phy@0 {
This node name is shared with upstream imx6qdl-sr-som.dtsi
> + /*
> + * The PHY can appear either:
> + * - AR8035: at address 0 or 4
> + * - ADIN1300: at address 1
> + * Actual address being detected at runtime.
> + */
> + reg = <0x>;
> + qca,clk-out-frequency = <12500>;
> + qca,smarteee-tw-us-1g = <24>;
> + adi,phy-output-clock = "125mhz-free-running";
> + };
> + };
> +};
> diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> index 8edabf4404c2..fbab39e800a6 100644
> --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
> +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
> @@ -447,7 +447,7 @@ static int find_ethernet_phy(void)
> */
> int ft_board_setup(void *fdt, struct bd_info *bd)
> {
> - int node_phy0, node_phy1, node_phy4;
> + int node_phy, node_phy0, node_phy1, node_phy4;
> int ret, phy;
> bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false;
> enum board_type board;
> @@ -479,6 +479,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
> return 0;
> }
>
> + // update U-Boot's own unified phy node phy address, if present
> + node_phy = fdt_path_offset(fdt,
> "/soc/bus@210/ethernet@2188000/mdio/phy");
This node no longer exists, unless you rename the u-boot-specific one.
The u-boot node should probably have its own separate name, to ensure
we do not find the upstream linux dtb ethernet-phy@0 node by mistake.
> + ret = fdt_setprop_u32(fdt, node_phy, "reg", phy);
> + if (ret < 0)
> + pr_err("%s: failed to update unified PHY node address\n",
> __func__);
> +
> // update all phy nodes status
> node_phy0 = fdt_path_offset(fdt,
> "/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0");
> ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay"
> : "disabled");
[PATCH] mx6cuboxi: Fix Ethernet after DT sync with Linux
From: Josua Mayer
The i.MX6 Cubox-i and HummingBoards can have different PHYs at varying
addresses. U-Boot needs to auto-detect which phy is actually present,
and at which address it is responding.
Auto-detection from multiple phy nodes specified in device-tree does not
currently work correct. As a work-around merge all three possible phys
into one node with the special address 0x which indicates to the
generic phy driver to probe all addresses.
Also fixup this fake address before booting Linux, *if* booting with
U-Boot's internal dtb.
Signed-off-by: Josua Mayer
[fabio: Added the changes to imx6qdl-sr-som-u-boot.dtsi.]
Signed-off-by: Fabio Estevam
Tested-by: Christian Gmeiner
---
...qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 1 +
arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi | 40 +++
board/solidrun/mx6cuboxi/mx6cuboxi.c | 8 +++-
3 files changed, 48 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index e9b188ed6587..358cf8abc4ff 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
#include "imx6qdl-u-boot.dtsi"
+#include "imx6qdl-sr-som-u-boot.dtsi"
/ {
board-detect {
diff --git a/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
new file mode 100644
index ..4c5f043ea92a
--- /dev/null
+++ b/arch/arm/dts/imx6qdl-sr-som-u-boot.dtsi
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+#include
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_microsom_enet_ar8035>;
+ phy-handle = <>;
+ phy-mode = "rgmii-id";
+
+ /*
+* The PHY seems to require a long-enough reset duration to avoid
+* some rare issues where the PHY gets stuck in an inconsistent and
+* non-functional state at boot-up. 10ms proved to be fine .
+*/
+ phy-reset-duration = <10>;
+ phy-reset-gpios = < 15 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /delete-node/ ethernet-phy@1;
+ /delete-node/ ethernet-phy@4;
+
+ phy: ethernet-phy@0 {
+ /*
+* The PHY can appear either:
+* - AR8035: at address 0 or 4
+* - ADIN1300: at address 1
+* Actual address being detected at runtime.
+*/
+ reg = <0x>;
+ qca,clk-out-frequency = <12500>;
+ qca,smarteee-tw-us-1g = <24>;
+ adi,phy-output-clock = "125mhz-free-running";
+ };
+ };
+};
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 8edabf4404c2..fbab39e800a6 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -447,7 +447,7 @@ static int find_ethernet_phy(void)
*/
int ft_board_setup(void *fdt, struct bd_info *bd)
{
- int node_phy0, node_phy1, node_phy4;
+ int node_phy, node_phy0, node_phy1, node_phy4;
int ret, phy;
bool enable_phy0 = false, enable_phy1 = false, enable_phy4 = false;
enum board_type board;
@@ -479,6 +479,12 @@ int ft_board_setup(void *fdt, struct bd_info *bd)
return 0;
}
+ // update U-Boot's own unified phy node phy address, if present
+ node_phy = fdt_path_offset(fdt,
"/soc/bus@210/ethernet@2188000/mdio/phy");
+ ret = fdt_setprop_u32(fdt, node_phy, "reg", phy);
+ if (ret < 0)
+ pr_err("%s: failed to update unified PHY node address\n",
__func__);
+
// update all phy nodes status
node_phy0 = fdt_path_offset(fdt,
"/soc/bus@210/ethernet@2188000/mdio/ethernet-phy@0");
ret = fdt_setprop_string(fdt, node_phy0, "status", enable_phy0 ? "okay"
: "disabled");
--
2.34.1
Re: Thoughts about U-boot binary size increase
Hi Lukasz, On Thu, Mar 28, 2024 at 6:20 AM Lukasz Majewski wrote: > > Dear Community, > > I'd like to share with you some thoughts about growth of u-boot's > binary size for SPL and u-boot proper. > > Board: XEA > SoC : imx287 (still in active production) > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). > Board design constraints u-boot proper size to less than ~448 > KiB > > > When XEA was added (2019.07): > - u-boot.sb (SPL): 37 KiB > - u-boot.img : 401 KiB > > Now (2024.04): > - u-boot.sb (SPL): 40 KiB > - u-boot.img : 427 KiB > > (With a _lot_ of effort put to reduce the size) > > Hence, the question - would it be possible to take more concern about > the binary size growth? > > Maybe CI could catch patches, which enable by default some features and > the size is unintentionally increased? > > I'm open for any feedback and thoughts on "stopping" the binary size > increase. In addition to adding CONFIG_BOARD_SIZE_LIMIT and CONFIG_SPL_SIZE_LIMIT checks, could you try the change below? diff --git a/arch/arm/mach-imx/mxs/Kconfig b/arch/arm/mach-imx/mxs/Kconfig index d2e4205c5ce5..ee8c23d0e04f 100644 --- a/arch/arm/mach-imx/mxs/Kconfig +++ b/arch/arm/mach-imx/mxs/Kconfig @@ -32,6 +32,7 @@ if ARCH_MX28 config MX28 bool + select LTO default y I did a quick imx28_xea_defconfig build test here: U-Boot mainline --- $ ls -al u-boot.img -rw-rw-r-- 1 fabio fabio 444128 mar 28 09:11 u-boot.img $ ls -al spl/u-boot-spl.bin -rwxrwxr-x 1 fabio fabio 39800 mar 28 09:12 spl/u-boot-spl.bin U-Boot mainline + LTO - $ ls -al u-boot.img -rw-rw-r-- 1 fabio fabio 424144 mar 28 09:14 u-boot.img $ ls -al spl/u-boot-spl.bin -rw-rw-r-- 1 fabio fabio 37664 mar 28 09:14 spl/u-boot-spl.bin
Re: Thoughts about U-boot binary size increase
On Thu, Mar 28, 2024 at 10:20:49AM +0100, Lukasz Majewski wrote: > Dear Community, > > I'd like to share with you some thoughts about growth of u-boot's > binary size for SPL and u-boot proper. > > Board: XEA > SoC : imx287 (still in active production) > Problem: SPL size constrained to ~55 KiB (This cannot be exceeded). >Board design constraints u-boot proper size to less than ~448 >KiB > > > When XEA was added (2019.07): > - u-boot.sb (SPL): 37 KiB > - u-boot.img : 401 KiB > > Now (2024.04): > - u-boot.sb (SPL): 40 KiB > - u-boot.img : 427 KiB > > (With a _lot_ of effort put to reduce the size) > > Hence, the question - would it be possible to take more concern about > the binary size growth? > > Maybe CI could catch patches, which enable by default some features and > the size is unintentionally increased? > > I'm open for any feedback and thoughts on "stopping" the binary size > increase. I think that's pretty amazingly small growth for nearly 5 years of bug fixes and feature enhancements that it's likely minor to make granular. If LTO is not enabled on this platform you should be able to use buildman to give you a "bloat" list from v2019.07 to v2024.04 and see if anything sticks out as being something that can be addressed. But that little growth seems pretty good to me at first glance. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
On 11:53-20240328, Sverdlin, Alexander wrote: [..] > > Btw, this no longer applies on next. only applies on master. Depending > > on where Tom would like to apply this change, might need a rebase. > > Thanks for the hint! I've totally missed this! > And I'm even not sure the patch makes sense on "next". > I'd need to retest if the problem is still there (and if there would be one, > then it's rather subsystem problem, not am65-cpsw any more. > > So the patch only makes sense for stable branches, if any. On next, I think a variant of the patch will be needed as well. I see the same bug on latest next as well (ab8d9ca3044a Merge tag 'v2024.04-rc5' into next) https://gist.github.com/nmenon/691ccd210ed7e1add4c865ca9a698f2e -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2] riscv: Move virtio scan to board_late_init()
On Thu, Mar 28, 2024 at 10:58:24AM +0100, Łukasz Stelmach wrote: > [EXTERNAL MAIL] > > When virtio_init() gets called from board_init() PCI isn't ready. Thus, > virtio-over-PCI (e.g. network interfaces) devices can't be detected and > used without additional `virtio scan` scan in the shell or a script. > > Signed-off-by: Łukasz Stelmach > --- > Changes since v1: > - remove virtio_init() call from board_init() > - select BOARD_LATE_INIT for TARGET_QEMU_VIRT > > arch/riscv/Kconfig | 1 + > board/emulation/qemu-riscv/qemu-riscv.c | 12 ++-- > 2 files changed, 7 insertions(+), 6 deletions(-) Reviewed-by: Leo Yu-Chi Liang
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi,
On Thu Mar 28, 2024 at 12:18 PM CET, Neha Malcom Francis wrote:
> On 27-Mar-24 8:03 PM, Michael Walle wrote:
> > On Wed Mar 27, 2024 at 8:01 AM CET, Neha Malcom Francis wrote:
> >> On 26/03/24 19:18, Michael Walle wrote:
> >>> On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote:
> Clean up templatized boot binaries for all K3 boards. This includes
> modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
> UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
> code.
>
> All k3--binman.dtsi will contain only templates. Only required boot
> binaries can be built from the templates in the boards' respective
> -u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
> clear distinction between the SoC common stuff vs. what is additionally
> needed to boot up a specific board.
> >>>
> >>> I appreciate the cleanup. But as far as I can see, a board might
> >>> only have one device tree. How would that work if the uboot proper
> >>> must support multiple device trees?
> >>>
> >>
> >> From the discussions that took place in the mailing list [1] the
> >> consensus
> >> seems to be to not focus on multiple devicetree support as it leads to
> >> confusion
> >> for downstream users.
> >
> > What are users in this regard? I don't think you'd confuse
> > developers.
> >
> > Anyway, I'm planning on upstreaming a TI board which will have
> > different memory configurations and different variants of the board.
>
> I am assuming you are reusing an existing TI SoC?
Not really yet. It's the j722s.
> > And on top of that, it will just be a base board and there will
> > likely be some carrier device trees (overlay? I'm not sure yet).
> >
> > As far as I can tell, you've put the memory configuration into the
> > device tree, so I'll probably need to switch between them somehow.
>
> The "k3--ddr.dtsi" file will be present in your k3-r5.dts
> which makes sense, the memory configuration depends on the board.
And one board might have multiple configuration depending on the
variant of the board. Typically, one board is available with
different memory options. i.e. 1GiB, 4GiB and so on. The actual RAM
chips can come from different manufacturers. So all all, I presume
there will be different RAM settings, i.e. different
k3--ddr.dtsi. But I have to switch between the setting during
runtime because there will be only one boot image for that board.
> > Also, regarding the board variants, I'll probably need to choose
> > between multiple device trees. That is invisible to the user,
> > because u-boot will choose the correct DTB according a board
> > strapping, which btw. works really fine, see for example
> > (boards/kontron/sl28/spl.c:board_fit_config_name_match).
>
> Again, this is assuming that there is some HW blown register available
> for the board to use (or in our earlier K3 case, the EEPROM) but that is
> not necessarily true every time.
No, that is of course board dependent. It is just an example that
there are boards with more than one DTB.
Let's step back a bit. Right now, there is
k3---binman.dtsi
which is fine. But it seems, that TI is heading towards a common
k3--binman.dtsi
which is intended to be used by all the boards that are using that
particular SoC, correct me if I'm wrong here. Now the problem with
that is that you hardcode the FIT configuations which are really
board dependent and assume that there will be exactly one DTB per
board, i.e. your "#define SPL_BOARD_DTB" etc.
Thus, what I was trying to say is that you should split all the
board independent configuration (dt fragments) from the board
specific configuration.
And again, of course I could just ignore the k3--binman.dtsi
and just use a suitable copy "k3---binman.dtsi" for my
board. But as I said, I'm not sure, this is the way to go and I have
a slight feeling I will be asked to reuse the "k3--binman.dtsi"
when I submit my board support.
> >
> > I don't think it makes much sense to hardcode your generic
> > *-binman.dtsi to just one FIT configuration. I'd rather see a split
> > between generic things which are shared across all boards and board
> > specifics, like the FIT configuration. I mean I could just copy all
>
> Correct me if I'm wrong, but my understanding is that you would want to
> add more FDT blobs in the *-binman.dtsi correct? That is still possible,
> adding another "fdt-1" and "conf-1" in the
>
> Something like this in your -u-boot.dtsi,
>
> tispl {
> insert-template = <_spl>;
> fit {
> images {
> fdt-1 {
> ...
> };
> };
> configurations {
> conf-1 {
> ...
> };
> };
> };
> };
Then you have the information at two places. One being the "#define
SPL_BOARD_DTB" stuff and the other one being in
Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
Hi Nishanth!
On Thu, 2024-03-28 at 06:45 -0500, Nishanth Menon wrote:
> On 07:29-20240328, A. Sverdlin wrote:
> > From: Alexander Sverdlin
> >
> > am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> > specified in DT gracefully:
> >
> > am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1
> > (-2)
> >
> > am65_cpsw_mdio_init() in turn is prepared for this, checks
> > if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
> >
> > am65_cpsw_phy_init() however is not prepared for this and calls
> > phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
> >
> > "Synchronous Abort" handler, esr 0x860d, far 0x0
> > elr: 808ab000 lr : 8083bde4 (reloc)
> >
> > where lr points to the instruction right after bus->read() in get_phy_id().
> >
> > Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
> > subsystem driver")
> > Signed-off-by: Alexander Sverdlin
> > ---
> > v2: rewritten subject; "is turn" -> "in turn" further down in message body
> >
> > drivers/net/ti/am65-cpsw-nuss.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/net/ti/am65-cpsw-nuss.c
> > b/drivers/net/ti/am65-cpsw-nuss.c
> > index 6da018c0f9d5..d1e452b6b43c 100644
> > --- a/drivers/net/ti/am65-cpsw-nuss.c
> > +++ b/drivers/net/ti/am65-cpsw-nuss.c
> > @@ -722,6 +722,9 @@ static int am65_cpsw_phy_init(struct udevice *dev)
> > u32 supported = PHY_GBIT_FEATURES;
> > int ret;
> >
> > + if (!priv->has_phy || !cpsw_common->bus)
> > + return 0;
> > +
> > phydev = phy_connect(cpsw_common->bus,
> > priv->phy_addr,
> > priv->dev,
> > --
> > 2.44.0
> >
>
> Reviewed-by: Nishanth Menon
>
>
> Thanks for fixing this.
>
> Btw, this no longer applies on next. only applies on master. Depending
> on where Tom would like to apply this change, might need a rebase.
Thanks for the hint! I've totally missed this!
And I'm even not sure the patch makes sense on "next".
I'd need to retest if the problem is still there (and if there would be one,
then it's rather subsystem problem, not am65-cpsw any more.
So the patch only makes sense for stable branches, if any.
--
Alexander Sverdlin
Siemens AG
www.siemens.com
Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
On 07:29-20240328, A. Sverdlin wrote:
> From: Alexander Sverdlin
>
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
>
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
>
> am65_cpsw_mdio_init() in turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
>
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
>
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
>
> where lr points to the instruction right after bus->read() in get_phy_id().
>
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
> subsystem driver")
> Signed-off-by: Alexander Sverdlin
> ---
> v2: rewritten subject; "is turn" -> "in turn" further down in message body
>
> drivers/net/ti/am65-cpsw-nuss.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 6da018c0f9d5..d1e452b6b43c 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -722,6 +722,9 @@ static int am65_cpsw_phy_init(struct udevice *dev)
> u32 supported = PHY_GBIT_FEATURES;
> int ret;
>
> + if (!priv->has_phy || !cpsw_common->bus)
> + return 0;
> +
> phydev = phy_connect(cpsw_common->bus,
>priv->phy_addr,
>priv->dev,
> --
> 2.44.0
>
Reviewed-by: Nishanth Menon
Thanks for fixing this.
Btw, this no longer applies on next. only applies on master. Depending
on where Tom would like to apply this change, might need a rebase.
CC Roger.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH v1] arm: mach-k3: common: EFI loader map memory below ram top
From: Vitor Soares
During the boot, the EFI loader maps the memory from ram_top to ram_end
as EFI_BOOT_SERVICES_DATA. When LMB does boot_fdt_add_mem_rsv_regions()
to OPTEE, TFA, R5, and M4F DMA/memory "no-map" for the kernel it produces
the following error message:
ERROR: reserving fdt memory region failed (addr=9cb0 size=10 flags=4)
ERROR: reserving fdt memory region failed (addr=9cc0 size=e0 flags=4)
ERROR: reserving fdt memory region failed (addr=9da0 size=10 flags=4)
ERROR: reserving fdt memory region failed (addr=9db0 size=c0 flags=4)
ERROR: reserving fdt memory region failed (addr=9e78 size=8 flags=4)
ERROR: reserving fdt memory region failed (addr=9e80 size=180 flags=4)
To avoid this, don't flag with EFI_BOOT_SERVICES_DATA the memory from
ram_top to ram_end by the EFI loader.
Signed-off-by: Vitor Soares
---
Similar fix for the same issue can be found at
https://lore.kernel.org/all/20240308101230.2595220-1-patrice.chot...@foss.st.com/
arch/arm/mach-k3/common.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index b54f2ddc47..80e89b2a16 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -24,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -607,3 +608,14 @@ void setup_qos(void)
writel(qos_data[i].val, (uintptr_t)qos_data[i].reg);
}
#endif
+
+void efi_add_known_memory(void)
+{
+ if (IS_ENABLED(CONFIG_EFI_LOADER))
+ /*
+* Memory over ram_top can be used by various firmware
+* Declare to EFI only memory area below ram_top
+*/
+ efi_add_memory_map(gd->ram_base, gd->ram_top - gd->ram_base,
+ EFI_CONVENTIONAL_MEMORY);
+}
--
2.34.1
[PATCH v2] riscv: Move virtio scan to board_late_init()
When virtio_init() gets called from board_init() PCI isn't ready. Thus,
virtio-over-PCI (e.g. network interfaces) devices can't be detected and
used without additional `virtio scan` scan in the shell or a script.
Signed-off-by: Łukasz Stelmach
---
Changes since v1:
- remove virtio_init() call from board_init()
- select BOARD_LATE_INIT for TARGET_QEMU_VIRT
arch/riscv/Kconfig | 1 +
board/emulation/qemu-riscv/qemu-riscv.c | 12 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ac52c5e6daf..c5c2e8a9c9d 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -22,6 +22,7 @@ config TARGET_OPENPITON_RISCV64
config TARGET_QEMU_VIRT
bool "Support QEMU Virt Board"
+ select BOARD_LATE_INIT
config TARGET_SIFIVE_UNLEASHED
bool "Support SiFive Unleashed Board"
diff --git a/board/emulation/qemu-riscv/qemu-riscv.c
b/board/emulation/qemu-riscv/qemu-riscv.c
index 181abbbf97d..173245b40e3 100644
--- a/board/emulation/qemu-riscv/qemu-riscv.c
+++ b/board/emulation/qemu-riscv/qemu-riscv.c
@@ -31,12 +31,6 @@ int is_flash_available(void)
int board_init(void)
{
- /*
-* Make sure virtio bus is enumerated so that peripherals
-* on the virtio bus can be discovered by their drivers
-*/
- virtio_init();
-
return 0;
}
@@ -46,6 +40,12 @@ int board_late_init(void)
if (CONFIG_IS_ENABLED(USB_KEYBOARD))
usb_init();
+ /*
+* Make sure virtio bus is enumerated so that peripherals
+* on the virtio bus can be discovered by their drivers
+*/
+ virtio_init();
+
return 0;
}
--
2.39.2
Re: [PATCH] mx6cuboxi: Do not print devicetree model
Hi Fabio > The mx6cuboxi_defconfig target supports several board > variants. All of these variants use the hummingboard devicetree in U-Boot. > > Currently, the devicetree model as well as the board variant name > are shown: > > U-Boot 2024.04-rc5-3-g774ec4fda8 (Mar 27 2024 - 16:48:35 +0100) > > ... > Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) > Board: MX6 Cubox-i > ... > > Printing the devicetree model that is used internally by U-Boot > may confuse users. > > Unselect the CONFIG_DISPLAY_BOARDINFO option so that only the > board name is printed instead. > This is not what this patch is doing. show_board_info() is the only caller of checkboard() so we end with the following output: U-Boot 2024.04-rc5-5-g50decee264-dirty (Mar 28 2024 - 08:09:58 +0100) CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 34C Reset cause: POR DRAM: 2 GiB Core: 84 devices, 19 uclasses, devicetree: fit WDT: Started watchdog@20bc000 with servicing every 1000ms (128s timeout) MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... *** Warning - bad CRC, using default environment Thanks & Regards, Christian
Re: [PATCH v2] net: ti: am65-cpsw-nuss: handle missing PHY in am65_cpsw_phy_init() gracefully
On Thu, Mar 28, 2024 at 07:29:10AM +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin
>
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
>
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
>
> am65_cpsw_mdio_init() in turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
>
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
>
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
>
> where lr points to the instruction right after bus->read() in get_phy_id().
>
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
> subsystem driver")
> Signed-off-by: Alexander Sverdlin
Reviewed-by: Siddharth Vadapalli
Regards,
Siddharth.
[PATCH v1 1/1] [U-Boot] drivers: misc: Fixes: Rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
From: Wan Yee Lau
Commit 3f190c55a4211215914126b74357344342329943
("drivers: misc: Add socfpga_dtreg driver for Intel SoCFPGA")
This commit rename CONFIG_SPL_SOCFPGA_SEC_REG to CONFIG_SPL_SOCFPGA_DT_REG
in Makefile.
Signed-off-by: Wan Yee Lau
---
drivers/misc/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 1522f6c3b7..5bb1b315cd 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -90,4 +90,4 @@ obj-$(CONFIG_K3_AVS0) += k3_avs.o
obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
-obj-$(CONFIG_SPL_SOCFPGA_SEC_REG) += socfpga_dtreg.o
+obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
--
2.25.1
Re: [PATCH] net: ti: am65-cpsw-nuss: Don't crash in am65_cpsw_phy_init()
On Wed, Mar 27, 2024 at 06:09:40PM +0100, A. Sverdlin wrote:
> From: Alexander Sverdlin
In the $subject, "Don't crash.." seems to indicate the consequence of
not handling the absence of PHYs gracefully within am65_cpsw_phy_init().
So the subject should probably be reworded to emphasize this instead.
Something like:
net: ti: am65-cpsw-nuss: Update am65_cpsw_phy_init() to handle PHY absence
The rest of the patch looks good to me. With the subject reworded,
Reviewed-by: Siddharth Vadapalli
Regards,
Siddharth.
>
> am65_cpsw_ofdata_parse_phy() tries to handle the case when PHY is not
> specified in DT gracefully:
>
> am65_cpsw_nuss_port ethernet@800port@1: can't parse phy-handle port 1 (-2)
>
> am65_cpsw_mdio_init() is turn is prepared for this, checks
> if priv->has_phy == 0 and bails out (leaving cpsw_common->bus == NULL).
>
> am65_cpsw_phy_init() however is not prepared for this and calls
> phy_connect(cpsw_common->bus, ...) unconditionally, which leads to:
>
> "Synchronous Abort" handler, esr 0x860d, far 0x0
> elr: 808ab000 lr : 8083bde4 (reloc)
>
> where lr points to the instruction right after bus->read() in get_phy_id().
>
> Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
> subsystem driver")
> Signed-off-by: Alexander Sverdlin
> ---
> drivers/net/ti/am65-cpsw-nuss.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
> index 6da018c0f9d5..d1e452b6b43c 100644
> --- a/drivers/net/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ti/am65-cpsw-nuss.c
> @@ -722,6 +722,9 @@ static int am65_cpsw_phy_init(struct udevice *dev)
> u32 supported = PHY_GBIT_FEATURES;
> int ret;
>
> + if (!priv->has_phy || !cpsw_common->bus)
> + return 0;
> +
> phydev = phy_connect(cpsw_common->bus,
>priv->phy_addr,
>priv->dev,
> --
> 2.44.0
>
[PATCH v4 5/5] imx93: convert to OF_UPSTREAM
From: Peng Fan
Convert all i.MX93 boards to OF_UPSTREAM.
Add lpi2c2 nodes for imx93-11x11-evk-u-boot.dtsi.
Add usbotg1 nodes in imx93-u-boot.dtsi and board u-boot.dtsi.
The nodes could be removed after upstream linux supports them.
Signed-off-by: Peng Fan
---
arch/arm/dts/Makefile | 5 -
arch/arm/dts/imx93-11x11-evk-u-boot.dtsi| 119
arch/arm/dts/imx93-11x11-evk.dts| 322 -
arch/arm/dts/imx93-phyboard-segin.dts | 117 ---
arch/arm/dts/imx93-phycore-som.dtsi | 126
arch/arm/dts/imx93-pinfunc.h| 623
arch/arm/dts/imx93-u-boot.dtsi | 80 +++
arch/arm/dts/imx93-var-som-symphony-u-boot.dtsi | 22 +
arch/arm/dts/imx93-var-som-symphony.dts | 323 -
arch/arm/dts/imx93-var-som.dtsi | 111 ---
arch/arm/dts/imx93.dtsi | 906
arch/arm/mach-imx/imx9/Kconfig | 1 +
configs/imx93-phyboard-segin_defconfig | 2 +-
configs/imx93_11x11_evk_defconfig | 2 +-
configs/imx93_11x11_evk_ld_defconfig| 2 +-
configs/imx93_var_som_defconfig | 2 +-
include/dt-bindings/clock/imx93-clock.h | 208 --
include/dt-bindings/power/fsl,imx93-power.h | 15 -
18 files changed, 226 insertions(+), 2760 deletions(-)
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d85a33055c9..75d9ee06bbf 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1114,11 +1114,6 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mq-kontron-pitx-imx8m.dtb \
imx8mq-librem5-r4.dtb
-dtb-$(CONFIG_ARCH_IMX9) += \
- imx93-11x11-evk.dtb \
- imx93-var-som-symphony.dtb \
- imx93-phyboard-segin.dtb
-
dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
imxrt1170-evk.dtb \
diff --git a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
index a99ba99bfb4..4a834ded44c 100644
--- a/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx93-11x11-evk-u-boot.dtsi
@@ -26,6 +26,112 @@
bootph-pre-ram;
};
+/* The node should be removed after upstream supports it */
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <40>;
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <_lpi2c2>;
+ pinctrl-1 = <_lpi2c2>;
+ status = "okay";
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+ interrupt-parent = <>;
+ interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <65>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4{
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5{
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <60>;
+ regulator-max-microvolt = <340>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <160>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+
Re: [RFC] Makefile.lib: find capsule ESL dtsi file when CONFIG_OF_UPSTREAM=y
Sughosh Ganu writes:
> hi Jonathan,
>
> On Wed, 27 Mar 2024 at 08:05, Jonathan Humphreys wrote:
>>
>> When CONFIG_OF_UPSTREAM is enabled, DTS files are in SOC subdirectories (vs
>> the
>> top level dts directory), but when CONFIG_EFI_CAPSULE_AUTHENTICATE is
>> enabled,
>> the dynamically created dtsi file containing the capsule ESL DT node is in
>> the
>> parent directory. This results in a build failure because the #include
>> inserted
>> in the DTS file is local to the current directory. Update Makefile to have
>> the
>> DT preprocessing of #includes search in the parent (dts top level) directory
>> too.
>>
>> I'm not sure if this is the best solution.
>>
>> I was also tempted to just manually include the capsule-key property in the
>> board dts, and avoid the Makefile implicit inclusion trickery. I would
>> actually
>> prefer this approach as everything is more explicit. But this isn't an
>> option
>> because if CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled, the implicit
>> inclusion of
>> the dtsi file happens. It would be better, IMO, if we only included the
>> generated dtsi file if CONFIG_EFI_CAPSULE_ESL_FILE is defined. Was only
>> supporting the implicit inclusiong approach an intentional design choice?
>
> I was not sure if users would want to manually insert the contents of
> the ESL file, which is a binary file(a few hundred bytes at least)
> into the DTS. If you prefer having such an option, we can change the
> logic to what you propose. Thanks.
What I was thinking is that one would explictly add the capsule-key
property to the board dts but do it just as the generated dtsi does
where it references the .esl file.
Jon
>
> -sughosh
>
>>
>> Thanks
>> Jon
>>
>> Signed-off-by: Jonathan Humphreys
>> ---
>> scripts/Makefile.lib | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
>> index 12857316c58..62f87517c09 100644
>> --- a/scripts/Makefile.lib
>> +++ b/scripts/Makefile.lib
>> @@ -334,7 +334,7 @@ cmd_dtc = mkdir -p $(dir ${dtc-tmp}) ; \
>> (cat $< > $(pre-tmp)); \
>> $(foreach f,$(subst $(quote),,$(dtsi_include_list)), \
>> echo '$(pound)include "$(f)"' >> $(pre-tmp);) \
>> - $(HOSTCC) -E $(dtc_cpp_flags) -x assembler-with-cpp -o $(dtc-tmp)
>> $(pre-tmp) ; \
>> + $(HOSTCC) -E $(dtc_cpp_flags) -I$(obj) -x assembler-with-cpp -o
>> $(dtc-tmp) $(pre-tmp) ; \
>> $(DTC) -O dtb -o $@ -b 0 \
>> -i $(dir $<) -i $(u_boot_dtsi_loc) $(DTC_FLAGS) \
>> -d $(depfile).dtc.tmp $(dtc-tmp) || \
>> --
>> 2.34.1
>>
Re: [PATCH u-boot-mvebu v3 11/18] arm: mvebu: system-controller: Add support for SYSRESET
On Thu, 28 Mar 2024 11:04:45 +0100
Stefan Roese wrote:
> > +static int mvebu_sysreset_request(struct udevice *dev, enum sysreset_t
> > type)
> > +{
> > + struct regmap *regmap = syscon_get_regmap(dev->parent);
> > + uint bit;
> > +
> > + if (type != SYSRESET_COLD)
> > + return -EPROTONOSUPPORT;
> > +
> > + bit = MVEBU_GLOBAL_SOFT_RST_BIT;
> > +
> > + regmap_update_bits(regmap, MVEBU_RSTOUTN_MASK_REG, bit, bit);
> > + regmap_update_bits(regmap, MVEBU_SYS_SOFT_RST_REG, bit, bit);
> > +
> > + while (1)
> > + ;
>
> A comment before this endless loop might be helpful here.
The code does the same as reset_cpu() in cpu.c, and the while() cycle
is not commented there.
But we can add something like
/* something has gone wrong if we reach here, so we may as well stay
* here */
What do you think? Could you amend the patch?
Marek
Re: [PATCH 3/4] arm: dts: k3-*-binman.dtsi: Clean up and templatize boot binaries
Hi Michael
On 27-Mar-24 8:03 PM, Michael Walle wrote:
Hi,
On Wed Mar 27, 2024 at 8:01 AM CET, Neha Malcom Francis wrote:
On 26/03/24 19:18, Michael Walle wrote:
On Fri Mar 22, 2024 at 2:10 PM CET, Neha Malcom Francis wrote:
Clean up templatized boot binaries for all K3 boards. This includes
modifying the k3-binman.dtsi to use SPL_BOARD_DTB, BOARD_DESCRIPTION and
UBOOT_BOARD_DESCRIPTION from the files that include it to further reuse
code.
All k3--binman.dtsi will contain only templates. Only required boot
binaries can be built from the templates in the boards' respective
-u-boot.dtsi file (or k3--binman.dtsi if it exists). This allows
clear distinction between the SoC common stuff vs. what is additionally
needed to boot up a specific board.
I appreciate the cleanup. But as far as I can see, a board might
only have one device tree. How would that work if the uboot proper
must support multiple device trees?
From the discussions that took place in the mailing list [1] the consensus
seems to be to not focus on multiple devicetree support as it leads to confusion
for downstream users.
What are users in this regard? I don't think you'd confuse
developers.
Anyway, I'm planning on upstreaming a TI board which will have
different memory configurations and different variants of the board.
I am assuming you are reusing an existing TI SoC?
And on top of that, it will just be a base board and there will
likely be some carrier device trees (overlay? I'm not sure yet).
As far as I can tell, you've put the memory configuration into the
device tree, so I'll probably need to switch between them somehow.
The "k3--ddr.dtsi" file will be present in your k3-r5.dts
which makes sense, the memory configuration depends on the board.
Also, regarding the board variants, I'll probably need to choose
between multiple device trees. That is invisible to the user,
because u-boot will choose the correct DTB according a board
strapping, which btw. works really fine, see for example
(boards/kontron/sl28/spl.c:board_fit_config_name_match).
Again, this is assuming that there is some HW blown register available
for the board to use (or in our earlier K3 case, the EEPROM) but that is
not necessarily true every time.
I don't think it makes much sense to hardcode your generic
*-binman.dtsi to just one FIT configuration. I'd rather see a split
between generic things which are shared across all boards and board
specifics, like the FIT configuration. I mean I could just copy all
Correct me if I'm wrong, but my understanding is that you would want to
add more FDT blobs in the *-binman.dtsi correct? That is still possible,
adding another "fdt-1" and "conf-1" in the
Something like this in your -u-boot.dtsi,
tispl {
insert-template = <_spl>;
fit {
images {
fdt-1 {
...
};
};
configurations {
conf-1 {
...
};
};
};
};
provided you have the support to handle this multi-dtb FIT. But as far
as reusing the k3-binman.dtsi and k3--binman.dtsi goes; you should
be able to do it.
the binman and tiboot3.bin and tispl.bin magic and put it into my
own "-u-boot.dtsi". But I'm not sure that will make things any
better.
-michael
--
Thanking You
Neha Malcom Francis
Re: [PATCH u-boot-mvebu v3 05/18] arm: mvebu: turris_omnia: Implement getting board information from MCU
On Thu, 28 Mar 2024 10:56:01 +0100
Stefan Roese wrote:
> On 3/27/24 17:23, Marek Behún wrote:
> > Implement reading board serial number, first MAC address and board
> > version from MCU. MCU supports board information if the FEAT_BOARD_INFO
> > feature bit is set in MCU features.
> >
> > Prefer getting board information from MCU if supported, fallback to
> > Atmel SHA chip.
> >
> > Signed-off-by: Marek Behún
>
> Minor comment below. Other than this:
>
> Reviewed-by: Stefan Roese
>
> Thanks,
> Stefan
>
> > ---
> > board/CZ.NIC/turris_atsha_otp.c | 27 +--
> > board/CZ.NIC/turris_omnia/Makefile | 2 +-
> > board/CZ.NIC/turris_omnia/turris_omnia.c | 94 +++-
> > 3 files changed, 93 insertions(+), 30 deletions(-)
> >
> > diff --git a/board/CZ.NIC/turris_atsha_otp.c
> > b/board/CZ.NIC/turris_atsha_otp.c
> > index a29fe36231..85eebcdf18 100644
> > --- a/board/CZ.NIC/turris_atsha_otp.c
> > +++ b/board/CZ.NIC/turris_atsha_otp.c
> > @@ -11,6 +11,7 @@
> > #include
> >
> > #include "turris_atsha_otp.h"
> > +#include "turris_common.h"
> >
> > #define TURRIS_ATSHA_OTP_VERSION 0
> > #define TURRIS_ATSHA_OTP_SERIAL 1
> > @@ -32,26 +33,6 @@ static struct udevice *get_atsha204a_dev(void)
> > return dev;
> > }
> >
> > -static void increment_mac(u8 *mac)
> > -{
> > - int i;
> > -
> > - for (i = 5; i >= 3; i--) {
> > - mac[i] += 1;
> > - if (mac[i])
> > - break;
> > - }
> > -}
> > -
> > -static void set_mac_if_invalid(int i, u8 *mac)
> > -{
> > - u8 oldmac[6];
> > -
> > - if (is_valid_ethaddr(mac) &&
> > - !eth_env_get_enetaddr_by_index("eth", i, oldmac))
> > - eth_env_set_enetaddr_by_index("eth", i, mac);
> > -}
> > -
> > int turris_atsha_otp_init_mac_addresses(int first_idx)
> > {
> > struct udevice *dev = get_atsha204a_dev();
> > @@ -84,11 +65,7 @@ int turris_atsha_otp_init_mac_addresses(int first_idx)
> > mac[4] = mac1[2];
> > mac[5] = mac1[3];
> >
> > - set_mac_if_invalid((first_idx + 0) % 3, mac);
> > - increment_mac(mac);
> > - set_mac_if_invalid((first_idx + 1) % 3, mac);
> > - increment_mac(mac);
> > - set_mac_if_invalid((first_idx + 2) % 3, mac);
> > + turris_init_mac_addresses(first_idx, mac);
> >
> > return 0;
> > }
> > diff --git a/board/CZ.NIC/turris_omnia/Makefile
> > b/board/CZ.NIC/turris_omnia/Makefile
> > index dc39b44ae1..341378b4e5 100644
> > --- a/board/CZ.NIC/turris_omnia/Makefile
> > +++ b/board/CZ.NIC/turris_omnia/Makefile
> > @@ -2,4 +2,4 @@
> > #
> > # Copyright (C) 2017 Marek Behún
> >
> > -obj-y := turris_omnia.o ../turris_atsha_otp.o
> > +obj-y := turris_omnia.o ../turris_atsha_otp.o ../turris_common.o
> > diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
> > b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > index 6dfde5ee7a..f63640ad64 100644
> > --- a/board/CZ.NIC/turris_omnia/turris_omnia.c
> > +++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
> > @@ -18,6 +18,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -25,12 +26,14 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> >
> > #include "../drivers/ddr/marvell/a38x/ddr3_init.h"
> > #include <../serdes/a38x/high_speed_env_spec.h>
> > #include "../turris_atsha_otp.h"
> > +#include "../turris_common.h"
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -186,6 +189,70 @@ static bool omnia_mcu_has_feature(u32 feature)
> > return feature & features;
> > }
> >
> > +static u32 omnia_mcu_crc32(const void *p, size_t len)
> > +{
> > + u32 val, crc = 0;
> > +
> > + compiletime_assert(!(len % 4), "length has to be a multiple of 4");
> > +
> > + while (len) {
> > + val = bitrev32(get_unaligned_le32(p));
> > + crc = crc32(crc, (void *), 4);
> > + p += 4;
> > + len -= 4;
> > + }
> > +
> > + return ~bitrev32(crc);
> > +}
> > +
> > +/* Can only be called after relocation, since it needs cleared BSS */
> > +static int omnia_mcu_board_info(char *serial, u8 *mac, char *version)
> > +{
> > + static u8 reply[17];
> > + static bool cached;
> > +
> > + if (!cached) {
> > + u8 csum;
> > + int ret;
> > +
> > + ret = omnia_mcu_read(CMD_BOARD_INFO_GET, reply, sizeof(reply));
> > + if (ret)
> > + return ret;
> > +
> > + if (reply[0] != 16)
> > + return -EBADMSG;
> > +
> > + csum = reply[16];
> > + reply[16] = 0;
> > +
> > + if ((omnia_mcu_crc32([1], 16) & 0xff) != csum)
> > + return -EBADMSG;
> > +
> > + cached = true;
> > + }
> > +
> > + if (serial) {
> > + const char *serial_env;
> > +
> > + serial_env = env_get("serial#");
> > + if (serial_env && strlen(serial_env) == 16) {
> > +
[PATCH] net: fec_mxc: Avoid enable regulator failure
Change to regulator_set_enable_if_allowed to avoid enable failure,
in case same phy supply shared by multiple FEC controllers.
Signed-off-by: Ye Li
---
drivers/net/fec_mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index ac93767..90af18f 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1310,7 +1310,7 @@ static int fecmxc_probe(struct udevice *dev)
#ifdef CONFIG_DM_REGULATOR
if (priv->phy_supply) {
- ret = regulator_set_enable(priv->phy_supply, true);
+ ret = regulator_set_enable_if_allowed(priv->phy_supply, true);
if (ret) {
printf("%s: Error enabling phy supply\n", dev->name);
return ret;
--
2.7.4
[PATCH] arm: imx: Fix incorrect return value
The spl_spi_get_uboot_offs weak function is defined unsigned int.
Signed-off-by: Ye Li
---
arch/arm/mach-imx/image-container.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/image-container.c
b/arch/arm/mach-imx/image-container.c
index c9455fe..35da0ae 100644
--- a/arch/arm/mach-imx/image-container.c
+++ b/arch/arm/mach-imx/image-container.c
@@ -262,7 +262,7 @@ static int get_imageset_end(void *dev, int dev_type)
}
#ifdef CONFIG_SPL_SPI_LOAD
-unsigned long spl_spi_get_uboot_offs(struct spi_flash *flash)
+unsigned int spl_spi_get_uboot_offs(struct spi_flash *flash)
{
int end;
--
2.7.4
[PATCH] thermal: imx_tmu: Fix TMU error on iMX8MQ
imx_tmu_arch_init does not implement for iMX8MQ, error is returned
Signed-off-by: Ye Li
---
drivers/thermal/imx_tmu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/thermal/imx_tmu.c b/drivers/thermal/imx_tmu.c
index 4721cfb..ca775e5 100644
--- a/drivers/thermal/imx_tmu.c
+++ b/drivers/thermal/imx_tmu.c
@@ -402,6 +402,7 @@ static inline void imx_tmu_mx8mp_init(struct udevice *dev)
{ }
#endif
static inline void imx_tmu_mx93_init(struct udevice *dev) { }
+static inline void imx_tmu_mx8mq_init(struct udevice *dev) { }
static void imx_tmu_arch_init(struct udevice *dev)
{
@@ -411,6 +412,8 @@ static void imx_tmu_arch_init(struct udevice *dev)
imx_tmu_mx8mp_init(dev);
else if (is_imx93())
imx_tmu_mx93_init(dev);
+ else if (is_imx8mq())
+ imx_tmu_mx8mq_init(dev);
else
dev_err(dev, "Unsupported SoC, TMU calibration not loaded!\n");
}
--
2.7.4
[PATCH] arm: imx9: Fix MMU map table overlap
The size for flexspi AHB buffer space is wrong, so correct it.
Signed-off-by: Ye Li
---
arch/arm/mach-imx/imx9/soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c
index 15e87b8..2117489 100644
--- a/arch/arm/mach-imx/imx9/soc.c
+++ b/arch/arm/mach-imx/imx9/soc.c
@@ -262,7 +262,7 @@ static struct mm_region imx93_mem_map[] = {
/* Flexible Serial Peripheral Interface */
.virt = 0x2800UL,
.phys = 0x2800UL,
- .size = 0x3000UL,
+ .size = 0x0800UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
PTE_BLOCK_NON_SHARE |
PTE_BLOCK_PXN | PTE_BLOCK_UXN
--
2.7.4
[PATCH 2/2] arm: imx9: Call imx9_probe_mu for DM post in board_r
This event callback imx9_probe_mu needs to be called in board_r
as well, because many ELE APIs depending on this MU probed
Signed-off-by: Ye Li
---
arch/arm/mach-imx/imx9/soc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-imx/imx9/soc.c b/arch/arm/mach-imx/imx9/soc.c
index f06339f..15e87b8 100644
--- a/arch/arm/mach-imx/imx9/soc.c
+++ b/arch/arm/mach-imx/imx9/soc.c
@@ -622,6 +622,7 @@ int imx9_probe_mu(void)
return 0;
}
EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_F, imx9_probe_mu);
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_R, imx9_probe_mu);
int timer_init(void)
{
--
2.7.4
[PATCH 1/2] arm: imx9: Correct imx9_probe_mu prototype
Since the event callback imx9_probe_mu is re-defined, update
its prototype.
Signed-off-by: Ye Li
---
arch/arm/include/asm/arch-imx9/mu.h | 2 +-
board/freescale/imx93_evk/spl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-imx9/mu.h
b/arch/arm/include/asm/arch-imx9/mu.h
index b860499..649b8a6 100644
--- a/arch/arm/include/asm/arch-imx9/mu.h
+++ b/arch/arm/include/asm/arch-imx9/mu.h
@@ -8,6 +8,6 @@
#include
-int imx9_probe_mu(void *ctx, struct event *event);
+int imx9_probe_mu(void);
#endif
diff --git a/board/freescale/imx93_evk/spl.c b/board/freescale/imx93_evk/spl.c
index 2fd5559..7331a20 100644
--- a/board/freescale/imx93_evk/spl.c
+++ b/board/freescale/imx93_evk/spl.c
@@ -116,7 +116,7 @@ void board_init_f(ulong dummy)
preloader_console_init();
- ret = imx9_probe_mu(NULL, NULL);
+ ret = imx9_probe_mu();
if (ret) {
printf("Fail to init Sentinel API\n");
} else {
--
2.7.4
[PATCH v2 3/3] configs: colibri-imx7: allow accessing job-rings from non-TrustZone
From: Emanuele Ghidoli Set FSL_CAAM_JR_NTZ_ACCESS configuration since colibri-imx7 uses Freescale CAAM Job Ring linux driver Signed-off-by: Emanuele Ghidoli --- configs/colibri_imx7_defconfig | 1 + configs/colibri_imx7_emmc_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig index 0c6a272ddfc6..16f923b07c22 100644 --- a/configs/colibri_imx7_defconfig +++ b/configs/colibri_imx7_defconfig @@ -72,6 +72,7 @@ CONFIG_SERVERIP="192.168.10.1" CONFIG_BOUNCE_BUFFER=y CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y +CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y CONFIG_DFU_NAND=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x8110 diff --git a/configs/colibri_imx7_emmc_defconfig b/configs/colibri_imx7_emmc_defconfig index 8dd9fe6e6a38..7c6a725ea9a2 100644 --- a/configs/colibri_imx7_emmc_defconfig +++ b/configs/colibri_imx7_emmc_defconfig @@ -61,6 +61,7 @@ CONFIG_USE_SERVERIP=y CONFIG_SERVERIP="192.168.10.1" CONFIG_BOOTCOUNT_LIMIT=y CONFIG_BOOTCOUNT_ENV=y +CONFIG_FSL_CAAM_JR_NTZ_ACCESS=y CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_BUF_ADDR=0x8110 CONFIG_FASTBOOT_FLASH=y -- 2.34.1
