| Message ID | 509d9db2.4883440a.7065.016e@mx.google.com |
|---|---|
| State | Superseded |
| Headers | show |
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]
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
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
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
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
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).
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
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
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
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>