ing
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 on both on
arm (stm32f7) and
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:
Petro Ka
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 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;
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(, 1);
"
, and never posting the sem from anywhere. The function return
-ETIMEDOUT properly on every
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
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
d, 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 would
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
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
>
> Petro = 145
>
> Unikie = 139
>
&
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 open
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
+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 лист.
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
se, 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.); with the
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
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
quot; (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 4/
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
.
- 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 standard
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.
> >
> > Posi
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
?
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
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
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
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
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 just leave
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 away
o 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 already
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
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,
> >
> > Maybe I was jumping in to conclusion and the issue is n
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-up.
Please give me feedback if
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
"
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,
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
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
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
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,
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
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;
> > +
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
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
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
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...
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
2_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 just the
>> first
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
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
48 matches
Mail list logo
