[Buildroot] What's the buildroot attitude to u-boot building?

[Buildroot] What's the buildroot attitude to u-boot building?

[Charles Manning]

Hi All

I am having a look at adding some stuff to generate a signed pre-loader for
the SoCFPGA architecture.

There seem to be two options to doing this:
1) Have it fall out of building u-boot (probably the best option once the
patches I'm pushing into u-vboot have settled down)
2) Make an independent build like xloader (probably a better interum
solution), since for now the SocFPGA preloader building is still somewhat
haphazard and needs a magic version of u-boot.

Looking through all the u-boot config stuff makes me wonder why some of the
stuff is even there.

For instance, why are there things like  BR2_TARGET_UBOOT_ETHADDR?
Overriding elements of the u-boot config header by patching over them from
a complete different config system (buildroot) seems to be asking for
trouble.

Surely it would be far better for people to edit their u-boot config
headers?

Can someone explain the rationale behind doing this sort of config in
buildroot?

Thanks

CHarles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140221/61317655/attachment.html>

[Buildroot] What's the buildroot attitude to u-boot building?

[Grant Edwards]

On 2014-02-21, Charles Manning <cdhmanning@gmail.com> wrote:

I messed with using buildroot for building U-Boot, and decided it was
better to build it outside of buildroot.  I found buildroot great for
building a root filesystem, but I didn't find it useful for other
things (like building toolchains, bootloaders, kernels, etc.).  I
think it makes a lot more sense to build those separately.

-- 
Grant

[Buildroot] What's the buildroot attitude to u-boot building?

[Thomas Petazzoni]

Dear Grant Edwards,

On Fri, 21 Feb 2014 14:49:43 +0000 (UTC), Grant Edwards wrote:

> I messed with using buildroot for building U-Boot, and decided it was
> better to build it outside of buildroot.  I found buildroot great for
> building a root filesystem, but I didn't find it useful for other
> things (like building toolchains, bootloaders, kernels, etc.).  I
> think it makes a lot more sense to build those separately.

Do you have more details about what you found unpractical in Buildroot
to build U-Boot and your kernel? What issues did you had, or things you
found not really nice?

Thanks for your feedback!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] What's the buildroot attitude to u-boot building?

[Thomas Petazzoni]

Dear Charles Manning,

On Fri, 21 Feb 2014 14:53:06 +1300, Charles Manning wrote:

> I am having a look at adding some stuff to generate a signed pre-loader for
> the SoCFPGA architecture.

As you can see, some people are already working on supporting the
SoCKit platform, which uses the SoCFPGA architecture.

> There seem to be two options to doing this:
> 1) Have it fall out of building u-boot (probably the best option once the
> patches I'm pushing into u-vboot have settled down)
> 2) Make an independent build like xloader (probably a better interum
> solution), since for now the SocFPGA preloader building is still somewhat
> haphazard and needs a magic version of u-boot.

I'm not sure to understand here. A defconfig for a SoCFPGA platform was
submitted today, and a single build of U-Boot produces both the
pre-loader and the real U-Boot image.

> For instance, why are there things like  BR2_TARGET_UBOOT_ETHADDR?
> Overriding elements of the u-boot config header by patching over them from
> a complete different config system (buildroot) seems to be asking for
> trouble.

Why is this asking for trouble?

Anyway, I agree that these tuning options for U-Boot are a bit weird.
Since in U-Boot there is no separation between the configuration and
the definition of the hardware platform, most people should patch
U-Boot if they want to change their configuration.

Options such as BR2_TARGET_UBOOT_ETHADDR have been here for many many
years, and we have simply kept them over time. It was added back in
June 2007.

While I don't find it particularly pretty, I kind of fail to see what
troubles you think it could cause. Could you give more details about
this?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] What's the buildroot attitude to u-boot building?

[Grant Edwards]

