grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] Initial support for the android bootimg filesystem.


From: shea
Subject: Re: [PATCH v2] Initial support for the android bootimg filesystem.
Date: Thu, 28 Jan 2016 15:48:24 -0800

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:
address@hidden

To:
"The development of GNU GRUB" <address@hidden>
Cc:
"Andrei Borzenkov" <address@hidden>
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" <address@hidden>

To:
"The development of GNU GRUB" <address@hidden>
Cc:
"Shea Levy" <address@hidden>
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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]