All of lore.kernel.org
 help / color / mirror / Atom feed
From: otavio.salvador@ossystems.com.br (Otavio Salvador)
To: linux-snps-arc@lists.infradead.org
Subject: [OE-core] [PATCH v7] u-boot: Add mkenvimage tool
Date: Mon, 26 Nov 2018 21:07:37 -0200	[thread overview]
Message-ID: <CAP9ODKrJ0Yshn29tSt-Aj1Gr01+XrZ7C_K4Yn4r6yA4CdkiCnQ@mail.gmail.com> (raw)
In-Reply-To: <8950e9f58055a8667d20ff83de1f8acd14b7f303.camel@synopsys.com>

Hello Alexey,

On Mon, Nov 26, 2018 at 7:30 PM Alexey Brodkin
<alexey.brodkin@synopsys.com> wrote:
> On Sat, 2018-11-24@06:57 -0800, Khem Raj wrote:
> >
> > http://errors.yoctoproject.org/Errors/Details/202185/
>
> Looking at the target name "u-boot-tools-1_2018.11-r0 do_compile"
> I think it might have something to do with bump of U-Boot to v2018.11
> and the error message in question was added in v2018.11-rc1,
> see http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a4958a71017fb142542f977c843c5fce769fc6ea
>
> The problem is we use "sandbox_defconfig" as a dummy defconfig
> because otherwise (not configured) U-Boot's build-system won't
> allow us to proceed and in its turn mentioned patch adds a check
> for a target platform like "if defined(__x86_64__)" which
> we essentially don't satisfy and so we fail.
>
> There're the following solutions:
>  1. Revert mentioned patch
>  2. Disable "CONFIG_EFI_LOADER"
>
> Reverting is not nice and not future-proof.
> Disabling of "CONFIG_EFI_LOADER" might be done in a couple of ways
> like:
>  1. Patching sandbox_defconfig
>  2. Filtering "CONFIG_EFI_LOADER" from "sandbox_defconfig" right before
>     execution of "make sandbox_defconfig"
>
> I think latter option is the simplest and cleanest.
>
> Should I send a patch for that?

Let's add Tom (U-Boot upstream main maintainer) to this so he can comment.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750

WARNING: multiple messages have this Message-ID (diff)
From: Otavio Salvador <otavio.salvador@ossystems.com.br>
To: Alexey Brodkin <alexey.brodkin@synopsys.com>
Cc: Marek Vasut <marex@denx.de>, Tom Rini <trini@konsulko.com>,
	Otavio Salvador <otavio@ossystems.com.br>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	linux-snps-arc@lists.infradead.org
Subject: Re: [PATCH v7] u-boot: Add mkenvimage tool
Date: Mon, 26 Nov 2018 21:07:37 -0200	[thread overview]
Message-ID: <CAP9ODKrJ0Yshn29tSt-Aj1Gr01+XrZ7C_K4Yn4r6yA4CdkiCnQ@mail.gmail.com> (raw)
In-Reply-To: <8950e9f58055a8667d20ff83de1f8acd14b7f303.camel@synopsys.com>

Hello Alexey,

On Mon, Nov 26, 2018 at 7:30 PM Alexey Brodkin
<alexey.brodkin@synopsys.com> wrote:
> On Sat, 2018-11-24 at 06:57 -0800, Khem Raj wrote:
> >
> > http://errors.yoctoproject.org/Errors/Details/202185/
>
> Looking at the target name "u-boot-tools-1_2018.11-r0 do_compile"
> I think it might have something to do with bump of U-Boot to v2018.11
> and the error message in question was added in v2018.11-rc1,
> see http://git.denx.de/?p=u-boot.git;a=commitdiff;h=a4958a71017fb142542f977c843c5fce769fc6ea
>
> The problem is we use "sandbox_defconfig" as a dummy defconfig
> because otherwise (not configured) U-Boot's build-system won't
> allow us to proceed and in its turn mentioned patch adds a check
> for a target platform like "if defined(__x86_64__)" which
> we essentially don't satisfy and so we fail.
>
> There're the following solutions:
>  1. Revert mentioned patch
>  2. Disable "CONFIG_EFI_LOADER"
>
> Reverting is not nice and not future-proof.
> Disabling of "CONFIG_EFI_LOADER" might be done in a couple of ways
> like:
>  1. Patching sandbox_defconfig
>  2. Filtering "CONFIG_EFI_LOADER" from "sandbox_defconfig" right before
>     execution of "make sandbox_defconfig"
>
> I think latter option is the simplest and cleanest.
>
> Should I send a patch for that?

Let's add Tom (U-Boot upstream main maintainer) to this so he can comment.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750


  parent reply	other threads:[~2018-11-26 23:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-22 22:58 [PATCH v7] u-boot: Add mkenvimage tool Alexey Brodkin
2018-11-22 22:58 ` Alexey Brodkin
2018-11-24 14:57 ` Khem Raj
2018-11-24 14:57   ` Khem Raj
2018-11-26 21:30   ` Alexey Brodkin
2018-11-26 21:30     ` Alexey Brodkin
2018-11-26 22:16     ` Khem Raj
2018-11-26 22:16       ` Khem Raj
2018-11-26 23:07     ` Otavio Salvador [this message]
2018-11-26 23:07       ` Otavio Salvador
2018-11-27  0:51       ` [OE-core] " Tom Rini
2018-11-27  0:51         ` Tom Rini
2018-11-27  6:54         ` [OE-core] " Alexey Brodkin
2018-11-27  6:54           ` Alexey Brodkin

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=CAP9ODKrJ0Yshn29tSt-Aj1Gr01+XrZ7C_K4Yn4r6yA4CdkiCnQ@mail.gmail.com \
    --to=otavio.salvador@ossystems.com.br \
    --cc=linux-snps-arc@lists.infradead.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.