[nuttx] Building for the pic32mx mmb7?

[[e-mail] [nuttx]]

Hi,


I am setting up my windows 10 computer to build the nuttx version 7.2 for the pic32mx.


I got up to the point that I feel it is a bug in the make files.


C:\Tmp\nuttx>make menuconfig
make[1]: Entering directory `/c/Tmp/nuttx/configs'
make[1]: Nothing to be done for `dirlinks'.
make[1]: Leaving directory `/c/Tmp/nuttx/configs'
make[1]: Entering directory `/c/Tmp/apps'
make[2]: Entering directory `/c/Tmp/apps/platform'
make[2]: Nothing to be done for `dirlinks'.
make[2]: Leaving directory `/c/Tmp/apps/platform'
make[1]: Leaving directory `/c/Tmp/apps'
make[1]: Entering directory `/c/Tmp/apps'
make[1]: Nothing to be done for `preconfig'.
make[1]: Leaving directory `/c/Tmp/apps'
../apps/Kconfig:8: can't open file "/c/Tmp/apps/NxWidgets/Kconfig"

make: *** [do_menuconfig] Error 1




/c/Tmp/apps/NxWidgets/Kconfig exists and I can open it.



The line with the error comes from apps\kconfig


#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
# This file is autogenerated, do not edit.
#


source "/c/Tmp/apps/NxWidgets/Kconfig"
source "/c/Tmp/apps/builtin/Kconfig"
source "/c/Tmp/apps/canutils/Kconfig"
source "/c/Tmp/apps/examples/Kconfig"
source "/c/Tmp/apps/fsutils/Kconfig"
source "/c/Tmp/apps/gpsutils/Kconfig"
source "/c/Tmp/apps/graphics/Kconfig"
source "/c/Tmp/apps/interpreters/Kconfig"
source "/c/Tmp/apps/modbus/Kconfig"
source "/c/Tmp/apps/netutils/Kconfig"
source "/c/Tmp/apps/nshlib/Kconfig"
source "/c/Tmp/apps/platform/Kconfig"
source "/c/Tmp/apps/system/Kconfig"




Commenting out the first line moves the error to /builtin/Kconfig

[Sebastien Lorquet [e-mail] [nuttx]]

Hello

7.2 or 7.20 ?


This error comes from my contributed automatic generation of intermediate
Kconfig files.

There is a dedicated windows tool at APPSDIR/tools/mkkconfig.bat, but the tool
uses $APPSDIR, which is not a windows shell variable, and is left uninitialized,
but in fact should be the current directory.

The attached patch may help, to be tested and fixed along these lines.


Sebastien

Post by ***@yahoo.com [nuttx]
Hi,
I am setting up my windows 10 computer to build the nuttx version 7.2 for the pic32mx.
I got up to the point that I feel it is a bug in the make files.
C:\Tmp\nuttx>make menuconfig
make[1]: Entering directory `/c/Tmp/nuttx/configs'
make[1]: Nothing to be done for `dirlinks'.
make[1]: Leaving directory `/c/Tmp/nuttx/configs'
make[1]: Entering directory `/c/Tmp/apps'
make[2]: Entering directory `/c/Tmp/apps/platform'
make[2]: Nothing to be done for `dirlinks'.
make[2]: Leaving directory `/c/Tmp/apps/platform'
make[1]: Leaving directory `/c/Tmp/apps'
make[1]: Entering directory `/c/Tmp/apps'
make[1]: Nothing to be done for `preconfig'.
make[1]: Leaving directory `/c/Tmp/apps'
../apps/Kconfig:8: can't open file "/c/Tmp/apps/NxWidgets/Kconfig"
make: *** [do_menuconfig] Error 1
/c/Tmp/apps/NxWidgets/Kconfig exists and I can open it.
The line with the error comes from apps\kconfig
#
# For a description of the syntax of this configuration file,
# see the file kconfig-language.txt in the NuttX tools repository.
#
# This file is autogenerated, do not edit.
#
source "/c/Tmp/apps/NxWidgets/Kconfig"
source "/c/Tmp/apps/builtin/Kconfig"
source "/c/Tmp/apps/canutils/Kconfig"
source "/c/Tmp/apps/examples/Kconfig"
source "/c/Tmp/apps/fsutils/Kconfig"
source "/c/Tmp/apps/gpsutils/Kconfig"
source "/c/Tmp/apps/graphics/Kconfig"
source "/c/Tmp/apps/interpreters/Kconfig"
source "/c/Tmp/apps/modbus/Kconfig"
source "/c/Tmp/apps/netutils/Kconfig"
source "/c/Tmp/apps/nshlib/Kconfig"
source "/c/Tmp/apps/platform/Kconfig"
source "/c/Tmp/apps/system/Kconfig"
Commenting out the first line moves the error to /builtin/Kconfig

[[e-mail] [nuttx]]

It looks like those are changes that should be incorporated in any event.


Notice that mkkconfig.bat would never be used unless CONFIG_WINDOWS_NATIVE were defined in the .config file.


And that could never be set using make menuconfig if the original defconfig was not intended for Windows native.


So I think that would be a "chicken and egg" problem that you only solved by editing the .config file and changing the platform manually before trying to make menuconfig.


There are lots of cases like that where the pure native Windows and POSIX logic are mutually toxic.


Greg

[[e-mail] [nuttx]]

I am running mingw32 to cross compile code for another pic32 project.

Had to change the .config file to compile with the XC32. This compiler is the way to go in the future. The new 250mhz 32MZ series are going to need it.


I guess that I will have to switch over to cygwin.

[[e-mail] [nuttx]]

Tonight I went up to the steps described in "https://bitbucket.org/nuttx/tools"

Downloaded "kconfig-frontends version 3.12.0"

cd kconfig-frontends
./configure --enable-mconf

Installed all the dependencies that configure complained about.. then make:

$ make
Making all in docs
Making all in libs
Making all in parser
CC libkconfig_parser_la-yconf.lo
In file included from yconf.c:234:0:
hconf.gperf:141:1: error: conflicting types for 'kconf_id_lookup'
hconf.gperf:12:31: note: previous declaration of 'kconf_id_lookup' was here
static const struct kconf_id *kconf_id_lookup(register const char *str, register unsigned int len);
^
make[3]: *** [Makefile:456: libkconfig_parser_la-yconf.lo] Error 1
make[2]: *** [Makefile:350: all] Error 2
make[1]: *** [Makefile:334: all-recursive] Error 1
make: *** [Makefile:385: all-recursive] Error 1

Tomorrow I will continue.

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi,

Please take a look here:

https://github.com/pfalcon/esp-open-sdk/issues/243

This error appears related to gperf.

BR,

Alan

Post by ***@yahoo.com [nuttx]
Tonight I went up to the steps described in
"https://bitbucket.org/nuttx/tools"
Downloaded "kconfig-frontends version 3.12.0"
cd kconfig-frontends
./configure --enable-mconf
$ make
Making all in docs
Making all in libs
Making all in parser
CC libkconfig_parser_la-yconf.lo
hconf.gperf:141:1: error: conflicting types for 'kconf_id_lookup'
hconf.gperf:12:31: note: previous declaration of 'kconf_id_lookup' was here
static const struct kconf_id *kconf_id_lookup(register const char *str,
register unsigned int len);
^
make[3]: *** [Makefile:456: libkconfig_parser_la-yconf.lo] Error 1
make[2]: *** [Makefile:350: all] Error 2
make[1]: *** [Makefile:334: all-recursive] Error 1
make: *** [Makefile:385: all-recursive] Error 1
Tomorrow I will continue.

