from:"Peter Kalbus"

Re: Build Nuttx on MAC / ARM64 Ubuntu

2022-02-02 Thread Peter Kalbus

Hi,

please check https://github.com/apache/incubator-nuttx/pull/5401 
<https://github.com/apache/incubator-nuttx/pull/5401> with initial support.

Feedback is highly appreciated.

/Piet


> Am 02.02.2022 um 08:57 schrieb Peter Kalbus :
> 
> Hi Flavio,
> 
> let me share my latest findings.
> 
> I’m down to setjmp/longjmp, which needs to be adapted to AARCH64. A 
> preliminary version is available, but not fully working, yet.
> 
> I can share my code, if you want to dig into that, too.
> 
> /Piet
> 
> 
> 
>> Am 31.01.2022 um 11:10 schrieb Flavio Castro Alves Filho 
>> :
>> 
>> Hi Peter,
>> 
>> Yes, I intend to use it for simulation only.
>> 
>> It is for a personal project. I already have a Ubuntu based desktop
>> machine, which works fine. But for mobility, if I could work on my MAC, it
>> would be better.
>> 
>> I will try to figure out what is going on.
>> 
>> Thank you for all your help.
>> 
>> Best regards,
>> 
>> Flavio
>> 
>> 
>> Em dom., 30 de jan. de 2022 10:28, Kalbus, Peter 
>> escreveu:
>> 
>>> Hi,
>>> 
>>> are you only interested in the simulation or also have a real target in
>>> mind?
>>> 
>>> Maybe you can try to get it working for your real target instead of the
>>> simulation. The simulation is definitely not working overall on M1 based
>>> host systems yet.
>>> 
>>> I‘m using RP2040 based targets and they are working using my M1 based host
>>> system.
>>> 
>>> /Piet
>>> 
>>> 
>>>> Am 30.01.2022 um 13:22 schrieb Flavio de Castro Alves Filho <
>>> flavio.al...@gmail.com>:
>>>> 
>>>> That’s what I did.
>>>> 
>>>> So it is not the problem.
>>>> 
>>>>> On 29 Jan 2022, at 19:43, Peter Kalbus 
>>> wrote:
>>>>> 
>>>>> Hi Flavio,
>>>>> 
>>>>> there’s an explanation in NuttX documentation:
>>> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend
>>> <
>>> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend
>>>> 
>>>>> Check for the „MacOS, Ubuntu 18.04 LTS and earlier“ tab.
>>>>> 
>>>>> It’s a couple of months back, as I did this … but I’m quite sure, that
>>> I followed that explanation.
>>>>> 
>>>>> /Piet
>>>>> 
>>>>> 
>>>>>>> Am 29.01.2022 um 23:17 schrieb Flavio de Castro Alves Filho <
>>> flavio.al...@gmail.com>:
>>>>>> 
>>>>>> Hi Peter,
>>>>>> 
>>>>>> How did you install kconfig-frontends on your machine?
>>>>>> 
>>>>>> Best regards,
>>>>>> 
>>>>>> Flavio
>>>>>> 
>>>>>>> On 29 Jan 2022, at 18:13, Kalbus, Peter 
>>> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I know, it‘s not complete. But you should get a different error … I
>>> see, ARM based CPU is now detected … next step will take longer.
>>>>>>> 
>>>>>>> /Piet
>>>>>>> 
>>>>>>>> Am 29.01.2022 um 22:03 schrieb Flavio de Castro Alves Filho <
>>> flavio.al...@gmail.com>:
>>>>>>>> 
>>>>>>>> Hello Guys. Thank you for your fast response.
>>>>>>>> 
>>>>>>>> @Alan, indeed it is an ARM-based Mac.
>>>>>>>> 
>>>>>>>> @Peter, I added your patch in my NuttX project and ran again the
>>> configuration, but without success yet :-(
>>>>>>>> 
>>>>>>>> Here is the output
>>>>>>>> 
>>>>>>>> flavio@Flavios-MacBook-Pro nuttx % tools/configure.sh -m sim:nsh
>>>>>>>> Copy files
>>>>>>>> Select CONFIG_HOST_MACOS=y
>>>>>>>> Select CONFIG_HOST_ARM=y
>>>>>>>> Refreshing...
>>>>>>>> make[2]: Nothing to be done for `clean_context'.
>>>>>>>> CP: arch/dummy/Kconfig to
>>> /Users/flavio/mestrado/nuttx/nuttx/arch/dummy/dummy_kconfig
>>>>>>>> CP: boards/dummy/Kconfig to
>>> /Users/flavio/mestrado/nuttx/nuttx/boards/dummy/dummy_kconfig
>

Re: Build Nuttx on MAC / ARM64 Ubuntu

2022-02-01 Thread Peter Kalbus

Hi Flavio,

let me share my latest findings.

I’m down to setjmp/longjmp, which needs to be adapted to AARCH64. A preliminary 
version is available, but not fully working, yet.

I can share my code, if you want to dig into that, too.

/Piet



> Am 31.01.2022 um 11:10 schrieb Flavio Castro Alves Filho 
> :
> 
> Hi Peter,
> 
> Yes, I intend to use it for simulation only.
> 
> It is for a personal project. I already have a Ubuntu based desktop
> machine, which works fine. But for mobility, if I could work on my MAC, it
> would be better.
> 
> I will try to figure out what is going on.
> 
> Thank you for all your help.
> 
> Best regards,
> 
> Flavio
> 
> 
> Em dom., 30 de jan. de 2022 10:28, Kalbus, Peter 
> escreveu:
> 
>> Hi,
>> 
>> are you only interested in the simulation or also have a real target in
>> mind?
>> 
>> Maybe you can try to get it working for your real target instead of the
>> simulation. The simulation is definitely not working overall on M1 based
>> host systems yet.
>> 
>> I‘m using RP2040 based targets and they are working using my M1 based host
>> system.
>> 
>> /Piet
>> 
>> 
>>> Am 30.01.2022 um 13:22 schrieb Flavio de Castro Alves Filho <
>> flavio.al...@gmail.com>:
>>> 
>>> That’s what I did.
>>> 
>>> So it is not the problem.
>>> 
>>>> On 29 Jan 2022, at 19:43, Peter Kalbus 
>> wrote:
>>>> 
>>>> Hi Flavio,
>>>> 
>>>> there’s an explanation in NuttX documentation:
>> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend
>> <
>> https://nuttx.apache.org/docs/latest/quickstart/install.html#kconfig-frontend
>>> 
>>>> Check for the „MacOS, Ubuntu 18.04 LTS and earlier“ tab.
>>>> 
>>>> It’s a couple of months back, as I did this … but I’m quite sure, that
>> I followed that explanation.
>>>> 
>>>> /Piet
>>>> 
>>>> 
>>>>>> Am 29.01.2022 um 23:17 schrieb Flavio de Castro Alves Filho <
>> flavio.al...@gmail.com>:
>>>>> 
>>>>> Hi Peter,
>>>>> 
>>>>> How did you install kconfig-frontends on your machine?
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> Flavio
>>>>> 
>>>>>> On 29 Jan 2022, at 18:13, Kalbus, Peter 
>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I know, it‘s not complete. But you should get a different error … I
>> see, ARM based CPU is now detected … next step will take longer.
>>>>>> 
>>>>>> /Piet
>>>>>> 
>>>>>>> Am 29.01.2022 um 22:03 schrieb Flavio de Castro Alves Filho <
>> flavio.al...@gmail.com>:
>>>>>>> 
>>>>>>> Hello Guys. Thank you for your fast response.
>>>>>>> 
>>>>>>> @Alan, indeed it is an ARM-based Mac.
>>>>>>> 
>>>>>>> @Peter, I added your patch in my NuttX project and ran again the
>> configuration, but without success yet :-(
>>>>>>> 
>>>>>>> Here is the output
>>>>>>> 
>>>>>>> flavio@Flavios-MacBook-Pro nuttx % tools/configure.sh -m sim:nsh
>>>>>>> Copy files
>>>>>>> Select CONFIG_HOST_MACOS=y
>>>>>>> Select CONFIG_HOST_ARM=y
>>>>>>> Refreshing...
>>>>>>> make[2]: Nothing to be done for `clean_context'.
>>>>>>> CP: arch/dummy/Kconfig to
>> /Users/flavio/mestrado/nuttx/nuttx/arch/dummy/dummy_kconfig
>>>>>>> CP: boards/dummy/Kconfig to
>> /Users/flavio/mestrado/nuttx/nuttx/boards/dummy/dummy_kconfig
>>>>>>> LN: platform/board to
>> /Users/flavio/mestrado/nuttx/apps/platform/dummy
>>>>>>> LN: include/arch to arch/sim/include
>>>>>>> LN: include/arch/board to
>> /Users/flavio/mestrado/nuttx/nuttx/boards/sim/sim/sim/include
>>>>>>> LN: drivers/platform to
>> /Users/flavio/mestrado/nuttx/nuttx/drivers/dummy
>>>>>>> LN: include/arch/chip to
>> /Users/flavio/mestrado/nuttx/nuttx/arch/sim/include/sim
>>>>>>> /Users/flavio/mestrado/nuttx/nuttx/tools/link.sh
>> /Users/flavio/mestrado/nuttx/nuttx/arch/sim/include/sim include/arch/chip
>>>>>>> LN: arch/sim/src/chi

Re: Build Nuttx on MAC / ARM64 Ubuntu

2022-01-29 Thread Peter Kalbus

rror
>>> arch/arm/src/stm32l4/Kconfig:5370: invalid statement
>>> arch/arm/src/stm32l4/Kconfig:5380: unexpected end statement
>>> arch/arm/src/stm32l4/Kconfig:5382: unexpected end statement
>>> arch/arm/src/stm32l4/Kconfig:5384: unexpected end statement
>>> arch/arm/src/stm32l4/Kconfig:6253: unexpected end statement
>>> arch/arm/Kconfig:1179: unexpected end statement
>>> arch/arm/Kconfig:1199: unexpected end statement
>>> Kconfig:1959: unexpected end statement
>>> boards/sim/sim/sim/Kconfig:58: syntax error
>>> boards/sim/sim/sim/Kconfig:57: invalid option
>>> drivers/note/Kconfig:80: syntax error
>>> drivers/note/Kconfig:79: invalid option
>>> drivers/sensors/Kconfig:308: syntax error
>>> drivers/sensors/Kconfig:307: invalid option
>>> drivers/syslog/Kconfig:317: syntax error
>>> drivers/syslog/Kconfig:316: invalid option
>>> make: *** [olddefconfig] Error 1
>>> ERROR: failed to refresh
>>> flavio@Flavios-MacBook-Pro nuttx % 
>>> 
>>> 
>>> Is there any missing requirement from my environment?
>>> 
>>> How do I implement the manual architecture setup? I’m afraid that it won’t 
>>> work either … 
>>> 
>>> Best regards,
>>> 
>>> Flavio
>>> 
>>> 
>>>> On 29 Jan 2022, at 17:53, Peter Kalbus  wrote:
>>>> 
>>>> Created PR to detect host CPU type: 
>>>> https://github.com/apache/incubator-nuttx/pull/5374 
>>>> <https://github.com/apache/incubator-nuttx/pull/5374> 
>>>> <https://github.com/apache/incubator-nuttx/pull/5374 
>>>> <https://github.com/apache/incubator-nuttx/pull/5374>>
>>>> 
>>>> /Piet
>>>> 
>>>> 
>>>>>> Am 29.01.2022 um 19:12 schrieb Peter Kalbus >>>>> <mailto:p...@mailbox.org>>:
>>>>> 
>>>>> Hi again,
>>>>> 
>>>>> just as an extension. On the same M1, I’ve Ubuntu ARM64 running using 
>>>>> Parallels VM.
>>>>> 
>>>>> Same issue: Host CPU Type detected as „x86_64“ and compilation stops at 
>>>>> same file —> see below.
>>>>> 
>>>>> Issue seems to be not specific to MacOS M1, but rather generic to ARM64 
>>>>> host systems.
>>>>> 
>>>>> /Piet
>>>>> 
>>>>> 
>>>>> —
>>>>> 
>>>>> 
>>>>> AR (create): libdrivers.a   bchlib_setup.o bchlib_teardown.o 
>>>>> bchlib_read.o bchlib_write.o bchlib_cache.o bchlib_sem.o 
>>>>> bchdev_register.o bchdev_unregister.o bchdev_driver.o ioe_dummy.o gpio.o 
>>>>> gpio_lower_half.o loop.o losetup.o pipe.o fifo.o pipe_common.o serial.o 
>>>>> serial_io.o vsyslog.o syslog_stream.o syslog_channel.o syslog_putc.o 
>>>>> syslog_write.o syslog_force.o syslog_flush.o syslog_initialize.o 
>>>>> syslog_device.o oneshot.o arch_alarm.o hid_parser.o dev_null.o dev_zero.o 
>>>>> ramdisk.o mkrd.o
>>>>> make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/drivers'
>>>>> IN: drivers/libdrivers.a -> staging/libdrivers.a
>>>>> make[1]: Entering directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
>>>>> CC:  boardctl.c
>>>>> AR (create): libboards.a   dummy.o boardctl.o 
>>>>> make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
>>>>> IN: boards/libboards.a -> staging/libboards.a
>>>>> make[1]: Entering directory 
>>>>> '/home/piet/Projects/NuttX/ptka/nuttx/libs/libc'
>>>>> AS:  machine/sim/arch_setjmp_arm.S
>>>>> machine/sim/arch_setjmp_arm.S: Assembler messages:
>>>>> machine/sim/arch_setjmp_arm.S:39: Error: unknown pseudo-op: `.syntax'
>>>>> machine/sim/arch_setjmp_arm.S:43: Error: operand 1 must be an integer 
>>>>> register -- `mov ip,r0'
>>>>> machine/sim/arch_setjmp_arm.S:44: Error: unknown mnemonic `stmia' -- 
>>>>> `stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp}'
>>>>> machine/sim/arch_setjmp_arm.S:45: Error: operand 1 must be an integer 
>>>>> register -- `mov r2,sp'
>>>>> machine/sim/arch_setjmp_arm.S:46: Error: unknown mnemonic `stmia' -- 
>>>>> `stmia ip!,{r2,lr}'
>>>>> machine/sim/arch_setjmp_arm.S:47: Error: operand 1 must be an integer 
>>>>> register -- `mov r0,#0'
>>&g

