[PATCH] Add basic m68k support to crosstool-ng

[PATCH] Add basic m68k support to crosstool-ng

[Remy Bohmer]

Signed-off-by: Remy Bohmer <linux@bohmer.net>
---
 config/arch/m68k.in                       |   10 +
 samples/m68k-unknown-elf/crosstool.config |  312 +++++++++++++++++++++++++++++
 samples/m68k-unknown-elf/reported.by      |    3 +
 scripts/build/arch/m68k.sh                |    6 +
 4 files changed, 331 insertions(+), 0 deletions(-)
 create mode 100644 config/arch/m68k.in
 create mode 100644 samples/m68k-unknown-elf/crosstool.config
 create mode 100644 samples/m68k-unknown-elf/reported.by
 create mode 100644 scripts/build/arch/m68k.sh

diff --git a/config/arch/m68k.in b/config/arch/m68k.in
new file mode 100644
index 0000000..df45501
--- /dev/null
+++ b/config/arch/m68k.in
@@ -0,0 +1,10 @@
+# m68k specific configuration file
+# depends on EXPERIMENTAL
+
+config ARCH_m68k
+    select ARCH_SUPPORTS_32
+    select ARCH_DEFAULT_32
+    select ARCH_DEFAULT_BE
+    select ARCH_SUPPORT_CPU
+     help
+      The m68k architecture
diff --git a/samples/m68k-unknown-elf/crosstool.config b/samples/m68k-unknown-elf/crosstool.config
new file mode 100644
index 0000000..737bd77
--- /dev/null
+++ b/samples/m68k-unknown-elf/crosstool.config
@@ -0,0 +1,312 @@
+#
+# Automatically generated make config: don't edit
+# crosstool-NG version: hg_unknown@20100128.184811
+# Thu Jan 28 18:54:44 2010
+#
+
+#
+# Paths and misc options
+#
+
+#
+# crosstool-NG behavior
+#
+# CT_OBSOLETE is not set
+CT_EXPERIMENTAL=y
+CT_DEBUG_CT=y
+# CT_DEBUG_PAUSE_STEPS is not set
+CT_DEBUG_CT_SAVE_STEPS=y
+CT_DEBUG_CT_SAVE_STEPS_GZIP=y
+# CT_NO_OVERIDE_LC_MESSAGES is not set
+
+#
+# Paths
+#
+CT_LOCAL_TARBALLS_DIR="${HOME}/src"
+CT_SAVE_TARBALLS=y
+CT_WORK_DIR="${CT_TOP_DIR}/targets"
+CT_PREFIX_DIR="${HOME}/x-tools/${CT_TARGET}"
+CT_INSTALL_DIR="${CT_PREFIX_DIR}"
+CT_REMOVE_DOCS=y
+CT_INSTALL_DIR_RO=y
+
+#
+# Downloading
+#
+# CT_FORBID_DOWNLOAD is not set
+# CT_FORCE_DOWNLOAD is not set
+CT_USE_MIRROR=y
+# CT_PREFER_MIRROR is not set
+CT_MIRROR_BASE_URL="http://ymorin.is-a-geek.org/mirrors/"
+# CT_MIRROR_LS_R is not set
+CT_CONNECT_TIMEOUT=10
+CT_DOWNLOAD_MAX_CHUNKS=5
+# CT_ONLY_DOWNLOAD is not set
+
+#
+# Extracting
+#
+# CT_FORCE_EXTRACT is not set
+CT_OVERIDE_CONFIG_GUESS_SUB=y
+# CT_ONLY_EXTRACT is not set
+CT_PATCH_BUNDLED=y
+# CT_PATCH_LOCAL is not set
+# CT_PATCH_BUNDLED_LOCAL is not set
+# CT_PATCH_LOCAL_BUNDLED is not set
+# CT_PATCH_BUNDLED_FALLBACK_LOCAL is not set
+# CT_PATCH_LOCAL_FALLBACK_BUNDLED is not set
+# CT_PATCH_NONE is not set
+CT_PATCH_ORDER="bundled"
+# CT_PATCH_SINGLE is not set
+# CT_PATCH_USE_LOCAL is not set
+
+#
+# Build behavior
+#
+CT_PARALLEL_JOBS=1
+CT_LOAD=0
+CT_NICE=0
+CT_USE_PIPES=y
+# CT_CONFIG_SHELL_SH is not set
+# CT_CONFIG_SHELL_ASH is not set
+CT_CONFIG_SHELL_BASH=y
+# CT_CONFIG_SHELL_CUSTOM is not set
+CT_CONFIG_SHELL="bash"
+
+#
+# Logging
+#
+# CT_LOG_ERROR is not set
+# CT_LOG_WARN is not set
+# CT_LOG_INFO is not set
+CT_LOG_EXTRA=y
+# CT_LOG_DEBUG is not set
+# CT_LOG_ALL is not set
+CT_LOG_LEVEL_MAX="EXTRA"
+# CT_LOG_SEE_TOOLS_WARN is not set
+CT_LOG_PROGRESS_BAR=y
+CT_LOG_TO_FILE=y
+CT_LOG_FILE_COMPRESS=y
+
+#
+# Target options
+#
+CT_ARCH="m68k"
+# CT_ARCH_SUPPORTS_BOTH_MMU is not set
+# CT_ARCH_SUPPORTS_BOTH_ENDIAN is not set
+CT_ARCH_SUPPORTS_32=y
+# CT_ARCH_SUPPORTS_64 is not set
+# CT_ARCH_SUPPORT_ARCH is not set
+# CT_ARCH_SUPPORT_ABI is not set
+CT_ARCH_SUPPORT_CPU=y
+CT_ARCH_SUPPORT_TUNE=y
+# CT_ARCH_SUPPORT_FPU is not set
+# CT_ARCH_DEFAULT_HAS_MMU is not set
+CT_ARCH_DEFAULT_BE=y
+# CT_ARCH_DEFAULT_LE is not set
+CT_ARCH_DEFAULT_32=y
+# CT_ARCH_DEFAULT_64 is not set
+CT_ARCH_CPU="cpu32"
+CT_ARCH_TUNE=""
+CT_ARCH_32=y
+# CT_ARCH_64 is not set
+CT_ARCH_BITNESS=32
+CT_ARCH_FLOAT_HW=y
+# CT_ARCH_FLOAT_SW is not set
+CT_TARGET_CFLAGS=""
+CT_TARGET_LDFLAGS=""
+
+#
+# General target options
+#
+# CT_ARCH_alpha is not set
+# CT_ARCH_arm is not set
+# CT_ARCH_avr32 is not set
+# CT_ARCH_ia64 is not set
+CT_ARCH_m68k=y
+# CT_ARCH_mips is not set
+# CT_ARCH_powerpc is not set
+# CT_ARCH_s390 is not set
+# CT_ARCH_sh is not set
+# CT_ARCH_x86 is not set
+# CT_ARCH_USE_MMU is not set
+
+#
+# Target optimisations
+#
+
+#
+# Toolchain options
+#
+
+#
+# General toolchain options
+#
+CT_USE_SYSROOT=y
+CT_SYSROOT_DIR_PREFIX=""
+
+#
+# Tuple completion and aliasing
+#
+CT_TARGET_VENDOR="unknown"
+CT_TARGET_ALIAS_SED_EXPR=""
+CT_TARGET_ALIAS=""
+
+#
+# Toolchain type
+#
+# CT_NATIVE is not set
+CT_CROSS=y
+# CT_CROSS_NATIVE is not set
+# CT_CANADIAN is not set
+CT_TOOLCHAIN_TYPE="cross"
+
+#
+# Build system
+#
+CT_BUILD=""
+CT_BUILD_PREFIX=""
+CT_BUILD_SUFFIX=""
+
+#
+# Operating System
+#
+CT_BARE_METAL=y
+# CT_KERNEL_SUPPORTS_SHARED_LIBS is not set
+CT_KERNEL="bare-metal"
+CT_KERNEL_bare_metal=y
+# CT_KERNEL_linux is not set
+
+#
+# Common kernel options
+#
+
+#
+# Binary utilities
+#
+# CT_ARCH_BINFMT_ELF is not set
+CT_ARCH_BINFMT_FLAT=y
+
+#
+# GNU binutils
+#
+# CT_BINUTILS_V_2_20 is not set
+CT_BINUTILS_V_2_19_1=y
+# CT_BINUTILS_V_2_19 is not set
+# CT_BINUTILS_V_2_18 is not set
+# CT_BINUTILS_V_2_17 is not set
+# CT_BINUTILS_V_2_16_1 is not set
+CT_BINUTILS_VERSION="2.19.1"
+CT_BINUTILS_EXTRA_CONFIG=""
+
+#
+# elf2flt
+#
+CT_ELF2FLT_CVSHEAD=y
+# CT_ELF2FLT_CVS_SNAPSHOT is not set
+CT_ELF2FLT_VERSION="head"
+CT_ELF2FLT_EXTRA_CONFIG=""
+
+#
+# C compiler
+#
+CT_CC="gcc"
+CT_CC_VERSION="4.3.4"
+CT_CC_gcc=y
+# CT_CC_V_4_4_3 is not set
+# CT_CC_V_4_4_2 is not set
+# CT_CC_V_4_4_1 is not set
+# CT_CC_V_4_4_0 is not set
+CT_CC_V_4_3_4=y
+# CT_CC_V_4_3_3 is not set
+# CT_CC_V_4_3_2 is not set
+# CT_CC_V_4_3_1 is not set
+# CT_CC_V_4_3_0 is not set
+# CT_CC_V_4_2_4 is not set
+# CT_CC_V_4_2_3 is not set
+# CT_CC_V_4_2_2 is not set
+# CT_CC_V_4_2_1 is not set
+# CT_CC_V_4_2_0 is not set
+# CT_CC_V_4_1_2 is not set
+# CT_CC_V_4_0_4 is not set
+# CT_CC_V_3_4_6 is not set
+CT_CC_GCC_4_3_or_later=y
+# CT_CC_GCC_4_4_or_later is not set
+CT_CC_ENABLE_CXX_FLAGS=""
+CT_CC_CORE_EXTRA_CONFIG=""
+CT_CC_PKGVERSION="crosstool-NG-${CT_VERSION}"
+CT_CC_BUGURL=""
+CT_CC_SUPPORT_CXX=y
+CT_CC_SUPPORT_FORTRAN=y
+CT_CC_SUPPORT_JAVA=y
+CT_CC_SUPPORT_ADA=y
+CT_CC_SUPPORT_OBJC=y
+CT_CC_SUPPORT_OBJCXX=y
+
+#
+# Additional supported languages:
+#
+# CT_CC_LANG_CXX is not set
+
+#
+# C-library
+#
+CT_LIBC="none"
+# CT_LIBC_eglibc is not set
+# CT_LIBC_glibc is not set
+# CT_LIBC_newlib is not set
+CT_LIBC_none=y
+# CT_LIBC_uClibc is not set
+# CT_LIBC_SUPPORT_NPTL is not set
+# CT_LIBC_SUPPORT_LINUXTHREADS is not set
+CT_THREADS="none"
+
+#
+# Debug facilities
+#
+# CT_DEBUG_dmalloc is not set
+# CT_DEBUG_duma is not set
+# CT_DEBUG_gdb is not set
+# CT_DEBUG_ltrace is not set
+# CT_DEBUG_strace is not set
+
+#
+# Tools facilities
+#
+# CT_TOOL_libelf is not set
+# CT_TOOL_sstrip is not set
+
+#
+# Companion libraries
+#
+CT_WRAPPER_NEEDED=y
+CT_GMP_MPFR=y
+CT_GMP_V_4_3_1=y
+# CT_GMP_V_4_3_0 is not set
+# CT_GMP_V_4_2_4 is not set
+# CT_GMP_V_4_2_2 is not set
+CT_GMP_VERSION="4.3.1"
+# CT_MPFR_V_2_4_2 is not set
+CT_MPFR_V_2_4_1=y
+# CT_MPFR_V_2_4_0 is not set
+# CT_MPFR_V_2_3_2 is not set
+# CT_MPFR_V_2_3_1 is not set
+CT_MPFR_VERSION="2.4.1"
+# CT_PPL_CLOOG_MPC is not set
+
+#
+# Companion libraries common options
+#
+# CT_COMP_LIBS_CHECK is not set
+CT_TOOLS_WRAPPER_SCRIPT=y
+# CT_TOOLS_WRAPPER_EXEC is not set
+CT_TOOLS_WRAPPER="script"
+
+#
+# Companion tools
+#
+
+#
+# READ HELP before you say 'Y' below !!!
+#
+# CT_COMP_TOOLS is not set
diff --git a/samples/m68k-unknown-elf/reported.by b/samples/m68k-unknown-elf/reported.by
new file mode 100644
index 0000000..b7bb658
--- /dev/null
+++ b/samples/m68k-unknown-elf/reported.by
@@ -0,0 +1,3 @@
+reporter_name="Remy Bohmer"
+reporter_url="linux@bohmer.net"
+reporter_comment="Example for building a toolchain for m68000 bare metal targets"
diff --git a/scripts/build/arch/m68k.sh b/scripts/build/arch/m68k.sh
new file mode 100644
index 0000000..ba843e4
--- /dev/null
+++ b/scripts/build/arch/m68k.sh
@@ -0,0 +1,6 @@
+# Compute M68k-specific values
+
+CT_DoArchTupleValues() {
+    # The architecture part of the tuple:
+    CT_TARGET_ARCH="${CT_ARCH}"
+}
-- 
1.6.3.3


