Re: [PATCH v1 3/3] board: microchip: set mac address for ethernet1 on icicle
On Tue, Jun 13, 2023 at 05:35:58AM +, padmarao.beg...@microchip.com wrote:
> On Wed, 2023-06-07 at 11:06 +0100, Conor Dooley wrote:
> > @@ -123,6 +123,15 @@ int board_late_init(void)
> >
> > mac_addr[5] = device_serial_number[0] + 1;
> >
> > + node = fdt_path_offset(blob, "/soc/ethernet@2011");
> > + if (node >= 0) {
> > + ret = fdt_setprop(blob, node, "local-mac-address",
> > mac_addr, 6);
> > + if (ret) {
> > + printf("Error setting local-mac-address
> > property for ethernet@20112000\n");
> The print error is for ethernet@2011 not ethernet@20112000.
Ah, good spot, thanks. I'll fix that up and resubmit.
Thanks,
Conor.
signature.asc
Description: PGP signature
Re: [RFC] disable NFS support by default
On Wed, Jun 14, 2023 at 12:34 AM Bin Meng wrote: > > On Wed, Jun 14, 2023 at 2:41 AM Tom Rini wrote: > > > > On Tue, Jun 13, 2023 at 11:52:16AM +0100, Peter Robinson wrote: > > > > > While NFS is widely used in data centres, and private > > > networks it's quite a nuanced usecase for device firmware. > > > A lot of devices already disable it. > > > > > > Various network protocols should really be opt in, not opt > > > out, because they add extra size and are potential attack > > > vectors from a security PoV. In the NFS case it doesn't > > > really make sense for a lot of devices like tables, SBCs etc. > > > It's also something we don't really want for SystemReady-IR > > > due to security concerns. > > > > > > Signed-off-by: Peter Robinson > > > --- > > > > > > This is a RFC to start a discussion around things like NFS, > > > with the addistion of old protocols like NFSv1 that were never > > > publicly released [1] we really shouldn't be enabling this by > > > default. > > > > > > I am aware it will likely break the functionality for users > > > that do use the various versions of NFS but it's straight forward > > > to add CMD_NFS as an explicit config. It's for this reason I > > > label the patch as RFC. > > > > > > There was about a 5Kb saving here when I tested a build with > > > pinebook-pro-rk3399. > > > > > > Peter > > > > > > [1] https://en.wikipedia.org/wiki/Network_File_System > > [snip] > > > > This is probably fine, honestly. I don't see any environments that > > default to making use of NFS within U-Boot (which is not the same as > > nfsroot for Linux, which a number of platforms have options for by > > default). > > > > How about changing > > config CMD_NFS > bool "nfs" > default y > help > Boot image via network using NFS protocol. > > To > > default n ? The defaut is n so just removing it has the same effect, and that's what most, but not all, things do. See CMD_RARP in the same list. Peter
Re: [PATCH v2 5/5] rockchip: rockpro64: Build u-boot-rockchip-spi.bin
On Tue, Jun 13, 2023 at 7:48 PM Jonas Karlman wrote: > > Hi Peter, > > On 2023-06-13 09:58, Peter Robinson wrote: > > On Mon, Jun 12, 2023 at 11:20 PM Jonas Karlman wrote: > >> > >> Hi Peter, > >> > >> On 2023-06-11 22:22, Peter Robinson wrote: > >>> Hi Jonas, > >>> > >>> This regresses the Rockpro64 build for me when building with gcc 12/13 > >>> with the following error, if I remove CONFIG_LTO it builds, but > >>> overlaps. > >>> > >>> /usr/bin/aarch64-linux-gnu-ld: > >>> /usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function > >>> `init_have_lse_atomics': > >>> /builddir/build/BUILD/gcc-13.1.1-20230519/aarch64-linux-gnu/aarch64-linux-gnu/libgcc/../../../gcc-13.1.1-20230519/libgcc/config/aarch64/lse-init.c:46: > >>> undefined reference to `__getauxval' > >>> collect2: fatal error: ld terminated with signal 11 [Segmentation > >>> fault], core dumped > >>> compilation terminated. > >> > >> Interesting, my test build using ubuntu-22.04 and gcc-12 did not seem > >> to fail, see [1]. Compiling with -mno-outline-atomics flag may work, not > >> sure that is a good workaround. > > > > I would prefer a fix. > > Not sure what such fix could be, cross compiling in CI and under ubuntu > 22.04 does not trigger this linking issue, not sure what is different in > your build environment to not allow build with CONFIG_LTO=y. > > Searching for similar linking issue suggest it could be related to > outline-atomics, do you use any special C/LDFLAGS or similar? > > > > >> An alternative could be to move the payload to @ 512KB instead of @ 384KB. > > > > What impact will moving this around have on upgrades? I am not sure we > > should be randomly moving stuff without knowing the impact TBH. Will > > this break existing users vs what you feel is appropriate for your > > usecase? > > I did a re-calculation and using @ 512 KB offset may not be enough > for a worst-case scenario. > > mkimage will enforce a 184 KB limit for the TPL on RK3399. With SPL > loaded at 0x0 and TF-A loaded to 0x4, we have a 256 KB size limit of > SPL. BootRom that loads both TPL and SPL only read first 2 KB of every > 4 KB page of SPI flash, so idbloader.img (TPL+SPL) could grow up to > ~880 KB in a worst-case scenario. (184+256) x 2 = 880 > > Using a payload offset of @ 896 KB (0xE) is probably the safest > default option if we need to revert the CONFIG_LTO=y change. > > As long as u-boot-rockchip-spi.bin is used to update SPI flash changing > offset should not have an impact. However, there are guides and scripts > that write idbloader.img and u-boot.itb separately, those could break. Well I believe your patch only enabled that option by default so most users I suspect write them separately up until now, does the new offsets affect existing env variables at all? > Such guides and scripts can already lead to users overwriting part of > SPL when the produced idbloader.img is over 384 KB in size. > With CONFIG_ROCKCHIP_SPI_IMAGE=y the size of idbloader.img is instead > enforced to not cause an overlap of the u-boot.itb at build time. Ultimately I would prefer to not actively break existing users if they're not aware of changes, and that is hard to communicate. People with broken devices tend to scream a lot. > Regards, > Jonas > > > > >> configs/rockpro64-rk3399_defconfig: > >> CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 > >> > >> arch/arm/dts/rk3399-rockpro64-u-boot.dtsi: > >> u-boot,spl-payload-offset = <0x8>; > >> > >> > >> [1] > >> https://github.com/Kwiboo/u-boot-build/actions/runs/5248398191/jobs/9479827969 > >> > >> Regards, > >> Jonas > >> > >>> > >>> Peter > >>> > >>> On Wed, May 17, 2023 at 7:41 PM Jonas Karlman wrote: > > Enable CONFIG_ROCKCHIP_SPI_IMAGE to build u-boot-rockchip-spi.bin. > Define CONFIG_SYS_SPI_U_BOOT_OFFS to write u-boot.itb at the expected > offset. Enable CONFIG_LTO to reduce size of SPL so that the mkimage > output fit before the 0x6 offset in u-boot-rockchip-spi.bin. > > => sf probe > SF: Detected gd25q128 with page size 256 Bytes, erase size 4 KiB, > total 16 MiB > => load mmc 1:1 1000 u-boot-rockchip-spi.bin > 1442304 bytes read in 27 ms (50.9 MiB/s) > => sf update $fileaddr 0 $filesize > device 0 offset 0x0, size 0x160200 > 1421824 bytes written, 20480 bytes skipped in 9.501s, speed 155432 B/s > > Signed-off-by: Jonas Karlman > Reviewed-by: Kever Yang > --- > v2: > - Collect r-b tag > > configs/rockpro64-rk3399_defconfig | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/configs/rockpro64-rk3399_defconfig > b/configs/rockpro64-rk3399_defconfig > index 0ca2cecade25..f41c03067903 100644 > --- a/configs/rockpro64-rk3399_defconfig > +++ b/configs/rockpro64-rk3399_defconfig > @@ -11,6 +11,7 @@ CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-rockpro64" > CONFIG_DM_RESET=y > CONFIG_R
Re: [SPAM] Re: [PATCH] cmd: usb: Prevent reset in usb tree/info command
Thanks for explaining, Simon Glass.
Can someone please stop me if I'm splitting hairs or bikeshedding or
something ? I guess we agree both checking for null or UCLASS_BOOTDEV
would work right now but we are looking for what's more future-proof.
El Tue, Jun 13, 2023 at 09:12:30PM +0100, Simon Glass deia:
> Hi Xavier,
>
> On Tue, 13 Jun 2023 at 17:04, Xavier Drudis Ferran wrote:
> >
> > El Tue, Jun 13, 2023 at 03:58:22PM +0100, Simon Glass deia:
> > >
> > > Yes that's right. So 'usb info' should ignore UCLASS_BOOTDEV devices.
> >
> > That's a possibility, yes. It should work until someone adds another
> > device there for some other purpose.
> >
> > > That is better than checking for the NULL pointer.
> > >
> >
> > Why? What's wrong about checking for null ?
> > Or maybe checking for both not null and not UCLASS_BOOTDEV ?
> >
> > Not that I care too much, just to understand your reasoning.
>
> Well, devices may have something attached there, so it may be
> non-NULL, but point to a different struct from the expected one.
>
Yes. That is possible. How likely ?
That "there" is dev_get_parent_priv(). If I understand the driver
model, those devices shouldn't put things there themselves, it should
be their parent who puts stuff there for them. And the parent should
be an usb_device->dev (because of the recursive code). So what other
struct would such a parent put in a child parent_priv_ ? Yes, whatever
it wants, but I mean, isn't it likely to assume the child would be
"adopted" with null as parent_priv_ or a "natural child" with a usb_device
in parent_priv_ ?
I did a very rough search
grep -rIE 'UCLASS_(BLK|BOOTDEV|USB_EMUL)' . |grep -F .id |cut -f1 -d: |xargs
-n 1 grep -l per_child_auto
./drivers/usb/emul/usb-emul-uclass.c
Which seems to suggest only UCLASS_USB_EMUL would have parent_priv_,
and that would be an usb_device, which the current code does not want
to recurse anyway. (dev_set_parent_priv() is almost never called).
It is also possible that one day a device that is not UCLASS_BLK,
UCLASS_BOOTDEV or UCLASS_USB_EMUL is put as children of a usb storage
device (just imagine a future system similar to bootstd for firmware
updates, trust material, etc.). Is it likely to have a struct in
parent_priv_ that is not a usb_device ?
So which is more likely to survive future changes ?
- checking for parent_priv_ not null and not UCLASS_USB_EMUL
- checking for parent_priv_ not null and not UCLASS_USB_EMUL and not UCLASS_BLK
(my patch, overcautious ?)
- checking for not (UCLASS_BLK, UCLASS_BOOTDEV or UCLASS_USB_EMUL)
(Simon Glass' idea)
- checking for not UCLASS_BLK and not UCLASS_BOOTDEV and not UCLASS_USB_EMUL
and parent_priv_ not null
> >
> > Or can we check for recursible devices somehow ?
> > Maybe flag them or something ?
> >
> > Why is better to state all devices are recursible except some UCLASSes
> > (meaning they can have stuff that needs listed in usb info - or
> > likewise usb tree -) instead of stating that some closed set are
> > recursible ?
> >
>
> For USB we can have lots of different types of devices as children, so
> it would be a pain to enumerate them all. At least that's how I see
> it.
>
We can have lots of devices as children, but those do get listed
before the recursive call. How many of those can have children that
we have to list too, i.e. how many of those do we want to recurse
into ?
I can only think of usb hubs (maybe some node for multifunction
devices too ???). Maybe I'm not understanding how U-Boot works with
USB devices... but it looks like it would be enough to look for
UCLASS_USB_HUB, then recursive call, else no recursion. I mean instead of
cmd/usb.c : usb_show_tree_graph() :
if ((device_get_uclass_id( child ) != UCLASS_USB_EMUL) &&
(device_get_uclass_id( child ) != UCLASS_BOOTDEV) &&
(device_get_uclass_id( child ) != UCLASS_BLK)) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
}
we could simply have
if (device_get_uclass_id( dev->dev ) == UCLASS_USB_HUB) {
usb_show_tree_graph(udev, pre);
pre[index] = 0;
}
(or put the condition directly before the for loop)
Or can we have an UCLASS_USB_EMUL, UCLASS_BLK or UCLASS_BOOTDEV as
direct child of an UCLASS_USB_HUB ???
Am I opening any cans of worms ?
[PATCH v1] colibri_imx6: fix RALAT and WALAT values
From: Stefan Eichenberger
Running a memtest in U-Boot and Linux shows that some Colibri iMX6
produce bitflips at temperatures above 60°C. This happens because the
RALAT and WALAT values on the Colibri iMX6 are too low. The problems
were introduced by commit 09dbac8174c4 ("mx6: ddr: Restore ralat/walat
in write level calibration") before the calibration process overwrote
the values and set them to the maximum value. With this commit, we make
sure that the RALAT and WALAT values are set to the maximum values
again. This has been proven to work for years.
Fixes: 09dbac8174c4 ("mx6: ddr: Restore ralat/walat in write level calibration")
Signed-off-by: Stefan Eichenberger
Signed-off-by: Francesco Dolcini
---
board/toradex/colibri_imx6/colibri_imx6.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/board/toradex/colibri_imx6/colibri_imx6.c
b/board/toradex/colibri_imx6/colibri_imx6.c
index 65e0e9a156ab..677caa4a4ebc 100644
--- a/board/toradex/colibri_imx6/colibri_imx6.c
+++ b/board/toradex/colibri_imx6/colibri_imx6.c
@@ -767,8 +767,7 @@ MX6_MMDC_P1_MPRDDQBY3DL, 0x,
/*
* MDMISC mirroring interleaved (row/bank/col)
*/
-/* TODO: check what the RALAT field does */
-MX6_MMDC_P0_MDMISC, 0x00081740,
+MX6_MMDC_P0_MDMISC, 0x000b17c0,
/*
* MDSCR con_req
@@ -900,8 +899,7 @@ MX6_MMDC_P1_MPRDDQBY3DL, 0x,
/*
* MDMISC mirroring interleaved (row/bank/col)
*/
-/* TODO: check what the RALAT field does */
-MX6_MMDC_P0_MDMISC, 0x00081740,
+MX6_MMDC_P0_MDMISC, 0x000b17c0,
/*
* MDSCR con_req
--
2.25.1
[PATCH v2 0/6] Fix sparse warnings in zynq platform
Fix below sparse warnings - Add missing prototype for zynqmp_mmio_write - Add missing prototype for zynq_qspi_mem_exec_op - Change datatype of status and ecc_status from u32 to int - Pass the missing argument type in function definition - Add the missing function prototypes - Add missing prototype for xilinx_qspi_mem_exec_op Changes in v2: - Move prototype declaration from sys_proto.h to include/zynqmp_firmware.h - Added argument void in below files to fix warning board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c board/xilinx/zynq/zynq-zed/ps7_init_gpl.c Algapally Santosh Sagar (6): spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op xilinx: zynq: Add missing prototype for zynqmp_mmio_write spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op mtd: nand: zynq_nand: Change datatype of status and ecc_status to int arm: zynq: Pass the missing argument type in function definition xilinx: zynq: Add the missing function prototypes board/xilinx/zynq/board.c | 2 ++ board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c | 4 ++-- board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c| 4 ++-- board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c| 4 ++-- board/xilinx/zynq/zynq-zed/ps7_init_gpl.c | 4 ++-- drivers/mtd/nand/raw/zynq_nand.c | 4 ++-- drivers/spi/xilinx_spi.c | 4 ++-- drivers/spi/zynq_qspi.c| 4 ++-- include/zynqmp_firmware.h | 1 + 9 files changed, 17 insertions(+), 14 deletions(-) -- 2.17.1
[PATCH v2 2/6] xilinx: zynq: Add missing prototype for zynqmp_mmio_write
From: Algapally Santosh Sagar Add missing prototype to fix the sparse warning, warning: no previous prototype for 'zynqmp_mmio_write' [-Wmissing-prototypes]. Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- Changes in v2: - Move prototype declaration from sys_proto.h to include/zynqmp_firmware.h include/zynqmp_firmware.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h index f7a4a39d35..3cbd91e216 100644 --- a/include/zynqmp_firmware.h +++ b/include/zynqmp_firmware.h @@ -454,6 +454,7 @@ int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32 value); int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config, u32 value); int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id); +int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value); /* Type of Config Object */ #define PM_CONFIG_OBJECT_TYPE_BASE 0x1U -- 2.17.1
[PATCH v2 1/6] spi: xilinx_spi: Add missing prototype for xilinx_qspi_mem_exec_op
From: Algapally Santosh Sagar
Add missing prototype to fix the below sparse warning
warning: no previous prototype for 'xilinx_qspi_mem_exec_op'
[-Wmissing-prototypes]
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Ashok Reddy Soma
---
(no changes since v1)
drivers/spi/xilinx_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/xilinx_spi.c b/drivers/spi/xilinx_spi.c
index 33575fe757..b58a3f632a 100644
--- a/drivers/spi/xilinx_spi.c
+++ b/drivers/spi/xilinx_spi.c
@@ -363,8 +363,8 @@ static int xilinx_qspi_check_buswidth(struct spi_slave
*slave, u8 width)
return -EOPNOTSUPP;
}
-bool xilinx_qspi_mem_exec_op(struct spi_slave *slave,
-const struct spi_mem_op *op)
+static bool xilinx_qspi_mem_exec_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
{
if (xilinx_qspi_check_buswidth(slave, op->cmd.buswidth))
return false;
--
2.17.1
[PATCH v2 3/6] spi: zynq_qspi: Add missing prototype for zynq_qspi_mem_exec_op
From: Algapally Santosh Sagar
Add missing prototype to fix the sparse warning, warning: no
previous prototype for 'zynq_qspi_mem_exec_op' [-Wmissing-prototypes].
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Ashok Reddy Soma
---
(no changes since v1)
drivers/spi/zynq_qspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/zynq_qspi.c b/drivers/spi/zynq_qspi.c
index d1d4048966..cb52c0f307 100644
--- a/drivers/spi/zynq_qspi.c
+++ b/drivers/spi/zynq_qspi.c
@@ -747,8 +747,8 @@ static int zynq_qspi_check_buswidth(struct spi_slave
*slave, u8 width)
return -EOPNOTSUPP;
}
-bool zynq_qspi_mem_exec_op(struct spi_slave *slave,
- const struct spi_mem_op *op)
+static bool zynq_qspi_mem_exec_op(struct spi_slave *slave,
+ const struct spi_mem_op *op)
{
if (zynq_qspi_check_buswidth(slave, op->cmd.buswidth))
return false;
--
2.17.1
[PATCH v2 5/6] arm: zynq: Pass the missing argument type in function definition
From: Algapally Santosh Sagar
Pass missing argument type in the function definition to fix the
sparse warning, warning: old-style function definition
[-Wold-style-definition]
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Ashok Reddy Soma
---
Changes in v2:
- Added argument void in below files to fix warning
board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c | 4 ++--
board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c| 4 ++--
board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c| 4 ++--
board/xilinx/zynq/zynq-zed/ps7_init_gpl.c | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
index c2a6f9199a..602a789e77 100644
--- a/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
@@ -12408,7 +12408,7 @@ unsigned long *ps7_ddr_init_data =
ps7_ddr_init_data_3_0;
unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0;
int
-ps7_post_config()
+ps7_post_config(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
@@ -12427,7 +12427,7 @@ ps7_post_config()
}
int
-ps7_init()
+ps7_init(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
diff --git a/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
index fd102a3ce4..9343683f4d 100644
--- a/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
@@ -12741,7 +12741,7 @@ unsigned long *ps7_ddr_init_data =
ps7_ddr_init_data_3_0;
unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0;
int
-ps7_post_config()
+ps7_post_config(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
@@ -12760,7 +12760,7 @@ ps7_post_config()
}
int
-ps7_init()
+ps7_init(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
diff --git a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
index 796e5b0c5f..6b153aa379 100644
--- a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
@@ -12648,7 +12648,7 @@ unsigned long *ps7_ddr_init_data =
ps7_ddr_init_data_3_0;
unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0;
int
-ps7_post_config()
+ps7_post_config(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
@@ -12667,7 +12667,7 @@ ps7_post_config()
}
int
-ps7_init()
+ps7_init(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
diff --git a/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
index baf89a5800..6f2edf16c2 100644
--- a/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
@@ -12306,7 +12306,7 @@ unsigned long *ps7_ddr_init_data =
ps7_ddr_init_data_3_0;
unsigned long *ps7_peripherals_init_data = ps7_peripherals_init_data_3_0;
int
-ps7_post_config()
+ps7_post_config(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
@@ -12325,7 +12325,7 @@ ps7_post_config()
}
int
-ps7_init()
+ps7_init(void)
{
// Get the PS_VERSION on run time
unsigned long si_ver = ps7GetSiliconVersion ();
--
2.17.1
[PATCH v2 6/6] xilinx: zynq: Add the missing function prototypes
From: Algapally Santosh Sagar Add the missing prototypes for the functions pointed by the below sparse warnings warning: no previous prototype for 'set_dfu_alt_info' [-Wmissing-prototypes] warning: no previous prototype for 'board_debug_uart_init' [-Wmissing-prototypes] Signed-off-by: Algapally Santosh Sagar Signed-off-by: Ashok Reddy Soma --- (no changes since v1) board/xilinx/zynq/board.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c index 9a59445b44..3b6581e304 100644 --- a/board/xilinx/zynq/board.c +++ b/board/xilinx/zynq/board.c @@ -5,6 +5,8 @@ */ #include +#include +#include #include #include #include -- 2.17.1
[PATCH v2 4/6] mtd: nand: zynq_nand: Change datatype of status and ecc_status to int
From: Algapally Santosh Sagar
status and ecc_status are of unsigned type where they are compared for
negative value. This is pointed by below sparse warning. Change datatype
to int to fix this.
warning: comparison of unsigned expression in '< 0' is always false
[-Wtype-limits]
Signed-off-by: Algapally Santosh Sagar
Reviewed-by: Michael Trimarchi
Signed-off-by: Ashok Reddy Soma
---
(no changes since v1)
drivers/mtd/nand/raw/zynq_nand.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/zynq_nand.c b/drivers/mtd/nand/raw/zynq_nand.c
index 9e3ee7412d..545fdd7b69 100644
--- a/drivers/mtd/nand/raw/zynq_nand.c
+++ b/drivers/mtd/nand/raw/zynq_nand.c
@@ -285,7 +285,7 @@ static int zynq_nand_init_nand_flash(struct mtd_info *mtd,
int option)
{
struct nand_chip *nand_chip = mtd_to_nand(mtd);
struct nand_drv *smc = nand_get_controller_data(nand_chip);
- u32 status;
+ int status;
/* disable interrupts */
writel(ZYNQ_NAND_CLR_CONFIG, &smc->reg->cfr);
@@ -332,7 +332,7 @@ static int zynq_nand_calculate_hwecc(struct mtd_info *mtd,
const u8 *data,
struct nand_drv *smc = nand_get_controller_data(nand_chip);
u32 ecc_value = 0;
u8 ecc_reg, ecc_byte;
- u32 ecc_status;
+ int ecc_status;
/* Wait till the ECC operation is complete */
ecc_status = zynq_nand_waitfor_ecc_completion(mtd);
--
2.17.1
[PATCH] arm64: versal-net: spi: Update boot sequence dynamically
Currently xspi0 is used for all spi boot modes, it means it will use "sf
probe 0 0 0" for all spi's irrespective of which node it is wired.
Get boot sequence from dev_seq() and update boot command for xspi
dynamically.
As a result bootcmd for spi is updated as below when two instances of spi
are present in DT node.
bootcmd_xspi0=devnum_xspi=0; run xspi_boot
bootcmd_xspi1=devnum_xspi=1; run xspi_boot
xspi_boot=sf probe $devnum_xspi:0 0 0 && sf read $scriptaddr
$script_offset_f $script_size_f && echo XSPI: Trying to boot script at
${scriptaddr} && source ${scriptaddr}; echo XSPI: SCRIPT FAILED:
continuing...;
Signed-off-by: Ashok Reddy Soma
---
board/xilinx/versal-net/board.c | 24 +---
include/configs/xilinx_versal_net.h | 19 ---
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index 6595d6f3e8..00b01d9641 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -214,15 +214,33 @@ int board_late_init(void)
break;
case QSPI_MODE_24BIT:
puts("QSPI_MODE_24\n");
- mode = "xspi0";
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f103", &dev)) {
+ puts("Boot from QSPI but without QSPI enabled!\n");
+ return -1;
+ }
+ mode = "xspi";
+ bootseq = dev_seq(dev);
break;
case QSPI_MODE_32BIT:
puts("QSPI_MODE_32\n");
- mode = "xspi0";
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f103", &dev)) {
+ puts("Boot from QSPI but without QSPI enabled!\n");
+ return -1;
+ }
+ mode = "xspi";
+ bootseq = dev_seq(dev);
break;
case OSPI_MODE:
puts("OSPI_MODE\n");
- mode = "xspi0";
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f101", &dev)) {
+ puts("Boot from OSPI but without OSPI enabled!\n");
+ return -1;
+ }
+ mode = "xspi";
+ bootseq = dev_seq(dev);
break;
case EMMC_MODE:
puts("EMMC_MODE\n");
diff --git a/include/configs/xilinx_versal_net.h
b/include/configs/xilinx_versal_net.h
index 424ead038e..613cce46f9 100644
--- a/include/configs/xilinx_versal_net.h
+++ b/include/configs/xilinx_versal_net.h
@@ -76,20 +76,24 @@
# define BOOT_TARGET_DEVICES_DHCP(func)
#endif
-#if defined(CONFIG_ZYNQMP_GQSPI) || defined(CONFIG_CADENCE_OSPI_VERSAL_NET)
-# define BOOT_TARGET_DEVICES_XSPI(func)func(XSPI, xspi, 0)
+#if defined(CONFIG_ZYNQMP_GQSPI) || defined(CONFIG_CADENCE_OSPI_VERSAL)
+# define BOOT_TARGET_DEVICES_XSPI(func)func(XSPI, xspi, 0) func(XSPI,
xspi, 1)
+# define BOOTENV_DEV_SHARED_XSPI \
+ "xspi_boot=sf probe $devnum_xspi:0 0 0 && " \
+ "sf read $scriptaddr $script_offset_f $script_size_f && " \
+ "echo XSPI: Trying to boot script at ${scriptaddr} && " \
+ "source ${scriptaddr}; echo XSPI: SCRIPT FAILED: continuing...;\0"
#else
# define BOOT_TARGET_DEVICES_XSPI(func)
+# define BOOTENV_DEV_SHARED_XSPI
#endif
#define BOOTENV_DEV_XSPI(devtypeu, devtypel, instance) \
- "bootcmd_xspi0=sf probe 0 0 0 && " \
- "sf read $scriptaddr $script_offset_f $script_size_f && " \
- "echo XSPI: Trying to boot script at ${scriptaddr} && " \
- "source ${scriptaddr}; echo XSPI: SCRIPT FAILED: continuing...;\0"
+ "bootcmd_" #devtypel #instance "=" \
+ "devnum_xspi=" #instance "; run " #devtypel "_boot\0" \
#define BOOTENV_DEV_NAME_XSPI(devtypeu, devtypel, instance) \
- "xspi0 "
+ ""
#define BOOT_TARGET_DEVICES_JTAG(func) func(JTAG, jtag, na)
@@ -127,6 +131,7 @@
#define CFG_EXTRA_ENV_SETTINGS \
ENV_MEM_LAYOUT_SETTINGS \
BOOTENV \
+ BOOTENV_DEV_SHARED_XSPI \
DFU_ALT_INFO
#endif
--
2.17.1
[PATCH V3 0/8] Update SPL splashscreen framework for AM62x
This patch series aims at updating SPL splashscreen framework for AM62x. This patch series depends on https://lore.kernel.org/u-boot/20230504225829.2537050-1-...@chromium.org/ This series: - Fixes compilation issues in case splash related configs are not defined in SPL. - Does page table setup, dram initialisation and dcache enabling in one function call spl_enable_dcache. - Allows passing of framebuffer from spl to u-boot, eliminating flicker. V3: - Fix spacing issues. - Add Reviewed-by tag. - Replace #if with if in patch common: spl: spl: Remove video driver - Add link to updated memory map. V2: - Update cover letter. - Fix commit message. Nikhil M Jain (8): common: spl: spl: Update stack pointer address arch: arm: mach-k3: common: Return a pointer after setting page table board: ti: am62x: evm: Update function calls for splash screen include: video: Reserve video using blob common: board_f: Pass frame buffer info from SPL to u-boot drivers: video: Kconfig: Add config remove video common: spl: spl: Remove video driver configs: am62x_evm_a53: Add bloblist address arch/arm/mach-k3/am625_init.c | 1 + arch/arm/mach-k3/common.c | 2 ++ board/ti/am62x/evm.c| 41 - common/board_f.c| 11 - common/spl/spl.c| 23 +- configs/am62x_evm_a53_defconfig | 1 + drivers/video/Kconfig | 12 ++ drivers/video/video-uclass.c| 23 ++ include/video.h | 9 9 files changed, 85 insertions(+), 38 deletions(-) -- 2.34.1
[PATCH V3 1/8] common: spl: spl: Update stack pointer address
At SPL stage when stack is relocated, the stack pointer needs to be updated, the stack pointer may point to stack in on chip memory even though stack is relocated. Signed-off-by: Nikhil M Jain Reviewed-by: Tom Rini --- V3: - Add Reviewed-by tag. V2: - No change. common/spl/spl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/common/spl/spl.c b/common/spl/spl.c index 801c4b507c..13b55e9769 100644 --- a/common/spl/spl.c +++ b/common/spl/spl.c @@ -992,6 +992,7 @@ ulong spl_relocate_stack_gd(void) #endif /* Get stack position: use 8-byte alignment for ABI compliance */ ptr = CONFIG_SPL_STACK_R_ADDR - roundup(sizeof(gd_t),16); + gd->start_addr_sp = ptr; new_gd = (gd_t *)ptr; memcpy(new_gd, (void *)gd, sizeof(gd_t)); #if CONFIG_IS_ENABLED(DM) -- 2.34.1
[PATCH V3 2/8] arch: arm: mach-k3: common: Return a pointer after setting page table
In spl_dcache_enable after setting up page table, set gd->relocaddr
pointer to tlb_addr, to get next location to reserve memory. Align
tlb_addr with 64KB address.
Signed-off-by: Nikhil M Jain
---
V3:
- No change.
V2:
- Perform 64KB alignment on tlb_addr.
arch/arm/mach-k3/common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 0e045919dd..9cd912c523 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -624,8 +624,10 @@ void spl_enable_dcache(void)
ram_top = (phys_addr_t) 0x1;
gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
+ gd->arch.tlb_addr &= ~(0x1 - 1);
debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
gd->arch.tlb_addr + gd->arch.tlb_size);
+ gd->relocaddr = gd->arch.tlb_addr;
dcache_enable();
#endif
--
2.34.1
[PATCH V3 3/8] board: ti: am62x: evm: Update function calls for splash screen
Use spl_dcache_enable, in place of setup_dram, arch_reserve_mmu to set
up pagetable, initialise DRAM and enable Dcache.
Signed-off-by: Nikhil M Jain
---
V3:
- No change.
V2:
- Use CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to reserve
video and call splash at SPL.
- Check SPL_SPLASH_SCREEN and SPL_BMP before calling splash display.
arch/arm/mach-k3/am625_init.c | 1 +
board/ti/am62x/evm.c | 41 +--
2 files changed, 16 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
index 787fe92295..0e5d44269e 100644
--- a/arch/arm/mach-k3/am625_init.c
+++ b/arch/arm/mach-k3/am625_init.c
@@ -214,6 +214,7 @@ void board_init_f(ulong dummy)
if (ret)
panic("DRAM init failed: %d\n", ret);
#endif
+ spl_enable_dcache();
}
u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
index 34830f445f..d3c1786cd9 100644
--- a/board/ti/am62x/evm.c
+++ b/board/ti/am62x/evm.c
@@ -59,42 +59,31 @@ int dram_init_banksize(void)
}
#if defined(CONFIG_SPL_BUILD)
-#ifdef CONFIG_SPL_VIDEO_TIDSS
-static int setup_dram(void)
-{
- dram_init();
- dram_init_banksize();
- gd->ram_base = CFG_SYS_SDRAM_BASE;
- gd->ram_top = gd->ram_base + gd->ram_size;
- gd->relocaddr = gd->ram_top;
- return 0;
-}
-
static int video_setup(void)
{
- ulong addr;
- int ret;
- addr = gd->relocaddr;
+ if (CONFIG_IS_ENABLED(VIDEO)) {
+ ulong addr;
+ int ret;
+
+ addr = gd->relocaddr;
+ ret = video_reserve(&addr);
+ if (ret)
+ return ret;
+ debug("Reserving %luk for video at: %08lx\n",
+ ((unsigned long)gd->relocaddr - addr) >> 10, addr);
+ gd->relocaddr = addr;
+ }
- ret = video_reserve(&addr);
- if (ret)
- return ret;
- debug("Reserving %luk for video at: %08lx\n",
- ((unsigned long)gd->relocaddr - addr) >> 10, addr);
- gd->relocaddr = addr;
return 0;
}
-#endif
void spl_board_init(void)
{
-#if defined(CONFIG_SPL_VIDEO_TIDSS)
- setup_dram();
- arch_reserve_mmu();
video_setup();
enable_caches();
- splash_display();
-#endif
+ if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
+ splash_display();
+
}
#if defined(CONFIG_K3_AM64_DDRSS)
--
2.34.1
[PATCH V3 6/8] drivers: video: Kconfig: Add config remove video
This is required since user may want to either call the remove method of video driver and reset the display or not call the remove method to continue displaying until next stage. Signed-off-by: Nikhil M Jain Reviewed-by: Devarsh Thakkar --- V3: - No change. V2: - Add Reviewed-by tag. drivers/video/Kconfig | 12 1 file changed, 12 insertions(+) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index fcc0e85d2e..a89bfaa448 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -840,6 +840,12 @@ config IHS_VIDEO_OUT out On-screen Display (OSD) used on gdsys FPGAs to control dynamic textual overlays of the display outputs. +config VIDEO_REMOVE + bool "Remove video driver" + help + Use this option to specify if user wants to call remove method of + video driver in u-boot proper stage. + config SPLASH_SCREEN bool "Show a splash-screen image" help @@ -1063,6 +1069,12 @@ config SPL_SYS_WHITE_ON_BLACK This can be better in low-light situations or to reduce eye strain in some cases. +config SPL_VIDEO_REMOVE + bool "Remove video driver after SPL stage" + help + if this option is enabled video driver will be removed at the end of + SPL stage, beforeloading the next stage. + if SPL_SPLASH_SCREEN config SPL_SPLASH_SCREEN_ALIGN -- 2.34.1
[PATCH V3 4/8] include: video: Reserve video using blob
Add method to reserve video framebuffer information using blob,
received from previous stage.
Signed-off-by: Nikhil M Jain
Reviewed-by: Simon Glass
---
V3:
- Add Reviewed-by tag.
V2:
- Remove #if CONFIG_IS_ENABLED(VIDEO) in video_reserve_from_blob.
drivers/video/video-uclass.c | 11 +++
include/video.h | 9 +
2 files changed, 20 insertions(+)
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 8396bdfb11..68ce681bb9 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -142,6 +142,17 @@ int video_reserve(ulong *addrp)
return 0;
}
+int video_reserve_from_bloblist(struct video_handoff *ho)
+{
+ gd->video_bottom = ho->fb;
+ gd->fb_base = ho->fb;
+ gd->video_top = ho->fb + ho->size;
+ debug("Reserving %luk for video using blob at: %08x\n",
+ ((unsigned long)ho->size) >> 10, (u32)ho->fb);
+
+ return 0;
+}
+
int video_fill(struct udevice *dev, u32 colour)
{
struct video_priv *priv = dev_get_uclass_priv(dev);
diff --git a/include/video.h b/include/video.h
index 18ed159b8d..5f3010d641 100644
--- a/include/video.h
+++ b/include/video.h
@@ -389,4 +389,13 @@ int bmp_display(ulong addr, int x, int y);
*/
int bmp_info(ulong addr);
+/*
+ * video_reserve_from_bloblist()- Reserve frame-buffer memory for video devices
+ * using blobs.
+ *
+ * @ho: video information passed from SPL
+ * Returns: 0 (always)
+ */
+int video_reserve_from_bloblist(struct video_handoff *ho);
+
#endif
--
2.34.1
[PATCH V3 5/8] common: board_f: Pass frame buffer info from SPL to u-boot
U-boot proper can use frame buffer address passed from SPL to reserve
the memory area used by framebuffer set in SPL so that splash image
set in SPL continues to get displayed while u-boot proper is running.
Put the framebuffer address and size in a bloblist to make them
available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined.
Signed-off-by: Nikhil M Jain
---
V3:
- Clean up errors appeared in checkpatch.
V2:
- Fix commit message.
- Revert use of #if.
common/board_f.c | 11 ++-
drivers/video/video-uclass.c | 12
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 1688e27071..8e5dbaf06c 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -411,7 +411,16 @@ __weak int arch_reserve_mmu(void)
static int reserve_video(void)
{
- if (IS_ENABLED(CONFIG_VIDEO)) {
+ if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL &&
+ CONFIG_IS_ENABLED(BLOBLIST)) {
+ struct video_handoff *ho;
+
+ ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
+ if (!ho)
+ return log_msg_ret("blf", -ENOENT);
+ video_reserve_from_bloblist(ho);
+ gd->relocaddr = ho->fb;
+ } else if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
index 68ce681bb9..f8f0dc0311 100644
--- a/drivers/video/video-uclass.c
+++ b/drivers/video/video-uclass.c
@@ -6,12 +6,14 @@
#define LOG_CATEGORY UCLASS_VIDEO
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -139,6 +141,16 @@ int video_reserve(ulong *addrp)
debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
gd->video_top);
+ if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
+ struct video_handoff *ho;
+
+ ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
+ if (!ho)
+ return log_msg_ret("blf", -ENOENT);
+ ho->fb = *addrp;
+ ho->size = size;
+ }
+
return 0;
}
--
2.34.1
[PATCH V3 8/8] configs: am62x_evm_a53: Add bloblist address
Set bloblist address to 0x80D0. Below is the link to updated memory map: Link: https://gist.github.com/NikMJain/5686f7f976c18a359762b52d474dc07b#file-am62x-a53_spl_memory_map-rst Signed-off-by: Nikhil M Jain Reviewed-by: Devarsh Thakkar --- V3: - Add link to updated memory map. V2: - Add Reviewed-by tag. configs/am62x_evm_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig index 7c3bc184cf..5c572dfb33 100644 --- a/configs/am62x_evm_a53_defconfig +++ b/configs/am62x_evm_a53_defconfig @@ -102,3 +102,4 @@ CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y CONFIG_SYSRESET_TI_SCI=y CONFIG_FS_FAT_MAX_CLUSTSIZE=16384 +CONFIG_BLOBLIST_ADDR=0x80D0 -- 2.34.1
[PATCH V3 7/8] common: spl: spl: Remove video driver
Use config SPL_VIDEO_REMOVE to remove video driver at SPL stage before
jumping to next stage, in place of CONFIG_SPL_VIDEO, to allow user to
remove video if required.
Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
---
V3:
- Replace #if defined(CONFIG_SPL_VIDEO_REMOVE) with
if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE).
V2:
- Add Reviewed-by tag.
common/spl/spl.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 13b55e9769..79291abeae 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -891,18 +891,18 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
debug("Failed to stash bootstage: err=%d\n", ret);
#endif
-#if defined(CONFIG_SPL_VIDEO)
- struct udevice *dev;
- int rc;
-
- rc = uclass_find_device(UCLASS_VIDEO, 0, &dev);
- if (!rc && dev) {
- rc = device_remove(dev, DM_REMOVE_NORMAL);
- if (rc)
- printf("Cannot remove video device '%s' (err=%d)\n",
- dev->name, rc);
+ if (IS_ENABLED(CONFIG_SPL_VIDEO_REMOVE)) {
+ struct udevice *dev;
+ int rc;
+
+ rc = uclass_find_device(UCLASS_VIDEO, 0, &dev);
+ if (!rc && dev) {
+ rc = device_remove(dev, DM_REMOVE_NORMAL);
+ if (rc)
+ printf("Cannot remove video device '%s'
(err=%d)\n",
+ dev->name, rc);
+ }
}
-#endif
spl_board_prepare_for_boot();
jump_to_image_no_args(&spl_image);
--
2.34.1
Re: [PATCH] mmc: Do not read eMMC partition access bits by default on OMAP2PLUS and BCM283X
On 5/17/2023 2:49 AM, Pali Rohár wrote: OMAP2PLUS and BCM283X mmc controllers do not work correctly with new emmc code which reads partition access bits prior mmc controller reset. So introduce a new config option MMC_ENABLE_PART_ACCESS, which is by default disabled for ARCH_OMAP2PLUS and ARCH_BCM283X; and selected for 32-bit mvebu mmc booting (which requires it). Signed-off-by: Pali Rohár Looks good to me. Reviewed-by: Peng Fan I expect Jaehoon will handle this patch. Regards, Peng. --- arch/arm/mach-mvebu/Kconfig | 1 + drivers/mmc/Kconfig | 12 drivers/mmc/mmc.c | 2 ++ 3 files changed, 15 insertions(+) diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig index ac484c73f62d..fe691cd435e7 100644 --- a/arch/arm/mach-mvebu/Kconfig +++ b/arch/arm/mach-mvebu/Kconfig @@ -353,6 +353,7 @@ config MVEBU_SPL_BOOT_DEVICE_MMC imply SPL_GPIO imply SPL_LIBDISK_SUPPORT imply SPL_MMC + select MMC_ENABLE_PART_ACCESS if SPL_MMC select SUPPORT_EMMC_BOOT if SPL_MMC select SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR if SPL_MMC select SPL_BOOTROM_SUPPORT diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig index de01b9687bad..ea50dfdb62c5 100644 --- a/drivers/mmc/Kconfig +++ b/drivers/mmc/Kconfig @@ -107,6 +107,18 @@ config MMC_HW_PARTITIONING This adds a command and an API to do hardware partitioning on eMMC devices. +config MMC_ENABLE_PART_ACCESS + bool "Support for MMC partition access bits" + default n if ARCH_OMAP2PLUS || ARCH_BCM283X + default y + help + Read partition access bits from partition config register before card reset command + because these bits are reset to default value (User Data Area) during card reset. + This allows us to preserve original value of partition access bits used by the code + which loaded us (for example BootROM) and use it for board specific boot purposes. + . + This is required when U-Boot is using EXT_CSD_EXTRACT_PARTITION_ACCESS macro. + config SUPPORT_EMMC_RPMB bool "Support eMMC replay protected memory block (RPMB)" imply CMD_MMC_RPMB diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 9915610d82b1..fa3c4d1937c1 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2864,6 +2864,7 @@ int mmc_get_op_cond(struct mmc *mmc, bool quiet) retry: mmc_set_initial_state(mmc); +#ifdef CONFIG_MMC_ENABLE_PART_ACCESS /* * Read partition access bits from partition config register before card reset command * because these bits are reset to default value (User Data Area) during card reset. @@ -2878,6 +2879,7 @@ retry: ext_csd[EXT_CSD_BOOT_MULT])) mmc->part_config = ext_csd[EXT_CSD_PART_CONF] & PART_ACCESS_MASK; } +#endif /* Reset the Card */ err = mmc_go_idle(mmc);
Re: [PATCH V3 2/8] arch: arm: mach-k3: common: Return a pointer after setting page table
On 14/06/23 15:04, Nikhil M Jain wrote:
> In spl_dcache_enable after setting up page table, set gd->relocaddr
> pointer to tlb_addr, to get next location to reserve memory. Align
> tlb_addr with 64KB address.
>
> Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
> ---
> V3:
> - No change.
>
> V2:
> - Perform 64KB alignment on tlb_addr.
>
> arch/arm/mach-k3/common.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
> index 0e045919dd..9cd912c523 100644
> --- a/arch/arm/mach-k3/common.c
> +++ b/arch/arm/mach-k3/common.c
> @@ -624,8 +624,10 @@ void spl_enable_dcache(void)
> ram_top = (phys_addr_t) 0x1;
>
> gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
> + gd->arch.tlb_addr &= ~(0x1 - 1);
> debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
> gd->arch.tlb_addr + gd->arch.tlb_size);
> + gd->relocaddr = gd->arch.tlb_addr;
>
> dcache_enable();
> #endif
Re: [PATCH V3 3/8] board: ti: am62x: evm: Update function calls for splash screen
Hi Nikhil,
On 14/06/23 15:04, Nikhil M Jain wrote:
> Use spl_dcache_enable, in place of setup_dram, arch_reserve_mmu to set
> up pagetable, initialise DRAM and enable Dcache.
>
I think the patch does more than just above, please mention about those
changes too in commit message for future reference.
> Signed-off-by: Nikhil M Jain
> ---
> V3:
> - No change.
>
> V2:
> - Use CONFIG_SPL_VIDEO in place of CONFIG_SPL_VIDEO_TIDSS to reserve
> video and call splash at SPL.
> - Check SPL_SPLASH_SCREEN and SPL_BMP before calling splash display.
Above should also go to commit message with reasoning along with other changes
done in the patch.
Regards
Devarsh
>
> arch/arm/mach-k3/am625_init.c | 1 +
> board/ti/am62x/evm.c | 41 +--
> 2 files changed, 16 insertions(+), 26 deletions(-)
>
> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> index 787fe92295..0e5d44269e 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -214,6 +214,7 @@ void board_init_f(ulong dummy)
> if (ret)
> panic("DRAM init failed: %d\n", ret);
> #endif
> + spl_enable_dcache();
> }
>
> u32 spl_mmc_boot_mode(struct mmc *mmc, const u32 boot_device)
> diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
> index 34830f445f..d3c1786cd9 100644
> --- a/board/ti/am62x/evm.c
> +++ b/board/ti/am62x/evm.c
> @@ -59,42 +59,31 @@ int dram_init_banksize(void)
> }
>
> #if defined(CONFIG_SPL_BUILD)
> -#ifdef CONFIG_SPL_VIDEO_TIDSS
> -static int setup_dram(void)
> -{
> - dram_init();
> - dram_init_banksize();
> - gd->ram_base = CFG_SYS_SDRAM_BASE;
> - gd->ram_top = gd->ram_base + gd->ram_size;
> - gd->relocaddr = gd->ram_top;
> - return 0;
> -}
> -
> static int video_setup(void)
> {
> - ulong addr;
> - int ret;
> - addr = gd->relocaddr;
> + if (CONFIG_IS_ENABLED(VIDEO)) {
> + ulong addr;
> + int ret;
> +
> + addr = gd->relocaddr;
> + ret = video_reserve(&addr);
> + if (ret)
> + return ret;
> + debug("Reserving %luk for video at: %08lx\n",
> + ((unsigned long)gd->relocaddr - addr) >> 10, addr);
> + gd->relocaddr = addr;
> + }
>
> - ret = video_reserve(&addr);
> - if (ret)
> - return ret;
> - debug("Reserving %luk for video at: %08lx\n",
> - ((unsigned long)gd->relocaddr - addr) >> 10, addr);
> - gd->relocaddr = addr;
> return 0;
> }
>
> -#endif
> void spl_board_init(void)
> {
> -#if defined(CONFIG_SPL_VIDEO_TIDSS)
> - setup_dram();
> - arch_reserve_mmu();
> video_setup();
> enable_caches();
> - splash_display();
> -#endif
> + if (IS_ENABLED(CONFIG_SPL_SPLASH_SCREEN) && IS_ENABLED(CONFIG_SPL_BMP))
> + splash_display();
> +
> }
>
> #if defined(CONFIG_K3_AM64_DDRSS)
Re: [PATCH V3 5/8] common: board_f: Pass frame buffer info from SPL to u-boot
On 14/06/23 15:04, Nikhil M Jain wrote:
> U-boot proper can use frame buffer address passed from SPL to reserve
> the memory area used by framebuffer set in SPL so that splash image
> set in SPL continues to get displayed while u-boot proper is running.
>
> Put the framebuffer address and size in a bloblist to make them
> available at u-boot proper, if in u-boot proper CONFIG_VIDEO is defined.
>
> Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
> ---
> V3:
> - Clean up errors appeared in checkpatch.
>
> V2:
> - Fix commit message.
> - Revert use of #if.
>
> common/board_f.c | 11 ++-
> drivers/video/video-uclass.c | 12
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 1688e27071..8e5dbaf06c 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -411,7 +411,16 @@ __weak int arch_reserve_mmu(void)
>
> static int reserve_video(void)
> {
> - if (IS_ENABLED(CONFIG_VIDEO)) {
> + if (IS_ENABLED(CONFIG_SPL_VIDEO) && spl_phase() > PHASE_SPL &&
> + CONFIG_IS_ENABLED(BLOBLIST)) {
> + struct video_handoff *ho;
> +
> + ho = bloblist_find(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho));
> + if (!ho)
> + return log_msg_ret("blf", -ENOENT);
> + video_reserve_from_bloblist(ho);
> + gd->relocaddr = ho->fb;
> + } else if (CONFIG_IS_ENABLED(VIDEO)) {
> ulong addr;
> int ret;
>
> diff --git a/drivers/video/video-uclass.c b/drivers/video/video-uclass.c
> index 68ce681bb9..f8f0dc0311 100644
> --- a/drivers/video/video-uclass.c
> +++ b/drivers/video/video-uclass.c
> @@ -6,12 +6,14 @@
> #define LOG_CATEGORY UCLASS_VIDEO
>
> #include
> +#include
> #include
> #include
> #include
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -139,6 +141,16 @@ int video_reserve(ulong *addrp)
> debug("Video frame buffers from %lx to %lx\n", gd->video_bottom,
> gd->video_top);
>
> + if (spl_phase() == PHASE_SPL && CONFIG_IS_ENABLED(BLOBLIST)) {
> + struct video_handoff *ho;
> +
> + ho = bloblist_add(BLOBLISTT_U_BOOT_VIDEO, sizeof(*ho), 0);
> + if (!ho)
> + return log_msg_ret("blf", -ENOENT);
> + ho->fb = *addrp;
> + ho->size = size;
> + }
> +
> return 0;
> }
>
Re: [PATCH 1/2] mmc: Introduce mmc_send_stop_transmission()
On 6/10/2023 7:23 PM, Marek Vasut wrote:
From: Hai Pham
If a tuning command times out, the card could still be processing it,
which will cause problems for recovery. The eMMC specification section
6.6 Data transfer mode (cont’d) claims that CMD12 can be used to stop
CMD21:
"
The relationship between the various data transfer modes is summarized (see
Figure 27):
- All data read commands can be aborted any time by the stop command (CMD12).
The data transfer will terminate and the Device will return to the Transfer
State.
The read commands are: ... send tuning block (CMD21)
"
Add a function that does that.
Based on Linux commit [1] and [2].
[1] e711f0309109 ("mmc: mmc: Introduce mmc_abort_tuning()")
[2] 21adc2e45f4e ("mmc: Improve function name when aborting a tuning
cmd")
Reviewed-by: Takeshi Kihara
Reviewed-by: Marek Vasut
Signed-off-by: Hai Pham
Signed-off-by: Marek Vasut
[Marek: Update commit message, quote relevant part of the specification.
Rename to mmc_send_stop_transmission().
Remove tuning opcode check, this is controller driver specific.
Deduplicate part of mmc_read_blocks() using this function.]
---
Cc: "Ying-Chun Liu (PaulLiu)"
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Loic Poulain
Cc: Peng Fan
Cc: Simon Glass
Cc: Takeshi Kihara
---
drivers/mmc/mmc.c | 16
include/mmc.h | 2 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 1af6af82e6b..68a76aa3e94 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -398,6 +398,17 @@ int mmc_send_tuning(struct mmc *mmc, u32 opcode, int
*cmd_error)
}
#endif
+int mmc_send_stop_transmission(struct mmc *mmc)
+{
+ struct mmc_cmd cmd;
+
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ cmd.resp_type = MMC_RSP_R1;
Should R1 and R1b both supported based on Read/Write access?
Thanks,
Peng.
+
+ return mmc_send_cmd(mmc, &cmd, NULL);
+}
+
static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
lbaint_t blkcnt)
{
@@ -425,10 +436,7 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
return 0;
if (blkcnt > 1) {
- cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
- cmd.cmdarg = 0;
- cmd.resp_type = MMC_RSP_R1b;
- if (mmc_send_cmd(mmc, &cmd, NULL)) {
+ if (mmc_send_stop_transmission(mmc)) {
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
#endif
diff --git a/include/mmc.h b/include/mmc.h
index b8fbff150de..a413dc2af4d 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -558,6 +558,8 @@ int mmc_deferred_probe(struct mmc *mmc);
int mmc_reinit(struct mmc *mmc);
int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
int mmc_hs400_prepare_ddr(struct mmc *mmc);
+int mmc_send_stop_transmission(struct mmc *mmc);
+
#else
struct mmc_ops {
int (*send_cmd)(struct mmc *mmc,
Re: [PATCH] mmc: Set clock when reverting to safe bus mode
On 6/10/2023 7:22 PM, Marek Vasut wrote: From: Valentine Barshak Set MMC clock when reverting to safe bus mode and speed in case current MMC mode fails. Otherwise, trying out the other modes may fail as well. Reviewed-by: Marek Vasut Signed-off-by: Valentine Barshak [hp: fallback to legacy_speed] Signed-off-by: Hai Pham --- Cc: "Ying-Chun Liu (PaulLiu)" Cc: Hai Pham Cc: Jaehoon Chung Cc: Loic Poulain Cc: Peng Fan Cc: Simon Glass Cc: Takeshi Kihara Reviewed-by: Peng Fan --- drivers/mmc/mmc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c index 68a76aa3e94..79d0d37c240 100644 --- a/drivers/mmc/mmc.c +++ b/drivers/mmc/mmc.c @@ -2231,6 +2231,7 @@ error: mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_BUS_WIDTH, EXT_CSD_BUS_WIDTH_1); mmc_select_mode(mmc, MMC_LEGACY); + mmc_set_clock(mmc, mmc->legacy_speed, MMC_CLK_ENABLE); mmc_set_bus_width(mmc, 1); } }
[PATCH v2] env: mmc: statically set the environment partition name
The new opt-out setting, CONFIG_ENV_MMC_PARTITION, statically sets
the MMC environment partition name. Prior to this patch, the only way
to declare this partition name was by creating a
'u-boot,mmc-env-partition' parameter in the device-tree's /config node.
This setting provides additional flexibility, particularly in cases
where accessing the device-tree is not straightforward (e.g. QEMU).
If undeclared, the device-tree's setting will be used.
Signed-off-by: Emmanuel Di Fede
Cc: Joe Hershberger
Cc: Patrick Delaunay
---
v2:
- Add CONFIG_USE_ENV_MMC_PARTITION
- Replace soft if(IS_DEFINED()) condition by pre-processor #if defined()
doc/device-tree-bindings/config.txt | 2 ++
env/Kconfig | 12
env/mmc.c | 5 +
3 files changed, 19 insertions(+)
diff --git a/doc/device-tree-bindings/config.txt
b/doc/device-tree-bindings/config.txt
index 3151778b2c..f50c68bbdc 100644
--- a/doc/device-tree-bindings/config.txt
+++ b/doc/device-tree-bindings/config.txt
@@ -76,6 +76,8 @@ u-boot,mmc-env-partition (int)
precedence. In that case, only if the partition is not found,
mmc-env-offset* will be tried.
+ Note that CONFIG_ENV_MMC_PARTITION overrides this device-tree setting.
+
u-boot,no-apm-finalize (bool)
For x86 devices running on coreboot, this tells U-Boot not to lock
down the Intel Management Engine (ME) registers. This allows U-Boot to
diff --git a/env/Kconfig b/env/Kconfig
index 2bbe4c466a..59a410447f 100644
--- a/env/Kconfig
+++ b/env/Kconfig
@@ -659,6 +659,18 @@ config SYS_MMC_ENV_PART
partition 0 or the first boot partition, which is 1 or some other
defined
partition.
+config USE_ENV_MMC_PARTITION
+ bool "use the mmc environment partition name"
+ depends on ENV_IS_IN_MMC
+
+config ENV_MMC_PARTITION
+ string "mmc environment partition name"
+ depends on USE_ENV_MMC_PARTITION
+ help
+ MMC partition name used to save environment variables.
+ If this variable is unset, u-boot will try to get the env partition
name
+ from the device-tree's /config node.
+
config ENV_MMC_USE_DT
bool "Read partition name and offset in DT"
depends on ENV_IS_IN_MMC && OF_CONTROL
diff --git a/env/mmc.c b/env/mmc.c
index 7a5836ad66..cb14bbb58f 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -114,8 +114,13 @@ static inline s64 mmc_offset(struct mmc *mmc, int copy)
if (IS_ENABLED(CONFIG_SYS_MMC_ENV_PART))
hwpart = mmc_get_env_part(mmc);
+#if defined(CONFIG_ENV_MMC_PARTITION)
+ str = CONFIG_ENV_MMC_PARTITION;
+#else
/* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
str = ofnode_conf_read_str(dt_prop.partition);
+#endif
+
if (str) {
/* try to place the environment at end of the partition */
err = mmc_offset_try_partition(str, copy, &val);
--
2.41.0
Re: [PATCH] mmc: rpmb: poll mmc status after sending rpmb request
On 5/25/2023 1:45 PM, Ji Luo wrote:
polling the mmc status to make sure the rpmb request has been
sent and the mmc is not in BUSY state. This avoids potential
rpmb request failure during rpmb data write.
Signed-off-by: Ji Luo
Reviewed-by: Peng Fan
---
drivers/mmc/rpmb.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index b68d98573c..8bf19fd696 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -94,6 +94,7 @@ static int mmc_rpmb_request(struct mmc *mmc, const struct
s_rpmb *s,
struct mmc_cmd cmd = {0};
struct mmc_data data;
struct sdhci_host *host = mmc->priv;
+ int timeout_ms = 1000;
int ret;
ret = mmc_set_blockcount(mmc, count, is_rel_write);
@@ -123,6 +124,15 @@ static int mmc_rpmb_request(struct mmc *mmc, const struct
s_rpmb *s,
#endif
return 1;
}
+
+ /* poll for the ready status */
+ if (mmc_poll_for_busy(mmc, timeout_ms)) {
+#ifdef CONFIG_MMC_RPMB_TRACE
+ printf("%s:mmc is busy!\n", __func__);
+#endif
+ return 1;
+ }
+
return 0;
}
static int mmc_rpmb_response(struct mmc *mmc, struct s_rpmb *s,
Re: [PATCH] mmc: rpmb: realign frames before passing to MMC driver
On 5/11/2023 11:07 PM, Pavel Löbl wrote:
MMC driver requires request and response frame buffers to be properly
aligned for DMA transfers.
Fix already implemented reallocation for request frame and also add
realigment for response frame if needed.
Have you met any issues without your patch?
Signed-off-by: Pavel Löbl
---
drivers/mmc/rpmb.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c
index b68d98573c..e951f4e9bd 100644
--- a/drivers/mmc/rpmb.c
+++ b/drivers/mmc/rpmb.c
@@ -482,13 +482,14 @@ int mmc_rpmb_route_frames(struct mmc *mmc, void *req,
unsigned long reqlen,
*/
void *rpmb_data = NULL;
int ret;
+ void *rsp_aligned = rsp;
if (reqlen % sizeof(struct s_rpmb) || rsplen % sizeof(struct s_rpmb))
return -EINVAL;
if (!IS_ALIGNED((uintptr_t)req, ARCH_DMA_MINALIGN)) {
/* Memory alignment is required by MMC driver */
- rpmb_data = malloc(reqlen);
+ rpmb_data = memalign(ARCH_DMA_MINALIGN, reqlen);
The mmc driver use ALLOC_CACHE_ALIGN_BUFFER, so better align.
Regards,
Peng.
if (!rpmb_data)
return -ENOMEM;
@@ -496,8 +497,20 @@ int mmc_rpmb_route_frames(struct mmc *mmc, void *req, unsigned long reqlen,
req = rpmb_data;
}
+ if (!IS_ALIGNED((uintptr_t)rsp_aligned, ARCH_DMA_MINALIGN)) {
+ rsp_aligned = memalign(ARCH_DMA_MINALIGN, rsplen);
+ if (!rsp_aligned)
+ return -ENOMEM;
+ }
+
ret = rpmb_route_frames(mmc, req, reqlen / sizeof(struct s_rpmb),
- rsp, rsplen / sizeof(struct s_rpmb));
+ rsp_aligned, rsplen / sizeof(struct s_rpmb));
+
+ if (rsp_aligned != rsp) {
+ memcpy(rsp, rsp_aligned, rsplen);
+ free(rsp_aligned);
+ }
+
free(rpmb_data);
return ret;
}
Re: [PATCH 2/4] mmc: hi6220_dw_mmc: add compatible for HC2910 support
On 4/1/2023 7:17 PM, Yang Xiwen wrote:
It adds compatible "hisilicon,hi3798mv200-dw-mshc" for HC2910 SoC
Hi3798MV200 to probe this mmc driver.
It would be better if you could write more information, about
why it reuse the data structure of hi6220_mmc_data.
Regards,
Peng.
Signed-off-by: Yang Xiwen
---
drivers/mmc/hi6220_dw_mmc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mmc/hi6220_dw_mmc.c b/drivers/mmc/hi6220_dw_mmc.c
index 2cec5b9ae3..71962cd47e 100644
--- a/drivers/mmc/hi6220_dw_mmc.c
+++ b/drivers/mmc/hi6220_dw_mmc.c
@@ -100,6 +100,8 @@ static const struct udevice_id hi6220_dwmmc_ids[] = {
.data = (ulong)&hi6220_mmc_data },
{ .compatible = "hisilicon,hi3798cv200-dw-mshc",
.data = (ulong)&hi6220_mmc_data },
+ { .compatible = "hisilicon,hi3798mv200-dw-mshc",
+ .data = (ulong)&hi6220_mmc_data },
{ .compatible = "hisilicon,hi3660-dw-mshc",
.data = (ulong)&hi3660_mmc_data },
{ }
[PATCH] cadence_qspi: Enable flash reset for Versal NET platform
Enable flash reset functionality for Versal NET platform.
In cadence_qspi.c there is weak function defined for reset, hence remove
the check for config, so that it will work for Versal and Versal NET
platforms.
Add register defines in Versal NET hardware.h for mini U-Boot flash
reset.
Add read_delay initialization for Versal NET also.
Signed-off-by: Ashok Reddy Soma
---
arch/arm/mach-versal-net/include/mach/hardware.h | 11 +++
drivers/spi/cadence_ospi_versal.c| 3 +--
drivers/spi/cadence_qspi.c | 13 +
3 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-versal-net/include/mach/hardware.h
b/arch/arm/mach-versal-net/include/mach/hardware.h
index 89b84a2efc..67b864101e 100644
--- a/arch/arm/mach-versal-net/include/mach/hardware.h
+++ b/arch/arm/mach-versal-net/include/mach/hardware.h
@@ -80,3 +80,14 @@ enum versal_net_platform {
#define VERSAL_SLCR_BASEADDR 0xF106
#define VERSAL_AXI_MUX_SEL (VERSAL_SLCR_BASEADDR + 0x504)
#define VERSAL_OSPI_LINEAR_MODEBIT(1)
+
+#define FLASH_RESET_GPIO 0xc
+#define WPROT_CRP 0xF126001C
+#define RST_GPIO 0xF1260318
+#define WPROT_LPD_MIO 0xFF080728
+#define WPROT_PMC_MIO 0xF1060828
+#define BOOT_MODE_DIR 0xF1020204
+#define BOOT_MODE_OUT 0xF1020208
+#define MIO_PIN_12 0xF1060030
+#define BANK0_OUTPUT 0xF1020040
+#define BANK0_TRI 0xF1060200
diff --git a/drivers/spi/cadence_ospi_versal.c
b/drivers/spi/cadence_ospi_versal.c
index 434c6038f3..a7685a2f51 100644
--- a/drivers/spi/cadence_ospi_versal.c
+++ b/drivers/spi/cadence_ospi_versal.c
@@ -130,7 +130,6 @@ int cadence_qspi_apb_wait_for_dma_cmplt(struct
cadence_spi_priv *priv)
#if defined(CONFIG_DM_GPIO)
int cadence_qspi_versal_flash_reset(struct udevice *dev)
{
-#ifndef CONFIG_ARCH_VERSAL_NET
struct gpio_desc gpio;
u32 reset_gpio;
int ret;
@@ -166,7 +165,7 @@ int cadence_qspi_versal_flash_reset(struct udevice *dev)
/* Set value 1 to pin */
dm_gpio_set_value(&gpio, 1);
udelay(1);
-#endif
+
return 0;
}
#else
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 2d715e478c..cc3a54f295 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -249,17 +249,14 @@ static int cadence_spi_probe(struct udevice *bus)
priv->wr_delay = 50 * DIV_ROUND_UP(NSEC_PER_SEC, priv->ref_clk_hz);
- if (IS_ENABLED(CONFIG_ARCH_VERSAL)) {
- /* Versal platform uses spi calibration to set read delay */
+ /* Versal and Versal-NET use spi calibration to set read delay */
+ if (CONFIG_IS_ENABLED(ARCH_VERSAL) ||
+ CONFIG_IS_ENABLED(ARCH_VERSAL_NET))
if (priv->read_delay >= 0)
priv->read_delay = -1;
- /* Reset ospi flash device */
- ret = cadence_qspi_versal_flash_reset(bus);
- if (ret)
- return ret;
- }
- return 0;
+ /* Reset ospi flash device */
+ return cadence_qspi_versal_flash_reset(bus);
}
static int cadence_spi_remove(struct udevice *dev)
--
2.17.1
[PATCH 0/3] Add Versal NET mini U-Boot configurations
In this patch series add support for Versal NET mini U-Boot configurations for qspi, ospi and emmc flashes. Ashok Reddy Soma (3): xilinx: versal-net: Add mini qspi configuration xilinx: versal-net: Add mini ospi configuration xilinx: versal-net: Add mini eMMC 5.1 configuration arch/arm/dts/Makefile | 3 + arch/arm/dts/versal-net-mini-emmc.dts | 64 +++ arch/arm/dts/versal-net-mini-ospi-single.dts | 19 + arch/arm/dts/versal-net-mini-ospi.dtsi| 78 +++ arch/arm/dts/versal-net-mini-qspi-single.dts | 16 arch/arm/dts/versal-net-mini-qspi.dtsi| 72 + configs/xilinx_versal_net_mini_emmc_defconfig | 63 +++ configs/xilinx_versal_net_mini_ospi_defconfig | 71 + configs/xilinx_versal_net_mini_qspi_defconfig | 75 ++ 9 files changed, 461 insertions(+) create mode 100644 arch/arm/dts/versal-net-mini-emmc.dts create mode 100644 arch/arm/dts/versal-net-mini-ospi-single.dts create mode 100644 arch/arm/dts/versal-net-mini-ospi.dtsi create mode 100644 arch/arm/dts/versal-net-mini-qspi-single.dts create mode 100644 arch/arm/dts/versal-net-mini-qspi.dtsi create mode 100644 configs/xilinx_versal_net_mini_emmc_defconfig create mode 100644 configs/xilinx_versal_net_mini_ospi_defconfig create mode 100644 configs/xilinx_versal_net_mini_qspi_defconfig -- 2.17.1
[PATCH 1/3] xilinx: versal-net: Add mini qspi configuration
Add support for Versal NET mini Quad SPI flash configuration. This runs
from onchip memory, so it has to be compact. Hence only Quad SPI
related settings are enabled.
Signed-off-by: Ashok Reddy Soma
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/versal-net-mini-qspi-single.dts | 16
arch/arm/dts/versal-net-mini-qspi.dtsi| 72 ++
configs/xilinx_versal_net_mini_qspi_defconfig | 75 +++
4 files changed, 164 insertions(+)
create mode 100644 arch/arm/dts/versal-net-mini-qspi-single.dts
create mode 100644 arch/arm/dts/versal-net-mini-qspi.dtsi
create mode 100644 configs/xilinx_versal_net_mini_qspi_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa60..7b2fd0653b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -413,6 +413,7 @@ dtb-$(CONFIG_ARCH_VERSAL) += \
xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_VERSAL_NET) += \
versal-net-mini.dtb \
+ versal-net-mini-qspi-single.dtb \
xilinx-versal-net-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
diff --git a/arch/arm/dts/versal-net-mini-qspi-single.dts
b/arch/arm/dts/versal-net-mini-qspi-single.dts
new file mode 100644
index 00..fec1b514ed
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini-qspi-single.dts
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Versal NET QSPI single DTS
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ */
+
+#include "versal-net-mini-qspi.dtsi"
+
+/ {
+ model = "Xilinx Versal NET MINI QSPI SINGLE";
+};
+
+&flash0 {
+ spi-rx-bus-width = <4>;
+};
diff --git a/arch/arm/dts/versal-net-mini-qspi.dtsi
b/arch/arm/dts/versal-net-mini-qspi.dtsi
new file mode 100644
index 00..2c91d8
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini-qspi.dtsi
@@ -0,0 +1,72 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx Versal NET Mini QSPI Configuration
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ * Ashok Reddy Soma
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx,versal-net-mini";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Xilinx Versal NET MINI QSPI";
+
+ aliases {
+ serial0 = &dcc;
+ spi0 = &qspi;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200";
+ };
+
+ memory@bbf0 {
+ device_type = "memory";
+ reg = <0 0xbbf0 0 0x10>;
+ };
+
+ clk150: clk150 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <15000>;
+ };
+
+ dcc: dcc {
+ compatible = "arm,dcc";
+ status = "okay";
+ u-boot,dm-pre-reloc;
+ };
+
+ amba: amba {
+ u-boot,dm-pre-reloc;
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ qspi: spi@f103 {
+ compatible = "xlnx,versal-qspi-1.0";
+ status = "okay";
+ clock-names = "ref_clk", "pclk";
+ num-cs = <1>;
+ reg = <0 0xf103 0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&clk150>, <&clk150>;
+
+ flash0: flash@0 {
+ compatible = "n25q512a", "micron,m25p80",
+"jedec,spi-nor";
+ reg = <0>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ spi-max-frequency = <2000>;
+ };
+ };
+ };
+};
diff --git a/configs/xilinx_versal_net_mini_qspi_defconfig
b/configs/xilinx_versal_net_mini_qspi_defconfig
new file mode 100644
index 00..a7ebc38cda
--- /dev/null
+++ b/configs/xilinx_versal_net_mini_qspi_defconfig
@@ -0,0 +1,75 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_net_mini"
+CONFIG_COUNTER_FREQUENCY=1
+CONFIG_ARCH_VERSAL_NET=y
+CONFIG_TEXT_BASE=0xBBF0
+CONFIG_SYS_MALLOC_LEN=0x2000
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xBBF2
+CONFIG_SF_DEFAULT_SPEED=3000
+CONFIG_ENV_SIZE=0x80
+CONFIG_DEFAULT_DEVICE_TREE="versal-net-mini-qspi-single"
+CONFIG_SYS_PROMPT="Versal NET> "
+CONFIG_SYS_MEM_RSVD_FOR_MMU=y
+# CONFIG_PSCI_RESET is not set
+CONFIG_SYS_LOAD_ADDR=0xBBF8
+# CONFIG_EXPERT is not set
+CONFIG_REMAKE_ELF=y
+# CONFIG_ARCH_FIXUP_FDT_MEMORY is not set
+# CONFIG_AUTOBOOT is not set
+CONFIG_LOGLEVEL=0
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_BOARD_EARLY_INIT_R=y
+# CONFIG_BOARD_LATE_INIT is not set
[PATCH 2/3] xilinx: versal-net: Add mini ospi configuration
Add support for Versal NET mini Octal SPI flash configuration. This runs
from onchip memory, so it has to be compact. Hence only Octal SPI
related settings are enabled.
Signed-off-by: Ashok Reddy Soma
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/versal-net-mini-ospi-single.dts | 19 +
arch/arm/dts/versal-net-mini-ospi.dtsi| 78 +++
configs/xilinx_versal_net_mini_ospi_defconfig | 71 +
4 files changed, 169 insertions(+)
create mode 100644 arch/arm/dts/versal-net-mini-ospi-single.dts
create mode 100644 arch/arm/dts/versal-net-mini-ospi.dtsi
create mode 100644 configs/xilinx_versal_net_mini_ospi_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7b2fd0653b..e6a06a226f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -413,6 +413,7 @@ dtb-$(CONFIG_ARCH_VERSAL) += \
xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_VERSAL_NET) += \
versal-net-mini.dtb \
+ versal-net-mini-ospi-single.dtb \
versal-net-mini-qspi-single.dtb \
xilinx-versal-net-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
diff --git a/arch/arm/dts/versal-net-mini-ospi-single.dts
b/arch/arm/dts/versal-net-mini-ospi-single.dts
new file mode 100644
index 00..11a8e8b136
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini-ospi-single.dts
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Xilinx Versal NET OSPI single DTS
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ * Ashok Reddy Soma
+ */
+
+#include "versal-net-mini-ospi.dtsi"
+
+/ {
+ model = "Xilinx Versal NET MINI OSPI SINGLE";
+};
+
+&flash0 {
+ spi-rx-bus-width = <8>;
+};
diff --git a/arch/arm/dts/versal-net-mini-ospi.dtsi
b/arch/arm/dts/versal-net-mini-ospi.dtsi
new file mode 100644
index 00..1fd8504d9a
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini-ospi.dtsi
@@ -0,0 +1,78 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx Versal NET Mini OSPI Configuration
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ * Ashok Reddy Soma
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx,versal-net-mini";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Xilinx Versal NET MINI OSPI";
+
+ aliases {
+ serial0 = &dcc;
+ spi0 = &ospi;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200";
+ };
+
+ memory@bbf0 {
+ device_type = "memory";
+ reg = <0 0xBBF0 0 0x10>;
+ };
+
+ clk125: clk125 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12500>;
+ };
+
+ dcc: dcc {
+ compatible = "arm,dcc";
+ status = "okay";
+ u-boot,dm-pre-reloc;
+ };
+
+ amba: amba {
+ u-boot,dm-pre-reloc;
+ compatible = "simple-bus";
+ #address-cells = <0x2>;
+ #size-cells = <0x2>;
+ ranges;
+
+ ospi: spi@f101 {
+ compatible = "cadence,qspi", "cdns,qspi-nor";
+ status = "okay";
+ reg = <0 0xf101 0 0x1>, <0 0xc000 0
0x2000>;
+ clock-names = "ref_clk", "pclk";
+ clocks = <&clk125>, <&clk125>;
+ bus-num = <2>;
+ num-cs = <1>;
+ cdns,fifo-depth = <256>;
+ cdns,fifo-width = <4>;
+ cdns,is-dma = <1>;
+ cdns,is-stig-pgm = <1>;
+ cdns,trigger-address = <0xc000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash0: flash@0 {
+ compatible = "mt35xu02g", "micron,m25p80",
+"jedec,spi-nor";
+ reg = <0>;
+ spi-tx-bus-width = <8>;
+ spi-rx-bus-width = <8>;
+ spi-max-frequency = <2000>;
+ };
+ };
+ };
+};
diff --git a/configs/xilinx_versal_net_mini_ospi_defconfig
b/configs/xilinx_versal_net_mini_ospi_defconfig
new file mode 100644
index 00..d11e180780
--- /dev/null
+++ b/configs/xilinx_versal_net_mini_ospi_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_net_mini"
+CONFIG_COUNTER_FREQUENCY=1
+CONFIG_ARCH_VERSAL_NET=y
+CONFIG_TEXT_BASE=0xBBF0
+CONFIG_SYS_MALLOC_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x500
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xBBF2
+CONFIG_SF_DEFAULT_SPEED=3000
+CONFIG_ENV_SIZE=0x80
+# CONFIG_DM_GPIO is not set
+CONFI
[PATCH 3/3] xilinx: versal-net: Add mini eMMC 5.1 configuration
Add support for Versal NET mini eMMC 5.1 configuration. Add device tree
and defconfig.
Signed-off-by: Ashok Reddy Soma
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/versal-net-mini-emmc.dts | 64 +++
configs/xilinx_versal_net_mini_emmc_defconfig | 63 ++
3 files changed, 128 insertions(+)
create mode 100644 arch/arm/dts/versal-net-mini-emmc.dts
create mode 100644 configs/xilinx_versal_net_mini_emmc_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e6a06a226f..ffb128b424 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -413,6 +413,7 @@ dtb-$(CONFIG_ARCH_VERSAL) += \
xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_VERSAL_NET) += \
versal-net-mini.dtb \
+ versal-net-mini-emmc.dtb \
versal-net-mini-ospi-single.dtb \
versal-net-mini-qspi-single.dtb \
xilinx-versal-net-virt.dtb
diff --git a/arch/arm/dts/versal-net-mini-emmc.dts
b/arch/arm/dts/versal-net-mini-emmc.dts
new file mode 100644
index 00..4bdbc1dad1
--- /dev/null
+++ b/arch/arm/dts/versal-net-mini-emmc.dts
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx Versal NET Mini eMMC Configuration
+ *
+ * (C) Copyright 2023, Advanced Micro Devices, Inc.
+ *
+ * Michal Simek
+ * Ashok Reddy Soma
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx,versal-net-mini";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Xilinx Versal NET MINI eMMC";
+
+ aliases {
+ serial0 = &dcc;
+ mmc0 = &sdhci1;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0 0 0 0x2000>;
+ };
+
+ clk200: clk200 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2>;
+ };
+
+ dcc: dcc {
+ compatible = "arm,dcc";
+ status = "okay";
+ u-boot,dm-pre-reloc;
+ };
+
+ amba: amba {
+ u-boot,dm-pre-reloc;
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ sdhci1: sdhci@f105 {
+ compatible = "xlnx,versal-net-emmc";
+ status = "okay";
+ non-removable;
+ disable-wp;
+ bus-width = <8>;
+ reg = <0 0xf105 0 0x1>;
+ clock-names = "clk_xin", "clk_ahb";
+ clocks = <&clk200>, <&clk200>;
+ xlnx,mio-bank = <0>;
+ };
+ };
+};
diff --git a/configs/xilinx_versal_net_mini_emmc_defconfig
b/configs/xilinx_versal_net_mini_emmc_defconfig
new file mode 100644
index 00..6d5affcd52
--- /dev/null
+++ b/configs/xilinx_versal_net_mini_emmc_defconfig
@@ -0,0 +1,63 @@
+CONFIG_ARM=y
+CONFIG_SYS_CONFIG_NAME="xilinx_versal_net_mini"
+CONFIG_COUNTER_FREQUENCY=1
+CONFIG_ARCH_VERSAL_NET=y
+CONFIG_TEXT_BASE=0x1
+CONFIG_SYS_MALLOC_LEN=0x8
+CONFIG_NR_DRAM_BANKS=1
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x1
+CONFIG_ENV_SIZE=0x80
+CONFIG_DEFAULT_DEVICE_TREE="versal-net-mini-emmc"
+CONFIG_SYS_PROMPT="Versal NET> "
+# CONFIG_PSCI_RESET is not set
+CONFIG_SYS_LOAD_ADDR=0x800
+# CONFIG_EXPERT is not set
+CONFIG_REMAKE_ELF=y
+# CONFIG_AUTOBOOT is not set
+CONFIG_SYS_CONSOLE_INFO_QUIET=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_BOARD_EARLY_INIT_R=y
+# CONFIG_BOARD_LATE_INIT is not set
+# CONFIG_CMDLINE_EDITING is not set
+# CONFIG_AUTO_COMPLETE is not set
+# CONFIG_SYS_LONGHELP is not set
+# CONFIG_CMD_BDI is not set
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_BOOTD is not set
+# CONFIG_CMD_BOOTM is not set
+# CONFIG_CMD_BOOTI is not set
+# CONFIG_CMD_ELF is not set
+# CONFIG_CMD_FDT is not set
+# CONFIG_CMD_GO is not set
+# CONFIG_CMD_RUN is not set
+# CONFIG_CMD_IMI is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_SAVEENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+# CONFIG_CMD_CRC32 is not set
+# CONFIG_CMD_LOADB is not set
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_ECHO is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SOURCE is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_FAT=y
+CONFIG_CMD_FS_GENERIC=y
+CONFIG_OF_EMBED=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+# CONFIG_NET is not set
+# CONFIG_DM_WARN is not set
+# CONFIG_DM_DEVICE_REMOVE is not set
+CONFIG_MMC_HS200_SUPPORT=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_ARM_DCC=y
+CONFIG_FAT_WRITE=y
+# CONFIG_GZIP is not set
+# CONFIG_EFI_LOADER is not set
+# CONFIG_LMB is not set
--
2.17.1
[PATCH 1/2] configs: phycore-imx8mp_defconfig: Enable LTO
Enable LTO for binary size reduction. Signed-off-by: Teresa Remmet --- configs/phycore-imx8mp_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/phycore-imx8mp_defconfig b/configs/phycore-imx8mp_defconfig index 3d076204ad03..7bf404be860b 100644 --- a/configs/phycore-imx8mp_defconfig +++ b/configs/phycore-imx8mp_defconfig @@ -21,6 +21,7 @@ CONFIG_SPL_STACK=0x96 CONFIG_SPL=y CONFIG_SPL_IMX_ROMAPI_LOADADDR=0x4800 CONFIG_SYS_LOAD_ADDR=0x4048 +CONFIG_LTO=y CONFIG_FIT=y CONFIG_FIT_EXTERNAL_OFFSET=0x3000 CONFIG_SPL_LOAD_FIT=y -- 2.34.1
[PATCH 2/2] configs: phycore-imx8mm_defconfig: Enable LTO
Enable LTO for binary size reduction. Signed-off-by: Teresa Remmet --- configs/phycore-imx8mm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/phycore-imx8mm_defconfig b/configs/phycore-imx8mm_defconfig index ffdb5cce8eb5..4a27d15cb113 100644 --- a/configs/phycore-imx8mm_defconfig +++ b/configs/phycore-imx8mm_defconfig @@ -21,6 +21,7 @@ CONFIG_SPL_STACK=0x92 CONFIG_SPL=y CONFIG_ENV_OFFSET_REDUND=0x3E CONFIG_SYS_LOAD_ADDR=0x4048 +CONFIG_LTO=y CONFIG_FIT=y CONFIG_FIT_EXTERNAL_OFFSET=0x3000 CONFIG_SPL_LOAD_FIT=y -- 2.34.1
[PATCH 1/4] config: rock64: start USB to make storage usable
Start the USB stack so usb storage can be used. Adding the command as usb keyboard isn't enabled as there's not currently display output. Signed-off-by: Peter Robinson --- configs/rock64-rk3328_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 5e36612bb80..1da9b0545a5 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -23,6 +23,8 @@ CONFIG_DEBUG_UART_BASE=0xFF13 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SYS_LOAD_ADDR=0x800800 CONFIG_DEBUG_UART=y +CONFIG_USE_PREBOOT=y +CONFIG_PREBOOT="usb start" # CONFIG_ANDROID_BOOT_IMAGE is not set CONFIG_FIT=y CONFIG_FIT_VERBOSE=y -- 2.41.0
[PATCH 2/4] config: rock64: enable efuse for stable mac addr
Enable the rockchip efuse driver on the Rock64 to provide a stable ethernet address on the device. Signed-off-by: Peter Robinson --- While the rockchip efuse driver currently has issues on rk3328 due to, I believe, it not being properly initialised in ATF, enabling it at least provides a stable MAC adress on the NIC which I think makes it worthwhile configs/rock64-rk3328_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig index 1da9b0545a5..97ac8734d1b 100644 --- a/configs/rock64-rk3328_defconfig +++ b/configs/rock64-rk3328_defconfig @@ -74,6 +74,7 @@ CONFIG_FASTBOOT_CMD_OEM_FORMAT=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y +CONFIG_ROCKCHIP_EFUSE=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_SPI_FLASH_GIGADEVICE=y -- 2.41.0
[PATCH 3/4] rockchip: dts: rk3328: Add rng details to u-boot.dtsi
Add the rk3328 rng details to the u-boot.dtsi and
enable the RNG on the Rock64 to be able to provide
a rnadom seed via UEFI.
Signed-off-by: Peter Robinson
---
The DT snippet will allow this to be enabled on other rk3328 devices but
I only have the Rock54 to test on.
arch/arm/dts/rk3328-u-boot.dtsi | 6 ++
configs/rock64-rk3328_defconfig | 2 ++
2 files changed, 8 insertions(+)
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index ce96ce40a73..a9f2536de2a 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -26,6 +26,12 @@
0x0 0xff72 0x0 0x1000
0x0 0xff798000 0x0 0x1000>;
};
+
+ rng: rng@ff06 {
+ compatible = "rockchip,cryptov1-rng";
+ reg = <0x0 0xff06 0x0 0x4000>;
+ status = "okay";
+ };
};
&cru {
diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
index 97ac8734d1b..1820deee373 100644
--- a/configs/rock64-rk3328_defconfig
+++ b/configs/rock64-rk3328_defconfig
@@ -77,6 +77,8 @@ CONFIG_MISC=y
CONFIG_ROCKCHIP_EFUSE=y
CONFIG_MMC_DW=y
CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_DM_RNG=y
+CONFIG_RNG_ROCKCHIP=y
CONFIG_SPI_FLASH_GIGADEVICE=y
CONFIG_ETH_DESIGNWARE=y
CONFIG_GMAC_ROCKCHIP=y
--
2.41.0
[PATCH 4/4] rockchip: dts: rk3328: rock64: Align spi flash entry
Align the SPI flash entry with upstream. There's no need
to diverge here.
Signed-off-by: Peter Robinson
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-rock64.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 849854302ee..6904515b969 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -54,7 +54,7 @@
};
&spi0 {
- spi_flash: spiflash@0 {
+ spi_flash: flash@0 {
bootph-all;
};
};
diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index 1b0f7e4551e..f69a38f42d2 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -345,7 +345,7 @@
&spi0 {
status = "okay";
- spiflash@0 {
+ flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
--
2.41.0
[PATCH 1/2] doc: board: phytec: add phycore_imx8mm
Add documentation on how to build a bootable U-Boot image for the PHYTEC phyCORE-i.MX 8M Mini. Signed-off-by: Yannic Moog --- doc/board/index.rst | 1 + doc/board/phytec/index.rst | 9 + doc/board/phytec/phycore-imx8mm.rst | 60 + 3 files changed, 70 insertions(+) create mode 100644 doc/board/phytec/index.rst create mode 100644 doc/board/phytec/phycore-imx8mm.rst diff --git a/doc/board/index.rst b/doc/board/index.rst index 9ef25b1091..ce1fbe2fff 100644 --- a/doc/board/index.rst +++ b/doc/board/index.rst @@ -32,6 +32,7 @@ Board-specific doc nokia/index nxp/index openpiton/index + phytec/index purism/index qualcomm/index renesas/index diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst new file mode 100644 index 00..30292d0d76 --- /dev/null +++ b/doc/board/phytec/index.rst @@ -0,0 +1,9 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +PHYTEC +== + +.. toctree:: + :maxdepth: 2 + + phycore-imx8mm diff --git a/doc/board/phytec/phycore-imx8mm.rst b/doc/board/phytec/phycore-imx8mm.rst new file mode 100644 index 00..e9dc225990 --- /dev/null +++ b/doc/board/phytec/phycore-imx8mm.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +phyCORE-i.MX 8M Mini + + +The phyCORE-i.MX 8M Mini with 2GB of main memory is supported. + +Quick Start +--- + +- Build the ARM Trusted firmware binary +- Get ddr firmware +- Build U-Boot +- Boot + +Build the ARM Trusted firmware binary +- + +.. code-block:: bash + + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + $ export CROSS_COMPILE=aarch64-linux-gnu + $ export IMX_BOOT_UART_BASE=0x3088 + $ make PLAT=imx8mm bl31 + +Get the ddr firmware + + +.. code-block:: bash + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin + $ chmod +x firmware-imx-8.19.bin + $ ./firmware-imx-8.19.bin + +Build U-Boot for SD card + + +Copy binaries +^ + +.. code-block:: bash + + $ cp /build/imx8mm/release/bl31.bin . + $ cp firmware-imx-8.19/firmware/ddr/synopsys/lpddr4*.bin . + +Build U-Boot + + +.. code-block:: bash + + $ make phycore-imx8mm_defconfig + $ make flash.bin + +Flash SD card +^ + +.. code-block:: bash + + $ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=33 conv=sync -- 2.34.1
[PATCH 2/2] doc: board: phytec: add phycore_imx8mp
Add documentation on how to build a bootable U-Boot image for the PHYTEC phyCORE-i.MX 8M Plus. Signed-off-by: Yannic Moog --- doc/board/phytec/index.rst | 1 + doc/board/phytec/phycore-imx8mp.rst | 60 + 2 files changed, 61 insertions(+) create mode 100644 doc/board/phytec/phycore-imx8mp.rst diff --git a/doc/board/phytec/index.rst b/doc/board/phytec/index.rst index 30292d0d76..a5b442045e 100644 --- a/doc/board/phytec/index.rst +++ b/doc/board/phytec/index.rst @@ -7,3 +7,4 @@ PHYTEC :maxdepth: 2 phycore-imx8mm + phycore-imx8mp diff --git a/doc/board/phytec/phycore-imx8mp.rst b/doc/board/phytec/phycore-imx8mp.rst new file mode 100644 index 00..fda751aeff --- /dev/null +++ b/doc/board/phytec/phycore-imx8mp.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +phyCORE-i.MX 8M Plus + + +The phyCORE-i.MX 8M Plus with 2GB of main memory is supported. + +Quick Start +--- + +- Build the ARM Trusted firmware binary +- Get ddr firmware +- Build U-Boot +- Boot + +Build the ARM Trusted firmware binary +- + +.. code-block:: bash + + $ git clone https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git + $ cd trusted-firmware-a + $ export CROSS_COMPILE=aarch64-linux-gnu + $ export IMX_BOOT_UART_BASE=0x3086 + $ make PLAT=imx8mp bl31 + +Get the ddr firmware + + +.. code-block:: bash + + $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin + $ chmod +x firmware-imx-8.19.bin + $ ./firmware-imx-8.19.bin + +Build U-Boot for SD card + + +Copy binaries +^ + +.. code-block:: bash + + $ cp /build/imx8mp/release/bl31.bin . + $ cp firmware-imx-8.19/firmware/ddr/synopsys/lpddr4*.bin . + +Build U-Boot + + +.. code-block:: bash + + $ make phycore-imx8mp_defconfig + $ make flash.bin + +Flash SD card +^ + +.. code-block:: bash + + $ sudo dd if=flash.bin of=/dev/sd[x] bs=1024 seek=32 conv=sync -- 2.34.1
[PATCH 0/1] Kbuild: Fix cleanup of generated sources in tools
Generated C files in tools/env/ and tools/boot/ are currently not cleaned on 'make clean'. The patch fixes it by establishing a dedicated tools/generated/ directory that can be cleaned as a whole. Steps to reproduce: $ make CROSS_COMPILE=aarch64-linux-gnu- O=./build qemu_arm64_defconfig $ make CROSS_COMPILE=aarch64-linux-gnu- O=./build $ make CROSS_COMPILE=aarch64-linux-gnu- O=./build clean $ ls build/tools/boot/ build/tools/env/ build/tools/boot/: bootm.c fdt_region.c image.c image-cipher.c image-fit.c image-fit-sig.c image-host.c build/tools/env/: embedded.c Tobias Deiminger (1): Kbuild: Fix cleanup of generated sources in tools tools/Makefile | 64 ++-- tools/env/.gitignore | 1 - 2 files changed, 32 insertions(+), 33 deletions(-) base-commit: 19b77d3d23966a0d6dbb3c86187765f11100fb6f -- 2.30.2
[PATCH 1/1] Kbuild: Fix cleanup of generated sources in tools
On 'make clean', generated C files in tools/env/ and tools/boot/ are
currently not removed, but they should.
Auto-generation for shared sources was first introduced with
ad80c4a3220b ("kbuild, tools: generate wrapper C sources automatically
by Makefile"). Cleanup later regressed (see Fixes:), because shared
files were moved out of lib/ and common/, but 'clean-dirs := lib common'
was not adjusted accordingly. Further, the generated
tools/env/embedded.c became a sibling to project files, which prevents
directory-wise cleanup at all.
To solve it, we established tools/generated/ as the sole place for
generated sources. Wrappers are now generated as
tools/generated//, and 'make clean' can
remove tools/generated/ as a whole (Linux Makefile.asm-generic headers
are cleaned similarly). This way we don't have to maintain separate
clean-files or clean-dirs entries for each single added or moved wrapper
file.
Fixes: 0649cd0d4908 ("Move environment files from common/ to env/")
Fixes: 19a91f2464a8 ("Create a new boot/ directory")
Signed-off-by: Tobias Deiminger
---
tools/Makefile | 64 ++--
tools/env/.gitignore | 1 -
2 files changed, 32 insertions(+), 33 deletions(-)
diff --git a/tools/Makefile b/tools/Makefile
index d793cf3bec..d6835b24b0 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -48,20 +48,20 @@ hostprogs-$(CONFIG_VIDEO_LOGO) += bmp_logo
HOSTCFLAGS_bmp_logo.o := -pedantic
hostprogs-$(BUILD_ENVCRC) += envcrc
-envcrc-objs := envcrc.o lib/crc32.o env/embedded.o lib/sha1.o
+envcrc-objs := envcrc.o generated/lib/crc32.o generated/env/embedded.o
generated/lib/sha1.o
hostprogs-$(CONFIG_CMD_NET) += gen_eth_addr
HOSTCFLAGS_gen_eth_addr.o := -pedantic
hostprogs-$(CONFIG_CMD_NET) += gen_ethaddr_crc
-gen_ethaddr_crc-objs := gen_ethaddr_crc.o lib/crc8.o
+gen_ethaddr_crc-objs := gen_ethaddr_crc.o generated/lib/crc8.o
HOSTCFLAGS_gen_ethaddr_crc.o := -pedantic
hostprogs-$(CONFIG_CMD_LOADS) += img2srec
HOSTCFLAGS_img2srec.o := -pedantic
hostprogs-y += mkenvimage
-mkenvimage-objs := mkenvimage.o os_support.o lib/crc32.o
+mkenvimage-objs := mkenvimage.o os_support.o generated/lib/crc32.o
hostprogs-y += dumpimage mkimage
hostprogs-$(CONFIG_TOOLS_LIBCRYPTO) += fit_info fit_check_sign
@@ -71,30 +71,30 @@ ifneq
($(CONFIG_CMD_BOOTEFI_SELFTEST)$(CONFIG_FWU_MDATA_GPT_BLK),)
hostprogs-y += file2include
endif
-FIT_OBJS-y := fit_common.o fit_image.o image-host.o boot/image-fit.o
-FIT_SIG_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := image-sig-host.o boot/image-fit-sig.o
-FIT_CIPHER_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := boot/image-cipher.o
+FIT_OBJS-y := fit_common.o fit_image.o image-host.o generated/boot/image-fit.o
+FIT_SIG_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := image-sig-host.o
generated/boot/image-fit-sig.o
+FIT_CIPHER_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := generated/boot/image-cipher.o
# The following files are synced with upstream DTC.
# Use synced versions from scripts/dtc/libfdt/.
LIBFDT_OBJS := $(addprefix libfdt/, fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o
\
fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o)
-RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/rsa/, \
+RSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/rsa/, \
rsa-sign.o rsa-verify.o \
rsa-mod-exp.o)
-ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/ecdsa/,
ecdsa-libcrypto.o)
+ECDSA_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/ecdsa/,
ecdsa-libcrypto.o)
-AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix lib/aes/, \
+AES_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := $(addprefix generated/lib/aes/, \
aes-encrypt.o aes-decrypt.o)
# Cryptographic helpers and image types that depend on openssl/libcrypto
LIBCRYPTO_OBJS-$(CONFIG_TOOLS_LIBCRYPTO) := \
- lib/fdt-libcrypto.o \
+ generated/lib/fdt-libcrypto.o \
sunxi_toc0.o
-ROCKCHIP_OBS = lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
+ROCKCHIP_OBS = generated/lib/rc4.o rkcommon.o rkimage.o rksd.o rkspi.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
@@ -102,20 +102,20 @@ dumpimage-mkimage-objs := aisimage.o \
$(FIT_OBJS-y) \
$(FIT_SIG_OBJS-y) \
$(FIT_CIPHER_OBJS-y) \
- boot/fdt_region.o \
- boot/bootm.o \
- lib/crc32.o \
+ generated/boot/fdt_region.o \
+ generated/boot/bootm.o \
+ generated/lib/crc32.o \
default_image.o \
- lib/fdtdec_common.o \
- lib/fdtdec.o \
- boot/image.o \
- boot/image-host.o \
+ generated/lib/fdtdec_common.o \
+
Re: [PATCH v2] efi_selftests: fix controllers repeated selftesting
On 6/14/23 08:55, Ilias Apalodimas wrote: Running the controller selftest more than one times fails with => setenv efi_selftest 'controllers' && bootefi selftest Testing EFI API implementation Selected test: 'controllers' Setting up 'controllers' Setting up 'controllers' succeeded Executing 'controllers' Executing 'controllers' succeeded Summary: 0 failures => bootefi selftest Testing EFI API implementation Selected test: 'controllers' Setting up 'controllers' lib/efi_selftest/efi_selftest_controllers.c(280): ERROR: InstallProtocolInterface failed lib/efi_selftest/efi_selftest.c(89): ERROR: Setting up 'controllers' failed Summary: 1 failures There are multiple reason for this. We don't uninstall the binding interface from the controller handle and we don't reset the handle pointers either. So let's uninstall all the protocols properly and reset the handles to NULL on setup(). While at it add a forgotten check when uninstalling protocols from the handle_controller and make sure the number of child controllers is 0 Signed-off-by: Ilias Apalodimas Reviewed-by: Heinrich Schuchardt
[PATCH v2 1/3] mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment
The MMC_CMD_STOP_TRANSMISSION response is R1 for read transfers
per JEDEC Standard No. 84-B51 Page 126 . Correct the response
type and add a comment about it.
Signed-off-by: Marek Vasut
---
V2: New patch
---
Cc: "Ying-Chun Liu (PaulLiu)"
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Loic Poulain
Cc: Peng Fan
Cc: Simon Glass
Cc: Takeshi Kihara
---
drivers/mmc/mmc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 965bc8f0dba..f9b2f940389 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -427,7 +427,12 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
if (blkcnt > 1) {
cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
cmd.cmdarg = 0;
- cmd.resp_type = MMC_RSP_R1b;
+ /*
+* JEDEC Standard No. 84-B51 Page 126
+* CMD12 STOP_TRANSMISSION R1/R1b[3]
+* NOTE 3 R1 for read cases and R1b for write cases.
+*/
+ cmd.resp_type = MMC_RSP_R1;
if (mmc_send_cmd(mmc, &cmd, NULL)) {
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
--
2.39.2
[PATCH v2 2/3] mmc: Introduce mmc_send_stop_transmission()
From: Hai Pham
If a tuning command times out, the card could still be processing it,
which will cause problems for recovery. The eMMC specification section
6.6 Data transfer mode (cont’d) claims that CMD12 can be used to stop
CMD21:
"
The relationship between the various data transfer modes is summarized (see
Figure 27):
- All data read commands can be aborted any time by the stop command (CMD12).
The data transfer will terminate and the Device will return to the Transfer
State.
The read commands are: ... send tuning block (CMD21)
"
Add a function that does that.
Based on Linux commit [1] and [2].
[1] e711f0309109 ("mmc: mmc: Introduce mmc_abort_tuning()")
[2] 21adc2e45f4e ("mmc: Improve function name when aborting a tuning
cmd")
Reviewed-by: Takeshi Kihara
Reviewed-by: Marek Vasut
Signed-off-by: Hai Pham
Signed-off-by: Marek Vasut
[Marek: Update commit message, quote relevant part of the specification.
Rename to mmc_send_stop_transmission().
Remove tuning opcode check, this is controller driver specific.
Deduplicate part of mmc_read_blocks() using this function.]
---
V2: Support both read and write transmission stop
---
Cc: "Ying-Chun Liu (PaulLiu)"
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Loic Poulain
Cc: Peng Fan
Cc: Simon Glass
Cc: Takeshi Kihara
---
drivers/mmc/mmc.c | 26 +-
include/mmc.h | 2 ++
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index f9b2f940389..d5922d842e8 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -398,6 +398,22 @@ int mmc_send_tuning(struct mmc *mmc, u32 opcode, int
*cmd_error)
}
#endif
+int mmc_send_stop_transmission(struct mmc *mmc, bool read)
+{
+ struct mmc_cmd cmd;
+
+ cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
+ cmd.cmdarg = 0;
+ /*
+* JEDEC Standard No. 84-B51 Page 126
+* CMD12 STOP_TRANSMISSION R1/R1b[3]
+* NOTE 3 R1 for read cases and R1b for write cases.
+*/
+ cmd.resp_type = read ? MMC_RSP_R1 : MMC_RSP_R1b;
+
+ return mmc_send_cmd(mmc, &cmd, NULL);
+}
+
static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
lbaint_t blkcnt)
{
@@ -425,15 +441,7 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
return 0;
if (blkcnt > 1) {
- cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
- cmd.cmdarg = 0;
- /*
-* JEDEC Standard No. 84-B51 Page 126
-* CMD12 STOP_TRANSMISSION R1/R1b[3]
-* NOTE 3 R1 for read cases and R1b for write cases.
-*/
- cmd.resp_type = MMC_RSP_R1;
- if (mmc_send_cmd(mmc, &cmd, NULL)) {
+ if (mmc_send_stop_transmission(mmc, true)) {
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
#endif
diff --git a/include/mmc.h b/include/mmc.h
index b8fbff150de..b47d2e1a895 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -558,6 +558,8 @@ int mmc_deferred_probe(struct mmc *mmc);
int mmc_reinit(struct mmc *mmc);
int mmc_get_b_max(struct mmc *mmc, void *dst, lbaint_t blkcnt);
int mmc_hs400_prepare_ddr(struct mmc *mmc);
+int mmc_send_stop_transmission(struct mmc *mmc, bool read);
+
#else
struct mmc_ops {
int (*send_cmd)(struct mmc *mmc,
--
2.39.2
[PATCH v2 3/3] mmc: renesas-sdhi: Send stop when MMC tuning command fails
From: Hai Pham
When tuning command (CMD21) fails with command error, call
mmc_send_stop_transmission() to send stop command (CMD12).
Reviewed-by: Takeshi Kihara
Reviewed-by: Marek Vasut
Signed-off-by: Hai Pham
Signed-off-by: Marek Vasut
[Marek: Add dev_dbg() message in case tuning abort fails
Move tuning opcode check from mmc_abort_tuning()]
---
V2: Update on previous patch changes
---
Cc: "Ying-Chun Liu (PaulLiu)"
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Loic Poulain
Cc: Peng Fan
Cc: Simon Glass
Cc: Takeshi Kihara
---
drivers/mmc/renesas-sdhi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 280d96dbc2d..484712b919e 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -611,6 +611,17 @@ int renesas_sdhi_execute_tuning(struct udevice *dev, uint
opcode)
priv->smpcmp |= BIT(i);
mdelay(1);
+
+ /*
+* eMMC specification specifies that CMD12 can be used to stop
a tuning
+* command, but SD specification does not, so do nothing unless
it is
+* eMMC.
+*/
+ if (ret && (opcode == MMC_CMD_SEND_TUNING_BLOCK_HS200)) {
+ ret = mmc_send_stop_transmission(mmc, true);
+ if (ret < 0)
+ dev_dbg(dev, "Tuning abort fail (%d)\n", ret);
+ }
}
ret = renesas_sdhi_select_tuning(priv, taps);
--
2.39.2
Re: [PATCH v2 2/3] renesas: rcar3: Expose the board revision in sysinfo
On 6/12/23 21:51, Detlev Casanova wrote:
The board revision is needed to determine which linux device tree to
load.
Signed-off-by: Detlev Casanova
---
.../arm/mach-rmobile/include/mach/sys_proto.h | 6 ++
drivers/sysinfo/rcar3.c | 60 +++
2 files changed, 40 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-rmobile/include/mach/sys_proto.h
b/arch/arm/mach-rmobile/include/mach/sys_proto.h
index e020b24f7c2..1f204f06c17 100644
--- a/arch/arm/mach-rmobile/include/mach/sys_proto.h
+++ b/arch/arm/mach-rmobile/include/mach/sys_proto.h
@@ -22,4 +22,10 @@
#define BOARD_EBISU_4D0xD
#define BOARD_CONDOR_I0x10
+/*
+ * Renesas sysinfo board revision
+ */
+#define RCAR_SYSINFO_REV_MAJOR SYSINFO_ID_USER
+#define RCAR_SYSINFO_REV_MINOR (SYSINFO_ID_USER + 1)
Please just introduce regular include/sysinfo.h board revision
properties for this, not custom stuff.
#endif
diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index b8b837341a2..3223875a99c 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -22,6 +22,8 @@
struct sysinfo_rcar_priv {
charboardmodel[64];
u8 board_id;
+ u8 rev_major;
+ u8 rev_minor;
u8 val;
};
[...]
Re: [PATCH v2 1/3] renesas: rcar3: Expose the board id in sysinfo
On 6/12/23 21:51, Detlev Casanova wrote:
This is a preparation commit for selecting the correct device tree name
to be loaded depending on the board id.
Signed-off-by: Detlev Casanova
---
.../arm/mach-rmobile/include/mach/sys_proto.h | 15 ++
drivers/sysinfo/rcar3.c | 30 +++
2 files changed, 33 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-rmobile/include/mach/sys_proto.h
b/arch/arm/mach-rmobile/include/mach/sys_proto.h
index ec8036a354c..e020b24f7c2 100644
--- a/arch/arm/mach-rmobile/include/mach/sys_proto.h
+++ b/arch/arm/mach-rmobile/include/mach/sys_proto.h
@@ -7,4 +7,19 @@
#ifndef _SYS_PROTO_H_
#define _SYS_PROTO_H_
+/*
+ * Renesas R-Car Board IDs
+ */
+#define BOARD_SALVATOR_X 0x0
+#define BOARD_KRIEK0x1
+#define BOARD_STARTER_KIT 0x2
+#define BOARD_EAGLE0x3
+#define BOARD_SALVATOR_XS 0x4
+#define BOARD_CONDOR 0x6
+#define BOARD_DRAAK0x7
+#define BOARD_EBISU0x8
+#define BOARD_STARTER_KIT_PRE 0xB
+#define BOARD_EBISU_4D 0xD
+#define BOARD_CONDOR_I 0x10
+
#endif
diff --git a/drivers/sysinfo/rcar3.c b/drivers/sysinfo/rcar3.c
index 7b127986da7..b8b837341a2 100644
--- a/drivers/sysinfo/rcar3.c
+++ b/drivers/sysinfo/rcar3.c
@@ -8,23 +8,12 @@
#include
#include
#include
+#include
#define BOARD_CODE_MASK 0xF8
#define BOARD_REV_MASK0x07
#define BOARD_CODE_SHIFT 0x03
-#define BOARD_SALVATOR_X 0x0
-#define BOARD_KRIEK0x1
-#define BOARD_STARTER_KIT 0x2
-#define BOARD_EAGLE0x3
-#define BOARD_SALVATOR_XS 0x4
-#define BOARD_CONDOR 0x6
-#define BOARD_DRAAK0x7
-#define BOARD_EBISU0x8
-#define BOARD_STARTER_KIT_PRE 0xB
-#define BOARD_EBISU_4D 0xD
-#define BOARD_CONDOR_I 0x10
-
This part ^ should not be in this patch .
All this patch should do is expose the board ID .
Please split that into separate patch.
/**
* struct sysinfo_rcar_priv - sysinfo private data
* @boardname: board model and revision
@@ -32,6 +21,7 @@
*/
struct sysinfo_rcar_priv {
charboardmodel[64];
+ u8 board_id;
u8 val;
};
@@ -42,6 +32,19 @@ static int sysinfo_rcar_detect(struct udevice *dev)
return priv->val == 0xff;
}
+static int sysinfo_rcar_get_int(struct udevice *dev, int id, int *val)
+{
+ struct sysinfo_rcar_priv *priv = dev_get_priv(dev);
+
+ switch (id) {
+ case SYSINFO_ID_BOARD_MODEL:
The BOARD_MODEL is a string, please add another 'BOARD_ID' into
include/sysinfo.h to discern the properties.
+ *val = priv->board_id;
+ return 0;
+ default:
+ return -EINVAL;
+ };
+}
[...]
Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree
On 6/12/23 21:51, Detlev Casanova wrote:
The Renesas R-Car Gen3 boards use different device trees than
the default one.
This commit uses the sysinfo's board id and revision
to determine which linux device tree to load:
* H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb
* H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb
This is not about loading DTs (as the subject would suggest), this is
about setting the correct default DT name in environment.
Signed-off-by: Detlev Casanova
---
board/renesas/ulcb/ulcb.c| 59
configs/rcar3_ulcb_defconfig | 1 +
2 files changed, 60 insertions(+)
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 1477750f921..cc78e0952b6 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -65,6 +66,64 @@ int board_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ struct udevice *dev;
+ int board_id;
+ int rev_major, rev_minor;
+ int ret = sysinfo_get(&dev);
+
+ if (ret) {
+ debug("Cannot get sysinfo: %d\n", ret);
+ return 0;
Why do we ignore errors here ?
+ }
+
+ ret = sysinfo_detect(dev);
+ if (ret) {
+ debug("Cannot detect sysinfo: %d\n", ret);
+ return 0;
+ }
Looking at all this, I really have to wonder, wouldn't it be nicer to
introduce a 'sysinfo' command which provides interface to obtain the
different properties (like board name, id, revision ...) from U-Boot
command line, and then script the DT selection in U-Boot shell ?
[v1] disable NFS support by default
While NFS is widely used in data centres, and private networks it's quite a nuanced usecase for device firmware. A lot of devices already disable it. Various network protocols should really be opt in, not opt out, because they add extra size and are potential attack vectors from a security PoV. In the NFS case it doesn't really make sense for a lot of devices like tables, SBCs etc. It's also something we don't really want for SystemReady-IR due to security concerns. Signed-off-by: Peter Robinson --- v1: drop RFC tag cmd/Kconfig | 1 - configs/10m50_defconfig | 1 - configs/3c120_defconfig | 1 - configs/CMPC885_defconfig | 1 - configs/CMPCPRO_defconfig | 1 - configs/apalis-tk1_defconfig | 1 - configs/apalis_imx6_defconfig | 1 - configs/apalis_t30_defconfig | 1 - configs/bayleybay_defconfig | 1 - configs/beaver_defconfig | 1 - configs/bitmain_antminer_s9_defconfig | 1 - configs/brppt1_mmc_defconfig | 1 - configs/brppt2_defconfig | 1 - configs/brsmarc1_defconfig| 1 - configs/brxre1_defconfig | 1 - configs/cardhu_defconfig | 1 - configs/cei-tk1-som_defconfig | 1 - configs/cherryhill_defconfig | 1 - configs/chromebook_link64_defconfig | 1 - configs/chromebook_link_defconfig | 1 - configs/chromebook_samus_defconfig| 1 - configs/chromebox_panther_defconfig | 1 - configs/cm_t43_defconfig | 1 - configs/colibri_imx6_defconfig| 1 - configs/colibri_t20_defconfig | 1 - configs/colibri_t30_defconfig | 1 - configs/colibri_vf_defconfig | 1 - configs/conga-qeval20-qa3-e3845-internal-uart_defconfig | 1 - configs/conga-qeval20-qa3-e3845_defconfig | 1 - configs/coreboot64_defconfig | 1 - configs/coreboot_defconfig| 1 - configs/corstone1000_defconfig| 1 - configs/cougarcanyon2_defconfig | 1 - configs/crownbay_defconfig| 1 - configs/dalmore_defconfig | 1 - configs/dfi-bt700-q7x-151_defconfig | 1 - configs/edison_defconfig | 1 - configs/efi-x86_payload32_defconfig | 1 - configs/efi-x86_payload64_defconfig | 1 - configs/galileo_defconfig | 1 - configs/gazerbeam_defconfig | 1 - configs/ge_bx50v3_defconfig | 1 - configs/harmony_defconfig | 1 - configs/jetson-tk1_defconfig | 1 - configs/malta64_defconfig | 1 - configs/malta64el_defconfig | 1 - configs/malta_defconfig | 1 - configs/maltael_defconfig | 1 - configs/medcom-wide_defconfig | 1 - configs/minnowmax_defconfig | 1 - configs/mscc_jr2_defconfig| 1 - configs/mscc_luton_defconfig | 1 - configs/mscc_ocelot_defconfig | 1 - configs/mscc_serval_defconfig | 1 - configs/mscc_servalt_defconfig| 1 - configs/mt7620_mt7530_rfb_defconfig | 1 - configs/mt7620_rfb_defconfig | 1 - configs/mt7621_nand_rfb_defconfig | 1 - configs/mt7621_rfb_defconfig | 1 - configs/mt7623a_unielec_u7623_02_defconfig| 1 - configs/mt7623n_bpir2_defconfig | 1 - configs/mt7628_rfb_defconfig | 1 - configs/mt7629_rfb_defconfig | 1 - configs/nyan-big_defconfig| 1 - configs/odroid_defconfig | 1 - configs/omap4_panda_defconfig | 1 - configs/omap4_sdp4430_defconfig | 1 - configs/p2371-_defconfig | 1 - configs/p2371-2180_defconfig
Re: [PATCH 1/4] config: rock64: start USB to make storage usable
Hi Peter, On 2023-06-14 14:43, Peter Robinson wrote: > Start the USB stack so usb storage can be used. Adding the command > as usb keyboard isn't enabled as there's not currently display output. This is not needed for autoboot from usb to work and slows down boot from sd/emmc by forcing usb to start. bootstd will init usb once it reaches usb in boot_targets and nothing can boot before it. boot_targets="mmc1 mmc0 nvme scsi usb pxe dhcp spi" You can change boot_targets env if you want to start from usb before mmc. Regards, Jonas > > Signed-off-by: Peter Robinson > --- > configs/rock64-rk3328_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig > index 5e36612bb80..1da9b0545a5 100644 > --- a/configs/rock64-rk3328_defconfig > +++ b/configs/rock64-rk3328_defconfig > @@ -23,6 +23,8 @@ CONFIG_DEBUG_UART_BASE=0xFF13 > CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SYS_LOAD_ADDR=0x800800 > CONFIG_DEBUG_UART=y > +CONFIG_USE_PREBOOT=y > +CONFIG_PREBOOT="usb start" > # CONFIG_ANDROID_BOOT_IMAGE is not set > CONFIG_FIT=y > CONFIG_FIT_VERBOSE=y
Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree
On Wednesday, June 14, 2023 9:53:14 A.M. EDT Marek Vasut wrote:
> On 6/12/23 21:51, Detlev Casanova wrote:
> > The Renesas R-Car Gen3 boards use different device trees than
> > the default one.
> >
> > This commit uses the sysinfo's board id and revision
> >
> > to determine which linux device tree to load:
> > * H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb
> > * H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb
>
> This is not about loading DTs (as the subject would suggest), this is
> about setting the correct default DT name in environment.
>
> > Signed-off-by: Detlev Casanova
> > ---
> >
> > board/renesas/ulcb/ulcb.c| 59
> > configs/rcar3_ulcb_defconfig | 1 +
> > 2 files changed, 60 insertions(+)
> >
> > diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
> > index 1477750f921..cc78e0952b6 100644
> > --- a/board/renesas/ulcb/ulcb.c
> > +++ b/board/renesas/ulcb/ulcb.c
> > @@ -27,6 +27,7 @@
> >
> > #include
> > #include
> > #include
> >
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -65,6 +66,64 @@ int board_init(void)
> >
> > return 0;
> >
> > }
> >
> > +int misc_init_r(void)
> > +{
> > + struct udevice *dev;
> > + int board_id;
> > + int rev_major, rev_minor;
> > + int ret = sysinfo_get(&dev);
> > +
> > + if (ret) {
> > + debug("Cannot get sysinfo: %d\n", ret);
> > + return 0;
>
> Why do we ignore errors here ?
>
> > + }
> > +
> > + ret = sysinfo_detect(dev);
> > + if (ret) {
> > + debug("Cannot detect sysinfo: %d\n", ret);
> > + return 0;
> > + }
>
> Looking at all this, I really have to wonder, wouldn't it be nicer to
> introduce a 'sysinfo' command which provides interface to obtain the
> different properties (like board name, id, revision ...) from U-Boot
> command line, and then script the DT selection in U-Boot shell ?
Yes, that could be a good option. This is more based on how raspberry pis are
selecting the correct devicetree in `board/raspberrypi/rpi/rpi.c`.
It is either about having simple shell scripts that are similar between
devices and the implementation is "hidden" in C for each platform (maybe
easier to use but less flexible). Or more complex shell scripts with simpler C
implementation (more flexible but having to modify a boot script can become
complicated for users)
Has this direction choice been discussed in the past already ?
Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree
On 6/14/23 17:10, Detlev Casanova wrote:
On Wednesday, June 14, 2023 9:53:14 A.M. EDT Marek Vasut wrote:
On 6/12/23 21:51, Detlev Casanova wrote:
The Renesas R-Car Gen3 boards use different device trees than
the default one.
This commit uses the sysinfo's board id and revision
to determine which linux device tree to load:
* H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb
* H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb
This is not about loading DTs (as the subject would suggest), this is
about setting the correct default DT name in environment.
Signed-off-by: Detlev Casanova
---
board/renesas/ulcb/ulcb.c| 59
configs/rcar3_ulcb_defconfig | 1 +
2 files changed, 60 insertions(+)
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 1477750f921..cc78e0952b6 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -65,6 +66,64 @@ int board_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ struct udevice *dev;
+ int board_id;
+ int rev_major, rev_minor;
+ int ret = sysinfo_get(&dev);
+
+ if (ret) {
+ debug("Cannot get sysinfo: %d\n", ret);
+ return 0;
Why do we ignore errors here ?
+ }
+
+ ret = sysinfo_detect(dev);
+ if (ret) {
+ debug("Cannot detect sysinfo: %d\n", ret);
+ return 0;
+ }
Looking at all this, I really have to wonder, wouldn't it be nicer to
introduce a 'sysinfo' command which provides interface to obtain the
different properties (like board name, id, revision ...) from U-Boot
command line, and then script the DT selection in U-Boot shell ?
Yes, that could be a good option. This is more based on how raspberry pis are
selecting the correct devicetree in `board/raspberrypi/rpi/rpi.c`.
It is either about having simple shell scripts that are similar between
devices and the implementation is "hidden" in C for each platform (maybe
easier to use but less flexible). Or more complex shell scripts with simpler C
implementation (more flexible but having to modify a boot script can become
complicated for users)
Has this direction choice been discussed in the past already ?
The less hard-coded board code (which cannot be updated by the user
easily), the better. Scripts can be updated in deployment far easier
than the bootloader itself. Hence the push for scripts over custom C code.
Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree
On Wednesday, June 14, 2023 11:32:31 A.M. EDT Marek Vasut wrote:
> On 6/14/23 17:10, Detlev Casanova wrote:
> > On Wednesday, June 14, 2023 9:53:14 A.M. EDT Marek Vasut wrote:
> >> On 6/12/23 21:51, Detlev Casanova wrote:
> >>> The Renesas R-Car Gen3 boards use different device trees than
> >>> the default one.
> >>>
> >>> This commit uses the sysinfo's board id and revision
> >>>
> >>> to determine which linux device tree to load:
> >>>* H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb
> >>>* H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb
> >>
> >> This is not about loading DTs (as the subject would suggest), this is
> >> about setting the correct default DT name in environment.
> >>
> >>> Signed-off-by: Detlev Casanova
> >>> ---
> >>>
> >>>board/renesas/ulcb/ulcb.c| 59
> >>>
> >>>configs/rcar3_ulcb_defconfig | 1 +
> >>>2 files changed, 60 insertions(+)
> >>>
> >>> diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
> >>> index 1477750f921..cc78e0952b6 100644
> >>> --- a/board/renesas/ulcb/ulcb.c
> >>> +++ b/board/renesas/ulcb/ulcb.c
> >>> @@ -27,6 +27,7 @@
> >>>
> >>>#include
> >>>#include
> >>>#include
> >>>
> >>> +#include
> >>>
> >>>DECLARE_GLOBAL_DATA_PTR;
> >>>
> >>> @@ -65,6 +66,64 @@ int board_init(void)
> >>>
> >>> return 0;
> >>>
> >>>}
> >>>
> >>> +int misc_init_r(void)
> >>> +{
> >>> + struct udevice *dev;
> >>> + int board_id;
> >>> + int rev_major, rev_minor;
> >>> + int ret = sysinfo_get(&dev);
> >>> +
> >>> + if (ret) {
> >>> + debug("Cannot get sysinfo: %d\n", ret);
> >>> + return 0;
> >>
> >> Why do we ignore errors here ?
> >>
> >>> + }
> >>> +
> >>> + ret = sysinfo_detect(dev);
> >>> + if (ret) {
> >>> + debug("Cannot detect sysinfo: %d\n", ret);
> >>> + return 0;
> >>> + }
> >>
> >> Looking at all this, I really have to wonder, wouldn't it be nicer to
> >> introduce a 'sysinfo' command which provides interface to obtain the
> >> different properties (like board name, id, revision ...) from U-Boot
> >> command line, and then script the DT selection in U-Boot shell ?
> >
> > Yes, that could be a good option. This is more based on how raspberry pis
> > are selecting the correct devicetree in `board/raspberrypi/rpi/rpi.c`. It
> > is either about having simple shell scripts that are similar between
> > devices and the implementation is "hidden" in C for each platform (maybe
> > easier to use but less flexible). Or more complex shell scripts with
> > simpler C implementation (more flexible but having to modify a boot
> > script can become complicated for users)
> >
> > Has this direction choice been discussed in the past already ?
>
> The less hard-coded board code (which cannot be updated by the user
> easily), the better. Scripts can be updated in deployment far easier
> than the bootloader itself. Hence the push for scripts over custom C code.
That makes sense. I'll create a new command for this then and use it to select
the dtb in the ulcb boards script.
Re: [PATCH v2 3/3] renesas: rcar3: Load the correct device tree
On 6/14/23 17:40, Detlev Casanova wrote:
On Wednesday, June 14, 2023 11:32:31 A.M. EDT Marek Vasut wrote:
On 6/14/23 17:10, Detlev Casanova wrote:
On Wednesday, June 14, 2023 9:53:14 A.M. EDT Marek Vasut wrote:
On 6/12/23 21:51, Detlev Casanova wrote:
The Renesas R-Car Gen3 boards use different device trees than
the default one.
This commit uses the sysinfo's board id and revision
to determine which linux device tree to load:
* H3 (Starter Kit Premier v2.0): renesas/r8a77951-ulcb.dtb
* H3e (Starter Kit Premier v2.1): renesas/r8a779m1-ulcb.dtb
This is not about loading DTs (as the subject would suggest), this is
about setting the correct default DT name in environment.
Signed-off-by: Detlev Casanova
---
board/renesas/ulcb/ulcb.c| 59
configs/rcar3_ulcb_defconfig | 1 +
2 files changed, 60 insertions(+)
diff --git a/board/renesas/ulcb/ulcb.c b/board/renesas/ulcb/ulcb.c
index 1477750f921..cc78e0952b6 100644
--- a/board/renesas/ulcb/ulcb.c
+++ b/board/renesas/ulcb/ulcb.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -65,6 +66,64 @@ int board_init(void)
return 0;
}
+int misc_init_r(void)
+{
+ struct udevice *dev;
+ int board_id;
+ int rev_major, rev_minor;
+ int ret = sysinfo_get(&dev);
+
+ if (ret) {
+ debug("Cannot get sysinfo: %d\n", ret);
+ return 0;
Why do we ignore errors here ?
+ }
+
+ ret = sysinfo_detect(dev);
+ if (ret) {
+ debug("Cannot detect sysinfo: %d\n", ret);
+ return 0;
+ }
Looking at all this, I really have to wonder, wouldn't it be nicer to
introduce a 'sysinfo' command which provides interface to obtain the
different properties (like board name, id, revision ...) from U-Boot
command line, and then script the DT selection in U-Boot shell ?
Yes, that could be a good option. This is more based on how raspberry pis
are selecting the correct devicetree in `board/raspberrypi/rpi/rpi.c`. It
is either about having simple shell scripts that are similar between
devices and the implementation is "hidden" in C for each platform (maybe
easier to use but less flexible). Or more complex shell scripts with
simpler C implementation (more flexible but having to modify a boot
script can become complicated for users)
Has this direction choice been discussed in the past already ?
The less hard-coded board code (which cannot be updated by the user
easily), the better. Scripts can be updated in deployment far easier
than the bootloader itself. Hence the push for scripts over custom C code.
That makes sense. I'll create a new command for this then and use it to select
the dtb in the ulcb boards script.
Thanks !
Re: [PATCH V3 8/8] configs: am62x_evm_a53: Add bloblist address
On Wed, Jun 14, 2023 at 03:04:40PM +0530, Nikhil M Jain wrote: > Set bloblist address to 0x80D0. > > Below is the link to updated memory map: > > Link: > https://gist.github.com/NikMJain/5686f7f976c18a359762b52d474dc07b#file-am62x-a53_spl_memory_map-rst > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar > --- > V3: > - Add link to updated memory map. > > V2: > - Add Reviewed-by tag. > > configs/am62x_evm_a53_defconfig | 1 + > 1 file changed, 1 insertion(+) Please update the in tree documentation, not point to an external gist. -- Tom signature.asc Description: PGP signature
Re: [PATCH V3 6/8] drivers: video: Kconfig: Add config remove video
On Wed, Jun 14, 2023 at 03:04:38PM +0530, Nikhil M Jain wrote: > This is required since user may want to either call the remove method > of video driver and reset the display or not call the remove method > to continue displaying until next stage. > > Signed-off-by: Nikhil M Jain > Reviewed-by: Devarsh Thakkar Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [v1] disable NFS support by default
On Wed, Jun 14, 2023 at 03:41:10PM +0100, Peter Robinson wrote: > While NFS is widely used in data centres, and private > networks it's quite a nuanced usecase for device firmware. > A lot of devices already disable it. > > Various network protocols should really be opt in, not opt > out, because they add extra size and are potential attack > vectors from a security PoV. In the NFS case it doesn't > really make sense for a lot of devices like tables, SBCs etc. > It's also something we don't really want for SystemReady-IR > due to security concerns. > > Signed-off-by: Peter Robinson Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH] riscv: add backtrace support
On 14/06/2023 07:25, Bo Gan wrote: On 5/25/23 4:05 AM, Ben Dooks wrote: On 15/05/2023 14:03, Ben Dooks wrote: When debugging, it is useful to have a backtrace to find out what is in the call stack as the previous function (RA) may not have been the culprit. Since this adds size to the build, do not add it by default and avoid putting it in the SPL build if not needed. Hi, has anyone had time to review this? Hi Ben, this looks really useful. I'd like to use it in SPL, but I'm unable to enable CONFIG_SPL_FRAMEPOINTER=y. It's likely that you need to add a SPL_FRAMEPOINTER entry to Kconfig as well. I will have a look at this, but testing may not be easy as the setup we're using has limited SPL space. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html
Re: [PATCH v2 5/5] rockchip: rockpro64: Build u-boot-rockchip-spi.bin
On 2023-06-14 09:46, Peter Robinson wrote: > On Tue, Jun 13, 2023 at 7:48 PM Jonas Karlman wrote: >> >> Hi Peter, >> >> On 2023-06-13 09:58, Peter Robinson wrote: >>> On Mon, Jun 12, 2023 at 11:20 PM Jonas Karlman wrote: Hi Peter, On 2023-06-11 22:22, Peter Robinson wrote: > Hi Jonas, > > This regresses the Rockpro64 build for me when building with gcc 12/13 > with the following error, if I remove CONFIG_LTO it builds, but > overlaps. > > /usr/bin/aarch64-linux-gnu-ld: > /usr/lib/gcc/aarch64-linux-gnu/13/libgcc.a(lse-init.o): in function > `init_have_lse_atomics': > /builddir/build/BUILD/gcc-13.1.1-20230519/aarch64-linux-gnu/aarch64-linux-gnu/libgcc/../../../gcc-13.1.1-20230519/libgcc/config/aarch64/lse-init.c:46: > undefined reference to `__getauxval' > collect2: fatal error: ld terminated with signal 11 [Segmentation > fault], core dumped > compilation terminated. Interesting, my test build using ubuntu-22.04 and gcc-12 did not seem to fail, see [1]. Compiling with -mno-outline-atomics flag may work, not sure that is a good workaround. >>> >>> I would prefer a fix. >> >> Not sure what such fix could be, cross compiling in CI and under ubuntu >> 22.04 does not trigger this linking issue, not sure what is different in >> your build environment to not allow build with CONFIG_LTO=y. >> >> Searching for similar linking issue suggest it could be related to >> outline-atomics, do you use any special C/LDFLAGS or similar? >> >>> An alternative could be to move the payload to @ 512KB instead of @ 384KB. >>> >>> What impact will moving this around have on upgrades? I am not sure we >>> should be randomly moving stuff without knowing the impact TBH. Will >>> this break existing users vs what you feel is appropriate for your >>> usecase? >> >> I did a re-calculation and using @ 512 KB offset may not be enough >> for a worst-case scenario. >> >> mkimage will enforce a 184 KB limit for the TPL on RK3399. With SPL >> loaded at 0x0 and TF-A loaded to 0x4, we have a 256 KB size limit of >> SPL. BootRom that loads both TPL and SPL only read first 2 KB of every >> 4 KB page of SPI flash, so idbloader.img (TPL+SPL) could grow up to >> ~880 KB in a worst-case scenario. (184+256) x 2 = 880 >> >> Using a payload offset of @ 896 KB (0xE) is probably the safest >> default option if we need to revert the CONFIG_LTO=y change. >> >> As long as u-boot-rockchip-spi.bin is used to update SPI flash changing >> offset should not have an impact. However, there are guides and scripts >> that write idbloader.img and u-boot.itb separately, those could break. > > Well I believe your patch only enabled that option by default so most > users I suspect write them separately up until now, does the new > offsets affect existing env variables at all? It does not look like it will overwrite env offset. CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 There will be room for a 3168 KB u-boot.itb payload until it would overlap env in SPI flash with a 0xE offset for u-boot.itb. Also look like many RK3399 defconfig have a SPL_MAX_SIZE=0x2e000, something that could be increased to SPL_MAX_SIZE=0x4 with an updated offset for u-boot.itb. I will prepare a small fix series that address your LTO issue and use proper offsets and max size options. > >> Such guides and scripts can already lead to users overwriting part of >> SPL when the produced idbloader.img is over 384 KB in size. >> With CONFIG_ROCKCHIP_SPI_IMAGE=y the size of idbloader.img is instead >> enforced to not cause an overlap of the u-boot.itb at build time. > > Ultimately I would prefer to not actively break existing users if > they're not aware of changes, and that is hard to communicate. People > with broken devices tend to scream a lot. Such change will not actively break existing users, SPL look for a FIT header and will fall back to next media in u-boot,spl-boot-order. Will include an update to SPI flash section of rockchip.rst to mention how to properly flash to correct offset using u-boot-rockchip-spi.bin in the fix series. Regards, Jonas > >> Regards, >> Jonas >> >>> configs/rockpro64-rk3399_defconfig: CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 arch/arm/dts/rk3399-rockpro64-u-boot.dtsi: u-boot,spl-payload-offset = <0x8>; [1] https://github.com/Kwiboo/u-boot-build/actions/runs/5248398191/jobs/9479827969 Regards, Jonas > > Peter > > On Wed, May 17, 2023 at 7:41 PM Jonas Karlman wrote: >> >> Enable CONFIG_ROCKCHIP_SPI_IMAGE to build u-boot-rockchip-spi.bin. >> Define CONFIG_SYS_SPI_U_BOOT_OFFS to write u-boot.itb at the expected >> offset. Enable CONFIG_LTO to reduce size of SPL so that the mkimage >> output fit before the 0x6 offset in u-boot-rockchip-spi.bin. >> >> => sf probe >> SF: Detected gd25q128 with page size 256 Bytes, erase
Re: [PATCH u-boot 0/3] Revert broken Bootmenu commits
On Sun, Jun 11, 2023 at 02:53:21PM +0200, Pali Rohár wrote: > These 3 commits broke support for U-Boot Bootmenu on Nokia N900. > Issues were reported more than month ago, but nobody reacted to them. > So revert these broken commits for now, to fix U-Boot Bootmenu support. > > With these revered commits, U-Boot Bootmenu from master branch is > working fine again on Nokia N900. > > Pali Rohár (3): > Revert "video: Enable VIDEO_ANSI by default only with EFI" > Revert "menu: Factor out menu-keypress decoding" > Revert "menu: Make use of CLI character processing" > > cmd/bootmenu.c| 9 ++-- > cmd/eficonfig.c | 12 ++--- > common/cli_getch.c| 12 ++--- > common/menu.c | 122 ++ > drivers/video/Kconfig | 7 +-- > include/cli.h | 4 +- > include/menu.h| 17 +- > 7 files changed, 91 insertions(+), 92 deletions(-) Following up over here, while https://patchwork.ozlabs.org/project/uboot/patch/20230612201434.861700-1-...@chromium.org/ addresses some of the issues, but not all (as it clearly isn't working in all of the cases Pali has explained), looking in to the VIDEO_ANSI part of this too, all three of these reverts are related seemingly to something escape-character related. I'm not taking any of the revert commits in just yet, but will by the next -rc if we don't have something that fixes all of the issues. -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootstd: Make BOOTSTD_FULL depend on BOOTSTD
On Wed, Feb 22, 2023 at 02:06:23PM -0700, Simon Glass wrote: > Move BOOTSTD_FULL down in the file so that it can be enabled only when > BOOTSTD is enabled. This prevents a build error if BOOTSTD is disabled > but BOOTSTD_FULL is enabled. > > Signed-off-by: Simon Glass > Reviewed-by: Ilias Apalodimas Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] spl: ext: Use partition size for mount
On Tue, May 02, 2023 at 09:40:20PM +0530, Mayuresh Chitale wrote:
> Since commit 9905cae65e03 ("fs: ext4: check the minimal partition size
> to mount"), a valid size needs to be provided when mounting
> an ext filesystem. Fix the spl ext driver to use the parition size
> instead of 0 when mounting the filesystem.
>
> Signed-off-by: Mayuresh Chitale
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] net: rtl8169: add depends on PCI
On Wed, May 17, 2023 at 01:41:24PM +0300, Eugen Hristev wrote: > The rtl8169 driver uses calls to dm_pci_bus_to_phys, > which are compiled under CONFIG_PCI. > > Without CONFIG_PCI, this happens: > > drivers/net/rtl8169.o: in function `rtl_recv_common': > drivers/net/rtl8169.c:555: undefined reference to `dm_pci_bus_to_phys' > > It is only natural that this driver depends on CONFIG_PCI then. > The device does not work connected in another way anyway, and the driver > does not assume anything else at this moment. > > Signed-off-by: Eugen Hristev > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] net: ipv6: Fix CID 453851 and CID 436278
On Thu, May 18, 2023 at 12:35:40PM -0700, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > CID 453851 : sprintf() shouldn't copy from/to tmp > CID 436278 : DHCP6 option_len should be checked before use > > Signed-off-by: Sean Edmond > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] net: dhcp6: Fix VCI string
On Thu, May 18, 2023 at 12:35:41PM -0700, seanedm...@linux.microsoft.com wrote: > From: Sean Edmond > > Change VCI string from "U-boot" to "U-Boot". > > Signed-off-by: Sean Edmond > Reviewed-by: Ramon Fried Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] bootstd: Fix relative path use in extlinux bootmeth
On Fri, Jun 09, 2023 at 02:59:01PM +, Jonas Karlman wrote:
> Using relative path in a /boot/extlinux/extlinux.conf file fails to load
> linux kernel.
>
> Using a /boot/extlinux/extlinux.conf file:
>
> LABEL test
> LINUX ../linux/Image
>
> Result in following error:
>
> Retrieving file: ../linux/Image
> Skipping test for failure retrieving kernel
> Boot failed (err=-14)
>
> However, using sysboot cmd successfully load kernel using same file:
>
> sysboot mmc 1:1 any ${scriptaddr} /boot/extlinux/extlinux.conf
>
> Retrieving file: /boot/extlinux/../linux/Image
>
> Fix relative path using bootmeth extlinux by supplying bootfile path
> instead of subdir path in the call to pxe_setup_ctx, same as done in the
> sysboot command.
>
> Fixes: 31aefaf89a5b ("bootstd: Add an implementation of distro boot")
> Signed-off-by: Jonas Karlman
> Reviewed-by: Simon Glass
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] rockchip: Pinephone Pro: Add DDR RAM type config
On Sun, Jun 11, 2023 at 06:18:34PM +0100, Peter Robinson wrote: > Add the RAM_ROCKCHIP_LPDDR4 to fix the Pinephone Pro booting. > When the configs were updated in 26f92be07e2 it somehow broke > the PPP boot process so let's fix it. > > Signed-off-by: Peter Robinson > CC: Jagan Teki > CC: Kever Yang Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 06/10] dt-bindings: spi: Add bcm63xx-hsspi controller support
Hi Jagan, On 06/11/2023 03:43 AM, Jagan Teki wrote: On Thu, Jun 8, 2023 at 5:08 AM William Zhang wrote: Bring the device tree binding document from Linux to u-boot Port from linux patches: Link: https://lore.kernel.org/r/20230207065826.285013-2-william.zh...@broadcom.com Link: https://lore.kernel.org/r/20230207065826.285013-3-william.zh...@broadcom.com Signed-off-by: William Zhang --- Reviewed-by: Jagan Teki Applied to u-boot-spi/master Thank you for accepting the patches. Do you mind to take the rest of the patches in the series as Tom was suggesting it is better to apply the whole thing and there is a dependency on patch 9 if you actually want to build with CONFIG_BCMBCA_HSSPI enabled? If not, maybe Tom can you please apply at least patch 6 to 10 of the series to the u-boot git, if there is no other concern and works for you? smime.p7s Description: S/MIME Cryptographic Signature
[PATCH v1] net: sun8i-emac: Add support for fixed-link phy
From: Maksim Kiselev
Based on dt-specs fixed-link doesn't require phy-handle to be used.
Fix driver to only read phy related setting when phy-handle is found.
Signed-off-by: Maksim Kiselev
---
drivers/net/sun8i_emac.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c
index 04c3274fbe..0e339d69e0 100644
--- a/drivers/net/sun8i_emac.c
+++ b/drivers/net/sun8i_emac.c
@@ -834,11 +834,8 @@ static int sun8i_emac_eth_of_to_plat(struct udevice *dev)
priv->use_internal_phy = false;
offset = fdtdec_lookup_phandle(gd->fdt_blob, node, "phy-handle");
- if (offset < 0) {
- debug("%s: Cannot find PHY address\n", __func__);
- return -EINVAL;
- }
- priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
+ if (offset >= 0)
+ priv->phyaddr = fdtdec_get_int(gd->fdt_blob, offset, "reg", -1);
pdata->phy_interface = dev_read_phy_mode(dev);
debug("phy interface %d\n", pdata->phy_interface);
--
2.39.2
Re: [RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support
On Mon, 12 Jun 2023 15:18:17 -0600 Sam Edwards wrote: Hi Sam, > On 6/11/23 18:20, Andre Przywara wrote: > > Thanks for the update and the list! Can you confirm where you > > still needed code changes compared to say my github branch plus the > > changes we already discussed? Trying some guesses below, please confirm > > or deny: > > Pretyyy much everything I've changed locally has been submitted > to the list or discussed in the relevant patchset. Have you updated your > GitHub branch recently (past couple of weeks)? I haven't been watching > it but I can pull it again and see which of my local changes are still > required. So I finally found some time to address some issues in the series, especially in the first patches (pinctrl rework and preparation). I pushed a branch to https://github.com/apritzel/u-boot/commits/r528-rc I need to do more testing, most importantly regression testing on other SoCs, and will only be able to post something next week, I guess. If you could briefly list the things that are still missing, I could try to pick some low hanging fruits. > >> I have a build of U-Boot for my target, complete with: > >> - UART3 initialized correctly > > > > this is problematic because of the other pinmux used on your board, > > which cannot easily be encoded alongside the existing UART3 pinmux? > > Actually no, my board's UART3 is on PB6/PB7, nice and standard. > > >> - DRAM coming up correctly > >> - SPL sets configured boot clock correctly > > > > This should work as per github? > > Yep, everything was working satisfactorily once I figured out I needed > to set CONFIG_SYS_CLK_FREQ to get acceptable boot speeds. Interesting, indeed this is left at 0, which I think will result in 288 MHz. What is that frequency in your case? Do you know what the BSP programs? Traditionally we used something conservative that works without cooling and with the default voltage, but I don't know that value for the T113s. > >> - SPI-NAND support (SPL and U-Boot proper) > > > > This is with Icenow's series? Any D1 specific changes needed there? > > Yes, with Icenowy's series (322733). > > I learned that the BROM sets the boot medium code to 0x04 when it's an > SPI-*NAND* (while older chips used 0x03 for "it's either SPI-NOR or > SPI-NAND, good luck figuring out which"). Since `env_get_location` > assumes BOOT_DEVICE_SPI is NOR (and my target needs to load env from UBI > iff booting from NAND), I'm hoping I can convince Icenowy to separate > out the SPI-NAND and SPI-NOR load methods entirely (vs. her current > try-NAND-then-NOR approach) with the aid of some disambiguation logic to > probe for an SPI-NAND on the older chips known to report these as 0x03. > > I also needed Maksim's patch series (355747) to support the D1 SPI master. > > >> - MMC support (SPL and U-Boot proper) > >> - SPL boot from FEL > > > > again worked already in github? > > Yes and yes. I was just confirming they're good; no local work needed > from me here. > > >> - USB gadget support > > > > So with the fixed SUNXI_SRAMC_BASE you said it worked? What about the > > USB PHY? That needs at least wiring in the compatible string? If you > > have such a patch, can you please rebase it on top of my v2 USB PHY > > series and post that? > > Yes, with corrected SUNXI_SRAMC_BASE -- though I also needed my patches > to make musb-new/sunxi.c use the UDC gadget model in DM (series 358842), > as I don't think there's another way to init the controller at runtime. > > I can't say whether the endpoint limit is correct or that mUSB *host* > operation works. > > The USB PHY only required that CONFIG_PHY_SUN4I_USB be enabled. The > correct compatible is already wired up. It does look like your PHY > series drops the explicit requirement to set PHY_SUN4I_USB so that's > better than what I was doing (adding a `select` directive under R528). Ah, right, we already merged the "allwinner,sun20i-d1-usb-phy" patch. > I can test your series if you want but I doubt it intersects my work > here in any significant way. > > >> - Ethernet MAC+PHY support > > > > Anything surprising here? Is that using an already supported external > > PHY? > > The only surprise was this was how I noticed that CONFIG_CLK_SUN20I_D1 > was not being implicitly enabled. Enabling that was then how I found > that the clock driver wasn't compatible with current upstream (which I > already mentioned). I think CLK_SUN20I_D1 should be set by default now, so can you check that this is fixed? > The PHY is external and already supported, adding it to my DT required > very little work. > > >> - I²C support * > >> - GPIO support (LEDs, buttons, misc. board management) > > > > again should work out of the box, minus your board specific > > configuration? > > GPIO is completely OotB, yes. I²C is OotB once MVTWSI_CONTROL_CLEAR_IFLG > is set correctly. (The pinctrl requirements for it are a little harder, > more on that
[PATCH] net: ti: am65-cpsw-nuss: Use dedicated port mode control registers
The different CPSW sub-system Ethernet ports have different PHY mode
control registers. In order to allow the modes to get configured
independently only the register for the port in question must be
accessed, otherwise we would just be re-configuring the mode for port 1,
while leaving all others at their power-on defaults. Fix this issue by
adding a port-number based offset to the mode control base register
address based on the fact that the control registers for the different
ports are spaced exactly 0x4 bytes apart.
Fixes: 9d0dca1199d1 ("net: ethernet: ti: Introduce am654 gigabit eth switch
subsystem driver")
Signed-off-by: Andreas Dannenberg
Reviewed-by: Siddharth Vadapalli
---
Driver changes bench-tested on an SK-AM62 EVM by iterating through
different variations of RGMII and RMII modes for CPSW ports 1 and 2 and
checking operation as well as CTRL_ENET1_CTRL and CTRL_ENET2_CTRL
control register contents from the U-Boot command line via 'md.l'.
Testing was done on top of today's 'next' branch.
drivers/net/ti/am65-cpsw-nuss.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f674b0baa3..523a4c9f91 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -223,6 +223,8 @@ out:
return phy->link;
}
+#define AM65_GMII_SEL_PORT_OFFS(x) (0x4 * ((x) - 1))
+
#define AM65_GMII_SEL_MODE_MII 0
#define AM65_GMII_SEL_MODE_RMII1
#define AM65_GMII_SEL_MODE_RGMII 2
@@ -233,11 +235,12 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
phy_interface_t phy_mode, int slave)
{
struct am65_cpsw_common *common = priv->cpsw_common;
+ fdt_addr_t gmii_sel = common->gmii_sel + AM65_GMII_SEL_PORT_OFFS(slave);
u32 reg;
u32 mode = 0;
bool rgmii_id = false;
- reg = readl(common->gmii_sel);
+ reg = readl(gmii_sel);
dev_dbg(common->dev, "old gmii_sel: %08x\n", reg);
@@ -273,9 +276,9 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv
*priv,
reg = mode;
dev_dbg(common->dev, "gmii_sel PHY mode: %u, new gmii_sel: %08x\n",
phy_mode, reg);
- writel(reg, common->gmii_sel);
+ writel(reg, gmii_sel);
- reg = readl(common->gmii_sel);
+ reg = readl(gmii_sel);
if (reg != mode)
dev_err(common->dev,
"gmii_sel PHY mode NOT SET!: requested: %08x, gmii_sel:
%08x\n",
--
2.34.1
Re: [PATCH v2 1/3] mmc: Fix MMC_CMD_STOP_TRANSMISSION response type and add comment
On 6/14/2023 9:42 PM, Marek Vasut wrote:
Caution: This is an external email. Please take care when clicking links or
opening attachments. When in doubt, report the message using the 'Report this
email' button
The MMC_CMD_STOP_TRANSMISSION response is R1 for read transfers
per JEDEC Standard No. 84-B51 Page 126 . Correct the response
type and add a comment about it.
Sorry, I may miss one point. CMD12 for SD is R1b. But CMD12
for eMMC is R1 and R1b.
I am not sure how we should do with current code.
Thanks,
Peng.
Signed-off-by: Marek Vasut
---
V2: New patch
---
Cc: "Ying-Chun Liu (PaulLiu)"
Cc: Hai Pham
Cc: Jaehoon Chung
Cc: Loic Poulain
Cc: Peng Fan
Cc: Simon Glass
Cc: Takeshi Kihara
---
drivers/mmc/mmc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 965bc8f0dba..f9b2f940389 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -427,7 +427,12 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
if (blkcnt > 1) {
cmd.cmdidx = MMC_CMD_STOP_TRANSMISSION;
cmd.cmdarg = 0;
- cmd.resp_type = MMC_RSP_R1b;
+ /*
+* JEDEC Standard No. 84-B51 Page 126
+* CMD12 STOP_TRANSMISSION R1/R1b[3]
+* NOTE 3 R1 for read cases and R1b for write cases.
+*/
+ cmd.resp_type = MMC_RSP_R1;
if (mmc_send_cmd(mmc, &cmd, NULL)) {
#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
pr_err("mmc fail to send stop cmd\n");
--
2.39.2
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi
wrote:
>
> On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
> > hi Takahiro,
> >
> > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> > wrote:
> > >
> > > Hi Sughosh,
> > >
> > > I think this is a good extension to mkeficapsule, but
> > >
> > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > > > Add support for specifying the parameters needed for capsule
> > > > generation through a config file, instead of passing them through
> > > > command-line. Parameters for more than a single capsule file can be
> > > > specified, resulting in generation of multiple capsules through a
> > > > single invocation of the command.
> > > >
> > > > This path is to be used for generating capsules through a make target,
> > > > with the parameters being parsed from the config file.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > tools/Kconfig | 9 +
> > > > tools/Makefile | 1 +
> > > > tools/eficapsule.h | 110
> > > > tools/mkeficapsule.c | 106 +++-
> > > > tools/mkeficapsule_parse.c | 345 +
> > > > 5 files changed, 531 insertions(+), 40 deletions(-)
> > > > create mode 100644 tools/mkeficapsule_parse.c
> > > >
> > > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > > index 539708f277..95f27b7c45 100644
> > > > --- a/tools/Kconfig
> > > > +++ b/tools/Kconfig
> > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > > > optionally sign that file. If you want to enable UEFI capsule
> > > > update feature on your target, you certainly need this.
> > > >
> > > > +config EFI_CAPSULE_CFG_FILE
> > > > + string "Path to the EFI Capsule Config File"
> > > > + default ""
> > > > + help
> > > > + Path to the EFI capsule config file which provides the
> > > > + parameters needed to build capsule(s). Parameters can be
> > > > + provided for multiple payloads resulting in corresponding
> > > > + capsule images being generated.
> > > > +
> > > > menuconfig FSPI_CONF_HEADER
> > > > bool "FlexSPI Header Configuration"
> > > > help
> > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > index d793cf3bec..ef366f3d61 100644
> > > > --- a/tools/Makefile
> > > > +++ b/tools/Makefile
> > > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > > > HOSTLDLIBS_mkeficapsule += \
> > > > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > > > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > > > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> > > >
> > > > # We build some files with extra pedantic flags to try to minimize
> > > > things
> > > > # that won't build on some weird host compiler -- though there are
> > > > lots of
> > > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > > index 072a4b5598..42e66c6d6a 100644
> > > > --- a/tools/eficapsule.h
> > > > +++ b/tools/eficapsule.h
> > > > @@ -52,6 +52,38 @@ typedef struct {
> > > > /* flags */
> > > > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> > > >
> > > > +enum capsule_type {
> > > > + CAPSULE_NORMAL_BLOB = 0,
> > > > + CAPSULE_ACCEPT,
> > > > + CAPSULE_REVERT,
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct efi_capsule_params - Capsule parameters
> > > > + * @image_guid: Guid value of the payload input image
> > > > + * @image_index: Image index value
> > > > + * @hardware_instance: Hardware instance to be used for the image
> > > > + * @monotonic_count: Monotonic count value to be used for signed
> > > > capsule
> > > > + * @privkey_file: Path to private key used in capsule signing
> > > > + * @cert_file: Path to public key certificate used in capsule signing
> > > > + * @input_file: Path to payload input image
> > > > + * @capsule_file: Path to the output capsule file
> > > > + * @oemflags: Oemflags to be populated in the capsule header
> > > > + * @capsule: Capsule Type, normal or accept or revert
> > > > + */
> > > > +struct efi_capsule_params {
> > > > + efi_guid_t *image_guid;
> > > > + unsigned long image_index;
> > > > + unsigned long hardware_instance;
> > > > + uint64_t monotonic_count;
> > > > + char *privkey_file;
> > > > + char *cert_file;
> > > > + char *input_file;
> > > > + char *capsule_file;
> > > > + unsigned long oemflags;
> > > > + enum capsule_type capsule;
> > > > +};
> > > > +
> > > > struct efi_capsule_header {
> > > > efi_guid_t capsule_guid;
> > > > uint32_t header_size;
> > > > @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> > > > struct win_certificate_uefi_guid auth_info;
> > > > } __packed;
> > > >
> > > > +/**
> > > > + * capsule_with_cfg_file() - Generate capsule from config file
> > > > + * @cfg_file: Path to the config file
> > > > + *
> > > > + * Parse the capsule parameters from the config file and use the
> > > > + * para
Re: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to support aclint
> > From: Bin Meng > > Sent: Monday, June 12, 2023 3:36 PM > > To: u-boot@lists.denx.de > > Cc: Leo Yu-Chi Liang(梁育齊) ; Rick Jian-Zhi Chen(陳建志) > > > > Subject: [PATCH 2/3] riscv: clint: Update the sifive clint ipi driver to > > support aclint > > > > This RISC-V ACLINT specification [1] defines a set of memory mapped devices > > which provide inter-processor interrupts (IPI) and timer functionalities > > for each HART on a multi-HART RISC-V platform. > > > > The RISC-V ACLINT specification is defined to be backward compatible with > > the SiFive CLINT specification, however the device tree binding is a new > > one. This change updates the sifive clint ipi driver to support ACLINT mswi > > device, by checking the per-driver data field of the ACLINT mtimer driver > > to determine whether a syscon based approach needs to be taken to get the > > base address of the ACLINT mswi device. > > > > [1] https://github.com/riscv/riscv-aclint/blob/main/riscv-aclint.adoc > > > > Signed-off-by: Bin Meng > > LGTM. Sorry, forgot the signed up. Reviewed-by: Rick Chen > > Thanks, > Rick
Re: [PATCH 3/3] riscv: Rename SiFive CLINT to RISC-V ALINT
> From: Bin Meng
> Sent: Monday, June 12, 2023 3:36 PM
> To: u-boot@lists.denx.de
> Cc: Andre Przywara ; Anup Patel
> ; Jonas Schwöbel ; Kautuk
> Consul ; Leo Yu-Chi Liang(梁育齊)
> ; Michael Walle ; Michal Simek
> ; Nikita Shubin ; Rick Jian-Zhi
> Chen(陳建志) ; Sean Anderson ; Sergei
> Antonov ; Simon Glass ; Stefan
> Herbrechtsmeier ; Svyatoslav Ryhel
> ; Tianrui Wei ; William Zhang
> ; Yanhong Wang ;
> Peter Yu-Chien Lin(林宇謙)
> Subject: [PATCH 3/3] riscv: Rename SiFive CLINT to RISC-V ALINT
>
> As the RISC-V ACLINT specification is defined to be backward compatible with
> the SiFive CLINT specification, we rename SiFive CLINT to RISC-V ALINT in the
> source tree to be future-proof.
>
> Signed-off-by: Bin Meng
>
> ---
>
> MAINTAINERS | 2 +-
> arch/riscv/Kconfig| 8
> arch/riscv/cpu/fu540/Kconfig | 2 +-
> arch/riscv/cpu/fu740/Kconfig | 2 +-
> arch/riscv/cpu/generic/Kconfig| 4 ++--
> arch/riscv/cpu/jh7110/Kconfig | 2 +-
> arch/riscv/include/asm/global_data.h | 4 ++--
> arch/riscv/include/asm/syscon.h | 2 +-
> arch/riscv/lib/Makefile | 2 +-
> .../lib/{sifive_clint.c => aclint_ipi.c} | 16 +++
> board/openpiton/riscv64/Kconfig | 2 +-
> board/sipeed/maix/Kconfig | 2 +-
> drivers/timer/Makefile| 2 +-
> ...ive_clint_timer.c => riscv_aclint_timer.c} | 20 +--
> 14 files changed, 35 insertions(+), 35 deletions(-) rename
> arch/riscv/lib/{sifive_clint.c => aclint_ipi.c} (73%) rename
> drivers/timer/{sifive_clint_timer.c => riscv_aclint_timer.c} (75%)
Reviewed-by: Rick Chen
Re: [PATCH 4/7] tools: mkeficapsule: Add support for parsing capsule params from config file
On Thu, Jun 15, 2023 at 10:09:06AM +0530, Sughosh Ganu wrote:
> On Wed, 14 Jun 2023 at 11:23, Takahiro Akashi
> wrote:
> >
> > On Wed, Jun 14, 2023 at 10:56:23AM +0530, Sughosh Ganu wrote:
> > > hi Takahiro,
> > >
> > > On Wed, 14 Jun 2023 at 09:09, Takahiro Akashi
> > > wrote:
> > > >
> > > > Hi Sughosh,
> > > >
> > > > I think this is a good extension to mkeficapsule, but
> > > >
> > > > On Tue, Jun 13, 2023 at 04:08:03PM +0530, Sughosh Ganu wrote:
> > > > > Add support for specifying the parameters needed for capsule
> > > > > generation through a config file, instead of passing them through
> > > > > command-line. Parameters for more than a single capsule file can be
> > > > > specified, resulting in generation of multiple capsules through a
> > > > > single invocation of the command.
> > > > >
> > > > > This path is to be used for generating capsules through a make target,
> > > > > with the parameters being parsed from the config file.
> > > > >
> > > > > Signed-off-by: Sughosh Ganu
> > > > > ---
> > > > > tools/Kconfig | 9 +
> > > > > tools/Makefile | 1 +
> > > > > tools/eficapsule.h | 110
> > > > > tools/mkeficapsule.c | 106 +++-
> > > > > tools/mkeficapsule_parse.c | 345
> > > > > +
> > > > > 5 files changed, 531 insertions(+), 40 deletions(-)
> > > > > create mode 100644 tools/mkeficapsule_parse.c
> > > > >
> > > > > diff --git a/tools/Kconfig b/tools/Kconfig
> > > > > index 539708f277..95f27b7c45 100644
> > > > > --- a/tools/Kconfig
> > > > > +++ b/tools/Kconfig
> > > > > @@ -98,6 +98,15 @@ config TOOLS_MKEFICAPSULE
> > > > > optionally sign that file. If you want to enable UEFI capsule
> > > > > update feature on your target, you certainly need this.
> > > > >
> > > > > +config EFI_CAPSULE_CFG_FILE
> > > > > + string "Path to the EFI Capsule Config File"
> > > > > + default ""
> > > > > + help
> > > > > + Path to the EFI capsule config file which provides the
> > > > > + parameters needed to build capsule(s). Parameters can be
> > > > > + provided for multiple payloads resulting in corresponding
> > > > > + capsule images being generated.
> > > > > +
> > > > > menuconfig FSPI_CONF_HEADER
> > > > > bool "FlexSPI Header Configuration"
> > > > > help
> > > > > diff --git a/tools/Makefile b/tools/Makefile
> > > > > index d793cf3bec..ef366f3d61 100644
> > > > > --- a/tools/Makefile
> > > > > +++ b/tools/Makefile
> > > > > @@ -250,6 +250,7 @@ HOSTLDLIBS_mkeficapsule += \
> > > > > HOSTLDLIBS_mkeficapsule += \
> > > > > $(shell pkg-config --libs uuid 2> /dev/null || echo "-luuid")
> > > > > hostprogs-$(CONFIG_TOOLS_MKEFICAPSULE) += mkeficapsule
> > > > > +mkeficapsule-objs := mkeficapsule.o mkeficapsule_parse.o
> > > > >
> > > > > # We build some files with extra pedantic flags to try to minimize
> > > > > things
> > > > > # that won't build on some weird host compiler -- though there are
> > > > > lots of
> > > > > diff --git a/tools/eficapsule.h b/tools/eficapsule.h
> > > > > index 072a4b5598..42e66c6d6a 100644
> > > > > --- a/tools/eficapsule.h
> > > > > +++ b/tools/eficapsule.h
> > > > > @@ -52,6 +52,38 @@ typedef struct {
> > > > > /* flags */
> > > > > #define CAPSULE_FLAGS_PERSIST_ACROSS_RESET 0x0001
> > > > >
> > > > > +enum capsule_type {
> > > > > + CAPSULE_NORMAL_BLOB = 0,
> > > > > + CAPSULE_ACCEPT,
> > > > > + CAPSULE_REVERT,
> > > > > +};
> > > > > +
> > > > > +/**
> > > > > + * struct efi_capsule_params - Capsule parameters
> > > > > + * @image_guid: Guid value of the payload input image
> > > > > + * @image_index: Image index value
> > > > > + * @hardware_instance: Hardware instance to be used for the image
> > > > > + * @monotonic_count: Monotonic count value to be used for signed
> > > > > capsule
> > > > > + * @privkey_file: Path to private key used in capsule signing
> > > > > + * @cert_file: Path to public key certificate used in capsule signing
> > > > > + * @input_file: Path to payload input image
> > > > > + * @capsule_file: Path to the output capsule file
> > > > > + * @oemflags: Oemflags to be populated in the capsule header
> > > > > + * @capsule: Capsule Type, normal or accept or revert
> > > > > + */
> > > > > +struct efi_capsule_params {
> > > > > + efi_guid_t *image_guid;
> > > > > + unsigned long image_index;
> > > > > + unsigned long hardware_instance;
> > > > > + uint64_t monotonic_count;
> > > > > + char *privkey_file;
> > > > > + char *cert_file;
> > > > > + char *input_file;
> > > > > + char *capsule_file;
> > > > > + unsigned long oemflags;
> > > > > + enum capsule_type capsule;
> > > > > +};
> > > > > +
> > > > > struct efi_capsule_header {
> > > > > efi_guid_t capsule_guid;
> > > > > uint32_t header_size;
> > > > > @@ -113,4 +145,82 @@ struct efi_firmware_image_authentication {
> > > > > struct w
Re: [PATCH] ARM: stm32: Power cycle Buck3 in reset on DHSOM
On 5/29/23 03:57, Marek Vasut wrote:
Hello again,
[...]
So the backup domain is loosed on ST board with STPMIC1 only when the
power
is removed and not for reset or for power off.
Thank you for the clarification.
I should check suspend/resume on EV1 soon ...
We do have this problem on EV1 too I'm afraid:
# U-Boot 2f4664f5c3e ("Merge branch '2023-06-14-assorted-fixes'")
$ git clean -fqdx ; make stm32mp15_basic_defconfig && make -j$(nproc)
$ dd if=u-boot-spl.stm32 of=/dev/sdX1 && dd if=u-boot-spl.stm32
of=/dev/sdX2 && dd if=u-boot.img of=/dev/sdX3
# Linux next 925294c9aa184 ("Add linux-next specific files for 20230615")
U-Boot SPL 2023.07-rc4-8-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
RAM: DDR3-DDR3L 32bits 533000kHz
WDT: Started watchdog@5a002000 with servicing every 1000ms (32s timeout)
image entry point: 0xc010
U-Boot 2023.07-rc4-8-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
CPU: STM32MP157FAA Rev.Z
Model: STMicroelectronics STM32MP157C eval daughter on eval mother
Board: stm32mp1 in basic mode (st,stm32mp157c-ev1)
Board: MB1263 Var4.0 Rev.C-03
...
boot as usual into Linux with initramfs for simplicity sake
...
$ cat /proc/cmdline
console=ttySTM0,115200 no_console_suspend
# Suspend the system repeatedly (failure happens after 2-3 wake up cycles)
$ while true ; do rtcwake -s 100 -m mem ; done
wakeup from "mem" at Sat Jan 1 00:03:11 2000
[ 39.316598] PM: suspend entry (deep)
[ 39.318905] Filesystems sync: 0.000 seconds
[ 39.324327] Freezing user space processes
[ 39.328194] Freezing user space processes completed (elapsed 0.001
seconds)
[ 39.334006] OOM killer disabled.
[ 39.337158] Freezing remaining freezable tasks
[ 39.342777] Freezing remaining freezable tasks completed (elapsed
0.001 seconds)
[ 39.426015] Disabling non-boot CPUs ...
[ 39.448635] Retrying again to check for CPU kill
[ 39.451909] CPU1 killed.
U-Boot SPL 2023.07-rc4-8-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
RAM: DDR3-DDR3L 32bits 533000kHz
DDR invalid size : 0x4, expected 0x4000
DRAM init failed: -22
### ERROR ### Please RESET the board ###
Press RESET button
U-Boot SPL 2023.07-rc4-8-g2f4664f5c3e (Jun 15 2023 - 08:36:52 +0200)
RAM: DDR3-DDR3L 32bits 533000kHz
DDR invalid size : 0x4, expected 0x4000
DRAM init failed: -22
### ERROR ### Please RESET the board ###
Re: [PATCH v9 08/10] doc: uefi: add anti-rollback documentation
On Wed, 7 Jun 2023 at 19:22, Takahiro Akashi wrote:
>
> On Wed, Jun 07, 2023 at 02:41:58PM +0900, Masahisa Kojima wrote:
> > This commit describe the procedure to configure lowest supported
> > version in the device tree for anti-rollback protection.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > No update since v7
> >
> > Changes in v7:
> > - describe the usage
> >
> > Newly created in v6
> >
> > doc/develop/uefi/uefi.rst | 39 +++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
> > index 30b90a09d5..ffd13cebe9 100644
> > --- a/doc/develop/uefi/uefi.rst
> > +++ b/doc/develop/uefi/uefi.rst
> > @@ -537,6 +537,45 @@ where signature.dts looks like::
> > };
> > };
> >
> > +Anti-rollback Protection
> > +
> > +
> > +Anti-rollback prevents unintentional installation of outdated firmware.
> > +To enable anti-rollback, you must add the lowest-supported-version property
> > +to dtb and specify --fw-version when creating a capsule file with the
> > +mkeficapsule tool.
> > +When executing capsule update, U-Boot checks if fw_version is greater than
> > +or equal to lowest-supported-version. If fw_version is less than
> > +lowest-supported-version, the update will fail.
> > +For example, if lowest-supported-version is set to 7 and you run capsule
> > +update using a capsule file with --fw-version of 5, the update will fail.
> > +When the --fw-version in the capsule file is updated,
> > lowest-supported-version
> > +in the dtb might be updated accordingly.
>
>
> I think that you should explicitly mention that a user always needs to update
> dtb
> *manually* in order to enforce anti-rollback to *any* older version.
> Otherwise, people may recognize that dtb be updated by the system (U-Boot).
Sorry for the late reply.
I agree with this.
This series was already merged into u-boot/next, so I will send the
follow-up patch
to include this comment.
Thanks,
Masahisa Kojima
>
> -Takahiro Akashi
>
> > +
> > +To insert the lowest supported version into a dtb
> > +
> > +.. code-block:: console
> > +
> > +$ dtc -@ -I dts -O dtb -o version.dtbo version.dts
> > +$ fdtoverlay -i orig.dtb -o new.dtb -v version.dtbo
> > +
> > +where version.dts looks like::
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +&{/} {
> > +firmware-version {
> > +image1 {
> > +image-type-id =
> > "09D7CF52-0720-4710-91D1-08469B7FE9C8";
> > +image-index = <1>;
> > +lowest-supported-version = <3>;
> > +};
> > +};
> > +};
> > +
> > +The properties of image-type-id and image-index must match the value
> > +defined in the efi_fw_image array as image_type_id and image_index.
> > +
> > Executing the boot manager
> > ~~
> >
> > --
> > 2.34.1
> >
[PATCH 1/2] efi_loader: use efi_install_multiple_protocol_interfaces()
The tcg protocol currently adds and removes protocols with
efi_(add/remove)_protocol(). Although this works fine protocol
interfaces should be installed using the EFI API functions instead
of the internal API ones
Signed-off-by: Ilias Apalodimas
---
lib/efi_loader/efi_tcg2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index a83ae7a46cf3..49f8a5e77cbf 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -1680,8 +1680,8 @@ void tcg2_uninit(void)
if (!is_tcg2_protocol_installed())
return;
- ret = efi_remove_protocol(efi_root, &efi_guid_tcg2_protocol,
- (void *)&efi_tcg2_protocol);
+ ret = efi_uninstall_multiple_protocol_interfaces(efi_root,
&efi_guid_tcg2_protocol,
+&efi_tcg2_protocol,
NULL);
if (ret != EFI_SUCCESS)
log_err("Failed to remove EFI TCG2 protocol\n");
}
@@ -2507,8 +2507,8 @@ efi_status_t efi_tcg2_register(void)
goto fail;
}
- ret = efi_add_protocol(efi_root, &efi_guid_tcg2_protocol,
- (void *)&efi_tcg2_protocol);
+ ret = efi_install_multiple_protocol_interfaces(&efi_root,
&efi_guid_tcg2_protocol,
+ &efi_tcg2_protocol,
NULL);
if (ret != EFI_SUCCESS) {
tcg2_uninit();
goto fail;
--
2.39.2
[PATCH 2/2] efi_loader: make efi_remove_protocol() static
A previous patch is removing the last consumer of efi_remove_protocol().
Switch that to static and treat it as an internal API in order to force
users install and remove protocols with the appropriate EFI functions.
It's worth noting that we still have files using efi_add_protocol(). We
should convert all these to efi_install_multiple_protocol_interfaces()
and treat efi_add_protocol() in a similar manner
Signed-off-by: Ilias Apalodimas
---
include/efi_loader.h | 4
lib/efi_loader/efi_boottime.c | 6 +++---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 11e08a804f7f..90a2f72d6929 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -651,10 +651,6 @@ efi_status_t efi_protocol_open(struct efi_handler *handler,
void **protocol_interface, void *agent_handle,
void *controller_handle, uint32_t attributes);
-/* Delete protocol from a handle */
-efi_status_t efi_remove_protocol(const efi_handle_t handle,
-const efi_guid_t *protocol,
-void *protocol_interface);
/* Install multiple protocol interfaces */
efi_status_t EFIAPI
efi_install_multiple_protocol_interfaces(efi_handle_t *handle, ...);
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index d5065f296aee..5006c0e1e4af 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -569,9 +569,9 @@ efi_status_t efi_search_protocol(const efi_handle_t handle,
*
* Return: status code
*/
-efi_status_t efi_remove_protocol(const efi_handle_t handle,
-const efi_guid_t *protocol,
-void *protocol_interface)
+static efi_status_t efi_remove_protocol(const efi_handle_t handle,
+ const efi_guid_t *protocol,
+ void *protocol_interface)
{
struct efi_handler *handler;
efi_status_t ret;
--
2.39.2