Re: Build Nuttx on MAC / ARM64 Ubuntu

2022-01-29 Thread Peter Kalbus

Created PR to detect host CPU type: 
https://github.com/apache/incubator-nuttx/pull/5374 
<https://github.com/apache/incubator-nuttx/pull/5374>

/Piet


> Am 29.01.2022 um 19:12 schrieb Peter Kalbus :
> 
> Hi again,
> 
> just as an extension. On the same M1, I’ve Ubuntu ARM64 running using 
> Parallels VM.
> 
> Same issue: Host CPU Type detected as „x86_64“ and compilation stops at same 
> file —> see below.
> 
> Issue seems to be not specific to MacOS M1, but rather generic to ARM64 host 
> systems.
> 
> /Piet
> 
> 
> —
> 
> 
> AR (create): libdrivers.a   bchlib_setup.o bchlib_teardown.o bchlib_read.o 
> bchlib_write.o bchlib_cache.o bchlib_sem.o bchdev_register.o 
> bchdev_unregister.o bchdev_driver.o ioe_dummy.o gpio.o gpio_lower_half.o 
> loop.o losetup.o pipe.o fifo.o pipe_common.o serial.o serial_io.o vsyslog.o 
> syslog_stream.o syslog_channel.o syslog_putc.o syslog_write.o syslog_force.o 
> syslog_flush.o syslog_initialize.o syslog_device.o oneshot.o arch_alarm.o 
> hid_parser.o dev_null.o dev_zero.o ramdisk.o mkrd.o
> make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/drivers'
> IN: drivers/libdrivers.a -> staging/libdrivers.a
> make[1]: Entering directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
> CC:  boardctl.c
> AR (create): libboards.a   dummy.o boardctl.o 
> make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
> IN: boards/libboards.a -> staging/libboards.a
> make[1]: Entering directory '/home/piet/Projects/NuttX/ptka/nuttx/libs/libc'
> AS:  machine/sim/arch_setjmp_arm.S
> machine/sim/arch_setjmp_arm.S: Assembler messages:
> machine/sim/arch_setjmp_arm.S:39: Error: unknown pseudo-op: `.syntax'
> machine/sim/arch_setjmp_arm.S:43: Error: operand 1 must be an integer 
> register -- `mov ip,r0'
> machine/sim/arch_setjmp_arm.S:44: Error: unknown mnemonic `stmia' -- `stmia 
> ip!,{v1,v2,v3,v4,v5,v6,sl,fp}'
> machine/sim/arch_setjmp_arm.S:45: Error: operand 1 must be an integer 
> register -- `mov r2,sp'
> machine/sim/arch_setjmp_arm.S:46: Error: unknown mnemonic `stmia' -- `stmia 
> ip!,{r2,lr}'
> machine/sim/arch_setjmp_arm.S:47: Error: operand 1 must be an integer 
> register -- `mov r0,#0'
> machine/sim/arch_setjmp_arm.S:75: Error: unknown mnemonic `bx' -- `bx lr'
> machine/sim/arch_setjmp_arm.S:77: Error: unknown pseudo-op: `.syntax'
> machine/sim/arch_setjmp_arm.S:81: Error: operand 1 must be an integer 
> register -- `mov ip,r0'
> machine/sim/arch_setjmp_arm.S:82: Error: operand 1 must be an SVE predicate 
> register -- `movs r0,r1'
> machine/sim/arch_setjmp_arm.S:83: Error: unknown mnemonic `moveq' -- `moveq 
> r0,#1'
> machine/sim/arch_setjmp_arm.S:84: Error: unknown mnemonic `ldmia' -- `ldmia 
> ip!,{v1,v2,v3,v4,v5,v6,sl,fp}'
> machine/sim/arch_setjmp_arm.S:85: Error: unknown mnemonic `ldmia' -- `ldmia 
> ip!,{r2,lr}'
> machine/sim/arch_setjmp_arm.S:103: Error: unknown mnemonic `bx' -- `bx lr'
> machine/sim/arch_setjmp_arm.S:86: Error: undefined symbol r2 used as an 
> immediate value
> make[1]: *** [Makefile:130: bin/arch_setjmp_arm.o] Error 1
> make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/libs/libc'
> make: *** [tools/LibTargets.mk:168: libs/libc/libc.a] Error 2
> 
> 
> 
> 
>> Am 29.01.2022 um 19:00 schrieb Peter Kalbus > <mailto:p...@mailbox.org.INVALID>>:
>> 
>> Config and log from my M1:
>> 
>> ——
>> 
>> #
>> # This file is autogenerated: PLEASE DO NOT EDIT IT.
>> #
>> # You can use "make menuconfig" to make any modifications to the installed 
>> .config file.
>> # You can then do "make savedefconfig" to generate a new defconfig file that 
>> includes your
>> # modifications.
>> #
>> # CONFIG_NSH_CMDOPT_HEXDUMP is not set
>> CONFIG_ARCH="sim"
>> CONFIG_ARCH_BOARD="sim"
>> CONFIG_ARCH_BOARD_SIM=y
>> CONFIG_ARCH_CHIP="sim"
>> CONFIG_ARCH_SIM=y
>> CONFIG_BOARDCTL_APP_SYMTAB=y
>> CONFIG_BOARDCTL_POWEROFF=y
>> CONFIG_BOARD_LOOPSPERMSEC=0
>> CONFIG_BOOT_RUNFROMEXTSRAM=y
>> CONFIG_BUILTIN=y
>> CONFIG_DEBUG_SYMBOLS=y
>> CONFIG_DEV_GPIO=y
>> CONFIG_DEV_LOOP=y
>> CONFIG_DEV_ZERO=y
>> CONFIG_EXAMPLES_GPIO=y
>> CONFIG_EXAMPLES_HELLO=y
>> CONFIG_FAT_LCNAMES=y
>> CONFIG_FAT_LFN=y
>> CONFIG_FSUTILS_PASSWD=y
>> CONFIG_FSUTILS_PASSWD_READONLY=y
>> CONFIG_FS_BINFS=y
>> CONFIG_FS_FAT=y
>> CONFIG_FS_PROCFS=y
>> CONFIG_FS_RAMMAP=y
>> CONFIG_FS_ROMFS=y
>> CONFIG_GPIO_LOWER_HALF=y
>> CONFIG_HOST_ARM=y
>> CONFIG_HOST_MACOS=y
>> CONFIG_IDLETHREAD_STACKSIZE=4096
>&

