Re: BL616/618 Support
That's great news! Thanks for letting me know. YB 2023년 4월 28일 (금) 오후 3:49, Xiang Xiao 님이 작성: > bouffalolab is porting BL616 to NuttX, you can ask FAE for the detailed > schedule. > > On Fri, Apr 28, 2023 at 1:40 PM Yebin Lee wrote: > > > Is anyone working on adding BL616/618 to NuttX? > > It seems it's good timing to add support for this wireless SoC as > > their recent SDK now supports WiFi, BLE, and almost all peripherals > > this chip has. > > If someone is already doing it, I'm wondering whether I can join and > > collaborate on it. > > > > YB > > >
Re: FAQ :-)
On Thu, Apr 27, 2023 at 6:03 PM Tomek CEDRO wrote: > Hello world :-) > > I have some in-development question that could probably go to DOC/FAQ > as I found some questions/answers there already :-) Any hints > appreciated. Also the logic / approach errors and valid solution > propositions welcome :-) :-) > > 1. Daemon / Service: > > 1.1. I would like to have application running as daemon in the > background all the time. Is this possible? Yes, though I don't think there's a way to designate a program as a "daemon" necessarily, but a program can run all the time. In Kconfig there's a setting (I'm on my phone now so don't remember the name off the top of my head) that determines what initial task to run. In most in-tree board configs this is set to nsh_main. You could set this to your own init-style program that launches your daemon, or multiple daemons, and perhaps nsh as well, if you want it in the end product. Continued below: 1.2. On application error / crash I would like the application to > restart so it is always available. Is this possible? > One idea is to make your init-style program monitor that your daemon is running and if not, either restart it or reboot the board, whichever is applicable to your product. 1.3. There is a Watchdog in NuttX. Who feeds the watchdog? Is it > possible that there are two watchdogs: one for the OS and second for > the Application? In case of either system / application crash the > system should be rebooted by one of the watchdogs. Is this possible? > > 1.4. Is it possible to call the nsh as sub-process from within my > application so the application keeps feeding the watchdog? It is possible to start nsh from another program. It doesn't have to be the default application launched at boot. In fact, everything in the apps repo should be seen as examples and demonstration programs that you can use as-is, or use as a guide to building your own. So you need not actually have nsh at all, if it isn't appropriate in your product. 1.5. If the timing is important should I rather keep my application in > the foreground and abandon the idea of a daemon? If the daemon responds to some outside stimulus, you can give the daemon a high priority and have it wait on a semaphore for the event to occur. Perhaps interrupt logic would post the semaphore. (Be careful with priority inheritance and the recently changed semantics.) Hopefully others will be able to help with these: 2. Sim -> HW. > > 2.1.. I would like to develop my application first on the Simulator, > and then when its working at some point I would like to port is to the > real hardware. How my firmware could know what Arch is it currently > running on? > > 2.2. On Sim I would like to produce log messages, while on the real > Hardware driver actions should be performed. What would be the best > way to achieve that? Is is possible to determine hardware / arch at > runtime? Should I use #ifded CONFIG_BLAH macros to attach driver code > when real hardware is selected? > > 2.3. I can see that there is GPIO available in the SIM. How can I > interact with that gpio from my host OS? Is there sort of additional > application to perform such interaction with the simulator > application? > > > 3. Out of tree Application / Board / Drivers. > > 3.1. My current working setup is based on git. I would like to keep > all firmware code in my project's repository and external to the NuttX > + NuttX-Applications source tree. So that nuttx.git and nuttx-app.git > is provided as git submodule on the main project repo. Is this > possible? > > 3.2. I know that Application can be kept out-of-tree if linked to > nuttx-apps.git. Should I do the same with Boards and Drivers? > > 3.3. Is it possible to attach Application / Board / Driver code > out-of-tree with no linking? > > 3.4. Is it possible to provide full path and no non-relative path to > nuttx-apps in ./tools/configure.sh? > > > Thanks :-) > Tomek > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > Cheers Nathan
Re: SAMA5(D2) SPI speed is restricted by the driver
On Thu, Apr 27, 2023 at 11:27 AM Tim Hardisty wrote: > Just posted this same text on GitHub: > > https://github.com/apache/nuttx/issues/9127#issue-1687069010. > > Content copied here for those that don't go there. > > --- > > I have been investigating poor MTD performance with a GD25 memory on SPI0 > of a SAMA5D27 processor. > > Using LittleFS, dd was showing 37KB/s transfer speeds. I ruled out > LittleFS - SmartFS was even slower. > > The memory is set to run at 50MHz, but I was seeing only 10MHz, and long > delays between transfers. > > looking at arch/arm/src/sama5/sam_spc.c it seems the SPI interface is hard > coded to be deliberately slow: > > 1) SCBR (Serial Clock Bit Rate) forced to have a minimum value of 9, when > the datasheet says 1 should be the minimum > 2) DLYBS (Delay from NPCS going active to first valid clock) forced to be > 2us > 3) DLYBCT(Delay between 2 consecutive transfers) forced to be 5us > 4) SPI clock defaulting to using main clock (164MHz) whereas it could use > the Peripheral Clock (492MHz) which limits the resolution of the actual > frequency realisable > > Changing these to the fastest allowable values results in a huge > improvement in transfer speed - it's now 263KB/s. > > BUT...is there a good reason why these very big values have been chosen? > Should they not be configurable rather than hard coded, even? > I don't work with this architecture so take with a grain of salt, but my guess is that these settings were based on the board used at the time it was implemented. Perhaps whoever implemented it didn't need the additional logic to select interface speeds etc. I am aware there are other processors in the SAMA5 family (i.e. SAMA5D3 and > SAMA5D4) so input from anyone who knows those would be welcomed, along with > any general observations and suggestions on the best way to improve this? > > As an aside, DMA doesn't work for the SAMA5D2 SPI - it uses "XDMAC" not > "DMAC" so Kconfig settings get disabled and the driver never works out the > right DMA setup (which would be wrong for this device anyway!). > > I am very happy to work on the fix and a PR after some feedback. > > Cheers Nathan
ARMv7-m strcmp broken?
I posted this as a comment on GitHub [1] but writing this here in case
it isn't seen:
Has anyone tried to use the ARMv7-m optimized (assembly-coded) strcmp?
I cannot seem to build with CONFIG_ARMV7M_STRCMP:
```
$ tools/configure.sh tm4c129e-launchpad:nsh
(snip)
$ make menuconfig
```
Here I enable these options:
CONFIG_ARMV7M_MEMCHR=y
CONFIG_ARMV7M_MEMCPY=y
CONFIG_ARMV7M_MEMMOVE=y
CONFIG_ARMV7M_MEMSET=y
CONFIG_ARMV7M_STRCMP=y
CONFIG_ARMV7M_STRCPY=y
CONFIG_ARMV7M_STRLEN=y
```
$ make
Create version.h
LN: platform/board to /home/work/NuttX/apps/platform/dummy
Register: ping
Register: nsh
Register: sh
Register: telnetd
AS: machine/arm/armv7-m/gnu/arch_strcmp.S
machine/arm/armv7-m/gnu/arch_strcmp.S: Assembler messages:
machine/arm/armv7-m/gnu/arch_strcmp.S:51: Error: bad instruction `def_fn strcmp'
machine/arm/armv7-m/gnu/arch_strcmp.S:75: Error: bad instruction `s2lo
r12,r3,r12'
machine/arm/armv7-m/gnu/arch_strcmp.S:94: Error: bad instruction `s2hi
r0,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:95: Error: bad instruction `s2lo r2,r2,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:98: Error: shift expression
expected -- `cmpcs r0,r3,S2HI#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:99: Error: IT falling in the
range of a previous IT block -- `it eq'
machine/arm/armv7-m/gnu/arch_strcmp.S:100: Error: bad instruction
`s2loeq r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:247: Error: shift expression
expected -- `cmp r5,r3,S2LO#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:256: Error: shift expression
expected -- `cmp r5,r3,S2HI#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:261: Error: bad instruction
`s2lo r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:278: Error: bad instruction
`s2lo r5,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:285: Error: bad instruction
`s2lo r5,r2,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:292: Error: bad instruction
`s2hi r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:294: Error: bad instruction
`s2lo r5,r5,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:296: Error: shift expression
expected -- `cmp r5,r3,S2LO#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:303: Error: shift expression
expected -- `cmp r5,r3,S2HI#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:321: Error: bad instruction
`s2lo r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:328: Error: bad instruction
`s2hi r3,r3,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:329: Error: bad instruction
`s2lo r5,r2,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:331: Error: bad instruction
`s2lo r3,r3,#16'
machine/arm/armv7-m/gnu/arch_strcmp.S:338: Error: shift expression
expected -- `cmp r5,r3,S2LO#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:347: Error: shift expression
expected -- `cmp r5,r3,S2HI#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:352: Error: bad instruction
`s2lo r3,r3,#24'
machine/arm/armv7-m/gnu/arch_strcmp.S:361: Error: bad instruction
`s2lo r5,r2,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:380: Error: bad instruction
`s2loeq r5,r5,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:381: Error: bad instruction
`s2loeq r3,r3,#8'
machine/arm/armv7-m/gnu/arch_strcmp.S:382: Error: branch must be last
instruction in IT block -- `beq .Lstrcmp_tail'
machine/arm/armv7-m/gnu/arch_strcmp.S:383: Error: instruction not
allowed in IT block -- `sub r0,r2,r0'
machine/arm/armv7-m/gnu/arch_strcmp.S:73: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:246: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:286: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:337: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:357: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:362: Error: undefined symbol MSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:374: Error: undefined symbol LSB
used as an immediate value
machine/arm/armv7-m/gnu/arch_strcmp.S:375: Error: undefined symbol LSB
used as an immediate value
{standard input}: Error: .size expression for strcmp does not evaluate
to a constant
make[1]: *** [Makefile:143: bin/arch_strcmp.o] Error 1
make: *** [tools/LibTargets.mk:180: libs/libc/libc.a] Error 2
```
I noticed that some of the other files have something like this:
```
.macro def_fn f p2align=0
.text
.p2align \p2align
.global \f
.type \f, %function
\f:
.endm
```
However I do not understand the assembly sources so I don't know
what will happen if I copy-and-paste that.
Interestingly, I found the newlib code and it also doesn't have the
macro def_fn. See [2].
[1] https://github.com/apache/nuttx/pull/8042#issuecomment-1527653447
[2]
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=newlib/libc/machine/arm/strcmp-armv7.S;h=7cafca151b162210c2af4a512a14255a2aecc4cd;hb=HEAD
Cheers,
Nathan
Re: FAQ :-)
> 1. Daemon / Service: > > 1.1. I would like to have application running as daemon in the > background all the time. Is this possible? NuttX supports the daemon() API. https://man7.org/linux/man-pages/man3/daemon.3.html Lots of examples to look at: $ grep -ri daemon apps | wc -l 2384 Most do not call daemon() but do the same thing inline. Using daemon() would be better: $ grep -r "daemon[(]" apps | wc -l 46 > 1.2. On application error / crash I would like the application to > restart so it is always available. Is this possible? If properly configured, the parent task can receive the Death-of-Child signal, SIGCHLD when a task dies. But not a "true" Linux deamon which would re-parent itself to the init process. daemon() does not re-parent today, but should. You could probably use on_exit() or atexit() to have a task restart itself too. I a more costly design, you could have another thread monitor the daemon with waitpid() to see it it executes. You can also check of the daemon is still running by using kill() with signal zero. > 1.3. There is a Watchdog in NuttX. Who feeds the watchdog? Is it > possible that there are two watchdogs: one for the OS and second for > the Application? In case of either system / application crash the > system should be rebooted by one of the watchdogs. Is this possible? These are your design decisions. > 1.4. Is it possible to call the nsh as sub-process from within my > application so the application keeps feeding the watchdog? NuttX supports the system() interface to run NSH commands: https://man7.org/linux/man-pages/man3/system.3.html > 1.5. If the timing is important should I rather keep my application in > the foreground and abandon the idea of a daemon? Daemonizing has no effect on the priority or timing of the daemon > 2. Sim -> HW. > > 2.1.. I would like to develop my application first on the Simulator, > and then when its working at some point I would like to port is to the > real hardware. How my firmware could know what Arch is it currently > running on? NSH supports the uname command: https://man7.org/linux/man-pages/man1/uname.1.html > 2.2. On Sim I would like to produce log messages, while on the real > Hardware driver actions should be performed. What would be the best > way to achieve that? Is is possible to determine hardware / arch at > runtime? Should I use #ifded CONFIG_BLAH macros to attach driver code > when real hardware is selected? Using uname or configuration options sound good to me. The existing CONFIG_ARCH_SIM that is set when you compile the system should be enough. > 2.3. I can see that there is GPIO available in the SIM. How can I > interact with that gpio from my host OS? Is there sort of additional > application to perform such interaction with the simulator > application? > > > 3. Out of tree Application / Board / Drivers. > > 3.1. My current working setup is based on git. I would like to keep > all firmware code in my project's repository and external to the NuttX > + NuttX-Applications source tree. So that nuttx.git and nuttx-app.git > is provided as git submodule on the main project repo. Is this > possible? Yes. See CONFIG_ARCH_BOARD_CUSTOM CONFIG_ARCH_BOARD_CUSTOM_NAME CONFIG_ARCH_BOARD_CUSTOM_DIR CONFIG_ARCH_BOARD_CUSTOM_DIR_RELPATH CONFIG_BOARD_CUSTOM_LEDS CONFIG_BOARD_CUSTOM_BUTTONS CONFIG_BOARD_CUSTOM_IRQBUTTONS CONFIG_BOARD_CUSTOM_INTERRUPT > 3.2. I know that Application can be kept out-of-tree if linked to > nuttx-apps.git. Should I do the same with Boards and Drivers? No, use the custom board configuration settings. > 3.3. Is it possible to attach Application / Board / Driver code > out-of-tree with no linking? What do you mean no linking? Do you mean that it is not linked into the code on the FLASH? Or do you meaning symbolic linking of files? If so, use the custom board configuration. > 3.4. Is it possible to provide full path and no non-relative path to > nuttx-apps in ./tools/configure.sh? Yes, I believe so.
Re: SAMA5(D2) SPI speed is restricted by the driver
On Thu, Apr 27, 2023 at 5:27 PM Tim Hardisty wrote: > (..) > I have been investigating poor MTD performance with a GD25 memory on SPI0 of > a SAMA5D27 processor. > (..) > I am very happy to work on the fix and a PR after some feedback. I do not have this board / mcu to help testnig, but I guess better efficiency and new features are highly welcome :-) Tim if that helps I can buy selected board for testing, I do not have time to help with development though, sorry. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
RE: SAMA5(D2) SPI speed is restricted by the driver
>From: Tomek CEDRO >Sent: Friday, April 28, 2023 5:15 PM > >On Thu, Apr 27, 2023 at 5:27 PM Tim Hardisty wrote: >> (..) >> I have been investigating poor MTD performance with a GD25 memory on >SPI0 of a SAMA5D27 processor. >> (..) >> I am very happy to work on the fix and a PR after some feedback. > >I do not have this board / mcu to help testnig, but I guess better >efficiency and new features are highly welcome :-) > >Tim if that helps I can buy selected board for testing, I do not have >time to help with development though, sorry. > >-- I have my custom board and an SAMA5D2 explained eval board so should be OK, thanks. I just want to make sure there's no "good" reason for this before messing it all up! Thanks for taking the time to reply :)
RE: SAMA5 secure fuse controller driver
I am trying to make use of the template/skeleton in include/nuttx/efuse.h
It defines:
struct efuse_param
{
FAR const efuse_desc_t **field;
size_t size;
FAR uint8_t *data;
};
With the explanation:
/* The efuse_param is used by the application to inform which field(s)
* will be passed to the ioctl() operation.
* - 'efuse_desc_t *field[]': contains one or more field and it
* it terminated by a NULL to indicate there is no more fields.
* NOTE: normally the application don't need to create these fields
* they are mapped inside an arch efuse table and referenced
* in a header file inside include/nuttx/efuse/ directory.
* - size: how many bits the field(s) use
* - data: an application side allocated buffer where the read operation
* will store the efuse bits, so the number of allocated bytes
* need to be enough to store all bits. For write operation, this
* pointer contains the bits to be written.
*/
There are no implementations that use this. Perhaps it's because it's the end
of a long week, but I can't get my head around what I'm supposed to do with
this.
Can some kind person explain how it is to be used, please?
Perhaps use the example of the SAMA5D2 that has 32 bit fuses (SFC_DR0 through
SFC_DR23)? What should the "arch efuse table" look like, where would it be, and
how is it to be referenced in a (new) header file?
Also, data is a uint8_t, but this arch has 32 bit "fields". Should I just stick
with 8 bit "fields" and have 4 times as many? Or have I missed the point of
"fields"?
Thank you!
>-Original Message-
>From: Tim Hardisty
>Sent: Tuesday, April 25, 2023 7:33 PM
>To: dev@nuttx.apache.org
>Subject: SAMA5 secure fuse controller driver
>
>The SAMA5 support has no driver for the secure fuse peripheral. Kconfig
>allows you to “enable” it but there’s no underlying code.
>
>Before I go ahead and create a character driver for this, is the omission
>for a “good” reason?
>
>The driver would handle the relatively straightforward management of
>programming the fuses, as well as obviously allowing you to read values.
>If another arch has anything similar please point me in its direction so
>I can create one that’s similar.
>
>Thanks,
>
>TimJTi.
Re: SAMA5 secure fuse controller driver
struct efuse_param Also .. does not follow the naming standard for structures. The coding standard requires that all structure names end with _s so, if this is needed, it must be efuse_param_s If it is not needed, then it should be removed.
