any success with spartan6-lx9mb?

any success with spartan6-lx9mb?

[Trevor Woerner]

Hi,

I was playing around with the meta-xilinx layer and tried to build
"core-image-minimal" for the spartan6 without success. I was wondering
if anyone has tried this lately and/or if anyone has any tips to
suggest?

configuration:

I'm using the latest HEAD:
    BB_VERSION        = "1.15.3"
    TARGET_ARCH       = "microblaze"
    TARGET_OS         = "linux"
    MACHINE           = "spartan6-lx9mb"
    DISTRO            = "poky"
    DISTRO_VERSION    = "1.2+snapshot-20120904"
    TUNE_FEATURES     = "m32 microblazeel"
    TARGET_FPU        = "soft"
    meta
    meta-yocto        = "master:37c8597e7600385367257e8a513e003947ebef5b"
    meta-xilinx       = "master:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7"

conf/local.conf:
    BB_NUMBER_THREADS = "4"
    PARALLEL_MAKE = "-j 4"
    MACHINE ??= "spartan6-lx9mb"
    DL_DIR = "/home/trevor/devel/Downloads"
    DISTRO ?= "poky"
    PACKAGE_CLASSES ?= "package_rpm"
    EXTRA_IMAGE_FEATURES = "debug-tweaks"
    USER_CLASSES ?= "buildstats image-mklibs image-prelink"
    PATCHRESOLVE = "noop"
    CONF_VERSION = "1"

conf/bblayers.conf:
    LCONF_VERSION = "5"
    BBPATH = "${TOPDIR}"
    BBFILES ?= ""
    BBLAYERS ?= " \
      /home/trevor/devel/yocto/git-method/poky/meta \
      /home/trevor/devel/yocto/git-method/poky/meta-yocto \
      /home/trevor/devel/yocto/git-method/poky/meta-xilinx \
      "

issues:

The first problem I encountered was trying to build gcc-cross-initial:
    This target does not support --with-float.

I was able to get around this with the following (very silly) patch:
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc
b/meta/recipes-devtools/gcc/gcc-common.inc
index 72180db..cb3a8cf 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,8 +12,6 @@ FILESDIR = "${@os.path.dirname(d.getVar('FILE',1))}/gcc-${PV}"
 def get_gcc_fpu_setting(bb, d):
     if d.getVar('ARMPKGSFX_EABI', True) == "hf" and
d.getVar('TRANSLATED_TARGET_ARCH', True) == "arm":
         return "--with-float=hard"
-    if d.getVar('TARGET_FPU', True) in [ 'soft' ]:
-        return "--with-float=soft"
     if d.getVar('TARGET_FPU', True) in [ 'ppc-efd' ]:
         return "--enable-e500_double"
     return ""
-- 


Although I could get past this point, bitbaking again led to the
following problem with the same, gcc-cross-initial, recipe:

opening microblaze-c.o: No such file or directory
make[1]: *** [cc1-checksum.c] Error 1
rm cpp.pod gcov.pod gfdl.pod gcc.pod fsf-funding.pod
make[1]: Leaving directory
`/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/work/microblazeel-poky-linux/gcc-cross-initial-4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede-r11/gcc-4_7-branch/build.x86_64-linux.microblaze-poky-linux/gcc'
make: *** [all-gcc] Error 2
ERROR: oe_runmake failed
ERROR: Function failed: do_compile

Re: any success with spartan6-lx9mb?

[Elvis Dowson]

Hi,
        
On Sep 4, 2012, at 6:25 AM, Trevor Woerner wrote:

> I was playing around with the meta-xilinx layer and tried to build
> "core-image-minimal" for the spartan6 without success. I was wondering
> if anyone has tried this lately and/or if anyone has any tips to
> suggest?

Can you please list which version of the Xilinx ISE tools you are using? e.g. 12.4, 14.1, 14.2 ?

Could you also please list the Xilinx development board that you are using? e.g. SP601 (Spartan6) ?

> 
> configuration:
> 
> I'm using the latest HEAD:
>    BB_VERSION        = "1.15.3"
>    TARGET_ARCH       = "microblaze"
>    TARGET_OS         = "linux"
>    MACHINE           = "spartan6-lx9mb"
>    DISTRO            = "poky"
>    DISTRO_VERSION    = "1.2+snapshot-20120904"
>    TUNE_FEATURES     = "m32 microblazeel"
>    TARGET_FPU        = "soft"
>    meta
>    meta-yocto        = "master:37c8597e7600385367257e8a513e003947ebef5b"
>    meta-xilinx       = "master:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7"
> 
> conf/local.conf:
>    BB_NUMBER_THREADS = "4"
>    PARALLEL_MAKE = "-j 4"
>    MACHINE ??= "spartan6-lx9mb"
>    DL_DIR = "/home/trevor/devel/Downloads"
>    DISTRO ?= "poky"
>    PACKAGE_CLASSES ?= "package_rpm"
>    EXTRA_IMAGE_FEATURES = "debug-tweaks"
>    USER_CLASSES ?= "buildstats image-mklibs image-prelink"
>    PATCHRESOLVE = "noop"
>    CONF_VERSION = "1"
> 
> conf/bblayers.conf:
>    LCONF_VERSION = "5"
>    BBPATH = "${TOPDIR}"
>    BBFILES ?= ""
>    BBLAYERS ?= " \
>      /home/trevor/devel/yocto/git-method/poky/meta \
>      /home/trevor/devel/yocto/git-method/poky/meta-yocto \
>      /home/trevor/devel/yocto/git-method/poky/meta-xilinx \
>      "
> 
> issues:
> 
> The first problem I encountered was trying to build gcc-cross-initial:
>    This target does not support --with-float.
> 

If you look at the tune file, it says TARGET_FPU = "soft", which means
software floating point emulation.

However, the gcc toolchain recipes are trying to build with hardware floating
point support, from the error message.

Let me know what you ISE development tool configuration and development
board is, and I'll see if I can divert a bit from target platform, and try to 
explore getting the toolchain to build for the Microblaze processor.

I've got the following boards with me:
- Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
- Xilinx SP601 (Spartan 6)
- Xilinx Zynq (ARM Cortex A-9)

Best regards,

Elvis Dowson

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

Hi Elvis,

Thanks so much for taking a look at my email! I've read through lots
of this mailing list's history and noticed all your meta-xilinx work
in the past and was hoping I could pique your interest :-)

On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson <elvis.dowson@gmail.com> wrote:
> Can you please list which version of the Xilinx ISE tools you are using? e.g. 12.4, 14.1, 14.2 ?

I have 14.2 installed on my Linux machine at home.

> Could you also please list the Xilinx development board that you are using? e.g. SP601 (Spartan6) ?

I have been (slowly) teaching myself VHDL and working with a Papilio
board from Gadget Factory. Are you familiar with them? They have a
Spartan 3E on them.

    http://papilio.cc/

> Let me know what you ISE development tool configuration and development
> board is, and I'll see if I can divert a bit from target platform, and try to
> explore getting the toolchain to build for the Microblaze processor.

It is my understanding that Microblaze won't fit or work with the
Spartan 3E (?). However, the guy who makes the Papilio board, Jack
Gassett, is currently working on his latest board called the "Papilio
Plus". The Plus is not yet out, although prototypes are available:

    http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/

The Plus will feature a Spartan 6 LX9, which, I believe, can support
the Microblaze.

In a comment on the All Programmable Planet blog about a month ago,
Jack bemoans how easy it used to be to get Linux up and running on a
Spartan 3E devel board using what has now become PetaLinux. The
problem is that PetaLinux is now a commercial product and not readily
available to the DIY market:

    http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509&piddl_msgid=717514#msg_717514

When I noticed the meta-xilinx layer had support for the Spartan 6 LX9
I was really hoping to surprise Jack by testing it out and providing
instructions for creating a filesystem he could use as part of his
work on the Plus. Unfortunately my attempts fell flat. I even tried
using denzil-7.0.1 but encountered the same problems.

Seeing how soft processors within programmable logic seems to be
gaining in popularity, I thought it would be a great niche to get
into. If the Yocto Project could be used to create images for the
Microblaze or even the Picoblaze processors I think it would help fill
a void which is quickly expanding. Also, if support could be added to
meta-xilinx to support Jack's Papilio boards it would help introduce
the DIY community to the Yocto Project.

> I've got the following boards with me:
> - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
> - Xilinx SP601 (Spartan 6)
> - Xilinx Zynq (ARM Cortex A-9)

Once I get more into the VHDL I'll probably end up getting a Zynq
myself too; talk about combining the best of both worlds :-)

Best regards,
    Trevor

Re: any success with spartan6-lx9mb?

[Philip Balister]

On 09/06/2012 04:11 PM, Trevor Woerner wrote:
> Hi Elvis,
>
> Thanks so much for taking a look at my email! I've read through lots
> of this mailing list's history and noticed all your meta-xilinx work
> in the past and was hoping I could pique your interest :-)
>
> On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson <elvis.dowson@gmail.com> wrote:
>> Can you please list which version of the Xilinx ISE tools you are using? e.g. 12.4, 14.1, 14.2 ?
>
> I have 14.2 installed on my Linux machine at home.
>
>> Could you also please list the Xilinx development board that you are using? e.g. SP601 (Spartan6) ?
>
> I have been (slowly) teaching myself VHDL and working with a Papilio
> board from Gadget Factory. Are you familiar with them? They have a
> Spartan 3E on them.
>
>      http://papilio.cc/
>
>> Let me know what you ISE development tool configuration and development
>> board is, and I'll see if I can divert a bit from target platform, and try to
>> explore getting the toolchain to build for the Microblaze processor.
>
> It is my understanding that Microblaze won't fit or work with the
> Spartan 3E (?). However, the guy who makes the Papilio board, Jack
> Gassett, is currently working on his latest board called the "Papilio
> Plus". The Plus is not yet out, although prototypes are available:
>
>      http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/
>
> The Plus will feature a Spartan 6 LX9, which, I believe, can support
> the Microblaze.
>
> In a comment on the All Programmable Planet blog about a month ago,
> Jack bemoans how easy it used to be to get Linux up and running on a
> Spartan 3E devel board using what has now become PetaLinux. The
> problem is that PetaLinux is now a commercial product and not readily
> available to the DIY market:
>
>      http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509&piddl_msgid=717514#msg_717514
>
> When I noticed the meta-xilinx layer had support for the Spartan 6 LX9
> I was really hoping to surprise Jack by testing it out and providing
> instructions for creating a filesystem he could use as part of his
> work on the Plus. Unfortunately my attempts fell flat. I even tried
> using denzil-7.0.1 but encountered the same problems.
>
> Seeing how soft processors within programmable logic seems to be
> gaining in popularity, I thought it would be a great niche to get
> into. If the Yocto Project could be used to create images for the
> Microblaze or even the Picoblaze processors I think it would help fill
> a void which is quickly expanding. Also, if support could be added to
> meta-xilinx to support Jack's Papilio boards it would help introduce
> the DIY community to the Yocto Project.
>
>> I've got the following boards with me:
>> - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
>> - Xilinx SP601 (Spartan 6)
>> - Xilinx Zynq (ARM Cortex A-9)
>
> Once I get more into the VHDL I'll probably end up getting a Zynq
> myself too; talk about combining the best of both worlds :-)

Speaking of zynq, I have a simple BSP here for the zc702 board:

https://github.com/balister/meta-zynq

Philip

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

Hi Philip,

On Thu, Sep 6, 2012 at 5:06 PM, Philip Balister <philip@balister.org> wrote:
> Speaking of zynq, I have a simple BSP here for the zc702 board:
> https://github.com/balister/meta-zynq

Thanks. I found your layer from the layer index page:
http://www.openembedded.org/wiki/LayerIndex

although I haven't tried it yet. It's good that the layer page is
updated regularly.

Re: any success with spartan6-lx9mb?

[Bruce Ashfield]

On 12-09-06 5:06 PM, Philip Balister wrote:
> On 09/06/2012 04:11 PM, Trevor Woerner wrote:
>> Hi Elvis,
>>
>> Thanks so much for taking a look at my email! I've read through lots
>> of this mailing list's history and noticed all your meta-xilinx work
>> in the past and was hoping I could pique your interest :-)
>>
>> On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson <elvis.dowson@gmail.com>
>> wrote:
>>> Can you please list which version of the Xilinx ISE tools you are
>>> using? e.g. 12.4, 14.1, 14.2 ?
>>
>> I have 14.2 installed on my Linux machine at home.
>>
>>> Could you also please list the Xilinx development board that you are
>>> using? e.g. SP601 (Spartan6) ?
>>
>> I have been (slowly) teaching myself VHDL and working with a Papilio
>> board from Gadget Factory. Are you familiar with them? They have a
>> Spartan 3E on them.
>>
>> http://papilio.cc/
>>
>>> Let me know what you ISE development tool configuration and development
>>> board is, and I'll see if I can divert a bit from target platform,
>>> and try to
>>> explore getting the toolchain to build for the Microblaze processor.
>>
>> It is my understanding that Microblaze won't fit or work with the
>> Spartan 3E (?). However, the guy who makes the Papilio board, Jack
>> Gassett, is currently working on his latest board called the "Papilio
>> Plus". The Plus is not yet out, although prototypes are available:
>>
>> http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/
>>
>>
>> The Plus will feature a Spartan 6 LX9, which, I believe, can support
>> the Microblaze.
>>
>> In a comment on the All Programmable Planet blog about a month ago,
>> Jack bemoans how easy it used to be to get Linux up and running on a
>> Spartan 3E devel board using what has now become PetaLinux. The
>> problem is that PetaLinux is now a commercial product and not readily
>> available to the DIY market:
>>
>> http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509&piddl_msgid=717514#msg_717514
>>
>>
>> When I noticed the meta-xilinx layer had support for the Spartan 6 LX9
>> I was really hoping to surprise Jack by testing it out and providing
>> instructions for creating a filesystem he could use as part of his
>> work on the Plus. Unfortunately my attempts fell flat. I even tried
>> using denzil-7.0.1 but encountered the same problems.
>>
>> Seeing how soft processors within programmable logic seems to be
>> gaining in popularity, I thought it would be a great niche to get
>> into. If the Yocto Project could be used to create images for the
>> Microblaze or even the Picoblaze processors I think it would help fill
>> a void which is quickly expanding. Also, if support could be added to
>> meta-xilinx to support Jack's Papilio boards it would help introduce
>> the DIY community to the Yocto Project.
>>
>>> I've got the following boards with me:
>>> - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
>>> - Xilinx SP601 (Spartan 6)
>>> - Xilinx Zynq (ARM Cortex A-9)
>>
>> Once I get more into the VHDL I'll probably end up getting a Zynq
>> myself too; talk about combining the best of both worlds :-)
>
> Speaking of zynq, I have a simple BSP here for the zc702 board:
>
> https://github.com/balister/meta-zynq

We have a namespace collision, there is also:

   http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/

Cheers,

Bruce

>
> Philip
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: any success with spartan6-lx9mb?

[Elvis Dowson]

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

Hi,

On Sep 6, 2012, at 7:19 PM, Elvis Dowson wrote:

>> 
>> issues:
>> 
>> The first problem I encountered was trying to build gcc-cross-initial:
>>   This target does not support --with-float.
>> 
> 
> If you look at the tune file, it says TARGET_FPU = "soft", which means
> software floating point emulation.
> 
> However, the gcc toolchain recipes are trying to build with hardware floating
> point support, from the error message.

My bad, the error was because the --with-float option does not exist for the
microblaze processor

Looking at the gcc options for microblaze from 

http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html

MicroBlaze Options

          -msoft-float -mhard-float -msmall-divides -mcpu=cpu 
          -mmemcpy -mxl-soft-mul -mxl-soft-div -mxl-barrel-shift 
          -mxl-pattern-compare -mxl-stack-check -mxl-gp-opt -mno-clearbss 
          -mxl-multiply-high -mxl-float-convert -mxl-float-sqrt 
          -mxl-mode-app-model

So, the next step is to try and modify the tune files, slightly. I recall someone from
windriver mentioned that TARGET_FPU is to be explicitly set specified only if a 
special hardware FPU was used. When it is blank, it means default, which is
hardware floating point. Software floating point gets set automatically from
other settings in the tune file.

So the first thing to try is to remove any entry for TARGET_FPU = "soft" from
any tune file that you are referencing. It will get set automatically at build time,
as far as I know from the other options in the tune file.



> opening microblaze-c.o: No such file or directory
> make[1]: *** [cc1-checksum.c] Error 1
> rm cpp.pod gcov.pod gfdl.pod gcc.pod fsf-funding.pod
> make[1]: Leaving directory
> `/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/work/microblazeel-poky-linux/gcc-cross-initial-4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede-r11/gcc-4_7-branch/build.x86_64-linux.microblaze-poky-linux/gcc'
> make: *** [all-gcc] Error 2
> ERROR: oe_runmake failed
> ERROR: Function failed: do_compile

The second thing to look at is the above error that you got. 

Perhaps the reason why it couldn't find the microblaze-c.o output file was because in the gcc sources, there is no cpu=microblazeel, but only cpu=microblaze

http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/microblaze/microblaze-c.c;h=32c38da311b12b07cc1ed9fbf13f7946291f2857;hb=refs/heads/gcc-4_7-branch

