[PATCH 00/26] leon: various fixes and TN0018 errata workaround

Daniel Hellstrom daniel at gaisler.com
Thu Mar 11 17:10:50 UTC 2021

On 2021-03-08 16:43, Joel Sherrill wrote:
> On Sun, Mar 7, 2021 at 9:51 AM Daniel Hellstrom <daniel at gaisler.com 
> <mailto:daniel at gaisler.com>> wrote:
>     On 2020-09-23 17:05, Gedare Bloom wrote:
>>     On Wed, Sep 23, 2020 at 4:34 AM Daniel Hellstrom<daniel at gaisler.com>  <mailto:daniel at gaisler.com>  wrote:
>>>     Hi Sebastian,
>>>     Thanks for asking and sorry for dropping the ball on these.
>>>     The status is that two needs updating (BSD license for new CAN files and
>>>     the last tn0018 patch needs some redesign based on feedback) and the
>>>     others are accepted for master. I've sent an response on the tn0018
>>>     errata patch just now. I would like to push them on the 5 and master
>>>     branches. To get them onto 5, should  I create a ticket for the whole
>>>     patch set? I will try getting this done next next couple of days, and
>>>     have a look at you patches too, thanks!
>>     It would be good to separate them logically to the TN-0018 errata
>>     fixes vs the CAN/grlib improvements. The concern for pushing them to 5
>>     is that they touch core sparc files, but since you guys are releasing
>>     them this way in RCC I'm also comfortable with it. I didn't see any
>>     changes outside the sparc (since currently grlib is sparc-specific
>>     too). We'll need those tickets to help us with the dot-release notes.
>     Sorry for my very late response. There were some more updates on a
>     few of the patches based on the review comments which has been
>     addressed. I have now created tickets for all of them which are
>     referenced from the patches, so I will go ahead and push them for
>     the 5-branch (the posted patches targeted 5).
> I agree with Gedare on trusting the patches. My only concern is making 
> sure proper tickets are filed. A couple of guidelines may help decide 
> how many tickets and for what.
> The first thing to remember is that tickets are automatically 
> processed into release notes. If it is important enough to show up in 
> a release note, file a ticket. I have been prodding Ryan to file 
> tickets for the Coverity issues because I think they should be in 
> release notes.
> For 5, any changes should have tickets. This is a long standing rule 
> for release branches.

Thanks for the comments, I will keep that in mind going forward. I made 
a couple of tickets for the RTEMS/master and tickets for all patches for 
5.2 milestone.

>     However, I will wait with the TN-0018 before I get an acknowledge
>     for that one. I updated the its ticket with links to the GCC patch
>     that has now been accepted into upstreams GCC (GCC-10 stable and
>     master). The TN0018 patch is not enabled if the GCC-patch is not
>     included in the toolchain, so I believe it should be ok to push,
>     even before RSB is updated?
> It sounds like it will be ok.
Ok, thanks!
> What happens with TN0018 on the 5 branch where we are using older tools?
>     https://devel.rtems.org/ticket/4155
>     <https://devel.rtems.org/ticket/4155>
I have submitted a RSB patch which as been acked by Chris and Sebastian, 
so I will proceed to push the tn0018 patch to 5 now.

>     Next step for me is to add some configurations for the new build
>     system before I can push them to RTEMS/master.
This has been done and pushed now. waf is really a speed improvement! 
> Thanks for submitting all these. Is this going to clean your queue?

The queue is much smaller now! These were the most important when I 
started but got choked, I will follow up with a few important fixes done 


> --joel
>     Thanks,
>     /Daniel
>>>     Kind Regards,
>>>     Daniel
>>>     On 2020-09-18 10:03, Sebastian Huber wrote:
>>>>     Hallo Daniel,
>>>>     what are your plans with respect to this patch set?
>>>>     Please also have a look at:
>>>>     https://lists.rtems.org/pipermail/devel/2020-September/062176.html  <https://lists.rtems.org/pipermail/devel/2020-September/062176.html>
>>>     _______________________________________________
>>>     devel mailing list
>>>     devel at rtems.org  <mailto:devel at rtems.org>
>>>     http://lists.rtems.org/mailman/listinfo/devel  <http://lists.rtems.org/mailman/listinfo/devel>
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
>     <http://lists.rtems.org/mailman/listinfo/devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210311/1192ee50/attachment.html>

More information about the devel mailing list