All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gregory CLEMENT <gregory.clement@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2 3/7] MSCC: add support for Ocelot SoCs
Date: Fri, 30 Nov 2018 15:48:50 +0100	[thread overview]
Message-ID: <87sgzimxil.fsf@bootlin.com> (raw)
In-Reply-To: <0da90b4c-40a3-8565-c98f-647bb791f82b@gmail.com> (Daniel Schwierzeck's message of "Sun, 28 Oct 2018 19:50:20 +0100")

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.

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

  reply	other threads:[~2018-11-30 14:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09 11:58 [U-Boot] [PATCH v2 0/7] Add support for the SoCs found in Microsemi switches Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 1/7] MIPS: move create_tlb() in an proper header: mipsregs.h Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 2/7] MIPS: Allow to prefetch and lock instructions into cache Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 3/7] MSCC: add support for Ocelot SoCs Gregory CLEMENT
2018-10-28 18:50   ` Daniel Schwierzeck
2018-11-30 14:48     ` Gregory CLEMENT [this message]
2018-10-09 11:58 ` [U-Boot] [PATCH v2 4/7] MSCC: add support for Luton SoCs Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 5/7] MSCC: add board support for the Ocelots based evaluation boards Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 6/7] MSCC: add board support for the Luton based evaluation board Gregory CLEMENT
2018-10-09 11:58 ` [U-Boot] [PATCH v2 7/7] MIPS: bootm: Add support for Vcore III linux kernel Gregory CLEMENT
2018-10-28 17:54   ` Daniel Schwierzeck
2018-11-30 14:16     ` Gregory CLEMENT

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87sgzimxil.fsf@bootlin.com \
    --to=gregory.clement@bootlin.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.