Re: [PATCH 2/2] rockchip: Add option to prevent booting on power plug-in
On 5/24/22 04:30, Chris Morgan wrote:
> From: Chris Morgan
>
> For Rockchip boards with the all rk8xx series PMICs (excluding the
> rk808), it is sometimes desirable to not boot whenever the device is
> plugged in. An example would be for the Odroid Go Advance.
>
> This provides a configurable option to check the PMIC says it was
> powered because of a plug-in event. If the value is 1 and this option
> is selected, the device shuts down shortly after printing a message
> to console stating the reason why it's shutting down. Powering up the
> board with the power button is not affected.
>
> This patch parallels the work done in the following patch series:
> https://lore.kernel.org/u-boot/20220121133732.2397273-1-andre.przyw...@arm.com/
>
> Signed-off-by: Chris Morgan
> ---
> arch/arm/mach-rockchip/Kconfig | 10 +
> drivers/power/pmic/rk8xx.c | 37 ++
> include/power/rk8xx_pmic.h | 3 +++
> 3 files changed, 50 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/Kconfig b/arch/arm/mach-rockchip/Kconfig
> index 18aff5480b..c561a77e6a 100644
> --- a/arch/arm/mach-rockchip/Kconfig
> +++ b/arch/arm/mach-rockchip/Kconfig
> @@ -361,6 +361,16 @@ config ROCKCHIP_BOOT_MODE_REG
> The Soc will enter to different boot mode(defined in
> asm/arch-rockchip/boot_mode.h)
> according to the value from this register.
>
> +config ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON
> + bool "Disable device boot on power plug-in"
> + depends on PMIC_RK8XX
> + default n
> + ---help---
> + Say Y here to prevent the device from booting up because of a plug-in
> + event. When set, the device will boot briefly to determine why it was
> + powered on, and if it was determined because of a plug-in event
> + instead of a button press event it will shut back off.
> +
> config ROCKCHIP_STIMER
> bool "Rockchip STIMER support"
> default y
> diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> index 1ffbecc02a..b59675a10e 100644
> --- a/drivers/power/pmic/rk8xx.c
> +++ b/drivers/power/pmic/rk8xx.c
> @@ -51,6 +51,41 @@ U_BOOT_DRIVER(rk8xx_sysreset) = {
> .ops= _sysreset_ops,
> };
>
> +void rk8xx_off_for_plugin(struct udevice *dev)
> +/* In the event of a plug-in and the appropriate option has been
> + * selected, we simply shutdown instead of continue the normal boot
> + * process. Please note the rk808 is not supported as it doesn't
> + * have the appropriate register.
> + */
Could you move comment to above or into function?
> +{
> + struct rk8xx_priv *priv = dev_get_priv(dev);
> + bool plug_in = 0;
> +
> + switch (priv->variant) {
> + case RK805_ID:
> + case RK816_ID:
> + case RK818_ID:
> + plug_in = pmic_reg_read(dev, RK8XX_ON_SOURCE) &
> RK8XX_ON_PLUG_IN;
> + if (plug_in) {
It seems that doesn't need to use plug_in. Can't use "if (pmic_reg_read() &
RK8XX_ON_PLUG_IN)"?
Best Regards,
Jaehoon Chung
> + printf("Power Off due to plug-in event\n");
> + pmic_clrsetbits(dev, REG_DEVCTRL, 0, BIT(0));
> + }
> + break;
> + case RK809_ID:
> + case RK817_ID:
> + plug_in = pmic_reg_read(dev, RK817_ON_SOURCE) &
> RK8XX_ON_PLUG_IN;
> + if (plug_in) {
> + printf("Power Off due to plug-in event\n");
> + pmic_clrsetbits(dev, RK817_REG_SYS_CFG3, 0,
> + BIT(0));
> + }
> + break;
> + default:
> + printf("PMIC RK%x: Cannot read boot reason.\n",
> +priv->variant);
> + }
> +}
> +
> static struct reg_data rk817_init_reg[] = {
> /* enable the under-voltage protection,
> * the under-voltage protection will shutdown the LDO3 and reset the PMIC
> @@ -211,6 +246,8 @@ static int rk8xx_probe(struct udevice *dev)
> pmic_reg_read(dev, on_source),
> pmic_reg_read(dev, off_source));
> printf("\n");
> + if (CONFIG_IS_ENABLED(ROCKCHIP_RK8XX_DISABLE_BOOT_ON_POWERON))
> + rk8xx_off_for_plugin(dev);
>
> return 0;
> }
> diff --git a/include/power/rk8xx_pmic.h b/include/power/rk8xx_pmic.h
> index 8ff0af35c5..3cbfc02195 100644
> --- a/include/power/rk8xx_pmic.h
> +++ b/include/power/rk8xx_pmic.h
> @@ -214,6 +214,9 @@ enum {
> #define RK817_ON_SOURCE 0xf5
> #define RK817_OFF_SOURCE 0xf6
>
> +#define RK8XX_ON_PWRON BIT(7)
> +#define RK8XX_ON_PLUG_IN BIT(6)
> +
> struct reg_data {
> u8 reg;
> u8 val;
Re: [PATCH 1/2] power: pmic: rk8xx: Support sysreset shutdown method
On 5/24/22 04:30, Chris Morgan wrote:
> From: Chris Morgan
>
> Add support for sysreset shutdown for this PMIC. The values were pulled
> from the various datasheets, but for now it has only been tested on
> the rk817 (for an Odroid Go Advance).
>
> Signed-off-by: Chris Morgan
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/power/pmic/rk8xx.c | 50 +-
> 1 file changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/pmic/rk8xx.c b/drivers/power/pmic/rk8xx.c
> index 5f442fea68..1ffbecc02a 100644
> --- a/drivers/power/pmic/rk8xx.c
> +++ b/drivers/power/pmic/rk8xx.c
> @@ -6,10 +6,50 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> #include
> +#include
> +
> +static int rk8xx_sysreset_request(struct udevice *dev, enum sysreset_t type)
> +{
> + struct rk8xx_priv *priv = dev_get_priv(dev->parent);
> +
> + if (type != SYSRESET_POWER_OFF)
> + return -EPROTONOSUPPORT;
> +
> + switch (priv->variant) {
> + case RK805_ID:
> + case RK808_ID:
> + case RK816_ID:
> + case RK818_ID:
> + pmic_clrsetbits(dev->parent, REG_DEVCTRL, 0, BIT(0));
> + break;
> + case RK809_ID:
> + case RK817_ID:
> + pmic_clrsetbits(dev->parent, RK817_REG_SYS_CFG3, 0,
> + BIT(0));
> + break;
> + default:
> + printf("Unknown PMIC RK%x: Cannot shutdown\n",
> +priv->variant);
> + return -EPROTONOSUPPORT;
> + };
> +
> + return -EINPROGRESS;
> +}
> +
> +static struct sysreset_ops rk8xx_sysreset_ops = {
> + .request= rk8xx_sysreset_request,
> +};
> +
> +U_BOOT_DRIVER(rk8xx_sysreset) = {
> + .name = "rk8xx_sysreset",
> + .id = UCLASS_SYSRESET,
> + .ops= _sysreset_ops,
> +};
>
> static struct reg_data rk817_init_reg[] = {
> /* enable the under-voltage protection,
> @@ -61,7 +101,7 @@ static int rk8xx_read(struct udevice *dev, uint reg,
> uint8_t *buff, int len)
> static int rk8xx_bind(struct udevice *dev)
> {
> ofnode regulators_node;
> - int children;
> + int children, ret;
>
> regulators_node = dev_read_subnode(dev, "regulators");
> if (!ofnode_valid(regulators_node)) {
> @@ -72,6 +112,14 @@ static int rk8xx_bind(struct udevice *dev)
>
> debug("%s: '%s' - found regulators subnode\n", __func__, dev->name);
>
> + if (CONFIG_IS_ENABLED(SYSRESET)) {
> + ret = device_bind_driver_to_node(dev, "rk8xx_sysreset",
> + "rk8xx_sysreset",
> + dev_ofnode(dev), NULL);
> + if (ret)
> + return ret;
> + }
> +
> children = pmic_bind_children(dev, regulators_node, pmic_children_info);
> if (!children)
> debug("%s: %s - no child found\n", __func__, dev->name);
[PATCH v2] ARM: dts: sun4i: Sync from Linux v5.18-rc1
Copy the devicetree source for the A10 SoC and all existing boards
verbatim from the Linux v5.18-rc1 tag.
The previous version of this change was only partially applied.
Fixes: 4746694cba74 ("ARM: dts: sun4i: Sync from Linux v5.18-rc1")
Signed-off-by: Samuel Holland
---
Changes in v2:
- Rebased. The commit that was sent in Andre's PR only contained
changes from one file -- the one with the character set change.
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/axp209.dtsi | 6 +-
arch/arm/dts/sun4i-a10-a1000.dts | 31 ++-
arch/arm/dts/sun4i-a10-ba10-tvbox.dts | 2 +-
arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts| 20 +-
arch/arm/dts/sun4i-a10-cubieboard.dts | 16 +-
arch/arm/dts/sun4i-a10-dserve-dsrv9703c.dts | 21 +-
arch/arm/dts/sun4i-a10-hackberry.dts | 2 +-
arch/arm/dts/sun4i-a10-hyundai-a7hd.dts | 20 +-
arch/arm/dts/sun4i-a10-inet1.dts | 21 +-
arch/arm/dts/sun4i-a10-inet9f-rev03.dts | 74 ++
.../dts/sun4i-a10-itead-iteaduino-plus.dts| 2 +-
arch/arm/dts/sun4i-a10-jesurun-q5.dts | 4 +-
arch/arm/dts/sun4i-a10-marsboard.dts | 22 +-
arch/arm/dts/sun4i-a10-olinuxino-lime.dts | 33 +--
arch/arm/dts/sun4i-a10-pcduino.dts| 20 +-
arch/arm/dts/sun4i-a10-pov-protab2-ips9.dts | 21 +-
arch/arm/dts/sun4i-a10-topwise-a721.dts | 242 ++
arch/arm/dts/sun4i-a10.dtsi | 135 +-
19 files changed, 459 insertions(+), 236 deletions(-)
create mode 100644 arch/arm/dts/sun4i-a10-topwise-a721.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 0a2713c06a3c..1bceae78c3c1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -539,7 +539,8 @@ dtb-$(CONFIG_MACH_SUN4I) += \
sun4i-a10-olinuxino-lime.dtb \
sun4i-a10-pcduino.dtb \
sun4i-a10-pcduino2.dtb \
- sun4i-a10-pov-protab2-ips9.dtb
+ sun4i-a10-pov-protab2-ips9.dtb \
+ sun4i-a10-topwise-a721.dtb
dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-auxtek-t003.dtb \
sun5i-a10s-auxtek-t004.dtb \
diff --git a/arch/arm/dts/axp209.dtsi b/arch/arm/dts/axp209.dtsi
index 0d9ff12bdf28..ca240cd6f6c3 100644
--- a/arch/arm/dts/axp209.dtsi
+++ b/arch/arm/dts/axp209.dtsi
@@ -53,7 +53,7 @@
interrupt-controller;
#interrupt-cells = <1>;
- ac_power_supply: ac-power-supply {
+ ac_power_supply: ac-power {
compatible = "x-powers,axp202-ac-power-supply";
status = "disabled";
};
@@ -69,7 +69,7 @@
#gpio-cells = <2>;
};
- battery_power_supply: battery-power-supply {
+ battery_power_supply: battery-power {
compatible = "x-powers,axp209-battery-power-supply";
status = "disabled";
};
@@ -112,7 +112,7 @@
};
};
- usb_power_supply: usb-power-supply {
+ usb_power_supply: usb-power {
compatible = "x-powers,axp202-usb-power-supply";
status = "disabled";
};
diff --git a/arch/arm/dts/sun4i-a10-a1000.dts b/arch/arm/dts/sun4i-a10-a1000.dts
index 6c254ec4c85b..20f9ed244851 100644
--- a/arch/arm/dts/sun4i-a10-a1000.dts
+++ b/arch/arm/dts/sun4i-a10-a1000.dts
@@ -60,15 +60,26 @@
stdout-path = "serial0:115200n8";
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
- red {
+ led-0 {
label = "a1000:red:usr";
gpios = < 7 10 GPIO_ACTIVE_HIGH>;
};
- blue {
+ led-1 {
label = "a1000:blue:pwr";
gpios = < 7 20 GPIO_ACTIVE_HIGH>;
default-state = "on";
@@ -125,7 +136,7 @@
};
{
- phy = <>;
+ phy-handle = <>;
status = "okay";
};
@@ -133,6 +144,20 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
{
status = "okay";
diff --git a/arch/arm/dts/sun4i-a10-ba10-tvbox.dts
b/arch/arm/dts/sun4i-a10-ba10-tvbox.dts
index 38a2c4134952..816d534ac093 100644
--- a/arch/arm/dts/sun4i-a10-ba10-tvbox.dts
+++ b/arch/arm/dts/sun4i-a10-ba10-tvbox.dts
@@ -68,7 +68,7 @@
};
{
- phy = <>;
+ phy-handle = <>;
status = "okay";
};
diff --git a/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts
b/arch/arm/dts/sun4i-a10-chuwi-v7-cw0825.dts
index cf7b392dff31..7426291c 100644
---
Re: Vulnerability Disclosure in net/
On Wed, May 18, 2022 at 7:14 PM Nicolas Bidron
wrote:
>
> Hello,
>
> We found a couple of bugs in net/net.s in the IP defragmentation
> function __net_defragment(). Below the writeup for the 2 bugs:
>
> ---BUG 1---
>
> # Hole Descriptor Overwrite in U-Boot IP Packet Defragmentation Leads to
> Arbitrary Out of Bounds Write Primitive (CVE-TBD)
>
> | | |
> | --- | --- |
> |Project | U-Boot |
> |Project URL | https://github.com/u-boot/u-boot |
> |Versions affected | all versions up to commit TBD |
> |Systems affected | All systems defining `CONFIG_IP_DEFRAG` |
> |CVE identifier | TBD |
> |Advisory URL | TBD |
> |Risk | Critical 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) |
> |Authors | Nicolas Guigo, Nicolas Bidron |
>
> ### Summary
>
> U-boot is a popular boot loader for embedded systems with
> implementations for a large number of architectures and prominent in
> most linux based embedded systems.
>
> ### Location
>
> In `u-boot/net/net.c` the `__net_defragment` function line 900 through 1018.
>
> ### Impact
>
> The U-Boot implementation of
> [RFC815](https://datatracker.ietf.org/doc/html/rfc815) IP DATAGRAM
> REASSEMBLY ALGORITHMS is susceptible to a Hole Descriptor overwrite
> attack which ultimately leads to an arbitrary write primitve.
>
> ### Description
>
> In compiled versions of U-Boot that define CONFIG_IP_DEFRAG, a value of
> `ip->ip_len` (IP packet header's Total Length) higher than `IP_HDR_SIZE`
> and strictly lower than `IP_HDR_SIZE+8` will lead to a value for `len`
> comprised between `0` and `7`. This will ultimately result in a
> truncated division by `8` resulting value of `0` forcing the hole
> metadata and fragment to point to the same location. The subsequent
> memcopy will overwrite the hole metadata with the fragment data. Through
> a second fragment, this can be exploited to write to an arbitrary offset
> controlled by that overwritten hole metadata value.
>
> This bug is only exploitable locally as it requires crafting two packets
> the first of which would most likely be dropped through routing due to
> its unexpectedly low Total Length. However, this bug can potentially be
> exploited to root linux based embedded devices locally.
>
> ```C
> static struct ip_udp_hdr *__net_defragment(struct ip_udp_hdr *ip, int *lenp)
> {
> static uchar pkt_buff[IP_PKTSIZE] __aligned(PKTALIGN);
> static u16 first_hole, total_len;
> struct hole *payload, *thisfrag, *h, *newh;
> struct ip_udp_hdr *localip = (struct ip_udp_hdr *)pkt_buff;
> uchar *indata = (uchar *)ip;
> int offset8, start, len, done = 0;
> u16 ip_off = ntohs(ip->ip_off);
>
> /* payload starts after IP header, this fragment is in there */
> payload = (struct hole *)(pkt_buff + IP_HDR_SIZE);
> offset8 = (ip_off & IP_OFFS);
> thisfrag = payload + offset8;
> start = offset8 * 8;
> len = ntohs(ip->ip_len) - IP_HDR_SIZE;
> ```
>
> The last line of the previous excerpt from `u-boot/net/net.c` shows how
> the attacker can control the value of `len` to be strictly lower than
> `8` by issuing a packet with `ip_len` between `21` and `27`
> (`IP_HDR_SIZE` has a value of `20`).
>
> Also note that `offset8` here is `0` which leads to `thisfrag = payload`.
>
> ```C
> } else if (h >= thisfrag) {
> /* overlaps with initial part of the hole: move this hole */
> newh = thisfrag + (len / 8);
> *newh = *h;
> h = newh;
> if (h->next_hole)
> payload[h->next_hole].prev_hole = (h - payload);
> if (h->prev_hole)
> payload[h->prev_hole].next_hole = (h - payload);
> else
> first_hole = (h - payload);
>
> } else {
> ```
>
> Lower down the same function, execution reaches the above code path.
> Here, `len / 8` evaluates to `0` leading to `newh = thisfrag`. Also note
> that `first_hole` here is `0` since `h` and `payload` point to the same
> location.
>
> ```C
> /* finally copy this fragment and possibly return whole packet */
> memcpy((uchar *)thisfrag, indata + IP_HDR_SIZE, len);
> ```
>
> Finally, in the above excerpt the `memcpy` overwrites the hole metadata
> since `thisfrag` and `h` both point to the same location. The hole
> metadata is effectively overwritten with arbitrary data from the
> fragmented IP packet data. If `len` was crafted to be `6`, `last_byte`,
> `next_hole`, and `prev_hole` of the `first_hole` can be controlled by
> the attacker.
>
> Finally the arbitrary offset write occurs through a second fragment that
> only needs to be crafted to write data in the hole pointed to by the
> previously controlled hole metadata (`next_hole`) from the first packet.
>
> ### Recommendation
>
> Handle cases where `len` is strictly lower than 8 by preventing the
> overwrite of the hole metadata during the memcpy of the fragment. This
> could be achieved by either:
> * Moving the location where the hole metadata is stored when `len` is
> lower than `8`.
Re: [PATCH 0/2] fix issues in bootmenu after adding efi entries
Hi Pali, On Thu, 26 May 2022 at 05:11, Pali Rohar wrote: > > On Wednesday 25 May 2022 17:18:11 Masahisa Kojima wrote: > > This series fixes the issue in bootmenu after adding efi entries. > > > > Masahisa Kojima (2): > > bootmenu: use utf-8 for menu title > > bootmenu: U-Boot console is enabled as default > > > > boot/Kconfig | 9 + > > cmd/Kconfig| 10 -- > > cmd/bootmenu.c | 40 +++- > > 3 files changed, 32 insertions(+), 27 deletions(-) > > > > -- > > 2.17.1 > > > > I have tested these two patches and bootmenu is working on n900 again! > > Tested-by: Pali Rohár Thank you very much for your testing. Regards, Masahisa Kojima
Re: [PATCH 0/2] fix issues in bootmenu after adding efi entries
On Wednesday 25 May 2022 17:18:11 Masahisa Kojima wrote: > This series fixes the issue in bootmenu after adding efi entries. > > Masahisa Kojima (2): > bootmenu: use utf-8 for menu title > bootmenu: U-Boot console is enabled as default > > boot/Kconfig | 9 + > cmd/Kconfig| 10 -- > cmd/bootmenu.c | 40 +++- > 3 files changed, 32 insertions(+), 27 deletions(-) > > -- > 2.17.1 > I have tested these two patches and bootmenu is working on n900 again! Tested-by: Pali Rohár
Re: [PATCH v2] arm: socfpga: Add the terasic de10-standard board
Thank you! On Wed, May 25, 2022 at 7:02 AM Marek Vasut wrote: > > On 5/23/22 03:54, Humberto Naves wrote: > > Use the de10-nano files as templates for the de10-standard board. > > The files in qts directory are generated by quartus from the GHRD > > design. > > Applied, thanks.
Re: [u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
On 5/25/22 3:30 AM, Roger Quadros wrote:
Hi Andrew,
On 25/05/2022 01:03, Andrew Davis wrote:
On 5/9/22 2:29 AM, Roger Quadros wrote:
Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
R5 build is still not converted to use binman so restrict binman.dtsi
to A53 builds only.
This patch also take care of building Secure (HS) images using
binman instead of tools/k3_fit_atf.sh if CONFIG_BINMAN is set.
Signed-off-by: Roger Quadros
---
arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++
arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 +
arch/arm/mach-k3/Kconfig | 1 +
arch/arm/mach-k3/config.mk | 7 +
4 files changed, 241 insertions(+)
create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi
diff --git a/arch/arm/dts/k3-am642-evm-binman.dtsi
b/arch/arm/dts/k3-am642-evm-binman.dtsi
new file mode 100644
index 00..9e85ef41b0
--- /dev/null
+++ b/arch/arm/dts/k3-am642-evm-binman.dtsi
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/ {
+ binman: binman {
+ multiple-images;
+ };
+};
+
+#ifdef CONFIG_TARGET_AM642_A53_EVM
+
+#ifdef CONFIG_TI_SECURE_DEVICE
+#define TISPL "tispl.bin_HS"
+#define UBOOT_IMG "u-boot.img_HS"
+#else
+#define TISPL "tispl.bin"
+#define UBOOT_IMG "u-boot.img"
+#endif
+
+#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
+#define SPL_AM642_EVM_DTB "spl/dts/k3-am642-evm.dtb"
+#define SPL_AM642_SK_DTB "spl/dts/k3-am642-sk.dtb"
+
+#define UBOOT_NODTB "u-boot-nodtb.bin"
+#define AM642_EVM_DTB "arch/arm/dts/k3-am642-evm.dtb"
+#define AM642_SK_DTB "arch/arm/dts/k3-am642-sk.dtb"
+
+ {
+ ti-spl {
+ filename = TISPL;
+ pad-byte = <0xff>;
+
+ fit {
+ description = "Configuration to load ATF and SPL";
+ #address-cells = <1>;
+
+ images {
+
+ atf {
+ description = "ARM Trusted Firmware";
+ type = "firmware";
+ arch = "arm64";
+ compression = "none";
+ os = "arm-trusted-firmware";
+ load = ;
+ entry = ;
+ atf-bl31 {
+ filename = "bl31.bin";
+ };
On HS, bl31.bin and the below TEE and DM images must also be signed
before being packaged into tispl.bin.
Can we add signing here?
I'm wondering how this is working as is on HS boards.
Today we manually sign those two before we feed them to U-Boot build.
I'd like to fix that and have them signed along with all the other
parts here when packaging them together.
Another thing to note is that the atf and tee entries take into consideration
the below environment variables
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
How do we continue to support that while adding the signing bits?
That's my question also, I'm not sure how we would make the type 'ti-secure'
while also changing their path names, seems like a limitation currently
of using etypes to do the signing, since we can do path renames from
command line.
Andrew
cheers,
-roger
Andrew
+ };
+
+ tee {
+ description = "OPTEE";
+ type = "tee";
+ arch = "arm64";
+ compression = "none";
+ os = "tee";
+ load = <0x9e80>;
+ entry = <0x9e80>;
+ tee-os {
+ filename = "tee-pager_v2.bin";
+ };
+ };
+
+ 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 = <0x8008>;
+ entry = <0x8008>;
+#ifdef CONFIG_TI_SECURE_DEVICE
+ ti-secure {
+#else
+ blob {
+#endif
+ filename = SPL_NODTB;
+ };
+ };
+
+ fdt-1 {
+ description = "k3-am642-evm";
+ type = "flat_dt";
+ arch = "arm";
+ compression = "none";
+#ifdef CONFIG_TI_SECURE_DEVICE
+ ti-secure {
+#else
+ blob {
+#endif
+ filename =
[PATCH v3 2/3] usb: add isp1760 family driver
ISP1760/61/63 are a family of usb controllers, here the main
goal is to support the ISP1763 hcd part found in the MPS3 FPGA
board form Arm. This is based on the kernel driver and ported
to u-boot.
Signed-off-by: Rui Miguel Silva
---
Makefile|1 +
drivers/usb/Kconfig |2 +
drivers/usb/common/Makefile |1 +
drivers/usb/isp1760/Kconfig | 12 +
drivers/usb/isp1760/Makefile|6 +
drivers/usb/isp1760/isp1760-core.c | 380
drivers/usb/isp1760/isp1760-core.h | 96 ++
drivers/usb/isp1760/isp1760-hcd.c | 2477 +++
drivers/usb/isp1760/isp1760-hcd.h | 81 +
drivers/usb/isp1760/isp1760-if.c| 125 ++
drivers/usb/isp1760/isp1760-regs.h | 292
drivers/usb/isp1760/isp1760-uboot.c | 75 +
drivers/usb/isp1760/isp1760-uboot.h | 27 +
13 files changed, 3575 insertions(+)
create mode 100644 drivers/usb/isp1760/Kconfig
create mode 100644 drivers/usb/isp1760/Makefile
create mode 100644 drivers/usb/isp1760/isp1760-core.c
create mode 100644 drivers/usb/isp1760/isp1760-core.h
create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
create mode 100644 drivers/usb/isp1760/isp1760-if.c
create mode 100644 drivers/usb/isp1760/isp1760-regs.h
create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
create mode 100644 drivers/usb/isp1760/isp1760-uboot.h
diff --git a/Makefile b/Makefile
index 61927f8918b4..c577ead0afc2 100644
--- a/Makefile
+++ b/Makefile
@@ -841,6 +841,7 @@ libs-y += drivers/usb/host/
libs-y += drivers/usb/mtu3/
libs-y += drivers/usb/musb/
libs-y += drivers/usb/musb-new/
+libs-y += drivers/usb/isp1760/
libs-y += drivers/usb/phy/
libs-y += drivers/usb/ulpi/
ifdef CONFIG_POST
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index ab1d061bd0d5..86804166de3e 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -68,6 +68,8 @@ config SPL_DM_USB_GADGET
source "drivers/usb/host/Kconfig"
+source "drivers/usb/isp1760/Kconfig"
+
source "drivers/usb/cdns3/Kconfig"
source "drivers/usb/dwc3/Kconfig"
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index dc05cb0a5077..f08b064d2493 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,6 +4,7 @@
#
obj-$(CONFIG_$(SPL_)DM_USB) += common.o
+obj-$(CONFIG_USB_ISP1760) += usb_urb.o
obj-$(CONFIG_USB_MUSB_HCD) += usb_urb.o
obj-$(CONFIG_USB_MUSB_UDC) += usb_urb.o
obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
diff --git a/drivers/usb/isp1760/Kconfig b/drivers/usb/isp1760/Kconfig
new file mode 100644
index ..993d71e74cd2
--- /dev/null
+++ b/drivers/usb/isp1760/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config USB_ISP1760
+ tristate "NXP ISP 1760/1761/1763 support"
+ select DM_USB
+ select USB_HOST
+ help
+ Say Y or M here if your system as an ISP1760/1761/1763 USB host
+ controller.
+
+ This USB controller is usually attached to a non-DMA-Master
+ capable bus.
diff --git a/drivers/usb/isp1760/Makefile b/drivers/usb/isp1760/Makefile
new file mode 100644
index ..2c809c01b118
--- /dev/null
+++ b/drivers/usb/isp1760/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+isp1760-y := isp1760-core.o isp1760-if.o isp1760-uboot.o isp1760-hcd.o
+
+#isp1760-hcd.o
+
+obj-$(CONFIG_USB_ISP1760) += isp1760.o
diff --git a/drivers/usb/isp1760/isp1760-core.c
b/drivers/usb/isp1760/isp1760-core.c
new file mode 100644
index ..31dfdae6c995
--- /dev/null
+++ b/drivers/usb/isp1760/isp1760-core.c
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Driver for the NXP ISP1760 chip
+ *
+ * Copyright 2022 Linaro, Rui Miguel Silva
+ *
+ * This is based on linux kernel driver, original developed:
+ * Copyright 2014 Laurent Pinchart
+ * Copyright 2007 Sebastian Siewior
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "isp1760-core.h"
+#include "isp1760-hcd.h"
+#include "isp1760-regs.h"
+
+#define msleep(a) udelay((a) * 1000)
+
+static int isp1760_init_core(struct isp1760_device *isp)
+{
+ struct isp1760_hcd *hcd = >hcd;
+
+ /*
+* Reset the host controller, including the CPU interface
+* configuration.
+*/
+ isp1760_field_set(hcd->fields, SW_RESET_RESET_ALL);
+ msleep(100);
+
+ /* Setup HW Mode Control: This assumes a level active-low interrupt */
+ if ((isp->devflags & ISP1760_FLAG_ANALOG_OC) && hcd->is_isp1763)
+ return -EINVAL;
+
+ if (isp->devflags & ISP1760_FLAG_BUS_WIDTH_16)
+ isp1760_field_clear(hcd->fields, HW_DATA_BUS_WIDTH);
+ if (isp->devflags & ISP1760_FLAG_BUS_WIDTH_8)
+ isp1760_field_set(hcd->fields, HW_DATA_BUS_WIDTH);
+ if (isp->devflags & ISP1760_FLAG_ANALOG_OC)
+
Re: [PATCH v1] fdt: Add U-Boot version to chosen node
On Wed, May 25, 2022 at 08:16:20AM +, Marcel Ziswiler wrote: > Hi Tom > > On Thu, 2022-05-19 at 13:24 -0400, Tom Rini wrote: > > On Thu, May 19, 2022 at 04:25:48PM +0200, Francesco Dolcini wrote: > > > On Thu, May 19, 2022 at 04:22:26PM +0200, Francesco Dolcini wrote: > > > > Add a new device tree property "u-boot,version" in the chosen node to > > > > pass the U-Boot version to the operating system. > > > > This can be useful to implement a firmware upgrade procedure from the > > > > operating system. > > > > > > Related change in dt-schema is available here: > > > https://github.com/devicetree-org/dt-schema/pull/74 > > > > Reviewed-by: Tom Rini > > Anybody dare to apply that one? Thanks! I've reviewed this side, and I'm subscribed to the pull request side. The way this worked last time is Rob took the PR then I took the U-Boot change. It's only been 6 days so I assume Rob will take it soon. -- Tom signature.asc Description: PGP signature
[PATCH] qfw: Don't fail if setup data size is 0
Skip missing setup data (which is valid) rather than failing with an
error.
Cc: Bin Meng
Cc: Simon Glass
Reported-by: Andrew Walbran
Signed-off-by: Pierre-Clément Tosi
---
cmd/qfw.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/cmd/qfw.c b/cmd/qfw.c
index d58615040c..ccbc967ca9 100644
--- a/cmd/qfw.c
+++ b/cmd/qfw.c
@@ -25,15 +25,17 @@ static int qemu_fwcfg_cmd_setup_kernel(void *load_addr,
void *initrd_addr)
qfw_read_entry(qfw_dev, FW_CFG_SETUP_SIZE, 4, _size);
qfw_read_entry(qfw_dev, FW_CFG_KERNEL_SIZE, 4, _size);
- if (setup_size == 0 || kernel_size == 0) {
+ if (kernel_size == 0) {
printf("warning: no kernel available\n");
return -1;
}
data_addr = load_addr;
- qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
- le32_to_cpu(setup_size), data_addr);
- data_addr += le32_to_cpu(setup_size);
+ if (setup_size != 0) {
+ qfw_read_entry(qfw_dev, FW_CFG_SETUP_DATA,
+ le32_to_cpu(setup_size), data_addr);
+ data_addr += le32_to_cpu(setup_size);
+ }
qfw_read_entry(qfw_dev, FW_CFG_KERNEL_DATA,
le32_to_cpu(kernel_size), data_addr);
--
2.36.1.124.g0e6072fb45-goog
[Rock Pi 4+] Mainline LPDDR4 RAM initialisation is not sufficient to boot successfully
Good afternoon, There appear to be a number of issues with the Rockchip rk3399 DDR RAM initialisation sequence in Mainline. Specifically, I'm seeing consistent failures on the Rock Pi 4+ during early boot. A typical failure looks something like this: U-Boot TPL 2022.07-rc3-5-g1b04a961c6 (May 25 2022 - 11:09:19) Channel 0: LPDDR4, 50MHz BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB Channel 1: col error Cap error! 256B stride lpddr4_set_rate: change freq to 4 mhz 0, 1 lpddr4_set_rate: change freq to 8 mhz 1, 0 Trying to boot from BOOTROM Returning to boot ROM... Even when the system boots to a terminal, which happens very infrequently, the LPDDR4 RAM chip at Channel 1 can have conflicting discovery information printed during TPL. The following 3 lines were printed during successive reboots using the same SD card with no changes: # Boot 1: BW=32 Col=9 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=384MB # Boot 2: BW=32 Col=10 Bk=4 CS0 Row=16/15 CS=1 Die BW=16 Size=768MB # Boot 3: BW=32 Col=10 Bk=4 CS0 Row=15 CS=1 Die BW=16 Size=512MB The story changes when I build the idbloader.img image with Rockchip's TBL (?) binary blob [0]. With that built in, presumably in place of the upstream TBL, both RAM chips are successfully enumerated and boot succeeds with 100% success rate: tools/mkimage -n rk3399 -T rksd -d \ rk3399_ddr_933MHz_v1.25.bin:spl/u-boot-spl.bin idbloader.img Another thing that is very different between the 2 is the initial frequency the LPDDR4 chips are clocked at. Using the upstream TBL version, the default is 50Mhz, which seems very low. If using the Rockchip supplied binary blob file, this is increased to a respectable 416MHz: # Mainline Channel 0: LPDDR4, 50MHz # Rockchip TBL blob Channel 0: LPDDR4,416MHz One thing I did
Re: Pull request: u-boot-sunxi/master fixes for v2022.07
On Wed, May 25, 2022 at 01:30:21AM +0100, Andre Przywara wrote: > Hi Tom, > > please pull the master branch from u-boot-sunxi, containing fixes and > updates for 2022.07. > The bulk of it is (finally!) some DT sync from the kernel. We refrained > from syncing one incompatible change, as this would spoil booting Linux > kernels before v5.13 with U-Boot's DT (via UEFI, for instance). > I test booted Linux v5.18 and v5.4 with that new DT on some boards, and > the headless peripherals (MMC, USB, Ethernet) seemed to work. > The rest are fixes: > - silencing missing clock warnings due to the new pinctrl driver > - fixing "UART0 on PortF", allowing UART access through the SD card pins > - add an F1C100s clock driver, to enable MMC support (SPI comes later) > - some cleanups for CONS_INDEX_n in Kconfig > > Tested on BananaPi-M1, Pine64-LTS, Pine-H64, X96-Mate (H616) and > OrangePi-Zero. > > Thanks, > Andre > > === > The following changes since commit 6f00b97d7e5760d92566317dde6c4b9224790827: > > Merge https://source.denx.de/u-boot/custodians/u-boot-usb (2022-05-20 > 22:07:56 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master > > for you to fetch changes up to 7495051219b64ec0e8fac8930586dc10666530da: > > serial: Remove obsolete CONS_INDEX_n Kconfig options (2022-05-24 01:46:06 > +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH v3 1/3] usb: common: move urb code to common
Move urb code from musb only use to a more common scope, so other
drivers in the future can use the handling of urb in usb.
Signed-off-by: Rui Miguel Silva
---
drivers/usb/common/Makefile | 2 +
drivers/usb/common/usb_urb.c | 160 ++
drivers/usb/host/r8a66597-hcd.c | 30 +---
drivers/usb/musb-new/musb_core.c | 2 +-
drivers/usb/musb-new/musb_host.c | 2 +-
drivers/usb/musb-new/musb_host.h | 2 +-
drivers/usb/musb-new/musb_uboot.c | 38 +
drivers/usb/musb-new/musb_uboot.h | 2 +-
.../linux/usb/usb_urb_compat.h| 47 -
include/usb_defs.h| 32
10 files changed, 241 insertions(+), 76 deletions(-)
create mode 100644 drivers/usb/common/usb_urb.c
rename drivers/usb/musb-new/usb-compat.h => include/linux/usb/usb_urb_compat.h
(59%)
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 3bedbf213f47..dc05cb0a5077 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -4,5 +4,7 @@
#
obj-$(CONFIG_$(SPL_)DM_USB) += common.o
+obj-$(CONFIG_USB_MUSB_HCD) += usb_urb.o
+obj-$(CONFIG_USB_MUSB_UDC) += usb_urb.o
obj-$(CONFIG_USB_EHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
obj-$(CONFIG_USB_XHCI_FSL) += fsl-dt-fixup.o fsl-errata.o
diff --git a/drivers/usb/common/usb_urb.c b/drivers/usb/common/usb_urb.c
new file mode 100644
index ..be3b6b9f32e8
--- /dev/null
+++ b/drivers/usb/common/usb_urb.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Common code for usb urb handling, based on the musb-new code
+ *
+ * Copyright 2021 Linaro, Rui Miguel Silva
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#if CONFIG_IS_ENABLED(DM_USB)
+struct usb_device *usb_dev_get_parent(struct usb_device *udev)
+{
+ struct udevice *parent = udev->dev->parent;
+
+ /*
+* When called from usb-uclass.c: usb_scan_device() udev->dev points
+* to the parent udevice, not the actual udevice belonging to the
+* udev as the device is not instantiated yet.
+*
+* If dev is an usb-bus, then we are called from usb_scan_device() for
+* an usb-device plugged directly into the root port, return NULL.
+*/
+ if (device_get_uclass_id(udev->dev) == UCLASS_USB)
+ return NULL;
+
+ /*
+* If these 2 are not the same we are being called from
+* usb_scan_device() and udev itself is the parent.
+*/
+ if (dev_get_parent_priv(udev->dev) != udev)
+ return udev;
+
+ /* We are being called normally, use the parent pointer */
+ if (device_get_uclass_id(parent) == UCLASS_USB_HUB)
+ return dev_get_parent_priv(parent);
+
+ return NULL;
+}
+#else
+struct usb_device *usb_dev_get_parent(struct usb_device *udev)
+{
+ return udev->parent;
+}
+#endif
+
+static void usb_urb_complete(struct urb *urb)
+{
+ urb->dev->status &= ~USB_ST_NOT_PROC;
+ urb->dev->act_len = urb->actual_length;
+
+ if (urb->status == -EINPROGRESS)
+ urb->status = 0;
+}
+
+void usb_urb_fill(struct urb *urb, struct usb_host_endpoint *hep,
+ struct usb_device *dev, int endpoint_type,
+ unsigned long pipe, void *buffer, int len,
+ struct devrequest *setup, int interval)
+{
+ int epnum = usb_pipeendpoint(pipe);
+ int is_in = usb_pipein(pipe);
+ u16 maxpacketsize = is_in ? dev->epmaxpacketin[epnum] :
+ dev->epmaxpacketout[epnum];
+
+ memset(urb, 0, sizeof(struct urb));
+ memset(hep, 0, sizeof(struct usb_host_endpoint));
+ INIT_LIST_HEAD(>urb_list);
+ INIT_LIST_HEAD(>urb_list);
+ urb->ep = hep;
+ urb->complete = usb_urb_complete;
+ urb->status = -EINPROGRESS;
+ urb->dev = dev;
+ urb->pipe = pipe;
+ urb->transfer_buffer = buffer;
+ urb->transfer_dma = (unsigned long)buffer;
+ urb->transfer_buffer_length = len;
+ urb->setup_packet = (unsigned char *)setup;
+
+ urb->ep->desc.wMaxPacketSize = __cpu_to_le16(maxpacketsize);
+ urb->ep->desc.bmAttributes = endpoint_type;
+ urb->ep->desc.bEndpointAddress = ((is_in ? USB_DIR_IN : USB_DIR_OUT) |
+ epnum);
+ urb->ep->desc.bInterval = interval;
+}
+
+int usb_urb_submit(struct usb_hcd *hcd, struct urb *urb)
+{
+ const struct usb_urb_ops *ops = hcd->urb_ops;
+ unsigned long timeout;
+ int ret;
+
+ if (!ops)
+ return -EINVAL;
+
+ ret = ops->urb_enqueue(hcd, urb, 0);
+ if (ret < 0) {
+ printf("Failed to enqueue URB to controller\n");
+ return ret;
+ }
+
+ timeout = get_timer(0) + USB_TIMEOUT_MS(urb->pipe);
+ do {
+ if (ctrlc())
+
[PATCH v3 3/3] corstone1000: enable isp1763 usb controller and mmc
MPS3 board have a ISP1763 usb controller, enable it to be used for mass storage access for example. Enable the usb command also and for the FVP support for mass storage enable the mmc command. Signed-off-by: Rui Miguel Silva --- configs/corstone1000_defconfig | 3 +++ include/configs/corstone1000.h | 6 ++ 2 files changed, 9 insertions(+) diff --git a/configs/corstone1000_defconfig b/configs/corstone1000_defconfig index 4f6082770f89..d6c0dc4c5641 100644 --- a/configs/corstone1000_defconfig +++ b/configs/corstone1000_defconfig @@ -23,6 +23,8 @@ CONFIG_CMD_BOOTZ=y # CONFIG_CMD_XIMG is not set CONFIG_CMD_LOADM=y # CONFIG_CMD_LOADS is not set +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set CONFIG_CMD_CACHE=y @@ -45,4 +47,5 @@ CONFIG_DM_RTC=y CONFIG_RTC_EMULATION=y CONFIG_DM_SERIAL=y CONFIG_USB=y +CONFIG_USB_ISP1760=y CONFIG_ERRNO_STR=y diff --git a/include/configs/corstone1000.h b/include/configs/corstone1000.h index 6bc0fc976018..ff327f59483f 100644 --- a/include/configs/corstone1000.h +++ b/include/configs/corstone1000.h @@ -35,7 +35,13 @@ #define CONFIG_SYS_CBSIZE 512 /* Console I/O Buffer Size */ #define CONFIG_SYS_MAXARGS 64 /* max command args */ +#define BOOT_TARGET_DEVICES(func) \ + func(USB, usb, 0) + +#include + #define CONFIG_EXTRA_ENV_SETTINGS \ + BOOTENV \ "usb_pgood_delay=250\0" \ "boot_bank_flag=0x08002000\0" \ "kernel_addr_bank_0=0x083EE000\0" \ -- 2.36.1
[PATCH v3 0/3] usb: add isp1760 hcd support
Add support for the usb isp1760 host controller family, which
for example is present in MPS3 FPGA board from Arm (isp1763).
First we move some helper functions and defines to a more
common place to be shared by several urb users. (patch 1/3)
Then add the driver itself, is a ported version of the kernel
actual driver, which I am also the maintainer. (patch 2/3)
And last, enable it for the corstone1000 platform that uses
that MPS3 board for its implementation (patch 3/3).
Cheers,
Rui
v2[3] -> v3:
- when you think you have amend commit and fix stay
uncommitted.
s/[HC_FIELD_MAX] = {};/[HC_FIELD_MAX] = {},/
v1[0] -> v2:
- gentle ping
- merge fix from kernel upstream [1]
PS: This should go on top of the corstone1000 platform enable
series [2]
0: https://lore.kernel.org/u-boot/20220512142016.2025129-1-rui.si...@linaro.org/
1:
https://lore.kernel.org/linux-usb/20220516091424.391209-1-linus.wall...@linaro.org/
2:
https://lore.kernel.org/u-boot/20220511095541.1461937-1-rui.si...@linaro.org/T/#t
3: https://lore.kernel.org/u-boot/20220523090119.1212016-1-rui.si...@linaro.org/
Rui Miguel Silva (3):
usb: common: move urb code to common
usb: add isp1760 family driver
corstone1000: enable isp1763 usb controller and mmc
Makefile |1 +
configs/corstone1000_defconfig|3 +
drivers/usb/Kconfig |2 +
drivers/usb/common/Makefile |3 +
drivers/usb/common/usb_urb.c | 160 ++
drivers/usb/host/r8a66597-hcd.c | 30 +-
drivers/usb/isp1760/Kconfig | 12 +
drivers/usb/isp1760/Makefile |6 +
drivers/usb/isp1760/isp1760-core.c| 380 +++
drivers/usb/isp1760/isp1760-core.h| 96 +
drivers/usb/isp1760/isp1760-hcd.c | 2477 +
drivers/usb/isp1760/isp1760-hcd.h | 81 +
drivers/usb/isp1760/isp1760-if.c | 125 +
drivers/usb/isp1760/isp1760-regs.h| 292 ++
drivers/usb/isp1760/isp1760-uboot.c | 75 +
drivers/usb/isp1760/isp1760-uboot.h | 27 +
drivers/usb/musb-new/musb_core.c |2 +-
drivers/usb/musb-new/musb_host.c |2 +-
drivers/usb/musb-new/musb_host.h |2 +-
drivers/usb/musb-new/musb_uboot.c | 38 +-
drivers/usb/musb-new/musb_uboot.h |2 +-
include/configs/corstone1000.h|6 +
.../linux/usb/usb_urb_compat.h| 47 +-
include/usb_defs.h| 32 +
24 files changed, 3825 insertions(+), 76 deletions(-)
create mode 100644 drivers/usb/common/usb_urb.c
create mode 100644 drivers/usb/isp1760/Kconfig
create mode 100644 drivers/usb/isp1760/Makefile
create mode 100644 drivers/usb/isp1760/isp1760-core.c
create mode 100644 drivers/usb/isp1760/isp1760-core.h
create mode 100644 drivers/usb/isp1760/isp1760-hcd.c
create mode 100644 drivers/usb/isp1760/isp1760-hcd.h
create mode 100644 drivers/usb/isp1760/isp1760-if.c
create mode 100644 drivers/usb/isp1760/isp1760-regs.h
create mode 100644 drivers/usb/isp1760/isp1760-uboot.c
create mode 100644 drivers/usb/isp1760/isp1760-uboot.h
rename drivers/usb/musb-new/usb-compat.h => include/linux/usb/usb_urb_compat.h
(59%)
--
2.36.1
Re: [PATCH] net: Add missing PCI dependency for CONFIG_E1000
On Tue, May 24, 2022 at 01:32:08PM -0400, Sean Anderson wrote: > > > On 5/24/22 1:16 PM, Pali Rohár wrote: > > On Tuesday 24 May 2022 13:12:02 Sean Anderson wrote: > >> Hi Pali, > >> > >> On 5/23/22 4:41 AM, Pali Rohár wrote: > >> > Signed-off-by: Pali Rohár > >> > --- > >> > drivers/net/Kconfig | 1 + > >> > 1 file changed, 1 insertion(+) > >> > > >> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > >> > index 7fe0e00649cf..84d859c21eb8 100644 > >> > --- a/drivers/net/Kconfig > >> > +++ b/drivers/net/Kconfig > >> > @@ -231,6 +231,7 @@ config DWC_ETH_QOS_TEGRA186 > >> > > >> > config E1000 > >> > bool "Intel PRO/1000 Gigabit Ethernet support" > >> > +depends on PCI > >> > help > >> >This driver supports Intel(R) PRO/1000 gigabit ethernet > >> > family of > >> >adapters. For more information on how to identify your > >> > adapter, go > >> > > >> > >> This appears to be a duplicate of [1]. > >> > >> [1] > >> https://lore.kernel.org/u-boot/20220426183533.3224252-1-sean.ander...@seco.com/ > >> > >> --Sean > > > > Interesting... this is my second duplicate patch this week. > > > > Any idea why above patch was not accepted yet? > > Looks like Ramon has not done a pull request since mid April [1]. Though > based on the past pattern, it seems like he just makes one PR each release. > Perhaps Tom can pick this up? > > [1] > https://lore.kernel.org/u-boot/cagi-ruk9pev+j8ocjxtejxnky-lm+3sgysckuyjerhldzxa...@mail.gmail.com/ Sure. It didn't stand out as a critical thing so I was assuming at the time it would come in eventually. I've put it in my bundle of stuff to not forget. -- Tom signature.asc Description: PGP signature
Re: [PATCH] imx8m: fixup thermal trips
On Wed, May 25, 2022 at 7:24 AM Andrejs Cainikovs
wrote:
>
> Adam,
>
> So you want me to rebase this patch to upstream, update according to
> your review, and send this one instead of yours?
Go ahead. Yours has all the requested improvements already applied.
I'm still playing catch up from being away for 2 weeks.
thanks
adam
>
> Best regards,
> Andrejs Cainikovs.
>
> On Wed, 2022-05-25 at 07:21 -0500, Adam Ford wrote:
> > On Wed, May 25, 2022 at 7:19 AM Andrejs Cainikovs
> > wrote:
> > >
> > > Hi Adam,
> > >
> > > On Wed, 2022-05-25 at 06:41 -0500, Adam Ford wrote:
> > > > On Thu, May 12, 2022 at 5:13 AM Andrejs Cainikovs
> > > > wrote:
> > > > >
> > > > > Fixup thermal trips in Linux device tree according to SoC
> > > > > thermal
> > > > > grade.
> > > > >
> > > > > Signed-off-by: Andrejs Cainikovs
> > > > >
> > > > > ---
> > > > > arch/arm/mach-imx/imx8m/soc.c | 50
> > > > > +++
> > > > > 1 file changed, 50 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-
> > > > > imx/imx8m/soc.c
> > > > > index e93ecd2846..b451ece91f 100644
> > > > > --- a/arch/arm/mach-imx/imx8m/soc.c
> > > > > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > > > > @@ -1001,6 +1001,49 @@ static int disable_cpu_nodes(void *blob,
> > > > > u32
> > > > > disabled_cores)
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +int fixup_thermal_trips(void *blob, const char *name)
> > > >
> > > > Is there any reason this function cannot be static?
> > >
> > > No, this function should be static indeed.
> >
> > With that change:
> >
> > Tested-by: Adam Ford
> >
> > >
> > > >
> > > > > +{
> > > > > + int minc, maxc;
> > > > > + int node, trip;
> > > > > +
> > > > > + node = fdt_path_offset(blob, "/thermal-zones");
> > > > > + if (node < 0)
> > > > > + return node;
> > > > > +
> > > > > + node = fdt_subnode_offset(blob, node, name);
> > > > > + if (node < 0)
> > > > > + return node;
> > > > > +
> > > > > + node = fdt_subnode_offset(blob, node, "trips");
> > > > > + if (node < 0)
> > > > > + return node;
> > > > > +
> > > > > + get_cpu_temp_grade(, );
> > > > > +
> > > > > + fdt_for_each_subnode(trip, blob, node) {
> > > > > + const char *type;
> > > > > + int temp, ret;
> > > > > +
> > > > > + type = fdt_getprop(blob, trip, "type", NULL);
> > > > > + if (!type)
> > > > > + continue;
> > > > > +
> > > > > + temp = 0;
> > > > > + if (!strcmp(type, "critical")) {
> > > > > + temp = 1000 * maxc;
> > > > > + } else if (!strcmp(type, "passive")) {
> > > > > + temp = 1000 * (maxc - 10);
> > > > > + }
> > > > > + if (temp) {
> > > > > + ret = fdt_setprop_u32(blob, trip,
> > > > > "temperature", temp);
> > > > > + if (ret)
> > > > > + return ret;
> > > > > + }
> > > > > + }
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > int ft_system_setup(void *blob, bd_t *bd)
> > > > > {
> > > > > #ifdef CONFIG_IMX8MQ
> > > > > @@ -1128,6 +1171,13 @@ usb_modify_speed:
> > > > > disable_cpu_nodes(blob, 2);
> > > > > #endif
> > > > >
> > > > > + if (fixup_thermal_trips(blob, "cpu-thermal"))
> > > > > + printf("Failed to update cpu-thermal trip(s)");
> > > > > +#ifdef CONFIG_IMX8MP
> > > > > + if (fixup_thermal_trips(blob, "soc-thermal"))
> > > > > + printf("Failed to update soc-thermal trip(s)");
> > > > > +#endif
> > > > > +
> > > > > return ft_add_optee_node(blob, bd);
> > > > > }
> > > > > #endif
> > > > > --
> > > > > 2.34.1
> > > > >
> > > >
> > >
> >
>
Re: [PATCH] imx8m: fixup thermal trips
On Wed, May 25, 2022 at 7:19 AM Andrejs Cainikovs
wrote:
>
> Hi Adam,
>
> On Wed, 2022-05-25 at 06:41 -0500, Adam Ford wrote:
> > On Thu, May 12, 2022 at 5:13 AM Andrejs Cainikovs
> > wrote:
> > >
> > > Fixup thermal trips in Linux device tree according to SoC thermal
> > > grade.
> > >
> > > Signed-off-by: Andrejs Cainikovs
> > > ---
> > > arch/arm/mach-imx/imx8m/soc.c | 50
> > > +++
> > > 1 file changed, 50 insertions(+)
> > >
> > > diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-
> > > imx/imx8m/soc.c
> > > index e93ecd2846..b451ece91f 100644
> > > --- a/arch/arm/mach-imx/imx8m/soc.c
> > > +++ b/arch/arm/mach-imx/imx8m/soc.c
> > > @@ -1001,6 +1001,49 @@ static int disable_cpu_nodes(void *blob, u32
> > > disabled_cores)
> > > return 0;
> > > }
> > >
> > > +int fixup_thermal_trips(void *blob, const char *name)
> >
> > Is there any reason this function cannot be static?
>
> No, this function should be static indeed.
With that change:
Tested-by: Adam Ford
>
> >
> > > +{
> > > + int minc, maxc;
> > > + int node, trip;
> > > +
> > > + node = fdt_path_offset(blob, "/thermal-zones");
> > > + if (node < 0)
> > > + return node;
> > > +
> > > + node = fdt_subnode_offset(blob, node, name);
> > > + if (node < 0)
> > > + return node;
> > > +
> > > + node = fdt_subnode_offset(blob, node, "trips");
> > > + if (node < 0)
> > > + return node;
> > > +
> > > + get_cpu_temp_grade(, );
> > > +
> > > + fdt_for_each_subnode(trip, blob, node) {
> > > + const char *type;
> > > + int temp, ret;
> > > +
> > > + type = fdt_getprop(blob, trip, "type", NULL);
> > > + if (!type)
> > > + continue;
> > > +
> > > + temp = 0;
> > > + if (!strcmp(type, "critical")) {
> > > + temp = 1000 * maxc;
> > > + } else if (!strcmp(type, "passive")) {
> > > + temp = 1000 * (maxc - 10);
> > > + }
> > > + if (temp) {
> > > + ret = fdt_setprop_u32(blob, trip,
> > > "temperature", temp);
> > > + if (ret)
> > > + return ret;
> > > + }
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > int ft_system_setup(void *blob, bd_t *bd)
> > > {
> > > #ifdef CONFIG_IMX8MQ
> > > @@ -1128,6 +1171,13 @@ usb_modify_speed:
> > > disable_cpu_nodes(blob, 2);
> > > #endif
> > >
> > > + if (fixup_thermal_trips(blob, "cpu-thermal"))
> > > + printf("Failed to update cpu-thermal trip(s)");
> > > +#ifdef CONFIG_IMX8MP
> > > + if (fixup_thermal_trips(blob, "soc-thermal"))
> > > + printf("Failed to update soc-thermal trip(s)");
> > > +#endif
> > > +
> > > return ft_add_optee_node(blob, bd);
> > > }
> > > #endif
> > > --
> > > 2.34.1
> > >
> >
>
[GIT PULL] xilinx patches for v2022.07-rc4
Hi Tom, please pull these patches to your tree. All of them are fixes I have collected for v2022.07 version. Gitlab CI doesn't show any issue too. Thanks, Michal The following changes since commit c387e62614713d0cc9e3ed022b86c9f320b02853: Merge branch '2022-05-11-Kconfig-cleanups-etc' (2022-05-11 13:27:44 -0400) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2022.07-rc4 for you to fetch changes up to 594f692f491f0def6c4b6543e158a7f367b35dcc: xilinx: zynqmp: Wire tee for Multi DTB use cases (2022-05-24 08:44:24 +0200) Xilinx changes for v2022.07-rc4 zynqmp: - Fix DP PLL configuration for zcu102/zcu106 and SOM - Fix split mode for starting R5s - DT fixes - Remove firmware node for mini configurations - Wire TEE for multi DTB fit image xilinx: - Handle board_get_usable_ram_top(0) properly phy: - Extend psgtr timeout mmc: - Fix mini configuration which misses zynqmp_pm_is_function_supported() Amit Kumar Mahapatra (1): arm64: zynqmp: Set qspi tx-buswidth to 4 Ashok Reddy Soma (1): phy: zynqmp: Increase timeout value to 10ms Jorge Ramirez-Ortiz (1): soc: xilinx: versal: fix out of bounds array access Michal Simek (11): soc: xilinx: zynqmp: fix out of bounds array access xilinx: Handle board_get_usable_ram_top(0) properly xilinx: zynqmp: Do not guard SPL_FS_LOAD_PAYLOAD_NAME by SDHCI driver arm64: zynqmp: Add gpio labels for modepin arm64: zynqmp: Fix opp-table-cpu arm64: zynqmp: Add power domain description for PL arm64: zynqmp: Add dmas, gpu, rtc, watchdogs and opp nodes for SOM arm64: zynqmp: Add PHY description for SGMII on vck190 SC arm64: zynqmp: Add linux,code for fwuen button arm64: zynqmp: Add DT description for si5328 for zcu102/zcu106 xilinx: zynqmp: Wire tee for Multi DTB use cases Neal Frager (5): arm64: zynqmp: zynqmp-zcu106-rev1.0: Fix DP PLL configuration arm64: zynqmp: zynqmp-zcu106-revA: Fix DP PLL configuration arm64: zynqmp: zynqmp-zcu102-revA: Fix DP PLL configuration arm64: zynqmp: Fix split mode reset functionality arm64: zynqmp: zynqmp-sm-k26-revA: Fix DP PLL configuration Piyush Mehta (1): arm64: zynqmp: Add mode-pin GPIO controller DT node T Karthik Reddy (3): Revert "arm64: xilinx: Set CONFIG_ZYNQMP_FIRMWARE config for mini emmc" mmc: zynq_sdhci: Add weak function prototype Revert "arm64: zynqmp: Add zynqmp firmware specific DT nodes" Vishal Patel (1): arm64: zynqmp: Add pwm-fan node and fix ttc0 pwm-cells property arch/arm/dts/zynqmp-e-a2197-00-revA.dts | 15 +++ arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 2 +- arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 2 +- arch/arm/dts/zynqmp-mini-emmc0.dts | 40 --- arch/arm/dts/zynqmp-mini-emmc1.dts | 40 --- arch/arm/dts/zynqmp-mini-qspi.dts | 2 +- arch/arm/dts/zynqmp-sm-k26-revA.dts | 115 +++- arch/arm/dts/zynqmp-topic-miamimp-xilinx-xdp-v1r1.dts | 2 +- arch/arm/dts/zynqmp-zc1232-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1254-revA.dts | 2 +- arch/arm/dts/zynqmp-zc1751-xm015-dc1.dts| 2 +- arch/arm/dts/zynqmp-zc1751-xm018-dc4.dts| 2 +- arch/arm/dts/zynqmp-zcu102-revA.dts | 23 +++- arch/arm/dts/zynqmp-zcu104-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu104-revC.dts | 2 +- arch/arm/dts/zynqmp-zcu106-revA.dts | 23 +++- arch/arm/dts/zynqmp-zcu111-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu1275-revA.dts| 2 +- arch/arm/dts/zynqmp-zcu208-revA.dts | 2 +- arch/arm/dts/zynqmp-zcu216-revA.dts | 2 +- arch/arm/dts/zynqmp.dtsi| 11 +- arch/arm/mach-zynqmp/mkimage_fit_atf.sh | 10 ++ arch/arm/mach-zynqmp/mp.c | 31 +- board/xilinx/versal/board.c | 3 + board/xilinx/zynqmp/zynqmp-sm-k26-revA/psu_init_gpl.c | 3 + board/xilinx/zynqmp/zynqmp-zcu102-revA/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp-zcu106-rev1.0/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp-zcu106-revA/psu_init_gpl.c | 4 +- board/xilinx/zynqmp/zynqmp.c| 3 + configs/xilinx_versal_mini_emmc0_defconfig | 1 - configs/xilinx_versal_mini_emmc1_defconfig | 1 - configs/xilinx_zynqmp_mini_emmc0_defconfig | 1 -
Re: [PATCH] imx8m: fixup thermal trips
On Thu, May 12, 2022 at 5:13 AM Andrejs Cainikovs
wrote:
>
> Fixup thermal trips in Linux device tree according to SoC thermal
> grade.
>
> Signed-off-by: Andrejs Cainikovs
> ---
> arch/arm/mach-imx/imx8m/soc.c | 50 +++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
> index e93ecd2846..b451ece91f 100644
> --- a/arch/arm/mach-imx/imx8m/soc.c
> +++ b/arch/arm/mach-imx/imx8m/soc.c
> @@ -1001,6 +1001,49 @@ static int disable_cpu_nodes(void *blob, u32
> disabled_cores)
> return 0;
> }
>
> +int fixup_thermal_trips(void *blob, const char *name)
Is there any reason this function cannot be static?
> +{
> + int minc, maxc;
> + int node, trip;
> +
> + node = fdt_path_offset(blob, "/thermal-zones");
> + if (node < 0)
> + return node;
> +
> + node = fdt_subnode_offset(blob, node, name);
> + if (node < 0)
> + return node;
> +
> + node = fdt_subnode_offset(blob, node, "trips");
> + if (node < 0)
> + return node;
> +
> + get_cpu_temp_grade(, );
> +
> + fdt_for_each_subnode(trip, blob, node) {
> + const char *type;
> + int temp, ret;
> +
> + type = fdt_getprop(blob, trip, "type", NULL);
> + if (!type)
> + continue;
> +
> + temp = 0;
> + if (!strcmp(type, "critical")) {
> + temp = 1000 * maxc;
> + } else if (!strcmp(type, "passive")) {
> + temp = 1000 * (maxc - 10);
> + }
> + if (temp) {
> + ret = fdt_setprop_u32(blob, trip, "temperature",
> temp);
> + if (ret)
> + return ret;
> + }
> + }
> +
> + return 0;
> +}
> +
> int ft_system_setup(void *blob, bd_t *bd)
> {
> #ifdef CONFIG_IMX8MQ
> @@ -1128,6 +1171,13 @@ usb_modify_speed:
> disable_cpu_nodes(blob, 2);
> #endif
>
> + if (fixup_thermal_trips(blob, "cpu-thermal"))
> + printf("Failed to update cpu-thermal trip(s)");
> +#ifdef CONFIG_IMX8MP
> + if (fixup_thermal_trips(blob, "soc-thermal"))
> + printf("Failed to update soc-thermal trip(s)");
> +#endif
> +
> return ft_add_optee_node(blob, bd);
> }
> #endif
> --
> 2.34.1
>
Re: [PATCH v2] arm: socfpga: Add the terasic de10-standard board
On 5/23/22 03:54, Humberto Naves wrote: Use the de10-nano files as templates for the de10-standard board. The files in qts directory are generated by quartus from the GHRD design. Applied, thanks.
Re: [PATCH 1/2] doc/efi: add firmware management protocol to the documentation
On 5/25/22 11:20, Vincent Stehlé wrote: The firmware management protocol can be used to manage device firmware. U-Boot can be configured to provide an implementation. Document the related functions in the API section. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt When merging this patch should succeed 2/2 to avoid build failures. Reviewed-by: Heinrich Schuchardt --- doc/api/efi.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/api/efi.rst b/doc/api/efi.rst index cb2a1c897e6..2b96783828b 100644 --- a/doc/api/efi.rst +++ b/doc/api/efi.rst @@ -166,6 +166,12 @@ Unicode Collation protocol .. kernel-doc:: lib/efi_loader/efi_unicode_collation.c :internal: +Firmware management protocol + + +.. kernel-doc:: lib/efi_loader/efi_firmware.c + :internal: + Unit testing
Re: [PATCH 2/2] efi: fix documentation warnings
On 5/25/22 11:20, Vincent Stehlé wrote:
This fixes the following warnings:
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:369: warning: bad line: firmware image
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version' not described in 'efi_firmware_raw_get_image_info'
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_raw_get_image_info'
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
We don't want to see any build errors when bisecting. Therefore this
match should be merged before patch 1/2.
Reviewed-by: Heinrich Schuchardt
---
lib/efi_loader/efi_firmware.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 27953fe7699..fe4e084106d 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -197,8 +197,8 @@ static efi_status_t efi_fill_image_desc_array(
* @descriptor_version: Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
@@ -296,15 +296,15 @@ const struct efi_firmware_management_protocol efi_fmp_fit
= {
/**
* efi_firmware_raw_get_image_info - return information about the current
-firmware image
+ * firmware image
* @this: Protocol instance
* @image_info_size: Size of @image_info
* @image_info: Image information
* @descriptor_version: Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
[PATCH 1/1] configs: imx8mm-cl-iot-gate: enable extension command
For imx8mm-cl-iot-gate we can use extension command to scan extension boards attached on the mainboard. We enable the extension command by default for users to detect the extension boards. Signed-off-by: Ying-Chun Liu (PaulLiu) Cc: Stefano Babic Cc: Fabio Estevam Cc: NXP i.MX U-Boot Team --- configs/imx8mm-cl-iot-gate-optee_defconfig | 2 ++ configs/imx8mm-cl-iot-gate_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/imx8mm-cl-iot-gate-optee_defconfig b/configs/imx8mm-cl-iot-gate-optee_defconfig index 8b3d1b3ef1..4a07d9afd7 100644 --- a/configs/imx8mm-cl-iot-gate-optee_defconfig +++ b/configs/imx8mm-cl-iot-gate-optee_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_POWER=y CONFIG_SPL_WATCHDOG=y CONFIG_SYS_PROMPT="u-boot=> " CONFIG_CMD_BOOTEFI_SELFTEST=y +CONFIG_CMD_EXTENSION=y CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_EEPROM=y CONFIG_CMD_SHA1SUM=y @@ -79,6 +80,7 @@ CONFIG_FASTBOOT_BUF_SIZE=0x500 CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=2 CONFIG_MXC_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_DM_KEYBOARD=y CONFIG_MISC=y diff --git a/configs/imx8mm-cl-iot-gate_defconfig b/configs/imx8mm-cl-iot-gate_defconfig index b418e86248..ccdacf56d9 100644 --- a/configs/imx8mm-cl-iot-gate_defconfig +++ b/configs/imx8mm-cl-iot-gate_defconfig @@ -33,6 +33,7 @@ CONFIG_SPL_POWER=y CONFIG_SPL_WATCHDOG=y CONFIG_SYS_PROMPT="u-boot=> " CONFIG_CMD_BOOTEFI_SELFTEST=y +CONFIG_CMD_EXTENSION=y CONFIG_CMD_NVEDIT_EFI=y CONFIG_CMD_EEPROM=y CONFIG_CMD_SHA1SUM=y @@ -82,6 +83,7 @@ CONFIG_FASTBOOT_BUF_SIZE=0x500 CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=2 CONFIG_MXC_GPIO=y +CONFIG_DM_PCA953X=y CONFIG_DM_I2C=y CONFIG_DM_KEYBOARD=y CONFIG_MISC=y -- 2.35.1
[PATCH 0/1] configs: imx8mm-cl-iot-gate: enable extension command
For imx8mm-cl-iot-gate we can use extension command to scan extension boards attached on the mainboard. We enable the extension command by default for users to detect the extension boards. Ying-Chun Liu (PaulLiu) (1): configs: imx8mm-cl-iot-gate: enable extension command configs/imx8mm-cl-iot-gate-optee_defconfig | 2 ++ configs/imx8mm-cl-iot-gate_defconfig | 2 ++ 2 files changed, 4 insertions(+) -- 2.35.1
[PATCH 2/2] efi: fix documentation warnings
This fixes the following warnings:
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_fit_get_image_info'
./lib/efi_loader/efi_firmware.c:369: warning: bad line: firmware image
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version' not described in 'efi_firmware_raw_get_image_info'
./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member
'package_version_name' not described in 'efi_firmware_raw_get_image_info'
Signed-off-by: Vincent Stehlé
Cc: Heinrich Schuchardt
---
lib/efi_loader/efi_firmware.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/efi_loader/efi_firmware.c b/lib/efi_loader/efi_firmware.c
index 27953fe7699..fe4e084106d 100644
--- a/lib/efi_loader/efi_firmware.c
+++ b/lib/efi_loader/efi_firmware.c
@@ -197,8 +197,8 @@ static efi_status_t efi_fill_image_desc_array(
* @descriptor_version:Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
@@ -296,15 +296,15 @@ const struct efi_firmware_management_protocol efi_fmp_fit
= {
/**
* efi_firmware_raw_get_image_info - return information about the current
-firmware image
+ * firmware image
* @this: Protocol instance
* @image_info_size: Size of @image_info
* @image_info:Image information
* @descriptor_version:Pointer to version number
* @descriptor_count: Pointer to number of descriptors
* @descriptor_size: Pointer to descriptor size
- * package_version:Package version
- * package_version_name: Package version's name
+ * @package_version: Package version
+ * @package_version_name: Package version's name
*
* Return information bout the current firmware image in @image_info.
* @image_info will consist of a number of descriptors.
--
2.35.1
[PATCH 1/2] doc/efi: add firmware management protocol to the documentation
The firmware management protocol can be used to manage device firmware. U-Boot can be configured to provide an implementation. Document the related functions in the API section. Signed-off-by: Vincent Stehlé Cc: Heinrich Schuchardt --- doc/api/efi.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/doc/api/efi.rst b/doc/api/efi.rst index cb2a1c897e6..2b96783828b 100644 --- a/doc/api/efi.rst +++ b/doc/api/efi.rst @@ -166,6 +166,12 @@ Unicode Collation protocol .. kernel-doc:: lib/efi_loader/efi_unicode_collation.c :internal: +Firmware management protocol + + +.. kernel-doc:: lib/efi_loader/efi_firmware.c + :internal: + Unit testing -- 2.35.1
Re: Raspberry Pi won’t boot from compressed subvolume (BTRFS)
On 22/05/2022 17:36, Nathan Henrie wrote: Hello u-boot team, I’ve been experimenting for about a year with a NixOS-based Raspberry Pi image, with the end goal of a zstd-compressed image that uses BTRFS subvolumes, having the root filesystem at @ and boot at @boot (with several other subvolumes). The NixOS Raspberry Pi images use u-boot by default. I’ve started a few discussions in the NixOS community as I learn and iterate: https://discourse.nixos.org/t/raspberry-pi-nixos-on-btrfs-root/14081 and I’ve made my code available at: https://github.com/n8henrie/nixos-btrfs-pi . I’m sure it’s obvious (or will be soon) that I’m a hobbyist, a novice with NixOS, and that I understand very little about u-boot and bootloaders in general, so I hope you can be patient as I humbly ask for someone to point me in the right direction. For reference, the official NixOS code for generating u-boot images is here: https://github.com/NixOS/nixpkgs/blob/3d4e586313d292c9e764a8e88a1fdccb16ffb2d3/pkgs/misc/uboot/default.nix I’ve made a lot of progress, including an image that reliably boots from @boot to the @ root subvolume with the u-boot configuration: CONFIG_CMD_BTRFS=y CONFIG_ZSTD=y CONFIG_BOOTCOMMAND="setenv boot_prefixes / /boot/ /@/ /@boot/; run distro_bootcmd;" with kernel params: "root=LABEL=NIXOS_SD" "rootfstype=btrfs" "rootflags=subvol=@" Unfortunately, after the initial boot and going through the initial OS installation steps, if I have compression enabled, it reboots into a boot loop with the following error messages: Scanning mmc 0:2... Found /@boot/extlinux/extlinux.conf Retrieving file: /@boot/extlinux/extlinux.conf 2938 bytes read in 27 ms (105.5 KiB/s) 1 NixOS Default 2 NixOS Configuration 4 (2022-02-24 21:34 22.05pre356135.7f9b6c2babf) 3 NixOS Configuration 3 (2022-02-25 03:59 22.05pre356435.7/9b6eZbabf) 4: NixOS Configuration 2 (2022-02-24 21:34 22.05pre356435.7/9b6c2babr) 5: NixOS Enter choice: 1: NixOS - Default Retrieving file: /@boot/extlinux/..nixos/zhbharzhzqga617uc37uk0g6q1bx891u-initrd-linux-5.10.101-initrd 20588420 bytes read in 1910 ms (10.3 MiB/s) Retrieving file: /@boot/extlinux/..nixos/6c1m6j0k1gmjrmikOyyizariiry?Zlqr-linux-5.10.101-Image 50629120 bytes read in 6863 ms (7 MiB/s) append: init-mix/store/pikl8ju4077iaix36n8mifzu6l6rcajz-nixos-system-nixpi-22.05p re356435-7/9b6eZbabf/init console=tty1 console=ttyAMAO console=ttyS0, 1115200 root= LABEL=-NIXOS_SD rootfstype=btrfs rootflags=subvol=@ loglevel=4 Retrieving file: /@boot/extlinux/../nixos/6c16j0k1gmjrmikOyyizari1ry72lqr-linux-5.10.101-dtbs/broadcon/bcn2837-rpi-3-b.dtb Just a random guess, but bcn2837-rpi-3-b.dtb does look right, the DTB should be called bcm2837-rpi-3-b.dtb 14310 bytes read in 66 ms (210.9 KiB/s) Moving Image from 0x8 to 0x20, end=32f ## Flattened Device Tree blob at 0370 Booting using the fdt blob at 0x370 Using Device Tree in place at 0370 end 037067e5 fdt_find_or_add_subnode: memory: FDT_ERR_BADSTRUCTURE ERROR: arch-specific fdt fixup failed - must RESET the board to recover. Then you try to fixup that address which has no valid DTB and fails. Anyway to me that sounds like a nixOS problem rather then a U-Boot problem. I'm not even sure which version of U-Boot you are using and if it has any patches on top of the upstream version. Regards, Matthias FDT creation failed! resetting ... This happens even though I have CONFIG_ZSTD=y. If I do *not* enable compression (in my BTRFS mount options), it reboots normally and everything works! I may have made some OCR / C errors above; I’ve posted some pictures of the error messages (and similar discussion to this email, with no responses) here: https://discourse.nixos.org/t/btrfs-pi-wont-boot-from-compressed-subvolume/18462/2 I’m not currently using BTRFS RAID, just a single device. One of my other (x86_64) machines uses a similar setup with @, @boot, and zstd-compression with grub and works well, so I’m hoping this is also possible with u-boot. Seeing that the errors mention the FDT and fixup, I tried CONFIG_ARCH_FIXUP_FDT_MEMORY with both =y and =n without interesting changes to the error messages. What I’m assuming, based on the above, is that re-writing the @boot subvolume with compression is moving the location of the device tree files and that u-boot is no longer able to find the necessary files (some of which I think may also be in the nix store in the @nix subvolume). Does that sound like a reasonable guess as to what is going on? If so, are there config options or settings that I might be able to use to help u-boot find the necessary files after things are re-written with compression? Many thanks in advance for your time and attention, and thanks for your hard work on u-boot!
Re: [PATCH 1/2] toradex: tdx-cfg-block: add new 8gb apalis-imx8
Hi Marcel, Philippe,
On 25.05.22 10:12, Marcel Ziswiler wrote:
Hi Stefano
On Mon, 2022-05-09 at 18:58 +0200, Philippe Schenker wrote:
From: Philippe Schenker
0067: Apalis iMX8 QuadMax 8GB Wi-Fi / BT IT
This module is identical to its 4GB counterpart
0037: Apalis iMX8 QuadMax 4GB Wi-Fi / BT IT
except for the RAM size.
Signed-off-by: Philippe Schenker
Reviewed-by: Francesco Dolcini
Those two patches are currently still missing. Could you please apply them as
well? Thanks!
Yes, I solved the long backlog, quite "recent" patches were out of my sight.
Marked them for the release, I plan another PR before release.
Regards,
Stefano
Cheers
Marcel
---
board/toradex/common/tdx-cfg-block.c | 18 --
board/toradex/common/tdx-cfg-block.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/board/toradex/common/tdx-cfg-block.c
b/board/toradex/common/tdx-cfg-block.c
index 9c87289ae9..6c8cf4592d 100644
--- a/board/toradex/common/tdx-cfg-block.c
+++ b/board/toradex/common/tdx-cfg-block.c
@@ -144,6 +144,7 @@ const char * const toradex_modules[] = {
[64] = "Verdin iMX8M Plus Quad 2GB Wi-Fi / BT IT",
[65] = "Verdin iMX8M Plus QuadLite 1GB IT",
[66] = "Verdin iMX8M Plus Quad 8GB Wi-Fi / BT",
+ [67] = "Apalis iMX8 QuadMax 8GB Wi-Fi / BT IT",
};
const char * const toradex_carrier_boards[] = {
@@ -359,6 +360,7 @@ static int get_cfgblock_interactive(void)
char *soc;
char it = 'n';
char wb = 'n';
+ char mem8g = 'n';
int len = 0;
/* Unknown module by default */
@@ -377,6 +379,14 @@ static int get_cfgblock_interactive(void)
sprintf(message, "Does the module have Wi-Fi / Bluetooth? [y/N] ");
len = cli_readline(message);
wb = console_buffer[0];
+
+#if defined(CONFIG_TARGET_APALIS_IMX8)
+ if ((wb == 'y' || wb == 'Y') && (it == 'y' || it == 'Y')) {
+ sprintf(message, "Does your module have 8GB of RAM? [y/N] ");
+ len = cli_readline(message);
+ mem8g = console_buffer[0];
+ }
+#endif
#endif
soc = env_get("soc");
@@ -430,8 +440,12 @@ static int get_cfgblock_interactive(void)
tdx_hw_tag.prodid = COLIBRI_IMX7S;
else if (is_cpu_type(MXC_CPU_IMX8QM)) {
if (it == 'y' || it == 'Y') {
- if (wb == 'y' || wb == 'Y')
- tdx_hw_tag.prodid = APALIS_IMX8QM_WIFI_BT_IT;
+ if (wb == 'y' || wb == 'Y') {
+ if (mem8g == 'y' || mem8g == 'Y')
+ tdx_hw_tag.prodid =
APALIS_IMX8QM_8GB_WIFI_BT_IT;
+ else
+ tdx_hw_tag.prodid =
APALIS_IMX8QM_WIFI_BT_IT;
+ }
else
tdx_hw_tag.prodid = APALIS_IMX8QM_IT;
} else {
diff --git a/board/toradex/common/tdx-cfg-block.h
b/board/toradex/common/tdx-cfg-block.h
index ddcf699748..43e662e41d 100644
--- a/board/toradex/common/tdx-cfg-block.h
+++ b/board/toradex/common/tdx-cfg-block.h
@@ -87,6 +87,7 @@ enum {
VERDIN_IMX8MPQ_2GB_WIFI_BT_IT,
VERDIN_IMX8MPQL_IT, /* 65 */
VERDIN_IMX8MPQ_8GB_WIFI_BT,
+ APALIS_IMX8QM_8GB_WIFI_BT_IT,
};
enum {
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
Re: [u-boot PATCH 3/3] k3-am642-evm-u-boot: Use binman to generate u-boot.img and tispl.bin
Hi Andrew,
On 25/05/2022 01:03, Andrew Davis wrote:
> On 5/9/22 2:29 AM, Roger Quadros wrote:
>> Introduce k3-am642-evm-binman.dtsi to provide binman configuration.
>>
>> R5 build is still not converted to use binman so restrict binman.dtsi
>> to A53 builds only.
>>
>> This patch also take care of building Secure (HS) images using
>> binman instead of tools/k3_fit_atf.sh if CONFIG_BINMAN is set.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> arch/arm/dts/k3-am642-evm-binman.dtsi | 230 ++
>> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 3 +
>> arch/arm/mach-k3/Kconfig | 1 +
>> arch/arm/mach-k3/config.mk | 7 +
>> 4 files changed, 241 insertions(+)
>> create mode 100644 arch/arm/dts/k3-am642-evm-binman.dtsi
>>
>> diff --git a/arch/arm/dts/k3-am642-evm-binman.dtsi
>> b/arch/arm/dts/k3-am642-evm-binman.dtsi
>> new file mode 100644
>> index 00..9e85ef41b0
>> --- /dev/null
>> +++ b/arch/arm/dts/k3-am642-evm-binman.dtsi
>> @@ -0,0 +1,230 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
>> + */
>> +
>> +/ {
>> + binman: binman {
>> + multiple-images;
>> + };
>> +};
>> +
>> +#ifdef CONFIG_TARGET_AM642_A53_EVM
>> +
>> +#ifdef CONFIG_TI_SECURE_DEVICE
>> +#define TISPL "tispl.bin_HS"
>> +#define UBOOT_IMG "u-boot.img_HS"
>> +#else
>> +#define TISPL "tispl.bin"
>> +#define UBOOT_IMG "u-boot.img"
>> +#endif
>> +
>> +#define SPL_NODTB "spl/u-boot-spl-nodtb.bin"
>> +#define SPL_AM642_EVM_DTB "spl/dts/k3-am642-evm.dtb"
>> +#define SPL_AM642_SK_DTB "spl/dts/k3-am642-sk.dtb"
>> +
>> +#define UBOOT_NODTB "u-boot-nodtb.bin"
>> +#define AM642_EVM_DTB "arch/arm/dts/k3-am642-evm.dtb"
>> +#define AM642_SK_DTB "arch/arm/dts/k3-am642-sk.dtb"
>> +
>> + {
>> + ti-spl {
>> + filename = TISPL;
>> + pad-byte = <0xff>;
>> +
>> + fit {
>> + description = "Configuration to load ATF and SPL";
>> + #address-cells = <1>;
>> +
>> + images {
>> +
>> + atf {
>> + description = "ARM Trusted Firmware";
>> + type = "firmware";
>> + arch = "arm64";
>> + compression = "none";
>> + os = "arm-trusted-firmware";
>> + load = ;
>> + entry = ;
>> + atf-bl31 {
>> + filename = "bl31.bin";
>> + };
>
>
> On HS, bl31.bin and the below TEE and DM images must also be signed
> before being packaged into tispl.bin.
> Can we add signing here?
I'm wondering how this is working as is on HS boards.
Another thing to note is that the atf and tee entries take into consideration
the below environment variables
-a atf-bl31-path=${BL31} \
-a tee-os-path=${TEE} \
How do we continue to support that while adding the signing bits?
cheers,
-roger
>
> Andrew
>
>
>> + };
>> +
>> + tee {
>> + description = "OPTEE";
>> + type = "tee";
>> + arch = "arm64";
>> + compression = "none";
>> + os = "tee";
>> + load = <0x9e80>;
>> + entry = <0x9e80>;
>> + tee-os {
>> + filename = "tee-pager_v2.bin";
>> + };
>> + };
>> +
>> + 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 = <0x8008>;
>> + entry = <0x8008>;
>> +#ifdef CONFIG_TI_SECURE_DEVICE
>> + ti-secure {
>> +#else
>> + blob {
>> +#endif
>> + filename = SPL_NODTB;
>> + };
>> + };
>> +
>> + fdt-1 {
>> + description = "k3-am642-evm";
>> + type = "flat_dt";
>> + arch = "arm";
>> + compression = "none";
>> +#ifdef CONFIG_TI_SECURE_DEVICE
>> + ti-secure {
>> +#else
>> + blob {
>> +#endif
>> + filename = SPL_AM642_EVM_DTB;
>> + };
>> + };
>> +
>> +
[PATCH v2 09/12] board: ti: Introduce the basic files to support AM62 SK board
From: Suman Anna
Add basic support for AM62 SK. This has 2GB DDR.
Note that stack for R5 SPL is in OCRAM @ 0x7000 so that is away from
BSS and does not step on BSS section
Add only the bare minimum required to support UART and SD.
Signed-off-by: Suman Anna
Signed-off-by: Aswath Govindraju
Signed-off-by: Nishanth Menon
Signed-off-by: Vignesh Raghavendra
---
arch/arm/mach-k3/Kconfig | 1 +
board/ti/am62x/Kconfig | 59
board/ti/am62x/Makefile | 8 ++
board/ti/am62x/evm.c | 39 ++
4 files changed, 107 insertions(+)
create mode 100644 board/ti/am62x/Kconfig
create mode 100644 board/ti/am62x/Makefile
create mode 100644 board/ti/am62x/evm.c
diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
index 0dc4f44fdd..57f693e9a1 100644
--- a/arch/arm/mach-k3/Kconfig
+++ b/arch/arm/mach-k3/Kconfig
@@ -178,6 +178,7 @@ config K3_DM_FW
source "board/ti/am65x/Kconfig"
source "board/ti/am64x/Kconfig"
+source "board/ti/am62x/Kconfig"
source "board/ti/j721e/Kconfig"
source "board/siemens/iot2050/Kconfig"
source "board/ti/j721s2/Kconfig"
diff --git a/board/ti/am62x/Kconfig b/board/ti/am62x/Kconfig
new file mode 100644
index 00..87fed44df1
--- /dev/null
+++ b/board/ti/am62x/Kconfig
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+# Suman Anna
+
+choice
+ prompt "TI K3 AM62x based boards"
+ optional
+
+config TARGET_AM625_A53_EVM
+ bool "TI K3 based AM625 EVM running on A53"
+ select ARM64
+ select SOC_K3_AM625
+
+config TARGET_AM625_R5_EVM
+ bool "TI K3 based AM625 EVM running on R5"
+ select CPU_V7R
+ select SYS_THUMB_BUILD
+ select K3_LOAD_SYSFW
+ select SOC_K3_AM625
+ select RAM
+ select SPL_RAM
+ select K3_DDRSS
+ imply SYS_K3_SPL_ATF
+
+endchoice
+
+if TARGET_AM625_A53_EVM
+
+config SYS_BOARD
+ default "am62x"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "am62x_evm"
+
+source "board/ti/common/Kconfig"
+
+endif
+
+if TARGET_AM625_R5_EVM
+
+config SYS_BOARD
+ default "am62x"
+
+config SYS_VENDOR
+ default "ti"
+
+config SYS_CONFIG_NAME
+ default "am62x_evm"
+
+config SPL_LDSCRIPT
+ default "arch/arm/mach-omap2/u-boot-spl.lds"
+
+source "board/ti/common/Kconfig"
+
+endif
diff --git a/board/ti/am62x/Makefile b/board/ti/am62x/Makefile
new file mode 100644
index 00..f4c35edffa
--- /dev/null
+++ b/board/ti/am62x/Makefile
@@ -0,0 +1,8 @@
+#
+# Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+# Suman Anna
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-y += evm.o
diff --git a/board/ti/am62x/evm.c b/board/ti/am62x/evm.c
new file mode 100644
index 00..4dd5e64299
--- /dev/null
+++ b/board/ti/am62x/evm.c
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Board specific initialization for AM62x platforms
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ * Suman Anna
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+int board_init(void)
+{
+ return 0;
+}
+
+int dram_init(void)
+{
+ gd->ram_size = 0x8000;
+
+ return 0;
+}
+
+int dram_init_banksize(void)
+{
+ /* Bank 0 declares the memory available in the DDR low region */
+ gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = 0x8000;
+ gd->ram_size = 0x8000;
+
+ return 0;
+}
--
2.36.1
[PATCH 2/2] bootmenu: U-Boot console is enabled as default
The commit 2158b0da220c ("bootmenu: add Kconfig option
not to enter U-Boot console") disables to enter U-Boot
console from bootmenu as default, this change affects the
existing bootmenu users.
This commit reverts the default behavior, the bootmenu can
enter U-Boot console same as before.
CMD_BOOTMENU_ENTER_UBOOT_CONSOLE is renamed
BOOTMENU_DISABLE_UBOOT_CONSOLE and depends on
AUTOBOOT_MENU_SHOW.
Fixes: 2158b0da220c ("bootmenu: add Kconfig option not to enter U-Boot console")
Signed-off-by: Masahisa Kojima
---
boot/Kconfig | 9 +
cmd/Kconfig| 10 --
cmd/bootmenu.c | 4 ++--
3 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/boot/Kconfig b/boot/Kconfig
index dff4d23b88..2eae3d5c6b 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -1143,6 +1143,15 @@ config AUTOBOOT_MENU_SHOW
environmnent variable (if enabled) and before handling the boot delay.
See README.bootmenu for more details.
+config BOOTMENU_DISABLE_UBOOT_CONSOLE
+ bool "Disallow bootmenu to enter the U-Boot console"
+ depends on AUTOBOOT_MENU_SHOW
+ default n
+ help
+ If this option is enabled, user can not enter
+ the U-Boot console from bootmenu. It increases
+ the system security.
+
config BOOT_RETRY
bool "Boot retry feature"
help
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 69c1814d24..09193b61b9 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -357,16 +357,6 @@ config CMD_BOOTMENU
help
Add an ANSI terminal boot menu command.
-config CMD_BOOTMENU_ENTER_UBOOT_CONSOLE
- bool "Allow Bootmenu to enter the U-Boot console"
- depends on CMD_BOOTMENU
- default n
- help
- Add an entry to enter U-Boot console in bootmenu.
- If this option is disabled, user can not enter
- the U-Boot console from bootmenu. It increases
- the system security.
-
config CMD_ADTIMG
bool "adtimg"
help
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index bf88c2127b..1002c6b20a 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -362,7 +362,7 @@ static struct bootmenu_data *bootmenu_create(int delay)
goto cleanup;
/* Add Quit entry if entering U-Boot console is disabled */
- if (IS_ENABLED(CONFIG_CMD_BOOTMENU_ENTER_UBOOT_CONSOLE))
+ if (!IS_ENABLED(CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE))
entry->title = strdup("U-Boot console");
else
entry->title = strdup("Quit");
@@ -595,7 +595,7 @@ int menu_show(int bootdelay)
if (ret == BOOTMENU_RET_UPDATED)
continue;
- if (!IS_ENABLED(CONFIG_CMD_BOOTMENU_ENTER_UBOOT_CONSOLE)) {
+ if (IS_ENABLED(CONFIG_BOOTMENU_DISABLE_UBOOT_CONSOLE)) {
if (ret == BOOTMENU_RET_QUIT) {
/* default boot process */
if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR))
--
2.17.1
[PATCH 1/2] bootmenu: use utf-8 for menu title
The commit a3d0aa87acbe ("bootmenu: update bootmenu_entry structure")
changes the bootmenu title type from char to u16(UTF16 string)
to support EFI based system. If EFI_LOADER is not enabled,
printf("%ls") is not supported, so bootmenu does not appear
correctly.
This commit changes the type of menu title from u16(UTF16) to
utf-8 string and EFI strings is conveted into utf-8.
Fixes: a3d0aa87acbe ("bootmenu: update bootmenu_entry structure")
Signed-off-by: Masahisa Kojima
---
cmd/bootmenu.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
index 8859eebea5..bf88c2127b 100644
--- a/cmd/bootmenu.c
+++ b/cmd/bootmenu.c
@@ -43,7 +43,7 @@ enum boot_type {
struct bootmenu_entry {
unsigned short int num; /* unique number 0 .. MAX_COUNT */
char key[3];/* key identifier of number */
- u16 *title; /* title of entry */
+ char *title;/* title of entry */
char *command; /* hush command of entry */
enum boot_type type;/* boot type of entry */
u16 bootorder; /* order for each boot type */
@@ -76,7 +76,7 @@ static void bootmenu_print_entry(void *data)
if (reverse)
puts(ANSI_COLOR_REVERSE);
- printf("%ls", entry->title);
+ printf("%s", entry->title);
if (reverse)
puts(ANSI_COLOR_RESET);
@@ -170,7 +170,7 @@ static int prepare_bootmenu_entry(struct bootmenu_data
*menu,
struct bootmenu_entry *iter = *current;
while ((option = bootmenu_getoption(i))) {
- u16 *buf;
+ char *buf;
sep = strchr(option, '=');
if (!sep) {
@@ -183,13 +183,13 @@ static int prepare_bootmenu_entry(struct bootmenu_data
*menu,
return -ENOMEM;
len = sep-option;
- buf = calloc(1, (len + 1) * sizeof(u16));
+ buf = calloc(1, (len + 1));
entry->title = buf;
if (!entry->title) {
free(entry);
return -ENOMEM;
}
- utf8_utf16_strncpy(, option, len);
+ strncpy(buf, option, len);
len = strlen(sep + 1);
entry->command = malloc(len + 1);
@@ -227,6 +227,7 @@ static int prepare_bootmenu_entry(struct bootmenu_data
*menu,
return 1;
}
+#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR))
/**
* prepare_uefi_bootorder_entry() - generate the uefi bootmenu entries
*
@@ -279,13 +280,17 @@ static int prepare_uefi_bootorder_entry(struct
bootmenu_data *menu,
}
if (lo.attributes & LOAD_OPTION_ACTIVE) {
- entry->title = u16_strdup(lo.label);
- if (!entry->title) {
+ char *buf;
+
+ buf = calloc(1, utf16_utf8_strlen(lo.label) + 1);
+ if (!buf) {
free(load_option);
free(entry);
free(bootorder);
return -ENOMEM;
}
+ entry->title = buf;
+ utf16_utf8_strncpy(, lo.label,
u16_strlen(lo.label));
entry->command = strdup("bootefi bootmgr");
sprintf(entry->key, "%d", i);
entry->num = i;
@@ -315,6 +320,7 @@ static int prepare_uefi_bootorder_entry(struct
bootmenu_data *menu,
return 1;
}
+#endif
static struct bootmenu_data *bootmenu_create(int delay)
{
@@ -341,13 +347,13 @@ static struct bootmenu_data *bootmenu_create(int delay)
if (ret < 0)
goto cleanup;
- if (IS_ENABLED(CONFIG_CMD_BOOTEFI_BOOTMGR)) {
- if (i < MAX_COUNT - 1) {
+#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR))
+ if (i < MAX_COUNT - 1) {
ret = prepare_uefi_bootorder_entry(menu, , );
if (ret < 0 && ret != -ENOENT)
goto cleanup;
- }
}
+#endif
/* Add U-Boot console entry at the end */
if (i <= MAX_COUNT - 1) {
@@ -357,9 +363,9 @@ static struct bootmenu_data *bootmenu_create(int delay)
/* Add Quit entry if entering U-Boot console is disabled */
if (IS_ENABLED(CONFIG_CMD_BOOTMENU_ENTER_UBOOT_CONSOLE))
- entry->title = u16_strdup(u"U-Boot console");
+ entry->title = strdup("U-Boot console");
else
- entry->title = u16_strdup(u"Quit");
+ entry->title = strdup("Quit");
if (!entry->title) {
free(entry);
@@ -461,7 +467,7 @@ static enum bootmenu_ret
[PATCH 0/2] fix issues in bootmenu after adding efi entries
This series fixes the issue in bootmenu after adding efi entries. Masahisa Kojima (2): bootmenu: use utf-8 for menu title bootmenu: U-Boot console is enabled as default boot/Kconfig | 9 + cmd/Kconfig| 10 -- cmd/bootmenu.c | 40 +++- 3 files changed, 32 insertions(+), 27 deletions(-) -- 2.17.1
Re: [PATCH v2 01/12] drivers: mmc: am654_sdhci: Add new compatible for AM62 SoC
On 5/25/22 17:08, Vignesh Raghavendra wrote:
> From: Aswath Govindraju
>
> The phy used in the 8 bit instance has been changed to the phy used in 4
> bit instance on AM62 SoC. This implies the phy configuration required for
> both the instances of mmc are similar. Therefore, add a new compatible
> for AM62 SoC using the driver data of am64 4 bit instance.
>
> Signed-off-by: Aswath Govindraju
> Signed-off-by: Vignesh Raghavendra
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/am654_sdhci.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
> index 4305967d78..42a6134364 100644
> --- a/drivers/mmc/am654_sdhci.c
> +++ b/drivers/mmc/am654_sdhci.c
> @@ -670,6 +670,10 @@ static const struct udevice_id am654_sdhci_ids[] = {
> .compatible = "ti,am64-sdhci-4bit",
> .data = (ulong)_am64_4bit_drvdata,
> },
> + {
> + .compatible = "ti,am62-sdhci",
> + .data = (ulong)_am64_4bit_drvdata,
> + },
> { }
> };
>
Re: [PATCH v2] mmc: nuvoton: Add NPCM7xx mmc driver
On 5/24/22 17:55, Jim Liu wrote:
> Add Nuvoton BMC NPCM750 mmc control driver.
>
> Signed-off-by: Jim Liu
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
>- modify kconfig description
>- use mmc_of_parse
>- modify U_BOOT_DRIVER and Copyright time
> ---
> drivers/mmc/Kconfig | 12 ++
> drivers/mmc/Makefile | 1 +
> drivers/mmc/npcm_sdhci.c | 86
> 3 files changed, 99 insertions(+)
> create mode 100644 drivers/mmc/npcm_sdhci.c
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index f04cc44e19..f6a1eb2ac5 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -607,6 +607,18 @@ config MMC_SDHCI_MV
>
> If unsure, say N.
>
> +config MMC_SDHCI_NPCM
> + bool "SDHCI support on Nuvoton NPCM device"
> + depends on MMC_SDHCI
> + depends on DM_MMC
> + help
> + This selects the Secure Digital Host Controller Interface (SDHCI)
> + on Nuvoton NPCM device.
> +
> + If you have a controller with this interface, say Y here.
> +
> + If unsure, say N.
> +
> config MMC_SDHCI_PIC32
> bool "Microchip PIC32 on-chip SDHCI support"
> depends on DM_MMC && MACH_PIC32
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 9627509302..280da24567 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_MMC_SDHCI_IPROC) += iproc_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_KONA) += kona_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_MSM) += msm_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_MV) += mv_sdhci.o
> +obj-$(CONFIG_MMC_SDHCI_NPCM)+= npcm_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_PIC32)+= pic32_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_ROCKCHIP) += rockchip_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_S5P) += s5p_sdhci.o
> diff --git a/drivers/mmc/npcm_sdhci.c b/drivers/mmc/npcm_sdhci.c
> new file mode 100644
> index 00..7eb17cce0b
> --- /dev/null
> +++ b/drivers/mmc/npcm_sdhci.c
> @@ -0,0 +1,86 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (c) 2022 Nuvoton Technology Corp.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define NPCM_SDHC_MIN_FREQ 40
> +
> +struct npcm_sdhci_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +static int npcm_sdhci_probe(struct udevice *dev)
> +{
> + struct npcm_sdhci_plat *plat = dev_get_plat(dev);
> + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> + struct sdhci_host *host = dev_get_priv(dev);
> + struct udevice *vqmmc_supply;
> + int vqmmc_uv, ret;
> + struct clk clk;
> +
> + host->name = dev->name;
> + host->ioaddr = dev_read_addr_ptr(dev);
> + host->max_clk = dev_read_u32_default(dev, "clock-frequency", 0);
> +
> + ret = clk_get_by_index(dev, 0, );
> + if (!ret && host->max_clk) {
> + ret = clk_set_rate(, host->max_clk);
> + if (ret < 0)
> + return ret;
> + }
> +
> + if (IS_ENABLED(CONFIG_DM_REGULATOR)) {
> + device_get_supply_regulator(dev, "vqmmc-supply", _supply);
> + vqmmc_uv = dev_read_u32_default(dev, "vqmmc-microvolt", 0);
> + /* Set IO voltage */
> + if (vqmmc_supply && vqmmc_uv)
> + regulator_set_value(vqmmc_supply, vqmmc_uv);
> + }
> +
> + host->index = dev_read_u32_default(dev, "index", 0);
> + ret = mmc_of_parse(dev, >cfg);
> + if (ret)
> + return ret;
> +
> + host->mmc = >mmc;
> + host->mmc->priv = host;
> + host->mmc->dev = dev;
> + upriv->mmc = host->mmc;
> +
> + ret = sdhci_setup_cfg(>cfg, host, 0, NPCM_SDHC_MIN_FREQ);
> + if (ret)
> + return ret;
> +
> + return sdhci_probe(dev);
> +}
> +
> +static int npcm_sdhci_bind(struct udevice *dev)
> +{
> + struct npcm_sdhci_plat *plat = dev_get_plat(dev);
> +
> + return sdhci_bind(dev, >mmc, >cfg);
> +}
> +
> +static const struct udevice_id npcm_mmc_ids[] = {
> + { .compatible = "nuvoton,npcm750-sdhci" },
> + { .compatible = "nuvoton,npcm845-sdhci" },
> + { }
> +};
> +
> +U_BOOT_DRIVER(npcm_sdhci_drv) = {
> + .name = "npcm_sdhci",
> + .id = UCLASS_MMC,
> + .of_match = npcm_mmc_ids,
> + .ops= _ops,
> + .bind = npcm_sdhci_bind,
> + .probe = npcm_sdhci_probe,
> + .priv_auto = sizeof(struct sdhci_host),
> + .plat_auto = sizeof(struct npcm_sdhci_plat),
> +};
[PATCH v2 10/12] arm: dts: Add support for AM62-SK
From: Nishanth Menon
AM62 StarterKit (SK) board is a low cost, small form factor board
designed for TI’s AM625 SoC. It supports the following interfaces:
* 2 GB DDR4 RAM
* x2 Gigabit Ethernet interfaces capable of working in Switch and MAC mode
* x1 HDMI Port with audio + x1 OLDI/LVDS Display interface for Dual Display
* x1 Headphone Jack
* x1 USB2.0 Hub with two Type A host and x1 USB Type-C DRP Port
* x1 UHS-1 capable µSD card slot
* 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837
* 512 Mbit OSPI flash
* x4 UART through UART-USB bridge
* XDS110 for onboard JTAG debug using USB
* Temperature sensors, user push buttons and LEDs
* 40-pin User Expansion Connector
* 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO)
* 20-pin header for Programmable Realtime Unit (PRU) IO pins
* 15-pin CSI header
Add basic support for AM62-SK.
To keep the changes to minimum. Only UART And SD are supported at the
moment. This should serve as good example for adding new board support
based on AM62x SoC
Schematics: https://www.ti.com/lit/zip/sprr448
Signed-off-by: Nishanth Menon
Signed-off-by: Aswath Govindraju
Signed-off-by: Nishanth Menon
Signed-off-by: Dave Gerlach
Signed-off-by: Vignesh Raghavendra
---
arch/arm/dts/Makefile |3 +
arch/arm/dts/k3-am625-r5-sk.dts| 140 ++
arch/arm/dts/k3-am625-sk-u-boot.dtsi | 100 +
arch/arm/dts/k3-am625-sk.dts | 150 ++
arch/arm/dts/k3-am62x-sk-ddr4-1600MTs.dtsi | 2189
5 files changed, 2582 insertions(+)
create mode 100644 arch/arm/dts/k3-am625-r5-sk.dts
create mode 100644 arch/arm/dts/k3-am625-sk-u-boot.dtsi
create mode 100644 arch/arm/dts/k3-am625-sk.dts
create mode 100644 arch/arm/dts/k3-am62x-sk-ddr4-1600MTs.dtsi
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 3ca980aae0..d1df5ae196 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1177,6 +1177,9 @@ dtb-$(CONFIG_SOC_K3_AM642) += k3-am642-evm.dtb \
k3-am642-sk.dtb \
k3-am642-r5-sk.dtb
+dtb-$(CONFIG_SOC_K3_AM625) += k3-am625-sk.dtb \
+ k3-am625-r5-sk.dtb
+
dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7622-rfb.dtb \
mt7623a-unielec-u7623-02-emmc.dtb \
diff --git a/arch/arm/dts/k3-am625-r5-sk.dts b/arch/arm/dts/k3-am625-r5-sk.dts
new file mode 100644
index 00..2691af40a1
--- /dev/null
+++ b/arch/arm/dts/k3-am625-r5-sk.dts
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AM625 SK dts file for R5 SPL
+ * Copyright (C) 2021-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am625-sk.dts"
+#include "k3-am62x-sk-ddr4-1600MTs.dtsi"
+#include "k3-am62-ddr.dtsi"
+
+#include "k3-am625-sk-u-boot.dtsi"
+
+/ {
+ aliases {
+ remoteproc0 =
+ remoteproc1 = _0;
+ serial0 = _uart0;
+ serial3 = _uart1;
+ };
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ tick-timer =
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ /* 2G RAM */
+ reg = <0x 0x8000 0x 0x8000>;
+
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ secure_ddr: optee@9e80 {
+ reg = <0x00 0x9e80 0x00 0x0180>; /* for OP-TEE
*/
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ a53_0: a53@0 {
+ compatible = "ti,am654-rproc";
+ reg = <0x00 0x00a9 0x00 0x10>;
+ power-domains = <_pds 61 TI_SCI_PD_EXCLUSIVE>,
+ <_pds 135 TI_SCI_PD_EXCLUSIVE>;
+ resets = <_reset 135 0>;
+ clocks = <_clks 61 0>;
+ assigned-clocks = <_clks 61 0>, <_clks 135 0>;
+ assigned-clock-parents = <_clks 61 2>;
+ assigned-clock-rates = <2>, <12>;
+ ti,sci = <>;
+ ti,sci-proc-id = <32>;
+ ti,sci-host-id = <10>;
+ u-boot,dm-spl;
+ };
+
+ dm_tifs: dm-tifs {
+ compatible = "ti,j721e-dm-sci";
+ ti,host-id = <36>;
+ ti,secure-host;
+ mbox-names = "rx", "tx";
+ mboxes= <_proxy_main 22>,
+ <_proxy_main 23>;
+ u-boot,dm-spl;
+ };
+};
+
+ {
+ mboxes= <_proxy_main 0>,
+ <_proxy_main 1>,
+ <_proxy_main 0>;
+ mbox-names = "rx", "tx", "notify";
+ ti,host-id = <35>;
+ ti,secure-host;
+};
+
+_main {
+ sa3_secproxy: secproxy@4488 {
+ u-boot,dm-spl;
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names =
[PATCH v2 08/12] arm: dts: Introduce base AM62 SoC dtsi files
From: Suman Anna
Introduce the basic AM62 SoC description dtsi files describing most
peripherals as per kernel dts.
Signed-off-by: Gowtham Tammana
Signed-off-by: Suman Anna
Signed-off-by: Vignesh Raghavendra
---
arch/arm/dts/k3-am62-ddr.dtsi| 11 +
arch/arm/dts/k3-am62-main.dtsi | 533 +++
arch/arm/dts/k3-am62-mcu.dtsi| 56
arch/arm/dts/k3-am62-wakeup.dtsi | 41 +++
arch/arm/dts/k3-am62.dtsi| 105 ++
arch/arm/dts/k3-am625.dtsi | 103 ++
6 files changed, 849 insertions(+)
create mode 100644 arch/arm/dts/k3-am62-ddr.dtsi
create mode 100644 arch/arm/dts/k3-am62-main.dtsi
create mode 100644 arch/arm/dts/k3-am62-mcu.dtsi
create mode 100644 arch/arm/dts/k3-am62-wakeup.dtsi
create mode 100644 arch/arm/dts/k3-am62.dtsi
create mode 100644 arch/arm/dts/k3-am625.dtsi
diff --git a/arch/arm/dts/k3-am62-ddr.dtsi b/arch/arm/dts/k3-am62-ddr.dtsi
new file mode 100644
index 00..0a8ced8f38
--- /dev/null
+++ b/arch/arm/dts/k3-am62-ddr.dtsi
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "k3-am64-ddr.dtsi"
+ {
+ power-domains = <_pds 170 TI_SCI_PD_SHARED>,
+ <_pds 55 TI_SCI_PD_SHARED>;
+ clocks = <_clks 170 0>, <_clks 16 4>;
+};
diff --git a/arch/arm/dts/k3-am62-main.dtsi b/arch/arm/dts/k3-am62-main.dtsi
new file mode 100644
index 00..4b6ba98dd0
--- /dev/null
+++ b/arch/arm/dts/k3-am62-main.dtsi
@@ -0,0 +1,533 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM625 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+_main {
+ oc_sram: sram@7000 {
+ compatible = "mmio-sram";
+ reg = <0x00 0x7000 0x00 0x1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x7000 0x1>;
+ };
+
+ gic500: interrupt-controller@180 {
+ compatible = "arm,gic-v3";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x00 0x0180 0x00 0x1>, /* GICD */
+ <0x00 0x0188 0x00 0xc>, /* GICR */
+ <0x00 0x0188 0x00 0xc>, /* GICR */
+ <0x01 0x 0x00 0x2000>,/* GICC */
+ <0x01 0x0001 0x00 0x1000>,/* GICH */
+ <0x01 0x0002 0x00 0x2000>;/* GICV */
+ /*
+* vcpumntirq:
+* virtual CPU interface maintenance interrupt
+*/
+ interrupts = ;
+
+ gic_its: msi-controller@182 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x00 0x0182 0x00 0x1>;
+ socionext,synquacer-pre-its = <0x100 0x40>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+
+ main_conf: syscon@10 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x00 0x0010 0x00 0x2>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x00 0x0010 0x2>;
+
+ phy_gmii_sel: phy@4044 {
+ compatible = "ti,am654-phy-gmii-sel";
+ reg = <0x4044 0x8>;
+ #phy-cells = <1>;
+ };
+ };
+
+ dmss: bus@4800 {
+ compatible = "simple-mfd";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-ranges;
+ ranges = <0x00 0x4800 0x00 0x4800 0x00 0x0640>;
+
+ ti,sci-dev-id = <25>;
+
+ secure_proxy_main: mailbox@4d00 {
+ compatible = "ti,am654-secure-proxy";
+ #mbox-cells = <1>;
+ reg-names = "target_data", "rt", "scfg";
+ reg = <0x00 0x4d00 0x00 0x8>,
+ <0x00 0x4a60 0x00 0x8>,
+ <0x00 0x4a40 0x00 0x8>;
+ interrupt-names = "rx_012";
+ interrupts = ;
+ };
+
+ inta_main_dmss: interrupt-controller@4800 {
+ compatible = "ti,sci-inta";
+ reg = <0x00 0x4800 0x00 0x10>;
+ #interrupt-cells = <0>;
+ interrupt-controller;
+ interrupt-parent = <>;
+ msi-controller;
+ ti,sci = <>;
+ ti,sci-dev-id = <28>;
+
[PATCH v2 12/12] doc: ti: Add readme for AM62x SK
Add info of boot flow and build steps for AM62x SK. Signed-off-by: Vignesh Raghavendra --- doc/board/ti/am62x_sk.rst | 231 ++ doc/board/ti/index.rst| 1 + 2 files changed, 232 insertions(+) create mode 100644 doc/board/ti/am62x_sk.rst diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst new file mode 100644 index 00..4e68c2018a --- /dev/null +++ b/doc/board/ti/am62x_sk.rst @@ -0,0 +1,231 @@ +.. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause +.. sectionauthor:: Vignesh Raghavendra + +Texas Instruments AM62 Platforms + + +Introduction: +- +The AM62 SoC family is the follow on AM335x built on the K3 Multicore +SoC architecture platform, providing ultra-low-power modes, dual +display, multi-sensor edge compute, security and other BOM-saving +integrations. The AM62 SoC targets a broad market to enable +applications such as Industrial HMI, PLC/CNC/Robot control, Medical +Equipment, Building Automation, Appliances and more. + +Some highlights of this SoC are: + +* Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. + Pin-to-pin compatible options for single and quad core are available. +* Cortex-M4F for general-purpose or safety usage. +* Dual display support, providing 24-bit RBG parallel interface and + OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display + resolution. +* Selectable GPU support, up to 8GFLOPS, providing better user experience + in 3D graphic display case and Android. +* PRU(Programmable Realtime Unit) support for customized programmable + interfaces/IOs. +* Integrated Giga-bit Ethernet switch supporting up to a total of two + external ports (TSN capable). +* 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for + NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio, + 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals. +* Dedicated Centralized System Controller for Security, Power, and + Resource Management. +* Multiple low power modes support, ex: Deep sleep, Standby, MCU-only, + enabling battery powered system design. + +More details can be found in the Technical Reference Manual: +https://www.ti.com/lit/pdf/spruiv7 + +Boot Flow: +-- +Below is the pictorial representation of boot flow: + +.. code-block:: text + + ++ + |TIFS| Main R5 |A53| + ++ + |++ | | | + || Reset | | | | + |++ | | | + | : | | | + |++ | +---+ | | + || *ROM* |--|-->| Reset rls | | | + |++ | +---+ | | + ||| | : | | + || ROM | | : | | + ||services| | : | | + ||| | +-+ | | + ||| | | *R5 ROM* | | | + ||| | +-+ | | + |||<-|---|Load and auth| | | + ||| | | tiboot3.bin | | | + |++ | +-+ | | + |||<-|---| Load sysfw | | | + ||| | | part to TIFS| | | + ||| | | core| | | + ||| | +-+ | | + ||| | : | | + ||| | : | | + ||| | : | | + ||| | +-+ | | + ||| | | *R5 SPL* | | | + ||| | +-+ | | + ||| | |DDR | | | + ||| | | config| | | + ||| | +-+ | | + ||| | |Load | | | + ||| | | tispl.bin | | | + |||
[PATCH v2 11/12] configs: Add configs for AM62x SK
Add am62x_evm_r5_defconfig for R5 SPL and am62x_evm_a53_defconfig for
A53 SPL and U-Boot support.
To keep the changes to minimum. Only UART And SD boot related configs
are included. This should serve as good starting point for new board
bringup with AM62x.
Signed-off-by: Aswath Govindraju
Signed-off-by: Vignesh Raghavendra
---
board/ti/am62x/MAINTAINERS | 8 +++
configs/am62x_evm_a53_defconfig | 71 +
configs/am62x_evm_r5_defconfig | 91 +++
include/configs/am62x_evm.h | 106
4 files changed, 276 insertions(+)
create mode 100644 board/ti/am62x/MAINTAINERS
create mode 100644 configs/am62x_evm_a53_defconfig
create mode 100644 configs/am62x_evm_r5_defconfig
create mode 100644 include/configs/am62x_evm.h
diff --git a/board/ti/am62x/MAINTAINERS b/board/ti/am62x/MAINTAINERS
new file mode 100644
index 00..105e741995
--- /dev/null
+++ b/board/ti/am62x/MAINTAINERS
@@ -0,0 +1,8 @@
+AM62x BOARD
+M: Dave Gerlach
+M: Tom Rini
+S: Maintained
+F: board/ti/am62x/
+F: include/configs/am62x_evm.h
+F: configs/am62x_evm_r5_defconfig
+F: configs/am62x_evm_a53_defconfig
diff --git a/configs/am62x_evm_a53_defconfig b/configs/am62x_evm_a53_defconfig
new file mode 100644
index 00..fd18fbd890
--- /dev/null
+++ b/configs/am62x_evm_a53_defconfig
@@ -0,0 +1,71 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x8000
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_SOC_K3_AM625=y
+CONFIG_K3_ATF_LOAD_ADDR=0x9e78
+CONFIG_TARGET_AM625_A53_EVM=y
+CONFIG_SPL_TEXT_BASE=0x8008
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-sk"
+CONFIG_DISTRO_DEFAULTS=y
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8100
+CONFIG_BOOTCOMMAND="run findfdt; run envboot; run init_${boot}; run
get_kern_${boot}; run get_fdt_${boot}; run get_overlay_${boot}; run run_kern"
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x1400
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_CMD_MMC=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_REGMAP=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_OF_TRANSLATE=y
+CONFIG_CLK=y
+CONFIG_SPL_CLK=y
+CONFIG_CLK_TI_SCI=y
+CONFIG_TI_SCI_PROTOCOL=y
+CONFIG_DM_MAILBOX=y
+CONFIG_K3_SEC_PROXY=y
+CONFIG_DM_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ADMA=y
+CONFIG_SPL_MMC_SDHCI_ADMA=y
+CONFIG_MMC_SDHCI_AM654=y
+CONFIG_PINCTRL=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+CONFIG_POWER_DOMAIN=y
+CONFIG_TI_SCI_POWER_DOMAIN=y
+CONFIG_K3_SYSTEM_CONTROLLER=y
+CONFIG_REMOTEPROC_TI_K3_ARM64=y
+CONFIG_DM_RESET=y
+CONFIG_RESET_TI_SCI=y
+CONFIG_DM_SERIAL=y
+CONFIG_SOC_DEVICE=y
+CONFIG_SOC_DEVICE_TI_K3=y
+CONFIG_SOC_TI=y
+CONFIG_SYSRESET=y
+CONFIG_SPL_SYSRESET=y
+CONFIG_SYSRESET_TI_SCI=y
+CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
+CONFIG_OF_LIBFDT_OVERLAY=y
diff --git a/configs/am62x_evm_r5_defconfig b/configs/am62x_evm_r5_defconfig
new file mode 100644
index 00..0e1b2ef13e
--- /dev/null
+++ b/configs/am62x_evm_r5_defconfig
@@ -0,0 +1,91 @@
+CONFIG_ARM=y
+CONFIG_ARCH_K3=y
+CONFIG_SPL_GPIO_SUPPORT=y
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x9000
+CONFIG_SOC_K3_AM625=y
+CONFIG_TARGET_AM625_R5_EVM=y
+CONFIG_DM_GPIO=y
+CONFIG_SPL_DM_SPI=y
+CONFIG_SPL_TEXT_BASE=0x43c0
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_SIZE_LIMIT=0x4
+CONFIG_SPL_FS_FAT=y
+CONFIG_SPL_LIBDISK_SUPPORT=y
+CONFIG_DEFAULT_DEVICE_TREE="k3-am625-r5-sk"
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_LOAD_FIT_ADDRESS=0x8008
+CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_SPL_SYS_REPORT_STACK_F_USAGE=y
+CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_EARLY_BSS=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x400
+CONFIG_SPL_DM_MAILBOX=y
+CONFIG_SPL_DM_RESET=y
+CONFIG_SPL_POWER_DOMAIN=y
+CONFIG_SPL_RAM_SUPPORT=y
+CONFIG_SPL_RAM_DEVICE=y
+CONFIG_SPL_REMOTEPROC=y
+CONFIG_SPL_YMODEM_SUPPORT=y
+CONFIG_HUSH_PARSER=y
+CONFIG_CMD_ASKENV=y
+CONFIG_CMD_DFU=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_REMOTEPROC=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_TIME=y
+CONFIG_CMD_FAT=y
+CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_SYS_RELOC_GD_ENV_ADDR=y
+CONFIG_DM=y
+CONFIG_SPL_DM=y
[PATCH v2 07/12] firmware: ti_sci_static_data: add static DMA chan data
Add range of DMA channels available for R5 SPL usage before DM firmware
is loaded.
Signed-off-by: Vignesh Raghavendra
---
drivers/firmware/ti_sci_static_data.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/firmware/ti_sci_static_data.h
b/drivers/firmware/ti_sci_static_data.h
index e6a3b66c03..8529ef2900 100644
--- a/drivers/firmware/ti_sci_static_data.h
+++ b/drivers/firmware/ti_sci_static_data.h
@@ -118,6 +118,19 @@ static struct ti_sci_resource_static_data rm_static_data[]
= {
};
#endif /* CONFIG_TARGET_J721S2_R5_EVM */
+#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+static struct ti_sci_resource_static_data rm_static_data[] = {
+ /* BC channels */
+ {
+ .dev_id = 26,
+ .subtype = 32,
+ .range_start = 18,
+ .range_num = 2,
+ },
+ { },
+};
+#endif /* CONFIG_SOC_K3_AM625 */
+
#else
static struct ti_sci_resource_static_data rm_static_data[] = {
{ },
--
2.36.1
[PATCH v2 04/12] arm: mach-k3: Introduce the basic files to support AM62
From: Suman Anna The AM62 SoC family is the follow on AM335x built on K3 Multicore SoC architecture platform, providing ultra-low-power modes, dual display, multi-sensor edge compute, security and other BOM-saving integration. The AM62 SoC targets broad market to enable applications such as Industrial HMI, PLC/CNC/Robot control, Medical Equipment, Building Automation, Appliances and more. Some highlights of this SoC are: * Quad-Cortex-A53s (running up to 1.4GHz) in a single cluster. Pin-to-pin compatible options for single and quad core are available. * Cortex-M4F for general-purpose or safety usage. * Dual display support, providing 24-bit RBG parallel interface and OLDI/LVDS-4 Lane x2, up to 200MHz pixel clock support for 2K display resolution. * Selectable GPUsupport, up to 8GFLOPS, providing better user experience in 3D graphic display case and Android. * PRU(Programmable Realtime Unit) support for customized programmable interfaces/IOs. * Integrated Giga-bit Ethernet switch supporting up to a total of two external ports (TSN capable). * 9xUARTs, 5xSPI, 6xI2C, 2xUSB2, 3xCAN-FD, 3x eMMC and SD, GPMC for NAND/FPGA connection, OSPI memory controller, 3xMcASP for audio, 1x CSI-RX-4L for Camera, eCAP/eQEP, ePWM, among other peripherals. * Dedicated Centralized System Controller for Security, Power, and Resource Management. * Multiple low power modes support, ex: Deep sleep,Standby, MCU-only, enabling battery powered system design. AM625 is the first device of the family. Add DT bindings for the same. More details can be found in the Technical Reference Manual: https://www.ti.com/lit/pdf/spruiv7 Signed-off-by: Suman Anna Signed-off-by: Gowtham Tammana Signed-off-by: Aswath Govindraju Signed-off-by: Nishanth Menon Signed-off-by: Vignesh Raghavendra --- arch/arm/mach-k3/Kconfig | 9 +- arch/arm/mach-k3/Makefile | 1 + arch/arm/mach-k3/am625_init.c | 271 ++ arch/arm/mach-k3/arm64-mmu.c | 4 +- arch/arm/mach-k3/include/mach/am62_hardware.h | 75 + arch/arm/mach-k3/include/mach/am62_spl.h | 48 arch/arm/mach-k3/include/mach/hardware.h | 4 + arch/arm/mach-k3/include/mach/spl.h | 5 + drivers/ram/Kconfig | 1 + 9 files changed, 415 insertions(+), 3 deletions(-) create mode 100644 arch/arm/mach-k3/am625_init.c create mode 100644 arch/arm/mach-k3/include/mach/am62_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/am62_spl.h diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig index a01bf23514..0dc4f44fdd 100644 --- a/arch/arm/mach-k3/Kconfig +++ b/arch/arm/mach-k3/Kconfig @@ -16,6 +16,9 @@ config SOC_K3_J721S2 config SOC_K3_AM642 bool "TI's K3 based AM642 SoC Family Support" +config SOC_K3_AM625 + bool "TI's K3 based AM625 SoC Family Support" + endchoice config SYS_SOC @@ -26,6 +29,7 @@ config SYS_K3_NON_SECURE_MSRAM_SIZE default 0x8 if SOC_K3_AM6 default 0x10 if SOC_K3_J721E || SOC_K3_J721S2 default 0x1c if SOC_K3_AM642 + default 0x3c000 if SOC_K3_AM625 help Describes the total size of the MCU or OCMC MSRAM present on the SoC in use. This doesn't specify the total size of SPL as @@ -37,6 +41,7 @@ config SYS_K3_MAX_DOWNLODABLE_IMAGE_SIZE default 0x58000 if SOC_K3_AM6 default 0xc if SOC_K3_J721E || SOC_K3_J721S2 default 0x18 if SOC_K3_AM642 + default 0x38000 if SOC_K3_AM625 help Describes the maximum size of the image that ROM can download from any boot media. @@ -61,6 +66,7 @@ config SYS_K3_BOOT_PARAM_TABLE_INDEX default 0x41cffbfc if SOC_K3_J721E default 0x41cfdbfc if SOC_K3_J721S2 default 0x701bebfc if SOC_K3_AM642 + default 0x43c3f290 if SOC_K3_AM625 help Address at which ROM stores the value which determines if SPL is booted up by primary boot media or secondary boot media. @@ -129,6 +135,7 @@ config K3_SYSFW_IMAGE_MMCSD_RAW_MODE_PART config K3_SYSFW_IMAGE_SIZE_MAX int "Amount of memory dynamically allocated for loading SYSFW blob" depends on K3_LOAD_SYSFW + default 163840 if SOC_K3_AM625 default 278000 help Amount of memory (in bytes) reserved through dynamic allocation at @@ -160,7 +167,7 @@ config K3_ATF_LOAD_ADDR config K3_DM_FW bool "Separate DM firmware image" - depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN + depends on SPL && CPU_V7R && (SOC_K3_J721E || SOC_K3_J721S2 || SOC_K3_AM625) && !CLK_TI_SCI && !TI_SCI_POWER_DOMAIN default y help Enabling this will indicate that the system has separate DM diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile index c0a6a9c87d..8459bef93b 100644 --- a/arch/arm/mach-k3/Makefile
[PATCH v2 05/12] arm: mach-k3: am62: Introduce autogenerated SoC data
From: Suman Anna
Introduce autogenerated SoC data support clk and device data for the
AM62. Hook it upto to power-domain and clk frameworks of U-Boot.
Signed-off-by: Dave Gerlach
Signed-off-by: Suman Anna
Signed-off-by: Vignesh Raghavendra
---
arch/arm/mach-k3/am62x/Makefile| 6 +
arch/arm/mach-k3/am62x/clk-data.c | 366 +
arch/arm/mach-k3/am62x/dev-data.c | 78 ++
drivers/clk/ti/clk-k3.c| 6 +
drivers/power/domain/ti-power-domain.c | 6 +
include/k3-clk.h | 1 +
include/k3-dev.h | 1 +
7 files changed, 464 insertions(+)
create mode 100644 arch/arm/mach-k3/am62x/Makefile
create mode 100644 arch/arm/mach-k3/am62x/clk-data.c
create mode 100644 arch/arm/mach-k3/am62x/dev-data.c
diff --git a/arch/arm/mach-k3/am62x/Makefile b/arch/arm/mach-k3/am62x/Makefile
new file mode 100644
index 00..d6c876df66
--- /dev/null
+++ b/arch/arm/mach-k3/am62x/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Copyright (C) 2021 Texas Instruments Incorporated - https://www.ti.com/
+
+obj-y += clk-data.o
+obj-y += dev-data.o
diff --git a/arch/arm/mach-k3/am62x/clk-data.c
b/arch/arm/mach-k3/am62x/clk-data.c
new file mode 100644
index 00..c0881778fe
--- /dev/null
+++ b/arch/arm/mach-k3/am62x/clk-data.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * AM62X specific clock platform data
+ *
+ * This file is auto generated. Please do not hand edit and report any issues
+ * to Dave Gerlach .
+ *
+ * Copyright (C) 2020-2022 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include
+#include "k3-clk.h"
+
+static const char * const gluelogic_hfosc0_clkout_parents[] = {
+ NULL,
+ NULL,
+ "osc_24_mhz",
+ "osc_25_mhz",
+ "osc_26_mhz",
+ NULL,
+};
+
+static const char * const main_emmcsd0_io_clklb_sel_out0_parents[] = {
+ "board_0_mmc0_clklb_out",
+ "board_0_mmc0_clk_out",
+};
+
+static const char * const main_emmcsd1_io_clklb_sel_out0_parents[] = {
+ "board_0_mmc1_clklb_out",
+ "board_0_mmc1_clk_out",
+};
+
+static const char * const main_ospi_loopback_clk_sel_out0_parents[] = {
+ "board_0_ospi0_dqs_out",
+ "board_0_ospi0_lbclko_out",
+};
+
+static const char * const main_usb0_refclk_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "postdiv4_16ff_main_0_hsdivout8_clk",
+};
+
+static const char * const main_usb1_refclk_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "postdiv4_16ff_main_0_hsdivout8_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_main_0_sysclkout_clk_parents[] =
{
+ "gluelogic_hfosc0_clkout",
+ "hsdiv4_16fft_main_0_hsdivout0_clk",
+};
+
+static const char * const sam62_pll_ctrl_wrap_mcu_0_sysclkout_clk_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "hsdiv4_16fft_mcu_0_hsdivout0_clk",
+};
+
+static const char * const clkout0_ctrl_out0_parents[] = {
+ "hsdiv4_16fft_main_2_hsdivout1_clk",
+ "hsdiv4_16fft_main_2_hsdivout1_clk",
+};
+
+static const char * const clk_32k_rc_sel_out0_parents[] = {
+ "gluelogic_rcosc_clk_1p0v_97p65k",
+ "hsdiv0_16fft_mcu_32khz_gen_0_hsdivout0_clk",
+ "clk_32k_rc_sel_div_clkout",
+ "gluelogic_lfosc0_clkout",
+};
+
+static const char * const main_cp_gemac_cpts_clk_sel_out0_parents[] = {
+ "postdiv4_16ff_main_2_hsdivout5_clk",
+ "postdiv4_16ff_main_0_hsdivout6_clk",
+ "board_0_cp_gemac_cpts0_rft_clk_out",
+ NULL,
+ "board_0_mcu_ext_refclk0_out",
+ "board_0_ext_refclk1_out",
+ "sam62_pll_ctrl_wrap_mcu_0_chip_div1_clk_clk",
+ "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
+};
+
+static const char * const main_emmcsd0_refclk_sel_out0_parents[] = {
+ "postdiv4_16ff_main_0_hsdivout5_clk",
+ "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_emmcsd1_refclk_sel_out0_parents[] = {
+ "postdiv4_16ff_main_0_hsdivout5_clk",
+ "hsdiv4_16fft_main_2_hsdivout2_clk",
+};
+
+static const char * const main_gtcclk_sel_out0_parents[] = {
+ "postdiv4_16ff_main_2_hsdivout5_clk",
+ "postdiv4_16ff_main_0_hsdivout6_clk",
+ "board_0_cp_gemac_cpts0_rft_clk_out",
+ NULL,
+ "board_0_mcu_ext_refclk0_out",
+ "board_0_ext_refclk1_out",
+ "sam62_pll_ctrl_wrap_mcu_0_chip_div1_clk_clk",
+ "sam62_pll_ctrl_wrap_main_0_chip_div1_clk_clk",
+};
+
+static const char * const main_ospi_ref_clk_sel_out0_parents[] = {
+ "hsdiv4_16fft_main_0_hsdivout1_clk",
+ "postdiv1_16fft_main_1_hsdivout5_clk",
+};
+
+static const char * const wkup_clkout_sel_out0_parents[] = {
+ "gluelogic_hfosc0_clkout",
+ "gluelogic_lfosc0_clkout",
+ "hsdiv4_16fft_main_0_hsdivout2_clk",
+ "hsdiv4_16fft_main_1_hsdivout2_clk",
+ "postdiv4_16ff_main_2_hsdivout9_clk",
+ "clk_32k_rc_sel_out0",
+ "gluelogic_rcosc_clkout",
+
[PATCH v2 06/12] dma: ti: Add PSIL data for AM62x DMASS
Add PSIL data for AM62x SoC.
Signed-off-by: Vignesh Raghavendra
---
drivers/dma/ti/Makefile | 1 +
drivers/dma/ti/k3-psil-am62.c | 50 +++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 2 ++
4 files changed, 54 insertions(+)
create mode 100644 drivers/dma/ti/k3-psil-am62.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 6a4f4f1365..56f348700d 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -7,3 +7,4 @@ k3-psil-data-$(CONFIG_SOC_K3_AM6) += k3-psil-am654.o
k3-psil-data-$(CONFIG_SOC_K3_J721E) += k3-psil-j721e.o
k3-psil-data-$(CONFIG_SOC_K3_J721S2) += k3-psil-j721s2.o
k3-psil-data-$(CONFIG_SOC_K3_AM642) += k3-psil-am64.o
+k3-psil-data-$(CONFIG_SOC_K3_AM625) += k3-psil-am62.o
diff --git a/drivers/dma/ti/k3-psil-am62.c b/drivers/dma/ti/k3-psil-am62.c
new file mode 100644
index 00..9527da4cac
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am62.c
@@ -0,0 +1,50 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2022 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_ETHERNET(x, ch, flow_base, flow_cnt) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = flow_base, \
+ }, \
+ }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep am62_src_ep_map[] = {
+ /* CPSW3G */
+ PSIL_ETHERNET(0x4600, 19, 19, 16),
+};
+
+/* PSI-L destination thread IDs, used for TX (DMA_MEM_TO_DEV) */
+static struct psil_ep am62_dst_ep_map[] = {
+ /* CPSW3G */
+ PSIL_ETHERNET(0xc600, 19, 19, 8),
+ PSIL_ETHERNET(0xc601, 20, 27, 8),
+ PSIL_ETHERNET(0xc602, 21, 35, 8),
+ PSIL_ETHERNET(0xc603, 22, 43, 8),
+ PSIL_ETHERNET(0xc604, 23, 51, 8),
+ PSIL_ETHERNET(0xc605, 24, 59, 8),
+ PSIL_ETHERNET(0xc606, 25, 67, 8),
+ PSIL_ETHERNET(0xc607, 26, 75, 8),
+};
+
+struct psil_ep_map am62_ep_map = {
+ .name = "am62",
+ .src = am62_src_ep_map,
+ .src_count = ARRAY_SIZE(am62_src_ep_map),
+ .dst = am62_dst_ep_map,
+ .dst_count = ARRAY_SIZE(am62_dst_ep_map),
+};
diff --git a/drivers/dma/ti/k3-psil-priv.h b/drivers/dma/ti/k3-psil-priv.h
index 77acaf2139..28078c6bd8 100644
--- a/drivers/dma/ti/k3-psil-priv.h
+++ b/drivers/dma/ti/k3-psil-priv.h
@@ -41,5 +41,6 @@ extern struct psil_ep_map am654_ep_map;
extern struct psil_ep_map j721e_ep_map;
extern struct psil_ep_map j721s2_ep_map;
extern struct psil_ep_map am64_ep_map;
+extern struct psil_ep_map am62_ep_map;
#endif /* K3_PSIL_PRIV_H_ */
diff --git a/drivers/dma/ti/k3-psil.c b/drivers/dma/ti/k3-psil.c
index 8b2129d4f5..f1330bf4b0 100644
--- a/drivers/dma/ti/k3-psil.c
+++ b/drivers/dma/ti/k3-psil.c
@@ -24,6 +24,8 @@ struct psil_endpoint_config *psil_get_ep_config(u32 thread_id)
soc_ep_map = _ep_map;
else if (IS_ENABLED(CONFIG_SOC_K3_AM642))
soc_ep_map = _ep_map;
+ else if (IS_ENABLED(CONFIG_SOC_K3_AM625))
+ soc_ep_map = _ep_map;
}
if (thread_id & K3_PSIL_DST_THREAD_ID_OFFSET && soc_ep_map->dst) {
--
2.36.1
[PATCH v2 03/12] soc: ti: k3-socinfo: Add entry for AM62X SoC family
From: Suman Anna Add support for AM62x SoC identification. Signed-off-by: Suman Anna Signed-off-by: Vignesh Raghavendra --- drivers/soc/soc_ti_k3.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/soc/soc_ti_k3.c b/drivers/soc/soc_ti_k3.c index 965728e818..42344145f9 100644 --- a/drivers/soc/soc_ti_k3.c +++ b/drivers/soc/soc_ti_k3.c @@ -15,6 +15,7 @@ #define J7200 0xbb6d #define AM64X 0xbb38 #define J721S2 0xbb75 +#define AM62X 0xbb7e #define JTAG_ID_VARIANT_SHIFT 28 #define JTAG_ID_VARIANT_MASK (0xf << 28) @@ -49,6 +50,9 @@ static const char *get_family_string(u32 idreg) case J721S2: family = "J721S2"; break; + case AM62X: + family = "AM62X"; + break; default: family = "Unknown Silicon"; }; -- 2.36.1
[PATCH v2 02/12] dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM62
From: Suman Anna Add pinctrl macros for AM62x SoCs. These macro definitions are similar to that of previous platforms, but adding new definitions to avoid any naming confusions in the SoC dts files. checkpatch insists the following error exists: ERROR: Macros with complex values should be enclosed in parentheses However, we do not need parentheses enclosing the values for this macro as we do intend it to generate two separate values as has been done for other similar platforms. Signed-off-by: Suman Anna Signed-off-by: Vignesh Raghavendra --- include/dt-bindings/pinctrl/k3.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/dt-bindings/pinctrl/k3.h b/include/dt-bindings/pinctrl/k3.h index 63e038e36c..a5204ab91d 100644 --- a/include/dt-bindings/pinctrl/k3.h +++ b/include/dt-bindings/pinctrl/k3.h @@ -41,4 +41,7 @@ #define J721S2_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) #define J721S2_WKUP_IOPAD(pa, val, muxmode)(((pa) & 0x1fff)) ((val) | (muxmode)) +#define AM62X_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) +#define AM62X_MCU_IOPAD(pa, val, muxmode) (((pa) & 0x1fff)) ((val) | (muxmode)) + #endif -- 2.36.1
[PATCH v2 00/12] TI: Add support for AM62 SoC
This adds basic support for TI's new AM62 family of SoCs and AM625 Starter Kit EVM with SD boot and UART boot. Board support, dts and configs are intentionally kept small to serve as example for future board bringups based on this SoC. Additional peripheral support will be posted separately All bindings and DT patches are in linux-next I have dropped review tags from previous version due to quite a few changes as mentioned below v2: * Patch 9,10,11 are trimmed down to bare minimum * Introduce patch to setup DMA static data for R5 SPL TISCI (patch 7) * Sync with kernel dts. * Drop unnecessary header inclusions () v1: lore.kernel.org/r/20220415140931.490047-1-vigne...@ti.com Aswath Govindraju (1): drivers: mmc: am654_sdhci: Add new compatible for AM62 SoC Nishanth Menon (1): arm: dts: Add support for AM62-SK Suman Anna (6): dt-bindings: pinctrl: k3: Introduce pinmux definitions for AM62 soc: ti: k3-socinfo: Add entry for AM62X SoC family arm: mach-k3: Introduce the basic files to support AM62 arm: mach-k3: am62: Introduce autogenerated SoC data arm: dts: Introduce base AM62 SoC dtsi files board: ti: Introduce the basic files to support AM62 SK board Vignesh Raghavendra (4): dma: ti: Add PSIL data for AM62x DMASS firmware: ti_sci_static_data: add static DMA chan data configs: Add configs for AM62x SK doc: ti: Add readme for AM62x SK arch/arm/dts/Makefile |3 + arch/arm/dts/k3-am62-ddr.dtsi | 11 + arch/arm/dts/k3-am62-main.dtsi| 533 arch/arm/dts/k3-am62-mcu.dtsi | 56 + arch/arm/dts/k3-am62-wakeup.dtsi | 41 + arch/arm/dts/k3-am62.dtsi | 105 + arch/arm/dts/k3-am625-r5-sk.dts | 140 ++ arch/arm/dts/k3-am625-sk-u-boot.dtsi | 100 + arch/arm/dts/k3-am625-sk.dts | 150 ++ arch/arm/dts/k3-am625.dtsi| 103 + arch/arm/dts/k3-am62x-sk-ddr4-1600MTs.dtsi| 2189 + arch/arm/mach-k3/Kconfig | 10 +- arch/arm/mach-k3/Makefile |1 + arch/arm/mach-k3/am625_init.c | 271 ++ arch/arm/mach-k3/am62x/Makefile |6 + arch/arm/mach-k3/am62x/clk-data.c | 366 +++ arch/arm/mach-k3/am62x/dev-data.c | 78 + arch/arm/mach-k3/arm64-mmu.c |4 +- arch/arm/mach-k3/include/mach/am62_hardware.h | 75 + arch/arm/mach-k3/include/mach/am62_spl.h | 48 + arch/arm/mach-k3/include/mach/hardware.h |4 + arch/arm/mach-k3/include/mach/spl.h |5 + board/ti/am62x/Kconfig| 59 + board/ti/am62x/MAINTAINERS|8 + board/ti/am62x/Makefile |8 + board/ti/am62x/evm.c | 39 + configs/am62x_evm_a53_defconfig | 71 + configs/am62x_evm_r5_defconfig| 91 + doc/board/ti/am62x_sk.rst | 231 ++ doc/board/ti/index.rst|1 + drivers/clk/ti/clk-k3.c |6 + drivers/dma/ti/Makefile |1 + drivers/dma/ti/k3-psil-am62.c | 50 + drivers/dma/ti/k3-psil-priv.h |1 + drivers/dma/ti/k3-psil.c |2 + drivers/firmware/ti_sci_static_data.h | 13 + drivers/mmc/am654_sdhci.c |4 + drivers/power/domain/ti-power-domain.c|6 + drivers/ram/Kconfig |1 + drivers/soc/soc_ti_k3.c |4 + include/configs/am62x_evm.h | 106 + include/dt-bindings/pinctrl/k3.h |3 + include/k3-clk.h |1 + include/k3-dev.h |1 + 44 files changed, 5003 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/k3-am62-ddr.dtsi create mode 100644 arch/arm/dts/k3-am62-main.dtsi create mode 100644 arch/arm/dts/k3-am62-mcu.dtsi create mode 100644 arch/arm/dts/k3-am62-wakeup.dtsi create mode 100644 arch/arm/dts/k3-am62.dtsi create mode 100644 arch/arm/dts/k3-am625-r5-sk.dts create mode 100644 arch/arm/dts/k3-am625-sk-u-boot.dtsi create mode 100644 arch/arm/dts/k3-am625-sk.dts create mode 100644 arch/arm/dts/k3-am625.dtsi create mode 100644 arch/arm/dts/k3-am62x-sk-ddr4-1600MTs.dtsi create mode 100644 arch/arm/mach-k3/am625_init.c create mode 100644 arch/arm/mach-k3/am62x/Makefile create mode 100644 arch/arm/mach-k3/am62x/clk-data.c create mode 100644 arch/arm/mach-k3/am62x/dev-data.c create mode 100644 arch/arm/mach-k3/include/mach/am62_hardware.h create mode 100644 arch/arm/mach-k3/include/mach/am62_spl.h create mode 100644 board/ti/am62x/Kconfig create mode 100644 board/ti/am62x/MAINTAINERS create mode 100644 board/ti/am62x/Makefile create mode 100644 board/ti/am62x/evm.c create mode 100644
[PATCH v2 01/12] drivers: mmc: am654_sdhci: Add new compatible for AM62 SoC
From: Aswath Govindraju
The phy used in the 8 bit instance has been changed to the phy used in 4
bit instance on AM62 SoC. This implies the phy configuration required for
both the instances of mmc are similar. Therefore, add a new compatible
for AM62 SoC using the driver data of am64 4 bit instance.
Signed-off-by: Aswath Govindraju
Signed-off-by: Vignesh Raghavendra
---
drivers/mmc/am654_sdhci.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mmc/am654_sdhci.c b/drivers/mmc/am654_sdhci.c
index 4305967d78..42a6134364 100644
--- a/drivers/mmc/am654_sdhci.c
+++ b/drivers/mmc/am654_sdhci.c
@@ -670,6 +670,10 @@ static const struct udevice_id am654_sdhci_ids[] = {
.compatible = "ti,am64-sdhci-4bit",
.data = (ulong)_am64_4bit_drvdata,
},
+ {
+ .compatible = "ti,am62-sdhci",
+ .data = (ulong)_am64_4bit_drvdata,
+ },
{ }
};
--
2.36.1
[PATCH v2] verdin-imx8mm, verdin-imx8mp: Fix default systemd console output
From: Philippe Schenker
systemd prints its messages on the last console= statement that it finds
in the kernel arguments. The current ordering sends the systemd messages
to tty1, by default this is the display.
Ensure that systemd sends its messages to the default UART, reorder the
console= statements accordingly.
Signed-off-by: Philippe Schenker
Reviewed-by: Stefano Babic
Acked-by: Marcel Ziswiler
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- Added Stefano's reviewed-by tag.
- Added my acked-by tag.
- Re-based on top of Stefano's master-next.
include/configs/verdin-imx8mm.h | 4 ++--
include/configs/verdin-imx8mp.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/configs/verdin-imx8mm.h b/include/configs/verdin-imx8mm.h
index cd950ad055e..558b78115df 100644
--- a/include/configs/verdin-imx8mm.h
+++ b/include/configs/verdin-imx8mm.h
@@ -58,8 +58,8 @@
"fdt_board=dev\0" \
"initrd_addr=0x4380\0" \
"initrd_high=0x\0" \
- "setup=setenv setupargs console=${console},${baudrate} " \
- "console=tty1 consoleblank=0 earlycon\0" \
+ "setup=setenv setupargs console=tty1 console=${console},${baudrate} " \
+ "consoleblank=0 earlycon\0" \
"update_uboot=askenv confirm Did you load flash.bin (y/N)?; " \
"if test \"$confirm\" = \"y\"; then " \
"setexpr blkcnt ${filesize} + 0x1ff && setexpr blkcnt " \
diff --git a/include/configs/verdin-imx8mp.h b/include/configs/verdin-imx8mp.h
index 470f64d5a74..52fa2be3ab1 100644
--- a/include/configs/verdin-imx8mp.h
+++ b/include/configs/verdin-imx8mp.h
@@ -75,7 +75,7 @@
"fdt_board=dev\0" \
"initrd_addr=0x4380\0" \
"initrd_high=0x\0" \
- "setup=setenv setupargs console=${console},${baudrate} console=tty1 " \
+ "setup=setenv setupargs console=tty1 console=${console},${baudrate} " \
"consoleblank=0 earlycon\0" \
"update_uboot=askenv confirm Did you load flash.bin (y/N)?; " \
"if test \"$confirm\" = \"y\"; then " \
--
2.35.1
[PATCH 7/7] mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure
From: Aaron Williams
This patch adds a fixup function related to a PCIe FLR (Function Level
Reset) problem on the NIC23 PCIe board. This function is imported from
the Marvell Octeon 2013 U-Boot version as a (nearly) verbatim copy. It
uses the newly introduced cyclic infrastructure, so that this function
gets called every 100us, which is needed to detect this FLR issue.
Signed-off-by: Aaron Williams
Signed-off-by: Stefan Roese
---
board/Marvell/octeon_nic23/board.c | 197 +
configs/octeon_nic23_defconfig | 3 +
2 files changed, 200 insertions(+)
diff --git a/board/Marvell/octeon_nic23/board.c
b/board/Marvell/octeon_nic23/board.c
index 3e2c5397..446fa5a659a8 100644
--- a/board/Marvell/octeon_nic23/board.c
+++ b/board/Marvell/octeon_nic23/board.c
@@ -3,8 +3,10 @@
* Copyright (C) 2021-2022 Stefan Roese
*/
+#include
#include
#include
+#include
#include
#include
@@ -15,11 +17,90 @@
#include
#include
#include
+#include
#include "board_ddr.h"
+/**
+ * cvmx_spem#_cfg_rd
+ *
+ * This register allows read access to the configuration in the PCIe core.
+ *
+ */
+union cvmx_spemx_cfg_rd {
+ u64 u64;
+ struct cvmx_spemx_cfg_rd_s {
+ u64 data : 32;
+ u64 addr : 32;
+ } s;
+ struct cvmx_spemx_cfg_rd_scn73xx;
+};
+
+/**
+ * cvmx_spem#_cfg_wr
+ *
+ * This register allows write access to the configuration in the PCIe core.
+ *
+ */
+union cvmx_spemx_cfg_wr {
+ u64 u64;
+ struct cvmx_spemx_cfg_wr_s {
+ u64 data : 32;
+ u64 addr : 32;
+ } s;
+ struct cvmx_spemx_cfg_wr_scn73xx;
+};
+
+/**
+ * cvmx_spem#_flr_pf_stopreq
+ *
+ * PF function level reset stop outbound requests register.
+ * Hardware automatically sets the STOPREQ bit for the PF when it enters a
+ * function level reset (FLR). Software is responsible for clearing the
STOPREQ
+ * bit but must not do so prior to hardware taking down the FLR, which could be
+ * as long as 100ms. It may be appropriate for software to wait longer before
clearing
+ * STOPREQ, software may need to drain deep DPI queues for example.
+ * Whenever SPEM receives a PF or child VF request mastered by CN over S2M
(i.e. P or NP),
+ * when STOPREQ is set for the function, SPEM will discard the outgoing request
+ * before sending it to the PCIe core. If a NP, SPEM will schedule an
immediate
+ * SWI_RSP_ERROR completion for the request - no timeout is required.
+ * In both cases, SPEM()_DBG_PF()_INFO[P()_BMD_E] will be set and a error
+ * interrupt is generated.
+ *
+ * STOPREQ mimics the behavior of PCIEEP()_CFG001[ME] for outbound requests
that will
+ * master the PCIe bus (P and NP).
+ *
+ * STOPREQ will have no effect on completions returned by CN over the S2M,
+ * nor on M2S traffic.
+ *
+ * When a PF()_STOPREQ is set, none of the associated
+ * PEM()_FLR_PF()_VF_STOPREQ[VF_STOPREQ] will be set.
+ *
+ * STOPREQ is reset when the MAC is reset, and is not reset after a chip soft
reset.
+ */
+union cvmx_spemx_flr_pf_stopreq {
+ u64 u64;
+ struct cvmx_spemx_flr_pf_stopreq_s {
+ u64 reserved_3_63: 61;
+ u64 pf2_stopreq : 1;
+ u64 pf1_stopreq : 1;
+ u64 pf0_stopreq : 1;
+ } s;
+ struct cvmx_spemx_flr_pf_stopreq_scn73xx;
+};
+
+#define CVMX_SPEMX_CFG_WR(offset) 0x00011800C028ull
+#define CVMX_SPEMX_CFG_RD(offset) 0x00011800C030ull
+#define CVMX_SPEMX_FLR_PF_STOPREQ(offset) 0x00011800C218ull
+
+#define DTX_SELECT_LTSSM 0x0
+#define DTX_SELECT_LTSSM_ENA 0x3ff
+#define LTSSM_L0 0x11
+
#define NIC23_DEF_DRAM_FREQ800
+static u32 pci_cfgspace_reg0[2] = { 0, 0 };
+
static u8 octeon_nic23_cfg0_spd_values[512] = {
OCTEON_NIC23_CFG0_SPD_VALUES
};
@@ -145,8 +226,118 @@ void board_configure_qlms(void)
cvmx_qlm_measure_clock(4), cvmx_qlm_measure_clock(5));
}
+/**
+ * If there is a PF FLR then the PCI EEPROM is not re-read. In this case
+ * we need to re-program the vendor and device ID immediately after hardware
+ * completes FLR.
+ *
+ * PCI spec requires FLR to be completed within 100ms. The user who triggered
+ * FLR expects hardware to finish FLR within 100ms, otherwise the user will
+ * end up reading DEVICE_ID incorrectly from the reset value.
+ * CN23XX exits FLR at any point between 66 and 99ms, so U-Boot has to wait
+ * 99ms to let hardware finish its part, then finish reprogramming the
+ * correct device ID before the end of 100ms.
+ *
+ * Note: this solution only works properly when there is no other activity
+ * within U-Boot for 100ms from the time FLR is triggered.
+ *
+ * This function gets called every
[PATCH 6/7] sandbox: Add cyclic demo function
This patch enables the cyclic infrastructure on sandbox and also adds
one simple example/demo functions using this cyclic functionality.
Signed-off-by: Stefan Roese
---
board/sandbox/sandbox.c | 15 +++
configs/sandbox_defconfig | 2 ++
2 files changed, 17 insertions(+)
diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c
index e054f300c4a5..3b48c9bf8cbb 100644
--- a/board/sandbox/sandbox.c
+++ b/board/sandbox/sandbox.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -16,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -105,8 +107,21 @@ int dram_init(void)
return 0;
}
+static void cyclic_demo(void *ctx)
+{
+ /* Just a small dummy delay here */
+ udelay(10);
+}
+
int board_init(void)
{
+ struct cyclic_struct *cyclic;
+
+ /* Register demo cyclic function */
+ cyclic = cyclic_register(cyclic_demo, 10 * 1000, "cyclic_demo", NULL);
+ if (!cyclic)
+ printf("Registering of cyclic_demo failed\n");
+
return 0;
}
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index c509a924e6b3..601c5dfe5a51 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -32,6 +32,7 @@ CONFIG_CONSOLE_RECORD_OUT_SIZE=0x6000
CONFIG_PRE_CONSOLE_BUFFER=y
CONFIG_LOG=y
CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_CYCLIC=y
CONFIG_STACKPROTECTOR=y
CONFIG_ANDROID_AB=y
CONFIG_CMD_CPU=y
@@ -111,6 +112,7 @@ CONFIG_CMD_EROFS=y
CONFIG_CMD_EXT4_WRITE=y
CONFIG_CMD_SQUASHFS=y
CONFIG_CMD_MTDPARTS=y
+CONFIG_CMD_CYCLIC=y
CONFIG_CMD_STACKPROTECTOR_TEST=y
CONFIG_MAC_PARTITION=y
CONFIG_AMIGA_PARTITION=y
--
2.36.1
[PATCH 5/7] cyclic: Add 'cyclic list' command
This patch adds the cyclic command, which currently only supports the
'list' subcommand, to list all currently registered cyclic functions.
Here an example:
=> cyclic list
function: cyclic_demo, cpu-time: 7010 us, frequency: 99.80 times/s
function: cyclic_demo2, cpu-time: 1 us, frequency: 1.13 times/s
As you can see, the cpu-time is accounted, so that cyclic functions
that take too long might be discovered. Additionally the frequency is
logged.
Signed-off-by: Stefan Roese
---
MAINTAINERS | 1 +
cmd/Kconfig | 6 ++
cmd/Makefile | 1 +
cmd/cyclic.c | 40
4 files changed, 48 insertions(+)
create mode 100644 cmd/cyclic.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 920f515dd555..e0f5bf83a953 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -755,6 +755,7 @@ F: doc/arch/m68k.rst
CYCLIC
M: Stefan Roese
S: Maintained
+F: cmd/cyclic.c
F: common/cyclic.c
F: include/cyclic.h
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 69c1814d24af..cb9bd0d6692a 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -2456,6 +2456,12 @@ config CMD_CBSYSINFO
memory by coreboot before jumping to U-Boot. It can be useful for
debugging the beaaviour of coreboot or U-Boot.
+config CMD_CYCLIC
+ bool "cyclic - Show information about cyclic functions"
+ help
+ This enables the 'cyclic' command which provides information about
+ cyclic excution functions.
+
config CMD_DIAG
bool "diag - Board diagnostics"
help
diff --git a/cmd/Makefile b/cmd/Makefile
index 5e43a1e022e8..c5a4fc5a5cfc 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_CMD_DIAG) += diag.o
endif
obj-$(CONFIG_CMD_ADTIMG) += adtimg.o
obj-$(CONFIG_CMD_ABOOTIMG) += abootimg.o
+obj-$(CONFIG_CMD_CYCLIC) += cyclic.o
obj-$(CONFIG_CMD_EVENT) += event.o
obj-$(CONFIG_CMD_EXTENSION) += extension_board.o
obj-$(CONFIG_CMD_ECHO) += echo.o
diff --git a/cmd/cyclic.c b/cmd/cyclic.c
new file mode 100644
index ..1714db18e480
--- /dev/null
+++ b/cmd/cyclic.c
@@ -0,0 +1,40 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * A general-purpose cyclic execution infrastructure, to allow "small"
+ * (run-time wise) functions to be executed at a specified frequency.
+ * Things like LED blinking or watchdog triggering are examples for such
+ * tasks.
+ *
+ * Copyright (C) 2022 Stefan Roese
+ */
+
+#include
+#include
+#include
+
+extern struct list_head cyclic_list;
+
+static int do_cyclic_list(struct cmd_tbl *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ struct cyclic_struct *cyclic, *tmp;
+ uint64_t cnt, freq;
+
+ list_for_each_entry_safe(cyclic, tmp, _list, list) {
+ cnt = cyclic->run_cnt * 100ULL * 100ULL;
+ freq = cnt / (timer_get_us() - cyclic->start_time_us);
+ printf("function: %s, cpu-time: %lld us, frequency: %lld.%02lld
times/s\n",
+ cyclic->name, cyclic->cpu_time_us,
+ freq / 100, freq % 100);
+ }
+
+ return 0;
+}
+
+#ifdef CONFIG_SYS_LONGHELP
+static char cyclic_help_text[] =
+ "cyclic list - list cyclic functions";
+#endif
+
+U_BOOT_CMD_WITH_SUBCMDS(cyclic, "Cyclic", cyclic_help_text,
+ U_BOOT_SUBCMD_MKENT(list, 1, 1, do_cyclic_list));
--
2.36.1
[PATCH 3/7] cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET
This patch integrates the main function responsible for calling all
registered cyclic functions cyclic_run() into the common WATCHDOG_RESET
macro. This guarantees that cyclic_run() is executed very often, which
is necessary for the cyclic functions to get scheduled and executed at
their configured periods.
If CONFIG_WATCHDOG is not enabled, only cyclic_run() without calling
watchdog_reset(). This guarantees that the cyclic functionality does not
rely on CONFIG_WATCHDOG being enabled.
Signed-off-by: Stefan Roese
---
fs/cramfs/uncompress.c | 2 +-
include/watchdog.h | 23 ---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/fs/cramfs/uncompress.c b/fs/cramfs/uncompress.c
index f431cc46c1f7..38e10e2e4422 100644
--- a/fs/cramfs/uncompress.c
+++ b/fs/cramfs/uncompress.c
@@ -62,7 +62,7 @@ int cramfs_uncompress_init (void)
stream.avail_in = 0;
#if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG)
- stream.outcb = (cb_func) WATCHDOG_RESET;
+ stream.outcb = (cb_func)watchdog_reset_func;
#else
stream.outcb = Z_NULL;
#endif /* CONFIG_HW_WATCHDOG */
diff --git a/include/watchdog.h b/include/watchdog.h
index 14fa5fda259e..c252cabffc2c 100644
--- a/include/watchdog.h
+++ b/include/watchdog.h
@@ -11,6 +11,8 @@
#define _WATCHDOG_H_
#if !defined(__ASSEMBLY__)
+#include
+
/*
* Reset the watchdog timer, always returns 0
*
@@ -54,11 +56,16 @@ int init_func_watchdog_reset(void);
/* Don't require the watchdog to be enabled in SPL */
#if defined(CONFIG_SPL_BUILD) &&\
!defined(CONFIG_SPL_WATCHDOG)
- #define WATCHDOG_RESET() {}
+ #define WATCHDOG_RESET() { \
+ cyclic_run(); \
+ }
#else
extern void watchdog_reset(void);
- #define WATCHDOG_RESET watchdog_reset
+ #define WATCHDOG_RESET() { \
+ watchdog_reset(); \
+ cyclic_run(); \
+ }
#endif
#endif
#else
@@ -68,11 +75,21 @@ int init_func_watchdog_reset(void);
#if defined(__ASSEMBLY__)
#define WATCHDOG_RESET /*XXX DO_NOT_DEL_THIS_COMMENT*/
#else
- #define WATCHDOG_RESET() {}
+ #define WATCHDOG_RESET() { \
+ cyclic_run(); \
+ }
#endif /* __ASSEMBLY__ */
#endif /* CONFIG_WATCHDOG && !__ASSEMBLY__ */
#endif /* CONFIG_HW_WATCHDOG */
+#if !defined(__ASSEMBLY__)
+/* Currently only needed for fs/cramfs/uncompress.c */
+static inline void watchdog_reset_func(void)
+{
+ WATCHDOG_RESET();
+}
+#endif
+
/*
* Prototypes from $(CPU)/cpu.c.
*/
--
2.36.1
[PATCH 2/7] cyclic: Add basic support for cyclic function execution infrastruture
Add the basic infrastructure to periodically execute code, e.g. all
100ms. Examples for such functions might be LED blinking etc. The
functions that are hooked into this cyclic list should be small timewise
as otherwise the execution of the other code that relies on a high
frequent polling (e.g. UART rx char ready check) might be delayed too
much. This patch also adds the Kconfig option
CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time
for such a cyclic function. If it's execution time exceeds this time,
this cyclic function will get removed from the cyclic list.
How is this cyclic functionality executed?
The following patch integrates the main function responsible for
calling all registered cyclic functions cyclic_run() into the
common WATCHDOG_RESET macro. This guarantees that cyclic_run() is
executed very often, which is necessary for the cyclic functions to
get scheduled and executed at their configured periods.
This cyclic infrastructure will be used by a board specific function on
the NIC23 MIPS Octeon board, which needs to check periodically, if a
PCIe FLR has occurred.
Signed-off-by: Stefan Roese
---
MAINTAINERS | 6 +++
common/Kconfig | 22 ++
common/Makefile | 1 +
common/cyclic.c | 112 +++
include/cyclic.h | 84 +++
5 files changed, 225 insertions(+)
create mode 100644 common/cyclic.c
create mode 100644 include/cyclic.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 56be0bfad00c..920f515dd555 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -752,6 +752,12 @@ T: git
https://source.denx.de/u-boot/custodians/u-boot-coldfire.git
F: arch/m68k/
F: doc/arch/m68k.rst
+CYCLIC
+M: Stefan Roese
+S: Maintained
+F: common/cyclic.c
+F: include/cyclic.h
+
DFU
M: Lukasz Majewski
S: Maintained
diff --git a/common/Kconfig b/common/Kconfig
index a96842a5c11d..1b04904fd688 100644
--- a/common/Kconfig
+++ b/common/Kconfig
@@ -551,6 +551,28 @@ config DISPLAY_BOARDINFO_LATE
menu "Start-up hooks"
+config CYCLIC
+ bool "General-purpose cyclic execution mechanism"
+ help
+ This enables a general-purpose cyclic execution infrastructure,
+ to allow "small" (run-time wise) functions to be executed at
+ a specified frequency. Things like LED blinking or watchdog
+ triggering are examples for such tasks.
+
+ See doc/develop/cyclic.rst for more information.
+
+if CYCLIC
+
+config CYCLIC_MAX_CPU_TIME_US
+ int "Sets the max allowed time for a cyclic function in us"
+ default 1000
+ help
+ The max allowed time for a cyclic function in us. If a functions
+ takes longer than this duration this function will get unregistered
+ automatically.
+
+endif # CYCLIC
+
config EVENT
bool "General-purpose event-handling mechanism"
default y if SANDBOX
diff --git a/common/Makefile b/common/Makefile
index 75c24e324927..a5f00ec371c1 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -89,6 +89,7 @@ obj-y += malloc_simple.o
endif
endif
+obj-$(CONFIG_$(SPL_TPL_)CYCLIC) += cyclic.o
obj-$(CONFIG_$(SPL_TPL_)EVENT) += event.o
obj-$(CONFIG_$(SPL_TPL_)HASH) += hash.o
diff --git a/common/cyclic.c b/common/cyclic.c
new file mode 100644
index ..6e7ebbe7b218
--- /dev/null
+++ b/common/cyclic.c
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * A general-purpose cyclic execution infrastructure, to allow "small"
+ * (run-time wise) functions to be executed at a specified frequency.
+ * Things like LED blinking or watchdog triggering are examples for such
+ * tasks.
+ *
+ * Copyright (C) 2022 Stefan Roese
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct list_head cyclic_list;
+static bool cyclic_ready;
+static bool cyclic_running;
+
+struct cyclic_struct *cyclic_register(cyclic_func_t func, uint64_t delay_us,
+ const char *name, void *ctx)
+{
+ struct cyclic_struct *cyclic;
+
+ if (!cyclic_ready) {
+ pr_debug("Cyclic IF not ready yet\n");
+ return NULL;
+ }
+
+ cyclic = calloc(1, sizeof(struct cyclic_struct));
+ if (!cyclic) {
+ pr_debug("Memory allocation error\n");
+ return NULL;
+ }
+
+ /* Store values in struct */
+ cyclic->func = func;
+ cyclic->ctx = ctx;
+ cyclic->name = strdup(name);
+ cyclic->delay_us = delay_us;
+ cyclic->start_time_us = timer_get_us();
+ list_add_tail(>list, _list);
+
+ return cyclic;
+}
+
+int cyclic_unregister(struct cyclic_struct *cyclic)
+{
+ list_del(>list);
+ free(cyclic);
+
+ return 0;
+}
+
+void cyclic_run(void)
+{
+ struct cyclic_struct *cyclic, *tmp;
+ uint64_t now, cpu_time;
+
+ /* Prevent recursion */
+ if (cyclic_running)
+ return;
+
+
[PATCH 4/7] cyclic: Integrate cyclic functionality at bootup in board_r/f
This patch adds a call to cyclic_init() to board_f/r.c, enabling the
common cyclic infrastructure. After this it's possible to add cyclic
functions via cyclic_register().
Signed-off-by: Stefan Roese
---
common/board_f.c | 2 ++
common/board_r.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 51d2f3c365e9..a02f435f477f 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -829,6 +830,7 @@ static const init_fnc_t init_sequence_f[] = {
initf_malloc,
log_init,
initf_bootstage,/* uses its own timer, so does not need DM */
+ cyclic_init,
event_init,
#ifdef CONFIG_BLOBLIST
bloblist_init,
diff --git a/common/board_r.c b/common/board_r.c
index 6f4aca2077d6..f8ea2a08ea12 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -600,6 +601,7 @@ static int run_main_loop(void)
static init_fnc_t init_sequence_r[] = {
initr_trace,
initr_reloc,
+ cyclic_init,
event_init,
/* TODO: could x86/PPC have this also perhaps? */
#if defined(CONFIG_ARM) || defined(CONFIG_RISCV)
--
2.36.1
[PATCH 1/7] time: Import time_after64() and friends from Linux
When using us times it makes sense to use 64bit variables for storage. The currently implemented time_after() and friends functions only handle 32bit variables. This patch now includes the 64bit variants as well from Linux. This will be used by the upcoming generic cyclic function infrastructure. These macros were copied from include/linux/jiffies.h of Linux 5.18. Signed-off-by: Stefan Roese --- include/time.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/time.h b/include/time.h index 9deb2cf61cc4..3b2ba0912470 100644 --- a/include/time.h +++ b/include/time.h @@ -83,6 +83,25 @@ uint64_t usec_to_tick(unsigned long usec); (time_after_eq(a,b) && \ time_before(a,c)) +/* Same as above, but does so with platform independent 64bit types. + * These must be used when utilizing jiffies_64 (i.e. return value of + * get_jiffies_64() */ +#define time_after64(a,b) \ + (typecheck(__u64, a) && \ +typecheck(__u64, b) && \ +((__s64)((b) - (a)) < 0)) +#define time_before64(a,b) time_after64(b,a) + +#define time_after_eq64(a,b) \ + (typecheck(__u64, a) && \ +typecheck(__u64, b) && \ +((__s64)((a) - (b)) >= 0)) +#define time_before_eq64(a,b) time_after_eq64(b,a) + +#define time_in_range64(a, b, c) \ + (time_after_eq64(a, b) && \ +time_before_eq64(a, c)) + /** * usec2ticks() - Convert microseconds to internal ticks * -- 2.36.1
[PATCH 0/7] Add support for cyclic function execution infrastruture
This patchset adds the basic infrastructure to periodically execute code, e.g. all 100ms. Examples for such functions might be LED blinking etc. The functions that are hooked into this cyclic list should be small timewise as otherwise the execution of the other code that relies on a high frequent polling (e.g. UART rx char ready check) might be delayed too much. This patch also adds the Kconfig option CONFIG_CYCLIC_MAX_CPU_TIME_US, which configures the max allowed time for such a cyclic function. If it's execution time exceeds this time, this cyclic function will get removed from the cyclic list. How is this cyclic functionality executed? This patchset integrates the main function responsible for calling all registered cyclic functions cyclic_run() into the common WATCHDOG_RESET macro. This guarantees that cyclic_run() is executed very often, which is necessary for the cyclic functions to get scheduled and executed at their configured periods. This cyclic infrastructure will be used by a board specific function on the NIC23 MIPS Octeon board, which needs to check periodically, if a PCIe FLR has occurred. Ideas how to continue: One idea is to rename WATCHDOG_RESET to something like SCHEDULE and move the watchdog_reset call into this cyclic infrastructure as well. Or to perhaps move the shell UART RX ready polling to a cyclic function. It's also possible to extend the "cyclic" command, to support the creation of periodically executed shell commands (for testing etc). Thanks, Stefan Aaron Williams (1): mips: octeon_nic23: Add PCIe FLR fixup via cyclic infrastructure Stefan Roese (6): time: Import time_after64() and friends from Linux cyclic: Add basic support for cyclic function execution infrastruture cyclic: Integrate cyclic infrastructure into WATCHDOG_RESET cyclic: Integrate cyclic functionality at bootup in board_r/f cyclic: Add 'cyclic list' command sandbox: Add cyclic demo function MAINTAINERS| 7 + board/Marvell/octeon_nic23/board.c | 197 + board/sandbox/sandbox.c| 15 +++ cmd/Kconfig| 6 + cmd/Makefile | 1 + cmd/cyclic.c | 40 ++ common/Kconfig | 22 common/Makefile| 1 + common/board_f.c | 2 + common/board_r.c | 2 + common/cyclic.c| 112 configs/octeon_nic23_defconfig | 3 + configs/sandbox_defconfig | 2 + fs/cramfs/uncompress.c | 2 +- include/cyclic.h | 84 include/time.h | 19 +++ include/watchdog.h | 23 +++- 17 files changed, 534 insertions(+), 4 deletions(-) create mode 100644 cmd/cyclic.c create mode 100644 common/cyclic.c create mode 100644 include/cyclic.h -- 2.36.1
Re: [PATCH] bootmenu: fix bootmenu title handling
Hi Pali,
On Wed, 25 May 2022 at 04:36, Pali Rohar wrote:
>
> On Tuesday 24 May 2022 09:43:56 Pali Rohár wrote:
> > On Tuesday 24 May 2022 12:45:30 Masahisa Kojima wrote:
> > > The commit a3d0aa87acbe ("bootmenu: update bootmenu_entry structure")
> > > changes the bootmenu title type from char to u16(UTF16 string)
> > > to support EFI based system. If EFI_LOADER is not enabled,
> > > printf("%ls") is not supported, so bootmenu does not appear
> > > correctly.
> > >
> > > This commit switches the menu title type from "char" to "u16"
> > > only when the EFI_LOADER is enabled.
> > >
> > > Fixes: a3d0aa87acbe ("bootmenu: update bootmenu_entry structure")
> > > Signed-off-by: Masahisa Kojima
> > > ---
> > > cmd/bootmenu.c | 48
> > > 1 file changed, 32 insertions(+), 16 deletions(-)
> > >
> > > diff --git a/cmd/bootmenu.c b/cmd/bootmenu.c
> > > index 8859eebea5..e422e0b348 100644
> > > --- a/cmd/bootmenu.c
> > > +++ b/cmd/bootmenu.c
> > > @@ -20,6 +20,20 @@
> > > /* maximum bootmenu entries */
> > > #define MAX_COUNT 99
> > >
> > > +#if (CONFIG_IS_ENABLED(EFI_LOADER))
> > > +#define TITLE_CHAR u16
> > > +#define titlefmt "ls"
> > > +#define TITLE_STRDUP u16_strdup
> > > +#define TITLE_STRNCPY(d, s, l) utf8_utf16_strncpy(, s, l)
> > > +#define TITLE_STR(x) u##x
> > > +#else
> > > +#define TITLE_CHAR char
> > > +#define titlefmt "s"
> > > +#define TITLE_STRDUP strdup
> > > +#define TITLE_STRNCPY(d, s, l) strncpy(d, s, l)
> > > +#define TITLE_STR(x) x
> > > +#endif
> >
> > This reminds me win98 days with tchar macros when NT systems used UCS-2
> > and DOS systems OEM codepage... Do we really have to use these 20 years
> > old patterns in new code?
Please ignore this patch. I will resend the patch using utf-8
for the menu title.
> >
> > Still, I do not see reason why EFI bloatware code has to be in common
> > U-boot code and not in separated parts?
>
> Anyway, now I have tested this patch, menu entries are now printed on
> serial console correctly, but still I'm not able to terminate bootmenu
> by CTRL+C like before that commit. So bootmenu is still broken on nokia
> n900.
I added a new Kconfig option "CMD_BOOTMENU_ENTER_UBOOT_CONSOLE" to disable
to enter U-Boot console from bootmenu, and U-Boot console is
disabled as default.
As Mark also mentioned before[*1], the default behavior is not
expected by the bootmenu user. I will also fix this issue.
[*1] https://lore.kernel.org/u-boot/d3cd306544dac...@bloch.sibelius.xs4all.nl/
Thanks,
Masahisa Kojima
>
> > > +
> > > /* maximal size of bootmenu env
> > > * 9 = strlen("bootmenu_")
> > > * 2 = strlen(MAX_COUNT)
> > > @@ -43,7 +57,7 @@ enum boot_type {
> > > struct bootmenu_entry {
> > > unsigned short int num; /* unique number 0 .. MAX_COUNT */
> > > char key[3];/* key identifier of number */
> > > - u16 *title; /* title of entry */
> > > + TITLE_CHAR *title; /* title of entry */
> > > char *command; /* hush command of entry */
> > > enum boot_type type;/* boot type of entry */
> > > u16 bootorder; /* order for each boot type */
> > > @@ -76,7 +90,7 @@ static void bootmenu_print_entry(void *data)
> > > if (reverse)
> > > puts(ANSI_COLOR_REVERSE);
> > >
> > > - printf("%ls", entry->title);
> > > + printf("%" titlefmt "", entry->title);
> > >
> > > if (reverse)
> > > puts(ANSI_COLOR_RESET);
> > > @@ -170,7 +184,7 @@ static int prepare_bootmenu_entry(struct
> > > bootmenu_data *menu,
> > > struct bootmenu_entry *iter = *current;
> > >
> > > while ((option = bootmenu_getoption(i))) {
> > > - u16 *buf;
> > > + TITLE_CHAR *buf;
> > >
> > > sep = strchr(option, '=');
> > > if (!sep) {
> > > @@ -183,13 +197,13 @@ static int prepare_bootmenu_entry(struct
> > > bootmenu_data *menu,
> > > return -ENOMEM;
> > >
> > > len = sep-option;
> > > - buf = calloc(1, (len + 1) * sizeof(u16));
> > > + buf = calloc(1, (len + 1) * sizeof(TITLE_CHAR));
> > > entry->title = buf;
> > > if (!entry->title) {
> > > free(entry);
> > > return -ENOMEM;
> > > }
> > > - utf8_utf16_strncpy(, option, len);
> > > + TITLE_STRNCPY(buf, option, len);
> > >
> > > len = strlen(sep + 1);
> > > entry->command = malloc(len + 1);
> > > @@ -227,6 +241,7 @@ static int prepare_bootmenu_entry(struct
> > > bootmenu_data *menu,
> > > return 1;
> > > }
> > >
> > > +#if (CONFIG_IS_ENABLED(CMD_BOOTEFI_BOOTMGR))
> > > /**
> > > * prepare_uefi_bootorder_entry() - generate the uefi bootmenu entries
> > > *
> > > @@ -315,6 +330,7 @@ static int prepare_uefi_bootorder_entry(struct
> > > bootmenu_data *menu,
> > >
> > > return 1;
> > > }
> > > +#endif
>
