All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gang <gang.chen.5i5j@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Max Filippov <jcmvbkbc@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Peter Maydell <peter.maydell@linaro.org>
Subject: Re: [Qemu-devel] [Consult] microblaze: About running upstream main branch qemu
Date: Sun, 09 Nov 2014 19:57:18 +0800	[thread overview]
Message-ID: <545F569E.9070206@gmail.com> (raw)
In-Reply-To: <5453C261.2010500@gmail.com>


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 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



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 <linux@roeck-us.net> 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	other threads:[~2014-11-09 11:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22  0:28 [Qemu-devel] [Consult] microblaze: About running upstream main branch qemu Chen Gang
2014-10-26 13:16 ` Chen Gang
2014-10-26 13:28 ` Chen Gang
2014-10-27  1:47   ` Chen Gang
2014-10-27 14:47     ` Chen Gang
2014-10-30 14:20       ` Chen Gang
2014-10-31 17:09         ` Chen Gang
2014-11-09 11:57           ` Chen Gang [this message]
  -- strict thread matches above, loose matches on Subject: below --
2014-10-19 23:38 Chen Gang
2014-10-19 13:37 Chen Gang
2014-10-19 13:38 ` Max Filippov
2014-10-19 13:58   ` Chen Gang
2014-10-19 14:58     ` Guenter Roeck
2014-10-20 15:23       ` Chen Gang
2014-10-21  4:37         ` Guenter Roeck
2014-10-21 10:41           ` Chen Gang
2014-10-21 16:43             ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=545F569E.9070206@gmail.com \
    --to=gang.chen.5i5j@gmail.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux@roeck-us.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.