Re: U-Boot OMAP GPMC ECC change
Hi Roger,
I really appreciate the help!
On Thu, May 18, 2023 at 01:55:38PM +0300, Roger Quadros wrote:
> Hi Colin,
>
> On 17/05/2023 22:39, Colin Foster wrote:
> >
> > I swapped in just U-Boot (not the SPL) with your patch, and everything
> > seems to work!
> >
> > The issue of Uncorrectable ECC errors spam came from the SPL. Here's a
> > snippet of the boot log with the "ecc" print as well as your patch:
> >
>
> Thanks for the tests. Glad to hear issue is narrowed down to SPL.
I can "fix" the issue by just commenting out the "ECC uncorrectable
errors" print :-)
>
> > U-Boot SPL 2023.04-00029-g26a9ce5314-dirty (May 17 2023 - 12:06:49 -0700)
> > OMAP4460-GP ES1.1
> > Trying to boot from NAND
> > ecc: 2420106
> > ecc: ebd922f6
> > ecc: 333f844f
> > ecc: ab812f72
>
> This is clearly the issue. They should all have been 0.
Interesting. With the "ecc" prints in U-Boot I also get some non-zero
values:
ecc: 0
ecc: 6bff997b
ecc: 6bff997b
ecc: 6bff997b
Once I'm booted, I can use nanddump. It seems like everything is correct
from the Linux side of things:
# nanddump -f mlo_dump /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x and ending at 0x0002...
# nanddump -f uboot1_dump /dev/mtd1
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x and ending at 0x0018...
# nanddump -f uboot2_dump /dev/mtd2
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x and ending at 0x0018...
# nanddump -f /dev/null /dev/mtd3
ECC failed: 0
ECC corrected: 6
Number of bad blocks: 0
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 64
Dumping data starting at 0x and ending at 0x1fce...
ECC: 1 corrected bitflip(s) at offset 0x0ab30800
ECC: 1 corrected bitflip(s) at offset 0x0b008800
ECC: 1 corrected bitflip(s) at offset 0x0deaa000
ECC: 1 corrected bitflip(s) at offset 0x0ea5b000
ECC: 1 corrected bitflip(s) at offset 0x0ecbc000
ECC: 1 corrected bitflip(s) at offset 0x0ed61800
> Can you please share your spl/u-boot.cfg?
Attached
> We have a stripped down driver "am335x_spl_bch.c"
> that deals with NAND at SPL.
> I haven't really looked much at that driver but
> it relies on omap_gpmc.c for
>
> ecc.hwctl()
> read_buf()
> ecc.calculate()
>
> We didn't do any functional change to these functions in commit 04fcd25873
> unless something slipped through the cracks.
I'll take a look at am335x_spl_bch.c and look at what I'm doing different.
I was sad to see that `dump_stack()` didn't work off the bat for me.
>
> It seems to rely on following config options
>
> CFG_SYS_NAND_ECCPOS
{2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, \
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, \
23, 24, 25, 26, 27, 28, 29, 30, 31, 32, \
33, 34, 35, 36, 37, 38, 39, 40, 41, \
42, 43, 44, 45, 46, 47, 48, 49, 50, 51, \
52, 53, 54, 55, 56, 57}
> CONFIG_SYS_NAND_PAGE_COUNT
0x40
> CONFIG_SYS_NAND_PAGE_SIZE
0x800
> CONFIG_SYS_NAND_5_ADDR_CYCLE
1
> CFG_SYS_NAND_ECCSIZE
512
> CFG_SYS_NAND_ECCBYTES
14
> CONFIG_SYS_NAND_OOBSIZE
0x40
> Could you please share what they are set to
> for your SPL build?
All the CFG_* values should be identical for the SPL and U-Boot.
>
> Meanwhile, I'll try to reproduce this on AM335x-EVM.
If you find anything let me know. I'll keep digging on my side as well.
Colin
#define CONFIG_CMD_MTD 1
#define CONFIG_ETH 1
#define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1
#define CONFIG_CMD_FAT 1
#define CONFIG_TOOLS_SHA1 1
#define CONFIG_HAVE_TEXT_BASE 1
#define CONFIG_EFI_DEVICE_PATH_UTIL 1
#define CONFIG_CMD_FDT 1
#define CONFIG_OMAP_SERIAL 1
#define CONFIG_NAND_OMAP_GPMC 1
#define CONFIG_SYS_NAND_U_BOOT_OFFS 0x2
#define CONFIG_BOOTMETH_VBE_SIMPLE 1
#define CONFIG_CMD_ITEST 1
#define CONFIG_ENV_UBI_PART "main"
#define CONFIG_ERR_PTR_OFFSET 0x0
#define CONFIG_BOOTMETH_SCRIPT 1
#define CONFIG_CMD_EDITENV 1
#define CONFIG_SPL_SPRINTF 1
#define CONFIG_NAND_OMAP_ELM 1
#define CONFIG_CMD_MTDPARTS 1
#define CONFIG_EFI_PLATFORM_LANG_CODES "en-US"
#define CONFIG_SPL_NAND_SUPPORT 1
#define CONFIG_CMD_SETEXPR 1
#define CONFIG_TOOLS_SHA384 1
#define CONFIG_SYS_MAX_NAND_DEVICE 1
#define CONFIG_TOOLS_OF_LIBFDT 1
#define CONFIG_CMD_BOOTP 1
#define CONFIG_SYS_MEM_TOP_HIDE 0x0
#define CONFIG_CMD_PART 1
#define CONFIG_SPL_LEGACY_IMAGE_FORMAT 1
#define CONFIG_ENV_SUPPORT 1
#define CONFIG_SPL_LOGLEVEL 7
#define CONFIG_SPL_USE_ARCH_MEMSET 1
#define CONFIG_SYS_NAND_DRIVER_ECC_LAYOUT 1
#define CONFIG_HAS_VBAR 1
#define CONFIG_CMD_ENV_EXISTS 1
#define CONFIG_VERSION_VARIABLE 1
#define CONFIG_CMD_CRC32 1
#define CONFIG_SYS_LONGHELP 1
#define CONFIG_SYS_NAND_5_ADDR_CYCLE 1
#define CONFIG_GCC_VERSION 90400
#define CONFIG_SYS_LOAD_ADDR 0x8200
#define CONFIG_HASH 1
#define
[PATCH 2/2] doc: bindings: soft-spi: Remove the usage of deprecated properties
From: Fabio Estevam
According to Documentation/devicetree/bindings/spi/spi-gpio.yaml
from Linux, the recommended spio-gpio properties are:
sck-gpios, miso-gpios and mosi-gpios.
gpio-sck, gpio-mosi and gpio-miso are considered deprecated.
Update the bindings to suggest the recommeded properties.
Signed-off-by: Fabio Estevam
---
doc/device-tree-bindings/spi/soft-spi.txt | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/doc/device-tree-bindings/spi/soft-spi.txt
b/doc/device-tree-bindings/spi/soft-spi.txt
index dfb50664732f..bdf7e86befb9 100644
--- a/doc/device-tree-bindings/spi/soft-spi.txt
+++ b/doc/device-tree-bindings/spi/soft-spi.txt
@@ -9,10 +9,10 @@ The soft SPI node requires the following properties:
Mandatory properties:
compatible: "spi-gpio"
cs-gpios: GPIOs to use for SPI chip select (output)
-gpio-sck: GPIO to use for SPI clock (output)
+sck-gpios: GPIO to use for SPI clock (output)
And at least one of:
-gpio-mosi: GPIO to use for SPI MOSI line (output)
-gpio-miso: GPIO to use for SPI MISO line (input)
+mosi-gpios: GPIO to use for SPI MOSI line (output)
+miso-gpios: GPIO to use for SPI MISO line (input)
Optional propertie:
spi-delay-us: Number of microseconds of delay between each CS transition
@@ -27,9 +27,9 @@ Example:
soft-spi {
compatible = "spi-gpio";
cs-gpios = < 235 0>; /* Y43 */
- gpio-sck = < 225 0>; /* Y31 */
- gpio-mosi = < 227 0>; /* Y33 */
- gpio-miso = < 224 0>; /* Y30 */
+ sck-gpios = < 225 0>; /* Y31 */
+ mosi-gpios = < 227 0>; /* Y33 */
+ miso-gpios = < 224 0>; /* Y30 */
spi-delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1
[PATCH 1/2] spi: soft_spi: Support the recommended soft spi properties
From: Fabio Estevam According to Documentation/devicetree/bindings/spi/spi-gpio.yaml from Linux, the recommended spio-gpio properties are: sck-gpios, miso-gpios and mosi-gpios. gpio-sck, gpio-mosi and gpio-miso are considered deprecated. Currently, U-Boot only supports the deprecated properties. Allow the soft_spi driver to support both the new and old properties. Signed-off-by: Fabio Estevam --- drivers/spi/soft_spi.c | 21 + 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/drivers/spi/soft_spi.c b/drivers/spi/soft_spi.c index f3602a25ba30..0fa14339bdcd 100644 --- a/drivers/spi/soft_spi.c +++ b/drivers/spi/soft_spi.c @@ -248,19 +248,32 @@ static int soft_spi_probe(struct udevice *dev) cs_flags = (slave && slave->mode & SPI_CS_HIGH) ? 0 : GPIOD_ACTIVE_LOW; clk_flags = (slave && slave->mode & SPI_CPOL) ? GPIOD_ACTIVE_LOW : 0; - if (gpio_request_by_name(dev, "cs-gpios", 0, >cs, -GPIOD_IS_OUT | cs_flags) || - gpio_request_by_name(dev, "gpio-sck", 0, >sclk, -GPIOD_IS_OUT | clk_flags)) + ret = gpio_request_by_name(dev, "cs-gpios", 0, >cs, + GPIOD_IS_OUT | cs_flags); + if (ret) + return -EINVAL; + + ret = gpio_request_by_name(dev, "gpio-sck", 0, >sclk, + GPIOD_IS_OUT | clk_flags); + if (ret) + ret = gpio_request_by_name(dev, "sck-gpios", 0, >sclk, + GPIOD_IS_OUT | clk_flags); + if (ret) return -EINVAL; ret = gpio_request_by_name(dev, "gpio-mosi", 0, >mosi, GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE); + if (ret) + ret = gpio_request_by_name(dev, "mosi-gpios", 0, >mosi, + GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE); if (ret) plat->flags |= SPI_MASTER_NO_TX; ret = gpio_request_by_name(dev, "gpio-miso", 0, >miso, GPIOD_IS_IN); + if (ret) + ret = gpio_request_by_name(dev, "gpio-miso", 0, >miso, + GPIOD_IS_IN); if (ret) plat->flags |= SPI_MASTER_NO_RX; -- 2.34.1
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 02:30:53PM -0400, Sean Anderson wrote: > On 5/18/23 10:06, Conor Dooley wrote: > > On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote: > >> On Thu, May 18, 2023 at 4:02 PM Andrew Jones > >> wrote: > >> > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > > >> > > - riscv,isa: > >> > > -description: > >> > > - Identifies the specific RISC-V instruction set architecture > >> > > - supported by the hart. These are documented in the RISC-V > >> > > - User-Level ISA document, available from > >> > > - https://riscv.org/specifications/ > >> > > - > >> > > - Due to revisions of the ISA specification, some deviations > >> > > - have arisen over time. > >> > > - Notably, riscv,isa was defined prior to the creation of the > >> > > - Zicsr and Zifencei extensions and thus "i" implies > >> > > - "zicsr_zifencei". > >> > > - > >> > > - While the isa strings in ISA specification are case > >> > > - insensitive, letters in the riscv,isa string must be all > >> > > - lowercase to simplify parsing. > >> > > -$ref: "/schemas/types.yaml#/definitions/string" > >> > > -pattern: > >> > > ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ > >> > > - > >> > ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here > >> > >timebase-frequency: false > >> > > > >> > > @@ -133,8 +117,13 @@ properties: > >> > >DMIPS/MHz, relative to highest capacity-dmips-mhz > >> > >in the system. > >> > > > >> > > +oneOf: > >> > > + - required: > >> > > + - riscv,isa > >> > > >> > This is the part Anup keeps reminding me about. We can create better ways > >> > to handle extensions in DT and ACPI, but we'll still need to parse ISA > >> > strings to handle legacy DTs and holdouts that keep creating ISA strings, > >> > at least during the deprecation period, since ISA strings are still "the > >> > way to do it" according to the spec. > >> > >> Coming up with an alternate way in DT is fine but we can't deprecate > >> ISA strings since ISA strings are widely used: > >> 1) Various bootloaders > > > > Aye, for the reason, as I mentioned earlier and in the RFC thread, > > removing existing parsers isn't a good idea. > > > >> 2) It is part of /proc/cpuinfo > > > > That is irrelevant. > > > >> 3) Hypervisors use it to communicate HW features to Guest/VM. > >> Hypervisors can't get away from generating ISA strings because > >> Hypervisors don't know what is running inside Guest/VM. > > > > Generate both :) As things stand, your guests could interpret what you > > communicate to them via riscv,isa differently! > > > >> In the case of ACPI, it is a very different situation. Like Sunil > >> mentioned, > >> ACPI will always follow mechanisms defined by RVI (such as ISA string). > >> Other ACPI approaches such as GUID for ISA extension are simply not > >> scalable and will take a lot more memory for ACPI tables compared to > >> ISA strings. > > > > My proposal should actually suit ACPI, at least for Linux, as it would > > be a chance to align currently misaligned definitions. I won't speak to > > GUIDs or whatever as that's someone else's problem :) > > > >> > Also, if we assume the wording in the spec does get shored up, then, > >> > unless I'm missing something, the list of advantages for this boolean > >> > proposal from your commit message would be > >> > >> IMO, we should try our best to have the wordings changed in RVI spec. > > > > Yes, doing so is beneficial for all of us regardless of what happens > > here. I do think that it is partially orthogonal - it allows us to not > > design an interface that needs to be capable of communicating a wide > > variety of versions, but I don't think it solves some of the issues > > that riscv,isa has. If I thought it did, I would not have gone to the > > trouble of respinning this patch out of the other approach. > > > >> > * More character choices for name -- probably not a huge gain for > >> > ratified > >> > extensions, since the boolean properties will likely still use the same > >> > name as the ISA string (riscv,isa-extension-). But, for vendor > >> > extensions, this is indeed a major improvement, since vendor extension > >> > boolean property names may need to be extended in unambiguous ways to > >> > handle changes in the extension. > >> > > >> > * Simpler, more complete DT validation (but we still need a best effort > >> > for legacy ISA strings) > >> > > >> > * Simpler DT parsing (but we still need the current parser for legacy ISA > >> > strings) > >> > > >> > > + - required: > >> > > + - riscv,isa-base > >> > > + > >> > > required: > >> > > - - riscv,isa > >> > >- interrupt-controller > >> > > > >> > > additionalProperties: true > >> > > @@ -177,7 +166,13 @@ examples: > >> > > i-tlb-size = <32>; > >> > > mmu-type = "riscv,sv39"; > >> > >
Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot
On 2023-05-08 1:20 p.m., Tom Rini wrote:
Here's the latest defect report:
-- Forwarded message -
From:
Date: Mon, May 8, 2023, 2:29 PM
Subject: New Defects reported by Coverity Scan for Das U-Boot
To:
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot
found with Coverity Scan.
5 new defect(s) introduced to Das U-Boot found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the
recent build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)
** CID 453851: Memory - corruptions (OVERLAPPING_COPY)
/cmd/net.c: 279 in netboot_update_env()
*** CID 453851: Memory - corruptions (OVERLAPPING_COPY)
/cmd/net.c: 279 in netboot_update_env()
273
274 if (IS_ENABLED(CONFIG_IPV6)) {
275 if (!ip6_is_unspecified_addr(_ip6) ||
276 net_prefix_length != 0) {
277 sprintf(tmp, "%pI6c", _ip6);
278 if (net_prefix_length != 0)
CID 453851: Memory - corruptions (OVERLAPPING_COPY)
In the call to function "sprintf", the arguments "tmp" and "tmp"
Just submitted a patch to fix 453851.
may point to the same object.
279 sprintf(tmp, "%s/%d", tmp,
net_prefix_length);
280
281 env_set("ip6addr", tmp);
282 }
283
284 if (!ip6_is_unspecified_addr(_server_ip6)) {
** CID 450971: Insecure data handling (TAINTED_SCALAR)
/net/ndisc.c: 391 in process_ra()
*** CID 450971: Insecure data handling (TAINTED_SCALAR)
/net/ndisc.c: 391 in process_ra()
385 /* Ignore the packet if router lifetime is 0. */
386 if (!icmp->icmp6_rt_lifetime)
387 return -EOPNOTSUPP;
388
389 /* Processing the options */
390 option = msg->opt;
CID 450971: Insecure data handling (TAINTED_SCALAR)
Using tainted variable "remaining_option_len" as a loop boundary.
391 while (remaining_option_len > 0) {
392 /* The 2nd byte of the option is its length. */
393 option_len = option[1];
394 /* All included options should have a positive
length. */
395 if (option_len == 0)
396 return -EINVAL;
** CID 450969: Security best practices violations (DC.WEAK_CRYPTO)
/net/ndisc.c: 209 in ip6_send_rs()
*** CID 450969: Security best practices violations (DC.WEAK_CRYPTO)
/net/ndisc.c: 209 in ip6_send_rs()
203icmp_len, PROT_ICMPV6, pcsum);
204 msg->icmph.icmp6_cksum = csum;
205 pkt += icmp_len;
206
207 /* Wait up to 1 second if it is the first try to get the RA
*/
208 if (retry_count == 0)
CID 450969: Security best practices violations (DC.WEAK_CRYPTO)
"rand" should not be used for security-related applications,
because linear congruential algorithms are too easy to break.
209 udelay(((unsigned int)rand() % 100) *
MAX_SOLICITATION_DELAY);
210
211 /* send it! */
212 net_send_packet(net_tx_packet, (pkt - net_tx_packet));
213
214 retry_count++;
** CID 436282:(DC.WEAK_CRYPTO)
/net/dhcpv6.c: 621 in dhcp6_state_machine()
/net/dhcpv6.c: 627 in dhcp6_state_machine()
/net/dhcpv6.c: 628 in dhcp6_state_machine()
/net/dhcpv6.c: 662 in dhcp6_state_machine()
/net/dhcpv6.c: 613 in dhcp6_state_machine()
*** CID 436282:(DC.WEAK_CRYPTO)
/net/dhcpv6.c: 621 in dhcp6_state_machine()
615 /* handle state machine entry conditions */
616 if (sm_params.curr_state != sm_params.next_state) {
617 sm_params.retry_cnt = 0;
618
619 if (sm_params.next_state == DHCP6_SOLICIT) {
620 /* delay a random ammount (special for
SOLICIT) */
CID 436282:(DC.WEAK_CRYPTO)
"rand" should not be used for security-related applications,
because linear congruential algorithms are too easy to break.
621 udelay((rand() % SOL_MAX_DELAY_MS) * 1000);
622 /* init timestamp variables after SOLICIT
delay */
623 sm_params.dhcp6_start_ms = get_timer(0);
624 sm_params.dhcp6_retry_start_ms =
sm_params.dhcp6_start_ms;
625 sm_params.dhcp6_retry_ms =
sm_params.dhcp6_start_ms;
Re: mmc: Read eMMC partition access bits before card reset
Hi Stefan, On Wed, May 17, 2023 at 1:26 AM Stefan Roese wrote: > > Hi Pali, > > On 5/17/23 00:30, Pali Rohár wrote: > > On Tuesday 16 May 2023 14:56:46 Tom Rini wrote: > >> On Tue, May 16, 2023 at 08:52:23PM +0200, Pali Rohár wrote: > >>> On Tuesday 16 May 2023 11:36:20 Tom Rini wrote: > On Tue, May 16, 2023 at 09:04:27AM +0200, Pali Rohár wrote: > > On Sunday 07 May 2023 22:36:16 Pali Rohár wrote: > >> On Sunday 07 May 2023 12:45:11 Tom Rini wrote: > >>> On Sun, May 07, 2023 at 04:56:04PM +0200, Pali Rohár wrote: > On Sunday 07 May 2023 10:40:44 Tom Rini wrote: > > On Sun, May 07, 2023 at 04:01:04PM +0200, Pali Rohár wrote: > >> On Sunday 07 May 2023 09:54:52 Tom Rini wrote: > >>> On Fri, May 05, 2023 at 09:37:10PM +0200, Pali Rohár wrote: > On Wednesday 03 May 2023 13:14:56 Tom Rini wrote: > > On Wed, May 03, 2023 at 11:18:39AM +0200, Stefan Roese wrote: > > > >> Hi Tom, > >> > >> please pull this next batch of mostly Marvell related patches: > > > > NAK. With commit: > > commit 461fa17970de418a93832f734a595031c0b72128 > > Author: Pali Rohár > > Date: Thu Apr 13 22:57:48 2023 +0200 > > > > mmc: Read eMMC partition access bits before card reset > > > > eMMC specification in section "Access partitions" says > > that all reset > > events will restore the access bits in PARTITION_CONFIG > > CSD register to > > default User Data Area value (0b000). > > > > So read partition access bits from PARTITION_CONFIG CSD > > register before > > issuing card reset. This allows SPL/U-Boot to get > > information which eMMC > > partition was in use before SPL/U-Boot was booted. For > > some platforms this > > is the way how to determinate boot partition from which > > BootROM loaded SPL. > > > > Signed-off-by: Pali Rohár > > > > My am335x_evm now fails to boot with: > > > > U-Boot SPL 2023.07-rc1-00021-g461fa17970de (May 03 2023 - > > 13:10:10 -0400) > > Trying to boot from MMC1 > > omap_hsmmc_send_cmd: timedout waiting on cmd inhibit to clear > > spl: mmc init failed with error: -110 > > SPL: failed to boot from all boot devices > > ### ERROR ### Please RESET the board ### > > > > I can provide more details / test patches as needed. > > > > -- > > Tom > > I do not know what to do with this... The only idea is to hide > this code > behind CONFIG symbol and enable it only for mvebu. For example > by this: > >>> > >>> Well, maybe the problem is we're trying this on uSD cards? The > >>> failure I > >>> reported was uSD and not eMMC. > >> > >> Maybe it is that reason. Problem is that at this stage we do not > >> know if > >> card is SD or MMC. > >> > >> Martin, can you check if booting from SD card is working fine on > >> mvebu > >> clearfog? > >> > >>> I see a failure with this commit on > >>> rpi_3_32b, also from uSD boot. This time it's: > >>> Loading Environment from FAT... fsm 0, hsts > >>> fsm 0, hsts > >>> ... > >>> > >>> once in U-Boot itself. Going to the commit prior to the above > >>> one and > >>> the board is fine again. > >>> > >>> -- > >>> Tom > >> > >> Immediately after that "problematic code" is card reset function. > >> So > >> another reason for failure is that card reset functionality does > >> not > >> work correctly on your board / platform. > > > > Well, we're at two different platforms and controllers that this > > change > > breaks things on, so I'm not sure where the fault is exactly. My > > mx6cuboxi is still fine booting from uSD. Another TI platform from > > the > > same general era as am335x fails the same way (not a surprise), > > amlogic > > libretech-cc is fine, pine64_plus is fine, and my newer TI > > platforms are > > also fine with this. So maybe the Kconfig is fine, but we just want > > default y, default n if ARCH_OMAP2PLUS || ARCH_BCM283X (the TI > > platforms > > that work are not ARCH_OMAP2PLUS). > > > > -- > > Tom > > And do you see this problem in SPL
Re: [PULL] u-boot-usb/next
On Thu, May 18, 2023 at 05:01:23PM +0200, Marek Vasut wrote: > The following changes since commit 5d0b3dde115b0d26d414199678983d01b738ad1b: > > Merge branch '2023-05-15-build-system-updates' into next (2023-05-15 > 15:26:54 -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-usb.git next > > for you to fetch changes up to da83ada02a2684f743fadaf3b915e92f83d74628: > > usb: gadget: Add and use matching SPL USB ethernet gadget Kconfig symbols > (2023-05-17 01:51:39 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/2] net: dhcp6: Fix VCI string
From: Sean Edmond Change VCI string from "U-boot" to "U-Boot". Signed-off-by: Sean Edmond --- net/dhcpv6.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/dhcpv6.h b/net/dhcpv6.h index 80ca520432..65c8e4c71d 100644 --- a/net/dhcpv6.h +++ b/net/dhcpv6.h @@ -38,7 +38,7 @@ #define DUID_MAX_SIZE DUID_LL_SIZE /* only supports DUID-LL currently */ /* vendor-class-data to send in vendor clas option */ -#define DHCP6_VCI_STRING "U-boot" +#define DHCP6_VCI_STRING "U-Boot" #define DHCP6_MULTICAST_ADDR "ff02::1:2" /* DHCP multicast address */ -- 2.40.0
[PATCH 1/2] net: ipv6: Fix CID 453851 and CID 436278
From: Sean Edmond
CID 453851 : sprintf() shouldn't copy from/to tmp
CID 436278 : DHCP6 option_len should be checked before use
Signed-off-by: Sean Edmond
---
cmd/net.c| 12 ++--
net/dhcpv6.c | 5 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/cmd/net.c b/cmd/net.c
index 68d406291e..9e1f40a56e 100644
--- a/cmd/net.c
+++ b/cmd/net.c
@@ -209,7 +209,7 @@ U_BOOT_CMD(
static void netboot_update_env(void)
{
- char tmp[44];
+ char tmp[46];
if (net_gateway.s_addr) {
ip_to_string(net_gateway, tmp);
@@ -274,20 +274,20 @@ static void netboot_update_env(void)
if (IS_ENABLED(CONFIG_IPV6)) {
if (!ip6_is_unspecified_addr(_ip6) ||
net_prefix_length != 0) {
- sprintf(tmp, "%pI6c", _ip6);
if (net_prefix_length != 0)
- sprintf(tmp, "%s/%d", tmp, net_prefix_length);
-
+ snprintf(tmp, sizeof(tmp), "%pI6c/%d",
_ip6, net_prefix_length);
+ else
+ snprintf(tmp, sizeof(tmp), "%pI6c", _ip6);
env_set("ip6addr", tmp);
}
if (!ip6_is_unspecified_addr(_server_ip6)) {
- sprintf(tmp, "%pI6c", _server_ip6);
+ snprintf(tmp, sizeof(tmp), "%pI6c", _server_ip6);
env_set("serverip6", tmp);
}
if (!ip6_is_unspecified_addr(_gateway6)) {
- sprintf(tmp, "%pI6c", _gateway6);
+ snprintf(tmp, sizeof(tmp), "%pI6c", _gateway6);
env_set("gatewayip6", tmp);
}
}
diff --git a/net/dhcpv6.c b/net/dhcpv6.c
index 0d1c600632..73a1067877 100644
--- a/net/dhcpv6.c
+++ b/net/dhcpv6.c
@@ -316,6 +316,11 @@ static void dhcp6_parse_options(uchar *rx_pkt, unsigned
int len)
option_ptr = ((uchar *)option_hdr) + sizeof(struct dhcp6_hdr);
option_len = ntohs(option_hdr->option_len);
+ if (option_ptr + option_len > rx_pkt + len) {
+ debug("Invalid option length\n");
+ return;
+ }
+
switch (ntohs(option_hdr->option_id)) {
case DHCP6_OPTION_CLIENTID:
if (memcmp(option_ptr, sm_params.duid, option_len)
--
2.40.0
[PATCH 0/2] *** minor fixes in DHCP6 ***
From: Sean Edmond Resolves 2 issues: - coverity CID 453851 and 436278 - Change DHCP6 VCI string from "U-boot" to "U-Boot" (this was found by more detailed testing on our end) Sean Edmond (2): net: ipv6: Fix CID 453851 and CID 436278 net: dhcp6: Fix VCI string cmd/net.c| 12 ++-- net/dhcpv6.c | 5 + net/dhcpv6.h | 2 +- 3 files changed, 12 insertions(+), 7 deletions(-) -- 2.40.0
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On 5/18/23 10:06, Conor Dooley wrote: > On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote: >> On Thu, May 18, 2023 at 4:02 PM Andrew Jones wrote: >> > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > >> > > - riscv,isa: >> > > -description: >> > > - Identifies the specific RISC-V instruction set architecture >> > > - supported by the hart. These are documented in the RISC-V >> > > - User-Level ISA document, available from >> > > - https://riscv.org/specifications/ >> > > - >> > > - Due to revisions of the ISA specification, some deviations >> > > - have arisen over time. >> > > - Notably, riscv,isa was defined prior to the creation of the >> > > - Zicsr and Zifencei extensions and thus "i" implies >> > > - "zicsr_zifencei". >> > > - >> > > - While the isa strings in ISA specification are case >> > > - insensitive, letters in the riscv,isa string must be all >> > > - lowercase to simplify parsing. >> > > -$ref: "/schemas/types.yaml#/definitions/string" >> > > -pattern: >> > > ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ >> > > - >> > ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here >> > >timebase-frequency: false >> > > >> > > @@ -133,8 +117,13 @@ properties: >> > >DMIPS/MHz, relative to highest capacity-dmips-mhz >> > >in the system. >> > > >> > > +oneOf: >> > > + - required: >> > > + - riscv,isa >> > >> > This is the part Anup keeps reminding me about. We can create better ways >> > to handle extensions in DT and ACPI, but we'll still need to parse ISA >> > strings to handle legacy DTs and holdouts that keep creating ISA strings, >> > at least during the deprecation period, since ISA strings are still "the >> > way to do it" according to the spec. >> >> Coming up with an alternate way in DT is fine but we can't deprecate >> ISA strings since ISA strings are widely used: >> 1) Various bootloaders > > Aye, for the reason, as I mentioned earlier and in the RFC thread, > removing existing parsers isn't a good idea. > >> 2) It is part of /proc/cpuinfo > > That is irrelevant. > >> 3) Hypervisors use it to communicate HW features to Guest/VM. >> Hypervisors can't get away from generating ISA strings because >> Hypervisors don't know what is running inside Guest/VM. > > Generate both :) As things stand, your guests could interpret what you > communicate to them via riscv,isa differently! > >> In the case of ACPI, it is a very different situation. Like Sunil mentioned, >> ACPI will always follow mechanisms defined by RVI (such as ISA string). >> Other ACPI approaches such as GUID for ISA extension are simply not >> scalable and will take a lot more memory for ACPI tables compared to >> ISA strings. > > My proposal should actually suit ACPI, at least for Linux, as it would > be a chance to align currently misaligned definitions. I won't speak to > GUIDs or whatever as that's someone else's problem :) > >> > Also, if we assume the wording in the spec does get shored up, then, >> > unless I'm missing something, the list of advantages for this boolean >> > proposal from your commit message would be >> >> IMO, we should try our best to have the wordings changed in RVI spec. > > Yes, doing so is beneficial for all of us regardless of what happens > here. I do think that it is partially orthogonal - it allows us to not > design an interface that needs to be capable of communicating a wide > variety of versions, but I don't think it solves some of the issues > that riscv,isa has. If I thought it did, I would not have gone to the > trouble of respinning this patch out of the other approach. > >> > * More character choices for name -- probably not a huge gain for ratified >> > extensions, since the boolean properties will likely still use the same >> > name as the ISA string (riscv,isa-extension-). But, for vendor >> > extensions, this is indeed a major improvement, since vendor extension >> > boolean property names may need to be extended in unambiguous ways to >> > handle changes in the extension. >> > >> > * Simpler, more complete DT validation (but we still need a best effort >> > for legacy ISA strings) >> > >> > * Simpler DT parsing (but we still need the current parser for legacy ISA >> > strings) >> > >> > > + - required: >> > > + - riscv,isa-base >> > > + >> > > required: >> > > - - riscv,isa >> > >- interrupt-controller >> > > >> > > additionalProperties: true >> > > @@ -177,7 +166,13 @@ examples: >> > > i-tlb-size = <32>; >> > > mmu-type = "riscv,sv39"; >> > > reg = <1>; >> > > -riscv,isa = "rv64imafdc"; >> > > +riscv,isa-base = "rv64i"; >> > > +riscv,isa-extension-i; >> > > +riscv,isa-extension-m; >> > > +riscv,isa-extension-a; >> > > +
[PATCH 0/2] IPv6 Network Discovery Boundary Variable and Packed Structure
From: Ehsan Mohandesi This series addresses the following. 1. Coverity Issue (CID 450971): Loop boundary variables should be checked to be within appropriate limits. 2. Making the structure icmp6_ra_prefix_info packed because it contains network protocol data received from the network. Ehsan Mohandesi (2): net: ipv6: router advertisement message length should be within limits net: ipv6: network protocol structures should be packed include/net6.h | 2 +- net/ndisc.c| 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.8.3.1
[PATCH 2/2] net: ipv6: network protocol structures should be packed
From: Ehsan Mohandesi
The structure icmp6_ra_prefix_info needs to be packed because it is read
from a network stream.
Signed-off-by: Ehsan Mohandesi
---
include/net6.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net6.h b/include/net6.h
index beafc05..1e766aa 100644
--- a/include/net6.h
+++ b/include/net6.h
@@ -204,7 +204,7 @@ struct icmp6_ra_prefix_info {
* be initialized to zero by the sender and ignored by the receiver.
*/
struct in6_addr prefix;
-};
+} __packed;
extern struct in6_addr const net_null_addr_ip6;/* NULL IPv6 address */
extern struct in6_addr net_gateway6; /* Our gateways IPv6 address */
--
1.8.3.1
[PATCH 1/2] net: ipv6: router advertisement message length should be within limits
From: Ehsan Mohandesi
The argument len passed to function process_ra is the length of the IPv6
router advertisement message and needs to be between 0 and MTU because
it is assigned to remaining_option_len and used as a loop variable.
Addresses-Coverity-ID: 450971 ("TAINTED_SCALAR")
Signed-off-by: Ehsan Mohandesi
---
net/ndisc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ndisc.c b/net/ndisc.c
index 0b27779..d1cec06 100644
--- a/net/ndisc.c
+++ b/net/ndisc.c
@@ -382,6 +382,8 @@ int process_ra(struct ip6_hdr *ip6, int len)
unsigned char type = 0;
struct icmp6_ra_prefix_info *prefix = NULL;
+ if (len > ETH_MAX_MTU)
+ return -EMSGSIZE;
/* Ignore the packet if router lifetime is 0. */
if (!icmp->icmp6_rt_lifetime)
return -EOPNOTSUPP;
--
1.8.3.1
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 07:41:17AM -0700, Palmer Dabbelt wrote: > On Thu, 18 May 2023 07:06:17 PDT (-0700), Conor Dooley wrote: > > On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote: > > > On Thu, May 18, 2023 at 4:02 PM Andrew Jones > > > wrote: > > > > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > > One downside of this new approach is it will increase the size of DTB. > > > Imaging 50 such DT properties in 46 CPU DT nodes. > > > > I should do a comparison between 50 extensions in riscv,isa and doing > > this 50 times and see what the sizes are. > > I'm not sure how sensitive people are to DT size (presumably it'd be DTB > size)? > > It's also not clear what we can do about it: RISC-V has lots of extensions, > that's going to take encoding space. Sticking with an ambiguous encoding > because it's smaller seems like a way to get burned in the long run. I did actually go an look at this. I cheated a little and renamed the properties to "riscv,isa-ext-foo", which is about as communicative IMO as the longer name I currently have, but may seem more agreeable to the size conscious. I added 30 cpu nodes to mpfs.dtsi, each with 100 extensions of 6 chars long. With just the string, containing "rv64imafdc_zabcde_...", it was unreadable, but "only" took up 46k. I then removed the multiletter extensions from riscv,isa & switched to riscv,isa-base & 100 booleans. IMO it was more readable (although still quite bad!), but took up 62k. Removing all of the boolean properties, leaving me with 30 addtional harts with "rv64imafdc" only, was 26k. I think the generic limit for dtb files is 2 MiB? To me the size increase doesn't sound like a bit problem. signature.asc Description: PGP signature
Re: [PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
On 5/18/23 9:27 AM, Neha Malcom Francis wrote: From: Kamlesh Gurudasani AM64x family of SoCs by default will have some level of security enforcement checking. Enable CONFIG_TI_SECURE_DEVICE by default so all levels of secure SoCs will boot with binman. Signed-off-by: Kamlesh Gurudasani Signed-off-by: Neha Francis Signed-off-by: Neha Malcom Francis --- This fix is independent of the binman changes and should go in first anyway to keep bisectability. Andrew configs/am64x_evm_a53_defconfig | 1 + configs/am64x_evm_r5_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index 4589624e96..09037ecd0f 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SPL_GPIO=y diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig index 023ee638a0..d824298773 100644 --- a/configs/am64x_evm_r5_defconfig +++ b/configs/am64x_evm_r5_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x8 CONFIG_SPL_GPIO=y
Re: [PATCH v4 05/23] j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
On 5/18/23 9:26 AM, Neha Malcom Francis wrote:
By providing entries in the binman node of the device tree, binman will
be able to find and package board config artifacts generated by
TIBoardConfig with sysfw.bin and generate the final image sysfw.itb.
It will also pick out the R5 SPL and sign it with the help of TI signing
entry and generate the final tiboot3.bin.
Entries for A72 build have been added to k3-j721e-binman.dtsi to
generate tispl.bin and u-boot.img.
Support has been added for both HS-SE(SR 1.1), HS-FS(SR 2.0) and GP images
In HS-SE, the encrypted system firmware binary must be signed along with
the signed certificate binary.
tiboot3.bin and sysfw-j721e_sr1_1-hs.itb: For HS-SE devices
tiboot3.bin_fs and sysfw-j721e_sr2-hs-fs.itb: For HS-FS devices
Do we actually need "tiboot3.bin_fs"? It should be identical to "tiboot3.bin".
tiboot3.bin_unsigned and sysfw-j721e-gp-evm.itb: For GP devices
I've been thinking about these filenames and what we use as the defaults.
We have 3 revisions {sr1, sr1_1, sr2) to choose from and each has 3
types {"gp", "hs", "hs-fs"}. Which gives 9 combos. For which the type
GP the does not care about revision (the revisions only effected HS parts,
so all revisions look the same for software on GP parts). The revision
SR1.0 was never widely released on HS-FS nor HS-SE, so those two combos
can also be ignored. This gives:
sysfw-j721e-gp.itb
sysfw-j721e_sr1_1-hs.itb
sysfw-j721e_sr1_1-hs-fs.itb
sysfw-j721e_sr2-hs.itb
sysfw-j721e_sr2-hs-fs.itb
So two are missing.
.bin/img: For HS devices
.bin_unsigned/img_unsigned: For GP devices
I'm not sure we need these two "_unsigned" images, the signature is
trival to strip out if needed and the signed version boots just
fine on GP devices as SPL knows how to strip out the signature
during boot when it detects it is running on a GP device.
None of the above is a big deal and nothing worth holding up this
series over, I'll send patches later after this is taken into -next.
Andrew
Re: [PATCH v3 13/13] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
On 5/18/23 18:39, Jonas Karlman wrote: Add sfc and flash node to device tree and config options to enable support for booting from SPI NOR flash on Radxa ROCK 5 Model B. Similar to RK3568 the BootRom in RK3588 can read all data and look for idbloader at 0x8000, same as on SD and eMMC. Use the rksd format and modify the mkimage offset to generate a bootable u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash. The FIT image is loaded from 0x6. => sf probe SF: Detected mx25u12835f with page size 256 Bytes, erase size 4 KiB, total 16 MiB => load mmc 1:1 1000 u-boot-rockchip-spi.bin 1492992 bytes read in 129 ms (11 MiB/s) => sf update $fileaddr 0 $filesize device 0 offset 0x0, size 0x16c800 1300480 bytes written, 192512 bytes skipped in 11.103s, speed 137694 B/s The BROM_BOOTSOURCE_ID value read back when booting from SPI flash does not match the expected value of 3 (SPINOR) used by other SoCs. Instead a value of 6 is read back, add a new enum value to handle this new bootsource id. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang Tested-by: Eugen Hristev Reviewed-by: Eugen Hristev
[PATCH v3 13/13] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
Add sfc and flash node to device tree and config options to enable
support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
Similar to RK3568 the BootRom in RK3588 can read all data and look for
idbloader at 0x8000, same as on SD and eMMC.
Use the rksd format and modify the mkimage offset to generate a bootable
u-boot-rockchip-spi.bin that can be written to 0x0 of SPI NOR flash. The
FIT image is loaded from 0x6.
=> sf probe
SF: Detected mx25u12835f with page size 256 Bytes, erase size 4 KiB, total 16
MiB
=> load mmc 1:1 1000 u-boot-rockchip-spi.bin
1492992 bytes read in 129 ms (11 MiB/s)
=> sf update $fileaddr 0 $filesize
device 0 offset 0x0, size 0x16c800
1300480 bytes written, 192512 bytes skipped in 11.103s, speed 137694 B/s
The BROM_BOOTSOURCE_ID value read back when booting from SPI flash does
not match the expected value of 3 (SPINOR) used by other SoCs. Instead a
value of 6 is read back, add a new enum value to handle this new
bootsource id.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
---
v3:
- Update commit message
- Rebase on top of u-boot-rockchip master branch
v2:
- Add and use BROM_BOOTSOURCE_SPINOR_RK3588 enum value
- Rebased to resolve conflicts
- Collect r-b tag
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
arch/arm/dts/rk3588s-u-boot.dtsi | 20
arch/arm/include/asm/arch-rockchip/bootrom.h | 1 +
arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
configs/rock5b-rk3588_defconfig | 10
5 files changed, 56 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index db342e6a9391..1cd8a57a6fa6 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -11,6 +11,7 @@
/ {
aliases {
mmc1 =
+ spi0 =
};
chosen {
@@ -54,6 +55,10 @@
bootph-all;
};
+_pins {
+ bootph-all;
+};
+
{
pinctrl-names = "default";
pinctrl-0 = <_pins _reset_h>;
@@ -123,6 +128,25 @@
pinctrl-0 = <_bus8 _clk _cmd _data_strobe
_rstnout>;
};
+ {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ bootph-pre-ram;
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2400>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ };
+};
+
_xfer {
bootph-all;
};
diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi b/arch/arm/dts/rk3588s-u-boot.dtsi
index 4fdf97ccac44..c703e41802b6 100644
--- a/arch/arm/dts/rk3588s-u-boot.dtsi
+++ b/arch/arm/dts/rk3588s-u-boot.dtsi
@@ -165,6 +165,15 @@
};
};
+ sfc: spi@fe2b {
+ compatible = "rockchip,sfc";
+ reg = <0x0 0xfe2b 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_SFC>, < HCLK_SFC>;
+ clock-names = "clk_sfc", "hclk_sfc";
+ status = "disabled";
+ };
+
otp: nvmem@fecc {
compatible = "rockchip,rk3588-otp";
reg = <0x0 0xfecc 0x0 0x400>;
@@ -242,3 +251,14 @@
{
bootph-pre-ram;
};
+
+#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
+ {
+ simple-bin-spi {
+ mkimage {
+ args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
+ offset = <0x8000>;
+ };
+ };
+};
+#endif
diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
b/arch/arm/include/asm/arch-rockchip/bootrom.h
index 4276a0f6811a..7dab18fbc3fb 100644
--- a/arch/arm/include/asm/arch-rockchip/bootrom.h
+++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
@@ -48,6 +48,7 @@ enum {
BROM_BOOTSOURCE_SPINOR = 3,
BROM_BOOTSOURCE_SPINAND = 4,
BROM_BOOTSOURCE_SD = 5,
+ BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
BROM_BOOTSOURCE_USB = 10,
BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
};
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index 18e67b5ca9b2..b1f535fad505 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -41,6 +41,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
+ [BROM_BOOTSOURCE_SPINOR_RK3588] = "/spi@fe2b/flash@0",
};
static struct mm_region rk3588_mem_map[] = {
diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index e2d5f9c10650..c1155c20efa8 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -8,15 +8,20 @@
Re: [PATCH 1/1] fs: fix smh_fs_read_at()
On 5/17/23 06:23, Heinrich Schuchardt wrote:
> The return value of smh_flen() is written to size and not to ret. But ret
> is checked. We can avoid calling smh_flen() by setting maxsize to LONG_MAX
> if it is not set yet.
>
> Check input parameters.
>
> Fixes: f676b45151c3 ("fs: Add semihosting filesystem")
> Signed-off-by: Heinrich Schuchardt
> ---
> fs/semihostingfs.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/fs/semihostingfs.c b/fs/semihostingfs.c
> index 96eb3349a2..8a7d4da884 100644
> --- a/fs/semihostingfs.c
> +++ b/fs/semihostingfs.c
> @@ -25,6 +25,9 @@ static int smh_fs_read_at(const char *filename, loff_t pos,
> void *buffer,
> {
> long fd, size, ret;
>
> + if (pos > LONG_MAX || maxsize > LONG_MAX)
Should be ULONG_MAX. The type should really be ulong but isn't.
> + return -EINVAL;
> +
> fd = smh_open(filename, MODE_READ | MODE_BINARY);
> if (fd < 0)
> return fd;
> @@ -33,15 +36,8 @@ static int smh_fs_read_at(const char *filename, loff_t
> pos, void *buffer,
> smh_close(fd);
> return ret;
> }
> - if (!maxsize) {
> - size = smh_flen(fd);
> - if (ret < 0) {
> - smh_close(fd);
> - return size;
> - }
> -
> - maxsize = size;
> - }
> + if (!maxsize)
> + maxsize = LONG_MAX;
Same here.
>
> size = smh_read(fd, buffer, maxsize);
> smh_close(fd);
This interface is nuts, but this patch does successfully implement it...
--Sean
[PULL] u-boot-usb/next
The following changes since commit 5d0b3dde115b0d26d414199678983d01b738ad1b: Merge branch '2023-05-15-build-system-updates' into next (2023-05-15 15:26:54 -0400) are available in the Git repository at: git://source.denx.de/u-boot-usb.git next for you to fetch changes up to da83ada02a2684f743fadaf3b915e92f83d74628: usb: gadget: Add and use matching SPL USB ethernet gadget Kconfig symbols (2023-05-17 01:51:39 +0200) Marek Vasut (4): usb: Move SPL_USB_HOST Kconfig symbol to drivers/usb/ usb: Move SPL_USB_STORAGE Kconfig symbol to drivers/usb/ usb: Move SPL_USB_GADGET and related Kconfig symbols to drivers/usb/ usb: gadget: Add and use matching SPL USB ethernet gadget Kconfig symbols common/spl/Kconfig | 90 - drivers/usb/Kconfig | 22 +++ drivers/usb/gadget/Kconfig | 88 drivers/usb/gadget/Makefile | 8 ++-- drivers/usb/host/Kconfig| 13 +++ 5 files changed, 126 insertions(+), 95 deletions(-)
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, 18 May 2023 07:06:17 PDT (-0700), Conor Dooley wrote: On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote: On Thu, May 18, 2023 at 4:02 PM Andrew Jones wrote: > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > - riscv,isa: > > -description: > > - Identifies the specific RISC-V instruction set architecture > > - supported by the hart. These are documented in the RISC-V > > - User-Level ISA document, available from > > - https://riscv.org/specifications/ > > - > > - Due to revisions of the ISA specification, some deviations > > - have arisen over time. > > - Notably, riscv,isa was defined prior to the creation of the > > - Zicsr and Zifencei extensions and thus "i" implies > > - "zicsr_zifencei". > > - > > - While the isa strings in ISA specification are case > > - insensitive, letters in the riscv,isa string must be all > > - lowercase to simplify parsing. > > -$ref: "/schemas/types.yaml#/definitions/string" > > -pattern: ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ > > - > ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here > >timebase-frequency: false > > > > @@ -133,8 +117,13 @@ properties: > >DMIPS/MHz, relative to highest capacity-dmips-mhz > >in the system. > > > > +oneOf: > > + - required: > > + - riscv,isa > > This is the part Anup keeps reminding me about. We can create better ways > to handle extensions in DT and ACPI, but we'll still need to parse ISA > strings to handle legacy DTs and holdouts that keep creating ISA strings, > at least during the deprecation period, since ISA strings are still "the > way to do it" according to the spec. Coming up with an alternate way in DT is fine but we can't deprecate ISA strings since ISA strings are widely used: 1) Various bootloaders Aye, for the reason, as I mentioned earlier and in the RFC thread, removing existing parsers isn't a good idea. Removing and deprecating are different. We can deprecate stuff. 2) It is part of /proc/cpuinfo That is irrelevant. 3) Hypervisors use it to communicate HW features to Guest/VM. Hypervisors can't get away from generating ISA strings because Hypervisors don't know what is running inside Guest/VM. Generate both :) As things stand, your guests could interpret what you communicate to them via riscv,isa differently! In the case of ACPI, it is a very different situation. Like Sunil mentioned, ACPI will always follow mechanisms defined by RVI (such as ISA string). Other ACPI approaches such as GUID for ISA extension are simply not scalable and will take a lot more memory for ACPI tables compared to ISA strings. My proposal should actually suit ACPI, at least for Linux, as it would be a chance to align currently misaligned definitions. I won't speak to GUIDs or whatever as that's someone else's problem :) We talked a bit in the patchwork meeting with Drew about ACPI. Any actual spec/encoding would need to be different, of course, but conceptually it seems to fit fine. It's also broadly similar to what we've done with riscv_hwprobe() for userspace, which is nice. > Also, if we assume the wording in the spec does get shored up, then, > unless I'm missing something, the list of advantages for this boolean > proposal from your commit message would be IMO, we should try our best to have the wordings changed in RVI spec. Yes, doing so is beneficial for all of us regardless of what happens here. I do think that it is partially orthogonal - it allows us to not design an interface that needs to be capable of communicating a wide variety of versions, but I don't think it solves some of the issues that riscv,isa has. If I thought it did, I would not have gone to the trouble of respinning this patch out of the other approach. > * More character choices for name -- probably not a huge gain for ratified > extensions, since the boolean properties will likely still use the same > name as the ISA string (riscv,isa-extension-). But, for vendor > extensions, this is indeed a major improvement, since vendor extension > boolean property names may need to be extended in unambiguous ways to > handle changes in the extension. > > * Simpler, more complete DT validation (but we still need a best effort > for legacy ISA strings) > > * Simpler DT parsing (but we still need the current parser for legacy ISA > strings) > > > + - required: > > + - riscv,isa-base > > + > > required: > > - - riscv,isa > >- interrupt-controller > > > > additionalProperties: true > > @@ -177,7 +166,13 @@ examples: > > i-tlb-size = <32>; > > mmu-type = "riscv,sv39"; > > reg = <1>; > > -riscv,isa = "rv64imafdc"; > > +riscv,isa-base = "rv64i"; > > +riscv,isa-extension-i; > > +riscv,isa-extension-m; > > +
[PATCH v4 22/23] CI: Make use of buildman requirements.txt
From: Tom Rini
Now that buildman has a requirements.txt file we need to make use of it.
Signed-off-by: Tom Rini
Reviewed-by: Simon Glass
[n-fran...@ti.com: Adding missing command from .azure-pipelines.yml]
Signed-off-by: Neha Malcom Francis
---
.azure-pipelines.yml | 4
.gitlab-ci.yml | 4
2 files changed, 8 insertions(+)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 3c1846a5bc..ea49430bf6 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -162,6 +162,7 @@ stages:
virtualenv -p /usr/bin/python3 /tmp/venv
. /tmp/venv/bin/activate
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl
export PYTHONPATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt
export PATH=${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}
@@ -209,6 +210,7 @@ stages:
git config --global --add safe.directory $(work_dir)
export USER=azure
pip install -r test/py/requirements.txt
+ pip install -r tools/buildman/requirements.txt
pip install asteval pylint==2.12.2 pyopenssl
export PATH=${PATH}:~/.local/bin
echo "[MASTER]" >> .pylintrc
@@ -404,6 +406,7 @@ stages:
if [ -n "${BUILD_ENV}" ]; then
export ${BUILD_ENV};
fi
+ pip install -r tools/buildman/requirements.txt
tools/buildman/buildman -o ${UBOOT_TRAVIS_BUILD_DIR} -w -E -W -e
--board ${TEST_PY_BD} ${OVERRIDE}
cp ~/grub_x86.efi ${UBOOT_TRAVIS_BUILD_DIR}/
cp ~/grub_x64.efi ${UBOOT_TRAVIS_BUILD_DIR}/
@@ -581,6 +584,7 @@ stages:
# make environment variables available as tests are running inside a
container
export BUILDMAN="${BUILDMAN}"
git config --global --add safe.directory ${WORK_DIR}
+ pip install -r tools/buildman/requirements.txt
EOF
cat << "EOF" >> build.sh
if [[ "${BUILDMAN}" != "" ]]; then
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index e6c6ab3586..7cf2eaef64 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -97,6 +97,7 @@ build all 32bit ARM platforms:
script:
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM arm -x aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -110,6 +111,7 @@ build all 64bit ARM platforms:
- . /tmp/venv/bin/activate
- ret=0;
git config --global --add safe.directory "${CI_PROJECT_DIR}";
+ pip install -r tools/buildman/requirements.txt;
./tools/buildman/buildman -o /tmp -PEWM aarch64 || ret=$?;
if [[ $ret -ne 0 ]]; then
./tools/buildman/buildman -o /tmp -seP;
@@ -208,6 +210,7 @@ Run binman, buildman, dtoc, Kconfig and patman testsuites:
virtualenv -p /usr/bin/python3 /tmp/venv;
. /tmp/venv/bin/activate;
pip install -r test/py/requirements.txt;
+ pip install -r tools/buildman/requirements.txt;
export UBOOT_TRAVIS_BUILD_DIR=/tmp/sandbox_spl;
export PYTHONPATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc/pylibfdt";
export PATH="${UBOOT_TRAVIS_BUILD_DIR}/scripts/dtc:${PATH}";
@@ -240,6 +243,7 @@ Run pylint:
script:
- git config --global --add safe.directory "${CI_PROJECT_DIR}"
- pip install -r test/py/requirements.txt
+- pip install -r tools/buildman/requirements.txt
- pip install asteval pylint==2.12.2 pyopenssl
- export PATH=${PATH}:~/.local/bin
- echo "[MASTER]" >> .pylintrc
--
2.34.1
[PATCH v4 23/23] configs: am64x: Enable TI_SECURE_DEV options
From: Kamlesh Gurudasani AM64x family of SoCs by default will have some level of security enforcement checking. Enable CONFIG_TI_SECURE_DEVICE by default so all levels of secure SoCs will boot with binman. Signed-off-by: Kamlesh Gurudasani Signed-off-by: Neha Francis Signed-off-by: Neha Malcom Francis --- configs/am64x_evm_a53_defconfig | 1 + configs/am64x_evm_r5_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/am64x_evm_a53_defconfig b/configs/am64x_evm_a53_defconfig index 4589624e96..09037ecd0f 100644 --- a/configs/am64x_evm_a53_defconfig +++ b/configs/am64x_evm_a53_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SKIP_LOWLEVEL_INIT=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x8000 CONFIG_SPL_GPIO=y diff --git a/configs/am64x_evm_r5_defconfig b/configs/am64x_evm_r5_defconfig index 023ee638a0..d824298773 100644 --- a/configs/am64x_evm_r5_defconfig +++ b/configs/am64x_evm_r5_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARCH_K3=y +CONFIG_TI_SECURE_DEVICE=y CONFIG_SYS_MALLOC_LEN=0x200 CONFIG_SYS_MALLOC_F_LEN=0x8 CONFIG_SPL_GPIO=y -- 2.34.1
[PATCH v4 21/23] buildman: Create a requirements.txt file
From: Tom Rini At this point, buildman requires a few different modules and so we need a requirements.txt to track what modules are needed. Cc: Simon Glass Cc: Neha Malcom Francis Signed-off-by: Tom Rini Reviewed-by: Simon Glass Signed-off-by: Neha Malcom Francis --- tools/buildman/requirements.txt | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 tools/buildman/requirements.txt diff --git a/tools/buildman/requirements.txt b/tools/buildman/requirements.txt new file mode 100644 index 00..a1efcb9d4b --- /dev/null +++ b/tools/buildman/requirements.txt @@ -0,0 +1,2 @@ +jsonschema==4.17.3 +pyyaml==6.0 -- 2.34.1
[PATCH v4 20/23] doc: board: ti: Update documentation for binman flow
Earlier documentation specified builds for generating bootloader images using an external TI repository k3-image-gen and core-secdev-k3. Modify this to using the binman flow so that user understands how to build the final boot images. Signed-off-by: Neha Malcom Francis Reviewed-by: Simon Glass --- doc/board/ti/am62x_sk.rst | 42 - doc/board/ti/j721e_evm.rst | 50 +--- doc/board/ti/k3.rst| 95 +- 3 files changed, 73 insertions(+), 114 deletions(-) diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index 27d7b527c6..e4d58b4958 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -115,23 +115,19 @@ Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master -5. TI Linux Firmware: +4. TI Linux Firmware: Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git Branch: ti-linux-firmware @@ -139,35 +135,37 @@ Build procedure: 1. ATF: -.. code-block:: text +.. code-block:: bash - $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=lite SPD=opteed + $ make CROSS_COMPILE=aarch64-none-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=lite SPD=opteed 2. OPTEE: -.. code-block:: text +.. code-block:: bash - $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- CROSS_COMPILE64=aarch64-none-linux-gnu- + $ make PLATFORM=k3 CFG_ARM64_core=y CROSS_COMPILE=arm-none-linux-gnueabihf- \ +CROSS_COMPILE64=aarch64-none-linux-gnu- 3. U-Boot: * 3.1 R5: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- am62x_evm_r5_defconfig O=/tmp/r5 - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- O=/tmp/r5 - $ cd - $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- SOC=am62x SBL=/tmp/r5/spl/u-boot-spl.bin SYSFW_PATH=/ti-sysfw/ti-fs-firmware-am62x-gp.bin - -Use the tiboot3.bin generated from last command + $ make ARCH=arm am62x_evm_r5_defconfig + $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabihf- \ +BINMAN_INDIRS= * 3.2 A53: -.. code-block:: text +.. code-block:: bash - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- am62x_evm_a53_defconfig O=/tmp/a53 - $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- ATF=/build/k3/lite/release/bl31.bin TEE=/out/arm-plat-k3/core/tee-pager_v2.bin DM=/ti-dm/am62xx/ipc_echo_testb_mcu1_0_release_strip.xer5f O=/tmp/a53 + $ make ARCH=arm am62x_evm_a53_defconfig + $ make ARCH=arm CROSS_COMPILE=aarch64-none-linux-gnu- \ +BL31=/build/k3/lite/release/bl31.bin \ +TEE=/out/arm-plat-k3/core/tee-pager_v2.bin \ +BINMAN_INDIRS= Target Images -- diff --git a/doc/board/ti/j721e_evm.rst b/doc/board/ti/j721e_evm.rst index e898601c41..3ff66bd1b4 100644 --- a/doc/board/ti/j721e_evm.rst +++ b/doc/board/ti/j721e_evm.rst @@ -130,67 +130,61 @@ support. Below is the pictorial representation of boot flow: Sources: -1. SYSFW: - Tree: git://git.ti.com/k3-image-gen/k3-image-gen.git - Branch: master - -2. ATF: +1. ATF: Tree: https://github.com/ARM-software/arm-trusted-firmware.git Branch: master -3. OPTEE: +2. OPTEE: Tree: https://github.com/OP-TEE/optee_os.git Branch: master -4. DM Firmware: - Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git - Branch: ti-linux-firmware - -5. U-Boot: +3. U-Boot: Tree: https://source.denx.de/u-boot/u-boot Branch: master +4. TI Linux Firmware: + Tree: git://git.ti.com/processor-firmware/ti-linux-firmware.git + Branch: ti-linux-firmware + Build procedure: -1. SYSFW: - -.. code-block:: bash - -make CROSS_COMPILE=arm-linux-gnueabihf- SOC=j721e - -2. ATF: +1. ATF: .. code-block:: bash -make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 TARGET_BOARD=generic SPD=opteed + $ make CROSS_COMPILE=aarch64-linux-gnu- ARCH=aarch64 PLAT=k3 \ +TARGET_BOARD=generic SPD=opteed -3. OPTEE: +2. OPTEE: .. code-block:: bash -make PLATFORM=k3-j721e CFG_ARM64_core=y + $ make PLATFORM=k3-j721e CFG_ARM64_core=y -4. U-Boot: +3. U-Boot: * 4.1 R5: .. code-block:: bash -make CROSS_COMPILE=arm-linux-gnueabihf- j721e_evm_r5_defconfig O=build/r5 -make CROSS_COMPILE=arm-linux-gnueabihf- O=build/r5 + $ make j721e_evm_r5_defconfig + $ make CROSS_COMPILE=arm-linux-gnueabihf- \ +BINMAN_INDIRS= * 4.2 A72: .. code-block:: bash -make
[PATCH v4 19/23] k3: tools: config.mk: Update makefile and remove scripts
Since binman is used to package bootloader images for all K3 devices, we
do not have to rely on the earlier methods to package them.
Scripts that were used to generate x509 certificate for tiboot3.bin and
generate tispl.bin, u-boot.img have been removed.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/mach-k3/config.mk | 101 --
tools/k3_fit_atf.sh| 123 -
tools/k3_gen_x509_cert.sh | 262 -
3 files changed, 486 deletions(-)
delete mode 100644 arch/arm/mach-k3/config.mk
delete mode 100755 tools/k3_fit_atf.sh
delete mode 100755 tools/k3_gen_x509_cert.sh
diff --git a/arch/arm/mach-k3/config.mk b/arch/arm/mach-k3/config.mk
deleted file mode 100644
index 9306f2627d..00
--- a/arch/arm/mach-k3/config.mk
+++ /dev/null
@@ -1,101 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0+
-#
-# Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
-# Lokesh Vutla
-
-ifdef CONFIG_SPL_BUILD
-
-# Openssl is required to generate x509 certificate.
-# Error out if openssl is not available.
-ifeq ($(shell which openssl),)
-$(error "No openssl in $(PATH), consider installing openssl")
-endif
-
-IMAGE_SIZE= $(shell cat $(obj)/u-boot-spl.bin | wc -c)
-MAX_SIZE= $(shell printf "%d" $(CONFIG_SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE))
-
-ifeq ($(CONFIG_SYS_K3_KEY), "")
-KEY=""
-# On HS use real key or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/custMpk.pem),)
-KEY=$(TI_SECURE_DEV_PKG)/keys/custMpk.pem
-else
-$(warning "WARNING: signing key not found. Random key will NOT work on HS
hardware!")
-endif
-endif
-else
-KEY=$(patsubst "%",$(srctree)/%,$(CONFIG_SYS_K3_KEY))
-endif
-
-# X509 SWRV default
-SWRV = $(CONFIG_K3_X509_SWRV)
-# On HS use SECDEV provided software revision or warn if not available
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-ifneq ($(wildcard $(TI_SECURE_DEV_PKG)/keys/swrv.txt),)
-SWRV= $(shell cat $(TI_SECURE_DEV_PKG)/keys/swrv.txt)
-else
-$(warning "WARNING: Software revision file not found. Default may not work on
HS hardware.")
-endif
-endif
-
-# tiboot3.bin is mandated by ROM and ROM only supports R5 boot.
-# So restrict tiboot3.bin creation for CPU_V7R.
-ifdef CONFIG_CPU_V7R
-image_check: $(obj)/u-boot-spl.bin FORCE
- @if [ $(IMAGE_SIZE) -gt $(MAX_SIZE) ]; then \
- echo "===" >&2; \
- echo "ERROR: Final Image too big. " >&2;\
- echo "$< size = $(IMAGE_SIZE), max size = $(MAX_SIZE)" >&2; \
- echo "===" >&2; \
- exit 1; \
- fi
-
-tiboot3.bin: image_check FORCE
- $(srctree)/tools/k3_gen_x509_cert.sh -c 16 -b $(obj)/u-boot-spl.bin \
- -o $@ -l $(CONFIG_SPL_TEXT_BASE) -r $(SWRV) -k
$(KEY)
-
-INPUTS-y += tiboot3.bin
-endif
-
-ifdef CONFIG_ARM64
-
-ifeq ($(CONFIG_SOC_K3_J721E),)
-export DM := /dev/null
-endif
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-SPL_ITS := u-boot-spl-k3_HS.its
-$(SPL_ITS): export IS_HS=1
-INPUTS-y += tispl.bin_HS
-else
-SPL_ITS := u-boot-spl-k3.its
-INPUTS-y += tispl.bin
-endif
-
-ifeq ($(CONFIG_SPL_OF_LIST),)
-LIST_OF_DTB := $(CONFIG_DEFAULT_DEVICE_TREE)
-else
-LIST_OF_DTB := $(CONFIG_SPL_OF_LIST)
-endif
-
-quiet_cmd_k3_mkits = MKITS $@
-cmd_k3_mkits = \
- $(srctree)/tools/k3_fit_atf.sh \
- $(CONFIG_K3_ATF_LOAD_ADDR) \
- $(patsubst %,$(obj)/dts/%.dtb,$(subst ",,$(LIST_OF_DTB))) > $@
-
-$(SPL_ITS): FORCE
- $(call cmd,k3_mkits)
-endif
-
-else
-
-ifeq ($(CONFIG_TI_SECURE_DEVICE),y)
-INPUTS-y += u-boot.img_HS
-else
-INPUTS-y += u-boot.img
-endif
-endif
-
-include $(srctree)/arch/arm/mach-k3/config_secure.mk
diff --git a/tools/k3_fit_atf.sh b/tools/k3_fit_atf.sh
deleted file mode 100755
index 7bc07ad074..00
--- a/tools/k3_fit_atf.sh
+++ /dev/null
@@ -1,123 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0+
-#
-# script to generate FIT image source for K3 Family boards with
-# ATF, OPTEE, SPL and multiple device trees (given on the command line).
-# Inspired from board/sunxi/mksunxi_fit_atf.sh
-#
-# usage: $0 [ [&2
- ATF=/dev/null
-fi
-
-[ -z "$TEE" ] && TEE="bl32.bin"
-
-if [ ! -f $TEE ]; then
- echo "WARNING OPTEE file $TEE NOT found, resulting might be
non-functional" >&2
- TEE=/dev/null
-fi
-
-[ -z "$DM" ] && DM="dm.bin"
-
-if [ ! -e $DM ]; then
- echo "WARNING DM file $DM NOT found, resulting might be non-functional"
>&2
- DM=/dev/null
-fi
-
-if [ ! -z "$IS_HS" ]; then
- HS_APPEND=_HS
-fi
-
-cat << __HEADER_EOF
-/dts-v1/;
-
-/ {
- description = "Configuration to load ATF and SPL";
- #address-cells = <1>;
-
- images {
- atf {
- description = "ARM Trusted
[PATCH v4 17/23] am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
Support added for HS and GP boot binaries for AM62ax.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned and u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by AM62ax requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-am62a-sk-binman.dtsi | 461 +++
arch/arm/dts/k3-am62a7-r5-sk.dts | 1 +
arch/arm/dts/k3-am62a7-sk.dts| 1 +
board/ti/am62ax/Kconfig | 2 +
4 files changed, 465 insertions(+)
create mode 100644 arch/arm/dts/k3-am62a-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am62a-sk-binman.dtsi
b/arch/arm/dts/k3-am62a-sk-binman.dtsi
new file mode 100644
index 00..c249c8574d
--- /dev/null
+++ b/arch/arm/dts/k3-am62a-sk-binman.dtsi
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM62A7_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62ax-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3_fs {
+ filename = "tiboot3.bin_fs";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-am62ax-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert_fs: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-fs-firmware-am62ax-hs-fs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg_fs: combined-dm-cfg.bin {
+
[PATCH v4 18/23] arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050
Move to using binman to generate tispl.bin which is used to generate the
final flash.bin bootloader for iot2050 boards.
Signed-off-by: Neha Malcom Francis
Cc: Jan Kiszka
---
arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +++-
1 file changed, 74 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
index 03ccc54329..9d83898d33 100644
--- a/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
+++ b/arch/arm/dts/k3-am65-iot2050-boot-image.dtsi
@@ -26,9 +26,81 @@
missing-msg = "iot2050-seboot";
};
- blob@0x18 {
+ fit@0x18 {
offset = <0x18>;
- filename = "tispl.bin";
+ pad-byte = <0xff>;
+ description = "Configuration to load ATF and SPL";
+
+ images {
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = ;
+ entry = ;
+ atf: atf-bl31 {
+ };
+ };
+
+ tee {
+ description = "OPTEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <0x9e80>;
+ entry = <0x9e80>;
+ tee: tee-os {
+ };
+ };
+
+ dm {
+ description = "DM binary";
+ type = "firmware";
+ arch = "arm32";
+ compression = "none";
+ os = "DM";
+ load = <0x8900>;
+ entry = <0x8900>;
+ blob-ext {
+ filename = "/dev/null";
+ };
+ };
+
+ spl {
+ description = "SPL (64-bit)";
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = ;
+ entry = ;
+ u_boot_spl_nodtb: blob-ext {
+ filename =
"spl/u-boot-spl-nodtb.bin";
+ };
+ };
+
+ fdt-0 {
+ description = "k3-am65-iot2050-spl.dtb";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+ spl_am65x_evm_dtb: blob-ext {
+ filename =
"spl/dts/k3-am65-iot2050-spl.dtb";
+ };
+ };
+ };
+
+ configurations {
+ default = "spl";
+ spl {
+ fdt = "fdt-0";
+ firmware = "atf";
+ loadables = "tee", "dm", "spl";
+ };
+ };
};
fit@0x38 {
--
2.34.1
[PATCH v4 16/23] am62a: yaml: Add board configs for AM62ax
Added YAML configs for AM62ax Signed-off-by: Neha Malcom Francis --- board/ti/am62ax/board-cfg.yaml | 36 + board/ti/am62ax/pm-cfg.yaml| 12 + board/ti/am62ax/rm-cfg.yaml| 1151 board/ti/am62ax/sec-cfg.yaml | 375 +++ 4 files changed, 1574 insertions(+) create mode 100644 board/ti/am62ax/board-cfg.yaml create mode 100644 board/ti/am62ax/pm-cfg.yaml create mode 100644 board/ti/am62ax/rm-cfg.yaml create mode 100644 board/ti/am62ax/sec-cfg.yaml diff --git a/board/ti/am62ax/board-cfg.yaml b/board/ti/am62ax/board-cfg.yaml new file mode 100644 index 00..6e45b494e0 --- /dev/null +++ b/board/ti/am62ax/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62ax +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62ax/pm-cfg.yaml b/board/ti/am62ax/pm-cfg.yaml new file mode 100644 index 00..a491f11260 --- /dev/null +++ b/board/ti/am62ax/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62ax +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62ax/rm-cfg.yaml b/board/ti/am62ax/rm-cfg.yaml new file mode 100644 index 00..f7315dd2b0 --- /dev/null +++ b/board/ti/am62ax/rm-cfg.yaml @@ -0,0 +1,1151 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62ax +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +
[PATCH v4 15/23] am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support added for HS and GP boot binaries for AM62
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by AM62 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-am625-r5-sk.dts | 1 +
arch/arm/dts/k3-am625-sk-binman.dtsi | 462 +++
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 2 +
board/ti/am62x/Kconfig | 2 +
4 files changed, 467 insertions(+)
create mode 100644 arch/arm/dts/k3-am625-sk-binman.dtsi
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
index 78df7cec3f..3ec5bad735 100644
--- a/arch/arm/dts/k3-am625-r5-sk.dts
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -9,6 +9,7 @@
#include "k3-am62-ddr.dtsi"
#include "k3-am625-sk-u-boot.dtsi"
+#include "k3-am625-sk-binman.dtsi"
/ {
aliases {
diff --git a/arch/arm/dts/k3-am625-sk-binman.dtsi
b/arch/arm/dts/k3-am625-sk-binman.dtsi
new file mode 100644
index 00..70798a5c0a
--- /dev/null
+++ b/arch/arm/dts/k3-am625-sk-binman.dtsi
@@ -0,0 +1,462 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM625_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-am62x-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3_fs {
+ filename = "tiboot3.bin_fs";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x43c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x43c3a800>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-am62x-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
[PATCH v4 14/23] am62: yaml: Add board configs for AM62
Added YAML configs for AM62 Signed-off-by: Neha Malcom Francis --- board/ti/am62x/board-cfg.yaml | 36 ++ board/ti/am62x/pm-cfg.yaml| 12 + board/ti/am62x/rm-cfg.yaml| 1088 + board/ti/am62x/sec-cfg.yaml | 375 4 files changed, 1511 insertions(+) create mode 100644 board/ti/am62x/board-cfg.yaml create mode 100644 board/ti/am62x/pm-cfg.yaml create mode 100644 board/ti/am62x/rm-cfg.yaml create mode 100644 board/ti/am62x/sec-cfg.yaml diff --git a/board/ti/am62x/board-cfg.yaml b/board/ti/am62x/board-cfg.yaml new file mode 100644 index 00..a26ef55bd4 --- /dev/null +++ b/board/ti/am62x/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM62 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am62x/pm-cfg.yaml b/board/ti/am62x/pm-cfg.yaml new file mode 100644 index 00..aa94097e97 --- /dev/null +++ b/board/ti/am62x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM62 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am62x/rm-cfg.yaml b/board/ti/am62x/rm-cfg.yaml new file mode 100644 index 00..ba82146551 --- /dev/null +++ b/board/ti/am62x/rm-cfg.yaml @@ -0,0 +1,1088 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM62 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0
[PATCH v4 12/23] j721s2: yaml: Add board configs for J721S2
Added YAML configs for J721S2 Signed-off-by: Neha Malcom Francis --- board/ti/j721s2/board-cfg.yaml | 37 + board/ti/j721s2/pm-cfg.yaml| 12 + board/ti/j721s2/rm-cfg.yaml| 2901 board/ti/j721s2/sec-cfg.yaml | 375 + 4 files changed, 3325 insertions(+) create mode 100644 board/ti/j721s2/board-cfg.yaml create mode 100644 board/ti/j721s2/pm-cfg.yaml create mode 100644 board/ti/j721s2/rm-cfg.yaml create mode 100644 board/ti/j721s2/sec-cfg.yaml diff --git a/board/ti/j721s2/board-cfg.yaml b/board/ti/j721s2/board-cfg.yaml new file mode 100644 index 00..d80f308ca6 --- /dev/null +++ b/board/ti/j721s2/board-cfg.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for J721S2 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 + diff --git a/board/ti/j721s2/pm-cfg.yaml b/board/ti/j721s2/pm-cfg.yaml new file mode 100644 index 00..45994e23cc --- /dev/null +++ b/board/ti/j721s2/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for J721S2 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/j721s2/rm-cfg.yaml b/board/ti/j721s2/rm-cfg.yaml new file mode 100644 index 00..d18288ae08 --- /dev/null +++ b/board/ti/j721s2/rm-cfg.yaml @@ -0,0 +1,2901 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for J721S2 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 21 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #6 +host_id: 23 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #7 +host_id: 35 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #8 +host_id: 37 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #9 +host_id: 40 +allowed_atype : 0x2A +
[PATCH v4 13/23] j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img
Support added for HS and GP boot binaries for J721S2.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by J721S2 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-j721s2-binman.dtsi| 545 ++
.../k3-j721s2-common-proc-board-u-boot.dtsi | 2 +
.../dts/k3-j721s2-r5-common-proc-board.dts| 1 +
board/ti/j721s2/Kconfig | 2 +
4 files changed, 550 insertions(+)
create mode 100644 arch/arm/dts/k3-j721s2-binman.dtsi
diff --git a/arch/arm/dts/k3-j721s2-binman.dtsi
b/arch/arm/dts/k3-j721s2-binman.dtsi
new file mode 100644
index 00..2f53783f2b
--- /dev/null
+++ b/arch/arm/dts/k3-j721s2-binman.dtsi
@@ -0,0 +1,545 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J721S2_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j721s2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3_fs {
+ filename = "tiboot3.bin_fs";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x67000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721s2-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg_fs: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert_fs: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-fs-firmware-j721s2-hs-fs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg_fs:
[PATCH v4 10/23] am64x: yaml: Add board configs for AM64x
Added YAML configs for AM64xx Signed-off-by: Neha Malcom Francis --- board/ti/am64x/board-cfg.yaml | 37 + board/ti/am64x/pm-cfg.yaml| 12 + board/ti/am64x/rm-cfg.yaml| 1400 + board/ti/am64x/sec-cfg.yaml | 378 + 4 files changed, 1827 insertions(+) create mode 100644 board/ti/am64x/board-cfg.yaml create mode 100644 board/ti/am64x/pm-cfg.yaml create mode 100644 board/ti/am64x/rm-cfg.yaml create mode 100644 board/ti/am64x/sec-cfg.yaml diff --git a/board/ti/am64x/board-cfg.yaml b/board/ti/am64x/board-cfg.yaml new file mode 100644 index 00..f1f7c68d50 --- /dev/null +++ b/board/ti/am64x/board-cfg.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM64x +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x0 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 + diff --git a/board/ti/am64x/pm-cfg.yaml b/board/ti/am64x/pm-cfg.yaml new file mode 100644 index 00..c97495f482 --- /dev/null +++ b/board/ti/am64x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM64x +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am64x/rm-cfg.yaml b/board/ti/am64x/rm-cfg.yaml new file mode 100644 index 00..6488c8a9c5 --- /dev/null +++ b/board/ti/am64x/rm-cfg.yaml @@ -0,0 +1,1400 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM64x +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 30 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 36 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 38 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 41 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +
[PATCH v4 08/23] am65x: yaml: Add AM65x board config files
Added YAML configs for AM65x Signed-off-by: Neha Malcom Francis --- board/ti/am65x/board-cfg.yaml | 36 + board/ti/am65x/pm-cfg.yaml| 12 + board/ti/am65x/rm-cfg.yaml| 2068 + board/ti/am65x/sec-cfg.yaml | 375 ++ 4 files changed, 2491 insertions(+) create mode 100644 board/ti/am65x/board-cfg.yaml create mode 100644 board/ti/am65x/pm-cfg.yaml create mode 100644 board/ti/am65x/rm-cfg.yaml create mode 100644 board/ti/am65x/sec-cfg.yaml diff --git a/board/ti/am65x/board-cfg.yaml b/board/ti/am65x/board-cfg.yaml new file mode 100644 index 00..133720ec3e --- /dev/null +++ b/board/ti/am65x/board-cfg.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for AM65x +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/am65x/pm-cfg.yaml b/board/ti/am65x/pm-cfg.yaml new file mode 100644 index 00..4b1ce475cd --- /dev/null +++ b/board/ti/am65x/pm-cfg.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for AM65x +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/am65x/rm-cfg.yaml b/board/ti/am65x/rm-cfg.yaml new file mode 100644 index 00..84ec04e1e1 --- /dev/null +++ b/board/ti/am65x/rm-cfg.yaml @@ -0,0 +1,2068 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for AM65x +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0x2A +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #6 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #7 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #8 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +allowed_sched_priority : 0 +- #9 +host_id: 0 +allowed_atype : 0 +allowed_qos : 0 +allowed_orderid : 0 +allowed_priority : 0 +
[PATCH v4 11/23] am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img
Support added for HS and GP boot binaries for AM64x.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned, u-boot.img_unsigned: For GP
devices
Note that the bootflow followed by AM64x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 2 +
arch/arm/dts/k3-am642-r5-evm.dts | 1 +
arch/arm/dts/k3-am64x-binman.dtsi | 514 ++
board/ti/am64x/Kconfig| 2 +
4 files changed, 519 insertions(+)
create mode 100644 arch/arm/dts/k3-am64x-binman.dtsi
diff --git a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
index 64857b0909..73577e8cfd 100644
--- a/arch/arm/dts/k3-am642-evm-u-boot.dtsi
+++ b/arch/arm/dts/k3-am642-evm-u-boot.dtsi
@@ -3,6 +3,8 @@
* Copyright (C) 2020-2021 Texas Instruments Incorporated - https://www.ti.com/
*/
+#include "k3-am64x-binman.dtsi"
+
/ {
chosen {
stdout-path = "serial2:115200n8";
diff --git a/arch/arm/dts/k3-am642-r5-evm.dts b/arch/arm/dts/k3-am642-r5-evm.dts
index e870492a69..b49064181a 100644
--- a/arch/arm/dts/k3-am642-r5-evm.dts
+++ b/arch/arm/dts/k3-am642-r5-evm.dts
@@ -8,6 +8,7 @@
#include "k3-am642.dtsi"
#include "k3-am64-evm-ddr4-1600MTs.dtsi"
#include "k3-am64-ddr.dtsi"
+#include "k3-am64x-binman.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/k3-am64x-binman.dtsi
b/arch/arm/dts/k3-am64x-binman.dtsi
new file mode 100644
index 00..eddaa286e3
--- /dev/null
+++ b/arch/arm/dts/k3-am64x-binman.dtsi
@@ -0,0 +1,514 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM642_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_sci_enc>,
+ <_sysfw_cfg>, <_inner_cert>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_sci_enc>;
+ content-sysfw-data = <_sysfw_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ load = <0x7000>;
+ load-sysfw = <0x44000>;
+ load-sysfw-data = <0x7b000>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_sci_enc: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_sysfw_cfg: combined-sysfw-cfg.bin {
+ filename = "combined-sysfw-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+
+ };
+};
+
+ {
+ tiboot3_fs {
+ filename = "tiboot3.bin_fs";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_sci_enc_fs>,
+ <_sysfw_cfg_fs>,
<_inner_cert_fs>;
+ combined;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_sci_enc_fs>;
+ content-sysfw-data = <_sysfw_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ load = <0x7000>;
+ load-sysfw = <0x44000>;
+ load-sysfw-data = <0x7b000>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_sci_enc_fs: ti-fs-enc.bin {
+ filename =
"ti-sysfw/ti-sci-firmware-am64x_sr2-hs-fs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_sysfw_cfg_fs: combined-sysfw-cfg.bin {
+ filename = "combined-sysfw-cfg.bin";
+ type = "blob-ext";
+ };
+
[PATCH v4 09/23] am65: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
Support added for HS and GP boot binaries for AM65x.
tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img: For HS devices
tiboot3.bin_unsigned, sysfw.itb, tispl.bin_unsigned,
u-boot.img_unsigned: For GP devices
Note that the bootflow followed by AM65x requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
sysfw.itb:
* sysfw
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* ATF
* OPTEE
* A53 SPL
* A53 SPL dtbs
u-boot.img:
* A53 U-Boot
* A53 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 1 +
.../dts/k3-am654-r5-base-board-u-boot.dtsi| 1 +
arch/arm/dts/k3-am65x-binman.dtsi | 518 ++
board/ti/am65x/Kconfig| 2 +
4 files changed, 522 insertions(+)
create mode 100644 arch/arm/dts/k3-am65x-binman.dtsi
diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
index 0c1305df7e..e4cbc47c2a 100644
--- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
@@ -4,6 +4,7 @@
*/
#include "k3-am654-r5-base-board-u-boot.dtsi"
+#include "k3-am65x-binman.dtsi"
_0 {
remoteproc-name = "pru0_0";
diff --git a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
index 4516ab1437..949320c91d 100644
--- a/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
+++ b/arch/arm/dts/k3-am654-r5-base-board-u-boot.dtsi
@@ -5,6 +5,7 @@
#include
#include
+#include "k3-am65x-binman.dtsi"
/ {
chosen {
diff --git a/arch/arm/dts/k3-am65x-binman.dtsi
b/arch/arm/dts/k3-am65x-binman.dtsi
new file mode 100644
index 00..fac7214ad2
--- /dev/null
+++ b/arch/arm/dts/k3-am65x-binman.dtsi
@@ -0,0 +1,518 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_AM654_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>;
+ core = "public";
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw {
+ filename = "sysfw.bin";
+ ti-secure-rom {
+ content = <_sci_cert>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_sci_cert: ti-sci-cert.bin {
+ filename = "ti-sysfw/ti-sci-firmware-am65x-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-sci-firmware-am65x-hs-enc.bin {
+ filename = "ti-sysfw/ti-sci-firmware-am65x-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb {
+ filename = "sysfw-am65x-hs.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg: board-cfg {
+ filename = "board-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+ pm-cfg.bin {
+ description = "pm-cfg";
+ type = "firmware";
+
[PATCH v4 06/23] j7200: yaml: Add J7200 board config files
Added YAML configs for J7200 Signed-off-by: Neha Malcom Francis --- board/ti/j721e/board-cfg_j7200.yaml | 36 + board/ti/j721e/pm-cfg_j7200.yaml| 12 + board/ti/j721e/rm-cfg_j7200.yaml| 2065 +++ board/ti/j721e/sec-cfg_j7200.yaml | 378 + 4 files changed, 2491 insertions(+) create mode 100644 board/ti/j721e/board-cfg_j7200.yaml create mode 100644 board/ti/j721e/pm-cfg_j7200.yaml create mode 100644 board/ti/j721e/rm-cfg_j7200.yaml create mode 100644 board/ti/j721e/sec-cfg_j7200.yaml diff --git a/board/ti/j721e/board-cfg_j7200.yaml b/board/ti/j721e/board-cfg_j7200.yaml new file mode 100644 index 00..1453317ecb --- /dev/null +++ b/board/ti/j721e/board-cfg_j7200.yaml @@ -0,0 +1,36 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Board configuration for J7200 +# + +--- + +board-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +control: +subhdr: +magic: 0xC1D3 +size: 7 +main_isolation_enable : 0x5A +main_isolation_hostid : 0x2 +secproxy: +subhdr: +magic: 0x1207 +size: 7 +scaling_factor : 0x1 +scaling_profile : 0x1 +disable_main_nav_secure_proxy : 0 +msmc: +subhdr: +magic: 0xA5C3 +size: 5 +msmc_cache_size : 0x10 +debug_cfg: +subhdr: +magic: 0x020C +size: 8 +trace_dst_enables : 0x00 +trace_src_enables : 0x00 diff --git a/board/ti/j721e/pm-cfg_j7200.yaml b/board/ti/j721e/pm-cfg_j7200.yaml new file mode 100644 index 00..588a1d530d --- /dev/null +++ b/board/ti/j721e/pm-cfg_j7200.yaml @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Power management configuration for J7200 +# + +--- + +pm-cfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 diff --git a/board/ti/j721e/rm-cfg_j7200.yaml b/board/ti/j721e/rm-cfg_j7200.yaml new file mode 100644 index 00..66b589f370 --- /dev/null +++ b/board/ti/j721e/rm-cfg_j7200.yaml @@ -0,0 +1,2065 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/ +# +# Resource management configuration for J7200 +# + +--- + +rm-cfg: +rm_boardcfg: +rev: +boardcfg_abi_maj : 0x0 +boardcfg_abi_min : 0x1 +host_cfg: +subhdr: +magic: 0x4C41 +size : 356 +host_cfg_entries: +- #1 +host_id: 3 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #2 +host_id: 5 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #3 +host_id: 12 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #4 +host_id: 13 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid : 0x +allowed_priority : 0x +allowed_sched_priority : 0xAA +- #5 +host_id: 35 +allowed_atype : 0b101010 +allowed_qos : 0x +allowed_orderid :
[PATCH v4 07/23] j7200: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img
Support added for HS and GP boot binaries for J7200.
tiboot3.bin, tispl.bin and u-boot.img: For HS-SE devices
tiboot3.bin_fs, tispl.bin and u-boot.img: For HS-FS devices
tiboot3.bin_unsigned, tispl.bin_unsigned and u-boot.img_unsigned: For GP
devices
It is to be noted that the bootflow followed by J7200 requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-j7200-binman.dtsi | 501 ++
.../k3-j7200-common-proc-board-u-boot.dtsi| 2 +
board/ti/j721e/Kconfig| 2 +
3 files changed, 505 insertions(+)
create mode 100644 arch/arm/dts/k3-j7200-binman.dtsi
diff --git a/arch/arm/dts/k3-j7200-binman.dtsi
b/arch/arm/dts/k3-j7200-binman.dtsi
new file mode 100644
index 00..c586f8abcd
--- /dev/null
+++ b/arch/arm/dts/k3-j7200-binman.dtsi
@@ -0,0 +1,501 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J7200_R5_EVM
+
+_yaml {
+ config = "board-cfg_j7200.yaml";
+};
+
+_yaml {
+ config = "rm-cfg_j7200.yaml";
+};
+
+_yaml {
+ config = "pm-cfg_j7200.yaml";
+};
+
+_yaml {
+ config = "sec-cfg_j7200.yaml";
+};
+
+_yaml_tifs {
+ config = "board-cfg_j7200.yaml";
+};
+
+_yaml_tifs {
+ config = "rm-cfg_j7200.yaml";
+};
+
+_yaml_tifs {
+ config = "pm-cfg_j7200.yaml";
+};
+
+_yaml_tifs {
+ config = "sec-cfg_j7200.yaml";
+};
+
+_yaml_dm {
+ config = "rm-cfg_j7200.yaml";
+};
+
+_yaml_dm {
+ config = "pm-cfg_j7200.yaml";
+};
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>, <_fs_enc>,
<_tifs_cfg>,
+ <_dm_cfg>, <_inner_cert>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl>;
+ content-sysfw = <_fs_enc>;
+ content-sysfw-data = <_tifs_cfg>;
+ content-sysfw-inner-cert = <_inner_cert>;
+ content-dm-data = <_dm_cfg>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_tifs_cfg: combined-tifs-cfg.bin {
+ filename = "combined-tifs-cfg.bin";
+ type = "blob-ext";
+ };
+ sysfw_inner_cert: sysfw-inner-cert {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ combined_dm_cfg: combined-dm-cfg.bin {
+ filename = "combined-dm-cfg.bin";
+ type = "blob-ext";
+ };
+ };
+};
+
+ {
+ tiboot3_fs {
+ filename = "tiboot3.bin_fs";
+ ti-secure-rom {
+ content = <_boot_spl_fs>, <_fs_enc_fs>,
<_tifs_cfg_fs>,
+ <_dm_cfg_fs>, <_inner_cert_fs>;
+ combined;
+ dm-data;
+ sysfw-inner-cert;
+ keyfile = "custMpk.pem";
+ sw-rev = <1>;
+ content-sbl = <_boot_spl_fs>;
+ content-sysfw = <_fs_enc_fs>;
+ content-sysfw-data = <_tifs_cfg_fs>;
+ content-sysfw-inner-cert = <_inner_cert_fs>;
+ content-dm-data = <_dm_cfg_fs>;
+ load = <0x41c0>;
+ load-sysfw = <0x4>;
+ load-sysfw-data = <0x7f000>;
+ load-dm-data = <0x41c8>;
+ };
+ u_boot_spl_fs: u-boot-spl {
+ no-expanded;
+ };
+ ti_fs_enc_fs: ti-fs-enc.bin {
+ filename = "ti-sysfw/ti-fs-firmware-j7200-hs-enc.bin";
+ type = "blob-ext";
+
[PATCH v4 05/23] j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img
By providing entries in the binman node of the device tree, binman will
be able to find and package board config artifacts generated by
TIBoardConfig with sysfw.bin and generate the final image sysfw.itb.
It will also pick out the R5 SPL and sign it with the help of TI signing
entry and generate the final tiboot3.bin.
Entries for A72 build have been added to k3-j721e-binman.dtsi to
generate tispl.bin and u-boot.img.
Support has been added for both HS-SE(SR 1.1), HS-FS(SR 2.0) and GP images
In HS-SE, the encrypted system firmware binary must be signed along with
the signed certificate binary.
tiboot3.bin and sysfw-j721e_sr1_1-hs.itb: For HS-SE devices
tiboot3.bin_fs and sysfw-j721e_sr2-hs-fs.itb: For HS-FS devices
tiboot3.bin_unsigned and sysfw-j721e-gp-evm.itb: For GP devices
.bin/img: For HS devices
.bin_unsigned/img_unsigned: For GP devices
Intention of patch is to move signing and packaging to binman,
thus making makefile target only if binman is not enabled.
It is to be noted that the bootflow followed by J721E requires:
tiboot3.bin:
* R5 SPL
* R5 SPL dtbs
sysfw.itb:
* TIFS
* board-cfg
* pm-cfg
* sec-cfg
* rm-cfg
tispl.bin:
* DM
* ATF
* OPTEE
* A72 SPL
* A72 SPL dtbs
u-boot.img:
* A72 U-Boot
* A72 U-Boot dtbs
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
arch/arm/dts/k3-j721e-binman.dtsi | 700 ++
.../k3-j721e-common-proc-board-u-boot.dtsi| 1 +
.../arm/dts/k3-j721e-r5-common-proc-board.dts | 1 +
board/ti/j721e/Kconfig| 2 +
4 files changed, 704 insertions(+)
create mode 100644 arch/arm/dts/k3-j721e-binman.dtsi
diff --git a/arch/arm/dts/k3-j721e-binman.dtsi
b/arch/arm/dts/k3-j721e-binman.dtsi
new file mode 100644
index 00..45891ee49c
--- /dev/null
+++ b/arch/arm/dts/k3-j721e-binman.dtsi
@@ -0,0 +1,700 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-binman.dtsi"
+
+#ifdef CONFIG_TARGET_J721E_R5_EVM
+
+ {
+ tiboot3 {
+ filename = "tiboot3.bin";
+ ti-secure-rom {
+ content = <_boot_spl>;
+ core = "public";
+ load = ;
+ keyfile = "custMpk.pem";
+ };
+ u_boot_spl: u-boot-spl {
+ no-expanded;
+ };
+ };
+ sysfw {
+ filename = "sysfw.bin";
+ ti-secure-rom {
+ content = <_fs_cert>;
+ core = "secure";
+ load = <0x4>;
+ keyfile = "custMpk.pem";
+ countersign;
+ };
+ ti_fs_cert: ti-fs-cert.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-cert.bin";
+ type = "blob-ext";
+ optional;
+ };
+ ti-fs-firmware-j721e_sr1_1-hs-enc.bin {
+ filename =
"ti-sysfw/ti-fs-firmware-j721e_sr1_1-hs-enc.bin";
+ type = "blob-ext";
+ optional;
+ };
+ };
+ itb {
+ filename = "sysfw-j721e_sr1_1-hs.itb";
+ fit {
+ description = "SYSFW and Config fragments";
+ #address-cells = <1>;
+ images {
+ sysfw.bin {
+ description = "sysfw";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ blob-ext {
+ filename = "sysfw.bin";
+ };
+ };
+ board-cfg.bin {
+ description = "board-cfg";
+ type = "firmware";
+ arch = "arm";
+ compression = "none";
+ ti-secure {
+ content = <_cfg>;
+ keyfile = "custMpk.pem";
+ };
+ board_cfg: board-cfg {
+ filename = "board-cfg.bin";
+ type = "blob-ext";
+ };
+
+ };
+ pm-cfg.bin {
+ description = "pm-cfg";
+
[PATCH v4 03/23] arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin
Board config binary artifacts must be generated to be used by binman to
package sysfw.itb and tiboot3.bin for all K3 devices.
For devices that follow combined flow, these board configuration
binaries must again be packaged into a combined board configuration
blobs to be used by binman to package tiboot3.bin.
Add common k3-binman.dtsi to generate all the board configuration
binaries needed.
Also add custMpk.pem and ti-degenerate-key.pem needed for signing GP and
HS bootloader images common to all K3 devices.
Signed-off-by: Neha Malcom Francis
---
arch/arm/dts/k3-binman.dtsi | 116
1 file changed, 116 insertions(+)
create mode 100644 arch/arm/dts/k3-binman.dtsi
diff --git a/arch/arm/dts/k3-binman.dtsi b/arch/arm/dts/k3-binman.dtsi
new file mode 100644
index 00..97a3573bdb
--- /dev/null
+++ b/arch/arm/dts/k3-binman.dtsi
@@ -0,0 +1,116 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ custMpk {
+ filename = "custMpk.pem";
+ blob-ext {
+ filename = "../keys/custMpk.pem";
+ };
+ };
+
+ ti-degenerate-key {
+ filename = "ti-degenerate-key.pem";
+ blob-ext {
+ filename = "../keys/ti-degenerate-key.pem";
+ };
+ };
+};
+
+#ifndef CONFIG_ARM64
+
+ {
+ board-cfg {
+ filename = "board-cfg.bin";
+ bcfg_yaml: ti-board-config {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ pm-cfg {
+ filename = "pm-cfg.bin";
+ rcfg_yaml: ti-board-config {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ rm-cfg {
+ filename = "rm-cfg.bin";
+ pcfg_yaml: ti-board-config {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ sec-cfg {
+ filename = "sec-cfg.bin";
+ scfg_yaml: ti-board-config {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ combined-tifs-cfg {
+ filename = "combined-tifs-cfg.bin";
+ ti-board-config {
+ bcfg_yaml_tifs: board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ scfg_yaml_tifs: sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ pcfg_yaml_tifs: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rcfg_yaml_tifs: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+ combined-dm-cfg {
+ filename = "combined-dm-cfg.bin";
+ ti-board-config {
+ pcfg_yaml_dm: pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rcfg_yaml_dm: rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+ combined-sysfw-cfg {
+ filename = "combined-sysfw-cfg.bin";
+ ti-board-config {
+ board-cfg {
+ config = "board-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ sec-cfg {
+ config = "sec-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ pm-cfg {
+ config = "pm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ rm-cfg {
+ config = "rm-cfg.yaml";
+ schema = "../common/schema.yaml";
+ };
+ };
+ };
+};
+
+#endif
--
2.34.1
[PATCH v4 02/23] binman: ti-secure: Add support for TI signing
The ti-secure entry contains certificate for binaries that will be loaded or booted by system firmware whereas the ti-secure-rom entry contains certificate for binaries that will be booted by ROM. Support for both these types of certificates is necessary for booting of K3 devices. Signed-off-by: Neha Malcom Francis Reviewed-by: Simon Glass --- board/ti/keys/custMpk.pem | 51 board/ti/keys/ti-degenerate-key.pem | 10 + tools/binman/btool/openssl.py | 244 + tools/binman/entries.rst | 65 + tools/binman/etype/ti_secure.py | 76 ++ tools/binman/etype/ti_secure_rom.py | 247 ++ tools/binman/etype/x509_cert.py | 87 +- tools/binman/ftest.py | 52 tools/binman/test/279_ti_secure.dts | 17 ++ tools/binman/test/280_ti_secure_rom.dts | 17 ++ .../test/281_ti_secure_rom_combined.dts | 25 ++ tools/binman/test/288_ti_secure_rom_a.dts | 19 ++ tools/binman/test/289_ti_secure_rom_b.dts | 18 ++ 13 files changed, 920 insertions(+), 8 deletions(-) create mode 100644 board/ti/keys/custMpk.pem create mode 100644 board/ti/keys/ti-degenerate-key.pem create mode 100644 tools/binman/etype/ti_secure.py create mode 100644 tools/binman/etype/ti_secure_rom.py create mode 100644 tools/binman/test/279_ti_secure.dts create mode 100644 tools/binman/test/280_ti_secure_rom.dts create mode 100644 tools/binman/test/281_ti_secure_rom_combined.dts create mode 100644 tools/binman/test/288_ti_secure_rom_a.dts create mode 100644 tools/binman/test/289_ti_secure_rom_b.dts diff --git a/board/ti/keys/custMpk.pem b/board/ti/keys/custMpk.pem new file mode 100644 index 00..adba378c80 --- /dev/null +++ b/board/ti/keys/custMpk.pem @@ -0,0 +1,51 @@ +-BEGIN RSA PRIVATE KEY- +MIIJKQIBAAKCAgEAvxSuSdh/ctNrI83rSA5l3CJN8g5PgvbttfLd23yR+m5Z/9X3 +tt4EHYrM0pXZ0eDEwfhQv/9IDJEiUJpMe4vzlgooJrOk2eCpVUEa+z5bJ2y/ysBx +ry9yIu5GASVirT7HBPaxGLYswBJuD+KbPuWmoKgGRQNBF04WH6l01oRO1nmnELgR +qQ6SHyXdf7Hy0bnyaNgzWUuCfXfM0Zz6I7T7WIjyzerVFvIsdS36YsPBCW7gBnDg +tQcJmWLZ1uTnbG3IggdQk/fi2O3RX+PQns+TVNlf3V3ON2DxqxSKBHtlp7p/30VF +fEuhW65OxpQ9jE6H0pQ8pPOf2vzyNnznDa1aQjfxKoHQbqGnZwMeh+0Au3NKaCgx +ooKaowTB6If/RX6qwZ/UOwXHg/0hcf69fzjJFhlSDuYDM40dHsk2HM1OnYIpiM2b +Kr5sX3uysjp5AGp99a0anR7NWCrPXvROgKs7T9341N40osQg2VkZLYUCXh9osUyN +uREG6S12tViMUKg3bmZ4b4MwRk00n7QYSrm7+nvFrtYyEISEbD+agDM1/E281W5g +VFDPfm2AlwT6jwsg/b2YK6E3vVn9SuxFoQmLF8lyFDO3BV4SXeJaHc4hVPbh6tVV +qifrTQnfGUCCLmaJF2XZbrPWOE6NYRbWdNTeFl9RGdVCuIPSyN5LqWmXto0CAwEA +AQKCAgAzkAwcJ0z1GnId/lJQZno8NhGckRoJuEKbR8dwlCP8VUz6Ca5H7Y9kvXDa +Hs/hn+rYgP6hYOz7XyrIX2rmJ/T6dxEwqGeC1+o59FConcIRWHpE5zuGT6JYJL5F +TuZa48bm4v8VMQvQZOjIZpkIFwao8c6HTwKAnHTB5IN/48I2hCt+Cn3RhfoOZ7Rm +4gkpaSkt+7GXlhXHb82YfujNO+hbktEamhUYlQ9EK70Wa8aqmf3gHxO0JgsEFjW8 +lJaSnultlTW8SDcx3LMUUjCYumECk4oX/VlJfmKYjPlVjkr3QQ+Cm3nNucb4K4hc +c+JL+2ERhSj8RjXL7VgbNgdPnIjvQDJuTNqecTU8xWPYrkOLQpNibbLjnutLkhJz +fMyRtmDtrsey8WiCDuCHkPJ8/f8RjL2zWI9fzTDDIzdlEKouUFGOovaHVnbua6pn +hymcu9d9FV3p2rcbj0ivCs7e8j+vhSxFJEJoAbcQdXCTi/n2uR7pLtoMNiUzsejy +d46Uz+KEU920NTwE2z6JJq8I2vegnxjc7PDDrV3/5rK04B93aXiqvwWseCpxelrI +xaMkRHbXrIXRO6MXQ3N+zNq8Dg3hjGTTvaBKuwgvqLwlXY8+Aa3ooFzEOInIOSsI +XcWqXxt/tgZgsj9RwpC42t8kbA+BkbNk9EIUa+P5kEr2P/fO7QKCAQEA4EtArnOX +D6tQF8uTw8USOZC2P9s/ez1z4jRq3oKP0Kv4tJiuIObJ/dUvGVD7aM5v2xaCfhm8 +xpk09VPUgghfG5jR5qVvQr75kCNToJQudWi4ngk1HwKJzzTO11giFEdybvTUA+Pj +fmxCM0dYYqRWZoj0hLqXlUCwxE74BFIhJVjeYbf+nTQrqpllTLoW7MTZHzGx5SXx +4dNzyVAUH49Yt2D8mgXXCkf5sGLh762wj34b/rR10Kr4O5utGMZrfTRIbuQ1pNjU +m66baPzq+mC0BzqZEW70TgEb7lOr8rcVXLOi3r36omfd9/MHx7iZD6o3K1axSO15 +grD4ZrN7Ac3QJwKCAQEA2heCoBdpvy6YUk8AO2k8qDygTdmPQRuwjjT+Z2fMslBt +D7DkpKwZ6Bl9OclcpiiLHmH+hv65KqYg+tR0RRb7PcogB9El9x7yKkGTPZEYWGky +n8P84rJpKwjnwWQvPQktI1cs3YGvZA9DQTFBavRrwuzgd1oSJq5aPQ2tme0kMvWp +l1/B/cPK+PKCi/Wfisaze1TjijP9qIeUwkdNN6WLrLU3QgsGppcg2I7RQtAIikT6 +GkuiOQAvWMsrJVV6PNrVKz4fJDJ59Rz6jbDHZNi1MEYNxQoB/Pl7QIakbfjWpHLv +8Ey7cB2JKxjQy8tmyl8WNQVbXbE6daPXcMTUmaRAKwKCAQBv1lYMJmq+T2eCVen6 +BbvOpE+bi5EdvEiaFBTtmiBnpjg+pJq+oRU60h/H+c9CNR0lGxY6Fk9An4f+g6xE +ojP6KLsQzJCrsVny+wpp2TlJJcxYULMCIVvhy60PR0zG29E9biqBPhJjKUvhEcQK +e3LxcXyq6fdHXphFajLUxLbuTl+kTgBRFoBnclFGbsubh5PTsA3J+p+fQLZNPPar +veg4l82cZykQYU8pGkUaI3sUMYd3+zd7sqRP5JHs9pMGPRmY4YW2CsAIWIn5UZNB +ARMDP76vKKn8cyUgMuxb+9pU/OVLN2NPs4bEaZQJjAwV+YPEwldny7F47xEM9JVz +EtKlAoIBAQDUt62u3GdGE/p5/ZgqWoDRTyDEDfmN9aYFbmbdEP80xQE7FrxMaZhz +K7laja6SWmUm40nQ/c45bQQp4uLtKHcxU15egX7YRBTLZl5o5IasZR79ebnEm2O8 +l9kEZeU1USf3mmWmP4GExOZCRfqaiYA6BbUCdJXTqKdXeWnkAssV8UrS3JFoJHpq +yo7OWGqefyQ8nRW6jO9SW7uaqtUD+7H6aF5XSk3YWvusfdBZrHNH+fM/hpnZovaL +Us7ogTDS/laA8PyK37jYfMVdQhmZoU1Iomt3zkUWK3gt/aWPpfAlQf4Jka4YspZB +tNiijefaZ1hPqsPs5Joyd/YAhdsfaHc1AoIBAQCn/9j6RRjRaw0ip756oad4AXHz +XBwVB2CrY96qT6Hj9Sq7tGgdskqGkOQkAivBLBizUdcWv0t1yenOsSgasQeMlvlh +B8md9cLvpKXPB3HM3rTDH/xNXe0TpVKLf7SXC8HfDyIweHwMW3QgO2DWrvI4BV/T
[PATCH v4 01/23] binman: ti-board-config: Add support for TI board config binaries
The ti-board-config entry loads and validates a given YAML config file
against a given schema, and generates the board config binary. K3
devices require these binaries to be packed into the final system
firmware images.
Signed-off-by: Neha Malcom Francis
Reviewed-by: Simon Glass
---
tools/binman/entries.rst | 48
tools/binman/etype/ti_board_config.py | 259 ++
tools/binman/ftest.py | 20 ++
tools/binman/pyproject.toml | 2 +-
tools/binman/test/277_ti_board_cfg.dts| 14 +
.../binman/test/278_ti_board_cfg_combined.dts | 25 ++
.../binman/test/279_ti_board_cfg_no_type.dts | 11 +
tools/binman/test/yaml/config.yaml| 19 ++
tools/binman/test/yaml/schema.yaml| 51
tools/binman/test/yaml/schema_notype.yaml | 40 +++
10 files changed, 488 insertions(+), 1 deletion(-)
create mode 100644 tools/binman/etype/ti_board_config.py
create mode 100644 tools/binman/test/277_ti_board_cfg.dts
create mode 100644 tools/binman/test/278_ti_board_cfg_combined.dts
create mode 100644 tools/binman/test/279_ti_board_cfg_no_type.dts
create mode 100644 tools/binman/test/yaml/config.yaml
create mode 100644 tools/binman/test/yaml/schema.yaml
create mode 100644 tools/binman/test/yaml/schema_notype.yaml
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index b71af801fd..14a2d03fad 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1658,6 +1658,54 @@ by setting the size of the entry to something larger
than the text.
+.. _etype_ti_board_config:
+
+Entry: ti-board-config: An entry containing a TI schema validated board config
binary
+-
+
+This etype supports generation of two kinds of board configuration
+binaries: singular board config binary as well as combined board config
+binary.
+
+Properties / Entry arguments:
+- config-file: File containing board configuration data in YAML
+- schema-file: File containing board configuration YAML schema against
+ which the config file is validated
+
+Output files:
+- board config binary: File containing board configuration binary
+
+These above parameters are used only when the generated binary is
+intended to be a single board configuration binary. Example::
+
+my-ti-board-config {
+ti-board-config {
+config = "board-config.yaml";
+schema = "schema.yaml";
+};
+};
+
+To generate a combined board configuration binary, we pack the
+needed individual binaries into a ti-board-config binary. In this case,
+the available supported subnode names are board-cfg, pm-cfg, sec-cfg and
+rm-cfg. The final binary is prepended with a header containing details about
+the included board config binaries. Example::
+
+my-combined-ti-board-config {
+ti-board-config {
+board-cfg {
+config = "board-cfg.yaml";
+schema = "schema.yaml";
+};
+sec-cfg {
+config = "sec-cfg.yaml";
+schema = "schema.yaml";
+};
+}
+}
+
+
+
.. _etype_u_boot:
Entry: u-boot: U-Boot flat binary
diff --git a/tools/binman/etype/ti_board_config.py
b/tools/binman/etype/ti_board_config.py
new file mode 100644
index 00..0799e5dc59
--- /dev/null
+++ b/tools/binman/etype/ti_board_config.py
@@ -0,0 +1,259 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2022 Texas Instruments Incorporated - https://www.ti.com/
+# Written by Neha Malcom Francis
+#
+# Entry-type module for generating schema validated TI board
+# configuration binary
+#
+
+import os
+import struct
+import yaml
+
+from collections import OrderedDict
+from jsonschema import validate
+from shutil import copyfileobj
+
+from binman.entry import Entry
+from binman.etype.section import Entry_section
+from dtoc import fdt_util
+from u_boot_pylib import tools
+
+BOARDCFG = 0xB
+BOARDCFG_SEC = 0xD
+BOARDCFG_PM = 0xE
+BOARDCFG_RM = 0xC
+BOARDCFG_NUM_ELEMS = 4
+
+class Entry_ti_board_config(Entry_section):
+"""An entry containing a TI schema validated board config binary
+
+This etype supports generation of two kinds of board configuration
+binaries: singular board config binary as well as combined board config
+binary.
+
+Properties / Entry arguments:
+- config-file: File containing board configuration data in YAML
+- schema-file: File containing board configuration YAML schema against
+ which the config file is validated
+
+Output files:
+- board config binary: File containing board configuration binary
+
+These above parameters are used only when the generated binary is
+intended to be a single board configuration binary. Example::
+
+my-ti-board-config {
+ti-board-config {
+config = "board-config.yaml";
+
[PATCH v4 00/23] Migration to using binman for bootloader
This series aims to eliminate the use of additional custom repositories such as k3-image-gen (K3 Image Generation) repo and core-secdev-k3 (K3 Security Development Tools) that was plumbed into the U-Boot build flow to generate boot images for TI K3 platform devices. And instead, we move towards using binman that aligns better with the community standard build flow. This series uses binman for all K3 platforms supported on U-Boot currently; both HS (High Security, both SE and FS) and GP (General Purpose) devices. Background on using k3-image-gen: * TI K3 devices require a SYSFW (System Firmware) image consisting of a signed system firmware image and board configuration binaries, this is needed to bring up system firmware during U-Boot R5 SPL startup. * Board configuration data contain board-specific information such as resource management, power management and security. Background on using core-secdev-k3: * Contains resources to sign x509 certificates for HS devices Series intends to use binman to take over the packaging and signing for the R5 bootloader images tiboot3.bin (and sysfw.itb, for non-combined boot flow) instead of k3-image-gen. Series also packages the A72/A53 bootloader images (tispl.bin and u-boot.img) using ATF, OPTEE and DM (Device Manager) Changes in v4: - added support for iot2050 - documentation fixes - move to using self.Raise in ti-board-config etype - introduced common k3-binman.dtsi (further reduction in code duplication can be targetted, this as first step) Changes in v3: - added support for HS-FS devices - added support for AM68-sk - added back dropped documentation patch - changed prefix for SYSFW and DM files to expected directory name - extended test coverage to 100% - documentation fixes - corrected formatting changes Changes in v2: - removed all external scripts - created ti-board-config etype to support generation of board config binaries - created ti-secure and ti-secure-rom etypes to handle signing instead of using external TI_SECURE_DEV_PKG - updated openssl btool to support x509 certificate generation - dropped Makefile changes to obtain external binary components, moving to using BINMAN_INDIRS to achieve the same CI/CD passes 100% (with series rebased on -master, current series based on -next) [1] v1: https://patchwork.ozlabs.org/project/uboot/cover/20230120101903.179959-1-n-fran...@ti.com/ v2: https://patchwork.ozlabs.org/project/uboot/cover/20230404121342.446935-1-n-fran...@ti.com/ [1] https://github.com/u-boot/u-boot/pull/291 Kamlesh Gurudasani (1): configs: am64x: Enable TI_SECURE_DEV options Neha Malcom Francis (20): binman: ti-board-config: Add support for TI board config binaries binman: ti-secure: Add support for TI signing arm: dts: k3: Add support for packaging sysfw.itb and tiboot3.bin j721e: schema: yaml: Add general schema and J721E board config files j721e: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img j7200: yaml: Add J7200 board config files j7200: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img am65x: yaml: Add AM65x board config files am65: dts: binman: Package tiboot3.bin, sysfw.itb, tispl.bin, u-boot.img am64x: yaml: Add board configs for AM64x am64x: dts: binman: Package tiboot3.bin, tispl.bin u-boot.img j721s2: yaml: Add board configs for J721S2 j721s2: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img am62: yaml: Add board configs for AM62 am625: dts: binman: Package tiboot3.bin, tispl.bin and u-boot.img am62a: yaml: Add board configs for AM62ax am62a: dts: binman: Package tiboot3.bin, tispl.bin, u-boot.img arm: k3-am65x-iot2050: Use binman for tispl.bin for iot2050 k3: tools: config.mk: Update makefile and remove scripts doc: board: ti: Update documentation for binman flow Tom Rini (2): buildman: Create a requirements.txt file CI: Make use of buildman requirements.txt .azure-pipelines.yml |4 + .gitlab-ci.yml|4 + arch/arm/dts/k3-am625-r5-sk.dts |1 + arch/arm/dts/k3-am625-sk-binman.dtsi | 462 +++ arch/arm/dts/k3-am625-sk-u-boot.dtsi |2 + arch/arm/dts/k3-am62a-sk-binman.dtsi | 461 +++ arch/arm/dts/k3-am62a7-r5-sk.dts |1 + arch/arm/dts/k3-am62a7-sk.dts |1 + arch/arm/dts/k3-am642-evm-u-boot.dtsi |2 + arch/arm/dts/k3-am642-r5-evm.dts |1 + arch/arm/dts/k3-am64x-binman.dtsi | 514 +++ arch/arm/dts/k3-am65-iot2050-boot-image.dtsi | 76 +- arch/arm/dts/k3-am654-base-board-u-boot.dtsi |1 + .../dts/k3-am654-r5-base-board-u-boot.dtsi|1 + arch/arm/dts/k3-am65x-binman.dtsi | 518 +++
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 07:13:15PM +0530, Anup Patel wrote: > On Thu, May 18, 2023 at 4:02 PM Andrew Jones wrote: > > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > > - riscv,isa: > > > -description: > > > - Identifies the specific RISC-V instruction set architecture > > > - supported by the hart. These are documented in the RISC-V > > > - User-Level ISA document, available from > > > - https://riscv.org/specifications/ > > > - > > > - Due to revisions of the ISA specification, some deviations > > > - have arisen over time. > > > - Notably, riscv,isa was defined prior to the creation of the > > > - Zicsr and Zifencei extensions and thus "i" implies > > > - "zicsr_zifencei". > > > - > > > - While the isa strings in ISA specification are case > > > - insensitive, letters in the riscv,isa string must be all > > > - lowercase to simplify parsing. > > > -$ref: "/schemas/types.yaml#/definitions/string" > > > -pattern: > > > ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ > > > - > > ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here > > >timebase-frequency: false > > > > > > @@ -133,8 +117,13 @@ properties: > > >DMIPS/MHz, relative to highest capacity-dmips-mhz > > >in the system. > > > > > > +oneOf: > > > + - required: > > > + - riscv,isa > > > > This is the part Anup keeps reminding me about. We can create better ways > > to handle extensions in DT and ACPI, but we'll still need to parse ISA > > strings to handle legacy DTs and holdouts that keep creating ISA strings, > > at least during the deprecation period, since ISA strings are still "the > > way to do it" according to the spec. > > Coming up with an alternate way in DT is fine but we can't deprecate > ISA strings since ISA strings are widely used: > 1) Various bootloaders Aye, for the reason, as I mentioned earlier and in the RFC thread, removing existing parsers isn't a good idea. > 2) It is part of /proc/cpuinfo That is irrelevant. > 3) Hypervisors use it to communicate HW features to Guest/VM. > Hypervisors can't get away from generating ISA strings because > Hypervisors don't know what is running inside Guest/VM. Generate both :) As things stand, your guests could interpret what you communicate to them via riscv,isa differently! > In the case of ACPI, it is a very different situation. Like Sunil mentioned, > ACPI will always follow mechanisms defined by RVI (such as ISA string). > Other ACPI approaches such as GUID for ISA extension are simply not > scalable and will take a lot more memory for ACPI tables compared to > ISA strings. My proposal should actually suit ACPI, at least for Linux, as it would be a chance to align currently misaligned definitions. I won't speak to GUIDs or whatever as that's someone else's problem :) > > Also, if we assume the wording in the spec does get shored up, then, > > unless I'm missing something, the list of advantages for this boolean > > proposal from your commit message would be > > IMO, we should try our best to have the wordings changed in RVI spec. Yes, doing so is beneficial for all of us regardless of what happens here. I do think that it is partially orthogonal - it allows us to not design an interface that needs to be capable of communicating a wide variety of versions, but I don't think it solves some of the issues that riscv,isa has. If I thought it did, I would not have gone to the trouble of respinning this patch out of the other approach. > > * More character choices for name -- probably not a huge gain for ratified > > extensions, since the boolean properties will likely still use the same > > name as the ISA string (riscv,isa-extension-). But, for vendor > > extensions, this is indeed a major improvement, since vendor extension > > boolean property names may need to be extended in unambiguous ways to > > handle changes in the extension. > > > > * Simpler, more complete DT validation (but we still need a best effort > > for legacy ISA strings) > > > > * Simpler DT parsing (but we still need the current parser for legacy ISA > > strings) > > > > > + - required: > > > + - riscv,isa-base > > > + > > > required: > > > - - riscv,isa > > >- interrupt-controller > > > > > > additionalProperties: true > > > @@ -177,7 +166,13 @@ examples: > > > i-tlb-size = <32>; > > > mmu-type = "riscv,sv39"; > > > reg = <1>; > > > -riscv,isa = "rv64imafdc"; > > > +riscv,isa-base = "rv64i"; > > > +riscv,isa-extension-i; > > > +riscv,isa-extension-m; > > > +riscv,isa-extension-a; > > > +riscv,isa-extension-f; > > > +riscv,isa-extension-d; > > > +riscv,isa-extension-c; > > One downside of this new approach is it will increase the size of
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 4:02 PM Andrew Jones wrote: > > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > intro > > = > > > > When the RISC-V dt-bindings were accepted upstream in Linux, the base > > ISA etc had yet to be ratified. By the ratification of the base ISA, > > incompatible changes had snuck into the specifications - for example the > > Zicsr and Zifencei extensions were spun out of the base ISA. > > > > Fast forward to today, and the reason for this patch. > > Currently the riscv,isa dt property permits only a specific subset of > > the ISA string - in particular it excludes version numbering. > > With the current constraints, it is not possible to discern whether > > "rv64i" means that the hart supports the fence.i instruction, for > > example. > > Future systems may choose to implement their own instruction fencing, > > perhaps using a vendor extension, or they may not implement the optional > > counter extensions. Software needs a way to determine this. > > > > versioning schemes > > == > > > > "Use the extension versions that are described in the ISA manual" you > > may say, and it's not like this has not been considered. > > Firstly, software that parses the riscv,isa property at runtime will > > need to contain a lookup table of some sort that maps arbitrary versions > > to versions it understands. There is not a consistent application of > > version number applied to extensions, with a higgledy-piggledy > > collection of tags, "bare" and version documents awaiting the reader on > > the "recently ratified extensions" page: > > https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions > > > > As an aside, this is reflected in the patch too, since many > > extensions have yet to appear in a release of the ISA specs, > > and are defined by commits in their respective "working draft" > > repositories. > > > > Secondly, there is an issue of backwards compatibility, whereby allowing > > numbers in the ISA string, some parsers may be broken. This would > > require an additional property to be created to even use the versions in > > this manner. > > > > boolean properties > > == > > > > If a new property is needed, the whole approach may as well be looked at > > from the bottom up. A string with limited character choices etc is > > hardly the best approach for communicating extension information to > > software. > > > > Switching to using boolean properties, one per extension, allows us to > > define explicit meanings for the DT representation of each extension - > > rather than the current situation where different operating systems or > > other bits of software may impart different meanings to characters in > > the string. Clearly the best source of meanings is the specifications > > themselves, this just provides us the ability to choose at what point > > in time the meaning is set. If an extension changes incompatibility in > > the future, a new property will be required. > > > > Off-list, some of the RVI folks have committed to shoring up the wording > > in either the ISA specifications, the riscv-isa-manual or > > so that in the future, modifications to and additions or removals of > > features will require a new extension. Codifying that assertion > > somewhere would make it quite unlikely that compatibility would be > > broken, but we have the tools required to deal with it, if & when it > > crops up. > > It is in our collective interest, as consumers of extension meanings, to > > define a scheme that enforces compatibility. > > > > The use of boolean properties, rather than elements in a string, will > > also permit validation that the strings have a meaning, as well as > > potentially reject mutually exclusive combinations, or enforce > > dependencies between instructions. That would not be possible with the > > current dt-schema infrastructure for arbitrary strings, as we would need > > to add a riscv,isa parser to dt-validate! > > That's not implemented in this patch, but rather left as > > future work! > > > > acpi > > > > > > The current ACPI ECR is based on having a string unfortunately, but > > ideally ACPI will move to another method, perhaps GUIDs, that give > > explicit meaning to extensions. > > > > parser simplicity > > = > > > > Many systems that parse DT at runtime already implement an function that > > can check for the presence of boolean properties, rather than having to > > implement - although unfortunately for backwards compatibility with old > > dtbs, existing parsers may not be removable - which may greatly simplify > > dt parsing code. For example, in Linux, checking for an extension > > becomes as simple as: > > of_property_present(node, "riscv,isa-extension-zicbom") > > > > vendor extensions > > = > > > > Compared to riscv,isa, this proposed scheme promotes vendor extensions, > > oft touted as the strength of RISC-V, to
RE: [PATCH v3 1/2] serial: zynqmp: Fetch baudrate from dtb and update
Hi Simon,
Thanks,
A Santosh Sagar.
> -Original Message-
> From: Simon Glass
> Sent: Tuesday, April 25, 2023 11:31 PM
> To: Abbarapu, Venkatesh
> Cc: u-boot@lists.denx.de; Simek, Michal ;
> g...@xilinx.com; Algapally, Santosh Sagar
> Subject: Re: [PATCH v3 1/2] serial: zynqmp: Fetch baudrate from dtb and update
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Hi Venkatesh,
>
> On Tue, 25 Apr 2023 at 06:05, Venkatesh Yadav Abbarapu
> wrote:
> >
> > From: Algapally Santosh Sagar
> >
> > The baudrate configured in .config is taken by default by serial. If
> > change of baudrate is required then the .config needs to changed and
> > u-boot recompilation is required or the u-boot environment needs to be
> > updated.
> >
> > To avoid this, support is added to fetch the baudrate directly from
> > the device tree file and update.
> > The serial, prints the log with the configured baudrate in the dtb.
> > The commit c4df0f6f315c ("arm: mvebu: Espressobin: Set default value
> > for $fdtfile env variable") is taken as reference for changing the
> > default environment variable.
> >
> > The default environment stores the default baudrate value, When
> > default baudrate and dtb baudrate are not same glitches are seen on the
> serial.
> > So, the environment also needs to be updated with the dtb baudrate to
> > avoid the glitches on the serial.
> >
> > Signed-off-by: Algapally Santosh Sagar
> >
> > Signed-off-by: Venkatesh Yadav Abbarapu
> > ---
> > drivers/serial/serial-uclass.c | 32 +++
> > include/env_default.h | 7 --
> > include/env_internal.h | 2 +-
> > include/fdtdec.h | 8 +++
> > include/serial.h | 1 +
> > lib/fdtdec.c | 40 ++
> > 6 files changed, 87 insertions(+), 3 deletions(-)
>
> Can you please add something to doc/ for this feature?
Ok sure
>
> >
> > diff --git a/drivers/serial/serial-uclass.c
> > b/drivers/serial/serial-uclass.c index 067fae2614..d77d3bda36 100644
> > --- a/drivers/serial/serial-uclass.c
> > +++ b/drivers/serial/serial-uclass.c
> > @@ -154,12 +154,44 @@ static void serial_find_console_or_panic(void)
> > }
> > #endif /* CONFIG_SERIAL_PRESENT */
> >
> > +#ifdef CONFIG_SERIAL_DT_BAUD
>
> Please drop this #ifdef
Will drop
>
> > +int serial_get_valid_baudrate(int baud) {
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(baudrate_table); ++i) {
> > + if (baud == baudrate_table[i])
> > + return 0;
> > + }
> > +
> > + return -EINVAL;
> > +}
> > +#endif
> > +
> > /* Called prior to relocation */
> > int serial_init(void)
> > {
> > #if CONFIG_IS_ENABLED(SERIAL_PRESENT)
> > serial_find_console_or_panic();
> > gd->flags |= GD_FLG_SERIAL_READY;
> > +#ifdef CONFIG_SERIAL_DT_BAUD
>
> if (IS_ENABLED(CONFIG_SERIAL_DT_BAUD)
On using this
if (IS_ENABLED(CONFIG_SERIAL_DT_BAUD))
The variables declared below are getting compiled and the below warning is
thrown. So, not changing this.
drivers/serial/serial-uclass.c: In function 'serial_init':
drivers/serial/serial-uclass.c:189:21: warning: initialization discards 'const'
qualifier from pointer target type [-Wdiscarded-qualifiers]
189 | char *ptr = _environment[0];
>
> You also should add a Kconfig option. I suggest naming it OF_SERIAL_BOARD
> since we typically put an OF_ prefix on such options.
>
Will change SERIAL_DT_BAUD to OF_SERIAL_DT_BAUD
> > + int ret = 0;
> > + char *ptr = _environment[0];
> > +
> > + /*
> > +* Fetch the baudrate from the dtb and update the value in the
> > +* default environment.
> > +*/
> > + ret = fdtdec_get_baud_from_dtb(gd->fdt_blob);
> > + if (ret != -EINVAL && ret != -EFAULT) {
> > + gd->baudrate = ret;
> > +
> > + while (*ptr != '\0' && *(ptr + 1) != '\0')
> > + ptr++;
> > + ptr += 2;
> > + sprintf(ptr, "baudrate=%d", gd->baudrate);
> > + }
> > +#endif
> > serial_setbrg();
> > #endif
> >
> > diff --git a/include/env_default.h b/include/env_default.h index
> > c0df39d62f..4f286ffc9e 100644
> > --- a/include/env_default.h
> > +++ b/include/env_default.h
> > @@ -23,7 +23,7 @@ env_t embedded_environment
> __UBOOT_ENV_SECTION__(environment) = {
> > {
> > #elif defined(DEFAULT_ENV_INSTANCE_STATIC)
> > static char default_environment[] = { -#elif
> > defined(DEFAULT_ENV_IS_RW)
> > +#elif defined(CONFIG_DEFAULT_ENV_IS_RW)
> > char default_environment[] = {
> > #else
> > const char default_environment[] = {
> > @@ -44,7 +44,7 @@ const char default_environment[] = { #if
> > defined(CONFIG_BOOTDELAY)
> > "bootdelay="__stringify(CONFIG_BOOTDELAY) "\0"
> > #endif
> > -#if defined(CONFIG_BAUDRATE) &&
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > intro > = > > When the RISC-V dt-bindings were accepted upstream in Linux, the base > ISA etc had yet to be ratified. By the ratification of the base ISA, > incompatible changes had snuck into the specifications - for example the > Zicsr and Zifencei extensions were spun out of the base ISA. > > Fast forward to today, and the reason for this patch. > Currently the riscv,isa dt property permits only a specific subset of > the ISA string - in particular it excludes version numbering. > With the current constraints, it is not possible to discern whether > "rv64i" means that the hart supports the fence.i instruction, for > example. > Future systems may choose to implement their own instruction fencing, > perhaps using a vendor extension, or they may not implement the optional > counter extensions. Software needs a way to determine this. > > versioning schemes > == > > "Use the extension versions that are described in the ISA manual" you > may say, and it's not like this has not been considered. > Firstly, software that parses the riscv,isa property at runtime will > need to contain a lookup table of some sort that maps arbitrary versions > to versions it understands. There is not a consistent application of > version number applied to extensions, with a higgledy-piggledy > collection of tags, "bare" and version documents awaiting the reader on > the "recently ratified extensions" page: > https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions > > As an aside, this is reflected in the patch too, since many > extensions have yet to appear in a release of the ISA specs, > and are defined by commits in their respective "working draft" > repositories. > > Secondly, there is an issue of backwards compatibility, whereby allowing > numbers in the ISA string, some parsers may be broken. This would > require an additional property to be created to even use the versions in > this manner. > > boolean properties > == > > If a new property is needed, the whole approach may as well be looked at > from the bottom up. A string with limited character choices etc is > hardly the best approach for communicating extension information to > software. > > Switching to using boolean properties, one per extension, allows us to > define explicit meanings for the DT representation of each extension - > rather than the current situation where different operating systems or > other bits of software may impart different meanings to characters in > the string. Clearly the best source of meanings is the specifications > themselves, this just provides us the ability to choose at what point > in time the meaning is set. If an extension changes incompatibility in > the future, a new property will be required. > > Off-list, some of the RVI folks have committed to shoring up the wording > in either the ISA specifications, the riscv-isa-manual or > so that in the future, modifications to and additions or removals of > features will require a new extension. Codifying that assertion > somewhere would make it quite unlikely that compatibility would be > broken, but we have the tools required to deal with it, if & when it > crops up. > It is in our collective interest, as consumers of extension meanings, to > define a scheme that enforces compatibility. > > The use of boolean properties, rather than elements in a string, will > also permit validation that the strings have a meaning, as well as > potentially reject mutually exclusive combinations, or enforce > dependencies between instructions. That would not be possible with the > current dt-schema infrastructure for arbitrary strings, as we would need > to add a riscv,isa parser to dt-validate! > That's not implemented in this patch, but rather left as > future work! > > acpi > > > The current ACPI ECR is based on having a string unfortunately, but > ideally ACPI will move to another method, perhaps GUIDs, that give > explicit meaning to extensions. > > parser simplicity > = > > Many systems that parse DT at runtime already implement an function that > can check for the presence of boolean properties, rather than having to > implement - although unfortunately for backwards compatibility with old > dtbs, existing parsers may not be removable - which may greatly simplify > dt parsing code. For example, in Linux, checking for an extension > becomes as simple as: > of_property_present(node, "riscv,isa-extension-zicbom") > > vendor extensions > = > > Compared to riscv,isa, this proposed scheme promotes vendor extensions, > oft touted as the strength of RISC-V, to first-class citizens. > At present, extensions are defined as meaning what the RISC-V ISA > specifications say they do. There is no realistic way of using that > interface to provide cross-platform definitions for what vendor > extensions mean.
[PATCH] common: dfu: Remove leading space characters
As per [1], dfu_alt_info is mentioned to be as semicolon separated
string of information on each alternate and the parsing logic in
the dfu.c is based on this.
Typically, the dfu_alt_info_* is defined in .h files as preprocessor
macros with 'alt' info separated by semicolon.
But when dfu_alt_info_* is added in the environment files(.env)
the script at "scripts/env2string.awk" converts a newline to space.
Thus adding a space character after semicolon. This results in
incorrect parsing in dfu.c which is based on the information that
'alt' info are only semicolon separated.
One option is to add dfu_alt_info_* variable in .env in single line.
But there is possiblity for it to exceed the line length limit.
So update the parsing logic to remove leading space characters
before adding to the dfu list.
[1]: https://u-boot.readthedocs.io/en/latest/usage/dfu.html
Signed-off-by: Ravi Gunasekaran
---
drivers/dfu/dfu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
index 516dda6179..b2ee5f1ede 100644
--- a/drivers/dfu/dfu.c
+++ b/drivers/dfu/dfu.c
@@ -135,6 +135,7 @@ int dfu_config_interfaces(char *env)
a = s;
do {
part = strsep(, ";");
+ part = skip_spaces(part);
ret = dfu_alt_add(dfu, i, d, part);
if (ret)
return ret;
@@ -629,6 +630,7 @@ int dfu_config_entities(char *env, char *interface, char
*devstr)
for (i = 0; i < dfu_alt_num; i++) {
s = strsep(, ";");
+ s = skip_spaces(s);
ret = dfu_alt_add(dfu, interface, devstr, s);
if (ret) {
/* We will free "dfu" in dfu_free_entities() */
base-commit: f0e201433a2f6e6776fe7aaa6a89ca3df21a4435
--
2.17.1
Re: [PATCH v3 2/2] firmware: zynqmp: Move permission to change config object message
On 5/17/23 16:11, Stefan Herbrechtsmeier wrote:
Am 17.05.2023 um 14:12 schrieb Michal Simek:
On 5/16/23 16:05, Stefan Herbrechtsmeier wrote:
From: Stefan Herbrechtsmeier
Move the permission to change a config object message from
zynqmp_pmufw_load_config_object function to zynqmp_pmufw_node function
to simplify the code and check the permission only if required.
Signed-off-by: Stefan Herbrechtsmeier
---
Changes in v4:
- Reword
- Move the check back to zynqmp_pmufw_node because the check need to be
run after the config object load.
- Return error in zynqmp_pmufw_config_close and zynqmp_pmufw_node
Changes in v3:
- Added
drivers/firmware/firmware-zynqmp.c | 36 ++
1 file changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 2b1ad5d2c3..6dc745bd14 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -63,29 +63,32 @@ static unsigned int xpm_configobject_close[] = {
int zynqmp_pmufw_config_close(void)
{
- zynqmp_pmufw_load_config_object(xpm_configobject_close,
- sizeof(xpm_configobject_close));
- return 0;
+ return zynqmp_pmufw_load_config_object(xpm_configobject_close,
+ sizeof(xpm_configobject_close));
}
int zynqmp_pmufw_node(u32 id)
{
- static bool skip_config;
- int ret;
+ static bool checked;
+ static bool skip;
I see interesting behavior in connection to these variables.
I did this change and keep test variable to see behavior.
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index 6dc745bd1424..becbea7b64ea 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -67,10 +67,14 @@ int zynqmp_pmufw_config_close(void)
sizeof(xpm_configobject_close));
}
+static bool checked;
+static bool skip;
+
int zynqmp_pmufw_node(u32 id)
{
- static bool checked;
- static bool skip;
+ static bool test;
+
+ printf("%s, id %d, ch %d, skp %d - test %d\n",
__func__, id, checked, skip, test);
if (!checked) {
checked = true;
@@ -379,6 +391,9 @@ static int zynqmp_firmware_bind(struct udevice *dev)
int ret;
struct udevice *child;
+ checked = 0;
+ skip = 0;
+
if ((IS_ENABLED(CONFIG_SPL_BUILD) &&
IS_ENABLED(CONFIG_SPL_POWER_DOMAIN) &&
IS_ENABLED(CONFIG_ZYNQMP_POWER_DOMAIN)) ||
zynqmp_power_domain zynqmp_power_domain: Request for id: 34
zynqmp_pmufw_node, id 34, ch 0, skp 0 - test 255/815a2fa
zynqmp_pmufw_node, id 11, ch 1, skp 0 - test 255/815a2fa
---zynqmp_pmufw_node ACCESS OK
zynqmp_pmufw_load_config_object
zynqmp_pmufw_load_config_object44
---zynqmp_pmufw_node ACCESS OK
zynqmp_pmufw_load_config_object
zynqmp_pmufw_load_config_object44
zynqmp_power_domain zynqmp_power_domain: Domain ON for id: 34
zynq_serial_setbrg: CLK
U-Boot 2023.07-rc2-00053-gaf7817988644-dirty (May 17 2023 - 14:03:37 +0200)
CPU: ZynqMP
Silicon: v3
Chip: xck26
zynqmp_power_domain zynqmp_power_domain: Request for id: 38
zynqmp_pmufw_node, id 38, ch 1, skp 0 - test 1/815a2fa
---zynqmp_pmufw_node ACCESS OK
zynqmp_pmufw_load_config_object
zynqmp_pmufw_load_config_object44
zynqmp_power_domain zynqmp_power_domain: Domain ON for id: 38
Detected name: zynqmp-smk-k26-xcl2g-revA-sck-kv-g-revB
Model: ZynqMP KV260 revB
Board: Xilinx ZynqMP
DRAM: 2 GiB (effective 4 GiB)
zynqmp_power_domain zynqmp_power_domain: Request for id: 46
zynqmp_pmufw_node, id 46, ch 0, skp 0 - test 0/7ffd42fa
zynqmp_pmufw_node, id 11, ch 1, skp 0 - test 0/7ffd42fa
---zynqmp_pmufw_node ACCESS OK
zynqmp_pmufw_load_config_object
zynqmp_pmufw_load_config_object44
---zynqmp_pmufw_node ACCESS OK
zynqmp_pmufw_load_config_object
zynqmp_pmufw_load_config_object44
zynqmp_power_domain zynqmp_power_domain: Domain ON for id: 46
PMUFW: v1.1
zynqmp_power_domain zynqmp_power_domain: Request for id: 38
zynqmp_pmufw_node, id 38, ch 1, skp 0 - test 1/7ffd42fa
---zynqmp_pmufw_node ACCESS OK
As you see test variable is in BSS section but it is not initialized at this
stage. If you look at arch/arm/lib/crt0_64.S debug uart is called before
calling board_init_f and bss is cleared before board_init_r is called.
What does "but BSS and initialized non-const data are still not available"
mean? Could we use variables from the data section like "static bool check = true"?
Yes - when you move that variable to data section then it should be fine.
Or just move it like this
struct fru_table fru_data __section(".data");
It means variables should be placed to different section or initialized them
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
On Thu, May 18, 2023 at 12:31:51PM +0200, Andrew Jones wrote: > > + # Additional Standard Extensions, sorted by category then alphabetically > > Can we just do pure alphabetically? And the single-letter extensions above > don't have a "sorted by" comment above them. I guess they need one, or > maybe they can also be alphabetical? Maybe it is just me, but my brain is too used to seeing those ones in something approaching canonical order. I'd rather keep them that way & then alphanumerical for everything else? I also noticed that the CMO stuff wasn't actually in the comment's order anyway, so needs a re-sort to begin with. A vote in favour of alphanumerical. signature.asc Description: PGP signature
Re: [PATCH v1] dt-bindings: riscv: deprecate riscv,isa
Hey Drew, On Thu, May 18, 2023 at 12:31:51PM +0200, Andrew Jones wrote: > On Thu, May 18, 2023 at 09:58:30AM +0100, Conor Dooley wrote: > > - riscv,isa: > > -description: > > - Identifies the specific RISC-V instruction set architecture > > - supported by the hart. These are documented in the RISC-V > > - User-Level ISA document, available from > > - https://riscv.org/specifications/ > > - > > - Due to revisions of the ISA specification, some deviations > > - have arisen over time. > > - Notably, riscv,isa was defined prior to the creation of the > > - Zicsr and Zifencei extensions and thus "i" implies > > - "zicsr_zifencei". > > - > > - While the isa strings in ISA specification are case > > - insensitive, letters in the riscv,isa string must be all > > - lowercase to simplify parsing. > > -$ref: "/schemas/types.yaml#/definitions/string" > > -pattern: > > ^rv(?:64|32)imaf?d?q?c?b?k?j?p?v?h?(?:[hsxz](?:[a-z])+)?(?:_[hsxz](?:[a-z])+)*$ > > - > ># RISC-V requires 'timebase-frequency' in /cpus, so disallow it here > >timebase-frequency: false > > > > @@ -133,8 +117,13 @@ properties: > >DMIPS/MHz, relative to highest capacity-dmips-mhz > >in the system. > > > > +oneOf: > > + - required: > > + - riscv,isa > > This is the part Anup keeps reminding me about. We can create better ways > to handle extensions in DT and ACPI, but we'll still need to parse ISA > strings to handle legacy DTs and holdouts that keep creating ISA strings, > at least during the deprecation period, Yeah, we cannot remove the string parser from the kernel as we will break existing users. I don't see keeping it as a problem, we should be nice to people rather than intentionally trip them up. Let them trip themselves up when their implicit meaning doesn't match whatever bit of software they are running's. > since ISA strings are still "the > way to do it" according to the spec. I am not sure what this means, dt-bindings determine the DT ABI, not what RVI puts in specs. > Also, if we assume the wording in the spec does get shored up, then, > unless I'm missing something, the list of advantages for this boolean > proposal from your commit message would be Well, shored up _AND_ adhered to. Actions speak far, far louder than words in that respect unfortunately! > * More character choices for name -- probably not a huge gain for ratified > extensions, since the boolean properties will likely still use the same > name as the ISA string (riscv,isa-extension-). But, for vendor > extensions, this is indeed a major improvement, since vendor extension > boolean property names may need to be extended in unambiguous ways to > handle changes in the extension. > > * Simpler, more complete DT validation (but we still need a best effort > for legacy ISA strings) The "best effort" validation via dt-bindings is the current regex. I've intentionally marked it deprecated, rather than delete it partly for that reason & partly out of consideration for other users. > * Simpler DT parsing (but we still need the current parser for legacy ISA > strings) Speaking only about Linux, we can use these meanings here for interpreting the strings and then apply the fixups that correspond to the difference between the defined meanings & those at the time of the dt-binding originally being merged - unconditionally setting zifencei, zicsr, zicntr, etc. If you don't implement those things, then expect to fall over. Other operating systems etc may have different implicit meanings and their own decisions to make! Oh, and if the "foo" bit of "riscv,isa-extension-foo" doesn't match what you put in riscv,isa then you keep the pieces. For example, if a vendor has a vendor extension Xconor where version 1.0.1 is incompatible with v1.0.0, the properties may be "riscv,isa-extension-xconor" and "riscv,isa-extension-xconor-no-insnx". In that case, for Linux, I would assert that there should/would be no way to get the later version of that extension via riscv,isa. There are no existing situations like this, so no backwards compatibility is broken here. If/when it happens, the property is deprecated and we can direct such cases to the new interface :) Basically the same as: https://lore.kernel.org/linux-riscv/20230504-oncoming-antihero-1ed69bb8f57d@spud/ That reminds me, I need to re-spin that with more extensions set unconditionally. If some new OS comes along, they don't need to implement riscv,isa at all as it's deprecated. I'd like to add another one: * Unified meaning of extensions across bits of software. I actually have no idea what versions of things other OSes map the characters to. > > diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml > > b/Documentation/devicetree/bindings/riscv/extensions.yaml > > new file mode 100644 > > index ..1b4d726f7174 > > --- /dev/null > > +++
Re: U-Boot OMAP GPMC ECC change
Hi Colin, On 17/05/2023 22:39, Colin Foster wrote: > Hi Roger, > > Thanks for the tests. I attached the files and commented in line... but > at the bottom of this email I have some findings... > > On Wed, May 17, 2023 at 04:30:55PM +0300, Roger Quadros wrote: >> Hi Colin, >> >> I just tested this on AM335x EVM which uses BCH8_CODE_HW but 8-bit NAND part. >> I see that you are using 16-bit NAND. >> >> One more difference in u-boot configuration. For me: >> CONFIG_NAND_OMAP_GPMC_PREFETCH=y >> >> Not sure if that matters but let's keep it set for now. >> >> For debug can you please apply the patch (at end) to u-boot at commit >> a95410696d21 >> (before breakage) and run the test. >> > All are attached. > > However I have some other initial findings: > > I swapped in just U-Boot (not the SPL) with your patch, and everything > seems to work! > > The issue of Uncorrectable ECC errors spam came from the SPL. Here's a > snippet of the boot log with the "ecc" print as well as your patch: > Thanks for the tests. Glad to hear issue is narrowed down to SPL. > U-Boot SPL 2023.04-00029-g26a9ce5314-dirty (May 17 2023 - 12:06:49 -0700) > OMAP4460-GP ES1.1 > Trying to boot from NAND > ecc: 2420106 > ecc: ebd922f6 > ecc: 333f844f > ecc: ab812f72 This is clearly the issue. They should all have been 0. > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > ecc: 2420106 > ecc: ebd922f6 > ecc: 333f844f > ecc: ab812f72 > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors > omap-elm: uncorrectable ECC errors Can you please share your spl/u-boot.cfg? We have a stripped down driver "am335x_spl_bch.c" that deals with NAND at SPL. I haven't really looked much at that driver but it relies on omap_gpmc.c for ecc.hwctl() read_buf() ecc.calculate() We didn't do any functional change to these functions in commit 04fcd25873 unless something slipped through the cracks. It seems to rely on following config options CFG_SYS_NAND_ECCPOS CONFIG_SYS_NAND_PAGE_COUNT CONFIG_SYS_NAND_PAGE_SIZE CONFIG_SYS_NAND_5_ADDR_CYCLE CFG_SYS_NAND_ECCSIZE CFG_SYS_NAND_ECCBYTES CONFIG_SYS_NAND_OOBSIZE Could you please share what they are set to for your SPL build? Meanwhile, I'll try to reproduce this on AM335x-EVM. -- cheers, -roger
Re: [PATCH v2 13/13] rockchip: rk3588-rock-5b: Enable boot from SPI NOR flash
Hi Kever,
On 2023-05-18 02:41, Kever Yang wrote:
> Hi Jonas,
>
>
> On 2023/5/18 02:26, Jonas Karlman wrote:
>> Add sfc and flash node to device tree and config options to enable
>> support for booting from SPI NOR flash on Radxa ROCK 5 Model B.
>>
>> Signed-off-by: Jonas Karlman
>> Reviewed-by: Kever Yang
>> ---
>> v2:
>> - Add and use BROM_BOOTSOURCE_SPINOR_RK3588 enum value
>> - Rebased to resolve conflicts
>> - Collect r-b tag
>>
>> arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 24
>> arch/arm/dts/rk3588s-u-boot.dtsi | 20
>> arch/arm/include/asm/arch-rockchip/bootrom.h | 1 +
>> arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
>> configs/rock5b-rk3588_defconfig | 10
>> 5 files changed, 56 insertions(+)
>>
>> diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>> b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>> index db342e6a9391..1cd8a57a6fa6 100644
>> --- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
>> @@ -11,6 +11,7 @@
>> / {
>> aliases {
>> mmc1 =
>> +spi0 =
>> };
>>
>> chosen {
>> @@ -54,6 +55,10 @@
>> bootph-all;
>> };
>>
>> +_pins {
>> +bootph-all;
>> +};
>> +
>>{
>> pinctrl-names = "default";
>> pinctrl-0 = <_pins _reset_h>;
>> @@ -123,6 +128,25 @@
>> pinctrl-0 = <_bus8 _clk _cmd _data_strobe
>> _rstnout>;
>> };
>>
>> + {
>> +bootph-pre-ram;
>> +u-boot,spl-sfc-no-dma;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_pins>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +status = "okay";
>> +
>> +flash@0 {
>> +bootph-pre-ram;
>> +compatible = "jedec,spi-nor";
>> +reg = <0>;
>> +spi-max-frequency = <2400>;
>> +spi-rx-bus-width = <4>;
>> +spi-tx-bus-width = <1>;
>> +};
>> +};
>> +
>> _xfer {
>> bootph-all;
>> };
>> diff --git a/arch/arm/dts/rk3588s-u-boot.dtsi
>> b/arch/arm/dts/rk3588s-u-boot.dtsi
>> index 2c4cad82b38f..64c309046587 100644
>> --- a/arch/arm/dts/rk3588s-u-boot.dtsi
>> +++ b/arch/arm/dts/rk3588s-u-boot.dtsi
>> @@ -165,6 +165,15 @@
>> };
>> };
>>
>> +sfc: spi@fe2b {
>> +compatible = "rockchip,sfc";
>> +reg = <0x0 0xfe2b 0x0 0x4000>;
>> +interrupts = ;
>> +clocks = < SCLK_SFC>, < HCLK_SFC>;
>> +clock-names = "clk_sfc", "hclk_sfc";
>> +status = "disabled";
>> +};
>> +
>> otp: nvmem@fecc {
>> compatible = "rockchip,rk3588-otp";
>> reg = <0x0 0xfecc 0x0 0x400>;
>> @@ -241,3 +250,14 @@
>>{
>> bootph-pre-ram;
>> };
>> +
>> +#ifdef CONFIG_ROCKCHIP_SPI_IMAGE
>> + {
>> +simple-bin-spi {
>> +mkimage {
>> +args = "-n", CONFIG_SYS_SOC, "-T", "rksd";
>> +offset = <0x8000>;
>> +};
>> +};
>> +};
>> +#endif
>> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h
>> b/arch/arm/include/asm/arch-rockchip/bootrom.h
>> index 4276a0f6811a..7dab18fbc3fb 100644
>> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
>> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
>> @@ -48,6 +48,7 @@ enum {
>> BROM_BOOTSOURCE_SPINOR = 3,
>> BROM_BOOTSOURCE_SPINAND = 4,
>> BROM_BOOTSOURCE_SD = 5,
>> +BROM_BOOTSOURCE_SPINOR_RK3588 = 6,
>
> Why we need a new type of SPINOR_RK3588?
Based on my testing I got an unexpected brom_bootdevice_id value when
booting from SPI Flash on my RK3588 ROCK 5B board.
On my RK3568 ROCK 3A board (and other RK3399 boards) brom_bootdevice_id = 3
(SPINOR)
Yet on my RK3588 ROCK 5B board I get brom_bootdevice_id = 6 instead.
RK3568: board_spl_was_booted_from: brom_bootdevice_id 3 maps to
'/spi@fe30/flash@0'
RK3588: board_spl_was_booted_from: brom_bootdevice_id 6 maps to
'/spi@fe2b/flash@0'
I did not find any new define in vendor u-boot for bootdevice_id 6 so do not
really know what we should call this new value, maybe SPINOR2 or SPINOR_ALT?
>
> And this patch not able to apply due to conflict at rk3588s-u-boot.dtsi.
Will resend a rebased version of this patch, I was expecting this to be
applied in a different order :-)
>
>> BROM_BOOTSOURCE_USB = 10,
>> BROM_LAST_BOOTSOURCE = BROM_BOOTSOURCE_USB
>> };
>> diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
>> b/arch/arm/mach-rockchip/rk3588/rk3588.c
>> index 18e67b5ca9b2..b1f535fad505 100644
>> --- a/arch/arm/mach-rockchip/rk3588/rk3588.c
>> +++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
>> @@ -41,6 +41,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1]
>> = {
>> [BROM_BOOTSOURCE_EMMC] = "/mmc@fe2e",
>> [BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
>> [BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
>> +[BROM_BOOTSOURCE_SPINOR_RK3588] = "/spi@fe2b/flash@0",
>
> BROM_BOOTSOURCE_SPINOR is
[PATCH v1] dt-bindings: riscv: deprecate riscv,isa
intro = When the RISC-V dt-bindings were accepted upstream in Linux, the base ISA etc had yet to be ratified. By the ratification of the base ISA, incompatible changes had snuck into the specifications - for example the Zicsr and Zifencei extensions were spun out of the base ISA. Fast forward to today, and the reason for this patch. Currently the riscv,isa dt property permits only a specific subset of the ISA string - in particular it excludes version numbering. With the current constraints, it is not possible to discern whether "rv64i" means that the hart supports the fence.i instruction, for example. Future systems may choose to implement their own instruction fencing, perhaps using a vendor extension, or they may not implement the optional counter extensions. Software needs a way to determine this. versioning schemes == "Use the extension versions that are described in the ISA manual" you may say, and it's not like this has not been considered. Firstly, software that parses the riscv,isa property at runtime will need to contain a lookup table of some sort that maps arbitrary versions to versions it understands. There is not a consistent application of version number applied to extensions, with a higgledy-piggledy collection of tags, "bare" and version documents awaiting the reader on the "recently ratified extensions" page: https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions As an aside, this is reflected in the patch too, since many extensions have yet to appear in a release of the ISA specs, and are defined by commits in their respective "working draft" repositories. Secondly, there is an issue of backwards compatibility, whereby allowing numbers in the ISA string, some parsers may be broken. This would require an additional property to be created to even use the versions in this manner. boolean properties == If a new property is needed, the whole approach may as well be looked at from the bottom up. A string with limited character choices etc is hardly the best approach for communicating extension information to software. Switching to using boolean properties, one per extension, allows us to define explicit meanings for the DT representation of each extension - rather than the current situation where different operating systems or other bits of software may impart different meanings to characters in the string. Clearly the best source of meanings is the specifications themselves, this just provides us the ability to choose at what point in time the meaning is set. If an extension changes incompatibility in the future, a new property will be required. Off-list, some of the RVI folks have committed to shoring up the wording in either the ISA specifications, the riscv-isa-manual or so that in the future, modifications to and additions or removals of features will require a new extension. Codifying that assertion somewhere would make it quite unlikely that compatibility would be broken, but we have the tools required to deal with it, if & when it crops up. It is in our collective interest, as consumers of extension meanings, to define a scheme that enforces compatibility. The use of boolean properties, rather than elements in a string, will also permit validation that the strings have a meaning, as well as potentially reject mutually exclusive combinations, or enforce dependencies between instructions. That would not be possible with the current dt-schema infrastructure for arbitrary strings, as we would need to add a riscv,isa parser to dt-validate! That's not implemented in this patch, but rather left as future work! acpi The current ACPI ECR is based on having a string unfortunately, but ideally ACPI will move to another method, perhaps GUIDs, that give explicit meaning to extensions. parser simplicity = Many systems that parse DT at runtime already implement an function that can check for the presence of boolean properties, rather than having to implement - although unfortunately for backwards compatibility with old dtbs, existing parsers may not be removable - which may greatly simplify dt parsing code. For example, in Linux, checking for an extension becomes as simple as: of_property_present(node, "riscv,isa-extension-zicbom") vendor extensions = Compared to riscv,isa, this proposed scheme promotes vendor extensions, oft touted as the strength of RISC-V, to first-class citizens. At present, extensions are defined as meaning what the RISC-V ISA specifications say they do. There is no realistic way of using that interface to provide cross-platform definitions for what vendor extensions mean. Vendor extensions may also have even less consistency than RVI do in terms of versioning, or no care about backwards compatibility. A boolean property allows us to assign explicit meanings on a per vendor extension basis, backed up by a description of
[PATCH] arm: mach-k3: security: separate out validating binary logic
K3 GP devices allows booting the secure binaries on them by bypassing
the x509 header on them.
ATF and OPTEE firewalling required the rproc_load to be called before
authentication. This change caused the failure for GP devices that
strips off the headers. The boot vector had been set before the headers
were stripped off causing the runtime stripping to fail and stripping
becoming in-effective.
Separate out the secure binary check on GP/HS devices so that the
boot_vector could be stripped before calling rproc_load. This allows
keeping the authentication later when the cluster is on along with
allowing the stripping of the binaries in case of gp devices.
Fixes: 1e00e9be62e5 ("arm: mach-k3: common: re-locate authentication for
atf/optee")
Signed-off-by: Manorit Chawdhry
---
arch/arm/mach-k3/common.c | 5 +
arch/arm/mach-k3/common.h | 1 +
arch/arm/mach-k3/security.c | 32
3 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
index 3c85caee579d..34737a43aa08 100644
--- a/arch/arm/mach-k3/common.c
+++ b/arch/arm/mach-k3/common.c
@@ -347,8 +347,13 @@ void board_fit_image_post_process(const void *fit, int
node, void **p_image,
if ((i != IMAGE_ID_ATF) && (i != IMAGE_ID_OPTEE))
#endif
{
+ ti_secure_image_check_binary(p_image, p_size);
ti_secure_image_post_process(p_image, p_size);
}
+#if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
+ else
+ ti_secure_image_check_binary(p_image, p_size);
+#endif
}
#endif
diff --git a/arch/arm/mach-k3/common.h b/arch/arm/mach-k3/common.h
index e7e59f533b70..899be64a50cb 100644
--- a/arch/arm/mach-k3/common.h
+++ b/arch/arm/mach-k3/common.h
@@ -41,3 +41,4 @@ enum k3_device_type get_device_type(void);
void ti_secure_image_post_process(void **p_image, size_t *p_size);
struct ti_sci_handle *get_ti_sci_handle(void);
void do_board_detect(void);
+void ti_secure_image_check_binary(void **p_image, size_t *p_size);
diff --git a/arch/arm/mach-k3/security.c b/arch/arm/mach-k3/security.c
index 6179f7373aa7..02a2c12dbd6f 100644
--- a/arch/arm/mach-k3/security.c
+++ b/arch/arm/mach-k3/security.c
@@ -38,19 +38,16 @@ static size_t ti_secure_cert_length(void *p_image)
return seq_length + 4;
}
-void ti_secure_image_post_process(void **p_image, size_t *p_size)
+void ti_secure_image_check_binary(void **p_image, size_t *p_size)
{
- struct ti_sci_handle *ti_sci = get_ti_sci_handle();
- struct ti_sci_proc_ops *proc_ops = _sci->ops.proc_ops;
- size_t cert_length;
- u64 image_addr;
u32 image_size;
- int ret;
-
+ size_t cert_length;
image_size = *p_size;
- if (!image_size)
+ if (!image_size) {
+ debug("%s: Image size is %d\n", __func__, image_size);
return;
+ }
if (get_device_type() == K3_DEVICE_TYPE_GP) {
if (ti_secure_cert_detected(*p_image)) {
@@ -78,6 +75,25 @@ void ti_secure_image_post_process(void **p_image, size_t
*p_size)
"This will fail on Security Enforcing(HS-SE) devices\n");
return;
}
+}
+
+void ti_secure_image_post_process(void **p_image, size_t *p_size)
+{
+ struct ti_sci_handle *ti_sci = get_ti_sci_handle();
+ struct ti_sci_proc_ops *proc_ops = _sci->ops.proc_ops;
+ u64 image_addr;
+ u32 image_size;
+ int ret;
+
+ image_size = *p_size;
+ if (!image_size) {
+ debug("%s: Image size is %d\n", __func__, image_size);
+ return;
+ }
+
+ if (get_device_type() != K3_DEVICE_TYPE_HS_SE &&
+ get_device_type() != K3_DEVICE_TYPE_HS_FS)
+ return;
/* Clean out image so it can be seen by system firmware */
image_addr = dma_map_single(*p_image, *p_size, DMA_BIDIRECTIONAL);
---
base-commit: 0a9a4384c1483a88776bca38e28f09be51161034
change-id: 20230512-b4-upstream-atf-optee-am62-gp-20bfcb479ac4
Best regards,
--
Manorit Chawdhry
[PATCH v1 2/2] configs: starfive_visionfive2_defconfig: Update CONFIG_SPL_STACK
SPL runs on the L2 LIM, which is 2M in size mapped at 0x800.This region consists of 16 0x2 sized regions, each one can be used as either L2 cache way or SRAM (not both).From top to bottom, you have way 0-15.The way 0 is always enabled, so SPL can only use at most 0x1e bytes of memory.So, update the value of the CONFIG_SPL_STACK to 0x81C. Signed-off-by: Yanhong Wang --- configs/starfive_visionfive2_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/starfive_visionfive2_defconfig b/configs/starfive_visionfive2_defconfig index ffbc4b9476..fc3d27bbec 100644 --- a/configs/starfive_visionfive2_defconfig +++ b/configs/starfive_visionfive2_defconfig @@ -13,7 +13,7 @@ CONFIG_SYS_PROMPT="StarFive #" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y CONFIG_SPL_MMC=y -CONFIG_SPL_STACK=0x818 +CONFIG_SPL_STACK=0x81C CONFIG_SPL=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y -- 2.17.1
[PATCH v1 1/2] arch: riscv: jh7110: Split the zeroing of L2 LIM on JH7110
The per-hart stack,malloc space and global variable 'gd' sits between
__bss_end and L2_LIM_MEM_END.Zeroing this region could overwrite the
hart's stack, and other harts' stacks.If it were to save and restore
`ra` register, then we would crash in function epilogue. Also, we are
having data-races here, because harts are writing over each other's
stack.
So we should split the zeroing of L2 LIM into different places just
before the region is to be used. For stacks,let each hart clearing its
own stack, and for the malloc space, we can do so during malloc
initialization. The global variable 'gd' is initialized in the
board_init_f_init_reserve function.
Signed-off-by: Yanhong Wang
---
arch/riscv/cpu/jh7110/spl.c | 6 +++---
arch/riscv/cpu/start.S | 14 ++
common/init/board_init.c| 1 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/cpu/jh7110/spl.c b/arch/riscv/cpu/jh7110/spl.c
index 104f0fe949..6a48fba63d 100644
--- a/arch/riscv/cpu/jh7110/spl.c
+++ b/arch/riscv/cpu/jh7110/spl.c
@@ -10,7 +10,6 @@
#include
#define CSR_U74_FEATURE_DISABLE0x7c1
-#define L2_LIM_MEM_END 0x81FUL
int spl_soc_init(void)
{
@@ -42,13 +41,14 @@ void harts_early_init(void)
csr_write(CSR_U74_FEATURE_DISABLE, 0);
/* clear L2 LIM memory
-* set __bss_end to 0x81F region to zero
+* set __bss_end to stack end region to zero
* The L2 Cache Controller supports ECC. ECC is applied to SRAM.
* If it is not cleared, the ECC part is invalid, and an ECC error
* will be reported when reading data.
*/
ptr = (ulong *)&__bss_end;
- len = L2_LIM_MEM_END - (ulong)&__bss_end;
+ len = CONFIG_SPL_STACK - CONFIG_VAL(SYS_MALLOC_F_LEN) - sizeof(*gd) -
+ CONFIG_NR_CPUS * BIT(CONFIG_STACK_SIZE_SHIFT) -
(ulong)&__bss_end;
remain = len % sizeof(ulong);
len /= sizeof(ulong);
diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index dad22bfea8..46da9ec503 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -118,6 +118,20 @@ call_board_init_f_0:
mv sp, a0
#endif
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK) && \
+ defined(CONFIG_STARFIVE_JH7110)
+
+ /* Set the stack region to zero */
+ li t0, 1
+ slli t1, t0, CONFIG_STACK_SIZE_SHIFT
+ mv t0, sp
+ sub t1, t0, t1
+clear_stack:
+ SREGzero, 0(t1)
+ addit1, t1, REGBYTES
+ blt t1, t0, clear_stack
+#endif
+
/* Configure proprietary settings and customized CSRs of harts */
call_harts_early_init:
jal harts_early_init
diff --git a/common/init/board_init.c b/common/init/board_init.c
index 96ffb79a98..46e4e4abc7 100644
--- a/common/init/board_init.c
+++ b/common/init/board_init.c
@@ -162,6 +162,7 @@ void board_init_f_init_reserve(ulong base)
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
/* go down one 'early malloc arena' */
gd->malloc_base = base;
+ memset((void *)base, 0, CONFIG_VAL(SYS_MALLOC_F_LEN));
#endif
if (CONFIG_IS_ENABLED(SYS_REPORT_STACK_F_USAGE))
--
2.17.1
RE: [RFC PATCH] mmc: zynq_sdhci: Dependable card detect
Hi Stefan,
We haven't seen any instability issue so far on ZynqMP boards and no one
reported any such issue till now.
We are already taking care of card detection stability issue with below
waiting logic.
https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/mmc/zynq_sdhci.c#L1161
Could you please answer below questions.
1. is this observed in SPL only or full u-boot ?
2. is this observed in dynamic config case only ? because your patch is in
dynamic path.
3. "On our hardware we get a "Sdhci card detect state not stable" error in the
SPL if no mmc card is present"
Are you seeing stability issue when card is not present ? can you please
elaborate more about the issue.
4. It is not convincing to me that you are trying to select eMMC for some
time and then switching back to SD.
Thanks,
Ashok
> -Original Message-
> From: U-Boot On Behalf Of Stefan
> Herbrechtsmeier
> Sent: Tuesday, May 16, 2023 7:51 PM
> To: u-boot@lists.denx.de
> Cc: Stefan Herbrechtsmeier ;
> Jaehoon Chung ; Simek, Michal
> ; Peng Fan
> Subject: [RFC PATCH] mmc: zynq_sdhci: Dependable card detect
>
> CAUTION: This message has originated from an External Source. Please use
> proper judgment and caution when opening attachments, clicking links, or
> responding to this email.
>
>
> From: Stefan Herbrechtsmeier
>
> The card detect logic needs a short card present signal to work dependable.
> Without a present card the SDHCI_CARD_STATE_STABLE signal is not set
> dependable after a reset. Use the internal fixed card present signal to
> initiate
> the card detect logic.
>
> Signed-off-by: Stefan Herbrechtsmeier
>
>
> ---
> On our hardware we get a "Sdhci card detect state not stable" error in the SPL
> if no mmc card is present. It is unclear if this patch is the correct
> solution, but
> a short card inserts or a fixed card present signal leads to a
> SDHCI_CARD_STATE_STABLE signal with and without card.
>
> drivers/mmc/zynq_sdhci.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c index
> e44868aaec..a88feeb367 100644
> --- a/drivers/mmc/zynq_sdhci.c
> +++ b/drivers/mmc/zynq_sdhci.c
> @@ -1075,6 +1075,26 @@ static int
> sdhci_zynqmp_set_dynamic_config(struct arasan_sdhci_priv *priv,
> return ret;
> }
>
> + /* The card detect logic needs a short card present signal to work
> +* dependable. Without a present card the SDHCI_CARD_STATE_STABLE
> +* signal is not set dependable after a reset. Use the internal
> +* fixed card present signal to initiate the card detect logic.
> +*/
> + if (!dev_read_bool(dev, "non-removable")) {
> + ret = zynqmp_pm_set_sd_config(priv->node_id,
> SD_CONFIG_EMMC_SEL,
> + 1);
> + if (ret) {
> + dev_err(dev, "SD_CONFIG_EMMC_SEL failed\n");
> + return ret;
> + }
> + ret = zynqmp_pm_set_sd_config(priv->node_id,
> SD_CONFIG_EMMC_SEL,
> + 0);
> + if (ret) {
> + dev_err(dev, "SD_CONFIG_EMMC_SEL failed\n");
> + return ret;
> + }
> + }
> +
> return 0;
> }
> #endif
> --
> 2.30.2
