Hi Daniel,
On dim., oct. 28 2018, Daniel Schwierzeck daniel.schwierzeck@gmail.com wrote:
Am 09.10.18 um 13:58 schrieb Gregory CLEMENT:
This family of SoCs are found in the Microsemi Switches solution and have already a support in the linux kernel.
Signed-off-by: Gregory CLEMENT gregory.clement@bootlin.com
arch/mips/Kconfig | 6 + arch/mips/Makefile | 1 + arch/mips/mach-mscc/Kconfig | 69 ++ arch/mips/mach-mscc/Makefile | 5 + arch/mips/mach-mscc/cpu.c | 42 ++ arch/mips/mach-mscc/dram.c | 61 ++ arch/mips/mach-mscc/include/ioremap.h | 51 ++ arch/mips/mach-mscc/include/mach/common.h | 27 + arch/mips/mach-mscc/include/mach/ddr.h | 680 ++++++++++++++++++ .../mach-mscc/include/mach/ocelot/ocelot.h | 35 + .../include/mach/ocelot/ocelot_devcpu_gcb.h | 21 + .../include/mach/ocelot/ocelot_icpu_cfg.h | 274 +++++++ arch/mips/mach-mscc/include/mach/tlb.h | 55 ++ arch/mips/mach-mscc/lowlevel_init.S | 23 + arch/mips/mach-mscc/reset.c | 36 + 15 files changed, 1386 insertions(+) create mode 100644 arch/mips/mach-mscc/Kconfig create mode 100644 arch/mips/mach-mscc/Makefile create mode 100644 arch/mips/mach-mscc/cpu.c create mode 100644 arch/mips/mach-mscc/dram.c create mode 100644 arch/mips/mach-mscc/include/ioremap.h create mode 100644 arch/mips/mach-mscc/include/mach/common.h create mode 100644 arch/mips/mach-mscc/include/mach/ddr.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_devcpu_gcb.h create mode 100644 arch/mips/mach-mscc/include/mach/ocelot/ocelot_icpu_cfg.h create mode 100644 arch/mips/mach-mscc/include/mach/tlb.h create mode 100644 arch/mips/mach-mscc/lowlevel_init.S create mode 100644 arch/mips/mach-mscc/reset.c
there are still some style issues and checkpatch.pl warnings in all patches. Please fix.
Actually there was a lot of warning no relevant such as:
- the ones about the "line over 80 character" in the headers, but splitting the register definition in multiple line woul just make the file less readbale
- the ones about "please write a paragraph that describes the config symbol fully" fro the RAM choice, but the title give engough information.
- the ones about "Use of volatile is usually wrong", but here we really want to be sure that value will be really read from the memory that we are testing.
- the one about "Avoid CamelCase", here the rational is to use a small "t" in the naem of a register, as it make prefectly sens to use it to indicate time: VC3_MPAR_tXSRD
And in the middle of them there were a few real issues that I indeed missed and that I fixed now.
+/*
- DDR memory sanity checking failed, tally and do hard reset
- NB: Assumes inlining as no stack is available!
- */
+static inline void hal_vcoreiii_ddr_failed(void) +{
- register u32 reset;
- writel(readl(REG_CFG(ICPU_GPR(6))) + 1, REG_CFG(ICPU_GPR(6)));
- clrbits_le32(REG_GCB(PERF_GPIO_OE), BIT(19));
- /* Jump to reset - does not return */
- reset = KSEG0ADDR(_machine_restart);
- /* Reset while running from cache */
- icache_lock((void *)reset, 128);
- asm volatile ("jr %0"::"r" (reset));
why do you need to move to KSEG0 and to lock the cache line? Do you run the whole lowlevel code in KSEG1 space?
Yes the vector code of this platform is not located in KSEG0 actually it started at address 0x40000000 so in KUSEG.
Gregory
I guess the SoC maps the SPI flash to some executable buffer from where U-Boot is started. If the I-Cache works on this buffer, you could move your text base to KSEG0 space and run fully cached after I-Caches have been initialised.