[U-Boot] RFC: "make DESTDIR=xxx install" ?

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Ulf Samuelsson]

Many packages support installing the resulting binary in another
location, but U-Boot does not.

When you use buildsystems like buildroot and openembedded,
you want to collect the end result in a target directory,
and while you can use internal knowledge about u-boot
to do so, it seems cleaner to me, to do a "make DESTDIR install".

Since you may want to put the binaries for several
boards in the same directory (like /tftpboot)
it is not always good to call the binary simply u-boot.bin.

I guess "make DESTDIR=<destination> TARGET=<name> install" would work

Alternatively, we collect the final binary from several variables,

openembedded typically calls the end binary:
${MACHINE}-u-boot-${U_BOOT_VERSION}-${REVISION}.bin

Feedback?

BR
Ulf Samuelsson

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4A843392.4020800@atmel.com> you wrote:
> Many packages support installing the resulting binary in another
> location, but U-Boot does not.
> 
> When you use buildsystems like buildroot and openembedded,
> you want to collect the end result in a target directory,
> and while you can use internal knowledge about u-boot
> to do so, it seems cleaner to me, to do a "make DESTDIR install".

Did you consider using out-of-tree builds for that? 

> Since you may want to put the binaries for several
> boards in the same directory (like /tftpboot)

In my experience this is not exactly a lucky choice; if youu have to
maintain more than just a few boards, you definitely want to have a
subdirectory per board in /tftpboot.

> it is not always good to call the binary simply u-boot.bin.

...which then is not problem any more.

> I guess "make DESTDIR=<destination> TARGET=<name> install" would work
> 
> Alternatively, we collect the final binary from several variables,

One question remains: what is "the final binary"?  for  example,  for
the  "kilauea"  board  it  may be "u-boot.bin" (when booting from NOR
flash), but it might also be "u-boot-nand.bin" (when booting from NOR
flash). Oh, and board "foo"  uses  not  the  binary  image,  but  the
S-Record  file  in  their factory installer, so we use "u-boot.srec".
Another  board  requires  am  Intel  hex   image,   so   they   build
"u-boot.hex". For the Marvell processors, we will use a special image
format,  so  it's "u-boot.kwb". BlackFin uses some similar mechanism,
but a different name, IIRC.

And no, we definitlely do not always want to build (and install) all
these images. That would be just a waste of resources.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can't say I've ever been lost, but I was bewildered once for  three
days.                                     - Daniel Boone (Attributed)

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[ksi at koi8.net]

On Thu, 13 Aug 2009, Ulf Samuelsson wrote:

> Many packages support installing the resulting binary in another
> location, but U-Boot does not.
> 
> When you use buildsystems like buildroot and openembedded,
> you want to collect the end result in a target directory,
> and while you can use internal knowledge about u-boot
> to do so, it seems cleaner to me, to do a "make DESTDIR install".
> 
> Since you may want to put the binaries for several
> boards in the same directory (like /tftpboot)
> it is not always good to call the binary simply u-boot.bin.
> 
> I guess "make DESTDIR=<destination> TARGET=<name> install" would work
> 
> Alternatively, we collect the final binary from several variables,
> 
> openembedded typically calls the end binary:
> ${MACHINE}-u-boot-${U_BOOT_VERSION}-${REVISION}.bin
> 
> Feedback?

IMHO it is not worth the effort... U-Boot builds its binary in source root
and there is no "make install" at all. When one builds RPM or whatever
packages (as I do) it is not big deal to move the resulting binary elsewhere
with a single "mv" command.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Ulf Samuelsson]

Wolfgang Denk skrev:
> Dear Ulf Samuelsson,
> 
> In message <4A843392.4020800@atmel.com> you wrote:
>> Many packages support installing the resulting binary in another
>> location, but U-Boot does not.
>>
>> When you use buildsystems like buildroot and openembedded,
>> you want to collect the end result in a target directory,
>> and while you can use internal knowledge about u-boot
>> to do so, it seems cleaner to me, to do a "make DESTDIR install".
> 
> Did you consider using out-of-tree builds for that? 

