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 none@192.168.122.2 "cd /test; ./test"
>>>        scp test.c none@192.168.122.2:/test/
>>>        scp none@192.168.122.2:/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

Reply via email to