--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Yann E. MORIN]

Hello Remy, All!

Whaoo! Very nice! Thank you for the submission! :-)

I have however a few questions, see below...

On Thursday 28 January 2010 19:57:14 Remy Bohmer wrote:
> +config ARCH_m68k
> +    select ARCH_SUPPORTS_32
> +    select ARCH_DEFAULT_32
> +    select ARCH_DEFAULT_BE
> +    select ARCH_SUPPORT_CPU

From the gcc man page, it seems you can also pass -march and -mtune.
Did you exclude those on purpose, or is it a oversight?

[--SNIP--]
> +#
> +# Operating System
> +#
> +CT_BARE_METAL=y
> +# CT_KERNEL_SUPPORTS_SHARED_LIBS is not set
> +CT_KERNEL="bare-metal"
> +CT_KERNEL_bare_metal=y
> +# CT_KERNEL_linux is not set

This means a bare-metal target. OK.
Is it possible to generate:
- m68k-linux-gnu ?
- m68k-linux-uclibc ?

> +#
> +# elf2flt
> +#
> +CT_ELF2FLT_CVSHEAD=y
> +# CT_ELF2FLT_CVS_SNAPSHOT is not set
> +CT_ELF2FLT_VERSION="head"
> +CT_ELF2FLT_EXTRA_CONFIG=""

