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
26 matches
Mail list logo