This still means that the external buildsystem need to
know the internals of u-boot.

It must know that the binary is called u-boot.bin
and where it is located (topdir).

> 
>> Since you may want to put the binaries for several
>> boards in the same directory (like /tftpboot)
> 
There is nothing to stop me calling u-boot with

make DESTDIR=/tftpboot/$(MACHINE)
TARGET=$(MACHINE)-u-boot-$(U_BOOT_VERSION)-$(REVISION).bin install


> In my experience this is not exactly a lucky choice; if youu have to
> maintain more than just a few boards, you definitely want to have a
> subdirectory per board in /tftpboot.
> 
>> it is not always good to call the binary simply u-boot.bin.
> 
> ...which then is not problem any more.

If you maintain just a couple of boards, then it is inconvenient to
have a subdirectory.
If the tftp command in u-boot would fetch from that subdirectory
automatically, then it would be less of a pain.

> 
>> I guess "make DESTDIR=<destination> TARGET=<name> install" would work
>>
>> Alternatively, we collect the final binary from several variables,
> 
> One question remains: what is "the final binary"?  for  example,  for
> the  "kilauea"  board  it  may be "u-boot.bin" (when booting from NOR
> flash), but it might also be "u-boot-nand.bin" (when booting from NOR
> flash). Oh, and board "foo"  uses  not  the  binary  image,  but  the
> S-Record  file  in  their factory installer, so we use "u-boot.srec".
> Another  board  requires  am  Intel  hex   image,   so   they   build
> "u-boot.hex". For the Marvell processors, we will use a special image
> format,  so  it's "u-boot.kwb". BlackFin uses some similar mechanism,
> but a different name, IIRC.

I am happy with u-boot.bin as a default,
but there is nothing stopping you from adding more parameters
like FORMAT=srec or FORMAT=hex.

If we come to use Kconfig, there will likely be board specific things
which can be used.

ifeq ($(CONFIG_BOARD_KILAUEA),y)
ifeq ($(CONFIG_BOARD_KILAUEA_NAND),y)
INSTALL_TARGETS += u-boot-nand.bin
else
INSTALL_TARGETS += u-boot.bin
end
endif

I think there are plenty of different solutions to this.

> 
> And no, we definitlely do not always want to build (and install) all
> these images. That would be just a waste of resources.
> 

You build what you currently build, and the make install
will copy that to another place.
I see no harm in copying both u-boot.bin and u-boot.srec,
since it is easier to delete what you see you do not need
than to get what you are not even aware is existing.

With the current method,assuming u-boot.bin is what you always
wanted in the past, u-boot.kwb would certainly NOT have been copied.



> Best regards,
> 
> Wolfgang Denk
> 

BR
Ulf Samuelsson

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Ulf Samuelsson]

ksi at koi8.net skrev:
> On Thu, 13 Aug 2009, Ulf Samuelsson wrote:
> 
>> Many packages support installing the resulting binary in another
>> location, but U-Boot does not.
>>
>> When you use buildsystems like buildroot and openembedded,
>> you want to collect the end result in a target directory,
>> and while you can use internal knowledge about u-boot
>> to do so, it seems cleaner to me, to do a "make DESTDIR install".
>>
>> Since you may want to put the binaries for several
>> boards in the same directory (like /tftpboot)
>> it is not always good to call the binary simply u-boot.bin.
>>
>> I guess "make DESTDIR=<destination> TARGET=<name> install" would work
>>
>> Alternatively, we collect the final binary from several variables,
>>
>> openembedded typically calls the end binary:
>> ${MACHINE}-u-boot-${U_BOOT_VERSION}-${REVISION}.bin
>>
>> Feedback?
> 
> IMHO it is not worth the effort... U-Boot builds its binary in source root
> and there is no "make install" at all. When one builds RPM or whatever
> packages (as I do) it is not big deal to move the resulting binary elsewhere
> with a single "mv" command.
> 

You forget that things change, and the "make install" puts
the responsibility for handling the installation inside u-boot
instead of outside u-boot.


u-boot is not only u-boot, since you have u-boot-tools
which are used to create the image and also
tools which can be running on the target.

