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