void 
microblaze_cpp_define (cpp_reader *pfile)
{
  builtin_assert ("cpu=microblaze");
  builtin_assert ("machine=microblaze");
  builtin_define ("__MICROBLAZE__");
  if (!TARGET_SOFT_MUL) 
    {
      if (!flag_iso)
        builtin_define ("HAVE_HW_MUL");
      builtin_define ("__HAVE_HW_MUL__");
    }

So, we will need to examine the tune files that you are using for your particular machine configuration, and ensure that it is setting the correct cpu type

What you could start off, as a quick test would be to replace the selected tune file in spartan6-lx9mb.conf and change it to use tune-microblaze.inc instead of tune-microblazeel.inc, because the latter appears to incorrectly set the cpu to microblazeel, I think.

File: meta-xilinx/tree/conf/machine/spartan6-lx9mb.conf
# Copyright (C) 2011, SecretLab Technologies Ltd.
# Adrian Alonso <aalonso@secretlab.ca>
# Released under the MIT license (see packages/COPYING)
#@TYPE: Machine
#@Name: Xilinx generic microblaze target support
#@DESCRIPTION: Machine configuration for Xilinx Microblaze
# Supported target: spartan6-lx9mb
#
# Xilinx EDK override hardware  definitions for xilinx-bsp
# Include in your local.conf
# XILINX_BSP_PATH = "complete path for Xilinx XPS project"

TARGET_CPU = "microblaze"
# tune for the microblaze little endian cpu
-require conf/machine/include/tune-microblazeel.inc
+require conf/machine/include/tune-microblaze.inc

PREFERRED_PROVIDER_virtual/kernel = "linux-xilinx"
PREFERRED_VERSION_u-boot = "uboot-xilinx"
# Add uboot to rootfs
EXTRA_IMAGEDEPENDS += "u-boot-xilinx"
XILINX_BOARD = "microblaze-generic"

KERNEL_IMAGETYPE = "simpleImage.system"

MACHINE_FEATURES = "kernel26 apm ext2 vfat ethernet"
MACHINE_EXTRA_RECOMMENDS = "kernel-modules"

UBOOT_ENTRYPOINT ?= "0xBC000000"
UBOOT_LOADADDRESS ?= "0xBC000000"
UBOOT_MACHINE ?= "microblaze-generic_config"

# Don't use tty1
USE_VT = "0"
SERIAL_CONSOLE = "115200 ttyUL0"

# Device nodes add xsa for (system ace)
IMAGE_DEVICE_TABLES = "files/device_table-minimal.txt \
                       files/device_table_add-xsa.txt"

Perhaps if you could try the above two changes, i.e. remove the TARGET_FPU = "soft" from the tune file, and switch tune files so that the correct cpu type is set, and see if the gcc-initial compilation progresses?

File: meta-xilinx/plain/conf/machine/include/tune-microblaze.inc
# Tune options for microblaze

require conf/machine/include/microblaze/arch-microblaze.inc

-TARGET_FPU = "soft"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblaze", "-mcpu=v8.10a", "", d)}"

#MACHINEOVERRIDES .= "microblaze"

If that works, then maybe we could update the tune-microblaze.inc files, so that it uses the variables defined in the following file, which I updated recently for powerpc440 soft float

File: meta-xilinx/tree/conf/machine/include/tune-ppc440.inc

DEFAULTTUNE ?= "ppc440"

require conf/machine/include/powerpc/arch-powerpc.inc

TUNEVALID[ppc440] = "Enable ppc440 specific processor optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "ppc440", "-mcpu=440", "", d)}"

AVAILTUNES += "ppc440"
TUNE_FEATURES_tune-ppc440 = "m32 fpu-soft ppc440"
TUNE_PKGARCH_tune-ppc440 = "ppc440"
PACKAGE_EXTRA_ARCHS_tune-ppc440 = "${PACKAGE_EXTRA_ARCHS_tune-powerpc-nf} ppc440"

# glibc configure options to get ppc440 specific library (for sqrt)
GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc440", "-with-cpu=440", "", d)}"

I don't see the need for tune-microblazeel.inc, and you could merge the contents of tune-microblazeel.inc, taking care not to define cpu = "microblazeel", as highlighed in red below. that should only be microblaze. 

meta-xilinx/conf.machine/include/tune-microblazeel.inc

# Tune options for microblaze endian little
DEFAULTTUNE ?= "microblazeel"

require conf/machine/include/microblaze/arch-microblaze.inc

TUNEVALID[microblazeel] = "Enable microblaze endian little optimizations"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblazeel", "-mcpu=v8.10a", "", d)}"
TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "microblazeel", "microblazeel", "microblazeel", d)}"

TARGET_FPU = "soft"

AVAILTUNES += "microblazeel"
TUNE_FEATURES_tune-microblazeel = "m32 microblazeel"
PACKAGE_EXTRA_ARCHS_tune-microblazeel = "microblazeel"

#MACHINEOVERRIDES .= "microblaze"


Summary

01. Remove the TARGET_FPU = "soft" specification

02. Quickly test the machine/spartan6-lx9mb.conf by temporarily changing the tune file to include/tune-microblaze.inc, and see if the toolchain gets built using gcc-4.7 recipes.

03. If that works, then update the include/tune-microblaze.inc, to make it more current by looking at include/tune-ppc440.inc. We could potentially delete include/tune-microblazeel.inc, since after including same variables from include/tune-ppc440.inc, into 
include/tune-microblaze.inc, it would end up nearly looking like include/tune-microblazeel.inc, without the erroneous cpu=microblazeel spec in TUNE_CCARGS.

04. Later on create a include/tune-microblazee.inc file, for hardware floating point support.

Do let me know how it goes!

Best regards,

Elvis Dowson

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

Re: any success with spartan6-lx9mb?

[Philip Balister]

On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
> On 12-09-06 5:06 PM, Philip Balister wrote:
>> On 09/06/2012 04:11 PM, Trevor Woerner wrote:
>>> Hi Elvis,
>>>
>>> Thanks so much for taking a look at my email! I've read through lots
>>> of this mailing list's history and noticed all your meta-xilinx work
>>> in the past and was hoping I could pique your interest :-)
>>>
>>> On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson <elvis.dowson@gmail.com>
>>> wrote:
>>>> Can you please list which version of the Xilinx ISE tools you are
>>>> using? e.g. 12.4, 14.1, 14.2 ?
>>>
>>> I have 14.2 installed on my Linux machine at home.
>>>
>>>> Could you also please list the Xilinx development board that you are
>>>> using? e.g. SP601 (Spartan6) ?
>>>
>>> I have been (slowly) teaching myself VHDL and working with a Papilio
>>> board from Gadget Factory. Are you familiar with them? They have a
>>> Spartan 3E on them.
>>>
>>> http://papilio.cc/
>>>
>>>> Let me know what you ISE development tool configuration and development
>>>> board is, and I'll see if I can divert a bit from target platform,
>>>> and try to
>>>> explore getting the toolchain to build for the Microblaze processor.
>>>
>>> It is my understanding that Microblaze won't fit or work with the
>>> Spartan 3E (?). However, the guy who makes the Papilio board, Jack
>>> Gassett, is currently working on his latest board called the "Papilio
>>> Plus". The Plus is not yet out, although prototypes are available:
>>>
>>> http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/
>>>
>>>
>>>
>>> The Plus will feature a Spartan 6 LX9, which, I believe, can support
>>> the Microblaze.
>>>
>>> In a comment on the All Programmable Planet blog about a month ago,
>>> Jack bemoans how easy it used to be to get Linux up and running on a
>>> Spartan 3E devel board using what has now become PetaLinux. The
>>> problem is that PetaLinux is now a commercial product and not readily
>>> available to the DIY market:
>>>
>>> http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509&piddl_msgid=717514#msg_717514
>>>
>>>
>>>
>>> When I noticed the meta-xilinx layer had support for the Spartan 6 LX9
>>> I was really hoping to surprise Jack by testing it out and providing
>>> instructions for creating a filesystem he could use as part of his
>>> work on the Plus. Unfortunately my attempts fell flat. I even tried
>>> using denzil-7.0.1 but encountered the same problems.
>>>
>>> Seeing how soft processors within programmable logic seems to be
>>> gaining in popularity, I thought it would be a great niche to get
>>> into. If the Yocto Project could be used to create images for the
>>> Microblaze or even the Picoblaze processors I think it would help fill
>>> a void which is quickly expanding. Also, if support could be added to
>>> meta-xilinx to support Jack's Papilio boards it would help introduce
>>> the DIY community to the Yocto Project.
>>>
>>>> I've got the following boards with me:
>>>> - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
>>>> - Xilinx SP601 (Spartan 6)
>>>> - Xilinx Zynq (ARM Cortex A-9)
>>>
>>> Once I get more into the VHDL I'll probably end up getting a Zynq
>>> myself too; talk about combining the best of both worlds :-)
>>
>> Speaking of zynq, I have a simple BSP here for the zc702 board:
>>
>> https://github.com/balister/meta-zynq
>
> We have a namespace collision, there is also:
>
>    http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/

Before creating the layer I checked:

http://www.openembedded.org/wiki/LayerIndex

This is where layer information is collected. If a layer is not listed 
here, yo can expect namespace collisions.

Philip

>
> Cheers,
>
> Bruce
>
>>
>> Philip
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>

Re: any success with spartan6-lx9mb?

[Bruce Ashfield]

