[U-Boot] recent tools on FreeBSD

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hello Guilherme / Simon,

It seems that commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c,
"tools: moved code common to all image tools to a separated module."

cause some trouble when building on FreeBSD.

/usr/bin/ld:./tools/imagetool.lds:24: syntax error
cc: error: linker command failed with exit code 1 (use -v to see invocation)

which is about the last line, /* INSERT BEFORE .data; */

And thereafter about:
/usr/lib/crt1.o: In function `_start':
/usr/src/lib/csu/amd64/crt1.c:(.text+0x90): undefined reference to 
`__preinit_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x95): undefined reference to 
`__preinit_array_end'
/usr/src/lib/csu/amd64/crt1.c:(.text+0xb1): undefined reference to 
`__preinit_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0xb6): undefined reference to 
`__preinit_array_end'
/usr/src/lib/csu/amd64/crt1.c:(.text+0xd4): undefined reference to 
`__preinit_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0xf9): undefined reference to 
`__init_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0xfe): undefined reference to 
`__init_array_end'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x11a): undefined reference to 
`__init_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x11f): undefined reference to 
`__init_array_end'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x144): undefined reference to 
`__init_array_start'
/usr/lib/crt1.o: In function `finalizer':
/usr/src/lib/csu/amd64/crt1.c:(.text+0x187): undefined reference to 
`__fini_array_start'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference to 
`__fini_array_end'
/usr/src/lib/csu/amd64/crt1.c:(.text+0x1b4): undefined reference to 
`__fini_array_start'
/usr/bin/ld: tools/mkenvimage: hidden symbol `__preinit_array_start' 
isn't defined

Which seems to be about missing sections. The (default) ld on FreeBSD 
branched of from an old version [1],
With below patch [2] things build at least.

Some question about this:
- why do we need linker magic for tools at all? Given that there is no 
custom linker script for tools (or I failed
   to find it), this adds a dependency between the host default linker 
script and the tweaks in imagetool.lds
- what it the INSERT BEFORE .data supposed to do?
- and last but not least, how can we make this work in general
- and really last, how do I test if it works..

With kind regards,
Jeroen

[1]
ld --version
GNU ld 2.17.50 [FreeBSD] 2007-07-03

[2]
diff --git a/tools/imagetool.lds b/tools/imagetool.ldsdiff --git 
a/tools/imagetool.lds b/tools/imagetool.lds
index 7e92b4a..b18eadb 100644
--- a/tools/imagetool.lds
+++ b/tools/imagetool.lds
@@ -19,6 +19,17 @@ SECTIONS
         __u_boot_sandbox_option_end = .;

         __bss_start = .;
+
+       . = ALIGN(32 / 8);
+         PROVIDE (__preinit_array_start = .);
+         .preinit_array     : { *(.preinit_array) }
+         PROVIDE (__preinit_array_end = .);
+         PROVIDE (__init_array_start = .);
+         .init_array     : { *(.init_array) }
+         PROVIDE (__init_array_end = .);
+         PROVIDE (__fini_array_start = .);
+         .fini_array     : { *(.fini_array) }
+         PROVIDE (__fini_array_end = .);
  }

-INSERT BEFORE .data;
+/* INSERT BEFORE .data; */

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Jeroen,

On 4 February 2015 at 12:37, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Guilherme / Simon,
>
> It seems that commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c,
> "tools: moved code common to all image tools to a separated module."
>
> cause some trouble when building on FreeBSD.
>
> /usr/bin/ld:./tools/imagetool.lds:24: syntax error
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>
> which is about the last line, /* INSERT BEFORE .data; */
>
> And thereafter about:
> /usr/lib/crt1.o: In function `_start':
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x90): undefined reference to
> `__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x95): undefined reference to
> `__preinit_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb1): undefined reference to
> `__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb6): undefined reference to
> `__preinit_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xd4): undefined reference to
> `__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xf9): undefined reference to
> `__init_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xfe): undefined reference to
> `__init_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11a): undefined reference to
> `__init_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11f): undefined reference to
> `__init_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x144): undefined reference to
> `__init_array_start'
> /usr/lib/crt1.o: In function `finalizer':
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x187): undefined reference to
> `__fini_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference to
> `__fini_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x1b4): undefined reference to
> `__fini_array_start'
> /usr/bin/ld: tools/mkenvimage: hidden symbol `__preinit_array_start' isn't
> defined
>
> Which seems to be about missing sections. The (default) ld on FreeBSD
> branched of from an old version [1],
> With below patch [2] things build at least.
>
> Some question about this:
> - why do we need linker magic for tools at all? Given that there is no
> custom linker script for tools (or I failed
>   to find it), this adds a dependency between the host default linker script
> and the tweaks in imagetool.lds
> - what it the INSERT BEFORE .data supposed to do?
> - and last but not least, how can we make this work in general
> - and really last, how do I test if it works..
>
> With kind regards,
> Jeroen
>
> [1]
> ld --version
> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>
> [2]
> diff --git a/tools/imagetool.lds b/tools/imagetool.ldsdiff --git

Where is this file?

> a/tools/imagetool.lds b/tools/imagetool.lds
> index 7e92b4a..b18eadb 100644
> --- a/tools/imagetool.lds
> +++ b/tools/imagetool.lds
> @@ -19,6 +19,17 @@ SECTIONS
>         __u_boot_sandbox_option_end = .;
>
>         __bss_start = .;
> +
> +       . = ALIGN(32 / 8);
> +         PROVIDE (__preinit_array_start = .);
> +         .preinit_array     : { *(.preinit_array) }
> +         PROVIDE (__preinit_array_end = .);
> +         PROVIDE (__init_array_start = .);
> +         .init_array     : { *(.init_array) }
> +         PROVIDE (__init_array_end = .);
> +         PROVIDE (__fini_array_start = .);
> +         .fini_array     : { *(.fini_array) }
> +         PROVIDE (__fini_array_end = .);
>  }
>
> -INSERT BEFORE .data;
> +/* INSERT BEFORE .data; */
>

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hi Simon,

