[PATCH] arm: mvebu: sata_mv: Add bootstd hook to enable sata_bootdev
Add hook in sata_mv probe to enable bootstd bootdev.
Note: bootdev_setup_for_sibling_blk() invocation is a noop if bootsd is
not enabled for ahci sata yet.
Signed-off-by: Tony Dinh
---
drivers/ata/sata_mv.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 18c7a66db1..55a5365b5a 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -34,6 +34,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1104,6 +1105,12 @@ static int sata_mv_probe(struct udevice *dev)
/* TODO: undo create */
continue;
+ ret = bootdev_setup_for_sibling_blk(blk, "sata_bootdev");
+ if (ret) {
+ printf("%s: Failed to create bootdev\n", __func__);
+ continue;
+ }
+
/* If we got here, the current SATA port was probed
* successfully, so set the probe status to successful.
*/
@@ -1116,7 +1123,6 @@ static int sata_mv_probe(struct udevice *dev)
static int sata_mv_scan(struct udevice *dev)
{
/* Nothing to do here */
-
return 0;
}
--
2.39.2
Re: [RFC PATCH 2/2] binman: j721e: Add firewall configurations for atf
Hi Andrew,
On 10:22-20230905, Andrew Davis wrote:
> On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
> > The following commits adds the configuration of firewalls required to
> > protect ATF and OP-TEE memory region from non-secure reads and
> > writes using master and slave firewalls present in our K3 SOCs.
> >
> > Signed-off-by: Manorit Chawdhry
> > ---
> > arch/arm/dts/k3-j721e-binman.dtsi | 161
> > ++
> > 1 file changed, 161 insertions(+)
> >
> > diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
> > b/arch/arm/dts/k3-j721e-binman.dtsi
> > index 4f566c21a9af..0569a592597e 100644
> > --- a/arch/arm/dts/k3-j721e-binman.dtsi
> > +++ b/arch/arm/dts/k3-j721e-binman.dtsi
> > @@ -330,6 +330,73 @@
> > ti-secure {
> > content = <>;
> > keyfile = "custMpk.pem";
> > + auth_in_place = <0xa02>;
> > +
> > + // cpu_0_cpu_0_msmc Background
> > Firewall - 0
>
> I don't have a personal preference, but I see most comments in DTS
> are C style /* */.
>
> Also it might be easier to understand if you put the comments right before
> the properties that they relate to, i.g.
>
> firewall-0 {
> /* cpu_0_cpu_0_msmc */
> id = <257>;
> region = <0>;
> /* Background, Locked */
> control = <0x31a>;
> permissions = <0xc3>;
> start_address = <0x0 0x0>;
> end_address = <0xff 0x>;
> };
>
> For permissions, I wonder if it would be easier to read if we add
> some helper macros:
>
> #define FWPRIVID_ALL 0xc3
>
> #define FWPERM_SECURE_PRIV_WRITE BIT(0)
> #define FWPERM_SECURE_PRIV_READ BIT(1)
> #define FWPERM_SECURE_PRIV_CACHEABLE BIT(2)
> #define FWPERM_SECURE_PRIV_DEBUG BIT(3)
> #define FWPERM_SECURE_USER_WRITE BIT(4)
> ...
>
> Then you would have:
>
> permissions = FWPERM_SECURE_PRIV_WRITE |
>FWPERM_SECURE_PRIV_READ |
Also, I would like to make FWPERM_SECURE_PRIV_RWCD too as it'll be
commonly used.
Would be sending another RFC with this change if you are fine with the
suggestions. Thank you for reviewing!
Regards,
Manorit
>...
> > ;
>
> > + firewall-0 {
> > + id = <257>;
> > + region = <0>;
> > + control = <0x31a>;
> > + permissions =
> > <0xc3>;
> > + start_address = <0x0
> > 0x0>;
> > + end_address = <0xff
> > 0x>;
> > + };
> > +
> > + // cpu_0_cpu_0_msmc Foreground
> > Firewall
> > + firewall-1 {
> > + id = <257>;
> > + region = <1>;
> > + control = <0x1a>;
> > + permissions =
> > <0x0100ff>;
> > + start_address = <0x0
> > 0x7000>;
>
> This address might change if one moves ATF, might work to use
> CONFIG_K3_ATF_LOAD_ADDR?
> Not sure how you would get the end address as we don't really know ATF size..
>
> Andrew
[PATCH v3 3/3] timer: riscv_aclint_timer: add timer_get_boot_us for BOOTSTAGE
timer_get_boot_us function is required to record the boot stages as
us-based timestamp.
To get a micro-second time from a timer tick, this converts the
formula like below to avoid zero result of (tick / rate) part.
From: time(us) = (tick / rate) * 1000
To : time(us) = (tick * 1000) / (rate / 1000)
Signed-off-by: Chanho Park
---
drivers/timer/riscv_aclint_timer.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/timer/riscv_aclint_timer.c
b/drivers/timer/riscv_aclint_timer.c
index e29d527c8d77..73fb87912851 100644
--- a/drivers/timer/riscv_aclint_timer.c
+++ b/drivers/timer/riscv_aclint_timer.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -44,6 +45,28 @@ u64 notrace timer_early_get_count(void)
}
#endif
+#if CONFIG_IS_ENABLED(RISCV_MMODE) && CONFIG_IS_ENABLED(BOOTSTAGE)
+ulong timer_get_boot_us(void)
+{
+ int ret;
+ u64 ticks = 0;
+ u32 rate;
+
+ ret = dm_timer_init();
+ if (!ret) {
+ rate = timer_get_rate(gd->timer);
+ timer_get_count(gd->timer, );
+ } else {
+ rate = RISCV_MMODE_TIMER_FREQ;
+ ticks = readq((void __iomem *)MTIME_REG(RISCV_MMODE_TIMERBASE,
+ RISCV_MMODE_TIMEROFF));
+ }
+
+ /* Below is converted from time(us) = (tick / rate) * 1000 */
+ return lldiv(ticks * 1000, (rate / 1000));
+}
+#endif
+
static const struct timer_ops riscv_aclint_timer_ops = {
.get_count = riscv_aclint_timer_get_count,
};
--
2.39.2
[PATCH v3 2/3] riscv: timer: add timer_get_boot_us for BOOTSTAGE
timer_get_boot_us function is required to record the boot stages as
us-based timestamp.
To get a micro-second time from a timer tick, this converts the
formula like below to avoid zero result of (tick / rate) part.
From: time(us) = (tick / rate) * 1000
To : time(us) = (tick * 1000) / (rate / 1000)
Signed-off-by: Chanho Park
---
drivers/timer/riscv_timer.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/timer/riscv_timer.c b/drivers/timer/riscv_timer.c
index 28a6a6870b81..169c03dcb5c1 100644
--- a/drivers/timer/riscv_timer.c
+++ b/drivers/timer/riscv_timer.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -51,6 +52,27 @@ u64 notrace timer_early_get_count(void)
}
#endif
+#if CONFIG_IS_ENABLED(RISCV_SMODE) && CONFIG_IS_ENABLED(BOOTSTAGE)
+ulong timer_get_boot_us(void)
+{
+ int ret;
+ u64 ticks = 0;
+ u32 rate;
+
+ ret = dm_timer_init();
+ if (!ret) {
+ rate = timer_get_rate(gd->timer);
+ timer_get_count(gd->timer, );
+ } else {
+ rate = RISCV_SMODE_TIMER_FREQ;
+ ticks = riscv_timer_get_count(NULL);
+ }
+
+ /* Below is converted from time(us) = (tick / rate) * 1000 */
+ return lldiv(ticks * 1000, (rate / 1000));
+}
+#endif
+
static int riscv_timer_probe(struct udevice *dev)
{
struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
--
2.39.2
[PATCH v3 1/3] riscv: bootstage: correct bootstage_report guard
Below warning can be occurred when CONFIG_BOOTSTAGE and !CONFIG_SPL_BOOTSTAGE. It should be guarded by using CONFIG_IS_ENABLED for SPL build. arch/riscv/lib/bootm.c:46:9: warning: implicit declaration of function 'bootstage_report' 46 | bootstage_report(); | ^~~~ | bootstage_error Signed-off-by: Chanho Park Reviewed-by: Leo Yu-Chi Liang --- arch/riscv/lib/bootm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/lib/bootm.c b/arch/riscv/lib/bootm.c index 276677a5e2f9..cc30efc90498 100644 --- a/arch/riscv/lib/bootm.c +++ b/arch/riscv/lib/bootm.c @@ -42,7 +42,7 @@ static void announce_and_cleanup(int fake) #ifdef CONFIG_BOOTSTAGE_FDT bootstage_fdt_add_report(); #endif -#ifdef CONFIG_BOOTSTAGE_REPORT +#if CONFIG_IS_ENABLED(BOOTSTAGE_REPORT) bootstage_report(); #endif -- 2.39.2
[PATCH v3 0/3] bootstage support for risc-v
This adds to support bootstage for risc-v. timer_get_boot_us function is required to record each boot stages with microsecond timestamp. Changes from v2: - Add a Leo's RB tag of 1/3 patch - Add a description of the calculation formula - Correct the divisor value typo of 3/3 patch Chanho Park (3): riscv: bootstage: correct bootstage_report guard riscv: timer: add timer_get_boot_us for BOOTSTAGE timer: riscv_aclint_timer: add timer_get_boot_us for BOOTSTAGE arch/riscv/lib/bootm.c | 2 +- drivers/timer/riscv_aclint_timer.c | 23 +++ drivers/timer/riscv_timer.c| 22 ++ 3 files changed, 46 insertions(+), 1 deletion(-) -- 2.39.2
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Hi Jonas,
Il giorno lun 4 set 2023 alle ore 18:52 Jonas Karlman
ha scritto:
>
> Hi Massimo,
>
> On 2023-09-04 17:05, Massimo Pegorer wrote:
> > Hi,
> >
> > Is there any way for binman to package FIT with U-Boot TF-A and
> > OP-TEE, using bl32 binary provided by Rockchip as TEE?
> >
> > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> > binman failed.
> >
> > In my poor understanding of Python code, it seems binman accepts only
> > ELF format or a binary format starting with optee_v1_header, but
> > binaries provided by Rockchip in rkbin repository do not have this
> > header.
>
> One way that I have used/tested before was to create a tee.elf version
> using something like:
>
> $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
> xxx_bl32_vX.YZ.bin bl32.o
> $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
>
> tee.ld:
>
> ENTRY(_binary_bl32_bin_start);
>
> SECTIONS
> {
> . = 0x0840;
> .data : {
> *(.data)
> }
> }
>
Thank you so much! I've been able to load and execute
rk3308_bl32_v2.05.bin using 0x0020 as load address instead of
0x0840 in the tee.ld. This is the value I found in
rkbin/RKTRUST/RK3308TRUST.ini.
Everything then goes smooth till kernel panic, but this can depends on
kernel build options I suspect (it is just a "random" kernel image I
had). I need to investigate more.
DDR V2.07 6ede97a868 wesley.yao 22/11/29-19:27:02
08
REG2C: 0x0034, 0x0034
In
589MHz
DDR3
Col=10 Bank=3 Row=15 Size=512MB
OUT: sdram_init finish.
U-Boot SPL 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
Trying to boot from MMC1
INFO:Preloader serial: 0
NOTICE: BL31: v1.3(release):0252d5c8f
NOTICE: BL31: Built : 07:51:11, Sep 28 2022
INFO:Lastlog: last=0x10, realtime=0x102000, size=0x2000
INFO:ARM GICv2 driver initialized
INFO:Using opteed sec cpu_context!
INFO:boot cpu mask: 1
INFO:plat_rockchip_pmu_init: pd status 0xe b
INFO:BL31: Initializing runtime services
INFO:BL31: Initializing BL32
I/TC:
I/TC: OP-TEE version: 3.13.0-651-gd84087907 #hisping.lin (gcc version
10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
10.2-2020.11 (arm-10.16))) #8 Fri Sep 16 16:15:04 CST 2022 aarch64
I/TC: Primary CPU initializing
I/TC: Primary CPU switching to normal world boot
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x60
INFO:SPSR = 0x3c9
U-Boot 2023.10-rc3-00053-ge0b1c90eda (Sep 05 2023 - 19:16:27 +0200)
Model: Radxa ROCK Pi S
DRAM: 512 MiB (effective 510 MiB)
Core: 284 devices, 21 uclasses, devicetree: separate
MMC: mmc@ff48: 1, mmc@ff49: 0, mmc@ff4a: 2
Loading Environment from nowhere... OK
rockchip_dnl_key_pressed read board id failed
Net:
Error: ethernet@ff4e address not set.
No ethernet found.
Hit any key to stop autoboot: 0
** Booting bootflow 'mmc@ff48.bootdev.part_1' with script
4414108 bytes read in 189 ms (22.3 MiB/s)
## Loading kernel from FIT Image at 0068 ...
Using 'config-1' configuration
Trying 'kernel-1' kernel subimage
Description: ARM64 OpenWrt Linux-6.1.46
Type: Kernel Image
Compression: lzma compressed
Data Start: 0x006800e8
Data Size:4379870 Bytes = 4.2 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x0320
Entry Point: 0x0320
Hash algo:crc32
Hash value: a99f6703
Hash algo:sha1
Hash value: 642b4e5d4bdab91260c07510ff9d1b13ada03add
Verifying Hash Integrity ... crc32+ sha1+ OK
## Loading fdt from FIT Image at 0068 ...
Using 'config-1' configuration
Trying 'fdt-1' fdt subimage
Description: ARM64 OpenWrt radxa_rock-pi-s device tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x00aad708
Data Size:32335 Bytes = 31.6 KiB
Architecture: AArch64
Hash algo:crc32
Hash value: 3d67cbee
Hash algo:sha1
Hash value: 82c778864784d98ae4150916adac497000e34c6a
Verifying Hash Integrity ... crc32+ sha1+ OK
Booting using the fdt blob at 0xaad708
Working FDT set to aad708
Uncompressing Kernel Image
Loading Device Tree to 1df25000, end 1df2fe4e ... OK
Working FDT set to 1df25000
Starting kernel ...
[0.00] Booting Linux on physical CPU 0x00 [0x410fd042]
[0.00] Linux version 6.1.46 (ubuntu@buildhost)
(aarch64-openwrt-linux-musl-gcc (OpenWrt GCC 12.3.0 r23781-426752b38a)
12.3.0, GNU ld (GNU Binutils) 2.40.0) #0 SMP PREEMPT Fri Aug 25
20:22:05 2023
[0.00] Machine model: Radxa ROCK Pi S
[0.00] earlycon: uart8250 at MMIO32 0xff0a (options '')
[0.00] printk: bootconsole [uart8250] enabled
[0.00] Zone ranges:
[0.00] DMA [mem 0x0020-0x1fff]
[0.00] DMA32empty
[0.00] Normal empty
[0.00] Movable zone start
Re: [PATCH] Adjust gitignore for /build
On 2023-09-04 22:18 +05:30, Simon Glass wrote: > Hi Rong, > > On Sun, 3 Sept 2023 at 20:50, Rong Tao wrote: >> >> From: Rong Tao >> >> /build-* can't ignore /build. > > How does that directory get created? Most likely `make O=build` as an attempt to do out-of-tree builds? FWIW, I manually create and use build/$board/ directories for build outputs, but adding "build" to .git/info/exclude is an easy enough alternative. >> Signed-off-by: Rong Tao >> --- >> .gitignore | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/.gitignore b/.gitignore >> index 002f95de4feb..9697f0088f80 100644 >> --- a/.gitignore >> +++ b/.gitignore >> @@ -35,7 +35,7 @@ >> *.tab.[ch] >> >> # Build tree >> -/build-* >> +/build* >> >> # >> # Top-level generic files >> -- >> 2.41.0 >> > > Regards, > Simon
Re: [RFC PATCH 2/2] binman: j721e: Add firewall configurations for atf
Hi Neha, Andrew,
On 09:20-20230906, Neha Malcom Francis wrote:
> Hi Andrew,
>
> On 05/09/23 20:52, Andrew Davis wrote:
> > On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
> > > The following commits adds the configuration of firewalls required to
> > > protect ATF and OP-TEE memory region from non-secure reads and
> > > writes using master and slave firewalls present in our K3 SOCs.
>
> [...]
>
> > > + // cpu_0_cpu_0_msmc Foreground Firewall
> > > + firewall-1 {
> > > + id = <257>;
> > > + region = <1>;
> > > + control = <0x1a>;
> > > + permissions = <0x0100ff>;
> > > + start_address = <0x0 0x7000>;
> >
> > This address might change if one moves ATF, might work to use
> > CONFIG_K3_ATF_LOAD_ADDR?
> > Not sure how you would get the end address as we don't really know ATF
> > size..
> >
>
> I think this could be handled within binman IF CONFIG_K3_ATF_LOAD_ADDR and
> the ATF binary were not only A53/A72 inputs. But since it is, I don't see
> how that can be implemented.
>
Andrew,
I don't think that just using the CONFIG would be a good solution as
the slave firewalls would not be able to protect the updated ATF address.
Maybe we can use configs and put some warning in build time if the ATF
address is not the default, would see how this could be done getting the
size is still an issue as Neha mentioned that they have to be inputs for
all the build stages.
Neha,
Would you be able to elaborate more on that part?
Regards,
Manorit
> > Andrew
>
> --
> Thanking You
> Neha Malcom Francis
Re: [RFC PATCH 1/2] binman: ti-secure: Add support for firewalling entities
Hi Neha,
On 09:16-20230906, Neha Malcom Francis wrote:
> Hi Manorit
>
> On 05/09/23 13:51, Manorit Chawdhry wrote:
> > We can now firewall entities while loading them through our secure
> > entity TIFS, the required information should be present in the
> > certificate that is being parsed by TIFS.
> >
> > The following commit adds the support to enable the certificates to be
> > generated if the firewall configurations are present in the binman dtsi
> > nodes.
> >
> > Signed-off-by: Manorit Chawdhry
> > ---
> > tools/binman/btool/openssl.py | 16 ++--
> > tools/binman/etype/ti_secure.py | 54
> > +
> > tools/binman/etype/x509_cert.py | 3 ++-
> > 3 files changed, 70 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
> > index aad3b61ae27c..dff439df211f 100644
> > --- a/tools/binman/btool/openssl.py
> > +++ b/tools/binman/btool/openssl.py
> > @@ -82,7 +82,7 @@ imageSize = INTEGER:{len(indata)}
> > return self.run_cmd(*args)
> > def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
> > - config_fname, req_dist_name_dict):
> > + config_fname, req_dist_name_dict, firewall_cert_data):
> > """Create a certificate to be booted by system firmware
> > Args:
> > @@ -94,6 +94,13 @@ imageSize = INTEGER:{len(indata)}
> > req_dist_name_dict (dict): Dictionary containing key-value
> > pairs of
> > req_distinguished_name section extensions, must contain
> > extensions for
> > C, ST, L, O, OU, CN and emailAddress
> > +firewall_cert_data (dict):
> > + - auth_in_place (int): The Priv ID for copying as the
> > +specific host in firewall protected region
> > + - num_firewalls (int): The number of firewalls in the
> > +extended certificate
> > + - certificate (str): Extended firewall certificate with
> > +the information for the firewall configurations.
> > Returns:
> > str: Tool output
> > @@ -121,6 +128,7 @@ basicConstraints = CA:true
> > 1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
> > 1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
> > 1.3.6.1.4.1.294.1.35 = ASN1:SEQUENCE:sysfw_image_load
> > +1.3.6.1.4.1.294.1.37 = ASN1:SEQUENCE:firewall
> > [ swrv ]
> > swrv = INTEGER:{sw_rev}
> > @@ -132,7 +140,11 @@ imageSize = INTEGER:{len(indata)}
> > [ sysfw_image_load ]
> > destAddr = FORMAT:HEX,OCT:
> > -authInPlace = INTEGER:2
> > +authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
> > +
> > +[ firewall ]
> > +numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
> > +{firewall_cert_data['certificate']}
> > ''', file=outf)
> > args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
> > '-outform', 'DER', '-out', cert_fname, '-config',
> > config_fname,
> > diff --git a/tools/binman/etype/ti_secure.py
> > b/tools/binman/etype/ti_secure.py
> > index d939dce57139..a980d10f4197 100644
> > --- a/tools/binman/etype/ti_secure.py
> > +++ b/tools/binman/etype/ti_secure.py
> > @@ -7,9 +7,39 @@
> > from binman.entry import EntryArg
> > from binman.etype.x509_cert import Entry_x509_cert
> > +from dataclasses import dataclass
> > from dtoc import fdt_util
> > +def hex_octet(n):
> > + x = '%x' % (n,)
> > + return ('0' * (len(x) % 2)) + x
> > +
>
> If this was the only way to grab the address this way, maybe consider adding
> this as a common fdt_util function?
>
Ah yes, I believe it can come helpful to other people using openssl too
as openssl gets the input in this hex_octet form. Will be moving there
as you mentioned. Thanks for the suggestion!
> > +@dataclass
> > +class Firewall():
> > +id: int
> > +region: int
> > +control : int
> > +permissions: list[hex]
> > +start_address: str
> > +end_address: str
> > +
> > +def get_certificate(self) -> str:
> > +unique_indentifier = f"{self.id}{self.region}"
> > +cert = f"""
> > +firewallID{unique_indentifier} = INTEGER:{self.id}
> > +region{unique_indentifier} = INTEGER:{self.region}
> > +control{unique_indentifier} = INTEGER:{hex(self.control)}
> > +nPermissionRegs{unique_indentifier} = INTEGER:{len(self.permissions)}
> > +"""
>
> s/indentifier/identifier ?
>
Ah yes, a typo.
> > +for index, permission in enumerate(self.permissions):
> > +cert += f"""permissions{unique_indentifier}{index} =
> > INTEGER:{hex(permission)}
> > +"""
> > +cert += f"""startAddress{unique_indentifier} =
> > FORMAT:HEX,OCT:{hex_octet(self.start_address)}
> > +endAddress{unique_indentifier} =
> > FORMAT:HEX,OCT:{hex_octet(self.end_address)}
> > +"""
> > +return cert
> > +
> > class
Re: [PATCH v4 6/6] board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File.
On 07:27-20230905, Nishanth Menon wrote: > On 16:08-20230904, Manorit Chawdhry wrote: > > Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due > > to the previous MAINTAINER not being associated with TI. > > > > Signed-off-by: Manorit Chawdhry > > --- > > board/ti/j721s2/MAINTAINERS | 11 +-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > For whatever it is worth: > > Reviewed-by: Nishanth Menon Thanks for your reviews Nishanth! Regards, Manorit > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D
[PATCH] bootstd: sata: Add bootstd support for ahci sata
Add ahci sata bootdev and corresponding hunting function.
Signed-off-by: Tony Dinh
---
drivers/ata/Makefile | 1 +
drivers/ata/sata.c | 25 +++
drivers/ata/sata_bootdev.c | 62 ++
include/sata.h | 1 +
4 files changed, 89 insertions(+)
create mode 100644 drivers/ata/sata_bootdev.c
diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
index 6e30180b8b..c1b51b5444 100644
--- a/drivers/ata/Makefile
+++ b/drivers/ata/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_DWC_AHSATA) += dwc_ahsata.o
obj-$(CONFIG_FSL_SATA) += fsl_sata.o
obj-$(CONFIG_LIBATA) += libata.o
obj-$(CONFIG_SATA) += sata.o
+obj-$(CONFIG_BOOTSTD) += sata_bootdev.o
obj-$(CONFIG_SATA_CEVA) += sata_ceva.o
obj-$(CONFIG_SATA_MV) += sata_mv.o
obj-$(CONFIG_SATA_SIL) += sata_sil.o
diff --git a/drivers/ata/sata.c b/drivers/ata/sata.c
index ce3e9b5a40..9da7218564 100644
--- a/drivers/ata/sata.c
+++ b/drivers/ata/sata.c
@@ -15,6 +15,8 @@
#include
#include
#include
+#include
+#include
#ifndef CONFIG_AHCI
struct blk_desc sata_dev_desc[CONFIG_SYS_SATA_MAX_DEVICE];
@@ -50,6 +52,29 @@ int sata_scan(struct udevice *dev)
return ops->scan(dev);
}
+int sata_rescan(bool verbose)
+{
+ struct udevice *dev;
+ int devnum = 0;
+ int ret;
+
+ /* Find and probing the SATA controller */
+ ret = uclass_get_device(UCLASS_AHCI, devnum, );
+
+ /* Sanity check */
+ if (ret)
+ ret = uclass_find_first_device(UCLASS_AHCI, );
+ if (ret) {
+ printf("Cannot probe SATA device %d (err=%d)\n", devnum, ret);
+ return -ENOSYS;
+ }
+ if (!dev) {
+ printf("No SATA device found!\n");
+ return -ENOSYS;
+ }
+ return 0;
+}
+
#ifndef CONFIG_AHCI
#ifdef CONFIG_PARTITIONS
struct blk_desc *sata_get_dev(int dev)
diff --git a/drivers/ata/sata_bootdev.c b/drivers/ata/sata_bootdev.c
new file mode 100644
index 00..f638493ce0
--- /dev/null
+++ b/drivers/ata/sata_bootdev.c
@@ -0,0 +1,62 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Bootdev for sata
+ *
+ * Copyright 2023 Tony Dinh
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int sata_bootdev_bind(struct udevice *dev)
+{
+ struct bootdev_uc_plat *ucp = dev_get_uclass_plat(dev);
+
+ ucp->prio = BOOTDEVP_4_SCAN_FAST;
+
+ return 0;
+}
+
+static int sata_bootdev_hunt(struct bootdev_hunter *info, bool show)
+{
+ int ret;
+
+ if (IS_ENABLED(CONFIG_PCI)) {
+ ret = pci_init();
+ if (ret)
+ return ret;
+ }
+
+ ret = sata_rescan(true);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+struct bootdev_ops sata_bootdev_ops = {
+};
+
+static const struct udevice_id sata_bootdev_ids[] = {
+ { .compatible = "u-boot,bootdev-sata" },
+ { }
+};
+
+U_BOOT_DRIVER(sata_bootdev) = {
+ .name = "sata_bootdev",
+ .id = UCLASS_BOOTDEV,
+ .ops= _bootdev_ops,
+ .bind = sata_bootdev_bind,
+ .of_match = sata_bootdev_ids,
+};
+
+BOOTDEV_HUNTER(sata_bootdev_hunter) = {
+ .prio = BOOTDEVP_4_SCAN_FAST,
+ .uclass = UCLASS_AHCI,
+ .hunt = sata_bootdev_hunt,
+ .drv= DM_DRIVER_REF(sata_bootdev),
+};
diff --git a/include/sata.h b/include/sata.h
index d89f7a8a29..0495744bad 100644
--- a/include/sata.h
+++ b/include/sata.h
@@ -20,5 +20,6 @@ extern struct blk_desc sata_dev_desc[];
int sata_probe(int devnum);
int sata_remove(int devnum);
+int sata_rescan(bool verbose);
#endif
--
2.39.2
Re: [RFC PATCH 2/2] binman: j721e: Add firewall configurations for atf
Hi Andrew,
On 05/09/23 20:52, Andrew Davis wrote:
On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
[...]
+ // cpu_0_cpu_0_msmc Foreground Firewall
+ firewall-1 {
+ id = <257>;
+ region = <1>;
+ control = <0x1a>;
+ permissions = <0x0100ff>;
+ start_address = <0x0 0x7000>;
This address might change if one moves ATF, might work to use
CONFIG_K3_ATF_LOAD_ADDR?
Not sure how you would get the end address as we don't really know ATF size..
I think this could be handled within binman IF CONFIG_K3_ATF_LOAD_ADDR and the
ATF binary were not only A53/A72 inputs. But since it is, I don't see how that
can be implemented.
Andrew
--
Thanking You
Neha Malcom Francis
Re: [RFC PATCH 1/2] binman: ti-secure: Add support for firewalling entities
Hi Manorit
On 05/09/23 13:51, Manorit Chawdhry wrote:
We can now firewall entities while loading them through our secure
entity TIFS, the required information should be present in the
certificate that is being parsed by TIFS.
The following commit adds the support to enable the certificates to be
generated if the firewall configurations are present in the binman dtsi
nodes.
Signed-off-by: Manorit Chawdhry
---
tools/binman/btool/openssl.py | 16 ++--
tools/binman/etype/ti_secure.py | 54 +
tools/binman/etype/x509_cert.py | 3 ++-
3 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index aad3b61ae27c..dff439df211f 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -82,7 +82,7 @@ imageSize = INTEGER:{len(indata)}
return self.run_cmd(*args)
def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
- config_fname, req_dist_name_dict):
+ config_fname, req_dist_name_dict, firewall_cert_data):
"""Create a certificate to be booted by system firmware
Args:
@@ -94,6 +94,13 @@ imageSize = INTEGER:{len(indata)}
req_dist_name_dict (dict): Dictionary containing key-value pairs
of
req_distinguished_name section extensions, must contain
extensions for
C, ST, L, O, OU, CN and emailAddress
+firewall_cert_data (dict):
+ - auth_in_place (int): The Priv ID for copying as the
+specific host in firewall protected region
+ - num_firewalls (int): The number of firewalls in the
+extended certificate
+ - certificate (str): Extended firewall certificate with
+the information for the firewall configurations.
Returns:
str: Tool output
@@ -121,6 +128,7 @@ basicConstraints = CA:true
1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
1.3.6.1.4.1.294.1.35 = ASN1:SEQUENCE:sysfw_image_load
+1.3.6.1.4.1.294.1.37 = ASN1:SEQUENCE:firewall
[ swrv ]
swrv = INTEGER:{sw_rev}
@@ -132,7 +140,11 @@ imageSize = INTEGER:{len(indata)}
[ sysfw_image_load ]
destAddr = FORMAT:HEX,OCT:
-authInPlace = INTEGER:2
+authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
+
+[ firewall ]
+numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
+{firewall_cert_data['certificate']}
''', file=outf)
args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
'-outform', 'DER', '-out', cert_fname, '-config',
config_fname,
diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
index d939dce57139..a980d10f4197 100644
--- a/tools/binman/etype/ti_secure.py
+++ b/tools/binman/etype/ti_secure.py
@@ -7,9 +7,39 @@
from binman.entry import EntryArg
from binman.etype.x509_cert import Entry_x509_cert
+from dataclasses import dataclass
from dtoc import fdt_util
+def hex_octet(n):
+ x = '%x' % (n,)
+ return ('0' * (len(x) % 2)) + x
+
If this was the only way to grab the address this way, maybe consider adding
this as a common fdt_util function?
+@dataclass
+class Firewall():
+id: int
+region: int
+control : int
+permissions: list[hex]
+start_address: str
+end_address: str
+
+def get_certificate(self) -> str:
+unique_indentifier = f"{self.id}{self.region}"
+cert = f"""
+firewallID{unique_indentifier} = INTEGER:{self.id}
+region{unique_indentifier} = INTEGER:{self.region}
+control{unique_indentifier} = INTEGER:{hex(self.control)}
+nPermissionRegs{unique_indentifier} = INTEGER:{len(self.permissions)}
+"""
s/indentifier/identifier ?
+for index, permission in enumerate(self.permissions):
+cert += f"""permissions{unique_indentifier}{index} =
INTEGER:{hex(permission)}
+"""
+cert += f"""startAddress{unique_indentifier} =
FORMAT:HEX,OCT:{hex_octet(self.start_address)}
+endAddress{unique_indentifier} = FORMAT:HEX,OCT:{hex_octet(self.end_address)}
+"""
+return cert
+
class Entry_ti_secure(Entry_x509_cert):
"""Entry containing a TI x509 certificate binary
@@ -32,11 +62,20 @@ class Entry_ti_secure(Entry_x509_cert):
def __init__(self, section, etype, node):
super().__init__(section, etype, node)
self.openssl = None
+self.firewall_cert_data: dict = {
+'auth_in_place': 0x02,
+'num_firewalls': 0,
+'certificate': "",
+}
def ReadNode(self):
super().ReadNode()
self.key_fname = self.GetEntryArgsOrProps([
EntryArg('keyfile', str)], required=True)[0]
+auth_in_place = fdt_util.GetInt(self._node, "auth_in_place")
+if
Re: [RFC 0/6] firmware: scmi: add SCMI pinctrl protocol support
Adding Peng Fan, who is working on scmi/pinctrl support for i.MX9:
https://lore.kernel.org/all/ZO9GLG5tQynYyAvR@pluto/T/
On Tue, Sep 5, 2023 at 11:41 PM AKASHI Takahiro
wrote:
>
> This is an RFC and meant to get feedback from other developers as
> - the specification (pinctrl part) is still in a draft
> - the upstream patch for linux, including dt bindings, is still WIP
> - I'm not confident the drivers are generic enough to cover most HWs
> - The tests ("ut") doesn't cover all the features yet
>
>
> This patch series allows users to access SCMI pin control protocol provided
> by SCMI server (platform). See SCMI specification document v3.2 beta 2[1]
> for more details about SCMI pin control protocol.
>
> The implementation consists of two layers:
> - basic helper functions for SCMI pin control protocol
> in drivers/firmware/scmi/pinctrl.c (patch#2)
> - DM-compliant pinctrl/gpio drivers, which utilizes the helper functions,
> in drivers/pinctrl/pinctrl-scmi.c (patch#3,#4)
>
> [1] https://developer.arm.com/documentation/den0056/e/?lang=en
>
> DT bindings
> ===
> Upstream pinctrl patch for linux defines the bindings in [2] though
> it doesn't say much.
> I expect that my implementation basically complies with U-Boot's generic
> bindings described in [3], but not all the features are verified.
>
> As for gpio, unless you hard-code pin assignments directly in a device
> driver, my implementation allows the following alternatives in DT.
> Either way, we may need an additional binding description for gpio.
>
> (A)
> scmi {
> ... // other protocols
> scmi_pinctrl: protocol@19 { // Pin control protocol
> ...
> {pinmux definitions}... // if any, including GPIO?
> }
> }
> scmi_gpio: scmi_gpio {
> compatible = "arm,scmi-gpio-generic";
> gpio-controller;
> #gpio-cells = <2>;
> gpio-ranges = <_pinctrl 0 5 4>,
> <_pinctrl 4 0 0>;
> gpio-ranges-group-names = "",
> "ANOTHER_GPIO_GROUP";
> }
> some_device {
> ...
> reset-gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
> }
> (B)
> scmi {
> ... // other protocols
> scmi_pinctrl: protocol@19 { // Pin control protocol
> ...
> {pinmux definitions}... // if any, including GPIO?
>
> scmi_gpio: scmi_gpio {
> // no need for "compatible"
> gpio-controller;
> #gpio-cells = <2>;
> gpio-ranges = <_pinctrl 0 5 4>,
> <_pinctrl 4 0 0>;
> gpio-ranges-group-names = "",
> "ANOTHER_GPIO_GROUP";
> }
> }
> }
> some_device {
> ...
> reset-gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
> }
> (C)
> if "gpio-ranges" is missing in gpio definition, assume 1:1 mapping,
> i.e. use a native pinctrl pin number (5).
> some_device {
> ...
> reset-gpios = <_gpio 5 GPIO_ACTIVE_HIGH>;
> }
>
>
> [2] https://lkml.iu.edu/hypermail/linux/kernel/2308.1/01084.html
> [3] /doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt
> /doc/device-tree-bindings/gpio/gpio.txt
>
> Test
>
> The patch series was tested on the following platforms:
> * sandbox ("ut dm pinmux" and manually using gpio command)
>
>
> Prerequisite:
> =
> * This patch series is based on my WIP "Base protocol support" patches
> on v2023.10-rc3. You can fetch the whole code from [4].
>
> [4] https://git.linaro.org/people/takahiro.akashi/u-boot.git
> branch:scmi/pinctrl
>
>
> Patches:
>
> Patch#1: Add SCMI base protocol driver
> Patch#2-#4: Add drivers
> Patch#5-#6: Test related
>
>
> Change history:
> ===
> RFC (Sep 6, 2023)
> * initial release as RFC
>
> AKASHI Takahiro (6):
> firmware: scmi: fix protocol enumeration logic
> firmware: scmi: add pinctrl protocol support
> pinctrl: add scmi driver
> gpio: add scmi driver based on pinctrl
> firmware: scmi: add pseudo pinctrl protocol support on sandbox
> test: dm: add SCMI pinctrl test
>
> arch/sandbox/dts/test.dts | 115 +++
> cmd/scmi.c |1 +
> drivers/firmware/scmi/Kconfig |3 +
> drivers/firmware/scmi/Makefile |1 +
> drivers/firmware/scmi/pinctrl.c| 412
> drivers/firmware/scmi/sandbox-scmi_agent.c | 722 +
> drivers/firmware/scmi/scmi_agent-uclass.c | 18 +-
> drivers/pinctrl/Kconfig| 11 +
> drivers/pinctrl/Makefile |1 +
> drivers/pinctrl/pinctrl-scmi.c | 1071
> include/scmi_agent-uclass.h|2 +
> include/scmi_protocols.h | 435
> test/dm/scmi.c | 62 ++
> 13 files changed, 2852 insertions(+), 2 deletions(-)
Re: [RFC] make sandbox UT more generic
Hi Simon, On Thu, Aug 31, 2023 at 09:04:43AM -0600, Simon Glass wrote: > Hi, > > On Wed, 30 Aug 2023 at 23:28, AKASHI Takahiro > wrote: > > > > Hi Simon, > > > > On Wed, Aug 30, 2023 at 08:49:05PM -0600, Simon Glass wrote: > > > Hi, > > > > > > On Wed, 30 Aug 2023 at 18:38, AKASHI Takahiro > > > wrote: > > > > > > > > Hi, > > > > > > > > I'm working on implementing SCMI-based pinctrl/gpio driver, > > > > and want to re-use sandbox UT to test the code. However, > > > > It is somehow sandbox-specific (with additional DT nodes). > > > > How can/should we make it more generic for other targets/drivers > > > > rather than just by copying the test code? > > > > (I have already created a test for pinmux since there is only > > > > one existing scenario, but gpio test has many.) > > > > > > > > Even if I say 'generic', my case may be special since real > > > > hardware (device drivers) cannot always run all the test cases, > > > > while SCMI-based drivers potentially can with a dummy SCMI server > > > > for sandbox. > > > > See: > > > > drivers/firmware/scmi/sandbox-scmi_agent.c > > > > > > We don't have a good way to test drivers that talk to hardware, in > > > general. > > > > > > For I2C, SPI and some PCI devices you can sometimes write an emulator > > > for the chip and then your driver can talk to the emulator as if it > > > were talking to the hardware. Sandbox does actually support that with > > > memory-mapped I/O too, although it is fairly rarely used. > > > > Well, I don't want or need to emulate some *real* hardware. > > Instead, I would like to emulate what the current sandbox drivers > > (pinctrl-sandbox.c and gpio/sandbox.c) emulate so that we can re-use > > (some portion of) test cases for sandbox (test/dm/pinmux.c and gpio.c). > > > > As you might know, SCMI protocol with associated drivers on U-Boot is > > so generic that it would be able to talk to any of real pinctrl/gpio > > drivers/firmware (say, run on OPTEE or SCP). > > By implementing/mimicking protocol messages in sandbox-scmi_agent.c, > > SCMI drivers are expected to provide *virtual* pinctrl/gpio devices > > similar to what sandbox does. > > I actually know almost nothing about SCMI. > > > > > I have already implemented pinmux test with some tweaks by copying > > test/dm/pinmux.c and duplicating almost the same DT nodes as "pinctrl-gpio" > > in test.dts. > > But I'm looking for any other means without test code duplication. > > > > Did I clarify my question a bit? > > Well you should be able to factor out the test code into a function, > then call it from two places with the two different devices (or other > params) that are needed. > > For the DT, copying a few nodes is not the end of the world, IMO. > > BTW have you seen this talk? [2] It seems that you are moving pieces > into firmware which should be OS drivers? > > Anyway, if you place a sandbox pinmux device under the SCMI node in > the DT, then you should end up with a pinmux device you can use likely > normal. Then if that device uses the sandbox emulator, you can run the > existing tests on it with little modification, I suspect. > > But if I am still missing the point, a diagram or patch might help me > understand! I just posted my RFC for supporting SCMI pinctrl protocol[1], hoping it will help you understand what I'm planning to do regarding test methodology, in particular by looking at patch#5 and #6. [1] https://lists.denx.de/pipermail/u-boot/2023-September/529765.html Thanks, -Takahiro Akashi > Regards, > Simon > > > > > > -Takahiro Akashi > > > > > > > We have done this a lot with Zephyr, as well[1] and achieved 90% code > > > coverage on some boards. > > > > > > But I'm not quite sure I am answering the right question, so I will stop > > > here. > > > > > > Regards, > > > Simon > > > > > > [1] https://www.youtube.com/watch?v=usXCAXR2G_c > > [2] https://www.usenix.org/conference/osdi21/presentation/fri-keynote
Re: [PATCH v2] binman: Fix SyntaxWarning: invalid escape sequence '\('
Thanks, Simon
The following lines is my systeme ENV and make log
$ cat /etc/os-release
NAME="Fedora Linux"
VERSION="40 (Workstation Edition Prerelease)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40 (Workstation Edition Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/;
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/;
SUPPORT_URL="https://ask.fedoraproject.org/;
BUG_REPORT_URL="https://bugzilla.redhat.com/;
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
SUPPORT_END=2024-05-14
VARIANT="Workstation Edition"
VARIANT_ID=workstation
$ uname -r
6.6.0-0.rc0.20230901git99d99825fc07.3.fc40.x86_64
$ gcc --version
gcc (GCC) 13.2.1 20230728 (Red Hat 13.2.1-1)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ make qemu-x86_64_defconfig
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
LEX scripts/kconfig/zconf.lex.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#
$ make -j8
... [too much logs]
SYM spl/u-boot-spl.sym
OBJCOPY spl/u-boot-x86-start16-spl.bin
OBJCOPY spl/u-boot-x86-reset16-spl.bin
CAT spl/u-boot-spl-dtb.bin
COPY spl/u-boot-spl.bin
BINMAN .binman_stamp
/home/sda/git-repos/u-boot/tools/binman/etype/section.py:25: SyntaxWarning:
invalid escape sequence '\('
"""Entry that contains other entries
OFCHK .config
Re: NVMe support on RPi CM4 board
Thanks for your answer Simon, Can you check if the device has PCI bus master enabled? > I think this one will take me a bit more time, should this be in raspberry pi’s eeprom firmware? Will the disabled PCI bus master also be a problem for the Linux kernel? As this is working as expected Regards Luis
Re: NVMe support on RPi CM4 board
Hi Simon, it took me some time to come back to this issue, but I was able to enable the debug messages on drivers/nvme/nvme.c. This is what I got when running the nvme scan command U-Boot> pci BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x14e4 0x2711 Bridge device 0x04 01.00.00 0x1c5c 0x174a Mass storage controller 0x08 U-Boot> nvme info U-Boot> nvme scan Cannot set queue count (err=-110) Unable to setup I/O queues(err=-110) Failed to probe 'nvme#0': err=-110 U-Boot> I'm reporting as soon as I got the messages, but I'll continue investigating. Regards, Luis El mié, 9 ago 2023 a las 20:15, Simon Glass () escribió: > Hi Luis, > > On Wed, 9 Aug 2023 at 10:43, Luis Alfredo da Silva > wrote: > > > > Hi Simon, I enabled the next four variables > > > > CONFIG_NVME_PCI=y > > CONFIG_NVME=y > > CONFIG_CMD_NVME=y > > CONFIG_PCI=y > > > > how different is CONFIG_NVME_PCI from NVME_PCI, I took the latter value > from several configs files in u-boot repo and from [1] > > I just left off the CONFIG as they all have that. This looks right to > me. Assuming that the NVMe controller appears in 'dm tree' perhaps you > can enable debugging in the driver and see why it is not working? > > Regards, > Simon > > > > > > > > [1] > https://github.com/u-boot/u-boot/blob/ef8336e2705fce2502383f25d68188c6b1f94dd0/doc/develop/driver-model/nvme.rst#L44 > > > > El mar, 8 ago 2023 a las 22:05, Simon Glass () escribió: > >> > >> Hi Luis, > >> > >> On Tue, 8 Aug 2023 at 17:09, Luis Alfredo da Silva > >> wrote: > >> > > >> > I compiled u-boot version 2023-07 and boot it on a RPi CM4 using a > PCIe M.2 > >> > NVMe drive, but it doesn't appear to be working. > >> > > >> > Once u-boot has started and boot successfully it recognizes the PCIe > device > >> > giving me the next output > >> > > >> > U-Boot> pci > >> > BusDevFun VendorId DeviceId Device Class Sub-Class > >> > _ > >> > 00.00.00 0x14e4 0x2711 Bridge device 0x04 > >> > 01.00.00 0x1c5c 0x174a Mass storage controller 0x08 > >> > > >> > but when trying to use the nvme scan and nvme info there is not > output. > >> > > >> > NVMe drive has two partitions 1st is a FAT partition, and 2nd is a > EXT4 > >> > partition, the RPi firmware recognizes the FAT partition and u-boot > boot > >> > correctly. > >> > > >> > I don't know if this worked before, but I saw in the mailing list that > >> > there could be already support for other ARM64 boards. > >> > >> Is NVME_PCI enabled? > >> > >> Regards, > >> SImon >
[PATCH v2] binman: Fix SyntaxWarning: invalid escape sequence '\('
From: Rong Tao
Reproduct warning:
$ git clean -dfx
$ make CROSS_COMPILE="" qemu-x86_64_defconfig
$ make -j8
...
u-boot/tools/binman/etype/section.py:25:
SyntaxWarning: invalid escape sequence '\('
"""Entry that contains other entries
Signed-off-by: Rong Tao
---
tools/binman/etype/section.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
index fb49e85a7634..30c1041c7e8d 100644
--- a/tools/binman/etype/section.py
+++ b/tools/binman/etype/section.py
@@ -40,7 +40,7 @@ class Entry_section(Entry):
For example code, see etypes which subclass `Entry_section`, or `cbfs.py`
for a more involved example::
- $ grep -l \(Entry_section tools/binman/etype/*.py
+ $ grep -l \\(Entry_section tools/binman/etype/*.py
ReadNode()
Call `super().ReadNode()`, then read any special properties for the
--
2.41.0
Re: [PATCH] binman: Fix SyntaxWarning: invalid escape sequence '\('
I Just try binman entry-docs entries.rst git difff It didn't change anything. Rong Tao
[RFC 6/6] test: dm: add SCMI pinctrl test
In this test, SCMI-based pinmux feature is exercised.
Signed-off-by: AKASHI Takahiro
---
test/dm/scmi.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/test/dm/scmi.c b/test/dm/scmi.c
index 423b6ef70b29..ca5a2e9c781e 100644
--- a/test/dm/scmi.c
+++ b/test/dm/scmi.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -395,3 +396,64 @@ static int dm_test_scmi_voltage_domains(struct
unit_test_state *uts)
return release_sandbox_scmi_test_devices(uts, dev);
}
DM_TEST(dm_test_scmi_voltage_domains, UT_TESTF_SCAN_FDT);
+
+/*
+ * This part is derived from test/dm/pinmux.c, So
+ *
+ * Copyright (C) 2020 Sean Anderson
+ */
+
+static char buf[64];
+#define test_muxing(selector, expected) do { \
+ ut_assertok(pinctrl_get_pin_muxing(dev, selector, buf, sizeof(buf))); \
+ ut_asserteq_str(expected, (char *)); \
+} while (0)
+
+#define test_name(selector, expected) do { \
+ ut_assertok(pinctrl_get_pin_name(dev, selector, buf, sizeof(buf))); \
+ ut_asserteq_str(expected, (char *)); \
+} while (0)
+
+static int dm_test_scmi_pinmux(struct unit_test_state *uts)
+{
+ struct udevice *dev;
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_PINCTRL, "protocol@19",
+ ));
+ ut_assertok(pinctrl_select_state(dev, "default"));
+ test_muxing(0, "");
+ test_muxing(1, "");
+ test_muxing(2, "I2S.");
+ test_muxing(3, "I2S.");
+ test_muxing(4, "I2S.");
+ test_muxing(5, "GPIO bias-pull-up.");
+ test_muxing(6, "GPIO drive-open-drain output-mode output-value.");
+ test_muxing(7, "GPIO bias-pull-down input-mode.");
+ test_muxing(8, "GPIO bias-disable.");
+
+ ut_assertok(pinctrl_select_state(dev, "alternate"));
+ test_muxing(0, "I2C drive-open-drain.");
+ test_muxing(1, "I2C drive-open-drain.");
+ test_muxing(2, "SPI.");
+ test_muxing(3, "SPI.");
+ test_muxing(4, "SPI.");
+ test_muxing(5, "CS bias-pull-up.");
+ test_muxing(6, "CS drive-open-drain output-mode output-value.");
+ test_muxing(7, "GPIO bias-pull-down input-mode.");
+ test_muxing(8, "GPIO bias-disable.");
+
+ ut_assertok(pinctrl_select_state(dev, "0"));
+ test_muxing(0, "I2C drive-open-drain.");
+ test_muxing(1, "I2C drive-open-drain.");
+ test_muxing(2, "I2S.");
+ test_muxing(3, "I2S.");
+ test_muxing(4, "I2S.");
+ test_muxing(5, "GPIO bias-pull-up.");
+ test_muxing(6, "GPIO drive-open-drain output-mode output-value.");
+ test_muxing(7, "GPIO bias-pull-down input-mode.");
+ test_muxing(8, "GPIO bias-disable.");
+
+ return 0;
+}
+
+DM_TEST(dm_test_scmi_pinmux, UT_TESTF_SCAN_FDT);
--
2.34.1
[RFC 5/6] firmware: scmi: add pseudo pinctrl protocol support on sandbox
With this patch, sandbox SCMI agent can handle pinctrl protocol.
This feature is used in an unit test for SCMI pinctrl.
Signed-off-by: AKASHI Takahiro
---
arch/sandbox/dts/test.dts | 115
drivers/firmware/scmi/sandbox-scmi_agent.c | 722 +
2 files changed, 837 insertions(+)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index dc0bfdfb6e4b..d2ddea801995 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -723,9 +723,124 @@
};
};
};
+
+ pinctrl_scmi: protocol@19 {
+ reg = <0x19>;
+
+ pinctrl-names = "default","alternate";
+ pinctrl-0 = <_pinctrl_gpios>,
<_pinctrl_i2s>;
+ pinctrl-1 = <_pinctrl_spi>,
<_pinctrl_i2c>;
+
+#if 0
+ scmi_pinctrl_gpio_a: scmi_gpios {
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-bank-name = "scmi_gpios";
+ ngpios = <4>;
+ gpio-ranges = <_scmi 0 5 4>,
+ <_scmi 4 0 0>;
+ gpio-ranges-group-names = "",
+ "GPIO_B";
+
+ hog_input_1 {
+ gpio-hog;
+ input;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ };
+ hog_output_3 {
+ gpio-hog;
+ output-high;
+ output-mode;
+ output-value = <1>;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ };
+ };
+#endif
+
+ scmi_pinctrl_gpios: gpios-pins {
+ gpio0 {
+ pins = "P5";
+ function = "GPIO";
+ bias-pull-up;
+ // input-disable;
+ input-mode = <0>;
+ };
+ gpio1 {
+ pins = "P6";
+ function = "GPIO";
+ // output-high;
+ output-mode;
+ output-value = <1>;
+ drive-open-drain;
+ };
+ gpio2 {
+ pinmux = ;
+ bias-pull-down;
+ // input-enable;
+ input-mode;
+ };
+ gpio3 {
+ pinmux = ;
+ bias-disable;
+ };
+ };
+
+ scmi_pinctrl_i2c: i2c-pins {
+ groups {
+ groups = "I2C_UART";
+ function = "I2C";
+ };
+
+ pins {
+ pins = "P0", "P1";
+ drive-open-drain;
+ };
+ };
+
+ scmi_pinctrl_i2s: i2s-pins {
+ groups = "SPI_I2S";
+ function = "I2S";
+ };
+
+ scmi_pinctrl_spi: spi-pins {
+ groups = "SPI_I2S";
+ function = "SPI";
+
+ cs {
+ pinmux = ,
+;
+
[RFC 4/6] gpio: add scmi driver based on pinctrl
This DM-compliant driver deals with SCMI pinctrl protocol and presents
gpio devices exposed by SCMI firmware (server).
Signed-off-by: AKASHI Takahiro
---
drivers/pinctrl/pinctrl-scmi.c | 544 -
1 file changed, 539 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
index 3ebdad57b86c..73d385bdbfcc 100644
--- a/drivers/pinctrl/pinctrl-scmi.c
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -11,21 +11,20 @@
#include
#include
#include
+#include
#include
+#include
+#include
#include
/**
* struct scmi_pin - attributes for a pin
* @name: Name of pin
- * @value: Value of pin
- * @flags: A set of flags
* @function: Function selected
* @status:An array of status of configuration types
*/
struct scmi_pin {
char*name;
- u32 value;
- u32 flags;
unsigned intfunction;
u32 status[SCMI_PINCTRL_CONFIG_RESERVED];
};
@@ -308,7 +307,6 @@ static int scmi_pinmux_group_set(struct udevice *dev,
return 0;
}
-/* TODO: may be driver-specific */
/**
* pinmux_property_set - Enable a pinmux group
* @dev: SCMI pinctrl device to use
@@ -424,6 +422,539 @@ const struct pinctrl_ops scmi_pinctrl_ops = {
.set_state = pinctrl_generic_set_state,
};
+#if CONFIG_IS_ENABLED(DM_GPIO)
+/*
+ * GPIO part
+ */
+
+/**
+ * struct scmi_pinctrl_gpio_plat - platform data
+ * @pinctrl_dev: Associated SCMI pinctrl device
+ * @gpio_map: A list of gpio mapping information
+ * @name: Name of ?
+ * @ngpios:A number of gpio pins
+ */
+struct scmi_pinctrl_gpio_plat {
+ struct list_head gpio_map;
+ char *name;
+ u32 ngpios;
+};
+
+/**
+ * struct scmi_pinctrl_gpio_map - gpio mapping information
+ * @gpio_pin: Start gpio pin selector
+ * @pinctrl_pin: Mapped start pinctrl pin selector, used for linear
mapping
+ * @pinctrl_group: Name of an associated group, used for group namee
mapping
+ * @num_pins: A number of pins
+ * @node: Node for a mapping list
+ */
+struct scmi_pinctrl_gpio_map {
+ struct udevice *pinctrl_dev;
+ u32 gpio_pin;
+ u32 pinctrl_pin;
+ u16 *pinctrl_group;
+ u32 num_pins;
+ struct list_head node;
+};
+
+/**
+ * map_to_id - Map a gpio pin offset to a pinctrl pin selector
+ * @dev: SCMI pinctrl device
+ * @offset:Pin offset
+ * @id:Pinctrl pin selector
+ *
+ * Map a gpio pin offset, @offset, to an associated pinctrl pin selector
+ *
+ * Return: 0 on success, -1 on failure
+ */
+static int map_to_id(struct udevice *dev, unsigned int offset,
+struct udevice **pinctrl_dev, u32 *id)
+{
+ struct scmi_pinctrl_gpio_plat *plat = dev_get_plat(dev);
+ struct scmi_pinctrl_gpio_map *map;
+
+ /* if no mapping is defined, return 1:1 pin */
+ if (list_empty(>gpio_map)) {
+ uclass_first_device(UCLASS_PINCTRL, pinctrl_dev);
+ if (!*pinctrl_dev)
+ return -1;
+
+ *id = offset;
+ return 0;
+ }
+
+ list_for_each_entry(map, >gpio_map, node) {
+ if (offset >= map->gpio_pin &&
+ offset < (map->gpio_pin + map->num_pins)) {
+ *pinctrl_dev = map->pinctrl_dev;
+ if (!pinctrl_dev)
+ return -1;
+
+ if (map->pinctrl_group)
+ *id = map->pinctrl_group[offset
+ - map->gpio_pin];
+ else
+ *id = map->pinctrl_pin
+ + (offset - map->gpio_pin);
+
+ return 0;
+ }
+ }
+
+ return -1;
+}
+
+/**
+ * scmi_gpio_get_value - Get a value of a gpio pin
+ * @dev: SCMI gpio device
+ * @offset:Pin offset
+ *
+ * Get a value of a gpio pin in @offset
+ *
+ * Return: Value of a pin on success, error code on failure
+ */
+static int scmi_gpio_get_value(struct udevice *dev, unsigned int offset)
+{
+ struct scmi_pinctrl_priv *priv;
+ u32 id;
+ struct udevice *pinctrl_dev;
+ struct scmi_pin_entry *config;
+ int config_type, ret;
+
+ if (map_to_id(dev, offset, _dev, )) {
+ dev_err(dev, "Invalid pin: %u\n", offset);
+ return -EINVAL;
+ }
+
+ priv = dev_get_priv(pinctrl_dev);
+ if (priv->pins[id].status[SCMI_PINCTRL_CONFIG_INPUT_MODE]) {
+ config_type = SCMI_PINCTRL_CONFIG_INPUT_VALUE;
+ } else if (priv->pins[id].status[SCMI_PINCTRL_CONFIG_OUTPUT_MODE]) {
+ config_type = SCMI_PINCTRL_CONFIG_OUTPUT_VALUE;
+ } else {
+ dev_err(dev, "Invalid pin mode: %u\n", offset);
+
[RFC 3/6] pinctrl: add scmi driver
This DM-compliant driver deals with SCMI pinctrl protocol and presents
pinctrl devices exposed by SCMI firmware (server).
Signed-off-by: AKASHI Takahiro
---
drivers/pinctrl/Kconfig| 11 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-scmi.c | 537 +
3 files changed, 549 insertions(+)
create mode 100644 drivers/pinctrl/pinctrl-scmi.c
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index 75b3ff47a2e8..d02f5db550c8 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -256,6 +256,17 @@ config PINCTRL_SANDBOX
Currently, this driver actually does nothing but print debug
messages when pinctrl operations are invoked.
+config PINCTRL_SCMI
+ bool "SCMI pinctrl driver"
+ depends on SCMI_FIRMWARE
+ select SCMI_PINCTRL
+ help
+ This enables pinctrl driver base on SCMI.
+
+ The driver is controlled by a device tree node which contains
+ both the GPIO definitions and pin control functions for each
+ available multiplex function.
+
config PINCTRL_SINGLE
bool "Single register pin-control and pin-multiplex driver"
depends on DM
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index fc1f01a02cbd..a791df022b7d 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_PINCTRL_MSCC)+= mscc/
obj-$(CONFIG_ARCH_MVEBU) += mvebu/
obj-$(CONFIG_ARCH_NEXELL) += nexell/
obj-$(CONFIG_PINCTRL_QE) += pinctrl-qe-io.o
+obj-$(CONFIG_PINCTRL_SCMI) += pinctrl-scmi.o
obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
obj-$(CONFIG_PINCTRL_STI) += pinctrl-sti.o
obj-$(CONFIG_PINCTRL_STM32)+= pinctrl_stm32.o
diff --git a/drivers/pinctrl/pinctrl-scmi.c b/drivers/pinctrl/pinctrl-scmi.c
new file mode 100644
index ..3ebdad57b86c
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-scmi.c
@@ -0,0 +1,537 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2023 Linaro Limited
+ * Author: AKASHI Takahiro
+ */
+
+#define LOG_CATEGORY UCLASS_PINCTRL
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct scmi_pin - attributes for a pin
+ * @name: Name of pin
+ * @value: Value of pin
+ * @flags: A set of flags
+ * @function: Function selected
+ * @status:An array of status of configuration types
+ */
+struct scmi_pin {
+ char*name;
+ u32 value;
+ u32 flags;
+ unsigned intfunction;
+ u32 status[SCMI_PINCTRL_CONFIG_RESERVED];
+};
+
+/**
+ * struct scmi_group - attributes for a group
+ * @name: Name of group
+ * @num_pins: A number of pins
+ * @pins: An array of pin id's
+ */
+struct scmi_group {
+ char*name;
+ unsigned intnum_pins;
+ u16 *pins;
+};
+
+/**
+ * struct scmi_pinctrl_priv - private data for pinctrl device
+ * @num_pins: A number of pins
+ * @num_groups:A number of groups
+ * @num_functions: A number of functions
+ * @pins: An array of pins
+ * @groups:An array of groups
+ * @functions: An array of function names
+ */
+struct scmi_pinctrl_priv {
+ unsigned intnum_pins;
+ unsigned intnum_groups;
+ unsigned intnum_functions;
+ struct scmi_pin *pins;
+ struct scmi_group *groups;
+ char**functions;
+};
+
+static const struct pinconf_param scmi_conf_params[] = {
+ { "default", SCMI_PINCTRL_CONFIG_DEFAULT, 1 },
+ { "bias-bus-hold", SCMI_PINCTRL_CONFIG_BIAS_BUS_HOLD, 1 },
+ { "bias-disable", SCMI_PINCTRL_CONFIG_BIAS_DISABLE, 1 },
+ { "bias-high-impedance", SCMI_PINCTRL_CONFIG_BIAS_HI_IMPEDANCE, 1 },
+ { "bias-pull-up", SCMI_PINCTRL_CONFIG_BIAS_PULL_UP, 1 },
+ { "bias-pull-default", SCMI_PINCTRL_CONFIG_BIAS_PULL_DEF, 1 },
+ { "bias-pull-down", SCMI_PINCTRL_CONFIG_BIAS_PULL_DOWN, 1 },
+ { "drive-open-drain", SCMI_PINCTRL_CONFIG_DRIVE_OPEN_DRAIN, 1 },
+ { "drive-open-source", SCMI_PINCTRL_CONFIG_DRIVE_OPEN_SOURCE, 1 },
+ { "drive-push-pull", SCMI_PINCTRL_CONFIG_DRIVE_PUSH_PULL, 1 },
+ { "drive-strength", SCMI_PINCTRL_CONFIG_DRIVE_STRENGTH, 0 },
+ { "input-debounce", SCMI_PINCTRL_CONFIG_INPUT_DEBOUNCE, 0 },
+ { "input-mode", SCMI_PINCTRL_CONFIG_INPUT_MODE, 1 },
+ { "pull-mode", SCMI_PINCTRL_CONFIG_PULL_MODE, 0 },
+ { "input-value", SCMI_PINCTRL_CONFIG_INPUT_VALUE, 0 },
+ { "input-schmitt", SCMI_PINCTRL_CONFIG_INPUT_SCHMITT, 1 },
+ { "low-power-mode", SCMI_PINCTRL_CONFIG_LOW_POWER_MODE, 1 },
+ { "output-mode", SCMI_PINCTRL_CONFIG_OUTPUT_MODE, 1 },
+ { "output-value", SCMI_PINCTRL_CONFIG_OUTPUT_VALUE, 0 },
+ { "power-source", SCMI_PINCTRL_CONFIG_POWER_SOURCE, 0 },
+ { "slew-rate", SCMI_PINCTRL_CONFIG_SLEW_RATE, 0
[RFC 2/6] firmware: scmi: add pinctrl protocol support
With this patch, transport-level utility functions for SCMI pinctrl
protocol are added. DM-compliant device drivers, pinctrl and gpio, are
added in the following patches.
Signed-off-by: AKASHI Takahiro
---
cmd/scmi.c| 1 +
drivers/firmware/scmi/Kconfig | 3 +
drivers/firmware/scmi/Makefile| 1 +
drivers/firmware/scmi/pinctrl.c | 412
drivers/firmware/scmi/scmi_agent-uclass.c | 11 +
include/scmi_agent-uclass.h | 2 +
include/scmi_protocols.h | 435 ++
7 files changed, 865 insertions(+)
create mode 100644 drivers/firmware/scmi/pinctrl.c
diff --git a/cmd/scmi.c b/cmd/scmi.c
index 5efec8ad87fd..ae7892381e0a 100644
--- a/cmd/scmi.c
+++ b/cmd/scmi.c
@@ -33,6 +33,7 @@ struct {
{SCMI_PROTOCOL_ID_SENSOR, "Sensor management"},
{SCMI_PROTOCOL_ID_RESET_DOMAIN, "Reset domain management"},
{SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN, "Voltage domain management"},
+ {SCMI_PROTOCOL_ID_PIN_CONTROL, "Pin control"},
};
/**
diff --git a/drivers/firmware/scmi/Kconfig b/drivers/firmware/scmi/Kconfig
index 8cf85f0d7a12..e0cb7b70dede 100644
--- a/drivers/firmware/scmi/Kconfig
+++ b/drivers/firmware/scmi/Kconfig
@@ -41,3 +41,6 @@ config SCMI_AGENT_OPTEE
help
Enable the SCMI communication channel based on OP-TEE transport
for compatible "linaro,scmi-optee".
+
+config SCMI_PINCTRL
+ bool
diff --git a/drivers/firmware/scmi/Makefile b/drivers/firmware/scmi/Makefile
index 1a23d4981709..bf6381332e9e 100644
--- a/drivers/firmware/scmi/Makefile
+++ b/drivers/firmware/scmi/Makefile
@@ -4,4 +4,5 @@ obj-y += smt.o
obj-$(CONFIG_SCMI_AGENT_SMCCC) += smccc_agent.o
obj-$(CONFIG_SCMI_AGENT_MAILBOX) += mailbox_agent.o
obj-$(CONFIG_SCMI_AGENT_OPTEE) += optee_agent.o
+obj-$(CONFIG_SCMI_PINCTRL) += pinctrl.o
obj-$(CONFIG_SANDBOX) += sandbox-scmi_agent.o sandbox-scmi_devices.o
diff --git a/drivers/firmware/scmi/pinctrl.c b/drivers/firmware/scmi/pinctrl.c
new file mode 100644
index ..88ec57dc3d53
--- /dev/null
+++ b/drivers/firmware/scmi/pinctrl.c
@@ -0,0 +1,412 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * SCMI Pin control protocol as U-Boot device
+ *
+ * Copyright (C) 2023 Linaro Limited
+ * author: AKASHI Takahiro
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * struct scmi_pinctrl_priv - Private data for SCMI Pin control protocol
+ * @channel: Reference to the SCMI channel to use
+ */
+struct scmi_pinctrl_priv {
+ struct scmi_channel *channel;
+};
+
+int scmi_pinctrl_protocol_attrs(struct udevice *dev, u32 *num_pins,
+ u32 *num_groups, u32 *num_functions)
+{
+ struct scmi_pinctrl_protocol_attrs_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_PIN_CONTROL,
+ .message_id = SCMI_PROTOCOL_ATTRIBUTES,
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ if (!dev || !num_pins || !num_groups || !num_functions)
+ return -EINVAL;
+
+ ret = devm_scmi_process_msg(dev, );
+ if (ret)
+ return ret;
+ if (out.status)
+ return scmi_to_linux_errno(out.status);
+
+ *num_groups = SCMI_PINCTRL_ATTRS_NUM_GROUPS(out.attributes_low);
+ *num_pins = SCMI_PINCTRL_ATTRS_NUM_PINS(out.attributes_low);
+ *num_functions = SCMI_PINCTRL_ATTRS_NUM_FUNCTIONS(out.attributes_high);
+
+ return 0;
+}
+
+int scmi_pinctrl_attrs(struct udevice *dev, u32 id, u32 flags,
+ bool *extended_name, u8 **name)
+{
+ struct scmi_pinctrl_attrs_in in;
+ struct scmi_pinctrl_attrs_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_PIN_CONTROL,
+ .message_id = SCMI_PINCTRL_ATTRIBUTES,
+ .in_msg = (u8 *),
+ .in_msg_sz = sizeof(in),
+ .out_msg = (u8 *),
+ .out_msg_sz = sizeof(out),
+ };
+ int ret;
+
+ if (!dev || !extended_name || !name)
+ return -EINVAL;
+
+ in.id = id;
+ in.flags = flags;
+ ret = devm_scmi_process_msg(dev, );
+ if (ret)
+ return ret;
+ if (out.status)
+ return scmi_to_linux_errno(out.status);
+
+ *extended_name = SCMI_PINCTRL_ATTRS_EXTENDED_NAME(out.attributes);
+ *name = strdup(out.name);
+ if (!*name)
+ return -ENOMEM;
+
+ return 0;
+}
+
+int scmi_pinctrl_list_assocs(struct udevice *dev, u32 id, u32 flags,
+u16 **array)
+{
+ struct scmi_pinctrl_list_assocs_in in;
+ struct scmi_pinctrl_list_assocs_out out;
+ struct scmi_msg msg = {
+ .protocol_id = SCMI_PROTOCOL_ID_PIN_CONTROL,
+
[RFC 1/6] firmware: scmi: fix protocol enumeration logic
The original logic in enumerating all the protocols accidentally
modifies a *loop* variable, node, at Voltage domain protocol.
So subsequent protocol nodes in a device tree won't be detected.
Signed-off-by: AKASHI Takahiro
---
drivers/firmware/scmi/scmi_agent-uclass.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/scmi/scmi_agent-uclass.c
b/drivers/firmware/scmi/scmi_agent-uclass.c
index 46a2933d51a4..79584c00a066 100644
--- a/drivers/firmware/scmi/scmi_agent-uclass.c
+++ b/drivers/firmware/scmi/scmi_agent-uclass.c
@@ -422,8 +422,11 @@ static int scmi_bind_protocols(struct udevice *dev)
case SCMI_PROTOCOL_ID_VOLTAGE_DOMAIN:
if (IS_ENABLED(CONFIG_DM_REGULATOR_SCMI) &&
scmi_protocol_is_supported(dev, protocol_id)) {
- node = ofnode_find_subnode(node, "regulators");
- if (!ofnode_valid(node)) {
+ ofnode sub_node;
+
+ sub_node = ofnode_find_subnode(node,
+ "regulators");
+ if (!ofnode_valid(sub_node)) {
dev_err(dev, "no regulators node\n");
return -ENXIO;
}
--
2.34.1
[RFC 0/6] firmware: scmi: add SCMI pinctrl protocol support
This is an RFC and meant to get feedback from other developers as
- the specification (pinctrl part) is still in a draft
- the upstream patch for linux, including dt bindings, is still WIP
- I'm not confident the drivers are generic enough to cover most HWs
- The tests ("ut") doesn't cover all the features yet
This patch series allows users to access SCMI pin control protocol provided
by SCMI server (platform). See SCMI specification document v3.2 beta 2[1]
for more details about SCMI pin control protocol.
The implementation consists of two layers:
- basic helper functions for SCMI pin control protocol
in drivers/firmware/scmi/pinctrl.c (patch#2)
- DM-compliant pinctrl/gpio drivers, which utilizes the helper functions,
in drivers/pinctrl/pinctrl-scmi.c (patch#3,#4)
[1] https://developer.arm.com/documentation/den0056/e/?lang=en
DT bindings
===
Upstream pinctrl patch for linux defines the bindings in [2] though
it doesn't say much.
I expect that my implementation basically complies with U-Boot's generic
bindings described in [3], but not all the features are verified.
As for gpio, unless you hard-code pin assignments directly in a device
driver, my implementation allows the following alternatives in DT.
Either way, we may need an additional binding description for gpio.
(A)
scmi {
... // other protocols
scmi_pinctrl: protocol@19 { // Pin control protocol
...
{pinmux definitions}... // if any, including GPIO?
}
}
scmi_gpio: scmi_gpio {
compatible = "arm,scmi-gpio-generic";
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <_pinctrl 0 5 4>,
<_pinctrl 4 0 0>;
gpio-ranges-group-names = "",
"ANOTHER_GPIO_GROUP";
}
some_device {
...
reset-gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
}
(B)
scmi {
... // other protocols
scmi_pinctrl: protocol@19 { // Pin control protocol
...
{pinmux definitions}... // if any, including GPIO?
scmi_gpio: scmi_gpio {
// no need for "compatible"
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = <_pinctrl 0 5 4>,
<_pinctrl 4 0 0>;
gpio-ranges-group-names = "",
"ANOTHER_GPIO_GROUP";
}
}
}
some_device {
...
reset-gpios = <_gpio 0 GPIO_ACTIVE_HIGH>;
}
(C)
if "gpio-ranges" is missing in gpio definition, assume 1:1 mapping,
i.e. use a native pinctrl pin number (5).
some_device {
...
reset-gpios = <_gpio 5 GPIO_ACTIVE_HIGH>;
}
[2] https://lkml.iu.edu/hypermail/linux/kernel/2308.1/01084.html
[3] /doc/device-tree-bindings/pinctrl/pinctrl-bindings.txt
/doc/device-tree-bindings/gpio/gpio.txt
Test
The patch series was tested on the following platforms:
* sandbox ("ut dm pinmux" and manually using gpio command)
Prerequisite:
=
* This patch series is based on my WIP "Base protocol support" patches
on v2023.10-rc3. You can fetch the whole code from [4].
[4] https://git.linaro.org/people/takahiro.akashi/u-boot.git
branch:scmi/pinctrl
Patches:
Patch#1: Add SCMI base protocol driver
Patch#2-#4: Add drivers
Patch#5-#6: Test related
Change history:
===
RFC (Sep 6, 2023)
* initial release as RFC
AKASHI Takahiro (6):
firmware: scmi: fix protocol enumeration logic
firmware: scmi: add pinctrl protocol support
pinctrl: add scmi driver
gpio: add scmi driver based on pinctrl
firmware: scmi: add pseudo pinctrl protocol support on sandbox
test: dm: add SCMI pinctrl test
arch/sandbox/dts/test.dts | 115 +++
cmd/scmi.c |1 +
drivers/firmware/scmi/Kconfig |3 +
drivers/firmware/scmi/Makefile |1 +
drivers/firmware/scmi/pinctrl.c| 412
drivers/firmware/scmi/sandbox-scmi_agent.c | 722 +
drivers/firmware/scmi/scmi_agent-uclass.c | 18 +-
drivers/pinctrl/Kconfig| 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-scmi.c | 1071
include/scmi_agent-uclass.h|2 +
include/scmi_protocols.h | 435
test/dm/scmi.c | 62 ++
13 files changed, 2852 insertions(+), 2 deletions(-)
create mode 100644 drivers/firmware/scmi/pinctrl.c
create mode 100644 drivers/pinctrl/pinctrl-scmi.c
--
2.34.1
Re: [PATCH] sunxi: board: provide CPU idle states to loaded OS
On Tue, 5 Sep 2023 11:37:31 +0300 Andrey Skvortsov wrote: Hi, > On 23-09-05 09:27, Andre Przywara wrote: > > On Mon, 4 Sep 2023 23:54:30 +0300 > > Andrey Skvortsov wrote: > > > > Hi Andrey, > > > > > When using SCPI as the PSCI backend, firmware can wake up the CPUs and > > > cluster from sleep, so CPU idle states are available for loaded OS to > > > use. TF-A modifies DTB to advertise available CPU idle states, when > > > SCPI is detected. This change copies nodes added by TF-A to any new > > > dtb that is used for loaded OS. > > > > Why do you need that, exactly? Why not just use $fdtcontroladdr for the > > kernel? We now keep the U-Boot copy of the .dts files in sync with the > > kernel. If you need to modify the DT in U-Boot, for instance by applying > > overlays, you can copy that DTB into a better suitable location first: > > => fdt move $fdtcontroladdr $fdt_addr_r > > > > In any case, there shall be only one DT, that one in the U-Boot image. Why > > do you need to load another one for the kernel? > > extlinux is used by distributions (sometimes with device-specific changes > especially What distros are that? I guess some special ones, targeting embedded devices, like the Pinephone? And who is generating extlinux.conf then? Is that some distro specific scripting, similar to how grub is configured? Honest questions, I am not a user of extlinux, I mostly use UEFI booting, or type U-Boot commands directly for experiments, or use boot.scr, as a quick-and-dirty hack. > for platforms not fully supported by mainline yet), Do you need any changes to the DT? Do you need to apply overlays? If you run on a non-mainlined platform, you could still put your DT into the U-Boot tree, then you wouldn't need to load another DTB, which also simplifies the deployment on the kernel/distro side. > then U-Boot loads DT defined in > extlinux.conf file. u-boot scripts are not used in case of extlinux at all. That's fine, you don't need any U-Boot scripts for this to work. If there is no "fdt" or "fdtdir" label in extlinux.conf, then the U-Boot PXE code will eventually fall back to $fdtcontroladdr - I just tested that. So could you make that work for you? I guess all you need to change is to remove any fdtdir label from extlinux.conf? Cheers, Andre
[PATCH v1] clk: use private clk struct in CLK_CCF's enable/disable functions
In clk_enable()/clk_disable() functions, when CCF is activated,
we must pass a private clk struct to enable()/disable() ops functions.
Otherwise, the use of a container_of() construction within these ops
should be banned. Because passing a non-private clk struct to
container_of() results in an out of range error.
At the moment, clk-mux, clk-fixed-factor, clk-gate and possibly other
clocks use container_of() in their enable()/disable() functions.
Therefore, for these functions to work correclty, private clk struct
must be passed.
Signed-off-by: Maksim Kiselev
---
drivers/clk/clk-uclass.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index dc3e9d6a26..542ec41cba 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -649,7 +649,7 @@ int clk_enable(struct clk *clk)
}
if (ops->enable) {
- ret = ops->enable(clk);
+ ret = ops->enable(clkp ? clkp : clk);
if (ret) {
printf("Enable %s failed\n", clk->dev->name);
return ret;
@@ -706,7 +706,7 @@ int clk_disable(struct clk *clk)
}
if (ops->disable) {
- ret = ops->disable(clk);
+ ret = ops->disable(clkp ? clkp : clk);
if (ret)
return ret;
}
--
2.39.2
Re: [PATCH v5 3/4] schemas: Add some common reserved-memory usages
On Thu, 31 Aug 2023 at 01:18, Simon Glass wrote:
>
> The Devicetree specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.
>
> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload" which selects the OS to be booted.
> Thus an handover interface is required between these two pieces.
>
> Where UEFI boot-time services are not available, but UEFI firmware is
> present on either side of this interface, information about memory usage
> and attributes must be presented to the "Payload" in some form.
>
I don't think the UEFI references are needed or helpful here.
> This aims to provide an small schema addition for this mapping.
>
> For now, no attempt is made to create an exhaustive binding, so there are
> some example types listed. More can be added later.
>
> The compatible string is not included, since the node name is enough to
> indicate the purpose of a node, as per the existing reserved-memory
> schema.
>
> This binding does not include a binding for the memory 'attribute'
> property, defined by EFI_BOOT_SERVICES.GetMemoryMap(). It may be useful
> to have that as well, but perhaps not as a bit mask.
>
> Signed-off-by: Simon Glass
> ---
>
> Changes in v5:
> - Drop the memory-map node (should have done that in v4)
> - Tidy up schema a bit
>
> Changes in v4:
> - Make use of the reserved-memory node instead of creating a new one
>
> Changes in v3:
> - Reword commit message again
> - cc a lot more people, from the FFI patch
> - Split out the attributes into the /memory nodes
>
> Changes in v2:
> - Reword commit message
>
> .../reserved-memory/common-reserved.yaml | 53 +++
> 1 file changed, 53 insertions(+)
> create mode 100644 dtschema/schemas/reserved-memory/common-reserved.yaml
>
> diff --git a/dtschema/schemas/reserved-memory/common-reserved.yaml
> b/dtschema/schemas/reserved-memory/common-reserved.yaml
> new file mode 100644
> index 000..d1b466b
> --- /dev/null
> +++ b/dtschema/schemas/reserved-memory/common-reserved.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/reserved-memory/common-reserved.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Common memory reservations
> +
> +description: |
> + Specifies that the reserved memory region can be used for the purpose
> + indicated by its node name.
> +
> + Clients may reuse this reserved memory if they understand what it is for.
> +
> +maintainers:
> + - Simon Glass
> +
> +allOf:
> + - $ref: reserved-memory.yaml
> +
> +properties:
> + $nodename:
> +enum:
> + - acpi-reclaim
> + - acpi-nvs
> + - boot-code
> + - boot-data
> + - runtime-code
> + - runtime-data
> +
These types are used by firmware to describe the nature of certain
memory regions to the OS. Boot code and data can be discarded, as well
as ACPI reclaim after its contents have been consumed. Runtime code
and data need to be mapped for runtime features to work.
When one firmware phase communicates the purpose of a certain memory
reservation to another, it is typically not limited to whether its
needs to be preserved and when it needs to be mapped (and with which
attributes). I'd expect a memory reservation appearing under this node
to have a clearly defined purpose, and the subsequent phases need to
be able to discover this information.
For example, a communication buffer for secure<->non-secure
communication or a page with spin tables used by PSCI. None of the
proposed labels are appropriate for this, and I'd much rather have a
compatible string or some other property that clarifies the nature in
a more suitable way. Note that 'no-map' already exists to indicate
that the CPU should not map this memory unless it does so for the
specific purpose that the reservation was made for.
> + reg:
> +description: region of memory that is reserved for the purpose indicated
> + by the node name.
> +
> +required:
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> +reserved-memory {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +
> +boot-code@1234 {
> +reg = <0x1234 0x0080>;
> +};
> +
> +boot-data@4321 {
> +reg = <0x4321 0x0080>;
> +};
> +};
> --
> 2.42.0.rc2.253.gd59a3bf2b4-goog
>
Re: NVMe support on RPi CM4 board
Hi Luis, L On Tue, Sep 5, 2023, 12:00 Luis Alfredo da Silva wrote: > Hi Simon, it took me some time to come back to this issue, but I was able > to enable the debug messages on drivers/nvme/nvme.c. > > This is what I got when running the nvme scan command > > U-Boot> pci > BusDevFun VendorId DeviceId Device Class Sub-Class > _ > 00.00.00 0x14e4 0x2711 Bridge device 0x04 > 01.00.00 0x1c5c 0x174a Mass storage controller 0x08 > U-Boot> nvme info > U-Boot> nvme scan > Cannot set queue count (err=-110) > Unable to setup I/O queues(err=-110) > Failed to probe 'nvme#0': err=-110 > U-Boot> > > I'm reporting as soon as I got the messages, but I'll continue > investigating. > Can you check if the device has PCI bus master enabled? Regards, Simon > Regards, > Luis > > > El mié, 9 ago 2023 a las 20:15, Simon Glass () escribió: > >> Hi Luis, >> >> On Wed, 9 Aug 2023 at 10:43, Luis Alfredo da Silva >> wrote: >> > >> > Hi Simon, I enabled the next four variables >> > >> > CONFIG_NVME_PCI=y >> > CONFIG_NVME=y >> > CONFIG_CMD_NVME=y >> > CONFIG_PCI=y >> > >> > how different is CONFIG_NVME_PCI from NVME_PCI, I took the latter value >> from several configs files in u-boot repo and from [1] >> >> I just left off the CONFIG as they all have that. This looks right to >> me. Assuming that the NVMe controller appears in 'dm tree' perhaps you >> can enable debugging in the driver and see why it is not working? >> >> Regards, >> Simon >> >> >> > >> > >> > [1] >> https://github.com/u-boot/u-boot/blob/ef8336e2705fce2502383f25d68188c6b1f94dd0/doc/develop/driver-model/nvme.rst#L44 >> > >> > El mar, 8 ago 2023 a las 22:05, Simon Glass () >> escribió: >> >> >> >> Hi Luis, >> >> >> >> On Tue, 8 Aug 2023 at 17:09, Luis Alfredo da Silva >> >> wrote: >> >> > >> >> > I compiled u-boot version 2023-07 and boot it on a RPi CM4 using a >> PCIe M.2 >> >> > NVMe drive, but it doesn't appear to be working. >> >> > >> >> > Once u-boot has started and boot successfully it recognizes the PCIe >> device >> >> > giving me the next output >> >> > >> >> > U-Boot> pci >> >> > BusDevFun VendorId DeviceId Device Class Sub-Class >> >> > _ >> >> > 00.00.00 0x14e4 0x2711 Bridge device 0x04 >> >> > 01.00.00 0x1c5c 0x174a Mass storage controller 0x08 >> >> > >> >> > but when trying to use the nvme scan and nvme info there is not >> output. >> >> > >> >> > NVMe drive has two partitions 1st is a FAT partition, and 2nd is a >> EXT4 >> >> > partition, the RPi firmware recognizes the FAT partition and u-boot >> boot >> >> > correctly. >> >> > >> >> > I don't know if this worked before, but I saw in the mailing list >> that >> >> > there could be already support for other ARM64 boards. >> >> >> >> Is NVME_PCI enabled? >> >> >> >> Regards, >> >> SImon >> >
Re: Pull request: please pull u-boot-imx-20230905
On Tue, Sep 05, 2023 at 09:56:31AM +0200, Stefano Babic wrote: > Hi Tom, > > some fixes for the release, please pull from u-boot-imx, thanks ! > > The following changes since commit 8999257f219d1e371c2fd66f255b8782897944d9: > > Merge tag 'doc-2023-10-rc4-2' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2023-09-02 09:08:54 > -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git > tags/u-boot-imx-20230905 > > for you to fetch changes up to a79fca7b44d0dee96e14d31de5869b35b587283c: > > thermal: imx_tmu: Increase the polling interval (2023-09-04 17:26:44 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-riscv/master
On Tue, Sep 05, 2023 at 11:30:34AM +0800, Leo Liang wrote: > Hi Tom, > > The following changes since commit 493fd3363f6da6a784514657d689c7cda0f390d5: > > nokia_rx51: Remove platform (2023-09-04 21:14:32 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-riscv.git > > for you to fetch changes up to dfe08374943c0e898fcfaf7327f69e0fb56b7d23: > > risc-v: implement DBCN based debug console (2023-09-05 10:53:55 +0800) > > CI result shows no issue: > https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/17650 Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 7/7] fs: Fix a confusing error about overlapping regions
Hi Tom,
On Sun, 3 Sept 2023 at 13:25, Tom Rini wrote:
>
> On Sun, Sep 03, 2023 at 12:06:13PM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Sun, 3 Sept 2023 at 10:42, Tom Rini wrote:
> > >
> > > On Thu, Aug 31, 2023 at 06:15:19PM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 23 Aug 2023 at 09:14, Tom Rini wrote:
> > > > >
> > > > > On Wed, Aug 23, 2023 at 07:42:03AM -0600, Simon Glass wrote:
> > > > >
> > > > > > When lmb runs out of space in its internal tables, it gives
errors on
> > > > > > every fs load operation. This is horribly confusing, as the
poor user
> > > > > > tries different memory regions one at a time.
> > > > > >
> > > > > > Use the updated API to check the error code and print a helpful
message.
> > > > > > Also, allow the operation to proceed.
> > > > > >
> > > > > > Update the tests accordingly.
> > > > > >
> > > > > > Signed-off-by: Simon Glass
> > > > > [snip]
> > > > > > + if (ret == -E2BIG) {
> > > > > > + log_warning("Reservation tables exhausted: see
CONFIG_LMB_USE_MAX_REGIONS\n");
> > > > > > + return 0;
> > > > > > + }
> > > > >
> > > > > This isn't the right option. Everyone has
CONFIG_LMB_USE_MAX_REGIONS
> > > > > set. You would want to increase CONFIG_LMB_MAX_REGIONS.
> > > > >
> > > > > But it sounds like what you've found and fixed is an underlying
problem
> > > > > as to why 16 regions isn't enough in some common cases now? So
we could
> > > >
> > > > I don't think I have fixed anything. But I'll send v2 and perhaps it
> > > > will be clearer what is going on here.
> > > >
> > > > > possibly avoid the string size growth here and have a comment
that also
> > > > > matches up with the help under LMB_MAX_REGIONS?
> > > >
> > > > I don't know, sorry. The size of struct(lmb) on 64-bit sandbox is
> > > > about 400 bytes. There seems to be a lot of code to save not much
> > > > memory.
> > >
> > > What do you mean here? The alternative is not unlimited ranges but
> > > instead to define the limit of memory regions and limit of reserved
> > > ranges.
> >
> > A better alternative would be not to limit the number of regions, IMO,
> > i.e. have an array of regions that can grow as needed.
>
> That's not something that we have in the code today, however.
No, I do have an arraylist thing that I plan to upstream, which could
handle that.
But for this series, what do you think of the memregion idea? I am still
unsure of the saming we should use - see Heinrich's comments too.
Regards,
Simon
Re: [PATCH 1/2] riscv: cpu: Rename EVENT_SPY to EVENT_SPY_SIMPLE
On Tue, 5 Sept 2023 at 07:48, Marek Vasut
wrote:
>
> Fix up cpu.c and align it with commit
> 6c4cad7438 ("event: Rename EVENT_SPY to EVENT_SPY_FULL")
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Chanho Park
> Cc: Leo
> Cc: Nikita Shubin
> Cc: Padmarao Begari
> Cc: Rick Chen
> Cc: Simon Glass
> Cc: Yu Chien Peter Lin
> ---
> arch/riscv/cpu/cpu.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Reviewed-by: Simon Glass
Re: [PATCH 2/2] event: Rename rest of EVENT_SPY to EVENT_SPY_FULL or EVENT_SPY*
On Tue, 5 Sept 2023 at 07:48, Marek Vasut
wrote:
>
> Fix up remaining occurances of EVENT_SPY with no suffix.
>
> Fixes: 6c4cad7438 ("event: Rename EVENT_SPY to EVENT_SPY_FULL")
> Signed-off-by: Marek Vasut
> ---
> Cc: Chanho Park
> Cc: Leo
> Cc: Nikita Shubin
> Cc: Padmarao Begari
> Cc: Rick Chen
> Cc: Simon Glass
> Cc: Yu Chien Peter Lin
> ---
> common/Kconfig | 4 ++--
> include/event.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
Reviewed-by: Simon Glass
Re: [PATCH v2] binman: Fix SyntaxWarning: invalid escape sequence '\('
Hi Rong,
On Tue, 5 Sept 2023 at 05:47, Rong Tao wrote:
>
> From: Rong Tao
>
> Reproduct warning:
>
> $ git clean -dfx
> $ make CROSS_COMPILE="" qemu-x86_64_defconfig
> $ make -j8
I cannot repro that...what toolchain are you using? Could you send the full
build log?
> ...
> u-boot/tools/binman/etype/section.py:25:
> SyntaxWarning: invalid escape sequence '\('
> """Entry that contains other entries
>
> Signed-off-by: Rong Tao
> ---
> tools/binman/etype/section.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/binman/etype/section.py b/tools/binman/etype/section.py
> index fb49e85a7634..30c1041c7e8d 100644
> --- a/tools/binman/etype/section.py
> +++ b/tools/binman/etype/section.py
> @@ -40,7 +40,7 @@ class Entry_section(Entry):
> For example code, see etypes which subclass `Entry_section`, or
`cbfs.py`
> for a more involved example::
>
> - $ grep -l \(Entry_section tools/binman/etype/*.py
> + $ grep -l \\(Entry_section tools/binman/etype/*.py
>
> ReadNode()
> Call `super().ReadNode()`, then read any special properties for
the
> --
> 2.41.0
>
Reviewed-by: Simon Glass
Regards,
Simon
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Hi Jonas,
On Mon, 4 Sept 2023 at 10:52, Jonas Karlman wrote:
>
> Hi Massimo,
>
> On 2023-09-04 17:05, Massimo Pegorer wrote:
> > Hi,
> >
> > Is there any way for binman to package FIT with U-Boot TF-A and
> > OP-TEE, using bl32 binary provided by Rockchip as TEE?
> >
> > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but
> > binman failed.
> >
> > In my poor understanding of Python code, it seems binman accepts only
> > ELF format or a binary format starting with optee_v1_header, but
> > binaries provided by Rockchip in rkbin repository do not have this
> > header.
>
> One way that I have used/tested before was to create a tee.elf version
> using something like:
>
> $ aarch64-linux-gnu-objcopy -B aarch64 -I binary -O elf64-littleaarch64
xxx_bl32_vX.YZ.bin bl32.o
> $ aarch64-linux-gnu-ld bl32.o -T tee.ld -o tee.elf
>
> tee.ld:
>
> ENTRY(_binary_bl32_bin_start);
>
> SECTIONS
> {
> . = 0x0840;
> .data : {
> *(.data)
> }
> }
>
>
> And then make with TEE=tee.elf, however keep in mind that U-Boot may not
> treat the memory region used by OP-TEE properly for aarch64.
>
> Regards,
> Jonas
>
> >
> > Thanks in advance for any hints!
Should we do something to support a 'flat' binary in the tee-os entry type?
For example, we could allow it if so long as a fixed load address is
provided? It might be a bit of a hack though.
Regards,
Simon
Re: [PATCH] Makefile: Force regeneration of env.txt
On 9/5/23 1:09 PM, Andrew Davis wrote:
If the source .env file changes to one that is also older than
the generated env.txt file then it is not regenerated. This means
when switching board configs we do not regenerate the env. This
can be tested easily with:
$ make j721e_evm_a72_defconfig
$ make # this may fail to complete but that is okay for this test
$ make am64x_evm_a53_defconfig
$ make
$ vim include/generated/env.txt
Note this is still the J721e env not the AM64 config as expected.
There is probably a better way to detect if the dependency name changed,
but that may involve extra files and hashing contents, so let's just
force it for now.
Signed-off-by: Andrew Davis
---
This is basically a revert of:
36fc832927eb ("Makefile: Fix incorrect FORCE deps on env rules")
But without changing the `include/generated/env.in` rule. The more
I think about it, that should also be changed to forced as right
now any changes to include/config.h or other kconfig options are
not reflected in the env.in file after updates.
That rule should depend on the generated config file so that any
change in kconfig variables will cause it to regenerate, that
might be what we need for this target instead of FORCE.
Andrew
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 9be24c4ec61..d195590d4b0 100644
--- a/Makefile
+++ b/Makefile
@@ -1830,7 +1830,7 @@ quiet_cmd_envc = ENVC$@
touch $@ ; \
fi
-include/generated/env.txt: $(wildcard $(ENV_FILE))
+include/generated/env.txt: $(wildcard $(ENV_FILE)) FORCE
$(call cmd,envc)
# Write out the resulting environment, converted to a C string
[PATCH 3/3] arm: dts: j7200: dtb sync with Linux 6.5-rc1
Sync j7200 device tree files with Linux 6.5-rc1
- k3-j7200-r5-common-proc-board.dts now inherits from
k3-j7200-common-proc-board.dts instead of k3-j7200-som-p0.dtsi. This
allows us to trim down the r5 file considerably by using existing
properties.
- remove pimux nodes from r5 file
- remove duplicate nodes & node properties from r5/u-boot files
- mcu_timer0 now used instead of timer1
mcu_timer0 device id added to dev-data.c file in order to work
- remove cpsw node
This node is no longer required since the compatible is now fixed
- remove dummy_clock_19_2_mhz
This node wasn't being used anyhere, so it was removed.
- remove dummy_clock_200mhz
main_sdhci0 & main_sdhci1 no longer need dummy clock for eMMC/SD
- fix secure proxy node
mcu_secproxy changed to used secure_prxy_mcu which is already
defined in k3-j7200-mcu-wakeup.dtsi
Signed-off-by: Reid Tonking
---
.../k3-j7200-common-proc-board-u-boot.dtsi| 160 +++---
arch/arm/dts/k3-j7200-common-proc-board.dts | 170 --
arch/arm/dts/k3-j7200-main.dtsi | 512 +-
arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 265 -
.../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +-
arch/arm/dts/k3-j7200-som-p0.dtsi | 153 --
arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++
arch/arm/dts/k3-j7200.dtsi| 30 +-
8 files changed, 1150 insertions(+), 488 deletions(-)
create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi
diff --git a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
index f25c7136c9..c32df00e9c 100644
--- a/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-j7200-common-proc-board-u-boot.dtsi
@@ -1,22 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com/
+ * Copyright (C) 2020-2023 Texas Instruments Incorporated - https://www.ti.com/
*/
#include "k3-j7200-binman.dtsi"
/ {
chosen {
- stdout-path = "serial2:115200n8";
- tick-timer =
- };
-
- aliases {
- ethernet0 = _port1;
- i2c0 = _i2c0;
- i2c1 = _i2c0;
- i2c2 = _i2c1;
- i2c3 = _i2c0;
+ tick-timer = _timer0;
};
};
@@ -28,48 +19,42 @@
bootph-pre-ram;
};
-_mcu_wakeup {
+_esm {
bootph-pre-ram;
+};
- timer1: timer@4040 {
- compatible = "ti,omap5430-timer";
- reg = <0x0 0x4040 0x0 0x80>;
- ti,timer-alwon;
- clock-frequency = <25000>;
- bootph-pre-ram;
- };
+_mcu_wakeup {
+ bootph-pre-ram;
chipid@4314 {
bootph-pre-ram;
};
+};
- mcu_navss: bus@2838 {
- bootph-pre-ram;
- #address-cells = <2>;
- #size-cells = <2>;
-
- ringacc@2b80 {
- reg = <0x0 0x2b80 0x0 0x40>,
- <0x0 0x2b00 0x0 0x40>,
- <0x0 0x2859 0x0 0x100>,
- <0x0 0x2a50 0x0 0x4>,
- <0x0 0x2844 0x0 0x4>;
- reg-names = "rt", "fifos", "proxy_gcfg",
"proxy_target", "cfg";
- bootph-pre-ram;
- };
-
- dma-controller@285c {
- reg = <0x0 0x285c 0x0 0x100>,
- <0x0 0x284c 0x0 0x4000>,
- <0x0 0x2a80 0x0 0x4>,
- <0x0 0x284a 0x0 0x4000>,
- <0x0 0x2aa0 0x0 0x4>,
- <0x0 0x2840 0x0 0x2000>;
- reg-names = "gcfg", "rchan", "rchanrt", "tchan",
- "tchanrt", "rflow";
- bootph-pre-ram;
- };
- };
+_navss {
+ bootph-pre-ram;
+};
+
+_ringacc {
+ reg = <0x0 0x2b80 0x0 0x40>,
+ <0x0 0x2b00 0x0 0x40>,
+ <0x0 0x2859 0x0 0x100>,
+ <0x0 0x2a50 0x0 0x4>,
+ <0x0 0x2844 0x0 0x4>;
+ reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg";
+ bootph-pre-ram;
+};
+
+_udmap {
+ reg = <0x0 0x285c 0x0 0x100>,
+ <0x0 0x284c 0x0 0x4000>,
+ <0x0 0x2a80 0x0 0x4>,
+ <0x0 0x284a 0x0 0x4000>,
+ <0x0 0x2aa0 0x0 0x4>,
+ <0x0 0x2840 0x0 0x2000>;
+ reg-names = "gcfg", "rchan", "rchanrt", "tchan",
+ "tchanrt", "rflow";
+ bootph-pre-ram;
};
_proxy_main {
@@ -78,10 +63,6 @@
{
bootph-pre-ram;
- k3_sysreset:
[PATCH 2/3] arm: mach-k3: j7200: Add mcu_timer0 id to the dev list
mcu_timer0 is now used as the tick timer in u-boot, so this adds the
timer to the soc device list so it can be enabled via the k3 power
controller.
Signed-off-by: Reid Tonking
---
arch/arm/mach-k3/j7200/dev-data.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-k3/j7200/dev-data.c
b/arch/arm/mach-k3/j7200/dev-data.c
index 4ddc34210e..8ce6796fd0 100644
--- a/arch/arm/mach-k3/j7200/dev-data.c
+++ b/arch/arm/mach-k3/j7200/dev-data.c
@@ -46,6 +46,7 @@ static struct ti_lpsc soc_lpsc_list[] = {
static struct ti_dev soc_dev_list[] = {
PSC_DEV(30, _lpsc_list[0]),
+ PSC_DEV(35, _lpsc_list[0]),
PSC_DEV(61, _lpsc_list[1]),
PSC_DEV(90, _lpsc_list[2]),
PSC_DEV(8, _lpsc_list[3]),
--
2.34.1
[PATCH 1/3] drivers: misc: k3_avs: Add Linux compatible to enable avs in u-boot
The ti,j7200-vtm compatible is used for voltage and thermal monitoring
(VTM) by (drivers/thermal/k3_j72xx_bandgap.c) in Linux, but the same
hardware is used for adaptive voltage scaling (AVS) in u-boot, This brings
both drivers in line with the same compatible. Since the j7200 uses the
config as the j721e, the data is inherited from j721e vs creating a
duplicate in all but name.
Signed-off-by: Reid Tonking
---
drivers/misc/k3_avs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/k3_avs.c b/drivers/misc/k3_avs.c
index 840148d090..f7936017ba 100644
--- a/drivers/misc/k3_avs.c
+++ b/drivers/misc/k3_avs.c
@@ -382,7 +382,7 @@ static struct vd_config am654_vd_config = {
static const struct udevice_id k3_avs_ids[] = {
{ .compatible = "ti,am654-avs", .data = (ulong)_vd_config },
{ .compatible = "ti,j721e-avs", .data = (ulong)_vd_config },
- {}
+ { .compatible = "ti,j7200-vtm", .data = (ulong)_vd_config }
};
U_BOOT_DRIVER(k3_avs) = {
--
2.34.1
[PATCH 0/3] J7200 device tree sync from v6.5-rc1 to u-boot
This series tries to sync device tree files from Linux v6.5-rc1 while making changes to the u-boot.dtsi and r5-common-proc-board.dts files in order to remove duplicate nodes and achieve successful boot. MCU Ringacc [0] and DMA fixes [1] are currently being upstreamed to Linux. They'll be fixed in U-boot post their merge in Linux, hopefully during v6.6-rc1 timeframe. Test Logs are included in [2] [0]: https://lore.kernel.org/all/20230809175932.2553156-1-vigne...@ti.com/ [1]: https://lore.kernel.org/all/20230810174356.3322583-1-vigne...@ti.com/ [2]: https://gist.github.com/Glockn/73c30d9a189919169e38c2c2566b5fc6 Signed-off-by: Reid Tonking --- Changes in v2: - Separated mcu_timer0 fix into separate patch - Added j7200-vtm compatible to k3_avs driver instead of using j721e compatible - node no longer needed for buck1_reg to enable avs - dropped uneeded chosen/alias property/node from u-boot.dtsi file - fixed spacing/typo issues - removed most nesting of nodes and using mostly labels only now - removed _r5fss0 - _timer0 now correctly implemented - _tifs moved to r5 root node - Link to v1: https://lore.kernel.org/u-boot/20230822185725.6718-1-re...@ti.com/ --- Reid Tonking (3): drivers: misc: k3_avs: Add Linux compatible to enable avs in u-boot arm: mach-k3: j7200: Add mcu_timer0 id to the dev list arm: dts: j7200: dtb sync with Linux 6.5-rc1 .../k3-j7200-common-proc-board-u-boot.dtsi| 160 +++--- arch/arm/dts/k3-j7200-common-proc-board.dts | 170 -- arch/arm/dts/k3-j7200-main.dtsi | 512 +- arch/arm/dts/k3-j7200-mcu-wakeup.dtsi | 265 - .../arm/dts/k3-j7200-r5-common-proc-board.dts | 301 +- arch/arm/dts/k3-j7200-som-p0.dtsi | 153 -- arch/arm/dts/k3-j7200-thermal.dtsi| 47 ++ arch/arm/dts/k3-j7200.dtsi| 30 +- arch/arm/mach-k3/j7200/dev-data.c | 1 + drivers/misc/k3_avs.c | 2 +- 10 files changed, 1152 insertions(+), 489 deletions(-) create mode 100644 arch/arm/dts/k3-j7200-thermal.dtsi -- 2.34.1
[PATCH] Makefile: Force regeneration of env.txt
If the source .env file changes to one that is also older than the generated env.txt file then it is not regenerated. This means when switching board configs we do not regenerate the env. This can be tested easily with: $ make j721e_evm_a72_defconfig $ make # this may fail to complete but that is okay for this test $ make am64x_evm_a53_defconfig $ make $ vim include/generated/env.txt Note this is still the J721e env not the AM64 config as expected. There is probably a better way to detect if the dependency name changed, but that may involve extra files and hashing contents, so let's just force it for now. Signed-off-by: Andrew Davis --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 9be24c4ec61..d195590d4b0 100644 --- a/Makefile +++ b/Makefile @@ -1830,7 +1830,7 @@ quiet_cmd_envc = ENVC$@ touch $@ ; \ fi -include/generated/env.txt: $(wildcard $(ENV_FILE)) +include/generated/env.txt: $(wildcard $(ENV_FILE)) FORCE $(call cmd,envc) # Write out the resulting environment, converted to a C string -- 2.39.2
Re: Binman how to build using Rockchip BL32 binary as OP-TEE
Il giorno lun 4 set 2023 alle ore 18:49 Simon Glass ha scritto: > > Hi Massimo, > > On Mon, 4 Sept 2023 at 09:05, Massimo Pegorer > wrote: > > > > Hi, > > > > Is there any way for binman to package FIT with U-Boot TF-A and > > OP-TEE, using bl32 binary provided by Rockchip as TEE? > > > > I've tried with TEE=/path/to/rkbin/bin/rk33/xxx_bl32_vX.YZ.bin, but > > binman failed. > > > > In my poor understanding of Python code, it seems binman accepts only > > ELF format or a binary format starting with optee_v1_header, but > > binaries provided by Rockchip in rkbin repository do not have this > > header. > > Yes that is correct. How would U-Boot know the load address of the TEE > fille? Hmm it seems to be a fixed address. Perhaps you could change > the rockchip-u-boot.dtsi file to make the 'tee-os' node a 'blobext' > node instead, then add a filename property in there with the name of > your file? Yes, I agree, it can not. But I was not complaining about binman, just wondering what I was missing, or why Rockchip binaries are lacking of optee_v1_header. It seems these binaries are in the format of tee-pager_v2.bin. I suspect the load address is the value of the ADDR field in the [BL32_OPTION] of rkbin/RKTRUST/RK33xxTRUST.ini file. That is 0x0840 except for RK3308 which has 0x0020. I will give it a try. Thanks. Regards, Massimo > > > > > Thanks in advance for any hints! > > Regards, > Simon
[PATCH v1] clk: mux: check value returned from clk_mux_val_to_index()
The clk_mux_val_to_index() may return -EINVAL. In this case
clk_mux_get_parent() will return a wrong parent index and
this will lead to out of bounds error.
E.g. when we register mux clk:
ret = clk_register(clk, UBOOT_DM_CLK_CCF_MUX, name,
parent_names[clk_mux_get_parent(clk)]);
Let's add a check on the return value of clk_mux_val_to_index() and if
it's negative, set parent index to 0.
Signed-off-by: Maksim Kiselev
---
drivers/clk/clk-mux.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 017f25f7a5..00fe916171 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -88,6 +88,7 @@ unsigned int clk_mux_index_to_val(u32 *table, unsigned int
flags, u8 index)
u8 clk_mux_get_parent(struct clk *clk)
{
struct clk_mux *mux = to_clk_mux(clk);
+ int index;
u32 val;
#if IS_ENABLED(CONFIG_SANDBOX_CLK_CCF)
@@ -98,7 +99,13 @@ u8 clk_mux_get_parent(struct clk *clk)
val >>= mux->shift;
val &= mux->mask;
- return clk_mux_val_to_index(clk, mux->table, mux->flags, val);
+ index = clk_mux_val_to_index(clk, mux->table, mux->flags, val);
+ if (index < 0) {
+ log_err("Could not fetch index\n");
+ index = 0;
+ }
+
+ return index;
}
static int clk_fetch_parent_index(struct clk *clk,
--
2.39.2
Re: [PATCH 2/2] riscv: Correct event usage for riscv_cpu_probe/setup
On Mon, 2023-09-04 at 15:06, Tom Rini wrote:
> With having both an EVENT_SPY_SIMPLE setup for both riscv_cpu_probe and
> riscv_cpu_setup we do not need the latter function to call the former
> function as it will already have been done in time.
>
> Fixes: 1c55d62fb9cc ("riscv: cpu: make riscv_cpu_probe to EVT_DM_POST_INIT_R
> callback")
> Signed-off-by: Tom Rini
Tested-by: Milan P. Stanić
> ---
> Cc: Rick Chen
> Cc: Leo Yu-Chi Liang
> Cc: Simon Glass
> Cc: Nikita Shubin
> Cc: Chanho Park
> Cc: Yu Chien Peter Lin
> ---
> arch/riscv/cpu/cpu.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index cfe9fdc9df55..c1a9638c1ab7 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -94,11 +94,7 @@ static void dummy_pending_ipi_clear(ulong hart, ulong
> arg0, ulong arg1)
>
> int riscv_cpu_setup(void)
> {
> - int ret;
> -
> - ret = riscv_cpu_probe(ctx, event);
> - if (ret)
> - return ret;
> + int __maybe_unused ret;
>
> /* Enable FPU */
> if (supports_extension('d') || supports_extension('f')) {
> --
> 2.34.1
>
Re: [PATCH 1/2] riscv: Rework riscv_cpu_probe for current event macros
On Mon, 2023-09-04 at 15:06, Tom Rini wrote:
> This function should now be a EVENT_SPY_SIMPLE call, update it.
>
> Signed-off-by: Tom Rini
Tested-by: Milan P. Stanić
> ---
> arch/riscv/cpu/cpu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> index d64aa330f206..cfe9fdc9df55 100644
> --- a/arch/riscv/cpu/cpu.c
> +++ b/arch/riscv/cpu/cpu.c
> @@ -66,7 +66,7 @@ static inline bool supports_extension(char ext)
> #endif /* CONFIG_CPU */
> }
>
> -static int riscv_cpu_probe(void *ctx, struct event *event)
> +static int riscv_cpu_probe(void)
> {
> #ifdef CONFIG_CPU
> int ret;
> @@ -79,7 +79,7 @@ static int riscv_cpu_probe(void *ctx, struct event *event)
>
> return 0;
> }
> -EVENT_SPY(EVT_DM_POST_INIT_R, riscv_cpu_probe);
> +EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_R, riscv_cpu_probe);
>
> /*
> * This is called on secondary harts just after the IPI is init'd. Currently
> --
> 2.34.1
>
Re: [RFC PATCH 2/2] binman: j721e: Add firewall configurations for atf
On 9/5/23 3:21 AM, Manorit Chawdhry wrote:
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-j721e-binman.dtsi | 161 ++
1 file changed, 161 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 4f566c21a9af..0569a592597e 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -330,6 +330,73 @@
ti-secure {
content = <>;
keyfile = "custMpk.pem";
+ auth_in_place = <0xa02>;
+
+ // cpu_0_cpu_0_msmc Background
Firewall - 0
I don't have a personal preference, but I see most comments in DTS
are C style /* */.
Also it might be easier to understand if you put the comments right before
the properties that they relate to, i.g.
firewall-0 {
/* cpu_0_cpu_0_msmc */
id = <257>;
region = <0>;
/* Background, Locked */
control = <0x31a>;
permissions = <0xc3>;
start_address = <0x0 0x0>;
end_address = <0xff 0x>;
};
For permissions, I wonder if it would be easier to read if we add
some helper macros:
#define FWPRIVID_ALL 0xc3
#define FWPERM_SECURE_PRIV_WRITE BIT(0)
#define FWPERM_SECURE_PRIV_READ BIT(1)
#define FWPERM_SECURE_PRIV_CACHEABLE BIT(2)
#define FWPERM_SECURE_PRIV_DEBUG BIT(3)
#define FWPERM_SECURE_USER_WRITE BIT(4)
...
Then you would have:
permissions =
;
+ firewall-0 {
+ id = <257>;
+ region = <0>;
+ control = <0x31a>;
+ permissions =
<0xc3>;
+ start_address = <0x0
0x0>;
+ end_address = <0xff
0x>;
+ };
+
+ // cpu_0_cpu_0_msmc Foreground
Firewall
+ firewall-1 {
+ id = <257>;
+ region = <1>;
+ control = <0x1a>;
+ permissions =
<0x0100ff>;
+ start_address = <0x0
0x7000>;
This address might change if one moves ATF, might work to use
CONFIG_K3_ATF_LOAD_ADDR?
Not sure how you would get the end address as we don't really know ATF size..
Andrew
Re: [PATCH v5 05/11] spl: Convert mmc to spl_load
On 9/4/23 08:59, Xavier Drudis Ferran wrote:
> El Sun, Sep 03, 2023 at 08:17:26AM +, Jonas Karlman deia:
>
>> > Fundamentally, we can't really deal with unaligned images without a
>> > bounce-buffer. The method used by SPL_LOAD_FIT_IMAGE_BUFFER_SIZE will
>> > continue working, since we call into the FIT routines to load the image.
>
> Yes
>
>> > I would like to defer bounce buffering for other images until someone
>> > actually needs it.
>> >
>
> Fine.
>
>> > Note that in the FIT case, you can also do `mkimage -EB`, at least if
>> > you aren't using FIT_LOAD_FULL.
>>
>> With the following two commits introduced in v2023.04-rc1, the alignment
>> issue for Rockchip has been fixed and all external data is now accessed
>> block aligned.
>>
>> 9b2fd2d22852 ("binman: Add support for align argument to mkimage tool")
>> 5ad03fc77dfa ("rockchip: Align FIT image data to SD/MMC block length")
>>
>> Regards,
>> Jonas
>>
>
> Well, yes, thanks.
>
> I was carrying Jerome's patch still thinking it was needed for me, but
> I just tried without and it works too, in mmc. In spi I didn't try but
> it should be even easier (bl_len=1).
>
> For me it's still odd to write outside intended memory. Would a warning
> in case legacy image loading writes before load_addr be acceptable ?
> Just in case someone was using the memory there for something else.
We could add something, but it would have to be behind SHOW_ERRORS. This
series is already having a very tough time reducing bloat without adding
any (other) new features.
--Sean
[PULL] u-boot-usb/master
The following changes since commit 8999257f219d1e371c2fd66f255b8782897944d9: Merge tag 'doc-2023-10-rc4-2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-09-02 09:08:54 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git master for you to fetch changes up to 7f4b73fe6939761dd3891b96628efcab47a0570e: usb: dwc3: Fix enabling USB_DR_MODE_HOST (2023-09-04 15:51:38 +0200) Oleksandr Suvorov (2): usb: dwc3: Fix renaming SPL_USB_HOST_SUPPORT to SPL_USB_HOST usb: dwc3: Fix enabling USB_DR_MODE_HOST drivers/usb/dwc3/dwc3-layerscape.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
[PULL] u-boot-usb/next
The following changes since commit f2bb6d9ffd9ba0d0d89c00445a70cf81327a7af2: Merge tag 'doc-next' of https://source.denx.de/u-boot/custodians/u-boot-efi into next (2023-09-02 09:08:34 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git next for you to fetch changes up to adee3ba577a6d5902b5af6c2368faf5f509003c6: usb: host: ohci-generic: Make usage of clock/reset bulk() API (2023-09-04 18:25:20 +0200) Fabrice Gasnier (2): usb: check for companion controller in uclass usb: host: ohci-generic: Make usage of clock/reset bulk() API drivers/usb/host/ohci-generic.c | 92 + drivers/usb/host/usb-uclass.c | 36 2 files changed, 65 insertions(+), 63 deletions(-)
[PULL] u-boot-sh/next
The following changes since commit b53ab97150314674edc25508f4fc528be2baa73f: event.h: Documented some newly added portions better (2023-09-04 11:19:50 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sh.git next for you to fetch changes up to 733fab7177ea3c0402bab9db07422d5dce495139: ARM: rmobile: Clean up rmobile_cpuinfo_idx() (2023-09-05 01:13:35 +0200) Marek Vasut (1): ARM: rmobile: Clean up rmobile_cpuinfo_idx() arch/arm/mach-rmobile/cpu_info.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-)
[PATCH 2/2] event: Rename rest of EVENT_SPY to EVENT_SPY_FULL or EVENT_SPY*
Fix up remaining occurances of EVENT_SPY with no suffix.
Fixes: 6c4cad7438 ("event: Rename EVENT_SPY to EVENT_SPY_FULL")
Signed-off-by: Marek Vasut
---
Cc: Chanho Park
Cc: Leo
Cc: Nikita Shubin
Cc: Padmarao Begari
Cc: Rick Chen
Cc: Simon Glass
Cc: Yu Chien Peter Lin
---
common/Kconfig | 4 ++--
include/event.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/Kconfig b/common/Kconfig
index d916194b942..bdc02f75620 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -620,7 +620,7 @@ config EVENT_DYNAMIC
bool
help
Enable this to support adding an event spy at runtime, without adding
- it to the EVENT_SPY() linker list. This increases code size slightly
+ it to the EVENT_SPY*() linker list. This increases code size slightly
but provides more flexibility for boards and subsystems that need it.
config EVENT_DEBUG
@@ -648,7 +648,7 @@ config SPL_EVENT_DYNAMIC
depends on SPL_EVENT && EVENT_DYNAMIC
help
Enable this to support adding an event spy at runtime, without adding
- it to the EVENT_SPY() linker list. This increases code size slightly
+ it to the EVENT_SPY*() linker list. This increases code size slightly
but provides more flexibility for boards and subsystems that need it.
endif # EVENT
diff --git a/include/event.h b/include/event.h
index 311df878c4a..5fffde960d0 100644
--- a/include/event.h
+++ b/include/event.h
@@ -282,9 +282,9 @@ static inline const char *event_spy_id(struct evspy_info
*spy)
* {
*return sandbox_early_getopt_check();
* }
- * EVENT_SPY(EVT_MISC_INIT_F, sandbox_misc_init_f);
+ * EVENT_SPY_FULL(EVT_MISC_INIT_F, sandbox_misc_init_f);
*
- * where EVENT_SPY uses ll_entry_declare()
+ * where EVENT_SPY_FULL uses ll_entry_declare()
*
* In this case, LTO decides to drop the sandbox_misc_init_f() function
* (which is fine) but then drops the linker-list entry too. This means
--
2.40.1
[PATCH 1/2] riscv: cpu: Rename EVENT_SPY to EVENT_SPY_SIMPLE
Fix up cpu.c and align it with commit
6c4cad7438 ("event: Rename EVENT_SPY to EVENT_SPY_FULL")
Signed-off-by: Marek Vasut
---
Cc: Chanho Park
Cc: Leo
Cc: Nikita Shubin
Cc: Padmarao Begari
Cc: Rick Chen
Cc: Simon Glass
Cc: Yu Chien Peter Lin
---
arch/riscv/cpu/cpu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index d64aa330f20..15beec29875 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -66,7 +66,7 @@ static inline bool supports_extension(char ext)
#endif /* CONFIG_CPU */
}
-static int riscv_cpu_probe(void *ctx, struct event *event)
+static int riscv_cpu_probe(void)
{
#ifdef CONFIG_CPU
int ret;
@@ -79,7 +79,7 @@ static int riscv_cpu_probe(void *ctx, struct event *event)
return 0;
}
-EVENT_SPY(EVT_DM_POST_INIT_R, riscv_cpu_probe);
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_R, riscv_cpu_probe);
/*
* This is called on secondary harts just after the IPI is init'd. Currently
@@ -96,7 +96,7 @@ int riscv_cpu_setup(void)
{
int ret;
- ret = riscv_cpu_probe(ctx, event);
+ ret = riscv_cpu_probe();
if (ret)
return ret;
--
2.40.1
Re: [PATCH v4 6/6] board: ti: j721s2: MAINTAINERS: Update the MAINTAINERS File.
On 16:08-20230904, Manorit Chawdhry wrote: > Update the MAINTAINERS file and propose a new MAINTAINER for j721s2 due > to the previous MAINTAINER not being associated with TI. > > Signed-off-by: Manorit Chawdhry > --- > board/ti/j721s2/MAINTAINERS | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > For whatever it is worth: Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v4 5/6] docs: board: ti: Add j721s2_evm documentation
On 16:08-20230904, Manorit Chawdhry wrote: > Add the documentation for J721S2-EVM and SK-AM68 > > TRM for J721S2/AM68: https://www.ti.com/lit/pdf/spruj28 > Product Page for J721S2: https://www.ti.com/tool/J721S2XSOMXEVM > Product Page for AM68: https://www.ti.com/tool/SK-AM68 > > Reviewed-by: Neha Malcom Francis > Signed-off-by: Manorit Chawdhry > --- Reviewed-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
[[PATCH v2]] riscv: add backtrace support
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.
Signed-off-by: Ben Dooks
---
v2:
- back to codethink email as sifive account is now gone
- add option to build SPL with frame pointer
(as suggested by Bo Gan
---
arch/riscv/Kconfig | 20
arch/riscv/Makefile | 4
arch/riscv/cpu/start.S | 1 +
arch/riscv/lib/interrupts.c | 35 +++
4 files changed, 60 insertions(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 6771d8d919..a446166631 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -111,6 +111,26 @@ config ARCH_RV64I
endchoice
+config FRAMEPOINTER
+ bool "Build with frame pointer for stack unwinding"
+ help
+ Choose this option to use the frame pointer so the stack can be
+ unwound if needed. This is useful for tracing where faults came
+ from as the source may be several functions back
+
+ If you say Y here, then the code size will be increased due to
+ having to store the fp.
+
+config SPL_FRAMEPOINTER
+ bool "Build SPL with frame pointer for stack unwinding"
+ help
+ Choose this option to use the frame pointer so the stack can be
+ unwound if needed. This is useful for tracing where faults came
+ from as the source may be several functions back
+
+ If you say Y here, then the code size will be increased due to
+ having to store the fp.
+
choice
prompt "Code Model"
default CMODEL_MEDLOW
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 4963b5109b..0cb60c7c7e 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -45,6 +45,10 @@ endif
ARCH_FLAGS = -march=$(RISCV_MARCH) -mabi=$(ABI) \
-mcmodel=$(CMODEL)
+ifeq ($(CONFIG_$(SPL_)FRAMEPOINTER),y)
+ ARCH_FLAGS += -fno-omit-frame-pointer
+endif
+
PLATFORM_CPPFLAGS += $(ARCH_FLAGS)
CFLAGS_EFI += $(ARCH_FLAGS)
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 30cf674370..53de424378 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -419,6 +419,7 @@ call_board_init_r:
*/
mv a0, s3 /* gd_t */
mv a1, s4 /* dest_addr */
+ mv s0, zero/* fp == NULL */
/*
* jump to it ...
diff --git a/arch/riscv/lib/interrupts.c b/arch/riscv/lib/interrupts.c
index e966afa7e3..db3d7e294b 100644
--- a/arch/riscv/lib/interrupts.c
+++ b/arch/riscv/lib/interrupts.c
@@ -53,6 +53,40 @@ static void show_regs(struct pt_regs *regs)
#endif
}
+#if defined(CONFIG_FRAMEPOINTER) || defined(CONFIG_SPL_FRAMEPOINTER)
+static void show_backtrace(struct pt_regs *regs)
+{
+ uintptr_t *fp = (uintptr_t *)regs->s0;
+ unsigned count = 0;
+ ulong ra;
+
+ printf("backtrace:\n");
+
+ /* there are a few entry points where the s0 register is
+* set to gd, so to avoid changing those, just abort if
+* the value is the same */
+ while (fp != NULL && fp != (uintptr_t *)gd) {
+ ra = fp[-1];
+ printf("backtrace %2d: FP: " REG_FMT " RA: " REG_FMT,
+ count, (ulong)fp, ra);
+
+ if (gd && gd->flags & GD_FLG_RELOC)
+ printf(" - RA: " REG_FMT " reloc adjusted\n",
+ ra - gd->reloc_off);
+ else
+ printf("\n");
+
+ fp = (uintptr_t *)fp[-2];
+ count++;
+ }
+}
+#else
+static void show_backtrace(struct pt_regs *regs)
+{
+ printf("No backtrace support enabled\n");
+}
+#endif
+
/**
* instr_len() - get instruction length
*
@@ -119,6 +153,7 @@ static void _exit_trap(ulong code, ulong epc, ulong tval,
struct pt_regs *regs)
epc - gd->reloc_off, regs->ra - gd->reloc_off);
show_regs(regs);
+ show_backtrace(regs);
show_code(epc);
show_efi_loaded_images(epc);
panic("\n");
--
2.40.1
[PATCH v2 1/2] arm: dts: rockchip: sync DT for RK3588 series with Linux
Sync the device tree for RK3588 series with Linux 6.6-rc1.
Signed-off-by: FUKAUMI Naoki
---
.../dts/rk3588-edgeble-neu6a-io-u-boot.dtsi | 1 -
arch/arm/dts/rk3588-edgeble-neu6a.dtsi| 1 -
.../dts/rk3588-edgeble-neu6b-io-u-boot.dtsi | 6 -
arch/arm/dts/rk3588-edgeble-neu6b-io.dts | 66 ++
arch/arm/dts/rk3588-edgeble-neu6b.dtsi| 359 -
arch/arm/dts/rk3588-evb1-v10.dts | 720 +-
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 113 +--
arch/arm/dts/rk3588-rock-5b.dts | 448 ++-
arch/arm/dts/rk3588.dtsi | 215 ++
arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi | 12 -
arch/arm/dts/rk3588s-rock-5a.dts | 665 +++-
arch/arm/dts/rk3588s-u-boot.dtsi | 162
arch/arm/dts/rk3588s.dtsi | 367 +
include/dt-bindings/ata/ahci.h| 20 +
14 files changed, 2866 insertions(+), 289 deletions(-)
create mode 100644 include/dt-bindings/ata/ahci.h
diff --git a/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
index 373f369c65..dd0058262b 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6a-io-u-boot.dtsi
@@ -11,7 +11,6 @@
};
chosen {
- stdout-path =
u-boot,spl-boot-order =
};
};
diff --git a/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
index 38e1a1e25f..727580aaa1 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6a.dtsi
@@ -25,7 +25,6 @@
no-sdio;
no-sd;
non-removable;
- max-frequency = <2>;
mmc-hs400-1_8v;
mmc-hs400-enhanced-strobe;
status = "okay";
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
index cd7626b24b..a45b3f5e86 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6b-io-u-boot.dtsi
@@ -11,12 +11,6 @@
};
chosen {
- stdout-path =
u-boot,spl-boot-order =
};
};
-
- {
- bus-width = <4>;
- status = "okay";
-};
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
b/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
index e9d5a8bab5..9933765e40 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
+++ b/arch/arm/dts/rk3588-edgeble-neu6b-io.dts
@@ -21,7 +21,73 @@
};
};
+_ps {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ hym8563: rtc@51 {
+ compatible = "haoyu,hym8563";
+ reg = <0x51>;
+ interrupt-parent = <>;
+ interrupts = ;
+ #clock-cells = <0>;
+ clock-output-names = "hym8563";
+ pinctrl-names = "default";
+ pinctrl-0 = <_int>;
+ wakeup-source;
+ };
+};
+
+ {
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO _pull_none>;
+ };
+ };
+};
+
+/* FAN */
+ {
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ disable-wp;
+ no-sdio;
+ no-mmc;
+ sd-uhs-sdr104;
+ vmmc-supply = <_3v3_s3>;
+ vqmmc-supply = <_sd_s0>;
+ status = "okay";
+};
+
{
pinctrl-0 = <_xfer>;
status = "okay";
};
+
+/* RS232 */
+ {
+ pinctrl-0 = <_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* RS485 */
+ {
+ pinctrl-0 = <_xfer>;
+ pinctrl-names = "default";
+ status = "okay";
+};
diff --git a/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
b/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
index 1c5bcf1280..017559bba3 100644
--- a/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
+++ b/arch/arm/dts/rk3588-edgeble-neu6b.dtsi
@@ -18,6 +18,42 @@
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <_dcin>;
+ };
+
+ vcc_1v1_nldo_s3: vcc-1v1-nldo-s3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v1_nldo_s3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <110>;
+ regulator-max-microvolt = <110>;
+ vin-supply = <_sys>;
+ };
+};
+
[PATCH v2 2/2] arm: dts: rockchip: rock-5b: add support for PCIe3 and NVMe
this patch adds support for PCIe3 (M.2 M key) and enables NVMe.
=> pci
BusDevFun VendorId DeviceId Device Class Sub-Class
_
00.00.00 0x1d87 0x3588 Bridge device 0x04
01.00.00 0x10ec 0x8125 Network controller 0x00
02.00.00 0x1d87 0x3588 Bridge device 0x04
03.00.00 0x1179 0x011a Mass storage controller 0x08
=> nvme scan
=> nvme info
Device 0: Vendor: 0x1179 Rev: AGHA4101 Prod: 79CA20WPKRYN
Type: Hard Disk
Capacity: 488386.3 MB = 476.9 GB (1000215216 x 512)
Signed-off-by: FUKAUMI Naoki
this patch depends:
- "rockchip: rk3568: Fix use of PCIe bifurcation" [1]
[1] https://patchwork.ozlabs.org/project/uboot/list/?series=366997
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 33 +
configs/rock5b-rk3588_defconfig | 1 +
2 files changed, 34 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 03626e71ea..96cc84e5aa 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -23,6 +23,19 @@
regulator-max-microvolt = <1200>;
};
+ vcc3v3_pcie30: vcc3v3-pcie30-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_pcie30";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ enable-active-high;
+ gpios = < RK_PA4 GPIO_ACTIVE_HIGH>;
+ startup-delay-us = <5000>;
+ vin-supply = <_sys>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_vcc3v3_en>;
+ };
+
vcc5v0_usbdcin: vcc5v0-usbdcin {
compatible = "regulator-fixed";
regulator-name = "vcc5v0_usbdcin";
@@ -71,6 +84,18 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ reset-gpios = < RK_PB6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <_pcie30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_rst>;
+ status = "okay";
+};
+
{
pcie {
pcie_reset_h: pcie-reset-h {
@@ -81,6 +106,14 @@
rockchip,pins = <3 RK_PC7 4 _pull_none>,
<3 RK_PD0 4 _pull_none>;
};
+
+ pcie3_rst: pcie3-rst {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO _pull_none>;
+ };
+
+ pcie3_vcc3v3_en: pcie3-vcc3v3-en {
+ rockchip,pins = <1 RK_PA4 RK_FUNC_GPIO _pull_none>;
+ };
};
usb-typec {
diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 3fa65cbf9b..50551c70f2 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -81,6 +81,7 @@ CONFIG_SPI_FLASH_XTX=y
CONFIG_ETH_DESIGNWARE=y
CONFIG_RTL8169=y
CONFIG_GMAC_ROCKCHIP=y
+CONFIG_NVME_PCI=y
CONFIG_PCIE_DW_ROCKCHIP=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
--
2.39.2
Re: [PATCH v2] dm: core: support reading a single indexed u64 value
On 8/25/23 11:37, Michal Simek wrote:
Add helper function to allow reading a single indexed u64 value from a
device-tree property containing multiple u64 values, that is an array of
u64's.
Co-developed-by: Ashok Reddy Soma
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
Changes in v2:
- fix kernel-doc for of_read_u64_index()
- add missing test reported by Simon
- fix debug print to print 64bit value
- convert of_read_u64 to use of_read_u64_index() as is done also for u32 version
- fix overflow size calculation
Tested on sandbox:
make defconfig && make -j8 && ./u-boot --fdt arch/sandbox/dts/test.dtb --command "ut
dm ofnode_u64" -v
Test: dm_test_ofnode_u64: ofnode.c
Test: dm_test_ofnode_u64: ofnode.c (flat tree)
Failures: 0
Based on v2023.07 tag.
---
arch/sandbox/dts/test.dts | 1 +
drivers/core/of_access.c | 16
drivers/core/ofnode.c | 30 ++
include/dm/of_access.h| 19 +++
include/dm/ofnode.h | 12
test/dm/ofnode.c | 8
6 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index ff9f9222e6f9..a3c12bb09874 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -288,6 +288,7 @@
uint-value = <(-1234)>;
int64-value = /bits/ 64 <0x>;
int-array = <5678 9123 4567>;
+ int64-array = /bits/ 64 <0x 0x>;
str-value = "test string";
interrupts-extended = < 3 0>;
acpi,name = "GHIJ";
diff --git a/drivers/core/of_access.c b/drivers/core/of_access.c
index 81a307992c01..1d5348bf2f50 100644
--- a/drivers/core/of_access.c
+++ b/drivers/core/of_access.c
@@ -570,26 +570,34 @@ int of_read_u32_index(const struct device_node *np, const
char *propname,
return 0;
}
-int of_read_u64(const struct device_node *np, const char *propname, u64 *outp)
+int of_read_u64_index(const struct device_node *np, const char *propname,
+ int index, u64 *outp)
{
const __be64 *val;
debug("%s: %s: ", __func__, propname);
if (!np)
return -EINVAL;
- val = of_find_property_value_of_size(np, propname, sizeof(*outp));
+
+ val = of_find_property_value_of_size(np, propname,
+sizeof(*outp) * (index + 1));
if (IS_ERR(val)) {
debug("(not found)\n");
return PTR_ERR(val);
}
- *outp = be64_to_cpup(val);
+ *outp = be64_to_cpup(val + index);
debug("%#llx (%lld)\n", (unsigned long long)*outp,
- (unsigned long long)*outp);
+ (unsigned long long)*outp);
return 0;
}
+int of_read_u64(const struct device_node *np, const char *propname, u64 *outp)
+{
+ return of_read_u64_index(np, propname, 0, outp);
+}
+
int of_property_match_string(const struct device_node *np, const char
*propname,
const char *string)
{
diff --git a/drivers/core/ofnode.c b/drivers/core/ofnode.c
index ec574c446079..e973c74af4cf 100644
--- a/drivers/core/ofnode.c
+++ b/drivers/core/ofnode.c
@@ -319,6 +319,36 @@ int ofnode_read_u32_index(ofnode node, const char
*propname, int index,
return 0;
}
+int ofnode_read_u64_index(ofnode node, const char *propname, int index,
+ u64 *outp)
+{
+ const fdt64_t *cell;
+ int len;
+
+ assert(ofnode_valid(node));
+
+ if (ofnode_is_np(node))
+ return of_read_u64_index(ofnode_to_np(node), propname, index,
+outp);
+
+ cell = fdt_getprop(ofnode_to_fdt(node), ofnode_to_offset(node),
+ propname, );
+ if (!cell) {
+ debug("(not found)\n");
+ return -EINVAL;
+ }
+
+ if (len < (sizeof(u64) * (index + 1))) {
+ debug("(not large enough)\n");
+ return -EOVERFLOW;
+ }
+
+ *outp = fdt64_to_cpu(cell[index]);
+ debug("%#llx (%lld)\n", *outp, *outp);
+
+ return 0;
+}
+
u32 ofnode_read_u32_index_default(ofnode node, const char *propname, int
index,
u32 def)
{
diff --git a/include/dm/of_access.h b/include/dm/of_access.h
index c556a18f7d9c..9361d0a87bfb 100644
--- a/include/dm/of_access.h
+++ b/include/dm/of_access.h
@@ -333,6 +333,25 @@ int of_read_u32(const struct device_node *np, const char
*propname, u32 *outp);
int of_read_u32_index(const struct device_node *np, const char *propname,
int index, u32 *outp);
+/**
+ * of_read_u64_index() - Find and read a 64-bit value from a multi-value
+ * property
+ *
+ * @np:device node from which the property value is to be read.
+ * @propname: name of the
[PATCH] arm64: xilinx: Guard distro boot variable generation
When distro boot is disabled there is no reason to generate variables for
it. Also do not update boot_targets variable because it would be unused.
It is useful for example when standard boot is enabled and distro boot
is disabled.
Signed-off-by: Michal Simek
---
board/xilinx/versal-net/board.c | 32 -
board/xilinx/versal/board.c | 31 +++-
board/xilinx/zynqmp/zynqmp.c| 56 +
include/configs/xilinx_versal.h | 6
include/configs/xilinx_versal_net.h | 6
include/configs/xilinx_zynqmp.h | 6
6 files changed, 97 insertions(+), 40 deletions(-)
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index 7ad299f3a231..c18be0c26c99 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -194,7 +194,7 @@ static u8 versal_net_get_bootmode(void)
return bootmode;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -205,14 +205,6 @@ int board_late_init(void)
char *new_targets;
char *env_targets;
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
bootmode = versal_net_get_bootmode();
puts("Bootmode: ");
@@ -320,6 +312,28 @@ int board_late_init(void)
env_set("boot_targets", new_targets);
}
+
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret;
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
+ debug("Saved variables - Skipping\n");
+ return 0;
+ }
+
+ if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
+ return 0;
+
+ if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
+ ret = boot_targets_setup();
+ if (ret)
+ return ret;
+ }
+
return board_late_init_xilinx();
}
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 982a8b3779f1..e4bdd5d7a38b 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -126,7 +126,7 @@ static u8 versal_get_bootmode(void)
return bootmode;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -137,14 +137,6 @@ int board_late_init(void)
char *new_targets;
char *env_targets;
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
bootmode = versal_get_bootmode();
puts("Bootmode: ");
@@ -247,6 +239,27 @@ int board_late_init(void)
env_set("boot_targets", new_targets);
}
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret;
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
+ debug("Saved variables - Skipping\n");
+ return 0;
+ }
+
+ if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
+ return 0;
+
+ if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
+ ret = boot_targets_setup();
+ if (ret)
+ return ret;
+ }
+
return board_late_init_xilinx();
}
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 0b6d4e57078b..f16280308483 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -384,7 +384,7 @@ static int set_fdtfile(void)
return 0;
}
-int board_late_init(void)
+static int boot_targets_setup(void)
{
u8 bootmode;
struct udevice *dev;
@@ -394,27 +394,6 @@ int board_late_init(void)
const char *mode = NULL;
char *new_targets;
char *env_targets;
- int ret, multiboot;
-
-#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
- usb_ether_init();
-#endif
-
- if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
- debug("Saved variables - Skipping\n");
- return 0;
- }
-
- if (!IS_ENABLED(CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG))
- return 0;
-
- ret = set_fdtfile();
- if (ret)
- return ret;
-
- multiboot = multi_boot();
- if (multiboot >= 0)
- env_set_hex("multiboot", multiboot);
bootmode = zynqmp_get_bootmode();
@@ -525,6 +504,39 @@ int board_late_init(void)
free(new_targets);
}
+ return 0;
+}
+
+int board_late_init(void)
+{
+ int ret, multiboot;
+
+#if defined(CONFIG_USB_ETHER) && !defined(CONFIG_USB_GADGET_DOWNLOAD)
+ usb_ether_init();
+#endif
+
+ if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
+ debug("Saved
[PATCH] riscv: enable multi-range memory layout
In order to enable PCIe passthrough on qemu riscv, the physical memory
range between 3GB and 4GB is reserved. Therefore if guest has 4GB ram,
two ranges are created as [2G, 3G) and [4G, 7G), currently u-boot sets
ram_top to 4G - 1 if the gd->ram_top is above 4G in
board_get_usable_ram_top(), but that address is not backed by ram. This
patch selects the lowest range instead.
Signed-off-by: Fei Wu
---
arch/riscv/cpu/generic/dram.c| 2 +-
configs/qemu-riscv64_smode_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/cpu/generic/dram.c b/arch/riscv/cpu/generic/dram.c
index 44e11bd56c..fb53a57b4e 100644
--- a/arch/riscv/cpu/generic/dram.c
+++ b/arch/riscv/cpu/generic/dram.c
@@ -13,7 +13,7 @@ DECLARE_GLOBAL_DATA_PTR;
int dram_init(void)
{
- return fdtdec_setup_mem_size_base();
+ return fdtdec_setup_mem_size_base_lowest();
}
int dram_init_banksize(void)
diff --git a/configs/qemu-riscv64_smode_defconfig
b/configs/qemu-riscv64_smode_defconfig
index 1d0f021ade..de08a49dab 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -1,6 +1,6 @@
CONFIG_RISCV=y
CONFIG_SYS_MALLOC_LEN=0x80
-CONFIG_NR_DRAM_BANKS=1
+CONFIG_NR_DRAM_BANKS=2
CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8020
CONFIG_ENV_SIZE=0x2
--
2.34.1
Re: [PATCH 1/3] xilinx: versal-net: Do not setup boot_targets if driver is not enabled
On 9/4/23 16:43, Simon Glass wrote: Hi Venkatesh, On Mon, 4 Sept 2023 at 07:58, Venkatesh Yadav Abbarapu wrote: SOC can boot in the device which is not accessible from APU and running this is detected as error which ends up in stopping boot process. Boot mode detection and logic around is present to setup priority on boot devices that SOC boot device is likely also used for booting OS. Change logic to detect this case with showing message about it but don't fail in boot process and don't prioritize boot device in this case. Signed-off-by: Michal Simek Signed-off-by: Venkatesh Yadav Abbarapu --- board/xilinx/versal-net/board.c | 76 - 1 file changed, 38 insertions(+), 38 deletions(-) If you switch to standard boot it won't try to boot on devices which don't exist. Actually I was looking at standard boot yesterday. We have enabled standard boot already but not BOOTSTD_FULL because there is a dependency on having video enabled. Actually this dependency should be covered in Kconfig too. I don't think this is an issue with this series which is trying to address issue properly. But let me send a patch to guard this code only when CONFIG_DISTRO_DEFAULTS is enabled. And also that huge amount of variables don't need to be created too in this case. Thanks, Michal
Re: [PATCH 1/2] riscv: Rework riscv_cpu_probe for current event macros
Hi Heinrich,
On Tue, Sep 05, 2023 at 10:58:31AM +0200, Heinrich Schuchardt wrote:
> On 05.09.23 05:01, Leo Liang wrote:
> > Hi Tom,
> >
> > On Mon, Sep 04, 2023 at 03:06:34PM -0400, Tom Rini wrote:
> > > This function should now be a EVENT_SPY_SIMPLE call, update it.
> > >
> > > Signed-off-by: Tom Rini
> > > ---
> > > arch/riscv/cpu/cpu.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
> > > index d64aa330f206..cfe9fdc9df55 100644
> > > --- a/arch/riscv/cpu/cpu.c
> > > +++ b/arch/riscv/cpu/cpu.c
> > > @@ -66,7 +66,7 @@ static inline bool supports_extension(char ext)
> > > #endif /* CONFIG_CPU */
> > > }
> > > -static int riscv_cpu_probe(void *ctx, struct event *event)
> > > +static int riscv_cpu_probe(void)
> > > {
> > > #ifdef CONFIG_CPU
> > > int ret;
> > > @@ -79,7 +79,7 @@ static int riscv_cpu_probe(void *ctx, struct event
> > > *event)
> > > return 0;
> > > }
> > > -EVENT_SPY(EVT_DM_POST_INIT_R, riscv_cpu_probe);
> > > +EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_R, riscv_cpu_probe);
> >
> > I cannot seem to find macro "EVENT_SPY_SIMPLE".
> > Is there anything that should be added?
> > Or did I miss anything?
>
> This patch is only applicable to origin/next. The definition there is in
> include/event.h:311.
>
Thanks for the pointer!
Best regards,
Leo
> Reviewed-by: Heinrich Schuchardt
>
Re: [PATCH 1/2] riscv: Rework riscv_cpu_probe for current event macros
On 05.09.23 05:01, Leo Liang wrote:
Hi Tom,
On Mon, Sep 04, 2023 at 03:06:34PM -0400, Tom Rini wrote:
This function should now be a EVENT_SPY_SIMPLE call, update it.
Signed-off-by: Tom Rini
---
arch/riscv/cpu/cpu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/cpu/cpu.c b/arch/riscv/cpu/cpu.c
index d64aa330f206..cfe9fdc9df55 100644
--- a/arch/riscv/cpu/cpu.c
+++ b/arch/riscv/cpu/cpu.c
@@ -66,7 +66,7 @@ static inline bool supports_extension(char ext)
#endif /* CONFIG_CPU */
}
-static int riscv_cpu_probe(void *ctx, struct event *event)
+static int riscv_cpu_probe(void)
{
#ifdef CONFIG_CPU
int ret;
@@ -79,7 +79,7 @@ static int riscv_cpu_probe(void *ctx, struct event *event)
return 0;
}
-EVENT_SPY(EVT_DM_POST_INIT_R, riscv_cpu_probe);
+EVENT_SPY_SIMPLE(EVT_DM_POST_INIT_R, riscv_cpu_probe);
I cannot seem to find macro "EVENT_SPY_SIMPLE".
Is there anything that should be added?
Or did I miss anything?
This patch is only applicable to origin/next. The definition there is in
include/event.h:311.
Reviewed-by: Heinrich Schuchardt
Re: [PATCH] sunxi: board: provide CPU idle states to loaded OS
Hi Andrey, On 23-09-05 09:27, Andre Przywara wrote: > On Mon, 4 Sep 2023 23:54:30 +0300 > Andrey Skvortsov wrote: > > Hi Andrey, > > > When using SCPI as the PSCI backend, firmware can wake up the CPUs and > > cluster from sleep, so CPU idle states are available for loaded OS to > > use. TF-A modifies DTB to advertise available CPU idle states, when > > SCPI is detected. This change copies nodes added by TF-A to any new > > dtb that is used for loaded OS. > > Why do you need that, exactly? Why not just use $fdtcontroladdr for the > kernel? We now keep the U-Boot copy of the .dts files in sync with the > kernel. If you need to modify the DT in U-Boot, for instance by applying > overlays, you can copy that DTB into a better suitable location first: > => fdt move $fdtcontroladdr $fdt_addr_r > > In any case, there shall be only one DT, that one in the U-Boot image. Why > do you need to load another one for the kernel? extlinux is used by distributions (sometimes with device-specific changes especially for platforms not fully supported by mainline yet), then U-Boot loads DT defined in extlinux.conf file. u-boot scripts are not used in case of extlinux at all. -- Best regards, Andrey Skvortsov
Re: [PATCH] sunxi: board: provide CPU idle states to loaded OS
On Mon, 4 Sep 2023 23:54:30 +0300
Andrey Skvortsov wrote:
Hi Andrey,
> When using SCPI as the PSCI backend, firmware can wake up the CPUs and
> cluster from sleep, so CPU idle states are available for loaded OS to
> use. TF-A modifies DTB to advertise available CPU idle states, when
> SCPI is detected. This change copies nodes added by TF-A to any new
> dtb that is used for loaded OS.
Why do you need that, exactly? Why not just use $fdtcontroladdr for the
kernel? We now keep the U-Boot copy of the .dts files in sync with the
kernel. If you need to modify the DT in U-Boot, for instance by applying
overlays, you can copy that DTB into a better suitable location first:
=> fdt move $fdtcontroladdr $fdt_addr_r
In any case, there shall be only one DT, that one in the U-Boot image. Why
do you need to load another one for the kernel?
Cheers,
Andre
> Signed-off-by: Andrey Skvortsov
> ---
> board/sunxi/board.c | 120
> 1 file changed, 120 insertions(+)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index f321cd58a6..e88bd11a99 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -870,6 +870,125 @@ int board_late_init(void)
> return 0;
> }
>
> +static int cpuidle_dt_fixup_copy_node(ofnode src, int dst_offset, void
> *dst_blob,
> + u32 *count, u32 *phandle)
> +{
> + int offs, len, ret;
> + struct ofprop prop;
> + ofnode subnode;
> +
> + ofnode_for_each_prop(prop, src) {
> + const char *name;
> + const char *val;
> +
> + val = ofprop_get_property(, , );
> + if (!val)
> + return -EINVAL;
> + if (!strcmp(name, "phandle")) {
> + if (ofnode_device_is_compatible(src, "arm,idle-state"))
> {
> + fdt_setprop_u32(dst_blob, dst_offset, name,
> *phandle);
> + (*phandle)++;
> + (*count)++;
> + } else {
> + log_err("Unexpected phandle node: %s\n", name);
> + return -EINVAL;
> + }
> + } else {
> + ret = fdt_setprop(dst_blob, dst_offset, name, val, len);
> + if (ret < 0)
> + return ret;
> + }
> + }
> +
> + ofnode_for_each_subnode(subnode, src) {
> + const char *name = ofnode_get_name(subnode);
> +
> + if (!name)
> + return -EINVAL;
> + offs = fdt_add_subnode(dst_blob, dst_offset, name);
> + if (offs < 0)
> + return offs;
> + ret = cpuidle_dt_fixup_copy_node(subnode, offs, dst_blob,
> count, phandle);
> + if (ret < 0)
> + return ret;
> + }
> + return 0;
> +}
> +
> +static int cpuidle_dt_fixup(void *blob)
> +{
> + ofnode idle_states_node;
> + ofnode subnode;
> + u32 count, phandle;
> + const struct property *prop;
> + int offs, len, ret;
> +
> + idle_states_node = ofnode_path("/cpus/idle-states");
> + if (!ofnode_valid(idle_states_node)) {
> + log_err("No idle-states node in old fdt, nothing to do");
> + return 0;
> + }
> +
> + /*
> + * Do not proceed if the target dt already has an idle-states node.
> + * In this case assume that the system knows better somehow,
> + * so do not interfere.
> + */
> + if (fdt_path_offset(blob, "/cpus/idle-states") >= 0) {
> + log_err("idle-states node already exists in target");
> + return 0;
> + }
> +
> + offs = fdt_path_offset(blob, "/cpus");
> + if (offs < 0)
> + return offs;
> +
> + offs = fdt_add_subnode(blob, offs, "idle-states");
> + if (offs < 0)
> + return offs;
> +
> + /* copy "/cpus/idle-states" node to destination fdt */
> + ret = fdt_find_max_phandle(blob, );
> + if (ret < 0)
> + return ret;
> + phandle++;
> + count = 0;
> + ret = cpuidle_dt_fixup_copy_node(idle_states_node, offs, blob, ,
> );
> + if (ret < 0)
> + return ret;
> +
> + /* copy "cpu-idle-state" property for all cpus */
> + ofnode_for_each_subnode(subnode, ofnode_path("/cpus")) {
> + char path[32];
> + fdt32_t *value;
> +
> + prop = ofnode_get_property(subnode, "cpu-idle-states", );
> + if (!prop)
> + continue;
> +
> + /* find the same node in a new device-tree */
> + ret = ofnode_get_path(subnode, path, sizeof(path));
> + if (ret)
> + return ret;
> +
> + offs = fdt_path_offset(blob, path);
> + if (offs < 0)
> + return offs;
> +
> + /* Allocate space for the list of phandles. */
> +
[PATCH] arm64: versal: Do not define boot command for mini configurations
Mini configuration is not design to boot anything that's why there is no reason to setup boot command. CONFIG_DISTRO_DEFAULTS is disabled anyway. Signed-off-by: Michal Simek --- configs/xilinx_versal_mini_defconfig | 2 -- configs/xilinx_versal_mini_emmc0_defconfig | 2 -- configs/xilinx_versal_mini_emmc1_defconfig | 2 -- 3 files changed, 6 deletions(-) diff --git a/configs/xilinx_versal_mini_defconfig b/configs/xilinx_versal_mini_defconfig index 53376db9df30..78be2002fb8a 100644 --- a/configs/xilinx_versal_mini_defconfig +++ b/configs/xilinx_versal_mini_defconfig @@ -21,8 +21,6 @@ CONFIG_SYS_MEMTEST_END=0x1000 CONFIG_REMAKE_ELF=y # CONFIG_LEGACY_IMAGE_FORMAT is not set # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y diff --git a/configs/xilinx_versal_mini_emmc0_defconfig b/configs/xilinx_versal_mini_emmc0_defconfig index 31b3c02f7389..129ddce3ef06 100644 --- a/configs/xilinx_versal_mini_emmc0_defconfig +++ b/configs/xilinx_versal_mini_emmc0_defconfig @@ -17,8 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800 # CONFIG_EXPERT is not set CONFIG_REMAKE_ELF=y # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y diff --git a/configs/xilinx_versal_mini_emmc1_defconfig b/configs/xilinx_versal_mini_emmc1_defconfig index 5480cf1d9cc4..116ec450bda8 100644 --- a/configs/xilinx_versal_mini_emmc1_defconfig +++ b/configs/xilinx_versal_mini_emmc1_defconfig @@ -17,8 +17,6 @@ CONFIG_SYS_LOAD_ADDR=0x800 # CONFIG_EXPERT is not set CONFIG_REMAKE_ELF=y # CONFIG_AUTOBOOT is not set -CONFIG_USE_BOOTCOMMAND=y -CONFIG_BOOTCOMMAND="run distro_bootcmd" CONFIG_SYS_CONSOLE_INFO_QUIET=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_BOARD_EARLY_INIT_R=y -- 2.36.1
[RFC PATCH 2/2] binman: j721e: Add firewall configurations for atf
The following commits adds the configuration of firewalls required to
protect ATF and OP-TEE memory region from non-secure reads and
writes using master and slave firewalls present in our K3 SOCs.
Signed-off-by: Manorit Chawdhry
---
arch/arm/dts/k3-j721e-binman.dtsi | 161 ++
1 file changed, 161 insertions(+)
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
index 4f566c21a9af..0569a592597e 100644
--- a/arch/arm/dts/k3-j721e-binman.dtsi
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -330,6 +330,73 @@
ti-secure {
content = <>;
keyfile = "custMpk.pem";
+ auth_in_place = <0xa02>;
+
+ // cpu_0_cpu_0_msmc Background
Firewall - 0
+ firewall-0 {
+ id = <257>;
+ region = <0>;
+ control = <0x31a>;
+ permissions =
<0xc3>;
+ start_address = <0x0
0x0>;
+ end_address = <0xff
0x>;
+ };
+
+ // cpu_0_cpu_0_msmc Foreground
Firewall
+ firewall-1 {
+ id = <257>;
+ region = <1>;
+ control = <0x1a>;
+ permissions =
<0x0100ff>;
+ start_address = <0x0
0x7000>;
+ end_address = <0x0
0x7001>;
+ };
+
+ // dru_0_msmc Background
Firewall - 0
+ firewall-4 {
+ id = <284>;
+ region = <0>;
+ control = <0x31a>;
+ permissions =
<0xc3>;
+ start_address = <0x0
0x0>;
+ end_address = <0xff
0x>;
+ };
+
+ // dru_0_msmc Foreground
Firewall
+ firewall-5 {
+ id = <284>;
+ region = <1>;
+ control = <0x1a>;
+ permissions =
<0x0100ff>;
+ start_address = <0x0
0x7000>;
+ end_address = <0x0
0x7001>;
+ };
+
+ // Slave Background Firewall - 0
+ // Already configured by secure
entity
+
+ // Slave Foreground Firewall
+ firewall-7 {
+ id = <4760>;
+ region = <1>;
+ control = <0x1a>;
+ permissions =
<0x0100ff>;
+ start_address = <0x0
0x7000>;
+ end_address = <0x0
0x7001>;
+ };
+
+ // Slave Background Firewall - 0
+ // Already configured by secure
entity
+
+ // Slave Foreground Firewall
+ firewall-9 {
+ id = <4761>;
+ region = <1>;
+ control = <0x1a>;
+ permissions =
<0x0100ff>;
+
[RFC PATCH 1/2] binman: ti-secure: Add support for firewalling entities
We can now firewall entities while loading them through our secure
entity TIFS, the required information should be present in the
certificate that is being parsed by TIFS.
The following commit adds the support to enable the certificates to be
generated if the firewall configurations are present in the binman dtsi
nodes.
Signed-off-by: Manorit Chawdhry
---
tools/binman/btool/openssl.py | 16 ++--
tools/binman/etype/ti_secure.py | 54 +
tools/binman/etype/x509_cert.py | 3 ++-
3 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index aad3b61ae27c..dff439df211f 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -82,7 +82,7 @@ imageSize = INTEGER:{len(indata)}
return self.run_cmd(*args)
def x509_cert_sysfw(self, cert_fname, input_fname, key_fname, sw_rev,
- config_fname, req_dist_name_dict):
+ config_fname, req_dist_name_dict, firewall_cert_data):
"""Create a certificate to be booted by system firmware
Args:
@@ -94,6 +94,13 @@ imageSize = INTEGER:{len(indata)}
req_dist_name_dict (dict): Dictionary containing key-value pairs of
req_distinguished_name section extensions, must contain extensions
for
C, ST, L, O, OU, CN and emailAddress
+firewall_cert_data (dict):
+ - auth_in_place (int): The Priv ID for copying as the
+specific host in firewall protected region
+ - num_firewalls (int): The number of firewalls in the
+extended certificate
+ - certificate (str): Extended firewall certificate with
+the information for the firewall configurations.
Returns:
str: Tool output
@@ -121,6 +128,7 @@ basicConstraints = CA:true
1.3.6.1.4.1.294.1.3= ASN1:SEQUENCE:swrv
1.3.6.1.4.1.294.1.34 = ASN1:SEQUENCE:sysfw_image_integrity
1.3.6.1.4.1.294.1.35 = ASN1:SEQUENCE:sysfw_image_load
+1.3.6.1.4.1.294.1.37 = ASN1:SEQUENCE:firewall
[ swrv ]
swrv = INTEGER:{sw_rev}
@@ -132,7 +140,11 @@ imageSize = INTEGER:{len(indata)}
[ sysfw_image_load ]
destAddr = FORMAT:HEX,OCT:
-authInPlace = INTEGER:2
+authInPlace = INTEGER:{hex(firewall_cert_data['auth_in_place'])}
+
+[ firewall ]
+numFirewallRegions = INTEGER:{firewall_cert_data['num_firewalls']}
+{firewall_cert_data['certificate']}
''', file=outf)
args = ['req', '-new', '-x509', '-key', key_fname, '-nodes',
'-outform', 'DER', '-out', cert_fname, '-config', config_fname,
diff --git a/tools/binman/etype/ti_secure.py b/tools/binman/etype/ti_secure.py
index d939dce57139..a980d10f4197 100644
--- a/tools/binman/etype/ti_secure.py
+++ b/tools/binman/etype/ti_secure.py
@@ -7,9 +7,39 @@
from binman.entry import EntryArg
from binman.etype.x509_cert import Entry_x509_cert
+from dataclasses import dataclass
from dtoc import fdt_util
+def hex_octet(n):
+ x = '%x' % (n,)
+ return ('0' * (len(x) % 2)) + x
+
+@dataclass
+class Firewall():
+id: int
+region: int
+control : int
+permissions: list[hex]
+start_address: str
+end_address: str
+
+def get_certificate(self) -> str:
+unique_indentifier = f"{self.id}{self.region}"
+cert = f"""
+firewallID{unique_indentifier} = INTEGER:{self.id}
+region{unique_indentifier} = INTEGER:{self.region}
+control{unique_indentifier} = INTEGER:{hex(self.control)}
+nPermissionRegs{unique_indentifier} = INTEGER:{len(self.permissions)}
+"""
+for index, permission in enumerate(self.permissions):
+cert += f"""permissions{unique_indentifier}{index} =
INTEGER:{hex(permission)}
+"""
+cert += f"""startAddress{unique_indentifier} =
FORMAT:HEX,OCT:{hex_octet(self.start_address)}
+endAddress{unique_indentifier} = FORMAT:HEX,OCT:{hex_octet(self.end_address)}
+"""
+return cert
+
class Entry_ti_secure(Entry_x509_cert):
"""Entry containing a TI x509 certificate binary
@@ -32,11 +62,20 @@ class Entry_ti_secure(Entry_x509_cert):
def __init__(self, section, etype, node):
super().__init__(section, etype, node)
self.openssl = None
+self.firewall_cert_data: dict = {
+'auth_in_place': 0x02,
+'num_firewalls': 0,
+'certificate': "",
+}
def ReadNode(self):
super().ReadNode()
self.key_fname = self.GetEntryArgsOrProps([
EntryArg('keyfile', str)], required=True)[0]
+auth_in_place = fdt_util.GetInt(self._node, "auth_in_place")
+if auth_in_place:
+self.firewall_cert_data['auth_in_place'] = auth_in_place
+self.ReadFirewallNode()
self.sha = fdt_util.GetInt(self._node, 'sha', 512)
self.req_dist_name = {'C': 'US',
'ST': 'TX',
@@ -46,6 +85,21 @@
[RFC PATCH 0/2] RFC version for ATF and OP-TEE Firewalling
This is a start to firewall ATF and OP-TEE memory regions using the firewalls present in K3 SoCs. Please give reviews as to what can be better in the implementation. Signed-off-by: Manorit Chawdhry --- Manorit Chawdhry (2): binman: ti-secure: Add support for firewalling entities binman: j721e: Add firewall configurations for atf arch/arm/dts/k3-j721e-binman.dtsi | 161 ++ tools/binman/btool/openssl.py | 16 +++- tools/binman/etype/ti_secure.py | 54 + tools/binman/etype/x509_cert.py | 3 +- 4 files changed, 231 insertions(+), 3 deletions(-) --- base-commit: 321d7b4d875a77552a969dd6ea5bbed2644fcb0c change-id: 20230724-binman-firewalling-65ecdb23ec0a Best regards, -- Manorit Chawdhry
Pull request: please pull u-boot-imx-20230905
Hi Tom, some fixes for the release, please pull from u-boot-imx, thanks ! The following changes since commit 8999257f219d1e371c2fd66f255b8782897944d9: Merge tag 'doc-2023-10-rc4-2' of https://source.denx.de/u-boot/custodians/u-boot-efi (2023-09-02 09:08:54 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-20230905 for you to fetch changes up to a79fca7b44d0dee96e14d31de5869b35b587283c: thermal: imx_tmu: Increase the polling interval (2023-09-04 17:26:44 +0200) Fixes for release - - imx9: fix DRAM calculation - thermal: fixes - fixed for DM, DH and Gateworks boards CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/17639 Elena Popa (1): arm: imx: imx8m: imx9: Fix DRAM size calculation due to rom_pointer Fabio Estevam (5): imx8mm_evk_defconfig: Select CONFIG_IMX_TMU thermal: imx_tmu: Fix the polling default thermal: imx_tmu: Increase the log level for high temperatures thermal: imx_tmu: Fix the temperature unit thermal: imx_tmu: Increase the polling interval Marek Vasut (5): ARM: imx: Drop CONFIG_USE_BOOTCOMMAND=n on i.MX6 DHSOM ARM: imx: Select 2 DRAM banks on Data Modul i.MX8M Mini eDM SBC ARM: imx: Use default SAVED_DRAM_TIMING_BASE on DH i.MX8M Plus DHCOM ARM: imx: Use default SAVED_DRAM_TIMING_BASE on Data Modul i.MX8M Mini eDM SBC ARM: imx: Use default SAVED_DRAM_TIMING_BASE on Data Modul i.MX8M Plus eDM SBC Tim Harvey (1): board: gateworks: venice: fix gw7904 arch/arm/mach-imx/imx8m/soc.c | 7 --- arch/arm/mach-imx/imx9/soc.c| 6 +++--- configs/dh_imx6_defconfig | 1 - configs/imx8mm_data_modul_edm_sbc_defconfig | 3 +-- configs/imx8mm_evk_defconfig| 1 + configs/imx8mm_venice_defconfig | 2 +- configs/imx8mp_data_modul_edm_sbc_defconfig | 1 - configs/imx8mp_dhcom_pdk2_defconfig | 1 - configs/imx8mp_dhcom_pdk3_defconfig | 1 - drivers/thermal/imx_tmu.c | 10 +++--- 10 files changed, 17 insertions(+), 16 deletions(-) Best regards, Stefano -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 1/5] imx8mm_evk_defconfig: Select CONFIG_IMX_TMU
> From: Fabio Estevam > Select the i.MX8MM thermal driver as it is useful for displaying > the CPU temperature and its grading: > CPU: Commercial temperature grade (0C to 95C) at 38C > It also prevents booting when the temperature is above the alert > point. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 3/5] thermal: imx_tmu: Increase the log level for high temperatures
> From: Fabio Estevam > dev_info() message is not printed by default. Increase the log level > to dev_crit(). This allows the critical messages related to the temperature > getting beyong the alert threshold to be displayed. > Signed-off-by: Fabio Estevam > Reviewed-by: Tom Rini Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 5/5] thermal: imx_tmu: Increase the polling interval
> From: Fabio Estevam > Polling every second to check whether the CPU has cooled down is > too frequent. > Allow more time for the CPU to cool down by increasing the polling > interval to 5 seconds by defaut. > This value is used in the absence of the 'polling-delay' devicetree > property. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 4/5] thermal: imx_tmu: Fix the temperature unit
> From: Fabio Estevam > The temperature unit is millidegree Celsius, so divide by 1000 to correctly > print the temperature values in Celsius. > While at it, also change a typo: "has beyond" to "is beyond". > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
[PATCH v2 2/5] thermal: imx_tmu: Fix the polling default
> From: Fabio Estevam > When the 'polling-delay' property is not passed via devicetree, > pdata->polling_delay keeps at 0. This causes the imx_tmu driver to get > stuck inside the busy while() loop when the CPU temperature is above > the alert point. > Fix this problem by passing a one second polling interval, which provides > a proper delay to let the system to cool down and exit the while() loop > when the temperature is below the alert point. > Signed-off-by: Fabio Estevam Applied to u-boot-imx, master, thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH,Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, 82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =
Re: [PATCH v2 1/6] net: wget: prevent overwriting reserved memory
Hi Simon,
On Sat, 2 Sept 2023 at 09:09, Simon Glass wrote:
>
> Hi Masahisa,
>
> On Fri, 1 Sept 2023 at 04:26, Masahisa Kojima
> wrote:
> >
> > This introduces the valid range check to store the received
> > blocks using lmb. The same logic is implemented in tftp.
> >
> > Signed-off-by: Masahisa Kojima
> > ---
> > net/wget.c | 76 +-
> > 1 file changed, 69 insertions(+), 7 deletions(-)
> >
> > diff --git a/net/wget.c b/net/wget.c
> > index 2dbfeb1a1d..8bf4db4d04 100644
> > --- a/net/wget.c
> > +++ b/net/wget.c
> > @@ -4,16 +4,20 @@
> > * Copyright Duncan Hare 2017
> > */
> >
> > +#include
> > #include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> >
> > +DECLARE_GLOBAL_DATA_PTR;
> > +
> > static const char bootfile1[] = "GET ";
> > static const char bootfile3[] = " HTTP/1.0\r\n\r\n";
> > static const char http_eom[] = "\r\n\r\n";
> > @@ -55,6 +59,32 @@ static unsigned int retry_tcp_ack_num; /* TCP
> > retry acknowledge number*/
> > static unsigned int retry_tcp_seq_num; /* TCP retry sequence number */
> > static int retry_len; /* TCP retry length */
> >
> > +#ifdef CONFIG_LMB
> > +static ulong wget_load_size;
> > +#endif
> > +
> > +/**
> > + * wget_init_max_size() - initialize maximum load size
> > + *
> > + * Return: 0 if success, -1 if fails
> > + */
> > +static int wget_init_load_size(void)
> > +{
> > +#ifdef CONFIG_LMB
>
> please can you use if IS_ENABLED() throughout?
OK.
>
> > + struct lmb lmb;
> > + phys_size_t max_size;
> > +
> > + lmb_init_and_reserve(, gd->bd, (void *)gd->fdt_blob);
> > +
> > + max_size = lmb_get_free_size(, image_load_addr);
> > + if (!max_size)
> > + return -1;
> > +
> > + wget_load_size = max_size;
> > +#endif
> > + return 0;
> > +}
> > +
> > /**
> > * store_block() - store block in memory
> > * @src: source of data
> > @@ -63,10 +93,24 @@ static int retry_len; /* TCP
> > retry length */
> > */
> > static inline int store_block(uchar *src, unsigned int offset, unsigned
> > int len)
> > {
> > + ulong store_addr = image_load_addr + offset;
> > ulong newsize = offset + len;
> > uchar *ptr;
> >
> > - ptr = map_sysmem(image_load_addr + offset, len);
> > +#ifdef CONFIG_LMB
> > + ulong end_addr = image_load_addr + wget_load_size;
> > +
> > + if (!end_addr)
> > + end_addr = ULONG_MAX;
> > +
> > + if (store_addr < image_load_addr ||
> > + store_addr + len > end_addr) {
> > + puts("\nwget error: ");
> > + puts("trying to overwrite reserved memory...\n");
> > + return -1;
> > + }
> > +#endif
> > + ptr = map_sysmem(store_addr, len);
> > memcpy(ptr, src, len);
> > unmap_sysmem(ptr);
> >
> > @@ -240,25 +284,37 @@ static void wget_connected(uchar *pkt, unsigned int
> > tcp_seq_num,
> >
> > net_boot_file_size = 0;
> >
> > - if (len > hlen)
> > - store_block(pkt + hlen, 0, len - hlen);
> > + if (len > hlen) {
> > + if (store_block(pkt + hlen, 0, len - hlen)
> > != 0) {
> > + wget_loop_state = NETLOOP_FAIL;
> > + wget_fail("wget: store error\n",
> > tcp_seq_num, tcp_ack_num, action);
> > + return;
> > + }
> > + }
> >
> > debug_cond(DEBUG_WGET,
> >"wget: Connected Pkt %p hlen %x\n",
> >pkt, hlen);
> >
> > for (i = 0; i < pkt_q_idx; i++) {
> > + int err;
> > +
> > ptr1 = map_sysmem(
> > (phys_addr_t)(pkt_q[i].pkt),
> > pkt_q[i].len);
> > - store_block(ptr1,
> > - pkt_q[i].tcp_seq_num -
> > - initial_data_seq_num,
> > - pkt_q[i].len);
> > + err = store_block(ptr1,
> > + pkt_q[i].tcp_seq_num -
> > + initial_data_seq_num,
> > + pkt_q[i].len);
> > unmap_sysmem(ptr1);
> > debug_cond(DEBUG_WGET,
> >"wget: Connctd pkt Q %p len
> > %x\n",
> >pkt_q[i].pkt,
Re: [PATCH v1 2/2] doc: board: starfive: Add more info about supported driver
On 8/22/23 16:33, Shengyu Qu wrote: Since PLDA PCIE driver is added and VL805 support is enabled in defconfig for Starfive Visionfive 2, modify the document to keep consistent. Signed-off-by: Shengyu Qu --- doc/board/starfive/visionfive2.rst | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/board/starfive/visionfive2.rst b/doc/board/starfive/visionfive2.rst index 941899a0a4..460f23aec3 100644 --- a/doc/board/starfive/visionfive2.rst +++ b/doc/board/starfive/visionfive2.rst @@ -20,6 +20,8 @@ The support for following drivers are already enabled: Nits: Support for the following drivers is already enabled: Best regards Heinrich 3. StarFive JH7110 reset Driver. 4. Cadence QSPI controller Driver. 5. MMC SPI Driver for MMC/SD support. +6. PLDA PCIE controller driver. +7. On-board VL805 PCIE-USB controller driver. Booting from MMC using U-Boot SPL -
Re: [PATCH] tools: logos: Rename TI logo files
On 01/09/23 16:09, Nikhil M Jain wrote:
> Change the file name from ti.gz and ti.bmp to ti_logos_414x97_32bpp to
> help user understand the resolution and identify the logo files when
> placed in the boot partition and update the splashfile name with the
> same in .env file.
>
> Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
Regards
Devarsh
> ---
> board/ti/am62x/am62x.env | 2 +-
> tools/logos/{ti.bmp => ti_logo_414x97_32bpp.bmp} | Bin
> tools/logos/{ti.gz => ti_logo_414x97_32bpp.bmp.gz} | Bin
> 3 files changed, 1 insertion(+), 1 deletion(-)
> rename tools/logos/{ti.bmp => ti_logo_414x97_32bpp.bmp} (100%)
> rename tools/logos/{ti.gz => ti_logo_414x97_32bpp.bmp.gz} (100%)
>
> diff --git a/board/ti/am62x/am62x.env b/board/ti/am62x/am62x.env
> index f2dc87893a..ece9eacc08 100644
> --- a/board/ti/am62x/am62x.env
> +++ b/board/ti/am62x/am62x.env
> @@ -17,7 +17,7 @@ bootpart=1:2
> bootdir=/boot
> rd_spec=-
>
> -splashfile=ti.gz
> +splashfile=ti_logo_414x97_32bpp.bmp.gz
> splashimage=0x8020
> splashpos=m,m
> splashsource=sf
> diff --git a/tools/logos/ti.bmp b/tools/logos/ti_logo_414x97_32bpp.bmp
> similarity index 100%
> rename from tools/logos/ti.bmp
> rename to tools/logos/ti_logo_414x97_32bpp.bmp
> diff --git a/tools/logos/ti.gz b/tools/logos/ti_logo_414x97_32bpp.bmp.gz
> similarity index 100%
> rename from tools/logos/ti.gz
> rename to tools/logos/ti_logo_414x97_32bpp.bmp.gz