On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister <philip@balister.org> wrote:
> On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
>>
>> On 12-09-06 5:06 PM, Philip Balister wrote:
>>>
>>> On 09/06/2012 04:11 PM, Trevor Woerner wrote:
>>>>
>>>> Hi Elvis,
>>>>
>>>> Thanks so much for taking a look at my email! I've read through lots
>>>> of this mailing list's history and noticed all your meta-xilinx work
>>>> in the past and was hoping I could pique your interest :-)
>>>>
>>>> On Thu, Sep 6, 2012 at 11:19 AM, Elvis Dowson <elvis.dowson@gmail.com>
>>>> wrote:
>>>>>
>>>>> Can you please list which version of the Xilinx ISE tools you are
>>>>> using? e.g. 12.4, 14.1, 14.2 ?
>>>>
>>>>
>>>> I have 14.2 installed on my Linux machine at home.
>>>>
>>>>> Could you also please list the Xilinx development board that you are
>>>>> using? e.g. SP601 (Spartan6) ?
>>>>
>>>>
>>>> I have been (slowly) teaching myself VHDL and working with a Papilio
>>>> board from Gadget Factory. Are you familiar with them? They have a
>>>> Spartan 3E on them.
>>>>
>>>> http://papilio.cc/
>>>>
>>>>> Let me know what you ISE development tool configuration and development
>>>>> board is, and I'll see if I can divert a bit from target platform,
>>>>> and try to
>>>>> explore getting the toolchain to build for the Microblaze processor.
>>>>
>>>>
>>>> It is my understanding that Microblaze won't fit or work with the
>>>> Spartan 3E (?). However, the guy who makes the Papilio board, Jack
>>>> Gassett, is currently working on his latest board called the "Papilio
>>>> Plus". The Plus is not yet out, although prototypes are available:
>>>>
>>>>
>>>> http://forum.gadgetfactory.net/index.php?/topic/1280-papilio-plus-prototypes-available-for-8499-in-the-store/
>>>>
>>>>
>>>>
>>>> The Plus will feature a Spartan 6 LX9, which, I believe, can support
>>>> the Microblaze.
>>>>
>>>> In a comment on the All Programmable Planet blog about a month ago,
>>>> Jack bemoans how easy it used to be to get Linux up and running on a
>>>> Spartan 3E devel board using what has now become PetaLinux. The
>>>> problem is that PetaLinux is now a commercial product and not readily
>>>> available to the DIY market:
>>>>
>>>>
>>>> http://www.programmableplanet.com/messages.asp?piddl_msgthreadid=252509&piddl_msgid=717514#msg_717514
>>>>
>>>>
>>>>
>>>> When I noticed the meta-xilinx layer had support for the Spartan 6 LX9
>>>> I was really hoping to surprise Jack by testing it out and providing
>>>> instructions for creating a filesystem he could use as part of his
>>>> work on the Plus. Unfortunately my attempts fell flat. I even tried
>>>> using denzil-7.0.1 but encountered the same problems.
>>>>
>>>> Seeing how soft processors within programmable logic seems to be
>>>> gaining in popularity, I thought it would be a great niche to get
>>>> into. If the Yocto Project could be used to create images for the
>>>> Microblaze or even the Picoblaze processors I think it would help fill
>>>> a void which is quickly expanding. Also, if support could be added to
>>>> meta-xilinx to support Jack's Papilio boards it would help introduce
>>>> the DIY community to the Yocto Project.
>>>>
>>>>> I've got the following boards with me:
>>>>> - Xilinx ML507 (Virtex 5 FX70T with PowerPC 440)
>>>>> - Xilinx SP601 (Spartan 6)
>>>>> - Xilinx Zynq (ARM Cortex A-9)
>>>>
>>>>
>>>> Once I get more into the VHDL I'll probably end up getting a Zynq
>>>> myself too; talk about combining the best of both worlds :-)
>>>
>>>
>>> Speaking of zynq, I have a simple BSP here for the zc702 board:
>>>
>>> https://github.com/balister/meta-zynq
>>
>>
>> We have a namespace collision, there is also:
>>
>>    http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
>
>
> Before creating the layer I checked:
>
> http://www.openembedded.org/wiki/LayerIndex
>
> This is where layer information is collected. If a layer is not listed here,
> yo can expect namespace collisions.

Sure, I don't argue with that, but I wasn't the original owner of the layer so
I can't say why it was or wasn't put into the wiki .. I'm not really concerned
about the minor oversight. They layer I pointed to was done under contract
by xilinx themselves, and contributed to be maintained as a yocto BSP, so
the layers name is not something that I control or can change.

Other similar layers can use the same name if they want, I was pointing it
out for reference, since I've had the same thing pointed out to me in
the past ;)

Cheers,

Bruce

>
> Philip
>
>
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Philip
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: any success with spartan6-lx9mb?

[Richard Purdie]

On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote:
> On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister <philip@balister.org> wrote:
> > On 09/06/2012 06:19 PM, Bruce Ashfield wrote:

> >>>
> >>> Speaking of zynq, I have a simple BSP here for the zc702 board:
> >>>
> >>> https://github.com/balister/meta-zynq
> >>
> >>
> >> We have a namespace collision, there is also:
> >>
> >>    http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
> >
> >
> > Before creating the layer I checked:
> >
> > http://www.openembedded.org/wiki/LayerIndex
> >
> > This is where layer information is collected. If a layer is not listed here,
> > yo can expect namespace collisions.
> 
> Sure, I don't argue with that, but I wasn't the original owner of the layer so
> I can't say why it was or wasn't put into the wiki .. I'm not really concerned
> about the minor oversight. They layer I pointed to was done under contract
> by xilinx themselves, and contributed to be maintained as a yocto BSP, so
> the layers name is not something that I control or can change.
> 
> Other similar layers can use the same name if they want, I was pointing it
> out for reference, since I've had the same thing pointed out to me in
> the past ;)

The bigger question is whether that layer is getting maintained. If it
isn't, it will likely get removed. I'd prefer it to get added to the
layer index and the namespace collision getting fixed.

I was going to cc the maintainer but there isn't one listed in the
README which is a really bad start. The feedback I gave when this was
added has not all been acted upon either (multi-dtb.inc,
layencytop/sysprof nastiness).

This puts it right at the top of my "likely to get removed soon" list.

Bruce: Since you have an idea who wrote it, could you find out whether
its going to get fixed (at the very least fix the README, add to the
index and resolve the namespace) or whether I should be deleting it.

Cheers,

Richard

Re: any success with spartan6-lx9mb?

[Bruce Ashfield]

On 12-09-07 12:19 PM, Richard Purdie wrote:
> On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote:
>> On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister<philip@balister.org>  wrote:
>>> On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
>
>>>>>
>>>>> Speaking of zynq, I have a simple BSP here for the zc702 board:
>>>>>
>>>>> https://github.com/balister/meta-zynq
>>>>
>>>>
>>>> We have a namespace collision, there is also:
>>>>
>>>>     http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
>>>
>>>
>>> Before creating the layer I checked:
>>>
>>> http://www.openembedded.org/wiki/LayerIndex
>>>
>>> This is where layer information is collected. If a layer is not listed here,
>>> yo can expect namespace collisions.
>>
>> Sure, I don't argue with that, but I wasn't the original owner of the layer so
>> I can't say why it was or wasn't put into the wiki .. I'm not really concerned
>> about the minor oversight. They layer I pointed to was done under contract
>> by xilinx themselves, and contributed to be maintained as a yocto BSP, so
>> the layers name is not something that I control or can change.
>>
>> Other similar layers can use the same name if they want, I was pointing it
>> out for reference, since I've had the same thing pointed out to me in
>> the past ;)
>
> The bigger question is whether that layer is getting maintained. If it
> isn't, it will likely get removed. I'd prefer it to get added to the
> layer index and the namespace collision getting fixed.
>
> I was going to cc the maintainer but there isn't one listed in the
> README which is a really bad start. The feedback I gave when this was
> added has not all been acted upon either (multi-dtb.inc,
> layencytop/sysprof nastiness).
>
> This puts it right at the top of my "likely to get removed soon" list.

It is being maintained, updates are pending.

>
> Bruce: Since you have an idea who wrote it, could you find out whether
> its going to get fixed (at the very least fix the README, add to the
> index and resolve the namespace) or whether I should be deleting it.

Don't delete it. Work is being done. This was supposed to be a primary
repository for work, and it is the basis for spin off BSPs. There was
a handoff issue between Wind River and Xylinx .. but I don't have all
the details.

And it's something that I'll be carrying forward and pulling kernel
patches into linux-yocto on the next kernel bump.

I'll do the simple updates to the README and put it in the layer index.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

meta-zynq, was Re: any success with spartan6-lx9mb?

[Philip Balister]