Re: Build Nuttx on MAC / ARM64 Ubuntu

2022-01-29 Thread Peter Kalbus

Hi again,

just as an extension. On the same M1, I’ve Ubuntu ARM64 running using Parallels 
VM.

Same issue: Host CPU Type detected as „x86_64“ and compilation stops at same 
file —> see below.

Issue seems to be not specific to MacOS M1, but rather generic to ARM64 host 
systems.

/Piet


—


AR (create): libdrivers.a   bchlib_setup.o bchlib_teardown.o bchlib_read.o 
bchlib_write.o bchlib_cache.o bchlib_sem.o bchdev_register.o 
bchdev_unregister.o bchdev_driver.o ioe_dummy.o gpio.o gpio_lower_half.o loop.o 
losetup.o pipe.o fifo.o pipe_common.o serial.o serial_io.o vsyslog.o 
syslog_stream.o syslog_channel.o syslog_putc.o syslog_write.o syslog_force.o 
syslog_flush.o syslog_initialize.o syslog_device.o oneshot.o arch_alarm.o 
hid_parser.o dev_null.o dev_zero.o ramdisk.o mkrd.o
make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/drivers'
IN: drivers/libdrivers.a -> staging/libdrivers.a
make[1]: Entering directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
CC:  boardctl.c
AR (create): libboards.a   dummy.o boardctl.o 
make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/boards'
IN: boards/libboards.a -> staging/libboards.a
make[1]: Entering directory '/home/piet/Projects/NuttX/ptka/nuttx/libs/libc'
AS:  machine/sim/arch_setjmp_arm.S
machine/sim/arch_setjmp_arm.S: Assembler messages:
machine/sim/arch_setjmp_arm.S:39: Error: unknown pseudo-op: `.syntax'
machine/sim/arch_setjmp_arm.S:43: Error: operand 1 must be an integer register 
-- `mov ip,r0'
machine/sim/arch_setjmp_arm.S:44: Error: unknown mnemonic `stmia' -- `stmia 
ip!,{v1,v2,v3,v4,v5,v6,sl,fp}'
machine/sim/arch_setjmp_arm.S:45: Error: operand 1 must be an integer register 
-- `mov r2,sp'
machine/sim/arch_setjmp_arm.S:46: Error: unknown mnemonic `stmia' -- `stmia 
ip!,{r2,lr}'
machine/sim/arch_setjmp_arm.S:47: Error: operand 1 must be an integer register 
-- `mov r0,#0'
machine/sim/arch_setjmp_arm.S:75: Error: unknown mnemonic `bx' -- `bx lr'
machine/sim/arch_setjmp_arm.S:77: Error: unknown pseudo-op: `.syntax'
machine/sim/arch_setjmp_arm.S:81: Error: operand 1 must be an integer register 
-- `mov ip,r0'
machine/sim/arch_setjmp_arm.S:82: Error: operand 1 must be an SVE predicate 
register -- `movs r0,r1'
machine/sim/arch_setjmp_arm.S:83: Error: unknown mnemonic `moveq' -- `moveq 
r0,#1'
machine/sim/arch_setjmp_arm.S:84: Error: unknown mnemonic `ldmia' -- `ldmia 
ip!,{v1,v2,v3,v4,v5,v6,sl,fp}'
machine/sim/arch_setjmp_arm.S:85: Error: unknown mnemonic `ldmia' -- `ldmia 
ip!,{r2,lr}'
machine/sim/arch_setjmp_arm.S:103: Error: unknown mnemonic `bx' -- `bx lr'
machine/sim/arch_setjmp_arm.S:86: Error: undefined symbol r2 used as an 
immediate value
make[1]: *** [Makefile:130: bin/arch_setjmp_arm.o] Error 1
make[1]: Leaving directory '/home/piet/Projects/NuttX/ptka/nuttx/libs/libc'
make: *** [tools/LibTargets.mk:168: libs/libc/libc.a] Error 2




