This is an automated email from the ASF dual-hosted git repository.

raiden00 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx.git

commit 387b0e41158f48a20addd0664cb4cadeea50645f
Author: Matteo Golin <matteo.go...@gmail.com>
AuthorDate: Thu Sep 11 20:11:08 2025 -0400

    docs/skp16c26: Migrated legacy README.txt to rst format
    
    Migrated the legacy README.txt file to rst.
    
    Signed-off-by: Matteo Golin <matteo.go...@gmail.com>
---
 .../renesas/m16c/boards/skp16c26/README.txt        | 110 -----------------
 .../renesas/m16c/boards/skp16c26/index.rst         | 135 ++++++++++++++++++++-
 2 files changed, 133 insertions(+), 112 deletions(-)

diff --git a/Documentation/platforms/renesas/m16c/boards/skp16c26/README.txt 
b/Documentation/platforms/renesas/m16c/boards/skp16c26/README.txt
deleted file mode 100644
index 4df78aa3cb8..00000000000
--- a/Documentation/platforms/renesas/m16c/boards/skp16c26/README.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-Documentation/platforms/renesas/m16c/boards/skp16c26/README.txt
-^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-1. The buildroot package can be used to build an M16C toolchain.  The toolchain
-   buildroot can be downloaded from buildroot in the NuttX GIT.  Insructions
-   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:
-
-     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:
-
-     /* 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:
-
-   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
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-NOTE:  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:
-
-     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:
-
-        git clone https://pataco...@bitbucket.org/nuttx/buildroot.git buildroot
-
-     Make the archive directory:
-
-       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
-
-     cd <nuttx-dir>
-     tools/configure.sh <nuttx-configuration>
-
-4. Configure and Make the buildroot
-
-     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:
-
-   "...
-      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 work 
around after the
-   above occurs is:
-
-      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:
-
-      cd -                                             # Back to the buildroot 
make directory
-      make                                             # Restart the build
-
-   GCC is built twice.  First a 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.
diff --git a/Documentation/platforms/renesas/m16c/boards/skp16c26/index.rst 
b/Documentation/platforms/renesas/m16c/boards/skp16c26/index.rst
index deee0d130a9..bb1cbf0c548 100644
--- a/Documentation/platforms/renesas/m16c/boards/skp16c26/index.rst
+++ b/Documentation/platforms/renesas/m16c/boards/skp16c26/index.rst
@@ -2,5 +2,136 @@
 SKP16C26
 ========
 
-.. include:: README.txt
-   :literal:
+.. 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://pataco...@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.

Reply via email to