On 09/07/2012 12:30 PM, Bruce Ashfield wrote:
> On 12-09-07 12:19 PM, Richard Purdie wrote:
>> On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote:
>>> On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister<philip@balister.org>
>>> wrote:
>>>> On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
>>
>>>>>>
>>>>>> Speaking of zynq, I have a simple BSP here for the zc702 board:
>>>>>>
>>>>>> https://github.com/balister/meta-zynq
>>>>>
>>>>>
>>>>> We have a namespace collision, there is also:
>>>>>
>>>>>     http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
>>>>
>>>>
>>>> Before creating the layer I checked:
>>>>
>>>> http://www.openembedded.org/wiki/LayerIndex
>>>>
>>>> This is where layer information is collected. If a layer is not
>>>> listed here,
>>>> yo can expect namespace collisions.
>>>
>>> Sure, I don't argue with that, but I wasn't the original owner of the
>>> layer so
>>> I can't say why it was or wasn't put into the wiki .. I'm not really
>>> concerned
>>> about the minor oversight. They layer I pointed to was done under
>>> contract
>>> by xilinx themselves, and contributed to be maintained as a yocto
>>> BSP, so
>>> the layers name is not something that I control or can change.
>>>
>>> Other similar layers can use the same name if they want, I was
>>> pointing it
>>> out for reference, since I've had the same thing pointed out to me in
>>> the past ;)
>>
>> The bigger question is whether that layer is getting maintained. If it
>> isn't, it will likely get removed. I'd prefer it to get added to the
>> layer index and the namespace collision getting fixed.
>>
>> I was going to cc the maintainer but there isn't one listed in the
>> README which is a really bad start. The feedback I gave when this was
>> added has not all been acted upon either (multi-dtb.inc,
>> layencytop/sysprof nastiness).
>>
>> This puts it right at the top of my "likely to get removed soon" list.
>
> It is being maintained, updates are pending.
>
>>
>> Bruce: Since you have an idea who wrote it, could you find out whether
>> its going to get fixed (at the very least fix the README, add to the
>> index and resolve the namespace) or whether I should be deleting it.
>
> Don't delete it. Work is being done. This was supposed to be a primary
> repository for work, and it is the basis for spin off BSPs. There was
> a handoff issue between Wind River and Xylinx .. but I don't have all
> the details.
>
> And it's something that I'll be carrying forward and pulling kernel
> patches into linux-yocto on the next kernel bump.
>
> I'll do the simple updates to the README and put it in the layer index.

I'm concerned the kernel version is the yocto project version is based 
off 3.2 and the code in git.xilinx.com is based of 3.3 now.

I do not like either situation :)

But, working with vendors who provide git repos of their work, it is 
easier for people using the boards to track the vendor tree, and not 
spend time figuring out how to get from linux releases to the vendor tree.

I'd like to see the layers unifed, since we need to reduce confusion, 
but have some reservations about the layer on the Yocto Project server.

Philip

>
> Cheers,
>
> Bruce
>
>>
>> Cheers,
>>
>> Richard
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

Re: meta-zynq, was Re: any success with spartan6-lx9mb?

[Bruce Ashfield]

On 12-09-07 01:29 PM, Philip Balister wrote:
> On 09/07/2012 12:30 PM, Bruce Ashfield wrote:
>> On 12-09-07 12:19 PM, Richard Purdie wrote:
>>> On Fri, 2012-09-07 at 08:27 -0400, Bruce Ashfield wrote:
>>>> On Fri, Sep 7, 2012 at 7:22 AM, Philip Balister<philip@balister.org>
>>>> wrote:
>>>>> On 09/06/2012 06:19 PM, Bruce Ashfield wrote:
>>>
>>>>>>>
>>>>>>> Speaking of zynq, I have a simple BSP here for the zc702 board:
>>>>>>>
>>>>>>> https://github.com/balister/meta-zynq
>>>>>>
>>>>>>
>>>>>> We have a namespace collision, there is also:
>>>>>>
>>>>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-zynq/
>>>>>
>>>>>
>>>>> Before creating the layer I checked:
>>>>>
>>>>> http://www.openembedded.org/wiki/LayerIndex
>>>>>
>>>>> This is where layer information is collected. If a layer is not
>>>>> listed here,
>>>>> yo can expect namespace collisions.
>>>>
>>>> Sure, I don't argue with that, but I wasn't the original owner of the
>>>> layer so
>>>> I can't say why it was or wasn't put into the wiki .. I'm not really
>>>> concerned
>>>> about the minor oversight. They layer I pointed to was done under
>>>> contract
>>>> by xilinx themselves, and contributed to be maintained as a yocto
>>>> BSP, so
>>>> the layers name is not something that I control or can change.
>>>>
>>>> Other similar layers can use the same name if they want, I was
>>>> pointing it
>>>> out for reference, since I've had the same thing pointed out to me in
>>>> the past ;)
>>>
>>> The bigger question is whether that layer is getting maintained. If it
>>> isn't, it will likely get removed. I'd prefer it to get added to the
>>> layer index and the namespace collision getting fixed.
>>>
>>> I was going to cc the maintainer but there isn't one listed in the
>>> README which is a really bad start. The feedback I gave when this was
>>> added has not all been acted upon either (multi-dtb.inc,
>>> layencytop/sysprof nastiness).
>>>
>>> This puts it right at the top of my "likely to get removed soon" list.
>>
>> It is being maintained, updates are pending.
>>
>>>
>>> Bruce: Since you have an idea who wrote it, could you find out whether
>>> its going to get fixed (at the very least fix the README, add to the
>>> index and resolve the namespace) or whether I should be deleting it.
>>
>> Don't delete it. Work is being done. This was supposed to be a primary
>> repository for work, and it is the basis for spin off BSPs. There was
>> a handoff issue between Wind River and Xylinx .. but I don't have all
>> the details.
>>
>> And it's something that I'll be carrying forward and pulling kernel
>> patches into linux-yocto on the next kernel bump.
>>
>> I'll do the simple updates to the README and put it in the layer index.
>
> I'm concerned the kernel version is the yocto project version is based
> off 3.2 and the code in git.xilinx.com is based of 3.3 now.

True. But the work I mentioned is happening is to move this to 3.4.
3.2 is the version that Xilinx requested for initial integration as a
yocto BSP, so that's where it sits for now.

>
> I do not like either situation :)

Niether do I.

>
> But, working with vendors who provide git repos of their work, it is
> easier for people using the boards to track the vendor tree, and not
> spend time figuring out how to get from linux releases to the vendor tree.

In this case, they were hoping to track the yocto kernel versions to
not make version skew or spread the version landscape anymore. As far
as I know, this is still the case, since it makes the route to commercial
support simpler in some cases.

>
> I'd like to see the layers unifed, since we need to reduce confusion,
> but have some reservations about the layer on the Yocto Project server.

I'm sure we can work through them, I'm raising the right people at
Xilinx to discuss as well, since in the end, their voice carries the
most weight.

Cheers,

Bruce

>
> Philip
>
>>
>> Cheers,
>>
>> Bruce
>>
>>>
>>> Cheers,
>>>
>>> Richard
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

Hi Elvis,

Wow! Thanks so much for the help. I have not yet had the time to dig
into the guts of yocto/oe so I appreciate the opportunity :-)

On Thu, Sep 6, 2012 at 11:21 PM, Elvis Dowson <elvis.dowson@gmail.com> wrote:
> 01. Remove the TARGET_FPU = "soft" specification
>
> 02. Quickly test the machine/spartan6-lx9mb.conf by temporarily changing the
> tune file to include/tune-microblaze.inc, and see if the toolchain gets
> built using gcc-4.7 recipes.

Using the information you provided, my investigations have centered
around 3 files from meta-xilinx:
    conf/machine/spartan6-lx9mb.conf
    conf/machine/include/tune-microblaze.inc
    conf/machine/include/microblaze/arch-microblaze.inc

First off: I'm curious why, when you refer to your meta-xilinx files,
you seem to have additional directories:
    meta-xilinx/tree/conf/machine/spartan6-lx9mb.conf [tree?]
    meta-xilinx/conf.machine/include/tune-microblazeel.inc [conf.machine?]

Secondly: usually when a bake needs to be restarted there's usually
some sort of "bitbake -f" or "bitbake -c clean -f <recipe>" that needs
to be issued. While performing my tests I never issued any such
cleanups and the new configurations seemed to be picked up correctly.
It is reasonable to believe my procedure is okay when modifying these
"machine" files?

I started by editing conf/machine/spartan-lx9mb.conf to "require
conf/machine/include/tune-microblaze.inc" from "tune-microblazeel.inc"
and removing 'TARGET_FPU = "soft"' from the "tune-microblaze.inc"
file. This, unfortunately failed:

    Build Configuration:
    BB_VERSION        = "1.15.3"
    TARGET_ARCH       = "microblaze"
    TARGET_OS         = "linux"
    MACHINE           = "spartan6-lx9mb"
    DISTRO            = "poky"
    DISTRO_VERSION    = "1.2+snapshot-20120908"
    TUNE_FEATURES     = "m32 fpu-soft"
    TARGET_FPU        = "soft"
    meta
    meta-yocto        = "master:5343cdb20ee56a8b507733c637dcc2466ae13288"
    meta-xilinx       = "mywork:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7"

because of the following line in
conf/machine/include/microblaze/arch-microblaze.inc:

    TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"soft", "", d)}"

If I delete the line I get:
    Build Configuration:
    BB_VERSION        = "1.15.3"
    TARGET_ARCH       = "microblaze"
    TARGET_OS         = "linux"
    MACHINE           = "spartan6-lx9mb"
    DISTRO            = "poky"
    DISTRO_VERSION    = "1.2+snapshot-20120908"
    TUNE_FEATURES     = "m32 fpu-soft"
    meta
    meta-yocto        = "master:5343cdb20ee56a8b507733c637dcc2466ae13288"
    meta-xilinx       = "mywork:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7"

