After try the latest gcc again (execuse me, during these days, I have to
do another things), all things OK, the kernel can be started by QEMU,
all related issues are fixed by other members.
I shall start the make check with qemu again (it is about 12-13 days).
I guess, this thread is almost spam thread, but I still should try my
best to finish it (then I shall try to start 'make check' for tile).
By the way, if this thread really has negative effect with other members,
please warn me, I should not notify it to mailing list again, and try my
best to finish it within myself.
Thanks.
On 11/29/2014 06:25 PM, Chen Gang wrote:
> Hello Maintainers:
>
> After analysing, it is not kernel's issue, it is gcc issue, after let
> kernel related variable bypass this gcc issue, the kernel can start up
> successfully.
>
> The issue is "after declaration, the __attribute_((__section__ ...))
> will be ignored". After simplification, the related shell commands are:
>
> [root@localhost ana]# cat test.i
> extern int a;
> int a __attribute__((__section__(".data..init_task"))) = 0;
> [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -c
> -o test.o test.i -save-temps
> [root@localhost ana]# cat test.s
> .globl a
> .bss
> .lcomm a,4,4
> .type a, @object
> [root@localhost ana]# microblaze-linux-gnu-gcc -c -o test.o test.i
> -save-temps
> [root@localhost ana]# cat test.s
> .globl a
> .section .data..init_task,"aw",@progbits
> .align 2
> .type a,@object
> .size a,4
> a:
> .space 4
> [root@localhost ana]# /upstream/release/bin/microblaze-gchen-linux-gcc -v
> Using built-in specs.
> COLLECT_GCC=/upstream/release/bin/microblaze-gchen-linux-gcc
>
> COLLECT_LTO_WRAPPER=/upstream/release/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
> Target: microblaze-gchen-linux
> Configured with: ../gcc-new/configure --target=microblaze-gchen-linux
> --disable-nls --enable-languages=c --disable-threads --disable-shared
> --with-headers=/upstream/release/kernel --disable-libssp
> --disable-libquadmath --disable-libgomp --disable-libatomic
> --with-sysroot=/upstream/release --prefix=/upstream/release : (reconfigured)
> ../gcc-new/configure --target=microblaze-gchen-linux --disable-nls
> --disable-threads --disable-shared --with-headers=/upstream/release/kernel
> --disable-libssp --disable-libquadmath --disable-libgomp --disable-libatomic
> --with-sysroot=/upstream/release --prefix=/upstream/release
> target_alias=microblaze-gchen-linux --enable-languages=c,lto --no-create
> --no-recursion
> Thread model: single
> gcc version 5.0.0 20140925 (experimental) (GCC)
>
>
> And it is fixed in the latest microblaze gcc version, but the latest gcc
> will cause another issue for compiling kernel. I shall try to analyse it
> within next month (2014-12-31), the related issue is:
>
> net/core/dev.c: In function 'register_netdevice':
> net/core/dev.c:7285:1: internal compiler error: in verify_ssa, at
> tree-ssa.c:939
> subsys_initcall(net_dev_init);
> ^
> 0xbf77ab verify_ssa(bool, bool)
> ../../gcc-microblaze/gcc/tree-ssa.c:939
> 0x956e6b execute_function_todo
> ../../gcc-microblaze/gcc/passes.c:1947
> 0x95756d do_per_function
> ../../gcc-microblaze/gcc/passes.c:1639
> 0x957683 execute_todo
> ../../gcc-microblaze/gcc/passes.c:1997
> 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.
> make[2]: *** [net/core/dev.o] Error 1
> [root@localhost ana]#
> /upstream/release-microblaze/bin/microblaze-gchen-linux-gcc -v
> Using built-in specs.
> COLLECT_GCC=/upstream/release-microblaze/bin/microblaze-gchen-linux-gcc
>
> COLLECT_LTO_WRAPPER=/upstream/release-microblaze/libexec/gcc/microblaze-gchen-linux/5.0.0/lto-wrapper
> Target: microblaze-gchen-linux
> Configured with: ../gcc-microblaze/configure
> --target=microblaze-gchen-linux --disable-nls --enable-languages=c
> --disable-threads --disable-shared
> --with-headers=/upstream/release-microblaze/kernel --disable-libssp
> --disable-libquadmath --disable-libgomp --disable-libatomic
> --with-sysroot=/upstream/release-microblaze
> --prefix=/upstream/release-microblaze
> Thread model: single
> gcc version 5.0.0 20141129 (experimental) (GCC)
>
>
> After finish analysing, I shall start "make check" under microblaze qemu
> (may need about 12-13 days for testing).
>
> Welcome any ideas, suggestions, and completions.
>
> Thanks.
>
> On 11/20/2014 11:33 PM, Chen Gang wrote:
>>
>> Oh, sorry, after ran more than 10 days, the qemu crashed :-(
>>
>> After checked the output log, and compare with the original log, we know
>> we have finished more than 90% test, and it is OK (no any new issues).
>> I guess the reason is I started too many other things on this machine.
>>
>> Next, I shall try to analyze "the cross compiled Linux kernel will run
>> in dead lock" issue. After finish analyzing, I shall restart the test.
>> I guess it needs 12-13 days (more than a week -- I originally expected).
>>
>> Thanks.
>>
>> On 11/9/14 21:15, Chen Gang wrote:
>>>
>>> At present, I use simplified sshd, ssh and scp (dropbear open source
>>> program) to communicate with microblaze qemu successfully, and let gcc
>>> 'make check' have real effect.
>>>
>>> It is just testing, at least after almost 10 hours, the log output is
>>> OK. For each ssh login, it will wast 10 - 20 seconds, so I guess, the
>>> "make check" may run a week!! The recent operations is below:
>>>
>>> - zlib (for dropbear):
>>>
>>> export CHOST=microblaze-gchen-linux
>>> export PATH=/upstream/release/bin:$PATH
>>> ./configure --prefix=/upstream/release && make && make install
>>>
>>> - dropbear (it is a simple sshd, ssh and scp):
>>>
>>> export PATH=/upstream/release/bin:$PATH
>>> ./configure --prefix=/upstream/release \
>>> --host=microblaze-gchen-linux \
>>> CC=microblaze-gchen-linux-gcc
>>>
>>> modify /ustream/release/include/stdio.h to avoid redefining sscanf to
>>> iso99_sscanf
>>>
>>> link libz.a (static lib) to 'dropbear' (sshd) and 'dbclient' (ssh).
>>> and "make scp" to generate 'scp' command.
>>>
>>> for supporting 'none' username:
>>>
>>> under ramfs, "echo 'none:x:0:0:none:/:/bin/sh' > ./etc/passwd"
>>>
>>> for supporting no passwords (it is temporary fix):
>>>
>>> modify common-session.c: "ses.authstate.pw_passwd[0] = '\0';"
>>>
>>> put 'dropbear', 'dbclient' and 'scp' to "./sbin" of ramfs and symbol
>>> links to "./usr/bin" of ramfs.
>>>
>>> for temporary fix its stable issue, need modify code to let it 'fork'
>>> as soon as startup, and only permit one child connection each time.
>>>
>>> usage:
>>>
>>> in microblaze qemu:
>>>
>>> "/sbin/dropbear -F -E -B -p 192.168.122.2:22"
>>>
>>> in host (x86_64), use system scp and ssh is OK (without password):
>>>
>>> ssh [email protected] "cd /test; ./test"
>>> scp test.c [email protected]:/test/
>>> scp [email protected]:/test/* ./
>>>
>>> - For dejagnu:
>>>
>>> need `echo "192.168.122.2 microblaze-xilinx-gdb" >> /etc/hosts`
>>> under /usr/local/share/dejagnu/*, use ssh/scp instead of rsh/rcp.
>>> (need replace all, or will cause failure during make check).
>>> for "/usr/local/share/dejagnu/baseboards/microblaze-xilinx-gdb.exp",
>>> need add additional variables:
>>>
>>> set_board_info sockethost "192.168.122.2"
>>> set_board_info username none
>>> set timeout 600
>>>
>>> Current left issues are:
>>>
>>> - Linux kernel built by current upstream microblaze toolchain will be
>>> dead lock. I shall analyze it (I guess it may be kernel self issue,
>>> which may caused by "include/compiler-gcc5.h").
>>>
>>> - One patch for qemu microblaze dtb file, just checking by related
>>> members (originally I though it was kernel issue, but after
>>> communicate with kernel members, it is more suitable to change qemu).
>>>
>>> - One or more issues for dropbear (at least include stable issues), and
>>> one or more issues for glibc. Sorry for I have to bypass them, since
>>> I have no enough time resource on it.
>>>
>>>
>>> Welcome any ideas, suggestions or completions.
>>>
>>> Thanks.
>>>
>>>
>>> On 11/01/2014 01:07 AM, Chen Gang wrote:
>>>>
>>>> At present, I use telnet (without password), login to microblaze qemu
>>>> successfully! :-)
>>>>
>>>> - I compile busy box with the glibc in orginal 'ramfs', so get telnetd:
>>>> use new busybox replace the old one, and add symbol link 'telnetd' to
>>>> busybox in "/bin".
>>>>
>>>> - configure qemu with network support (device "xlnx.xps-ethernetlite").
>>>>
>>>> yum install libvirt
>>>> yum install tunctl
>>>> tunctl -b
>>>> ip link set tap0 up
>>>> brctl addif virbr0 tap0
>>>> ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>> -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>> -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic \
>>>> -net nic,vlan=0,model=xlnx.xps-ethernetlite,macaddr=00:16:35:AF:94:00
>>>> \
>>>> -net tap,vlan=0,ifname=tap0,script=no,downscript=no
>>>>
>>>> - fix a kernel bug: add "xlnx,xps-ethernetlite-2.00.b" for compatible
>>>> with its firmware (can find it under "/sys/firmware..../compatible",
>>>> within microblaze qemu bash environments). Related diff:
>>>>
>>>> diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>> b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>> index 28dbbdc..298fad3 100644
>>>> --- a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>> +++ b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
>>>> @@ -1236,6 +1236,7 @@ static struct of_device_id xemaclite_of_match[] =
>>>> {
>>>> { .compatible = "xlnx,opb-ethernetlite-1.01.b", },
>>>> { .compatible = "xlnx,xps-ethernetlite-1.00.a", },
>>>> { .compatible = "xlnx,xps-ethernetlite-2.00.a", },
>>>> + { .compatible = "xlnx,xps-ethernetlite-2.00.b", },
>>>> { .compatible = "xlnx,xps-ethernetlite-2.01.a", },
>>>> { .compatible = "xlnx,xps-ethernetlite-3.00.a", },
>>>> { /* end of list */ },
>>>>
>>>> Next, I shall send related kernel patch for upstream kernel, and continue
>>>> for microbaze DejaGNU with microbaze qemu, and sorry again, I did not
>>>> finish it within this month.
>>>>
>>>>
>>>> Thanks.
>>>>
>>>>
>>>> On 10/30/14 22:04, Chen Gang wrote:
>>>>> On 10/29/14 23:58, Chen Gang wrote:
>>>>>> On 10/27/14 9:42, Chen Gang wrote:
>>>>>>> On 10/27/14 2:22, Michael Eager wrote:
>>>>>>>>
>>>>>>>> Microblaze-sim provides basic instruction set architecture and memory
>>>>>>>> simulation.
>>>>>>>> There is no operating system support. (It's also quite old. I'm not
>>>>>>>> sure
>>>>>>>> which version of the MB architecture it models, but it is not recent.)
>>>>>>>>
>>>>>>>> Microblaze-sim is not a full system simulator, like QEMU. To be able
>>>>>>>> to
>>>>>>>> run a program which requires glibc, you need to be able to boot a full
>>>>>>>> Linux
>>>>>>>> image on the simulator, which microblaze-sim cannot do. QEMU models an
>>>>>>>> entire processor and can boot a Linux image.
>>>>>>>>
>>>>>>
>>>>>> At present, run upstream qemu 2.1.2 and upstream Linux kernel 3.17-rc7
>>>>>> with simple ramfs successfully. Via modify ramfs, can run hello world
>>>>>> program with static glibc (built by upstream mc_gcc), successfully.
>>>>>>
>>>>>
>>>>> After copy the ramfs' "/lib" and "/usr/lib" to outside, build the hello
>>>>> world program again with the dynamic glibc, then put it to ramfs. The
>>>>> hello world program with dynamic glibc can run correctly inside qemu :-)
>>>>>
>>>>> Next, I need focus on networking (I have found qemu related device, and
>>>>> kernel related device, and I also know, it needs telnetd in busy box).
>>>>> But sorry, it seems I can not finish within this month :-(
>>>>>
>>>>> - I wasted much time resources on choosing qemu or sim, next I should
>>>>> notice about it (do not waste time, again).
>>>>>
>>>>> - and another excuse is: I have to do it in my free time (within 2.5
>>>>> hours per day, in average). My current job is not related with it
>>>>> (at present, it is about Global Platform Java applet for iPhone OS).
>>>>>
>>>>> Next month:
>>>>>
>>>>> - I should finish microblaze qemu test under DejaGNU, should finish
>>>>> within next month (2014-11-30).
>>>>>
>>>>> - I also shall start tile cross compiling for gcc/binutils, and use it
>>>>> to Linux kernel, and test it with qemu. I shall try to finish them
>>>>> within 2 months (finish before 2014-12-31).
>>>>>
>>>>> - At least, finish 1 patch for gcc, 1 patch for binutils, 1 patch for
>>>>> qemu/kvm/xen, 3 patches for kernel, within next month (2014-11-30).
>>>>>
>>>>>
>>>>> Welcome any ideas, suggestions or completions.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>> - For ramfs:
>>>>>>
>>>>>> wget
>>>>>> http://www.wiki.xilinx.com/file/view/microblaze_complete.cpio.gz/419243588/microblaze_complete.cpio.gz
>>>>>>
>>>>>> - Related qemu command:
>>>>>>
>>>>>> ./microblaze-softmmu/qemu-system-microblaze -M petalogix-s3adsp1800 \
>>>>>> -kernel ../linux-stable.microblaze/arch/microblaze/boot/linux.bin \
>>>>>> -no-reboot -append "console=ttyUL0,115200 doreboot" -nographic
>>>>>>
>>>>>> Next, I shall try to let our gdb and DejaGNU work for it:
>>>>>>
>>>>>> - How to let qemu support network and rsh (ramfs need telnetd, kernel
>>>>>> may need related driver, and qemu related hardware need be tested).
>>>>>>
>>>>>> - Let gdb work for it, then config DejaGNU (need we test the program
>>>>>> with dynamic glib, it will be fail now for not match glibc version
>>>>>> in ramfs).
>>>>>>
>>>>>> - At last, run our test.
>>>>>>
>>>>>> It seems, still many things need trying. Welcome any ideas, suggestions,
>>>>>> and completions for it (especially for ramfs network and/or glibc, and
>>>>>> DejaGNU configuration ...).
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>> OK, thank you very much, I shall rewind to qemu, and should try my best
>>>>>>> to finish within within this month.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
--
Chen Gang
Open share and attitude like air water and life which God blessed
