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