[PATCH v2 00/12] mips: Add initial Octeon MIPS64 base support

[Stefan Roese]

Hi Daniel,

On 05.06.20 17:40, Daniel Schwierzeck wrote:
> Hi Stefan,
> 
> sorry for the delay.
> 
> Am 02.06.20 um 12:59 schrieb Stefan Roese:
>> Hi Daniel,
>>
>> On 26.05.20 14:23, Stefan Roese wrote:
>>> Hi Daniel,
>>>
>>> On 14.05.20 11:59, Stefan Roese wrote:
>>>>
>>>> This patch adds very basic support for the Octeon III SoCs. Only CFI
>>>> parallel UART, reset and NOR flash are supported for now.
>>>>
>>>> Please note that the basic Octeon port does not include the DDR3/4
>>>> initialization yet. This will be added in some follow-up patches later.
>>>> To still use U-Boot on with this port, the L2 cache (4MiB on Octeon III
>>>> CN73xx) is used as RAM. This way, U-Boot can boot to the prompt on such
>>>> boards.
>>>>
>>>> Thanks,
>>>> Stefan
>>>>
>>>> Changes in v2:
>>>> - New patch
>>>> - New patch
>>>> - Restructure patch by adding empty functions to asm/cm.h instead
>>>> - New patch
>>>> - New patch
>>>> - Move bit macro definition to mipsregs.h
>>>> - Remove custom start.S and use common start.S. Minimal custom lowlevel
>>>>     init code is currently added in the custom lowlevel_init.S. This
>>>> needs
>>>>     to be extended with necessary code, like errata handling etc. But for
>>>>     a very first basic port, this seems to be all thats needed to boot on
>>>>     the EBB7304 to the prompt.
>>>> - Removed select CREATE_ARCH_SYMLINK
>>>> - Removed Octeon II support, as its currently no added in this patchset
>>>> - Added cache.c to add the platform specific cache functions as no-ops
>>>>     for Octeon as the platform is cache coherent
>>>> - Removed CONFIG_MIPS_CACHE_COHERENT
>>>> - Added CONFIG_CPU_CAVIUM_OCTEON to Kconfig and selected it for Octeon
>>>>     to enable better sync with the Linux files in the future
>>>> - Add get_tbclk() -> no need to define CONFIG_SYS_MIPS_TIMER_FREQ any
>>>> more
>>>> - Removed CONFIG_SYS_MIPS_TIMER_FREQ
>>>
>>> Daniel, do you have any comments and / or change requests to v2 of this
>>> base Octeon patchset?
>>
>> Sorry for triggering you again on this. Again my question, if you
>> have any comments on the latest patchet version.
>>
> 
> I've applied some patches which are ready.

Thanks.

> Actually I wanted to do a more complete header sync with Linux and
> submit some minimal refactorings of start.S so that you have a better
> working base. Unfortuneately I hadn't time to do so in the last 3 weeks.

I understand. Is there something I can help you with, to speed this
up?

> Regarding the copying to L2 cache: could we do this later and add the
> init stuff at first? So we could have functionality at first and then
> boot time optimization later. This also would give me some more time to
> refactor the start.S hooks which would give you a better base for
> implementing such optimizations.

IIUYC, then your main reason that I should remove the L2 cache copy
is, that you would like to refactor start.S first and add some hooks
for e.g. this L2C cache copy, where it would fit better than currently
in mips_sram_init(). I definitely promise to re-work this Octeon early
boot code to fit into your refactored start.S, once its ready. This
way, you wouldn't be pressed in time to get this rework done. And we
have a chance to get this Octeon base support integrated in a "decent"
state (bootup time, please see DDR4 init below) soon.

There are other reasons, beside the boot speedup, for the L2 cache
copy:

Running from L2 cache also helps with re-mapping the CFI flash
bootmap, so that the 8 MiB flash can be fully accessed. Otherwise
the flash is too big for the initial bootmap size and things like
environement can't be accessed.

The DDR init code that I'm currently working on - I'm actually
preparing the first patchset right now - is only tested with this
configration right now.

I'm also working on other peripheral drivers for Octeon. Some have
already started (like USB) and others are on my list. All this work
is pretty painful without the boot speedup, as e.g. the DDR4 init
will take very long (many minutes compared to a few seconds, as I've
been told).

But of course this is your call. If you insist on removing the L2 cache
copy from the base Octeon port, then I will re-visit the patchet and
try to address it.

Thanks,
Stefan