[PULL] u-boot-riscv/master
Hi Tom, The following changes since commit 7755b2200777f72dca87dd169138e95f011bbcb9: Merge tag 'x86-pull-20230801' of https://source.denx.de/u-boot/custodians/u-boot-x86 (2023-08-01 11:57:55 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-riscv.git for you to fetch changes up to 093bd0354e5b947b0bd634bf5ed4041ba075b57d: acpi: Add missing RISC-V acpi_table header (2023-08-02 11:02:33 +0800) CI result shows no issue: https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/17177 + Fix compilation error for CI when enabling RTL8169 driver + Fix compilation error for pci_mmc.c by adding acpi_table header file + Support StarFive JH7110 PCIe driver + Enable PCI on Unmatched board Heinrich Schuchardt (2): riscv: sifive: initialize PCI on Unmatched acpi: Add missing RISC-V acpi_table header Mason Huo (3): starfive: pci: Add StarFive JH7110 pcie driver configs: starfive-jh7110: Add support for PCIe host driver riscv: dts: starfive: Enable PCIe host controller Minda Chen (5): i2c: designware: Add Kconfig for designware_i2c_pci.c net: rtl8169: Fix compile warning in rtl8169 net: rtl8169: Fix DMA minimal aligned compile warning in RISC-V net: rtl8169: Add one device ID 0x8161 configs: starfive-jh7110: Add CONFIG_RTL8169 arch/riscv/dts/jh7110-starfive-visionfive-2.dtsi | 11 +++ arch/riscv/dts/jh7110.dtsi | 74 + arch/riscv/include/asm/acpi_table.h | 11 +++ configs/sifive_unmatched_defconfig | 1 + configs/starfive_visionfive2_defconfig | 8 + drivers/i2c/Kconfig | 9 + drivers/i2c/Makefile | 4 +-- drivers/net/rtl8169.c| 22 - drivers/pci/Kconfig | 13 drivers/pci/Makefile | 2 ++ drivers/pci/pcie_plda_common.c | 116 drivers/pci/pcie_plda_common.h | 118 + drivers/pci/pcie_starfive_jh7110.c | 317 +++ 13 files changed, 694 insertions(+), 12 deletions(-) create mode 100644 arch/riscv/include/asm/acpi_table.h create mode 100644 drivers/pci/pcie_plda_common.c create mode 100644 drivers/pci/pcie_plda_common.h create mode 100644 drivers/pci/pcie_starfive_jh7110.c Best regards, Leo
Re: [PATCH 0/6] rockchip: rk3568: Fix use of PCIe bifurcation
It appears that you had a transmission problem with this patch as I am missing 1/6, 4/6, and 6/6. I am pretty sure these are from your repo here: https://github.com/Kwiboo/u-boot-rockchip/tree/rk35xx-pcie-bifurcation-v1 (1/6) pci: pcie_dw_rockchip: Configure number of lanes and link width speed https://github.com/Kwiboo/u-boot-rockchip/commit/2b3f591aec3abe69adc9bbc723d98550ecce3614 (2/6) phy: rockchip: snps-pcie3: Refactor to use clk_bulk API https://github.com/Kwiboo/u-boot-rockchip/commit/e6c561d1e00b92e1d4c98f9ce581385d601dbc4c (3/6) phy: rockchip: snps-pcie3: Refactor to use a phy_init ops https://github.com/Kwiboo/u-boot-rockchip/commit/627648f509f149ac9b0ade84c2a863e62b15d0a7 (4/6) phy: rockchip: snps-pcie3: Add bifurcation support for RK3568 https://github.com/Kwiboo/u-boot-rockchip/commit/a8d3342b986df42191793e2d0f72df2f41e8adff (5/6) phy: rockchip: snps-pcie3: Add support for RK3588 https://github.com/Kwiboo/u-boot-rockchip/commit/031df04ac14b3ddaba7f3be07f9a78898b73d0a5 (6/6) rockchip: rk3568-radxa-e25: Enable pcie3x1 node https://github.com/Kwiboo/u-boot-rockchip/commit/4439243b10731067baf64ea6bff84ac0519fe6d7 These work for me and detect a Nanopi R5S NVMe. Can you resend this patchset so I can definitively confirm? It would be great if this can be fixed in 2023.10. Thanks, John Clark On 8/1/23 5:25 PM, Jonas Karlman wrote: This series add support for use of PCIe bifurcation on RK3568, and as a bonus support for the RK3588 PHY is also included. With PCIe bifurcation supported it is possible to enable PCIe on more RK3568 boards, e.g. on NanoPi R5C and NanoPi R5S. This series only include fixing the mini PCIe slot on Radxa E25. Most parts of this series was imported almost 1:1 from mainline linux. Patch 1 fixes configuration of number of lanes in pcie_dw_rockchip. Patch 2-3 refactor the snps-pcie3 phy driver. Patch 4 add bifurcation support for RK3568. Patch 5 add support for RK3588. Patch 6 enables the mini PCIe slot on Radxa E25. The RK3588 PHY part was tested on a ROCK 5B together with device tree files picked from Sebastian Reichel's rk3588 branch at [1]. Patches in this series is also aviliable at [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/tree/?h=rk3588 [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-pcie-bifurcation-v1 Jonas Karlman (6): pci: pcie_dw_rockchip: Configure number of lanes and link width speed phy: rockchip: snps-pcie3: Refactor to use clk_bulk API phy: rockchip: snps-pcie3: Refactor to use a phy_init ops phy: rockchip: snps-pcie3: Add bifurcation support for RK3568 phy: rockchip: snps-pcie3: Add support for RK3588 rockchip: rk3568-radxa-e25: Enable pcie3x1 node arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 11 +- configs/radxa-e25-rk3568_defconfig| 1 - drivers/pci/pcie_dw_rockchip.c| 58 - .../phy/rockchip/phy-rockchip-snps-pcie3.c| 230 ++ 4 files changed, 235 insertions(+), 65 deletions(-)
Re: [PATCH 3/3] malloc: Enable SYS_MALLOC_RUNTIME_INIT by default in SPL
On 8/1/23 11:25, Tom Rini wrote:
> On Mon, Jul 31, 2023 at 06:33:27PM -0400, Sean Anderson wrote:
>
>> On boards with size restrictions, 1-2k can be a significant fraction of
>> the binary size. Add a new SPL version of SYS_MALLOC_RUNTIME_INIT and
>> enable it by default.
>>
>> Signed-off-by: Sean Anderson
>> ---
>>
>> Kconfig | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/Kconfig b/Kconfig
>> index 4b32286b69..3cb31a9346 100644
>> --- a/Kconfig
>> +++ b/Kconfig
>> @@ -381,6 +381,17 @@ config SYS_MALLOC_RUNTIME_INIT
>> reduce the size of U-Boot by letting malloc's data reside in .bss
>> instead of .data.
>>
>> +config SPL_SYS_MALLOC_RUNTIME_INIT
>> +bool "Initialize malloc's internal data at runtime in SPL"
>> +default y
>> +depends on SPL
>> +help
>> + Initialize malloc's internal data structures at SPL runtime, rather
>> + than at compile-time. This is necessary if relocating the malloc arena
>> + from a smaller static memory to a large DDR memory. It can also reduce
>> + the size of U-Boot by letting malloc's data reside in .bss instead of
>> + .data.
>> +
>> config TOOLS_DEBUG
>> bool "Enable debug information for tools"
>> help
>
> Can you use something like grabserial (or other tooling) to quantify the
> change on a platform or two?
I had a ZynqMP board roughly based on xilinx_zynqmp_virt_defconfig lying
around. On this board, serial is not initialized until after malloc, so
I used the internal timer and printed the times later. DEBUG_UART would
probably be better but I didn't get it working.
diff --git a/common/board_r.c b/common/board_r.c
index d798c00a80a..d7aee85e5b1 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -194,6 +194,7 @@ static int initr_barrier(void)
return 0;
}
+static ulong malloc_begin, malloc_end;
static int initr_malloc(void)
{
ulong malloc_start;
@@ -208,8 +209,10 @@ static int initr_malloc(void)
* reserve_noncached().
*/
malloc_start = gd->relocaddr - TOTAL_MALLOC_LEN;
+ malloc_begin = timer_get_boot_us();
mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
TOTAL_MALLOC_LEN);
+ malloc_end = timer_get_boot_us();
return 0;
}
@@ -569,6 +572,7 @@ static int dm_announce(void)
static int run_main_loop(void)
{
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
malloc_begin, malloc_end);
#ifdef CONFIG_SANDBOX
sandbox_main_loop_init();
#endif
diff --git a/common/spl/spl.c b/common/spl/spl.c
index d74acec10b5..09abcc74442 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -755,7 +755,9 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_set_bd();
#if defined(CONFIG_SYS_SPL_MALLOC)
+ ulong malloc_begin = timer_get_boot_us();
mem_malloc_init(SYS_SPL_MALLOC_START, CONFIG_SYS_SPL_MALLOC_SIZE);
+ ulong malloc_end = timer_get_boot_us();
gd->flags |= GD_FLG_FULL_MALLOC_INIT;
#endif
if (!(gd->flags & GD_FLG_SPL_INIT)) {
@@ -817,6 +819,7 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
spl_image.boot_device = BOOT_DEVICE_NONE;
board_boot_order(spl_boot_list);
+ printf("malloc_init took %luus (%lu %lu)\n", malloc_end - malloc_begin,
malloc_begin, malloc_end);
ret = boot_from_devices(_image, spl_boot_list,
ARRAY_SIZE(spl_boot_list));
if (ret) {
I recorded times (in us) from five boots. The value of
(SPL_)SYS_MALLOC_RUNTIME_INIT is in parentheses:
SPL (n) U-Boot (n) SPL (y) U-Boot (y)
=== == === ==
192975 47557 135027 47557
192940 47557 135059 47557
193006 47557 134722 47558
193015 47556 135055 47557
193987 47557 134790 47557
So SPL took 60 ms shorter (?!) and U-Boot was mostly unaffected. Not
sure how that happened. The raw values for begin/end look reasonable:
malloc_init took 47557us (6778108 6825665)
malloc_init took 47557us (6779290 6826847)
malloc_init took 47558us (6780379 6827937)
etc. but to be honest I don't really see how SPL can spend 190ms setting
some variables and clearing the arena.
--Sean
[PATCH v3] gpio: Use separate bitfield array to indicate GPIO is claimed
The current gpio-uclass design uses name field in struct gpio_dev_priv as
an indicator that GPIO is claimed by consumer. This overloads the function
of name field and does not work well for named pins not configured as GPIO
pins.
Introduce separate bitfield array as the claim indicator.
This unbreaks dual-purpose AF and GPIO operation on STM32MP since commit
2c38f7c31806 ("pinctrl: pinctrl_stm32: Populate uc_priv->name[] with pinmux
node's name")
where any pin which has already been configured as AF could no longer be
claimed as dual-purpose GPIO. This is important for pins like STM32 MMCI
st,cmd-gpios .
Signed-off-by: Marek Vasut
---
Cc: Michal Suchanek
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Rasmus Villemoes
Cc: Samuel Holland
Cc: Simon Glass
---
V2: Add set/clear helpers
V3: Define GPIO_ALLOC_BITS, update calloc() invocation accordingly
---
drivers/gpio/gpio-uclass.c | 64 +++---
include/asm-generic/gpio.h | 2 ++
2 files changed, 61 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
index 712119c3415..3e33a12456b 100644
--- a/drivers/gpio/gpio-uclass.c
+++ b/drivers/gpio/gpio-uclass.c
@@ -28,6 +28,8 @@
DECLARE_GLOBAL_DATA_PTR;
+#define GPIO_ALLOC_BITS32
+
/**
* gpio_desc_init() - Initialize the GPIO descriptor
*
@@ -75,6 +77,46 @@ static int gpio_to_device(unsigned int gpio, struct
gpio_desc *desc)
return -ENOENT;
}
+/**
+ * gpio_is_claimed() - Test whether GPIO is claimed by consumer
+ *
+ * Test whether GPIO is claimed by consumer already.
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ * @return:true if claimed, false if not claimed
+ */
+static bool gpio_is_claimed(struct gpio_dev_priv *uc_priv, unsigned int offset)
+{
+ return !!(uc_priv->claimed[offset / GPIO_ALLOC_BITS] & BIT(offset %
GPIO_ALLOC_BITS));
+}
+
+/**
+ * gpio_set_claim() - Set GPIO claimed by consumer
+ *
+ * Set a bit which indicate the GPIO is claimed by consumer
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ */
+static void gpio_set_claim(struct gpio_dev_priv *uc_priv, unsigned int offset)
+{
+ uc_priv->claimed[offset / GPIO_ALLOC_BITS] |= BIT(offset %
GPIO_ALLOC_BITS);
+}
+
+/**
+ * gpio_clear_claim() - Clear GPIO claimed by consumer
+ *
+ * Clear a bit which indicate the GPIO is claimed by consumer
+ *
+ * @uc_priv: gpio_dev_priv pointer.
+ * @offset:gpio offset within the device
+ */
+static void gpio_clear_claim(struct gpio_dev_priv *uc_priv, unsigned int
offset)
+{
+ uc_priv->claimed[offset / GPIO_ALLOC_BITS] &= ~BIT(offset %
GPIO_ALLOC_BITS);
+}
+
#if CONFIG_IS_ENABLED(DM_GPIO_LOOKUP_LABEL)
/**
* dm_gpio_lookup_label() - look for name in gpio device
@@ -94,7 +136,7 @@ static int dm_gpio_lookup_label(const char *name,
*offset = -1;
for (i = 0; i < uc_priv->gpio_count; i++) {
- if (!uc_priv->name[i])
+ if (!gpio_is_claimed(uc_priv, i))
continue;
if (!strcmp(name, uc_priv->name[i])) {
*offset = i;
@@ -350,7 +392,7 @@ int dm_gpio_request(struct gpio_desc *desc, const char
*label)
int ret;
uc_priv = dev_get_uclass_priv(dev);
- if (uc_priv->name[desc->offset])
+ if (gpio_is_claimed(uc_priv, desc->offset))
return -EBUSY;
str = strdup(label);
if (!str)
@@ -362,6 +404,8 @@ int dm_gpio_request(struct gpio_desc *desc, const char
*label)
return ret;
}
}
+
+ gpio_set_claim(uc_priv, desc->offset);
uc_priv->name[desc->offset] = str;
return 0;
@@ -438,7 +482,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
int ret;
uc_priv = dev_get_uclass_priv(dev);
- if (!uc_priv->name[offset])
+ if (!gpio_is_claimed(uc_priv, offset))
return -ENXIO;
if (ops->rfree) {
ret = ops->rfree(dev, offset);
@@ -446,6 +490,7 @@ int _dm_gpio_free(struct udevice *dev, uint offset)
return ret;
}
+ gpio_clear_claim(uc_priv, offset);
free(uc_priv->name[offset]);
uc_priv->name[offset] = NULL;
@@ -480,7 +525,7 @@ static int check_reserved(const struct gpio_desc *desc,
const char *func)
return -ENOENT;
uc_priv = dev_get_uclass_priv(desc->dev);
- if (!uc_priv->name[desc->offset]) {
+ if (!gpio_is_claimed(uc_priv, desc->offset)) {
printf("%s: %s: error: gpio %s%d not reserved\n",
desc->dev->name, func,
uc_priv->bank_name ? uc_priv->bank_name : "",
@@ -826,7 +871,7 @@ static int get_function(struct udevice *dev, int offset,
bool skip_unused,
return -EINVAL;
if (namep)
*namep = uc_priv->name[offset];
- if
Re: [PATCH v3 1/4] cmd: bind: Add unbind command with driver filter
On 8/1/23 20:53, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Mon, 31 Jul 2023 16:40:04 +0200: On 7/31/23 16:25, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Mon, 31 Jul 2023 16:08:19 +0200: On 7/31/23 15:58, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Mon, 31 Jul 2023 15:50:58 +0200: On 7/31/23 15:36, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Mon, 31 Jul 2023 13:44:25 +0200: On 7/31/23 11:31, Miquel Raynal wrote: Hi Marek, ma...@denx.de wrote on Sat, 29 Jul 2023 16:57:09 +0200: Extend the driver core to perform lookup by both OF node and driver bound to the node. Use this to look up specific device instances to unbind from nodes in the unbind command. One example where this is needed is USB peripheral controller, which may have multiple gadget drivers bound to it. The unbind command has to select that specific gadget driver instance to unbind from the controller, not unbind the controller driver itself from the controller. USB ethernet gadget usage looks as follows with this change. Notice the extra 'usb_ether' addition in the 'unbind' command at the end. " bind /soc/usb-otg@4900 usb_ether setenv ethact usb_ether setenv loadaddr 0xc200 setenv ipaddr 10.0.0.2 setenv serverip 10.0.0.1 setenv netmask 255.255.255.0 tftpboot 0xc200 10.0.0.1:test.file unbind /soc/usb-otg@4900 usb_ether " Signed-off-by: Marek Vasut --- I am no longer getting wrong pointer dereferences, the SPL is working in recovery mode, TFTP "File not found" errors are no longer a problem and I did not experience any reset while tftp'ing regular files. One last remaining request on my side is the need for using fastboot as well which does no longer work as-is: >>> => fastboot usb 0 couldn't find an available UDC g_dnl_register: failed!, error: -19 exit not allowed from main input shell. Can you advise what bind/unbind command would be necessary here? Either 'unbind usb_ether' or run 'dm tree' -> look up the path to usb_ether in the tree (it will be hanging under usb_peripheral or some such), and then use 'unbind '. Nice `dm tree` command, never used it before. Even when I unbind usb_ether I still get the same error: >>> => unbind /ocp/usb@4740/usb@47401000 => fastboot usb 0 couldn't find an available UDC g_dnl_register: failed!, error: -19 exit not allowed from main input shell. Is there a specific gadget driver which I should bind again manually? Can you share the output of dm tree before/after unbind ? fastboot should auto-bind to the right thing. Ok. Apparently it does not, but I don't have any clue why. If you want me to check something else I will. Here is the output: U-Boot 2023.07-00806-g979e7443428 (Jul 31 2023 - 11:17:06 +0200) [...] watchdog 0 [ + ] omap3_wdt | |-- wdt@44e35000 misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 ethernet 1 [ + ] usb_ether | | | `-- usb_ether bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev usb 0 [ ] ti-musb-host | | `-- usb@47401800 ethernet 0 [ + ] eth_cpsw | |-- ethernet@4a10 bootdev 2 [ ] eth_bootdev | | `-- ethernet@4a10.bootdev simple_bus 67 [ ] ti_sysc | |-- target-module@5310 simple_bus 68 [ ] ti_sysc | |-- target-module@5350 simple_bus 69 [ ] ti_sysc | `-- target-module@5600 clk 62 [ ] fixed_clock |-- clk_mcasp0_fixed bootstd 0 [ ] bootstd_drv |-- bootstd bootmeth 0 [ ] bootmeth_efi | |-- efi bootmeth 1 [ ] bootmeth_extlinux | |-- extlinux bootmeth 2 [ ] bootmeth_pxe | |-- pxe bootmeth 3 [ ] vbe_simple| `-- vbe_simple timer 0 [ + ] omap_timer`-- timer@0 => unbind /ocp/usb@4740/usb@47401000 The commit message of this patch contains the following example: unbind /soc/usb-otg@4900 usb_ether so in your case, try unbind /ocp/usb@4740/usb@47401000 usb_ether Does not work, unfortunately: => unbind /ocp/usb@4740/usb@47401000 usb_ether Cannot find a device with path /ocp/usb@4740/usb@47401000 => unbind /ocp/usb@4740/usb@47401000 Did this even work before , i.e. without this series, if you were to use USB ethernet first and then fastboot second (that sequence is important) ? Yes it did. Can you debug this ? Basically the problem that happens is that if you run: unbind /ocp/usb@4740/usb@47401000 this unbind ti-musb-peripheral usb@47401000 instead of just unbinding usb_ether usb_ether True. Maybe just try unbind usb_ether => unbind usb_ether unbind - Unbind a
[PATCH 5/6] phy: rockchip: snps-pcie3: Add support for RK3588
Add support for the RK3588 variant to the driver.
Code imported almost 1:1 from mainline linux driver.
Signed-off-by: Jonas Karlman
---
.../phy/rockchip/phy-rockchip-snps-pcie3.c| 85 +++
1 file changed, 85 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
index 642819b1f672..a4392daf4c92 100644
--- a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -27,6 +27,17 @@
#define RK3568_BIFURCATION_LANE_0_1BIT(0)
+/* Register for RK3588 */
+#define PHP_GRF_PCIESEL_CON0x100
+#define RK3588_PCIE3PHY_GRF_CMN_CON0 0x0
+#define RK3588_PCIE3PHY_GRF_PHY0_STATUS1 0x904
+#define RK3588_PCIE3PHY_GRF_PHY1_STATUS1 0xa04
+#define RK3588_SRAM_INIT_DONE(reg) (reg & BIT(0))
+
+#define RK3588_BIFURCATION_LANE_0_1BIT(0)
+#define RK3588_BIFURCATION_LANE_2_3BIT(1)
+#define RK3588_LANE_AGGREGATIONBIT(2)
+
/**
* struct rockchip_p3phy_priv - RK DW PCIe PHY state
*
@@ -40,6 +51,7 @@
struct rockchip_p3phy_priv {
void __iomem *mmio;
struct regmap *phy_grf;
+ struct regmap *pipe_grf;
struct reset_ctl p30phy;
struct clk_bulk clks;
int num_lanes;
@@ -93,6 +105,66 @@ static const struct rockchip_p3phy_ops rk3568_ops = {
.phy_init = rockchip_p3phy_rk3568_init,
};
+static int rockchip_p3phy_rk3588_init(struct phy *phy)
+{
+ struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
+ u32 reg = 0;
+ u8 mode = 0;
+ int ret;
+
+ /* Deassert PCIe PMA output clamp mode */
+ regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+BIT(8) | BIT(24));
+
+ /* Set bifurcation if needed */
+ for (int i = 0; i < priv->num_lanes; i++) {
+ if (!priv->lanes[i])
+ mode |= (BIT(i) << 3);
+
+ if (priv->lanes[i] > 1)
+ mode |= (BIT(i) >> 1);
+ }
+
+ if (!mode) {
+ reg = RK3588_LANE_AGGREGATION;
+ } else {
+ if (mode & (BIT(0) | BIT(1)))
+ reg |= RK3588_BIFURCATION_LANE_0_1;
+
+ if (mode & (BIT(2) | BIT(3)))
+ reg |= RK3588_BIFURCATION_LANE_2_3;
+ }
+
+ regmap_write(priv->phy_grf, RK3588_PCIE3PHY_GRF_CMN_CON0,
+(0x7 << 16) | reg);
+
+ /* Set pcie1ln_sel in PHP_GRF_PCIESEL_CON */
+ reg = (mode & (BIT(6) | BIT(7))) >> 6;
+ if (reg)
+ regmap_write(priv->pipe_grf, PHP_GRF_PCIESEL_CON,
+(reg << 16) | reg);
+
+ reset_deassert(>p30phy);
+ udelay(1);
+
+ ret = regmap_read_poll_timeout(priv->phy_grf,
+ RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
+ reg, RK3588_SRAM_INIT_DONE(reg),
+ 0, 500);
+ ret |= regmap_read_poll_timeout(priv->phy_grf,
+ RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
+ reg, RK3588_SRAM_INIT_DONE(reg),
+ 0, 500);
+ if (ret)
+ dev_err(phy->dev, "lock failed 0x%x\n", reg);
+
+ return ret;
+}
+
+static const struct rockchip_p3phy_ops rk3588_ops = {
+ .phy_init = rockchip_p3phy_rk3588_init,
+};
+
static int rochchip_p3phy_init(struct phy *phy)
{
struct rockchip_p3phy_ops *ops =
@@ -139,6 +211,15 @@ static int rockchip_p3phy_probe(struct udevice *dev)
return PTR_ERR(priv->phy_grf);
}
+ if (device_is_compatible(dev, "rockchip,rk3588-pcie3-phy")) {
+ priv->pipe_grf =
+ syscon_regmap_lookup_by_phandle(dev,
"rockchip,pipe-grf");
+ if (IS_ERR(priv->pipe_grf)) {
+ dev_err(dev, "failed to find rockchip,pipe_grf
regmap\n");
+ return PTR_ERR(priv->pipe_grf);
+ }
+ }
+
ret = dev_read_size(dev, "data-lanes");
if (ret > 0) {
priv->num_lanes = ret / sizeof(u32);
@@ -181,6 +262,10 @@ static const struct udevice_id rockchip_p3phy_of_match[] =
{
.compatible = "rockchip,rk3568-pcie3-phy",
.data = (ulong)_ops,
},
+ {
+ .compatible = "rockchip,rk3588-pcie3-phy",
+ .data = (ulong)_ops,
+ },
{ },
};
--
2.41.0
[PATCH 0/6] rockchip: rk3568: Fix use of PCIe bifurcation
This series add support for use of PCIe bifurcation on RK3568, and as a bonus support for the RK3588 PHY is also included. With PCIe bifurcation supported it is possible to enable PCIe on more RK3568 boards, e.g. on NanoPi R5C and NanoPi R5S. This series only include fixing the mini PCIe slot on Radxa E25. Most parts of this series was imported almost 1:1 from mainline linux. Patch 1 fixes configuration of number of lanes in pcie_dw_rockchip. Patch 2-3 refactor the snps-pcie3 phy driver. Patch 4 add bifurcation support for RK3568. Patch 5 add support for RK3588. Patch 6 enables the mini PCIe slot on Radxa E25. The RK3588 PHY part was tested on a ROCK 5B together with device tree files picked from Sebastian Reichel's rk3588 branch at [1]. Patches in this series is also aviliable at [2]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/tree/?h=rk3588 [2] https://github.com/Kwiboo/u-boot-rockchip/commits/rk35xx-pcie-bifurcation-v1 Jonas Karlman (6): pci: pcie_dw_rockchip: Configure number of lanes and link width speed phy: rockchip: snps-pcie3: Refactor to use clk_bulk API phy: rockchip: snps-pcie3: Refactor to use a phy_init ops phy: rockchip: snps-pcie3: Add bifurcation support for RK3568 phy: rockchip: snps-pcie3: Add support for RK3588 rockchip: rk3568-radxa-e25: Enable pcie3x1 node arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 11 +- configs/radxa-e25-rk3568_defconfig| 1 - drivers/pci/pcie_dw_rockchip.c| 58 - .../phy/rockchip/phy-rockchip-snps-pcie3.c| 230 ++ 4 files changed, 235 insertions(+), 65 deletions(-) -- 2.41.0
[PATCH 3/6] phy: rockchip: snps-pcie3: Refactor to use a phy_init ops
Add a phy_init ops in preparation for upcoming support of a RK3588
variant in the driver.
Signed-off-by: Jonas Karlman
---
.../phy/rockchip/phy-rockchip-snps-pcie3.c| 40 +++
1 file changed, 32 insertions(+), 8 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
index 3053543a3329..b76b5386bef0 100644
--- a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -35,8 +35,32 @@ struct rockchip_p3phy_priv {
struct clk_bulk clks;
};
+struct rockchip_p3phy_ops {
+ int (*phy_init)(struct phy *phy);
+};
+
+static int rockchip_p3phy_rk3568_init(struct phy *phy)
+{
+ struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
+
+ /* Deassert PCIe PMA output clamp mode */
+ regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
+(0x1 << 15) | (0x1 << 31));
+
+ reset_deassert(>p30phy);
+ udelay(1);
+
+ return 0;
+}
+
+static const struct rockchip_p3phy_ops rk3568_ops = {
+ .phy_init = rockchip_p3phy_rk3568_init,
+};
+
static int rochchip_p3phy_init(struct phy *phy)
{
+ struct rockchip_p3phy_ops *ops =
+ (struct rockchip_p3phy_ops *)dev_get_driver_data(phy->dev);
struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
int ret;
@@ -47,14 +71,11 @@ static int rochchip_p3phy_init(struct phy *phy)
reset_assert(>p30phy);
udelay(1);
- /* Deassert PCIe PMA output clamp mode */
- regmap_write(priv->phy_grf, GRF_PCIE30PHY_CON9,
-(0x1 << 15) | (0x1 << 31));
-
- reset_deassert(>p30phy);
- udelay(1);
+ ret = ops->phy_init(phy);
+ if (ret)
+ clk_disable_bulk(>clks);
- return 0;
+ return ret;
}
static int rochchip_p3phy_exit(struct phy *phy)
@@ -103,7 +124,10 @@ static struct phy_ops rochchip_p3phy_ops = {
};
static const struct udevice_id rockchip_p3phy_of_match[] = {
- { .compatible = "rockchip,rk3568-pcie3-phy" },
+ {
+ .compatible = "rockchip,rk3568-pcie3-phy",
+ .data = (ulong)_ops,
+ },
{ },
};
--
2.41.0
[PATCH 2/6] phy: rockchip: snps-pcie3: Refactor to use clk_bulk API
Change to use clk_bulk API and syscon_regmap_lookup_by_phandle to
simplify in preparation for upcoming support of a RK3588 variant.
Signed-off-by: Jonas Karlman
---
.../phy/rockchip/phy-rockchip-snps-pcie3.c| 58 +++
1 file changed, 9 insertions(+), 49 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
index 66c75f98e6d1..3053543a3329 100644
--- a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
+++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
@@ -26,17 +26,13 @@
* @mmio: The base address of PHY internal registers
* @phy_grf: The regmap for controlling pipe signal
* @p30phy: The reset signal for PHY
- * @ref_clk_m: The reference clock of M for PHY
- * @ref_clk_n: The reference clock of N for PHY
- * @pclk: The clock for accessing PHY blocks
+ * @clks: The clocks for PHY
*/
struct rockchip_p3phy_priv {
void __iomem *mmio;
struct regmap *phy_grf;
struct reset_ctl p30phy;
- struct clk ref_clk_m;
- struct clk ref_clk_n;
- struct clk pclk;
+ struct clk_bulk clks;
};
static int rochchip_p3phy_init(struct phy *phy)
@@ -44,18 +40,10 @@ static int rochchip_p3phy_init(struct phy *phy)
struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
int ret;
- ret = clk_enable(>ref_clk_m);
- if (ret < 0 && ret != -ENOSYS)
+ ret = clk_enable_bulk(>clks);
+ if (ret)
return ret;
- ret = clk_enable(>ref_clk_n);
- if (ret < 0 && ret != -ENOSYS)
- goto err_ref;
-
- ret = clk_enable(>pclk);
- if (ret < 0 && ret != -ENOSYS)
- goto err_pclk;
-
reset_assert(>p30phy);
udelay(1);
@@ -67,21 +55,13 @@ static int rochchip_p3phy_init(struct phy *phy)
udelay(1);
return 0;
-err_pclk:
- clk_disable(>ref_clk_n);
-err_ref:
- clk_disable(>ref_clk_m);
-
- return ret;
}
static int rochchip_p3phy_exit(struct phy *phy)
{
struct rockchip_p3phy_priv *priv = dev_get_priv(phy->dev);
- clk_disable(>ref_clk_m);
- clk_disable(>ref_clk_n);
- clk_disable(>pclk);
+ clk_disable_bulk(>clks);
reset_assert(>p30phy);
return 0;
@@ -90,21 +70,13 @@ static int rochchip_p3phy_exit(struct phy *phy)
static int rockchip_p3phy_probe(struct udevice *dev)
{
struct rockchip_p3phy_priv *priv = dev_get_priv(dev);
- struct udevice *syscon;
int ret;
priv->mmio = dev_read_addr_ptr(dev);
if (!priv->mmio)
return -EINVAL;
- ret = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
- "rockchip,phy-grf", );
- if (ret) {
- pr_err("unable to find syscon device for rockchip,phy-grf\n");
- return ret;
- }
-
- priv->phy_grf = syscon_get_regmap(syscon);
+ priv->phy_grf = syscon_regmap_lookup_by_phandle(dev,
"rockchip,phy-grf");
if (IS_ERR(priv->phy_grf)) {
dev_err(dev, "failed to find rockchip,phy_grf regmap\n");
return PTR_ERR(priv->phy_grf);
@@ -116,22 +88,10 @@ static int rockchip_p3phy_probe(struct udevice *dev)
return ret;
}
- ret = clk_get_by_name(dev, "refclk_m", >ref_clk_m);
+ ret = clk_get_bulk(dev, >clks);
if (ret) {
- dev_err(dev, "failed to find ref clock M\n");
- return PTR_ERR(>ref_clk_m);
- }
-
- ret = clk_get_by_name(dev, "refclk_n", >ref_clk_n);
- if (ret) {
- dev_err(dev, "failed to find ref clock N\n");
- return PTR_ERR(>ref_clk_n);
- }
-
- ret = clk_get_by_name(dev, "pclk", >pclk);
- if (ret) {
- dev_err(dev, "failed to find pclk\n");
- return PTR_ERR(>pclk);
+ dev_err(dev, "failed to get clocks\n");
+ return ret;
}
return 0;
--
2.41.0
Re: [PATCH v3 1/4] cmd: bind: Add unbind command with driver filter
Hi Marek, ma...@denx.de wrote on Mon, 31 Jul 2023 16:40:04 +0200: > On 7/31/23 16:25, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Mon, 31 Jul 2023 16:08:19 +0200: > > > >> On 7/31/23 15:58, Miquel Raynal wrote: > >>> Hi Marek, > >>> > >>> ma...@denx.de wrote on Mon, 31 Jul 2023 15:50:58 +0200: > >>> On 7/31/23 15:36, Miquel Raynal wrote: > > Hi Marek, > > > > ma...@denx.de wrote on Mon, 31 Jul 2023 13:44:25 +0200: > > On 7/31/23 11:31, Miquel Raynal wrote: > >>> Hi Marek, > >>> > >>> ma...@denx.de wrote on Sat, 29 Jul 2023 16:57:09 +0200: > >>> Extend the driver core to perform lookup by both OF node > >>> and driver > bound to the node. Use this to look up specific device instances to > unbind from nodes in the unbind command. One example where this is > needed is USB peripheral controller, which may have multiple gadget > drivers bound to it. The unbind command has to select that specific > gadget driver instance to unbind from the controller, not unbind the > controller driver itself from the controller. > > USB ethernet gadget usage looks as follows with this change. Notice > the extra 'usb_ether' addition in the 'unbind' command at the end. > " > bind /soc/usb-otg@4900 usb_ether > setenv ethact usb_ether > setenv loadaddr 0xc200 > setenv ipaddr 10.0.0.2 > setenv serverip 10.0.0.1 > setenv netmask 255.255.255.0 > tftpboot 0xc200 10.0.0.1:test.file > unbind /soc/usb-otg@4900 usb_ether > " > > Signed-off-by: Marek Vasut > --- > >>> > >>> I am no longer getting wrong pointer dereferences, the SPL is working > >>> in > >>> recovery mode, TFTP "File not found" errors are no longer a problem > >>> and > >>> I did not experience any reset while tftp'ing regular files. > >>> > >>> One last remaining request on my side is the need for using fastboot > >>> as > >>> well which does no longer work as-is: > >>> >>> => fastboot usb 0 > >>> couldn't find an available UDC > >>> g_dnl_register: failed!, error: -19 > >>> exit not allowed from main input shell. > >>> > >>> Can you advise what bind/unbind command would be necessary here? > >> > >> Either 'unbind usb_ether' or run 'dm tree' -> look up the path to > >> usb_ether in the tree (it will be hanging under usb_peripheral or some > >> such), and then use 'unbind '. > > > > Nice `dm tree` command, never used it before. > > > > Even when I unbind usb_ether I still get the same error: > > >>> => unbind /ocp/usb@4740/usb@47401000 > > => fastboot usb 0 > > couldn't find an available UDC > > g_dnl_register: failed!, error: -19 > > exit not allowed from main input shell. > > > > Is there a specific gadget driver which I should bind again manually? > > Can you share the output of dm tree before/after unbind ? > > fastboot should auto-bind to the right thing. > >>> > >>> Ok. Apparently it does not, but I don't have any clue why. If you want > >>> me to check something else I will. Here is the output: > >>> > >>> U-Boot 2023.07-00806-g979e7443428 (Jul 31 2023 - 11:17:06 +0200) > >> > >> [...] > >> > >>>watchdog 0 [ + ] omap3_wdt | |-- wdt@44e35000 > >>>misc 0 [ + ] ti-musb-wrapper | |-- usb@4740 > >>>usb 0 [ + ] ti-musb-peripheral| | |-- usb@47401000 > >>>ethernet 1 [ + ] usb_ether | | | `-- > >>> usb_ether > >>>bootdev 3 [ ] eth_bootdev | | | `-- > >>> usb_ether.bootdev > >>>usb 0 [ ] ti-musb-host | | `-- usb@47401800 > >>>ethernet 0 [ + ] eth_cpsw | |-- > >>> ethernet@4a10 > >>>bootdev 2 [ ] eth_bootdev | | `-- > >>> ethernet@4a10.bootdev > >>>simple_bus 67 [ ] ti_sysc | |-- > >>> target-module@5310 > >>>simple_bus 68 [ ] ti_sysc | |-- > >>> target-module@5350 > >>>simple_bus 69 [ ] ti_sysc | `-- > >>> target-module@5600 > >>>clk 62 [ ] fixed_clock |-- clk_mcasp0_fixed > >>>bootstd 0 [ ] bootstd_drv |-- bootstd > >>>bootmeth 0 [ ] bootmeth_efi | |-- efi > >>>bootmeth 1 [ ] bootmeth_extlinux | |-- extlinux > >>>bootmeth 2 [ ] bootmeth_pxe | |-- pxe > >>>bootmeth 3 [ ] vbe_simple| `-- vbe_simple > >>>timer 0 [ + ] omap_timer`-- timer@0 > >>> => unbind
[PATCH] doc/sphinx/requirements.txt: Bump certifi up
Upgrade certifi to the latest version, to remove e-Tugra from the root store. Link: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/C-HrP1SEq1A?pli=1 Signed-off-by: Tom Rini --- doc/sphinx/requirements.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sphinx/requirements.txt b/doc/sphinx/requirements.txt index b74661ad3f1c..4f411f78d030 100644 --- a/doc/sphinx/requirements.txt +++ b/doc/sphinx/requirements.txt @@ -1,6 +1,6 @@ alabaster==0.7.12 Babel==2.9.1 -certifi==2023.5.7 +certifi==2023.07.22 charset-normalizer==2.0.12 docutils==0.16 idna==3.3 -- 2.34.1
Re: [PATCH 2/2] drivers: video: tidss: tidss_drv: Use kconfig VIDEO_REMOVE to remove video
On Thu, 27 Jul 2023 12:01:26 +0530 Nikhil M Jain n-ja...@ti.com wrote: > Perform removal of DSS if kconfigs VIDEO_REMOVE or SPL_VIDEO_REMOVE is > set by user. Otherwise if above Kconfigs are not selected, it is assumed > that user wants splash screen to be displayed until linux kernel boots > up. In such scenario, leave the power domain of DSS as "on" so that > splash screen stays intact until kernel boots up. > > Signed-off-by: Nikhil M Jain > --- > drivers/video/tidss/tidss_drv.c | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 1/2] drivers: video: tidss: tidss_drv: Change remove method
On Thu, 27 Jul 2023 12:01:25 +0530 Nikhil M Jain n-ja...@ti.com wrote: > Change remove method of DSS video driver to disable video port instead > of performing a soft reset, as soft reset takes longer duration. Video > port is disabled by setting enable bit of video port to 0. > > Signed-off-by: Nikhil M Jain > --- > drivers/video/tidss/tidss_drv.c | 12 +--- > 1 file changed, 1 insertion(+), 11 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
[PATCH V3] doc: board: ti: k3: Add a guide to debugging with OpenOCD
From: Jason Kacines Bootloader debug usually tends to be a bit dicey prior to DDR and serial port getting active in the system. JTAG typically remains the only practical debug option during the initial bringup. OpenOCD is one of the most popular environment for providing debug capability via a gdb compatible interface for developers to work with. Debugging U-boot and bootloaders on K3 platform does have a bit of tribal knowledge that is better documented in our common platform documentation. Signed-off-by: Jason Kacines Signed-off-by: Nishanth Menon --- Changes since V2: * Review comments and further grammatical fixes * Added openOCD version supported in each of the board documentation V2: https://lore.kernel.org/all/20230729204500.31823-1...@ti.com/ V1: https://lore.kernel.org/u-boot/20230721191934.1959003-1-j-kaci...@ti.com/ doc/board/ti/am62x_sk.rst | 24 ++ doc/board/ti/am65x_evm.rst| 24 ++ doc/board/ti/img/openocd-overview.svg | 580 ++ doc/board/ti/j7200_evm.rst| 24 ++ doc/board/ti/j721e_evm.rst| 24 ++ doc/board/ti/k3.rst | 481 + 6 files changed, 1157 insertions(+) create mode 100644 doc/board/ti/img/openocd-overview.svg diff --git a/doc/board/ti/am62x_sk.rst b/doc/board/ti/am62x_sk.rst index 637985cb096e..9f577fe0f430 100644 --- a/doc/board/ti/am62x_sk.rst +++ b/doc/board/ti/am62x_sk.rst @@ -246,3 +246,27 @@ https://www.ti.com/lit/pdf/spruiv7 under the `Boot Mode Pins` section. - 11001010 For SW2 and SW1, the switch state in the "ON" position = 1. + +Debugging U-boot + + +See :ref:`Common Debugging environment - openOCD`: for +detailed setup information. + +.. warning:: + + **OpenOCD support since**: v0.12.0 + + If the default package version of OpenOCD in your development + environment's distribution needs to be updated, it might be necessary to + build OpenOCD from the source. + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_openocd_connect_XDS110 +:end-before: .. k3_rst_include_end_openocd_connect_XDS110 + +To start OpenOCD to connect to the board + +.. code-block:: bash + + openocd -f board/ti_am625evm.cfg diff --git a/doc/board/ti/am65x_evm.rst b/doc/board/ti/am65x_evm.rst index 0129235c2b29..60d18390959f 100644 --- a/doc/board/ti/am65x_evm.rst +++ b/doc/board/ti/am65x_evm.rst @@ -287,3 +287,27 @@ artifacts needed to the device: sb --ymodem tispl.bin > $MAIN_DEV < $MAIN_DEV sleep 1 sb --xmodem u-boot.img > $MAIN_DEV < $MAIN_DEV + +Debugging U-boot + + +See :ref:`Common Debugging environment - openOCD`: for +detailed setup information. + +.. warning:: + + **OpenOCD support since**: v0.12.0 + + If the default package version of OpenOCD in your development + environment's distribution needs to be updated, it might be necessary to + build OpenOCD from the source. + +.. include:: k3.rst +:start-after: .. k3_rst_include_start_openocd_connect_XDS110 +:end-before: .. k3_rst_include_end_openocd_connect_XDS110 + +To start OpenOCD to connect to the board + +.. code-block:: bash + + openocd -f board/ti_am654evm.cfg diff --git a/doc/board/ti/img/openocd-overview.svg b/doc/board/ti/img/openocd-overview.svg new file mode 100644 index ..13a817132a45 --- /dev/null +++ b/doc/board/ti/img/openocd-overview.svg @@ -0,0 +1,580 @@ + + +
[PATCH v6 9/9] sandbox: capsule: Generate capsule related files through binman
The EFI capsule files can now be generated as part of u-boot
build. This is done through binman. Add capsule entry nodes in the
u-boot.dtsi for the sandbox architecture for generating the
capsules. Remove the corresponding generation of capsules from the
capsule update conftest file.
The capsules are generated through the config file for the sandbox
variant, and through explicit parameters for the sandbox_flattree
variant.
Also generate the FIT image used for testing the capsule update
feature on the sandbox_flattree variant through binman. Remove the now
superfluous its file which was used for generating this FIT image.
Signed-off-by: Sughosh Ganu
---
Changes since V5:
* Use the public key ESL file and other input files from the tree
instead of the /tmp/capsules/ directory being used in previous
version.
* Use macros for other input files and certs.
arch/sandbox/dts/u-boot.dtsi | 347 ++
test/py/tests/test_efi_capsule/conftest.py| 128 +--
.../tests/test_efi_capsule/uboot_bin_env.its | 36 --
3 files changed, 348 insertions(+), 163 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
index 60bd004937..ae798660de 100644
--- a/arch/sandbox/dts/u-boot.dtsi
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -7,11 +7,358 @@
*/
#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+
+#define SANDBOX_UBOOT_IMAGE_GUID "09d7cf52-0720-4710-91d1-08469b7fe9c8"
+#define SANDBOX_UBOOT_ENV_IMAGE_GUID "5a7021f5-fef2-48b4-aaba-832e777418c0"
+#define SANDBOX_FIT_IMAGE_GUID "3673b45d-6a7c-46f3-9e60-adabb03f7937"
+#define SANDBOX_INCORRECT_GUID "058b7d83-50d5-4c47-a195-60d86ad341c4"
+
+#define UBOOT_BIN_IMAGE
"test/py/tests/test_efi_capsule/test_files/u-boot.bin.new"
+#define UBOOT_ENV_IMAGE
"test/py/tests/test_efi_capsule/test_files/u-boot.env.new"
+#define UBOOT_FIT_IMAGE"u-boot_bin_env.itb"
+
+#define CAPSULE_PRIV_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER.key"
+#define CAPSULE_PUB_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER.crt"
+#define CAPSULE_INVAL_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER2.key"
+#define CAPSULE_INVAL_PUB_KEY
"test/py/tests/test_efi_capsule/test_files/SIGNER2.crt"
+
/ {
#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
signature {
capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
};
#endif
+
+ binman: binman {
+ multiple-images;
+ };
+};
+
+ {
+ itb {
+ filename = UBOOT_FIT_IMAGE;
+
+ fit {
+ description = "Automatic U-Boot environment update";
+ #address-cells = <2>;
+
+ images {
+ u-boot-bin {
+ description = "U-Boot binary on SPI
Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename = UBOOT_BIN_IMAGE;
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ u-boot-env {
+ description = "U-Boot environment on
SPI Flash";
+ compression = "none";
+ type = "firmware";
+ arch = "sandbox";
+ load = <0>;
+ blob {
+ filename = UBOOT_ENV_IMAGE;
+ };
+
+ hash-1 {
+ algo = "sha1";
+ };
+ };
+ };
+ };
+ };
+
+ capsule1 {
+ filename = "Test01";
+ capsule {
+ type = "efi-capsule";
+ image-index = <0x1>;
+ image-type-id = SANDBOX_UBOOT_IMAGE_GUID;
+
+ blob-ext {
+ filename = UBOOT_BIN_IMAGE;
+ };
+ };
+ };
+
+ capsule2 {
+ filename = "Test02";
+ capsule {
+ type = "efi-capsule";
+ image-index = <0x2>;
+
[PATCH v6 8/9] test: capsule: Remove public key embed logic from capsule update test
The embedding of the public key EFI Signature List(ESL) file into the
platform's DTB is now done at the time of u-boot build. Remove this
logic from the capsule update test' configuration.
Include the public key for the sandbox and sandbox_flattree variant
as part of the build.
Signed-off-by: Sughosh Ganu
---
Changes since V5:
* Use the public key ESL file from the tree instead of the
/tmp/capsules/ directory being used in previous version.
configs/sandbox_defconfig| 1 +
configs/sandbox_flattree_defconfig | 1 +
test/py/tests/test_efi_capsule/conftest.py | 37
test/py/tests/test_efi_capsule/signature.dts | 10 --
4 files changed, 9 insertions(+), 40 deletions(-)
delete mode 100644 test/py/tests/test_efi_capsule/signature.dts
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index b6c4f735f2..3d9e59a11d 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -341,6 +341,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="../../../test/py/tests/test_efi_capsule/test_files/SIGNER.esl"
CONFIG_EFI_SECURE_BOOT=y
CONFIG_TEST_FDTDEC=y
CONFIG_UNIT_TEST=y
diff --git a/configs/sandbox_flattree_defconfig
b/configs/sandbox_flattree_defconfig
index 8aa295686d..325e162ad9 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -227,6 +227,7 @@ CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
CONFIG_EFI_CAPSULE_ON_DISK=y
CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
CONFIG_EFI_CAPSULE_AUTHENTICATE=y
+CONFIG_EFI_CAPSULE_ESL_FILE="../../../test/py/tests/test_efi_capsule/test_files/SIGNER.esl"
CONFIG_UNIT_TEST=y
CONFIG_UT_TIME=y
CONFIG_UT_DM=y
diff --git a/test/py/tests/test_efi_capsule/conftest.py
b/test/py/tests/test_efi_capsule/conftest.py
index 054be1ee97..bee3050282 100644
--- a/test/py/tests/test_efi_capsule/conftest.py
+++ b/test/py/tests/test_efi_capsule/conftest.py
@@ -25,48 +25,25 @@ def efi_capsule_data(request, u_boot_config):
image_path = u_boot_config.persistent_data_dir + '/test_efi_capsule.img'
try:
+capsules_path_dir = u_boot_config.source_dir +
'/test/py/tests/test_efi_capsule/test_files/'
# Create a target device
check_call('dd if=/dev/zero of=./spi.bin bs=1MiB count=16', shell=True)
check_call('rm -rf %s' % mnt_point, shell=True)
check_call('mkdir -p %s' % data_dir, shell=True)
check_call('mkdir -p %s' % install_dir, shell=True)
-
-capsule_auth_enabled = u_boot_config.buildconfig.get(
-'config_efi_capsule_authenticate')
-if capsule_auth_enabled:
-# Create private key (SIGNER.key) and certificate (SIGNER.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER.key '
-'-out SIGNER.crt -nodes -days 365'
- % data_dir, shell=True)
-check_call('cd %s; %scert-to-efi-sig-list SIGNER.crt SIGNER.esl'
- % (data_dir, EFITOOLS_PATH), shell=True)
-
-# Update dtb adding capsule certificate
-check_call('cd %s; '
- 'cp %s/test/py/tests/test_efi_capsule/signature.dts .'
- % (data_dir, u_boot_config.source_dir), shell=True)
-check_call('cd %s; '
- 'dtc -@ -I dts -O dtb -o signature.dtbo signature.dts; '
- 'fdtoverlay -i %s/arch/sandbox/dts/test.dtb '
-'-o test_sig.dtb signature.dtbo'
- % (data_dir, u_boot_config.build_dir), shell=True)
-
-# Create *malicious* private key (SIGNER2.key) and certificate
-# (SIGNER2.crt)
-check_call('cd %s; '
- 'openssl req -x509 -sha256 -newkey rsa:2048 '
-'-subj /CN=TEST_SIGNER/ -keyout SIGNER2.key '
-'-out SIGNER2.crt -nodes -days 365'
- % data_dir, shell=True)
+check_call('cp %s/* %s ' % (capsules_path_dir, data_dir), shell=True)
# Update dtb to add the version information
check_call('cd %s; '
'cp %s/test/py/tests/test_efi_capsule/version.dts .'
% (data_dir, u_boot_config.source_dir), shell=True)
+
+capsule_auth_enabled = u_boot_config.buildconfig.get(
+'config_efi_capsule_authenticate')
if capsule_auth_enabled:
+check_call('cp %s/arch/sandbox/dts/test.dtb %s/test_sig.dtb' %
+ (u_boot_config.build_dir, data_dir), shell=True)
check_call('cd %s; '
'dtc -@ -I dts -O dtb -o version.dtbo version.dts; '
'fdtoverlay -i test_sig.dtb '
diff
[PATCH v6 7/9] doc: Add documentation to highlight capsule generation related updates
The EFI capsules can now be generated as part of u-boot build, through binman. Highlight these changes in the documentation. Signed-off-by: Sughosh Ganu --- Changes since V5: * Remove the documentation for generating the capsule through config file, as that functionality is not added through this series. doc/develop/uefi/uefi.rst | 18 ++ 1 file changed, 18 insertions(+) diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst index b2854b52a6..3150d6fb9c 100644 --- a/doc/develop/uefi/uefi.rst +++ b/doc/develop/uefi/uefi.rst @@ -318,6 +318,9 @@ Run the following command --guid \ +Capsule with firmware version +* + The UEFI specification does not define the firmware versioning mechanism. EDK II reference implementation inserts the FMP Payload Header right before the payload. It coutains the fw_version and lowest supported version, @@ -345,6 +348,21 @@ add --fw-version option in mkeficapsule tool. If the --fw-version option is not set, FMP Payload Header is not inserted and fw_version is set as 0. + +Capsule Generation through binman +* + +Support has also been added to generate capsules during u-boot build +through binman. This requires the platform's DTB to be populated with +the capsule entry nodes for binman. The capsules then can be generated +by specifying the capsule parameters either through a config file, or +by specifying them as properties in the capsule entry node. + +Check the arch/sandbox/dts/u-boot.dtsi file for the sandbox platform +as reference for how to generate capsules through binman as part of +u-boot build. + + Performing the update * -- 2.34.1
[PATCH v6 6/9] binman: capsule: Add support for generating EFI capsules
Add support in binman for generating EFI capsules. The capsule parameters can be specified through the capsule binman entry. Also add test cases in binman for testing capsule generation. Signed-off-by: Sughosh Ganu --- Changes since V5: * Add support for the oemflag parameter used in FWU A/B updates. This was missed in the earlier version. * Use a single function, generate_capsule in the mkeficapsule bintool, instead of the multiple functions in earlier version. * Remove the logic for generating capsules from config file as suggested by Simon. * Use required_props for image index and GUID parameters. * Use a subnode for the capsule payload instead of using a filename for the payload, as suggested by Simon. * Add a capsule generation test with oemflag parameter being passed. configs/sandbox_spl_defconfig | 1 + tools/binman/btool/mkeficapsule.py| 101 +++ tools/binman/entries.rst | 64 +++ tools/binman/etype/efi_capsule.py | 160 ++ tools/binman/ftest.py | 122 + tools/binman/test/307_capsule.dts | 21 +++ tools/binman/test/308_capsule_signed.dts | 23 +++ tools/binman/test/309_capsule_version.dts | 22 +++ tools/binman/test/310_capsule_signed_ver.dts | 24 +++ tools/binman/test/311_capsule_oemflags.dts| 22 +++ tools/binman/test/312_capsule_missing_key.dts | 22 +++ .../binman/test/313_capsule_missing_index.dts | 20 +++ .../binman/test/314_capsule_missing_guid.dts | 19 +++ .../test/315_capsule_missing_payload.dts | 17 ++ 14 files changed, 638 insertions(+) create mode 100644 tools/binman/btool/mkeficapsule.py create mode 100644 tools/binman/etype/efi_capsule.py create mode 100644 tools/binman/test/307_capsule.dts create mode 100644 tools/binman/test/308_capsule_signed.dts create mode 100644 tools/binman/test/309_capsule_version.dts create mode 100644 tools/binman/test/310_capsule_signed_ver.dts create mode 100644 tools/binman/test/311_capsule_oemflags.dts create mode 100644 tools/binman/test/312_capsule_missing_key.dts create mode 100644 tools/binman/test/313_capsule_missing_index.dts create mode 100644 tools/binman/test/314_capsule_missing_guid.dts create mode 100644 tools/binman/test/315_capsule_missing_payload.dts diff --git a/configs/sandbox_spl_defconfig b/configs/sandbox_spl_defconfig index 8d50162b27..65223475ab 100644 --- a/configs/sandbox_spl_defconfig +++ b/configs/sandbox_spl_defconfig @@ -249,3 +249,4 @@ CONFIG_UNIT_TEST=y CONFIG_SPL_UNIT_TEST=y CONFIG_UT_TIME=y CONFIG_UT_DM=y +CONFIG_TOOLS_MKEFICAPSULE=y diff --git a/tools/binman/btool/mkeficapsule.py b/tools/binman/btool/mkeficapsule.py new file mode 100644 index 00..da1d5de873 --- /dev/null +++ b/tools/binman/btool/mkeficapsule.py @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0+ +# Copyright 2023 Linaro Limited +# +"""Bintool implementation for mkeficapsule tool + +mkeficapsule is a tool used for generating EFI capsules. + +The following are the command-line options to be provided +to the tool +Usage: mkeficapsule [options] +Options: + -g, --guid guid for image blob type + -i, --index update image index + -I, --instanceupdate hardware instance + -v, --fw-version firmware version + -p, --private-key private key file + -c, --certificate signer's certificate file + -m, --monotonic-count monotonic count + -d, --dump_sig dump signature (*.p7) + -A, --fw-accept firmware accept capsule, requires GUID, no image blob + -R, --fw-revert firmware revert capsule, takes no GUID, no image blob + -o, --capoemflag Capsule OEM Flag, an integer between 0x and 0x + -h, --help print a help message +""" + +from binman import bintool + +class Bintoolmkeficapsule(bintool.Bintool): +"""Handles the 'mkeficapsule' tool + +This bintool is used for generating the EFI capsules. The +capsule generation parameters can either be specified through +command-line, or through a config file. +""" +def __init__(self, name): +super().__init__(name, 'mkeficapsule tool for generating capsules') + +def generate_capsule(self, image_index, image_guid, hardware_instance, + payload, output_fname, priv_key, pub_key, + monotonic_count=0, version=0, oemflags=0): +"""Generate a capsule through commandline provided parameters + +Args: +image_index (int): Unique number for identifying payload image +image_guid (str): GUID used for identifying the image +hardware_instance (int): Optional unique hardware instance of +a device in the system. 0 if not being used +payload (str): Path to the input payload image +output_fname (str): Path to the output capsule file +
[PATCH v6 5/9] test: capsule: Add files needed for testing EFI capsule updates
Add the files that would be needed for testing the EFI capsule update
functionality. These include the keys needed for signing and
authenticating the capsules with the capsule authentication
functionality enabled. This includes the public key in form of the EFI
Signature List(ESL) file which will be embedded in the platform's DTB.
Signed-off-by: Sughosh Ganu
---
Changes since V5:
* Get rid of the logic of keeping the files under the /tmp/capsules/
directory from earlier versions.
* New patch which introduces the input files and certs needed for EFI
capsule update testing in the tree.
* The capsule input files and certs are put under the
test/py/tests/test_efi_capsule/test_files/ directory.
.../test_efi_capsule/test_files/SIGNER.crt| 19
.../test_efi_capsule/test_files/SIGNER.esl| Bin 0 -> 829 bytes
.../test_efi_capsule/test_files/SIGNER.key| 28 ++
.../test_efi_capsule/test_files/SIGNER2.crt | 19
.../test_efi_capsule/test_files/SIGNER2.key | 28 ++
.../test_files/u-boot.bin.new | 1 +
.../test_files/u-boot.bin.old | 1 +
.../test_files/u-boot.env.new | 1 +
.../test_files/u-boot.env.old | 1 +
9 files changed, 98 insertions(+)
create mode 100644 test/py/tests/test_efi_capsule/test_files/SIGNER.crt
create mode 100644 test/py/tests/test_efi_capsule/test_files/SIGNER.esl
create mode 100644 test/py/tests/test_efi_capsule/test_files/SIGNER.key
create mode 100644 test/py/tests/test_efi_capsule/test_files/SIGNER2.crt
create mode 100644 test/py/tests/test_efi_capsule/test_files/SIGNER2.key
create mode 100644 test/py/tests/test_efi_capsule/test_files/u-boot.bin.new
create mode 100644 test/py/tests/test_efi_capsule/test_files/u-boot.bin.old
create mode 100644 test/py/tests/test_efi_capsule/test_files/u-boot.env.new
create mode 100644 test/py/tests/test_efi_capsule/test_files/u-boot.env.old
diff --git a/test/py/tests/test_efi_capsule/test_files/SIGNER.crt
b/test/py/tests/test_efi_capsule/test_files/SIGNER.crt
new file mode 100644
index 00..722a4e2483
--- /dev/null
+++ b/test/py/tests/test_efi_capsule/test_files/SIGNER.crt
@@ -0,0 +1,19 @@
+-BEGIN CERTIFICATE-
+MIIDDTCCAfWgAwIBAgIUGGjxXEUS+sBJaSOBz4u0MJRWdcowDQYJKoZIhvcNAQEL
+BQAwFjEUMBIGA1UEAwwLVEVTVF9TSUdORVIwHhcNMjMwNzI3MDY1NjQzWhcNMzMw
+NzI0MDY1NjQzWjAWMRQwEgYDVQQDDAtURVNUX1NJR05FUjCCASIwDQYJKoZIhvcN
+AQEBBQADggEPADCCAQoCggEBAMUEYpFf8i/zLX6/4bhUAIrLWCxaLCqGscZ85DSU
+SagMu+9DpCDrJSzgZQFj2+YSc4JSoBDs9u/JN+HNH+hK255Slzf8+Pl2YeRjTyCA
+7k6u0s2nFpLJkMPBzqyrEYP+fNrGsTtIlvutef2MPs8WfgyzB5CSRx/K40PirQHE
+Lt5HfLJ8WOvPAbdZ4z+PDm5LrZReewJOYHVKQepAY8z3Dsy3ZBnXGI/1ZYgMfTU0
+sBCfTtEBJb+ja+eKepw93IuxPLdN1ZXW1YUiBTs7h+BUAJr+Qjt/zvWl2ms1+sQf
+dHtsMa+WmTLu0XHCGOEfgX/fdTWv1GaelMTxl9Lzqug/+8cCAwEAAaNTMFEwHQYD
+VR0OBBYEFLH9hYGrnXfQ/CfAMaMAh64xJxTCMB8GA1UdIwQYMBaAFLH9hYGrnXfQ
+/CfAMaMAh64xJxTCMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
+ACSmt+2O8mNT5K232P2BOPt3r2v3M+HZFsjb54s+wSiY5tS1KBFJbMehGKhwNZRz
+uEIp1RJnsh9Kg8Cnzh2Hpgwnycx2sipbTXN0Frz8QuC3zbAqhrcalaKFOuSXbY6O
+mBBJDJENj+d57yzHxT3XvSmAu62UMf2hwJqIqQfA7+wrV2VGEbrY4O9KY6O4Mj2f
+vS9WjN3840xQCqsohwbU9u9GpHYb6eFQ+jiit/yqYVlJCSDN812Fv1TYOPzLqG8L
+VCCqqpPRJX0E13kPAafoNK5UA2OKglgosvufWzwJ3Mn0Al8BQnv5rRnBoTxJLDef
+n+uX7jeUW6LfIH5s8cMrA2Y=
+-END CERTIFICATE-
diff --git a/test/py/tests/test_efi_capsule/test_files/SIGNER.esl
b/test/py/tests/test_efi_capsule/test_files/SIGNER.esl
new file mode 100644
index
..3d584cd44a22e0b9c5414f54a3a5bc24504f0a71
GIT binary patch
literal 829
zcmZ1^?2Da*aux2_hA(f&|m%gg`ZcJn3lsqe}#s3e(NrsT`o51o;%XmcZo_o!vnuyou8MjA1w(sZ5^Ikh8uA0d&
zq14Oql|%BG?|f$}Cx=>MA9!BcB$vO!?J-$h2%{fo1ocU8@?z0V^I9<4nwq42+9|4FU~hfuSzT$0Eievhih`*nu$%40c8am1W!C_I*kYezJD^jlYc+zsuKW
ze>Z-3Q|!d;=iPP(HD)}!vQ%G+4f~T>L<^X
zZPJSNEiMt;^T+AI_Olzb+O|tgUDRszWO{C2-wXjyo{7Bu^S96xG%eXnN2?zK}4
z|1LZ*t79emf%k8;!^cinjK-Ya?W4kO$7d-cP5?*4h~6Tr1vqn+)_xA$%A{XD
z4ESZSX#1a4iIJY13THpZw(bwPVe#kmihS-6g;lF2UsSDSxn9Z7xcr65x)A2%uBHf$
wO~21F`GqN-(W(09TFHY8Z9H|%=g)sV{hj%g=tcJx>T*6F)@Duv0DX*DtN;K2
literal 0
HcmV?d1
diff --git a/test/py/tests/test_efi_capsule/test_files/SIGNER.key
b/test/py/tests/test_efi_capsule/test_files/SIGNER.key
new file mode 100644
index 00..e124cd35f0
--- /dev/null
+++ b/test/py/tests/test_efi_capsule/test_files/SIGNER.key
@@ -0,0 +1,28 @@
+-BEGIN PRIVATE KEY-
+MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDFBGKRX/Iv8y1+
+v+G4VACKy1gsWiwqhrHGfOQ0lEmoDLvvQ6Qg6yUs4GUBY9vmEnOCUqAQ7PbvyTfh
+zR/oStueUpc3/Pj5dmHkY08ggO5OrtLNpxaSyZDDwc6sqxGD/nzaxrE7SJb7rXn9
+jD7PFn4MsweQkkcfyuND4q0BxC7eR3yyfFjrzwG3WeM/jw5uS62UXnsCTmB1SkHq
+QGPM9w7Mt2QZ1xiP9WWIDH01NLAQn07RASW/o2vninqcPdyLsTy3TdWV1tWFIgU7
+O4fgVACa/kI7f871pdprNfrEH3R7bDGvlpky7tFxwhjhH4F/33U1r9RmnpTE8ZfS
+86roP/vHAgMBAAECggEAMvsIAIM52cOM1bwUTgzamQ+2UL/Cpvx0ux5tNNfcWXJ2
+HRs9ONFwLLUiHeJ3sAi9QA9eYRLYcUL5xWG9bHAWdVj8zV2WFYNXIHC8NHZ4c/7U
[PATCH v6 4/9] doc: capsule: Document the new mechanism to embed ESL file into dtb
Update the document to specify how the EFI Signature List(ESL) file
can be embedded into the platform's dtb as part of the u-boot build.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V5: None
doc/develop/uefi/uefi.rst | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/doc/develop/uefi/uefi.rst b/doc/develop/uefi/uefi.rst
index a7a41f2fac..b2854b52a6 100644
--- a/doc/develop/uefi/uefi.rst
+++ b/doc/develop/uefi/uefi.rst
@@ -522,20 +522,16 @@ and used by the steps highlighted below.
...
}
-You can do step-4 manually with
+You can perform step-4 by defining the Kconfig symbol
+CONFIG_EFI_CAPSULE_ESL_FILE. Once this has been done, the signature
+node can be added to the u-boot.dtsi file. For reference, check the
+u-boot.dtsi file for the sandbox architecture. If this node has not
+been added to the architecture's u-boot.dtsi file, this needs to be
+done. The node has currently been added for the sandbox and arm
+architectures' in the u-boot.dtsi file. Once the u-boot.dtsi file has
+been added with the signature node, the esl file will automatically
+get embedded into the platform's dtb as part of u-boot build.
-.. code-block:: console
-
-$ dtc -@ -I dts -O dtb -o signature.dtbo signature.dts
-$ fdtoverlay -i orig.dtb -o new.dtb -v signature.dtbo
-
-where signature.dts looks like::
-
-&{/} {
-signature {
-capsule-key = /incbin/("CRT.esl");
-};
-};
Anti-rollback Protection
--
2.34.1
[PATCH v6 3/9] capsule: authenticate: Add capsule public key in platform's dtb
The EFI capsule authentication logic in u-boot expects the public key
in the form of an EFI Signature List(ESL) to be provided as part of
the platform's dtb. Currently, the embedding of the ESL file into the
dtb needs to be done manually.
Add a signature node in the u-boot dtsi file and include the public
key through the capsule-key property. This file is per architecture,
and is currently being added for sandbox and arm architectures. It
will have to be added for other architectures which need to enable
capsule authentication support.
The path to the ESL file is specified through the
CONFIG_EFI_CAPSULE_ESL_FILE symbol.
Signed-off-by: Sughosh Ganu
---
Changes since V5:
* None
arch/arm/dts/u-boot.dtsi | 14 ++
arch/sandbox/dts/u-boot.dtsi | 17 +
lib/efi_loader/Kconfig | 9 +
3 files changed, 40 insertions(+)
create mode 100644 arch/arm/dts/u-boot.dtsi
create mode 100644 arch/sandbox/dts/u-boot.dtsi
diff --git a/arch/arm/dts/u-boot.dtsi b/arch/arm/dts/u-boot.dtsi
new file mode 100644
index 00..4f31da4521
--- /dev/null
+++ b/arch/arm/dts/u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ */
+
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+/ {
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+};
+#endif /* CONFIG_EFI_CAPSULE_AUTHENTICATE */
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
new file mode 100644
index 00..60bd004937
--- /dev/null
+++ b/arch/sandbox/dts/u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Devicetree file with miscellaneous nodes that will be included
+ * at build time into the DTB. Currently being used for including
+ * capsule related information.
+ *
+ */
+
+#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
+/ {
+#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
+ signature {
+ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
+ };
+#endif
+};
+#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index a22e47616f..0d559ff3a1 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -235,6 +235,15 @@ config EFI_CAPSULE_MAX
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
+config EFI_CAPSULE_ESL_FILE
+ string "Path to the EFI Signature List File"
+ default ""
+ depends on EFI_CAPSULE_AUTHENTICATE
+ help
+ Provides the absolute path to the EFI Signature List file which
+ will be embedded in the platform's device tree and used for
+ capsule authentication at the time of capsule update.
+
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
--
2.34.1
[PATCH v6 2/9] nuvoton: npcm845-evb: Add a newline at the end of file
Add a newline at the end of the dts, without which the build fails when including the u-boot.dtsi file. Signed-off-by: Sughosh Ganu Reviewed-by: Simon Glass Reviewed-by: Ilias Apalodimas --- Changes since V5: None arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/dts/nuvoton-npcm845-evb.dts b/arch/arm/dts/nuvoton-npcm845-evb.dts index 3cab7807e3..a93666cb41 100644 --- a/arch/arm/dts/nuvoton-npcm845-evb.dts +++ b/arch/arm/dts/nuvoton-npcm845-evb.dts @@ -354,4 +354,4 @@ _pins _pins >; -}; \ No newline at end of file +}; -- 2.34.1
[PATCH v6 1/9] binman: bintool: Build a tool from a list of commands
Add support to build a tool from source with a list of commands. This
is useful when a tool can be built with multiple commands instead of a
single command.
Signed-off-by: Sughosh Ganu
Reviewed-by: Simon Glass
---
Changes since V5: None
tools/binman/bintool.py | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/tools/binman/bintool.py b/tools/binman/bintool.py
index 0b0f56dbbb..3c4ad1adbb 100644
--- a/tools/binman/bintool.py
+++ b/tools/binman/bintool.py
@@ -328,7 +328,7 @@ class Bintool:
return result.stdout
@classmethod
-def build_from_git(cls, git_repo, make_target, bintool_path, flags=None):
+def build_from_git(cls, git_repo, make_targets, bintool_path, flags=None):
"""Build a bintool from a git repo
This clones the repo in a temporary directory, builds it with 'make',
@@ -336,7 +336,8 @@ class Bintool:
Args:
git_repo (str): URL of git repo
-make_target (str): Target to pass to 'make' to build the tool
+make_targets (list of str): List of targets to pass to 'make' to
build
+the tool
bintool_path (str): Relative path of the tool in the repo, after
build is complete
flags (list of str): Flags or variables to pass to make, or None
@@ -350,12 +351,14 @@ class Bintool:
tmpdir = tempfile.mkdtemp(prefix='binmanf.')
print(f"- clone git repo '{git_repo}' to '{tmpdir}'")
tools.run('git', 'clone', '--depth', '1', git_repo, tmpdir)
-print(f"- build target '{make_target}'")
-cmd = ['make', '-C', tmpdir, '-j', f'{multiprocessing.cpu_count()}',
- make_target]
-if flags:
-cmd += flags
-tools.run(*cmd)
+for target in make_targets:
+print(f"- build target '{target}'")
+cmd = ['make', '-C', tmpdir, '-j',
f'{multiprocessing.cpu_count()}',
+ target]
+if flags:
+cmd += flags
+tools.run(*cmd)
+
fname = os.path.join(tmpdir, bintool_path)
if not os.path.exists(fname):
print(f"- File '{fname}' was not produced")
--
2.34.1
[PATCH v6 0/9] Integrate EFI capsule tasks into u-boot's build flow
This patchset aims to bring two capsule related tasks under the u-boot build flow. One is the embedding of the public key into the platform's dtb. The public key is in the form of an EFI Signature List(ESL) file and is used for capsule authentication. This is being achieved by adding the signature node containing the capsule public key in the architecture's u-boot.dtsi file. Currently, the u-boot.dtsi file has been added for the sandbox and arm architectures. The path to the ESL file is being provided through a Kconfig symbol(CONFIG_EFI_CAPSULE_ESL_FILE). Changes have also been made to the test flow so that the keys used for signing the capsule, and the ESL file, are generated prior to invoking the u-boot's build, which enables embedding the ESL file into the dtb as part of the u-boot build. The other task is related to generation of capsules. The capsules can be generated as part of u-boot build, and this is being achieved through binman, by adding a capsule entry type. The capsules can be generated by specifying the capsule parameters as properties under the capsule entry node. Changes have also been made to the efi capsule update feature testing setup on the sandbox variants. Currently, the capsule files and the public key ESL file are generated after u-boot has been built. This logic has been changed so that the capsule input files along with the keys needed for capsule signing and authentication are generated prior to initiation of the u-boot build. The placement of all the files needed for generation of capsules is under the test/py/tests/test_efi_capsule/test_files/ directory. The document has been updated to reflect the above changes. Changes since V5: This series drops the changes for generating capsules by reading the params from a config file. This was suggested by Simon Glass. The config file changes would be submitted separately once these changes get merged. * Get rid of the logic of keeping the files under the /tmp/capsules/ directory from earlier versions. * New patch which introduces the input files and certs needed for EFI capsule update testing in the tree. * The capsule input files and certs are put under the test/py/tests/test_efi_capsule/test_files/ directory. * Add support for the oemflag parameter used in FWU A/B updates. This was missed in the earlier version. * Use a single function, generate_capsule in the mkeficapsule bintool, instead of the multiple functions in earlier version. * Remove the logic for generating capsules from config file as suggested by Simon. * Use required_props for image index and GUID parameters. * Use a subnode for the capsule payload instead of using a filename for the payload, as suggested by Simon. * Add a capsule generation test with oemflag parameter being passed. * Remove the documentation for generating the capsule through config file, as that functionality is not added through this series. * Use the public key ESL file from the tree instead of the /tmp/capsules/ directory being used in previous version. * Use the public key ESL file and other input files from the tree instead of the /tmp/capsules/ directory being used in previous version. * Use macros for other input files and certs. Sughosh Ganu (9): binman: bintool: Build a tool from a list of commands nuvoton: npcm845-evb: Add a newline at the end of file capsule: authenticate: Add capsule public key in platform's dtb doc: capsule: Document the new mechanism to embed ESL file into dtb test: capsule: Add files needed for testing EFI capsule updates binman: capsule: Add support for generating EFI capsules doc: Add documentation to highlight capsule generation related updates test: capsule: Remove public key embed logic from capsule update test sandbox: capsule: Generate capsule related files through binman arch/arm/dts/nuvoton-npcm845-evb.dts | 2 +- arch/arm/dts/u-boot.dtsi | 14 + arch/sandbox/dts/u-boot.dtsi | 364 ++ configs/sandbox_defconfig | 1 + configs/sandbox_flattree_defconfig| 1 + configs/sandbox_spl_defconfig | 1 + doc/develop/uefi/uefi.rst | 40 +- lib/efi_loader/Kconfig| 9 + test/py/tests/test_efi_capsule/conftest.py| 165 +--- test/py/tests/test_efi_capsule/signature.dts | 10 - .../test_efi_capsule/test_files/SIGNER.crt| 19 + .../test_efi_capsule/test_files/SIGNER.esl| Bin 0 -> 829 bytes .../test_efi_capsule/test_files/SIGNER.key| 28 ++ .../test_efi_capsule/test_files/SIGNER2.crt | 19 + .../test_efi_capsule/test_files/SIGNER2.key | 28 ++ .../test_files/u-boot.bin.new | 1 + .../test_files/u-boot.bin.old | 1 + .../test_files/u-boot.env.new | 1 + .../test_files/u-boot.env.old | 1 + .../tests/test_efi_capsule/uboot_bin_env.its | 36 --
Re: [PATCH 2/3] malloc: Don't statically initialize av_ if using malloc_init
On 8/1/23 12:56, Heinrich Schuchardt wrote:
On 01.08.23 18:27, Sean Anderson wrote:
On 8/1/23 12:23, Heinrich Schuchardt wrote:
On 01.08.23 18:02, Sean Anderson wrote:
On 8/1/23 03:04, Heinrich Schuchardt wrote:
On 8/1/23 00:33, Sean Anderson wrote:
When we enable malloc_init, there is no need to statically initialize
av_, since we are going to do it manually. This lets us move av_ to
.bss, saving around 1-2k of data (depending on the pointer size).
cALLOc must be adjusted to not access top before malloc_init.
While we're at it, rename/reword the Kconfig to better describe what
this option does.
Signed-off-by: Sean Anderson
---
Kconfig | 18 +++---
common/dlmalloc.c | 9 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..4b32286b69 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,18 +372,14 @@ if EXPERT
When disabling this, please check if malloc calls, maybe
should be replaced by calloc - if one expects zeroed memory.
-config SYS_MALLOC_DEFAULT_TO_INIT
-bool "Default malloc to init while reserving the memory for it"
+config SYS_MALLOC_RUNTIME_INIT
+bool "Initialize malloc's internal data at runtime"
help
- It may happen that one needs to move the dynamic allocation
- from one to another memory range, eg. when moving the malloc
- from the limited static to a potentially large dynamic (DDR)
- memory.
-
- If so then on top of setting the updated memory aside one
- needs to bring the malloc init.
-
- If such a scenario is sought choose yes.
+ Initialize malloc's internal data structures at runtime,
rather than
+ at compile-time. This is necessary if relocating the
malloc arena
+ from a smaller static memory to a large DDR memory. It
can also
+ reduce the size of U-Boot by letting malloc's data
reside in .bss
+ instead of .data.
config TOOLS_DEBUG
bool "Enable debug information for tools"
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 30c78ae976..8a1daae5ec 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -556,6 +556,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
static mbinptr av_[NAV * 2 + 2] = {
+#if !CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
NULL, NULL,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5),
IAV(6), IAV(7),
IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13),
IAV(14), IAV(15),
@@ -573,6 +574,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109),
IAV(110), IAV(111),
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117),
IAV(118), IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125),
IAV(126), IAV(127)
+#endif
};
With this patch booting qemu-riscv64_spl_defconfig with
SYS_MALLOC_RUNTIME_INIT=y fails without output from main U-Boot.
After removing the #if above, main U-Boot output provides some
output but driver binding fails.
Without this patch and with SYS_MALLOC_DEFAULT_TO_INIT=y booting
succeeds.
#ifdef CONFIG_NEEDS_MANUAL_RELOC
@@ -623,7 +625,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end = start + size;
mem_malloc_brk = start;
-if (CONFIG_IS_ENABLED(SYS_MALLOC_DEFAULT_TO_INIT))
+if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT))
malloc_init();
debug("using memory %#lx-%#lx for malloc()\n",
mem_malloc_start,
@@ -2151,7 +2153,10 @@ Void_t* cALLOc(n, elem_size) size_t n;
size_t elem_size;
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
- INTERNAL_SIZE_T oldtopsize = chunksize(top);
+ INTERNAL_SIZE_T oldtopsize;
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
+ !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+oldtopsize = chunksize(top);
malloc_simple needs a value for oldtopsize and this is before
GD_FLG_FULL_MALLOC_INIT is set.
This change worked for me:
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
malloc_init();
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
#endif
You don't want to call malloc_init() twice. So some flag should be
added indicating if malloc_init() has been invoked.
Actually, I think the original condition was just backwards. It should
be
if (!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
(gd->flags & GD_FLG_FULL_MALLOC_INIT))
GD_FLG_FULL_MALLOC_INIT is set in initr_reloc().
*Thereafter*
mem_malloc_init is called in initr_malloc().
See init_sequence_r[].
This explains why calling malloc_init() here helped me.
Ah. So maybe we should set this flag in malloc_init. This is what SPL
does (see board_init_r).
--Sean
Re: [PATCH v5 03/12] capsule: authenticate: Add capsule public key in platform's dtb
hi Simon,
On Wed, 26 Jul 2023 at 19:56, Simon Glass wrote:
>
> Hi Sughosh,
>
> On Wed, 26 Jul 2023 at 02:57, Sughosh Ganu wrote:
> >
> > hi Simon,
> >
> > On Wed, 26 Jul 2023 at 04:22, Simon Glass wrote:
> > >
> > > Hi Sughosh,
> > >
> > > On Tue, 25 Jul 2023 at 02:58, Sughosh Ganu
> > > wrote:
> > > >
> > > > The EFI capsule authentication logic in u-boot expects the public key
> > > > in the form of an EFI Signature List(ESL) to be provided as part of
> > > > the platform's dtb. Currently, the embedding of the ESL file into the
> > > > dtb needs to be done manually.
> > > >
> > > > Add a signature node in the u-boot dtsi file and include the public
> > > > key through the capsule-key property. This file is per architecture,
> > > > and is currently being added for sandbox and arm architectures. It
> > > > will have to be added for other architectures which need to enable
> > > > capsule authentication support.
> > > >
> > > > The path to the ESL file is specified through the
> > > > CONFIG_EFI_CAPSULE_ESL_FILE symbol.
> > > >
> > > > Signed-off-by: Sughosh Ganu
> > > > ---
> > > > Changes since V4:
> > > > * Fix multi line comment format.
> > > > * Drop additional blank line.
> > > > * Remove the check for CONFIG_EFI_HAVE_CAPSULE_SUPPORT from arm's
> > > > u-boot.dtsi.
> > > > * Wrap the help text in the EFI_CAPSULE_ESL_FILE config at 72 chars.
> > > >
> >
> >
> >
> > > > diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi
> > > > new file mode 100644
> > > > index 00..60bd004937
> > > > --- /dev/null
> > > > +++ b/arch/sandbox/dts/u-boot.dtsi
> > > > @@ -0,0 +1,17 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +/*
> > > > + * Devicetree file with miscellaneous nodes that will be included
> > > > + * at build time into the DTB. Currently being used for including
> > > > + * capsule related information.
> > > > + *
> > > > + */
> > > > +
> > > > +#ifdef CONFIG_EFI_HAVE_CAPSULE_SUPPORT
> > > > +/ {
> > > > +#ifdef CONFIG_EFI_CAPSULE_AUTHENTICATE
> > > > + signature {
> > > > + capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE);
> > > > + };
> > > > +#endif
> > > > +};
> > > > +#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
> > >
> > > You missed my comment there. You should not need the outer #ifdef, but
> > > if you do, please combine them into one #if
> >
> > I did not miss your comment. The reason I have kept both the ifdefs is
> > that we need to include stuff which is needed only when
> > CONFIG_EFI_CAPSULE_AUTHENTICATE is enabled, and then the rest of the
> > stuff is needed only when CONFIG_EFI_HAVE_CAPSULE_SUPPORT is enabled.
> > Not having both the ifdefs would result in build failures. In the
> > u-boot.dtsi included for the arm arch, I am using a single ifdef,
> > since we are including only the signature node in that file.
>
> Well having
>
> / {
> };
>
> is harmless in all cases, I believe. So you should not need the outer one?
Sorry, I missed out this comment earlier. So this would not be an
empty node but contain the capsule generation nodes. This would result
in capsules getting generated for the sandbox_vpl and sandbox_noinst
variants which do not enable the capsule functionality.
-sughosh
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On Tue, 01 Aug 2023 09:53:52 +0100, Oliver Graute wrote: > > On 14/02/23, Ying-Chun Liu (PaulLiu) wrote: > > From: Marc Zyngier > > > > In the add_map() function, for each level it populates, it iterates from > > the root of the PT tree, making it ineficient if a mapping needs to occur > > past level 1. > > > > Instead, replace it with a recursive (and much simpler) algorithm > > that keeps the complexity as low as possible. With this, mapping > > 512GB at level 2 goes from several seconds down to not measurable > > on an A55 machine. > > > > We keep the block mappings at level 1 for now though. > > > > Signed-off-by: Marc Zyngier > > Signed-off-by: Pierre-Clément Tosi > > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the > > upstream ] > > Signed-off-by: Ying-Chun Liu (PaulLiu) > > Cc: Tom Rini > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6 > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059 > > Hello Marc, > > this patch somehow broke the boot of my imx8qm board. I run into this > issue: > > U-Boot 2023.07-rc6-4-g5527698481 (Aug 01 2023 - 10:10:52 +0200) > > Model: Advantech iMX8QM DMSSE20 > Board: DMS-SE20A1 8GB > Build: SCFW 549b1e18, SECO-FW c9de51c0, ATF 5782363 > Boot: USB > DRAM: 8 GiB > "Error" handler, esr 0xbf00 SError. > elr: 80020938 lr : 800209c8 (reloc) > elr: ffecf938 lr : ffecf9c8 > x0 : 0001 x1 : 6000 > x2 : 1000 x3 : 0002 > x4 : 4000 x5 : 00600401 > x6 : 0800 x7 : fff44a60 > x8 : 00680481 x9 : 0008 > x10: 0a200023 x11: 0002 > x12: 0002 x13: 80095a00 > x14: x15: ffecfd2c > x16: 8005454c x17: > x18: fd6afd50 x19: 0fe0 > x20: x21: 00600401 > x22: 6020 x23: 0020 > x24: 4808 x25: 001f > x26: 0003 x27: 6020 > x28: 0002 x29: fd6ab110 > > Code: a94573fb a8c67bfd d65f03c0 b9418a40 (8a160334) > Resetting CPU ... > > resetting ... > SCI reboot > request > > After some bisecting this patch poped up: > > 41e2787f5ec4249cb2e77a3ebd3c49035e3c6535 is the first bad commit > arm64: Reduce add_map() complexity > > After I reverted everything on top of this patch its booting again with > v2023.07 > > commit c1da6fdb5c239b432440721772d993e63cfdeb20 > armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present > > commit 836b8d4b205d2175b57cb9ef271e638b0c116e89 > arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present > > commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213 > arm64: Use FEAT_HAFDBS to track dirty pages when available > > > Do you have any idea whats going on here? Not really. I can only tell you that your HW has generated a SError, which is usually pretty fatal. There could be all sort of reasons why this happen, such as mapping a piece of address space that you are not supposed to access. If the previous incarnation of the PT code was behaving in a better way, the way to debug this is to dump both sets of page tables and compare what they actually map, figuring out where things go wrong. M. -- Without deviation from the norm, progress is not possible.
Re: [PATCH 2/3] malloc: Don't statically initialize av_ if using malloc_init
On 01.08.23 18:27, Sean Anderson wrote:
On 8/1/23 12:23, Heinrich Schuchardt wrote:
On 01.08.23 18:02, Sean Anderson wrote:
On 8/1/23 03:04, Heinrich Schuchardt wrote:
On 8/1/23 00:33, Sean Anderson wrote:
When we enable malloc_init, there is no need to statically initialize
av_, since we are going to do it manually. This lets us move av_ to
.bss, saving around 1-2k of data (depending on the pointer size).
cALLOc must be adjusted to not access top before malloc_init.
While we're at it, rename/reword the Kconfig to better describe what
this option does.
Signed-off-by: Sean Anderson
---
Kconfig | 18 +++---
common/dlmalloc.c | 9 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..4b32286b69 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,18 +372,14 @@ if EXPERT
When disabling this, please check if malloc calls, maybe
should be replaced by calloc - if one expects zeroed memory.
-config SYS_MALLOC_DEFAULT_TO_INIT
- bool "Default malloc to init while reserving the memory for it"
+config SYS_MALLOC_RUNTIME_INIT
+ bool "Initialize malloc's internal data at runtime"
help
- It may happen that one needs to move the dynamic allocation
- from one to another memory range, eg. when moving the malloc
- from the limited static to a potentially large dynamic (DDR)
- memory.
-
- If so then on top of setting the updated memory aside one
- needs to bring the malloc init.
-
- If such a scenario is sought choose yes.
+ Initialize malloc's internal data structures at runtime,
rather than
+ at compile-time. This is necessary if relocating the
malloc arena
+ from a smaller static memory to a large DDR memory. It
can also
+ reduce the size of U-Boot by letting malloc's data reside
in .bss
+ instead of .data.
config TOOLS_DEBUG
bool "Enable debug information for tools"
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 30c78ae976..8a1daae5ec 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -556,6 +556,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
static mbinptr av_[NAV * 2 + 2] = {
+#if !CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
NULL, NULL,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5),
IAV(6), IAV(7),
IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13),
IAV(14), IAV(15),
@@ -573,6 +574,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109),
IAV(110), IAV(111),
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117),
IAV(118), IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125),
IAV(126), IAV(127)
+#endif
};
With this patch booting qemu-riscv64_spl_defconfig with
SYS_MALLOC_RUNTIME_INIT=y fails without output from main U-Boot.
After removing the #if above, main U-Boot output provides some
output but driver binding fails.
Without this patch and with SYS_MALLOC_DEFAULT_TO_INIT=y booting
succeeds.
#ifdef CONFIG_NEEDS_MANUAL_RELOC
@@ -623,7 +625,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end = start + size;
mem_malloc_brk = start;
- if (CONFIG_IS_ENABLED(SYS_MALLOC_DEFAULT_TO_INIT))
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT))
malloc_init();
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
@@ -2151,7 +2153,10 @@ Void_t* cALLOc(n, elem_size) size_t n;
size_t elem_size;
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
- INTERNAL_SIZE_T oldtopsize = chunksize(top);
+ INTERNAL_SIZE_T oldtopsize;
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
+ !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+ oldtopsize = chunksize(top);
malloc_simple needs a value for oldtopsize and this is before
GD_FLG_FULL_MALLOC_INIT is set.
This change worked for me:
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
malloc_init();
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
#endif
You don't want to call malloc_init() twice. So some flag should be
added indicating if malloc_init() has been invoked.
Actually, I think the original condition was just backwards. It should
be
if (!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
(gd->flags & GD_FLG_FULL_MALLOC_INIT))
GD_FLG_FULL_MALLOC_INIT is set in initr_reloc().
*Thereafter*
mem_malloc_init is called in initr_malloc().
See init_sequence_r[].
This explains why calling malloc_init() here helped me.
Best regards
Heinrich
Re: [PATCH 2/3] malloc: Don't statically initialize av_ if using malloc_init
On 8/1/23 12:23, Heinrich Schuchardt wrote:
On 01.08.23 18:02, Sean Anderson wrote:
On 8/1/23 03:04, Heinrich Schuchardt wrote:
On 8/1/23 00:33, Sean Anderson wrote:
When we enable malloc_init, there is no need to statically initialize
av_, since we are going to do it manually. This lets us move av_ to
.bss, saving around 1-2k of data (depending on the pointer size).
cALLOc must be adjusted to not access top before malloc_init.
While we're at it, rename/reword the Kconfig to better describe what
this option does.
Signed-off-by: Sean Anderson
---
Kconfig | 18 +++---
common/dlmalloc.c | 9 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..4b32286b69 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,18 +372,14 @@ if EXPERT
When disabling this, please check if malloc calls, maybe
should be replaced by calloc - if one expects zeroed memory.
-config SYS_MALLOC_DEFAULT_TO_INIT
-bool "Default malloc to init while reserving the memory for it"
+config SYS_MALLOC_RUNTIME_INIT
+bool "Initialize malloc's internal data at runtime"
help
- It may happen that one needs to move the dynamic allocation
- from one to another memory range, eg. when moving the malloc
- from the limited static to a potentially large dynamic (DDR)
- memory.
-
- If so then on top of setting the updated memory aside one
- needs to bring the malloc init.
-
- If such a scenario is sought choose yes.
+ Initialize malloc's internal data structures at runtime,
rather than
+ at compile-time. This is necessary if relocating the
malloc arena
+ from a smaller static memory to a large DDR memory. It can
also
+ reduce the size of U-Boot by letting malloc's data reside
in .bss
+ instead of .data.
config TOOLS_DEBUG
bool "Enable debug information for tools"
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 30c78ae976..8a1daae5ec 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -556,6 +556,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
static mbinptr av_[NAV * 2 + 2] = {
+#if !CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
NULL, NULL,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5),
IAV(6), IAV(7),
IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13),
IAV(14), IAV(15),
@@ -573,6 +574,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109),
IAV(110), IAV(111),
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117),
IAV(118), IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125),
IAV(126), IAV(127)
+#endif
};
With this patch booting qemu-riscv64_spl_defconfig with
SYS_MALLOC_RUNTIME_INIT=y fails without output from main U-Boot.
After removing the #if above, main U-Boot output provides some output
but driver binding fails.
Without this patch and with SYS_MALLOC_DEFAULT_TO_INIT=y booting
succeeds.
#ifdef CONFIG_NEEDS_MANUAL_RELOC
@@ -623,7 +625,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end = start + size;
mem_malloc_brk = start;
-if (CONFIG_IS_ENABLED(SYS_MALLOC_DEFAULT_TO_INIT))
+if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT))
malloc_init();
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
@@ -2151,7 +2153,10 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
elem_size;
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
- INTERNAL_SIZE_T oldtopsize = chunksize(top);
+ INTERNAL_SIZE_T oldtopsize;
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
+ !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+oldtopsize = chunksize(top);
malloc_simple needs a value for oldtopsize and this is before
GD_FLG_FULL_MALLOC_INIT is set.
This change worked for me:
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
malloc_init();
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
#endif
You don't want to call malloc_init() twice. So some flag should be
added indicating if malloc_init() has been invoked.
Actually, I think the original condition was just backwards. It should
be
if (!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
(gd->flags & GD_FLG_FULL_MALLOC_INIT))
This does not work either.
oldtopsize is needed in calloc() both w/ and w/o GD_FLG_FULL_MALLOC_INIT
and w/ and w/o SYS_MALLOC_RUNTIME_INIT to define the memory area to zero
out for calloc(). You must set it to the correct value irrespective of
these conditions.
No it's not.
if (mem == NULL)
return NULL;
else
{
#if CONFIG_VAL(SYS_MALLOC_F_LEN)
if (!(gd->flags & GD_FLG_FULL_MALLOC_INIT)) {
memset(mem, 0, sz);
Re: [PATCH 2/3] malloc: Don't statically initialize av_ if using malloc_init
On 01.08.23 18:02, Sean Anderson wrote:
On 8/1/23 03:04, Heinrich Schuchardt wrote:
On 8/1/23 00:33, Sean Anderson wrote:
When we enable malloc_init, there is no need to statically initialize
av_, since we are going to do it manually. This lets us move av_ to
.bss, saving around 1-2k of data (depending on the pointer size).
cALLOc must be adjusted to not access top before malloc_init.
While we're at it, rename/reword the Kconfig to better describe what
this option does.
Signed-off-by: Sean Anderson
---
Kconfig | 18 +++---
common/dlmalloc.c | 9 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..4b32286b69 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,18 +372,14 @@ if EXPERT
When disabling this, please check if malloc calls, maybe
should be replaced by calloc - if one expects zeroed memory.
-config SYS_MALLOC_DEFAULT_TO_INIT
- bool "Default malloc to init while reserving the memory for it"
+config SYS_MALLOC_RUNTIME_INIT
+ bool "Initialize malloc's internal data at runtime"
help
- It may happen that one needs to move the dynamic allocation
- from one to another memory range, eg. when moving the malloc
- from the limited static to a potentially large dynamic (DDR)
- memory.
-
- If so then on top of setting the updated memory aside one
- needs to bring the malloc init.
-
- If such a scenario is sought choose yes.
+ Initialize malloc's internal data structures at runtime,
rather than
+ at compile-time. This is necessary if relocating the malloc
arena
+ from a smaller static memory to a large DDR memory. It can
also
+ reduce the size of U-Boot by letting malloc's data reside
in .bss
+ instead of .data.
config TOOLS_DEBUG
bool "Enable debug information for tools"
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 30c78ae976..8a1daae5ec 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -556,6 +556,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
static mbinptr av_[NAV * 2 + 2] = {
+#if !CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
NULL, NULL,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5),
IAV(6), IAV(7),
IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13),
IAV(14), IAV(15),
@@ -573,6 +574,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109),
IAV(110), IAV(111),
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117),
IAV(118), IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125),
IAV(126), IAV(127)
+#endif
};
With this patch booting qemu-riscv64_spl_defconfig with
SYS_MALLOC_RUNTIME_INIT=y fails without output from main U-Boot.
After removing the #if above, main U-Boot output provides some output
but driver binding fails.
Without this patch and with SYS_MALLOC_DEFAULT_TO_INIT=y booting
succeeds.
#ifdef CONFIG_NEEDS_MANUAL_RELOC
@@ -623,7 +625,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end = start + size;
mem_malloc_brk = start;
- if (CONFIG_IS_ENABLED(SYS_MALLOC_DEFAULT_TO_INIT))
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT))
malloc_init();
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
@@ -2151,7 +2153,10 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
elem_size;
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
- INTERNAL_SIZE_T oldtopsize = chunksize(top);
+ INTERNAL_SIZE_T oldtopsize;
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
+ !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+ oldtopsize = chunksize(top);
malloc_simple needs a value for oldtopsize and this is before
GD_FLG_FULL_MALLOC_INIT is set.
This change worked for me:
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
malloc_init();
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
#endif
You don't want to call malloc_init() twice. So some flag should be
added indicating if malloc_init() has been invoked.
Actually, I think the original condition was just backwards. It should
be
if (!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
(gd->flags & GD_FLG_FULL_MALLOC_INIT))
This does not work either.
oldtopsize is needed in calloc() both w/ and w/o GD_FLG_FULL_MALLOC_INIT
and w/ and w/o SYS_MALLOC_RUNTIME_INIT to define the memory area to zero
out for calloc(). You must set it to the correct value irrespective of
these conditions.
Why don't you want to call malloc_init() here?
Best regards
Heinrich
although this still doesn't match the malloc_simple condition. So maybe
the condition to remove the initialization should be
#if !CONFIG_VAL(SYS_MALLOC_F_LEN) && \
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
On Tue, Aug 01, 2023 at 05:10:08PM +0100, Abdellatif El Khlifi wrote: > Hi guys, > > On Tue, Aug 01, 2023 at 11:00:57AM -0400, Tom Rini wrote: > > > > > > > > > ... > > > > > > > > > Changelog: > > > > > > > > > === > > > > > > > > > > > > > > > > > > v17: > > > > > > > > > > > > > > > > > > * show a debug message rather than an error when FF-A is not > > > > > > > > > detected > > > > > > > > [snip] > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > > > index c5835e6ef6..8fbadb9201 100644 > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > > > > > > stored as file /ubootefi.var on the EFI system > > > > > > > > > partition. > > > > > > > > > > > > > > > > > > config EFI_MM_COMM_TEE > > > > > > > > > - bool "UEFI variables storage service via OP-TEE" > > > > > > > > > - depends on OPTEE > > > > > > > > > + bool "UEFI variables storage service via the trusted > > > > > > > > > world" > > > > > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > > > > > > > > > > > You didn't get my changes in here however. If you can do > > > > > > > > EFI_MM_COMM_TEE > > > > > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig > > > > > > > > does) then > > > > > > > > you don't make this option depend on . If FF-A is only > > > > > > > > for use here, you make FF-A depend on this, and the FF-A > > > > > > > > specific > > > > > > > > variable depend on ARM_FFA_TRANSPORT. > > > > > > > > > > > > > > Abdellatif hinted at what's going on here. When I added this > > > > > > > Kconfig > > > > > > > option to lx2160 FF-A wasn't implemented yet. > > > > > > > > > > > > The defconfig has existed since May 2020, which is when you added > > > > > > EFI_MM_COMM_TEE itself too. So I think it's that no one did the > > > > > > check I > > > > > > did until now and saw this series was disabling what was on the > > > > > > other > > > > > > platform. > > > > > > > > > > > > > Since FF-A isn't a new > > > > > > > communication mechanism but builds upon the existing SMCs to > > > > > > > build an > > > > > > > easier API, I asked Abdellatif to hide this complexity. > > > > > > > We had two options, either make Kconfig options for either FF-A > > > > > > > or the > > > > > > > traditional SMCs and remove the dependencies, or piggyback on > > > > > > > FF-As > > > > > > > discovery mechanism and make the choice at runtime. The latter > > > > > > > has a > > > > > > > small impact on code size, but imho makes developers' life a lot > > > > > > > easier. > > > > > > > > > > > > I'm not sure how much you can do a run-time option here since you're > > > > > > setting a bunch of default values for FF-A to 0 in Kconfig. If > > > > > > we're > > > > > > supposed to be able to get them at run time, we shouldn't need a > > > > > > Kconfig > > > > > > option at all. I'm also not sure how valid a use case it is where > > > > > > we > > > > > > won't know at build time what the rest of the firmware stack > > > > > > supports > > > > > > here. > > > > > > > > > > > > > > > > That's a fair point. FF-A in theory has APIs to discover memory. > > > > > Abdellatif, why do we need the Kconfigs for shared memory on FF-A? > > > > > > > > The statically carved out MM shared buffer address, size and offset > > > > cannot be discovered by FF-A ABIs. > > > > The MM communication driver in U-Boot could allocate the buffer and > > > > share it with the MM SP but > > > > we do not implement that support currently in either U-Boot or UEFI. > > > > > > Ok, that's a bit unfortunate, but Tom is right. Having the FF-A > > > addresses show up is as confusing as having Kconfig options for > > > discrete options. The whole point of my suggestion was to make users' > > > lives easier. Apologies for the confusion but can you bring back the > > > ifdefs? Looking at the patch this should be minimal just use > > > ifdef ARM_FFA_TRANSPORT and ifndef ARM_FFA_TRANSPORT. > > > > > > Tom you prefer that as well? > > > > Pending an answer to Jens' feedback, yes, going back to #ifdef's is > > fine, especially since default values of 0 are nonsense in this case > > (and as Heinrich's patch re SYS_MALLOC_LEN shows, dangerous since 0 != > > 0x0 once we do string comparisons). > > > > I'd like to give some context why it's important for Corstone-1000 platform > that the DT passed to the kernel matches the official kernel DT. Note that we've set aside the "should this be in DT or not" question. > There is a SystemReady IR 2.0 test checking the DT. It compares the DT > passed by U-Boot with a reference DT (the kernel DT) . The test fails if there > is a mismatch. So, if we add a DT node in U-Boot and the node is not > upstreamed > to the kernel DT, the DT test will fail. This is overall good and progress. > To be approved by the kernel
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
Hi guys, On Tue, Aug 01, 2023 at 11:00:57AM -0400, Tom Rini wrote: > > > > > > > > ... > > > > > > > > Changelog: > > > > > > > > === > > > > > > > > > > > > > > > > v17: > > > > > > > > > > > > > > > > * show a debug message rather than an error when FF-A is not > > > > > > > > detected > > > > > > > [snip] > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > > index c5835e6ef6..8fbadb9201 100644 > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > > > > > stored as file /ubootefi.var on the EFI system > > > > > > > > partition. > > > > > > > > > > > > > > > > config EFI_MM_COMM_TEE > > > > > > > > - bool "UEFI variables storage service via OP-TEE" > > > > > > > > - depends on OPTEE > > > > > > > > + bool "UEFI variables storage service via the trusted > > > > > > > > world" > > > > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > > > > > > > > > You didn't get my changes in here however. If you can do > > > > > > > EFI_MM_COMM_TEE > > > > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) > > > > > > > then > > > > > > > you don't make this option depend on . If FF-A is only > > > > > > > for use here, you make FF-A depend on this, and the FF-A specific > > > > > > > variable depend on ARM_FFA_TRANSPORT. > > > > > > > > > > > > Abdellatif hinted at what's going on here. When I added this > > > > > > Kconfig > > > > > > option to lx2160 FF-A wasn't implemented yet. > > > > > > > > > > The defconfig has existed since May 2020, which is when you added > > > > > EFI_MM_COMM_TEE itself too. So I think it's that no one did the > > > > > check I > > > > > did until now and saw this series was disabling what was on the other > > > > > platform. > > > > > > > > > > > Since FF-A isn't a new > > > > > > communication mechanism but builds upon the existing SMCs to build > > > > > > an > > > > > > easier API, I asked Abdellatif to hide this complexity. > > > > > > We had two options, either make Kconfig options for either FF-A or > > > > > > the > > > > > > traditional SMCs and remove the dependencies, or piggyback on FF-As > > > > > > discovery mechanism and make the choice at runtime. The latter has > > > > > > a > > > > > > small impact on code size, but imho makes developers' life a lot > > > > > > easier. > > > > > > > > > > I'm not sure how much you can do a run-time option here since you're > > > > > setting a bunch of default values for FF-A to 0 in Kconfig. If we're > > > > > supposed to be able to get them at run time, we shouldn't need a > > > > > Kconfig > > > > > option at all. I'm also not sure how valid a use case it is where we > > > > > won't know at build time what the rest of the firmware stack supports > > > > > here. > > > > > > > > > > > > > That's a fair point. FF-A in theory has APIs to discover memory. > > > > Abdellatif, why do we need the Kconfigs for shared memory on FF-A? > > > > > > The statically carved out MM shared buffer address, size and offset > > > cannot be discovered by FF-A ABIs. > > > The MM communication driver in U-Boot could allocate the buffer and share > > > it with the MM SP but > > > we do not implement that support currently in either U-Boot or UEFI. > > > > Ok, that's a bit unfortunate, but Tom is right. Having the FF-A > > addresses show up is as confusing as having Kconfig options for > > discrete options. The whole point of my suggestion was to make users' > > lives easier. Apologies for the confusion but can you bring back the > > ifdefs? Looking at the patch this should be minimal just use > > ifdef ARM_FFA_TRANSPORT and ifndef ARM_FFA_TRANSPORT. > > > > Tom you prefer that as well? > > Pending an answer to Jens' feedback, yes, going back to #ifdef's is > fine, especially since default values of 0 are nonsense in this case > (and as Heinrich's patch re SYS_MALLOC_LEN shows, dangerous since 0 != > 0x0 once we do string comparisons). > I'd like to give some context why it's important for Corstone-1000 platform that the DT passed to the kernel matches the official kernel DT. There is a SystemReady IR 2.0 test checking the DT. It compares the DT passed by U-Boot with a reference DT (the kernel DT) . The test fails if there is a mismatch. So, if we add a DT node in U-Boot and the node is not upstreamed to the kernel DT, the DT test will fail. To be approved by the kernel DT maintainers, the node should have a use case in the kernel which is not the case. There is a solution for this which is deleting the node we don't want to pass to the kernel using delete-node in the U-Boot DT. This method is used by many boards in U-Boot. Example: /delete-node/ mm-comms-buf@0200; Corstone-1000 can have a DT overlay that deletes the node just before running Linux (in the boot command). If you are happy with this solution, I
Re: Please pull u-boot-x86
On Tue, Aug 01, 2023 at 11:34:47PM +0800, Bin Meng wrote: > Hi Tom, > > CI: https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17161 > > The following changes since commit 4e619e8d4fd68095bc665a78f2651d8e478a4534: > > Merge tag 'u-boot-rockchip-20230731' of > https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-07-31 > 11:33:51 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-x86.git > tags/x86-pull-20230801 > > for you to fetch changes up to db971a7587d04b3f1cf2e6d452f9e37f50c5b3ed: > > x86: Add a little more info to cbsysinfo (2023-08-01 10:08:49 +0800) > The signed tag worked for me and applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] malloc: Don't statically initialize av_ if using malloc_init
On 8/1/23 03:04, Heinrich Schuchardt wrote:
On 8/1/23 00:33, Sean Anderson wrote:
When we enable malloc_init, there is no need to statically initialize
av_, since we are going to do it manually. This lets us move av_ to
.bss, saving around 1-2k of data (depending on the pointer size).
cALLOc must be adjusted to not access top before malloc_init.
While we're at it, rename/reword the Kconfig to better describe what
this option does.
Signed-off-by: Sean Anderson
---
Kconfig | 18 +++---
common/dlmalloc.c | 9 +++--
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..4b32286b69 100644
--- a/Kconfig
+++ b/Kconfig
@@ -372,18 +372,14 @@ if EXPERT
When disabling this, please check if malloc calls, maybe
should be replaced by calloc - if one expects zeroed memory.
-config SYS_MALLOC_DEFAULT_TO_INIT
-bool "Default malloc to init while reserving the memory for it"
+config SYS_MALLOC_RUNTIME_INIT
+bool "Initialize malloc's internal data at runtime"
help
- It may happen that one needs to move the dynamic allocation
- from one to another memory range, eg. when moving the malloc
- from the limited static to a potentially large dynamic (DDR)
- memory.
-
- If so then on top of setting the updated memory aside one
- needs to bring the malloc init.
-
- If such a scenario is sought choose yes.
+ Initialize malloc's internal data structures at runtime,
rather than
+ at compile-time. This is necessary if relocating the malloc
arena
+ from a smaller static memory to a large DDR memory. It can also
+ reduce the size of U-Boot by letting malloc's data reside in
.bss
+ instead of .data.
config TOOLS_DEBUG
bool "Enable debug information for tools"
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 30c78ae976..8a1daae5ec 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -556,6 +556,7 @@ typedef struct malloc_chunk* mbinptr;
#define IAV(i) bin_at(i), bin_at(i)
static mbinptr av_[NAV * 2 + 2] = {
+#if !CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
NULL, NULL,
IAV(0), IAV(1), IAV(2), IAV(3), IAV(4), IAV(5),
IAV(6), IAV(7),
IAV(8), IAV(9), IAV(10), IAV(11), IAV(12), IAV(13),
IAV(14), IAV(15),
@@ -573,6 +574,7 @@ static mbinptr av_[NAV * 2 + 2] = {
IAV(104), IAV(105), IAV(106), IAV(107), IAV(108), IAV(109),
IAV(110), IAV(111),
IAV(112), IAV(113), IAV(114), IAV(115), IAV(116), IAV(117),
IAV(118), IAV(119),
IAV(120), IAV(121), IAV(122), IAV(123), IAV(124), IAV(125),
IAV(126), IAV(127)
+#endif
};
With this patch booting qemu-riscv64_spl_defconfig with
SYS_MALLOC_RUNTIME_INIT=y fails without output from main U-Boot.
After removing the #if above, main U-Boot output provides some output
but driver binding fails.
Without this patch and with SYS_MALLOC_DEFAULT_TO_INIT=y booting succeeds.
#ifdef CONFIG_NEEDS_MANUAL_RELOC
@@ -623,7 +625,7 @@ void mem_malloc_init(ulong start, ulong size)
mem_malloc_end = start + size;
mem_malloc_brk = start;
-if (CONFIG_IS_ENABLED(SYS_MALLOC_DEFAULT_TO_INIT))
+if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT))
malloc_init();
debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
@@ -2151,7 +2153,10 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
elem_size;
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
- INTERNAL_SIZE_T oldtopsize = chunksize(top);
+ INTERNAL_SIZE_T oldtopsize;
+ if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
+ !(gd->flags & GD_FLG_FULL_MALLOC_INIT))
+oldtopsize = chunksize(top);
malloc_simple needs a value for oldtopsize and this is before
GD_FLG_FULL_MALLOC_INIT is set.
This change worked for me:
#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
#if MORECORE_CLEARS
mchunkptr oldtop = top;
if (CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
!(gd->flags & GD_FLG_FULL_MALLOC_INIT))
malloc_init();
INTERNAL_SIZE_T oldtopsize = chunksize(top);
#endif
#endif
You don't want to call malloc_init() twice. So some flag should be added
indicating if malloc_init() has been invoked.
Actually, I think the original condition was just backwards. It should
be
if (!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT) &&
(gd->flags & GD_FLG_FULL_MALLOC_INIT))
although this still doesn't match the malloc_simple condition. So maybe
the condition to remove the initialization should be
#if !CONFIG_VAL(SYS_MALLOC_F_LEN) && \
!CONFIG_IS_ENABLED(SYS_MALLOC_RUNTIME_INIT)
or perhaps RUNTIME_INIT should depend on F_LEN? I don't see anyone using
for other purposes, so I think adding this dependency should be fine.
--Sean
Re: Please pull u-boot-video
On Tue, Aug 01, 2023 at 02:52:55PM +0200, Anatolij Gustschin wrote: > Hi Tom, > > please pull new video patches for v2023.10. > > CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/17167 > > Thanks, > Anatolij > > The following changes since commit 4e619e8d4fd68095bc665a78f2651d8e478a4534: > > Merge tag 'u-boot-rockchip-20230731' of > https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-07-31 11:33:51 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-video.git > tags/video-20230801 > > for you to fetch changes up to b8d3a6c7d12fc6101f99cde0acedb4a799fdb5f3: > > drivers: video: tidss: tidss_drv: Use kconfig VIDEO_REMOVE to remove video > (2023-08-01 13:41:02 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/master
On Tue, Aug 01, 2023 at 11:17:16AM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the following, partly Marvell MVEBU related patches into > master: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Please pull u-boot-x86
Hi Tom, CI: https://source.denx.de/u-boot/custodians/u-boot-x86/-/pipelines/17161 The following changes since commit 4e619e8d4fd68095bc665a78f2651d8e478a4534: Merge tag 'u-boot-rockchip-20230731' of https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-07-31 11:33:51 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-x86.git tags/x86-pull-20230801 for you to fetch changes up to db971a7587d04b3f1cf2e6d452f9e37f50c5b3ed: x86: Add a little more info to cbsysinfo (2023-08-01 10:08:49 +0800) - MTRR fixes for x86 boards - Add a little more info to 'cbsysinfo' command Bin Meng (5): x86: Change testing logic of mtrr commit x86: fsp: Use mtrr_set_next_var() for graphics memory video: broadwell: Use mtrr_set_next_var() for graphics memory video: ivybridge: Use mtrr_set_next_var() for graphics memory video: vesa: Use mtrr_set_next_var() for graphics memory Simon Glass (2): x86: Return mtrr_add_request() to its old purpose x86: Add a little more info to cbsysinfo arch/x86/cpu/mtrr.c| 6 +- arch/x86/include/asm/cb_sysinfo.h | 4 arch/x86/lib/coreboot/cb_sysinfo.c | 4 arch/x86/lib/fsp/fsp_graphics.c| 3 +-- arch/x86/lib/init_helpers.c| 6 ++ cmd/x86/cbsysinfo.c| 5 +++-- drivers/video/broadwell_igd.c | 10 +++--- drivers/video/ivybridge_igd.c | 3 +-- drivers/video/vesa.c | 3 +-- 9 files changed, 24 insertions(+), 20 deletions(-) Regards, Bin
Re: [PATCH 3/3] malloc: Enable SYS_MALLOC_RUNTIME_INIT by default in SPL
On Mon, Jul 31, 2023 at 06:33:27PM -0400, Sean Anderson wrote: > On boards with size restrictions, 1-2k can be a significant fraction of > the binary size. Add a new SPL version of SYS_MALLOC_RUNTIME_INIT and > enable it by default. > > Signed-off-by: Sean Anderson > --- > > Kconfig | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/Kconfig b/Kconfig > index 4b32286b69..3cb31a9346 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -381,6 +381,17 @@ config SYS_MALLOC_RUNTIME_INIT > reduce the size of U-Boot by letting malloc's data reside in .bss > instead of .data. > > +config SPL_SYS_MALLOC_RUNTIME_INIT > + bool "Initialize malloc's internal data at runtime in SPL" > + default y > + depends on SPL > + help > + Initialize malloc's internal data structures at SPL runtime, rather > + than at compile-time. This is necessary if relocating the malloc arena > + from a smaller static memory to a large DDR memory. It can also reduce > + the size of U-Boot by letting malloc's data reside in .bss instead of > + .data. > + > config TOOLS_DEBUG > bool "Enable debug information for tools" > help Can you use something like grabserial (or other tooling) to quantify the change on a platform or two? -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] common: fix detection of SYS_MALLOC_F_LEN=0x0
On Tue, Aug 01, 2023 at 03:33:41PM +0200, Heinrich Schuchardt wrote:
> CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN is defined as hex. If set to zero
> manually, .config contains '0x0' and not '0' as value.
>
> The default value for CONFIG_SPL_SYS_MALLOC_F_LEN should not be set to 0
> but to 0x0 if CONFIG_SPL_FRAMEWORK=n to match a manually set value.
>
> Fixes: c0126bd862a0 ("spl: Support bootstage, log, hash and early malloc in
> TPL")
> Fixes: b61694705217 ("SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without
> SPL_FRAMEWORK by default")
> Signed-off-by: Heinrich Schuchardt
Reviewed-by: Tom Rini
And I see a number of other cases where a "hex" option has a default of
"0" and not "0x0" so I'll have a patch soon.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
On Tue, Aug 01, 2023 at 11:24:46AM +0300, Ilias Apalodimas wrote: > Hi Abdellatif > > On Mon, 31 Jul 2023 at 14:46, Abdellatif El Khlifi > wrote: > > > > Hi Ilias, > > > > On Mon, Jul 31, 2023 at 12:38:16PM +0300, Ilias Apalodimas wrote: > > > > > > > ... > > > > > > > Changelog: > > > > > > > === > > > > > > > > > > > > > > v17: > > > > > > > > > > > > > > * show a debug message rather than an error when FF-A is not > > > > > > > detected > > > > > > [snip] > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > index c5835e6ef6..8fbadb9201 100644 > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > > > > > > > > > config EFI_MM_COMM_TEE > > > > > > > - bool "UEFI variables storage service via OP-TEE" > > > > > > > - depends on OPTEE > > > > > > > + bool "UEFI variables storage service via the trusted world" > > > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > > > > > > > You didn't get my changes in here however. If you can do > > > > > > EFI_MM_COMM_TEE > > > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) > > > > > > then > > > > > > you don't make this option depend on . If FF-A is only > > > > > > for use here, you make FF-A depend on this, and the FF-A specific > > > > > > variable depend on ARM_FFA_TRANSPORT. > > > > > > > > > > Abdellatif hinted at what's going on here. When I added this Kconfig > > > > > option to lx2160 FF-A wasn't implemented yet. > > > > > > > > The defconfig has existed since May 2020, which is when you added > > > > EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I > > > > did until now and saw this series was disabling what was on the other > > > > platform. > > > > > > > > > Since FF-A isn't a new > > > > > communication mechanism but builds upon the existing SMCs to build an > > > > > easier API, I asked Abdellatif to hide this complexity. > > > > > We had two options, either make Kconfig options for either FF-A or the > > > > > traditional SMCs and remove the dependencies, or piggyback on FF-As > > > > > discovery mechanism and make the choice at runtime. The latter has a > > > > > small impact on code size, but imho makes developers' life a lot > > > > > easier. > > > > > > > > I'm not sure how much you can do a run-time option here since you're > > > > setting a bunch of default values for FF-A to 0 in Kconfig. If we're > > > > supposed to be able to get them at run time, we shouldn't need a Kconfig > > > > option at all. I'm also not sure how valid a use case it is where we > > > > won't know at build time what the rest of the firmware stack supports > > > > here. > > > > > > > > > > That's a fair point. FF-A in theory has APIs to discover memory. > > > Abdellatif, why do we need the Kconfigs for shared memory on FF-A? > > > > The statically carved out MM shared buffer address, size and offset cannot > > be discovered by FF-A ABIs. > > The MM communication driver in U-Boot could allocate the buffer and share > > it with the MM SP but > > we do not implement that support currently in either U-Boot or UEFI. > > Ok, that's a bit unfortunate, but Tom is right. Having the FF-A > addresses show up is as confusing as having Kconfig options for > discrete options. The whole point of my suggestion was to make users' > lives easier. Apologies for the confusion but can you bring back the > ifdefs? Looking at the patch this should be minimal just use > ifdef ARM_FFA_TRANSPORT and ifndef ARM_FFA_TRANSPORT. > > Tom you prefer that as well? Pending an answer to Jens' feedback, yes, going back to #ifdef's is fine, especially since default values of 0 are nonsense in this case (and as Heinrich's patch re SYS_MALLOC_LEN shows, dangerous since 0 != 0x0 once we do string comparisons). -- Tom signature.asc Description: PGP signature
[RFC PATCH] env: Export environment config to OS devicetree
From: Frieder Schrempf
There are plenty of cases where the OS wants to know where the
persistent environment is stored in order to print or manipulate it.
In most cases a userspace tool like libubootenv [1] is used to handle
the environment. It uses hardcoded settings in a config file in the
rootfs to determine the exact location of the environment.
In order to make systems more flexible and let userspace tools
detect the location of the environment currently in use, let's
add an option to export the runtime configuration to the FDT passed
to the OS.
This is especially useful when your device is able to use multiple
locations for the environment and the rootfs containing the
fw_env.config file should be kept universal.
Currently the general information like location/type, size, offset
and redundancy are exported. Userspace tools might already be able
to guess the correct device to access based on this information.
For further device-specific information two additional properties
'id1' and 'id2' are used. The current implementation uses them for
MMC and SPI FLASH like this:
| Type | id1| id2|
| -- | -- | -- |
| MMC| MMC device index in U-Boot | MMC hwpart index in U-Boot |
| SPI FLASH | SPI bus index in U-Boot| SPI CS index in U-Boot |
Further extensions for other environment devices are possible.
We add the necessary information to the '/chosen' node. The following
shows two examples:
Redundant environment in MMC:
/chosen {
u-boot,env-config {
location = <5>; # according to 'enum env_location'
offset = <0x1E>;
size = <0x10>;
sect_size = <0x10>;
id1 = <1>; # MMC device index
id2 = <0>; # MMC HW partition index
};
u-boot,env-redund-config {
offset = <0x1F>;
};
};
Redundant environment in SPI NOR:
/chosen {
u-boot,env-config {
location = <10>; # according to 'enum env_location'
offset = <0x1E>;
size = <0x10>;
sect_size = <0x10>;
id1 = <0>; # SPI bus
id2 = <0>; # SPI CS
};
u-boot,env-redund-config {
offset = <0x1F>;
};
};
See [2] for an example parser implementation for libubootenv.
[1] https://github.com/sbabic/libubootenv
[2]
https://github.com/fschrempf/libubootenv/commit/726a7ac9b1b1020354ee8fe750f4cad3df01f5e7
Cc: Stefano Babic
Cc: Michael Walle
Signed-off-by: Frieder Schrempf
---
boot/Kconfig | 9
boot/image-fdt.c | 8
env/env.c| 53
include/env.h| 4
4 files changed, 74 insertions(+)
diff --git a/boot/Kconfig b/boot/Kconfig
index e8fb03b801..16a94f9b35 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -702,6 +702,15 @@ config OF_BOARD_SETUP
board-specific information in the device tree for use by the OS.
The device tree is then passed to the OS.
+config OF_EXPORT_ENV_CONFIG
+ bool "Export environment config to device tree before boot"
+ depends on OF_LIBFDT
+ help
+ This causes U-Boot to call fdt_environment_config() before booting
into
+ the operating system. This function exports the currently in use
+ environemnt configuration to the "chosen" node of the fdt. This allows
+ the OS to determine where the environment is located.
+
config OF_SYSTEM_SETUP
bool "Set up system-specific details in device tree before boot"
depends on OF_LIBFDT
diff --git a/boot/image-fdt.c b/boot/image-fdt.c
index f10200f647..c02c8f33ef 100644
--- a/boot/image-fdt.c
+++ b/boot/image-fdt.c
@@ -643,6 +643,14 @@ int image_setup_libfdt(struct bootm_headers *images, void
*blob,
/* Append PStore configuration */
fdt_fixup_pstore(blob);
#endif
+ if (IS_ENABLED(CONFIG_OF_EXPORT_ENV_CONFIG)) {
+ fdt_ret = fdt_environment_config(blob);
+ if (fdt_ret) {
+ printf("ERROR: environment config fdt fixup failed:
%s\n",
+ fdt_strerror(fdt_ret));
+ goto err;
+ }
+ }
if (IS_ENABLED(CONFIG_OF_BOARD_SETUP)) {
const char *skip_board_fixup;
diff --git a/env/env.c b/env/env.c
index 2aa52c98f8..a640977205 100644
--- a/env/env.c
+++ b/env/env.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -156,6 +157,58 @@ __weak enum env_location env_get_location(enum
env_operation op, int prio)
return arch_env_get_location(op, prio);
}
+#ifdef CONFIG_OF_EXPORT_ENV_CONFIG
+int fdt_environment_config(void *blob)
+{
+ struct mmc *mmc;
+ u32 location;
+ int chosen_offs, offs;
+ int ret;
+
+ if (CONFIG_IS_ENABLED(ENV_IS_NOWHERE))
+
Re: [PATCH v3 5/9] board_f: Fix corruption of relocaddr
Hi Tom, Simon,
Thanks for sharing all the information.
On 01/08/23 02:39, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 31 Jul 2023 at 15:06, Tom Rini wrote:
>>
>> On Mon, Jul 31, 2023 at 02:49:06PM -0600, Simon Glass wrote:
>>> Hi Tom,
>>>
>>> On Mon, 31 Jul 2023 at 14:45, Tom Rini wrote:
On Mon, Jul 31, 2023 at 02:37:04PM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Mon, 31 Jul 2023 at 13:32, Tom Rini wrote:
>>
>> On Mon, Jul 31, 2023 at 09:59:56AM -0600, Simon Glass wrote:
>>
>>> When the video framebuffer comes from the bloblist, we should not change
>>> relocaddr to this address, since it interfers with the normal memory
>>> allocation.
>>>
>>> This fixes a boot loop in qemu-x86_64
>>>
>>> Signed-off-by: Simon Glass
>>> Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from SPL
>>> to u-boot")
>>> Suggested-by: Nikhil M Jain
>>> ---
>>>
>>> Changes in v3:
>>> - Reword the Kconfig help as suggested
>>>
>>> Changes in v2:
>>> - Add a Kconfig as the suggested conditional did not work
>>>
>>> common/board_f.c | 3 ++-
>>> drivers/video/Kconfig | 9 +
>>> 2 files changed, 11 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/common/board_f.c b/common/board_f.c
>>> index 7d2c380e91e..5173d0a0c2d 100644
>>> --- a/common/board_f.c
>>> +++ b/common/board_f.c
>>> @@ -419,7 +419,8 @@ static int reserve_video(void)
>>> if (!ho)
>>> return log_msg_ret("blf", -ENOENT);
>>> video_reserve_from_bloblist(ho);
>>> - gd->relocaddr = ho->fb;
>>> + if (IS_ENABLED(CONFIG_VIDEO_RESERVE_SPL))
>>> + gd->relocaddr = ho->fb;
>>> } else if (CONFIG_IS_ENABLED(VIDEO)) {
>>> ulong addr;
>>> int ret;
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index b41dc60cec5..f2e56204d52 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -1106,6 +1106,15 @@ config SPL_VIDEO_REMOVE
>>> if this option is enabled video driver will be removed at the
>>> end of
>>> SPL stage, beforeloading the next stage.
>>>
>>> +config VIDEO_RESERVE_SPL
>>> + bool
>>> + help
>>> + This adjusts reserve_video() to redirect memory reservation
>>> when it
>>> + sees a video handoff blob (BLOBLISTT_U_BOOT_VIDEO). This avoids
>>> the
>>> + memory used for framebuffer from being allocated by U-Boot
>>> proper,
>>> + thus preventing any further memory reservations done by U-Boot
>>> proper
>>> + from overwriting the framebuffer.
>>> +
>>> if SPL_SPLASH_SCREEN
>>>
>>> config SPL_SPLASH_SCREEN_ALIGN
>>
>> Nothing selects this and it's not offered as a choice, so now we've just
>> broken the original case?
>
> Yes, I should have mentioned that. I'm not sure which board(s) need
> this option selected.
>
> Devarsh, do you know?
And shouldn't this just be part of the normal flow when we have
SPL_BLOBLIST && BLOBLIST, and not need a new symbol? I feel like I'm
missing something here.
>>>
>>> Most of the discussion was on the v1 patch.
>>>
>>> https://patchwork.ozlabs.org/project/uboot/patch/20230724145210.304917-5-...@chromium.org/
>>
>> OK, yeah. It seems like something more needs to be done then since
>> "don't flicker the screen" is pretty much always the case if we have
>> splash screen / video set up in SPL. Perhaps the case where that's not
>> true should just be treated as the uncommon one, so we can do the
>> ram_top suggestion normally?
>
The gd->relocaddr points to ram_top at the start and framebuffer is not the
first region, I think TLB table is reserved first and then the framebuffer, so
I am not sure if it is good idea to move ram_top since old ram_top is already
used for reserving page table.
As per my opinion
https://patchwork.ozlabs.org/project/uboot/patch/20230801140414.76216-1-devar...@ti.com/
should suffice to fix this issue ?
Simon,
Could you please try with above patch once? ?
In your case ,
gd->relocaddr=c000, ho->fb=d000
so the relocaddr is already below the framebuffer so condition won't hold true
and relocaddr won't get updated.
> Yes I think that would be best. Also the video info needs to be fully
> filled out to fix the x86 problem.
>
Sorry I didn't get this, As i understand by the time video_reserve is called
only driver is bound but not yet probed and I think below fields are only
filled after driver is probed, this for most video drivers as I see.
u32 size;
u16 xsize;
u16 ysize;
u32 line_length;
So all these fields are zero in the handoff structure.
Kindly let me know if any queries or issues faced.
Regards
Re: [PATCH] arm: moxa: add nport6600 platform
On Tue, Aug 01, 2023 at 01:11:28PM +0300, Sergei Antonov wrote: > On Mon, 31 Jul 2023 at 21:59, Tom Rini wrote: > > > > On Mon, Jul 31, 2023 at 09:43:29PM +0300, Sergei Antonov wrote: > > > > > Support for NPort 6600 Series RS-232/422/485 secure terminal servers. > > > > > > Technical specifications: > > > FA526 ARMv4 CPU, 64 MB of RAM, 16 MB NOR flash, 100 Mbit/s Ethernet, > > > optional expansion modules, up to 32 RS-232/422/485 ports. > > > > > > Signed-off-by: Sergei Antonov > > > --- > > > arch/arm/Kconfig | 9 +++ > > > arch/arm/dts/nport6600.dts | 134 +++ > > > > Where does the device tree come from? > > From the datasheet, testing, and a similar dts in Linux: > https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts/moxa It needs to be the same dts as in Linux, and re-synced periodically. The -u-boot.dtsi file can be used for changes that are still being staged to Linux, but shouldn't be used indefinitely. > > > diff --git a/board/moxa/nport6600/nport6600.c > > > b/board/moxa/nport6600/nport6600.c > > > new file mode 100644 > > > index ..88fa98c315fd > > > --- /dev/null > > > +++ b/board/moxa/nport6600/nport6600.c > > > @@ -0,0 +1,78 @@ > > > +// SPDX-License-Identifier: GPL-2.0-or-later > > > + > > > +#include > > OK. Compiles without it. > > > New files must not add common.h > > > > > diff --git a/include/configs/nport6600.h b/include/configs/nport6600.h > > > new file mode 100644 > > > index ..c70cc7e1ac72 > > > --- /dev/null > > > +++ b/include/configs/nport6600.h > > [snip] > > > +#define __io > > > > What's this for? > > Removing it leads to warnings: > > .../u-boot/drivers/serial/ns16550.c: In function ‘serial_out_dynamic’: > .../u-boot/drivers/serial/ns16550.c:111:17: warning: implicit > declaration of function ‘outb’ [-Wimplicit-function-declaration] > 111 | outb(value, addr); > | ^~~~ > .../u-boot/drivers/serial/ns16550.c: In function ‘serial_in_dynamic’: > .../u-boot/drivers/serial/ns16550.c:131:24: warning: implicit > declaration of function ‘inb’; did you mean ‘isb’? > [-Wimplicit-function-declaration] > 131 | return inb(addr); > |^~~ > |isb > > and then linking errors: > > .../armv4/lib/gcc/armv4-linux-gnueabi/13.0.1/../../../../armv4-linux-gnueabi/bin/ld: > /tmp/ccIta0uJ.ltrans12.ltrans.o: in function `ns16550_writeb.isra.0': > .../u-boot/drivers/serial/ns16550.c:111: undefined reference to `outb' > .../armv4/lib/gcc/armv4-linux-gnueabi/13.0.1/../../../../armv4-linux-gnueabi/bin/ld: > /tmp/ccIta0uJ.ltrans12.ltrans.o: in function `ns16550_readb.isra.0': > .../u-boot/drivers/serial/ns16550.c:131: undefined reference to `inb' Oh, you need to be enabling CONFIG_DM_SERIAL. -- Tom signature.asc Description: PGP signature
Re: Re: [PATCH] rockchip: rk3399: nanopc-t4: use 1600MHz sdram config
> Does the 1866M worked for your board before? 1866M ddr blobs from rkbin works fine on my board, but TPL works bad every time. I have never encountered an exception of this result. > I think this config should be fine for other people, it has been > submit for 4 years. For another tester, this config works fine. But I think the individual difference of this board or different board revision leads to the result. Maybe it is better to lower the frequency to ensure more people can use TPL without problems.
Re: [PATCH 0/4] imx93: add DWC EQoS MAC driver support
Hi Sébastien, On Thu, Jul 27, 2023 at 5:33 AM Sébastien Szymanski wrote: > > This series makes the DWC EQos MAC work on i.MX93. > It depends on the i.MX93 CCF driver: > https://lore.kernel.org/u-boot/20230725080856.26567-1-sebastien.szyman...@armadeus.com/ > > Tested on i.MX93 EVK board: > u-boot=> dhcp > ethernet@428a Waiting for PHY auto negotiation to complete done > BOOTP broadcast 1 > *** Unhandled DHCP Option in OFFER/ACK: 125 > *** Unhandled DHCP Option in OFFER/ACK: 125 > DHCP client bound to address 192.168.1.50 (35 ms) > > u-boot=> ping 192.168.1.51 > Using ethernet@428a device > host 192.168.1.51 is alive > u-boot=> Thanks for the series: Reviewed-by: Fabio Estevam
[PATCH] common: board_f: Move relocation address after framebuffer
When passing framebuffer address using bloblist, check
that passed address is overlapping with current relocation
address, if so move the relocation address after the framebuffer
region to avoid overlap.
Fixes: 5bc610a7d9d ("common: board_f: Pass frame buffer info from
SPL to u-boot")
Signed-off-by: Devarsh Thakkar
---
common/board_f.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 7d2c380e91..20fa17207a 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -419,7 +419,10 @@ static int reserve_video(void)
if (!ho)
return log_msg_ret("blf", -ENOENT);
video_reserve_from_bloblist(ho);
- gd->relocaddr = ho->fb;
+ /* Relocate after framebuffer area to avoid overlap */
+ if (gd->relocaddr > (unsigned long)ho->fb)
+ gd->relocaddr = ho->fb;
+
} else if (CONFIG_IS_ENABLED(VIDEO)) {
ulong addr;
int ret;
--
2.34.1
Re: [PATCH v4 32/45] fs: fat: Support reading from a larger block size
Hi Simon, On Tue, Aug 1, 2023 at 9:26 PM Simon Glass wrote: > > Hi Bin, > > On Mon, 31 Jul 2023 at 04:54, Bin Meng wrote: > > > > On Mon, Jul 31, 2023 at 6:33 PM Bin Meng wrote: > > > > > > Hi Simon, > > > > > > On Fri, Jul 28, 2023 at 7:56 AM Simon Glass wrote: > > > > > > > > Hi Bin, > > > > > > > > On Wed, 19 Jul 2023 at 01:58, Bin Meng wrote: > > > > > > > > > > Hi Simon, > > > > > > > > > > On Wed, Jul 19, 2023 at 9:11 AM Simon Glass wrote: > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > On Sun, 16 Jul 2023 at 09:19, Bin Meng wrote: > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > On Sun, Jul 16, 2023 at 7:42 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > > > On Thu, 13 Jul 2023 at 04:49, Bin Meng > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > > > On Mon, Jun 19, 2023 at 8:02 PM Simon Glass > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > At present it is not possible to read from some CDROM > > > > > > > > > > drives since the > > > > > > > > > > FAT sector size does not match the media's block size. Add > > > > > > > > > > a conversion > > > > > > > > > > option for this, so that reading is possible. > > > > > > > > > > > > > > > > > > I am completely confused. The CDROM uses iso9660 file system. > > > > > > > > > This has > > > > > > > > > nothing to do with FAT. > > > > > > > > > > > > > > > > It actually can use both - this is the -cdrom option in QEMU > > > > > > > > which can > > > > > > > > emulate an old-style CDROM, with a FAT filesystem on it! > > > > > > > > > > > > > > > > > > > > > > What QEMU command line is this to enable a CDROM with FAT file > > > > > > > system? > > > > > > > > > > > > > > If that is the case, what you changed in this commit only works > > > > > > > with > > > > > > > QEMU, not with any real-world devices, I believe? > > > > > > > > > > > > > > Could you use iso9660 instead? > > > > > > > > > > > > Sure, but the image I am using has an MSDOS partition name, an EFI > > > > > > partition table, a FAT filesystem and an ISO9660 filesystem! I was > > > > > > trying to look at the FAT filesystem via the MSDOS partition table. > > > > > > > > > > > > > > > > Is that a released installer iso that I can download somewhere? > > > > > > > > > > Which QEMU command line should I use for reproducing the issue? > > > > > > > > Here is what I did: > > > > > > > > qemu-system-x86_64 -m 2G -smp 4 -bios /tmp/b/qemu-x86/u-boot.rom > > > > -cdrom /vid/software/linux/debian/debian-11.5.0-i386-DVD-1.iso -serial > > > > mon:stdio > > > > => part set ide 2 iso > > > > > > > > Partition Map for IDE device 2 -- Partition Type: ISO > > > > > > > > Part Start Sect x Size Type > > > > 1 69121 2048 U-Boot > > > > 2 5912 1000 2048 U-Boot > > > > => ls ide 2:2 > > > > FAT sector size mismatch (fs=512, dev=2048): translating for read-only > > > > efi/ > > > > 160 ubootefi.var > > > > > > > > 1 file(s), 1 dir(s) > > > > > > > > => > > > > > > > > Without this patch we cannot enable translation and it is not possible > > > > to read the files. > > > > > > I cannot reproduce this issue. > > > > > > I investigated this a little bit, and it looks the iso image you are > > > using is of the so-called "isohybrid" [1] type. Almost all recent > > > Linux distros release their CDs using the isohyrbrid format. > > > > > > So with isohybrid I think you can directly boot this using the "-drive > > > file=xxx.iso,if=virtio" without this patch, no? > > Yes, that's right. > > > > > > > [1] https://wiki.syslinux.org/wiki/index.php?title=Isohybrid > > > > > > > I don't think QEMU's -cdrom should work with the isohybrid format > > images. The isohybrid image is a hack, according to the Rufus author > > [1]. > > > > The isohybrid images are nothing different from the normal harddisk > > images, so it should only work with the disk controllers that expect > > the 512 byte sector size. > > > > The -cdrom should work with the original iso image, for example, > > distros 10 years ago, like Ubuntu 10.04 [2] > > > > [1] https://superuser.com/a/1527373/241386 > > [2] > > https://old-releases.ubuntu.com/releases/10.04.0/ubuntu-10.04-desktop-amd64.iso > > I think this patch is needed when virtio is not used, but for virtio > it is not needed. For other block interfaces like if=nvme, if=sd, they are not needed too. As I said in the comments, only -cdrom needs this patch to work with IsoHybrid images, but I don't think that's a valid use case. Regards, Bin
Re: [PATCH 00/18] video: bochs: Remove the x86 limitation
On Tue, Aug 1, 2023 at 9:03 PM Anatolij Gustschin wrote: > > Hi Bin, > > On Mon, 31 Jul 2023 13:26:23 +0800 > Bin Meng bmeng...@gmail.com wrote: > ... > > Looks the first half is assigned to Anatolij and the second half to Rick. > > > > I guess the first half should go first. > > > > Ping for apply? > > I've applied patches 1/18 to 9/18 now, a pull request is pending. > Thank you Anatolij. Regards, Bin
[PATCH 1/1] common: fix detection of SYS_MALLOC_F_LEN=0x0
CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN is defined as hex. If set to zero
manually, .config contains '0x0' and not '0' as value.
The default value for CONFIG_SPL_SYS_MALLOC_F_LEN should not be set to 0
but to 0x0 if CONFIG_SPL_FRAMEWORK=n to match a manually set value.
Fixes: c0126bd862a0 ("spl: Support bootstage, log, hash and early malloc in
TPL")
Fixes: b61694705217 ("SPL: Do not enable SPL_SYS_MALLOC_SIMPLE without
SPL_FRAMEWORK by default")
Signed-off-by: Heinrich Schuchardt
---
Kconfig | 2 +-
common/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Kconfig b/Kconfig
index 70efb41cc6..91170bf8d2 100644
--- a/Kconfig
+++ b/Kconfig
@@ -298,7 +298,7 @@ config SYS_MALLOC_LEN
config SPL_SYS_MALLOC_F_LEN
hex "Size of malloc() pool in SPL"
depends on SYS_MALLOC_F && SPL
- default 0 if !SPL_FRAMEWORK
+ default 0x0 if !SPL_FRAMEWORK
default 0x2800 if RCAR_GEN3
default 0x2000 if IMX8MQ
default SYS_MALLOC_F_LEN
diff --git a/common/Makefile b/common/Makefile
index c87bb2e78b..f5c3d90f06 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -79,7 +79,7 @@ endif # CONFIG_SPL_BUILD
obj-$(CONFIG_CROS_EC) += cros_ec.o
obj-y += dlmalloc.o
ifdef CONFIG_SYS_MALLOC_F
-ifneq ($(CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN),0)
+ifneq ($(CONFIG_$(SPL_TPL_)SYS_MALLOC_F_LEN),0x0)
obj-y += malloc_simple.o
endif
endif
--
2.40.1
Re: [PATCH v4 32/45] fs: fat: Support reading from a larger block size
Hi Bin, On Mon, 31 Jul 2023 at 04:54, Bin Meng wrote: > > On Mon, Jul 31, 2023 at 6:33 PM Bin Meng wrote: > > > > Hi Simon, > > > > On Fri, Jul 28, 2023 at 7:56 AM Simon Glass wrote: > > > > > > Hi Bin, > > > > > > On Wed, 19 Jul 2023 at 01:58, Bin Meng wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, Jul 19, 2023 at 9:11 AM Simon Glass wrote: > > > > > > > > > > Hi Bin, > > > > > > > > > > On Sun, 16 Jul 2023 at 09:19, Bin Meng wrote: > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > On Sun, Jul 16, 2023 at 7:42 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Hi Bin, > > > > > > > > > > > > > > On Thu, 13 Jul 2023 at 04:49, Bin Meng wrote: > > > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > > > On Mon, Jun 19, 2023 at 8:02 PM Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > At present it is not possible to read from some CDROM drives > > > > > > > > > since the > > > > > > > > > FAT sector size does not match the media's block size. Add a > > > > > > > > > conversion > > > > > > > > > option for this, so that reading is possible. > > > > > > > > > > > > > > > > I am completely confused. The CDROM uses iso9660 file system. > > > > > > > > This has > > > > > > > > nothing to do with FAT. > > > > > > > > > > > > > > It actually can use both - this is the -cdrom option in QEMU > > > > > > > which can > > > > > > > emulate an old-style CDROM, with a FAT filesystem on it! > > > > > > > > > > > > > > > > > > > What QEMU command line is this to enable a CDROM with FAT file > > > > > > system? > > > > > > > > > > > > If that is the case, what you changed in this commit only works with > > > > > > QEMU, not with any real-world devices, I believe? > > > > > > > > > > > > Could you use iso9660 instead? > > > > > > > > > > Sure, but the image I am using has an MSDOS partition name, an EFI > > > > > partition table, a FAT filesystem and an ISO9660 filesystem! I was > > > > > trying to look at the FAT filesystem via the MSDOS partition table. > > > > > > > > > > > > > Is that a released installer iso that I can download somewhere? > > > > > > > > Which QEMU command line should I use for reproducing the issue? > > > > > > Here is what I did: > > > > > > qemu-system-x86_64 -m 2G -smp 4 -bios /tmp/b/qemu-x86/u-boot.rom > > > -cdrom /vid/software/linux/debian/debian-11.5.0-i386-DVD-1.iso -serial > > > mon:stdio > > > => part set ide 2 iso > > > > > > Partition Map for IDE device 2 -- Partition Type: ISO > > > > > > Part Start Sect x Size Type > > > 1 69121 2048 U-Boot > > > 2 5912 1000 2048 U-Boot > > > => ls ide 2:2 > > > FAT sector size mismatch (fs=512, dev=2048): translating for read-only > > > efi/ > > > 160 ubootefi.var > > > > > > 1 file(s), 1 dir(s) > > > > > > => > > > > > > Without this patch we cannot enable translation and it is not possible > > > to read the files. > > > > I cannot reproduce this issue. > > > > I investigated this a little bit, and it looks the iso image you are > > using is of the so-called "isohybrid" [1] type. Almost all recent > > Linux distros release their CDs using the isohyrbrid format. > > > > So with isohybrid I think you can directly boot this using the "-drive > > file=xxx.iso,if=virtio" without this patch, no? Yes, that's right. > > > > [1] https://wiki.syslinux.org/wiki/index.php?title=Isohybrid > > > > I don't think QEMU's -cdrom should work with the isohybrid format > images. The isohybrid image is a hack, according to the Rufus author > [1]. > > The isohybrid images are nothing different from the normal harddisk > images, so it should only work with the disk controllers that expect > the 512 byte sector size. > > The -cdrom should work with the original iso image, for example, > distros 10 years ago, like Ubuntu 10.04 [2] > > [1] https://superuser.com/a/1527373/241386 > [2] > https://old-releases.ubuntu.com/releases/10.04.0/ubuntu-10.04-desktop-amd64.iso I think this patch is needed when virtio is not used, but for virtio it is not needed. Regards, Simon
Re: [PATCH] event: Fix an wrong type_name from dm_post_init to dm_post_init_f
On Tue, 1 Aug 2023 at 04:17, Jaehoon Chung wrote: > > DM_POST_INIT was changed to DM_POST_INIT_F. > To debug correct message, change type_name from dm_post_init to > dm_post_init_f. > > Signed-off-by: Jaehoon Chung > --- > common/event.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Reviewed-by: Simon Glass
Re: [PATCH v2 0/2] arm: dts: k3-am6: Sync DT with Linux
On 01/08/2023 15:37, Nishanth Menon wrote: > On 15:27-20230731, Roger Quadros wrote: >> Hi, >> >> This series syncs AM64 DT files from Linux v6.5-rc1. >> >> NOTE: I have only boot tested this on AM64-GP-EVM. >> I would appreciate a tested-by for AM64-sk EVM. Thanks. >> >> cheers, >> -roger >> >> Changelog: >> >> v2: >> - Sync with v6.5-rc1 >> - Rebase on latest uboot/master >> - CPSW node cleanup >> - Timer node cleanup >> >> Roger Quadros (2): >> board: ti: am64x: Recognize AM64-HSEVM >> arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 >> >> arch/arm/dts/k3-am64-main.dtsi| 171 +++-- >> arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- >> arch/arm/dts/k3-am64-thermal.dtsi | 33 + >> arch/arm/dts/k3-am64.dtsi | 22 +--- >> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++- >> arch/arm/dts/k3-am642-evm.dts | 173 -- >> arch/arm/dts/k3-am642-r5-evm.dts | 26 +++- >> arch/arm/dts/k3-am642-r5-sk.dts | 31 - >> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++- >> arch/arm/dts/k3-am642-sk.dts | 166 +--- >> arch/arm/dts/k3-am642.dtsi| 1 + >> board/ti/am64x/evm.c | 3 +- >> 12 files changed, 589 insertions(+), 175 deletions(-) >> create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi >> >> -- >> 2.34.1 >> > Could you also add documentation for u-boot (doc/board/ti/) > https://github.com/nmenon/fix-k3-dt-u-boot/commit/840ad0f07d6028e3758650f6d3d0d468438910ce > Yes, and will resolve all your comments on this series. Thanks. -- cheers, -roger
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
Hi Sughosh, On Tue, 1 Aug 2023 at 06:29, Sughosh Ganu wrote: > > hi Simon, > > On Wed, 26 Jul 2023 at 04:06, Simon Glass wrote: > > > > Hi Sughosh, > > > > On Thu, 20 Jul 2023 at 03:20, Sughosh Ganu wrote: > > > > > > hi Simon, > > > > > > On Thu, 20 Jul 2023 at 00:41, Simon Glass wrote: > > > > > > > > Hi Sughosh, > > > > > > > > On Wed, 19 Jul 2023 at 02:42, Sughosh Ganu > > > > wrote: > > > > > > > > > > hi Simon, > > > > > > > > > > On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu > > > > > > wrote: > > > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Add support in binman for generating capsules. The capsule > > > > > > > > > parameters > > > > > > > > > can be specified either through a config file or through the > > > > > > > > > capsule > > > > > > > > > binman entry. Also add test cases in binman for capsule > > > > > > > > > generation, > > > > > > > > > and enable this testing on the sandbox_spl variant. > > > > > > > > > > > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is > > > > > > > > really for > > > > > > > > SPL testing. > > > > > > > > > > > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > > --- > > > > > > > > > Changes since V3: > > > > > > > > > * Add test cases for covering the various capsule generation > > > > > > > > > scenarios. > > > > > > > > > * Add function comments in the mkeficapsule bintool. > > > > > > > > > * Fix the fetch method of the mkeficapsule bintool to enable > > > > > > > > > building > > > > > > > > > the tool. > > > > > > > > > * Add more details about the capsule parameters in the > > > > > > > > > documentation > > > > > > > > > as well as the code. > > > > > > > > > * Fix order of module imports, and addition of blank lines in > > > > > > > > > the > > > > > > > > > capsule.py file. > > > > > > > > > * Use SetContents in the ObtainContents method. > > > > > > > > > > > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > > > > > > tools/binman/btool/mkeficapsule.py| 158 > > > > > > > > > ++ > > > > > > > > > tools/binman/entries.rst | 37 > > > > > > > > > tools/binman/etype/capsule.py | 132 > > > > > > > > > +++ > > > > > > > > > tools/binman/ftest.py | 127 > > > > > > > > > ++ > > > > > > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > > > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > > > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > > > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > > > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > > > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > > > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > > > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > > > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > > > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > > > > > > 15 files changed, 619 insertions(+) > > > > > > > > > create mode 100644 tools/binman/btool/mkeficapsule.py > > > > > > > > > create mode 100644 tools/binman/etype/capsule.py > > > > > > > > > create mode 100644 tools/binman/test/282_capsule.dts > > > > > > > > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > > > > > > > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > > > > > > > > create mode 100644 > > > > > > > > > tools/binman/test/285_capsule_missing_key.dts > > > > > > > > > create mode 100644 > > > > > > > > > tools/binman/test/286_capsule_missing_index.dts > > > > > > > > > create mode 100644 > > > > > > > > > tools/binman/test/287_capsule_missing_guid.dts > > > > > > > > > create mode 100644 > > > > > > > > > tools/binman/test/288_capsule_missing_payload.dts > > > > > > > > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > > > > > > > > create mode 100644 tools/binman/test/290_capsule_version.dts > > > > > > > > > create mode 100644 tools/binman/test/capsule_cfg.txt > > > > > > > > > > > > > > > > This looks pretty good to me. Some nits below > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/configs/sandbox_spl_defconfig > > > > > > > > > b/configs/sandbox_spl_defconfig > > > > > > > > > index dd848c57c6..2fcc789347 100644 > > > > > > > > > --- a/configs/sandbox_spl_defconfig > > > > >
Re: [PATCH v2 2/2] arm: dts: k3-am64: Sync DT with Linux v6.5-rc1
On 15:27-20230731, Roger Quadros wrote:
> Sync all am642-evm/am642-sk related DT files
> with Linux v6.5-rc1.
>
> - drop timer1 in favor of main_timer0 in am64-main.dtsi.
> Need to delete clock & power domain properties of
> main_timer1 in -r5.dts else won't boot.
> - drop cpsw3g custom DT property 'mac_efuse' and custom
> DT node cpsw-phy-sel as driver picks these from standard
> property/node.
>
> Signed-off-by: Roger Quadros
> ---
> arch/arm/dts/k3-am64-main.dtsi| 171 +++--
> arch/arm/dts/k3-am64-mcu.dtsi | 53 +++-
> arch/arm/dts/k3-am64-thermal.dtsi | 33 +
> arch/arm/dts/k3-am64.dtsi | 22 +---
> arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++-
> arch/arm/dts/k3-am642-evm.dts | 173 --
> arch/arm/dts/k3-am642-r5-evm.dts | 26 +++-
> arch/arm/dts/k3-am642-r5-sk.dts | 31 -
> arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++-
> arch/arm/dts/k3-am642-sk.dts | 166 +---
> arch/arm/dts/k3-am642.dtsi| 1 +
> 11 files changed, 587 insertions(+), 174 deletions(-)
> create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi
>
> diff --git a/arch/arm/dts/k3-am64-main.dtsi b/arch/arm/dts/k3-am64-main.dtsi
> index 5e8036f32d..1664d9f024 100644
> --- a/arch/arm/dts/k3-am64-main.dtsi
> +++ b/arch/arm/dts/k3-am64-main.dtsi
> @@ -228,12 +228,161 @@
> };
> };
>
> + main_timer0: timer@240 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x240 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 36 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 36 1>;
> + assigned-clock-parents = <_clks 36 2>;
> + power-domains = <_pds 36 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer1: timer@241 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x241 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 37 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 37 1>;
> + assigned-clock-parents = <_clks 37 2>;
> + power-domains = <_pds 37 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer2: timer@242 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x242 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 38 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 38 1>;
> + assigned-clock-parents = <_clks 38 2>;
> + power-domains = <_pds 38 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer3: timer@243 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x243 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 39 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 39 1>;
> + assigned-clock-parents = <_clks 39 2>;
> + power-domains = <_pds 39 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer4: timer@244 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x244 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 40 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 40 1>;
> + assigned-clock-parents = <_clks 40 2>;
> + power-domains = <_pds 40 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer5: timer@245 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x245 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 41 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 41 1>;
> + assigned-clock-parents = <_clks 41 2>;
> + power-domains = <_pds 41 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer6: timer@246 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x246 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 42 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 42 1>;
> + assigned-clock-parents = <_clks 42 2>;
> + power-domains = <_pds 42 TI_SCI_PD_EXCLUSIVE>;
> + ti,timer-pwm;
> + };
> +
> + main_timer7: timer@247 {
> + compatible = "ti,am654-timer";
> + reg = <0x00 0x247 0x00 0x400>;
> + interrupts = ;
> + clocks = <_clks 43 1>;
> + clock-names = "fck";
> + assigned-clocks = <_clks 43 1>;
> + assigned-clock-parents = <_clks 43 2>;
> +
Re: [PATCH 00/18] video: bochs: Remove the x86 limitation
Hi Bin, On Mon, 31 Jul 2023 13:26:23 +0800 Bin Meng bmeng...@gmail.com wrote: ... > Looks the first half is assigned to Anatolij and the second half to Rick. > > I guess the first half should go first. > > Ping for apply? I've applied patches 1/18 to 9/18 now, a pull request is pending. -- Anatolij
Re: [PATCH 09/18] video: bochs: Set the frame buffer size per configuration
On Sun, 23 Jul 2023 12:40:32 +0800 Bin Meng bm...@tinylab.org wrote: > At present the uclass stored frame buffer size is set to a hard > coded value, but we can calculate the correct value based on what > is configured. > > Signed-off-by: Bin Meng > --- > > drivers/video/bochs.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 08/18] video: kconfig: Set default FB size for Bochs
On Sun, 23 Jul 2023 12:40:31 +0800 Bin Meng bm...@tinylab.org wrote: > Set up a default frame buffer size of 8MiB for Bochs for non-x86 > architecturs as PCI is normally not enumerated before relocation > on these architectures. > > Signed-off-by: Bin Meng > --- > > drivers/video/Kconfig | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 07/18] video: kconfig: Drop the superfluous dependency
On Sun, 23 Jul 2023 12:40:30 +0800 Bin Meng bm...@tinylab.org wrote: > PCI is always selected by X86 architecture hence "X86 && PCI" does > not make it better. > > Signed-off-by: Bin Meng > --- > > drivers/video/Kconfig | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 06/18] video: kconfig: Fix wrong text for the PCI default FB size
On Sun, 23 Jul 2023 12:40:29 +0800 Bin Meng bm...@tinylab.org wrote: > There is an example in the VIDEO_PCI_DEFAULT_FB_SIZE help text to > tell people how to calculate its value but the resolution given > does not match the value. Fix it. > > Signed-off-by: Bin Meng > --- > > drivers/video/Kconfig | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 04/18] video: bochs: Avoid using IO instructions to access VGA IO port
On Sun, 23 Jul 2023 12:40:27 +0800 Bin Meng bm...@tinylab.org wrote: > At present the driver uses IO instructions to access the legacy > VGA IO ports, which unfortunately limits the driver to work only > on x86. It turns out the IO instruction is not necessary as Bochs > VGA card remaps the legacy VGA IO ports (0x3c0 -> 0x3df) to its > memory mapped register space from offset 0x400. > > Update the driver to use MMIO access for VGA IO port. > > Signed-off-by: Bin Meng > --- > > drivers/video/bochs.c | 6 +++--- > drivers/video/bochs.h | 4 +--- > 2 files changed, 4 insertions(+), 6 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 02/18] video: bochs: Drop inclusion of
On Sun, 23 Jul 2023 12:40:25 +0800 Bin Meng bm...@tinylab.org wrote: > The driver does not call any MTRR APIs. > > Signed-off-by: Bin Meng > --- > > drivers/video/bochs.c | 1 - > 1 file changed, 1 deletion(-) applied to u-boot-video/master, thanks! -- Anatolij
Re: [PATCH 01/18] dm: video: Cosmetic style fix
On Sun, 23 Jul 2023 12:40:24 +0800 Bin Meng bm...@tinylab.org wrote: > Some coding convention fixes for video_post_bind(). > > Signed-off-by: Bin Meng > --- > > drivers/video/video-uclass.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) applied to u-boot-video/master, thanks! -- Anatolij
Please pull u-boot-video
Hi Tom, please pull new video patches for v2023.10. CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/17167 Thanks, Anatolij The following changes since commit 4e619e8d4fd68095bc665a78f2651d8e478a4534: Merge tag 'u-boot-rockchip-20230731' of https://source.denx.de/u-boot/custodians/u-boot-rockchip (2023-07-31 11:33:51 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-video.git tags/video-20230801 for you to fetch changes up to b8d3a6c7d12fc6101f99cde0acedb4a799fdb5f3: drivers: video: tidss: tidss_drv: Use kconfig VIDEO_REMOVE to remove video (2023-08-01 13:41:02 +0200) - dm video cosmetic style fix - bochs: remove the x86 limitation - correct kconfig text for PCI default FB size - kconfig: drop the superfluous PCI dependency - set up default FB size for Bochs Bin Meng (9): dm: video: Cosmetic style fix video: bochs: Drop inclusion of video: bochs: Drop the useless argument of bochs_vga_write() video: bochs: Avoid using IO instructions to access VGA IO port video: bochs: Remove the x86 dependency video: kconfig: Fix wrong text for the PCI default FB size video: kconfig: Drop the superfluous dependency video: kconfig: Set default FB size for Bochs video: bochs: Set the frame buffer size per configuration Nikhil M Jain (2): drivers: video: tidss: tidss_drv: Change remove method drivers: video: tidss: tidss_drv: Use kconfig VIDEO_REMOVE to remove video drivers/video/Kconfig | 15 --- drivers/video/bochs.c | 12 ++-- drivers/video/bochs.h | 7 --- drivers/video/tidss/tidss_drv.c | 18 +++--- drivers/video/video-uclass.c| 6 -- 5 files changed, 29 insertions(+), 29 deletions(-)
Re: [PATCH v2 0/2] arm: dts: k3-am6: Sync DT with Linux
On 15:27-20230731, Roger Quadros wrote: > Hi, > > This series syncs AM64 DT files from Linux v6.5-rc1. > > NOTE: I have only boot tested this on AM64-GP-EVM. > I would appreciate a tested-by for AM64-sk EVM. Thanks. > > cheers, > -roger > > Changelog: > > v2: > - Sync with v6.5-rc1 > - Rebase on latest uboot/master > - CPSW node cleanup > - Timer node cleanup > > Roger Quadros (2): > board: ti: am64x: Recognize AM64-HSEVM > arm: dts: k3-am64: Sync DT with Linux v6.5-rc1 > > arch/arm/dts/k3-am64-main.dtsi| 171 +++-- > arch/arm/dts/k3-am64-mcu.dtsi | 53 +++- > arch/arm/dts/k3-am64-thermal.dtsi | 33 + > arch/arm/dts/k3-am64.dtsi | 22 +--- > arch/arm/dts/k3-am642-evm-u-boot.dtsi | 42 ++- > arch/arm/dts/k3-am642-evm.dts | 173 -- > arch/arm/dts/k3-am642-r5-evm.dts | 26 +++- > arch/arm/dts/k3-am642-r5-sk.dts | 31 - > arch/arm/dts/k3-am642-sk-u-boot.dtsi | 43 ++- > arch/arm/dts/k3-am642-sk.dts | 166 +--- > arch/arm/dts/k3-am642.dtsi| 1 + > board/ti/am64x/evm.c | 3 +- > 12 files changed, 589 insertions(+), 175 deletions(-) > create mode 100644 arch/arm/dts/k3-am64-thermal.dtsi > > -- > 2.34.1 > Could you also add documentation for u-boot (doc/board/ti/) https://github.com/nmenon/fix-k3-dt-u-boot/commit/840ad0f07d6028e3758650f6d3d0d468438910ce -- Regards, Nishanth Menon Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Re: [PATCH v2 2/2] arm: dts: k3-am64: Sync DT with Linux v6.5-rc1
On 15:27-20230731, Roger Quadros wrote:
> Sync all am642-evm/am642-sk related DT files
> with Linux v6.5-rc1.
>
> - drop timer1 in favor of main_timer0 in am64-main.dtsi.
> Need to delete clock & power domain properties of
> main_timer1 in -r5.dts else won't boot.
As we discussed in IRC, we should document the rationale
> - drop cpsw3g custom DT property 'mac_efuse' and custom
> DT node cpsw-phy-sel as driver picks these from standard
> property/node.
>
> Signed-off-by: Roger Quadros
> ---
[...]
> diff --git a/arch/arm/dts/k3-am642-r5-evm.dts
> b/arch/arm/dts/k3-am642-r5-evm.dts
> index b49064181a..fd9e9a6489 100644
> --- a/arch/arm/dts/k3-am642-r5-evm.dts
> +++ b/arch/arm/dts/k3-am642-r5-evm.dts
Same with the evm and sk dts files.
> @@ -13,12 +13,17 @@
> / {
> chosen {
> stdout-path = "serial2:115200n8";
> - tick-timer =
> };
>
> aliases {
> remoteproc0 =
> remoteproc1 = _0;
> + serial1 = _uart1;
> + serial2 = _uart0;
> + i2c0 = _i2c0;
> + mmc0 =
> + mmc1 =
> + ethernet0 = _port1;
Why do we need any of these?
> };
>
> memory@8000 {
We dont need this either.
> @@ -210,6 +215,13 @@
> AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
> PRG1_PRU1_GPO15.RGMII2_TX_CTL */
> >;
> };
> +
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> I2C0_SCL */
> + AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> I2C0_SDA */
> + >;
> + };
we should drop all the pinmuxes - they come in from board.dts.
> };
>
> {
> @@ -227,6 +239,7 @@
> /delete-property/ clock-names;
> pinctrl-names = "default";
> pinctrl-0 = <_uart0_pins_default>;
> + current-speed = <115200>;
> status = "okay";
> };
>
> @@ -267,6 +280,10 @@
>
> /* EEPROM might be read before SYSFW is available */
> _i2c0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> /delete-property/ power-domains;
> };
We should be inheriting stuff from board.dts.
>
> @@ -282,4 +299,11 @@
> pinctrl-0 = <_usb0_pins_default>;
> };
>
> +_timer0 {
> + /delete-property/ clocks;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ power-domains;
This needs documentation.
> +};
> +
> #include "k3-am642-evm-u-boot.dtsi"
> diff --git a/arch/arm/dts/k3-am642-r5-sk.dts b/arch/arm/dts/k3-am642-r5-sk.dts
> index 32d4c31728..5487973e6e 100644
> --- a/arch/arm/dts/k3-am642-r5-sk.dts
> +++ b/arch/arm/dts/k3-am642-r5-sk.dts
> @@ -15,12 +15,17 @@
> / {
> chosen {
> stdout-path = "serial2:115200n8";
> - tick-timer =
> };
>
> aliases {
> remoteproc0 =
> remoteproc1 = _0;
> + serial1 = _uart1;
> + serial2 = _uart0;
> + i2c0 = _i2c0;
> + mmc1 =
> + ethernet0 = _port1;
> + ethernet1 = _port2;
> };
>
> memory@8000 {
> @@ -178,6 +183,13 @@
> AM64X_IOPAD(0x0144, PIN_OUTPUT, 4) /* (Y11)
> PRG1_PRU1_GPO15.RGMII2_TX_CTL */
> >;
> };
> +
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + AM64X_IOPAD(0x0260, PIN_INPUT_PULLUP, 0) /* (A18)
> I2C0_SCL */
> + AM64X_IOPAD(0x0264, PIN_INPUT_PULLUP, 0) /* (B18)
> I2C0_SDA */
> + >;
> + };
> };
>
> {
> @@ -189,12 +201,22 @@
> ti,secure-host;
> };
>
> +/* EEPROM might be read before SYSFW is available */
> +_i2c0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins_default>;
> + clock-frequency = <40>;
> + /delete-property/ power-domains;
> +};
> +
> _uart0 {
> /delete-property/ power-domains;
> /delete-property/ clocks;
> /delete-property/ clock-names;
> pinctrl-names = "default";
> pinctrl-0 = <_uart0_pins_default>;
> + current-speed = <115200>;
> status = "okay";
> };
>
> @@ -264,4 +286,11 @@
> };
> };
>
> +_timer0 {
> + /delete-property/ clocks;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ power-domains;
> +};
> +
> #include "k3-am642-sk-u-boot.dtsi"
Move the u-boot.dtsi include to the very top after board.dts is
included. - Same with the evm dts.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
Re: [PATCH v4 06/12] binman: capsule: Add support for generating capsules
hi Simon, On Wed, 26 Jul 2023 at 04:06, Simon Glass wrote: > > Hi Sughosh, > > On Thu, 20 Jul 2023 at 03:20, Sughosh Ganu wrote: > > > > hi Simon, > > > > On Thu, 20 Jul 2023 at 00:41, Simon Glass wrote: > > > > > > Hi Sughosh, > > > > > > On Wed, 19 Jul 2023 at 02:42, Sughosh Ganu > > > wrote: > > > > > > > > hi Simon, > > > > > > > > On Wed, 19 Jul 2023 at 06:41, Simon Glass wrote: > > > > > > > > > > Hi Sughosh, > > > > > > > > > > On Mon, 17 Jul 2023 at 04:44, Sughosh Ganu > > > > > wrote: > > > > > > > > > > > > hi Simon, > > > > > > > > > > > > On Sun, 16 Jul 2023 at 05:12, Simon Glass wrote: > > > > > > > > > > > > > > Hi Sughosh, > > > > > > > > > > > > > > On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu > > > > > > > wrote: > > > > > > > > > > > > > > > > Add support in binman for generating capsules. The capsule > > > > > > > > parameters > > > > > > > > can be specified either through a config file or through the > > > > > > > > capsule > > > > > > > > binman entry. Also add test cases in binman for capsule > > > > > > > > generation, > > > > > > > > and enable this testing on the sandbox_spl variant. > > > > > > > > > > > > > > Can you use sandbox instead, or perhaps sandbox_spl? SPL is > > > > > > > really for > > > > > > > SPL testing. > > > > > > > > > > > > Er, I am actually using the sandbox_spl variant. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > > > > > --- > > > > > > > > Changes since V3: > > > > > > > > * Add test cases for covering the various capsule generation > > > > > > > > scenarios. > > > > > > > > * Add function comments in the mkeficapsule bintool. > > > > > > > > * Fix the fetch method of the mkeficapsule bintool to enable > > > > > > > > building > > > > > > > > the tool. > > > > > > > > * Add more details about the capsule parameters in the > > > > > > > > documentation > > > > > > > > as well as the code. > > > > > > > > * Fix order of module imports, and addition of blank lines in > > > > > > > > the > > > > > > > > capsule.py file. > > > > > > > > * Use SetContents in the ObtainContents method. > > > > > > > > > > > > > > > > configs/sandbox_spl_defconfig | 1 + > > > > > > > > tools/binman/btool/mkeficapsule.py| 158 > > > > > > > > ++ > > > > > > > > tools/binman/entries.rst | 37 > > > > > > > > tools/binman/etype/capsule.py | 132 > > > > > > > > +++ > > > > > > > > tools/binman/ftest.py | 127 > > > > > > > > ++ > > > > > > > > tools/binman/test/282_capsule.dts | 18 ++ > > > > > > > > tools/binman/test/283_capsule_signed.dts | 20 +++ > > > > > > > > tools/binman/test/284_capsule_conf.dts| 14 ++ > > > > > > > > tools/binman/test/285_capsule_missing_key.dts | 19 +++ > > > > > > > > .../binman/test/286_capsule_missing_index.dts | 17 ++ > > > > > > > > .../binman/test/287_capsule_missing_guid.dts | 17 ++ > > > > > > > > .../test/288_capsule_missing_payload.dts | 17 ++ > > > > > > > > tools/binman/test/289_capsule_missing.dts | 17 ++ > > > > > > > > tools/binman/test/290_capsule_version.dts | 19 +++ > > > > > > > > tools/binman/test/capsule_cfg.txt | 6 + > > > > > > > > 15 files changed, 619 insertions(+) > > > > > > > > create mode 100644 tools/binman/btool/mkeficapsule.py > > > > > > > > create mode 100644 tools/binman/etype/capsule.py > > > > > > > > create mode 100644 tools/binman/test/282_capsule.dts > > > > > > > > create mode 100644 tools/binman/test/283_capsule_signed.dts > > > > > > > > create mode 100644 tools/binman/test/284_capsule_conf.dts > > > > > > > > create mode 100644 > > > > > > > > tools/binman/test/285_capsule_missing_key.dts > > > > > > > > create mode 100644 > > > > > > > > tools/binman/test/286_capsule_missing_index.dts > > > > > > > > create mode 100644 > > > > > > > > tools/binman/test/287_capsule_missing_guid.dts > > > > > > > > create mode 100644 > > > > > > > > tools/binman/test/288_capsule_missing_payload.dts > > > > > > > > create mode 100644 tools/binman/test/289_capsule_missing.dts > > > > > > > > create mode 100644 tools/binman/test/290_capsule_version.dts > > > > > > > > create mode 100644 tools/binman/test/capsule_cfg.txt > > > > > > > > > > > > > > This looks pretty good to me. Some nits below > > > > > > > > > > > > > > > > > > > > > > > diff --git a/configs/sandbox_spl_defconfig > > > > > > > > b/configs/sandbox_spl_defconfig > > > > > > > > index dd848c57c6..2fcc789347 100644 > > > > > > > > --- a/configs/sandbox_spl_defconfig > > > > > > > > +++ b/configs/sandbox_spl_defconfig > > > > > > > > @@ -248,3 +248,4 @@ CONFIG_UNIT_TEST=y > > > > > > > > CONFIG_SPL_UNIT_TEST=y > > > > > > > > CONFIG_UT_TIME=y > > > > > > > > CONFIG_UT_DM=y > > > > > > > > +CONFIG_TOOLS_MKEFICAPSULE=y > > > > > > > > > > > > > > Why enabling this here?
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
Hi Abdellatif, On Mon, Jul 31, 2023 at 1:46 PM Abdellatif El Khlifi wrote: > > Hi Ilias, > > On Mon, Jul 31, 2023 at 12:38:16PM +0300, Ilias Apalodimas wrote: > > > > > > ... > > > > > > Changelog: > > > > > > === > > > > > > > > > > > > v17: > > > > > > > > > > > > * show a debug message rather than an error when FF-A is not > > > > > > detected > > > > > [snip] > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > index c5835e6ef6..8fbadb9201 100644 > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > > > > > > > config EFI_MM_COMM_TEE > > > > > > - bool "UEFI variables storage service via OP-TEE" > > > > > > - depends on OPTEE > > > > > > + bool "UEFI variables storage service via the trusted world" > > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > > > > > You didn't get my changes in here however. If you can do > > > > > EFI_MM_COMM_TEE > > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then > > > > > you don't make this option depend on . If FF-A is only > > > > > for use here, you make FF-A depend on this, and the FF-A specific > > > > > variable depend on ARM_FFA_TRANSPORT. > > > > > > > > Abdellatif hinted at what's going on here. When I added this Kconfig > > > > option to lx2160 FF-A wasn't implemented yet. > > > > > > The defconfig has existed since May 2020, which is when you added > > > EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I > > > did until now and saw this series was disabling what was on the other > > > platform. > > > > > > > Since FF-A isn't a new > > > > communication mechanism but builds upon the existing SMCs to build an > > > > easier API, I asked Abdellatif to hide this complexity. > > > > We had two options, either make Kconfig options for either FF-A or the > > > > traditional SMCs and remove the dependencies, or piggyback on FF-As > > > > discovery mechanism and make the choice at runtime. The latter has a > > > > small impact on code size, but imho makes developers' life a lot > > > > easier. > > > > > > I'm not sure how much you can do a run-time option here since you're > > > setting a bunch of default values for FF-A to 0 in Kconfig. If we're > > > supposed to be able to get them at run time, we shouldn't need a Kconfig > > > option at all. I'm also not sure how valid a use case it is where we > > > won't know at build time what the rest of the firmware stack supports > > > here. > > > > > > > That's a fair point. FF-A in theory has APIs to discover memory. > > Abdellatif, why do we need the Kconfigs for shared memory on FF-A? > > The statically carved out MM shared buffer address, size and offset cannot be > discovered by FF-A ABIs. > The MM communication driver in U-Boot could allocate the buffer and share it > with the MM SP but > we do not implement that support currently in either U-Boot or UEFI. > > Simon suggested we use build configs to set the buffer address, size and > offset since we don't want > a DT node for the MM firmware. In the OP-TEE driver we're allocating memory to share dynamically using malloc() or memalign(). Why isn't the same approach possible here? Thanks, Jens
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On 01/08/23, Oliver Graute wrote: > On 14/02/23, Ying-Chun Liu (PaulLiu) wrote: > > From: Marc Zyngier > > > > In the add_map() function, for each level it populates, it iterates from > > the root of the PT tree, making it ineficient if a mapping needs to occur > > past level 1. > > > > Instead, replace it with a recursive (and much simpler) algorithm > > that keeps the complexity as low as possible. With this, mapping > > 512GB at level 2 goes from several seconds down to not measurable > > on an A55 machine. > > > > We keep the block mappings at level 1 for now though. > > > > Signed-off-by: Marc Zyngier > > Signed-off-by: Pierre-Clément Tosi > > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the > > upstream ] > > Signed-off-by: Ying-Chun Liu (PaulLiu) > > Cc: Tom Rini > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6 > > Link: > > https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059 > > Hello Marc, > > this patch somehow broke the boot of my imx8qm board. I run into this > issue: > > U-Boot 2023.07-rc6-4-g5527698481 (Aug 01 2023 - 10:10:52 +0200) > > Model: Advantech iMX8QM DMSSE20 > Board: DMS-SE20A1 8GB > Build: SCFW 549b1e18, SECO-FW c9de51c0, ATF 5782363 > Boot: USB > DRAM: 8 GiB > "Error" handler, esr 0xbf00 > elr: 80020938 lr : 800209c8 (reloc) > elr: ffecf938 lr : ffecf9c8 > x0 : 0001 x1 : 6000 > x2 : 1000 x3 : 0002 > x4 : 4000 x5 : 00600401 > x6 : 0800 x7 : fff44a60 > x8 : 00680481 x9 : 0008 > x10: 0a200023 x11: 0002 > x12: 0002 x13: 80095a00 > x14: x15: ffecfd2c > x16: 8005454c x17: > x18: fd6afd50 x19: 0fe0 > x20: x21: 00600401 > x22: 6020 x23: 0020 > x24: 4808 x25: 001f > x26: 0003 x27: 6020 > x28: 0002 x29: fd6ab110 > > Code: a94573fb a8c67bfd d65f03c0 b9418a40 (8a160334) > Resetting CPU ... > > resetting ... > SCI reboot > request > > After some bisecting this patch poped up: > > 41e2787f5ec4249cb2e77a3ebd3c49035e3c6535 is the first bad commit > arm64: Reduce add_map() complexity > > After I reverted everything on top of this patch its booting again with > v2023.07 > > commit c1da6fdb5c239b432440721772d993e63cfdeb20 > armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present > > commit 836b8d4b205d2175b57cb9ef271e638b0c116e89 > arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present > > commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213 > arm64: Use FEAT_HAFDBS to track dirty pages when available > > > Do you have any idea whats going on here? Is this behavior somehow releated to the known Cache coherency issue on A53 Core on NXP imx8qm? https://lore.kernel.org/linux-arm-kernel/ZDflS%2FCnEx8iCspk@FVFF77S0Q05N/T/#mf733406e618244b0b21fd25077febd69b31b686e +Jason Liu +Peng Fan Best Regards, Oliver
Data abort when starting DFU on SAMA5D2
Hi, I am currently using an ATSAMA5D27-WLSOM1-EK1. This boards embeds an ATSAMA5D27-WLSOM1, which in turns holds an ATSAMA5D27 and a 8MB QSPI flash. I have been wanting to program u-boot in the QSPI flash thanks to DFU, since the board is able to boot from QSPI and is supported in uboot. To do so, I have executed the following steps: - check out recent uboot version (2023.07.02, but issed described below is observed on master too) - load sama5d27_wlsom1_ek_qspiflash_defconfig - tune the configuration to enable DFU: - CONFIG_CMD_DFU=y - CONFIG_DFU_SF=y - CONFIG_USB_GADGET_DOWNLOAD=y - build uboot, upload and run it onto external ram thanks to snagrecover ([1]). - running "bdinfo" shows that board is properly defined/recognized - "sf probe" properly detects the qspi flash chip - in u-boot console, configure dfu: - setenv dfu_alt_info uboot raw 0 0x8 - start DFU: - dfu 0 sf 2:0 Unfortunately, this step systematically and immediately leads to a data abort with the following log: => dfu 0 sf 2:0 data abort pc : [<2fda9ee0>] lr : [<2fd8dc08>] reloc pc : [<26f3fee0>]lr : [<26f23c08>] sp : 2f963fe8 ip : 2f9829cc fp : r10: 2fde1cd9 r9 : 2f969e80 r8 : 2fdfc304 r7 : r6 : r5 : 2fdf3034 r4 : 2f982948 r3 : 0a299cfc r2 : ffec r1 : r0 : Flags: nzCv IRQs off FIQs off Mode SVC_32 Code: e5843058 e5950004 e3a01000 e5903008 (e5933008) Resetting CPU ... resetting ... System reset not supported on this platform ### ERROR ### Please RESET the board ### A quick translation with addr2line shows that the data abort occurs in include/linux/usb/gagdet.h, in usb_ep_alloc_request, likely because of ep being NULL, which seems confirmed by adding some custom logs in both usb_ep_alloc_request and its caller (composite_bind). Before digging further, does anyone have successfully used DFU on SAMA5D2 boards (and if so, am I missing something in the configuration) ? Or does this data abort show that some support is still missing to make it work for SAMA5D2 ? Kind regards, Alexis [1] https://github.com/bootlin/snagboot -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
Re: [PATCH v2 05/10] usb: dwc3: Increase DWC3 controller halt timeout
On 8/1/23 09:28, Eugen Hristev wrote:
Since EP0 transactions need to be completed before the controller halt
sequence is finished, this may take some time depending on the host and the
enabled functions. Increase the controller halt timeout, so that we give
the controller sufficient time to handle EP0 transfers.
Signed-off-by: Wesley Cheng
Link: https://lore.kernel.org/r/20220901193625.8727-4-quic_wch...@quicinc.com
Cherry-picked from Linux: 461ee467507c ("usb: dwc3: Increase DWC3 controller halt
timeout")
Signed-off-by: Eugen Hristev
---
Not to be merged, I know Marek does not apply any patches to DWC3.
NAK. The statement above is not true, see patch 02/10 .
Re: [PATCH v2 04/10] usb: dwc3: core: Only handle soft-reset in DCTL
On 8/1/23 09:28, Eugen Hristev wrote:
From: Venkatesh Yadav Abbarapu
[ Nguyen/Greg: Ported from Linux kernel commit
f4fd84ae0765a ("usb: dwc3: core: Only handle soft-reset in DCTL") ]
Make sure not to set run_stop bit or link state change request while
initiating soft-reset. Register read-modify-write operation may
unintentionally start the controller before the initialization completes
with its previous DCTL value, which can cause initialization failure.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Not to be merged, I know Marek does not apply any patches to DWC3.
NAK. The statement above is not true, see patch 02/10 .
Re: [PATCH v2 03/10] usb: dwc3: gadget: Don't send unintended link state change
On 8/1/23 09:28, Eugen Hristev wrote:
From: Venkatesh Yadav Abbarapu
[ Nguyen/Felipe/Greg: Ported from Linux kernel commit
5b738211fb59 ("usb: dwc3: gadget: Don't send
unintended link state change") ]
DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write
to DCTL, the driver must make sure that there's no unintended link state
change request from whatever is read from DCTL.ULSTCHNGREQ. Set link
state change to no-action when the driver writes to DCTL.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Not to be merged, I know Marek does not apply any patches to DWC3.
NAK. The statement above is not true, see patch 02/10 .
Re: [PATCH v2 02/10] usb: dwc3: core: improve reset sequence
On 8/1/23 09:28, Eugen Hristev wrote:
From: Venkatesh Yadav Abbarapu
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
[eugen.hris...@collabora.com: keep the PHY resets code]
Signed-off-by: Eugen Hristev
NAK
---
Not to be merged, I know Marek does not apply any patches to DWC3.
That is not true and taken out of context.
What needs to happen is, someone needs to sync the DWC3 with Linux
instead of picking random subsets patches and turning the driver into a
total unmaintainable mess, which will be horribly difficult to sync in
the future due to these random patches mixed in the history. I explained
how to do it to Xilinx, it is a trivial thing to do, but it seems they
did not even bother to try the method.
Re: [PATCH] fs: btrfs: Prevent error pointer dereference in list_subvolums()
On Tue, Aug 01, 2023 at 11:05:11AM +0200, Marek Behún wrote: > nice catch :) Dan, I always wanted to ask, since I've seen many such > "nice catches" over different subsystems from you. Do you write some > tools to find these? Or do you use coccinelle, or something? > Thanks! I'm using Smatch. https://github.com/error27/smatch/ It's handy for me that u-boot and the Linux kernel have so much in common and I can re-use a the kernel checks. I had to make some changes to Smatch to make it work but those are pushed now. U-boot is something that Linaro cares about so if you have static checker ideas then feel free to email the smatch mailing list. sma...@vger.kernel.org regards, dan carpenter
Re: [PATCH 2/2] drivers: video: tidss: tidss_drv: Use kconfig VIDEO_REMOVE to remove video
On 27/07/23 12:01, Jain, Nikhil wrote:
> Perform removal of DSS if kconfigs VIDEO_REMOVE or SPL_VIDEO_REMOVE is
> set by user. Otherwise if above Kconfigs are not selected, it is assumed
> that user wants splash screen to be displayed until linux kernel boots
> up. In such scenario, leave the power domain of DSS as "on" so that
> splash screen stays intact until kernel boots up.
>
> Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
> ---
> drivers/video/tidss/tidss_drv.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/tidss/tidss_drv.c b/drivers/video/tidss/tidss_drv.c
> index 623bf4cf31..e285f255d7 100644
> --- a/drivers/video/tidss/tidss_drv.c
> +++ b/drivers/video/tidss/tidss_drv.c
> @@ -901,9 +901,11 @@ static int tidss_drv_probe(struct udevice *dev)
>
> static int tidss_drv_remove(struct udevice *dev)
> {
> - struct tidss_drv_priv *priv = dev_get_priv(dev);
> + if (CONFIG_IS_ENABLED(VIDEO_REMOVE)) {
> + struct tidss_drv_priv *priv = dev_get_priv(dev);
>
> - VP_REG_FLD_MOD(priv, 0, DSS_VP_CONTROL, 0, 0, 0);
> + VP_REG_FLD_MOD(priv, 0, DSS_VP_CONTROL, 0, 0, 0);
> + }
> return 0;
> }
>
> @@ -929,5 +931,9 @@ U_BOOT_DRIVER(tidss_drv) = {
> .probe = tidss_drv_probe,
> .remove = tidss_drv_remove,
> .priv_auto = sizeof(struct tidss_drv_priv),
> +#if CONFIG_IS_ENABLED(VIDEO_REMOVE)
> .flags = DM_FLAG_OS_PREPARE,
> +#else
> + .flags = DM_FLAG_OS_PREPARE | DM_FLAG_LEAVE_PD_ON,
> +#endif
> };
[PATCH] event: Fix an wrong type_name from dm_post_init to dm_post_init_f
DM_POST_INIT was changed to DM_POST_INIT_F.
To debug correct message, change type_name from dm_post_init to
dm_post_init_f.
Signed-off-by: Jaehoon Chung
---
common/event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/event.c b/common/event.c
index 20720c52839e..3224e2812224 100644
--- a/common/event.c
+++ b/common/event.c
@@ -27,7 +27,7 @@ const char *const type_name[] = {
"test",
/* Events related to driver model */
- "dm_post_init",
+ "dm_post_init_f",
"dm_pre_probe",
"dm_post_probe",
"dm_pre_remove",
--
2.25.1
Re: [PATCH] arm: moxa: add nport6600 platform
On Mon, 31 Jul 2023 at 21:59, Tom Rini wrote: > > On Mon, Jul 31, 2023 at 09:43:29PM +0300, Sergei Antonov wrote: > > > Support for NPort 6600 Series RS-232/422/485 secure terminal servers. > > > > Technical specifications: > > FA526 ARMv4 CPU, 64 MB of RAM, 16 MB NOR flash, 100 Mbit/s Ethernet, > > optional expansion modules, up to 32 RS-232/422/485 ports. > > > > Signed-off-by: Sergei Antonov > > --- > > arch/arm/Kconfig | 9 +++ > > arch/arm/dts/nport6600.dts | 134 +++ > > Where does the device tree come from? >From the datasheet, testing, and a similar dts in Linux: https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts/moxa > > diff --git a/board/moxa/nport6600/nport6600.c > > b/board/moxa/nport6600/nport6600.c > > new file mode 100644 > > index ..88fa98c315fd > > --- /dev/null > > +++ b/board/moxa/nport6600/nport6600.c > > @@ -0,0 +1,78 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > + > > +#include OK. Compiles without it. > New files must not add common.h > > > diff --git a/include/configs/nport6600.h b/include/configs/nport6600.h > > new file mode 100644 > > index ..c70cc7e1ac72 > > --- /dev/null > > +++ b/include/configs/nport6600.h > [snip] > > +#define __io > > What's this for? Removing it leads to warnings: .../u-boot/drivers/serial/ns16550.c: In function ‘serial_out_dynamic’: .../u-boot/drivers/serial/ns16550.c:111:17: warning: implicit declaration of function ‘outb’ [-Wimplicit-function-declaration] 111 | outb(value, addr); | ^~~~ .../u-boot/drivers/serial/ns16550.c: In function ‘serial_in_dynamic’: .../u-boot/drivers/serial/ns16550.c:131:24: warning: implicit declaration of function ‘inb’; did you mean ‘isb’? [-Wimplicit-function-declaration] 131 | return inb(addr); |^~~ |isb and then linking errors: .../armv4/lib/gcc/armv4-linux-gnueabi/13.0.1/../../../../armv4-linux-gnueabi/bin/ld: /tmp/ccIta0uJ.ltrans12.ltrans.o: in function `ns16550_writeb.isra.0': .../u-boot/drivers/serial/ns16550.c:111: undefined reference to `outb' .../armv4/lib/gcc/armv4-linux-gnueabi/13.0.1/../../../../armv4-linux-gnueabi/bin/ld: /tmp/ccIta0uJ.ltrans12.ltrans.o: in function `ns16550_readb.isra.0': .../u-boot/drivers/serial/ns16550.c:131: undefined reference to `inb'
Re: [PATCH 1/2] drivers: video: tidss: tidss_drv: Change remove method
On 27/07/23 12:01, Jain, Nikhil wrote:
> Change remove method of DSS video driver to disable video port instead
> of performing a soft reset, as soft reset takes longer duration. Video
> port is disabled by setting enable bit of video port to 0.
>
> Signed-off-by: Nikhil M Jain
Reviewed-by: Devarsh Thakkar
> ---
> drivers/video/tidss/tidss_drv.c | 12 +---
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/drivers/video/tidss/tidss_drv.c b/drivers/video/tidss/tidss_drv.c
> index 078e3e82e3..623bf4cf31 100644
> --- a/drivers/video/tidss/tidss_drv.c
> +++ b/drivers/video/tidss/tidss_drv.c
> @@ -901,19 +901,9 @@ static int tidss_drv_probe(struct udevice *dev)
>
> static int tidss_drv_remove(struct udevice *dev)
> {
> - u32 val;
> - int ret;
> struct tidss_drv_priv *priv = dev_get_priv(dev);
>
> - priv->base_common = dev_remap_addr_index(dev, 0);
> - REG_FLD_MOD(priv, DSS_SYSCONFIG, 1, 1, 1);
> - /* Wait for reset to complete */
> - ret = readl_poll_timeout(priv->base_common + DSS_SYSSTATUS,
> - val, val & 1, 5000);
> - if (ret) {
> - dev_warn(priv->dev, "failed to reset priv\n");
> - return ret;
> - }
> + VP_REG_FLD_MOD(priv, 0, DSS_VP_CONTROL, 0, 0, 0);
> return 0;
> }
>
Please pull u-boot-marvell/master
Hi Tom,
please pull the following, partly Marvell MVEBU related patches into
master:
- i2c-gpio: Correctly handle new {sda, scl}-gpios bindings (Chris)
- mvebu: x240: Use i2c-gpio instead of built in controller (Chris)
Here the Azure build, without any issues:
https://dev.azure.com/sr0718/u-boot/_build/results?buildId=307=results
Thanks,
Stefan
The following changes since commit a36d59ba99a19c777d896d4c70e75975654e2831:
Merge tag 'efi-2023-10-rc2' of
https://source.denx.de/u-boot/custodians/u-boot-efi (2023-07-28 12:48:00
-0400)
are available in the Git repository at:
g...@source.denx.de:u-boot/custodians/u-boot-marvell.git
for you to fetch changes up to 5c1c6b7306f2b4c0fd50c7cb5d757e245b93606e:
arm: mvebu: x240: Use i2c-gpio instead of built in controller
(2023-07-31 13:50:57 +0200)
Chris Packham (2):
i2c: i2c-gpio: Correctly handle new {sda, scl}-gpios bindings
arm: mvebu: x240: Use i2c-gpio instead of built in controller
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 +++---
configs/x240_defconfig | 1 +
drivers/i2c/i2c-gpio.c | 2 +-
3 files changed, 25 insertions(+), 8 deletions(-)
Re: [PATCH v2 1/2] i2c: i2c-gpio: Correctly handle new {sda, scl}-gpios bindings
On 7/26/23 01:13, Chris Packham wrote:
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham
Applied to u-boot-marvell/master
Thanks,
Stefan
---
This was originally sent as a single patch[1]. I've rolled it into this
series as the board change is dependent on it.
[1] -
https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
(no changes since v1)
drivers/i2c/i2c-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4ed9e9e7cddd..c1fc290bd253 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -339,7 +339,7 @@ static int i2c_gpio_of_to_plat(struct udevice *dev)
/* "gpios" is deprecated and replaced by "sda-gpios" + "scl-gpios". */
ret = gpio_request_list_by_name(dev, "gpios", bus->gpios,
ARRAY_SIZE(bus->gpios), 0);
- if (ret == -ENOENT) {
+ if (ret == 0) {
ret = gpio_request_by_name(dev, "sda-gpios", 0,
>gpios[PIN_SDA], 0);
if (ret < 0)
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v2 2/2] arm: mvebu: x240: Use i2c-gpio instead of built in controller
On 7/26/23 01:13, Chris Packham wrote:
There is an Errata with the built-in I2C controller where various I2C
hardware errors cause a complete lockup of the CPU (which eventually
results in an watchdog reset).
Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
This uses a bit-banged implementation of an I2C controller and avoids
triggering the Errata.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
Applied to u-boot-marvell/master
Thanks,
Stefan
---
Changes in v2:
- Update i2c0 alias
- Move i2c-gpio definition to root of device tree
- Remove instead of just disabling it
- Add r-by from Stefan
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 --
configs/x240_defconfig | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index 820ec18b4355..c19b25925ba2 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -16,7 +16,7 @@
gpio0 =
gpio1 =
spi0 =
- i2c0 =
+ i2c0 =
usb0 =
pinctrl0 =
};
@@ -40,6 +40,19 @@
default-state = "on";
};
};
+
+ i2cgpio: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio>;
+ scl-gpios = < 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ sda-gpios = < 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ status = "okay";
+};
};
{
@@ -70,9 +83,7 @@
status = "okay";
};
- {
- status = "okay";
-
+ {
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -177,8 +188,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26]
-* I2C0_SDA [27]
+* I2C0_SCL [26] (GPIO)
+* I2C0_SDA [27] (GPIO)
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -201,7 +212,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000001100
+0000000xff 0xff 00
1111000000
000111>;
@@ -209,4 +220,9 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
+
+ i2c0_gpio: i2c0-gpio-pins {
+ marvell,pins = <26 27>;
+ marvell,function = <0>;
+ };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index a78cb3ce6cbf..7d2b8603e6f4 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -42,6 +42,7 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] fs: btrfs: Prevent error pointer dereference in list_subvolums()
On 2023/7/26 14:59, Dan Carpenter wrote: If btrfs_read_fs_root() fails with -ENOENT, then we go to the next entry. Fine. But if it fails for a different reason then we need to clean up and return an error code. In the current code it doesn't clean up but instead dereferences "root" and crashes. Signed-off-by: Dan Carpenter Reviewed-by: Qu Wenruo --- I didn't CC the btrfs mailing list. Perhaps, I should have? This patch is fine. The function is specific to U-boot, and not utilized by kernel/btrfs-progs. Thanks, Qu fs/btrfs/subvolume.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/subvolume.c b/fs/btrfs/subvolume.c index d446e7a2c418..68ca7e48e48e 100644 --- a/fs/btrfs/subvolume.c +++ b/fs/btrfs/subvolume.c @@ -199,6 +199,7 @@ static int list_subvolums(struct btrfs_fs_info *fs_info) ret = PTR_ERR(root); if (ret == -ENOENT) goto next; + goto out; } ret = list_one_subvol(root, result); if (ret < 0)
Re: [PATCH] fs: btrfs: Prevent error pointer dereference in list_subvolums()
On Wed, 26 Jul 2023 09:59:04 +0300 Dan Carpenter wrote: > If btrfs_read_fs_root() fails with -ENOENT, then we go to the next > entry. Fine. But if it fails for a different reason then we need > to clean up and return an error code. In the current code it > doesn't clean up but instead dereferences "root" and crashes. > > Signed-off-by: Dan Carpenter > --- > I didn't CC the btrfs mailing list. Perhaps, I should have? > > fs/btrfs/subvolume.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/btrfs/subvolume.c b/fs/btrfs/subvolume.c > index d446e7a2c418..68ca7e48e48e 100644 > --- a/fs/btrfs/subvolume.c > +++ b/fs/btrfs/subvolume.c > @@ -199,6 +199,7 @@ static int list_subvolums(struct btrfs_fs_info *fs_info) > ret = PTR_ERR(root); > if (ret == -ENOENT) > goto next; > + goto out; > } > ret = list_one_subvol(root, result); > if (ret < 0) Reviewed-by: Marek Behún nice catch :) Dan, I always wanted to ask, since I've seen many such "nice catches" over different subsystems from you. Do you write some tools to find these? Or do you use coccinelle, or something? Marek
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On 14/02/23, Ying-Chun Liu (PaulLiu) wrote: > From: Marc Zyngier > > In the add_map() function, for each level it populates, it iterates from > the root of the PT tree, making it ineficient if a mapping needs to occur > past level 1. > > Instead, replace it with a recursive (and much simpler) algorithm > that keeps the complexity as low as possible. With this, mapping > 512GB at level 2 goes from several seconds down to not measurable > on an A55 machine. > > We keep the block mappings at level 1 for now though. > > Signed-off-by: Marc Zyngier > Signed-off-by: Pierre-Clément Tosi > [ Paul: pick from the Android tree. Fixup Pierre's commit. Rebase to the > upstream ] > Signed-off-by: Ying-Chun Liu (PaulLiu) > Cc: Tom Rini > Link: > https://android.googlesource.com/platform/external/u-boot/+/96ad729cf4cab53bdff8222bb3eb256f38b5c3a6 > Link: > https://android.googlesource.com/platform/external/u-boot/+/6be9330601d81545c7c941e3609f35bf68a09059 Hello Marc, this patch somehow broke the boot of my imx8qm board. I run into this issue: U-Boot 2023.07-rc6-4-g5527698481 (Aug 01 2023 - 10:10:52 +0200) Model: Advantech iMX8QM DMSSE20 Board: DMS-SE20A1 8GB Build: SCFW 549b1e18, SECO-FW c9de51c0, ATF 5782363 Boot: USB DRAM: 8 GiB "Error" handler, esr 0xbf00 elr: 80020938 lr : 800209c8 (reloc) elr: ffecf938 lr : ffecf9c8 x0 : 0001 x1 : 6000 x2 : 1000 x3 : 0002 x4 : 4000 x5 : 00600401 x6 : 0800 x7 : fff44a60 x8 : 00680481 x9 : 0008 x10: 0a200023 x11: 0002 x12: 0002 x13: 80095a00 x14: x15: ffecfd2c x16: 8005454c x17: x18: fd6afd50 x19: 0fe0 x20: x21: 00600401 x22: 6020 x23: 0020 x24: 4808 x25: 001f x26: 0003 x27: 6020 x28: 0002 x29: fd6ab110 Code: a94573fb a8c67bfd d65f03c0 b9418a40 (8a160334) Resetting CPU ... resetting ... SCI reboot request After some bisecting this patch poped up: 41e2787f5ec4249cb2e77a3ebd3c49035e3c6535 is the first bad commit arm64: Reduce add_map() complexity After I reverted everything on top of this patch its booting again with v2023.07 commit c1da6fdb5c239b432440721772d993e63cfdeb20 armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present commit 836b8d4b205d2175b57cb9ef271e638b0c116e89 arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213 arm64: Use FEAT_HAFDBS to track dirty pages when available Do you have any idea whats going on here? Best Regards, Oliver
Re: [PATCH v3] board: rockchip: Add Radxa E25 Carrier Board
Hi, On 2023-07-31 11:27, FUKAUMI Naoki wrote: > hi, > > one thing in defconfig, > > On 7/30/23 21:30, Jonas Karlman wrote: >> Radxa E25 is a network application carrier board for the Radxa CM3I SoM >> with a RK3568 SoC. It features dual 2.5G ethernet, mini PCIe, M.2 B Key, >> USB3, eMMC, SD, nano SIM card slot and a 26-pin GPIO header. >> >> Features tested on a Radxa E25 v1.4: >> - SD-card boot >> - eMMC boot >> - USB host >> - PCIe/Ethernet adapters is detected >> - SATA >> >> Device tree is imported from linux next-20230728. >> >> Signed-off-by: Jonas Karlman >> Reviewed-by: Kever Yang >> --- >> Changes in v3: >> - Rebased on master and "board: rockchip: Add Pine64 Quartz64 and >>SOQuartz boards" v2 series >> - Sync device tree from linux next-20230728 to include sata1, combphy1 >>and regulator fixes merged into linux maintainer tree since v2 >> - Drop u-boot.dtsi pcie pinctrl change that caused pinmux issue in linux >>when using EFI boot flow >> - Collect r-b tag >> >> Changes in v2: >> - Remove the unneeded always-on/boot-on prop of vcc3v3_pi6c_05 >> - Drop PCI_INIT_R=y and add MMC_HS200_SUPPORT=y to speed up boot >> - Enable sata1 node and set correct regulator to combphy1 node, >>can be dropped in a future DT sync once linux patch [1] lands >> >> This patch depends on the series "board: rockchip: Add Pine64 Quartz64 >> and SOQuartz boards" v2 [2] and all its depends. >> >> A copy of this patch and all its depends can be found at [3]. >> >> [1] >> https://lore.kernel.org/linux-rockchip/20230724145213.3833099-1-jo...@kwiboo.se/ >> [2] https://patchwork.ozlabs.org/project/uboot/list/?series=366399 >> [3] https://github.com/Kwiboo/u-boot-rockchip/commits/rk3568-radxa-e25-v3 >> >> arch/arm/dts/Makefile | 1 + >> arch/arm/dts/rk3568-radxa-cm3i.dtsi | 415 ++ >> arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi | 32 ++ >> arch/arm/dts/rk3568-radxa-e25.dts | 236 >> board/rockchip/evb_rk3568/MAINTAINERS | 8 + >> configs/radxa-e25-rk3568_defconfig| 94 + >> doc/board/rockchip/rockchip.rst | 1 + >> 7 files changed, 787 insertions(+) >> create mode 100644 arch/arm/dts/rk3568-radxa-cm3i.dtsi >> create mode 100644 arch/arm/dts/rk3568-radxa-e25-u-boot.dtsi >> create mode 100644 arch/arm/dts/rk3568-radxa-e25.dts >> create mode 100644 configs/radxa-e25-rk3568_defconfig >> [...] >> diff --git a/configs/radxa-e25-rk3568_defconfig >> b/configs/radxa-e25-rk3568_defconfig >> new file mode 100644 >> index ..a905100a794d >> --- /dev/null >> +++ b/configs/radxa-e25-rk3568_defconfig >> @@ -0,0 +1,94 @@ >> +CONFIG_ARM=y >> +CONFIG_SKIP_LOWLEVEL_INIT=y >> +CONFIG_SYS_HAS_NONCACHED_MEMORY=y >> +CONFIG_COUNTER_FREQUENCY=2400 >> +CONFIG_ARCH_ROCKCHIP=y >> +CONFIG_TEXT_BASE=0x00a0 >> +CONFIG_SPL_LIBCOMMON_SUPPORT=y >> +CONFIG_SPL_LIBGENERIC_SUPPORT=y >> +CONFIG_NR_DRAM_BANKS=2 >> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y >> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0 >> +CONFIG_DEFAULT_DEVICE_TREE="rk3568-radxa-e25" >> +CONFIG_ROCKCHIP_RK3568=y >> +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y >> +CONFIG_SPL_SERIAL=y >> +CONFIG_SPL_STACK_R_ADDR=0x60 >> +CONFIG_SPL_STACK=0x40 >> +CONFIG_DEBUG_UART_BASE=0xFE66 >> +CONFIG_DEBUG_UART_CLOCK=2400 >> +CONFIG_SYS_LOAD_ADDR=0xc00800 >> +CONFIG_PCI=y >> +CONFIG_DEBUG_UART=y >> +CONFIG_AHCI=y >> +CONFIG_FIT=y >> +CONFIG_FIT_VERBOSE=y >> +CONFIG_SPL_FIT_SIGNATURE=y >> +CONFIG_SPL_LOAD_FIT=y >> +CONFIG_LEGACY_IMAGE_FORMAT=y >> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-radxa-e25.dtb" >> +# CONFIG_DISPLAY_CPUINFO is not set >> +CONFIG_DISPLAY_BOARDINFO_LATE=y >> +CONFIG_SPL_MAX_SIZE=0x4 >> +CONFIG_SPL_PAD_TO=0x7f8000 >> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y >> +CONFIG_SPL_BSS_START_ADDR=0x400 >> +CONFIG_SPL_BSS_MAX_SIZE=0x4000 >> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set >> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set >> +CONFIG_SPL_STACK_R=y >> +CONFIG_SPL_ATF=y >> +CONFIG_CMD_GPIO=y >> +CONFIG_CMD_GPT=y >> +CONFIG_CMD_I2C=y >> +CONFIG_CMD_MMC=y >> +CONFIG_CMD_PCI=y >> +CONFIG_CMD_USB=y >> +# CONFIG_CMD_SETEXPR is not set >> +CONFIG_CMD_PMIC=y >> +CONFIG_CMD_REGULATOR=y >> +# CONFIG_SPL_DOS_PARTITION is not set >> +CONFIG_SPL_OF_CONTROL=y >> +CONFIG_OF_LIVE=y >> +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks >> assigned-clock-rates assigned-clock-parents" >> +CONFIG_SPL_DM_SEQ_ALIAS=y >> +CONFIG_SPL_REGMAP=y >> +CONFIG_SPL_SYSCON=y >> +CONFIG_AHCI_PCI=y > > AHCI_PCI is not required for SATA on Carrier Board. Thanks for testing and reporting this. And you are correct, we do not need to enable AHCI_PCI to support a SATA drive in the M.2 slot. I am currently working on a follow-up series to add the missing driver support for PCIe bifurcation. Will include a small change to drop this Kconfig option in that series. Regards, Jonas > > Tested-by: FUKAUMI Naoki > > => scsi scan > scanning bus for
Re: [PATCH v3] rockchip: rk3568: Add EmbedFire Lubancat 2 support
On 2023-07-31 03:11, Andy Yan wrote: > > Hi Jonas： > Thanks for you kindly review。 > > At 2023-07-30 21:22:36, "Jonas Karlman" wrote: >> Hi Andy, >> >> On 2023-07-29 13:58, Andy Yan wrote: >>> LubanCat2 is a rk3568 based SBC from EmbedFire. >>> >>> Specification: >>> - Rockchip rk3568 >>> - LPDDR4/4X 1/2/4/8 GB >>> - TF scard slot >>> - eMMC 8/32/64/128 GB >>> - Gigabit ethernet x 2 >>> - HDMI out >>> - USB 2.0 Host x 1 >>> - USB 2.0 Type-C OTG x 1 >>> - USB 3.0 Host x 1 >>> - Mini PCIE interface for WIFI/BT module >>> - M.2 key for 2280 NVME >>> - 40 pin header >>> >>> The dts file is sync from linux mainline. >>> >>> There are some dts bootph-all and USB3 update according to Jonas >>> suggestion[0], >>> so this patch based on Jonas patch [1] [2]. >>> >>> Signed-off-by: Andy Yan >>> [0]:http://patchwork.ozlabs.org/project/uboot/patch/20230708102556.25472-1-andys...@163.com/ >>> [1]:http://patchwork.ozlabs.org/project/uboot/cover/20230728115302.1735429-1-jo...@kwiboo.se/ >>> [2]:http://patchwork.ozlabs.org/project/uboot/cover/20230728124011.1747408-1-jo...@kwiboo.se/ >>> >>> --- >>> >>> Changes in v3: >>> - some alphabetical order update >>> - disable all SPI flash related options. >>> - remove bootph-all for pinctrl >>> - add emmc_datastrobe pinconfig for hs200/hs400 in u-boot.dtsi >>> - use USB_DWC3_GENERIC driver as Jonas suggested. >>> - add CONFIG_SPL_DM_SEQ_ALIAS >>> >>> Changes in v2: >>> - enable SPL_FIT_SIGNATURE >>> >>> arch/arm/dts/Makefile | 1 + >>> arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi | 28 + >>> arch/arm/dts/rk3568-lubancat-2.dts | 734 + >>> configs/lubancat-2-rk3568_defconfig| 87 +++ >>> 4 files changed, 850 insertions(+) >>> create mode 100644 arch/arm/dts/rk3568-lubancat-2-u-boot.dtsi >>> create mode 100644 arch/arm/dts/rk3568-lubancat-2.dts >>> create mode 100644 configs/lubancat-2-rk3568_defconfig >> >> You should add an entry for this board to evb_rk3568/MAINTAINERS and >> also to the documentation at doc/board/rockchip/rockchip.rst >> >> [...] >> >>> diff --git a/arch/arm/dts/rk3568-lubancat-2.dts >>> b/arch/arm/dts/rk3568-lubancat-2.dts >>> new file mode 100644 >>> index 00..da257b0591 >>> --- /dev/null >>> +++ b/arch/arm/dts/rk3568-lubancat-2.dts >>> @@ -0,0 +1,734 @@ >>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >>> + >>> +/* >>> + * Copyright (c) 2023 Rockchip Electronics Co., Ltd. >>> + * Copyright (c) 2023 EmbedFire >>> + * Copyright (c) 2023 Andy Yan >> >> You are changing copyright header on a file otherwise copied 1:1 from >> the linux kernel. >> >>> + */ >>> + >> >> [...] >> >>> diff --git a/configs/lubancat-2-rk3568_defconfig >>> b/configs/lubancat-2-rk3568_defconfig >>> new file mode 100644 >>> index 00..278ee8dc70 >>> --- /dev/null >>> +++ b/configs/lubancat-2-rk3568_defconfig >>> @@ -0,0 +1,87 @@ >>> +CONFIG_ARM=y >>> +CONFIG_SKIP_LOWLEVEL_INIT=y >>> +CONFIG_COUNTER_FREQUENCY=2400 >>> +CONFIG_ARCH_ROCKCHIP=y >>> +CONFIG_TEXT_BASE=0x00a0 >>> +CONFIG_SPL_LIBCOMMON_SUPPORT=y >>> +CONFIG_SPL_LIBGENERIC_SUPPORT=y >>> +CONFIG_NR_DRAM_BANKS=2 >>> +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y >>> +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0 >>> +CONFIG_DEFAULT_DEVICE_TREE="rk3568-lubancat-2" >>> +CONFIG_ROCKCHIP_RK3568=y >>> +CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y >>> +CONFIG_SPL_SERIAL=y >>> +CONFIG_SPL_STACK_R_ADDR=0x60 >>> +CONFIG_SPL_STACK=0x40 >>> +CONFIG_DEBUG_UART_BASE=0xFE66 >>> +CONFIG_DEBUG_UART_CLOCK=2400 >>> +CONFIG_SYS_LOAD_ADDR=0xc00800 >>> +CONFIG_DEBUG_UART=y >>> +CONFIG_FIT=y >>> +CONFIG_FIT_VERBOSE=y >>> +CONFIG_SPL_FIT_SIGNATURE=y >>> +CONFIG_SPL_LOAD_FIT=y >>> +CONFIG_LEGACY_IMAGE_FORMAT=y >>> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3568-lubancat-2.dtb" >>> +# CONFIG_DISPLAY_CPUINFO is not set >>> +CONFIG_DISPLAY_BOARDINFO_LATE=y >>> +CONFIG_SPL_MAX_SIZE=0x4 >>> +CONFIG_SPL_PAD_TO=0x7f8000 >>> +CONFIG_SPL_HAS_BSS_LINKER_SECTION=y >>> +CONFIG_SPL_BSS_START_ADDR=0x400 >>> +CONFIG_SPL_BSS_MAX_SIZE=0x4000 >>> +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set >>> +# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set >>> +CONFIG_SPL_STACK_R=y >>> +CONFIG_SPL_ATF=y >>> +CONFIG_CMD_GPIO=y >>> +CONFIG_CMD_GPT=y >>> +CONFIG_CMD_I2C=y >>> +CONFIG_CMD_MMC=y >>> +CONFIG_CMD_USB=y >>> +# CONFIG_CMD_SETEXPR is not set >>> +CONFIG_CMD_PMIC=y >>> +CONFIG_CMD_REGULATOR=y >>> +# CONFIG_SPL_DOS_PARTITION is not set >>> +CONFIG_SPL_OF_CONTROL=y >>> +CONFIG_OF_LIVE=y >>> +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks >>> assigned-clock-rates assigned-clock-parents" >>> +CONFIG_SPL_DM_SEQ_ALIAS=y >>> +CONFIG_SPL_REGMAP=y >>> +CONFIG_SPL_SYSCON=y >>> +CONFIG_SPL_CLK=y >>> +CONFIG_ROCKCHIP_GPIO=y >>> +CONFIG_SYS_I2C_ROCKCHIP=y >>> +CONFIG_MISC=y >>> +CONFIG_SUPPORT_EMMC_RPMB=y >>> +CONFIG_MMC_DW=y >>> +CONFIG_MMC_DW_ROCKCHIP=y >>> +CONFIG_MMC_SDHCI=y >>> +CONFIG_MMC_SDHCI_SDMA=y >>> +CONFIG_MMC_SDHCI_ROCKCHIP=y >>> +# CONFIG_SPI_FLASH is not set >>>
Re: [PATCH] i2c: mvtwsi: reset controller if stuck in "bus error" state
On 7/26/23 00:13, Sam Edwards wrote:
The MVTWSI controller can act either as a master or slave device. When
acting as a master, the FSM is driven by the CPU. As a slave, the FSM is
driven by the bus directly. In what is (apparently) a safety mechanism,
if the bus transitions our FSM in any improper way, the FSM goes to a
"bus error" state (0x00). I could find no documented or experimental way
to get the FSM out of this state, except for a controller reset.
Since U-Boot only uses the MVTWSI controller as a bus master, this
feature only gets in the way: we do not care what happened on the bus
previously as long as the bus is ready for a new transaction. So, when
trying to start a new transaction, check for this state and reset the
controller if necessary.
Note that this should not be confused with the "deblocking" technique
(used by the `i2c reset` command), which involves pulsing SCL repeatedly
if SDA is found to be held low, in an attempt to force the bus back to
an idle state. This patch only resets the controller in case something
else had previously upset it, and (in principle) results in no
externally-observable change in behavior.
Signed-off-by: Sam Edwards
Reviewed-by: Stefan Roese
Thanks,
Stefan
---
drivers/i2c/mvtwsi.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 93bbc6916e..14cdb0f663 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -142,6 +142,8 @@ enum mvtwsi_ctrl_register_fields {
* code.
*/
enum mvstwsi_status_values {
+ /* Protocol violation on bus; this is a terminal state */
+ MVTWSI_BUS_ERROR= 0x00,
/* START condition transmitted */
MVTWSI_STATUS_START = 0x08,
/* Repeated START condition transmitted */
@@ -525,6 +527,36 @@ static void __twsi_i2c_init(struct mvtwsi_registers *twsi,
int speed,
#endif
}
+/*
+ * __twsi_i2c_reinit() - Reset and reinitialize the I2C controller.
+ *
+ * This function should be called to get the MVTWSI controller out of the
+ * "bus error" state. It saves and restores the baud and address registers.
+ *
+ * @twsi: The MVTWSI register structure to use.
+ * @tick: The duration of a clock cycle at the current I2C speed.
+ */
+static void __twsi_i2c_reinit(struct mvtwsi_registers *twsi, uint tick)
+{
+ uint baud;
+ uint slaveadd;
+
+ /* Save baud, address registers */
+ baud = readl(>baudrate);
+ slaveadd = readl(>slave_address);
+
+ /* Reset controller */
+ twsi_reset(twsi);
+
+ /* Restore baud, address registers */
+ writel(baud, >baudrate);
+ writel(slaveadd, >slave_address);
+ writel(0, >xtnd_slave_addr);
+
+ /* Assert STOP, but don't care for the result */
+ (void) twsi_stop(twsi, tick);
+}
+
/*
* i2c_begin() - Start a I2C transaction.
*
@@ -621,6 +653,11 @@ static int __twsi_i2c_read(struct mvtwsi_registers *twsi,
uchar chip,
int stop_status;
int expected_start = MVTWSI_STATUS_START;
+ /* Check for (and clear) a bus error from a previous failed transaction
+* or another master on the same bus */
+ if (readl(>status) == MVTWSI_BUS_ERROR)
+ __twsi_i2c_reinit(twsi, tick);
+
if (alen > 0) {
/* Begin i2c write to send the address bytes */
status = i2c_begin(twsi, expected_start, (chip << 1), tick);
@@ -668,6 +705,11 @@ static int __twsi_i2c_write(struct mvtwsi_registers *twsi,
uchar chip,
{
int status, stop_status;
+ /* Check for (and clear) a bus error from a previous failed transaction
+* or another master on the same bus */
+ if (readl(>status) == MVTWSI_BUS_ERROR)
+ __twsi_i2c_reinit(twsi, tick);
+
/* Begin i2c write to send first the address bytes, then the
* data bytes */
status = i2c_begin(twsi, MVTWSI_STATUS_START, (chip << 1), tick);
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH v17 09/10] arm_ffa: efi: introduce FF-A MM communication
Hi Abdellatif On Mon, 31 Jul 2023 at 14:46, Abdellatif El Khlifi wrote: > > Hi Ilias, > > On Mon, Jul 31, 2023 at 12:38:16PM +0300, Ilias Apalodimas wrote: > > > > > > ... > > > > > > Changelog: > > > > > > === > > > > > > > > > > > > v17: > > > > > > > > > > > > * show a debug message rather than an error when FF-A is not > > > > > > detected > > > > > [snip] > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > index c5835e6ef6..8fbadb9201 100644 > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > @@ -55,13 +55,53 @@ config EFI_VARIABLE_FILE_STORE > > > > > > stored as file /ubootefi.var on the EFI system partition. > > > > > > > > > > > > config EFI_MM_COMM_TEE > > > > > > - bool "UEFI variables storage service via OP-TEE" > > > > > > - depends on OPTEE > > > > > > + bool "UEFI variables storage service via the trusted world" > > > > > > + depends on OPTEE && ARM_FFA_TRANSPORT > > > > > > > > > > You didn't get my changes in here however. If you can do > > > > > EFI_MM_COMM_TEE > > > > > without ARM_FFA_TRANSPORT (as lx2160ardb_tfa_stmm_defconfig does) then > > > > > you don't make this option depend on . If FF-A is only > > > > > for use here, you make FF-A depend on this, and the FF-A specific > > > > > variable depend on ARM_FFA_TRANSPORT. > > > > > > > > Abdellatif hinted at what's going on here. When I added this Kconfig > > > > option to lx2160 FF-A wasn't implemented yet. > > > > > > The defconfig has existed since May 2020, which is when you added > > > EFI_MM_COMM_TEE itself too. So I think it's that no one did the check I > > > did until now and saw this series was disabling what was on the other > > > platform. > > > > > > > Since FF-A isn't a new > > > > communication mechanism but builds upon the existing SMCs to build an > > > > easier API, I asked Abdellatif to hide this complexity. > > > > We had two options, either make Kconfig options for either FF-A or the > > > > traditional SMCs and remove the dependencies, or piggyback on FF-As > > > > discovery mechanism and make the choice at runtime. The latter has a > > > > small impact on code size, but imho makes developers' life a lot > > > > easier. > > > > > > I'm not sure how much you can do a run-time option here since you're > > > setting a bunch of default values for FF-A to 0 in Kconfig. If we're > > > supposed to be able to get them at run time, we shouldn't need a Kconfig > > > option at all. I'm also not sure how valid a use case it is where we > > > won't know at build time what the rest of the firmware stack supports > > > here. > > > > > > > That's a fair point. FF-A in theory has APIs to discover memory. > > Abdellatif, why do we need the Kconfigs for shared memory on FF-A? > > The statically carved out MM shared buffer address, size and offset cannot be > discovered by FF-A ABIs. > The MM communication driver in U-Boot could allocate the buffer and share it > with the MM SP but > we do not implement that support currently in either U-Boot or UEFI. Ok, that's a bit unfortunate, but Tom is right. Having the FF-A addresses show up is as confusing as having Kconfig options for discrete options. The whole point of my suggestion was to make users' lives easier. Apologies for the confusion but can you bring back the ifdefs? Looking at the patch this should be minimal just use ifdef ARM_FFA_TRANSPORT and ifndef ARM_FFA_TRANSPORT. Tom you prefer that as well? Thanks /Ilias > > Simon suggested we use build configs to set the buffer address, size and > offset since we don't want > a DT node for the MM firmware. > > Kind regards > Abdellatif
[PATCH v2 10/10] configs: rockchip: rock5b-rk3588: enable DFU and related configs
Enable DFU and related configs, expand stack and buffers to hold downloaded image. Signed-off-by: Eugen Hristev --- Changes in v2: - added # CONFIG_SPL_BINMAN_UBOOT_SYMBOLS is not set because with the configs enabled here, this is automatically set as =y and this causes a build failure. configs/rock5b-rk3588_defconfig | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig index 3976a6c0f05c..ca70073f3ccc 100644 --- a/configs/rock5b-rk3588_defconfig +++ b/configs/rock5b-rk3588_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_HAS_NONCACHED_MEMORY=y CONFIG_COUNTER_FREQUENCY=2400 CONFIG_ARCH_ROCKCHIP=y CONFIG_TEXT_BASE=0x00a0 +CONFIG_SYS_MALLOC_F_LEN=0x50 CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=2 @@ -16,9 +17,9 @@ CONFIG_ROCKCHIP_RK3588=y CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y CONFIG_ROCKCHIP_SPI_IMAGE=y CONFIG_SPL_SERIAL=y -CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_SPL_STACK_R_ADDR=0x100 CONFIG_TARGET_ROCK5B_RK3588=y -CONFIG_SPL_STACK=0x40 +CONFIG_SPL_STACK=0x100 CONFIG_DEBUG_UART_BASE=0xFEB5 CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y @@ -30,6 +31,7 @@ CONFIG_FIT=y CONFIG_FIT_VERBOSE=y CONFIG_SPL_FIT_SIGNATURE=y CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x5000 CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588-rock-5b.dtb" @@ -41,12 +43,17 @@ CONFIG_SPL_PAD_TO=0x7f8000 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y CONFIG_SPL_BSS_START_ADDR=0x400 CONFIG_SPL_BSS_MAX_SIZE=0x4000 +# CONFIG_SPL_BINMAN_UBOOT_SYMBOLS is not set # CONFIG_SPL_RAW_IMAGE_SUPPORT is not set # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_STACK_R=y +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x30 +CONFIG_SPL_ENV_SUPPORT=y +CONFIG_SPL_RAM_SUPPORT=y CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x6 CONFIG_SPL_ATF=y +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y CONFIG_CMD_I2C=y @@ -59,10 +66,12 @@ CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y -CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_OF_SPL_REMOVE_PROPS="interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y +CONFIG_DFU_RAM=y +CONFIG_SYS_DFU_DATA_BUF_SIZE=0x20 # CONFIG_USB_FUNCTION_FASTBOOT is not set CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y @@ -93,6 +102,7 @@ CONFIG_ROCKCHIP_SFC=y CONFIG_SYSRESET=y CONFIG_USB=y CONFIG_DM_USB_GADGET=y +CONFIG_SPL_DM_USB_GADGET=y CONFIG_USB_XHCI_HCD=y # CONFIG_USB_XHCI_DWC3_OF_SIMPLE is not set CONFIG_USB_EHCI_HCD=y @@ -111,7 +121,9 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y CONFIG_USB_GADGET=y +CONFIG_SPL_USB_GADGET=y CONFIG_USB_GADGET_PRODUCT_NUM=0x350b CONFIG_USB_GADGET_DOWNLOAD=y CONFIG_USB_FUNCTION_ROCKUSB=y +CONFIG_SPL_DFU=y CONFIG_ERRNO_STR=y -- 2.34.1
[PATCH v2 09/10] rockchip: rk3588: prepare env for DFU
Prepare env variables for DFU Signed-off-by: Eugen Hristev --- include/configs/rk3588_common.h | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/include/configs/rk3588_common.h b/include/configs/rk3588_common.h index 46389d087d29..48414fe946a0 100644 --- a/include/configs/rk3588_common.h +++ b/include/configs/rk3588_common.h @@ -7,6 +7,7 @@ #ifndef __CONFIG_RK3588_COMMON_H #define __CONFIG_RK3588_COMMON_H +#include #include "rockchip-common.h" #define CFG_IRAM_BASE 0xff00 @@ -31,6 +32,12 @@ "partitions=" PARTS_DEFAULT \ ENV_MEM_LAYOUT_SETTINGS \ ROCKCHIP_DEVICE_SETTINGS \ - "boot_targets=" BOOT_TARGETS "\0" + "boot_targets=" BOOT_TARGETS "\0" \ + "dfu_alt_info=ram ram0=ram ram " \ + __stringify(CONFIG_SPL_LOAD_FIT_ADDRESS) " " \ + __stringify(CONFIG_SYS_DFU_DATA_BUF_SIZE) "\0" \ + "dfu_alt_info_ram=u-boot.itb ram " \ + __stringify(CONFIG_SPL_LOAD_FIT_ADDRESS) " " \ + __stringify(CONFIG_SYS_DFU_DATA_BUF_SIZE) #endif /* __CONFIG_RK3588_COMMON_H */ -- 2.34.1
[PATCH v2 08/10] ARM: mach-rockchip: rk3588: add gadget device to the boot order
In case SPL was booted from USB, add the gadget as the boot device
for the 'same-as-spl' boot order next device.
Signed-off-by: Eugen Hristev
---
arch/arm/mach-rockchip/rk3588/rk3588.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-rockchip/rk3588/rk3588.c
b/arch/arm/mach-rockchip/rk3588/rk3588.c
index b1f535fad505..c95268e18801 100644
--- a/arch/arm/mach-rockchip/rk3588/rk3588.c
+++ b/arch/arm/mach-rockchip/rk3588/rk3588.c
@@ -42,6 +42,7 @@ const char * const boot_devices[BROM_LAST_BOOTSOURCE + 1] = {
[BROM_BOOTSOURCE_SPINOR] = "/spi@fe2b/flash@0",
[BROM_BOOTSOURCE_SD] = "/mmc@fe2c",
[BROM_BOOTSOURCE_SPINOR_RK3588] = "/spi@fe2b/flash@0",
+ [BROM_BOOTSOURCE_USB] = "/usbdrd3_0/usb@fc00",
};
static struct mm_region rk3588_mem_map[] = {
--
2.34.1
[PATCH v2 07/10] ARM: mach-rockchip: spl-boot-order: add possibility to DFU
Add DFU as a possible SPL boot media if the boot device is a
gadget device.
Signed-off-by: Eugen Hristev
---
arch/arm/mach-rockchip/spl-boot-order.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-rockchip/spl-boot-order.c
b/arch/arm/mach-rockchip/spl-boot-order.c
index 93b8e7de4d0d..89bbe449e86c 100644
--- a/arch/arm/mach-rockchip/spl-boot-order.c
+++ b/arch/arm/mach-rockchip/spl-boot-order.c
@@ -66,6 +66,9 @@ static int spl_node_to_boot_device(int node)
} else if (!uclass_get_device_by_of_offset(UCLASS_SPI_FLASH, node,
)) {
return BOOT_DEVICE_SPI;
+ } else if (!uclass_get_device_by_of_offset(UCLASS_USB_GADGET_GENERIC,
+ node, )) {
+ return BOOT_DEVICE_DFU;
}
/*
--
2.34.1
[PATCH v2 05/10] usb: dwc3: Increase DWC3 controller halt timeout
Since EP0 transactions need to be completed before the controller halt
sequence is finished, this may take some time depending on the host and the
enabled functions. Increase the controller halt timeout, so that we give
the controller sufficient time to handle EP0 transfers.
Signed-off-by: Wesley Cheng
Link: https://lore.kernel.org/r/20220901193625.8727-4-quic_wch...@quicinc.com
Cherry-picked from Linux: 461ee467507c ("usb: dwc3: Increase DWC3 controller
halt timeout")
Signed-off-by: Eugen Hristev
---
Not to be merged, I know Marek does not apply any patches to DWC3.
drivers/usb/dwc3/gadget.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 24a2c455b0a4..a86680719108 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -1356,7 +1356,7 @@ static int dwc3_gadget_set_selfpowered(struct usb_gadget
*g,
static int dwc3_gadget_run_stop(struct dwc3 *dwc, int is_on, int suspend)
{
u32 reg;
- u32 timeout = 500;
+ u32 timeout = 2000;
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
if (is_on) {
@@ -1385,6 +1385,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
dwc3_gadget_dctl_write_safe(dwc, reg);
do {
+ mdelay(2);
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
if (is_on) {
if (!(reg & DWC3_DSTS_DEVCTRLHLT))
@@ -1396,7 +1397,6 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
timeout--;
if (!timeout)
return -ETIMEDOUT;
- udelay(1);
} while (1);
dev_vdbg(dwc->dev, "gadget %s data soft-%s\n",
--
2.34.1
[PATCH v2 06/10] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes
Add bootph-all to gadget nodes to have the gadget available in SPL.
Signed-off-by: Eugen Hristev
---
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 5a3292699640..f453aeeaf526 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -221,10 +221,12 @@
};
{
+ bootph-all;
status = "okay";
};
_otg {
+ bootph-all;
rockchip,typec-vbus-det;
status = "okay";
};
@@ -271,6 +273,7 @@
};
_phy0 {
+ bootph-all;
orientation-switch;
svid = <0xff01>;
sbu1-dc-gpios = < RK_PA6 GPIO_ACTIVE_HIGH>;
@@ -293,14 +296,17 @@
};
_phy0_u3 {
+ bootph-all;
status = "okay";
};
_0 {
+ bootph-all;
status = "okay";
};
_dwc3_0 {
+ bootph-all;
dr_mode = "otg";
usb-role-switch;
--
2.34.1
[PATCH v2 04/10] usb: dwc3: core: Only handle soft-reset in DCTL
From: Venkatesh Yadav Abbarapu
[ Nguyen/Greg: Ported from Linux kernel commit
f4fd84ae0765a ("usb: dwc3: core: Only handle soft-reset in DCTL") ]
Make sure not to set run_stop bit or link state change request while
initiating soft-reset. Register read-modify-write operation may
unintentionally start the controller before the initialization completes
with its previous DCTL value, which can cause initialization failure.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Not to be merged, I know Marek does not apply any patches to DWC3.
drivers/usb/dwc3/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index bdfe51c3df96..06ca3fc96842 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -72,7 +72,8 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg |= DWC3_DCTL_CSFTRST;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ reg &= ~DWC3_DCTL_RUN_STOP;
+ dwc3_gadget_dctl_write_safe(dwc, reg);
/* Assert USB3 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
--
2.34.1
[PATCH v2 03/10] usb: dwc3: gadget: Don't send unintended link state change
From: Venkatesh Yadav Abbarapu
[ Nguyen/Felipe/Greg: Ported from Linux kernel commit
5b738211fb59 ("usb: dwc3: gadget: Don't send
unintended link state change") ]
DCTL.ULSTCHNGREQ is a write-only field. When doing a read-modify-write
to DCTL, the driver must make sure that there's no unintended link state
change request from whatever is read from DCTL.ULSTCHNGREQ. Set link
state change to no-action when the driver writes to DCTL.
Signed-off-by: Venkatesh Yadav Abbarapu
---
Not to be merged, I know Marek does not apply any patches to DWC3.
drivers/usb/dwc3/gadget.c | 16 +++-
drivers/usb/dwc3/gadget.h | 14 ++
2 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index eb416b832aad..24a2c455b0a4 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -62,7 +62,7 @@ int dwc3_gadget_set_test_mode(struct dwc3 *dwc, int mode)
return -EINVAL;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
return 0;
}
@@ -1382,7 +1382,7 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int
is_on, int suspend)
dwc->pullups_connected = false;
}
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
do {
reg = dwc3_readl(dwc->regs, DWC3_DSTS);
@@ -2047,10 +2047,8 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3
*dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_INITU1ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
-
reg &= ~DWC3_DCTL_INITU2ENA;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc3_disconnect_gadget(dwc);
dwc->start_config_issued = false;
@@ -2099,7 +2097,7 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_TSTCTRL_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
dwc->test_mode = false;
dwc3_stop_active_transfers(dwc);
@@ -2215,11 +2213,11 @@ static void dwc3_gadget_conndone_interrupt(struct dwc3
*dwc)
if (dwc->has_lpm_erratum && dwc->revision >= DWC3_REVISION_240A)
reg |= DWC3_DCTL_LPM_ERRATA(dwc->lpm_nyet_threshold);
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
} else {
reg = dwc3_readl(dwc->regs, DWC3_DCTL);
reg &= ~DWC3_DCTL_HIRD_THRES_MASK;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
}
dep = dwc->eps[0];
@@ -2327,7 +2325,7 @@ static void dwc3_gadget_linksts_change_interrupt(struct
dwc3 *dwc,
reg &= ~u1u2;
- dwc3_writel(dwc->regs, DWC3_DCTL, reg);
+ dwc3_gadget_dctl_write_safe(dwc, reg);
break;
default:
/* do nothing */
diff --git a/drivers/usb/dwc3/gadget.h b/drivers/usb/dwc3/gadget.h
index 7806ce59a27f..b48ec6b2372f 100644
--- a/drivers/usb/dwc3/gadget.h
+++ b/drivers/usb/dwc3/gadget.h
@@ -104,4 +104,18 @@ static inline u32 dwc3_gadget_ep_get_transfer_index(struct
dwc3 *dwc, u8 number)
return DWC3_DEPCMD_GET_RSC_IDX(res_id);
}
+/**
+ * dwc3_gadget_dctl_write_safe - write to DCTL safe from link state change
+ * @dwc: pointer to our context structure
+ * @value: value to write to DCTL
+ *
+ * Use this function when doing read-modify-write to DCTL. It will not
+ * send link state change request.
+ */
+static inline void dwc3_gadget_dctl_write_safe(struct dwc3 *dwc, u32 value)
+{
+ value &= ~DWC3_DCTL_ULSTCHNGREQ_MASK;
+ dwc3_writel(dwc->regs, DWC3_DCTL, value);
+}
+
#endif /* __DRIVERS_USB_DWC3_GADGET_H */
--
2.34.1
[PATCH v2 02/10] usb: dwc3: core: improve reset sequence
From: Venkatesh Yadav Abbarapu
[ Felipe: Ported from Linux kernel commit
f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
According to Synopsys Databook, we shouldn't be relying on
GCTL.CORESOFTRESET bit as that's only for debugging purposes.
Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
Host side block will be reset by XHCI driver if necessary. Note that this
reduces amount of time spent on dwc3_probe() by a long margin.
We're still gonna wait for reset to finish for a long time
(default to 1ms max), but tests show that the reset polling loop executed
at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
times in a row).
Without proper core reset, observing random issues like when the
USB(DWC3) is in device mode, the host device is not able to detect the
USB device.
Signed-off-by: Venkatesh Yadav Abbarapu
[eugen.hris...@collabora.com: keep the PHY resets code]
Signed-off-by: Eugen Hristev
---
Not to be merged, I know Marek does not apply any patches to DWC3.
drivers/usb/dwc3/core.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 5a8c29424578..bdfe51c3df96 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -60,17 +60,24 @@ static void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
static int dwc3_core_soft_reset(struct dwc3 *dwc)
{
u32 reg;
+ int retries = 1000;
- /* Before Resetting PHY, put Core in Reset */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg |= DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ /*
+* We're resetting only the device side because, if we're in host mode,
+* XHCI driver will reset the host block. If dwc3 was configured for
+* host-only mode, then we can return early.
+*/
+ if (dwc->dr_mode == USB_DR_MODE_HOST)
+ return 0;
+
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ reg |= DWC3_DCTL_CSFTRST;
+ dwc3_writel(dwc->regs, DWC3_DCTL, reg);
/* Assert USB3 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
reg |= DWC3_GUSB3PIPECTL_PHYSOFTRST;
dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
-
/* Assert USB2 PHY reset */
reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
reg |= DWC3_GUSB2PHYCFG_PHYSOFTRST;
@@ -88,14 +95,14 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc)
reg &= ~DWC3_GUSB2PHYCFG_PHYSOFTRST;
dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
- mdelay(100);
-
- /* After PHYs are stable we can take Core out of reset state */
- reg = dwc3_readl(dwc->regs, DWC3_GCTL);
- reg &= ~DWC3_GCTL_CORESOFTRESET;
- dwc3_writel(dwc->regs, DWC3_GCTL, reg);
+ do {
+ reg = dwc3_readl(dwc->regs, DWC3_DCTL);
+ if (!(reg & DWC3_DCTL_CSFTRST))
+ return 0;
+ udelay(1);
+ } while (--retries);
- return 0;
+ return -ETIMEDOUT;
}
/*
--
2.34.1
[PATCH v2 01/10] rockchip: allow env defines for SPL build
For environment in SPL, all these defines are required, otherwise
build fails:
[...]
include/env_default.h:120:9: note: in expansion of macro
‘CFG_EXTRA_ENV_SETTINGS’
120 | CFG_EXTRA_ENV_SETTINGS
| ^~
In file included from env/common.c:32:
[...]
Environment in SPL is needed e.g. for DFU, as dfu_alt is kept as
env variable.
Signed-off-by: Eugen Hristev
---
include/configs/rockchip-common.h | 4
1 file changed, 4 deletions(-)
diff --git a/include/configs/rockchip-common.h
b/include/configs/rockchip-common.h
index 9121bba37384..be20b135066e 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -11,8 +11,6 @@
#define CFG_CPUID_OFFSET 0x7
#endif
-#ifndef CONFIG_SPL_BUILD
-
#define BOOT_TARGETS "mmc1 mmc0 nvme scsi usb pxe dhcp spi"
#ifdef CONFIG_ARM64
@@ -28,6 +26,4 @@
"name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};" \
"name=rootfs,size=-,uuid="ROOT_UUID
-#endif
-
#endif /* _ROCKCHIP_COMMON_H_ */
--
2.34.1
[PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL
This series adds support for DFU in SPL for rockchip rk3588 on rock5b board. Namely, when SPL is loaded via rockusb (thus via USB), having the `same-as-spl` boot order item, after having detected that it was loaded from USB, it will lookup the gadget USB node in DT and boot via DFU. Some changes were required namely: - DFU needs environment, hence adding environment variables into DFU - added bootph-all to nodes such that they are available in SPL - insert gadget into boot order I had to port one patch for DWC3 from Linux, and include in this series the patches that are floating from Venkatesh that fixup the DWC3 (https://marc.info/?l=u-boot=168351919807081=2 ) I know that Marek NAKed them and I am fine with it, I am not trying to sneak in any patches, they are not to be merged, also this patch `usb: dwc3: Increase DWC3 controller halt timeout` is in the same bucket so Marek you can NAK this one as well, no problem, I am just sending out all the series so maybe the rockchip part for the gadget can be picked up and if people want to use the DFU SPL gadget can also manually pick the DWC3 patches. The branch with all the patches is available here : https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot Thanks! Changes in v2: - rebased on latest upstream which caused a change in the config patch. Eugen Hristev (7): rockchip: allow env defines for SPL build usb: dwc3: Increase DWC3 controller halt timeout ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes ARM: mach-rockchip: spl-boot-order: add possibility to DFU ARM: mach-rockchip: rk3588: add gadget device to the boot order rockchip: rk3588: prepare env for DFU configs: rockchip: rock5b-rk3588: enable DFU and related configs Venkatesh Yadav Abbarapu (3): usb: dwc3: core: improve reset sequence usb: dwc3: gadget: Don't send unintended link state change usb: dwc3: core: Only handle soft-reset in DCTL arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 6 + arch/arm/mach-rockchip/rk3588/rk3588.c | 1 + arch/arm/mach-rockchip/spl-boot-order.c | 3 +++ configs/rock5b-rk3588_defconfig | 18 +++--- drivers/usb/dwc3/core.c | 32 +++-- drivers/usb/dwc3/gadget.c | 20 +++- drivers/usb/dwc3/gadget.h | 14 +++ include/configs/rk3588_common.h | 9 ++- include/configs/rockchip-common.h | 4 9 files changed, 76 insertions(+), 31 deletions(-) -- 2.34.1
[PATCH v4 2/2] xilinx: board: Add support to pick bootscr address from DT
From: Algapally Santosh Sagar
The bootscript is expected at a default address specific to each
platform.
When high speed memory like Programmable Logic Double Data Rate RAM
(PL DDR RAM) or Higher Bandwidth Memory RAM (HBM) is used the boot.scr
may be loaded at a different offset. The offset needs to be set through
setenv. Due to the default values in some cases the boot.scr is falling
in between the kernel partition.
The bootscript address or the bootscript offset is fetched directly from
the DT and updated in the environment making it easier for automated
flows.
Signed-off-by: Algapally Santosh Sagar
Signed-off-by: Michal Simek
---
(no changes since v3)
Changes in v3:
- Rename get_bootscript_address() to ofnode_read_bootscript_address()
and move it to common location
- Fix alignments
Changes in v2:
- s/bootscr-offset-from-ram-start/bootscr-ram-offset/
- Aligned with https://github.com/devicetree-org/dt-schema/pull/105
board/xilinx/common/board.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 0328d68e7512..61dd998198e9 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -414,9 +414,25 @@ int board_late_init_xilinx(void)
if (!IS_ENABLED(CONFIG_MICROBLAZE)) {
ulong scriptaddr;
-
- scriptaddr = env_get_hex("scriptaddr", 0);
- ret |= env_set_hex("scriptaddr", gd->ram_base + scriptaddr);
+ u64 bootscr_address;
+ u64 bootscr_offset;
+
+ /* Fetch bootscr_address/bootscr_offset from DT and update */
+ if (!ofnode_read_bootscript_address(_address,
+ _offset)) {
+ if (bootscr_offset)
+ ret |= env_set_hex("scriptaddr",
+ gd->ram_base +
+ bootscr_offset);
+ else
+ ret |= env_set_hex("scriptaddr",
+ bootscr_address);
+ } else {
+ /* Update scriptaddr(bootscr offset) from env */
+ scriptaddr = env_get_hex("scriptaddr", 0);
+ ret |= env_set_hex("scriptaddr",
+ gd->ram_base + scriptaddr);
+ }
}
if (IS_ENABLED(CONFIG_ARCH_ZYNQ) || IS_ENABLED(CONFIG_MICROBLAZE))
--
2.36.1