> Am 29.01.2022 um 19:00 schrieb Peter Kalbus :
> 
> Config and log from my M1:
> 
> ——
> 
> #
> # This file is autogenerated: PLEASE DO NOT EDIT IT.
> #
> # You can use "make menuconfig" to make any modifications to the installed 
> .config file.
> # You can then do "make savedefconfig" to generate a new defconfig file that 
> includes your
> # modifications.
> #
> # CONFIG_NSH_CMDOPT_HEXDUMP is not set
> CONFIG_ARCH="sim"
> CONFIG_ARCH_BOARD="sim"
> CONFIG_ARCH_BOARD_SIM=y
> CONFIG_ARCH_CHIP="sim"
> CONFIG_ARCH_SIM=y
> CONFIG_BOARDCTL_APP_SYMTAB=y
> CONFIG_BOARDCTL_POWEROFF=y
> CONFIG_BOARD_LOOPSPERMSEC=0
> CONFIG_BOOT_RUNFROMEXTSRAM=y
> CONFIG_BUILTIN=y
> CONFIG_DEBUG_SYMBOLS=y
> CONFIG_DEV_GPIO=y
> CONFIG_DEV_LOOP=y
> CONFIG_DEV_ZERO=y
> CONFIG_EXAMPLES_GPIO=y
> CONFIG_EXAMPLES_HELLO=y
> CONFIG_FAT_LCNAMES=y
> CONFIG_FAT_LFN=y
> CONFIG_FSUTILS_PASSWD=y
> CONFIG_FSUTILS_PASSWD_READONLY=y
> CONFIG_FS_BINFS=y
> CONFIG_FS_FAT=y
> CONFIG_FS_PROCFS=y
> CONFIG_FS_RAMMAP=y
> CONFIG_FS_ROMFS=y
> CONFIG_GPIO_LOWER_HALF=y
> CONFIG_HOST_ARM=y
> CONFIG_HOST_MACOS=y
> CONFIG_IDLETHREAD_STACKSIZE=4096
> CONFIG_INIT_ENTRYPOINT="nsh_main"
> CONFIG_IOEXPANDER=y
> CONFIG_IOEXPANDER_DUMMY=y
> CONFIG_LIBC_ENVPATH=y
> CONFIG_LIBC_EXECFUNCS=y
> CONFIG_LIBC_LOCALE=y
> CONFIG_LIBC_LOCALE_CATALOG=y
> CONFIG_LIBC_LOCALE_GETTEXT=y
> CONFIG_NSH_ARCHINIT=y
> CONFIG_NSH_ARCHROMFS=y
> CONFIG_NSH_BUILTIN_APPS=y
> CONFIG_NSH_CONSOLE_LOGIN=y
> CONFIG_NSH_FATDEVNO=2
> CONFIG_NSH_FILE_APPS=y
> CONFIG_NSH_MOTD=y
> CONFIG_NSH_MOTD_STRING="MOTD: username=admin password=Administrator"
> CONFIG_NSH_READLINE=y
> CONFIG_NSH_ROMFSDEVNO=1
> CONFIG_NSH_ROMFSETC=y
> CONFIG_PATH_INITIAL="/bin"
> CONFIG_POSIX_SPAWN_PROXY_STACKSIZE=2048
> CONFIG_PSEUDOFS_ATTRIBUTES=y
> CONFIG_PSEUDOFS_SOFTLINKS=y
> CONFIG_READLINE_TABCOMPLETI

