Documentation: migrate the rest boards

- migrated /README are removed from /boards

- there are a lot of READMEs that should be further converted to rst.
  At the moment they are moved to Documentation/platforms and included in rst files
This commit is contained in:
raiden00pl
2023-10-25 20:28:04 +02:00
committed by Alan Carvalho de Assis
parent d77dff786b
commit 56529d2944
370 changed files with 2475 additions and 2493 deletions
-110
View File
@@ -1,110 +0,0 @@
boards/renesas/m16c/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 hhttps://patacongo@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.
@@ -1,419 +0,0 @@
README
======
This README file discusses the port of NuttX to “GR-ROSE” board produced by Gadget Renesas.This board features the RX65N (R5F565NEHDFP 100pin QFP)
Contents
========
- Board Features
- Status/Open Issues
- Serial Console
- LEDs
- Networking
- Contents
- RTC
- USB Device
- RSPI
- RIIC
- DTC
- USB Host
- USB Host Hub
- Debugging
Board Features
==============
- Micro controller - RX65N (R5F565NEHDFP 100pin QFP) RXv2 core [34 CoreMark/mA]
- ROM/RAM - 2MB/640KB
- Operating Frequency - 120MHz(12MHz 10 Multiplication)
- RTC Clock - 32.768kHz
- Sensors - Temperature(inside MCU)
- ROS I/F - Ethernet, USB(rosserial)
- Serial Servo I/F - TTL x 4, RS-485 x 1
- Analog I/F - ADC(12bit) x 6, DAC x 1
- Wireless - IEEE 802.11b/g/n
- PMOD I/F - 1 (I2C, SPI, UART)
- External power supply - USB VBUS or 4.5V18V
- Supply to external - 3.3V, 5V
See the RX65N GRROSE website for further information about this board:
- http://gadget.renesas.com/en/product/rose.html
Serial Console
==============
RX65N GRROSE supports 12 serial ports (SCI0 - SCI12), however only 5 ports can be tested(SCI0, SCI1, SCI2,
SCI5 & SCI6).
Please find the pin configurations for SCI0, SCI1, SCI2, SCI5 & SCI6
SCI0 Pin Configuration :
-----------
RX65N GRROSE
Function
-----------
P21 RXD0
P20 TXD0
------------
SCI1 Pin Configuration :
-----------
RX65N GRROSE
Function
-----------
P30 RXD1
P26 TXD1
------------
SCI2 Pin Configuration :
-----------
RX65N GRROSE
Function
-----------
P12 RXD2
P13 TXD2
------------
SCI3 Pin Configuration :
-----------
RX65N GRROSE
Function (connected to WiFi module)
-----------
P25 RXD3
P23 TXD3
------------
SCI5 Pin Configuration :
-----------
RX65N GRROSE
Function
-----------
PC2 RXD5
PC3 TXD5
------------
SCI6 Pin Configuration :
-----------
RX65N GRROSE
Function
-----------
P33 RXD6
P32 TXD6
------------
SCI8 Pin Configuration :
-----------
RX65N GRROSE
Function (Half duplication mode with RS485 driver)
-----------
PC6 RXD8
PC7 TXD8
PC5 Direction (L=TX, H=RX)
Serial Connection Configuration
--------------------------
1. GRROSE board needs to be connected to PC terminal, using USB to Serial Chip.
2. Connect TX of USB to serial chip to RX of SCIX(0,1,2,5,6)
3. Connect RX of USB to serial chip to TX of SCIX(0,1,2,5,6)
4. Connect GND to GND pin.
5. Configure Teraterm to 115200 baud.
LEDs
====
The RX65N GRROSE board has 2 LED's, 1 Power LED(LED3) and 2 User LED's(LED1, LED2),which are enabled through software.
If enabled the LED is simply turned on when the board boots
successfully, and is blinking on panic / assertion failed.
Networking
==========
Ethernet Connections
-----------
------ ---------
RX65N
GRROSE Ethernet
Pin Function
------ ---------
PA4 ET0_MDC
PA3 ET0_MDIO
PB2 REF50CK0
PB7 RMII0_CRS_DV
PB1 RMII0_RXD0
PB0 RMII0_RXD1
PB3 RMII0_RX_ER
PB5 RMII0_ETXD0
PB6 RMII0_ETXD1
PB4 RMII0_TXD_EN
PA5 ET0_LINKSTA
PA6_ET_RST ETHER reset
------ ---------
NuttX Configurations
---------------
The following configurations, need to be enabled for network.
CONFIG_RX65N_EMAC=y : Enable the EMAC Peripheral for RX65N
CONFIG_RX65N_EMAC0=y : Enable the EMAC Peripheral for RX65N
CONFIG_RX65N_EMAC0_PHYSR=30 : Address of PHY status register on LAN8720A
CONFIG_RX65N_EMAC0_PHYSR_100FD=0x18 : Needed for LAN8720A
CONFIG_RX65N_EMAC0_PHYSR_100HD=0x08 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_10FD=0x14 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_10HD=0x04 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_ALTCONFIG=y : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_ALTMODE=0x1c : " " " " " "
CONFIG_RX65N_EMAC0_RMII=y
CONFIG_RX65N_EMAC0_PHYADDR=0 : LAN8720A PHY is at address 1
CONFIG_SCHED_WORKQUEUE=y : Work queue support is needed
CONFIG_SCHED_HPWORK=y : High Priority Work queue support
CONFIG_SCHED_LPWORK=y : Low Priority Work queue support
Using the network with NSH
--------------------------
The IP address is configured using DHCP, using the below mentioned configurations :
The IP address is configured using DHCP, using the below mentioned configurations :
CONFIG_NETUTILS_DHCPC=y
CONFIG_NETUTILS_DHCPD=y
CONFIG_NSH_DHCPC=y
CONFIG_NETINIT_DHCPC=y
nsh> ifconfig
eth0 HWaddr 00:e0:de:ad:be:ef at UP
IPaddr:10.75.24.53 DRaddr:10.75.24.1 Mask:255.255.254.0
You can use ping to test for connectivity to the host (Careful,
Window firewalls usually block ping-related ICMP traffic). On the
target side, you can:
nsh> ping 10.75.24.250
PING 10.75.24.250 56 bytes of data
56 bytes from 10.75.24.250: icmp_seq=1 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=2 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=3 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=4 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=5 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=6 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=7 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=8 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=9 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=10 time=0 ms
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
On the host side, you should also be able to ping the RX65N-GRROSE:
$ ping 10.75.24.53
Configure UDP blaster application as mentioned below :
CONFIG_EXAMPLES_UDPBLASTER_HOSTIP=0x0a4b1801 (10.75.24.1) ------> Gateway IP
CONFIG_EXAMPLES_UDPBLASTER_NETMASK=0xfffffe00 (255.255.254.0) --------> Netmask
CONFIG_EXAMPLES_UDPBLASTER_TARGETIP=0x0a4b189b (10.75.24.155) ---------> Target IP
RSPI
-----------
For GRROSE board only channel 1 can be tested since RSPI channel1 pinout is only brought out as
Pin number 2 and 3 in CN4 is used for MOSIB and MISOB respectively.
USB Host
=============
For the RX65N RSK2MB board, to be used as USB Device, the following Jumper settings need to be done
J7 Short Pin 1 & Pin 2
J16 Short Pin 2 & Pin 3
USB Device
=============
For the RX65N RSK2MB board, to be used as USB Device, the following Jumper settings need to be done
J7 Short Pin 2 & Pin 3
J16 Short Pin 1 & Pin 2
RTC
==========
NuttX Configurations
---------------
The configurations listed in Renesas_RX65N_NuttX_RTC_Design.doc need to be enabled.
RTC Testing
------------------
The test cases mentioned in Renesas_RX65N_RTC_Test_Cases.xls are to be executed
as part of RTC testing.
The following configurations are to be enabled as part of testing RTC examples.
CONFIG_EXAMPLES_ALARM
CONFIG_EXAMPLES_PERIODIC
CONFIG_EXAMPLES_CARRY
USB Device Configurations
--------------------------
The following configurations need to be enabled for USB Device
CONFIG_USBDEV
CONFIG_CDCACM
CONFIG_STDIO_BUFFER_SIZE=64
CONFIG_STDIO_LINEBUFFER
USB Device Testing
------------------------
The following testing is executed as part of USB Device testing on RX65N target for GRROSE board
echo "This is a test for USB Device" > /dev/ttyACM0
xd 0 0x20000 > /dev/ttyACM0
The output of the commands mentioned above should be seen on the USB Device COM port on teraterm
RSPI Configurations
--------------------------
The following configurations need to be enabled for RSPI
CONFIG_SYSTEM_SPITOOL=y
RSPI Testing
------------------------
The following testing is executed as part of RSPI testing on RX65N target for GRROSE board
On GRROSE board only channel 1 can be tested since RSPI channel1 pinout is only brought out.
Following command can be used for testing RSPI communication to slave device.
spi exch -b 0 -x 4 aabbccdd
where b is bus number and x is Number of word to exchange.
RIIC Configurations
--------------------------
The following configurations need to be enabled for RIIC
CONFIG_SYSTEM_I2CTOOL=y
RIIC Testing
------------------------
On GRROSE board, none of the RIIC channel pins are brought out in the board so not tested for communication.
DTC Configurations
--------------------------
The following configurations need to be enabled for DTC.
CONFIG_SYSTEM_SPITOOL=y
DTC Testing
------------------------
DTC has been tested using RSPI driver.
USB Host Configurations
--------------------------
The following configurations need to be enabled for USB Host Mode driver to
support USB HID Keyboard class and MSC Class.
CONFIG_USBHOST=y
CONFIG_USBHOST_HIDKBD=y
CONFIG_FS_FAT=y
CONFIG_EXAMPLES_HIDKBD=y
USB Host Driver Testing
------------------------
The Following Class Drivers were tested as mentioned below :
- USB HID Keyboard Class
On the NuttX Console "hidkbd" application was executed
nsh> hidkbd
The characters typed from the keyboard were executed correctly.
- USB MSC Class
The MSC device is enumerated as sda in /dev directory.
The block device is mounted using the command as mentioned below :
mount -t vfat /dev/sda /mnt
The MSC device is mounted in /dev directory
The copy command is executed to test the Read/Write functionality
cp /mnt/<file.txt> /mnt/file_copy.txt
USB Host Hub Configurations
--------------------------
The following configurations need to be enabled for USB Host Mode driver to
support USB HID Keyboard class and MSC Class.
CONFIG_RX65N_USBHOST=y
CONFIG_USBHOST_HUB=y
CONFIG_USBHOST_ASYNCH=y
CONFIG_USBHOST=y
CONFIG_USBHOST_HIDKBD=y
CONFIG_FS_FAT=y
CONFIG_EXAMPLES_HIDKBD=y
USB Host Hub Driver Testing
------------------------
The Following Class Drivers were tested as mentioned below :
- USB HID Keyboard Class
On the NuttX Console "hidkbd" application was executed
nsh> hidkbd
The characters typed from the keyboard were executed correctly.
- USB MSC Class
The MSC device is enumerated as sda in /dev directory.
The block device is mounted using the command as mentioned below :
mount -t vfat /dev/sda /mnt
The MSC device is mounted in /dev directory
The copy command is executed to test the Read/Write functionality
cp /mnt/<file.txt> /mnt/file_copy.txt
Debugging
==========
1. NuttX needs to be compiled in Cygwin.
The following Configuration needs to be set, in order to do source level debugging.
CONFIG_DEBUG_SYMBOLS = y (Set this option, using menuconfig only, DO NOT Enable this as default configuration).
2. Download & Install Renesas e2studio IDE.
3. Load the project(NuttX built on Cygwin) as Makefile project with existing code
4. Right click on the project, and select Debug Configurations.
5. The binary(NuttX) needs to be loaded using E1/E2 Emulator.
6. Select the Device name as R5F565NE and Emulator as E1/E2(whichever is being used)
7. Select Connection type as FINE.
8. Load and run the binary.
Flashing NuttX
===============
Alternatively, NuttX binary can be flashed using Renesas flash programmer tool without using e2 studio/Cygwin
Below are the steps mentioned to flash NuttX binary using Renesas flash programmer tool(RFP).
1.In order to flash using Renesas flash programmer tool, nuttx.mot file should be generated.
2. Add the following lines in tools/Unix.mk file :
ifeq ($(CONFIG_MOTOROLA_SREC),y)
@echo "CP: nuttx.mot"
$(Q) $(OBJCOPY) $(OBJCOPYARGS) $(BIN) -O srec -I elf32-rx-be-ns nuttx.mot
endif
3. Add CONFIG_MOTOROLA_SREC=y in defconfig file or choose make menucofig->Build Setup-> Binary Output Format->
Select Motorola SREC format.
4. Download Renesas flash programmer tool from https://www.renesas.com/in/en/products/software-tools/tools/programmer/renesas-flash-programmer-programming-gui.html#downloads
5. Refer to the user manual document, for steps to flash NuttX binary using RFP tool.
@@ -1,89 +0,0 @@
README
======
Overview
--------
This directory contains logic to support a custom ROMFS system-init script
and start-up script. These scripts are used by by the NSH when it starts
provided that CONFIG_NSH_ARCHROMFS=y. These scripts provide a ROMFS volume
that will be mounted at /etc and will look like this at run-time:
NuttShell (NSH) NuttX-8.2
nsh> ls -Rl /etc
/etc:
dr-xr-xr-x 0 .
-r--r--r-- 20 group
dr-xr-xr-x 0 init.d/
-r--r--r-- 35 passwd
/etc/init.d:
dr-xr-xr-x 0 ..
-r--r--r-- 110 rcS
-r--r--r-- 110 rc.sysinit
nsh>
/etc/init.d/rc.sysinit is system init script; /etc/init.d/rcS is the start-up
script; /etc/passwd is a the password file. It supports a single user:
USERNAME: admin
PASSWORD: Administrator
nsh> cat /etc/passwd
admin:8Tv+Hbmr3pLVb5HHZgd26D:0:0:/
The encrypted passwords in the provided passwd file are only valid if the
TEA key is set to: 012345678 9abcdef0 012345678 9abcdef0. Changes to either
the key or the password word will require regeneration of the nsh_romfimg.h
header file.
The format of the password file is:
user:x:uid:gid:home
Where:
user: User name
x: Encrypted password
uid: User ID (0 for now)
gid: Group ID (0 for now)
home: Login directory (/ for now)
/etc/group is a group file. It is not currently used.
nsh> cat /etc/group
root:*:0:root,admin
The format of the group file is:
group:x:gid:users
Where:
group: The group name
x: Group password
gid: Group ID
users: A comma separated list of members of the group
/etc/init.d/rcS should have the following contents :
vi rcS
echo "This is NuttX"
Updating the ROMFS File System
------------------------------
The content on the nsh_romfsimg.h header file is generated from a sample
directory structure. That directory structure is contained in the etc/ directory and can be modified per the following steps:
1. Change directory to etc/:
cd etc/
2. Make modifications as desired.
3. Create the new ROMFS image.
genromfs -f romfs_img -d etc -V SimEtcVol
4. Convert the ROMFS image to a C header file
xxd -i romfs_img >nsh_romfsimg.h
5. Edit nsh_romfsimg.h, mark both data definitions as 'const' so that
that will be stored in FLASH.
@@ -1,391 +0,0 @@
README
======
This README file discusses the port of NuttX to the RX65N RSK2MB board. This board features the RX65N (R5F565NEHDFC 176pin)
Contents
========
- Board Features
- Status/Open Issues
- Serial Console
- LEDs
- Networking
- RTC
- USB Device
- RSPI
- RIIC
- DTC
- USB Host
- USB Host Hub
- Debugging
Board Features
==============
- Mounted devices: RX65N (R5F565NEDDFC: No Encrypt Function, Code Flash 2MB, Pin Count 176-pin),
or RX65N (R5F565NEHDFC: Supported Encrypt Function, Code Flash 2MB, Pin Count 176-pin)
- Mounts TFT Display. Graphic LCD controller can be evaluated
- 1 channel Ethernet can be evaluated
- RX65N builds in Trusted Secure IP. AES encryption function and robust key management can be evaluated (*)
- Mounts SD slot. If an optional Wireless LAN expansion board package for RSK (RTK0ZZZZZZP00000BR#WS) is used,
Wireless LAN can evaluated
- 1 channel USB Function and 1 channel USB Host can be evaluated
- In addition, CAN, RSPI, QSPI, etc. can be evaluated
See the RX65N RSK2MB website for further information about this board:
- https://www.renesas.com/br/en/products/software-tools/boards-and-kits/starter-kits/renesas-starter-kitplus-for-rx65n-2mb.html
Serial Console
==============
RX65N RSK2MB supports 12 serial ports (SCI0 - SCI12), however only 1 port can be tested(SCI8, which is the serial console). Only SCI8 port can be tested which is connected to USB Serial port.
Serial ports SCI1, SCI2, SCI9-SCI12, cannot be tested because they are multiplexed to other Rx65N controller interfaces.
Following SCI ports are configured w.r.t RX65N pin configuration
SCI1 Pin Configuration :
-----------
RX65N RSK2MB
Function
-----------
PF2 RXD1
PF1 TXD1
------------
SCI2 Pin Configuration :
-----------
RX65N RSK2MB
Function
-----------
P52 RXD2
P50 TXD2
------------
SCI8 Pin Configuration :
-----------
RX65N RSK2MB
Function
-----------
PJ1 RXD8
PJ2 TXD8
------------
Serial Connection Configuration
-------------------------------
1. RSK2MB board needs to be connected to PC, using USB cable(One end of which is connected to PC, other end
connected to USB serial port on H/W board).
2. RSK USB Serial Driver needs to be downloaded on PC side.
3. Configure Teraterm to 115200 baud.
LEDs
====
The RX65N RSK2MB board has 2 Power LED's(PowerLED5 LED_G, PowerLED3 LED_G) and 4 user LED's (LED_G, LED_O, LED_R, LED_R).
If enabled 4 User LED's are simply turned on when the board boots
successfully, and is blinking on panic / assertion failed.
Networking
==========
Ethernet Connections
--------------------
------ ---------
RX65N
RSK2MB Ethernet
Pin Function
------ ---------
PC4 ET0_TX_CLK
P76 ET0_RX_CLK
P80 ET0_TX_EN
PC6 ET0_ETXD3
PC5 ET0_ETXD2
P82 ET0_ETXD1
P81 ET0_ETXD0
PC3 ET0_TX_ER
PC2 ET0_RX_DV
PC0 ET0_ERXD3
PC1 ET0_ERXD2
P74 ET0_ERXD1
P75 ET0_ERXD0
P77 ET0_RX_ER
P83 ET0_CRS
PC7 ET0_COL
P72 ET0_MDC
P71 ET0_MDIO
P54 ET0_LINKSTA
------ ---------
USB Device
-----------
For the RX65N RSK2MB board, to be used as USB Device, the following Jumper settings need to be done
J7 Short Pin 2 & Pin 3
J16 Short Pin 1 & Pin 2
NuttX Configurations
--------------------
The following configurations, need to be enabled for network.
CONFIG_RX65N_EMAC=y : Enable the EMAC Peripheral for RX65N
CONFIG_RX65N_EMAC0=y : Enable the EMAC Peripheral for RX65N
CONFIG_RX65N_EMAC0_PHYSR=30 : Address of PHY status register
CONFIG_RX65N_EMAC0_PHYSR_100FD=0x18 : Needed for PHY CHIP
CONFIG_RX65N_EMAC0_PHYSR_100HD=0x08 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_10FD=0x14 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_10HD=0x04 : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_ALTCONFIG=y : " " " " " "
CONFIG_RX65N_EMAC0_PHYSR_ALTMODE=0x1c : " " " " " "
CONFIG_RX65N_EMAC0_RMII=y
CONFIG_RX65N_EMAC0_PHYADDR=0 : PHY is at address 1
CONFIG_SCHED_WORKQUEUE=y : Work queue support is needed
CONFIG_SCHED_HPWORK=y : High Priority Work queue support
CONFIG_SCHED_LPWORK=y : Low Priority Work queue support
Using the network with NSH
--------------------------
The IP address is configured using DHCP, using the below mentioned configurations :
CONFIG_NETUTILS_DHCPC=y
CONFIG_NETUTILS_DHCPD=y
CONFIG_NSH_DHCPC=y
CONFIG_NETINIT_DHCPC=y
nsh> ifconfig
eth0 HWaddr 00:e0:de:ad:be:ef at UP
IPaddr:10.75.24.53 DRaddr:10.75.24.1 Mask:255.255.254.0
You can use ping to test for connectivity to the host (Careful,
Window firewalls usually block ping-related ICMP traffic). On the
target side, you can:
nsh> ping 10.75.24.250
PING 10.75.24.250 56 bytes of data
56 bytes from 10.75.24.250: icmp_seq=1 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=2 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=3 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=4 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=5 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=6 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=7 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=8 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=9 time=0 ms
56 bytes from 10.75.24.250: icmp_seq=10 time=0 ms
10 packets transmitted, 10 received, 0% packet loss, time 10100 ms
On the host side, you should also be able to ping the RX65N-RSK2MB:
$ ping 10.75.24.53
Configure UDP blaster application as mentioned below :
CONFIG_EXAMPLES_UDPBLASTER_HOSTIP=0x0a4b1801 (10.75.24.1) ------> Gateway IP
CONFIG_EXAMPLES_UDPBLASTER_NETMASK=0xfffffe00 (255.255.254.0) --------> Netmask
CONFIG_EXAMPLES_UDPBLASTER_TARGETIP=0x0a4b189b (10.75.24.155) ---------> Target IP
RSPI
-----------
For RX65N RSK2MB board, Following pin is configured for all channels in JA3.
Channel0: Pin number 7 and 8 in JA3 is used for MOSIA and MISOA respectively
Channel1: Pin number 35 and 36 in JA3 is used for MOSIB and MISOB respectively
Channel2: Pin number 18 and 19 in JA3 is used for MOSIC and MISOC respectively
and for enabling these pin need to select DSW-SEL0 by making off SW4-4
USB Host
=============
For the RX65N RSK2MB board, to be used as USB Device, the following Jumper settings need to be done
J7 Short Pin 1 & Pin 2
J16 Short Pin 2 & Pin 3
USB Device
=============
For the RX65N RSK2MB board, to be used as USB Device, the following Jumper settings need to be done
J7 Short Pin 2 & Pin 3
J16 Short Pin 1 & Pin 2
RTC
==========
NuttX Configurations
---------------
The configurations listed in Renesas_RX65N_NuttX_RTC_Design.doc need to be enabled.
RTC Testing
------------------
The test cases mentioned in Renesas_RX65N_RTC_Test_Cases.xls are to be executed
as part of RTC testing.
The following configurations are to be enabled as part of testing RTC examples.
CONFIG_EXAMPLES_ALARM
CONFIG_EXAMPLES_PERIODIC
CONFIG_EXAMPLES_CARRY
USB Device Configurations
--------------------------
The following configurations need to be enabled for USB Device
CONFIG_USBDEV
CONFIG_CDCACM
CONFIG_STDIO_BUFFER_SIZE=64
CONFIG_STDIO_LINEBUFFER
USB Device Testing
------------------------
The following testing is executed as part of USB Device testing on RX65N target for GRROSE board
echo "This is a test for USB Device" > /dev/ttyACM0
xd 0 0x20000 > /dev/ttyACM0
The output of the commands mentioned above should be seen on the USB Device COM port on teraterm
RSPI Configurations
--------------------------
The following configurations need to be enabled for RSPI
CONFIG_SYSTEM_SPITOOL=y
RSPI Testing
------------------------
The following testing is executed as part of RSPI testing on RX65N target for RSK2MB board
On RSK2MB board, all three channels 0, 1 and 2 has been brought out and tested.
Following command can be used for testing RSPI communication to slave device.
spi exch -b 0 -x 4 aabbccdd
where b is bus number and x is Number of word to exchange.
RIIC Configurations
--------------------------
The following configurations need to be enabled for RIIC.
CONFIG_SYSTEM_I2CTOOL=y
RIIC Testing
------------------------
The following testing is executed as part of RIIC testing on RX65N target for RSK2MB board
On RSK2MB board only channel 0 can be tested.
Following command can be used for testing RIIC communication with slave device.
i2c set -b 0 -a 53 -r 0 10
where b is bus number, a is the slave address, r is the register address and 10 is the value to be written.
DTC Configurations
--------------------------
The following configurations need to be enabled for DTC.
CONFIG_SYSTEM_SPITOOL=y
DTC Testing
------------------------
DTC has been tested using RSPI driver.
USB Host Configurations
--------------------------
The following configurations need to be enabled for USB Host Mode driver to
support USB HID Keyboard class and MSC Class.
CONFIG_USBHOST=y
CONFIG_USBHOST_HIDKBD=y
CONFIG_FS_FAT=y
CONFIG_EXAMPLES_HIDKBD=y
USB Host Driver Testing
------------------------
The Following Class Drivers were tested as mentioned below :
- USB HID Keyboard Class
On the NuttX Console "hidkbd" application was executed
nsh> hidkbd
The characters typed from the keyboard were executed correctly.
- USB MSC Class
The MSC device is enumerated as sda in /dev directory.
The block device is mounted using the command as mentioned below :
mount -t vfat /dev/sda /mnt
The MSC device is mounted in /dev directory
The copy command is executed to test the Read/Write functionality
cp /mnt/<file.txt> /mnt/file_copy.txt
USB Host Hub Configurations
--------------------------
The following configurations need to be enabled for USB Host Mode driver to
support USB HID Keyboard class and MSC Class.
CONFIG_RX65N_USBHOST=y
CONFIG_USBHOST_HUB=y
CONFIG_USBHOST_ASYNCH=y
CONFIG_USBHOST=y
CONFIG_USBHOST_HIDKBD=y
CONFIG_FS_FAT=y
CONFIG_EXAMPLES_HIDKBD=y
USB Host Hub Driver Testing
------------------------
The Following Class Drivers were tested as mentioned below :
- USB HID Keyboard Class
On the NuttX Console "hidkbd" application was executed
nsh> hidkbd
The characters typed from the keyboard were executed correctly.
- USB MSC Class
The MSC device is enumerated as sda in /dev directory.
The block device is mounted using the command as mentioned below :
mount -t vfat /dev/sda /mnt
The MSC device is mounted in /dev directory
The copy command is executed to test the Read/Write functionality
cp /mnt/<file.txt> /mnt/file_copy.txt
Debugging
==========
1. NuttX needs to be compiled in Cygwin environment on Windows.
The following Configuration needs to be set, in order to do source level debugging.
CONFIG_DEBUG_SYMBOLS = y (Set this option, using menuconfig only, DO NOT Enable this as default configuration).
2. Download & Install Renesas e2studio IDE
3. Load the project(NuttX built on Cygwin) as Makefile project with existing code
4. Right click on the project, and select Debug Configurations
5. The binary(NuttX) needs to be loaded using E1/E2 Emulator
6. Select the Device name as R5F565NE and Emulator as E1/E2(whichever is being used)
7. Select Connection type as JTAG
8. Load and run the binary
Flashing NuttX
===============
Alternatively, NuttX binary can be flashed using Renesas flash programmer tool without using e2 studio/Cygwin
Below are the steps mentioned to flash NuttX binary using Renesas flash programmer tool(RFP).
1.In order to flash using Renesas flash programmer tool, nuttx.mot file should be generated.
2. Add the following lines in tools/Unix.mk file :
ifeq ($(CONFIG_MOTOROLA_SREC),y)
@echo "CP: nuttx.mot"
$(Q) $(OBJCOPY) $(OBJCOPYARGS) $(BIN) -O srec -I elf32-rx-be-ns nuttx.mot
endif
3. Add CONFIG_MOTOROLA_SREC=y in defconfig file or choose make menucofig->Build Setup-> Binary Output Format->
Select Motorola SREC format.
4. Download Renesas flash programmer tool from https://www.renesas.com/in/en/products/software-tools/tools/programmer/renesas-flash-programmer-programming-gui.html#downloads
5. Refer to the user manual document, for steps to flash NuttX binary using RFP tool.
@@ -1,85 +0,0 @@
README
======
Overview
--------
This directory contains logic to support a custom ROMFS system-init script
and start-up script. These scripts are used by by the NSH when it starts
provided that CONFIG_NSH_ARCHROMFS=y. These scripts provide a ROMFS volume
that will be mounted at /etc and will look like this at run-time:
NuttShell (NSH) NuttX-8.2
nsh> ls -l /etc
/etc:
dr-xr-xr-x 0 .
-r--r--r-- 20 group
dr-xr-xr-x 0 init.d/
-r--r--r-- 35 passwd
/etc/init.d:
dr-xr-xr-x 0 ..
-r--r--r-- 110 rcS
-r--r--r-- 110 rc.sysinit
nsh>
/etc/init.d/rc.sysinit is system init script; /etc/init.d/rcS is the start-up
script; /etc/passwd is a the password file. It supports a single user:
USERNAME: admin
PASSWORD: Administrator
nsh> cat /etc/passwd
admin:8Tv+Hbmr3pLVb5HHZgd26D:0:0:/
The encrypted passwords in the provided passwd file are only valid if the
TEA key is set to: 012345678 9abcdef0 012345678 9abcdef0. Changes to either
the key or the password word will require regeneration of the nsh_romfimg.h
header file.
The format of the password file is:
user:x:uid:gid:home
Where:
user: User name
x: Encrypted password
uid: User ID (0 for now)
gid: Group ID (0 for now)
home: Login directory (/ for now)
/etc/group is a group file. It is not currently used.
nsh> cat /etc/group
root:*:0:root,admin
The format of the group file is:
group:x:gid:users
Where:
group: The group name
x: Group password
gid: Group ID
users: A comma separated list of members of the group
Updating the ROMFS File System
------------------------------
The content on the nsh_romfsimg.h header file is generated from a sample
directory structure. That directory structure is contained in the etc/ directory and can be modified per the following steps:
1. Change directory to etc/:
cd etc/
2. Make modifications as desired.
3. Create the new ROMFS image.
genromfs -f romfs_img -d etc -V SimEtcVol
4. Convert the ROMFS image to a C header file
xxd -i romfs_img >nsh_romfsimg.h
5. Edit nsh_romfsimg.h, mark both data definitions as 'const' so that
that will be stored in FLASH.
-151
View File
@@ -1,151 +0,0 @@
Status
^^^^^^
*** UNSTABLE ***
The port is basically complete and many examples run correctly. However, there
are remaining instabilities that make the port un-usable. The nature of these
is not understood; the behavior is that certain SH-1 instructions stop working
as advertised. This could be a silicon problem, some pipeline issue that is not
handled properly by the gcc 3.4.5 toolchain (which has very limited SH-1 support
to begin with), or perhaps with the CMON debugger. At any rate, I have exhausted
all of the energy that I am willing to put into this cool old processor for the
time being.
Toolchain
^^^^^^^^^
A GNU GCC-based toolchain is assumed. The PATH environment variable should
be modified to point to the correct path to the SH toolchain (if
different from the default).
If you have no SH toolchain, one can be downloaded from the NuttX
Bitbucket download site (https://bitbucket.org/nuttx/buildroot/downloads/).
1. You must have already configured NuttX in <some-dir>nuttx.
tools/configure.sh us7032evb1:<sub-dir>
2. Download the latest buildroot package into <some-dir>
3. unpack
4. cd <some-dir>/buildroot
5. cp boards/sh-defconfig .config
6. make oldconfig
7. make
8. Make sure that the PATH variable includes the path to the newly built
binaries.
shterm
^^^^^^
The USB7032EVB1 supports CMON in PROM. CMON requires special
serial interactions in order to upload and download program files.
Therefore, a standard terminal emulation program (such as minicom)
cannot be used.
The shterm subdirectory contains a small terminal emulation
program that supports these special interactions for file transfers.
Configurations
^^^^^^^^^^^^^^
Common Configuration Notes
--------------------------
1. Each SH-1 configuration is maintained in a sub-directory and
can be selected as follow:
tools/configure.sh us7032evb1:<subdir>
Where <subdir> is one of the configuration sub-directories described in
the following paragraph.
2. These configurations use the mconf-based configuration tool. To
change a configurations using that tool, you should:
a. Build and install the kconfig-mconf tool. See nuttx/README.txt
see additional README.txt files in the NuttX tools repository.
b. Execute 'make menuconfig' in nuttx/ in order to start the
reconfiguration process.
3. By default, all configurations assume that you are building under
Linux (should work under Windows with Cygwin as well). This is
is easily reconfigured:
CONFIG_HOST_LINUX=y
Configuration Sub-Directories
-----------------------------
ostest
This configuration directory, performs a simple OS test using
examples/ostest.
nsh
Configures the NuttShell (nsh) located at examples/nsh. The
Configuration enables only the serial NSH interfaces.
NOTE: At present, the NSH example does not run. See the "Status"
discussion above for a full explanation.
Configuration Options
^^^^^^^^^^^^^^^^^^^^^
In additional to the common configuration options listed in the
file boards/README.txt, there are other configuration options
specific to the SH-1
Architecture selection
CONFIG_ARCH - identifies the arch subdirectory and, hence, the
processor architecture. This should be renesas (for arch/renesas)
CONFIG_ARCH_CHIP - Identifies the arch/*/chip subdirectory.
This should be sh1 (for arch/renesas/src/sh1 and arch/renesas/include/sh1)
CONFIG_ARCH_SH1 and CONFIG_ARCH_CHIP_SH7032 - for use in C code. These
identify the particular chip or SoC that the architecture is
implemented in.
CONFIG_ARCH_BOARD - identifies the boards/ subdirectory and, hence,
the board that supports the particular chip or SoC. This
should be us7032evb1 for (boards/renesas/sh1/us7032evb1).
CONFIG_ARCH_BOARD_US7032EVB1 - for use in C code
CONFIG_ENDIAN_BIG - the SH-1 usually runs big-endian
CONFIG_ARCH_NOINTC - define if the architecture does not
support an interrupt controller or otherwise cannot support
APIs like up_enable_irq() and up_disable_irq(). Should be
defined.
CONFIG_BOARD_LOOPSPERMSEC - for delay loops
CONFIG_ARCH_LEDS - Use LEDs to show state. Unique to SH1_LCEVB1
CONFIG_RAM_SIZE - Describes the internal DRAM.
CONFIG_RAM_START - The start address of internal DRAM
CONFIG_ARCH_INTERRUPTSTACK - This architecture supports an interrupt
stack. If defined, this symbol is the size of the interrupt
stack in bytes. If not defined, the user task stacks will be
used during interrupt handling.
CONFIG_ARCH_STACKDUMP - Do stack dumps after assertions
CONFIG_SH1_DMAC0, CONFIG_SH1_DMAC1, CONFIG_SH1_DMAC2, CONFIG_SH1_DMAC3,
CONFIG_SH1_ITU1, CONFIG_SH1_ITU2, CONFIG_SH1_ITU3, CONFIG_SH1_ITU4,
CONFIG_SH1_SCI0, CONFIG_SH1_SCI1, CONFIG_SH1_PCU, CONFIG_SH1_AD,
CONFIG_SH1_WDT, CONFIG_SH1_CMI - Each unused chip block should b
disabled to save space
SH1 specific device driver settings
CONFIG_SCIn_SERIAL_CONSOLE - selects the SCIn for the
console and ttys0 (default is the UART0).
CONFIG_SCIn_RXBUFSIZE - Characters are buffered as received.
This specific the size of the receive buffer
CONFIG_SCIn_TXBUFSIZE - Characters are buffered before
being sent. This specific the size of the transmit buffer
CONFIG_SCIn_BAUD - The configure BAUD of the UART. Must be
CONFIG_SCIn_BITS - The number of bits. Must be either 7 or 8.
CONFIG_SCIn_PARTIY - 0=no parity, 1=odd parity, 2=even parity, 3=mark 1, 4=space 0
CONFIG_SCIn_2STOP - Two stop bits