Wolfgang Denk skrev: > Dear Ulf Samuelsson, > > In message <[email protected]> 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. > >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 > _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