On 2014-02-21, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Dear Grant Edwards,
>
> On Fri, 21 Feb 2014 14:49:43 +0000 (UTC), Grant Edwards wrote:
>
>> I messed with using buildroot for building U-Boot, and decided it was
>> better to build it outside of buildroot.  I found buildroot great for
>> building a root filesystem, but I didn't find it useful for other
>> things (like building toolchains, bootloaders, kernels, etc.).  I
>> think it makes a lot more sense to build those separately.
>
> Do you have more details about what you found unpractical in Buildroot
> to build U-Boot and your kernel? What issues did you had, or things you
> found not really nice?

First, I should have prefaced my comments by saying that was a couple
years ago, so things may be different now.

There are two main reasons I switched to building the kernel and
U-Boot outside buildroot:

1) U-Boot, the Linux kernel, and the root FS are three differnt
   "things".  The binaries are versioned and archived independently,
   they have separate part numbers, and they're distributed and
   installed independently.  Building all three of them together at
   the same time with buildroot doesn't really fit well with that.  It
   ends up wasting a lot of build time when only one of them needs to
   be built.
   
   Or, you set up three different biuldroot configs to build the three
   different things. But, using buildroot to build just the kernel, or
   just U-Boot just adds a layer of indirection and opacity over the
   simple "make menuconfig && make".

2) When doing active development, it usually wasn't simple/clear how
   to get buildroot to do a "make" in the directory I wanted it to
   after a source file had been edited.  There were several occasions
   when I thought something had been rebuilt, but it wasn't -- and
   after messing around for a while I ended up having to create source
   tarballs from my edited source files, remove the buildroot build
   tree and start over from scratch.

   Buildroot is based on the sequence:

      a) fetch tarball
      b) unpack tarball
      c) apply patches
      d) run build script
      e) run install script
      
   When you're doing development on the Kernel or U-Boot that sequence
   isn't very convenient. It's a lot simpler to (in eamcs):

      a) Edit source file(s) and hit ctrl-X ctrl-S to save changes
      b) Hit F8 to do a "make" and move the cursor to the first
         warning/error.
      
After all development is done, it might be more feasible to use
buildroot to build everything. But, when you get to that point, you've
alreay got a working source trees, configurations, and makefiles for
the kernel and U-Boot, so it's simple just to stick with them.

-- 
Grant

[Buildroot] What's the buildroot attitude to u-boot building?

[Mike Zick]

On Sat, 22 Feb 2014 20:45:54 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> First, I should have prefaced my comments by saying that was a couple
> years ago, so things may be different now.
> 

"Things" are indeed much different now.

Many of the irritations of Buildroot in single package development have
been dealt with over the past couple of years.

And, there is now the Buildroot plug-in for Eclipse.

But, you may have to spin your own plug-in for e-macs.  ;)

There is even an on-line (and packaged with BR) manual that is kept
fairly upto date.

You might want to skim that to see what all has happened to BR.

Mike

[Buildroot] What's the buildroot attitude to u-boot building?

[Thomas Petazzoni]

Dear Grant Edwards,

On Sat, 22 Feb 2014 20:45:54 +0000 (UTC), Grant Edwards wrote:

> > Do you have more details about what you found unpractical in Buildroot
> > to build U-Boot and your kernel? What issues did you had, or things you
> > found not really nice?
> 
> First, I should have prefaced my comments by saying that was a couple
> years ago, so things may be different now.
> 
> There are two main reasons I switched to building the kernel and
> U-Boot outside buildroot:
> 
> 1) U-Boot, the Linux kernel, and the root FS are three differnt
>    "things".  The binaries are versioned and archived independently,
>    they have separate part numbers, and they're distributed and
>    installed independently.  Building all three of them together at
>    the same time with buildroot doesn't really fit well with that.  It
>    ends up wasting a lot of build time when only one of them needs to
>    be built.
>    
>    Or, you set up three different biuldroot configs to build the three
>    different things. But, using buildroot to build just the kernel, or
>    just U-Boot just adds a layer of indirection and opacity over the
>    simple "make menuconfig && make".

I guess here it's really a matter of taste. I've seen a large of number
of people/companies who really like the fact that one *single*
Buildroot configuration is building their entire embedded Linux
system: toolchain, rootfs, kernel and bootloader images.

