Re: [Upstream] [PATCH 6/6] configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITE
Hi, On 22.05.24 10:30, Wadim Egorov wrote: Hi Daniel, Am 22.05.24 um 08:18 schrieb Daniel Schultz: Enable CONFIG_ENV_OVERWRITE to overwrite ethaddr in the environment. This is required because our environment is not located in the boot partition. Signed-off-by: Daniel Schultz --- configs/phycore_am62x_a53_defconfig | 1 + What about the change for the phycore_am64x? Will enable phyCORE-AM64x later with additional changes to enable SOM detection. Regards, Daniel 1 file changed, 1 insertion(+) diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index fd36edc29dd..286cd89c5a6 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -59,6 +59,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y +CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_NET_RANDOM_ETHADDR=y
[PATCH] include: extension_board: Increase overlay file name size
Upstream overlays like the ARM64 TI
k3-am625-beagleplay-csi2-tevi-ov5640.dtso can easily have more then
32 characters. Increase the overlay length to 64 characters to
apply overlays with longer names.
Signed-off-by: Daniel Schultz
---
include/extension_board.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/extension_board.h b/include/extension_board.h
index 87d404c0074..22e4104bc54 100644
--- a/include/extension_board.h
+++ b/include/extension_board.h
@@ -14,7 +14,7 @@ struct extension {
char name[32];
char owner[32];
char version[32];
- char overlay[32];
+ char overlay[64];
char other[32];
};
--
2.25.1
[PATCH 6/6] configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITE
Enable CONFIG_ENV_OVERWRITE to overwrite ethaddr in the environment. This is required because our environment is not located in the boot partition. Signed-off-by: Daniel Schultz --- configs/phycore_am62x_a53_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/phycore_am62x_a53_defconfig b/configs/phycore_am62x_a53_defconfig index fd36edc29dd..286cd89c5a6 100644 --- a/configs/phycore_am62x_a53_defconfig +++ b/configs/phycore_am62x_a53_defconfig @@ -59,6 +59,7 @@ CONFIG_SPL_OF_CONTROL=y CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y +CONFIG_ENV_OVERWRITE=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_MMC_ENV_DEV=1 CONFIG_NET_RANDOM_ETHADDR=y -- 2.25.1
[PATCH 5/6] board: phytec: common: k3: Set MAC
Read the EEPROM API v3 content and set all available
MAC-Addresses to the environment.
Signed-off-by: Daniel Schultz
---
board/phytec/common/k3/board.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/board/phytec/common/k3/board.c b/board/phytec/common/k3/board.c
index 9cb168c36cb..f21e154d4fe 100644
--- a/board/phytec/common/k3/board.c
+++ b/board/phytec/common/k3/board.c
@@ -8,6 +8,8 @@
#include
#include
+#include "../am6_som_detection.h"
+
#if IS_ENABLED(CONFIG_ENV_IS_IN_FAT) || IS_ENABLED(CONFIG_ENV_IS_IN_MMC)
int mmc_get_env_dev(void)
{
@@ -68,6 +70,27 @@ int board_late_init(void)
break;
};
+ if (IS_ENABLED(CONFIG_PHYTEC_SOM_DETECTION_BLOCKS)) {
+ struct phytec_api3_element *block_element;
+ struct phytec_eeprom_data data;
+ int ret;
+
+ ret = phytec_eeprom_data_setup(, 0, EEPROM_ADDR);
+ if (ret || !data.valid)
+ return 0;
+
+ PHYTEC_API3_FOREACH_BLOCK(block_element, ) {
+ switch (block_element->block_type) {
+ case PHYTEC_API3_BLOCK_MAC:
+ phytec_blocks_add_mac_to_env(block_element);
+ break;
+ default:
+ debug("%s: Unknown block type %i\n", __func__,
+ block_element->block_type);
+ }
+ }
+ }
+
return 0;
}
#endif
--
2.25.1
[PATCH 4/6] board: phytec: common: Add API v3
This API is based on a block structure with a 8 Byte large
API v3 header and various of different blocks following. It extends
our current API v2, which is always 32 Byte large, and is located
directly after v2.
Add the MAC block as first block type. It contains the physical
Ehternet interface number, a MAC address and a CRC checksum over the
MAC payload.
Signed-off-by: Daniel Schultz
---
board/phytec/common/Kconfig | 9 ++
board/phytec/common/Makefile | 2 +-
board/phytec/common/phytec_som_detection.c| 153 ++
board/phytec/common/phytec_som_detection.h| 7 +
.../common/phytec_som_detection_blocks.c | 105
.../common/phytec_som_detection_blocks.h | 61 +++
6 files changed, 336 insertions(+), 1 deletion(-)
create mode 100644 board/phytec/common/phytec_som_detection_blocks.c
create mode 100644 board/phytec/common/phytec_som_detection_blocks.h
diff --git a/board/phytec/common/Kconfig b/board/phytec/common/Kconfig
index 1077f0f4b61..668afe2a534 100644
--- a/board/phytec/common/Kconfig
+++ b/board/phytec/common/Kconfig
@@ -4,6 +4,13 @@ config PHYTEC_SOM_DETECTION
help
Support of I2C EEPROM based SoM detection.
+config PHYTEC_SOM_DETECTION_BLOCKS
+ bool "Extend SoM detection with block support"
+ depends on PHYTEC_SOM_DETECTION
+ help
+ Extend the I2C EEPROM based SoM detection with API v3. This API
+ introduces blocks with different payloads.
+
config PHYTEC_IMX8M_SOM_DETECTION
bool "Support SoM detection for i.MX8M PHYTEC platforms"
depends on ARCH_IMX8M && PHYTEC_SOM_DETECTION
@@ -16,6 +23,7 @@ config PHYTEC_AM62_SOM_DETECTION
bool "Support SoM detection for AM62x PHYTEC platforms"
depends on (TARGET_PHYCORE_AM62X_A53 || TARGET_PHYCORE_AM62X_R5) && \
PHYTEC_SOM_DETECTION
+ select PHYTEC_SOM_DETECTION_BLOCKS
default y
help
Support of I2C EEPROM based SoM detection. Supported
@@ -25,6 +33,7 @@ config PHYTEC_AM64_SOM_DETECTION
bool "Support SoM detection for AM64x PHYTEC platforms"
depends on (TARGET_PHYCORE_AM64X_A53 || TARGET_PHYCORE_AM64X_R5) && \
PHYTEC_SOM_DETECTION
+ select PHYTEC_SOM_DETECTION_BLOCKS
default y
help
Support of I2C EEPROM based SoM detection. Supported
diff --git a/board/phytec/common/Makefile b/board/phytec/common/Makefile
index c34fc503059..446c481a6e6 100644
--- a/board/phytec/common/Makefile
+++ b/board/phytec/common/Makefile
@@ -9,6 +9,6 @@ else
obj-$(CONFIG_ARCH_K3) += k3/
endif
-obj-y += phytec_som_detection.o
+obj-y += phytec_som_detection.o phytec_som_detection_blocks.o
obj-$(CONFIG_ARCH_K3) += am6_som_detection.o
obj-$(CONFIG_ARCH_IMX8M) += imx8m_som_detection.o
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index ab2d5a7b726..166c3eae565 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -91,6 +91,134 @@ int phytec_eeprom_data_init_v2(struct phytec_eeprom_data
*data)
return 0;
}
+#if IS_ENABLED(CONFIG_PHYTEC_SOM_DETECTION_BLOCKS)
+
+int phytec_eeprom_data_init_v3_block(struct phytec_eeprom_data *data,
+struct phytec_api3_block_header *header,
+u8 *payload)
+{
+ struct phytec_api3_element *element = NULL;
+ struct phytec_api3_element *list_iterator;
+
+ if (!header)
+ return -1;
+ if (!payload)
+ return -1;
+
+ debug("%s: block type: %i\n", __func__, header->block_type);
+ switch (header->block_type) {
+ case PHYTEC_API3_BLOCK_MAC:
+ element = phytec_blocks_init_mac(header, payload);
+ break;
+ default:
+ debug("%s: Unknown block type %i\n", __func__,
+ header->block_type);
+ }
+ if (!element)
+ return -1;
+
+ if (!data->payload.block_head) {
+ data->payload.block_head = element;
+ return 0;
+ }
+
+ list_iterator = data->payload.block_head;
+ while (list_iterator && list_iterator->next)
+ list_iterator = list_iterator->next;
+ list_iterator->next = element;
+
+ return 0;
+}
+
+int phytec_eeprom_data_init_v3(struct phytec_eeprom_data *data,
+ int bus_num, int addr)
+{
+ int ret, i;
+ struct phytec_api3_header header;
+ unsigned int crc;
+ u8 *payload;
+ int block_addr;
+ struct phytec_api3_block_header *block_header;
+
+ if (!data)
+ return -1;
+
+ ret = phytec_eeprom_read((uint8_t *), bus_num, addr,
+
[PATCH 3/6] board: phytec: common: Move API v2 init to new function
Move the entire initialization code for API v2 into a dedicated
function. This rework will allow to easily integrate the API v3
as next step during init.
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 38 +-
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index f0e35d8d2ec..ab2d5a7b726 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -72,11 +72,29 @@ int phytec_eeprom_read(u8 *data, int bus_num, int addr, int
size, int offset)
return ret;
}
+int phytec_eeprom_data_init_v2(struct phytec_eeprom_data *data)
+{
+ unsigned int crc;
+
+ if (!data)
+ return -1;
+
+ crc = crc8(0, (const unsigned char *)>payload,
PHYTEC_API2_DATA_LEN);
+ debug("%s: crc: %x\n", __func__, crc);
+
+ if (crc) {
+ pr_err("%s: CRC mismatch. EEPROM data is not usable.\n",
+ __func__);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
int bus_num, int addr)
{
int ret, i;
- unsigned int crc;
u8 *ptr;
if (!data)
@@ -104,20 +122,10 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data
*data,
goto err;
}
- /* We are done here for early revisions */
- if (data->payload.api_rev <= PHYTEC_API_REV1) {
- data->valid = true;
- return 0;
- }
-
- crc = crc8(0, (const unsigned char *)>payload,
PHYTEC_API2_DATA_LEN);
- debug("%s: crc: %x\n", __func__, crc);
-
- if (crc) {
- pr_err("%s: CRC mismatch. EEPROM data is not usable.\n",
- __func__);
- ret = -EINVAL;
- goto err;
+ if (data->payload.api_rev >= PHYTEC_API_REV2) {
+ ret = phytec_eeprom_data_init_v2(data);
+ if (ret)
+ goto err;
}
data->valid = true;
--
2.25.1
[PATCH 2/6] board: phytec: common: Define PHYTEC_API2_DATA_LEN
The EEPROM image length for API v2 is fixed to 32 bytes. No need
to use sizeof while this value won't change. This value is
also be required for API v3 to know where the API v3 header starts.
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 9 -
board/phytec/common/phytec_som_detection.h | 2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index a089fe9bc90..f0e35d8d2ec 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -78,13 +78,12 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
int ret, i;
unsigned int crc;
u8 *ptr;
- const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
if (!data)
data = _data;
ret = phytec_eeprom_read((u8 *)data, bus_num, addr,
-payload_size, 0);
+PHYTEC_API2_DATA_LEN, 0);
if (ret)
goto err;
@@ -95,11 +94,11 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
}
ptr = (u8 *)data;
- for (i = 0; i < payload_size; ++i)
+ for (i = 0; i < PHYTEC_API2_DATA_LEN; ++i)
if (ptr[i] != 0x0)
break;
- if (i == payload_size) {
+ if (i == PHYTEC_API2_DATA_LEN) {
pr_err("%s: EEPROM data is all zero. Erased?\n", __func__);
ret = -EINVAL;
goto err;
@@ -111,7 +110,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
return 0;
}
- crc = crc8(0, (const unsigned char *)>payload, payload_size);
+ crc = crc8(0, (const unsigned char *)>payload,
PHYTEC_API2_DATA_LEN);
debug("%s: crc: %x\n", __func__, crc);
if (crc) {
diff --git a/board/phytec/common/phytec_som_detection.h
b/board/phytec/common/phytec_som_detection.h
index 0ad5c14ef4e..1ccf36c8e7a 100644
--- a/board/phytec/common/phytec_som_detection.h
+++ b/board/phytec/common/phytec_som_detection.h
@@ -10,6 +10,8 @@
#define PHYTEC_MAX_OPTIONS 17
#define PHYTEC_EEPROM_INVAL0xff
+#define PHYTEC_API2_DATA_LEN 32
+
#define PHYTEC_GET_OPTION(option) \
(((option) > '9') ? (option) - 'A' + 10 : (option) - '0')
--
2.25.1
[PATCH 1/6] board: phytec: common: Move eeprom read to new function
We need to read multiple times from different offsets in API v3.
Move the EEPROM read logic into a dedicated function to make it
usable multiple times.
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 38 ++
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index b14bb3dbb7f..a089fe9bc90 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -47,16 +47,9 @@ int phytec_eeprom_data_setup(struct phytec_eeprom_data *data,
return ret;
}
-int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
- int bus_num, int addr)
+int phytec_eeprom_read(u8 *data, int bus_num, int addr, int size, int offset)
{
- int ret, i;
- unsigned int crc;
- u8 *ptr;
- const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
-
- if (!data)
- data = _data;
+ int ret;
#if CONFIG_IS_ENABLED(DM_I2C)
struct udevice *dev;
@@ -64,19 +57,36 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
ret = i2c_get_chip_for_busnum(bus_num, addr, 2, );
if (ret) {
pr_err("%s: i2c EEPROM not found: %i.\n", __func__, ret);
- goto err;
+ return ret;
}
- ret = dm_i2c_read(dev, 0, (uint8_t *)data, payload_size);
+ ret = dm_i2c_read(dev, offset, (uint8_t *)data, size);
if (ret) {
pr_err("%s: Unable to read EEPROM data: %i\n", __func__, ret);
- goto err;
+ return ret;
}
#else
i2c_set_bus_num(bus_num);
- ret = i2c_read(addr, 0, 2, (uint8_t *)data,
- sizeof(struct phytec_eeprom_data));
+ ret = i2c_read(addr, offset, 2, (uint8_t *)data, size);
#endif
+ return ret;
+}
+
+int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
+ int bus_num, int addr)
+{
+ int ret, i;
+ unsigned int crc;
+ u8 *ptr;
+ const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
+
+ if (!data)
+ data = _data;
+
+ ret = phytec_eeprom_read((u8 *)data, bus_num, addr,
+payload_size, 0);
+ if (ret)
+ goto err;
if (data->payload.api_rev == 0xff) {
pr_err("%s: EEPROM is not flashed. Prototype?\n", __func__);
--
2.25.1
[PATCH 0/6] PHYTEC SOM Detection API v3
This patch series adds support for the EEPROM v3 API. V3 is backwards compatible to V2 and therefore, the V2 image still exists at the beginning. Only the API version changed from 2 to 3. V3 is a block-based memory layout organized as singled-linked list with different types of blocks. This is a more flexible approach and allows us to extend it by more block types in the future. The V3 data starts with a 8-byte large header which defines the block count (u8), V3 subversion (u8) and data payload length (u16). Additionally the header contains a CRC8 checksum a 3 reserved bytes. Each block starts with a 4-byte large header which defined the block type (u8), the absolute address of the next block (u16) and a CRC8 checksum. The content itself is defined via the block type and we currently have 2 different types: 1) MAC: Contains the Ethernet interface number (u8), MAC address (6 x u8) and a CRC8 checksum. Daniel Schultz (6): board: phytec: common: Move eeprom read to new function board: phytec: common: Define PHYTEC_API2_DATA_LEN board: phytec: common: Move API v2 init to new function board: phytec: common: Add API v3 board: phytec: common: k3: Set MAC configs: phycore_am62x_a53_defconfig: Enable CONFIG_ENV_OVERWRITE board/phytec/common/Kconfig | 9 + board/phytec/common/Makefile | 2 +- board/phytec/common/k3/board.c| 23 ++ board/phytec/common/phytec_som_detection.c| 228 +++--- board/phytec/common/phytec_som_detection.h| 9 + .../common/phytec_som_detection_blocks.c | 105 .../common/phytec_som_detection_blocks.h | 61 + configs/phycore_am62x_a53_defconfig | 1 + 8 files changed, 408 insertions(+), 30 deletions(-) create mode 100644 board/phytec/common/phytec_som_detection_blocks.c create mode 100644 board/phytec/common/phytec_som_detection_blocks.h -- 2.25.1
Re: [PATCH v3 12/12] mailmap: Update email for Paul Burton
On 5/17/24 20:15, Jiaxun Yang wrote: Paul had left MIPS a couple of years ago, his email address is no longer valid. Replace it with his kenrel.org email, which has been used in kernel and QEMU, in case we still want to reach him. Signed-off-by: Jiaxun Yang --- .mailmap| 3 ++- board/imgtec/boston/MAINTAINERS | 2 +- board/imgtec/malta/MAINTAINERS | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 11/12] MIPS: boston: Migrate to OF_UPSTREAM
On 5/17/24 20:14, Jiaxun Yang wrote:
We can now boot with upstream devicetree.
Reviewed-by: Sumit Garg
Signed-off-by: Jiaxun Yang
---
arch/mips/Kconfig| 1 +
arch/mips/dts/Makefile | 1 -
arch/mips/dts/boston-u-boot.dtsi | 10 ++
arch/mips/dts/img,boston.dts | 222 ---
board/imgtec/boston/MAINTAINERS | 1 +
configs/boston32r2_defconfig | 2 +-
configs/boston32r2el_defconfig | 2 +-
configs/boston32r6_defconfig | 2 +-
configs/boston32r6el_defconfig | 2 +-
configs/boston64r2_defconfig | 2 +-
configs/boston64r2el_defconfig | 2 +-
configs/boston64r6_defconfig | 2 +-
configs/boston64r6el_defconfig | 2 +-
13 files changed, 20 insertions(+), 231 deletions(-)
Reviewed-by: Daniel Schwierzeck
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 748b5175b2eb..733a8de4fb83 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -146,6 +146,7 @@ config TARGET_BOSTON
select SUPPORTS_CPU_MIPS64_R2
select SUPPORTS_CPU_MIPS64_R6
select SUPPORTS_LITTLE_ENDIAN
+ imply OF_UPSTREAM
should be 'select' because the switch to upstream DTS is permanent and
it does not make sense for the user to be able to deselect this option
imply BOOTSTD_FULL
imply CLK
imply CLK_BOSTON
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 14fbce597b9e..5478dcd8d025 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -3,7 +3,6 @@
dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
-dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
dtb-$(CONFIG_TARGET_XILFPGA) += nexys4ddr.dtb
diff --git a/arch/mips/dts/boston-u-boot.dtsi b/arch/mips/dts/boston-u-boot.dtsi
new file mode 100644
index ..1b0c0a289613
--- /dev/null
+++ b/arch/mips/dts/boston-u-boot.dtsi
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+_regs {
+ compatible = "img,boston-platform-regs", "syscon", "simple-mfd";
+ bootph-all;
+};
+
+_boston {
+ bootph-all;
+};
diff --git a/arch/mips/dts/img,boston.dts b/arch/mips/dts/img,boston.dts
deleted file mode 100644
index c1a73963037d..
--- a/arch/mips/dts/img,boston.dts
+++ /dev/null
@@ -1,222 +0,0 @@
-/dts-v1/;
-
-#include
-#include
-#include
-#include
-
-/ {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "img,boston";
-
- chosen {
- stdout-path =
- };
-
- cpus {
- #address-cells = <1>;
- #size-cells = <0>;
-
- cpu@0 {
- device_type = "cpu";
- compatible = "img,mips";
- reg = <0>;
- clocks = <_boston BOSTON_CLK_CPU>;
- };
- };
-
- memory@0 {
- device_type = "memory";
- reg = <0x 0x1000>;
- };
-
- gic: interrupt-controller {
- compatible = "mti,gic";
-
- interrupt-controller;
- #interrupt-cells = <3>;
-
- timer {
- compatible = "mti,gic-timer";
- interrupts = ;
- clocks = <_boston BOSTON_CLK_CPU>;
- };
- };
-
- pci0: pci@1000 {
- status = "disabled";
- compatible = "xlnx,axi-pcie-host-1.00.a";
- device_type = "pci";
- reg = <0x1000 0x200>;
-
- #address-cells = <3>;
- #size-cells = <2>;
- #interrupt-cells = <1>;
-
- interrupt-parent = <>;
- interrupts = ;
-
- ranges = <0x0200 0 0x4000
- 0x4000 0 0x4000>;
-
- interrupt-map-mask = <0 0 0 7>;
- interrupt-map = <0 0 0 1 _intc 0>,
- <0 0 0 2 _intc 1>,
- <0 0 0 3 _intc 2>,
- <0 0 0 4 _intc 3>;
-
- pci0_intc: interrupt-controller {
- interrupt-controller;
- #address-cells = <0>;
- #interrupt-cells = <1>;
- };
- };
-
- pci1: pci@1200 {
- status = "disabled";
- compatible = "xlnx,axi-pcie-host-1.00.a";
- device_type = "pci";
- reg = <0x1200 0x200>;
Re: [PATCH v3 10/12] dts/upstream: Add Makefile for MIPS
On 5/17/24 20:14, Jiaxun Yang wrote: It is required to make OF_UPSTREAM work. Reviewed-by: Sumit Garg Signed-off-by: Jiaxun Yang --- dts/upstream/src/mips/Makefile | 14 ++ 1 file changed, 14 insertions(+) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 09/12] clk: boston: Allow to get regmap from parent device
On 5/17/24 20:14, Jiaxun Yang wrote: In upstream devicetree, clk_boston is a child of syscon node and there is no "regmap" property for clk_boston node. Try to check parent device first to look for syscon. Signed-off-by: Jiaxun Yang --- v2: Move syscon_get_regmap to probe v3: Move syscon detection code to probe to ensure parent is probbed before syscon_get_regmap. --- drivers/clk/clk_boston.c | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 08/12] MIPS: boston: Provide default env vars
On 5/17/24 20:14, Jiaxun Yang wrote: Provide default environment variables on image loading address to make the board useful. Signed-off-by: Jiaxun Yang --- board/imgtec/boston/Kconfig| 4 board/imgtec/boston/boston.env | 9 + 2 files changed, 13 insertions(+) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 07/12] MIPS: boston: Imply various options
On 5/17/24 20:14, Jiaxun Yang wrote: This is a PC-like platform board. Enable drivers for most on-board devices to make it useful. Signed-off-by: Jiaxun Yang --- arch/mips/Kconfig | 27 +++ 1 file changed, 27 insertions(+) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 06/12] MIPS: Provide dummy acpi_table.h
On 5/17/24 20:14, Jiaxun Yang wrote: Some drivers need this header. Provide this dummy header as riscv did. Signed-off-by: Jiaxun Yang --- arch/mips/include/asm/acpi_table.h | 10 ++ 1 file changed, 10 insertions(+) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 03/12] pci: Enable PCI_MAP_SYSTEM_MEMORY when ARCH_MAP_SYSMEM is not set
On 5/17/24 20:14, Jiaxun Yang wrote: For MIPS we are always looking gd->dram in virtual address so PCI_MAP_SYSTEM_MEMORY should always be enabled. If in future we ever want to make it physical we have to set ARCH_MAP_SYSMEM. Signed-off-by: Jiaxun Yang --- drivers/pci/Kconfig | 1 + 1 file changed, 1 insertion(+) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 02/12] pci: auto: Reduce bridge mem alignment boundary for boston
On 5/17/24 20:14, Jiaxun Yang wrote: Boston has a very limited memory range for PCI controllers, where 1MB can't easily fit into it. Make alignment boundary of PCI memory resource allocation a Kconfig option and default to 0x1 for boston. Signed-off-by: Jiaxun Yang --- drivers/pci/Kconfig| 9 + drivers/pci/pci_auto.c | 16 2 files changed, 17 insertions(+), 8 deletions(-) Reviewed-by: Daniel Schwierzeck
Re: [PATCH v3 01/12] pci: xilinx: Handle size of ecam region properly
On 5/17/24 20:14, Jiaxun Yang wrote: Probe size of ecam from devicetree properly and cap accessible bus number accorading to ecam region size to ensure we don't go beyond hardware address space. Also disable all interrupts to ensure errors are handled silently. Signed-off-by: Jiaxun Yang --- drivers/pci/pcie_xilinx.c | 53 +++ 1 file changed, 40 insertions(+), 13 deletions(-) Reviewed-by: Daniel Schwierzeck
Re: [PATCH 5/5] board: phytec: am62x: Add support for 1 & 4 GB RAM variants
Hey Wadim,
On 07.05.24 17:17, Wadim Egorov wrote:
Use content of EEPROM to detect the actual RAM size and adjust
DDR timings, size and banks accordingly.
Also enable the SoM detection per default in the defconfigs.
Signed-off-by: Wadim Egorov
---
board/phytec/common/am6_som_detection.h | 8 +
board/phytec/phycore_am62x/phycore-am62x.c| 152 -
board/phytec/phycore_am62x/phycore-ddr-data.h | 206 ++
configs/phycore_am62x_a53_defconfig | 4 +
configs/phycore_am62x_r5_defconfig| 4 +
5 files changed, 372 insertions(+), 2 deletions(-)
create mode 100644 board/phytec/phycore_am62x/phycore-ddr-data.h
diff --git a/board/phytec/common/am6_som_detection.h
b/board/phytec/common/am6_som_detection.h
index 032f9da3aab..c5c6e179da6 100644
--- a/board/phytec/common/am6_som_detection.h
+++ b/board/phytec/common/am6_som_detection.h
@@ -9,11 +9,19 @@
#include "phytec_som_detection.h"
+#define EEPROM_ADDR0x50
#define PHYTEC_AM62X_SOM 71
#define PHYTEC_AM64X_SOM 72
#define PHYTEC_EEPROM_VALUE_X 0x21
#define PHYTEC_EEPROM_NOR_FLASH_64MB_QSPI 0xC
+enum {
+ EEPROM_RAM_SIZE_512MB = 0,
+ EEPROM_RAM_SIZE_1GB = 1,
+ EEPROM_RAM_SIZE_2GB = 2,
+ EEPROM_RAM_SIZE_4GB = 4
+};
+
int __maybe_unused phytec_am6_detect(struct phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_am6_ddr_size(struct phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_am6_spi(struct phytec_eeprom_data *data);
diff --git a/board/phytec/phycore_am62x/phycore-am62x.c
b/board/phytec/phycore_am62x/phycore-am62x.c
index a082b886bda..4a76f1343d7 100644
--- a/board/phytec/phycore_am62x/phycore-am62x.c
+++ b/board/phytec/phycore_am62x/phycore-am62x.c
@@ -8,6 +8,13 @@
#include
#include
+#include "phycore-ddr-data.h"
+#include "../common/k3/k3_ddrss_patch.h"
+#include "../common/am6_som_detection.h"
+
+#define AM64_DDRSS_SS_BASE 0x0F30
+#define DDRSS_V2A_CTL_REG 0x0020
+
DECLARE_GLOBAL_DATA_PTR;
int board_init(void)
@@ -15,16 +22,157 @@ int board_init(void)
return 0;
}
+static u8 phytec_get_am62_ddr_size_default(void)
+{
+ int ret;
+ struct phytec_eeprom_data data;
+
+ if (IS_ENABLED(CONFIG_PHYCORE_AM62X_RAM_SIZE_FIX)) {
+ if (IS_ENABLED(CONFIG_PHYCORE_AM62X_RAM_SIZE_1GB))
+ return EEPROM_RAM_SIZE_1GB;
+ else if (IS_ENABLED(CONFIG_PHYCORE_AM62X_RAM_SIZE_2GB))
+ return EEPROM_RAM_SIZE_2GB;
+ else if (IS_ENABLED(CONFIG_PHYCORE_AM62X_RAM_SIZE_4GB))
+ return EEPROM_RAM_SIZE_4GB;
+ }
Please define these configs in board/phytec/phycore_am62x/Kconfig.
- Daniel
+
+ ret = phytec_eeprom_data_setup(, 0, EEPROM_ADDR);
+ if (!ret && data.valid)
+ return phytec_get_am6_ddr_size();
+
+ /* Default DDR size is 2GB */
+ return EEPROM_RAM_SIZE_2GB;
+}
+
int dram_init(void)
{
- return fdtdec_setup_mem_size_base();
+ u8 ram_size = phytec_get_am62_ddr_size_default();
+
+ /*
+* HACK: ddrss driver support 2GB RAM by default
+* V2A_CTL_REG should be updated to support other RAM size
+*/
+ if (IS_ENABLED(CONFIG_K3_AM64_DDRSS))
+ if (ram_size == EEPROM_RAM_SIZE_4GB)
+ writel(0x0210, AM64_DDRSS_SS_BASE +
DDRSS_V2A_CTL_REG);
+
+ switch (ram_size) {
+ case EEPROM_RAM_SIZE_1GB:
+ gd->ram_size = 0x4000;
+ break;
+ case EEPROM_RAM_SIZE_2GB:
+ gd->ram_size = 0x8000;
+ break;
+ case EEPROM_RAM_SIZE_4GB:
+#ifdef CONFIG_PHYS_64BIT
+ gd->ram_size = 0x1;
+#else
+ gd->ram_size = 0x8000;
+#endif
+ break;
+ default:
+ gd->ram_size = 0x8000;
+ }
+
+ return 0;
+}
+
+phys_size_t board_get_usable_ram_top(phys_size_t total_size)
+{
+#ifdef CONFIG_PHYS_64BIT
+ /* Limit RAM used by U-Boot to the DDR low region */
+ if (gd->ram_top > 0x1)
+ return 0x1;
+#endif
+ return gd->ram_top;
}
int dram_init_banksize(void)
{
- return fdtdec_setup_memory_banksize();
+ u8 ram_size;
+
+ ram_size = phytec_get_am62_ddr_size_default();
+ switch (ram_size) {
+ case EEPROM_RAM_SIZE_1GB:
+ gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = 0x4000;
+ gd->ram_size = 0x4000;
+ break;
+
+ case EEPROM_RAM_SIZE_2GB:
+ gd->bd->bi_dram[0].start = CFG_SYS_SDRAM_BASE;
+ gd->bd->bi_dram[0].size = 0x8000;
+ gd->ram_size = 0x8000;
+
Re: RISC-V u-boot unable to boot QEMU using '-cpu max'
On 4/23/24 09:41, Conor Dooley wrote:
On Tue, Apr 23, 2024 at 01:34:42PM +0800, Leo Liang wrote:
On Mon, Apr 22, 2024 at 04:43:59PM -0300, Daniel Henrique Barboza wrote:
[EXTERNAL MAIL]
Hi,
In QEMU we have a 'max' type CPU that implements (almost) all extensions that
QEMU
is able to emulate. Recently, in QEMU commit 249e0905d05, we bumped the
extensions
for this CPU.
And after this commit this CPU is now unable to boot a guest using upstream
u-boot. Here's the error being thrown:
qemu-system-riscv64 \
-machine virt -nographic -m 8G -smp 8 \
-cpu max -kernel uboot.elf (...)
(...)
initcall sequence 8027c3e8 failed at call 8021259e (err=-28)
### ERROR ### Please RESET the board ###
I can get the guest to boot if I disable the following extensions from the
'max' CPU:
-cpu max,zfbfmin=false,zvfbfmin=false,zvfbfwma=false
Due to QEMU extension dependencies I'm not able to disable these individually.
What I can
say is that u-boot isn't playing ball to at least one of them.
Is this an u-boot bug? Up to this point I was assuming that u-boot would
silently ignore
hart extensions that it doesn't support.
Hi Daniel,
Which u-boot version are you using?
I think this issue is fixed by the following patch set sent by Conor.
f39b1b77d8 riscv: support extension probing using riscv, isa-extensions
b90edde701 riscv: don't read riscv, isa in the riscv cpu's get_desc()
I've tested and can reproduce the issue you mentioned if these two patches are
reverted.
Could you try with the lastest u-boot master branch again?
For reference, my testing commands are as follows:
1. cd ${u-boot} && make qemu-riscv64_defconfig && make -j`nproc`
2. ./${qemu}/build/qemu-system-riscv64 -nographic -machine virt -cpu max -bios
u-boot.bin -m 8G -smp 8
- u-boot branch (commit): master (38ea74d6d5c0 "Prepare v2024.07-rc1")
- qemu branch (commit): master (62dbe54c24db "Update version for v9.0.0-rc4
release")
I'll go take a look at this, it's possible that my patches only hide the
problem due to the new property being prioritised.
Don't bother. I just checked with most recent u-boot master and I can't
reproduce the
problem, as Leo said.
I apologize for the noise. I failed to fetch the latest upstream and do a last
test before posting it here.
We were discussing here and there about disabling these extensions in the 'max'
CPU in QEMU if u-boot wasn't able to handle them. I'm happy to see that u-boot
is now able to do so and we can keep the 'max' CPU as is.
Thanks for the help,
Daniel
RISC-V u-boot unable to boot QEMU using '-cpu max'
Hi, In QEMU we have a 'max' type CPU that implements (almost) all extensions that QEMU is able to emulate. Recently, in QEMU commit 249e0905d05, we bumped the extensions for this CPU. And after this commit this CPU is now unable to boot a guest using upstream u-boot. Here's the error being thrown: qemu-system-riscv64 \ -machine virt -nographic -m 8G -smp 8 \ -cpu max -kernel uboot.elf (...) (...) initcall sequence 8027c3e8 failed at call 8021259e (err=-28) ### ERROR ### Please RESET the board ### I can get the guest to boot if I disable the following extensions from the 'max' CPU: -cpu max,zfbfmin=false,zvfbfmin=false,zvfbfwma=false Due to QEMU extension dependencies I'm not able to disable these individually. What I can say is that u-boot isn't playing ball to at least one of them. Is this an u-boot bug? Up to this point I was assuming that u-boot would silently ignore hart extensions that it doesn't support. Thanks, Daniel
[PATCH 5/5] board: phytec: Add SOM detection for AM6x
Add all functions to read each SOM option from the EEPROM
image and detect whether it's the correct product for this
image.
Signed-off-by: Daniel Schultz
---
board/phytec/common/Kconfig | 18 +++
board/phytec/common/Makefile| 1 +
board/phytec/common/am6_som_detection.c | 159
board/phytec/common/am6_som_detection.h | 36 ++
board/phytec/phycore_am62x/Kconfig | 4 +
board/phytec/phycore_am64x/Kconfig | 4 +
6 files changed, 222 insertions(+)
create mode 100644 board/phytec/common/am6_som_detection.c
create mode 100644 board/phytec/common/am6_som_detection.h
diff --git a/board/phytec/common/Kconfig b/board/phytec/common/Kconfig
index 3b1c5aa0d02..1077f0f4b61 100644
--- a/board/phytec/common/Kconfig
+++ b/board/phytec/common/Kconfig
@@ -11,3 +11,21 @@ config PHYTEC_IMX8M_SOM_DETECTION
help
Support of I2C EEPROM based SoM detection. Supported
for PHYTEC i.MX8MM/i.MX8MP boards
+
+config PHYTEC_AM62_SOM_DETECTION
+ bool "Support SoM detection for AM62x PHYTEC platforms"
+ depends on (TARGET_PHYCORE_AM62X_A53 || TARGET_PHYCORE_AM62X_R5) && \
+ PHYTEC_SOM_DETECTION
+ default y
+ help
+ Support of I2C EEPROM based SoM detection. Supported
+ for PHYTEC AM62x boards.
+
+config PHYTEC_AM64_SOM_DETECTION
+ bool "Support SoM detection for AM64x PHYTEC platforms"
+ depends on (TARGET_PHYCORE_AM64X_A53 || TARGET_PHYCORE_AM64X_R5) && \
+ PHYTEC_SOM_DETECTION
+ default y
+ help
+ Support of I2C EEPROM based SoM detection. Supported
+ for PHYTEC AM64x boards.
diff --git a/board/phytec/common/Makefile b/board/phytec/common/Makefile
index 35c81741306..3feb00fd1ec 100644
--- a/board/phytec/common/Makefile
+++ b/board/phytec/common/Makefile
@@ -8,4 +8,5 @@ obj- := __dummy__.o
endif
obj-y += phytec_som_detection.o
+obj-$(CONFIG_ARCH_K3) += am6_som_detection.o
obj-$(CONFIG_ARCH_IMX8M) += imx8m_som_detection.o
diff --git a/board/phytec/common/am6_som_detection.c
b/board/phytec/common/am6_som_detection.c
new file mode 100644
index 000..2e9884dab44
--- /dev/null
+++ b/board/phytec/common/am6_som_detection.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2024 PHYTEC Messtechnik GmbH
+ * Author: Daniel Schultz
+ */
+
+#include
+
+#include "am6_som_detection.h"
+
+extern struct phytec_eeprom_data eeprom_data;
+
+#if IS_ENABLED(CONFIG_PHYTEC_AM62_SOM_DETECTION) || \
+ IS_ENABLED(CONFIG_PHYTEC_AM64_SOM_DETECTION)
+
+/* Check if the SoM is actually one of the following products:
+ * - phyCORE-AM62x
+ * - phyCORE-AM64x
+ *
+ * Returns 0 in case it's a known SoM. Otherwise, returns -1.
+ */
+int phytec_am6_detect(struct phytec_eeprom_data *data)
+{
+ char *opt;
+ u8 som;
+
+ if (!data)
+ data = _data;
+
+ /* We cannot do the check for early API revisions */
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return -1;
+
+ som = data->payload.data.data_api2.som_no;
+ debug("%s: som id: %u\n", __func__, som);
+
+ opt = phytec_get_opt(data);
+ if (!opt)
+ return -1;
+
+ if (som == PHYTEC_AM62X_SOM && soc_is_am62x())
+ return 0;
+
+ if (som == PHYTEC_AM64X_SOM && soc_is_am64x())
+ return 0;
+
+ return -1;
+}
+
+static u8 phytec_check_opt(struct phytec_eeprom_data *data, u8 option)
+{
+ char *opt;
+
+ if (!data)
+ data = _data;
+
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return PHYTEC_EEPROM_INVAL;
+
+ if (option > 8)
+ return PHYTEC_EEPROM_INVAL;
+
+ opt = phytec_get_opt(data);
+ if (opt)
+ return PHYTEC_GET_OPTION(opt[option]);
+ return PHYTEC_EEPROM_INVAL;
+}
+
+/*
+ * Reads LPDDR4 ram size from EEPROM.
+ *
+ * returns:
+ * - The size
+ * - PHYTEC_EEPROM_INVAL when the data is invalid.
+ */
+u8 __maybe_unused phytec_get_am62_ddr_size(struct phytec_eeprom_data *data)
+{
+ u8 ddr_id = phytec_check_opt(data, 3);
+
+ pr_debug("%s: ddr id: %u\n", __func__, ddr_id);
+ return ddr_id;
+}
+
+/*
+ * Reads SPI-NOR flash size and type from EEPROM.
+ *
+ * returns:
+ * - PHYTEC_EEPROM_VALUE_X if no SPI is poulated.
+ * - Otherwise a board depended code for the size.
+ * - PHYTEC_EEPROM_INVAL when the data is invalid.
+ */
+u8 __maybe_unused phytec_get_am62_spi(struct phytec_eeprom_data *data)
+{
+ u8 spi = phytec_check_opt(data, 5);
+
+ pr_debug("%s: spi: %u\n", __func__, spi);
+ return spi;
+}
+
+/*
+ * Reads Ethernet phy information from EEPROM.
+ *
+ * returns:
+ * - 0x0 no ethernet phy is populated.
+ * - 0x1 if 10/100/1000 MBit Phy i
[PATCH 4/5] board: phytec: common: Fix eepom is empty check
The ptr variable is currently defined as int and sizeof
returns the size of the eeprom data struct as Byte (32 in total).
In case the eeprom is empty, the check, if the eeprom is empty,
will most likely stop after 8 iterations because it will continue
with the stack which should contain some data. Therefore, the
init function will detect an empty EEPROM as API0 and return with
the valid flag set to True.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection")
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index 5a4cc9e8b02..78c173df20d 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -53,7 +53,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
{
int ret, i;
unsigned int crc;
- int *ptr;
+ u8 *ptr;
const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
if (!data)
@@ -85,7 +85,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
goto err;
}
- ptr = (int *)data;
+ ptr = (u8 *)data;
for (i = 0; i < payload_size; ++i)
if (ptr[i] != 0x0)
break;
--
2.25.1
[PATCH 3/5] board: phytec: check eeprom_data validity
From: Yannic Moog
For all of the functions that access the eeprom_data, make sure these
data are valid. Use the valid member of the phytec_eeprom_data struct.
This fixes a bug where only the API revision check guarded against
accessing rubbish. But if API revision was e.g. 6, eeprom setup failed
before, but phytec_get_imx8m_eth would still happily access the data.
Fixes: dc22188cdc8 ("board: phytec: Add common PHYTEC SoM detection")
Signed-off-by: Yannic Moog
Signed-off-by: Daniel Schultz
---
board/phytec/common/imx8m_som_detection.c | 11 +++
board/phytec/common/phytec_som_detection.c | 10 +++---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/board/phytec/common/imx8m_som_detection.c
b/board/phytec/common/imx8m_som_detection.c
index 7571076a09e..ee34a5b9579 100644
--- a/board/phytec/common/imx8m_som_detection.c
+++ b/board/phytec/common/imx8m_som_detection.c
@@ -34,7 +34,7 @@ int __maybe_unused phytec_imx8m_detect(struct
phytec_eeprom_data *data)
data = _data;
/* We can not do the check for early API revisions */
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return -1;
som = data->payload.data.data_api2.som_no;
@@ -75,6 +75,9 @@ u8 __maybe_unused phytec_get_imx8m_ddr_size(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
+ return PHYTEC_EEPROM_INVAL;
+
opt = phytec_get_opt(data);
if (opt)
ddr_id = PHYTEC_GET_OPTION(opt[2]);
@@ -99,7 +102,7 @@ u8 __maybe_unused phytec_get_imx8m_spi(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -126,7 +129,7 @@ u8 __maybe_unused phytec_get_imx8m_eth(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -154,7 +157,7 @@ u8 __maybe_unused phytec_get_imx8mp_rtc(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index 7913764be0a..5a4cc9e8b02 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -128,7 +128,7 @@ void __maybe_unused phytec_print_som_info(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return;
api2 = >payload.data.data_api2;
@@ -190,6 +190,9 @@ char * __maybe_unused phytec_get_opt(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
+ if (!data->valid)
+ return NULL;
+
if (data->payload.api_rev < PHYTEC_API_REV2)
opt = data->payload.data.data_api0.opt;
else
@@ -205,7 +208,7 @@ u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data
*data)
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
api2 = >payload.data.data_api2;
@@ -217,7 +220,8 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
{
if (!data)
data = _data;
- if (data->payload.api_rev < PHYTEC_API_REV2)
+
+ if (!data->valid || data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
return data->payload.data.data_api2.som_type;
--
2.25.1
[PATCH 2/5] board: phytec: introduce eeprom struct member 'valid'
From: Yannic Moog
Add a new nember to the eeprom_data that indicates whether the
associated data is valid or not. Make use of this new member in the
phytec_eeprom_data_init function by setting the valid value
appropriately.
Move the eeprom data to a new struct payload that holds
the payload of the eeprom.
Signed-off-by: Yannic Moog
Signed-off-by: Daniel Schultz
---
board/phytec/common/imx8m_som_detection.c | 10 ++--
board/phytec/common/phytec_som_detection.c | 56 --
board/phytec/common/phytec_som_detection.h | 11 +++--
3 files changed, 45 insertions(+), 32 deletions(-)
diff --git a/board/phytec/common/imx8m_som_detection.c
b/board/phytec/common/imx8m_som_detection.c
index 214b75db3b0..7571076a09e 100644
--- a/board/phytec/common/imx8m_som_detection.c
+++ b/board/phytec/common/imx8m_som_detection.c
@@ -34,10 +34,10 @@ int __maybe_unused phytec_imx8m_detect(struct
phytec_eeprom_data *data)
data = _data;
/* We can not do the check for early API revisions */
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return -1;
- som = data->data.data_api2.som_no;
+ som = data->payload.data.data_api2.som_no;
debug("%s: som id: %u\n", __func__, som);
opt = phytec_get_opt(data);
@@ -99,7 +99,7 @@ u8 __maybe_unused phytec_get_imx8m_spi(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -126,7 +126,7 @@ u8 __maybe_unused phytec_get_imx8m_eth(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
@@ -154,7 +154,7 @@ u8 __maybe_unused phytec_get_imx8mp_rtc(struct
phytec_eeprom_data *data)
if (!data)
data = _data;
- if (data->api_rev < PHYTEC_API_REV2)
+ if (data->payload.api_rev < PHYTEC_API_REV2)
return PHYTEC_EEPROM_INVAL;
opt = phytec_get_opt(data);
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index d167a77c25b..7913764be0a 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -54,6 +54,7 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
int ret, i;
unsigned int crc;
int *ptr;
+ const unsigned int payload_size = sizeof(struct phytec_eeprom_payload);
if (!data)
data = _data;
@@ -64,14 +65,13 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
ret = i2c_get_chip_for_busnum(bus_num, addr, 2, );
if (ret) {
pr_err("%s: i2c EEPROM not found: %i.\n", __func__, ret);
- return ret;
+ goto err;
}
- ret = dm_i2c_read(dev, 0, (uint8_t *)data,
- sizeof(struct phytec_eeprom_data));
+ ret = dm_i2c_read(dev, 0, (uint8_t *)data, payload_size);
if (ret) {
- pr_err("%s: Unable to read EEPROM data\n", __func__);
- return ret;
+ pr_err("%s: Unable to read EEPROM data: %i\n", __func__, ret);
+ goto err;
}
#else
i2c_set_bus_num(bus_num);
@@ -79,36 +79,44 @@ int phytec_eeprom_data_init(struct phytec_eeprom_data *data,
sizeof(struct phytec_eeprom_data));
#endif
- if (data->api_rev == 0xff) {
+ if (data->payload.api_rev == 0xff) {
pr_err("%s: EEPROM is not flashed. Prototype?\n", __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
ptr = (int *)data;
- for (i = 0; i < sizeof(struct phytec_eeprom_data); i++)
+ for (i = 0; i < payload_size; ++i)
if (ptr[i] != 0x0)
break;
- if (i == sizeof(struct phytec_eeprom_data)) {
+ if (i == payload_size) {
pr_err("%s: EEPROM data is all zero. Erased?\n", __func__);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err;
}
/* We are done here for early revisions */
- if (data->api_rev <= PHYTEC_API_REV1)
+ if (data->payload.api_rev <= PHYTEC_API_REV1) {
+ data->valid = true;
return 0;
+ }
- crc = crc8(0, (const unsigned char *)data,
- sizeof(struct phytec_eeprom_data));
+ crc = crc8(0, (const unsigned char *)>payload, payload_
[PATCH 1/5] board: phytec: common: Generic "add extension" function
Add a generic function to apply overlays in our board code to not
implement the same logic in different PHYTEC products.
Signed-off-by: Daniel Schultz
---
board/phytec/common/phytec_som_detection.c | 33 ++
board/phytec/common/phytec_som_detection.h | 5
2 files changed, 38 insertions(+)
diff --git a/board/phytec/common/phytec_som_detection.c
b/board/phytec/common/phytec_som_detection.c
index a56e0f60d62..d167a77c25b 100644
--- a/board/phytec/common/phytec_som_detection.c
+++ b/board/phytec/common/phytec_som_detection.c
@@ -9,6 +9,8 @@
#include
#include
#include
+#include
+#include
#include "phytec_som_detection.h"
@@ -213,6 +215,28 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
return data->data.data_api2.som_type;
}
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+struct extension *phytec_add_extension(const char *name, const char *overlay,
+ const char *other)
+{
+ struct extension *extension;
+
+ if (strlen(overlay) > sizeof(extension->overlay)) {
+ pr_err("Overlay name %s is longer than %lu.\n", overlay,
+ sizeof(extension->overlay));
+ return NULL;
+ }
+
+ extension = calloc(1, sizeof(struct extension));
+ snprintf(extension->name, sizeof(extension->name), name);
+ snprintf(extension->overlay, sizeof(extension->overlay), overlay);
+ snprintf(extension->other, sizeof(extension->other), other);
+ snprintf(extension->owner, sizeof(extension->owner), "PHYTEC");
+
+ return extension;
+}
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#else
inline int phytec_eeprom_data_setup(struct phytec_eeprom_data *data,
@@ -253,4 +277,13 @@ u8 __maybe_unused phytec_get_som_type(struct
phytec_eeprom_data *data)
return PHYTEC_EEPROM_INVAL;
}
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+inline struct extension *phytec_add_extension(const char *name,
+ const char *overlay,
+ const char *other)
+{
+ return NULL;
+}
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#endif /* IS_ENABLED(CONFIG_PHYTEC_SOM_DETECTION) */
diff --git a/board/phytec/common/phytec_som_detection.h
b/board/phytec/common/phytec_som_detection.h
index 7edbfa3ca5c..ea99a687fee 100644
--- a/board/phytec/common/phytec_som_detection.h
+++ b/board/phytec/common/phytec_som_detection.h
@@ -76,4 +76,9 @@ char * __maybe_unused phytec_get_opt(struct
phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_rev(struct phytec_eeprom_data *data);
u8 __maybe_unused phytec_get_som_type(struct phytec_eeprom_data *data);
+#if IS_ENABLED(CONFIG_CMD_EXTENSION)
+struct extension *phytec_add_extension(const char *name, const char *overlay,
+ const char *other);
+#endif /* IS_ENABLED(CONFIG_CMD_EXTENSION) */
+
#endif /* _PHYTEC_SOM_DETECTION_H */
--
2.25.1
[PATCH 0/5] Update PHYTEC SOM Detection
This patch series extends PHYTEC's SOM detection by minor fixes, a generic helper function and a new valid flag. Moreover, it adds a module to provide access to the SOM detection for our TI AM6 products. Daniel Schultz (3): board: phytec: common: Generic "add extension" function board: phytec: common: Fix eepom is empty check board: phytec: Add SOM detection for AM6x Yannic Moog (2): board: phytec: introduce eeprom struct member 'valid' board: phytec: check eeprom_data validity board/phytec/common/Kconfig| 18 +++ board/phytec/common/Makefile | 1 + board/phytec/common/am6_som_detection.c| 159 + board/phytec/common/am6_som_detection.h| 36 + board/phytec/common/imx8m_som_detection.c | 13 +- board/phytec/common/phytec_som_detection.c | 97 + board/phytec/common/phytec_som_detection.h | 16 ++- board/phytec/phycore_am62x/Kconfig | 4 + board/phytec/phycore_am64x/Kconfig | 4 + 9 files changed, 314 insertions(+), 34 deletions(-) create mode 100644 board/phytec/common/am6_som_detection.c create mode 100644 board/phytec/common/am6_som_detection.h -- 2.25.1
[PULL] u-boot-mips fixes for v2024.04
Hi Tom, please pull two bugfixes for MIPS, thanks. CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/19933 The following changes since commit f3c979dd0053c082d2df170446923e7ce5edbc2d: Prepare v2024.04-rc4 (2024-03-11 13:11:46 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-fixes-for-v2024.04 for you to fetch changes up to 6806a133cde6f99777925953ee046bf2f050d4ef: mips: fix change_k0_cca() (2024-03-13 21:15:40 +0100) - mips: implement __udivdi3 to fix building of SquashFS - mips: fix bug in cache init on MIPS32r2 or later Daniel Schwierzeck (1): mips: fix change_k0_cca() Linus Walleij (1): mips: implement __udivdi3 arch/mips/lib/Makefile | 2 +- arch/mips/lib/cache_init.S | 4 ++-- arch/mips/lib/udivdi3.c| 17 + 3 files changed, 20 insertions(+), 3 deletions(-) create mode 100644 arch/mips/lib/udivdi3.c
Re: [PATCH 1/2] board: phytec: am64x: Add PHYTEC phyCORE-AM64x SoM
Hey Wadim, just trying to give you feedback through the archived mail. (That's why the content is missing). The R5 config has 0x800 as value for CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR. This offset wasn't changed upstream and the TI EVM still uses 0x400. Regards, Daniel
Re: Passing boot logs to Linux?
On Thu, Dec 21, 2023 at 12:55:20AM +0100, Dragan Simic wrote: > On 2023-12-21 00:27, Csókás Bence wrote: > > Not every system has eMMC/uSD, and as you said, these arguments don't > > hold for a 4 MB SPI NAND, for example, one you might find in an OpenWrt > > router for example. Whereas RAM is quite cheap nowadays. > > I see, but I also wonder how many such OpenWrt routers are still used these > days, and, even more importantly, how many of them are regularly updated and > can be expected to actually use this new feature? Avoid flash writes is a very important matter, even on systems with 128 MiB of SPI-NAND flash which is by far the most common setup you find on off-the-shelf plastic routers and access points nowadays. Especially also as those devices often come without a local console, having U-Boot's output prepended to dmesg on boot would be a very big win. > > Please, don't get me wrong, I still support having both options available, > but I'm also wondering about the target demographic. > > > > > Plus, I don't want the console subsystem to depend on any file/disk > > > > operations/drivers. > > > > > > Well, the console would still work as usual even if logging to disk > > > would fail for any reason, which is similar to the serial console > > > still > > > working if the graphical console fails. Moreover, if the disk fails, > > > the system isn't be able to boot, so any RAM-based console logs > > > would be > > > lost in that case. All this makes the RAM-based logging no more > > > resilient to disk failures. > > > > Correction: if disk *reads* fail, as well as writes, then the system > > will not boot. However, typical failure of Flash media is that it > > becomes read-only. > > That's a good point, but having a read-only root filesystem usually also > means having a non-operational system that can only have its stored data > salvaged. Unless the system is specifically crafted to survive such > scenarios, of course. ... which holds true for any decent embedded OS, which at least allows limited remote access and some kind of recovery even in this situation. > > > > I still think that using disk-based pstore is a better option. Just > > > as > > > you don't want to wear out your flash disks with 30-40 KB of data, I > > > also don't want to waste 30-40 KB of RAM. > > > > As I said, you could just unload the log after you're done processing > > it. 40 KB RAM is less, than what `sshd` uses, for instance (860k on my > > laptop, but it can probably be less, maybe even 10x less, so 80-90k?), > > so you could, in your init, process the in-RAM log, then unload it, then > > start your other services, thereby reclaiming that RAM. > > Using pstore should have that unloading already covered, and the already > existing systemd service is there to perform the archiving to the primary > filesystem, if desired so. It would all need to be tested in detail, of > course. pstore/ramoops uses a statically assigned reserved memory region, so in the moment you want to use that feature you loose that amount of RAM (a few kB, so it doesn't really matter on modern systems). As in: there is *no* dynamic allocation. Imho using pstore/ramoops (which is a more or less Linux-specific debugging feature, meant to store one or more timestamped logs of crashes) might not be the most suitable choice. I understand the advantages of using existing infrastructure, but on the other hand we don't need most of the complexity of pstore for the task. What I'd like to see is having a couple of log lines from U-Boot prepended to Linux' dmesg buffer, and for that we anyway will have to come up with a way to hand over that buffer. Another reserved-memory region would be one way, embedding the buffer as a blob into the /chosen/ section of the device tree would be another way.
Re: Passing boot logs to Linux?
Hi Bence, On Tue, Dec 19, 2023 at 08:08:48PM +, Csókás Bence wrote: > Hi! > > Is passing the U-Boot boot log to Linux supported yet? We are working > with a third-party solution, which works, but is a bit hacky, so I was > wondering if an official solution has been merged yet. > > I saw that there was an option CONFIG_CONSOLE_RECORD that saves > everything to a membuff, but I don't know if that can be exported to > Linux yet. And if not in the tree yet, would such a patch be welcome? To me this sounds very useful and definitely something we'd like to have in OpenWrt. So I'd volunteer to review and test your patches once they are ready. What comes to mind is that CONFIG_CONSOLE_RECORD also captures ANSI sequences during menu or count-down before boot, so we'd have to either introduce a dedicated log_printf() call and use that when ever we want the output to also become part of the log buffer or we could somehow filter the recorded console, eliminating all terminal control sequences. Cheers Daniel
Re: [PATCH 00/21] Qualcomm generic board support
On Tue, Dec 05, 2023 at 10:36:28AM +, ff wrote: > > Le 5 déc. 2023 à 10:46, Sumit Garg a écrit : > > > > + U-boot custodians list > > > >> On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski > >> wrote: > >> > >> On 05/12/2023 08:13, Sumit Garg wrote: > >>>>> @DT bindings maintainers, > >>>>> > >>>>> Given the ease of maintenance of DT bindings within Linux kernel > >>>>> source tree, I don't have a specific objection there. But can we > >>>>> ease DTS testing for firmware/bootloader projects by providing a > >>>>> versioned release package for DT bindings? Or if someone else > >>>>> has a better idea here please feel free to chime in. > >>>> > >>>> This doesn't work for you?: > >>>> > >>>> https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/ > >>> > >>> Thanks, this is certainly a good step which I wasn't aware of. > >>> Further simplification can be done to decouple devicetree source > >>> files from DT bindings. > >> > >> Why? > > > > I suppose you are already aware that Linux DTS files are a subset of > > what could be supported by devicetree schemas. There can be > > firmware/bootloader specific properties (one example being [1]) > > which Linux kernel can simply ignore. Will you be willing to add all > > of those DT properties to Linux DTS files and maintain them? > > A pre-existing effort to solve the same problem as [1] is System > Device Tree, discussed in the context of Linaro supported OpenAMP > project. It is not just about cherry picking devices that have > bindings in Linux but also information about clock and power domains > or devices that are not seen by Linux. It is obvious that the > resulting bindings should be maintained upstream in the DT repo > regardless of the communities adopted solution. This seems to be artificially linking two topics: system DT and DT schema validation within u-boot. They are somewhat related but one of not a precondition of the other. > > However, DT bindings are something which should be common, the > > hardware description of a device should be universal. IMO, splitting > > DT bindings alone would ease the compliance process for u-boot > > drivers in quite similar manner to Linux drivers. > > I remember a discussion with ST on that topic related to Framebuffer. > U-Boot can need a very different representation of the same device to > use it while Linux need an in-depth description of all shaders and « > stuff » (another reason why [1] is addressing only a portion of the > problem) So even if there is a single frame buffer binding, there > should be two (at least) conformance tests. I don't follow this, for two reasons. 1. DT describes the hardware, not how it is driven. Having a relationship between u-boot and linux DTs with different representation would imply that the hardware changes between u-boot and the kernel. 2. Even if we were to accept that there must be two device tree instances (beyond transient workarounds for missing features), why would there need to be two conformance tests rather than one conformance test run on the two DTs? Daniel.
Re: [PATCH 00/21] Qualcomm generic board support
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote: > + Linux kernel DT bindings maintainers, EBBR ML > > On Thu, 30 Nov 2023 at 20:05, Tom Rini wrote: > > On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: > > > On Wed, 29 Nov 2023 at 22:06, Neil Armstrong > > > wrote: > > > > > I've been thinking about and hacking on this for the last week or so, > > > > > sorry for the delayed reply here. > > > > > > > > > > The value is in preventing any of the existing bindings from > > > > > regressing, > > > > > > That is actually best addressed in Linux by checking the DTS against > > > yaml DT bindings. We don't have that testing available in u-boot and > > > only depend on careful reviews. > > > > I would absolutely love for someone to make another attempt at updating > > our kbuild infrastucture so that we can run the validation targets. > > > > Given that EBBR requires [1] the platform (firmware/bootloader) and > not OS to supply the devicetree, it becomes evident that > firmware/bootloaders import DTS from Linux kernel (where it is > maintained). > > But currently u-boot doesn't have a proper way to validate those DTS > against DT bindings (maintained in Linux kernel). Although there are > Devicetree schema tools available here [2], there isn't a versioned > release package of DT bindings which one should use to validate DTS > files. The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory? Daniel.
[PATCH] mips: fix change_k0_cca()
The intention of change_k0_cca() is to read the C0.Config register into register $t0, update $t0 with the new cache coherency mode passed in $a0 and write back $t0 to C0.Config. With MIPS32 R2 or later instruction sets, this can be achieved with a single instruction with INS. The source and destination register of the INS instruction is passed as first parameter. In case of change_k0_cca() it is register $t0. But for writing back the updated value to C0.Config, the incorrect $a0 register is used. This is only correct in the MIPS32 R1 code path. Fix the `mtc0` instruction to write back the value of the $t0 register. Fix the MIPS32 R1 code path to also store the updated value in $t0. Reported by user ddqxy138 on Github. https://github.com/u-boot/u-boot/commit/b838586086af3278bcaead3720c7a18813cf4619 Signed-off-by: Daniel Schwierzeck --- arch/mips/lib/cache_init.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/mips/lib/cache_init.S b/arch/mips/lib/cache_init.S index 602741c65d..d64209d76a 100644 --- a/arch/mips/lib/cache_init.S +++ b/arch/mips/lib/cache_init.S @@ -431,9 +431,9 @@ LEAF(change_k0_cca) #else xor a0, a0, t0 andia0, a0, CONF_CM_CMASK - xor a0, a0, t0 + xor t0, a0, t0 #endif - mtc0a0, CP0_CONFIG + mtc0t0, CP0_CONFIG jr.hb ra END(change_k0_cca) -- 2.41.0
[PATCH] mips: implement __udivdi3
From: Linus Walleij
Squashfs wasn't compiling because the lldiv() directives
turn into __udivdi3 and we are using private libgcc.
After this squashfs compiles for MIPS.
Signed-off-by: Linus Walleij
Signed-off-by: Daniel Schwierzeck
---
Linus, this is the updated and optimized version of your initial patch.
Sorry for the long delay ;)
arch/mips/lib/Makefile | 2 +-
arch/mips/lib/udivdi3.c | 17 +
2 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/lib/udivdi3.c
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9ee1fcb5c7..1621cc9a1f 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -14,4 +14,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_CMD_GO) += boot.o
obj-$(CONFIG_SPL_BUILD) += spl.o
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o udivdi3.o
diff --git a/arch/mips/lib/udivdi3.c b/arch/mips/lib/udivdi3.c
new file mode 100644
index 00..4d780117cf
--- /dev/null
+++ b/arch/mips/lib/udivdi3.c
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#include "libgcc.h"
+
+#if BITS_PER_LONG == 32
+
+#include
+
+long long __udivdi3(long long u, word_type b)
+{
+ long long ret = u;
+
+ __div64_32(, b);
+ return ret;
+}
+
+#endif /* BITS_PER_LONG == 32 */
--
2.41.0
Re: [PATCH] bmips: Add Inteno XG6846 board
On 9/20/23 09:42, Linus Walleij wrote: This adds support for the Inteno XG6846 board based on the Broadcom MIPS 6328 SoC. The default boot will read a uImage from flash and boot it. Cc: Daniel Schwierzeck Signed-off-by: Linus Walleij --- arch/mips/dts/Makefile | 1 + arch/mips/dts/inteno,xg6846.dts | 57 ++ arch/mips/mach-bmips/Kconfig| 12 + board/inteno/xg6846/Kconfig | 12 + board/inteno/xg6846/MAINTAINERS | 6 +++ board/inteno/xg6846/Makefile| 3 ++ board/inteno/xg6846/xg6846.c| 6 +++ configs/inteno_xg6846_ram_defconfig | 74 + include/configs/inteno_xg6846.h | 8 9 files changed, 179 insertions(+) create mode 100644 arch/mips/dts/inteno,xg6846.dts create mode 100644 board/inteno/xg6846/Kconfig create mode 100644 board/inteno/xg6846/MAINTAINERS create mode 100644 board/inteno/xg6846/Makefile create mode 100644 board/inteno/xg6846/xg6846.c create mode 100644 configs/inteno_xg6846_ram_defconfig create mode 100644 include/configs/inteno_xg6846.h if you remove board/inteno/xg6846/Makefile and board/inteno/xg6846/xg6846.c: Reviewed-by: Daniel Schwierzeck -- - Daniel
Re: [PATCH] bmips: Add Inteno XG6846 board
On 9/20/23 20:55, Tom Rini wrote: On Wed, Sep 20, 2023 at 08:51:07PM +0200, Linus Walleij wrote: On Wed, Sep 20, 2023 at 4:22 PM Tom Rini wrote: + * This is a diet version of the device tree from Linux, + * suitable for U-Boot. + */ We shouldn't need a diet version of the tree. If it's reasonably done and stable in the kernel, we can even move towards just passing the U-Boot tree along to Linux. The device tree is not stable in the kernel. It exists in OpenWrt and the creators of the bmips target are kind of absent for the moment. The reason it is not in Linux is that the "switch ethernet" driver and bindings need to be upstreamed before the device trees can be upstreamed. But I can try to bring in more of it for sure :) Just like ARM the goal is just to drop in the kernel dts here. I guess this approach works well for ARM but not for MIPS. Most MIPS consumer boards are just maintained in OpenWRT but not in mainline Linux. And there are a few boards which have been just mainlined in U-Boot but not Linux so them also don't have a stable Linux DT. As MIPS is a dead architecture I suggest to just go with the minimal DT suited for U-Boot ;) +++ b/board/inteno/xg6846/xg6846.c @@ -0,0 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2023 Linus Walleij + */ + +#include So basically just an empty object file. Can we just _not_ have something here, if we perhaps don't set SYS_BOARD? I assume if there's just nothing here the link rules fail. Admittedly my knowledge of U-Boot internals are not the best and this is a bit of a copy and paste job from board/comtrend/ar5387un/ar-5387un.c which looks like this and sets a bad example I suppose. Yeah, I didn't know we had someone doing that already here, whoops. I guess you are asking me to modify U-Boots build system to make the whole .c and Makefile inside a board subdir optional so we can delete all such empty boardfiles? Well, it'd sure be nice if we could avoid having a dummy C file. If it looks like a nightmare once you take a peek, we can just live with it. I just tested it, you can simply add an empty board/inteno/xg6846/Makefile and remove board/inteno/xg6846/xg6846.c. But you can also remove the Makefile. Just the Kconfig and MAINTAINERS file are needed. -- - Daniel
Re: [PATCH] RFT: mips: implement __udivdi3
Hi Linus,
On 9/18/23 08:11, Linus Walleij wrote:
Squashfs wasn't compiling because the lldiv() directives
turn into __udivdi3 and we are using private libgcc.
This is just copied from the Linux kernel v6.6-rc1
arch/mips/include/asm/div64.h and then adjusted for
U-Boot.
After this squashfs compiles for MIPS.
Cc: Daniel Schwierzeck
Cc: Mauro Condarelli
Cc: Ralf Baechle
Signed-off-by: Linus Walleij
---
I can't test this because it didn't work for MTD devices
as I had expected, but I saw Mauro had this problem
before so I think I might have fixed it. I better put
the patch out there rather than let it sit on my drive.
thanks for the patch. IIRC the problem was due to the usage of a/b vs.
do_div(a,b). We already thought about two options: fix the SquashFS code
or add __udivdi3(). Because no upstream MIPS board enabled SquashFS,
this issue remained unresolved.
---
arch/mips/lib/Makefile | 2 +-
arch/mips/lib/udivdi3.c | 86 +
2 files changed, 87 insertions(+), 1 deletion(-)
create mode 100644 arch/mips/lib/udivdi3.c
diff --git a/arch/mips/lib/Makefile b/arch/mips/lib/Makefile
index 9ee1fcb5c702..1621cc9a1ff9 100644
--- a/arch/mips/lib/Makefile
+++ b/arch/mips/lib/Makefile
@@ -14,4 +14,4 @@ obj-$(CONFIG_CMD_BOOTM) += bootm.o
obj-$(CONFIG_CMD_GO) += boot.o
obj-$(CONFIG_SPL_BUILD) += spl.o
-lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o
+lib-$(CONFIG_USE_PRIVATE_LIBGCC) += ashldi3.o ashrdi3.o lshrdi3.o udivdi3.o
diff --git a/arch/mips/lib/udivdi3.c b/arch/mips/lib/udivdi3.c
new file mode 100644
index ..6a4ee5fa46ab
--- /dev/null
+++ b/arch/mips/lib/udivdi3.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2000, 2004, 2021 Maciej W. Rozycki
+ * Copyright (C) 2003, 07 Ralf Baechle (r...@linux-mips.org)
+ */
+
+#include "libgcc.h"
+
+/*
+ * No traps on overflows for any of these...
+ */
+
+#define do_div64_32(res, high, low, base) ({ \
+ unsigned long __cf, __tmp, __tmp2, __i; \
+ unsigned long __quot32, __mod32;\
+ \
+ __asm__(\
+ " .setpush\n"\
+ " .setnoat\n"\
+ " .setnoreorder \n"\
+ " move%2, $0 \n"\
+ " move%3, $0 \n"\
+ " b 1f \n"\
+ " li %4, 0x21\n"\
+ "0:\n"\
+ " sll $1, %0, 0x1 \n"\
+ " srl %3, %0, 0x1f\n"\
+ " or %0, $1, %5 \n"\
+ " sll %1, %1, 0x1 \n"\
+ " sll %2, %2, 0x1 \n"\
+ "1:\n"\
+ " bnez%3, 2f \n"\
+ " sltu %5, %0, %z6 \n"\
+ " bnez%5, 3f \n"\
+ "2:\n"\
+ " addiu %4, %4, -1 \n"\
+ " subu%0, %0, %z6 \n"\
+ " addiu %2, %2, 1 \n"\
+ "3:\n"\
+ " bnez%4, 0b \n"\
+ " srl%5, %1, 0x1f\n"\
+ " .setpop" \
+ : "=" (__mod32), "=" (__tmp), \
+ "=" (__quot32), "=" (__cf), \
+ "=" (__i), "=" (__tmp2) \
+ : "Jr" (base), "0" (high), "1" (low));\
+ \
+ (res) = __quot32; \
+ __mod32;
[PATCH] configs: set CONFIG_LMB_MAX_REGIONS=64 for MT7988 boards
Similar to MT7981 and MT7986 also MT7988 can have a high number of
reserved-memory regions used by the various hardware offloading
subsystems.
Raise CONFIG_LMB_MAX_REGIONS to 64 to avoid errors when trying to boot
Linux with more then 6 reserved regions:
ERROR: reserving fdt memory region failed (addr=4f70 size=24 flags=4)
ERROR: reserving fdt memory region failed (addr=15194000 size=1000 flags=4)
ERROR: reserving fdt memory region failed (addr=15294000 size=1000 flags=4)
ERROR: reserving fdt memory region failed (addr=15394000 size=1000 flags=4)
ERROR: Failed to allocate 0xb161 bytes below 0x8000.
device tree - allocation error
Fixes: bc4adc97cfb ("board: mediatek: add MT7988 reference boards")
Reported-by: Lorenzo Bianconi
Signed-off-by: Daniel Golle
---
configs/mt7988_rfb_defconfig| 1 +
configs/mt7988_sd_rfb_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/configs/mt7988_rfb_defconfig b/configs/mt7988_rfb_defconfig
index dc97bb36ea..ced52edecf 100644
--- a/configs/mt7988_rfb_defconfig
+++ b/configs/mt7988_rfb_defconfig
@@ -81,3 +81,4 @@ CONFIG_MTK_SPIM=y
CONFIG_LZO=y
CONFIG_HEXDUMP=y
# CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
diff --git a/configs/mt7988_sd_rfb_defconfig b/configs/mt7988_sd_rfb_defconfig
index 421999da86..670f5eae18 100644
--- a/configs/mt7988_sd_rfb_defconfig
+++ b/configs/mt7988_sd_rfb_defconfig
@@ -69,3 +69,4 @@ CONFIG_MTK_SPIM=y
CONFIG_LZO=y
CONFIG_HEXDUMP=y
# CONFIG_EFI_LOADER is not set
+CONFIG_LMB_MAX_REGIONS=64
--
2.41.0
Re: [PATCH] arm: dts: medaitek: convert gmac link mode to 2500base-x for mt7986a-bpi-r3-sd
On Fri, Aug 04, 2023 at 09:01:55AM +0800, Weijie Gao wrote:
> The mt7531 of bpi-r3 is connected to mt7986 with 2.5Gbps HSGMII, not the
> regular 1Gbps SGMII.
>
> Signed-off-by: Weijie Gao
Reviewed-by: Daniel Golle
> ---
> This is a supplement to commit:
> aef54ea1 (arm: dts: medaitek: convert gmac link mode to 2500base-x)
> ---
> arch/arm/dts/mt7986a-bpi-r3-sd.dts | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> index 15256302b8..c156a81363 100644
> --- a/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> +++ b/arch/arm/dts/mt7986a-bpi-r3-sd.dts
> @@ -76,12 +76,12 @@
> {
> status = "okay";
> mediatek,gmac-id = <0>;
> - phy-mode = "sgmii";
> + phy-mode = "2500base-x";
> mediatek,switch = "mt7531";
> reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
>
> fixed-link {
> - speed = <1000>;
> + speed = <2500>;
> full-duplex;
> };
> };
> --
> 2.17.1
>
[PATCH] ram: mediatek: mt7629: include
Something between U-Boot 2023.04 and 2023.07.02 resulted in no longer implicitely including in the DDR3 RAM driver for the MT7929 SoC. The result is a build failure: drivers/ram/mediatek/ddr3-mt7629.c: In function 'mtk_ddr3_get_info': drivers/ram/mediatek/ddr3-mt7629.c:734:30: error: 'SZ_128M' undeclared (first use in this function) 734 | info->size = SZ_128M; | ^~~ drivers/ram/mediatek/ddr3-mt7629.c:734:30: note: each undeclared identifier is reported only once for each function it appears in drivers/ram/mediatek/ddr3-mt7629.c:737:30: error: 'SZ_256M' undeclared (first use in this function) 737 | info->size = SZ_256M; | ^~~ drivers/ram/mediatek/ddr3-mt7629.c:740:30: error: 'SZ_512M' undeclared (first use in this function) 740 | info->size = SZ_512M; | ^~~ drivers/ram/mediatek/ddr3-mt7629.c:743:30: error: 'SZ_1G' undeclared (first use in this function) 743 | info->size = SZ_1G; | ^ Include so SZ_* is defined. Reported-by: Tianling Shen Signed-off-by: Daniel Golle --- drivers/ram/mediatek/ddr3-mt7629.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/ram/mediatek/ddr3-mt7629.c b/drivers/ram/mediatek/ddr3-mt7629.c index 1737fdac970..f65fcf179cf 100644 --- a/drivers/ram/mediatek/ddr3-mt7629.c +++ b/drivers/ram/mediatek/ddr3-mt7629.c @@ -14,6 +14,7 @@ #include #include #include +#include /* EMI */ #define EMI_CONA 0x000 -- 2.41.0
[PATCH] pinctrl: mediatek: set R1/R0 in case pullen/pullsel succeeded
Commit dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and
related functions") changed the logic deciding to set R0 and R1
registers for V1 devices.
Before:
/* Also set PUPD/R0/R1 if the pin has them */
err = mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_PUPD, !pullup);
if (err != -EINVAL) {
mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R0, r0);
mtk_hw_set_value(dev, pin, PINCTRL_PIN_REG_R1, r1);
}
After:
/* try pupd_r1_r0 if pullen_pullsel return error */
err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
val);
if (err)
return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
pullup, val);
Tracing mtk_pinconf_bias_set_pullen_pullsel shows that the function
always either returns 0 in case of success or -EINVAL in case any error
has occurred. Hence the logic responsible of the decision to program R0
and R1 has been inverted.
This leads to problems on BananaPi R2 (MT7623N) when booting from
SDMMC, it turns out accessing eMMC no longer works since
U-Boot 2022.07:
MT7623> mmc dev 0
Card did not respond to voltage select! : -110
The problem wasn't detected for a long time as both eMMC and SDMMC work
fine if they are used to boot from, and hence R0 and R1 were already
setup by the bootrom and/or preloader.
Fix the logic to restore the originally intended and correct behavior
and also change the descriptive comment accordingly.
Fixes: dafe0fbfb0f3 ("pinctrl: mediatek: rewrite mtk_pinconf_set and related
functions")
Signed-off-by: Daniel Golle
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 4ae328699e2..23d759aa2d8 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -319,10 +319,10 @@ int mtk_pinconf_bias_set_v1(struct udevice *dev, u32 pin,
bool disable,
{
int err;
- /* try pupd_r1_r0 if pullen_pullsel return error */
+ /* set pupd_r1_r0 if pullen_pullsel succeeded */
err = mtk_pinconf_bias_set_pullen_pullsel(dev, pin, disable, pullup,
val);
- if (err)
+ if (!err)
return mtk_pinconf_bias_set_pupd_r1_r0(dev, pin, disable,
pullup, val);
--
2.40.0
Re: [PATCH v3 08/25] menu: Make use of CLI character processing
On Fri, Jan 06, 2023 at 08:52:26AM -0600, Simon Glass wrote: > Avoid duplicating some of the escape-sequence processing here and use the > CLI function instead. > > Signed-off-by: Simon Glass > --- > > [...] > diff --git a/common/menu.c b/common/menu.c > index 7db98942a61..45f36ae3ede 100644 > --- a/common/menu.c > +++ b/common/menu.c > @@ -15,6 +15,8 @@ > > #include "menu.h" > > +#define ansi 0 Now that I'm using U-Boot 2023.04 I noticed that this introduces a (cosmetic) regression: The autoboot countdown in bootmenu is now longer re-written, but instead the last menu item line is continously appended like: U-Boot consoleHit any key to stop autoboot: 3 Hit any key to stop autoboot: 2 To regain the previous behavior one should change the line to #define ansi 1 To me this looks a bit unfinished, as if there was some sort of probing of the terminal capabilities supposed to happen but then this has never been implemeneted...
Re: [PATCH 02/88] treewide: Correct invalid Kconfig syntax and warnings
On 1/27/23 14:45, Tom Rini wrote: On Mon, Jan 23, 2023 at 02:59:05PM -0700, Simon Glass wrote: In several places a 'select' is used to select a choice, which is not supported by Kconfig. In other places, the filename for the 'source' command is not in quites. Fix these two problems throughout the tree, so that kconfiglib does not show any more warnings. Signed-off-by: Simon Glass OK, to summarize what I just said in another email and clarify future work. Please first split this patch in to its own series that corrects each type of problem, per commit. The missing quotes for example, and then the extra whitespace ones. Next, commenting out a select is wrong, and each case needs to be better understood / fixed. I'm honestly not sure if asking endianness for MIPS is right and if we should select that from boards too, like ARC, but probably. The ARC_MMU one also should just not be asked, I suspect, but as a separate patch where you cc Alexey, we'll find out :) And so on, for each. Thanks. For MIPS the endianess (and also architecture/ISA level) needs to be able to be set by the user via menuconfig as most MIPS cores or SoCs can support multiple variants. The idea is that the specific SoC or machine just sets the supported options to restrict the options the user can choose. The board's defconfig should set the required default value for each option but must not *select* it. See the Boston board for example: config TARGET_BOSTON bool "Support Boston" ... select SUPPORTS_BIG_ENDIAN select SUPPORTS_CPU_MIPS32_R1 select SUPPORTS_CPU_MIPS32_R2 select SUPPORTS_CPU_MIPS32_R6 select SUPPORTS_CPU_MIPS64_R1 select SUPPORTS_CPU_MIPS64_R2 select SUPPORTS_CPU_MIPS64_R6 select SUPPORTS_LITTLE_ENDIAN A possible fix for ARC could be: --- a/arch/Kconfig +++ b/arch/Kconfig @@ -53,8 +53,6 @@ config ARC select SUPPORT_OF_CONTROL select SYS_CACHE_SHIFT_7 select TIMER - select SYS_BIG_ENDIAN if CPU_BIG_ENDIAN - select SYS_LITTLE_ENDIAN if !CPU_BIG_ENDIAN config ARM bool "ARM architecture" @@ -490,7 +488,7 @@ endif source "board/keymile/Kconfig" -if MIPS || MICROBLAZE +if MIPS || MICROBLAZE || ARC choice prompt "Endianness selection" @@ -502,11 +500,11 @@ choice config SYS_BIG_ENDIAN bool "Big endian" - depends on (SUPPORTS_BIG_ENDIAN && MIPS) || MICROBLAZE + depends on (SUPPORTS_BIG_ENDIAN && MIPS) || MICROBLAZE || (CPU_BIG_ENDIAN && ARC) config SYS_LITTLE_ENDIAN bool "Little endian" - depends on (SUPPORTS_LITTLE_ENDIAN && MIPS) || MICROBLAZE + depends on (SUPPORTS_LITTLE_ENDIAN && MIPS) || MICROBLAZE || (CPU_LITTLE_ENDIAN && ARC) endchoice A *make savedefconfig* should than automatically add *CONFIG_SYS_LITTLE_ENDIAN=y* or *CONFIG_SYS_BIG_ENDIAN=y* to the ARC board defconfig's. -- - Daniel
Re: DDR timing for vendor board
Hi Rob, On 12/9/22 12:10, Rob Kramer wrote: Hi Jack, Thanks for your suggestion, I hadn't thought of using just the rkbin ddr file together with u-boot SPL. My biggest objection was the rkbin miniloader that makes assumptions on partition layout. It seems to work, but now I'm in for some DT pain :) I don't know anything about Rockchip but from experience with other SoC's and DDR2/3 controllers I would say that the reason for this closed-source loader is likely some proprietary dynamic tuning algorithm for some memory controller parameters (e.g. DQS) to adapt to manufacturing tolerances of the board. If that's the case, the static setting of memory size and timings via DT won't be enough to run the board stable and Jack's approach would be more reliable. Cheers, Rob 9 Dec 2022 00:49:30 Jack Mitchell : On 08/12/2022 04:01, Rob Kramer wrote: Hi all, I have a RK3288 board from a Chinese display vendor that came with the usual giant Rockchip tarball that they patched here and there to make the board work. It seems to be based on a rk3288-evb, since that is what they patched in the kernel. The kernel is a 4.4 kernel with Android stuff in it (i.e. fiq-debugger) and a large amount of Rockchip patches, u-boot is 2017.09, with rk patches. It turns out that u-boot TPL/SPL won't boot because the DDR timings are incorrect, and the Chinese vendor uses the Rockchip rk3288_ddr_400MHz_v1.09.bin loader. I'm using u-boot 2022.01 for now, and I've tried to naively modify the timing in arch/arm/dts/rk3288-evb.dts, but it doesn't work at all, with varying errors on boot. The Rockchip loader provides the following info when booting: In Channel a: DDR3 400MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB Memory OK OUT Boot1 Release Time: Apr 11 2018 10:32:58, version: 2.36 ChipType = 0x8, 232 I've tried various DDR3 (not LPDDR3) settings from other boards, for example for a Firefly (666 MHz DDR3): U-Boot TPL 2022.01 (Jan 10 2022 - 18:46:34) Col detect error DRAM init failed! ### ERROR ### Please RESET the board ### It was expected that 666MHz doesn't work, but if I just change the frequency in the dts, that also fails (error -22). How can I support the DDR for this board? I can't even see what the ID on the chips is, because the heatsink is blocking sight and seems to be attached with some sort of thermal glue. Is there a way to read back the DDR timings (phy-timing, sdram-params) from the kernel/SoC on a board that is booted using the proprietary loader? Cheers! Rob Hi Rob, You could be in for a world of hurt here as Rockchip are very poor at supporting different DDR init configurations in u-boot. In the past with awkward boards I've used the Rockchip DDR init blob as the TPL binary for u-boot then skip the DRAM init in the u-boot SPL. From my travels in this area I've found that single channel RAM boards are particularly difficult to get working as the majority if not all mainlined board use dual channel RAM. Sorry I can't be more help, but trying to use the DDR blob is a good starting point to get you going on mainline. Good Luck! -- Jack Mitchell, Consultant https://www.tuxable.co.uk -- - Daniel
Re: [PATCH] net: ipv6: Fix link-partner MAC address assignment
On 12/7/22 12:25, Vyacheslav Mitrofanov V wrote: On Tue, 2022-12-06 at 13:22 +0100, Daniel Schwierzeck wrote: «Внимание! Данное письмо от внешнего адресата!» On 12/6/22 08:08, Viacheslav Mitrofanov wrote: MAC address of a link-partner is not saved for future use because of bad condition of if statement. Moreover it can potentially cause to NULL-pointer dereference. Signed-off-by: Viacheslav Mitrofanov --- net/ndisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Daniel Schwierzeck diff --git a/net/ndisc.c b/net/ndisc.c index 3c0eeeaea3..56fc6390bc 100644 --- a/net/ndisc.c +++ b/net/ndisc.c @@ -264,7 +264,7 @@ int ndisc_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6, int len) ndisc_extract_enetaddr(ndisc, neigh_eth_addr); /* save address for later use */ - if (!net_nd_packet_mac) + if (net_nd_packet_mac) memcpy(net_nd_packet_mac, neigh_eth_addr, 7); /* modify header, and transmit it */ -- - Daniel This patch is not appropriate!net_nd_packet_mac is just a pointer, moreover there is no memory allocation. It has just keep a pointer to neigh_eth_addr. So the solution must be sth. like net_nd_packet_mac = neigh_eth_addr; that wouldn't make much sense. You would assign a global pointer to an array defined in local function scope. After ndisc_receive() has finished, the pointer will have an invalid address. The same problem exists in ping6_send(). Also the pointer is assigned in net_send_udp_packet6() to an array so the memcpy in ndisc_receive() would work. BTW: the same approach is used with IPv4 and the arp_wait_packet_ethaddr pointer. The pointer is assigned in net_send_ip_packet() to an array and arp_receive() does a memcpy to that pointer if it is not NULL. I think this patch is correct but you should revisit the assignment of net_nd_packet_mac in ping6_send(). You copy net_null_ethaddr to the local mac array and assign net_nd_packet_mac to the mac array. Either the assignment is useless or it should be a memcpy too. -- - Daniel
Re: [PATCH] net: ipv6: Fix link-partner MAC address assignment
On 12/6/22 08:08, Viacheslav Mitrofanov wrote: MAC address of a link-partner is not saved for future use because of bad condition of if statement. Moreover it can potentially cause to NULL-pointer dereference. Signed-off-by: Viacheslav Mitrofanov --- net/ndisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Daniel Schwierzeck diff --git a/net/ndisc.c b/net/ndisc.c index 3c0eeeaea3..56fc6390bc 100644 --- a/net/ndisc.c +++ b/net/ndisc.c @@ -264,7 +264,7 @@ int ndisc_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6, int len) ndisc_extract_enetaddr(ndisc, neigh_eth_addr); /* save address for later use */ - if (!net_nd_packet_mac) + if (net_nd_packet_mac) memcpy(net_nd_packet_mac, neigh_eth_addr, 7); /* modify header, and transmit it */ -- - Daniel
Re: [PATCH] net: ipv6: Add missing break into IPv6 protocol handler
On 12/6/22 08:08, Viacheslav Mitrofanov wrote: IPv6 protocol handler is not terminated with a break statment. It can lead to running unexpected code. Signed-off-by: Viacheslav Mitrofanov --- net/net.c | 1 + 1 file changed, 1 insertion(+) thanks for the quick fix Reviewed-by: Daniel Schwierzeck diff --git a/net/net.c b/net/net.c index 1c39acc493..57da9bda85 100644 --- a/net/net.c +++ b/net/net.c @@ -1269,6 +1269,7 @@ void net_process_received_packet(uchar *in_packet, int len) #if IS_ENABLED(CONFIG_IPV6) case PROT_IP6: net_ip6_handler(et, (struct ip6_hdr *)ip, len); + break; #endif case PROT_IP: debug_cond(DEBUG_NET_PKT, "Got IP\n"); -- - Daniel
Re: [PATCH v5 04/19] net: ipv6: Add Neighbor Discovery Protocol (NDP)
On 12/2/22 10:18, Viacheslav Mitrofanov wrote:
Implement basic of NDP. It doesn't include such things as Router
Solicitation, Router Advertisement and Redirect. It just has Neighbor
Solicitation and Neighbor Advertisement. Only these two features are used
in u-boot IPv6. Implementation of some NDP functions uses API that was
exposed in "net: ipv6: Add IPv6 basic primitives".
Also this patch inlcudes update in Makefile to build NDP.
Series-changes: 3
- Added structures and functions descriptions
- Fixed style problems
Series-changes: 4
- Fixed structures and functions description style
Signed-off-by: Viacheslav Mitrofanov
Reviewed-by: Ramon Fried
Reviewed-by: Simon Glass
---
include/ndisc.h | 102 +
net/Makefile| 1 +
net/ndisc.c | 289
3 files changed, 392 insertions(+)
create mode 100644 include/ndisc.h
create mode 100644 net/ndisc.c
...
+
+int ndisc_receive(struct ethernet_hdr *et, struct ip6_hdr *ip6, int len)
+{
+ struct icmp6hdr *icmp =
+ (struct icmp6hdr *)(((uchar *)ip6) + IP6_HDR_SIZE);
+ struct nd_msg *ndisc = (struct nd_msg *)icmp;
+ uchar neigh_eth_addr[6];
+
+ switch (icmp->icmp6_type) {
+ case IPV6_NDISC_NEIGHBOUR_SOLICITATION:
+ debug("received neighbor solicitation for %pI6c from %pI6c\n",
+ >target, >saddr);
+ if (ip6_is_our_addr(>target) &&
+ ndisc_has_option(ip6, ND_OPT_SOURCE_LL_ADDR)) {
+ ndisc_extract_enetaddr(ndisc, neigh_eth_addr);
+ ip6_send_na(neigh_eth_addr, >saddr,
+ >target);
+ }
+ break;
+
+ case IPV6_NDISC_NEIGHBOUR_ADVERTISEMENT:
+ /* are we waiting for a reply ? */
+ if (ip6_is_unspecified_addr(_nd_sol_packet_ip6))
+ break;
+
+ if ((memcmp(>target, _nd_rep_packet_ip6,
+ sizeof(struct in6_addr)) == 0) &&
+ ndisc_has_option(ip6, ND_OPT_TARGET_LL_ADDR)) {
+ ndisc_extract_enetaddr(ndisc, neigh_eth_addr);
+
+ /* save address for later use */
+ if (!net_nd_packet_mac)
+ memcpy(net_nd_packet_mac, neigh_eth_addr, 7);
Coverity reports the following:
CID 430977: Null pointer dereferences (FORWARD_NULL)
Passing null pointer "net_nd_packet_mac" to "memcpy", which dereferences
it. [Note: The source code implementation of the function has been
overridden by a builtin model.]
CID 430974: Memory - corruptions (OVERRUN)
Overrunning array "neigh_eth_addr" of 6 bytes by passing it to a
function which accesses it at byte offset 6 using argument "7UL". [Note:
The source code implementation of the function has been overridden by a
builtin model.]
Did you mean to write the following which would make more sense?
if (net_nd_packet_mac)
memcpy(net_nd_packet_mac, neigh_eth_addr, 7);
+
+ /* modify header, and transmit it */
+ memcpy(((struct ethernet_hdr
*)net_nd_tx_packet)->et_dest,
+ neigh_eth_addr, 6);
+
+ net_send_packet(net_nd_tx_packet,
+ net_nd_tx_packet_size);
+
+ /* no ND request pending now */
+ net_nd_sol_packet_ip6 = net_null_addr_ip6;
+ net_nd_tx_packet_size = 0;
+ net_nd_packet_mac = NULL;
+ }
+ break;
+ default:
+ debug("Unexpected ICMPv6 type 0x%x\n", icmp->icmp6_type);
+ return -1;
+ }
+
+ return 0;
+}
--
- Daniel
Re: [PATCH v5 09/19] net: ipv6: Incorporate IPv6 support into u-boot net subsystem
On 12/2/22 10:18, Viacheslav Mitrofanov wrote:
Add net_ip6_handler (an IPv6 packet handler) into net_loop. Add
neighbor discovery mechanism into network init process. That is the
main step to run IPv6 in u-boot. Now u-boot is capable to use NDP and
handle IPv6 packets.
Signed-off-by: Viacheslav Mitrofanov
Reviewed-by: Ramon Fried
Reviewed-by: Simon Glass
---
net/net.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/net/net.c b/net/net.c
index aca20e43b0..63bf962b53 100644
--- a/net/net.c
+++ b/net/net.c
@@ -91,6 +91,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -343,8 +345,17 @@ void net_auto_load(void)
static int net_init_loop(void)
{
- if (eth_get_dev())
+ if (eth_get_dev()) {
memcpy(net_ethaddr, eth_get_ethaddr(), 6);
+
+ if (IS_ENABLED(CONFIG_IPV6)) {
+ ip6_make_lladdr(_link_local_ip6, net_ethaddr);
+ if (!memcmp(_ip6, _null_addr_ip6,
+ sizeof(struct in6_addr)))
+ memcpy(_ip6, _link_local_ip6,
+ sizeof(struct in6_addr));
+ }
+ }
else
/*
* Not ideal, but there's no way to get the actual error, and I
@@ -385,6 +396,7 @@ int net_init(void)
(i + 1) * PKTSIZE_ALIGN;
}
arp_init();
+ ndisc_init();
net_clear_handlers();
/* Only need to setup buffer pointers once. */
@@ -589,6 +601,11 @@ restart:
if (arp_timeout_check() > 0)
time_start = get_timer(0);
+ if (IS_ENABLED(CONFIG_IPV6)) {
+ if (use_ip6 && (ndisc_timeout_check() > 0))
+ time_start = get_timer(0);
+ }
+
/*
* Check the ethernet for a new packet. The ethernet
* receive routine will process it.
@@ -1243,6 +1260,10 @@ void net_process_received_packet(uchar *in_packet, int
len)
case PROT_RARP:
rarp_receive(ip, len);
break;
+#endif
+#if IS_ENABLED(CONFIG_IPV6)
+ case PROT_IP6:
+ net_ip6_handler(et, (struct ip6_hdr *)ip, len);
#endif
Coverity reports the following:
CID 430975: Control flow issues (MISSING_BREAK)
The case for value "34525" is not terminated by a "break" statement.
Either a 'break;' or a 'fallthrough;' is missing. It looks like
net_ip6_handler() already handles ICMP and UDP so probably the PROT_IP
case shouldn't be executed at all. Therefore you should add a 'break;'.
case PROT_IP:
debug_cond(DEBUG_NET_PKT, "Got IP\n");
--
- Daniel
[PATCH] configs: set CONFIG_LMB_MAX_REGIONS=64 for all mt798[16] boards
With recently added wireless offloading features in Linux [1] the number of reserved memory regions with MediaTek SoCs supporting offloading wireless-to-Ethernet traffic grew beyond the default (8) which breaks booting Linux: ERROR: Failed to allocate 0xa6ac bytes below 0xc000. device tree - allocation error FDT creation failed! resetting ... Raise CONFIG_LMB_MAX_REGIONS to 64 like it is already done for other SoCs which require a larger number of reserved memory regions, eg. exynos78x0 based a3y17lte, a5y17lte and a7y17lte or dragonboard845c. [1]: https://lore.kernel.org/netdev/e3489a697b404bd47447190cd2e5adf090ae61c2.1667687249.git.lore...@kernel.org/ https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=eed4f1ddad8c5ad7596b229caec8bd7b477b81ee Signed-off-by: Daniel Golle --- configs/mt7981_emmc_rfb_defconfig| 1 + configs/mt7981_rfb_defconfig | 1 + configs/mt7981_sd_rfb_defconfig | 1 + configs/mt7986_rfb_defconfig | 1 + configs/mt7986a_bpir3_emmc_defconfig | 1 + configs/mt7986a_bpir3_sd_defconfig | 1 + 6 files changed, 6 insertions(+) diff --git a/configs/mt7981_emmc_rfb_defconfig b/configs/mt7981_emmc_rfb_defconfig index 4832a22643..b3b37b6e5e 100644 --- a/configs/mt7981_emmc_rfb_defconfig +++ b/configs/mt7981_emmc_rfb_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_rfb_defconfig b/configs/mt7981_rfb_defconfig index c397527887..b7ffb4dfa7 100644 --- a/configs/mt7981_rfb_defconfig +++ b/configs/mt7981_rfb_defconfig @@ -64,3 +64,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7981_sd_rfb_defconfig b/configs/mt7981_sd_rfb_defconfig index 17592dc22b..85be9bbc50 100644 --- a/configs/mt7981_sd_rfb_defconfig +++ b/configs/mt7981_sd_rfb_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986_rfb_defconfig b/configs/mt7986_rfb_defconfig index 1363f9dc6d..ac91c93efb 100644 --- a/configs/mt7986_rfb_defconfig +++ b/configs/mt7986_rfb_defconfig @@ -64,3 +64,4 @@ CONFIG_SPI=y CONFIG_DM_SPI=y CONFIG_MTK_SPIM=y CONFIG_HEXDUMP=y +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_emmc_defconfig b/configs/mt7986a_bpir3_emmc_defconfig index 354159df9b..2d4876f299 100644 --- a/configs/mt7986a_bpir3_emmc_defconfig +++ b/configs/mt7986a_bpir3_emmc_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 diff --git a/configs/mt7986a_bpir3_sd_defconfig b/configs/mt7986a_bpir3_sd_defconfig index db7ef98d80..08edfe7ac4 100644 --- a/configs/mt7986a_bpir3_sd_defconfig +++ b/configs/mt7986a_bpir3_sd_defconfig @@ -62,3 +62,4 @@ CONFIG_MTK_SERIAL=y CONFIG_FAT_WRITE=y CONFIG_HEXDUMP=y # CONFIG_EFI_LOADER is not set +CONFIG_LMB_MAX_REGIONS=64 -- 2.38.1
[PULL] u-boot-mips
Hi Tom, please pull the Kconfig migration for CONFIG_SYS_MIPS_TIMER_FREQ as well as the mtmips bugfix for the incorrectly converted default value for CONFIG_SPL_PAD_TO. Gitlab: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/14002 The following changes since commit cca41ed3d63f462ca044e0d2d30a34d4917fc6c5: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-watchdog (2022-11-02 09:10:30 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-pull-2022-11-03 for you to fetch changes up to 8450b97bf4464ab8b9c1b33b5a9150ae80c6136e: mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS (2022-11-02 21:54:26 +0100) - MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig - MIPS: mtmips: fix incorrectly converted default value for CONFIG_SPL_PAD_TO Daniel Schwierzeck (4): MIPS: remove deprecated TARGET_VCT option MIPS: remove CONFIG_SYS_MHZ MIPS: mscc: remove unused CPU_CLOCK_RATE MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig Stefan Roese (1): mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS arch/mips/Kconfig | 26 ++ arch/mips/mach-jz47xx/include/mach/jz4780.h| 2 +- arch/mips/mach-jz47xx/jz4780/pll.c | 6 +- board/imgtec/ci20/ci20.c | 4 common/spl/Kconfig | 1 + configs/ap121_defconfig| 1 + configs/ap143_defconfig| 1 + configs/ap152_defconfig| 1 + configs/bcm968380gerg_ram_defconfig| 1 + configs/boston32r2_defconfig | 1 + configs/boston32r2el_defconfig | 1 + configs/boston32r6_defconfig | 1 + configs/boston32r6el_defconfig | 1 + configs/boston64r2_defconfig | 1 + configs/boston64r2el_defconfig | 1 + configs/boston64r6_defconfig | 1 + configs/boston64r6el_defconfig | 1 + configs/ci20_mmc_defconfig | 1 + configs/comtrend_ar5315u_ram_defconfig | 1 + configs/comtrend_ar5387un_ram_defconfig| 1 + configs/comtrend_ct5361_ram_defconfig | 1 + configs/comtrend_vr3032u_ram_defconfig | 1 + configs/comtrend_wap5813n_ram_defconfig| 1 + configs/gardena-smart-gateway-mt7688_defconfig | 1 + configs/huawei_hg556a_ram_defconfig| 1 + configs/imgtec_xilfpga_defconfig | 1 + configs/linkit-smart-7688_defconfig| 1 + configs/malta64_defconfig | 1 + configs/malta64el_defconfig| 1 + configs/malta_defconfig| 1 + configs/maltael_defconfig | 1 + configs/mscc_jr2_defconfig | 1 + configs/mscc_luton_defconfig | 1 + configs/mscc_ocelot_defconfig | 1 + configs/mscc_serval_defconfig | 1 + configs/mscc_servalt_defconfig | 1 + configs/mt7620_mt7530_rfb_defconfig| 1 + configs/mt7620_rfb_defconfig | 1 + configs/mt7621_nand_rfb_defconfig | 1 + configs/mt7621_rfb_defconfig | 1 + configs/mt7628_rfb_defconfig | 1 + configs/netgear_cg3100d_ram_defconfig | 1 + configs/netgear_dgnd3700v2_ram_defconfig | 1 + configs/pic32mzdask_defconfig | 1 + configs/sagem_f@st1704_ram_defconfig | 1 + configs/sfr_nb4-ser_ram_defconfig | 1 + configs/tplink_wdr4300_defconfig | 1 + configs/vocore2_defconfig | 1 + include/configs/ap121.h| 3 --- include/configs/ap143.h| 3 --- include/configs/ap152.h| 3 --- include/configs/bmips_bcm3380.h| 3 --- include/configs/bmips_bcm6318.h| 3 --- include/configs/bmips_bcm63268.h | 3 --- include/configs/bmips_bcm6328.h| 3 --- include/configs/bmips_bcm6338.h| 3 --- include/configs/bmips_bcm6348.h| 3 --- include/configs/bmips_bcm6358.h| 3 --- include/configs/bmips_bcm6362.h| 3 --- include/configs/bmips_bcm6368.h| 3 --- include/configs/bmips_bcm6838.h| 3 --- include/configs/boston.h | 1 - include/configs/ci20.h | 4 include/configs/gardena-smart-gateway-mt7688.h | 3 --- include/configs/imgtec_xilfpga.h | 2 -- include/configs/linkit-smart
Re: [PATCH] mips: mtmips: spl/Kconfig: Set CONFIG_SPL_PAD_TO to 0x0 for ARCH_MTMIPS
On 10/28/22 14:46, Stefan Roese wrote:
It was noticed that while converting CONFIG_SPL_PAD_TO to Kconfig its
value for the MIPS MT762x/8x targets got not ported correctly. Its
default is not 0x1 instead of 0x0. This patch fixes this issue.
Fixes: ca8a329a1b7f ("Convert CONFIG_SPL_PAD_TO et al to Kconfig")
Signed-off-by: Stefan Roese
Cc: Ruben Winters
Cc: Weijie Gao
Cc: Daniel Schwierzeck
Cc: Tom Rini
---
common/spl/Kconfig | 1 +
1 file changed, 1 insertion(+)
applied to u-boot-mips, thanks
--
- Daniel
Re: [ISSUE] Failure to compile for MIPS32 using maltael_defconfig
On 9/29/22 05:45, Majid B. wrote: Hello, I've tried to build U-Boot 2022.07 with the following series of instructions: export CROSS_COMPILE=mipsel-linux-gnu- make mrproper make O=build maltael_defconfig make V=1 O=build -j$(nproc) Unfortunately, I seem to always run into this error: In file included from arch/mips/lib/cache.c:10: ./arch/mips/include/asm/cacheops.h: In function ‘flush_cache’: ./arch/mips/include/asm/cacheops.h:18:9: error: invalid argument to built-in function 18 | __builtin_mips_cache(op, addr); | ^~ make[1]: *** [scripts/Makefile.build:257: arch/mips/lib/cache.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [Makefile:1906: arch/mips/lib] Error 2 make: *** Waiting for unfinished jobs What could I be doing wrong? what toolchain you are using? Is the toolchain bin path set in your PATH variable? If not, you need to include the absolute path to the toolchain in your CROSS_COMPILE variable. So either do (my example uses the kernel.org toolchains): export PATH=/opt/gcc-11.1.0-nolibc/mips-linux/bin:$PATH export CROSS_COMPILE=mips-linux- or export CROSS_COMPILE=/opt/gcc-11.1.0-nolibc/mips-linux/bin/mips-linux- To rule out toolchain issues, you could always try the kernel.org toolchains, with which all U-Boot configs are built in CI. You could use U-Boot's buildman tool to download those toolchains for each supported architecture. E.g. ./tools/buildman/buildman --fetch-arch mips ./tools/buildman/buildman --list-tool-chains I'd really appreciate any help I can get on this. Thank you in advance! Regards, Majid B. -- - Daniel
Re: [PATCH 0/9] Nokia RX-51: Small cleanups and UBI boot test case
On Sun, Sep 04, 2022 at 12:28:24PM -0700, Tony Dinh wrote: > Hi Pali, > > On Sun, Sep 4, 2022 at 2:37 AM Pali Rohár wrote: > > > > On Saturday 03 September 2022 20:01:45 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sat, Sep 3, 2022 at 6:29 PM Pali Rohár wrote: > > > > > > > > Do various small fixup/cleanups and extend test script to boot kernel > > > > image from UBI volume. This test verifies that U-Boot UBI implementation > > > > is working and U-Boot can read volume with bootable kernel code > > > > correctly. And therefore CI prevents UBI breakage. > > > > > > > > Note that U-Boot UBIFS code on ARM is currently somehow broken and > > > > trying to mount UBIFS from UBI volume fails :-( I have already tried to > > > > debug this issue but I have no idea why it is failing. > > > > > > I've recently implemented UBI distro boot on a pair of Kirkwood boards > > > (Pogo V4 and NSA310s) successfully. I created the UBI partition and > > > formatted it in Debian 11.x, Linux kernel 5.19.x. I could let the > > > u-boot distro boot scan the UBI partition to find the boot script > > > boot.scr. And also mount it manually to look at the file system. > > > > Hello! I think you mean UBIFS on UBI, right? > > Yes. UBIFS on UBI. > > > > > > An observation: I cannot mount OpenWrt rootfs in u-boot, since it is > > > an UBIFS volume overlay on squashfs. But creating my own UBIFS volume > > > allowed me to mount it in the u-boot command line. I think squashfs is > > > incomplete in u-boot, at the moment. > > > > UBIFS on squashfs? This looks strange. AFAIK UBIFS (also on linux) works > > only on UBI. I guess you could have squashfs on UBI, but on linux this > > requires mtdblock, hence it is squashfs on mtdblock on UBI. > > I meant that (the rootfs) is a squashfs inside an UBIFS volume. And > the system running with another UBIFS volume overlaid on top of that. Just to clarify: OpenWrt uses squashfs in UBI volumes for the compressed rootfs. In Linux, ubiblock is used to mount them. We also usually don't store the kernel in a filesystem but just use a bare UBI volume to directly store the uImage.FIT to be booted, for both simplicity and robustness reasons. On devices with recent enough U-Boot we can use a 'filesystem'-type sub-image of a uImage.FIT for squashfs and mount that in Linux. > > Best, > Tony > > > > > > Best, > > > Tony > > > > > > > > > > Function > > > > check_lpt_crc in unpack_ltab is failing. Volume is for sure correct and > > > > valid because Linux kernel can successfully mount it. And to make it > > > > more suspicious, U-Boot UBIFS is working fine on big endian powerpc > > > > platform. So UBIFS issue is probably endian or arch specific. > > > > (This is UBIFS related, not UBI related.) > > > > > > > > Pali Rohár (9): > > > > Nokia RX-51: Remove label copy_kernel_start from lowlevel_init.S > > > > Nokia RX-51: Do not clear unknown memory in lowlevel_init.S > > > > Nokia RX-51: Set default SYS_LOAD_ADDR to 0x80008000 > > > > Nokia RX-51: Change UBIFS volume size to 1870 LEBs in test script > > > > Nokia RX-51: Call bootm in test script only when image is valid > > > > Nokia RX-51: Fix documentation how to enable UBI support > > > > Nokia RX-51: Do not set useless ARCH= in test script > > > > Nokia RX-51: Add comment describing kernel image type into test script > > > > Nokia RX-51: Add booting from UBI into test script > > > > > > > > board/nokia/rx51/lowlevel_init.S | 7 +-- > > > > configs/nokia_rx51_defconfig | 2 +- > > > > doc/board/nokia/rx51.rst | 3 +- > > > > test/nokia_rx51_test.sh | 97 +--- > > > > 4 files changed, 82 insertions(+), 27 deletions(-) > > > > > > > > -- > > > > 2.20.1 > > > >
Re: [PATCH v2 31/32] tools: mtk_image: add support for nand headers used by newer chips
On Wed, Aug 31, 2022 at 07:05:26PM +0800, Weijie Gao wrote:
> This patch adds more nand headers in two new types:
> 1. HSM header, used for spi-nand thru SNFI interface
> 2. SPIM header, used for spi-nand thru spi-mem interface
>
> The original nand header is renamed to AP header.
Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).
Tested-by: Daniel Golle
>
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> tools/mtk_image.c| 23 ++-
> tools/mtk_nand_headers.c | 422 +--
> tools/mtk_nand_headers.h | 110 +-
> 3 files changed, 525 insertions(+), 30 deletions(-)
>
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index 1f7396aa69..9b3136afa3 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -33,6 +33,9 @@ static const struct brom_img_type {
> }, {
> .name = "snand",
> .type = BRLYT_TYPE_SNAND
> + }, {
> + .name = "spim-nand",
> + .type = BRLYT_TYPE_SNAND
> }
> };
>
> @@ -54,7 +57,7 @@ static char lk_name[32] = "U-Boot";
> static uint32_t crc32tbl[256];
>
> /* NAND header selected by user */
> -static const union nand_boot_header *hdr_nand;
> +static const struct nand_header_type *hdr_nand;
> static uint32_t hdr_nand_size;
>
> /* GFH header + 2 * 4KB pages of NAND */
> @@ -366,20 +369,26 @@ static int mtk_image_verify_nand_header(const uint8_t
> *ptr, int print)
> if (ret < 0)
> return ret;
>
> - bh = (struct brom_layout_header *)(ptr + info.page_size);
> + if (!ret) {
> + bh = (struct brom_layout_header *)(ptr + info.page_size);
>
> - if (strcmp(bh->name, BRLYT_NAME))
> - return -1;
> + if (strcmp(bh->name, BRLYT_NAME))
> + return -1;
> +
> + if (le32_to_cpu(bh->magic) != BRLYT_MAGIC)
> + return -1;
>
> - if (le32_to_cpu(bh->magic) != BRLYT_MAGIC) {
> - return -1;
> - } else {
> if (le32_to_cpu(bh->type) == BRLYT_TYPE_NAND)
> bootmedia = "Parallel NAND";
> else if (le32_to_cpu(bh->type) == BRLYT_TYPE_SNAND)
> bootmedia = "Serial NAND (SNFI/AP)";
> else
> return -1;
> + } else {
> + if (info.snfi)
> + bootmedia = "Serial NAND (SNFI/HSM)";
> + else
> + bootmedia = "Serial NAND (SPIM)";
> }
>
> if (print) {
> diff --git a/tools/mtk_nand_headers.c b/tools/mtk_nand_headers.c
> index 12f827c39f..2fa91e7af0 100644
> --- a/tools/mtk_nand_headers.c
> +++ b/tools/mtk_nand_headers.c
> @@ -188,55 +188,346 @@ static const union nand_boot_header
> nand_hdr_4gb_2k_128_data = {
> }
> };
>
> -static const struct nand_header_type {
> +/* HSM BROM NAND header for SPI NAND with 2KB page + 64B spare */
> +static const union hsm_nand_boot_header hsm_nand_hdr_2k_64_data = {
> + .data = {
> + 0x4E, 0x41, 0x4E, 0x44, 0x43, 0x46, 0x47, 0x21,
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x04, 0x00, 0x00, 0x08, 0x00, 0x00, 0x00,
> + 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x08, 0x00, 0x00, 0x40, 0x00, 0x00, 0x00,
> + 0x40, 0x00, 0x00, 0x00, 0x00, 0x08, 0x00, 0x00,
> + 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> + 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00,
> + 0xFF, 0x00, 0x00, 0x00, 0x21, 0xD2, 0xEE, 0xF6,
> + 0xAE, 0xDD, 0x5E, 0xC2, 0x82, 0x8E, 0x9A, 0x62,
> + 0x09, 0x8E, 0x80, 0xE2, 0x37, 0x0D, 0xC9, 0xFA,
> + 0xA9, 0xDD, 0xFC, 0x92, 0x34, 0x2A, 0xED, 0x51,
> + 0xA4, 0x1B, 0xF7, 0x63, 0xCC, 0x5A, 0xC7, 0xFB,
> + 0xED, 0x21, 0x02, 0x23, 0x51, 0x31
> + }
> +};
> +
> +/* HSM BROM NAND header for SPI NAND with 2KB page + 128B spare */
> +static const union hsm_nand_boot_header hsm_nand_hdr_2k_128_data = {
> + .data = {
> +
Re: [PATCH v2 30/32] tools: mtk_image: split the code of generating NAND header into a new file
On Wed, Aug 31, 2022 at 07:05:24PM +0800, Weijie Gao wrote:
> The predefined NAND headers take too much spaces in the mtk_image.c.
> Moving them into a new file can significantly improve the readability of
> both mtk_image.c and the new mtk_nand_headers.c.
>
> This is a preparation for adding more NAND headers.
Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Add comments
> Call mtk_nand_header_size only for NAND/SNAND to avoid NULL pointer access
> ---
> tools/Makefile | 1 +
> tools/mtk_image.c| 305 ++-
> tools/mtk_image.h| 25
> tools/mtk_nand_headers.c | 286
> tools/mtk_nand_headers.h | 61
> 5 files changed, 389 insertions(+), 289 deletions(-)
> create mode 100644 tools/mtk_nand_headers.c
> create mode 100644 tools/mtk_nand_headers.h
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 3626919633..34a1aa7a8b 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -147,6 +147,7 @@ dumpimage-mkimage-objs := aisimage.o \
> gpimage.o \
> gpimage-common.o \
> mtk_image.o \
> + mtk_nand_headers.o \
> $(ECDSA_OBJS-y) \
> $(RSA_OBJS-y) \
> $(AES_OBJS-y)
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index dcd6525f32..1f7396aa69 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -12,216 +12,7 @@
> #include
> #include "imagetool.h"
> #include "mtk_image.h"
> -
> -/* NAND header for SPI-NAND with 2KB page + 64B spare */
> -static const union nand_boot_header snand_hdr_2k_64_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x03, 0x00, 0x40, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x7B, 0xC4, 0x17, 0x9D,
> - 0xCA, 0x42, 0x90, 0xD0, 0x98, 0xD0, 0xE0, 0xF7,
> - 0xDB, 0xCD, 0x16, 0xF6, 0x03, 0x73, 0xD2, 0xB8,
> - 0x93, 0xB2, 0x56, 0x5A, 0x84, 0x6E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 2KB page + 120B/128B spare */
> -static const union nand_boot_header snand_hdr_2k_128_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x05, 0x00, 0x70, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x90, 0x28, 0xED, 0x13,
> - 0x7F, 0x12, 0x22, 0xCD, 0x3D, 0x06, 0xF1, 0xB3,
> - 0x6F, 0x2E, 0xD9, 0xA0, 0x9D, 0x7A, 0xBD, 0xD7,
> - 0xB3, 0x28, 0x3C, 0x13, 0xDB, 0x4E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 4KB page + 256B spare */
> -static const union nand_boot_header snand_hdr_4k_256_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x10, 0x05, 0x00, 0xE0, 0x00
Re: [PATCH v2 29/32] tools: mtk_image: split gfh header verification into a new function
On Wed, Aug 31, 2022 at 07:05:22PM +0800, Weijie Gao wrote:
> The verification code of gfh header for NAND and non-NAND are identical.
> It's better to define a individual function to reduce redundancy.
Tested ARM Trusted Firmware-A bl2 images generated for
Bananapi R64 (MT7622; eMMC, SDMMC, SPI-NAND),
UniFi 6 LR (MT7622; SPI-NOR) and
Bananapi BPi-R3 (MT7986A; eMMC, SDMMC, SPI-NAND, SPI-NOR).
Also tested MT7621 images still work fine on ZBT-WG3526 (MT7621; SPI-NOR).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> tools/mtk_image.c | 51 +++
> 1 file changed, 21 insertions(+), 30 deletions(-)
>
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index de5ce4d964..dcd6525f32 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -480,6 +480,25 @@ static int mtk_image_vrec_header(struct
> image_tool_params *params,
> return SHA256_SUM_LEN;
> }
>
> +static int mtk_image_verify_gfh(struct gfh_header *gfh, uint32_t type, int
> print)
> +{
> + if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> + return -1;
> +
> + if (le32_to_cpu(gfh->file_info.flash_type) != type)
> + return -1;
> +
> + if (print)
> + printf("Load Address: %08x\n",
> +le32_to_cpu(gfh->file_info.load_addr) +
> +le32_to_cpu(gfh->file_info.jump_offset));
> +
> + if (print)
> + printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> +
> + return 0;
> +}
> +
> static int mtk_image_verify_gen_header(const uint8_t *ptr, int print)
> {
> union gen_boot_header *gbh = (union gen_boot_header *)ptr;
> @@ -542,21 +561,7 @@ static int mtk_image_verify_gen_header(const uint8_t
> *ptr, int print)
>
> gfh = (struct gfh_header *)(ptr + gfh_offset);
>
> - if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> - return -1;
> -
> - if (le32_to_cpu(gfh->file_info.flash_type) != GFH_FLASH_TYPE_GEN)
> - return -1;
> -
> - if (print)
> - printf("Load Address: %08x\n",
> -le32_to_cpu(gfh->file_info.load_addr) +
> -le32_to_cpu(gfh->file_info.jump_offset));
> -
> - if (print)
> - printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> -
> - return 0;
> + return mtk_image_verify_gfh(gfh, GFH_FLASH_TYPE_GEN, print);
> }
>
> static int mtk_image_verify_nand_header(const uint8_t *ptr, int print)
> @@ -610,21 +615,7 @@ static int mtk_image_verify_nand_header(const uint8_t
> *ptr, int print)
>
> gfh = (struct gfh_header *)(ptr + 2 * le16_to_cpu(nh->pagesize));
>
> - if (strcmp(gfh->file_info.name, GFH_FILE_INFO_NAME))
> - return -1;
> -
> - if (le32_to_cpu(gfh->file_info.flash_type) != GFH_FLASH_TYPE_NAND)
> - return -1;
> -
> - if (print)
> - printf("Load Address: %08x\n",
> -le32_to_cpu(gfh->file_info.load_addr) +
> -le32_to_cpu(gfh->file_info.jump_offset));
> -
> - if (print)
> - printf("Architecture: %s\n", is_arm64_image ? "ARM64" : "ARM");
> -
> - return 0;
> + return mtk_image_verify_gfh(gfh, GFH_FLASH_TYPE_NAND, print);
> }
>
> static uint32_t crc32be_cal(const void *data, size_t length)
> --
> 2.17.1
>
Re: [PATCH v2 28/32] cpu: add basic cpu driver for MediaTek ARM chips
On Wed, Aug 31, 2022 at 07:05:20PM +0800, Weijie Gao wrote:
> Add basic CPU driver used to retrieve CPU model information.
>
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
> Signed-off-by: Weijie Gao
> ---
> v2 changes: new
> ---
> drivers/cpu/Makefile | 1 +
> drivers/cpu/mtk_cpu.c | 106 ++
> 2 files changed, 107 insertions(+)
> create mode 100644 drivers/cpu/mtk_cpu.c
>
> diff --git a/drivers/cpu/Makefile b/drivers/cpu/Makefile
> index 20884b1795..3b38ba9c58 100644
> --- a/drivers/cpu/Makefile
> +++ b/drivers/cpu/Makefile
> @@ -9,6 +9,7 @@ obj-$(CONFIG_CPU) += cpu-uclass.o
> obj-$(CONFIG_ARCH_BMIPS) += bmips_cpu.o
> obj-$(CONFIG_ARCH_IMX8) += imx8_cpu.o
> obj-$(CONFIG_ARCH_AT91) += at91_cpu.o
> +obj-$(CONFIG_ARCH_MEDIATEK) += mtk_cpu.o
> obj-$(CONFIG_CPU_MPC83XX) += mpc83xx_cpu.o
> obj-$(CONFIG_CPU_RISCV) += riscv_cpu.o
> obj-$(CONFIG_CPU_MICROBLAZE) += microblaze_cpu.o
> diff --git a/drivers/cpu/mtk_cpu.c b/drivers/cpu/mtk_cpu.c
> new file mode 100644
> index 00..d00b4c669e
> --- /dev/null
> +++ b/drivers/cpu/mtk_cpu.c
> @@ -0,0 +1,106 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2022 MediaTek Inc. All rights reserved.
> + *
> + * Author: Weijie Gao
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct mtk_cpu_plat {
> + void __iomem *hwver_base;
> +};
> +
> +static int mtk_cpu_get_desc(const struct udevice *dev, char *buf, int size)
> +{
> + struct mtk_cpu_plat *plat = dev_get_plat(dev);
> +
> + snprintf(buf, size, "MediaTek MT%04X", readl(plat->hwver_base));
> +
> + return 0;
> +}
> +
> +static int mtk_cpu_get_count(const struct udevice *dev)
> +{
> + return 1;
> +}
> +
> +static int mtk_cpu_get_vendor(const struct udevice *dev, char *buf, int size)
> +{
> + snprintf(buf, size, "MediaTek");
> +
> + return 0;
> +}
> +
> +static int mtk_cpu_probe(struct udevice *dev)
> +{
> + struct mtk_cpu_plat *plat = dev_get_plat(dev);
> + const void *fdt = gd->fdt_blob, *reg;
> + int offset, parent, len, na, ns;
> + u64 addr;
> +
> + if (!fdt)
> + return -ENODEV;
> +
> + offset = fdt_path_offset(fdt, "/hwver");
> + if (offset < 0)
> + return -ENODEV;
> +
> + parent = fdt_parent_offset(fdt, offset);
> + if (parent < 0)
> + return -ENODEV;
> +
> + na = fdt_address_cells(fdt, parent);
> + if (na < 1)
> + return -ENODEV;
> +
> + ns = fdt_size_cells(gd->fdt_blob, parent);
> + if (ns < 0)
> + return -ENODEV;
> +
> + reg = fdt_getprop(gd->fdt_blob, offset, "reg", );
> + if (!reg)
> + return -ENODEV;
> +
> + if (ns)
> + addr = fdt_translate_address(fdt, offset, reg);
> + else
> + addr = fdt_read_number(reg, na);
> +
> + plat->hwver_base = map_sysmem(addr, 0);
> + if (!plat->hwver_base)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static const struct cpu_ops mtk_cpu_ops = {
> + .get_desc = mtk_cpu_get_desc,
> + .get_count = mtk_cpu_get_count,
> + .get_vendor = mtk_cpu_get_vendor,
> +};
> +
> +static const struct udevice_id mtk_cpu_ids[] = {
> + { .compatible = "arm,cortex-a7" },
> + { .compatible = "arm,cortex-a53" },
> + { .compatible = "arm,cortex-a73" },
> + { /* sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(cpu_mtk) = {
> + .name = "mtk-cpu",
> + .id = UCLASS_CPU,
> + .of_match = mtk_cpu_ids,
> + .ops= _cpu_ops,
> + .probe = mtk_cpu_probe,
> + .plat_auto = sizeof(struct mtk_cpu_plat),
> + .flags = DM_FLAG_PRE_RELOC,
> +};
> --
> 2.17.1
>
Re: [PATCH v2 26/32] clk: mediatek: add clock driver support for MediaTek MT7986 SoC
On Wed, Aug 31, 2022 at 07:05:13PM +0800, Weijie Gao wrote:
> This patch adds clock driver support for MediaTek MT7986 SoC
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Sean Anderson
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Fix coding style
> ---
> drivers/clk/mediatek/Makefile | 1 +
> drivers/clk/mediatek/clk-mt7986.c | 672 +
> include/dt-bindings/clock/mt7986-clk.h | 249 +
> 3 files changed, 922 insertions(+)
> create mode 100644 drivers/clk/mediatek/clk-mt7986.c
> create mode 100644 include/dt-bindings/clock/mt7986-clk.h
>
> diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
> index 522e724221..1aa38215bf 100644
> --- a/drivers/clk/mediatek/Makefile
> +++ b/drivers/clk/mediatek/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_MT8512) += clk-mt8512.o
> obj-$(CONFIG_TARGET_MT7623) += clk-mt7623.o
> obj-$(CONFIG_TARGET_MT7622) += clk-mt7622.o
> obj-$(CONFIG_TARGET_MT7629) += clk-mt7629.o
> +obj-$(CONFIG_TARGET_MT7986) += clk-mt7986.o
> obj-$(CONFIG_TARGET_MT8183) += clk-mt8183.o
> obj-$(CONFIG_TARGET_MT8516) += clk-mt8516.o
> obj-$(CONFIG_TARGET_MT8518) += clk-mt8518.o
> diff --git a/drivers/clk/mediatek/clk-mt7986.c
> b/drivers/clk/mediatek/clk-mt7986.c
> new file mode 100644
> index 00..b3fa63fc0a
> --- /dev/null
> +++ b/drivers/clk/mediatek/clk-mt7986.c
> @@ -0,0 +1,672 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * MediaTek clock driver for MT7986 SoC
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk-mtk.h"
> +
> +#define MT7986_CLK_PDN 0x250
> +#define MT7986_CLK_PDN_EN_WRITE BIT(31)
> +
> +#define PLL_FACTOR(_id, _name, _parent, _mult, _div)
> \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_APMIXED)
> +
> +#define TOP_FACTOR(_id, _name, _parent, _mult, _div)
> \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_TOPCKGEN)
> +
> +#define INFRA_FACTOR(_id, _name, _parent, _mult, _div)
> \
> + FACTOR(_id, _parent, _mult, _div, CLK_PARENT_INFRASYS)
> +
> +/* FIXED PLLS */
> +static const struct mtk_fixed_clk fixed_pll_clks[] = {
> + FIXED_CLK(CK_APMIXED_ARMPLL, CLK_XTAL, 20),
> + FIXED_CLK(CK_APMIXED_NET2PLL, CLK_XTAL, 8),
> + FIXED_CLK(CK_APMIXED_MMPLL, CLK_XTAL, 144000),
> + FIXED_CLK(CK_APMIXED_SGMPLL, CLK_XTAL, 32500),
> + FIXED_CLK(CK_APMIXED_WEDMCUPLL, CLK_XTAL, 76000),
> + FIXED_CLK(CK_APMIXED_NET1PLL, CLK_XTAL, 25),
> + FIXED_CLK(CK_APMIXED_MPLL, CLK_XTAL, 41600),
> + FIXED_CLK(CK_APMIXED_APLL2, CLK_XTAL, 196608000),
> +};
> +
> +/* TOPCKGEN FIXED CLK */
> +static const struct mtk_fixed_clk top_fixed_clks[] = {
> + FIXED_CLK(CK_TOP_CB_CKSQ_40M, CLK_XTAL, 4000),
> +};
> +
> +/* TOPCKGEN FIXED DIV */
> +static const struct mtk_fixed_factor top_fixed_divs[] = {
> + PLL_FACTOR(CK_TOP_CB_M_416M, "cb_m_416m", CK_APMIXED_MPLL, 1, 1),
> + PLL_FACTOR(CK_TOP_CB_M_D2, "cb_m_d2", CK_APMIXED_MPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_M_D4, "cb_m_d4", CK_APMIXED_MPLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_M_D8, "cb_m_d8", CK_APMIXED_MPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_M_D8_D2, "m_d8_d2", CK_APMIXED_MPLL, 1, 16),
> + PLL_FACTOR(CK_TOP_M_D3_D2, "m_d3_d2", CK_APMIXED_MPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_MM_D2, "cb_mm_d2", CK_APMIXED_MMPLL, 1, 2),
> + PLL_FACTOR(CK_TOP_CB_MM_D4, "cb_mm_d4", CK_APMIXED_MMPLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_MM_D8, "cb_mm_d8", CK_APMIXED_MMPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_MM_D8_D2, "mm_d8_d2", CK_APMIXED_MMPLL, 1, 16),
> + PLL_FACTOR(CK_TOP_MM_D3_D8, "mm_d3_d8", CK_APMIXED_MMPLL, 1, 8),
> + PLL_FACTOR(CK_TOP_CB_U2_PHYD_CK, "cb_u2_phyd", CK_APMIXED_MMPLL, 1, 30),
> + PLL_FACTOR(CK_TOP_CB_APLL2_196M, "cb_apll2_196m", CK_APMIXED_APLL2, 1,
> +1),
> + PLL_FACTOR(CK_TOP_APLL2_D4, "apll2_d4", CK_APMIXED_APLL2, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_NET1_D4, "cb_net1_d4", CK_APMIXED_NET1PLL, 1, 4),
> + PLL_FACTOR(CK_TOP_CB_NET1_D5, "cb_net1_d5", CK_APMIXED_NET1PLL, 1, 5),
> + PLL_FACTOR(CK_TOP_NET1_D5_D2, "net1_d5_d2", CK_APMIXED_NET1PLL, 1, 10),
> + PLL_FACTOR(CK_TOP_NET1_D5_D4, "net1_d5_d4", CK_APMIXED_NET1PLL, 1, 20),
> + PLL_FACTOR(CK_TOP_NET1_
Re: [PATCH v2 25/32] clk: mediatek: add CLK_XTAL support for clock driver
On Wed, Aug 31, 2022 at 07:05:11PM +0800, Weijie Gao wrote: > This adds the CLK_XTAL macro/flag to allow modeling clocks which are > directly connected to the xtal clock. Tested on Bananapi BPi-R3 (MT7986A). Tested-by: Daniel Golle > > Signed-off-by: Weijie Gao > --- > v2 changes: > Fix incorrect fallback in mtk_infrasys_get_factor_rate > Fix commit description > --- > drivers/clk/mediatek/clk-mtk.c | 4 > drivers/clk/mediatek/clk-mtk.h | 3 ++- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c > index 207a4c6b11..4303300d3a 100644 > --- a/drivers/clk/mediatek/clk-mtk.c > +++ b/drivers/clk/mediatek/clk-mtk.c > @@ -296,6 +296,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk > *clk, u32 off) > rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL); > break; > > + case CLK_PARENT_XTAL: > default: > rate = priv->tree->xtal_rate; > } > @@ -314,6 +315,9 @@ static ulong mtk_infrasys_get_factor_rate(struct clk > *clk, u32 off) > rate = mtk_clk_find_parent_rate(clk, fdiv->parent, > priv->parent); > break; > + case CLK_PARENT_XTAL: > + rate = priv->tree->xtal_rate; > + break; > default: > rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL); > } > diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h > index e7c61ae483..48ce16484e 100644 > --- a/drivers/clk/mediatek/clk-mtk.h > +++ b/drivers/clk/mediatek/clk-mtk.h > @@ -29,7 +29,8 @@ > #define CLK_PARENT_APMIXED BIT(4) > #define CLK_PARENT_TOPCKGEN BIT(5) > #define CLK_PARENT_INFRASYS BIT(6) > -#define CLK_PARENT_MASK GENMASK(6, 4) > +#define CLK_PARENT_XTAL BIT(7) > +#define CLK_PARENT_MASK GENMASK(7, 4) > > #define ETHSYS_HIFSYS_RST_CTRL_OFS 0x34 > > -- > 2.17.1 >
Re: [PATCH v2 24/32] clk: mediatek: add infrasys clock mux support
On Wed, Aug 31, 2022 at 07:05:09PM +0800, Weijie Gao wrote:
> This patch adds infrasys clock mux support for mediatek clock drivers.
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Fix the if condition of CLK_BYPASS_XTAL
> ---
> drivers/clk/mediatek/clk-mtk.c | 71 ++
> drivers/clk/mediatek/clk-mtk.h | 4 +-
> 2 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index a537ff259f..207a4c6b11 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -303,6 +303,24 @@ static ulong mtk_topckgen_get_factor_rate(struct clk
> *clk, u32 off)
> return mtk_factor_recalc_rate(fdiv, rate);
> }
>
> +static ulong mtk_infrasys_get_factor_rate(struct clk *clk, u32 off)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> + const struct mtk_fixed_factor *fdiv = >tree->fdivs[off];
> + ulong rate;
> +
> + switch (fdiv->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_TOPCKGEN:
> + rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
> + priv->parent);
> + break;
> + default:
> + rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
> + }
> +
> + return mtk_factor_recalc_rate(fdiv, rate);
> +}
> +
> static ulong mtk_topckgen_get_mux_rate(struct clk *clk, u32 off)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -331,6 +349,33 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
> u32 off)
> return priv->tree->xtal_rate;
> }
>
> +static ulong mtk_infrasys_get_mux_rate(struct clk *clk, u32 off)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> + const struct mtk_composite *mux = >tree->muxes[off];
> + u32 index;
> +
> + index = readl(priv->base + mux->mux_reg);
> + index &= mux->mux_mask << mux->mux_shift;
> + index = index >> mux->mux_shift;
> +
> + if (mux->parent[index] > 0 ||
> + (mux->parent[index] == CLK_XTAL &&
> + priv->tree->flags & CLK_BYPASS_XTAL)) {
> + switch (mux->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_TOPCKGEN:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + priv->parent);
> + break;
> + default:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + NULL);
> + break;
> + }
> + }
> + return 0;
> +}
> +
> static ulong mtk_topckgen_get_rate(struct clk *clk)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -345,6 +390,25 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
>priv->tree->muxes_offs);
> }
>
> +static ulong mtk_infrasys_get_rate(struct clk *clk)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> +
> + ulong rate;
> +
> + if (clk->id < priv->tree->fdivs_offs) {
> + rate = priv->tree->fclks[clk->id].rate;
> + } else if (clk->id < priv->tree->muxes_offs) {
> + rate = mtk_infrasys_get_factor_rate(clk, clk->id -
> + priv->tree->fdivs_offs);
> + } else {
> + rate = mtk_infrasys_get_mux_rate(clk, clk->id -
> + priv->tree->muxes_offs);
> + }
> +
> + return rate;
> +}
> +
> static int mtk_clk_mux_enable(struct clk *clk)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> @@ -493,6 +557,13 @@ const struct clk_ops mtk_clk_topckgen_ops = {
> .set_parent = mtk_common_clk_set_parent,
> };
>
> +const struct clk_ops mtk_clk_infrasys_ops = {
> + .enable = mtk_clk_mux_enable,
> + .disable = mtk_clk_mux_disable,
> + .get_rate = mtk_infrasys_get_rate,
> + .set_parent = mtk_common_clk_set_parent,
> +};
> +
> const struct clk_ops mtk_clk_gate_ops = {
> .enable = mtk_clk_gate_enable,
> .disable = mtk_clk_gate_disable,
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 41854879c6..e7c61ae483 100644
> --- a/drivers/clk/mediatek/c
Re: [PATCH v2 23/32] clk: mediatek: add support to configure clock driver parent
On Wed, Aug 31, 2022 at 07:05:06PM +0800, Weijie Gao wrote:
> This patch adds support for a clock node to configure its parent clock
> where possible.
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/clk/mediatek/clk-mtk.c | 79 --
> drivers/clk/mediatek/clk-mtk.h | 2 +
> 2 files changed, 48 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index 7d145f4975..a537ff259f 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -42,20 +42,14 @@
> * the accurate frequency.
> */
> static ulong mtk_clk_find_parent_rate(struct clk *clk, int id,
> - const struct driver *drv)
> + struct udevice *pdev)
> {
> struct clk parent = { .id = id, };
>
> - if (drv) {
> - struct udevice *dev;
> -
> - if (uclass_get_device_by_driver(UCLASS_CLK, drv, ))
> - return -ENODEV;
> -
> - parent.dev = dev;
> - } else {
> + if (pdev)
> + parent.dev = pdev;
> + else
> parent.dev = clk->dev;
> - }
>
> return clk_get_rate();
> }
> @@ -296,7 +290,7 @@ static ulong mtk_topckgen_get_factor_rate(struct clk
> *clk, u32 off)
> switch (fdiv->flags & CLK_PARENT_MASK) {
> case CLK_PARENT_APMIXED:
> rate = mtk_clk_find_parent_rate(clk, fdiv->parent,
> - DM_DRIVER_GET(mtk_clk_apmixedsys));
> + priv->parent);
> break;
> case CLK_PARENT_TOPCKGEN:
> rate = mtk_clk_find_parent_rate(clk, fdiv->parent, NULL);
> @@ -321,9 +315,18 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
> u32 off)
>
> if (mux->parent[index] > 0 ||
> (mux->parent[index] == CLK_XTAL &&
> - priv->tree->flags & CLK_BYPASS_XTAL))
> - return mtk_clk_find_parent_rate(clk, mux->parent[index],
> - NULL);
> + priv->tree->flags & CLK_BYPASS_XTAL)) {
> + switch (mux->flags & CLK_PARENT_MASK) {
> + case CLK_PARENT_APMIXED:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + priv->parent);
> + break;
> + default:
> + return mtk_clk_find_parent_rate(clk, mux->parent[index],
> + NULL);
> + break;
> + }
> + }
>
> return priv->tree->xtal_rate;
> }
> @@ -342,7 +345,7 @@ static ulong mtk_topckgen_get_rate(struct clk *clk)
>priv->tree->muxes_offs);
> }
>
> -static int mtk_topckgen_enable(struct clk *clk)
> +static int mtk_clk_mux_enable(struct clk *clk)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> const struct mtk_composite *mux;
> @@ -375,7 +378,7 @@ static int mtk_topckgen_enable(struct clk *clk)
> return 0;
> }
>
> -static int mtk_topckgen_disable(struct clk *clk)
> +static int mtk_clk_mux_disable(struct clk *clk)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
> const struct mtk_composite *mux;
> @@ -401,7 +404,7 @@ static int mtk_topckgen_disable(struct clk *clk)
> return 0;
> }
>
> -static int mtk_topckgen_set_parent(struct clk *clk, struct clk *parent)
> +static int mtk_common_clk_set_parent(struct clk *clk, struct clk *parent)
> {
> struct mtk_clk_priv *priv = dev_get_priv(clk->dev);
>
> @@ -473,19 +476,7 @@ static ulong mtk_clk_gate_get_rate(struct clk *clk)
> struct mtk_cg_priv *priv = dev_get_priv(clk->dev);
> const struct mtk_gate *gate = >gates[clk->id];
>
> - switch (gate->flags & CLK_PARENT_MASK) {
> - case CLK_PARENT_APMIXED:
> - return mtk_clk_find_parent_rate(clk, gate->parent,
> - DM_DRIVER_GET(mtk_clk_apmixedsys));
> - break;
> - case CLK_PARENT_TOPCKGEN:
> - return mtk_clk_find_parent_rate(clk, gate->parent,
> - DM_DRIVER_GET(mtk_clk_topckgen));
> - break;
> -
> - default:
> - return priv->tree->xtal_rate;
> - }
> +
Re: [PATCH v2 22/32] clk: mediatek: add CLK_BYPASS_XTAL flag to allow bypassing searching clock parent of xtal clock
On Wed, Aug 31, 2022 at 07:04:59PM +0800, Weijie Gao wrote:
> The mtk clock framework in u-boot uses array index for searching clock
> parent (kernel uses strings for search), so we need to specify a special
> clock with ID=0 for CLK_XTAL in u-boot.
>
> In the mt7622/mt7629 clock tree, the clocks with ID=0 never call
> mtk_topckgen_get_mux_rate, adn return xtal clock directly. This what we
> expected.
>
> However for newer chips, they may have some clocks with ID=0 not
> representing the xtal clock and still needs mtk_topckgen_get_mux_rate be
> called. Current logic will make entire clock driver not working.
>
> This patch adds a flag to indicate that whether a clock driver needs clocks
> with ID=0 to call mtk_topckgen_get_mux_rate.
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Add comment for flags
> Fix the if condition of CLK_BYPASS_XTAL
> ---
> drivers/clk/mediatek/clk-mtk.c | 4 +++-
> drivers/clk/mediatek/clk-mtk.h | 6 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mtk.c b/drivers/clk/mediatek/clk-mtk.c
> index d43b8a0648..7d145f4975 100644
> --- a/drivers/clk/mediatek/clk-mtk.c
> +++ b/drivers/clk/mediatek/clk-mtk.c
> @@ -319,7 +319,9 @@ static ulong mtk_topckgen_get_mux_rate(struct clk *clk,
> u32 off)
> index &= mux->mux_mask << mux->mux_shift;
> index = index >> mux->mux_shift;
>
> - if (mux->parent[index])
> + if (mux->parent[index] > 0 ||
> + (mux->parent[index] == CLK_XTAL &&
> + priv->tree->flags & CLK_BYPASS_XTAL))
> return mtk_clk_find_parent_rate(clk, mux->parent[index],
> NULL);
>
> diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
> index 95a23d14a8..e0c5550c80 100644
> --- a/drivers/clk/mediatek/clk-mtk.h
> +++ b/drivers/clk/mediatek/clk-mtk.h
> @@ -11,6 +11,11 @@
> #define CLK_XTAL 0
> #define MHZ (1000 * 1000)
>
> +/* flags in struct mtk_clk_tree */
> +
> +/* clk id == 0 doesn't mean it's xtal clk */
> +#define CLK_BYPASS_XTAL BIT(0)
> +
> #define HAVE_RST_BAR BIT(0)
> #define CLK_DOMAIN_SCPSYSBIT(0)
> #define CLK_MUX_SETCLR_UPD BIT(1)
> @@ -197,6 +202,7 @@ struct mtk_clk_tree {
> const struct mtk_fixed_clk *fclks;
> const struct mtk_fixed_factor *fdivs;
> const struct mtk_composite *muxes;
> + u32 flags;
> };
>
> struct mtk_clk_priv {
> --
> 2.17.1
>
Re: [PATCH v2 21/32] pinctrl: mediatek: add pinctrl driver for MT7986 SoC
On Wed, Aug 31, 2022 at 07:04:57PM +0800, Weijie Gao wrote:
> This patch adds pinctrl and gpio support for MT7986 SoC
>
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/pinctrl/mediatek/Kconfig | 4 +
> drivers/pinctrl/mediatek/Makefile | 1 +
> drivers/pinctrl/mediatek/pinctrl-mt7986.c | 775 ++
> 3 files changed, 780 insertions(+)
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7986.c
>
> diff --git a/drivers/pinctrl/mediatek/Kconfig
> b/drivers/pinctrl/mediatek/Kconfig
> index aceec9277d..27e8998e59 100644
> --- a/drivers/pinctrl/mediatek/Kconfig
> +++ b/drivers/pinctrl/mediatek/Kconfig
> @@ -20,6 +20,10 @@ config PINCTRL_MT7981
> bool "MT7981 SoC pinctrl driver"
> select PINCTRL_MTK
>
> +config PINCTRL_MT7986
> + bool "MT7986 SoC pinctrl driver"
> + select PINCTRL_MTK
> +
> config PINCTRL_MT8512
> bool "MT8512 SoC pinctrl driver"
> select PINCTRL_MTK
> diff --git a/drivers/pinctrl/mediatek/Makefile
> b/drivers/pinctrl/mediatek/Makefile
> index 1879d7ae2a..6e733759f5 100644
> --- a/drivers/pinctrl/mediatek/Makefile
> +++ b/drivers/pinctrl/mediatek/Makefile
> @@ -7,6 +7,7 @@ obj-$(CONFIG_PINCTRL_MT7622) += pinctrl-mt7622.o
> obj-$(CONFIG_PINCTRL_MT7623) += pinctrl-mt7623.o
> obj-$(CONFIG_PINCTRL_MT7629) += pinctrl-mt7629.o
> obj-$(CONFIG_PINCTRL_MT7981) += pinctrl-mt7981.o
> +obj-$(CONFIG_PINCTRL_MT7986) += pinctrl-mt7986.o
> obj-$(CONFIG_PINCTRL_MT8512) += pinctrl-mt8512.o
> obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-mt8516.o
> obj-$(CONFIG_PINCTRL_MT8518) += pinctrl-mt8518.o
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mt7986.c
> b/drivers/pinctrl/mediatek/pinctrl-mt7986.c
> new file mode 100644
> index 00..449e5adcd9
> --- /dev/null
> +++ b/drivers/pinctrl/mediatek/pinctrl-mt7986.c
> @@ -0,0 +1,775 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * The MT7986 driver based on Linux generic pinctrl binding.
> + *
> + * Copyright (C) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
> +#include "pinctrl-mtk-common.h"
> +
> +#define MT7986_TYPE0_PIN(_number, _name) \
> + MTK_TYPED_PIN(_number, _name, DRV_GRP4, IO_TYPE_GRP0)
> +
> +#define MT7986_TYPE1_PIN(_number, _name) \
> + MTK_TYPED_PIN(_number, _name, DRV_GRP4, IO_TYPE_GRP1)
> +
> +#define PIN_FIELD_GPIO(_s_pin, _e_pin, _s_addr, _x_addrs, _s_bit, _x_bits)
> \
> + PIN_FIELD_BASE_CALC(_s_pin, _e_pin, GPIO_BASE, _s_addr, _x_addrs,
> \
> + _s_bit, _x_bits, 32, 0)
> +
> +#define PIN_FIELD_BASE(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,
> \
> +_x_bits)
> \
> + PIN_FIELD_BASE_CALC(_s_pin, _e_pin, _i_base, _s_addr, _x_addrs, _s_bit,
> \
> + _x_bits, 32, 0)
> +
> +/**
> + * enum - Locking variants of the iocfg bases
> + *
> + * MT7986 have multiple bases to program pin configuration listed as the
> below:
> + * iocfg_rt:0x11c3, iocfg_rb:0x11c4, iocfg_lt:0x11e2,
> + * iocfg_lb:0x11e3, iocfg_tr:0x11f0, iocfg_tl:0x11f1,
> + * _i_based could be used to indicate what base the pin should be mapped
> into.
> + *
> + * Each iocfg register base control different group of pads on the SoC
> + *
> + *
> + * chip carrier
> + *
> + * A B C D E F G H
> + *++
> + * 8 | o o o o o o o o |
> + * 7 | o o o o o o o o |
> + * 6 | o o o o o o o o |
> + * 5 | o o o o o o o o |
> + * 4 | o o o o o o o o |
> + * 3 | o o o o o o o o |
> + * 2 | o o o o o o o o |
> + * 1 | o o o o o o o o |
> + *++
> + *
> + * inside Chip carrier
> + *
> + * A B C D E F G H
> + *++
> + * 8 ||
> + * 7 |TL TR |
> + * 6 | +-+ |
> + * 5 | LT | | RT|
> + * 4 | | | |
> + * 3 | LB | | RB|
> + * 2 | +-+ |
> + * 1 ||
> + *++
> + *
> + */
> +
> +enum {
> + GPIO_BASE,
> + IOCFG_RT_BASE,
> + IOCFG_RB_BASE,
> + IOCFG_LT_BASE,
> + IOCFG_LB_BASE,
> + IOCFG_TR_BASE,
> + IOCFG_TL_BASE,
> +};
> +
> +static const char *const mt7986_pinctrl_register_base_names[] = {
> + "gpio", "iocf
Re: [PATCH v2 16/32] spi: add support for MediaTek spi-mem controller
On Wed, Aug 31, 2022 at 07:04:45PM +0800, Weijie Gao wrote: > This patch adds support for spi-mem controller found on newer MediaTek SoCs > This controller supports Single/Dual/Quad SPI mode. Tested on Bananapi BPi-R3 (MT7986A). Tested-by: Daniel Golle > > Reviewed-by: Simon Glass > Signed-off-by: SkyLake.Huang > --- > v2 changes: > Remove unused code > Fix coding style > Add description for struct fields > --- > drivers/spi/Kconfig| 8 + > drivers/spi/Makefile | 1 + > drivers/spi/mtk_spim.c | 701 + > 3 files changed, 710 insertions(+) > create mode 100644 drivers/spi/mtk_spim.c > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > index 75b794548b..7e72ab9c24 100644 > --- a/drivers/spi/Kconfig > +++ b/drivers/spi/Kconfig > @@ -276,6 +276,14 @@ config MTK_SNFI_SPI > used to access SPI memory devices like SPI-NOR or SPI-NAND on > platforms embedding this IP core, like MT7622/M7629. > > +config MTK_SPIM > + bool "Mediatek SPI-MEM master controller driver" > + depends on SPI_MEM > + help > + Enable MediaTek SPI-MEM master controller driver. This driver mainly > + supports SPI flashes. You can use single, dual or quad mode > + transmission on this controller. > + > config MVEBU_A3700_SPI > bool "Marvell Armada 3700 SPI driver" > select CLK_ARMADA_3720 > diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile > index 4de77c260a..309f6b5328 100644 > --- a/drivers/spi/Makefile > +++ b/drivers/spi/Makefile > @@ -43,6 +43,7 @@ obj-$(CONFIG_MPC8XX_SPI) += mpc8xx_spi.o > obj-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o > obj-$(CONFIG_MTK_SNFI_SPI) += mtk_snfi_spi.o > obj-$(CONFIG_MTK_SNOR) += mtk_snor.o > +obj-$(CONFIG_MTK_SPIM) += mtk_spim.o > obj-$(CONFIG_MT7620_SPI) += mt7620_spi.o > obj-$(CONFIG_MT7621_SPI) += mt7621_spi.o > obj-$(CONFIG_MSCC_BB_SPI) += mscc_bb_spi.o > diff --git a/drivers/spi/mtk_spim.c b/drivers/spi/mtk_spim.c > new file mode 100644 > index 00..b45ef529a5 > --- /dev/null > +++ b/drivers/spi/mtk_spim.c > @@ -0,0 +1,701 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * Copyright (C) 2022 MediaTek Inc. All Rights Reserved. > + * > + * Author: SkyLake.Huang > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define SPI_CFG0_REG 0x > +#define SPI_CFG1_REG 0x0004 > +#define SPI_TX_SRC_REG 0x0008 > +#define SPI_RX_DST_REG 0x000c > +#define SPI_TX_DATA_REG 0x0010 > +#define SPI_RX_DATA_REG 0x0014 > +#define SPI_CMD_REG 0x0018 > +#define SPI_IRQ_REG 0x001c > +#define SPI_STATUS_REG 0x0020 > +#define SPI_PAD_SEL_REG 0x0024 > +#define SPI_CFG2_REG 0x0028 > +#define SPI_TX_SRC_REG_640x002c > +#define SPI_RX_DST_REG_640x0030 > +#define SPI_CFG3_IPM_REG 0x0040 > + > +#define SPI_CFG0_SCK_HIGH_OFFSET 0 > +#define SPI_CFG0_SCK_LOW_OFFSET 8 > +#define SPI_CFG0_CS_HOLD_OFFSET 16 > +#define SPI_CFG0_CS_SETUP_OFFSET 24 > +#define SPI_ADJUST_CFG0_CS_HOLD_OFFSET 0 > +#define SPI_ADJUST_CFG0_CS_SETUP_OFFSET 16 > + > +#define SPI_CFG1_CS_IDLE_OFFSET 0 > +#define SPI_CFG1_PACKET_LOOP_OFFSET 8 > +#define SPI_CFG1_PACKET_LENGTH_OFFSET16 > +#define SPI_CFG1_GET_TICKDLY_OFFSET 29 > + > +#define SPI_CFG1_GET_TICKDLY_MASKGENMASK(31, 29) > +#define SPI_CFG1_CS_IDLE_MASK0xff > +#define SPI_CFG1_PACKET_LOOP_MASK0xff00 > +#define SPI_CFG1_PACKET_LENGTH_MASK 0x3ff > +#define SPI_CFG1_IPM_PACKET_LENGTH_MASK GENMASK(31, 16) > +#define SPI_CFG2_SCK_HIGH_OFFSET 0 > +#define SPI_CFG2_SCK_LOW_OFFSET 16 > +#define SPI_CFG2_SCK_HIGH_MASK GENMASK(15, 0) > +#define SPI_CFG2_SCK_LOW_MASKGENMASK(31, 16) > + > +#define SPI_CMD_ACT BIT(0) > +#define SPI_CMD_RESUME BIT(1) > +#define SPI_CMD_RST
Re: [PATCH v2 15/32] watchdog: mediatek: add support for MediaTek MT7986 SoC
On Wed, Aug 31, 2022 at 07:04:42PM +0800, Weijie Gao wrote:
> Add watchdog support for MediaTek MT7986 SoC
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/watchdog/mtk_wdt.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> index b098b2e3cf..368b36849c 100644
> --- a/drivers/watchdog/mtk_wdt.c
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -145,6 +145,7 @@ static const struct wdt_ops mtk_wdt_ops = {
> static const struct udevice_id mtk_wdt_ids[] = {
> { .compatible = "mediatek,wdt"},
> { .compatible = "mediatek,mt6589-wdt"},
> + { .compatible = "mediatek,mt7986-wdt" },
> {}
> };
>
> --
> 2.17.1
>
Re: [PATCH v2 14/32] timer: mtk: add support for MediaTek MT7981/MT7986 SoCs
On Wed, Aug 31, 2022 at 07:04:40PM +0800, Weijie Gao wrote:
> This patch add general-purpose timer support for MediaTek MT7981/MT7986.
> These two SoCs uses a newer version of timer with its register definition
> slightly changed.
>
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/timer/mtk_timer.c | 59 ---
> 1 file changed, 37 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/timer/mtk_timer.c b/drivers/timer/mtk_timer.c
> index f6b97f868c..223e63f6c1 100644
> --- a/drivers/timer/mtk_timer.c
> +++ b/drivers/timer/mtk_timer.c
> @@ -13,24 +13,32 @@
> #include
> #include
>
> -#define MTK_GPT4_CTRL0x40
> -#define MTK_GPT4_CLK 0x44
> -#define MTK_GPT4_CNT 0x48
> +#define MTK_GPT4_OFFSET_V1 0x40
> +#define MTK_GPT4_OFFSET_V2 0x80
>
> -#define GPT4_ENABLE BIT(0)
> -#define GPT4_CLEAR BIT(1)
> -#define GPT4_FREERUN GENMASK(5, 4)
> -#define GPT4_CLK_SYS 0x0
> -#define GPT4_CLK_DIV10x0
> +#define MTK_GPT_CON 0x0
> +#define MTK_GPT_V1_CLK 0x4
> +#define MTK_GPT_CNT 0x8
> +
> +#define GPT_ENABLE BIT(0)
> +#define GPT_CLEARBIT(1)
> +#define GPT_V1_FREERUN GENMASK(5, 4)
> +#define GPT_V2_FREERUN GENMASK(6, 5)
> +
> +enum mtk_gpt_ver {
> + MTK_GPT_V1,
> + MTK_GPT_V2
> +};
>
> struct mtk_timer_priv {
> void __iomem *base;
> + unsigned int gpt4_offset;
> };
>
> static u64 mtk_timer_get_count(struct udevice *dev)
> {
> struct mtk_timer_priv *priv = dev_get_priv(dev);
> - u32 val = readl(priv->base + MTK_GPT4_CNT);
> + u32 val = readl(priv->base + priv->gpt4_offset + MTK_GPT_CNT);
>
> return timer_conv_64(val);
> }
> @@ -40,12 +48,27 @@ static int mtk_timer_probe(struct udevice *dev)
> struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> struct mtk_timer_priv *priv = dev_get_priv(dev);
> struct clk clk, parent;
> - int ret;
> + int ret, gpt_ver;
>
> priv->base = dev_read_addr_ptr(dev);
> + gpt_ver = dev_get_driver_data(dev);
> +
> if (!priv->base)
> return -ENOENT;
>
> + if (gpt_ver == MTK_GPT_V2) {
> + priv->gpt4_offset = MTK_GPT4_OFFSET_V2;
> +
> + writel(GPT_V2_FREERUN | GPT_CLEAR | GPT_ENABLE,
> +priv->base + priv->gpt4_offset + MTK_GPT_CON);
> + } else {
> + priv->gpt4_offset = MTK_GPT4_OFFSET_V1;
> +
> + writel(GPT_V1_FREERUN | GPT_CLEAR | GPT_ENABLE,
> +priv->base + priv->gpt4_offset + MTK_GPT_CON);
> + writel(0, priv->base + priv->gpt4_offset + MTK_GPT_V1_CLK);
> + }
> +
> ret = clk_get_by_index(dev, 0, );
> if (ret)
> return ret;
> @@ -61,16 +84,6 @@ static int mtk_timer_probe(struct udevice *dev)
> if (!uc_priv->clock_rate)
> return -EINVAL;
>
> - /*
> - * Initialize the timer:
> - * 1. set clock source to system clock with clock divider setting to 1
> - * 2. set timer mode to free running
> - * 3. reset timer counter to 0 then enable the timer
> - */
> - writel(GPT4_CLK_SYS | GPT4_CLK_DIV1, priv->base + MTK_GPT4_CLK);
> - writel(GPT4_FREERUN | GPT4_CLEAR | GPT4_ENABLE,
> -priv->base + MTK_GPT4_CTRL);
> -
> return 0;
> }
>
> @@ -79,8 +92,10 @@ static const struct timer_ops mtk_timer_ops = {
> };
>
> static const struct udevice_id mtk_timer_ids[] = {
> - { .compatible = "mediatek,timer" },
> - { .compatible = "mediatek,mt6577-timer" },
> + { .compatible = "mediatek,timer", .data = MTK_GPT_V1 },
> + { .compatible = "mediatek,mt6577-timer", .data = MTK_GPT_V1 },
> + { .compatible = "mediatek,mt7981-timer", .data = MTK_GPT_V2 },
> + { .compatible = "mediatek,mt7986-timer", .data = MTK_GPT_V2 },
> { }
> };
>
> --
> 2.17.1
>
Re: [PATCH v2 11/32] arm: dts: mt7622: force high-speed mode for uart
On Wed, Aug 31, 2022 at 07:04:34PM +0800, Weijie Gao wrote:
> The input clock for uart is too slow (25MHz) which introduces frequent data
> error on both receiving and transmitting even if the baudrate is 115200.
>
> Using high-speed can significantly solve this issue.
Tested on Bananapi BPi-R64 (MT7622).
Fixes unstable console issues previously observed on MT7622 systems.
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> arch/arm/dts/mt7622.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/dts/mt7622.dtsi b/arch/arm/dts/mt7622.dtsi
> index 0127474c95..fb6c1b7154 100644
> --- a/arch/arm/dts/mt7622.dtsi
> +++ b/arch/arm/dts/mt7622.dtsi
> @@ -175,6 +175,7 @@
> status = "disabled";
> assigned-clocks = < CLK_TOP_AXI_SEL>;
> assigned-clock-parents = < CLK_TOP_SYSPLL1_D2>;
> + mediatek,force-highspeed;
> };
>
> mmc0: mmc@1123 {
> --
> 2.17.1
>
Re: [PATCH v2 10/32] serial: mtk: add support for using dynamic baud clock souce
On Wed, Aug 31, 2022 at 07:04:32PM +0800, Weijie Gao wrote:
> The baud clock on some platform may change due to assigned-clock-parent
> set in DT. In current flow the baud clock is only retrieved during probe
> stage. If the parent of the source clock changes after probe stage, the
> setbrg will set wrong baudrate.
>
> To get the right clock rate, this patch records the baud clk struct to the
> driver's priv, and changes the driver's flow to get the clock rate before
> calling _mtk_serial_setbrg().
Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Add description for priv struct
> Fix the type of clk_rate
> ---
> drivers/serial/serial_mtk.c | 80 ++---
> 1 file changed, 47 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/serial/serial_mtk.c b/drivers/serial/serial_mtk.c
> index a84f39b3fa..1d7cc9f7b6 100644
> --- a/drivers/serial/serial_mtk.c
> +++ b/drivers/serial/serial_mtk.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -70,27 +71,37 @@ struct mtk_serial_regs {
> #define BAUD_ALLOW_MAX(baud) ((baud) + (baud) * 3 / 100)
> #define BAUD_ALLOW_MIX(baud) ((baud) - (baud) * 3 / 100)
>
> +/* struct mtk_serial_priv - Structure holding all information used by the
> + * driver
> + * @regs:Register base of the serial port
> + * @clk: The baud clock device
> + * @fixed_clk_rate: Fallback fixed baud clock rate if baud clock
> + * device is not specified
> + * @force_highspeed: Force using high-speed mode
> + */
> struct mtk_serial_priv {
> struct mtk_serial_regs __iomem *regs;
> - u32 clock;
> + struct clk clk;
> + u32 fixed_clk_rate;
> bool force_highspeed;
> };
>
> -static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud)
> +static void _mtk_serial_setbrg(struct mtk_serial_priv *priv, int baud,
> +uint clk_rate)
> {
> u32 quot, realbaud, samplecount = 1;
>
> /* Special case for low baud clock */
> - if (baud <= 115200 && priv->clock <= 1200) {
> + if (baud <= 115200 && clk_rate == 1200) {
> writel(3, >regs->highspeed);
>
> - quot = DIV_ROUND_CLOSEST(priv->clock, 256 * baud);
> + quot = DIV_ROUND_CLOSEST(clk_rate, 256 * baud);
> if (quot == 0)
> quot = 1;
>
> - samplecount = DIV_ROUND_CLOSEST(priv->clock, quot * baud);
> + samplecount = DIV_ROUND_CLOSEST(clk_rate, quot * baud);
>
> - realbaud = priv->clock / samplecount / quot;
> + realbaud = clk_rate / samplecount / quot;
> if (realbaud > BAUD_ALLOW_MAX(baud) ||
> realbaud < BAUD_ALLOW_MIX(baud)) {
> pr_info("baud %d can't be handled\n", baud);
> @@ -104,7 +115,7 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
> *priv, int baud)
>
> if (baud <= 115200) {
> writel(0, >regs->highspeed);
> - quot = DIV_ROUND_CLOSEST(priv->clock, 16 * baud);
> + quot = DIV_ROUND_CLOSEST(clk_rate, 16 * baud);
> } else if (baud <= 576000) {
> writel(2, >regs->highspeed);
>
> @@ -112,13 +123,13 @@ static void _mtk_serial_setbrg(struct mtk_serial_priv
> *priv, int baud)
> if ((baud == 50) || (baud == 576000))
> baud = 460800;
>
> - quot = DIV_ROUND_UP(priv->clock, 4 * baud);
> + quot = DIV_ROUND_UP(clk_rate, 4 * baud);
> } else {
> use_hs3:
> writel(3, >regs->highspeed);
>
> - quot = DIV_ROUND_UP(priv->clock, 256 * baud);
> - samplecount = DIV_ROUND_CLOSEST(priv->clock, quot * baud);
> + quot = DIV_ROUND_UP(clk_rate, 256 * baud);
> + samplecount = DIV_ROUND_CLOSEST(clk_rate, quot * baud);
> }
>
> set_baud:
> @@ -167,8 +178,13 @@ static int _mtk_serial_pending(struct mtk_serial_priv
> *priv, bool input)
> static int mtk_serial_setbrg(struct udevice *dev, int baudrate)
> {
> struct mtk_serial_priv *priv = dev_get_priv(dev);
> + u32 clk_rate;
> +
> + clk_rate = clk_get_rate(>clk);
> + if (IS_ERR_VALUE(clk_rate) || clk_rate == 0)
> + clk
Re: [PATCH v2 09/32] net: mediatek: add support for MediaTek MT7981/MT7986
On Wed, Aug 31, 2022 at 07:04:29PM +0800, Weijie Gao wrote:
> This patch adds support for MediaTek MT7981 and MT7986. Both chips uses
> PDMA v2.
>
Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
> Reviewed-by: Ramon Fried
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/net/mtk_eth.c | 27 +++
> drivers/net/mtk_eth.h | 5 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index fb72baae68..4c9fb266c7 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -115,6 +115,7 @@ struct mtk_eth_priv {
> int force_mode;
> int speed;
> int duplex;
> + bool pn_swap;
>
> struct phy_device *phydev;
> int phy_interface;
> @@ -1057,6 +1058,12 @@ static void mtk_sgmii_init(struct mtk_eth_priv *priv)
> /* SGMII force mode setting */
> writel(SGMII_FORCE_MODE, priv->sgmii_base + SGMSYS_SGMII_MODE);
>
> + /* SGMII PN SWAP setting */
> + if (priv->pn_swap) {
> + setbits_le32(priv->sgmii_base + SGMSYS_QPHY_WRAP_CTRL,
> + SGMII_PN_SWAP_TX_RX);
> + }
> +
> /* Release PHYA power down state */
> clrsetbits_le32(priv->sgmii_base + SGMSYS_QPHY_PWR_STATE_CTRL,
> SGMII_PHYA_PWD, 0);
> @@ -1470,6 +1477,8 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
> dev_err(dev, "Unable to find sgmii\n");
> return -ENODEV;
> }
> +
> + priv->pn_swap = ofnode_read_bool(args.node, "pn_swap");
> }
>
> /* check for switch first, otherwise phy will be used */
> @@ -1520,6 +1529,22 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
> return 0;
> }
>
> +static const struct mtk_soc_data mt7986_data = {
> + .caps = MT7986_CAPS,
> + .ana_rgc3 = 0x128,
> + .pdma_base = PDMA_V2_BASE,
> + .txd_size = sizeof(struct mtk_tx_dma_v2),
> + .rxd_size = sizeof(struct mtk_rx_dma_v2),
> +};
> +
> +static const struct mtk_soc_data mt7981_data = {
> + .caps = MT7986_CAPS,
> + .ana_rgc3 = 0x128,
> + .pdma_base = PDMA_V2_BASE,
> + .txd_size = sizeof(struct mtk_tx_dma_v2),
> + .rxd_size = sizeof(struct mtk_rx_dma_v2),
> +};
> +
> static const struct mtk_soc_data mt7629_data = {
> .ana_rgc3 = 0x128,
> .pdma_base = PDMA_V1_BASE,
> @@ -1549,6 +1574,8 @@ static const struct mtk_soc_data mt7621_data = {
> };
>
> static const struct udevice_id mtk_eth_ids[] = {
> + { .compatible = "mediatek,mt7986-eth", .data = (ulong)_data },
> + { .compatible = "mediatek,mt7981-eth", .data = (ulong)_data },
> { .compatible = "mediatek,mt7629-eth", .data = (ulong)_data },
> { .compatible = "mediatek,mt7623-eth", .data = (ulong)_data },
> { .compatible = "mediatek,mt7622-eth", .data = (ulong)_data },
> diff --git a/drivers/net/mtk_eth.h b/drivers/net/mtk_eth.h
> index 236c498a1b..1382ccbeb2 100644
> --- a/drivers/net/mtk_eth.h
> +++ b/drivers/net/mtk_eth.h
> @@ -36,6 +36,8 @@ enum mkt_eth_capabilities {
>
> #define MT7623_CAPS (MTK_GMAC1_TRGMII)
>
> +#define MT7986_CAPS (MTK_NETSYS_V2)
> +
> /* Frame Engine Register Bases */
> #define PDMA_V1_BASE 0x0800
> #define PDMA_V2_BASE 0x6000
> @@ -72,6 +74,9 @@ enum mkt_eth_capabilities {
> #define SGMSYS_QPHY_PWR_STATE_CTRL 0xe8
> #define SGMII_PHYA_PWD BIT(4)
>
> +#define SGMSYS_QPHY_WRAP_CTRL0xec
> +#define SGMII_PN_SWAP_TX_RX 0x03
> +
> #define SGMSYS_GEN2_SPEED0x2028
> #define SGMSYS_GEN2_SPEED_V2 0x128
> #define SGMSYS_SPEED_2500BIT(2)
> --
> 2.17.1
>
Re: [PATCH v2 08/32] net: mediatek: add support for PDMA v2
On Wed, Aug 31, 2022 at 07:04:27PM +0800, Weijie Gao wrote:
> This patch adds support for PDMA v2 hardware. The PDMA v2 has extended the
> DMA descriptor to 8-words, and some of its fields have changed comparing
> to the v1 hardware.
Tested on Bananapi BPi-R2 (MT7623), Bananapi BPi-R64 (MT7623) and
Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
>
> Reviewed-by: Ramon Fried
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Add description for new fields
> ---
> drivers/net/mtk_eth.c | 54 ---
> drivers/net/mtk_eth.h | 53 +++---
> 2 files changed, 86 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index e3738b9277..fb72baae68 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -76,10 +76,14 @@ enum mtk_switch {
> * @caps Flags shown the extra capability for the SoC
> * @ana_rgc3:The offset for register ANA_RGC3
> related to
> * sgmiisys syscon
> + * @pdma_base: Register base of PDMA block
> + * @txd_size:Tx DMA descriptor size.
> + * @rxd_size:Rx DMA descriptor size.
> */
> struct mtk_soc_data {
> u32 caps;
> u32 ana_rgc3;
> + u32 pdma_base;
> u32 txd_size;
> u32 rxd_size;
> };
> @@ -130,13 +134,13 @@ struct mtk_eth_priv {
>
> static void mtk_pdma_write(struct mtk_eth_priv *priv, u32 reg, u32 val)
> {
> - writel(val, priv->fe_base + PDMA_BASE + reg);
> + writel(val, priv->fe_base + priv->soc->pdma_base + reg);
> }
>
> static void mtk_pdma_rmw(struct mtk_eth_priv *priv, u32 reg, u32 clr,
>u32 set)
> {
> - clrsetbits_le32(priv->fe_base + PDMA_BASE + reg, clr, set);
> + clrsetbits_le32(priv->fe_base + priv->soc->pdma_base + reg, clr, set);
> }
>
> static void mtk_gdma_write(struct mtk_eth_priv *priv, int no, u32 reg,
> @@ -1133,8 +1137,8 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
> static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
> {
> char *pkt_base = priv->pkt_pool;
> - struct mtk_tx_dma *txd;
> - struct mtk_rx_dma *rxd;
> + struct mtk_tx_dma_v2 *txd;
> + struct mtk_rx_dma_v2 *rxd;
> int i;
>
> mtk_pdma_rmw(priv, PDMA_GLO_CFG_REG, 0x, 0);
> @@ -1155,7 +1159,11 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv
> *priv)
>
> txd->txd1 = virt_to_phys(pkt_base);
> txd->txd2 = PDMA_TXD2_DDONE | PDMA_TXD2_LS0;
> - txd->txd4 = PDMA_TXD4_FPORT_SET(priv->gmac_id + 1);
> +
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + txd->txd5 = PDMA_V2_TXD5_FPORT_SET(priv->gmac_id + 1);
> + else
> + txd->txd4 = PDMA_V1_TXD4_FPORT_SET(priv->gmac_id + 1);
>
> pkt_base += PKTSIZE_ALIGN;
> }
> @@ -1164,7 +1172,11 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv
> *priv)
> rxd = priv->rx_ring_noc + i * priv->soc->rxd_size;
>
> rxd->rxd1 = virt_to_phys(pkt_base);
> - rxd->rxd2 = PDMA_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
> +
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + rxd->rxd2 = PDMA_V2_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
> + else
> + rxd->rxd2 = PDMA_V1_RXD2_PLEN0_SET(PKTSIZE_ALIGN);
>
> pkt_base += PKTSIZE_ALIGN;
> }
> @@ -1193,6 +1205,9 @@ static int mtk_eth_start(struct udevice *dev)
> reset_deassert(>rst_fe);
> mdelay(10);
>
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_NETSYS_V2))
> + setbits_le32(priv->fe_base + FE_GLO_MISC_REG, PDMA_VER_V2);
> +
> /* Packets forward to PDMA */
> mtk_gdma_write(priv, priv->gmac_id, GDMA_IG_CTRL_REG, GDMA_FWD_TO_CPU);
>
> @@ -1227,7 +1242,7 @@ static void mtk_eth_stop(struct udevice *dev)
>TX_WB_DDONE | RX_DMA_EN | TX_DMA_EN, 0);
> udelay(500);
>
> - wait_for_bit_le32(priv->fe_base + PDMA_BASE + PDMA_GLO_CFG_REG,
> + wait_for_bit_le32(priv->fe_base + priv->soc->pdma_base +
> PDMA_GLO_CFG_REG,
> RX_DMA_BUSY | TX_DMA_BUSY, 0, 5000, 0);
> }
>
> @@ -1252,7 +1267,7 @@ static int mtk_eth_send(struct udevice *dev, void
> *packet, int length)
> {
> struct mtk_eth_priv *priv = dev_get_priv(dev);
>
Re: [PATCH v2 07/32] net: mediatek: stop using bitfileds for DMA descriptors
On Wed, Aug 31, 2022 at 07:04:23PM +0800, Weijie Gao wrote:
> This patch is a preparation for adding a new version of PDMA of which the
> DMA descriptor fields has changed. Using bitfields will result in a complex
> modification. Convert bitfields to u32 units can solve this problem easily.
Tested on Bananapi BPi-R64 (MT7622) and BPi-R2 (MT7623).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes:
> Fix typo in commit message
> ---
> drivers/net/mtk_eth.c | 144 ++
> drivers/net/mtk_eth.h | 32 ++
> 2 files changed, 80 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index ce4aa6e065..e3738b9277 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -65,77 +65,6 @@
> (DP_DISCARD << MC_DP_S) | \
> (DP_DISCARD << UN_DP_S))
>
> -struct pdma_rxd_info1 {
> - u32 PDP0;
> -};
> -
> -struct pdma_rxd_info2 {
> - u32 PLEN1 : 14;
> - u32 LS1 : 1;
> - u32 UN_USED : 1;
> - u32 PLEN0 : 14;
> - u32 LS0 : 1;
> - u32 DDONE : 1;
> -};
> -
> -struct pdma_rxd_info3 {
> - u32 PDP1;
> -};
> -
> -struct pdma_rxd_info4 {
> - u32 FOE_ENTRY : 14;
> - u32 CRSN : 5;
> - u32 SP : 3;
> - u32 L4F : 1;
> - u32 L4VLD : 1;
> - u32 TACK : 1;
> - u32 IP4F : 1;
> - u32 IP4 : 1;
> - u32 IP6 : 1;
> - u32 UN_USED : 4;
> -};
> -
> -struct pdma_rxdesc {
> - struct pdma_rxd_info1 rxd_info1;
> - struct pdma_rxd_info2 rxd_info2;
> - struct pdma_rxd_info3 rxd_info3;
> - struct pdma_rxd_info4 rxd_info4;
> -};
> -
> -struct pdma_txd_info1 {
> - u32 SDP0;
> -};
> -
> -struct pdma_txd_info2 {
> - u32 SDL1 : 14;
> - u32 LS1 : 1;
> - u32 BURST : 1;
> - u32 SDL0 : 14;
> - u32 LS0 : 1;
> - u32 DDONE : 1;
> -};
> -
> -struct pdma_txd_info3 {
> - u32 SDP1;
> -};
> -
> -struct pdma_txd_info4 {
> - u32 VLAN_TAG : 16;
> - u32 INS : 1;
> - u32 RESV : 2;
> - u32 UDF : 6;
> - u32 FPORT : 3;
> - u32 TSO : 1;
> - u32 TUI_CO : 3;
> -};
> -
> -struct pdma_txdesc {
> - struct pdma_txd_info1 txd_info1;
> - struct pdma_txd_info2 txd_info2;
> - struct pdma_txd_info3 txd_info3;
> - struct pdma_txd_info4 txd_info4;
> -};
> -
> enum mtk_switch {
> SW_NONE,
> SW_MT7530,
> @@ -151,13 +80,15 @@ enum mtk_switch {
> struct mtk_soc_data {
> u32 caps;
> u32 ana_rgc3;
> + u32 txd_size;
> + u32 rxd_size;
> };
>
> struct mtk_eth_priv {
> char pkt_pool[TOTAL_PKT_BUF_SIZE] __aligned(ARCH_DMA_MINALIGN);
>
> - struct pdma_txdesc *tx_ring_noc;
> - struct pdma_rxdesc *rx_ring_noc;
> + void *tx_ring_noc;
> + void *rx_ring_noc;
>
> int rx_dma_owner_idx0;
> int tx_cpu_owner_idx0;
> @@ -1202,14 +1133,16 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
> static void mtk_eth_fifo_init(struct mtk_eth_priv *priv)
> {
> char *pkt_base = priv->pkt_pool;
> + struct mtk_tx_dma *txd;
> + struct mtk_rx_dma *rxd;
> int i;
>
> mtk_pdma_rmw(priv, PDMA_GLO_CFG_REG, 0x, 0);
> udelay(500);
>
> - memset(priv->tx_ring_noc, 0, NUM_TX_DESC * sizeof(struct pdma_txdesc));
> - memset(priv->rx_ring_noc, 0, NUM_RX_DESC * sizeof(struct pdma_rxdesc));
> - memset(priv->pkt_pool, 0, TOTAL_PKT_BUF_SIZE);
> + memset(priv->tx_ring_noc, 0, NUM_TX_DESC * priv->soc->txd_size);
> + memset(priv->rx_ring_noc, 0, NUM_RX_DESC * priv->soc->rxd_size);
> + memset(priv->pkt_pool, 0xff, TOTAL_PKT_BUF_SIZE);
>
> flush_dcache_range((ulong)pkt_base,
> (ulong)(pkt_base + TOTAL_PKT_BUF_SIZE));
> @@ -1218,17 +1151,21 @@ static void mtk_eth_fifo_init(struct mtk_eth_priv
> *priv)
> priv->tx_cpu_owner_idx0 = 0;
>
> for (i = 0; i < NUM_TX_DESC; i++) {
> - priv->tx_ring_noc[i].txd_info2.LS0 = 1;
> - priv->tx_ring_noc[i].txd_info2.DDONE = 1;
> - priv->tx_ring_noc[i].txd_info4.FPORT = priv->gmac_id + 1;
> + txd = priv->tx_ring_noc + i * priv->soc->txd_size;
> +
> + txd->txd1 = virt_to_phys(pkt_base);
> + txd->txd2 = PDMA_TXD2_DDONE | PDMA_TXD2_LS0;
> + txd->txd4 = PDMA_TXD4_FPORT_SET(priv->gmac_id + 1);
>
> - priv->tx_ring_noc[i].txd_info1.SDP0 = virt_to_phys(pkt_base);
>
Re: [PATCH v2 06/32] net: mediatek: use a struct to cover variations of all SoCs
On Wed, Aug 31, 2022 at 07:04:19PM +0800, Weijie Gao wrote:
> Using a single soc id to control different initialization and TX/RX flow
> for all SoCs is not extensible if more hardware variations are added in
> the future.
>
> This patch introduces a struct to replace the original mtk_soc to allow
> the driver be able handle newer hardwares.
Tested on Bananapi BPi-R64 (MT7622) and Bananapi BPi-R2 (MT7623).
Tested-by: Daniel Golle
>
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2c changes:
> Add description for new struct
> ---
> drivers/net/mtk_eth.c | 56 ++-
> drivers/net/mtk_eth.h | 25 ++-
> 2 files changed, 64 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/net/mtk_eth.c b/drivers/net/mtk_eth.c
> index 4fe7ee0d36..ce4aa6e065 100644
> --- a/drivers/net/mtk_eth.c
> +++ b/drivers/net/mtk_eth.c
> @@ -142,11 +142,15 @@ enum mtk_switch {
> SW_MT7531
> };
>
> -enum mtk_soc {
> - SOC_MT7623,
> - SOC_MT7629,
> - SOC_MT7622,
> - SOC_MT7621
> +/* struct mtk_soc_data - This is the structure holding all differences
> + * among various plaforms
> + * @caps Flags shown the extra capability for the SoC
> + * @ana_rgc3:The offset for register ANA_RGC3
> related to
> + * sgmiisys syscon
> + */
> +struct mtk_soc_data {
> + u32 caps;
> + u32 ana_rgc3;
> };
>
> struct mtk_eth_priv {
> @@ -171,7 +175,7 @@ struct mtk_eth_priv {
> int (*mmd_write)(struct mtk_eth_priv *priv, u8 addr, u8 devad, u16 reg,
>u16 val);
>
> - enum mtk_soc soc;
> + const struct mtk_soc_data *soc;
> int gmac_id;
> int force_mode;
> int speed;
> @@ -679,7 +683,7 @@ static int mt7530_setup(struct mtk_eth_priv *priv)
> u32 val, txdrv;
> int i;
>
> - if (priv->soc != SOC_MT7621) {
> + if (!MTK_HAS_CAPS(priv->soc->caps, MTK_TRGMII_MT7621_CLK)) {
> /* Select 250MHz clk for RGMII mode */
> mtk_ethsys_rmw(priv, ETHSYS_CLKCFG0_REG,
> ETHSYS_TRGMII_CLK_SEL362_5, 0);
> @@ -1108,9 +1112,8 @@ static int mtk_phy_probe(struct udevice *dev)
> static void mtk_sgmii_init(struct mtk_eth_priv *priv)
> {
> /* Set SGMII GEN2 speed(2.5G) */
> - clrsetbits_le32(priv->sgmii_base + ((priv->soc == SOC_MT7622) ?
> - SGMSYS_GEN2_SPEED : SGMSYS_GEN2_SPEED_V2),
> - SGMSYS_SPEED_2500, SGMSYS_SPEED_2500);
> + setbits_le32(priv->sgmii_base + priv->soc->ana_rgc3,
> + SGMSYS_SPEED_2500);
>
> /* Disable SGMII AN */
> clrsetbits_le32(priv->sgmii_base + SGMSYS_PCS_CONTROL_1,
> @@ -1182,7 +1185,8 @@ static void mtk_mac_init(struct mtk_eth_priv *priv)
> mtk_gmac_write(priv, GMAC_PORT_MCR(priv->gmac_id), mcr);
> }
>
> - if (priv->soc == SOC_MT7623) {
> + if (MTK_HAS_CAPS(priv->soc->caps, MTK_GMAC1_TRGMII) &&
> + !MTK_HAS_CAPS(priv->soc->caps, MTK_TRGMII_MT7621_CLK)) {
> /* Lower Tx Driving for TRGMII path */
> for (i = 0 ; i < NUM_TRGMII_CTRL; i++)
> mtk_gmac_write(priv, GMAC_TRGMII_TD_ODT(i),
> @@ -1431,7 +1435,11 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
> ofnode subnode;
> int ret;
>
> - priv->soc = dev_get_driver_data(dev);
> + priv->soc = (const struct mtk_soc_data *)dev_get_driver_data(dev);
> + if (!priv->soc) {
> + dev_err(dev, "missing soc compatible data\n");
> + return -EINVAL;
> + }
>
> pdata->iobase = (phys_addr_t)dev_remap_addr(dev);
>
> @@ -1544,11 +1552,27 @@ static int mtk_eth_of_to_plat(struct udevice *dev)
> return 0;
> }
>
> +static const struct mtk_soc_data mt7629_data = {
> + .ana_rgc3 = 0x128,
> +};
> +
> +static const struct mtk_soc_data mt7623_data = {
> + .caps = MT7623_CAPS,
> +};
> +
> +static const struct mtk_soc_data mt7622_data = {
> + .ana_rgc3 = 0x2028,
> +};
> +
> +static const struct mtk_soc_data mt7621_data = {
> + .caps = MT7621_CAPS,
> +};
> +
> static const struct udevice_id mtk_eth_ids[] = {
> - { .compatible = "mediatek,mt7629-eth", .data = SOC_MT7629 },
> - { .compatible = "mediatek,mt7623-eth", .data = SOC_MT7623 },
> - { .compatible = "mediatek,mt7622-eth", .data = SOC_MT7622 },
> - { .compatible = "mediatek,mt7621-eth", .dat
Re: [PATCH v2 05/32] mmc: mediatek: add support for MediaTek MT7891/MT7986 SoCs
On Wed, Aug 31, 2022 at 07:04:12PM +0800, Weijie Gao wrote:
> Add eMMC and SDXC support for MediaTek MT7981/MT7986 SoCs
> Both chips support SDXC and eMMC 4.5. MT7986A supports eMMC 5.1.
>
Tested on Bananapi BPi-R3 (MT7986A) with both eMMC and SDMMC.
Tested-by: Daniel Golle
> Reviewed-by: Jaehoon Chung
> Reviewed-by: Simon Glass
> Signed-off-by: Weijie Gao
> ---
> v2 changes: none
> ---
> drivers/mmc/mtk-sd.c | 68 ++--
> 1 file changed, 53 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c
> index e61e8cf4b9..b206b0a085 100644
> --- a/drivers/mmc/mtk-sd.c
> +++ b/drivers/mmc/mtk-sd.c
> @@ -1496,7 +1496,12 @@ static void msdc_init_hw(struct msdc_host *host)
> /* Enable data & cmd interrupts */
> writel(DATA_INTS_MASK | CMD_INTS_MASK, >base->msdc_inten);
>
> - writel(0, tune_reg);
> + if (host->top_base) {
> + writel(0, >top_base->emmc_top_control);
> + writel(0, >top_base->emmc_top_cmd);
> + } else {
> + writel(0, tune_reg);
> + }
> writel(0, >base->msdc_iocon);
>
> if (host->r_smpl)
> @@ -1507,9 +1512,14 @@ static void msdc_init_hw(struct msdc_host *host)
> writel(0x403c0046, >base->patch_bit0);
> writel(0x4089, >base->patch_bit1);
>
> - if (host->dev_comp->stop_clk_fix)
> + if (host->dev_comp->stop_clk_fix) {
> clrsetbits_le32(>base->patch_bit1, MSDC_PB1_STOP_DLY_M,
> 3 << MSDC_PB1_STOP_DLY_S);
> + clrbits_le32(>base->sdc_fifo_cfg,
> + SDC_FIFO_CFG_WRVALIDSEL);
> + clrbits_le32(>base->sdc_fifo_cfg,
> + SDC_FIFO_CFG_RDVALIDSEL);
> + }
>
> if (host->dev_comp->busy_check)
> clrbits_le32(>base->patch_bit1, (1 << 7));
> @@ -1544,15 +1554,28 @@ static void msdc_init_hw(struct msdc_host *host)
> }
>
> if (host->dev_comp->data_tune) {
> - setbits_le32(tune_reg,
> - MSDC_PAD_TUNE_RD_SEL | MSDC_PAD_TUNE_CMD_SEL);
> - clrsetbits_le32(>base->patch_bit0,
> - MSDC_INT_DAT_LATCH_CK_SEL_M,
> - host->latch_ck <<
> - MSDC_INT_DAT_LATCH_CK_SEL_S);
> + if (host->top_base) {
> + setbits_le32(>top_base->emmc_top_control,
> + PAD_DAT_RD_RXDLY_SEL);
> + clrbits_le32(>top_base->emmc_top_control,
> + DATA_K_VALUE_SEL);
> + setbits_le32(>top_base->emmc_top_cmd,
> + PAD_CMD_RD_RXDLY_SEL);
> + } else {
> + setbits_le32(tune_reg,
> + MSDC_PAD_TUNE_RD_SEL |
> MSDC_PAD_TUNE_CMD_SEL);
> + clrsetbits_le32(>base->patch_bit0,
> + MSDC_INT_DAT_LATCH_CK_SEL_M,
> + host->latch_ck <<
> + MSDC_INT_DAT_LATCH_CK_SEL_S);
> + }
> } else {
> /* choose clock tune */
> - setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
> + if (host->top_base)
> + setbits_le32(>top_base->emmc_top_control,
> + PAD_RXDLY_SEL);
> + else
> + setbits_le32(tune_reg, MSDC_PAD_TUNE_RXDLYSEL);
> }
>
> if (host->dev_comp->builtin_pad_ctrl) {
> @@ -1604,12 +1627,6 @@ static void msdc_init_hw(struct msdc_host *host)
> clrsetbits_le32(>base->sdc_cfg, SDC_CFG_DTOC_M,
> 3 << SDC_CFG_DTOC_S);
>
> - if (host->dev_comp->stop_clk_fix) {
> - clrbits_le32(>base->sdc_fifo_cfg,
> - SDC_FIFO_CFG_WRVALIDSEL);
> - clrbits_le32(>base->sdc_fifo_cfg,
> - SDC_FIFO_CFG_RDVALIDSEL);
> - }
>
> host->def_tune_para.iocon = readl(>base->msdc_iocon);
> host->def_tune_para.pad_tune = readl(>base->pad_tune);
> @@ -1792,6 +1809,25 @@ static const struct msdc_compatible mt7623_compat = {
> .enhance_rx = false
> };
>
> +static const struct msdc_compatible mt7986_compat = {
> + .clk_div_bits = 12,
> + .pad_tune0 = true,
> + .async_fifo = true,
&
Re: [PATCH v2 01/32] arm: mediatek: add support for MediaTek MT7986 SoC
On Wed, Aug 31, 2022 at 07:00:17PM +0800, Weijie Gao wrote:
> This patch adds basic support for MediaTek MT7986 SoC.
> This include the file that will initialize the SoC after boot and its
> device tree.
>
> Signed-off-by: Weijie Gao
Tested on Bananapi BPi-R3 (MT7986A).
Tested-by: Daniel Golle
> ---
> v2 changes:
> Sort include lines
> Add reference link for armv8_el2_to_aarch32 in lowlevel_init.S
> Remove print_cpuinfo and use cpu driver instead
> ---
> arch/arm/dts/mt7986-u-boot.dtsi | 33 ++
> arch/arm/dts/mt7986.dtsi | 346 ++
> arch/arm/mach-mediatek/Kconfig| 12 +
> arch/arm/mach-mediatek/Makefile | 1 +
> arch/arm/mach-mediatek/mt7986/Makefile| 4 +
> arch/arm/mach-mediatek/mt7986/init.c | 45 +++
> arch/arm/mach-mediatek/mt7986/lowlevel_init.S | 32 ++
> 7 files changed, 473 insertions(+)
> create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
> create mode 100644 arch/arm/dts/mt7986.dtsi
> create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
> create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
> create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
>
> diff --git a/arch/arm/dts/mt7986-u-boot.dtsi b/arch/arm/dts/mt7986-u-boot.dtsi
> new file mode 100644
> index 00..95671f8afa
> --- /dev/null
> +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> new file mode 100644
> index 00..25b81ab7e1
> --- /dev/null
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -0,0 +1,346 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "mediatek,mt7986";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + config {
> + u-boot,mmc-env-partition = "u-boot-env";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + };
> +
> + dummy_clk: dummy12m {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + #clock-cells = <0>;
> + /* must need this line, or uart uanable to get dummy_clk */
> + u-boot,dm-pre-reloc;
> + };
> +
> + hwver: hwver {
> + compatible = "mediatek,hwver";
> + reg = <0x800 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <>;
> + clock-frequency = <1300>;
> + interrupts = ,
> + ,
> + ,
> + ;
> + arm,cpu-registers-not-fw-configured;
> + };
> +
> + timer0: timer@10008000 {
> + compatible = "mediatek,mt7986-timer";
> + reg = <0x10008000 0x1000>;
> + interrupts = ;
> + clocks = < CK_INFRA_CK_F26M>;
> +
Re: [PATCH v4 1/2] bootm: fix typo imape_comp -> image_comp
On Mon, Aug 29, 2022 at 08:30:14PM -0600, Simon Glass wrote: > On Fri, 26 Aug 2022 at 21:15, Daniel Golle wrote: > > > > Chage variable name 'imape_comp' to the supposedly intended name > > Change Can you fix that on-the-fly while comitting or should I repost with that typo in the patch description fixed? > > > 'image_comp'. > > > > Signed-off-by: Daniel Golle > > --- > > v4: add missing name replacement > > > > boot/bootm.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > Reviewed-by: Simon Glass
[PATCH v4 2/2] image-fit: don't set compression if it can't be read
fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.
As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its
file!
no longer shows if the compression node is actually absent.
Signed-off-by: Daniel Golle
---
v2: fix typo 'imape_comp' vs. 'image_comp'
v3: rather fix the typo everywhere in an additional patch before
v4: rebase on updated patch fixing typo
boot/bootm.c | 6 ++
boot/image-fit.c | 3 +--
cmd/ximg.c | 7 ++-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 63c79a9cfc..29c067fae7 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
return -EINVAL;
}
- if (fit_image_get_comp(fit, noffset, _comp)) {
- puts("Can't get image compression!\n");
- return -EINVAL;
- }
+ if (fit_image_get_comp(fit, noffset, _comp))
+ image_comp = IH_COMP_NONE;
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
void fit_image_print(const void *fit, int image_noffset, const char *p)
{
char *desc;
- uint8_t type, arch, os, comp;
+ uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset,
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
- *comp = -1;
return -1;
}
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return 1;
}
- if (fit_image_get_comp(fit_hdr, noffset, )) {
- puts("Could not find script subimage "
- "compression type\n");
- return 1;
- }
+ if (fit_image_get_comp(fit_hdr, noffset, ))
+ comp = IH_COMP_NONE;
data = (ulong)fit_data;
len = (ulong)fit_len;
--
2.37.2
[PATCH v4 1/2] bootm: fix typo imape_comp -> image_comp
Chage variable name 'imape_comp' to the supposedly intended name
'image_comp'.
Signed-off-by: Daniel Golle
---
v4: add missing name replacement
boot/bootm.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..63c79a9cfc 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1006,7 +1006,7 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
int noffset;
ulong load_end, buf_size;
uint8_t image_type;
- uint8_t imape_comp;
+ uint8_t image_comp;
void *load_buf;
int ret;
@@ -1024,7 +1024,7 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
return -EINVAL;
}
- if (fit_image_get_comp(fit, noffset, _comp)) {
+ if (fit_image_get_comp(fit, noffset, _comp)) {
puts("Can't get image compression!\n");
return -EINVAL;
}
@@ -1032,12 +1032,12 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
load_buf = malloc(buf_size);
- ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
+ ret = image_decomp(image_comp, 0, data, image_type, load_buf,
(void *)data, len, buf_size, _end);
free(load_buf);
if (ret) {
- ret = handle_decomp_error(imape_comp, load_end - 0, buf_size,
ret);
+ ret = handle_decomp_error(image_comp, load_end - 0, buf_size,
ret);
if (ret != BOOTM_ERR_UNIMPLEMENTED)
return ret;
}
--
2.37.2
[PATCH v3 2/2] image-fit: don't set compression if it can't be read
fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.
As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its
file!
no longer shows if the compression node is actually absent.
Signed-off-by: Daniel Golle
---
boot/bootm.c | 6 ++
boot/image-fit.c | 3 +--
cmd/ximg.c | 7 ++-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 4de573e24e..29c067fae7 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
return -EINVAL;
}
- if (fit_image_get_comp(fit, noffset, _comp)) {
- puts("Can't get image compression!\n");
- return -EINVAL;
- }
+ if (fit_image_get_comp(fit, noffset, _comp))
+ image_comp = IH_COMP_NONE;
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
void fit_image_print(const void *fit, int image_noffset, const char *p)
{
char *desc;
- uint8_t type, arch, os, comp;
+ uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset,
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
- *comp = -1;
return -1;
}
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return 1;
}
- if (fit_image_get_comp(fit_hdr, noffset, )) {
- puts("Could not find script subimage "
- "compression type\n");
- return 1;
- }
+ if (fit_image_get_comp(fit_hdr, noffset, ))
+ comp = IH_COMP_NONE;
data = (ulong)fit_data;
len = (ulong)fit_len;
--
2.37.2
[PATCH v3 1/2] bootm: fix typo imape_comp -> image_comp
Chage variable name 'imape_comp' to the supposedly intended name
'image_comp'.
Signed-off-by: Daniel Golle
---
boot/bootm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..4de573e24e 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1006,7 +1006,7 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
int noffset;
ulong load_end, buf_size;
uint8_t image_type;
- uint8_t imape_comp;
+ uint8_t image_comp;
void *load_buf;
int ret;
@@ -1032,12 +1032,12 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
load_buf = malloc(buf_size);
- ret = image_decomp(imape_comp, 0, data, image_type, load_buf,
+ ret = image_decomp(image_comp, 0, data, image_type, load_buf,
(void *)data, len, buf_size, _end);
free(load_buf);
if (ret) {
- ret = handle_decomp_error(imape_comp, load_end - 0, buf_size,
ret);
+ ret = handle_decomp_error(image_comp, load_end - 0, buf_size,
ret);
if (ret != BOOTM_ERR_UNIMPLEMENTED)
return ret;
}
--
2.37.2
[PATCH v2] image-fit: don't set compression if it can't be read
fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.
As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its
file!
no longer shows if the compression node is actually absent.
Signed-off-by: Daniel Golle
---
v2: fix typo 'imape_comp' vs. 'image_comp'
boot/bootm.c | 6 ++
boot/image-fit.c | 3 +--
cmd/ximg.c | 7 ++-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..fcdf23f19c 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
return -EINVAL;
}
- if (fit_image_get_comp(fit, noffset, _comp)) {
- puts("Can't get image compression!\n");
- return -EINVAL;
- }
+ if (fit_image_get_comp(fit, noffset, _comp))
+ imape_comp = IH_COMP_NONE;
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
void fit_image_print(const void *fit, int image_noffset, const char *p)
{
char *desc;
- uint8_t type, arch, os, comp;
+ uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset,
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
- *comp = -1;
return -1;
}
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return 1;
}
- if (fit_image_get_comp(fit_hdr, noffset, )) {
- puts("Could not find script subimage "
- "compression type\n");
- return 1;
- }
+ if (fit_image_get_comp(fit_hdr, noffset, ))
+ comp = IH_COMP_NONE;
data = (ulong)fit_data;
len = (ulong)fit_len;
--
2.37.2
[PATCH] image-fit: don't set compression if it can't be read
fit_image_get_comp() should not set value -1 in case it can't read
the compression node. Instead, leave the value untouched in that case
as it can be absent and a default value previously defined by the
caller of fit_image_get_comp() should be used.
As a result the warning message
WARNING: 'compression' nodes for ramdisks are deprecated, please fix your .its
file!
no longer shows if the compression node is actually absent.
Signed-off-by: Daniel Golle
---
boot/bootm.c | 6 ++
boot/image-fit.c | 3 +--
cmd/ximg.c | 7 ++-
3 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/boot/bootm.c b/boot/bootm.c
index 86dbfbcfed..b659825305 100644
--- a/boot/bootm.c
+++ b/boot/bootm.c
@@ -1024,10 +1024,8 @@ static int bootm_host_load_image(const void *fit, int
req_image_type,
return -EINVAL;
}
- if (fit_image_get_comp(fit, noffset, _comp)) {
- puts("Can't get image compression!\n");
- return -EINVAL;
- }
+ if (fit_image_get_comp(fit, noffset, _comp))
+ image_comp = IH_COMP_NONE;
/* Allow the image to expand by a factor of 4, should be safe */
buf_size = (1 << 20) + len * 4;
diff --git a/boot/image-fit.c b/boot/image-fit.c
index df3e5df883..21dbd05118 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -477,7 +477,7 @@ void fit_print_contents(const void *fit)
void fit_image_print(const void *fit, int image_noffset, const char *p)
{
char *desc;
- uint8_t type, arch, os, comp;
+ uint8_t type, arch, os, comp = IH_COMP_NONE;
size_t size;
ulong load, entry;
const void *data;
@@ -794,7 +794,6 @@ int fit_image_get_comp(const void *fit, int noffset,
uint8_t *comp)
data = fdt_getprop(fit, noffset, FIT_COMP_PROP, );
if (data == NULL) {
fit_get_debug(fit, noffset, FIT_COMP_PROP, len);
- *comp = -1;
return -1;
}
diff --git a/cmd/ximg.c b/cmd/ximg.c
index 65ba41320a..f84141ff45 100644
--- a/cmd/ximg.c
+++ b/cmd/ximg.c
@@ -171,11 +171,8 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc,
char *const argv[])
return 1;
}
- if (fit_image_get_comp(fit_hdr, noffset, )) {
- puts("Could not find script subimage "
- "compression type\n");
- return 1;
- }
+ if (fit_image_get_comp(fit_hdr, noffset, ))
+ comp = IH_COMP_NONE;
data = (ulong)fit_data;
len = (ulong)fit_len;
--
2.37.1
Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards
On Fri, Aug 12, 2022 at 07:02:17PM +0800, Weijie Gao wrote:
> On Tue, 2022-08-09 at 11:10 +0200, Daniel Golle wrote:
> > Hi Weijie,
> >
> > On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote:
> > > This patch adds general board files based on MT7986 SoCs.
> > >
> > > The SD/eMMC controller on MT7986A and MT7986B have different pin
> > > configurations so that four different reference board configs has
> > > to be
> > > added.
> > >
> > > Signed-off-by: Weijie Gao
> > > ---
> > > [...]
> > > diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h
> > > new file mode 100644
> > > index 00..b28fc0f613
> > > --- /dev/null
> > > +++ b/include/configs/mt7986.h
> > > @@ -0,0 +1,26 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > +/*
> > > + * Configuration for MediaTek MT7986 SoC
> > > + *
> > > + * Copyright (C) 2022 MediaTek Inc.
> > > + * Author: Sam Shih
> > > + */
> > > +
> > > +#ifndef __MT7986_H
> > > +#define __MT7986_H
> > > +
> > > +#include
> > > +
> >
> > In the SDK sources I found also
> > #define CONFIG_SYS_BOOTM_LEN SZ_128M
> > here which is actually needed to boot any image with uncompressed
> > kernel larger than 8MiB. As for ARM64 this size is easily exceeded
> > and
> > we got plenty of RAM, I suggest to also include a more generous
> > CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot.
>
> CONFIG_SYS_BOOTM_LEN is now a Kconfig symbol. It will no be defined in
> this header.
> Instead, the default value of this symbol is 0x400 (64M) for ARM64
> which is enough for an ARM64 kernel.
Sorry, I missed c45568cc4e ("Convert CONFIG_SYS_BOOTM_LEN to Kconfig")
and was trying the series on top of U-Boot 2022.07 (for inclusion in
OpenWrt) locally.
I've tested the whole series with Bananapi BPi-R3 (MT7986A) board.
U-Boot itself works great with all 4 boot media options.
The only remaining problem is BootROM header generation using
mkimage/mtk_image for SPI-NOR:
TF-A and U-Boot ithemselves both work well with SPI-NOR when using
'bromutil' to generate the image. When using 'mkimage -T mtk_image'
instead of 'bromutil' the resulting bl2.img doesn't work:
F0: 102B
FA:
V0: 7027 6006 [0001]
00: 1017
FA: 5100
01: 102A 0001
02: 5100
BP: 2000 00C0 [0001]
EC: []
T0: 0213 [010F]
System halt!
Cheers
Daniel
Re: [PATCH 03/31] board: mediatek: add MT7986 reference boards
Hi Weijie, On Thu, Aug 04, 2022 at 11:35:03AM +0800, Weijie Gao wrote: > This patch adds general board files based on MT7986 SoCs. > > The SD/eMMC controller on MT7986A and MT7986B have different pin > configurations so that four different reference board configs has to be > added. > > Signed-off-by: Weijie Gao > --- > [...] > diff --git a/include/configs/mt7986.h b/include/configs/mt7986.h > new file mode 100644 > index 00..b28fc0f613 > --- /dev/null > +++ b/include/configs/mt7986.h > @@ -0,0 +1,26 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Configuration for MediaTek MT7986 SoC > + * > + * Copyright (C) 2022 MediaTek Inc. > + * Author: Sam Shih > + */ > + > +#ifndef __MT7986_H > +#define __MT7986_H > + > +#include > + In the SDK sources I found also #define CONFIG_SYS_BOOTM_LEN SZ_128M here which is actually needed to boot any image with uncompressed kernel larger than 8MiB. As for ARM64 this size is easily exceeded and we got plenty of RAM, I suggest to also include a more generous CONFIG_SYS_BOOTM_LEN in your submission to upstream U-Boot. > +#define CONFIG_SYS_NONCACHED_MEMORY SZ_1M > +#define CONFIG_SYS_MMC_ENV_DEV 0 > + > +/* Uboot definition */ > +#define CONFIG_SYS_UBOOT_BASECONFIG_SYS_TEXT_BASE > + > +/* SPL -> Uboot */ > +#define CONFIG_SYS_UBOOT_START CONFIG_SYS_TEXT_BASE > + > +/* DRAM */ > +#define CONFIG_SYS_SDRAM_BASE0x4000 > + > +#endif > -- > 2.17.1 >
Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC
Hi Weijie, I manually fixed the last 3 patches in the series adding support for newer SoCs to mkimage/mtk_image. On my BPi-R3 (mt7986a) I was now trying to use mkimage instead of bromimage in the same way you introduced that option for mt7622[1]: The resulting bl2.img works fine on SPI-NAND and eMMC, however, booting from SPI-NOR or SD card doesn't work. On SPI-NOR: F0: 102B FA: V0: 7027 6006 [0001] 00: 1017 FA: 5100 01: 102A 0001 02: 5100 BP: 2000 00C0 [0001] EC: [] T0: 0213 [010F] System halt! On SD card: F0: 102B FA: 1040 FA: 1040 [0200] F9: 103F F3: 1001 [0200] F3: 1001 F6: 300C 0028 F5: L0: 8005 [0001] 00: 1012 BP: 2000 00C0 [0001] EC: [3000] T0: 00E8 [010F] System halt! All generate image headers also differ from the ones generated by bromimage, however, for SPI-NAND and eMMC they still work. hexdiff of SD card bl2.img @@ -65,7 +65,7 @@ 4420 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * 4600 42 52 4c 59 54 00 00 00 01 00 00 00 00 4a 00 00 |BRLYTJ..| -4610 88 51 03 00 42 42 42 42 08 00 01 00 00 06 00 00 |.Q..| +4610 88 51 03 00 42 42 42 42 08 00 01 00 00 4a 00 00 |.Q...J..| 4620 88 51 03 00 ff ff ff ff ff ff ff ff ff ff ff ff |.Q..| 4630 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || * @@ -73,15 +73,15 @@ 4a10 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O. .| 4a20 88 07 03 00 88 0d 03 00 00 03 00 00 20 00 00 00 | ...| 4a30 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |MMM.| -4a40 01 00 00 00 4d 4d 4d 01 14 00 02 00 00 00 00 00 |MMM.| -4a50 10 00 00 00 80 00 00 00 4d 4d 4d 01 14 02 03 00 |MMM.| -4a60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || -* -4c60 00 00 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 03 |MMM.| -4c70 64 00 07 00 90 11 00 00 00 00 00 00 00 00 00 00 |d...| -4c80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || +4a40 01 00 00 00 4d 4d 4d 03 64 00 07 00 90 11 00 00 |MMM.d...| +4a50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * -4cc0 00 64 00 00 88 13 00 00 00 00 00 00 00 00 00 00 |.d..| +4a90 00 00 00 00 00 00 00 00 00 64 00 00 88 13 00 00 |.d..| +4aa0 00 00 00 00 00 00 00 00 4d 4d 4d 01 14 02 03 00 |MMM.| +4ab0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || +* +4cb0 00 00 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 01 |MMM.| +4cc0 14 00 02 00 00 00 00 00 10 00 00 00 80 00 00 00 || 4cd0 4d 4d 4d 01 30 00 08 00 03 00 00 00 00 00 00 00 |MMM.0...| 4ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * hexdiff of SPI-NOR bl2.img @@ -11,15 +11,15 @@ 0610 4f 00 00 00 01 00 00 00 01 00 05 01 00 0d 20 00 |O. .| 0620 70 0a 03 00 70 10 03 00 00 03 00 00 20 00 00 00 |p...p... ...| 0630 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |MMM.| -0640 01 00 00 00 4d 4d 4d 03 64 00 07 00 90 11 00 00 |MMM.d...| -0650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || +0640 01 00 00 00 4d 4d 4d 01 14 00 02 00 00 00 00 00 |MMM.| +0650 10 00 00 00 80 00 00 00 4d 4d 4d 01 14 02 03 00 |MMM.| +0660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * -0690 00 00 00 00 00 00 00 00 00 64 00 00 88 13 00 00 |.d..| -06a0 00 00 00 00 00 00 00 00 4d 4d 4d 01 14 02 03 00 |MMM.| -06b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || +0860 00 00 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 03 |MMM.| +0870 64 00 07 00 90 11 00 00 00 00 00 00 00 00 00 00 |d...| +0880 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * -08b0 00 00 00 00 00 00 00 00 00 00 00 00 4d 4d 4d 01 |MMM.| -08c0 14 00 02 00 00 00 00 00 10 00 00 00 80 00 00 00 || +08c0 00 64 00 00 88 13 00 00 00 00 00 00 00 00 00 00 |.d..| 08d0 4d 4d 4d 01 30 00 08 00 03 00 00 00 00 00 00 00 |MMM.0...| 08e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * I'll try to have a look at this more deepply in the next days, but if you already spot the error I'd also be glad ;) Cheers Daniel [1]: https://github.com/dangowrt/arm-trusted-firmware/commit/3b8a17bd847d864379fe9953a82991b522f64add On Fri, Aug 05, 2022 at 04:43:39PM +0800, Weijie Gao wrote: > Hi Daniel, > > It turns out that this was caused by a setting change of company's mail
Re: [PATCH 29/31] tools: mtk_image: split the code of generating NAND header into a new file
Hi Weijie,
please see one comment in-line below:
On Thu, Aug 04, 2022 at 11:36:50AM +0800, Weijie Gao wrote:
> The predefined NAND headers take too much spaces in the mtk_image.c.
> Moving them into a new file can significantly improve the readability of
> both mtk_image.c and the new mtk_nand_headers.c.
>
> This is a preparation for adding more NAND headers.
>
> Signed-off-by: Weijie Gao
> ---
> tools/Makefile | 1 +
> tools/mtk_image.c| 304 ++-
> tools/mtk_image.h| 25
> tools/mtk_nand_headers.c | 286
> tools/mtk_nand_headers.h | 52 +++
> 5 files changed, 379 insertions(+), 289 deletions(-)
> create mode 100644 tools/mtk_nand_headers.c
> create mode 100644 tools/mtk_nand_headers.h
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 9f2339666a..4f27ed1ab1 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -147,6 +147,7 @@ dumpimage-mkimage-objs := aisimage.o \
> gpimage.o \
> gpimage-common.o \
> mtk_image.o \
> + mtk_nand_headers.o \
> $(ECDSA_OBJS-y) \
> $(RSA_OBJS-y) \
> $(AES_OBJS-y)
> diff --git a/tools/mtk_image.c b/tools/mtk_image.c
> index dcd6525f32..3701d1564a 100644
> --- a/tools/mtk_image.c
> +++ b/tools/mtk_image.c
> @@ -12,216 +12,7 @@
> #include
> #include "imagetool.h"
> #include "mtk_image.h"
> -
> -/* NAND header for SPI-NAND with 2KB page + 64B spare */
> -static const union nand_boot_header snand_hdr_2k_64_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x03, 0x00, 0x40, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x7B, 0xC4, 0x17, 0x9D,
> - 0xCA, 0x42, 0x90, 0xD0, 0x98, 0xD0, 0xE0, 0xF7,
> - 0xDB, 0xCD, 0x16, 0xF6, 0x03, 0x73, 0xD2, 0xB8,
> - 0x93, 0xB2, 0x56, 0x5A, 0x84, 0x6E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 2KB page + 120B/128B spare */
> -static const union nand_boot_header snand_hdr_2k_128_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x08, 0x05, 0x00, 0x70, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x90, 0x28, 0xED, 0x13,
> - 0x7F, 0x12, 0x22, 0xCD, 0x3D, 0x06, 0xF1, 0xB3,
> - 0x6F, 0x2E, 0xD9, 0xA0, 0x9D, 0x7A, 0xBD, 0xD7,
> - 0xB3, 0x28, 0x3C, 0x13, 0xDB, 0x4E, 0x00, 0x00
> - }
> -};
> -
> -/* NAND header for SPI-NAND with 4KB page + 256B spare */
> -static const union nand_boot_header snand_hdr_4k_256_data = {
> - .data = {
> - 0x42, 0x4F, 0x4F, 0x54, 0x4C, 0x4F, 0x41, 0x44,
> - 0x45, 0x52, 0x21, 0x00, 0x56, 0x30, 0x30, 0x36,
> - 0x4E, 0x46, 0x49, 0x49, 0x4E, 0x46, 0x4F, 0x00,
> - 0x00, 0x00, 0x00, 0x10, 0x05, 0x00, 0xE0, 0x00,
> - 0x40, 0x00, 0x00, 0x08, 0x10, 0x00, 0x16, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x47, 0xED, 0x0E, 0xC3,
> - 0x83, 0xBF, 0x41, 0xD2, 0x85, 0x21, 0x97, 0x57,
> - 0xC4, 0x2E, 0x6B, 0x7A, 0x40, 0xE0,
Re: [PATCH 01/31] arm: mediatek: add support for MediaTek MT7986 SoC
Hi Weijie,
happy to see this series posted!
Trying to apply it unfortunately fails due to errornous line-breaks,
supposedly inserted by your MUA, see below.
I didn't go beyond the first patch and it'd be nice if you report the
whole series without the wrong line-breaks.
Cheers
Daniel
On Thu, Aug 04, 2022 at 11:34:28AM +0800, Weijie Gao wrote:
> This patch adds basic support for MediaTek MT7986 SoC.
> This include the file that will initialize the SoC after boot and its
> device tree.
>
> Signed-off-by: Weijie Gao
> ---
> arch/arm/dts/mt7986-u-boot.dtsi | 33 ++
> arch/arm/dts/mt7986.dtsi | 341 ++
> arch/arm/mach-mediatek/Kconfig| 11 +
> arch/arm/mach-mediatek/Makefile | 1 +
> arch/arm/mach-mediatek/mt7986/Makefile| 4 +
> arch/arm/mach-mediatek/mt7986/init.c | 53 +++
> arch/arm/mach-mediatek/mt7986/lowlevel_init.S | 30 ++
> 7 files changed, 473 insertions(+)
> create mode 100644 arch/arm/dts/mt7986-u-boot.dtsi
> create mode 100644 arch/arm/dts/mt7986.dtsi
> create mode 100644 arch/arm/mach-mediatek/mt7986/Makefile
> create mode 100644 arch/arm/mach-mediatek/mt7986/init.c
> create mode 100644 arch/arm/mach-mediatek/mt7986/lowlevel_init.S
>
> diff --git a/arch/arm/dts/mt7986-u-boot.dtsi
> b/arch/arm/dts/mt7986-u-boot.dtsi
The above two lines should be a single line.
> new file mode 100644
> index 00..95671f8afa
> --- /dev/null
> +++ b/arch/arm/dts/mt7986-u-boot.dtsi
> @@ -0,0 +1,33 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/mt7986.dtsi b/arch/arm/dts/mt7986.dtsi
> new file mode 100644
> index 00..f235bd8b8c
> --- /dev/null
> +++ b/arch/arm/dts/mt7986.dtsi
> @@ -0,0 +1,341 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2022 MediaTek Inc.
> + * Author: Sam Shih
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "mediatek,mt7986";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + config {
> + u-boot,mmc-env-partition = "u-boot-env";
> + };
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x0>;
> + };
> + cpu1: cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu2: cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + cpu3: cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53";
> + reg = <0x1>;
> + };
> + };
> +
> + dummy_clk: dummy12m {
> + compatible = "fixed-clock";
> + clock-frequency = <1200>;
> + #clock-cells = <0>;
> + /* must need this line, or uart uanable to get dummy_clk */
> + u-boot,dm-pre-reloc;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupt-parent = <>;
> + clock-frequency = <1300>;
> + interrupts = ,
> + ,
> + ,
> + ;
> + arm,cpu-registers-not-fw-configured;
> + };
> +
> + timer0: timer@10008000 {
> + compatible = "mediatek,mt7986-timer";
> + reg = <0x10008000 0x1000>;
> + interrupts = ;
> + clocks = < CK_INFRA_CK_F26M>;
> + clock-names = "gpt-clk";
>
[PULL] u-boot-mips for v2022.10
Hi Tom, this time with all Kconfig migrations from -next included ;) Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12740 Azure: https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=31=results The following changes since commit 357fa8bb4d40abf411a6cca70f5a2dd6413028ea: Merge tag 'u-boot-stm32-20220712' of https://source.denx.de/u-boot/custodians/u-boot-stm (2022-07-13 08:09:20 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-pull-2022-07-13 for you to fetch changes up to dd6bf539e88aff1b8caeeccbe9af59b2191a178b: MAINTAINERS: update maintainer for MediaTek MIPS platform (2022-07-13 23:03:37 +0200) - MIPS: add drivers and board support for Mediatek MT7621 SoC Weijie Gao (25): mips: add asm/mipsmtregs.h for MIPS multi-threading mips: add more definitions for asm/cm.h mips: add __image_copy_len for SPL linker script mips: add support for noncached_alloc() mips: mtmips: add support for MediaTek MT7621 SoC mips: mtmips: add two reference boards for mt7621 doc: mediatek: add documentation for mt7621 reference boards clk: mtmips: add clock driver for MediaTek MT7621 SoC reset: mtmips: add reset controller support for MediaTek MT7621 SoC pinctrl: mtmips: add support for MediaTek MT7621 SoC usb: xhci-mtk: add support for MediaTek MT7621 SoC phy: mtk-tphy: add support for MediaTek MT7621 SoC spi: add support for MediaTek MT7621 SoC gpio: add support for MediaTek MT7621 SoC watchdog: add support for MediaTek MT7621 SoC mmc: mediatek: add support for MediaTek MT7621 SoC net: mediatek: remap iobase address net: mediatek: use regmap api to modify ethsys registers net: mediatek: add support for MediaTek MT7621 SoC nand: raw: add support for MediaTek MT7621 SoC spl: allow using nand base without standard nand driver spl: spl_legacy: fix the use of SPL_COPY_PAYLOAD_ONLY spl: nand: support loading legacy image with payload compressed tools: mtk_image: add support for MT7621 NAND images MAINTAINERS: update maintainer for MediaTek MIPS platform MAINTAINERS|8 + arch/mips/Makefile |5 + arch/mips/cpu/u-boot-spl.lds |3 + arch/mips/dts/Makefile |2 + arch/mips/dts/mediatek,mt7621-nand-rfb.dts | 67 ++ arch/mips/dts/mediatek,mt7621-rfb.dts | 82 ++ arch/mips/dts/mt7621-u-boot.dtsi | 111 +++ arch/mips/dts/mt7621.dtsi | 349 +++ arch/mips/include/asm/cm.h | 67 ++ arch/mips/include/asm/mipsmtregs.h | 142 +++ arch/mips/include/asm/system.h | 20 + arch/mips/lib/cache.c | 43 + arch/mips/mach-mtmips/Kconfig | 49 +- arch/mips/mach-mtmips/Makefile |4 + arch/mips/mach-mtmips/cpu.c|2 +- arch/mips/mach-mtmips/mt7621/Kconfig | 115 +++ arch/mips/mach-mtmips/mt7621/Makefile | 14 + arch/mips/mach-mtmips/mt7621/init.c| 246 + arch/mips/mach-mtmips/mt7621/mt7621.h | 229 + arch/mips/mach-mtmips/mt7621/serial.c | 23 + arch/mips/mach-mtmips/mt7621/spl/Makefile |9 + arch/mips/mach-mtmips/mt7621/spl/cps.c | 153 +++ arch/mips/mach-mtmips/mt7621/spl/dram.c| 153 +++ arch/mips/mach-mtmips/mt7621/spl/dram.h| 39 + arch/mips/mach-mtmips/mt7621/spl/launch.c | 100 ++ arch/mips/mach-mtmips/mt7621/spl/launch.h | 52 + arch/mips/mach-mtmips/mt7621/spl/launch_ll.S | 339 +++ arch/mips/mach-mtmips/mt7621/spl/serial.c | 24 + arch/mips/mach-mtmips/mt7621/spl/spl.c | 96 ++ arch/mips/mach-mtmips/mt7621/spl/start.S | 226 + arch/mips/mach-mtmips/mt7621/sram_init.S | 22 + arch/mips/mach-mtmips/mt7621/tpl/Makefile |4 + arch/mips/mach-mtmips/mt7621/tpl/start.S | 161 arch/mips/mach-mtmips/mt7621/tpl/tpl.c | 144 +++ board/mediatek/mt7621/MAINTAINERS |8 + board/mediatek/mt7621/Makefile |3 + board/mediatek/mt7621/board.c |6 + common/spl/Kconfig |2 +- common/spl/spl_legacy.c| 21 +- common/spl/spl_nand.c | 27 + configs/mt7621_nand_rfb_defconfig | 89 ++ configs/mt7621_rfb_defconfig | 86 ++ doc/board/index.rst|1 + doc/board/mediatek/index.rst |9 + doc/board/mediatek/mt7621.rst | 48 +
[PATCH 4/4] MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig
This converts the following to Kconfig: CONFIG_SYS_MIPS_TIMER_REQ Signed-off-by: Daniel Schwierzeck --- arch/mips/Kconfig | 18 ++ configs/ap121_defconfig| 1 + configs/ap143_defconfig| 1 + configs/ap152_defconfig| 1 + configs/bcm968380gerg_ram_defconfig| 1 + configs/boston32r2_defconfig | 1 + configs/boston32r2el_defconfig | 1 + configs/boston32r6_defconfig | 1 + configs/boston32r6el_defconfig | 1 + configs/boston64r2_defconfig | 1 + configs/boston64r2el_defconfig | 1 + configs/boston64r6_defconfig | 1 + configs/boston64r6el_defconfig | 1 + configs/ci20_mmc_defconfig | 1 + configs/comtrend_ar5315u_ram_defconfig | 1 + configs/comtrend_ar5387un_ram_defconfig| 1 + configs/comtrend_ct5361_ram_defconfig | 1 + configs/comtrend_vr3032u_ram_defconfig | 1 + configs/comtrend_wap5813n_ram_defconfig| 1 + configs/gardena-smart-gateway-mt7688_defconfig | 1 + configs/huawei_hg556a_ram_defconfig| 1 + configs/imgtec_xilfpga_defconfig | 1 + configs/linkit-smart-7688_defconfig| 1 + configs/malta64_defconfig | 1 + configs/malta64el_defconfig| 1 + configs/malta_defconfig| 1 + configs/maltael_defconfig | 1 + configs/mscc_jr2_defconfig | 1 + configs/mscc_luton_defconfig | 1 + configs/mscc_ocelot_defconfig | 1 + configs/mscc_serval_defconfig | 1 + configs/mscc_servalt_defconfig | 1 + configs/mt7620_mt7530_rfb_defconfig| 1 + configs/mt7620_rfb_defconfig | 1 + configs/mt7621_nand_rfb_defconfig | 1 + configs/mt7621_rfb_defconfig | 1 + configs/mt7628_rfb_defconfig | 1 + configs/netgear_cg3100d_ram_defconfig | 1 + configs/netgear_dgnd3700v2_ram_defconfig | 1 + configs/pic32mzdask_defconfig | 1 + configs/sagem_f@st1704_ram_defconfig | 1 + configs/sfr_nb4-ser_ram_defconfig | 1 + configs/tplink_wdr4300_defconfig | 1 + configs/vocore2_defconfig | 1 + include/configs/ap121.h| 2 -- include/configs/ap143.h| 2 -- include/configs/ap152.h| 2 -- include/configs/bmips_bcm3380.h| 3 --- include/configs/bmips_bcm6318.h| 3 --- include/configs/bmips_bcm63268.h | 3 --- include/configs/bmips_bcm6328.h| 3 --- include/configs/bmips_bcm6338.h| 3 --- include/configs/bmips_bcm6348.h| 3 --- include/configs/bmips_bcm6358.h| 3 --- include/configs/bmips_bcm6362.h| 3 --- include/configs/bmips_bcm6368.h| 3 --- include/configs/bmips_bcm6838.h| 3 --- include/configs/boston.h | 1 - include/configs/ci20.h | 3 --- include/configs/gardena-smart-gateway-mt7688.h | 3 --- include/configs/imgtec_xilfpga.h | 2 -- include/configs/linkit-smart-7688.h| 3 --- include/configs/malta.h| 1 - include/configs/mt7620.h | 2 -- include/configs/mt7621.h | 2 -- include/configs/mt7628.h | 2 -- include/configs/pic32mzdask.h | 2 -- include/configs/tplink_wdr4300.h | 2 -- include/configs/vcoreiii.h | 5 - include/configs/vocore2.h | 3 --- scripts/config_whitelist.txt | 1 - 71 files changed, 61 insertions(+), 68 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 8bef63cbb7..9af0133f10 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -14,6 +14,7 @@ choice config TARGET_MALTA bool "Support malta" + select HAS_FIXED_TIMER_FREQUENCY select BOARD_EARLY_INIT_R select DM select DM_SERIAL @@ -41,17 +42,20 @@ config TARGET_MALTA config ARCH_ATH79 bool "Support QCA/Atheros ath79" + select HAS_FIXED_TIMER_FREQUENCY select DM select OF_CONTROL imply CMD_DM config ARCH_MSCC bool "Support MSCC VCore-III" + select HAS_FIXED_TIMER_FREQUENCY select OF_CONTROL select DM config ARCH_BMIPS bool "Support BMIPS SoCs" + select HAS_FIXED_TIMER_FREQUENCY select CLK select CPU selec
[PATCH 2/4] MIPS: remove CONFIG_SYS_MHZ
Resolve all uses of CONFIG_SYS_MHZ with the currently defined value.
Remove code which depends on CONFIG_SYS_MHZ but where no board configs
actually use that code.
Signed-off-by: Daniel Schwierzeck
---
arch/mips/mach-jz47xx/include/mach/jz4780.h | 2 +-
arch/mips/mach-jz47xx/jz4780/pll.c | 6 +-
board/imgtec/ci20/ci20.c| 4
include/configs/ap121.h | 3 +--
include/configs/ap143.h | 3 +--
include/configs/ap152.h | 3 +--
include/configs/ci20.h | 3 +--
include/configs/malta.h | 3 +--
include/configs/tplink_wdr4300.h| 3 +--
scripts/config_whitelist.txt| 1 -
10 files changed, 8 insertions(+), 23 deletions(-)
diff --git a/arch/mips/mach-jz47xx/include/mach/jz4780.h
b/arch/mips/mach-jz47xx/include/mach/jz4780.h
index 4422e503ed..880445dac3 100644
--- a/arch/mips/mach-jz47xx/include/mach/jz4780.h
+++ b/arch/mips/mach-jz47xx/include/mach/jz4780.h
@@ -60,7 +60,7 @@
/* PLL setup */
#define JZ4780_SYS_EXTAL 4800
-#define JZ4780_SYS_MEM_SPEED (CONFIG_SYS_MHZ * 100)
+#define JZ4780_SYS_MEM_SPEED (1200 * 100)
#define JZ4780_SYS_MEM_DIV 3
#define JZ4780_SYS_AUDIO_SPEED (768 * 100)
diff --git a/arch/mips/mach-jz47xx/jz4780/pll.c
b/arch/mips/mach-jz47xx/jz4780/pll.c
index 323c634fb3..4519b478cc 100644
--- a/arch/mips/mach-jz47xx/jz4780/pll.c
+++ b/arch/mips/mach-jz47xx/jz4780/pll.c
@@ -399,11 +399,7 @@ static void cpu_mux_select(int pll)
((2 - 1) << CPM_CPCCR_L2DIV_BIT) |
((1 - 1) << CPM_CPCCR_CDIV_BIT);
- if (CONFIG_SYS_MHZ >= 1000)
- clk_ctrl |= (12 - 1) << CPM_CPCCR_PDIV_BIT;
- else
- clk_ctrl |= (6 - 1) << CPM_CPCCR_PDIV_BIT;
-
+ clk_ctrl |= (12 - 1) << CPM_CPCCR_PDIV_BIT;
clrsetbits_le32(cpm_regs + CPM_CPCCR, 0x00ff, clk_ctrl);
while (readl(cpm_regs + CPM_CPCSR) & (CPM_CPCSR_CDIV_BUSY |
diff --git a/board/imgtec/ci20/ci20.c b/board/imgtec/ci20/ci20.c
index 7cbe49abd9..89f5e7ad79 100644
--- a/board/imgtec/ci20/ci20.c
+++ b/board/imgtec/ci20/ci20.c
@@ -350,10 +350,6 @@ static const struct jz4780_ddr_config
H5TQ2G83CFR_48_config = {
.pulldn = 0x0e,
};
-#if (CONFIG_SYS_MHZ != 1200)
-#error No DDR configuration for CPU speed
-#endif
-
const struct jz4780_ddr_config *jz4780_get_ddr_config(void)
{
const int board_revision = ci20_revision();
diff --git a/include/configs/ap121.h b/include/configs/ap121.h
index 099aac5421..61cc073a8a 100644
--- a/include/configs/ap121.h
+++ b/include/configs/ap121.h
@@ -6,8 +6,7 @@
#ifndef __CONFIG_H
#define __CONFIG_H
-#define CONFIG_SYS_MHZ 200
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 2
#define CONFIG_SYS_SDRAM_BASE 0x8000
diff --git a/include/configs/ap143.h b/include/configs/ap143.h
index 60b9e779fa..579b9b4f2c 100644
--- a/include/configs/ap143.h
+++ b/include/configs/ap143.h
@@ -6,8 +6,7 @@
#ifndef __CONFIG_H
#define __CONFIG_H
-#define CONFIG_SYS_MHZ 325
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 32500
#define CONFIG_SYS_SDRAM_BASE 0x8000
diff --git a/include/configs/ap152.h b/include/configs/ap152.h
index d165ead7bb..283762fd22 100644
--- a/include/configs/ap152.h
+++ b/include/configs/ap152.h
@@ -6,8 +6,7 @@
#ifndef __CONFIG_H
#define __CONFIG_H
-#define CONFIG_SYS_MHZ 375
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 37500
#define CONFIG_SYS_SDRAM_BASE 0x8000
diff --git a/include/configs/ci20.h b/include/configs/ci20.h
index 192da015e1..7e8a9fcb80 100644
--- a/include/configs/ci20.h
+++ b/include/configs/ci20.h
@@ -10,8 +10,7 @@
#define __CONFIG_CI20_H__
/* Ingenic JZ4780 clock configuration. */
-#define CONFIG_SYS_MHZ 1200
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 12
/* Memory configuration */
#define CONFIG_SYS_MONITOR_LEN (512 * 1024)
diff --git a/include/configs/malta.h b/include/configs/malta.h
index c8b230ab21..717867d12a 100644
--- a/include/configs/malta.h
+++ b/include/configs/malta.h
@@ -18,8 +18,7 @@
/*
* CPU Configuration
*/
-#define CONFIG_SYS_MHZ 250 /* arbitrary value */
-#define CONFIG_SYS_MIPS_TIMER_FREQ (CONFIG_SYS_MHZ * 100)
+#define CONFIG_SYS_MIPS_TIMER_FREQ 25000
/*
* Memory map
diff --git a/include/configs/tplink_wdr4300.h b/include/configs/tplink_wdr4300.h
index f5466fd509..1400a211e3 100644
--- a/include/configs/tplink_wdr4300.h
+++ b/include/configs/tplink_wdr4300.h
@@ -6,8 +6,7 @@
#ifndef __CO
[PATCH 1/4] MIPS: remove deprecated TARGET_VCT option
This board has been removed a long time ago. Signed-off-by: Daniel Schwierzeck --- arch/mips/Kconfig | 8 1 file changed, 8 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 2e0793a7a7..8bef63cbb7 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -39,14 +39,6 @@ config TARGET_MALTA select SWAP_IO_SPACE imply CMD_DM -config TARGET_VCT - bool "Support vct" - select ROM_EXCEPTION_VECTORS - select SUPPORTS_BIG_ENDIAN - select SUPPORTS_CPU_MIPS32_R1 - select SUPPORTS_CPU_MIPS32_R2 - select SYS_MIPS_CACHE_INIT_RAM_LOAD - config ARCH_ATH79 bool "Support QCA/Atheros ath79" select DM -- 2.37.0
[PATCH 3/4] MIPS: mscc: remove unused CPU_CLOCK_RATE
CPU_CLOCK_RATE is just used once for CONFIG_SYS_MIPS_TIMER_FREQ which is migrated to Kconfig in the next patch. Signed-off-by: Daniel Schwierzeck --- include/configs/vcoreiii.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/configs/vcoreiii.h b/include/configs/vcoreiii.h index 78a62a8b02..5c5036b8be 100644 --- a/include/configs/vcoreiii.h +++ b/include/configs/vcoreiii.h @@ -13,11 +13,9 @@ #define CONFIG_SYS_INIT_SP_OFFSET 0x40 #if defined(CONFIG_SOC_LUTON) || defined(CONFIG_SOC_SERVAL) -#define CPU_CLOCK_RATE 41666 /* Clock for the MIPS core */ #define CONFIG_SYS_MIPS_TIMER_FREQ 20833 #else -#define CPU_CLOCK_RATE 5 /* Clock for the MIPS core */ -#define CONFIG_SYS_MIPS_TIMER_FREQ (CPU_CLOCK_RATE / 2) +#define CONFIG_SYS_MIPS_TIMER_FREQ 25000 #endif #define CONFIG_SYS_NS16550_CLK CONFIG_SYS_MIPS_TIMER_FREQ -- 2.37.0
[PATCH 0/4] Convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig
This removes CONFIG_SYS_HZ and converts CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig. The series only applies on u-boot-mips/next (based on u-boot/next and the Mediatek MT7621 series). Daniel Schwierzeck (4): MIPS: remove deprecated TARGET_VCT option MIPS: remove CONFIG_SYS_MHZ MIPS: mscc: remove unused CPU_CLOCK_RATE MIPS: convert CONFIG_SYS_MIPS_TIMER_FREQ to Kconfig arch/mips/Kconfig | 26 +-- arch/mips/mach-jz47xx/include/mach/jz4780.h | 2 +- arch/mips/mach-jz47xx/jz4780/pll.c| 6 + board/imgtec/ci20/ci20.c | 4 --- configs/ap121_defconfig | 1 + configs/ap143_defconfig | 1 + configs/ap152_defconfig | 1 + configs/bcm968380gerg_ram_defconfig | 1 + configs/boston32r2_defconfig | 1 + configs/boston32r2el_defconfig| 1 + configs/boston32r6_defconfig | 1 + configs/boston32r6el_defconfig| 1 + configs/boston64r2_defconfig | 1 + configs/boston64r2el_defconfig| 1 + configs/boston64r6_defconfig | 1 + configs/boston64r6el_defconfig| 1 + configs/ci20_mmc_defconfig| 1 + configs/comtrend_ar5315u_ram_defconfig| 1 + configs/comtrend_ar5387un_ram_defconfig | 1 + configs/comtrend_ct5361_ram_defconfig | 1 + configs/comtrend_vr3032u_ram_defconfig| 1 + configs/comtrend_wap5813n_ram_defconfig | 1 + .../gardena-smart-gateway-mt7688_defconfig| 1 + configs/huawei_hg556a_ram_defconfig | 1 + configs/imgtec_xilfpga_defconfig | 1 + configs/linkit-smart-7688_defconfig | 1 + configs/malta64_defconfig | 1 + configs/malta64el_defconfig | 1 + configs/malta_defconfig | 1 + configs/maltael_defconfig | 1 + configs/mscc_jr2_defconfig| 1 + configs/mscc_luton_defconfig | 1 + configs/mscc_ocelot_defconfig | 1 + configs/mscc_serval_defconfig | 1 + configs/mscc_servalt_defconfig| 1 + configs/mt7620_mt7530_rfb_defconfig | 1 + configs/mt7620_rfb_defconfig | 1 + configs/mt7621_nand_rfb_defconfig | 1 + configs/mt7621_rfb_defconfig | 1 + configs/mt7628_rfb_defconfig | 1 + configs/netgear_cg3100d_ram_defconfig | 1 + configs/netgear_dgnd3700v2_ram_defconfig | 1 + configs/pic32mzdask_defconfig | 1 + configs/sagem_f@st1704_ram_defconfig | 1 + configs/sfr_nb4-ser_ram_defconfig | 1 + configs/tplink_wdr4300_defconfig | 1 + configs/vocore2_defconfig | 1 + include/configs/ap121.h | 3 --- include/configs/ap143.h | 3 --- include/configs/ap152.h | 3 --- include/configs/bmips_bcm3380.h | 3 --- include/configs/bmips_bcm6318.h | 3 --- include/configs/bmips_bcm63268.h | 3 --- include/configs/bmips_bcm6328.h | 3 --- include/configs/bmips_bcm6338.h | 3 --- include/configs/bmips_bcm6348.h | 3 --- include/configs/bmips_bcm6358.h | 3 --- include/configs/bmips_bcm6362.h | 3 --- include/configs/bmips_bcm6368.h | 3 --- include/configs/bmips_bcm6838.h | 3 --- include/configs/boston.h | 1 - include/configs/ci20.h| 4 --- .../configs/gardena-smart-gateway-mt7688.h| 3 --- include/configs/imgtec_xilfpga.h | 2 -- include/configs/linkit-smart-7688.h | 3 --- include/configs/malta.h | 2 -- include/configs/mt7620.h | 2 -- include/configs/mt7621.h | 2 -- include/configs/mt7628.h | 2 -- include/configs/pic32mzdask.h | 2 -- include/configs/tplink_wdr4300.h | 3 --- include/configs/vcoreiii.h| 7 - include/configs/vocore2.h | 3 --- scripts/config_whitelist.txt | 2 -- 74 files changed, 63 insertions(+), 95 deletions(-) -- 2.37.0
Re: [PULL] u-boot-mips for u-boot/next (v2022.10)
On 09.07.22 14:43, Tom Rini wrote: On Sat, Jul 09, 2022 at 02:01:01PM +0200, Daniel Schwierzeck wrote: Hi Tom, On 08.07.22 18:50, Tom Rini wrote: On Fri, Jul 08, 2022 at 05:21:48PM +0200, Daniel SchwierzeckHi Tom, wrote: Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12656 Azure: https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=30=results The following changes since commit 2d2c61ff0460740d9ec5a44dbef9255a8c690696: Merge tag 'efi-2022-07-rc7' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-07-06 09:17:08 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-pull-2022-07-08 for you to fetch changes up to e5fc4022af3cfd59e3459276305671a595ac5ff0: MAINTAINERS: update maintainer for MediaTek MIPS platform (2022-07-08 15:13:29 +0200) - MIPS: add drivers and board support for Mediatek MT7621 SoC OK, we need a few changes here, sorry. There's now migrated CONFIG symbols, most of which are easy to do and I was about to, and then I saw this: #ifdef CONFIG_TPL_BUILD #define CONFIG_SPL_START_S_PATH "arch/mips/mach-mtmips/mt7621/tpl" /* .bss will not be used by TPL */ #define CONFIG_SPL_BSS_START_ADDR 0x8000 #define CONFIG_SPL_BSS_MAX_SIZE 0 #else #define CONFIG_SPL_START_S_PATH "arch/mips/mach-mtmips/mt7621/spl" #define CONFIG_SPL_BSS_START_ADDR 0x8014 #define CONFIG_SPL_BSS_MAX_SIZE 0x8 #define CONFIG_SPL_MAX_SIZE 0x3 #endif No, you cannot abuse CONFIG_TPL_BUILD to set CONFIG_SPL_foo. Those need to become CONFIG_TPL_foo, and set appropriately. And then for [ST]PL_START_S_PATH, you need to set head-$(CONFIG_ARCH_xxx) to the right file, for SPL/TPL instead. do you already have patches for converting stuff like CONFIG_SPL_BSS_START_ADDR prepared? Than I would wait with the pull request until those patches are applied to mainline and I would adapt the MT7621 patches. I could also assist with converting CONFIG_SPL_START_S_PATH because that's only used on MIPS and one ARM board. See what's in -next already? SPL_BSS_START_ADDR is migrated, but there were no TPL_BSS_START_ADDR cases. For START_S_PATH, the platform just needs to be reworked as I suggested above I believe, to achieve the desired result. sorry, didn't check the latest updates in -next and the series was too long on the list ;) TPL_BSS_START_ADDR shouldn't be necessary because MT7621 doesn't use BSS in TPL, the defined values where just dummy values. I rechecked and removed all migrated Kconfig options from mt7621.h and pushed an update to u-boot-mips/next. Weijie could you verify that? If all is okay, I'll prepare a new pull request, otherwise please send me a v7 patch series. -- - Daniel
Re: [PULL] u-boot-mips for u-boot/next (v2022.10)
Hi Tom, On 08.07.22 18:50, Tom Rini wrote: On Fri, Jul 08, 2022 at 05:21:48PM +0200, Daniel SchwierzeckHi Tom, wrote: Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12656 Azure: https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=30=results The following changes since commit 2d2c61ff0460740d9ec5a44dbef9255a8c690696: Merge tag 'efi-2022-07-rc7' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-07-06 09:17:08 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-pull-2022-07-08 for you to fetch changes up to e5fc4022af3cfd59e3459276305671a595ac5ff0: MAINTAINERS: update maintainer for MediaTek MIPS platform (2022-07-08 15:13:29 +0200) - MIPS: add drivers and board support for Mediatek MT7621 SoC OK, we need a few changes here, sorry. There's now migrated CONFIG symbols, most of which are easy to do and I was about to, and then I saw this: #ifdef CONFIG_TPL_BUILD #define CONFIG_SPL_START_S_PATH "arch/mips/mach-mtmips/mt7621/tpl" /* .bss will not be used by TPL */ #define CONFIG_SPL_BSS_START_ADDR 0x8000 #define CONFIG_SPL_BSS_MAX_SIZE 0 #else #define CONFIG_SPL_START_S_PATH "arch/mips/mach-mtmips/mt7621/spl" #define CONFIG_SPL_BSS_START_ADDR 0x8014 #define CONFIG_SPL_BSS_MAX_SIZE 0x8 #define CONFIG_SPL_MAX_SIZE 0x3 #endif No, you cannot abuse CONFIG_TPL_BUILD to set CONFIG_SPL_foo. Those need to become CONFIG_TPL_foo, and set appropriately. And then for [ST]PL_START_S_PATH, you need to set head-$(CONFIG_ARCH_xxx) to the right file, for SPL/TPL instead. do you already have patches for converting stuff like CONFIG_SPL_BSS_START_ADDR prepared? Than I would wait with the pull request until those patches are applied to mainline and I would adapt the MT7621 patches. I could also assist with converting CONFIG_SPL_START_S_PATH because that's only used on MIPS and one ARM board. -- - Daniel
[PULL] u-boot-mips for u-boot/next (v2022.10)
Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12656 Azure: https://dev.azure.com/danielschwierzeck/u-boot/_build/results?buildId=30=results The following changes since commit 2d2c61ff0460740d9ec5a44dbef9255a8c690696: Merge tag 'efi-2022-07-rc7' of https://source.denx.de/u-boot/custodians/u-boot-efi (2022-07-06 09:17:08 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-mips.git/ tags/mips-pull-2022-07-08 for you to fetch changes up to e5fc4022af3cfd59e3459276305671a595ac5ff0: MAINTAINERS: update maintainer for MediaTek MIPS platform (2022-07-08 15:13:29 +0200) - MIPS: add drivers and board support for Mediatek MT7621 SoC Weijie Gao (25): mips: add asm/mipsmtregs.h for MIPS multi-threading mips: add more definitions for asm/cm.h mips: add __image_copy_len for SPL linker script mips: add support for noncached_alloc() mips: mtmips: add support for MediaTek MT7621 SoC mips: mtmips: add two reference boards for mt7621 doc: mediatek: add documentation for mt7621 reference boards clk: mtmips: add clock driver for MediaTek MT7621 SoC reset: mtmips: add reset controller support for MediaTek MT7621 SoC pinctrl: mtmips: add support for MediaTek MT7621 SoC usb: xhci-mtk: add support for MediaTek MT7621 SoC phy: mtk-tphy: add support for MediaTek MT7621 SoC spi: add support for MediaTek MT7621 SoC gpio: add support for MediaTek MT7621 SoC watchdog: add support for MediaTek MT7621 SoC mmc: mediatek: add support for MediaTek MT7621 SoC net: mediatek: remap iobase address net: mediatek: use regmap api to modify ethsys registers net: mediatek: add support for MediaTek MT7621 SoC nand: raw: add support for MediaTek MT7621 SoC spl: allow using nand base without standard nand driver spl: spl_legacy: fix the use of SPL_COPY_PAYLOAD_ONLY spl: nand: support loading legacy image with payload compressed tools: mtk_image: add support for MT7621 NAND images MAINTAINERS: update maintainer for MediaTek MIPS platform MAINTAINERS|8 + arch/mips/cpu/u-boot-spl.lds |3 + arch/mips/dts/Makefile |2 + arch/mips/dts/mediatek,mt7621-nand-rfb.dts | 67 ++ arch/mips/dts/mediatek,mt7621-rfb.dts | 82 ++ arch/mips/dts/mt7621-u-boot.dtsi | 111 +++ arch/mips/dts/mt7621.dtsi | 349 +++ arch/mips/include/asm/cm.h | 67 ++ arch/mips/include/asm/mipsmtregs.h | 142 +++ arch/mips/include/asm/system.h | 20 + arch/mips/lib/cache.c | 43 + arch/mips/mach-mtmips/Kconfig | 49 +- arch/mips/mach-mtmips/Makefile |4 + arch/mips/mach-mtmips/cpu.c|2 +- arch/mips/mach-mtmips/mt7621/Kconfig | 115 +++ arch/mips/mach-mtmips/mt7621/Makefile | 14 + arch/mips/mach-mtmips/mt7621/init.c| 246 + arch/mips/mach-mtmips/mt7621/mt7621.h | 229 + arch/mips/mach-mtmips/mt7621/serial.c | 23 + arch/mips/mach-mtmips/mt7621/spl/Makefile |9 + arch/mips/mach-mtmips/mt7621/spl/cps.c | 153 +++ arch/mips/mach-mtmips/mt7621/spl/dram.c| 153 +++ arch/mips/mach-mtmips/mt7621/spl/dram.h| 39 + arch/mips/mach-mtmips/mt7621/spl/launch.c | 100 ++ arch/mips/mach-mtmips/mt7621/spl/launch.h | 52 + arch/mips/mach-mtmips/mt7621/spl/launch_ll.S | 339 +++ arch/mips/mach-mtmips/mt7621/spl/serial.c | 24 + arch/mips/mach-mtmips/mt7621/spl/spl.c | 95 ++ arch/mips/mach-mtmips/mt7621/spl/start.S | 226 + arch/mips/mach-mtmips/mt7621/sram_init.S | 22 + arch/mips/mach-mtmips/mt7621/tpl/Makefile |4 + arch/mips/mach-mtmips/mt7621/tpl/start.S | 161 arch/mips/mach-mtmips/mt7621/tpl/tpl.c | 144 +++ board/mediatek/mt7621/MAINTAINERS |8 + board/mediatek/mt7621/Makefile |3 + board/mediatek/mt7621/board.c |6 + common/spl/Kconfig |2 +- common/spl/spl_legacy.c| 21 +- common/spl/spl_nand.c | 27 + configs/mt7621_nand_rfb_defconfig | 85 ++ configs/mt7621_rfb_defconfig | 82 ++ doc/board/index.rst|1 + doc/board/mediatek/index.rst |9 + doc/board/mediatek/mt7621.rst | 48 + drivers/clk/mtmips/Makefile|1 + drivers/clk/mtmips/clk-mt7621.c| 288 ++
Re: [PATCH v6 00/25] Add support for MediaTek MT7621 SoC - v6
/spl_nand.c | 27 + configs/mt7621_nand_rfb_defconfig | 83 ++ configs/mt7621_rfb_defconfig | 82 ++ doc/board/mediatek/mt7621.rst | 48 + drivers/clk/mtmips/Makefile |1 + drivers/clk/mtmips/clk-mt7621.c | 288 drivers/gpio/Kconfig |2 +- drivers/mmc/mtk-sd.c | 13 + drivers/mtd/nand/raw/Kconfig | 17 +- drivers/mtd/nand/raw/Makefile |2 + drivers/mtd/nand/raw/mt7621_nand.c| 1205 + drivers/mtd/nand/raw/mt7621_nand.h| 29 + drivers/mtd/nand/raw/mt7621_nand_spl.c| 237 drivers/net/mtk_eth.c | 45 +- drivers/phy/Kconfig |2 +- drivers/pinctrl/mtmips/Kconfig|9 + drivers/pinctrl/mtmips/Makefile |1 + drivers/pinctrl/mtmips/pinctrl-mt7621.c | 306 + .../pinctrl/mtmips/pinctrl-mtmips-common.c|4 +- .../pinctrl/mtmips/pinctrl-mtmips-common.h| 12 + drivers/spi/Kconfig |2 +- drivers/usb/host/Kconfig |2 +- drivers/watchdog/Kconfig |2 +- include/configs/mt7621.h | 67 + include/dt-bindings/clock/mt7621-clk.h| 46 + include/dt-bindings/reset/mt7621-reset.h | 38 + tools/mtk_image.c | 182 +++ tools/mtk_image.h | 24 + 66 files changed, 5877 insertions(+), 36 deletions(-) create mode 100644 arch/mips/dts/mediatek,mt7621-nand-rfb.dts create mode 100644 arch/mips/dts/mediatek,mt7621-rfb.dts create mode 100644 arch/mips/dts/mt7621-u-boot.dtsi create mode 100644 arch/mips/dts/mt7621.dtsi create mode 100644 arch/mips/include/asm/mipsmtregs.h create mode 100644 arch/mips/mach-mtmips/mt7621/Kconfig create mode 100644 arch/mips/mach-mtmips/mt7621/Makefile create mode 100644 arch/mips/mach-mtmips/mt7621/init.c create mode 100644 arch/mips/mach-mtmips/mt7621/mt7621.h create mode 100644 arch/mips/mach-mtmips/mt7621/serial.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/Makefile create mode 100644 arch/mips/mach-mtmips/mt7621/spl/cps.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/dram.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/dram.h create mode 100644 arch/mips/mach-mtmips/mt7621/spl/launch.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/launch.h create mode 100644 arch/mips/mach-mtmips/mt7621/spl/launch_ll.S create mode 100644 arch/mips/mach-mtmips/mt7621/spl/serial.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/spl.c create mode 100644 arch/mips/mach-mtmips/mt7621/spl/start.S create mode 100644 arch/mips/mach-mtmips/mt7621/sram_init.S create mode 100644 arch/mips/mach-mtmips/mt7621/tpl/Makefile create mode 100644 arch/mips/mach-mtmips/mt7621/tpl/start.S create mode 100644 arch/mips/mach-mtmips/mt7621/tpl/tpl.c create mode 100644 board/mediatek/mt7621/MAINTAINERS create mode 100644 board/mediatek/mt7621/Makefile create mode 100644 board/mediatek/mt7621/board.c create mode 100644 configs/mt7621_nand_rfb_defconfig create mode 100644 configs/mt7621_rfb_defconfig create mode 100644 doc/board/mediatek/mt7621.rst create mode 100644 drivers/clk/mtmips/clk-mt7621.c create mode 100644 drivers/mtd/nand/raw/mt7621_nand.c create mode 100644 drivers/mtd/nand/raw/mt7621_nand.h create mode 100644 drivers/mtd/nand/raw/mt7621_nand_spl.c create mode 100644 drivers/pinctrl/mtmips/pinctrl-mt7621.c create mode 100644 include/configs/mt7621.h create mode 100644 include/dt-bindings/clock/mt7621-clk.h create mode 100644 include/dt-bindings/reset/mt7621-reset.h series applied to u-boot-mips/next, thanks. -- - Daniel
Re: [PATCH v6 00/25] Add support for MediaTek MT7621 SoC - v6
Hi Weijie, On 20.05.22 05:21, Weijie Gao wrote: This series will add support for MediaTek MT7621 SoC with two reference boards and related drivers. The MediaTek MT7621 is a network processor integrating a dual-core dual-threaded MIPS 1004Kc processor running at a normal frequency of 880MHz. This chip can be found in many wireless routers. This series add all basic drivers which are useful in u-boot, like usb, sdxc, ethernet, spi, nand and serial. Building the u-boot requires external binary blob which is described in doc/board/mediatek/mt7621.rst Thanks, Weijie I applied v6 to u-boot-mips/next for the upcoming merge window. I needed to add some fixups to make CI happy. Could you check if the changes are okay, especially the Kconfig migration of CONFIG_SYS_NAND_U_BOOT_OFFS? https://source.denx.de/u-boot/custodians/u-boot-mips/-/commits/next/ https://source.denx.de/u-boot/custodians/u-boot-mips/-/pipelines/12637 Thanks, Daniel
