[Buildroot] [PATCH 1/3] buildroot: target: Add Blackfin architecture support in configuration.

[Buildroot] [PATCH 1/3] buildroot: target: Add Blackfin architecture support in configuration.

[Sonic Zhang]

From: Sonic Zhang <sonic.zhang@analog.com>

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
 target/Config.in.arch |   19 +++++++++++++++++++
 1 files changed, 19 insertions(+), 0 deletions(-)

diff --git a/target/Config.in.arch b/target/Config.in.arch
index 6eaa951..001faf0 100644
--- a/target/Config.in.arch
+++ b/target/Config.in.arch
@@ -131,6 +131,15 @@ config BR2_xtensa
 	  http://www.tensilica.com/
 endchoice
 
+config BR2_ABI_FLAT
+	bool
+	default n
+
+config BR2_ABI_ELF
+	bool
+	default y
+	depends on !BR2_ABI_FLAT
+
 config BR2_microblaze
 	bool
 	default y if BR2_microblazeel || BR2_microblazebe
@@ -231,8 +240,18 @@ choice
 	default BR2_BFIN_FDPIC
 config BR2_BFIN_FDPIC
 	bool "FDPIC"
+	select BR2_ABI_ELF
 config BR2_BFIN_FLAT
 	bool "FLAT"
+	select BR2_ABI_FLAT
+	select BR2_PREFER_STATIC_LIB
+config BR2_BFIN_FLAT_SEP_DATA
+	bool "FLAT (Separate data)"
+	select BR2_ABI_FLAT
+	select BR2_PREFER_STATIC_LIB
+config BR2_BFIN_SHARED_FLAT
+	bool "Shared FLAT"
+	select BR2_ABI_FLAT
 	select BR2_PREFER_STATIC_LIB
 endchoice
 
-- 
1.7.0.4

[Buildroot] [PATCH 2/2] buildroot:package: Avoids prefix absolute compiler path when external toolchain path is empty.

[Sonic Zhang]

From: Sonic Zhang <sonic.zhang@analog.com>

Current external compiler is always prefixed by he customer path.
When external toolchain path is left empty, this patch avoids prefix absolute path.

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
 package/Makefile.in |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/package/Makefile.in b/package/Makefile.in
index 6fad224..ecbdc00 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -101,8 +101,13 @@ TARGET_LDFLAGS=$(call qstrip,$(BR2_TARGET_LDFLAGS))
 ifeq ($(BR2_TOOLCHAIN_BUILDROOT)$(BR2_TOOLCHAIN_CTNG),y)
 TARGET_CROSS=$(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-
 else
+TOOLCHAIN_EXTERNAL_LOCATION=$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PATH))
+ifeq ($(TOOLCHAIN_EXTERNAL_LOCATION),)
+TARGET_CROSS=$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))-
+else
 TARGET_CROSS=$(HOST_DIR)/usr/bin/$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))-
 endif
+endif
 
 # Quotes are needed for spaces et al in path components.
 TARGET_PATH="$(HOST_DIR)/bin:$(HOST_DIR)/usr/bin:$(HOST_DIR)/usr/sbin/:$(PATH)"
-- 
1.7.0.4

[Buildroot] [PATCH 2/2] buildroot:package: Avoids prefix absolute compiler path when external toolchain path is empty.

[Thomas Petazzoni]

Le Mon, 6 Aug 2012 19:17:26 +0800,
Sonic Zhang <sonic.adi@gmail.com> a ?crit :

> From: Sonic Zhang <sonic.zhang@analog.com>
> 
> Current external compiler is always prefixed by he customer path.
> When external toolchain path is left empty, this patch avoids prefix absolute path.
> 
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
>  package/Makefile.in |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
> 
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 6fad224..ecbdc00 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -101,8 +101,13 @@ TARGET_LDFLAGS=$(call qstrip,$(BR2_TARGET_LDFLAGS))
>  ifeq ($(BR2_TOOLCHAIN_BUILDROOT)$(BR2_TOOLCHAIN_CTNG),y)
>  TARGET_CROSS=$(HOST_DIR)/usr/bin/$(GNU_TARGET_NAME)-
>  else
> +TOOLCHAIN_EXTERNAL_LOCATION=$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PATH))
> +ifeq ($(TOOLCHAIN_EXTERNAL_LOCATION),)
> +TARGET_CROSS=$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))-
> +else
>  TARGET_CROSS=$(HOST_DIR)/usr/bin/$(call qstrip,$(BR2_TOOLCHAIN_EXTERNAL_PREFIX))-
>  endif
> +endif

I am sorry but this is not correct. It will lead to packages calling
directly the compiler without going through our external toolchain
wrapper, which is mandatory to ensure that the correct sysroot (and
other flags) are passed correctly.

