public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox