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

[Stefan Roese]

Hi Daniel,

On 06.06.20 07:25, Stefan Roese wrote:
> 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?

Again, can I assist with some of your tasks? I really would like to see
the base Octeon support appear in mainline U-Boot in the upcoming
merge window. Please see below.

>> 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.

Do you have some guidance for me on this? How should we continue here?
Can I help with the Linux header sync or start.S refactoring? Did you
start with this work already or do you have a rough schedule?

Sorry for being so persistent on this. I really don't want to rush
you, but as mentioned above, I really would like to see at least the
Octeon base port in mainline U-Boot in the next merge window. And if
there is something that I can do to help you, then please let me know.

Thanks,
Stefan