All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Bruce Ashfield" <bruce.ashfield@gmail.com>
To: Adrian Freihofer <adrian.freihofer@gmail.com>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	 Adrian Freihofer <adrian.freihofer@siemens.com>
Subject: Re: [OE-core] [PATCH] runqemu: support uImage kernel
Date: Fri, 16 Apr 2021 14:06:27 -0400	[thread overview]
Message-ID: <CADkTA4O9o1-ivXKjUiidMh+b7qTegDnDwV0Y_dViwCBOz7aCEg@mail.gmail.com> (raw)
In-Reply-To: <20210416164310.275973-1-adrian.freihofer@siemens.com>

On Fri, Apr 16, 2021 at 12:43 PM Adrian Freihofer
<adrian.freihofer@gmail.com> wrote:
>
> u-boot's uImage kernel format is not supported by Qemu. Extract the
> kernel from the uImage to a temporary directory.
>

I'd suggest that we should document in the commit log why someone
wouldn't just build a kernel image format that is already supported by
runqemu (which is what I typically do). I'm guessing it is some sort
of h/w boot being re-purposed to qemu emulation, and this is to avoid
building a second kernel image ?

Additionally, this should have some sort of test, or the code is going
to bitrot due to not being run by anything in core.

> Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
> ---
>  scripts/runqemu | 24 ++++++++++++++++++++++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index ba0b701aff..fa630fc7a4 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -163,6 +163,7 @@ class BaseConfig(object):
>          self.bios = ''
>          self.kernel_cmdline = ''
>          self.kernel_cmdline_script = ''
> +        self.temp_kernel_dir = None
>          self.bootparams = ''
>          self.dtb = ''
>          self.fstype = ''
> @@ -1422,10 +1423,26 @@ class BaseConfig(object):
>          self.setup_serial()
>          self.setup_vga()
>
> +    def dump_uimage(self):
> +        if self.kernel and self.get('KERNEL_IMAGETYPE') == 'uImage':
> +            import tempfile
> +            self.temp_kernel_dir = tempfile.mkdtemp()
> +            kernel = os.path.join(self.temp_kernel_dir, 'image')
> +            dumpimage_bin = os.path.join(self.bindir_native, 'dumpimage')
> +            image_link_name = self.get('IMAGE_LINK_NAME')
> +            logger.info('Running: %s' % str([dumpimage_bin, "-o ", kernel, self.kernel]))
> +            staging_bindir_native = '%s/usr/bin' % self.get('STAGING_DIR_NATIVE')
> +            dumpimage_bin = os.path.join(staging_bindir_native, 'dumpimage')
> +            subprocess.run([dumpimage_bin, "-p", "0", "-o", kernel, self.kernel])
> +            return kernel
> +        return self.kernel
> +
>      def start_qemu(self):
>          import shlex
> -        if self.kernel:
> -            kernel_opts = "-kernel %s -append '%s %s %s %s'" % (self.kernel, self.kernel_cmdline,
> +
> +        kernel = self.dump_uimage()
> +        if kernel:
> +            kernel_opts = "-kernel %s -append '%s %s %s %s'" % (kernel, self.kernel_cmdline,
>                                                                  self.kernel_cmdline_script, self.get('QB_KERNEL_CMDLINE_APPEND'),
>                                                                  self.bootparams)

If the kernel never fails from the dup_uimage() command, why test for
it ? I don't see how the routine could return something that doesn't
pass the test. If so, aren't we going to run into more cryptic errors
(or traceback) later if there was some sort of failure.

The existing code doesn't look like it is completely error proofed
either, that just came to mind when looking at the patch.

Bruce

>              if self.bios:
> @@ -1481,6 +1498,9 @@ class BaseConfig(object):
>              shutil.rmtree(self.rootfs)
>              shutil.rmtree('%s.pseudo_state' % self.rootfs)
>
> +        if self.temp_kernel_dir:
> +            shutil.rmtree(self.temp_kernel_dir)
> +
>          self.cleaned = True
>
>      def run_bitbake_env(self, mach=None):
> --
> 2.26.3
>
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

  reply	other threads:[~2021-04-16 18:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16 16:43 [PATCH] runqemu: support uImage kernel Adrian Freihofer
2021-04-16 18:06 ` Bruce Ashfield [this message]
2021-04-18 13:53   ` [OE-core] " Adrian Freihofer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADkTA4O9o1-ivXKjUiidMh+b7qTegDnDwV0Y_dViwCBOz7aCEg@mail.gmail.com \
    --to=bruce.ashfield@gmail.com \
    --cc=adrian.freihofer@gmail.com \
    --cc=adrian.freihofer@siemens.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.