[[e-mail] [nuttx]]

Lastest gnuwin seems to break the build system in a lot of places.

Downgraded gperf to version 3.0.4.


$make clean
$./configure --disable-shared --enable-static --enable-mconf --disable-nconf --disable-gconf --disable-qconf --disable-nconf --disable-utils


$ make
Making all in docs
Making all in libs
Making all in parser
GPERF hconf.c
LEX lconf.c
YACC yconf.c
byacc: e - line 90 of "/usr/src/kconfig-frontends-3.12.0.0/libs/parser/yconf.y", syntax error
%destructor {
^
make[3]: *** [Makefile:512: yconf.c] Error 1
make[2]: *** [Makefile:350: all] Error 2
make[1]: *** [Makefile:334: all-recursive] Error 1
make: *** [Makefile:385: all-recursive] Error 1

[Alan Carvalho de Assis [e-mail] [nuttx]]

Try to replace yacc with bison, see:

https://github.com/openscad/openscad/issues/2

Post by ***@yahoo.com [nuttx]
Lastest gnuwin seems to break the build system in a lot of places.
Downgraded gperf to version 3.0.4.
$make clean
$./configure --disable-shared --enable-static --enable-mconf
--disable-nconf --disable-gconf --disable-qconf --disable-nconf
--disable-utils
$ make
Making all in docs
Making all in libs
Making all in parser
GPERF hconf.c
LEX lconf.c
YACC yconf.c
byacc: e - line 90 of
"/usr/src/kconfig-frontends-3.12.0.0/libs/parser/yconf.y", syntax error
%destructor {
^
make[3]: *** [Makefile:512: yconf.c] Error 1
make[2]: *** [Makefile:350: all] Error 2
make[1]: *** [Makefile:334: all-recursive] Error 1
make: *** [Makefile:385: all-recursive] Error 1

[[e-mail] [nuttx]]

Got the system set up with lastest tool versions. GCC/Binutils.

file nuttx created in the main folder.


mips-elf-objcopy complains about invalid address 0xfffffffffffff9000000.


ran objcopy and got the hex file that the programmer does not accept... fixed with mkpichex.


Loaded on my board successfuly. USB cable connected to the shield... FT232 to the pic UART1.


Expected to see something there. Not yet. More tomorrow.

[[e-mail] [nuttx]]

mips-elf-objcopy complains about the address range. So I ran the host binutils on it.

You cannot do that. That will never work. You cannot mix tools for different architectures.

mips-elf-objcopy: nuttx.hex: address 0xffffffff9d000000 out of range for Intel Hex file

[[e-mail] [nuttx]]

Than my mips-binutils might be broken because it does not like the uttx elf file generated by the mips-gcc.

Is the strange address message related to code placed in virtual addresses?




I am looking forward to get my build system to produce a working image.

[[e-mail] [nuttx]]

Than my mips-binutils might be broken because it does not like the uttx elf file generated by the mips-gcc.


Is the strange address message related to code placed in virtual addresses?


/mnt/c/Tmp/nuttx/nuttx: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, not stripped
9d018a40 T accept
9d018f70 t accept_interrupt
9d03b848 T __adddf3
9d0389a4 T add_file_action
9d03a7bc T __addsf3
9d0171e8 T arg_decimal
9d017268 T arg_hex
9d0171bc T arg_string
9d019990 T arp_arpin
9d019e80 T arp_find
9d019bc8 T arp_format
9d019e70 T arp_hdr_update
...





I am looking forward to get my build system to produce a working image.

[[e-mail] [nuttx]]

I don't know what strange message you are talking about. The .hex file looks good.


You cannot load that .hex file into FLASH however because it does contain KSEG0 virtual addresses. First you have to run the pichex tool which will convert the virtual addresses to physical FLASH addresses.

[[e-mail] [nuttx]]

I just successfully built and verified NuttX on my old PIC32MXMMB board (that has not been touched in many years). Everything went perfectly. The hold thing from beginning to end took about 15 minutes.

I built in Cygwin under Windows 10. There were essentially no changes to the .config file except for switching the Pinquino toolchain:


$ tools/cmpconfig.exe .config configs/pic32mx7mmb/nsh/defconfig
Comparing:

file1 = .config
file2 = configs/pic32mx7mmb/nsh/defconfig

file1: CONFIG_APPS_DIR="../apps"
file2:

file1: CONFIG_ARCH_TOOLCHAIN_GNU=y
file2:

file1: CONFIG_IOB_THROTTLE=0
file2:

file1:
file2: CONFIG_MIPS32_TOOLCHAIN_MICROCHIPW_LITE=y

file1: CONFIG_MIPS32_TOOLCHAIN_PINGUINOW=y
file2:

file1: CONFIG_SYSLOG_WRITE=y
file2:


Then I loaded the code using ICD3 and IPE and it just worked:


Successfully initialized SPI port 1
Successfully bound SPI port 1 to MMC/SD slot 0

NuttShell (NSH) NuttX-7.20
nsh> help
help usage: help [-v] [<cmd>]

[ cmp free mkfatfs put time
? dirname get mkrd pwd true
arp dd help mh rm uname
basename df hexdump mount rmdir umount
break echo kill mv set unset
cat exec ls mw sh usleep
cd exit mb nslookup sleep wget
cp false mkdir ping test xd

Builtin Apps:
msconn
msdis
nsh> ls -Rl /
/:
dr--r--r-- 0 dev/
/dev:
crw-rw-rw- 0 console
brw-rw-rw- 0 mmcsd0
crw-rw-rw- 0 null
crw-rw-rw- 0 telnet
crw-rw-rw- 0 ttyS0
nsh>

Very, very easy if you carefully follow the instructions in the README.txt file and take the time to set up a proper build environment.

[[e-mail] [nuttx]]

I make a few changes to the PIC32MX7MMB to bring it up to date. The Penguino toolchain is now the default. I also enabled the PROCFS file system and verified networking:

Successfully initialized SPI port 1
Successfully bound SPI port 1 to MMC/SD slot 0

NuttShell (NSH) NuttX-7.20
nsh>
nsh> help
help usage: help [-v] [<cmd>]

[ dirname help mh rm umount
? dd hexdump mount rmdir unset
arp df ifconfig mv set usleep
basename echo kill mw sh wget
break exec ls nslookup sleep xd
cat exit mb ping test
cd false mkdir ps time
cp free mkfatfs put true
cmp get mkrd pwd uname

Builtin Apps:
msconn
msdis
nsh> ifconfig
eth0 Link encap:Ethernet HWaddr 00:04:a3:1e:a6:ed at UP
inet addr:10.0.0.2 DRaddr:10.0.0.1 Mask:255.255.255.0


nsh> ping 10.0.0.42
PING 10.0.0.42 56 bytes of data
56 bytes from 10.0.0.42: icmp_seq=1 time=0 ms
56 bytes from 10.0.0.42: icmp_seq=2 time=60 ms
56 bytes from 10.0.0.42: icmp_seq=3 time=60 ms
...
10 packets transmitted, 10 received, 0% packet loss, time 9740 ms
nsh>

[[e-mail] [nuttx]]

While still trying to get a working development enrironment, I have followed the tutorial at http://retrobsd.org/wiki/doku.php/doc/toolchain-mips http://retrobsd.org/wiki/doku.php/doc/toolchain-mips

The versions on the page do not build correctly because of errors in the source files.


I did the proper adjustments and built gcc 7.1.0 and its dependencies, lastest binutils...


These are the nuttx build last lines:


...
CC: fs_initialize.c
CC: inode/fs_files.c
CC: inode/fs_foreachinode.c
CC: inode/fs_inode.c
CC: inode/fs_inodeaddref.c
CC: inode/fs_inodebasename.c
CC: inode/fs_inodefind.c
CC: inode/fs_inodefree.c
CC: inode/fs_inoderelease.c
CC: inode/fs_inoderemove.c
CC: inode/fs_inodereserve.c
CC: inode/fs_inodesearch.c
CC: inode/fs_filedetach.c
CC: vfs/fs_close.c
CC: vfs/fs_dup.c
CC: vfs/fs_dup2.c
CC: vfs/fs_fcntl.c
CC: vfs/fs_dupfd.c
CC: vfs/fs_dupfd2.c
CC: vfs/fs_epoll.c
CC: vfs/fs_fstat.c
CC: vfs/fs_fstatfs.c
CC: vfs/fs_getfilep.c
CC: vfs/fs_ioctl.c
CC: vfs/fs_lseek.c
CC: vfs/fs_mkdir.c
CC: vfs/fs_open.c
CC: vfs/fs_poll.c
CC: vfs/fs_read.c
CC: vfs/fs_rename.c
CC: vfs/fs_rmdir.c
CC: vfs/fs_statfs.c
CC: vfs/fs_stat.c
CC: vfs/fs_select.c
CC: vfs/fs_unlink.c
CC: vfs/fs_write.c
CC: vfs/fs_fsync.c
CC: vfs/fs_pread.c
CC: vfs/fs_pwrite.c
CC: vfs/fs_link.c
CC: vfs/fs_readlink.c
CC: vfs/fs_fdopen.c
CC: driver/fs_registerdriver.c
CC: driver/fs_unregisterdriver.c
CC: driver/fs_registerblockdriver.c
CC: driver/fs_unregisterblockdriver.c
CC: driver/fs_findblockdriver.c
CC: driver/fs_openblockdriver.c
CC: driver/fs_closeblockdriver.c
CC: driver/fs_blockproxy.c
CC: dirent/fs_closedir.c
CC: dirent/fs_opendir.c
CC: dirent/fs_readdir.c
CC: dirent/fs_rewinddir.c
CC: dirent/fs_seekdir.c
CC: mmap/fs_mmap.c
CC: mqueue/mq_open.c
CC: mqueue/mq_close.c
CC: mqueue/mq_unlink.c
CC: mount/fs_mount.c
CC: mount/fs_umount2.c
CC: mount/fs_foreachmountpoint.c
CC: fat/fs_fat32.c
CC: fat/fs_fat32dirent.c
CC: fat/fs_fat32attrib.c
CC: fat/fs_fat32util.c
CC: fat/fs_mkfatfs.c
CC: fat/fs_configfat.c
CC: fat/fs_writefat.c
AR: fs_initialize.o fs_files.o fs_foreachinode.o fs_inode.o fs_inodeaddref.o fs_inodebasename.o fs_inodefind.o fs_inodefree.o fs_inoderelease.o fs_inoderemove.o fs_inodereserve.o fs_inodesearch.o fs_filedetach.o fs_close.o fs_dup.o fs_dup2.o fs_fcntl.o fs_dupfd.o fs_dupfd2.o fs_epoll.o fs_fstat.o fs_fstatfs.o fs_getfilep.o fs_ioctl.o fs_lseek.o fs_mkdir.o fs_open.o fs_poll.o fs_read.o fs_rename.o fs_rmdir.o fs_statfs.o fs_stat.o fs_select.o fs_unlink.o fs_write.o fs_fsync.o fs_pread.o fs_pwrite.o fs_link.o fs_readlink.o fs_fdopen.o fs_registerdriver.o fs_unregisterdriver.o fs_registerblockdriver.o fs_unregisterblockdriver.o fs_findblockdriver.o fs_openblockdriver.o fs_closeblockdriver.o fs_blockproxy.o fs_closedir.o fs_opendir.o fs_readdir.o fs_rewinddir.o fs_seekdir.o fs_mmap.o mq_open.o mq_close.o mq_unlink.o fs_mount.o fs_umount2.o fs_foreachmountpoint.o fs_fat32.o fs_fat32dirent.o fs_fat32attrib.o fs_fat32util.o fs_mkfatfs.o fs_configfat.o fs_writefat.o
make[1]: Leaving directory '/home/future/nuttx/fs'
make[1]: Entering directory '/home/future/nuttx/binfmt'
CC: binfmt_globals.c
CC: binfmt_register.c
CC: binfmt_unregister.c
CC: binfmt_loadmodule.c
CC: binfmt_unloadmodule.c
CC: binfmt_execmodule.c
CC: binfmt_exec.c
CC: binfmt_copyargv.c
CC: binfmt_dumpmodule.c
CC: builtin.c
CC: libbuiltin/libbuiltin_getname.c
CC: libbuiltin/libbuiltin_isavail.c
AR: binfmt_globals.o binfmt_register.o binfmt_unregister.o binfmt_loadmodule.o binfmt_unloadmodule.o binfmt_execmodule.o binfmt_exec.o binfmt_copyargv.o binfmt_dumpmodule.o builtin.o libbuiltin_getname.o libbuiltin_isavail.o
make[1]: Leaving directory '/home/future/nuttx/binfmt'
make[1]: Entering directory '/home/future/nuttx/arch/mips/src'
AS: chip/pic32mx-head.S
make[2]: Entering directory '/home/future/nuttx/configs/pic32mx7mmb/src'
CC: pic32_boot.c
CC: pic32_leds.c
CC: pic32_spi.c
CC: pic32_mio283qt2.c
CC: pic32_usbdev.c
CC: pic32_appinit.c
CC: pic32_usbmsc.c
AR: pic32_boot.o pic32_leds.o pic32_spi.o pic32_mio283qt2.o pic32_usbdev.o pic32_appinit.o pic32_usbmsc.o
make[2]: Leaving directory '/home/future/nuttx/configs/pic32mx7mmb/src'
LD: nuttx
make[1]: Leaving directory '/home/future/nuttx/arch/mips/src'
CP: nuttx.hex
mips-elf-objcopy: nuttx.hex: address 0xffffffff9d000000 out of range for Intel Hex file
mips-elf-objcopy:nuttx.hex: Bad value
Makefile.unix:404: recipe for target 'pass2' failed

[[e-mail] [nuttx]]

Try 'make V=1' That will show you the actual commands used.

[[e-mail] [nuttx]]

Can you post the hex file?

[[e-mail] [nuttx]]

No, I don't have it anymore.

[[e-mail] [nuttx]]

Did you change the linker script from tradlittlemips to littlemips?

p32-objcopy.exe does not support tradlittlemips.

[[e-mail] [nuttx]]

I changed quite a few things because the original scripts supported only the old, obsolete C32 toolchain. I added support for the Pinguino toolchain. You can resync with the repository to get those changes.

[[e-mail] [nuttx]]

It went better this time. No compile errors and I got the HEX file.


But I still see nothing on the UART1 @ 115200,8,N,1.


Is this the correct board? I have it and the shield.


https://shop.mikroe.com/smart-displays/mikromedia/mikromedia-4/pic32mx7 https://shop.mikroe.com/smart-displays/mikromedia/mikromedia-4/pic32mx7



The pic32mx UART1 is connected to the FTDI232 on it.




This is what I did.


Downloaded the tree: https://github.com/PinguinoIDE/pinguino-compilers/tree/master/linux64/p32


Copied over /usr/local


cd ~
git clone https://bitbucket.org/nuttx/nuttx.git nuttx


apps/ was there already


cd nuttx
cd tools
./configure.sh pic32mx7mmb/nsh
cd ..


changed in .config...
#
# Build Setup
#
CONFIG_HOST_LINUX=y


PINGUINOW was already set


first built mkpichex


make


everything went fine and the hex was produced


cp nuttx.hex /mnt/c/Tmp/nuttx-before.hex
tools/pic32mx/mkpichex $PWD
cp nuttx.hex /mnt/c/Tmp/




MPLAB-X when it loads the before mkpichex hex file:


Loading code from C:/Tmp/nuttx-before.hex...
Warning: C:/Tmp/nuttx-before.hex contains code that is located at addresses that do not exist on the PIC32MX795F512L.


And after:


Loading code from C:/Tmp/nuttx.hex...
Warning: The hex file has the debug bit set. The debug bit has been cleared during load to memory.
The original hex file has not been modified.
Loading completed


Target voltage detected
Target device PIC32MX795F512L found.
Device ID Revision = 54300053


Device Erased...


Programming...


The following memory area(s) will be programmed:
program memory: start address = 0x0, end address = 0x3afff
boot config memory
configuration memory
Programming/Verify complete








Also found that if the sd card support is removed, the build breaks.




Thank you.

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi barbiani,

On 5/30/17, ***@yahoo.com [nuttx] <***@yahoogroups.com> wrote:
...

Post by ***@yahoo.com [nuttx]
changed in .config...

You cannot edit the .config manually, there are many interdependences
that need to be created. You need to run "make menuconfig" and select
it.

BR,

Alan

[[e-mail] [nuttx]]

Alan is right. You must be editing the .config files by hand. That will screw up the build completely. You must never do that. You must always use the kconfig-frontends tools.


That explains:


- You selected LINUX with a Windows toolchain (PINGUINOW). The configuration system would never let you do that.


- The build broke when you manually disabled the SD card. Most manual edits will break the build because there are many interdependencies.


If you want you make this work, then you going to need to get serious and follow the instructions. Otherwise, you are wasting everyone's time. Do not post any issues on this forum until you configure using kconfig-frontends. We have been things to do that respond to such ignorant and irresponsible behavior

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
It went better this time. No compile errors and I got the HEX file.
Is this the correct board? I have it and the shield.
https://shop.mikroe.com/smart-displays/mikromedia/mikromedia-4/pic32mx7
The pic32mx UART1 is connected to the FTDI232 on it.

No, that is a different board. This is the MMB (MultiMediaBoard) for PIC32MX7:

https://www.mikroe.com/new-pic32mx7-tool-multimedia-board-for-pic32mx7/
http://www.mikrocity.com.hk/productdetails.php?pid=NTQ=#sthash.Zv3UO66r.dpbs

Post by ***@yahoo.com [nuttx]
CONFIG_HOST_LINUX=y

You are working under Linux?

Post by ***@yahoo.com [nuttx]
PINGUINOW was already set

But this is a Windows toolchain selection. Trying to use that with Linux will probably cause some issues. There should be a PINGUINOL for Linux (CONFIG_MIPS32_TOOLCHAIN_PINGUINOL).
I used the IPE to load code.

If you want to use a MPLAB debugger, you need to use a different linker script. You need a linker script that reserves memory that is used by the debugger. You could adapt one of these:

$ find configs -name *-debug.ld
configs/mirtoo/scripts/c32-debug.ld
configs/mirtoo/scripts/mips-elf-debug.ld
configs/mirtoo/scripts/xc32-debug.ld
configs/pic32mz-starterkit/scripts/c32-debug.ld
configs/pic32mz-starterkit/scripts/mips-debug.ld
configs/pic32mz-starterkit/scripts/pinguino-debug.ld
configs/pic32mz-starterkit/scripts/xc32-debug.ld

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Greg,

On 5/30/17, ***@yahoo.com [nuttx] <***@yahoogroups.com> wrote:
...

Post by ***@yahoo.com [nuttx]

Post by ***@yahoo.com [nuttx]
CONFIG_HOST_LINUX=y

You are working under Linux?

Post by ***@yahoo.com [nuttx]
PINGUINOW was already set

But this is a Windows toolchain selection. Trying to use that with Linux
will probably cause some issues. There should be a PINGUINOL for Linux
(CONFIG_MIPS32_TOOLCHAIN_PINGUINOL).

He/she is using the penguino toolchain for Linux. So, I think it is
the Ubuntu bash running inside win10.

Maybe in the "Build Host Platform" we should have a "Linux under
Windows (i.e. Ubuntu Bash)" to handle with these differences.

I think the challenge here is because he/she is using a cutting edge
solution (Ubuntu Bash on Windows) that was not too much used yet.

Barbiani, you will need to create a new board configuration to
encompass the differences between pic32mx7mmb and your board
(pic32mx7). Download the schematic of both boards and write down the
differences. You will need to modify it in the source code.

So you will need to:

$ cp -a configs/pic32mx7mmb configs/pic32mx7

Edit the configs/Kconfig and include at the right place (just above
each PIC32MX7MMB) :

------------------------------------------------------------------------------
config ARCH_BOARD_PIC32MX7
bool "Mikroelektronika PIC32MX7"
depends on ARCH_CHIP_PIC32MX795F512L
select ARCH_HAVE_LEDS
---help---
This is the port NuttX to the Mikroelektronika
PIC32MX7 Multimedia Board
(MMB). See http://www.mikroe.com/ for further information.

------------------------------------------------------------------------------

if ARCH_BOARD_PIC32MX7
source "configs/pic32mx7/Kconfig"
endif

------------------------------------------------------------------------------

default "pic32mx7" if ARCH_BOARD_PIC32MX7

------------------------------------------------------------------------------

Also change all references of ARCH_BOARD_PIC32_PIC32MX7MMB to
ARCH_BOARD_PIC32_PIC32MX7. And rename the pic32mx7mmb.h to pic32mx7.h

Then when you get everything done and working correctly, please
contribute your modifications to help other people.

BR,

Alan

[[e-mail] [nuttx]]

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]

But this is a Windows toolchain selection. Trying to use that with Linux
will probably cause some issues. There should be a PINGUINOL for Linux
(CONFIG_MIPS32_TOOLCHAIN_PINGUINOL).

He/she is using the penguino toolchain for Linux. So, I think it is
the Ubuntu bash running inside win10.

AFAIK you still have to use Linux tools running inside the Ubuntu Bash SandBox. It seems that external Windows-native tools cannot access files on the internal lxfs file system (althought the top level and at least the /bin directory are visisble). And the configuration tool would never let you select any Windows toolchain option with CONFIG_HOST_LINUX.

From the standpoint of Windows tools, the Ubuntu root FS is at %localappdata%\lxss\rootfs. You can see files in the rootfs\ but rootfs\home appears as an empty directory (this is where all of my files should be located). Perhaps there is a trick that I do not yet know.

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
Maybe in the "Build Host Platform" we should have a "Linux under
Windows (i.e. Ubuntu Bash)" to handle with these differences.

That option exists, it is call CONFIG_WINDOWS_UBUNTU. But that is not what was selected and I doubt that you can use a Window-native toolchain with that configuration.

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think the challenge here is because he/she is using a cutting edge
solution (Ubuntu Bash on Windows) that was not too much used yet.

It works fine. I don't know how you would load the code or debug it since the Windows tools cannot access the code in the lxfs file system. But the build does work fine.

Perhaps you could use OpenOCD? But I am not quite should how the USB devices work inside the sandbox.

[[e-mail] [nuttx]]

AFAIK you still have to use Linux tools running inside the Ubuntu Bash SandBox. It seems that external Windows-native tools cannot access files on the internal lxfs file system (althought the top level and at least the /bin directory are visisble). And the configuration tool would never let you select any Windows toolchain option with CONFIG_HOST_LINUX.
From the standpoint of Windows tools, the Ubuntu root FS is at %localappdata%\lxss\rootfs. You can see files in the rootfs\ but rootfs\home appears as an empty directory (this is where all of my files should be located). Perhaps there is a trick that I do not yet know.

Okay, I think I found the trick. Although, the %localappdata%\lxss\rootfs\home directory appears to be empty, I find all of the user data is accessible from windows at: %localappdata%\lxss\home

With that trick directory, you should actually be able to use Windows tools outside of the Ubuntu sandbox with versions of NuttX built within the sandbox using that path. I also verified that you can use execute Windows tools from within the Ubuntu sandbox:

$ /mnt/c/Program\ Files\ \(x86\)/Microchip/xc32/v1.43/bin/xc32-gcc.exe --version
Unable to translate current working directory. Using C:\WINDOWS\System32
xc32-gcc.exe (Microchip Technology) 4.8.3 MPLAB XC32 Compiler v1.43 Build date: Mar 1 2017
...

But the error message indicates that there are more issues: You still cannot mix Windows tools that use Windows style paths in an environment that uses POSIX paths. That can never work without some path conversion tool. I think you would have to use Linux tools only within the Ubuntu sandbox.

[[e-mail] [nuttx]]

My board is different! Now you said it. But google for pic32mx7 mmb and you will see my board also. Probably something else is different. Starting from the crystal clock speed!


SD card support was removed using the menuconfig and I am using it since the begining.

PINGUINOL makes reference to mips-elf-gcc, but the file is mips-elf-gcc-4.9.2 that comes with the pinguino package or is p32-gcc. Maybe it needs a symbolic link?


/usr/local/bin/mips-elf-ar: 1: /usr/local/bin/mips-elf-ar: /dvpt/pinguino/git-copy/pinguino-compilers/linux64/p32/bin/p32-ar: not found.
mips-elf-ar rcs libsched.a FAILED!


$ which p32-ar
/usr/local/bin/p32-ar


p32 is in the PATH and the build system can not find it.



Every selection under menuconfig has another thing that breaks.


Maybe somebody can test the compiled code I am attaching on the post.


Selecting UBUNTU bash under win10 or linux makes no difference from the compilation point of view. Both make the same hex file.



I am not stupid, seriously. I do not know the build system.



Installing the pinguino for linux 64 on ubuntu bash created hex files. It just did. Again, I do not know how this linux under windows works.


Windows access to the files were done by copying them to a folder already mounted in /mnt/



I am sorry to be wasting our time!

[[e-mail] [nuttx]]

You mean the hex I had attached to the post? It was processed with mkpihex already.

[[e-mail] [nuttx]]

That pic32mx7mmb/nsh configuration is very complex. It has a lot of features enabled like:


- Networking (CONFIG_NET)
- USB device (CONFIG_USBDEV,
- MMC/SD via SPI


You might want to simplify some of that to make the bring-up simpler.

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi barbiani,

If you compiled your boardname/nsh configuration it should print
something like this in the serial console:

NuttShell (NSH)
nsh>

You can run "make menuconfig" and enable the DEBUG. It will print a
character for each stage of NuttX boot process, something like this:
ABCBF ...

Also you can enable debug for each specific subsystem of NuttX. Really
useful want you are doing board bring-up.

If nothing works, then you need to go deep in the hole, use a JTAG/SWD
programmer with GDB to see what is going on.

BR,

Alan

A bit more of information about the build and the system.
$ mips-elf-gcc --version
mips-elf-gcc (GCC) 7.1.0
$ mips-elf-ld --version
GNU ld (GNU Binutils) 2.28
xc32-objcopy -V
GNU objcopy (Microchip Technology) 2.23.51. MPLAB XC32 Compiler v1.43
A make on the nuttx folder created the nuttx elf file.
mips-elf-objcopy complains about the address range. So I ran the host
binutils on it.
mips-elf-objcopy: nuttx.hex: address 0xffffffff9d000000 out of range for
Intel Hex file
Also, applied the xc32-objcopy... both generate the same hex file.
Fixed it with mkpichex tool and flashed with icd3.
Should I see anything on the serial port at 115200,8,N,1 ?
Thank you for your time.

[[e-mail] [nuttx]]

Hello,

I noticed this thread when also attempting to do a Windows native build using the GNUWin32 tools, and the pre-build kconfig-mconf.exe tool from here:


http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html



(I have already tried and proven out an Ubuntu build process using buildroot, which ended up being relatively simple.)


As Greg noted in a previous post... I had to edit .config manually to enable the Windows native switches throughout the makefiles. It got pretty far before finally choking on the generated apps/Kconfig file... the kconfig-mconf.exe didn't like having backslashes in the paths to the child directories.


Furthermore, I think there are issues with this line:
SET APPSDIR=%~dp0

as %~dp0 returns the path of the batch file itself (apps/tools), not the apps directory itself.


If I figure out how to patch mkkconfig.bat and prove out the Windows native toolchain, would someone here accept my patch? Is there a more direct pull request process through bitbucket.org?


I'm a newcomer to NuttX, and I'm excited to explore and contribute to this RTOS!


Thanks,
Jeff

[Alan Carvalho de Assis [e-mail] [nuttx]]

Hi Jeff,

Post by ***@yahoo.com [nuttx]
Hello,
I noticed this thread when also attempting to do a Windows native build
using the GNUWin32 tools, and the pre-build kconfig-mconf.exe tool from
http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html
http://uvc.de/posts/linux-kernel-configuration-tool-kconfig-under-windows.html
(I have already tried and proven out an Ubuntu build process using
buildroot, which ended up being relatively simple.)

Nice to know it works fine on Ubuntu.

Post by ***@yahoo.com [nuttx]
As Greg noted in a previous post... I had to edit .config manually to
enable the Windows native switches throughout the makefiles. It got pretty
far before finally choking on the generated apps/Kconfig file... the
kconfig-mconf.exe didn't like having backslashes in the paths to the child
directories.

I think you confused something here... Greg didn't say to people to
edit .config manually.

Editing the .config manually is a really bad practice that could
raises many issues in the building system. Please *ALWAYS* use "make
menuconfig".

Post by ***@yahoo.com [nuttx]
SET APPSDIR=%~dp0
as %~dp0 returns the path of the batch file itself (apps/tools), not the
apps directory itself.

I'm not the right person the respond it, because I'm not using
Windows. Maybe Greg or other people could to reply.

Post by ***@yahoo.com [nuttx]
If I figure out how to patch mkkconfig.bat and prove out the Windows native
toolchain, would someone here accept my patch? Is there a more direct pull
request process through bitbucket.org?

Well, if you find the correct fix I don't see why it couldn't be
applied to mainline.

Post by ***@yahoo.com [nuttx]
I'm a newcomer to NuttX, and I'm excited to explore and contribute to this RTOS!

Welcome to NuttX Jeff!

BR,

Alan

[[e-mail] [nuttx]]

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think you confused something here... Greg didn't say to people to

edit .config manually.


You do have to edit the file manually in this case. If it is initially configured for a POSIX environment, then you cannot use 'make menuconfig' because it won't run. So if you want to change a configuration from POSIX to Windows native or vice versa, then you do have to manually edit the .config file to select CONFIG_HOST_WINDOWS and CONFIG_WINDOWS_NATIVE before trying to run 'make menuconfig'


I have not used the native build in a very long time. I would suspect that there are problems that need to be fixed due to bit rot. You can use PRs, patches posted on this forum, or patches in the Bitbucket issues list. Your choice, people do all three.


I can be more difficult to work with if you do PRs, however. In that case, the code must 100% follow the coding standard and I must have confidence that the change will not break anything. You change to the APPSDIR setting would, I believe, break other platforms because that has worked perfectly for many years. So I would have to decline that without a better understanding.


Greg

[[e-mail] [nuttx]]

I have gotten the Windows native build to work, but with several changes that feel a bit hacky. For example,
I had to change DELIM from \ to \\ (I'll have to see where the single backslash is being mangled into an escape character).

The APPSDIR setting issue is most likely related to HOW the mkkconfig.bat file is being called, but changing it from %~dp0 to %cd% does fix some things. (The APPSDIR line was introduced to mkkconfig.bat on 2017-05-22.)

But I still need to do my best attempt at determining actual root cause for some of this stuff...

Thanks,
Jeff

[[e-mail] [nuttx]]

That was not the APPSDIR setting I was thinking of. Since the .bat files are not being used now (I think you are the only Windows native "customer"), I would take your word for whatever needs to change for any .bat file.


The change in definition of DELIM was necessary in the past, but most like something is not done correctly somewhere. It would be great if you could find that place.


Greg

[[e-mail] [nuttx]]

Also another option to the pure native build is to use the MSYS tools that come with MinGW. Those tools derive from an old Cygwin port but can work well in a Windows native environment.


There was a person on this list who used MSYS for all builds, but I am not if that has been done lately either.


Greg

[Alan Carvalho de Assis [e-mail] [nuttx]]

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]

Post by Alan Carvalho de Assis ***@gmail.com [nuttx]
I think you confused something here... Greg didn't say to people to

edit .config manually.
You do have to edit the file manually in this case. If it is initially
configured for a POSIX environment, then you cannot use 'make menuconfig'
because it won't run. So if you want to change a configuration from POSIX
to Windows native or vice versa, then you do have to manually edit the
.config file to select CONFIG_HOST_WINDOWS and CONFIG_WINDOWS_NATIVE before
trying to run 'make menuconfig'

Ok, sorry about my comment here. Normally we shouldn't to edit the
.config manually, but in this case when the kconfig-frontend isn't
available, then manually editing it to setup the host and the type of
environment is the way to go.

BR,

Alan

[[e-mail] [nuttx]]

Thanks for all the feedback. Here are my suggested changes so far. I can create a patch file later if someone on here can "sanity check" my findings below... I'll also test the patch in an Ubuntu build for good measure, but I don't think any of this can negatively impact other build host platforms.

nuttx/tools/Config.mk - Make the default path delimiter double backslashes for windows native. I was not able to find a relatively low-impact way around this... I didn't want to touch a ton of known-working makefiles. It should be the most compatible solution anyway, for the various ways DELIM is used.
ifeq ($(CONFIG_WINDOWS_NATIVE),y)
DELIM = $(strip \\)

apps/tools/mkkconfig.bat - Use %cd% instead of %~dp0 for usage of APPSDIR in this batch file (perhaps the variable should be renamed to avoid confusion/ambiguty); Fix double-double-quote issue on Kconfig "menu" lines in app subdirectories
SET APPSDIR=%cd%
SET APPSDIR=%APPSDIR:\=/%
...
Echo menu %menu% >> %kconfig%

nuttx/configs/Board.mk - Place the "# Create an empty archive" comment on its own line, because in windows it appears to be trying to make that an extra parameter to $(AR)
# Create an empty archive
$(Q) $(AR) $@

nuttx/Makefile.win - Because the windows delimiter is now \\, when defining LINKLIBS, we have to double up the backslashes again in this case so that it removes lib\\ from the start of each lib\\lib*.a path
LINKLIBS = $(patsubst lib$(DELIM:\\=\\\\)%,%,$(NUTTXLIBS))


One remaining question I have: What about buildroot? Was that ever working for windows native? Does it make any sense to spend time getting buildroot to build arm-nuttx-eabi-gcc.exe, etc.?

Thanks,
Jeff

[[e-mail] [nuttx]]

Post by ***@gmail.com [nuttx]
nuttx/tools/Config.mk - Make the default path delimiter double backslashes for windows native.

and

Post by ***@gmail.com [nuttx]
nuttx/Makefile.win - Because the windows delimiter is now \\, when defining LINKLIBS, we have to double up the backslashes again in this case so that it removes lib\\ from the start of each lib\\lib*.a path

This bothers me some because it used to work fine with the single backslash. Something has change in some restricted location, I think, but this is a global change. That leaves me a little uncomfortable.

Can you carry these a local changes until we learn a little more? Where exactly does it fail without the double backslashes? Maybe we can solve the problem without resorting to double back slashes.

Normally the double backslashes are only necessary if you run things through a Bash shell because the shell will remove them. But you should not be doing anything like that, right? Everything should be backslash knowledgable, right?

Post by ***@gmail.com [nuttx]
apps/tools/mkkconfig.bat - Use %cd% instead of %~dp0 for usage of APPSDIR in this batch file
SET APPSDIR=%cd%
nuttx/configs/Board.mk - Place the "# Create an empty archive" comment on its own line, because in windows it appears to be trying to make that an extra parameter to $(AR)

I can commit those changes now.

Post by ***@gmail.com [nuttx]
Fix double-double-quote issue on Kconfig "menu" lines in app subdirectories
...
SET APPSDIR=%APPSDIR:\=/%
...
Echo menu %menu% >> %kconfig%

Is that related to the double backslashes again?

Post by ***@gmail.com [nuttx]
One remaining question I have: What about buildroot?

I have never built GCC for Windows, but I presume it is possible with MinGW. I don't know if the scripts are sufficient to support the build or not since I have never done it.

Greg

[[e-mail] [nuttx]]

This bothers me some because it used to work fine with the single backslash. Something has change in some restricted location, I think, but this is a global change. That leaves me a little uncomfortable.

Once I get back to my Windows machine, I'll mail out some specifics on what fails with the single backslash.

SET APPSDIR=%APPSDIR:\=/%

The build of kconfig-mconf.exe obtained from the site mentioned before interprets the single backslashes as escape characters, and throws an error when attempting to parse the apps/Kconfig file. But it does load the Windows paths fine using forward slashes.

Echo menu %menu% >> %kconfig%

In apps subdirectory Kconfig files, mkkconfig.bat was generating lines like:
menu ""menuname""
which were not parsed properly by kconfig-mconf.exe. The changed line instead yields:
menu "menuname"





Jeff

nuttx/tools/Config.mk - Make the default path delimiter double backslashes for windows native.

and

nuttx/Makefile.win - Because the windows delimiter is now \\, when defining LINKLIBS, we have to double up the backslashes again in this case so that it removes lib\\ from the start of each lib\\lib*.a path

This bothers me some because it used to work fine with the single backslash. Something has change in some restricted location, I think, but this is a global change. That leaves me a little uncomfortable.

Can you carry these a local changes until we learn a little more? Where exactly does it fail without the double backslashes? Maybe we can solve the problem without resorting to double back slashes.

Normally the double backslashes are only necessary if you run things through a Bash shell because the shell will remove them. But you should not be doing anything like that, right? Everything should be backslash knowledgable, right?

apps/tools/mkkconfig.bat - Use %cd% instead of %~dp0 for usage of APPSDIR in this batch file
SET APPSDIR=%cd%
nuttx/configs/Board.mk - Place the "# Create an empty archive" comment on its own line, because in windows it appears to be trying to make that an extra parameter to $(AR)

I can commit those changes now.

Fix double-double-quote issue on Kconfig "menu" lines in app subdirectories
...
SET APPSDIR=%APPSDIR:\=/%
...
Echo menu %menu% >> %kconfig%

Is that related to the double backslashes again?

One remaining question I have: What about buildroot?

I have never built GCC for Windows, but I presume it is possible with MinGW. I don't know if the scripts are sufficient to support the build or not since I have never done it.

Greg

[[e-mail] [nuttx]]

Okay, here are some more specifics on the Windows native issues... tl;dr: Greg, you were right, a global double backslash delimiter probably isn't necessary :)

This is from a clean clone of nuttx and apps a couple of hours ago, so it includes Greg's latest commits.

First is an issue with apps/platform/Makefile interpreting path backslashes as escape characters in certain contexts, yielding the error:
make[1]: Entering directory `C:/Users/Reclone/nuttx-git/nuttx/configs'
make[1]: Leaving directory `C:/Users/Reclone/nuttx-git/nuttx/configs'
make[1]: Entering directory `C:/Users/Reclone/nuttx-git/apps'
make[2]: Entering directory `C:/Users/Reclone/nuttx-git/apps/platform'
makefile:112: *** target pattern contains no `%'. Stop.
make[2]: Leaving directory `C:/Users/Reclone/nuttx-git/apps/platform'
make[1]: *** [dirlinks] Error 2
make[1]: Leaving directory `C:/Users/Reclone/nuttx-git/apps'
make: *** [dirlinks] Error 2

After learning painfully how to debug makefiles ("make menuconfig V=2 -d > make.output 2>&1") I found the issues in apps/platform/Makefile, and added substitutions in the $(DELIM)s to make the makefile happier, apparently required in the cases of patsubst or static pattern rules (alternatively you could just put forward slashes there, at the risk of potential copy-paste oversights later):
AOBJS = $(patsubst %.S, bin$(DELIM:\=/)%$(OBJEXT), $(ASRCS))
COBJS = $(patsubst %.c, bin$(DELIM:\=/)%$(OBJEXT), $(CSRCS))
$(AOBJS): bin$(DELIM:\\=/)%$(OBJEXT): %.S
$(COBJS): bin$(DELIM:\\=/)%$(OBJEXT): %.c

Second, there was the error when kconfig-mconf.exe tries to load the Kconfig files:
..\apps/Kconfig:8: can't open file "C:UsersReclonenuttx-gitapps/builtin/Kconfig"
make: *** [do_menuconfig] Error 1

The errant line in the generated apps/Kconfig looks like this:
source "C:\Users\Reclone\nuttx-git\apps/builtin/Kconfig"
so it appears to be interpreting the backslashes as escape characters as kconfig-mconf is parsing it.

The fix is to swap backslash for forward slash in APPSDIR in apps/tools/mkkconfig.bat:
REM Get the current directory
SET APPSDIR=%cd%
REM kconfig-mconf.exe doesn't like backslashes in paths in Kconfig files
SET APPSDIR=%APPSDIR:\=/%

This is enough to fix up "make menuconfig" and get into Nuttx Configuration.

After saving some configuration for an stm32f4discovery board, I exited menuconfig and attempted "make":
make: *** ..apps: No such file or directory. Stop.
make: *** [dirlinks] Error 2

Even worse, attempting "make menuconfig" again gave the same error. But it must be some quirk of the kconfig-mconf tool after I originally enabled windows native. After editing the .config file again to change the apps directory from "..apps" back to "../apps", I didn't have a problem with that setting again.

A "make" then proceeded through several subdirectories. Now, I am getting this error:
make[2]: Entering directory `C:/Users/Reclone/nuttx-git/nuttx/arch/arm/src/board'
"CC: stm32_boot.c"
arm-none-eabi-gcc: fatal error: no input files
compilation terminated.

Probably due to a previous issue:
make[1]: Entering directory `C:/Users/Reclone/nuttx-git/nuttx/arch/arm/src'
make[2]: Entering directory `C:/Users/Reclone/nuttx-git/nuttx/arch/arm/src/board'
ERROR: No compiler specified:
C:\Users\Reclone\nuttx-git\nuttx/tools/mkdeps [OPTIONS] CC -- CFLAGS -- file [file [file...]]
Where:
...
--winnative
By default, a POSIX-style environment is assumed (e.g., Linux, Cygwin, etc.) This option is
inform the tool that is working in a pure Windows native environment.
...
make[2]: *** [.depend] Error 1
make[2]: Leaving directory `C:/Users/Reclone/nuttx-git/nuttx/arch/arm/src/board'
make[1]: *** [.depend] Error 2

But I'm too tired to dig in to that tonight.

Cheers,
Jeff

[[e-mail] [nuttx]]

Most of things... at least the apps/platform problem and the mkkconfig.bat... were caused by recently introduced build system changes that have never been tested with Windows native.


IMHO the existing Windows native build has too many path-related kludges already. I can see what you are struggling with because I have been there too. Certainly the native Windows build is possible, but it seems like an endless sequence of awkward hacks.


This is really something that I would like to see done right. And I am wondering if there is some way to reconceive the Windows build that does not require so many hacks. I am in the middle of a few things now but would be willing to help in a week or so.


Some of these issues are also due to the only partial compatibility of the GNUWin32 make (as you mention with regard to how it makes some of the substitutions). I am wondering if there is any kind of build tool available that would support generation of custom makefiles for either Windows or POSIX. Is that a capability of a tool like cmake?


I really know little about such tools, I have also resisted committing to additional build tools in the past because I did not want to put that burden on everyone's development environment.


At one time, I also thought about have a parallel, nmake-based build. But nmake is so much more primitive the GNU make that I think that would be a difficult job as well.


Greg

[[e-mail] [nuttx]]

I know CMake well because I use it at my day job. It would be ideal if you wanted to help guarantee compatibility with different make systems and build hosts, but yes, it would introduce an extra required tool and might also change up some workflows.

I think that we could keep it compatible with Kconfig. We might still need some helper scripts manage the plethora of toolchain options and targets currently available in NuttX.

One happy side-effect of using CMake is that (if you manage your dependencies correctly) you automatically enable parallel builds (make -j8 to use eight parallel workers, for example).


But once the windows native build is back to working in vanilla NuttX, I plan to set up a Jenkins build server job at home as an early warning system. Is there any other continuous integration system already in place?


Jeff

[[e-mail] [nuttx]]

Post by ***@yahoo.com [nuttx]
I am setting up my windows 10 computer to build the nuttx version 7.2 for the pic32mx.
I got up to the point that I feel it is a bug in the make files.

I think you have your build system very confused because you are mixing tools that expect different kinds of paths.

Post by ***@yahoo.com [nuttx]
C:\Tmp\nuttx>make menuconfig
make[1]: Entering directory `/c/Tmp/nuttx/configs'

You do not mention which development environment you are using. Certainly it is not Cygwin which I use on Windows. For Cygwin, the path would be /cydrive/c/Tmp/NuttX/configs. And certainly it is not Ubuntu Bash under Windows. That would be /mnt/c/Tmp/NuttX/config.

So it appears that you are trying to do a native windows build using MYSY tools? Or GnuWin32 tools? That will probably be a problem for you. My suggestion is that you use one of the better established development environments. You should read the top-level nuttx/README.txt for instructions.

Post by ***@yahoo.com [nuttx]
make[1]: Nothing to be done for `dirlinks'.
make[1]: Leaving directory `/c/Tmp/nuttx/configs'
make[1]: Entering directory `/c/Tmp/apps'

...

Post by ***@yahoo.com [nuttx]
make[1]: Leaving directory `/c/Tmp/apps'

So I assume that you are using the MSYS make.exe and it is happily using its fake path to C:/Tmp/...

Post by ***@yahoo.com [nuttx]
../apps/Kconfig:8: can't open file "/c/Tmp/apps/NxWidgets/Kconfig"

It successfully followed all of the relative paths under the nuttx/ directory and followed the relative to ../apps/Kconfig but then kconfig-mconf died as soon as it tried to access the ABSOLUTE path /c/Tmp/apps/NxWidgets/Kconfig because it does not understand that MSYS nonsense.

You will need (1) either rebuild kconfig-frontends so that it uses the same tools that you use, (2) write a program to convert all of the paths to C:\Tmp\..., or (3) switch to Cygwin or to Ubuntu Bash under Windows. My recommendation is that you do (3) using the instructions at nuttx/README.txt.

If you switch from MSYS to GnuWin32, that might also eliminate the problem as well. But there is no one else in the world using the Windows native build as far as I know. If you go that way it would be good for because it would help to re-verify that build mode but it would be bad for you because it will cost you a lot of work.

Greg

[[e-mail] [nuttx]]

Hello everybody,

I have been studying the system and getting it to work with this controller.


Dev machine is now ubuntu linux with the pinguino compiler.


Got the prompt and local loopback network running. Also works fine with the ethernet cable. I can ping the router at 192.168.25.1.


It stays running fine until I scan the network with nmap or an android app. The kernel crashes.




Where should I look? Do I drop this dev board and go to ARM?




nsh>
nsh> ping 192.168.25.1
PING 192.168.25.1 56 bytes of data
up_assert: Assertion failed at file:sched/sched_addprioritized.c line: 88
up_dumpstate: sp: a0009298
up_dumpstate: stack base: a0007008
up_dumpstate: stack size: 00000800
up_dumpstate: ERROR: Stack pointer is not within allocated stack
icmp_seq=1 Network is unreachable
icmp_seq=2 Network is unreachable
icmp_seq=3 Network is unreachable
icmp_seq=4 Network is unreachable
icmp_seq=5 Network is unreachable
pic32mx_exception: EXCEPTION: CAUSE: 0080101c EPC: 9d045f78
up_assert: Assertion failed at file:chip/pic32mx-exception.c line: 181
up_dumpstate: sp: a00091f0
up_dumpstate: stack base: a0007008
up_dumpstate: stack size: 00000800
up_dumpstate: ERROR: Stack pointer is not within allocated stack
up_registerdump: MFLO:a0009268 MFHI:00000001 EPC:9d045f78 STATUS:00100303
up_registerdump: AT:00000000 V0:00000000 V1:00000028 A0:a0008ab0 A1:a00004ec A2:9d047314 A3:00000001
up_registerdump: T0:00010000 T1:00000001 T2:98968000 T3:00000000 T4:00000000 T5:00009896 T6:00000000
T7:00000000
up_registerdump: S0:00000002 S1:a0000738 S2:00000004 S3:a0009444 S4:01312d00 S5:00000000 S6:00000000
S7:00000000
up_registerdump: T8:00000000 T9:00000000 SP:a00092e8 FP:00000000 RA:9d048ea8






and also






nsh> up_assert: Assertion failed at file:mips32/up_sigdeliver.c line: 101
up_dumpstate: sp: a0008828
up_dumpstate: stack base: a0008a80
up_dumpstate: stack size: 000007e4
up_stackdump: a0008820: a0008820 a0008820 00000045 9d0088c8 a0008828 a0008a80 9d068c20 000007e4
up_stackdump: a0008840: a0008a80 000007e4 a0007df0 a0008828 00000000 9d007a9c 00000000 9d0689b0
up_stackdump: a0008860: 9d0689dc 9d0689fc 00000065 a0008878 00000000 9d008178 9d0689fc 00000065
up_stackdump: a0008880: 00000030 a00088a0 a0007df0 00000004 9d002570 a00088a0 00000002 9d008138
up_stackdump: a00088a0: 00100303 00000000 a000063c a0007e5c 00000002 a0007e5c a000063c 00000001
up_stackdump: a00088c0: 00000000 00000003 00000000 90801100 00030000 00000000 00000000 00000000
up_stackdump: a00088e0: 00000000 00000000 02faf080 00000000 00000000 00000000 00000000 00000000
up_stackdump: a0008900: 00000000 9d009a60 a0008920 00000000 9d05d6d4 a0008920 00000000 9d05d6d4
up_stackdump: a0008920: a00005d0 00000006 0000001e 00000002 00100301 a0007df0 a00005d0 00100301
up_stackdump: a0008940: 00000000 9d049358 a0007df0 00000006 9d049008 00000001 a0007df0 00000000
up_stackdump: a0008960: ffffffff a0007df0 00100301 00000000 00000005 00000000 00000005 00000000
up_stackdump: a0008980: a0007df0 00000000 00000000 00000000 00000000 00000000 00000000 9d047428
up_stackdump: a00089a0: a00089c8 00000000 a00089f0 00000000 00000000 00000000 00100301 00000b53
up_stackdump: a00089c0: a0007df0 9d02b670 00000000 00000002 bf881078 9d0062cc a00089f0 00000000
up_stackdump: a00089e0: 00100301 00000000 00000000 00000000 00000000 02faf080 00000000 9d002b7c
up_stackdump: a0008a00: 0000c350 a0006350 00100301 00000000 00000000 0010ff01 00000000 00000005
up_stackdump: a0008a20: 00000b53 00000b53 9d00a178 a0000b9c 00000005 a0008a3c 00000000 9d000f10
up_stackdump: a0008a40: a000634c 00000005 00000000 00000000 0000000b 9d000e88 00000001 a0008a84
up_stackdump: a0008a60: a0000580 00000000 00000001 a0007df0 9d000828 9d005d4c 00036464 00000000



Thank you.

[[e-mail] [nuttx]]

Problems like this are typically caused by stack overflows and are fixed by increasing stack sizes. But there could also be other causes as well.

You many need to analyze the crash dump. There are detailed instructions here for ARMv7-M: http://www.nuttx.org/doku.php?id=wiki:howtos:cortexm-hardfault

Everything in that page applies to MIPS to with the exception of the interpretation of some specific ARM registers and the odd addressing used in ARMv7-M (ignore everything about bit 0 being set in the addresses).

Greg