Re: Build Nuttx on MAC

2022-01-29 Thread Peter Kalbus

 
EXTRAFLAGS="-D__KERNEL__ "
make[1]: `libsched.a' is up to date.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C drivers libdrivers.a 
EXTRAFLAGS="-D__KERNEL__ "
make[1]: `libdrivers.a' is up to date.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C boards libboards.a 
EXTRAFLAGS="-D__KERNEL__ "
make[1]: `libboards.a' is up to date.
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C libs/libc libc.a 
EXTRAFLAGS=""
AS:  machine/sim/arch_setjmp_arm.S
cc -c -Wall -Wstrict-prototypes -Wshadow -Wundef -g -fno-builtin 
-fvisibility=hidden -fno-common -isystem 
"/Users/piet/Projects/NuttX/feature-sim-macos-m1-support/nuttx/include" 
-D__NuttX__ -U_AIX -U_WIN32 -U__APPLE__ -U__FreeBSD__ -U__NetBSD__ -U__linux__ 
-U__sun__ -U__unix__ -U__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__  -pipe 
-D__ASSEMBLY__  machine/sim/arch_setjmp_arm.S  -o  bin/arch_setjmp_arm.o
machine/sim/arch_setjmp_arm.S:38:1: error: unknown directive
.syntax unified
^
machine/sim/arch_setjmp_arm.S:40:1: error: unknown directive
.type setjmp,%function
^
machine/sim/arch_setjmp_arm.S:42:6: error: invalid operand for instruction
 mov ip,r0
 ^
machine/sim/arch_setjmp_arm.S:43:31: error: vector register expected
 stmia ip!,{v1,v2,v3,v4,v5,v6,sl,fp}
  ^
machine/sim/arch_setjmp_arm.S:44:6: error: invalid operand for instruction
 mov r2,sp
 ^
machine/sim/arch_setjmp_arm.S:45:13: error: vector register expected
 stmia ip!,{r2,lr}
^
machine/sim/arch_setjmp_arm.S:46:6: error: invalid operand for instruction
 mov r0,#0
 ^
machine/sim/arch_setjmp_arm.S:48:4: error: unrecognized instruction mnemonic, 
did you mean: b, bcax, bl, br, sb, tbx?
3: bx lr
   ^
machine/sim/arch_setjmp_arm.S:50:1: error: unknown directive
.syntax unified
^
machine/sim/arch_setjmp_arm.S:52:1: error: unknown directive
.type longjmp,%function
^
machine/sim/arch_setjmp_arm.S:54:6: error: invalid operand for instruction
 mov ip,r0
 ^
machine/sim/arch_setjmp_arm.S:55:7: error: invalid operand for instruction
 movs r0,r1
  ^
machine/sim/arch_setjmp_arm.S:56:2: error: unrecognized instruction mnemonic, 
did you mean: mov?
 moveq r0,#1
 ^
machine/sim/arch_setjmp_arm.S:57:32: error: vector register expected
 ldmia ip!, {v1,v2,v3,v4,v5,v6,sl,fp}
   ^
machine/sim/arch_setjmp_arm.S:58:14: error: vector register expected
 ldmia ip!, {r2,lr}
 ^
machine/sim/arch_setjmp_arm.S:59:9: error: expected compatible register or 
logical immediate
 mov sp,r2
^
machine/sim/arch_setjmp_arm.S:61:4: error: unrecognized instruction mnemonic, 
did you mean: b, bcax, bl, br, sb, tbx?
3: bx lr
   ^
make[1]: *** [bin/arch_setjmp_arm.o] Error 1
make: *** [libs/libc/libc.a] Error 2



> Am 29.01.2022 um 18:40 schrieb Peter Kalbus :
> 
> Hi,
> 
> I’m using NuttX on a M1 MacBook Air since a couple of months. 
> I’ve no issues to get NuttX compiled for my RP2040 based targets.
> 
> But I can confirm, that the Sim configuration sim:nsh not working.
> 
> Currently, I see there are two issues:
> 
>   /1/ M1 „Host CPU Type“ is detected as x86_64, but not as „arm“
>   Workarround for this is, to set it manually in the configuration
> 
>   /2/ At least the following files are not compilable
>   arch/sim/src/sim/up_vfork_arm.S 
> <https://github.com/ptka/incubator-nuttx#diff-fd079323b0636ac4012f50afe8c656d7a760b0429f46188919fe7807f8a5>
>   libs/libc/machine/sim/arch_setjmp_arm.S 
> <https://github.com/ptka/incubator-nuttx#diff-cffded10274b4845aae8c75bd91550d140214585ea17d47f2cf01dd021a16abe>
>   libs/libc/stdio/lib_libvsprintf.c 
> <https://github.com/ptka/incubator-nuttx#diff-befc8e04ddb3722f024f65ffd7648aac1cb24846d2b80fff6328e3cb5862220f>
> 
> The 2nd point could be related to a wrong compiler/assembler selected
> or the way, the compiler is invoked. In worst case, it’s there code itself.
> 
> I would be very interested helping to find a solution on this topic.
> 
> /Piet
> 
>> Am 29.01.2022 um 17:33 schrieb Tomasz CEDRO :
>> 
>> macOS is a BSD.. very close to FreeBSD:
>> 1. Use gmake.
>> 2. Make sure you have the right version of kconfig-frontends package
>> installed. If you installed it locally make sure path to your local
>> binary is in the first place.
>> 
>> -- 
>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>

Re: Build Nuttx on MAC

2022-01-29 Thread Peter Kalbus

Hi,

I’m using NuttX on a M1 MacBook Air since a couple of months. 
I’ve no issues to get NuttX compiled for my RP2040 based targets.

But I can confirm, that the Sim configuration sim:nsh not working.

Currently, I see there are two issues:

/1/ M1 „Host CPU Type“ is detected as x86_64, but not as „arm“
Workarround for this is, to set it manually in the configuration

/2/ At least the following files are not compilable
arch/sim/src/sim/up_vfork_arm.S 

libs/libc/machine/sim/arch_setjmp_arm.S 

libs/libc/stdio/lib_libvsprintf.c 


The 2nd point could be related to a wrong compiler/assembler selected
or the way, the compiler is invoked. In worst case, it’s there code itself.

I would be very interested helping to find a solution on this topic.

/Piet

> Am 29.01.2022 um 17:33 schrieb Tomasz CEDRO :
> 
> macOS is a BSD.. very close to FreeBSD:
> 1. Use gmake.
> 2. Make sure you have the right version of kconfig-frontends package
> installed. If you installed it locally make sure path to your local
> binary is in the first place.
> 
> -- 
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info

Re: SD Card in Simulation

2022-01-24 Thread Peter Kalbus

Hi Fotis,

you use the ROMFS feature to include files directly on the image … it depends 
on some external tool called ‚genromfs‘

You may check for ROMFS and ROMFSETC in the configuration and documentation.

/Piet



> Am 24.01.2022 um 12:07 schrieb Fotis Panagiotopoulos :
> 
> Hello,
> 
> I am working on a system that uses an SD card to read various files.
> I am also using the simulator for testing this firmware.
> 
> I would like to test the parts of the system that read and parse these
> files, so I need a way to simulate the SD card.
> 
> Is there any way to achieve this?
> 
> Ideally, I would like to mount a directory of the host system directly in
> NuttX.
> Or maybe select a set of files to be included in compile time?
> 
> Thank you!

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

2022-01-17 Thread Peter Kalbus

Hi Alan,

sure … can I create a PR from a single chasnge?

Background is, that I have two changes on the branch:

- older one: get CDCECM enabled in RP2040 in general —> not yet fully 
done
- newer one: the fix from alignment issue

/Piet


> Am 17.01.2022 um 13:08 schrieb Alan Carvalho de Assis :
> 
> Hi Peter,
> 
> Could you please send a Pull Request to mainline? Click on Pull
> Request tab and New Pull Request.
> 
> BR,
> 
> Alan
> 
> On 1/17/22, Peter Kalbus  wrote:
>> Hi Michael,
>> 
>> understood … I changed the fix according to you proposal and tested it …
>> works fine,too:
>> 
>> https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d
>> <https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d>
>> 
>> struct cdcecm_driver_s
>> {
>>  /* USB CDC-ECM device */
>> 
>>  struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
>>  struct usbdev_devinfo_s  devinfo;
>>  FAR struct usbdev_req_s *ctrlreq; /* Allocated control request */
>>  FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
>>  FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
>>  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>  uint8_t  config;  /* Selected configuration number
>> */
>> 
>>  aligned_data(2) uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
>>  CONFIG_NET_GUARDSIZE];
>> 
>>  struct usbdev_req_s *rdreq;   /* Single read request */
>> 
>> 
>> /Piet
>> 
>> 
>>> Am 17.01.2022 um 10:42 schrieb Michael Jung :
>>> 
>>> Hi Peter,
>>> 
>>> good finding!
>>> 
>>> There is actually a comment in this regard in include/nuttx/net/netdev.h:
>>>> The d_buf array must be aligned to two-byte, 16-bit address boundaries
>>>> in
>>> order to support aligned 16-bit accesses performed by the network.
>>> 
>>> W.r.t. to your proposed fix I think it would be more appropriate to make
>>> the alignment requirement explicit by using the 'aligned_data' macro from
>>> include/nuttx/compiler.h.
>>> 
>>> Thanks!
>>> Michael
>>> 
>>> Am Mo., 17. Jan. 2022 um 09:01 Uhr schrieb Peter Kalbus
>>> mailto:p...@mailbox.org.invalid>>:
>>> 
>>>> Hi all,
>>>> 
>>>> during the bring-up of the composite-cdcecm a alignment issue result in
>>>> hard faults (always on the used rp2040 based device).
>>>> 
>>>> ANALYSIS:
>>>> 
>>>> The root cause seems to be the way the pktbuf is defined in
>>>> cdcecm_driver_s (driver/usbdev/cdcecm.c):
>>>> 
>>>> struct cdcecm_driver_s
>>>> {
>>>> /* USB CDC-ECM device */
>>>> 
>>>> struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
>>>> struct usbdev_devinfo_s  devinfo;
>>>> FAR struct usbdev_req_s *ctrlreq; /* Allocated control request
>>>> */
>>>> FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
>>>> FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
>>>> FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>>> uint8_t  config;  /* Selected configuration
>>>> number */
>>>> 
>>>> uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
>>>> CONFIG_NET_GUARDSIZE];
>>>> 
>>>> 
>>>> Due to 'config‘ element ‚ pktbuf‘ in the structure is not aligned in
>>>> anyway from the struct itself.
>>>> 
>>>> The driver structure is allocation during driver initialization in
>>>> cdcecm_classobject():
>>>> 
>>>> /* Initialize the driver structure */
>>>> 
>>>> self = kmm_zalloc(sizeof(struct cdcecm_driver_s));
>>>> if (!self)
>>>>   {
>>>> nerr("Out of memory!\n");
>>>> return -ENOMEM;
>>>>   }
>>>> 
>>>> /* Network device initialization */
>>>> 
>>>> self->dev.d_buf = self->pktbuf;
>>>> 
>>>> As ’ self’ points to an aligned address, 'pktbuf' is always aligned at
>>>> an
>>>> odd address.
>>>> 
>>>> Once the driver is ini

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

2022-01-17 Thread Peter Kalbus

Hi Alan,

sure … can I create a PR from a single chasnge?

Background is, that I have two changes on the branch:

- older one: get CDCECM enabled in RP2040 in general —> not yet fully 
done
- newer one: the fix from alignment issue

/Piet


> Am 17.01.2022 um 13:19 schrieb Peter Kalbus :
> 
> Hi Alan,
> 
> sure … can I create a PR from a single chasnge?
> 
> Background is, that I have two changes on the branch:
> 
>   - older one: get CDCECM enabled in RP2040 in general —> not yet fully 
> done
>   - newer one: the fix from alignment issue
> 
> /Piet
> 
> 
>> Am 17.01.2022 um 13:08 schrieb Alan Carvalho de Assis :
>> 
>> Hi Peter,
>> 
>> Could you please send a Pull Request to mainline? Click on Pull
>> Request tab and New Pull Request.
>> 
>> BR,
>> 
>> Alan
>> 
>> On 1/17/22, Peter Kalbus  wrote:
>>> Hi Michael,
>>> 
>>> understood … I changed the fix according to you proposal and tested it …
>>> works fine,too:
>>> 
>>> https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d
>>> <https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d>
>>> 
>>> struct cdcecm_driver_s
>>> {
>>> /* USB CDC-ECM device */
>>> 
>>> struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
>>> struct usbdev_devinfo_s  devinfo;
>>> FAR struct usbdev_req_s *ctrlreq; /* Allocated control request */
>>> FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
>>> FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
>>> FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>> uint8_t  config;  /* Selected configuration number
>>> */
>>> 
>>> aligned_data(2) uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
>>> CONFIG_NET_GUARDSIZE];
>>> 
>>> struct usbdev_req_s *rdreq;   /* Single read request */
>>> 
>>> 
>>> /Piet
>>> 
>>> 
>>>> Am 17.01.2022 um 10:42 schrieb Michael Jung :
>>>> 
>>>> Hi Peter,
>>>> 
>>>> good finding!
>>>> 
>>>> There is actually a comment in this regard in include/nuttx/net/netdev.h:
>>>>> The d_buf array must be aligned to two-byte, 16-bit address boundaries
>>>>> in
>>>> order to support aligned 16-bit accesses performed by the network.
>>>> 
>>>> W.r.t. to your proposed fix I think it would be more appropriate to make
>>>> the alignment requirement explicit by using the 'aligned_data' macro from
>>>> include/nuttx/compiler.h.
>>>> 
>>>> Thanks!
>>>> Michael
>>>> 
>>>> Am Mo., 17. Jan. 2022 um 09:01 Uhr schrieb Peter Kalbus
>>>> mailto:p...@mailbox.org.invalid>>:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> during the bring-up of the composite-cdcecm a alignment issue result in
>>>>> hard faults (always on the used rp2040 based device).
>>>>> 
>>>>> ANALYSIS:
>>>>> 
>>>>> The root cause seems to be the way the pktbuf is defined in
>>>>> cdcecm_driver_s (driver/usbdev/cdcecm.c):
>>>>> 
>>>>> struct cdcecm_driver_s
>>>>> {
>>>>> /* USB CDC-ECM device */
>>>>> 
>>>>> struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
>>>>> struct usbdev_devinfo_s  devinfo;
>>>>> FAR struct usbdev_req_s *ctrlreq; /* Allocated control request
>>>>> */
>>>>> FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
>>>>> FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
>>>>> FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>>>> uint8_t  config;  /* Selected configuration
>>>>> number */
>>>>> 
>>>>> uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
>>>>>CONFIG_NET_GUARDSIZE];
>>>>> 
>>>>> 
>>>>> Due to 'config‘ element ‚ pktbuf‘ in the structure is not aligned in
>>>>> anyway from the struct itself.
>>>>> 
>>>>> The driver structure is allocation during drive

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

2022-01-17 Thread Peter Kalbus

Hi Michael,

understood … I changed the fix according to you proposal and tested it … works 
fine,too:

https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d
 
<https://github.com/ptka/incubator-nuttx/commit/09be64bb1f2fff9f85a392e0fab6915f9083fe2d>

struct cdcecm_driver_s
{
  /* USB CDC-ECM device */

  struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
  struct usbdev_devinfo_s  devinfo;
  FAR struct usbdev_req_s *ctrlreq; /* Allocated control request */
  FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
  FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
  uint8_t  config;  /* Selected configuration number */
 
  aligned_data(2) uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
  CONFIG_NET_GUARDSIZE];

  struct usbdev_req_s *rdreq;   /* Single read request */


/Piet


> Am 17.01.2022 um 10:42 schrieb Michael Jung :
> 
> Hi Peter,
> 
> good finding!
> 
> There is actually a comment in this regard in include/nuttx/net/netdev.h:
>> The d_buf array must be aligned to two-byte, 16-bit address boundaries in
> order to support aligned 16-bit accesses performed by the network.
> 
> W.r.t. to your proposed fix I think it would be more appropriate to make
> the alignment requirement explicit by using the 'aligned_data' macro from
> include/nuttx/compiler.h.
> 
> Thanks!
> Michael
> 
> Am Mo., 17. Jan. 2022 um 09:01 Uhr schrieb Peter Kalbus
> mailto:p...@mailbox.org.invalid>>:
> 
>> Hi all,
>> 
>> during the bring-up of the composite-cdcecm a alignment issue result in
>> hard faults (always on the used rp2040 based device).
>> 
>> ANALYSIS:
>> 
>> The root cause seems to be the way the pktbuf is defined in
>> cdcecm_driver_s (driver/usbdev/cdcecm.c):
>> 
>> struct cdcecm_driver_s
>> {
>>  /* USB CDC-ECM device */
>> 
>>  struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
>>  struct usbdev_devinfo_s  devinfo;
>>  FAR struct usbdev_req_s *ctrlreq; /* Allocated control request */
>>  FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
>>  FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
>>  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>  uint8_t  config;  /* Selected configuration
>> number */
>> 
>>  uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
>>  CONFIG_NET_GUARDSIZE];
>> 
>> 
>> Due to 'config‘ element ‚ pktbuf‘ in the structure is not aligned in
>> anyway from the struct itself.
>> 
>> The driver structure is allocation during driver initialization in
>> cdcecm_classobject():
>> 
>>  /* Initialize the driver structure */
>> 
>>  self = kmm_zalloc(sizeof(struct cdcecm_driver_s));
>>  if (!self)
>>{
>>  nerr("Out of memory!\n");
>>  return -ENOMEM;
>>}
>> 
>>  /* Network device initialization */
>> 
>>  self->dev.d_buf = self->pktbuf;
>> 
>> As ’ self’ points to an aligned address, 'pktbuf' is always aligned at an
>> odd address.
>> 
>> Once the driver is initialized and processes received data in
>> cdcecm_receive() the driver creates a hard fault at:
>> 
>> #ifdef CONFIG_NET_IPv4
>>  if (BUF->type == HTONS(ETHTYPE_IP))
>>{
>> 
>> BUF/eth_hdr_s are defined as:
>> 
>> #define BUF ((struct eth_hdr_s *)self->dev.d_buf)
>> 
>> 
>> struct eth_hdr_s
>> {
>>  uint8_t  dest[6]; /* Ethernet destination address (6 bytes) */
>>  uint8_t  src[6];  /* Ethernet source address (6 bytes) */
>>  uint16_t type;/* Type code (2 bytes) */
>> };
>> 
>> 
>> Element ’ type’ is always odd aligned and access to it results in all
>> cases to a hard fault on the used rp2040 based board.
>> 
>> PROPOSAL:
>> 
>> Assuming the analysis is correct, there could be different options to fix
>> there issue.
>> Proposal would be to let the compiler do the job and not introduce any
>> special code or elements in the structure to fix it programmatically.
>> 
>> Analysing cdcdcm_driver_s in more details:
>> 
>>  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
>>  uint8_t  config;  /* Selected configuration
>> number */
>> 
>>  uint8_t

rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

2022-01-17 Thread Peter Kalbus

Hi all,

during the bring-up of the composite-cdcecm a alignment issue result in hard 
faults (always on the used rp2040 based device).

ANALYSIS:

The root cause seems to be the way the pktbuf is defined in cdcecm_driver_s 
(driver/usbdev/cdcecm.c):

struct cdcecm_driver_s
{
  /* USB CDC-ECM device */

  struct usbdevclass_driver_s  usbdev;  /* USB device class vtable */
  struct usbdev_devinfo_s  devinfo;
  FAR struct usbdev_req_s *ctrlreq; /* Allocated control request */
  FAR struct usbdev_ep_s  *epint;   /* Interrupt IN endpoint */
  FAR struct usbdev_ep_s  *epbulkin;/* Bulk IN endpoint */
  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
  uint8_t  config;  /* Selected configuration number */

  uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
  CONFIG_NET_GUARDSIZE];


Due to 'config‘ element ‚ pktbuf‘ in the structure is not aligned in anyway 
from the struct itself.

The driver structure is allocation during driver initialization in 
cdcecm_classobject():

  /* Initialize the driver structure */

  self = kmm_zalloc(sizeof(struct cdcecm_driver_s));
  if (!self)
{
  nerr("Out of memory!\n");
  return -ENOMEM;
}

  /* Network device initialization */

  self->dev.d_buf = self->pktbuf;

As ’ self’ points to an aligned address, 'pktbuf' is always aligned at an odd 
address.

Once the driver is initialized and processes received data in cdcecm_receive() 
the driver creates a hard fault at:

#ifdef CONFIG_NET_IPv4
  if (BUF->type == HTONS(ETHTYPE_IP))
{

BUF/eth_hdr_s are defined as:

#define BUF ((struct eth_hdr_s *)self->dev.d_buf)


struct eth_hdr_s
{
  uint8_t  dest[6]; /* Ethernet destination address (6 bytes) */
  uint8_t  src[6];  /* Ethernet source address (6 bytes) */
  uint16_t type;/* Type code (2 bytes) */
};


Element ’ type’ is always odd aligned and access to it results in all cases to 
a hard fault on the used rp2040 based board.

PROPOSAL:

Assuming the analysis is correct, there could be different options to fix there 
issue.
Proposal would be to let the compiler do the job and not introduce any special 
code or elements in the structure to fix it programmatically.

Analysing cdcdcm_driver_s in more details:

  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */
  uint8_t  config;  /* Selected configuration number */

  uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
  CONFIG_NET_GUARDSIZE];


Element 'epbulkout' is a 32bit pointer and thus always aligned to 32bit.
Element 'config‘ following is also aligned to 32bit —> as it’s only an uint8_t 
is doesn’t need to be aligned at all.
Element ‚pktbuf‘ is odd aligned, but needs to be at least 16bit aligned.

Exchanging 'config‘ and 'pktbuf‘ in the structure solves the issue:

  FAR struct usbdev_ep_s  *epbulkout;   /* Bulk OUT endpoint */

  uint8_t  pktbuf[CONFIG_NET_ETH_PKTSIZE +
  CONFIG_NET_GUARDSIZE];

  uint8_t  config;  /* Selected configuration number */


Element ‚pktbuf‘ is now 32bit aligned as it’s following a 32bit pointer.

The change has been tested on an rp2040 based device.

The fix can be reviewed at: 
https://github.com/ptka/incubator-nuttx/commit/01732850ad345b5e2a9af24f788935d8f7928781
 


Please comment on the analysis and proposed fix.

/Piet

Re: Support for Pimonori Tiny2040

2022-01-11 Thread Peter Kalbus

Hi Alan,

saw it this morning, too … don’t know why … I was sleeping :-)

Let’s see, what todo next with the Tiny2040 device.

/Piet


> Am 11.01.2022 um 14:18 schrieb Alan Carvalho de Assis :
> 
> Hi Peter,
> 
> For some strange reason your email was sent again today (I don't know
> if only I received it). But it is strange because the date of the
> email is from Jan 7 2022, although it was received today.
> 
> BTW, I think you already added the support to your board:
> https://github.com/apache/incubator-nuttx/commit/72355878ec608bacc55afcbe15fecfdce04bad65
> 
> Great work! Kudos!!!
> 
> Now you can start to play with it adding sensors, creating new board
> profiles to test other NuttX features, etc.
> 
> BR,
> 
> Alan
> 
> On 1/7/22, Peter Kalbus  wrote:
>> Hi,
>> 
>> I owned a Pimoroni Tiny2040 device.
>> It’s an RP2040 based device with some interesting features:
>> 
>>  + small form factor (18x21.3mm)
>>  + 8 MByte Flash
>>  + RGB LED
>>  + Reset Button
>>  + USB-C
>>  - reduced pin-header
>> 
>> I’d like to add the device based on the available RP2040 support.
>> It’s basically working, but the specifics are missing.
>> 
>> 
>> My plan is to re-use the code from
>> 
>>  'boards/arm/rp2040/raspberrypi-pico‘ and
>> 
>> and add the support in
>> 
>>  'boards/arm/rp2040/pimoroni-tiny2040‘.
>> 
>> 
>> Anything wrong with this approach?
>> 
>> Regards
>> Piet
>> 
>>

Support for Pimonori Tiny2040

2022-01-10 Thread Peter Kalbus

Hi,

I owned a Pimoroni Tiny2040 device.
It’s an RP2040 based device with some interesting features:

  + small form factor (18x21.3mm)
  + 8 MByte Flash
  + RGB LED
  + Reset Button
  + USB-C
  - reduced pin-header

I’d like to add the device based on the available RP2040 support.
It’s basically working, but the specifics are missing.


My plan is to re-use the code from

  'boards/arm/rp2040/raspberrypi-pico‘ and

and add the support in

  'boards/arm/rp2040/pimoroni-tiny2040‘.


Anything wrong with this approach?

Regards
Piet

Re: Support for Pimoroni Tiny2040

2022-01-07 Thread Peter Kalbus

Hi Alan,

thanks for feedback.

Support will go into 'boards/arm/rp2040/pimoroni-tiny2040‘.

I’ll create PR once it’s done.

/Piet


> Am 07.01.2022 um 15:50 schrieb Alan Carvalho de Assis :
> 
> Hi Peter,
> 
> You can use RaspberryPico board, but I think it is a good idea to
> create a new directory to Pimoroni Tiny2040 on NuttX because the
> RaspberryPico could have different hardware features and different
> pins usage.
> 
> So, if you create a new directory entry to Tiny2040 you can submit it
> to mainline and let more people to use it.
> 
> BR,
> 
> Alan
> 
> On 1/7/22, Kalbus, Peter  wrote:
>> Corrected subject …
>> 
>> /Piet
>> 
>> 
>>> Am 07.01.2022 um 14:55 schrieb Kalbus, Peter :
>>> 
>>> Hi,
>>> 
>>> I owned a Pimoroni Tiny2040 device.
>>> It’s an RP2040 based device with some interesting features:
>>> 
>>> + small form factor (18x21.3mm)
>>> + 8 MByte Flash
>>> + RGB LED
>>> + Reset Button
>>> + USB-C
>>> - reduced pin-header
>>> 
>>> I’d like to add the device based on the available RP2040 support.
>>> It’s basically working, but the specifics are missing.
>>> 
>>> 
>>> My plan is to re-use the code from
>>> 
>>> 'boards/arm/rp2040/raspberrypi-pico‘ and
>>> 
>>> and add the support in
>>> 
>>> 'boards/arm/rp2040/pimoroni-tiny2040‘.
>>> 
>>> 
>>> Anything wrong with this approach?
>>> Someone already working on this device?
>>> 
>>> 
>>> Regards
>>> Piet
>>> 
>>

Re: Build Nuttx on MAC / ARM64 Ubuntu

Re: Build Nuttx on MAC / ARM64 Ubuntu

Re: Build Nuttx on MAC / ARM64 Ubuntu

Re: Build Nuttx on MAC / ARM64 Ubuntu

Re: Build Nuttx on MAC / ARM64 Ubuntu

Re: Build Nuttx on MAC

Re: Build Nuttx on MAC

Re: SD Card in Simulation

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

Re: rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

rp2040: composite-cdcecm: hardfault due to alignment issue in driver/usbdev/usbdev.c

Re: Support for Pimonori Tiny2040

Support for Pimonori Tiny2040

Re: Support for Pimoroni Tiny2040

15 matches

Site Navigation

Mail list logo

Footer information