embeddedxen-devel — EmbeddedXEN development discussions

[Embeddedxen-devel] Mounting root filesystem through NFS

[Salvatore C. <sal...@gm...>]

Hi, I'm writing since I'm trying to run EmbeddedXen on top of QEMU.
I have the root filesystem in /home/user/opt/boards/filesystem/rootfs-oabi/
and the machine where the NFS server is running has ip=10.0.2.15

I run qeum with the following command

sudo qemu-system-arm -localtime -M mainstone -kernel
xen/arch/arm/boot/zImage -append "root=/dev/nfs
nfsroot=10.0.2.15:/home/user/opt/boards/filesystem/rootfs-oabi
rw ip=dhcp" -pflash ./flash1 -pflash ./flash2 -s -m 256 -net nic -net
tap,ifname=$iface,script=/etc/qemu-ifup -serial vc:1000x500

and before mounting the root filesystem it prints the following:

OVERRUN
done!
[DOM0] IP-Config: Complete:
   device=eth0, addr=192.168.1.150, mask=255.255.55.0, gw=192.168.1.1
   host=qemu0, domain=, nis-domani=(none)
   bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath=
[DOM0] <5> Looking up port of RPC 100003/2 on 192.168.1.1
[DOM0] <5> portmap: server 192.168.1.1 not responding, timed out
[DOM0] <3> Root-NFS: Unable to get nfsd port number for server, using
default
...

It is clear that the ip address where the NFS server should be is not
right...

Is there any way to change the NFS configuration parameters in order to put
the right values?
Is there something wrong in the command line?

I tryied to append the NFS parameters through the kernel command line but it
lokks like it is not working.

Any hint?

Thanks,

Salvatore

[Embeddedxen-devel] Next release

[ROSSIER D. <Dan...@he...>]

For information, we will release a new version of EmbeddedXEN in the upcoming days which includes a new building environment,
a paravirtualized Linux 2.6.34-dom0, linux-2.6.18-dom0 (improved), and the realtime domain xenomai-2.6.4-domU-RT (few modifications at the moment).

The following machines are supported: mainstone (qemu), versatilepb (qemu), and Colibri/PXA270.

We have also consolidated our xen-guest API which remains simple and introduce low overhead.

As next actions, we will also provide the support for ARM-11 processors (ARMv6) and OMAPx series (ARMv7).

Cheers
Daniel

Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[ROSSIER D. <Dan...@he...>]

Hi Pushparajan,

Indeed, XEN as such - from out of the shelf - is not suited to hard realtime applications, mainly due to its inter-domains scheduling strategy
and its IRQ layer model. First, the scheduler needs to deserve a hard realtime domain whenever it is required by task deadlines, and this
is not properly done yet (nor in embeddedxen actually). This is a major point on which we will spend more time on over the next months.
Any help in this area will be welcome besides. On the other hand, the IRQ layer model is based on a event polling mechanism within the
guest domain, which is not adequate to hard realtime; so this part also needs to be reworked out and designed accordingly.
This is why we set up a particular domU-RT domain (for hard realtime applications) in XEN to be able to manage this kind of issues, but
as you can see, a lot of work remains to be done. If you want, we can guide you through theses different adaptations; but one thing sure,

Thanks for your help.

Kind regards
Daniel


> -----Original Message-----
> From: Pushparajan V [mailto:vp...@gm...]
> Sent: mardi 1 juin 2010 20:17
> To: SAMBUC Lionel
> Cc: emb...@li...
> Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> 
> Hi Lionel,
> On Sun, May 23, 2010 at 12:21 AM, Pushparajan V <vp...@gm...>
> wrote:
> Hi Lionel,
> On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <lionel.sambuc@heig-
> vd.ch> wrote:
> Hello,
> 
> First, let me apologize for my last mail, whose formatting was a disaster. I am
> glad it still was helpful.
> 
> > -----Original Message-----
> > From: Pushparajan V [mailto:vp...@gm...]
> > Sent: Tuesday, May 18, 2010 8:25 PM
> > To: SAMBUC Lionel
> > Cc: emb...@li...
> > Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> >
> > Hi Lionel,
> >
> > Thanks for the guidance.
> >
> > Finally I am able to connect to the NFS server from qemu (without
> > breaking my head with making the rootfs in flash).
> >
> >
> > I reiterated the steps and got the correct configuration for this.
> > Since this is first time working with bridge & tap for U-boot, got
> > confused with the steps. :)
> >
> > As 2 ethernet cards are required, I added one more network adapter in
> > the vmware ubuntu (adding new network card costed me just $ 0.. :) )
> >
> It seems this is not yet clear, so I will try to explicit this by using an analogy.
> 
> The bridge is like a hub, which has a number of interfaces (ports), as this is all
> software we can add and remove "ports" (interfaces) on the fly.
> 
> Now in /etc/interfaces we define the bridge br0 and attached to it an ip
> address (in my configuration 192.168.1.1), while each ports (interfaces) as no
> ip identification of it's own.
> 
> A little trick used to ensure that the Ethernet interfaces (our "ports") does
> not filter the traffic as they would usually do and transmit everything up the
> network stack is used. We put them into promiscuous mode.
> 
> This is done in the same file for the second physical card and by qemu
> through the parameters we give it (as we instruct it to use the tap0 interface
> and the qemu-ifup and qemu-ifdown scripts). Those two script simply add to
> / remove from the bridge the interface (the "port") created by qemu when it
> starts and quits.
> 
> This works because as soon as it is part of the bridge, all the traffic sent to /
> received on the bridge is automatically seen by all its "ports".
> 
> On the other end of each "ports" there is a second network interface (be it
> the one emulated by qemu, or a real one) which has its own ip address.
> 
> Then we tell the dhcp server to only listen for request on the bridge (and not
> one of its port) we enables us to add / remove "ports" on the fly without
> having to relaunch the dhcp server, as the bridge (hub) itself stays always on.
> 
> For the tftp server, there is no such facilities, so it will answer anyone who try
> to load a file from it. As there is only our kernel uImage, it is not that much of
> a threat, but it means other computer can connect and load any file visible
> under the tftp root. It may be possible to increase security by adding some
> restriction on  the inet super server.
> 
> Now for the NFS server, it will allow the connection to the shares only
> according to the /etc/exports file in which we allow only our private network
> to access to our shares ("exports").
> 
> Thanks for a clear explanation. I will try this out
> 
> > 1. Changed /etc/exports for the local subnet (192.168.198.0) [got -13
> > "access denied errors, so gave full permission with asterix) 2.
> > Changed /etc/dhcp3/dhcpd.conf 3. Changed /etc/network/interfaces to
> > add new bridge interface with new ethernet card eth1 4. Reconfigured
> > embeddedxem/.cmdline.h -> It was pointing to hardcoded IP address
> > settings.. changed and recompiled
> For the rights, a line like the following should be alright:
> /opt/boards/filesystem/rootfs-
> oabi      192.168.198.0/24(rw,no_root_squash,async,no_subtree_check)
> 
> As explained before, the bridge do not require to have a real interface
> connected to it, so you may simply delete it and remove the references to
> your eth1 card in /etc/network. QEMU will still work as intended.
> 
> >
> > Finally able to see the DOM0 shell. But sometimes getting nfs: RPC
> > call returned error 101, which is anyway some configuration issue.
> >
> This error is still to be explained, we also have it, usually one time every two
> starts, or something approaching. I have no solution or idea concerning this
> minor issue.
> 
> > Attached screenshot of it.
> >
> > I have one query, From which version of Xen (svn label) embeddedxen is
> > cloned from ?
> >
> The current EmbeddedXen is based on the official 3.1.3 version of Xen.
> 
> > I heard Samsung has done an ARM port of Xen already and didn't
> > upstream it and also it is not in sync with latest Xen. Is embeddedxen
> > also falls into the same state or it goes in sync with Xen community?
> >
> The project is still in alpha stage, so there is no plan to upstream it at the
> moment. Now, the project was done while incorporating some of the
> modifications released by Samsung, but we are not related to them.
> 
> We are planning to update the linux kernel used to version 2.6.34 (I am
> personally starting on this) and we may upgrade our Xen version to the 4.0.0.
> That last point is not yet defined, as we need to evaluate the benefit our
> internal projects may gain from this move.
> Thats a good news!!.. I am just curious about various usage scenarios of
> embeddedxen. If its possible to share, please do so.
> 
> We also continue our work on the realtime side, as we still need to do some
> major modifications to the scheduling policy of the hypervisor (Xen) to be
> able to ensure the realtime constraints for a domain.
> 
> 
> The next item i am planning to explore more about is the performance of
> hypervisor/DOM0 service layer calls  under Real time constraints. (need to try
> DOM-rt-xenomai next). I already read some articles about real time usability
> of Xen. But also confused with KVM added up from Linux kernel 2.6.20 with
> paravirtualization + hardware virtualization (support only for x86).
> 
> 
> I tried the xenomai stack as well and found some DOM-RT: xen_tests
> running. The main objective as you mentioned is to get seperate scheduling
> for each domain with hard realtime constraint. I got that I-pipe is responsible
> for this and its ported for some specific board under embeddedxen code
> base. (should be pxa? )
> 
> If you can give more exposure on the flow of code under DOM-RT, it will be
> very helpful. I can collect the profiling data using Oprofile and share it.
> 
> If possible, we can have offline chat on  IRC or private chat to get more
> understanding on this.
> 
> I found that OKL4 proves that it satisfy all RT constraints and also many
> papers are constantly proving that xen is not suited for embedded control
> systems. I strongly doubt on this.
> 
> not sure what problem does Xen have that OKL4 solve for the RT?.. Is it only
> the scheduling method at the hypervisor level?
> 
> basically my first objective is to get a proof that xen is also usable for RT
> systems as well.
> 
> 
> > Really gr8 work done here. I would love to contribute on the front of
> > documentation (as much a begineer can do here).
> >
> We are welcoming any help, but to answer that last point, it may help if you
> could mail me what are your goals concerning EmbeddedXen.
> We can then discuss what you can contribute to the project.
> 
> I am just experimenting with xen (for embedded systems) without much
> knowledge about it, So cannot comment more on the goals concerning to it.
> 
> 
> I want to try the following things with embeddedxen,
> 
> 1. VM snapshot for pause/resume (pause at one device and resume at
> another device) 2. Try various types of virtualization possible, application virt
> (RPC), OS virt, hardware virt. software virt (qemu) 3. Try some real world
> scenario (android, meego with beagleboard)
> 
> Not sure about the practical implication of the above experiments and also
> not sure whether any of the above trails will help in contribution.
> 
> 
> 
> --
> Pushparajan V
> http://vprajan.blogspot.com
> 
> 
> 
> 
> 
> --
> Pushparajan V
> http://vprajan.blogspot.com
> 

Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[Pushparajan V <vp...@gm...>]

Hi Lionel,

On Sun, May 23, 2010 at 12:21 AM, Pushparajan V <vp...@gm...> wrote:

> Hi Lionel,
>
> On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <lio...@he...>wrote:
>
>> Hello,
>>
>> First, let me apologize for my last mail, whose formatting was a
>> disaster. I am glad it still was helpful.
>>
>> > -----Original Message-----
>> > From: Pushparajan V [mailto:vp...@gm...]
>> > Sent: Tuesday, May 18, 2010 8:25 PM
>> > To: SAMBUC Lionel
>> > Cc: emb...@li...
>> > Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
>> >
>> > Hi Lionel,
>> >
>> > Thanks for the guidance.
>> >
>> > Finally I am able to connect to the NFS server from qemu (without
>> > breaking my head with making the rootfs in flash).
>> >
>> >
>> > I reiterated the steps and got the correct configuration for this.
>> > Since this is first time working with bridge & tap for U-boot, got
>> > confused with the steps. :)
>> >
>> > As 2 ethernet cards are required, I added one more network adapter in
>> > the vmware ubuntu (adding new network card costed me just $ 0.. :) )
>> >
>>
>> It seems this is not yet clear, so I will try to explicit this by using an
>> analogy.
>>
>> The bridge is like a hub, which has a number of interfaces (ports), as
>> this is all software we can add and remove "ports" (interfaces) on the
>> fly.
>>
>> Now in /etc/interfaces we define the bridge br0 and attached to it an ip
>> address (in my configuration 192.168.1.1), while each ports (interfaces)
>> as no ip identification of it's own.
>>
>> A little trick used to ensure that the Ethernet interfaces (our "ports")
>> does not filter the traffic as they would usually do and transmit
>> everything up the network stack is used. We put them into promiscuous
>> mode.
>>
>> This is done in the same file for the second physical card and by qemu
>> through the parameters we give it (as we instruct it to use the tap0
>> interface and the qemu-ifup and qemu-ifdown scripts). Those two script
>> simply add to / remove from the bridge the interface (the "port")
>> created by qemu when it starts and quits.
>>
>> This works because as soon as it is part of the bridge, all the traffic
>> sent to / received on the bridge is automatically seen by all its "ports".
>>
>> On the other end of each "ports" there is a second network interface
>> (be it the one emulated by qemu, or a real one) which has its own ip
>> address.
>>
>> Then we tell the dhcp server to only listen for request on the bridge
>> (and not one of its port) we enables us to add / remove "ports" on the
>> fly without having to relaunch the dhcp server, as the bridge (hub) itself
>> stays always on.
>>
>> For the tftp server, there is no such facilities, so it will answer anyone
>> who try to load a file from it. As there is only our kernel uImage, it is
>> not that much of a threat, but it means other computer can connect and
>> load
>> any file visible under the tftp root. It may be possible to increase
>> security
>> by adding some restriction on  the inet super server.
>>
>> Now for the NFS server, it will allow the connection to the shares only
>> according to the /etc/exports file in which we allow only our private
>> network to access to our shares ("exports").
>>
>
> Thanks for a clear explanation. I will try this out
>
>
>> > 1. Changed /etc/exports for the local subnet (192.168.198.0) [got -13
>> > "access denied errors, so gave full permission with asterix) 2. Changed
>> > /etc/dhcp3/dhcpd.conf 3. Changed /etc/network/interfaces to add new
>> > bridge interface with new ethernet card eth1 4. Reconfigured
>> > embeddedxem/.cmdline.h -> It was pointing to hardcoded IP address
>> > settings.. changed and recompiled
>>
>> For the rights, a line like the following should be alright:
>> /opt/boards/filesystem/rootfs-oabi
>> 192.168.198.0/24(rw,no_root_squash,async,no_subtree_check)<http://192.168.198.0/24%28rw,no_root_squash,async,no_subtree_check%29>
>>
>> As explained before, the bridge do not require to have a real interface
>> connected to it, so you may simply delete it and remove the references
>> to your eth1 card in /etc/network. QEMU will still work as intended.
>>
>> >
>> > Finally able to see the DOM0 shell. But sometimes getting nfs: RPC call
>> > returned error 101, which is anyway some configuration issue.
>> >
>>
>> This error is still to be explained, we also have it, usually one time
>> every two starts, or something approaching. I have no solution or idea
>> concerning this minor issue.
>>
>> > Attached screenshot of it.
>> >
>> > I have one query, From which version of Xen (svn label) embeddedxen is
>> > cloned from ?
>> >
>>
>> The current EmbeddedXen is based on the official 3.1.3 version of Xen.
>>
>> > I heard Samsung has done an ARM port of Xen already and didn't upstream
>> > it and also it is not in sync with latest Xen. Is embeddedxen also
>> > falls into the same state or it goes in sync with Xen community?
>> >
>> The project is still in alpha stage, so there is no plan to upstream it
>> at the moment. Now, the project was done while incorporating some of the
>> modifications released by Samsung, but we are not related to them.
>>
>> We are planning to update the linux kernel used to version 2.6.34 (I am
>> personally starting on this) and we may upgrade our Xen version to the
>> 4.0.0. That last point is not yet defined, as we need to evaluate the
>> benefit our internal projects may gain from this move.
>>
>> Thats a good news!!.. I am just curious about various usage scenarios of
> embeddedxen. If its possible to share, please do so.
>
>
>> We also continue our work on the realtime side, as we still need to do
>> some major modifications to the scheduling policy of the hypervisor (Xen)
>> to be able to ensure the realtime constraints for a domain.
>>
>>
> The next item i am planning to explore more about is the performance of
> hypervisor/DOM0 service layer calls  under Real time constraints. (need to
> try DOM-rt-xenomai next). I already read some articles about real time
> usability of Xen. But also confused with KVM added up from Linux kernel
> 2.6.20 with paravirtualization + hardware virtualization (support only for
> x86).
>


I tried the xenomai stack as well and found some DOM-RT: xen_tests running.
The main objective as you mentioned is to get seperate scheduling for each
domain with hard realtime constraint. I got that I-pipe is responsible for
this and its ported for some specific board under embeddedxen code base.
(should be pxa? )

If you can give more exposure on the flow of code under DOM-RT, it will be
very helpful. I can collect the profiling data using Oprofile and share it.

If possible, we can have offline chat on  IRC or private chat to get more
understanding on this.

I found that OKL4 proves that it satisfy all RT constraints and also many
papers are constantly proving that xen is not suited for embedded control
systems. I strongly doubt on this.

not sure what problem does Xen have that OKL4 solve for the RT?.. Is it only
the scheduling method at the hypervisor level?

basically my first objective is to get a proof that xen is also usable for
RT systems as well.


>
>>
>>
>  > Really gr8 work done here. I would love to contribute on the front of
>> > documentation (as much a begineer can do here).
>> >
>> We are welcoming any help, but to answer that last point, it may help
>> if you could mail me what are your goals concerning EmbeddedXen.
>> We can then discuss what you can contribute to the project.
>>
>>
> I am just experimenting with xen (for embedded systems) without much
> knowledge about it, So cannot comment more on the goals concerning to it.
>
>
> I want to try the following things with embeddedxen,
>
> 1. VM snapshot for pause/resume (pause at one device and resume at another
> device)
> 2. Try various types of virtualization possible, application virt (RPC), OS
> virt, hardware virt. software virt (qemu)
> 3. Try some real world scenario (android, meego with beagleboard)
>
> Not sure about the practical implication of the above experiments and also
> not sure whether any of the above trails will help in contribution.
>
>
>
>
> --
> Pushparajan V
> http://vprajan.blogspot.com
>
>
>
>


-- 
Pushparajan V
http://vprajan.blogspot.com

Re: [Embeddedxen-devel] Launch with some warning and how to show GUI in qemu box

[SAMBUC L. <lio...@he...>]

Hello,

> -----Original Message-----
> From: om...@gm... [mailto:om...@gm...] On Behalf Of Tek-life
> Sent: Saturday, May 22, 2010 7:34 AM
> To: emb...@li...
> Cc: SAMBUC Lionel; Pushparajan V
> Subject: Launch with some warning and how to show GUI in qemu box
> 
> Hi,all.I have run the embedxen on qemu correctly.But I also have some
> question:
> 
> 1.
> When I run the embededxen on qemu,it launchs.But has some warning .Does
> it matter?
> The message is :
> ...
> locale: Cannot set LC_CTYPE to default locale: No such file or
> directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or
> directory
> locale: Cannot set LC_ALL to default locale: No such file or directory

This is normal, those files are not on the rootfs. It just means you won't 
have any translation.

> Setting the system clock..
> Cannot access the Hardware Clock via any known method.
> ...
Just means there is no way to read/write the realtime clock (the one which 
store the current hour of the day and date). This has no consequence at this 
time in the project.

> Starting kernel log daemon: klogd.
> * Not starting internet superserver: no services enabled.
> 
> 2.
> How to show the GUI in the qemu box?
> When I run the startx ,then the error is :
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME

...

> /usr/bin/startx: line 131: xauth: command not found
> /usr/bin/startx: line 141: xauth: command not found
> /usr/bin/startx: line 143: xauth: command not found
> /usr/bin/startx: line 141: xauth: command not found
> /usr/bin/startx: line 143: xauth: command not found
> /usr/bin/startx: line 154: xinit: command not found
> /usr/bin/startx: line 158: xauth: command not found
> 

... Again the problem seems pretty clear to me.

> And after that .
> when I input the init 5 ,Nothing happens.
> 
Not a surprise, there is no X installed, I believe. The level 5 is the level 
usually used for graphical login, not a good idea to go there if you have 
not a functioning X.

> iemQemu:~# init 5
> INIT: Switching to runlevel: 5
> INIT: Sending processes the TERM signal
> 
> Then nothing happens.
> 
> How to show the GUI in Qemu box?
> 
There is no GUI on the given rootfs, you may use one from another embedded 
project, though.

> 
> Best wishes.

Regards,

Lionel SAMBUC

Re: [Embeddedxen-devel] Launch with some warning and how to show GUI in qemu box

[Pushparajan V <vp...@gm...>]

Hi,

On Sat, May 22, 2010 at 11:04 AM, Tek-life <tek...@te...> wrote:

> Hi,all.I have run the embedxen on qemu correctly.But I also have some
> question:
>
> 1.
> When I run the embededxen on qemu,it launchs.But has some warning .*Does
> it matter*?
> The message is :
> ...
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory
> Setting the system clock..
> Cannot access the Hardware Clock via any known method.
> ...
> Starting kernel log daemon: klogd.
> * Not starting internet superserver: no services enabled.
>
> 2.
> How to show the GUI in the qemu box?
> *When I run the **startx* ,then the error is :
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> [DOM0] DON't Call ME
> /usr/bin/startx: line 131: xauth: command not found
> /usr/bin/startx: line 141: xauth: command not found
> /usr/bin/startx: line 143: xauth: command not found
> /usr/bin/startx: line 141: xauth: command not found
> /usr/bin/startx: line 143: xauth: command not found
> /usr/bin/startx: line 154: xinit: command not found
> /usr/bin/startx: line 158: xauth: command not found
>
> And after that .
> *when I input the init 5* ,Nothing happens.
>
>
I believe the rootfs distributed by embeddedxen project doesn't have Xserver
or init 5. You can create a custom rootfs (take it from some embedded linux
project, meego, android) and try starting X under DOM0.



> iemQemu:~# init 5
> INIT: Switching to runlevel: 5
> INIT: Sending processes the TERM signal
>
> Then nothing happens.
>
> How to show the GUI in Qemu box?
>
>
> Best wishes.




-- 
Pushparajan V
http://vprajan.blogspot.com

Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[Pushparajan V <vp...@gm...>]

Hi Lionel,

On Thu, May 20, 2010 at 7:36 PM, SAMBUC Lionel <lio...@he...>wrote:

> Hello,
>
> First, let me apologize for my last mail, whose formatting was a
> disaster. I am glad it still was helpful.
>
> > -----Original Message-----
> > From: Pushparajan V [mailto:vp...@gm...]
> > Sent: Tuesday, May 18, 2010 8:25 PM
> > To: SAMBUC Lionel
> > Cc: emb...@li...
> > Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> >
> > Hi Lionel,
> >
> > Thanks for the guidance.
> >
> > Finally I am able to connect to the NFS server from qemu (without
> > breaking my head with making the rootfs in flash).
> >
> >
> > I reiterated the steps and got the correct configuration for this.
> > Since this is first time working with bridge & tap for U-boot, got
> > confused with the steps. :)
> >
> > As 2 ethernet cards are required, I added one more network adapter in
> > the vmware ubuntu (adding new network card costed me just $ 0.. :) )
> >
>
> It seems this is not yet clear, so I will try to explicit this by using an
> analogy.
>
> The bridge is like a hub, which has a number of interfaces (ports), as
> this is all software we can add and remove "ports" (interfaces) on the fly.
>
> Now in /etc/interfaces we define the bridge br0 and attached to it an ip
> address (in my configuration 192.168.1.1), while each ports (interfaces)
> as no ip identification of it's own.
>
> A little trick used to ensure that the Ethernet interfaces (our "ports")
> does not filter the traffic as they would usually do and transmit
> everything up the network stack is used. We put them into promiscuous mode.
>
> This is done in the same file for the second physical card and by qemu
> through the parameters we give it (as we instruct it to use the tap0
> interface and the qemu-ifup and qemu-ifdown scripts). Those two script
> simply add to / remove from the bridge the interface (the "port")
> created by qemu when it starts and quits.
>
> This works because as soon as it is part of the bridge, all the traffic
> sent to / received on the bridge is automatically seen by all its "ports".
>
> On the other end of each "ports" there is a second network interface
> (be it the one emulated by qemu, or a real one) which has its own ip
> address.
>
> Then we tell the dhcp server to only listen for request on the bridge
> (and not one of its port) we enables us to add / remove "ports" on the
> fly without having to relaunch the dhcp server, as the bridge (hub) itself
> stays always on.
>
> For the tftp server, there is no such facilities, so it will answer anyone
> who try to load a file from it. As there is only our kernel uImage, it is
> not that much of a threat, but it means other computer can connect and load
> any file visible under the tftp root. It may be possible to increase
> security
> by adding some restriction on  the inet super server.
>
> Now for the NFS server, it will allow the connection to the shares only
> according to the /etc/exports file in which we allow only our private
> network to access to our shares ("exports").
>

