walnux/Documentation/platforms/renesas/m16c/boards/skp16c26/index.rst
Matteo Golin 387b0e4115 docs/skp16c26: Migrated legacy README.txt to rst format
Migrated the legacy README.txt file to rst.

Signed-off-by: Matteo Golin <matteo.golin@gmail.com>
2025-09-12 07:20:04 +02:00

137 lines
4.3 KiB
ReStructuredText

========
SKP16C26
========
.. tags:: arch:renesas
1. The buildroot package can be used to build an M16C toolchain. The toolchain
buildroot can be downloaded from buildroot in the NuttX GIT. Instructions for
building the toolchain are provided below.
However, the target cannot be built because the GNU m16c-nuttx-elf-ld link
fails with the following message:
.. code:: console
m32c-nuttx-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482
Where the reference line is:
.. code:: c
/* If the symbol is out of range for a 16-bit address,
we must have allocated a plt entry. */
BFD_ASSERT (*plt_offset != (bfd_vma) -1);
No workaround is known at this time. This is a show stopper for M16C.
2. A supported version of the M16C toolchain is available here:
http://www.kpitgnutools.com/index.php
This download is free but requires registration. Unfortunately, this v0901 of
this toolchain shows the same behavior:
.. code:: console
c:\Hew3\Tools\KPIT Cummins\GNUM16CM32C-ELF\v0901\m32c-elf\bin\m32c-elf-ld.exe: BFD (GNU Binutils) 2.19-GNUM16CM32C_v0901 assertion fail /home/kpit/fsfsrc/binutils-2.19/bfd/elf32-m32c.c:482
It is possible that this error message may be telling me -- a very roundabout way --
that I have exceeded the FLASH region, but I think that unlikely (it is difficult
to know if the link does not complete gracefully).
Building the R8C/M16C/M32C GNU Toolchain Using Buildroot
========================================================
.. warning::
See the toolchain issues above -- you may not want to waste your time.
1. CD to the correct directory.
Change to the directory just above the NuttX installation. If <nuttx-dir> is
where NuttX is installed, then cd to <nuttx-dir>/..
2. Get and Install the buildroot Module
a. Using a release tarball:
.. code:: console
$ cd <nuttx-dir>/..
Download the appropriate buildroot package.
unpack the buildroot package
rename the directory to buildroot
b. Using GIT
Check out the buildroot module. GIT checkout instructions:
.. code:: console
$ git clone https://patacongo@bitbucket.org/nuttx/buildroot.git buildroot
Make the archive directory:
.. code:: console
$ mkdir archive
The ``<nuttx-dir>/../buildroot`` is where the toolchain is built;
The ``<nuttx-dir>/../archive`` directory is where toolchain sources will be downloaded.
3. Make sure that NuttX is configured
.. code:: console
$ cd <nuttx-dir>
$ tools/configure.sh <nuttx-configuration>
4. Configure and Make the buildroot
.. code:: console
$ cd <buildroot-dir>
$ cp boards/m32c-defconfig-4.2.4 .config
$ make oldconfig
$ make
This will download the large source packages for the toolchain and build the toolchain.
The resulting binaries will be under buildroot/build_m32c. There will also be a
large build directory called toolchain_build_m32c; this directory can be removed once
the build completes successfully.
Cygwin GCC BUILD NOTES
======================
On Cygwin, the buildroot 'make' command will fail with an error like:
.. code:: console
build/genchecksum cc1-dummy > cc1-checksum.c
opening cc1-dummy: No such file or directory
This is caused because on Cygwin, host executables will be generated with the
extension .exe and, apparently, the make variable "exeext" is set incorrectly. A
workaround after the above occurs is:
.. code:: console
$ cd toolchain_build_m32c/gcc-4.2.4-initial/gcc # Go to the directory where error occurred
$ mv cc1-dummy.exe cc1-dummy # Rename the executable without .exe
$ rm cc1-checksum.c # Get rid of the bad generated file
Then resume the buildroot make:
.. code:: console
$ cd - # Back to the buildroot make directory
$ make # Restart the build
GCC is built twice. First an initial "bootstrap" GCC is produced in
toolchain_build_m32c/gcc-4.2.4-initial, then the final GCC is produced in
toolchain_build_m32c/gcc-4.2.4-final. The above error will occur twice: Once for
the initial GCC build (see above) and once for the final GCC build. For the
final GCC build, the workaround is the same except that the directory will be
toolchain_build_m32c/gcc-4.2.4-final/gcc.