It is indeed true that for the kernel, Buildroot creates one layer of
indirection: you have to run "make linux-menuconfig" to adjust the
kernel configuration, and remember to save back the modified
configuration file. There's not much we can do about it, though:
Buildroot is a meta build-system: its purpose is to trigger the build
of various components, using their respective build systems. There are
necessarily limits to the integration that can be done between the meta
build-system that Buildroot is, and the respective build systems of
each component.

> 2) When doing active development, it usually wasn't simple/clear how
>    to get buildroot to do a "make" in the directory I wanted it to
>    after a source file had been edited.  There were several occasions
>    when I thought something had been rebuilt, but it wasn't -- and
>    after messing around for a while I ended up having to create source
>    tarballs from my edited source files, remove the buildroot build
>    tree and start over from scratch.
> 
>    Buildroot is based on the sequence:
> 
>       a) fetch tarball
>       b) unpack tarball
>       c) apply patches
>       d) run build script
>       e) run install script
>       
>    When you're doing development on the Kernel or U-Boot that sequence
>    isn't very convenient. It's a lot simpler to (in eamcs):
> 
>       a) Edit source file(s) and hit ctrl-X ctrl-S to save changes
>       b) Hit F8 to do a "make" and move the cursor to the first
>          warning/error.
>       
> After all development is done, it might be more feasible to use
> buildroot to build everything. But, when you get to that point, you've
> alreay got a working source trees, configurations, and makefiles for
> the kernel and U-Boot, so it's simple just to stick with them.

It is indeed clear that Buildroot used to be mainly aimed at
"integration", not to be used during development work.

However, based on what you say, it really looks like you have never
looked at using <pkg>_OVERRIDE_SRCDIR together with "make
<pkg>-rebuild", because they do precisely what you're looking for :-)

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] What's the buildroot attitude to u-boot building?

[Grant Edwards]

On 2014-02-23, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> I guess here it's really a matter of taste.

True.

> I've seen a large of number of people/companies who really like the
> fact that one *single* Buildroot configuration is building their
> entire embedded Linux system: toolchain, rootfs, kernel and
> bootloader images.

If those make up the entire embedded Linux system, then that would be
convenient.

> It is indeed clear that Buildroot used to be mainly aimed at
> "integration", not to be used during development work.
>
> However, based on what you say, it really looks like you have never
> looked at using <pkg>_OVERRIDE_SRCDIR together with "make
><pkg>-rebuild", because they do precisely what you're looking for :-)

Indeed, I wasn't aware of those. It looks like they were added after I
decided to build kernel and boot-loader independently.

[Buildroot] What's the buildroot attitude to u-boot building?

[Mike Zick]

On Sun, 23 Feb 2014 18:50:53 +0000 (UTC)
Grant Edwards <grant.b.edwards@gmail.com> wrote:

> > I've seen a large of number of people/companies who really like the
> > fact that one *single* Buildroot configuration is building their
> > entire embedded Linux system: toolchain, rootfs, kernel and
> > bootloader images.  
> 
> If those make up the entire embedded Linux system, then that would be
> convenient.
>

And there is now the BR_EXTERNAL source tree for the additions to 
complete the specific embedded Linux system.

Mike

[Buildroot] What's the buildroot attitude to u-boot building?

[Charles Manning]

On Saturday 22 February 2014 12:13:09 Thomas Petazzoni wrote:
> Dear Charles Manning,
>
> On Fri, 21 Feb 2014 14:53:06 +1300, Charles Manning wrote:
> > I am having a look at adding some stuff to generate a signed pre-loader
> > for the SoCFPGA architecture.
>
> As you can see, some people are already working on supporting the
> SoCKit platform, which uses the SoCFPGA architecture.

Yes, I am watching that closely and I hope to be able to contribute.

>
> > There seem to be two options to doing this:
> > 1) Have it fall out of building u-boot (probably the best option once the
> > patches I'm pushing into u-vboot have settled down)
> > 2) Make an independent build like xloader (probably a better interum
> > solution), since for now the SocFPGA preloader building is still somewhat
> > haphazard and needs a magic version of u-boot.
>
> I'm not sure to understand here. A defconfig for a SoCFPGA platform was
> submitted today, and a single build of U-Boot produces both the
> pre-loader and the real U-Boot image.

