MFC r290647, r292523, r292891:

  ARM: Improve robustness of locore_v6.S and fix errors.
  - boot page table is not allocated in data section, so must be
    cleared before use
  - map only one section (1 MB) for SOCDEV mapping (*)
  - DSB must be used for ensuring of finishing TLB operations
  - Invalidate BTB when appropriate

  Allow armv4/5 kernels to be loaded on any 2MB boundary, like armv6/7.

  This eliminates the reliance on PHYSADDR and KERNPHYSADDR compile-time
  symbols (except when the rom-copy code is enabled) by using the current
  PC and the assumption that the entry-point routine is in the first 1MB
  section of the text segment.

  Other cleanups done:

   - Reduce the initarm() stack size back to 2K.  It got increased to
     4 * 2K when this file was supporting multicore armv6, but that
     support is now in locore-v6.S.

   - When building the temporary startup page tables, map the entire
     4GB address space as VA=PA before mapping the kernel at its loaded
     location.  This allows access to boot parameters stored somewhere
     in ram by the bootloader, regardless of where that may be.

   - When building the page table entry for supporting EARLY_PRINTF, map
     the section as uncached unbuffered, since it is presumably device
     registers.

  Note that this restores the ability to use loader(8)/ubldr on armv4/5
  kernels.  That was broken in r283035, the point at which ubldr started
  loading an arm kernel at any 2MB boundary.

  Also note that after this, there is no reason to set KERNVIRTADDR to
  anything other than 0xc0000000, and no need for PHYSADDR or KERNPHYSADDR
  symbols at all.

  Bring some of the recent locore-v4.S improvements into locore-V6...

   - Map all 4GB as VA=PA so that args passed in from a bootloader can
     be accessed regardless of where they are.
   - Figure out the kernel load address by directly masking the PC rather
     then by doing pc-relative math on the _start symbol.
   - For EARLY_PRINTF support, map device memory as uncacheable (no-op for
     ARM_NEW_PMAP because all TEX types resolve to uncacheable).

0 files changed, 0 insertions, 0 deletions