On Wed, Apr 25, 2018 at 03:27:11AM +0000, rick@andestech.com wrote:
-----Original Message----- From: Tom Rini [mailto:trini@konsulko.com] Sent: Tuesday, April 24, 2018 8:14 PM To: Rick Jian-Zhi Chen(陳建志) Cc: u-boot@lists.denx.de; Greentime Ying-Han Hu(胡英漢); rickchen36@gmail.com Subject: Re: NDS32 toolchain?
On Tue, Apr 24, 2018 at 03:10:02AM +0000, rick@andestech.com wrote:
-----Original Message----- From: Tom Rini [mailto:trini@konsulko.com] Sent: Tuesday, April 24, 2018 4:17 AM To: u-boot@lists.denx.de; Rick Jian-Zhi Chen(陳建志) Subject: NDS32 toolchain?
Hey,
So I'm looking over my setups again at what we do and do not have build testing and run-time testing, and I see that for nds32 I just cannot find a
good toolchain.
If I try for example https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64 /7.3.0/x86_ 64-gcc-7.3.0-nolibc-nds32-elf.tar.xz it first fails on the -G0 flag that we have set in and then it complains about a lack of position independent code support. Is the kernel.org toolchain perhaps configured incorrectly?
Hi Tom
You may try the following paths:
github version https://github.com/andestech/build_script.git https://github.com/greentime/prebuilt-nds32-toolchain/releases
This binary gets a lot farther: CC drivers/mtd/cfi_flash.o drivers/mtd/cfi_flash.c: In function 'write_buff': drivers/mtd/cfi_flash.c:1435:1: internal compiler error: in change_address_1, at emit-rtl.c:2126 } ^ 0x81fecd6 change_address_1
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/ emit-rtl.c:2126 0x81ff26d adjust_address_1(rtx_def*, machine_mode, long long, int, int, int, long long)
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/ emit-rtl.c:2264 0x8762488 nds32_spilt_doubleword(rtx_def**, bool)
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/c onfig/nds32/nds32-md-auxiliary.c:3238 0x886be2f gen_split_7(rtx_insn*, rtx_def**)
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/c onfig/nds32/nds32-doubleword.md:209 0x81fdf74 try_split(rtx_def*, rtx_insn*, int)
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/ emit-rtl.c:3658 0x8450a37 split_insn
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r ecog.c:2865 0x8450d0e split_all_insns()
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r ecog.c:2955 0x8450d6a rest_of_handle_split_before_sched2
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r ecog.c:3995 0x8450d6a execute
/NOBACKUP/sqa2/greentime/contrib/travis/build_script/src_pkg/gcc-6.3.0/gcc/r ecog.c:4034 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. /home/trini/work/u-boot/u-boot/scripts/Makefile.build:280: recipe for target 'drivers/mtd/cfi_flash.o' failed make[2]: *** [drivers/mtd/cfi_flash.o] Error 1 /home/trini/work/u-boot/u-boot/Makefile:1355: recipe for target 'drivers/mtd' failed make[1]: *** [drivers/mtd] Error 2 make[1]: Leaving directory '/tmp/adp-ag101p' Makefile:150: recipe for target 'sub-make' failed make: *** [sub-make] Error 2
Hi Tom
Very Sorry about the build failure. I shall verify it before sending to you.
Our teammates are trying to fix this problem. I will offer you a refine one ASAP.
Thanks, I appreciate it!
Arnd Bergmann built https://lkml.org/lkml/2018/4/17/395 www.kernel.org/pub/tools/crosstool/files/bin/x86_64/6.4.0/x86_64-gcc-6 .4.0-nolibc-nds32le-linux.tar.xz
Oddly, his 6.4.0 gets farther along than his 7.3.0 ones, but still doesn't work as I get things like this: AS arch/nds32/cpu/n1213/start.o arch/nds32/cpu/n1213/start.S: Assembler messages: arch/nds32/cpu/n1213/start.S:256: Error: Incorrect syntax, sethi $ta,hi20(_start@GOTOFF). arch/nds32/cpu/n1213/start.S:256: Error: Incorrect syntax, ori $ta,$ta,lo12(_start@GOTOFF). arch/nds32/cpu/n1213/start.S:256: Warning: relax hint unrecognized instruction: line 254.
and it just keeps going from there. You may want to drop him an email about how he's configuring for nds32le. Last time I talked with him, he wasn't planning to re-spin the 7.3.x ones, but he might do gcc-8 once it's ready.
Related, is there a QEMU target for nds32 that we could leverage so that once the toolchain issue is resolved we can update .travis.yml to run
tests on it?
Thanks!
I am applying the QEMU offering permit. If it is ok. I will prepare it for you.
Because I always verify NDS32 on board (AG101P or AE3XX). I never verify it on NDS32 QEMU. It seem still have some problems, maybe need some time to debug for work.
But the RISC-V QEMU is available noe. Maybe I can give it to you for trying.
Adding riscv to the test.py + QEMU section of .travis.yml would be great!