Re: Vote for rename modlib to libelf

2025-04-10 Thread Takashi Yamamoto
modlib -> libelf is to complete prior > changes chain, as explained by the author. > > If you like the change please vote +1 and it will pass. Your -1 blocks > the change. i'm not a "NuttX PMC" member and thus my vote is not a "binding vote" and do not block the c

Re: Vote for rename modlib to libelf

2025-04-09 Thread Takashi Yamamoto
and 1.13 a few times. but i don't see what's i'm missing. do people here think this change is "absolutely necessary and unavoidable"? > > BRs, > > Takashi Yamamoto 于2025年4月9日周三 06:56写道: > >> -1 >> >> reading the recently added text in CONTR

Re: Vote for rename modlib to libelf

2025-04-09 Thread Takashi Yamamoto
ast binding votes" in CONTRIBUTING.md section 1.12 made me think otherwise. anyway, the code change itself is fine for me. if everyone here is happy with the interaction with the CONTRIBTING.md text, (it seems so) i withdraw my -1 vote. > BRs, > > Takashi Yamamoto 于2025年4月10日周四 10:37写

Re: Vote for rename modlib to libelf

2025-04-08 Thread Takashi Yamamoto
anding the text in CONTRIBUTING.md? > > Rationale behind this change modlib -> libelf is to complete prior > changes chain, as explained by the author. > > If you like the change please vote +1 and it will pass. Your -1 blocks > the change. > > Thanks :-) >

Re: Vote for rename modlib to libelf

2025-04-08 Thread Takashi Yamamoto
-1 reading the recently added text in CONTRIBUTING.md, this change doesn't seem even eligible for voting because it is not "absolutely necessary and unavoidable". i personally like the change itself and prefer loosening the rules in CONTRIBUTING.md though. On Mon, Apr 7, 2025 at 6:13 PM chao an

Re: Can NSEC_PER_USEC in clock.h be changed to 1000L?

2025-04-01 Thread Takashi Yamamoto
> After some debugging I found out that up_alarm_tick_cancel in > sched/sched/sched_timerexpiration.c reads an incorrect ticks value from > clock_time2ticks macro. It received 0 seconds, 0x77358ns as a parameter, > which - rounded up - should yield 1 tick with USEC_PER_TICK set to 1000. > Instead,

Re: [VOTE] NuttX Contributing Guidelines update 202502.

2025-02-11 Thread Takashi Yamamoto
On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote: > > Hello world :-) > > As discussed extensively in various mailing list threads we have > gathered all additional ideas for Contributing Guidelines update that > should improve NuttX Code Quality and self-compatibility / long term > maintenance.

Re: Change time_t to signed type

2024-11-07 Thread Takashi Yamamoto
On Fri, Nov 8, 2024 at 3:42 AM Gregory Nutt wrote: > > > On 11/7/2024 12:34 PM, Tomek CEDRO wrote: > > Still it will be possible to set _by_hand_ other values (i.e. int32_t > > or uint32_t) via kconfig when necessary for older / smaller platforms. > > But not POSIX 2024 compliant. We have forbid

Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
On Wed, Nov 6, 2024 at 12:31 PM Gregory Nutt wrote: > > > On 11/5/2024 9:18 PM, Takashi Yamamoto wrote: > > does that GCC have int64_t? > Yes, according to include/nuttx/compiler.h. > > > >> zNEO (z16) and z8 are no long supportable without ZDS-II. Other z80s

Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
On Wed, Nov 6, 2024 at 11:47 AM Gregory Nutt wrote: > > > On 11/5/2024 8:35 PM, Byron Ellacott wrote: > > Hi Takashi, > > > >> ideally, we should use int64_t for all targets unconditionally, IMO. > >> however, in practice, 64-bit integers don't seem available for some of > >> our targets. (ez80, z

Re: Change time_t to signed type