On 05-02-15 04:34, Simon Glass wrote:
> Hi Jeroen,
>
> On 4 February 2015 at 12:37, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> Hello Guilherme / Simon,
>>
>> It seems that commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c,
>> "tools: moved code common to all image tools to a separated module."
>>
>> cause some trouble when building on FreeBSD.
>>
>> /usr/bin/ld:./tools/imagetool.lds:24: syntax error
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>>
>> which is about the last line, /* INSERT BEFORE .data; */
>>
>> And thereafter about:
>> /usr/lib/crt1.o: In function `_start':
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x90): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x95): undefined reference to
>> `__preinit_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb1): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb6): undefined reference to
>> `__preinit_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xd4): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xf9): undefined reference to
>> `__init_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xfe): undefined reference to
>> `__init_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11a): undefined reference to
>> `__init_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11f): undefined reference to
>> `__init_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x144): undefined reference to
>> `__init_array_start'
>> /usr/lib/crt1.o: In function `finalizer':
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x187): undefined reference to
>> `__fini_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference to
>> `__fini_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x1b4): undefined reference to
>> `__fini_array_start'
>> /usr/bin/ld: tools/mkenvimage: hidden symbol `__preinit_array_start' isn't
>> defined
>>
>> Which seems to be about missing sections. The (default) ld on FreeBSD
>> branched of from an old version [1],
>> With below patch [2] things build at least.
>>
>> Some question about this:
>> - why do we need linker magic for tools at all? Given that there is no
>> custom linker script for tools (or I failed
>>    to find it), this adds a dependency between the host default linker script
>> and the tweaks in imagetool.lds
>> - what it the INSERT BEFORE .data supposed to do?
>> - and last but not least, how can we make this work in general
>> - and really last, how do I test if it works..
>>
>> With kind regards,
>> Jeroen
>>
>> [1]
>> ld --version
>> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>>
>> [2]
>> diff --git a/tools/imagetool.lds b/tools/imagetool.ldsdiff --git
> Where is this file?

It is in 2015-04-rc1, see e.g.
http://git.denx.de/?p=u-boot.git;a=blob;f=tools/imagetool.lds;h=7e92b4ac66c811866148540b6c424026ef7abbbc;hb=HEAD

Regards,
Jeroen

[U-Boot] recent tools on FreeBSD

[Guilherme Maciel Ferreira]

Hi Simon,

I introduced that file to use the linker list with the image types.
Like you suggested long time ago.

Best regards,

2015-02-05 1:34 GMT-02:00 Simon Glass <sjg@chromium.org>:
> Hi Jeroen,
>
> On 4 February 2015 at 12:37, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> Hello Guilherme / Simon,
>>
>> It seems that commit f86ed6a8d52c99bb2d17d3cac1647edca0c4399c,
>> "tools: moved code common to all image tools to a separated module."
>>
>> cause some trouble when building on FreeBSD.
>>
>> /usr/bin/ld:./tools/imagetool.lds:24: syntax error
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>>
>> which is about the last line, /* INSERT BEFORE .data; */
>>
>> And thereafter about:
>> /usr/lib/crt1.o: In function `_start':
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x90): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x95): undefined reference to
>> `__preinit_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb1): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb6): undefined reference to
>> `__preinit_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xd4): undefined reference to
>> `__preinit_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xf9): undefined reference to
>> `__init_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0xfe): undefined reference to
>> `__init_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11a): undefined reference to
>> `__init_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11f): undefined reference to
>> `__init_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x144): undefined reference to
>> `__init_array_start'
>> /usr/lib/crt1.o: In function `finalizer':
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x187): undefined reference to
>> `__fini_array_start'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference to
>> `__fini_array_end'
>> /usr/src/lib/csu/amd64/crt1.c:(.text+0x1b4): undefined reference to
>> `__fini_array_start'
>> /usr/bin/ld: tools/mkenvimage: hidden symbol `__preinit_array_start' isn't
>> defined
>>
>> Which seems to be about missing sections. The (default) ld on FreeBSD
>> branched of from an old version [1],
>> With below patch [2] things build at least.
>>
>> Some question about this:
>> - why do we need linker magic for tools at all? Given that there is no
>> custom linker script for tools (or I failed
>>   to find it), this adds a dependency between the host default linker script
>> and the tweaks in imagetool.lds
>> - what it the INSERT BEFORE .data supposed to do?
>> - and last but not least, how can we make this work in general
>> - and really last, how do I test if it works..
>>
>> With kind regards,
>> Jeroen
>>
>> [1]
>> ld --version
>> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>>
>> [2]
>> diff --git a/tools/imagetool.lds b/tools/imagetool.ldsdiff --git
>
> Where is this file?
>
>> a/tools/imagetool.lds b/tools/imagetool.lds
>> index 7e92b4a..b18eadb 100644
>> --- a/tools/imagetool.lds
>> +++ b/tools/imagetool.lds
>> @@ -19,6 +19,17 @@ SECTIONS
>>         __u_boot_sandbox_option_end = .;
>>
>>         __bss_start = .;
>> +
>> +       . = ALIGN(32 / 8);
>> +         PROVIDE (__preinit_array_start = .);
>> +         .preinit_array     : { *(.preinit_array) }
>> +         PROVIDE (__preinit_array_end = .);
>> +         PROVIDE (__init_array_start = .);
>> +         .init_array     : { *(.init_array) }
>> +         PROVIDE (__init_array_end = .);
>> +         PROVIDE (__fini_array_start = .);
>> +         .fini_array     : { *(.fini_array) }
>> +         PROVIDE (__fini_array_end = .);
>>  }
>>
>> -INSERT BEFORE .data;
>> +/* INSERT BEFORE .data; */
>>
>
> Regards,
> Simon



-- 
Guilherme Maciel Ferreira
Mobile Brazil: +55 48 9917 3969
Site: http://guilhermemacielferreira.com/
Skype: guilherme.maciel.ferreira

[U-Boot] recent tools on FreeBSD

[Guilherme Maciel Ferreira]

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@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.


>
> cause some trouble when building on FreeBSD.
>
> /usr/bin/ld:./tools/imagetool.lds:24: syntax error
> cc: error: linker command failed with exit code 1 (use -v to see
invocation)
>
> which is about the last line, /* INSERT BEFORE .data; */
>
> And thereafter about:
> /usr/lib/crt1.o: In function `_start':
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x90): undefined reference to
`__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x95): undefined reference to
`__preinit_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb1): undefined reference to
`__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xb6): undefined reference to
`__preinit_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xd4): undefined reference to
`__preinit_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xf9): undefined reference to
`__init_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0xfe): undefined reference to
`__init_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11a): undefined reference to
`__init_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x11f): undefined reference to
`__init_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x144): undefined reference to
`__init_array_start'
> /usr/lib/crt1.o: In function `finalizer':
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x187): undefined reference to
`__fini_array_start'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x18c): undefined reference to
`__fini_array_end'
> /usr/src/lib/csu/amd64/crt1.c:(.text+0x1b4): undefined reference to
`__fini_array_start'
> /usr/bin/ld: tools/mkenvimage: hidden symbol `__preinit_array_start'
isn't defined
>
> Which seems to be about missing sections. The (default) ld on FreeBSD
branched of from an old version [1],
> With below patch [2] things build at least.
>
> Some question about this:
> - why do we need linker magic for tools at all? Given that there is no
custom linker script for tools (or I failed
>   to find it), this adds a dependency between the host default linker
script and the tweaks in imagetool.lds

The imagetools.lds is there to allow image types (e.g. FIT, Multimage, ...)
to be placed in a linked list built by the linker (called linker list). The
previous linked list that connected the tools (mkimage and dumpimage) with
the image types, required a lot more code. With the linker list, there is
less code, and most of the linked list setup is performed automatically by
the linker. This explains the linker magic :-)

The imagetool.lds file follows the same approach of other ld scripts in
U-Boot, specially those that create a linked list of U-Boot commands.


> - what it the INSERT BEFORE .data supposed to do?
Each image type object file has a .u_boot_list_2_image_type_2 section. This
section has the code to place each image type in the linked list.

The INSERT BEFORE is supposed to place linker list stuff before the .data
section.


> - and last but not least, how can we make this work in general

First, you have to make sure the BSD linker supports the directives in the
ld script (imagetools.lds). Second, you can use the test scripts (next
topic). Third, check if the directives you introduced are not BSD-specific.


> - 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

I hope it helps.

>
> With kind regards,
> Jeroen
>
> [1]
> ld --version
> GNU ld 2.17.50 [FreeBSD] 2007-07-03
>
> [2]
> diff --git a/tools/imagetool.lds b/tools/imagetool.ldsdiff --git
a/tools/imagetool.lds b/tools/imagetool.lds
> index 7e92b4a..b18eadb 100644
> --- a/tools/imagetool.lds
> +++ b/tools/imagetool.lds
> @@ -19,6 +19,17 @@ SECTIONS
>         __u_boot_sandbox_option_end = .;
>
>         __bss_start = .;
> +
> +       . = ALIGN(32 / 8);
> +         PROVIDE (__preinit_array_start = .);
> +         .preinit_array     : { *(.preinit_array) }
> +         PROVIDE (__preinit_array_end = .);
> +         PROVIDE (__init_array_start = .);
> +         .init_array     : { *(.init_array) }
> +         PROVIDE (__init_array_end = .);
> +         PROVIDE (__fini_array_start = .);
> +         .fini_array     : { *(.fini_array) }
> +         PROVIDE (__fini_array_end = .);
>  }
>
> -INSERT BEFORE .data;
> +/* INSERT BEFORE .data; */
>

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

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@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.

Regards,
Jeroen

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Jeroen,

On 5 February 2015 at 12:51, Jeroen Hofstee <jeroen@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@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?

Regards,
Simon

[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@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@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] recent tools on FreeBSD

[Andreas Bießmann]

Hi,

On 06.02.15 20:56, Jeroen Hofstee wrote:
> Hello Simon, +Andreas,
> 
> On 06-02-15 04:05, Simon Glass wrote:
>> Hi Jeroen,
>>
>> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen@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@myspectrum.nl>:

> 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?

unfortunately it does not.

---8<---
andreas at imac % git describe
v2015.04-rc1-4-g7f641d5
andreas at imac %
PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
...
   gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
ld: unknown option: -T
collect2: error: ld returned 1 exit status
make[1]: *** [tools/envcrc] Error 1
make: *** [tools] Error 2
andreas@imac % gcc --version
gcc (MacPorts gcc49 4.9.2_1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
--->8---

> 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.

+1

Dynamic list-sections is in general a good thing. But beside the linker
problem here we will get another problem on darwin hosts when we want to
read the sections. I added a patch to linux kernel to get around [1].

So I have another option here:

4) setup the lists sections in code, add the magic handling for Mach-O
binaries and remove the linker foo.

Best regards

Andreas Bie?mann

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dd2a3acaecd7abb2d43b09a823cf2e4c967fa2ac

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi,

On 6 February 2015 at 13:40, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Hi,
>
> On 06.02.15 20:56, Jeroen Hofstee wrote:
>> Hello Simon, +Andreas,
>>
>> On 06-02-15 04:05, Simon Glass wrote:
>>> Hi Jeroen,
>>>
>>> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen@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@myspectrum.nl>:
>
>> 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?
>
> unfortunately it does not.
>
> ---8<---
> andreas at imac % git describe
> v2015.04-rc1-4-g7f641d5
> andreas at imac %
> PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
> make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
> ...
>    gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
> tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
> ld: unknown option: -T
> collect2: error: ld returned 1 exit status
> make[1]: *** [tools/envcrc] Error 1
> make: *** [tools] Error 2
> andreas at imac % gcc --version
> gcc (MacPorts gcc49 4.9.2_1) 4.9.2
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> --->8---
>
>> 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.
>
> +1
>
> Dynamic list-sections is in general a good thing. But beside the linker
> problem here we will get another problem on darwin hosts when we want to
> read the sections. I added a patch to linux kernel to get around [1].
>
> So I have another option here:
>
> 4) setup the lists sections in code, add the magic handling for Mach-O
> binaries and remove the linker foo.

The lower-common-denominator approach is a bit frustrating. How does
FreeBSD compile U-Boot? What are you actually using that system for if
it cannot build U-Boot?

Re 1) I found an open in ld to produce the standard link script. I
actually used that before I found INSERT BEFORE.

Before giving up I think it would be worth exploring 1). It should
then be possible to make sandbox work also.

Finally, please point me to how I can install FreeBSD in viritualbox
or similar. I'm interested in that...

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hi Simon,

On 06-02-15 22:00, Simon Glass wrote:
> Hi,
>
> On 6 February 2015 at 13:40, Andreas Bie?mann
> <andreas.devel@googlemail.com> wrote:
>> Hi,
>>
>> On 06.02.15 20:56, Jeroen Hofstee wrote:
>>> Hello Simon, +Andreas,
>>>
>>> On 06-02-15 04:05, Simon Glass wrote:
>>>> Hi Jeroen,
>>>>
>>>> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen@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@myspectrum.nl>:
>>> 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?
>> unfortunately it does not.
>>
>> ---8<---
>> andreas at imac % git describe
>> v2015.04-rc1-4-g7f641d5
>> andreas at imac %
>> PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
>> make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
>> ...
>>     gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
>> tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
>> ld: unknown option: -T
>> collect2: error: ld returned 1 exit status
>> make[1]: *** [tools/envcrc] Error 1
>> make: *** [tools] Error 2
>> andreas at imac % gcc --version
>> gcc (MacPorts gcc49 4.9.2_1) 4.9.2
>> Copyright (C) 2014 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> --->8---
>>
>>> 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.
>> +1
>>
>> Dynamic list-sections is in general a good thing. But beside the linker
>> problem here we will get another problem on darwin hosts when we want to
>> read the sections. I added a patch to linux kernel to get around [1].
>>
>> So I have another option here:
>>
>> 4) setup the lists sections in code, add the magic handling for Mach-O
>> binaries and remove the linker foo.
> The lower-common-denominator approach is a bit frustrating. How does
> FreeBSD compile U-Boot?

I guess I am missing the point here. U-boot v2015.01 builds fine
on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
which no longer builds mkimage on FreeBSD and Darwin.

> What are you actually using that system for if
> it cannot build U-Boot?

I am missing the point, u-boot and its tools build fine until v2015.04-rc1
on FreeBSD and a mac. And this is easily fixed by not using linker magic
for tools. (and yes sandbox likely fails to build, but I don't care that 
much)
> Re 1) I found an open in ld to produce the standard link script. I
> actually used that before I found INSERT BEFORE.
>
> Before giving up I think it would be worth exploring 1). It should
> then be possible to make sandbox work also.

I am not giving up, I think it is sane if a tool which adds a header and
a checksum does not use linker magic.  Sandbox biggest problem is
not the linking, but the fact that linux headers and std* are included,
it is a different topic.

> Finally, please point me to how I can install FreeBSD in viritualbox
> or similar. I'm interested in that...

Just download an install image and start it in virtualbox, see 1.
You might need to change the motherboard type.

doc/README.clang explains how to use the host compiler to cross build
u-boot (for some boards). You can install a gcc cross compiler as well.

[1] https://www.freebsd.org/releases/10.1R/announce.html

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Jeroen,

On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hi Simon,
>
> On 06-02-15 22:00, Simon Glass wrote:
>>
>> Hi,
>>
>> On 6 February 2015 at 13:40, Andreas Bie?mann
>> <andreas.devel@googlemail.com> wrote:
>>>
>>> Hi,
>>>
>>> On 06.02.15 20:56, Jeroen Hofstee wrote:
>>>>
>>>> Hello Simon, +Andreas,
>>>>
>>>> On 06-02-15 04:05, Simon Glass wrote:
>>>>>
>>>>> Hi Jeroen,
>>>>>
>>>>> On 5 February 2015 at 12:51, Jeroen Hofstee<jeroen@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@myspectrum.nl>:
>>>>
>>>> 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?
>>>
>>> unfortunately it does not.
>>>
>>> ---8<---
>>> andreas at imac % git describe
>>> v2015.04-rc1-4-g7f641d5
>>> andreas at imac %
>>> PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
>>> make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
>>> ...
>>>     gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
>>> tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
>>> ld: unknown option: -T
>>> collect2: error: ld returned 1 exit status
>>> make[1]: *** [tools/envcrc] Error 1
>>> make: *** [tools] Error 2
>>> andreas at imac % gcc --version
>>> gcc (MacPorts gcc49 4.9.2_1) 4.9.2
>>> Copyright (C) 2014 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>> --->8---
>>>
>>>> 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.
>>>
>>> +1
>>>
>>> Dynamic list-sections is in general a good thing. But beside the linker
>>> problem here we will get another problem on darwin hosts when we want to
>>> read the sections. I added a patch to linux kernel to get around [1].
>>>
>>> So I have another option here:
>>>
>>> 4) setup the lists sections in code, add the magic handling for Mach-O
>>> binaries and remove the linker foo.
>>
>> The lower-common-denominator approach is a bit frustrating. How does
>> FreeBSD compile U-Boot?
>
>
> I guess I am missing the point here. U-boot v2015.01 builds fine
> on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
> which no longer builds mkimage on FreeBSD and Darwin.
>
>> What are you actually using that system for if
>> it cannot build U-Boot?
>
>
> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
> on FreeBSD and a mac. And this is easily fixed by not using linker magic
> for tools. (and yes sandbox likely fails to build, but I don't care that
> much)

How do you build U-Boot for any of the boards supported? What I mean
is that if you can't handle linker scripts in FreeBSD how do you build
anything beyond the 'tools' build?

The docs for 'ld' seem to indicate that if the -T option is not used
the file is treated as a link script addendum rather than replacing it
entirely. Is that what we want?

>>
>> Re 1) I found an open in ld to produce the standard link script. I
>> actually used that before I found INSERT BEFORE.
>>
>> Before giving up I think it would be worth exploring 1). It should
>> then be possible to make sandbox work also.
>
>
> I am not giving up, I think it is sane if a tool which adds a header and
> a checksum does not use linker magic.  Sandbox biggest problem is
> not the linking, but the fact that linux headers and std* are included,
> it is a different topic.

This should be easy to fix in os.c since all the inclusions are
isolated to there. I'd been keen to see a patch for that. Also if you
want LCD support, sdl.c.

>> Finally, please point me to how I can install FreeBSD in viritualbox
>> or similar. I'm interested in that...
>
>
> Just download an install image and start it in virtualbox, see 1.
> You might need to change the motherboard type.
>
> doc/README.clang explains how to use the host compiler to cross build
> u-boot (for some boards). You can install a gcc cross compiler as well.
>
> [1] https://www.freebsd.org/releases/10.1R/announce.html
>

I tried this out and I have a prompt but I'm not sure how to install
git or anything else 'pkg install git' tells me there are no packages
available to install matching 'git'. pkg_add seems to be missing. I am
none the wiser after some web searching.

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Andreas Bießmann]

Hi Simon,

On 07.02.15 16:10, Simon Glass wrote:
> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>> On 06-02-15 22:00, Simon Glass wrote:
>>> On 6 February 2015 at 13:40, Andreas Bie?mann
>>> <andreas.devel@googlemail.com> wrote:
>>>> On 06.02.15 20:56, Jeroen Hofstee wrote:

>>>> Dynamic list-sections is in general a good thing. But beside the linker
>>>> problem here we will get another problem on darwin hosts when we want to
>>>> read the sections. I added a patch to linux kernel to get around [1].
>>>>
>>>> So I have another option here:
>>>>
>>>> 4) setup the lists sections in code, add the magic handling for Mach-O
>>>> binaries and remove the linker foo.
>>>
>>> The lower-common-denominator approach is a bit frustrating. How does
>>> FreeBSD compile U-Boot?
>>
>>
>> I guess I am missing the point here. U-boot v2015.01 builds fine
>> on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
>> which no longer builds mkimage on FreeBSD and Darwin.

Exactly that is the point. Before it worked to build the host tools on
some exotic hosts. The introduced linker generated lists breaks this.

>>> What are you actually using that system for if
>>> it cannot build U-Boot?
>>
>> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>> for tools. (and yes sandbox likely fails to build, but I don't care that
>> much)
> 
> How do you build U-Boot for any of the boards supported? What I mean
> is that if you can't handle linker scripts in FreeBSD how do you build
> anything beyond the 'tools' build?

to build U-Boot for any board we use a cross toolchain, to build the
host tools we use the host compiler. In most cases the cross toolchain
is gnu/linux which comes with a linker as we know in linux.
But some host systems toolchain differ. *BSD with ELF as binary format
is not really a problem here, cause the binary format is comparable. It
requires just some tweaks for the used host-tools (e.g. host linker) and
it will work. Unfortunately Darwin uses Mach-O as binary format which
has some more restrictions. Especially it does not work with sections
the same way as ELF does. Therefore I posted the patch for
scripts/mod/file2alias.c in linux kernel to handle these. In days gone
by we used to support windows as host too, at least with mingw which
tries to clone a unix environment on windows. But the binary format on
Windows is still PE (AFAIK) ... I wonder if the MS linker can generate
those lists.

Please do not use the linker to generate those lists. Maybe we should
use the kernel approach and build the lists inside the code.

Best regards

Andreas Bie?mann

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Andreas,

On 7 February 2015 at 09:23, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Hi Simon,
>
> On 07.02.15 16:10, Simon Glass wrote:
>> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>> On 06-02-15 22:00, Simon Glass wrote:
>>>> On 6 February 2015 at 13:40, Andreas Bie?mann
>>>> <andreas.devel@googlemail.com> wrote:
>>>>> On 06.02.15 20:56, Jeroen Hofstee wrote:
>
>>>>> Dynamic list-sections is in general a good thing. But beside the linker
>>>>> problem here we will get another problem on darwin hosts when we want to
>>>>> read the sections. I added a patch to linux kernel to get around [1].
>>>>>
>>>>> So I have another option here:
>>>>>
>>>>> 4) setup the lists sections in code, add the magic handling for Mach-O
>>>>> binaries and remove the linker foo.
>>>>
>>>> The lower-common-denominator approach is a bit frustrating. How does
>>>> FreeBSD compile U-Boot?
>>>
>>>
>>> I guess I am missing the point here. U-boot v2015.01 builds fine
>>> on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
>>> which no longer builds mkimage on FreeBSD and Darwin.
>
> Exactly that is the point. Before it worked to build the host tools on
> some exotic hosts. The introduced linker generated lists breaks this.
>
>>>> What are you actually using that system for if
>>>> it cannot build U-Boot?
>>>
>>> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
>>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>>> for tools. (and yes sandbox likely fails to build, but I don't care that
>>> much)
>>
>> How do you build U-Boot for any of the boards supported? What I mean
>> is that if you can't handle linker scripts in FreeBSD how do you build
>> anything beyond the 'tools' build?
>
> to build U-Boot for any board we use a cross toolchain, to build the
> host tools we use the host compiler. In most cases the cross toolchain
> is gnu/linux which comes with a linker as we know in linux.
> But some host systems toolchain differ. *BSD with ELF as binary format
> is not really a problem here, cause the binary format is comparable. It
> requires just some tweaks for the used host-tools (e.g. host linker) and
> it will work. Unfortunately Darwin uses Mach-O as binary format which
> has some more restrictions. Especially it does not work with sections
> the same way as ELF does. Therefore I posted the patch for
> scripts/mod/file2alias.c in linux kernel to handle these. In days gone
> by we used to support windows as host too, at least with mingw which
> tries to clone a unix environment on windows. But the binary format on
> Windows is still PE (AFAIK) ... I wonder if the MS linker can generate
> those lists.

OK I see, so the GNU cross compilers are used on BSD, but the GNU x86
compiler is not used for host compiling.

>
> Please do not use the linker to generate those lists. Maybe we should
> use the kernel approach and build the lists inside the code.

Can you point me to that please? I'm not familiar with it. The kernel
uses all sorts of crazy link scripts - I wonder how FreeBSD deals with
that? I suppose you can't compile Linux on FreeBSD natively?

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Andreas Bießmann]

Hi Simon,

On 07.02.15 17:29, Simon Glass wrote:
> On 7 February 2015 at 09:23, Andreas Bie?mann
> <andreas.devel@googlemail.com> wrote:
>> On 07.02.15 16:10, Simon Glass wrote:
>>> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>>> On 06-02-15 22:00, Simon Glass wrote:
>>>>> On 6 February 2015 at 13:40, Andreas Bie?mann
>>>>> <andreas.devel@googlemail.com> wrote:
>>>>>> On 06.02.15 20:56, Jeroen Hofstee wrote:
>>
>>>>>> Dynamic list-sections is in general a good thing. But beside the linker
>>>>>> problem here we will get another problem on darwin hosts when we want to
>>>>>> read the sections. I added a patch to linux kernel to get around [1].
>>>>>>
>>>>>> So I have another option here:
>>>>>>
>>>>>> 4) setup the lists sections in code, add the magic handling for Mach-O
>>>>>> binaries and remove the linker foo.
>>>>>
>>>>> The lower-common-denominator approach is a bit frustrating. How does
>>>>> FreeBSD compile U-Boot?
>>>>
>>>>
>>>> I guess I am missing the point here. U-boot v2015.01 builds fine
>>>> on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
>>>> which no longer builds mkimage on FreeBSD and Darwin.
>>
>> Exactly that is the point. Before it worked to build the host tools on
>> some exotic hosts. The introduced linker generated lists breaks this.
>>
>>>>> What are you actually using that system for if
>>>>> it cannot build U-Boot?
>>>>
>>>> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
>>>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>>>> for tools. (and yes sandbox likely fails to build, but I don't care that
>>>> much)
>>>
>>> How do you build U-Boot for any of the boards supported? What I mean
>>> is that if you can't handle linker scripts in FreeBSD how do you build
>>> anything beyond the 'tools' build?
>>
>> to build U-Boot for any board we use a cross toolchain, to build the
>> host tools we use the host compiler. In most cases the cross toolchain
>> is gnu/linux which comes with a linker as we know in linux.
>> But some host systems toolchain differ. *BSD with ELF as binary format
>> is not really a problem here, cause the binary format is comparable. It
>> requires just some tweaks for the used host-tools (e.g. host linker) and
>> it will work. Unfortunately Darwin uses Mach-O as binary format which
>> has some more restrictions. Especially it does not work with sections
>> the same way as ELF does. Therefore I posted the patch for
>> scripts/mod/file2alias.c in linux kernel to handle these. In days gone
>> by we used to support windows as host too, at least with mingw which
>> tries to clone a unix environment on windows. But the binary format on
>> Windows is still PE (AFAIK) ... I wonder if the MS linker can generate
>> those lists.
> 
> OK I see, so the GNU cross compilers are used on BSD, but the GNU x86
> compiler is not used for host compiling.
> 
>>
>> Please do not use the linker to generate those lists. Maybe we should
>> use the kernel approach and build the lists inside the code.
> 
> Can you point me to that please?

I added correct section handling for Mach-O binary format to the
file2alias.c [1] when they introduced dynamic sections
(ADD_TO_DEVTABLE() macro in that file) which broke compilation on darwin.

> I'm not familiar with it. 

Me too, I just fixed the build when it was broken.

> The kernel
> uses all sorts of crazy link scripts - I wonder how FreeBSD deals with
> that? 

AFAIK there is no link script for any host tool. They use it heavily for
the kernel. But again, this is compiled and linked with the gnu linux
cross tool chain.

> I suppose you can't compile Linux on FreeBSD natively?

This will not work.

Best regards

Andreas Bie?mann

[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/file2alias.c?id=bb66fc67192bbd406fe9c22033f1bbbf3e7ec621

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Andreas,

On 7 February 2015 at 10:08, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Hi Simon,
>
> On 07.02.15 17:29, Simon Glass wrote:
>> On 7 February 2015 at 09:23, Andreas Bie?mann
>> <andreas.devel@googlemail.com> wrote:
>>> On 07.02.15 16:10, Simon Glass wrote:
>>>> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>>>> On 06-02-15 22:00, Simon Glass wrote:
>>>>>> On 6 February 2015 at 13:40, Andreas Bie?mann
>>>>>> <andreas.devel@googlemail.com> wrote:
>>>>>>> On 06.02.15 20:56, Jeroen Hofstee wrote:
>>>
>>>>>>> Dynamic list-sections is in general a good thing. But beside the linker
>>>>>>> problem here we will get another problem on darwin hosts when we want to
>>>>>>> read the sections. I added a patch to linux kernel to get around [1].
>>>>>>>
>>>>>>> So I have another option here:
>>>>>>>
>>>>>>> 4) setup the lists sections in code, add the magic handling for Mach-O
>>>>>>> binaries and remove the linker foo.
>>>>>>
>>>>>> The lower-common-denominator approach is a bit frustrating. How does
>>>>>> FreeBSD compile U-Boot?
>>>>>
>>>>>
>>>>> I guess I am missing the point here. U-boot v2015.01 builds fine
>>>>> on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
>>>>> which no longer builds mkimage on FreeBSD and Darwin.
>>>
>>> Exactly that is the point. Before it worked to build the host tools on
>>> some exotic hosts. The introduced linker generated lists breaks this.
>>>
>>>>>> What are you actually using that system for if
>>>>>> it cannot build U-Boot?
>>>>>
>>>>> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
>>>>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>>>>> for tools. (and yes sandbox likely fails to build, but I don't care that
>>>>> much)
>>>>
>>>> How do you build U-Boot for any of the boards supported? What I mean
>>>> is that if you can't handle linker scripts in FreeBSD how do you build
>>>> anything beyond the 'tools' build?
>>>
>>> to build U-Boot for any board we use a cross toolchain, to build the
>>> host tools we use the host compiler. In most cases the cross toolchain
>>> is gnu/linux which comes with a linker as we know in linux.
>>> But some host systems toolchain differ. *BSD with ELF as binary format
>>> is not really a problem here, cause the binary format is comparable. It
>>> requires just some tweaks for the used host-tools (e.g. host linker) and
>>> it will work. Unfortunately Darwin uses Mach-O as binary format which
>>> has some more restrictions. Especially it does not work with sections
>>> the same way as ELF does. Therefore I posted the patch for
>>> scripts/mod/file2alias.c in linux kernel to handle these. In days gone
>>> by we used to support windows as host too, at least with mingw which
>>> tries to clone a unix environment on windows. But the binary format on
>>> Windows is still PE (AFAIK) ... I wonder if the MS linker can generate
>>> those lists.
>>
>> OK I see, so the GNU cross compilers are used on BSD, but the GNU x86
>> compiler is not used for host compiling.
>>
>>>
>>> Please do not use the linker to generate those lists. Maybe we should
>>> use the kernel approach and build the lists inside the code.
>>
>> Can you point me to that please?
>
> I added correct section handling for Mach-O binary format to the
> file2alias.c [1] when they introduced dynamic sections
> (ADD_TO_DEVTABLE() macro in that file) which broke compilation on darwin.
>
>> I'm not familiar with it.
>
> Me too, I just fixed the build when it was broken.

So are you saying that we need to write a tool which converts the ELF
sections in the u-boot ELF into C code which then gets compiled and
put into a final u-boot ELF? And if we did that then sandbox would
work?

BTW I never did have any success getting a dev environment up on a
Mac. It took hours to download and install things and then I can't
remember what went wrong but it was awful. This was about 2 years ago
- maybe things have got easier? I'm happy to fiddle with this sort of
thing but my pain tolerance isn't what it was/

>
>> The kernel
>> uses all sorts of crazy link scripts - I wonder how FreeBSD deals with
>> that?
>
> AFAIK there is no link script for any host tool. They use it heavily for
> the kernel. But again, this is compiled and linked with the gnu linux
> cross tool chain.

Ah OK. And compiling U-Boot sandbox with a gnu linux cross tool chain
(with x86 target) on BSD is not an option? I suppose it would not run.

>
>> I suppose you can't compile Linux on FreeBSD natively?
>
> This will not work.
>
> Best regards
>
> Andreas Bie?mann
>
> [1]
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/mod/file2alias.c?id=bb66fc67192bbd406fe9c22033f1bbbf3e7ec621

Regards,
Simon

[U-Boot] [RFC PATCH] tools/imagetool: remove linker generated list

[Andreas Bießmann]

Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated
lists for imagetool which is part of mkimage. It is a nice feature to remove
the annoying register function calls, but is not portable. Unfortunately some
host compilers do not support this type of linker scripts. Therefore this
commit broke this host-tool for theem, namely FreeBSD and Darwin (OS/X).

This commit tries to fix this. We won't go back to the register functions but
we also can not use the linker script. So use another approach copied from
linux kernel scripts/mod/file2alias.c.

Signed-off-by: Andreas Bie?mann <andreas.devel@googlemail.com>
Cc: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
---

 tools/Makefile      |    2 --
 tools/imagetool.c   |   34 +++++++++++++++----------------
 tools/imagetool.h   |   56 +++++++++++++++++++++++++++++++++++++++++----------
 tools/imagetool.lds |   24 ----------------------
 4 files changed, 61 insertions(+), 55 deletions(-)
 delete mode 100644 tools/imagetool.lds

diff --git a/tools/Makefile b/tools/Makefile
index 6e1ce79..ea76a3e 100644
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -124,8 +124,6 @@ HOSTLOADLIBES_dumpimage := $(HOSTLOADLIBES_mkimage)
 HOSTLOADLIBES_fit_info := $(HOSTLOADLIBES_mkimage)
 HOSTLOADLIBES_fit_check_sign := $(HOSTLOADLIBES_mkimage)
 
-HOSTLDFLAGS += -T $(srctree)/tools/imagetool.lds
-
 hostprogs-$(CONFIG_EXYNOS5250) += mkexynosspl
 hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
 HOSTCFLAGS_mkexynosspl.o := -pedantic
diff --git a/tools/imagetool.c b/tools/imagetool.c
index 148e466..8563032 100644
--- a/tools/imagetool.c
+++ b/tools/imagetool.c
@@ -12,16 +12,15 @@
 
 struct image_type_params *imagetool_get_type(int type)
 {
-	struct image_type_params *curr;
-	struct image_type_params *start = ll_entry_start(
-			struct image_type_params, image_type);
-	struct image_type_params *end = ll_entry_end(
-			struct image_type_params, image_type);
+	struct image_type_params **curr;
+	INIT_SECTION(image_type);
+	struct image_type_params **start = __start_image_type;
+	struct image_type_params **end = __stop_image_type;
 
 	for (curr = start; curr != end; curr++) {
-		if (curr->check_image_type) {
-			if (!curr->check_image_type(type))
-				return curr;
+		if ((*curr)->check_image_type) {
+			if (!(*curr)->check_image_type(type))
+				return *curr;
 		}
 	}
 	return NULL;
@@ -34,16 +33,15 @@ int imagetool_verify_print_header(
 	struct image_tool_params *params)
 {
 	int retval = -1;
-	struct image_type_params *curr;
+	struct image_type_params **curr;
+	INIT_SECTION(image_type);
 
-	struct image_type_params *start = ll_entry_start(
-			struct image_type_params, image_type);
-	struct image_type_params *end = ll_entry_end(
-			struct image_type_params, image_type);
+	struct image_type_params **start = __start_image_type;
+	struct image_type_params **end = __stop_image_type;
 
 	for (curr = start; curr != end; curr++) {
-		if (curr->verify_header) {
-			retval = curr->verify_header((unsigned char *)ptr,
+		if ((*curr)->verify_header) {
+			retval = (*curr)->verify_header((unsigned char *)ptr,
 						     sbuf->st_size, params);
 
 			if (retval == 0) {
@@ -51,12 +49,12 @@ int imagetool_verify_print_header(
 				 * Print the image information  if verify is
 				 * successful
 				 */
-				if (curr->print_header) {
-					curr->print_header(ptr);
+				if ((*curr)->print_header) {
+					(*curr)->print_header(ptr);
 				} else {
 					fprintf(stderr,
 						"%s: print_header undefined for %s\n",
-						params->cmdname, curr->name);
+						params->cmdname, (*curr)->name);
 				}
 				break;
 			}
diff --git a/tools/imagetool.h b/tools/imagetool.h
index f35dec7..3e15b4e 100644
--- a/tools/imagetool.h
+++ b/tools/imagetool.h
@@ -20,15 +20,6 @@
 #include <unistd.h>
 #include <u-boot/sha1.h>
 
-/* define __KERNEL__ in order to get the definitions
- * required by the linker list. This is probably not
- * the best way to do this */
-#ifndef __KERNEL__
-#define __KERNEL__
-#include <linker_lists.h>
-#undef __KERNEL__
-#endif /* __KERNEL__ */
-
 #include "fdt_host.h"
 
 #define ARRAY_SIZE(x)		(sizeof(x) / sizeof((x)[0]))
@@ -194,6 +185,46 @@ int imagetool_save_subimage(
 
 void pbl_load_uboot(int fd, struct image_tool_params *mparams);
 
+#define ___cat(a, b) a ## b
+#define __cat(a, b) ___cat(a, b)
+
+/* we need some special handling for this host tool running eventually on
+ * Darwin. The Mach-O section handling is a bit different than ELF section
+ * handling. The differnces in detail are:
+ *  a) we have segments which have sections
+ *  b) we need a API call to get the respective section symbols */
+#if defined(__MACH__)
+#include <mach-o/getsect.h>
+
+#define INIT_SECTION(name)  do {					\
+		unsigned long name ## _len;				\
+		char *__cat(pstart_, name) = getsectdata("__TEXT",	\
+			#name, &__cat(name, _len));			\
+		char *__cat(pstop_, name) = __cat(pstart_, name) +	\
+			__cat(name, _len);				\
+		__cat(__start_, name) = (void *)__cat(pstart_, name);	\
+		__cat(__stop_, name) = (void *)__cat(pstop_, name);	\
+	} while (0)
+#define SECTION(name)   __attribute__((section("__TEXT, " #name)))
+
+struct image_type_params **__start_image_type, **__stop_image_type;
+#else
+#define INIT_SECTION(name) /* no-op for ELF */
+#define SECTION(name)   __attribute__((section(#name)))
+
+/* We construct a table of pointers in an ELF section (pointers generally
+ * go unpadded by gcc).  ld creates boundary syms for us. */
+extern struct image_type_params *__start_image_type[], *__stop_image_type[];
+#endif /* __MACH__ */
+
+#if !defined(__used)
+# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
+#  define __used			__attribute__((__unused__))
+# else
+#  define __used			__attribute__((__used__))
+# endif
+#endif
+
 #define U_BOOT_IMAGE_TYPE( \
 		_id, \
 		_name, \
@@ -208,7 +239,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
 		_fflag_handle, \
 		_vrec_header \
 	) \
-	ll_entry_declare(struct image_type_params, _id, image_type) = { \
+	static struct image_type_params __cat(image_type_, _id) = \
+	{ \
 		.name = _name, \
 		.header_size = _header_size, \
 		.hdr = _header, \
@@ -220,6 +252,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
 		.check_image_type = _check_image_type, \
 		.fflag_handle = _fflag_handle, \
 		.vrec_header = _vrec_header \
-	}
+	}; \
+	static struct image_type_params *SECTION(image_type) __used \
+		__cat(image_type_ptr_, _id) = &__cat(image_type_, _id)
 
 #endif /* _IMAGETOOL_H_ */
diff --git a/tools/imagetool.lds b/tools/imagetool.lds
deleted file mode 100644
index 7e92b4a..0000000
--- a/tools/imagetool.lds
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * Copyright (c) 2011-2012 The Chromium OS Authors.
- * Use of this source code is governed by a BSD-style license that can be
- * found in the LICENSE file.
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-SECTIONS
-{
-
-	. = ALIGN(4);
-	.u_boot_list : {
-		KEEP(*(SORT(.u_boot_list*)));
-	}
-
-	__u_boot_sandbox_option_start = .;
-	_u_boot_sandbox_getopt : { *(.u_boot_sandbox_getopt) }
-	__u_boot_sandbox_option_end = .;
-
-	__bss_start = .;
-}
-
-INSERT BEFORE .data;
-- 
1.7.10.4

[U-Boot] [RFC PATCH] tools/imagetool: remove linker generated list

[Jeroen Hofstee]

Thanks,

On 02/07/15 22:19, Andreas Bie?mann wrote:
> Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated
> lists for imagetool which is part of mkimage. It is a nice feature to remove
> the annoying register function calls, but is not portable. Unfortunately some
> host compilers do not support this type of linker scripts. Therefore this
> commit broke this host-tool for theem, namely FreeBSD and Darwin (OS/X).
>
> This commit tries to fix this. We won't go back to the register functions but
> we also can not use the linker script. So use another approach copied from
> linux kernel scripts/mod/file2alias.c.
>
> Signed-off-by: Andreas Bie?mann <andreas.devel@googlemail.com>
> Cc: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
>

I haven't looked into the details yet, but at least things build
again on FreeBSD with this patch. And tools/mkimage at least
displays a help :)

Thanks again, regards
Jeroen

[U-Boot] [RFC PATCH] tools/imagetool: remove linker generated list

[Guilherme Maciel Ferreira]

Hi,

The code looks fine, and it works on my Linux host.

Best regards,

2015-02-07 19:19 GMT-02:00 Andreas Bie?mann <andreas.devel@googlemail.com>:
> Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated
> lists for imagetool which is part of mkimage. It is a nice feature to remove
> the annoying register function calls, but is not portable. Unfortunately some
> host compilers do not support this type of linker scripts. Therefore this
> commit broke this host-tool for theem, namely FreeBSD and Darwin (OS/X).
>
> This commit tries to fix this. We won't go back to the register functions but
> we also can not use the linker script. So use another approach copied from
> linux kernel scripts/mod/file2alias.c.
>
> Signed-off-by: Andreas Bie?mann <andreas.devel@googlemail.com>
> Cc: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
> ---
>
>  tools/Makefile      |    2 --
>  tools/imagetool.c   |   34 +++++++++++++++----------------
>  tools/imagetool.h   |   56 +++++++++++++++++++++++++++++++++++++++++----------
>  tools/imagetool.lds |   24 ----------------------
>  4 files changed, 61 insertions(+), 55 deletions(-)
>  delete mode 100644 tools/imagetool.lds
>
> diff --git a/tools/Makefile b/tools/Makefile
> index 6e1ce79..ea76a3e 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -124,8 +124,6 @@ HOSTLOADLIBES_dumpimage := $(HOSTLOADLIBES_mkimage)
>  HOSTLOADLIBES_fit_info := $(HOSTLOADLIBES_mkimage)
>  HOSTLOADLIBES_fit_check_sign := $(HOSTLOADLIBES_mkimage)
>
> -HOSTLDFLAGS += -T $(srctree)/tools/imagetool.lds
> -
>  hostprogs-$(CONFIG_EXYNOS5250) += mkexynosspl
>  hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
>  HOSTCFLAGS_mkexynosspl.o := -pedantic
> diff --git a/tools/imagetool.c b/tools/imagetool.c
> index 148e466..8563032 100644
> --- a/tools/imagetool.c
> +++ b/tools/imagetool.c
> @@ -12,16 +12,15 @@
>
>  struct image_type_params *imagetool_get_type(int type)
>  {
> -       struct image_type_params *curr;
> -       struct image_type_params *start = ll_entry_start(
> -                       struct image_type_params, image_type);
> -       struct image_type_params *end = ll_entry_end(
> -                       struct image_type_params, image_type);
> +       struct image_type_params **curr;
> +       INIT_SECTION(image_type);
> +       struct image_type_params **start = __start_image_type;
> +       struct image_type_params **end = __stop_image_type;
>
>         for (curr = start; curr != end; curr++) {
> -               if (curr->check_image_type) {
> -                       if (!curr->check_image_type(type))
> -                               return curr;
> +               if ((*curr)->check_image_type) {
> +                       if (!(*curr)->check_image_type(type))
> +                               return *curr;
>                 }
>         }
>         return NULL;
> @@ -34,16 +33,15 @@ int imagetool_verify_print_header(
>         struct image_tool_params *params)
>  {
>         int retval = -1;
> -       struct image_type_params *curr;
> +       struct image_type_params **curr;
> +       INIT_SECTION(image_type);
>
> -       struct image_type_params *start = ll_entry_start(
> -                       struct image_type_params, image_type);
> -       struct image_type_params *end = ll_entry_end(
> -                       struct image_type_params, image_type);
> +       struct image_type_params **start = __start_image_type;
> +       struct image_type_params **end = __stop_image_type;
>
>         for (curr = start; curr != end; curr++) {
> -               if (curr->verify_header) {
> -                       retval = curr->verify_header((unsigned char *)ptr,
> +               if ((*curr)->verify_header) {
> +                       retval = (*curr)->verify_header((unsigned char *)ptr,
>                                                      sbuf->st_size, params);
>
>                         if (retval == 0) {
> @@ -51,12 +49,12 @@ int imagetool_verify_print_header(
>                                  * Print the image information  if verify is
>                                  * successful
>                                  */
> -                               if (curr->print_header) {
> -                                       curr->print_header(ptr);
> +                               if ((*curr)->print_header) {
> +                                       (*curr)->print_header(ptr);
>                                 } else {
>                                         fprintf(stderr,
>                                                 "%s: print_header undefined for %s\n",
> -                                               params->cmdname, curr->name);
> +                                               params->cmdname, (*curr)->name);
>                                 }
>                                 break;
>                         }
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index f35dec7..3e15b4e 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -20,15 +20,6 @@
>  #include <unistd.h>
>  #include <u-boot/sha1.h>
>
> -/* define __KERNEL__ in order to get the definitions
> - * required by the linker list. This is probably not
> - * the best way to do this */
> -#ifndef __KERNEL__
> -#define __KERNEL__
> -#include <linker_lists.h>
> -#undef __KERNEL__
> -#endif /* __KERNEL__ */
> -
>  #include "fdt_host.h"
>
>  #define ARRAY_SIZE(x)          (sizeof(x) / sizeof((x)[0]))
> @@ -194,6 +185,46 @@ int imagetool_save_subimage(
>
>  void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>
> +#define ___cat(a, b) a ## b
> +#define __cat(a, b) ___cat(a, b)
> +
> +/* we need some special handling for this host tool running eventually on
> + * Darwin. The Mach-O section handling is a bit different than ELF section
> + * handling. The differnces in detail are:
> + *  a) we have segments which have sections
> + *  b) we need a API call to get the respective section symbols */
> +#if defined(__MACH__)
> +#include <mach-o/getsect.h>
> +
> +#define INIT_SECTION(name)  do {                                       \
> +               unsigned long name ## _len;                             \
> +               char *__cat(pstart_, name) = getsectdata("__TEXT",      \
> +                       #name, &__cat(name, _len));                     \
> +               char *__cat(pstop_, name) = __cat(pstart_, name) +      \
> +                       __cat(name, _len);                              \
> +               __cat(__start_, name) = (void *)__cat(pstart_, name);   \
> +               __cat(__stop_, name) = (void *)__cat(pstop_, name);     \
> +       } while (0)
> +#define SECTION(name)   __attribute__((section("__TEXT, " #name)))
> +
> +struct image_type_params **__start_image_type, **__stop_image_type;
> +#else
> +#define INIT_SECTION(name) /* no-op for ELF */
> +#define SECTION(name)   __attribute__((section(#name)))
> +
> +/* We construct a table of pointers in an ELF section (pointers generally
> + * go unpadded by gcc).  ld creates boundary syms for us. */
> +extern struct image_type_params *__start_image_type[], *__stop_image_type[];
> +#endif /* __MACH__ */
> +
> +#if !defined(__used)
> +# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> +#  define __used                       __attribute__((__unused__))
> +# else
> +#  define __used                       __attribute__((__used__))
> +# endif
> +#endif
> +
>  #define U_BOOT_IMAGE_TYPE( \
>                 _id, \
>                 _name, \
> @@ -208,7 +239,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>                 _fflag_handle, \
>                 _vrec_header \
>         ) \
> -       ll_entry_declare(struct image_type_params, _id, image_type) = { \
> +       static struct image_type_params __cat(image_type_, _id) = \
> +       { \
>                 .name = _name, \
>                 .header_size = _header_size, \
>                 .hdr = _header, \
> @@ -220,6 +252,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>                 .check_image_type = _check_image_type, \
>                 .fflag_handle = _fflag_handle, \
>                 .vrec_header = _vrec_header \
> -       }
> +       }; \
> +       static struct image_type_params *SECTION(image_type) __used \
> +               __cat(image_type_ptr_, _id) = &__cat(image_type_, _id)
>
>  #endif /* _IMAGETOOL_H_ */
> diff --git a/tools/imagetool.lds b/tools/imagetool.lds
> deleted file mode 100644
> index 7e92b4a..0000000
> --- a/tools/imagetool.lds
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/*
> - * Copyright (c) 2011-2012 The Chromium OS Authors.
> - * Use of this source code is governed by a BSD-style license that can be
> - * found in the LICENSE file.
> - *
> - * SPDX-License-Identifier:    GPL-2.0+
> - */
> -
> -SECTIONS
> -{
> -
> -       . = ALIGN(4);
> -       .u_boot_list : {
> -               KEEP(*(SORT(.u_boot_list*)));
> -       }
> -
> -       __u_boot_sandbox_option_start = .;
> -       _u_boot_sandbox_getopt : { *(.u_boot_sandbox_getopt) }
> -       __u_boot_sandbox_option_end = .;
> -
> -       __bss_start = .;
> -}
> -
> -INSERT BEFORE .data;
> --
> 1.7.10.4
>



-- 
Guilherme Maciel Ferreira
Mobile Brazil: +55 48 9917 3969
Site: http://guilhermemacielferreira.com/
Skype: guilherme.maciel.ferreira

[U-Boot] [RFC PATCH] tools/imagetool: remove linker generated list

[Simon Glass]

Hi Andreas,

On 7 February 2015 at 14:19, Andreas Bie?mann
<andreas.devel@googlemail.com> wrote:
> Commit a93648d197df48fa46dd55f925ff70468bd81c71 introduced linker generated
> lists for imagetool which is part of mkimage. It is a nice feature to remove
> the annoying register function calls, but is not portable. Unfortunately some
> host compilers do not support this type of linker scripts. Therefore this
> commit broke this host-tool for theem, namely FreeBSD and Darwin (OS/X).
>
> This commit tries to fix this. We won't go back to the register functions but
> we also can not use the linker script. So use another approach copied from
> linux kernel scripts/mod/file2alias.c.
>
> Signed-off-by: Andreas Bie?mann <andreas.devel@googlemail.com>
> Cc: Guilherme Maciel Ferreira <guilherme.maciel.ferreira@gmail.com>
> ---
>
>  tools/Makefile      |    2 --
>  tools/imagetool.c   |   34 +++++++++++++++----------------
>  tools/imagetool.h   |   56 +++++++++++++++++++++++++++++++++++++++++----------
>  tools/imagetool.lds |   24 ----------------------
>  4 files changed, 61 insertions(+), 55 deletions(-)
>  delete mode 100644 tools/imagetool.lds

I have a FreeBSD set up now thanks to Jeroen so have had a play with this.

>
> diff --git a/tools/Makefile b/tools/Makefile
> index 6e1ce79..ea76a3e 100644
> --- a/tools/Makefile
> +++ b/tools/Makefile
> @@ -124,8 +124,6 @@ HOSTLOADLIBES_dumpimage := $(HOSTLOADLIBES_mkimage)
>  HOSTLOADLIBES_fit_info := $(HOSTLOADLIBES_mkimage)
>  HOSTLOADLIBES_fit_check_sign := $(HOSTLOADLIBES_mkimage)
>
> -HOSTLDFLAGS += -T $(srctree)/tools/imagetool.lds
> -
>  hostprogs-$(CONFIG_EXYNOS5250) += mkexynosspl
>  hostprogs-$(CONFIG_EXYNOS5420) += mkexynosspl
>  HOSTCFLAGS_mkexynosspl.o := -pedantic
> diff --git a/tools/imagetool.c b/tools/imagetool.c
> index 148e466..8563032 100644
> --- a/tools/imagetool.c
> +++ b/tools/imagetool.c
> @@ -12,16 +12,15 @@
>
>  struct image_type_params *imagetool_get_type(int type)
>  {
> -       struct image_type_params *curr;
> -       struct image_type_params *start = ll_entry_start(
> -                       struct image_type_params, image_type);
> -       struct image_type_params *end = ll_entry_end(
> -                       struct image_type_params, image_type);
> +       struct image_type_params **curr;
> +       INIT_SECTION(image_type);
> +       struct image_type_params **start = __start_image_type;
> +       struct image_type_params **end = __stop_image_type;
>
>         for (curr = start; curr != end; curr++) {
> -               if (curr->check_image_type) {
> -                       if (!curr->check_image_type(type))
> -                               return curr;
> +               if ((*curr)->check_image_type) {
> +                       if (!(*curr)->check_image_type(type))
> +                               return *curr;
>                 }
>         }
>         return NULL;
> @@ -34,16 +33,15 @@ int imagetool_verify_print_header(
>         struct image_tool_params *params)
>  {
>         int retval = -1;
> -       struct image_type_params *curr;
> +       struct image_type_params **curr;
> +       INIT_SECTION(image_type);
>
> -       struct image_type_params *start = ll_entry_start(
> -                       struct image_type_params, image_type);
> -       struct image_type_params *end = ll_entry_end(
> -                       struct image_type_params, image_type);
> +       struct image_type_params **start = __start_image_type;
> +       struct image_type_params **end = __stop_image_type;
>
>         for (curr = start; curr != end; curr++) {
> -               if (curr->verify_header) {
> -                       retval = curr->verify_header((unsigned char *)ptr,
> +               if ((*curr)->verify_header) {
> +                       retval = (*curr)->verify_header((unsigned char *)ptr,
>                                                      sbuf->st_size, params);
>
>                         if (retval == 0) {
> @@ -51,12 +49,12 @@ int imagetool_verify_print_header(
>                                  * Print the image information  if verify is
>                                  * successful
>                                  */
> -                               if (curr->print_header) {
> -                                       curr->print_header(ptr);
> +                               if ((*curr)->print_header) {
> +                                       (*curr)->print_header(ptr);
>                                 } else {
>                                         fprintf(stderr,
>                                                 "%s: print_header undefined for %s\n",
> -                                               params->cmdname, curr->name);
> +                                               params->cmdname, (*curr)->name);
>                                 }
>                                 break;
>                         }
> diff --git a/tools/imagetool.h b/tools/imagetool.h
> index f35dec7..3e15b4e 100644
> --- a/tools/imagetool.h
> +++ b/tools/imagetool.h
> @@ -20,15 +20,6 @@
>  #include <unistd.h>
>  #include <u-boot/sha1.h>
>
> -/* define __KERNEL__ in order to get the definitions
> - * required by the linker list. This is probably not
> - * the best way to do this */
> -#ifndef __KERNEL__
> -#define __KERNEL__
> -#include <linker_lists.h>
> -#undef __KERNEL__
> -#endif /* __KERNEL__ */
> -
>  #include "fdt_host.h"
>
>  #define ARRAY_SIZE(x)          (sizeof(x) / sizeof((x)[0]))
> @@ -194,6 +185,46 @@ int imagetool_save_subimage(
>
>  void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>
> +#define ___cat(a, b) a ## b
> +#define __cat(a, b) ___cat(a, b)
> +
> +/* we need some special handling for this host tool running eventually on
> + * Darwin. The Mach-O section handling is a bit different than ELF section
> + * handling. The differnces in detail are:
> + *  a) we have segments which have sections
> + *  b) we need a API call to get the respective section symbols */
> +#if defined(__MACH__)
> +#include <mach-o/getsect.h>
> +
> +#define INIT_SECTION(name)  do {                                       \
> +               unsigned long name ## _len;                             \
> +               char *__cat(pstart_, name) = getsectdata("__TEXT",      \
> +                       #name, &__cat(name, _len));                     \
> +               char *__cat(pstop_, name) = __cat(pstart_, name) +      \
> +                       __cat(name, _len);                              \
> +               __cat(__start_, name) = (void *)__cat(pstart_, name);   \
> +               __cat(__stop_, name) = (void *)__cat(pstop_, name);     \
> +       } while (0)
> +#define SECTION(name)   __attribute__((section("__TEXT, " #name)))

If I understand this correctly, in both cases we put things in a
separate section so that all the pieces get collected together. The
only difference seems to be the naming of the section - for MACH it
has a __TEXT prefix. Is that right? If so, I wonder if this should go
in linker_list.h?

For access to the data, here we are using a list of pointers to the
struct rather than a list of struct. Why is that? I can't see that
this is required by the MACH system.

If that is correct, then it should be easy to support linker_list on MACH, by:

- Adding a __TEXT prefix to all the section() bits in linker_lists.h
- Changing any access to the lists to use INIT_SECTION instead of
going there directly

Then we should be able to support running sandbox.

Does that sound feasible?

> +
> +struct image_type_params **__start_image_type, **__stop_image_type;
> +#else
> +#define INIT_SECTION(name) /* no-op for ELF */
> +#define SECTION(name)   __attribute__((section(#name)))
> +
> +/* We construct a table of pointers in an ELF section (pointers generally
> + * go unpadded by gcc).  ld creates boundary syms for us. */
> +extern struct image_type_params *__start_image_type[], *__stop_image_type[];
> +#endif /* __MACH__ */
> +
> +#if !defined(__used)
> +# if __GNUC__ == 3 && __GNUC_MINOR__ < 3
> +#  define __used                       __attribute__((__unused__))
> +# else
> +#  define __used                       __attribute__((__used__))
> +# endif
> +#endif
> +
>  #define U_BOOT_IMAGE_TYPE( \
>                 _id, \
>                 _name, \
> @@ -208,7 +239,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>                 _fflag_handle, \
>                 _vrec_header \
>         ) \
> -       ll_entry_declare(struct image_type_params, _id, image_type) = { \
> +       static struct image_type_params __cat(image_type_, _id) = \
> +       { \
>                 .name = _name, \
>                 .header_size = _header_size, \
>                 .hdr = _header, \
> @@ -220,6 +252,8 @@ void pbl_load_uboot(int fd, struct image_tool_params *mparams);
>                 .check_image_type = _check_image_type, \
>                 .fflag_handle = _fflag_handle, \
>                 .vrec_header = _vrec_header \
> -       }
> +       }; \
> +       static struct image_type_params *SECTION(image_type) __used \
> +               __cat(image_type_ptr_, _id) = &__cat(image_type_, _id)
>
>  #endif /* _IMAGETOOL_H_ */
> diff --git a/tools/imagetool.lds b/tools/imagetool.lds
> deleted file mode 100644
> index 7e92b4a..0000000
> --- a/tools/imagetool.lds
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/*
> - * Copyright (c) 2011-2012 The Chromium OS Authors.
> - * Use of this source code is governed by a BSD-style license that can be
> - * found in the LICENSE file.
> - *
> - * SPDX-License-Identifier:    GPL-2.0+
> - */
> -
> -SECTIONS
> -{
> -
> -       . = ALIGN(4);
> -       .u_boot_list : {
> -               KEEP(*(SORT(.u_boot_list*)));
> -       }
> -
> -       __u_boot_sandbox_option_start = .;
> -       _u_boot_sandbox_getopt : { *(.u_boot_sandbox_getopt) }
> -       __u_boot_sandbox_option_end = .;
> -
> -       __bss_start = .;
> -}
> -
> -INSERT BEFORE .data;
> --
> 1.7.10.4
>

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hello Simon,

On 07-02-15 16:10, Simon Glass wrote:
> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>
>>
>> I am missing the point, u-boot and its tools build fine until v2015.04-rc1
>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>> for tools. (and yes sandbox likely fails to build, but I don't care that
>> much)
> How do you build U-Boot for any of the boards supported? What I mean
> is that if you can't handle linker scripts in FreeBSD how do you build
> anything beyond the 'tools' build?

FreeBSD host ld can handle linker scripts fine, it is INSERT BEFORE .data;
which is not supported. Boards don't use the host linker script, but one for
the target, which comes from ports and hence is not that old e.g.

arm-gnueabi-freebsd-ld --version
GNU ld (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later 
version.
This program has absolutely no warranty.

Besides that, boards don't use INSERT before .data, since they have a 
complete
linker script.


> The docs for 'ld' seem to indicate that if the -T option is not used
> the file is treated as a link script addendum rather than replacing it
> entirely. Is that what we want?

FreeBSD ld has this option, it does not work on a MAC/Darwin though
according to Andreas his post. The problem on FreeBSD is the INSERT 
before .data
inside the "addendum" aka tools/imagetool.lds

>>> Finally, please point me to how I can install FreeBSD in viritualbox
>>> or similar. I'm interested in that...
>>
>> Just download an install image and start it in virtualbox, see 1.
>> You might need to change the motherboard type.
>>
>> doc/README.clang explains how to use the host compiler to cross build
>> u-boot (for some boards). You can install a gcc cross compiler as well.
>>
>> [1] https://www.freebsd.org/releases/10.1R/announce.html
>>
> I tried this out and I have a prompt but I'm not sure how to install
> git or anything else 'pkg install git' tells me there are no packages
> available to install matching 'git'. pkg_add seems to be missing. I am
> none the wiser after some web searching.

pkg replaced the pkg_add / pkg_info and friends. So it is fine that they
are not there. The weird thing is I just booted 10.1 in virtualbox to 
reproduce
this but works fine (just defaults everywhere), I roughly did [1]. 
Obviously you
need root credentials to install packages, but I doubt you forgot that.

If this still fails, you can always build it from source, but needs a 
bit of patience.
Somthing like this should always work:

portsnap fetch
portsnap extract

cd /usr/ports/devel/git
make config-recursive
make
make install

Let me know if you still have issues.

Regards,
Jeroen


[1] (as root)

pkg install nano git
git clone git://git.denx.de/u-boot.git
git checkout v2015.01 -b b2015.01
cd u-boot
pkg install arm-gnueabi-binutils gmake

gmake CC="clang -target arm-freebsd-eabi -no-integrated-as -mllvm 
-arm-use-movt=0" rpi_defconfig
gmake CROSS_COMPILE=arm-gnueabi-freebsd- CC="clang -target 
arm-freebsd-eabi -no-integrated-as -mllvm -arm-use-movt=0 
-B/usr/local/bin/arm-gnueabi-freebsd-" CONFIG_USE_PRIVATE_LIBGCC=y

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Jeroen,

On 7 February 2015 at 13:17, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Simon,
>
> On 07-02-15 16:10, Simon Glass wrote:
>>
>> On 7 February 2015 at 03:04, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
>>>
>>>
>>>
>>> I am missing the point, u-boot and its tools build fine until
>>> v2015.04-rc1
>>> on FreeBSD and a mac. And this is easily fixed by not using linker magic
>>> for tools. (and yes sandbox likely fails to build, but I don't care that
>>> much)
>>
>> How do you build U-Boot for any of the boards supported? What I mean
>> is that if you can't handle linker scripts in FreeBSD how do you build
>> anything beyond the 'tools' build?
>
>
> FreeBSD host ld can handle linker scripts fine, it is INSERT BEFORE .data;
> which is not supported. Boards don't use the host linker script, but one for
> the target, which comes from ports and hence is not that old e.g.
>
> arm-gnueabi-freebsd-ld --version
> GNU ld (GNU Binutils) 2.25
> Copyright (C) 2014 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later
> version.
> This program has absolutely no warranty.
>
> Besides that, boards don't use INSERT before .data, since they have a
> complete
> linker script.
>
>
>> The docs for 'ld' seem to indicate that if the -T option is not used
>> the file is treated as a link script addendum rather than replacing it
>> entirely. Is that what we want?
>
>
> FreeBSD ld has this option, it does not work on a MAC/Darwin though
> according to Andreas his post. The problem on FreeBSD is the INSERT before
> .data
> inside the "addendum" aka tools/imagetool.lds

Do you need INSERT BEFORE or would it just work to specify the .lds
fragment on the ld command line without -T?

>
>>>> Finally, please point me to how I can install FreeBSD in viritualbox
>>>> or similar. I'm interested in that...
>>>
>>>
>>> Just download an install image and start it in virtualbox, see 1.
>>> You might need to change the motherboard type.
>>>
>>> doc/README.clang explains how to use the host compiler to cross build
>>> u-boot (for some boards). You can install a gcc cross compiler as well.
>>>
>>> [1] https://www.freebsd.org/releases/10.1R/announce.html
>>>
>> I tried this out and I have a prompt but I'm not sure how to install
>> git or anything else 'pkg install git' tells me there are no packages
>> available to install matching 'git'. pkg_add seems to be missing. I am
>> none the wiser after some web searching.
>
>
> pkg replaced the pkg_add / pkg_info and friends. So it is fine that they
> are not there. The weird thing is I just booted 10.1 in virtualbox to
> reproduce
> this but works fine (just defaults everywhere), I roughly did [1]. Obviously
> you
> need root credentials to install packages, but I doubt you forgot that.

I may as well press on and figure this out.

I tried again and this time it is fine. Last time I tried to install
system documentation and source code, and it tried to install the
package manager but maybe it failed and then put things in a broken
state. Thanks for the help.

>
> If this still fails, you can always build it from source, but needs a bit of
> patience.
> Somthing like this should always work:
>
> portsnap fetch
> portsnap extract
>
> cd /usr/ports/devel/git
> make config-recursive
> make
> make install
>
> Let me know if you still have issues.
>
> Regards,
> Jeroen
>
>
> [1] (as root)
>
> pkg install nano git
> git clone git://git.denx.de/u-boot.git
> git checkout v2015.01 -b b2015.01
> cd u-boot
> pkg install arm-gnueabi-binutils gmake
>
> gmake CC="clang -target arm-freebsd-eabi -no-integrated-as -mllvm
> -arm-use-movt=0" rpi_defconfig
> gmake CROSS_COMPILE=arm-gnueabi-freebsd- CC="clang -target arm-freebsd-eabi
> -no-integrated-as -mllvm -arm-use-movt=0
> -B/usr/local/bin/arm-gnueabi-freebsd-" CONFIG_USE_PRIVATE_LIBGCC=y
>

Is this for using an ARM cross-compiler? What should I do for building
the tools? I keep seeing 'gcc not found'.

Regards,
Simon

[U-Boot] recent tools on FreeBSD

[Jeroen Hofstee]

Hello Simon,

On 07-02-15 22:02, Simon Glass wrote:
>> If this still fails, you can always build it from source, but needs a bit of
>> patience.
>> Somthing like this should always work:
>>
>> portsnap fetch
>> portsnap extract
>>
>> cd /usr/ports/devel/git
>> make config-recursive
>> make
>> make install
>>
>> Let me know if you still have issues.
>>
>> Regards,
>> Jeroen
>>
>>
>> [1] (as root)
>>
>> pkg install nano git
>> git clone git://git.denx.de/u-boot.git
>> git checkout v2015.01 -b b2015.01
>> cd u-boot
>> pkg install arm-gnueabi-binutils gmake
>>
>> gmake CC="clang -target arm-freebsd-eabi -no-integrated-as -mllvm
>> -arm-use-movt=0" rpi_defconfig
>> gmake CROSS_COMPILE=arm-gnueabi-freebsd- CC="clang -target arm-freebsd-eabi
>> -no-integrated-as -mllvm -arm-use-movt=0
>> -B/usr/local/bin/arm-gnueabi-freebsd-" CONFIG_USE_PRIVATE_LIBGCC=y
>>
> Is this for using an ARM cross-compiler? What should I do for building
> the tools? I keep seeing 'gcc not found'.

Yes it is for cross building. So the host clang / host ld do the native
build, the host clang with some help from arm-gnueabi-freebsd-as and
arm-gnueabi-freebsd-ld do the cross build.

If you only want  to build tools for the host you need something like:

gmake CC=cc sandbox_config tools

Since CC is defined to $(CROSS_COMPILE)gcc it ends up being gcc when
CROSS_COMPILE is not set, hence you get the 'gcc not found' errors.

Regards,
Jeroen

[U-Boot] recent tools on FreeBSD

[Simon Glass]

Hi Jeroen,

On 8 February 2015 at 03:03, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Simon,
>
>
> On 07-02-15 22:02, Simon Glass wrote:
>>>
>>> If this still fails, you can always build it from source, but needs a bit
>>> of
>>> patience.
>>> Somthing like this should always work:
>>>
>>> portsnap fetch
>>> portsnap extract
>>>
>>> cd /usr/ports/devel/git
>>> make config-recursive
>>> make
>>> make install
>>>
>>> Let me know if you still have issues.
>>>
>>> Regards,
>>> Jeroen
>>>
>>>
>>> [1] (as root)
>>>
>>> pkg install nano git
>>> git clone git://git.denx.de/u-boot.git
>>> git checkout v2015.01 -b b2015.01
>>> cd u-boot
>>> pkg install arm-gnueabi-binutils gmake
>>>
>>> gmake CC="clang -target arm-freebsd-eabi -no-integrated-as -mllvm
>>> -arm-use-movt=0" rpi_defconfig
>>> gmake CROSS_COMPILE=arm-gnueabi-freebsd- CC="clang -target
>>> arm-freebsd-eabi
>>> -no-integrated-as -mllvm -arm-use-movt=0
>>> -B/usr/local/bin/arm-gnueabi-freebsd-" CONFIG_USE_PRIVATE_LIBGCC=y
>>>
>> Is this for using an ARM cross-compiler? What should I do for building
>> the tools? I keep seeing 'gcc not found'.
>
>
> Yes it is for cross building. So the host clang / host ld do the native
> build, the host clang with some help from arm-gnueabi-freebsd-as and
> arm-gnueabi-freebsd-ld do the cross build.
>
> If you only want  to build tools for the host you need something like:
>
> gmake CC=cc sandbox_config tools
>
> Since CC is defined to $(CROSS_COMPILE)gcc it ends up being gcc when
> CROSS_COMPILE is not set, hence you get the 'gcc not found' errors.

Thanks for your help. I have a FreeBSD running now and can build the
tools with your patch.

Regards,
Simon

[U-Boot] sandbox on FreeBSD

[Jeroen Hofstee]

Hello Simon,

On 02/07/15 16:10, Simon Glass wrote:
>
>>
>> I am not giving up, I think it is sane if a tool which adds a header and
>> a checksum does not use linker magic.  Sandbox biggest problem is
>> not the linking, but the fact that linux headers and std* are included,
>> it is a different topic.
> This should be easy to fix in os.c since all the inclusions are
> isolated to there. I'd been keen to see a patch for that. Also if you
> want LCD support, sdl.c.

I had a look at this and hacked my way through and linked it
with a GNU ld (GNU Binutils) 2.25. So at least I have a binary, but
unfortunately it doesn't work, and errors out with:

Fatal error 'Can't allocate initial thread' at line 350 in file 
/usr/src/lib/libthr/thread/thr_init.c (errno = 2)


The reason for this seems to be void _thread_init_hack(void) 
__attribute__ ((constructor));
which calls _libpthread_init -> _thr_alloc -> calloc and that calls the 
version
in u-boots version of dl-malloc which is not initialized yet.


Did you encounter such problems on linux as well? Or does libpthread simply
not allocate memory before reaching main?


Regards,
Jeroen


ldd ../u-boot-build/u-boot
../u-boot-build/u-boot:
librt.so.1 => /usr/lib/librt.so.1 (0x800896000)
libSDL-1.2.so.0 => /usr/local/lib/libSDL-1.2.so.0 (0x800a9c000)
libthr.so.3 => /lib/libthr.so.3 (0x800d02000)
libc.so.7 => /lib/libc.so.7 (0x800f27000)
libm.so.5 => /lib/libm.so.5 (0x8012d0000)
libvgl.so.6 => /usr/lib/libvgl.so.6 (0x8014f8000)
libaa.so.1 => /usr/local/lib/libaa.so.1 (0x801701000)
libusbhid.so.4 => /usr/lib/libusbhid.so.4 (0x801919000)
libncurses.so.8 => /lib/libncurses.so.8 (0x801b1d000)

[U-Boot] sandbox on FreeBSD

[Simon Glass]

Hi Jeroen,

On 9 February 2015 at 16:20, Jeroen Hofstee <jeroen@myspectrum.nl> wrote:
> Hello Simon,
>
> On 02/07/15 16:10, Simon Glass wrote:
>>
>>
>>>
>>> I am not giving up, I think it is sane if a tool which adds a header and
>>> a checksum does not use linker magic.  Sandbox biggest problem is
>>> not the linking, but the fact that linux headers and std* are included,
>>> it is a different topic.
>>
>> This should be easy to fix in os.c since all the inclusions are
>> isolated to there. I'd been keen to see a patch for that. Also if you
>> want LCD support, sdl.c.
>
>
> I had a look at this and hacked my way through and linked it
> with a GNU ld (GNU Binutils) 2.25. So at least I have a binary, but
> unfortunately it doesn't work, and errors out with:
>
> Fatal error 'Can't allocate initial thread' at line 350 in file
> /usr/src/lib/libthr/thread/thr_init.c (errno = 2)
>
>
> The reason for this seems to be void _thread_init_hack(void) __attribute__
> ((constructor));
> which calls _libpthread_init -> _thr_alloc -> calloc and that calls the
> version
> in u-boots version of dl-malloc which is not initialized yet.
>
>
> Did you encounter such problems on linux as well? Or does libpthread simply
> not allocate memory before reaching main?

No I see no such problem but I can understand why it might happen.

There is a USE_DL_PREFIX in malloc.h which might fix the naming clash.
U-Boot sandbox uses mmap() to allocate memory from the OS.

It may be worth sending a patch even if you are not quite there?

I suspect we can adjust the Makefile to use U-Boot's internal malloc()
only for U-Boot and not for the libraries it uses. I've done that sort
of thing before and remember it being a little painful.

>
>
> Regards,
> Jeroen
>
>
> ldd ../u-boot-build/u-boot
> ../u-boot-build/u-boot:
> librt.so.1 => /usr/lib/librt.so.1 (0x800896000)
> libSDL-1.2.so.0 => /usr/local/lib/libSDL-1.2.so.0 (0x800a9c000)
> libthr.so.3 => /lib/libthr.so.3 (0x800d02000)
> libc.so.7 => /lib/libc.so.7 (0x800f27000)
> libm.so.5 => /lib/libm.so.5 (0x8012d0000)
> libvgl.so.6 => /usr/lib/libvgl.so.6 (0x8014f8000)
> libaa.so.1 => /usr/local/lib/libaa.so.1 (0x801701000)
> libusbhid.so.4 => /usr/lib/libusbhid.so.4 (0x801919000)
> libncurses.so.8 => /lib/libncurses.so.8 (0x801b1d000)
>

Regards,
Simon