[PATCH 0/4] bootstd: Test and boot_targets improvements
This series makes another attempt to support things like "mmc" in the boot_targets variable. The previous attempt introduced a bug which made iteration fail. New test coverage is provided for some previously untested behaviour, to prevent regressions. Simon Glass (4): Revert "bootstd: Scan all bootdevs in a boot_targets entry" bootstd: Expand boot-ordering test to include USB bootstd: Correct logic for single uclass bootstd: Scan all bootdevs in a boot_targets entry (take 2) boot/bootflow.c | 29 test/boot/bootdev.c | 54 - 2 files changed, 73 insertions(+), 10 deletions(-) -- 2.42.0.655.g421f12c284-goog
[PATCH v4 0/4] fix npcm bmc error
1. Add name for gpio pinctrl function 2. Add baud rate table 3. Fix ecc ram size - ECC ram size - Fix wrong place to set dram bank size 4. Modify configs Jim Liu (4): pinctrl: npcm8xx: add name for gpio function configs: npcm: support more uart baud rate board: nuvuton: arbel: fix incorrect ram size configs: nuvoton: npcm8xx: disable CONFIG_SPI_FLASH_USE_4K_SECTORS board/nuvoton/arbel_evb/arbel_evb.c | 36 +++ configs/arbel_evb_defconfig | 1 + drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c | 1 + include/configs/arbel.h | 5 +++- include/configs/poleg.h | 2 ++ 5 files changed, 26 insertions(+), 19 deletions(-) -- 2.25.1
[PATCH v4 1/4] pinctrl: npcm8xx: Add name for gpio function
GPIO function name is needed in the debug log
Signed-off-by: Jim Liu
Changes for v2:
- add commit message
Changes for v3:
- no change
Changes for v4:
- no change
---
drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
index 7976e3b3ed..ff49819b58 100644
--- a/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
+++ b/drivers/pinctrl/nuvoton/pinctrl-npcm8xx.c
@@ -329,6 +329,7 @@ struct group_info {
static const struct group_info npcm8xx_groups[] = {
FUNC_LIST
+ {FN_gpio, "GPIO", NULL, 0, 0, 0}
};
/* Pin flags */
--
2.25.1
[PATCH v4 2/4] configs: npcm: Support more uart baud rate
Add uart baud rate table to arbel(npcm8xx) and poleg(npcm7xx)
Signed-off-by: Jim Liu
Changes for v2:
- Add commit message
Changes for v3:
- Modify CONFIG_SYS_BAUDRATE_TABLE
Changes for v4:
- No change
---
include/configs/arbel.h | 5 -
include/configs/poleg.h | 2 ++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/configs/arbel.h b/include/configs/arbel.h
index 891257bc93..29010503d3 100644
--- a/include/configs/arbel.h
+++ b/include/configs/arbel.h
@@ -7,11 +7,14 @@
#define __CONFIG_ARBEL_H
#define CFG_SYS_SDRAM_BASE 0x0
-#define CFG_SYS_BOOTMAPSZ (30 << 20)
+#define CFG_SYS_BOOTMAPSZ (128 << 20)
#define CFG_SYS_BOOTM_LEN (20 << 20)
#define CFG_SYS_INIT_RAM_ADDR CFG_SYS_SDRAM_BASE
#define CFG_SYS_INIT_RAM_SIZE 0x8000
+#define CFG_SYS_BAUDRATE_TABLE { 9600, 14400, 19200, 38400, 57600, 115200,
230400, \ 380400, 460800, 921600 }
+
+
/* Default environemnt variables */
#define CFG_EXTRA_ENV_SETTINGS "uimage_flash_addr=8040\0" \
"stdin=serial\0" \
diff --git a/include/configs/poleg.h b/include/configs/poleg.h
index 1e96e838be..2a2d85c8ec 100644
--- a/include/configs/poleg.h
+++ b/include/configs/poleg.h
@@ -13,6 +13,8 @@
#define CFG_SYS_BOOTMAPSZ(0x30 << 20)
#define CFG_SYS_SDRAM_BASE 0x0
+#define CFG_SYS_BAUDRATE_TABLE { 57600, 115200, 230400, 460800 }
+
/* Default environemnt variables */
#define CFG_EXTRA_ENV_SETTINGS "uimage_flash_addr=8020\0" \
"stdin=serial\0" \
--
2.25.1
[PATCH v4 3/4] board: nuvuton: arbel: Fix incorrect ram size
1. Fix incorrect ram size of 4GB dram with ECC enabled
2. Fix wrong place to set dram bank size
- The dram bank size should be set in dram_init_banksize
- Dram_init should not access gd->bd because the board info
struct is not reserved yet.
Signed-off-by: Jim Liu
Changes for v2:
- add commit message
Changes for v3:
- no change
Changes for v4:
- Add Fix wrong place to set dram bank size
---
board/nuvoton/arbel_evb/arbel_evb.c | 36 ++---
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/board/nuvoton/arbel_evb/arbel_evb.c
b/board/nuvoton/arbel_evb/arbel_evb.c
index e52e0a59ab..8516a37b78 100644
--- a/board/nuvoton/arbel_evb/arbel_evb.c
+++ b/board/nuvoton/arbel_evb/arbel_evb.c
@@ -16,7 +16,7 @@
#define DRAM_1GB_SIZE 0x4000ULL
#define DRAM_2GB_ECC_SIZE 0x7000ULL
#define DRAM_2GB_SIZE 0x8000ULL
-#define DRAM_4GB_ECC_SIZE 0xEULL
+#define DRAM_4GB_ECC_SIZE 0xE000ULL
#define DRAM_4GB_SIZE 0x1ULL
DECLARE_GLOBAL_DATA_PTR;
@@ -29,7 +29,6 @@ int board_init(void)
int dram_init(void)
{
struct npcm_gcr *gcr = (struct npcm_gcr *)NPCM_GCR_BA;
- uint64_t delta = 0ULL;
/*
* get dram active size value from bootblock.
@@ -38,18 +37,23 @@ int dram_init(void)
*/
gd->ram_size = readl(&gcr->scrpad_c);
- debug("%s: scrpad_c: %llx ", __func__, gd->ram_size);
if (gd->ram_size == 0) {
gd->ram_size = readl(&gcr->scrpad_b);
- debug("%s: scrpad_b: %llx ", __func__, gd->ram_size);
- } else {
+ else
gd->ram_size *= 0x10ULL;
}
- gd->bd->bi_dram[0].start = 0;
debug("ram_size: %llx ", gd->ram_size);
+ return 0;
+}
+
+int dram_init_banksize(void)
+{
+
+ gd->bd->bi_dram[0].start = 0;
+
switch (gd->ram_size) {
case DRAM_512MB_ECC_SIZE:
case DRAM_512MB_SIZE:
@@ -62,32 +66,28 @@ int dram_init(void)
gd->bd->bi_dram[1].size = 0;
break;
case DRAM_4GB_ECC_SIZE:
- gd->bd->bi_dram[0].size = DRAM_2GB_ECC_SIZE;
+ gd->bd->bi_dram[0].size = DRAM_2GB_SIZE;
gd->bd->bi_dram[1].start = DRAM_4GB_SIZE;
- gd->bd->bi_dram[1].size = DRAM_2GB_SIZE;
- delta = DRAM_4GB_SIZE - DRAM_2GB_ECC_SIZE;
+ gd->bd->bi_dram[1].size = DRAM_2GB_SIZE -
+ (DRAM_4GB_SIZE - DRAM_4GB_ECC_SIZE);
+ /* use bank0 only */
+ gd->ram_size = DRAM_2GB_SIZE;
break;
case DRAM_4GB_SIZE:
gd->bd->bi_dram[0].size = DRAM_2GB_SIZE;
gd->bd->bi_dram[1].start = DRAM_4GB_SIZE;
gd->bd->bi_dram[1].size = DRAM_2GB_SIZE;
- delta = DRAM_4GB_SIZE - DRAM_2GB_SIZE;
+ /* use bank0 only */
+ gd->ram_size = DRAM_2GB_SIZE;
break;
default:
gd->bd->bi_dram[0].size = DRAM_1GB_SIZE;
gd->bd->bi_dram[1].start = 0;
gd->bd->bi_dram[1].size = 0;
+ gd->ram_size = DRAM_1GB_SIZE;
break;
}
- gd->ram_size -= delta;
-
return 0;
}
-int dram_init_banksize(void)
-{
- dram_init();
-
- return 0;
-}
--
2.25.1
[PATCH v4 4/4] configs: nuvoton: npcm8xx: Disable CONFIG_SPI_FLASH_USE_4K_SECTORS
disable this config to improve flash program time Signed-off-by: Jim Liu Changes for v2: - add commit message Changes for v3: - no change Changes for v4: - no change --- configs/arbel_evb_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/arbel_evb_defconfig b/configs/arbel_evb_defconfig index 8c32b4b20d..6cfb5a7d32 100644 --- a/configs/arbel_evb_defconfig +++ b/configs/arbel_evb_defconfig @@ -58,6 +58,7 @@ CONFIG_MMC_SDHCI_NPCM=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_WINBOND=y +# CONFIG_SPI_FLASH_USE_4K_SECTORS is not set CONFIG_PHY_BROADCOM=y CONFIG_PHY_GIGE=y CONFIG_ETH_DESIGNWARE=y -- 2.25.1
[PATCH 1/4] Revert "bootstd: Scan all bootdevs in a boot_targets entry"
This commit was intended to allow all bootdevs in each boot_targets
entry to be scanned. However it causes bad ordering with bootdevs, e.g.
scanning Ethernet bootdevs when it should be keeping to mmc.
Revert it so we can try another approach.
This reverts commit e824d0d0c219bc6da767f13f90c5b00eefe929f0.
Signed-off-by: Simon Glass
---
boot/bootdev-uclass.c | 3 +--
boot/bootflow.c | 21 ++---
test/boot/bootdev.c | 10 --
3 files changed, 3 insertions(+), 31 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 44ae98a9269c..974ddee5d2fa 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -469,11 +469,10 @@ int bootdev_find_by_label(const char *label, struct
udevice **devp,
* if no sequence number was provided, we must scan all
* bootdevs for this media uclass
*/
- if (seq == -1)
+ if (IS_ENABLED(CONFIG_BOOTSTD_FULL) && seq == -1)
method_flags |= BOOTFLOW_METHF_SINGLE_UCLASS;
if (method_flagsp)
*method_flagsp = method_flags;
- log_debug("method flags %x\n", method_flags);
return 0;
}
log_debug("- no device in %s\n", media->name);
diff --git a/boot/bootflow.c b/boot/bootflow.c
index e03932e65a74..6ef62e1d1896 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -260,25 +260,8 @@ static int iter_incr(struct bootflow_iter *iter)
} else {
log_debug("labels %p\n", iter->labels);
if (iter->labels) {
- /*
-* when the label is "mmc" we want to scan all
-* mmc bootdevs, not just the first. See
-* bootdev_find_by_label() where this flag is
-* set up
-*/
- if (iter->method_flags &
BOOTFLOW_METHF_SINGLE_UCLASS) {
- uclass_next_device(&dev);
- log_debug("looking for next device %s:
%s\n",
- iter->dev->name,
- dev ? dev->name : "");
- } else {
- dev = NULL;
- }
- if (!dev) {
- log_debug("looking at next label\n");
- ret = bootdev_next_label(iter, &dev,
-&method_flags);
- }
+ ret = bootdev_next_label(iter, &dev,
+&method_flags);
} else {
ret = bootdev_next_prio(iter, &dev);
method_flags = 0;
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index c5f14a7a1323..6b29213416db 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -221,16 +221,6 @@ static int bootdev_test_order(struct unit_test_state *uts)
ut_asserteq_str("mmc2.bootdev", iter.dev_used[1]->name);
bootflow_iter_uninit(&iter);
- /* Make sure it scans a bootdevs in each target */
- ut_assertok(env_set("boot_targets", "mmc spi"));
- ut_asserteq(0, bootflow_scan_first(NULL, NULL, &iter, 0, &bflow));
- ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow));
- ut_asserteq(3, iter.num_devs);
- ut_asserteq_str("mmc2.bootdev", iter.dev_used[0]->name);
- ut_asserteq_str("mmc1.bootdev", iter.dev_used[1]->name);
- ut_asserteq_str("mmc0.bootdev", iter.dev_used[2]->name);
- bootflow_iter_uninit(&iter);
-
return 0;
}
BOOTSTD_TEST(bootdev_test_order, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
--
2.42.0.655.g421f12c284-goog
[PATCH 2/4] bootstd: Expand boot-ordering test to include USB
Scan the USB bus as well, so we can check that different uclasses work
correctly in boot_targets
update the function comment with more detail.
Signed-off-by: Simon Glass
---
test/boot/bootdev.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index 6b29213416db..7228f545e9e6 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -190,12 +190,21 @@ static int bootdev_test_any(struct unit_test_state *uts)
BOOTSTD_TEST(bootdev_test_any, UT_TESTF_DM | UT_TESTF_SCAN_FDT |
UT_TESTF_ETH_BOOTDEV);
-/* Check bootdev ordering with the bootdev-order property */
+/*
+ * Check bootdev ordering with the bootdev-order property and boot_targets
+ * environment variable
+ */
static int bootdev_test_order(struct unit_test_state *uts)
{
struct bootflow_iter iter;
struct bootflow bflow;
+ test_set_skip_delays(true);
+
+ /* Start up USB which gives us three additional bootdevs */
+ usb_started = false;
+ ut_assertok(run_command("usb start", 0));
+
/*
* First try the order set by the bootdev-order property
* Like all sandbox unit tests this relies on the devicetree setting up
@@ -213,12 +222,14 @@ static int bootdev_test_order(struct unit_test_state *uts)
bootflow_iter_uninit(&iter);
/* Use the environment variable to override it */
- ut_assertok(env_set("boot_targets", "mmc1 mmc2"));
+ ut_assertok(env_set("boot_targets", "mmc1 mmc2 usb"));
ut_assertok(bootflow_scan_first(NULL, NULL, &iter, 0, &bflow));
ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow));
- ut_asserteq(2, iter.num_devs);
+ ut_asserteq(3, iter.num_devs);
ut_asserteq_str("mmc1.bootdev", iter.dev_used[0]->name);
ut_asserteq_str("mmc2.bootdev", iter.dev_used[1]->name);
+ ut_asserteq_str("usb_mass_storage.lun0.bootdev",
+ iter.dev_used[2]->name);
bootflow_iter_uninit(&iter);
return 0;
--
2.42.0.655.g421f12c284-goog
[PATCH 3/4] bootstd: Correct logic for single uclass
The current logic for "bootflow mmc" is flawed since it checks the
uclass of the bootdev instead of its parent, the media device. Correct
this and add a test that covers this scenario.
Signed-off-by: Simon Glass
---
boot/bootflow.c | 24 ++--
test/boot/bootdev.c | 13 +
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 6ef62e1d1896..7f5b0e942078 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -155,6 +155,27 @@ static void bootflow_iter_set_dev(struct bootflow_iter
*iter,
}
}
+/**
+ * scan_next_in_uclass() - Scan for the next bootdev in the same media uclass
+ *
+ * Move through the following bootdevs until we find another in this media
+ * uclass, or run out
+ *
+ * @devp: On entry, the device to check, on exit the new device, or NULL if
+ * there is none
+ */
+static void scan_next_in_uclass(struct udevice **devp)
+{
+ struct udevice *dev = *devp;
+ enum uclass_id cur_id = device_get_uclass_id(dev->parent);
+
+ do {
+ uclass_find_next_device(&dev);
+ } while (dev && cur_id != device_get_uclass_id(dev->parent));
+
+ *devp = dev;
+}
+
/**
* iter_incr() - Move to the next item (method, part, bootdev)
*
@@ -230,8 +251,7 @@ static int iter_incr(struct bootflow_iter *iter)
&method_flags);
} else if (IS_ENABLED(CONFIG_BOOTSTD_FULL) &&
(iter->flags & BOOTFLOWIF_SINGLE_UCLASS)) {
- /* Move to the next bootdev in this uclass */
- uclass_find_next_device(&dev);
+ scan_next_in_uclass(&dev);
if (!dev) {
log_debug("finished uclass %s\n",
dev_get_uclass_name(dev));
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index 7228f545e9e6..637861748057 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -232,6 +232,19 @@ static int bootdev_test_order(struct unit_test_state *uts)
iter.dev_used[2]->name);
bootflow_iter_uninit(&iter);
+ /* Try a single uclass */
+ ut_assertok(env_set("boot_targets", NULL));
+ ut_assertok(bootflow_scan_first(NULL, "mmc", &iter, 0, &bflow));
+ ut_asserteq(2, iter.num_devs);
+
+ /* Now scan pass mmc1 and make sure that only mmc0 shows up */
+ ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow));
+ ut_asserteq(3, iter.num_devs);
+ ut_asserteq_str("mmc2.bootdev", iter.dev_used[0]->name);
+ ut_asserteq_str("mmc1.bootdev", iter.dev_used[1]->name);
+ ut_asserteq_str("mmc0.bootdev", iter.dev_used[2]->name);
+ bootflow_iter_uninit(&iter);
+
return 0;
}
BOOTSTD_TEST(bootdev_test_order, UT_TESTF_DM | UT_TESTF_SCAN_FDT);
--
2.42.0.655.g421f12c284-goog
[PATCH 4/4] bootstd: Scan all bootdevs in a boot_targets entry (take 2)
When the boot_targets environment variable is used with the distro-boot
scripts, each device is included individually. For example, if there
are three mmc devices, then we will have something like:
boot_targets="mmc0 mmc1 mmc2"
In contrast, standard boot supports specifying just the uclass, i.e.:
boot_targets="mmc"
The intention is that this should scan all MMC devices, but in fact it
currently only scans the first.
Update the logic to handle this case, without required BOOTSTD_FULL to
be enabled.
Signed-off-by: Simon Glass
Reported-by: Date Huang
Reported-by: Vincent Stehlé
Reported-by: Ivan Ivanov
---
boot/bootdev-uclass.c | 3 ++-
boot/bootflow.c | 22 --
test/boot/bootdev.c | 32 ++--
3 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/boot/bootdev-uclass.c b/boot/bootdev-uclass.c
index 974ddee5d2fa..44ae98a9269c 100644
--- a/boot/bootdev-uclass.c
+++ b/boot/bootdev-uclass.c
@@ -469,10 +469,11 @@ int bootdev_find_by_label(const char *label, struct
udevice **devp,
* if no sequence number was provided, we must scan all
* bootdevs for this media uclass
*/
- if (IS_ENABLED(CONFIG_BOOTSTD_FULL) && seq == -1)
+ if (seq == -1)
method_flags |= BOOTFLOW_METHF_SINGLE_UCLASS;
if (method_flagsp)
*method_flagsp = method_flags;
+ log_debug("method flags %x\n", method_flags);
return 0;
}
log_debug("- no device in %s\n", media->name);
diff --git a/boot/bootflow.c b/boot/bootflow.c
index 7f5b0e942078..be543c8588cc 100644
--- a/boot/bootflow.c
+++ b/boot/bootflow.c
@@ -280,8 +280,26 @@ static int iter_incr(struct bootflow_iter *iter)
} else {
log_debug("labels %p\n", iter->labels);
if (iter->labels) {
- ret = bootdev_next_label(iter, &dev,
-&method_flags);
+ /*
+* when the label is "mmc" we want to scan all
+* mmc bootdevs, not just the first. See
+* bootdev_find_by_label() where this flag is
+* set up
+*/
+ if (iter->method_flags &
+ BOOTFLOW_METHF_SINGLE_UCLASS) {
+ scan_next_in_uclass(&dev);
+ log_debug("looking for next device %s:
%s\n",
+ iter->dev->name,
+ dev ? dev->name : "");
+ } else {
+ dev = NULL;
+ }
+ if (!dev) {
+ log_debug("looking at next label\n");
+ ret = bootdev_next_label(iter, &dev,
+&method_flags);
+ }
} else {
ret = bootdev_next_prio(iter, &dev);
method_flags = 0;
diff --git a/test/boot/bootdev.c b/test/boot/bootdev.c
index 637861748057..0702fccdae60 100644
--- a/test/boot/bootdev.c
+++ b/test/boot/bootdev.c
@@ -225,7 +225,7 @@ static int bootdev_test_order(struct unit_test_state *uts)
ut_assertok(env_set("boot_targets", "mmc1 mmc2 usb"));
ut_assertok(bootflow_scan_first(NULL, NULL, &iter, 0, &bflow));
ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow));
- ut_asserteq(3, iter.num_devs);
+ ut_asserteq(5, iter.num_devs);
ut_asserteq_str("mmc1.bootdev", iter.dev_used[0]->name);
ut_asserteq_str("mmc2.bootdev", iter.dev_used[1]->name);
ut_asserteq_str("usb_mass_storage.lun0.bootdev",
@@ -237,7 +237,20 @@ static int bootdev_test_order(struct unit_test_state *uts)
ut_assertok(bootflow_scan_first(NULL, "mmc", &iter, 0, &bflow));
ut_asserteq(2, iter.num_devs);
- /* Now scan pass mmc1 and make sure that only mmc0 shows up */
+ /* Now scan past mmc1 and make sure that only mmc0 shows up */
+ ut_asserteq(-ENODEV, bootflow_scan_next(&iter, &bflow));
+ ut_asserteq(3, iter.num_devs);
+ ut_asserteq_str("mmc2.bootdev", iter.dev_used[0]->name);
+ ut_asserteq_str("mmc1.bootdev", iter.dev_used[1]->name);
+ ut_asserteq_str("mmc0.bootdev", iter.dev_used[2]->name);
+ bootflow_iter_uninit(&iter);
+
+ /* Try a single uclass with boot_targets */
+ ut_assertok(env_set("boot
Re: [PATCH] smbios: arm64: Allow table to be written at a fixed addr
Hi Caleb,
On Sat, 21 Oct 2023 at 01:43, Caleb Connolly wrote:
>
> Hi Simon,
>
> On 21/10/2023 01:45, Simon Glass wrote:
> > U-Boot typically sets up its malloc() pool near the top of memory. On
> > ARM64 systems this can result in an SMBIOS table above 4GB which is
> > not supported by SMBIOSv2.
> >
> > Work around this problem by providing a new option to choose an address
> > just below 4GB, if needed.
> I may well be missing something here, but I don't quite understand the
> justification behind the original patch [1] which caused this regression.
>
> I'm currently preparing support for a few different Qualcomm boards
> which have different memory layouts, so far it's been possible to avoid
> having any fixed addresses, so the same u-boot image can be used on all
> of them (with just a different DTB).
What sort of memory layout do you have? I could enhance the patch to
find the top of a memory bank below 4GB, perhaps? E.g. see the
'bdinfo' command.
>
> As I mentioned before, efi_allocate_pages() seems to work fine from
> install_smbios_table(), I haven't delved into the code too much but I
> wonder if this could be an acceptable solution?
Unfortunately that function is EFI-specific. The function can only be
called once EFI is inited. We only want to do that if booting with
EFI.
The tables are written at the start of U-Boot, partly because that is
how it is done on x86 and partly so the 'acpi' command actually works.
The EFI code ended up writing a separate set of tables, which is of
course not correct.
I did look at creating an API in U-Boot to alloc memory below 4GB but
then decided that for just this one use case it might not be worth it.
>
> Barring that, could we use an environment variable to pass this address
> in? Although I think that might not be a very desirable solution.
>
> I appreciate you taking the time to prepare this patch and CC me. If
> nobody else objects to this patch then I'd prefer to avoid blocking it.
> In either case, I'd greatly appreciate any input on the above
> suggestions so that I can implement a solution for my boards.
I would like it to be automatic. I assumed on ARM64 that there is
memory available at 3.99GB if U-Boot has relocated to above 4GB, but
as above I could make this more clever.
Regards,
Simon
>
> Thanks and regards,
>
> [1]:
> https://lore.kernel.org/u-boot/20230920030027.1385833-16-...@chromium.org/
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > lib/Kconfig | 17 +
> > lib/efi_loader/efi_smbios.c | 12
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/lib/Kconfig b/lib/Kconfig
> > index f6ca559897e7..a77f2f3e9089 100644
> > --- a/lib/Kconfig
> > +++ b/lib/Kconfig
> > @@ -994,6 +994,23 @@ config GENERATE_SMBIOS_TABLE
> > See also SMBIOS_SYSINFO which allows SMBIOS values to be provided in
> > the devicetree.
> >
> > +config SMBIOS_TABLE_FIXED
> > + bool "Place the SMBIOS table at a special address"
> > + depends on GENERATE_SMBIOS_TABLE && ARM64 && SMBIOS && EFI_LOADER
> > + default y
> > + help
> > + Use this option to place the SMBIOS table at a fixed address.
> > +
> > + U-Boot typically sets up its malloc() pool near the top of memory.
> > On
> > + ARM64 systems this can result in an SMBIOS table above 4GB which is
> > + not supported by SMBIOSv2. This option works around this problem by
> > + chosing an address just below 4GB, if needed.
> > +
> > +config SMBIOS_TABLE_FIXED_ADDR
> > + hex "Fixed address for use for SMBIOS table"
> > + depends on SMBIOS_TABLE_FIXED
> > + default 0x
> > +
> > endmenu
> >
> > config LIB_RATIONAL
> > diff --git a/lib/efi_loader/efi_smbios.c b/lib/efi_loader/efi_smbios.c
> > index 48446f654d9b..84ea027ea48c 100644
> > --- a/lib/efi_loader/efi_smbios.c
> > +++ b/lib/efi_loader/efi_smbios.c
> > @@ -61,6 +61,18 @@ static int install_smbios_table(void)
> > return log_msg_ret("mem", -ENOMEM);
> >
> > addr = map_to_sysmem(buf);
> > +
> > + /*
> > + * Deal with a fixed address if needed. For simplicity we assume that
> > + * the SMBIOS-table size is <64KB and that the malloc region does not
> > + * straddle the 4GB boundary.
> > + */
> > + if (IS_ENABLED(CONFIG_SMBIOS_TABLE_FIXED) && addr >= SZ_4G - SZ_64K) {
> > + addr = IF_ENABLED_INT(CONFIG_SMBIOS_TABLE_FIXED,
> > + CONFIG_SMBIOS_TABLE_FIXED_ADDR);
> > + log_warning("Forcing SMBIOS table to address %lx\n", addr);
> > + }
> > +
> > if (!write_smbios_table(addr)) {
> > log_err("Failed to write SMBIOS table\n");
> > return log_msg_ret("smbios", -EINVAL);
>
> --
> // Caleb (they/them)
Re: [PATCH 1/1] efi_loader: fix efi_dp_from_eth
On Sat, 21 Oct 2023 at 23:20, Heinrich Schuchardt wrote: > > When compiling the sandbox with CONFIG_LTO=n, CONFIG_NET=n an error is > reported: > > /usr/bin/ld: lib/efi_loader/efi_device_path.o: > in function `efi_dp_from_eth': > lib/efi_loader/efi_device_path.c:985:(.text+0xcf4): > undefined reference to `eth_get_dev' > > Add a missing configuration check. > > As the function is exported __maybe_unused can be removed. > > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_loader/efi_device_path.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 1/1] general: fix GPL-2.0-or-later SPDX headers
Hi Heinrich, On Sun, 22 Oct 2023 at 10:48, Heinrich Schuchardt wrote: > > SPDX headers should use GPL-2.0-or-later and not GPL-2.0+. > > Signed-off-by: Heinrich Schuchardt > --- > Makefile | 2 +- > README | 2 +- > api/Makefile | 2 +- > api/api.c | 2 +- > api/api_display.c | 2 +- > api/api_net.c | 2 +- > api/api_platform-arm.c | 2 +- > api/api_platform-mips.c| 2 +- In License/README it shows the identifier as 'GPL-2.0+'. Regards, simon
Re: [PATCH] mmc: tmio: Disable 1/1024 clock divider on Renesas R-Car platforms
On Sun, Oct 22, 2023 at 11:40:43PM +0200, Marek Vasut wrote:
> The R-Car Gen3 SD_CLK_CTRL register does not use BIT(16) to implement
> divider 1/1024, instead BIT(16) is reserved bit and divider 1/1024 is
> not supported. The divider 1/1024 is specific to Socionext variant of
> the IP, as is indicated by Linux commit:
>
> 0196c8db8363 ("mmc: tmio: move tmio_mmc_set_clock() to platform hook")
> "
> Socionext (and Panasonic) uses bit 10 (CLKSEL) for 1/1. Also, newer
> versions of UniPhier SoC variants use bit 16 for 1/1024.
> "
>
> Do not set the TMIO_SD_CAP_DIV1024 on Renesas R-Car platforms even if
> the IP VERSION register does exist, and indicates IP version is newer
> or equal to version 1.0 . The IP version 1.0 or newer does not imply
> presence of the 1/1024 divider.
>
> Since the TMIO driver is used exactly by two supported platforms, that
> is Renesas R-Car and Socionext UniPhier, it is OK to check whether the
> TMIO_SD_CAP_RCAR capability is not set to identify the UniPhier platform
> and add the capability only on that platform.
>
> Fixes: 58c35b17aa8f ("mmc: matsushita-common: Always check controller
> version")
> Signed-off-by: Marek Vasut
I've confirmed that the 1/1024 divider doesn't exist in the RZ/G2L
datasheet.
Acked-by: Paul Barker
signature.asc
Description: PGP signature
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
Hi Tom, On Sun, 22 Oct 2023 at 16:45, Tom Rini wrote: > > On Sun, Oct 22, 2023 at 02:55:32PM -0700, Simon Glass wrote: > > Hi, > > > > On Sun, 22 Oct 2023 at 07:59, Tom Rini wrote: > > > > > > On Sun, Oct 22, 2023 at 10:29:22AM -0400, Tom Rini wrote: > > > > On Sun, Oct 22, 2023 at 08:08:11AM +0200, Heinrich Schuchardt wrote: > > > > > On 10/21/23 20:26, Tom Rini wrote: > > > > > > On Sat, Oct 21, 2023 at 08:43:08AM -0700, Simon Glass wrote: > > > > > > > Hi, > > > > > > > > > > > > > > On Thu, 19 Oct 2023 at 17:30, AKASHI Takahiro > > > > > > > wrote: > > > > > > > > > > > > > > > > On Thu, Oct 19, 2023 at 08:01:11AM -0600, Simon Glass wrote: > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > > > On Wed, 18 Oct 2023 at 06:55, Heinrich Schuchardt > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On 10/17/23 16:09, Tom Rini wrote: > > > > > > > > > > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Since efi_device_path.c calls eth_get_dev() and assumes > > > > > > > > > > > > that Ethernet is > > > > > > > > > > > > available, add it as an explicit dependency. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > (no changes since v2) > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > - Add new patch to update EFI_LOADER to depend on DM_ETH > > > > > > > > > > > > > > > > > > > > > > > >lib/efi_loader/Kconfig | 1 + > > > > > > > > > > > >1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig > > > > > > > > > > > > b/lib/efi_loader/Kconfig > > > > > > > > > > > > index 13cad6342c36..fca4b3eef270 100644 > > > > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > > > > @@ -11,6 +11,7 @@ config EFI_LOADER > > > > > > > > > > > > # We need EFI_STUB_32BIT to be set on x86_32 with > > > > > > > > > > > > EFI_STUB > > > > > > > > > > > > depends on !EFI_STUB || !X86 || X86_64 || > > > > > > > > > > > > EFI_STUB_32BIT > > > > > > > > > > > > depends on BLK > > > > > > > > > > > > +depends on DM_ETH > > > > > > > > > > > > depends on !EFI_APP > > > > > > > > > > > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU = > > > > > > > > > > > > armv8 > > > > > > > > > > > > select CHARSET > > > > > > > > > > > > > > > > > > > > > > Does this work for you Heinrich, or do you want to > > > > > > > > > > > clarify the > > > > > > > > > > > dependencies (and re-organize the code as needed) around > > > > > > > > > > > networking? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We should be able to boot via EFI on devices without U-Boot > > > > > > > > > > network support. > > > > > > > > > > > > > > > > > > > > We already use IS_ENABLED(CONFIG_NETDEVICES) to avoid > > > > > > > > > > invoking > > > > > > > > > > eth_get_dev() if there is no network. CONFIG_NETDEVICES=y > > > > > > > > > > selects > > > > > > > > > > CONFIG_DM_ETH. > > > > > > > > > > > > > > > > > > > > Why is this not sufficient? > > > > > > > > > > Is there a configuration that does not build? > > > > > > > > > > > > > > > > > > The point of this series is to disable CMDLINE and fix up > > > > > > > > > what breaks. > > > > > > > > > > > > > > > > > > In this case we have some sort of breakage...perhaps Tom has > > > > > > > > > already > > > > > > > > > found it, but otherwise could you take a look? > > > > > > > > > > > > > > > > > > We should be able to disable NET and LTO in sandbox and still > > > > > > > > > build. > > > > > > > > > But this fails at present[1]. You can try it on -master > > > > > > > > > > > > > > > > Obviously, it would be necessary to enclose efi_dp_from_eth() > > > > > > > > with "if defined(CONFIG_NETDEVICES)" (or DM_ETH). > > > > > > > > Then, we could drop "depends on DM_ETH". > > > > > > > > > > > > > > Strange that it only happens on the non-LTO board, though? > > > > > > > > > > > > There's two issues. The first of which is that I think you need to > > > > > > re-check your error exactly? With my series, and LTO also disabled > > > > > > the > > > > > > problem is a call to efi_get_image_parameters() as that's defined in > > > > > > cmd/bootefi.c, but also only used with cmdline invocations. So we > > > > > > can > > > > > > fix that CMDLINE=n && LTO=n case with a IS_ENABLED(CONFIG_CMDLINE) > > > > > > around that, and then discard efi_dp_from_name() entirely. > > > > > > > > > > > > The second issue is that with LTO we more completely find the cases > > > > > > where if x() calls y() and y() is undefined but nothing calls x() > > > > > > we can > > > > > > just discard x() and not care that y() is undefined. > > > > > > > > > > > > > > > > I will send a patch for function efi_dp_
Re: [v4.1 2/2] CI, pytest: Add a test for sandbox without LTO
Hi Tom,
On Sat, 21 Oct 2023 at 11:34, Tom Rini wrote:
>
> On Sat, Oct 21, 2023 at 08:43:00AM -0700, Simon Glass wrote:
> > On Fri, 20 Oct 2023 at 14:53, Tom Rini wrote:
> > >
> > > The primary motivation for having a sandbox without LTO build in CI is
> > > to ensure that we don't have that option break. We now have the ability
> > > to run tests of specific options being enabled/disabled, so drop the
> > > parts of CI that build and test that configuration specifically and add
> > > a build test instead. We still test that "NO_LTO=1" rather than editing
> > > the config file works via the ftrace tests.
> > >
> > > Signed-off-by: Tom Rini
> > > ---
> > > This creates a small bisectability gap in CI itself, but I think is more
> > > reasonable than reworking the introduction of
> > > test/py/tests/test_sandbox_opts.py
> > >
> > > Cc: Simon Glass
> > > ---
> > > .azure-pipelines.yml | 3 ---
> > > .gitlab-ci.yml | 12
> > > test/py/tests/test_sandbox_opts.py | 10 ++
> > > 3 files changed, 10 insertions(+), 15 deletions(-)
> >
> > Reviewed-by: Simon Glass
> >
> > Q below
> >
> > >
> > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > index 6f91553e8613..65533b36dde4 100644
> > > --- a/.azure-pipelines.yml
> > > +++ b/.azure-pipelines.yml
> > > @@ -287,9 +287,6 @@ stages:
> > > sandbox64_clang:
> > >TEST_PY_BD: "sandbox64"
> > >OVERRIDE: "-O clang-16"
> > > -sandbox_nolto:
> > > - TEST_PY_BD: "sandbox"
> > > - BUILD_ENV: "NO_LTO=1"
> > > sandbox_spl:
> > >TEST_PY_BD: "sandbox_spl"
> > >TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or
> > > test_spl"
> > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > index 6decdfdee334..97c964fb8079 100644
> > > --- a/.gitlab-ci.yml
> > > +++ b/.gitlab-ci.yml
> > > @@ -258,12 +258,6 @@ sandbox with clang test.py:
> > > OVERRIDE: "-O clang-16"
> > ><<: *buildman_and_testpy_dfn
> > >
> > > -sandbox without LTO test.py:
> > > - variables:
> > > -TEST_PY_BD: "sandbox"
> > > -BUILD_ENV: "NO_LTO=1"
> > > - <<: *buildman_and_testpy_dfn
> > > -
> > > sandbox64 test.py:
> > >variables:
> > > TEST_PY_BD: "sandbox64"
> > > @@ -275,12 +269,6 @@ sandbox64 with clang test.py:
> > > OVERRIDE: "-O clang-16"
> > ><<: *buildman_and_testpy_dfn
> > >
> > > -sandbox64 without LTO test.py:
> > > - variables:
> > > -TEST_PY_BD: "sandbox64"
> > > -BUILD_ENV: "NO_LTO=1"
> > > - <<: *buildman_and_testpy_dfn
> > > -
> > > sandbox_spl test.py:
> > >variables:
> > > TEST_PY_BD: "sandbox_spl"
> > > diff --git a/test/py/tests/test_sandbox_opts.py
> > > b/test/py/tests/test_sandbox_opts.py
> > > index 91790b3374b4..422b43cb3bc1 100644
> > > --- a/test/py/tests/test_sandbox_opts.py
> > > +++ b/test/py/tests/test_sandbox_opts.py
> > > @@ -18,3 +18,13 @@ def test_sandbox_cmdline(u_boot_console):
> > > out = util.run_and_log(
> > > cons, ['./tools/buildman/buildman', '-m', '--board', 'sandbox',
> > > '-a', '~CMDLINE', '-o', TMPDIR])
> > > +
> > > +@pytest.mark.slow
> > > +@pytest.mark.boardspec('sandbox')
> > > +def test_sandbox_lto(u_boot_console):
> > > +"""Test building sandbox without CONFIG_LTO"""
> > > +cons = u_boot_console
> > > +
> > > +out = util.run_and_log(
> > > +cons, ['./tools/buildman/buildman', '-m', '--board', 'sandbox',
> > > + '-a', '~LTO', '-o', TMPDIR])
> >
> > Don't you need sandbox64 here?
>
> No, I don't think it's providing further value to just build sandbox64
> without LTO. I'm also not 100% sure this patch is really needed in that we're
> trying to test for "did we disable LTO via make arguments" and in turn
> only the ftrace test really catches that, as it will fail if we do have
> LTO enabled, yes?
Really the test is to make sure that sandbox builds without LTO. With
the build time being. For development, LTO serves no useful purpose
and just triples the incremental build time.
I suggest we keep sandbox64 just to prevent a regression on non-LTO,
but I suspect it is unlikely to happen in practice.
Regards,
Simon
Re: [PATCH v3 1/2] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts
Hi Simon
On 19/10/23 19:25, Simon Glass wrote:
Hi Neha,
On Tue, 17 Oct 2023 at 23:20, Neha Malcom Francis wrote:
Hi Simon
On 18/10/23 09:03, Simon Glass wrote:
Hi Neha,
On Tue, 17 Oct 2023 at 03:58, Neha Malcom Francis wrote:
Hi Simon
On 08/10/23 04:39, Simon Glass wrote:
Hi Neha,
On Fri, 6 Oct 2023 at 04:07, Neha Malcom Francis wrote:
According to the TRMs of K3 platform of devices, the ROM boot image
format specifies a "Core Options Field" that provides the capability to
set the boot core in lockstep when set to 0 or to split mode when set
to 2. Add support for providing the same from the binman DTS. Also
modify existing test case for ensuring future coverage.
Signed-off-by: Neha Malcom Francis
---
Link to J721E TRM: https://www.ti.com/lit/zip/spruil1
Section 4.5.4.1 Boot Info
Changes in v3:
- updated function comments
- removed inconsistency in setting bootcore_opts to 32
Changes in v2:
- included TRM link in commit message
tools/binman/btool/openssl.py | 6 --
tools/binman/entries.rst| 1 +
tools/binman/etype/ti_secure_rom.py | 11 +--
tools/binman/etype/x509_cert.py | 3 ++-
tools/binman/test/297_ti_secure_rom.dts | 1 +
5 files changed, 17 insertions(+), 5 deletions(-)
[...]
diff --git a/tools/binman/test/297_ti_secure_rom.dts
b/tools/binman/test/297_ti_secure_rom.dts
index d1313769f4..1a3eca9425 100644
--- a/tools/binman/test/297_ti_secure_rom.dts
+++ b/tools/binman/test/297_ti_secure_rom.dts
@@ -9,6 +9,7 @@
binman {
ti-secure-rom {
content = <&unsecure_binary>;
+ core-opts = <2>;
here ^
Do you think there could be a binding file in dt-bindings/ for this value?
Sorry for getting back to this patch so late, but wanted to ask about this. I
had seen a last version of getting the binman compatible in dt-bindings but I
don't see it merged. Not sure where I would add this property in.
Yes it is difficult to do anything genuinely new.
I am anticipating something like compatible = "ti,secure-rom"
so I suppose you could create a header file with suitable values for
this property.
On the other hand, you could wait until there is progress with the bindings.
I can try adding a header file for now, but follow up question; shouldn't it be
added to arch/arm/dts rather than include/dt-bindings? There was traction by DT
maintainers to move all such constants not directly used by the driver (in this
case binman) to arch/arm/dts? [1] If you mean to use these constants in binman,
will need to see how we can do that.
You can put the constant in the .dtsi and #include your binding file.
But if you hit problems, let's worry about it later.
I'm a little confused on what has to be done regarding the binding ATM, so I'll
stick to waiting for some progress with the binman bindings and then tackle it.
};
unsecure_binary: blob-ext {
filename = "ti_unsecure.bin";
--
2.34.1
Regards,
Simon
[1] https://lore.kernel.org/all/c4d53e9c-dac0-8ccc-dc86-faada324b...@linaro.org/
Regards,
Simon
--
Thanking You
Neha Malcom Francis
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
Hi Heinrich, On Sat, 21 Oct 2023 at 21:53, Heinrich Schuchardt wrote: > > On 10/21/23 17:42, Simon Glass wrote: > > Hi Tom, > > > > On Fri, 20 Oct 2023 at 09:24, Tom Rini wrote: > >> > >> On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote: > >>> On 20.10.23 15:21, Simon Glass wrote: > +Doug Anderson > > Hi Heinrich, > > On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt > wrote: > > > > On 19.10.23 15:55, Simon Glass wrote: > >> Hi Heinrich, > >> > >> On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt > >> wrote: > >>> > >>> On 10/18/23 05:33, Simon Glass wrote: > Hi Heinrich, > > On Tue, 17 Oct 2023 at 07:50, Heinrich Schuchardt > wrote: > > > > Forward and backward compatibility of Linux kernel device-trees is > > sometimes missing. One solution approach is to load a kernel > > specific > > device-tree. This can either be done via a U-Boot scripts (like the > > one > > generated by Debian package flash-kernel or by a boot loader like > > GRUB. > > The boot loader approach currently requires to know the device-tree > > name > > before first boot which makes it unusable for generic images. > > > > Expose the device-tree file name as EFI variable FdtFile. > > This will allow bootloaders to load a kernel specific device-tree. > > > > The variable will not be exposed on ACPI based systems or if the > > environment variable fdtfile is not defined. > > > > Signed-off-by: Heinrich Schuchardt > > > > --- > > v2: > > Use a unique GUID to enable future U-Boot independent > > standardization. > > Do not try to add the variable on ACPI based systems. > > --- > > include/efi_loader.h | 5 + > > lib/efi_loader/efi_setup.c | 30 ++ > > 2 files changed, 35 insertions(+) > > I was too slow to reply to v1. > > Does grub load the DT? I was assuming that U-Boot would pass it on? > What is the interface between U-Boot and grub? > >>> > >>> The device-tree built into U-Boot is often out of date and not usable > >>> to > >>> boot current Linux. A single device-tree can be loaded by U-Boot from > >>> file and passed on as EFI configuration table. This device-tree may > >>> not > >>> be compatible with all kernel versions exposed by GRUB. > >>> > >>> GRUB provides a devicetree command. It is disabled if you use secure > >>> boot. At least in Debian and Ubuntu GRUB invokes the > >>> EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree > >>> fix-ups after loading a device-tree. > >>> > >>> Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add > >>> devicetree commands to the boot options in grub.cfg. > >> > >> Thanks. I wonder if you could document this somewhere? It seems like > >> there are a lot of options and it is quite complicated. > >> > >> Back to the question, I suppose you are expecting grub to load the DT > >> using this filename? But why doesn't U-Boot load it instead? It seems > >> very convoluted. > > > > A separate file of this name exists for every kernel version installed. > > The loaded dtb must match the kernel. U-Boot does not know what kernel > > version will be chosen in GRUB. And for a generic image GRUB does not > > what board it is on. > > > >> > >> Also, can we test this interface? > > > > Neither the sandbox nor QEMU have environment variable fdtfile. And we > > don't create the EFI variable with ACPI as used on the sandbox. > > I worry that this is creating another interface that some poor sod is > going to have to deal with in the future. Is this part of the EFI > standard? > >>> > >>> No, the UEFI standard does not care much about device-trees. It only > >>> defines > >>> the GUID for the configuration table. > >>> > > We should really be using the compatible string to choose the > devicetree. Why are we using filenames at all? What is the > relationship between the compatible string and the filename? Is there > a lookup table, or should we create one? > >>> > >>> There is no 1:1 relationship between compatible string and filename, e.g. > >>> the following arm64 device-trees use the same compatible string: > >>> > >>> amd/amd-overdrive-rev-b0.dts > >>> amd/amd-overdrive-rev-b1.dts > >>> > >>> amlogic/meson-axg-jethome-jethub-j110-rev-2.dts > >>> amlogic/meson-axg-jethome-jethub-j110-rev-3.dts > >>> > >>> xilinx/zynqmp-zc1751-xm015-dc1.dts > >>> xilinx/zynqmp-zc1751-xm015-dc1.dts > >>> xilinx/zynqmp-zc1751-xm015-dc1.dts >
Re: [PATCH 1/1] efi_loader: fix efi_dp_from_eth
On Sun, 22 Oct 2023 at 09:20, Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:
> When compiling the sandbox with CONFIG_LTO=n, CONFIG_NET=n an error is
> reported:
>
> /usr/bin/ld: lib/efi_loader/efi_device_path.o:
> in function `efi_dp_from_eth':
> lib/efi_loader/efi_device_path.c:985:(.text+0xcf4):
> undefined reference to `eth_get_dev'
>
> Add a missing configuration check.
>
> As the function is exported __maybe_unused can be removed.
>
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_device_path.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index ed7214f3a3..f3a0e855b3 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -977,11 +977,14 @@ struct efi_device_path *efi_dp_from_uart(void)
> return buf;
> }
>
> -struct efi_device_path __maybe_unused *efi_dp_from_eth(void)
> +struct efi_device_path *efi_dp_from_eth(void)
> {
> void *buf, *start;
> unsigned dpsize = 0;
>
> + if (!IS_ENABLED(CONFIG_NETDEVICES))
> + return NULL;
> +
> assert(eth_get_dev());
>
> dpsize += dp_size(eth_get_dev());
> --
> 2.40.1
>
>
Reviewed-by: Ilias Apalodimas
[PATCH v2] arm: xilinx: Add missing dual parallel flash description
Describe flash memories based on the latest DT binding.
Signed-off-by: Michal Simek
---
Changes in v2:
- Add missing description for zc706
arch/arm/dts/zynq-zc706.dts | 5 +++--
arch/arm/dts/zynq-zc770-xm013.dts | 5 +++--
arch/arm/dts/zynqmp-m-a2197-01-revA.dts | 4 +++-
arch/arm/dts/zynqmp-m-a2197-02-revA.dts | 4 +++-
arch/arm/dts/zynqmp-m-a2197-03-revA.dts | 4 +++-
5 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index 03eb016ed687..18963a395156 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -309,10 +309,11 @@
&qspi {
bootph-all;
status = "okay";
- num-cs = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "n25q128a11", "jedec,spi-nor";
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x100 0x100>; /* 16MB */
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <5000>;
diff --git a/arch/arm/dts/zynq-zc770-xm013.dts
b/arch/arm/dts/zynq-zc770-xm013.dts
index 21902fbb0cc1..582aa1f1b873 100644
--- a/arch/arm/dts/zynq-zc770-xm013.dts
+++ b/arch/arm/dts/zynq-zc770-xm013.dts
@@ -61,10 +61,11 @@
&qspi {
status = "okay";
- num-cs = <1>;
+ num-cs = <2>;
flash@0 {
compatible = "n25q128a11", "jedec,spi-nor";
- reg = <0x0>;
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x100 0x100>; /* 16MB */
spi-tx-bus-width = <1>;
spi-rx-bus-width = <4>;
spi-max-frequency = <5000>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
index 25ef646c8466..83b8a98d80ca 100644
--- a/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-01-revA.dts
@@ -71,11 +71,13 @@
&qspi {
status = "okay";
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
index ece9e6914541..dd37b726d3dc 100644
--- a/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-02-revA.dts
@@ -67,11 +67,13 @@
&qspi {
status = "okay";
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
diff --git a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
index 7372968e5734..811cebafe9e6 100644
--- a/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
+++ b/arch/arm/dts/zynqmp-m-a2197-03-revA.dts
@@ -67,11 +67,13 @@
&qspi {
status = "okay";
+ num-cs = <2>;
flash@0 {
compatible = "m25p80", "jedec,spi-nor"; /* 32MB */
+ reg = <0>, <1>;
+ parallel-memories = /bits/ 64 <0x400 0x400>; /* 64MB */
#address-cells = <1>;
#size-cells = <1>;
- reg = <0x0>;
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
spi-max-frequency = <10800>;
--
2.36.1
[PATCH] buildman: Include symbols in the read-only data section
When symbols switch between the inited data section and the read-only
data section their visbility changes, at present, with the -B option.
This is confusing, since adding 'const' to a variable declaration can
make it look like a significant improvement in bloat. But in fact
nothing has changed.
Add 'r' to the list of symbols types that are recorded, to correct this
problem. Add a constant to make it easier to find this code next time.
Signed-off-by: Simon Glass
---
tools/buildman/builder.py | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/buildman/builder.py b/tools/buildman/builder.py
index 5305477c5be6..3e42c987d1cd 100644
--- a/tools/buildman/builder.py
+++ b/tools/buildman/builder.py
@@ -35,6 +35,10 @@ from u_boot_pylib.terminal import tprint
# which indicates that BREAK_ME has an empty default
RE_NO_DEFAULT = re.compile(b'\((\w+)\) \[] \(NEW\)')
+# Symbol types which appear in the bloat feature (-B). Others are silently
+# dropped when reading in the 'nm' output
+NM_SYMBOL_TYPES = 'tTdDbBr'
+
"""
Theory of Operation
@@ -693,7 +697,7 @@ class Builder:
parts = line.split()
if line and len(parts) == 3:
size, type, name = line.split()
-if type in 'tTdDbB':
+if type in NM_SYMBOL_TYPES:
# function names begin with '.' on 64-bit powerpc
if '.' in name[1:]:
name = 'static.' + name.split('.')[0]
--
2.42.0.655.g421f12c284-goog
Re: [PATCH v3 1/2] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts
Hi Neha,
On Mon, 23 Oct 2023 at 00:06, Neha Malcom Francis wrote:
>
> Hi Simon
>
> On 19/10/23 19:25, Simon Glass wrote:
> > Hi Neha,
> >
> > On Tue, 17 Oct 2023 at 23:20, Neha Malcom Francis wrote:
> >>
> >> Hi Simon
> >>
> >> On 18/10/23 09:03, Simon Glass wrote:
> >>> Hi Neha,
> >>>
> >>> On Tue, 17 Oct 2023 at 03:58, Neha Malcom Francis
> >>> wrote:
>
> Hi Simon
>
> On 08/10/23 04:39, Simon Glass wrote:
> > Hi Neha,
> >
> > On Fri, 6 Oct 2023 at 04:07, Neha Malcom Francis
> > wrote:
> >>
> >> According to the TRMs of K3 platform of devices, the ROM boot image
> >> format specifies a "Core Options Field" that provides the capability to
> >> set the boot core in lockstep when set to 0 or to split mode when set
> >> to 2. Add support for providing the same from the binman DTS. Also
> >> modify existing test case for ensuring future coverage.
> >>
> >> Signed-off-by: Neha Malcom Francis
> >> ---
> >> Link to J721E TRM: https://www.ti.com/lit/zip/spruil1
> >> Section 4.5.4.1 Boot Info
> >>
> >> Changes in v3:
> >>- updated function comments
> >>- removed inconsistency in setting bootcore_opts to 32
> >>
> >> Changes in v2:
> >>- included TRM link in commit message
> >>
> >> tools/binman/btool/openssl.py | 6 --
> >> tools/binman/entries.rst| 1 +
> >> tools/binman/etype/ti_secure_rom.py | 11 +--
> >> tools/binman/etype/x509_cert.py | 3 ++-
> >> tools/binman/test/297_ti_secure_rom.dts | 1 +
> >> 5 files changed, 17 insertions(+), 5 deletions(-)
> >>
>
> [...]
>
> >> diff --git a/tools/binman/test/297_ti_secure_rom.dts
> >> b/tools/binman/test/297_ti_secure_rom.dts
> >> index d1313769f4..1a3eca9425 100644
> >> --- a/tools/binman/test/297_ti_secure_rom.dts
> >> +++ b/tools/binman/test/297_ti_secure_rom.dts
> >> @@ -9,6 +9,7 @@
> >>binman {
> >>ti-secure-rom {
> >>content = <&unsecure_binary>;
> >> + core-opts = <2>;
> >
> > here ^
> >
> > Do you think there could be a binding file in dt-bindings/ for this
> > value?
> >
>
> Sorry for getting back to this patch so late, but wanted to ask about
> this. I
> had seen a last version of getting the binman compatible in dt-bindings
> but I
> don't see it merged. Not sure where I would add this property in.
> >>>
> >>> Yes it is difficult to do anything genuinely new.
> >>>
> >>> I am anticipating something like compatible = "ti,secure-rom"
> >>>
> >>> so I suppose you could create a header file with suitable values for
> >>> this property.
> >>>
> >>> On the other hand, you could wait until there is progress with the
> >>> bindings.
> >>>
> >>>
> >>
> >> I can try adding a header file for now, but follow up question; shouldn't
> >> it be
> >> added to arch/arm/dts rather than include/dt-bindings? There was traction
> >> by DT
> >> maintainers to move all such constants not directly used by the driver (in
> >> this
> >> case binman) to arch/arm/dts? [1] If you mean to use these constants in
> >> binman,
> >> will need to see how we can do that.
> >
> > You can put the constant in the .dtsi and #include your binding file.
> > But if you hit problems, let's worry about it later.
> >
>
> I'm a little confused on what has to be done regarding the binding ATM, so
> I'll
> stick to waiting for some progress with the binman bindings and then tackle
> it.
>
Yes that sounds fine.
> >>
>
> >>};
> >>unsecure_binary: blob-ext {
> >>filename = "ti_unsecure.bin";
> >> --
> >> 2.34.1
> >>
> >>> Regards,
> >>> Simon
> >>
> >> [1]
> >> https://lore.kernel.org/all/c4d53e9c-dac0-8ccc-dc86-faada324b...@linaro.org/
> > Regards,
> > Simon
>
Regards,
Simon
[PATCH v4 1/2] binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts
According to the TRMs of K3 platform of devices, the ROM boot image
format specifies a "Core Options Field" that provides the capability to
set the boot core in lockstep when set to 0 or to split mode when set
to 2. Add support for providing the same from the binman DTS. Also
modify existing test case for ensuring future coverage.
Signed-off-by: Neha Malcom Francis
---
Link to J721E TRM: https://www.ti.com/lit/zip/spruil1
Section 4.5.4.1 Boot Info
Changes in v4:
- corrected function comments, 0 for lockstep, 2 for split mode
Changes in v3:
- updated function comments
- removed inconsistency in setting bootcore_opts to 32
Changes in v2:
- included TRM link in commit message
tools/binman/btool/openssl.py | 6 --
tools/binman/entries.rst| 1 +
tools/binman/etype/ti_secure_rom.py | 11 +--
tools/binman/etype/x509_cert.py | 3 ++-
tools/binman/test/297_ti_secure_rom.dts | 1 +
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/tools/binman/btool/openssl.py b/tools/binman/btool/openssl.py
index aad3b61ae2..7ee2683ab2 100644
--- a/tools/binman/btool/openssl.py
+++ b/tools/binman/btool/openssl.py
@@ -155,6 +155,7 @@ authInPlace = INTEGER:2
C, ST, L, O, OU, CN and emailAddress
cert_type (int): Certification type
bootcore (int): Booting core
+bootcore_opts(int): Booting core option, lockstep (0) or split (2)
mode
load_addr (int): Load address of image
sha (int): Hash function
@@ -225,7 +226,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
imagesize_sbl, hashval_sbl, load_addr_sysfw, imagesize_sysfw,
hashval_sysfw, load_addr_sysfw_data, imagesize_sysfw_data,
hashval_sysfw_data, sysfw_inner_cert_ext_boot_block,
- dm_data_ext_boot_block):
+ dm_data_ext_boot_block, bootcore_opts):
"""Create a certificate
Args:
@@ -241,6 +242,7 @@ emailAddress =
{req_dist_name_dict['emailAddress']}
bootcore (int): Booting core
load_addr (int): Load address of image
sha (int): Hash function
+bootcore_opts (int): Booting core option, lockstep (0) or split
(2) mode
Returns:
str: Tool output
@@ -285,7 +287,7 @@ sysfw_data=SEQUENCE:sysfw_data
[sbl]
compType = INTEGER:1
bootCore = INTEGER:16
-compOpts = INTEGER:0
+compOpts = INTEGER:{bootcore_opts}
destAddr = FORMAT:HEX,OCT:{load_addr:08x}
compSize = INTEGER:{imagesize_sbl}
shaType = OID:{sha_type}
diff --git a/tools/binman/entries.rst b/tools/binman/entries.rst
index e7b4e9380e..2402adb3d9 100644
--- a/tools/binman/entries.rst
+++ b/tools/binman/entries.rst
@@ -1944,6 +1944,7 @@ Properties / Entry arguments:
- core: core on which bootloader runs, valid cores are 'secure' and
'public'
- content: phandle of SPL in case of legacy bootflow or phandles of
component binaries
in case of combined bootflow
+- core-opts (optional): lockstep (0) or split (2) mode set to 0 by default
The following properties are only for generating a combined bootflow binary:
- sysfw-inner-cert: boolean if binary contains sysfw inner certificate
diff --git a/tools/binman/etype/ti_secure_rom.py
b/tools/binman/etype/ti_secure_rom.py
index 9a7ac9e9e0..f6fc3f90f8 100644
--- a/tools/binman/etype/ti_secure_rom.py
+++ b/tools/binman/etype/ti_secure_rom.py
@@ -32,6 +32,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
- core: core on which bootloader runs, valid cores are 'secure' and
'public'
- content: phandle of SPL in case of legacy bootflow or phandles of
component binaries
in case of combined bootflow
+- core-opts (optional): lockstep (0) or split (2) mode set to 0 by
default
The following properties are only for generating a combined bootflow
binary:
- sysfw-inner-cert: boolean if binary contains sysfw inner certificate
@@ -69,6 +70,7 @@ class Entry_ti_secure_rom(Entry_x509_cert):
self.sw_rev = fdt_util.GetInt(self._node, 'sw-rev', 1)
self.sha = fdt_util.GetInt(self._node, 'sha', 512)
self.core = fdt_util.GetString(self._node, 'core', 'secure')
+self.bootcore_opts = fdt_util.GetInt(self._node, 'core-opts')
self.key_fname = self.GetEntryArgsOrProps([
EntryArg('keyfile', str)], required=True)[0]
if self.combined:
@@ -97,17 +99,19 @@ class Entry_ti_secure_rom(Entry_x509_cert):
bytes content of the entry, which is the certificate binary for the
provided data
"""
+if self.bootcore_opts is None:
+self.bootcore_opts = 0
+
if self.core == 'secure':
if self.countersign:
self.cert_type = 3
else:
self.cert_type = 2
self.bootcore = 0
-
[PATCH v4 2/2] DONOTMERGE: arm: dts: k3-j7200-binman: Enable split mode for MCU R5
Set boot core-opts to enable split mode for MCU R5 cluster by default. This patch serves to demonstrate how this can be done. Signed-off-by: Neha Malcom Francis --- No change since v2 arch/arm/dts/k3-j7200-binman.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/dts/k3-j7200-binman.dtsi b/arch/arm/dts/k3-j7200-binman.dtsi index 14f7dea65e..025a0bd071 100644 --- a/arch/arm/dts/k3-j7200-binman.dtsi +++ b/arch/arm/dts/k3-j7200-binman.dtsi @@ -55,6 +55,7 @@ <&combined_dm_cfg>, <&sysfw_inner_cert>; combined; dm-data; + core-opts = <2>; sysfw-inner-cert; keyfile = "custMpk.pem"; sw-rev = <1>; @@ -100,6 +101,7 @@ <&combined_dm_cfg_fs>, <&sysfw_inner_cert_fs>; combined; dm-data; + core-opts = <2>; sysfw-inner-cert; keyfile = "custMpk.pem"; sw-rev = <1>; @@ -146,6 +148,7 @@ <&combined_tifs_cfg_gp>, <&combined_dm_cfg_gp>; combined; dm-data; + core-opts = <2>; content-sbl = <&u_boot_spl_unsigned>; load = <0x41c0>; content-sysfw = <&ti_fs_gp>; -- 2.34.1
[PATCH v4 0/2] Enable split mode in binman
This series extends the functionality of ti-secure-rom entry type in binman to support enabling of split mode vs. the default lockstep mode via changing the field in the x509 certificate. A DONOTMERGE patch is added to give an example of how this can be done via the binman.dtsi Changes in v4: - Simon: - correct function comments for setting bit for split and lockstep mode Changes in v3: - Simon: - added entries.rst change - updated function comments - removed inconsistency in setting bootcore_opts to 32 Changes in v2: - Udit: - included TRM link in commit message - added DONOTMERGE patch showing example Neha Malcom Francis (2): binman: openssl: x509: ti_secure_rom: Add support for bootcore_opts DONOTMERGE: arm: dts: k3-j7200-binman: Enable split mode for MCU R5 arch/arm/dts/k3-j7200-binman.dtsi | 3 +++ tools/binman/btool/openssl.py | 6 -- tools/binman/entries.rst| 1 + tools/binman/etype/ti_secure_rom.py | 11 +-- tools/binman/etype/x509_cert.py | 3 ++- tools/binman/test/297_ti_secure_rom.dts | 1 + 6 files changed, 20 insertions(+), 5 deletions(-) -- 2.34.1
Re: [PATCH v2 1/1] efi_loader: expose the device-tree file name
On 10/23/23 09:08, Simon Glass wrote: Hi Heinrich, On Sat, 21 Oct 2023 at 21:53, Heinrich Schuchardt wrote: On 10/21/23 17:42, Simon Glass wrote: Hi Tom, On Fri, 20 Oct 2023 at 09:24, Tom Rini wrote: On Fri, Oct 20, 2023 at 05:40:03PM +0200, Heinrich Schuchardt wrote: On 20.10.23 15:21, Simon Glass wrote: +Doug Anderson Hi Heinrich, On Thu, 19 Oct 2023 at 09:09, Heinrich Schuchardt wrote: On 19.10.23 15:55, Simon Glass wrote: Hi Heinrich, On Wed, 18 Oct 2023 at 02:15, Heinrich Schuchardt wrote: On 10/18/23 05:33, Simon Glass wrote: Hi Heinrich, On Tue, 17 Oct 2023 at 07:50, Heinrich Schuchardt wrote: Forward and backward compatibility of Linux kernel device-trees is sometimes missing. One solution approach is to load a kernel specific device-tree. This can either be done via a U-Boot scripts (like the one generated by Debian package flash-kernel or by a boot loader like GRUB. The boot loader approach currently requires to know the device-tree name before first boot which makes it unusable for generic images. Expose the device-tree file name as EFI variable FdtFile. This will allow bootloaders to load a kernel specific device-tree. The variable will not be exposed on ACPI based systems or if the environment variable fdtfile is not defined. Signed-off-by: Heinrich Schuchardt --- v2: Use a unique GUID to enable future U-Boot independent standardization. Do not try to add the variable on ACPI based systems. --- include/efi_loader.h | 5 + lib/efi_loader/efi_setup.c | 30 ++ 2 files changed, 35 insertions(+) I was too slow to reply to v1. Does grub load the DT? I was assuming that U-Boot would pass it on? What is the interface between U-Boot and grub? The device-tree built into U-Boot is often out of date and not usable to boot current Linux. A single device-tree can be loaded by U-Boot from file and passed on as EFI configuration table. This device-tree may not be compatible with all kernel versions exposed by GRUB. GRUB provides a devicetree command. It is disabled if you use secure boot. At least in Debian and Ubuntu GRUB invokes the EFI_DT_FIXUP_PROTOCOL exposed by U-Boot to run U-Boot's device-tree fix-ups after loading a device-tree. Vendor scripts for GRUB like Ubuntu's /etc/grub.d/10_linux add devicetree commands to the boot options in grub.cfg. Thanks. I wonder if you could document this somewhere? It seems like there are a lot of options and it is quite complicated. Back to the question, I suppose you are expecting grub to load the DT using this filename? But why doesn't U-Boot load it instead? It seems very convoluted. A separate file of this name exists for every kernel version installed. The loaded dtb must match the kernel. U-Boot does not know what kernel version will be chosen in GRUB. And for a generic image GRUB does not what board it is on. Also, can we test this interface? Neither the sandbox nor QEMU have environment variable fdtfile. And we don't create the EFI variable with ACPI as used on the sandbox. I worry that this is creating another interface that some poor sod is going to have to deal with in the future. Is this part of the EFI standard? No, the UEFI standard does not care much about device-trees. It only defines the GUID for the configuration table. We should really be using the compatible string to choose the devicetree. Why are we using filenames at all? What is the relationship between the compatible string and the filename? Is there a lookup table, or should we create one? There is no 1:1 relationship between compatible string and filename, e.g. the following arm64 device-trees use the same compatible string: amd/amd-overdrive-rev-b0.dts amd/amd-overdrive-rev-b1.dts amlogic/meson-axg-jethome-jethub-j110-rev-2.dts amlogic/meson-axg-jethome-jethub-j110-rev-3.dts xilinx/zynqmp-zc1751-xm015-dc1.dts xilinx/zynqmp-zc1751-xm015-dc1.dts xilinx/zynqmp-zc1751-xm015-dc1.dts xilinx/zynqmp-zc1751-xm015-dc1.dts The correct way of doing this is implemented in U-Boot with CONFIG_FIT_BEST_MATCH. Why should we write complicated code to find a *possibly* matching file if we already know the filename that needs to be loaded? I think that is the unfortunate key here. We can make a guess, or best match, but it might not be right. And we need a reliable way to find and use the correct tree. And the U-Boot portion of that may be "set the EFI var if it's not already set" rather than "and now load it". That is not my understanding of how it works. The compatible string is how Linux knows what the hardware is...if it doesn't match, then things are going to go wrong. It is also how U-Boot works, e.g. with FIT. I don't believe this is a 'guess'. The compatible string is used programmatically and must be correct. It is not how U-Boot works. In distroboot U-Boot uses environment variable fdtfile to load the correct device-tree. Yes, that is
[PATCH] led: Do not overwrite label
label might have been set by a non device-tree based U-Boot driver already.
In my concrete case there is a PCI driver that uses device_bind_driver(..)
for different class types. The UCLASS_LED specific driver sets label
in its bind function.
Without this change the LEDs exposed by the PCI device are not available.
Fixes: 83c63f0d11 ("led: Move OF "label" property parsing to core")
Signed-off-by: Christian Gmeiner
---
drivers/led/led-uclass.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 68ca3c2970..aebdfdeb95 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -71,9 +71,10 @@ static int led_post_bind(struct udevice *dev)
struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
const char *default_state;
- uc_plat->label = dev_read_string(dev, "label");
if (!uc_plat->label)
- uc_plat->label = ofnode_get_name(dev_ofnode(dev));
+ uc_plat->label = dev_read_string(dev, "label");
+ if (!uc_plat->label)
+ uc_plat->label = ofnode_get_name(dev_ofnode(dev));
uc_plat->default_state = LEDST_COUNT;
--
2.41.0
Re: [PATCH 1/1] general: fix GPL-2.0-or-later SPDX headers
On 10/23/23 09:05, Simon Glass wrote: Hi Heinrich, On Sun, 22 Oct 2023 at 10:48, Heinrich Schuchardt wrote: SPDX headers should use GPL-2.0-or-later and not GPL-2.0+. Signed-off-by: Heinrich Schuchardt --- Makefile | 2 +- README | 2 +- api/Makefile | 2 +- api/api.c | 2 +- api/api_display.c | 2 +- api/api_net.c | 2 +- api/api_platform-arm.c | 2 +- api/api_platform-mips.c| 2 +- In License/README it shows the identifier as 'GPL-2.0+'. I know. That file needs to be reworked to remove the redundancy with doc/develop/sending_patches.rst (which has some inaccuracies concerning SPDX) and moved to HTML. We should handle it in a separate patch. We will need separate patches for LGPL-2.0+ and LGPL-2.1+, too. But this should not stop us from merging the current patch. Best regards Heinrich
Re: [PATCH v5 4/8] rockchip: block: blk-uclass: add bounce buffer flag to blk_desc
On 2023/10/18 22:01, Johan Jonker wrote:
Currently bounce buffer support is enabled for all block devices
when available. Add a flag to blk_desc to enable only on demand.
Signed-off-by: Johan Jonker
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Changed V5:
New patch
---
drivers/block/blk-uclass.c | 4 ++--
drivers/scsi/scsi.c| 4
include/blk.h | 1 +
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 30ad5bbb0024..77066da352a3 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -441,7 +441,7 @@ long blk_read(struct udevice *dev, lbaint_t start, lbaint_t
blkcnt, void *buf)
start, blkcnt, desc->blksz, buf))
return blkcnt;
- if (IS_ENABLED(CONFIG_BOUNCE_BUFFER)) {
+ if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) {
struct blk_bounce_buffer bbstate = { .dev = dev };
int ret;
@@ -478,7 +478,7 @@ long blk_write(struct udevice *dev, lbaint_t start,
lbaint_t blkcnt,
blkcache_invalidate(desc->uclass_id, desc->devnum);
- if (IS_ENABLED(CONFIG_BOUNCE_BUFFER)) {
+ if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) {
struct blk_bounce_buffer bbstate = { .dev = dev };
int ret;
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 7411660d465e..779a34bd2f1c 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -459,6 +459,9 @@ static void scsi_init_dev_desc_priv(struct blk_desc
*dev_desc)
dev_desc->product[0] = 0;
dev_desc->revision[0] = 0;
dev_desc->removable = false;
+#if IS_ENABLED(CONFIG_BOUNCE_BUFFER)
+ dev_desc->bb = true;
+#endif /* CONFIG_BOUNCE_BUFFER */
}
#if !defined(CONFIG_DM_SCSI)
@@ -606,6 +609,7 @@ static int do_scsi_scan_one(struct udevice *dev, int id,
int lun, bool verbose)
bdesc->lun = lun;
bdesc->removable = bd.removable;
bdesc->type = bd.type;
+ bdesc->bb = bd.bb;
memcpy(&bdesc->vendor, &bd.vendor, sizeof(bd.vendor));
memcpy(&bdesc->product, &bd.product, sizeof(bd.product));
memcpy(&bdesc->revision, &bd.revision, sizeof(bd.revision));
diff --git a/include/blk.h b/include/blk.h
index 76bd5baf9959..7c7cf7f2b102 100644
--- a/include/blk.h
+++ b/include/blk.h
@@ -68,6 +68,7 @@ struct blk_desc {
/* device can use 48bit addr (ATA/ATAPI v7) */
boollba48;
unsigned char atapi; /* Use ATAPI protocol */
+ unsigned char bb; /* Use bounce buffer */
lbaint_tlba;/* number of blocks */
unsigned long blksz; /* block size */
int log2blksz; /* for convenience: log2(blksz) */
--
2.39.2
Re: [PATCH] led: Do not overwrite label
On 10/23/23 10:21, Christian Gmeiner wrote:
label might have been set by a non device-tree based U-Boot driver already.
In my concrete case there is a PCI driver that uses device_bind_driver(..)
for different class types. The UCLASS_LED specific driver sets label
in its bind function.
Without this change the LEDs exposed by the PCI device are not available.
Fixes: 83c63f0d11 ("led: Move OF "label" property parsing to core")
Signed-off-by: Christian Gmeiner
---
drivers/led/led-uclass.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 68ca3c2970..aebdfdeb95 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -71,9 +71,10 @@ static int led_post_bind(struct udevice *dev)
struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
const char *default_state;
- uc_plat->label = dev_read_string(dev, "label");
if (!uc_plat->label)
- uc_plat->label = ofnode_get_name(dev_ofnode(dev));
+ uc_plat->label = dev_read_string(dev, "label");
+ if (!uc_plat->label)
+ uc_plat->label = ofnode_get_name(dev_ofnode(dev));
uc_plat->default_state = LEDST_COUNT;
+CC Rasmus, you really do want to review this one.
There is existing and more extensive series from Rasmus addressing the
same issue.
Re: [PATCH 1/6] led-uclass: do not create fallback label for top-level node
On 19/10/2023 15.51, Marek Vasut wrote:
> On 10/19/23 11:58, Rasmus Villemoes wrote:
>> Many existing drivers, and led-uclass itself, rely on uc_plat->label
>> being NULL for the device representing the top node, as opposed to the
>> child nodes representing individual LEDs. This means that the drivers
>> whose .probe methods rely on this were broken by 83c63f0d1185 ("led:
>> Move OF "label" property parsing to core"), and also that the top node
>> wrongly shows up with 'led list'. Some drivers have since been fixed
>> up individually, e.g.
>>
>> e3aa76644c2a "led: gpio: Check device compatible string to determine
>> the top level node"
>> 01074697801b "led: gpio: Use NOP uclass driver for top-level node"
>> 910b01c27c04 "drivers: led: bcm6753: do not use null label to find the
>> top"
>>
>> Binding the same driver to the top node as to the individual child
>> nodes is arguably wrong, and the approach of using a UCLASS_NOP driver
>> for the top node is probably better.
>
> Note that
> 83c63f0d1185 ("led: Move OF "label" property parsing to core")
> and
> 01074697801b ("led: gpio: Use NOP uclass driver for top-level node")
> were applied shortly after each other, so I don't see the point of the
> aforementioned rant.
What rant? I'm merely trying to write down what I found out while trying
to figure out why 83c63f0d1185 broke stuff, while acknowledging that the
fixes that have been applied to some drivers are probably the approach
in general.
> I sort-of understand what you are trying to do in this patch based on
> $SUBJECT of this email, but not from this wall of text, so can you
> abbreviate the commit message ?
Sure, I can try and make it shorter.
>> - if (!uc_plat->label)
>> + if (!uc_plat->label && !dev_read_string(dev, "compatible"))
>> uc_plat->label = ofnode_get_name(dev_ofnode(dev));
>
> Is there an existing driver which has a top-level DT node with "label"
> property ?
-ENOPARSE? A driver doesn't have a top-level DT node.
And regardless, this wouldn't change anything for a top-level DT node
with a "label" property, as we're still unconditionally first trying to
read a "label" property, this is merely avoiding adding a fallback value
for top-level DT nodes (using "having a "compatible" DT property as
proxy for that "is a top-level DT node"). So I really don't understand
what you are trying to ask.
Rasmus
Re: [PATCH 2/6] led-uclass: honour ->label field populated by driver's own .bind
On 19/10/2023 15.54, Marek Vasut wrote:
> On 10/19/23 11:58, Rasmus Villemoes wrote:
>> If the driver's own .bind method has populated uc_plat->label, don't
>> override that. This is necessary for an upcoming driver for ti,lp5562,
>> where the DT binding unfortunately says to use "chan-name" and not
>> "label".
>>
>> Signed-off-by: Rasmus Villemoes
>> ---
>> drivers/led/led-uclass.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
>> index 5a5d07b9a7..0232fa84de 100644
>> --- a/drivers/led/led-uclass.c
>> +++ b/drivers/led/led-uclass.c
>> @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
>> struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
>> const char *default_state;
>> - uc_plat->label = dev_read_string(dev, "label");
>> + if (!uc_plat->label)
>> + uc_plat->label = dev_read_string(dev, "label");
>> +
>
> One thing I have to wonder about is, why does this controller have label
> property in the top-level node , what is that used for ?
>
> (see Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml)
>
> Reviewed-by: Marek Vasut
Reading the linux driver, it seems that the top-level label, if any, is
used as part of the naming for individual channels if they don't have
individual chan-name properties:
if (pdata->led_config[chan].name) {
led->cdev.name = pdata->led_config[chan].name;
} else {
snprintf(name, sizeof(name), "%s:channel%d",
pdata->label ? : chip->cl->name, chan);
led->cdev.name = name;
}
but I think the rationale in d1188adb2dabc is a bit weak, since the only
example also does have individual chan-name properties.
[Complete aside: At first I thought it was related to the multi-color
LED work that has been ongoing for many many years (I think there was an
LWN article at some point), where this could be exposed as a single
multi-color LED, as opposed to the "traditional" three/four individual
LEDs. In the former case, there would only be one sysfs entry, but with
attributes exposing the multicolor functionality. I must admit I don't
know the status of that work, when something reaches v31,
http://archive.lwn.net:8080/linux-kernel/20200722071055.GA8984@amd/t/ ,
it's hard to know if it ever lands, or if pieces of it has landed.]
Rasmus
[GIT PULL] Please pull u-boot-amlogic-20231023
Hi Tom, An important fix for USB Gadget on G12/SM1 boards and a welcome DT sync for the Amlogic A1 DT. The CI job is at https://source.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/18256 Thanks, Neil The following changes since commit e65b5d35c9116485366bb08138043d51220551da: Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh (2023-10-17 09:15:56 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20231023 for you to fetch changes up to 14a21f1a80afc58d52dc72e35f27d3a47d36c082: arm: meson-a1: dts: Sync DT with Linux (2023-10-18 09:46:01 +0200) - sync A1 with Linux and add missing UART compatible - fix USB2 gadget init on G12/SM1 based Boards Guillaume La Roque (1): phy: meson-g12a-usb2: fix ret check on power_domain_get Igor Prusov (2): serial: amlogic: Add UART compatible for A1 board arm: meson-a1: dts: Sync DT with Linux arch/arm/dts/meson-a1.dtsi| 356 +- drivers/phy/meson-g12a-usb2.c | 6 +- drivers/serial/serial_meson.c | 1 + 3 files changed, 355 insertions(+), 8 deletions(-)
Re: [PATCH 6/6] led: add TI LP5562 LED driver
On 19/10/2023 15.58, Marek Vasut wrote: > On 10/19/23 11:58, Rasmus Villemoes wrote: >> From: Doug Zobel >> >> Driver for the TI LP5562 4 channel LED controller. Supports >> independent on/off control of all 4 channels. Supports LED_BLINK on 3 >> independent channels: blue/green/red. The white channel can blink, but >> shares the blue channel blink rate. >> >> Heavily based on patch originally from Doug Zobel [1]. >> >> I have modified it so it matches the DT bindings in the linux tree, >> and also follows the linux driver implementation more closely. This >> should address Tom's concerns, and also matches my goal of making the >> U-Boot driver work with our existing .dts which is known to work in >> linux. >> >> As our boards only have the R,G,B outputs connected, I have not >> actually tested how the white channel behaves, but the R,G,B work >> exactly as expected. >> >> [1] >> https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/ >> >> Cc: Doug Zobel >> Signed-off-by: Rasmus Villemoes >> --- >> doc/device-tree-bindings/leds/leds-lp5562.txt | 63 ++ >> drivers/led/Kconfig | 8 + >> drivers/led/Makefile | 1 + >> drivers/led/led_lp5562.c | 578 ++ >> 4 files changed, 650 insertions(+) >> create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt >> create mode 100644 drivers/led/led_lp5562.c >> >> diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt >> b/doc/device-tree-bindings/leds/leds-lp5562.txt >> new file mode 100644 >> index 00..4e0c742959 >> --- /dev/null >> +++ b/doc/device-tree-bindings/leds/leds-lp5562.txt > > Why not use Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml ? Because I'm not adding support for all the devices covered by that binding, nor for all the properties defined there (and some of those, I think, do not even make sense for the lp5562 but only apply to some of the other variants). > [...] > >> --- /dev/null >> +++ b/drivers/led/led_lp5562.c >> @@ -0,0 +1,578 @@ >> +// SPDX-License-Identifier: GPL-2.0+ >> +/* >> + * Copyright (C) 2018 Doug Zobel > > Why not port Linux drivers/leds/leds-lp5562.c ? Because that would be way more work to make that fit into U-Boot's LED framework than to take Doug's initial patch and make it build against current U-Boot. Rasmus
Re: [PATCH 0/4] bootstd: Test and boot_targets improvements
On 10-23 00:02, Simon Glass wrote: > > This series makes another attempt to support things like "mmc" in the > boot_targets variable. The previous attempt introduced a bug which made > iteration fail. > > New test coverage is provided for some previously untested behaviour, to > prevent regressions. > > Thank you! Booting RPi4 from USB and uSB looks fine now. I have updated also our Bugzilla entry with the boot log. Tested-by: Ivan T.Ivanov Regards, Ivan [1] https://bugzilla.suse.com/show_bug.cgi?id=1216036 > Simon Glass (4): > Revert "bootstd: Scan all bootdevs in a boot_targets entry" > bootstd: Expand boot-ordering test to include USB > bootstd: Correct logic for single uclass > bootstd: Scan all bootdevs in a boot_targets entry (take 2) >
Re: [PATCH v2 2/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board
On 2023/10/17 23:59, Tom Fitzhenry wrote:
QuartzPro64 is a Rockchip RK3588 based SBC by Pine64.
UART and boot over SD/eMMC/RJ45 are tested to work.
Linux commits from next-20231013:
8152d3d070a9 ("arm64: dts: rockchip: Add QuartzPro64 SBC device tree")
Signed-off-by: Tom Fitzhenry
Cc: Eugen Hristev
Cc: Jonas Karlman
Cc: Ondrej Jirman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
This patch depends on "rockchip: rk3588: Sync device tree from linux
maintainer tree"[0], since the QuartzPro64 upstream DT depends on upstream
dtsi changes.
0. https://lore.kernel.org/all/20231010222344.3436526-2-jo...@kwiboo.se
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi | 12 +
arch/arm/dts/rk3588-quartzpro64.dts | 1137 +
arch/arm/mach-rockchip/rk3588/Kconfig |8 +
board/pine64/quartzpro64-rk3588/Kconfig | 15 +
board/pine64/quartzpro64-rk3588/MAINTAINERS |8 +
board/pine64/quartzpro64-rk3588/Makefile |3 +
.../quartzpro64-rk3588/quartzpro64-rk3588.c | 39 +
configs/quartzpro64-rk3588_defconfig | 72 ++
doc/board/rockchip/rockchip.rst |1 +
include/configs/quartzpro64-rk3588.h | 14 +
11 files changed, 1310 insertions(+)
create mode 100644 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-quartzpro64.dts
create mode 100644 board/pine64/quartzpro64-rk3588/Kconfig
create mode 100644 board/pine64/quartzpro64-rk3588/MAINTAINERS
create mode 100644 board/pine64/quartzpro64-rk3588/Makefile
create mode 100644 board/pine64/quartzpro64-rk3588/quartzpro64-rk3588.c
create mode 100644 configs/quartzpro64-rk3588_defconfig
create mode 100644 include/configs/quartzpro64-rk3588.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4569483d5fd..6d1e33d9e2e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+ rk3588-quartzpro64.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
new file mode 100644
index 000..191ec988c45
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Google, Inc
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
+ };
+};
diff --git a/arch/arm/dts/rk3588-quartzpro64.dts
b/arch/arm/dts/rk3588-quartzpro64.dts
new file mode 100644
index 000..5c59f9571dc
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64.dts
@@ -0,0 +1,1137 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ model = "PINE64 QuartzPro64";
+ compatible = "pine64,quartzpro64", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys-0 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-maskrom {
+ label = "Mask Rom";
+ linux,code = ;
+ press-threshold-microvolt = <393>;
+ };
+ };
+
+ adc-keys-1 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-volume-up {
+ label = "V+/REC";
+ linux,code = ;
+ press-threshold-microvolt = <17821>;
+ };
+
+ button-volume-down {
+ label = "V-";
+ linux,code = ;
+ press-threshold-microvolt = <415384>;
+ };
+
+ button-menu {
+ label = "MENU";
+ linux,code = ;
+ press-threshold-microvolt = <890909>;
+ };
+
+ button-esc {
+ label = "ESC";
+ linux,code = ;
+ press-threshold-microvolt = <1233962>;
+ };
+ };
+
+ headphone_amp: audio-amplifier-headphone {
+ compatible = "simple-audio-amplifier";
+
Re: [PATCH v2 2/4] rockchip: rk3588-rock-5a: Enable support for USB 2.0 ports
On 2023/10/18 01:02, Jonas Karlman wrote: Enable Kconfig options for the two USB 2.0 ports and bottom USB 3.0 port on ROCK 5 Model A. Signed-off-by: Jonas Karlman Reviewed-by: Kever Yang Thanks, - Kever --- v2: - New patch configs/rock5a-rk3588s_defconfig | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig index bccdb1e3ecd6..a6471a519514 100644 --- a/configs/rock5a-rk3588s_defconfig +++ b/configs/rock5a-rk3588s_defconfig @@ -39,13 +39,16 @@ CONFIG_SPL_STACK_R=y CONFIG_SPL_ATF=y CONFIG_CMD_GPIO=y CONFIG_CMD_GPT=y +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_REGULATOR=y # CONFIG_SPL_DOS_PARTITION is not set CONFIG_SPL_OF_CONTROL=y CONFIG_OF_LIVE=y CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_SPL_REGMAP=y CONFIG_SPL_SYSCON=y CONFIG_SPL_CLK=y @@ -61,12 +64,23 @@ CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_PHY_REALTEK=y CONFIG_DWC_ETH_QOS=y CONFIG_DWC_ETH_QOS_ROCKCHIP=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y +CONFIG_PHY_ROCKCHIP_USBDP=y CONFIG_SPL_PINCTRL=y -CONFIG_REGULATOR_PWM=y CONFIG_PWM_ROCKCHIP=y CONFIG_SPL_RAM=y CONFIG_BAUDRATE=150 CONFIG_DEBUG_UART_SHIFT=2 CONFIG_SYS_NS16550_MEM32=y CONFIG_SYSRESET=y +CONFIG_USB=y +CONFIG_DM_USB_GADGET=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC3=y +CONFIG_USB_DWC3_GENERIC=y CONFIG_ERRNO_STR=y
Re: [PATCH v2 4/4] rockchip: rk3588-rock-5b: Sync USB3 nodes from mainline linux patches
On 2023/10/18 01:02, Jonas Karlman wrote:
The device tree for rk3588 and rock-5b contain usb3 nodes that have
deviated too much from current state of submitted mainline linux usb3
patches, see [1].
Sync usb3 related nodes from latest patches and collaboras rk3588 tree
so that dwc3-generic driver can be updated to include support for the
rockchip,rk3588-dwc3 compatible in the future, use rockchip,rk3568-dwc3
compatible until final node is merged in linux maintainer tree.
[1]
https://lore.kernel.org/lkml/20231009172129.43568-1-sebastian.reic...@collabora.com/
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
v2:
- Use rockchip,rk3568-dwc3 compatible so that driver change can be
submitted in a separate series.
RK3588 USB 3.0 binding update [2] has not been merged for linux v6.7.
Our options is to update these nodes to latest submitted state, as done
in this patch, or to remove them until a sync of final nodes can be done.
[2]
https://lore.kernel.org/all/20231009172129.43568-2-sebastian.reic...@collabora.com/
arch/arm/dts/rk3588-rock-5b-u-boot.dtsi | 148 +++-
arch/arm/dts/rk3588-u-boot.dtsi | 39 +++
arch/arm/dts/rk3588s-u-boot.dtsi| 68 ++-
configs/rock5b-rk3588_defconfig | 1 -
4 files changed, 99 insertions(+), 157 deletions(-)
diff --git a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
index 3f390ef26a3f..b595ddef7028 100644
--- a/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
+++ b/arch/arm/dts/rk3588-rock-5b-u-boot.dtsi
@@ -19,38 +19,10 @@
regulator-min-microvolt = <1200>;
regulator-max-microvolt = <1200>;
};
+};
- vcc5v0_usbdcin: vcc5v0-usbdcin {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usbdcin";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <&vcc12v_dcin>;
- };
-
- vcc5v0_usb: vcc5v0-usb {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_usb";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- vin-supply = <&vcc5v0_usbdcin>;
- };
-
- vbus5v0_typec: vbus5v0-typec {
- compatible = "regulator-fixed";
- regulator-name = "vbus5v0_typec";
- regulator-min-microvolt = <500>;
- regulator-max-microvolt = <500>;
- enable-active-high;
- gpio = <&gpio2 RK_PB6 GPIO_ACTIVE_HIGH>;
- vin-supply = <&vcc5v0_usb>;
- pinctrl-names = "default";
- pinctrl-0 = <&typec5v_pwren>;
- };
+&combphy2_psu {
+ status = "okay";
};
&fspim2_pins {
@@ -58,13 +30,9 @@
};
&pinctrl {
- usb-typec {
+ usb {
usbc0_int: usbc0-int {
- rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
- };
-
- typec5v_pwren: typec5v-pwren {
- rockchip,pins = <2 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ rockchip,pins = <3 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
};
@@ -97,7 +65,6 @@
};
&u2phy0_otg {
- rockchip,typec-vbus-det;
status = "okay";
};
@@ -109,25 +76,17 @@
status = "okay";
};
-&usb2phy2_grf {
+&usbdp_phy1 {
status = "okay";
};
-&usb2phy3_grf {
+&usbdp_phy1_u3 {
status = "okay";
};
-&usb_host0_ehci {
- companion = <&usb_host0_ohci>;
-};
-
-&usb_host1_ehci {
- companion = <&usb_host1_ohci>;
-};
-
&usbdp_phy0 {
orientation-switch;
- svid = <0xff01>;
+ mode-switch;
sbu1-dc-gpios = <&gpio4 RK_PA6 GPIO_ACTIVE_HIGH>;
sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
@@ -135,14 +94,15 @@
port {
#address-cells = <1>;
#size-cells = <0>;
- usbdp_phy0_orientation_switch: endpoint@0 {
+
+ usbdp_phy0_typec_ss: endpoint@0 {
reg = <0>;
- remote-endpoint = <&usbc0_orien_sw>;
+ remote-endpoint = <&usbc0_ss>;
};
- usbdp_phy0_dp_altmode_mux: endpoint@1 {
+ usbdp_phy0_typec_sbu: endpoint@1 {
reg = <1>;
- remote-endpoint = <&dp_altmode_mux>;
+ remote-endpoint = <&usbc0_sbu>;
};
};
};
@@ -151,84 +111,53 @@
status = "okay";
};
-&usbdp_phy1 {
- rockchip,dp-lane-mux = <2 3>;
+&usb_host0_xhci {
+ usb-role-switch;
status = "okay";
-};
-&
Re: [PATCH 3/3] board: rockchip: Add support for RGB30 and RK2023 to RGxx3
On 2023/10/18 02:24, Chris Morgan wrote:
From: Chris Morgan
Add support for the Powkiddy RK2023 and RGB30 to the Anbernic RGxx3.
While these devices are manufactured by Powkiddy instead of Anbernic,
the hardware is so similar they can all use the same bootloader.
Signed-off-by: Chris Morgan
Reviewed-by: Kever Yang
Thanks,
- Kever
---
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 16
1 file changed, 16 insertions(+)
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index a93b11cd47..dae9dc87c2 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -60,6 +60,8 @@ enum rgxx3_device_id {
RG353P,
RG353V,
RG503,
+ RGB30,
+ RK2023,
/* Devices with duplicate ADC value */
RG353PS,
RG353VS,
@@ -95,6 +97,20 @@ static const struct rg3xx_model rg3xx_model_details[] = {
.fdtfile = DTB_DIR "rk3566-anbernic-rg503.dtb",
.detect_panel = 0,
},
+ [RGB30] = {
+ .adc_value = 383, /* Gathered from second hand information */
+ .board = "rk3566-powkiddy-rgb30",
+ .board_name = "RGB30",
+ .fdtfile = DTB_DIR "rk3566-powkiddy-rgb30.dtb",
+ .detect_panel = 0,
+ },
+ [RK2023] = {
+ .adc_value = 635, /* Observed average from device */
+ .board = "rk3566-powkiddy-rk2023",
+ .board_name = "RK2023",
+ .fdtfile = DTB_DIR "rk3566-powkiddy-rk2023.dtb",
+ .detect_panel = 0,
+ },
/* Devices with duplicate ADC value */
[RG353PS] = {
.adc_value = 860, /* Observed average from device */
Re: [PATCH 2/3] board: rockchip: Add Maskrom Mode for Anbernic RGxx3
Hi Chris,
On 2023/10/18 02:24, Chris Morgan wrote:
From: Chris Morgan
Add support for users to enter maskrom mode by holding the function
button when they power up the device.
Since the device has soldered eMMC and sometimes does not expose a clk
pin on the mainboard
This board already available, so does this clk pin available?
Not only clk, other cmd/data pin is also OK to make the soc get into
maskrom mode.
there is a small chance that a user who flashes a
bad bootloader may not be able to recover if the headers themselves
are valid. As a result this check is done during spl_early_init() to
ensure that it runs as early as possible, and it does so by directly
manipulating the ADC hardware in lieu of loading the ADC driver.
This key seems like a "recovery" adc key instead of "maskrom" key, right?
I think we don't need to add this patch if the hardware does not really
have a "maskrom" key.
Basically the "maskrom" key should not depends on any software.
Thanks,
- Kever
Ideally, once we have an open source TPL stage we can move this to
the TPL stage, so it will run even earlier.
Signed-off-by: Chris Morgan
---
board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
index 3d0c614623..a93b11cd47 100644
--- a/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
+++ b/board/anbernic/rgxx3_rk3566/rgxx3-rk3566.c
@@ -6,12 +6,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
@@ -20,6 +22,8 @@
#include
#include
+#define BOOT_BROM_DOWNLOAD 0xef08a53c
+
#define GPIO0_BASE0xfdd6
#define GPIO4_BASE0xfe77
#define GPIO_SWPORT_DR_L 0x
@@ -33,6 +37,14 @@
#define GPIO_WRITEMASK(bits) ((bits) << 16)
+#define SARADC_BASE 0xfe72
+#define SARADC_DATA0x
+#define SARADC_STAS0x0004
+#define SARADC_ADC_STATUS BIT(0)
+#define SARADC_CTRL0x0008
+#define SARADC_INPUT_SRC_MSK 0x7
+#define SARADC_POWER_CTRL BIT(3)
+
#define DTB_DIR "rockchip/"
struct rg3xx_model {
@@ -118,12 +130,64 @@ static const struct rg353_panel rg353_panel_details[] = {
},
};
+/*
+ * The device has internal eMMC, and while some devices have an exposed
+ * clk pin you can ground to force a bypass not all devices do. As a
+ * result it may be possible for some devices to become a perma-brick
+ * if a corrupted TPL or SPL stage with a valid header is flashed to
+ * the internal eMMC. Add functionality to read ADC channel 0 (the func
+ * button) as early as possible in the boot process to provide some
+ * protection against this. If we ever get an open TPL stage, we should
+ * consider moving this function there.
+ */
+void read_func_button(void)
+{
+ int ret;
+ u32 reg;
+
+ /* Turn off SARADC to reset it. */
+ writel(0, (SARADC_BASE + SARADC_CTRL));
+
+ /* Enable channel 0 and power on SARADC. */
+ writel(((0 & SARADC_INPUT_SRC_MSK) | SARADC_POWER_CTRL),
+ (SARADC_BASE + SARADC_CTRL));
+
+ /*
+* Wait for data to be ready. Use timeout of 2us from
+* rockchip_saradc driver.
+*/
+ ret = readl_poll_timeout((SARADC_BASE + SARADC_STAS), reg,
+!(reg & SARADC_ADC_STATUS), 2);
+ if (ret) {
+ printf("ADC Timeout");
+ return;
+ }
+
+ /* Read the data from the SARADC. */
+ reg = readl((SARADC_BASE + SARADC_DATA));
+
+ /* Turn the SARADC back off so it's ready to be used again. */
+ writel(0, (SARADC_BASE + SARADC_CTRL));
+
+ /*
+* If the value is less than 30 the button is being pressed.
+* Reset the device back into Rockchip download mode.
+*/
+ if (reg <= 30) {
+ printf("download key pressed, entering download mode...");
+ writel(BOOT_BROM_DOWNLOAD, CONFIG_ROCKCHIP_BOOT_MODE_REG);
+ do_reset(NULL, 0, 0, NULL);
+ }
+};
+
/*
* Start LED very early so user knows device is on. Set color
* to red.
*/
void spl_board_init(void)
{
+ read_func_button();
+
/* Set GPIO0_C5, GPIO0_C6, and GPIO0_C7 to output. */
writel(GPIO_WRITEMASK(GPIO_C7 | GPIO_C6 | GPIO_C5) | \
(GPIO_C7 | GPIO_C6 | GPIO_C5),
Re: [PATCH 1/3] mtd: spi-nor: Add support for XMC XM25QU128C
On 2023/10/18 05:40, Jonas Karlman wrote:
From: Ricardo Pardini
Add support for XMC XM25QU128C (128M-bit) Serial Flash memory. Used on
the Xunlong Orange Pi 3B, 5 and 5 Plus boards.
Datasheet:
https://www.xmcwh.com/uploads/806/XM25QU128C_Ver2.0.pdf
Signed-off-by: Ricardo Pardini
[jo...@kwiboo.se: update commit message]
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
drivers/mtd/spi/spi-nor-ids.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 5c35171ffd55..392db5c99e84 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -536,6 +536,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("XM25QH64A", 0x207017, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("XM25QH64C", 0x204017, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("XM25QH128A", 0x207018, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+ { INFO("XM25QU128C", 0x204118, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
#endif
#ifdef CONFIG_SPI_FLASH_XTX
/* XTX Technology Limited */
Re: [PATCH 2/3] board: rockchip: Add Xunlong Orange Pi 5
On 2023/10/18 05:40, Jonas Karlman wrote:
Xunlong Orange Pi 5 is a single-board computer based on the Rockchip
RK3588S SoC. The board provides abundant interfaces, HDMI output, GPIO
interface, M.2 PCIe2.0, Type-C, Gigabit LAN port, 2*USB2.0, 1*USB3.0,
etc.
Features tested on a Orange Pi 5 4GB v1.2:
- SD-card boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Cc: Muhammed Efe Cetin
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi | 22 +
arch/arm/dts/rk3588s-orangepi-5.dts | 662
board/rockchip/evb_rk3588/MAINTAINERS | 7 +
configs/orangepi-5-rk3588s_defconfig| 102 +++
doc/board/rockchip/rockchip.rst | 1 +
6 files changed, 795 insertions(+)
create mode 100644 arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588s-orangepi-5.dts
create mode 100644 configs/orangepi-5-rk3588s_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 490709359553..fd99bb76fa6b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -192,6 +192,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
rk3588-nanopc-t6.dtb \
+ rk3588s-orangepi-5.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi b/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
new file mode 100644
index ..888d1b9c12d7
--- /dev/null
+++ b/arch/arm/dts/rk3588s-orangepi-5-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc;
+ };
+};
+
+&fspim0_pins {
+ bootph-all;
+};
+
+&sfc {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+
+ flash@0 {
+ bootph-pre-ram;
+ };
+};
diff --git a/arch/arm/dts/rk3588s-orangepi-5.dts
b/arch/arm/dts/rk3588s-orangepi-5.dts
new file mode 100644
index ..8f399c4317bd
--- /dev/null
+++ b/arch/arm/dts/rk3588s-orangepi-5.dts
@@ -0,0 +1,662 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include "rk3588s.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5";
+ compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdmmc;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <1800>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 =<&leds_gpio>;
+
+ led-1 {
+ gpios = <&gpio1 RK_PA2 GPIO_ACTIVE_HIGH>;
+ label = "status_led";
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ vbus_typec: vbus-typec-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpio = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&typec5v_pwren>;
+ regulator-name = "vbus_typec";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc5v0_sys: vcc5v0-sys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ vcc_3v3_sd_s0: vcc-3v3-sd-s0-regulator {
+ compatible = "regulator-fixed";
+ enable-active-low;
+ gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
+ regulator-name = "vcc_3v3_sd_s0";
+ regulator-boot-on;
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_pcie20: vcc3v3-pcie20-regulator {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC5 GPIO_ACTIVE
Re: [PATCH 3/3] board: rockchip: Add Xunlong Orange Pi 5 Plus
On 2023/10/18 05:40, Jonas Karlman wrote:
Xunlong Orange Pi 5 Plus is a single-board computer based on the
Rockchip RK3588 SoC. The board provides abundant interfaces, including
two HDMI output ports, one HDMI input port, two 2.5G Ethernet ports,
M.2 M-Key slot, M.2 E-Key slot, two USB 3.0, two USB 2.0, and two Type-C.
Features tested on a Orange Pi 5 Plus 4GB v1.2:
- SD-card boot
- eMMC boot
- SPI Flash boot
- PCIe/NVMe
- USB 2.0 host
- Ethernet
Device tree is imported from linux v6.7-rockchip-dts64-1 tag.
Signed-off-by: Jonas Karlman
Reviewed-by: Kever Yang
Thanks,
- Kever
---
Cc: Ondrej Jirman
---
arch/arm/dts/Makefile | 1 +
.../dts/rk3588-orangepi-5-plus-u-boot.dtsi| 27 +
arch/arm/dts/rk3588-orangepi-5-plus.dts | 848 ++
board/rockchip/evb_rk3588/MAINTAINERS | 7 +
configs/orangepi-5-plus-rk3588_defconfig | 105 +++
doc/board/rockchip/rockchip.rst | 1 +
6 files changed, 989 insertions(+)
create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-orangepi-5-plus.dts
create mode 100644 configs/orangepi-5-plus-rk3588_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index fd99bb76fa6b..c1a760592df5 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -193,6 +193,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-evb1-v10.dtb \
rk3588-nanopc-t6.dtb \
rk3588s-orangepi-5.dtb \
+ rk3588-orangepi-5-plus.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi b/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
new file mode 100644
index ..b0f5c667197c
--- /dev/null
+++ b/arch/arm/dts/rk3588-orangepi-5-plus-u-boot.dtsi
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
+ };
+};
+
+&fspim1_pins {
+ bootph-all;
+};
+
+&sdhci {
+ cap-mmc-highspeed;
+ mmc-hs200-1_8v;
+};
+
+&sfc {
+ bootph-pre-ram;
+ u-boot,spl-sfc-no-dma;
+
+ flash@0 {
+ bootph-pre-ram;
+ };
+};
diff --git a/arch/arm/dts/rk3588-orangepi-5-plus.dts
b/arch/arm/dts/rk3588-orangepi-5-plus.dts
new file mode 100644
index ..298c183d6f4f
--- /dev/null
+++ b/arch/arm/dts/rk3588-orangepi-5-plus.dts
@@ -0,0 +1,848 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Plus";
+ compatible = "xunlong,orangepi-5-plus", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys-0 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-maskrom {
+ label = "Mask Rom";
+ linux,code = ;
+ press-threshold-microvolt = <2000>;
+ };
+ };
+
+ adc-keys-1 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-recovery {
+ label = "Recovery";
+ linux,code = ;
+ press-threshold-microvolt = <2000>;
+ };
+ };
+
+ speaker_amp: speaker-audio-amplifier {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = <&gpio3 RK_PC0 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Speaker Amp";
+ };
+
+ headphone_amp: headphones-audio-amplifier {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Headphones Amp";
+ };
+
+ ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio4 RK_PB3 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&ir_receiver_pin>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&blue_led_pin>;
+
+ led {
+ color = ;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <1>;
+ gpios = <&g
Re: [PATCH v2 1/2] dt-bindings: leds: import common led bindings from linux v6.5
On 2023/10/17 23:59, Tom Fitzhenry wrote:
This brings in more colours, e.g. ORANGE needed for the QuartzPro64 DT.
Linux commits:
472d7b9e8141 ("dt-bindings: leds: Expand LED_COLOR_ID definitions")
Signed-off-by: Tom Fitzhenry
Reviewed-by: Kever Yang
Thanks,
- Kever
---
include/dt-bindings/leds/common.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/leds/common.h
b/include/dt-bindings/leds/common.h
index 3be89a7c20a..9a0d33d027f 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -33,7 +33,12 @@
#define LED_COLOR_ID_MULTI8 /* For multicolor LEDs */
#define LED_COLOR_ID_RGB 9 /* For multicolor LEDs that can do
arbitrary color,
so this would include RGBW and
similar */
-#define LED_COLOR_ID_MAX 10
+#define LED_COLOR_ID_PURPLE10
+#define LED_COLOR_ID_ORANGE11
+#define LED_COLOR_ID_PINK 12
+#define LED_COLOR_ID_CYAN 13
+#define LED_COLOR_ID_LIME 14
+#define LED_COLOR_ID_MAX 15
/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
Please pull u-boot-video
Hi Tom, please pull video driver updates for v2024.01-rc1. CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/18257 Thanks! The following changes since commit 9a3a58396b78b1f9d0c14580dc03f81d29207dd2: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2023-10-20 12:54:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-video.git tags/video-20231022 for you to fetch changes up to 846dcae7337e25d1608c891fb68ce4227bc6b710: video: tegra20: dsi: use regulator_set_enable_if_allowed (2023-10-22 19:28:31 +0200) - updates for pwm_backlight, simple_panel and tegra20 to keep fixed/gpio regulator counter in balance Svyatoslav Ryhel (3): video: pwm_backlight: use regulator_set_enable_if_allowed video: simple_panel: use regulator_set_enable_if_allowed video: tegra20: dsi: use regulator_set_enable_if_allowed drivers/video/pwm_backlight.c | 13 ++--- drivers/video/simple_panel.c | 10 +- drivers/video/tegra20/tegra-dsi.c | 8 +++- 3 files changed, 14 insertions(+), 17 deletions(-)
Re: [PATCH v2 2/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board
On 2023/10/17 23:59, Tom Fitzhenry wrote:
QuartzPro64 is a Rockchip RK3588 based SBC by Pine64.
UART and boot over SD/eMMC/RJ45 are tested to work.
Linux commits from next-20231013:
8152d3d070a9 ("arm64: dts: rockchip: Add QuartzPro64 SBC device tree")
Signed-off-by: Tom Fitzhenry
Cc: Eugen Hristev
Cc: Jonas Karlman
Cc: Ondrej Jirman
---
This patch depends on "rockchip: rk3588: Sync device tree from linux
maintainer tree"[0], since the QuartzPro64 upstream DT depends on upstream
dtsi changes.
This patch has been update to V2, and your patch are not able to apply
any more.
Please help to rebase it.
Thanks,
- Kever
0. https://lore.kernel.org/all/20231010222344.3436526-2-jo...@kwiboo.se
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi | 12 +
arch/arm/dts/rk3588-quartzpro64.dts | 1137 +
arch/arm/mach-rockchip/rk3588/Kconfig |8 +
board/pine64/quartzpro64-rk3588/Kconfig | 15 +
board/pine64/quartzpro64-rk3588/MAINTAINERS |8 +
board/pine64/quartzpro64-rk3588/Makefile |3 +
.../quartzpro64-rk3588/quartzpro64-rk3588.c | 39 +
configs/quartzpro64-rk3588_defconfig | 72 ++
doc/board/rockchip/rockchip.rst |1 +
include/configs/quartzpro64-rk3588.h | 14 +
11 files changed, 1310 insertions(+)
create mode 100644 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-quartzpro64.dts
create mode 100644 board/pine64/quartzpro64-rk3588/Kconfig
create mode 100644 board/pine64/quartzpro64-rk3588/MAINTAINERS
create mode 100644 board/pine64/quartzpro64-rk3588/Makefile
create mode 100644 board/pine64/quartzpro64-rk3588/quartzpro64-rk3588.c
create mode 100644 configs/quartzpro64-rk3588_defconfig
create mode 100644 include/configs/quartzpro64-rk3588.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4569483d5fd..6d1e33d9e2e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+ rk3588-quartzpro64.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
new file mode 100644
index 000..191ec988c45
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Google, Inc
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
+ };
+};
diff --git a/arch/arm/dts/rk3588-quartzpro64.dts
b/arch/arm/dts/rk3588-quartzpro64.dts
new file mode 100644
index 000..5c59f9571dc
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64.dts
@@ -0,0 +1,1137 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ model = "PINE64 QuartzPro64";
+ compatible = "pine64,quartzpro64", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys-0 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-maskrom {
+ label = "Mask Rom";
+ linux,code = ;
+ press-threshold-microvolt = <393>;
+ };
+ };
+
+ adc-keys-1 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-volume-up {
+ label = "V+/REC";
+ linux,code = ;
+ press-threshold-microvolt = <17821>;
+ };
+
+ button-volume-down {
+ label = "V-";
+ linux,code = ;
+ press-threshold-microvolt = <415384>;
+ };
+
+ button-menu {
+ label = "MENU";
+ linux,code = ;
+ press-threshold-microvolt = <890909>;
+ };
+
+ button-esc {
+ label = "ESC";
+ linux,code = ;
+ press-threshold-microvolt = <1233962>;
+ };
+ };
+
+ headphone_am
Re: [PATCH 2/6] led-uclass: honour ->label field populated by driver's own .bind
Am Mo., 23. Okt. 2023 um 11:30 Uhr schrieb Rasmus Villemoes
:
>
> On 19/10/2023 15.54, Marek Vasut wrote:
> > On 10/19/23 11:58, Rasmus Villemoes wrote:
> >> If the driver's own .bind method has populated uc_plat->label, don't
> >> override that. This is necessary for an upcoming driver for ti,lp5562,
> >> where the DT binding unfortunately says to use "chan-name" and not
> >> "label".
> >>
> >> Signed-off-by: Rasmus Villemoes
> >> ---
> >> drivers/led/led-uclass.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
> >> index 5a5d07b9a7..0232fa84de 100644
> >> --- a/drivers/led/led-uclass.c
> >> +++ b/drivers/led/led-uclass.c
> >> @@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
> >> struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> >> const char *default_state;
> >> -uc_plat->label = dev_read_string(dev, "label");
> >> +if (!uc_plat->label)
> >> +uc_plat->label = dev_read_string(dev, "label");
> >> +
> >
> > One thing I have to wonder about is, why does this controller have label
> > property in the top-level node , what is that used for ?
> >
> > (see Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml)
> >
> > Reviewed-by: Marek Vasut
>
> Reading the linux driver, it seems that the top-level label, if any, is
> used as part of the naming for individual channels if they don't have
> individual chan-name properties:
>
>
> if (pdata->led_config[chan].name) {
> led->cdev.name = pdata->led_config[chan].name;
> } else {
> snprintf(name, sizeof(name), "%s:channel%d",
> pdata->label ? : chip->cl->name, chan);
> led->cdev.name = name;
> }
>
> but I think the rationale in d1188adb2dabc is a bit weak, since the only
> example also does have individual chan-name properties.
>
> [Complete aside: At first I thought it was related to the multi-color
> LED work that has been ongoing for many many years (I think there was an
> LWN article at some point), where this could be exposed as a single
> multi-color LED, as opposed to the "traditional" three/four individual
> LEDs. In the former case, there would only be one sysfs entry, but with
> attributes exposing the multicolor functionality. I must admit I don't
> know the status of that work, when something reaches v31,
> http://archive.lwn.net:8080/linux-kernel/20200722071055.GA8984@amd/t/ ,
> it's hard to know if it ever lands, or if pieces of it has landed.]
>
> Rasmus
>
I have an almost similar patch sent out today as I have not seen yours
before. The end results
is the same as mine
https://patchwork.ozlabs.org/project/uboot/patch/20231023082117.39290-1-christian.gmei...@gmail.com/
Reviewed-by: Christian Gmeiner
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
Re: [PATCH 1/6] led-uclass: do not create fallback label for top-level node
On 10/23/23 10:28, Rasmus Villemoes wrote:
On 19/10/2023 15.51, Marek Vasut wrote:
On 10/19/23 11:58, Rasmus Villemoes wrote:
Many existing drivers, and led-uclass itself, rely on uc_plat->label
being NULL for the device representing the top node, as opposed to the
child nodes representing individual LEDs. This means that the drivers
whose .probe methods rely on this were broken by 83c63f0d1185 ("led:
Move OF "label" property parsing to core"), and also that the top node
wrongly shows up with 'led list'. Some drivers have since been fixed
up individually, e.g.
e3aa76644c2a "led: gpio: Check device compatible string to determine
the top level node"
01074697801b "led: gpio: Use NOP uclass driver for top-level node"
910b01c27c04 "drivers: led: bcm6753: do not use null label to find the
top"
Binding the same driver to the top node as to the individual child
nodes is arguably wrong, and the approach of using a UCLASS_NOP driver
for the top node is probably better.
Note that
83c63f0d1185 ("led: Move OF "label" property parsing to core")
and
01074697801b ("led: gpio: Use NOP uclass driver for top-level node")
were applied shortly after each other, so I don't see the point of the
aforementioned rant.
What rant? I'm merely trying to write down what I found out while trying
to figure out why 83c63f0d1185 broke stuff, while acknowledging that the
fixes that have been applied to some drivers are probably the approach
in general.
I sort-of understand what you are trying to do in this patch based on
$SUBJECT of this email, but not from this wall of text, so can you
abbreviate the commit message ?
Sure, I can try and make it shorter.
- if (!uc_plat->label)
+ if (!uc_plat->label && !dev_read_string(dev, "compatible"))
uc_plat->label = ofnode_get_name(dev_ofnode(dev));
Is there an existing driver which has a top-level DT node with "label"
property ?
-ENOPARSE? A driver doesn't have a top-level DT node.
I mean, is there a driver which does:
/ {
led {
label = "example";
};
};
?
I think that is what the conditional checks here, right ?
And regardless, this wouldn't change anything for a top-level DT node
with a "label" property, as we're still unconditionally first trying to
read a "label" property, this is merely avoiding adding a fallback value
for top-level DT nodes (using "having a "compatible" DT property as
proxy for that "is a top-level DT node"). So I really don't understand
what you are trying to ask.
Re: [PATCH 2/6] led-uclass: honour ->label field populated by driver's own .bind
On 10/23/23 10:51, Rasmus Villemoes wrote:
On 19/10/2023 15.54, Marek Vasut wrote:
On 10/19/23 11:58, Rasmus Villemoes wrote:
If the driver's own .bind method has populated uc_plat->label, don't
override that. This is necessary for an upcoming driver for ti,lp5562,
where the DT binding unfortunately says to use "chan-name" and not
"label".
Signed-off-by: Rasmus Villemoes
---
drivers/led/led-uclass.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/led/led-uclass.c b/drivers/led/led-uclass.c
index 5a5d07b9a7..0232fa84de 100644
--- a/drivers/led/led-uclass.c
+++ b/drivers/led/led-uclass.c
@@ -71,7 +71,9 @@ static int led_post_bind(struct udevice *dev)
struct led_uc_plat *uc_plat = dev_get_uclass_plat(dev);
const char *default_state;
- uc_plat->label = dev_read_string(dev, "label");
+ if (!uc_plat->label)
+ uc_plat->label = dev_read_string(dev, "label");
+
One thing I have to wonder about is, why does this controller have label
property in the top-level node , what is that used for ?
(see Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml)
Reviewed-by: Marek Vasut
Reading the linux driver, it seems that the top-level label, if any, is
used as part of the naming for individual channels if they don't have
individual chan-name properties:
if (pdata->led_config[chan].name) {
led->cdev.name = pdata->led_config[chan].name;
} else {
snprintf(name, sizeof(name), "%s:channel%d",
pdata->label ? : chip->cl->name, chan);
led->cdev.name = name;
}
but I think the rationale in d1188adb2dabc is a bit weak, since the only
example also does have individual chan-name properties.
[Complete aside: At first I thought it was related to the multi-color
LED work that has been ongoing for many many years (I think there was an
LWN article at some point), where this could be exposed as a single
multi-color LED, as opposed to the "traditional" three/four individual
LEDs. In the former case, there would only be one sysfs entry, but with
attributes exposing the multicolor functionality. I must admit I don't
know the status of that work, when something reaches v31,
http://archive.lwn.net:8080/linux-kernel/20200722071055.GA8984@amd/t/ ,
it's hard to know if it ever lands, or if pieces of it has landed.]
+CC Pavel
Re: [PATCH 6/6] led: add TI LP5562 LED driver
On 10/23/23 11:11, Rasmus Villemoes wrote: On 19/10/2023 15.58, Marek Vasut wrote: On 10/19/23 11:58, Rasmus Villemoes wrote: From: Doug Zobel Driver for the TI LP5562 4 channel LED controller. Supports independent on/off control of all 4 channels. Supports LED_BLINK on 3 independent channels: blue/green/red. The white channel can blink, but shares the blue channel blink rate. Heavily based on patch originally from Doug Zobel [1]. I have modified it so it matches the DT bindings in the linux tree, and also follows the linux driver implementation more closely. This should address Tom's concerns, and also matches my goal of making the U-Boot driver work with our existing .dts which is known to work in linux. As our boards only have the R,G,B outputs connected, I have not actually tested how the white channel behaves, but the R,G,B work exactly as expected. [1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/ Cc: Doug Zobel Signed-off-by: Rasmus Villemoes --- doc/device-tree-bindings/leds/leds-lp5562.txt | 63 ++ drivers/led/Kconfig | 8 + drivers/led/Makefile | 1 + drivers/led/led_lp5562.c | 578 ++ 4 files changed, 650 insertions(+) create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt create mode 100644 drivers/led/led_lp5562.c diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt b/doc/device-tree-bindings/leds/leds-lp5562.txt new file mode 100644 index 00..4e0c742959 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-lp5562.txt Why not use Linux Documentation/devicetree/bindings/leds/leds-lp55xx.yaml ? Because I'm not adding support for all the devices covered by that binding, nor for all the properties defined there (and some of those, I think, do not even make sense for the lp5562 but only apply to some of the other variants). Using old bindings like that will only cause divergence, please dont do that. [...] --- /dev/null +++ b/drivers/led/led_lp5562.c @@ -0,0 +1,578 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Doug Zobel Why not port Linux drivers/leds/leds-lp5562.c ? Because that would be way more work to make that fit into U-Boot's LED framework than to take Doug's initial patch and make it build against current U-Boot. Seems the drivers are just about the same complexity, so why not port the new Linux one ?
Pull request: u-boot-sunxi/master for v2024.01
Hi Tom, please pull the sunxi/master branch, containing the first part of the 2024.01 changes. Apologies for the late PR, there were quite some recent activities (fixes and reviews), but I didn't want to delay this series any longer, since it's been around one year in the making already: This is mostly about support for the Allwinner R528/T113s SoC, which is reportedly the same die as the Allwinner D1, but with the two Arm Cortex-A7 cores activated instead of the RISC-V one. Using sunxi code outside of arch/arm proved to be difficult, so apart from enabling this Arm SoC, the patches also prepare for more refactoring to get the D1 nicely supported some day: - We get rid of some Kconfig (hard-)coded GPIO pins, responsible for enabling regulators. - The GPIO code is moved out of arch/arm, into drivers/gpio. - Some definitions are moved out of header files under asm/arch. - Some T113s/D1 specific definitions are guarded by a generic Kconfig symbol (CONFIG_SUNXI_GEN_NCAT2). - The DRAM controller initialisation code is located under drivers/ram. - The base SoC .dtsi files are shared (under arch/riscv, as in Linux). Of course there are also the usual new SoC specific patches, like clock and pinmux descriptions, alongside a rework of the pinctrl code, since Allwinner changed the GPIO register layout, for the first time since sunxi's inception. On top of this the PSCI code sees some update, to provide SMP services for R528/T113s boards. Many thanks to Sam for providing this code and staying strong through the review cycles. The final patch enables support for one popular board, I hope to see more DTs and defconfigs contributed in the future! Many thanks to all the various contributors, testers and reviewers, that series was a real team effort! The gitlab CI completed successfully. Thanks, Andre === The following changes since commit 9a3a58396b78b1f9d0c14580dc03f81d29207dd2: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2023-10-20 12:54:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master for you to fetch changes up to fa066df62ed9bfe0aed7749a68457468ad8bcc1c: sunxi: add MangoPi MQ-R board support (2023-10-23 01:00:56 +0100) Andre Przywara (21): sunxi: dts: arm64: update devicetree files from Linux-v6.6-rc6 sunxi: dts: arm: update devicetree files from Linux-v6.6-rc6 sunxi: dts: arm: add T113s/D1 DT files from Linux-v6.6-rc6 sunxi: remove CONFIG_SATAPWR net: sunxi_emac: chase DT nodes to find PHY regulator sunxi: remove CONFIG_MACPWR pinctrl: sunxi: move pinctrl code pinctrl: sunxi: add GPIO in/out wrappers pinctrl: sunxi: remove struct sunxi_gpio pinctrl: sunxi: remove GPIO_EXTRA_HEADER pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h pinctrl: sunxi: add new D1 pinctrl support sunxi: introduce NCAT2 generation model pinctrl: sunxi: add Allwinner D1 pinctrl description sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup sunxi: clock: support D1/R528 PLL6 clock Kconfig: sunxi: prepare for using drivers/ram/sunxi sunxi: add R528/T113-s3/D1(s) DRAM initialisation code sunxi: add Allwinner R528/T113 SoC support sunxi: refactor serial base addresses to avoid asm/arch/cpu.h sunxi: add MangoPi MQ-R board support Okhunjon Sobirjonov (1): sunxi: R528: add SMHC2 pin pull ups support Sam Edwards (4): sunxi: psci: clean away preprocessor macros sunxi: psci: refactor register access to separate functions sunxi: psci: stop modeling register layout with C structs sunxi: psci: implement PSCI on R528 Samuel Holland (1): clk: sunxi: Add support for the D1 CCU arch/arm/Kconfig |3 +- arch/arm/cpu/armv7/Kconfig |3 +- arch/arm/cpu/armv7/sunxi/psci.c| 190 ++- arch/arm/cpu/armv7/sunxi/sram.c|1 + arch/arm/cpu/armv8/fel_utils.S |1 + arch/arm/dts/Makefile |2 + arch/arm/dts/axp209.dtsi |7 + arch/arm/dts/sun50i-a64.dtsi |3 +- arch/arm/dts/sun50i-h6-pine-h64-model-b.dts|2 +- arch/arm/dts/sun50i-h616-orangepi-zero.dtsi| 134 ++ arch/arm/dts/sun50i-h616-orangepi-zero2.dts| 121 +- arch/arm/dts/sun50i-h616-x96-mate.dts |2 +- arch/arm/dts/sun50i-h618-orangepi-zero3.dts| 94 ++ arch/arm/dts/sun5i-r8-chip.dts |6 + arch/arm/dts/sun5i.dtsi| 11 +- arch/arm/dts/sun7i-a20-icnova-a20-adb4006.dts | 137 ++ arch/arm/dts/sun7i-a20-icnova-a20.dtsi | 62 + arch/arm/dts/sun8i-a23-a33.dtsi|2 +- arch/arm/dts/sun8i-a83t.dtsi
Re: [PATCH 6/6] led: add TI LP5562 LED driver
On 23/10/2023 11.39, Marek Vasut wrote: > On 10/23/23 11:11, Rasmus Villemoes wrote: >> On 19/10/2023 15.58, Marek Vasut wrote: >>> On 10/19/23 11:58, Rasmus Villemoes wrote: From: Doug Zobel Driver for the TI LP5562 4 channel LED controller. Supports independent on/off control of all 4 channels. Supports LED_BLINK on 3 independent channels: blue/green/red. The white channel can blink, but shares the blue channel blink rate. Heavily based on patch originally from Doug Zobel [1]. I have modified it so it matches the DT bindings in the linux tree, and also follows the linux driver implementation more closely. This should address Tom's concerns, and also matches my goal of making the U-Boot driver work with our existing .dts which is known to work in linux. As our boards only have the R,G,B outputs connected, I have not actually tested how the white channel behaves, but the R,G,B work exactly as expected. [1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zo...@climate.com/ Cc: Doug Zobel Signed-off-by: Rasmus Villemoes --- doc/device-tree-bindings/leds/leds-lp5562.txt | 63 ++ drivers/led/Kconfig | 8 + drivers/led/Makefile | 1 + drivers/led/led_lp5562.c | 578 ++ 4 files changed, 650 insertions(+) create mode 100644 doc/device-tree-bindings/leds/leds-lp5562.txt create mode 100644 drivers/led/led_lp5562.c diff --git a/doc/device-tree-bindings/leds/leds-lp5562.txt b/doc/device-tree-bindings/leds/leds-lp5562.txt new file mode 100644 index 00..4e0c742959 --- /dev/null +++ b/doc/device-tree-bindings/leds/leds-lp5562.txt >>> >>> Why not use Linux >>> Documentation/devicetree/bindings/leds/leds-lp55xx.yaml ? >> >> Because I'm not adding support for all the devices covered by that >> binding, nor for all the properties defined there (and some of those, I >> think, do not even make sense for the lp5562 but only apply to some of >> the other variants). > > Using old bindings like that will only cause divergence, please dont do > that. I am not doing that (i.e. using old bindings). Compared to Doug's original patch, I _have_ changed that .txt file to match the existing linux binding and hence my existing .dts. And made all the corresponding (mostly mechanical) changes in the driver. Which I also mentioned in the commit log: I have modified it so it matches the DT bindings in the linux tree, For example reading some property values using dev_read_u8, because for some reason the binding specifies that the values are /bits/8. If you want I can spell out all the changes I made. It just doesn't make sense to have that kind of info in the commit log. >>> [...] >>> --- /dev/null +++ b/drivers/led/led_lp5562.c @@ -0,0 +1,578 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Doug Zobel >>> >>> Why not port Linux drivers/leds/leds-lp5562.c ? >> >> Because that would be way more work to make that fit into U-Boot's LED >> framework than to take Doug's initial patch and make it build against >> current U-Boot. > > Seems the drivers are just about the same complexity, so why not port > the new Linux one ? So how did you measure the complexity? LOC? If so, you may have missed drivers/leds/leds-lp55xx-common.[ch]. They are far from the same complexity, and the linux driver simply has tons of gunk that would have to be removed or #ifdef'ed out to compile in U-Boot, and I'd still need to add the U-Boot-specific glue for the struct led_ops etc. In the end I don't think much more than the register defines could actually be reused. And since I now have a driver that actually works I don't really want to try and see what it would take to port the linux driver. It even includes blink support, for which there is AFAIK no equivalent API in linux, so that would have to be implemented separately on top - I don't need it, but left it in (and tested it) because it was in Doug's original patch. If I removed that it would be cut at least 1/3 of the lines. Rasmus
Re: [RFC PATCH 1/5] arm: mach-k3: common: Reserve video memory from end of the RAM
Hi Simon,
Thanks for the review.
On 19/10/23 19:26, Simon Glass wrote:
> Hi Devarsh,
>
> On Mon, 16 Oct 2023 at 10:06, Devarsh Thakkar wrote:
>>
>> Move the function to setup video memory before page table
>> reservation so that framebuffer memory gets reserved from
>> the end of RAM.
>>
>> This is as per the new policy being discussed for passing
>> blobs where each of the reserved areas for bloblists
>> to be passed need to be reserved at the end of RAM.
>>
>> This is to enable the next stage to directly skip
>> the pre-reserved area from previous stage without
>> having to making any gaps/holes to accomodate those
>> regions which was the case if previous stage
>> reserved region say somewhere in the middle and not at
>> the end of RAM.
>>
>> Suggested-by: Simon Glass
>> Signed-off-by: Devarsh Thakkar
>> ---
>> arch/arm/mach-k3/common.c | 21 +
>> 1 file changed, 21 insertions(+)
>>
>> diff --git a/arch/arm/mach-k3/common.c b/arch/arm/mach-k3/common.c
>> index cc755dd1bf..3978b9ccca 100644
>> --- a/arch/arm/mach-k3/common.c
>> +++ b/arch/arm/mach-k3/common.c
>> @@ -27,6 +27,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #if IS_ENABLED(CONFIG_SYS_K3_SPL_ATF)
>> enum {
>> @@ -522,6 +523,24 @@ void remove_fwl_configs(struct fwl_data *fwl_data,
>> size_t fwl_data_size)
>> }
>> }
>>
>> +static int video_setup(void)
>
> Shouldn't this be in generic code?
>
The reason I kept it here instead of video-uclass was since this function also
uses and updates gd->relocaddr and not just reserves the memory region and I
don't see any function in video-uclass playing with gd->relocaddr
and this is inspired by and parallel to reserve_video from common/board_f.c
which is also static function defined in board_f instead of video-uclass.
This basically is a wrapper function which calls video_reserve and also
uses/updates gd->relocaddr, since I am calling this for SPL I could not find
any common layer to define this since most vendors call board_init_f from
platform specific file which in turn call this function.
Could you please share your opinion and suggestions for generic location if
above still not look good?
Regards
Devarsh
>> +{
>> + if (CONFIG_IS_ENABLED(VIDEO)) {
>> + ulong addr;
>> + int ret;
>> +
>> + addr = gd->relocaddr;
>> + ret = video_reserve(&addr);
>> + if (ret)
>> + return ret;
>> + debug("Reserving %luk for video at: %08lx\n",
>> + ((unsigned long)gd->relocaddr - addr) >> 10, addr);
>> + gd->relocaddr = addr;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> void spl_enable_dcache(void)
>> {
>> #if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
>> @@ -537,6 +556,8 @@ void spl_enable_dcache(void)
>> if (ram_top >= 0x1)
>> ram_top = (phys_addr_t) 0x1;
>>
>> + gd->relocaddr = ram_top;
>> + video_setup();
>> gd->arch.tlb_addr = ram_top - gd->arch.tlb_size;
>> gd->arch.tlb_addr &= ~(0x1 - 1);
>> debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
>> --
>> 2.34.1
>>
>
> Regards,
> Simon
[PATCH 0/4] ARM: meson: Add boot over DFU RAM as an USB boot step
Add boot over DFU RAM as an alternate to running script at a fixed address like done today. The main culprit is that it's not possible to do that on G12A/SM1 platforms due to changes in the USB boot protocol. With this, U-Boot will present a DFU device with a ram slot where the Host could write a fitImage or legacy U-Boot image, then with the detach command boot will continue trying to boot the uploaded image. Signed-off-by: Neil Armstrong --- Neil Armstrong (4): ARM: meson: enable FIT with LEGACY_IMAGE_FORMAT on all configs configs: meson64: declare addr out of EXTRA_ENV_SETTINGS configs: meson64: add alternate USB DFU boot target ARM: meson: enable USB DFU + RAM on Amlogic boards with USB Gadget configs/ad401_defconfig | 2 ++ configs/bananapi-cm4-cm4io_defconfig | 6 configs/bananapi-m2-pro_defconfig | 6 configs/bananapi-m2s_defconfig| 6 configs/bananapi-m5_defconfig | 6 configs/beelink-gsking-x_defconfig| 6 configs/beelink-gt1-ultimate_defconfig| 6 configs/beelink-gtking_defconfig | 6 configs/beelink-gtkingpro_defconfig | 6 configs/jethub_j100_defconfig | 6 configs/jethub_j80_defconfig | 6 configs/khadas-vim2_defconfig | 6 configs/khadas-vim3_android_ab_defconfig | 4 +++ configs/khadas-vim3_android_defconfig | 4 +++ configs/khadas-vim3_defconfig | 6 configs/khadas-vim3l_android_ab_defconfig | 4 +++ configs/khadas-vim3l_android_defconfig| 4 +++ configs/khadas-vim3l_defconfig| 6 configs/khadas-vim_defconfig | 6 configs/libretech-ac_defconfig| 6 configs/libretech-cc_defconfig| 6 configs/libretech-cc_v2_defconfig | 6 configs/libretech-s905d-pc_defconfig | 6 configs/libretech-s912-pc_defconfig | 6 configs/nanopi-k2_defconfig | 4 +++ configs/odroid-c2_defconfig | 4 +++ configs/odroid-c4_defconfig | 6 configs/odroid-go-ultra_defconfig | 6 configs/odroid-hc4_defconfig | 6 configs/odroid-n2_defconfig | 6 configs/odroid-n2l_defconfig | 6 configs/p200_defconfig| 4 +++ configs/p201_defconfig| 4 +++ configs/p212_defconfig| 4 +++ configs/radxa-zero2_defconfig | 6 configs/radxa-zero_defconfig | 6 configs/s400_defconfig| 6 configs/sei510_defconfig | 6 configs/sei610_defconfig | 6 configs/u200_defconfig| 6 configs/videostrong-kii-pro_defconfig | 4 +++ configs/wetek-core2_defconfig | 6 configs/wetek-hub_defconfig | 4 +++ configs/wetek-play2_defconfig | 4 +++ include/configs/meson64.h | 49 ++- 45 files changed, 278 insertions(+), 7 deletions(-) --- base-commit: 9a0cf3993f71043ba08c315572c54622de42d447 change-id: 20231023-usb-dfu-boot-f47849f9fb34 Best regards, -- Neil Armstrong
[PATCH 1/4] ARM: meson: enable FIT with LEGACY_IMAGE_FORMAT on all configs
Allow all boards to boot with a fitImage, but keep support for Legacy image format for now. Signed-off-by: Neil Armstrong --- configs/bananapi-cm4-cm4io_defconfig | 4 configs/bananapi-m2-pro_defconfig | 4 configs/bananapi-m2s_defconfig| 4 configs/bananapi-m5_defconfig | 4 configs/beelink-gsking-x_defconfig| 4 configs/beelink-gt1-ultimate_defconfig| 4 configs/beelink-gtking_defconfig | 4 configs/beelink-gtkingpro_defconfig | 4 configs/jethub_j100_defconfig | 4 configs/jethub_j80_defconfig | 4 configs/khadas-vim2_defconfig | 4 configs/khadas-vim3_android_ab_defconfig | 4 configs/khadas-vim3_android_defconfig | 4 configs/khadas-vim3_defconfig | 4 configs/khadas-vim3l_android_ab_defconfig | 4 configs/khadas-vim3l_android_defconfig| 4 configs/khadas-vim3l_defconfig| 4 configs/khadas-vim_defconfig | 4 configs/libretech-ac_defconfig| 4 configs/libretech-cc_defconfig| 4 configs/libretech-cc_v2_defconfig | 4 configs/libretech-s905d-pc_defconfig | 4 configs/libretech-s912-pc_defconfig | 4 configs/nanopi-k2_defconfig | 4 configs/odroid-c2_defconfig | 4 configs/odroid-c4_defconfig | 4 configs/odroid-go-ultra_defconfig | 4 configs/odroid-hc4_defconfig | 4 configs/odroid-n2_defconfig | 4 configs/odroid-n2l_defconfig | 4 configs/p200_defconfig| 4 configs/p201_defconfig| 4 configs/p212_defconfig| 4 configs/radxa-zero2_defconfig | 4 configs/radxa-zero_defconfig | 4 configs/s400_defconfig| 4 configs/sei510_defconfig | 4 configs/sei610_defconfig | 4 configs/u200_defconfig| 4 configs/videostrong-kii-pro_defconfig | 4 configs/wetek-core2_defconfig | 4 configs/wetek-hub_defconfig | 4 configs/wetek-play2_defconfig | 4 43 files changed, 172 insertions(+) diff --git a/configs/bananapi-cm4-cm4io_defconfig b/configs/bananapi-cm4-cm4io_defconfig index bb43cc41e5..5fa4b8952a 100644 --- a/configs/bananapi-cm4-cm4io_defconfig +++ b/configs/bananapi-cm4-cm4io_defconfig @@ -17,6 +17,10 @@ CONFIG_SYS_LOAD_ADDR=0x100 CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_REMAKE_ELF=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y diff --git a/configs/bananapi-m2-pro_defconfig b/configs/bananapi-m2-pro_defconfig index 4f8cec9956..6c16953383 100644 --- a/configs/bananapi-m2-pro_defconfig +++ b/configs/bananapi-m2-pro_defconfig @@ -16,6 +16,10 @@ CONFIG_IDENT_STRING="bpi-m2-pro" CONFIG_SYS_LOAD_ADDR=0x100 CONFIG_DEBUG_UART=y CONFIG_REMAKE_ELF=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y diff --git a/configs/bananapi-m2s_defconfig b/configs/bananapi-m2s_defconfig index 3dd8ddcdca..eb3bb17c9a 100644 --- a/configs/bananapi-m2s_defconfig +++ b/configs/bananapi-m2s_defconfig @@ -18,6 +18,10 @@ CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_AHCI=y CONFIG_REMAKE_ELF=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y diff --git a/configs/bananapi-m5_defconfig b/configs/bananapi-m5_defconfig index 696d2fcc5c..0895af81be 100644 --- a/configs/bananapi-m5_defconfig +++ b/configs/bananapi-m5_defconfig @@ -16,6 +16,10 @@ CONFIG_IDENT_STRING="bpi-m5" CONFIG_SYS_LOAD_ADDR=0x100 CONFIG_DEBUG_UART=y CONFIG_REMAKE_ELF=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y diff --git a/configs/beelink-gsking-x_defconfig b/configs/beelink-gsking-x_defconfig index c022097390..8cd0cff6ce 100644 --- a/configs/beelink-gsking-x_defconfig +++ b/configs/beelink-gsking-x_defconfig @@ -17,6 +17,10 @@ CONFIG_IDENT_STRING=" beelink" CONFIG_SYS_LOAD_ADDR=0x100 CONFIG_DEBUG_UART=y CONFIG_REMAKE_ELF=y +CONFIG_FIT=y +CONFIG_FIT_SIGNATURE=y +CONFIG_FIT_VERBOSE=y +CONFIG_LEGACY_IMAGE_FORMAT=y CONFIG_OF_BOARD_SETUP=y # CONFIG_DISPLAY_CPUINFO is not set CONFIG_MISC_INIT_R=y diff --git a/configs/beelink-gt1-ultimate_defconfig b/configs/beelink-gt1-ultimate_defconfig index c0d22c4147..5156dedca8 100644 --- a/configs/beelink-gt1-ultimate_defconfig
[PATCH 2/4] configs: meson64: declare addr out of EXTRA_ENV_SETTINGS
In order to reuse addresses for DFU RAM, define them separately, it's cleaner and will be easier to override. Signed-off-by: Neil Armstrong --- include/configs/meson64.h | 23 --- 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/include/configs/meson64.h b/include/configs/meson64.h index 801cdae470..a64817ec9b 100644 --- a/include/configs/meson64.h +++ b/include/configs/meson64.h @@ -84,6 +84,15 @@ func(DHCP, dhcp, na) #endif +#define BOOTM_SIZE __stringify(0x170) +#define KERNEL_ADDR_R __stringify(0x0808) +#define KERNEL_COMP_ADDR_R __stringify(0x0d08) +#define FDT_ADDR_R __stringify(0x08008000) +#define SCRIPT_ADDR_R __stringify(0x0800) +#define PXEFILE_ADDR_R __stringify(0x0108) +#define FDTOVERLAY_ADDR_R __stringify(0x0100) +#define RAMDISK_ADDR_R __stringify(0x1300) + #include #ifndef CFG_EXTRA_ENV_SETTINGS @@ -91,14 +100,14 @@ "stdin=" STDIN_CFG "\0" \ "stdout=" STDOUT_CFG "\0" \ "stderr=" STDOUT_CFG "\0" \ - "kernel_comp_addr_r=0x0d08\0" \ + "kernel_comp_addr_r=" KERNEL_COMP_ADDR_R "\0" \ "kernel_comp_size=0x200\0" \ - "fdt_addr_r=0x08008000\0" \ - "scriptaddr=0x0800\0" \ - "kernel_addr_r=0x0808\0" \ - "pxefile_addr_r=0x0108\0" \ - "fdtoverlay_addr_r=0x0100\0" \ - "ramdisk_addr_r=0x1300\0" \ + "fdt_addr_r=" FDT_ADDR_R "\0" \ + "scriptaddr=" SCRIPT_ADDR_R "\0" \ + "kernel_addr_r=" KERNEL_ADDR_R "\0" \ + "pxefile_addr_r=" PXEFILE_ADDR_R "\0" \ + "fdtoverlay_addr_r=" FDTOVERLAY_ADDR_R "\0" \ + "ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \ "fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \ BOOTENV #endif -- 2.34.1
[PATCH 3/4] configs: meson64: add alternate USB DFU boot target
Add boot over DFU RAM as an alternate to running script at
a fixed address like done today.
The main culprit is that it's not possible to do that
on G12A/Sm1 platforms due to changes in the USB boot protocol.
With this, U-Boot will present a DFU device with a ram slot where
the Host could write a fitImage or legacy U-Boot image, then with the
detach command boot will continue trying to boot the uploaded image.
Signed-off-by: Neil Armstrong
---
include/configs/meson64.h | 26 ++
1 file changed, 26 insertions(+)
diff --git a/include/configs/meson64.h b/include/configs/meson64.h
index a64817ec9b..efab9a624d 100644
--- a/include/configs/meson64.h
+++ b/include/configs/meson64.h
@@ -53,6 +53,30 @@
#define BOOTENV_DEV_NAME_ROMUSB(devtypeu, devtypel, instance) \
"romusb "
+/*
+ * Fallback to "USB DFU" boot if script is not at scriptaddr
+ *
+ * DFU will expose the kernel_addr_r memory range as DFU entry,
+ * then with `dfu-util --detach`, booting the uploaded image
+ * will be attempted:
+ * $ dfu-util -a 0 -D fitImage
+ * $ dfu-util -a 0 -e
+ */
+#if CONFIG_IS_ENABLED(USB_GADGET) && CONFIG_IS_ENABLED(DFU_RAM)
+ #define BOOTENV_DEV_USB_DFU(devtypeu, devtypel, instance) \
+ "bootcmd_usbdfu=" \
+ "if test \"${boot_source}\" = \"usb\"; then " \
+ "dfu 0 ram 0 60;" \
+ "bootm ${kernel_addr_r};" \
+ "fi\0"
+
+ #define BOOTENV_DEV_NAME_USB_DFU(devtypeu, devtypel, instance) \
+ "usbdfu "
+#else
+ #define BOOTENV_DEV_USB_DFU(devtypeu, devtypel, instance)
+ #define BOOTENV_DEV_NAME_USB_DFU(devtypeu, devtypel, instance)
+#endif
+
#ifdef CONFIG_CMD_USB
#define BOOT_TARGET_DEVICES_USB(func) func(USB, usb, 0)
#else
@@ -74,6 +98,7 @@
#ifndef BOOT_TARGET_DEVICES
#define BOOT_TARGET_DEVICES(func) \
func(ROMUSB, romusb, na) \
+ func(USB_DFU, usbdfu, na) \
func(MMC, mmc, 0) \
func(MMC, mmc, 1) \
func(MMC, mmc, 2) \
@@ -109,6 +134,7 @@
"fdtoverlay_addr_r=" FDTOVERLAY_ADDR_R "\0" \
"ramdisk_addr_r=" RAMDISK_ADDR_R "\0" \
"fdtfile=amlogic/" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+ "dfu_alt_info=fitimage ram " KERNEL_ADDR_R " 0x400 \0" \
BOOTENV
#endif
--
2.34.1
[PATCH 4/4] ARM: meson: enable USB DFU + RAM on Amlogic boards with USB Gadget
Enable DFU as an alternate USB boot method when script wasn't uploaded, this fixes USB full boot on G12/SM1 boards. Signed-off-by: Neil Armstrong --- configs/ad401_defconfig| 2 ++ configs/bananapi-cm4-cm4io_defconfig | 2 ++ configs/bananapi-m2-pro_defconfig | 2 ++ configs/bananapi-m2s_defconfig | 2 ++ configs/bananapi-m5_defconfig | 2 ++ configs/beelink-gsking-x_defconfig | 2 ++ configs/beelink-gt1-ultimate_defconfig | 2 ++ configs/beelink-gtking_defconfig | 2 ++ configs/beelink-gtkingpro_defconfig| 2 ++ configs/jethub_j100_defconfig | 2 ++ configs/jethub_j80_defconfig | 2 ++ configs/khadas-vim2_defconfig | 2 ++ configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ configs/khadas-vim_defconfig | 2 ++ configs/libretech-ac_defconfig | 2 ++ configs/libretech-cc_defconfig | 2 ++ configs/libretech-cc_v2_defconfig | 2 ++ configs/libretech-s905d-pc_defconfig | 2 ++ configs/libretech-s912-pc_defconfig| 2 ++ configs/odroid-c4_defconfig| 2 ++ configs/odroid-go-ultra_defconfig | 2 ++ configs/odroid-hc4_defconfig | 2 ++ configs/odroid-n2_defconfig| 2 ++ configs/odroid-n2l_defconfig | 2 ++ configs/radxa-zero2_defconfig | 2 ++ configs/radxa-zero_defconfig | 2 ++ configs/s400_defconfig | 2 ++ configs/sei510_defconfig | 2 ++ configs/sei610_defconfig | 2 ++ configs/u200_defconfig | 2 ++ configs/wetek-core2_defconfig | 2 ++ 32 files changed, 64 insertions(+) diff --git a/configs/ad401_defconfig b/configs/ad401_defconfig index b9aca3ab0d..c78014ef93 100644 --- a/configs/ad401_defconfig +++ b/configs/ad401_defconfig @@ -21,6 +21,7 @@ CONFIG_BOOTCOMMAND="run storeboot" CONFIG_SYS_PROMPT="ad401 # " # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y CONFIG_CMD_I2C=y # CONFIG_CMD_LOADB is not set @@ -34,6 +35,7 @@ CONFIG_CMD_UBI=y CONFIG_OF_CONTROL=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_DFU_RAM=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MESON=y CONFIG_LED=y diff --git a/configs/bananapi-cm4-cm4io_defconfig b/configs/bananapi-cm4-cm4io_defconfig index 5fa4b8952a..116147fc9a 100644 --- a/configs/bananapi-cm4-cm4io_defconfig +++ b/configs/bananapi-cm4-cm4io_defconfig @@ -27,6 +27,7 @@ CONFIG_MISC_INIT_R=y CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y @@ -41,6 +42,7 @@ CONFIG_ADC=y CONFIG_SARADC_MESON=y CONFIG_BUTTON=y CONFIG_BUTTON_ADC=y +CONFIG_DFU_RAM=y CONFIG_MMC_MESON_GX=y CONFIG_PHY_REALTEK=y CONFIG_DM_MDIO=y diff --git a/configs/bananapi-m2-pro_defconfig b/configs/bananapi-m2-pro_defconfig index 6c16953383..2a3958b0fd 100644 --- a/configs/bananapi-m2-pro_defconfig +++ b/configs/bananapi-m2-pro_defconfig @@ -26,6 +26,7 @@ CONFIG_MISC_INIT_R=y CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y @@ -37,6 +38,7 @@ CONFIG_OF_CONTROL=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_DFU_RAM=y CONFIG_MMC_MESON_GX=y CONFIG_PHY_REALTEK=y CONFIG_DM_MDIO=y diff --git a/configs/bananapi-m2s_defconfig b/configs/bananapi-m2s_defconfig index eb3bb17c9a..405ce3a93a 100644 --- a/configs/bananapi-m2s_defconfig +++ b/configs/bananapi-m2s_defconfig @@ -28,6 +28,7 @@ CONFIG_MISC_INIT_R=y CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y @@ -40,6 +41,7 @@ CONFIG_OF_CONTROL=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_DFU_RAM=y CONFIG_MMC_MESON_GX=y CONFIG_PHY_REALTEK=y CONFIG_DM_MDIO=y diff --git a/configs/bananapi-m5_defconfig b/configs/bananapi-m5_defconfig index 0895af81be..6de5d5fe7b 100644 --- a/configs/bananapi-m5_defconfig +++ b/configs/bananapi-m5_defconfig @@ -26,6 +26,7 @@ CONFIG_MISC_INIT_R=y CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y @@ -37,6 +38,7 @@ CONFIG_OF_CONTROL=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_ADC=y CONFIG_SARADC_MESON=y +CONFIG_DFU_RAM=y CONFIG_MMC_MESON_GX=y CONFIG_PHY_REALTEK=y CONFIG_DM_MDIO=y diff --git a/configs/beelink-gsking-x_defconfig b/configs/beelink-gsking-x_defconfig index 8cd0cff6ce..99e36e970a 100644 --- a/configs/beelink-gsking-x_defconfig +++ b/configs/beelink-gsking-x_defconfig @@ -27,6 +27,7 @@ CONFIG_MISC_INIT_R=y CONFIG_SYS_MAXARGS=32 # CONFIG_CMD_BDI is not set # CONFIG_CMD_IMI is not set +CONFIG_CMD_DFU=y CONFIG_CMD_GPIO=y # CONFIG_CMD_LOADS is not set CONFIG_CMD_MMC=y @
Re: [PATCH 0/4] ARM: meson: Add boot over DFU RAM as an USB boot step
Hi, > Add boot over DFU RAM as an alternate to running script at > a fixed address like done today. > > The main culprit is that it's not possible to do that > on G12A/SM1 platforms due to changes in the USB boot protocol. > > With this, U-Boot will present a DFU device with a ram slot where > the Host could write a fitImage or legacy U-Boot image, then with the > detach command boot will continue trying to boot the uploaded image. > > Signed-off-by: Neil Armstrong Nice to see this! Next step would be to have this in U-Boot SPLin Amlogic SoCs in the future. I'm tempted to implement this in my tree before sending SPL support for (some) Amlogic SoCs upstream. Cheers.
Re: [PATCH] smbios: arm64: Allow table to be written at a fixed addr
On 23/10/2023 08:04, Simon Glass wrote: > Hi Caleb, > > On Sat, 21 Oct 2023 at 01:43, Caleb Connolly > wrote: >> >> Hi Simon, >> >> On 21/10/2023 01:45, Simon Glass wrote: >>> U-Boot typically sets up its malloc() pool near the top of memory. On >>> ARM64 systems this can result in an SMBIOS table above 4GB which is >>> not supported by SMBIOSv2. >>> >>> Work around this problem by providing a new option to choose an address >>> just below 4GB, if needed. >> I may well be missing something here, but I don't quite understand the >> justification behind the original patch [1] which caused this regression. >> >> I'm currently preparing support for a few different Qualcomm boards >> which have different memory layouts, so far it's been possible to avoid >> having any fixed addresses, so the same u-boot image can be used on all >> of them (with just a different DTB). > > What sort of memory layout do you have? I could enhance the patch to > find the top of a memory bank below 4GB, perhaps? E.g. see the > 'bdinfo' command. I think that would probably be sensible (afaict this is more of less what the EFI function did). One of my boards has RAM starting at 0x4000 and ending at 0xC000, frustratingly not quite managing to use the entire 4G address space. There is also a hole in RAM, so u-boot relocates itself to the end of the first memory bank => bdinfo boot_params = 0x DRAM bank = 0x -> start= 0x4000 -> size = 0x3eb0 DRAM bank = 0x0001 -> start= 0x8000 -> size = 0x4000 flashstart = 0x flashsize = 0x flashoffset = 0x baudrate= 115200 bps relocaddr = 0x7ea12000 reloc off = 0x7ea12000 Build = 64-bit fdt_blob= 0x7e5ec5c0 new_fdt = 0x7e5ec5c0 fdt_size= 0x6780 lmb_dump_all: memory.cnt = 0x2 / max = 0x40 memory[0] [0x4000-0x7eaf], 0x3eb0 bytes flags: 0 memory[1] [0x8000-0xbfff], 0x4000 bytes flags: 0 reserved.cnt = 0x8 / max = 0x40 reserved[0][0x4570-0x45cf], 0x0060 bytes flags: 4 reserved[1][0x45e0-0x45f3], 0x0014 bytes flags: 4 reserved[2][0x45fff000-0x461f], 0x00201000 bytes flags: 4 reserved[3][0x4ab0-0x53616fff], 0x08b17000 bytes flags: 4 reserved[4][0x5c00-0x5cff], 0x0100 bytes flags: 4 reserved[5][0x6000-0x638f], 0x0390 bytes flags: 4 reserved[6][0x7d5e8000-0x7eaf], 0x01518000 bytes flags: 0 reserved[7][0x89b01000-0x89d00fff], 0x0020 bytes flags: 4 > >> >> As I mentioned before, efi_allocate_pages() seems to work fine from >> install_smbios_table(), I haven't delved into the code too much but I >> wonder if this could be an acceptable solution? > > Unfortunately that function is EFI-specific. The function can only be > called once EFI is inited. We only want to do that if booting with > EFI. > > The tables are written at the start of U-Boot, partly because that is > how it is done on x86 and partly so the 'acpi' command actually works. > > The EFI code ended up writing a separate set of tables, which is of > course not correct. > > I did look at creating an API in U-Boot to alloc memory below 4GB but > then decided that for just this one use case it might not be worth it. The LMB allocator can already do this with lmb_alloc_base(), would this be an ok solution? I have tested it and it seems to work as intended, allocating the first free 32-bit address, and avoiding reserved regions. It seems like the LMB allocator doesn't have a global pool, so I'm not sure how it avoids conflicts, although maybe that just isn't really an issue in reality. > >> >> Barring that, could we use an environment variable to pass this address >> in? Although I think that might not be a very desirable solution. >> >> I appreciate you taking the time to prepare this patch and CC me. If >> nobody else objects to this patch then I'd prefer to avoid blocking it. >> In either case, I'd greatly appreciate any input on the above >> suggestions so that I can implement a solution for my boards. > > I would like it to be automatic. I assumed on ARM64 that there is > memory available at 3.99GB if U-Boot has relocated to above 4GB, but > as above I could make this more clever. > > Regards, > Simon > > >> >> Thanks and regards, >> >> [1]: >> https://lore.kernel.org/u-boot/20230920030027.1385833-16-...@chromium.org/ >>> >>> Signed-off-by: Simon Glass >>> --- >>> >>> lib/Kconfig | 17 + >>> lib/efi_loader/efi_smbios.c | 12 >>> 2 files changed, 29 insertions(+) >>> >>> diff --git a/lib/Kconfig b/lib/Kconfig >>> index f6ca559897e7..a77f2f3e9089 100644 >>> --- a/lib/Kconfig >>> +++ b/lib/Kconfig >>> @@ -994,6 +994,23 @@ config GENERATE_SMBIOS_TABLE >>> See also SMBIOS_SYSINFO which allows SMBIOS value
Re: [PATCH v3 22/32] efi: Update EFI_LOADER to depend on DM_ETH
On Mon, Oct 23, 2023 at 12:05:28AM -0700, Simon Glass wrote: > Hi Tom, > > On Sun, 22 Oct 2023 at 16:45, Tom Rini wrote: > > > > On Sun, Oct 22, 2023 at 02:55:32PM -0700, Simon Glass wrote: > > > Hi, > > > > > > On Sun, 22 Oct 2023 at 07:59, Tom Rini wrote: > > > > > > > > On Sun, Oct 22, 2023 at 10:29:22AM -0400, Tom Rini wrote: > > > > > On Sun, Oct 22, 2023 at 08:08:11AM +0200, Heinrich Schuchardt wrote: > > > > > > On 10/21/23 20:26, Tom Rini wrote: > > > > > > > On Sat, Oct 21, 2023 at 08:43:08AM -0700, Simon Glass wrote: > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Thu, 19 Oct 2023 at 17:30, AKASHI Takahiro > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Oct 19, 2023 at 08:01:11AM -0600, Simon Glass wrote: > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > > > > > > > On Wed, 18 Oct 2023 at 06:55, Heinrich Schuchardt > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > On 10/17/23 16:09, Tom Rini wrote: > > > > > > > > > > > > On Mon, Oct 16, 2023 at 04:28:13PM -0600, Simon Glass > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > Since efi_device_path.c calls eth_get_dev() and > > > > > > > > > > > > > assumes that Ethernet is > > > > > > > > > > > > > available, add it as an explicit dependency. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > (no changes since v2) > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > > - Add new patch to update EFI_LOADER to depend on > > > > > > > > > > > > > DM_ETH > > > > > > > > > > > > > > > > > > > > > > > > > >lib/efi_loader/Kconfig | 1 + > > > > > > > > > > > > >1 file changed, 1 insertion(+) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig > > > > > > > > > > > > > b/lib/efi_loader/Kconfig > > > > > > > > > > > > > index 13cad6342c36..fca4b3eef270 100644 > > > > > > > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > > > > > > > @@ -11,6 +11,7 @@ config EFI_LOADER > > > > > > > > > > > > > # We need EFI_STUB_32BIT to be set on x86_32 > > > > > > > > > > > > > with EFI_STUB > > > > > > > > > > > > > depends on !EFI_STUB || !X86 || X86_64 || > > > > > > > > > > > > > EFI_STUB_32BIT > > > > > > > > > > > > > depends on BLK > > > > > > > > > > > > > +depends on DM_ETH > > > > > > > > > > > > > depends on !EFI_APP > > > > > > > > > > > > > default y if !ARM || SYS_CPU = armv7 || SYS_CPU > > > > > > > > > > > > > = armv8 > > > > > > > > > > > > > select CHARSET > > > > > > > > > > > > > > > > > > > > > > > > Does this work for you Heinrich, or do you want to > > > > > > > > > > > > clarify the > > > > > > > > > > > > dependencies (and re-organize the code as needed) > > > > > > > > > > > > around networking? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We should be able to boot via EFI on devices without > > > > > > > > > > > U-Boot network support. > > > > > > > > > > > > > > > > > > > > > > We already use IS_ENABLED(CONFIG_NETDEVICES) to avoid > > > > > > > > > > > invoking > > > > > > > > > > > eth_get_dev() if there is no network. CONFIG_NETDEVICES=y > > > > > > > > > > > selects > > > > > > > > > > > CONFIG_DM_ETH. > > > > > > > > > > > > > > > > > > > > > > Why is this not sufficient? > > > > > > > > > > > Is there a configuration that does not build? > > > > > > > > > > > > > > > > > > > > The point of this series is to disable CMDLINE and fix up > > > > > > > > > > what breaks. > > > > > > > > > > > > > > > > > > > > In this case we have some sort of breakage...perhaps Tom > > > > > > > > > > has already > > > > > > > > > > found it, but otherwise could you take a look? > > > > > > > > > > > > > > > > > > > > We should be able to disable NET and LTO in sandbox and > > > > > > > > > > still build. > > > > > > > > > > But this fails at present[1]. You can try it on -master > > > > > > > > > > > > > > > > > > Obviously, it would be necessary to enclose efi_dp_from_eth() > > > > > > > > > with "if defined(CONFIG_NETDEVICES)" (or DM_ETH). > > > > > > > > > Then, we could drop "depends on DM_ETH". > > > > > > > > > > > > > > > > Strange that it only happens on the non-LTO board, though? > > > > > > > > > > > > > > There's two issues. The first of which is that I think you need to > > > > > > > re-check your error exactly? With my series, and LTO also > > > > > > > disabled the > > > > > > > problem is a call to efi_get_image_parameters() as that's defined > > > > > > > in > > > > > > > cmd/bootefi.c, but also only used with cmdline invocations. So we > > > > > > > can > > > > > > > fix that CMDLINE=n && LTO=n case with a IS_ENABLED(CONFIG_CMDLINE) > > > > > > > around that, and then discard efi_dp_from_name() entirely. > > > > > > > > >
[PATCH v3 00/24] sunxi: Allwinner T113s support
Hi, this is just for the records (mailing list archives), I just sent a pull request with that series, to still make the 2024.01 merge window. Some smaller changes, addressing the review comments (many thanks to Samuel!) This now embeds Sam's PSCI support patches, and also relies on the devicetree sync from the Linux v6.6-rc6 kernel. If you find issues with this series, then please reply to the respective patch, or send a patch on top. We still have till the end of the year to fix things in the repo. Changelog below. === This series adds support for the new SoC series that covers the Allwinner D1 siblings R528 and T113s (a version with co-packaged DRAM). They all share the same die, although the D1 and D1s use RISC-V cores, which requires more plumbing, to use the sunxi code across two architectures. Getting the R528 support in should help a bit in sorting out what's new peripheral code and what is architecture dependent. IIUC, Samuel has that running, although with some hacks, the number of which this series tries to reduce. The most interesting part of this is the pincontroller rework, this tackles two issues: - For the first time in the history of mainline Allwinner support the pincontroller changed the register layout. The code here tries to abstract the differences away, so both variants can share the code peacefully. - For the above mentioned reason, the pincontroller code is quite old, and is mostly spread out across arch/arm, in a pre-DM style, even though we have real DM support in U-Boot proper. We need the non-DM version for the (ARM-only?) legacy SPL, so can't get rid of that completely. This series also tries to modernise that code, and moves it into drivers/gpio, where it can be more easily shared with RISC-V. The main feature is then of course the T113s support, of which the new pinctroller is only one part. Apart from the new pincontroller and the usual new SoC bits (like clock and pinmux support), this includes the DRAM controller code. The PSCI support has been contributed by Sam (many thanks for that!). To follow the common pattern there is first some refactoring, then the R528/T113s bits plug on top. With the basics in, we add support for the MangoPi MQ-R board, which uses the T113s and seems to be a popular board. This should also serve as a blueprint for supporting similar boards. This series is based on top of current master, but it relies on the Allwinner DT update series (from Linux kernel v6.6-rc6). A branch is available at: https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master Cheers, Andre Changelog v3 .. v2: - add review and test tags - mention OrangePi Plus USB3_VBUS_PIN speciality in commit message - use dev_get_phy_node() wrapper in sunxi_emac.c - change [gs]et_output_ to [gs]et_value_ in pinctrl code - move SUNXI_NEW_PINCTRL Kconfig definition to drivers/gpio - fix ordering of pinctrl structure definitions - add some new pinmux functions (i2c0, mmc1, uart1/2) - fix ordering of clock structure definitions - drop DRAM_SUN8I_R528 symbol in favour of just DRAM_SUN20I_D1 - drop defaults from DRAM parameters (forces definition in defconfig) - fix test writes/reads into DRAM for 64-bit builds - fix DRAM driver build failure for DM_RAM - un-indent dram_para_t definition - drop devicetree patches and rely on generic DT update - include PSCI patches from Sam Edwards - make sure SUNXI_R_CPUCFG_BASE is always defined Changelog v2 .. v1: - add review and test tags - reorder pinctrl rework patches: first move shared code, then add in/out, then remove struct, then move headers - move all GPIO routines into drivers/gpio/sunxi_gpio.c - move private GPIO definitions from GPIO header file to sunxi_gpio.c - use GPIO_NUM() instead of "% 32" directly - define more MMIO addresses (PRCM, CPUCFG, R_PIO) - do not enable 8-bit eMMC mode (Okhunjon) - add eMMC pins to SPL pinmux setup (Okhunjon) - drop patch [PATCH 13/20] sunxi: clock: h6: prepare for PRCM less SoCs - update DT files from latest Linux kernel tree - fix pin numbers for the UART pinmux setup - let DRAM driver depend on ARCH_SUNXI Andre Przywara (18): sunxi: remove CONFIG_SATAPWR net: sunxi_emac: chase DT nodes to find PHY regulator sunxi: remove CONFIG_MACPWR pinctrl: sunxi: move pinctrl code pinctrl: sunxi: add GPIO in/out wrappers pinctrl: sunxi: remove struct sunxi_gpio pinctrl: sunxi: remove GPIO_EXTRA_HEADER pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h pinctrl: sunxi: add new D1 pinctrl support sunxi: introduce NCAT2 generation model pinctrl: sunxi: add Allwinner D1 pinctrl description sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup sunxi: clock: support D1/R528 PLL6 clock Kconfig: sunxi: prepare for using drivers/ram/sunxi sunxi: add R528/T113-s3/D1(s) DRAM initialisation code sunxi: add Allwinner R528/T113 SoC support sunxi: refactor serial base addresses to avoid asm/arch/cpu.h sunxi: add MangoPi MQ-R board support Okhunjon Sob
[PATCH v3 01/24] sunxi: remove CONFIG_SATAPWR
The CONFIG_SATAPWR Kconfig symbol was used to point to a GPIO that
enables the power for a SATA harddisk.
In the DT this is described with the target-supply property in the AHCI
DT node, pointing to a (GPIO controlled) regulator. Since we need SATA
only in U-Boot proper, and use a DM driver for AHCI there, we should use
the DT instead of hardcoding this.
Add code to the sunxi AHCI driver to check the DT for that regulator and
enable it, at probe time. Then drop the current code from board.c, which
was doing that job before.
This allows us to remove the SATAPWR Kconfig definition and the
respective values from the defconfigs.
We also select the generic fixed regulator driver, which handles those
GPIO controlled regulators.
Please note that the OrangePi Plus is a bit special here, it's a H3
board without native SATA, but with a USB-to-SATA bridge. The DT models
the SATA power via a VBUS supply regulator, which we don't parse yet in
the USB PHY driver. Use the hardcoded CONFIG_USB3_VBUS_PIN for that
board meanwhile.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
Reviewed-by: Samuel Holland
---
arch/arm/Kconfig | 2 ++
arch/arm/mach-sunxi/Kconfig | 8
board/sunxi/board.c | 16 +---
configs/A10-OLinuXino-Lime_defconfig | 1 -
configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 -
configs/A20-OLinuXino-Lime2_defconfig| 1 -
configs/A20-OLinuXino-Lime_defconfig | 1 -
configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 -
configs/A20-OLinuXino_MICRO_defconfig| 1 -
configs/A20-Olimex-SOM-EVB_defconfig | 1 -
configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 -
configs/A20-Olimex-SOM204-EVB_defconfig | 1 -
configs/Cubieboard2_defconfig| 1 -
configs/Cubieboard_defconfig | 1 -
configs/Cubietruck_defconfig | 1 -
configs/Itead_Ibox_A20_defconfig | 1 -
configs/Lamobo_R1_defconfig | 1 -
configs/Linksprite_pcDuino3_Nano_defconfig | 1 -
configs/Linksprite_pcDuino3_defconfig| 1 -
configs/Sinovoip_BPI_M3_defconfig| 1 -
configs/orangepi_plus_defconfig | 2 +-
drivers/ata/ahci_sunxi.c | 9 +
22 files changed, 13 insertions(+), 41 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 531b081de99..dcccbfea42a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1159,6 +1159,8 @@ config ARCH_SUNXI
imply CMD_GPT
imply CMD_UBI if MTD_RAW_NAND
imply DISTRO_DEFAULTS
+ imply DM_REGULATOR
+ imply DM_REGULATOR_FIXED
imply FAT_WRITE
imply FIT
imply OF_LIBFDT_OVERLAY
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 9d5df2c1027..1b24dfe4dd1 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -1008,14 +1008,6 @@ config VIDEO_LCD_TL059WV5C0
endchoice
-config SATAPWR
- string "SATA power pin"
- default ""
- help
- Set the pins used to power the SATA. This takes a string in the
- format understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of
- port H.
-
config GMAC_TX_DELAY
int "GMAC Transmit Clock Delay Chain"
default 0
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index ebaa9431984..50a60e760d4 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -187,7 +187,7 @@ enum env_location env_get_location(enum env_operation op,
int prio)
/* add board specific code here */
int board_init(void)
{
- __maybe_unused int id_pfr1, ret, satapwr_pin, macpwr_pin;
+ __maybe_unused int id_pfr1, ret, macpwr_pin;
gd->bd->bi_boot_params = (PHYS_SDRAM_0 + 0x100);
@@ -225,20 +225,6 @@ int board_init(void)
return ret;
/* strcmp() would look better, but doesn't get optimised away. */
- if (CONFIG_SATAPWR[0]) {
- satapwr_pin = sunxi_name_to_gpio(CONFIG_SATAPWR);
- if (satapwr_pin >= 0) {
- gpio_request(satapwr_pin, "satapwr");
- gpio_direction_output(satapwr_pin, 1);
-
- /*
-* Give the attached SATA device time to power-up
-* to avoid link timeouts
-*/
- mdelay(500);
- }
- }
-
if (CONFIG_MACPWR[0]) {
macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
if (macpwr_pin >= 0) {
diff --git a/configs/A10-OLinuXino-Lime_defconfig
b/configs/A10-OLinuXino-Lime_defconfig
index df4fdfaba41..57e91d0f017 100644
--- a/configs/A10-OLinuXino-Lime_defconfig
+++ b/configs/A10-OLinuXino-Lime_defconfig
@@ -7,7 +7,6 @@ CONFIG_DRAM_CLK=480
CONFIG_DRAM_EMR1=4
CONFIG_SYS_CLK_FREQ=91200
CONFIG_I2C1_ENABLE=y
-CONFIG_SATAPWR="PC3"
CONFIG_AHCI=y
# CONFIG_SYS_MALLOC_CLE
[PATCH v3 02/24] net: sunxi_emac: chase DT nodes to find PHY regulator
At the moment the sun4i EMAC driver relies on hardcoded CONFIG_MACPWR
Kconfig symbols to enable potential PHY regulators. As we want to get rid
of those, we need to find the regulator by chasing up the DT.
The sun4i-emac binding puts the PHY regulator into the MDIO node, which
is the parent of the PHY device. U-Boot does not have (and does not
need) an MDIO driver, so we need to chase down the regulator through the
EMAC node: we follow the "phy-handle" property to find the PHY node,
then go up to its parent, where we find the "phy-supply" link to the
regulator. Let U-Boot find the associated regulator device, and put that
into the private device struct, so we can find and enable the regulator
at probe time, later.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
Reviewed-by: Samuel Holland
---
drivers/net/sunxi_emac.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/drivers/net/sunxi_emac.c b/drivers/net/sunxi_emac.c
index 4c90d4b4981..b599b84852f 100644
--- a/drivers/net/sunxi_emac.c
+++ b/drivers/net/sunxi_emac.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
/* EMAC register */
struct emac_regs {
@@ -165,6 +166,7 @@ struct emac_eth_dev {
struct phy_device *phydev;
int link_printed;
uchar rx_buf[EMAC_RX_BUFSIZE];
+ struct udevice *phy_reg;
};
struct emac_rxhdr {
@@ -572,6 +574,9 @@ static int sunxi_emac_eth_probe(struct udevice *dev)
if (ret)
return ret;
+ if (priv->phy_reg)
+ regulator_set_enable(priv->phy_reg, true);
+
return sunxi_emac_init_phy(priv, dev);
}
@@ -585,9 +590,42 @@ static const struct eth_ops sunxi_emac_eth_ops = {
static int sunxi_emac_eth_of_to_plat(struct udevice *dev)
{
struct eth_pdata *pdata = dev_get_plat(dev);
+ struct emac_eth_dev *priv = dev_get_priv(dev);
+ struct ofnode_phandle_args args;
+ ofnode phy_node, mdio_node;
+ int ret;
pdata->iobase = dev_read_addr(dev);
+ phy_node = dev_get_phy_node(dev);
+ if (phy_node == ofnode_null()) {
+ dev_err(dev, "failed to get PHY node\n");
+ return ret;
+ }
+ /*
+* The PHY regulator is in the MDIO node, not the EMAC or PHY node.
+* U-Boot does not have (and does not need) a device driver for the
+* MDIO device, so just "pass through" that DT node to get to the
+* regulator phandle.
+* The PHY regulator is optional, though: ignore if we cannot find
+* a phy-supply property.
+*/
+ mdio_node = ofnode_get_parent(phy_node);
+ ret= ofnode_parse_phandle_with_args(mdio_node, "phy-supply", NULL, 0, 0,
+ &args);
+ if (ret && ret != -ENOENT) {
+ dev_err(dev, "failed to get PHY supply node\n");
+ return ret;
+ }
+ if (!ret) {
+ ret = uclass_get_device_by_ofnode(UCLASS_REGULATOR, args.node,
+ &priv->phy_reg);
+ if (ret) {
+ dev_err(dev, "failed to get PHY regulator node\n");
+ return ret;
+ }
+ }
+
return 0;
}
--
2.25.1
[PATCH v3 03/24] sunxi: remove CONFIG_MACPWR
The CONFIG_MACPWR Kconfig symbol is used to point to a GPIO that enables
the power for the Ethernet "MAC" (mostly PHY, really).
In the DT this is described with the phy-supply property in the MAC DT
node, pointing to a (GPIO controlled) regulator. Since we need Ethernet
only in U-Boot proper, and use a DM driver there, we should use the DT
instead of hardcoding this.
Add code to the sun8i_emac and sunxi_emac drivers to check the DT for
that regulator and enable it, at probe time. Then drop the current code
from board.c, which was doing that job before.
This allows us to remove the MACPWR Kconfig definition and the respective
values from the defconfigs.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
---
arch/arm/mach-sunxi/Kconfig | 7 ---
board/sunxi/board.c | 12 +---
configs/Bananapi_M2_Ultra_defconfig | 1 -
configs/Bananapi_defconfig| 1 -
configs/Bananapro_defconfig | 1 -
configs/Lamobo_R1_defconfig | 1 -
configs/Mele_A1000_defconfig | 1 -
configs/Orangepi_defconfig| 1 -
configs/Orangepi_mini_defconfig | 1 -
configs/bananapi_m1_plus_defconfig| 1 -
configs/bananapi_m2_plus_h3_defconfig | 1 -
configs/bananapi_m2_plus_h5_defconfig | 1 -
configs/i12-tvbox_defconfig | 1 -
configs/jesurun_q5_defconfig | 1 -
configs/mixtile_loftq_defconfig | 1 -
configs/nanopi_m1_plus_defconfig | 1 -
configs/nanopi_neo_plus2_defconfig| 1 -
configs/nanopi_r1s_h5_defconfig | 1 -
configs/orangepi_pc2_defconfig| 1 -
configs/orangepi_plus2e_defconfig | 1 -
configs/orangepi_plus_defconfig | 1 -
configs/orangepi_win_defconfig| 1 -
configs/pine_h64_defconfig| 1 -
configs/zeropi_defconfig | 1 -
drivers/net/sun8i_emac.c | 7 +++
drivers/net/sunxi_emac.c | 4 ++--
26 files changed, 10 insertions(+), 42 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 1b24dfe4dd1..d3ed62add99 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -695,13 +695,6 @@ config OLD_SUNXI_KERNEL_COMPAT
Set this to enable various workarounds for old kernels, this results in
sub-optimal settings for newer kernels, only enable if needed.
-config MACPWR
- string "MAC power pin"
- default ""
- help
- Set the pin used to power the MAC. This takes a string in the format
- understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of port H.
-
config MMC1_PINS_PH
bool "Pins for mmc1 are on Port H"
depends on MACH_SUN4I || MACH_SUN7I || MACH_SUN8I_R40
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 50a60e760d4..5cfb33468e5 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -187,7 +187,7 @@ enum env_location env_get_location(enum env_operation op,
int prio)
/* add board specific code here */
int board_init(void)
{
- __maybe_unused int id_pfr1, ret, macpwr_pin;
+ __maybe_unused int id_pfr1, ret;
gd->bd->bi_boot_params = (PHYS_SDRAM_0 + 0x100);
@@ -224,15 +224,6 @@ int board_init(void)
if (ret)
return ret;
- /* strcmp() would look better, but doesn't get optimised away. */
- if (CONFIG_MACPWR[0]) {
- macpwr_pin = sunxi_name_to_gpio(CONFIG_MACPWR);
- if (macpwr_pin >= 0) {
- gpio_request(macpwr_pin, "macpwr");
- gpio_direction_output(macpwr_pin, 1);
- }
- }
-
#if CONFIG_IS_ENABLED(DM_I2C)
/*
* Temporary workaround for enabling I2C clocks until proper sunxi DM
@@ -240,7 +231,6 @@ int board_init(void)
*/
i2c_init_board();
#endif
-
eth_init_board();
return 0;
diff --git a/configs/Bananapi_M2_Ultra_defconfig
b/configs/Bananapi_M2_Ultra_defconfig
index a5fe76af568..2cc7bbbd8b7 100644
--- a/configs/Bananapi_M2_Ultra_defconfig
+++ b/configs/Bananapi_M2_Ultra_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun8i-r40-bananapi-m2-ultra"
CONFIG_SPL=y
CONFIG_MACH_SUN8I_R40=y
CONFIG_DRAM_CLK=576
-CONFIG_MACPWR="PA17"
CONFIG_MMC_SUNXI_SLOT_EXTRA=2
CONFIG_USB1_VBUS_PIN="PH23"
CONFIG_USB2_VBUS_PIN="PH23"
diff --git a/configs/Bananapi_defconfig b/configs/Bananapi_defconfig
index 6c2a1f630e8..f4910ba13ac 100644
--- a/configs/Bananapi_defconfig
+++ b/configs/Bananapi_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapi"
CONFIG_SPL=y
CONFIG_MACH_SUN7I=y
CONFIG_DRAM_CLK=432
-CONFIG_MACPWR="PH23"
CONFIG_VIDEO_COMPOSITE=y
CONFIG_GMAC_TX_DELAY=3
CONFIG_AHCI=y
diff --git a/configs/Bananapro_defconfig b/configs/Bananapro_defconfig
index 94fd74754ea..02be8971df9 100644
--- a/configs/Bananapro_defconfig
+++ b/configs/Bananapro_defconfig
@@ -4,7 +4,6 @@ CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-bananapro"
CONFIG_SPL=y
CONFIG_MACH_
[PATCH v3 04/24] pinctrl: sunxi: move pinctrl code
Move the existing sunxi-specific low level pinctrl routines from
arch/arm/mach-sunxi into the existing GPIO code under drivers/gpio, so
that the common code can be shared outside of arch/arm.
This also takes the opportunity to move some definitions from our
header file into the driver C file, as they are private to the driver
and are not needed elsewhere.
Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
Tested-by: Samuel Holland
---
arch/arm/include/asm/arch-sunxi/gpio.h | 20 +
arch/arm/mach-sunxi/Makefile | 1 -
arch/arm/mach-sunxi/pinmux.c | 78 ---
drivers/gpio/sunxi_gpio.c | 102 -
4 files changed, 105 insertions(+), 96 deletions(-)
delete mode 100644 arch/arm/mach-sunxi/pinmux.c
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 6eaeece4e24..4bc9e8ffcc9 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -3,6 +3,9 @@
* (C) Copyright 2007-2012
* Allwinner Technology Co., Ltd.
* Tom Cubie
+ *
+ * Definitions that are shared between the Allwinner pinctrl and GPIO drivers,
+ * also used by some non-DM SPL code directly.
*/
#ifndef _SUNXI_GPIO_H
@@ -76,22 +79,6 @@ struct sunxi_gpio_reg {
#define SUN50I_H6_GPIO_POW_MOD_SEL 0x340
#define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
-#define BANK_TO_GPIO(bank) (((bank) < SUNXI_GPIO_L) ? \
- &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
- &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) -
SUNXI_GPIO_L])
-
-#define GPIO_BANK(pin) ((pin) >> 5)
-#define GPIO_NUM(pin) ((pin) & 0x1f)
-
-#define GPIO_CFG_INDEX(pin)(((pin) & 0x1f) >> 3)
-#define GPIO_CFG_OFFSET(pin) pin) & 0x1f) & 0x7) << 2)
-
-#define GPIO_DRV_INDEX(pin)(((pin) & 0x1f) >> 4)
-#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
-
-#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
-#define GPIO_PULL_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
-
/* GPIO bank sizes */
#define SUNXI_GPIOS_PER_BANK 32
@@ -217,6 +204,7 @@ struct sunxi_gpio_plat {
charbank_name[3];
};
+/* prototypes for the non-DM GPIO/pinctrl functions, used in the SPL */
void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val);
void sunxi_gpio_set_cfgpin(u32 pin, u32 val);
int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset);
diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
index 58f807cb82d..671211e9322 100644
--- a/arch/arm/mach-sunxi/Makefile
+++ b/arch/arm/mach-sunxi/Makefile
@@ -10,7 +10,6 @@ obj-y += board.o
obj-y += clock.o
obj-y += cpu_info.o
obj-y += dram_helpers.o
-obj-y += pinmux.o
obj-$(CONFIG_SUN6I_PRCM) += prcm.o
obj-$(CONFIG_AXP_PMIC_BUS) += pmic_bus.o
obj-$(CONFIG_MACH_SUNIV) += clock_sun6i.o
diff --git a/arch/arm/mach-sunxi/pinmux.c b/arch/arm/mach-sunxi/pinmux.c
deleted file mode 100644
index c95fcee9f6c..000
--- a/arch/arm/mach-sunxi/pinmux.c
+++ /dev/null
@@ -1,78 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * (C) Copyright 2007-2011
- * Allwinner Technology Co., Ltd.
- * Tom Cubie
- */
-
-#include
-#include
-#include
-
-void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val)
-{
- u32 index = GPIO_CFG_INDEX(bank_offset);
- u32 offset = GPIO_CFG_OFFSET(bank_offset);
-
- clrsetbits_le32(&pio->cfg[index], 0xf << offset, val << offset);
-}
-
-void sunxi_gpio_set_cfgpin(u32 pin, u32 val)
-{
- u32 bank = GPIO_BANK(pin);
- struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
-
- sunxi_gpio_set_cfgbank(pio, pin, val);
-}
-
-int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset)
-{
- u32 index = GPIO_CFG_INDEX(bank_offset);
- u32 offset = GPIO_CFG_OFFSET(bank_offset);
- u32 cfg;
-
- cfg = readl(&pio->cfg[index]);
- cfg >>= offset;
-
- return cfg & 0xf;
-}
-
-int sunxi_gpio_get_cfgpin(u32 pin)
-{
- u32 bank = GPIO_BANK(pin);
- struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
-
- return sunxi_gpio_get_cfgbank(pio, pin);
-}
-
-void sunxi_gpio_set_drv(u32 pin, u32 val)
-{
- u32 bank = GPIO_BANK(pin);
- struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
-
- sunxi_gpio_set_drv_bank(pio, pin, val);
-}
-
-void sunxi_gpio_set_drv_bank(struct sunxi_gpio *pio, u32 bank_offset, u32 val)
-{
- u32 index = GPIO_DRV_INDEX(bank_offset);
- u32 offset = GPIO_DRV_OFFSET(bank_offset);
-
- clrsetbits_le32(&pio->drv[index], 0x3 << offset, val << offset);
-}
-
-void sunxi_gpio_set_pull(u32 pin, u32 val)
-{
- u32 bank = GPIO_BANK(pin);
- struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
-
- sunxi_gpio_set_pull_bank(pio, pin, val);
-}
-
-void sunxi_gpio_set_pull_bank(struct sunxi_gpio *pio, int bank_offset, u32 val)
-{
- u32 index = GPIO_PULL_INDEX(bank_off
[PATCH v3 06/24] pinctrl: sunxi: remove struct sunxi_gpio
So far every Allwinner SoC used the same basic pincontroller/GPIO
register frame, and just differed by the number of implemented banks and
pins, plus some special functionality from time to time. However the D1
and successors use a slightly different pinctrl register layout.
Use that opportunity to drop "struct sunxi_gpio", that described that
MMIO frame in a C struct. That approach is somewhat frowned upon in the
Linux world and rarely used there, though still popular with U-Boot.
Switching from a C struct to a "base address plus offset" approach allows
to switch between the two models more dynamically, without reverting to
preprocessor macros and #ifdef's.
Model the pinctrl MMIO register frame in the usual "base address +
offset" way, and replace a hard-to-parse CPP macro with a more readable
static function.
All the users get converted over. There are no functional changes at
this point, it just prepares the stages for the D1 and friends.
Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
Tested-by: Samuel Holland
---
arch/arm/include/asm/arch-sunxi/gpio.h | 40 ++--
drivers/gpio/sunxi_gpio.c | 88 --
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 14 ++--
3 files changed, 66 insertions(+), 76 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 4bc9e8ffcc9..e0fb5b5da63 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -31,13 +31,6 @@
#define SUNXI_GPIO_H 7
#define SUNXI_GPIO_I 8
-/*
- * This defines the number of GPIO banks for the _main_ GPIO controller.
- * You should fix up the padding in struct sunxi_gpio_reg below if you
- * change this.
- */
-#define SUNXI_GPIO_BANKS 9
-
/*
* sun6i/sun8i and later SoCs have an additional GPIO controller (R_PIO)
* at a different register offset.
@@ -55,32 +48,11 @@
#define SUNXI_GPIO_M 12
#define SUNXI_GPIO_N 13
-struct sunxi_gpio {
- u32 cfg[4];
- u32 dat;
- u32 drv[2];
- u32 pull[2];
-};
-
-/* gpio interrupt control */
-struct sunxi_gpio_int {
- u32 cfg[3];
- u32 ctl;
- u32 sta;
- u32 deb;/* interrupt debounce */
-};
-
-struct sunxi_gpio_reg {
- struct sunxi_gpio gpio_bank[SUNXI_GPIO_BANKS];
- u8 res[0xbc];
- struct sunxi_gpio_int gpio_int;
-};
-
#define SUN50I_H6_GPIO_POW_MOD_SEL 0x340
#define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
-/* GPIO bank sizes */
#define SUNXI_GPIOS_PER_BANK 32
+#define SUNXI_PINCTRL_BANK_SIZE 0x24
#define SUNXI_GPIO_NEXT(__gpio) \
((__gpio##_START) + SUNXI_GPIOS_PER_BANK)
@@ -200,19 +172,19 @@ enum sunxi_gpio_number {
#define SUNXI_GPIO_AXP0_GPIO_COUNT 6
struct sunxi_gpio_plat {
- struct sunxi_gpio *regs;
+ void*regs;
charbank_name[3];
};
/* prototypes for the non-DM GPIO/pinctrl functions, used in the SPL */
-void sunxi_gpio_set_cfgbank(struct sunxi_gpio *pio, int bank_offset, u32 val);
+void sunxi_gpio_set_cfgbank(void *bank_base, int pin_offset, u32 val);
void sunxi_gpio_set_cfgpin(u32 pin, u32 val);
-int sunxi_gpio_get_cfgbank(struct sunxi_gpio *pio, int bank_offset);
+int sunxi_gpio_get_cfgbank(void *bank_base, int pin_offset);
int sunxi_gpio_get_cfgpin(u32 pin);
void sunxi_gpio_set_drv(u32 pin, u32 val);
-void sunxi_gpio_set_drv_bank(struct sunxi_gpio *pio, u32 bank_offset, u32 val);
+void sunxi_gpio_set_drv_bank(void *bank_base, u32 pin_offset, u32 val);
void sunxi_gpio_set_pull(u32 pin, u32 val);
-void sunxi_gpio_set_pull_bank(struct sunxi_gpio *pio, int bank_offset, u32
val);
+void sunxi_gpio_set_pull_bank(void *bank_base, int pin_offset, u32 val);
int sunxi_name_to_gpio(const char *name);
#if !defined CONFIG_SPL_BUILD && defined CONFIG_AXP_GPIO
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 3ca833316b5..d7f6a266e53 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -29,45 +29,61 @@
* ===
*/
-#define BANK_TO_GPIO(bank) (((bank) < SUNXI_GPIO_L) ? \
- &((struct sunxi_gpio_reg *)SUNXI_PIO_BASE)->gpio_bank[bank] : \
- &((struct sunxi_gpio_reg *)SUNXI_R_PIO_BASE)->gpio_bank[(bank) -
SUNXI_GPIO_L])
-
#define GPIO_BANK(pin) ((pin) >> 5)
#define GPIO_NUM(pin) ((pin) & 0x1f)
+#define GPIO_CFG_REG_OFFSET0x00
#define GPIO_CFG_INDEX(pin)(((pin) & 0x1f) >> 3)
#define GPIO_CFG_OFFSET(pin) pin) & 0x1f) & 0x7) << 2)
+#define GPIO_DAT_REG_OFFSET0x10
+
+#define GPIO_DRV_REG_OFFSET0x14
#define GPIO_DRV_INDEX(pin)(((pin) & 0x1f) >> 4)
#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
+#define GPIO_PULL_REG_OFFSET 0x1c
#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
#define GPIO_PULL_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
-void sunxi_gpio_set_cfgbank(struct sunxi_
[PATCH v3 07/24] pinctrl: sunxi: remove GPIO_EXTRA_HEADER
U-Boot's generic GPIO_EXTRA_HEADER is a convenience symbol to allow code to more easily include platform specific GPIO headers. This should not be needed in a DM world anymore, since the generic GPIO framework handles that nicely. For Allwinner boards we still need to deal with non-DM GPIO in the SPL, but this should become the exception, not the rule. Make this more obvious by removing the definition of GPIO_EXTRA_HEADER, and just force every legacy user of platform specific GPIO to include the new sunxi_gpio.h header explicitly. Everyone doing so should feel ashamed and should find a way to avoid it from now on. Signed-off-by: Andre Przywara Tested-by: Samuel Holland --- arch/arm/Kconfig | 1 - arch/arm/mach-sunxi/board.c| 1 + arch/arm/mach-sunxi/dram_suniv.c | 2 +- arch/arm/mach-sunxi/spl_spi_sunxi.c| 1 + board/sunxi/board.c| 1 + board/sunxi/chip.c | 2 +- drivers/gpio/axp_gpio.c| 1 + drivers/gpio/sunxi_gpio.c | 1 + drivers/i2c/sun6i_p2wi.c | 2 +- drivers/i2c/sun8i_rsb.c| 2 +- drivers/mmc/sunxi_mmc.c| 1 + drivers/pinctrl/sunxi/pinctrl-sunxi.c | 1 + drivers/video/hitachi_tx18d42vm_lcd.c | 1 + drivers/video/ssd2828.c| 1 - drivers/video/sunxi/sunxi_display.c| 1 + drivers/video/sunxi/sunxi_lcd.c| 1 + arch/arm/include/asm/arch-sunxi/gpio.h => include/sunxi_gpio.h | 0 17 files changed, 14 insertions(+), 6 deletions(-) rename arch/arm/include/asm/arch-sunxi/gpio.h => include/sunxi_gpio.h (100%) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index dcccbfea42a..d812685c984 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1135,7 +1135,6 @@ config ARCH_SUNXI select DM_MMC if MMC select DM_SCSI if SCSI select DM_SERIAL - select GPIO_EXTRA_HEADER select OF_BOARD_SETUP select OF_CONTROL select OF_SEPARATE diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c index 78597ad932c..4a1a0eacdba 100644 --- a/arch/arm/mach-sunxi/board.c +++ b/arch/arm/mach-sunxi/board.c @@ -17,6 +17,7 @@ #include #include #include +#include #include #include #include diff --git a/arch/arm/mach-sunxi/dram_suniv.c b/arch/arm/mach-sunxi/dram_suniv.c index 3aa3ce76272..9e583e18553 100644 --- a/arch/arm/mach-sunxi/dram_suniv.c +++ b/arch/arm/mach-sunxi/dram_suniv.c @@ -13,10 +13,10 @@ #include #include #include -#include #include #include #include +#include #define SDR_T_CAS (0x2) #define SDR_T_RAS (0x8) diff --git a/arch/arm/mach-sunxi/spl_spi_sunxi.c b/arch/arm/mach-sunxi/spl_spi_sunxi.c index 81159cfee61..c2410dd7bb1 100644 --- a/arch/arm/mach-sunxi/spl_spi_sunxi.c +++ b/arch/arm/mach-sunxi/spl_spi_sunxi.c @@ -13,6 +13,7 @@ #include #include #include +#include #ifdef CONFIG_SPL_OS_BOOT #error CONFIG_SPL_OS_BOOT is not supported yet diff --git a/board/sunxi/board.c b/board/sunxi/board.c index 5cfb33468e5..7a1c708b9f2 100644 --- a/board/sunxi/board.c +++ b/board/sunxi/board.c @@ -38,6 +38,7 @@ #include #endif #include +#include #include #include #include diff --git a/board/sunxi/chip.c b/board/sunxi/chip.c index cde04bebe96..6319e79 100644 --- a/board/sunxi/chip.c +++ b/board/sunxi/chip.c @@ -12,7 +12,7 @@ #include #include -#include +#include #include diff --git a/drivers/gpio/axp_gpio.c b/drivers/gpio/axp_gpio.c index 49672193ffc..af6631697f5 100644 --- a/drivers/gpio/axp_gpio.c +++ b/drivers/gpio/axp_gpio.c @@ -14,6 +14,7 @@ #include #include #include +#include static int axp_gpio_set_value(struct udevice *dev, unsigned pin, int val); diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c index d7f6a266e53..e335496581f 100644 --- a/drivers/gpio/sunxi_gpio.c +++ b/drivers/gpio/sunxi_gpio.c @@ -17,6 +17,7 @@ #include #include #include +#include /* * === diff --git a/drivers/i2c/sun6i_p2wi.c b/drivers/i2c/sun6i_p2wi.c index d221323295d..b8e07a533ca 100644 --- a/drivers/i2c/sun6i_p2wi.c +++ b/drivers/i2c/sun6i_p2wi.c @@ -20,10 +20,10 @@ #include #include #include +#include #include #include #include -#include #include #include #include diff --git a/drivers/i2c/sun8i_rsb.c b/drivers/i2c/sun8i_rsb.c index 47fa05b6d1c..f36f2c7afac 100644 --- a/drivers/i2c/sun8i_rsb.c +++ b/drivers/i2c/sun8i_rsb.c @@ -14,10 +14,10 @@ #include #include #include +#i
[PATCH v3 08/24] pinctrl: sunxi: move PIO_BASE into sunxi_gpio.h
On the Allwinner platform we were describing a quite comprehensive memory map in a per-SoC header unser arch/arm. In the old days that was used by every driver, but nowadays it should only be needed by SPL drivers (not using the DT). Many addresses in there were never used, and some are not needed anymore. To avoid a dependency on CPU specific headers in an arch specific directory, move the definition of the pinctroller MMIO base address into the sunxi_gpio.h header, because the SPL routines for GPIO should be the only one needing this address. This is a first step towards getting rid of cpu_sun[x]i.h completely, and allows to remove the inclusion of that file from the sunxi_gpio.h header. Signed-off-by: Andre Przywara --- arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 2 -- arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h | 2 -- arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 2 -- include/sunxi_gpio.h| 12 +++- 4 files changed, 11 insertions(+), 7 deletions(-) diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h index f7ecc790dbf..d6fe51f24bc 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h @@ -91,7 +91,6 @@ #define SUNXI_CCM_BASE 0x01c2 #define SUNXI_INTC_BASE0x01c20400 -#define SUNXI_PIO_BASE 0x01c20800 #define SUNXI_TIMER_BASE 0x01c20c00 #ifndef CONFIG_SUNXI_GEN_SUN6I #define SUNXI_PWM_BASE 0x01c20e00 @@ -210,7 +209,6 @@ defined(CONFIG_MACH_SUN50I) #define SUNXI_R_TWI_BASE 0x01f02400 #define SUNXI_R_UART_BASE 0x01f02800 -#define SUNXI_R_PIO_BASE 0x01f02c00 #define SUN6I_P2WI_BASE0x01f03400 #define SUNXI_RSB_BASE 0x01f03400 diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h index d9cf8ae0428..9b6bf843601 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h @@ -22,7 +22,6 @@ #define SUNXI_SIDC_BASE0x03006000 #define SUNXI_SID_BASE 0x03006200 #define SUNXI_TIMER_BASE 0x03009000 -#define SUNXI_PIO_BASE 0x0300B000 #define SUNXI_PSI_BASE 0x0300C000 #define SUNXI_GIC400_BASE 0x0302 @@ -68,7 +67,6 @@ #define SUNXI_R_CPUCFG_BASE0x07000400 #define SUNXI_PRCM_BASE0x0701 #define SUNXI_R_WDOG_BASE 0x07020400 -#define SUNXI_R_PIO_BASE 0x07022000 #define SUNXI_R_UART_BASE 0x0708 #define SUNXI_R_TWI_BASE 0x07081400 diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h index 9c2d11b5901..20025be2319 100644 --- a/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h +++ b/arch/arm/include/asm/arch-sunxi/cpu_sun9i.h @@ -81,7 +81,6 @@ /* APB0 Module */ #define SUNXI_CCM_BASE (REGS_APB0_BASE + 0x) #define SUNXI_CCMMODULE_BASE (REGS_APB0_BASE + 0x0400) -#define SUNXI_PIO_BASE (REGS_APB0_BASE + 0x0800) #define SUNXI_TIMER_BASE (REGS_APB0_BASE + 0x0C00) #define SUNXI_PWM_BASE (REGS_APB0_BASE + 0x1400) #define SUNXI_LRADC_BASE (REGS_APB0_BASE + 0x1800) @@ -102,7 +101,6 @@ /* RCPUS Module */ #define SUNXI_PRCM_BASE(REGS_RCPUS_BASE + 0x1400) #define SUNXI_R_UART_BASE (REGS_RCPUS_BASE + 0x2800) -#define SUNXI_R_PIO_BASE (REGS_RCPUS_BASE + 0x2c00) #define SUNXI_RSB_BASE (REGS_RCPUS_BASE + 0x3400) /* Misc. */ diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h index e0fb5b5da63..c1fdf7ea1d7 100644 --- a/include/sunxi_gpio.h +++ b/include/sunxi_gpio.h @@ -12,7 +12,17 @@ #define _SUNXI_GPIO_H #include -#include + +#if defined(CONFIG_MACH_SUN9I) +#define SUNXI_PIO_BASE 0x06000800 +#define SUNXI_R_PIO_BASE 0x08002c00 +#elif defined(CONFIG_SUN50I_GEN_H6) +#define SUNXI_PIO_BASE 0x0300b000 +#define SUNXI_R_PIO_BASE 0x07022000 +#else +#define SUNXI_PIO_BASE 0x01c20800 +#define SUNXI_R_PIO_BASE 0x01f02c00 +#endif /* * sunxi has 9 banks of gpio, they are: -- 2.25.1
[PATCH v3 09/24] pinctrl: sunxi: add new D1 pinctrl support
For the first time since at least the Allwinner A10 SoCs, the D1 (and
related cores) use a new pincontroller MMIO register layout, so we
cannot use our hardcoded, fixed offsets anymore.
Ideally this would all be handled by devicetree and DM drivers, but for
the DT-less SPL we still need the legacy interfaces.
Add a new Kconfig symbol to differenciate between the two generations of
pincontrollers, and just use that to just switch some basic symbols.
The rest is already abstracted enough, so works out of the box.
Signed-off-by: Andre Przywara
Reviewed-by: Sam Edwards
Tested-by: Sam Edwards
Tested-by: Samuel Holland
---
drivers/gpio/Kconfig | 7 +++
drivers/gpio/sunxi_gpio.c | 17 +++--
include/sunxi_gpio.h | 10 --
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 74baa98d3c1..ba42b0768e1 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -372,6 +372,13 @@ config SUNXI_GPIO
help
Support the GPIO device in Allwinner SoCs.
+config SUNXI_NEW_PINCTRL
+ bool
+ depends on SUNXI_GPIO
+ ---help---
+ The Allwinner D1 and other new SoCs use a different register map
+ for the GPIO block, which we need to know about in the SPL.
+
config XILINX_GPIO
bool "Xilinx GPIO driver"
depends on DM_GPIO
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index e335496581f..e4463a223f7 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -40,10 +40,23 @@
#define GPIO_DAT_REG_OFFSET0x10
#define GPIO_DRV_REG_OFFSET0x14
-#define GPIO_DRV_INDEX(pin)(((pin) & 0x1f) >> 4)
-#define GPIO_DRV_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
+
+/* Newer SoCs use a slightly different register layout */
+#ifdef CONFIG_SUNXI_NEW_PINCTRL
+/* pin drive strength: 4 bits per pin */
+#define GPIO_DRV_INDEX(pin)((pin) / 8)
+#define GPIO_DRV_OFFSET(pin) (((pin) % 8) * 4)
+
+#define GPIO_PULL_REG_OFFSET 0x24
+
+#else /* older generation pin controllers */
+/* pin drive strength: 2 bits per pin */
+#define GPIO_DRV_INDEX(pin)((pin) / 16)
+#define GPIO_DRV_OFFSET(pin) (((pin) % 16) * 2)
#define GPIO_PULL_REG_OFFSET 0x1c
+#endif
+
#define GPIO_PULL_INDEX(pin) (((pin) & 0x1f) >> 4)
#define GPIO_PULL_OFFSET(pin) pin) & 0x1f) & 0xf) << 1)
diff --git a/include/sunxi_gpio.h b/include/sunxi_gpio.h
index c1fdf7ea1d7..30d8879dbd3 100644
--- a/include/sunxi_gpio.h
+++ b/include/sunxi_gpio.h
@@ -62,7 +62,6 @@
#define SUN50I_H6_GPIO_POW_MOD_VAL 0x348
#define SUNXI_GPIOS_PER_BANK 32
-#define SUNXI_PINCTRL_BANK_SIZE 0x24
#define SUNXI_GPIO_NEXT(__gpio) \
((__gpio##_START) + SUNXI_GPIOS_PER_BANK)
@@ -102,7 +101,6 @@ enum sunxi_gpio_number {
/* GPIO pin function config */
#define SUNXI_GPIO_INPUT 0
#define SUNXI_GPIO_OUTPUT 1
-#define SUNXI_GPIO_DISABLE 7
#define SUN8I_H3_GPA_UART0 2
#define SUN8I_H3_GPA_UART2 2
@@ -171,6 +169,14 @@ enum sunxi_gpio_number {
#define SUN9I_GPN_R_RSB3
+#ifdef CONFIG_SUNXI_NEW_PINCTRL
+ #define SUNXI_PINCTRL_BANK_SIZE 0x30
+ #define SUNXI_GPIO_DISABLE 0xf
+#else
+ #define SUNXI_PINCTRL_BANK_SIZE 0x24
+ #define SUNXI_GPIO_DISABLE 0x7
+#endif
+
/* GPIO pin pull-up/down config */
#define SUNXI_GPIO_PULL_DISABLE0
#define SUNXI_GPIO_PULL_UP 1
--
2.25.1
[PATCH v3 10/24] sunxi: introduce NCAT2 generation model
Allwinner seems to typically stick to a common MMIO memory map for
several SoCs, but from time to time does some breaking changes, which
also introduce new generations of some peripherals. The last time this
happened with the H6, which apart from re-organising the base addresses
also changed the clock controller significantly. We added a
CONFIG_SUN50I_GEN_H6 symbol back then to mark SoCs sharing those traits.
Now the Allwinner D1 changes the memory map again, and also extends the
pincontroller, among other peripherals.
To mark this generation of SoCs, add a CONFIG_SUNXI_GEN_NCAT2 symbol,
this name is reportedly used in the Allwinner BSP code, and prevents us
from inventing our own name.
Add this new symbol to some guards that were already checking for the H6
generation, since many features are shared between the two (like the
renovated clock controller).
This paves the way to introduce a first user of this generation.
Signed-off-by: Andre Przywara
Tested-by: Samuel Holland
---
arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
arch/arm/include/asm/arch-sunxi/cpu.h | 2 +
.../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 43 +++
arch/arm/include/asm/arch-sunxi/mmc.h | 2 +-
arch/arm/include/asm/arch-sunxi/prcm.h| 2 +-
arch/arm/include/asm/arch-sunxi/timer.h | 2 +-
arch/arm/mach-sunxi/Kconfig | 12 +-
arch/arm/mach-sunxi/Makefile | 1 +
arch/arm/mach-sunxi/board.c | 22 ++
arch/arm/mach-sunxi/clock_sun50i_h6.c | 7 ++-
common/spl/Kconfig| 2 +-
drivers/i2c/mvtwsi.c | 3 +-
drivers/mmc/sunxi_mmc.c | 7 +--
include/sunxi_gpio.h | 3 ++
14 files changed, 90 insertions(+), 20 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 2cfd5407423..3d34261b0e5 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -16,7 +16,7 @@
/* clock control module regs definition */
#if defined(CONFIG_MACH_SUN8I_A83T)
#include
-#elif defined(CONFIG_SUN50I_GEN_H6)
+#elif defined(CONFIG_SUN50I_GEN_H6) || defined(CONFIG_SUNXI_GEN_NCAT2)
#include
#elif defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN8I) || \
defined(CONFIG_MACH_SUN50I) || defined(CONFIG_MACH_SUNIV)
diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h
b/arch/arm/include/asm/arch-sunxi/cpu.h
index b08f2023748..768c6572d6b 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu.h
@@ -10,6 +10,8 @@
#include
#elif defined(CONFIG_SUN50I_GEN_H6)
#include
+#elif defined(CONFIG_SUNXI_GEN_NCAT2)
+#include
#else
#include
#endif
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h
b/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h
new file mode 100644
index 000..ca92c39927d
--- /dev/null
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sunxi_ncat2.h
@@ -0,0 +1,43 @@
+/*
+ * (C) Copyright 2022 Arm Limited
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _SUNXI_CPU_SUNXI_NCAT2_H
+#define _SUNXI_CPU_SUNXI_NCAT2_H
+
+#define SUNXI_CCM_BASE 0x02001000
+#define SUNXI_TIMER_BASE 0x0205
+
+#define SUNXI_UART0_BASE 0x0250
+#define SUNXI_UART1_BASE 0x02500400
+#define SUNXI_UART2_BASE 0x02500800
+#define SUNXI_UART3_BASE 0x02500C00
+#define SUNXI_TWI0_BASE0x02502000
+#define SUNXI_TWI1_BASE0x02502400
+#define SUNXI_TWI2_BASE0x02502800
+#define SUNXI_TWI3_BASE0x02502C00
+
+#define SUNXI_SRAMC_BASE 0x0300
+/* SID address space starts at 0x03006000, but e-fuse is at offset 0x200 */
+#define SUNXI_SIDC_BASE0x03006000
+#define SUNXI_SID_BASE 0x03006200
+#define SUNXI_GIC400_BASE 0x0302
+
+#define SUNXI_MMC0_BASE0x0402
+#define SUNXI_MMC1_BASE0x04021000
+#define SUNXI_MMC2_BASE0x04022000
+
+#define SUNXI_R_CPUCFG_BASE0x07000400
+#define SUNXI_PRCM_BASE0x0701
+
+#define SUNXI_CPUCFG_BASE 0x0901
+
+#ifndef __ASSEMBLY__
+void sunxi_board_init(void);
+void sunxi_reset(void);
+int sunxi_get_sid(unsigned int *sid);
+#endif
+
+#endif /* _SUNXI_CPU_SUNXI_NCAT2_H */
diff --git a/arch/arm/include/asm/arch-sunxi/mmc.h
b/arch/arm/include/asm/arch-sunxi/mmc.h
index 5daacf10eb1..8ed3e0459c9 100644
--- a/arch/arm/include/asm/arch-sunxi/mmc.h
+++ b/arch/arm/include/asm/arch-sunxi/mmc.h
@@ -45,7 +45,7 @@ struct sunxi_mmc {
u32 chda; /* 0x90 */
u32 cbda; /* 0x94 */
u32 re
[PATCH v3 11/24] pinctrl: sunxi: add Allwinner D1 pinctrl description
Apart from using the new pinctrl MMIO register layout, the Allwinner D1
and related SoCs still need to usual set of mux values hardcoded in
U-Boot's pinctrl driver.
Add the values we need so far to this list, so that DM based drivers
will just work without further ado.
Signed-off-by: Andre Przywara
---
drivers/pinctrl/sunxi/Kconfig | 4
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 32 +++
2 files changed, 36 insertions(+)
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 77da90836b6..c8f937d91e9 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -124,4 +124,8 @@ config PINCTRL_SUN50I_H616_R
default MACH_SUN50I_H616
select PINCTRL_SUNXI
+config PINCTRL_SUN20I_D1
+ bool "Support for the Allwinner D1/R528 PIO"
+ select PINCTRL_SUNXI
+
endif
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index fc80fe50b14..bdf6360f176 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -598,6 +598,32 @@ static const struct sunxi_pinctrl_desc __maybe_unused
sun9i_a80_r_pinctrl_desc =
.num_banks = 3,
};
+static const struct sunxi_pinctrl_function sun20i_d1_pinctrl_functions[] = {
+ { "emac", 8 },/* PE0-PE15 */
+ { "gpio_in",0 },
+ { "gpio_out", 1 },
+ { "i2c0", 4 },/* PB10-PB11 */
+ { "mmc0", 2 },/* PF0-PF5 */
+ { "mmc1", 2 },/* PG0-PG5 */
+ { "mmc2", 3 },/* PC2-PC7 */
+ { "spi0", 2 },/* PC2-PC7 */
+#if IS_ENABLED(CONFIG_UART0_PORT_F)
+ { "uart0", 3 },/* PF2,PF4 */
+#else
+ { "uart0", 6 },/* PB0-PB1, PB8-PB9, PE2-PE3 */
+#endif
+ { "uart1", 2 },/* PG6-PG7 */
+ { "uart2", 7 },/* PB0-PB1 */
+ { "uart3", 7 },/* PB6-PB7 */
+};
+
+static const struct sunxi_pinctrl_desc __maybe_unused sun20i_d1_pinctrl_desc =
{
+ .functions = sun20i_d1_pinctrl_functions,
+ .num_functions = ARRAY_SIZE(sun20i_d1_pinctrl_functions),
+ .first_bank = SUNXI_GPIO_A,
+ .num_banks = 7,
+};
+
static const struct sunxi_pinctrl_function sun50i_a64_pinctrl_functions[] = {
{ "emac", 4 },/* PD8-PD23 */
{ "gpio_in",0 },
@@ -863,6 +889,12 @@ static const struct udevice_id sunxi_pinctrl_ids[] = {
.data = (ulong)&sun9i_a80_r_pinctrl_desc,
},
#endif
+#ifdef CONFIG_PINCTRL_SUN20I_D1
+ {
+ .compatible = "allwinner,sun20i-d1-pinctrl",
+ .data = (ulong)&sun20i_d1_pinctrl_desc,
+ },
+#endif
#ifdef CONFIG_PINCTRL_SUN50I_A64
{
.compatible = "allwinner,sun50i-a64-pinctrl",
--
2.25.1
[PATCH v3 05/24] pinctrl: sunxi: add GPIO in/out wrappers
So far we were open-coding the pincontroller's GPIO output/input access
in each function using that.
Provide functions that wrap that nicely, and follow the existing pattern
(set/get_{bank,}), so users don't need to know about the internals, and
we can abstract the new D1 pinctrl more easily.
Signed-off-by: Andre Przywara
Reviewed-by: Samuel Holland
---
drivers/gpio/sunxi_gpio.c | 55 ++-
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index 71c3168b755..3ca833316b5 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -81,6 +81,19 @@ int sunxi_gpio_get_cfgpin(u32 pin)
return sunxi_gpio_get_cfgbank(pio, pin);
}
+static void sunxi_gpio_set_value_bank(struct sunxi_gpio *pio,
+ int pin, bool set)
+{
+ u32 mask = 1U << pin;
+
+ clrsetbits_le32(&pio->dat, set ? 0 : mask, set ? mask : 0);
+}
+
+static int sunxi_gpio_get_value_bank(struct sunxi_gpio *pio, int pin)
+{
+ return !!(readl(&pio->dat) & (1U << pin));
+}
+
void sunxi_gpio_set_drv(u32 pin, u32 val)
{
u32 bank = GPIO_BANK(pin);
@@ -117,35 +130,20 @@ void sunxi_gpio_set_pull_bank(struct sunxi_gpio *pio, int
bank_offset, u32 val)
/* === Non-DM code, used by the SPL. */
#if !CONFIG_IS_ENABLED(DM_GPIO)
-static int sunxi_gpio_output(u32 pin, u32 val)
+static void sunxi_gpio_set_value(u32 pin, bool set)
{
- u32 dat;
u32 bank = GPIO_BANK(pin);
- u32 num = GPIO_NUM(pin);
struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
- dat = readl(&pio->dat);
- if (val)
- dat |= 0x1 << num;
- else
- dat &= ~(0x1 << num);
-
- writel(dat, &pio->dat);
-
- return 0;
+ sunxi_gpio_set_value_bank(pio, GPIO_NUM(pin), set);
}
-static int sunxi_gpio_input(u32 pin)
+static int sunxi_gpio_get_value(u32 pin)
{
- u32 dat;
u32 bank = GPIO_BANK(pin);
- u32 num = GPIO_NUM(pin);
struct sunxi_gpio *pio = BANK_TO_GPIO(bank);
- dat = readl(&pio->dat);
- dat >>= num;
-
- return dat & 0x1;
+ return sunxi_gpio_get_value_bank(pio, GPIO_NUM(pin));
}
int gpio_request(unsigned gpio, const char *label)
@@ -168,18 +166,21 @@ int gpio_direction_input(unsigned gpio)
int gpio_direction_output(unsigned gpio, int value)
{
sunxi_gpio_set_cfgpin(gpio, SUNXI_GPIO_OUTPUT);
+ sunxi_gpio_set_value(gpio, value);
- return sunxi_gpio_output(gpio, value);
+ return 0;
}
int gpio_get_value(unsigned gpio)
{
- return sunxi_gpio_input(gpio);
+ return sunxi_gpio_get_value(gpio);
}
int gpio_set_value(unsigned gpio, int value)
{
- return sunxi_gpio_output(gpio, value);
+ sunxi_gpio_set_value(gpio, value);
+
+ return 0;
}
int sunxi_name_to_gpio(const char *name)
@@ -231,13 +232,8 @@ int sunxi_name_to_gpio(const char *name)
static int sunxi_gpio_get_value(struct udevice *dev, unsigned offset)
{
struct sunxi_gpio_plat *plat = dev_get_plat(dev);
- u32 num = GPIO_NUM(offset);
- unsigned dat;
-
- dat = readl(&plat->regs->dat);
- dat >>= num;
- return dat & 0x1;
+ return sunxi_gpio_get_value_bank(plat->regs, offset);
}
static int sunxi_gpio_get_function(struct udevice *dev, unsigned offset)
@@ -275,9 +271,8 @@ static int sunxi_gpio_set_flags(struct udevice *dev,
unsigned int offset,
if (flags & GPIOD_IS_OUT) {
u32 value = !!(flags & GPIOD_IS_OUT_ACTIVE);
- u32 num = GPIO_NUM(offset);
- clrsetbits_le32(&plat->regs->dat, 1 << num, value << num);
+ sunxi_gpio_set_value_bank(plat->regs, offset, value);
sunxi_gpio_set_cfgbank(plat->regs, offset, SUNXI_GPIO_OUTPUT);
} else if (flags & GPIOD_IS_IN) {
u32 pull = 0;
--
2.25.1
[PATCH v3 12/24] clk: sunxi: Add support for the D1 CCU
From: Samuel Holland
Since the D1 CCU binding is defined, we can add support for its
gates/resets, following the pattern of the existing drivers.
Signed-off-by: Samuel Holland
Reviewed-by: Andre Przywara
Acked-by: Sean Anderson
Signed-off-by: Andre Przywara
---
drivers/clk/sunxi/Kconfig | 6 +++
drivers/clk/sunxi/Makefile| 1 +
drivers/clk/sunxi/clk_d1.c| 84 +++
drivers/clk/sunxi/clk_sunxi.c | 5 +++
4 files changed, 96 insertions(+)
create mode 100644 drivers/clk/sunxi/clk_d1.c
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf11fad6eef..f65e482ba4c 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -87,6 +87,12 @@ config CLK_SUN8I_H3
This enables common clock driver support for platforms based
on Allwinner H3/H5 SoC.
+config CLK_SUN20I_D1
+ bool "Clock driver for Allwinner D1"
+ help
+ This enables common clock driver support for platforms based
+ on Allwinner D1 SoC.
+
config CLK_SUN50I_H6
bool "Clock driver for Allwinner H6"
default MACH_SUN50I_H6
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 895da02ebea..90a277489dc 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
obj-$(CONFIG_CLK_SUN8I_H3) += clk_h3.o
+obj-$(CONFIG_CLK_SUN20I_D1) += clk_d1.o
obj-$(CONFIG_CLK_SUN50I_H6) += clk_h6.o
obj-$(CONFIG_CLK_SUN50I_H6_R) += clk_h6_r.o
obj-$(CONFIG_CLK_SUN50I_H616) += clk_h616.o
diff --git a/drivers/clk/sunxi/clk_d1.c b/drivers/clk/sunxi/clk_d1.c
new file mode 100644
index 000..9dae761de83
--- /dev/null
+++ b/drivers/clk/sunxi/clk_d1.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2021 Samuel Holland
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct ccu_clk_gate d1_gates[] = {
+ [CLK_APB0] = GATE_DUMMY,
+
+ [CLK_BUS_MMC0] = GATE(0x84c, BIT(0)),
+ [CLK_BUS_MMC1] = GATE(0x84c, BIT(1)),
+ [CLK_BUS_MMC2] = GATE(0x84c, BIT(2)),
+ [CLK_BUS_UART0] = GATE(0x90c, BIT(0)),
+ [CLK_BUS_UART1] = GATE(0x90c, BIT(1)),
+ [CLK_BUS_UART2] = GATE(0x90c, BIT(2)),
+ [CLK_BUS_UART3] = GATE(0x90c, BIT(3)),
+ [CLK_BUS_UART4] = GATE(0x90c, BIT(4)),
+ [CLK_BUS_UART5] = GATE(0x90c, BIT(5)),
+ [CLK_BUS_I2C0] = GATE(0x91c, BIT(0)),
+ [CLK_BUS_I2C1] = GATE(0x91c, BIT(1)),
+ [CLK_BUS_I2C2] = GATE(0x91c, BIT(2)),
+ [CLK_BUS_I2C3] = GATE(0x91c, BIT(3)),
+ [CLK_SPI0] = GATE(0x940, BIT(31)),
+ [CLK_SPI1] = GATE(0x944, BIT(31)),
+ [CLK_BUS_SPI0] = GATE(0x96c, BIT(0)),
+ [CLK_BUS_SPI1] = GATE(0x96c, BIT(1)),
+
+ [CLK_BUS_EMAC] = GATE(0x97c, BIT(0)),
+
+ [CLK_USB_OHCI0] = GATE(0xa70, BIT(31)),
+ [CLK_USB_OHCI1] = GATE(0xa74, BIT(31)),
+ [CLK_BUS_OHCI0] = GATE(0xa8c, BIT(0)),
+ [CLK_BUS_OHCI1] = GATE(0xa8c, BIT(1)),
+ [CLK_BUS_EHCI0] = GATE(0xa8c, BIT(4)),
+ [CLK_BUS_EHCI1] = GATE(0xa8c, BIT(5)),
+ [CLK_BUS_OTG] = GATE(0xa8c, BIT(8)),
+ [CLK_BUS_LRADC] = GATE(0xa9c, BIT(0)),
+
+ [CLK_RISCV] = GATE(0xd04, BIT(31)),
+};
+
+static struct ccu_reset d1_resets[] = {
+ [RST_BUS_MMC0] = RESET(0x84c, BIT(16)),
+ [RST_BUS_MMC1] = RESET(0x84c, BIT(17)),
+ [RST_BUS_MMC2] = RESET(0x84c, BIT(18)),
+ [RST_BUS_UART0] = RESET(0x90c, BIT(16)),
+ [RST_BUS_UART1] = RESET(0x90c, BIT(17)),
+ [RST_BUS_UART2] = RESET(0x90c, BIT(18)),
+ [RST_BUS_UART3] = RESET(0x90c, BIT(19)),
+ [RST_BUS_UART4] = RESET(0x90c, BIT(20)),
+ [RST_BUS_UART5] = RESET(0x90c, BIT(21)),
+ [RST_BUS_I2C0] = RESET(0x91c, BIT(16)),
+ [RST_BUS_I2C1] = RESET(0x91c, BIT(17)),
+ [RST_BUS_I2C2] = RESET(0x91c, BIT(18)),
+ [RST_BUS_I2C3] = RESET(0x91c, BIT(19)),
+ [RST_BUS_SPI0] = RESET(0x96c, BIT(16)),
+ [RST_BUS_SPI1] = RESET(0x96c, BIT(17)),
+
+ [RST_BUS_EMAC] = RESET(0x97c, BIT(16)),
+
+ [RST_USB_PHY0] = RESET(0xa70, BIT(30)),
+ [RST_USB_PHY1] = RESET(0xa74, BIT(30)),
+ [RST_BUS_OHCI0] = RESET(0xa8c, BIT(16)),
+ [RST_BUS_OHCI1] = RESET(0xa8c, BIT(17)),
+ [RST_BUS_EHCI0] = RESET(0xa8c, BIT(20)),
+ [RST_BUS_EHCI1] = RESET(0xa8c, BIT(21)),
+ [RST_BUS_OTG] = RESET(0xa8c, BIT(24)),
+ [RS
[PATCH v3 13/24] sunxi: clock: D1/R528: Enable PLL LDO during PLL1 setup
The D1/R528/T113s SoCs introduce a new "LDO enable" bit in the CPUX_PLL.
Just enable that when we program that PLL.
Signed-off-by: Andre Przywara
---
arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 1 +
arch/arm/mach-sunxi/clock_sun50i_h6.c | 12 +++-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 37df4410eaa..9895c2c220e 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -228,6 +228,7 @@ struct sunxi_ccm_reg {
/* pll1 bit field */
#define CCM_PLL1_CTRL_EN BIT(31)
+#define CCM_PLL1_LDO_ENBIT(30)
#define CCM_PLL1_LOCK_EN BIT(29)
#define CCM_PLL1_LOCK BIT(28)
#define CCM_PLL1_OUT_ENBIT(27)
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index 767a39fa2ab..d32e33465f5 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -89,11 +89,13 @@ void clock_set_pll1(unsigned int clk)
writel(val, &ccm->cpu_axi_cfg);
/* clk = 24*n/p, p is ignored if clock is >288MHz */
- writel(CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2 |
-#ifdef CONFIG_MACH_SUN50I_H616
- CCM_PLL1_OUT_EN |
-#endif
- CCM_PLL1_CTRL_N(clk / 2400), &ccm->pll1_cfg);
+ val = CCM_PLL1_CTRL_EN | CCM_PLL1_LOCK_EN | CCM_PLL1_CLOCK_TIME_2;
+ val |= CCM_PLL1_CTRL_N(clk / 2400);
+ if (IS_ENABLED(CONFIG_MACH_SUN50I_H616))
+ val |= CCM_PLL1_OUT_EN;
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2))
+ val |= CCM_PLL1_OUT_EN | CCM_PLL1_LDO_EN;
+ writel(val, &ccm->pll1_cfg);
while (!(readl(&ccm->pll1_cfg) & CCM_PLL1_LOCK)) {}
/* Switch CPU to PLL1 */
--
2.25.1
[PATCH v3 14/24] sunxi: clock: support D1/R528 PLL6 clock
The PLL_PERIPH0 clock changed a bit in the D1/R528/T113s SoCs: there is
new P0 divider at bits [18:16], and the M divider is 1.
Add code to support this version of "PLL6".
Signed-off-by: Andre Przywara
---
.../include/asm/arch-sunxi/clock_sun50i_h6.h | 2 ++
arch/arm/mach-sunxi/clock_sun50i_h6.c | 24 +--
2 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 9895c2c220e..8471e11aa02 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -249,6 +249,8 @@ struct sunxi_ccm_reg {
#define CCM_PLL6_CTRL_EN BIT(31)
#define CCM_PLL6_LOCK_EN BIT(29)
#define CCM_PLL6_LOCK BIT(28)
+#define CCM_PLL6_CTRL_P0_SHIFT 16
+#define CCM_PLL6_CTRL_P0_MASK (0x7 << CCM_PLL6_CTRL_P0_SHIFT)
#define CCM_PLL6_CTRL_N_SHIFT 8
#define CCM_PLL6_CTRL_N_MASK (0xff << CCM_PLL6_CTRL_N_SHIFT)
#define CCM_PLL6_CTRL_DIV1_SHIFT 0
diff --git a/arch/arm/mach-sunxi/clock_sun50i_h6.c
b/arch/arm/mach-sunxi/clock_sun50i_h6.c
index d32e33465f5..daae994787e 100644
--- a/arch/arm/mach-sunxi/clock_sun50i_h6.c
+++ b/arch/arm/mach-sunxi/clock_sun50i_h6.c
@@ -110,16 +110,26 @@ unsigned int clock_get_pll6(void)
{
struct sunxi_ccm_reg *const ccm =
(struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
- int m = IS_ENABLED(CONFIG_MACH_SUN50I_H6) ? 4 : 2;
-
uint32_t rval = readl(&ccm->pll6_cfg);
int n = ((rval & CCM_PLL6_CTRL_N_MASK) >> CCM_PLL6_CTRL_N_SHIFT) + 1;
- int div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
- CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
int div2 = ((rval & CCM_PLL6_CTRL_DIV2_MASK) >>
- CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
- /* The register defines PLL6-2X or PLL6-4X, not plain PLL6 */
- return 2400 / m * n / div1 / div2;
+ CCM_PLL6_CTRL_DIV2_SHIFT) + 1;
+ int div1, m;
+
+ if (IS_ENABLED(CONFIG_SUNXI_GEN_NCAT2)) {
+ div1 = ((rval & CCM_PLL6_CTRL_P0_MASK) >>
+ CCM_PLL6_CTRL_P0_SHIFT) + 1;
+ m = 1;
+ } else {
+ div1 = ((rval & CCM_PLL6_CTRL_DIV1_MASK) >>
+ CCM_PLL6_CTRL_DIV1_SHIFT) + 1;
+ if (IS_ENABLED(CONFIG_MACH_SUN50I_H6))
+ m = 4;
+ else
+ m = 2;
+ }
+
+ return 2400U * n / m / div1 / div2;
}
int clock_twi_onoff(int port, int state)
--
2.25.1
[PATCH v3 15/24] Kconfig: sunxi: prepare for using drivers/ram/sunxi
At the moment all Allwinner DRAM initialisation routines are stored in arch/arm/mach-sunxi, even though those "drivers" are just a giant collection of writel's, without any architectural dependency. The R528/T113-s SoC (with ARM cores) and the D1/D1s Soc (with RISC-V cores) share the same die, so should share the same DRAM init routines as well. To prepare for this, add a new sunxi directory inside drivers/ram, and add some stub entries to prepare for the addition of the share DRAM code for those SoCs. The RISC-V D1(s) SoCs will probably use SPL_DM, so for that SoC this would be the right directory anyway. Signed-off-by: Andre Przywara --- drivers/ram/Kconfig | 3 ++- drivers/ram/sunxi/Kconfig | 6 ++ 2 files changed, 8 insertions(+), 1 deletion(-) create mode 100644 drivers/ram/sunxi/Kconfig diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index bf999645774..5b07e920301 100644 --- a/drivers/ram/Kconfig +++ b/drivers/ram/Kconfig @@ -109,8 +109,9 @@ config IMXRT_SDRAM source "drivers/ram/aspeed/Kconfig" source "drivers/ram/cadence/Kconfig" +source "drivers/ram/octeon/Kconfig" source "drivers/ram/rockchip/Kconfig" source "drivers/ram/sifive/Kconfig" source "drivers/ram/stm32mp1/Kconfig" -source "drivers/ram/octeon/Kconfig" source "drivers/ram/starfive/Kconfig" +source "drivers/ram/sunxi/Kconfig" diff --git a/drivers/ram/sunxi/Kconfig b/drivers/ram/sunxi/Kconfig new file mode 100644 index 000..d7cf84c39a3 --- /dev/null +++ b/drivers/ram/sunxi/Kconfig @@ -0,0 +1,6 @@ +config DRAM_SUN20I_D1 + bool + depends on ARCH_SUNXI + help + This enables support for the DRAM controller driver covering + the Allwinner D1/R528/T113s SoCs. -- 2.25.1
[PATCH v3 16/24] sunxi: add R528/T113-s3/D1(s) DRAM initialisation code
The Allwinner R528/T113-s/D1/D1s SoCs all share the same die, so use the same DRAM initialisation code. Make use of prior art here and lift some code from awboot[1], which carried init code based on earlier decompilation efforts, but with a GPL2 license tag. This code has been heavily reworked and cleaned up, to match previous DRAM routines for other SoCs, and also to be closer to U-Boot's coding style and support routines. The actual DRAM chip timing parameters are included in the main file, since they cover all DRAM types, and are protected by a new Kconfig CONFIG_SUNXI_DRAM_TYPE symbol, which allows the compiler to pick only the relevant settings, at build time. The relevant DRAM chips/board specific configuration parameters are delivered via Kconfig, so this code here should work for all supported SoCs and DRAM chips combinations. Signed-off-by: Andre Przywara Tested-by: Sam Edwards --- drivers/Makefile |1 + drivers/ram/Makefile |3 + drivers/ram/sunxi/Kconfig | 54 ++ drivers/ram/sunxi/Makefile |3 + drivers/ram/sunxi/dram_sun20i_d1.c | 1441 drivers/ram/sunxi/dram_sun20i_d1.h | 73 ++ 6 files changed, 1575 insertions(+) create mode 100644 drivers/ram/sunxi/Makefile create mode 100644 drivers/ram/sunxi/dram_sun20i_d1.c create mode 100644 drivers/ram/sunxi/dram_sun20i_d1.h diff --git a/drivers/Makefile b/drivers/Makefile index 74f940a57d3..bf73b7718ce 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -57,6 +57,7 @@ obj-$(CONFIG_$(SPL_)ALTERA_SDRAM) += ddr/altera/ obj-$(CONFIG_ARCH_IMX8M) += ddr/imx/imx8m/ obj-$(CONFIG_IMX8ULP_DRAM) += ddr/imx/imx8ulp/ obj-$(CONFIG_ARCH_IMX9) += ddr/imx/imx9/ +obj-$(CONFIG_DRAM_SUN20I_D1) += ram/ obj-$(CONFIG_SPL_DM_RESET) += reset/ obj-$(CONFIG_SPL_MUSB_NEW) += usb/musb-new/ obj-$(CONFIG_SPL_USB_GADGET) += usb/gadget/ diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile index 6eb1a241359..985990ab5ac 100644 --- a/drivers/ram/Makefile +++ b/drivers/ram/Makefile @@ -23,6 +23,9 @@ obj-$(CONFIG_RAM_SIFIVE) += sifive/ ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_STARFIVE_DDR) += starfive/ endif + +obj-$(CONFIG_DRAM_SUN20I_D1) += sunxi/ + obj-$(CONFIG_ARCH_OCTEON) += octeon/ obj-$(CONFIG_ARCH_RMOBILE) += renesas/ diff --git a/drivers/ram/sunxi/Kconfig b/drivers/ram/sunxi/Kconfig index d7cf84c39a3..1775cb0d780 100644 --- a/drivers/ram/sunxi/Kconfig +++ b/drivers/ram/sunxi/Kconfig @@ -4,3 +4,57 @@ config DRAM_SUN20I_D1 help This enables support for the DRAM controller driver covering the Allwinner D1/R528/T113s SoCs. + +if DRAM_SUN20I_D1 + +config DRAM_SUNXI_ODT_EN + hex "DRAM ODT EN parameter" + help + ODT EN value from vendor DRAM settings. + +config DRAM_SUNXI_TPR0 + hex "DRAM TPR0 parameter" + help + TPR0 value from vendor DRAM settings. + +config DRAM_SUNXI_TPR11 + hex "DRAM TPR11 parameter" + help + TPR11 value from vendor DRAM settings. + +config DRAM_SUNXI_TPR12 + hex "DRAM TPR12 parameter" + help + TPR12 value from vendor DRAM settings. + +config DRAM_SUNXI_TPR13 + hex "DRAM TPR13 parameter" + help + TPR13 value from vendor DRAM settings. It tells which features + should be configured. + +choice + prompt "DRAM chip type" + default SUNXI_DRAM_TYPE_DDR3 if DRAM_SUN20I_D1 + +config SUNXI_DRAM_TYPE_DDR2 + bool "DDR2 chips" + +config SUNXI_DRAM_TYPE_DDR3 + bool "DDR3 chips" + +config SUNXI_DRAM_TYPE_LPDDR2 + bool "LPDDR2 chips" + +config SUNXI_DRAM_TYPE_LPDDR3 + bool "LPDDR3 chips" +endchoice + +config SUNXI_DRAM_TYPE + int + default 2 if SUNXI_DRAM_TYPE_DDR2 + default 3 if SUNXI_DRAM_TYPE_DDR3 + default 6 if SUNXI_DRAM_TYPE_LPDDR2 + default 7 if SUNXI_DRAM_TYPE_LPDDR3 + +endif diff --git a/drivers/ram/sunxi/Makefile b/drivers/ram/sunxi/Makefile new file mode 100644 index 000..86ea0b9ae98 --- /dev/null +++ b/drivers/ram/sunxi/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0+ + +obj-$(CONFIG_DRAM_SUN20I_D1) += dram_sun20i_d1.o diff --git a/drivers/ram/sunxi/dram_sun20i_d1.c b/drivers/ram/sunxi/dram_sun20i_d1.c new file mode 100644 index 000..38379281d73 --- /dev/null +++ b/drivers/ram/sunxi/dram_sun20i_d1.c @@ -0,0 +1,1441 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Allwinner D1/D1s/R528/T113-sx DRAM initialisation + * + * As usual there is no documentation for the memory controller or PHY IP + * used here. The baseline of this code was lifted from awboot[1], which + * seems to be based on some form of de-compilation of some original Allwinner + * code bits (with a GPL2 license tag from the very beginning). + * This version here is a reworked version, to match the U-Boot coding style + * and style of the other Allwinner DRAM drivers. + * + * [1] https://github.com/szemzoa/awboot.git + */ + +#include +#include +#ifdef CON
[PATCH v3 18/24] sunxi: R528: add SMHC2 pin pull ups support
From: Okhunjon Sobirjonov
Add support for eMMC (SMHC2) pin pull ups for R528 boards.
The D1 and T113s (and even R329) SoCs do not support 8-bit eMMC anymore,
so it's just four data pins to cover here.
Signed-off-by: Okhunjon Sobirjonov
Reviewed-by: Andre Przywara
[Andre: adjust commit message]
Signed-off-by: Andre Przywara
---
board/sunxi/board.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index 7a1c708b9f2..39ecbe988f7 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -459,6 +459,13 @@ static void mmc_pinmux_setup(int sdc)
sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
sunxi_gpio_set_drv(pin, 2);
}
+#elif defined(CONFIG_MACH_SUN8I_R528)
+/* SDC2: PC2-PC7 */
+for (pin = SUNXI_GPC(2); pin <= SUNXI_GPC(7); pin++) {
+sunxi_gpio_set_cfgpin(pin, SUNXI_GPC_SDC2);
+sunxi_gpio_set_pull(pin, SUNXI_GPIO_PULL_UP);
+sunxi_gpio_set_drv(pin, 2);
+}
#else
puts("ERROR: No pinmux setup defined for MMC2!\n");
#endif
--
2.25.1
[PATCH v3 17/24] sunxi: add Allwinner R528/T113 SoC support
This adds the remaining code bits to teach U-Boot about Allwinner's
newest SoC generation. This was introduced with the RISC-V based
Allwinner D1 SoC, which actually shares a die with the ARM cores versions
called R528 (BGA, without DRAM) and T113s (QFP, with embedded DRAM).
This adds the new Kconfig stanza, using the two newly introduced symbols
for the new SoC generation and pincontroller. It also adds the new symbols
to the relavent code places, to set all the hardcoded bits directly.
We need one DT override:
The ARM core version of the DT specifies the CPUX watchdog as
"reserved", which means it won't be recognised by U-Boot. Override this
in our generic sunxi-u-boot.dtsi, to let U-Boot pick up this watchdog,
so that the generic reset driver will work.
Signed-off-by: Andre Przywara
---
arch/arm/dts/sunxi-u-boot.dtsi| 7 +++
arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h | 9 +++--
arch/arm/mach-sunxi/Kconfig | 11 +++
arch/arm/mach-sunxi/board.c | 8
arch/arm/mach-sunxi/clock_sun50i_h6.c | 2 ++
arch/arm/mach-sunxi/cpu_info.c| 2 ++
common/spl/Kconfig| 1 +
drivers/clk/sunxi/Kconfig | 1 +
drivers/mmc/sunxi_mmc.c | 1 +
drivers/pinctrl/sunxi/Kconfig | 1 +
10 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/sunxi-u-boot.dtsi b/arch/arm/dts/sunxi-u-boot.dtsi
index af419c7e590..a0c8abb7033 100644
--- a/arch/arm/dts/sunxi-u-boot.dtsi
+++ b/arch/arm/dts/sunxi-u-boot.dtsi
@@ -23,6 +23,13 @@
};
};
+/* Let U-Boot be the firmware layer that controls the watchdog. */
+#ifdef CONFIG_MACH_SUN8I_R528
+&wdt {
+ status = "okay";
+};
+#endif
+
&binman {
u-boot-sunxi-with-spl {
filename = "u-boot-sunxi-with-spl.bin";
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
index 8471e11aa02..a84a57e5b41 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun50i_h6.h
@@ -266,7 +266,7 @@ struct sunxi_ccm_reg {
#define CCM_CPU_AXI_AXI_MASK 0x3
#define CCM_CPU_AXI_DEFAULT_FACTORS0x301
-#ifdef CONFIG_MACH_SUN50I_H6
+#ifdef CONFIG_MACH_SUN50I_H6 /* H6 */
#define CCM_PLL6_DEFAULT 0xa0006300
/* psi_ahb1_ahb2 bit field */
@@ -277,7 +277,7 @@ struct sunxi_ccm_reg {
/* apb1 bit field */
#define CCM_APB1_DEFAULT 0x03000102
-#elif CONFIG_MACH_SUN50I_H616
+#elif CONFIG_MACH_SUN50I_H616 /* H616 */
#define CCM_PLL6_DEFAULT 0xa8003100
/* psi_ahb1_ahb2 bit field */
@@ -288,6 +288,11 @@ struct sunxi_ccm_reg {
/* apb1 bit field */
#define CCM_APB1_DEFAULT 0x03000102
+#elif CONFIG_MACH_SUN8I_R528 /* R528 */
+#define CCM_PLL6_DEFAULT 0xe8216300
+#define CCM_PSI_AHB1_AHB2_DEFAULT 0x0302
+//#define CCM_AHB3_DEFAULT 0x0302
+#define CCM_APB1_DEFAULT 0x03000102
#endif
/* apb2 bit field */
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 6ba9ed2bb2a..d976203ee7b 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -346,6 +346,15 @@ config MACH_SUN8I_R40
select SUNXI_DRAM_DW_32BIT
imply SPL_SYS_I2C_LEGACY
+config MACH_SUN8I_R528
+ bool "sun8i (Allwinner R528)"
+ select CPU_V7A
+ select SUNXI_GEN_NCAT2
+ select SUNXI_NEW_PINCTRL
+ select MMC_SUNXI_HAS_NEW_MODE
+ select SUPPORT_SPL
+ select DRAM_SUN20I_D1
+
config MACH_SUN8I_V3S
bool "sun8i (Allwinner V3/V3s/S3/S3L)"
select CPU_V7A
@@ -656,6 +665,7 @@ config SYS_CLK_FREQ
default 100800 if MACH_SUN9I
default 88800 if MACH_SUN50I_H6
default 100800 if MACH_SUN50I_H616
+ default 100800 if MACH_SUN8I_R528
config SYS_CONFIG_NAME
default "suniv" if MACH_SUNIV
@@ -664,6 +674,7 @@ config SYS_CONFIG_NAME
default "sun6i" if MACH_SUN6I
default "sun7i" if MACH_SUN7I
default "sun8i" if MACH_SUN8I
+ default "sun8i" if MACH_SUN8I_R528
default "sun9i" if MACH_SUN9I
default "sun50i" if MACH_SUN50I
default "sun50i" if MACH_SUN50I_H6
diff --git a/arch/arm/mach-sunxi/board.c b/arch/arm/mach-sunxi/board.c
index d572314f0da..c2fadf75367 100644
--- a/arch/arm/mach-sunxi/board.c
+++ b/arch/arm/mach-sunxi/board.c
@@ -147,6 +147,10 @@ static int gpio_init(void)
sunxi_gpio_set_cfgpin(SUNXI_GPH(12), SUN9I_GPH_UART0);
sunxi_gpio_set_cfgpin(SUNXI_GPH(13), SUN9I_GPH_UART0);
sunxi_gpio_set_pull(SUNXI_GPH(13), SUNXI_GPIO_PULL_UP);
+#elif CONFIG_CONS_INDEX == 1 && defined(CONFIG_MACH_SUN8I_R528)
+ sunxi_gpio_set_cfgpin(SUNXI_GPE(2),
[PATCH v3 19/24] sunxi: refactor serial base addresses to avoid asm/arch/cpu.h
At the moment we have each SoC's memory map defined in its own cpu.h,
which is included in include/configs/sunxi_common.h. This will be a
problem with the introduction of Allwinner RISC-V support.
Remove the inclusion of that header file from the common config header,
instead move the required serial base addresses (for the SPL) into a
separate header file. Then include the original cpu.h file only where
we really need it, which is only under arch/arm now.
This disentangles the architecture specific header files from the
generic code.
Signed-off-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/sram.c | 1 +
arch/arm/cpu/armv8/fel_utils.S| 1 +
arch/arm/include/asm/arch-sunxi/boot0.h | 2 ++
arch/arm/include/asm/arch-sunxi/clock.h | 1 +
arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 15 -
.../include/asm/arch-sunxi/cpu_sun50i_h6.h| 5 ---
arch/arm/include/asm/arch-sunxi/cpu_sun9i.h | 7
.../include/asm/arch-sunxi/cpu_sunxi_ncat2.h | 4 ---
arch/arm/include/asm/arch-sunxi/serial.h | 32 +++
arch/arm/mach-sunxi/gtbus_sun9i.c | 1 +
arch/arm/mach-sunxi/timer.c | 1 +
include/configs/sunxi-common.h| 2 +-
12 files changed, 40 insertions(+), 32 deletions(-)
create mode 100644 arch/arm/include/asm/arch-sunxi/serial.h
diff --git a/arch/arm/cpu/armv7/sunxi/sram.c b/arch/arm/cpu/armv7/sunxi/sram.c
index 28564c2846a..28ff6a1b7c2 100644
--- a/arch/arm/cpu/armv7/sunxi/sram.c
+++ b/arch/arm/cpu/armv7/sunxi/sram.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
void sunxi_sram_init(void)
{
diff --git a/arch/arm/cpu/armv8/fel_utils.S b/arch/arm/cpu/armv8/fel_utils.S
index 2fe38a1a047..939869b9ffa 100644
--- a/arch/arm/cpu/armv8/fel_utils.S
+++ b/arch/arm/cpu/armv8/fel_utils.S
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/*
* We don't overwrite save_boot_params() here, to save the FEL state upon
diff --git a/arch/arm/include/asm/arch-sunxi/boot0.h
b/arch/arm/include/asm/arch-sunxi/boot0.h
index 30f5680757a..cad25c50bc6 100644
--- a/arch/arm/include/asm/arch-sunxi/boot0.h
+++ b/arch/arm/include/asm/arch-sunxi/boot0.h
@@ -3,6 +3,8 @@
* Configuration settings for the Allwinner A64 (sun50i) CPU
*/
+#include
+
#if defined(CONFIG_RESERVE_ALLWINNER_BOOT0_HEADER) &&
!defined(CONFIG_SPL_BUILD)
/* reserve space for BOOT0 header information */
b reset
diff --git a/arch/arm/include/asm/arch-sunxi/clock.h
b/arch/arm/include/asm/arch-sunxi/clock.h
index 3d34261b0e5..fcc8966cb0b 100644
--- a/arch/arm/include/asm/arch-sunxi/clock.h
+++ b/arch/arm/include/asm/arch-sunxi/clock.h
@@ -9,6 +9,7 @@
#define _SUNXI_CLOCK_H
#include
+#include
#define CLK_GATE_OPEN 0x1
#define CLK_GATE_CLOSE 0x0
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
index d6fe51f24bc..3daee2f574a 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun4i.h
@@ -128,20 +128,6 @@ defined(CONFIG_MACH_SUN50I)
#define SUNXI_CPUCFG_BASE 0x01c25c00
#endif
-#ifdef CONFIG_MACH_SUNIV
-#define SUNXI_UART0_BASE 0x01c25000
-#define SUNXI_UART1_BASE 0x01c25400
-#define SUNXI_UART2_BASE 0x01c25800
-#else
-#define SUNXI_UART0_BASE 0x01c28000
-#define SUNXI_UART1_BASE 0x01c28400
-#define SUNXI_UART2_BASE 0x01c28800
-#endif
-#define SUNXI_UART3_BASE 0x01c28c00
-#define SUNXI_UART4_BASE 0x01c29000
-#define SUNXI_UART5_BASE 0x01c29400
-#define SUNXI_UART6_BASE 0x01c29800
-#define SUNXI_UART7_BASE 0x01c29c00
#define SUNXI_PS2_0_BASE 0x01c2a000
#define SUNXI_PS2_1_BASE 0x01c2a400
@@ -208,7 +194,6 @@ defined(CONFIG_MACH_SUN50I)
#endif
#define SUNXI_R_TWI_BASE 0x01f02400
-#define SUNXI_R_UART_BASE 0x01f02800
#define SUN6I_P2WI_BASE0x01f03400
#define SUNXI_RSB_BASE 0x01f03400
diff --git a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
index 9b6bf843601..15ee092d358 100644
--- a/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
+++ b/arch/arm/include/asm/arch-sunxi/cpu_sun50i_h6.h
@@ -42,10 +42,6 @@
#define SUNXI_DRAM_PHY0_BASE 0x0480
#endif
-#define SUNXI_UART0_BASE 0x0500
-#define SUNXI_UART1_BASE 0x05000400
-#define SUNXI_UART2_BASE 0x05000800
-#define SUNXI_UART3_BASE 0x05000C00
#define SUNXI_TWI0_BASE0x05002000
#define SUNXI_TWI1_BASE0x05002400
#define SUNXI_TWI2_BASE0x05002800
@@ -67,7 +63,6 @@
#define SUNXI_R_CPUCFG_BASE0x07000400
#define SUNXI_PRCM_BASE
[PATCH v3 20/24] sunxi: psci: clean away preprocessor macros
From: Sam Edwards
This patch restructures psci.c to get away from the "many different
function definitions switched by #ifdef" paradigm to the preferred style
of having a single function definition with `if (IS_ENABLED(...))` to
make the optimizer include only the appropriate function bodies instead.
There are no functional changes here.
Signed-off-by: Sam Edwards
Reviewed-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/psci.c | 103 +---
1 file changed, 43 insertions(+), 60 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index e1d3638b5ca..69fa3f3c2eb 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -76,11 +76,8 @@ static void __secure __mdelay(u32 ms)
isb();
}
-static void __secure clamp_release(u32 __maybe_unused *clamp)
+static void __secure clamp_release(u32 *clamp)
{
-#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
- defined(CONFIG_MACH_SUN8I_H3) || \
- defined(CONFIG_MACH_SUN8I_R40)
u32 tmp = 0x1ff;
do {
tmp >>= 1;
@@ -88,83 +85,69 @@ static void __secure clamp_release(u32 __maybe_unused
*clamp)
} while (tmp);
__mdelay(10);
-#endif
}
-static void __secure clamp_set(u32 __maybe_unused *clamp)
+static void __secure clamp_set(u32 *clamp)
{
-#if defined(CONFIG_MACH_SUN6I) || defined(CONFIG_MACH_SUN7I) || \
- defined(CONFIG_MACH_SUN8I_H3) || \
- defined(CONFIG_MACH_SUN8I_R40)
writel(0xff, clamp);
-#endif
}
-static void __secure sunxi_power_switch(u32 *clamp, u32 *pwroff, bool on,
- int cpu)
+static void __secure sunxi_set_entry_address(void *entry)
{
- if (on) {
- /* Release power clamp */
- clamp_release(clamp);
-
- /* Clear power gating */
- clrbits_le32(pwroff, BIT(cpu));
+ /* secondary core entry address is programmed differently on R40 */
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
+ writel((u32)entry,
+ SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
} else {
- /* Set power gating */
- setbits_le32(pwroff, BIT(cpu));
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
- /* Activate power clamp */
- clamp_set(clamp);
+ writel((u32)entry, &cpucfg->priv0);
}
}
-#ifdef CONFIG_MACH_SUN8I_R40
-/* secondary core entry address is programmed differently on R40 */
-static void __secure sunxi_set_entry_address(void *entry)
-{
- writel((u32)entry,
- SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
-}
-#else
-static void __secure sunxi_set_entry_address(void *entry)
+static void __secure sunxi_cpu_set_power(int cpu, bool on)
{
+ u32 *clamp = NULL;
+ u32 *pwroff;
struct sunxi_cpucfg_reg *cpucfg =
(struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
- writel((u32)entry, &cpucfg->priv0);
-}
-#endif
+ /* sun7i (A20) is different from other single cluster SoCs */
+ if (IS_ENABLED(CONFIG_MACH_SUN7I)) {
+ clamp = &cpucfg->cpu1_pwr_clamp;
+ pwroff = &cpucfg->cpu1_pwroff;
+ cpu = 0;
+ } else if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
+ clamp = (void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu);
+ pwroff = (void *)cpucfg + SUN8I_R40_PWROFF;
+ } else {
+ struct sunxi_prcm_reg *prcm =
+ (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
-#ifdef CONFIG_MACH_SUN7I
-/* sun7i (A20) is different from other single cluster SoCs */
-static void __secure sunxi_cpu_set_power(int __always_unused cpu, bool on)
-{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+ if (IS_ENABLED(CONFIG_MACH_SUN6I) ||
+ IS_ENABLED(CONFIG_MACH_SUN8I_H3))
+ clamp = &prcm->cpu_pwr_clamp[cpu];
- sunxi_power_switch(&cpucfg->cpu1_pwr_clamp, &cpucfg->cpu1_pwroff,
- on, 0);
-}
-#elif defined CONFIG_MACH_SUN8I_R40
-static void __secure sunxi_cpu_set_power(int cpu, bool on)
-{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+ pwroff = &prcm->cpu_pwroff;
+ }
- sunxi_power_switch((void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu),
- (void *)cpucfg + SUN8I_R40_PWROFF,
- on, cpu);
-}
-#else /* ! CONFIG_MACH_SUN7I && ! CONFIG_MACH_SUN8I_R40 */
-static void __secure sunxi_cpu_set_power(int cpu, bool on)
-{
- struct sunxi_prcm_reg *prcm =
- (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
+ if (on) {
+ /* Release power clamp */
+ if (clamp)
+
[PATCH v3 21/24] sunxi: psci: refactor register access to separate functions
From: Sam Edwards
This is to prepare for R528, which does not have the typical
"CPUCFG" block; it has a "CPUX" block which provides these
same functions but is organized differently.
Moving the hardware-access bits to their own functions separates the
logic from the hardware so we can reuse the same logic.
Signed-off-by: Sam Edwards
Reviewed-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/psci.c | 66 +++--
1 file changed, 47 insertions(+), 19 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 69fa3f3c2eb..27ca9c39e18 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -92,7 +92,7 @@ static void __secure clamp_set(u32 *clamp)
writel(0xff, clamp);
}
-static void __secure sunxi_set_entry_address(void *entry)
+static void __secure sunxi_cpu_set_entry(int __always_unused cpu, void *entry)
{
/* secondary core entry address is programmed differently on R40 */
if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
@@ -149,30 +149,60 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
}
}
-void __secure sunxi_cpu_power_off(u32 cpuid)
+static void __secure sunxi_cpu_set_reset(int cpu, bool reset)
{
struct sunxi_cpucfg_reg *cpucfg =
(struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+ writel(reset ? 0b00 : 0b11, &cpucfg->cpu[cpu].rst);
+}
+
+static void __secure sunxi_cpu_set_locking(int cpu, bool lock)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+ if (lock)
+ clrbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ else
+ setbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+}
+
+static bool __secure sunxi_cpu_poll_wfi(int cpu)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+ return !!(readl(&cpucfg->cpu[cpu].status) & BIT(2));
+}
+
+static void __secure sunxi_cpu_invalidate_cache(int cpu)
+{
+ struct sunxi_cpucfg_reg *cpucfg =
+ (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
+
+ clrbits_le32(&cpucfg->gen_ctrl, BIT(cpu));
+}
+
+static void __secure sunxi_cpu_power_off(u32 cpuid)
+{
u32 cpu = cpuid & 0x3;
/* Wait for the core to enter WFI */
- while (1) {
- if (readl(&cpucfg->cpu[cpu].status) & BIT(2))
- break;
+ while (!sunxi_cpu_poll_wfi(cpu))
__mdelay(1);
- }
/* Assert reset on target CPU */
- writel(0, &cpucfg->cpu[cpu].rst);
+ sunxi_cpu_set_reset(cpu, true);
/* Lock CPU (Disable external debug access) */
- clrbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ sunxi_cpu_set_locking(cpu, true);
/* Power down CPU */
sunxi_cpu_set_power(cpuid, false);
- /* Unlock CPU (Disable external debug access) */
- setbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ /* Unlock CPU (Reenable external debug access) */
+ sunxi_cpu_set_locking(cpu, false);
}
static u32 __secure cp15_read_scr(void)
@@ -229,33 +259,31 @@ out:
int __secure psci_cpu_on(u32 __always_unused unused, u32 mpidr, u32 pc,
u32 context_id)
{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
u32 cpu = (mpidr & 0x3);
/* store target PC and context id */
psci_save(cpu, pc, context_id);
/* Set secondary core power on PC */
- sunxi_set_entry_address(&psci_cpu_entry);
+ sunxi_cpu_set_entry(cpu, &psci_cpu_entry);
/* Assert reset on target CPU */
- writel(0, &cpucfg->cpu[cpu].rst);
+ sunxi_cpu_set_reset(cpu, true);
/* Invalidate L1 cache */
- clrbits_le32(&cpucfg->gen_ctrl, BIT(cpu));
+ sunxi_cpu_invalidate_cache(cpu);
/* Lock CPU (Disable external debug access) */
- clrbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ sunxi_cpu_set_locking(cpu, true);
/* Power up target CPU */
sunxi_cpu_set_power(cpu, true);
/* De-assert reset on target CPU */
- writel(BIT(1) | BIT(0), &cpucfg->cpu[cpu].rst);
+ sunxi_cpu_set_reset(cpu, false);
- /* Unlock CPU (Disable external debug access) */
- setbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ /* Unlock CPU (Reenable external debug access) */
+ sunxi_cpu_set_locking(cpu, false);
return ARM_PSCI_RET_SUCCESS;
}
--
2.25.1
[PATCH v3 22/24] sunxi: psci: stop modeling register layout with C structs
From: Sam Edwards
Since the sunxi support nowadays generally prefers #defined register
offsets instead of modeling register layouts using C structs, now is a
good time to do this for PSCI as well. This patch moves away from using
the structs `sunxi_cpucfg_reg` and `sunxi_prcm_reg` in psci.c.
The former struct and its associated header file existed only to support
PSCI code, so also delete them altogether.
Signed-off-by: Sam Edwards
Reviewed-by: Andre Przywara
---
arch/arm/cpu/armv7/sunxi/psci.c | 57
arch/arm/include/asm/arch-sunxi/cpucfg.h | 67
2 files changed, 23 insertions(+), 101 deletions(-)
delete mode 100644 arch/arm/include/asm/arch-sunxi/cpucfg.h
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 27ca9c39e18..207aa6bc4bf 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -11,8 +11,6 @@
#include
#include
-#include
-#include
#include
#include
#include
@@ -27,6 +25,17 @@
#defineGICD_BASE (SUNXI_GIC400_BASE + GIC_DIST_OFFSET)
#defineGICC_BASE (SUNXI_GIC400_BASE + GIC_CPU_OFFSET_A15)
+/*
+ * Offsets into the CPUCFG block applicable to most SUNXIs.
+ */
+#define SUNXI_CPU_RST(cpu) (0x40 + (cpu) * 0x40 + 0x0)
+#define SUNXI_CPU_STATUS(cpu) (0x40 + (cpu) * 0x40 + 0x8)
+#define SUNXI_GEN_CTRL (0x184)
+#define SUNXI_PRIV0(0x1a4)
+#define SUN7I_CPU1_PWR_CLAMP (0x1b0)
+#define SUN7I_CPU1_PWROFF (0x1b4)
+#define SUNXI_DBG_CTRL1(0x1e4)
+
/*
* R40 is different from other single cluster SoCs.
*
@@ -99,10 +108,7 @@ static void __secure sunxi_cpu_set_entry(int
__always_unused cpu, void *entry)
writel((u32)entry,
SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
} else {
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
-
- writel((u32)entry, &cpucfg->priv0);
+ writel((u32)entry, SUNXI_CPUCFG_BASE + SUNXI_PRIV0);
}
}
@@ -110,26 +116,21 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
{
u32 *clamp = NULL;
u32 *pwroff;
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
/* sun7i (A20) is different from other single cluster SoCs */
if (IS_ENABLED(CONFIG_MACH_SUN7I)) {
- clamp = &cpucfg->cpu1_pwr_clamp;
- pwroff = &cpucfg->cpu1_pwroff;
+ clamp = (void *)SUNXI_CPUCFG_BASE + SUN7I_CPU1_PWR_CLAMP;
+ pwroff = (void *)SUNXI_CPUCFG_BASE + SUN7I_CPU1_PWROFF;
cpu = 0;
} else if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
- clamp = (void *)cpucfg + SUN8I_R40_PWR_CLAMP(cpu);
- pwroff = (void *)cpucfg + SUN8I_R40_PWROFF;
+ clamp = (void *)SUNXI_CPUCFG_BASE + SUN8I_R40_PWR_CLAMP(cpu);
+ pwroff = (void *)SUNXI_CPUCFG_BASE + SUN8I_R40_PWROFF;
} else {
- struct sunxi_prcm_reg *prcm =
- (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
-
if (IS_ENABLED(CONFIG_MACH_SUN6I) ||
IS_ENABLED(CONFIG_MACH_SUN8I_H3))
- clamp = &prcm->cpu_pwr_clamp[cpu];
+ clamp = (void *)SUNXI_PRCM_BASE + 0x140 + cpu * 0x4;
- pwroff = &prcm->cpu_pwroff;
+ pwroff = (void *)SUNXI_PRCM_BASE + 0x100;
}
if (on) {
@@ -151,37 +152,25 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
static void __secure sunxi_cpu_set_reset(int cpu, bool reset)
{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
-
- writel(reset ? 0b00 : 0b11, &cpucfg->cpu[cpu].rst);
+ writel(reset ? 0b00 : 0b11, SUNXI_CPUCFG_BASE + SUNXI_CPU_RST(cpu));
}
static void __secure sunxi_cpu_set_locking(int cpu, bool lock)
{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
-
if (lock)
- clrbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ clrbits_le32(SUNXI_CPUCFG_BASE + SUNXI_DBG_CTRL1, BIT(cpu));
else
- setbits_le32(&cpucfg->dbg_ctrl1, BIT(cpu));
+ setbits_le32(SUNXI_CPUCFG_BASE + SUNXI_DBG_CTRL1, BIT(cpu));
}
static bool __secure sunxi_cpu_poll_wfi(int cpu)
{
- struct sunxi_cpucfg_reg *cpucfg =
- (struct sunxi_cpucfg_reg *)SUNXI_CPUCFG_BASE;
-
- return !!(readl(&cpucfg->cpu[cpu].status) & BIT(2));
+ return !!(readl(SUNXI_CPUCFG_BASE + SUNXI_CPU_STATUS(cpu)) & BIT(2));
}
static void __secure sunxi_cpu_invalidate_cache(int cpu)
{
- struct sunxi_cpucfg_reg *cpucfg =
-
[PATCH v3 23/24] sunxi: psci: implement PSCI on R528
From: Sam Edwards
This patch adds the necessary code to make nonsec booting and PSCI
secondary core management functional on the R528/T113.
Signed-off-by: Sam Edwards
Tested-by: Maksim Kiselev
Tested-by: Kevin Amadiva
Reviewed-by: Andre Przywara
---
arch/arm/cpu/armv7/Kconfig | 3 +-
arch/arm/cpu/armv7/sunxi/psci.c | 52 -
arch/arm/mach-sunxi/Kconfig | 4 +++
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index f015d133cb0..4eb34b7b449 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -61,8 +61,9 @@ config ARMV7_SECURE_MAX_SIZE
config ARM_GIC_BASE_ADDRESS
hex
depends on ARMV7_NONSEC
- depends on ARCH_EXYNOS5
+ depends on ARCH_EXYNOS5 || MACH_SUN8I_R528
default 0x1048 if ARCH_EXYNOS5
+ default 0x0302 if MACH_SUN8I_R528
help
Override the GIC base address if the Arm Cortex defined
CBAR/PERIPHBASE system register holds the wrong value.
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 207aa6bc4bf..5cb8cfa6cf3 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -47,6 +47,24 @@
#define SUN8I_R40_PWR_CLAMP(cpu) (0x120 + (cpu) * 0x4)
#define SUN8I_R40_SRAMC_SOFT_ENTRY_REG0(0xbc)
+/*
+ * R528 is also different, as it has both cores powered up (but held in reset
+ * state) after the SoC is reset. Like the R40, it uses a "soft" entry point
+ * address register, but unlike the R40, it uses a newer "CPUX" block to manage
+ * CPU state, rather than the older CPUCFG system.
+ */
+#define SUN8I_R528_SOFT_ENTRY (0x1c8)
+#define SUN8I_R528_C0_RST_CTRL (0x)
+#define SUN8I_R528_C0_CTRL_REG0(0x0010)
+#define SUN8I_R528_C0_CPU_STATUS (0x0080)
+
+#define SUN8I_R528_C0_STATUS_STANDBYWFI(16)
+
+/* Only newer cores have this additional IP block. */
+#ifndef SUNXI_R_CPUCFG_BASE
+#define SUNXI_R_CPUCFG_BASE0
+#endif
+
static void __secure cp15_write_cntp_tval(u32 tval)
{
asm volatile ("mcr p15, 0, %0, c14, c2, 0" : : "r" (tval));
@@ -103,10 +121,12 @@ static void __secure clamp_set(u32 *clamp)
static void __secure sunxi_cpu_set_entry(int __always_unused cpu, void *entry)
{
- /* secondary core entry address is programmed differently on R40 */
if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
writel((u32)entry,
SUNXI_SRAMC_BASE + SUN8I_R40_SRAMC_SOFT_ENTRY_REG0);
+ } else if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ writel((u32)entry,
+ SUNXI_R_CPUCFG_BASE + SUN8I_R528_SOFT_ENTRY);
} else {
writel((u32)entry, SUNXI_CPUCFG_BASE + SUNXI_PRIV0);
}
@@ -125,6 +145,9 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
} else if (IS_ENABLED(CONFIG_MACH_SUN8I_R40)) {
clamp = (void *)SUNXI_CPUCFG_BASE + SUN8I_R40_PWR_CLAMP(cpu);
pwroff = (void *)SUNXI_CPUCFG_BASE + SUN8I_R40_PWROFF;
+ } else if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ /* R528 leaves both cores powered up, manages them via reset */
+ return;
} else {
if (IS_ENABLED(CONFIG_MACH_SUN6I) ||
IS_ENABLED(CONFIG_MACH_SUN8I_H3))
@@ -152,11 +175,27 @@ static void __secure sunxi_cpu_set_power(int cpu, bool on)
static void __secure sunxi_cpu_set_reset(int cpu, bool reset)
{
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ if (reset)
+ clrbits_le32(SUNXI_CPUCFG_BASE + SUN8I_R528_C0_RST_CTRL,
+BIT(cpu));
+ else
+ setbits_le32(SUNXI_CPUCFG_BASE + SUN8I_R528_C0_RST_CTRL,
+BIT(cpu));
+
+ return;
+ }
+
writel(reset ? 0b00 : 0b11, SUNXI_CPUCFG_BASE + SUNXI_CPU_RST(cpu));
}
static void __secure sunxi_cpu_set_locking(int cpu, bool lock)
{
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ /* Not required on R528 */
+ return;
+ }
+
if (lock)
clrbits_le32(SUNXI_CPUCFG_BASE + SUNXI_DBG_CTRL1, BIT(cpu));
else
@@ -165,11 +204,22 @@ static void __secure sunxi_cpu_set_locking(int cpu, bool
lock)
static bool __secure sunxi_cpu_poll_wfi(int cpu)
{
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ return !!(readl(SUNXI_CPUCFG_BASE + SUN8I_R528_C0_CPU_STATUS) &
+ BIT(SUN8I_R528_C0_STATUS_STANDBYWFI + cpu));
+ }
+
return !!(readl(SUNXI_CPUCFG_BASE + SUNXI_CPU_STATUS(cpu)) & BIT(2));
}
static void __secure sunxi_cpu_invalidate_cache(int cpu)
{
+ if (IS_ENABLED(CONFIG_MACH_SUN8I_R528)) {
+ clrbits
[PATCH v3 24/24] sunxi: add MangoPi MQ-R board support
The MangoPi MQ-R board uses an Allwinner T113s Soc (with 128MB of embedded DRAM), support for which was just added to the code. Since the devicetree was already synced from the latest Linux kernel tree, all we need is a _defconfig file to add support for the board. Signed-off-by: Andre Przywara --- arch/arm/dts/Makefile | 2 ++ configs/mangopi_mq_r_defconfig | 15 +++ 2 files changed, 17 insertions(+) create mode 100644 configs/mangopi_mq_r_defconfig diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index 4569483d5fd..3a9b365de10 100644 --- a/arch/arm/dts/Makefile +++ b/arch/arm/dts/Makefile @@ -776,6 +776,8 @@ dtb-$(CONFIG_MACH_SUN8I_V3S) += \ sun8i-s3-pinecube.dtb \ sun8i-v3-sl631-imx179.dtb \ sun8i-v3s-licheepi-zero.dtb +dtb-$(CONFIG_MACH_SUN8I_R528) += \ + sun8i-t113s-mangopi-mq-r-t113.dtb dtb-$(CONFIG_MACH_SUN50I_H5) += \ sun50i-h5-bananapi-m2-plus.dtb \ sun50i-h5-emlid-neutis-n5-devboard.dtb \ diff --git a/configs/mangopi_mq_r_defconfig b/configs/mangopi_mq_r_defconfig new file mode 100644 index 000..66ae639326f --- /dev/null +++ b/configs/mangopi_mq_r_defconfig @@ -0,0 +1,15 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_DEFAULT_DEVICE_TREE="sun8i-t113s-mangopi-mq-r-t113" +CONFIG_SPL=y +CONFIG_MACH_SUN8I_R528=y +CONFIG_DRAM_CLK=792 +CONFIG_DRAM_ZQ=8092667 +CONFIG_SUNXI_MINIMUM_DRAM_MB=128 +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_DRAM_SUNXI_ODT_EN=0 +CONFIG_DRAM_SUNXI_TPR0=0x004a2195 +CONFIG_DRAM_SUNXI_TPR11=0x34 +CONFIG_DRAM_SUNXI_TPR12=0x46 +CONFIG_DRAM_SUNXI_TPR13=0x34000100 +CONFIG_CONS_INDEX=4 -- 2.25.1
Re: [v4.1 2/2] CI, pytest: Add a test for sandbox without LTO
On Mon, Oct 23, 2023 at 12:05:34AM -0700, Simon Glass wrote:
> Hi Tom,
>
> On Sat, 21 Oct 2023 at 11:34, Tom Rini wrote:
> >
> > On Sat, Oct 21, 2023 at 08:43:00AM -0700, Simon Glass wrote:
> > > On Fri, 20 Oct 2023 at 14:53, Tom Rini wrote:
> > > >
> > > > The primary motivation for having a sandbox without LTO build in CI is
> > > > to ensure that we don't have that option break. We now have the ability
> > > > to run tests of specific options being enabled/disabled, so drop the
> > > > parts of CI that build and test that configuration specifically and add
> > > > a build test instead. We still test that "NO_LTO=1" rather than editing
> > > > the config file works via the ftrace tests.
> > > >
> > > > Signed-off-by: Tom Rini
> > > > ---
> > > > This creates a small bisectability gap in CI itself, but I think is more
> > > > reasonable than reworking the introduction of
> > > > test/py/tests/test_sandbox_opts.py
> > > >
> > > > Cc: Simon Glass
> > > > ---
> > > > .azure-pipelines.yml | 3 ---
> > > > .gitlab-ci.yml | 12
> > > > test/py/tests/test_sandbox_opts.py | 10 ++
> > > > 3 files changed, 10 insertions(+), 15 deletions(-)
> > >
> > > Reviewed-by: Simon Glass
> > >
> > > Q below
> > >
> > > >
> > > > diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
> > > > index 6f91553e8613..65533b36dde4 100644
> > > > --- a/.azure-pipelines.yml
> > > > +++ b/.azure-pipelines.yml
> > > > @@ -287,9 +287,6 @@ stages:
> > > > sandbox64_clang:
> > > >TEST_PY_BD: "sandbox64"
> > > >OVERRIDE: "-O clang-16"
> > > > -sandbox_nolto:
> > > > - TEST_PY_BD: "sandbox"
> > > > - BUILD_ENV: "NO_LTO=1"
> > > > sandbox_spl:
> > > >TEST_PY_BD: "sandbox_spl"
> > > >TEST_PY_TEST_SPEC: "test_ofplatdata or test_handoff or
> > > > test_spl"
> > > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
> > > > index 6decdfdee334..97c964fb8079 100644
> > > > --- a/.gitlab-ci.yml
> > > > +++ b/.gitlab-ci.yml
> > > > @@ -258,12 +258,6 @@ sandbox with clang test.py:
> > > > OVERRIDE: "-O clang-16"
> > > ><<: *buildman_and_testpy_dfn
> > > >
> > > > -sandbox without LTO test.py:
> > > > - variables:
> > > > -TEST_PY_BD: "sandbox"
> > > > -BUILD_ENV: "NO_LTO=1"
> > > > - <<: *buildman_and_testpy_dfn
> > > > -
> > > > sandbox64 test.py:
> > > >variables:
> > > > TEST_PY_BD: "sandbox64"
> > > > @@ -275,12 +269,6 @@ sandbox64 with clang test.py:
> > > > OVERRIDE: "-O clang-16"
> > > ><<: *buildman_and_testpy_dfn
> > > >
> > > > -sandbox64 without LTO test.py:
> > > > - variables:
> > > > -TEST_PY_BD: "sandbox64"
> > > > -BUILD_ENV: "NO_LTO=1"
> > > > - <<: *buildman_and_testpy_dfn
> > > > -
> > > > sandbox_spl test.py:
> > > >variables:
> > > > TEST_PY_BD: "sandbox_spl"
> > > > diff --git a/test/py/tests/test_sandbox_opts.py
> > > > b/test/py/tests/test_sandbox_opts.py
> > > > index 91790b3374b4..422b43cb3bc1 100644
> > > > --- a/test/py/tests/test_sandbox_opts.py
> > > > +++ b/test/py/tests/test_sandbox_opts.py
> > > > @@ -18,3 +18,13 @@ def test_sandbox_cmdline(u_boot_console):
> > > > out = util.run_and_log(
> > > > cons, ['./tools/buildman/buildman', '-m', '--board', 'sandbox',
> > > > '-a', '~CMDLINE', '-o', TMPDIR])
> > > > +
> > > > +@pytest.mark.slow
> > > > +@pytest.mark.boardspec('sandbox')
> > > > +def test_sandbox_lto(u_boot_console):
> > > > +"""Test building sandbox without CONFIG_LTO"""
> > > > +cons = u_boot_console
> > > > +
> > > > +out = util.run_and_log(
> > > > +cons, ['./tools/buildman/buildman', '-m', '--board', 'sandbox',
> > > > + '-a', '~LTO', '-o', TMPDIR])
> > >
> > > Don't you need sandbox64 here?
> >
> > No, I don't think it's providing further value to just build sandbox64
> > without LTO. I'm also not 100% sure this patch is really needed in that
> > we're
> > trying to test for "did we disable LTO via make arguments" and in turn
> > only the ftrace test really catches that, as it will fail if we do have
> > LTO enabled, yes?
>
> Really the test is to make sure that sandbox builds without LTO. With
> the build time being. For development, LTO serves no useful purpose
> and just triples the incremental build time.
>
> I suggest we keep sandbox64 just to prevent a regression on non-LTO,
> but I suspect it is unlikely to happen in practice.
I don't follow you here. This adds the build time test for disabling
LTO, as that's at least an option for sandbox (other platforms require
it because otherwise we won't fit on the hardware). I'm mainly not sure
if this test is right in that what we really want to know is "does
NO_LTO=1" pass things as expected, and the ftrace test covers that.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] buildman: Include symbols in the read-only data section
On Mon, Oct 23, 2023 at 12:52:43AM -0700, Simon Glass wrote: > When symbols switch between the inited data section and the read-only > data section their visbility changes, at present, with the -B option. > > This is confusing, since adding 'const' to a variable declaration can > make it look like a significant improvement in bloat. But in fact > nothing has changed. > > Add 'r' to the list of symbols types that are recorded, to correct this > problem. Add a constant to make it easier to find this code next time. > > Signed-off-by: Simon Glass Thanks for fixing this. Reported-by: Tom Rini Reviewed-by: Tom Rini Link: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/6 -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] general: fix GPL-2.0-or-later SPDX headers
On Sun, Oct 22, 2023 at 07:47:07PM +0200, Heinrich Schuchardt wrote: > SPDX headers should use GPL-2.0-or-later and not GPL-2.0+. > > Signed-off-by: Heinrich Schuchardt So, first, iirc GPL-2.0+ is deprecated, but still valid, yes? We should use the current form of all tags moving forward as I do remember there's a reason for the switch to "-or-later" from "+". But second, the linux kernel is still full of "GPL-2.0+" including dts files that this patch changes, and so will get lost again on re-sync. -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] general: fix GPL-2.0-or-later SPDX headers
On 23.10.23 15:43, Tom Rini wrote: On Sun, Oct 22, 2023 at 07:47:07PM +0200, Heinrich Schuchardt wrote: SPDX headers should use GPL-2.0-or-later and not GPL-2.0+. Signed-off-by: Heinrich Schuchardt So, first, iirc GPL-2.0+ is deprecated, but still valid, yes? We should use the current form of all tags moving forward as I do remember there's a reason for the switch to "-or-later" from "+". But second, the linux kernel is still full of "GPL-2.0+" including dts files that this patch changes, and so will get lost again on re-sync. I cannot find GPL-2.0+ in https://spdx.org/licenses/ anymore. It was marked deprecated in 2017. Best regards Heinrich
Re: [PATCH 1/1] general: fix GPL-2.0-or-later SPDX headers
On Mon, Oct 23, 2023 at 03:51:39PM +0200, Heinrich Schuchardt wrote: > On 23.10.23 15:43, Tom Rini wrote: > > On Sun, Oct 22, 2023 at 07:47:07PM +0200, Heinrich Schuchardt wrote: > > > > > SPDX headers should use GPL-2.0-or-later and not GPL-2.0+. > > > > > > Signed-off-by: Heinrich Schuchardt > > > > So, first, iirc GPL-2.0+ is deprecated, but still valid, yes? We should > > use the current form of all tags moving forward as I do remember there's > > a reason for the switch to "-or-later" from "+". But second, the linux > > kernel is still full of "GPL-2.0+" including dts files that this patch > > changes, and so will get lost again on re-sync. > > > > I cannot find GPL-2.0+ in https://spdx.org/licenses/ anymore. It was marked > deprecated in 2017. Yes, deprecated is still valid. A quick peek at the kernel shows ~4600 "+" and ~8800 "or-later". So please re-work this to not touch the dts and binding files that come from Linux, so we don't revert this change on resyncs, thanks. -- Tom signature.asc Description: PGP signature
Re: [RESEND PATCH 1/1] clk: ti: k3-pll: Add calibration support for non fractional mode
Hi Vishal! +Tom On October 23, 2023 thus sayeth Vishal Mahaveer: > PLL calibration needs to be enabled when operating in non fractional > mode. Add the sequence to do a fast calibration when using PLL > in this mode. > > Signed-off-by: Vishal Mahaveer Reviewed-by: Bryan Brattlof > --- > drivers/clk/ti/clk-k3-pll.c | 81 ++--- > 1 file changed, 75 insertions(+), 6 deletions(-) > Thanks for fixing this! I've tested the am62x and the j721e and this appears to properly setup the PLLs without firmware's help after :) ~Bryan
Re: [PATCH v5 0/4] Conclusive KSTR-SAMA5D27 support
On 10/18/23 17:00, Artur Rojek wrote: Hi all, this is v5 of the Conclusive KSTR-SAMA5D27 support series. Patches [1/4], [2/4] and [3/4] remain unchanged. In patch [4/4], a new dtsi file has been added in order to keep U-Boot specific properties separate from the main dts. As such, MAINTAINERS has been modified to feature the new file. An alias to the i2c node holding the EEPROM has also been explicitly added, so that it always enumerates at bus 2. Artur Rojek (4): common: add prototype & rename populate_serial_number() event: add new EVT_SETTINGS_R event arm: dts: at91: sama5: Add flexcom4 node board: Add support for Conclusive KSTR-SAMA5D27 arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi | 42 +++ arch/arm/dts/at91-kstr-sama5d27.dts | 127 ++ arch/arm/dts/sama5d2.dtsi | 20 ++ arch/arm/mach-at91/Kconfig| 12 + board/conclusive/kstr-sama5d27/Kconfig| 15 ++ board/conclusive/kstr-sama5d27/MAINTAINERS| 9 + board/conclusive/kstr-sama5d27/Makefile | 5 + .../conclusive/kstr-sama5d27/kstr-sama5d27.c | 239 ++ cmd/tlv_eeprom.c | 14 +- common/board_r.c | 1 + common/event.c| 1 + configs/kstr_sama5d27_defconfig | 73 ++ include/configs/kstr-sama5d27.h | 15 ++ include/event.h | 9 + include/init.h| 14 + 16 files changed, 586 insertions(+), 13 deletions(-) create mode 100644 arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts create mode 100644 board/conclusive/kstr-sama5d27/Kconfig create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS create mode 100644 board/conclusive/kstr-sama5d27/Makefile create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c create mode 100644 configs/kstr_sama5d27_defconfig create mode 100644 include/configs/kstr-sama5d27.h Applied series to u-boot-at91 / master, thanks !
[PATCH v3 0/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board
Changes since v2: * Rebase on pending DT sync patch. * Collect r-b tags. Changes since v1: * Sync recently added DT from linux-next * Sync led dt-bindings Tom Fitzhenry (2): dt-bindings: leds: import common led bindings from linux v6.5 board: rockchip: add Pine64 QuartzPro64 RK3588 board arch/arm/dts/Makefile |1 + arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi | 12 + arch/arm/dts/rk3588-quartzpro64.dts | 1137 + arch/arm/mach-rockchip/rk3588/Kconfig |8 + board/pine64/quartzpro64-rk3588/Kconfig | 15 + board/pine64/quartzpro64-rk3588/MAINTAINERS |8 + board/pine64/quartzpro64-rk3588/Makefile |3 + .../quartzpro64-rk3588/quartzpro64-rk3588.c | 39 + configs/quartzpro64-rk3588_defconfig | 72 ++ doc/board/rockchip/rockchip.rst |1 + include/configs/quartzpro64-rk3588.h | 14 + include/dt-bindings/leds/common.h |7 +- 12 files changed, 1316 insertions(+), 1 deletion(-) create mode 100644 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi create mode 100644 arch/arm/dts/rk3588-quartzpro64.dts create mode 100644 board/pine64/quartzpro64-rk3588/Kconfig create mode 100644 board/pine64/quartzpro64-rk3588/MAINTAINERS create mode 100644 board/pine64/quartzpro64-rk3588/Makefile create mode 100644 board/pine64/quartzpro64-rk3588/quartzpro64-rk3588.c create mode 100644 configs/quartzpro64-rk3588_defconfig create mode 100644 include/configs/quartzpro64-rk3588.h -- 2.42.0
[PATCH v3 1/2] dt-bindings: leds: import common led bindings from linux v6.5
This brings in more colours, e.g. ORANGE needed for the QuartzPro64 DT.
Linux commits:
472d7b9e8141 ("dt-bindings: leds: Expand LED_COLOR_ID definitions")
Signed-off-by: Tom Fitzhenry
Reviewed-by: Kever Yang
---
include/dt-bindings/leds/common.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/include/dt-bindings/leds/common.h
b/include/dt-bindings/leds/common.h
index 3be89a7c20a..9a0d33d027f 100644
--- a/include/dt-bindings/leds/common.h
+++ b/include/dt-bindings/leds/common.h
@@ -33,7 +33,12 @@
#define LED_COLOR_ID_MULTI 8 /* For multicolor LEDs */
#define LED_COLOR_ID_RGB 9 /* For multicolor LEDs that can do
arbitrary color,
so this would include RGBW and
similar */
-#define LED_COLOR_ID_MAX 10
+#define LED_COLOR_ID_PURPLE10
+#define LED_COLOR_ID_ORANGE11
+#define LED_COLOR_ID_PINK 12
+#define LED_COLOR_ID_CYAN 13
+#define LED_COLOR_ID_LIME 14
+#define LED_COLOR_ID_MAX 15
/* Standard LED functions */
/* Keyboard LEDs, usually it would be input4::capslock etc. */
--
2.42.0
[PATCH v3 2/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board
QuartzPro64 is a Rockchip RK3588 based SBC by Pine64.
UART and boot over SD/eMMC/RJ45 are tested to work.
Linux commits from next-20231013:
8152d3d070a9 ("arm64: dts: rockchip: Add QuartzPro64 SBC device tree")
Signed-off-by: Tom Fitzhenry
Reviewed-by: Kever Yang
Cc: Eugen Hristev
Cc: Jonas Karlman
Cc: Ondrej Jirman
---
This patch depends on "rockchip: rk3588: Sync device tree from
v6.7-rockchip-dts64-1 tag"[0], since the QuartzPro64 upstream DT
depends on upstream dtsi changes.
0. https://lore.kernel.org/all/20231017170216.1627789-2-jo...@kwiboo.se/
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi | 12 +
arch/arm/dts/rk3588-quartzpro64.dts | 1137 +
arch/arm/mach-rockchip/rk3588/Kconfig |8 +
board/pine64/quartzpro64-rk3588/Kconfig | 15 +
board/pine64/quartzpro64-rk3588/MAINTAINERS |8 +
board/pine64/quartzpro64-rk3588/Makefile |3 +
.../quartzpro64-rk3588/quartzpro64-rk3588.c | 39 +
configs/quartzpro64-rk3588_defconfig | 72 ++
doc/board/rockchip/rockchip.rst |1 +
include/configs/quartzpro64-rk3588.h | 14 +
11 files changed, 1310 insertions(+)
create mode 100644 arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3588-quartzpro64.dts
create mode 100644 board/pine64/quartzpro64-rk3588/Kconfig
create mode 100644 board/pine64/quartzpro64-rk3588/MAINTAINERS
create mode 100644 board/pine64/quartzpro64-rk3588/Makefile
create mode 100644 board/pine64/quartzpro64-rk3588/quartzpro64-rk3588.c
create mode 100644 configs/quartzpro64-rk3588_defconfig
create mode 100644 include/configs/quartzpro64-rk3588.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 4569483d5fd..6d1e33d9e2e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -191,6 +191,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3588) += \
rk3588-edgeble-neu6a-io.dtb \
rk3588-edgeble-neu6b-io.dtb \
rk3588-evb1-v10.dtb \
+ rk3588-quartzpro64.dtb \
rk3588s-rock-5a.dtb \
rk3588-rock-5b.dtb
diff --git a/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
new file mode 100644
index 000..191ec988c45
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi
@@ -0,0 +1,12 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2023 Google, Inc
+ */
+
+#include "rk3588-u-boot.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
+ };
+};
diff --git a/arch/arm/dts/rk3588-quartzpro64.dts
b/arch/arm/dts/rk3588-quartzpro64.dts
new file mode 100644
index 000..5c59f9571dc
--- /dev/null
+++ b/arch/arm/dts/rk3588-quartzpro64.dts
@@ -0,0 +1,1137 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Ondřej Jirman
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+#include
+#include
+#include "rk3588.dtsi"
+
+/ {
+ model = "PINE64 QuartzPro64";
+ compatible = "pine64,quartzpro64", "rockchip,rk3588";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ serial2 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys-0 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-maskrom {
+ label = "Mask Rom";
+ linux,code = ;
+ press-threshold-microvolt = <393>;
+ };
+ };
+
+ adc-keys-1 {
+ compatible = "adc-keys";
+ io-channels = <&saradc 1>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ button-volume-up {
+ label = "V+/REC";
+ linux,code = ;
+ press-threshold-microvolt = <17821>;
+ };
+
+ button-volume-down {
+ label = "V-";
+ linux,code = ;
+ press-threshold-microvolt = <415384>;
+ };
+
+ button-menu {
+ label = "MENU";
+ linux,code = ;
+ press-threshold-microvolt = <890909>;
+ };
+
+ button-esc {
+ label = "ESC";
+ linux,code = ;
+ press-threshold-microvolt = <1233962>;
+ };
+ };
+
+ headphone_amp: audio-amplifier-headphone {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = <&gpio1 RK_PD2 GPIO_ACTIVE_HIGH>;
+ sou
Re: [PATCH v2 2/2] board: rockchip: add Pine64 QuartzPro64 RK3588 board
Kever Yang writes: > On 2023/10/17 23:59, Tom Fitzhenry wrote: >> This patch depends on "rockchip: rk3588: Sync device tree from linux >> maintainer tree"[0], since the QuartzPro64 upstream DT depends on upstream >> dtsi changes. > > This patch has been update to V2, and your patch are not able to apply > any more. > > Please help to rebase it. Thank you for your review. I have sent a v3 patch[0] which is rebased on top of master ( 9a3a58396b78b1f9d0c14580dc03f81d29207dd2 ) and Jonas's v2 patch. 0. https://lore.kernel.org/all/20231023142246.26830-1-...@tom-fitzhenry.me.uk/ 1. https://lore.kernel.org/all/20231017170216.1627789-2-jo...@kwiboo.se/
[PULL] u-boot-at91-2024.01-b
Hello Tom, Please pull tag u-boot-at91-2024.01-b , the second set of at91 features for 2024.01 cycle. This feature set a new board named Conclusive KSTR sama5d27 with some small prerequisites patches. Thanks, Eugen The following changes since commit 9a3a58396b78b1f9d0c14580dc03f81d29207dd2: Merge https://source.denx.de/u-boot/custodians/u-boot-marvell (2023-10-20 12:54:33 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-at91.git tags/u-boot-at91-2024.01-b for you to fetch changes up to 27347893f02d4457b80357a38c194a726a43533a: board: Add support for Conclusive KSTR-SAMA5D27 (2023-10-23 17:07:06 +0300) Second set of u-boot-at91 features for the 2024.01 cycle Artur Rojek (4): common: add prototype & rename populate_serial_number() event: add new EVT_SETTINGS_R event arm: dts: at91: sama5: Add flexcom4 node board: Add support for Conclusive KSTR-SAMA5D27 arch/arm/dts/Makefile | 3 + arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi| 42 + arch/arm/dts/at91-kstr-sama5d27.dts| 127 + arch/arm/dts/sama5d2.dtsi | 20 +++ arch/arm/mach-at91/Kconfig | 12 ++ board/conclusive/kstr-sama5d27/Kconfig | 15 ++ board/conclusive/kstr-sama5d27/MAINTAINERS | 9 + board/conclusive/kstr-sama5d27/Makefile| 5 + board/conclusive/kstr-sama5d27/kstr-sama5d27.c | 239 + cmd/tlv_eeprom.c | 14 +- common/board_r.c | 1 + common/event.c | 1 + configs/kstr_sama5d27_defconfig| 73 include/configs/kstr-sama5d27.h| 15 ++ include/event.h| 9 + include/init.h | 14 ++ 16 files changed, 586 insertions(+), 13 deletions(-) create mode 100644 arch/arm/dts/at91-kstr-sama5d27-u-boot.dtsi create mode 100644 arch/arm/dts/at91-kstr-sama5d27.dts create mode 100644 board/conclusive/kstr-sama5d27/Kconfig create mode 100644 board/conclusive/kstr-sama5d27/MAINTAINERS create mode 100644 board/conclusive/kstr-sama5d27/Makefile create mode 100644 board/conclusive/kstr-sama5d27/kstr-sama5d27.c create mode 100644 configs/kstr_sama5d27_defconfig create mode 100644 include/configs/kstr-sama5d27.h
[PATCH] MAINTAINERS: Remove non-working address from MAINTAINERS
From: Hugo Villeneuve The address ariel.dalessan...@collabora.com is no longer working: A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: ariel.dalessan...@collabora.com host mx.collabora.co.uk [46.235.227.165] SMTP error from remote mail server after RCPT TO:: 550 5.1.1 : Recipient address rejected: undeliverable address: host mail.collabora.co.uk[46.235.227.172] said: 550 5.1.1 : Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command) Remove this address from MAINTAINERS. Signed-off-by: Hugo Villeneuve --- board/bsh/imx8mn_smm_s2/MAINTAINERS| 1 - board/variscite/imx8mn_var_som/MAINTAINERS | 1 - 2 files changed, 2 deletions(-) diff --git a/board/bsh/imx8mn_smm_s2/MAINTAINERS b/board/bsh/imx8mn_smm_s2/MAINTAINERS index 1de816ca871..c7898278359 100644 --- a/board/bsh/imx8mn_smm_s2/MAINTAINERS +++ b/board/bsh/imx8mn_smm_s2/MAINTAINERS @@ -1,5 +1,4 @@ ARM i.MX8MN BSH SMM S2 BOARDS -M: Ariel D'Alessandro M: Michael Trimarchi S: Maintained F: arch/arm/dts/imx8mn-bsh-smm-s2* diff --git a/board/variscite/imx8mn_var_som/MAINTAINERS b/board/variscite/imx8mn_var_som/MAINTAINERS index 367f72dfe4f..a0fb1546f2f 100644 --- a/board/variscite/imx8mn_var_som/MAINTAINERS +++ b/board/variscite/imx8mn_var_som/MAINTAINERS @@ -1,5 +1,4 @@ ARM i.MX8MN VARISCITE VAR-SOM-MX8MN MODULE -M: Ariel D'Alessandro M: Hugo Villeneuve S: Maintained F: arch/arm/dts/imx8mn-var-som* base-commit: 4655b75335384e040358a2e3e478cc42f32a96c9 prerequisite-patch-id: 046349f916b24300d12c076e4cc3f02d81599e5e -- 2.39.2
[PATCH] ae350: Update defconfig list
Update the list of defconfigs, this was missed with the last pull request of the u-boot-riscv tree. Signed-off-by: Tom Rini --- board/AndesTech/ae350/MAINTAINERS | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/board/AndesTech/ae350/MAINTAINERS b/board/AndesTech/ae350/MAINTAINERS index ead8e0e2afb6..a6bc90baf883 100644 --- a/board/AndesTech/ae350/MAINTAINERS +++ b/board/AndesTech/ae350/MAINTAINERS @@ -4,10 +4,14 @@ S:Maintained F: board/AndesTech/ae350/ F: include/configs/ae350.h F: configs/ae350_rv32_defconfig -F: configs/ae350_rv64_defconfig -F: configs/ae350_rv32_xip_defconfig -F: configs/ae350_rv64_xip_defconfig +F: configs/ae350_rv32_falcon_defconfig +F: configs/ae350_rv32_falcon_xip_defconfig F: configs/ae350_rv32_spl_defconfig -F: configs/ae350_rv64_spl_defconfig F: configs/ae350_rv32_spl_xip_defconfig +F: configs/ae350_rv32_xip_defconfig +F: configs/ae350_rv64_defconfig +F: configs/ae350_rv64_falcon_defconfig +F: configs/ae350_rv64_falcon_xip_defconfig +F: configs/ae350_rv64_spl_defconfig F: configs/ae350_rv64_spl_xip_defconfig +F: configs/ae350_rv64_xip_defconfig -- 2.34.1
