Re: [PATCH v4] Changed ARM fenv support and remodeled it similar to RISCV
Hello Eshan, I changed the commit message and sent the patch to the Newlib list: https://sourceware.org/pipermail/newlib/2020/017778.html ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [GSoC 2020]: Weekly thread update
On Sun, Jul 19, 2020 at 4:28 AM Gedare Bloom wrote:
> On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma
> wrote:
> >
> > [UPDATE]: Thank you so much Heinz, with commit
> `3afec267ab08568ea454789e562450b00feea5c0`v
> > I was able to successfully built EPICS7 with RTEMS5 for pc-386 and
> pc-386 qemu both.
> >
>
> Great. Is this with --enable-networking?
>
Yes.
>
> Is libbsd still not yet working?
>
Not sure. Can you tell me the way it can be checked here?
>
> > As advised, should I begin writing RSB recipe now for RTEMS5?
> > What can be the next steps?
> >
>
> I think so. You might try to write some simple script first for
> yourself, to help think through the logic of automation.
>
Sure, I will be starting a new thread for the next week and I will post it
there.
>
> > Please advise and also guide on what will be the best way to begin with
> writing RSB recipe?
> >
>
> Now that you know how to build by hand, you want to document what you
> need to do and then you can try to script it. I'm not really sure, but
> I guess it would be a new kind of "rtems-package" to build, since it
> is done after rtems is successfully installed? We'll eventually want
> this to be a vertically integrated package with the RTEMS
> configuration combined with EPICS for some BSPs that are known to
> work. Get started, and ask questions as you go.
>
> work from doco at
> https://docs.rtems.org/branches/master/user/rsb/index.html
> and submit changes as needed to improve it
>
Thank you so much, Gedare. I will work and update on a new thread soon.
>
> > Thanks
> > Mritunjay
> >
> > On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >>
> >>
> >> Thank you so much, I am trying and reverting soon.
> >>
> >> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes
> wrote:
> >>>
> >>> Mritunjay,
> >>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
> >>> Dated 25.9. 2019
> >>>
> >>> From Heinz
> >>>
> >>> On 17.07.2020, at 20:23, Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes <
> jun...@fhi-berlin.mpg.de> wrote:
>
> You are right. I was not aware of that the dhcpcd stuff is already
> included into the source of the epicsPlayground repo. Will have a look into
> it.
> Heinz
>
> FHI, Heinz Junkes
> >>>
> >>>
> >>> Thank you so much, Heinz! It will be kind of you to advice for now to
> how to proceed ahead like whether we have to either
> >>> use and build the old legacy stack using `--enable-networking` or the
> libbsd stack?
> >>> Also, should I start writing the recipe for RSB based on the existing
> notes of how the process went for building
> >>> EPICS7 for RTEMS5 for pc-386?
> >>>
> >>> Also, I have written another blog on what I learnt recently (using
> mutt). Here's the link:
> >>>
> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
> >>>
> >>> I also learnt about Networking Drivers from
> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
> >>>
> >>>
> >>> Thanks,
> >>> Mritunjay.
> >>>
> >>>
>
> On 15. Jul 2020, at 22:05, Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
>
>
> Apologies as I mistakenly sent this as a private mail.
> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending
> this again on what
> I responded.
>
> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma <
> mritunjaysharma...@gmail.com> wrote:
> >
> >
> >
> > On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes <
> jun...@fhi-berlin.mpg.de> wrote:
> >>
> >> Hello, Mritunjay,
> >>
> >> I'm afraid I've lost track of the situation. I am also still on
> holiday in Norway for 2 weeks and
> >> I don't always have perfect internet access.
> >
> >
>
> This:->
>
> >
> > I am extremely sorry to disturb you on a holiday. I will try to
> bring back to you where we currently are:
> > As advised by you I already have Built EPICS 7 with RTEMS 4.10 and
> tested it as well.
> > I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise
> that I forgot to update the thread that the suggestion
> > presented by Gedare to change to `#include ` from
> existing `#include ` helped me
> > fixed the error mentioned in the start of the thread
> ("../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such file
> or directory
> > #include ").
> >
> > I used the 'make' command again then inside `epics-base` (Downloaded
> from your GitHub's playground) and then got the
> > following error:
> >
> > `../posix/rtems_init.c:39:10: fatal error: rtems/dhcpcd.h: No such
> file or directory
> > #include
> > `
> > I discussed this with Gedare on the IRC channel and we concluded
> that it is there because we have to either
> > use and build the old legacy stack u
Re: [GSoC 2020]: Weekly thread update
It uses the legacy-stack.
When I am back I will adapt rtems_init to use libbsd.
You should proceed to write rsb recipes.
Heinz
FHI, Heinz Junkes
> On 19. Jul 2020, at 16:03, Mritunjay Sharma
> wrote:
>
>
>
>
>> On Sun, Jul 19, 2020 at 4:28 AM Gedare Bloom wrote:
>> On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma
>> wrote:
>> >
>> > [UPDATE]: Thank you so much Heinz, with commit
>> > `3afec267ab08568ea454789e562450b00feea5c0`v
>> > I was able to successfully built EPICS7 with RTEMS5 for pc-386 and pc-386
>> > qemu both.
>> >
>>
>> Great. Is this with --enable-networking?
>
> Yes.
>>
>> Is libbsd still not yet working?
>
> Not sure. Can you tell me the way it can be checked here?
>>
>> > As advised, should I begin writing RSB recipe now for RTEMS5?
>> > What can be the next steps?
>> >
>>
>> I think so. You might try to write some simple script first for
>> yourself, to help think through the logic of automation.
>
> Sure, I will be starting a new thread for the next week and I will post it
> there.
>>
>> > Please advise and also guide on what will be the best way to begin with
>> > writing RSB recipe?
>> >
>>
>> Now that you know how to build by hand, you want to document what you
>> need to do and then you can try to script it. I'm not really sure, but
>> I guess it would be a new kind of "rtems-package" to build, since it
>> is done after rtems is successfully installed? We'll eventually want
>> this to be a vertically integrated package with the RTEMS
>> configuration combined with EPICS for some BSPs that are known to
>> work. Get started, and ask questions as you go.
>>
>> work from doco at https://docs.rtems.org/branches/master/user/rsb/index.html
>> and submit changes as needed to improve it
>
> Thank you so much, Gedare. I will work and update on a new thread soon.
>>
>> > Thanks
>> > Mritunjay
>> >
>> > On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma
>> > wrote:
>> >>
>> >>
>> >> Thank you so much, I am trying and reverting soon.
>> >>
>> >> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes
>> >> wrote:
>> >>>
>> >>> Mritunjay,
>> >>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0
>> >>> Dated 25.9. 2019
>> >>>
>> >>> From Heinz
>> >>>
>> >>> On 17.07.2020, at 20:23, Mritunjay Sharma
>> >>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes
>> >>> wrote:
>>
>> You are right. I was not aware of that the dhcpcd stuff is already
>> included into the source of the epicsPlayground repo. Will have a look
>> into it.
>> Heinz
>>
>> FHI, Heinz Junkes
>> >>>
>> >>>
>> >>> Thank you so much, Heinz! It will be kind of you to advice for now to
>> >>> how to proceed ahead like whether we have to either
>> >>> use and build the old legacy stack using `--enable-networking` or the
>> >>> libbsd stack?
>> >>> Also, should I start writing the recipe for RSB based on the existing
>> >>> notes of how the process went for building
>> >>> EPICS7 for RTEMS5 for pc-386?
>> >>>
>> >>> Also, I have written another blog on what I learnt recently (using
>> >>> mutt). Here's the link:
>> >>> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003
>> >>>
>> >>> I also learnt about Networking Drivers from
>> >>> https://docs.rtems.org/branches/master/bsp-howto/networking.html.
>> >>>
>> >>>
>> >>> Thanks,
>> >>> Mritunjay.
>> >>>
>> >>>
>>
>> On 15. Jul 2020, at 22:05, Mritunjay Sharma
>> wrote:
>>
>>
>> Apologies as I mistakenly sent this as a private mail.
>> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending
>> this again on what
>> I responded.
>>
>> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma
>> wrote:
>> >
>> >
>> >
>> > On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes
>> > wrote:
>> >>
>> >> Hello, Mritunjay,
>> >>
>> >> I'm afraid I've lost track of the situation. I am also still on
>> >> holiday in Norway for 2 weeks and
>> >> I don't always have perfect internet access.
>> >
>> >
>>
>> This:->
>>
>> >
>> > I am extremely sorry to disturb you on a holiday. I will try to bring
>> > back to you where we currently are:
>> > As advised by you I already have Built EPICS 7 with RTEMS 4.10 and
>> > tested it as well.
>> > I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise
>> > that I forgot to update the thread that the suggestion
>> > presented by Gedare to change to `#include ` from
>> > existing `#include ` helped me
>> > fixed the error mentioned in the start of the thread
>> > ("../posix/rtems_init.c:38:10: fatal error: rtems/bsd/bsd.h: No such
>> > file or directory
>> > #include ").
>> >
>> > I used the 'make' command again then inside `epics-base` (Downloaded
>> > from your GitHub's playgroun
Re: [GSoC 2020]: Weekly thread update
Thank you, Heinz, for telling that. I have started writing recipes and will update about it in the new thread. Thanks Mritunjay On Sun, Jul 19, 2020 at 8:49 PM Heinz Junkes wrote: > It uses the legacy-stack. > When I am back I will adapt rtems_init to use libbsd. > You should proceed to write rsb recipes. > Heinz > > FHI, Heinz Junkes > > On 19. Jul 2020, at 16:03, Mritunjay Sharma > wrote: > > > > > On Sun, Jul 19, 2020 at 4:28 AM Gedare Bloom wrote: > >> On Sat, Jul 18, 2020 at 2:02 PM Mritunjay Sharma >> wrote: >> > >> > [UPDATE]: Thank you so much Heinz, with commit >> `3afec267ab08568ea454789e562450b00feea5c0`v >> > I was able to successfully built EPICS7 with RTEMS5 for pc-386 and >> pc-386 qemu both. >> > >> >> Great. Is this with --enable-networking? >> > > Yes. > >> >> Is libbsd still not yet working? >> > > Not sure. Can you tell me the way it can be checked here? > >> >> > As advised, should I begin writing RSB recipe now for RTEMS5? >> > What can be the next steps? >> > >> >> I think so. You might try to write some simple script first for >> yourself, to help think through the logic of automation. >> > > Sure, I will be starting a new thread for the next week and I will post it > there. > >> >> > Please advise and also guide on what will be the best way to begin with >> writing RSB recipe? >> > >> >> Now that you know how to build by hand, you want to document what you >> need to do and then you can try to script it. I'm not really sure, but >> I guess it would be a new kind of "rtems-package" to build, since it >> is done after rtems is successfully installed? We'll eventually want >> this to be a vertically integrated package with the RTEMS >> configuration combined with EPICS for some BSPs that are known to >> work. Get started, and ask questions as you go. >> >> work from doco at >> https://docs.rtems.org/branches/master/user/rsb/index.html >> and submit changes as needed to improve it >> > > Thank you so much, Gedare. I will work and update on a new thread soon. > >> >> > Thanks >> > Mritunjay >> > >> > On Sat, Jul 18, 2020 at 10:48 PM Mritunjay Sharma < >> mritunjaysharma...@gmail.com> wrote: >> >> >> >> >> >> Thank you so much, I am trying and reverting soon. >> >> >> >> On Sat, Jul 18, 2020 at 10:45 PM Heinz Junkes < >> jun...@fhi-berlin.mpg.de> wrote: >> >>> >> >>> Mritunjay, >> >>> can you try to use the commit 3afec267ab08568ea454789e562450b00feea5c0 >> >>> Dated 25.9. 2019 >> >>> >> >>> From Heinz >> >>> >> >>> On 17.07.2020, at 20:23, Mritunjay Sharma < >> mritunjaysharma...@gmail.com> wrote: >> >>> >> >>> >> >>> >> >>> On Fri, Jul 17, 2020 at 12:53 PM Heinz Junkes < >> jun...@fhi-berlin.mpg.de> wrote: >> >> You are right. I was not aware of that the dhcpcd stuff is already >> included into the source of the epicsPlayground repo. Will have a look into >> it. >> Heinz >> >> FHI, Heinz Junkes >> >>> >> >>> >> >>> Thank you so much, Heinz! It will be kind of you to advice for now to >> how to proceed ahead like whether we have to either >> >>> use and build the old legacy stack using `--enable-networking` or the >> libbsd stack? >> >>> Also, should I start writing the recipe for RSB based on the existing >> notes of how the process went for building >> >>> EPICS7 for RTEMS5 for pc-386? >> >>> >> >>> Also, I have written another blog on what I learnt recently (using >> mutt). Here's the link: >> >>> >> https://medium.com/@mritunjaysharma394/how-to-set-up-mutt-text-based-mail-client-with-gmail-993ae40b0003 >> >>> >> >>> I also learnt about Networking Drivers from >> https://docs.rtems.org/branches/master/bsp-howto/networking.html. >> >>> >> >>> >> >>> Thanks, >> >>> Mritunjay. >> >>> >> >>> >> >> On 15. Jul 2020, at 22:05, Mritunjay Sharma < >> mritunjaysharma...@gmail.com> wrote: >> >> >> Apologies as I mistakenly sent this as a private mail. >> I missed to tag Chris, Gedare and RTEMS Devel and that's why sending >> this again on what >> I responded. >> >> On Wed, Jul 15, 2020 at 10:35 PM Mritunjay Sharma < >> mritunjaysharma...@gmail.com> wrote: >> > >> > >> > >> > On Wed, Jul 15, 2020 at 7:48 PM Heinz Junkes < >> jun...@fhi-berlin.mpg.de> wrote: >> >> >> >> Hello, Mritunjay, >> >> >> >> I'm afraid I've lost track of the situation. I am also still on >> holiday in Norway for 2 weeks and >> >> I don't always have perfect internet access. >> > >> > >> >> This:-> >> >> > >> > I am extremely sorry to disturb you on a holiday. I will try to >> bring back to you where we currently are: >> > As advised by you I already have Built EPICS 7 with RTEMS 4.10 and >> tested it as well. >> > I was doing the same for EPICS7 with RTEMS5 for pc-386. I apologise >> that I forgot to update the thread that the suggestion >> > presented by Gedare to change to `#include ` from >> existing `#include ` helped me >> > fixed the error mentioned in
Re: [GSoC 2020]: Weekly thread update
On 20/7/20 2:08 am, Mritunjay Sharma wrote: > Thank you, Heinz, for telling that. > I have started writing recipes and will update about it in the new thread. Sorry for not responding before now, I have been occupied else where. Please follow Gedare's recommendation and document the steps. Do you have a script to perform an EPICS build? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Re: A question about rtems license
Thanks both of you for these advice. It is very clear for me now. small...@aliyun.com From: Gedare Bloom Date: 2020-07-18 23:49 To: Christian Mauderer CC: small...@aliyun.com; devel Subject: Re: A question about rtems license On Sat, Jul 18, 2020 at 9:20 AM Christian Mauderer wrote: > > Hello, > > note that I'm not a lawyer. I can only provide my personal opinion > regarding that topic. Depending of the legal system of your country a > lawyer might has a different point of view. I'm also only a small part > of the project and can't speak for all persons involved. > Indeed, we have no lawyers here to provide legal advice. > > As far as I understand your situation you basically forked RTEMS. The > fork would consist of "rtems src" and "rtems src2". These parts would be > covered by the RTEMS license. So if you provide a binary to someone, you > would have to make the "rtems src" and "rtems src2" available to this > person too if they ask. > Yes, if you modified "rtems src" and then distribute it, you need to provide the source for those modifications. > But your application is still a separate part and would be covered by > the linking exception. That means: you can keep it private. > Also correct. > > Please note that there is an ongoing effort to change the RTEMS license > to a BSD style license. A lot of sources are already BSD licensed. You > can see that if you have a look at the file headers. > That said, we encourage users to provide us with the changes they made to rtems. There are advantages if your changes are accepted, then you have more confidence about their correctness (additional review) and they may also be maintained by the community as long as they are useful. > As another note: RTEMS is always open to patches. So you might want to > think about polishing the "rtems src2" parts a bit and sending them to > the mailing list for integration into the official sources. > +1 > Best regards > > Christian > > On 18/07/2020 11:45, small...@aliyun.com wrote: > > Hi, > > There is a project using rtems as a real time os in an arm cortex R5 > > bsp. Primary RTEMS License says > > that RTEMS is free software; you can redistribute it and/or modify it under > > terms of the > > GPL. > > As a special exception, including RTEMS header files in a file, > > instantiating RTEMS generics or templates, or linking other files with > > RTEMS objects to produce an executable application, does not by itself > > cause the resulting executable application to be covered by the GPL. > > I draw a picture to describe this special exception: > > There are "rtems src", "rtems header" and our "application". The "rtems > > src" will be compiled to a lib called "rtems lib". If our "application" > > includes "rtems header" and linkes with "rtems lib", then our > > "application" does not follow GPL. > > > > OK, here is my question: we modify some code in "rtems src" and build it > > to "rtems lib2". If our "application" includes "rtems header" and > > linkes with "rtems lib2", whether or not our "application" should follow > > GPL? > > (of course, rtems src2 should follow GPL) > > > > > > small...@aliyun.com > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 3/3] bsps/fdt: Make sure data is cache aligned.
Hello Gedare,
thanks for the review.
On 17/07/2020 17:53, Gedare Bloom wrote:
> The other 2 BSP-specific patches look fine. I didn't look too closely
> at the imx-specific part.
>
> On Thu, Jul 16, 2020 at 11:55 PM Christian Mauderer
> wrote:
>>
>> The cache of the fdt blob is flushed after copy. Therefore it should be
>> aligned.
>> ---
>> bsps/shared/start/bsp-fdt.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
>> index 7e8d8922a8..f55273e4ca 100644
>> --- a/bsps/shared/start/bsp-fdt.c
>> +++ b/bsps/shared/start/bsp-fdt.c
>> @@ -28,10 +28,10 @@
>> #endif
>>
>> #ifdef BSP_FDT_BLOB_READ_ONLY
>> -static const uint32_t
>> +static const uint32_t CPU_STRUCTURE_ALIGNMENT
>
> Typically seen the alignment after the variable decl. Maybe it is
> flexible, but we might consider a rule for consistency if both
> placements work.
I'll move it.
>
>> bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
>> #else
>> -static uint32_t
>> +static uint32_t CPU_STRUCTURE_ALIGNMENT
>> bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
>> #endif
>>
>> @@ -48,6 +48,7 @@ void bsp_fdt_copy(const void *src)
>>
>>if (s != d) {
>> size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
>> +size_t aligned_size = ((m-1) | (CPU_CACHE_LINE_BYTES-1)) + 1;
>
> This is a little bit of magic, I guess it works with cache line bytes
> a power of 2. Do we have a macro for this?
>
I don't think that we have a macro for alignment. But I found a
"roundup2" in newlibs sys/param.h after some searching. I'll try to use
that one.
>> size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
>> size_t i;
>>
>> @@ -55,7 +56,7 @@ void bsp_fdt_copy(const void *src)
>>d[i] = s[i];
>> }
>>
>> -rtems_cache_flush_multiple_data_lines(d, m);
>> +rtems_cache_flush_multiple_data_lines(d, aligned_size);
>>}
>> }
>>
>> --
>> 2.26.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2 3/3] bsps/fdt: Make sure data is cache aligned.
The cache of the fdt blob is flushed after copy. Therefore it should be
aligned.
---
bsps/shared/start/bsp-fdt.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/bsps/shared/start/bsp-fdt.c b/bsps/shared/start/bsp-fdt.c
index 7e8d8922a8..50a485eb16 100644
--- a/bsps/shared/start/bsp-fdt.c
+++ b/bsps/shared/start/bsp-fdt.c
@@ -29,10 +29,11 @@
#ifdef BSP_FDT_BLOB_READ_ONLY
static const uint32_t
-bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] = { 0xdeadbeef };
+bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT
=
+ { 0xdeadbeef };
#else
static uint32_t
-bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)];
+bsp_fdt_blob[BSP_FDT_BLOB_SIZE_MAX / sizeof(uint32_t)] CPU_STRUCTURE_ALIGNMENT;
#endif
void bsp_fdt_copy(const void *src)
@@ -48,6 +49,7 @@ void bsp_fdt_copy(const void *src)
if (s != d) {
size_t m = MIN(sizeof(bsp_fdt_blob), fdt_totalsize(src));
+size_t aligned_size = roundup2(m, CPU_CACHE_LINE_BYTES);
size_t n = (m + sizeof(*d) - 1) / sizeof(*d);
size_t i;
@@ -55,7 +57,7 @@ void bsp_fdt_copy(const void *src)
d[i] = s[i];
}
-rtems_cache_flush_multiple_data_lines(d, m);
+rtems_cache_flush_multiple_data_lines(d, aligned_size);
}
}
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
