[PATCH] configs: evb-ast2600: Enable configs to store env in SPI
Enable defconfigs relevant for storing env on SPI flash. Signed-off-by: Ryan Chen --- configs/evb-ast2600_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig index 3440062156..7c09e846ac 100644 --- a/configs/evb-ast2600_defconfig +++ b/configs/evb-ast2600_defconfig @@ -13,6 +13,8 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds" CONFIG_ENV_SIZE=0x1 +CONFIG_ENV_OFFSET=0xe +CONFIG_ENV_SECT_SIZE=0x1 CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb" CONFIG_SPL_SERIAL=y @@ -74,6 +76,8 @@ CONFIG_EFI_PARTITION=y # CONFIG_SPL_EFI_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_ENV_OVERWRITE=y +CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_SECT_SIZE_AUTO=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y CONFIG_SPL_DM=y -- 2.34.1
[PATCH 1/1] efi_loader: enable eficonfig command by default
The eficonfig command is required to set boot options. Signed-off-by: Heinrich Schuchardt --- cmd/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/cmd/Kconfig b/cmd/Kconfig index aef99d2eb8..2caa4af71c 100644 --- a/cmd/Kconfig +++ b/cmd/Kconfig @@ -2000,6 +2000,7 @@ config CMD_EFIDEBUG config CMD_EFICONFIG bool "eficonfig - provide menu-driven uefi variables maintenance interface" + default y if !HAS_BOARD_SIZE_LIMIT depends on CMD_BOOTEFI_BOOTMGR select MENU help -- 2.38.1
[PATCH 3/3] efi_loader: add definition for efi_main()
U-Boot provides multiple EFI applications. The entry point is called
efi_main(). Provide a definition for this function. This avoids
build warnings like
lib/efi_loader/initrddump.c:468:21: warning:
no previous prototype for ‘efi_main’ [-Wmissing-prototypes]
468 | efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
| ^~~~
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/efi_api.h b/include/efi_api.h
index e1cdaf5247..2d18d25a71 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -513,6 +513,16 @@ struct efi_system_table {
struct efi_configuration_table *tables;
};
+/**
+ * efi_main() - entry point of EFI applications
+ *
+ * @image_handle: handle with the Loaded Image Protocol
+ * @systab:pointer to the system table
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_main(efi_handle_t image_handle,
+struct efi_system_table *systab);
+
#define EFI_LOADED_IMAGE_PROTOCOL_GUID \
EFI_GUID(0x5b1b31a1, 0x9562, 0x11d2, \
0x8e, 0x3f, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b)
--
2.38.1
[PATCH 1/3] efi_loader: make get_load_options() static
In program initrddump.efi function get_load_options() can be static.
This avoids a warning when building with 'make W=1':
lib/efi_loader/initrddump.c:442:6: warning:
no previous prototype for ‘get_load_options’ [-Wmissing-prototypes]
442 | u16 *get_load_options(void)
| ^~~~
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/initrddump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/initrddump.c b/lib/efi_loader/initrddump.c
index 9872106981..971a3b6236 100644
--- a/lib/efi_loader/initrddump.c
+++ b/lib/efi_loader/initrddump.c
@@ -439,7 +439,7 @@ out:
*
* Return: load options or NULL
*/
-u16 *get_load_options(void)
+static u16 *get_load_options(void)
{
efi_status_t ret;
struct efi_loaded_image *loaded_image;
--
2.38.1
[PATCH 2/3] efi_loader: fix struct efi_input_key
The UEFI specification defines filed UnicodeChar as CHAR16. We use
u16 for CHAR16 throughout our code. The change fixes the following errors:
lib/efi_loader/initrddump.c: In function ‘efi_input’:
lib/efi_loader/initrddump.c:218:38: warning:
comparison is always false due to limited range of data type
[-Wtype-limits]
218 | if (key.unicode_char >= 0xD800 && key.unicode_char <= 0xDBFF)
| ^~
lib/efi_loader/initrddump.c:218:68: warning:
comparison is always true due to limited range of data type
[-Wtype-limits]
218 | if (key.unicode_char >= 0xD800 && key.unicode_char <= 0xDBFF)
|^~
Fixes: 867a6ac86dd8 ("efi: Add start-up library code")
Reported-by: Marek Vasut
Signed-off-by: Heinrich Schuchardt
---
include/efi_api.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/efi_api.h b/include/efi_api.h
index 9bd70b0f18..e1cdaf5247 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -817,7 +817,7 @@ struct efi_simple_text_output_protocol {
struct efi_input_key {
u16 scan_code;
- s16 unicode_char;
+ u16 unicode_char;
};
#define EFI_SHIFT_STATE_INVALID0x
--
2.38.1
[PATCH 0/3] efi_loader: fix build warnings for initrddump.c
When building with 'make W=1' multipled build warnings were shown. Heinrich Schuchardt (3): efi_loader: make get_load_options() static efi_loader: fix struct efi_input_key efi_loader: add definition for efi_main() include/efi_api.h | 12 +++- lib/efi_loader/initrddump.c | 2 +- 2 files changed, 12 insertions(+), 2 deletions(-) -- 2.38.1
Re: [PATCH v2] riscv: cancel the limitation that NR_CPUS is less than or equal to 32
Hi Xiang, On Fri, Feb 03, 2023 at 03:24:37PM +0100, David Abdurachmanov wrote: > On Mon, Jan 3, 2022 at 1:13 PM Leo Liang wrote: > > > > On Thu, Dec 30, 2021 at 01:55:15AM +0800, Xiang W wrote: > > > 在 2021-12-29星期三的 17:23 +0800，Leo Liang写道： > > > > Hi Xiang, > > > > On Wed, Dec 22, 2021 at 07:32:53AM +0800, Xiang W wrote: > > > > > Various specifications of riscv allow the number of hart to be > > > > > greater than 32. The limit of 32 is determined by > > > > > gd->arch.available_harts. We can eliminate this limitation through > > > > > bitmaps. Currently, the number of hart is limited to 4095, and 4095 > > > > > is the limit of the RISC-V Advanced Core Local Interruptor > > > > > Specification. > > > > > > > > > > Test on sifive unmatched. > > > > > > > > > > Signed-off-by: Xiang W > > > > > --- > > > > > Changes since v1: > > > > > > > > > > * When NR_CPUS is very large, the value of GD_AVAILABLE_HARTS will > > > > > overflow the immediate range of ld/lw. This patch fixes this > > > > > problem > > > > > > > > > > arch/riscv/Kconfig | 4 ++-- > > > > > arch/riscv/cpu/start.S | 21 - > > > > > arch/riscv/include/asm/global_data.h | 4 +++- > > > > > arch/riscv/lib/smp.c | 2 +- > > > > > 4 files changed, 22 insertions(+), 9 deletions(-) > > > > > > > I noticed that this has never landed in U-Boot. Was this forgotten or > dropped for some reason (couldn't find anything)? > > The current limit on the Linux kernel side is 512. The default on > 64-bit (riscv64) is 64. > > david The patch seems to cause some CI error (timeout on QEMU). (https://source.denx.de/u-boot/custodians/u-boot-riscv/-/pipelines/15076) Could you take a look at it if you have time? Best regards, Leo
Re: [PATCH v2 031/169] Correct SPL use of ATMEL_PIO4
On 2/9/23 19:36, Tom Rini wrote: On Sun, Feb 05, 2023 at 03:36:17PM -0700, Simon Glass wrote: This converts 1 usage of this option to the non-SPL form, since there is no SPL_ATMEL_PIO4 defined in Kconfig Signed-off-by: Simon Glass --- (no changes since v1) drivers/pinctrl/pinctrl-at91-pio4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c b/drivers/pinctrl/pinctrl-at91-pio4.c index 50e3dd449ab..84b398619c4 100644 --- a/drivers/pinctrl/pinctrl-at91-pio4.c +++ b/drivers/pinctrl/pinctrl-at91-pio4.c @@ -271,7 +271,7 @@ static int atmel_pinctrl_bind(struct udevice *dev) ofnode node = dev_ofnode(dev); struct atmel_pinctrl_data *priv = (struct atmel_pinctrl_data *)dev_get_driver_data(dev); - if (!CONFIG_IS_ENABLED(ATMEL_PIO4)) + if (!IS_ENABLED(CONFIG_ATMEL_PIO4)) return 0; /* Obtain a handle to the GPIO driver */ This grows SPL in a number of platforms, so adding in Eugen to see if we really do want to omit this here in SPL on platforms that otherwise set the symbol. Hi Simon, Tom, The growth is because the compiler will now include in SPL all the code below the check ? The respective code is not conditionally compiled, so I am trying to see why the growth. The solution would be to guard all the below code in the function (or the whole bind itself) by #ifndef CONFIG_SPL_BUILD ? Eugen
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi Tony, Hi Pali, On 2/10/23 02:37, Tony Dinh wrote: Could you please check if Pogo V4 boots with CONFIG_REQUIRE_SERIAL_CONSOLE unset? Indeed, you're right! unset CONFIG_REQUIRE_SERIAL_CONSOLE allows the Pogo V4 to boot OK, without dm-pre-reloc needed. And it booted normally with kwboot, all serial input/outputs are OK. Also, note that just enabling DEBUG_UART would always make the board frozen when u-boot starts. This should not be the case of course. Are you sure you've correctly configured the DEBUG UART? I think I did that correctly (we've used that to debug the orion_timer issue previously). Here is how I've configured it: +CONFIG_DEBUG_UART_BASE=0xf1012000 +CONFIG_DEBUG_UART_CLOCK=25000 +CONFIG_DEBUG_UART=y Maybe you hit same issue in mach-kirkwood as me in the past for mach-mvebu? U-Boot code was trying to initialize UART at the _new_ base register address (0xf1012000) when U-Boot was still using the _old_ base register address (0xd0012000). I fixed it by moving code which changes base register address from arch_cpu_init() function to arch_very_early_init() function in commit: https://source.denx.de/u-boot/u-boot/-/commit/5bb2c550b11eb087437740b2a0d1fe780be5aec3 Thanks Pali, this is very likely the root cause here. Thanks for the info! Looking at that patch, I think I'm out of my depth :) Here the line for Kirkwood, re-configuring the base address of the internal registers: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-kirkwood/cpu.c#L193 You need to make sure, that this configuration is done before you use the DEBUG UART with base address 0xf1xx.. If you use the DEBUG UART before this, which is very likely, then you could also test if this works for you: CONFIG_DEBUG_UART_BASE=0xd0012000 For now I will fix this Pogo V4 with the -u-boot.dtsi, so as not to mess up anybody who might try UART booting with kwboot. Sure, please go ahead this way for now. BTW: Many years ago my intention was to include the Kirkwood support into the "common" Marvell MVEBU support in mach-mvebu. So that mach-kirkwood and it's special handling could be dropped. It's great to see that Kirkwood is getting attention now. Perhaps this move into mach-mvebu could be addressed at some point. Thanks, Stefan Thanks, Tony So this was another factor why it took me so long to figure this out :) I've just restored everything and removed the uart0 node from the Pogo V4 DTS like above and it is working. But of course, we don't want to change the Pogo V4 DTS, so I will submit another patch just for the Pogo V4 to add -u-boot.dtsi for this box to enable the dm-pre-reloc tag for uart0. Understood. Thanks, Tony Thanks, Stefan 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
[PATCH] riscv: add sbi v0.2 or later support
add rfence and ipi extension for sbi v0.2 or later. sbi_ipi add support
for sbi v0.2 or later. This can make sbi_ipi break through the limit that
the number of cores needs to be less than or equal to xlen
Signed-off-by: Xiang W
---
arch/riscv/Kconfig | 2 +-
arch/riscv/include/asm/sbi.h | 16 +++-
arch/riscv/lib/sbi.c | 71 +++-
arch/riscv/lib/sbi_ipi.c | 8 +++-
4 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ebc4bef220..1f534f6f77 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -212,7 +212,7 @@ config ANDES_PLICSW
config SMP
bool "Symmetric Multi-Processing"
-depends on SBI_V01 || !RISCV_SMODE
+depends on SBI || !RISCV_SMODE
help
This enables support for systems with more than one CPU. If
you say N here, U-Boot will run on single and multiprocessor
diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 81fcfe0b36..5c4df101f5 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -135,11 +135,12 @@ struct sbiret sbi_ecall(int ext, int fid,
unsigned long arg0,
unsigned long arg3, unsigned long arg4,
unsigned long arg5);
-#ifdef CONFIG_SBI_V01
void sbi_console_putchar(int ch);
int sbi_console_getchar(void);
void sbi_clear_ipi(void);
void sbi_shutdown(void);
+
+#ifdef CONFIG_SBI_V01
void sbi_send_ipi(const unsigned long *hart_mask);
void sbi_remote_fence_i(const unsigned long *hart_mask);
void sbi_remote_sfence_vma(const unsigned long *hart_mask,
@@ -149,7 +150,18 @@ void sbi_remote_sfence_vma_asid(const unsigned
long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid);
-#endif
+#else /* CONFIG_SBI_V01 */
+void sbi_send_ipi(unsigned long hart_mask, unsigned long hart_mask_base);
+void sbi_remote_fence_i(unsigned long hart_mask, unsigned long hart_mask_base);
+void sbi_remote_sfence_vma(unsigned long hart_mask, unsigned long
hart_mask_base,
+ unsigned long start,
+ unsigned long size);
+void sbi_remote_sfence_vma_asid(unsigned long hart_mask, unsigned
long hart_mask_base,
+ unsigned long start,
+ unsigned long size,
+ unsigned long asid);
+#endif /* CONFIG_SBI_V01 */
+
void sbi_set_timer(uint64_t stime_value);
long sbi_get_spec_version(void);
int sbi_get_impl_id(void);
diff --git a/arch/riscv/lib/sbi.c b/arch/riscv/lib/sbi.c
index 8724e3a460..0daf43ceec 100644
--- a/arch/riscv/lib/sbi.c
+++ b/arch/riscv/lib/sbi.c
@@ -204,8 +204,6 @@ void sbi_srst_reset(unsigned long type, unsigned
long reason)
0, 0, 0, 0);
}
-#ifdef CONFIG_SBI_V01
-
/**
* sbi_console_putchar() - Writes given character to the console device.
* @ch: The data to be written to the console.
@@ -251,6 +249,7 @@ void sbi_shutdown(void)
sbi_ecall(SBI_EXT_0_1_SHUTDOWN, 0, 0, 0, 0, 0, 0, 0);
}
+#ifdef CONFIG_SBI_V01
/**
* sbi_send_ipi() - Send an IPI to any hart.
* @hart_mask: A cpu mask containing all the target harts.
@@ -313,4 +312,72 @@ void sbi_remote_sfence_vma_asid(const unsigned
long *hart_mask,
(unsigned long)hart_mask, start, size, asid, 0, 0);
}
+#else /* CONFIG_SBI_V01 */
+
+/**
+ * sbi_send_ipi() - Send an IPI to any hart.
+ * @hart_mask: A cpu mask containing the target harts.
+ * @hart_mask_base: The hartid represented by the nth bit in
hart_mask is hart_mask_base+n
+ *
+ * Return: None
+ */
+void sbi_send_ipi(unsigned long hart_mask, unsigned long hart_mask_base)
+{
+sbi_ecall(SBI_EXT_SEND_IPI, SBI_FID_SEND_IPI, hart_mask,
+ hart_mask_base, 0, 0, 0, 0);
+}
+
+/**
+ * sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
+ * @hart_mask: A cpu mask containing the target harts.
+ * @hart_mask_base: The hartid represented by the nth bit in
hart_mask is hart_mask_base+n
+ *
+ * Return: None
+ */
+void sbi_remote_fence_i(unsigned long hart_mask, unsigned long hart_mask_base)
+{
+sbi_ecall(SBI_EXT_REMOTE_FENCE_I, SBI_FID_REMOTE_FENCE_I,
+ hart_mask, hart_mask_base, 0, 0, 0, 0);
+}
+
+/**
+ * sbi_remote_sfence_vma() - Execute SFENCE.VMA instructions on given remote
+ * harts for the specified virtual address range.
+ * @hart_mask: A cpu mask containing the target harts.
+ * @hart_mask_base: The hartid represented by the nth bit in
hart_mask is hart_mask_base+n
+ * @start: Start of the virtual address
+ * @size: Total size of the virtual address range.
+ *
+ * Return: None
+ */
+void sbi_remote_sfence_vma(unsigned long hart_mask, unsigned long
hart_mask_base,
+ unsigned long start,
+ unsigned long size)
+{
+sbi_ecall(SBI_EXT_REMOTE_SFENCE_VMA, SBI_FID_REMOTE_SFENCE_VMA,
+ hart_mask, hart_mask_base, start, size, 0, 0);
+}
+
+/**
+ * sbi_remote_sfence_vma_asid() - Execute SFENCE.VMA instructions on given
+ * remo
Re: [PATCH v2 1/6] clk: sunxi: Add NAND clocks and resets
On Sun, 22 Jan 2023 16:06:31 -0600
Samuel Holland wrote:
> Currently NAND clock setup is done in board code, both in SPL and in
> U-Boot proper. Add the NAND clocks/resets here so they can be used by
> the "full" NAND driver once it is converted to the driver model.
>
> The bit locations are copied from the Linux CCU drivers.
>
> Reviewed-by: Jagan Teki
> Signed-off-by: Samuel Holland
Thanks for the changes, looks good now.
Reviewed-by: Andre Przywara
Cheers,
Andre
> ---
>
> Changes in v2:
> - Fix A80 bus clock/reset bit positions
>
> drivers/clk/sunxi/clk_a10.c | 2 ++
> drivers/clk/sunxi/clk_a10s.c | 2 ++
> drivers/clk/sunxi/clk_a23.c | 3 +++
> drivers/clk/sunxi/clk_a31.c | 6 ++
> drivers/clk/sunxi/clk_a64.c | 3 +++
> drivers/clk/sunxi/clk_a80.c | 8
> drivers/clk/sunxi/clk_a83t.c | 3 +++
> drivers/clk/sunxi/clk_h3.c | 3 +++
> drivers/clk/sunxi/clk_h6.c | 6 ++
> drivers/clk/sunxi/clk_h616.c | 6 ++
> drivers/clk/sunxi/clk_r40.c | 3 +++
> 11 files changed, 45 insertions(+)
>
> diff --git a/drivers/clk/sunxi/clk_a10.c b/drivers/clk/sunxi/clk_a10.c
> index abd4e8b738..f27306fe33 100644
> --- a/drivers/clk/sunxi/clk_a10.c
> +++ b/drivers/clk/sunxi/clk_a10.c
> @@ -23,6 +23,7 @@ static struct ccu_clk_gate a10_gates[] = {
> [CLK_AHB_MMC1] = GATE(0x060, BIT(9)),
> [CLK_AHB_MMC2] = GATE(0x060, BIT(10)),
> [CLK_AHB_MMC3] = GATE(0x060, BIT(11)),
> + [CLK_AHB_NAND] = GATE(0x060, BIT(13)),
> [CLK_AHB_EMAC] = GATE(0x060, BIT(17)),
> [CLK_AHB_SPI0] = GATE(0x060, BIT(20)),
> [CLK_AHB_SPI1] = GATE(0x060, BIT(21)),
> @@ -47,6 +48,7 @@ static struct ccu_clk_gate a10_gates[] = {
> [CLK_APB1_UART6]= GATE(0x06c, BIT(22)),
> [CLK_APB1_UART7]= GATE(0x06c, BIT(23)),
>
> + [CLK_NAND] = GATE(0x080, BIT(31)),
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
> [CLK_SPI1] = GATE(0x0a4, BIT(31)),
> [CLK_SPI2] = GATE(0x0a8, BIT(31)),
> diff --git a/drivers/clk/sunxi/clk_a10s.c b/drivers/clk/sunxi/clk_a10s.c
> index e486cedd48..16ac589bb2 100644
> --- a/drivers/clk/sunxi/clk_a10s.c
> +++ b/drivers/clk/sunxi/clk_a10s.c
> @@ -20,6 +20,7 @@ static struct ccu_clk_gate a10s_gates[] = {
> [CLK_AHB_MMC0] = GATE(0x060, BIT(8)),
> [CLK_AHB_MMC1] = GATE(0x060, BIT(9)),
> [CLK_AHB_MMC2] = GATE(0x060, BIT(10)),
> + [CLK_AHB_NAND] = GATE(0x060, BIT(13)),
> [CLK_AHB_EMAC] = GATE(0x060, BIT(17)),
> [CLK_AHB_SPI0] = GATE(0x060, BIT(20)),
> [CLK_AHB_SPI1] = GATE(0x060, BIT(21)),
> @@ -35,6 +36,7 @@ static struct ccu_clk_gate a10s_gates[] = {
> [CLK_APB1_UART2]= GATE(0x06c, BIT(18)),
> [CLK_APB1_UART3]= GATE(0x06c, BIT(19)),
>
> + [CLK_NAND] = GATE(0x080, BIT(31)),
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
> [CLK_SPI1] = GATE(0x0a4, BIT(31)),
> [CLK_SPI2] = GATE(0x0a8, BIT(31)),
> diff --git a/drivers/clk/sunxi/clk_a23.c b/drivers/clk/sunxi/clk_a23.c
> index d94fecadd5..45d5ba75bf 100644
> --- a/drivers/clk/sunxi/clk_a23.c
> +++ b/drivers/clk/sunxi/clk_a23.c
> @@ -17,6 +17,7 @@ static struct ccu_clk_gate a23_gates[] = {
> [CLK_BUS_MMC0] = GATE(0x060, BIT(8)),
> [CLK_BUS_MMC1] = GATE(0x060, BIT(9)),
> [CLK_BUS_MMC2] = GATE(0x060, BIT(10)),
> + [CLK_BUS_NAND] = GATE(0x060, BIT(13)),
> [CLK_BUS_SPI0] = GATE(0x060, BIT(20)),
> [CLK_BUS_SPI1] = GATE(0x060, BIT(21)),
> [CLK_BUS_OTG] = GATE(0x060, BIT(24)),
> @@ -34,6 +35,7 @@ static struct ccu_clk_gate a23_gates[] = {
> [CLK_BUS_UART3] = GATE(0x06c, BIT(19)),
> [CLK_BUS_UART4] = GATE(0x06c, BIT(20)),
>
> + [CLK_NAND] = GATE(0x080, BIT(31)),
> [CLK_SPI0] = GATE(0x0a0, BIT(31)),
> [CLK_SPI1] = GATE(0x0a4, BIT(31)),
>
> @@ -52,6 +54,7 @@ static struct ccu_reset a23_resets[] = {
> [RST_BUS_MMC0] = RESET(0x2c0, BIT(8)),
> [RST_BUS_MMC1] = RESET(0x2c0, BIT(9)),
> [RST_BUS_MMC2] = RESET(0x2c0, BIT(10)),
> + [RST_BUS_NAND] = RESET(0x2c0, BIT(13)),
> [RST_BUS_SPI0] = RESET(0x2c0, BIT(20)),
> [RST_BUS_SPI1] = RESET(0x2c0, BIT(21)),
> [RST_BUS_OTG] = RESET(0x2c0, BIT(24)),
> diff --git a/drivers/clk/sunxi/clk_a31.c b/drivers/clk/sunxi/clk_a31.c
> index 360658912d..6ca800050e 100644
> --- a/drivers/clk/sunxi/clk_a31.c
> +++ b/drivers/clk/sunxi/clk_a31.c
> @@ -18,6 +18,8 @@ static struct ccu_clk_gate a31_gates[] = {
> [CLK_AHB1_MMC1] = GATE(0x060, BIT(9)),
> [CLK_AHB1_MMC2] = GATE(0x060, BIT(10)),
> [CLK_AHB1_MMC3] = GATE(0x060, BIT(11)),
> + [C
Re: [PATCH 5/5] video console: remove unused 4x6 font
On Wed, 11 Jan 2023 20:05:11 +0300 Dzmitry Sankouski wrote: > ok > > пт, 30 дек. 2022 г. в 01:40, Simon Glass : > > > > Hi Dzmitry, > > > > On Mon, 26 Dec 2022 at 13:50, Dzmitry Sankouski > > wrote: > > > > > > Remove video_font_4x6.h file because it's unused. > > > > > > Signed-off-by: Dzmitry Sankouski > > > --- > > > drivers/video/Kconfig|6 - > > > include/video_font.h |4 +- > > > include/video_font_4x6.h | 2155 -- > > > 3 files changed, 1 insertion(+), 2164 deletions(-) > > > delete mode 100644 include/video_font_4x6.h > > > > > > > I do think this is useful, e.g. on small displays. How about adding a > > Kconfig for it instead? You can cherry-pick this patch for the conversion: https://patchwork.ozlabs.org/project/uboot/patch/20220110005638.21599-4-andre.przyw...@arm.com/ Cheers, Andre
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi Pali, On Thu, Feb 9, 2023 at 1:45 PM Pali Rohár wrote: > > On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > > Hi Stefan, > > > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese wrote: > > > > > > Hi Tony, > > > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > > Hi Stefan, > > > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh wrote: > > > >> > > > >> Hi Pali, > > > >> > > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár wrote: > > > >>> > > > >>> On Thursday 02 February 2023 19:04:45 Pali Rohár wrote: > > > On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote: > > > > Hi all, > > > > > > > > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote: > > > >> > > > >> On Wednesday 01 February 2023 09:17:15 Michael Walle wrote: > > > >> When DM_SERIAL is enabled, the device-tree property > > > >> dm-pre-reloc is > > > >> required to boot over UART with kwboot. Enable this in a > > > >> Kirkwood > > > >> common u-boot dtsi. > > > > > > > > My (dev) board unfortunately, have a bootloader which can't > > > > boot over > > > > serial. > > > > > > This is feature of Marvell BootROM and does not require any > > > special from > > > Bootloader. So you should be able to boot over UART (if you have > > > accessible pins). > > > >>> > > > >>> I know, but there are known versions ob the bootrom where uart > > > >>> boot > > > >>> isn't supported (correctly). > > > >> > > > >> I heard about it... maybe it is a bug in client software (kwboot)? > > > >> I do > > > >> not have such board if you are interested in it I could try to > > > >> send some > > > >> details how to debug it. > > > > > > > > The Kirkwood SoCs came with different BootROM versions. Version 1.1 > > > > cannot be booted over UART, but version 1.2 can. I think there must > > > > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug, > > > > Dockstar, iConnect boards come with BootROM 1.1. Later version of > > > > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel > > > > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is > > > > the same SoC, eg. 6281, they are actually produced at a different > > > > time > > > > and have different BootROM versions. > > > > > > There are always multiple revisions of the same SoC. So it is > > > possible > > > that something was broken on first revision of 88F6281 and in next > > > revision was updated BootROM with some fixes. Revision is written on > > > package label and for Armada SoCs it is available also in some > > > register > > > (not sure about Kirkwood). It looks like that there is at least > > > revision > > > Z0 and revision A0 of some Kirkwood SoC. > > > > > > If there is a bug in first revisions then it should be documented in > > > some Kirkwood Errata document. Unfortunately I have never seen it, > > > it is > > > not public, so I have no idea. In any case, if somebody has access to > > > Marvell documents, interesting are these document numbers: > > > > > > * MV-S105223-001 - Differences Between the 88F6192, and 88F6281 > > > Stepping Z0 and A0 > > > * MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata, > > > Interface Guidelines, and Restrictions > > > * MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional > > > Errata, Interface Guidelines, and Restrictions > > > > > > One of the option how to investigate or debug this issue without > > > documentation is to dump both BootROM versions (1.1, 1.2) and compare > > > them. Either there is different UART protocol for booting (which > > > needs > > > to be implemented) or UART protocol is buggy and needs some > > > workaround > > > or it is completely broken and does not work. > > > >>> > > > >>> BootROM is mapped to 0xF800 address and is 64 kB long. So via > > > >>> U-Boot > > > >>> md command it is possible to dump it over console. Or via ext4write > > > >>> command store it so ext4 fs on sd card / sata disk. > > > >> > > > >> Thanks for the info. It will be a while before I can get back to this > > > >> BootROM 1.1 vs 1.2 topic. > > > >> > > > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > > consistent with the serial documentation in > > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > > must also be used. > > > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > >
Re: [PATCH 3/5] video console: add support for fonts wider than 1 byte
On Mon, 26 Dec 2022 22:49:27 +0300
Dzmitry Sankouski wrote:
Hi Dzmitry,
> Devices with high ppi may benefit from wider fonts.
>
> Current width implementation is limited by 1 byte, i.e. 8 bits.
> New version iterates VIDEO_FONT_BYTE_WIDTH times, to process all
> width bytes, thus allowing fonts wider than 1 byte.
In general I think this is probably better than my version, not only
because it unifies rotated and normal consoles.
Some minor/stylistic comments below.
>
> Signed-off-by: Dzmitry Sankouski
> ---
> drivers/video/console_simple.c | 79 ++
> include/video_font_4x6.h | 2 +
> include/video_font_data.h | 2 +
> 3 files changed, 47 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/video/console_simple.c b/drivers/video/console_simple.c
> index 20087a30af..3ae1fbdc89 100644
> --- a/drivers/video/console_simple.c
> +++ b/drivers/video/console_simple.c
> @@ -61,30 +61,32 @@ static int fill_char_horizontally(uchar *pfont, void
> **line, struct video_priv *
> {
> int ret;
> void *dst;
> - u8 mask = 0x80;
> -
> + u8 mask;
> ret = check_bpix_support(vid_priv->bpix);
> if (ret)
> return ret;
>
> - for (int col = 0; col < VIDEO_FONT_WIDTH; col++) {
> - dst = *line;
> - for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> - u32 value = (pfont[row * VIDEO_FONT_BYTE_WIDTH + col] &
> mask) ?
> - vid_priv->colour_fg :
> - vid_priv->colour_bg;
> -
> - ret = fill_pixel_and_goto_next(&dst,
> -value,
> -VNBYTES(vid_priv->bpix),
> -direction
> - );
> + for (int col = 0; col < VIDEO_FONT_BYTE_WIDTH; col++) {
> + mask = 0x80;
> + for (int bit = 0; bit < 8; bit++) {
I think it's cleaner to collapse this:
for (int col = 0; col < VIDEO_FONT_WIDTH; col++) {
if ((col % 8) == 0)
mask = 0x80;
...
> + dst = *line;
> + for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> + u32 value = (pfont[row * VIDEO_FONT_BYTE_WIDTH
> + col] & mask) ?
... and use (col / 8) here.
> + vid_priv->colour_fg :
> + vid_priv->colour_bg;
> +
> + ret = fill_pixel_and_goto_next(&dst,
> +value,
> +
> VNBYTES(vid_priv->bpix),
> +direction
> + );
> + }
> + if (direction)
> + *line += vid_priv->line_length;
> + else
> + *line -= vid_priv->line_length;
> + mask >>= 1;
> }
> - if (direction)
> - *line += vid_priv->line_length;
> - else
> - *line -= vid_priv->line_length;
> - mask >>= 1;
> }
> return ret;
> }
> @@ -101,24 +103,29 @@ static int fill_char_vertically(uchar *pfont, void
> **line, struct video_priv *vi
> return ret;
> for (int row = 0; row < VIDEO_FONT_HEIGHT; row++) {
> dst = *line;
> - uchar bits = pfont[row];
> -
> - for (int i = 0; i < VIDEO_FONT_WIDTH; i++) {
> - u32 value = (bits & 0x80) ?
> - vid_priv->colour_fg :
> - vid_priv->colour_bg;
> -
> - ret = fill_pixel_and_goto_next(&dst,
> -value,
> -VNBYTES(vid_priv->bpix),
> -direction
> - );
> - bits <<= 1;
> + uchar bits;
> +
> + for (int i = 0; i < VIDEO_FONT_BYTE_WIDTH; i++) {
> + bits = pfont[i];
> + for (int bit = 0; bit < 8; bit++) {
Same as above, those two loops should become one.
> + u32 value = (bits & 0x80) ?
> + vid_priv->colour_fg :
> + vid_priv->colour_bg;
> +
> + ret = fill_pixel_and_goto_next(&dst,
> +value,
> +
> VNBYTES(vid_priv->bpix),
> +
Re: U-boot not loading NVMe driver on Pi CM4
Added more debug logging and for some reason the nvme driver tries to bind to pcie root bridge instead of the SSD drivers/pinctrl/pinctrl-uclass.c:300-pinctrl_select_state_simple() pcie_brcm pcie@7d50: set_state_simple op missing PCIe BRCM: link up, 5.0 Gbps x1 (SSC) drivers/core/device.c:184- device_bind_common() Bound device pci_0:0.0 to pcie@7d50 drivers/core/uclass.c:338-uclass_find_device_by_seq() 0 drivers/core/uclass.c:346-uclass_find_device_by_seq()- 0 'gpio@7e20' drivers/core/uclass.c:349-uclass_find_device_by_seq()- found drivers/pinctrl/pinctrl-uclass.c:300-pinctrl_select_state_simple() pci_bridge_drv pci_0:0.0: set_state_simple op missing drivers/core/device.c:184- device_bind_common() Bound device nvme#0 to pci_0:0.0 U-Boot> pci DEBUG.driver-model,drivers/core/uclass.c:338-uclass_find_device_by_seq() 0 DEBUG.driver-model,drivers/core/uclass.c:346-uclass_find_device_by_seq() - 0 'pcie@7d50' DEBUG.driver-model,drivers/core/uclass.c:349-uclass_find_device_by_seq() - found BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x14e4 0x2711 Bridge device 0x04 DEBUG.driver-model,drivers/core/uclass.c:338-uclass_find_device_by_seq() 1 DEBUG.driver-model,drivers/core/uclass.c:346-uclass_find_device_by_seq() - 0 'pcie@7d50' DEBUG.driver-model,drivers/core/uclass.c:346-uclass_find_device_by_seq() - 1 'pci_0:0.0' DEBUG.driver-model,drivers/core/uclass.c:349-uclass_find_device_by_seq() - found 01.00.00 0x1e0f 0x0001 Mass storage controller 0x08 DEBUG.driver-model,drivers/core/uclass.c:338-uclass_find_device_by_seq() 2 DEBUG.driver-model,drivers/core/uclass.c:346-uclass_find_device_by_seq() - 0 'pcie@7d50' DEBUG.driver-model,drivers/core/uclass.c:346-uclass_find_device_by_seq() - 1 'pci_0:0.0' DEBUG.driver-model,drivers/core/uclass.c:353-uclass_find_device_by_seq() - not found It should be pci_1:0.0 I think On Thu, Feb 9, 2023 at 11:22 AM Ignatius Rivaldi wrote: > Hi all, > > I'm using U-boot 2022.07 from Yocto Langdale distribution, with the > following NVMe related kconfigs manually enabled through menuconfig: > > CONFIG_NVME > CONFIG_NVME_PCI > CONFIG_CMD_NVME > > and logging turned into max > > The SSD is Kioxia SSD, and it works with Pi 4 bootloader as I can boot > Raspberry Pi OS from the NVMe drive. > > U boot is installed in the fat32 partition in the NVMe SSD for this Yocto > poky build. > > When I boot to U boot prompt, I can see that the SSD is detected by pci > U-Boot> pci long > 0 > - 0 'pcie@7d50' > - found > > Found PCI device 00.00.00: > vendor ID = 0x14e4 > device ID = 0x2711 > command register ID = 0x0006 > status register = 0x0010 > revision ID = 0x20 > class code = 0x06 (Bridge device) > sub class code = 0x04 > programming interface = 0x00 > cache line = 0x08 > latency time =0x00 > header type = 0x01 > BIST =0x00 > base address 0 = 0x > base address 1 = 0x > primary bus number = 0x00 > secondary bus number =0x01 > subordinate bus number = 0x01 > secondary latency timer = 0x00 > IO base = 0x00 > IO limit =0x00 > secondary status =0x > memory base = 0xc000 > memory limit =0xc000 > prefetch memory base =0xfff1 > prefetch memory limit = 0x0001 > prefetch memory base upper = 0x > prefetch memory limit upper = 0x > IO base upper 16 bits = 0x > IO limit upper 16 bits = 0x > expansion ROM base address = 0x > interrupt line = 0x00 > interrupt pin = 0x01 > bridge control = 0x > 1 > - 0 'pcie@7d50' > - 1 'pci_0:0.0' > - found > > Found PCI device 01.00.00: > vendor ID = 0x1e0f > device ID = 0x0001 > command register ID = 0x0006 > status register = 0x0010 > revision ID = 0x00 > class code = 0x01 (Mass storage controller) > sub class code = 0x08 > programming interface = 0x02 > cache line = 0x08 > latency time =0x00 > header type = 0x00 > BIST =0x00 > base address 0 = 0xc004 > base address 1 = 0x > base address 2 = 0x > base address 3 = 0x > base address 4 = 0x > base address 5 = 0x > cardBus CIS pointer = 0x > sub system vendor ID =0x1e0f > sub system ID = 0x0001 > expansion ROM base address
RE: [PATCH v2 1/2] env: mmc: Clean up macro usage
> -Original Message-
> From: U-Boot On Behalf Of Marek Vasut
> Sent: Thursday, February 9, 2023 9:30 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Patrice Chotard
> ; Patrick Delaunay
> ; Tom Rini
> Subject: [PATCH v2 1/2] env: mmc: Clean up macro usage
>
> Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of
> mix of ifdef.
>
> Signed-off-by: Marek Vasut
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Cc: Patrice Chotard
> Cc: Patrick Delaunay
> Cc: Tom Rini
> ---
> V2: Replace CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) with
> IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)
> ---
> env/mmc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/env/mmc.c b/env/mmc.c
> index 5b01f657a7a..d51a5579128 100644
> --- a/env/mmc.c
> +++ b/env/mmc.c
> @@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
>
> if (str && !strncmp((const char *)info.name, str,
> sizeof(info.name)))
> break;
> -#ifdef CONFIG_PARTITION_TYPE_GUID
> - if (!str) {
> + if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && !str) {
> const efi_guid_t env_guid =
> PARTITION_U_BOOT_ENVIRONMENT;
> efi_guid_t type_guid;
>
> @@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str,
> int copy, s64 *val)
> if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
> break;
> }
> -#endif
> }
>
> /* round up to info.blksz */
> --
> 2.39.1
RE: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
Hi,
> -Original Message-
> From: U-Boot On Behalf Of Henrik Grimler
> Sent: Thursday, February 9, 2023 4:04 AM
> To: jo...@diskos.nl; jh80.ch...@gmail.com; andy...@sony.com;
> s...@chromium.org;
> m.szyprow...@samsung.com; u-boot@lists.denx.de;
> ~postmarketos/upstream...@lists.sr.ht
> Cc: Henrik Grimler
> Subject: [PATCH 1/2] Revert "mmc: s5p_sdhci: unset the SDHCI_QUIRK_BROKEN_R1B"
>
> This reverts commit a034ec06ff1d558bbe11d5ee05edbb4de3ee2215.
>
> Commit 4a3ea75de4c5 ("Revert "mmc: sdhci: set to INT_DATA_END when
> there are data"") reverted the alternative fix that was added for
> Exynos 4 devices, causing an error when trying to boot from an sdcard:
>
> <...>
> Loading Environment from MMC... sdhci_send_command: Timeout for status
> update!
> mmc fail to send stop cmd
> <...>
Thanks for sharing issue.
I will check this on Exynos Board. Frankly, I hope not to re-add QUIRK.
Because it was verified that it was working fine without SDHCI_QUIKR_BROKEN_RIB.
Best Regards,
Jaehoon Chung
>
> Re-add the quirk to allow booting from sdcards again.
>
> Signed-off-by: Henrik Grimler
> ---
> drivers/mmc/s5p_sdhci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/s5p_sdhci.c b/drivers/mmc/s5p_sdhci.c
> index dee84263c3fd..3b74feae68c7 100644
> --- a/drivers/mmc/s5p_sdhci.c
> +++ b/drivers/mmc/s5p_sdhci.c
> @@ -90,7 +90,7 @@ static int s5p_sdhci_core_init(struct sdhci_host *host)
> host->name = S5P_NAME;
>
> host->quirks = SDHCI_QUIRK_NO_HISPD_BIT | SDHCI_QUIRK_BROKEN_VOLTAGE |
> - SDHCI_QUIRK_32BIT_DMA_ADDR |
> + SDHCI_QUIRK_BROKEN_R1B | SDHCI_QUIRK_32BIT_DMA_ADDR |
> SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_USE_WIDE8;
> host->max_clk = 5200;
> host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
> --
> 2.30.2
Re: [PATCH v2 119/169] Correct SPL use of PCI_PNP
On Sun, Feb 05, 2023 at 03:40:28PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_PCI_PNP defined in Kconfig > > Signed-off-by: Simon Glass On x86, this is used to avoid the code in SPL/TPL. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/2] semihosting: use assembly conduit functions
On 2/7/23 10:21, Andre Przywara wrote: > Hi, > > to trigger the actual semihosting action in the debugger, we used some > carefully constructed inline assembly sequence. This was motivated by > the trigger being really just a single instruction, so originally this > could be neatly inlined by the compiler. > However we now have a separate function anyway, so inlining is no longer > happening. On top of that the inline assembly was really fragile and > hard to read. > > To clean that up, just use actual assembly functions, which does away > with all the tricks to force the compiler into submission. > Patch 1 is for ARM, patch 2 for RISC-V. > Briefly tested on arm and aarch64 QEMU, and on an ARMv8 fastmodel, plus > compile-tested for RISC-V. Please test it on your system! > > Cheers, > Andre > > P.S. This idea came up before, but I don't remember if patches were > floating around already. If there were, apologies for my ignorance, and > I will be all too happy to use those patches instead of mine here, just > point me to them. > > Andre Przywara (2): > arm: semihosting: replace inline assembly with assembly file > riscv: semihosting: replace inline assembly with assembly file > > arch/arm/lib/semihosting.S | 31 > arch/arm/lib/semihosting.c | 47 > arch/riscv/lib/semihosting.S | 22 + > arch/riscv/lib/semihosting.c | 24 -- > 4 files changed, 53 insertions(+), 71 deletions(-) > create mode 100644 arch/arm/lib/semihosting.S > delete mode 100644 arch/arm/lib/semihosting.c > create mode 100644 arch/riscv/lib/semihosting.S > delete mode 100644 arch/riscv/lib/semihosting.c > I would like to test this, but I don't think I'll have time for a bit. --Sean
Re: [PATCH 2/2] riscv: semihosting: replace inline assembly with assembly file
On 2/7/23 10:21, Andre Przywara wrote:
> So far we used inline assembly to inject the actual instruction that
> triggers the semihosting service. While this sounds elegant, as it's
> really only about a few instructions, it has some serious downsides:
> - We need some barriers in place to force the compiler to issue writes
> to a data structure before issuing the trap instruction.
> - We need to convince the compiler to actually fill the structures that
> we use pointers to.
> - We need a memory clobber to avoid the compiler caching the data in
> those structures, when semihosting writes data back.
> - We need register arguments to make sure the function ID and the
> pointer land in the right registers.
>
> This is all doable, but fragile and somewhat cumbersome. Since we now
> have a separate function in an extra file anyway, we can do away with
> all the magic and just write that in an actual assembler.
> This is much more readable and robust.
>
> Signed-off-by: Andre Przywara
> ---
> arch/riscv/lib/semihosting.S | 22 ++
> arch/riscv/lib/semihosting.c | 24
> 2 files changed, 22 insertions(+), 24 deletions(-)
> create mode 100644 arch/riscv/lib/semihosting.S
> delete mode 100644 arch/riscv/lib/semihosting.c
>
> diff --git a/arch/riscv/lib/semihosting.S b/arch/riscv/lib/semihosting.S
> new file mode 100644
> index 000..5fff485b875
> --- /dev/null
> +++ b/arch/riscv/lib/semihosting.S
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2022 Ventana Micro Systems Inc.
> + */
> +
> +#include
> +#include
> +
> +.pushsection .text.smh_trap, "ax"
> +ENTRY(smh_trap)
> + .align 2
> + .option push
> + .option norvc /* semihosting sequence must be 32-bit wide */
> +
> + slli zero, zero, 0x1f /* Entry NOP to identify semihosting */
> + ebreak
> + srai zero, zero, 7 /* NOP encoding of semihosting call number */
> + .option pop
> +
> + ret
> +ENDPROC(smh_trap)
> +.popsection
> diff --git a/arch/riscv/lib/semihosting.c b/arch/riscv/lib/semihosting.c
> deleted file mode 100644
> index d6593b02a6f..000
> --- a/arch/riscv/lib/semihosting.c
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2022 Ventana Micro Systems Inc.
> - */
> -
> -#include
> -
> -long smh_trap(int sysnum, void *addr)
> -{
> - register int ret asm ("a0") = sysnum;
> - register void *param0 asm ("a1") = addr;
> -
> - asm volatile (".align 4\n"
> - ".option push\n"
> - ".option norvc\n"
> -
> - "slli zero, zero, 0x1f\n"
> - "ebreak\n"
> - "srai zero, zero, 7\n"
> - ".option pop\n"
> - : "+r" (ret) : "r" (param0) : "memory");
> -
> - return ret;
> -}
Reviewed-by: Sean Anderson
Re: [PATCH 1/2] arm: semihosting: replace inline assembly with assembly file
On 2/7/23 10:21, Andre Przywara wrote:
> So far we used inline assembly to inject the actual instruction that
> triggers the semihosting service. While this sounds elegant, as it's
> really only about one instruction, it has some serious downsides:
> - We need some barriers in place to force the compiler to issue writes
> to a data structure before issuing the trap instruction.
> - We need to convince the compiler to actually fill the structures that
> we use pointers to.
> - We need a memory clobber to avoid the compiler caching the data in
> those structures, when semihosting writes data back.
> - We need register arguments to make sure the function ID and the
> pointer land in the right registers.
>
> This is all doable, but fragile and somewhat cumbersome. Since we now
> have a separate function in an extra file anyway, we can do away with
> all the magic and just write that in an actual assembly file.
> This is much more readable and robust.
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm/lib/semihosting.S | 31 +
> arch/arm/lib/semihosting.c | 47 --
> 2 files changed, 31 insertions(+), 47 deletions(-)
> create mode 100644 arch/arm/lib/semihosting.S
> delete mode 100644 arch/arm/lib/semihosting.c
>
> diff --git a/arch/arm/lib/semihosting.S b/arch/arm/lib/semihosting.S
> new file mode 100644
> index 000..393aade94a5
> --- /dev/null
> +++ b/arch/arm/lib/semihosting.S
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * (C) 2022 Arm Ltd.
> + */
> +
> +#include
> +#include
> +#include
> +
> +.pushsection .text.smh_trap, "ax"
> +/* long smh_trap(unsigned int sysnum, void *addr); */
> +ENTRY(smh_trap)
> +
> +#if defined(CONFIG_ARM64)
> + hlt #0xf000
> +#elif defined(CONFIG_CPU_V7M)
> + bkpt#0xab
> +#elif defined(CONFIG_SYS_THUMB_BUILD)
> + svc #0xab
> +#else
> + svc #0x123456
> +#endif
> +
> +#if defined(CONFIG_ARM64)
> + ret
> +#else
> + bx lr
> +#endif
> +
> +ENDPROC(smh_trap)
> +.popsection
> diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
> deleted file mode 100644
> index 7b7669bed06..000
> --- a/arch/arm/lib/semihosting.c
> +++ /dev/null
> @@ -1,47 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2022 Sean Anderson
> - * Copyright 2014 Broadcom Corporation
> - */
> -
> -#include
> -
> -/*
> - * Macro to force the compiler to *populate* memory (for an array or struct)
> - * before passing the pointer to an inline assembly call.
> - */
> -#define USE_PTR(ptr) *(const char (*)[]) (ptr)
> -
> -#if defined(CONFIG_ARM64)
> - #define SMH_TRAP "hlt #0xf000"
> -#elif defined(CONFIG_CPU_V7M)
> - #define SMH_TRAP "bkpt #0xAB"
> -#elif defined(CONFIG_SYS_THUMB_BUILD)
> - #define SMH_TRAP "svc #0xab"
> -#else
> - #define SMH_TRAP "svc #0x123456"
> -#endif
> -
> -/*
> - * Call the handler
> - */
> -long smh_trap(unsigned int sysnum, void *addr)
> -{
> - register long result asm("r0");
> - register void *_addr asm("r1") = addr;
> -
> - /*
> - * We need a memory clobber (aka compiler barrier) for two reasons:
> - * - The compiler needs to populate any data structures pointed to
> - * by "addr" *before* the trap instruction is called.
> - * - At least the SYSREAD function puts the result into memory pointed
> - * to by "addr", so the compiler must not use a cached version of
> - * the previous content, after the call has finished.
> - */
> - asm volatile (SMH_TRAP
> - : "=r" (result)
> - : "0"(sysnum), "r"(USE_PTR(_addr))
> - : "memory");
> -
> - return result;
> -}
Reviewed-by: Sean Anderson
[PATCH] arm: mvebu: Add support for Synology DS116 (Armada 385)
Synology DS116 is a NAS based on Marvell Armada 385 SoC.
Board Specification:
- Marvel MV88F6820 Dual Core at 1.8GHz
- 1 GiB DDR3 RAM
- 8MB Macronix mx25l6405d SPI flash
- I2C
- 2x USB 3.0
- 1x GBE LAN port (PHY: Marvell 88E1510)
- 1x SATA (6 Gbps)
- 3x LED
- PIC16F1829 (connected to uart1)
- GPIO fan
- serial console
Note that this patch depends on the add-support for Thecus N2350 patch:
https://patchwork.ozlabs.org/project/uboot/patch/20230201231306.7010-1-mibo...@gmail.com/
Signed-off-by: Tony Dinh
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/armada-385-synology-ds116.dts | 291 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/Synology/ds116/MAINTAINERS | 7 +
board/Synology/ds116/Makefile | 6 +
board/Synology/ds116/ds116.c | 135 ++
configs/ds116_defconfig| 92 +++
include/configs/ds116.h| 56
8 files changed, 595 insertions(+)
create mode 100644 arch/arm/dts/armada-385-synology-ds116.dts
create mode 100644 board/Synology/ds116/MAINTAINERS
create mode 100644 board/Synology/ds116/Makefile
create mode 100644 board/Synology/ds116/ds116.c
create mode 100644 configs/ds116_defconfig
create mode 100644 include/configs/ds116.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dee298228f..9d647b9639 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -247,6 +247,7 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
armada-385-atl-x530.dtb \
armada-385-atl-x530DP.dtb \
armada-385-db-88f6820-amc.dtb \
+ armada-385-synology-ds116.dtb \
armada-385-thecus-n2350.dtb \
armada-385-turris-omnia.dtb \
armada-388-clearfog.dtb \
diff --git a/arch/arm/dts/armada-385-synology-ds116.dts
b/arch/arm/dts/armada-385-synology-ds116.dts
new file mode 100644
index 00..82a0373f7f
--- /dev/null
+++ b/arch/arm/dts/armada-385-synology-ds116.dts
@@ -0,0 +1,291 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Device Tree file for Synology DS116 NAS
+ *
+ * Copyright (C) 2017 Willy Tarreau
+ */
+
+/dts-v1/;
+#include "armada-385.dtsi"
+#include
+
+/ {
+ model = "Synology DS116";
+ compatible = "marvell,a385-gp", "marvell,armada385",
"marvell,armada380";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x4000>; /* 1 GB */
+ };
+
+ soc {
+ ranges = ;
+
+ internal-regs {
+ i2c@11000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ status = "okay";
+ clock-frequency = <10>;
+
+ eeprom@57 {
+ compatible = "atmel,24c64";
+ reg = <0x57>;
+ };
+ };
+
+ serial@12000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins>;
+ status = "okay";
+ };
+
+ serial@12100 {
+ /* A PIC16F1829 is connected to uart1 at 9600
bps,
+* and takes single-character orders :
+* "1" : power off // already handled by the
poweroff node
+* "2" : short beep
+* "3" : long beep
+* "4" : turn the power LED ON
+* "5" : flash the power LED
+* "6" : turn the power LED OFF
+* "7" : turn the status LED OFF
+* "8" : turn the status LED ON
+* "9" : flash the status LED
+* "A" : flash the motherboard LED (D8)
+* "B" : turn the motherboard LED OFF
+* "C" : hard reset
+*/
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart1_pins>;
+ status = "okay";
+ };
+
+ poweroff@12100 {
+ compatible = "synology,power-off";
+ reg = <0x12100 0x100>;
+ clocks = <&coreclk 0>;
+ };
+
+ ethernet@7 {
+ pinctrl-names = "de
[PATCH v2 08/10] net: dwc_eth_qos: Add board_interface_eth_init() for i.MX8M Plus
Implement common board_interface_eth_init() and call it from the DWMAC
driver to configure IOMUXC GPR[1] register according to the PHY mode
obtained from DT. This supports all three interface modes supported by
the i.MX8M Plus DWMAC and supersedes current board-side configuration
of the same IOMUX GPR[1] duplicated in the board files.
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: - Add RB from Ramon
- Handle RGMII_ID/RGMII_RXID/RGMII_TXID just like plain RGMII
---
arch/arm/include/asm/arch-imx8m/imx-regs.h | 8 -
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 40 ++
drivers/net/dwc_eth_qos_imx.c | 4 +++
3 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h
b/arch/arm/include/asm/arch-imx8m/imx-regs.h
index 1559bf6d218..1818b459fa6 100644
--- a/arch/arm/include/asm/arch-imx8m/imx-regs.h
+++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h
@@ -89,7 +89,13 @@
#define DDRC_IPS_BASE_ADDR(X) (0x3d40 + ((X) * 0x200))
#define DDR_CSD1_BASE_ADDR 0x4000
-#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK 0x7
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_RGMII_EN BIT(21)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_TX_CLK_SELBIT(20)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_GEN_ENBIT(19)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK GENMASK(18, 16)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MII (0 << 16)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_RGMII(1 << 16)
+#define IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_RMII (4 << 16)
#define FEC_QUIRK_ENET_MAC
#ifdef CONFIG_ARMV8_PSCI /* Final jump location */
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 494bfbedc8c..6d3539ec982 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -872,6 +873,45 @@ int set_clk_eqos(enum enet_freq type)
return 0;
}
+
+int board_interface_eth_init(struct udevice *dev, phy_interface_t
interface_type)
+{
+ struct iomuxc_gpr_base_regs *gpr =
+ (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
+
+ clrbits_le32(&gpr->gpr[1],
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_RGMII_EN |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_TX_CLK_SEL |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_GEN_EN);
+
+ switch (interface_type) {
+ case PHY_INTERFACE_MODE_MII:
+ setbits_le32(&gpr->gpr[1],
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_GEN_EN |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MII);
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ setbits_le32(&gpr->gpr[1],
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_TX_CLK_SEL |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_GEN_EN |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_RMII);
+ break;
+ case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
+ setbits_le32(&gpr->gpr[1],
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_RGMII_EN |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_CLK_GEN_EN |
+IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_RGMII);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
#endif
#ifdef CONFIG_FEC_MXC
diff --git a/drivers/net/dwc_eth_qos_imx.c b/drivers/net/dwc_eth_qos_imx.c
index fb4e6d38e24..f565a5fd21a 100644
--- a/drivers/net/dwc_eth_qos_imx.c
+++ b/drivers/net/dwc_eth_qos_imx.c
@@ -55,6 +55,10 @@ static int eqos_probe_resources_imx(struct udevice *dev)
return -EINVAL;
}
+ ret = board_interface_eth_init(dev, interface);
+ if (ret)
+ return -EINVAL;
+
eqos->max_speed = dev_read_u32_default(dev, "max-speed", 0);
ret = clk_get_by_name(dev, "stmmaceth", &eqos->clk_master_bus);
--
2.39.1
[PATCH v2 09/10] arm64: dts: imx8mp: Drop EQoS clock workaround
The assigned-clock no longer have to be dropped, the clock are now
defined in clk-imx8mp.c and used by DWMAC driver to configure the
DWMAC clock. Drop the workarounds from U-Boot specific DT extras.
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: No change
---
arch/arm/dts/imx8mp-dhcom-u-boot.dtsi| 6 --
arch/arm/dts/imx8mp-evk-u-boot.dtsi | 6 --
arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi | 6 --
arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi| 6 --
arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi | 6 --
5 files changed, 30 deletions(-)
diff --git a/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
index ae838caebcf..ea6ab9f2e17 100644
--- a/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-dhcom-u-boot.dtsi
@@ -33,12 +33,6 @@
u-boot,dm-spl;
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
&gpio1 {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
index f43eb6238d0..cd0fb815c79 100644
--- a/arch/arm/dts/imx8mp-evk-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-evk-u-boot.dtsi
@@ -131,12 +131,6 @@
u-boot,dm-spl;
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
ðphy0 {
reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <15000>;
diff --git a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
index 342c523b0c5..3e48cf8ec5c 100644
--- a/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-icore-mx8mp-edimm2.2-u-boot.dtsi
@@ -130,12 +130,6 @@
u-boot,dm-spl;
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
ðphy0 {
reset-gpios = <&gpio4 22 GPIO_ACTIVE_LOW>;
reset-delay-us = <15000>;
diff --git a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
index d8721124526..849950fe026 100644
--- a/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-venice-gw74xx-u-boot.dtsi
@@ -20,12 +20,6 @@
};
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
ðphy0 {
reset-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>;
reset-delay-us = <1000>;
diff --git a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
index 8a4cdc717d2..5f021d17230 100644
--- a/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
+++ b/arch/arm/dts/imx8mp-verdin-wifi-dev-u-boot.dtsi
@@ -39,12 +39,6 @@
u-boot,dm-spl;
};
-&eqos {
- /delete-property/ assigned-clocks;
- /delete-property/ assigned-clock-parents;
- /delete-property/ assigned-clock-rates;
-};
-
&gpio1 {
u-boot,dm-spl;
};
--
2.39.1
[PATCH v2 04/10] net: dwc_eth_qos: Staticize eqos_inval_buffer_tegra186()
This function is only used within the driver, staticize it.
Fixes: 149e80f74b6 ("net: dwc_eth_qos: public some functions")
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: - New patch
---
drivers/net/dwc_eth_qos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 3b62b283c45..bdf0f2e6812 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -108,7 +108,7 @@ void eqos_flush_desc_generic(void *desc)
flush_dcache_range(start, end);
}
-void eqos_inval_buffer_tegra186(void *buf, size_t size)
+static void eqos_inval_buffer_tegra186(void *buf, size_t size)
{
unsigned long start = (unsigned long)buf & ~(ARCH_DMA_MINALIGN - 1);
unsigned long end = ALIGN(start + size, ARCH_DMA_MINALIGN);
--
2.39.1
[PATCH v2 01/10] clk: imx8mp: Add EQoS MAC clock
Add clock for the DWMAC EQoS block. This is used among other things
to configure the MII clock via DM CLK.
Acked-by: Sean Anderson
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: Add AB from Sean
---
drivers/clk/imx/clk-imx8mp.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/clk/imx/clk-imx8mp.c b/drivers/clk/imx/clk-imx8mp.c
index ffbc1d1ba9f..6dda0403e35 100644
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -70,6 +70,14 @@ static const char *imx8mp_i2c6_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
"sys_pll3_out", "audio_pll1_out",
"video_pll1_out",
"audio_pll2_out", "sys_pll1_133m", };
+static const char *imx8mp_enet_qos_sels[] = {"clock-osc-24m", "sys_pll2_125m",
"sys_pll2_50m",
+"sys_pll2_100m", "sys_pll1_160m",
"audio_pll1_out",
+"video_pll1_out", "clk_ext4", };
+
+static const char *imx8mp_enet_qos_timer_sels[] = {"clock-osc-24m",
"sys_pll2_100m", "audio_pll1_out",
+ "clk_ext1", "clk_ext2",
"clk_ext3",
+ "clk_ext4",
"video_pll1_out", };
+
static const char *imx8mp_usdhc1_sels[] = {"clock-osc-24m", "sys_pll1_400m",
"sys_pll1_800m",
"sys_pll2_500m", "sys_pll3_out",
"sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
@@ -250,6 +258,8 @@ static int imx8mp_clk_probe(struct udevice *dev)
clk_dm(IMX8MP_CLK_DRAM_APB, imx8m_clk_composite_critical("dram_apb",
imx8mp_dram_apb_sels, base + 0xa080));
clk_dm(IMX8MP_CLK_I2C5, imx8m_clk_composite("i2c5", imx8mp_i2c5_sels,
base + 0xa480));
clk_dm(IMX8MP_CLK_I2C6, imx8m_clk_composite("i2c6", imx8mp_i2c6_sels,
base + 0xa500));
+ clk_dm(IMX8MP_CLK_ENET_QOS, imx8m_clk_composite("enet_qos",
imx8mp_enet_qos_sels, base + 0xa880));
+ clk_dm(IMX8MP_CLK_ENET_QOS_TIMER, imx8m_clk_composite("enet_qos_timer",
imx8mp_enet_qos_timer_sels, base + 0xa900));
clk_dm(IMX8MP_CLK_ENET_REF, imx8m_clk_composite("enet_ref",
imx8mp_enet_ref_sels, base + 0xa980));
clk_dm(IMX8MP_CLK_ENET_TIMER, imx8m_clk_composite("enet_timer",
imx8mp_enet_timer_sels, base + 0xaa00));
clk_dm(IMX8MP_CLK_ENET_PHY_REF, imx8m_clk_composite("enet_phy_ref",
imx8mp_enet_phy_ref_sels, base + 0xaa80));
@@ -292,10 +302,13 @@ static int imx8mp_clk_probe(struct udevice *dev)
clk_dm(IMX8MP_CLK_I2C2_ROOT, imx_clk_gate4("i2c2_root_clk", "i2c2",
base + 0x4180, 0));
clk_dm(IMX8MP_CLK_I2C3_ROOT, imx_clk_gate4("i2c3_root_clk", "i2c3",
base + 0x4190, 0));
clk_dm(IMX8MP_CLK_I2C4_ROOT, imx_clk_gate4("i2c4_root_clk", "i2c4",
base + 0x41a0, 0));
+ clk_dm(IMX8MP_CLK_QOS_ROOT, imx_clk_gate4("qos_root_clk", "ipg_root",
base + 0x42c0, 0));
+ clk_dm(IMX8MP_CLK_QOS_ENET_ROOT, imx_clk_gate4("qos_enet_root_clk",
"ipg_root", base + 0x42e0, 0));
clk_dm(IMX8MP_CLK_QSPI_ROOT, imx_clk_gate4("qspi_root_clk", "qspi",
base + 0x42f0, 0));
clk_dm(IMX8MP_CLK_I2C5_ROOT, imx_clk_gate2("i2c5_root_clk", "i2c5",
base + 0x4330, 0));
clk_dm(IMX8MP_CLK_I2C6_ROOT, imx_clk_gate2("i2c6_root_clk", "i2c6",
base + 0x4340, 0));
clk_dm(IMX8MP_CLK_SIM_ENET_ROOT, imx_clk_gate4("sim_enet_root_clk",
"enet_axi", base + 0x4400, 0));
+ clk_dm(IMX8MP_CLK_ENET_QOS_ROOT, imx_clk_gate4("enet_qos_root_clk",
"sim_enet_root_clk", base + 0x43b0, 0));
clk_dm(IMX8MP_CLK_UART1_ROOT, imx_clk_gate4("uart1_root_clk", "uart1",
base + 0x4490, 0));
clk_dm(IMX8MP_CLK_UART2_ROOT, imx_clk_gate4("uart2_root_clk", "uart2",
base + 0x44a0, 0));
clk_dm(IMX8MP_CLK_UART3_ROOT, imx_clk_gate4("uart3_root_clk", "uart3",
base + 0x44b0, 0));
--
2.39.1
[PATCH v2 10/10] arm64: imx8mp: Drop EQoS GPR[1] board workaround
The EQoS interface mode is now configured in common board_interface_eth_init()
and called by EQoS MAC driver when appropriate. Drop the board side duplicates
if the same functionality.
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: Fix the advantech board build
---
.../imx8mp_rsb3720a1/imx8mp_rsb3720a1.c | 17 +
.../dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c | 14 --
board/engicam/imx8mp/icore_mx8mp.c | 16
board/freescale/imx8mp_evk/imx8mp_evk.c | 17 -
board/gateworks/venice/venice.c | 15 ---
board/msc/sm2s_imx8mp/sm2s_imx8mp.c | 15 ---
board/toradex/verdin-imx8mp/verdin-imx8mp.c | 16
7 files changed, 1 insertion(+), 109 deletions(-)
diff --git a/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
b/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
index aa9687f7a9d..56068b0c01e 100644
--- a/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
+++ b/board/advantech/imx8mp_rsb3720a1/imx8mp_rsb3720a1.c
@@ -113,7 +113,7 @@ static const iomux_v3_cfg_t eqos_rst_pads[] = {
MX8MP_PAD_SAI2_RXC__GPIO4_IO22 | MUX_PAD_CTRL(NO_PAD_CTRL),
};
-static void setup_iomux_eqos(void)
+static void setup_eqos(void)
{
imx_iomux_v3_setup_multiple_pads(eqos_rst_pads,
ARRAY_SIZE(eqos_rst_pads));
@@ -124,21 +124,6 @@ static void setup_iomux_eqos(void)
gpio_direction_output(EQOS_RST_PAD, 1);
mdelay(100);
}
-
-static int setup_eqos(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
- setup_iomux_eqos();
-
- /* set INTF as RGMII, enable RGMII TXC clock */
- clrsetbits_le32(&gpr->gpr[1],
- IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK, BIT(16));
- setbits_le32(&gpr->gpr[1], BIT(19) | BIT(21));
-
- return set_clk_eqos(ENET_125MHZ);
-}
#endif /* CONFIG_DWC_ETH_QOS */
int board_phy_config(struct phy_device *phydev)
diff --git a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
index 9d8e19d994a..cb9973900bd 100644
--- a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
+++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
@@ -37,19 +37,6 @@ int board_phys_sdram_size(phys_size_t *size)
return 0;
}
-static void setup_eqos(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
- /* Set INTF as RGMII, enable RGMII TXC clock. */
- clrsetbits_le32(&gpr->gpr[1],
- IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK, BIT(16));
- setbits_le32(&gpr->gpr[1], BIT(19) | BIT(21));
-
- set_clk_eqos(ENET_125MHZ);
-}
-
static void setup_fec(void)
{
struct iomuxc_gpr_base_regs *gpr =
@@ -127,7 +114,6 @@ int dh_setup_mac_address(void)
int board_init(void)
{
- setup_eqos();
setup_fec();
return 0;
}
diff --git a/board/engicam/imx8mp/icore_mx8mp.c
b/board/engicam/imx8mp/icore_mx8mp.c
index b309a12df08..b80513c7957 100644
--- a/board/engicam/imx8mp/icore_mx8mp.c
+++ b/board/engicam/imx8mp/icore_mx8mp.c
@@ -34,19 +34,6 @@ static void setup_fec(void)
setbits_le32(&gpr->gpr[1], BIT(22));
}
-static int setup_eqos(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
- /* set INTF as RGMII, enable RGMII TXC clock */
- clrsetbits_le32(&gpr->gpr[1],
- IOMUXC_GPR_GPR1_GPR_ENET_QOS_INTF_SEL_MASK, BIT(16));
- setbits_le32(&gpr->gpr[1], BIT(19) | BIT(21));
-
- return set_clk_eqos(ENET_125MHZ);
-}
-
#if CONFIG_IS_ENABLED(NET)
int board_phy_config(struct phy_device *phydev)
{
@@ -61,9 +48,6 @@ int board_init(void)
if (CONFIG_IS_ENABLED(FEC_MXC))
setup_fec();
- if (CONFIG_IS_ENABLED(DWC_ETH_QOS))
- setup_eqos();
-
return 0;
}
diff --git a/board/freescale/imx8mp_evk/imx8mp_evk.c
b/board/freescale/imx8mp_evk/imx8mp_evk.c
index 8971a827df3..0fefdafadfa 100644
--- a/board/freescale/imx8mp_evk/imx8mp_evk.c
+++ b/board/freescale/imx8mp_evk/imx8mp_evk.c
@@ -29,19 +29,6 @@ static void setup_fec(void)
setbits_le32(&gpr->gpr[1], BIT(22));
}
-static int setup_eqos(void)
-{
- struct iomuxc_gpr_base_regs *gpr =
- (struct iomuxc_gpr_base_regs *)IOMUXC_GPR_BASE_ADDR;
-
- /* set INTF as RGMII, enable RGMII TXC clock */
- clrsetbits_le32(&gpr->gpr[1],
- I
[PATCH v2 07/10] net: dwc_eth_qos: Add i.MX8M Plus RMII support
With DM clock support in place, it is easy to add RMII support into the
MAC driver. The RMII cannot operate at 1000 Mbps and at 100 and 10 Mbps
the clock frequency is 50 MHz and 5 MHz instead of 25 MHz and 2.5 MHz.
The board DT requires the following adjustments to EQoS node:
phy-mode = "rmii";
assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_266M>,
<&clk IMX8MP_SYS_PLL2_100M>,
<&clk IMX8MP_SYS_PLL2_50M>;
assigned-clock-rates = <0>, <1>, <5000>;
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: Add RB from Ramon
---
drivers/net/dwc_eth_qos_imx.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/net/dwc_eth_qos_imx.c b/drivers/net/dwc_eth_qos_imx.c
index f5f3f2099f0..fb4e6d38e24 100644
--- a/drivers/net/dwc_eth_qos_imx.c
+++ b/drivers/net/dwc_eth_qos_imx.c
@@ -179,21 +179,25 @@ static int eqos_set_tx_clk_speed_imx(struct udevice *dev)
debug("%s(dev=%p):\n", __func__, dev);
- switch (eqos->phy->speed) {
- case SPEED_1000:
- rate = 125 * 1000 * 1000;
- break;
- case SPEED_100:
- rate = 25 * 1000 * 1000;
- break;
- case SPEED_10:
- rate = 2.5 * 1000 * 1000;
- break;
- default:
+ if (eqos->phy->interface == PHY_INTERFACE_MODE_RMII)
+ rate = 5000;/* 5000 kHz = 5 MHz */
+ else
+ rate = 2500;/* 2500 kHz = 2.5 MHz */
+
+ if (eqos->phy->speed == SPEED_1000 &&
+ eqos->phy->interface == PHY_INTERFACE_MODE_RGMII) {
+ rate *= 50; /* Use 50x base rate i.e. 125 MHz */
+ } else if (eqos->phy->speed == SPEED_100) {
+ rate *= 10; /* Use 10x base rate */
+ } else if (eqos->phy->speed == SPEED_10) {
+ rate *= 1; /* Use base rate */
+ } else {
pr_err("invalid speed %d", eqos->phy->speed);
return -EINVAL;
}
+ rate *= 1000; /* clk_set_rate() operates in Hz */
+
ret = clk_set_rate(&eqos->clk_tx, rate);
if (ret < 0) {
pr_err("imx (tx_clk, %lu) failed: %d", rate, ret);
--
2.39.1
[PATCH v2 06/10] net: dwc_eth_qos: Add DM CLK support for i.MX8M Plus
The DWMAC clock in i.MX8M Plus were so far configured via ad-hoc
architecture code. Replace that with DM clock instead. This way,
the driver claims all its required clock, enables and disables
them, and even gets the CSR clock rate and sets the TX clock rate,
without any need of architecture specific register fiddling. Drop
the architecture specific code while at it too.
The adjustment here is modeled after STM32MP15xx clock handling
in this driver.
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: Turn all the pr_err() into dev_dbg()
---
arch/arm/mach-imx/imx8m/clock_imx8mm.c | 41
drivers/net/dwc_eth_qos_imx.c | 131 +++--
2 files changed, 121 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
index 64ad57e9b39..494bfbedc8c 100644
--- a/arch/arm/mach-imx/imx8m/clock_imx8mm.c
+++ b/arch/arm/mach-imx/imx8m/clock_imx8mm.c
@@ -872,47 +872,6 @@ int set_clk_eqos(enum enet_freq type)
return 0;
}
-
-int imx_eqos_txclk_set_rate(ulong rate)
-{
- u32 val;
- u32 eqos_post_div;
-
- /* disable the clock first */
- clock_enable(CCGR_QOS_ETHENET, 0);
- clock_enable(CCGR_SDMA2, 0);
-
- switch (rate) {
- case 12500:
- eqos_post_div = 1;
- break;
- case 2500:
- eqos_post_div = 12500 / 2500;
- break;
- case 250:
- eqos_post_div = 12500 / 250;
- break;
- default:
- return -EINVAL;
- }
-
- clock_get_target_val(ENET_QOS_CLK_ROOT, &val);
- val &= ~(CLK_ROOT_PRE_DIV_MASK | CLK_ROOT_POST_DIV_MASK);
- val |= CLK_ROOT_PRE_DIV(CLK_ROOT_PRE_DIV1) |
- CLK_ROOT_POST_DIV(eqos_post_div - 1);
- clock_set_target_val(ENET_QOS_CLK_ROOT, val);
-
- /* enable clock */
- clock_enable(CCGR_QOS_ETHENET, 1);
- clock_enable(CCGR_SDMA2, 1);
-
- return 0;
-}
-
-u32 imx_get_eqos_csr_clk(void)
-{
- return get_root_clk(ENET_AXI_CLK_ROOT);
-}
#endif
#ifdef CONFIG_FEC_MXC
diff --git a/drivers/net/dwc_eth_qos_imx.c b/drivers/net/dwc_eth_qos_imx.c
index 42cb164ad14..f5f3f2099f0 100644
--- a/drivers/net/dwc_eth_qos_imx.c
+++ b/drivers/net/dwc_eth_qos_imx.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -32,20 +33,18 @@ __weak u32 imx_get_eqos_csr_clk(void)
return 100 * 100;
}
-__weak int imx_eqos_txclk_set_rate(unsigned long rate)
-{
- return 0;
-}
-
static ulong eqos_get_tick_clk_rate_imx(struct udevice *dev)
{
- return imx_get_eqos_csr_clk();
+ struct eqos_priv *eqos = dev_get_priv(dev);
+
+ return clk_get_rate(&eqos->clk_master_bus);
}
static int eqos_probe_resources_imx(struct udevice *dev)
{
struct eqos_priv *eqos = dev_get_priv(dev);
phy_interface_t interface;
+ int ret;
debug("%s(dev=%p):\n", __func__, dev);
@@ -56,6 +55,118 @@ static int eqos_probe_resources_imx(struct udevice *dev)
return -EINVAL;
}
+ eqos->max_speed = dev_read_u32_default(dev, "max-speed", 0);
+
+ ret = clk_get_by_name(dev, "stmmaceth", &eqos->clk_master_bus);
+ if (ret) {
+ dev_dbg(dev, "clk_get_by_name(master_bus) failed: %d", ret);
+ goto err_probe;
+ }
+
+ ret = clk_get_by_name(dev, "ptp_ref", &eqos->clk_ptp_ref);
+ if (ret) {
+ dev_dbg(dev, "clk_get_by_name(ptp_ref) failed: %d", ret);
+ goto err_free_clk_master_bus;
+ }
+
+ ret = clk_get_by_name(dev, "tx", &eqos->clk_tx);
+ if (ret) {
+ dev_dbg(dev, "clk_get_by_name(tx) failed: %d", ret);
+ goto err_free_clk_ptp_ref;
+ }
+
+ ret = clk_get_by_name(dev, "pclk", &eqos->clk_ck);
+ if (ret) {
+ dev_dbg(dev, "clk_get_by_name(pclk) failed: %d", ret);
+ goto err_free_clk_tx;
+ }
+
+ debug("%s: OK\n", __func__);
+ return 0;
+
+err_free_clk_tx:
+ clk_free(&eqos->clk_tx);
+err_free_clk_ptp_ref:
+ clk_free(&eqos->clk_ptp_ref);
+err_free_clk_master_bus:
+ clk_free(&eqos->clk_master_bus);
+err_probe:
+
+ debug("%s: returns %d\n", __func__, ret);
+ return ret;
+}
+
+static int eqos_remove_resources_imx(struct udevice *dev)
+{
+ struct eqos_priv *eqos = dev_get_priv(dev);
+
+ debug("%s(dev=%p):\n", __func__, dev);
+
+ clk_free(&eqos->clk_ck);
+ clk_free(&eqos->clk_tx);
+ clk_free(&eqos->clk_ptp_ref);
+ clk_free(&eqos->clk_master_bus
[PATCH v2 02/10] net: dwc_eth_qos: Drop bogus return after goto
The return is never triggered due to the goto just above it.
Drop it. No functional change.
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: Add RB from Ramon
---
drivers/net/dwc_eth_qos.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index afc47b56ff5..44d05908894 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1373,7 +1373,6 @@ static int eqos_probe_resources_tegra186(struct udevice
*dev)
if (ret) {
pr_err("clk_get_by_name(ptp_ref) failed: %d", ret);
goto err_free_clk_rx;
- return ret;
}
ret = clk_get_by_name(dev, "tx", &eqos->clk_tx);
--
2.39.1
[PATCH v2 03/10] net: dwc_eth_qos: Drop unused dm_gpio_free() on STM32
The dm_gpio_free() is never called, because for stm32, the phy_reset_gpio
pointer is never valid. This is because only tegra186 ever claims the
phy_reset_gpio, all other platforms use the PHY framework to reset the
PHY instead. Drop the dm_gpio_free() and dm_gpio_is_valid().
Reviewed-by: Ramon Fried
Signed-off-by: Marek Vasut
---
Cc: "Ariel D'Alessandro"
Cc: "NXP i.MX U-Boot Team"
Cc: Andrey Zhizhikin
Cc: Fabio Estevam
Cc: Joe Hershberger
Cc: Lukasz Majewski
Cc: Marcel Ziswiler
Cc: Marek Vasut
Cc: Michael Trimarchi
Cc: Peng Fan
Cc: Ramon Fried
Cc: Sean Anderson
Cc: Stefano Babic
Cc: Tim Harvey
Cc: Tommaso Merciai
Cc: u-boot@lists.denx.de
---
V2: - Add RB from Ramon
- Mark eqos variable in eqos_remove_resources_stm32() with __maybe_unused
---
drivers/net/dwc_eth_qos.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c
index 44d05908894..3b62b283c45 100644
--- a/drivers/net/dwc_eth_qos.c
+++ b/drivers/net/dwc_eth_qos.c
@@ -1490,7 +1490,7 @@ static int eqos_remove_resources_tegra186(struct udevice
*dev)
static int eqos_remove_resources_stm32(struct udevice *dev)
{
- struct eqos_priv *eqos = dev_get_priv(dev);
+ struct eqos_priv * __maybe_unused eqos = dev_get_priv(dev);
debug("%s(dev=%p):\n", __func__, dev);
@@ -1502,9 +1502,6 @@ static int eqos_remove_resources_stm32(struct udevice
*dev)
clk_free(&eqos->clk_ck);
#endif
- if (dm_gpio_is_valid(&eqos->phy_reset_gpio))
- dm_gpio_free(dev, &eqos->phy_reset_gpio);
-
debug("%s: OK\n", __func__);
return 0;
}
--
2.39.1
[PATCH v2 05/10] net: dwc_eth_qos: Set DMA_MODE SWR bit to reset the MAC
The driver currently only waits for DMA_MODE SWR bit to clear itself. This is insufficient e.g. on i.MX8M Plus, where the MAC must be reset before IOMUX GPR[1] content is latched into the MAC and used. Without the proper reset, the i.MX8M Plus MAC variant does not take the value in IOMUX GPR[1] into account, which makes it impossible e.g. to switch interface mode from RGMII to any other. Since proper reset is desired in general to put the block into defined state, always assert the DMA_MODE SWR bit before waiting for the bit to clear itself. Reviewed-by: Ramon Fried Signed-off-by: Marek Vasut --- Cc: "Ariel D'Alessandro" Cc: "NXP i.MX U-Boot Team" Cc: Andrey Zhizhikin Cc: Fabio Estevam Cc: Joe Hershberger Cc: Lukasz Majewski Cc: Marcel Ziswiler Cc: Marek Vasut Cc: Michael Trimarchi Cc: Peng Fan Cc: Ramon Fried Cc: Sean Anderson Cc: Stefano Babic Cc: Tim Harvey Cc: Tommaso Merciai Cc: u-boot@lists.denx.de --- V2: Add RB from Ramon --- drivers/net/dwc_eth_qos.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/dwc_eth_qos.c b/drivers/net/dwc_eth_qos.c index bdf0f2e6812..66e3f354b65 100644 --- a/drivers/net/dwc_eth_qos.c +++ b/drivers/net/dwc_eth_qos.c @@ -761,6 +761,12 @@ static int eqos_start(struct udevice *dev) eqos->reg_access_ok = true; + /* +* Assert the SWR first, the actually reset the MAC and to latch in +* e.g. i.MX8M Plus GPR[1] content, which selects interface mode. +*/ + setbits_le32(&eqos->dma_regs->mode, EQOS_DMA_MODE_SWR); + ret = wait_for_bit_le32(&eqos->dma_regs->mode, EQOS_DMA_MODE_SWR, false, eqos->config->swr_wait, false); -- 2.39.1
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
On Thursday 09 February 2023 13:33:23 Tony Dinh wrote: > Hi Stefan, > > On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese wrote: > > > > Hi Tony, > > > > On 2/9/23 04:17, Tony Dinh wrote: > > > Hi Stefan, > > > > > > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh wrote: > > >> > > >> Hi Pali, > > >> > > >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár wrote: > > >>> > > >>> On Thursday 02 February 2023 19:04:45 Pali Rohár wrote: > > On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote: > > > Hi all, > > > > > > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote: > > >> > > >> On Wednesday 01 February 2023 09:17:15 Michael Walle wrote: > > >> When DM_SERIAL is enabled, the device-tree property dm-pre-reloc > > >> is > > >> required to boot over UART with kwboot. Enable this in a Kirkwood > > >> common u-boot dtsi. > > > > > > My (dev) board unfortunately, have a bootloader which can't boot > > > over > > > serial. > > > > This is feature of Marvell BootROM and does not require any > > special from > > Bootloader. So you should be able to boot over UART (if you have > > accessible pins). > > >>> > > >>> I know, but there are known versions ob the bootrom where uart boot > > >>> isn't supported (correctly). > > >> > > >> I heard about it... maybe it is a bug in client software (kwboot)? I > > >> do > > >> not have such board if you are interested in it I could try to send > > >> some > > >> details how to debug it. > > > > > > The Kirkwood SoCs came with different BootROM versions. Version 1.1 > > > cannot be booted over UART, but version 1.2 can. I think there must > > > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug, > > > Dockstar, iConnect boards come with BootROM 1.1. Later version of > > > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel > > > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is > > > the same SoC, eg. 6281, they are actually produced at a different time > > > and have different BootROM versions. > > > > There are always multiple revisions of the same SoC. So it is possible > > that something was broken on first revision of 88F6281 and in next > > revision was updated BootROM with some fixes. Revision is written on > > package label and for Armada SoCs it is available also in some register > > (not sure about Kirkwood). It looks like that there is at least > > revision > > Z0 and revision A0 of some Kirkwood SoC. > > > > If there is a bug in first revisions then it should be documented in > > some Kirkwood Errata document. Unfortunately I have never seen it, it > > is > > not public, so I have no idea. In any case, if somebody has access to > > Marvell documents, interesting are these document numbers: > > > > * MV-S105223-001 - Differences Between the 88F6192, and 88F6281 > > Stepping Z0 and A0 > > * MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata, > > Interface Guidelines, and Restrictions > > * MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional > > Errata, Interface Guidelines, and Restrictions > > > > One of the option how to investigate or debug this issue without > > documentation is to dump both BootROM versions (1.1, 1.2) and compare > > them. Either there is different UART protocol for booting (which needs > > to be implemented) or UART protocol is buggy and needs some workaround > > or it is completely broken and does not work. > > >>> > > >>> BootROM is mapped to 0xF800 address and is 64 kB long. So via U-Boot > > >>> md command it is possible to dump it over console. Or via ext4write > > >>> command store it so ext4 fs on sd card / sata disk. > > >> > > >> Thanks for the info. It will be a while before I can get back to this > > >> BootROM 1.1 vs 1.2 topic. > > >> > > > > > > I have run some more tests, and am quite positive that if the uart0 > > > node exists in the DTS, it must be tagged with dm,pre-reloc. That is > > > consistent with the serial documentation in > > > doc/develop/driver-model/serial-howto.rst. The issue is whether the > > > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag > > > must also be used. > > > > > > To prove my theory, I've modified the Pogo V4 DTS to look exactly like > > > the NSA310S, as far as uart0 is concerned. The NSA310S does not even > > > have a uart0 node! and DM_SERIAL boots fine with this box. With the > > > patch below, the Pogo V4 can be kwboot and run normally. No > > > dm-pre-reloc tag is needed. > > > > > > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts > > > index 5aa4669ae2..227d5ff802 100644 > > > --- a/arch/arm/dts/kirkwood
Re: [PATCH] arm: kirkwood: Enable uart0 dm-pre-reloc for Kirkwood boards
Hi Stefan,
On Wed, Feb 8, 2023 at 11:15 PM Stefan Roese wrote:
>
> Hi Tony,
>
> On 2/9/23 04:17, Tony Dinh wrote:
> > Hi Stefan,
> >
> > On Fri, Feb 3, 2023 at 4:11 PM Tony Dinh wrote:
> >>
> >> Hi Pali,
> >>
> >> On Fri, Feb 3, 2023 at 2:05 PM Pali Rohár wrote:
> >>>
> >>> On Thursday 02 February 2023 19:04:45 Pali Rohár wrote:
> On Wednesday 01 February 2023 13:13:16 Tony Dinh wrote:
> > Hi all,
> >
> > On Wed, Feb 1, 2023 at 11:05 AM Pali Rohár wrote:
> >>
> >> On Wednesday 01 February 2023 09:17:15 Michael Walle wrote:
> >> When DM_SERIAL is enabled, the device-tree property dm-pre-reloc is
> >> required to boot over UART with kwboot. Enable this in a Kirkwood
> >> common u-boot dtsi.
> >
> > My (dev) board unfortunately, have a bootloader which can't boot
> > over
> > serial.
>
> This is feature of Marvell BootROM and does not require any special
> from
> Bootloader. So you should be able to boot over UART (if you have
> accessible pins).
> >>>
> >>> I know, but there are known versions ob the bootrom where uart boot
> >>> isn't supported (correctly).
> >>
> >> I heard about it... maybe it is a bug in client software (kwboot)? I do
> >> not have such board if you are interested in it I could try to send
> >> some
> >> details how to debug it.
> >
> > The Kirkwood SoCs came with different BootROM versions. Version 1.1
> > cannot be booted over UART, but version 1.2 can. I think there must
> > be a bug in the BootROM 1.1. The older Kirkwood such as Sheevaplug,
> > Dockstar, iConnect boards come with BootROM 1.1. Later version of
> > Sheevaplug, GoFlex Home, GoFlex Net, Dreamplug, Pogoplug V4, Zyxel
> > NSA310S, NSA320, NSA325 come with BootROM 1.2. So even though it is
> > the same SoC, eg. 6281, they are actually produced at a different time
> > and have different BootROM versions.
>
> There are always multiple revisions of the same SoC. So it is possible
> that something was broken on first revision of 88F6281 and in next
> revision was updated BootROM with some fixes. Revision is written on
> package label and for Armada SoCs it is available also in some register
> (not sure about Kirkwood). It looks like that there is at least revision
> Z0 and revision A0 of some Kirkwood SoC.
>
> If there is a bug in first revisions then it should be documented in
> some Kirkwood Errata document. Unfortunately I have never seen it, it is
> not public, so I have no idea. In any case, if somebody has access to
> Marvell documents, interesting are these document numbers:
>
> * MV-S105223-001 - Differences Between the 88F6192, and 88F6281 Stepping
> Z0 and A0
> * MV-S501081-00 - 88F6180, 88F6192, and 88F6281 Functional Errata,
> Interface Guidelines, and Restrictions
> * MV-S501157-U0 - 88F6180, 88F6190, 88F6192, and 88F6281 Functional
> Errata, Interface Guidelines, and Restrictions
>
> One of the option how to investigate or debug this issue without
> documentation is to dump both BootROM versions (1.1, 1.2) and compare
> them. Either there is different UART protocol for booting (which needs
> to be implemented) or UART protocol is buggy and needs some workaround
> or it is completely broken and does not work.
> >>>
> >>> BootROM is mapped to 0xF800 address and is 64 kB long. So via U-Boot
> >>> md command it is possible to dump it over console. Or via ext4write
> >>> command store it so ext4 fs on sd card / sata disk.
> >>
> >> Thanks for the info. It will be a while before I can get back to this
> >> BootROM 1.1 vs 1.2 topic.
> >>
> >
> > I have run some more tests, and am quite positive that if the uart0
> > node exists in the DTS, it must be tagged with dm,pre-reloc. That is
> > consistent with the serial documentation in
> > doc/develop/driver-model/serial-howto.rst. The issue is whether the
> > uart0 node is specified in the DTS. If it is, the dm-pre-reloc tag
> > must also be used.
> >
> > To prove my theory, I've modified the Pogo V4 DTS to look exactly like
> > the NSA310S, as far as uart0 is concerned. The NSA310S does not even
> > have a uart0 node! and DM_SERIAL boots fine with this box. With the
> > patch below, the Pogo V4 can be kwboot and run normally. No
> > dm-pre-reloc tag is needed.
> >
> > diff --git a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > index 5aa4669ae2..227d5ff802 100644
> > --- a/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > +++ b/arch/arm/dts/kirkwood-pogoplug-series-4.dts
> > @@ -24,7 +24,8 @@
> > };
> >
> > chosen {
> > - stdout-path = "uart0:115200n8";
> > + bootargs = "console=ttyS0,115200";
> > + stdout-path = &uart0;
> > };
>
Re: [PATCH v2] powerpc/mpc85xx: use board env file for socrates board
On Fri, Jan 27, 2023 at 06:50:52AM +0100, Heiko Schocher wrote: > as Tom suggested get rid of CFG_EXTRA_ENV_SETTINGS and > enable CONFIG_ENV_SOURCE_FILE and use text file > > board/socrates/socrates.env > > which contains the default environment. While at it, > cleanup the default Environment. > > Signed-off-by: Heiko Schocher > Suggested-by: Tom Rini > Reviewed-by: Tom Rini Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 107/169] Correct SPL use of MMC_QUIRKS
On Sun, Feb 05, 2023 at 03:40:16PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_MMC_QUIRKS defined in Kconfig > > Signed-off-by: Simon Glass > Reviewed-by: Jaehoon Chung Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3] console: usb: kbd: Limit poll frequency to improve performance
Hi,
On 2/8/23 19:45, Michal Suchánek wrote:
Hello,
On Wed, Jan 18, 2023 at 05:01:12PM +0100, Filip Žaludek wrote:
Hi Michal,
thanks for testing! Do you consider keyboard as working once it is detected
without
'usb_kbd usb_kbd: Timeout poll on interrupt endpoint', or judging from
subsequent
typing? Note that issue is reproducible only in about 20% of reboots.
I rely on keyboard input to boot so if it was 20% broken I would notice.
I don't use the rPi all that much so if it was broken only a few
% of the time there is a chance I would miss it.
Common denominator here is most likely dwc2 controller on RPi3.
However, for me not typing on the keyboard during usb detection it is
100% not detected, typing on it during usb detection it is 100%
detected.
There are 3 states:
Keyboard not detected, keyboard detected but does not work, keyboard detected
and works.
If keyboard is not detected/does not work then subsequent grub timeout is
misleading/pointless..
The timeout is limitation of the dwc2 controller handling of usb hubs.
Michal, can you please elaborate more [pointers to docs, discussions] why/how
is the timeout
limitation of the dwc2 controller handling of usb hubs?
I am trying to dissect it more by printing single character from myriad of
places what actually
works as a workaround, but when substituting with mdelay(x) exceeding printing
does not.
[common/usb.c, common/usb_hub.c, drivers/core/device.c,
drivers/usb/host/dwc2.c, drivers/usb/host/usb-uclass.c]
Thanks,
Filip
There might be a possibility to improve the driver so that it handles
the condition but it might be that the Linux driver relies on a separate
thread handling the controller which is not acceptable for u-boot.
I am not usb expert and definitely not dwc2 expert so I cannot do more
than workaround the current driver limitation.
For me I can always enter 'U-Boot>' shell, but then keyboard usually does not
work.
And yes, resetting the usb controller with pressing a key afterwards will
finally break the keyboard. ('usb reset' typed from keyboard)
If you are Prague located I am ready to demonstrate what I am talking about.
Simon's keyboard detection is somewhat interfered by 'SanDisk USB Extreme
Pro' detection,
printed complaints but keyboard still works..
'usb_kbd usb_kbd: Timeout poll on interrupt endpoint' and 'Failed to get
keyboard state from device 0c40:8000'
Btw. why from 0c40:8000 (ELMCU 2.4GHz receiver) when wired keyboard is
046d:c31c (Logitech Keyboard K120)?
What is supposed scenario for RPi3/u-boot/grub usb keyboard equipped users
wanting to boot non-default?
Enter 'U-Boot>' shell to detect keyboard; type boot; select desired grub
entry..?
Reverting either from the two makes it non issue for me:
'dwc2: use the nonblock argument in submit_int_msg'
commit 9dcab2c4d2cb50ab1864c818b82a72393c160236
Without this booting from USB is not feasible because reading every
block from the USB drive waits for the keyboard to time out.
'console: usb: kbd: Limit poll frequency to improve performance'
commit 96991e652f541323a03c5b7e075d54a117091618
No idea about this one, for me it doea not give any substantial
difference in behavior.
Thanks
Michal
Re: [PATCH v2 1/2] env: mmc: Clean up macro usage
On Thu, 9 Feb 2023 at 08:27, Tom Rini wrote: > > On Thu, Feb 09, 2023 at 01:30:09PM +0100, Marek Vasut wrote: > > > Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of > > mix of ifdef. > > > > Signed-off-by: Marek Vasut > > Reviewed-by: Tom Rini > > -- > Tom Reviewed-by: Simon Glass
imx8mm USB Mass Storage fails through a HUB
Greetings,
I'm finding that USB Mass Storage devices appear to fail detection on
imx8mm when hanging off a USB hub whereas other devices such as USB
ethernet work fine.
u-boot=> usb start && usb tree
starting USB...
Bus usb@32e4: Bus usb@32e5: USB EHCI 1.00
scanning bus usb@32e4 for devices... 1 USB Device(s) found
scanning bus usb@32e5 for devices... cannot reset port 3!?
3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
USB device tree:
1 Hub (480 Mb/s, 0mA)
u-boot EHCI Host Controller
1 Hub (480 Mb/s, 0mA)
| u-boot EHCI Host Controller
|
+-2 Hub (480 Mb/s, 0mA)
| Microchip Tech USB2744
|
+-3 Vendor specific (480 Mb/s, 0mA)
Microchip Tech Hub Controller
Depending on the board and port sometimes I see the 'cannot reset
port' issue calling out the port of the hub and sometimes I see a
'EHCI timed out on TD - token=0x80008c80 unable to get device
descriptor (error=-1)' error.
I have several imx8m{m,n,p}-venice boards with onboard hubs I noticed
this with but you can re-create this on an imx8mm-evk if you attach a
HUB with a USB Mass Storage Device to the front-panel USB Type-C
connector after manually enabling VBUS (due to the lack of a PTN5110
driver that would handle source/sink detection on that port):
i2c dev 1 && i2c mw 0x50 0x23 0x77 1 # COMMAND: SRC_VBUS_HIGH
usb start && usb tree
So far I've tried without success:
- setenv usb_pgood_delay 5000
- CONFIG_USB_ONBOARD_HUB=y
Any ideas on this?
Best Regards,
Tim
Re: [PATCH] schemas: Add schema for firmware logs
Hi Jan, On Wed, 8 Feb 2023 at 01:15, Jan Lübbe wrote: > > On Tue, 2023-02-07 at 11:39 -0700, Simon Glass wrote: > > Hi Jan, > > > > On Tue, 7 Feb 2023 at 08:39, Jan Lübbe wrote: > > > > > > On Tue, 2023-02-07 at 06:38 -0700, Simon Glass wrote: > > > > Hi Jan, > > > > > > > > On Tue, 7 Feb 2023 at 04:56, Jan Lübbe wrote: > > > > > [snip] > > > > Thanks for the pointer. I had a look at this. How do you deal with > > > > updating a filesystem that might be corrupt? Is that even a good idea, > > > > if the purpose of it is to collect data from a kernel crash? > > > > > > This uses only the ramoops "backend" in pstore, so no filesystems are > > > involved. > > > If I remember correctly, ramoops in the kernel just discards any data > > > that is > > > too corrupted to process. Barebox should behave the same, as the code was > > > ported > > > from the kernel. > > > > Yes...actually I found that U-Boot has pstore too, but it does not > > support writing the console into it. I suppose it would be easy > > enough, but it seems that U-Boot's pstore is not as advanced. > > > > > > > > We are working on a firmware 'Transfer List' which is a simple data > > > > structure to communicate through the different firmware phases. Since > > > > U-Boot is the last one, in this case, I suppose it could do the > > > > ramoops thing and add files for each of the firmware phases. > > > > > > For passing logs "forward" to the next step in the boot chain, this > > > should work > > > as well and could be more explicit than the ramoops console. One benefit > > > would > > > be that keeping the logs from each step separate, right? > > > > Yes. But we can't use this to pass it to the kernel. > > > > Hmm, because we would need to reserve space for the text memory regions, which > couldn't be used by the kernel later? Because the transfer list does not get passed to the kernel. We don't want to invent another way to pass info to Linux, since we already have FDT, ACPI and cmdline. In fact I have a horrible suspicion that someone added a structured cmdline a bit like an FDT but in text... > > > > ramoops has additional mechanisms to deal with the possible corruption > > > caused by > > > the crash or reset cycle, which shouldn't be needed in to "forward" > > > direction. > > > > But if there is corruption there, what does U-Boot do? > > > > 1. Clear the ramoops and write its console info (that will be annoying > > for people trying to debug kernel crashes) > > 2. Leave it alone and not write the console info (then it is non-functional) > > 3. Or is it possible to write even when some things are corrupted? > > As the console is protected by ECC in blocks, you can have corrupted blocks in > the middle and still continue logging at the end, if you want. The corrupted > block can then either be repaired when reading or need to be skipped. OK I see. > > > > > What about logging support? It would be nice to have a format that > > > > understands logging level, category, filename/function, etc. > > > > > > ramoops console is just unstructured text, Linux and Barebox just write > > > characters to it. More structure might be nice some cases, but the > > > necessary > > > coordination between different projects could be a high barrier. ;) > > > > Indeed it is, but that is the point of the binding :-) > > > > > > > > Perhaps a simple list of text blocks would be enough, though. > > > > Do you mean a list of nul-terminated strings? What format are you thinking > > of? > > > > > > I think the format described in the binding should work well enough (ASCII > lines, with NUL termination). And it's readable on a terminal. :) Yes I think that is important. > > > > > > Regards, > > > > > Jan > > > > > > > > > > > I think any new DT binding is premature and pstore/ramoops was just > > > > > > a > > > > > > suggestion to consider. This needs wider consideration of how to > > > > > > handle all the various (boot) firmware logs. I've added the > > > > > > boot-architecture list for a bit more visibility. > > > > > > > > If this needs a call, I have not seen one for quite a while. It seems > > > > to get cancelled at the last minute. I would be happy to attend one to > > > > discuss this topic. But if people have ideas here, please weigh in. > > > > > > Looking at the proposed schema, I'd prefer to drop the boot-phase and > > > project > > > patterns and use the lists as suggestions only. The order of > > > /chosen/logs/log@N > > > should be enough to make sense of those. > > > > Yes I suppose so, but I would really like to have a clear view of what > > booted and which project it came from. Do you think it is an undue > > burden? > > > > I didn't mean to drop the properties, but to allow free-form text. Not all > firmware stacks use the same phases and not all bootloader project names start > with "^U-Boot|TF-A". :) > > I don't think we'll see project name collisions, and the boot-phase name > should > be unique with in a project, so free
Re: [PATCH v2 064/169] Correct SPL uses of DFU_VIRT
On Sun, Feb 05, 2023 at 03:39:33PM -0700, Simon Glass wrote:
> This converts 3 usages of this option to the non-SPL form, since there is
> no SPL_DFU_VIRT defined in Kconfig
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> board/st/common/stm32mp_dfu.c | 2 +-
> drivers/dfu/Makefile | 2 +-
> include/dfu.h | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/board/st/common/stm32mp_dfu.c b/board/st/common/stm32mp_dfu.c
> index 0096f71dfc1..19e9c3b2402 100644
> --- a/board/st/common/stm32mp_dfu.c
> +++ b/board/st/common/stm32mp_dfu.c
> @@ -159,7 +159,7 @@ void set_dfu_alt_info(char *interface, char *devstr)
> puts("DFU alt info setting: done\n");
> }
>
> -#if CONFIG_IS_ENABLED(DFU_VIRT)
> +#if IS_ENABLED(CONFIG_DFU_VIRT)
> #include
> #include
>
> diff --git a/drivers/dfu/Makefile b/drivers/dfu/Makefile
> index dfbf64da667..df88f4be59a 100644
> --- a/drivers/dfu/Makefile
> +++ b/drivers/dfu/Makefile
> @@ -10,4 +10,4 @@ obj-$(CONFIG_$(SPL_)DFU_NAND) += dfu_nand.o
> obj-$(CONFIG_$(SPL_)DFU_RAM) += dfu_ram.o
> obj-$(CONFIG_$(SPL_)DFU_SF) += dfu_sf.o
> obj-$(CONFIG_$(SPL_)DFU_WRITE_ALT) += dfu_alt.o
> -obj-$(CONFIG_$(SPL_)DFU_VIRT) += dfu_virt.o
> +obj-$(CONFIG_DFU_VIRT) += dfu_virt.o
> diff --git a/include/dfu.h b/include/dfu.h
> index 0794ef1..06efbf4b208 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -495,7 +495,7 @@ static inline int dfu_fill_entity_mtd(struct dfu_entity
> *dfu, char *devstr,
> }
> #endif
>
> -#if CONFIG_IS_ENABLED(DFU_VIRT)
> +#if IS_ENABLED(CONFIG_DFU_VIRT)
> int dfu_fill_entity_virt(struct dfu_entity *dfu, char *devstr,
>char **argv, int argc);
> int dfu_write_medium_virt(struct dfu_entity *dfu, u64 offset,
This is I believe an intentional usage.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 031/169] Correct SPL use of ATMEL_PIO4
On Sun, Feb 05, 2023 at 03:36:17PM -0700, Simon Glass wrote: > This converts 1 usage of this option to the non-SPL form, since there is > no SPL_ATMEL_PIO4 defined in Kconfig > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/pinctrl/pinctrl-at91-pio4.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c > b/drivers/pinctrl/pinctrl-at91-pio4.c > index 50e3dd449ab..84b398619c4 100644 > --- a/drivers/pinctrl/pinctrl-at91-pio4.c > +++ b/drivers/pinctrl/pinctrl-at91-pio4.c > @@ -271,7 +271,7 @@ static int atmel_pinctrl_bind(struct udevice *dev) > ofnode node = dev_ofnode(dev); > struct atmel_pinctrl_data *priv = (struct atmel_pinctrl_data > *)dev_get_driver_data(dev); > > - if (!CONFIG_IS_ENABLED(ATMEL_PIO4)) > + if (!IS_ENABLED(CONFIG_ATMEL_PIO4)) > return 0; > > /* Obtain a handle to the GPIO driver */ This grows SPL in a number of platforms, so adding in Eugen to see if we really do want to omit this here in SPL on platforms that otherwise set the symbol. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 025/169] Correct SPL uses of ARCH_MVEBU
On Sun, Feb 05, 2023 at 03:36:11PM -0700, Simon Glass wrote:
> This converts 2 usages of this option to the non-SPL form, since there is
> no SPL_ARCH_MVEBU defined in Kconfig
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> drivers/mmc/mv_sdhci.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
> index 336ebf14102..20049981473 100644
> --- a/drivers/mmc/mv_sdhci.c
> +++ b/drivers/mmc/mv_sdhci.c
> @@ -64,7 +64,7 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32
> min_clk, u32 quirks)
> host->ops = &mv_ops;
> #endif
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> + if (IS_ENABLED(CONFIG_ARCH_MVEBU)) {
> /* Configure SDHCI MBUS mbus bridge windows */
> sdhci_mvebu_mbus_config((void __iomem *)regbase);
> }
> @@ -103,7 +103,7 @@ static int mv_sdhci_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> - if (CONFIG_IS_ENABLED(ARCH_MVEBU)) {
> + if (IS_ENABLED(CONFIG_ARCH_MVEBU)) {
> /* Configure SDHCI MBUS mbus bridge windows */
> sdhci_mvebu_mbus_config(host->ioaddr);
> }
So, a number of mvebu platforms now grow their SPL here, which is (a) a
functional change and (b) implies it's intentional. I'm adding Stefan
here to start to get a better handle on if this really should be like
this, or not.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 142/169] Correct SPL uses of SPI_FLASH_MACRONIX
On Sun, Feb 05, 2023 at 05:55:09PM -0700, Simon Glass wrote: > This converts 2 usages of this option to the non-SPL form, since there is > no SPL_SPI_FLASH_MACRONIX defined in Kconfig > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/mtd/spi/spi-nor-core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This increases size on at least xilinx_zynqmp_virt. -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 09/19] android: boot: add vendor boot image to prepare for v3,v4 support
On 07/02/2023 05:02, Simon Glass wrote: On Sun, 5 Feb 2023 at 16:50, Safae Ouajih wrote: Introduce vendor boot image for version 3 and 4 of boot image header. The vendor boot image will hold extra information about kernel, dtb and ramdisk. This is done to prepare for boot image version 3 and 4 support. Signed-off-by: Safae Ouajih --- boot/bootm.c | 8 +++ boot/image-android.c | 54 boot/image-board.c | 3 +-- boot/image-fdt.c | 3 ++- cmd/abootimg.c | 4 ++-- include/image.h | 48 ++- 6 files changed, 81 insertions(+), 39 deletions(-) I don't see a change log but I see some comments. Not sure what else I said on the review. Only the comments changed to add the new partition Thank you for the review, BR, Safae Reviewed-by: Simon Glass
Re: [PATCH v3 18/19] test/py: android: extend abootimg test
On 07/02/2023 20:02, Tom Rini wrote: On Mon, Feb 06, 2023 at 12:50:20AM +0100, Safae Ouajih wrote: test_abootimg is extended to include the testing of boot images version 4. For this, boot.img and vendor_boot.img have been generated using mkbootimg tool with setting the header version to 4. This tests: - Getting the header version using abootimg - Extracting the load address of the dtb - Extracting the dtb start address in RAM Running test: $ ./test/py/test.py --bd sandbox --build -k test_abootimg Signed-off-by: Safae Ouajih Reviewed-by: Simon Glass --- test/py/tests/test_android/test_abootimg.py | 136 ++-- 1 file changed, 123 insertions(+), 13 deletions(-) Alright, so I don't know where the failure starts, exactly. And to make testing this easier, there's currently the trini/u-boot-gitlab-ci-runner:jammy-20230126-07Feb2023 container you can use to replicate my problem. The problem is that while this test passes in CI, with GCC, with Clang it fails, consistently: https://source.denx.de/u-boot/u-boot/-/jobs/572239#L284 and I'm not quite sure why. I hope that building sandbox with clang and also just trying these features out interactively will fail too, and so debugging this will be less of a problem. Hi Tom, I will try to reproduce this fail and fix it on a v4. Thank you for reporting, BRs, Safae
Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation
On Thu, Feb 09, 2023 at 10:24:47AM +0100, Frieder Schrempf wrote: > Hi, > > On 10.01.23 12:58, Frieder Schrempf wrote: > > From: Mikhail Kshevetskiy > > > > Currently there are 3 different variants of read_id implementation: > > 1. opcode only. Found in GD5FxGQ4xF. > > 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E > > 3. opcode + 1 dummy byte. Found in other currently supported chips. > > > > Original implementation was for variant 1 and let detect function > > of chips with variant 2 and 3 to ignore the first byte. This isn't > > robust: > > > > 1. For chips of variant 2, if SPI master doesn't keep MOSI low > > during read, chip will get a random id offset, and the entire id > > buffer will shift by that offset, causing detect failure. > > > > 2. For chips of variant 1, if it happens to get a devid that equals > > to manufacture id of variant 2 or 3 chips, it'll get incorrectly > > detected. > > > > This patch reworks detect procedure to address problems above. New > > logic do detection for all variants separatedly, in 1-2-3 order. > > Since all current detect methods do exactly the same id matching > > procedure, unify them into core.c and remove detect method from > > manufacture_ops. > > > > This is a rework of Chuanhong Guo patch > > submitted to linux kernel > > > > Signed-off-by: Mikhail Kshevetskiy > > Signed-off-by: Frieder Schrempf > > +Cc: Jagan, Tom > > Who is supposed to pick up these patches? Some of them have been around > for some months (before I resent them). > > There is no maintainer for drivers/mtd/spinand/ and no maintainer for > drivers/mtd/ in general. > > In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't > even add him to Cc, of course. > > Any ideas how to proceed? We don't have anyone dedicated to that area, yes, sadly. I've added Michael and Dario as they've also been doing mtd-but-not-spi work of late to see if they're interested. Or since you've long been working here, would you like to more formally maintain the area? Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 06/19] android: boot: move to andr_image_data structure
On 09/02/2023 15:26, Mattijs Korpershoek wrote:
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
Move from andr_boot_img_hdr_v0 to andr_image_data
structure to prepare for boot image header
version 3 and 4.
Signed-off-by: Safae Ouajih
---
boot/image-android.c | 121 +++
cmd/abootimg.c | 31 +--
2 files changed, 81 insertions(+), 71 deletions(-)
diff --git a/boot/image-android.c b/boot/image-android.c
index ea05c1814f..15a735e230 100644
--- a/boot/image-android.c
+++ b/boot/image-android.c
@@ -86,7 +86,7 @@ bool android_image_get_data(const void *boot_hdr, struct
andr_image_data *data)
return true;
}
-static ulong android_image_get_kernel_addr(const struct andr_boot_img_hdr_v0 *hdr)
+static ulong android_image_get_kernel_addr(struct andr_image_data *img_data)
{
/*
* All the Android tools that generate a boot.img use this
@@ -99,17 +99,17 @@ static ulong android_image_get_kernel_addr(const struct
andr_boot_img_hdr_v0 *hd
*
* Otherwise, we will return the actual value set by the user.
*/
- if (hdr->kernel_addr == ANDROID_IMAGE_DEFAULT_KERNEL_ADDR)
- return (ulong)hdr + hdr->page_size;
+ if (img_data->kernel_addr == ANDROID_IMAGE_DEFAULT_KERNEL_ADDR)
+ return img_data->kernel_ptr;
/*
* abootimg creates images where all load addresses are 0
* and we need to fix them.
*/
- if (hdr->kernel_addr == 0 && hdr->ramdisk_addr == 0)
+ if (img_data->kernel_addr == 0 && img_data->ramdisk_addr == 0)
return env_get_ulong("kernel_addr_r", 16, 0);
- return hdr->kernel_addr;
+ return img_data->kernel_addr;
}
/**
@@ -130,27 +130,33 @@ static ulong android_image_get_kernel_addr(const struct
andr_boot_img_hdr_v0 *hd
int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr, int
verify,
ulong *os_data, ulong *os_len)
{
- u32 kernel_addr = android_image_get_kernel_addr(hdr);
- const struct legacy_img_hdr *ihdr = (const struct legacy_img_hdr *)
- ((uintptr_t)hdr + hdr->page_size);
+ struct andr_image_data img_data = {0};
+ u32 kernel_addr;
+ const struct legacy_img_hdr *ihdr;
+
+ if (!android_image_get_data(hdr, &img_data))
+ return -EINVAL;
+
+ kernel_addr = android_image_get_kernel_addr(&img_data);
+ ihdr = (const struct legacy_img_hdr *)img_data.kernel_ptr;
/*
* Not all Android tools use the id field for signing the image with
* sha1 (or anything) so we don't check it. It is not obvious that the
* string is null terminated so we take care of this.
*/
- strncpy(andr_tmp_str, hdr->name, ANDR_BOOT_NAME_SIZE);
+ strlcpy(andr_tmp_str, img_data.image_name, ANDR_BOOT_NAME_SIZE);
While strlcpy is probably better than strncpy here, it has nothing to do
with this change. Either mention in the commit message that this is
intentional or drop this change.
Note that strncpy was used in v2 of this patch. Why change it to strlcpy here?
Hello Mattijs,
Thank you for the review,
This is done to fix checkpatch.pl warning : WARNING: strlcpy is
preferred over strncpy
andr_tmp_str[ANDR_BOOT_NAME_SIZE] = '\0';
if (strlen(andr_tmp_str))
printf("Android's image name: %s\n", andr_tmp_str);
printf("Kernel load addr 0x%08x size %u KiB\n",
- kernel_addr, DIV_ROUND_UP(hdr->kernel_size, 1024));
+ kernel_addr, DIV_ROUND_UP(img_data.kernel_size, 1024));
int len = 0;
- if (*hdr->cmdline) {
- printf("Kernel command line: %s\n", hdr->cmdline);
- len += strlen(hdr->cmdline);
+ if (*img_data.kcmdline) {
+ printf("Kernel command line: %s\n", img_data.kcmdline);
+ len += strlen(img_data.kcmdline);
}
char *bootargs = env_get("bootargs");
@@ -168,8 +174,9 @@ int android_image_get_kernel(const struct
andr_boot_img_hdr_v0 *hdr, int verify,
strcpy(newbootargs, bootargs);
strcat(newbootargs, " ");
}
- if (*hdr->cmdline)
- strcat(newbootargs, hdr->cmdline);
+
+ if (*img_data.kcmdline)
+ strcat(newbootargs, img_data.kcmdline);
env_set("bootargs", newbootargs);
@@ -177,15 +184,14 @@ int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr, int verify,
if (image_get_magic(ihdr) == IH_MAGIC) {
*os_data = image_get_data(ihdr);
} else {
- *os_data = (ulong)hdr;
- *os_data += hdr->page_size;
+ *os_data = img_data.kernel_ptr;
}
}
if (os_len) {
if (image_get_magic(ihdr) == IH_MAGIC)
*os_len = image_get_data_s
Re: [PATCH v2 2/2] env: mmc: Apply GPT only on eMMC user HW partition
On 2/9/23 16:27, Tom Rini wrote:
On Thu, Feb 09, 2023 at 01:30:10PM +0100, Marek Vasut wrote:
Apply the GPT U-Boot environment GUID type look up only on eMMC user
HW partition, do not apply the look up on eMMC boot HW partitions as
mmc_offset_try_partition() assumes either SD partitions or eMMC user
HW partition.
This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
Signed-off-by: Marek Vasut
So you're saying that today, you cannot make use of this feature and put
the environment on one of the boot partitions, as it doesn't work?
Today you cannot place env into GPT which is located in eMMC BOOT HW
partitions, that only works for GPT which is located in eMMC USER HW
partition.
If
so, then yes, this is the first step forward and someone else with that
wants the case I described here can fix things further.
I'm not even sure whether it makes sense to have 4 MiB or so GPT in eMMC
BOOT HW partitions in the first place, but sure, if someone needs that
at some later point, why not.
Reviewed-by: Tom Rini
Re: [PATCH v3 06/19] android: boot: move to andr_image_data structure
On 07/02/2023 05:02, Simon Glass wrote: Hi Safae, On Sun, 5 Feb 2023 at 16:50, Safae Ouajih wrote: Move from andr_boot_img_hdr_v0 to andr_image_data structure to prepare for boot image header version 3 and 4. Change log? Hi Simon, I will make sure to include changelogs in v4. For this patch it would be : -- v2->v3 - Remove #ifdef directives that are not needed in v3 - Use strlcpy instead of strncpy as required by checkpatch.pl - Fix coding style (spaces at the start of a line) in android_image_get_second() as required by checkpatch.pl Thank you for the review, BRs, Safae Signed-off-by: Safae Ouajih --- boot/image-android.c | 121 +++ cmd/abootimg.c | 31 +-- 2 files changed, 81 insertions(+), 71 deletions(-)
[PATCH 2/2] drivers: net: fsl-mc: fix MAC address fixup procedure
In the process of adopting CONFIG_DM_ETH on the DPAA2 based platforms,
interfaces which were previously defined as "xgmii" were transitioned to
be defined as "xfi" in the DTS.
See the commit below for reference:
commit 87274918f2f4 ("arm: dts: ls2088ardb: add DPMAC and PHY nodes")
Then Vladimir's commit replaced all occurrences of "xfi" with
"10gbase-r" in an effort to make U-Boot work with the same device tree
as Linux.
commit 77b11f760416 ("net: replace the "xfi" phy-mode with "10gbase-r"")
These changes to the phy_interface_t of an Ethernet port meant that the
mc_fixup_mac_addrs() function was no longer capable to properly fixup
the MAC addresses. The problem arises from the fact that the hardcoded
information about an interface (wriop_get_enet_if()) was no longer
matching any actual device.
For example, the function tried to search for "DPMAC1@xgmii1" by name
using eth_get_dev_by_name() when only "DPMAC1@10gbase-r" was available.
This function removes the need to rely on the hardcoded information by
iterating through all the UCLASS_ETH devices which are DPAA2 and request
a fixup for each of them.
Signed-off-by: Ioana Ciornei
---
drivers/net/fsl-mc/mc.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 4f84403d956c..78a40f285aa2 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#define MC_RAM_BASE_ADDR_ALIGNMENT (512UL * 1024 * 1024)
#define MC_RAM_BASE_ADDR_ALIGNMENT_MASK(~(MC_RAM_BASE_ADDR_ALIGNMENT -
1))
@@ -383,37 +384,31 @@ static int mc_fixup_dpc_mac_addr(void *blob, int dpmac_id,
static int mc_fixup_mac_addrs(void *blob, enum mc_fixup_type type)
{
- int i, err = 0, ret = 0;
-#define ETH_NAME_LEN 20
struct udevice *eth_dev;
- char ethname[ETH_NAME_LEN];
-
- for (i = WRIOP1_DPMAC1; i < NUM_WRIOP_PORTS; i++) {
- /* port not enabled */
- if (wriop_is_enabled_dpmac(i) != 1)
- continue;
-
- snprintf(ethname, ETH_NAME_LEN, "DPMAC%d@%s", i,
-phy_interface_strings[wriop_get_enet_if(i)]);
-
- eth_dev = eth_get_dev_by_name(ethname);
- if (eth_dev == NULL)
+ int err = 0, ret = 0;
+ struct uclass *uc;
+ uint32_t dpmac_id;
+
+ uclass_get(UCLASS_ETH, &uc);
+ uclass_foreach_dev(eth_dev, uc) {
+ if (!eth_dev->driver || !eth_dev->driver->name ||
+ strcmp(eth_dev->driver->name, LDPAA_ETH_DRIVER_NAME))
continue;
+ dpmac_id = ldpaa_eth_get_dpmac_id(eth_dev);
switch (type) {
case MC_FIXUP_DPL:
- err = mc_fixup_dpl_mac_addr(blob, i, eth_dev);
+ err = mc_fixup_dpl_mac_addr(blob, dpmac_id, eth_dev);
break;
case MC_FIXUP_DPC:
- err = mc_fixup_dpc_mac_addr(blob, i, eth_dev);
+ err = mc_fixup_dpc_mac_addr(blob, dpmac_id, eth_dev);
break;
default:
break;
}
if (err)
- printf("fsl-mc: ERROR fixing mac address for %s\n",
- ethname);
+ printf("fsl-mc: ERROR fixing mac address for %s\n",
eth_dev->name);
ret |= err;
}
--
2.25.1
[PATCH 1/2] drivers: net: ldpaa: export driver name and API to get DPMAC id
Export the ldpaa_eth_get_dpmac_id() function so that it can be used from
other drivers, especially by fsl-mc which will need it the next patch.
Also, create a macro for the Ethernet ldpaa driver name and export it as
well.
Signed-off-by: Ioana Ciornei
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 7 ---
include/net/ldpaa_eth.h | 15 +++
2 files changed, 19 insertions(+), 3 deletions(-)
create mode 100644 include/net/ldpaa_eth.h
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 24850777949a..2cb6e9b7d705 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2014-2016 Freescale Semiconductor, Inc.
- * Copyright 2017 NXP
+ * Copyright 2017, 2023 NXP
*/
#include
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include "ldpaa_eth.h"
#ifdef CONFIG_PHYLIB
@@ -995,7 +996,7 @@ static int ldpaa_eth_probe(struct udevice *dev)
return 0;
}
-static uint32_t ldpaa_eth_get_dpmac_id(struct udevice *dev)
+uint32_t ldpaa_eth_get_dpmac_id(struct udevice *dev)
{
int port_node = dev_of_offset(dev);
@@ -1049,7 +1050,7 @@ static const struct udevice_id ldpaa_eth_of_ids[] = {
};
U_BOOT_DRIVER(ldpaa_eth) = {
- .name = "ldpaa_eth",
+ .name = LDPAA_ETH_DRIVER_NAME,
.id = UCLASS_ETH,
.of_match = ldpaa_eth_of_ids,
.of_to_plat = ldpaa_eth_of_to_plat,
diff --git a/include/net/ldpaa_eth.h b/include/net/ldpaa_eth.h
new file mode 100644
index ..7474bfaeec30
--- /dev/null
+++ b/include/net/ldpaa_eth.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright 2023 NXP
+ */
+
+#define LDPAA_ETH_DRIVER_NAME "ldpaa_eth"
+
+/**
+ * ldpaa_eth_get_dpmac_id() - Get the dpmac_id of a DPAA2 ethernet device
+ *
+ * @dev: DPAA2 ethernet udevice pointer
+ * Return: requested dpmac_id
+ */
+
+uint32_t ldpaa_eth_get_dpmac_id(struct udevice *dev);
--
2.25.1
[PATCH 0/2] drivers: net: fsl-mc: fix MAC address fixup procedure
This patch set fixes the MAC address fixup procedure which was impacted by several changes in the phy_interface_t used to describe some interfaces. The transitions from "xgmii" to "xfi" and then finally to "10gbase-r" were involved. The first patch just exports a function to identify the DPMAC id of an UCLASS_ETH device and the DPAA2 driver name as a macro. Ioana Ciornei (2): drivers: net: ldpaa: export driver name and API to get DPMAC id drivers: net: fsl-mc: fix MAC address fixup procedure drivers/net/fsl-mc/mc.c | 31 +-- drivers/net/ldpaa_eth/ldpaa_eth.c | 7 --- include/net/ldpaa_eth.h | 15 +++ 3 files changed, 32 insertions(+), 21 deletions(-) create mode 100644 include/net/ldpaa_eth.h -- 2.25.1
Re: [PATCH v2 109/169] Correct SPL uses of MULTIPLEXER
On Sun, Feb 05, 2023 at 03:40:18PM -0700, Simon Glass wrote: > This converts 3 usages of this option to the non-SPL form, since there is > no SPL_MULTIPLEXER defined in Kconfig > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > drivers/Makefile | 2 +- > drivers/mux/Makefile | 2 +- > include/mux.h| 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) This is done so that we don't force multiplexer to be linked in to SPL, as there is no SPL_MULTIPLEXER option. For a v2 of this patch, also move the line down to the block of all of the other options that lack SPL_FOO but that we guard with a check for not doing SPL/TPL builds, thanks. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 041/169] Correct SPL uses of CMD_DHCP
On Sun, Feb 05, 2023 at 03:36:27PM -0700, Simon Glass wrote: > This converts 7 usages of this option to the non-SPL form, since there is > no SPL_CMD_DHCP defined in Kconfig > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > include/configs/am335x_evm.h | 2 +- > include/configs/imx8mm-cl-iot-gate.h | 2 +- > include/configs/imx8mp_rsb3720.h | 2 +- > include/configs/j721e_evm.h | 2 +- > include/configs/qemu-arm.h | 2 +- > include/configs/rockchip-common.h| 2 +- > include/configs/rpi.h| 2 +- > 7 files changed, 7 insertions(+), 7 deletions(-) So this, and a few other CMD cases are special. We have in SPL, ENV_NOWHERE for various good and valid use cases. So we want to limit the size of the default environment. We also use the generic distro bootcmd framework on these boards. So CONFIG_IS_ENABLED(CMD_FOO) gets used to nop out the boot targets we don't need taking up space. It's not a fatal problem to change these, but I'm not going to pick these changes up just yet. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 2/2] env: mmc: Apply GPT only on eMMC user HW partition
On Thu, Feb 09, 2023 at 01:30:10PM +0100, Marek Vasut wrote:
> Apply the GPT U-Boot environment GUID type look up only on eMMC user
> HW partition, do not apply the look up on eMMC boot HW partitions as
> mmc_offset_try_partition() assumes either SD partitions or eMMC user
> HW partition.
>
> This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
> is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
>
> Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
> Signed-off-by: Marek Vasut
So you're saying that today, you cannot make use of this feature and put
the environment on one of the boot partitions, as it doesn't work? If
so, then yes, this is the first step forward and someone else with that
wants the case I described here can fix things further.
Reviewed-by: Tom Rini
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2 1/2] env: mmc: Clean up macro usage
On Thu, Feb 09, 2023 at 01:30:09PM +0100, Marek Vasut wrote: > Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of > mix of ifdef. > > Signed-off-by: Marek Vasut Reviewed-by: Tom Rini -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 15/19] android: boot: support boot image header version 3 and 4
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Enable the support for boot image header version 3 and 4
> using abootimg command.
>
> In order to use version 3 or 4:
>
> 1- Vendor boot image address should be given to abootimg cmd.
>
> abootimg addr $1 $vendor_boot_load_addr
>
> 2- "ramdisk_addr_r" env variable (ramdisk address) should be set to host
> the ramdisk : generic ramdisk + vendor ramdisk
>
> Replace "struct andr_boot_img_hdr_v0*" by "void *" in
> some functions since v3 and v4 are now supported as well.
>
> Signed-off-by: Safae Ouajih
Reviewed-by: Mattijs Korpershoek
> ---
> boot/bootm.c | 37 -
> boot/image-android.c | 16 ++--
> boot/image-board.c | 18 +++---
> boot/image-fdt.c | 2 +-
> cmd/abootimg.c | 24 ++--
> include/image.h | 25 +++--
> 6 files changed, 99 insertions(+), 23 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index a58e6f391e..a7fc6c4545 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -113,6 +113,10 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int
> flag, int argc,
>char *const argv[])
> {
> const void *os_hdr;
> +#ifdef CONFIG_ANDROID_BOOT_IMAGE
> + const void *vendor_boot_img;
> + const void *boot_img;
> +#endif
> bool ep_found = false;
> int ret;
>
> @@ -181,14 +185,23 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int
> flag, int argc,
> #endif
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> + boot_img = os_hdr;
> + vendor_boot_img = NULL;
> + if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) {
> + boot_img = map_sysmem(get_abootimg_addr(), 0);
> + vendor_boot_img =
> map_sysmem(get_avendor_bootimg_addr(), 0);
> + }
> images.os.type = IH_TYPE_KERNEL;
> - images.os.comp = android_image_get_kcomp(os_hdr, NULL);
> + images.os.comp = android_image_get_kcomp(boot_img,
> vendor_boot_img);
> images.os.os = IH_OS_LINUX;
> -
> - images.os.end = android_image_get_end(os_hdr, NULL);
> - images.os.load = android_image_get_kload(os_hdr, NULL);
> + images.os.end = android_image_get_end(boot_img,
> vendor_boot_img);
> + images.os.load = android_image_get_kload(boot_img,
> vendor_boot_img);
> images.ep = images.os.load;
> ep_found = true;
> + if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) {
> + unmap_sysmem(vendor_boot_img);
> + unmap_sysmem(boot_img);
> + }
> break;
> #endif
> default:
> @@ -889,6 +902,10 @@ static const void *boot_get_kernel(struct cmd_tbl
> *cmdtp, int flag, int argc,
> int os_noffset;
> #endif
>
> +#ifdef CONFIG_ANDROID_BOOT_IMAGE
> + const void *boot_img;
> + const void *vendor_boot_img;
> +#endif
> img_addr = genimg_get_kernel_addr_fit(argc < 1 ? NULL : argv[0],
> &fit_uname_config,
> &fit_uname_kernel);
> @@ -964,10 +981,20 @@ static const void *boot_get_kernel(struct cmd_tbl
> *cmdtp, int flag, int argc,
> #endif
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> + boot_img = buf;
> + vendor_boot_img = NULL;
> + if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) {
> + boot_img = map_sysmem(get_abootimg_addr(), 0);
> + vendor_boot_img =
> map_sysmem(get_avendor_bootimg_addr(), 0);
> + }
> printf("## Booting Android Image at 0x%08lx ...\n", img_addr);
> - if (android_image_get_kernel(buf, NULL, images->verify,
> + if (android_image_get_kernel(boot_img, vendor_boot_img,
> images->verify,
>os_data, os_len))
> return NULL;
> + if (IS_ENABLED(CONFIG_CMD_ABOOTIMG)) {
> + unmap_sysmem(vendor_boot_img);
> + unmap_sysmem(boot_img);
> + }
> break;
> #endif
> default:
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 6be439ed12..fb29ff403f 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -201,7 +201,7 @@ static ulong android_image_get_kernel_addr(struct
> andr_image_data *img_data)
> * Return: Zero, os start address and length on success,
> * otherwise on failure.
> */
> -int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr,
> +int android_image_get_kernel(const void *hdr,
>const void *vendor_boot_img, int verify,
>ulong *os_data, ulong *os_len)
> {
> @@ -286,7 +286,7 @@ bool is_android_vendor_boot_image_header(const
Re: [PATCH v3 14/19] drivers: fastboot: zImage flashing is not supported for v3,v4
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> With vendor boot image introduced in version 3 and 4 of boot
> image header, boot information is located in both boot image
> and vendor boot image.
>
> Flashing zImage is not supported for version 3 and 4 since this
> requires updating vendor boot image and/or generating a new image.
>
> Print an error message when the boot image header version is
> greater than 2.
>
> Signed-off-by: Safae Ouajih
Reviewed-by: Mattijs Korpershoek
> ---
> drivers/fastboot/fb_mmc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/fastboot/fb_mmc.c b/drivers/fastboot/fb_mmc.c
> index 086e5f7843..1dea82835c 100644
> --- a/drivers/fastboot/fb_mmc.c
> +++ b/drivers/fastboot/fb_mmc.c
> @@ -370,6 +370,14 @@ static int fb_mmc_update_zimage(struct blk_desc
> *dev_desc,
> return -1;
> }
>
> + /* Check if boot image header version is 2 or less */
> + if (hdr->header_version > 2) {
> + pr_err("zImage flashing supported only for boot images v2 and
> less\n");
> + fastboot_fail("zImage flashing supported only for boot images
> v2 and less",
> + response);
> + return -EOPNOTSUPP;
> + }
> +
> /* Check if boot image has second stage in it (we don't support it) */
> if (hdr->second_size > 0) {
> pr_err("moving second stage is not supported yet\n");
> --
> 2.34.1
Re: [PATCH v3 11/19] android: boot: ramdisk: support vendor ramdisk
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Version 3 and 4 of boot image header introduced
> vendor boot ramdisk: Please check include/android_image.h
> for details.
>
> The ramdisk is now split into a generic ramdisk in boot image
> and a vendor ramdisk in vendor boot image.
>
> Support the new vendor ramdisk.
>
> Signed-off-by: Safae Ouajih
> Reviewed-by: Simon Glass
Reviewed-by: Mattijs Korpershoek
> ---
> boot/image-android.c | 13 +++--
> include/image.h | 4 ++--
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 712d437766..35243fd5b1 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -25,6 +25,7 @@ static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3
>
> data->kcmdline = hdr->cmdline;
> data->header_version = hdr->header_version;
> + data->ramdisk_ptr = env_get_ulong("ramdisk_addr_r", 16, 0);
>
> /*
>* The header takes a full page, the remaining components are aligned
> @@ -322,10 +323,11 @@ ulong android_image_get_kcomp(const struct
> andr_boot_img_hdr_v0 *hdr,
> return image_decomp_type(p, sizeof(u32));
> }
>
> -int android_image_get_ramdisk(const struct andr_boot_img_hdr_v0 *hdr,
> - const void *vendor_boot_img, ulong *rd_data,
> ulong *rd_len)
> +int android_image_get_ramdisk(const void *hdr, const void *vendor_boot_img,
> + ulong *rd_data, ulong *rd_len)
> {
> struct andr_image_data img_data = {0};
> + ulong ramdisk_ptr;
>
> if (!android_image_get_data(hdr, vendor_boot_img, &img_data))
> return -EINVAL;
> @@ -334,6 +336,13 @@ int android_image_get_ramdisk(const struct
> andr_boot_img_hdr_v0 *hdr,
> *rd_data = *rd_len = 0;
> return -1;
> }
> + if (img_data.header_version > 2) {
> + ramdisk_ptr = img_data.ramdisk_ptr;
> + memcpy((void *)(ramdisk_ptr), (void
> *)img_data.vendor_ramdisk_ptr,
> +img_data.vendor_ramdisk_size);
> + memcpy((void *)(ramdisk_ptr + img_data.vendor_ramdisk_size),
> +(void *)img_data.ramdisk_ptr,
> img_data.boot_ramdisk_size);
> + }
>
> printf("RAM disk load addr 0x%08lx size %u KiB\n",
> img_data.ramdisk_ptr, DIV_ROUND_UP(img_data.ramdisk_size, 1024));
> diff --git a/include/image.h b/include/image.h
> index c2e751c136..c4d9b1c575 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -1782,8 +1782,8 @@ int android_image_get_kernel(const struct
> andr_boot_img_hdr_v0 *hdr,
> * @rd_len: Pointer to a ulong variable, will hold ramdisk length
> * Return: 0 if succeeded, -1 if ramdisk size is 0
> */
> -int android_image_get_ramdisk(const struct andr_boot_img_hdr_v0 *hdr,
> - const void *vendor_boot_img, ulong *rd_data,
> ulong *rd_len);
> +int android_image_get_ramdisk(const void *hdr, const void *vendor_boot_img,
> + ulong *rd_data, ulong *rd_len);
>
> /**
> * android_image_get_second() - Extracts the secondary bootloader address
> --
> 2.34.1
Re: [PATCH v3 10/19] android: boot: update android_image_get_data to support v3,v4
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Since boot image header version 3 and 4 introduced vendor boot image,
> use the following functions to fill the generic android
> structure : andr_image_data:
>
> - android_boot_image_v3_v4_parse_hdr()
> - android_vendor_boot_image_v3_v4_parse_hdr()
>
> Update android_image_get_data() to support v3 and v4
>
> Signed-off-by: Safae Ouajih
> Reviewed-by: Simon Glass
Reviewed-by: Mattijs Korpershoek
> ---
> boot/image-android.c| 80 +++--
> include/android_image.h | 3 ++
> include/image.h | 11 ++
> 3 files changed, 91 insertions(+), 3 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index f16eebff49..712d437766 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -18,6 +18,65 @@
>
> static char andr_tmp_str[ANDR_BOOT_ARGS_SIZE + 1];
>
> +static void android_boot_image_v3_v4_parse_hdr(const struct
> andr_boot_img_hdr_v3 *hdr,
> +struct andr_image_data *data)
> +{
> + ulong end;
> +
> + data->kcmdline = hdr->cmdline;
> + data->header_version = hdr->header_version;
> +
> + /*
> + * The header takes a full page, the remaining components are aligned
> + * on page boundary.
> + */
> + end = (ulong)hdr;
> + end += ANDR_GKI_PAGE_SIZE;
> + data->kernel_ptr = end;
> + data->kernel_size = hdr->kernel_size;
> + end += ALIGN(hdr->kernel_size, ANDR_GKI_PAGE_SIZE);
> + data->ramdisk_size = hdr->ramdisk_size;
> + data->boot_ramdisk_size = hdr->ramdisk_size;
> + end += ALIGN(hdr->ramdisk_size, ANDR_GKI_PAGE_SIZE);
> +
> + if (hdr->header_version > 3)
> + end += ALIGN(hdr->signature_size, ANDR_GKI_PAGE_SIZE);
> +
> + data->boot_img_total_size = end - (ulong)hdr;
> +}
> +
> +static void android_vendor_boot_image_v3_v4_parse_hdr(const struct
> andr_vnd_boot_img_hdr
> + *hdr, struct
> andr_image_data *data)
> +{
> + ulong end;
> +
> + /*
> + * The header takes a full page, the remaining components are aligned
> + * on page boundary.
> + */
> + data->tags_addr = hdr->tags_addr;
> + data->image_name = hdr->name;
> + data->kernel_addr = hdr->kernel_addr;
> + data->ramdisk_addr = hdr->ramdisk_addr;
> + data->dtb_load_addr = hdr->dtb_addr;
> + end = (ulong)hdr;
> + end += hdr->page_size;
> + if (hdr->vendor_ramdisk_size) {
> + data->vendor_ramdisk_ptr = end;
> + data->vendor_ramdisk_size = hdr->vendor_ramdisk_size;
> + data->ramdisk_size += hdr->vendor_ramdisk_size;
> + end += ALIGN(hdr->vendor_ramdisk_size, hdr->page_size);
> + }
> +
> + data->dtb_ptr = end;
> + data->dtb_size = hdr->dtb_size;
> +
> + end += ALIGN(hdr->dtb_size, hdr->page_size);
> + end += ALIGN(hdr->vendor_ramdisk_table_size, hdr->page_size);
> + end += ALIGN(hdr->bootconfig_size, hdr->page_size);
> + data->vendor_boot_img_total_size = end - (ulong)hdr;
> +}
> +
> static void android_boot_image_v0_v1_v2_parse_hdr(const struct
> andr_boot_img_hdr_v0 *hdr,
> struct andr_image_data *data)
> {
> @@ -79,10 +138,20 @@ bool android_image_get_data(const void *boot_hdr, const
> void *vendor_boot_hdr,
> return false;
> }
>
> - if (((struct andr_boot_img_hdr_v0 *)boot_hdr)->header_version > 2)
> - printf("Only boot image header version 2 and below are
> supported\n");
> - else
> + if (((struct andr_boot_img_hdr_v0 *)boot_hdr)->header_version > 2) {
> + if (!vendor_boot_hdr) {
> + printf("For boot header v3+ vendor boot image has to be
> provided\n");
> + return false;
> + }
> + if (!is_android_vendor_boot_image_header(vendor_boot_hdr)) {
> + printf("Incorrect vendor boot image header\n");
> + return false;
> + }
> + android_boot_image_v3_v4_parse_hdr(boot_hdr, data);
> + android_vendor_boot_image_v3_v4_parse_hdr(vendor_boot_hdr,
> data);
> + } else {
> android_boot_image_v0_v1_v2_parse_hdr(boot_hdr, data);
> + }
>
> return true;
> }
> @@ -200,6 +269,11 @@ int android_image_get_kernel(const struct
> andr_boot_img_hdr_v0 *hdr,
> return 0;
> }
>
> +bool is_android_vendor_boot_image_header(const void *vendor_boot_img)
> +{
> + return !memcmp(VENDOR_BOOT_MAGIC, vendor_boot_img,
> ANDR_VENDOR_BOOT_MAGIC_SIZE);
> +}
> +
> bool is_android_boot_image_header(const struct andr_boot_img_hdr_v0 *hdr)
> {
> return !memcmp(ANDR_BOOT_MAGIC, hdr, ANDR_BOOT_MAGIC_SIZE);
> diff --git a/include/android_image.h b/include/android_image.h
> index fb3a9d9858..99e7803508 100644
> --- a/include/android_image.h
> +++ b/include/android
[PATCH v3 6/7] phy: rockchip-inno-usb2: Add USB2 PHY for rk3568
From: Manoj Sai
RK3568 has two USB 2.0 PHYs, and each PHY has two ports, the OTG port
of PHY0 support OTG mode with charging detection function, they are
similar to previous Rockchip SoCs.
However, there are three different designs for RK3568 USB 2.0 PHY.
1. RK3568 uses independent USB GRF module for each USB 2.0 PHY.
2. RK3568 accesses the registers of USB 2.0 PHY IP directly by APB.
3. The two ports of USB 2.0 PHY share one interrupt.
This patch only PHY1 with necessary attributes required to function
USBPHY1 on U-Boot.
Co-developed-by: Ren Jianing
Signed-off-by: Ren Jianing
Co-developed-by: Jagan Teki
Signed-off-by: Jagan Teki
Signed-off-by: Manoj Sai
---
Changes for v3:
- new patch
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index a01148db22..38cd0f0f33 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -298,11 +298,40 @@ static const struct rockchip_usb2phy_cfg
rk3399_usb2phy_cfgs[] = {
{ /* sentinel */ }
};
+static const struct rockchip_usb2phy_cfg rk3568_phy_cfgs[] = {
+ {
+ .reg= 0xfe8b,
+ .port_cfgs = {
+ [USB2PHY_PORT_OTG] = {
+ .phy_sus= { 0x, 8, 0, 0x1d2, 0x1d1
},
+ .ls_det_en = { 0x0080, 0, 0, 0, 1 },
+ .ls_det_st = { 0x0084, 0, 0, 0, 1 },
+ .ls_det_clr = { 0x0088, 0, 0, 0, 1 },
+ .utmi_ls= { 0x00c0, 5, 4, 0, 1 },
+ .utmi_hstdet= { 0x00c0, 7, 7, 0, 1 }
+ },
+ [USB2PHY_PORT_HOST] = {
+ .phy_sus= { 0x0004, 8, 0, 0x1d2, 0x1d1
},
+ .ls_det_en = { 0x0080, 1, 1, 0, 1 },
+ .ls_det_st = { 0x0084, 1, 1, 0, 1 },
+ .ls_det_clr = { 0x0088, 1, 1, 0, 1 },
+ .utmi_ls= { 0x00c0, 17, 16, 0, 1 },
+ .utmi_hstdet= { 0x00c0, 19, 19, 0, 1 }
+ }
+ },
+ },
+ { /* sentinel */ }
+};
+
static const struct udevice_id rockchip_usb2phy_ids[] = {
{
.compatible = "rockchip,rk3399-usb2phy",
.data = (ulong)&rk3399_usb2phy_cfgs,
},
+ {
+ .compatible = "rockchip,rk3568-usb2phy",
+ .data = (ulong)&rk3568_phy_cfgs,
+ },
{ /* sentinel */ }
};
--
2.25.1
[PATCH v3 7/7] config: Enable USB 2.0 for Radxa CM3-IO
=> usb start starting USB... Bus usb@fd80: USB EHCI 1.00 scanning bus usb@fd80 for devices... 4 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => usb tree USB device tree: 1 Hub (480 Mb/s, 0mA) | u-boot EHCI Host Controller | +-2 Hub (480 Mb/s, 100mA) | USB 2.0 Hub | +-3 Mass Storage (480 Mb/s, 224mA) |SanDisk Dual Drive 04019c9b2e1a58f24ee318c3c123aa5 | +-4 Human Interface (12 Mb/s, 100mA) CX 2.4G Receiver Co-developed-by: Manoj Sai Signed-off-by: Manoj Sai Signed-off-by: Jagan Teki --- Changes for v3: - new patch configs/radxa-cm3-io-rk3566_defconfig | 5 + 1 file changed, 5 insertions(+) diff --git a/configs/radxa-cm3-io-rk3566_defconfig b/configs/radxa-cm3-io-rk3566_defconfig index 10b81e0c6d..404ada3323 100644 --- a/configs/radxa-cm3-io-rk3566_defconfig +++ b/configs/radxa-cm3-io-rk3566_defconfig @@ -39,6 +39,7 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_ATF=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y @@ -58,11 +59,15 @@ CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_ETH_DESIGNWARE=y CONFIG_GMAC_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y CONFIG_SPL_RAM=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYSRESET=y +CONFIG_USB=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y # CONFIG_BINMAN_FDT is not set CONFIG_ERRNO_STR=y -- 2.25.1
[PATCH v3 5/7] phy: rockchip: inno-usb2: Add support #address_cells = 2
New Rockchip devices have the usb phy nodes as standalone devices.
These nodes have register nodes with #address_cells = 2, but only
use 32 bit addresses.
Adjust the driver to check if the returned address is "0", and adjust
the index in that case.
Derived and adjusted the similar change from linux-next with below
commit <9c19c531dc98> ("phy: phy-rockchip-inno-usb2: support
#address_cells = 2")
Co-developed-by: Manoj Sai
Signed-off-by: Manoj Sai
Signed-off-by: Jagan Teki
---
Changes for v3:
- new patch
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index b32a498ea7..a01148db22 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -179,12 +179,21 @@ static int rockchip_usb2phy_probe(struct udevice *dev)
if (IS_ERR(priv->reg_base))
return PTR_ERR(priv->reg_base);
- ret = ofnode_read_u32(dev_ofnode(dev), "reg", ®);
+ ret = ofnode_read_u32_index(dev_ofnode(dev), "reg", 0, ®);
if (ret) {
dev_err(dev, "failed to read reg property (ret = %d)\n", ret);
return ret;
}
+ /* support address_cells=2 */
+ if (reg == 0) {
+ if (ofnode_read_u32_index(dev_ofnode(dev), "reg", 1, ®)) {
+ dev_err(dev, "%s must have reg[1]\n",
+ ofnode_get_name(dev_ofnode(dev)));
+ return -EINVAL;
+ }
+ }
+
phy_cfgs = (const struct rockchip_usb2phy_cfg *)
dev_get_driver_data(dev);
if (!phy_cfgs)
--
2.25.1
[PATCH v3 4/7] board: rockchip: Add Radxa Compute Module 3 IO Board
Radxa Compute Module 3(CM3) IO board an application board from Radxa
and is compatible with Raspberry Pi CM4 IO form factor.
Radxa CM3 needs to mount on top of this IO board in order to create
complete Radxa CM3 IO board platform.
Add support for Radxa CM3 IO Board defconfig and -u-boot.dtsi
Reviewed-by: Kever Yang
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
Changes for v2:
- collect Kever RB
arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi | 18 ++
board/rockchip/evb_rk3568/MAINTAINERS| 5 ++
configs/radxa-cm3-io-rk3566_defconfig| 68
3 files changed, 91 insertions(+)
create mode 100644 arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
create mode 100644 configs/radxa-cm3-io-rk3566_defconfig
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
new file mode 100644
index 00..3c925161d4
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-cm3-io-u-boot.dtsi
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2021 Rockchip Electronics Co., Ltd
+ */
+
+#include "rk356x-u-boot.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart2;
+ };
+};
+
+&uart2 {
+ clock-frequency = <2400>;
+ u-boot,dm-spl;
+ status = "okay";
+};
diff --git a/board/rockchip/evb_rk3568/MAINTAINERS
b/board/rockchip/evb_rk3568/MAINTAINERS
index b6ea498d2b..88d11f05c2 100644
--- a/board/rockchip/evb_rk3568/MAINTAINERS
+++ b/board/rockchip/evb_rk3568/MAINTAINERS
@@ -4,3 +4,8 @@ S: Maintained
F: board/rockchip/evb_rk3568
F: include/configs/evb_rk3568.h
F: configs/evb-rk3568_defconfig
+
+RADXA-CM3
+M: Jagan Teki
+S: Maintained
+F: configs/radxa-cm3-io-rk3566_defconfig
diff --git a/configs/radxa-cm3-io-rk3566_defconfig
b/configs/radxa-cm3-io-rk3566_defconfig
new file mode 100644
index 00..10b81e0c6d
--- /dev/null
+++ b/configs/radxa-cm3-io-rk3566_defconfig
@@ -0,0 +1,68 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_TEXT_BASE=0x00a0
+CONFIG_SPL_LIBCOMMON_SUPPORT=y
+CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_NR_DRAM_BANKS=2
+CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
+CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xc0
+CONFIG_DEFAULT_DEVICE_TREE="rk3566-radxa-cm3-io"
+CONFIG_DM_RESET=y
+CONFIG_ROCKCHIP_RK3568=y
+CONFIG_SPL_ROCKCHIP_BACK_TO_BROM=y
+CONFIG_SPL_ROCKCHIP_COMMON_BOARD=y
+CONFIG_SPL_MMC=y
+CONFIG_SPL_SERIAL=y
+CONFIG_SPL_STACK_R_ADDR=0x60
+CONFIG_TARGET_EVB_RK3568=y
+CONFIG_SPL_STACK=0x40
+CONFIG_DEBUG_UART_BASE=0xFE66
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3566-radxa-cm3-io.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x2
+CONFIG_SPL_PAD_TO=0x7f8000
+CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
+CONFIG_SPL_BSS_START_ADDR=0x400
+CONFIG_SPL_BSS_MAX_SIZE=0x4000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+# CONFIG_SPL_SHARES_INIT_SP_ADDR is not set
+CONFIG_SPL_STACK_R=y
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_MMC=y
+# CONFIG_CMD_SETEXPR is not set
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_ROCKCHIP=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_SPL_RAM=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYSRESET=y
+# CONFIG_BINMAN_FDT is not set
+CONFIG_ERRNO_STR=y
--
2.25.1
[PATCH v3 3/7] arm64: dts: rockchip: rk3566: Add Radxa Compute Module 3 IO
Radxa Compute Module 3(CM3) IO board an application board from Radxa
and is compatible with Raspberry Pi CM4 IO form factor.
Specification:
- 1x HDMI,
- 2x MIPI DSI
- 2x MIPI CSI2
- 1x eDP
- 1x PCIe card
- 2x SATA
- 2x USB 2.0 Host
- 1x USB 3.0
- 1x USB 2.0 OTG
- Phone jack
- microSD slot
- 40-pin GPIO expansion header
- 12V DC
Radxa CM3 needs to mount on top of this IO board in order to create
complete Radxa CM3 IO board platform.
linux-next commit for the same,
commit <8f19828844f2> ("arm64: dts: rockchip: Fix compatible for Radxa
CM3")
Add support for Radxa CM3 IO Board.
Co-developed-by: FUKAUMI Naoki
Signed-off-by: FUKAUMI Naoki
Co-developed-by: Manoj Sai
Signed-off-by: Manoj Sai
Signed-off-by: Jagan Teki
---
Changes for v3:
- updated linux-next commit
Changes for v2:
- collect Kever RB
- add linux-next commit
arch/arm/dts/Makefile| 1 +
arch/arm/dts/rk3566-radxa-cm3-io.dts | 272 +++
2 files changed, 273 insertions(+)
create mode 100644 arch/arm/dts/rk3566-radxa-cm3-io.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d9b719f85d..8d45050c2a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -165,6 +165,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
rk3399pro-rock-pi-n10.dtb
dtb-$(CONFIG_ROCKCHIP_RK3568) += \
+ rk3566-radxa-cm3-io.dtb \
rk3568-evb.dtb
dtb-$(CONFIG_ROCKCHIP_RV1108) += \
diff --git a/arch/arm/dts/rk3566-radxa-cm3-io.dts
b/arch/arm/dts/rk3566-radxa-cm3-io.dts
new file mode 100644
index 00..d89d5263cb
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-cm3-io.dts
@@ -0,0 +1,272 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Radxa Limited
+ * Copyright (c) 2022 Amarula Solutions(India)
+ */
+
+/dts-v1/;
+#include
+#include "rk3566.dtsi"
+#include "rk3566-radxa-cm3.dtsi"
+
+/ {
+ model = "Radxa Compute Module 3(CM3) IO Board";
+ compatible = "radxa,cm3-io", "radxa,cm3", "rockchip,rk3566";
+
+ aliases {
+ mmc1 = &sdmmc0;
+ };
+
+ chosen: chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ gmac1_clkin: external-gmac1-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <12500>;
+ clock-output-names = "gmac1_clkin";
+ #clock-cells = <0>;
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-1 {
+ gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_LOW>;
+ color = ;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pi_nled_activity>;
+ };
+ };
+
+ vcc5v0_usb30: vcc5v0-usb30-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_usb30";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_usb30_en_h>;
+ regulator-always-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <&vcc_sys>;
+ };
+
+ vcca1v8_image: vcca1v8-image-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcca1v8_image";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <&vcc_1v8_p>;
+ };
+
+ vdda0v9_image: vdda0v9-image-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcca0v9_image";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <90>;
+ regulator-max-microvolt = <90>;
+ vin-supply = <&vdda_0v9>;
+ };
+};
+
+&combphy1 {
+ status = "okay";
+};
+
+&gmac1 {
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>, <&gmac1_clkin>;
+ assigned-clock-rates = <0>, <12500>;
+ clock_in_out = "input";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m0_miim
+&gmac1m0_tx_bus2
+&gmac1m0_rx_bus2
+&gmac1m0_rgmii_clk
+&gmac1m0_rgmii_bus
+
[PATCH v3 2/7] arm64: dts: rockchip: rk3566: Add Radxa Compute Module 3
Radxa Compute Module 3(CM3) is one of the modules from a series
System On Module based on the Radxa ROCK 3 series and is compatible
with Raspberry Pi CM4 pinout and form factor.
Specification:
- Rockchip RK3566
- up to 8GB LPDDR4
- up to 128GB high performance eMMC
- Optional wireless LAN, 2.4GHz and 5.0GHz IEEE 802.11b/g/n/ac wireless,
BT 5.0, BLE with onboard and external antenna.
- Gigabit Ethernet PHY
Radxa CM3 needs to mount on top of this IO board in order to create
complete Radxa CM3 IO board platform.
Since Radxa CM3 is compatible with Raspberry Pi CM4 pinout so it is
possible to mount Radxa CM3 on top of the Rasberry Pi CM4 IO board.
linux-next commit for the same,
commit <8f19828844f2> ("arm64: dts: rockchip: Fix compatible for Radxa
CM3")
Add support for Radxa CM3.
Reviewed-by: Kever Yang
Co-developed-by: FUKAUMI Naoki
Signed-off-by: FUKAUMI Naoki
Signed-off-by: Jagan Teki
---
Changes for v3:
- updated linux-next commit
Changes for v2:
- collect Kever RB
- add linux-next commit
arch/arm/dts/rk3566-radxa-cm3.dtsi | 425 +
1 file changed, 425 insertions(+)
create mode 100644 arch/arm/dts/rk3566-radxa-cm3.dtsi
diff --git a/arch/arm/dts/rk3566-radxa-cm3.dtsi
b/arch/arm/dts/rk3566-radxa-cm3.dtsi
new file mode 100644
index 00..45de2630bb
--- /dev/null
+++ b/arch/arm/dts/rk3566-radxa-cm3.dtsi
@@ -0,0 +1,425 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2022 Radxa Limited
+ * Copyright (c) 2022 Amarula Solutions(India)
+ */
+
+#include
+#include
+
+/ {
+ compatible = "radxa,cm3", "rockchip,rk3566";
+
+ aliases {
+ mmc0 = &sdhci;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "timer";
+ default-state = "on";
+ pinctrl-names = "default";
+ pinctrl-0 = <&user_led2>;
+ };
+ };
+
+ vcc_sys: vcc-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_1v8: vcc-1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <&vcc_1v8_p>;
+ };
+
+ vcc_3v3: vcc-3v3-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcca_1v8: vcca-1v8-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ vin-supply = <&vcc_1v8_p>;
+ };
+
+ sdio_pwrseq: pwrseq-sdio {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&rk817 1>;
+ clock-names = "ext_clock";
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_reg_on_h>;
+ reset-gpios = <&gpio2 RK_PB7 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu_npu>;
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <712500>;
+ regulator-max-microvolt = <139>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk817: pmic@20 {
+ compatible = "rockchip,rk817";
+ reg = <0x20>;
+ #clock-cells = <1>;
+ clock-output-names = "rk817-clkout1", "rk817-clkou
[PATCH v3 1/7] dt-bindings: rockchip: Sync rockchip, vop2.h from Linux
Sync rockchip,vop2.h from linux-next, and the last commit is
commit <604be85547ce> ("drm/rockchip: Add VOP2 driver")
Reviewed-by: Kever Yang
Signed-off-by: Jagan Teki
---
Changes for v3:
- none
Changes for v2:
- collect Kever RB
include/dt-bindings/soc/rockchip,vop2.h | 14 ++
1 file changed, 14 insertions(+)
create mode 100644 include/dt-bindings/soc/rockchip,vop2.h
diff --git a/include/dt-bindings/soc/rockchip,vop2.h
b/include/dt-bindings/soc/rockchip,vop2.h
new file mode 100644
index 00..6e66a802b9
--- /dev/null
+++ b/include/dt-bindings/soc/rockchip,vop2.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+
+#ifndef __DT_BINDINGS_ROCKCHIP_VOP2_H
+#define __DT_BINDINGS_ROCKCHIP_VOP2_H
+
+#define ROCKCHIP_VOP2_EP_RGB0 1
+#define ROCKCHIP_VOP2_EP_HDMI0 2
+#define ROCKCHIP_VOP2_EP_EDP0 3
+#define ROCKCHIP_VOP2_EP_MIPI0 4
+#define ROCKCHIP_VOP2_EP_LVDS0 5
+#define ROCKCHIP_VOP2_EP_MIPI1 6
+#define ROCKCHIP_VOP2_EP_LVDS1 7
+
+#endif /* __DT_BINDINGS_ROCKCHIP_VOP2_H */
--
2.25.1
Re: [PATCH v3 09/19] android: boot: add vendor boot image to prepare for v3,v4 support
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Introduce vendor boot image for version 3 and 4 of boot image header.
> The vendor boot image will hold extra information about kernel, dtb
> and ramdisk.
>
> This is done to prepare for boot image version 3 and 4 support.
>
> Signed-off-by: Safae Ouajih
Reviewed-by: Mattijs Korpershoek
> ---
> boot/bootm.c | 8 +++
> boot/image-android.c | 54
> boot/image-board.c | 3 +--
> boot/image-fdt.c | 3 ++-
> cmd/abootimg.c | 4 ++--
> include/image.h | 48 ++-
> 6 files changed, 81 insertions(+), 39 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 15fce8ad95..a58e6f391e 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -182,11 +182,11 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int
> flag, int argc,
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> images.os.type = IH_TYPE_KERNEL;
> - images.os.comp = android_image_get_kcomp(os_hdr);
> + images.os.comp = android_image_get_kcomp(os_hdr, NULL);
> images.os.os = IH_OS_LINUX;
>
> - images.os.end = android_image_get_end(os_hdr);
> - images.os.load = android_image_get_kload(os_hdr);
> + images.os.end = android_image_get_end(os_hdr, NULL);
> + images.os.load = android_image_get_kload(os_hdr, NULL);
> images.ep = images.os.load;
> ep_found = true;
> break;
> @@ -965,7 +965,7 @@ static const void *boot_get_kernel(struct cmd_tbl *cmdtp,
> int flag, int argc,
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> printf("## Booting Android Image at 0x%08lx ...\n", img_addr);
> - if (android_image_get_kernel(buf, images->verify,
> + if (android_image_get_kernel(buf, NULL, images->verify,
>os_data, os_len))
> return NULL;
> break;
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 748fd212ae..f16eebff49 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -66,7 +66,8 @@ static void android_boot_image_v0_v1_v2_parse_hdr(const
> struct andr_boot_img_hdr
> data->boot_img_total_size = end - (ulong)hdr;
> }
>
> -bool android_image_get_data(const void *boot_hdr, struct andr_image_data
> *data)
> +bool android_image_get_data(const void *boot_hdr, const void
> *vendor_boot_hdr,
> + struct andr_image_data *data)
> {
> if (!boot_hdr || !data) {
> printf("boot_hdr or data params can't be NULL\n");
> @@ -114,8 +115,10 @@ static ulong android_image_get_kernel_addr(struct
> andr_image_data *img_data)
>
> /**
> * android_image_get_kernel() - processes kernel part of Android boot images
> - * @hdr: Pointer to image header, which is at the start
> + * @hdr: Pointer to boot image header, which is at the start
> * of the image.
> + * @vendor_boot_img: Pointer to vendor boot image header, which is at the
> + * start of the image.
> * @verify: Checksum verification flag. Currently unimplemented.
> * @os_data: Pointer to a ulong variable, will hold os data start
> * address.
> @@ -127,14 +130,15 @@ static ulong android_image_get_kernel_addr(struct
> andr_image_data *img_data)
> * Return: Zero, os start address and length on success,
> * otherwise on failure.
> */
> -int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr, int
> verify,
> +int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr,
> + const void *vendor_boot_img, int verify,
>ulong *os_data, ulong *os_len)
> {
> struct andr_image_data img_data = {0};
> u32 kernel_addr;
> const struct legacy_img_hdr *ihdr;
>
> - if (!android_image_get_data(hdr, &img_data))
> + if (!android_image_get_data(hdr, vendor_boot_img, &img_data))
> return -EINVAL;
>
> kernel_addr = android_image_get_kernel_addr(&img_data);
> @@ -201,11 +205,12 @@ bool is_android_boot_image_header(const struct
> andr_boot_img_hdr_v0 *hdr)
> return !memcmp(ANDR_BOOT_MAGIC, hdr, ANDR_BOOT_MAGIC_SIZE);
> }
>
> -ulong android_image_get_end(const struct andr_boot_img_hdr_v0 *hdr)
> +ulong android_image_get_end(const struct andr_boot_img_hdr_v0 *hdr,
> + const void *vendor_boot_img)
> {
> struct andr_image_data img_data;
>
> - if (!android_image_get_data(hdr, &img_data))
> + if (!android_image_get_data(hdr, vendor_boot_img, &img_data))
> return -EINVAL;
>
> if (img_data.header_version > 2)
> @@ -214,22 +219,24 @@ ulong android_image_get_end(const struct
> andr_boot_img_hdr_v0 *hdr)
> return
Re: [PATCH v3 09/19] android: boot: add vendor boot image to prepare for v3,v4 support
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Introduce vendor boot image for version 3 and 4 of boot image header.
> The vendor boot image will hold extra information about kernel, dtb
> and ramdisk.
>
> This is done to prepare for boot image version 3 and 4 support.
>
> Signed-off-by: Safae Ouajih
Reviewed-by: Mattijs Korpershoek
> ---
> boot/bootm.c | 8 +++
> boot/image-android.c | 54
> boot/image-board.c | 3 +--
> boot/image-fdt.c | 3 ++-
> cmd/abootimg.c | 4 ++--
> include/image.h | 48 ++-
> 6 files changed, 81 insertions(+), 39 deletions(-)
>
> diff --git a/boot/bootm.c b/boot/bootm.c
> index 15fce8ad95..a58e6f391e 100644
> --- a/boot/bootm.c
> +++ b/boot/bootm.c
> @@ -182,11 +182,11 @@ static int bootm_find_os(struct cmd_tbl *cmdtp, int
> flag, int argc,
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> images.os.type = IH_TYPE_KERNEL;
> - images.os.comp = android_image_get_kcomp(os_hdr);
> + images.os.comp = android_image_get_kcomp(os_hdr, NULL);
> images.os.os = IH_OS_LINUX;
>
> - images.os.end = android_image_get_end(os_hdr);
> - images.os.load = android_image_get_kload(os_hdr);
> + images.os.end = android_image_get_end(os_hdr, NULL);
> + images.os.load = android_image_get_kload(os_hdr, NULL);
> images.ep = images.os.load;
> ep_found = true;
> break;
> @@ -965,7 +965,7 @@ static const void *boot_get_kernel(struct cmd_tbl *cmdtp,
> int flag, int argc,
> #ifdef CONFIG_ANDROID_BOOT_IMAGE
> case IMAGE_FORMAT_ANDROID:
> printf("## Booting Android Image at 0x%08lx ...\n", img_addr);
> - if (android_image_get_kernel(buf, images->verify,
> + if (android_image_get_kernel(buf, NULL, images->verify,
>os_data, os_len))
> return NULL;
> break;
> diff --git a/boot/image-android.c b/boot/image-android.c
> index 748fd212ae..f16eebff49 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -66,7 +66,8 @@ static void android_boot_image_v0_v1_v2_parse_hdr(const
> struct andr_boot_img_hdr
> data->boot_img_total_size = end - (ulong)hdr;
> }
>
> -bool android_image_get_data(const void *boot_hdr, struct andr_image_data
> *data)
> +bool android_image_get_data(const void *boot_hdr, const void
> *vendor_boot_hdr,
> + struct andr_image_data *data)
> {
> if (!boot_hdr || !data) {
> printf("boot_hdr or data params can't be NULL\n");
> @@ -114,8 +115,10 @@ static ulong android_image_get_kernel_addr(struct
> andr_image_data *img_data)
>
> /**
> * android_image_get_kernel() - processes kernel part of Android boot images
> - * @hdr: Pointer to image header, which is at the start
> + * @hdr: Pointer to boot image header, which is at the start
> * of the image.
> + * @vendor_boot_img: Pointer to vendor boot image header, which is at the
> + * start of the image.
> * @verify: Checksum verification flag. Currently unimplemented.
> * @os_data: Pointer to a ulong variable, will hold os data start
> * address.
> @@ -127,14 +130,15 @@ static ulong android_image_get_kernel_addr(struct
> andr_image_data *img_data)
> * Return: Zero, os start address and length on success,
> * otherwise on failure.
> */
> -int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr, int
> verify,
> +int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr,
> + const void *vendor_boot_img, int verify,
>ulong *os_data, ulong *os_len)
> {
> struct andr_image_data img_data = {0};
> u32 kernel_addr;
> const struct legacy_img_hdr *ihdr;
>
> - if (!android_image_get_data(hdr, &img_data))
> + if (!android_image_get_data(hdr, vendor_boot_img, &img_data))
> return -EINVAL;
>
> kernel_addr = android_image_get_kernel_addr(&img_data);
> @@ -201,11 +205,12 @@ bool is_android_boot_image_header(const struct
> andr_boot_img_hdr_v0 *hdr)
> return !memcmp(ANDR_BOOT_MAGIC, hdr, ANDR_BOOT_MAGIC_SIZE);
> }
>
> -ulong android_image_get_end(const struct andr_boot_img_hdr_v0 *hdr)
> +ulong android_image_get_end(const struct andr_boot_img_hdr_v0 *hdr,
> + const void *vendor_boot_img)
> {
> struct andr_image_data img_data;
>
> - if (!android_image_get_data(hdr, &img_data))
> + if (!android_image_get_data(hdr, vendor_boot_img, &img_data))
> return -EINVAL;
>
> if (img_data.header_version > 2)
> @@ -214,22 +219,24 @@ ulong android_image_get_end(const struct
> andr_boot_img_hdr_v0 *hdr)
> return
Re: [PATCH v3 06/19] android: boot: move to andr_image_data structure
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote:
> Move from andr_boot_img_hdr_v0 to andr_image_data
> structure to prepare for boot image header
> version 3 and 4.
>
> Signed-off-by: Safae Ouajih
> ---
> boot/image-android.c | 121 +++
> cmd/abootimg.c | 31 +--
> 2 files changed, 81 insertions(+), 71 deletions(-)
>
> diff --git a/boot/image-android.c b/boot/image-android.c
> index ea05c1814f..15a735e230 100644
> --- a/boot/image-android.c
> +++ b/boot/image-android.c
> @@ -86,7 +86,7 @@ bool android_image_get_data(const void *boot_hdr, struct
> andr_image_data *data)
> return true;
> }
>
> -static ulong android_image_get_kernel_addr(const struct andr_boot_img_hdr_v0
> *hdr)
> +static ulong android_image_get_kernel_addr(struct andr_image_data *img_data)
> {
> /*
>* All the Android tools that generate a boot.img use this
> @@ -99,17 +99,17 @@ static ulong android_image_get_kernel_addr(const struct
> andr_boot_img_hdr_v0 *hd
>*
>* Otherwise, we will return the actual value set by the user.
>*/
> - if (hdr->kernel_addr == ANDROID_IMAGE_DEFAULT_KERNEL_ADDR)
> - return (ulong)hdr + hdr->page_size;
> + if (img_data->kernel_addr == ANDROID_IMAGE_DEFAULT_KERNEL_ADDR)
> + return img_data->kernel_ptr;
>
> /*
>* abootimg creates images where all load addresses are 0
>* and we need to fix them.
>*/
> - if (hdr->kernel_addr == 0 && hdr->ramdisk_addr == 0)
> + if (img_data->kernel_addr == 0 && img_data->ramdisk_addr == 0)
> return env_get_ulong("kernel_addr_r", 16, 0);
>
> - return hdr->kernel_addr;
> + return img_data->kernel_addr;
> }
>
> /**
> @@ -130,27 +130,33 @@ static ulong android_image_get_kernel_addr(const struct
> andr_boot_img_hdr_v0 *hd
> int android_image_get_kernel(const struct andr_boot_img_hdr_v0 *hdr, int
> verify,
>ulong *os_data, ulong *os_len)
> {
> - u32 kernel_addr = android_image_get_kernel_addr(hdr);
> - const struct legacy_img_hdr *ihdr = (const struct legacy_img_hdr *)
> - ((uintptr_t)hdr + hdr->page_size);
> + struct andr_image_data img_data = {0};
> + u32 kernel_addr;
> + const struct legacy_img_hdr *ihdr;
> +
> + if (!android_image_get_data(hdr, &img_data))
> + return -EINVAL;
> +
> + kernel_addr = android_image_get_kernel_addr(&img_data);
> + ihdr = (const struct legacy_img_hdr *)img_data.kernel_ptr;
>
> /*
>* Not all Android tools use the id field for signing the image with
>* sha1 (or anything) so we don't check it. It is not obvious that the
>* string is null terminated so we take care of this.
>*/
> - strncpy(andr_tmp_str, hdr->name, ANDR_BOOT_NAME_SIZE);
> + strlcpy(andr_tmp_str, img_data.image_name, ANDR_BOOT_NAME_SIZE);
While strlcpy is probably better than strncpy here, it has nothing to do
with this change. Either mention in the commit message that this is
intentional or drop this change.
Note that strncpy was used in v2 of this patch. Why change it to strlcpy here?
> andr_tmp_str[ANDR_BOOT_NAME_SIZE] = '\0';
> if (strlen(andr_tmp_str))
> printf("Android's image name: %s\n", andr_tmp_str);
>
> printf("Kernel load addr 0x%08x size %u KiB\n",
> -kernel_addr, DIV_ROUND_UP(hdr->kernel_size, 1024));
> +kernel_addr, DIV_ROUND_UP(img_data.kernel_size, 1024));
>
> int len = 0;
> - if (*hdr->cmdline) {
> - printf("Kernel command line: %s\n", hdr->cmdline);
> - len += strlen(hdr->cmdline);
> + if (*img_data.kcmdline) {
> + printf("Kernel command line: %s\n", img_data.kcmdline);
> + len += strlen(img_data.kcmdline);
> }
>
> char *bootargs = env_get("bootargs");
> @@ -168,8 +174,9 @@ int android_image_get_kernel(const struct
> andr_boot_img_hdr_v0 *hdr, int verify,
> strcpy(newbootargs, bootargs);
> strcat(newbootargs, " ");
> }
> - if (*hdr->cmdline)
> - strcat(newbootargs, hdr->cmdline);
> +
> + if (*img_data.kcmdline)
> + strcat(newbootargs, img_data.kcmdline);
>
> env_set("bootargs", newbootargs);
>
> @@ -177,15 +184,14 @@ int android_image_get_kernel(const struct
> andr_boot_img_hdr_v0 *hdr, int verify,
> if (image_get_magic(ihdr) == IH_MAGIC) {
> *os_data = image_get_data(ihdr);
> } else {
> - *os_data = (ulong)hdr;
> - *os_data += hdr->page_size;
> + *os_data = img_data.kernel_ptr;
> }
> }
> if (os_len) {
> if (image_get_magic(ihdr) == IH_MAGIC)
> *os_len = image_get_data_size(ihdr);
> else
> - *os_len = hdr->kernel_size;
> +
Re: [PATCH v3 00/19] Support android boot image v3/v4
On Mon, Feb 06, 2023 at 00:50, Safae Ouajih wrote: > Hello everyone, > > * This is based on Roman Stratiienko's work to support boot image header > version 3 and 4. > > * This supports the new boot image headers v3, v4 and bootconfig feature. > https://source.android.com/docs/core/architecture/bootloader/boot-image-header > https://source.android.com/docs/core/architecture/bootloader/implementing-bootconfig > > - Tested on Amlogic Khadas vim3l, a reference board for Android Open Source > Project > https://www.khadas.com/vim3l > > And on AM625 Texas Instruments board with 5.10 linux kernel > > Main changes : > - New partition : vendor boot, with a specific vendor ramdisk > - DTB is stored in the vendor boot partition > - The generic ramdisk is placed after the vendor ramdisk > - Bootconfig feature support > > > Here is a link to see the related android boot flow changes on KHADAS vim3l > as an example: > https://gitlab.baylibre.com/baylibre/amlogic/atv/u-boot/-/commits/souajih/BootImagev4/ Re-tested the whole series on Khadas vim3l board with boot header v2. Tested-by: Mattijs Korpershoek > > Changes in v3: > - Ddd documentation for v3,v4 boot image header > - Add mkbootimg tool to Dockerfile > - Add full comments for functions/structs in include/image.h and > include/android_image.h > - Add map_sysmem() to make the boot work on Sandbox > - Rename andr_vendor_img_hdr -> andr_vnd_boot_img_hdr > > Changes in v2: > - Rework parts of the code to fix the abootimg test: test_abootimg > - Update test_abootimg to support boot image header v4 > - Remove LIBXBC library, import and adapt the functions to support bootconfig > feature > - Rename the used structures : > andr_boot_img_hdr_v0_v1_v2 -> andr_boot_img_hdr_v0 > andr_boot_img_hdr_v3_v4 -> andr_boot_img_hdr_v3 > andr_vendor_boot_img_hdr_v3_v4 -> andr_vendor_img_hdr > > Safae Ouajih (19): > android: boot: rename andr_img_hdr -> andr_boot_img_hdr_v0 > android: boot: support vendor boot image in abootimg > android: boot: replace android_image_check_header > android: boot: add boot image header v3 and v4 structures > android: boot: kcomp: support andr_image_data > android: boot: move to andr_image_data structure > android: boot: content print is not supported for v3,v4 header version > android: boot: boot image header v3,v4 do not support recovery DTBO > android: boot: add vendor boot image to prepare for v3,v4 support > android: boot: update android_image_get_data to support v3,v4 > android: boot: ramdisk: support vendor ramdisk > android: boot: support extra command line > android: boot: update android_image_get_dtb_img_addr to support v3,v4 > drivers: fastboot: zImage flashing is not supported for v3,v4 > android: boot: support boot image header version 3 and 4 > android: boot: support bootconfig > doc: android: add documentation for v3,v4 boot image header > test/py: android: extend abootimg test > Dockerfile: add mkbootimg tool > > boot/bootm.c| 37 +- > boot/image-android.c| 461 > boot/image-board.c | 19 +- > boot/image-fdt.c| 5 +- > cmd/abootimg.c | 75 +++- > doc/android/boot-image.rst | 13 +- > drivers/fastboot/fb_mmc.c | 19 +- > include/android_image.h | 228 +- > include/image.h | 173 +++- > test/py/tests/test_android/test_abootimg.py | 136 +- > tools/docker/Dockerfile | 4 + > 11 files changed, 1009 insertions(+), 161 deletions(-) > > -- > 2.34.1
[PATCH v2 2/2] env: mmc: Apply GPT only on eMMC user HW partition
Apply the GPT U-Boot environment GUID type look up only on eMMC user
HW partition, do not apply the look up on eMMC boot HW partitions as
mmc_offset_try_partition() assumes either SD partitions or eMMC user
HW partition.
This fixes environment operation on systems where CONFIG_SYS_MMC_ENV_PART
is non-zero and CONFIG_SYS_REDUNDAND_ENVIRONMENT is set.
Fixes: 80105d8fd52 ("env: mmc: select GPT env partition by type guid")
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
V2: Rebase on changes in 1/2
---
env/mmc.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/env/mmc.c b/env/mmc.c
index d51a5579128..88f8a9a8978 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -92,7 +92,7 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
return 0;
}
-static inline s64 mmc_offset(int copy)
+static inline s64 mmc_offset(struct mmc *mmc, int copy)
{
const struct {
const char *offset_redund;
@@ -106,8 +106,12 @@ static inline s64 mmc_offset(int copy)
s64 val = 0, defvalue;
const char *propname;
const char *str;
+ int hwpart = 0;
int err;
+ if (IS_ENABLED(CONFIG_SYS_MMC_ENV_PART))
+ hwpart = mmc_get_env_part(mmc);
+
/* look for the partition in mmc CONFIG_SYS_MMC_ENV_DEV */
str = ofnode_conf_read_str(dt_prop.partition);
if (str) {
@@ -119,7 +123,7 @@ static inline s64 mmc_offset(int copy)
}
/* try the GPT partition with "U-Boot ENV" TYPE GUID */
- if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)) {
+ if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && hwpart == 0) {
err = mmc_offset_try_partition(NULL, copy, &val);
if (!err)
return val;
@@ -136,7 +140,7 @@ static inline s64 mmc_offset(int copy)
return ofnode_conf_read_int(propname, defvalue);
}
#else
-static inline s64 mmc_offset(int copy)
+static inline s64 mmc_offset(struct mmc *mmc, int copy)
{
s64 offset = ENV_MMC_OFFSET;
@@ -149,7 +153,7 @@ static inline s64 mmc_offset(int copy)
__weak int mmc_get_env_addr(struct mmc *mmc, int copy, u32 *env_addr)
{
- s64 offset = mmc_offset(copy);
+ s64 offset = mmc_offset(mmc, copy);
if (offset == ENV_MMC_INVALID_OFFSET) {
printf("Invalid ENV offset in MMC, copy=%d\n", copy);
--
2.39.1
[PATCH v2 1/2] env: mmc: Clean up macro usage
Consistently use 'if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID))' instead of
mix of ifdef.
Signed-off-by: Marek Vasut
---
Cc: Patrice Chotard
Cc: Patrick Delaunay
Cc: Tom Rini
---
V2: Replace CONFIG_IS_ENABLED(PARTITION_TYPE_GUID) with
IS_ENABLED(CONFIG_PARTITION_TYPE_GUID)
---
env/mmc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/env/mmc.c b/env/mmc.c
index 5b01f657a7a..d51a5579128 100644
--- a/env/mmc.c
+++ b/env/mmc.c
@@ -73,8 +73,7 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
if (str && !strncmp((const char *)info.name, str,
sizeof(info.name)))
break;
-#ifdef CONFIG_PARTITION_TYPE_GUID
- if (!str) {
+ if (IS_ENABLED(CONFIG_PARTITION_TYPE_GUID) && !str) {
const efi_guid_t env_guid =
PARTITION_U_BOOT_ENVIRONMENT;
efi_guid_t type_guid;
@@ -82,7 +81,6 @@ static inline int mmc_offset_try_partition(const char *str,
int copy, s64 *val)
if (!memcmp(&env_guid, &type_guid, sizeof(efi_guid_t)))
break;
}
-#endif
}
/* round up to info.blksz */
--
2.39.1
Re: [PATCH] cpsw_mdio.c: Use correct reg in cpsw_mdio_get_alive
On 09/02/23 14:56, Ulf Samuelsson wrote:
>
> Den 2023-02-09 kl. 08:29, skrev Siddharth Vadapalli:
>> Hello Ulf,
>>
>> On 07/02/23 13:55, Ulf Samuelsson wrote:
>>> cpsw_mdio_get_alive reads the wrong register.
>>> See page 2316 in SPRUH73Q AM335x TRM
>>>
>>> Signed-off-by: Ulf Samuelsson
>>> Cc: Joe Hershberger
>>> Cc: Ramon Fried
>>> ---
>>> drivers/net/ti/cpsw_mdio.c | 6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
>>> index a5ba73b739..ac791faa81 100644
>>> --- a/drivers/net/ti/cpsw_mdio.c
>>> +++ b/drivers/net/ti/cpsw_mdio.c
>>> @@ -51,7 +51,7 @@ struct cpsw_mdio_regs {
>>> #define USERACCESS_PHY_REG_SHIFT (21)
>>> #define USERACCESS_PHY_ADDR_SHIFT (16)
>>> #define USERACCESS_DATA GENMASK(15, 0)
>>> - } user[0];
>>> + } user[2];
>>> };
>>> #define CPSW_MDIO_DIV_DEF 0xff
>>> @@ -366,8 +366,8 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
>>> struct cpsw_mdio *mdio = bus->priv;
>>> u32 val;
>>> - val = readl(&mdio->regs->control);
>>> - return val & GENMASK(15, 0);
>>> + val = readl(&mdio->regs->alive);
>>> + return val & GENMASK(7, 0);
>>
>> Referring to the TRM for AM335x at [0], on page 2401, the MDIOALIVE register
>> reports the presence of Ethernet PHYs up to ADDR 31. Also, the cpsw driver:
>> drivers/net/ti/cpsw.c which uses the cpsw_mdio_get_alive() function, expects
>> the
>> return value to be a 16 bit value. Therefore, I believe that the GENMASK
>> should
>> retain the previous value of "GENMASK(15, 0)", while only the register being
>> read needs to be changed from "control" to "alive". Please let me know if I
>> misunderstood something regarding your implementation.
>>
> We had an unusual H/W where the PHY (actually a switch) was connected to the
> second Ethernet port. All boards I have seen have the PHY connected to the
> first
> port or have both ports connected.
>
> IIRC correctly (this patch is > 2 years old),
> we had bad data in the bits (15:8) and this is why only the 8 bits.
> Only bits [1:0] are used anyway.
Thank you for clarifying.
Reviewed-by: Siddharth Vadapalli
Regards,
Siddharth.
Re: [PATCH 1/1] rockchip: rk3568: Add Radxa Rock Pi 3A board support
Hi FUKAUMI,
Thanks for the review comments, I will correct this in the next revision.
@marek.vasut+rene...@mailbox.org ,
@feste...@denx.de , @Simon Glass , @Kever
Yang , @Philipp Tomsich
Any comments from your side?
Best Regards,
Akash
On Tue, Feb 7, 2023 at 8:32 AM FUKAUMI Naoki wrote:
> sorry, few more corrections...
>
> On 2/7/23 10:07, FUKAUMI Naoki wrote:
> > hi
> >
> > thank you very much for your work!
> >
> > On 2/7/23 02:56, Akash Gajjar wrote:
> >> Add Radxa Rock Pi 3A support.
> > "ROCK 3 Model A" or "ROCK 3A". uppercase "ROCK", no "Pi" please.
> >
> > > sync rk3568-rock-3a.dts from Linux 6.2.0-rc7
> >
> > it seems several parts of dts are omitted. why?
> >
> >> Board Specification
> >> - Rockchip RK3568
> >> - 2/4/8 GB Dual-Channel LPDDR4
>
> no "Dual-Channel"
>
> >> - eMMC socket,SD card slot
> >> - GbE LAN
> >> - PCIe 3.0/2.0
> >> - M.2 Connector
> >> - HDMI In/Out, DP, MIPI DSI/CSI
> >
> > no "HDMI In".
>
> no "DP"
>
>
> --
> FUKAUMI Naoki
>
> >> - USB 3.0, 2.0
> >> - 40-pin GPIO expansion ports
> >> - DC 12V/2A
> >
> > Type-C PD 2.0 or QC 3.0/2.0, 9V/2A - 20V/2A.
> >
> >> Signed-off-by: Akash Gajjar
> >> ---
> >> arch/arm/dts/Makefile | 3 +-
> >> arch/arm/dts/rk3568-rock-3a-u-boot.dtsi | 24 +++
> >> arch/arm/dts/rk3568-rock-3a.dts | 214
> >> configs/rock-pi-3a-rk3568_defconfig | 69
> >> 4 files changed, 309 insertions(+), 1 deletion(-)
> >> create mode 100644 arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
> >> create mode 100644 arch/arm/dts/rk3568-rock-3a.dts
> >> create mode 100644 configs/rock-pi-3a-rk3568_defconfig
> >>
> >> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> >> index d9b719f85d..7c28418c82 100644
> >> --- a/arch/arm/dts/Makefile
> >> +++ b/arch/arm/dts/Makefile
> >> @@ -165,7 +165,8 @@ dtb-$(CONFIG_ROCKCHIP_RK3399) += \
> >> rk3399pro-rock-pi-n10.dtb
> >> dtb-$(CONFIG_ROCKCHIP_RK3568) += \
> >> -rk3568-evb.dtb
> >> +rk3568-evb.dtb \
> >> +rk3568-rock-3a.dtb
> >> dtb-$(CONFIG_ROCKCHIP_RV1108) += \
> >> rv1108-elgin-r1.dtb \
> >> diff --git a/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
> >> b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
> >> new file mode 100644
> >> index 00..42c5b6a6c5
> >> --- /dev/null
> >> +++ b/arch/arm/dts/rk3568-rock-3a-u-boot.dtsi
> >> @@ -0,0 +1,24 @@
> >> +// SPDX-License-Identifier: GPL-2.0+
> >> +/*
> >> + * (C) Copyright 2021 Rockchip Electronics Co., Ltd
> >> + * (c) Copyright 2023 Akash Gajjar
> >> + */
> >> +
> >> +#include "rk356x-u-boot.dtsi"
> >> +
> >> +/ {
> >> +chosen {
> >> +stdout-path = &uart2;
> >> +u-boot,spl-boot-order = "same-as-spl", &sdmmc0;
> >> +};
> >> +};
> >> +
> >> +&sdmmc0 {
> >> +status = "okay";
> >> +};
> >
> > redundant?
> >
> >
> > Best regards,
> >
> > --
> > FUKAUMI Naoki
> >
> >> +&uart2 {
> >> +clock-frequency = <2400>;
> >> +u-boot,dm-spl;
> >> +status = "okay";
> >> +};
> >> diff --git a/arch/arm/dts/rk3568-rock-3a.dts
> >> b/arch/arm/dts/rk3568-rock-3a.dts
> >> new file mode 100644
> >> index 00..0ff511d6a2
> >> --- /dev/null
> >> +++ b/arch/arm/dts/rk3568-rock-3a.dts
> >> @@ -0,0 +1,214 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +/*
> >> + * Copyright (c) 2021 Rockchip Electronics Co., Ltd.
> >> + * Copyright (c) 2023 Akash Gajjar
> >> + */
> >> +
> >> +/dts-v1/;
> >> +#include
> >> +#include
> >> +#include "rk3568.dtsi"
> >> +
> >> +/ {
> >> +model = "Radxa ROCK3 Model A";
> >> +compatible = "radxa,rock3a", "rockchip,rk3568";
> >> +
> >> +chosen: chosen {
> >> +stdout-path = "serial2:150n8";
> >> +};
> >> +
> >> +gmac1_clkin: external-gmac1-clock {
> >> +compatible = "fixed-clock";
> >> +clock-frequency = <12500>;
> >> +clock-output-names = "gmac1_clkin";
> >> +#clock-cells = <0>;
> >> +};
> >> +
> >> +vcc12v_dcin: vcc12v-dcin-regulator {
> >> +compatible = "regulator-fixed";
> >> +regulator-name = "vcc12v_dcin";
> >> +regulator-always-on;
> >> +regulator-boot-on;
> >> +regulator-min-microvolt = <1200>;
> >> +regulator-max-microvolt = <1200>;
> >> +};
> >> +
> >> +vcc3v3_sys: vcc3v3-sys-regulator {
> >> +compatible = "regulator-fixed";
> >> +regulator-name = "vcc3v3_sys";
> >> +regulator-always-on;
> >> +regulator-boot-on;
> >> +regulator-min-microvolt = <330>;
> >> +regulator-max-microvolt = <330>;
> >> +vin-supply = <&vcc12v_dcin>;
> >> +};
> >> +
> >> +vcc5v0_sys: vcc5v0-sys-regulator {
> >> +compatible = "regulator-fixed";
> >> +regulator-name = "vcc5v0_sys";
> >> +regulator-always-on;
> >> +regulator-boot-on;
> >> +regulator-min-microvolt = <500>;
> >> +regulator-max-microvolt = <500>;
> >> +vin-supply = <&vcc12v_dcin>;
> >> +};
>
Re: [PATCH] cpsw_mdio.c: Use correct reg in cpsw_mdio_get_alive
Hello Ulf,
On 07/02/23 13:55, Ulf Samuelsson wrote:
> cpsw_mdio_get_alive reads the wrong register.
> See page 2316 in SPRUH73Q AM335x TRM
>
> Signed-off-by: Ulf Samuelsson
> Cc: Joe Hershberger
> Cc: Ramon Fried
> ---
> drivers/net/ti/cpsw_mdio.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
> index a5ba73b739..ac791faa81 100644
> --- a/drivers/net/ti/cpsw_mdio.c
> +++ b/drivers/net/ti/cpsw_mdio.c
> @@ -51,7 +51,7 @@ struct cpsw_mdio_regs {
> #define USERACCESS_PHY_REG_SHIFT (21)
> #define USERACCESS_PHY_ADDR_SHIFT(16)
> #define USERACCESS_DATA GENMASK(15, 0)
> - } user[0];
> + } user[2];
> };
>
> #define CPSW_MDIO_DIV_DEF0xff
> @@ -366,8 +366,8 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
> struct cpsw_mdio *mdio = bus->priv;
> u32 val;
>
> - val = readl(&mdio->regs->control);
> - return val & GENMASK(15, 0);
> + val = readl(&mdio->regs->alive);
> + return val & GENMASK(7, 0);
Referring to the TRM for AM335x at [0], on page 2401, the MDIOALIVE register
reports the presence of Ethernet PHYs up to ADDR 31. Also, the cpsw driver:
drivers/net/ti/cpsw.c which uses the cpsw_mdio_get_alive() function, expects the
return value to be a 16 bit value. Therefore, I believe that the GENMASK should
retain the previous value of "GENMASK(15, 0)", while only the register being
read needs to be changed from "control" to "alive". Please let me know if I
misunderstood something regarding your implementation.
[0] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
Regards,
Siddharth.
> }
>
> struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,
Re: [PATCH 1/1] cmd: CONFIG_CMD_EFICONFIG requires CONFIG_MENU
On Wed, Feb 08, 2023 at 02:01:33PM +0100, Heinrich Schuchardt wrote:
> The eficonfig command invokes functions implemented in common/menu.c like
>
> * menu_default_set()
> * menu_get_choice()
> * menu_destroy()
> * menu_item_add()
>
> Fixes: 87d791423ac6 ("eficonfig: menu-driven addition of UEFI boot option")
> Signed-off-by: Heinrich Schuchardt
> ---
> cmd/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index c7344ee1f6..aef99d2eb8 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -2001,6 +2001,7 @@ config CMD_EFIDEBUG
> config CMD_EFICONFIG
> bool "eficonfig - provide menu-driven uefi variables maintenance
> interface"
> depends on CMD_BOOTEFI_BOOTMGR
> + select MENU
> help
> Enable the 'eficonfig' command which provides the menu-driven UEFI
> variable maintenance interface.
> --
> 2.38.1
>
Reviewed-by: Ilias Apalodimas
Re: [PATCH] cpsw_mdio.c: Use correct reg in cpsw_mdio_get_alive
Den 2023-02-09 kl. 08:29, skrev Siddharth Vadapalli:
Hello Ulf,
On 07/02/23 13:55, Ulf Samuelsson wrote:
cpsw_mdio_get_alive reads the wrong register.
See page 2316 in SPRUH73Q AM335x TRM
Signed-off-by: Ulf Samuelsson
Cc: Joe Hershberger
Cc: Ramon Fried
---
drivers/net/ti/cpsw_mdio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ti/cpsw_mdio.c b/drivers/net/ti/cpsw_mdio.c
index a5ba73b739..ac791faa81 100644
--- a/drivers/net/ti/cpsw_mdio.c
+++ b/drivers/net/ti/cpsw_mdio.c
@@ -51,7 +51,7 @@ struct cpsw_mdio_regs {
#define USERACCESS_PHY_REG_SHIFT (21)
#define USERACCESS_PHY_ADDR_SHIFT (16)
#define USERACCESS_DATA GENMASK(15, 0)
- } user[0];
+ } user[2];
};
#define CPSW_MDIO_DIV_DEF 0xff
@@ -366,8 +366,8 @@ u32 cpsw_mdio_get_alive(struct mii_dev *bus)
struct cpsw_mdio *mdio = bus->priv;
u32 val;
- val = readl(&mdio->regs->control);
- return val & GENMASK(15, 0);
+ val = readl(&mdio->regs->alive);
+ return val & GENMASK(7, 0);
Referring to the TRM for AM335x at [0], on page 2401, the MDIOALIVE register
reports the presence of Ethernet PHYs up to ADDR 31. Also, the cpsw driver:
drivers/net/ti/cpsw.c which uses the cpsw_mdio_get_alive() function, expects the
return value to be a 16 bit value. Therefore, I believe that the GENMASK should
retain the previous value of "GENMASK(15, 0)", while only the register being
read needs to be changed from "control" to "alive". Please let me know if I
misunderstood something regarding your implementation.
We had an unusual H/W where the PHY (actually a switch) was connected to
the second Ethernet port. All boards I have seen have the PHY connected
to the first port or have both ports connected.
IIRC correctly (this patch is > 2 years old),
we had bad data in the bits (15:8) and this is why only the 8 bits.
Only bits [1:0] are used anyway.
[0] https://www.ti.com/lit/ug/spruh73q/spruh73q.pdf
Regards,
Siddharth.
}
struct mii_dev *cpsw_mdio_init(const char *name, phys_addr_t mdio_base,
Best Regards
Ulf Samuelsson
Re: [PATCH 1/5] mtd/spinand: rework detect procedure for different READ_ID operation
Hi, On 10.01.23 12:58, Frieder Schrempf wrote: > From: Mikhail Kshevetskiy > > Currently there are 3 different variants of read_id implementation: > 1. opcode only. Found in GD5FxGQ4xF. > 2. opcode + 1 addr byte. Found in GD5GxGQ4xA/E > 3. opcode + 1 dummy byte. Found in other currently supported chips. > > Original implementation was for variant 1 and let detect function > of chips with variant 2 and 3 to ignore the first byte. This isn't > robust: > > 1. For chips of variant 2, if SPI master doesn't keep MOSI low > during read, chip will get a random id offset, and the entire id > buffer will shift by that offset, causing detect failure. > > 2. For chips of variant 1, if it happens to get a devid that equals > to manufacture id of variant 2 or 3 chips, it'll get incorrectly > detected. > > This patch reworks detect procedure to address problems above. New > logic do detection for all variants separatedly, in 1-2-3 order. > Since all current detect methods do exactly the same id matching > procedure, unify them into core.c and remove detect method from > manufacture_ops. > > This is a rework of Chuanhong Guo patch > submitted to linux kernel > > Signed-off-by: Mikhail Kshevetskiy > Signed-off-by: Frieder Schrempf +Cc: Jagan, Tom Who is supposed to pick up these patches? Some of them have been around for some months (before I resent them). There is no maintainer for drivers/mtd/spinand/ and no maintainer for drivers/mtd/ in general. In Patchwork Jagan got assigned, but the get_maintainer.pl script didn't even add him to Cc, of course. Any ideas how to proceed? Thanks Frieder
[PATCH 2/2] riscv: ae350: Adjust the memory layout of ae350
Signed-off-by: Leo Yu-Chi Liang --- configs/ae350_rv32_spl_defconfig | 6 +++--- configs/ae350_rv32_spl_xip_defconfig | 6 +++--- configs/ae350_rv64_spl_defconfig | 6 +++--- configs/ae350_rv64_spl_xip_defconfig | 6 +++--- 4 files changed, 12 insertions(+), 12 deletions(-) diff --git a/configs/ae350_rv32_spl_defconfig b/configs/ae350_rv32_spl_defconfig index d61f7f5d1d..fd9f100be3 100644 --- a/configs/ae350_rv32_spl_defconfig +++ b/configs/ae350_rv32_spl_defconfig @@ -1,7 +1,9 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x0120 +CONFIG_TEXT_BASE=0x0180 CONFIG_SYS_MALLOC_LEN=0x8 CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x100 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="ae350_32" CONFIG_SYS_PROMPT="RISC-V # " @@ -12,8 +14,6 @@ CONFIG_TARGET_AE350=y CONFIG_RISCV_SMODE=y # CONFIG_AVAILABLE_HARTS is not set CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x00 CONFIG_SYS_MONITOR_LEN=786432 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x0020 diff --git a/configs/ae350_rv32_spl_xip_defconfig b/configs/ae350_rv32_spl_xip_defconfig index e59ba0c38a..16461e7bf9 100644 --- a/configs/ae350_rv32_spl_xip_defconfig +++ b/configs/ae350_rv32_spl_xip_defconfig @@ -1,7 +1,9 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x0120 +CONFIG_TEXT_BASE=0x0180 CONFIG_SYS_MALLOC_LEN=0x8 CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x100 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="ae350_32" CONFIG_SPL_TEXT_BASE=0x8000 @@ -13,8 +15,6 @@ CONFIG_TARGET_AE350=y CONFIG_RISCV_SMODE=y CONFIG_SPL_XIP=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x00 CONFIG_SYS_MONITOR_LEN=786432 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8001 diff --git a/configs/ae350_rv64_spl_defconfig b/configs/ae350_rv64_spl_defconfig index cb69514a7e..c2793cd593 100644 --- a/configs/ae350_rv64_spl_defconfig +++ b/configs/ae350_rv64_spl_defconfig @@ -1,7 +1,9 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x0120 +CONFIG_TEXT_BASE=0x0180 CONFIG_SYS_MALLOC_LEN=0x8 CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x100 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="ae350_64" CONFIG_SYS_PROMPT="RISC-V # " @@ -13,8 +15,6 @@ CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y # CONFIG_AVAILABLE_HARTS is not set CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xfffe70 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x0020 CONFIG_SYS_MONITOR_BASE=0x8800 diff --git a/configs/ae350_rv64_spl_xip_defconfig b/configs/ae350_rv64_spl_xip_defconfig index e0773fa0aa..bdc09d035d 100644 --- a/configs/ae350_rv64_spl_xip_defconfig +++ b/configs/ae350_rv64_spl_xip_defconfig @@ -1,7 +1,9 @@ CONFIG_RISCV=y -CONFIG_TEXT_BASE=0x0120 +CONFIG_TEXT_BASE=0x0180 CONFIG_SYS_MALLOC_LEN=0x8 CONFIG_NR_DRAM_BANKS=2 +CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y +CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x100 CONFIG_ENV_SECT_SIZE=0x1000 CONFIG_DEFAULT_DEVICE_TREE="ae350_64" CONFIG_SPL_TEXT_BASE=0x8000 @@ -14,8 +16,6 @@ CONFIG_ARCH_RV64I=y CONFIG_RISCV_SMODE=y CONFIG_SPL_XIP=y CONFIG_DISTRO_DEFAULTS=y -CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y -CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0xfffe70 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT_ADDRESS=0x8001 CONFIG_SYS_MONITOR_BASE=0x8800 -- 2.38.0.68.ge85701b4af.dirty
[PATCH 1/2] riscv: Rename Andes cpu and board names
The current ae350-related defconfigs could also
support newer Andes CPU IP, so modify the names of CPU
from ax25 to andesv5, and board name from ax25-ae350 to ae350.
Signed-off-by: Leo Yu-Chi Liang
---
arch/riscv/Kconfig | 8
arch/riscv/cpu/{ax25 => andesv5}/Kconfig | 0
arch/riscv/cpu/{ax25 => andesv5}/Makefile| 0
arch/riscv/cpu/{ax25 => andesv5}/cache.c | 0
arch/riscv/cpu/{ax25 => andesv5}/cpu.c | 0
arch/riscv/cpu/{ax25 => andesv5}/spl.c | 0
arch/riscv/dts/Makefile | 2 +-
board/AndesTech/{ax25-ae350 => ae350}/Kconfig| 8
.../AndesTech/{ax25-ae350 => ae350}/MAINTAINERS | 6 +++---
board/AndesTech/{ax25-ae350 => ae350}/Makefile | 2 +-
.../{ax25-ae350/ax25-ae350.c => ae350/ae350.c} | 0
configs/ae350_rv32_defconfig | 2 +-
configs/ae350_rv32_spl_defconfig | 2 +-
configs/ae350_rv32_spl_xip_defconfig | 2 +-
configs/ae350_rv32_xip_defconfig | 2 +-
configs/ae350_rv64_defconfig | 2 +-
configs/ae350_rv64_spl_defconfig | 2 +-
configs/ae350_rv64_spl_xip_defconfig | 2 +-
configs/ae350_rv64_xip_defconfig | 2 +-
.../AndesTech/{ax25-ae350.rst => ae350.rst} | 16
doc/board/AndesTech/index.rst| 2 +-
include/configs/{ax25-ae350.h => ae350.h}| 0
22 files changed, 30 insertions(+), 30 deletions(-)
rename arch/riscv/cpu/{ax25 => andesv5}/Kconfig (100%)
rename arch/riscv/cpu/{ax25 => andesv5}/Makefile (100%)
rename arch/riscv/cpu/{ax25 => andesv5}/cache.c (100%)
rename arch/riscv/cpu/{ax25 => andesv5}/cpu.c (100%)
rename arch/riscv/cpu/{ax25 => andesv5}/spl.c (100%)
rename board/AndesTech/{ax25-ae350 => ae350}/Kconfig (88%)
rename board/AndesTech/{ax25-ae350 => ae350}/MAINTAINERS (80%)
rename board/AndesTech/{ax25-ae350 => ae350}/Makefile (87%)
rename board/AndesTech/{ax25-ae350/ax25-ae350.c => ae350/ae350.c} (100%)
rename doc/board/AndesTech/{ax25-ae350.rst => ae350.rst} (98%)
rename include/configs/{ax25-ae350.h => ae350.h} (100%)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index ebc4bef220..48ca4ff4c4 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -8,8 +8,8 @@ choice
prompt "Target select"
optional
-config TARGET_AX25_AE350
- bool "Support ax25-ae350"
+config TARGET_AE350
+ bool "Support ae350"
config TARGET_MICROCHIP_ICICLE
bool "Support Microchip PolarFire-SoC Icicle Board"
@@ -58,7 +58,7 @@ config SPL_SYS_DCACHE_OFF
Do not enable data cache in SPL.
# board-specific options below
-source "board/AndesTech/ax25-ae350/Kconfig"
+source "board/AndesTech/ae350/Kconfig"
source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
source "board/sifive/unleashed/Kconfig"
@@ -67,7 +67,7 @@ source "board/openpiton/riscv64/Kconfig"
source "board/sipeed/maix/Kconfig"
# platform-specific options below
-source "arch/riscv/cpu/ax25/Kconfig"
+source "arch/riscv/cpu/andesv5/Kconfig"
source "arch/riscv/cpu/fu540/Kconfig"
source "arch/riscv/cpu/fu740/Kconfig"
source "arch/riscv/cpu/generic/Kconfig"
diff --git a/arch/riscv/cpu/ax25/Kconfig b/arch/riscv/cpu/andesv5/Kconfig
similarity index 100%
rename from arch/riscv/cpu/ax25/Kconfig
rename to arch/riscv/cpu/andesv5/Kconfig
diff --git a/arch/riscv/cpu/ax25/Makefile b/arch/riscv/cpu/andesv5/Makefile
similarity index 100%
rename from arch/riscv/cpu/ax25/Makefile
rename to arch/riscv/cpu/andesv5/Makefile
diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/andesv5/cache.c
similarity index 100%
rename from arch/riscv/cpu/ax25/cache.c
rename to arch/riscv/cpu/andesv5/cache.c
diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/andesv5/cpu.c
similarity index 100%
rename from arch/riscv/cpu/ax25/cpu.c
rename to arch/riscv/cpu/andesv5/cpu.c
diff --git a/arch/riscv/cpu/ax25/spl.c b/arch/riscv/cpu/andesv5/spl.c
similarity index 100%
rename from arch/riscv/cpu/ax25/spl.c
rename to arch/riscv/cpu/andesv5/spl.c
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 5c15a0f303..c576c55767 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0+
-dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
+dtb-$(CONFIG_TARGET_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
diff --git a/board/AndesTech/ax25-ae350/Kconfig b/board/AndesTech/ae350/Kconfig
similarity index 88%
rename from board/AndesTech/ax25-ae350/Kconfig
rename to board/AndesTech/ae350/Kconfig
index 4bb33b0793..75815bf99a 100644
--- a/board/AndesTech/ax25-ae350/Kconfig
+++ b/board/AndesTech/ae350/Kconfig
@@ -
