[U-Boot] RFC: "make DESTDIR=xxx install" ?
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
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
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
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
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
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?
- INSIDE the U-Boot tree
- Designed to be stable, even if U-Boot evolves.
- 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
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.
- INSIDE the U-Boot tree
- Designed to be stable, even if U-Boot evolves.
- 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.
From the documentation:
... This will generate the SPL image in the "nand_spl" directory: nand_spl/u-boot-spl.bin Also another image is created spanning a whole NAND block (16kBytes): nand_spl/u-boot-spl-16k.bin The main NAND U-Boot image is generated in the toplevel directory: u-boot.bin A combined image of u-boot-spl-16k.bin and u-boot.bin is also created: u-boot-nand.bin
... You say that you did not write any new buildscripts which did not copy anything except u-boot.bin?
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.
Thanks,
Best regards,
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
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@home KOI8 Net < > The impossible we do immediately. * * Las Vegas NV, USA < > Miracles require 24-hour notice. * ******************************************************************
ksi@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@home KOI8 Net < > The impossible we do immediately. *
- Las Vegas NV, USA < > Miracles require 24-hour notice. *
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (3)
-
ksi＠koi8.net -
Ulf Samuelsson -
Wolfgang Denk