Hi,
I have used in init scripts:
ifconfig eth0 hw
ifup eth0
One suitable place could be in rc.board_defaults, you just need to fetch
the mac address from the eeprom first with some other program.
Another option surely is to bring it up in board's board_app_initialize
or such...
Hi!
I just encountered a problem with do_stackcheck(), and wanted to ask for
an opinion...
In my (PX4) software I have got some threads, who define their stack
size unaligned by 4 bytes (uint32_t). The stack coloring works on
uint32, and thus doesn't color the topmost bytes of the stack whe
Hi!
I just encountered a problem with do_stackcheck(), and wanted to ask for
an opinion...
In my (PX4) software I have got some threads, who define their stack
size unaligned by 4 bytes (uint32_t). The stack coloring works on
uint32, and thus doesn't color the topmost bytes of the stack whe
Hi,
Yes it happens on master (just tested a minute ago). I think everything
else is in order, but stack coloring is broken at the top of the stack,
if the stack size is not aligned.
-Jukka
On 25.9.2020 11.08, Schock, Johannes - NIVUS GmbH wrote:
Is this happening on master as well? I've co
Sure! Go ahead and fix it the way you see best, thanks!
-Jukka
Schock, Johannes - NIVUS GmbH kirjoitti perjantai 25. syyskuuta 2020:
> > 1. Set the stack size as aligned already in
> > arch/arm/src/common/arm_createstack.c:
> >
> > - tcb->adj_stack_size = stack_size;
> > + tcb->adj_sta
Hi,
I am not quite sure about from where you measured (and what is your phy
config), but sending out 1000 bytes will take in theory about 800+ us at 10Mbps
and 80+ us at 100Mbps, so you probably wouldn't want it to be synchronous
(you'd like to be able to receive in full duplex at the same time
Hi!
I bumped into weirdest problem while running NuttX in protected mode
build on the STM32F765II (Pixhawk 4 HW):
If the user SRAM is configured as "shareable", I am not able to write
anything into the SRAM (not even early in the boot, initializing user
heaps fail).
If I remove the MPU_RAS
library, or
a c++ class, which is intended to be used on both sides.
I wonder if there is some nice way to avoid this kind of asymmetry?
br,
Jukka Laitinen
Hi,
There seems to be a bug in sector calculation which may trigger with
e.g. corrupted fs. I just made a PR for this,
https://github.com/apache/incubator-nuttx/pull/3740
But I really don't know if this is related to your issues, this is just
something that suddenly popped up elsewhere.
-J
Could it simply be a stack overflow?
Alan Carvalho de Assis kirjoitti keskiviikko 22. joulukuuta 2021:
> Exactly, something is changing the memory layout and forcing the error
> to happen.
>
> I can try duplicate it later, but I think it could be specific for
> your board configuration. What boar
Hi,
Sorry if this question comes several times, it seems that for some
reason my emails are not always coming through to the mailing list... So
re-sending.
I started getting this build error from the latest NuttX:
misc/lib_execinfo.c:45:17: error: null argument where non-null required
(argu
Hi,
Sorry if this question comes several times, it seems that for some
reason my emails are not always coming through to the mailing list... So
re-sending.
I started getting this build error from the latest NuttX:
misc/lib_execinfo.c:45:17: error: null argument where non-null required
(argu
Just my two cents,
I like the self-merge policy. I am using it in all the repos where I can decide.
My take on it is that it leaves the final responsibility for the change to the
PR creator. And at the same time it doesn't take away the authority of the
approvers.
While the responsibility is
HI,
Not sure what is the correct way to fix this, but I reverted:
"
commit f77956a227f1db6ecb44eda3814e7b02aa2187a6
Author: Petro Karashchenko
Date: Wed Jan 19 11:16:11 2022 +0200
tools: add option to reuse boards common files for custom boards
Signed-off-by: Petro Karashchenko
"
ree that have exactly the same
implementation as files from "boards/arm/samv7/common"
It seems like Daniel is hitting the same issue, so I expect that
renaming Makefile to Make.defs plus setting "BOARD_STM32_COMMON=n"
should fix the issue without any additional file clean-
e
> path '/home/pkarashchenko$/workspace/px4-firmware/boards/ssrc/saluki-v1'
> failed
> Failed to clone 'boards/ssrc/saluki-v1' a second time, aborting
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 09:34 Jukka Laitinen пише:
> >
> > Hi
And also note that the commit I mentioned is already reverted in nuttx
submodule, so you need to put it back in order to re-produce the issue :)
Jukka Laitinen kirjoitti torstai 3. maaliskuuta 2022:
> Hi, sorry about that; you can just remove that submodule, it is not needed to
> re-p
w to build or download a docker image that
> can be used to build that project?
> It takes me too much time to get build running.
>
> Best regards,
> Petro
>
> чт, 3 бер. 2022 р. о 12:43 Jukka Laitinen пише:
> >
> > And also note that the commit I mentioned is alread
/5705 to recover things
and added a separate option that should be explicitly enabled to
re-use a board-level common code by custom boards users.
Please try this change and feedback if that solves the problem.
Best regards,
Petro
чт, 3 бер. 2022 р. о 15:33 Jukka Laitinen пише:
Hi, sorry but I am
22 21.00, Petro Karashchenko wrote:
Hello Jukka,
I would like to ask you to try an alternative PR
https://github.com/apache/incubator-nuttx/pull/5712 and feedback if it
works for you.
Best regards,
Petro
чт, 10 бер. 2022 р. о 07:24 Jukka Laitinen пише:
Hi,
This fixes the build for me, I
Hi,
It is working fine for me now, thanks!
-jukka
On 17.3.2022 15.22, Petro Karashchenko wrote:
Helo Jukka,
I just want to confirm that you do not have any issues with the build on
the latest mainline.
Best regards,
Petro
пт, 11 бер. 2022 р. о 08:12 Jukka Laitinen пише:
Hi,
With this
Hi,
Please don't take the following as a rant, but rather as a kind reminder
for people conducting code reviews for NuttX.
Please, respect the author. You don't need to re-write every line of the
patch in comments just because you feel that the variable name could be
different or something i
Hi,
I was trying to make a more general statement than starting discussion
on separate PRs, but let me shortly answer still
On 25.3.2022 10.32, Xiang Xiao wrote:
On Fri, Mar 25, 2022 at 3:35 PM Jukka Laitinen
wrote:
Hi,
As an another example, we would very much like to bring in
?
Sorry for being blunt, but this is really irritating.
-Jukka
On 25.3.2022 21.47, Xiang Xiao wrote:
On Fri, Mar 25, 2022 at 6:53 PM Jukka Laitinen
wrote:
Hi,
I was trying to make a more general statement than starting discussion
on separate PRs, but let me shortly answer still
On 25.3.2022
Different posix implementations have different values for these flags, so I
think it is ok not to have the same as what linux has.
Posix (2017) specifies thar exactly one of the following is provided for open:
O_EXEC, O_RDWR, O_RDONLY, O_SEARCH and O_WRONLY, and other flags are bitwise
OR'd to
d be passed.
>
> Best regards,
> Petro
>
> On Fri, Apr 1, 2022, 6:54 PM Jukka Laitinen wrote:
>
> > Different posix implementations have different values for these flags, so
> > I think it is ok not to have the same as what linux has.
> >
> > Posix (2
no-op.
- Jukka
Jukka Laitinen kirjoitti perjantai 1. huhtikuuta 2022:
> In my opinion 0, if you are asking that, but it is strictly not conforming
> the standard.
>
> Posix says that "Applications shall specify exactly one of the first
> five...", so there is no correct sta
Hi,
If RISC-V S-mode and CONFIG_BUILD_KERNEL support is not wanted into NuttX,
please say it out loud instead of playing unfair review games.
The team has better things to do than re-write code letter-by letter via code
review, week after week. The code is good quality and working, and is d
owds" (i.e.:
> https://www.youtube.com/watch?v=Qfh-k9P8ZPI )
>
> So, instead getting mad about it, please try to implement the
> suggestions. You are an experienced contributor and I'm sure you can
> get this PR accepted as well. :-)
>
> BR,
>
> Alan
>
> On
As Greg said, this is a traditional way. I'd maybe allow dummy reads/writes if
permissions allow, but keep that logic in vfs by checking if the pointer is
initialized. Then you don't need to provide the dummy implementation in every
driver.
Petro Karashchenko kirjoitti lauantai 2. huhtikuuta 2
Hi!
I would like to do the posix shm interface for NuttX (shm_open,
shm_unlink etc.); with the following properties
- Would work in all memory protection modes (flat, protected and kernel).
- In flat it would just "malloc" the memory and share the pointer
w. mmap
- In protected it
ng else, ideas?
Suggestions? Maybe I missed something, but I didn't see an obvious way
to do munmap.
-Jukka
On 5.4.2022 14.04, Xiang Xiao wrote:
On Tue, Apr 5, 2022 at 5:08 PM Jukka Laitinen wrote:
Hi!
I would like to do the posix shm interface for NuttX (shm_open,
shm_unlink etc.)
On 7.4.2022 8.18, Xiang Xiao wrote:
On Wed, Apr 6, 2022 at 8:20 PM Jukka Laitinen wrote:
Hi!
Just started crafting the posix shm driver, with the following:
- Started with "driver" approach (i.e. not mountable fs), similar to
mqueue.
- Added shm_open and shm_unlink to syscalls
+1 for
nuttx
nuttx-apps
Petro Karashchenko kirjoitti lauantai 19. marraskuuta 2022:
> Hi,
>
> My two cents are that I think we should not rock the boat and just remove
> "incubator-" prefix from current repos that results in:
>
> nuttx
> nuttx-apps
>
> Best regards,
> Petro
>
> сб, 19 лист. 2
Hi,
We've implemented and been using "posix shm" support for nuttx ( not
up-streamed to mainline nuttx so far - I am open to discussion whether
there is interest for it ). For this, we've naturally utilized the
interfaces mentioned in the subject.
Currently those operations are implemented a
Xiang Xiao kirjoitti torstai 22. joulukuuta 2022:
> On Thu, Dec 22, 2022 at 2:28 PM Jukka Laitinen
> wrote:
>
> > Hi,
> >
> > We've implemented and been using "posix shm" support for nuttx ( not
> > up-streamed to mainline nuttx so far - I am
t; I listed only contributors with more than 10 commits, this is what I got:
>
> Xiaomi = 912 + 449 + 168 + 152 + (52) + 52 + 50 + 47 + 46 + 43 + 23 + 17 =
> 2011
>
> Sony = 116 + 113 + 75 + 73 + 53 = 430
>
> Espressif = 155 + 101 + 86 + 39 + 32 = 413
>
> Pe
Hi,
I am not sure whether it is necessary to separate mutex and semaphore
(although I do see the performance gain that it would give for mutex),
but there is another related topic I would like to raise.
Currently, the semaphores don't work (at all) for CONFIG_BUILD_KERNEL.
The simple reason
urpose. And, mapping
two full pages for just one semaphore. So it is not so nice.
>
> On 4/14/2023 6:18 AM, Jukka Laitinen wrote:
> > Hi,
> >
> > I am not sure whether it is necessary to separate mutex and semaphore
> > (although I do see the performance gain that it
Hi,
I like the alignment idea, thanks for bringing it up!
I think forcing the alignment for the semaphore, and accessing it
directly via page pool from the kernel is the simplest and most trivial
thing. It implements what also Greg suggested + fixes the issue of
semaphore being on the page bo
Hi,
A simple fix; just edit the topmost commit's commit message (simply do "git
commit --amend"). There is always something that can be improved or altered..
Then force-push the branch again :)
A bit hackish, I admit, but unless the re-trigger has not been enabled for
author, it is the best wa
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
ret = nxsem_tickwait_uninterruptible(&sem, 1);
"
, and never posting the sem from anywhere. The function return
-ETIMEDOUT properly on every
On 17.5.2023 16.38, Gregory Nutt wrote:
On 5/17/2023 7:21 AM, Gregory Nutt wrote:
On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
Hi,
I just observed the behaviour mentioned in the subject;
I tried just calling in a loop:
"
sem_t sem =SEM_INITIALIZER(0);
int ret;
d, May 17, 2023, 5:43 PM Jukka Laitinen wrote:
>
> >
> > On 17.5.2023 16.38, Gregory Nutt wrote:
> > > On 5/17/2023 7:21 AM, Gregory Nutt wrote:
> > >> On 5/17/2023 4:21 AM, Jukka Laitinen wrote:
> > >>>
> > >>> Hi,
> > >
On 17.5.2023 18.51, Nathan Hartman wrote:
Was it working before? If so, are you able to use a git bisect to find
the commit where the bug was introduced? This might minimize the
amount of testing and debugging that needs to be done.
On Wed, May 17, 2023 at 11:12 AM Jukka Laitinen wrote:
Pet
k timer and the watchdogs working
reliably.
Note that this is broken in all risc-v platforms. Arm platforms seem to
handle the systick in their own arch specific codes as before.
Br,
Jukka
On 19.5.2023 15.51, Jukka Laitinen wrote:
Yes, it worked before, but a long time ago. I tested this
Hi,
Reviewing the ethernet driver, I can see couple of bugs:
1) In stm32_freeframe, it should free all the buffers, and not just the first
one. So remove the "if ((txdesc->des3 & ETH_TDES3_RD_FD) != 0)"
That may cause it run out of buffers.
2) In stm32_freesegment, the order of getting the nex
Hi,
Reviewing the ethernet driver, I can see couple of bugs:
1) In stm32_freeframe, it should free all the buffers, and not just the
first one. So remove the "if ((txdesc->des3 & ETH_TDES3_RD_FD) != 0)"
That may cause it run out of buffers
2) In stm32_freesegment, the order of getting the next
change in the
> stm32_freebuffer. Have a nice weekend,
> Reto
>
> On 2020/02/21 08:07:41, Jukka Laitinen wrote:
>> Hi,
>>
>> Reviewing the ethernet driver, I can see couple of bugs:
>>
>> 1) In stm32_freeframe, it should free all the buffers, and not
The numbered list is reasonable as a guideline and good practise to cover at
least most of those things in free text.
But the template in the commit... please, no. I have had enough of those in big
companies and in the end they are just harmful.
Br,
Jukka
- Jukka
David Sidrane kirjoitti torst
Hi,
A kind reminder to everyone contributing code to NuttX;
Please keep in mind that it is NOT allowed to copy code snippets from
any GPL licensed code into Apache/NuttX.
While reading through arch/arm64 code base, my eye catches a lot of
places now, which resemble code in linux kernel. This
Hi!
LTS releases is a good idea as such, but the underlying problem which
Sebastien is (sort of..) pointing out needs to be addressed somehow also
in the mainline.
I get frustrated as well, from time to time, with a huge amount of
unnecessary commits being pushed in, very quickly. I will jus
Hi,
I didn't follow the full discussion, but we had similar problems with
sockets, file descriptors and dup. Just to draw your attention, this was
the PR / patches where the issue was fixed:
https://github.com/apache/nuttx/pull/16499 (originally
https://github.com/apache/nuttx/pull/16361)
53 matches
Mail list logo