Assume that a tool for the target is added
and other tools rely on that tool?
Since you have not updated your external Makefile
to also "mv" that file, you will be delivering
a broken system.

The effort is probably considerably less than what is spent
on discussing many items on this list.


> ---
> ******************************************************************
> *  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
> *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
> ******************************************************************
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4A84779F.7010201@atmel.com> you wrote:
>
> This still means that the external buildsystem need to
> know the internals of u-boot.

You always have to know the interface to the U-Boot build framework,
there is no way around that.

> There is nothing to stop me calling u-boot with
> 
> make DESTDIR=/tftpboot/$(MACHINE)
> TARGET=$(MACHINE)-u-boot-$(U_BOOT_VERSION)-$(REVISION).bin install

Well, you must know that the U-Boot build framework does support these
options (or whatever they might be called), assuming they existed.

> If you maintain just a couple of boards, then it is inconvenient to
> have a subdirectory.
> If the tftp command in u-boot would fetch from that subdirectory
> automatically, then it would be less of a pain.

Well, that's the default for many board configurations - at least for
all where I have something to say about the implementation.

It's in your hands to make it the default for all your boards, too.

> I am happy with u-boot.bin as a default,
> but there is nothing stopping you from adding more parameters
> like FORMAT=srec or FORMAT=hex.

I'm not sure if this is the right approch. To me it seems that a small
wrapper script, optimized for your (or my) purpose, is much more
flexible and does not pollute the Makefile for features only very
few people ever need.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The Wright Bothers weren't the first to fly. They were just the first
not to crash.

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Ulf Samuelsson]

Wolfgang Denk skrev:
> Dear Ulf Samuelsson,
> 
> In message <4A84779F.7010201@atmel.com> you wrote:
>> This still means that the external buildsystem need to
>> know the internals of u-boot.
> 
> You always have to know the interface to the U-Boot build framework,
> there is no way around that.

Yes, but today U-Boot does not provide any interface for copying
the build result to another place.
People have to dig into internals and if internals change,
then it is likely to be detected by something breaking.

> 
>> There is nothing to stop me calling u-boot with
>>
>> make DESTDIR=/tftpboot/$(MACHINE)
>> TARGET=$(MACHINE)-u-boot-$(U_BOOT_VERSION)-$(REVISION).bin install
> 
> Well, you must know that the U-Boot build framework does support these
> options (or whatever they might be called), assuming they existed.

Yes, but a "make install" is a much more stable interface.

>> If you maintain just a couple of boards, then it is inconvenient to
>> have a subdirectory.
>> If the tftp command in u-boot would fetch from that subdirectory
>> automatically, then it would be less of a pain.
> 
> Well, that's the default for many board configurations - at least for
> all where I have something to say about the implementation.

The proposal does not stop anyone from doing this.
You can do
make DESTDIR=/tftpboot TARGET=u-boot.bin install
make DESTDIR=/tftpboot/$(MACHINE) TARGET=u-boot-bin install
make DESTDIR=/tftpboot/$(MACHINE) \
	TARGET=$(MACHINE)-u-boot-$(U_VER)-$(REV).bin install

I am quite happy to let you put your binaries in the directory
of your choice.


> It's in your hands to make it the default for all your boards, too.
> 
>> I am happy with u-boot.bin as a default,
>> but there is nothing stopping you from adding more parameters
>> like FORMAT=srec or FORMAT=hex.
> 
> I'm not sure if this is the right approch. To me it seems that a small
> wrapper script, optimized for your (or my) purpose, is much more
> flexible and does not pollute the Makefile for features only very
> few people ever need.

I think the open source community has converged on the
"make DESTDIR=<dir> install" method

The important thing is however that the solution is
1) INSIDE the U-Boot tree
2) Designed to be stable, even if U-Boot evolves.
3) Documented so it is easy to use.

If your proposal is that the "wrapper" script is outside u-boot,
then this is nothing new. This is how it is done today,
Having wrapper scripts to an unstable interface is an
accident waiting to happen.

