Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changeset accdbd8 in mainline


Ignore:
Timestamp:
2018-12-27T17:14:08Z (3 years ago)
Author:
Jakub Jermar <jakub@…>
Branches:
lfn, master
Children:
599a1c7, 6371eb47, 96e9434
Parents:
59564e6
Message:

Create mappings also for the kernel

If needed, create also dedicated mappings for the kernel with proper
memory region attributes. At the same time, stop making assumptions
about various mirrors of the physical memory and consider only the
layout of the physical address space.

This commit fixes boot on RaspberryPi which stopped working due to
the switch to LDREX/STREX-based atomics, which do not work in memory
regions with wrong attributes.

Tested on: RaspberryPi, GTA02, bbone, bbxm and Integrator/CP

File:
1 edited

Legend:

Unmodified
Added
Removed
  • boot/arch/arm32/src/mm.c

    r59564e6 raccdbd8  
    9999 *
    100100 * Memory areas used for I/O are excluded from caching.
    101  * At the moment caching is enabled only on GTA02.
    102101 *
    103102 * @param section       The section number.
     
    171170{
    172171        /*
    173          * Create 1:1 virtual-physical mapping.
    174          * Physical memory on BBxM a BBone starts at 2GB
    175          * boundary, icp has a memory mirror at 2GB.
    176          * (ARM Integrator Core Module User guide ch. 6.3,  p. 6-7)
    177          * gta02 somehow works (probably due to limited address size),
    178          * s3c2442b manual ch. 5, p.5-1:
    179          * "Address space: 128Mbytes per bank (total 1GB/8 banks)"
    180          */
    181         for (pfn_t page = 0; page < PTL0_ENTRIES; ++page)
    182                 init_ptl0_section(&boot_pt[page], page);
     172         * Our goal is to create page tables that serve two purposes:
     173         *
     174         * 1. Allow the loader to run in identity-mapped virtual memory and use
     175         *    I/O devices (e.g. an UART for logging).
     176         * 2. Allow the kernel to start running in virtual memory from addresses
     177         *    above 2G.
     178         *
     179         * The matters are slightly complicated by the different locations of
     180         * physical memory and I/O devices on the various boards that we
     181         * support. We see two cases (but other are still possible):
     182         *
     183         * a) Both RAM and I/O is in memory below 2G
     184         *    For instance, this is the case of GTA02, Integrator/CP
     185         *    and RaspberryPi
     186         * b) RAM starts at 2G and I/O devices are below 2G
     187         *    For example, this is the case of BeagleBone and BeagleBoard XM
     188         *
     189         * This leads to two possible setups of boot page tables:
     190         *
     191         * A) To arrange for a), split the virtual address space into two
     192         *    halves, both identity-mapping the first 2G of physical address
     193         *    space.
     194         * B) To accommodate b), create one larger virtual address space
     195         *    identity-mapping the entire physical address space.
     196         */
     197
     198        for (pfn_t page = 0; page < PTL0_ENTRIES; page++) {
     199                pfn_t frame = page;
     200                if (BOOT_BASE < 0x80000000UL && page >= PTL0_ENTRIES / 2)
     201                        frame -= PTL0_ENTRIES / 2;
     202                init_ptl0_section(&boot_pt[page], frame);
     203        }
    183204
    184205        /*
Note: See TracChangeset for help on using the changeset viewer.