[U-Boot] [PATCH v2 3/7] MSCC: add support for Ocelot SoCs

[Gregory CLEMENT]

Hi Daniel,
 
 On dim., oct. 28 2018, Daniel Schwierzeck <daniel.schwierzeck at 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 at 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.

-- 
Gregory Clement, Bootlin
Embedded Linux and Kernel engineering
http://bootlin.com