Hi!
On 21.2.2020 16.08, Reto Gähwiler wrote:
> Hi Jukka,
>
> First of all, thanks for your time and hints. Just applied your suggested
> change to the stm32_freebuffer.
Don't mention, I am sort of responsible for these bugs originally ;)
> About the second suggested fix in
Could you register a confluence account? so you can modify the page directly.
On Fri, Feb 21, 2020 at 10:51 PM Florian Wehmeyer wrote:
>
>
> Hi all,
>
> just tested the
>
> "Updating a Release System with ELF Programs – No Symbol Tables"
>
>
The attachment may be filtered by apache server, please submit a PR to:
https://github.com/apache/incubator-nuttx/pulls
Or change the patch suffix and resend again.
Thanks
Xiang
On Sat, Feb 22, 2020 at 5:33 AM GOERLITZ Otmar
wrote:
>
> Dear Madams and Sirs,
>
>
>
> the file
On Sat, Feb 22, 2020 at 12:58 AM Nathan Hartman
wrote:
>
> On Fri, Feb 21, 2020 at 11:21 AM David Sidrane
> wrote:
>
> > This is what I did:
> >
> > For apps and nuttx git fetch nuttx
> > For apps and nuttx git checkout master
> > For apps and nuttx git reset -hard nuttx/master
> >
> > make
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
On Fri, Feb 21, 2020 at 4:33 PM GOERLITZ Otmar
wrote:
> Dear Madams and Sirs,
> the file arch/arm/src/stm32/hardware/stm32f30xxx_rcc.h of NuttX 8.2. (as of
> 2020-02-21) appears to contain some incorrect definitions for RCC_CFGR3
> register.
>
> Please consider the attached patch.
Hello,
Dear Madams and Sirs,
the file arch/arm/src/stm32/hardware/stm32f30xxx_rcc.h of NuttX 8.2. (as of
2020-02-21) appears to contain some incorrect definitions for RCC_CFGR3
register.
Please consider the attached patch.
Best regards,
Otmar
Otmar Görlitz
Embedded Software Developer
T: +41 41 729
Hi Jukka,
First of all, thanks for your time and hints. Just applied your suggested
change to the stm32_freebuffer.
About the second suggested fix in stm32_freesegment, how do you mean that? The
stm32_get_next_rxdesc just increments the descriptor, this should be
independent from advancing
On Fri, Feb 21, 2020 at 11:21 AM David Sidrane
wrote:
> This is what I did:
>
> For apps and nuttx git fetch nuttx
> For apps and nuttx git checkout master
> For apps and nuttx git reset -hard nuttx/master
>
> make distclean
> ./tools/configure.sh imxrt1060-evk:nsh
> make oldconfig
> make
>
>
Hi Takashi
Spot on!
Reverting 5cb020c70f14b2ff766c96da87c3c4bfd32c
Fixes the build.
Please test these changes on all build platforms before merging.
David
-Original Message-
From: Takashi Yamamoto [mailto:yamam...@midokura.com.INVALID]
Sent: Friday, February 21, 2020 7:25 AM
To:
This is what I did:
For apps and nuttx git fetch nuttx
For apps and nuttx git checkout master
For apps and nuttx git reset -hard nuttx/master
make distclean
./tools/configure.sh imxrt1060-evk:nsh
make oldconfig
make
The results are as shown.
Why are we changed the build system without testing
it seems --no-print-directory/--print-directory controls these outputs.
do you have any MAKEFLAGS set?
or maybe different builds of make might come with different defaults.
(i'm using the one from macOS)
i'm afraid i can't investigate this until Tue.
please feel free to revert my changes in the
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
On Fri, Feb 21, 2020 at 10:13 AM David Sidrane
wrote:
> Build is broken
>
> Build is broken
>
> And the output looks very ODD - any ideas on what happened?
Have you tried make distclean, reconfigure, retry build?
If so, could you run a bisect since the last good known build and identify
the
Build is broken
Build is broken
And the output looks very ODD - any ideas on what happened?
Leaving directory
'/home/david_s5/src/PX4/repos/mainline/NuttX/apps/platform'
arm-none-eabi-ar rcs
/home/david_s5/src/PX4/repos/mainline/NuttX/apps/libapps.a make[1]:
Entering directory
Hi all,
just tested the
"Updating a Release System with ELF Programs – No Symbol Tables"
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629542
which is same procedure as Alans video tutorial at nuttx channel.
In the elfprog-nosymtab.tar.gz files downloaded from the
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.
I am not clear how that would work.
Hi David,
I'm a bit new to the Github/upstreaming flow, so please forgive any mistakes.
I have created a draft PR here:
https://github.com/apache/incubator-nuttx/pull/347
I have correctly enumerated the board as a USB serial port and as an RNDIS
device. I figured that D-Cache without
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
19 matches
Mail list logo
