From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gregory CLEMENT Date: Fri, 30 Nov 2018 15:48:50 +0100 Subject: [U-Boot] [PATCH v2 3/7] MSCC: add support for Ocelot SoCs In-Reply-To: <0da90b4c-40a3-8565-c98f-647bb791f82b@gmail.com> (Daniel Schwierzeck's message of "Sun, 28 Oct 2018 19:50:20 +0100") References: <20181009115838.21795-1-gregory.clement@bootlin.com> <20181009115838.21795-4-gregory.clement@bootlin.com> <0da90b4c-40a3-8565-c98f-647bb791f82b@gmail.com> Message-ID: <87sgzimxil.fsf@bootlin.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Daniel, On dim., oct. 28 2018, Daniel Schwierzeck 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 >> --- >> 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. -- Gregory Clement, Bootlin Embedded Linux and Kernel engineering http://bootlin.com