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: Michael Zimmermann
Subject: Re: [PATCH v2] Initial support for the android bootimg filesystem.
Date: Fri, 29 Jan 2016 19:56:38 +0100

I think we should create a new loader(maybe separating common linux and android code into a lib) for this rather than a filesystem because it would simplify grub.cfg files.
Also in case we'll ever need to support 2ndloader(I'm like 99% sure this will never happen though) it would be easier to implement this in the android loader rather than adding another command for that.

On Fri, Jan 29, 2016 at 3:12 PM, Shea Levy <address@hidden> wrote:
On 2016-01-29 04:18, Andrei Borzenkov wrote:
On Fri, Jan 29, 2016 at 2:48 AM,  <address@hidden> wrote:
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.


"It needs work" is rather weak argument against doing something.

Actually it is not that much work, at least for initial
implementation. You could use "anonymous" files that are instantiated
on the fly (see verify command for example how to do it); that needs
minimal changes to linux/initrd to split out front end part that opens
files. All further processing would then be shared.


OK, will take this approach.



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

Dealing with stored command line on grub shell level is not simpler
due to fun with word splitting and quoting. Working with it in C would
be easier. But here again is the question if we can treat Android as
Linux. E.g. does Android support (or required to support) vga and mem
parameters? If not, this part is obviously redundant.


At least for android-x86 (the part I'm most familiar with), android is just a normal Linux as far as bootloading/command line is concerned.



Nothing prevents Android command from supporting extra kernel
arguments that override stored command line.

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

_______________________________________________
Grub-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel


_______________________________________________
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]