Re: BL616/618 Support

2023-04-27 Thread 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

BL616/618 Support

2023-04-27 Thread Yebin Lee
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

FAQ :-)

2023-04-27 Thread Tomek CEDRO
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 applica

SAMA5(D2) SPI speed is restricted by the driver

2023-04-27 Thread Tim Hardisty
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

Re: asprintf failure

2023-04-27 Thread Fotis Panagiotopoulos
Indeed your suggestion is valid. I created the following issues: https://github.com/apache/nuttx/issues/9126 https://github.com/apache/nuttx-apps/issues/1727 On Thu, Apr 27, 2023 at 5:06 AM Nathan Hartman wrote: > On Wed, Apr 26, 2023 at 9:32 AM Fotis Panagiotopoulos > wrote: > > > > Hello, >

Re: Usage of mutex_t inside libc

2023-04-27 Thread Gregory Nutt
On 4/27/2023 3:50 AM, Ville Juven wrote: Hi, I agree totally that the contents of the stack allocated wait object (whatever) do not need validation, and the user of course cannot access / destroy the contents. What I did not understand before inspecting the Linux kernel code, is how the wai

Re: Usage of mutex_t inside libc

2023-04-27 Thread Gregory Nutt
I think Xiang refers to how Linux does it. It simply creates a new "waitobj" variable into the kernel stack by declaring it inside the sem_wait()-equivalent function. The wait object is created into the kernel stack, ... Yep, I was not thinking of allocating as a local variable.  So I had a

Re: Usage of mutex_t inside libc

2023-04-27 Thread Ville Juven
Hi, I agree totally that the contents of the stack allocated wait object (whatever) do not need validation, and the user of course cannot access / destroy the contents. What I did not understand before inspecting the Linux kernel code, is how the wait list integrity is ensured when the stack

Re: Usage of mutex_t inside libc

2023-04-27 Thread Xiang Xiao
Yes, this is what I said before. You don't need to validate the stack allocated list since it comes from the kernel stack which can't be modified or even read by the userspace code. On Thu, Apr 27, 2023 at 3:43 PM Ville Juven wrote: > Hi, > > I think Xiang refers to how Linux does it. It simply

Re: Usage of mutex_t inside libc

2023-04-27 Thread Ville Juven
Hi, I think Xiang refers to how Linux does it. It simply creates a new "waitobj" variable into the kernel stack by declaring it inside the sem_wait()-equivalent function. The wait object is created into the kernel stack, and a hash is calculated for the user semaphore address. The hash is use