All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/6] MSCC: add support for VCoreIII SoCs
Date: Thu, 27 Sep 2018 13:57:14 +0200	[thread overview]
Message-ID: <20180927115714.GI16644@piout.net> (raw)
In-Reply-To: <875zyrdz7t.fsf@bootlin.com>

On 27/09/2018 12:14:14+0200, Gregory CLEMENT wrote:
> Hi Daniel,
> 
> First thanks for you prompt review, it is much appreciate. :)
> 
> This week I am at kernel recipes conference, so I won't be able to fully
> address your comments but I will do it next week.
> 
> However, here are some answers:
> 
>  On mer., sept. 26 2018, Daniel Schwierzeck <daniel.schwierzeck@gmail.com> wrote:
> 
> > Hi Gregory,
> >
> > On 25.09.2018 15:01, Gregory CLEMENT wrote:
> >> These families of SoCs are found in the Microsemi Switches solution.
> >> 
> >> Currently the support for two families support is added:
> >>  - Ocelot (VSC7513, VSC7514) already supported in Linux
> >>  - Luton (Luton10: VSC7423, VSC7424, VSC7428 and Luton26: VSC7425,
> >>    VSC7426, VSC7426, VSC7427, VSC7429)
> >
> > Is this some polished version of the original vendor U-Boot?
> 
> No the original vendor version was RedBoot
> 
> > Could you maybe add Ocelot and Luton in separate patches?
> 
> Yes sure the intent to have a uniq patch was to justify the common code
> between both SoC.
> 
> >
> >> 
> >> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
> >> ---
> [..]
> 
> >> +endif
> >
> > from the code below I assume you have a MIPS24k core? If so you should
> > use the automatic cache size detection
> 
> Yes it is a MIPS24k core. I will have a look on the automatic cache size
> detection.
> 
> >
> >> +
> >> +menu "MSCC VCore-III platforms"
> >> +	depends on ARCH_MSCC
> >> +
> >> +config SOC_VCOREIII
> >> +	select SUPPORTS_LITTLE_ENDIAN
> >> +	select SUPPORTS_BIG_ENDIAN
> >> +	select SUPPORTS_CPU_MIPS32_R1
> >> +	select SUPPORTS_CPU_MIPS32_R2
> >> +	select ROM_EXCEPTION_VECTORS
> >> +	select MIPS_TUNE_24KC
> >> +	bool
> >
> > sort this alpahetically
> 
> OK
> 
> >
> >> +
> [...]
> 
> >> +void vcoreiii_tlb_init(void)
> >> +{
> >> +        register int tlbix = 0;
> >> +
> >> +        init_tlb();
> >> +
> >> +        /* 0x70000000 size 32M (0x02000000) */
> >> +        create_tlb(tlbix++, MSCC_IO_ORIGIN1_OFFSET, SZ_16M, MMU_REGIO_RW, MMU_REGIO_RW);
> >> +#ifdef CONFIG_SOC_LUTON
> >> +	create_tlb(tlbix++, MSCC_IO_ORIGIN2_OFFSET, SZ_16M, MMU_REGIO_RW, MMU_REGIO_RW);
> >> +#endif
> >> +        /* 0x40000000 - 0x43ffffff - NON-CACHED! */
> >> +        /* Flash CS0-3, each 16M = 64M total (16 x 4 below )  */
> >> +        create_tlb(tlbix++, MSCC_FLASH_TO,        SZ_16M, MMU_REGIO_RO, MMU_REGIO_RO);
> >> +        create_tlb(tlbix++, MSCC_FLASH_TO+SZ_32M, SZ_16M, MMU_REGIO_RO, MMU_REGIO_RO);
> >> +
> >> +        /* 0x20000000 - up */
> >> +#if CONFIG_SYS_SDRAM_SIZE <= SZ_64M
> >> +        create_tlb(tlbix++, MSCC_DDR_TO,        SZ_64M,  MMU_REGIO_RW, MMU_REGIO_INVAL);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_128M
> >> +        create_tlb(tlbix++, MSCC_DDR_TO,        SZ_64M,  MMU_REGIO_RW, MMU_REGIO_RW);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_256M
> >> +        create_tlb(tlbix++, MSCC_DDR_TO,       SZ_256M,  MMU_REGIO_RW, MMU_REGIO_INVAL);
> >> +#elif CONFIG_SYS_SDRAM_SIZE <= SZ_512M
> >> +        create_tlb(tlbix++, MSCC_DDR_TO,       SZ_256M,  MMU_REGIO_RW, MMU_REGIO_RW);
> >> +#else  /* 1024M */
> >> +        create_tlb(tlbix++, MSCC_DDR_TO,       SZ_512M,  MMU_REGIO_RW, MMU_REGIO_RW);
> >> +#endif
> >
> > can't you leave that to the kernel? U-Boot is only running in kernel
> > mode and doesn't need MMU mappings.
> 
> You should be right, I will check it.
> 

At least MSCC_IO_ORIGIN1_OFFSET is necessary to get earlyprintk working
because the SoC registers are not in kseg0.

> >> +int mach_cpu_init(void)
> >> +{
> >> +        /* Speed up NOR flash access */
> >> +#ifdef CONFIG_SOC_LUTON
> >> +        writel(ICPU_SPI_MST_CFG_FAST_READ_ENA +
> >> +#else
> >> +	writel(
> >> +#endif
> >> +	       ICPU_SPI_MST_CFG_CS_DESELECT_TIME(0x19) +
> >> +               ICPU_SPI_MST_CFG_CLK_DIV(9), REG_CFG(ICPU_SPI_MST_CFG));
> >> +
> >> +        /* Disable all IRQs - map to destination map 0 */
> >> +        writel(0, REG_CFG(ICPU_INTR_ENA));
> >> +#ifdef CONFIG_SOC_OCELOT
> >> +        writel(~0, REG_CFG(ICPU_DST_INTR_MAP(0)));
> >> +        writel(0, REG_CFG(ICPU_DST_INTR_MAP(1)));
> >> +        writel(0, REG_CFG(ICPU_DST_INTR_MAP(2)));
> >> +        writel(0, REG_CFG(ICPU_DST_INTR_MAP(3)));
> >> +#else
> >> +	writel(ICPU_INTR_IRQ0_ENA_IRQ0_ENA, REG_CFG(ICPU_INTR_IRQ0_ENA));
> >> +#endif
> >
> > do you really need to disable interrupts after a cold or warm boot?
> 
> I think it is needed, but I will check.
> 

I would think this was done to avoid the spi driver crash. The interrupt
mapping should stay though.

> 
> >> +static inline void init_tlb(void)
> >> +{
> >> +    register int i, max;
> >> +
> >> +    max = get_tlb_count();
> >> +    for(i = 0; i < max; i++)
> >> +        create_tlb(i, i * SZ_1M, SZ_4K, MMU_REGIO_INVAL, MMU_REGIO_INVAL);
> >> +}
> >
> > again can't you leave the setup of MMU mappings to the kernel?
> 
> I will check again
> 

No, we need those mappings for earlyprintk and SoC detection. They are
needed to boot legacy kernels.


-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

  reply	other threads:[~2018-09-27 11:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 13:01 [U-Boot] [PATCH 0/6] Add support for VCore III SoCs found in Microsemi switches Gregory CLEMENT
2018-09-25 13:01 ` [U-Boot] [PATCH 1/6] MIPS: move create_tlb() in an proper header: mipsregs.h Gregory CLEMENT
2018-09-25 13:01 ` [U-Boot] [PATCH 3/6] MSCC: add board support for the VCoreIII based evaluation boards Gregory CLEMENT
2018-09-26 19:28   ` Daniel Schwierzeck
2018-10-09 11:22     ` Gregory CLEMENT
2018-09-26 23:03   ` Marek Vasut
2018-10-09 11:23     ` Gregory CLEMENT
2018-09-25 13:01 ` [U-Boot] [PATCH 4/6] MSCC: add device tree for Ocelot and Luton (boards and SoCs) Gregory CLEMENT
2018-09-26 19:31   ` Daniel Schwierzeck
2018-10-09 11:23     ` Gregory CLEMENT
2018-09-25 13:01 ` [U-Boot] [PATCH 5/6] MSCC: add configuration for Ocelot and Luton based boards Gregory CLEMENT
2018-09-26 19:31   ` Daniel Schwierzeck
2018-10-09 11:24     ` Gregory CLEMENT
2018-09-25 13:01 ` [U-Boot] [PATCH 6/6] MIPS: bootm: Add support for Vcore III linux kernel Gregory CLEMENT
2018-09-26 19:40   ` Daniel Schwierzeck
2018-10-09 11:28     ` Gregory CLEMENT
2018-09-25 15:22 ` [U-Boot] [PATCH 0/6] Add support for VCore III SoCs found in Microsemi switches Gregory CLEMENT
2018-09-25 15:25 ` [U-Boot] [PATCH 2/6] MSCC: add support for VCoreIII SoCs Gregory CLEMENT
     [not found] ` <20180925130108.19211-3-gregory.clement@bootlin.com>
2018-09-26 19:25   ` Daniel Schwierzeck
2018-09-27 10:14     ` Gregory CLEMENT
2018-09-27 11:57       ` Alexandre Belloni [this message]
2018-10-09 11:20     ` 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=20180927115714.GI16644@piout.net \
    --to=alexandre.belloni@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.