2024-11-05 Thread Takashi Yamamoto
> I don't think, personally, that any of this is reason enough to worry about > it. Using an int64_t for time_t is IMO a perfectly reasonable default for > 32-bit and up targets. and possibly for all targets. Offering a kconfig > option to support 32-bit (signed or unsigned) time_t offers an easy >

Re: POSIX environ variable

2024-11-05 Thread Takashi Yamamoto
i guess it's possible to implement it similarly to what we do for errno. eg. # define environ (*get_environ_ptr_ptr()) although it still isn't quite posix compatible, it might be good enough for many applications. whatever approach we take, it probably requires some extra validations in the ker

Re: Change time_t to signed type

2024-11-04 Thread Takashi Yamamoto
On Mon, Nov 4, 2024 at 10:33 PM Guiding Li wrote: > > Hi all: > > We decide change 'time_t' from unsigned type to signed type in PR: > https://github.com/apache/nuttx/pull/14460 > > Because when compile some POSIX library, there always be a warning on > comparison > between time_t and zero. > > Fo

events.nuttx.apache.org

2024-06-12 Thread Takashi Yamamoto
- the email address works...@nuttx.org mentioned on https://events.nuttx.apache.org/ seems dead. - i wonder if the online attendance registration on the page is working. i think i registered myself a few days ago. but i have not noticed "event notifications and links for the event" in my inbox.

Re: stack issue when using littlefs (was Re: littlefs broken)

2024-04-01 Thread Takashi Yamamoto
On Tue, Mar 19, 2024 at 8:01 PM Sebastien Lorquet wrote: > > Damn, that was a stack issue, but not in littlefs itself. or is it? idk. > > > This is a useful "bug" to know: Littlefs uses A LOT of stack. > > The issue was nsh. it is configured with a 2048 bytes stack by default, > and increasing it

Re: bl808 status?

2023-03-08 Thread Takashi Yamamoto
ocumented and fairly > challenging. You can find my notes here as well. > > https://btashton.github.io/bl808-notes/ > > If you would like to collaborate on this that would be awesome! > > --Brennan > > On Wed, Mar 8, 2023, 8:48 AM Takashi Yamamoto > wrote: > >

bl808 status?

2023-03-08 Thread Takashi Yamamoto
hi, i recently received a few small boxes labelled "Sipeed M1S Dock" and i'm interested in nuttx support of the board. google suggested me Brennan's wip tree. https://github.com/btashton/incubator-nuttx/tree/bl808/bringup Brennan, is it the latest? or do you have any unpushed changes?

recent WASM build stuff

2023-03-08 Thread Takashi Yamamoto
hi, let me repeat my concerns about the recent addition of WASM module build support here as i think it warrants a ML discussion. https://github.com/apache/nuttx-apps/pull/1609#issuecomment-1460411089 honestly speaking, i feel the feature is halfly-baked at best. maybe it's a misfeature. * i fee

Re: [VOTE] Apache NuttX 12.0.0 RC0 release

2022-12-25 Thread Takashi Yamamoto
i guess we need to make a decision about time_t signedness. references: https://github.com/apache/nuttx/pull/4693 https://github.com/apache/nuttx/pull/7115 https://github.com/apache/nuttx/pull/7975 On Mon, Dec 19, 2022 at 4:22 PM Alin Jerpelea wrote: > > Hello all, > Apache NuttX 12.0.0 RC0 has

Re: is CODE keyword still used?

2022-01-26 Thread Takashi Yamamoto
On Thu, Jan 27, 2022 at 1:57 AM Alan Carvalho de Assis wrote: > > Sorry Petro, I missed that files! > > Maybe Greg could explain why it is missing or if it is not necessary. i'm interested in the answer to this. > > Should be nice if we could find a wait to instruct the compiler (or > the buildi

Re: is CODE keyword still used?

2022-01-26 Thread Takashi Yamamoto
i guess that a problem is the semantics of CODE/FAR/NEAR is not very well documented. On Thu, Jan 27, 2022 at 5:21 AM Gregory Nutt wrote: > > > > >> Should be nice if we could find a wait to instruct the compiler (or > >> the building system) to include the typedefed CODE to the pointer > >> func

