Loading ...
Sorry, an error occurred while loading the content.
 

buildroot

Expand Messages
  • harald_kubota
    Hi, Building a tool chain with the provided buildroot package is not that straightforward. 1. The location of where the buildroot-0.1.5 was not clear to me
    Message 1 of 8 , May 5, 2009
      Hi,

      Building a tool chain with the provided buildroot package is not that straightforward.

      1. The location of where the buildroot-0.1.5 was not clear to me (Inside nuttx? Outside of it? Answer: Outside.)
      2. When extracting nuttx, it's creating a nuttx-0.4.5 directory. The buildroot scripts expect a directory called "nuttx". And even a symbolic link won't help.

      Although I do have a working arm-elf toolchain, it could not link the mcu123-lpc214x/ostest package. Thus I very much appreciate a known-to-work tool chain which is NOT provided as a binary.

      Harald

      ...to be continued...
    • Gregory Nutt
      ... If everything is set right, it should be just a matter of typing make and waiting a hour or so. But, yes, that is a lot of complexity under the hood. If
      Message 2 of 8 , May 5, 2009
        --- In nuttx@yahoogroups.com, "harald_kubota" <hkubota@...> wrote:
        > Building a tool chain with the provided buildroot package is not that straightforward.

        If everything is set right, it should be just a matter of typing make and waiting a hour or so. But, yes, that is a lot of complexity under the hood. If things don't work as expected, it is good to ask questions.

        > 1. The location of where the buildroot-0.1.5 was not clear to me (Inside nuttx? Outside of it? Answer: Outside.)

        Yes. There are instructions inside the tarball at configs/README.txt. See
        http://nuttx.cvs.sourceforge.net/viewvc/*checkout*/nuttx/misc/buildroot/configs/README.txt?revision=1.10

        You can actually put the buildroot anywhere you want to. But if you use the default setenv.sh script to set your PATH variable, then it will expect to find the toolchain at a particular location. Of course you can build the toolchain anywhere you want, but you will have to change your PATH variable to match. You can change the following line in your setenv.sh file to whereever you want the toolchain:

        export BUILDROOT_BIN=${WD}/../buildroot/build_arm_nofpu/staging_dir/bin

        > 2. When extracting nuttx, it's creating a nuttx-0.4.5 directory. The buildroot scripts expect a directory called "nuttx". And even a symbolic link won't help.

        Yes. The buildroot has a configuration file that includes the path to the NuttX directory. The directory name you use does not matter, but the name of the NuttX directory must match the name in the buildroot/.config file. The default name in that .config file is nuttx. The path in the buildroot/.config file must be the same path.

        There are two choices:

        1. Change the path in the setenv.sh file:

        mv nuttx-0.4.5 nuttx

        2. Or, change the path in the .config file:

        From: BR2_NUTTX_DIR="$(TOPDIR)/../nuttx"
        To: BR2_NUTTX_DIR="$(TOPDIR)/../nuttx-0.4.5"


        > Although I do have a working arm-elf toolchain, it could not link the mcu123-lpc214x/ostest package. Thus I very much appreciate a known-to-work tool chain which is NOT provided as a binary.

        What link problem are you having? It wouldn't happen to be the one mentioned in the buildroot/configs/README.txt file would it? A fix for that one is in this email thread: http://tech.groups.yahoo.com/group/nuttx/message/41

        Good luck,

        Let me of any problems you have. I'm sure we can get you up and running without too much trouble.

        Greg
      • harald_kubota
        ... That did not take long... Got an error already: This target does not support --with-abi. Building on Ubuntu 9.04 with gcc-4.3.3 on x86_64. I changed OABI
        Message 3 of 8 , May 5, 2009
          >
          > ...to be continued...
          >

          That did not take long...

          Got an error already:

          This target does not support --with-abi.

          Building on Ubuntu 9.04 with gcc-4.3.3 on x86_64.

          I changed OABI into EABI but that did not help.
          Testing with gcc-4.3.3 now (and binutils-2.19.1 as I am pushing my luck here). Got a Cortex-M3 here, so I might need gcc-4.3.3 anyway.
        • Gregory Nutt
          ... That is odd, I just built the Cortex-M3 toolchain on SuSE 11.1 this morning. I am not sure what kind of environmental differences could cause this
          Message 4 of 8 , May 5, 2009
            --- In nuttx@yahoogroups.com, "harald_kubota" <hkubota@...> wrote:
            > ...
            > This target does not support --with-abi.
            >
            > Building on Ubuntu 9.04 with gcc-4.3.3 on x86_64.

            That is odd, I just built the Cortex-M3 toolchain on SuSE 11.1 this morning. I am not sure what kind of environmental differences could cause this different behavior.

            You should be able to suppress the --with-abi configuration option in the following way:

            1. In the buildroot directory, edit Config.in. Edit the following line:

            choice
            prompt "Target ABI"
            depends BR2_arm || BR2_armeb
            - defualt BR2_ARM_OABI
            + default BR2_ARM_OABI if !BR2_cortex_m3
            + default BR2_ARM_NOABI if BR2_cortex_m3
            help
            Application Binary Interface to use

            config BR2_ARM_OABI
            bool "OABI"
            config BR2_ARM_EABI
            bool "EABI"
            + config BR2_ARM_NOABI
            + bool "None"
            endchoice

            2. make oldconfig. Look at .config. The string BR2_GCC_TARGET_ABI should be empty or undefined. It is checked in toolchain/gcc/Makefile.in to see it it will add the --with-abi configuration option.

            I also have a Cortex-M3 port on my plate. I will be starting that in a couple of weeks when I receive hardware.

            Greg
          • Gregory Nutt
            ... Scratch that last response. I see what is going on -- I needed a little more information. You are not making the cortexm3-defconfig-4.3.3 -- that builds
            Message 5 of 8 , May 5, 2009
              --- In nuttx@yahoogroups.com, "harald_kubota" <hkubota@...> wrote:
              > Got an error already:
              >
              > This target does not support --with-abi.
              >
              > Building on Ubuntu 9.04 with gcc-4.3.3 on x86_64.

              Scratch that last response. I see what is going on -- I needed a little more information. You are not making the cortexm3-defconfig-4.3.3 -- that builds fine. You are talking about the older arm-defconfig that builds the gcc-3.4.6 toolchain, right?

              I just duplicated your problem here using the configs/arm-defconfig configuration. Yes, you are right. I broke the gcc-3.x.x build with some of the last checkins. I have also checked the correct fix into CVS. Here is a patch that you can use now to get the gcc-3.4.6 build working correctly:


              Index: gcc-nuttx-3.x.mk
              ===================================================================
              RCS file: /cvsroot/nuttx/misc/buildroot/toolchain/gcc/gcc-nuttx-3.x.mk,v
              retrieving revision 1.8
              diff -u -r1.8 gcc-nuttx-3.x.mk
              --- gcc-nuttx-3.x.mk 25 Apr 2009 19:12:24 -0000 1.8
              +++ gcc-nuttx-3.x.mk 6 May 2009 00:44:12 -0000
              @@ -123,7 +123,7 @@
              $(THREADS) \
              $(MULTILIB) \
              $(SOFT_FLOAT_CONFIG_OPTION) \
              - $(GCC_WITH_ABI) $(GCC_WITH_ARCH) $(GCC_WITH_TUNE) $(GCC_WITH_MODE) \
              + $(GCC_WITH_ARCH) $(GCC_WITH_TUNE) $(GCC_WITH_MODE) \
              $(GCC_USE_SJLJ_EXCEPTIONS) \
              $(DISABLE_LARGEFILE) \
              $(EXTRA_GCC_CONFIG_OPTIONS));

              The change is, just remove $(GCC_WITH_ABI).

              After changing the gcc-nuttx-3.x.mk file, be sure to remove the toolchain_build_arm_nofpu/gcc-3.4.6-build directory before restarting the make (otherwise, it will use the bad, cached settings for the configuration).

              Greg
            • Harald Kubota
              ... Right. ... Awesome support here :-) Game me another error though: gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes
              Message 6 of 8 , May 5, 2009
                Gregory Nutt wrote:
                > You are talking about the older arm-defconfig that builds the gcc-3.4.6 toolchain, right?
                >
                >
                Right.


                > I just duplicated your problem here using the configs/arm-defconfig configuration. Yes, you are right. I broke the gcc-3.x.x build with some of the last checkins. I have also checked the correct fix into CVS.

                Awesome support here :-)

                Game me another error though:
                gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
                -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
                -DHAVE_CONFIG_H -I.
                -I.-I/home/harald/uController/LPC/buildroot-0.1.5/toolchain_build_arm_nofpu/gcc-3.4.6/gcc
                -I/home/harald/uController/LPC/buildroot-0.1.5/toolchain_build_arm_nofpu/gcc-3.4.6/gcc/.
                -I/home/harald/uController/LPC/buildroot-0.1.5/toolchain_build_arm_nofpu/gcc-3.4.6/gcc/../include
                \
                -DTARGET_MACHINE=\"arm-elf\" \
                -c
                /home/harald/uController/LPC/buildroot-0.1.5/toolchain_build_arm_nofpu/gcc-3.4.6/gcc/collect2.c
                -o collect2.o
                In function ‘open’,
                inlined from ‘collect_execute’ at
                /home/harald/uController/LPC/buildroot-0.1.5/toolchain_build_arm_nofpu/gcc-3.4.6/gcc/collect2.c:1537:
                /usr/include/bits/fcntl2.h:51: error: call to ‘__open_missing_mode’
                declared with attribute error: open with O_CREAT in second argument
                needs 3 arguments

                The line in question in collect2.c is:

                redir_handle = open (redir, O_WRONLY | O_TRUNC | O_CREAT);

                That one needs a create mode like 0644 as 3rd argument if I remember
                correctly. That looks like a gcc problem though, not something NuttX
                needs to fix.

                Anyway, the fix for that was easy and it helped. Now off I go to port
                this to another LPC2148 board!

                Harald
              • Gregory Nutt
                ... I created a patch an checked it into CVS. This patch will automatically be applied and will add the 3rd mode argument to the open call when gcc-3.4.6 is
                Message 7 of 8 , May 5, 2009
                  --- In nuttx@yahoogroups.com, Harald Kubota <hkubota@...> wrote:
                  > The line in question in collect2.c is:
                  >
                  > redir_handle = open (redir, O_WRONLY | O_TRUNC | O_CREAT);
                  >
                  > That one needs a create mode like 0644 as 3rd argument if I remember
                  > correctly. That looks like a gcc problem though, not something NuttX
                  > needs to fix.

                  I created a patch an checked it into CVS. This patch will automatically be applied and will add the 3rd mode argument to the open call when gcc-3.4.6 is unpacked.

                  Thanks for the find!
                  Greg
                • Harald Kubota
                  If anyone cares: porting nuttx to another LPC2148 board takes next to no time once the compiling issue is fixed. And fixing those did not take a long time.
                  Message 8 of 8 , May 6, 2009
                    If anyone cares: 'porting' nuttx to another LPC2148 board takes next to
                    no time once the compiling issue is fixed. And fixing those did not take
                    a long time. ostest worked right out of the box. As did nsh.

                    And the even better news is: adding a command to nsh is done in less
                    than 1h. Now I can toggle LEDs with a "led x" command with x=0..7

                    I wish all software I have to work with would be so pleasant to use!

                    Harald
                  Your message has been successfully submitted and would be delivered to recipients shortly.