Mailing List Archive

Hello Damien,

On Wed, Oct 17, 2007 at 04:53:39PM -0400, Damien Barthélémy wrote:
> Hello
>
> This is my first message on the list. I am the student working with Daniel
> Rossier.
>
> We finally got a minimal xen code (without virt mechanisms, bootstrap only)
> building, linking and starting.
>
> The first step was to get a minimal version of linux 2.6.18 (isolate the
> linux arm bootstrap). We built only some files in /arch/arm and got a 3 ko
> linux image. We suppressed the directories containing unused code /fs /crypt
> /kernel /drivers /mm /ipc /net...
>
> The initial idea was to introduce this bootstrap in the xen 3.1 tree. But I
> got many problems with this job. It is difficult to adapt the xen Makefiles
> to get the linux bootstrap build. I had problems with CFLAGS, linker script,
> the whole build process, ... We decided not to spend to much (more) time on
> this problem and to include the xen tree into our modified linux bootstrap
> tree. The linux bootstrap code call the xen first C function (start_xen).

FWIW, I'ld recommend using a .config and config.h generated for the
Xen ARM target machine using Linux. Have xen/arch/arm/Rules.mk
include the .config and include config.h in source files to properly
select ARM processor and machine build time options. I'ld also recommend
using (a sub set of ) the linux/arch/arm/Makefile as the basis for the
xen/arch/arm/Rules.mk file. In this way you should have most of the
compiler machine dependent options properly specified and then sources
leveraged from Linux for Xen ARM will select all of the proper ARM
processor and machine specific code. Unfortunately Xen arch and machine
selection is much more primitive (non-existent even : ) than Linux kbuild
but using the preceding helps to alleviate this issue (especially for
ARM which does not have a common machine architecture as do x86 and other
architectures). It would be nice to augment Xen ARM processor and
machine selection via some type of `make *config` option similar to
Linux but, as I mention, the preceding should be good enough to get
started...

>
> This code is now avaible on sourceforge
> http://sourceforge.net/projects/embeddedxen/

I notice that the embeddedxen CVS repo is not setup yet. Hrm, maybe
that's for the better. I'ld personally prefer to see a GIT or HG
repo instead...

> The final image is 4.4 ko big with a source code tree of 40 Mo.
>
> The plan is now to introduce virt functionalities in our code. One
> possibility is to use some of the linux low level functionalities to avoid
> reimplementing them in the xen code. Memory mapping is also a problem we
> will spend time on the next weeks.

It's nice to see you're making some progress getting the Xen ARM community
port moving forward! Hopefully we can spend some time collaborating on
this...

>
>
> Damien

> _______________________________________________
> Xen-arm mailing list
> Xen-arm@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm


--
Regards,
George

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm

On Wed, Oct 17, 2007 at 08:47:13PM -0400, George G. Davis wrote:
> Hello Damien,
>
> On Wed, Oct 17, 2007 at 04:53:39PM -0400, Damien Barthélémy wrote:
> > Hello
> >
> > This is my first message on the list. I am the student working with Daniel
> > Rossier.
> >
> > We finally got a minimal xen code (without virt mechanisms, bootstrap only)
> > building, linking and starting.
> >
> > The first step was to get a minimal version of linux 2.6.18 (isolate the
> > linux arm bootstrap). We built only some files in /arch/arm and got a 3 ko
> > linux image. We suppressed the directories containing unused code /fs /crypt
> > /kernel /drivers /mm /ipc /net...
> >
> > The initial idea was to introduce this bootstrap in the xen 3.1 tree. But I
> > got many problems with this job. It is difficult to adapt the xen Makefiles
> > to get the linux bootstrap build. I had problems with CFLAGS, linker script,
> > the whole build process, ... We decided not to spend to much (more) time on
> > this problem and to include the xen tree into our modified linux bootstrap
> > tree. The linux bootstrap code call the xen first C function (start_xen).
>
> FWIW, I'ld recommend using a .config and config.h generated for the
> Xen ARM target machine using Linux. Have xen/arch/arm/Rules.mk
> include the .config and include config.h in source files to properly
> select ARM processor and machine build time options. I'ld also recommend
> using (a sub set of ) the linux/arch/arm/Makefile as the basis for the
> xen/arch/arm/Rules.mk file. In this way you should have most of the
> compiler machine dependent options properly specified and then sources
> leveraged from Linux for Xen ARM will select all of the proper ARM
> processor and machine specific code. Unfortunately Xen arch and machine
> selection is much more primitive (non-existent even : ) than Linux kbuild
> but using the preceding helps to alleviate this issue (especially for
> ARM which does not have a common machine architecture as do x86 and other
> architectures). It would be nice to augment Xen ARM processor and
> machine selection via some type of `make *config` option similar to
> Linux but, as I mention, the preceding should be good enough to get
> started...
>
> >
> > This code is now avaible on sourceforge
> > http://sourceforge.net/projects/embeddedxen/

I had a quick look at the tarball, interesting approach integrating Xen
source as a subdirectory of Linux-2.6.18. : ) Now I see how that solved
the problem of gcc/gas command line args as well as the problem of
configuring the ARM machine (using Linux kbuild : ). Could do similar
as I mentioned above but that leaves the machine config issue unresolved
and I reckon it is rather inconvenient to create config files under
Linux and manually copy those into Xen. I do like your approach so
far but it will need to be reconciled when pushing it back upstream...

