Re: [Xenomai-help] Xenomai on Gumstix

Re: [Xenomai-help] Xenomai on Gumstix

[BERRUER Sébastien]

Hello,

I finally find a way to make it works. You showed me the way:
>my bitbake recipe does have a few modifications to auto-patch adeos into the 
kernel
I've add only one line to my recipe for the kernel (~/gumstix/gumstix-
oe/user.collection/packages/linux/gumstix-kernel_2.6.24.bb). After all the 
require files and specifics patchs, I've add:
file://adeos-ipipe-2.6.24-arm-1.9-01.patch; patch=1

That patch file come directly from Xenomai 2.4.3 
(Xenomai-2.4.3/ksrc/arch/arm/patches/). I've made a local copy of it in the 
specific kernel directory 
(~/gumstix/gumstixoe/use.collection/packages/linux/gumstix-kernel-2.6.24/). 
Then, I only ran:
bitbake gumstix-kernel -c rebuild
To produce the uImage.

When I ran bitbake the first time to get the sources, I ran the previous 
command (Yes, I only focus now that it wasn't the right thing to do). There 
was a complete compilation on this source code. Only after that, I applied the 
Xenomai patch. So, when I compiled again, I suppose there would have been some 
object code that would not be compile again. So, those parts would never know 
the existance of Adeos. It's probably that which gave me an error.

Now, Adeos works ! I have to see what will append with the Xenomai 
userspace...

Really great thanks !

Regards,


Le vendredi 16 janvier 2009 17:57:40 Felipe Brandão Cavalcanti, vous avez 
écrit :
> On Fri, Jan 16, 2009 at 11:42 AM, <Sebastien.Berruer@domain.hid>wrote:
> > Hello,
> >
> > KERNEL VERSIONING
> >
> > > I've patched the kernel with Adeos. I followed the instruction of
> > >
> >> > Xenomai 2.4.3 for a linux kernel 2.6.24.
> >>
> >> Please use the latest version from the 2.4 (stable) branch: Xenomai
> >> 2.4.6.1.
> >
> > I've tried to update from the repository using:
> >
> > svn update
> >
> > But, I still have only kernel minor versions 21, 22, 24 of kernel 2.6.
> > (NOTE: letting svn using the content of .svn/ to find the repository
> > or typing the complete address does the same)
> > Then, I've tried to list the repository with:
> >
> > svn list
> >
> > There is still the same directory structure, so it's logical nothing
> > append. I'm ready to use the patch 2.6.26 from Xenomai 2.4.6.1, but I
> > need to be able to download the sources of the corresponding kernel.
> > May I not looking for at the right place ? May I do my own recipe ?
>
> I grabbed the latest Adeos patch from their website:
> http://home.gna.org/adeos/
> (actually, http://download.gna.org/adeos/patches/v2.6/arm/older/)
> I chose the appropriate architecture and kernel version and used it by
> passing an extra argument to the ./prepare-kernel script so that it would
> use the apropriate version of the adeos patch. I don't remember it off the
> top of my head, however a --help in the script should point you in the
> right direction.
>
> > KERNEL COMPILATION
> >
> >
> >  After getting everything set up (including the removal of several
> > features
> >
> >> witch you might not really need - the kernel needs to be less than 1
> >> Mb)[...]
> >
> > (NOTE: I've done my changes from the original copy of the kernel)
> > I've tried to remove the device drivers for USB using the menuconfig:
> >
> > bitbake -c menuconfig gumstix-kernel
> >
> > Then, I still have done the manual patch for Xenomai and copied the
> > .config over the defconfig.
> > (NOTE: It would not change anything to patch first and then removing
> > the USB drivers using the menuconfig (?) Furthermore, doing the copy over
> > defconfig, I write definitively the default defconfig)
>
> This should be fine - the important part is that the kernel is properly
> configured (i.e., Gumstix selected as the target machine, etc..) and that
> the xenomai options are properly configured as well (there should be a
> whole section for xenomai and real-time options).
>
> > I force the compilation:
> >
> > bitbake -f -c compile gumstix-kernel
> >
> > I saw that Adeos doesn't work in the final kernel. During the boot in
> > simulation with Qemu, I've got this kind of messages:
> >
> > [...]
> > <4>smc91x: Unknown symbol __ipipe_unstall_root
> > <4>smc91x: Unknown symbol __ipipe_root_status
> > <4>smc91x: Unknown symbol __ipipe_restore_root
> > <4>smc911x: Unknown symbol __ipipe_root_status
> > <4>smc911x: Unknown symbol __ipipe_restore_root
> > <4>evdev: Unknown symbol __ipipe_unstall_root
> > <4>evdev: Unknown symbol __ipipe_root_status
> > <4>mmc_core: Unknown symbol __ipipe_root_status
> > <4>mmc_core: Unknown symbol __ipipe_restore_root
> > <4>mmc_block: Unknown symbol __ipipe_unstall_root
> > <4>mmc_block: Unknown symbol __ipipe_root_status
> > [...]
> >
> > I'm disappointed and I'm asking myself if don't need to add something to
> > the recipe that manage the modules (i.e task-base-gumstix) ?
> >
> > Regards,
>
> Well, try to patch it with the other version of Adeos. I never really
> worked with Qemu, so I am not sure where the problem might be. I always
> generate a new image for my gumstix (using the bitbake gumstix-basic-image
> -c rebuild command,
> as well as rebuilding task-base-gumstix) and flash it in order to do the
> testing - however, Adeos is loaded way before any modules, so I doubt that
> it has anything to do with that.
>
> Anyway, try this out - if everything goes wrong, I can send you my own
> kernel for testing, and I can take a quick look at your .config files to
> see if there is anything wrong.
>
> Hope this helps,
>       -Felipe Brandão Cavalcanti
>       LARA - Laboratory of Robotics and Automation
>       Department of Electrical Engineering
>       UnB - University of Brasília, Brazil
>       http://www.lara.unb.br/
>
> PS: Don't forget to send the messages to the list!
>
> Felipe Brandão Cavalcanti <cavalkaf@domain.hid> a écrit :
> >  Well, I did have a few issues with the initial kernel config - what I
> > did
> >
> >> to
> >> get the kernel working was to copy the original (i.e., the one that came
> >> with the Gumstix) defconfig file to the working directory (IIRC,
> >> ~/gumstix/gumstix-oe/tmp/work/....) as .config BEFORE running the
> >> command bitbake -c menuconfig gumstix-kernel. This will give you the
> >> default gumstix
> >> config to start off the kernel customization procedure.
> >> After getting everything set up (including the removal of several
> >> features witch you might not really need - the kernel needs to be less
> >> than 1 Mb), I
> >> copied the new .config over to the defconfig file. Than I just went on
> >> to compile the kernel as usual (however, my bitbake recipe does have a
> >> few modifications to auto-patch adeos into the kernel).
> >>
> >> BTW, keep in mind that you also need to install the xenomai userspace
> >> packages, that will take up around 7 Mb in your system.
> >>
> >> I will be happy to help if you have any other specific questions - I
> >> have a
> >> fully custom gumstix distribution with Xenomai (it is a work in
> >> progress, but it does seem to work fine at the moment), with a working
> >> kernel and xenomai packages (stripped-out, no documentation, etc...) I
> >> would also be happy to receive any interesting info on this area (any
> >> new solutions, etc)
> >> - not many people seem to be using the gumstix platform for
> >> real-time purposes, but it seems like an excellent choice. I do plan on
> >> organizing all of this information sooner or later on a webpage (the
> >> last step of my project involves porting the OROCOS plataform over to
> >> the XScale
> >> processor, and than getting it working on the gumstix - after thats
> >> done, I
> >> will document the entire process).
> >>
> >> Hope this helps!
> >>        -Felipe Brandão Cavalcanti
> >>        LARA - Laboratory of Robotics and Automation
> >>        Department of Electrical Engineering
> >>        UnB - University of Brasília, Brazil
> >>        http://www.lara.unb.br/
> >>
> >> On Mon, Jan 12, 2009 at 8:14 AM, Gilles Chanteperdrix <
> >> gilles.chanteperdrix@xenomai.org> wrote:
> >>
> >>  Sebastien.Berruer@domain.hid wrote:
> >>> > Hi,
> >>> >
> >>> > I'm a student and I work on a project to get Xenomai running on a
> >>> > gumstix platform. I'm using a Verdex board and OpenEmbedded as my
> >>> > development environment. Prior to re-flashing the board, I'm testing
> >>> > the RAM image with Qemu.
> >>> >
> >>> > I've patched the kernel with Adeos. I followed the instruction of
> >>> > Xenomai 2.4.3 for a linux kernel 2.6.24.
> >>>
> >>> Please use the latest version from the 2.4 (stable) branch: Xenomai
> >>> 2.4.6.1.
> >>>
> >>> > I've been careful to run the command :
> >>> > bitbake gumstix-kernel -c menuconfig
> >>> > to force the copy of
> >>>
> >>> ~/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnue
> >>>abi/gumstix-kernel-2.6.24-r1/linux-2.6.24/.config
> >>>
> >>> > to
> >>>
> >>> ~/gumstix/gumstix-oe/user.collection/packages/linux/gumstix-kernel-2.6.
> >>>24/gumstix-custom-verdex/defconfig
> >>>
> >>> > Then, I tried to recompile the kernel source code (without that
> >>> > bitbake unpacked the archive of the previous version)
> >>> > bitbake gumstix-kernel -f -c compile
> >>> >
> >>> > And create the new images
> >>> > bitbake task-base-gumstix -c rebuild
> >>> > bitbake gumstix-basic-image -c rebuild
> >>> >
> >>> > I've made an image of RAM with the dd command to run in Qemu. But,
> >>> > when I'm trying to boot this image, the boot stop and said me :
> >>> > Copying kernel to 0xa2000000 from 0x01f00000 (length
> >>> > 0x00100000)...done ## Booting image at a2000000 ...
> >>> >      Image Name:   Angstrom/2.6.24/gumstix-custom-v
> >>> >      Image Type:   ARM Linux Kernel Image (uncompressed)
> >>> >      Data Size:    1124960 Bytes =  1.1 MB
> >>> >      Load Address: a0008000
> >>> >      Entry Point:  a0008000
> >>> > OK
> >>> >
> >>> > Starting kernel ...
> >>> >
> >>> > ran out of input data
> >>>
> >>> It looks like a memory layout issue, such as the bootloader not copying
> >>> the kernel completely, or the places where the kernel is copied
> >>> overlapping with something else like an initrd.
> >>>
> >>>
> >>> --
> >>>                                                 Gilles.
> >>>
> >>> _______________________________________________
> >>> Xenomai-help mailing list
> >>> Xenomai-help@domain.hid
> >>> https://mail.gna.org/listinfo/xenomai-help
> >>>
> > |=============================================================|
> > | BERRUER Sébastien        |                                  |
> > | 2 rue du Vieil Armand    | Tel : 06-76-35-29-55             |
> > | Studio 112               | Email : sberruer@domain.hid     |
> > | 67100 STRASBOURG         |                                  |
> > |=============================================================|

Re: [Xenomai-help] Xenomai on Gumstix

[Gilles Chanteperdrix]

BERRUER Sébastien wrote:
> Hello,
> 
> I finally find a way to make it works. You showed me the way:
>> my bitbake recipe does have a few modifications to auto-patch adeos into the 
> kernel
> I've add only one line to my recipe for the kernel (~/gumstix/gumstix-
> oe/user.collection/packages/linux/gumstix-kernel_2.6.24.bb). After all the 
> require files and specifics patchs, I've add:
> file://adeos-ipipe-2.6.24-arm-1.9-01.patch; patch=1
> 
> That patch file come directly from Xenomai 2.4.3 
> (Xenomai-2.4.3/ksrc/arch/arm/patches/). I've made a local copy of it in the 
> specific kernel directory 
> (~/gumstix/gumstixoe/use.collection/packages/linux/gumstix-kernel-2.6.24/). 
> Then, I only ran:
> bitbake gumstix-kernel -c rebuild
> To produce the uImage.
> 
> When I ran bitbake the first time to get the sources, I ran the previous 
> command (Yes, I only focus now that it wasn't the right thing to do). There 
> was a complete compilation on this source code. Only after that, I applied the 
> Xenomai patch. So, when I compiled again, I suppose there would have been some 
> object code that would not be compile again. So, those parts would never know 
> the existance of Adeos. It's probably that which gave me an error.
> 
> Now, Adeos works ! I have to see what will append with the Xenomai 
> userspace...

I still do not understand why you are picking up such old versions. When
starting a new development, there is simply no reason to pick an old
version, as you risk to hit and report bugs which have already been
fixed, and waste everybody's precious time.

Anyway, you are not doing things the proper way, as Felipe told you, as
explained in the README.INSTALL file which you can find in the xenomai
tarball, and as explained here:
http://www.xenomai.org/index.php/Xenomai_quick_build_quide

To get xenomai kernel-space support, you have to run the
prepare-kernel.sh script prior to compile the kernel.

If you do not do that, Xenomai user-space support will simply not work.

-- 
					    Gilles.

[Xenomai-help] Xenomai on gumstix

[Linus Casassa]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

It works!

But I notice that the frequency is bad configured.

I am using the trivial-periodic example.
http://www.xenomai.org/documentation/xenomai-2.4/html/api/trivial-periodic_8c-example.html

I had to change
rt_task_set_periodic(NULL, TM_NOW, 1000000000);
to
rt_task_set_periodic(NULL, TM_NOW, 1000);
to get 1 second.

How can I fix this?

I have a gumstix verdex pro:
Marvell PXA270 with XScale
Speed: 400MHz

PD: The more I go into xenomai the more I like it! Thanks for the wonderful
invention!

-- 
Linus Casassa
Estudiante Ingeniería Civil Electrónica
Fono: 56-9-97776941

[-- Attachment #2: Type: text/html, Size: 783 bytes --]

Re: [Xenomai-help] Xenomai on gumstix

[Gilles Chanteperdrix]

Linus Casassa wrote:
> It works!
> 
> But I notice that the frequency is bad configured.
> 
> I am using the trivial-periodic example.
> http://www.xenomai.org/documentation/xenomai-2.4/html/api/trivial-periodic_8c-example.html
> 
> I had to change
> rt_task_set_periodic(NULL, TM_NOW, 1000000000);
> to
> rt_task_set_periodic(NULL, TM_NOW, 1000);
> to get 1 second.
> 
> How can I fix this?

You probably selected a periodic timer for the native skin. The example
is made for the aperiodic timer.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on gumstix

[Linus Casassa]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

I don't understand. The example is for a periodic task. What did I miss? :S

On Sat, Oct 3, 2009 at 6:08 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Linus Casassa wrote:
> > It works!
> >
> > But I notice that the frequency is bad configured.
> >
> > I am using the trivial-periodic example.
> >
> http://www.xenomai.org/documentation/xenomai-2.4/html/api/trivial-periodic_8c-example.html
> >
> > I had to change
> > rt_task_set_periodic(NULL, TM_NOW, 1000000000);
> > to
> > rt_task_set_periodic(NULL, TM_NOW, 1000);
> > to get 1 second.
> >
> > How can I fix this?
>
> You probably selected a periodic timer for the native skin. The example
> is made for the aperiodic timer.
>
> --
>                                             Gilles.
>



-- 
Linus Casassa
Estudiante Ingeniería Civil Electrónica
Fono: 56-9-97776941

[-- Attachment #2: Type: text/html, Size: 1433 bytes --]

Re: [Xenomai-help] Xenomai on gumstix

[Gilles Chanteperdrix]

Linus Casassa wrote:
> I don't understand. The example is for a periodic task. What did I miss? :S

The configuration of the skin timer. The skin timer may be periodic or
aperiodic. Whereas everyone chooses to run an aperiodic timer since it
gives a much better precision, you seem to have chosen to run a periodic
timer.

-- 
					    Gilles.

Re: [Xenomai-help] Xenomai on Gumstix

[Felipe Brandão Cavalcanti]

[-- Attachment #1: Type: text/plain, Size: 9159 bytes --]

On Fri, Jan 16, 2009 at 11:42 AM, <Sebastien.Berruer@domain.hid>wrote:

> Hello,
>
> KERNEL VERSIONING
>
> > I've patched the kernel with Adeos. I followed the instruction of
>> > Xenomai 2.4.3 for a linux kernel 2.6.24.
>>
>> Please use the latest version from the 2.4 (stable) branch: Xenomai
>> 2.4.6.1.
>>
>
> I've tried to update from the repository using:
>
> svn update
>
> But, I still have only kernel minor versions 21, 22, 24 of kernel 2.6.
> (NOTE: letting svn using the content of .svn/ to find the repository
> or typing the complete address does the same)
> Then, I've tried to list the repository with:
>
> svn list
>
> There is still the same directory structure, so it's logical nothing
> append. I'm ready to use the patch 2.6.26 from Xenomai 2.4.6.1, but I
> need to be able to download the sources of the corresponding kernel.
> May I not looking for at the right place ? May I do my own recipe ?
>

I grabbed the latest Adeos patch from their website:
http://home.gna.org/adeos/
(actually, http://download.gna.org/adeos/patches/v2.6/arm/older/)
I chose the appropriate architecture and kernel version and used it by
passing an extra argument to the ./prepare-kernel script so that it would
use the apropriate version of the adeos patch. I don't remember it off the
top of my head, however a --help in the script should point you in the right
direction.


>
> KERNEL COMPILATION
>
>
>  After getting everything set up (including the removal of several features
>> witch you might not really need - the kernel needs to be less than 1
>> Mb)[...]
>>
>
> (NOTE: I've done my changes from the original copy of the kernel)
> I've tried to remove the device drivers for USB using the menuconfig:
>
> bitbake -c menuconfig gumstix-kernel
>
> Then, I still have done the manual patch for Xenomai and copied the
> .config over the defconfig.
> (NOTE: It would not change anything to patch first and then removing
> the USB drivers using the menuconfig (?) Furthermore, doing the copy over
> defconfig, I write definitively the default defconfig)


This should be fine - the important part is that the kernel is properly
configured (i.e., Gumstix selected as the target machine, etc..) and that
the xenomai options are properly configured as well (there should be a whole
section for xenomai and real-time options).


>
> I force the compilation:
>
> bitbake -f -c compile gumstix-kernel
>
> I saw that Adeos doesn't work in the final kernel. During the boot in
> simulation with Qemu, I've got this kind of messages:
>
> [...]
> <4>smc91x: Unknown symbol __ipipe_unstall_root
> <4>smc91x: Unknown symbol __ipipe_root_status
> <4>smc91x: Unknown symbol __ipipe_restore_root
> <4>smc911x: Unknown symbol __ipipe_root_status
> <4>smc911x: Unknown symbol __ipipe_restore_root
> <4>evdev: Unknown symbol __ipipe_unstall_root
> <4>evdev: Unknown symbol __ipipe_root_status
> <4>mmc_core: Unknown symbol __ipipe_root_status
> <4>mmc_core: Unknown symbol __ipipe_restore_root
> <4>mmc_block: Unknown symbol __ipipe_unstall_root
> <4>mmc_block: Unknown symbol __ipipe_root_status
> [...]
>
> I'm disappointed and I'm asking myself if don't need to add something to
> the recipe that manage the modules (i.e task-base-gumstix) ?
>
> Regards,
>

Well, try to patch it with the other version of Adeos. I never really worked
with Qemu, so I am not sure where the problem might be. I always generate a
new image for my gumstix (using the bitbake gumstix-basic-image -c
rebuild command,
as well as rebuilding task-base-gumstix) and flash it in order to do the
testing - however, Adeos is loaded way before any modules, so I doubt that
it has anything to do with that.

Anyway, try this out - if everything goes wrong, I can send you my own
kernel for testing, and I can take a quick look at your .config files to see
if there is anything wrong.

Hope this helps,
      -Felipe Brandão Cavalcanti
      LARA - Laboratory of Robotics and Automation
      Department of Electrical Engineering
      UnB - University of Brasília, Brazil
      http://www.lara.unb.br/

PS: Don't forget to send the messages to the list!

Felipe Brandão Cavalcanti <cavalkaf@domain.hid> a écrit :
>
>  Well, I did have a few issues with the initial kernel config - what I did
>> to
>> get the kernel working was to copy the original (i.e., the one that came
>> with the Gumstix) defconfig file to the working directory (IIRC,
>> ~/gumstix/gumstix-oe/tmp/work/....) as .config BEFORE running the command
>> bitbake -c menuconfig gumstix-kernel. This will give you the default
>> gumstix
>> config to start off the kernel customization procedure.
>> After getting everything set up (including the removal of several features
>> witch you might not really need - the kernel needs to be less than 1 Mb),
>> I
>> copied the new .config over to the defconfig file. Than I just went on to
>> compile the kernel as usual (however, my bitbake recipe does have a few
>> modifications to auto-patch adeos into the kernel).
>>
>> BTW, keep in mind that you also need to install the xenomai userspace
>> packages, that will take up around 7 Mb in your system.
>>
>> I will be happy to help if you have any other specific questions - I have
>> a
>> fully custom gumstix distribution with Xenomai (it is a work in progress,
>> but it does seem to work fine at the moment), with a working kernel and
>> xenomai packages (stripped-out, no documentation, etc...) I would also be
>> happy to receive any interesting info on this area (any new solutions,
>> etc)
>> - not many people seem to be using the gumstix platform for
>> real-time purposes, but it seems like an excellent choice. I do plan on
>> organizing all of this information sooner or later on a webpage (the last
>> step of my project involves porting the OROCOS plataform over to the
>> XScale
>> processor, and than getting it working on the gumstix - after thats done,
>> I
>> will document the entire process).
>>
>> Hope this helps!
>>        -Felipe Brandão Cavalcanti
>>        LARA - Laboratory of Robotics and Automation
>>        Department of Electrical Engineering
>>        UnB - University of Brasília, Brazil
>>        http://www.lara.unb.br/
>>
>> On Mon, Jan 12, 2009 at 8:14 AM, Gilles Chanteperdrix <
>> gilles.chanteperdrix@xenomai.org> wrote:
>>
>>  Sebastien.Berruer@domain.hid wrote:
>>> > Hi,
>>> >
>>> > I'm a student and I work on a project to get Xenomai running on a
>>> > gumstix platform. I'm using a Verdex board and OpenEmbedded as my
>>> > development environment. Prior to re-flashing the board, I'm testing
>>> > the RAM image with Qemu.
>>> >
>>> > I've patched the kernel with Adeos. I followed the instruction of
>>> > Xenomai 2.4.3 for a linux kernel 2.6.24.
>>>
>>> Please use the latest version from the 2.4 (stable) branch: Xenomai
>>> 2.4.6.1.
>>>
>>> >
>>> > I've been careful to run the command :
>>> > bitbake gumstix-kernel -c menuconfig
>>> > to force the copy of
>>> >
>>>
>>> ~/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.24-r1/linux-2.6.24/.config
>>> > to
>>> >
>>>
>>> ~/gumstix/gumstix-oe/user.collection/packages/linux/gumstix-kernel-2.6.24/gumstix-custom-verdex/defconfig
>>> >
>>> > Then, I tried to recompile the kernel source code (without that
>>> > bitbake unpacked the archive of the previous version)
>>> > bitbake gumstix-kernel -f -c compile
>>> >
>>> > And create the new images
>>> > bitbake task-base-gumstix -c rebuild
>>> > bitbake gumstix-basic-image -c rebuild
>>> >
>>> > I've made an image of RAM with the dd command to run in Qemu. But,
>>> > when I'm trying to boot this image, the boot stop and said me :
>>> > Copying kernel to 0xa2000000 from 0x01f00000 (length 0x00100000)...done
>>> > ## Booting image at a2000000 ...
>>> >      Image Name:   Angstrom/2.6.24/gumstix-custom-v
>>> >      Image Type:   ARM Linux Kernel Image (uncompressed)
>>> >      Data Size:    1124960 Bytes =  1.1 MB
>>> >      Load Address: a0008000
>>> >      Entry Point:  a0008000
>>> > OK
>>> >
>>> > Starting kernel ...
>>> >
>>> > ran out of input data
>>>
>>> It looks like a memory layout issue, such as the bootloader not copying
>>> the kernel completely, or the places where the kernel is copied
>>> overlapping with something else like an initrd.
>>>
>>>
>>> --
>>>                                                 Gilles.
>>>
>>> _______________________________________________
>>> Xenomai-help mailing list
>>> Xenomai-help@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-help
>>>
>>>
>>
>
> |=============================================================|
> | BERRUER Sébastien        |                                  |
> | 2 rue du Vieil Armand    | Tel : 06-76-35-29-55             |
> | Studio 112               | Email : sberruer@domain.hid     |
> | 67100 STRASBOURG         |                                  |
> |=============================================================|
>

[-- Attachment #2: Type: text/html, Size: 12911 bytes --]

[Xenomai-help] Xenomai on Gumstix

[Sebastien.Berruer]

Hi,

I'm a student and I work on a project to get Xenomai running on a
gumstix platform. I'm using a Verdex board and OpenEmbedded as my
development environment. Prior to re-flashing the board, I'm testing
the RAM image with Qemu.

I've patched the kernel with Adeos. I followed the instruction of
Xenomai 2.4.3 for a linux kernel 2.6.24.

I've been careful to run the command :
bitbake gumstix-kernel -c menuconfig
to force the copy of
~/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.24-r1/linux-2.6.24/.config
to
~/gumstix/gumstix-oe/user.collection/packages/linux/gumstix-kernel-2.6.24/gumstix-custom-verdex/defconfig

Then, I tried to recompile the kernel source code (without that
bitbake unpacked the archive of the previous version)
bitbake gumstix-kernel -f -c compile

And create the new images
bitbake task-base-gumstix -c rebuild
bitbake gumstix-basic-image -c rebuild

I've made an image of RAM with the dd command to run in Qemu. But,
when I'm trying to boot this image, the boot stop and said me :
Copying kernel to 0xa2000000 from 0x01f00000 (length 0x00100000)...done
## Booting image at a2000000 ...
     Image Name:   Angstrom/2.6.24/gumstix-custom-v
     Image Type:   ARM Linux Kernel Image (uncompressed)
     Data Size:    1124960 Bytes =  1.1 MB
     Load Address: a0008000
     Entry Point:  a0008000
OK

Starting kernel ...

ran out of input data

   -- System halted

I've seen in previous threads the experience from Felipe Brandão
Cavalcanti. This thread shows that it's possible to get an operational
system on this platform. Can I hope some specific help ?

Best regards,

|=============================================================|
| BERRUER Sébastien        |                                  |
| 2 rue du Vieil Armand    | Tel : 06-76-35-29-55             |
| Studio 112               | Email : sberruer@domain.hid     |
| 67100 STRASBOURG         |                                  |
|=============================================================|

Re: [Xenomai-help] Xenomai on Gumstix

[Gilles Chanteperdrix]

Sebastien.Berruer@domain.hid wrote:
> Hi,
> 
> I'm a student and I work on a project to get Xenomai running on a
> gumstix platform. I'm using a Verdex board and OpenEmbedded as my
> development environment. Prior to re-flashing the board, I'm testing
> the RAM image with Qemu.
> 
> I've patched the kernel with Adeos. I followed the instruction of
> Xenomai 2.4.3 for a linux kernel 2.6.24.

Please use the latest version from the 2.4 (stable) branch: Xenomai 2.4.6.1.

> 
> I've been careful to run the command :
> bitbake gumstix-kernel -c menuconfig
> to force the copy of
> ~/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.24-r1/linux-2.6.24/.config
> to
> ~/gumstix/gumstix-oe/user.collection/packages/linux/gumstix-kernel-2.6.24/gumstix-custom-verdex/defconfig
> 
> Then, I tried to recompile the kernel source code (without that
> bitbake unpacked the archive of the previous version)
> bitbake gumstix-kernel -f -c compile
> 
> And create the new images
> bitbake task-base-gumstix -c rebuild
> bitbake gumstix-basic-image -c rebuild
> 
> I've made an image of RAM with the dd command to run in Qemu. But,
> when I'm trying to boot this image, the boot stop and said me :
> Copying kernel to 0xa2000000 from 0x01f00000 (length 0x00100000)...done
> ## Booting image at a2000000 ...
>      Image Name:   Angstrom/2.6.24/gumstix-custom-v
>      Image Type:   ARM Linux Kernel Image (uncompressed)
>      Data Size:    1124960 Bytes =  1.1 MB
>      Load Address: a0008000
>      Entry Point:  a0008000
> OK
> 
> Starting kernel ...
> 
> ran out of input data

It looks like a memory layout issue, such as the bootloader not copying
the kernel completely, or the places where the kernel is copied
overlapping with something else like an initrd.


-- 
                                                 Gilles.

Re: [Xenomai-help] Xenomai on Gumstix

[Felipe Brandão Cavalcanti]

[-- Attachment #1: Type: text/plain, Size: 4376 bytes --]

Well, I did have a few issues with the initial kernel config - what I did to
get the kernel working was to copy the original (i.e., the one that came
with the Gumstix) defconfig file to the working directory (IIRC,
~/gumstix/gumstix-oe/tmp/work/....) as .config BEFORE running the command
bitbake -c menuconfig gumstix-kernel. This will give you the default gumstix
config to start off the kernel customization procedure.
After getting everything set up (including the removal of several features
witch you might not really need - the kernel needs to be less than 1 Mb), I
copied the new .config over to the defconfig file. Than I just went on to
compile the kernel as usual (however, my bitbake recipe does have a few
modifications to auto-patch adeos into the kernel).

BTW, keep in mind that you also need to install the xenomai userspace
packages, that will take up around 7 Mb in your system.

I will be happy to help if you have any other specific questions - I have a
fully custom gumstix distribution with Xenomai (it is a work in progress,
but it does seem to work fine at the moment), with a working kernel and
xenomai packages (stripped-out, no documentation, etc...) I would also be
happy to receive any interesting info on this area (any new solutions, etc)
- not many people seem to be using the gumstix platform for
real-time purposes, but it seems like an excellent choice. I do plan on
organizing all of this information sooner or later on a webpage (the last
step of my project involves porting the OROCOS plataform over to the XScale
processor, and than getting it working on the gumstix - after thats done, I
will document the entire process).

Hope this helps!
        -Felipe Brandão Cavalcanti
        LARA - Laboratory of Robotics and Automation
        Department of Electrical Engineering
        UnB - University of Brasília, Brazil
        http://www.lara.unb.br/

On Mon, Jan 12, 2009 at 8:14 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Sebastien.Berruer@domain.hid wrote:
> > Hi,
> >
> > I'm a student and I work on a project to get Xenomai running on a
> > gumstix platform. I'm using a Verdex board and OpenEmbedded as my
> > development environment. Prior to re-flashing the board, I'm testing
> > the RAM image with Qemu.
> >
> > I've patched the kernel with Adeos. I followed the instruction of
> > Xenomai 2.4.3 for a linux kernel 2.6.24.
>
> Please use the latest version from the 2.4 (stable) branch: Xenomai
> 2.4.6.1.
>
> >
> > I've been careful to run the command :
> > bitbake gumstix-kernel -c menuconfig
> > to force the copy of
> >
> ~/gumstix/gumstix-oe/tmp/work/gumstix-custom-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.24-r1/linux-2.6.24/.config
> > to
> >
> ~/gumstix/gumstix-oe/user.collection/packages/linux/gumstix-kernel-2.6.24/gumstix-custom-verdex/defconfig
> >
> > Then, I tried to recompile the kernel source code (without that
> > bitbake unpacked the archive of the previous version)
> > bitbake gumstix-kernel -f -c compile
> >
> > And create the new images
> > bitbake task-base-gumstix -c rebuild
> > bitbake gumstix-basic-image -c rebuild
> >
> > I've made an image of RAM with the dd command to run in Qemu. But,
> > when I'm trying to boot this image, the boot stop and said me :
> > Copying kernel to 0xa2000000 from 0x01f00000 (length 0x00100000)...done
> > ## Booting image at a2000000 ...
> >      Image Name:   Angstrom/2.6.24/gumstix-custom-v
> >      Image Type:   ARM Linux Kernel Image (uncompressed)
> >      Data Size:    1124960 Bytes =  1.1 MB
> >      Load Address: a0008000
> >      Entry Point:  a0008000
> > OK
> >
> > Starting kernel ...
> >
> > ran out of input data
>
> It looks like a memory layout issue, such as the bootloader not copying
> the kernel completely, or the places where the kernel is copied
> overlapping with something else like an initrd.
>
>
> --
>                                                  Gilles.
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>



-- 
*º¤., ¸¸,.¤º*¨*¤., ¸¸,.¤º*¨*
Cavalkaf (aka Felipe) <cavalkaf@domain.hid>
AIM: Cavalkaf | MSN: cavalkaf2@domain.hid
Check out <http://www.flickr.com/photos/rbcav2003/>

[-- Attachment #2: Type: text/html, Size: 6132 bytes --]

Re: [Xenomai-help] Xenomai on Gumstix

[Gilles Chanteperdrix]

Felipe Brandão Cavalcanti wrote:
> (...)
> witch you might not really need - the kernel needs to be less than 1 Mb), I
> (...)

What is the point of imposing such a limit? The kernel itself has no
such limit.

-- 
                                                 Gilles.

Re: [Xenomai-help] Xenomai on Gumstix

[Felipe Brandão Cavalcanti]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]

The Gumstix has a separate 1 Mb partition for the kernel - it has something
to do with the bootloader and how it handles the kernel. I don't think
anyone has bothered to make a custom version with a different partition
scheme.

On Tue, Jan 13, 2009 at 12:41 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:

> Felipe Brandão Cavalcanti wrote:
> > (...)
> > witch you might not really need - the kernel needs to be less than 1 Mb),
> I
> > (...)
>
> What is the point of imposing such a limit? The kernel itself has no
> such limit.
>
> --
>                                                  Gilles.
>
>

[-- Attachment #2: Type: text/html, Size: 1191 bytes --]

Re: [Xenomai-help] Xenomai on Gumstix

[Gilles Chanteperdrix]

Felipe Brandão Cavalcanti wrote:
> The Gumstix has a separate 1 Mb partition for the kernel - it has something
> to do with the bootloader and how it handles the kernel. I don't think
> anyone has bothered to make a custom version with a different partition
> scheme.

A 1mb limitation will become harder and harder, kernels are growing bigger.

-- 
                                                 Gilles.