You have a unique position as the maintainer of U-Boot.
You know immediately when your scripts needs to be updated.
People working on a build environment does not neccessarily
have that knowledge, and if not, will run into trouble,
or rather their customers might.

Maybe I misunderstand you and you propose that the build-script
should be inside the tree.
Please clarify!




> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4A864121.908@atmel.com> you wrote:
>
> I think the open source community has converged on the
> "make DESTDIR=<dir> install" method

$ cd linux
$ make at91rm9200dk_defconfig
$ make uImage
$ mkdir /tmp/foo
$ mkdir DESTDIR=/tmp/foo install
...
  CHK     include/linux/compile.h
  Kernel: arch/arm/boot/Image is ready
/bin/sh /home/wd/git/linux/work/arch/arm/boot/install.sh 2.6.30-rc8-01295-g06b727a \
        arch/arm/boot/Image System.map "/boot"
Installing normal kernel
/home/wd/git/linux/work/arch/arm/boot/install.sh: line 40: /boot/vmlinux-2.6.30-rc8-01295-g06b727a: Permission denied
cp: cannot create regular file `/boot/System.map-2.6.30-rc8-01295-g06b727a': Permission denied
You have to install it yourself

Hmmm... doesn't seem to ork for me.

> The important thing is however that the solution is

Important for what?

> 1) INSIDE the U-Boot tree
> 2) Designed to be stable, even if U-Boot evolves.
> 3) Documented so it is easy to use.

So far you seem to be the only person who needs this.

> If your proposal is that the "wrapper" script is outside u-boot,
> then this is nothing new. This is how it is done today,
> Having wrapper scripts to an unstable interface is an
> accident waiting to happen.

Could you please explain which part of  this  has  been  an  unstable
interface?  As  far  as  I  can  tell PPCBoot / ARMBoot / U-Boot have
always created the "final binary image" as you called it in  the  top
level  directory,  and  also  it's  name  has  never changed. So what
exactly is unstable here?

> You have a unique position as the maintainer of U-Boot.

I don't. The U-Boot project is driven by a community. If a clear
majority of voices requests something I would have hard times to make
my way.

> You know immediately when your scripts needs to be updated.

Fact is that I am using some scripts that are 10 years old  now,  and
there  has  never  been need to change them because of changes in the
PPCBoot/ARMBoot/U-Boot "interface" - not even when ARMBoot was forked
from PPCBoot, nor when PPCBoot and  ARMBoot  were  merged  back  into
U-Boot.

> People working on a build environment does not neccessarily
> have that knowledge, and if not, will run into trouble,
> or rather their customers might.
> 
> Maybe I misunderstand you and you propose that the build-script
> should be inside the tree.
> Please clarify!

I still fail to understand which sort of trouble you are talking about.


BTW: the usual way to suggest code changes is to submit  a  patch  as
RFC.  If  your  code looks clean and works fine across architectures,
with  and  without  out-of-tree  builds,  and  if  it  includes  some
documentation  I  see  little reason to reject it. Our general policy
has always been to accept stuff that is technically clean, when it is
useful to at least some, as long as it doesn't hurt all the others.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Ulf Samuelsson]

Wolfgang Denk skrev:
> Dear Ulf Samuelsson,
> 
> In message <4A864121.908@atmel.com> you wrote:
>> I think the open source community has converged on the
>> "make DESTDIR=<dir> install" method
> 
> $ cd linux
> $ make at91rm9200dk_defconfig
> $ make uImage
> $ mkdir /tmp/foo
> $ mkdir DESTDIR=/tmp/foo install
> ...
>   CHK     include/linux/compile.h
>   Kernel: arch/arm/boot/Image is ready
> /bin/sh /home/wd/git/linux/work/arch/arm/boot/install.sh 2.6.30-rc8-01295-g06b727a \
>         arch/arm/boot/Image System.map "/boot"
> Installing normal kernel
> /home/wd/git/linux/work/arch/arm/boot/install.sh: line 40: /boot/vmlinux-2.6.30-rc8-01295-g06b727a: Permission denied
> cp: cannot create regular file `/boot/System.map-2.6.30-rc8-01295-g06b727a': Permission denied
> You have to install it yourself
> 
> Hmmm... doesn't seem to ork for me.