elf2flt is currently disabled in the code. We do not (yet) build it, as
we do not call its functions (for now).

Did you notice that?
Was your toolchain functional?

[--SNIP--]
> +CT_DoArchTupleValues() {
> +    # The architecture part of the tuple:
> +    CT_TARGET_ARCH="${CT_ARCH}"

This is the default, and needs not be repeated.

This is a whole new architecture, and should not disrupt existing code,
so I'll add it. I'd like to read your answers, however, at least for my
own curiosity, or better yet, so we can improve m68k support.

Thank you again! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Remy Bohmer]

Hi Yann,

2010/1/28 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Hello Remy, All!
>
> Whaoo! Very nice! Thank you for the submission! :-)
>
> I have however a few questions, see below...
>
> On Thursday 28 January 2010 19:57:14 Remy Bohmer wrote:
>> +config ARCH_m68k
>> +    select ARCH_SUPPORTS_32
>> +    select ARCH_DEFAULT_32
>> +    select ARCH_DEFAULT_BE
>> +    select ARCH_SUPPORT_CPU
>
> From the gcc man page, it seems you can also pass -march and -mtune.
> Did you exclude those on purpose, or is it a oversight?

I excluded them because they were not yet needed.

> [--SNIP--]
>> +#
>> +# Operating System
>> +#
>> +CT_BARE_METAL=y
>> +# CT_KERNEL_SUPPORTS_SHARED_LIBS is not set
>> +CT_KERNEL="bare-metal"
>> +CT_KERNEL_bare_metal=y
>> +# CT_KERNEL_linux is not set
>
> This means a bare-metal target. OK.
> Is it possible to generate:
> - m68k-linux-gnu ?
> - m68k-linux-uclibc ?

