Is it important that this go the "dedicated loader" route? It looks
like quite a bit of work to abstract out the functionality of the
"linux" and "initrd" commands in a way that enables reuse from other
commands.
----- Original Message -----
From: s...@shealevy.com
To:"The development of GNU GRUB" <grub-devel@gnu.org>
Cc:"Andrei Borzenkov" <arvidj...@gmail.com>
Sent:Wed, 27 Jan 2016 04:53:07 -0800
Subject:Re: [PATCH v2] Initial support for the android bootimg
filesystem.
The main reason was that it wasn't clear how to easily reuse the code
in the linux module to load the kernel and initrd; a secondary reason
is to allow overriding the kernel command line or whatever provided in
the bootimg. If there is a relatively straightforward path to fix the
first one, though, I'm happy to do that and figure out ways to
override later once the need actually arises, if ever.
~Shea
----- Original Message -----
From: "The development of GNU GRUB" <grub-devel@gnu.org>
To:"The development of GNU GRUB" <grub-devel@gnu.org>
Cc:"Shea Levy" <s...@shealevy.com>
Sent:Wed, 27 Jan 2016 10:22:34 +0300
Subject:Re: [PATCH v2] Initial support for the android bootimg
filesystem.
On Tue, Jan 26, 2016 at 10:42 PM, Shea Levy <s...@shealevy.com>
wrote:
> Currently, the kernel and, if present, the ramdisk are made
available as
> regular files.
...
> +
> +struct boot_img_hdr
> +{
> + uint8_t magic[BOOT_MAGIC_SIZE];
> +
> + uint32_t kernel_size;
> + uint32_t kernel_addr;
> +
> + uint32_t ramdisk_size;
> + uint32_t ramdisk_addr;
> +
> + uint32_t second_size;
> + uint32_t second_addr;
> +
> + uint32_t tags_addr;
> + uint32_t page_size;
> + uint32_t unused[2];
> +
> + uint8_t name[BOOT_NAME_SIZE];
> +
> + uint8_t cmdline[BOOT_ARGS_SIZE];
> +
> + uint32_t id[8];
> +
> + uint8_t extra_cmdline[BOOT_EXTRA_ARGS_SIZE];
> +} GRUB_PACKED;
> +
What is the use case for exposing it as filesystem in the first
place?
Dedicated android loader that reads them looks more logical.
Should this layout/content ever change in the future it will be near
to impossible to modify without breaking unknown number of users
relying on it; while simple
android hd1,msdos4
can transparently handle any forward and backward compatibility
without impacting existing grub.cfg.
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
