[U-Boot] recent tools on FreeBSD
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; */
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
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=7e92b4ac66c8...
Regards, Jeroen
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
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; */
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
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
Hello Simon, +Andreas,
On 06-02-15 04:05, Simon Glass wrote:
Hi Jeroen,
On 5 February 2015 at 12:51, Jeroen Hofsteejeroen@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
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 Hofsteejeroen@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):
- include a complete linker script so INSERT BEFORE .data is not needed
- teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
- don't use linker magic in tools (and use a linux box for sandbox, at
least for now)
- sounds like a bad idea, the target/host might be any arch e.g.
- 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@imac % git describe v2015.04-rc1-4-g7f641d5 andreas@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---
- 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=d...
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 Hofsteejeroen@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):
- include a complete linker script so INSERT BEFORE .data is not needed
- teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
- don't use linker magic in tools (and use a linux box for sandbox, at
least for now)
- sounds like a bad idea, the target/host might be any arch e.g.
- 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@imac % git describe v2015.04-rc1-4-g7f641d5 andreas@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---
- 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:
- 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
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 Hofsteejeroen@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):
- include a complete linker script so INSERT BEFORE .data is not needed
- teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
- don't use linker magic in tools (and use a linux box for sandbox, at
least for now)
- sounds like a bad idea, the target/host might be any arch e.g.
- 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@imac % git describe v2015.04-rc1-4-g7f641d5 andreas@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---
- 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:
- 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.
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 Hofsteejeroen@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):
- include a complete linker script so INSERT BEFORE .data is not needed
- teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
- don't use linker magic in tools (and use a linux box for sandbox, at
least for now)
- sounds like a bad idea, the target/host might be any arch e.g.
- 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@imac % git describe v2015.04-rc1-4-g7f641d5 andreas@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---
- 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:
- 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.
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
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:
- 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
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:
- 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
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:
- 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...
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...
Regards, Simon
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;
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
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
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
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.
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
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.
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
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
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
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)
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
participants (4)
-
Andreas Bießmann -
Guilherme Maciel Ferreira -
Jeroen Hofstee -
Simon Glass