On 2025-07-09 01:20, Tomek CEDRO wrote:
Thank you Kerogit :-)
How about ARCH_HAVE_AVR_FLMAP? This would align with existing
nomenclature and enable easy filtering / sorting?
Thanks :-)
Tomek
Xiaoxiang781216 was faster on GitHub so I will be echoing a bit - I
don't think ARCH_HAVE is a good
Hello,
I prepared new version of the series, it's available in branch named
avrdx_flmap_v2 (and also attached.)
The changes are based on the feedback both from the mailing list and
from PR:
1) the #endif alignment was fixed. Checkpatch doesn't complain about
assembly files unfortunately an
Hi,
the naming may need to change but otherwise, this is intended.
The main deciding factor for this change is always board's linker script
- it has a final say for data placement and if it places .rodata into
appropriate location in flash and makes sure pointers are adjusted to
point into co
On 2025-07-07 13:03, Alin Jerpelea wrote:
Hi KR,
the patches have been submitted to mainline
you can follow the feedback on
https://github.com/apache/nuttx/pull/16687
Best regards
Alin
Thanks, will do.
Hello,
I would like to submit patches which change handling of const variables
in AVR architecture, DA/DB family.
AVR is a Harvard architecture with separate address spaces for program
and data memory. Unless the compiler is instructed otherwise, C pointers
are always referring to the data m
Hello,
I did some basic tests for AVR (AVR128DA28), everything seems to be fine
(casting no vote as I am not a PMC member and and I only used sources
from git and the tests done were really basic.)
Best regards
On 2025-06-30 07:05, Alin Jerpelea wrote:
Hello all,
Apache NuttX 12.10.0 RC0 h
Hi, I see that the patches are merged - thanks to the reviewers and
thank you for forwarding the patches to GitHub.
On 2025-06-19 09:01, Alin Jerpelea wrote:
Hi KR,
the patches have been uploaded
Best regards
Alin
On Thu, Jun 19, 2025 at 1:14 AM wrote:
Hello,
finally got to it, 4th revi
Hello,
finally got to it, 4th revision of the patches is in branch named
uart_fixes_rfc4 and also attached. This revision incorporates
suggestions from GitHub review.
1. The order of patches in the series is reversed (not counting the typo
fix patch.) The less intrusive one is now placed bef
Hello,
thanks. Here is a response to xiaoxiang781216's review:
could we extract a common typedef to avoid #ifdef/#else/#endif spread
the code base?
Can do - sbuf_size_t seems unused throughout the whole tree so I'll add
that to serial.h.
can we change to ARCH_HAVE_8BIT_BUFSIZE and put int
Hi,
thanks both to you and to the people who did the review.
On 2025-06-09 10:10, alin.jerpe...@sony.com wrote:
Hi KR,
your patch has been submitted
https://github.com/apache/nuttx/pull/16498
Best regards
Alin
Från: kr@kerogit.eu
Skickat: den 5 juni 2025 1
Hello,
reworked version of the series is in branch uart_fixes_rfc3 and also
attached. This version incorporates xiaoxiang781216's suggestion on
GitHub to simply make the buffer size stored in uint8_t variable if the
architecture cannot handle 16-bit loads atomically.
Fix for TOCTOU in waterm
Hello,
I would like to submit a patch fixing atomic functions defined in
arch_atomic.c when compiled for AVR
When trying to fix a race condition in the serial driver (PR #16466)
using __atomic_load_N, I noticed that the generated code was incorrect
for AVR architecture. The disassembly looke
Hello,
based on the feedback in GitHub review, I will redo the patch
differently and reduce the size of the circular buffers so the variables
fit into uint8_t.
To respond to xiaoxiang781216's comment about using atomic_xxx API
instead the critical section - I was considering that as well but
Hi
As for your second paragraph - have a look into the avrdx directory.
The first depends on if you are strictly speaking about ATmega and
AT90USB or if you mean all 8-bit MCUs in the AVR architecture. If you
only mean those two, then I can't really provide much input, don't have
experience w
Hello,
I noticed a review from Allan C. Assis about a spelling error. Updated
patches are attached and also available in repository in uart_fixes_rfc2
branch. (Sorry about the extra work, I was even trying to check the word
using web search... but I didn't spot that the search autocorrected it
While going through the code in drivers/serial/serial.c, I noticed this
comment:
The head and tail pointers are 16-bit values. The only time that
the following could be unsafe is if the CPU made two non-atomic
8-bit accesses to obtain the 16-bit head index.
This is what happens for (at least)
Hi,
I don't think updating the comment can do any harm so why not. And since
I have a fresh experience of trying to add support for new AVR
family/board, I can certainly imagine that I would be confused if I
noticed the discrepancy between the comment about the variable and its
initialization
Hi, was following, I see patches are merged, thanks to everyone for
help.
On 2025-05-27 10:24, Alin Jerpelea wrote:
Hi KR,
the patches have been submitted for review! Thanks for sending them .
please follow the progress on
https://github.com/apache/nuttx/pull/16451
Best regards
Alin
On Tue,
Well, I think I managed to figure it out.
First, an apology - I didn't read the patch in #16457 properly and
thought it just moves the _eronly assignment while it, in fact, changes
ABSOLUTE to LOADADDR too. Sorry for that.
After spotting this, I went and tried to find out how the change makes
Alright, I looked into the possible bug mentioned in the last paragraph
of my previous message and it seems the code is actually correct. What I
thought was that if register pair Z overflows, subsequent reads would
read from incorrect memory locations. However, that does not seem to be
the case
Hello,
I don't that is a correct fix and in fact, from a quick look at things
it seems to me that it actually introduces another bug. As described in
src/atmega/atmega_head.S, that value is supposed to be "Start of .data
section in FLASH". You changed it to end of .data section in FLASH. It
i
Thanks to you as well.
I spotted an error in the config posted both in the issue #16444 and PR
#16443. It is the
CONFIG_RAM_START=0x800100
Unless I overlooked something, the RAM starts at address 0x200
(0x800200) for AtMega 2560.
Not sure if that's what causing the problem though - as far
Hello,
as mentioned in one of my previous e-mails to this list (RFC: decoupling
ability to always panic from board_reset), I noticed #16444 and #16443
on GitHub.
I found some time to look into this and I believe I found the reason for
"If you add avr_lowputc calls in the board initialization
Hello,
I would like to submit some patches related to AVR architecture. Their
description is as follows:
0001 - this patch fixes LED constants for breadxavr board. The code was
developed based on other AVR boards, LED constants were taken from board
that apparently has multiple status LEDs a
Hello,
I would like to request comments for a change to _assert() behaviour in
sched/misc/assert.c
I noticed PR #16443 and associated issue #16444 . I wanted to do some
testing and noticed that it is somewhat difficult to terminate execution
using PANIC()
Currently, the code only terminate
Hello,
while working on documentation for AVR DA/DB chips, I noticed that two
documents related to networking in the simulator architecture are
leaking to the Table of Contents for supported platforms. I prepared a
patch to fix this - it is attached to this message as
0001a-Documentation-plat
Hello,
I noticed that the patches are now merged in master branch. Thanks to
everyone for the support. I also noticed that for a brief period there
was a second pull request (#16410) - it is now closed but it did mention
some problem. So just to be sure, is there something that still needs to
Hi,
thanks for the patience, now it makes sense. I started with assumption
that the default config file is created manually and then got confused
by the "modifications to the installed .config" in the disclaimer (was
thinking that is a step after I already have the default file complete
and w
Hello,
thanks for letting me know and thanks to the people reviewing the PR.
Based on their feedback, I prepared version 2 of the patches:
The elimination of unused sections patch (0004) was reworked. I have to
admit that I only have user experience with Kconfig (Linux kernel build)
and no d
Hello,
I would like to submit some fixes/improvements for the AVR DA/DB family
according to previous discussion in this thread. Summary of the changes
follows:
Patch 0004 - AVR_LINUXGCC_TOOLCHAIN_IS_GCC configuration option is now
removed. Instead, AVR_LINUXGCC_TOOLCHAIN selects ARCH_TOOLCHA
Hello,
On 2025-05-07 19:02, Xiang Xiao wrote:
Yes, it's better to not introduce AVR_LINUXGCC_TOOLCHAIN_IS_GCC since:
1. Other arch doesn't have this similar option
2. For compatibility, we can either unselect
DEBUG_OPT_UNUSED_SECTIONS
in defconfig or verify ld add KEEP correctly
A
I noticed, thanks. To reply to the comments and feedback in the PR:
1. The discussion about AVR_LINUXGCC_TOOLCHAIN_IS_GCC - my overall goal
was to minimize changes for boards and AVR families I am not using (and
have no experience with them and, most importantly, cannot test.)
Setting DEBUG_O
Hi, it's just /nuttx.git without the /apache part.
On 2025-05-05 17:46, Tomek CEDRO wrote:
Is server broken? I get 403 on https://git.kerogit.eu/apache/nuttx.git
and anything else in kerogit.eu domain :-(
Tomek
On Sun, May 4, 2025 at 4:44 PM wrote:
Hello,
new version of the patch series is
Hello,
new version of the patch series is posted in the git repository, the
branch is named avrdx_rfc2 and starts at avr_fixes_rfc2 (everything up
to and including avr_fixes_rfc2 is already merged.)
Here are the changes from previous version:
1. some formatting and typo fixes in various docu
Hi,
as far as I know, the development of gcc port for AVR stalled for some
time and there were some licensing issues. The result is that both
Ubuntu and Debian got stuck with some ancient versions (Ubuntu has
version 7.3, Debian has 5.4.) According to Ubuntu website, none of them
support thes
Hi,
thanks for the response and for the PR on GitHub.
Ok. If possible, could you explain the issue with github?
Well, it's a personal thing. Aside from the usual gripe about big
corporation there is also a clause in their Terms of Service that
requires the user to "agree to submit to the ex
Hello,
I would like to submit some patches for review and comments. The overall
goal is to provide support for AVR DA/DB family of chips but some of the
patches are more generic - fixes in other AVR chips and some typofixes
elsewhere.
I will attempt to post these patches through the mailing
Hi,
thanks for the reply and for the review. Also, no need to apologize.
As for the two configs - the original idea was to make sure
AVR_HAS_RAMPZ is deselected when the configuration changes to a chip
which does not have the register (or the only valid value is zero.) That
is what the "depen
Hello,
I would like to solicit a review for some fixes of (mostly) AVR
architecture code. These are some things I noticed when attempting to
create a port for AVR DA/DB family. I am doing my development based on
ATmega family since I am familiar with that and these patches (should)
only apply
Dne 2025-04-02 06:43, Takashi Yamamoto napsal:
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
Hello,
thanks for the replies. I attached a gzipped patch and also posted it in
clear below. It is based on 12.9 branch but should apply correctly to
master branch as well. Hopefully someone with GitHub account finds the
time. (Provided such a change indeed does not negatively affect other
ar
Hello,
I decided to try NuttX out - just as a hobbyist for learning experience.
I am currently attempting to create port for DA/DB family of AVR
architecture with support for tickless OS. My initial implementation
worked sort-of well: I created a simple application with a LED blinking
in 1/2
42 matches
Mail list logo