Maybe, but I did not look into that.
We only need a bare metal compiler to replace another old exotic
compiler, running linux on an ancient 20MHz processor  with just 512kB
of RAM is not that useful...

>> +#
>> +# elf2flt
>> +#
>> +CT_ELF2FLT_CVSHEAD=y
>> +# CT_ELF2FLT_CVS_SNAPSHOT is not set
>> +CT_ELF2FLT_VERSION="head"
>> +CT_ELF2FLT_EXTRA_CONFIG=""
>
> elf2flt is currently disabled in the code. We do not (yet) build it, as
> we do not call its functions (for now).

elf2flt was auto-magically selected, I did not select it on purpose.
Actually we even do not need the elf2flt code.
We will create a separate patch to get rid of this unexpected and
unwanted relation.

> Did you notice that?
> Was your toolchain functional?

We are still testing it, but everything looks good, and the compiler
seems to deliver proper executables.
However, we have not yet build a complete product with it so there
might still be some issues, but we will fix those as well.

> [--SNIP--]
>> +CT_DoArchTupleValues() {
>> +    # The architecture part of the tuple:
>> +    CT_TARGET_ARCH="${CT_ARCH}"
>
> This is the default, and needs not be repeated.

Copy-pasted from another architecture... (x86_64)

> This is a whole new architecture, and should not disrupt existing code,
> so I'll add it. I'd like to read your answers, however, at least for my
> own curiosity, or better yet, so we can improve m68k support.

Thanks.
Soon, there will be updates to this architecture to make it more
useful. (Me or Bart will post those)
We also want a canadian build for this toolchain (Windows hosted) and
we are having some issues to get it compiled properly.
We also want newlib support in it as well. (does not compile yet)

Kind regards,

Remy

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Remy Bohmer]

