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