Re: [PATCH 014/149] board: alliedtelesis: Remove and add needed includes
On 1/05/24 14:41, Tom Rini wrote: > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Chris Packham Reviewed-by: Chris Packham > --- > board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c | 1 - > board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c | 1 - > board/alliedtelesis/common/gpio_hog.c | 1 - > board/alliedtelesis/x240/x240.c | 2 +- > board/alliedtelesis/x530/x530.c | 2 +- > 5 files changed, 2 insertions(+), 5 deletions(-) > > diff --git a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c > b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c > index e0a7f3fa89f0..5e6d6c6234fb 100644 > --- a/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c > +++ b/board/alliedtelesis/SBx81LIFKW/sbx81lifkw.c > @@ -4,7 +4,6 @@ >* Allied Telesis > <http://scanmail.trustwave.com/?c=20988=2ayx5kNiqyP-Zhu-6cGRswhIuvU8IKOw7TN5W7swfg=http%3a%2f%2fwww%2ealliedtelesis%2ecom> >*/ > > -#include > #include > #include > #include > diff --git a/board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c > b/board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c > index 52b8eba92fc1..f30821c17963 100644 > --- a/board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c > +++ b/board/alliedtelesis/SBx81LIFXCAT/sbx81lifxcat.c > @@ -4,7 +4,6 @@ >* Allied Telesis > <http://scanmail.trustwave.com/?c=20988=2ayx5kNiqyP-Zhu-6cGRswhIuvU8IKOw7TN5W7swfg=http%3a%2f%2fwww%2ealliedtelesis%2ecom> >*/ > > -#include > #include > #include > #include > diff --git a/board/alliedtelesis/common/gpio_hog.c > b/board/alliedtelesis/common/gpio_hog.c > index 4aecf7e2cef7..7da70fb4f7d6 100644 > --- a/board/alliedtelesis/common/gpio_hog.c > +++ b/board/alliedtelesis/common/gpio_hog.c > @@ -3,7 +3,6 @@ >* Copyright (C) 2018 Allied Telesis Labs >*/ > > -#include > #include > #include > #include > diff --git a/board/alliedtelesis/x240/x240.c b/board/alliedtelesis/x240/x240.c > index 0c4f8e03b859..c1b7cc3b613c 100644 > --- a/board/alliedtelesis/x240/x240.c > +++ b/board/alliedtelesis/x240/x240.c > @@ -1,6 +1,6 @@ > // SPDX-License-Identifier: GPL-2.0+ > > -#include > +#include > #include > > DECLARE_GLOBAL_DATA_PTR; > diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c > index 80ad62c2c665..65e6d48db0a6 100644 > --- a/board/alliedtelesis/x530/x530.c > +++ b/board/alliedtelesis/x530/x530.c > @@ -3,7 +3,7 @@ >* Copyright (C) 2017 Allied Telesis Labs >*/ > > -#include > +#include > #include > #include > #include
Re: [PATCH 010/149] board: Marvell: Remove and add needed includes
On 1/05/24 14:40, Tom Rini wrote: > Remove from this board vendor directory and when needed > add missing include files directly. > > Signed-off-by: Tom Rini > --- > Cc: Stefan Roese > Cc: Chris Packham > Cc: Tony Dinh > Cc: Jason Cooper > Cc: Siddarth Gore > Cc: Aaron Williams Reviewed-by: Chris Packham > --- > arch/arm/mach-kirkwood/include/mach/mpp.h | 2 ++ > board/Marvell/db-88f6720/db-88f6720.c | 1 - > board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 2 +- > board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 2 +- > board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c | 1 - > board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c | 1 - > board/Marvell/dreamplug/dreamplug.c | 1 - > board/Marvell/guruplug/guruplug.c | 1 - > board/Marvell/mvebu_alleycat-5/board.c| 2 +- > board/Marvell/mvebu_armada-37xx/board.c | 2 +- > board/Marvell/mvebu_armada-8k/board.c | 2 +- > board/Marvell/octeontx2/soc-utils.c | 1 - > board/Marvell/openrd/openrd.c | 1 - > board/Marvell/sheevaplug/sheevaplug.c | 1 - > 14 files changed, 7 insertions(+), 13 deletions(-) > > diff --git a/arch/arm/mach-kirkwood/include/mach/mpp.h > b/arch/arm/mach-kirkwood/include/mach/mpp.h > index 4d1f58c0cbdf..e2757942590b 100644 > --- a/arch/arm/mach-kirkwood/include/mach/mpp.h > +++ b/arch/arm/mach-kirkwood/include/mach/mpp.h > @@ -8,6 +8,8 @@ > #ifndef __KIRKWOOD_MPP_H > #define __KIRKWOOD_MPP_H > > +#include > + > #define MPP(_num, _sel, _in, _out, _F6180, _F6190, _F6192, _F6281) ( \ > /* MPP number */((_num) & 0xff) | \ > /* MPP select value */ (((_sel) & 0xf) << 8) | \ > diff --git a/board/Marvell/db-88f6720/db-88f6720.c > b/board/Marvell/db-88f6720/db-88f6720.c > index 26c30647fbb0..920421366f11 100644 > --- a/board/Marvell/db-88f6720/db-88f6720.c > +++ b/board/Marvell/db-88f6720/db-88f6720.c > @@ -3,7 +3,6 @@ >* Copyright (C) 2016 Stefan Roese >*/ > > -#include > #include > #include > #include > diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > index 122c63d11f99..0f92cc385bc8 100644 > --- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > +++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c > @@ -3,7 +3,7 @@ >* Copyright (C) 2015 Stefan Roese >*/ > > -#include > +#include > #include > #include > #include > diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > index 1edc1cb6515c..8f8b2720107a 100644 > --- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > +++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c > @@ -3,7 +3,7 @@ >* Copyright (C) 2015 Stefan Roese >*/ > > -#include > +#include > #include > #include > #include > diff --git a/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > b/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > index 9e1fdecfca4d..6bca1f91a0a4 100644 > --- a/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > +++ b/board/Marvell/db-mv784mp-gp/db-mv784mp-gp.c > @@ -3,7 +3,6 @@ >* Copyright (C) 2014 Stefan Roese >*/ > > -#include > #include > #include > #include > diff --git a/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > b/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > index 0abdca1cd210..a7a84798a53b 100644 > --- a/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > +++ b/board/Marvell/db-xc3-24g4xg/db-xc3-24g4xg.c > @@ -3,7 +3,6 @@ >* Copyright (C) 2015 Stefan Roese >*/ > > -#include > #include > #include > #include > diff --git a/board/Marvell/dreamplug/dreamplug.c > b/board/Marvell/dreamplug/dreamplug.c > index d15faa1cb7ff..381275061318 100644 > --- a/board/Marvell/dreamplug/dreamplug.c > +++ b/board/Marvell/dreamplug/dreamplug.c > @@ -8,7 +8,6 @@ >* Written-by: Siddarth Gore >*/ > > -#include > #include > #include > #include > diff --git a/board/Marvell/guruplug/guruplug.c > b/board/Marvell/guruplug/guruplug.c > index ea87ded222e6..7c3cea22b936 100644 > --- a/board/Marvell/guruplug/guruplug.c > +++ b/board/Marvell/guruplug/guruplug.c > @@ -5,7 +5,6 @@ >* Written-by: Siddarth Gore >*/ > > -#include > #include > #include > #include > diff --git a/board/Marvell/mvebu_alleycat-5/board.c > b/board/Marvell/mvebu_alleycat-5/board.c > index 0c4f8e03b859..c1b7cc3b613c 100644 > --- a/board/Marvell/mvebu_alleycat-5/board.c > +++ b/board/Marvell/mvebu_alleycat-5/board.c > @@ -1,6 +1,6 @@ >
Re: [PATCH] mtd: nand: pxa3xx: Incorrect bitflip return on page read
On Sun, Apr 28, 2024 at 4:15 AM Ravi Minnikanti wrote:
>
> Once a page is read with higher bitflips all subsequent reads
> are returning the same bitflip value even though they have none.
> max_bitflip variable is not being reset to 0 across page reads.
>
> This is causing problems like incorrectly
> marking erase blocks bad by UBI and causing read failures.
>
> Verified the change with both MTD reads and UBI.
> This change is inline with other NFC drivers.
>
> Sample error log where a block is marked bad incorrectly:
>
> ubi0: fixable bit-flip detected at PEB 125
> ubi0: run torture test for PEB 125
> ubi0: fixable bit-flip detected at PEB 125
> ubi0 error: torture_peb: read problems on freshly erased PEB 125,
> must be bad
> ubi0 error: erase_worker: failed to erase PEB 125, error -5
> ubi0: mark PEB 125 as bad
>
> Signed-off-by: rminnikanti
Looks good to me
Reviewed-by: Chris Packham
> ---
> drivers/mtd/nand/raw/pxa3xx_nand.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index 1d9a6d107b..d2a4faad56 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -800,6 +800,11 @@ static void prepare_start_command(struct
> pxa3xx_nand_info *info, int command)
> info->ecc_err_cnt = 0;
> info->ndcb3 = 0;
> info->need_wait = 0;
> + /*
> +* Reset max_bitflips to zero. Once command is complete,
> +* max_bitflips for this READ is returned in ecc.read_page()
> +*/
> + info->max_bitflips = 0;
>
> switch (command) {
> case NAND_CMD_READ0:
> --
> 2.17.1
Re: [PATCH 0/3] Revert HAFDBS changes
On Fri, 10 Nov 2023, 10:33 am Tom Rini, wrote: > On Fri, Oct 27, 2023 at 01:22:37PM -0400, Tom Rini wrote: > > On Fri, Oct 27, 2023 at 10:49:47AM +0100, Pierre-Clément Tosi wrote: > > > Hi Chris, > > > > > > On Fri, Oct 27, 2023 at 01:23:51PM +1300, Chris Packham wrote: > > > > As discussed this series reverts the HAFDBS changes that caused an > issue > > > > on AC5/AC5X. I think there are some improvements that can be made to > the > > > > initial memory map for the AC5/AC5X but so far nothing I've found > makes > > > > it compatible with the HAFDBS changes. > > > > > > Would you mind briefly explaining what those issues are and/or point > me to the > > > discussion where it was decided to revert these patches? > > > > > > The feature is quite useful for users of CONFIG_CMO_BY_VA_ONLY, to > speed up the > > > boot sequence: instead of reverting these patches altogether, would a > reasonable > > > alternative be to put them behind a build option? > > > > > > Also, could you confirm that the "initial memory map" you are > referring to above > > > only describes actual memory as, IIRC, some boards were using mappings > **much** > > > larger than their DRAM address space? > > > > The most details are in this thread: > > > https://lore.kernel.org/u-boot/CAFOYHZC_Dveax85n0fLr5BFyZcLqsvUssn=j0ohyvn75bta...@mail.gmail.com/ > > with some follow-up in: > > > https://lore.kernel.org/u-boot/CAFOYHZB7jJWwD24oWzx6u55w2whHYjK56f=qyn0lwu4z8ds...@mail.gmail.com/ > > Checking to see if you have any feedback for these platforms? I would > like to have them working again one way or another in v2024.01, thanks. > Either this series or https://lore.kernel.org/u-boot/20231018205358.1557234-1-judge.pack...@gmail.com/ will get the AC5X boards back working. I'm out of other ideas but happy to test patches. >
Re: [PATCH] arm: mvebu: AC5: Use finer grained memory map
Hi Tom, On Fri, 27 Oct 2023, 1:54 pm Tom Rini, wrote: > On Fri, Oct 27, 2023 at 01:44:11PM +1300, Chris Packham wrote: > > > The ATF implementation for AC5/AC5X ends up with bl31 living in some > > internal SRAM. This is in the middle of the large MMIO region that we > > were using. Adjust this to be finer grained blocks based on the address > > map from the AC5X Family Control and Management Subsystem Functional > > Datasheet. > > > > Signed-off-by: Chris Packham > > Does this mean we don't need to revert that other patch, or is this > unrelated? Thanks. > Unrelated. Just something I found along the way. I had hope it would fix the hang but with or without this change the HAFDBS support causes issues for me. >
[PATCH] arm: mvebu: AC5: Use finer grained memory map
The ATF implementation for AC5/AC5X ends up with bl31 living in some
internal SRAM. This is in the middle of the large MMIO region that we
were using. Adjust this to be finer grained blocks based on the address
map from the AC5X Family Control and Management Subsystem Functional
Datasheet.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 66 ++---
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..0f72ae1709be 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -16,7 +16,10 @@
DECLARE_GLOBAL_DATA_PTR;
-#define RAM_SIZE SZ_1G
+#define AC5_PTE_BLOCK_DEVICE \
+ (PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | \
+PTE_BLOCK_NON_SHARE | \
+PTE_BLOCK_PXN | PTE_BLOCK_UXN)
static struct mm_region ac5_mem_map[] = {
{
@@ -31,30 +34,63 @@ static struct mm_region ac5_mem_map[] = {
.phys = 0x,
.virt = 0xa000,
.size = 0x10,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
/* MMIO regions */
.phys = 0x10,
.virt = 0x10,
.size = 0x3ff0,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
- /* MMIO regions */
.phys = 0x7F00,
.virt = 0x7F00,
- .size = 0x2100,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .size = SZ_8M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7F80,
+ .virt = 0x7F80,
+ .size = SZ_4M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC0,
+ .virt = 0x7FC0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC8,
+ .virt = 0x7FC8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FD0,
+ .virt = 0x7FD0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ /* ATF region 0x7FE0-0x7FE2 not mapped */
+ {
+ .phys = 0x7FE8,
+ .virt = 0x7FE8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FFF,
+ .virt = 0x7FFF,
+ .size = SZ_1M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x8000,
+ .virt = 0x8000,
+ .size = SZ_2G,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
0,
--
2.42.0
[PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c | 16 +---
arch/arm/include/asm/armv8/mmu.h | 14 --
arch/arm/include/asm/global_data.h | 1 -
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 4760064ee18f..697334086fdc 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -93,8 +93,6 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
if (el == 1) {
tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
- if (gd->arch.has_hafdbs)
- tcr |= TCR_HA | TCR_HD;
} else if (el == 2) {
tcr = TCR_EL2_RSVD | (ips << 16);
} else {
@@ -202,9 +200,6 @@ static void __cmo_on_leaves(void (*cmo_fn)(unsigned long,
unsigned long),
attrs != PTE_BLOCK_MEMTYPE(MT_NORMAL_NC))
continue;
- if (gd->arch.has_hafdbs && (pte & (PTE_RDONLY | PTE_DBM)) !=
PTE_DBM)
- continue;
-
end = va + BIT(level2shift(level)) - 1;
/* No intersection with RAM? */
@@ -353,9 +348,6 @@ static void add_map(struct mm_region *map)
if (va_bits < 39)
level = 1;
- if (gd->arch.has_hafdbs)
- attrs |= PTE_DBM | PTE_RDONLY;
-
map_range(map->virt, map->phys, map->size, level,
(u64 *)gd->arch.tlb_addr, attrs);
}
@@ -407,13 +399,7 @@ static int count_ranges(void)
__weak u64 get_page_table_size(void)
{
u64 one_pt = MAX_PTE_ENTRIES * sizeof(u64);
- u64 size, mmfr1;
-
- asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
- if ((mmfr1 & 0xf) == 2)
- gd->arch.has_hafdbs = true;
- else
- gd->arch.has_hafdbs = false;
+ u64 size;
/* Account for all page tables we would need to cover our memory map */
size = one_pt * count_ranges();
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 98a27db3166b..9f58cedb650c 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -49,13 +49,10 @@
#define PTE_TYPE_BLOCK (1 << 0)
#define PTE_TYPE_VALID (1 << 0)
-#define PTE_RDONLY BIT(7)
-#define PTE_DBMBIT(51)
-
-#define PTE_TABLE_PXN BIT(59)
-#define PTE_TABLE_XN BIT(60)
-#define PTE_TABLE_AP BIT(61)
-#define PTE_TABLE_NS BIT(63)
+#define PTE_TABLE_PXN (1UL << 59)
+#define PTE_TABLE_XN (1UL << 60)
+#define PTE_TABLE_AP (1UL << 61)
+#define PTE_TABLE_NS (1UL << 63)
/*
* Block
@@ -102,9 +99,6 @@
#define TCR_TG0_16K(2 << 14)
#define TCR_EPD1_DISABLE (1 << 23)
-#define TCR_HA BIT(39)
-#define TCR_HD BIT(40)
-
#define TCR_EL1_RSVD (1U << 31)
#define TCR_EL2_RSVD (1U << 31 | 1 << 23)
#define TCR_EL3_RSVD (1U << 31 | 1 << 23)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 1325b0644248..75bd9d56f893 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -52,7 +52,6 @@ struct arch_global_data {
#if defined(CONFIG_ARM64)
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
- bool has_hafdbs;
#endif
#endif
#ifdef CFG_SYS_MEM_RESERVE_SECURE
--
2.42.0
[PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c | 14 --
arch/arm/include/asm/global_data.h | 1 -
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 4c6a1b1d6c5e..4760064ee18f 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -314,7 +314,7 @@ static void map_range(u64 virt, u64 phys, u64 size, int
level,
for (i = idx; size; i++) {
u64 next_size, *next_table;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
if (level == 3)
table[i] = phys | attrs | PTE_TYPE_PAGE;
@@ -353,9 +353,6 @@ static void add_map(struct mm_region *map)
if (va_bits < 39)
level = 1;
- if (!gd->arch.first_block_level)
- gd->arch.first_block_level = 1;
-
if (gd->arch.has_hafdbs)
attrs |= PTE_DBM | PTE_RDONLY;
@@ -372,7 +369,7 @@ static void count_range(u64 virt, u64 size, int level, int
*cntp)
for (i = idx; size; i++) {
u64 next_size;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
virt += map_size;
size -= map_size;
@@ -413,13 +410,10 @@ __weak u64 get_page_table_size(void)
u64 size, mmfr1;
asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
- if ((mmfr1 & 0xf) == 2) {
+ if ((mmfr1 & 0xf) == 2)
gd->arch.has_hafdbs = true;
- gd->arch.first_block_level = 2;
- } else {
+ else
gd->arch.has_hafdbs = false;
- gd->arch.first_block_level = 1;
- }
/* Account for all page tables we would need to cover our memory map */
size = one_pt * count_ranges();
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index b385bae02669..1325b0644248 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -52,7 +52,6 @@ struct arch_global_data {
#if defined(CONFIG_ARM64)
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
- unsigned int first_block_level;
bool has_hafdbs;
#endif
#endif
--
2.42.0
[PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c| 6 +-
arch/arm/include/asm/armv8/mmu.h | 10 ++
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cb1131a0480e..4c6a1b1d6c5e 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -94,15 +94,11 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
if (el == 1) {
tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
if (gd->arch.has_hafdbs)
- tcr |= TCR_EL1_HA | TCR_EL1_HD;
+ tcr |= TCR_HA | TCR_HD;
} else if (el == 2) {
tcr = TCR_EL2_RSVD | (ips << 16);
- if (gd->arch.has_hafdbs)
- tcr |= TCR_EL2_HA | TCR_EL2_HD;
} else {
tcr = TCR_EL3_RSVD | (ips << 16);
- if (gd->arch.has_hafdbs)
- tcr |= TCR_EL3_HA | TCR_EL3_HD;
}
/* PTWs cacheable, inner/outer WBWA and inner shareable */
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 19a9e112a434..98a27db3166b 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -102,14 +102,8 @@
#define TCR_TG0_16K(2 << 14)
#define TCR_EPD1_DISABLE (1 << 23)
-#define TCR_EL1_HA BIT(39)
-#define TCR_EL1_HD BIT(40)
-
-#define TCR_EL2_HA BIT(21)
-#define TCR_EL2_HD BIT(22)
-
-#define TCR_EL3_HA BIT(21)
-#define TCR_EL3_HD BIT(22)
+#define TCR_HA BIT(39)
+#define TCR_HD BIT(40)
#define TCR_EL1_RSVD (1U << 31)
#define TCR_EL2_RSVD (1U << 31 | 1 << 23)
--
2.42.0
[PATCH 0/3] Revert HAFDBS changes
As discussed this series reverts the HAFDBS changes that caused an issue on AC5/AC5X. I think there are some improvements that can be made to the initial memory map for the AC5/AC5X but so far nothing I've found makes it compatible with the HAFDBS changes. Chris Packham (3): Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present" Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present" Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available" arch/arm/cpu/armv8/cache_v8.c | 30 +++--- arch/arm/include/asm/armv8/mmu.h | 20 arch/arm/include/asm/global_data.h | 2 -- 3 files changed, 7 insertions(+), 45 deletions(-) -- 2.42.0
Re: [PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
On Sat, 21 Oct 2023, 2:04 am Marc Zyngier, wrote:
> On 2023-10-18 21:53, Chris Packham wrote:
> > Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
> > when available") the default get_page_table_size() sets some flags for
> > more efficient handling of dirty page table entries. This causes
> > problems on the AC5/AC5X SoC (specifically a lockup when calling
> > __asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
> >
> > The reason for the lockup isn't at all clear but it can be avoided if
> > we
> > provide our own get_page_table_size() which stops gd->arch.has_hafdbs
> > from being set to true effectively returning the AC5/AC5X to the older
> > behaviour. This also opts for a simple fixed page table size rather
> > than
> > trying to duplicate the more complicated logic to optimise the table
> > size.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > index 8204d9627515..7ba57ae75e76 100644
> > --- a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > +++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > @@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
> >
> > struct mm_region *mem_map = ac5_mem_map;
> >
> > +u64 get_page_table_size(void)
> > +{
> > + return 0x8;
> > +}
> > +
> > void reset_cpu(void)
> > {
> > }
>
> This looks terribly wrong. In all honesty, if the original
> patch creates problems and that people add this sort of stuff
> to paper over it, I'd rather your *revert* my patch altogether.
>
There are other platforms that define a get_page_table_size(). That may
mean that they are just inadvertently avoiding the issues I'm seeing.
I'm happy to prepare a series reverting the problematic changes. But I'm
sure that there's something about the AC5 that's the actual problem. I'm
just out of my depth in terms of my ability to progress it.
> M.
> --
> Jazz is not dead. It just smells funny...
>
Re: [PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
On Fri, 20 Oct 2023, 7:18 pm Stefan Roese, wrote:
> Hi Chris,
>
> On 10/18/23 22:53, Chris Packham wrote:
> > Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
> > when available") the default get_page_table_size() sets some flags for
> > more efficient handling of dirty page table entries. This causes
> > problems on the AC5/AC5X SoC (specifically a lockup when calling
> > __asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
> >
> > The reason for the lockup isn't at all clear but it can be avoided if we
> > provide our own get_page_table_size() which stops gd->arch.has_hafdbs
> > from being set to true effectively returning the AC5/AC5X to the older
> > behaviour. This also opts for a simple fixed page table size rather than
> > trying to duplicate the more complicated logic to optimise the table
> > size.
> >
> > Signed-off-by: Chris Packham
>
> I'm not 100% happy with this approach / workaround - still it fixes an
> issue on your board, so:
>
> Reviewed-by: Stefan Roese
>
Yeah I'm not super happy about this either. But this is about the best I
could come up with.
> Perhaps you (or someone else) can look into this in more depth to get
> to the root of this issue at a later time.
>
I did spend a reasonable amount of time tracking down where things were
going wrong, even if I couldn't figure out why. The commit message
basically reflects what I found.
> Thanks,
> Stefan
>
> > ---
> >
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
> b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > index 8204d9627515..7ba57ae75e76 100644
> > --- a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > +++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > @@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
> >
> > struct mm_region *mem_map = ac5_mem_map;
> >
> > +u64 get_page_table_size(void)
> > +{
> > + return 0x8;
> > +}
> > +
> > void reset_cpu(void)
> > {
> > }
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
>
[PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
when available") the default get_page_table_size() sets some flags for
more efficient handling of dirty page table entries. This causes
problems on the AC5/AC5X SoC (specifically a lockup when calling
__asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
The reason for the lockup isn't at all clear but it can be avoided if we
provide our own get_page_table_size() which stops gd->arch.has_hafdbs
from being set to true effectively returning the AC5/AC5X to the older
behaviour. This also opts for a simple fixed page table size rather than
trying to duplicate the more complicated logic to optimise the table
size.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..7ba57ae75e76 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
struct mm_region *mem_map = ac5_mem_map;
+u64 get_page_table_size(void)
+{
+ return 0x8;
+}
+
void reset_cpu(void)
{
}
--
2.42.0
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Tue, Oct 17, 2023 at 12:21 AM Marc Zyngier wrote: > > On Mon, 16 Oct 2023 02:42:08 +0100, > Chris Packham wrote: > > > > On Sun, Oct 15, 2023 at 10:29 AM Chris Packham > > wrote: > > > > > > > > > > > > On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: > > >> > > >> On 2023-10-13 03:40, Chris Packham wrote: > > >> > Hi Marc, Paul, > > >> > > > >> > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) > > >> > wrote: > > >> >> > > >> >> From: Marc Zyngier > > >> >> > > >> >> Some recent arm64 cores have a facility that allows the page > > >> >> table walker to track the dirty state of a page. This makes it > > >> >> really efficient to perform CMOs by VA as we only need to look > > >> >> at dirty pages. > > >> >> > > >> >> Signed-off-by: Marc Zyngier > > >> >> [ Paul: pick from the Android tree. Rebase to the upstream ] > > >> >> Signed-off-by: Ying-Chun Liu (PaulLiu) > > >> >> Cc: Tom Rini > > >> >> Link: > > >> >> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 > > >> > > > >> > I think this may have caused a regression for the Marvell AC5X > > >> > board(s). I found that v2023.07 locked up at boot but v2023.01 was > > >> > fine. The lockup seemed to be in the 'Net:' init probably just as the > > >> > mvneta driver was being initialised. > > >> > > > >> > A git bisect led me to this change although for this specific change > > >> > instead of the lockup I get a crash so maybe I'm actually hitting a > > >> > different issue. > > >> > > > >> > Any thoughts as to why this may have caused problems? > > >> > > >> Not really. What CPUs does this platform have? What is the offending > > >> driver doing to trigger the issue? Can you provide some level of > > >> tracing? > > > > > > > > > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU > > > (8.1 specifically I think). > > > > > > I think there is something that the mvneta driver is doing triggering the > > > issue. I have another AC5X based board without an Ethernet port that > > > boots just fine (this is also why I didn't notice earlier). > > > > > > I'll try and get some more debug out when I'm back in the office > > > > > > > The thing the mvneta driver does that upsets things appears to be > > > > mmu_set_region_dcache_behaviour((phys_addr_t)bd_space, BD_SPACE, > > DCACHE_OFF); > > > > I can comment that line out and everything works. > > This leads to two questions: > > - is the device cache coherent, in which case it doesn't need the > memory being non-cacheable? If everything is OK, then why the switch > to device memory? I'll be honest and say I understand less than 50% of that. The network transfer does seem to work without the call so perhaps the device is cache coherent but this seems to be a common thing in many drivers so I'd assume that on such platforms this should be innocuous. It's totally possible I haven't done a good job of setting up the CPU or informing the rest of the system about it. I did just take a lot of the code from the Marvell SDK and clean it up without really understanding what most of it did. > > - what goes wrong when these attributes are applied? do we have to > split a block mapping? > > Instrumenting the MMU code would certainly help understanding what > goes wrong here. I did do that a little bit. At first I thought there was a possible infinite loop in mmu_set_region_dcache_behaviour(). Squinting at things you could naively say that if set_one_region() failed to find an entry then it would loop forever but if that happened I'd have some debug saying that it failed. Things seem to go south after __asm_switch_ttbr(gd->arch.tlb_emerg) which did get me thinking that perhaps the emergency tables aren't setup (or at least aren't set up in a way that allows debug output). That's about as far as I got debugging wise, I'll try and spend some more time digging into the MMU code. > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Sun, Oct 15, 2023 at 10:29 AM Chris Packham wrote: > > > > On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: >> >> On 2023-10-13 03:40, Chris Packham wrote: >> > Hi Marc, Paul, >> > >> > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) >> > wrote: >> >> >> >> From: Marc Zyngier >> >> >> >> Some recent arm64 cores have a facility that allows the page >> >> table walker to track the dirty state of a page. This makes it >> >> really efficient to perform CMOs by VA as we only need to look >> >> at dirty pages. >> >> >> >> Signed-off-by: Marc Zyngier >> >> [ Paul: pick from the Android tree. Rebase to the upstream ] >> >> Signed-off-by: Ying-Chun Liu (PaulLiu) >> >> Cc: Tom Rini >> >> Link: >> >> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 >> > >> > I think this may have caused a regression for the Marvell AC5X >> > board(s). I found that v2023.07 locked up at boot but v2023.01 was >> > fine. The lockup seemed to be in the 'Net:' init probably just as the >> > mvneta driver was being initialised. >> > >> > A git bisect led me to this change although for this specific change >> > instead of the lockup I get a crash so maybe I'm actually hitting a >> > different issue. >> > >> > Any thoughts as to why this may have caused problems? >> >> Not really. What CPUs does this platform have? What is the offending >> driver doing to trigger the issue? Can you provide some level of >> tracing? > > > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU (8.1 > specifically I think). > > I think there is something that the mvneta driver is doing triggering the > issue. I have another AC5X based board without an Ethernet port that boots > just fine (this is also why I didn't notice earlier). > > I'll try and get some more debug out when I'm back in the office > The thing the mvneta driver does that upsets things appears to be mmu_set_region_dcache_behaviour((phys_addr_t)bd_space, BD_SPACE, DCACHE_OFF); I can comment that line out and everything works.
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: > On 2023-10-13 03:40, Chris Packham wrote: > > Hi Marc, Paul, > > > > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) > > wrote: > >> > >> From: Marc Zyngier > >> > >> Some recent arm64 cores have a facility that allows the page > >> table walker to track the dirty state of a page. This makes it > >> really efficient to perform CMOs by VA as we only need to look > >> at dirty pages. > >> > >> Signed-off-by: Marc Zyngier > >> [ Paul: pick from the Android tree. Rebase to the upstream ] > >> Signed-off-by: Ying-Chun Liu (PaulLiu) > >> Cc: Tom Rini > >> Link: > >> > https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 > > > > I think this may have caused a regression for the Marvell AC5X > > board(s). I found that v2023.07 locked up at boot but v2023.01 was > > fine. The lockup seemed to be in the 'Net:' init probably just as the > > mvneta driver was being initialised. > > > > A git bisect led me to this change although for this specific change > > instead of the lockup I get a crash so maybe I'm actually hitting a > > different issue. > > > > Any thoughts as to why this may have caused problems? > > Not really. What CPUs does this platform have? What is the offending > driver doing to trigger the issue? Can you provide some level of > tracing? > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU (8.1 specifically I think). I think there is something that the mvneta driver is doing triggering the issue. I have another AC5X based board without an Ethernet port that boots just fine (this is also why I didn't notice earlier). I'll try and get some more debug out when I'm back in the office > M. > -- > Jazz is not dead. It just smells funny... >
[PATCH] arm: mvebu: AC5/AC5X: Disable SMBIOS
The RD-AC5X doesn't make use of EFI or SMBIOS. Recently we started seeing boot failures such as WARNING: SMBIOS table_address overflow 27f60f020 Failed to write SMBIOS table initcall failed at event 10/(unknown) (err=-22) ### ERROR ### Please RESET the board ### The error is because the physical address of the RAM on the AC5X SoC is above the 32GiB boundary. As we don't need SMBIOS or EFI this can be safely disabled. Signed-off-by: Chris Packham --- This probably should have been part of the series I sent as https://lore.kernel.org/u-boot/20231003035800.2626121-1-judge.pack...@gmail.com/ but I didn't have the RD-AC5X board at the time. There is another issue that's stopping the RD-AC5X board from booting with current master but with the suspect commit reverted you can see the same SMBIOS issue I was seeing on the x240. configs/mvebu_ac5_rd_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mvebu_ac5_rd_defconfig b/configs/mvebu_ac5_rd_defconfig index dbf1e3136cdf..e8fa22b648be 100644 --- a/configs/mvebu_ac5_rd_defconfig +++ b/configs/mvebu_ac5_rd_defconfig @@ -85,3 +85,4 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +# CONFIG_SMBIOS is not set -- 2.42.0
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
Hi Marc, Paul,
On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu)
wrote:
>
> From: Marc Zyngier
>
> Some recent arm64 cores have a facility that allows the page
> table walker to track the dirty state of a page. This makes it
> really efficient to perform CMOs by VA as we only need to look
> at dirty pages.
>
> Signed-off-by: Marc Zyngier
> [ Paul: pick from the Android tree. Rebase to the upstream ]
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Cc: Tom Rini
> Link:
> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263
I think this may have caused a regression for the Marvell AC5X
board(s). I found that v2023.07 locked up at boot but v2023.01 was
fine. The lockup seemed to be in the 'Net:' init probably just as the
mvneta driver was being initialised.
A git bisect led me to this change although for this specific change
instead of the lockup I get a crash so maybe I'm actually hitting a
different issue.
Any thoughts as to why this may have caused problems?
> ---
> arch/arm/cpu/armv8/cache_v8.c | 16 +++-
> arch/arm/include/asm/armv8/mmu.h | 14 ++
> arch/arm/include/asm/global_data.h | 1 +
> 3 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 697334086f..4760064ee1 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -93,6 +93,8 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
>
> if (el == 1) {
> tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
> + if (gd->arch.has_hafdbs)
> + tcr |= TCR_HA | TCR_HD;
> } else if (el == 2) {
> tcr = TCR_EL2_RSVD | (ips << 16);
> } else {
> @@ -200,6 +202,9 @@ static void __cmo_on_leaves(void (*cmo_fn)(unsigned long,
> unsigned long),
> attrs != PTE_BLOCK_MEMTYPE(MT_NORMAL_NC))
> continue;
>
> + if (gd->arch.has_hafdbs && (pte & (PTE_RDONLY | PTE_DBM)) !=
> PTE_DBM)
> + continue;
> +
> end = va + BIT(level2shift(level)) - 1;
>
> /* No intersection with RAM? */
> @@ -348,6 +353,9 @@ static void add_map(struct mm_region *map)
> if (va_bits < 39)
> level = 1;
>
> + if (gd->arch.has_hafdbs)
> + attrs |= PTE_DBM | PTE_RDONLY;
> +
> map_range(map->virt, map->phys, map->size, level,
> (u64 *)gd->arch.tlb_addr, attrs);
> }
> @@ -399,7 +407,13 @@ static int count_ranges(void)
> __weak u64 get_page_table_size(void)
> {
> u64 one_pt = MAX_PTE_ENTRIES * sizeof(u64);
> - u64 size;
> + u64 size, mmfr1;
> +
> + asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
> + if ((mmfr1 & 0xf) == 2)
> + gd->arch.has_hafdbs = true;
> + else
> + gd->arch.has_hafdbs = false;
>
> /* Account for all page tables we would need to cover our memory map
> */
> size = one_pt * count_ranges();
> diff --git a/arch/arm/include/asm/armv8/mmu.h
> b/arch/arm/include/asm/armv8/mmu.h
> index 9f58cedb65..98a27db316 100644
> --- a/arch/arm/include/asm/armv8/mmu.h
> +++ b/arch/arm/include/asm/armv8/mmu.h
> @@ -49,10 +49,13 @@
> #define PTE_TYPE_BLOCK (1 << 0)
> #define PTE_TYPE_VALID (1 << 0)
>
> -#define PTE_TABLE_PXN (1UL << 59)
> -#define PTE_TABLE_XN (1UL << 60)
> -#define PTE_TABLE_AP (1UL << 61)
> -#define PTE_TABLE_NS (1UL << 63)
> +#define PTE_RDONLY BIT(7)
> +#define PTE_DBMBIT(51)
> +
> +#define PTE_TABLE_PXN BIT(59)
> +#define PTE_TABLE_XN BIT(60)
> +#define PTE_TABLE_AP BIT(61)
> +#define PTE_TABLE_NS BIT(63)
>
> /*
> * Block
> @@ -99,6 +102,9 @@
> #define TCR_TG0_16K(2 << 14)
> #define TCR_EPD1_DISABLE (1 << 23)
>
> +#define TCR_HA BIT(39)
> +#define TCR_HD BIT(40)
> +
> #define TCR_EL1_RSVD (1U << 31)
> #define TCR_EL2_RSVD (1U << 31 | 1 << 23)
> #define TCR_EL3_RSVD (1U << 31 | 1 << 23)
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h
> index 9e746e380a..eda99b5b41 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -52,6 +52,7 @@ struct arch_global_data {
> #if defined(CONFIG_ARM64)
> unsigned long tlb_fillptr;
> unsigned long tlb_emerg;
> + bool has_hafdbs;
> #endif
> #endif
> #ifdef CFG_SYS_MEM_RESERVE_SECURE
> --
> 2.39.2
>
[PATCH 2/2] Revert "arm: mvebu: x240: Use i2c-gpio instead of built in controller"
This reverts commit 5c1c6b7306f2b4c0fd50c7cb5d757e245b93606e. The reason
for switching to i2c-gpio was due to an issue we were seeing in the
Linux kernel where the CPU would lock up on certain adverse I2C bus
conditions. We were never able to reproduce the lockup in U-Boot but
assumed that was probably just luck.
Since then we have discovered that the lock up was due to the I2C
transaction offload engine in the I2C controller not coping with the
adverse bus conditions (basically it thinks there's another master and
waits for a STOP condition that never comes). U-Boot doesn't use the I2C
offload feature so is not susceptible to the lockup.
We can therefore safely return to using the built-in I2C controller.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
configs/x240_defconfig | 1 -
2 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index c19b25925ba2..820ec18b4355 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -16,7 +16,7 @@
gpio0 =
gpio1 =
spi0 =
- i2c0 =
+ i2c0 =
usb0 =
pinctrl0 =
};
@@ -40,19 +40,6 @@
default-state = "on";
};
};
-
- i2cgpio: i2c-gpio-0 {
- compatible = "i2c-gpio";
- #address-cells = <1>;
- #size-cells = <0>;
-
- pinctrl-names = "default";
- pinctrl-0 = <_gpio>;
- scl-gpios = < 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
- sda-gpios = < 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
- i2c-gpio,delay-us = <2>;
- status = "okay";
-};
};
{
@@ -83,7 +70,9 @@
status = "okay";
};
- {
+ {
+ status = "okay";
+
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -188,8 +177,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26] (GPIO)
-* I2C0_SDA [27] (GPIO)
+* I2C0_SCL [26]
+* I2C0_SDA [27]
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -212,7 +201,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000000xff 0xff 00
+0000001100
1111000000
000111>;
@@ -220,9 +209,4 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
-
- i2c0_gpio: i2c0-gpio-pins {
- marvell,pins = <26 27>;
- marvell,function = <0>;
- };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index 0d5a19df25aa..4b1a761a9086 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -42,7 +42,6 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
-CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.42.0
[PATCH 1/2] arm: mvebu: x240: Disable SMBIOS
The x240 doesn't make use of EFI or SMBIOS. Recently we started seeing boot failures such as WARNING: SMBIOS table_address overflow 23f60c020 Failed to write SMBIOS table initcall failed at event 10/(unknown) (err=-22) ### ERROR ### Please RESET the board ### The error is because the physical address of the RAM on the AC5X SoC is above the 32GiB boundary. As we don't need SMBIOS or EFI this can be safely disabled. Signed-off-by: Chris Packham --- configs/x240_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/x240_defconfig b/configs/x240_defconfig index 7d2b8603e6f4..0d5a19df25aa 100644 --- a/configs/x240_defconfig +++ b/configs/x240_defconfig @@ -84,3 +84,4 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y # CONFIG_FAT_WRITE is not set +# CONFIG_SMBIOS is not set -- 2.42.0
[PATCH 2/2] ARM64: dts: marvell: cn9310-crb: Remove duplicate pinctrl
The cn9130.dtsi defines a pinctrl node for SPI1 (until recently it was
mislabeled as spi0). Use this instead of having a duplicate definition
with a different label.
Signed-off-by: Chris Packham
---
arch/arm/dts/cn9130-crb.dtsi | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/dts/cn9130-crb.dtsi b/arch/arm/dts/cn9130-crb.dtsi
index b229725184a9..7dd36cae282b 100644
--- a/arch/arm/dts/cn9130-crb.dtsi
+++ b/arch/arm/dts/cn9130-crb.dtsi
@@ -125,11 +125,6 @@
marvell,function = <0>;
};
- cp0_spi1_pins_crb: cp0-spi-pins-crb {
- marvell,pins = < 13 14 15 16 >;
- marvell,function = <3>;
- };
-
cp0_smi_pins_crb: cp0-smi-pins-crb {
marvell,pins = < 40 41 >;
marvell,function = <8>;
@@ -170,7 +165,7 @@
_spi1 {
pinctrl-names = "default";
- pinctrl-0 = <_spi1_pins_crb>;
+ pinctrl-0 = <_spi1_pins>;
reg = <0x700680 0x50>, /* control */
<0x200 0x100>,/* CS0 */
<0 0x>, /* CS1 */
--
2.41.0
[PATCH 1/2] ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins
The CN9130-DB uses the SPI1 interface but had the pinctrl node labelled
as "cp0_spi0_pins". Use the label "cp0_spi1_pins" and update the node
name to "cp0-spi-pins-1" to avoid confusion with the pinctrl options for
SPI0.
Signed-off-by: Chris Packham
---
arch/arm/dts/cn9130-db.dtsi | 2 +-
arch/arm/dts/cn9130.dtsi| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/cn9130-db.dtsi b/arch/arm/dts/cn9130-db.dtsi
index 1b28732ee752..4b21ff46d507 100644
--- a/arch/arm/dts/cn9130-db.dtsi
+++ b/arch/arm/dts/cn9130-db.dtsi
@@ -183,7 +183,7 @@
/* U55 */
_spi1 {
pinctrl-names = "default";
- pinctrl-0 = <_spi0_pins>;
+ pinctrl-0 = <_spi1_pins>;
reg = <0x700680 0x50>, /* control */
<0x200 0x100>,/* CS0 */
<0 0x>, /* CS1 */
diff --git a/arch/arm/dts/cn9130.dtsi b/arch/arm/dts/cn9130.dtsi
index 68b767a70639..efcb2e906b91 100644
--- a/arch/arm/dts/cn9130.dtsi
+++ b/arch/arm/dts/cn9130.dtsi
@@ -66,7 +66,7 @@
marvell,pins = < 56 57 58 59 60 61 >;
marvell,function = <14>;
};
- cp0_spi0_pins: cp0-spi-pins-0 {
+ cp0_spi1_pins: cp0-spi-pins-1 {
marvell,pins = < 13 14 15 16 >;
marvell,function = <3>;
};
--
2.41.0
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
On Mon, Jul 31, 2023 at 9:29 AM Pierre Bourdon wrote: > > On Sun, Jul 30, 2023 at 11:21 PM Chris Packham > wrote: > > On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon wrote: > > > > > > Chunked raw reads get accumulated to the data buffer, but in some > > > ECC configurations they can end up being larger than the originally > > > computed size (write page size + OOB size). For example: > > > > > > 4K page size, ECC strength 8: > > > - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes. > > > - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5 > > > ECC areas of 32B = 4320B. > > > > I'm not a NAND expert and I haven't sat down and fully grasped the > > math but I was curious to see what the Linux kernel did. It looks like > > it uses the same mtd->writesize + mtd->oobsize calculation (see > > nand_scan_tail() in nand_base.c). So either Linux has the same bug or > > maybe there's something off in u-boot's nfc_layouts[]. I'll see if I > > can get one of my boards to trigger a KASAN report (I'm not sure if > > any of the NAND chips we use will hit the cases you're pointing out). > > Sure, please let me know. I'm not 100% convinced that this is the > correct fix - I know very little about this driver or NANDs in > general. On the board I'm playing with (Marvell AC3-based) this patch > prevents the driver from corrupting dlmalloc's data structures and > causing u-boot to hang. But it could be that this is just papering > over another root cause. > > The NAND chip is a Micron MT29F4G08ABBEAH4, so nothing too unusual. At least according to the datasheet I can find MT29F4G08ABBEAH4 has a page size of 4320 bytes (4096 + 224 bytes). Perhaps the problem is actually related to the fact that somehow you've ended up with an oobsize of 128. > > Thanks! > Best, > > -- > Pierre Bourdon > Software Engineer @ Zürich, Switzerland > https://delroth.net/
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
On Mon, 31 Jul 2023, 9:29 am Pierre Bourdon, wrote: > On Sun, Jul 30, 2023 at 11:21 PM Chris Packham > wrote: > > On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon > wrote: > > > > > > Chunked raw reads get accumulated to the data buffer, but in some > > > ECC configurations they can end up being larger than the originally > > > computed size (write page size + OOB size). For example: > > > > > > 4K page size, ECC strength 8: > > > - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes. > > > - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5 > > > ECC areas of 32B = 4320B. > > > > I'm not a NAND expert and I haven't sat down and fully grasped the > > math but I was curious to see what the Linux kernel did. It looks like > > it uses the same mtd->writesize + mtd->oobsize calculation (see > > nand_scan_tail() in nand_base.c). So either Linux has the same bug or > > maybe there's something off in u-boot's nfc_layouts[]. I'll see if I > > can get one of my boards to trigger a KASAN report (I'm not sure if > > any of the NAND chips we use will hit the cases you're pointing out). > > Sure, please let me know. I'm not 100% convinced that this is the > correct fix - I know very little about this driver or NANDs in > general. On the board I'm playing with (Marvell AC3-based) this patch > prevents the driver from corrupting dlmalloc's data structures and > causing u-boot to hang. But it could be that this is just papering > over another root cause. > > The NAND chip is a Micron MT29F4G08ABBEAH4, so nothing too unusual. > Hmm. Both boards I tried had sufficient space in writesize+oobsize. I'll see if I can find others with different nand chips. > Thanks! > Best, > > -- > Pierre Bourdon > Software Engineer @ Zürich, Switzerland > https://delroth.net/ >
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
Hi Pierre,
On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon wrote:
>
> Chunked raw reads get accumulated to the data buffer, but in some
> ECC configurations they can end up being larger than the originally
> computed size (write page size + OOB size). For example:
>
> 4K page size, ECC strength 8:
> - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes.
> - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5
> ECC areas of 32B = 4320B.
I'm not a NAND expert and I haven't sat down and fully grasped the
math but I was curious to see what the Linux kernel did. It looks like
it uses the same mtd->writesize + mtd->oobsize calculation (see
nand_scan_tail() in nand_base.c). So either Linux has the same bug or
maybe there's something off in u-boot's nfc_layouts[]. I'll see if I
can get one of my boards to trigger a KASAN report (I'm not sure if
any of the NAND chips we use will hit the cases you're pointing out).
>
> Fixes: 6293b0361d9 ("mtd: nand: pxa3xx: add raw read support")
> Signed-off-by: Pierre Bourdon
> ---
>
> drivers/mtd/nand/raw/pxa3xx_nand.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index d502e967f9..2894ababbe 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -1471,6 +1471,19 @@ static void pxa3xx_nand_detect_config(struct
> pxa3xx_nand_info *info)
>
> static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
> {
> + unsigned int chunk_size;
> + unsigned int last_chunk_size;
> +
> + /*
> +* The data buffer needs to not only be large enough for normal + OOB
> +* reads, but also for raw reads. The raw reads can end up taking more
> +* space due to the chunking scheme.
> +*/
> + chunk_size = info->chunk_size + info->spare_size + info->ecc_size;
> + last_chunk_size =
> + info->last_chunk_size + info->last_spare_size +
> info->ecc_size;
> + info->buf_size = info->nfullchunks * chunk_size + last_chunk_size;
> +
> info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
> if (info->data_buff == NULL)
> return -ENOMEM;
> @@ -1661,7 +1674,6 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> kfree(info->data_buff);
>
> /* allocate the real data + oob buffer */
> - info->buf_size = mtd->writesize + mtd->oobsize;
> ret = pxa3xx_nand_init_buff(info);
> if (ret)
> return ret;
> --
> 2.41.0
>
[PATCH v2 2/2] arm: mvebu: x240: Use i2c-gpio instead of built in controller
There is an Errata with the built-in I2C controller where various I2C
hardware errors cause a complete lockup of the CPU (which eventually
results in an watchdog reset).
Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
This uses a bit-banged implementation of an I2C controller and avoids
triggering the Errata.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v2:
- Update i2c0 alias
- Move i2c-gpio definition to root of device tree
- Remove instead of just disabling it
- Add r-by from Stefan
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 --
configs/x240_defconfig | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index 820ec18b4355..c19b25925ba2 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -16,7 +16,7 @@
gpio0 =
gpio1 =
spi0 =
- i2c0 =
+ i2c0 =
usb0 =
pinctrl0 =
};
@@ -40,6 +40,19 @@
default-state = "on";
};
};
+
+ i2cgpio: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio>;
+ scl-gpios = < 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ sda-gpios = < 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ status = "okay";
+};
};
{
@@ -70,9 +83,7 @@
status = "okay";
};
- {
- status = "okay";
-
+ {
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -177,8 +188,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26]
-* I2C0_SDA [27]
+* I2C0_SCL [26] (GPIO)
+* I2C0_SDA [27] (GPIO)
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -201,7 +212,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000001100
+0000000xff 0xff 00
1111000000
000111>;
@@ -209,4 +220,9 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
+
+ i2c0_gpio: i2c0-gpio-pins {
+ marvell,pins = <26 27>;
+ marvell,function = <0>;
+ };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index a78cb3ce6cbf..7d2b8603e6f4 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -42,6 +42,7 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.41.0
[PATCH v2 1/2] i2c: i2c-gpio: Correctly handle new {sda, scl}-gpios bindings
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham
---
This was originally sent as a single patch[1]. I've rolled it into this
series as the board change is dependent on it.
[1] -
https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
(no changes since v1)
drivers/i2c/i2c-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4ed9e9e7cddd..c1fc290bd253 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -339,7 +339,7 @@ static int i2c_gpio_of_to_plat(struct udevice *dev)
/* "gpios" is deprecated and replaced by "sda-gpios" + "scl-gpios". */
ret = gpio_request_list_by_name(dev, "gpios", bus->gpios,
ARRAY_SIZE(bus->gpios), 0);
- if (ret == -ENOENT) {
+ if (ret == 0) {
ret = gpio_request_by_name(dev, "sda-gpios", 0,
>gpios[PIN_SDA], 0);
if (ret < 0)
--
2.41.0
Re: [PATCH] arm: mvebu: x240: Use i2c-gpio instead of built in controller
Hi Me,
On Thu, Jul 20, 2023 at 3:03 PM Chris Packham wrote:
>
> There is an Errata with the built-in I2C controller where various I2C
> hardware errors cause a complete lockup of the CPU (which eventually
> results in an watchdog reset).
>
> Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
> This uses a bit-banged implementation of an I2C controller and avoids
> triggering the Errata.
>
> Signed-off-by: Chris Packham
> ---
> This is dependent on a bug-fix for the i2c-gpio driver I just sent
> out[1] (sorry I should have sent them as a series but I thought this
> would take me longer to test than it did).
>
> [1] -
> https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
>
> arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
> configs/x240_defconfig | 1 +
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> index 820ec18b4355..d47220520b9e 100644
> --- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> +++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> @@ -71,8 +71,25 @@
> };
>
> {
> - status = "okay";
> + status = "disabled";
> +};
I'll remove this section completely. I did want to make it clear that
we're using the same pins just as GPIOs instead of the dedicated I2C
mode which has issues but that can be explained better in the commit
message.
>
> +&{/} {
I should probably move this part up to the root node rather than
addressing it here.
> + i2cgpio: i2c-gpio-0 {
> + compatible = "i2c-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio>;
> + scl-gpios = < 26 (GPIO_ACTIVE_HIGH |
> GPIO_OPEN_DRAIN)>;
> + sda-gpios = < 27 (GPIO_ACTIVE_HIGH |
> GPIO_OPEN_DRAIN)>;
> + i2c-gpio,delay-us = <2>;
> + status = "okay";
> +};
> +};
> +
> + {
> mux@71 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -177,8 +194,8 @@
> * LED_OE_N [23]
> * USB_PWR_FLT_N [24]
> * SFP_INT_N [25]
> -* I2C0_SCL [26]
> -* I2C0_SDA [27]
> +* I2C0_SCL [26] (GPIO)
> +* I2C0_SDA [27] (GPIO)
> * USB_EN[28]
> * MONITOR_INT_N [29]
> * XM1_MDC [30]
> @@ -201,7 +218,7 @@
> /* 0123456789 */
> pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> 0xff 0xff 11110xff 0xff 00
> -0000001100
> +0000000xff 0xff 00
> 1111000000
> 000111>;
>
> @@ -209,4 +226,9 @@
> marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
> marvell,function = <2>;
> };
> +
> + i2c0_gpio: i2c0-gpio-pins {
> + marvell,pins = <26 27>;
> + marvell,function = <0>;
> + };
> };
> diff --git a/configs/x240_defconfig b/configs/x240_defconfig
> index 6d25c5ae3fcf..e8589d636081 100644
> --- a/configs/x240_defconfig
> +++ b/configs/x240_defconfig
> @@ -43,6 +43,7 @@ CONFIG_CLK_MVEBU=y
> CONFIG_GPIO_HOG=y
> CONFIG_DM_PCA953X=y
> CONFIG_DM_I2C=y
> +CONFIG_DM_I2C_GPIO=y
> CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_MUX=y
> CONFIG_I2C_MUX_PCA954x=y
> --
> 2.41.0
>
[PATCH] arm: mvebu: x240: Use i2c-gpio instead of built in controller
There is an Errata with the built-in I2C controller where various I2C
hardware errors cause a complete lockup of the CPU (which eventually
results in an watchdog reset).
Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
This uses a bit-banged implementation of an I2C controller and avoids
triggering the Errata.
Signed-off-by: Chris Packham
---
This is dependent on a bug-fix for the i2c-gpio driver I just sent
out[1] (sorry I should have sent them as a series but I thought this
would take me longer to test than it did).
[1] -
https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
configs/x240_defconfig | 1 +
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index 820ec18b4355..d47220520b9e 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -71,8 +71,25 @@
};
{
- status = "okay";
+ status = "disabled";
+};
+&{/} {
+ i2cgpio: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <_gpio>;
+ scl-gpios = < 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ sda-gpios = < 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ status = "okay";
+};
+};
+
+ {
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -177,8 +194,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26]
-* I2C0_SDA [27]
+* I2C0_SCL [26] (GPIO)
+* I2C0_SDA [27] (GPIO)
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -201,7 +218,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000001100
+0000000xff 0xff 00
1111000000
000111>;
@@ -209,4 +226,9 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
+
+ i2c0_gpio: i2c0-gpio-pins {
+ marvell,pins = <26 27>;
+ marvell,function = <0>;
+ };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index 6d25c5ae3fcf..e8589d636081 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -43,6 +43,7 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.41.0
[PATCH] i2c: i2c-gpio: Correctly handle new {sda,scl}-gpios bindings
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham
---
drivers/i2c/i2c-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4ed9e9e7cddd..c1fc290bd253 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -339,7 +339,7 @@ static int i2c_gpio_of_to_plat(struct udevice *dev)
/* "gpios" is deprecated and replaced by "sda-gpios" + "scl-gpios". */
ret = gpio_request_list_by_name(dev, "gpios", bus->gpios,
ARRAY_SIZE(bus->gpios), 0);
- if (ret == -ENOENT) {
+ if (ret == 0) {
ret = gpio_request_by_name(dev, "sda-gpios", 0,
>gpios[PIN_SDA], 0);
if (ret < 0)
--
2.41.0
[PATCH] drivers: rtc: max313xx: provide read8/write8
In some designs the MAX313xx RTC may need calibration to cope with
oscillator inaccuracies. Provide read8/write8 ops so that the registers
can be accessed. Because the driver covers a range of MAX313xx variants
no attempt is made to ensure the register is valid.
Signed-off-by: Chris Packham
---
drivers/rtc/max313xx.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
index 748f3c42c30e..60400235dd0f 100644
--- a/drivers/rtc/max313xx.c
+++ b/drivers/rtc/max313xx.c
@@ -326,10 +326,22 @@ static int max313xx_reset(struct udevice *dev)
return ret;
}
+static int max313xx_read8(struct udevice *dev, unsigned int reg)
+{
+ return dm_i2c_reg_read(dev, reg);
+}
+
+static int max313xx_write8(struct udevice *dev, unsigned int reg, int val)
+{
+ return dm_i2c_reg_write(dev, reg, val);
+}
+
static const struct rtc_ops max3133x_rtc_ops = {
.get= max313xx_read_time,
.set= max313xx_set_time,
.reset = max313xx_reset,
+ .read8 = max313xx_read8,
+ .write8 = max313xx_write8,
};
static int max313xx_init(struct udevice *dev)
--
2.41.0
[PATCH v2 6/6] arm: mvebu: Remove unused alias from RC AC5X dts
The sar-reg0 alias was left over from an earlier iteration of the
patches adding support for this board. Remove the unused alias.
Fixes: 6cc8b5db40 ("arm: mvebu: Add RD-AC5X board")
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-rd.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
index d9f217cd4a5f..1dc85bb7ef24 100644
--- a/arch/arm/dts/ac5-98dx35xx-rd.dts
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -31,7 +31,6 @@
usb0 =
usb1 =
pinctrl0 =
- sar-reg0 = "/config-space/sar-reg";
};
usb1phy: usb-phy {
--
2.41.0
[PATCH v2 5/6] arm: mvebu: Add Allied Telesis x240 board
The x240 and SE240 are a series of L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- drop CONFIG_DEBUG_UART
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/alliedtelesis/x240/MAINTAINERS | 7 +
board/alliedtelesis/x240/Makefile | 6 +
board/alliedtelesis/x240/x240.c| 13 ++
configs/x240_defconfig | 86 ++
include/configs/x240.h | 37 +
8 files changed, 370 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
create mode 100644 board/alliedtelesis/x240/MAINTAINERS
create mode 100644 board/alliedtelesis/x240/Makefile
create mode 100644 board/alliedtelesis/x240/x240.c
create mode 100644 configs/x240_defconfig
create mode 100644 include/configs/x240.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..38d878a0f853 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
cn9130-crb-B.dtb\
- ac5-98dx35xx-rd.dtb
+ ac5-98dx35xx-rd.dtb \
+ ac5-98dx35xx-atl-x240.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
new file mode 100644
index ..820ec18b4355
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Allied Telesis x240";
+ compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ spi0 =
+ i2c0 =
+ usb0 =
+ pinctrl0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ boot-board {
+ compatible = "atl,boot-board";
+ present-gpio = < 6 GPIO_ACTIVE_HIGH>;
+ override-gpio = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ fault {
+ label = "fault:red";
+ gpios = <_gpio 11 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@user {
+ reg = <0x 0x1000>;
+ label = "user";
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>; /*
MPP36 */
+ status = "okay";
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ rtc@68 {
+ compatible = "adi,max31331";
+ reg = <0x68>;
+ };
+
+ system_gpio: gpio@27 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells= <2>;
+ reg = <0x27>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_L
[PATCH v2 4/6] mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K
The CN9130 SoC (an ARMADA 8K type) has both a NAND Flash Controller and a generic local bus controller (Device Bus Controller) that share common pins. With a board design that incorporates both a NAND flash and uses the Device Bus (in our case for an SRAM) accessing the Device Bus device fails unless the NfArbiterEn bit is set. Setting the bit enables arbitration between the Device Bus and the NAND flash. Since there is no obvious downside in enabling this for designs that don't require arbitration, we always enable it. Signed-off-by: Chris Packham --- drivers/mtd/nand/raw/pxa3xx_nand.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c b/drivers/mtd/nand/raw/pxa3xx_nand.c index 9dee580ab9c2..d502e967f92c 100644 --- a/drivers/mtd/nand/raw/pxa3xx_nand.c +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c @@ -125,6 +125,7 @@ DECLARE_GLOBAL_DATA_PTR; /* System control register and bit to enable NAND on some SoCs */ #define GENCONF_SOC_DEVICE_MUX 0x208 #define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0) +#define GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN BIT(27) /* * This should be large enough to read 'ONFI' and 'JEDEC'. @@ -1739,7 +1740,7 @@ static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info *inf return PTR_ERR(sysctrl_base); regmap_read(sysctrl_base, GENCONF_SOC_DEVICE_MUX, ); - reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN; + reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN | GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN; regmap_write(sysctrl_base, GENCONF_SOC_DEVICE_MUX, reg); } -- 2.41.0
[PATCH v2 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
the NFC used on other Marvell SoCs. It does have the additional
restriction of only supporting SDR timing modes up to 3.
Signed-off-by: Chris Packham
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index fcd1b9c63614..9dee580ab9c2 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
PXA3XX_NAND_VARIANT_ARMADA_8K,
+ PXA3XX_NAND_VARIANT_AC5,
};
struct pxa3xx_nand_host {
@@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada-8k-nand-controller",
.data = PXA3XX_NAND_VARIANT_ARMADA_8K,
},
+ {
+ .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_AC5,
+ },
{}
};
@@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host
*host)
if (mode < 0)
mode = 0;
+ if (info->variant == PXA3XX_NAND_VARIANT_AC5)
+ mode = min(mode, 3);
+
timings = onfi_async_timing_mode_to_sdr_timings(mode);
if (IS_ERR(timings))
return PTR_ERR(timings);
@@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
/* Device detection must be done with ECC disabled */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
*/
if (mtd->writesize > info->chunk_size) {
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
--
2.41.0
[PATCH v2 2/6] arm: mvebu: ac5: Define mvebu_get_nand_clock()
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping
or gating require so just add a mvebu_get_nand_clock() that
returns this value.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/soc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
b/arch/arm/mach-mvebu/alleycat5/soc.c
index dc69f46eedb2..734b0a87dd49 100644
--- a/arch/arm/mach-mvebu/alleycat5/soc.c
+++ b/arch/arm/mach-mvebu/alleycat5/soc.c
@@ -255,6 +255,12 @@ void soc_print_clock_info(void)
printf("\tMSS %4d MHz\n", 200);
}
+/* Return NAND clock in Hz */
+u32 mvebu_get_nand_clock(void)
+{
+ return 400 * 100;
+}
+
/*
* Override of __weak int mach_cpu_init(void) :
* SoC/machine dependent CPU setup
--
2.41.0
[PATCH v2 1/6] arm: mvebu: ac5: Add nand-controller node
The AC5/AC5X SoC has a NAND flash controller. Add this to the
SoC device tree.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx25xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
index 3c68355f323a..f53b4781d7fd 100644
--- a/arch/arm/dts/ac5-98dx25xx.dtsi
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -251,6 +251,15 @@
status = "disabled";
};
+ nand: nand-controller@805b {
+ compatible = "marvell,mvebu-ac5-pxa3xx-nand";
+ reg = <0x0 0x805b 0x0 0x54>;
+ #address-cells = <0x0001>;
+ marvell,nand-enable-arbiter;
+ num-cs = <0x0001>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@8060 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
2.41.0
[PATCH v2 0/6] Support for AC5X NAND and AT-x240 board
This series adds support for the NAND flash controller on the AC5X SoC and adds support for the Allied Telesis x240 board. I've also included 2 unrelated changes. "arm: mvebu: Remove unused alias from RC AC5X dts" removes an unused alias from the dts. This was in the neighborhood of the x240 so I included it. "mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K" allows using the NFC and device bus at the same time. This is needed for another board (CN9130 based) that I'll hopefully get upstream in the near future. I figured I'd include it now since I was touching the NAND driver. Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/mach-mvebu/Kconfig| 7 + arch/arm/mach-mvebu/alleycat5/soc.c| 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile | 6 + board/alliedtelesis/x240/x240.c| 13 ++ configs/x240_defconfig | 86 ++ drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 12 files changed, 401 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h -- 2.41.0
Re: [PATCH 5/6] arm: mvebu: Add Allied Telesis x240 board
On Mon, Jul 3, 2023 at 3:39 PM Chris Packham wrote:
>
> The x240 and SE240 are a series of L2+ switches from Allied Telesis.
> There are a number of them in the range but as far as U-Boot is
> concerned all the CPU block components are the same so there's only one
> board defined.
>
> Signed-off-by: Chris Packham
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
> arch/arm/mach-mvebu/Kconfig| 7 +
> board/alliedtelesis/x240/MAINTAINERS | 7 +
> board/alliedtelesis/x240/Makefile | 6 +
> board/alliedtelesis/x240/x240.c| 13 ++
> configs/x240_defconfig | 87 ++
> include/configs/x240.h | 37 +
> 8 files changed, 371 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> create mode 100644 board/alliedtelesis/x240/MAINTAINERS
> create mode 100644 board/alliedtelesis/x240/Makefile
> create mode 100644 board/alliedtelesis/x240/x240.c
> create mode 100644 configs/x240_defconfig
> create mode 100644 include/configs/x240.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa6065..38d878a0f853 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> cn9132-db-B.dtb \
> cn9130-crb-A.dtb\
> cn9130-crb-B.dtb\
> - ac5-98dx35xx-rd.dtb
> + ac5-98dx35xx-rd.dtb \
> + ac5-98dx35xx-atl-x240.dtb
> endif
>
> dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
> diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> new file mode 100644
> index ..820ec18b4355
> --- /dev/null
> +++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> @@ -0,0 +1,212 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "ac5-98dx35xx.dtsi"
> +
> +/ {
> + model = "Allied Telesis x240";
> + compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
> +
> + aliases {
> + serial0 =
> + spiflash0 =
> + gpio0 =
> + gpio1 =
> + spi0 =
> + i2c0 =
> + usb0 =
> + pinctrl0 =
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + boot-board {
> + compatible = "atl,boot-board";
> + present-gpio = < 6 GPIO_ACTIVE_HIGH>;
> + override-gpio = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + label = "fault:red";
> + gpios = <_gpio 11 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + };
> +};
> +
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_pins>;
> +
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> + status = "okay";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@user {
> + reg = <0x 0x1000>;
> + label = "user";
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + mux@71 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nxp,pca9546";
> + reg = <0x71>;
> + i2c-mux-idle-disconnect;
> + reset-gpios = < 4 GPIO_ACTIVE_LOW>; /*
> MPP36 */
> + status = "okay";
> +
> + i2c@1 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <1>;
> +
> + hwmon@2e {
> +
[PATCH 6/6] arm: mvebu: Remove unused alias from RC AC5X dts
The sar-reg0 alias was left over from an earlier iteration of the
patches adding support for this board. Remove the unused alias.
Fixes: 6cc8b5db40 ("arm: mvebu: Add RD-AC5X board")
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-rd.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
index d9f217cd4a5f..1dc85bb7ef24 100644
--- a/arch/arm/dts/ac5-98dx35xx-rd.dts
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -31,7 +31,6 @@
usb0 =
usb1 =
pinctrl0 =
- sar-reg0 = "/config-space/sar-reg";
};
usb1phy: usb-phy {
--
2.41.0
[PATCH 5/6] arm: mvebu: Add Allied Telesis x240 board
The x240 and SE240 are a series of L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/alliedtelesis/x240/MAINTAINERS | 7 +
board/alliedtelesis/x240/Makefile | 6 +
board/alliedtelesis/x240/x240.c| 13 ++
configs/x240_defconfig | 87 ++
include/configs/x240.h | 37 +
8 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
create mode 100644 board/alliedtelesis/x240/MAINTAINERS
create mode 100644 board/alliedtelesis/x240/Makefile
create mode 100644 board/alliedtelesis/x240/x240.c
create mode 100644 configs/x240_defconfig
create mode 100644 include/configs/x240.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..38d878a0f853 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
cn9130-crb-B.dtb\
- ac5-98dx35xx-rd.dtb
+ ac5-98dx35xx-rd.dtb \
+ ac5-98dx35xx-atl-x240.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
new file mode 100644
index ..820ec18b4355
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Allied Telesis x240";
+ compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ spi0 =
+ i2c0 =
+ usb0 =
+ pinctrl0 =
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ boot-board {
+ compatible = "atl,boot-board";
+ present-gpio = < 6 GPIO_ACTIVE_HIGH>;
+ override-gpio = < 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ fault {
+ label = "fault:red";
+ gpios = <_gpio 11 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@user {
+ reg = <0x 0x1000>;
+ label = "user";
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>; /*
MPP36 */
+ status = "okay";
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ rtc@68 {
+ compatible = "adi,max31331";
+ reg = <0x68>;
+ };
+
+ system_gpio: gpio@27 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells= <2>;
+ reg = <0x27>;
+ interrupt-parent = <>;
+ interrupts = <25 IRQ_TYPE_LEVEL_LOW>; /*
MPP25 */
+ };
+
[PATCH 4/6] mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K
The CN9130 SoC (an ARMADA 8K type) has both a NAND Flash Controller and a generic local bus controller (Device Bus Controller) that share common pins. With a board design that incorporates both a NAND flash and uses the Device Bus (in our case for an SRAM) accessing the Device Bus device fails unless the NfArbiterEn bit is set. Setting the bit enables arbitration between the Device Bus and the NAND flash. Since there is no obvious downside in enabling this for designs that don't require arbitration, we always enable it. Signed-off-by: Chris Packham --- drivers/mtd/nand/raw/pxa3xx_nand.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c b/drivers/mtd/nand/raw/pxa3xx_nand.c index 9dee580ab9c2..d502e967f92c 100644 --- a/drivers/mtd/nand/raw/pxa3xx_nand.c +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c @@ -125,6 +125,7 @@ DECLARE_GLOBAL_DATA_PTR; /* System control register and bit to enable NAND on some SoCs */ #define GENCONF_SOC_DEVICE_MUX 0x208 #define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0) +#define GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN BIT(27) /* * This should be large enough to read 'ONFI' and 'JEDEC'. @@ -1739,7 +1740,7 @@ static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info *inf return PTR_ERR(sysctrl_base); regmap_read(sysctrl_base, GENCONF_SOC_DEVICE_MUX, ); - reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN; + reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN | GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN; regmap_write(sysctrl_base, GENCONF_SOC_DEVICE_MUX, reg); } -- 2.41.0
[PATCH 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
the NFC used on other Marvell SoCs. It does have the additional
restriction of only supporting SDR timing modes up to 3.
Signed-off-by: Chris Packham
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index fcd1b9c63614..9dee580ab9c2 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
PXA3XX_NAND_VARIANT_ARMADA_8K,
+ PXA3XX_NAND_VARIANT_AC5,
};
struct pxa3xx_nand_host {
@@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada-8k-nand-controller",
.data = PXA3XX_NAND_VARIANT_ARMADA_8K,
},
+ {
+ .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_AC5,
+ },
{}
};
@@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host
*host)
if (mode < 0)
mode = 0;
+ if (info->variant == PXA3XX_NAND_VARIANT_AC5)
+ mode = min(mode, 3);
+
timings = onfi_async_timing_mode_to_sdr_timings(mode);
if (IS_ERR(timings))
return PTR_ERR(timings);
@@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
/* Device detection must be done with ECC disabled */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
*/
if (mtd->writesize > info->chunk_size) {
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
--
2.41.0
[PATCH 1/6] arm: mvebu: ac5: Add nand-controller node
The AC5/AC5X SoC has a NAND flash controller. Add this to the
SoC device tree.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx25xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
index 3c68355f323a..f53b4781d7fd 100644
--- a/arch/arm/dts/ac5-98dx25xx.dtsi
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -251,6 +251,15 @@
status = "disabled";
};
+ nand: nand-controller@805b {
+ compatible = "marvell,mvebu-ac5-pxa3xx-nand";
+ reg = <0x0 0x805b 0x0 0x54>;
+ #address-cells = <0x0001>;
+ marvell,nand-enable-arbiter;
+ num-cs = <0x0001>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@8060 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
2.41.0
[PATCH 2/6] arm: mvebu: ac5: Define mvebu_get_nand_clock()
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping
or gating require so just add a mvebu_get_nand_clock() that
returns this value.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/soc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
b/arch/arm/mach-mvebu/alleycat5/soc.c
index dc69f46eedb2..734b0a87dd49 100644
--- a/arch/arm/mach-mvebu/alleycat5/soc.c
+++ b/arch/arm/mach-mvebu/alleycat5/soc.c
@@ -255,6 +255,12 @@ void soc_print_clock_info(void)
printf("\tMSS %4d MHz\n", 200);
}
+/* Return NAND clock in Hz */
+u32 mvebu_get_nand_clock(void)
+{
+ return 400 * 100;
+}
+
/*
* Override of __weak int mach_cpu_init(void) :
* SoC/machine dependent CPU setup
--
2.41.0
[PATCH 0/6] Support for AC5X NAND and AT-x240 board
This series adds support for the NAND flash controller on the AC5X SoC and adds support for the Allied Telesis x240 board. I've also included 2 unrelated changes. "arm: mvebu: Remove unused alias from RC AC5X dts" removes an unused alias from the dts. This was in the neighborhood of the x240 so I included it. "mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K" allows using the NFC and device bus at the same time. This is needed for another board (CN9130 based) that I'll hopefully get upstream in the near future. I figured I'd include it now since I was touching the NAND driver. Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/mach-mvebu/Kconfig| 7 + arch/arm/mach-mvebu/alleycat5/soc.c| 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile | 6 + board/alliedtelesis/x240/x240.c| 13 ++ configs/x240_defconfig | 87 ++ drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 12 files changed, 402 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h -- 2.41.0
Re: Current way of using pinctrl-mvebu
Answering my own question (I think) On Mon, Jul 3, 2023 at 12:10 PM Chris Packham wrote: > > Hi, > > I'm looking to upstream support for a new board with the Marvell AC5X > SoC and some NAND driver changes to support the SoC/board. I've got > things working when chain loading vendor based u-boot -> upstream > u-boot but when I boot directly the NAND controller reports > "pxa3xx-nand nand-controller@805b: Ready timeout!!!". > > I think this is because the multi purpose pins are not in NAND/DEV > mode. When chainloading the vendor u-boot has already done this so the > driver works. > > I notice that pinctrl-mvebu.c just expects a single fixed pin-func > property the covers all the functions required. How is the probe for > this supposed to be configured? If I define the proper pinconf subnodes and associate them with the device then the pinmux does get probed. I still need to define a pin-func property otherwise mvebu_pinctl_probe()/mvebu_pinctrl_set_state_all() will fail with -EINVAL. > > Thanks, > Chris
Current way of using pinctrl-mvebu
Hi, I'm looking to upstream support for a new board with the Marvell AC5X SoC and some NAND driver changes to support the SoC/board. I've got things working when chain loading vendor based u-boot -> upstream u-boot but when I boot directly the NAND controller reports "pxa3xx-nand nand-controller@805b: Ready timeout!!!". I think this is because the multi purpose pins are not in NAND/DEV mode. When chainloading the vendor u-boot has already done this so the driver works. I notice that pinctrl-mvebu.c just expects a single fixed pin-func property the covers all the functions required. How is the probe for this supposed to be configured? Thanks, Chris
[PATCH v2 2/2] drivers: rtc: add max313xx series rtc driver
Adding support for Analog Devices MAX313XX series RTCs.
This is ported from the Linux driver and adapted for use in u-boot.
Notable differences are
- handling of tm_year and tm_mon differ
- clock source support is omitted
- hwmon support for the MAX31328 and MAX31343 is omitted
- rtc_ops->reset is added
Signed-off-by: Chris Packham
Reviewed-by: Simon Glass
---
Changes in v2:
- Enable in sandbox for compile testing
- Note feature omissions in Kconfig
- Incorporate review comments from Simon
- Collect r-by from Simon
configs/sandbox_defconfig | 1 +
drivers/rtc/Kconfig | 13 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/max313xx.c| 459 ++
4 files changed, 474 insertions(+)
create mode 100644 drivers/rtc/max313xx.c
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 77ade1f1d873..0c898df44672 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -267,6 +267,7 @@ CONFIG_SANDBOX_RESET=y
CONFIG_RESET_SYSCON=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RTC=y
+CONFIG_RTC_MAX313XX=y
CONFIG_RTC_RV8803=y
CONFIG_RTC_HT1380=y
CONFIG_SCSI=y
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 35b6ed4d7c72..aae2ae61ba36 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -134,6 +134,19 @@ config RTC_ISL1208
This driver supports reading and writing the RTC/calendar and detects
total power failures.
+config RTC_MAX313XX
+ bool "Analog Devices MAX313XX RTC driver"
+ depends on DM_RTC
+ depends on DM_I2C
+ help
+ If you say yes here you will get support for the
+ Analog Devices MAX313XX series RTC family.
+
+ Chip features not currently supported:
+ - Timestamp registers as SRAM
+ - Temperature sensor
+ - CLKOUT generation
+
config RTC_PCF8563
tristate "Philips PCF8563"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 447551e15aa2..adfa23f66702 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RTC_HT1380) += ht1380.o
obj-$(CONFIG_SANDBOX) += i2c_rtc_emul.o
obj-$(CONFIG_RTC_ISL1208) += isl1208.o
obj-$(CONFIG_RTC_M41T62) += m41t62.o
+obj-$(CONFIG_RTC_MAX313XX) += max313xx.o
obj-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
obj-$(CONFIG_RTC_MC146818) += mc146818.o
obj-$(CONFIG_MCFRTC) += mcfrtc.o
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
new file mode 100644
index ..748f3c42c30e
--- /dev/null
+++ b/drivers/rtc/max313xx.c
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices MAX313XX series I2C RTC driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* common registers */
+#define MAX313XX_INT_ALARM1BIT(0)
+#define MAX313XX_INT_ALARM2BIT(1)
+#define MAX313XX_HRS_F_12_24 BIT(6)
+#define MAX313XX_HRS_F_AM_PM BIT(5)
+#define MAX313XX_MONTH_CENTURY BIT(7)
+
+#define MAX313XX_TMR_CFG_ENABLEBIT(4)
+#define MAX313XX_TMR_CFG_FREQ_MASK GENMASK(1, 0)
+#define MAX313XX_TMR_CFG_FREQ_16HZ 0x03
+
+#define MAX313XX_REG_MINUTE0x01
+#define MAX313XX_REG_HOUR 0x02
+
+#define MAX313XX_TIME_SIZE 0x07
+
+/* device specific registers */
+#define MAX3134X_CFG2_REG 0x01
+#define MAX3134X_CFG2_SET_RTC BIT(1)
+
+#define MAX31341_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31341_TRICKLE_DIODE_EN BIT(2)
+#define MAX31341_TRICKLE_ENABLE_BITBIT(3)
+#define MAX31341_POWER_MGMT_REG0x56
+#define MAX31341_POWER_MGMT_TRICKLE_BITBIT(0)
+
+#define MAX3133X_TRICKLE_RES_MASK GENMASK(2, 1)
+#define MAX3133X_TRICKLE_DIODE_EN BIT(3)
+#define MAX3133X_TRICKLE_ENABLE_BITBIT(0)
+
+#define MAX31329_TRICKLE_ENABLE_BITBIT(7)
+#define MAX31343_TRICKLE_ENABLE_MASK GENMASK(7, 4)
+#define MAX31343_TRICKLE_ENABLE_CODE 5
+#define MAX31329_43_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31329_43_TRICKLE_DIODE_EN BIT(2)
+
+#define MAX31329_CONFIG2_REG 0x04
+#define MAX31329_CONFIG2_CLKIN_EN BIT(2)
+#define MAX31329_CONFIG2_CLKIN_FREQGENMASK(1, 0)
+
+#define MAX31341_42_CONFIG1_REG0x00
+#define MAX31341_42_CONFIG1_CLKIN_EN BIT(7)
+#define MAX31341_42_CONFIG1_CLKIN_FREQ GENMASK(5, 4)
+#define MAX31341_42_CONFIG1_OSC_DISABLEBIT(3)
+#define MAX31341_42_CONFIG1_SWRST BIT(0)
+
+enum max313xx_ids {
+ ID_MAX31328,
+ ID_MAX31329,
+ ID_MAX31331,
+ ID_MAX31334,
+ ID_MAX31341,
+ ID_MAX31342,
+ ID_MAX31343,
+ MAX313XX_ID_NR
+};
+
+/**
+ * struct chip_desc - descriptor for MAX313xx variants
+ * @sec_reg: Offset to seconds register. Used to denote the start of the
+ * current time registers.
+ * @alarm1_sec_reg: Offset to Alarm1 seconds r
[PATCH v2 1/2] include: kernel.h: port find_closest() from Linux
The find_closest() macro can be used to find an element in a sorted
array that is closest to an input value. Bring in this macro from
Linux v6.3-rc1-2-g8ca09d5fa354.
Signed-off-by: Chris Packham
Reviewed-by: Simon Glass
---
Changes in v2:
- Add note on which Linux version this came from
- Collect review from Simon
include/linux/kernel.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3e71d61074b6..5cd6c9dc8219 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -284,4 +284,28 @@
offsetof(struct structure, member) == (offset), \
"`struct " #structure "` offset for `" #member "` is not " #offset)
+#define __find_closest(x, a, as, op) \
+({ \
+ typeof(as) __fc_i, __fc_as = (as) - 1; \
+ typeof(x) __fc_x = (x); \
+ typeof(*a) const *__fc_a = (a); \
+ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \
+ if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] +\
+ __fc_a[__fc_i + 1], 2)) \
+ break; \
+ } \
+ (__fc_i); \
+})
+
+/**
+ * find_closest - locate the closest element in a sorted array
+ * @x: The reference value.
+ * @a: The array in which to look for the closest element. Must be sorted
+ * in ascending order.
+ * @as: Size of 'a'.
+ *
+ * Returns the index of the element closest to 'x'.
+ */
+#define find_closest(x, a, as) __find_closest(x, a, as, <=)
+
#endif
--
2.40.0
[PATCH v2 0/2] max313xx RTC driver
This series is based on the in-flight linux patch that is adding support for this family of RTCs to linux[1]. The u-boot driver is a bit different due to some of the differences between Linux and u-boot and I've dropped the support for hwmon and clock source functions. Where possible I've tried to keep things such that the U-Boot and Linux versions can be compared and kept in sync. For reference the datasheets are all available at https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31328.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31329.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31331.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31334.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31341B-MAX31341C.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31342.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31343.pdf [1] - https://lore.kernel.org/all/20221108122254.1185-2-ibrahim.ti...@analog.com/ Changes in v2: - Add note on which Linux version this came from - Collect review from Simon - Enable in sandbox for compile testing - Note feature omissions in Kconfig - Incorporate review comments from Simon - Collect r-by from Simon Chris Packham (2): include: kernel.h: port find_closest() from Linux drivers: rtc: add max313xx series rtc driver configs/sandbox_defconfig | 1 + drivers/rtc/Kconfig | 13 ++ drivers/rtc/Makefile | 1 + drivers/rtc/max313xx.c| 459 ++ include/linux/kernel.h| 24 ++ 5 files changed, 498 insertions(+) create mode 100644 drivers/rtc/max313xx.c -- 2.40.0
[PATCH 2/2] drivers: rtc: add max313xx series rtc driver
Adding support for Analog Devices MAX313XX series RTCs.
This is ported from the Linux driver and adapted for use in u-boot.
Notable differences are
- handling of tm_year and tm_mon differ
- clock source support is omitted
- hwmon support for the MAX31328 and MAX31343 is omitted
- rtc_ops->reset is added
Signed-off-by: Chris Packham
---
drivers/rtc/Kconfig| 8 +
drivers/rtc/Makefile | 1 +
drivers/rtc/max313xx.c | 442 +
3 files changed, 451 insertions(+)
create mode 100644 drivers/rtc/max313xx.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 35b6ed4d7c72..49c260b5b190 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -134,6 +134,14 @@ config RTC_ISL1208
This driver supports reading and writing the RTC/calendar and detects
total power failures.
+config RTC_MAX313XX
+ bool "Analog Devices MAX313XX RTC driver"
+ depends on DM_RTC
+ depends on DM_I2C
+ help
+ If you say yes here you will get support for the
+ Analog Devices MAX313XX series RTC family.
+
config RTC_PCF8563
tristate "Philips PCF8563"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 447551e15aa2..adfa23f66702 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RTC_HT1380) += ht1380.o
obj-$(CONFIG_SANDBOX) += i2c_rtc_emul.o
obj-$(CONFIG_RTC_ISL1208) += isl1208.o
obj-$(CONFIG_RTC_M41T62) += m41t62.o
+obj-$(CONFIG_RTC_MAX313XX) += max313xx.o
obj-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
obj-$(CONFIG_RTC_MC146818) += mc146818.o
obj-$(CONFIG_MCFRTC) += mcfrtc.o
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
new file mode 100644
index ..1aa430d121ee
--- /dev/null
+++ b/drivers/rtc/max313xx.c
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices MAX313XX series I2C RTC driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* common registers */
+#define MAX313XX_INT_ALARM1BIT(0)
+#define MAX313XX_INT_ALARM2BIT(1)
+#define MAX313XX_HRS_F_12_24 BIT(6)
+#define MAX313XX_HRS_F_AM_PM BIT(5)
+#define MAX313XX_MONTH_CENTURY BIT(7)
+
+#define MAX313XX_TMR_CFG_ENABLEBIT(4)
+#define MAX313XX_TMR_CFG_FREQ_MASK GENMASK(1, 0)
+#define MAX313XX_TMR_CFG_FREQ_16HZ 0x03
+
+#define MAX313XX_REG_MINUTE0x01
+#define MAX313XX_REG_HOUR 0x02
+
+#define MAX313XX_TIME_SIZE 0x07
+
+/* device specific registers */
+#define MAX3134X_CFG2_REG 0x01
+#define MAX3134X_CFG2_SET_RTC BIT(1)
+
+#define MAX31341_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31341_TRICKLE_DIODE_EN BIT(2)
+#define MAX31341_TRICKLE_ENABLE_BITBIT(3)
+#define MAX31341_POWER_MGMT_REG0x56
+#define MAX31341_POWER_MGMT_TRICKLE_BITBIT(0)
+
+#define MAX3133X_TRICKLE_RES_MASK GENMASK(2, 1)
+#define MAX3133X_TRICKLE_DIODE_EN BIT(3)
+#define MAX3133X_TRICKLE_ENABLE_BITBIT(0)
+
+#define MAX31329_TRICKLE_ENABLE_BITBIT(7)
+#define MAX31343_TRICKLE_ENABLE_MASK GENMASK(7, 4)
+#define MAX31343_TRICKLE_ENABLE_CODE 5
+#define MAX31329_43_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31329_43_TRICKLE_DIODE_EN BIT(2)
+
+#define MAX31329_CONFIG2_REG 0x04
+#define MAX31329_CONFIG2_CLKIN_EN BIT(2)
+#define MAX31329_CONFIG2_CLKIN_FREQGENMASK(1, 0)
+
+#define MAX31341_42_CONFIG1_REG0x00
+#define MAX31341_42_CONFIG1_CLKIN_EN BIT(7)
+#define MAX31341_42_CONFIG1_CLKIN_FREQ GENMASK(5, 4)
+#define MAX31341_42_CONFIG1_OSC_DISABLEBIT(3)
+#define MAX31341_42_CONFIG1_SWRST BIT(0)
+
+enum max313xx_ids {
+ ID_MAX31328,
+ ID_MAX31329,
+ ID_MAX31331,
+ ID_MAX31334,
+ ID_MAX31341,
+ ID_MAX31342,
+ ID_MAX31343,
+ MAX313XX_ID_NR
+};
+
+struct chip_desc {
+ struct clkout_cfg *clkout;
+ const char *clkout_name;
+ u8 sec_reg;
+ u8 alarm1_sec_reg;
+
+ u8 int_en_reg;
+ u8 int_status_reg;
+
+ u8 ram_reg;
+ u8 ram_size;
+
+ u8 temp_reg;
+
+ u8 trickle_reg;
+
+ u8 rst_reg;
+ u8 rst_bit;
+};
+
+struct max313xx {
+ enum max313xx_ids id;
+ const struct chip_desc *chip;
+};
+
+static const struct chip_desc chip[MAX313XX_ID_NR] = {
+ [ID_MAX31328] = {
+ .int_en_reg = 0x0E,
+ .int_status_reg = 0x0F,
+ .sec_reg = 0x00,
+ .alarm1_sec_reg = 0x07,
+ },
+ [ID_MAX31329] = {
+ .int_en_reg = 0x01,
+ .int_status_reg = 0x00,
+ .sec_reg = 0x06,
+ .alarm1_sec_reg = 0x0D,
+ .ram_reg = 0x22,
+ .ram_size = 64,
+ .trickle_reg = 0x19,
+
[PATCH 1/2] include: kernel.h: port find_closest() from Linux
The find_closest() macro can be used to find an element in a sorted
array that is closest to an input value.
Signed-off-by: Chris Packham
---
include/linux/kernel.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3e71d61074b6..5cd6c9dc8219 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -284,4 +284,28 @@
offsetof(struct structure, member) == (offset), \
"`struct " #structure "` offset for `" #member "` is not " #offset)
+#define __find_closest(x, a, as, op) \
+({ \
+ typeof(as) __fc_i, __fc_as = (as) - 1; \
+ typeof(x) __fc_x = (x); \
+ typeof(*a) const *__fc_a = (a); \
+ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \
+ if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] +\
+ __fc_a[__fc_i + 1], 2)) \
+ break; \
+ } \
+ (__fc_i); \
+})
+
+/**
+ * find_closest - locate the closest element in a sorted array
+ * @x: The reference value.
+ * @a: The array in which to look for the closest element. Must be sorted
+ * in ascending order.
+ * @as: Size of 'a'.
+ *
+ * Returns the index of the element closest to 'x'.
+ */
+#define find_closest(x, a, as) __find_closest(x, a, as, <=)
+
#endif
--
2.40.0
[PATCH 0/2] max313xx RTC driver
This series is based on the in-flight linux patch that is adding support for this family of RTCs to linux[1]. The u-boot driver is a bit different due to some of the differences between Linux and u-boot and I've dropped the support for hwmon and clock source functions. Where possible I've tried to keep things such that the U-Boot and Linux versions can be compared and kept in sync. [1] - https://lore.kernel.org/all/20221108122254.1185-2-ibrahim.ti...@analog.com/ Chris Packham (2): include: kernel.h: port find_closest() from Linux drivers: rtc: add max313xx series rtc driver drivers/rtc/Kconfig| 8 + drivers/rtc/Makefile | 1 + drivers/rtc/max313xx.c | 442 + include/linux/kernel.h | 24 +++ 4 files changed, 475 insertions(+) create mode 100644 drivers/rtc/max313xx.c -- 2.40.0
Re: [PATCH 07/13] mvebe: Drop ARCH_MISC_INIT from alleycat 5
On 16/02/23 16:36, Tom Rini wrote:
> In this platform, arch_misc_init doesn't perform any real function. The
> call to get_soc_type_rev has no lasting side effects.
>
> Cc: Chris Packham
> Signed-off-by: Tom Rini \
A hangover from the Marvell code I started with. They've replaced it
with an empty arch_misc_init() in their newer u-boot code but not
selecting CONFIG_ARCH_MISC_INIT is a much better approach.
Reviewed-by: Chris Packham
> ---
> arch/arm/mach-mvebu/alleycat5/soc.c | 9 -
> configs/mvebu_ac5_rd_defconfig | 1 -
> 2 files changed, 10 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> b/arch/arm/mach-mvebu/alleycat5/soc.c
> index efbef233a148..dc69f46eedb2 100644
> --- a/arch/arm/mach-mvebu/alleycat5/soc.c
> +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> @@ -287,12 +287,3 @@ int mach_cpu_init(void)
>
> return 0;
> }
> -
> -int arch_misc_init(void)
> -{
> - u32 type, rev;
> -
> - get_soc_type_rev(, );
> -
> - return 0;
> -}
> diff --git a/configs/mvebu_ac5_rd_defconfig b/configs/mvebu_ac5_rd_defconfig
> index a27202eb23e2..4e66791dbda8 100644
> --- a/configs/mvebu_ac5_rd_defconfig
> +++ b/configs/mvebu_ac5_rd_defconfig
> @@ -22,7 +22,6 @@ CONFIG_SYS_CONSOLE_ENV_OVERWRITE=y
> CONFIG_SYS_CONSOLE_INFO_QUIET=y
> CONFIG_DISPLAY_BOARDINFO_LATE=y
> CONFIG_ARCH_EARLY_INIT_R=y
> -CONFIG_ARCH_MISC_INIT=y
> CONFIG_CMD_BOOTZ=y
> CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS=10
> CONFIG_CMD_MEMTEST=y
Re: [PATCH 29/88] i2c: Rename I2C_MUX_PCA954x
Hi Simon On 24/01/23 10:59, Simon Glass wrote: > CONFIG options must not use lower-case letter. Convert this to upper case. > > Signed-off-by: Simon Glass > --- > > configs/SBx81LIFKW_defconfig | 2 +- > configs/SBx81LIFXCAT_defconfig | 2 +- > configs/x530_defconfig | 2 +- For these boards Reviewed-by: Chris Packham
Re: kwboot: UART booting with bin_hdr u-boot (Marvell Armada 385)
On Wed, 4 Jan 2023, 8:52 PM Pali Rohár, wrote: > On Wednesday 04 January 2023 08:50:28 Pali Rohár wrote: > > Hello! > > > > On Tuesday 03 January 2023 17:55:41 Tony Dinh wrote: > > > Hi Pali, > > > > > > I'm building a new u-boot for the Thecus N2350 board (Armada 385 > > > dual-core 1Ghz 1GB DDR4). The trouble with this board is DDR4, which > > > is not currently supported in u-boot (also cc this to Chris for > > > commenting about Marvell DDR4 training driver). > > > > Yes, ddr4 training code is not in u-boot yet. > > > > A38x u-boot ddr driver is in this directory: > > > https://source.denx.de/u-boot/u-boot/-/tree/master/drivers/ddr/marvell/a38x > > > > And it is copied from the original marvell driver by stripping non-a38x > > code and removal of the ddr4 code from the master branch: > > https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell > > > > So you can try to copy code again without stripping ddr4 parts > > (run git log drivers/ddr/marvell/a38x in u-boot) > > > https://source.denx.de/u-boot/u-boot/-/commit/107c3391b95bcc2ba09a876da4fa0c31b6c1e460 > > > And adjust u-boot board code for ddr4. > > > > I guess it could work but it would be needed to play with it. > Last time I looked the MarvellEmbeddedProcessors stuff was a long way behind what Marvell are releasing to customers. That was for the newer SoCs so maybe the A385 stuff is current. > > > > So I'm building with binary.0 in the ./board/thecus/n2350/. This > > > binary.0 is a copy of the Marvell bin_hdr for SPI in the GPL source > > > for this board (provided by Thecus). My > > > ./board/thecus/n2350/kwbimage.cfg.in file looks like this > > > > > > # Armada 38x uses version 1 image format > > > VERSION 1 > > > # Boot Media configurations > > > BOOT_FROM spi > > > # Binary Header (bin_hdr) with DDR4 training code > > > BINARY board/thecus/n2350/binary.0 005b 0068 > > > > > > When I kwboot the u-boot.kwb image (using kwboot binary built with > > > 2023.01-rc4), the header was transferred successfully, but then the > > > BootROM jumped to SPI u-boot, instead of loading the u-boot payload > > > from UART. Please see the log below. > > > > > > # ./kwboot -t -p -B 115200 /dev/ttyUSB0 -b uboot.kwb > > > > > > kwboot version 2023.01-tld-1-00048-g19e15f9081-dirty > > > Patching image boot signature to UART > > > Aligning image header to Xmodem block size > > > Sending boot message. Please reboot the target.../ > > > Sending boot image header (97792 bytes)... > > > 0 % > [..] > > > 9 % > [..] > > > > > > 82 % > [..] > > > 91 % > [ ] > > > Done > > > > > > BootROM - 1.73 > > > Booting from SPI flash > > > > This indicates reset of the board. BootROM started execution of the > > image from the primary location. > > > > > > > > U-Boot 2013.01 (Nov 12 2018 - 20:56:19) Marvell version: > 2015_T1.0p18-tld-4 > > > > > > > > > It seems kwboot patched the image, but the BOOT_FROM indicator was > > > still recognized as from SPI. So the BootROM loaded the stock u-boot > > > image from SPI and executed it. Since I am booting with bin_hdr, I'm > > > not sure if there is something inside this blob that has forced this > > > indicator to SPI. > > > > No, blob cannot force BootROM to switch boot location. This really > > indicates crash of the blob or crash of the payload which results in the > > board reset. > > > > > I'm attaching the u-boot.kwb image to this email, in case you are > > > interested in taking a look at the structure. > > > > > > Thanks, > > > Tony > > > > >
Re: [PATCH 0/5] Complete the migration of MTDPARTS_DEFAULT / MTDIDS_DEFAULT
On 7/12/22 21:26, Patrick Delaunay wrote:
> Addition for previous commit a331017c237c ("Complete migration of
> MTDPARTS_DEFAULT / MTDIDS_DEFAULT, include in environment")
>
> Remove the remaining defines MTDPARTS_DEFAULT and MTDIDS_DEFAULT
> in the configuration files (include/configs/*.h).
>
> After this serie, the only remaining references of these 2 defines are
> located in cmd/mtdparts.c and only for local purpose when
> CONFIG_MTDIDS_DEFAULT or CONFIG_MTDPART_DEFAULT are not defined.
>
> Patrick.
>
>
> Patrick Delaunay (5):
>configs: am333x_guardian: move MTDIDS_DEFAULT in defconfif
>configs: x530: move MTDPART/MTDIDS_DEFAULT in defconfig
>configs: SBx81LIFXCAT: move MTDPART_DEFAULT in defconfig
>configs: SBx81LIFKW: move MTDPART_DEFAULT in defconfig
>configs: remove support of MTDIDS_DEFAULT/MTDPARTS_DEFAULT
For x530, SBx81LIFXCAT and SBx81LIFKW
Reviewed-by: Chris Packham
> cmd/mtdparts.c| 5 +
> configs/SBx81LIFKW_defconfig | 1 +
> configs/SBx81LIFXCAT_defconfig| 1 +
> configs/am335x_guardian_defconfig | 1 +
> configs/x530_defconfig| 2 ++
> drivers/mtd/mtd_uboot.c | 4
> include/configs/SBx81LIFKW.h | 1 -
> include/configs/SBx81LIFXCAT.h| 1 -
> include/configs/am335x_guardian.h | 1 -
> include/configs/x530.h| 2 --
> 10 files changed, 6 insertions(+), 13 deletions(-)
>
Re: [PATCH v3 4/8] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
On Mon, Nov 7, 2022 at 9:45 PM Pali Rohár wrote: > > On Monday 07 November 2022 09:13:37 Stefan Roese wrote: > > Hi Chris, > > > > On 07.11.22 09:11, Chris Packham wrote: > > > > > > > > > On Mon, 7 Nov 2022, 7:23 PM Stefan Roese, > > <mailto:s...@denx.de>> wrote: > > > > > > Hi Chris, > > > > > > On 05.11.22 05:08, Chris Packham wrote: > > > > On Sat, Nov 5, 2022 at 5:03 PM Chris Packham > > > mailto:judge.pack...@gmail.com>> wrote: > > > >> > > > >> Hi Stefan, > > > >> > > > >> On Fri, Sep 16, 2022 at 2:23 AM Stefan Roese > > <mailto:s...@denx.de>> wrote: > > > >>> > > > >>> Now that the new timer support is available for these > > > platforms, let's > > > >>> select this IF for all these platforms. This way it's not > > > necessary > > > >>> that each board changes it's config header. > > > >>> > > > >>> Signed-off-by: Stefan Roese mailto:s...@denx.de>> > > > >>> Tested-by: Tony Dinh > > <mailto:mibo...@gmail.com>> > > > >>> --- > > > >>> v3: > > > >>> - No change > > > >>> > > > >>> v2: > > > >>> - No change > > > >>> > > > >>> arch/arm/Kconfig | 4 > > > >>> arch/arm/mach-mvebu/include/mach/config.h | 5 - > > > >>> 2 files changed, 4 insertions(+), 5 deletions(-) > > > >>> > > > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > > >>> index 82cd456f51f1..4ed100ab0ede 100644 > > > >>> --- a/arch/arm/Kconfig > > > >>> +++ b/arch/arm/Kconfig > > > >>> @@ -618,6 +618,7 @@ config ARCH_KIRKWOOD > > > >>> select BOARD_EARLY_INIT_F > > > >>> select CPU_ARM926EJS > > > >>> select GPIO_EXTRA_HEADER > > > >>> + select TIMER > > > >>> > > > >>> config ARCH_MVEBU > > > >>> bool "Marvell MVEBU family (Armada > > > XP/375/38x/3700/7K/8K)" > > > >>> @@ -629,6 +630,8 @@ config ARCH_MVEBU > > > >>> select GPIO_EXTRA_HEADER > > > >>> select SPL_DM_SPI if SPL > > > >>> select SPL_DM_SPI_FLASH if SPL > > > >>> + select SPL_TIMER if SPL > > > >>> + select TIMER > > > >>> select OF_CONTROL > > > >>> select OF_SEPARATE > > > >>> select SPI > > > >>> @@ -639,6 +642,7 @@ config ARCH_ORION5X > > > >>> select CPU_ARM926EJS > > > >>> select GPIO_EXTRA_HEADER > > > >>> select SPL_SEPARATE_BSS if SPL > > > >>> + select TIMER > > > >>> > > > >>> config TARGET_STV0991 > > > >>> bool "Support stv0991" > > > >>> diff --git a/arch/arm/mach-mvebu/include/mach/config.h > > > b/arch/arm/mach-mvebu/include/mach/config.h > > > >>> index 4add0d9e1030..9b5036c31dd3 100644 > > > >>> --- a/arch/arm/mach-mvebu/include/mach/config.h > > > >>> +++ b/arch/arm/mach-mvebu/include/mach/config.h > > > >>> @@ -41,9 +41,4 @@ > > > >>> #endif > > > >>> #endif > > > >>> > > > >>> -/* Use common timer */ > > > >>> -#define CONFIG_SYS_TIMER_COUNTS_DOWN > > > >>> -#define CONFIG_SYS_TIMER_COUNTER (MVEBU_TIMER_BASE + 0x14) > > > >>> -#define CONFIG_SYS_TIMER_RATE 2500 > > > >>> - > > > >>> #endif /* __MVEBU_CONFIG_H */ > > > >>> -- > > > >>> 2.37.3 > > > >>> > > > >> > > > >> I think this may have broken the 64-bit mvebu S
Re: [PATCH v3 4/8] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
On Mon, 7 Nov 2022, 7:23 PM Stefan Roese, wrote: > Hi Chris, > > On 05.11.22 05:08, Chris Packham wrote: > > On Sat, Nov 5, 2022 at 5:03 PM Chris Packham > wrote: > >> > >> Hi Stefan, > >> > >> On Fri, Sep 16, 2022 at 2:23 AM Stefan Roese wrote: > >>> > >>> Now that the new timer support is available for these platforms, let's > >>> select this IF for all these platforms. This way it's not necessary > >>> that each board changes it's config header. > >>> > >>> Signed-off-by: Stefan Roese > >>> Tested-by: Tony Dinh > >>> --- > >>> v3: > >>> - No change > >>> > >>> v2: > >>> - No change > >>> > >>> arch/arm/Kconfig | 4 > >>> arch/arm/mach-mvebu/include/mach/config.h | 5 - > >>> 2 files changed, 4 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > >>> index 82cd456f51f1..4ed100ab0ede 100644 > >>> --- a/arch/arm/Kconfig > >>> +++ b/arch/arm/Kconfig > >>> @@ -618,6 +618,7 @@ config ARCH_KIRKWOOD > >>> select BOARD_EARLY_INIT_F > >>> select CPU_ARM926EJS > >>> select GPIO_EXTRA_HEADER > >>> + select TIMER > >>> > >>> config ARCH_MVEBU > >>> bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" > >>> @@ -629,6 +630,8 @@ config ARCH_MVEBU > >>> select GPIO_EXTRA_HEADER > >>> select SPL_DM_SPI if SPL > >>> select SPL_DM_SPI_FLASH if SPL > >>> + select SPL_TIMER if SPL > >>> + select TIMER > >>> select OF_CONTROL > >>> select OF_SEPARATE > >>> select SPI > >>> @@ -639,6 +642,7 @@ config ARCH_ORION5X > >>> select CPU_ARM926EJS > >>> select GPIO_EXTRA_HEADER > >>> select SPL_SEPARATE_BSS if SPL > >>> + select TIMER > >>> > >>> config TARGET_STV0991 > >>> bool "Support stv0991" > >>> diff --git a/arch/arm/mach-mvebu/include/mach/config.h > b/arch/arm/mach-mvebu/include/mach/config.h > >>> index 4add0d9e1030..9b5036c31dd3 100644 > >>> --- a/arch/arm/mach-mvebu/include/mach/config.h > >>> +++ b/arch/arm/mach-mvebu/include/mach/config.h > >>> @@ -41,9 +41,4 @@ > >>> #endif > >>> #endif > >>> > >>> -/* Use common timer */ > >>> -#define CONFIG_SYS_TIMER_COUNTS_DOWN > >>> -#define CONFIG_SYS_TIMER_COUNTER (MVEBU_TIMER_BASE + 0x14) > >>> -#define CONFIG_SYS_TIMER_RATE 2500 > >>> - > >>> #endif /* __MVEBU_CONFIG_H */ > >>> -- > >>> 2.37.3 > >>> > >> > >> I think this may have broken the 64-bit mvebu SoCs (at least reverting > >> it gets my AC5X series back to a working state). As far as I can tell > >> none of them have anything that would bring in any timer driver. > > > > The following seems to sort things out without the need for a revert > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 710f171f87..e8968d61cd 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -640,7 +640,7 @@ config ARCH_MVEBU > > select SPL_DM_SPI if SPL > > select SPL_DM_SPI_FLASH if SPL > > select SPL_TIMER if SPL > > - select TIMER > > + select TIMER if !ARM64 > > select OF_CONTROL > > select OF_SEPARATE > > select SPI > > > > I'll include it in the series I'm about to send. > > Thanks. Even though I wonder a bit that no other ARM64 Marvell user > stumbled over this yet. > Yeah I did wonder. I do have access to another less obscure Marvell board at $dayjob. I'll see if I can confirm whether it needs the same change or not. > Thanks, > Stefan >
[PATCH v6 6/6] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v6:
- Set CONFIG_DEFAULT_DEVICE_TREE and CONFIG_TEXT_BASE
Changes in v5:
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CPNFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +++
configs/mvebu_ac5_rd_defconfig | 81 +
include/configs/mvebu_alleycat-5.h | 42 +++
8 files changed, 284 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 791838733c..b52077cddc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -278,7 +278,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..d9f217cd4a
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ ethernet0 =
+ ethernet1 =
+ spi0 =
+ i2c0 =
+ i2c1 =
+ usb0 =
+ usb1 =
+ pinctrl
[PATCH v6 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
(no changes since v5)
Changes in v5:
- Minor fixup for checkpatch.pl complaint
Changes in v4:
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 ++
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
10 files changed, 745 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..3c68355f32
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = ;
+
[PATCH v6 3/6] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v5)
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 53 -
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 1aabe062fb..c750b0207d 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..6093c8fb0b 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,7 +149,7 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
@@ -136,6 +159,19 @@ static int ehci_mvebu_probe(struct udevice *dev)
(uintptr_t)hccr, (uintptr_t)hcor,
(uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ void *phy_calib_reg = (void *)(priv->hcd_base +
PHY_CALIB_OFFSET);
+ u32 val = readl(phy_calib_reg) & (~BIT(13));
+
+
[PATCH v6 4/6] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese --- (no changes since v4) Changes in v4: - Collect r-by from Stefan drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.38.1
[PATCH v6 2/6] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v3)
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, , , );
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, _args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.38.1
[PATCH v6 1/6] arm: mvebu: Don't use CONFIG_TIMER on ARM64
The 64-bit mvebu SoCs don't have a suitable timer driver so add a !ARM64
condition to the select.
Fixes: 7b530bb19e ("arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD
platforms")
Signed-off-by: Chris Packham
---
(no changes since v1)
arch/arm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 453bef900e..7866e8f3c4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -640,7 +640,7 @@ config ARCH_MVEBU
select SPL_DM_SPI if SPL
select SPL_DM_SPI_FLASH if SPL
select SPL_TIMER if SPL
- select TIMER
+ select TIMER if !ARM64
select OF_CONTROL
select OF_SEPARATE
select SPI
--
2.38.1
[PATCH v6 0/6] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X
which was based on u-boot 2018.03. I've split that code into consumable
chunks and dropped as much unnecessary stuff as I can. I've also tried
to sync the device trees as much as possible with the support that will
land in Linux 6.0 although there are still some differences
Changes in v6:
- Set CONFIG_DEFAULT_DEVICE_TREE and CONFIG_TEXT_BASE
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
- Minor fixup for checkpatch.pl complaint
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CPNFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Collect r-by from Stefan
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
Chris Packham (6):
arm: mvebu: Don't use CONFIG_TIMER on ARM64
net: mvneta: Add support for AlleyCat5
usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
pinctrl: mvebu: Add AlleyCat5 support
arm: mvebu: Support for 98DX25xx/98DX35xx SoC
arm: mvebu: Add RD-AC5X board
arch/arm/Kconfig | 2 +-
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 13 +-
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 +
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +
configs/mvebu_ac5_rd_defconfig | 81 ++
drivers/net/Kconfig| 2 +-
drivers/net/mvneta.c | 43 ++-
drivers/pinctrl/mvebu/Kconfig | 2 +-
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-marvell.c| 53 +++-
include/configs/mvebu_alleycat-5.h | 42 +++
23 files changed, 1120 insertions(+), 14 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
--
2.38.1
Re: [PATCH v3 4/8] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
On Sat, Nov 5, 2022 at 5:03 PM Chris Packham wrote: > > Hi Stefan, > > On Fri, Sep 16, 2022 at 2:23 AM Stefan Roese wrote: > > > > Now that the new timer support is available for these platforms, let's > > select this IF for all these platforms. This way it's not necessary > > that each board changes it's config header. > > > > Signed-off-by: Stefan Roese > > Tested-by: Tony Dinh > > --- > > v3: > > - No change > > > > v2: > > - No change > > > > arch/arm/Kconfig | 4 > > arch/arm/mach-mvebu/include/mach/config.h | 5 - > > 2 files changed, 4 insertions(+), 5 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > > index 82cd456f51f1..4ed100ab0ede 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -618,6 +618,7 @@ config ARCH_KIRKWOOD > > select BOARD_EARLY_INIT_F > > select CPU_ARM926EJS > > select GPIO_EXTRA_HEADER > > + select TIMER > > > > config ARCH_MVEBU > > bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" > > @@ -629,6 +630,8 @@ config ARCH_MVEBU > > select GPIO_EXTRA_HEADER > > select SPL_DM_SPI if SPL > > select SPL_DM_SPI_FLASH if SPL > > + select SPL_TIMER if SPL > > + select TIMER > > select OF_CONTROL > > select OF_SEPARATE > > select SPI > > @@ -639,6 +642,7 @@ config ARCH_ORION5X > > select CPU_ARM926EJS > > select GPIO_EXTRA_HEADER > > select SPL_SEPARATE_BSS if SPL > > + select TIMER > > > > config TARGET_STV0991 > > bool "Support stv0991" > > diff --git a/arch/arm/mach-mvebu/include/mach/config.h > > b/arch/arm/mach-mvebu/include/mach/config.h > > index 4add0d9e1030..9b5036c31dd3 100644 > > --- a/arch/arm/mach-mvebu/include/mach/config.h > > +++ b/arch/arm/mach-mvebu/include/mach/config.h > > @@ -41,9 +41,4 @@ > > #endif > > #endif > > > > -/* Use common timer */ > > -#define CONFIG_SYS_TIMER_COUNTS_DOWN > > -#define CONFIG_SYS_TIMER_COUNTER (MVEBU_TIMER_BASE + 0x14) > > -#define CONFIG_SYS_TIMER_RATE 2500 > > - > > #endif /* __MVEBU_CONFIG_H */ > > -- > > 2.37.3 > > > > I think this may have broken the 64-bit mvebu SoCs (at least reverting > it gets my AC5X series back to a working state). As far as I can tell > none of them have anything that would bring in any timer driver. The following seems to sort things out without the need for a revert diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 710f171f87..e8968d61cd 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -640,7 +640,7 @@ config ARCH_MVEBU select SPL_DM_SPI if SPL select SPL_DM_SPI_FLASH if SPL select SPL_TIMER if SPL - select TIMER + select TIMER if !ARM64 select OF_CONTROL select OF_SEPARATE select SPI I'll include it in the series I'm about to send.
Re: [PATCH v3 4/8] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms
Hi Stefan, On Fri, Sep 16, 2022 at 2:23 AM Stefan Roese wrote: > > Now that the new timer support is available for these platforms, let's > select this IF for all these platforms. This way it's not necessary > that each board changes it's config header. > > Signed-off-by: Stefan Roese > Tested-by: Tony Dinh > --- > v3: > - No change > > v2: > - No change > > arch/arm/Kconfig | 4 > arch/arm/mach-mvebu/include/mach/config.h | 5 - > 2 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 82cd456f51f1..4ed100ab0ede 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -618,6 +618,7 @@ config ARCH_KIRKWOOD > select BOARD_EARLY_INIT_F > select CPU_ARM926EJS > select GPIO_EXTRA_HEADER > + select TIMER > > config ARCH_MVEBU > bool "Marvell MVEBU family (Armada XP/375/38x/3700/7K/8K)" > @@ -629,6 +630,8 @@ config ARCH_MVEBU > select GPIO_EXTRA_HEADER > select SPL_DM_SPI if SPL > select SPL_DM_SPI_FLASH if SPL > + select SPL_TIMER if SPL > + select TIMER > select OF_CONTROL > select OF_SEPARATE > select SPI > @@ -639,6 +642,7 @@ config ARCH_ORION5X > select CPU_ARM926EJS > select GPIO_EXTRA_HEADER > select SPL_SEPARATE_BSS if SPL > + select TIMER > > config TARGET_STV0991 > bool "Support stv0991" > diff --git a/arch/arm/mach-mvebu/include/mach/config.h > b/arch/arm/mach-mvebu/include/mach/config.h > index 4add0d9e1030..9b5036c31dd3 100644 > --- a/arch/arm/mach-mvebu/include/mach/config.h > +++ b/arch/arm/mach-mvebu/include/mach/config.h > @@ -41,9 +41,4 @@ > #endif > #endif > > -/* Use common timer */ > -#define CONFIG_SYS_TIMER_COUNTS_DOWN > -#define CONFIG_SYS_TIMER_COUNTER (MVEBU_TIMER_BASE + 0x14) > -#define CONFIG_SYS_TIMER_RATE 2500 > - > #endif /* __MVEBU_CONFIG_H */ > -- > 2.37.3 > I think this may have broken the 64-bit mvebu SoCs (at least reverting it gets my AC5X series back to a working state). As far as I can tell none of them have anything that would bring in any timer driver.
Re: [PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
On Thu, Nov 3, 2022 at 9:29 AM Chris Packham wrote: > > On Thu, Nov 3, 2022 at 2:40 AM Stefan Roese wrote: > > > > Hi Chris, > > > > On 22.09.22 05:31, Chris Packham wrote: > > > The RD-AC5X-32G16HVG6HLG-A0 development board main components and > > > features include: > > > * Main 12V/54V power supply > > > * 270 Gbps throughput packet processor on the main board > > > * DDR4: > > >* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs) > > >* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs) > > >* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement > > > * 16GB eMMC (Samsung KLMAG1JETD-B041006) > > > * 16MB SPI NOR(GD25Q127C) > > > * 32 x 1000 Base-T interfaces > > > * 16 x 2500 Base-T interfaces > > >* SR1: 88E2540*4 > > >* SR2: 88E2580*1+88E2540*2 > > > * Six (6) x 25G Base-R SFP28 interfaces > > > * One (1) x RJ-45 console connector, interfacing to the on board UART > > > * One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0) > > > * One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1) > > > * One (1) x RJ-45 1G Base-T Management port, interfacing to the host > > >port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy > > > * One (1) x Oculink port, interfacing to the PCIe port for external CPU > > >connection > > > * POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ > > >Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 > > >solution) > > > * POE total power budget 780W > > > * LED interfaces per network port/POE > > > * LED interfaces (common) showing system status > > > * PTP TC mode Supported (Reserved M.2 connector to support BC mode) > > > > > > Signed-off-by: Chris Packham > > > --- > > > > > > Changes in v4: > > > - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to > > >the defconfig. > > > - Remove CONFIG_BAUDRATE as this is already set in the default config > > > - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with > > >DM_USB > > > - Remove CONFIG_PREBOOT as we don't have anything to run > > > - Remove commented out CONFIG_BOARD_EARLY_INIT_R > > > - Remove DEBUG_UART configuration > > > - Remove unnecessary console environment variable > > > - Remove CONFIG_MVEBU_SAR > > > > > > Changes in v3: > > > - Remove MMC and UBIFS distroboot options (MMC driver is not currently > > >functional, NAND is not populated on the RD-AC5X board) > > > - Remove unnecessary Ethernet configuration > > > - Remove unnecessary NAND configuration > > > - Remove memory node from dts so the value passed by the DDR FW will be > > >used > > > > > > Changes in v2: > > > - Use distro boot by default > > > - remove unnecessary SPI-NOR partitions > > > > > > arch/arm/dts/Makefile | 3 +- > > > arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + > > > arch/arm/mach-mvebu/Kconfig| 9 +- > > > board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + > > > board/Marvell/mvebu_alleycat-5/Makefile| 3 + > > > board/Marvell/mvebu_alleycat-5/board.c | 28 + > > > configs/mvebu_ac5_rd_defconfig | 84 ++ > > > include/configs/mvebu_alleycat-5.h | 42 +++ > > > 8 files changed, 302 insertions(+), 2 deletions(-) > > > create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts > > > create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS > > > create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile > > > create mode 100644 board/Marvell/mvebu_alleycat-5/board.c > > > create mode 100644 configs/mvebu_ac5_rd_defconfig > > > create mode 100644 include/configs/mvebu_alleycat-5.h > > > > While running a CI build I run into these issues: > > > > CONFIG_SYS_TEXT_BASE is now renamed to CONFIG_TEXT_BASE. I've already > > fixes this locally. But now I also get this compilation error: > > > > [stefan@ryzen u-boot-marvell (master)]$ make -sj > > > > Device Tree Source (arch/arm/dts/unset.dtb) is not correctly specified. > > Please define 'CONFIG_DEFAULT_DEVICE_TREE' > > or build with 'DEVICE_TREE=' argument > > > > make[1]: *** [dts/Makefile:34: arch/arm/dts/unset.dtb] Error 1 >
Re: [PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
On Thu, Nov 3, 2022 at 2:40 AM Stefan Roese wrote: > > Hi Chris, > > On 22.09.22 05:31, Chris Packham wrote: > > The RD-AC5X-32G16HVG6HLG-A0 development board main components and > > features include: > > * Main 12V/54V power supply > > * 270 Gbps throughput packet processor on the main board > > * DDR4: > >* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs) > >* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs) > >* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement > > * 16GB eMMC (Samsung KLMAG1JETD-B041006) > > * 16MB SPI NOR(GD25Q127C) > > * 32 x 1000 Base-T interfaces > > * 16 x 2500 Base-T interfaces > >* SR1: 88E2540*4 > >* SR2: 88E2580*1+88E2540*2 > > * Six (6) x 25G Base-R SFP28 interfaces > > * One (1) x RJ-45 console connector, interfacing to the on board UART > > * One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0) > > * One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1) > > * One (1) x RJ-45 1G Base-T Management port, interfacing to the host > >port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy > > * One (1) x Oculink port, interfacing to the PCIe port for external CPU > >connection > > * POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ > >Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 > >solution) > > * POE total power budget 780W > > * LED interfaces per network port/POE > > * LED interfaces (common) showing system status > > * PTP TC mode Supported (Reserved M.2 connector to support BC mode) > > > > Signed-off-by: Chris Packham > > --- > > > > Changes in v4: > > - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to > >the defconfig. > > - Remove CONFIG_BAUDRATE as this is already set in the default config > > - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with > >DM_USB > > - Remove CONFIG_PREBOOT as we don't have anything to run > > - Remove commented out CONFIG_BOARD_EARLY_INIT_R > > - Remove DEBUG_UART configuration > > - Remove unnecessary console environment variable > > - Remove CONFIG_MVEBU_SAR > > > > Changes in v3: > > - Remove MMC and UBIFS distroboot options (MMC driver is not currently > >functional, NAND is not populated on the RD-AC5X board) > > - Remove unnecessary Ethernet configuration > > - Remove unnecessary NAND configuration > > - Remove memory node from dts so the value passed by the DDR FW will be > >used > > > > Changes in v2: > > - Use distro boot by default > > - remove unnecessary SPI-NOR partitions > > > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + > > arch/arm/mach-mvebu/Kconfig| 9 +- > > board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + > > board/Marvell/mvebu_alleycat-5/Makefile| 3 + > > board/Marvell/mvebu_alleycat-5/board.c | 28 + > > configs/mvebu_ac5_rd_defconfig | 84 ++ > > include/configs/mvebu_alleycat-5.h | 42 +++ > > 8 files changed, 302 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts > > create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS > > create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile > > create mode 100644 board/Marvell/mvebu_alleycat-5/board.c > > create mode 100644 configs/mvebu_ac5_rd_defconfig > > create mode 100644 include/configs/mvebu_alleycat-5.h > > While running a CI build I run into these issues: > > CONFIG_SYS_TEXT_BASE is now renamed to CONFIG_TEXT_BASE. I've already > fixes this locally. But now I also get this compilation error: > > [stefan@ryzen u-boot-marvell (master)]$ make -sj > > Device Tree Source (arch/arm/dts/unset.dtb) is not correctly specified. > Please define 'CONFIG_DEFAULT_DEVICE_TREE' > or build with 'DEVICE_TREE=' argument > > make[1]: *** [dts/Makefile:34: arch/arm/dts/unset.dtb] Error 1 > make: *** [Makefile:1162: dts/dt.dtb] Error 2 > > So where is CONFIG_DEFAULT_DEVICE_TREE defined? I might have overlooked > this. > Ah. Because these arm64 SoCs need other components in the "bootloader" I've been using a meta build system that passes DEVICE_TREE= on the make command line. I'll rebase the series and add fixup CONFIG_TEXT_BASE/CONFIG_DEFAULT_DEVICE_TREE. > Thanks, > Stefan > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 96
[PATCH v5 5/5] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v5:
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CONFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +++
configs/mvebu_ac5_rd_defconfig | 80 +
include/configs/mvebu_alleycat-5.h | 42 +++
8 files changed, 283 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..d9f217cd4a
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ ethernet0 =
+ ethernet1 =
+ spi0 =
+ i2c0 =
+ i2c1 =
+ usb0 =
+ usb1 =
+ pinctrl0 =
+ sar-reg0 = "/config-space/sar-reg";
+
[PATCH v5 4/5] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v5:
- Minor fixup for checkpatch.pl complaint
Changes in v4:
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 ++
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
10 files changed, 745 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..3c68355f32
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = ;
+
[PATCH v5 3/5] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese --- (no changes since v4) Changes in v4: - Collect r-by from Stefan drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v5 2/5] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 53 -
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..6093c8fb0b 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,7 +149,7 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
@@ -136,6 +159,19 @@ static int ehci_mvebu_probe(struct udevice *dev)
(uintptr_t)hccr, (uintptr_t)hcor,
(uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ void *phy_calib_reg = (void *)(priv->hcd_base +
PHY_CALIB_OFFSET);
+ u32 val = readl(phy_calib_reg) & (~BIT(13));
+
+ w
[PATCH v5 1/5] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v3)
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, , , );
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, _args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v5 0/5] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X
which was based on u-boot 2018.03. I've split that code into consumable
chunks and dropped as much unnecessary stuff as I can. I've also tried
to sync the device trees as much as possible with the support that will
land in Linux 6.0 although there are still some differences
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
- Minor fixup for checkpatch.pl complaint
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CONFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Collect r-by from Stefan
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
Chris Packham (5):
net: mvneta: Add support for AlleyCat5
usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
pinctrl: mvebu: Add AlleyCat5 support
arm: mvebu: Support for 98DX25xx/98DX35xx SoC
arm: mvebu: Add RD-AC5X board
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 13 +-
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 +
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +
configs/mvebu_ac5_rd_defconfig | 80 ++
drivers/net/Kconfig| 2 +-
drivers/net/mvneta.c | 43 ++-
drivers/pinctrl/mvebu/Kconfig | 2 +-
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-marvell.c| 53 +++-
include/configs/mvebu_alleycat-5.h | 42 +++
22 files changed, 1118 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
--
2.37.3
Re: [PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
On Thu, Sep 22, 2022 at 5:10 PM Stefan Roese wrote: > > On 22.09.22 05:31, Chris Packham wrote: > > The RD-AC5X-32G16HVG6HLG-A0 development board main components and > > features include: > > * Main 12V/54V power supply > > * 270 Gbps throughput packet processor on the main board > > * DDR4: > >* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs) > >* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs) > >* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement > > * 16GB eMMC (Samsung KLMAG1JETD-B041006) > > * 16MB SPI NOR(GD25Q127C) > > * 32 x 1000 Base-T interfaces > > * 16 x 2500 Base-T interfaces > >* SR1: 88E2540*4 > >* SR2: 88E2580*1+88E2540*2 > > * Six (6) x 25G Base-R SFP28 interfaces > > * One (1) x RJ-45 console connector, interfacing to the on board UART > > * One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0) > > * One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1) > > * One (1) x RJ-45 1G Base-T Management port, interfacing to the host > >port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy > > * One (1) x Oculink port, interfacing to the PCIe port for external CPU > >connection > > * POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ > >Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 > >solution) > > * POE total power budget 780W > > * LED interfaces per network port/POE > > * LED interfaces (common) showing system status > > * PTP TC mode Supported (Reserved M.2 connector to support BC mode) > > > > Signed-off-by: Chris Packham > > --- > > > > Changes in v4: > > - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to > >the defconfig. > > - Remove CONFIG_BAUDRATE as this is already set in the default config > > - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with > >DM_USB > > - Remove CONFIG_PREBOOT as we don't have anything to run > > - Remove commented out CONFIG_BOARD_EARLY_INIT_R > > - Remove DEBUG_UART configuration > > - Remove unnecessary console environment variable > > - Remove CONFIG_MVEBU_SAR > > > > Changes in v3: > > - Remove MMC and UBIFS distroboot options (MMC driver is not currently > >functional, NAND is not populated on the RD-AC5X board) > > - Remove unnecessary Ethernet configuration > > - Remove unnecessary NAND configuration > > - Remove memory node from dts so the value passed by the DDR FW will be > >used > > > > Changes in v2: > > - Use distro boot by default > > - remove unnecessary SPI-NOR partitions > > > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + > > arch/arm/mach-mvebu/Kconfig| 9 +- > > board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + > > board/Marvell/mvebu_alleycat-5/Makefile| 3 + > > board/Marvell/mvebu_alleycat-5/board.c | 28 + > > configs/mvebu_ac5_rd_defconfig | 84 ++ > > include/configs/mvebu_alleycat-5.h | 42 +++ > > 8 files changed, 302 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts > > create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS > > create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile > > create mode 100644 board/Marvell/mvebu_alleycat-5/board.c > > create mode 100644 configs/mvebu_ac5_rd_defconfig > > create mode 100644 include/configs/mvebu_alleycat-5.h > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 965895bc2a..57a5272884 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \ > > cn9132-db-A.dtb \ > > cn9132-db-B.dtb \ > > cn9130-crb-A.dtb\ > > - cn9130-crb-B.dtb > > + cn9130-crb-B.dtb\ > > + ac5-98dx35xx-rd.dtb > > endif > > > > dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb > > diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts > > b/arch/arm/dts/ac5-98dx35xx-rd.dts > > new file mode 100644 > > index 00..d9f217cd4a > > --- /dev/null > > +++ b/arch/arm/dts/ac5-98dx35xx-rd.dts > > @@ -0,0 +1,129 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) > > +/* &
Re: [PATCH v4 2/5] usb: ehci: ehci-marvell: Support for marvell, ac5-ehci
On Thu, Sep 22, 2022 at 5:18 PM Stefan Roese wrote:
>
> On 22.09.22 05:31, Chris Packham wrote:
> > Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
> > block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
> > the fact that the ac5 does not have the mbus infrastructure the 32-bit
> > SoCs have and ensure USB_EHCI_IS_TDI is selected.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > drivers/usb/host/Kconfig| 1 +
> > drivers/usb/host/ehci-marvell.c | 57 +++--
> > 2 files changed, 48 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index a0f48f09a7..628078f495 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
> > depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
> > default y
> > select USB_EHCI_IS_TDI if !ARM64
> > + select USB_EHCI_IS_TDI if ALLEYCAT_5
> > ---help---
> > Enables support for the on-chip EHCI controller on MVEBU SoCs.
> >
> > diff --git a/drivers/usb/host/ehci-marvell.c
> > b/drivers/usb/host/ehci-marvell.c
> > index b7e60c690a..7d859b9cce 100644
> > --- a/drivers/usb/host/ehci-marvell.c
> > +++ b/drivers/usb/host/ehci-marvell.c
> > @@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
> > fdt_addr_t hcd_base;
> > };
> >
> > +#define USB_TO_DRAM_TARGET_ID 0x2
> > +#define USB_TO_DRAM_ATTR_ID 0x0
> > +#define USB_DRAM_BASE 0x
> > +#define USB_DRAM_SIZE 0xfff /* don't overrun u-boot source (was 0x) */
> > +
> > /*
> >* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
> >* to the common mvebu archticture including the mbus setup, this
> >* will be the only function needed to configure the access windows
> >*/
> > -static void usb_brg_adrdec_setup(void *base)
> > +static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
> > {
> > const struct mbus_dram_target_info *dram;
> > int i;
> > @@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
> > writel(0, base + USB_WINDOW_BASE(i));
> > }
> >
> > - for (i = 0; i < dram->num_cs; i++) {
> > - const struct mbus_dram_window *cs = dram->cs + i;
> > + if (device_is_compatible(dev, "marvell,ac5-ehci")) {
> > + /*
> > + * use decoding window to map dram address seen by usb to 0x0
> > + */
> >
> > /* Write size, attributes and target id to control register */
> > - writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
> > -(dram->mbus_dram_target_id << 4) | 1,
> > -base + USB_WINDOW_CTRL(i));
> > + writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
> > +(USB_TO_DRAM_TARGET_ID << 4) | 1,
> > +base + USB_WINDOW_CTRL(0));
>
> Nitpicking / coding-style comment: Not aligned with the '(' in the
> line above. I assume that checkpatch.pl will complain here.
>
Doesn't seem to complain about this (ran manually and via patman).
I'll fix it regardless.
> >
> > /* Write base address to base register */
> > - writel(cs->base, base + USB_WINDOW_BASE(i));
> > + writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
> > +
> > + debug("## AC5 decoding windows, ctrl[%p]=0x%x,
> > base[%p]=0x%x\n",
> > + base + USB_WINDOW_CTRL(0), readl(base +
> > USB_WINDOW_CTRL(0)),
> > + base + USB_WINDOW_BASE(0), readl(base +
> > USB_WINDOW_BASE(0)));
> > + } else {
> > + for (i = 0; i < dram->num_cs; i++) {
> > + const struct mbus_dram_window *cs = dram->cs + i;
> > +
> > + /* Write size, attributes and target id to control
> > register */
> > + writel(((cs->size - 1) & 0x) | (cs->mbus_attr
> > << 8) |
> > +(dram->mbus_dram_target_id << 4) | 1,
> > +base + USB_WINDOW_CTRL(i));
> > +
> > + /* Write base address to base register */
> > + writel(cs->base, base + USB_
[PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v4:
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 28 +
configs/mvebu_ac5_rd_defconfig | 84 ++
include/configs/mvebu_alleycat-5.h | 42 +++
8 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..d9f217cd4a
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ ethernet0 =
+ ethernet1 =
+ spi0 =
+ i2c0 =
+ i2c1 =
+ usb0 =
+ usb1 =
+ pinctrl0 =
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8"
[PATCH v4 4/5] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v4:
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 ++
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
10 files changed, 745 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..3c68355f32
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = ;
+ reg-io-width = <1>;
+
[PATCH v4 3/5] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese --- Changes in v4: - Collect r-by from Stefan drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v4 2/5] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ void *phy_ca
[PATCH v4 1/5] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v3)
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, , , );
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, _args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v4 0/5] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Changes in v4: - Collect r-by from Stefan - Remove unused mvebu_get_nand_clock() (will return in a later series) - Remove unnecessary #ifdefs - Misc style cleanups - Replace CONFIG_MVEBU_SAR with simpler code implemented directly in soc.c based around get_sar_freq which the 32-bit platforms already use. - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to the defconfig. - Remove CONFIG_BAUDRATE as this is already set in the default config - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with DM_USB - Remove CONFIG_PREBOOT as we don't have anything to run - Remove commented out CONFIG_BOARD_EARLY_INIT_R - Remove DEBUG_UART configuration - Remove unnecessary console environment variable - Remove CONFIG_MVEBU_SAR Changes in v3: - Remove unnecessary changes to RX descriptor handling - Use dev_get_dma_range() to parse dma-ranges property from parent device. - Remove unnecessary dma-ranges property from ethernet nodes (mvneta now correctly parses the property from the parent node). - Keep soc_print_clock_info and soc_print_device_info local to alleycat5. - Remove MMC and UBIFS distroboot options (MMC driver is not currently functional, NAND is not populated on the RD-AC5X board) - Remove unnecessary Ethernet configuration - Remove unnecessary NAND configuration - Remove memory node from dts so the value passed by the DDR FW will be used Changes in v2: - Use distro boot by default - remove unnecessary SPI-NOR partitions Chris Packham (5): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++ arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 13 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 8 + arch/arm/mach-mvebu/alleycat5/cpu.c| 124 + arch/arm/mach-mvebu/alleycat5/soc.c| 298 + arch/arm/mach-mvebu/alleycat5/soc.h| 7 + arch/arm/mach-mvebu/arm64-common.c | 5 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 28 ++ configs/mvebu_ac5_rd_defconfig | 84 ++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 43 ++- drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 42 +++ 22 files changed, 1139 insertions(+), 15 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 include/configs/mvebu_alleycat-5.h -- 2.37.3
Re: [PATCH v3 6/6] arm: mvebu: Add RD-AC5X board
On Thu, Sep 22, 2022 at 9:55 AM Pali Rohár wrote:
>
> On Wednesday 21 September 2022 16:59:41 Chris Packham wrote:
> > diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts
> > b/arch/arm/dts/ac5-98dx35xx-rd.dts
> ...
> > +/ {
> > + model = "Marvell RD-AC5X Board";
> > + compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
> > +
> > + aliases {
> > + serial0 =
> ...
> > + };
> ...
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> ...
> > diff --git a/include/configs/mvebu_alleycat-5.h
> > b/include/configs/mvebu_alleycat-5.h
> ...
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> ...
> > + "console=console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000\0"\
>
> Hello! Is not this console=console= line suspicious?
>
> And also because default console device is selected by /chosen/stdout-path
> DT property and earlycon address is also parsed from DTS, I have feeling
> that specifying it on cmdline is just duplication of DTS.
>
> Try to boot your arm64 kernel with just "earlycon" string without
> specifying uart8250,mmio32... I think that it should work fine.
>
Yeah I think this is a relic. The original code had all kinds of magic
for manipulating bootargs that involved pulling in the console from
the environment. I think it can go as the default should come from the
DTS. Anything else is up to the user to configure bootargs
appropriately.
>
> I think that main issue here is that people just choose one board or
> config file, copy it and simple modify it and letting all those historic
> relict not needed in u-boot anymore. And due to this copy+paste stuff
> nobody knows what is needed, what not and nobody knows answer to
> important question "why it is there?".
>
> But I understand it. The best for developer is to take something which
> works and do just simple modification for specific board to achieve
> functionality. Doing more modification or trying to understand if there
> is not unnecessary code consume lot of time which people do not have...
>
> (nothing wrong; just I'm reading code and trying to understand it what
> it is doing or why it is there... and detect possible dead code patterns
> :-))
I think you're right to point it out. I encounter the same thing all
the time at $dayjob and try to push back against the blind
copy-pasting so I should really know better (there is an amount of
rebase fatigue from porting the old code).
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Thu, Sep 22, 2022 at 9:40 AM Pali Rohár wrote:
>
> On Thursday 22 September 2022 09:25:37 Chris Packham wrote:
> > On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
> > >
> > > On 21.09.22 06:59, Chris Packham wrote:
> > > > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > > > an integrated CPU (referred to as the CnM block in Marvell's
> > > > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > > > has been ported from Marvell's SDK which is based on a much older
> > > > version of U-Boot.
> > > >
> > > > Signed-off-by: Chris Packham
> > > > ---
> > > >
> >
> >
> >
> > > > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > > > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > > > new file mode 100644
> > > > index 00..f388d4ee40
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> >
> >
> >
> > > > +int soc_early_init_f(void)
> > > > +{
> > > > +#ifdef CONFIG_MVEBU_SAR
> > > > +/* Sample at reset register init */
> > > > + mvebu_sar_init();
> > > > +#endif
> > >
> > > Won't CONFIG_MVEBU_SAR always be enabled? Remove the #ifdef in this
> > > case.
> > >
> > > > + return 0;
> > > > +}
> >
> > Currently it is possible to turn it off. As I've said I think I do
> > need to look at the whole SAR business and see if it can be done
> > differently.
> >
> > One useful thing it does do is tell me about how the hardware has been
> > strapped. U-Boot itself doesn't care about that specifically as the
> > separate mv_ddr blob that runs before ATF is the thing that actually
> > uses the SAR values. But U-
> > Boot is the first place that can give me some friendly output about
> > the board and knowing the CPU/DDR clock speed is useful at that level.
>
> I agree that the last thing - print information about CPU/DDR clock
> speed is useful [1]. But I do not see reason why to complicate it such
> much via new uclass OOP model for other things in DTS, which moreover
> use already deprecated structure and requires hack in fdtdec.c file.
>
Agreed. The fact that I can turn the driver off and (after fixing some
code that calls into it directly) everything still works (except for
the reporting of the clock speeds) it does indicate that I don't
really need this.
> I think that the whole SAR code can be simplified and written
> straightforward for AC5 to be easier for developer to read... but this
> step is not probably such simple as it is required to first understand
> what is this "complicated" code doing and it is probably boring job :-(
Not boring but it doesn't help that Marvell don't document the SAR
registers so I can only go by following their overly complicated code.
>
> For 32-bit Armada there is already very simple SAR register handling to
> check and detect TCLK speed. So I think AC5 is similar in this area, but
> more has more complicated code logic and "very simple 32-bit SAR" is not
> suitable to reuse.
>
I think I can come up with something that replaces the sar-uclass
business with code that just accesses the relevant register(s)
directly in the alleycat5/soc.c code.
>
> [1] - Btw, I added this print in A3720 secure firmware, because it is
> really useful and important (!) and secure firmware is who configures it
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
>
> On 21.09.22 06:59, Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > new file mode 100644
> > index 00..f388d4ee40
> > --- /dev/null
> > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> > +int soc_early_init_f(void)
> > +{
> > +#ifdef CONFIG_MVEBU_SAR
> > +/* Sample at reset register init */
> > + mvebu_sar_init();
> > +#endif
>
> Won't CONFIG_MVEBU_SAR always be enabled? Remove the #ifdef in this
> case.
>
> > + return 0;
> > +}
Currently it is possible to turn it off. As I've said I think I do
need to look at the whole SAR business and see if it can be done
differently.
One useful thing it does do is tell me about how the hardware has been
strapped. U-Boot itself doesn't care about that specifically as the
separate mv_ddr blob that runs before ATF is the thing that actually
uses the SAR values. But U-
Boot is the first place that can give me some friendly output about
the board and knowing the CPU/DDR clock speed is useful at that level.
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
>
> On 21.09.22 06:59, Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > new file mode 100644
> > index 00..f388d4ee40
> > --- /dev/null
> > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> > +/* Return NAND clock in Hz */
> > +u32 mvebu_get_nand_clock(void)
> > +{
> > + return 200 * 100;
> > +}
>
> Is this still needed?
>
It will be needed eventually. After I get this landed I'll start work
on getting our board upstreamed and that does make use of the NAND
interface. There are some NAND driver changes that go along with this
so I'll move this over into that patch series.
[PATCH v3 6/6] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features
include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host port
(shared with PCIe)
Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48
(Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 135 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 35 ++
configs/mvebu_ac5_rd_defconfig | 88 ++
include/configs/mvebu_alleycat-5.h | 57 +
8 files changed, 334 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..7f1c8a5e22
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ ethernet0 =
+ ethernet1 =
+ spi0 =
+ i2c0 =
+ i2c1 =
+ usb0 =
+ usb1 =
+ pinctrl0 =
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ config-space {
+ sar-reg {
+ reg = <0x944F8204 0x1>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ phy-handle = <>;
+};
+
+/* USB0 is a host USB */
[PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 290 +
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
arch/arm/mach-mvebu/alleycat5/clock.c | 49 +
arch/arm/mach-mvebu/alleycat5/clock.h | 11 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 129 +++
arch/arm/mach-mvebu/alleycat5/soc.c| 229 +++
arch/arm/mach-mvebu/alleycat5/soc.h| 6 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
12 files changed, 754 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.h
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..64516938e8
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <>;
+ };
+ core1 {
+ cpu = <>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ config-space {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ sar-reg {
+ compatible = "marvell,sample-at-reset-common";
+ sar-driver = "ac5_sar";
+ sar-name = "ac5_sar";
+ status = "okay";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-c
[PATCH v3 4/6] misc: mvebu: Add sample at reset driver
Add a new UCLASS_SAR, the generic SAR code and an Alleycat5 driver. This
has been adapted from the Marvell SDK but only the AC5 driver has been
brought through (other drivers exist for the ap806, ap807 and cp110 IP
blocks).
Signed-off-by: Chris Packham
---
Changes in v3:
- None. Note some changes related to this have been requested and will
be looked into I just wanted to get v3 out so the other changes could
be reviewed.
drivers/misc/Kconfig| 6 ++
drivers/misc/Makefile | 1 +
drivers/misc/mvebu_sar/Makefile | 4 +
drivers/misc/mvebu_sar/ac5_sar.c| 119 +++
drivers/misc/mvebu_sar/sar-uclass.c | 146
include/dm/uclass-id.h | 1 +
include/fdtdec.h| 4 +
include/mvebu/mvebu_chip_sar.h | 73 ++
include/mvebu/sar.h | 57 +++
include/mvebu/var.h | 28 ++
include/sar-uclass.h| 23 +
lib/fdtdec.c| 6 +-
12 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/mvebu_sar/Makefile
create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c
create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c
create mode 100644 include/mvebu/mvebu_chip_sar.h
create mode 100644 include/mvebu/sar.h
create mode 100644 include/mvebu/var.h
create mode 100644 include/sar-uclass.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a6da6e215d..4e99ef29d9 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -645,4 +645,10 @@ config SL28CPLD
the base driver which provides common access methods for the
sub-drivers.
+config MVEBU_SAR
+ bool "MVEBU SAR driver"
+ depends on ARCH_MVEBU
+ help
+ Support MVEBU SAR driver
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d494639cd9..3cf976edd8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o
obj-$(CONFIG_P2SB) += p2sb-uclass.o
obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
+obj-$(CONFIG_MVEBU_SAR) += mvebu_sar/
ifdef CONFIG_QFW
obj-y += qfw.o
obj-$(CONFIG_QFW_PIO) += qfw_pio.o
diff --git a/drivers/misc/mvebu_sar/Makefile b/drivers/misc/mvebu_sar/Makefile
new file mode 100644
index 00..6f339fb7b4
--- /dev/null
+++ b/drivers/misc/mvebu_sar/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_MVEBU_SAR) += sar-uclass.o
+obj-$(CONFIG_ALLEYCAT_5) += ac5_sar.o
diff --git a/drivers/misc/mvebu_sar/ac5_sar.c b/drivers/misc/mvebu_sar/ac5_sar.c
new file mode 100644
index 00..67b2110bc8
--- /dev/null
+++ b/drivers/misc/mvebu_sar/ac5_sar.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MHz100
+
+#define BIT_VAL(b) ((1ULL << ((b) + 1)) - 1)
+#define BIT_RANGE(Bl, Bh) (BIT_VAL(Bh) - BIT_VAL((Bl) - 1))
+
+#define PLL_MAX_CHOICE 4
+
+#define CPU_TYPE_AC50
+#define CPU_TYPE_AC5x 1
+#define CPU_TYPE_LAST 2
+
+static const u32 pll_freq_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ +
1][PLL_MAX_CHOICE] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1400 * MHz, 1000 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 396 * MHz, 290 * MHz, 197 * MHz, 0
+ },
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1500 * MHz, 1600 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 0, 0, 0, 0
+ }
+ }
+};
+
+static const u32 soc_sar_masks_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ + 1] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(18, 20),
+ [SAR_DDR_FREQ] = BIT_RANGE(16, 17),
+ [SAR_AP_FABRIC_FREQ] = BIT_RANGE(22, 23),
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(8, 10),
+ [SAR_DDR_FREQ] = BIT_RANGE(6, 7),
+ [SAR_AP_FABRIC_FREQ] = 1,
+ },
+};
+
+static int ac5_sar_value_get(struct udevice *dev, enum mvebu_sar_opts sar_opt,
+struct sar_val *val)
+{
+ u32 *pSarBase = (u32 *)(((struct dm_sar_pdata
*)dev_get_priv(dev))->sar_base);
+ u32 sar_reg_val = readl(pSarBase);
+ u32 mask;
+ unsigned char choice;
+ int cpu_type = ((readl(0x7f90004c) & 0xFF000) >>
[PATCH v3 3/6] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham --- (no changes since v1) drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v3 2/6] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(>cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(>cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ void *phy_ca
[PATCH v3 1/6] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, , , );
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, _args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v3 0/6] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Changes in v3: - Remove unnecessary changes to RX descriptor handling - Use dev_get_dma_range() to parse dma-ranges property from parent device. - None. Note some changes related to this have been requested and will be looked into I just wanted to get v3 out so the other changes could be reviewed. - Remove unnecessary dma-ranges property from ethernet nodes (mvneta now correctly parses the property from the parent node). - Keep soc_print_clock_info and soc_print_device_info local to alleycat5. - Remove MMC and UBIFS distroboot options (MMC driver is not currently functional, NAND is not populated on the RD-AC5X board) - Remove unnecessary Ethernet configuration - Remove unnecessary NAND configuration - Remove memory node from dts so the value passed by the DDR FW will be used Changes in v2: - Use distro boot by default - remove unnecessary SPI-NOR partitions Chris Packham (6): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support misc: mvebu: Add sample at reset driver arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 290 + arch/arm/dts/ac5-98dx35xx-rd.dts | 135 ++ arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 13 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 9 + arch/arm/mach-mvebu/alleycat5/clock.c | 49 arch/arm/mach-mvebu/alleycat5/clock.h | 11 + arch/arm/mach-mvebu/alleycat5/cpu.c| 129 + arch/arm/mach-mvebu/alleycat5/soc.c| 229 arch/arm/mach-mvebu/alleycat5/soc.h| 6 + arch/arm/mach-mvebu/arm64-common.c | 5 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 35 +++ configs/mvebu_ac5_rd_defconfig | 88 +++ drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/mvebu_sar/Makefile| 4 + drivers/misc/mvebu_sar/ac5_sar.c | 119 + drivers/misc/mvebu_sar/sar-uclass.c| 146 +++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 43 ++- drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 57 include/dm/uclass-id.h | 1 + include/fdtdec.h | 4 + include/mvebu/mvebu_chip_sar.h | 73 ++ include/mvebu/sar.h| 57 include/mvebu/var.h| 28 ++ include/sar-uclass.h | 23 ++ lib/fdtdec.c | 6 +- 36 files changed, 1647 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.h create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 drivers/misc/mvebu_sar/Makefile create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c create mode 100644 include/configs/mvebu_alleycat-5.h create mode 100644 include/mvebu/mvebu_chip_sar.h create mode 100644 include/mvebu/sar.h create mode 100644 include/mvebu/var.h create mode 100644 include/sar-uclass.h -- 2.37.3
Re: [PATCH v2 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Tue, Sep 20, 2022 at 9:22 PM Pali Rohár wrote:
>
> On Tuesday 20 September 2022 20:31:52 Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/ac5-98dx25xx.dtsi | 292 +++
> > arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
> > arch/arm/mach-mvebu/Kconfig | 5 +
> > arch/arm/mach-mvebu/Makefile | 1 +
> > arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
> > arch/arm/mach-mvebu/alleycat5/clock.c| 49
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 129 ++
> > arch/arm/mach-mvebu/alleycat5/soc.c | 229 ++
> > arch/arm/mach-mvebu/arm64-common.c | 15 ++
> > arch/arm/mach-mvebu/include/mach/clock.h | 11 +
> > arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
> > arch/arm/mach-mvebu/include/mach/soc.h | 4 +
> > 12 files changed, 765 insertions(+)
> > create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
> > create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
> > create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h
> >
> ...
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index a81b8e2b0d..400a308985 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -49,6 +49,11 @@ config ARMADA_8K
> > bool
> > select ARM64
> >
> > +config ALLEYCAT_5
> > + bool
> > + select ARM64
> > + select HAVE_MVEBU_EFUSE
>
> Hello! You are not adding any efuse implementation for AC5 platform,
> so selecting this symbol seems to be wrong.
>
> Or are you reusing A3720 or A38x OTP implementation for AC5? This is not
> clear from the patch.
>
The original code did have some EFUSE stuff in it but I've dropped
most of it out. I think this can go.
> > +
> > # Armada PLL frequency (used for NAND clock generation)
> > config SYS_MVEBU_PLL_CLOCK
> > int
> ...
> > diff --git a/arch/arm/mach-mvebu/arm64-common.c
> > b/arch/arm/mach-mvebu/arm64-common.c
> > index 238edbe6ba..c9b6f16c63 100644
> > --- a/arch/arm/mach-mvebu/arm64-common.c
> > +++ b/arch/arm/mach-mvebu/arm64-common.c
> > @@ -53,6 +53,8 @@ __weak int dram_init_banksize(void)
> > return a8k_dram_init_banksize();
> > else if (CONFIG_IS_ENABLED(ARMADA_3700))
> > return a3700_dram_init_banksize();
> > + else if (CONFIG_IS_ENABLED(ALLEYCAT_5))
> > + return alleycat5_dram_init_banksize();
> > else
> > return fdtdec_setup_memory_banksize();
> > }
> > @@ -68,6 +70,9 @@ __weak int dram_init(void)
> > if (CONFIG_IS_ENABLED(ARMADA_3700))
> > return a3700_dram_init();
> >
> > + if (CONFIG_IS_ENABLED(ALLEYCAT_5))
> > + return alleycat5_dram_init();
> > +
> > if (fdtdec_setup_mem_size_base() != 0)
> > return -EINVAL;
> >
> > @@ -100,6 +105,16 @@ int arch_early_init_r(void)
> > break;
> > }
> >
> > + i = 0;
> > + while (1) {
> > + /* Call the pinctrl code via the PINCTRL uclass driver */
> > + ret = uclass_get_device(UCLASS_PINCTRL, i++, );
> > +
> > + /* We're done, once no further CP110 device is found */
> > + if (ret)
> > + break;
> > + }
>
> This code is unconditionally called for all 64-bit mvebu platforms, not
> only for new AC5. So if this is some fix, it should be in separate
> commit. If not then it should be marked AC5 specific and explained why.
>
Yeah I can't see why it's needed. The pinctrl device still gets probed
without it so I suspect it's just old cruft left over from a time that
wasn't the case.
> > +
> > /* Cause the SATA device to do its early init */
> > uclass_first_device(UCLASS_AHCI, );
> >
> > diff --git a/arch/arm/mach-mv
Re: [PATCH v2 1/6] net: mvneta: Add support for AlleyCat5
On Tue, Sep 20, 2022 at 10:48 PM Pali Rohár wrote:
>
> On Tuesday 20 September 2022 20:31:48 Chris Packham wrote:
> > diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
> > index d2c42c4396..07919d6d35 100644
> > --- a/drivers/net/mvneta.c
> > +++ b/drivers/net/mvneta.c
> > @@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define MVNETA_WIN_SIZE_MASK (0x)
> > #define MVNETA_BASE_ADDR_ENABLE 0x2290
> > #define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
> > +#define MVNETA_AC5_CNM_DDR_TARGET 0x2
> > +#define MVNETA_AC5_CNM_DDR_ATTR 0xb
> > #define MVNETA_PORT_ACCESS_PROTECT 0x2294
> > #define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW 0x3
> > #define MVNETA_PORT_CONFIG 0x2400
> > @@ -282,6 +284,8 @@ struct mvneta_port {
> > struct gpio_desc phy_reset_gpio;
> > struct gpio_desc sfp_tx_disable_gpio;
> > #endif
> > +
> > + uintptr_t dma_base; /* base address for DMA address decoding */
> > };
> >
> > /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > @@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct
> > mvneta_port *pp,
> > static struct mvneta_rx_desc *
> > mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > {
> > + struct mvneta_rx_desc *curr;
> > int rx_desc = rxq->next_desc_to_proc;
> >
> > + /* validate RX descriptor */
> > + curr = rxq->descs + rx_desc;
> > + if (curr->data_size == 0) {
> > + /* do it to read real descriptor next time */
> > + DSB;
> > + return NULL;
> > + }
> > +
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > - return rxq->descs + rx_desc;
> > + return curr;
> > }
>
> Hello! This change looks like some fix, and not related to AC5 support.
> So it should be in separate patch as it affects all mvneta platforms,
> not only AC5.
>
Yep. I'll see if I can get away without this change for the AC5X. So
I'll either move it to a new patch or remove it completely in the next
round.
> > @@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >*/
> > rx_desc = mvneta_rxq_next_desc_get(rxq);
> >
> > + if (!rx_desc)
> > + return 0;
> > +
> > rx_status = rx_desc->status;
> > if (!mvneta_rxq_desc_is_first_last(rx_status) ||
> > (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
> > mvneta_rx_error(pp, rx_desc);
> > - /* leave the descriptor untouched */
> > + /* invalidate the descriptor */
> > + rx_desc->data_size = 0;
> > return -EIO;
> > }
>
> ditto.
>
> > @@ -1525,13 +1565,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >* No cache invalidation needed here, since the rx_buffer's
> > are
> >* located in a uncached memory region
> >*/
> > - *packetp = data;
> > + *packetp = data + pp->dma_base;
> >
> > /*
> >* Only mark one descriptor as free
> >* since only one was processed
> >*/
> > mvneta_rxq_desc_num_update(pp, rxq, 1, 1);
> > + /* invalidate the descriptor */
> > + rx_desc->data_size = 0;
>
> ditto.
>
> > }
> >
> > return rx_bytes;
> > @@ -1544,6 +1586,11 @@ static int mvneta_probe(struct udevice *dev)
> > struct ofnode_phandle_args sfp_args;
> > #endif
> > void *bd_space;
> > + void *blob = (void *)gd->fdt_blob;
> > + int node = dev_of_offset(dev);
> > + const int *cell;
> > + int len;
> > +
> >
> > /*
> >* Allocate buffer area for descs and rx_buffers. This is only
> > @@ -1577,9 +1624,21 @@ static int mvneta_probe(struct udevice *dev)
> > /* Configure MBUS address windows */
> > if (device_is_compatible(dev, "marvell,armada-3700-neta"))
> > mvneta_bypass_mbus_windows(pp);
> > + else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
> > + mvneta_conf_ac5_cnm_xbar_windows(pp);
> >
Re: [PATCH v2 1/6] net: mvneta: Add support for AlleyCat5
On Tue, Sep 20, 2022 at 9:17 PM Stefan Roese wrote:
>
> On 20.09.22 10:31, Chris Packham wrote:
> > Add support for the AlleyCat5 SoC. This lacks the mbus from the other
> > users of the mvneta.c driver so a new compatible string is needed to
> > allow for a different window configuration.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > drivers/net/Kconfig | 2 +-
> > drivers/net/mvneta.c | 66 ++--
> > 2 files changed, 64 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 6bbbadc5ee..8df3dce6df 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -448,7 +448,7 @@ config MVGBE
> >
> > config MVNETA
> > bool "Marvell Armada XP/385/3700 network interface support"
> > - depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
> > + depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
> > select PHYLIB
> > select DM_MDIO
> > help
> > diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
> > index d2c42c4396..07919d6d35 100644
> > --- a/drivers/net/mvneta.c
> > +++ b/drivers/net/mvneta.c
> > @@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define MVNETA_WIN_SIZE_MASK(0x)
> > #define MVNETA_BASE_ADDR_ENABLE 0x2290
> > #define MVNETA_BASE_ADDR_ENABLE_BIT0x1
> > +#define MVNETA_AC5_CNM_DDR_TARGET 0x2
> > +#define MVNETA_AC5_CNM_DDR_ATTR 0xb
> > #define MVNETA_PORT_ACCESS_PROTECT 0x2294
> > #define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW 0x3
> > #define MVNETA_PORT_CONFIG 0x2400
> > @@ -282,6 +284,8 @@ struct mvneta_port {
> > struct gpio_desc phy_reset_gpio;
> > struct gpio_desc sfp_tx_disable_gpio;
> > #endif
> > +
> > + uintptr_t dma_base; /* base address for DMA address decoding */
> > };
> >
> > /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > @@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct
> > mvneta_port *pp,
> > static struct mvneta_rx_desc *
> > mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > {
> > + struct mvneta_rx_desc *curr;
> > int rx_desc = rxq->next_desc_to_proc;
> >
> > + /* validate RX descriptor */
> > + curr = rxq->descs + rx_desc;
> > + if (curr->data_size == 0) {
> > + /* do it to read real descriptor next time */
> > + DSB;
> > + return NULL;
> > + }
> > +
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > - return rxq->descs + rx_desc;
> > + return curr;
> > }
> >
> > /* Tx descriptors helper methods */
> > @@ -1343,6 +1356,29 @@ static void mvneta_conf_mbus_windows(struct
> > mvneta_port *pp)
> > mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
> > }
> >
> > +static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
> > +{
> > + int i;
> > +
> > + /* Clear all windows */
> > + for (i = 0; i < 6; i++) {
> > + mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
> > + mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
> > +
> > + if (i < 4)
> > + mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
> > + }
> > +
> > + /*
> > + * Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
> > 0xb, size 4GB
> > + * AMB2 address decoder remaps 0x0 to DDR 64 bit base address
> > + */
> > + mvreg_write(pp, MVNETA_WIN_BASE(0),
> > + (MVNETA_AC5_CNM_DDR_ATTR << 8) |
> > MVNETA_AC5_CNM_DDR_TARGET);
> > + mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
> > + mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
> > +}
> > +
> > /* Power up the port */
> > static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
> > {
> > @@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >*/
> > rx_desc = mvneta_rxq_next_desc_get(rxq);
> >
> > + if (!rx_desc)
> > + return 0;
> > +
> > rx_status = rx_desc->status;
> > if (!mvneta_rxq_
[PATCH v2 6/6] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features
include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host port
(shared with PCIe)
Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48
(Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 140 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 35 ++
configs/mvebu_ac5_rd_defconfig | 88 +
include/configs/mvebu_alleycat-5.h | 71 +++
8 files changed, 353 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7330121dba..a334596ada 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..3b747e722e
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 =
+ spiflash0 =
+ gpio0 =
+ gpio1 =
+ ethernet0 =
+ ethernet1 =
+ spi0 =
+ i2c0 =
+ i2c1 =
+ usb0 =
+ usb1 =
+ pinctrl0 =
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x2 0x 0x0 0x4000>;
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ config-space {
+ sar-reg {
+ reg = <0x944F8204 0x1>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ phy-handle = <>;
+};
+
+/* USB0 is a host USB */
+ {
+ status = "okay";
+};
+
+/* USB1 is a peripheral USB */
+ {
+ status = "okay";
+ phys = <>;
+ phy-names = &q
