Hello Simon, +Andreas,
On 06-02-15 04:05, Simon Glass wrote:
Hi Jeroen,
On 5 February 2015 at 12:51, Jeroen Hofstee<jer...@myspectrum.nl> wrote:
Hello Guilherme,
Thanks for commenting on this,
On 02/05/15 13:27, Guilherme Maciel Ferreira wrote:
Hi Jeroen,
My apologies, I didn't test the tools on BSD. The answers are inline.
Best regards,
Guilherme
Am 04.02.2015 19:37 schrieb "Jeroen Hofstee"<jer...@myspectrum.nl>:
Hello Guilherme / Simon,
It seems that commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c,
"tools: moved code common to all image tools to a separated module."
I guess the culprit is commit a93648d197df48fa46dd55f925ff70468bd81c71,
"imagetool: replace image registration function by linker_lists feature".
Because that commit introduced the linker script to imagetools.
Likely, since some patches depend on each other I was unable to revert
a single commit.
Anyway as far as I am concerned there are two separate
build targets, the bare u-boot having an (almost) naked compiler, beside
stdarg and stdbool? without any other host includes or objects (well with
CONFIG_USE_PRIVATE_LIBGCC=y). U-boot provides linker scripts for them,
and we have fine grained control over them and an excuse to throw any
trick at them if it makes things faster / smaller etc. It is still nice if
this
compiles anywhere though..
On the other hand there are "tools" for the host / target userland, which
should build against the host / targets "std*". Those things should be
buildable
on any decent host / target and be straightforward (and _not_ define KERNEL
etc, since it are userland tools). There is no linker for them afaik, so
tweaking
them seems like a bad idea. Hence I am tempted to remove the use of
linker generated lists from tools...
- and really last, how do I test if it works..
There are two scripts to test the image tools, test-imagetools.sh and
test-fit.py. Running those scripts you make sure the linker list is
properly setup, because it is required by the imagetools to find the image
type.
$ make O=sandbox clean
$ make O=sandbox sandbox_config
$ make mrproper
$ make O=sandbox
$ ./test/image/test-imagetools.sh
$ ./test/image/test-fit.py -u sandbox/u-boot
Sandbox used to build on FreeBSD, but it is quite a mess at the moment.
But a I said, I think the best solution for tools is not to use linker
generated
list in the first place for tools.
Sandbox uses driver model so has the same problem. How can we solve this?
Why is the FreeBSD toolchain so different? Does it not have the
concept of link scripts?
First of all, the biggest problem for sandbox at the moment are header
files.
For a "normal" cross target this works fine since the target uses u-boot
headers
(linux/*) and the tools the (std*). For sandbox we end up with both of
them included at the same time at the moment, leading to redefinitions
of uint64_t, time_t, ptrdiff_t, fd_set etc. I will have to look in more
details
if this is fixable. It is a different problem then the link error since
it already
errors before attempting to link.
Regarding the linking problem, there is nothing special about FreeBSD ld,
it just is based on a version which has no idea what INSERT BEFORE .data
means.
there are several option I guess (not tested):
1) include a complete linker script so INSERT BEFORE .data is not needed
2) teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
3) don't use linker magic in tools (and use a linux box for sandbox, at
least for now)
1) sounds like a bad idea, the target/host might be any arch e.g.
2) won't magically fix problems as well, even if FreeBSD trunk can be
teached to understand
this, things will still be broken on releases. And u-boot tools work on
more host systems,
Andreas, can you check if Darwin is still able to compile tools from
u-boot master?
3) the option I would be tempted to choose, just don't do linker magic
for tools. This would
make sure at least mkimage etc can be build everywhere. sandbox won't
build, but as said
it is already broken because of other issues. (and I doubt there is even
an single user around
besides me to even try to build sandbox on FreeBSD).
So as far as I am concerned we go for option 3.
Regards,
Jeroen
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
