Patchwork [2/2,v3] xtensa: support configurable processor configurations

login
register
mail settings
Submitter Chris Zankel
Date Nov. 10, 2012, 12:20 a.m.
Message ID <509d9db2.4883440a.7065.016e@mx.google.com>
Download mbox | patch
Permalink /patch/198165/
State Superseded
Headers show

Comments

Chris Zankel - Nov. 10, 2012, 12:20 a.m.
Xtensa is a configurable processor architecture, which allows to define
additional instructions and registers. The required variant specific
information for the toolchain is delivered in an 'overlay' file, which
needs to be 'untarred' to the corresponding directories after the
source is installed and patched.
This patch provides support for binutils, gcc, and gdb with a very
limited changes to the build scripts. These additions are only executed
for the Xtensa architecture and have no effect on other architectures.

Signed-off-by: Chris Zankel <chris@zankel.net>
Arnout Vandecappelle - Nov. 10, 2012, 12:51 a.m.
On 11/10/12 01:20, Chris Zankel wrote:
> Xtensa is a configurable processor architecture, which allows to define
> additional instructions and registers. The required variant specific
> information for the toolchain is delivered in an 'overlay' file, which
> needs to be 'untarred' to the corresponding directories after the
> source is installed and patched.
> This patch provides support for binutils, gcc, and gdb with a very
> limited changes to the build scripts. These additions are only executed
> for the Xtensa architecture and have no effect on other architectures.
>
> Signed-off-by: Chris Zankel<chris@zankel.net>
>
> diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
> new file mode 100644
> index 0000000..61c0235
> --- /dev/null
> +++ b/arch/Config.in.xtensa
> @@ -0,0 +1,30 @@
> +choice
> +	prompt "Target ABI"
> +	depends on BR2_xtensa
> +	default BR2_xtensa_fsf
> +config BR2_xtensa_custom
> +	bool "Custom Xtensa processor configuration"
> +config BR2_xtensa_fsf
> +	bool "fsf - Default configuration"
> +endchoice

  Put empty lines between the different config options.

  All config names should be in capitals - the only exception is the
arch name itself (i.e. BR2_xtensa, but BR2_XTENSA_FSF).

> +
> +config BR2_xtensa_custom_name
> +	string "Custom Xtensa processor configuration anme"

  anme -> name

> +	depends on BR2_xtensa_custom
> +	default ""
> +	help
> +	  Name given to a custom Xtensa processor configuration.
> +
> +config BR2_xtensa_core_name
> +	string
> +	default BR2_xtensa_custom_name	if BR2_xtensa_custom
> +	default ""			if BR2_xtensa_fsf

  Minor detail: missing "depends on BR2_xtensa".

  Perhaps it's better to move the condition to a
if BR2_xtensa
...
endif
around the entire file.  Thomas has a patch lined up to move all
the conditions outside of the Config.in.*

> +
> +config BR2_xtensa_overlay_dir
> +	string "Overlay directory for custom configuration"
> +	depends on BR2_xtensa_custom
> +	default ""
> +	help
> +	  Provide a directory path that contains the overlay files
> +	  for the custom configuration. The path is based on the
> +	  buildroot top directory.

  based on -> relative to

  I don't find this explanation sufficient. First of all, it should