Thanks for a clear explanation. I will try this out


> > 1. Changed /etc/exports for the local subnet (192.168.198.0) [got -13
> > "access denied errors, so gave full permission with asterix) 2. Changed
> > /etc/dhcp3/dhcpd.conf 3. Changed /etc/network/interfaces to add new
> > bridge interface with new ethernet card eth1 4. Reconfigured
> > embeddedxem/.cmdline.h -> It was pointing to hardcoded IP address
> > settings.. changed and recompiled
>
> For the rights, a line like the following should be alright:
> /opt/boards/filesystem/rootfs-oabi
> 192.168.198.0/24(rw,no_root_squash,async,no_subtree_check)<http://192.168.198.0/24%28rw,no_root_squash,async,no_subtree_check%29>
>
> As explained before, the bridge do not require to have a real interface
> connected to it, so you may simply delete it and remove the references
> to your eth1 card in /etc/network. QEMU will still work as intended.
>
> >
> > Finally able to see the DOM0 shell. But sometimes getting nfs: RPC call
> > returned error 101, which is anyway some configuration issue.
> >
>
> This error is still to be explained, we also have it, usually one time
> every two starts, or something approaching. I have no solution or idea
> concerning this minor issue.
>
> > Attached screenshot of it.
> >
> > I have one query, From which version of Xen (svn label) embeddedxen is
> > cloned from ?
> >
>
> The current EmbeddedXen is based on the official 3.1.3 version of Xen.
>
> > I heard Samsung has done an ARM port of Xen already and didn't upstream
> > it and also it is not in sync with latest Xen. Is embeddedxen also
> > falls into the same state or it goes in sync with Xen community?
> >
> The project is still in alpha stage, so there is no plan to upstream it
> at the moment. Now, the project was done while incorporating some of the
> modifications released by Samsung, but we are not related to them.
>
> We are planning to update the linux kernel used to version 2.6.34 (I am
> personally starting on this) and we may upgrade our Xen version to the
> 4.0.0. That last point is not yet defined, as we need to evaluate the
> benefit our internal projects may gain from this move.
>
> Thats a good news!!.. I am just curious about various usage scenarios of
embeddedxen. If its possible to share, please do so.


> We also continue our work on the realtime side, as we still need to do
> some major modifications to the scheduling policy of the hypervisor (Xen)
> to be able to ensure the realtime constraints for a domain.
>
>
The next item i am planning to explore more about is the performance of
hypervisor/DOM0 service layer calls  under Real time constraints. (need to
try DOM-rt-xenomai next). I already read some articles about real time
usability of Xen. But also confused with KVM added up from Linux kernel
2.6.20 with paravirtualization + hardware virtualization (support only for
x86).


>
>
 > Really gr8 work done here. I would love to contribute on the front of
> > documentation (as much a begineer can do here).
> >
> We are welcoming any help, but to answer that last point, it may help
> if you could mail me what are your goals concerning EmbeddedXen.
> We can then discuss what you can contribute to the project.
>
>
I am just experimenting with xen (for embedded systems) without much
knowledge about it, So cannot comment more on the goals concerning to it.


I want to try the following things with embeddedxen,

1. VM snapshot for pause/resume (pause at one device and resume at another
device)
2. Try various types of virtualization possible, application virt (RPC), OS
virt, hardware virt. software virt (qemu)
3. Try some real world scenario (android, meego with beagleboard)

Not sure about the practical implication of the above experiments and also
not sure whether any of the above trails will help in contribution.




-- 
Pushparajan V
http://vprajan.blogspot.com

[Embeddedxen-devel] Launch with some warning and how to show GUI in qemu box

[Tek-life <tek...@te...>]

Hi,all.I have run the embedxen on qemu correctly.But I also have some
question:

1.
When I run the embededxen on qemu,it launchs.But has some warning .*Does it
matter*?
The message is :
...
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting the system clock..
Cannot access the Hardware Clock via any known method.
...
Starting kernel log daemon: klogd.
* Not starting internet superserver: no services enabled.

2.
How to show the GUI in the qemu box?
*When I run the **startx* ,then the error is :
[DOM0] DON't Call ME
[DOM0] DON't Call ME
[DOM0] DON't Call ME
[DOM0] DON't Call ME
[DOM0] DON't Call ME
[DOM0] DON't Call ME
[DOM0] DON't Call ME
/usr/bin/startx: line 131: xauth: command not found
/usr/bin/startx: line 141: xauth: command not found
/usr/bin/startx: line 143: xauth: command not found
/usr/bin/startx: line 141: xauth: command not found
/usr/bin/startx: line 143: xauth: command not found
/usr/bin/startx: line 154: xinit: command not found
/usr/bin/startx: line 158: xauth: command not found

And after that .
*when I input the init 5* ,Nothing happens.

iemQemu:~# init 5
INIT: Switching to runlevel: 5
INIT: Sending processes the TERM signal

Then nothing happens.

How to show the GUI in Qemu box?


Best wishes.

Re: [Embeddedxen-devel] Load dom0 Error by Qemu

[Pushparajan V <vp...@gm...>]

Hi tek life,

2010/5/21 Tek-life <tek...@te...>

> hi,all.
> I follow this article step by stem :
> http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted
> And lunch the embededxen by qemu.
> But It cannot run correctly.
> The error infomation is :
>
>      (XEN) ***************************** LOADING DOMAIN 0
> *****************************
>      (XEN) Parsing domain #0 (1919876B) at 0xc3e1b478
>      (XEN) elf_init: not an ELF binary
>
> But I find that the vmlinux.dom0 is ELF binary indeed.
>
>     ro...@lo...main:~/embededxen_work/git_tree/embeddedxen$ file
> vmlinux.dom0
>     vmlinux.dom0: ELF 32-bit LSB executable, ARM, version 1, statically
> linked, strippe
>
> Who can tell me why?
>
>
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> map addr 0x8182dc0
> Uncompressing
> Xen.............................................................................................................................
> done, booting the kernel.
>  __  __            _____  _   _____              _ _ _          _
>  \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
>   \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
>   /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
>  /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|
>
>  http://www.cl.cam.ac.uk/netos/xen
>  University of Cambridge Computer Laboratory
>
>  Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14
> CET 2009
>  EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System (REDS)
> Institute from HEIG-VD/Switzerland
>  http://reds.heig-vd.ch
>
>  Latest ChangeSet: unavailable
>
> (XEN) Hypervisor area start at: 0xff000000 (virt)
> (XEN) Physical RAM map:
> (XEN)   00000000a0000000: 0000000004000000
> (XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
> (XEN) End of Xen Area: 2561MiB (2622464KiB)
> (XEN) End of RAM: 0xa3f00000
> (XEN) Boot allocator @ a0100000 - a0115000
> (XEN) NUMA turned off
> (XEN) Faking a node at 0000000000000000-00000000a3f00000
> (XEN) xenheap: 00000000a0115000 - 00000000a0314fff
> (XEN) xenheap(virt): ff115000 - ff314fff
> (XEN) ### frametable: ff315000
> (XEN) ### min_page: a0100
> (XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000
> maddr_to_page(ps)=ff3151f8
> (XEN) Xen heap: 2MiB (2048kiB)
> (XEN) ### first_valid_mfn = a0315
> (XEN) ### max_page = a3f00
> (XEN) Domain heap initialised: DMA width 32 bits
> (XEN) Dom Heap: 15230 pages
> (XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
> (XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init():
> alloc_xenheap_page
> (XEN) Mapping I/O on mainstone...
> (XEN) Init IRQ...
> (XEN) Initing arch-IRQ...
> (XEN) Init scheduler...
> (XEN) Using scheduler: Simple EDF Scheduler (sedf)
> (XEN) Initializing timer...
> (XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
> (XEN) Platform periodic timer is osmr0 @ 1000 Hz
> (XEN) ### arch_domain create OK
> (XEN) ### t->shared[i] = ff308000
> (XEN) ### t->shared[i] = ff307000
> (XEN) ### t->shared[i] = ff306000
> (XEN) ### t->shared[i] = ff305000
> (XEN) ### frame_table: ff315000
> (XEN) ### virt: ff308000
> (XEN)  pg: ff3180c0
> (XEN) ### virt: ff307000
> (XEN)  pg: ff3180a8
> (XEN) ### virt: ff306000
> (XEN)  pg: ff318090
> (XEN) ### virt: ff305000
> (XEN)  pg: ff318078
> (XEN) ### arch_domain create OK
> (XEN) ***************************** LOADING DOMAIN 0
> *****************************
> (XEN) Parsing domain #0 (1919876B) at 0xc3e1b478
> (XEN) elf_init: not an ELF binary
>


I too got these errors. This is probably due to not readable DOM0 in the
integrated single binary.

Try a clean build,

./build-embedded-xen -clean

And also check whether you are using correct toolchain as mentioned in the
documents. Better to use openembedded or codesourcery toolchain
(arm-none-eabi-).

use,
CROSS_COMPILE=arm-none-eabi-

before starting the build.


>
> My build kernel information ：
> ........
>   Building modules, stage 2.
>   OBJCOPY xen/arch/arm/boot/Image
>   MODPOST
>   MV      xen/arch/arm/boot/Image to xen/arch/arm/boot/Image.xen
>   CAT     xen/arch/arm/boot/Image.xen vmlinux.dom0 vmlinux.eod zero.eod
> vmlinux.domu-rt vmlinux.eod one.eod vmlinux.eod >
> xen/arch/arm/boot/Image.tmp
>   MV      xen/arch/arm/boot/Image.tmp to xen/arch/arm/boot/Image
>   Kernel: xen/arch/arm/boot/Image is ready
>   GZIP    xen/arch/arm/boot/compressed/piggy.gz
>   AS      xen/arch/arm/boot/compressed/piggy.o
>   LD      xen/arch/arm/boot/compressed/vmlinux
>   RM      xen/arch/arm/boot/Image
>   OBJCOPY xen/arch/arm/boot/zImage
>   Kernel: xen/arch/arm/boot/zImage is ready
> #################################### uImage
> ####################################
>   CHK     include/linux/version.h
> make[1]: `include/asm-arm/mach-types.h' is up to date.
>   CHK     include/linux/utsrelease.h
>   OBJCOPY xen/arch/arm/boot/Image
>   MV      xen/arch/arm/boot/Image to xen/arch/arm/boot/Image.xen
>   CAT     xen/arch/arm/boot/Image.xen vmlinux.dom0 vmlinux.eod zero.eod
> vmlinux.domu-rt vmlinux.eod one.eod vmlinux.eod >
> xen/arch/arm/boot/Image.tmp
>   MV      xen/arch/arm/boot/Image.tmp to xen/arch/arm/boot/Image
>   Kernel: xen/arch/arm/boot/Image is ready
>   GZIP    xen/arch/arm/boot/compressed/piggy.gz
>   AS      xen/arch/arm/boot/compressed/piggy.o
>   LD      xen/arch/arm/boot/compressed/vmlinux
>   RM      xen/arch/arm/boot/Image
>   OBJCOPY xen/arch/arm/boot/zImage
>   Kernel: xen/arch/arm/boot/zImage is ready
>   UIMAGE  xen/arch/arm/boot/uImage
> Image Name:   Linux-2.6.18
> Created:      Fri May 21 16:38:01 2010
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:    1764332 Bytes = 1722.98 kB = 1.68 MB
> Load Address: 0xA0008000
> Entry Point:  0xA0008000
>   MV      uImage to uImage.mainstone
>   Kernel: xen/arch/arm/boot/uImage.mainstone is ready
> ######### WARNING Use uImage.mainstone (instead of uImage)
>
>
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Embeddedxen-devel mailing list
> Emb...@li...
> https://lists.sourceforge.net/lists/listinfo/embeddedxen-devel
>
>


-- 
Pushparajan V
http://vprajan.blogspot.com

[Embeddedxen-devel] Load dom0 Error by Qemu

[Tek-life <tek...@te...>]

hi,all.
I follow this article step by stem :
http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted
And lunch the embededxen by qemu.
But It cannot run correctly.
The error infomation is :

     (XEN) ***************************** LOADING DOMAIN 0
*****************************
     (XEN) Parsing domain #0 (1919876B) at 0xc3e1b478
     (XEN) elf_init: not an ELF binary

But I find that the vmlinux.dom0 is ELF binary indeed.

    ro...@lo...main:~/embededxen_work/git_tree/embeddedxen$ file
vmlinux.dom0
    vmlinux.dom0: ELF 32-bit LSB executable, ARM, version 1, statically
linked, strippe

Who can tell me why?

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
map addr 0x8182dc0
Uncompressing
Xen.............................................................................................................................
done, booting the kernel.
 __  __            _____  _   _____              _ _ _          _
 \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
  \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
  /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
 /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|

 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory

 Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14
CET 2009
 EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System (REDS)
Institute from HEIG-VD/Switzerland
 http://reds.heig-vd.ch

 Latest ChangeSet: unavailable

(XEN) Hypervisor area start at: 0xff000000 (virt)
(XEN) Physical RAM map:
(XEN)   00000000a0000000: 0000000004000000
(XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
(XEN) End of Xen Area: 2561MiB (2622464KiB)
(XEN) End of RAM: 0xa3f00000
(XEN) Boot allocator @ a0100000 - a0115000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-00000000a3f00000
(XEN) xenheap: 00000000a0115000 - 00000000a0314fff
(XEN) xenheap(virt): ff115000 - ff314fff
(XEN) ### frametable: ff315000
(XEN) ### min_page: a0100
(XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000
maddr_to_page(ps)=ff3151f8
(XEN) Xen heap: 2MiB (2048kiB)
(XEN) ### first_valid_mfn = a0315
(XEN) ### max_page = a3f00
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Dom Heap: 15230 pages
(XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
(XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init():
alloc_xenheap_page
(XEN) Mapping I/O on mainstone...
(XEN) Init IRQ...
(XEN) Initing arch-IRQ...
(XEN) Init scheduler...
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) Initializing timer...
(XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
(XEN) Platform periodic timer is osmr0 @ 1000 Hz
(XEN) ### arch_domain create OK
(XEN) ### t->shared[i] = ff308000
(XEN) ### t->shared[i] = ff307000
(XEN) ### t->shared[i] = ff306000
(XEN) ### t->shared[i] = ff305000
(XEN) ### frame_table: ff315000
(XEN) ### virt: ff308000
(XEN)  pg: ff3180c0
(XEN) ### virt: ff307000
(XEN)  pg: ff3180a8
(XEN) ### virt: ff306000
(XEN)  pg: ff318090
(XEN) ### virt: ff305000
(XEN)  pg: ff318078
(XEN) ### arch_domain create OK
(XEN) ***************************** LOADING DOMAIN 0
*****************************
(XEN) Parsing domain #0 (1919876B) at 0xc3e1b478
(XEN) elf_init: not an ELF binary

My build kernel information ：
........
  Building modules, stage 2.
  OBJCOPY xen/arch/arm/boot/Image
  MODPOST
  MV      xen/arch/arm/boot/Image to xen/arch/arm/boot/Image.xen
  CAT     xen/arch/arm/boot/Image.xen vmlinux.dom0 vmlinux.eod zero.eod
vmlinux.domu-rt vmlinux.eod one.eod vmlinux.eod >
xen/arch/arm/boot/Image.tmp
  MV      xen/arch/arm/boot/Image.tmp to xen/arch/arm/boot/Image
  Kernel: xen/arch/arm/boot/Image is ready
  GZIP    xen/arch/arm/boot/compressed/piggy.gz
  AS      xen/arch/arm/boot/compressed/piggy.o
  LD      xen/arch/arm/boot/compressed/vmlinux
  RM      xen/arch/arm/boot/Image
  OBJCOPY xen/arch/arm/boot/zImage
  Kernel: xen/arch/arm/boot/zImage is ready
#################################### uImage
####################################
  CHK     include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
  CHK     include/linux/utsrelease.h
  OBJCOPY xen/arch/arm/boot/Image
  MV      xen/arch/arm/boot/Image to xen/arch/arm/boot/Image.xen
  CAT     xen/arch/arm/boot/Image.xen vmlinux.dom0 vmlinux.eod zero.eod
vmlinux.domu-rt vmlinux.eod one.eod vmlinux.eod >
xen/arch/arm/boot/Image.tmp
  MV      xen/arch/arm/boot/Image.tmp to xen/arch/arm/boot/Image
  Kernel: xen/arch/arm/boot/Image is ready
  GZIP    xen/arch/arm/boot/compressed/piggy.gz
  AS      xen/arch/arm/boot/compressed/piggy.o
  LD      xen/arch/arm/boot/compressed/vmlinux
  RM      xen/arch/arm/boot/Image
  OBJCOPY xen/arch/arm/boot/zImage
  Kernel: xen/arch/arm/boot/zImage is ready
  UIMAGE  xen/arch/arm/boot/uImage
Image Name:   Linux-2.6.18
Created:      Fri May 21 16:38:01 2010
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1764332 Bytes = 1722.98 kB = 1.68 MB
Load Address: 0xA0008000
Entry Point:  0xA0008000
  MV      uImage to uImage.mainstone
  Kernel: xen/arch/arm/boot/uImage.mainstone is ready
######### WARNING Use uImage.mainstone (instead of uImage)

Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[SAMBUC L. <lio...@he...>]

Hello,

First, let me apologize for my last mail, whose formatting was a 
disaster. I am glad it still was helpful.

> -----Original Message-----
> From: Pushparajan V [mailto:vp...@gm...]
> Sent: Tuesday, May 18, 2010 8:25 PM
> To: SAMBUC Lionel
> Cc: emb...@li...
> Subject: Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd
> 
> Hi Lionel,
> 
> Thanks for the guidance.
> 
> Finally I am able to connect to the NFS server from qemu (without
> breaking my head with making the rootfs in flash).
> 
> 
> I reiterated the steps and got the correct configuration for this.
> Since this is first time working with bridge & tap for U-boot, got
> confused with the steps. :)
> 
> As 2 ethernet cards are required, I added one more network adapter in
> the vmware ubuntu (adding new network card costed me just $ 0.. :) )
> 

It seems this is not yet clear, so I will try to explicit this by using an 
analogy.

The bridge is like a hub, which has a number of interfaces (ports), as 
this is all software we can add and remove "ports" (interfaces) on the fly.

Now in /etc/interfaces we define the bridge br0 and attached to it an ip
address (in my configuration 192.168.1.1), while each ports (interfaces)
as no ip identification of it's own. 

A little trick used to ensure that the Ethernet interfaces (our "ports") 
does not filter the traffic as they would usually do and transmit 
everything up the network stack is used. We put them into promiscuous mode. 

This is done in the same file for the second physical card and by qemu 
through the parameters we give it (as we instruct it to use the tap0 
interface and the qemu-ifup and qemu-ifdown scripts). Those two script 
simply add to / remove from the bridge the interface (the "port") 
created by qemu when it starts and quits.

This works because as soon as it is part of the bridge, all the traffic 
sent to / received on the bridge is automatically seen by all its "ports".
 
On the other end of each "ports" there is a second network interface 
(be it the one emulated by qemu, or a real one) which has its own ip 
address.

Then we tell the dhcp server to only listen for request on the bridge 
(and not one of its port) we enables us to add / remove "ports" on the 
fly without having to relaunch the dhcp server, as the bridge (hub) itself 
stays always on.

For the tftp server, there is no such facilities, so it will answer anyone 
who try to load a file from it. As there is only our kernel uImage, it is 
not that much of a threat, but it means other computer can connect and load 
any file visible under the tftp root. It may be possible to increase security
by adding some restriction on  the inet super server.

Now for the NFS server, it will allow the connection to the shares only 
according to the /etc/exports file in which we allow only our private 
network to access to our shares ("exports").
 
> 1. Changed /etc/exports for the local subnet (192.168.198.0) [got -13
> "access denied errors, so gave full permission with asterix) 2. Changed
> /etc/dhcp3/dhcpd.conf 3. Changed /etc/network/interfaces to add new
> bridge interface with new ethernet card eth1 4. Reconfigured
> embeddedxem/.cmdline.h -> It was pointing to hardcoded IP address
> settings.. changed and recompiled

For the rights, a line like the following should be alright:
/opt/boards/filesystem/rootfs-oabi	192.168.198.0/24(rw,no_root_squash,async,no_subtree_check)

As explained before, the bridge do not require to have a real interface 
connected to it, so you may simply delete it and remove the references 
to your eth1 card in /etc/network. QEMU will still work as intended.

> 
> Finally able to see the DOM0 shell. But sometimes getting nfs: RPC call
> returned error 101, which is anyway some configuration issue.
> 

This error is still to be explained, we also have it, usually one time 
every two starts, or something approaching. I have no solution or idea
concerning this minor issue.

> Attached screenshot of it.
> 
> I have one query, From which version of Xen (svn label) embeddedxen is
> cloned from ?
> 

The current EmbeddedXen is based on the official 3.1.3 version of Xen.

> I heard Samsung has done an ARM port of Xen already and didn't upstream
> it and also it is not in sync with latest Xen. Is embeddedxen also
> falls into the same state or it goes in sync with Xen community?
> 
The project is still in alpha stage, so there is no plan to upstream it
at the moment. Now, the project was done while incorporating some of the 
modifications released by Samsung, but we are not related to them. 

We are planning to update the linux kernel used to version 2.6.34 (I am 
personally starting on this) and we may upgrade our Xen version to the 
4.0.0. That last point is not yet defined, as we need to evaluate the 
benefit our internal projects may gain from this move.

We also continue our work on the realtime side, as we still need to do 
some major modifications to the scheduling policy of the hypervisor (Xen)
to be able to ensure the realtime constraints for a domain.

> Really gr8 work done here. I would love to contribute on the front of
> documentation (as much a begineer can do here).
> 
We are welcoming any help, but to answer that last point, it may help 
if you could mail me what are your goals concerning EmbeddedXen. 
We can then discuss what you can contribute to the project.

> 
> --
> Pushparajan V
> http://vprajan.blogspot.com
> 
> 
> 

Regards, 

Lionel Sambuc

Re: [Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[SAMBUC L. <lio...@he...>]

Hello,

On 14 mai 2010, at 20:42, Pushparajan V wrote:

Hi,

I am trying to run embeddedxen on a vmware ubuntu 8.04 installation.


As specified in the getting started, there are some software version which are required, as it seems you are using a virtualization solution, it should not be a major problem to begin with the correct software versions. That would help immensely in getting you up and running in the shortest amount of time.

I followed the steps given inhttp://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted

I configured everything but never get kernel detect the rootfs because of nfs server configuration problem.

If you are hitting some NFS problems, it would be a good thing to check your firewall settings, /etc/hosts.allow, /etc/hosts.deny as well as VMware network settings. The NFS traffic may be filtered by these.

Looks like the addresses are hardcoded (192.168.1.1) and never worked out for me.

It is not, everything is specified in the dhcp config. You may adapt these as you wish, as long as you do it everywhere, i.e. in:
o /etc/network/interfaces
  (the bridge has to be on the correct network)
o /etc/exports
  (obviously, you have to let the correct network access your shares)
o /etc/dhcp3/dhcpd.conf
  (The settings for the network, default gateway, IP address and all are there.)

Is there anyway that i can configure dom0 to boot from ramfs ?


It may be possible, but complicated. As of now, we never used that option as we are booting an image which is not standard at all, as explained in the technical report. It seems to me it is much simpler to follow the setup, as it is also much more flexible.

For any further help, I would require the full log.

Regards

Lionel Sambuc

--
Pushparajan V
http://vprajan.blogspot.com<http://vprajan.blogspot.com/>



<ATT00001..txt><ATT00002..txt>

[Embeddedxen-devel] embeddedxen Dom0 boot from initrd

[Pushparajan V <vp...@gm...>]

Hi,

I am trying to run embeddedxen on a vmware ubuntu 8.04 installation.

I followed the steps given in
http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted

I configured everything but never get kernel detect the rootfs because of
nfs server configuration problem.

Looks like the addresses are hardcoded (192.168.1.1) and never worked out
for me.

Is there anyway that i can configure dom0 to boot from ramfs ?

-- 
Pushparajan V
http://vprajan.blogspot.com

Re: [Embeddedxen-devel] RE : [XenARM] Re:xen-pxa270-qemu

[SAMBUC L. <lio...@he...>]

Hello,

The short answer to your questions:

1.a You do not navigate between domains, domU-RT as no input facility such as a 
    console.
1.b You do not create on-the-fly domains, this a is not a foreseen feature.

2. The Xen utilities have not yet been ported, as they need the xenbus 
   infrastructure to run, which is not yet functional (which implies 1.b).

The long answer:

EmbeddedXen is a work-in-progress, We have already come a long way to be able
to run two domains concurrently. Now, the project objectives are as follow:
 * Having two (2) domains on an embedded platform whose roles are:
   o A real-time domain, which is responsible for motor control and the like.
   o A Linux non-RT domain whose job is to run some kind of device interface,
     be it a GUI on a touch screen, a web server, etc...
 * The RT domain registers the drivers it needs to control the peripheral it 
   uses in order to check the system status and modify it. It also communicates
   only with the domain 0 to retrieve any modification in settings and the like.

This means the Dom0 (non-RT) domain is responsible to do all the parameter checking, 
control the rights for any modification of the settings and / or the validity of the 
given settings, while the RT domain only focuses on the system regulation. This allow  
a clear cut between roles and responsibilities, which then simplify the critical code 
(DomU-RT).

The current status of the project is the following:
 o Xen has been partially been ported to the ARM platform, for example we are still 
   missing some feature such as:
    * Memory page granting.
    * The inter-domain channels are completely untested.
    * Live creation of a domain is untested and __is not planned__.
    * Xenbus & XenStore
 o The current Dom0 rootfs does not come with the XEN utilities to manage 
   domains, we are yet to port them and then test them.
 o The DomU system is a bare Xenomai nucleus, with only the needed services from 
   Linux on which it relies to run. This means:
    * No driver are loaded, besides the timer.
    * No network!
    * No Linux scheduler!

Regards, 

Lionel

> -----Original Message-----
> From: sreenaath vasudevan [mailto:sre...@gm...]
> Sent: mardi 27 avril 2010 02:25
> To: SAMBUC Lionel
> Cc: emb...@li...
> Subject: Re: RE : [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 
> Hi Lionel
> Thanks for the pointer on qemu version issue.
> I am now using qemu-0.9.1 and I am ale to get to dom0 login.  The system is
> booting :)
> Thanks a lot for helping me out to get to this stage.
> 
> I ve some query on getting in to domU.
> 
> 1. In general, while using xen in a desktop environment, we use xen-tools
> to create new guest domains right and then we login in to that particular
> IP to login to that guest domain.
> In this case, with embeddedxen, we have the image of both dom0 and domU
> embedded in to this bootable image. Then how do I get to domU? How do I
> navigate between dom0 and domU ?
> 
> 2. Also I am not able to use standard xen commands in DOM0 ?
> 
> Note:
> For building the image, I used this command "./build-embeddedxen -u -0 -x"
> 
> 
> On Sun, Apr 25, 2010 at 10:28 PM, SAMBUC Lionel <lio...@he...>
> wrote:
> 
> 
> 	Hello,
> 
> 	I have been able to reproduce your issue with QEMU-0.10.5.
> 	This is a driver / QEMU emulation issue which was introduced between
> 	QEMU 0.9.1 and QEMU 0.10.5.
> 
> 	I have no fix at the moment, so meanwhile please stick to the 0.9.1
> 	revision.
> 
> 	Regards,
> 
> 	Lionel
> 
> 
> 	> -----Original Message-----
> 	> From: sreenaath vasudevan [mailto:sre...@gm...]
> 
> 	> Sent: samedi 24 avril 2010 21:49
> 	> To: SAMBUC Lionel
> 	> Cc: emb...@li...
> 
> 	> Subject: Re: RE : [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 	>
> 	> Hi Lionel
> 	> Thanks for the quick response.
> 	> I ve installed elfutils and I could see that the WARNING regarding
> "eu-
> 	> strip missing" while building the image is gone. However I get the
> 	> following two warning.
> 	> WARNING: "HYPERVISOR_shared_info" [drivers/video/backlight/lcd.ko]
> 	> undefined!
> 	> WARNING: "HYPERVISOR_shared_info"
> [drivers/video/backlight/backlight.ko]
> 	> undefined!
> 	>
> 	> Not sure If the problem I mentioned below is because of these
> warnings
> 	>
> 	> This is the way I built and  ran the image
> 	> building the image -> ./build-embeddedxen -u -0 -x
> 	>
> 	> running the image -> sudo qemu-system-arm -localtime -M mainstone -
> kernel
> 	> ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -
> pflash
> 	> ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -
> serial stdio
> 	>
> 	> However while running the image, I get "aborted" the following
> error
> 	> appears(I am pasting only the last few lines. I am attaching the
> build and
> 	> output log with this post.)
> 	>
> 	> last few lines of output while running the built image
> 	> -------------------------------------------------------------------
> --------
> 	> ----------------------------------------------------------
> 	> [DOM0] IP route cache hash table entries: 128 (order: -3, 512
> bytes)
> 	> [DOM0] TCP established hash table entries: 512 (order: -1, 2048
> bytes)
> 	> [DOM0] TCP bind hash table entries: 256 (order: -2, 1024 bytes)
> 	> [DOM0] <6>TCP: Hash tables configured (established 512 bind 256)
> 	> [DOM0] <6>TCP reno registered
> 	> [DOM0] <4>NetWinder Floating Point Emulator V0.97 (extended
> precision)
> 	> [DOM0] <6>JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> 	> [DOM0] <6>Initializing Cryptographic API
> 	> [DOM0] <6>io scheduler noop registered
> 	> [DOM0] <6>io scheduler anticipatory registered
> 	> [DOM0] <6>io scheduler deadline registered
> 	> [DOM0] <6>io scheduler cfq registered (default)
> 	> [DOM0] Event-channel device installed.
> 	> [DOM0] Xen virtual console successfully installed as ttyS0
> 	> qemu: fatal: smc91c111_read: Bad reg 0:30e
> 	>
> 	> R00=c1850300 R01=00000001 R02=00000000 R03=00007ff0
> 	> R04=c0c3a800 R05=c024a19c R06=c1850300 R07=00000000
> 	> R08=c024a194 R09=00000000 R10=c024a674 R11=c0351ebc
> 	> R12=c0351e24 R13=c0351e70 R14=c0130cfc R15=c016ac90
> 	> PSR=a0000010 N-C- A usr32
> 	> Aborted
> 	>
> 	> -------------------------------------------------------------------
> --------
> 	> ----------------------------------------------------------
> 	>
> 	>
> 	> On Sat, Apr 24, 2010 at 6:28 AM, SAMBUC Lionel <lionel.sambuc@heig-
> vd.ch>
> 	> wrote:
> 	>
> 	>
> 	>       Hello,
> 	>
> 	>       from your attched output log, the eu-strip tool is not
> installed on
> 	> your system.
> 	>       It is found in the elfutils package. I will update the wiki
> and add
> 	> this package in
> 	>       the requirement list, as well as the bridge utils.
> 	>
> 	>       Otherwise, both domains are compiled alright. As the final
> image is
> 	> made from
> 	>       the stripped versions of the images files and as they are not
> 	> created, they are
> 	>       not included. There is no error reported during the creation
> of the
> 	> final image
> 	>       as this is possible to include only one domain (be it either
> domU or
> 	> dom0).
> 	>
> 	>       With that last package, you should have an embeddedxen up and
> 	> running.
> 	>
> 	>       Thank you for your feedback, it has helped a lot in the
> creation of a
> 	> complete
> 	>       step by step guide.
> 	>
> 	>       As usual, if any question arise, just let us know!
> 	>
> 	>       Regards,
> 	>
> 	>       Lionel
> 	>       ________________________________________
> 	>       De : sreenaath vasudevan [sre...@gm...]
> 	>       Date d'envoi : vendredi, 23. avril 2010 21:14
> 	>       À : ROSSIER Daniel
> 	>       Cc : emb...@li...
> 	>       Objet : Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 	>
> 	>
> 	>       Hi
> 	>       Yes I think dom0 is missing. This is how I got the code and
> how I
> 	> built it
> 	>
> 	>
> 	>       1. git clone
> 	>
> git://embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen<http:
> 	> //embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen>
> 	>
> 	>
> 	>       2. cd embeddedxen
> 	>
> 	>       3. ./build-embeddedxen -u -0 -x
> 	>
> 	>       The output in the command line after firing the build-
> embeddedxen
> 	> command, the last few line of the output I am giving below. Also I
> am
> 	> attaching the full output of the build-embeddedxen command.
> 	>
> 	>       4. untarred rootfs like sudo tar -jxf rootfs.tar.bz2
> 	>        @ /opt/boards/filesystem/rootfs-
> 	>       oabi.
> 	>
> 	>       After this made changes to config files as told in wiki
> 	>
> 	>       Then ran QEMU like this
> 	>       user@localhost > sudo qemu-system-arm -localtime -M mainstone
> -kernel
> 	> xen/arch/arm/boot/uImage.mainstone -pflash ./flash1 -pflash
> ./flash2 -s -m
> 	> 256 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial
> vc:1000x500
> 	>
> 	>       On doing this I got the panic as reported in my previous
> post. Please
> 	> do let me know if theres anything wrong wiht the build-embeddexen
> command
> 	> or anything is wrong from the output.
> 	>
> 	>
> 	>       --
> 	>       regards
> 	>       sreenaath
> 	>
> 	>
> 	>
> 	>
> 	>
> 	> --
> 	> regards
> 	> sreenaath
> 
> 
> 
> 
> 
> 
> --
> regards
> sreenaath

Re: [Embeddedxen-devel] RE : [XenARM] Re:xen-pxa270-qemu

[sreenaath v. <sre...@gm...>]

Hi Lionel
Thanks for the pointer on qemu version issue.
I am now using qemu-0.9.1 and I am ale to get to dom0 login.  The system is
booting :)
Thanks a lot for helping me out to get to this stage.

I ve some query on getting in to domU.

1. In general, while using xen in a desktop environment, we use xen-tools to
create new guest domains right and then we login in to that particular IP to
login to that guest domain.
In this case, with embeddedxen, we have the image of both dom0 and domU
embedded in to this bootable image. Then how do I get to domU? How do I
navigate between dom0 and domU ?

2. Also I am not able to use standard xen commands in DOM0 ?

Note:
For building the image, I used this command "./build-embeddedxen -u -0 -x"


On Sun, Apr 25, 2010 at 10:28 PM, SAMBUC Lionel <lio...@he...>wrote:

> Hello,
>
> I have been able to reproduce your issue with QEMU-0.10.5.
> This is a driver / QEMU emulation issue which was introduced between
> QEMU 0.9.1 and QEMU 0.10.5.
>
> I have no fix at the moment, so meanwhile please stick to the 0.9.1
> revision.
>
> Regards,
>
> Lionel
>
> > -----Original Message-----
> > From: sreenaath vasudevan [mailto:sre...@gm...]
> > Sent: samedi 24 avril 2010 21:49
> > To: SAMBUC Lionel
> > Cc: emb...@li...
> > Subject: Re: RE : [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> >
> > Hi Lionel
> > Thanks for the quick response.
> > I ve installed elfutils and I could see that the WARNING regarding "eu-
> > strip missing" while building the image is gone. However I get the
> > following two warning.
> > WARNING: "HYPERVISOR_shared_info" [drivers/video/backlight/lcd.ko]
> > undefined!
> > WARNING: "HYPERVISOR_shared_info" [drivers/video/backlight/backlight.ko]
> > undefined!
> >
> > Not sure If the problem I mentioned below is because of these warnings
> >
> > This is the way I built and  ran the image
> > building the image -> ./build-embeddedxen -u -0 -x
> >
> > running the image -> sudo qemu-system-arm -localtime -M mainstone -kernel
> > ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -pflash
> > ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial
> stdio
> >
> > However while running the image, I get "aborted" the following error
> > appears(I am pasting only the last few lines. I am attaching the build
> and
> > output log with this post.)
> >
> > last few lines of output while running the built image
> >
> ---------------------------------------------------------------------------
> > ----------------------------------------------------------
> > [DOM0] IP route cache hash table entries: 128 (order: -3, 512 bytes)
> > [DOM0] TCP established hash table entries: 512 (order: -1, 2048 bytes)
> > [DOM0] TCP bind hash table entries: 256 (order: -2, 1024 bytes)
> > [DOM0] <6>TCP: Hash tables configured (established 512 bind 256)
> > [DOM0] <6>TCP reno registered
> > [DOM0] <4>NetWinder Floating Point Emulator V0.97 (extended precision)
> > [DOM0] <6>JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> > [DOM0] <6>Initializing Cryptographic API
> > [DOM0] <6>io scheduler noop registered
> > [DOM0] <6>io scheduler anticipatory registered
> > [DOM0] <6>io scheduler deadline registered
> > [DOM0] <6>io scheduler cfq registered (default)
> > [DOM0] Event-channel device installed.
> > [DOM0] Xen virtual console successfully installed as ttyS0
> > qemu: fatal: smc91c111_read: Bad reg 0:30e
> >
> > R00=c1850300 R01=00000001 R02=00000000 R03=00007ff0
> > R04=c0c3a800 R05=c024a19c R06=c1850300 R07=00000000
> > R08=c024a194 R09=00000000 R10=c024a674 R11=c0351ebc
> > R12=c0351e24 R13=c0351e70 R14=c0130cfc R15=c016ac90
> > PSR=a0000010 N-C- A usr32
> > Aborted
> >
> >
> ---------------------------------------------------------------------------
> > ----------------------------------------------------------
> >
> >
> > On Sat, Apr 24, 2010 at 6:28 AM, SAMBUC Lionel <lio...@he...
> >
> > wrote:
> >
> >
> >       Hello,
> >
> >       from your attched output log, the eu-strip tool is not installed on
> > your system.
> >       It is found in the elfutils package. I will update the wiki and add
> > this package in
> >       the requirement list, as well as the bridge utils.
> >
> >       Otherwise, both domains are compiled alright. As the final image is
> > made from
> >       the stripped versions of the images files and as they are not
> > created, they are
> >       not included. There is no error reported during the creation of the
> > final image
> >       as this is possible to include only one domain (be it either domU
> or
> > dom0).
> >
> >       With that last package, you should have an embeddedxen up and
> > running.
> >
> >       Thank you for your feedback, it has helped a lot in the creation of
> a
> > complete
> >       step by step guide.
> >
> >       As usual, if any question arise, just let us know!
> >
> >       Regards,
> >
> >       Lionel
> >       ________________________________________
> >       De : sreenaath vasudevan [sre...@gm...]
> >       Date d'envoi : vendredi, 23. avril 2010 21:14
> >       À : ROSSIER Daniel
> >       Cc : emb...@li...
> >       Objet : Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> >
> >
> >       Hi
> >       Yes I think dom0 is missing. This is how I got the code and how I
> > built it
> >
> >
> >       1. git clone
> > git://embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen
> <http:
> > //embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen>
> >
> >
> >       2. cd embeddedxen
> >
> >       3. ./build-embeddedxen -u -0 -x
> >
> >       The output in the command line after firing the build-embeddedxen
> > command, the last few line of the output I am giving below. Also I am
> > attaching the full output of the build-embeddedxen command.
> >
> >       4. untarred rootfs like sudo tar -jxf rootfs.tar.bz2
> >        @ /opt/boards/filesystem/rootfs-
> >       oabi.
> >
> >       After this made changes to config files as told in wiki
> >
> >       Then ran QEMU like this
> >       user@localhost > sudo qemu-system-arm -localtime -M mainstone
> -kernel
> > xen/arch/arm/boot/uImage.mainstone -pflash ./flash1 -pflash ./flash2 -s
> -m
> > 256 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial
> vc:1000x500
> >
> >       On doing this I got the panic as reported in my previous post.
> Please
> > do let me know if theres anything wrong wiht the build-embeddexen command
> > or anything is wrong from the output.
> >
> >
> >       --
> >       regards
> >       sreenaath
> >
> >
> >
> >
> >
> > --
> > regards
> > sreenaath
>
>


-- 
regards
sreenaath

Re: [Embeddedxen-devel] RE : [XenARM] Re:xen-pxa270-qemu

[SAMBUC L. <lio...@he...>]

Hello,

I have been able to reproduce your issue with QEMU-0.10.5. 
This is a driver / QEMU emulation issue which was introduced between 
QEMU 0.9.1 and QEMU 0.10.5.

I have no fix at the moment, so meanwhile please stick to the 0.9.1
revision.

Regards,

Lionel

> -----Original Message-----
> From: sreenaath vasudevan [mailto:sre...@gm...]
> Sent: samedi 24 avril 2010 21:49
> To: SAMBUC Lionel
> Cc: emb...@li...
> Subject: Re: RE : [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 
> Hi Lionel
> Thanks for the quick response.
> I ve installed elfutils and I could see that the WARNING regarding "eu-
> strip missing" while building the image is gone. However I get the
> following two warning.
> WARNING: "HYPERVISOR_shared_info" [drivers/video/backlight/lcd.ko]
> undefined!
> WARNING: "HYPERVISOR_shared_info" [drivers/video/backlight/backlight.ko]
> undefined!
> 
> Not sure If the problem I mentioned below is because of these warnings
> 
> This is the way I built and  ran the image
> building the image -> ./build-embeddedxen -u -0 -x
> 
> running the image -> sudo qemu-system-arm -localtime -M mainstone -kernel
> ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -pflash
> ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial stdio
> 
> However while running the image, I get "aborted" the following error
> appears(I am pasting only the last few lines. I am attaching the build and
> output log with this post.)
> 
> last few lines of output while running the built image
> ---------------------------------------------------------------------------
> ----------------------------------------------------------
> [DOM0] IP route cache hash table entries: 128 (order: -3, 512 bytes)
> [DOM0] TCP established hash table entries: 512 (order: -1, 2048 bytes)
> [DOM0] TCP bind hash table entries: 256 (order: -2, 1024 bytes)
> [DOM0] <6>TCP: Hash tables configured (established 512 bind 256)
> [DOM0] <6>TCP reno registered
> [DOM0] <4>NetWinder Floating Point Emulator V0.97 (extended precision)
> [DOM0] <6>JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc.
> [DOM0] <6>Initializing Cryptographic API
> [DOM0] <6>io scheduler noop registered
> [DOM0] <6>io scheduler anticipatory registered
> [DOM0] <6>io scheduler deadline registered
> [DOM0] <6>io scheduler cfq registered (default)
> [DOM0] Event-channel device installed.
> [DOM0] Xen virtual console successfully installed as ttyS0
> qemu: fatal: smc91c111_read: Bad reg 0:30e
> 
> R00=c1850300 R01=00000001 R02=00000000 R03=00007ff0
> R04=c0c3a800 R05=c024a19c R06=c1850300 R07=00000000
> R08=c024a194 R09=00000000 R10=c024a674 R11=c0351ebc
> R12=c0351e24 R13=c0351e70 R14=c0130cfc R15=c016ac90
> PSR=a0000010 N-C- A usr32
> Aborted
> 
> ---------------------------------------------------------------------------
> ----------------------------------------------------------
> 
> 
> On Sat, Apr 24, 2010 at 6:28 AM, SAMBUC Lionel <lio...@he...>
> wrote:
> 
> 
> 	Hello,
> 
> 	from your attched output log, the eu-strip tool is not installed on
> your system.
> 	It is found in the elfutils package. I will update the wiki and add
> this package in
> 	the requirement list, as well as the bridge utils.
> 
> 	Otherwise, both domains are compiled alright. As the final image is
> made from
> 	the stripped versions of the images files and as they are not
> created, they are
> 	not included. There is no error reported during the creation of the
> final image
> 	as this is possible to include only one domain (be it either domU or
> dom0).
> 
> 	With that last package, you should have an embeddedxen up and
> running.
> 
> 	Thank you for your feedback, it has helped a lot in the creation of a
> complete
> 	step by step guide.
> 
> 	As usual, if any question arise, just let us know!
> 
> 	Regards,
> 
> 	Lionel
> 	________________________________________
> 	De : sreenaath vasudevan [sre...@gm...]
> 	Date d'envoi : vendredi, 23. avril 2010 21:14
> 	À : ROSSIER Daniel
> 	Cc : emb...@li...
> 	Objet : Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 
> 
> 	Hi
> 	Yes I think dom0 is missing. This is how I got the code and how I
> built it
> 
> 
> 	1. git clone
> git://embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen<http:
> //embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen>
> 
> 
> 	2. cd embeddedxen
> 
> 	3. ./build-embeddedxen -u -0 -x
> 
> 	The output in the command line after firing the build-embeddedxen
> command, the last few line of the output I am giving below. Also I am
> attaching the full output of the build-embeddedxen command.
> 
> 	4. untarred rootfs like sudo tar -jxf rootfs.tar.bz2
> 	 @ /opt/boards/filesystem/rootfs-
> 	oabi.
> 
> 	After this made changes to config files as told in wiki
> 
> 	Then ran QEMU like this
> 	user@localhost > sudo qemu-system-arm -localtime -M mainstone -kernel
> xen/arch/arm/boot/uImage.mainstone -pflash ./flash1 -pflash ./flash2 -s -m
> 256 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial vc:1000x500
> 
> 	On doing this I got the panic as reported in my previous post. Please
> do let me know if theres anything wrong wiht the build-embeddexen command
> or anything is wrong from the output.
> 
> 
> 	--
> 	regards
> 	sreenaath
> 
> 
> 
> 
> 
> --
> regards
> sreenaath

[Embeddedxen-devel] RE : [XenARM] Re:xen-pxa270-qemu

[SAMBUC L. <lio...@he...>]

Hello,

from your attched output log, the eu-strip tool is not installed on your system.
It is found in the elfutils package. I will update the wiki and add this package in 
the requirement list, as well as the bridge utils.

Otherwise, both domains are compiled alright. As the final image is made from 
the stripped versions of the images files and as they are not created, they are 
not included. There is no error reported during the creation of the final image 
as this is possible to include only one domain (be it either domU or dom0).

With that last package, you should have an embeddedxen up and running.

Thank you for your feedback, it has helped a lot in the creation of a complete 
step by step guide.

As usual, if any question arise, just let us know!

Regards, 

Lionel
________________________________________
De : sreenaath vasudevan [sre...@gm...]
Date d'envoi : vendredi, 23. avril 2010 21:14
À : ROSSIER Daniel
Cc : emb...@li...
Objet : Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

Hi
Yes I think dom0 is missing. This is how I got the code and how I built it

1. git clone git://embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen<http://embeddedxen.git.sourceforge.net/gitroot/embeddedxen/embeddedxen>

2. cd embeddedxen

3. ./build-embeddedxen -u -0 -x

The output in the command line after firing the build-embeddedxen command, the last few line of the output I am giving below. Also I am attaching the full output of the build-embeddedxen command.

4. untarred rootfs like sudo tar -jxf rootfs.tar.bz2
 @ /opt/boards/filesystem/rootfs-
oabi.

After this made changes to config files as told in wiki

Then ran QEMU like this
user@localhost > sudo qemu-system-arm -localtime -M mainstone -kernel xen/arch/arm/boot/uImage.mainstone -pflash ./flash1 -pflash ./flash2 -s -m 256 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial vc:1000x500

On doing this I got the panic as reported in my previous post. Please do let me know if theres anything wrong wiht the build-embeddexen command or anything is wrong from the output.

--
regards
sreenaath

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[sreenaath v. <sre...@gm...>]

Hi
I got your point.
I made a mistake by adding the "brctl addbr $BRIDGE" command to the
qemu-ifup script. Initially when I just followed the wiki and had the
original qemu-ifup script given in the wiki, it threw me error as 'br0' was
not added. Hence I added the command in qemu-ifup script, which I should not
have done and rather fired it from command line for the first time alone.
Regarding how I build the image, I ll post my reply in the next post.
Thanks :)

On Fri, Apr 23, 2010 at 9:53 AM, SAMBUC Lionel <lio...@he...>wrote:

> Hello,
>
> > -----Original Message-----
> > From: sreenaath vasudevan [mailto:sre...@gm...]
> > Sent: vendredi 23 avril 2010 04:14
> > To: emb...@li...
> > Subject: Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> >
> ...
> >
> >       3. Also I changed the /etc/wemu-ifup script as follows (added two
> > more lines to what is givien in the wiki for adding the bridge being
> > linking it with the tap0 interface.)
> >              /etc/qemu-ifup
> >
> >              #!/bin/sh
> >              BRIDGE=br0
> >             #setup in promiscuous mode qemu's device
> >             echo ifconfig $1 0.0.0.0 promisc up
> >             ifconfig $1 0.0.0.0 promisc up
> >             echo brctl addbr $BRIDGE
> >             brctl addbr $BRIDGE
> >             #add it to the bridge
> >             echo brctl addif $BRIDGE $1
> >             brctl addif $BRIDGE $1
> >
>
> While not being a show stopper, your qemu-ifup script seems wrong, please
> take the one from the GettingStarted guide. Based on your email, I also
> updated the guide this morning as some steps where incomplete.
>
> For reference, the complete script:
>
>  #!/bin/sh
>
>  BRIDGE=br0
>
>  #setup in promiscuous mode qemu's device
>  echo ifconfig $1 0.0.0.0 promisc up
>  ifconfig $1 0.0.0.0 promisc up
>  #add it to the bridge
>  echo brctl addif $BRIDGE $1
>  brctl addif $BRIDGE $1
>
> The bridge device is created once (normally in /etc/network/interfaces) and
> then only modified with regards to the linked interfaces (brctl addif and
> brctl delif commands). This is also why we can see complaints about trying
> to create a bridge interface which already exists.
>
> > ---------------------------------------------------------------------
> >       user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M
> > mainstone -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash
> > ./flash1 -pflash ./flash2 -net nic -net
> tap,ifname=tap0,script=/etc/qemu-ifup
> >       ifconfig tap0 0.0.0.0 promisc up
> >       brctl addbr br0
> >       device br0 already exists; can't create bridge with the same name
>
> This error comes from your "brctl addbr $BRIDGE" command.
>
> >       brctl addif br0 tap0
> >       map addr 0x82200a0
> ...
> >
> > --
> > regards
> > sreenaath
>
> Have a nice day,
>
> Lionel
>



-- 
regards
sreenaath

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[ROSSIER D. <Dan...@he...>]

oups, just realized one thing: please use the last version from the git repository (just follow the instructions from the
GettingStarted wiki page); the .tar.gz which is available from "download" button is outdated; we will update it very soon.

Daniel

From: sreenaath vasudevan [mailto:sre...@gm...]
Sent: vendredi 23 avril 2010 04:14
To: emb...@li...
Subject: Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

The panic is happening in the file hypervisor/setup.c and not in hypervisor.c as i told in my previous post.
Sorry for the confusion.
On Thu, Apr 22, 2010 at 10:11 PM, sreenaath vasudevan <sre...@gm...<mailto:sre...@gm...>> wrote:
Hi
Thanks for the detailed info given in the wiki http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted.

I am running in to a panic issue (panic at hypervisor.c) when trying to get the system up and running (as  given in the wiki), which prevents xen from booting.
This is what I have done.
1. I have a virtual machine having ubuntu-9.10 where I followed and installed the packages as given in the wiki.
2. In addition to that, I did install the following packages, brctl, uml-utilities (for 'tunctl') and uboot-mkimage as they were not there in my ubuntu-9.10 VM.
3. Also I changed the /etc/wemu-ifup script as follows (added two more lines to what is givien in the wiki for adding the bridge being linking it with the tap0 interface.)
       /etc/qemu-ifup

       #!/bin/sh
       BRIDGE=br0
      #setup in promiscuous mode qemu's device
      echo ifconfig $1 0.0.0.0 promisc up
      ifconfig $1 0.0.0.0 promisc up
      echo brctl addbr $BRIDGE
      brctl addbr $BRIDGE
      #add it to the bridge
      echo brctl addif $BRIDGE $1
      brctl addif $BRIDGE $1

4. After that I created two dummy flash files 'flash1' and 'flash2' of sixe 32 MB as follows
 $> sudo dd if=/dev/zero of=./flash2 bs=32000000 count=1

5. Then I ran 'qemu' and got the panic at 'hypervisor.c' which I am giving below. It would be great if you could let me know how to fix it and get it running.

------------------------------------------------------------------------------------------------------------------------------------------
user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup
ifconfig tap0 0.0.0.0 promisc up
brctl addbr br0
device br0 already exists; can't create bridge with the same name
brctl addif br0 tap0
map addr 0x82200a0
root@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial stdio
ifconfig tap0 0.0.0.0 promisc up
brctl addbr br0
device br0 already exists; can't create bridge with the same name
brctl addif br0 tap0
map addr 0x82200a0
Uncompressing Xen................................... done, booting the kernel.
 __  __            _____  _   _____              _ _ _          _
 \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
  \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
  /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
 /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|

 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory

 Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14 CET 2009
 EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System (REDS) Institute from HEIG-VD/Switzerland
 http://reds.heig-vd.ch

 Latest ChangeSet: unavailable

(XEN) Hypervisor area start at: 0xff000000 (virt)
(XEN) Physical RAM map:
(XEN)   00000000a0000000: 0000000004000000
(XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
(XEN) End of Xen Area: 2561MiB (2622464KiB)
(XEN) End of RAM: 0xa3f00000
(XEN) Boot allocator @ a0100000 - a0115000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-00000000a3f00000
(XEN) xenheap: 00000000a0115000 - 00000000a0314fff
(XEN) xenheap(virt): ff115000 - ff314fff
(XEN) ### frametable: ff315000
(XEN) ### min_page: a0100
(XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000 maddr_to_page(ps)=ff3151f8
(XEN) Xen heap: 2MiB (2048kiB)
(XEN) ### first_valid_mfn = a0315
(XEN) ### max_page = a3f00
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Dom Heap: 15230 pages
(XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
(XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init(): alloc_xenheap_page
(XEN) Mapping I/O on mainstone...
(XEN) Init IRQ...
(XEN) Initing arch-IRQ...
(XEN) Init scheduler...
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) Initializing timer...
(XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
(XEN) Platform periodic timer is osmr0 @ 1000 Hz
(XEN) ### arch_domain create OK
(XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
(XEN) CPU: 0
(XEN) PC is at ff00eea8
(XEN) LR is at ff030ab0
(XEN) pc : [<ff00eea8>]    lr : [<ff030ab0>]
(XEN) sp : ff03ff40  ip : ff03ffb4  fp : ff03ffb0
(XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
(XEN) r7 : ff052454  r6 : 00000000  r5 : ff0364b3  r4 : 000001d0
(XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059073
(XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
(XEN) Control: 7977  Table: A0004000  DAC: 000000DF
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
(XEN) CPU: 0
(XEN) PC is at ff00eea8
(XEN) LR is at ff030a0c
(XEN) pc : [<ff00eea8>]    lr : [<ff030a0c>]
(XEN) sp : ff03ff14  ip : ff03ff88  fp : ff03ff84
(XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
(XEN) r7 : ff052454  r6 : 00000000  r5 : 60000153  r4 : ff030ac0
(XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059071
(XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
(XEN) Control: 7977  Table: A0004000  DAC: 000000DF
(XEN) [<ff00eeec>] (+0xff00eeec/0xff03a000) from [<ff030a1c>] (+0xff030a1c/0xff03a000)
(XEN) [<ff030980>] (+0xff030980/0xff03a000) from [<ff030ac0>] (+0xff030ac0/0xff03a000)
(XEN)  r3 = 00000000  r2 = 000001D0  r1 = FF0364B3  r0 = FF039970
(XEN)  r5 = FF0364B3  r4 = 000001D0
(XEN) [<ff030a84>] (+0xff030a84/0xff03a000) from [<ff008e58>] (+0xff008e58/0xff00acc8)
(XEN)  r5 = FF05264C  r4 = 00000000
(XEN) [<ff0089b4>] (+0xff0089b4/0xff00acc8) from [<a0008028>] (???)
(XEN) machine_halt called: spinning....
------------------------------------------------------------------------------------------------------------------------------------------
Thanks :)

On Thu, Apr 22, 2010 at 12:56 AM, SAMBUC Lionel <lio...@he...<mailto:lio...@he...>> wrote:
Hi,

Sorry for the delay, I will put online a short step by step procedure to compile and
start EmbeddedXen, as well as a FAQ, starting with your questions.
This will be available on the SourceForge web page of the project, I intend to have it
online by the end of the day (17h00 GMT, 22nd April 2010).

The web page is located at http://embeddedxen.sourceforge.net/, this is where
you will find the most up to date information.

Please continue to post any other question on this mailing list.

Have a nice day,

Lionel

From: xen...@li...<mailto:xen...@li...> [mailto:xen...@li...<mailto:xen...@li...>] On Behalf Of sreenaath vasudevan
Sent: mercredi 21 avril 2010 04:50
To: xe...@li...<mailto:xe...@li...>
Subject: [XenARM] Re:xen-pxa270-qemu

 Hi
I tried to run xen-arm on pxa270 emulated on qemu by following this link
http://lists.xensource.com/archives/html/xen-arm/2009-04/msg00001.html
I am not able to get in to dom0 console at all.

This is what I ve done
1. I installed the cross compiler arm-unknown-linux-gnuabi-gcc. The Linux distro I use is Ubuntu 9.10.

2. I installed the qemu that came default with ubuntu 9.10 linux.

3. The I installed xen-pxa270-qemu from https://sourceforge.net/projects/embeddedxen.

4. To compile and run it, this is what I did
    a) I untarred the tarball and did a 'make all' inside the 'xen-pxa270-qemu' folder. Before firing the make command, I set the CROSS_COMPILE env variable to point to the cross compiler 'arm-unknown-linux-gnuabi-gcc'.

    b) Then after successful completion of make command, I followed the instructions in http://lists.xensource.com/archives/html/xen-arm/2009-05/msg00000.html

    c) When I run it in non-graphical mode with -nographic option in qemu-system-arm, the console outputs that xen image is getting loaded and linux image is getting loaded in dom0. After that nothing happens. I am not able to enter anything in the command console as it only displays 'Hit Ctrl 'A'  three times to enter in to xen mode'. When I hit Ctrl + 'A' three time it displays 'Hit Ctrl 'A'  three times to enter in to dom0'

   d) When I ran it, in Graphical mode I saw a black screen popping up and in the command window I see the message "map addr 0x8297e80". After that nothing happens. I am not able to see anything in the graphical screen too.


It would be extremely helpful if someone can tell me how to get in to dom0 console.


--
regards
sreenaath


--
regards
sreenaath



--
regards
sreenaath

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[SAMBUC L. <lio...@he...>]

Hello,

> -----Original Message-----
> From: sreenaath vasudevan [mailto:sre...@gm...]
> Sent: vendredi 23 avril 2010 04:14
> To: emb...@li...
> Subject: Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 
... 
> 
> 	3. Also I changed the /etc/wemu-ifup script as follows (added two
> more lines to what is givien in the wiki for adding the bridge being
> linking it with the tap0 interface.)
> 	       /etc/qemu-ifup
> 
> 	       #!/bin/sh
> 	       BRIDGE=br0
> 	      #setup in promiscuous mode qemu's device
> 	      echo ifconfig $1 0.0.0.0 promisc up
> 	      ifconfig $1 0.0.0.0 promisc up
> 	      echo brctl addbr $BRIDGE
> 	      brctl addbr $BRIDGE
> 	      #add it to the bridge
> 	      echo brctl addif $BRIDGE $1
> 	      brctl addif $BRIDGE $1
> 

While not being a show stopper, your qemu-ifup script seems wrong, please take the one from the GettingStarted guide. Based on your email, I also updated the guide this morning as some steps where incomplete. 

For reference, the complete script:

 #!/bin/sh 
 
 BRIDGE=br0
 
 #setup in promiscuous mode qemu's device
 echo ifconfig $1 0.0.0.0 promisc up
 ifconfig $1 0.0.0.0 promisc up
 #add it to the bridge
 echo brctl addif $BRIDGE $1
 brctl addif $BRIDGE $1

The bridge device is created once (normally in /etc/network/interfaces) and then only modified with regards to the linked interfaces (brctl addif and brctl delif commands). This is also why we can see complaints about trying to create a bridge interface which already exists.

> ---------------------------------------------------------------------
> 	user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M
> mainstone -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash
> ./flash1 -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup
> 	ifconfig tap0 0.0.0.0 promisc up
> 	brctl addbr br0
> 	device br0 already exists; can't create bridge with the same name

This error comes from your "brctl addbr $BRIDGE" command.

> 	brctl addif br0 tap0
> 	map addr 0x82200a0
...
> 
> --
> regards
> sreenaath

Have a nice day,

Lionel

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[ROSSIER D. <Dan...@he...>]

Apparently, you have no dom0 image in the kernel image. How did you build your image?
Normally, you must use the build-embeddedxen with appropriate option (build-embeddedxen -? for getting all options)

Maybe, could you send us the result of the build-embeddedxen command?

Cheers
Daniel


> -----Original Message-----
> From: sreenaath vasudevan [mailto:sre...@gm...]
> Sent: vendredi 23 avril 2010 04:14
> To: emb...@li...
> Subject: Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu
> 
> The panic is happening in the file hypervisor/setup.c and not in hypervisor.c
> as i told in my previous post.
> Sorry for the confusion.
> On Thu, Apr 22, 2010 at 10:11 PM, sreenaath vasudevan
> <sre...@gm...> wrote:
> Hi
> Thanks for the detailed info given in the
> wiki http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title
> =GettingStarted.
> 
> I am running in to a panic issue (panic at hypervisor.c) when trying to get the
> system up and running (as  given in the wiki), which prevents xen from
> booting.
> This is what I have done.
> 1. I have a virtual machine having ubuntu-9.10 where I followed and installed
> the packages as given in the wiki.
> 2. In addition to that, I did install the following packages, brctl, uml-utilities
> (for 'tunctl') and uboot-mkimage as they were not there in my ubuntu-9.10
> VM.
> 3. Also I changed the /etc/wemu-ifup script as follows (added two more lines
> to what is givien in the wiki for adding the bridge being linking it with the tap0
> interface.)
>        /etc/qemu-ifup
> 
>        #!/bin/sh
>        BRIDGE=br0
>       #setup in promiscuous mode qemu's device
>       echo ifconfig $1 0.0.0.0 promisc up
>       ifconfig $1 0.0.0.0 promisc up
>       echo brctl addbr $BRIDGE
>       brctl addbr $BRIDGE
>       #add it to the bridge
>       echo brctl addif $BRIDGE $1
>       brctl addif $BRIDGE $1
> 
> 4. After that I created two dummy flash files 'flash1' and 'flash2' of sixe 32 MB
> as follows
>  $> sudo dd if=/dev/zero of=./flash2 bs=32000000 count=1
> 
> 5. Then I ran 'qemu' and got the panic at 'hypervisor.c' which I am giving
> below. It would be great if you could let me know how to fix it and get it
> running.
> 
> ----------------------------------------------------------------------------------------------
> --------------------------------------------
> user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M
> mainstone -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash
> ./flash1 -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup
> ifconfig tap0 0.0.0.0 promisc up
> brctl addbr br0
> device br0 already exists; can't create bridge with the same name brctl addif
> br0 tap0 map addr 0x82200a0 root@ubuntu:~/embeddedxen# sudo qemu-
> system-arm -localtime -M mainstone -kernel
> ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1 -pflash
> ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial stdio
> ifconfig tap0 0.0.0.0 promisc up brctl addbr br0 device br0 already exists; can't
> create bridge with the same name brctl addif br0 tap0 map addr 0x82200a0
> Uncompressing Xen................................... done, booting the kernel.
>  __  __            _____  _   _____              _ _ _          _
>  \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
>   \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
>   /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
>  /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|
> 
>  http://www.cl.cam.ac.uk/netos/xen
>  University of Cambridge Computer Laboratory
> 
>  Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14 CET
> 2009
>  EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System
> (REDS) Institute from HEIG-VD/Switzerland
>  http://reds.heig-vd.ch
> 
>  Latest ChangeSet: unavailable
> 
> (XEN) Hypervisor area start at: 0xff000000 (virt)
> (XEN) Physical RAM map:
> (XEN)   00000000a0000000: 0000000004000000
> (XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
> (XEN) End of Xen Area: 2561MiB (2622464KiB)
> (XEN) End of RAM: 0xa3f00000
> (XEN) Boot allocator @ a0100000 - a0115000
> (XEN) NUMA turned off
> (XEN) Faking a node at 0000000000000000-00000000a3f00000
> (XEN) xenheap: 00000000a0115000 - 00000000a0314fff
> (XEN) xenheap(virt): ff115000 - ff314fff
> (XEN) ### frametable: ff315000
> (XEN) ### min_page: a0100
> (XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000
> maddr_to_page(ps)=ff3151f8
> (XEN) Xen heap: 2MiB (2048kiB)
> (XEN) ### first_valid_mfn = a0315
> (XEN) ### max_page = a3f00
> (XEN) Domain heap initialised: DMA width 32 bits
> (XEN) Dom Heap: 15230 pages
> (XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
> (XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init():
> alloc_xenheap_page
> (XEN) Mapping I/O on mainstone...
> (XEN) Init IRQ...
> (XEN) Initing arch-IRQ...
> (XEN) Init scheduler...
> (XEN) Using scheduler: Simple EDF Scheduler (sedf)
> (XEN) Initializing timer...
> (XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
> (XEN) Platform periodic timer is osmr0 @ 1000 Hz
> (XEN) ### arch_domain create OK
> (XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
> (XEN) CPU: 0
> (XEN) PC is at ff00eea8
> (XEN) LR is at ff030ab0
> (XEN) pc : [<ff00eea8>]    lr : [<ff030ab0>]
> (XEN) sp : ff03ff40  ip : ff03ffb4  fp : ff03ffb0
> (XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
> (XEN) r7 : ff052454  r6 : 00000000  r5 : ff0364b3  r4 : 000001d0
> (XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059073
> (XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
> (XEN) Control: 7977  Table: A0004000  DAC: 000000DF
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
> (XEN) ****************************************
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
> (XEN) CPU: 0
> (XEN) PC is at ff00eea8
> (XEN) LR is at ff030a0c
> (XEN) pc : [<ff00eea8>]    lr : [<ff030a0c>]
> (XEN) sp : ff03ff14  ip : ff03ff88  fp : ff03ff84
> (XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
> (XEN) r7 : ff052454  r6 : 00000000  r5 : 60000153  r4 : ff030ac0
> (XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059071
> (XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
> (XEN) Control: 7977  Table: A0004000  DAC: 000000DF
> (XEN) [<ff00eeec>] (+0xff00eeec/0xff03a000) from [<ff030a1c>]
> (+0xff030a1c/0xff03a000)
> (XEN) [<ff030980>] (+0xff030980/0xff03a000) from [<ff030ac0>]
> (+0xff030ac0/0xff03a000)
> (XEN)  r3 = 00000000  r2 = 000001D0  r1 = FF0364B3  r0 = FF039970
> (XEN)  r5 = FF0364B3  r4 = 000001D0
> (XEN) [<ff030a84>] (+0xff030a84/0xff03a000) from [<ff008e58>]
> (+0xff008e58/0xff00acc8)
> (XEN)  r5 = FF05264C  r4 = 00000000
> (XEN) [<ff0089b4>] (+0xff0089b4/0xff00acc8) from [<a0008028>] (???)
> (XEN) machine_halt called: spinning....
> ----------------------------------------------------------------------------------------------
> --------------------------------------------
> Thanks :)
> 
> On Thu, Apr 22, 2010 at 12:56 AM, SAMBUC Lionel <lionel.sambuc@heig-
> vd.ch> wrote:
> Hi,
> 
> Sorry for the delay, I will put online a short step by step procedure to compile
> and start EmbeddedXen, as well as a FAQ, starting with your questions.
> This will be available on the SourceForge web page of the project, I intend to
> have it online by the end of the day (17h00 GMT, 22nd April 2010).
> 
> The web page is located at http://embeddedxen.sourceforge.net/, this is
> where you will find the most up to date information.
> 
> Please continue to post any other question on this mailing list.
> 
> Have a nice day,
> 
> Lionel
> 
> From: xen...@li... [mailto:xen-arm-
> bo...@li...] On Behalf Of sreenaath vasudevan
> Sent: mercredi 21 avril 2010 04:50
> To: xe...@li...
> Subject: [XenARM] Re:xen-pxa270-qemu
> 
>  Hi
> I tried to run xen-arm on pxa270 emulated on qemu by following this link
> http://lists.xensource.com/archives/html/xen-arm/2009-04/msg00001.html
> 
> I am not able to get in to dom0 console at all.
> 
> This is what I ve done
> 1. I installed the cross compiler arm-unknown-linux-gnuabi-gcc. The Linux
> distro I use is Ubuntu 9.10.
> 
> 2. I installed the qemu that came default with ubuntu 9.10 linux.
> 
> 3. The I installed xen-pxa270-qemu from
> https://sourceforge.net/projects/embeddedxen.
> 
> 4. To compile and run it, this is what I did
>     a) I untarred the tarball and did a 'make all' inside the 'xen-pxa270-qemu'
> folder. Before firing the make command, I set the CROSS_COMPILE env
> variable to point to the cross compiler 'arm-unknown-linux-gnuabi-gcc'.
> 
>     b) Then after successful completion of make command, I followed the
> instructions in http://lists.xensource.com/archives/html/xen-arm/2009-
> 05/msg00000.html
> 
>     c) When I run it in non-graphical mode with -nographic option in qemu-
> system-arm, the console outputs that xen image is getting loaded and linux
> image is getting loaded in dom0. After that nothing happens. I am not able to
> enter anything in the command console as it only displays 'Hit Ctrl 'A'  three
> times to enter in to xen mode'. When I hit Ctrl + 'A' three time it displays 'Hit
> Ctrl 'A'  three times to enter in to dom0'
> 
>    d) When I ran it, in Graphical mode I saw a black screen popping up and in
> the command window I see the message "map addr 0x8297e80". After that
> nothing happens. I am not able to see anything in the graphical screen too.
> 
> 
> It would be extremely helpful if someone can tell me how to get in to dom0
> console.
> 
> 
> --
> regards
> sreenaath
> 
> 
> 
> --
> regards
> sreenaath
> 
> 
> 
> --
> regards
> sreenaath

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[sreenaath v. <sre...@gm...>]

The panic is happening in the file hypervisor/setup.c and not in
hypervisor.c as i told in my previous post.
Sorry for the confusion.

On Thu, Apr 22, 2010 at 10:11 PM, sreenaath vasudevan <sre...@gm...
> wrote:

> Hi
> Thanks for the detailed info given in the wiki
> http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted
> .
>
> I am running in to a panic issue (panic at hypervisor.c) when trying to get
> the system up and running (as  given in the wiki), which prevents xen from
> booting.
> This is what I have done.
> 1. I have a virtual machine having ubuntu-9.10 where I followed and
> installed the packages as given in the wiki.
>
> 2. In addition to that, I did install the following packages, brctl,
> uml-utilities (for 'tunctl') and uboot-mkimage as they were not there in my
> ubuntu-9.10 VM.
>
> 3. Also I changed the /etc/wemu-ifup script as follows (added two more
> lines to what is givien in the wiki for adding the bridge being linking it
> with the tap0 interface.)
>        /etc/qemu-ifup
>
>        #!/bin/sh
>        BRIDGE=br0
>       #setup in promiscuous mode qemu's device
>       echo ifconfig $1 0.0.0.0 promisc up
>       ifconfig $1 0.0.0.0 promisc up
>       echo brctl addbr $BRIDGE
>       brctl addbr $BRIDGE
>       #add it to the bridge
>       echo brctl addif $BRIDGE $1
>       brctl addif $BRIDGE $1
>
> 4. After that I created two dummy flash files 'flash1' and 'flash2' of sixe
> 32 MB as follows
>  $> sudo dd if=/dev/zero of=./flash2 bs=32000000 count=1
>
> 5. Then I ran 'qemu' and got the panic at 'hypervisor.c' which I am giving
> below. It would be great if you could let me know how to fix it and get it
> running.
>
>
> ------------------------------------------------------------------------------------------------------------------------------------------
> user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone
> -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1
> -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup
> ifconfig tap0 0.0.0.0 promisc up
> brctl addbr br0
> device br0 already exists; can't create bridge with the same name
> brctl addif br0 tap0
> map addr 0x82200a0
> root@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone
> -kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1
> -pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial
> stdio
> ifconfig tap0 0.0.0.0 promisc up
> brctl addbr br0
> device br0 already exists; can't create bridge with the same name
> brctl addif br0 tap0
> map addr 0x82200a0
> Uncompressing Xen................................... done, booting the
> kernel.
>  __  __            _____  _   _____              _ _ _          _
>  \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
>   \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
>   /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
>  /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|
>
>  http://www.cl.cam.ac.uk/netos/xen
>  University of Cambridge Computer Laboratory
>
>  Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14
> CET 2009
>  EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System (REDS)
> Institute from HEIG-VD/Switzerland
>  http://reds.heig-vd.ch
>
>  Latest ChangeSet: unavailable
>
> (XEN) Hypervisor area start at: 0xff000000 (virt)
> (XEN) Physical RAM map:
> (XEN)   00000000a0000000: 0000000004000000
> (XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
> (XEN) End of Xen Area: 2561MiB (2622464KiB)
> (XEN) End of RAM: 0xa3f00000
> (XEN) Boot allocator @ a0100000 - a0115000
> (XEN) NUMA turned off
> (XEN) Faking a node at 0000000000000000-00000000a3f00000
> (XEN) xenheap: 00000000a0115000 - 00000000a0314fff
> (XEN) xenheap(virt): ff115000 - ff314fff
> (XEN) ### frametable: ff315000
> (XEN) ### min_page: a0100
> (XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000
> maddr_to_page(ps)=ff3151f8
> (XEN) Xen heap: 2MiB (2048kiB)
> (XEN) ### first_valid_mfn = a0315
> (XEN) ### max_page = a3f00
> (XEN) Domain heap initialised: DMA width 32 bits
> (XEN) Dom Heap: 15230 pages
> (XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
> (XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init():
> alloc_xenheap_page
> (XEN) Mapping I/O on mainstone...
> (XEN) Init IRQ...
> (XEN) Initing arch-IRQ...
> (XEN) Init scheduler...
> (XEN) Using scheduler: Simple EDF Scheduler (sedf)
> (XEN) Initializing timer...
> (XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
> (XEN) Platform periodic timer is osmr0 @ 1000 Hz
> (XEN) ### arch_domain create OK
> (XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
> (XEN) CPU: 0
> (XEN) PC is at ff00eea8
> (XEN) LR is at ff030ab0
> (XEN) pc : [<ff00eea8>]    lr : [<ff030ab0>]
> (XEN) sp : ff03ff40  ip : ff03ffb4  fp : ff03ffb0
> (XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
> (XEN) r7 : ff052454  r6 : 00000000  r5 : ff0364b3  r4 : 000001d0
> (XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059073
> (XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
> (XEN) Control: 7977  Table: A0004000  DAC: 000000DF
> (XEN)
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
> (XEN) ****************************************
> (XEN)
> (XEN) Manual reset required ('noreboot' specified)
> (XEN) CPU: 0
> (XEN) PC is at ff00eea8
> (XEN) LR is at ff030a0c
> (XEN) pc : [<ff00eea8>]    lr : [<ff030a0c>]
> (XEN) sp : ff03ff14  ip : ff03ff88  fp : ff03ff84
> (XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
> (XEN) r7 : ff052454  r6 : 00000000  r5 : 60000153  r4 : ff030ac0
> (XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059071
> (XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
> (XEN) Control: 7977  Table: A0004000  DAC: 000000DF
> (XEN) [<ff00eeec>] (+0xff00eeec/0xff03a000) from [<ff030a1c>]
> (+0xff030a1c/0xff03a000)
> (XEN) [<ff030980>] (+0xff030980/0xff03a000) from [<ff030ac0>]
> (+0xff030ac0/0xff03a000)
> (XEN)  r3 = 00000000  r2 = 000001D0  r1 = FF0364B3  r0 = FF039970
> (XEN)  r5 = FF0364B3  r4 = 000001D0
> (XEN) [<ff030a84>] (+0xff030a84/0xff03a000) from [<ff008e58>]
> (+0xff008e58/0xff00acc8)
> (XEN)  r5 = FF05264C  r4 = 00000000
> (XEN) [<ff0089b4>] (+0xff0089b4/0xff00acc8) from [<a0008028>] (???)
> (XEN) machine_halt called: spinning....
>
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Thanks :)
>
>
> On Thu, Apr 22, 2010 at 12:56 AM, SAMBUC Lionel <lio...@he...>wrote:
>
>>  Hi,
>>
>>
>>
>> Sorry for the delay, I will put online a short step by step procedure to
>> compile and
>>
>> start EmbeddedXen, as well as a FAQ, starting with your questions.
>>
>> This will be available on the SourceForge web page of the project, I
>> intend to have it
>>
>> online by the end of the day (17h00 GMT, 22nd April 2010).
>>
>>
>>
>> The web page is located at http://embeddedxen.sourceforge.net/, this is
>> where
>>
>> you will find the most up to date information.
>>
>>
>>
>> Please continue to post any other question on this mailing list.
>>
>>
>>
>> Have a nice day,
>>
>>
>>
>> Lionel
>>
>>
>>
>> *From:* xen...@li... [mailto:
>> xen...@li...] *On Behalf Of *sreenaath vasudevan
>> *Sent:* mercredi 21 avril 2010 04:50
>> *To:* xe...@li...
>> *Subject:* [XenARM] Re:xen-pxa270-qemu
>>
>>
>>
>>  Hi
>>
>> I tried to run xen-arm on pxa270 emulated on qemu by following this link
>>
>> http://lists.xensource.com/archives/html/xen-arm/2009-04/msg00001.html
>>
>> I am not able to get in to dom0 console at all.
>>
>>
>>
>> This is what I ve done
>>
>> 1. I installed the cross compiler arm-unknown-linux-gnuabi-gcc. The Linux
>> distro I use is Ubuntu 9.10.
>>
>>
>>
>> 2. I installed the qemu that came default with ubuntu 9.10 linux.
>>
>>
>>
>> 3. The I installed xen-pxa270-qemu from
>> https://sourceforge.net/projects/embeddedxen.
>>
>>
>>
>> 4. To compile and run it, this is what I did
>>
>>     a) I untarred the tarball and did a 'make all' inside the
>> 'xen-pxa270-qemu' folder. Before firing the make command, I set the
>> CROSS_COMPILE env variable to point to the cross compiler
>> 'arm-unknown-linux-gnuabi-gcc'.
>>
>>
>>
>>     b) Then after successful completion of make command, I followed the
>> instructions in
>> http://lists.xensource.com/archives/html/xen-arm/2009-05/msg00000.html
>>
>>
>>
>>     c) When I run it in non-graphical mode with -nographic option in
>> qemu-system-arm, the console outputs that xen image is getting loaded and
>> linux image is getting loaded in dom0. After that nothing happens. I am not
>> able to enter anything in the command console as it only displays 'Hit Ctrl
>> 'A'  three times to enter in to xen mode'. When I hit Ctrl + 'A' three time
>> it displays 'Hit Ctrl 'A'  three times to enter in to dom0'
>>
>>
>>
>>    d) When I ran it, in Graphical mode I saw a black screen popping up and
>> in the command window I see the message "map addr 0x8297e80". After that
>> nothing happens. I am not able to see anything in the graphical screen too.
>>
>>
>>
>>
>>
>> It would be extremely helpful if someone can tell me how to get in to dom0
>> console.
>>
>>
>>
>>
>> --
>> regards
>> sreenaath
>>
>
>
>
> --
> regards
> sreenaath
>



-- 
regards
sreenaath

Re: [Embeddedxen-devel] [XenARM] Re:xen-pxa270-qemu

[sreenaath v. <sre...@gm...>]

Hi
Thanks for the detailed info given in the wiki
http://sourceforge.net/apps/mediawiki/embeddedxen/index.php?title=GettingStarted
.

I am running in to a panic issue (panic at hypervisor.c) when trying to get
the system up and running (as  given in the wiki), which prevents xen from
booting.
This is what I have done.
1. I have a virtual machine having ubuntu-9.10 where I followed and
installed the packages as given in the wiki.

2. In addition to that, I did install the following packages, brctl,
uml-utilities (for 'tunctl') and uboot-mkimage as they were not there in my
ubuntu-9.10 VM.

3. Also I changed the /etc/wemu-ifup script as follows (added two more lines
to what is givien in the wiki for adding the bridge being linking it with
the tap0 interface.)
       /etc/qemu-ifup

       #!/bin/sh
       BRIDGE=br0
      #setup in promiscuous mode qemu's device
      echo ifconfig $1 0.0.0.0 promisc up
      ifconfig $1 0.0.0.0 promisc up
      echo brctl addbr $BRIDGE
      brctl addbr $BRIDGE
      #add it to the bridge
      echo brctl addif $BRIDGE $1
      brctl addif $BRIDGE $1

4. After that I created two dummy flash files 'flash1' and 'flash2' of sixe
32 MB as follows
 $> sudo dd if=/dev/zero of=./flash2 bs=32000000 count=1

5. Then I ran 'qemu' and got the panic at 'hypervisor.c' which I am giving
below. It would be great if you could let me know how to fix it and get it
running.

------------------------------------------------------------------------------------------------------------------------------------------
user@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone
-kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1
-pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup
ifconfig tap0 0.0.0.0 promisc up
brctl addbr br0
device br0 already exists; can't create bridge with the same name
brctl addif br0 tap0
map addr 0x82200a0
root@ubuntu:~/embeddedxen# sudo qemu-system-arm -localtime -M mainstone
-kernel ./xen/arch/arm/boot/uImage.mainstone -s -m 256 -pflash ./flash1
-pflash ./flash2 -net nic -net tap,ifname=tap0,script=/etc/qemu-ifup -serial
stdio
ifconfig tap0 0.0.0.0 promisc up
brctl addbr br0
device br0 already exists; can't create bridge with the same name
brctl addif br0 tap0
map addr 0x82200a0
Uncompressing Xen................................... done, booting the
kernel.
 __  __            _____  _   _____              _ _ _          _
 \ \/ /___ _ __   |___ / / | |___ /     ___ ___ | (_) |__  _ __(_)
  \  // _ \ '_ \    |_ \ | |   |_ \ __ / __/ _ \| | | '_ \| '__| |
  /  \  __/ | | |  ___) || |_ ___) |__| (_| (_) | | | |_) | |  | |
 /_/\_\___|_| |_| |____(_)_(_)____/    \___\___/|_|_|_.__/|_|  |_|

 http://www.cl.cam.ac.uk/netos/xen
 University of Cambridge Computer Laboratory

 Xen version 3.1.3-colibri (root@) (gcc version 4.1.2) Wed Feb 11 11:24:14
CET 2009
 EmbeddedXEN/PENAR Project - Reconfigurable Embedded Digital System (REDS)
Institute from HEIG-VD/Switzerland
 http://reds.heig-vd.ch

 Latest ChangeSet: unavailable

(XEN) Hypervisor area start at: 0xff000000 (virt)
(XEN) Physical RAM map:
(XEN)   00000000a0000000: 0000000004000000
(XEN) End of multi-kernel area (XEN+dom0/U) -> min_page: 0xa0100
(XEN) End of Xen Area: 2561MiB (2622464KiB)
(XEN) End of RAM: 0xa3f00000
(XEN) Boot allocator @ a0100000 - a0115000
(XEN) NUMA turned off
(XEN) Faking a node at 0000000000000000-00000000a3f00000
(XEN) xenheap: 00000000a0115000 - 00000000a0314fff
(XEN) xenheap(virt): ff115000 - ff314fff
(XEN) ### frametable: ff315000
(XEN) ### min_page: a0100
(XEN) ### ps = a0115000 maddr_to_virt(ps)=ff115000
maddr_to_page(ps)=ff3151f8
(XEN) Xen heap: 2MiB (2048kiB)
(XEN) ### first_valid_mfn = a0315
(XEN) ### max_page = a3f00
(XEN) Domain heap initialised: DMA width 32 bits
(XEN) Dom Heap: 15230 pages
(XEN) CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE)
(XEN) (GCD) xen/arch/arm/hypervisor/mm.c:2070:vector_pt_init():
alloc_xenheap_page
(XEN) Mapping I/O on mainstone...
(XEN) Init IRQ...
(XEN) Initing arch-IRQ...
(XEN) Init scheduler...
(XEN) Using scheduler: Simple EDF Scheduler (sedf)
(XEN) Initializing timer...
(XEN) Platform clock source oscr0 @ 3249600 Hz overflows in 660845 jiffies.
(XEN) Platform periodic timer is osmr0 @ 1000 Hz
(XEN) ### arch_domain create OK
(XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
(XEN) CPU: 0
(XEN) PC is at ff00eea8
(XEN) LR is at ff030ab0
(XEN) pc : [<ff00eea8>]    lr : [<ff030ab0>]
(XEN) sp : ff03ff40  ip : ff03ffb4  fp : ff03ffb0
(XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
(XEN) r7 : ff052454  r6 : 00000000  r5 : ff0364b3  r4 : 000001d0
(XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059073
(XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
(XEN) Control: 7977  Table: A0004000  DAC: 000000DF
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Xen BUG at xen/arch/arm/hypervisor/setup.c:464
(XEN) ****************************************
(XEN)
(XEN) Manual reset required ('noreboot' specified)
(XEN) CPU: 0
(XEN) PC is at ff00eea8
(XEN) LR is at ff030a0c
(XEN) pc : [<ff00eea8>]    lr : [<ff030a0c>]
(XEN) sp : ff03ff14  ip : ff03ff88  fp : ff03ff84
(XEN) r10: ff052648  r9 : ff052528  r8 : 00000000
(XEN) r7 : ff052454  r6 : 00000000  r5 : 60000153  r4 : ff030ac0
(XEN) r3 : 00000000  r2 : 00000000  r1 : 0000000a  r0 : ff059071
(XEN) Flags: nZCv  IRQs on  FIQs off  Mode SVC_32
(XEN) Control: 7977  Table: A0004000  DAC: 000000DF
(XEN) [<ff00eeec>] (+0xff00eeec/0xff03a000) from [<ff030a1c>]
(+0xff030a1c/0xff03a000)
(XEN) [<ff030980>] (+0xff030980/0xff03a000) from [<ff030ac0>]
(+0xff030ac0/0xff03a000)
(XEN)  r3 = 00000000  r2 = 000001D0  r1 = FF0364B3  r0 = FF039970
(XEN)  r5 = FF0364B3  r4 = 000001D0
(XEN) [<ff030a84>] (+0xff030a84/0xff03a000) from [<ff008e58>]
(+0xff008e58/0xff00acc8)
(XEN)  r5 = FF05264C  r4 = 00000000
(XEN) [<ff0089b4>] (+0xff0089b4/0xff00acc8) from [<a0008028>] (???)
(XEN) machine_halt called: spinning....
------------------------------------------------------------------------------------------------------------------------------------------

Thanks :)

On Thu, Apr 22, 2010 at 12:56 AM, SAMBUC Lionel <lio...@he...>wrote:

>  Hi,
>
>
>
> Sorry for the delay, I will put online a short step by step procedure to
> compile and
>
> start EmbeddedXen, as well as a FAQ, starting with your questions.
>
> This will be available on the SourceForge web page of the project, I intend
> to have it
>
> online by the end of the day (17h00 GMT, 22nd April 2010).
>
>
>
> The web page is located at http://embeddedxen.sourceforge.net/, this is
> where
>
> you will find the most up to date information.
>
>
>
> Please continue to post any other question on this mailing list.
>
>
>
> Have a nice day,
>
>
>
> Lionel
>
>
>
> *From:* xen...@li... [mailto:
> xen...@li...] *On Behalf Of *sreenaath vasudevan
> *Sent:* mercredi 21 avril 2010 04:50
> *To:* xe...@li...
> *Subject:* [XenARM] Re:xen-pxa270-qemu
>
>
>
>  Hi
>
> I tried to run xen-arm on pxa270 emulated on qemu by following this link
>
> http://lists.xensource.com/archives/html/xen-arm/2009-04/msg00001.html
>
> I am not able to get in to dom0 console at all.
>
>
>
> This is what I ve done
>
> 1. I installed the cross compiler arm-unknown-linux-gnuabi-gcc. The Linux
> distro I use is Ubuntu 9.10.
>
>
>
> 2. I installed the qemu that came default with ubuntu 9.10 linux.
>
>
>
> 3. The I installed xen-pxa270-qemu from
> https://sourceforge.net/projects/embeddedxen.
>
>
>
> 4. To compile and run it, this is what I did
>
>     a) I untarred the tarball and did a 'make all' inside the
> 'xen-pxa270-qemu' folder. Before firing the make command, I set the
> CROSS_COMPILE env variable to point to the cross compiler
> 'arm-unknown-linux-gnuabi-gcc'.
>
>
>
>     b) Then after successful completion of make command, I followed the
> instructions in
> http://lists.xensource.com/archives/html/xen-arm/2009-05/msg00000.html
>
>
>
>     c) When I run it in non-graphical mode with -nographic option in
> qemu-system-arm, the console outputs that xen image is getting loaded and
> linux image is getting loaded in dom0. After that nothing happens. I am not
> able to enter anything in the command console as it only displays 'Hit Ctrl
> 'A'  three times to enter in to xen mode'. When I hit Ctrl + 'A' three time
> it displays 'Hit Ctrl 'A'  three times to enter in to dom0'
>
>
>
>    d) When I ran it, in Graphical mode I saw a black screen popping up and
> in the command window I see the message "map addr 0x8297e80". After that
> nothing happens. I am not able to see anything in the graphical screen too.
>
>
>
>
>
> It would be extremely helpful if someone can tell me how to get in to dom0
> console.
>
>
>
>
> --
> regards
> sreenaath
>



-- 
regards
sreenaath

Re: [Embeddedxen-devel] xen-pxa270-qemu

[sreenaath v. <sre...@gm...>]

 Hi
I tried to run xen-arm on pxa270 emulated on qemu by following this link
http://lists.xensource.com/archives/html/xen-arm/2009-04/msg00001.html

I am not able to get in to dom0 console at all.

This is what I ve done
1. I installed the cross compiler arm-unknown-linux-gnuabi-gcc. The Linux
distro I use is Ubuntu 9.10.

2. I installed the qemu that came default with ubuntu 9.10 linux.

3. The I installed xen-pxa270-qemu from
https://sourceforge.net/projects/embeddedxen.

4. To compile and run it, this is what I did
    a) I untarred the tarball and did a 'make all' inside the
'xen-pxa270-qemu' folder. Before firing the make command, I set the
CROSS_COMPILE env variable to point to the cross compiler
'arm-unknown-linux-gnuabi-gcc'.

    b) Then after successful completion of make command, I followed the
instructions in
http://lists.xensource.com/archives/html/xen-arm/2009-05/msg00000.html

    c) When I run it in non-graphical mode with -nographic option in
qemu-system-arm, the console outputs that xen image is getting loaded and
linux image is getting loaded in dom0. After that nothing happens. I am not
able to enter anything in the command console as it only displays 'Hit Ctrl
'A'  three times to enter in to xen mode'. When I hit Ctrl + 'A' three time
it displays 'Hit Ctrl 'A'  three times to enter in to dom0'

   d) When I ran it, in Graphical mode I saw a black screen popping up and
in the command window I see the message "map addr 0x8297e80". After that
nothing happens. I am not able to see anything in the graphical screen too.


It would be extremely helpful if someone can tell me how to get in to dom0
console.


regards
sreenaath

Re: [Embeddedxen-devel] Questions about your project

[ROSSIER D. <Dan...@he...>]

Hello Adrien,

Sorry for my late answer. I'm also posting this mail to the mailing list in case of interest.

> -----Original Message-----
> From: deG Adrien [mailto:adr...@ya...]
> Sent: jeudi 18 mars 2010 11:33
> To: ros...@us...; pat...@us...
> Subject: Questions about your project
> 
> Hello,
> 
> It seems that your work is a fork of SAMSUNG development initialized in
> 2008 on IMX21ADS dev board (we don't have any news now since it was
> supposed to integrate XEN mainline in 2009).

Samsung probably had to face some issues with their management to get the approval for further public releases.

> From what I understand, the intent of your project is to bring hard realtime
> within XEN using xenomai.

That's correct; indeed, we started a first porting of Xenomai on top of the hypervisor as a special realtime XEN domU 
(called domU-RT). But there still remain quite a lot of things to do in this area, that we plan to achieve over this Year.

> I am very interested with your project, but it brings a lot of questions to me
> since there are a lot of patches been done.
> Do you think we can execute a VXWORKS in parallel with your modifications ?

hmm, the only way I see for using VxWorks applications would be to use the Xenomai skin devoted to this RTOS.
If you want to a "full" VxWorks, it will require much more adaptations, however still possible to do.

> What are the hard real time performance you can actually achieve ?

Currently, we didn't modify the hypervisor scheduling policy. It means that the domU-RT gets regular ticks at the same frequency
that a "non-RT" domU domain. We made some measurements and got some delays up to 300us for a IRQ propagation from the hypervisor to the domU,
with quite a big jitter. We understand this delay, and I'm sure that we can reduce provided some modification of the underlying scheduling policy.

> Is your work related to some professionnal stuff or a hobby ?

I would prefer to say something "professional"; we are actually doing this work in a context of applied research projects.

> Are you using the same hardware environment as SAMSUNG people i.e.
> IMX21ADS dev board, same OS fedora 6 and same cross compilation
> environment ? I can't see any information on this subject, but would like to
> test your solution.

Not at all; we are using a Intel/PXA270 Colibri board on the one hand, and a QEMU/Mainstone on the other hand. Saying that,
both boards are endowed with an ARMv5 core such as the one used by i.MX21, so the same MMU mechanisms are used, and
we can much rely on the port from Samsung.


Kind regards
Daniel