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: Fri, 29 Jan 2016 10:53:57 -0800

The bootimg contains a kernel, optional initrd, optional secondary payload (unused on x86 as far as I know), and kernel command line, as well as recommended load addresses for the kernel, initrd, secondary payload, and kernel tags (also unused on x86 as far as I know).

Making the linux command recognize it would be fine with me, if that is the preferred approach. Would we want to have the linux command load the kernel and the initrd load the ramdisk?

~Shea


----- Original Message -----
From:
"Vladimir 'phcoder' Serbinenko" <address@hidden>

To:
"The development of GNU GRUB" <address@hidden>
Cc:

Sent:
Fri, 29 Jan 2016 17:37:52 +0000
Subject:
Re: [PATCH v2] Initial support for the android bootimg filesystem.


I actually think that both approaches have pros and cons. Can we settle on a design before plunging forward? 
We should have feature parity between Android image and plain linux. I.a. it should be possible to replace or append initrd and command line. Doing this with a single command is tricky. Does bootimg come with a command line or is it just a bundle of Linux image and initrd? Have you considered making linux recognize androidimg and pull linux out of it? Adding androidimg: alongside newc: syntax to initrd?

Le ven. 29 janv. 2016 15:13, Shea Levy <address@hidden> a écrit :
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]