mention that that directory should contain tar files. Second, it
would help if you could explain where the tar files are supposed
to come from (I guess they're generated by some Xtensa tool).


  Regards,
  Arnout

[snip]
Chris Zankel - Nov. 12, 2012, 9:28 p.m.
Hi Arnout,

On 11/09/2012 04:51 PM, Arnout Vandecappelle wrote:
> On 11/10/12 01:20, Chris Zankel wrote:
>> +config BR2_xtensa_custom
>> +	bool "Custom Xtensa processor configuration"
>> +config BR2_xtensa_fsf
>> +	bool "fsf - Default configuration"
>> +endchoice
>   Put empty lines between the different config options.
Done.
>   All config names should be in capitals - the only exception is the
> arch name itself (i.e. BR2_xtensa, but BR2_XTENSA_FSF).
To give you some background, 'fsf' describes the default configuration
used in the various toolchain packages (gcc, buildroot, etc.). The idea
is to append the name of the processor configuration (for example,
dc232b), so to follow other architectures, I think it would be best to
keep lower-case for processor names, and upper case for other options.

For the case above, it would look like this:

config BR_XTENSA_CUSTOM
...

config BR_xtensa_fsf
...

config BR_xtensa_dc232b
...

etc.

I actually think that this makes a nice distinction between processor
names and buildroot configuration options.


>> +
>> +config BR2_xtensa_custom_name
>> +	string "Custom Xtensa processor configuration anme"
>   anme -> name
Done
>
>> +	depends on BR2_xtensa_custom
>> +	default ""
>> +	help
>> +	  Name given to a custom Xtensa processor configuration.
>> +
>> +config BR2_xtensa_core_name
>> +	string
>> +	default BR2_xtensa_custom_name	if BR2_xtensa_custom
>> +	default ""			if BR2_xtensa_fsf
>   Minor detail: missing "depends on BR2_xtensa".
Done.
>   Perhaps it's better to move the condition to a
> if BR2_xtensa
> ...
> endif
> around the entire file.  Thomas has a patch lined up to move all
> the conditions outside of the Config.in.*
It seems Xtensa would be the only one that uses that scheme, so maybe
wait for the generic patch from Thomas?

>> +
>> +config BR2_xtensa_overlay_dir
>> +	string "Overlay directory for custom configuration"
>> +	depends on BR2_xtensa_custom
>> +	default ""
>> +	help
>> +	  Provide a directory path that contains the overlay files
>> +	  for the custom configuration. The path is based on the
>> +	  buildroot top directory.
>   based on -> relative to
>
>   I don't find this explanation sufficient. First of all, it should
> mention that that directory should contain tar files. Second, it
> would help if you could explain where the tar files are supposed
> to come from (I guess they're generated by some Xtensa tool).
Made some additions, and will send a new set of patches in a bit...

-Chris
Arnout Vandecappelle - Nov. 12, 2012, 9:33 p.m.
On 11/12/12 22:28, Chris Zankel wrote:
> Hi Arnout,
>
> On 11/09/2012 04:51 PM, Arnout Vandecappelle wrote:
>> On 11/10/12 01:20, Chris Zankel wrote:
>>> +config BR2_xtensa_custom
>>> +	bool "Custom Xtensa processor configuration"
>>> +config BR2_xtensa_fsf
>>> +	bool "fsf - Default configuration"
>>> +endchoice
>>    Put empty lines between the different config options.
> Done.
>>    All config names should be in capitals - the only exception is the
>> arch name itself (i.e. BR2_xtensa, but BR2_XTENSA_FSF).
> To give you some background, 'fsf' describes the default configuration
> used in the various toolchain packages (gcc, buildroot, etc.). The idea
> is to append the name of the processor configuration (for example,
> dc232b), so to follow other architectures, I think it would be best to
> keep lower-case for processor names, and upper case for other options.
>
> For the case above, it would look like this:
>
> config BR_XTENSA_CUSTOM
> ...
>
> config BR_xtensa_fsf
> ...
>
> config BR_xtensa_dc232b
> ...
>
> etc.
>
> I actually think that this makes a nice distinction between processor
> names and buildroot configuration options.

  ACK good point.

>
>
>>> +
>>> +config BR2_xtensa_custom_name
>>> +	string "Custom Xtensa processor configuration anme"
>>    anme ->  name
> Done
>>
>>> +	depends on BR2_xtensa_custom
>>> +	default ""
>>> +	help
>>> +	  Name given to a custom Xtensa processor configuration.
>>> +
>>> +config BR2_xtensa_core_name
>>> +	string
>>> +	default BR2_xtensa_custom_name	if BR2_xtensa_custom
>>> +	default ""			if BR2_xtensa_fsf
>>    Minor detail: missing "depends on BR2_xtensa".
> Done.
>>    Perhaps it's better to move the condition to a
>> if BR2_xtensa
>> ...
>> endif
>> around the entire file.  Thomas has a patch lined up to move all
>> the conditions outside of the Config.in.*
> It seems Xtensa would be the only one that uses that scheme, so maybe
> wait for the generic patch from Thomas?

  I don't think so. Then it means more work for Thomas to refresh his
patch.  There will be a merge conflict anyway between the two, but
with the condition outside the file the conflict will be small.

  That said, Peter hasn't merged Thomas's patch even though I acked
it, so maybe he has some fundamental objection to the principle.
Or maybe it's just because I didn't test it.

  Bottom line: this issue won't stop my ack.

[snip]

  Regards,
  Arnout
Chris Zankel - Nov. 12, 2012, 11:45 p.m.
On 11/12/2012 01:33 PM, Arnout Vandecappelle wrote:
>
>    Perhaps it's better to move the condition to a
> if BR2_xtensa
> ...
> endif
> around the entire file.  Thomas has a patch lined up to move all
> the conditions outside of the Config.in.*
>> It seems Xtensa would be the only one that uses that scheme, so maybe
>> wait for the generic patch from Thomas?
>   I don't think so. Then it means more work for Thomas to refresh his
> patch.  There will be a merge conflict anyway between the two, but
> with the condition outside the file the conflict will be small.
>
>   That said, Peter hasn't merged Thomas's patch even though I acked
> it, so maybe he has some fundamental objection to the principle.
> Or maybe it's just because I didn't test it.
I guess I don't understand what that patch does, i.e. where is the
'if...endif'? Could you maybe point to the patch?

Thanks,
-Chris
Arnout Vandecappelle - Nov. 13, 2012, 8:29 p.m.
On 13/11/12 00:45, Chris Zankel wrote:
> On 11/12/2012 01:33 PM, Arnout Vandecappelle wrote:
>>
>>     Perhaps it's better to move the condition to a
>> if BR2_xtensa
>> ...
>> endif
>> around the entire file.  Thomas has a patch lined up to move all
>> the conditions outside of the Config.in.*
>>> It seems Xtensa would be the only one that uses that scheme, so maybe
>>> wait for the generic patch from Thomas?
>>    I don't think so. Then it means more work for Thomas to refresh his
>> patch.  There will be a merge conflict anyway between the two, but
>> with the condition outside the file the conflict will be small.
>>
>>    That said, Peter hasn't merged Thomas's patch even though I acked
>> it, so maybe he has some fundamental objection to the principle.
>> Or maybe it's just because I didn't test it.

> I guess I don't understand what that patch does, i.e. where is the
> 'if...endif'? Could you maybe point to the patch?

  I'm talking about http://patchwork.ozlabs.org/patch/196916/
In arch/Config.in, it introduces the following construct:

if BR2_xtensa
source "arch/Config.in.xtensa"
endif

  This removes the need for adding 'depend on BR2_xtensa' in every config
option in that file.

  It's true that _now_ xtensa would be the only one using that scheme, but the
idea is that if you do that for xtensa now, it will be easier to merge in
Thomas's patch later (or vice versa, it will be easier to rebase your patch
once Thomas's patch gets merged).

  Regards,
  Arnout
Chris Zankel - Nov. 13, 2012, 9:01 p.m.
Hi Arnout,

Sorry, I got your email after I sent out version 4 of the patch, which
doesn't include the change you mentioned (somehow, fetchmail was stuck
:-( So, please let me know if you want me to send out another version
that includes that change. I don't want to confuse Thomas with all those
versions...

Thanks,
-Chris



On 11/13/2012 12:29 PM, Arnout Vandecappelle wrote:
>> I guess I don't understand what that patch does, i.e. where is the
>> 'if...endif'? Could you maybe point to the patch?
>   I'm talking about http://patchwork.ozlabs.org/patch/196916/
> In arch/Config.in, it introduces the following construct:
>
> if BR2_xtensa
> source "arch/Config.in.xtensa"
> endif
>
>   This removes the need for adding 'depend on BR2_xtensa' in every config
> option in that file.
>
>   It's true that _now_ xtensa would be the only one using that scheme, but the
> idea is that if you do that for xtensa now, it will be easier to merge in
> Thomas's patch later (or vice versa, it will be easier to rebase your patch
> once Thomas's patch gets merged).
Thomas Petazzoni - Nov. 13, 2012, 9:44 p.m.
Chris,

On Tue, 13 Nov 2012 13:01:03 -0800, Chris Zankel wrote:

> Sorry, I got your email after I sent out version 4 of the patch, which
> doesn't include the change you mentioned (somehow, fetchmail was stuck
> :-( So, please let me know if you want me to send out another version
> that includes that change. I don't want to confuse Thomas with all
> those versions...

You can keep your patch as is wrt to Config.in. What I propose to do is
that I merge your Xtensa support in one of my branch together with my
reorganization of the architecture definitions and I send a
pull-request for the whole thing to Peter.

Would that be OK for you?

Thanks,

Thomas
Chris Zankel - Nov. 13, 2012, 9:54 p.m.
Hi Thomas,

On 11/13/2012 01:44 PM, Thomas Petazzoni wrote:
> Chris,
>
> On Tue, 13 Nov 2012 13:01:03 -0800, Chris Zankel wrote:
>
>> Sorry, I got your email after I sent out version 4 of the patch, which
>> doesn't include the change you mentioned (somehow, fetchmail was stuck
>> :-( So, please let me know if you want me to send out another version
>> that includes that change. I don't want to confuse Thomas with all
>> those versions...
> You can keep your patch as is wrt to Config.in. What I propose to do is
> that I merge your Xtensa support in one of my branch together with my
> reorganization of the architecture definitions and I send a
> pull-request for the whole thing to Peter.
>
> Would that be OK for you?
That would be great! Could you please use v4 of the two patches as they
include changes suggested by Arnout.

Thanks,
-Chris

Patch

diff --git a/arch/Config.in.xtensa b/arch/Config.in.xtensa
new file mode 100644
index 0000000..61c0235
--- /dev/null
+++ b/arch/Config.in.xtensa
@@ -0,0 +1,30 @@ 
+choice
+	prompt "Target ABI"
+	depends on BR2_xtensa
+	default BR2_xtensa_fsf
+config BR2_xtensa_custom
+	bool "Custom Xtensa processor configuration"
+config BR2_xtensa_fsf
+	bool "fsf - Default configuration"
+endchoice
+
+config BR2_xtensa_custom_name
+	string "Custom Xtensa processor configuration anme"
+	depends on BR2_xtensa_custom
+	default ""
+	help
+	  Name given to a custom Xtensa processor configuration.
+
+config BR2_xtensa_core_name
+	string
+	default BR2_xtensa_custom_name	if BR2_xtensa_custom
+	default ""			if BR2_xtensa_fsf
+
+config BR2_xtensa_overlay_dir
+	string "Overlay directory for custom configuration"
+	depends on BR2_xtensa_custom
+	default ""
+	help
+	  Provide a directory path that contains the overlay files
+	  for the custom configuration. The path is based on the
+	  buildroot top directory.
diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index e1aac9b..0c69cb5 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -66,5 +66,14 @@  define BINUTILS_INSTALL_TARGET_CMDS
 endef
 endif
 
+XTENSA_CORE_NAME = $(call qstrip, $(BR2_xtensa_core_name))
+ifneq ($(XTENSA_CORE_NAME),)
+define BINUTILS_XTENSA_PRE_PATCH
+	tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(XTENSA_CORE_NAME).tar \
+		-C $(@D) bfd include ld
+endef
+HOST_BINUTILS_PRE_PATCH_HOOKS += BINUTILS_XTENSA_PRE_PATCH
+endif
+
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))
diff --git a/toolchain/gcc/gcc-uclibc-4.x.mk b/toolchain/gcc/gcc-uclibc-4.x.mk
index 1a075cc..1710070 100644
--- a/toolchain/gcc/gcc-uclibc-4.x.mk
+++ b/toolchain/gcc/gcc-uclibc-4.x.mk
@@ -251,6 +251,10 @@  $(GCC_DIR)/.unpacked: $(DL_DIR)/$(GCC_SOURCE)
 	rm -rf $(GCC_DIR)
 	$(GCC_CAT) $(DL_DIR)/$(GCC_SOURCE) | tar -C $(TOOLCHAIN_DIR) $(TAR_OPTIONS) -
 	$(call CONFIG_UPDATE,$(@D))
+ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
+	tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip,\
+		$(BR2_xtensa_core_name)).tar -C $(@D) include
+endif
 	touch $@
 
 gcc-patched: $(GCC_DIR)/.patched
diff --git a/toolchain/gdb/gdb.mk b/toolchain/gdb/gdb.mk
index 6b029a8..dc305a6 100644
--- a/toolchain/gdb/gdb.mk
+++ b/toolchain/gdb/gdb.mk
@@ -25,6 +25,10 @@  gdb-unpacked: $(GDB_DIR)/.unpacked
 $(GDB_DIR)/.unpacked: $(DL_DIR)/$(GDB_SOURCE)
 	mkdir -p $(GDB_DIR)
 	$(GDB_CAT) $(DL_DIR)/$(GDB_SOURCE) | tar -C $(GDB_DIR) $(TAR_STRIP_COMPONENTS)=1 $(TAR_OPTIONS) -
+ifneq ($(call qstrip, $(BR2_xtensa_core_name)),)
+	tar xf $(BR2_xtensa_overlay_dir)/xtensa_$(call qstrip, \
+		$(BR2_xtensa_core_name)).tar -C $(@D) bfd include gdb
+endif
 ifneq ($(wildcard $(GDB_PATCH_DIR)),)
 	support/scripts/apply-patches.sh $(GDB_DIR) $(GDB_PATCH_DIR) \*.patch
 endif