All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] Initial support for the android bootimg filesystem.
@ 2016-01-26 19:42 Shea Levy
  2016-01-27  7:22 ` Andrei Borzenkov
  0 siblings, 1 reply; 11+ messages in thread
From: Shea Levy @ 2016-01-26 19:42 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Shea Levy

Currently, the kernel and, if present, the ramdisk are made available as
regular files.
---
 grub-core/Makefile.core.def    |   7 ++
 grub-core/fs/android_bootimg.c | 271 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 278 insertions(+)
 create mode 100644 grub-core/fs/android_bootimg.c

diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 0cc40bb..a726abd 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1231,6 +1231,13 @@ module = {
 };
 
 module = {
+  name = android_bootimg;
+  common = fs/android_bootimg.c;
+  cflags = '$(CFLAGS_POSIX) $(CFLAGS_GNULIB)';
+  cppflags = '$(CPPFLAGS_POSIX) $(CPPFLAGS_GNULIB)';
+};
+
+module = {
   name = bfs;
   common = fs/bfs.c;
 };
diff --git a/grub-core/fs/android_bootimg.c b/grub-core/fs/android_bootimg.c
new file mode 100644
index 0000000..093307a
--- /dev/null
+++ b/grub-core/fs/android_bootimg.c
@@ -0,0 +1,271 @@
+/* android-bootimg.c - android bootimg filesystem.  */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2016 Free Software Foundation, Inc.
+ *
+ *  This program is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include <stdint.h>
+#include <grub/dl.h>
+#include <grub/file.h>
+
+GRUB_MOD_LICENSE ("GPLv3+");
+
+/* from https://android.googlesource.com/platform/system/core/+/506d233e7ac8ca4efa80768153d842c296477f99/mkbootimg/bootimg.h */
+/* From here until the end of struct boot_img_hdr available under the following terms:
+ *
+ * Copyright 2007, The Android Open Source Project
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ *     http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#define BOOT_MAGIC	"ANDROID!"
+#define BOOT_MAGIC_SIZE	8
+#define BOOT_NAME_SIZE	16
+#define BOOT_ARGS_SIZE	512
+#define BOOT_EXTRA_ARGS_SIZE	1024
+
+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;
+
+typedef enum
+  {
+    ROOT,
+    KERNEL,
+    RAMDISK,
+    NOT_FOUND,
+    BAD_NAME
+  }
+grub_android_bootimg_filename_t;
+
+static grub_android_bootimg_filename_t
+handle_path (const char *path)
+{
+  if (!path || path[0] != '/')
+    return BAD_NAME;
+
+  const char *path_iter;
+  for (path_iter = path + 1; *path_iter; ++path_iter) {
+    if (*path_iter == '/')
+      continue;
+    if (*path_iter == '.') {
+      if (*(++path_iter) == '/')
+	continue;
+      else if (*path_iter == '.' && *(++path_iter) == '/')
+	continue;
+      else
+	return NOT_FOUND;
+    }
+    break;
+  }
+
+  if (!*path_iter)
+    return ROOT;
+  else if (grub_strcmp (path_iter, "kernel") == 0)
+    return KERNEL;
+  else if (grub_strcmp (path_iter, "ramdisk") == 0)
+    return RAMDISK;
+  else
+    return NOT_FOUND;
+}
+
+static grub_err_t
+read_hdr (grub_disk_t disk, struct boot_img_hdr *hd)
+{
+  if (grub_disk_read (disk, 0, 0, sizeof *hd, hd))
+    goto fail;
+
+  if (grub_memcmp (hd->magic, BOOT_MAGIC, BOOT_MAGIC_SIZE))
+    goto fail;
+
+  if (hd->unused[0] || hd->unused[1])
+    goto fail;
+
+  return GRUB_ERR_NONE;
+
+fail:
+  return grub_error (GRUB_ERR_BAD_FS, N_("%s not an android bootimg"),
+                     disk->name);
+}
+
+static grub_err_t
+grub_android_bootimg_dir (grub_device_t device, const char *path,
+               grub_fs_dir_hook_t hook, void *hook_data)
+{
+  struct boot_img_hdr hd;
+
+  if (read_hdr (device->disk, &hd))
+    return grub_errno;
+
+  grub_android_bootimg_filename_t file = handle_path (path);
+  if (file == NOT_FOUND)
+    return grub_error (GRUB_ERR_FILE_NOT_FOUND, N_("directory `%s' not found"),
+                       path);
+  else if (file == BAD_NAME)
+    return grub_error (GRUB_ERR_BAD_FILENAME, N_("invalid directory name `%s'"),
+                       path);
+  else if (file != ROOT)
+    return grub_error (GRUB_ERR_BAD_FILE_TYPE, N_("`%s' not a directory"),
+                       path);
+
+  struct grub_dirhook_info info = {
+    .dir = 1,
+    .mtimeset = 0,
+    .case_insensitive = 0,
+    .inodeset = 0,
+    .mtime = 0,
+    .inode = 0
+  };
+
+  if (hook (".", &info, hook_data)) {
+    return grub_errno;
+  }
+
+  if (hook ("..", &info, hook_data)) {
+    return grub_errno;
+  }
+
+  info.dir = 0;
+
+  if (hook ("kernel", &info, hook_data)) {
+    return grub_errno;
+  }
+
+  if (hd.ramdisk_size != 0) {
+    if (hook ("ramdisk", &info, hook_data)) {
+      return grub_errno;
+    }
+  }
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_err_t
+grub_android_bootimg_open (grub_file_t file, const char *name)
+{
+  struct boot_img_hdr hd;
+
+  if (read_hdr (file->device->disk, &hd))
+    return grub_errno;
+
+  grub_off_t *begin_offset;
+
+  grub_android_bootimg_filename_t fn = handle_path (name);
+  switch (fn)
+    {
+    case NOT_FOUND:
+      return grub_error (GRUB_ERR_FILE_NOT_FOUND, N_("file `%s' not found"),
+                         name);
+    case BAD_NAME:
+      return grub_error (GRUB_ERR_BAD_FILENAME, N_("bad file name `%s'"), name);
+    case ROOT:
+      return grub_error (GRUB_ERR_BAD_FILE_TYPE, N_("`%s' not a regular file"),
+                         name);
+    case KERNEL:
+      begin_offset = grub_malloc (sizeof *begin_offset);
+      *begin_offset = hd.page_size;
+      file->data = begin_offset;
+      file->size = hd.kernel_size;
+      break;
+    case RAMDISK:
+      begin_offset = grub_malloc (sizeof *begin_offset);
+      *begin_offset =
+        hd.page_size * (1 + (hd.kernel_size + hd.page_size - 1) / hd.page_size);
+      file->data = begin_offset;
+      file->size = hd.ramdisk_size;
+      break;
+    }
+
+  return GRUB_ERR_NONE;
+}
+
+static grub_ssize_t
+grub_android_bootimg_read (grub_file_t file, char *buf, grub_size_t len)
+{
+  grub_size_t len_left = file->size - file->offset;
+  len = len > len_left ? len_left : len;
+  grub_off_t *begin_offset = file->data;
+  grub_off_t actual_offset = *begin_offset + file->offset;
+  file->device->disk->read_hook = file->read_hook;
+  file->device->disk->read_hook_data = file->read_hook_data;
+  grub_errno = grub_disk_read (file->device->disk, 0, actual_offset, len, buf);
+  file->device->disk->read_hook = 0;
+
+  if (grub_errno)
+    return -1;
+  else
+    return len;
+}
+
+static grub_err_t
+grub_android_bootimg_close (grub_file_t file)
+{
+  grub_free (file->data);
+  return GRUB_ERR_NONE;
+}
+
+static struct grub_fs grub_android_bootimg_fs = {
+  .name = "android_bootimg",
+  .dir = grub_android_bootimg_dir,
+  .open = grub_android_bootimg_open,
+  .read = grub_android_bootimg_read,
+  .close = grub_android_bootimg_close,
+#ifdef GRUB_UTIL
+  .reserved_first_sector = 0,
+  .blocklist_install = 0,
+#endif
+};
+
+GRUB_MOD_INIT (android_bootimg)
+{
+  grub_fs_register (&grub_android_bootimg_fs);
+}
+
+GRUB_MOD_FINI (android_bootimg)
+{
+  grub_fs_unregister (&grub_android_bootimg_fs);
+}
-- 
2.7.0



