)]}'
{
  "commit": "94c2b6aff43cdfcfdfb552773a6b6b973a72ef0b",
  "tree": "a205528a4eb7cc1b1abcb27e69eae92349e1cada",
  "parents": [
    "df7131623daf4823e087eb1128f6c1c351519774"
  ],
  "author": {
    "name": "Paul Burton",
    "email": "paul.burton@imgtec.com",
    "time": "Fri Sep 06 13:57:44 2013 +0100"
  },
  "committer": {
    "name": "Aurelien Jarno",
    "email": "aurelien@aurel32.net",
    "time": "Mon Sep 09 18:42:22 2013 +0200"
  },
  "message": "mips_malta: support up to 2GiB RAM\n\nA Malta board can support up to 2GiB of RAM. Since the unmapped kseg0/1\nregions are only 512MiB large \u0026 the latter 256MiB of those are taken up\nby the IO region, access to RAM beyond 256MiB must be done through a\nmapped region. In the case of a Linux guest this means we need to use\nhighmem.\n\nThe mainline Linux kernel does not support highmem for Malta at this\ntime, however this can be tested using the linux-mti-3.8 kernel branch\navailable from:\n\n  git://git.linux-mips.org/pub/scm/linux-mti.git\n\nYou should be able to boot a Linux kernel built from the linux-mti-3.8\nbranch, with CONFIG_HIGHMEM enabled, using 2GiB RAM by passing \"-m 2G\"\nto QEMU and appending the following kernel parameters:\n\n  mem\u003d256m@0x0 mem\u003d256m@0x90000000 mem\u003d1536m@0x20000000\n\nNote that the upper half of the physical address space of a Malta\nmirrors the lower half (hence the 2GiB limit) except that the IO region\n(0x10000000-0x1fffffff in the lower half) is not mirrored in the upper\nhalf. That is, physical addresses 0x90000000-0x9fffffff access RAM\nrather than the IO region, resulting in a physical address space\nresembling the following:\n\n  0x00000000 -\u003e 0x0fffffff  RAM\n  0x10000000 -\u003e 0x1fffffff  I/O\n  0x20000000 -\u003e 0x7fffffff  RAM\n  0x80000000 -\u003e 0x8fffffff  RAM (mirror of 0x00000000 -\u003e 0x0fffffff)\n  0x90000000 -\u003e 0x9fffffff  RAM\n  0xa0000000 -\u003e 0xffffffff  RAM (mirror of 0x20000000 -\u003e 0x7fffffff)\n\nThe second mem parameter provided to the kernel above accesses the\nsecond 256MiB of RAM through the upper half of the physical address\nspace, making use of the aliasing described above in order to avoid\nthe IO region and use the whole 2GiB RAM.\n\nThe memory setup may be seen as \u0027backwards\u0027 in this commit since the\n\u0027real\u0027 memory is mapped in the upper half of the physical address space\nand the lower half contains the aliases. On real hardware it would be\ntypical to see the upper half of the physical address space as the alias\nsince the bus addresses generated match the lower half of the physical\naddress space. However since the memory accessible in the upper half of\nthe physical address space is uninterrupted by the IO region it is\neasiest to map the RAM as a whole there, and functionally it makes no\ndifference to the target code.\n\nDue to the requirements of accessing the second 256MiB of RAM through\na mapping to the upper half of the physical address space it is usual\nfor the bootloader to indicate a maximum of 256MiB memory to a kernel.\nThis allows kernels which do not support such access to boot on systems\nwith more than 256MiB of RAM. It is also the behaviour assumed by Linux.\nQEMUs small generated bootloader is modified to provide this behaviour.\n\nSigned-off-by: Paul Burton \u003cpaul.burton@imgtec.com\u003e\nSigned-off-by: Yongbok Kim \u003cyongbok.kim@imgtec.com\u003e\nReviewed-by: Aurelien Jarno \u003caurelien@aurel32.net\u003e\nSigned-off-by: Aurelien Jarno \u003caurelien@aurel32.net\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ae0921c6aadcee16b1b607a9462a0064de17e4a2",
      "old_mode": 33188,
      "old_path": "hw/mips/mips_malta.c",
      "new_id": "05c87712205e5e2a6436d054e9daece87393f1cb",
      "new_mode": 33188,
      "new_path": "hw/mips/mips_malta.c"
    }
  ]
}