Hi,

2010/1/28 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> Hello Remy, All!
>
> Whaoo! Very nice! Thank you for the submission! :-)
>
> I have however a few questions, see below...
>
> On Thursday 28 January 2010 19:57:14 Remy Bohmer wrote:
>> +config ARCH_m68k
>> +    select ARCH_SUPPORTS_32
>> +    select ARCH_DEFAULT_32
>> +    select ARCH_DEFAULT_BE
>> +    select ARCH_SUPPORT_CPU
>
> From the gcc man page, it seems you can also pass -march and -mtune.
> Did you exclude those on purpose, or is it a oversight?

Looking deeper into this it seems that:
* if GCC is compiled with --with-arch=m68k (ARCH_ARCH=m68k) then the
build of newlib eventually fails because its compilation passes
-march=m68k to GCC, which is an illegal value for GCC itself.
* If GCC is compiled with 'ARCH_ARCH=cpu32', which is valid for -march
for GCC as listed on the man-pages, then the compilation of GCC fails
since it does not like this option to be passed through --with-arch.
* --with-tune is not supported either, although --with-cpu works properly.

Any ideas?

Kind regards,

Remy

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Yann E. MORIN]

Hello Remy, Bart!
All,

On Sunday 07 February 2010 12:52:45 Remy Bohmer wrote:
> 2010/1/28 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>:
> > From the gcc man page, it seems you can also pass -march and -mtune.
> > Did you exclude those on purpose, or is it a oversight?
> I excluded them because they were not yet needed.

OK.

> > Is it possible to generate:
> > - m68k-linux-gnu ?
> > - m68k-linux-uclibc ?
> Maybe, but I did not look into that.
> We only need a bare metal compiler to replace another old exotic
> compiler, running linux on an ancient 20MHz processor  with just 512kB
> of RAM is not that useful...

OK, I was just inquiring. Let's keep it as-is for now, until someone
requires Linux and his/her box and provides a proper patch! ;-)

> > elf2flt is currently disabled in the code. We do not (yet) build it, as
> > we do not call its functions (for now).
> elf2flt was auto-magically selected, I did not select it on purpose.
> Actually we even do not need the elf2flt code.
> We will create a separate patch to get rid of this unexpected and
> unwanted relation.

How do you manage this noMMU stuff if not using elf2flt, then?

> > Was your toolchain functional?
> We are still testing it, but everything looks good, and the compiler
> seems to deliver proper executables.
> However, we have not yet build a complete product with it so there
> might still be some issues, but we will fix those as well.

Any feedback?

