On Tue, May 13, 2014 at 08:55:17PM -0500, Rob Herring wrote:
On Mon, May 5, 2014 at 10:26 AM, Tom Rini trini@ti.com wrote:
The default format for arm64 Linux kernels is the "Image" format, described in Documentation/arm64/booting.txt. This, along with an optional gzip compression on top is all that is generated by default. The Image format has a magic number within the header for verification, a text_offset where the Image must be run from and reserved fields.
This does not support automatic detection of a gzip compressed image.
Signed-off-by: Tom Rini trini@ti.com
README | 1 + common/cmd_bootm.c | 139 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 140 insertions(+)
diff --git a/README b/README index 12758dc..e7c8b2e 100644 --- a/README +++ b/README @@ -946,6 +946,7 @@ The following options need to be configured: CONFIG_CMD_BMP * BMP support CONFIG_CMD_BSP * Board specific commands CONFIG_CMD_BOOTD bootd
CONFIG_CMD_BOOTI * ARM64 Linux kernel Image supportAs I mentioned at ELC, I would prefer to see bootz and booti combined so we have a single "boot a plain kernel image" command. I'd rather see the command be smart enough to figure what the image is rather than the user have to figure out the right command. Of course with this argument, then everything should be a bootm command. IIRC, there would be some challenges to add bootz or booti functionality into bootm.
Yes, this is an idea worth exploring.
CONFIG_CMD_CACHE * icache, dcache CONFIG_CMD_CLK * clock command support CONFIG_CMD_CONSOLE coninfodiff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index c243a5b..3b9635c 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -1929,3 +1929,142 @@ U_BOOT_CMD( "boot Linux zImage image from memory", bootz_help_text ); #endif /* CONFIG_CMD_BOOTZ */
+#ifdef CONFIG_CMD_BOOTI +/* See Documentation/arm64/booting.txt in the Linux kernel */ +struct Image_header {
uint32_t code0; /* Executable code */uint32_t code1; /* Executable code */uint64_t text_offset; /* Image load offset */uint64_t res0; /* reserved */uint64_t res1; /* reserved */uint64_t res2; /* reserved */uint64_t res3; /* reserved */uint64_t res4; /* reserved */uint32_t magic; /* Magic number */uint32_t res5;+};
+#define LINUX_ARM64_IMAGE_MAGIC 0x644d5241 +/* XXX: Hack 16MB image size for now */ +#define HACK_ARM64_IMAGE_SIZE (16 << 20)
+static int booti_setup(bootm_headers_t *images) +{
struct Image_header *ih;uint64_t dst;ih = (struct Image_header *)map_sysmem(images->ep, 0);if (ih->magic != LINUX_ARM64_IMAGE_MAGIC) {puts("Bad Linux ARM64 Image magic!\n");return 1;}/** If we are not at the correct run-time location, set the new* correct location and then move the image there.*/dst = gd->bd->bi_dram[0].start + ih->text_offset;if (images->ep != dst) {void *src;debug("Moving Image from 0x%lx to 0x%llx\n", images->ep, dst);src = (void *)images->ep;images->ep = dst;memmove((void *)dst, src, HACK_ARM64_IMAGE_SIZE);Don't you at least know the load size or the decompressed size? Only the .bss size is missing and you only need that to have some checks for overlapping images.
No, we don't know for certain what the size is today. For example, my workflow is to load the kernel, load the dtb so filesize would have had the Image size, but then we've overwritten it. Since this information will be part of the header, so long as it's merged into the kernel soon I'm OK with saying at least this part of the series is just for RFC and people can apply it locally as needed. If we handled Image.gz we would know the decompress size but today I expect to handle Image.gz as a 2 step unzip and then booti. As I said in 0/4 I have some concern about doing it all as a single step, especially once randomized text offset happens (at least, depending on the range the offset could be within).