Re: NET_TCP_SPLIT removal

2021-10-14 Thread Takashi Yamamoto
hi, > I am not 100% sure of this, but I still think that it would be better to > remove the unbuffered TCP send logic rather than remove the packet split > logic. personally i have no objection against the removal of unbuffered send. but i can understand if someone objects it. for some situation

NET_TCP_SPLIT removal

2021-10-12 Thread Takashi Yamamoto
hi, i submitted a PR to remove NET_TCP_SPLIT. https://github.com/apache/incubator-nuttx/pull/4660 i'm posting this here because a feature removal should be reviewed by wider audience. especially, if you are relying on it, please speak up.

Re: FreeBSD / BSD

2021-10-07 Thread Takashi Yamamoto
On Fri, Oct 8, 2021 at 2:25 PM Tomasz CEDRO wrote: > > On Fri, Oct 8, 2021 at 6:45 AM Takashi Yamamoto wrote: > > > > On Fri, Oct 8, 2021 at 12:51 PM Tomasz CEDRO wrote: > > > > > > On Fri, Oct 8, 2021 at 5:15 AM Tomasz CEDRO wrote: > > > > On F

Re: FreeBSD / BSD

2021-10-07 Thread Takashi Yamamoto
On Fri, Oct 8, 2021 at 12:51 PM Tomasz CEDRO wrote: > > On Fri, Oct 8, 2021 at 5:15 AM Tomasz CEDRO wrote: > > On Fri, Oct 8, 2021 at 4:47 AM Nathan Hartman wrote: > > > There is a NuttX Tools repo at > > > https://bitbucket.org/nuttx/tools/downloads/ > > > > > > I think I built the kconfig-front

Re: ESP32-C3 RISC-V