Or if I modify the line to be:

    TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"", "", d)}"

I get:
    Build Configuration:
    BB_VERSION        = "1.15.3"
    TARGET_ARCH       = "microblaze"
    TARGET_OS         = "linux"
    MACHINE           = "spartan6-lx9mb"
    DISTRO            = "poky"
    DISTRO_VERSION    = "1.2+snapshot-20120908"
    TUNE_FEATURES     = "m32 fpu-soft"
    TARGET_FPU        = ""
    meta
    meta-yocto        = "master:5343cdb20ee56a8b507733c637dcc2466ae13288"
    meta-xilinx       = "mywork:d196fa93c7ff5e080d4c44e2b83aed472f32b2c7"

I don't know if one is better than the other, but in either case the
build of gcc-cross-initial_4.7.bb fails with:

    opening microblaze-c.o: No such file or directory

which is ironic since this is the same error message that originally
led you to suggest I try without the "el".

It appears as though gcc-cross-initial_4.7 is being configured with
the following options:

/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/work-shared/gcc-4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede-r11/git/configure
    --build=x86_64-linux
    --host=x86_64-linux
    --target=microblaze-poky-linux
    --prefix=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr
    --exec_prefix=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr
    --bindir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/bin/microblaze-poky-linux.gcc-cross-initial
    --sbindir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/bin/microblaze-poky-linux.gcc-cross-initial
    --libexecdir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/libexec/microblaze-poky-linux.gcc-cross-initial
    --datadir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/share
    --sysconfdir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/etc
    --sharedstatedir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/com
    --localstatedir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/var
    --libdir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/lib/microblaze-poky-linux.gcc-cross-initial
    --includedir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/include
    --oldincludedir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/include
    --infodir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/share/info
    --mandir=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux/usr/share/man
    --disable-silent-rules
    --disable-dependency-tracking
    --with-libtool-sysroot=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/x86_64-linux
    --with-newlib
    --without-headers
    --disable-shared
    --disable-threads
    --disable-multilib
    --disable-__cxa_atexit
    --enable-languages=c
    --enable-target-optspace
    --program-prefix=microblaze-poky-linux-
    --with-sysroot=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/sysroots/spartan6-lx9mb
    --with-build-sysroot=/home/trevor/devel/yocto/git-method/spartan6-lx9/tmp/work/microblaze-poky-linux/gcc-cross-initial-4.7.1.0+git1+d07e24f4ab59f264d68d21838795349faab5dede-r11/gcc-4_7-branch/build.x86_64-linux.microblaze-poky-linux/tmpsysroot
    --disable-libmudflap
    --disable-libgomp
    --disable-libssp
    --disable-libquadmath
    --with-system-zlib
    --disable-lto
    --disable-plugin
    --enable-decimal-float=no
    --disable-nls
    --enable-__cxa_atexit

I'll continue digging at the compiler, but all and any suggested
gladly welcomed. Two (or more things) are obviously fighting each
other since __cxa_atexit is both --disabled and --enabled. Is the
--with-newlib strange? Shouldn't there be a "-mcpu=" option in there
somewhere?

Does Xilinx have/use/suggest a particular version of gcc?

If I did have a filesystem ready to test and a board containing an
appropriate Xilinx part, do the free ISE tools allow me to work with
any soft cores, or do I need a paid license? (I also wonder how this
works for the Zynq board too).

Best regards,
    Trevor

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

Here's a status update, in case anyone is interested. My goal is to
use the Yocto Project to create an image for the Microblaze soft
processor core.

I started by adding the meta-xilinx layer and specifying:
    MACHINE = "spartan6-lx9mb"

This fails because the microblaze port of the gcc compiler does not
accept the soft FPU compile flag; this one is easy enough to get
around (the details can be found in earlier emails). Later the build
of the cross compiler fails because an object file is not found. Elvis
suggested switching from microblaze EL to "regular" microblaze. No
change; same failure in the same place.

I then started looking at Xilinx's website to see what they provided
in terms of a gcc compiler. Surfing to

    http://www.xilinx.com/guest_resources/gnu/

I find two sets of microblaze compiler tools: one based around
gcc-4.1.2/gdb-6.5/binutils-2.16/newlib-1.14 and another based around
gcc-4.6.2/gdb-7.3.50/binutils-2.21.53/newlib-1.19.

Unpacking any from the first set gives me a README file, 3 scripts to
run (build_binutils.sh,  build_gcc.sh (which calls
build_newlib_variants.sh), and build_gdb.sh). build_binutils.sh builds
binutils and gprof, build_gcc.sh builds a cross-gcc and several
variants of newlib. If I run the build_binutils.sh script binutils
builds okay but gprof fails. I can still run build_gcc.sh and both the
cross-compiler and the newlib variants are built. build_gdb.sh fails.
If I start by replacing my host's gcc-4.7.1 with gcc-4.1.2 gprof will
succeed but gdb will continue to fail.

I am not able to get either of the two packages based around gcc-4.6.2
(etc) to build using either my native gcc-4.7.1 or gcc-4.1.2.

So now that I had a cross-toolchain based around gcc-4.1.2 I started
looking at configuring yocto to use an external toolchain. That's when
I noticed Adrian had already provided recipes for using another,
pre-built, toolchain from Xilinx (awesome!):

    git://git.xilinx.com/xldk/microblaze_v2.0.git

So setup yocto for an external toolchain,

    TCMODE = "external-xilinx"
    XILINX_TOOLCHAIN = "<path to unpacked
toolchain>/microblaze_v2.0/microblaze-unknown-linux-gnu"

retrieved and unpacked this new toolchain (based around gcc-4.1.2),
and attempted a "bitbake core-image-minimal"

This fails too, when trying to configure libtool-cross for a couple of reasons:

| configure:3661: checking for C compiler version
| configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
--sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
--version >&5
| microblaze-unknown-linux-gnu-gcc (GCC) 4.1.2
| Copyright (C) 2006 Free Software Foundation, Inc.
| This is free software; see the source for copying conditions.  There is NO
| warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
| configure:3681: $? = 0
| configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
--sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
-v >&5
| Using built-in specs.
| Target: microblaze-unknown-linux-gnu
| Configured with:
/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/skeleton/build/crosstool-ng/targets/src/gcc-4.1.2/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=microblaze-unknown-linux-gnu
--prefix=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu
--with-sysroot=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu//sys-root
--enable-languages=c,c++ --enable-multilib --enable-__cxa_atexit
--with-local-prefix=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu//sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
| Thread model: posix
| gcc version 4.1.2
| configure:3681: $? = 0
| configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
--sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
-V >&5
| microblaze-unknown-linux-gnu-gcc: '-V' must come at the start of the
command line
| configure:3681: $? = 1
| configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
--sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
-qversion >&5
| microblaze-unknown-linux-gnu-gcc: unrecognized option '-qversion'
| microblaze-unknown-linux-gnu-gcc: no input files
| configure:3681: $? = 1
| configure:3701: checking whether the C compiler works
| configure:3723: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
--sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
-O2 -pipe -g -feliminate-unused-debug-types  -Wl,-O1
-Wl,--hash-style=gnu conftest.c  >&5
| cc1: error: unrecognized command line option "-m32"
| conftest.c:1: error: (v8.10a) is an invalid argument to -mcpu=

It is too bad libtool is required as part of core-image-minimal, that
seems kinda heavy for a minimal image. In any case I also gave
poky-tiny a spin but that didn't work either for the exact same
reason. My next steps are to try creating my own "minimal" images that
can hopefully get around libtool-cross. Another plan of action is to
try using meta-xilinx with one or more of the yocto releases to see if
that doesn't help create a clean build.

I would be interested in knowing if anyone else is interested in
microblaze. It would also be great to know if Xilinx is aware of this
and/or is working on this support.

I also can't help notice that on Aug. 28, 2012 Xilinx acquired
PetaLogix. I hope this helps improve Xilinx's public support for this
architecture :-)

Re: any success with spartan6-lx9mb?

[Khem Raj]