--
Regards,
George

_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm

> FWIW, I'ld recommend using a .config and config.h generated for the
> Xen ARM target machine using Linux. Have xen/arch/arm/Rules.mk
> include the .config and include config.h in source files to properly
> select ARM processor and machine build time options. I'ld also recommend
> using (a sub set of ) the linux/arch/arm/Makefile as the basis for the
> xen/arch/arm/Rules.mk file.
>

I note this for future work on xen3.1 tree integration. I didn't use these 3
linux files directly as a base (copy of the file). I tried to adapt the
Makefiles/config options one by one.

I notice that the embeddedxen CVS repo is not setup yet. Hrm, maybe
> that's for the better. I'ld personally prefer to see a GIT or HG
> repo instead...


The question of what code repo to use is not clear. We prefer to use
tarball+patch now (we have to do a lot of add/remove file). But it will
certainly change with the project progress.

It's nice to see you're making some progress getting the Xen ARM community
> port moving forward! Hopefully we can spend some time collaborating on
> this...


Of course. I will continue to send information about my work ! A code
repository is a question to study... I am not familiar with this !

>-----Original Message-----
>From: xen-arm-bounces@lists.xensource.com [mailto:xen-arm-
>bounces@lists.xensource.com] On Behalf Of George G. Davis
>Sent: jeudi 18 octobre 2007 02:47
>To: Damien Barthélémy
>Cc: xen-arm@lists.xensource.com
>Subject: Re: [XenARM] initial bootstrap code
>
>Hello Damien,
>
>On Wed, Oct 17, 2007 at 04:53:39PM -0400, Damien Barthélémy wrote:
>> Hello
>>
>> This is my first message on the list. I am the student working with
>Daniel
>> Rossier.
>>
>> We finally got a minimal xen code (without virt mechanisms, bootstrap
>only)
>> building, linking and starting.
>>
>> The first step was to get a minimal version of linux 2.6.18 (isolate
>the
>> linux arm bootstrap). We built only some files in /arch/arm and got a
>3 ko
>> linux image. We suppressed the directories containing unused code /fs
>/crypt
>> /kernel /drivers /mm /ipc /net...
>>
>> The initial idea was to introduce this bootstrap in the xen 3.1 tree.
>But I
>> got many problems with this job. It is difficult to adapt the xen
>Makefiles
>> to get the linux bootstrap build. I had problems with CFLAGS, linker
>script,
>> the whole build process, ... We decided not to spend to much (more)
>time on
>> this problem and to include the xen tree into our modified linux
>bootstrap
>> tree. The linux bootstrap code call the xen first C function
>(start_xen).
>
>FWIW, I'ld recommend using a .config and config.h generated for the
>Xen ARM target machine using Linux. Have xen/arch/arm/Rules.mk
>include the .config and include config.h in source files to properly
>select ARM processor and machine build time options. I'ld also
>recommend
>using (a sub set of ) the linux/arch/arm/Makefile as the basis for the
>xen/arch/arm/Rules.mk file. In this way you should have most of the
>compiler machine dependent options properly specified and then sources
>leveraged from Linux for Xen ARM will select all of the proper ARM
>processor and machine specific code. Unfortunately Xen arch and machine
>selection is much more primitive (non-existent even : ) than Linux
>kbuild
>but using the preceding helps to alleviate this issue (especially for
>ARM which does not have a common machine architecture as do x86 and
>other
>architectures). It would be nice to augment Xen ARM processor and
>machine selection via some type of `make *config` option similar to
>Linux but, as I mention, the preceding should be good enough to get
>started...
>
>>
>> This code is now avaible on sourceforge
>> http://sourceforge.net/projects/embeddedxen/
>
>I notice that the embeddedxen CVS repo is not setup yet. Hrm, maybe
>that's for the better. I'ld personally prefer to see a GIT or HG
>repo instead...

Yes, I definitively agree. The best would be to contact xensource for
an official repository. However, since Damien has not much time
remaining for his work, I would suggest to keep this way and to think
about a better way as soon as we are more advanced. We didn't want to
bother you either with uploading big files every two days ;-)
>
>> The final image is 4.4 ko big with a source code tree of 40 Mo.
>>
>> The plan is now to introduce virt functionalities in our code. One
>> possibility is to use some of the linux low level functionalities to
>avoid
>> reimplementing them in the xen code. Memory mapping is also a problem
>we
>> will spend time on the next weeks.
>
>It's nice to see you're making some progress getting the Xen ARM
>community
>port moving forward! Hopefully we can spend some time collaborating on
>this...

Sure. Damien will investigate the IRQ virtualization mechanisms in XEN before
porting the low-leve memory manager initializations.

>
>>
>>
>> Damien
>
>> _______________________________________________
>> Xen-arm mailing list
>> Xen-arm@lists.xensource.com
>> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm
>
>
>--
>Regards,
>George
>
>_______________________________________________
>Xen-arm mailing list
>Xen-arm@lists.xensource.com
>http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm

Daniel


_______________________________________________
Xen-arm mailing list
Xen-arm@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-arm