2021-10-07 Thread Takashi Yamamoto
> I can see some "bashisms" in the shell scripts, did you consider using > raw /bin/sh or is it too much work and `bash` is the best way already? > I am asking because on Linux `/bin/sh` is `/bin/bash` while on BSD > `/bin/sh` is /bin/sh` while `bash` is the optional package :-) i consider using b

Re: Support for disk full detection using LittleFS

2021-05-30 Thread Takashi Yamamoto
On Fri, May 28, 2021 at 9:21 PM Flavio Castro Alves Filho wrote: > > Hello, > > I am using LittleFS to store information on an external dataflash. > > I need to know if the memory is full. I saw that the nsh provides the > df command, which as far as I understood is a cat for /proc/fs/usage > file

Re: spiffs (in)compatilibity

2020-12-21 Thread Takashi Yamamoto
On Tue, Dec 22, 2020 at 8:08 AM Gregory Nutt wrote: > > > >> The version in NuttX is based off an older version of SPIFFS (before all > >> of the security related changes) and may have incompatibilities with the > >> current SPIFFS. > > do you remember which exact version of SPIFFS it was? > You w

Re: spiffs (in)compatilibity

2020-12-21 Thread Takashi Yamamoto
> > On 12/20/2020 11:26 PM, Takashi Yamamoto wrote: > > hi, > > > > a question: is the nuttx implementation of spiffs diverted intentionally > > from > > other implementations? or is it just a bug? > > > > background: > > i needed the followi

spiffs (in)compatilibity

2020-12-20 Thread Takashi Yamamoto
hi, a question: is the nuttx implementation of spiffs diverted intentionally from other implementations? or is it just a bug? background: i needed the following changes to use spiffs images from mkspiffs and spiffsgen.py. https://github.com/apache/incubator-nuttx/pull/2572

Re: official nuttx-ci-linux image

2020-08-06 Thread Takashi Yamamoto
On Fri, Aug 7, 2020 at 9:38 AM Brennan Ashton wrote: > > On Thu, Aug 6, 2020, 4:35 PM Takashi Yamamoto > wrote: > > > On Thu, Aug 6, 2020 at 11:57 PM Brennan Ashton > > wrote: > > > > > > On Thu, Aug 6, 2020, 4:03 AM Takashi Yamamoto > > &g

Re: official nuttx-ci-linux image

2020-08-06 Thread Takashi Yamamoto
On Thu, Aug 6, 2020 at 11:57 PM Brennan Ashton wrote: > > On Thu, Aug 6, 2020, 4:03 AM Takashi Yamamoto > wrote: > > > hi, > > > > the docker image used by the CI (nuttx-ci-linux) is useful for other > > purposes. > > but as far as i know, it isn&#

official nuttx-ci-linux image

2020-08-06 Thread Takashi Yamamoto
hi, the docker image used by the CI (nuttx-ci-linux) is useful for other purposes. but as far as i know, it isn't pullable publicly. right now, i'm building and pushing it to docker hub for my own consumption. https://hub.docker.com/repository/docker/yamt/nuttx-ci-linux i think it's worth to prov

Re: api stability in apps/netutils/webclient

2020-07-30 Thread Takashi Yamamoto
x27;t. (sorry!) > > BR, > > Alan > > On 5/29/20, Takashi Yamamoto wrote: > > hi, > > > > On Fri, May 29, 2020 at 11:53 PM Sebastien Lorquet > > wrote: > >> > >> I think the web client could be rewritten to benefit from the curl port > >&g

Re: api stability in apps/netutils/webclient

2020-07-30 Thread Takashi Yamamoto
On Fri, May 29, 2020 at 3:23 PM Takashi Yamamoto wrote: > > hi, > > On Fri, May 29, 2020 at 7:00 AM Gregory Nutt wrote: > > > > > > > i want to add some stuff to apps/netutils/webclient. > > > for example, > > > > > > * ability to

ftw/fts

2020-06-22 Thread Takashi Yamamoto
hi, does anyone know ftw/nftw, fts, or similar libraries for nuttx? https://pubs.opengroup.org/onlinepubs/9699919799/functions/nftw.html https://netbsd.gw.com/cgi-bin/man-cgi?fts++NetBSD-current

dirname_r?

2020-06-04 Thread Takashi Yamamoto
hi, i'm using FLAT memory model. i want to use dirname() in my app. but there seems to be no safe way to use static-buffer returning functions like this unless you have very tight control on what you run on your system. am i correct? i think it makes sense for nuttx to provide non-standard reentra

Re: api stability in apps/netutils/webclient

2020-05-29 Thread Takashi Yamamoto
"easy" api was not that attractive. i hope it were "multi" api. * it looked like an abandoned project. (i guess i was wrong on this point as apparently you still care.) btw, is it a curl port? i thought it was an independent project with a similar api. > > Sebastien &

Re: api stability in apps/netutils/webclient

2020-05-28 Thread Takashi Yamamoto
hi, On Fri, May 29, 2020 at 7:00 AM Gregory Nutt wrote: > > > > i want to add some stuff to apps/netutils/webclient. > > for example, > > > > * ability to report http status to the caller > > * ability to add some request headers > > * put > > * other content-type for post > > * tls > > > > a que

api stability in apps/netutils/webclient

2020-05-28 Thread Takashi Yamamoto
hi, i want to add some stuff to apps/netutils/webclient. for example, * ability to report http status to the caller * ability to add some request headers * put * other content-type for post * tls a question: how much api stability is expected for this? can i just add extra arguments to wget() et

Re: FAR for pointer to pointer

2020-05-26 Thread Takashi Yamamoto
On Tue, May 26, 2020 at 8:05 PM Alan Carvalho de Assis wrote: > > man strtoul my question was about FAR. strtoul is just an example. > > On 5/25/20, Takashi Yamamoto wrote: > > hi, > > > > our strtoul prototype is: > > > > unsigned long strtoul(FA

FAR for pointer to pointer

2020-05-25 Thread Takashi Yamamoto
hi, our strtoul prototype is: unsigned long strtoul(FAR const char *nptr, FAR char **endptr, int base); why shouldn't they be like, say, "FAR char * FAR * endptr"?

Re: kconfig (Re: mbedtls)

2020-05-25 Thread Takashi Yamamoto
ifferent opinions. > Original message ----From: Takashi Yamamoto > Date: 5/25/20 6:41 PM (GMT-06:00) To: > dev@nuttx.apache.org Subject: Re: kconfig (Re: mbedtls) On Tue, May 26, 2020 > at 12:48 AM Gregory Nutt wrote:>> We should all be > using a consistent, common vers

Re: kconfig (Re: mbedtls)

2020-05-25 Thread Takashi Yamamoto
On Tue, May 26, 2020 at 10:11 AM Nathan Hartman wrote: > > On Mon, May 25, 2020 at 8:41 PM Takashi Yamamoto > wrote: > > > On Tue, May 26, 2020 at 12:48 AM Gregory Nutt wrote: > > > > > > We should all be using a consistent, common version of > > >

Re: kconfig (Re: mbedtls)

2020-05-25 Thread Takashi Yamamoto
itely easier to deal with than the current state of kconfig-frontends. > > Greg > > On 5/25/2020 9:38 AM, Nathan Hartman wrote: > > On Mon, May 25, 2020 at 12:36 AM Takashi Yamamoto > > wrote: > >> On Mon, May 25, 2020 at 1:00 AM Nathan Hartman > >> wrote

Re: mbedtls

2020-05-24 Thread Takashi Yamamoto
On Mon, May 25, 2020 at 3:41 PM Xiang Xiao wrote: > > > > > -Original Message- > > From: Nathan Hartman > > Sent: Monday, May 25, 2020 12:00 AM > > To: dev@nuttx.apache.org > > Subject: Re: mbedtls > > > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > > wrote: > > > Some mont

kconfig (Re: mbedtls)

2020-05-24 Thread Takashi Yamamoto
On Mon, May 25, 2020 at 1:00 AM Nathan Hartman wrote: > > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis > wrote: > > Some months ago I suggested that NuttX could focus only in the kernel > > and we could create an external distribution using some build system > > like buildroot, yocto, e

Re: mbedtls

2020-05-22 Thread Takashi Yamamoto
On Fri, May 22, 2020 at 10:14 PM Xiang Xiao wrote: > > On Fri, May 22, 2020 at 8:41 PM Alan Carvalho de Assis > wrote: > > > > Hi Xiang, > > > > On 5/22/20, Xiang Xiao wrote: > > sic > > > > > > But mbedtls can be used in more context than HTTPS/TLS like security > > > boot, OTA and TEE, it does

Re: mbedtls

2020-05-22 Thread Takashi Yamamoto
On Fri, May 22, 2020 at 7:26 PM Sebastien Lorquet wrote: > > Hello > > Le 22/05/2020 à 10:05, Takashi Yamamoto a écrit : > > can you explain what's "real nuttx code"? > > For me, code specifically written for NuttX with good integration and > perform

Re: mbedtls

2020-05-22 Thread Takashi Yamamoto
t; > Sebastien > > Le 22/05/2020 à 09:41, Takashi Yamamoto a écrit : > > hi, > > > > i'm working on mbedtls Makefile/Kconfig glue for NuttX. > > right now, it downloads and uses the mbedtls source code from > > the upstream as it is. (similarly to what netuti

mbedtls

2020-05-22 Thread Takashi Yamamoto
hi, i'm working on mbedtls Makefile/Kconfig glue for NuttX. right now, it downloads and uses the mbedtls source code from the upstream as it is. (similarly to what netutils/cjson does) questions: 1. if we decide to contribute it, is there a chance to be accepted by NuttX? 2. if yes, which reposi

intel64

2020-05-17 Thread Takashi Yamamoto
hi, this is just a curious question. why do we use the name "intel64" for qemu things? i thought it was from qemu, but qemu seems to use x86_64 or amd64. i think "amd64" is more commonly used as it's from amd. do we want to help intel marketing for some reasons?

CONFIG_SMP_IDLETHREAD_STACKSIZE vs CONFIG_IDLETHREAD_STACKSIZE

2020-03-30 Thread Takashi Yamamoto
hi, these configs have the following default values: CONFIG_SMP_IDLETHREAD_STACKSIZE=2048 CONFIG_IDLETHREAD_STACKSIZE=1024 is there any rationale of these values? the kconfig help text seems to suggest the opposite; the SMP one should be smaller.

broken CI

2020-03-22 Thread Takashi Yamamoto
hi, is anyone already looking at these failures? https://github.com/apache/incubator-nuttx/pull/607/checks?check_run_id=526302981 Configuration/Tool: pcduino-a10/nsh,CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL ---

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

2020-03-19 Thread Takashi Yamamoto
On Thu, Mar 19, 2020 at 10:12 PM Gregory Nutt wrote: > > > > depending on CONFIG_CAN_PASS_STRUCTS, > > mallinfo has a different prototype. > > > > #ifdef CONFIG_CAN_PASS_STRUCTS > > struct mallinfo mallinfo(void); > > #else > > int mallinfo(FAR struct mallinfo *info); > > #endif > > > > and w

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

2020-03-19 Thread Takashi Yamamoto
On Thu, Mar 19, 2020 at 7:59 PM Xiang Xiao wrote: > > On Thu, Mar 19, 2020 at 6:39 PM Takashi Yamamoto > wrote: > > > > do you feel the returning-structure version less uglier? > > Yes, returning-structure is a bad design in most case, but we can't > change mal

Re: mallinfo and CONFIG_CAN_PASS_STRUCTS

2020-03-19 Thread Takashi Yamamoto
CTS option and clean up the whole code > base. > > On Thu, Mar 19, 2020 at 2:41 PM Takashi Yamamoto > wrote: > > > > hi, > > > > depending on CONFIG_CAN_PASS_STRUCTS, > > mallinfo has a different prototype. > > > > #ifdef CONFIG_CAN_PASS_STRUCTS

mallinfo and CONFIG_CAN_PASS_STRUCTS

2020-03-18 Thread Takashi Yamamoto
hi, depending on CONFIG_CAN_PASS_STRUCTS, mallinfo has a different prototype. #ifdef CONFIG_CAN_PASS_STRUCTS struct mallinfo mallinfo(void); #else int mallinfo(FAR struct mallinfo *info); #endif and we have a lot of #ifdef CONFIG_CAN_PASS_STRUCTS for this even in APPDIR. i'd like to suggest

Re: Should we relax precheck a little bit?

2020-03-10 Thread Takashi Yamamoto
we basically prevent changes on files unless you can fix all nxstyle issues in them. i don't think it's a good idea. i believe that there can be changes more important than style fixes. in addition to -r option you suggested, i'd suggest to make precheck separate from other (IMO more important) ch

Re: Should we relax precheck a little bit?

2020-03-10 Thread Takashi Yamamoto
On Tue, Mar 10, 2020 at 3:43 PM Xiang Xiao wrote: > > On Tue, Mar 10, 2020 at 1:17 AM Gregory Nutt wrote: > > > > > > > - Fixing the entire file we touch helps makes things better overall > > > even > > > though its painful in the short run. > > > - Having a tool that produces accura

Re: Re: Should we relax precheck a little bit?

2020-03-10 Thread Takashi Yamamoto
On Mon, Mar 9, 2020 at 6:09 AM Peter Van Der Perk wrote: > > Hi Adam, > > I've been trying to make a clang-format for NuttX however I did run in some > nasty bugs with clang-format. > Mostly the inconsistent spacing caused by preprocessor directives (#ifdef) > etc. > I've filed a bug on the LLVM

Re: Should we relax precheck a little bit?

2020-03-09 Thread Takashi Yamamoto
On Sun, Mar 8, 2020 at 9:30 AM Gregory Nutt wrote: > > > > Since there's no current maintainer for nxstyle... What would people think > > about trying Clang-Format ? > > > > It's a well-used tool (LLVM, Google, Chromium, Mozilla, Webkit, and > > Microso

dlopen for I/D separated platform

2020-03-05 Thread Takashi Yamamoto
hi, i want to make dlopen work on esp32. [1] right now, nuttx just does malloc to allocate memory to load text. however, it can't work on esp32, where instruction and data are separated. i guess it would be the most straightforward to introduce another "heap" instance for text. (according to esp32

squashing commits or not

2020-03-04 Thread Takashi Yamamoto
hi, it seems that in nuttx it's common to squash commits when merging pull requests. i'd like to suggest _not_ to do that because: * it makes cherry-pick/backport/revert cumbersome * larger changes are more difficult to read/understand on the other hand, i can think of only little benefit. * aes

Re: how to build userspace for CONFIG_BUILD_KERNEL

2020-02-25 Thread Takashi Yamamoto
; block. it should not affect KERNEL build, should it? > 2.LDLIBS should contain libproxy.a to resolve sched_*, and libc.a for > fprintf, but these library should in LDLIBS automatically. > > Thanks > Xiang > > On Wed, Feb 26, 2020 at 11:23 AM Takashi Yamamoto > wrote: >

how to build userspace for CONFIG_BUILD_KERNEL

2020-02-25 Thread Takashi Yamamoto
hi, how can i build userspace for CONFIG_BUILD_KERNEL? using sama5d4-ek:knsh config, i tried "make TOPDIR=$(pwd) APPDIR=$(pwd)/../apps -C ../apps install". it generated some binaries like the following. but i don't see how it will get nsh_consolemain etc. spacetanuki% nm ../apps/bin/init 00c

Re: Build is broken

2020-02-24 Thread Takashi Yamamoto
may i assume you are using linux? here's a fix i tested on ubuntu. https://github.com/apache/incubator-nuttx-apps/pull/95/commits/adb08a2634ef8df99d509a472e28a7907f73210d On Sat, Feb 22, 2020 at 1:21 AM David Sidrane wrote: > > This is what I did: > > For apps and nuttx git fetch nuttx > For app

Re: userspace/kernel isolation question

2020-02-24 Thread Takashi Yamamoto
On Fri, Feb 21, 2020 at 10:29 PM Gregory Nutt wrote: > > > > while looking at PROTECTED build, > > i noticed that it was trivial for userspace code to bypass the > > protection and access kernel memory. > > eg. by passing kernel pointer to system calls. > > and it seems that it isn't the only way

Re: Build is broken

2020-02-21 Thread Takashi Yamamoto
changes in the meantime. sorry for the inconvenience. On Sat, Feb 22, 2020 at 12:25 AM Takashi Yamamoto wrote: > > it's likely because of > https://github.com/apache/incubator-nuttx-apps/commit/5cb020c70f14b2ff766c96da87c3c4bfd32c > i suspect APPOBJS variable contains some g

Re: Build is broken

2020-02-21 Thread Takashi Yamamoto
it's likely because of https://github.com/apache/incubator-nuttx-apps/commit/5cb020c70f14b2ff766c96da87c3c4bfd32c i suspect APPOBJS variable contains some garbage output from make itself. like "make[2]: Leaving directory" On Sat, Feb 22, 2020 at 12:13 AM David Sidrane wrote: > > Build is bro

userspace/kernel isolation question

2020-02-20 Thread Takashi Yamamoto
hi, while looking at PROTECTED build, i noticed that it was trivial for userspace code to bypass the protection and access kernel memory. eg. by passing kernel pointer to system calls. and it seems that it isn't the only way for userspace to trick the kernel. are these by design? eg. not a proble

CONFIG_BUILD_KERNEL questions

2020-02-20 Thread Takashi Yamamoto
hi, what's the status of CONFIG_BUILD_KERNEL? it seems only sama5 has the necessary up_ functions. is this right? is there a way to run on emulators like qemu? thank you

Re: dev board recommendation?

2020-02-13 Thread Takashi Yamamoto
her Wi-Fi router which does not have AR9223 chip? > > On 2020/02/12 16:56, "Takashi Yamamoto" > wrote: > > hi, > > what settings do you have in mind? > > the wifi router is in the same room, a few meters away from the board. > the smart

Re: dev board recommendation?

2020-02-11 Thread Takashi Yamamoto
ES)" > wrote: > > Thanks for the details. > > I think it's a GS2200M firmware issue. > Could you tell me a product name of the Wi-Fi router? > And the issue might be mitigated if you change Wi-Fi router settings. > > > On 2020/02/12 12:32,

Re: dev board recommendation?

2020-02-11 Thread Takashi Yamamoto
nect. i haven't investigated this symptom. > > On 2020/02/11 1:20, "Takashi Yamamoto" wrote: > > Thank you. > It looks like the same board as I have. > For me I feel it works 30% of the time. > I wonder what's the difference. >

Re: dev board recommendation?

2020-02-10 Thread Takashi Yamamoto
&keyword=spresense&zaikoFlg=false&partSameFlg=false > > On Mon, Feb 10, 2020 at 5:06 PM Xiang Xiao > wrote: > > > Ubuntu 18.04 run on VirtualBox with NAT. For me, I just spend the time > > with the hardware my project will use or the simulator. > > >

Re: dev board recommendation?

2020-02-10 Thread Takashi Yamamoto
ense > board since I am working on it and the WiFi implementation seems to be > stable > > //Alin > > On Mon, Feb 10, 2020, 16:53 Takashi Yamamoto > wrote: > > > which host os are you using? > > > > On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao > > wrote:

Re: dev board recommendation?

2020-02-10 Thread Takashi Yamamoto
which host os are you using? On Tue, Feb 11, 2020 at 12:46 AM Xiang Xiao wrote: > > We use sim which work very well and stable, all > TCP/IP(IP[v6]/ICMP[v6]/UDP/DHCP/DNS/NTP/TCP/TELNET) stack can run in > this virtual environment. > > On Mon, Feb 10, 2020 at 11:41 PM Takashi

Re: how to port things from spresense sdk

2020-02-10 Thread Takashi Yamamoto
On Tue, Feb 11, 2020 at 12:34 AM Gregory Nutt wrote: > > > > How about we host the active project porting on github.com/nuttx? so > > the community could share the work. > The ideal solution would be to have the Pahu MQTT support NuttX natively > in their code. Then you do not have to port it at

dev board recommendation?

2020-02-10 Thread Takashi Yamamoto
hi, i'm working on some apps which need network connectivity. does anyone have a recommendation of a board for development on which i can run nuttx reliably with network? (wifi or ethernet) either a real board i can purchase, or emulators/simulators. right now i'm using spresense and gs2200m-base

predefined platform C macro

2020-02-10 Thread Takashi Yamamoto
hi, i'm looking for something like __Darwin__, __Linux__, etc for nuttx so that i can have something like the following in my app. #ifdef __NuttX__ #include #endif i found some Make.defs defining -D__NuttX__. is it commonly used?

how to port things from spresense sdk

2020-02-10 Thread Takashi Yamamoto
hi, I wanted to use mqtt on nuttx. I found a nuttx port of paho.mqtt.embedded-c in spresense sdk. [1] I modified it for my nuttx $(APPDIR)/external. you can find it here: https://github.com/yamt/mqtt_nuttx while it worked, i'm not quite happy with having a fork like this. can anyone suggest a bett