On Wed, Sep 12, 2012 at 11:47 AM, Trevor Woerner <twoerner@gmail.com> wrote:
> Here's a status update, in case anyone is interested. My goal is to
> use the Yocto Project to create an image for the Microblaze soft
> processor core.
>
> I started by adding the meta-xilinx layer and specifying:
>     MACHINE = "spartan6-lx9mb"
>
> This fails because the microblaze port of the gcc compiler does not
> accept the soft FPU compile flag; this one is easy enough to get
> around (the details can be found in earlier emails). Later the build
> of the cross compiler fails because an object file is not found. Elvis
> suggested switching from microblaze EL to "regular" microblaze. No
> change; same failure in the same place.
>
> I then started looking at Xilinx's website to see what they provided
> in terms of a gcc compiler. Surfing to
>
>     http://www.xilinx.com/guest_resources/gnu/
>
> I find two sets of microblaze compiler tools: one based around
> gcc-4.1.2/gdb-6.5/binutils-2.16/newlib-1.14 and another based around
> gcc-4.6.2/gdb-7.3.50/binutils-2.21.53/newlib-1.19.
>
> Unpacking any from the first set gives me a README file, 3 scripts to
> run (build_binutils.sh,  build_gcc.sh (which calls
> build_newlib_variants.sh), and build_gdb.sh). build_binutils.sh builds
> binutils and gprof, build_gcc.sh builds a cross-gcc and several
> variants of newlib. If I run the build_binutils.sh script binutils
> builds okay but gprof fails. I can still run build_gcc.sh and both the
> cross-compiler and the newlib variants are built. build_gdb.sh fails.
> If I start by replacing my host's gcc-4.7.1 with gcc-4.1.2 gprof will
> succeed but gdb will continue to fail.
>
> I am not able to get either of the two packages based around gcc-4.6.2
> (etc) to build using either my native gcc-4.7.1 or gcc-4.1.2.
>
> So now that I had a cross-toolchain based around gcc-4.1.2 I started
> looking at configuring yocto to use an external toolchain. That's when
> I noticed Adrian had already provided recipes for using another,
> pre-built, toolchain from Xilinx (awesome!):
>
>     git://git.xilinx.com/xldk/microblaze_v2.0.git
>
> So setup yocto for an external toolchain,
>
>     TCMODE = "external-xilinx"
>     XILINX_TOOLCHAIN = "<path to unpacked
> toolchain>/microblaze_v2.0/microblaze-unknown-linux-gnu"
>
> retrieved and unpacked this new toolchain (based around gcc-4.1.2),
> and attempted a "bitbake core-image-minimal"
>
> This fails too, when trying to configure libtool-cross for a couple of reasons:
>
> | configure:3661: checking for C compiler version
> | configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
> --sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
> --version >&5
> | microblaze-unknown-linux-gnu-gcc (GCC) 4.1.2
> | Copyright (C) 2006 Free Software Foundation, Inc.
> | This is free software; see the source for copying conditions.  There is NO
> | warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> |
> | configure:3681: $? = 0
> | configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
> --sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
> -v >&5
> | Using built-in specs.
> | Target: microblaze-unknown-linux-gnu
> | Configured with:
> /home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/skeleton/build/crosstool-ng/targets/src/gcc-4.1.2/configure
> --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
> --target=microblaze-unknown-linux-gnu
> --prefix=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu
> --with-sysroot=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu//sys-root
> --enable-languages=c,c++ --enable-multilib --enable-__cxa_atexit
> --with-local-prefix=/home/jwilliams/petalinux/petalinux-v1.00-devel/devel/packager/gnu/toolchains/../toolchains/tool-build/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu//sys-root
> --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
> --enable-long-long --enable-target-optspace
> | Thread model: posix
> | gcc version 4.1.2
> | configure:3681: $? = 0
> | configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
> --sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
> -V >&5
> | microblaze-unknown-linux-gnu-gcc: '-V' must come at the start of the
> command line
> | configure:3681: $? = 1
> | configure:3670: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
> --sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
> -qversion >&5
> | microblaze-unknown-linux-gnu-gcc: unrecognized option '-qversion'
> | microblaze-unknown-linux-gnu-gcc: no input files
> | configure:3681: $? = 1
> | configure:3701: checking whether the C compiler works
> | configure:3723: microblaze-unknown-linux-gnu-gcc  -m32  -mcpu=v8.10a
> --sysroot=/home/trevor/devel/microblaze/microblaze_v2.0/microblaze-unknown-linux-gnu/microblaze-unknown-linux-gnu/sys-root
> -O2 -pipe -g -feliminate-unused-debug-types  -Wl,-O1
> -Wl,--hash-style=gnu conftest.c  >&5
> | cc1: error: unrecognized command line option "-m32"
> | conftest.c:1: error: (v8.10a) is an invalid argument to -mcpu=
>


here find out from where is -m32 option coming from. It seems the
compiler you are hooking in does not like it. similarly it does not
seem to like mcpu=v8.10a they must be coming from tune-microblaze.inc
file. It could be that those tune files are written for gcc 4.6 and
not 4.1 as you are trying.


> It is too bad libtool is required as part of core-image-minimal, that
> seems kinda heavy for a minimal image.

its libtool-cross so its being built for some other packages that are
going into root file system having some libtool infra
libtool is not directly going into your image per se. But libtool is
very commonly used tool.

In any case I also gave
> poky-tiny a spin but that didn't work either for the exact same
> reason. My next steps are to try creating my own "minimal" images that
> can hopefully get around libtool-cross. Another plan of action is to
> try using meta-xilinx with one or more of the yocto releases to see if
> that doesn't help create a clean build.
>
> I would be interested in knowing if anyone else is interested in
> microblaze. It would also be great to know if Xilinx is aware of this
> and/or is working on this support.
>
> I also can't help notice that on Aug. 28, 2012 Xilinx acquired
> PetaLogix. I hope this helps improve Xilinx's public support for this
> architecture :-)
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: any success with spartan6-lx9mb?

[Elvis Dowson]

Hi Trevor,
                   I just briefly tried building it, using gcc-4.5.1, and got build failures too. It looks like it will take some effort to get this up and running with the current version of yocto. I just managed to get powerpc440 soft-float working with gcc-4.5.1 & eglibc-2.13 with a specific commit id for poky and meta-openembedded. Now I have to try and make that legacy gcc-4.5.1 support with with the latest poky and meta-openembedded master branch. Perhaps if you get a Xilinx SP601 board and dive in, you could help get microblaze up and running!

Best regards,

Elvis

Re: any success with spartan6-lx9mb?

[Khem Raj]

On Thu, Sep 13, 2012 at 9:36 AM, Elvis Dowson <elvis.dowson@gmail.com> wrote:
>
>                    I just briefly tried building it, using gcc-4.5.1, and got build failures too. It looks like it will take some effort to get this up and running with the current version of yocto. I just managed to get powerpc440 soft-float working with gcc-4.5.1 & eglibc-2.13 with a specific commit id for poky and meta-openembedded. Now I have to try and make that legacy gcc-4.5.1 support with with the latest poky and meta-openembedded master branch. Perhaps if you get a Xilinx SP601 board and dive in, you could help get microblaze up and running!

we always like good problem reports so if you find anything wrong with
core metadata we would be more than happy to help in fixing it.
Elvis, btw. I have done a patch for gcc 4.7 in master which should
help fix ppc/soft-float I dont know if it will help you but you could
try that out.

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

Hi guys,

Thanks for all the support so far. Currently I'm still trying to make
some headway with the Xilinx-supplied external toolchain (gcc-4.1.2).

When I saw the original errors I was having configuring libtool-cross
I was concerned about the "-V must be at start" and "unrecognized
option -qversion" problems I was having. Searching online wasn't
helping very much. But then Khem correctly pointed out (indirectly)
that those weren't any problem. libtool-cross's ./configure script was
simply examining the compiler tools to see if those options were okay
or not. The real problem (as Khem pointed out) was with the -m32 and
-mcpu= options.

Looking at an older version of
meta-xilinx/conf/machine/include/tune-microblazeel.inc (which was
committed by Adrian) showed that the -mcpu= option used to be:

    -mcpu=v8.10.a

instead of:

    -mcpu=v8.10a

So with the following patch to
meta-xilinx/conf/machine/include/tune-microblazeel.inc

-------------------------------------------------------------------
diff --git a/conf/machine/include/tune-microblazeel.inc
b/conf/machine/include/tune-microblazeel.inc
index a0cf7b7..1dc1bf3 100644
--- a/conf/machine/include/tune-microblazeel.inc
+++ b/conf/machine/include/tune-microblazeel.inc
@@ -4,13 +4,13 @@ DEFAULTTUNE ?= "microblazeel"
 require conf/machine/include/microblaze/arch-microblaze.inc

 TUNEVALID[microblazeel] = "Enable microblaze endian little optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"-mcpu=v8.10a", "", d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"-mcpu=v8.10.a", "", d)}"
 TUNE_PKGARCH = "${@bb.utils.contains("TUNE_FEATURES", "microblazeel",
"microblazeel", "microblazeel", d)}"

-TARGET_FPU = "soft"
+#TARGET_FPU = "soft"

 AVAILTUNES += "microblazeel"
-TUNE_FEATURES_tune-microblazeel = "m32 microblazeel"
+TUNE_FEATURES_tune-microblazeel = "microblazeel"
 PACKAGE_EXTRA_ARCHS_tune-microblazeel = "microblazeel"

 #MACHINEOVERRIDES .= "microblaze"
-------------------------------------------------------------------

and the following patch to
meta-xilinx/conf/machine/include/microblaze/arch-microblaze.inc

-------------------------------------------------------------------
diff --git a/conf/machine/include/microblaze/arch-microblaze.inc
b/conf/machine/include/microblaze/arch-microblaze.inc
index 485defa..f76f30e 100644
--- a/conf/machine/include/microblaze/arch-microblaze.inc
+++ b/conf/machine/include/microblaze/arch-microblaze.inc
@@ -2,16 +2,16 @@
 DEFAULTTUNE ?= "microblaze"

 TUNEVALID[m32] = "Microblaze ELF32 standard ABI"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
-TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
"microblaze", "", d)}"
+#TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "", "microblaze", "", d)}"

 TUNEVALID[fpu-soft] = "Use software FPU."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"-msoft-float", "", d)}"
-TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"soft", "", d)}"
+#TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"-msoft-float", "", d)}"
+#TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft",
"soft", "", d)}"

 TUNE_PKGARCH ?= "${TUNE_ARCH}"

 AVAILTUNES += "microblaze"
-TUNE_FEATURES_tune-microblaze ?= "m32 fpu-soft"
+#TUNE_FEATURES_tune-microblaze ?= "m32 fpu-soft"
 PACKAGE_EXTRA_ARCHS_tune-microblaze = "microblaze"
-------------------------------------------------------------------

Basically:
- remove any references to TARGET_FPU/fpu-soft/soft/FPU/...
- remove any references to m32/32/...
- change v8.10a to v8.10.a

I was able to get libtool-cross to configure.

While building libtool-cross, however, I encountered another problem,
something to do with "--hash-style=gnu" not supported. This problem I
was able to fix by adding the following line to my conf/local.conf:

    TARGET_LINK_HASH_STYLE = ""

With this last change I was able to get past libtool-cross which built
just fine.

The build then progresses for quite a while past that but then finally
fails trying to configure libffi:

  error: "libffi has not been ported to microblaze-unknown-linux-gnu."

So now I'm basically digging through the various layers to investigate
making my own really small "distribution". If all I really want to do
is get to a command-line, isn't all I _really_ need just a kernel,
busybox, and a small set of configuration files?

Re: any success with spartan6-lx9mb?

[Trevor Woerner]

PS simply BBMASK'ing out libffi doesn't help as too many things...
require(?) it (depend on it, rdepend on it...?)

ERROR: Nothing PROVIDES 'libffi' (but
/home/trevor/devel/yocto/gitrepo-method/poky/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
DEPENDS on or otherwise requires it)
NOTE: Runtime target 'udev' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['udev', 'glib-2.0', 'libffi']
NOTE: Runtime target 'packagegroup-core-boot' is unbuildable, removing...
Missing or unbuildable dependency chain was:
['packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi']
ERROR: Required build target 'core-image-minimal' has no buildable providers.
Missing or unbuildable dependency chain was: ['core-image-minimal',
'packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi']

Re: any success with spartan6-lx9mb?

[Khem Raj]

Trevor Woerner <twoerner@gmail.com> wrote:

>PS simply BBMASK'ing out libffi doesn't help as too many things...
>require(?) it (depend on it, rdepend on it...?)


You can try to make libffi as a package group in glib20 if possible other option would be to use something like mdev instead of udev
>
>ERROR: Nothing PROVIDES 'libffi' (but
>/home/trevor/devel/yocto/gitrepo-method/poky/meta/recipes-core/glib-2.0/glib-2.0_2.32.4.bb
>DEPENDS on or otherwise requires it)
>NOTE: Runtime target 'udev' is unbuildable, removing...
>Missing or unbuildable dependency chain was: ['udev', 'glib-2.0',
>'libffi']
>NOTE: Runtime target 'packagegroup-core-boot' is unbuildable,
>removing...
>Missing or unbuildable dependency chain was:
>['packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi']
>ERROR: Required build target 'core-image-minimal' has no buildable
>providers.
>Missing or unbuildable dependency chain was: ['core-image-minimal',
>'packagegroup-core-boot', 'udev', 'glib-2.0', 'libffi']

Re: any success with spartan6-lx9mb?

[Elvis Dowson]

Hi Trevor,

On Sep 13, 2012, at 10:17 PM, Trevor Woerner wrote:
> 
> ~$300 for the SP601 is certainly not too onerous. If I start to see
> more success with yocto I will definitely consider it.
> 
> Other options include:
> - qemu (maybe getting yocto to run/build a microblaze qemu image would be nice)
> - the spartan-6 version of the papilio board (which is either going to
> be a papilio plus or the papilio pro)
> 
> I do have one question though: if I had the SP601, would I be able to
> download (for free) an synthesize (using the freely available ISE
> tools) a microblaze and/or a PPC soft core? Or would I need to pay for
> those components (and if so, how much)?

There are two parts of the design suite, ISE (for VHDL and Verilog) 
development, and XPS (EDK) for re-using the Xilinx IP cores in
a project. To edit microblaze projects, you would need an EDK
license. The standard webpack only includes a license for the ISE
component, and is usually device locked to a particular set of 
devices, usually the low-end FPGAs.

The SP601 comes only with the WebPack software, so hmm no, not
suitable for what you want to do.

What you really need is the ISE Embedded Edition or System Edition,
in order to be able to configure your IP cores using the Xilinx
Base System Builder, so that you can design your peripherals
around a MicroBlaze (Virtex, Spartan) or ARM (Zynq) processor core.

There are no soft PowerPC IP cores, only hard PowerPC IP cores on
specific Virtex 4 (PPC405) / 5 (PPC440) FPGA variants, with the FXT designation. 

Xilinx stopped using PowerPC hard cores with the Virtex 5 series.

So, series-6 and series-7 FPGAs don't have PowerPC any more, and the only
option was to use a soft core processor like the microblaze. In the specific 
case of the Zynq series, they have a dual ARM Cortex-A9 hard core processor.

I find that the Spartan-6 Embedded Kit (SP605 + ISE Design Suite Embedded
Edition) gives you want you want, and the price listed on the website is USD$695.

http://www.xilinx.com/products/boards-and-kits/DK-S6-EMBD-G.htm

The other option is the Zynq-EPP 7020 platform which includes the base board
with the ARM processor, and ISE Design Suite System Edition for USD$895.

Best regards,

Elvis Dowson

Re: any success with spartan6-lx9mb?

[Adrian Alonso]

I just read most of the thread,

Is clear that another maintainer for meta-xilinx is needed :)

To summarize spartan6-lx9mb I only succeed in building an initramfs image, using
Xilinx prebuilt toolchain.

Check
recipes-core/images/initramfs-image
in microblaze-support branch

The only build step that I found are here
http://wiki.secretlab.ca/Poky_Linux_Microblaze_support

Which are for Microblaze in Virtex5 M507;

At the time that I was working to integrate Microblaze I never pass to
successfully build gcc (4.5.0)
but probably with newer gcc it could be different story.

Regards

On Thu, Sep 13, 2012 at 7:08 PM, Elvis Dowson <elvis.dowson@gmail.com> wrote:
>
> Hi Trevor,
>
> On Sep 13, 2012, at 10:17 PM, Trevor Woerner wrote:
> >
> > ~$300 for the SP601 is certainly not too onerous. If I start to see
> > more success with yocto I will definitely consider it.
> >
> > Other options include:
> > - qemu (maybe getting yocto to run/build a microblaze qemu image would be nice)
> > - the spartan-6 version of the papilio board (which is either going to
> > be a papilio plus or the papilio pro)
> >
> > I do have one question though: if I had the SP601, would I be able to
> > download (for free) an synthesize (using the freely available ISE
> > tools) a microblaze and/or a PPC soft core? Or would I need to pay for
> > those components (and if so, how much)?
>
> There are two parts of the design suite, ISE (for VHDL and Verilog)
> development, and XPS (EDK) for re-using the Xilinx IP cores in
> a project. To edit microblaze projects, you would need an EDK
> license. The standard webpack only includes a license for the ISE
> component, and is usually device locked to a particular set of
> devices, usually the low-end FPGAs.
>
> The SP601 comes only with the WebPack software, so hmm no, not
> suitable for what you want to do.
>
> What you really need is the ISE Embedded Edition or System Edition,
> in order to be able to configure your IP cores using the Xilinx
> Base System Builder, so that you can design your peripherals
> around a MicroBlaze (Virtex, Spartan) or ARM (Zynq) processor core.
>
> There are no soft PowerPC IP cores, only hard PowerPC IP cores on
> specific Virtex 4 (PPC405) / 5 (PPC440) FPGA variants, with the FXT designation.
>
> Xilinx stopped using PowerPC hard cores with the Virtex 5 series.
>
> So, series-6 and series-7 FPGAs don't have PowerPC any more, and the only
> option was to use a soft core processor like the microblaze. In the specific
> case of the Zynq series, they have a dual ARM Cortex-A9 hard core processor.
>
> I find that the Spartan-6 Embedded Kit (SP605 + ISE Design Suite Embedded
> Edition) gives you want you want, and the price listed on the website is USD$695.
>
> http://www.xilinx.com/products/boards-and-kits/DK-S6-EMBD-G.htm
>
> The other option is the Zynq-EPP 7020 platform which includes the base board
> with the ARM processor, and ISE Design Suite System Edition for USD$895.
>
> Best regards,
>
> Elvis Dowson
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto




--
Saludos
Adrian Alonso
http://aalonso.wordpress.com