[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hello Simon, +Andreas,

On 06-02-15 04:05, Simon Glass wrote:
> Hi Jeroen,
>
> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen at 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"<jeroen at 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