qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Consult] microblaze: About running upstream main branc


From: Chen Gang
Subject: Re: [Qemu-devel] [Consult] microblaze: About running upstream main branch qemu
Date: Sun, 09 Nov 2014 19:57:18 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

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 (may run a week!!).

So we can say, the related environments construction based on qemu is
finished. This thread can be ended (but the related thread for gcc is
not ended, for it also needs the testing result).

The recent operations is below, it is generated by the latest upstream
microblaze toolchain (need build toolchain firstly, also at last, will
use microblaze qemu and dropbear to test this toolchain):

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



Welcome any ideas, suggestions or completions.

Thanks.

On 11/01/2014 01:09 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:20, Chen Gang wrote:
>> On 10/27/14 22:47, Chen Gang wrote:
>>>
>>> After a little try, I succeed run microblaze under upstream qemu 2.1.2
>>> and upstream Linux kernel 3.17-rc7, with the xilinux own ramdisk:
>>> "microblaze_complete.cpio.gz". :-)
>>>
>>> Compiler is "gcc version 4.9.1 20140717 (Red Hat Cross 4.9.1-1) (GCC)"
>>> for microblaze, and "gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)"
>>> for x86_64 qemu.
>>>
>>> Next I shall try to use virtio file to share the local data to virtual
>>> guest (I guess, it should be OK).
>>>
>>
>> I finished testing the microblaze hello world program with both dynamic
>> glibc and static glibc under qemu (I put it to 'ramfs' manualy, and it
>> runs well)  :-)
>>
>> 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 (especially for net device,
>> net drivers, busy box for telnet ...).
>>
>> Thanks.
>>
>>
>>>
>>> Thanks again!
>>>
>>>
>>>
>>> On 10/27/2014 09:47 AM, Chen Gang wrote:
>>>> On 10/26/14 21:28, Chen Gang wrote:
>>>>> Hello Guenter Roeck:
>>>>>
>>>>> I still shall try qemu and kernel distribution, next, since it can do
>>>>> it successfully (whether 'sim' can be success or not).
>>>>>
>>>>
>>>> I got confirmation from microblaze members, at present, microblaze sim
>>>> can not full simulate entire system, so I shall try qemu and kernel
>>>> distribution for it (which can do full simulation for microblaze).
>>>>
>>>> I shall try my best to finish it within this month.
>>>>
>>>> Thanks.
>>>>
>>>>> But excuse me, maybe I can not finish microblaze qemu test within this
>>>>> month, hope I can finish within next month (2014-11-30).
>>>>>
>>>>> Thank your information about qemu, again.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On 10/22/2014 08:28 AM, Chen Gang wrote:
>>>>>> OK, thanks, there are multiple branches in upstream qemu. Sorry
>>>>>> for my original said, and I can only say: for upstream  develop
>>>>>> master branch, it does not support microblaze.
>>>>>>
>>>>>> Excuse me, I does not mainly focus on only using qemu, and I
>>>>>> also found another easier way for test microblaze toolchain (use sim of 
>>>>>> binutils). So next, I will mainly focus on sim.
>>>>>>
>>>>>> I also met some issues for sim, but I guess, I can analyze it,
>>>>>> maybe also have chances to make patch for it (that is the main
>>>>>> reason why I want to focus on it).
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Send from Lenovo A788t.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Guenter Roeck <address@hidden> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 21, 2014 at 06:41:14PM +0800, Chen Gang wrote:
>>>>>>> On 10/21/14 12:37, Guenter Roeck wrote:
>>>>>>>> On 10/20/2014 08:23 AM, Chen Gang wrote:
>>>>>>>>> On 10/19/2014 10:58 PM, Guenter Roeck wrote:
>>>>>>>>>>
>>>>>>>>>> This doesn't use devicetree, but the configurations are known to be 
>>>>>>>>>> working
>>>>>>>>>> with kernel releases all the way back to kernel version 3.10.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yeah, really it is !
>>>>>>>>>
>>>>>>>>> After try upstream qemu and upstream kernel, for me, neither them can
>>>>>>>>> work well. For xilinx qemu with xilinux kernel, it should be well,
>>>>>>>>> although I still met issue below, is what I have done incorrect?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Difficult to say.
>>>>>>>>
>>>>>>>> I use gcc 4.8.0 from kernel.org and qemu 2.1.2 with its default 
>>>>>>>> configuration
>>>>>>>> for the microblaze big endian target. No idea if that makes a 
>>>>>>>> difference,
>>>>>>>> but I would suggest to start with those.
>>>>>>>>
>>>>>>>> For microblazeel I use gcc 4.9.1 built with buildroot 2014.08 for both
>>>>>>>> kernel and initramfs. Initramfs for that target is built from busybox.
>>>>>>>>
>>>>>>>
>>>>>>> OK, thank you very much for your information.
>>>>>>>
>>>>>>> But sorry, I have to stop trying, because that is far from upstream qemu
>>>>>>> and upstream kernel (at present, I have no enough time resource on it).
>>>>>>>
>>>>>>> My original goal is "use upstream microblaze qemu to test upstream gcc,
>>>>>>> binutils and glibc of microblaze". And now I find another ways: "use sim
>>>>>>> which is in upstream binutils to perform the related test".
>>>>>>>
>>>>>> You lost me. qemu 2.1.2 is the upstream qemu, and I do use upstream 
>>>>>> binutils
>>>>>> (2.24 if I recall corectly) as well as upstream gcc and upstream kernel.
>>>>>> Did I indicate otherwise in anything I said ? FWIW, should be able to use
>>>>>> qemu from distributions without recompiling it.
>>>>>>
>>>>>> Thanks,
>>>>>> Guenter
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 


-- 
Chen Gang

Open share and attitude like air water and life which God blessed



reply via email to

[Prev in Thread] Current Thread [Next in Thread]