Passing an empty BR2_TOOLCHAIN_EXTERNAL_PATH works just fine for me if
the toolchain binaries are in the PATH.

Could you explain in more details what you are trying to achieve here?

Thanks,

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

[Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver when external toolchain is selected.

[Sonic Zhang]

From: Sonic Zhang <sonic.zhang@analog.com>

Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
 toolchain/gdb/Config.in |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
index fd6956b..8a440d8 100644
--- a/toolchain/gdb/Config.in
+++ b/toolchain/gdb/Config.in
@@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain"
 
 config BR2_PACKAGE_GDB_SERVER
 	bool "Build gdb server for the Target"
-	depends on !BR2_TOOLCHAIN_EXTERNAL
 	help
 	    Build the gdbserver stub to run on the target.
 	    A full gdb is needed to debug the progam.
 
 config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
 	bool "Copy gdb server to the Target"
-	depends on BR2_TOOLCHAIN_EXTERNAL
+	depends on BR2_TOOLCHAIN_EXTERNAL && !BR2_PACKAGE_GDB_SERVER
 	help
 	  Copy the gdbserver provided by the external toolchain to the
 	  target.
-- 
1.7.0.4

[Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver when external toolchain is selected.

[Thomas Petazzoni]

Le Mon, 6 Aug 2012 19:17:27 +0800,
Sonic Zhang <sonic.adi@gmail.com> a ?crit :

> From: Sonic Zhang <sonic.zhang@analog.com>
> 
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
>  toolchain/gdb/Config.in |    3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
> 
> diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
> index fd6956b..8a440d8 100644
> --- a/toolchain/gdb/Config.in
> +++ b/toolchain/gdb/Config.in
> @@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR support in toolchain"
>  
>  config BR2_PACKAGE_GDB_SERVER
>  	bool "Build gdb server for the Target"
> -	depends on !BR2_TOOLCHAIN_EXTERNAL
>  	help
>  	    Build the gdbserver stub to run on the target.
>  	    A full gdb is needed to debug the progam.
>  
>  config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
>  	bool "Copy gdb server to the Target"
> -	depends on BR2_TOOLCHAIN_EXTERNAL
> +	depends on BR2_TOOLCHAIN_EXTERNAL && !BR2_PACKAGE_GDB_SERVER
>  	help
>  	  Copy the gdbserver provided by the external toolchain to the
>  	  target.

Is this really a good idea? For compatibility reasons, we generally
want the gdbserver on the target to have the same version as the cross
gdb on the development machine. Therefore, in the external toolchain
case, it sounds like a really bad idea to let the user build its own
gdbserver instead of using the one of the external toolchain.

I know the Blackfin toolchains are not providing their own gdbserver
(but they provide a cross gdb), but in my opinion, it's a bug that
should be fixed in the build process of the Blackfin toolchains: they
should include their own gdbserver, just like the Linaro and Sourcery
CodeBench toolchains do.

Best regards,

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

[Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver when external toolchain is selected.

[Sonic Zhang]

On Tue, Aug 7, 2012 at 11:22 AM, Zhang, Sonic <Sonic.Zhang@analog.com> wrote:
> Hi Thomas,
>
>>-----Original Message-----
>>From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
>>Sent: Monday, August 06, 2012 8:55 PM
>>To: Sonic Zhang
>>Cc: Peter Korsgaard; buildroot at busybox.net; buildroot-devel at lackfin.uclinux.org;
>>Zhang, Sonic
>>Subject: Re: [Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver
>>when external toolchain is selected.
>>
>>Le Mon, 6 Aug 2012 19:17:27 +0800,
>>Sonic Zhang <sonic.adi@gmail.com> a ?crit :
>>
>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>
>>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>>> ---
>>>  toolchain/gdb/Config.in |    3 +--
>>>  1 files changed, 1 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/toolchain/gdb/Config.in b/toolchain/gdb/Config.in
>>> index fd6956b..8a440d8 100644
>>> --- a/toolchain/gdb/Config.in
>>> +++ b/toolchain/gdb/Config.in
>>> @@ -14,14 +14,13 @@ comment "Gdb debugger for the target needs WCHAR
>>support in toolchain"
>>>
>>>  config BR2_PACKAGE_GDB_SERVER
>>>      bool "Build gdb server for the Target"
>>> -    depends on !BR2_TOOLCHAIN_EXTERNAL
>>>      help
>>>          Build the gdbserver stub to run on the target.
>>>          A full gdb is needed to debug the progam.
>>>
>>>  config BR2_TOOLCHAIN_EXTERNAL_GDB_SERVER_COPY
>>>      bool "Copy gdb server to the Target"
>>> -    depends on BR2_TOOLCHAIN_EXTERNAL
>>> +    depends on BR2_TOOLCHAIN_EXTERNAL
>>&& !BR2_PACKAGE_GDB_SERVER
>>>      help
>>>        Copy the gdbserver provided by the external toolchain to the
>>>        target.
>>
>>Is this really a good idea? For compatibility reasons, we generally
>>want the gdbserver on the target to have the same version as the cross
>>gdb on the development machine. Therefore, in the external toolchain
>>case, it sounds like a really bad idea to let the user build its own
>>gdbserver instead of using the one of the external toolchain.
>>
>
> This is an option for developers who want to develop/debug gdb server or want to use an alternative version.
> The developer is responsible to ensure the compatibility.
>
>>I know the Blackfin toolchains are not providing their own gdbserver
>>(but they provide a cross gdb), but in my opinion, it's a bug that
>>should be fixed in the build process of the Blackfin toolchains: they
>>should include their own gdbserver, just like the Linaro and Sourcery
>>CodeBench toolchains do.
>>
>
> I include ADI blackfin GNU toolchain developer Stuart for your question.
>

Because Stuart is out these days, I cc David as well.

Regards,

Sonic

[Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver when external toolchain is selected.

[Thomas Petazzoni]

Hello,

Le Wed, 8 Aug 2012 17:29:20 +0100,
"Henderson, Stuart" <Stuart.Henderson@analog.com> a ?crit :

> Since Sonic's linux distro has gdbserver built into it anyway (built
> using the appropriate version of the toolchain), I don't think
> providing gdbserver in the toolchain as well would provide any
> particular benefit to the end user.  Is there a scenario where having
> gdbserver in the toolchain is going to help the user?  I'd happily
> introduce it, if so.

Well, my personal experience (and I've heard this experience from
several other people has well) is that to avoid problems the gdbserver
version you're using should be the same as the cross-gdb used to
connect to this gdbserver. Therefore, it makes sense for a toolchain to
provide both cross-gdb *and* gdbserver, or none of them, but it doesn't
make much sense to offer just cross-gdb without a gdbserver. As I was
mentioning before, Linaro toolchains, Sourcery CodeBench toolchains do
that.

Best regards,

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

[Buildroot] [PATCH 3/3] buildroot: toolchain: Allow to build gdbserver when external toolchain is selected.

[Thomas Petazzoni]

Hello,

Le Tue, 14 Aug 2012 12:06:38 +0100,
"Henderson, Stuart" <Stuart.Henderson@analog.com> a ?crit :

> >Well, my personal experience (and I've heard this experience from several other people has well)
> >is that to avoid problems the gdbserver version you're using should be the same as the cross-gdb
> >used to connect to this gdbserver. Therefore, it makes sense for a toolchain to provide both cross-gdb
> >*and* gdbserver, or none of them, but it doesn't make much sense to offer just cross-gdb without a
> >gdbserver. As I was mentioning before, Linaro toolchains, Sourcery CodeBench toolchains do that.
> 
> This seems reasonable, however we only support matching releases of the toolchain/u-boot/linux, so the result is much the same.
> i.e. The 2012R1 release of the toolchain is used to build the 2012R1 release of u-boot and linux.  The latter of which contains the correct version of gdbserver for the 2012R1 release of the toolchain.

I am not sure to understand: why would gdbserver be part of your
"linux" release? Linux is the kernel, was does it has to do with
gdbserver.

> However, like I said, I certainly don't have any strong objections to having gdbserver in the toolchain package as well.  I'll take a look at how other people package it and see what Sonic's thoughts are on it when we're doing the next release.

Ok, thanks!

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

[Buildroot] [PATCH 1/3] buildroot: target: Add Blackfin architecture support in configuration.

[Thomas Petazzoni]

Hello,

Le Mon, 6 Aug 2012 19:17:25 +0800,
Sonic Zhang <sonic.adi@gmail.com> a ?crit :

> From: Sonic Zhang <sonic.zhang@analog.com>
> 
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> ---
>  target/Config.in.arch |   19 +++++++++++++++++++
>  1 files changed, 19 insertions(+), 0 deletions(-)
> 
> diff --git a/target/Config.in.arch b/target/Config.in.arch
> index 6eaa951..001faf0 100644
> --- a/target/Config.in.arch
> +++ b/target/Config.in.arch
> @@ -131,6 +131,15 @@ config BR2_xtensa
>  	  http://www.tensilica.com/
>  endchoice
>  
> +config BR2_ABI_FLAT
> +	bool
> +	default n
> +
> +config BR2_ABI_ELF
> +	bool
> +	default y
> +	depends on !BR2_ABI_FLAT

Could you expand a bit on why this is needed, and where it will be
used? I have seen those used in various places in some of your packages
in your Git repository, but I am not sure the use cases were actually
valid.

>  config BR2_microblaze
>  	bool
>  	default y if BR2_microblazeel || BR2_microblazebe
> @@ -231,8 +240,18 @@ choice
>  	default BR2_BFIN_FDPIC
>  config BR2_BFIN_FDPIC
>  	bool "FDPIC"
> +	select BR2_ABI_ELF
>  config BR2_BFIN_FLAT
>  	bool "FLAT"
> +	select BR2_ABI_FLAT
> +	select BR2_PREFER_STATIC_LIB
> +config BR2_BFIN_FLAT_SEP_DATA
> +	bool "FLAT (Separate data)"
> +	select BR2_ABI_FLAT
> +	select BR2_PREFER_STATIC_LIB
> +config BR2_BFIN_SHARED_FLAT
> +	bool "Shared FLAT"
> +	select BR2_ABI_FLAT
>  	select BR2_PREFER_STATIC_LIB
>  endchoice

Are these "FLAT (Separate data)" and "Shared FLAT" use cases actually
used in practice by people? I'm not a Blackfin expert, so I don't know
what's used in the field.

Thanks!

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

[Buildroot] [PATCH 1/3] buildroot: target: Add Blackfin architecture support in configuration.

[Sonic Zhang]

On Tue, Aug 7, 2012 at 11:14 AM, Zhang, Sonic <Sonic.Zhang@analog.com> wrote:
> Hi Thomas,
>
>>-----Original Message-----
>>From: Thomas Petazzoni [mailto:thomas.petazzoni at free-electrons.com]
>>Sent: Monday, August 06, 2012 8:36 PM
>>To: Sonic Zhang
>>Cc: Peter Korsgaard; buildroot at busybox.net; buildroot-devel at lackfin.uclinux.org;
>>Zhang, Sonic
>>Subject: Re: [PATCH 1/3] buildroot: target: Add Blackfin architecture support in
>>configuration.
>>
>>Hello,
>>
>>Le Mon, 6 Aug 2012 19:17:25 +0800,
>>Sonic Zhang <sonic.adi@gmail.com> a ?crit :
>>
>>> From: Sonic Zhang <sonic.zhang@analog.com>
>>>
>>> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
>>> ---
>>>  target/Config.in.arch |   19 +++++++++++++++++++
>>>  1 files changed, 19 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/target/Config.in.arch b/target/Config.in.arch
>>> index 6eaa951..001faf0 100644
>>> --- a/target/Config.in.arch
>>> +++ b/target/Config.in.arch
>>> @@ -131,6 +131,15 @@ config BR2_xtensa
>>>        http://www.tensilica.com/
>>>  endchoice
>>>
>>> +config BR2_ABI_FLAT
>>> +    bool
>>> +    default n
>>> +
>>> +config BR2_ABI_ELF
>>> +    bool
>>> +    default y
>>> +    depends on !BR2_ABI_FLAT
>>
>>Could you expand a bit on why this is needed, and where it will be
>>used? I have seen those used in various places in some of your packages
>>in your Git repository, but I am not sure the use cases were actually
>>valid.
>
> Blackfin toolchain support both the FLAT ABI and ELF(FDPIC) ABI. Some features are different between them, such as the default stack size. The default stack size of FLAT binary is only 4k bytes, while it is 128k for ELF binary. Although 4k is enough for most application, it may be too small for the others such as bonnie++. The flat to enlarge stack size "-Wl,-elf2flt=-s64000" only apply to FLAT toolchain with BF2_ABI_FLAT defined.
>
>
>>
>>>  config BR2_microblaze
>>>      bool
>>>      default y if BR2_microblazeel || BR2_microblazebe
>>> @@ -231,8 +240,18 @@ choice
>>>      default BR2_BFIN_FDPIC
>>>  config BR2_BFIN_FDPIC
>>>      bool "FDPIC"
>>> +    select BR2_ABI_ELF
>>>  config BR2_BFIN_FLAT
>>>      bool "FLAT"
>>> +    select BR2_ABI_FLAT
>>> +    select BR2_PREFER_STATIC_LIB
>>> +config BR2_BFIN_FLAT_SEP_DATA
>>> +    bool "FLAT (Separate data)"
>>> +    select BR2_ABI_FLAT
>>> +    select BR2_PREFER_STATIC_LIB
>>> +config BR2_BFIN_SHARED_FLAT
>>> +    bool "Shared FLAT"
>>> +    select BR2_ABI_FLAT
>>>      select BR2_PREFER_STATIC_LIB
>>>  endchoice
>>
>>Are these "FLAT (Separate data)" and "Shared FLAT" use cases actually
>>used in practice by people? I'm not a Blackfin expert, so I don't know
>>what's used in the field.
>
> Though I don't know if our end customers use shared FLAT in their blackfin based products, we do support these binary formats in blackfin GNU toolchain and Linux distribution for years.

Because Stuart is out these days, I cc David as well.

Regards,

Sonic