)]}'
{
  "commit": "b251f30ec00dd4beb7baf42963a026ea9bc165ca",
  "tree": "e7c580b842514178429dc5024ca4fd4a7673fb66",
  "parents": [
    "defc5b8f346ee14f6b0962a368c6a408194783c0"
  ],
  "author": {
    "name": "Gianfranco Valentino",
    "email": "gevalentino@fuchsia.infra.roller.google.com",
    "time": "Thu May 30 01:07:51 2024 +0000"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Wed May 29 18:08:54 2024 -0700"
  },
  "message": "[roll] Roll fuchsia [boot-mmu] Build driven boot page allocation\n\nInstead of hard coding the value, the number of allocated pages\nis determined based on the boot-mmu-config, which defines a preprocessor\nsymbol that is the upper bound on the kernel image size.\n\nThis allows to change this estimation based on different build\ninformation, such as whether this is an instrumented build or not.\n\nThe values uses for the image size are obtained from the addressable\nsizes that the current number of preallocatd pages can address. For\ninstrumentation we just used the value of riscv64 which caused failures\ndue to not having enough pages, and boosted it by 25% (20 -\u003e 25MB).\n\nAs a first step, physboot will panic if the kernel size is bigger than\nthe max kernel image size. This allows having a direct cause to what\notherwise would have been observed as a hang from zircon.\n\nOriginal-Fixed: 339565993\nOriginal-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1045160\nOriginal-Revision: 738f5e0a26a636a8e6d679796535791df6c8b7db\nGitOrigin-RevId: d5ed1e5a3fc0b14ca3edaf422a2d274c4472ecdc\nChange-Id: I623e45307a1b6c4b68df3c5cd866cbcf23aae780\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "bcf519b6eae0d21f0a53d70b3af33c1901ac00f8",
      "old_mode": 33188,
      "old_path": "stem",
      "new_id": "8da7d1a82e6ba437efa01132e14a76beec90d1a4",
      "new_mode": 33188,
      "new_path": "stem"
    }
  ]
}