[Buildroot] Xtensa in the autobuilders, first build failures

[Buildroot] Xtensa in the autobuilders, first build failures

[Thomas Petazzoni]

Hello Chris,

As you have probably noticed, we merged your Xtensa support in
Buildroot a few days ago. I'm really happy that your patches came in,
as it means that the removal of the Xtensa architecture will not be
visible (we removed it during this development cycle, and later
re-introduced it thanks to your patches).

I have also added one Xtensa toolchain configuration in our
autobuilder, and we are therefore starting to see a few Xtensa-related
build issues. Note that this is not at all a blocking issue for now:
when a new architecture is introduced, we expect to have build
failures. I'm listing below the failures we had, in case you have some
time to look at them:

 * Failure to build gdbserver for the target, and gdb for the target as
   well, both for the same reason: PTRACE_GETXTREGS and
   PTRACE_SETXTREGS are not defined by the kernel headers apparently.
   I'm not sure if they are just missing from the kernel headers, of
   the ptrace support is missing in the kernel. See:

   http://autobuild.buildroot.org/results/1d2f307b2aa59bebca3bcb9ea854839f4b1d14fb/build-end.log
   http://autobuild.buildroot.org/results/ec58e302030b8f72b19e9bada16dabb076c60261/build-end.log

   It would be nice if you could have a look at this.

 * Xtensa apparently does not have libffi support. However, it is quite
   a bit of work to get libffi support, so maybe we should just mark
   libffi as not available on Xtensa (which is quite annoying because
   libffi is a dependency for a huge number of packages, but we have
   the same problem with other architectures as well). See:

   http://autobuild.buildroot.org/results/e097c27d38e49d4bf4e07f95c52e995709c08aa8/build-end.log

Besides those issues, I'm just reminding you that we are still very
interested in having a Qemu Xtensa configuration to be able to run the
Xtensa systems we generate with Buildroot.

Thanks a lot!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Xtensa in the autobuilders, first build failures

[Chris Zankel]

Hi Thomas,

On 11/18/2012 02:25 PM, Thomas Petazzoni wrote:
> As you have probably noticed, we merged your Xtensa support in
> Buildroot a few days ago. I'm really happy that your patches came in,
> as it means that the removal of the Xtensa architecture will not be
> visible (we removed it during this development cycle, and later
> re-introduced it thanks to your patches).
Thanks

However, I noticed that it was not the most recent version where I
incorporated suggestions from Arnout, so will provide a small patch on
top of it.

> I have also added one Xtensa toolchain configuration in our
> autobuilder, and we are therefore starting to see a few Xtensa-related
> build issues. Note that this is not at all a blocking issue for now:
> when a new architecture is introduced, we expect to have build
> failures. I'm listing below the failures we had, in case you have some
> time to look at them:
>
>  * Failure to build gdbserver for the target, and gdb for the target as
>    well, both for the same reason: PTRACE_GETXTREGS and
>    PTRACE_SETXTREGS are not defined by the kernel headers apparently.
>    I'm not sure if they are just missing from the kernel headers, of
>    the ptrace support is missing in the kernel. See:
>
>    http://autobuild.buildroot.org/results/1d2f307b2aa59bebca3bcb9ea854839f4b1d14fb/build-end.log
>    http://autobuild.buildroot.org/results/ec58e302030b8f72b19e9bada16dabb076c60261/build-end.log
Yes, I do have a patch for gdb. There are actually two ways to fix it,
either in uClibc or gdb. I'm also working with Tensilica to get those
changes upstream, so I have to avoid providing additional patches.

>
>    It would be nice if you could have a look at this.
>
>  * Xtensa apparently does not have libffi support. However, it is quite
>    a bit of work to get libffi support, so maybe we should just mark
>    libffi as not available on Xtensa (which is quite annoying because
>    libffi is a dependency for a huge number of packages, but we have
>    the same problem with other architectures as well). See:
>
>    http://autobuild.buildroot.org/results/e097c27d38e49d4bf4e07f95c52e995709c08aa8/build-end.log
Thanks, I will look into it.

> Besides those issues, I'm just reminding you that we are still very
> interested in having a Qemu Xtensa configuration to be able to run the
> Xtensa systems we generate with Buildroot.
I'm juggling between kernel, uClibc, and buildroot, so, please allow me
some more time.


Regarding patches, should I send them to you and cc buildroot, or only
to the mailing list? What's the best path to get them looked at and
integrated into the tree?


Thanks,
-Chris

[Buildroot] Xtensa in the autobuilders, first build failures

[Thomas Petazzoni]

Dear Chris Zankel,

On Mon, 19 Nov 2012 13:45:50 -0800, Chris Zankel wrote:

> However, I noticed that it was not the most recent version where I
> incorporated suggestions from Arnout, so will provide a small patch on
> top of it.

Ah, sorry, my bad. Don't hesitate to send a follow-up patch that fixes
the remaining problems.

> >  * Failure to build gdbserver for the target, and gdb for the target as
> >    well, both for the same reason: PTRACE_GETXTREGS and
> >    PTRACE_SETXTREGS are not defined by the kernel headers apparently.
> >    I'm not sure if they are just missing from the kernel headers, of
> >    the ptrace support is missing in the kernel. See:
> >
> >    http://autobuild.buildroot.org/results/1d2f307b2aa59bebca3bcb9ea854839f4b1d14fb/build-end.log
> >    http://autobuild.buildroot.org/results/ec58e302030b8f72b19e9bada16dabb076c60261/build-end.log
> Yes, I do have a patch for gdb. There are actually two ways to fix it,
> either in uClibc or gdb. I'm also working with Tensilica to get those
> changes upstream, so I have to avoid providing additional patches.

