Created attachment 5264 [details]
config file for sh4 toolchain build

Aah, glad to see we have a SuperH user!

This problem is well-known (at least to me). The issue is that gcc for SH4 insists on being multilib, to all the libraries are not directly in the sysroot but in some directory named "!m4" if I remember correctly. This confuses the Buildroot toolchain logic, which assumes the toolchain is not multilib.

Moreover, the other problem we have with SH4 is that to be able a kernel, you really need to have the m4-nofpu multilib variant, in addition to the m4 one. This is why configs/qemu_sh4_r2d_defconfig has this special configuration option:

BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-multilib-list=m4,m4-nofpu"

At this point, I must say I am not sure how this problem should be fixed exactly.

Do you have some good knowledge of the SuperH architecture variants? That would be very helpful: we lack some contributors using SuperH and having some minimal knowledge of the architecture.

Created attachment 5270 [details]
Fix the toolchain build for the SuperH architecture.

Hi,

I've attached a small patch that fixes the toolchain build for the SuperH architecture.

Could you take a look at it and if it's ok, add it into the git repo?


Cheers
George

(In reply to comment #3)
> Created attachment 5270 [details]
> Fix the toolchain build for the SuperH architecture.

Thanks for the patch!

However, I am not sure it will work correctly in all cases. It works in your case because only one multilib variant gets built, and installed in the !m4 directory. But if you have BR2_EXTRA_GCC_CONFIG_OPTIONS="--with-multilib-list=m4,m4-nofpu", then two multilib variants will be built, and you will have two directories, not one.

Could you check this case?

It's also a bit annoying that on SuperH, specifying a custom gcc option is needed to even be able to build a kernel. Do you know if there's something that can be done about it?

Hi George,

Did you already find some time to look into this further?

Thanks a lot,
ThomasDS

Hi Thomas,

with my little patch, I was able to have a toolchain capable of building the whole rootfs for my board.

I did not use the BR2_EXTRA_GCC_CONFIG_OPTIONS, and to be honest, I don't understand why I'd need those.

I don't know what else to say. It works in my case, but I don't know if there are other cases that might not work.


Cheers
George

(In reply to comment #6)
> Hi George,
> 
> Did you already find some time to look into this further?
> 
> Thanks a lot,
> ThomasDS

Did you try building an SH4 Linux kernel with the generated toolchain?

Yes, I was able to build using the default defconfig for ecovec24.
I had to modify the ./arch/sh/Makefile in that kernel by removing the -m4-nofpu for sh4.


cflags-$(CONFIG_CPU_SH4)        := $(call cc-option,-m4,) \
    $(call cc-option,-mno-implicit-fp)

(In reply to comment #9)
> Yes, I was able to build using the default defconfig for ecovec24.
> I had to modify the ./arch/sh/Makefile in that kernel by removing the -m4-nofpu
> for sh4.
> 
> 
> cflags-$(CONFIG_CPU_SH4)        := $(call cc-option,-m4,) \
>     $(call cc-option,-mno-implicit-fp)

Hum, right, but we don't want people to be forced to modify the kernel Makefiles in order to be able to build a SH4 kernel with a Buildroot toolchain. That isn't really nice, right?

Hi,

I don't think removing m4-nofpu is the right thing to create a good kernel.
As gcc does not include support for -mno-implicit-fp, there is no way around using
a multilib gcc to compile a kernel without floating point instructions.

See here for an interesting thread:
http://sourceforge.net/p/linuxsh/mailman/linuxsh-dev/thread/3B732B78.28B8BF39@pocketpenguins.com/

It seems Codesourcery has some gcc patches included to support -mno-implicit-fp.
But the gcc people have rejected it. 

best regards
 Waldemar

Fixed by http://git.buildroot.net/buildroot/commit/package/gcc?id=19d5953bf15b9e68d083fc72bcd40b02b7ab810a.