[Buildroot] svn commit: trunk/buildroot/target/linux
Jean-Christian de Rivaz
jc at eclis.ch
Wed Apr 16 18:22:46 UTC 2008
Ulf Samuelsson a écrit :
>
>> Ulf Samuelsson a écrit :
>>>> I think that we mess with two different goals:
>>>>
>>>> 1) Allow the build to complete by not using "/tftpboot". This is really
>>>> important. As pointed many times:
>>>> - System don't have alway a /tftpboot.
>>>> - It is not alway writable by the users.
>>>> - Superuser are not alway ok to do a /tftpboot just for an application.
>>> Linux is not built by default.
>> Are you talking about the Linux kernel ? If yes, this is not true at
>> least for the at91sam9261 target.
>>
>>> If you enable Linux, then the normal build is the default.
>> Sorry, I don't understand your sentence. I make the test by using the
>> default configuration of the at91sam9261 target. What do you means by
>> "enable Linux" ?
>>
>
> The default is not when you use the make <XXX>_defconfig.
> They you are using a predefined board, and that may have
> configuration items which are different from default settings.
>
> Default is when you do the make menuconfig from scratch.
I am very surprised by this response. Users take buildroot because it
have a target (that means an XXX_defconfig) that match there board (if
it's a development kit) or that is a starting point to match there
custom board. Maintainers taking buildroot for a new target will
probably start by duplicate and modifying an existing XXX_defconfig that
there will publish for the users. Configuring from scratch can be a
painful and time consuming exercise that request knowledge in many area.
I take buildroot after some search on the internet about works related
to the AT91SAM9261 processor. The first thing I tryed have been to do a
make at91sam9261ek_deconfig and a make, just to evaluate the project
maturity. I started the make menuconfig, but frankly I was boring to
search what I should change in so many settings to get something working
while a ready to go XXX_defconfig already exists. Just an an example:
the make menuconfig have u-boot deselected by default, but without it
the at91sam9261 target failed to compile. There is many traps like this
one. It take many try an error cycle to find a good setting. I suspect
that many users are likely to prefer to start from a "make
XXX_defconfig" that just work. Anyway when a user have found a
configuration that match there needs, it will save it configuration file
and will use the menuconfig only to adjust a setting.
My point is that it's a bad idea trying to see two differents process
between the make menuconfig and the make XXX_defconfig. The two methods
should work out of the box.
>>> The problem only occurs when you do the advanced build
>>> and have the COPYTO_TFTPBOOT set.
>> Again what an "advanced build". If I wants to change the tftpboot path I
>> simply edit the .config file. This method, default config or changes
>> made by menuconfig make no difference for the Makefile.
>>
>
> "Advanced build" is a selection done in the target/linux/Config.in's.
I my test I never changed the Linux kernel configuration, only the top
level ".config". In fact I used exactly this command:
git clean -dfx && git reset --hard && git svn rebase && ( yes "" | make
at91sam9261ek_defconfig ) && mv .config .config.def && sed
's#/tftpboot#/var/lib/tftpboot#' < .config.def > .config && ( yes "" |
make )
Because on my system there is no such /tftpboot thing.
>>> There is an easy workaround, and that is to disable copying to /tftpboot if there is a problem.
>>> You can always copy manually from your BINARIES to wherever,
>>> or use the programmable COPYTO.
>> Yes, but this is not obvious from the user perspective.
>>
>
> You only need to learn once.
I have changed the sed command of the above command to this:
sed
's#/tftpboot#/var/lib/tftpboot#;s#BR2_LINUX_COPYTO_TFTPBOOT=y#BR2_LINUX_COPYTO_TFTPBOOT=n#'
< .config.def > .config
Now the build can be completed, after this 3 commands:
yes "" | make
cp -pf
project_build_arm/at91sam9261ek/linux-2.6.24.3/arch/arm/boot/uImage
project_build_arm/at91sam9261ek/linux-2.6.24.3/uImage
yes "" | make
>>> Question is how much we need to protect the user from impossible combinations.
>> As mush as possible by replacing difficult and fragile things by simple
>> and reliable ones.
>
>
>>>> - It will not work as expected in case multiple users run buildroot.
>>>> - It is the wrong path for a TFTP server in many new distributions.
>>>> So I think there is really no point to keep it (other than the effort to
>>>> change little code in target/linux/Makefile.in.advanced). All the
>>>> Makefile targets and results of the build at this stage must be only
>>>> into the buildroot user tree.
>>> The point is that it simplifies the complete build to doing "make".
>> Exactly. Currently this goal in not reach because of the hardcoded
>> /tftpboot in the Makefile.
>
> No, the Makefile is not the problem, the ".config" is the problem,
> and that is an easy fix by the user.
> Now, the build will continue if the copy fails.
Sorry but I found this way of doing thing not a clean fix, but a hack.
The problem is booth the Makefile and the ".config". The
BR2_LINUX_COPYTO_TFTPBOOT must be removed completely in a way that the
build in granted to complete whatever is set into BR2_LINUX_COPYTO. This
last one could be by default "/tftpboot" if you like and must be the
absolutely last operation of the full build process, like if the user
manually copy the result files into the TFTP server directory. Really,
BR2_LINUX_COPYTO_TFTPBOOT is a terrible bad thing that bring absolutely
no feature that can't be done by BR2_LINUX_COPYTO alone. It only make
thing confusing and error prone.
>>>> 2) Option to copy the result of the build into the TFTP server
>>>> directory. This stage simply take the result of the previous stage and
>>>> allow to have ready to go files available with the TFTP protocol at the
>>>> end of the build. Technically the best way would be to know if there is
>>>> a TFTP server installed and use the directory he serve as a default, or
>>>> to not make a copy if none is installed. As this idea seem difficult to
>>>> make, I agree that we can live with "/tftpboot" by default, even if I
>>>> suspect that "/var/lib/tftpboot" will be more and more appropriate.
>>>>
>>>> This will not solve the possibility that multiple users clash there
>>>> files into the TFTP directory, but at least this remove any possibility
>>>> that there build are broken because of a common target in there
>>>> Makefiles. Users that wants to share a common TFTP server should take
>>>> each others to agree to a directory structure into the TFTP server that
>>>> let each of them have a private space for theres files.
>>> As long as they do not use the same project name, there is no conflict.
>>> That is the purpose of the long file names.
>> Multiples users can work on the same targets.
>
> And they will have to understand the conflict and
> can use "make menuconfig" to resolve the problem.
> An easy way to do this, is to call the project:
> "Jean-Christian-at91sam9261"
> Then the binaries in will contain files like:
> "Jean-Christian-at91sam9261-linux-2.6.24.bin"
I have not tryed this, but after the build I have thoses file into the
/var/lib/tftpboot:
-rw-r--r-- 1 jcdr jcdr 553 2008-04-16 20:12 autoscript.at91sam9261ek
-rwxr-xr-x 1 jcdr jcdr 200708 2008-04-16 20:12
at91sam9261ek-u-boot-1.2.0-atmel-20080416.bin
drwxrwxrwx 2 root root 4096 2008-04-16 20:12 .
-rwxr-xr-x 1 jcdr jcdr 4100 2008-04-16 20:12
at91sam9261ek-dataflashboot-2.3.4.bin
-rw-r--r-- 1 jcdr jcdr 1611128 2008-04-16 20:17 uImage
I wonder why the "uImage" is not prefixed with a "at91sam9261ek".
--
Jean-Christian de Rivaz
More information about the buildroot
mailing list