That is right, it does produce an SPL image, but what is produced by 
u-boot/master is currently rubbish code that does not execute. It is only 
about 4k instead of about 45k.

These issues are being worked on.

>
> > For instance, why are there things like  BR2_TARGET_UBOOT_ETHADDR?
> > Overriding elements of the u-boot config header by patching over them
> > from a complete different config system (buildroot) seems to be asking
> > for trouble.
>
> Why is this asking for trouble?

Well when you're trying to set up a u-boot environment, it makes sense to do 
this in one place surely? If you do some settings in one place and others 
elsewhere, you need to dig deeper to find which has precedence etc.

>
> Anyway, I agree that these tuning options for U-Boot are a bit weird.
> Since in U-Boot there is no separation between the configuration and
> the definition of the hardware platform, most people should patch
> U-Boot if they want to change their configuration.
>
> Options such as BR2_TARGET_UBOOT_ETHADDR have been here for many many
> years, and we have simply kept them over time. It was added back in
> June 2007.

Why would I want to set it here and not in the u-boot config header file where 
the other stuff is configured?

>
> While I don't find it particularly pretty, I kind of fail to see what
> troubles you think it could cause. Could you give more details about
> this?

I have used buildroot in the past to generate u-boot + MLO and have just 
ignored these special options, using my u-boot config instead.

Now I am looking at adding some configs, or working with existing ones, to add 
SOCFPGA handling. so I wanted to understand why things were done as they are 
so that I could do a better job.

Since there are also some socfpga patches in the pipe, I will look at those 
and try to play along with them.

Thanks

Regards

Charles

[Buildroot] What's the buildroot attitude to u-boot building?

[Peter Korsgaard]

>>>>> "Charles" == Charles Manning <cdhmanning@gmail.com> writes:

Hi,

 >> While I don't find it particularly pretty, I kind of fail to see what
 >> troubles you think it could cause. Could you give more details about
 >> this?

 > I have used buildroot in the past to generate u-boot + MLO and have just 
 > ignored these special options, using my u-boot config instead.

 > Now I am looking at adding some configs, or working with existing ones, to add 
 > SOCFPGA handling. so I wanted to understand why things were done as they are 
 > so that I could do a better job.

I've also never used them (and disliked when they got added). Perhaps
the time has come to deprecate those options?

Anybody disagrees?

-- 
Bye, Peter Korsgaard

[Buildroot] What's the buildroot attitude to u-boot building?

[Thomas Petazzoni]

Dear Peter Korsgaard,

On Mon, 24 Feb 2014 09:37:07 +0100, Peter Korsgaard wrote:

>  >> While I don't find it particularly pretty, I kind of fail to see what
>  >> troubles you think it could cause. Could you give more details about
>  >> this?
> 
>  > I have used buildroot in the past to generate u-boot + MLO and have just 
>  > ignored these special options, using my u-boot config instead.
> 
>  > Now I am looking at adding some configs, or working with existing ones, to add 
>  > SOCFPGA handling. so I wanted to understand why things were done as they are 
>  > so that I could do a better job.
> 
> I've also never used them (and disliked when they got added). Perhaps
> the time has come to deprecate those options?
> 
> Anybody disagrees?

I agree that those options are weird. I don't think we should be poking
into the U-Boot header files.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] What's the buildroot attitude to u-boot building?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

Hi,

 >> > I have used buildroot in the past to generate u-boot + MLO and have just 
 >> > ignored these special options, using my u-boot config instead.
 >> 
 >> > Now I am looking at adding some configs, or working with existing ones, to add 
 >> > SOCFPGA handling. so I wanted to understand why things were done as they are 
 >> > so that I could do a better job.
 >> 
 >> I've also never used them (and disliked when they got added). Perhaps
 >> the time has come to deprecate those options?
 >> 
 >> Anybody disagrees?

 > I agree that those options are weird. I don't think we should be poking
 > into the U-Boot header files.

OK, then I will mark them as BR2_DEPRECATED_SINCE_2014_05.

-- 
Bye, Peter Korsgaard