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?
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