Re: [PATCH] mtd: spi-nor-core: Invert logic to reflect sst26 flash unlocked
út 22. 11. 2022 v 6:19 odesílatel Ashok Reddy Soma
napsal:
>
> From: Algapally Santosh Sagar
>
> flash_is_locked is changed to flash_is_unlocked with commit 513c6071ce73
> ("mtd: spi: Convert is_locked callback to is_unlocked"). sst26_is_locked()
> is also changed to sst26_is_unlocked() but the logic remained same.
> Invert the logic for the flash lock/unlock to work properly.
>
> Signed-off-by: Algapally Santosh Sagar
> Signed-off-by: Ashok Reddy Soma
> ---
>
> drivers/mtd/spi/spi-nor-core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
> index 78de3c5281..1ea8363d9f 100644
> --- a/drivers/mtd/spi/spi-nor-core.c
> +++ b/drivers/mtd/spi/spi-nor-core.c
> @@ -1600,7 +1600,7 @@ static int sst26_is_unlocked(struct spi_nor *nor,
> loff_t ofs, uint64_t len)
> ofs -= ofs & (SZ_64K - 1);
> len = len & (SZ_64K - 1) ? (len & ~(SZ_64K - 1)) + SZ_64K : len;
>
> - return sst26_lock_ctl(nor, ofs, len, SST26_CTL_CHECK);
> + return !sst26_lock_ctl(nor, ofs, len, SST26_CTL_CHECK);
> }
>
> static int sst_write_byteprogram(struct spi_nor *nor, loff_t to, size_t len,
> --
> 2.17.1
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH v2] usb: gadget: rndis: Prevent InformationBufferOffset manipulation
Prevent access to arbitrary memory locations in gen_ndis_set_resp
via manipulation of buf->InformationBufferOffset. Original
implementation permits manipulation of InformationBufferOffset to
exploit OID_GEN_CURRENT_PACKET_FILTER to set arbitrary memory contents
within a 32byte offset as the devices packet filter. The packet filter
value may be next retrieved using gen_ndis_query_resp so it is possible
to extract specific memory regions two bytes a time.
The rndis_query_response was not modified as neither the buffer offset
nor length passed to gen_ndis_query_resp is used.
Signed-off-by: Szymon Heidrich
---
V1 -> V2: Updated commit message
drivers/usb/gadget/rndis.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/rndis.c b/drivers/usb/gadget/rndis.c
index 13c327ea38..3948f2cc9a 100644
--- a/drivers/usb/gadget/rndis.c
+++ b/drivers/usb/gadget/rndis.c
@@ -855,14 +855,17 @@ static int rndis_set_response(int configNr,
rndis_set_msg_type *buf)
rndis_set_cmplt_type*resp;
rndis_resp_t*r;
+ BufLength = get_unaligned_le32(&buf->InformationBufferLength);
+ BufOffset = get_unaligned_le32(&buf->InformationBufferOffset);
+ if ((BufOffset > RNDIS_MAX_TOTAL_SIZE - 8) ||
+ (BufLength > RNDIS_MAX_TOTAL_SIZE - 8 - BufOffset))
+ return -EINVAL;
+
r = rndis_add_response(configNr, sizeof(rndis_set_cmplt_type));
if (!r)
return -ENOMEM;
resp = (rndis_set_cmplt_type *) r->buf;
- BufLength = get_unaligned_le32(&buf->InformationBufferLength);
- BufOffset = get_unaligned_le32(&buf->InformationBufferOffset);
-
#ifdef VERBOSE
debug("%s: Length: %d\n", __func__, BufLength);
debug("%s: Offset: %d\n", __func__, BufOffset);
--
2.38.1
[PATCH] arm: dts: ti: k3-am64-mcu: Add pinctrl
Add the definition of the pinctrl for the MCU domain.
Same as kernel commit 500e6dfbb465531150ac6e2ff0856dd357ddc8a4
Signed-off-by: Christian Gmeiner
---
arch/arm/dts/k3-am64-mcu.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/k3-am64-mcu.dtsi b/arch/arm/dts/k3-am64-mcu.dtsi
index 59cc58f7d0..2bb5c9ff17 100644
--- a/arch/arm/dts/k3-am64-mcu.dtsi
+++ b/arch/arm/dts/k3-am64-mcu.dtsi
@@ -97,4 +97,12 @@
clocks = <&k3_clks 79 0>;
clock-names = "gpio";
};
+
+ mcu_pmx0: pinctrl@4084000 {
+ compatible = "pinctrl-single";
+ reg = <0x00 0x4084000 0x00 0x84>;
+ #pinctrl-cells = <1>;
+ pinctrl-single,register-width = <32>;
+ pinctrl-single,function-mask = <0x>;
+ };
};
--
2.38.1
Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
On Fri, Dec 02, 2022 at 06:08:22PM +0100, Marek Vasut wrote:
> But here I would say this is a firmware bug and it might have to be handled
> like a firmware bug, i.e. with fixup in the partition parser. I seem to be
> changing my opinion here again.
I was thinking at this over the weekend, and I came to the following
ideas:
- we need some improvement on the fixup we already have in the
partition parser. We cannot ignore the fdt produced by U-Boot - as
bad as it is.
- the proposed fixup is fine for the immediate need, but it is
not going to be enough to cover the general issue with the U-Boot
generated partitions. U-Boot might keep generating partitions as direct
child of the nand controller even when a partitions{} node is
available. In this case the current parser just fails since it looks
only into it and it will find it empty.
- the current U-Boot only handle partitions{} as a direct child of the
nand-controller, the nand-chip is ignored. This is not the way it is
supposed to work. U-Boot code would need to be improved.
With all of that said I think that Miquel is right
> When a patch breaks a board and there is no straight fix, you revert
> it, then you think harder. That's what I am saying. This is a temporary
> solution.
?
Francesco
[GIT PULL] xilinx patches for v2023.01-rc3-v2
Hi Tom, please pull these changes to your tree. I thought that we are running regression against upstream regularly but it looks like that it wasn't the case. Based on internal upgrade to rc2 version we found some issues with mini configurations which are major fixes in this pull request. There are also some other fixes too. buildman and gitlab CI are not showing any issue. Thanks, Michal The following changes since commit d2c5607edde2544e059fa871927877213f6bd532: Merge tag 'efi-2023-01-rc3' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-12-04 10:01:48 -0500) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2023.01-rc3-v2 for you to fetch changes up to 7ad3c09e7911e71c9a16a30aa052093a8f9b7e7c: mtd: spi-nor-core: Invert logic to reflect sst26 flash unlocked (2022-12-05 10:01:45 +0100) Xilinx changes for v2023.01-rc3-v2 xilinx: - Fix MAC address selection for System Controller from FRU - Cleanup Kconfig (ZYNQ_MAC_IN_EEPROM symbol) versal: - Create u-boot.elf for mini spi configurations versal-net: - Enable MT35XU flash zynq: - Add missing timer to DT for mini configurations zynqmp: - Do not include psu_init to U-Boot by default - Do not enable IPI by default to mini U-Boot - Update Luca's fragment - Fix SPL_FS_LOAD_PAYLOAD_NAME usage spi: - gqspi: Fix tapdelay values - gqspi: Fix 64bit address support - cadence: Remove condition for calling enable linear mode - nor-core: Invert logic to reflect sst26 flash unlocked net: - Add PCS/PMA phy support Algapally Santosh Sagar (1): mtd: spi-nor-core: Invert logic to reflect sst26 flash unlocked Andy Chiu (2): net: xilinx_axi: add PCS/PMA PHY net: xilinx_axi: check PCS/PMA PHY status in setup_phy Ashok Reddy Soma (2): spi: cadence-qspi: Remove condition for calling enable linear mode arm64: versal-net: Enable defconfig for Micron octal flashes Luca Ceresoli (1): board/xilinx/zynqmp/MAINTAINERS: change e-mail address for Luca Ceresoli Lukas Funke (1): arm64: zynqmp: dynamically mark r5 cores as used Michal Simek (6): xilinx: Add option to select SC id instead of DUT id for SC support xilinx: Remove unused ZYNQ_MAC_IN_EEPROM/ZYNQ_GEM_I2C_MAC_OFFSET entries arm64: zynqmp: Do not include psu_init to U-Boot by default arm64: zynqmp: Do not enable IPI by default ARM: zynq: Add missing twd timer for mini configurations xilinx: zynqmp: Fix SPL_FS_LOAD_PAYLOAD_NAME usage T Karthik Reddy (1): spi: zynqmp_gqspi: Update tapdelay value Venkatesh Yadav Abbarapu (2): arm64: versal: Enable REMAKE_ELF for mini_ospi/mini_qspi spi: zynqmp_qspi: Add support for 64-bit read/write arch/arm/Kconfig | 4 +- arch/arm/dts/zynq-cse-nand.dts | 7 ++ arch/arm/dts/zynq-cse-nor.dts | 7 ++ arch/arm/dts/zynq-cse-qspi.dtsi| 7 ++ arch/arm/mach-zynqmp/Kconfig | 9 ++- arch/arm/mach-zynqmp/Makefile | 2 +- arch/arm/mach-zynqmp/include/mach/hardware.h | 4 +- arch/arm/mach-zynqmp/mp.c | 26 board/xilinx/Kconfig | 26 +++- board/xilinx/common/fru.h | 1 + board/xilinx/common/fru_ops.c | 6 +- board/xilinx/zynqmp/MAINTAINERS| 2 +- board/xilinx/zynqmp/Makefile | 6 +- board/xilinx/zynqmp/zynqmp.c | 45 +++-- configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 3 - configs/syzygy_hub_defconfig | 2 - configs/xilinx_versal_mini_ospi_defconfig | 1 + configs/xilinx_versal_mini_qspi_defconfig | 1 + configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_zynqmp_mini_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 +- configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 +- configs/xilinx_zynqmp_mini_nand_defconfig | 2 +- configs/xilinx_zynqmp_mini_nand_single_defconfig | 2 +- configs/xilinx_zynqmp_mini_qspi_defconfig | 2 +- configs/xilinx_zynqmp_virt_defconfig | 2 - drivers/mtd/spi/spi-nor-core.c | 2 +- drivers/net/xilinx_axi_emac.c | 70 +++- drivers/spi/cadence_qspi_apb.c
Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Hello Miquel
On Fri, Dec 02, 2022 at 06:20:02PM +0100, Francesco Dolcini wrote:
> On Fri, Dec 02, 2022 at 05:42:55PM +0100, Miquel Raynal wrote:
> > Please also do it with the NAND chip described. If, when the NAND chip
> > is described U-Boot tries to create partitions in the controller node,
> > then the situation is even worse than I thought. But I believe
>
> It's like that for U-Boot older than v2022.04 ... and IMO we cannot
> ignore it.
>
> Said that from the code U-Boot looks into a `partition{}` node only as a
> direct child of the nand-controller, if there is a nand-chip in between
> the nand-controller{} and the partitions{} it will just ignore it.
>
> I could try to see what it is doing exactly, but I would need a little
> bit more time, I just tried changing the DTS as wrote I got a non
> bootable system.
If I have a nand-chip { partitions {} } described in the dts U-Boot
(even the latest one) ignores it and generates the partition as child of
the nand controller, the linux parser however see that partitions{}
exists, even if empty, and ignore the partition directly defined as
child of the nand controller.
TL;DR: parser fails and boot fails according to that.
Francesco
Re: [PATCH 1/1] mvebu: fix end-of-array check
Hi!
On 12/4/22 11:39, Pali Rohár wrote:
Hello!
I would suggest to change description of the patch from
"mvebu: fix end-of-array check"
to something like:
"arm: mvebu: Espressobin: fix end-of-array check in env"
as it affects only Espressobin boards (not other mvebu).
Yes, please update the commit subject here.
Stefan, please look below as this issue/fix is important.
Yes.
On Wednesday 30 November 2022 13:33:40 Derek LaHousse wrote:
Properly seek the end of default_environment variables.
The current algorithm overwrites from the second variable. This
replacement finds the end of the array of strings.
Stomped variables include "board", "soc", "loadaddr". These can be
seen on a "env default -a" after patch, but they are not seen with a
version before the patch.
This is a real issue which I introduced in the past. So it some fix for
this issue should be pulled into the v2023.01 release.
Understood.
Signed-off-by: Derek LaHousse
---
board/Marvell/mvebu_armada-37xx/board.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index c6ecc323bb..ac29ac5b95 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -100,8 +100,11 @@ int board_late_init(void)
return 0;
/* Find free buffer in default_environment[] for new variables
*/
- while (*ptr != '\0' && *(ptr+1) != '\0') ptr++;
- ptr += 2;
+ if (*ptr != '\0') { // Defending against empty default env
+ while ((i = strlen(ptr)) != 0) {
+ ptr += i + 1;
+ }
+ }
If I'm looking at the outer-if condition correctly then it is not
needed. strlen("") returns zero and so inner-while loop stops
immediately.
My proposed fix for this issue was just changing correct while loop
check to ensure that ptr is set after the _last_ variable.
- while (*ptr != '\0' && *(ptr+1) != '\0') ptr++;
- ptr += 2;
+ while (*ptr != '\0' || *(ptr+1) != '\0') ptr++;
+ ptr++;
Both changes should be equivalent, but I'm not sure which one is more
readable. The original issue was introduced really by non-readable
code...
Stefan, do you have a preference which one fix is better / more
readable?
I would prefer to get Pali's corrected version included. Could you
please prepare a v2 patch with this update and also with the added
or changed patch subject.
It would be really a good idea if you try to check if any of those
proposed fixes/patches are now really correct.
Yes, please do.
Thanks,
Stefan
Re: [PATCH] net: eth-uclass: change state before stop() in eth_halt()
Hi Marek,
On 04/12/2022 03:17, Marek Vasut wrote:
On 12/2/22 11:36, Niel Fourie wrote:
Hi Marek,
Hi,
On 01/12/2022 11:44, Marek Vasut wrote:
On 12/1/22 09:24, Lukasz Majewski wrote:
On Wed, 30 Nov 2022 17:42:25 +0100
Niel Fourie wrote:
In eth_halt(), change the private uclass state before calling
stop() instead of afterwards, to avoid writing to memory which
may have been freed during stop().
In the ethernet gadget implementation, the gadget device gets
probed during start() and removed during stop(), which includes
freeing `uclass_priv_` to which `priv` is pointing. Writing to
`priv` after stop() may corrupt the `fd` member of `struct
malloc_chunk`, which represents the freed block, and could cause
hard-to-debug crashes on subsequent calls to malloc()/free().
Signed-off-by: Niel Fourie
Cc: Ramon Fried
Cc: Marek Vasut
Cc: Lukasz Majewski
---
net/eth-uclass.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index f41da4b37b3..bc3b9751e32 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -342,9 +342,9 @@ void eth_halt(void)
if (!priv || !priv->running)
return;
- eth_get_ops(current)->stop(current);
priv->state = ETH_STATE_PASSIVE;
priv->running = false;
+ eth_get_ops(current)->stop(current);
}
int eth_is_active(struct udevice *dev)
Reviewed-by: Lukasz Majewski
How come nobody triggered this problem with regular ethernet in U-Boot ?
If this is isolated to USB gadget ethernet, then please do not hack
around this in core networking code, but rather fix the USB ethernet
gadget itself. It seems that gadget code should not unregister the
gadget in drivers/usb/gadget/ether.c _usb_eth_halt() , at least not
fully.
The reason is simple, the regular ethernet drivers do not get removed
on stop() like for the gadget ethernet driver, and in their case
`priv` is still valid.
The suggestion for a proper fix is in the last paragraph above -- do not
unregister the usb ethernet gadget device in halt(), keep the gadget
device registered. Then the priv pointer would be valid. (*)
I agree on your point that reworking the ethernet gadget code would be
preferable, but this would be a much bigger effort (and if I were to
do it, I would probably introduce even more bugs). I am not certain
whether this would not also affect the non-DM gadget implementation as
well, which still contain drivers like ci_udc.c which does not appear
to have been ported to DM gadget yet? (I only see DM USB there...)
That said, I am not certain whether this is not also bug, as I am not
certain whether the assumption that `priv` should be available after
stop() is valid or not.
The documentation at
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/develop/driver-model/ethernet.rst?plain=1#L135 states:
The **stop** function should turn off / disable the hardware and place
it back in its reset state. It can be called at any time (before any
call to the related start() function), so make sure it can handle this
sort of thing.
The ->stop callback is supposed to stop the interface, turn off its DMA,
but NOT deallocate the device (and its associated data) behind it.
In such a complete reset state I am not certain whether the assumption
that `priv` should exist is still valid, at least not without another
call to dev_get_uclass_priv() and revalidating it first?
In case a device is probe()d, its private data are also allocated and
available, so yes, 'priv' pointer should still be valid.
Granted, the usb gadget driver implementation is problematic, and it
definitely belongs on the TODO list.
That being said, priv not being valid at this stage is not a new
problem, as validation for it after stop() was explicitly added in
commit c3211708 ("net: eth-uclass: Fix for DM USB ethernet support") for
this reason 4 years ago. Fortunately in that case, it just fixed a null
pointer de-reference, not corruption of freed memory.
Lastly, this assumption that priv is still valid is rather new and it
was introduced here:
https://source.denx.de/u-boot/u-boot/-/commit/fa795f452541ce07b33be603de36cac3c5d7dfcf
I disagree, the device private data are valid during the entire lifespan
of the device. That assumption has been baked into the driver model
itself and far predates that commit.
In case of a usb ethernet, the lifespan of the device starts with the
'bind' command which triggers the ->bind callback, and first use which
triggers its ->probe callback. The lifespan ends with 'unbind' command
or OS boot, which triggers ->remove callback and ->unbind callbacks.
This commit appears to be a workaround for drivers which cannot deal
with stop() being called at any time as required in the above quoted
documentation.
This commit prevents network device ->start() from being called multiple
times, which is a valid precaution, as calling start while the interface
is already up would interfere wit
Re: [PATCH 1/2] drivers: watchdog: Enhance watchdog support in SPL for Stratix 10 and Agilex
On 11/22/22 15:18, Jit Loon Lim wrote: From: Siew Chin Lim Change watchdog default timeout to 10 seconds and enable watchdog before initializing other component (example: DDR). Thus, watchdog need to be fully executed in onchip ram. Please find some comments below. Signed-off-by: Siew Chin Lim Signed-off-by: Jit Loon Lim --- arch/arm/mach-socfpga/spl_agilex.c | 17 + arch/arm/mach-socfpga/spl_s10.c| 14 +++--- drivers/watchdog/Kconfig | 2 +- 3 files changed, 17 insertions(+), 16 deletions(-) diff --git a/arch/arm/mach-socfpga/spl_agilex.c b/arch/arm/mach-socfpga/spl_agilex.c index ee5a9dc1e2..c279f97cea 100644 --- a/arch/arm/mach-socfpga/spl_agilex.c +++ b/arch/arm/mach-socfpga/spl_agilex.c @@ -20,7 +20,7 @@ #include #include #include -#include +#include #include DECLARE_GLOBAL_DATA_PTR; @@ -40,13 +40,6 @@ void board_init_f(ulong dummy) writel(SYSMGR_WDDBG_PAUSE_ALL_CPU, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_WDDBG); -#ifdef CONFIG_HW_WATCHDOG - /* Enable watchdog before initializing the HW */ - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1); - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0); - hw_watchdog_init(); -#endif - The patch also removes the CONFIG_HW_WATCHDOG stuff, which is probably unused right now. Could you please also mention this in the commit message? /* ensure all processors are not released prior Linux boot */ writeq(0, CPU_RELEASE_ADDR); @@ -60,6 +53,14 @@ void board_init_f(ulong dummy) hang(); } + /* +* Enable watchdog as early as possible before initializing other +* component. Watchdog need to be enabled after clock driver because +* it will retrieve the clock frequency from clock driver. +*/ + if (CONFIG_IS_ENABLED(WDT)) + initr_watchdog(); + initr_watchdog() will get called from spl/common/spl/spl.c: board_init_r(). Is this too late? How much time passes between these two code path's? Thanks, Stefan preloader_console_init(); print_reset_info(); cm_print_clock_quick_summary(); diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-socfpga/spl_s10.c index c20e87cdbe..4044dc335e 100644 --- a/arch/arm/mach-socfpga/spl_s10.c +++ b/arch/arm/mach-socfpga/spl_s10.c @@ -21,7 +21,7 @@ #include #include #include -#include +#include #include DECLARE_GLOBAL_DATA_PTR; @@ -41,12 +41,12 @@ void board_init_f(ulong dummy) writel(SYSMGR_WDDBG_PAUSE_ALL_CPU, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_WDDBG); -#ifdef CONFIG_HW_WATCHDOG - /* Enable watchdog before initializing the HW */ - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1); - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0); - hw_watchdog_init(); -#endif + /* +* Enable watchdog as early as possible before initializing other +* component. +*/ + if (CONFIG_IS_ENABLED(WDT)) + initr_watchdog(); /* ensure all processors are not released prior Linux boot */ writeq(0, CPU_RELEASE_ADDR); diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index 50e6a1efba..a6c242ac9d 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -27,7 +27,7 @@ config WATCHDOG_TIMEOUT_MSECS int "Watchdog timeout in msec" default 128000 if ARCH_MX31 || ARCH_MX5 || ARCH_MX6 default 128000 if ARCH_MX7 || ARCH_VF610 - default 3 if ARCH_SOCFPGA + default 1 if ARCH_SOCFPGA default 16000 if ARCH_SUNXI default 6 help 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: Re: [PATCH 1/1] drivers:spi:fix some typos
Thank you for your suggestions. The next patch will be modified according to
your suggestions.
Thanks,
Pengfei Fan
2022-12-05 05:17:05 "Simon Glass" 写道：
> On Sat, 3 Dec 2022 at 01:26, Pengfei Fan
> wrote:
> >
> > Fix some typos in spi drivers
> >
> > Signed-off-by: Pengfei Fan
> > ---
> > drivers/spi/bcm63xx_hsspi.c | 2 +-
> > drivers/spi/cadence_qspi.c| 2 +-
> > drivers/spi/fsl_dspi.c| 4 ++--
> > drivers/spi/mtk_snfi_spi.c| 4 ++--
> > drivers/spi/mvebu_a3700_spi.c | 2 +-
> > drivers/spi/omap3_spi.c | 2 +-
> > drivers/spi/rk_spi.c | 2 +-
> > drivers/spi/sh_qspi.c | 2 +-
> > drivers/spi/spi-aspeed-smc.c | 4 ++--
> > drivers/spi/spi-qup.c | 2 +-
> > drivers/spi/spi-sifive.c | 2 +-
> > 11 files changed, 14 insertions(+), 14 deletions(-)
>
> Reviewed-by: Simon Glass
>
> [..]
>
> > diff --git a/drivers/spi/sh_qspi.c b/drivers/spi/sh_qspi.c
> > index 5ba8a8ea79..23af77f3df 100644
> > --- a/drivers/spi/sh_qspi.c
> > +++ b/drivers/spi/sh_qspi.c
> > @@ -160,7 +160,7 @@ static int sh_qspi_xfer_common(struct sh_qspi_slave
> > *ss, unsigned int bitlen,
> > }
> >
> > if (bitlen % 8) {
> > - printf("%s: bitlen is not 8bit alined %d", __func__,
> > bitlen);
> > + printf("%s: bitlen is not 8bit aligned %d", __func__,
> > bitlen);
> > return 1;
> > }
> >
>
> But we should not be using __func__. Better:
>
> log_warning("bitlen is not 8bit aligned %d", bitlen);
>
> Also need to put this at the very top of the file:
>
> #define LOG_CATEGORY UCLASS_SPI
>
> Regards,
> Simon
RE: [PATCH 1/2] drivers: watchdog: Enhance watchdog support in SPL for Stratix 10 and Agilex
-Original Message- From: Stefan Roese Sent: Monday, 5 December, 2022 8:28 PM To: Lim, Jit Loon ; u-boot@lists.denx.de Cc: Jagan Teki ; Vignesh R ; Vasut, Marek ; Simon ; Chee, Tien Fong ; Hea, Kok Kiang ; Lim, Elly Siew Chin ; Kho, Sin Hui ; Lokanathan, Raaj ; Maniyam, Dinesh ; Ng, Boon Khai ; Yuslaimi, Alif Zakuan ; Chong, Teik Heng ; Zamri, Muhammad Hazim Izzat ; Tang, Sieu Mun Subject: Re: [PATCH 1/2] drivers: watchdog: Enhance watchdog support in SPL for Stratix 10 and Agilex On 11/22/22 15:18, Jit Loon Lim wrote: > From: Siew Chin Lim > > Change watchdog default timeout to 10 seconds and enable watchdog > before initializing other component (example: DDR). Thus, watchdog > need to be fully executed in onchip ram. Please find some comments below. > Signed-off-by: Siew Chin Lim > Signed-off-by: Jit Loon Lim > --- > arch/arm/mach-socfpga/spl_agilex.c | 17 + > arch/arm/mach-socfpga/spl_s10.c| 14 +++--- > drivers/watchdog/Kconfig | 2 +- > 3 files changed, 17 insertions(+), 16 deletions(-) > > diff --git a/arch/arm/mach-socfpga/spl_agilex.c > b/arch/arm/mach-socfpga/spl_agilex.c > index ee5a9dc1e2..c279f97cea 100644 > --- a/arch/arm/mach-socfpga/spl_agilex.c > +++ b/arch/arm/mach-socfpga/spl_agilex.c > @@ -20,7 +20,7 @@ > #include > #include > #include -#include > +#include > #include > > DECLARE_GLOBAL_DATA_PTR; > @@ -40,13 +40,6 @@ void board_init_f(ulong dummy) > writel(SYSMGR_WDDBG_PAUSE_ALL_CPU, > socfpga_get_sysmgr_addr() + SYSMGR_SOC64_WDDBG); > > -#ifdef CONFIG_HW_WATCHDOG > - /* Enable watchdog before initializing the HW */ > - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1); > - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0); > - hw_watchdog_init(); > -#endif > - The patch also removes the CONFIG_HW_WATCHDOG stuff, which is probably unused right now. Could you please also mention this in the commit message? Sure. > /* ensure all processors are not released prior Linux boot */ > writeq(0, CPU_RELEASE_ADDR); > > @@ -60,6 +53,14 @@ void board_init_f(ulong dummy) > hang(); > } > > + /* > + * Enable watchdog as early as possible before initializing other > + * component. Watchdog need to be enabled after clock driver because > + * it will retrieve the clock frequency from clock driver. > + */ > + if (CONFIG_IS_ENABLED(WDT)) > + initr_watchdog(); > + initr_watchdog() will get called from spl/common/spl/spl.c: board_init_r(). Is this too late? How much time passes between these two code path's? We do not have the actual measurement now and shall update once we get it measured. Thanks, Stefan > preloader_console_init(); > print_reset_info(); > cm_print_clock_quick_summary(); > diff --git a/arch/arm/mach-socfpga/spl_s10.c > b/arch/arm/mach-socfpga/spl_s10.c index c20e87cdbe..4044dc335e 100644 > --- a/arch/arm/mach-socfpga/spl_s10.c > +++ b/arch/arm/mach-socfpga/spl_s10.c > @@ -21,7 +21,7 @@ > #include > #include > #include -#include > +#include > #include > > DECLARE_GLOBAL_DATA_PTR; > @@ -41,12 +41,12 @@ void board_init_f(ulong dummy) > writel(SYSMGR_WDDBG_PAUSE_ALL_CPU, > socfpga_get_sysmgr_addr() + SYSMGR_SOC64_WDDBG); > > -#ifdef CONFIG_HW_WATCHDOG > - /* Enable watchdog before initializing the HW */ > - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 1); > - socfpga_per_reset(SOCFPGA_RESET(L4WD0), 0); > - hw_watchdog_init(); > -#endif > + /* > + * Enable watchdog as early as possible before initializing other > + * component. > + */ > + if (CONFIG_IS_ENABLED(WDT)) > + initr_watchdog(); > > /* ensure all processors are not released prior Linux boot */ > writeq(0, CPU_RELEASE_ADDR); > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index > 50e6a1efba..a6c242ac9d 100644 > --- a/drivers/watchdog/Kconfig > +++ b/drivers/watchdog/Kconfig > @@ -27,7 +27,7 @@ config WATCHDOG_TIMEOUT_MSECS > int "Watchdog timeout in msec" > default 128000 if ARCH_MX31 || ARCH_MX5 || ARCH_MX6 > default 128000 if ARCH_MX7 || ARCH_VF610 > - default 3 if ARCH_SOCFPGA > + default 1 if ARCH_SOCFPGA > default 16000 if ARCH_SUNXI > default 6 > help 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] arm: dts: ti: k3-am64-mcu: Add pinctrl
On 12:10-20221205, Christian Gmeiner wrote:
> Add the definition of the pinctrl for the MCU domain.
>
> Same as kernel commit 500e6dfbb465531150ac6e2ff0856dd357ddc8a4
>
> Signed-off-by: Christian Gmeiner
> ---
> arch/arm/dts/k3-am64-mcu.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/dts/k3-am64-mcu.dtsi b/arch/arm/dts/k3-am64-mcu.dtsi
> index 59cc58f7d0..2bb5c9ff17 100644
> --- a/arch/arm/dts/k3-am64-mcu.dtsi
> +++ b/arch/arm/dts/k3-am64-mcu.dtsi
> @@ -97,4 +97,12 @@
> clocks = <&k3_clks 79 0>;
> clock-names = "gpio";
> };
> +
> + mcu_pmx0: pinctrl@4084000 {
> + compatible = "pinctrl-single";
> + reg = <0x00 0x4084000 0x00 0x84>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x>;
> + };
> };
> --
> 2.38.1
>
Reviewed-by: Nishanth Menon
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH 4/5] arm: dts: socfpga: Update existing FW & SEC config to DTS
From: Tien Fong Chee
Update N5X existing firewall and secure register settings in source codes to
device tree.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
arch/arm/dts/socfpga_n5x-u-boot.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/socfpga_n5x-u-boot.dtsi
b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
index 98cbd4c808..c25d99366a 100644
--- a/arch/arm/dts/socfpga_n5x-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
@@ -132,6 +132,8 @@
&spi1 {
clocks = <&clkmgr N5X_L4_MAIN_CLK>;
+};
+
&socfpga_secreg {
soc_noc_fw_mpfe_csr_inst_0_mpfe_scr@f802 {
reg = <0xf802 0x001c>;
--
2.26.2
[PATCH 3/5] arm: dts: socfpga: Copy existing FW & SEC config to DTS
From: Tien Fong Chee
Copy existing firewall and secure register settings in source codes to
device tree.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
arch/arm/dts/socfpga_agilex-u-boot.dtsi| 13 ++-
arch/arm/dts/socfpga_n5x-u-boot.dtsi | 10 ++
arch/arm/dts/socfpga_soc64_u-boot.dtsi | 112 +
arch/arm/dts/socfpga_stratix10-u-boot.dtsi | 17 +++-
4 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/socfpga_soc64_u-boot.dtsi
diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
index 08f7cf7f7a..774cebd30c 100644
--- a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_agilex-u-boot.dtsi
@@ -2,9 +2,10 @@
/*
* U-Boot additions
*
- * Copyright (C) 2019-2020 Intel Corporation
+ * Copyright (C) 2019-2021 Intel Corporation
*/
+#include "socfpga_soc64_u-boot.dtsi"
#include "socfpga_soc64_fit-u-boot.dtsi"
/{
@@ -84,6 +85,16 @@
u-boot,dm-pre-reloc;
};
+&socfpga_secreg {
+ soc_noc_fw_mpfe_csr_inst_0_mpfe_scr@f802 {
+ reg = <0xf802 0x001c>;
+ intel,offset-settings =
+ <0x 0x00010101>,
+ <0x0004 0x0001>;
+ u-boot,dm-pre-reloc;
+ };
+};
+
&sysmgr {
compatible = "altr,sys-mgr", "syscon";
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/socfpga_n5x-u-boot.dtsi
b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
index d377ae5f69..98cbd4c808 100644
--- a/arch/arm/dts/socfpga_n5x-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
@@ -5,6 +5,7 @@
* Copyright (C) 2020-2021 Intel Corporation
*/
+#include "socfpga_soc64_u-boot.dtsi"
#include "socfpga_soc64_fit-u-boot.dtsi"
#include
@@ -130,6 +131,15 @@
&spi1 {
clocks = <&clkmgr N5X_L4_MAIN_CLK>;
+
+&socfpga_secreg {
+ soc_noc_fw_mpfe_csr_inst_0_mpfe_scr@f802 {
+ reg = <0xf802 0x001c>;
+ intel,offset-settings =
+ <0x 0x00010101>,
+ <0x0004 0x0001>;
+ u-boot,dm-pre-reloc;
+ };
};
&sysmgr {
diff --git a/arch/arm/dts/socfpga_soc64_u-boot.dtsi
b/arch/arm/dts/socfpga_soc64_u-boot.dtsi
new file mode 100644
index 00..34997b4c30
--- /dev/null
+++ b/arch/arm/dts/socfpga_soc64_u-boot.dtsi
@@ -0,0 +1,112 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2021 Intel Corporation
+ */
+
+/ {
+ soc {
+ socfpga_secreg: socfpga-secreg {
+ compatible = "intel,socfpga-secreg";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ i_sys_mgr_core@ffd12000 {
+ reg = <0xffd12000 0x0230>;
+ intel,offset-settings =
+ <0x0020 0xff01>,
+ <0x0024 0x>;
+ u-boot,dm-pre-reloc;
+ };
+
+ noc_fw_l4_per_l4_per_scr@ffd21000 {
+ reg = <0xffd21000 0x0074>;
+ intel,offset-settings =
+ <0x 0x01010001>,
+ <0x0004 0x01010001>,
+ <0x000c 0x01010001>,
+ <0x0010 0x01010001>,
+ <0x001c 0x01010001>,
+ <0x0020 0x01010001>,
+ <0x0024 0x01010001>,
+ <0x0028 0x01010001>,
+ <0x002c 0x01010001>,
+ <0x0030 0x01010001>,
+ <0x0034 0x01010001>,
+ <0x0040 0x01010001>,
+ <0x0044 0x01010001>,
+ <0x0048 0x01010001>,
+ <0x0050 0x01010001>,
+ <0x0054 0x01010001>,
+ <0x0058 0x01010001>,
+ <0x005c 0x01010001>,
+ <0x0060 0x01010001>,
+ <0x0064 0x01010001>,
+ <0x0068 0x01010001>,
+ <0x006c 0x01010001>,
+ <0x0070 0x01010001>;
+ u-boot,dm-pre-reloc;
+ };
+
+ noc_fw_l4_sys_l4_sys_s
[PATCH 1/5] doc: dtbinding: Add doc for privilege regs settings
From: Tien Fong Chee
Add a document to describe firewall and privilege register settings binding
information.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
.../misc/socfpga_secreg.txt | 26 +++
1 file changed, 26 insertions(+)
create mode 100644 doc/device-tree-bindings/misc/socfpga_secreg.txt
diff --git a/doc/device-tree-bindings/misc/socfpga_secreg.txt
b/doc/device-tree-bindings/misc/socfpga_secreg.txt
new file mode 100644
index 00..66df51f613
--- /dev/null
+++ b/doc/device-tree-bindings/misc/socfpga_secreg.txt
@@ -0,0 +1,26 @@
+* Firewall and privilege register settings in device tree
+
+Required properties:
+
+
+- compatible: should contain "intel,socfpga-secreg"
+- intel,offset-settings: 32-bit offset address of block register, and then
+followed by 32-bit value
settings.
+
+Example:
+
+
+ socfpga_secreg: socfpga-secreg {
+ compatible = "intel,socfpga-secreg";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ u-boot,dm-pre-reloc;
+
+ i_sys_mgr@ffd12000 {
+ reg = <0xffd12000 0x0228>;
+ intel,offset-settings =
+ <0x0020 0xff01>,
+ <0x0024 0x>;
+ u-boot,dm-pre-reloc;
+ };
+ };
--
2.26.2
[PATCH 5/5] arm: socfpga: Switch FW settings from codes to DTS
From: Tien Fong Chee
Switching the firewall, and high privilege registers setting in source
codes over to device tree implementation.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
arch/arm/Kconfig | 2 ++
arch/arm/mach-socfpga/Makefile| 29 +--
.../include/mach/system_manager_soc64.h | 3 ++
arch/arm/mach-socfpga/spl_agilex.c| 9 --
arch/arm/mach-socfpga/spl_n5x.c | 8 +++--
arch/arm/mach-socfpga/spl_s10.c | 11 ---
configs/socfpga_agilex_nand_atf_defconfig | 1 -
configs/socfpga_agilex_nand_defconfig | 1 -
configs/socfpga_n5x_atf_defconfig | 1 -
configs/socfpga_n5x_defconfig | 1 -
configs/socfpga_n5x_vab_defconfig | 1 -
configs/socfpga_stratix10_nand_atf_defconfig | 1 -
...onfig => socfpga_stratix10_nand_defconfig} | 18 ++--
13 files changed, 54 insertions(+), 32 deletions(-)
copy configs/{socfpga_agilex_nand_defconfig =>
socfpga_stratix10_nand_defconfig} (82%)
mode change 100755 => 100644
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 949ebb46ba..128039e207 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1115,6 +1115,8 @@ config ARCH_SOCFPGA
select SPL_LIBGENERIC_SUPPORT
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_SOC64
+ select SPL_DRIVERS_MISC if TARGET_SOCFPGA_SOC64
+ select SPL_SOCFPGA_SEC_REG if TARGET_SOCFPGA_SOC64
select SPL_SERIAL
select SPL_SYSRESET
select SPL_WATCHDOG
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 58a486f6de..0112555926 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -35,10 +35,18 @@ obj-y += mailbox_s10.o
obj-y += misc_soc64.o
obj-y += mmu-arm64_s10.o
obj-y += reset_manager_s10.o
+obj-y += smmu_s10.o
obj-y += system_manager_soc64.o
obj-y += timer_s10.o
obj-y += wrap_handoff_soc64.o
obj-y += wrap_pll_config_soc64.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_ARMV8_PSCI) += psci.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_ecc_dbe_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_fpga_reconfig_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_registers_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_rsu_s10.o
+endif
endif
ifdef CONFIG_TARGET_SOCFPGA_AGILEX
@@ -49,11 +57,19 @@ obj-y += misc_soc64.o
obj-y += mmu-arm64_s10.o
obj-y += reset_manager_s10.o
obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH) += secure_vab.o
+obj-y += smmu_s10.o
obj-y += system_manager_soc64.o
obj-y += timer_s10.o
obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH) += vab.o
obj-y += wrap_handoff_soc64.o
obj-y += wrap_pll_config_soc64.o
+ifndef CONFIG_SPL_BUILD
+obj-$(CONFIG_ARMV8_PSCI) += psci.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_ecc_dbe_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_fpga_reconfig_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_registers_s10.o
+obj-$(CONFIG_ARMV8_PSCI) += smc_rsu_s10.o
+endif
endif
ifdef CONFIG_TARGET_SOCFPGA_N5X
@@ -71,10 +87,6 @@ obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)+= vab.o
obj-y += wrap_handoff_soc64.o
obj-y += wrap_pll_config_soc64.o
ifndef CONFIG_SPL_BUILD
-obj-y += rsu.o
-obj-y += rsu_ll_qspi.o
-obj-y += rsu_misc.o
-obj-y += rsu_s10.o
obj-$(CONFIG_ARMV8_PSCI) += psci.o
obj-$(CONFIG_ARMV8_PSCI) += smc_ecc_dbe_s10.o
obj-$(CONFIG_ARMV8_PSCI) += smc_registers_s10.o
@@ -90,21 +102,20 @@ obj-y += wrap_iocsr_config.o
obj-y += wrap_pinmux_config.o
obj-y += wrap_sdram_config.o
endif
-ifdef CONFIG_TARGET_SOCFPGA_SOC64
-obj-y += firewall.o
-obj-y += spl_soc64.o
-endif
ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
obj-y += spl_a10.o
endif
ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
obj-y += spl_s10.o
+obj-y += spl_soc64.o
endif
ifdef CONFIG_TARGET_SOCFPGA_AGILEX
obj-y += spl_agilex.o
+obj-y += spl_soc64.o
endif
ifdef CONFIG_TARGET_SOCFPGA_N5X
obj-y += spl_n5x.o
+obj-y += spl_soc64.o
endif
else
obj-$(CONFIG_SPL_ATF) += secure_reg_helper.o
@@ -117,4 +128,4 @@ CFLAGS_wrap_iocsr_config.o +=
-I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_pinmux_config.o+= -I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_pll_config.o += -I$(srctree)/board/$(BOARDDIR)
CFLAGS_wrap_sdram_config.o += -I$(srctree)/board/$(BOARDDIR)
-endif
+endif
\ No newline at end of file
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
index 4441649a31..c24319ffe5 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
@@ -16,6 +16,9 @@ void populate_sysmgr_pinmux(void);
#define SYSMGR_SOC64_DMA_PERIPH0x24
#define SYSMGR_SOC64_SDMMC 0x28
#define SYSMGR_SOC64_SDMMC_L3MASTER0x2c
+#define SYSMGR_SOC64_NANDGRP_L3MASTER 0x34
+#define SYSMGR_SOC64_USB0_L3MASTER 0x38
+#define SYSMGR_SOC64_USB1_L3MAS
[PATCH 2/5] misc: socfpga_secreg: Enable register settings in DTS
From: Tien Fong Chee
Enable register settings from device tree in SPL, which require high
privilege access like firewall registers. This also provides user a clean
interface and all register settings are centralized in one place, device
tree.
Signed-off-by: Tien Fong Chee
Signed-off-by: Jit Loon Lim
---
drivers/misc/Kconfig | 9
drivers/misc/Makefile | 2 +
drivers/misc/socfpga_secreg.c | 86 +++
3 files changed, 97 insertions(+)
create mode 100644 drivers/misc/socfpga_secreg.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a6da6e215d..d9da836675 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -645,4 +645,13 @@ config SL28CPLD
the base driver which provides common access methods for the
sub-drivers.
+config SPL_SOCFPGA_SEC_REG
+ bool "Enable register setting from device tree in SPL"
+ depends on SPL
+ help
+ Enable register setting from device tree in SPL, which require
+ high privilege access like firewall registers. This also
+ provides user a clean interface and all register settings are
+ centralized in one place, device tree.
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d494639cd9..183d92b6e0 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -29,6 +29,7 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SANDBOX) += spltest_sandbox.o
endif
endif
+
obj-$(CONFIG_ALI152X) += ali512x.o
obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
@@ -89,3 +90,4 @@ obj-$(CONFIG_K3_AVS0) += k3_avs.o
obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
+obj-$(CONFIG_SPL_SOCFPGA_SEC_REG) += socfpga_secreg.o
diff --git a/drivers/misc/socfpga_secreg.c b/drivers/misc/socfpga_secreg.c
new file mode 100644
index 00..a4b297e7f1
--- /dev/null
+++ b/drivers/misc/socfpga_secreg.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2021 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+static int socfpga_secreg_probe(struct udevice *dev)
+{
+ const fdt32_t *list;
+ fdt_addr_t offset, base;
+ fdt_val_t val, read_val;
+ int size, i;
+ u32 blk_sz, reg;
+ ofnode node;
+ const char *name = NULL;
+
+ debug("%s(dev=%p)\n", __func__, dev);
+
+ if (!dev_has_ofnode(dev))
+ return 0;
+
+ dev_for_each_subnode(node, dev) {
+ name = ofnode_get_name(node);
+ if (!name)
+ return -EINVAL;
+
+ if (ofnode_read_u32_index(node, "reg", 1, &blk_sz))
+ return -EINVAL;
+
+ base = ofnode_get_addr(node);
+ if (base == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+ debug("%s(node_offset 0x%lx node_name %s ", __func__,
+ node.of_offset, name);
+ debug("node addr 0x%llx blk sz 0x%x)\n", base, blk_sz);
+
+ list = ofnode_read_prop(node, "intel,offset-settings", &size);
+ if (!list)
+ return -EINVAL;
+
+ debug("%s(intel,offset-settings property size=%x)\n", __func__,
+ size);
+ size /= sizeof(*list) * 2;
+ for (i = 0; i < size; i++) {
+ offset = fdt32_to_cpu(*list++);
+ val = fdt32_to_cpu(*list++);
+ debug("%s(intel,offset-settings 0x%llx : 0x%llx)\n",
+ __func__, offset, val);
+
+ if (blk_sz <= offset) {
+ printf("%s: Overflow as offset 0x%llx",
+ __func__, offset);
+ printf(" is larger than block size 0x%x\n",
+ blk_sz);
+ return -EINVAL;
+ }
+
+ reg = base + offset;
+ writel(val, (uintptr_t)reg);
+
+ read_val = readl((uintptr_t)reg);
+ debug("%s(reg 0x%x = wr : 0x%llx rd : 0x%llx)\n",
+ __func__, reg, val, read_val);
+ }
+ }
+
+ return 0;
+};
+
+static const struct udevice_id socfpga_secreg_ids[] = {
+ {.compatible = "intel,socfpga-secreg"},
+ { }
+};
+
+U_BOOT_DRIVER(socfpga_secreg) = {
+ .name = "socfpga-secreg",
+ .id = UCLASS_NOP,
+ .of_match = socfpga_secreg_ids,
+ .probe = socfpga_secreg_probe,
+};
--
2.26.2
Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Hi Francesco,
france...@dolcini.it wrote on Mon, 5 Dec 2022 12:26:44 +0100:
> On Fri, Dec 02, 2022 at 06:08:22PM +0100, Marek Vasut wrote:
> > But here I would say this is a firmware bug and it might have to be handled
> > like a firmware bug, i.e. with fixup in the partition parser. I seem to be
> > changing my opinion here again.
>
> I was thinking at this over the weekend, and I came to the following
> ideas:
>
> - we need some improvement on the fixup we already have in the
>partition parser. We cannot ignore the fdt produced by U-Boot - as
>bad as it is.
> - the proposed fixup is fine for the immediate need, but it is
>not going to be enough to cover the general issue with the U-Boot
>generated partitions. U-Boot might keep generating partitions as direct
>child of the nand controller even when a partitions{} node is
>available. In this case the current parser just fails since it looks
>only into it and it will find it empty.
> - the current U-Boot only handle partitions{} as a direct child of the
>nand-controller, the nand-chip is ignored. This is not the way it is
>supposed to work. U-Boot code would need to be improved.
I've been thinking about it this weekend as well and the current fix
which "just set" s_cell to 1 seems risky for me, it is typically the
type of quick & dirty fix that might even break other board (nobody
knew that U-Boot current logic expected #size-cells to be set in the
DT, what if another "broken" DT expects the opposite...), not
mentioning potential issues with big storages (> 4GiB).
All in all, I really think we should revert the DT change now, reverting
as little to no drawbacks besides a dt_binding_check warning and gives
us time to deal with it properly (both in U-Boot and Linux).
> With all of that said I think that Miquel is right
>
> > When a patch breaks a board and there is no straight fix, you revert
> > it, then you think harder. That's what I am saying. This is a temporary
> > solution.
>
> ?
>
> Francesco
>
>
Thanks,
Miquèl
Re: [PATCH v5 3/3] board: qemu-riscv: enable semihosting
On Mon, Dec 5, 2022 at 1:51 PM Kautuk Consul wrote: > > Hi, > > On Sat, Dec 3, 2022 at 9:44 AM Bin Meng wrote: > > > > On Fri, Sep 23, 2022 at 3:03 PM Kautuk Consul > > wrote: > > > > > > To enable semihosting we also need to enable the following > > > configs in defconfigs: > > > CONFIG_SEMIHOSTING > > > CONFIG_SPL_SEMIHOSTING > > > CONFIG_SEMIHOSTING_SERIAL > > > CONFIG_SERIAL_PROBE_ALL > > > CONFIG_SPL_FS_EXT4 > > > CONFIG_SPL_FS_FAT > > > > Why should these _SPL_FS_xxx be required? If it's required by > > SEMIHOSTING, could the dependency be fixed there? > > The build dependencies require that these options be there. > I think you need to fix the dependencies of CONFIG_SPL_SEMIHOSTING Regards, Bin
Re: [PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices
On Saturday, December 3, 2022 7:23:10 A.M. EST Fabio Estevam wrote:
> On Fri, Dec 2, 2022 at 8:36 PM Tom Rini wrote:
> > No, upstream has different aliases and doesn't want these. That's the
> > point of the above thread, right?
>
> Upstream is correct in not accepting new alias for this board, as this
> could break
> existing setups.
>
> In U-Boot, we had alias for this board originally. After the sync with
> Linux they are gone.
>
> To fix U-Boot, the less invasive change is to add the alias into
> arch/arm/dts/imx6qdl-sabrelite-u-boot.dtsi.
>
> This way we can:
>
> 1. Keep the dtsi in sync with Linux
>
> 2. Do not break users in U-Boot
>
> This is the same approach I did for wandboard in the following commit:
>
> commit f827f84d3f5607d0b33e927f6127a888e7bd664f
> Author: Fabio Estevam
> Date: Fri Nov 4 08:12:54 2022 -0300
>
> wandboard: Pass mmc aliases
>
> Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
>
> After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
> synchronise device trees with linux"), the aliases node is gone as
> the upstream version does not have it.
>
> This causes a regression in which the SD card cannot be found anymore:
>
> Since commit the aliases node has been removed
> U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
>
> CPU: Freescale i.MX6QP rev1.0 at 792 MHz
> Reset cause: POR
> DRAM: 2 GiB
> Core: 62 devices, 17 uclasses, devicetree: separate
> PMIC: PFUZE100 ID=0x10
> MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... MMC: no card present
> *** Warning - No block device, using default environment
>
> Fix it by passing the alias node in the u-boot.dtsi file to
> restore the original behaviour where the SD card (esdhc3) was
> mapped to mmc0.
>
> Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with
> linux") Signed-off-by: Fabio Estevam
Ha good idea to use a u-boot specific dtsi. I'll send a new patch with that
then.
Thanks !
Detlev.
Re: [PATCH v5 3/3] board: qemu-riscv: enable semihosting
On 12/5/22 00:51, Kautuk Consul wrote: > Hi, > > On Sat, Dec 3, 2022 at 9:44 AM Bin Meng wrote: >> >> On Fri, Sep 23, 2022 at 3:03 PM Kautuk Consul >> wrote: >> > >> > To enable semihosting we also need to enable the following >> > configs in defconfigs: >> > CONFIG_SEMIHOSTING >> > CONFIG_SPL_SEMIHOSTING >> > CONFIG_SEMIHOSTING_SERIAL >> > CONFIG_SERIAL_PROBE_ALL >> > CONFIG_SPL_FS_EXT4 >> > CONFIG_SPL_FS_FAT >> >> Why should these _SPL_FS_xxx be required? If it's required by >> SEMIHOSTING, could the dependency be fixed there? > > The build dependencies require that these options be there. What error do you get? --Sean >> >> > >> > Signed-off-by: Kautuk Consul >> > --- >> > configs/qemu-riscv32_defconfig | 4 >> > configs/qemu-riscv32_smode_defconfig | 4 >> > configs/qemu-riscv32_spl_defconfig | 7 +++ >> > configs/qemu-riscv64_defconfig | 4 >> > configs/qemu-riscv64_smode_defconfig | 4 >> > configs/qemu-riscv64_spl_defconfig | 7 +++ >> > 6 files changed, 30 insertions(+) >> > >> >> Regards, >> Bin
Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
Hi Francesco,
france...@dolcini.it wrote on Mon, 5 Dec 2022 12:30:16 +0100:
> Hello Miquel
>
> On Fri, Dec 02, 2022 at 06:20:02PM +0100, Francesco Dolcini wrote:
> > On Fri, Dec 02, 2022 at 05:42:55PM +0100, Miquel Raynal wrote:
> > > Please also do it with the NAND chip described. If, when the NAND chip
> > > is described U-Boot tries to create partitions in the controller node,
> > > then the situation is even worse than I thought. But I believe
> >
> > It's like that for U-Boot older than v2022.04 ... and IMO we cannot
> > ignore it.
> >
> > Said that from the code U-Boot looks into a `partition{}` node only as a
> > direct child of the nand-controller, if there is a nand-chip in between
> > the nand-controller{} and the partitions{} it will just ignore it.
> >
> > I could try to see what it is doing exactly, but I would need a little
> > bit more time, I just tried changing the DTS as wrote I got a non
> > bootable system.
>
> If I have a nand-chip { partitions {} } described in the dts U-Boot
> (even the latest one) ignores it and generates the partition as child of
> the nand controller, the linux parser however see that partitions{}
> exists, even if empty, and ignore the partition directly defined as
> child of the nand controller.
>
> TL;DR: parser fails and boot fails according to that.
Yeah I get that. For me the longterm goal should be to just kill that
function. We have proper DT support today, Linux knows how to read the
mtdparts cmdline variable, so there is no need for anything else. I
guess in U-Boot we should just:
- warn users of this function that the function is deprecated and they
should update their machine support
- just migrate to another solution on the colibri board
What do you think?
Thanks,
Miquèl
Re: [PATCH] net: eth-uclass: change state before stop() in eth_halt()
Hi Marek,
On 05/12/2022 13:06, Niel Fourie wrote:
[...]
It does however show that this patch introduces a bug -- this patch
changes the order in which priv->state = ETH_STATE_PASSIVE; is
assigned from _after_ the ->stop callback to _before_ the -> stop
callback. This breaks drivers/net/ldpaa_eth/ldpaa_eth.c which checks
the priv->state in its ->stop callback, either on its own in non-DM
case, or in eth_is_active() implementation in DM case. With this
patch, the interface would never be stopped in the ->stop callback,
because the condition (net_dev->state == ETH_STATE_PASSIVE) test in
the ldpaa stop callback implementation would always be true.
In drivers/net/ldpaa_eth/ldpaa_eth.c:ldpaa_eth_stop(), priv is of type
struct ldpaa_eth_priv*, defined in drivers/net/ldpaa_eth/ldpaa_eth.h and
is accessed using dev_get_priv().
In net/eth-uclass.c:eht_halt(), priv is of type struct eth_device_priv*
and defined in the same .c file, and is accessed using
dev_get_uclass_priv(). As the structure is local to this file, nothing
outside of this file should have any knowledge of its contents, and
changing of the order of the calls should only impact this file.
I sincerely hope that these two are not interfering with each other,
otherwise we have much bigger problems...
Shucks, I was thrown off by the the fact that net_dev is of type struct
eth_device, and its member state is separate from struct
eth_device_state and its member state, that I missed the implication of
eth_is_active() *setting* the value of struct eth_device_priv's state
not *reading* it.
Well spotted, you are correct. The patch in its current form would
introduce that bug. Thank you for finding that.
Adding back the call to dev_get_uclass_priv() to get priv and validating
it again *after* stop() as it was done before commit fa795f45254 ("net:
eth-uclass: avoid running start() twice without stop()") would fix this,
and perhaps also make the issue with stop() and Ethernet gadget more
obvious. A comment on why it needs to be repeated would also be useful.
Would this be an acceptable improvement?
I agree that fixing the USB ethernet gadget is still the best solution,
but until that happens, we could at least limit everyone's pain.
Best regards,
Niel Fourie
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-21 Fax: +49-8142-66989-80 Email: lu...@denx.de
Re: [PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices
On Sat, Dec 03, 2022 at 09:23:10AM -0300, Fabio Estevam wrote:
> On Fri, Dec 2, 2022 at 8:36 PM Tom Rini wrote:
>
> > No, upstream has different aliases and doesn't want these. That's the
> > point of the above thread, right?
>
> Upstream is correct in not accepting new alias for this board, as this
> could break
> existing setups.
>
> In U-Boot, we had alias for this board originally. After the sync with
> Linux they are gone.
>
> To fix U-Boot, the less invasive change is to add the alias into
> arch/arm/dts/imx6qdl-sabrelite-u-boot.dtsi.
>
> This way we can:
>
> 1. Keep the dtsi in sync with Linux
>
> 2. Do not break users in U-Boot
>
> This is the same approach I did for wandboard in the following commit:
>
> commit f827f84d3f5607d0b33e927f6127a888e7bd664f
> Author: Fabio Estevam
> Date: Fri Nov 4 08:12:54 2022 -0300
>
> wandboard: Pass mmc aliases
>
> Originally, the mmc aliases node was present in imx6qdl-wandboard.dtsi.
>
> After the sync with Linux in commit d0399a46e7cd ("imx6dl/imx6qdl:
> synchronise device trees with linux"), the aliases node is gone as
> the upstream version does not have it.
>
> This causes a regression in which the SD card cannot be found anymore:
>
> Since commit the aliases node has been removed
> U-Boot 2022.10-00999-gcca41ed3d63f-dirty (Nov 03 2022 - 22:07:38 -0300)
>
> CPU: Freescale i.MX6QP rev1.0 at 792 MHz
> Reset cause: POR
> DRAM: 2 GiB
> Core: 62 devices, 17 uclasses, devicetree: separate
> PMIC: PFUZE100 ID=0x10
> MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... MMC: no card present
> *** Warning - No block device, using default environment
>
> Fix it by passing the alias node in the u-boot.dtsi file to
> restore the original behaviour where the SD card (esdhc3) was
> mapped to mmc0.
>
> Fixes: d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with
> linux")
> Signed-off-by: Fabio Estevam
I'm not really happy with this approach. It's not that upstream doesn't
have aliases now, it's that it has different aliases, right? That's why
they won't accept these?
But this also highlights that we really need to get these kind of
aliases and similar (a) re-synced with upstream ASAP and (b) do that at
the start. I don't know which group of "users are broken by this change"
is bigger, the group that needs the aliases we have or the group that
needs the other aliases, but the group that gets changes upstream first
"wins" here is how the OSS world works.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v8 03/10] arm_ffa: introduce Arm FF-A low-level driver
On Sun, Dec 4, 2022 at 1:22 PM Simon Glass wrote:
>
> Hi Rob,
>
> On Tue, 29 Nov 2022 at 05:22, Rob Herring wrote:
> >
> > On Fri, Nov 25, 2022 at 3:18 PM Simon Glass wrote:
> > >
> > > Hi Abdellatif,
> > >
> > > On Thu, 24 Nov 2022 at 06:21, Abdellatif El Khlifi
> > > wrote:
> > > >
> > > > On Tue, Nov 22, 2022 at 07:09:16PM -0700, Simon Glass wrote:
> > > > > should be called 'priov' and should beHi Abdellatif,
> > > > >
> > >
> > > [..]
> > >
> > > > > > +/**
> > > > > > + * ffa_device_get - create, bind and probe the arm_ffa device
> > > > > > + * @pdev: the address of a device pointer (to be filled when the
> > > > > > arm_ffa bus device is created
> > > > > > + * successfully)
> > > > > > + *
> > > > > > + * This function makes sure the arm_ffa device is
> > > > > > + * created, bound to this driver, probed and ready to use.
> > > > > > + * Arm FF-A transport is implemented through a single U-Boot
> > > > > > + * device managing the FF-A bus (arm_ffa).
> > > > > > + *
> > > > > > + * Return:
> > > > > > + *
> > > > > > + * 0 on success. Otherwise, failure
> > > > > > + */
> > > > > > +int ffa_device_get(struct udevice **pdev)
> > > > > > +{
> > > > > > + int ret;
> > > > > > + struct udevice *dev = NULL;
> > > > > > +
> > > > > > + ret = device_bind(dm_root(), DM_DRIVER_GET(arm_ffa),
> > > > > > FFA_DRV_NAME, NULL, ofnode_null(),
> > > > > > + &dev);
> > > > >
> > > > > Please add a DT binding. Even if only temporary, we need something
> > > > > for this.
> > > >
> > > > Thanks for the feedback. I'm happy to address all the comments.
> > > >
> > > > Regarding DT binding and FF-A discovery. We agreed with Linaro and Rob
> > > > Herring
> > > > about the following:
> > > >
> > > > - DT is only for what we failed to make discoverable. For hardware,
> > > > we're stuck
> > > > with it. We shouldn't repeat that for software interfaces. This
> > > > approach is
> > > > already applied in the FF-A kernel driver which comes with no DT
> > > > support and
> > > > discovers the bus with bus_register() API [1].
> > >
> > > This may be the UEFI view, but it is not how U-Boot works. This is not
> > > something we are 'stuck' with. It is how we define what is present on a
> > > device. This is how the PCI bus works in U-Boot. It is best practice in
> > > U-Boot to use the device tree to make this things visible and
> > > configurable. Unlike with Linux there is no other way to provide
> > > configuration needed by these devices.
> >
> > Where do you get UEFI out of this?
>
> I assume it was UEFI as there was no discussion about this in U-Boot.
> Which firmware project was consulted about this?
>
> >
> > It is the discoverability of hardware that is fixed (and we are stuck
> > with). We can't change hardware. The disoverability may be PCI
> > VID/PID, USB device descriptors, or nothing. We only use DT when those
> > are not sufficient. For a software interface, there is no reason to
> > make them non-discoverable as the interface can be fixed (at least for
> > new things like FF-A).
>
> Here I am talking about the controller itself, the top-level node in
> the device tree. For PCI this is a device tree node and it should be
> the same here. So I am not saying that the devices on the bus need to
> be in the device tree (that can be optional, but may be useful in some
> situations where it is status and known).
Sure, the PCI host bridges are not discoverable, have a bunch of
resources, and do need to be in DT. The downstream devices only do if
they have extra resources such as when a device is soldered down on a
board rather than a standard slot.
> We need something like:
>
> ff-a {
> compatible = "something";
> };
>
> I don't know what mechanism is actually used to communicate with it,
> but that will be enough to get the top-level driver started.
There's discovery of FF-A itself and then discovery of FF-A features
(e.g. partitions). Both of those are discoverable without DT. The
first is done by checking the SMCCC version, then checking for FF-A
presence and features. Putting this into DT is redundant. Worse, what
if they disagree?
> If Linux does not want to use the node, that it another thing, but I
> respectfully request that U-Boot's needs be considered more carefully.
It's not really a big deal for just one compatible. It's the next 10
firmware things Arm comes up with. Or the let's add one property at a
time binding (mis)design that happens once we have a binding.
> I'd also like to see more willingness to accommodate open-source
> software in these designs.
I'm not sure what you are asking for here. Are you talking about FF-A
and Arm firmware interfaces itself, the DT binding for it, or
something else? I'd agree on the first part. I only saw this when the
binding landed on my plate. For bindings themselves, the firehose is
there. I can't pick out what you or others care and don't care about.
I try to steer common things to the
Re: Please pull u-boot-i2c
On Mon, Dec 05, 2022 at 08:30:53AM +0100, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c: > > The following changes since commit d2c5607edde2544e059fa871927877213f6bd532: > > Merge tag 'efi-2023-01-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-12-04 > 10:01:48 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-i2c.git > tags/i2cfixes-for-v2023.01-rc3 > > for you to fetch changes up to d7b8fa1a6cd3201c3b71ed7c7b2b6e6eab00173b: > > i2c: nuvoton: renamed the NPCM i2c driver (2022-12-05 06:00:37 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [GIT PULL] xilinx patches for v2023.01-rc3-v2
On Mon, Dec 05, 2022 at 12:29:38PM +0100, Michal Simek wrote: > Hi Tom, > > please pull these changes to your tree. I thought that we are running > regression against upstream regularly but it looks like that it wasn't the > case. Based on internal upgrade to rc2 version we found some issues with > mini configurations which are major fixes in this pull request. > There are also some other fixes too. > > buildman and gitlab CI are not showing any issue. > > Thanks, > Michal > > > > The following changes since commit d2c5607edde2544e059fa871927877213f6bd532: > > Merge tag 'efi-2023-01-rc3' of > https://source.denx.de/u-boot/custodians/u-boot-efi (2022-12-04 10:01:48 > -0500) > > are available in the Git repository at: > > g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2023.01-rc3-v2 > > > for you to fetch changes up to 7ad3c09e7911e71c9a16a30aa052093a8f9b7e7c: > > mtd: spi-nor-core: Invert logic to reflect sst26 flash unlocked > (2022-12-05 10:01:45 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] mvebu: fix end-of-array check
Hi Pali, On Mon, 5 Dec 2022 at 10:51, Pali Rohár wrote: > > On Monday 05 December 2022 10:16:51 Simon Glass wrote: > > On Thu, 1 Dec 2022 at 07:55, Derek LaHousse wrote: > > > > > > Properly seek the end of default_environment variables. > > > > > > The current algorithm overwrites from the second variable. This > > > replacement finds the end of the array of strings. > > > > > > Stomped variables include "board", "soc", "loadaddr". These can be > > > seen on a "env default -a" after patch, but they are not seen with a > > > version before the patch. > > > > > > Signed-off-by: Derek LaHousse > > > --- > > > board/Marvell/mvebu_armada-37xx/board.c | 7 +-- > > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > Reviewed-by: Simon Glass > > > > It seems odd to update the default environment, but if we want to do > > this, it should really be done in a function in env/ along with some > > tests in test/env > > > > Regards, > > Simon > > Well, this is just a temporary solution until Marek's env patch series is > merged: > https://lore.kernel.org/u-boot/20211103232332.2737-1-ka...@kernel.org/ > > But I agree that tests would prevent these bugs. OK I see. Regards, Simon
Re: [PATCH 1/7] mtd: replace name of 'rfree' field with 'free' in struct mtd_ooblayout_ops to better match it's description
Hi Frieder,
On Fri, 25 Nov 2022 at 04:09, Frieder Schrempf
wrote:
>
> On 07.10.22 13:58, Fabio Estevam wrote:
> > On Fri, Oct 7, 2022 at 8:34 AM Michael Nazzareno Trimarchi
> > wrote:
> >
> >> About this change, there was a commit from Simon 8d38a8459b0
> >> that was renamed. You ask basically to revert it
> >
> > Correct, what about fixing it like this?
> >
> > diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> > index ff635bd716..09f5269887 100644
> > --- a/include/linux/mtd/mtd.h
> > +++ b/include/linux/mtd/mtd.h
> > @@ -122,7 +122,7 @@ struct mtd_oob_region {
> > * @ecc: function returning an ECC region in the OOB area.
> > * Should return -ERANGE if %section exceeds the total number of
> > * ECC sections.
> > - * @free: function returning a free region in the OOB area.
> > + * @rfree: function returning a free region in the OOB area.
> > * Should return -ERANGE if %section exceeds the total number of
> > * free sections.
> > */
>
> But do we really want to stay out of sync with the Linux kernel code? Is
> the reasoning behind Simon's change in 8d38a8459b0 still valid today?
See here:
https://patchwork.ozlabs.org/project/uboot/cover/20200203143618.74619-1-...@chromium.org/
I don't believe this patch even builds for sandbox:
drivers/mtd/mtdcore.c: In function ‘mtd_ooblayout_free’:
drivers/mtd/mtdcore.c:1214:58: error: macro "free" passed 3 arguments,
but takes just 1
1214 | return mtd->ooblayout->free(mtd, section, oobfree);
See malloc.h for the #define for free()
Regards,
Simon
Re: [PATCH 1/3] sound: function to generate sine wave
On Mon, 5 Dec 2022 at 09:53, Heinrich Schuchardt wrote: > > Add function sound_create_sine_wave(). > > Signed-off-by: Heinrich Schuchardt > --- > drivers/sound/sound.c | 39 +++ > include/sound.h | 12 > 2 files changed, 51 insertions(+) > Reviewed-by: Simon Glass
Re: [PATCH 3/3] sandbox: fix sound driver
On Mon, 5 Dec 2022 at 09:53, Heinrich Schuchardt wrote: > > In the callback function we have to use memcpy(). Otherwise we add > the new samples on top of what is stored in the stream buffer. > > If we don't have enough data, zero out the rest of the stream buffer. > > Our sampling frequency is 48000. Let the batch size for the callback > function be 960. If we play a multiple of 20 ms, this will always be > a full batch. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/sdl.c | 11 +-- > 1 file changed, 5 insertions(+), 6 deletions(-) > Reviewed-by: Simon Glass
Re: [PATCHv2 010/149] rsa-verify: Rework host check for CONFIG_RSA_VERIFY_WITH_PKEY
On Mon, 5 Dec 2022 at 11:37, Tom Rini wrote: > > While we do not want to use CONFIG_RSA_VERIFY_WITH_PKEY on the host, we > cannot undef the symbol in this manner. As this ends up being a test > within another function we can use !tools_build() as a test here. > > Cc: Simon Glass > Signed-off-by: Tom Rini > --- > Changes in v2: > - Switch to !tools_build() per Simon > --- > lib/rsa/rsa-verify.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass
Re: [PATCH 0/3] clang-14 fixes
Hi Tom, On Wed, 12 Oct 2022 at 05:13, Tom Rini wrote: > > On Tue, Oct 11, 2022 at 08:14:53AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Sat, 8 Oct 2022 at 21:33, Simon Glass wrote: > > > > > > This series contains a few clang-14 fixes to partly resolve the problems > > > shown by [1]. > > > > > > The event_dump problem is that the symbol name is not printed by > > > addr2line even though it seems to be present: > > > > > > Without LTO: > > > > > >$ addr2line -e u-boot.clang14.no-lto 4a37f > > >addr2line: DWARF error: invalid or unhandled FORM value: 0x23 > > >vbe_simple.c:? > > > > > >$ nm u-boot.clang14.no-lto |grep 4a37f > > >0004a37f t bootmeth_vbe_simple_ft_fixup > > > > > > With LTO is even worse: > > > > > >$ addr2line -e u-boot.clang14.lto 2d2ee0 > > >addr2line: DWARF error: invalid or unhandled FORM value: 0x23 > > >??:0 > > > > > >$ nm u-boot.clang14.lto |grep 4dad1 > > >0004dad1 t bootmeth_vbe_simple_ft_fixup > > > > > > Perhaps this is a bug in addr2line or the clang DWARF output? > > > > > > [1] https://source.denx.de/u-boot/u-boot/-/jobs/510282#L287 > > > > I should have mentioned that I can respin the series to deal with > > this, perhaps by not requiring the function name to be present when > > clang is used (or just at all?) > > > > Plus I have one more patch to add for the LTO stuff. > > > > Let me know what you think and I can respin this this. > > Maybe it's worth raising a question on one of the LLVM lists? This seems > fairly odd. > > I would like to move to LLVM-14 / gcc-12.2 for CI, for v2023.01, but > there's still other warnings to be fixed too, so we have a little time > yet. It looks like you fixed this with the dwarf change. Regards, Simon
Re: [PATCH 1/7] mtd: replace name of 'rfree' field with 'free' in struct mtd_ooblayout_ops to better match it's description
Hi
On Mon, Dec 5, 2022 at 5:11 PM Simon Glass wrote:
>
> Hi Frieder,
>
> On Fri, 25 Nov 2022 at 04:09, Frieder Schrempf
> wrote:
> >
> > On 07.10.22 13:58, Fabio Estevam wrote:
> > > On Fri, Oct 7, 2022 at 8:34 AM Michael Nazzareno Trimarchi
> > > wrote:
> > >
> > >> About this change, there was a commit from Simon 8d38a8459b0
> > >> that was renamed. You ask basically to revert it
> > >
> > > Correct, what about fixing it like this?
> > >
> > > diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
> > > index ff635bd716..09f5269887 100644
> > > --- a/include/linux/mtd/mtd.h
> > > +++ b/include/linux/mtd/mtd.h
> > > @@ -122,7 +122,7 @@ struct mtd_oob_region {
> > > * @ecc: function returning an ECC region in the OOB area.
> > > * Should return -ERANGE if %section exceeds the total number of
> > > * ECC sections.
> > > - * @free: function returning a free region in the OOB area.
> > > + * @rfree: function returning a free region in the OOB area.
> > > * Should return -ERANGE if %section exceeds the total number of
> > > * free sections.
> > > */
> >
> > But do we really want to stay out of sync with the Linux kernel code? Is
> > the reasoning behind Simon's change in 8d38a8459b0 still valid today?
>
We will be stay in sync to linux as much as possible
Michael
> See here:
>
> https://patchwork.ozlabs.org/project/uboot/cover/20200203143618.74619-1-...@chromium.org/
>
> I don't believe this patch even builds for sandbox:
>
> drivers/mtd/mtdcore.c: In function ‘mtd_ooblayout_free’:
> drivers/mtd/mtdcore.c:1214:58: error: macro "free" passed 3 arguments,
> but takes just 1
> 1214 | return mtd->ooblayout->free(mtd, section, oobfree);
>
> See malloc.h for the #define for free()
>
> Regards,
> Simon
--
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
mich...@amarulasolutions.com
__
Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
i...@amarulasolutions.com
www.amarulasolutions.com
Re: [PATCH v1] mtd: parsers: ofpart: Fix parsing when size-cells is 0
On 12/5/22 14:49, Miquel Raynal wrote:
Hi Francesco,
Hi,
france...@dolcini.it wrote on Mon, 5 Dec 2022 12:26:44 +0100:
On Fri, Dec 02, 2022 at 06:08:22PM +0100, Marek Vasut wrote:
But here I would say this is a firmware bug and it might have to be handled
like a firmware bug, i.e. with fixup in the partition parser. I seem to be
changing my opinion here again.
I was thinking at this over the weekend, and I came to the following
ideas:
- we need some improvement on the fixup we already have in the
partition parser. We cannot ignore the fdt produced by U-Boot - as
bad as it is.
- the proposed fixup is fine for the immediate need, but it is
not going to be enough to cover the general issue with the U-Boot
generated partitions. U-Boot might keep generating partitions as direct
child of the nand controller even when a partitions{} node is
available. In this case the current parser just fails since it looks
only into it and it will find it empty.
- the current U-Boot only handle partitions{} as a direct child of the
nand-controller, the nand-chip is ignored. This is not the way it is
supposed to work. U-Boot code would need to be improved.
I've been thinking about it this weekend as well and the current fix
which "just set" s_cell to 1 seems risky for me, it is typically the
type of quick & dirty fix that might even break other board (nobody
knew that U-Boot current logic expected #size-cells to be set in the
DT, what if another "broken" DT expects the opposite...)
Then with the current configuration, such broken DT would not work,
since current DT does set #size-cells=<1> (wrongly).
, not
mentioning potential issues with big storages (> 4GiB).
All in all, I really think we should revert the DT change now, reverting
as little to no drawbacks besides a dt_binding_check warning and gives
us time to deal with it properly (both in U-Boot and Linux).
I am really not happy with this, but if that's marked as intermediate
fix, go for it.
How do we deal with this in the long run however? Parser-side fix like
this one, maybe with better heuristics ?
Re: [PATCH 0/3] clang-14 fixes
On Tue, Dec 06, 2022 at 05:11:46AM +1300, Simon Glass wrote: > Hi Tom, > > On Wed, 12 Oct 2022 at 05:13, Tom Rini wrote: > > > > On Tue, Oct 11, 2022 at 08:14:53AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Sat, 8 Oct 2022 at 21:33, Simon Glass wrote: > > > > > > > > This series contains a few clang-14 fixes to partly resolve the problems > > > > shown by [1]. > > > > > > > > The event_dump problem is that the symbol name is not printed by > > > > addr2line even though it seems to be present: > > > > > > > > Without LTO: > > > > > > > >$ addr2line -e u-boot.clang14.no-lto 4a37f > > > >addr2line: DWARF error: invalid or unhandled FORM value: 0x23 > > > >vbe_simple.c:? > > > > > > > >$ nm u-boot.clang14.no-lto |grep 4a37f > > > >0004a37f t bootmeth_vbe_simple_ft_fixup > > > > > > > > With LTO is even worse: > > > > > > > >$ addr2line -e u-boot.clang14.lto 2d2ee0 > > > >addr2line: DWARF error: invalid or unhandled FORM value: 0x23 > > > >??:0 > > > > > > > >$ nm u-boot.clang14.lto |grep 4dad1 > > > >0004dad1 t bootmeth_vbe_simple_ft_fixup > > > > > > > > Perhaps this is a bug in addr2line or the clang DWARF output? > > > > > > > > [1] https://source.denx.de/u-boot/u-boot/-/jobs/510282#L287 > > > > > > I should have mentioned that I can respin the series to deal with > > > this, perhaps by not requiring the function name to be present when > > > clang is used (or just at all?) > > > > > > Plus I have one more patch to add for the LTO stuff. > > > > > > Let me know what you think and I can respin this this. > > > > Maybe it's worth raising a question on one of the LLVM lists? This seems > > fairly odd. > > > > I would like to move to LLVM-14 / gcc-12.2 for CI, for v2023.01, but > > there's still other warnings to be fixed too, so we have a little time > > yet. > > It looks like you fixed this with the dwarf change. Yes, the dwarf change addresses this, and I'll be picking that up for next as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH] dts: Re-add aliases for imx6qdl-sabrelite devices
On Mon, Dec 5, 2022 at 12:37 PM Tom Rini wrote:
> I'm not really happy with this approach. It's not that upstream doesn't
> have aliases now, it's that it has different aliases, right? That's why
> they won't accept these?
imx6q.dtsi does have the default mmc aliases:
mmc0 = &usdhc1;
mmc1 = &usdhc2;
mmc2 = &usdhc3;
mmc3 = &usdhc4;
Upstream does not want to change mmc alias because users may rely on
this mmc aliases.
Changing it now may cause the board not to boot anymore as the rootfs
cannot be found.
It is OK to change mmc alias for a newly introduced board, but please
keep in mind that
wandboard and sabrelite have been launched many many years ago.
So for upstream Linux the message was clear: don't change the mmc
alias for these boards.
Now let's talk about U-Boot.
Prior to d0399a46e7cd ("imx6dl/imx6qdl: synchronise device trees with
linux") the mmc alias for sabrelite was present:
mmc0 = &usdhc3;
mmc1 = &usdhc4;
After this commit, the mmc alias is gone and causes the boot
regression as reported by Detlev.
We don't want to cause regressions in U-Boot as well, so that's why I
propose just adding the alias into u-boot.dtsi.
There are many boards that does the same.
> But this also highlights that we really need to get these kind of
> aliases and similar (a) re-synced with upstream ASAP and (b) do that at
imx6 dts files are already synced with Linux.
> the start. I don't know which group of "users are broken by this change"
> is bigger, the group that needs the aliases we have or the group that
> needs the other aliases, but the group that gets changes upstream first
> "wins" here is how the OSS world works.
I prefer to not break things for anyone, hence my proposal.
If you are still not happy with it, please feel free to submit a patch
with your proposal.
RE: [TF-A] [RFC] Proposed location to host the firmware handoff specification.
Hi Just a few comments: * I agree with Julius that in general it isn't feasible for firmware to refuse to accept a TL with unknown tags. The structures are defined to help with backwards/forwards compatibility. To assume that all firmware is built at the same time is a special case. A particular firmware implementation could have such a policy, but I don't think we can specify this. I like the idea of defining a tag allocation policy but I'm not sure it's a good idea for this to be in the main specification as this could rapidly change depending on how the spec is used in practice. I've commented on the PR to this effect. * I don't think we’re all going to agree on how we're going to use the TL, which is part of the reason for its existence. At least one of the use-cases is combining the passing of standard structures like FDT/HOBs through to the normal world firmware and/or OS, with the passing of smaller structures between more tightly integrated firmware components. In a system where BL31 (for example) has to parse FDT anyway, it might make sense to put all data in FDT format, but in other systems, BL31 might just relay the FDT, so adding an FDT parser might add unnecessary overhead. I don't think we need to mandate usage for now - patterns will emerge. * Using TEs throughout is probably only going to work for vertically integrated systems, but that is clearly also an important case, so optimizing the structures for size in those cases is reasonable. I've also commented on the PR about this. Cheers Dan. > -Original Message- > From: Simon Glass > Sent: 02 December 2022 17:54 > To: Julius Werner > Cc: Jose Marinho ; t...@lists.trustedfirmware.org; > u-boot@lists.denx.de; boot-architect...@lists.linaro.org; Manish Pandey2 > ; Joanna Farley ; > Ilias Apalodimas ; Matteo Carlini > ; Dan Handley ; Rob > Herring ; Harb Abdulhamid > (h...@amperecomputing.com) ; > Sivasakthivel Nainar ; Samer El-Haj- > Mahmoud ; nd > Subject: Re: [TF-A] [RFC] Proposed location to host the firmware handoff > specification. > > Hi, > > On Wed, 30 Nov 2022 at 16:48, Julius Werner > wrote: > > > > Okay, FWIW I created a pull request with my suggestions here: > > https://github.com/FirmwareHandoff/firmware_handoff/pull/4 > > > > That should make it easier to discuss specific details, hopefully. As > > I was looking at the header size and format more closely I noticed > > that the checksum calculation and some details about what the size > > fields mean seems underspecified right now, so I suggested a change > > for that as well. Let me know what you think. > > > > > One way to enforce that is for firmware components to refuse to > > > accept a transfer list with unknown tags, assuming that all firmware > > > is built from source at the same time. It might be a pain, but I > > > suspect it could help avoid security problems, where bad actors use > > > the structure to pass code to a firmware blob, etc. > > > > I don't think that's feasible, particularly if tag IDs are not > > allocated in order (which I think is useful so that we can try to > > group similar tags by vendor, e.g. if say MediaTek wanted to add some > > tags they could just find some nice round number in the tag space, say > > 0x200, and then start allocating 0x201, 0x202, 0x203, etc. while the > > next vendor can do their own thing at 0x300 instead). It also creates > > automatic incompatibilities if you put newer and older components in > > the same image, which I think is something we explicitly don't want. I > > think the right policy to encourage compatibility is that unknown tags > > just get ignored. > > > > > I have to disagree here. The context is gone in this email, so I > > > cannot reply to the comments there. But I think it was talking about > > > using the transfer list for very tiny structures, just a few words. > > > That is not the intent. Firstly we should really have TF-A use the > > > device tree (embedded in the transfer list) instead of replicating > > > bl_params in this structure. Secondly, we should group things into a > > > C structure that is at least 16-32 bytes long. > > > > Uhh... okay, sorry, but then you're going against everything that was > > discussed in this thread and in the previous discussions last year. > > The whole idea of making this a tagged list came from the argument > > that other structures (like FDT) are unnecessarily bulky and complex > > for some of the intended use cases (like replacing TF-A > > bl_aux_params). I mean, what's the point of even having a transfer > > list if all it does is wrap an FDT? You could just use the FDT > > directly! I think all the 4 tags that are currently specified in that > > document are pathological edge cases that may be necessary for legacy > > applications but represent the opposite of how this structure *should* > > be used in the ideal case. We don't need just more wrappers for the > > stuff that we already have, that doesn't promote interoperabil
Re: [TF-A] [RFC] Proposed location to host the firmware handoff specification.
Hi Dan, Julius, On Tue, 6 Dec 2022 at 06:51, Dan Handley wrote: > > Hi > > Just a few comments: > > * I agree with Julius that in general it isn't feasible for firmware to > refuse to accept a TL with unknown tags. The structures are defined to help > with backwards/forwards compatibility. To assume that all firmware is built > at the same time is a special case. A particular firmware implementation > could have such a policy, but I don't think we can specify this. I like the > idea of defining a tag allocation policy but I'm not sure it's a good idea > for this to be in the main specification as this could rapidly change > depending on how the spec is used in practice. I've commented on the PR to > this effect. That all sounds reasonable to me. > > * I don't think we’re all going to agree on how we're going to use the TL, > which is part of the reason for its existence. At least one of the use-cases > is combining the passing of standard structures like FDT/HOBs through to the > normal world firmware and/or OS, with the passing of smaller structures > between more tightly integrated firmware components. In a system where BL31 > (for example) has to parse FDT anyway, it might make sense to put all data in > FDT format, but in other systems, BL31 might just relay the FDT, so adding an > FDT parser might add unnecessary overhead. I don't think we need to mandate > usage for now - patterns will emerge. The main concern I have here is that TL not be used for non-trivial binary formats (say more than a C struct or table of them). We have so many of those sorts of things. The overhead of FDT is certainly a concern, but some of these components have hundreds of KB of code anyway. Adding another 5KB for all the convenience and visibility shouldn't matter. > > * Using TEs throughout is probably only going to work for vertically > integrated systems, but that is clearly also an important case, so optimizing > the structures for size in those cases is reasonable. I've also commented on > the PR about this. OK. - Simon > > Cheers > > Dan. > > > -Original Message- > > From: Simon Glass > > Sent: 02 December 2022 17:54 > > To: Julius Werner > > Cc: Jose Marinho ; t...@lists.trustedfirmware.org; > > u-boot@lists.denx.de; boot-architect...@lists.linaro.org; Manish Pandey2 > > ; Joanna Farley ; > > Ilias Apalodimas ; Matteo Carlini > > ; Dan Handley ; Rob > > Herring ; Harb Abdulhamid > > (h...@amperecomputing.com) ; > > Sivasakthivel Nainar ; Samer El-Haj- > > Mahmoud ; nd > > Subject: Re: [TF-A] [RFC] Proposed location to host the firmware handoff > > specification. > > > > Hi, > > > > On Wed, 30 Nov 2022 at 16:48, Julius Werner > > wrote: > > > > > > Okay, FWIW I created a pull request with my suggestions here: > > > https://github.com/FirmwareHandoff/firmware_handoff/pull/4 > > > > > > That should make it easier to discuss specific details, hopefully. As > > > I was looking at the header size and format more closely I noticed > > > that the checksum calculation and some details about what the size > > > fields mean seems underspecified right now, so I suggested a change > > > for that as well. Let me know what you think. > > > > > > > One way to enforce that is for firmware components to refuse to > > > > accept a transfer list with unknown tags, assuming that all firmware > > > > is built from source at the same time. It might be a pain, but I > > > > suspect it could help avoid security problems, where bad actors use > > > > the structure to pass code to a firmware blob, etc. > > > > > > I don't think that's feasible, particularly if tag IDs are not > > > allocated in order (which I think is useful so that we can try to > > > group similar tags by vendor, e.g. if say MediaTek wanted to add some > > > tags they could just find some nice round number in the tag space, say > > > 0x200, and then start allocating 0x201, 0x202, 0x203, etc. while the > > > next vendor can do their own thing at 0x300 instead). It also creates > > > automatic incompatibilities if you put newer and older components in > > > the same image, which I think is something we explicitly don't want. I > > > think the right policy to encourage compatibility is that unknown tags > > > just get ignored. > > > > > > > I have to disagree here. The context is gone in this email, so I > > > > cannot reply to the comments there. But I think it was talking about > > > > using the transfer list for very tiny structures, just a few words. > > > > That is not the intent. Firstly we should really have TF-A use the > > > > device tree (embedded in the transfer list) instead of replicating > > > > bl_params in this structure. Secondly, we should group things into a > > > > C structure that is at least 16-32 bytes long. > > > > > > Uhh... okay, sorry, but then you're going against everything that was > > > discussed in this thread and in the previous discussions last year. > > > The whole idea of making this a tagged list came
Re: [PATCH] net: eth-uclass: change state before stop() in eth_halt()
On 12/5/22 13:06, Niel Fourie wrote:
Hi,
[...]
How come nobody triggered this problem with regular ethernet in
U-Boot ?
If this is isolated to USB gadget ethernet, then please do not hack
around this in core networking code, but rather fix the USB ethernet
gadget itself. It seems that gadget code should not unregister the
gadget in drivers/usb/gadget/ether.c _usb_eth_halt() , at least not
fully.
The reason is simple, the regular ethernet drivers do not get removed
on stop() like for the gadget ethernet driver, and in their case
`priv` is still valid.
The suggestion for a proper fix is in the last paragraph above -- do
not unregister the usb ethernet gadget device in halt(), keep the
gadget device registered. Then the priv pointer would be valid. (*)
I agree on your point that reworking the ethernet gadget code would
be preferable, but this would be a much bigger effort (and if I were
to do it, I would probably introduce even more bugs). I am not
certain whether this would not also affect the non-DM gadget
implementation as well, which still contain drivers like ci_udc.c
which does not appear to have been ported to DM gadget yet? (I only
see DM USB there...)
That said, I am not certain whether this is not also bug, as I am not
certain whether the assumption that `priv` should be available after
stop() is valid or not.
The documentation at
https://source.denx.de/u-boot/u-boot/-/blob/master/doc/develop/driver-model/ethernet.rst?plain=1#L135 states:
The **stop** function should turn off / disable the hardware and
place it back in its reset state. It can be called at any time
(before any call to the related start() function), so make sure it
can handle this sort of thing.
The ->stop callback is supposed to stop the interface, turn off its
DMA, but NOT deallocate the device (and its associated data) behind it.
In such a complete reset state I am not certain whether the
assumption that `priv` should exist is still valid, at least not
without another call to dev_get_uclass_priv() and revalidating it first?
In case a device is probe()d, its private data are also allocated and
available, so yes, 'priv' pointer should still be valid.
Granted, the usb gadget driver implementation is problematic, and it
definitely belongs on the TODO list.
That being said, priv not being valid at this stage is not a new
problem, as validation for it after stop() was explicitly added in
commit c3211708 ("net: eth-uclass: Fix for DM USB ethernet support") for
this reason 4 years ago. Fortunately in that case, it just fixed a null
pointer de-reference, not corruption of freed memory.
I believe the aforementioned patch is already also wrong, since the priv
pointer would be invalid for gadget ethernet driver got removed in the
stop callback.
Lastly, this assumption that priv is still valid is rather new and it
was introduced here:
https://source.denx.de/u-boot/u-boot/-/commit/fa795f452541ce07b33be603de36cac3c5d7dfcf
I disagree, the device private data are valid during the entire
lifespan of the device. That assumption has been baked into the driver
model itself and far predates that commit.
In case of a usb ethernet, the lifespan of the device starts with the
'bind' command which triggers the ->bind callback, and first use which
triggers its ->probe callback. The lifespan ends with 'unbind' command
or OS boot, which triggers ->remove callback and ->unbind callbacks.
This commit appears to be a workaround for drivers which cannot deal
with stop() being called at any time as required in the above quoted
documentation.
This commit prevents network device ->start() from being called
multiple times, which is a valid precaution, as calling start while
the interface is already up would interfere with existing connection
(e.g. the netconsole as mentioned in the commit message). That does
not seem to be a workaround to me.
Ah yes, the commit message indeed states that some drivers (like
fec_mxc) cannot deal with multiple start() calls, not multiple stop()
calls. My mistake, good point.
But preventing multiple start()s getting called is not what the code
change in this commit is actually doing. It is instead inhibiting
calling stop() on devices for which priv is not valid or for which
priv->running is false. Therefore it is avoiding calling stop() on
un-started devices.
I wonder if such a patch is needed to fix it ?
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index f41da4b37b3..e7b5d3943e8 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -298,7 +298,7 @@ int eth_init(void)
if (current) {
debug("Trying %s\n", current->name);
- if (device_active(current)) {
+ if (!eth_is_active(current)) {
I would consider adding a workaround to a workaround in this case to
be the lesser evil, as tracking down this bug in the first place was
like looking for a needle in a
Re: [PATCH] net: eth-uclass: change state before stop() in eth_halt()
On 12/5/22 16:33, Niel Fourie wrote:
Hi Marek,
Hi,
On 05/12/2022 13:06, Niel Fourie wrote:
[...]
It does however show that this patch introduces a bug -- this patch
changes the order in which priv->state = ETH_STATE_PASSIVE; is
assigned from _after_ the ->stop callback to _before_ the -> stop
callback. This breaks drivers/net/ldpaa_eth/ldpaa_eth.c which checks
the priv->state in its ->stop callback, either on its own in non-DM
case, or in eth_is_active() implementation in DM case. With this
patch, the interface would never be stopped in the ->stop callback,
because the condition (net_dev->state == ETH_STATE_PASSIVE) test in
the ldpaa stop callback implementation would always be true.
In drivers/net/ldpaa_eth/ldpaa_eth.c:ldpaa_eth_stop(), priv is of type
struct ldpaa_eth_priv*, defined in drivers/net/ldpaa_eth/ldpaa_eth.h
and is accessed using dev_get_priv().
In net/eth-uclass.c:eht_halt(), priv is of type struct
eth_device_priv* and defined in the same .c file, and is accessed
using dev_get_uclass_priv(). As the structure is local to this file,
nothing outside of this file should have any knowledge of its
contents, and changing of the order of the calls should only impact
this file.
I sincerely hope that these two are not interfering with each other,
otherwise we have much bigger problems...
Shucks, I was thrown off by the the fact that net_dev is of type struct
eth_device, and its member state is separate from struct
eth_device_state and its member state, that I missed the implication of
eth_is_active() *setting* the value of struct eth_device_priv's state
not *reading* it.
Well spotted, you are correct. The patch in its current form would
introduce that bug. Thank you for finding that.
Good, so we agree this patch introduces a bug.
Adding back the call to dev_get_uclass_priv() to get priv and validating
it again *after* stop() as it was done before commit fa795f45254 ("net:
eth-uclass: avoid running start() twice without stop()") would fix this,
and perhaps also make the issue with stop() and Ethernet gadget more
obvious. A comment on why it needs to be repeated would also be useful.
Would this be an acceptable improvement?
I agree that fixing the USB ethernet gadget is still the best solution,
but until that happens, we could at least limit everyone's pain.
See my reply to the previous email.
Keep the usb gadget device around, that should not be hard to implement
and that should fix this problem once and for all, and for the future too.
Re: [PATCH 1/1] mvebu: fix end-of-array check
On Monday 05 December 2022 12:42:44 Stefan Roese wrote:
> Hi!
>
> On 12/4/22 11:39, Pali Rohár wrote:
> > Hello!
> >
> > I would suggest to change description of the patch from
> >
> >"mvebu: fix end-of-array check"
> >
> > to something like:
> >
> >"arm: mvebu: Espressobin: fix end-of-array check in env"
> >
> > as it affects only Espressobin boards (not other mvebu).
>
> Yes, please update the commit subject here.
>
> > Stefan, please look below as this issue/fix is important.
>
> Yes.
>
> > On Wednesday 30 November 2022 13:33:40 Derek LaHousse wrote:
> > > Properly seek the end of default_environment variables.
> > >
> > > The current algorithm overwrites from the second variable. This
> > > replacement finds the end of the array of strings.
> > >
> > > Stomped variables include "board", "soc", "loadaddr". These can be
> > > seen on a "env default -a" after patch, but they are not seen with a
> > > version before the patch.
> >
> > This is a real issue which I introduced in the past. So it some fix for
> > this issue should be pulled into the v2023.01 release.
>
> Understood.
>
> > > Signed-off-by: Derek LaHousse
> > > ---
> > > board/Marvell/mvebu_armada-37xx/board.c | 7 +--
> > > 1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/board/Marvell/mvebu_armada-37xx/board.c
> > > b/board/Marvell/mvebu_armada-37xx/board.c
> > > index c6ecc323bb..ac29ac5b95 100644
> > > --- a/board/Marvell/mvebu_armada-37xx/board.c
> > > +++ b/board/Marvell/mvebu_armada-37xx/board.c
> > > @@ -100,8 +100,11 @@ int board_late_init(void)
> > > return 0;
> > > /* Find free buffer in default_environment[] for new variables
> > > */
> > > - while (*ptr != '\0' && *(ptr+1) != '\0') ptr++;
> > > - ptr += 2;
> > > + if (*ptr != '\0') { // Defending against empty default env
> > > + while ((i = strlen(ptr)) != 0) {
> > > + ptr += i + 1;
> > > + }
> > > + }
> >
> > If I'm looking at the outer-if condition correctly then it is not
> > needed. strlen("") returns zero and so inner-while loop stops
> > immediately.
> >
> > My proposed fix for this issue was just changing correct while loop
> > check to ensure that ptr is set after the _last_ variable.
> >
> > - while (*ptr != '\0' && *(ptr+1) != '\0') ptr++;
> > - ptr += 2;
> > + while (*ptr != '\0' || *(ptr+1) != '\0') ptr++;
> > + ptr++;
> >
> > Both changes should be equivalent, but I'm not sure which one is more
> > readable. The original issue was introduced really by non-readable
> > code...
> >
> > Stefan, do you have a preference which one fix is better / more
> > readable?
>
> I would prefer to get Pali's corrected version included. Could you
> please prepare a v2 patch with this update and also with the added
> or changed patch subject.
Originally this issue was reported half year ago on the armbian forum:
https://forum.armbian.com/topic/19564-making-espressobin-v7-work-in-2022/?do=findComment&comment=138136
U-Boot "changed" variable name scriptaddr to criptaddr (without leading
s) and broke booting.
Details are later in comments:
https://forum.armbian.com/topic/19564-making-espressobin-v7-work-in-2022/?do=findComment&comment=154062
https://forum.armbian.com/topic/19564-making-espressobin-v7-work-in-2022/?do=findComment&comment=154235
If you prefer my variant, I can prepare a v2 patch.
Please let me know.
> > It would be really a good idea if you try to check if any of those
> > proposed fixes/patches are now really correct.
>
> Yes, please do.
>
> Thanks,
> Stefan
[PATCH v2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
arch/arm/dts/rk3399.dtsi has a node
usb_host0_ehci: usb@fe38 {
compatible = "generic-ehci";
with clocks:
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
<&u2phy0>;
The first 2 refer to nodes with class UCLASS_CLK, but &u2phy0
has class UCLASS_PHY.
u2phy0: usb2phy@e450 {
compatible = "rockchip,rk3399-usb2phy";
Since clk_get_bulk() only looks for devices with UCLASS_CLK,
it fails with -ENODEV and then ehci_usb_probe() aborts.
The consequence is peripherals connected to a USB 2 port (e.g. in a
Rock Pi 4 the white port, nearer the edge) not being detected.
They're detected if CONFIG_USB_OHCI_GENERIC is selected in Kconfig,
because ohci_usb_probe() does not abort when one clk_get_by_index()
fails, but then they work in USB 1 mode,.
rk3399.dtsi comes from linux and the u2phy0 was added[1] to the clock
list in:
commit b5d1c57299734f5b54035ef2e61706b83041f20c
Author: William wu
Date: Wed Dec 21 18:41:05 2016 +0800
arm64: dts: rockchip: add u2phy clock for ehci and ohci of rk3399
We found that the suspend process was blocked when it run into
ehci/ohci module due to clk-480m of usb2-phy was disabled.
[...]
Suspend concerns don't apply to U-Boot, and the problem with U-Boot
failing to probe EHCI doesn't apply to linux, because in linux
rockchip_usb2phy_clk480m_register makes u2phy0 a proper clock provider
when called by rockchip_usb2phy_probe().
So I can think of a few alternative solutions:
1- Change ehci_usb_probe() to make it more similar to
ohci_usb_probe(), and survive failure to get one clock. Looks a
little harder, and I don't know whether it could break something if
it ignored a clock that was important for something else than
suspend.
2- Change rk3399.dtsi effecttively reverting the linux commit
b5d1c57299734f5b54035ef2e61706b83041f20c. This dealigns the .dtsi
from linux and seems fragile at the next synchronisation.
3- Change the clock list in rk3399-u-boot.dtsi or somewhere else.
This survives .dts* sync but may survive "too much" and miss some
change from linux that we might want.
4- Enable CONFIG_USB_OHCI_GENERIC and use the ports in USB 1 mode.
This would need to be made for all boards using rk3399. In a
simple test reading one file from USB storage it gave 769.5 KiB/s
instead of 20.5 MiB/s with solution 2.
5- Trying to replicate linux and have usb2phy somehow provide a clk,
or have a separate clock device for usb2phy in addition to the phy
device. I just can't seem to imagine how to achieve this with the
U-Boot driver model, maybe because of my limited familiarity with
it.
This patch is option 1 as Kever Yang requested on August 27th[2] when
option 3 didn't get through. Sorry for the delay.
Yet maybe the get_some_clks() function should be added to clk-uclass.c
if it may be useful elsewhere. Or alternatively, clk_get_bulk() could
be changed to the lenient behaviour of get_some_clks(), but that seems
too invasive to me. Either of these changes can always be done in a
later patch if needed.
If so, one possibility would be to call it from ohci-generic.c. As it
is now it looks like if it ever misses a clock but finds a subsequent
clock, assigned to a higher index in the clock table, it may leave
clock_count too low to release all found clocks. I don't know of a
case where this happens, for rk3399 usb, even with non-default
CONFIG_OHCI_GENERIC, the missing clock is the last one, and so the
release iteration happens to find all found clocks.
Link: [1] https://lkml.kernel.org/lkml/1731551.Q6cHK6n5ZM@phil/T/
[2]
https://patchwork.ozlabs.org/project/uboot/patch/20220701185959.GC1700@begut/#2954536
Cc: Simon Glass
Cc: Philipp Tomsich
Cc: Kever Yang
Cc: Lukasz Majewski
Cc: Sean Anderson
Cc: Marek Vasut
Signed-off-by: Xavier Drudis Ferran
---
Changes:
v2: implement option 1 (ehci-generic.c tolerates missing clocks)
instead of option 3 (change dts node to remove the missing
clock).
---
drivers/usb/host/ehci-generic.c | 59 -
1 file changed, 58 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-generic.c b/drivers/usb/host/ehci-generic.c
index a765a307a3..aa86dcc435 100644
--- a/drivers/usb/host/ehci-generic.c
+++ b/drivers/usb/host/ehci-generic.c
@@ -60,6 +60,63 @@ static int ehci_disable_vbus_supply(struct generic_ehci
*priv)
return 0;
}
+/**
+ * get_some_clks() - Get/request all available clocks of a
+ *device. Leave other as null.
+ *
+ * @dev: The client device.
+ * @bulk: A pointer to a clock bulk struct to initialize.
+ *
+ * This looks up and requests all clocks of the client device; each
+ * device is assumed to have n clocks associated with it somehow, and
+ * this function tries to find and request all of them in a separate
+ * structure. The mapping of client device clock indices to provider
+ * clocks may be via device
Re: [PATCH v2] fastboot: Add OEM run command
Hi,
On 12/2/22 22:03, Sean Anderson wrote:
This adds the UUU UCmd functionality as an OEM command. While the
fastboot tool allows sending arbitrary commands as long as they are
prefixed with "oem". This allows running generic U-Boot commands over
fastboot without UUU, which is especially useful when not using USB.
This is really the route we should have gone in the first place when
adding these commands.
While we're here, clean up the Kconfig a bit.
Signed-off-by: Sean Anderson
---
Changes in v2:
- Document usage
- Keep enum in order
doc/android/fastboot.rst | 15 +++
drivers/fastboot/Kconfig | 10 +-
drivers/fastboot/fb_command.c | 4
include/fastboot.h| 1 +
4 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index 7611f07038..7f343d5dfc 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -28,6 +28,7 @@ The following OEM commands are supported (if enabled):
- ``oem partconf`` - this executes ``mmc partconf %x 0`` to configure
eMMC
with = boot_ack boot_partition
- ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC
+- ``oem run`` - this executes an arbitrary U-Boot command
Support for both eMMC and NAND devices is included.
@@ -127,6 +128,19 @@ Boot command
When executing the fastboot ``boot`` command, if ``fastboot_bootcmd`` is set
then that will be executed in place of ``bootm ``.
+Running Shell Commands
+--
+
+Normally, arbitrary U-Boot command execution is not enabled. This is so
+fastboot can be used to update systems using verified boot. However, such
+functionality can be useful for production or when verified boot is not in use.
+Enable ``CONFIG_FASTBOOT_UUU_SUPPORT`` to use this functionality. This will
+enable the ``UCmd`` and ``ACmd`` commands for use with UUU [3]_. It also
+enables the ``oem run`` command, which can be used with the fastboot client.
+For example, to print "Hello world", run::
+
+$ fastboot oem run:echo Hello world
+
Partition Names
---
@@ -232,3 +246,4 @@ References
.. [1] :doc:`fastboot-protocol`
.. [2] https://developer.android.com/studio/releases/platform-tools
+.. [3] https://github.com/NXPmicro/mfgtools
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index b97c67bf60..8f2d52cb8a 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -80,12 +80,12 @@ config FASTBOOT_FLASH
this to enable the "fastboot flash" command.
config FASTBOOT_UUU_SUPPORT
- bool "Enable FASTBOOT i.MX UUU special command"
+ bool "Enable running arbitrary commands from FASTBOOT"
help
- The fastboot protocol includes "UCmd" and "ACmd" command.
- Be aware that you provide full access to any U-Boot command,
- including working with memory and may open a huge backdoor,
- when enabling this option.
+ This extends the fastboot protocol with the "UCmd" and "ACmd"
+ commands, as well as the "oem run" command. These commands provide
+ full access to any U-Boot command, including working with memory.
+ This may open a huge backdoor if you are using verified boot.
why the support of "oem run" generic support is include in the IMX config
CONFIG_FASTBOOT_UUU_SUPPORT
"UCmd" and "Acmd" are imx additions in fastboot standard for UUU support
https://android.googlesource.com/platform/system/core/+/2ec418a4c98f6e8f95395456e1ad4c2956cac007/fastboot/fastboot_protocol.txt
but "oem run" can be see as generic U-Boot 'oem' command to execute
U-boot command.
for me I see 2 separate configs to handle other platform than IMX ones (with
UUU support)
config FASTBOOT_CMD_OEM_RUN
bool "Enable fastboot oem run command"
config FASTBOOT_UUU_SUPPORT
bool "Enable FASTBOOT i.MX UUU special command"
select FASTBOOT_CMD_OEM_RUN
PS: FASTBOOT_UUU_SUPPORT could depends on CONFIG_ARCH_IMX*
choice
prompt "Flash provider for FASTBOOT"
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 98eccc3455..1732406c18 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -123,6 +123,10 @@ static const struct {
},
#endif
#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
+ [FASTBOOT_COMMAND_OEM_RUN] = {
+ .command = "oem run",
+ .dispatch = run_ucmd,
+ },
#if CONFIG_IS_ENABLED(FASTBOOT_CMD_OEM_RUN)
[FASTBOOT_COMMAND_OEM_RUN] = {
.command = "oem run",
.dispatch = run_ucmd,
},
#endif
#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
[FASTBOOT_COMMAND_UCMD] = {
.command = "UCmd",
.dispatch = run_ucmd,
That allows other platform to enable FASTBOOT_CMD_OEM_RUN but not
FASTBOOT_UUU_SUPPORT.
[FASTBOOT_COMMAND_UCMD] = {
Re: [PATCH v2] arm: dts: rockchip: rk3399: usb: ehci: Fix EHCI probe in rk3399 to access peripherals by USB 2.
On 12/5/22 19:54, Xavier Drudis Ferran wrote:
arch/arm/dts/rk3399.dtsi has a node
usb_host0_ehci: usb@fe38 {
compatible = "generic-ehci";
with clocks:
clocks = <&cru HCLK_HOST0>, <&cru HCLK_HOST0_ARB>,
<&u2phy0>;
The first 2 refer to nodes with class UCLASS_CLK, but &u2phy0
has class UCLASS_PHY.
[...]
5- Trying to replicate linux and have usb2phy somehow provide a clk,
or have a separate clock device for usb2phy in addition to the phy
device. I just can't seem to imagine how to achieve this with the
U-Boot driver model, maybe because of my limited familiarity with
it.
Yes please
Have a look at the end of drivers/led/led_gpio.c and how gpio_led_wrap
binds a gpio_led driver to each LED. You can bind an UCLASS_PHY and
UCLASS_CLK driver to the u2phy0 the same way, the u2phy0 would behave
the same way as gpio_led_wrap wrapper . You would likely be using
device_bind_driver() instead of device_bind_driver_to_node() in the bind
callback.
[...]
Re: [PATCH v2] fastboot: Add OEM run command
On 12/5/22 14:04, Patrick DELAUNAY wrote: > Hi, > > On 12/2/22 22:03, Sean Anderson wrote: >> This adds the UUU UCmd functionality as an OEM command. While the >> fastboot tool allows sending arbitrary commands as long as they are >> prefixed with "oem". This allows running generic U-Boot commands over >> fastboot without UUU, which is especially useful when not using USB. >> This is really the route we should have gone in the first place when >> adding these commands. >> >> While we're here, clean up the Kconfig a bit. >> >> Signed-off-by: Sean Anderson >> --- >> >> Changes in v2: >> - Document usage >> - Keep enum in order >> >> doc/android/fastboot.rst | 15 +++ >> drivers/fastboot/Kconfig | 10 +- >> drivers/fastboot/fb_command.c | 4 >> include/fastboot.h | 1 + >> 4 files changed, 25 insertions(+), 5 deletions(-) >> >> diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst >> index 7611f07038..7f343d5dfc 100644 >> --- a/doc/android/fastboot.rst >> +++ b/doc/android/fastboot.rst >> @@ -28,6 +28,7 @@ The following OEM commands are supported (if enabled): >> - ``oem partconf`` - this executes ``mmc partconf %x 0`` to >> configure eMMC >> with = boot_ack boot_partition >> - ``oem bootbus`` - this executes ``mmc bootbus %x %s`` to configure eMMC >> +- ``oem run`` - this executes an arbitrary U-Boot command >> Support for both eMMC and NAND devices is included. >> @@ -127,6 +128,19 @@ Boot command >> When executing the fastboot ``boot`` command, if ``fastboot_bootcmd`` is >> set >> then that will be executed in place of ``bootm >> ``. >> +Running Shell Commands >> +-- >> + >> +Normally, arbitrary U-Boot command execution is not enabled. This is so >> +fastboot can be used to update systems using verified boot. However, such >> +functionality can be useful for production or when verified boot is not in >> use. >> +Enable ``CONFIG_FASTBOOT_UUU_SUPPORT`` to use this functionality. This will >> +enable the ``UCmd`` and ``ACmd`` commands for use with UUU [3]_. It also >> +enables the ``oem run`` command, which can be used with the fastboot client. >> +For example, to print "Hello world", run:: >> + >> + $ fastboot oem run:echo Hello world >> + >> Partition Names >> --- >> @@ -232,3 +246,4 @@ References >> .. [1] :doc:`fastboot-protocol` >> .. [2] https://developer.android.com/studio/releases/platform-tools >> +.. [3] https://github.com/NXPmicro/mfgtools >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig >> index b97c67bf60..8f2d52cb8a 100644 >> --- a/drivers/fastboot/Kconfig >> +++ b/drivers/fastboot/Kconfig >> @@ -80,12 +80,12 @@ config FASTBOOT_FLASH >> this to enable the "fastboot flash" command. >> config FASTBOOT_UUU_SUPPORT >> - bool "Enable FASTBOOT i.MX UUU special command" >> + bool "Enable running arbitrary commands from FASTBOOT" >> help >> - The fastboot protocol includes "UCmd" and "ACmd" command. >> - Be aware that you provide full access to any U-Boot command, >> - including working with memory and may open a huge backdoor, >> - when enabling this option. >> + This extends the fastboot protocol with the "UCmd" and "ACmd" >> + commands, as well as the "oem run" command. These commands provide >> + full access to any U-Boot command, including working with memory. >> + This may open a huge backdoor if you are using verified boot. >> > > why the support of "oem run" generic support is include in the IMX config > CONFIG_FASTBOOT_UUU_SUPPORT > Because they are effectively the same command, but named differently. oem run is just an alias for UCmd which can be used by the fastboot Linux command without modification. > "UCmd" and "Acmd" are imx additions in fastboot standard for UUU support > > https://android.googlesource.com/platform/system/core/+/2ec418a4c98f6e8f95395456e1ad4c2956cac007/fastboot/fastboot_protocol.txt These commands are absent from that standard (and thus are non-standard). > but "oem run" can be see as generic U-Boot 'oem' command to execute U-boot > command. All of these commands are effectively non-standard, although "oem" is a common prefix. > for me I see 2 separate configs to handle other platform than IMX ones (with > UUU support) > > > config FASTBOOT_CMD_OEM_RUN > bool "Enable fastboot oem run command" > > config FASTBOOT_UUU_SUPPORT > bool "Enable FASTBOOT i.MX UUU special command" > select FASTBOOT_CMD_OEM_RUN > > > PS: FASTBOOT_UUU_SUPPORT could depends on CONFIG_ARCH_IMX* Maybe we can have something like config FASTBOOT_ARBITRARY_EXECUTION which UUU_SUPPORT could depend on. >> choice >> prompt "Flash provider for FASTBOOT" >> diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c >> index 98eccc3455..1732406c18 100644 >> --- a/drivers/fastboot/fb_command.c >> +++ b/drivers/fastboot/fb_command.c
Re: [PATCH v5 01/19] net: ipv6: Add IPv6 basic primitives
On Fri, Dec 02, 2022 at 12:17:58PM +0300, Viacheslav Mitrofanov wrote: > This patch is a collection of basic primitives that are prerequisite for > further IPv6 implementation. > > There are structures definition such as IPv6 header, UDP header > (for TFTP), ICMPv6 header. There are auxiliary defines such as protocol > codes, padding, struct size and etc. Also here are functions prototypes > and its empty implementation that will be used as API for further patches. > Here are variables declaration such as IPv6 address of our host, > gateway, ipv6 server. > > Series-changes: 3 > - Added functions and structures descriptions > - Removed enums ND_OPT_*. It will be moved into further patches > - Substituted -1 for error codes > > Series-changes: 4 > - Changed functions and structures description style > > Signed-off-by: Viacheslav Mitrofanov > Reviewed-by: Ramon Fried > Reviewed-by: Simon Glass For the series, applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[ANN] U-Boot v2023.01-rc3 released
Hey all, Now that we're back on schedule, here's -rc3. Since -rc2 I've pulled in a lot of network changes that've been outstanding, and with maybe one exception that's done now. I hope we can stay in a fairly narrow stabilization patch flow now, and to that end I'm also opening up -next. With -next I plan to start taking the changes to allow for newer gcc/clang and also the large sets of CONFIG migration / rename work. In terms of a changelog, git log --merges v2023.01-rc2..v2023.01-rc3 contains what I've pulled but as always, better PR messages and tags will provide better results here. Looking forward, the schedule is for now rcs every other Monday, and with final release on January 9th, 2023. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH] sunxi: define SYS_MONITOR_LEN in Kconfig, not _defconfig
Dne sreda, 23. november 2022 ob 23:51:17 CET je Andre Przywara napisal(a):
> Commit 08574ed339fb ("Convert CONFIG_SYS_MONITOR_LEN to Kconfig") moved
> the definition of said config variable from the common sunxi header to
> *every board's* defconfig.
> This is a platform choice, not board specific, so remove the variable
> from there, instead set the one value for all Allwinner boards in
> Kconfig.
>
> Signed-off-by: Andre Przywara
Acked-by: Jernej Skrabec
Best regards,
Jernej
Re: [PATCH] rockchip: Pinebook Pro: Do not initialize i2c before relocation
On Sat, Dec 3, 2022 at 12:31 PM Michal Suchanek wrote:
>
> The i2c locks up when initialized before relocation, and it stays broken
> in Linux as well breaking the ability to boot Linux.
>
> The i2c bus and pmic was not actually used in pre-reloc before
> commit ad607512f575 ("power: pmic: rk8xx: Support sysreset shutdown method")
>
> The cause is not known.
>
> This is board-specific, other boards that do not add the option to
> include the i2c bus in pre-reloc DT are not affected.
>
> Signed-off-by: Michal Suchanek
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
Thanks for checking this out, I had noticed a regression and had got
as far as bisecting it but not getting to a fix.
Tom: can we get this pulled into 2023.01 please?
Peter
> ---
>
> This is not tested, my board does not currentl;y boot at all, YMMV
> ---
> arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> index 2d87bea933..fd87102c0b 100644
> --- a/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi
> @@ -20,14 +20,6 @@
> rockchip,panel = <&edp_panel>;
> };
>
> -&i2c0 {
> - u-boot,dm-pre-reloc;
> -};
> -
> -&rk808 {
> - u-boot,dm-pre-reloc;
> -};
> -
> &sdhci {
> max-frequency = <2500>;
> u-boot,dm-pre-reloc;
> --
> 2.38.1
>
Re: [PATCH] rockchip: Pinebook Pro: Do not initialize i2c before relocation
On Mon, Dec 05, 2022 at 09:35:41PM +, Peter Robinson wrote:
> On Sat, Dec 3, 2022 at 12:31 PM Michal Suchanek wrote:
> >
> > The i2c locks up when initialized before relocation, and it stays broken
> > in Linux as well breaking the ability to boot Linux.
> >
> > The i2c bus and pmic was not actually used in pre-reloc before
> > commit ad607512f575 ("power: pmic: rk8xx: Support sysreset shutdown method")
> >
> > The cause is not known.
> >
> > This is board-specific, other boards that do not add the option to
> > include the i2c bus in pre-reloc DT are not affected.
> >
> > Signed-off-by: Michal Suchanek
>
> Reviewed-by: Peter Robinson
> Tested-by: Peter Robinson
>
> Thanks for checking this out, I had noticed a regression and had got
> as far as bisecting it but not getting to a fix.
>
> Tom: can we get this pulled into 2023.01 please?
Probably should be, yes. Kever, are there any other rockchip must-fixes
for v2023.01? I can take this directly if you don't have others and/or
don't want to make up a PR, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote:
>
> Buildman should consider a build as a success (with warnings) if missing
> blobs have been dealt with by binman, even though buildman itself returns
> and error code overall. This is how other warnings are dealt with.
>
> We cannot easily access the 103 exit code, so detect the problem in the
> output.
>
> With this change, missing blobs result in an exit code of 101, although
> they still indicate failure.
So either this or Tom's change of "buildman: Add --allow-missing flag
to allow missing blobs" has broken rc3 builds for Allwinner boards on
Fedora. Tom's isn't a clean revert and I've not had time to test that
but either way the SCP firmware is optional and it works just fine,
ATM we don't have the SCP firmware available to Fedora builds.
Maybe that sort of of change to the build is expected but which ever
patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but
doesn't change the overall failure, I wouldn't expect this sort of
breakage so late in the cycle.
Do either of you know which one does the hard breakage here? I thought
I'd highlight it now because I don't have time over the next two weeks
to fully investigate the regression.
Peter
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> tools/buildman/builderthread.py | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py
> index 6240e08c767..065d836d68c 100644
> --- a/tools/buildman/builderthread.py
> +++ b/tools/buildman/builderthread.py
> @@ -288,10 +288,14 @@ class BuilderThread(threading.Thread):
> args.append('cfg')
> result = self.Make(commit, brd, 'build', cwd, *args,
> env=env)
> +if (result.return_code == 2 and
> +('Some images are invalid' in result.stderr)):
> +# This is handled later by the check for output in
> +# stderr
> +result.return_code = 0
> if adjust_cfg:
> errs = cfgutil.check_cfg_file(cfg_file, adjust_cfg)
> if errs:
> -print('errs', errs)
> result.stderr += errs
> result.return_code = 1
> result.stderr = result.stderr.replace(src_dir + '/', '')
> --
> 2.38.1.431.g37b22c650d-goog
>
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote: > > > > Buildman should consider a build as a success (with warnings) if missing > > blobs have been dealt with by binman, even though buildman itself returns > > and error code overall. This is how other warnings are dealt with. > > > > We cannot easily access the 103 exit code, so detect the problem in the > > output. > > > > With this change, missing blobs result in an exit code of 101, although > > they still indicate failure. > > So either this or Tom's change of "buildman: Add --allow-missing flag > to allow missing blobs" has broken rc3 builds for Allwinner boards on > Fedora. Tom's isn't a clean revert and I've not had time to test that > but either way the SCP firmware is optional and it works just fine, > ATM we don't have the SCP firmware available to Fedora builds. > > Maybe that sort of of change to the build is expected but which ever > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but > doesn't change the overall failure, I wouldn't expect this sort of > breakage so late in the cycle. > > Do either of you know which one does the hard breakage here? I thought > I'd highlight it now because I don't have time over the next two weeks > to fully investigate the regression. So, is this for 32bit or 64bit? I only have a 64bit allwinner in my lab and it needs (I've been assuming, since I'm also passing in SCP) BL31 as well. And since you're mentioning buildman, I assume Fedora IS using that rather than make to build everything. I'll go and think about this now.. -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote: > > > > > > Buildman should consider a build as a success (with warnings) if missing > > > blobs have been dealt with by binman, even though buildman itself returns > > > and error code overall. This is how other warnings are dealt with. > > > > > > We cannot easily access the 103 exit code, so detect the problem in the > > > output. > > > > > > With this change, missing blobs result in an exit code of 101, although > > > they still indicate failure. > > > > So either this or Tom's change of "buildman: Add --allow-missing flag > > to allow missing blobs" has broken rc3 builds for Allwinner boards on > > Fedora. Tom's isn't a clean revert and I've not had time to test that > > but either way the SCP firmware is optional and it works just fine, > > ATM we don't have the SCP firmware available to Fedora builds. > > > > Maybe that sort of of change to the build is expected but which ever > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but > > doesn't change the overall failure, I wouldn't expect this sort of > > breakage so late in the cycle. > > > > Do either of you know which one does the hard breakage here? I thought > > I'd highlight it now because I don't have time over the next two weeks > > to fully investigate the regression. > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my lab 64 bit, 32 bit is EOL in Fedora as of F-36. > and it needs (I've been assuming, since I'm also passing in SCP) BL31 as BL31 isn't the same as SCP, the later is a firmware for the onboard PMIC co-processor where as BL31 is Arm Trusted Firmware. > well. And since you're mentioning buildman, I assume Fedora IS using > that rather than make to build everything. I'll go and think about this I'm using: make pine64_plus_defconfig O=builds/pine64_plus/ cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin builds/pine64_plus/ make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ I thought binman was basically default for this now. I tried for the last line the following, it changed the error output but not the failure: BINMAN_ALLOW_MISSING=1 make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ Peter
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote: > > > > > > > > Buildman should consider a build as a success (with warnings) if missing > > > > blobs have been dealt with by binman, even though buildman itself > > > > returns > > > > and error code overall. This is how other warnings are dealt with. > > > > > > > > We cannot easily access the 103 exit code, so detect the problem in the > > > > output. > > > > > > > > With this change, missing blobs result in an exit code of 101, although > > > > they still indicate failure. > > > > > > So either this or Tom's change of "buildman: Add --allow-missing flag > > > to allow missing blobs" has broken rc3 builds for Allwinner boards on > > > Fedora. Tom's isn't a clean revert and I've not had time to test that > > > but either way the SCP firmware is optional and it works just fine, > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > Maybe that sort of of change to the build is expected but which ever > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but > > > doesn't change the overall failure, I wouldn't expect this sort of > > > breakage so late in the cycle. > > > > > > Do either of you know which one does the hard breakage here? I thought > > > I'd highlight it now because I don't have time over the next two weeks > > > to fully investigate the regression. > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my lab > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > and it needs (I've been assuming, since I'm also passing in SCP) BL31 as > > BL31 isn't the same as SCP, the later is a firmware for the onboard > PMIC co-processor where as BL31 is Arm Trusted Firmware. Right, yes. > > well. And since you're mentioning buildman, I assume Fedora IS using > > that rather than make to build everything. I'll go and think about this > > I'm using: > make pine64_plus_defconfig O=builds/pine64_plus/ > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin builds/pine64_plus/ > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ OK, that's a little different than how I run make, that's why it wasn't caught at least. I do: export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin export BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > I thought binman was basically default for this now. We have too many *man tools sometimes. I thought you said buildman, yes, binman assembles the images here, when invoking make. Digging more now, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote: > > > > > > > > > > Buildman should consider a build as a success (with warnings) if > > > > > missing > > > > > blobs have been dealt with by binman, even though buildman itself > > > > > returns > > > > > and error code overall. This is how other warnings are dealt with. > > > > > > > > > > We cannot easily access the 103 exit code, so detect the problem in > > > > > the > > > > > output. > > > > > > > > > > With this change, missing blobs result in an exit code of 101, > > > > > although > > > > > they still indicate failure. > > > > > > > > So either this or Tom's change of "buildman: Add --allow-missing flag > > > > to allow missing blobs" has broken rc3 builds for Allwinner boards on > > > > Fedora. Tom's isn't a clean revert and I've not had time to test that > > > > but either way the SCP firmware is optional and it works just fine, > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > Maybe that sort of of change to the build is expected but which ever > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but > > > > doesn't change the overall failure, I wouldn't expect this sort of > > > > breakage so late in the cycle. > > > > > > > > Do either of you know which one does the hard breakage here? I thought > > > > I'd highlight it now because I don't have time over the next two weeks > > > > to fully investigate the regression. > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my lab > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > and it needs (I've been assuming, since I'm also passing in SCP) BL31 as > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > Right, yes. > > > > well. And since you're mentioning buildman, I assume Fedora IS using > > > that rather than make to build everything. I'll go and think about this > > > > I'm using: > > make pine64_plus_defconfig O=builds/pine64_plus/ > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin builds/pine64_plus/ > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ > > OK, that's a little different than how I run make, that's why it wasn't > caught at least. I do: > export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > export BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) We build ~90 boards so we've historically copied it to each of the board build output directories, could look at setting vars for each of the loops too. > > I thought binman was basically default for this now. > > We have too many *man tools sometimes. I thought you said buildman, yes, > binman assembles the images here, when invoking make. Digging more now, > thanks! It could easily be me getting confused, trying to balance a lot of plates right now :-/ Peter
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 05, 2022 at 11:43:24PM +, Peter Robinson wrote: > On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass wrote: > > > > > > > > > > > > Buildman should consider a build as a success (with warnings) if > > > > > > missing > > > > > > blobs have been dealt with by binman, even though buildman itself > > > > > > returns > > > > > > and error code overall. This is how other warnings are dealt with. > > > > > > > > > > > > We cannot easily access the 103 exit code, so detect the problem in > > > > > > the > > > > > > output. > > > > > > > > > > > > With this change, missing blobs result in an exit code of 101, > > > > > > although > > > > > > they still indicate failure. > > > > > > > > > > So either this or Tom's change of "buildman: Add --allow-missing flag > > > > > to allow missing blobs" has broken rc3 builds for Allwinner boards on > > > > > Fedora. Tom's isn't a clean revert and I've not had time to test that > > > > > but either way the SCP firmware is optional and it works just fine, > > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > > > Maybe that sort of of change to the build is expected but which ever > > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error but > > > > > doesn't change the overall failure, I wouldn't expect this sort of > > > > > breakage so late in the cycle. > > > > > > > > > > Do either of you know which one does the hard breakage here? I thought > > > > > I'd highlight it now because I don't have time over the next two weeks > > > > > to fully investigate the regression. > > > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my lab > > > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > > > and it needs (I've been assuming, since I'm also passing in SCP) BL31 as > > > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > > > Right, yes. > > > > > > well. And since you're mentioning buildman, I assume Fedora IS using > > > > that rather than make to build everything. I'll go and think about this > > > > > > I'm using: > > > make pine64_plus_defconfig O=builds/pine64_plus/ > > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin builds/pine64_plus/ > > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ > > > > OK, that's a little different than how I run make, that's why it wasn't > > caught at least. I do: > > export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > > export BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > > We build ~90 boards so we've historically copied it to each of the > board build output directories, could look at setting vars for each of > the loops too. > > > > I thought binman was basically default for this now. > > > > We have too many *man tools sometimes. I thought you said buildman, yes, > > binman assembles the images here, when invoking make. Digging more now, > > thanks! > > It could easily be me getting confused, trying to balance a lot of > plates right now :-/ OK, so yes, you've found a problem here. What I need to throw a CI loop at now is: diff --git a/Makefile b/Makefile index d48f52f2943b..b2253ac8ecde 100644 --- a/Makefile +++ b/Makefile @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \ --toolpath $(objtree)/tools \ $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ build -u -d u-boot.dtb -O . -m \ - $(if $(BINMAN_ALLOW_MISSING),--allow-missing --fake-ext-blobs) \ + $(if $(BINMAN_ALLOW_MISSING),--allow-missing --ignore-missing) \ -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ Which means that this then works: $ (export CROSS_COMPILE=~/.buildman-toolchains/gcc-11.1.0-nolibc/aarch64-linux/bin/aarch64-linux- ; make pine64_plus_defconfig O=builds/pine64_plus ; cp /home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin builds/pine64_plus ; BINMAN_ALLOW_MISSING=1 make O=builds/pine64_plus -sj$(nproc); echo $?) make[1]: Entering directory '/home/trini/work/u-boot/u-boot/builds/pine64_plus' GEN Makefile # # configuration written to .config # make[1]: Leaving directory '/home/trini/work/u-boot/u-boot/builds/pine64_plus' Image 'main-section' is missing external blobs and is non-functional: scp /binman/u-boot-sunxi-with-spl/fit/images/scp/scp: SCP firmware is required for system suspend
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Mon, Dec 5, 2022 at 11:46 PM Tom Rini wrote: > > On Mon, Dec 05, 2022 at 11:43:24PM +, Peter Robinson wrote: > > On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > > > > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Buildman should consider a build as a success (with warnings) if > > > > > > > missing > > > > > > > blobs have been dealt with by binman, even though buildman itself > > > > > > > returns > > > > > > > and error code overall. This is how other warnings are dealt with. > > > > > > > > > > > > > > We cannot easily access the 103 exit code, so detect the problem > > > > > > > in the > > > > > > > output. > > > > > > > > > > > > > > With this change, missing blobs result in an exit code of 101, > > > > > > > although > > > > > > > they still indicate failure. > > > > > > > > > > > > So either this or Tom's change of "buildman: Add --allow-missing > > > > > > flag > > > > > > to allow missing blobs" has broken rc3 builds for Allwinner boards > > > > > > on > > > > > > Fedora. Tom's isn't a clean revert and I've not had time to test > > > > > > that > > > > > > but either way the SCP firmware is optional and it works just fine, > > > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > > > > > Maybe that sort of of change to the build is expected but which ever > > > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error > > > > > > but > > > > > > doesn't change the overall failure, I wouldn't expect this sort of > > > > > > breakage so late in the cycle. > > > > > > > > > > > > Do either of you know which one does the hard breakage here? I > > > > > > thought > > > > > > I'd highlight it now because I don't have time over the next two > > > > > > weeks > > > > > > to fully investigate the regression. > > > > > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my > > > > > lab > > > > > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > > > > > and it needs (I've been assuming, since I'm also passing in SCP) BL31 > > > > > as > > > > > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > > > > > Right, yes. > > > > > > > > well. And since you're mentioning buildman, I assume Fedora IS using > > > > > that rather than make to build everything. I'll go and think about > > > > > this > > > > > > > > I'm using: > > > > make pine64_plus_defconfig O=builds/pine64_plus/ > > > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin > > > > builds/pine64_plus/ > > > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ > > > > > > OK, that's a little different than how I run make, that's why it wasn't > > > caught at least. I do: > > > export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > > > export BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > > > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > > > > We build ~90 boards so we've historically copied it to each of the > > board build output directories, could look at setting vars for each of > > the loops too. > > > > > > I thought binman was basically default for this now. > > > > > > We have too many *man tools sometimes. I thought you said buildman, yes, > > > binman assembles the images here, when invoking make. Digging more now, > > > thanks! > > > > It could easily be me getting confused, trying to balance a lot of > > plates right now :-/ > > OK, so yes, you've found a problem here. What I need to throw a CI loop > at now is: > diff --git a/Makefile b/Makefile > index d48f52f2943b..b2253ac8ecde 100644 > --- a/Makefile > +++ b/Makefile > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > $(BINMAN_DEBUG),-D) \ > --toolpath $(objtree)/tools \ > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > build -u -d u-boot.dtb -O . -m \ > - $(if $(BINMAN_ALLOW_MISSING),--allow-missing > --fake-ext-blobs) \ > + $(if $(BINMAN_ALLOW_MISSING),--allow-missing > --ignore-missing) \ > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ > > Which means that this then works: > $ (export > CROSS_COMPILE=~/.buildman-toolchains/gcc-11.1.0-nolibc/aarch64-linux/bin/aarch64-linux- > ; make pine64_plus_defconfig O=builds/pine64_plus ; cp > /home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > builds/pine64_plus ; BINMAN_ALLOW_MISSING=1 make O=builds/pine64_plus > -sj$(nproc); echo $?) > m
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
Hi Tom, On Tue, 6 Dec 2022 at 12:46, Tom Rini wrote: > > On Mon, Dec 05, 2022 at 11:43:24PM +, Peter Robinson wrote: > > On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > > > > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass > > > > > > wrote: > > > > > > > > > > > > > > Buildman should consider a build as a success (with warnings) if > > > > > > > missing > > > > > > > blobs have been dealt with by binman, even though buildman itself > > > > > > > returns > > > > > > > and error code overall. This is how other warnings are dealt with. > > > > > > > > > > > > > > We cannot easily access the 103 exit code, so detect the problem > > > > > > > in the > > > > > > > output. > > > > > > > > > > > > > > With this change, missing blobs result in an exit code of 101, > > > > > > > although > > > > > > > they still indicate failure. > > > > > > > > > > > > So either this or Tom's change of "buildman: Add --allow-missing > > > > > > flag > > > > > > to allow missing blobs" has broken rc3 builds for Allwinner boards > > > > > > on > > > > > > Fedora. Tom's isn't a clean revert and I've not had time to test > > > > > > that > > > > > > but either way the SCP firmware is optional and it works just fine, > > > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > > > > > Maybe that sort of of change to the build is expected but which ever > > > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the error > > > > > > but > > > > > > doesn't change the overall failure, I wouldn't expect this sort of > > > > > > breakage so late in the cycle. > > > > > > > > > > > > Do either of you know which one does the hard breakage here? I > > > > > > thought > > > > > > I'd highlight it now because I don't have time over the next two > > > > > > weeks > > > > > > to fully investigate the regression. > > > > > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my > > > > > lab > > > > > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > > > > > and it needs (I've been assuming, since I'm also passing in SCP) BL31 > > > > > as > > > > > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > > > > > Right, yes. > > > > > > > > well. And since you're mentioning buildman, I assume Fedora IS using > > > > > that rather than make to build everything. I'll go and think about > > > > > this > > > > > > > > I'm using: > > > > make pine64_plus_defconfig O=builds/pine64_plus/ > > > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin > > > > builds/pine64_plus/ > > > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ > > > > > > OK, that's a little different than how I run make, that's why it wasn't > > > caught at least. I do: > > > export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > > > export BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > > > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > > > > We build ~90 boards so we've historically copied it to each of the > > board build output directories, could look at setting vars for each of > > the loops too. > > > > > > I thought binman was basically default for this now. > > > > > > We have too many *man tools sometimes. I thought you said buildman, yes, > > > binman assembles the images here, when invoking make. Digging more now, > > > thanks! > > > > It could easily be me getting confused, trying to balance a lot of > > plates right now :-/ > > OK, so yes, you've found a problem here. What I need to throw a CI loop > at now is: > diff --git a/Makefile b/Makefile > index d48f52f2943b..b2253ac8ecde 100644 > --- a/Makefile > +++ b/Makefile > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > $(BINMAN_DEBUG),-D) \ > --toolpath $(objtree)/tools \ > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > build -u -d u-boot.dtb -O . -m \ > - $(if $(BINMAN_ALLOW_MISSING),--allow-missing > --fake-ext-blobs) \ > + $(if $(BINMAN_ALLOW_MISSING),--allow-missing > --ignore-missing) \ I think you need to keep the old flag too, right? > -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ > -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ > $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ > > Which means that this then works: > $ (export > CROSS_COMPILE=~/.buildman-toolchains/gcc-11.1.0-nolibc/aarch64-linux/bin/aarch64-linux- > ; make pine64_plus_defconfig O=builds/pine64_plus ; cp > /home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > builds/pine64_plus ; BINMAN_ALLOW_MISSIN
Re: [RFC 1/1] sound: allow waveform selection
Hi Heinrich, On Mon, 5 Dec 2022 at 13:38, Heinrich Schuchardt wrote: > > * Allow the sound command to select the sine or the square waveform. > * Allow to play multiple tones with one command. > * Adjust documentation. > * Adjust unit test. > > Signed-off-by: Heinrich Schuchardt > --- > This would be the alternative to > [v2,6/7] sound: add CONFIG_SOUND_SINE symbol > For testing with the sandbox remove this line > > arch/sandbox/dts/test.dts:969 > sandbox,silent; /* Don't emit sounds while testing */ > > run the sand box with './u-boot -T' and issue the following commands > > sound play > sound play -s > sound play -s 600 500 -q > sound play -s 500 1047 500 880 500 0 500 1047 500 880 500 0 500 784 500 > 698 500 784 1000 698 > > Listening to the output demonstrates why patch 7/7 is needed. > --- > arch/sandbox/include/asm/test.h | 7 > cmd/sound.c | 60 ++--- > doc/usage/cmd/sound.rst | 28 ++- > drivers/sound/sandbox.c | 7 > drivers/sound/sound-uclass.c| 19 +-- > include/sound.h | 21 +--- > test/dm/sound.c | 45 - > 7 files changed, 151 insertions(+), 36 deletions(-) This seems OK to me. Perhaps add a few run_command() tests as well? Regards, Simon
Re: [PATCH] rockchip: Pinebook Pro: Do not initialize i2c before relocation
Hi,
On Tue, 6 Dec 2022 at 11:25, Tom Rini wrote:
>
> On Mon, Dec 05, 2022 at 09:35:41PM +, Peter Robinson wrote:
> > On Sat, Dec 3, 2022 at 12:31 PM Michal Suchanek wrote:
> > >
> > > The i2c locks up when initialized before relocation, and it stays broken
> > > in Linux as well breaking the ability to boot Linux.
> > >
> > > The i2c bus and pmic was not actually used in pre-reloc before
> > > commit ad607512f575 ("power: pmic: rk8xx: Support sysreset shutdown
> > > method")
> > >
> > > The cause is not known.
> > >
> > > This is board-specific, other boards that do not add the option to
> > > include the i2c bus in pre-reloc DT are not affected.
> > >
> > > Signed-off-by: Michal Suchanek
> >
> > Reviewed-by: Peter Robinson
> > Tested-by: Peter Robinson
> >
> > Thanks for checking this out, I had noticed a regression and had got
> > as far as bisecting it but not getting to a fix.
> >
> > Tom: can we get this pulled into 2023.01 please?
>
> Probably should be, yes. Kever, are there any other rockchip must-fixes
> for v2023.01? I can take this directly if you don't have others and/or
> don't want to make up a PR, thanks!
There is also this one:
https://patchwork.ozlabs.org/project/uboot/patch/20220928024046.2657593-1-...@chromium.org/
Regards,
Simon
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
On Tue, Dec 06, 2022 at 12:55:08PM +1300, Simon Glass wrote: > Hi Tom, > > On Tue, 6 Dec 2022 at 12:46, Tom Rini wrote: > > > > On Mon, Dec 05, 2022 at 11:43:24PM +, Peter Robinson wrote: > > > On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > > > > > > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > > > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass > > > > > > > wrote: > > > > > > > > > > > > > > > > Buildman should consider a build as a success (with warnings) > > > > > > > > if missing > > > > > > > > blobs have been dealt with by binman, even though buildman > > > > > > > > itself returns > > > > > > > > and error code overall. This is how other warnings are dealt > > > > > > > > with. > > > > > > > > > > > > > > > > We cannot easily access the 103 exit code, so detect the > > > > > > > > problem in the > > > > > > > > output. > > > > > > > > > > > > > > > > With this change, missing blobs result in an exit code of 101, > > > > > > > > although > > > > > > > > they still indicate failure. > > > > > > > > > > > > > > So either this or Tom's change of "buildman: Add --allow-missing > > > > > > > flag > > > > > > > to allow missing blobs" has broken rc3 builds for Allwinner > > > > > > > boards on > > > > > > > Fedora. Tom's isn't a clean revert and I've not had time to test > > > > > > > that > > > > > > > but either way the SCP firmware is optional and it works just > > > > > > > fine, > > > > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > > > > > > > Maybe that sort of of change to the build is expected but which > > > > > > > ever > > > > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the > > > > > > > error but > > > > > > > doesn't change the overall failure, I wouldn't expect this sort of > > > > > > > breakage so late in the cycle. > > > > > > > > > > > > > > Do either of you know which one does the hard breakage here? I > > > > > > > thought > > > > > > > I'd highlight it now because I don't have time over the next two > > > > > > > weeks > > > > > > > to fully investigate the regression. > > > > > > > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in my > > > > > > lab > > > > > > > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > > > > > > > and it needs (I've been assuming, since I'm also passing in SCP) > > > > > > BL31 as > > > > > > > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > > > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > > > > > > > Right, yes. > > > > > > > > > > well. And since you're mentioning buildman, I assume Fedora IS > > > > > > using > > > > > > that rather than make to build everything. I'll go and think about > > > > > > this > > > > > > > > > > I'm using: > > > > > make pine64_plus_defconfig O=builds/pine64_plus/ > > > > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin > > > > > builds/pine64_plus/ > > > > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" O=builds/pine64_plus/ > > > > > > > > OK, that's a little different than how I run make, that's why it wasn't > > > > caught at least. I do: > > > > export SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > > > > export > > > > BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > > > > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > > > > > > We build ~90 boards so we've historically copied it to each of the > > > board build output directories, could look at setting vars for each of > > > the loops too. > > > > > > > > I thought binman was basically default for this now. > > > > > > > > We have too many *man tools sometimes. I thought you said buildman, yes, > > > > binman assembles the images here, when invoking make. Digging more now, > > > > thanks! > > > > > > It could easily be me getting confused, trying to balance a lot of > > > plates right now :-/ > > > > OK, so yes, you've found a problem here. What I need to throw a CI loop > > at now is: > > diff --git a/Makefile b/Makefile > > index d48f52f2943b..b2253ac8ecde 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > > $(BINMAN_DEBUG),-D) \ > > --toolpath $(objtree)/tools \ > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > > build -u -d u-boot.dtb -O . -m \ > > - $(if $(BINMAN_ALLOW_MISSING),--allow-missing > > --fake-ext-blobs) \ > > + $(if $(BINMAN_ALLOW_MISSING),--allow-missing > > --ignore-missing) \ > > I think you need to keep the old flag too, right? Not in my first pine64_plus only test, but I just threw CI at the world, so pass-or-fireworks in about an hour. -- Tom signature.asc Description: PGP signat
Re: [PATCH v5 10/16] buildman: Detect binman reporting missing blobs
Hi Tom, On Tue, 6 Dec 2022 at 12:56, Tom Rini wrote: > > On Tue, Dec 06, 2022 at 12:55:08PM +1300, Simon Glass wrote: > > Hi Tom, > > > > On Tue, 6 Dec 2022 at 12:46, Tom Rini wrote: > > > > > > On Mon, Dec 05, 2022 at 11:43:24PM +, Peter Robinson wrote: > > > > On Mon, Dec 5, 2022 at 11:35 PM Tom Rini wrote: > > > > > > > > > > On Mon, Dec 05, 2022 at 11:29:30PM +, Peter Robinson wrote: > > > > > > On Mon, Dec 5, 2022 at 11:23 PM Tom Rini wrote: > > > > > > > > > > > > > > On Mon, Dec 05, 2022 at 11:13:03PM +, Peter Robinson wrote: > > > > > > > > On Thu, Nov 10, 2022 at 2:17 AM Simon Glass > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Buildman should consider a build as a success (with warnings) > > > > > > > > > if missing > > > > > > > > > blobs have been dealt with by binman, even though buildman > > > > > > > > > itself returns > > > > > > > > > and error code overall. This is how other warnings are dealt > > > > > > > > > with. > > > > > > > > > > > > > > > > > > We cannot easily access the 103 exit code, so detect the > > > > > > > > > problem in the > > > > > > > > > output. > > > > > > > > > > > > > > > > > > With this change, missing blobs result in an exit code of > > > > > > > > > 101, although > > > > > > > > > they still indicate failure. > > > > > > > > > > > > > > > > So either this or Tom's change of "buildman: Add > > > > > > > > --allow-missing flag > > > > > > > > to allow missing blobs" has broken rc3 builds for Allwinner > > > > > > > > boards on > > > > > > > > Fedora. Tom's isn't a clean revert and I've not had time to > > > > > > > > test that > > > > > > > > but either way the SCP firmware is optional and it works just > > > > > > > > fine, > > > > > > > > ATM we don't have the SCP firmware available to Fedora builds. > > > > > > > > > > > > > > > > Maybe that sort of of change to the build is expected but which > > > > > > > > ever > > > > > > > > patch it is, and adding "BINMAN_ALLOW_MISSING=1" changes the > > > > > > > > error but > > > > > > > > doesn't change the overall failure, I wouldn't expect this sort > > > > > > > > of > > > > > > > > breakage so late in the cycle. > > > > > > > > > > > > > > > > Do either of you know which one does the hard breakage here? I > > > > > > > > thought > > > > > > > > I'd highlight it now because I don't have time over the next > > > > > > > > two weeks > > > > > > > > to fully investigate the regression. > > > > > > > > > > > > > > So, is this for 32bit or 64bit? I only have a 64bit allwinner in > > > > > > > my lab > > > > > > > > > > > > 64 bit, 32 bit is EOL in Fedora as of F-36. > > > > > > > > > > > > > and it needs (I've been assuming, since I'm also passing in SCP) > > > > > > > BL31 as > > > > > > > > > > > > BL31 isn't the same as SCP, the later is a firmware for the onboard > > > > > > PMIC co-processor where as BL31 is Arm Trusted Firmware. > > > > > > > > > > Right, yes. > > > > > > > > > > > > well. And since you're mentioning buildman, I assume Fedora IS > > > > > > > using > > > > > > > that rather than make to build everything. I'll go and think > > > > > > > about this > > > > > > > > > > > > I'm using: > > > > > > make pine64_plus_defconfig O=builds/pine64_plus/ > > > > > > cp /usr/share/arm-trusted-firmware/sun50i_a64/bl31.bin > > > > > > builds/pine64_plus/ > > > > > > make CROSS_COMPILE="/usr/bin/aarch64-linux-gnu-" > > > > > > O=builds/pine64_plus/ > > > > > > > > > > OK, that's a little different than how I run make, that's why it > > > > > wasn't > > > > > caught at least. I do: > > > > > export > > > > > SCP=/home/trini/work/u-boot/external-binaries/pine64_plus/scp.bin > > > > > export > > > > > BL31=/home/trini/work/u-boot/external-binaries/pine64_plus/bl31.bin > > > > > make O=/tmp/pine64_plus pine64_plus_defconfig all -sj$(nproc) > > > > > > > > We build ~90 boards so we've historically copied it to each of the > > > > board build output directories, could look at setting vars for each of > > > > the loops too. > > > > > > > > > > I thought binman was basically default for this now. > > > > > > > > > > We have too many *man tools sometimes. I thought you said buildman, > > > > > yes, > > > > > binman assembles the images here, when invoking make. Digging more > > > > > now, > > > > > thanks! > > > > > > > > It could easily be me getting confused, trying to balance a lot of > > > > plates right now :-/ > > > > > > OK, so yes, you've found a problem here. What I need to throw a CI loop > > > at now is: > > > diff --git a/Makefile b/Makefile > > > index d48f52f2943b..b2253ac8ecde 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if > > > $(BINMAN_DEBUG),-D) \ > > > --toolpath $(objtree)/tools \ > > > $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ > > > build -u -d u-boot.dtb -O . -m \ > > > - $(if $(BINMAN_ALLOW_MISSING)
Re: [PATCH v2 00/25] bootstd: Add a boot menu
Hi Heinrich (and anyone else), On Thu, 10 Nov 2022 at 15:15, Simon Glass wrote: > > Hi Heinrich, > > On Mon, 7 Nov 2022 at 16:35, Simon Glass wrote: > > > > Hi Heinrich, > > > > On Mon, 7 Nov 2022 at 12:15, Heinrich Schuchardt wrote: > > > > > > On 11/4/22 23:48, Simon Glass wrote: > > > > So far standard boot lacks a boot menu, although it is possible to > > > > create > > > > a rudimentary one using the existing 'bootmenu' command. > > > > > > > > Even then, this text-based menu offer only basic functionality and does > > > > not take full advantage of the displays which are common on many > > > > devices. > > > > > > > > This series provides a 'bootflow menu' command which allows the user to > > > > select from the available bootflows. An attempt is made to show the name > > > > of the available operating systems, by reading more information into the > > > > bootflow. A logo can be read also, where supported, so that this can be > > > > presented to the user when an option is highlighted. > > > > > > > > Full use is made of TrueType fonts, if enabled. For cases where only a > > > > serial console is available, it falls back to a simple text-based menu. > > > > > > Please, add the link to your design document > > > > > > https://docs.google.com/document/d/1VQeApnLlH6xKm_OI36AhWkJLUEd9OXEvIJXB8aM2de8/edit?resourcekey=0-DwgHpR2S8vJEJzvvwPb-AQ#heading=h.17wg41voij6q > > > is broken. > > > > What happens when you click that? It works for me. > > > > > > > > in future version of this series. > > > > > > The series leaves us with duplicate code in > > > > > > bootmenu_choice_entry() and eficonfig_choice_entry() as well as > > > bootmenu_loop() and bootmenu_autoboot_loop(). > > > > Yes OK, but that is the case today and my series actually removes some > > duplicated code, so perhaps that could be cleaned up later? > > > > > > > > The bootmenu command relies heavily on ANSI sequences but VIDEO_ANSI is > > > disabled by default for CONFIG_EFI_LOADER=n which means that the > > > bootmenu command will not work anymore. > > > > Does it not work, or does it just work but in a serial fashion? I > > don't see ANSI codes as being necessary to show a menu. > > > > > > > > > > > > > All of this is implementing using a new 'expo' construct, a collection > > > > of > > > > > > Expo is not an English word. Expo is typically used as name of trade > > > fairs. Transaction probably is the right word to use here. > > > > That is debatable I think. Transaction is quite generic and appears in > > U-Boot >400 times. I think it will just be confusing, like the word > > 'metadata' used in the FWU stuff. > > > > Expo is short for exposition. My use of it is somewhat archaic > > perhaps, but even for the meaning you mention, a public exposition is > > not a bad description of what is provided here. > > > > I am not 100% convinced about 'expo' either. Do you have any other ideas? > > > > > > > > Files expo.c and scene.c are in boot/ which does not match a generic GUI > > > feature. They should be placed in lib/. > > > > Yes I was wondering about that, but thought that boot/ made at least > > some sense since the menu will only ever be used for booting...? > > > > I can move it, but I am a little nervous about that, since lib/ > > normally has utility libraries. Perhaps lib/expo would be better? > > Just to say that I replied to your comments on the doc also, so let me > know what you think. I'd like to get this applied now that -next is opening. Do you have any more comments? Regards, Simon
[RFC PATCH 00/17] sunxi: rework pinctrl and add T113s support
Hi, this is some early attempt at supporting the new SoC series that covers the Allwinner D1 siblings R528 and T113s. They all share the same die, although the D1 and D1s use RISC-V cores, which requires more plumbing, to use the sunxi code across two architectures. Getting the R528 support in should help a bit in sorting out what's new peripheral code and what is architecture dependent. IIUC, Samuel has that running, although with some hacks, the number of which this series tries to reduce. The most interesting part of this is the pincontroller rework, this tackles two issues: - For the first time in the history of mainline Allwinner support the pincontroller changed the register layout. The code here tries to abstract the differences away, so both variants can share the code peacefully. - For the above mentioned reason, the pincontroller code is quite old, and is mostly spread out across arch/arm, in a pre-DM style, even though we have real DM support in U-Boot proper. We need the non-DM version for the (ARM-only?) legacy SPL, so can't get rid of that completely. This series also tries to modernise that code, and moves it into board/sunxi/, where it can be more easily shared with RISC-V. The preliminary MangoPi MQ-R bits on top are mostly for illustration purposes, and in case someone wants to give it a try. For some probably stupid reason MMC doesn't work, although the driver loads fine. Also this omits the DRAM code, although there is some GPLed code out there, which can be lifted into here, with some extra work. I would mostly appreciate to have some opinion on the pinctrl patches: I understand that patch 03/17 isn't strictly necessary, but I always disliked U-Boot's "use C structs to model MMIO register frames" approach, so thought now is the time to get rid of that ;-) Also I am unsure about patch 06/17, which seems like a step back (spreading per-SoC data over several files), but I actually aim at getting rid of cpu_sun[x]i.h altogether, since we should not really need it, except for some exceptions. The third patch I would like to hear feedback about is patch 08/17. Finally patch 14/17 would deserve some extra pair of eyes. Please let me know if you have any opinions! Cheers, Andre P.S. I understand there is some code to support those SoCs out there, apologies if I just re-implemented some of it. Please point me to patches that seem upstream-worthy, and I will happily integrate them in here, potentially replacing some of my patches. Andre Przywara (15): sunxi: remove CONFIG_SATAPWR sunxi: remove CONFIG_MACPWR pinctrl: sunxi: remove struct sunxi_gpio pinctrl: sunxi: add GPIO in/out wrappers pinctrl: sunxi: move pinctrl code and remove GPIO_EXTRA_HEADER pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h pinctrl: sunxi: add new D1 pinctrl support sunxi: introduce NCAT2 generation model pinctrl: sunxi: add Allwinner D1 pinctrl description sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup sunxi: clock: support D1/R528 PLL6 clock sunxi: add early Allwinner R528/T113 SoC support sunxi: refactor serial base addresses to avoid asm/arch/cpu.h arm: sunxi: add Allwinner T113s devicetree stub sunxi: add preliminary MangoPi MQ-R board support Samuel Holland (2): clk: sunxi: Add support for the D1 CCU riscv: dts: allwinner: Add the D1/D1s SoC devicetree arch/arm/Kconfig | 3 +- arch/arm/cpu/armv7/sunxi/sram.c | 1 + arch/arm/cpu/armv8/fel_utils.S| 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts | 54 ++ arch/arm/dts/sun8i-t113s.dtsi | 59 ++ arch/arm/include/asm/arch-sunxi/clock.h | 3 +- .../include/asm/arch-sunxi/clock_sun50i_h6.h | 8 + arch/arm/include/asm/arch-sunxi/cpu.h | 2 + arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 17 - .../include/asm/arch-sunxi/cpu_sun50i_h6.h| 7 - arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 9 - .../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 49 + arch/arm/include/asm/arch-sunxi/mmc.h | 2 +- arch/arm/include/asm/arch-sunxi/prcm.h| 2 +- arch/arm/include/asm/arch-sunxi/serial.h | 32 + arch/arm/include/asm/arch-sunxi/timer.h | 2 +- arch/arm/mach-sunxi/Kconfig | 51 +- arch/arm/mach-sunxi/Makefile | 2 +- arch/arm/mach-sunxi/board.c | 9 +- arch/arm/mach-sunxi/clock_sun50i_h6.c | 38 +- arch/arm/mach-sunxi/cpu_info.c| 2 + arch/arm/mach-sunxi/dram_suniv.c | 2 +- arch/arm/mach-sunxi/gtbus_sun9i.c | 1 + arch/arm/mach-sunxi/pinmux.c | 78 -- arch/arm/mach-sunxi/spl_spi_sunxi.c | 1 + arch/arm/mach-sunxi/timer.c | 1 + arch/riscv/dts/sun20i-d1.dtsi | 66 ++ arch/riscv/dts/sun20i-d1s.dtsi| 76 ++ arch/riscv/dts/su
[RFC PATCH 01/17] sunxi: remove CONFIG_SATAPWR
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Signed-off-by: Andre Przywara
---
arch/arm/Kconfig | 2 ++
arch/arm/mach-sunxi/Kconfig | 8
board/sunxi/board.c | 14 --
configs/A10-OLinuXino-Lime_defconfig | 1 -
configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 -
configs/A20-OLinuXino-Lime2_defconfig| 1 -
configs/A20-OLinuXino-Lime_defconfig | 1 -
configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 -
configs/A20-OLinuXino_MICRO_defconfig| 1 -
configs/A20-Olimex-SOM-EVB_defconfig | 1 -
configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 -
configs/A20-Olimex-SOM204-EVB_defconfig | 1 -
configs/Cubieboard2_defconfig| 1 -
configs/Cubieboard_defconfig | 1 -
configs/Cubietruck_defconfig | 1 -
configs/Itead_Ibox_A20_defconfig | 1 -
configs/Lamobo_R1_defconfig | 1 -
configs/Linksprite_pcDuino3_Nano_defconfig | 1 -
configs/Linksprite_pcDuino3_defconfig| 1 -
configs/Sinovoip_BPI_M3_defconfig| 1 -
configs/orangepi_plus_defconfig | 1 -
drivers/ata/ahci_sunxi.c | 9 +
22 files changed, 11 insertions(+), 40 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f95ed71b246..3623520b353 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1148,6 +1148,8 @@ config ARCH_SUNXI
select DM_SPI_FLASH if SPI
select DM_KEYBOARD
select DM_MMC if MMC
+ select DM_REGULATOR
+ select DM_REGULATOR_FIXED
select DM_SCSI if SCSI
select DM_SERIAL
select GPIO_EXTRA_HEADER
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index dbe6005daab..5f95fe72d08 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -985,14 +985,6 @@ config VIDEO_LCD_TL059WV5C0
endchoice
-config SATAPWR
- string "SATA power pin"
- default ""
- help
- Set the pins used to power the SATA. This takes a string in the
- format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
- port H.
-
config GMAC_TX_DELAY
int "GMAC Transmit Clock Delay Chain"
default 0
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 21a2407e062..ec35a7f06bd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -229,20 +229,6 @@ int board_init(void)
return ret;
/* strcmp() would look better, but doesn't get optimised away. */
- if (CONFIG_SATAPWR[0]) {
- satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
- if (satapwr_pin >= 0) {
- gpio_request(satapwr_pin, "satapwr");
- gpio_direction_output(satapwr_pin, 1);
-
- /*
-* Give the attached SATA device time to power-up
-* to avoid link timeouts
-*/
- mdelay(500);
- }
- }
-
if (CONFIG_MACPWR[0]) {
macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
if (macpwr_pin >= 0) {
diff --git a/configs/A10-OLinuXino-Lime_defconfig
b/configs/A10-OLinuXino-Lime_defconfig
index ee92ac45fbc..f5d98607003 100644
--- a/configs/A10-OLinuXino-Lime_defconfig
+++ b/configs/A10-OLinuXino-Lime_defconfig
@@ -8,7 +8,6 @@ CONFIG_DRAM_EMR1=4
CONFIG_SYS_CLK_FREQ=91200
CONFIG_MMC0_CD_PIN="PH1"
CONFIG_I2C1_ENABLE=y
-CONFIG_SATAPWR="PC3"
CONFIG_AHCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
CONFIG_SYS_MONITOR_LEN=786432
diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig
b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
index 8ce10d6f75b..a8e949a3971 100644
--- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig
+++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig
@@ -9,7 +9,6 @@ CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_USB0_VBUS_PIN="PC17"
CONFIG_USB0_VBUS_DET="PH5"
CONFIG_I2C1_ENABLE=y
-CONFIG_SATAPWR="PC3"
CONFIG_SPL_SPI_SUNXI=y
CONFIG_AHCI=y
# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
diff --git a/configs/A20-OLinuXino-Lime2_defconfig
b/configs/A20-OLinuXino-Lime2_defconfig
index e38110b030b..c143cc17314 100644
--- a/config
[RFC PATCH 03/17] pinctrl: sunxi: remove struct sunxi_gpio
So far every Allwinner SoC used the same basic pincontroller/GPIO
register frame, and just differed by the number of implemented banks and
pins, plus some special functionality from time to time. However the D1
and successors use a slightly different pinctrl register layout.
Use that opportunity to drop "struct sunxi_gpio", that described that
MMIO frame in a C struct. That approach is somewhat frowned upon in the
Linux world and rarely used there, though still popular with U-Boot.
Switching from a C struct to a "base address plus offset" approach allows
to switch between the two models more dynamically, without reverting to
preprocessor macros and #ifdef's.
Model the pinctrl MMIO register frame in the usual "base address +
offset" way, and replace a hard-to-parse CPP macro with a more readable
static function.
All the users get converted over. There are no functional changes at
this point, it just prepares the stages for the D1 and friends.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/gpio.h | 63 +++---
arch/arm/mach-sunxi/pinmux.c | 51 +++--
drivers/gpio/sunxi_gpio.c | 15 +++---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 14 +++---
4 files changed, 68 insertions(+), 75 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 437e86479ce..8333810a69f 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -28,13 +28,6 @@
#define SUNXI_GPIO_H 7
#define SUNXI_GPIO_I 8
-/*
- * This defines the number of GPIO banks for the _main_ GPIO controller.
- * You should fix up the padding in struct sunxi_gpio_reg below if you
- * change this.
- */
-#define SUNXI_GPIO_BANKS 9
-
/*
* sun6i/sun8i and later SoCs have an additional GPIO controller (R_PIO)
* at a different register offset.
@@ -52,46 +45,42 @@
#define SUNXI_GPIO_M 12
#define SUNXI_GPIO_N 13
-struct sunxi_gpio {
- u32 cfg[4];
- u32 dat;
- u32 drv[2];
- u32 pull[2];
-};
-
-/* gpio interrupt control */
-struct sunxi_gpio_int {
- u32 cfg[3];
- u32 ctl;
- u32 sta;
- u32 deb;/* interrupt debounce */
-};
-
-struct sunxi_gpio_reg {
- struct sunxi_gpio gpio_bank[SUNXI_GPIO_BANKS];
- u8 res[0xbc];
- struct sunxi_gpio_int gpio_int;
-};
-
#define SUN50I_H6_GPIO_POW_MOD_SEL 0x340
#define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
-#define BANK_TO_GPIO(bank) (((bank) < SUNXI_GPIO_L) ? \
- &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
- &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) -
SUNXI_GPIO_L])
-
#define GPIO_BANK(pin) ((pin) >> 5)
#define GPIO_NUM(pin) ((pin) & 0x1f)
+#define GPIO_CFG_REG_OFFSET0x00
#define GPIO_CFG_INDEX(pin)(((pin) & 0x1f) >> 3)
#define GPIO_CFG_OFFSET(pin) pin) & 0x1f) & 0x7) << 2)
+#define GPIO_DAT_REG_OFFSET0x10
+
+#define GPIO_DRV_REG_OFFSET0x14
#define GPIO_DRV_INDEX(pin)(((pin) & 0x1f) >> 4)
#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
+#define GPIO_PULL_REG_OFFSET 0x1c
#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
#define GPIO_PULL_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
+#define SUNXI_PINCTRL_BANK_SIZE 0x24
+
+static inline void* BANK_TO_GPIO(int bank)
+{
+ void *pio_base;
+
+ if (bank < SUNXI_GPIO_L) {
+ pio_base = (void *)(uintptr_t)SUNXI_PIO_BASE;
+ } else {
+ pio_base = (void *)(uintptr_t)SUNXI_R_PIO_BASE;
+ bank -= SUNXI_GPIO_L;
+ }
+
+ return pio_base + bank * SUNXI_PINCTRL_BANK_SIZE;
+}
+
/* GPIO bank sizes */
#define SUNXI_GPIOS_PER_BANK 32
@@ -214,18 +203,18 @@ enum sunxi_gpio_number {
#define SUNXI_GPIO_AXP0_GPIO_COUNT 6
struct sunxi_gpio_plat {
- struct sunxi_gpio *regs;
+ void*regs;
charbank_name[3];
};
-void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val);
+void sunxi_gpio_set_cfgbank(void *bank_base, int pin_offset, u32 val);
void sunxi_gpio_set_cfgpin(u32 pin, u32 val);
-int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset);
+int sunxi_gpio_get_cfgbank(void *bank_base, int pin_offset);
int sunxi_gpio_get_cfgpin(u32 pin);
void sunxi_gpio_set_drv(u32 pin, u32 val);
-void sunxi_gpio_set_drv_bank(struct sunxi_gpio *pio, u32 bank_offset, u32 val);
+void sunxi_gpio_set_drv_bank(void *bank_base, u32 pin_offset, u32 val);
void sunxi_gpio_set_pull(u32 pin, u32 val);
-void sunxi_gpio_set_pull_bank(struct sunxi_gpio *pio, int bank_offset, u32
val);
+void sunxi_gpio_set_pull_bank(void *bank_base, int pin_offset, u32 val);
int sunxi_name_to_gpio(const char *name);
#if !defined CONFIG_SPL_BUILD && defined CONFIG_AXP_GPIO
diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
index c95fcee9f6c..b650f6b
[RFC PATCH 02/17] sunxi: remove CONFIG_MACPWR
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/Kconfig | 7 ---
board/sunxi/board.c | 10 --
configs/Bananapi_M2_Ultra_defconfig | 1 -
configs/Bananapi_defconfig| 1 -
configs/Bananapro_defconfig | 1 -
configs/Lamobo_R1_defconfig | 1 -
configs/Mele_A1000_defconfig | 1 -
configs/Orangepi_defconfig| 1 -
configs/Orangepi_mini_defconfig | 1 -
configs/bananapi_m1_plus_defconfig| 1 -
configs/bananapi_m2_plus_h3_defconfig | 1 -
configs/bananapi_m2_plus_h5_defconfig | 1 -
configs/i12-tvbox_defconfig | 1 -
configs/jesurun_q5_defconfig | 1 -
configs/mixtile_loftq_defconfig | 1 -
configs/nanopi_m1_plus_defconfig | 1 -
configs/nanopi_neo_plus2_defconfig| 1 -
configs/nanopi_r1s_h5_defconfig | 1 -
configs/orangepi_pc2_defconfig| 1 -
configs/orangepi_plus2e_defconfig | 1 -
configs/orangepi_plus_defconfig | 1 -
configs/orangepi_win_defconfig| 1 -
configs/pine_h64_defconfig| 1 -
configs/zeropi_defconfig | 1 -
drivers/net/sun8i_emac.c | 9 +++--
drivers/net/sunxi_emac.c | 10 --
26 files changed, 15 insertions(+), 43 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 5f95fe72d08..6220175d612 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -645,13 +645,6 @@ config OLD_SUNXI_KERNEL_COMPAT
Set this to enable various workarounds for old kernels, this results in
sub-optimal settings for newer kernels, only enable if needed.
-config MACPWR
- string "MAC power pin"
- default ""
- help
- Set the pin used to power the MAC. This takes a string in the format
- understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
-
config MMC0_CD_PIN
string "Card detect pin for mmc0"
default "PF6" if MACH_SUN8I_A83T || MACH_SUNXI_H3_H5 || MACH_SUN50I
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index ec35a7f06bd..3077cc71ebd 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -228,15 +228,6 @@ int board_init(void)
if (ret)
return ret;
- /* strcmp() would look better, but doesn't get optimised away. */
- if (CONFIG_MACPWR[0]) {
- macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
- if (macpwr_pin >= 0) {
- gpio_request(macpwr_pin, "macpwr");
- gpio_direction_output(macpwr_pin, 1);
- }
- }
-
#if CONFIG_IS_ENABLED(DM_I2C)
/*
* Temporary workaround for enabling I2C clocks until proper sunxi DM
@@ -244,7 +235,6 @@ int board_init(void)
*/
i2c_init_board();
#endif
-
eth_init_board();
return 0;
diff --git a/configs/Bananapi_M2_Ultra_defconfig
b/configs/Bananapi_M2_Ultra_defconfig
index 0bd163afdd7..1c4b90ab9d2 100644
--- a/configs/Bananapi_M2_Ultra_defconfig
+++ b/configs/Bananapi_M2_Ultra_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun8i-r40-bananapi-m2-ultra"
CONFIG_SPL=y
CONFIG_MACH_SUN8I_R40=y
CONFIG_DRAM_CLK=576
-CONFIG_MACPWR="PA17"
CONFIG_MMC0_CD_PIN="PH13"
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_USB1_VBUS_PIN="PH23"
diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig
index 2814d77c187..2a590e141d9 100644
--- a/configs/Bananapi_defconfig
+++ b/configs/Bananapi_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapi"
CONFIG_SPL=y
CONFIG_MACH_SUN7I=y
CONFIG_DRAM_CLK=432
-CONFIG_MACPWR="PH23"
CONFIG_VIDEO_COMPOSITE=y
CONFIG_GMAC_TX_DELAY=3
CONFIG_AHCI=y
diff --git a/configs/Bananapro_defconfig b/configs/Bananapro_defconfig
index 11375991c81..4b56195d4f2 100644
--- a/configs/Bananapro_defconfig
+++ b/configs/Bananapro_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapro"
CONFIG_SPL=y
CONFIG_MACH_SUN7I=y
CONFIG_DRAM_CLK=432
-CONFIG_MACPWR="PH23"
CONFIG_USB1_VBUS_PIN="PH0"
CONFIG_USB2_VBUS_PIN="PH1"
CONFIG_VIDEO_COMPOSITE=y
diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index d51601ff10f..fc63a7fbd46 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -4
[RFC PATCH 04/17] pinctrl: sunxi: add GPIO in/out wrappers
So far we were open-coding the pincontroller's GPIO output/input access
in each function using that.
Provide two functions that wrap that nicely, so users don't need to know
about the internals, and we can abstract the new D1 pinctrl more easily.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/gpio.h | 2 ++
arch/arm/mach-sunxi/pinmux.c | 10 ++
drivers/gpio/sunxi_gpio.c | 26 +-
3 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 8333810a69f..42ca03d8c18 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -211,6 +211,8 @@ void sunxi_gpio_set_cfgbank(void *bank_base, int
pin_offset, u32 val);
void sunxi_gpio_set_cfgpin(u32 pin, u32 val);
int sunxi_gpio_get_cfgbank(void *bank_base, int pin_offset);
int sunxi_gpio_get_cfgpin(u32 pin);
+void sunxi_gpio_set_output_bank(void *bank_base, u32 clear_mask, u32 set_mask);
+u32 sunxi_gpio_get_output_bank(void *bank_base);
void sunxi_gpio_set_drv(u32 pin, u32 val);
void sunxi_gpio_set_drv_bank(void *bank_base, u32 pin_offset, u32 val);
void sunxi_gpio_set_pull(u32 pin, u32 val);
diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
index b650f6b1aea..91acbf9269f 100644
--- a/arch/arm/mach-sunxi/pinmux.c
+++ b/arch/arm/mach-sunxi/pinmux.c
@@ -46,6 +46,16 @@ int sunxi_gpio_get_cfgpin(u32 pin)
return sunxi_gpio_get_cfgbank(bank_base, pin % 32);
}
+void sunxi_gpio_set_output_bank(void *bank_base, u32 clear_mask, u32 set_mask)
+{
+ clrsetbits_le32(bank_base + GPIO_DAT_REG_OFFSET, clear_mask, set_mask);
+}
+
+u32 sunxi_gpio_get_output_bank(void *bank_base)
+{
+ return readl(bank_base + GPIO_DAT_REG_OFFSET);
+}
+
void sunxi_gpio_set_drv(u32 pin, u32 val)
{
u32 bank = GPIO_BANK(pin);
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 1bf691a204a..767996c10fc 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -21,33 +21,22 @@
#if !CONFIG_IS_ENABLED(DM_GPIO)
static int sunxi_gpio_output(u32 pin, u32 val)
{
- u32 dat;
u32 bank = GPIO_BANK(pin);
u32 num = GPIO_NUM(pin);
void *pio = BANK_TO_GPIO(bank);
- dat = readl(pio + 0x10);
- if (val)
- dat |= 0x1 << num;
- else
- dat &= ~(0x1 << num);
-
- writel(dat, pio + 0x10);
-
+ sunxi_gpio_set_output_bank(pio, val ? 0 : 1U << num,
+ val ? 1U << num : 0);
return 0;
}
static int sunxi_gpio_input(u32 pin)
{
- u32 dat;
u32 bank = GPIO_BANK(pin);
u32 num = GPIO_NUM(pin);
void *pio = BANK_TO_GPIO(bank);
- dat = readl(pio + 0x10);
- dat >>= num;
-
- return dat & 0x1;
+ return (sunxi_gpio_get_output_bank(pio) >> num) & 0x1;
}
int gpio_request(unsigned gpio, const char *label)
@@ -136,12 +125,8 @@ static int sunxi_gpio_get_value(struct udevice *dev,
unsigned offset)
{
struct sunxi_gpio_plat *plat = dev_get_plat(dev);
u32 num = GPIO_NUM(offset);
- unsigned dat;
-
- dat = readl(plat->regs + GPIO_DAT_REG_OFFSET);
- dat >>= num;
- return dat & 0x1;
+ return (sunxi_gpio_get_output_bank(plat->regs) >> num) & 0x1;
}
static int sunxi_gpio_get_function(struct udevice *dev, unsigned offset)
@@ -181,8 +166,7 @@ static int sunxi_gpio_set_flags(struct udevice *dev,
unsigned int offset,
u32 value = !!(flags & GPIOD_IS_OUT_ACTIVE);
u32 num = GPIO_NUM(offset);
- clrsetbits_le32(plat->regs + GPIO_DAT_REG_OFFSET,
- 1 << num, value << num);
+ sunxi_gpio_set_output_bank(plat->regs, 1U << num, value << num);
sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_OUTPUT);
} else if (flags & GPIOD_IS_IN) {
u32 pull = 0;
--
2.35.5
[RFC PATCH 07/17] pinctrl: sunxi: add new D1 pinctrl support
For the first time since at least the Allwinner A10 SoCs, the D1 (and
related cores) use a new pincontroller MMIO register layout, so we
cannot use our hardcoded, fixed offsets anymore.
Ideally this would all be handled by devicetree and DM drivers, but for
the DT-less SPL we still need the legacy interfaces.
Add a new Kconfig symbol to differenciate between the two generations of
pincontrollers, and just use that to just switch some basic symbols.
The rest is already abstracted enough, so works out of the box.
Signed-off-by: Andre Przywara
---
arch/arm/mach-sunxi/Kconfig | 6 ++
include/sunxi_gpio.h| 26 +-
2 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 6220175d612..5e019948f85 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -113,6 +113,12 @@ config SUNXI_SRAM_ADDRESS
config SUNXI_A64_TIMER_ERRATUM
bool
+config SUNXI_NEW_PINCTRL
+ bool
+ ---help---
+ The Allwinner D1 and other new SoCs use a different register map
+ for the GPIO block, which we need to know about in the SPL.
+
# Note only one of these may be selected at a time! But hidden choices are
# not supported by Kconfig
config SUNXI_GEN_SUN4I
diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h
index 5ac476f960d..2f8b220f750 100644
--- a/include/sunxi_gpio.h
+++ b/include/sunxi_gpio.h
@@ -68,15 +68,32 @@
#define GPIO_DAT_REG_OFFSET0x10
#define GPIO_DRV_REG_OFFSET0x14
-#define GPIO_DRV_INDEX(pin)(((pin) & 0x1f) >> 4)
-#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
+
+/* Newer SoCs use a slightly different register layout */
+#ifdef CONFIG_SUNXI_NEW_PINCTRL
+/* pin drive strength: 4 bits per pin */
+#define GPIO_DRV_INDEX(pin)((pin) / 8)
+#define GPIO_DRV_OFFSET(pin) (((pin) % 8) * 4)
+
+#define GPIO_PULL_REG_OFFSET 0x24
+
+#define SUNXI_PINCTRL_BANK_SIZE0x30
+#define SUNXI_GPIO_DISABLE 0xf
+
+#else /* older generation pin controllers */
+/* pin drive strength: 2 bits per pin */
+#define GPIO_DRV_INDEX(pin)((pin) / 16)
+#define GPIO_DRV_OFFSET(pin) (((pin) % 16) * 2)
#define GPIO_PULL_REG_OFFSET 0x1c
+
+#define SUNXI_PINCTRL_BANK_SIZE0x24
+#define SUNXI_GPIO_DISABLE 0x7
+#endif
+
#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
#define GPIO_PULL_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
-#define SUNXI_PINCTRL_BANK_SIZE 0x24
-
static inline void* BANK_TO_GPIO(int bank)
{
void *pio_base;
@@ -132,7 +149,6 @@ enum sunxi_gpio_number {
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
#define SUNXI_GPIO_OUTPUT 1
-#define SUNXI_GPIO_DISABLE 7
#define SUN8I_H3_GPA_UART0 2
#define SUN8I_H3_GPA_UART2 2
--
2.35.5
[RFC PATCH 05/17] pinctrl: sunxi: move pinctrl code and remove GPIO_EXTRA_HEADER
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code to more easily include platform specific GPIO headers. This should not be needed in a DM world anymore, since the generic GPIO framework handles that nicely. For Allwinner boards we still need to deal with non-DM GPIO in the SPL, but this should become the exception, not the rule. Make this more obvious by removing the definition of GPIO_EXTRA_HEADER, and just force every legacy user of platform specific GPIO to include the new sunxi_gpio.h header explicitly. Everyone doing so should feel ashamed and should find a way to avoid it from now on. This also moves and renames the existing sunxi-specific low level pinctrl routines from arch/arm/mach-sunxi into board/sunxi, and the gpio.h header to the generic include/ directory, so the common code can be shared outside of arch/arm. Signed-off-by: Andre Przywara --- arch/arm/Kconfig | 1 - arch/arm/mach-sunxi/Makefile | 1 - arch/arm/mach-sunxi/board.c | 1 + arch/arm/mach-sunxi/dram_suniv.c | 2 +- arch/arm/mach-sunxi/spl_spi_sunxi.c | 1 + board/sunxi/Makefile | 1 + board/sunxi/board.c | 1 + board/sunxi/chip.c | 2 +- arch/arm/mach-sunxi/pinmux.c => board/sunxi/pinctrl.c| 5 - drivers/gpio/axp_gpio.c | 1 + drivers/gpio/sunxi_gpio.c| 1 + drivers/i2c/sun6i_p2wi.c | 2 +- drivers/i2c/sun8i_rsb.c | 2 +- drivers/mmc/sunxi_mmc.c | 1 + drivers/pinctrl/sunxi/pinctrl-sunxi.c| 1 + drivers/video/hitachi_tx18d42vm_lcd.c| 1 + drivers/video/ssd2828.c | 1 - drivers/video/sunxi/sunxi_display.c | 1 + drivers/video/sunxi/sunxi_lcd.c | 1 + .../include/asm/arch-sunxi/gpio.h => include/sunxi_gpio.h| 0 20 files changed, 19 insertions(+), 8 deletions(-) rename arch/arm/mach-sunxi/pinmux.c => board/sunxi/pinctrl.c (93%) rename arch/arm/include/asm/arch-sunxi/gpio.h => include/sunxi_gpio.h (100%) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3623520b353..c19b2c49359 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1152,7 +1152,6 @@ config ARCH_SUNXI select DM_REGULATOR_FIXED select DM_SCSI if SCSI select DM_SERIAL - select GPIO_EXTRA_HEADER select OF_BOARD_SETUP select OF_CONTROL select OF_SEPARATE diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile index 58f807cb82d..671211e9322 100644 --- a/arch/arm/mach-sunxi/Makefile +++ b/arch/arm/mach-sunxi/Makefile @@ -10,7 +10,6 @@ obj-y += board.o obj-y += clock.o obj-y += cpu_info.o obj-y += dram_helpers.o -obj-y += pinmux.o obj-$(CONFIG_SUN6I_PRCM) += prcm.o obj-$(CONFIG_AXP_PMIC_BUS) += pmic_bus.o obj-$(CONFIG_MACH_SUNIV) += clock_sun6i.o diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 86233637bfc..b6ffbff883c 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/arm/mach-sunxi/dram_suniv.c b/arch/arm/mach-sunxi/dram_suniv.c index 56c2d557ff1..fcc8dad2a2f 100644 --- a/arch/arm/mach-sunxi/dram_suniv.c +++ b/arch/arm/mach-sunxi/dram_suniv.c @@ -13,10 +13,10 @@ #include #include #include -#include #include #include #include +#include #define SDR_T_CAS (0x2) #define SDR_T_RAS (0x8) diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c b/arch/arm/mach-sunxi/spl_spi_sunxi.c index 81159cfee61..c2410dd7bb1 100644 --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef CONFIG_SPL_OS_BOOT #error CONFIG_SPL_OS_BOOT is not supported yet diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile index d96b7897b6c..7763b032c80 100644 --- a/board/sunxi/Makefile +++ b/board/sunxi/Makefile @@ -7,6 +7,7 @@ # (C) Copyright 2000-2003 # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-y += board.o +obj-y += pinctrl.o obj-$(CONFIG_SUN7I_GMAC) += gmac.o obj-$(CONFIG_MACH_SUN4I) += dram_sun4i_auto.o obj-$(CONFIG_MACH_SUN5I) += dram_sun5i_auto.o diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 3077cc71ebd..ef24413de4c 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -38,6 +38,7 @@ #include #endif #include +#include #include #include #include diff --git a/board/sunx
[RFC PATCH 06/17] pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h
On the Allwinner platform we were describing a quite comprehensive memory map in a per-SoC header unser arch/arm. In the old days that was used by every driver, but nowadays it should only be needed by SPL drivers (not using the DT). Many addresses in there were never used, and some are not needed anymore. To avoid a dependency on CPU specific headers in an arch specific directory, move the definition of the pinctroller MMIO base address into the sunxi_gpio.h header, because the SPL routines for GPIO should be the only one needing this address. This is a first step towards getting rid of cpu_sun[x]i.h completely, and allows to remove the inclusion of that file from the sunxi_gpio.h header. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 -- arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 2 -- arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 2 -- include/sunxi_gpio.h| 12 +++- 4 files changed, 11 insertions(+), 7 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h index f7ecc790dbf..d6fe51f24bc 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h @@ -91,7 +91,6 @@ #define SUNXI_CCM_BASE 0x01c2 #define SUNXI_INTC_BASE0x01c20400 -#define SUNXI_PIO_BASE 0x01c20800 #define SUNXI_TIMER_BASE 0x01c20c00 #ifndef CONFIG_SUNXI_GEN_SUN6I #define SUNXI_PWM_BASE 0x01c20e00 @@ -210,7 +209,6 @@ defined(CONFIG_MACH_SUN50I) #define SUNXI_R_TWI_BASE 0x01f02400 #define SUNXI_R_UART_BASE 0x01f02800 -#define SUNXI_R_PIO_BASE 0x01f02c00 #define SUN6I_P2WI_BASE0x01f03400 #define SUNXI_RSB_BASE 0x01f03400 diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h index d9cf8ae0428..9b6bf843601 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h @@ -22,7 +22,6 @@ #define SUNXI_SIDC_BASE0x03006000 #define SUNXI_SID_BASE 0x03006200 #define SUNXI_TIMER_BASE 0x03009000 -#define SUNXI_PIO_BASE 0x0300B000 #define SUNXI_PSI_BASE 0x0300C000 #define SUNXI_GIC400_BASE 0x0302 @@ -68,7 +67,6 @@ #define SUNXI_R_CPUCFG_BASE0x07000400 #define SUNXI_PRCM_BASE0x0701 #define SUNXI_R_WDOG_BASE 0x07020400 -#define SUNXI_R_PIO_BASE 0x07022000 #define SUNXI_R_UART_BASE 0x0708 #define SUNXI_R_TWI_BASE 0x07081400 diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h index 9c2d11b5901..20025be2319 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h @@ -81,7 +81,6 @@ /* APB0 Module */ #define SUNXI_CCM_BASE (REGS_APB0_BASE + 0x) #define SUNXI_CCMMODULE_BASE (REGS_APB0_BASE + 0x0400) -#define SUNXI_PIO_BASE (REGS_APB0_BASE + 0x0800) #define SUNXI_TIMER_BASE (REGS_APB0_BASE + 0x0C00) #define SUNXI_PWM_BASE (REGS_APB0_BASE + 0x1400) #define SUNXI_LRADC_BASE (REGS_APB0_BASE + 0x1800) @@ -102,7 +101,6 @@ /* RCPUS Module */ #define SUNXI_PRCM_BASE(REGS_RCPUS_BASE + 0x1400) #define SUNXI_R_UART_BASE (REGS_RCPUS_BASE + 0x2800) -#define SUNXI_R_PIO_BASE (REGS_RCPUS_BASE + 0x2c00) #define SUNXI_RSB_BASE (REGS_RCPUS_BASE + 0x3400) /* Misc. */ diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h index 42ca03d8c18..5ac476f960d 100644 --- a/include/sunxi_gpio.h +++ b/include/sunxi_gpio.h @@ -9,7 +9,17 @@ #define _SUNXI_GPIO_H #include -#include + +#if defined(CONFIG_MACH_SUN9I) +#define SUNXI_PIO_BASE 0x06000800 +#define SUNXI_R_PIO_BASE 0x08002c00 +#elif defined(CONFIG_SUN50I_GEN_H6) +#define SUNXI_PIO_BASE 0x0300b000 +#define SUNXI_R_PIO_BASE 0x07022000 +#else +#define SUNXI_PIO_BASE 0x01c20800 +#define SUNXI_R_PIO_BASE 0x01f02c00 +#endif /* * sunxi has 9 banks of gpio, they are: -- 2.35.5
[RFC PATCH 12/17] sunxi: clock: support D1/R528 PLL6 clock
The PLL_PERIPH0 clock changed a bit in the D1/R528/T113s SoCs: there is
new P0 divider at bits [18:16], and the M divider is 1.
Add code to support this version of "PLL6".
Signed-off-by: Andre Przywara
---
.../include/asm/arch-sunxi/clock_sun50i_h6.h | 2 ++
arch/arm/mach-sunxi/clock_sun50i_h6.c | 24 +--
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 9895c2c220e..8471e11aa02 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -249,6 +249,8 @@ struct sunxi_ccm_reg {
#define CCM_PLL6_CTRL_EN BIT(31)
#define CCM_PLL6_LOCK_EN BIT(29)
#define CCM_PLL6_LOCK BIT(28)
+#define CCM_PLL6_CTRL_P0_SHIFT 16
+#define CCM_PLL6_CTRL_P0_MASK (0x7 << CCM_PLL6_CTRL_P0_SHIFT)
#define CCM_PLL6_CTRL_N_SHIFT 8
#define CCM_PLL6_CTRL_N_MASK (0xff << CCM_PLL6_CTRL_N_SHIFT)
#define CCM_PLL6_CTRL_DIV1_SHIFT 0
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index 90110eab101..607efe6a9c1 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -107,16 +107,26 @@ unsigned int clock_get_pll6(void)
{
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
- int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
-
uint32_t rval = readl(&ccm->pll6_cfg);
int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
- int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
- CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
- CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
- /* The register defines PLL6-2X or PLL6-4X, not plain PLL6 */
- return 2400 / m * n / div1 / div2;
+ CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
+ int div1, m;
+
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)) {
+ div1 = ((rval & CCM_PLL6_CTRL_P0_MASK) >>
+ CCM_PLL6_CTRL_P0_SHIFT) + 1;
+ m = 1;
+ } else {
+ div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
+ CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
+ if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
+ m = 4;
+ else
+ m = 2;
+ }
+
+ return 2400U * n / m / div1 / div2;
}
int clock_twi_onoff(int port, int state)
--
2.35.5
[RFC PATCH 08/17] sunxi: introduce NCAT2 generation model
Allwinner seems to typically stick to a common MMIO memory map for several SoCs, but from time to time does some breaking changes, which also introduce new generations of some peripherals. The last time this happened with the H6, which apart from re-organising the base addresses also changed the clock controller significantly. We added a CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits. Now the Allwinner D1 changes the memory map again, and also extends the pincontroller, among other peripherals. To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol, this name is reportedly used in the Allwinner BSP code, and prevents us from inventing our own name. Add this new symbol to some guards that were already checking for the H6 generation, since many features are shared between the two (like the renovated clock controller). This paves the way to introduce a first user of this generation. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/clock.h | 2 +- arch/arm/include/asm/arch-sunxi/cpu.h | 2 + .../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 54 +++ arch/arm/include/asm/arch-sunxi/mmc.h | 2 +- arch/arm/include/asm/arch-sunxi/prcm.h| 2 +- arch/arm/include/asm/arch-sunxi/timer.h | 2 +- arch/arm/mach-sunxi/Kconfig | 14 - arch/arm/mach-sunxi/Makefile | 1 + arch/arm/mach-sunxi/board.c | 4 +- common/spl/Kconfig| 2 +- drivers/mmc/sunxi_mmc.c | 10 ++-- include/sunxi_gpio.h | 3 ++ 12 files changed, 86 insertions(+), 12 deletions(-) create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h diff --git a/arch/arm/include/asm/arch-sunxi/clock.h b/arch/arm/include/asm/arch-sunxi/clock.h index 2cfd5407423..3d34261b0e5 100644 --- a/arch/arm/include/asm/arch-sunxi/clock.h +++ b/arch/arm/include/asm/arch-sunxi/clock.h @@ -16,7 +16,7 @@ /* clock control module regs definition */ #if defined(CONFIG_MACH_SUN8I_A83T) #include -#elif defined(CONFIG_SUN50I_GEN_H6) +#elif defined(CONFIG_SUN50I_GEN_H6) || defined(CONFIG_SUNXI_GEN_NCAT2) #include #elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \ defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUNIV) diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h b/arch/arm/include/asm/arch-sunxi/cpu.h index b08f2023748..768c6572d6b 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu.h +++ b/arch/arm/include/asm/arch-sunxi/cpu.h @@ -10,6 +10,8 @@ #include #elif defined(CONFIG_SUN50I_GEN_H6) #include +#elif defined(CONFIG_SUNXI_GEN_NCAT2) +#include #else #include #endif diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h b/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h new file mode 100644 index 000..13093085a5e --- /dev/null +++ b/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h @@ -0,0 +1,54 @@ +/* + * (C) Copyright 2022 Arm Limited + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#ifndef _SUNXI_CPU_SUNXI_NCAT2_H +#define _SUNXI_CPU_SUNXI_NCAT2_H + +#define SUNXI_SRAM_A1_BASE CONFIG_SUNXI_SRAM_ADDRESS +#define SUNXI_SRAM_C_BASE 0x00028000 +#define SUNXI_SRAM_A2_BASE 0x0010 + +#define SUNXI_SRAMC_BASE 0x0280 +#define SUNXI_CCM_BASE 0x02001000 +/* SID address space starts at 0x03006000, but e-fuse is at offset 0x200 */ +#define SUNXI_SIDC_BASE0x03006000 +#define SUNXI_SID_BASE 0x03006200 +#define SUNXI_TIMER_BASE 0x0205 + +#ifdef CONFIG_MACH_SUN50I_H6 +#define SUNXI_DRAM_COM_BASE0x04002000 +#define SUNXI_DRAM_CTL0_BASE 0x04003000 +#define SUNXI_DRAM_PHY0_BASE 0x04005000 +#endif +#define SUNXI_MMC0_BASE0x0402 +#define SUNXI_MMC1_BASE0x04021000 +#define SUNXI_MMC2_BASE0x04022000 + +#define SUNXI_UART0_BASE 0x0250 +#define SUNXI_UART1_BASE 0x02500400 +#define SUNXI_UART2_BASE 0x02500800 +#define SUNXI_UART3_BASE 0x02500C00 +#define SUNXI_TWI0_BASE0x02502000 +#define SUNXI_TWI1_BASE0x02502400 +#define SUNXI_TWI2_BASE0x02502800 +#define SUNXI_TWI3_BASE0x02502C00 +#define SUNXI_SPI0_BASE0x04025000 +#define SUNXI_SPI1_BASE0x04026000 + +#define SUNXI_RTC_BASE 0x0700 +#define SUNXI_R_CPUCFG_BASE0x07000400 +#define SUNXI_PRCM_BASE0x0701 +#define SUNXI_R_WDOG_BASE 0x07020400 +#define SUNXI_R_UART_BASE 0x0708 +#define SUNXI_R_TWI_BASE 0x07081400 + +#ifndef __ASSEMBLY__ +void sunxi_board_init(void); +void sunxi_reset(void); +int sunxi_g
[RFC PATCH 09/17] pinctrl: sunxi: add Allwinner D1 pinctrl description
Apart from using the new pinctrl MMIO register layout, the Allwinner D1
and related SoCs still need to usual set of mux values hardcoded in
U-Boot's pinctrl driver.
Add the values we need so far to this list, so that DM based drivers
will just work without further ado.
Signed-off-by: Andre Przywara
---
drivers/pinctrl/sunxi/Kconfig | 4
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 28 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 77da90836b6..c8f937d91e9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -124,4 +124,8 @@ config PINCTRL_SUN50I_H616_R
default MACH_SUN50I_H616
select PINCTRL_SUNXI
+config PINCTRL_SUN20I_D1
+ bool "Support for the Allwinner D1/R528 PIO"
+ select PINCTRL_SUNXI
+
endif
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 8c12febcc0d..83720cea747 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -728,6 +728,28 @@ static const struct sunxi_pinctrl_desc __maybe_unused
sun50i_h616_r_pinctrl_desc
.num_banks = 1,
};
+static const struct sunxi_pinctrl_function sun20i_d1_pinctrl_functions[] = {
+ { "emac", 8 },/* PE0-PE15 */
+ { "gpio_in",0 },
+ { "gpio_out", 1 },
+ { "mmc0", 2 },/* PF0-PF5 */
+ { "mmc2", 3 },/* PC1-PC7 */
+ { "spi0", 2 },/* PC2-PC7 */
+#if IS_ENABLED(CONFIG_UART0_PORT_F)
+ { "uart0", 3 },/* PF2-PF4 */
+#else
+ { "uart0", 6 },/* PB2-PB3 */
+#endif
+ { "uart3", 3 },/* PB6-PB9 */
+};
+
+static const struct sunxi_pinctrl_desc __maybe_unused sun20i_d1_pinctrl_desc =
{
+ .functions = sun20i_d1_pinctrl_functions,
+ .num_functions = ARRAY_SIZE(sun20i_d1_pinctrl_functions),
+ .first_bank = SUNXI_GPIO_A,
+ .num_banks = 7,
+};
+
static const struct udevice_id sunxi_pinctrl_ids[] = {
#ifdef CONFIG_PINCTRL_SUNIV_F1C100S
{
@@ -884,6 +906,12 @@ static const struct udevice_id sunxi_pinctrl_ids[] = {
.compatible = "allwinner,sun50i-h616-r-pinctrl",
.data = (ulong)&sun50i_h616_r_pinctrl_desc,
},
+#endif
+#ifdef CONFIG_PINCTRL_SUN20I_D1
+ {
+ .compatible = "allwinner,sun20i-d1-pinctrl",
+ .data = (ulong)&sun20i_d1_pinctrl_desc,
+ },
#endif
{}
};
--
2.35.5
[RFC PATCH 11/17] sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup
The D1/R528/T113s SoCs introduce a new "LDO enable" bit in the CPUX_PLL.
Just enable that when we program that PLL.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 1 +
arch/arm/mach-sunxi/clock_sun50i_h6.c | 12 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 37df4410eaa..9895c2c220e 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -228,6 +228,7 @@ struct sunxi_ccm_reg {
/* pll1 bit field */
#define CCM_PLL1_CTRL_EN BIT(31)
+#define CCM_PLL1_LDO_ENBIT(30)
#define CCM_PLL1_LOCK_EN BIT(29)
#define CCM_PLL1_LOCK BIT(28)
#define CCM_PLL1_OUT_ENBIT(27)
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index 7926394cf76..90110eab101 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -86,11 +86,13 @@ void clock_set_pll1(unsigned int clk)
writel(val, &ccm->cpu_axi_cfg);
/* clk = 24*n/p, p is ignored if clock is >288MHz */
- writel(CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2 |
-#ifdef CONFIG_MACH_SUN50I_H616
- CCM_PLL1_OUT_EN |
-#endif
- CCM_PLL1_CTRL_N(clk / 2400), &ccm->pll1_cfg);
+ val = CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2;
+ val |= CCM_PLL1_CTRL_N(clk / 2400);
+ if (IS_ENABLED(CONFIG_MACH_SUN50I_H616))
+ val |= CCM_PLL1_OUT_EN;
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2))
+ val |= CCM_PLL1_OUT_EN | CCM_PLL1_LDO_EN;
+ writel(val, &ccm->pll1_cfg);
while (!(readl(&ccm->pll1_cfg) & CCM_PLL1_LOCK)) {}
/* Switch CPU to PLL1 */
--
2.35.5
[RFC PATCH 10/17] clk: sunxi: Add support for the D1 CCU
From: Samuel Holland
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Signed-off-by: Samuel Holland
Reviewed-by: Andre Przywara
Acked-by: Sean Anderson
---
drivers/clk/sunxi/Kconfig | 6 +
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk_d1.c| 101 ++
include/dt-bindings/clock/sun20i-d1-ccu.h | 156 ++
include/dt-bindings/reset/sun20i-d1-ccu.h | 77 +++
5 files changed, 341 insertions(+)
create mode 100644 drivers/clk/sunxi/clk_d1.c
create mode 100644 include/dt-bindings/clock/sun20i-d1-ccu.h
create mode 100644 include/dt-bindings/reset/sun20i-d1-ccu.h
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf11fad6eef..f65e482ba4c 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -87,6 +87,12 @@ config CLK_SUN8I_H3
This enables common clock driver support for platforms based
on Allwinner H3/H5 SoC.
+config CLK_SUN20I_D1
+ bool "Clock driver for Allwinner D1"
+ help
+ This enables common clock driver support for platforms based
+ on Allwinner D1 SoC.
+
config CLK_SUN50I_H6
bool "Clock driver for Allwinner H6"
default MACH_SUN50I_H6
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 895da02ebea..90a277489dc 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
+obj-$(CONFIG_CLK_SUN20I_D1) += clk_d1.o
obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
obj-$(CONFIG_CLK_SUN50I_H6_R) += clk_h6_r.o
obj-$(CONFIG_CLK_SUN50I_H616) += clk_h616.o
diff --git a/drivers/clk/sunxi/clk_d1.c b/drivers/clk/sunxi/clk_d1.c
new file mode 100644
index 000..9412b77a542
--- /dev/null
+++ b/drivers/clk/sunxi/clk_d1.c
@@ -0,0 +1,101 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2021 Samuel Holland
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct ccu_clk_gate d1_gates[] = {
+ [CLK_BUS_MMC0] = GATE(0x84c, BIT(0)),
+ [CLK_BUS_MMC1] = GATE(0x84c, BIT(1)),
+ [CLK_BUS_MMC2] = GATE(0x84c, BIT(2)),
+ [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
+ [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
+ [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
+ [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
+ [CLK_BUS_UART4] = GATE(0x90c, BIT(4)),
+ [CLK_BUS_UART5] = GATE(0x90c, BIT(5)),
+ [CLK_BUS_I2C0] = GATE(0x91c, BIT(0)),
+ [CLK_BUS_I2C1] = GATE(0x91c, BIT(1)),
+ [CLK_BUS_I2C2] = GATE(0x91c, BIT(2)),
+ [CLK_BUS_I2C3] = GATE(0x91c, BIT(3)),
+ [CLK_SPI0] = GATE(0x940, BIT(31)),
+ [CLK_SPI1] = GATE(0x944, BIT(31)),
+ [CLK_BUS_SPI0] = GATE(0x96c, BIT(0)),
+ [CLK_BUS_SPI1] = GATE(0x96c, BIT(1)),
+
+ [CLK_BUS_EMAC] = GATE(0x97c, BIT(0)),
+
+ [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
+ [CLK_USB_OHCI1] = GATE(0xa74, BIT(31)),
+ [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
+ [CLK_BUS_OHCI1] = GATE(0xa8c, BIT(1)),
+ [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
+ [CLK_BUS_EHCI1] = GATE(0xa8c, BIT(5)),
+ [CLK_BUS_OTG] = GATE(0xa8c, BIT(8)),
+ [CLK_BUS_LRADC] = GATE(0xa9c, BIT(0)),
+
+ [CLK_RISCV] = GATE(0xd04, BIT(31)),
+};
+
+static struct ccu_reset d1_resets[] = {
+ [RST_BUS_MMC0] = RESET(0x84c, BIT(16)),
+ [RST_BUS_MMC1] = RESET(0x84c, BIT(17)),
+ [RST_BUS_MMC2] = RESET(0x84c, BIT(18)),
+ [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
+ [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
+ [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
+ [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
+ [RST_BUS_UART4] = RESET(0x90c, BIT(20)),
+ [RST_BUS_UART5] = RESET(0x90c, BIT(21)),
+ [RST_BUS_I2C0] = RESET(0x91c, BIT(16)),
+ [RST_BUS_I2C1] = RESET(0x91c, BIT(17)),
+ [RST_BUS_I2C2] = RESET(0x91c, BIT(18)),
+ [RST_BUS_I2C3] = RESET(0x91c, BIT(19)),
+ [RST_BUS_SPI0] = RESET(0x96c, BIT(16)),
+ [RST_BUS_SPI1] = RESET(0x96c, BIT(17)),
+
+ [RST_BUS_EMAC] = RESET(0x97c, BIT(16)),
+
+ [RST_USB_PHY0] = RESET(0xa70, BIT(30)),
+ [RST_USB_PHY1] = RESET(0xa74, BIT(30)),
+ [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
+ [RST_BUS_OHCI1] = RESET(0xa8c, BIT(17)),
+ [RST_BUS_EHCI0]
[RFC PATCH 13/17] sunxi: add early Allwinner R528/T113 SoC support
This adds the remaining code bits to teach U-Boot about Allwinner's
newest SoC generation. This was introduced with the RISC-V based
Allwinner D1 SoC, which actually shares a die with the ARM cores versions
called R528 (BGA, without DRAM) and T113s (QFP, with embedded DRAM).
This adds the new Kconfig stanza, using the two newly introduced symbols
for the new SoC generation and pincontroller. It also adds the new symbols
to the relavent code places, to set all the hardcoded bits directly.
We just chicken out the DRAM controller code for now with a stub to make
it compile. There is GPLed code out there that can be used, although that
still looks very much like the disassembly/decompile it came from.
Signed-off-by: Andre Przywara
---
.../arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 5 +
arch/arm/mach-sunxi/Kconfig | 16
arch/arm/mach-sunxi/board.c | 4
arch/arm/mach-sunxi/clock_sun50i_h6.c| 2 ++
arch/arm/mach-sunxi/cpu_info.c | 2 ++
board/sunxi/Makefile | 1 +
board/sunxi/dram_sun8i_r528.c| 9 +
drivers/mmc/sunxi_mmc.c | 1 +
drivers/pinctrl/sunxi/Kconfig| 1 +
9 files changed, 41 insertions(+)
create mode 100644 board/sunxi/dram_sun8i_r528.c
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 8471e11aa02..d34a9baf5e1 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -288,6 +288,11 @@ struct sunxi_ccm_reg {
/* apb1 bit field */
#define CCM_APB1_DEFAULT 0x03000102
+#elif CONFIG_MACH_SUN8I_R528
+#define CCM_PLL6_DEFAULT 0xe8216300
+#define CCM_PSI_AHB1_AHB2_DEFAULT 0x0302
+//#define CCM_AHB3_DEFAULT 0x0302
+#define CCM_APB1_DEFAULT 0x03000102
#endif
/* apb2 bit field */
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index b59db212fa8..71799686a05 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -51,6 +51,12 @@ config DRAM_SUN50I_H616
Select this dram controller driver for some sun50i platforms,
like H616.
+config DRAM_SUN8I_R528
+ bool
+ help
+ Select this DRAM controller driver for the R528, T113, D1
+ and D1s/F133 SoC.
+
if DRAM_SUN50I_H616
config DRAM_SUN50I_H616_WRITE_LEVELING
bool "H616 DRAM write leveling"
@@ -318,6 +324,15 @@ config MACH_SUN8I_R40
select PHY_SUN4I_USB
imply SPL_SYS_I2C_LEGACY
+config MACH_SUN8I_R528
+ bool "sun8i (Allwinner R528)"
+ select CPU_V7A
+ select SUNXI_GEN_NCAT2
+ select SUNXI_NEW_PINCTRL
+ select MMC_SUNXI_HAS_NEW_MODE
+ select SUPPORT_SPL
+ select DRAM_SUN8I_R528
+
config MACH_SUN8I_V3S
bool "sun8i (Allwinner V3/V3s/S3/S3L)"
select CPU_V7A
@@ -622,6 +637,7 @@ config SYS_CONFIG_NAME
default "sun6i" if MACH_SUN6I
default "sun7i" if MACH_SUN7I
default "sun8i" if MACH_SUN8I
+ default "sun8i" if MACH_SUN8I_R528
default "sun9i" if MACH_SUN9I
default "sun50i" if MACH_SUN50I
default "sun50i" if MACH_SUN50I_H6
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index 3763ec3d2e4..1cda5e2 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -148,6 +148,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_R528)
+ sunxi_gpio_set_cfgpin(SUNXI_GPE(2), 6);
+ sunxi_gpio_set_cfgpin(SUNXI_GPE(3), 6);
+ sunxi_gpio_set_pull(SUNXI_GPE(3), SUNXI_GPIO_PULL_UP);
#elif CONFIG_CONS_INDEX == 2 && defined(CONFIG_MACH_SUNIV)
sunxi_gpio_set_cfgpin(SUNXI_GPA(2), SUNIV_GPE_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPA(3), SUNIV_GPE_UART0);
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index 607efe6a9c1..4d5e23a9af4 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -38,7 +38,9 @@ void clock_init_safe(void)
CCM_CPU_AXI_DEFAULT_FACTORS);
writel(CCM_PSI_AHB1_AHB2_DEFAULT, &ccm->psi_ahb1_ahb2_cfg);
+#ifdef CCM_AHB3_DEFAULT
writel(CCM_AHB3_DEFAULT, &ccm->ahb3_cfg);
+#endif
writel(CCM_APB1_DEFAULT, &ccm->apb1_cfg);
/*
diff --git a/arch/arm/mach-sunxi/cpu_info.c b/arch/arm/mach-sunxi/cpu_info.c
index 7eef178859b..7fecc3b88dd 100644
--- a/arch/arm/mach-sunxi/cpu_info.c
+++ b/arch/arm/mach-sunxi/cpu_info.c
@@ -93,6 +93,8 @@ int print_cpuinfo(void)
printf("CPU: Allwinner R40 (SUN8I %04x)\n",
[RFC PATCH 14/17] sunxi: refactor serial base addresses to avoid asm/arch/cpu.h
At the moment we have each SoC's memory map defined in its own cpu.h,
which is included in include/configs/sunxi_common.h. This will be a
problem with the introduction of Allwinner RISC-V support.
Remove the inclusion of that header file from the common config header,
instead move the required serial base addresses (for the SPL) into a
separate header file. Then include the original cpu.h file only where
we really need it, which is only under arch/arm now.
This disentangles the architecture specific header files from the
generic code.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/sram.c | 1 +
arch/arm/cpu/armv8/fel_utils.S| 1 +
arch/arm/include/asm/arch-sunxi/clock.h | 1 +
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 15 -
.../include/asm/arch-sunxi/cpu_sun50i_h6.h| 5 ---
arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 7
.../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 5 ---
arch/arm/include/asm/arch-sunxi/serial.h | 32 +++
arch/arm/mach-sunxi/gtbus_sun9i.c | 1 +
arch/arm/mach-sunxi/timer.c | 1 +
include/configs/sunxi-common.h| 2 +-
11 files changed, 38 insertions(+), 33 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/serial.h
diff --git a/arch/arm/cpu/armv7/sunxi/sram.c b/arch/arm/cpu/armv7/sunxi/sram.c
index 28564c2846a..28ff6a1b7c2 100644
--- a/arch/arm/cpu/armv7/sunxi/sram.c
+++ b/arch/arm/cpu/armv7/sunxi/sram.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
void sunxi_sram_init(void)
{
diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
index 5266515f145..9b1d55bb31a 100644
--- a/arch/arm/cpu/armv8/fel_utils.S
+++ b/arch/arm/cpu/armv8/fel_utils.S
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/*
* We don't overwrite save_boot_params() here, to save the FEL state upon
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 3d34261b0e5..fcc8966cb0b 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -9,6 +9,7 @@
#define _SUNXI_CLOCK_H
#include
+#include
#define CLK_GATE_OPEN 0x1
#define CLK_GATE_CLOSE 0x0
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index d6fe51f24bc..3daee2f574a 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -128,20 +128,6 @@ defined(CONFIG_MACH_SUN50I)
#define SUNXI_CPUCFG_BASE 0x01c25c00
#endif
-#ifdef CONFIG_MACH_SUNIV
-#define SUNXI_UART0_BASE 0x01c25000
-#define SUNXI_UART1_BASE 0x01c25400
-#define SUNXI_UART2_BASE 0x01c25800
-#else
-#define SUNXI_UART0_BASE 0x01c28000
-#define SUNXI_UART1_BASE 0x01c28400
-#define SUNXI_UART2_BASE 0x01c28800
-#endif
-#define SUNXI_UART3_BASE 0x01c28c00
-#define SUNXI_UART4_BASE 0x01c29000
-#define SUNXI_UART5_BASE 0x01c29400
-#define SUNXI_UART6_BASE 0x01c29800
-#define SUNXI_UART7_BASE 0x01c29c00
#define SUNXI_PS2_0_BASE 0x01c2a000
#define SUNXI_PS2_1_BASE 0x01c2a400
@@ -208,7 +194,6 @@ defined(CONFIG_MACH_SUN50I)
#endif
#define SUNXI_R_TWI_BASE 0x01f02400
-#define SUNXI_R_UART_BASE 0x01f02800
#define SUN6I_P2WI_BASE0x01f03400
#define SUNXI_RSB_BASE 0x01f03400
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
index 9b6bf843601..15ee092d358 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
@@ -42,10 +42,6 @@
#define SUNXI_DRAM_PHY0_BASE 0x0480
#endif
-#define SUNXI_UART0_BASE 0x0500
-#define SUNXI_UART1_BASE 0x05000400
-#define SUNXI_UART2_BASE 0x05000800
-#define SUNXI_UART3_BASE 0x05000C00
#define SUNXI_TWI0_BASE0x05002000
#define SUNXI_TWI1_BASE0x05002400
#define SUNXI_TWI2_BASE0x05002800
@@ -67,7 +63,6 @@
#define SUNXI_R_CPUCFG_BASE0x07000400
#define SUNXI_PRCM_BASE0x0701
#define SUNXI_R_WDOG_BASE 0x07020400
-#define SUNXI_R_UART_BASE 0x0708
#define SUNXI_R_TWI_BASE 0x07081400
#ifndef __ASSEMBLY__
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
index 20025be2319..2bf2675d5c1 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h
@@ -86,12 +86,6 @@
#define SUNXI_LRADC_BASE (REGS_APB0_BASE + 0x18
[RFC PATCH 16/17] arm: sunxi: add Allwinner T113s devicetree stub
This adds the basic SoC .dtsi devicetree stub for the Allwinner T113s
SoC. This shares a die with the Allwinner D1 SoC (with RISC-V cores),
but uses two Cortex-A7 cores instead of the T-HEAD C906 RISC-V core.
Include the existing D1 devicetree stub, but add the ARM specific nodes,
like for the CPU, the arch timer and the GIC.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sun8i-t113s.dtsi | 59 +++
1 file changed, 59 insertions(+)
create mode 100644 arch/arm/dts/sun8i-t113s.dtsi
diff --git a/arch/arm/dts/sun8i-t113s.dtsi b/arch/arm/dts/sun8i-t113s.dtsi
new file mode 100644
index 000..0919ce559f6
--- /dev/null
+++ b/arch/arm/dts/sun8i-t113s.dtsi
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// Copyright (C) 2022 Arm Ltd.
+
+#define SOC_PERIPHERAL_IRQ(nr) GIC_SPI nr
+
+#include
+#include <../../riscv/dts/sunxi-d1s-t113.dtsi>
+#include <../../riscv/dts/sunxi-d1-t113.dtsi>
+
+/ {
+ interrupt-parent = <&gic>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
+ };
+
+ cpu1: cpu@1 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <1>;
+ clocks = <&ccu CLK_CPUX>;
+ clock-names = "cpu";
+ };
+ };
+
+ gic: interrupt-controller@1c81000 {
+ compatible = "arm,gic-400";
+ reg = <0x03021000 0x1000>,
+ <0x03022000 0x2000>,
+ <0x03024000 0x2000>,
+ <0x03026000 0x2000>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = ,
+;
+ interrupt-affinity = <&cpu0>, <&cpu1>;
+ };
+};
--
2.35.5
[RFC PATCH 15/17] riscv: dts: allwinner: Add the D1/D1s SoC devicetree
From: Samuel Holland
D1 (aka D1-H), D1s (aka F133), R528, and T113 are a family of SoCs based
on a single die, or at a pair of dies derived from the same design.
D1 and D1s contain a single T-HEAD Xuantie C906 CPU, whereas R528 and
T113 contain a pair of Cortex-A7's. D1 and R528 are the full version of
the chip with a BGA package, whereas D1s and T113 are low-pin-count QFP
variants.
Because the original design supported both ARM and RISC-V CPUs, some
peripherals are duplicated. In addition, all variants except D1s contain
a HiFi 4 DSP with its own set of peripherals.
The devicetrees are organized to minimize duplication:
- Common perhiperals are described in sunxi-d1s-t113.dtsi
- DSP-related peripherals are described in sunxi-d1-t113.dtsi
- RISC-V specific hardware is described in sun20i-d1s.dtsi
- Functionality unique to the D1 variant is described in sun20i-d1.dtsi
The SOC_PERIPHERAL_IRQ macro handles the different #interrupt-cells
values between the ARM (GIC) and RISC-V (PLIC) versions of the SoC.
Signed-off-by: Samuel Holland
---
arch/riscv/dts/sun20i-d1.dtsi | 66 ++
arch/riscv/dts/sun20i-d1s.dtsi | 76 ++
arch/riscv/dts/sunxi-d1-t113.dtsi | 15 +
arch/riscv/dts/sunxi-d1s-t113.dtsi | 844
include/dt-bindings/clock/sun20i-d1-r-ccu.h | 19 +
include/dt-bindings/reset/sun20i-d1-r-ccu.h | 16 +
6 files changed, 1036 insertions(+)
create mode 100644 arch/riscv/dts/sun20i-d1.dtsi
create mode 100644 arch/riscv/dts/sun20i-d1s.dtsi
create mode 100644 arch/riscv/dts/sunxi-d1-t113.dtsi
create mode 100644 arch/riscv/dts/sunxi-d1s-t113.dtsi
create mode 100644 include/dt-bindings/clock/sun20i-d1-r-ccu.h
create mode 100644 include/dt-bindings/reset/sun20i-d1-r-ccu.h
diff --git a/arch/riscv/dts/sun20i-d1.dtsi b/arch/riscv/dts/sun20i-d1.dtsi
new file mode 100644
index 000..97e7cbb3259
--- /dev/null
+++ b/arch/riscv/dts/sun20i-d1.dtsi
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// Copyright (C) 2021-2022 Samuel Holland
+
+#include "sun20i-d1s.dtsi"
+#include "sunxi-d1-t113.dtsi"
+
+/ {
+ soc {
+ lradc: keys@2009800 {
+ compatible = "allwinner,sun20i-d1-lradc",
+"allwinner,sun50i-r329-lradc";
+ reg = <0x2009800 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_LRADC>;
+ resets = <&ccu RST_BUS_LRADC>;
+ status = "disabled";
+ };
+
+ i2s0: i2s@2032000 {
+ compatible = "allwinner,sun20i-d1-i2s",
+"allwinner,sun50i-r329-i2s";
+ reg = <0x2032000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_I2S0>,
+<&ccu CLK_I2S0>;
+ clock-names = "apb", "mod";
+ resets = <&ccu RST_BUS_I2S0>;
+ dmas = <&dma 3>, <&dma 3>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ #sound-dai-cells = <0>;
+ };
+ };
+};
+
+&pio {
+ /omit-if-no-ref/
+ dmic_pb11_d0_pin: dmic-pb11-d0-pin {
+ pins = "PB11";
+ function = "dmic";
+ };
+
+ /omit-if-no-ref/
+ dmic_pe17_clk_pin: dmic-pe17-clk-pin {
+ pins = "PE17";
+ function = "dmic";
+ };
+
+ /omit-if-no-ref/
+ i2c0_pb10_pins: i2c0-pb10-pins {
+ pins = "PB10", "PB11";
+ function = "i2c0";
+ };
+
+ /omit-if-no-ref/
+ i2c2_pb0_pins: i2c2-pb0-pins {
+ pins = "PB0", "PB1";
+ function = "i2c2";
+ };
+
+ /omit-if-no-ref/
+ uart0_pb8_pins: uart0-pb8-pins {
+ pins = "PB8", "PB9";
+ function = "uart0";
+ };
+};
diff --git a/arch/riscv/dts/sun20i-d1s.dtsi b/arch/riscv/dts/sun20i-d1s.dtsi
new file mode 100644
index 000..859509832d5
--- /dev/null
+++ b/arch/riscv/dts/sun20i-d1s.dtsi
@@ -0,0 +1,76 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// Copyright (C) 2021-2022 Samuel Holland
+
+#define SOC_PERIPHERAL_IRQ(nr) (nr + 16)
+
+#include "sunxi-d1s-t113.dtsi"
+
+/ {
+ cpus {
+ timebase-frequency = <2400>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ compatible = "thead,c906", "riscv";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&ccu CLK_RISCV>;
+ d-cache-block-size = <64>;
+ d-cache-sets = <256>;
+ d-cache-size = <32768>;
+ i-cache-block-size = <64>;
+ i-cache-s
[RFC PATCH 17/17] sunxi: add preliminary MangoPi MQ-R board support
This includes a preliminary basic DT and a defconfig to get the board
booted. Although there is some DRAM code based on some disassembly, it
is not ready yet, so the SPL doesn't really work, and needs some help
from awboot.
Signed-off-by: Andre Przywara
---
arch/arm/dts/Makefile | 2 +
arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts | 54 +++
configs/mangopi_mq_r_defconfig| 12 +
3 files changed, 68 insertions(+)
create mode 100644 arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts
create mode 100644 configs/mangopi_mq_r_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 43951a7731e..602349b88ab 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -694,6 +694,8 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-s3-pinecube.dtb \
sun8i-v3-sl631-imx179.dtb \
sun8i-v3s-licheepi-zero.dtb
+dtb-$(CONFIG_MACH_SUN8I_R528) += \
+ sun8i-t113s-mangopi-mq-r.dtb
dtb-$(CONFIG_MACH_SUN50I_H5) += \
sun50i-h5-bananapi-m2-plus.dtb \
sun50i-h5-emlid-neutis-n5-devboard.dtb \
diff --git a/arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts
b/arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts
new file mode 100644
index 000..1fa0c46b7dc
--- /dev/null
+++ b/arch/arm/dts/sun8i-t113s-mangopi-mq-r.dts
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+// Copyright (C) 2022 Arm Ltd.
+
+/dts-v1/;
+
+#include "sun8i-t113s.dtsi"
+#include
+
+/ {
+ model = "Mangopi MQ-R";
+ compatible = "mangopi,mq-r", "allwinner,sun8i-t113s";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&dcxo {
+ clock-frequency = <2400>;
+};
+
+&mmc0 {
+ pinctrl-0 = <&mmc0_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <®_3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pe_pins>;
+ status = "okay";
+};
+
+&pio {
+ uart0_pe_pins: uart0-pe-pins {
+ pins = "PE2", "PE3";
+ function = "uart0";
+ };
+};
diff --git a/configs/mangopi_mq_r_defconfig b/configs/mangopi_mq_r_defconfig
new file mode 100644
index 000..32b1449dc92
--- /dev/null
+++ b/configs/mangopi_mq_r_defconfig
@@ -0,0 +1,12 @@
+CONFIG_ARM=y
+CONFIG_ARCH_SUNXI=y
+CONFIG_DEFAULT_DEVICE_TREE="sun8i-t113s-mangopi-mq-r"
+CONFIG_SUNXI_MINIMUM_DRAM_MB=128
+CONFIG_SPL=y
+CONFIG_MACH_SUN8I_R528=y
+CONFIG_MMC0_CD_PIN="PF6"
+# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set
+CONFIG_SYS_MONITOR_LEN=786432
+# dummy values
+CONFIG_DRAM_CLK=600
+CONFIG_DRAM_ZQ=0
--
2.35.5
Re: [v1] spl: nand: allow partial nand page reads during nand_spl_load_image
On Tue, Nov 29, 2022 at 10:00:19AM +0100, Dario Binacchi wrote:
> Hi Colinn
>
> On Fri, Nov 18, 2022 at 1:08 PM Dario Binacchi
> wrote:
> >
> > Hi Colin,
> >
> > On Tue, Nov 15, 2022 at 5:35 PM Colin Foster
> > wrote:
> > >
> > > The nand_spl_load_image function was guaranteed to read an entire block
> > > into RAM, regardless of how many bytes were to be read. This is
> > > particularly problematic when spl_load_legacy_image is called, as this
> > > function attempts to load a struct image_header but gets surprised with
> > > a full flash sector.
> > >
> > > Allow partial reads to restore functionality to the code path
> > > spl_nand_load_element() -> spl_load_legacy_img() ->
> > > spl_nand_legacy_read(load, header, sizeof(hdr), header);
> > >
> > > Signed-off-by: Colin Foster
> > > ---
> > > drivers/mtd/nand/raw/nand_spl_loaders.c | 36 -
> > > 1 file changed, 24 insertions(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/mtd/nand/raw/nand_spl_loaders.c
> > > b/drivers/mtd/nand/raw/nand_spl_loaders.c
> > > index 4befc75c04..84ac482c06 100644
> > > --- a/drivers/mtd/nand/raw/nand_spl_loaders.c
> > > +++ b/drivers/mtd/nand/raw/nand_spl_loaders.c
> > > @@ -1,9 +1,18 @@
> > > +/*
> > > + * Temporary storage for non NAND page aligned and non NAND page sized
> > > + * reads. Note: This does not support runtime detected FLASH yet, but
> > > + * that should be reasonably easy to fix by making the buffer large
> > > + * enough :)
> > > + */
> > > +static u8 scratch_buf[CONFIG_SYS_NAND_PAGE_SIZE];
> > > +
> > > int nand_spl_load_image(uint32_t offs, unsigned int size, void *dst)
> > > {
> > > + unsigned int read_this_time = CONFIG_SYS_NAND_PAGE_SIZE;
> > > + unsigned int size_remaining = size;
> > > unsigned int block, lastblock;
> > > unsigned int page, page_offset;
> > >
> > > - /* offs has to be aligned to a page address! */
> > > block = offs / CONFIG_SYS_NAND_BLOCK_SIZE;
> > > lastblock = (offs + size - 1) / CONFIG_SYS_NAND_BLOCK_SIZE;
> > > page = (offs % CONFIG_SYS_NAND_BLOCK_SIZE) /
> > > CONFIG_SYS_NAND_PAGE_SIZE;
> > > @@ -12,8 +21,18 @@ int nand_spl_load_image(uint32_t offs, unsigned int
> > > size, void *dst)
> > > while (block <= lastblock) {
> > > if (!nand_is_bad_block(block)) {
> > > /* Skip bad blocks */
> > > - while (page < CONFIG_SYS_NAND_PAGE_COUNT) {
> > > - nand_read_page(block, page, dst);
> > > + while (page < CONFIG_SYS_NAND_PAGE_COUNT &&
> > > + size_remaining > 0) {
> > > + if (size_remaining <
> > > CONFIG_SYS_NAND_PAGE_SIZE)
> > > + {
> > > + nand_read_page(block, page,
> > > + scratch_buf);
> > > + memcpy(dst, scratch_buf,
> > > + size_remaining);
> > > + read_this_time = size_remaining;
> > > + } else {
> > > + nand_read_page(block, page, dst);
> > > + }
> > > /*
> > > * When offs is not aligned to page
> > > address the
> > > * extra offset is copied to dst as well.
> > > Copy
> > > @@ -26,7 +45,8 @@ int nand_spl_load_image(uint32_t offs, unsigned int
> > > size, void *dst)
> > > dst = (void *)((int)dst -
> > > page_offset);
> > > page_offset = 0;
> > > }
> > > - dst += CONFIG_SYS_NAND_PAGE_SIZE;
> > > + dst += read_this_time;
> > > + size_remaining -= read_this_time;
> > > page++;
> > > }
> > >
> > > @@ -70,14 +90,6 @@ u32 nand_spl_adjust_offset(u32 sector, u32 offs)
> > > }
> > >
> > > #ifdef CONFIG_SPL_UBI
> > > -/*
> > > - * Temporary storage for non NAND page aligned and non NAND page sized
> > > - * reads. Note: This does not support runtime detected FLASH yet, but
> > > - * that should be reasonably easy to fix by making the buffer large
> > > - * enough :)
> > > - */
> > > -static u8 scratch_buf[CONFIG_SYS_NAND_PAGE_SIZE];
> > > -
> > > /**
> > > * nand_spl_read_block - Read data from physical eraseblock into a buffer
> > > * @block: Number of the physical eraseblock
> > > --
> > > 2.25.1
> > >
> >
> > Reviewed-by: Dario Binacchi
> >
> > Thanks and regards,
> > Dario
> >
>
> This is the error reported by the CI/CD pipeline:
>
> arm: + corvus
> 241+arm-linux-gnueabi-ld.bfd: u-boot-spl section `.bss' wi
PSU initialization code on zynqmp platforms
Hi Michal, (Well, that's embarassing. Sending again with a useful subject.) I'm bringing up u-boot on a custom zynqmp platform. For the PSU initialization, I can start with the psu_init_gpl.[ch] files embedded in the .xsa generated by Vivado. However, these are pretty flawed [1, 2]. What is your workflow for generating and maintaining the in-tree psu_init_gpl files you maintain? Are these files cleaned up and maintained by hand? If your workflow is functional, I will happily emulate it instead - even if it means straying from Vivado's configuration GUI. best, Graeme 1: https://lists.denx.de/pipermail/u-boot/2021-February/439394.html 2: https://support.xilinx.com/s/feed/0D52E6kuRAMSA2
[PATCH] Makefile: With BINMAN_ALLOW_MISSING=1 don't error on missing
When the user builds with BINMAN_ALLOW_MISSING=1 they're explicitly setting the flag to allow for additional binaries to be missing and so have acknowledged the output might not work. In this case we want to default to not passing a non-zero exit code. Cc: Simon Glass Reported-by: Peter Robinson Signed-off-by: Tom Rini --- This passes CI as-is: https://source.denx.de/u-boot/u-boot/-/pipelines/14340 --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index de5746399a63..03de1da1bfd0 100644 --- a/Makefile +++ b/Makefile @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if $(BINMAN_DEBUG),-D) \ --toolpath $(objtree)/tools \ $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \ build -u -d u-boot.dtb -O . -m \ - $(if $(BINMAN_ALLOW_MISSING),--allow-missing --fake-ext-blobs) \ + $(if $(BINMAN_ALLOW_MISSING),--allow-missing --ignore-missing) \ -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \ -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \ $(foreach f,$(BINMAN_INDIRS),-I $(f)) \ -- 2.25.1
Re: [PATCH 01/10] Convert CONFIG_SYS_NAND_DBW_8 et al to Kconfig
On Sat, Nov 12, 2022 at 05:36:42PM -0500, Tom Rini wrote: > This converts the following to Kconfig: >CONFIG_SYS_NAND_DBW_8 >CONFIG_SYS_NAND_DBW_16 > > Note that all instances of the code check for CONFIG_SYS_NAND_DBW_16 > being defined, and then "else" to CONFIG_SYS_NAND_DBW_8 whereas all of > the configs set CONFIG_SYS_NAND_DBW_8. So we introduce > CONFIG_SYS_NAND_DBW_16 as an option. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/17] global: Move remaining CONFIG_SYS_NOR_* to CFG_SYS_NOR_*
On Wed, Nov 16, 2022 at 01:10:25PM -0500, Tom Rini wrote: > The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_NOR > namespace do not easily transition to Kconfig. In many cases they likely > should come from the device tree instead. Move these out of CONFIG > namespace and in to CFG namespace. > > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass For the series, (and v2 of #3) applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 01/38] power: pmic: Guard non-DM_PMIC drivers with a check for POWER_LEGACY
On Sat, Nov 19, 2022 at 06:45:08PM -0500, Tom Rini wrote: > As we have more legacy PMIC drivers to move to Kconfig, guard them all > with POWER_LEGACY or SPL_POWER_LEGACY. Do the same kind of check for > building the drivers too. This also means that we need to resort the > list slightly in the Makefile. > > Cc: Jaehoon Chung > Signed-off-by: Tom Rini > Reviewed-by: Simon Glass For the series, applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v5 09/19] net: ipv6: Incorporate IPv6 support into u-boot net subsystem
On 12/2/22 10:18, Viacheslav Mitrofanov wrote:
Add net_ip6_handler (an IPv6 packet handler) into net_loop. Add
neighbor discovery mechanism into network init process. That is the
main step to run IPv6 in u-boot. Now u-boot is capable to use NDP and
handle IPv6 packets.
Signed-off-by: Viacheslav Mitrofanov
Reviewed-by: Ramon Fried
Reviewed-by: Simon Glass
---
net/net.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/net/net.c b/net/net.c
index aca20e43b0..63bf962b53 100644
--- a/net/net.c
+++ b/net/net.c
@@ -91,6 +91,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -343,8 +345,17 @@ void net_auto_load(void)
static int net_init_loop(void)
{
- if (eth_get_dev())
+ if (eth_get_dev()) {
memcpy(net_ethaddr, eth_get_ethaddr(), 6);
+
+ if (IS_ENABLED(CONFIG_IPV6)) {
+ ip6_make_lladdr(&net_link_local_ip6, net_ethaddr);
+ if (!memcmp(&net_ip6, &net_null_addr_ip6,
+ sizeof(struct in6_addr)))
+ memcpy(&net_ip6, &net_link_local_ip6,
+ sizeof(struct in6_addr));
+ }
+ }
else
/*
* Not ideal, but there's no way to get the actual error, and I
@@ -385,6 +396,7 @@ int net_init(void)
(i + 1) * PKTSIZE_ALIGN;
}
arp_init();
+ ndisc_init();
net_clear_handlers();
/* Only need to setup buffer pointers once. */
@@ -589,6 +601,11 @@ restart:
if (arp_timeout_check() > 0)
time_start = get_timer(0);
+ if (IS_ENABLED(CONFIG_IPV6)) {
+ if (use_ip6 && (ndisc_timeout_check() > 0))
+ time_start = get_timer(0);
+ }
+
/*
* Check the ethernet for a new packet. The ethernet
* receive routine will process it.
@@ -1243,6 +1260,10 @@ void net_process_received_packet(uchar *in_packet, int
len)
case PROT_RARP:
rarp_receive(ip, len);
break;
+#endif
+#if IS_ENABLED(CONFIG_IPV6)
+ case PROT_IP6:
+ net_ip6_handler(et, (struct ip6_hdr *)ip, len);
#endif
Coverity reports the following:
CID 430975: Control flow issues (MISSING_BREAK)
The case for value "34525" is not terminated by a "break" statement.
Either a 'break;' or a 'fallthrough;' is missing. It looks like
net_ip6_handler() already handles ICMP and UDP so probably the PROT_IP
case shouldn't be executed at all. Therefore you should add a 'break;'.
case PROT_IP:
debug_cond(DEBUG_NET_PKT, "Got IP\n");
--
- Daniel
Re: [PATCH v5 04/19] net: ipv6: Add Neighbor Discovery Protocol (NDP)
On 12/2/22 10:18, Viacheslav Mitrofanov wrote:
Implement basic of NDP. It doesn't include such things as Router
Solicitation, Router Advertisement and Redirect. It just has Neighbor
Solicitation and Neighbor Advertisement. Only these two features are used
in u-boot IPv6. Implementation of some NDP functions uses API that was
exposed in "net: ipv6: Add IPv6 basic primitives".
Also this patch inlcudes update in Makefile to build NDP.
Series-changes: 3
- Added structures and functions descriptions
- Fixed style problems
Series-changes: 4
- Fixed structures and functions description style
Signed-off-by: Viacheslav Mitrofanov
Reviewed-by: Ramon Fried
Reviewed-by: Simon Glass
---
include/ndisc.h | 102 +
net/Makefile| 1 +
net/ndisc.c | 289
3 files changed, 392 insertions(+)
create mode 100644 include/ndisc.h
create mode 100644 net/ndisc.c
...
+
+int ndisc_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6, int len)
+{
+ struct icmp6hdr *icmp =
+ (struct icmp6hdr *)(((uchar *)ip6) + IP6_HDR_SIZE);
+ struct nd_msg *ndisc = (struct nd_msg *)icmp;
+ uchar neigh_eth_addr[6];
+
+ switch (icmp->icmp6_type) {
+ case IPV6_NDISC_NEIGHBOUR_SOLICITATION:
+ debug("received neighbor solicitation for %pI6c from %pI6c\n",
+ &ndisc->target, &ip6->saddr);
+ if (ip6_is_our_addr(&ndisc->target) &&
+ ndisc_has_option(ip6, ND_OPT_SOURCE_LL_ADDR)) {
+ ndisc_extract_enetaddr(ndisc, neigh_eth_addr);
+ ip6_send_na(neigh_eth_addr, &ip6->saddr,
+ &ndisc->target);
+ }
+ break;
+
+ case IPV6_NDISC_NEIGHBOUR_ADVERTISEMENT:
+ /* are we waiting for a reply ? */
+ if (ip6_is_unspecified_addr(&net_nd_sol_packet_ip6))
+ break;
+
+ if ((memcmp(&ndisc->target, &net_nd_rep_packet_ip6,
+ sizeof(struct in6_addr)) == 0) &&
+ ndisc_has_option(ip6, ND_OPT_TARGET_LL_ADDR)) {
+ ndisc_extract_enetaddr(ndisc, neigh_eth_addr);
+
+ /* save address for later use */
+ if (!net_nd_packet_mac)
+ memcpy(net_nd_packet_mac, neigh_eth_addr, 7);
Coverity reports the following:
CID 430977: Null pointer dereferences (FORWARD_NULL)
Passing null pointer "net_nd_packet_mac" to "memcpy", which dereferences
it. [Note: The source code implementation of the function has been
overridden by a builtin model.]
CID 430974: Memory - corruptions (OVERRUN)
Overrunning array "neigh_eth_addr" of 6 bytes by passing it to a
function which accesses it at byte offset 6 using argument "7UL". [Note:
The source code implementation of the function has been overridden by a
builtin model.]
Did you mean to write the following which would make more sense?
if (net_nd_packet_mac)
memcpy(net_nd_packet_mac, neigh_eth_addr, 7);
+
+ /* modify header, and transmit it */
+ memcpy(((struct ethernet_hdr
*)net_nd_tx_packet)->et_dest,
+ neigh_eth_addr, 6);
+
+ net_send_packet(net_nd_tx_packet,
+ net_nd_tx_packet_size);
+
+ /* no ND request pending now */
+ net_nd_sol_packet_ip6 = net_null_addr_ip6;
+ net_nd_tx_packet_size = 0;
+ net_nd_packet_mac = NULL;
+ }
+ break;
+ default:
+ debug("Unexpected ICMPv6 type 0x%x\n", icmp->icmp6_type);
+ return -1;
+ }
+
+ return 0;
+}
--
- Daniel
[PATCH 1/4] ARM: stm32: Fix ECDSA authentication with Dcache enabled
In case Dcache is enabled while the ECDSA authentication function is
called via BootROM ROM API, the CRYP DMA might pick stale version of
data from DRAM. Disable Dcache around the BootROM call to avoid this
issue.
Signed-off-by: Marek Vasut
---
Cc: Alexandru Gagniuc
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
arch/arm/mach-stm32mp/ecdsa_romapi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/mach-stm32mp/ecdsa_romapi.c
b/arch/arm/mach-stm32mp/ecdsa_romapi.c
index a2f63ff879f..72b87bf2c64 100644
--- a/arch/arm/mach-stm32mp/ecdsa_romapi.c
+++ b/arch/arm/mach-stm32mp/ecdsa_romapi.c
@@ -64,6 +64,7 @@ static int romapi_ecdsa_verify(struct udevice *dev,
const void *signature, size_t sig_len)
{
struct ecdsa_rom_api rom;
+ bool reenable_dcache;
uint8_t raw_key[64];
uint32_t rom_ret;
int algo;
@@ -81,8 +82,21 @@ static int romapi_ecdsa_verify(struct udevice *dev,
memcpy(raw_key + 32, pubkey->y, 32);
stm32mp_rom_get_ecdsa_functions(&rom);
+
+ /*
+* Disable D-cache before calling into BootROM, else CRYP DMA
+* may fail to pick up the correct data.
+*/
+ if (dcache_status()) {
+ dcache_disable();
+ reenable_dcache = true;
+ }
+
rom_ret = rom.ecdsa_verify_signature(hash, raw_key, signature, algo);
+ if (reenable_dcache)
+ dcache_enable();
+
return rom_ret == ROM_API_SUCCESS ? 0 : -EPERM;
}
--
2.35.1
[PATCH 2/4] ARM: stm32: Factor out save_boot_params
The STM32MP15xx platform currently comes with two incompatible
implementations of save_boot_params() weak function override.
Factor the save_boot_params() implementation into common cpu.c
code and provide accessors to read out both ROM API table address
and DT address from any place in the code instead.
Signed-off-by: Marek Vasut
---
Cc: Alexandru Gagniuc
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
arch/arm/mach-stm32mp/boot_params.c | 20 ++-
arch/arm/mach-stm32mp/cpu.c | 35 +++
arch/arm/mach-stm32mp/ecdsa_romapi.c | 20 ++-
.../arm/mach-stm32mp/include/mach/sys_proto.h | 3 ++
4 files changed, 42 insertions(+), 36 deletions(-)
diff --git a/arch/arm/mach-stm32mp/boot_params.c
b/arch/arm/mach-stm32mp/boot_params.c
index e91ef1b2fc7..e40cca938ef 100644
--- a/arch/arm/mach-stm32mp/boot_params.c
+++ b/arch/arm/mach-stm32mp/boot_params.c
@@ -11,30 +11,14 @@
#include
#include
-/*
- * Force data-section, as .bss will not be valid
- * when save_boot_params is invoked.
- */
-static unsigned long nt_fw_dtb __section(".data");
-
-/*
- * Save the FDT address provided by TF-A in r2 at boot time
- * This function is called from start.S
- */
-void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
- unsigned long r3)
-{
- nt_fw_dtb = r2;
-
- save_boot_params_ret();
-}
-
/*
* Use the saved FDT address provided by TF-A at boot time (NT_FW_CONFIG =
* Non Trusted Firmware configuration file) when the pointer is valid
*/
void *board_fdt_blob_setup(int *err)
{
+ unsigned long nt_fw_dtb = get_stm32mp_bl2_dtb();
+
log_debug("%s: nt_fw_dtb=%lx\n", __func__, nt_fw_dtb);
*err = 0;
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 855fc755fe0..fa02a11d867 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -378,3 +378,38 @@ int arch_misc_init(void)
return 0;
}
+
+/*
+ * Without forcing the ".data" section, this would get saved in ".bss". BSS
+ * will be cleared soon after, so it's not suitable.
+ */
+static uintptr_t rom_api_table __section(".data");
+static uintptr_t nt_fw_dtb __section(".data");
+
+/*
+ * The ROM gives us the API location in r0 when starting. This is only
available
+ * during SPL, as there isn't (yet) a mechanism to pass this on to u-boot. Save
+ * the FDT address provided by TF-A in r2 at boot time. This function is called
+ * from start.S
+ */
+void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
+ unsigned long r3)
+{
+#if IS_ENABLED(CONFIG_STM32_ECDSA_VERIFY)
+ rom_api_table = r0;
+#endif
+#if IS_ENABLED(CONFIG_TFABOOT)
+ nt_fw_dtb = r2;
+#endif
+ save_boot_params_ret();
+}
+
+uintptr_t get_stm32mp_rom_api_table(void)
+{
+ return rom_api_table;
+}
+
+uintptr_t get_stm32mp_bl2_dtb(void)
+{
+ return nt_fw_dtb;
+}
diff --git a/arch/arm/mach-stm32mp/ecdsa_romapi.c
b/arch/arm/mach-stm32mp/ecdsa_romapi.c
index 72b87bf2c64..32a7357ad56 100644
--- a/arch/arm/mach-stm32mp/ecdsa_romapi.c
+++ b/arch/arm/mach-stm32mp/ecdsa_romapi.c
@@ -24,26 +24,10 @@ struct ecdsa_rom_api {
uint32_t ecc_algo);
};
-/*
- * Without forcing the ".data" section, this would get saved in ".bss". BSS
- * will be cleared soon after, so it's not suitable.
- */
-static uintptr_t rom_api_loc __section(".data");
-
-/*
- * The ROM gives us the API location in r0 when starting. This is only
available
- * during SPL, as there isn't (yet) a mechanism to pass this on to u-boot.
- */
-void save_boot_params(unsigned long r0, unsigned long r1, unsigned long r2,
- unsigned long r3)
-{
- rom_api_loc = r0;
- save_boot_params_ret();
-}
-
static void stm32mp_rom_get_ecdsa_functions(struct ecdsa_rom_api *rom)
{
- uintptr_t verify_ptr = rom_api_loc + ROM_API_OFFSET_ECDSA_VERIFY;
+ uintptr_t verify_ptr = get_stm32mp_rom_api_table() +
+ ROM_API_OFFSET_ECDSA_VERIFY;
rom->ecdsa_verify_signature = *(void **)verify_ptr;
}
diff --git a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
index f19a70e53e0..0d39b67178e 100644
--- a/arch/arm/mach-stm32mp/include/mach/sys_proto.h
+++ b/arch/arm/mach-stm32mp/include/mach/sys_proto.h
@@ -77,3 +77,6 @@ void stm32mp_misc_init(void);
/* helper function: read data from OTP */
u32 get_otp(int index, int shift, int mask);
+
+uintptr_t get_stm32mp_rom_api_table(void);
+uintptr_t get_stm32mp_bl2_dtb(void);
--
2.35.1
[PATCH 3/4] ARM: stm32: Pass ROM API table pointer to U-Boot proper
The ROM API table pointer is no longer accessible from U-Boot, fix
this by passing the ROM API pointer through. This makes it possible
for U-Boot to call ROM API functions to authenticate payload like
signed fitImages.
Signed-off-by: Marek Vasut
---
Cc: Alexandru Gagniuc
Cc: Patrice Chotard
Cc: Patrick Delaunay
---
arch/arm/mach-stm32mp/cpu.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index fa02a11d867..9553ecd243c 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
/*
* early TLB into the .data section so that it not get cleared
@@ -413,3 +414,17 @@ uintptr_t get_stm32mp_bl2_dtb(void)
{
return nt_fw_dtb;
}
+
+#ifdef CONFIG_SPL_BUILD
+void jump_to_image_no_args(struct spl_image_info *spl_image)
+{
+ typedef void __noreturn (*image_entry_noargs_t)(u32 romapi);
+ uintptr_t romapi = get_stm32mp_rom_api_table();
+
+ image_entry_noargs_t image_entry =
+ (image_entry_noargs_t)spl_image->entry_point;
+
+ printf("image entry point: 0x%lx\n", spl_image->entry_point);
+ image_entry(romapi);
+}
+#endif
--
2.35.1
[PATCH 4/4] ARM: stm32: Make ECDSA authentication available to U-Boot
With U-Boot having access to ROM API call table, it is possible to use the ROM API call it authenticate e.g. signed kernel fitImages using the BootROM ECDSA support. Make this available by pulling the ECDSA BootROM call support from SPL-only guard. Signed-off-by: Marek Vasut --- Cc: Alexandru Gagniuc Cc: Patrice Chotard Cc: Patrick Delaunay --- arch/arm/mach-stm32mp/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-stm32mp/Makefile b/arch/arm/mach-stm32mp/Makefile index 1db9057e049..a19b2797c8b 100644 --- a/arch/arm/mach-stm32mp/Makefile +++ b/arch/arm/mach-stm32mp/Makefile @@ -11,10 +11,10 @@ obj-y += bsec.o obj-$(CONFIG_STM32MP13x) += stm32mp13x.o obj-$(CONFIG_STM32MP15x) += stm32mp15x.o +obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o ifdef CONFIG_SPL_BUILD obj-y += spl.o obj-y += tzc400.o -obj-$(CONFIG_STM32_ECDSA_VERIFY) += ecdsa_romapi.o else obj-y += cmd_stm32prog/ obj-$(CONFIG_CMD_STM32KEY) += cmd_stm32key.o -- 2.35.1
[PATCH 1/3] ARM: stm32: Enable assorted ST specific commands on DHSOM
Enable the stm32prog, stm32key, stboard commands on DHSOM. Those can be used e.g. to implement verified boot. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 4 configs/stm32mp15_dhcor_basic_defconfig | 4 2 files changed, 8 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index fd261d96105..92ccbb70939 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -11,7 +11,11 @@ CONFIG_SPL_MMC=y CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_ADDR=0x5C00A14C CONFIG_SPL=y +CONFIG_CMD_STM32KEY=y +CONFIG_CMD_STBOARD=y CONFIG_TARGET_DH_STM32MP1_PDK2=y +CONFIG_CMD_STM32PROG=y +CONFIG_CMD_STM32PROG_OTP=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y # CONFIG_ARMV7_VIRT is not set diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 947bc6b502e..306221404df 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -11,7 +11,11 @@ CONFIG_SPL_MMC=y CONFIG_BOOTCOUNT_BOOTLIMIT=3 CONFIG_SYS_BOOTCOUNT_ADDR=0x5C00A14C CONFIG_SPL=y +CONFIG_CMD_STM32KEY=y +CONFIG_CMD_STBOARD=y CONFIG_TARGET_DH_STM32MP1_PDK2=y +CONFIG_CMD_STM32PROG=y +CONFIG_CMD_STM32PROG_OTP=y CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y # CONFIG_ARMV7_VIRT is not set -- 2.35.1
[PATCH 2/3] ARM: stm32: Increment boot counter in SPL on DHSOM
Increment the boot counter already in U-Boot SPL instead of incrementing it only later in U-Boot proper. This can be used by SPL to boot either of two U-Boot copies and improve redundancy of software on the platform, e.g. in case of full A/B update strategy. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 1 + configs/stm32mp15_dhcor_basic_defconfig | 1 + 2 files changed, 2 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index 92ccbb70939..f1eb022bc66 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -36,6 +36,7 @@ CONFIG_CONSOLE_MUX=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_FOOTPRINT_LIMIT=y CONFIG_SPL_MAX_FOOTPRINT=0x3db00 +CONFIG_SPL_BOOTCOUNT_LIMIT=y CONFIG_SPL_LEGACY_IMAGE_FORMAT=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_STACK=0x3000 diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 306221404df..2e9f2049784 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -34,6 +34,7 @@ CONFIG_CONSOLE_MUX=y CONFIG_BOARD_EARLY_INIT_F=y CONFIG_SPL_FOOTPRINT_LIMIT=y CONFIG_SPL_MAX_FOOTPRINT=0x3db00 +CONFIG_SPL_BOOTCOUNT_LIMIT=y CONFIG_SPL_LEGACY_IMAGE_FORMAT=y # CONFIG_SPL_SHARES_INIT_SP_ADDR is not set CONFIG_SPL_STACK=0x3000 -- 2.35.1
[PATCH 3/3] ARM: stm32: Increment WDT by default on DHSOM
Enable watchdog timer on the DHSOM by default, both in U-Boot proper and in SPL. This can be used in combination with boot counter by either SPL or U-Boot proper to boot either copy of system software, e.g. in case of full A/B update strategy. Signed-off-by: Marek Vasut --- Cc: Patrice Chotard Cc: Patrick Delaunay --- configs/stm32mp15_dhcom_basic_defconfig | 2 ++ configs/stm32mp15_dhcor_basic_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index f1eb022bc66..26c2e73aa04 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -175,6 +175,8 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_WDT=y +CONFIG_WDT_STM32MP=y CONFIG_FAT_WRITE=y # CONFIG_BINMAN_FDT is not set CONFIG_FDT_FIXUP_PARTITIONS=y diff --git a/configs/stm32mp15_dhcor_basic_defconfig b/configs/stm32mp15_dhcor_basic_defconfig index 2e9f2049784..f76e13eafd7 100644 --- a/configs/stm32mp15_dhcor_basic_defconfig +++ b/configs/stm32mp15_dhcor_basic_defconfig @@ -174,6 +174,8 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x0483 CONFIG_USB_GADGET_PRODUCT_NUM=0x5720 CONFIG_USB_GADGET_DWC2_OTG=y CONFIG_USB_GADGET_DOWNLOAD=y +CONFIG_WDT=y +CONFIG_WDT_STM32MP=y CONFIG_FAT_WRITE=y # CONFIG_BINMAN_FDT is not set CONFIG_FDT_FIXUP_PARTITIONS=y -- 2.35.1
Re: [PATCH] Makefile: With BINMAN_ALLOW_MISSING=1 don't error on missing
Hi Tom,
On Tue, 6 Dec 2022 at 15:03, Tom Rini wrote:
>
> When the user builds with BINMAN_ALLOW_MISSING=1 they're explicitly
> setting the flag to allow for additional binaries to be missing and so
> have acknowledged the output might not work. In this case we want to
> default to not passing a non-zero exit code.
>
> Cc: Simon Glass
> Reported-by: Peter Robinson
> Signed-off-by: Tom Rini
> ---
> This passes CI as-is:
> https://source.denx.de/u-boot/u-boot/-/pipelines/14340
> ---
> Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index de5746399a63..03de1da1bfd0 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1334,7 +1334,7 @@ cmd_binman = $(srctree)/tools/binman/binman $(if
> $(BINMAN_DEBUG),-D) \
> --toolpath $(objtree)/tools \
> $(if $(BINMAN_VERBOSE),-v$(BINMAN_VERBOSE)) \
> build -u -d u-boot.dtb -O . -m \
> - $(if $(BINMAN_ALLOW_MISSING),--allow-missing
> --fake-ext-blobs) \
> + $(if $(BINMAN_ALLOW_MISSING),--allow-missing
> --ignore-missing) \
> -I . -I $(srctree) -I $(srctree)/board/$(BOARDDIR) \
> -I arch/$(ARCH)/dts -a of-list=$(CONFIG_OF_LIST) \
> $(foreach f,$(BINMAN_INDIRS),-I $(f)) \
> --
> 2.25.1
>
I believe we need the --fake-ext-blobs flag as well, since otherwise
boards which use tools (like mkimage) on things that don't exist will
not work.
Yes I know this passes on CI, but it will cause breakages when people
use mkimage or other things which have missing inputs. It will be
quite confusing too!
As to the logic, I thought you had wanted the build to fail if there
are missing blobs, regardless of whether they were allowed or not.
There is currently code in buildman to detect this failure and either
report it or ignore it:
if (result.return_code == 2 and
('Some images are invalid' in result.stderr)):
# This is handled later by the check for output in
# stderr
result.return_code = 0
Since buildman sets BINMAN_ALLOW_MISSING=1 if -M is given, we will not
be able to detect missing binaries at all when built from buildman. I
think a suitable fix would be to update the code above to detect the
'Some images are invalid' regardless of the return code.
Regards,
Simon
Re: [PATCHv2 010/149] rsa-verify: Rework host check for CONFIG_RSA_VERIFY_WITH_PKEY
On Sun, Dec 04, 2022 at 05:37:06PM -0500, Tom Rini wrote:
> While we do not want to use CONFIG_RSA_VERIFY_WITH_PKEY on the host, we
> cannot undef the symbol in this manner. As this ends up being a test
> within another function we can use !tools_build() as a test here.
>
> Cc: Simon Glass
> Signed-off-by: Tom Rini
> ---
> Changes in v2:
> - Switch to !tools_build() per Simon
> ---
> lib/rsa/rsa-verify.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c
> index 9605c376390a..db2aca5385a9 100644
> --- a/lib/rsa/rsa-verify.c
> +++ b/lib/rsa/rsa-verify.c
> @@ -23,18 +23,13 @@
> #include
> #include
>
> -#ifndef __UBOOT__
> /*
> * NOTE:
> * Since host tools, like mkimage, make use of openssl library for
> * RSA encryption, rsa_verify_with_pkey()/rsa_gen_key_prop() are
> * of no use and should not be compiled in.
> - * So just turn off CONFIG_RSA_VERIFY_WITH_PKEY.
> */
I think you can delete the whole comment here.
If you think it's still helpful, please place it below
in the function.
-Takahiro Akashi
> -#undef CONFIG_RSA_VERIFY_WITH_PKEY
> -#endif
> -
> /* Default public exponent for backward compatibility */
> #define RSA_DEFAULT_PUBEXP 65537
>
> @@ -506,7 +501,8 @@ int rsa_verify_hash(struct image_sign_info *info,
> {
> int ret = -EACCES;
>
> - if (CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) && !info->fdt_blob) {
> + if (!tools_build() && CONFIG_IS_ENABLED(RSA_VERIFY_WITH_PKEY) &&
> + !info->fdt_blob) {
> /* don't rely on fdt properties */
> ret = rsa_verify_with_pkey(info, hash, sig, sig_len);
> if (ret)
> --
> 2.25.1
>
Re: [PATCH] rockchip: Pinebook Pro: Do not initialize i2c before relocation
Hi Tom,
On 2022/12/6 06:25, Tom Rini wrote:
On Mon, Dec 05, 2022 at 09:35:41PM +, Peter Robinson wrote:
On Sat, Dec 3, 2022 at 12:31 PM Michal Suchanek wrote:
The i2c locks up when initialized before relocation, and it stays broken
in Linux as well breaking the ability to boot Linux.
The i2c bus and pmic was not actually used in pre-reloc before
commit ad607512f575 ("power: pmic: rk8xx: Support sysreset shutdown method")
The cause is not known.
This is board-specific, other boards that do not add the option to
include the i2c bus in pre-reloc DT are not affected.
Signed-off-by: Michal Suchanek
Reviewed-by: Peter Robinson
Tested-by: Peter Robinson
Thanks for checking this out, I had noticed a regression and had got
as far as bisecting it but not getting to a fix.
Tom: can we get this pulled into 2023.01 please?
Probably should be, yes. Kever, are there any other rockchip must-fixes
for v2023.01? I can take this directly if you don't have others and/or
don't want to make up a PR, thanks!
I will take these fixes, and send a PR to you later.
Thanks,
- Kever
