Hi Naman,
Just some pointers to make sure we don't try to pull in different directions:
Next up, was another hitch. During the build, ‘mmu_enable()’ and ‘arch_secondary_cpu_init()’ function calls are happening for all stages but the definitions for these functions are getting compiled only for ramstage. So this gave recurrent errors since the compiler couldn’t find these definitions. While attempting to sort this, I stumbled across something on the chromium tree. There was a patch which dealt with some of the issues, similar to mine. I had to cherry pick and apply this change.
That patch from the Exynos7 series was just a hack to get stuff working, it's not really solving anything. The whole stage_entry() code is still really screwed up, it shouldn't run all of that in every stage. We want to switch to a model where the MMU is only enabled once in the bootblock and then just stays on, being able to add new mappings later if necessary (similar to how ARMv7 works). A small start of that has happened with http://review.coreboot.org/10304 but there are still more issues to solve, unfortunately.
Another aspect in question is the bootblock initialisation. The src/arch/arm64/armv8/bootblock_simple.c calls for an appropriate bootblock_cpu_init(). This is another thing I will be working on in the coming days.
armv8/bootblock_simple.c and armv8/bootblock.S are currently completely broken (i.e. they may happen to work for you, but not as intended). They should instead look very similar to the armv7 code... a small assembly stub to initialize stack and caches, and the main bootblock function with all the advances that we've made to the ARMv7 model since they split (e.g. bootblock_cpu_init() should be renamed to bootblock_soc_init(), and it should be a normally linked function with a weak default implementation instead of that weird #including a whole .c file with CONFIG_BOOTBLOCK_CPU_INIT).
Sorry that everything's so broken and not moving faster.
-
Julius Werner -
WordPress