There are plenty examples of where it will work, as you know.

> 
>> The important thing is however that the solution is
> 
> Important for what?

To avoid that external build systems break if anything changes in u-boot.

> 
>> 1) INSIDE the U-Boot tree
>> 2) Designed to be stable, even if U-Boot evolves.
>> 3) Documented so it is easy to use.
> 
> So far you seem to be the only person who needs this.
> 
>> If your proposal is that the "wrapper" script is outside u-boot,
>> then this is nothing new. This is how it is done today,
>> Having wrapper scripts to an unstable interface is an
>> accident waiting to happen.
> 
> Could you please explain which part of  this  has  been  an  unstable
> interface?  As  far  as  I  can  tell PPCBoot / ARMBoot / U-Boot have
> always created the "final binary image" as you called it in  the  top
> level  directory,  and  also  it's  name  has  never changed. So what
> exactly is unstable here?

You mentioned yourself that Marvell want to have something different
than u-boot.bin

> 
>> You have a unique position as the maintainer of U-Boot.
> 
> I don't. The U-Boot project is driven by a community. If a clear
> majority of voices requests something I would have hard times to make
> my way.

I am not talking about decisions, I am talking about you not running
into problems, if anything changes, because you know it by heart.

> 
>> You know immediately when your scripts needs to be updated.
> 
> Fact is that I am using some scripts that are 10 years old  now,  and
> there  has  never  been need to change them because of changes in the
> PPCBoot/ARMBoot/U-Boot "interface" - not even when ARMBoot was forked
> from PPCBoot, nor when PPCBoot and  ARMBoot  were  merged  back  into
> U-Boot.
> 
>> People working on a build environment does not neccessarily
>> have that knowledge, and if not, will run into trouble,
>> or rather their customers might.
>>
>> Maybe I misunderstand you and you propose that the build-script
>> should be inside the tree.
>> Please clarify!
> 
> I still fail to understand which sort of trouble you are talking about.
> 

[U-Boot] RFC: "make DESTDIR=xxx install" ?

[Wolfgang Denk]

Dear Ulf Samuelsson,

In message <4A86814F.1070805@atmel.com> you wrote:
>
> >> The important thing is however that the solution is
> > 
> > Important for what?
> 
> To avoid that external build systems break if anything changes in u-boot.

I don;t see any risk of such breakage, because U-Boot does not exactly
have a tradition to change these things avery few weeks.

> > Could you please explain which part of  this  has  been  an  unstable
> > interface?  As  far  as  I  can  tell PPCBoot / ARMBoot / U-Boot have
> > always created the "final binary image" as you called it in  the  top
> > level  directory,  and  also  it's  name  has  never changed. So what
> > exactly is unstable here?
> 
> You mentioned yourself that Marvell want to have something different
> than u-boot.bin

New features get added, indeed. But this does not count here - we were
discussing stability of existing interfaces, and these haven't
changed.

> > I don't. The U-Boot project is driven by a community. If a clear
> > majority of voices requests something I would have hard times to make
> > my way.
> 
> I am not talking about decisions, I am talking about you not running
> into problems, if anything changes, because you know it by heart.

Well, if there would be changes to any "install" interface you had to
know about these as well.

> > Fact is that I am using some scripts that are 10 years old  now,  and
> > there  has  never  been need to change them because of changes in the
> > PPCBoot/ARMBoot/U-Boot "interface" - not even when ARMBoot was forked
> > from PPCBoot, nor when PPCBoot and  ARMBoot  were  merged  back  into
> > U-Boot.
...
> You say that you did not  write any new buildscripts
> which did not copy anything except u-boot.bin?

No, I didn't day that. Don't twist my words. I wrote that I  did  not
have  to  change  existing  scripts because existing interfaces never
changed.

And that was what you complained about: the rist that existing
interfaces might change below your feet.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Unix: Some say the learning curve is steep,  but  you  only  have  to
climb it once.                                      - Karl Lehenbauer