^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-26 19:42 [PATCH v2] Initial support for the android bootimg filesystem Shea Levy
@ 2016-01-27  7:22 ` Andrei Borzenkov
  2016-01-27 12:53   ` shea
  0 siblings, 1 reply; 11+ messages in thread
From: Andrei Borzenkov @ 2016-01-27  7:22 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Shea Levy

On Tue, Jan 26, 2016 at 10:42 PM, Shea Levy <shea@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.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-27  7:22 ` Andrei Borzenkov
@ 2016-01-27 12:53   ` shea
  2016-01-28 23:48     ` shea
  0 siblings, 1 reply; 11+ messages in thread
From: shea @ 2016-01-27 12:53 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Andrei Borzenkov

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

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" <shea@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 <shea@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


[-- Attachment #2: Type: text/html, Size: 2824 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-27 12:53   ` shea
@ 2016-01-28 23:48     ` shea
  2016-01-29  9:18       ` Andrei Borzenkov
  0 siblings, 1 reply; 11+ messages in thread
From: shea @ 2016-01-28 23:48 UTC (permalink / raw)
  To: The development of GNU GRUB; +Cc: Andrei Borzenkov

[-- Attachment #1: Type: text/plain, Size: 2521 bytes --]

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: shea@shealevy.com
To:"The development of GNU GRUB" <grub-devel@gnu.org>
Cc:"Andrei Borzenkov" <arvidjaar@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" <shea@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 <shea@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


[-- Attachment #2: Type: text/html, Size: 3616 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-28 23:48     ` shea
@ 2016-01-29  9:18       ` Andrei Borzenkov
  2016-01-29 14:12         ` Shea Levy
  0 siblings, 1 reply; 11+ messages in thread
From: Andrei Borzenkov @ 2016-01-29  9:18 UTC (permalink / raw)
  To: Shea Levy; +Cc: The development of GNU GRUB

On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com> 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.

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

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" <grub-devel@gnu.org>
>
> To:
> "The development of GNU GRUB" <grub-devel@gnu.org>
> Cc:
> "Shea Levy" <shea@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 <shea@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


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29  9:18       ` Andrei Borzenkov
@ 2016-01-29 14:12         ` Shea Levy
  2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
  2016-01-29 18:56           ` Michael Zimmermann
  0 siblings, 2 replies; 11+ messages in thread
From: Shea Levy @ 2016-01-29 14:12 UTC (permalink / raw)
  To: grub-devel

On 2016-01-29 04:18, Andrei Borzenkov wrote:
> On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com> 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" <grub-devel@gnu.org>
>>
>> To:
>> "The development of GNU GRUB" <grub-devel@gnu.org>
>> Cc:
>> "Shea Levy" <shea@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 <shea@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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29 14:12         ` Shea Levy
@ 2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
  2016-01-29 17:51             ` Andrei Borzenkov
  2016-01-29 18:53             ` shea
  2016-01-29 18:56           ` Michael Zimmermann
  1 sibling, 2 replies; 11+ messages in thread
From: Vladimir 'phcoder' Serbinenko @ 2016-01-29 17:37 UTC (permalink / raw)
  To: The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 4791 bytes --]

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 <shea@shealevy.com> a écrit :

> On 2016-01-29 04:18, Andrei Borzenkov wrote:
> > On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com> 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" <grub-devel@gnu.org>
> >>
> >> To:
> >> "The development of GNU GRUB" <grub-devel@gnu.org>
> >> Cc:
> >> "Shea Levy" <shea@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 <shea@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
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 6846 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
@ 2016-01-29 17:51             ` Andrei Borzenkov
  2016-01-29 18:53             ` shea
  1 sibling, 0 replies; 11+ messages in thread
From: Andrei Borzenkov @ 2016-01-29 17:51 UTC (permalink / raw)
  To: grub-devel

29.01.2016 20:37, Vladimir 'phcoder' Serbinenko пишет:
> 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?
> 

As far as I understand this is single file that packs kernel, initrd and
command line in one unit.

https://www.compulab.co.il/workspace/mediawiki/index.php5/Android:_Boot_image

I am not sure it is correct to treat it as free standing Linux kernel.

> Le ven. 29 janv. 2016 15:13, Shea Levy <shea@shealevy.com> a écrit :
> 
>> On 2016-01-29 04:18, Andrei Borzenkov wrote:
>>> On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com> 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" <grub-devel@gnu.org>
>>>>
>>>> To:
>>>> "The development of GNU GRUB" <grub-devel@gnu.org>
>>>> Cc:
>>>> "Shea Levy" <shea@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 <shea@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
>>
>>
>> _______________________________________________
>> 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
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
  2016-01-29 17:51             ` Andrei Borzenkov
@ 2016-01-29 18:53             ` shea
  2016-02-02 20:31               ` shea
  1 sibling, 1 reply; 11+ messages in thread
From: shea @ 2016-01-29 18:53 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 5927 bytes --]

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" <phcoder@gmail.com>
To:"The development of GNU GRUB" <grub-devel@gnu.org>
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 <shea@shealevy.com [1]> a
écrit :
On 2016-01-29 04:18, Andrei Borzenkov wrote:
 > On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com [2]> 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" <grub-devel@gnu.org [3]>
 >>
 >> To:
 >> "The development of GNU GRUB" <grub-devel@gnu.org [4]>
 >> Cc:
 >> "Shea Levy" <shea@shealevy.com [5]>
 >> 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 <shea@shealevy.com
[6]>
 >> 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 [7]
 >> https://lists.gnu.org/mailman/listinfo/grub-devel [8]
 >
 > _______________________________________________
 > Grub-devel mailing list
 > Grub-devel@gnu.org [9]
 > https://lists.gnu.org/mailman/listinfo/grub-devel [10]

 _______________________________________________
 Grub-devel mailing list
Grub-devel@gnu.org [11]
https://lists.gnu.org/mailman/listinfo/grub-devel [12]
 

Links:
------
[1] mailto:shea@shealevy.com
[2] mailto:shea@shealevy.com
[3] mailto:grub-devel@gnu.org
[4] mailto:grub-devel@gnu.org
[5] mailto:shea@shealevy.com
[6] mailto:shea@shealevy.com
[7] mailto:Grub-devel@gnu.org
[8] https://lists.gnu.org/mailman/listinfo/grub-devel
[9] mailto:Grub-devel@gnu.org
[10] https://lists.gnu.org/mailman/listinfo/grub-devel
[11] mailto:Grub-devel@gnu.org
[12] https://lists.gnu.org/mailman/listinfo/grub-devel


[-- Attachment #2: Type: text/html, Size: 7819 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29 14:12         ` Shea Levy
  2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
@ 2016-01-29 18:56           ` Michael Zimmermann
  1 sibling, 0 replies; 11+ messages in thread
From: Michael Zimmermann @ 2016-01-29 18:56 UTC (permalink / raw)
  To: The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 4399 bytes --]

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 <shea@shealevy.com> wrote:

> On 2016-01-29 04:18, Andrei Borzenkov wrote:
>
>> On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com> 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" <grub-devel@gnu.org>
>>>
>>> To:
>>> "The development of GNU GRUB" <grub-devel@gnu.org>
>>> Cc:
>>> "Shea Levy" <shea@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 <shea@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
>>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 6734 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] Initial support for the android bootimg filesystem.
  2016-01-29 18:53             ` shea
@ 2016-02-02 20:31               ` shea
  0 siblings, 0 replies; 11+ messages in thread
From: shea @ 2016-02-02 20:31 UTC (permalink / raw)
  To: Vladimir 'phcoder' Serbinenko, The development of GNU GRUB

[-- Attachment #1: Type: text/plain, Size: 6285 bytes --]

Any advice on how to move forward with this patch?

Thanks,
Shea

----- Original Message -----
From: shea@shealevy.com
To:"Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>, "The
development of GNU GRUB" <grub-devel@gnu.org>
Cc:
Sent:Fri, 29 Jan 2016 10:53:57 -0800
Subject:Re: [PATCH v2] Initial support for the android bootimg
filesystem.

 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" <phcoder@gmail.com>
To:"The development of GNU GRUB" <grub-devel@gnu.org>
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 <shea@shealevy.com [1]> a
écrit :
On 2016-01-29 04:18, Andrei Borzenkov wrote:
 > On Fri, Jan 29, 2016 at 2:48 AM,  <shea@shealevy.com [2]> 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" <grub-devel@gnu.org [3]>
 >>
 >> To:
 >> "The development of GNU GRUB" <grub-devel@gnu.org [4]>
 >> Cc:
 >> "Shea Levy" <shea@shealevy.com [5]>
 >> 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 <shea@shealevy.com
[6]>
 >> 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 [7]
 >> https://lists.gnu.org/mailman/listinfo/grub-devel [8]
 >
 > _______________________________________________
 > Grub-devel mailing list
 > Grub-devel@gnu.org [9]
 > https://lists.gnu.org/mailman/listinfo/grub-devel [10]

 _______________________________________________
 Grub-devel mailing list
Grub-devel@gnu.org [11]
https://lists.gnu.org/mailman/listinfo/grub-devel [12]
 

Links:
------
[1] mailto:shea@shealevy.com
[2] mailto:shea@shealevy.com
[3] mailto:grub-devel@gnu.org
[4] mailto:grub-devel@gnu.org
[5] mailto:shea@shealevy.com
[6] mailto:shea@shealevy.com
[7] mailto:Grub-devel@gnu.org
[8] https://lists.gnu.org/mailman/listinfo/grub-devel
[9] mailto:Grub-devel@gnu.org
[10] https://lists.gnu.org/mailman/listinfo/grub-devel
[11] mailto:Grub-devel@gnu.org
[12] https://lists.gnu.org/mailman/listinfo/grub-devel


[-- Attachment #2: Type: text/html, Size: 8503 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2016-02-02 20:31 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-26 19:42 [PATCH v2] Initial support for the android bootimg filesystem Shea Levy
2016-01-27  7:22 ` Andrei Borzenkov
2016-01-27 12:53   ` shea
2016-01-28 23:48     ` shea
2016-01-29  9:18       ` Andrei Borzenkov
2016-01-29 14:12         ` Shea Levy
2016-01-29 17:37           ` Vladimir 'phcoder' Serbinenko
2016-01-29 17:51             ` Andrei Borzenkov
2016-01-29 18:53             ` shea
2016-02-02 20:31               ` shea
2016-01-29 18:56           ` Michael Zimmermann

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.