mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Lior Weintraub <liorw@pliops.com>,
	"barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: Pass user defines for Barebox build
Date: Thu, 30 Nov 2023 08:28:22 +0100	[thread overview]
Message-ID: <1349c023-d0dd-49f2-9d91-e3c870430cf3@pengutronix.de> (raw)
In-Reply-To: <PR3P195MB05556E1A5C2285F0DEA6EA5EC383A@PR3P195MB0555.EURP195.PROD.OUTLOOK.COM>

Hi,

On 29.11.23 11:13, Lior Weintraub wrote:
> Thanks Ahmad,
> 
> On our Barebox porting we have a small piece of code that needs different coding if we build it for QEMU or for the real HW.
> We are used to pass build defines in other projects so that is way we took this approach.  
> 
> I assume the official way would be to set a new defconfig and define a new platform?
> Currently our spider_defconfig has:
> CONFIG_MACH_SPIDER_MK1_EVK=y
> So the new one (spider-qemu_defconfig) would use:
> CONFIG_MACH_SPIDER_QEMU_EVK=y  
> 
> Is this the correct solution?

I'd rather suggest either

   - Having the difference detected at runtime.

   - Have the difference encoded into the device tree: You can have
     multiple ENTRY_FUNCTION, each with a different device tree and
     get multiple images in the same build, one for each device tree.

This avoids the confusion when the wrong image is used. You can even
combine them, see for example arch/arm/boards/stm32mp15xx-dkx/lowlevel.c.

Cheers,
Ahmad

> 
> Cheers,
> Lior.
> 
>> -----Original Message-----
>> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> Sent: Wednesday, November 29, 2023 9:20 AM
>> To: Lior Weintraub <liorw@pliops.com>; barebox@lists.infradead.org
>> Subject: Re: Pass user defines for Barebox build
>>
>> CAUTION: External Sender
>>
>> Hello Lior,
>>
>> On 27.11.23 08:02, Lior Weintraub wrote:
>>> Hi guys,
>>>
>>> Is there a formal way to pass user compilation flags into Barebox build?
>>
>> There isn't. Both barebox and Linux have been broken in the past by distros
>> setting CFLAGS that force hardening options that require kernel/libc cooperation,
>> which didn't apply to barebox. For that reason, the variables were prefixed
>> with KBUILD_ and a way to inject variables into the build of barebox itself
>> (i.e. not host tools) is intentionally not provided.
>>
>> What options do you want to inject?
>>
>>> I couldn't find one so I just patched the main Makefile
>>> diff --git a/Makefile b/Makefile
>>> index 471bbc2679..febc94b7f3 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -443,7 +443,7 @@ KBUILD_CPPFLAGS        := -D__KERNEL__ -
>> D__BAREBOX__ $(LINUXINCLUDE) -fno-builti
>>>  KBUILD_CFLAGS   := -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs
>> \
>>>                    -fno-strict-aliasing -fno-common -fshort-wchar \
>>>                     -Werror=implicit-function-declaration -Werror=implicit-int \
>>> -                   -Os -pipe -Wmissing-prototypes -std=gnu89
>>> +                   -Os -pipe -Wmissing-prototypes -std=gnu89
>> $(BAREBOX_USER_CFLAGS)
>>
>> USER is an unfortunate name, because there's already KBUILD_USERCFLAGS
>> and that user is short for userspace and not the user, who is building
>> barebox.
>>
>> Cheers,
>> Ahmad
>>
>>>  KBUILD_AFLAGS          := -D__ASSEMBLY__
>>>  KBUILD_AFLAGS_KERNEL :=
>>>  KBUILD_CFLAGS_KERNEL :=
>>>
>>> This patch allowed me to set BAREBOX_CFLAGS environment when calling
>> make.
>>>
>>> Thanks,
>>> Lior.
>>>
>>>
>>>
>>
>> --
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       | http://secure-web.cisco.com/1V675vT6A56-
>> sSk-T9-bJ2qzuaJbiJ0EB_N1QWP_UHYUKGBuj9PAjRQHPYsTfz9deA_5ev2NrI87w-
>> kH7EvvotDdB1MXS4OIYlI3dCXTV0YhfEZy-
>> woT7YkA7cjsyhiUkvVJ_RIhamKrCuM300cDnHTGxcaoc6H6DkhUysqXNFY9FCXjser
>> C7dKTwiEPxhk_pdVn-S0-lW1YjHU-UonTqdBHcJvBCtjWkVOiihczwV-
>> TCt9jiaam9NqGn_WreRxWWTC0hcFH0eAsBAi277FQmsFnxcBgaEKxI40JADKLuW
>> F0/http%3A%2F%2Fwww.pengutronix.de%2F  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>>
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |




  reply	other threads:[~2023-11-30  7:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-27  7:02 Lior Weintraub
2023-11-29  7:19 ` Ahmad Fatoum
2023-11-29 10:13   ` Lior Weintraub
2023-11-30  7:28     ` Ahmad Fatoum [this message]
2023-11-30  7:30       ` Lior Weintraub

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=1349c023-d0dd-49f2-9d91-e3c870430cf3@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=liorw@pliops.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox