From: Darren Hart <dvhart@linux.intel.com>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] Add KERNEL_EXTRA_ARGS parameter
Date: Tue, 08 May 2012 08:20:40 -0700 [thread overview]
Message-ID: <4FA939C8.3040403@linux.intel.com> (raw)
In-Reply-To: <1336055317.30113.124.camel@ted>
On 05/03/2012 07:28 AM, Richard Purdie wrote:
> On Thu, 2012-05-03 at 16:02 +0200, Koen Kooi wrote:
>> Op 3 mei 2012, om 15:48 heeft Wolfgang Denk het volgende geschreven:
>>
>>> With recent kernel versions, some ARM configurations need may fail to
>>> build with errors like this:
>>>
>>> multiple load addresses: 0x80008000 0x80008000
>>> This is incompatible with uImages
>>> Specify LOADADDR on the commandline to build an uImage
>>>
>>> We cannot pass this information in EXTRA_OEMAKE, as
>>> "meta/classes/kernel.bbclass" explicitly ignores all EXTRA_OEMAKE
>>> settings. So add KERNEL_EXTRA_ARGS parameter so affected boards
>>> can add for example
>>>
>>> KERNEL_EXTRA_ARGS = "LOADADDR=0x80008000"
>>
>> Isn't KERNEL_EXTRA_OEMAKE clearer in this case? I see kernel args
>> being what ends up in /proc/cmdline.
>
> In many ways I wish we could use EXTRA_OEMAKE and try and keep the API
> simpler. Looking at the code, I think it actually can work even with the
> existing code in some circumstances.
>
> Whilst kernel.bbclass does zero out the contents, it does this simply to
> get rid of the default value (the -e MAKEARGS= bit).
>
> The following recipe will therefore work:
>
> """
> <some recipe code>
>
> inherit kernel
>
> EXTRA_OEMAKE += 'LOADADDR=0x80008000'
> """
>
> but the problem is likely this can't be set from machine.conf.
>
> I was wondering about changing the system so that in bitbake.conf we
> set:
>
> OEMAKEDEFAULT = "-e MAKEFLAGS="
> EXTRA_OEMAKE = "${OEMAKEDEFAULT}"
>
> and then kernel.bbclass can zero out OEMAKEDEFAULT. The trouble is you
> want to set:
>
> EXTRA_OEMAKE_append_xxxx = " LOADADDR=0x80008000"
>
> and I'm not coming up with a good value of xxxx other than
> pn-linux-xxxx :/. We could consider an extra override for the kernel
> case I guess.
>
> I would prefer not to add mode global variables unless we can possibly
> help it...
I like the idea of reusing EXTRA_OEMAKE. Unfortunately, by the time we
have to add _append_pn-linux-yocto it seems like the benefit is lost and
I prefer Koen's KERNEL_EXTRA_OEMAKE suggestion.
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
next prev parent reply other threads:[~2012-05-08 15:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-29 10:03 [RFC] [PATCH] Add KERNEL_EXTRA_ARGS parameter Wolfgang Denk
2012-04-29 15:41 ` Khem Raj
2012-04-30 21:03 ` Wolfgang Denk
2012-05-03 13:48 ` Wolfgang Denk
2012-05-03 14:02 ` Koen Kooi
2012-05-03 14:28 ` Richard Purdie
2012-05-08 15:20 ` Darren Hart [this message]
2012-05-03 14:23 ` Eric Bénard
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=4FA939C8.3040403@linux.intel.com \
--to=dvhart@linux.intel.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.