> > [--SNIP--]
> >> +CT_DoArchTupleValues() {
> >> +    # The architecture part of the tuple:
> >> +    CT_TARGET_ARCH="${CT_ARCH}"
> >
> > This is the default, and needs not be repeated.
> Copy-pasted from another architecture... (x86_64)

Well, x86_64 is only a variant of the x86 arch, and thus needs to set this
value.

> Soon, there will be updates to this architecture to make it more
> useful. (Me or Bart will post those)
> We also want a canadian build for this toolchain (Windows hosted) and
> we are having some issues to get it compiled properly.
> We also want newlib support in it as well. (does not compile yet)

Any progress in those fields?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Yann E. MORIN]

Hello Remy, All!

On Sunday 07 February 2010 22:17:13 Remy Bohmer wrote:
> > From the gcc man page, it seems you can also pass -march and -mtune.
> > Did you exclude those on purpose, or is it a oversight?
> Looking deeper into this it seems that:
> * if GCC is compiled with --with-arch=m68k (ARCH_ARCH=m68k) then the
> build of newlib eventually fails because its compilation passes
> -march=m68k to GCC, which is an illegal value for GCC itself.
> * If GCC is compiled with 'ARCH_ARCH=cpu32', which is valid for -march
> for GCC as listed on the man-pages, then the compilation of GCC fails
> since it does not like this option to be passed through --with-arch.
> * --with-tune is not supported either, although --with-cpu works properly.

Hmmm. Lemme see...

OK, gcc is clearly at fault here (IMHO). So it's the responsibility of the
gcc build script to fix those.

Eg.:
- CT_ARCH_ARCH can take any value acceptable by -march
- the build script mangles that value to build a value suitable for
  --with-arch

That's the idea... But I'm no m68k expert, here...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'



--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Remy Bohmer]

Hi Yann,

>> > elf2flt is currently disabled in the code. We do not (yet) build it, as
>> > we do not call its functions (for now).
>> elf2flt was auto-magically selected, I did not select it on purpose.
>> Actually we even do not need the elf2flt code.
>> We will create a separate patch to get rid of this unexpected and
>> unwanted relation.
>
> How do you manage this noMMU stuff if not using elf2flt, then?

m68k-none-elf-objcopy -O binary <my-elf-image-in> <my-binary-image-out>

>> > Was your toolchain functional?
>> We are still testing it, but everything looks good, and the compiler
>> seems to deliver proper executables.
>> However, we have not yet build a complete product with it so there
>> might still be some issues, but we will fix those as well.
>
> Any feedback?

Due to some holidays I expect more feedback within 2 weeks from now.

>> Soon, there will be updates to this architecture to make it more
>> useful. (Me or Bart will post those)
>> We also want a canadian build for this toolchain (Windows hosted) and
>> we are having some issues to get it compiled properly.
>> We also want newlib support in it as well. (does not compile yet)
>
> Any progress in those fields?

Canadian build still not functional since we have conflicts with
building GCC for baremetal in canadian build, it seems that some
HOST-tools/libs are build with BUILD-system flags which makes the
build fail. It might be that those failing tools/libs do not need to
be build at all.
We will continue with it after about 2 weeks from now. Canadian for
bare metal is a wish for us at the moment, but I foresee that it can
become mandatory within a few months.
Newlib support is working after disabling --with-arch ;-)
Patches will be posted after they are stable and that will be after
the holidays... :-)

Kind regards,

Remy

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: [PATCH] Add basic m68k support to crosstool-ng

[Remy Bohmer]

Hi,

> OK, gcc is clearly at fault here (IMHO). So it's the responsibility of the
> gcc build script to fix those.

From what I read in the GCC release notes was that the arch flag
support for m68k was recently added, so it does not surprise me that
it did not work properly. I guess it was added for Coldfire support.

> Eg.:
> - CT_ARCH_ARCH can take any value acceptable by -march
> - the build script mangles that value to build a value suitable for
>  --with-arch

Do you really want to work around GCC bugs in the ct-ng scripts?
I would expect that patching GCC was the better approach... (i.e.
adding patches in the ct-ng patches directory for GCC)

> That's the idea... But I'm no m68k expert, here...

Me neither ;-)))

Remy

--
For unsubscribe information see http://sourceware.org/lists.html#faq