Great!

> >    It would be nice if you could have a look at this.
> >
> >  * Xtensa apparently does not have libffi support. However, it is quite
> >    a bit of work to get libffi support, so maybe we should just mark
> >    libffi as not available on Xtensa (which is quite annoying because
> >    libffi is a dependency for a huge number of packages, but we have
> >    the same problem with other architectures as well). See:
> >
> >    http://autobuild.buildroot.org/results/e097c27d38e49d4bf4e07f95c52e995709c08aa8/build-end.log
> Thanks, I will look into it.

Adding support for one architecture in libffi is not very simple, so if
you don't need it for your own projects, I don't think you'll have the
energy to work on this. 

> > Besides those issues, I'm just reminding you that we are still very
> > interested in having a Qemu Xtensa configuration to be able to run the
> > Xtensa systems we generate with Buildroot.
> I'm juggling between kernel, uClibc, and buildroot, so, please allow me
> some more time.

Sure, no problem!

> Regarding patches, should I send them to you and cc buildroot, or only
> to the mailing list? What's the best path to get them looked at and
> integrated into the tree?

Just send them to the list. You can Cc: me as well if you want, but I'm
basically reading everything that goes on the Buildroot list, so I
should catch them even if you don't Cc: me.

Thanks again!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Xtensa in the autobuilders, first build failures

[Chris Zankel]

Hi Thomas,

On 11/19/2012 02:46 PM, Thomas Petazzoni wrote:
> On Mon, 19 Nov 2012 13:45:50 -0800, Chris Zankel wrote:
>
>> However, I noticed that it was not the most recent version where I
>> incorporated suggestions from Arnout, so will provide a small patch on
>> top of it.
> Ah, sorry, my bad. Don't hesitate to send a follow-up patch that fixes
> the remaining problems.
No worries, I think my email system wasn't working, so maybe you didn't
even get them.

I'm lining up a few patches, just running some more build tests (which
always take some time)

> Adding support for one architecture in libffi is not very simple, so if
> you don't need it for your own projects, I don't think you'll have the
> energy to work on this. 
You are right, it looks like some work, and it would be lower priority.
I'll just disable it for Xtensa for now.

>>> Besides those issues, I'm just reminding you that we are still very
>>> interested in having a Qemu Xtensa configuration to be able to run the
>>> Xtensa systems we generate with Buildroot.
>> I'm juggling between kernel, uClibc, and buildroot, so, please allow me
>> some more time.
> Sure, no problem!
How do you actually build qemu inside buildroot, or is this not
supported? I couldn't find any config option to enable it.
Also note that the current kernel version (3.6) doesn't have all
required patches, we are 'forward-focusing' at the moment, so things
will be easier in the future.

>> Regarding patches, should I send them to you and cc buildroot, or only
>> to the mailing list? What's the best path to get them looked at and
>> integrated into the tree?
> Just send them to the list. You can Cc: me as well if you want, but I'm
> basically reading everything that goes on the Buildroot list, so I
> should catch them even if you don't Cc: me.
Thanks. I'll keep them coming :-)

Cheers!
-Chris

[Buildroot] Xtensa in the autobuilders, first build failures

[Thomas Petazzoni]

Dear Chris Zankel,

On Tue, 20 Nov 2012 16:35:34 -0800, Chris Zankel wrote:

> > Ah, sorry, my bad. Don't hesitate to send a follow-up patch that
> > fixes the remaining problems.
> No worries, I think my email system wasn't working, so maybe you
> didn't even get them.

Yeah, after seeing your patch, I don't think I had seen those changes
before, but I may well have overlooked them.

> > Adding support for one architecture in libffi is not very simple,
> > so if you don't need it for your own projects, I don't think you'll
> > have the energy to work on this. 
> You are right, it looks like some work, and it would be lower
> priority. I'll just disable it for Xtensa for now.

Right, but as I replied, it's not that easy :)

> >>> Besides those issues, I'm just reminding you that we are still
> >>> very interested in having a Qemu Xtensa configuration to be able
> >>> to run the Xtensa systems we generate with Buildroot.
> >> I'm juggling between kernel, uClibc, and buildroot, so, please
> >> allow me some more time.
> > Sure, no problem!
> How do you actually build qemu inside buildroot, or is this not
> supported?

We have a host-qemu package, but it only builds the user-mode
emulation, and is not visible in menuconfig. For now, I think you can
just use the latest version of Qemu and compile it on your own. Unless
you have some time and want to extend the existing host-qemu package,
of course.

> I couldn't find any config option to enable it.
> Also note that the current kernel version (3.6) doesn't have all
> required patches, we are 'forward-focusing' at the moment, so things
> will be easier in the future.

That's a good strategy indeed. I don't mind if the Xtensa Qemu
defconfig currently points to a special Git tree for the kernel
sources, or if we have a few kernel patches in board/qemu/xtensa/, for
example.

Just let us what kernel version + patches, or kernel Git tree and we'll
figure out together how to make that fit into Buildroot.

> >> Regarding patches, should I send them to you and cc buildroot, or
> >> only to the mailing list? What's the best path to get them looked
> >> at and integrated into the tree?
> > Just send them to the list. You can Cc: me as well if you want, but
> > I'm basically reading everything that goes on the Buildroot list,
> > so I should catch them even if you don't Cc: me.
> Thanks. I'll keep them coming :-)

Seen them, the first two got applied, the last one about libffi is more
problematic.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com