]> git.baikalelectronics.ru Git - uboot.git/commit
armv8: start.S: remove CONFIG_SYS_RESET_SCTRL code
authorAndre Przywara <andre.przywara@arm.com>
Mon, 24 Jan 2022 17:17:40 +0000 (17:17 +0000)
committerTom Rini <trini@konsulko.com>
Thu, 3 Feb 2022 17:15:37 +0000 (12:15 -0500)
commit4e1b4ea6689ed1aa9450bdc5033f7c4945e8474c
tree7f4b44cb13be02fbb0b154e18fbefb7da0a7ab53
parentc9bc8e2973ac5e1d785b8226d23c482e22d68fe9
armv8: start.S: remove CONFIG_SYS_RESET_SCTRL code

There is some code that tries to "reset" the SCTLR_ELx register early in
the boot process. The idea seems to be to guarantee some sane settings
that U-Boot actually relies on, for instance running in little-endian
mode, with the MMU off initially.
However the current code has multiple problems:
- For a start, no platform or config defines the symbol that would
  enable that code.
- The code itself really only works if the bits that it tries to clear
  are already cleared:
  - If we run in big-endian mode initially, any previous loads would have
    been wrong already. That applies to the (optional) relocation code,
    but more prominently to the mask that it uses to clear those bits:
    "ldr x1, =0xfdfffffa" looks innocent, but actually involves a memory
    access to the literal pool, using the current endianness.
  - If we run with the MMU enabled, we are probably doomed already. We
    *could* hope that we are running with an identity mapping, but would
    need to do some cache maintenance to avoid losing dirty cache lines.
- The idea of doing a read-modify-write of SCTLR is somewhat
  questionable to begin with, because as the owner of the current
  exception level we should initialise all bits of this register with a
  certain fixed value.
- The code is unnecessarily complicated, and the function name is
  misspelled.

While those problems *could* admittedly be fixed, the point that is does
not seem to be used at all at the moment tells me we should just remove
this code, and be it to not give a bad example.

If people care, I could introduce some proper SCTLR initialisation code.
We are about to work this out for the boot-wrapper[1] as we speak, but
apparently we got away without doing this in U-Boot ever since, so it
might not be worth the potential trouble.

[1] https://lore.kernel.org/linux-arm-kernel/20220114105653.3003399-7-mark.rutland@arm.com/

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
arch/arm/cpu/armv8/start.S