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