Re: [PATCH v3] riscv: add freedom E310 Arty A7 bsp

[Pragnesh Patel]

On Mon, Sep 30, 2019 at 12:03 PM Hesham Almatary
 wrote:
>
> Hi Pragnesh,
>
> That's a so much better refined patch, thanks! Please find my minor
> comments inlined below.
>
> After the patch gets merged, could you please add a new section about
> that BSP to the RISC-V chapter doc here [1]?
>
> [1] https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html

Ok, I will do that.

>
> On Fri, 27 Sep 2019 at 12:20, Pragnesh Patel  
> wrote:
> >
> > Added support for Sifive Freedom FE310 soc on Arty A7 FPGA board.
> > Update #3785.
> >
> > Signed-off-by: Pragnesh Patel 
> > ---
> >
> > Changes in v3:
> >   - Remove bsps/riscv/frdme310arty/ directory and added support for
> > Freedom FE310 soc in common bsps/riscv/riscv/ directory
> >
> >   - Added #define RISCV_ENABLE_FRDME310ARTY_SUPPORT in configure.ac
> > to enable support for FE310
> >
> >   - Change the RISCV_RAM_REGION_SIZE to 256 MB for riscv
> >
> > Changes in v2:
> >
> >   bsps/riscv/frdme310arty/btimer/btimer.c
> > - Remove the read_csr() function from btimer.c
> > - Remove CONFIG_BTIMER_RISCV_GET_MCYCLES macro to get time in
> >   microseconds
> >
> >   bsps/riscv/frdme310arty/clock/clockdrv.c
> >   bsps/riscv/riscv/clock/clockdrv.c
> > - Delete both files and Add bsps/riscv/shared/clock/clockdrv.c
> > - riscv_clock_get_timebase_frequency(): Get timebase-frequency from
> >   cpus or cpu@0 devicetree node because riscv uses "cpus" node and
> >   frdme310arty uses "cpu@0" node to look for timebase-frequency
> > - Remove rtems_counter_initialize_converter() and
> >   rtems_timecounter_simple_install() functions
> >
> >   bsps/riscv/frdme310arty/include/bsp/riscv.h
> > - Remove unused frdme310arty_l2c_base;
> >
> >   bsps/riscv/frdme310arty/start/bsp_fatal_halt.c
> >   bsps/riscv/riscv/start/bsp_fatal_halt.c
> > - Delete this file and Add bsps/riscv/shared/start/bsp_fatal_halt.c
> >
> >   bsps/riscv/frdme310arty/start/bspstart.c
> > - Remove unused function riscv_get_node_byname()
> >
> >   bsps/riscv/frdme310arty/start/linkcmds.in
> > - Use @RISCV_RAM_REGION_BEGIN@ and @RISCV_RAM_REGION_SIZE@ instead of
> >   hard coded values
> >
> >   c/src/lib/libbsp/riscv/frdme310arty/Makefile.am
> > - librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
> > - librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c
> >
> >   c/src/lib/libbsp/riscv/frdme310arty/configure.ac
> > - change RISCV_RAM_REGION_SIZE to default 256MiB
> >
> >   bsps/riscv/riscv/irq/irq.c
> > - Delete this irq.c and it will now use bsps/riscv/shared/irq/irq.c
> >
> >   c/src/lib/libbsp/riscv/riscv/Makefile.am
> > - librtemsbsp_a_SOURCES -> bsps/riscv/shared/start/bsp_fatal_halt.c
> > - librtemsbsp_a_SOURCES -> bsps/riscv/shared/clock/clockdrv.c
> > - librtemsbsp_a_SOURCES -> bsps/riscv/shared/irq/irq.c
> >
> >
> >  bsps/include/bsp/fatal.h  |   3 +-
> >  bsps/riscv/riscv/clock/clockdrv.c |  16 ++--
> >  bsps/riscv/riscv/console/console-config.c |  57 +
> >  bsps/riscv/riscv/console/fe310-uart.c | 100 +++
> >  bsps/riscv/riscv/dts/frdme310arty.dts | 130 
> > ++
> >  bsps/riscv/riscv/include/bsp/fe310-uart.h |  42 ++
> >  bsps/riscv/riscv/include/bsp/riscv.h  |   4 +
> >  bsps/riscv/riscv/start/bspstart.c |  52 
> >  c/src/lib/libbsp/riscv/riscv/Makefile.am  |   8 ++
> >  c/src/lib/libbsp/riscv/riscv/configure.ac |   7 +-
> >  10 files changed, 411 insertions(+), 8 deletions(-)
> >  create mode 100644 bsps/riscv/riscv/console/fe310-uart.c
> >  create mode 100644 bsps/riscv/riscv/dts/frdme310arty.dts
> Why do you need to add the .dts file? Is it just for reference?
> Doesn't the bootrom and/or u-boot pass its to RTEMS in a1 register?

We are using a custom Bootloader (Not bootrom or u-boot) for Freedom
E310. I will provide a link for it in
README. Bootloader will pass .dtb address in a1 register and copy the
rtems Binary from Flash to RAM and passes
control to RTEMS binary.

User can create a .dtb file which will be used by bootloader. Right
now, .dts file used for both as a reference and to generate
a .dtb file.

>
> >  create mode 100644 bsps/riscv/riscv/include/bsp/fe310-uart.h
> >
> > diff --git a/bsps/include/bsp/fatal.h b/bsps/include/bsp/fatal.h
> > index fae5461..3f8e1eb 100644
> > --- a/bsps/include/bsp/fatal.h
> > +++ b/bsps/include/bsp/fatal.h
> > @@ -152,7 +152,8 @@ typedef enum {
> >RISCV_FATAL_INVALID_PLIC_NDEV_IN_DEVICE_TREE,
> >RISCV_FATAL_TOO_LARGE_PLIC_NDEV_IN_DEVICE_TREE,
> >RISCV_FATAL_INVALID_INTERRUPT_AFFINITY,
> > -  RISCV_FATAL_NO_NS16550_INTERRUPTS_IN_DEVICE_TREE
> > +  RISCV_FATAL_NO_NS16550_INTERRUPTS_IN_DEVICE_TREE,
> > +  RISCV_FATAL_NO_TLCLOCK_FREQUENCY_IN_DEVICE_TREE
> >  } bsp_fatal_code;
> >
> >  RTEMS_NO_RETURN static inline void
> > diff --git a/bsps/riscv/riscv/clock/clockdrv.c 
> > b/bsps/riscv/riscv/clock/clockd

[PATCH] eng: Update issue tracking section

[Sebastian Huber]

---
 eng/issue-tracking.rst | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/eng/issue-tracking.rst b/eng/issue-tracking.rst
index 62c8a28..1039b41 100644
--- a/eng/issue-tracking.rst
+++ b/eng/issue-tracking.rst
@@ -1,21 +1,16 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
+.. Copyright (C) 2019 embedded brains GmbH
+.. Copyright (C) 2019 Sebastian Huber
+.. Copyright (C) 2018 Joel Sherill
 
 Issue Tracking
 **
 
-TBD Review process, workflows, etc
-
-TBD - This covers Issue Tracking and Trac usage
-Need instructions which weave useful URLs including ones like these
-https://devel.rtems.org/query
-https://devel.rtems.org/wiki/NewTicket
+The RTEMS Project uses Trac to manage all change requests and problem reports
+and refers to either as a ticket.
 
-Filing a Change Request or Problem Report
-=
+The bug reporting procedure is documented in the
+`RTEMS User Manual 
`_.
 
-The RTEMS Project uses Trac to manage all change requests and problem reports
-and refers to either as a ticket.  Ticket may be filed or viewed at
-https://devel.rtems.org/wiki/Release
+TBD Review process, workflows, etc.
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/2] user: Update contributing section

[Sebastian Huber]

---
 user/support/contrib.rst | 41 +++--
 1 file changed, 19 insertions(+), 22 deletions(-)

diff --git a/user/support/contrib.rst b/user/support/contrib.rst
index fb95e34..04c5dd8 100644
--- a/user/support/contrib.rst
+++ b/user/support/contrib.rst
@@ -21,8 +21,8 @@ Why Contribute?
 ===
 
 If you are writing a major extension to RTEMS, such as a port
-to a new CPU family or model, a new target board, a major rewrite
-of some existing component, or adding some missing functionality,
+to a new CPU family (processor architecture) or model, a new target board, a
+major rewrite of some existing component, or adding some missing functionality,
 please keep in mind the importance of keeping other developers informed.
 Part of being a good cooperating member of the RTEMS development team is the
 responsibility to consider what the other developers need in order
@@ -30,7 +30,7 @@ to work effectively.
 
 Nobody likes to do a lot of work and find it was duplicated effort.
 So when you work on a major new feature, you should tell
-rtems-us...@www.rtems.com what you are working on, and give
+:r:list:`users` what you are working on, and give
 occasional reports of how far you have come and how confident
 you are that you will finish the job. This way, other developers
 (if they are paying attention) will be aware which projects would
@@ -38,11 +38,12 @@ duplicate your effort, and can either join up with you, or 
at
 least avoid spending time on something that will be unnecessary
 because of your work. If, for whatever reason, you are not in a
 position to publicly discuss your work, please at least privately
-let a Steering Committee member know about it so they can look
-out for duplicated effort or possible collaborators.
+let an
+`RTEMS maintainer `_
+know about it so they can look out for duplicated effort or possible
+collaborators.
 
-You should also monitor the
-`RTEMS Mailing Lists 
`_.
+You should also monitor the :r:list:`users` and :r:list:`devel`
 to see if someone else mentions working on a similar
 project to yours. If that happens, speak up!
 
@@ -58,7 +59,7 @@ Someone else may be able to finish the job.
 Many people have done RTEMS ports or BSPs on their own, to a wide
 variety of processors, without much communication with the RTEMS
 development team. However, much of this work has been lost over
-time, or have proven very hard to integrate. So, what we're asking
+time, or have proven very hard to integrate. So, what we are asking
 is that, to the maximum extent possible, you communicate with us
 as early on and as much as possible.
 
@@ -70,9 +71,9 @@ them. While the focus here is on new ports and BSPs, we 
believe that
 the issues are similar for other RTEMS development efforts including
 student efforts to implement new algorithmic optimizations.
 
-''Our engineers understand our target environment better than anyone
-else, and we have a tight schedule. Why should we work with the RTEMS
-developers, when we can get the code out faster by whacking it out on our 
own?''
+Our engineers understand our target environment better than anyone else, 
and
+we have a tight schedule. Why should we work with the RTEMS developers, 
when
+we can get the code out faster by whacking it out on our own?
 
 You understand your target environment better than anyone else.
 However, the RTEMS developers understand RTEMS better than anyone
@@ -99,10 +100,10 @@ to begin interacting with the RTEMS team, you might find 
that you did
 some things wrong and you may have to rewrite parts of your RTEMS port,
 which is a waste of your valuable time.
 
-''Why should we care if our port is integrated into the official
-RTEMS sources? We can distribute it ourselves to whoever is interested.''
+Why should we care if our port is integrated into the official RTEMS
+sources? We can distribute it ourselves to whoever is interested.
 
-Yes, the GNU GPL allows you to do that. But by doing so, you end up
+Yes, the RTEMS licenses allows you to do that. But by doing so, you end up
 having to maintain that code yourself; this can be a significant
 effort over time as the RTEMS sources change rapidly.
 
@@ -117,14 +118,14 @@ intervention.
 It has been our experience that integrated ports tend to ultimately
 be of better quality and stay up to date from release to release.
 
-''Why should we communicate up front? We're happy to let the
-RTEMS developers integrate our stuff later.''
+Why should we communicate up front? We are happy to let the RTEMS 
developers
+integrate our stuff later.
 
 See above. It will save work for you over both the short and the
 long term, and it is the right thing to do.
 
-''Aspects of my target environment that my application exploits
-are still under NDA.''
+Aspects of my target environment that my application exploits are still
+

[PATCH 1/2] Move contributing content from eng to user

[Sebastian Huber]

---
 eng/management.rst   |   1 -
 eng/why-contribute.rst   | 151 ---
 user/support/contrib.rst | 146 +
 3 files changed, 146 insertions(+), 152 deletions(-)
 delete mode 100644 eng/why-contribute.rst

diff --git a/eng/management.rst b/eng/management.rst
index 3b9a565..064559c 100644
--- a/eng/management.rst
+++ b/eng/management.rst
@@ -18,4 +18,3 @@ Software Development Management
 coding
 change-management
 issue-tracking
-why-contribute
diff --git a/eng/why-contribute.rst b/eng/why-contribute.rst
deleted file mode 100644
index 2e12f5c..000
--- a/eng/why-contribute.rst
+++ /dev/null
@@ -1,151 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-4.0
-
-.. Copyright (C) 2018.
-.. COMMENT: RTEMS Foundation, The RTEMS Documentation Project
-
-
-Why Contribute?
-***
-
-If you are writing a major extension to RTEMS, such as a port
-to a new CPU family or model, a new target board, a major rewrite
-of some existing component, or adding some missing functionality,
-please keep in mind the importance of keeping other developers informed.
-Part of being a good cooperating member of the RTEMS development team is the
-responsibility to consider what the other developers need in order
-to work effectively.
-
-Nobody likes to do a lot of work and find it was duplicated effort.
-So when you work on a major new feature, you should tell
-rtems-us...@www.rtems.com what you are working on, and give
-occasional reports of how far you have come and how confident
-you are that you will finish the job. This way, other developers
-(if they are paying attention) will be aware which projects would
-duplicate your effort, and can either join up with you, or at
-least avoid spending time on something that will be unnecessary
-because of your work. If, for whatever reason, you are not in a
-position to publicly discuss your work, please at least privately
-let a Steering Committee member know about it so they can look
-out for duplicated effort or possible collaborators.
-
-You should also monitor the
-`RTEMS Mailing Lists 
`_.
-to see if someone else mentions working on a similar
-project to yours. If that happens, speak up!
-
-If you are thinking of taking a contract to develop changes
-under a temporary delayed-release agreement, please negotiate
-the agreement so that you can give progress reports before the
-release date, even though you cannot release the code itself.
-Also please arrange so that, when the agreed-on date comes,
-you can release whatever part of the job you succeeded in doing,
-even if you have not succeeded in finishing it.
-Someone else may be able to finish the job.
-
-Many people have done RTEMS ports or BSPs on their own, to a wide
-variety of processors, without much communication with the RTEMS
-development team. However, much of this work has been lost over
-time, or have proven very hard to integrate. So, what we're asking
-is that, to the maximum extent possible, you communicate with us
-as early on and as much as possible.
-
-
-Common Questions and Answers
-
-
-Here are some questions RTEMS porters may have with our answers to
-them. While the focus here is on new ports and BSPs, we believe that
-the issues are similar for other RTEMS development efforts including
-student efforts to implement new algorithmic optimizations.
-
-''Our engineers understand our target environment better than anyone
-else, and we have a tight schedule. Why should we work with the RTEMS
-developers, when we can get the code out faster by whacking it out on our 
own?''
-
-You understand your target environment better than anyone else.
-However, the RTEMS developers understand RTEMS better than anyone
-else; furthermore, the RTEMS developers tend to have a wide breadth
-of experience across a large number of processors, boards, peripherals,
-and application domains. It has been our experience that few problems
-encountered in embedded systems development are unique to a particular
-processor or application. The vast majority of the time an issue that
-arises in one project has also shown up in other projects.
-
-The intimate knowledge of RTEMS internals as well as a wide breadth of
-embedded systems knowledge means that there is a good chance that at
-least one RTEMS developer has already addressed issues you are likely
-to face when doing your port, BSP, or application. The developers can
-help guide you towards a workable long term solution, possibly saving
-you significant time in your development cycle.
-
-If getting the sources into the official RTEMS distributions is one of
-your goals, then engaging other RTEMS developers early will also likely
-shorten your development time. By interacting as early as possible you
-are more likely to write code which can be easily accepted into the official
-sources when you are fin

[PATCH] MAINTAINERS: Remove Martin Galvan

[Sebastian Huber]

Remove Martin Galvan due to inactivity from the Write After Approval
list.
---
 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2732d773c4..68137a80d9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -48,7 +48,6 @@ Write After Approval
 
 Daniel Hellstrom   dan...@gaisler.com
 Ben Gras   b...@rtems.org
-Martin Galvan  martin.gal...@tallertechnologies.com
 Pavel Pisa pp...@pikron.com
 Christian Mauderer christian.maude...@embedded-brains.de
 
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] user: Document patch review process

[Sebastian Huber]

---
 images/user/patch-review.png  | Bin 0 -> 57130 bytes
 images/user/patch-review.puml |  44 +++
 user/support/contrib.rst  |  67 +-
 3 files changed, 97 insertions(+), 14 deletions(-)
 create mode 100644 images/user/patch-review.png
 create mode 100644 images/user/patch-review.puml

diff --git a/images/user/patch-review.png b/images/user/patch-review.png
new file mode 100644
index 
..eadb7735eeb907f4dfecd2bcdca9fe000388cf32
GIT binary patch
literal 57130
zcma%jbzGEN*S3n%A=1)aGJq&Cl%O;YAtl}23?QwfbPEVbgMxIofOJSmcQZ87{cVn(
z^PKm2-#@j
zW9-Uk0RCZyi>bj4Y;0XDjf~;9B#f+$?DgPAhE)14RHksaEtH+z)>6+J?r3ERF|e`1
z<=`W`b?eSMGbJ_n-{0T54Q}%$Dfv|sZ1UOtdW{82aRr>f2sZ9aW_z5h`=6zw@8dqp
zjp^18U$olNa(1%nm~|e3p)##!p>%KT)$#1lY$j#k7T-bh}x6o=Y;h0IqLO_Y<215k>YWO7y%s>#TrupVVOOaHLDb_;U=z
za>%tFVh{+u7q`e?R2ZS})5^#9$jZ=kt7$TqKh>vNj;vz#M>Wg+GiNL0C?ogI>3YO<
zYFFHCCXCAzQxu8Y&jdKF(C1Usaktahu+reD51!-+^>@w%upFWVGRvr_roU7-(OKwxGujB;R)6MJ^uP!8e}4O5n@n9>ZuU
zLh&1{TJ$V06x+$T=E6d@+Db`$XQD`QKx9Mm$;jfKN|=Yogk{doc8DWca#&!ePT(jfXHVWnL)^_;O@DGr%hS-J|6TNK7aqs)P(Z)o~xIM;Qez0nvr
z@Tr7ab8?D_Tb73fPp*AZudO)mb!)`g&UQf+<;o4bMQmwF(VWYja+eYvG}0OpF2?T7
zN%I7S9I4V*xg>4jwPoyj?~FYN)Ogqax_y7FoWSS)fYcKxAx&9%YtiTL61d6Yi;}+V
zCX0Jax)f1iHtdghKA2FpC?U@1tF*SI#3PAI%Gg{x9=GcSC49volC9z4i6?Hn%PBCW
z6JXL5Q)u6Nj$69ll%+>f7C1jCwo9}vZJUUS*&%Z4*4tZBFGQ5yXm2K?y}>*tZKt;u
zc~6V#NU1E599Z?hdFrRKRX
zS_i`SMMq~RVkDn*b{4s)qGG1brBo%ax2LD4uWyAtnCcOsJ(L=Er6-|-Bq`r=vV$h>v_$I+5-;r<`@A_HY
zQBhIx^z{5X@83R6)%%TlDLqceT-@M;jPIUOvo;#}eo~w)~o2!(0
zEQaz-O-+4(XmyQ|Juva@BSain-x7TY-U0EJg|ysBQBm>5ix=|p_ua|M`ZW~NOBXg`
zL%Lq4wJe784}{Fji~aR-|GQ<`F-d*l{pZZ?nQ(MD9SZl$teUhX>Em2Z3Y$!0W{
z*VoUlX~oXY&h*)=mV_iGSV$47wVoc?d=%41;L}9
z=%G8kG^9zoD%DT%M^Xx#Amh&Yl@vh%R;_CanuMM+D-_k0^6dTtKd?6>;Fdh#qMvWv
zFB`8hSm01+770iL
zd`X^W%0;=ds(#8QA*(#}sAe}?C1u%Nj5~bJoDXe5+QhU_dD41Ekb%oTYO3eF
z-{BCsR&1-=giLNNXPD$Z7Q~gjr
z8KN@7SN0|lEFTS&b*NjPts<6d25cnI5^f@ZEc{Z>*7ZfG=LOnbY6Wnq$fqf<-DeJm
zBlAk#y?eMAa|Z@3LU^!})H$Z5DYtLJ0(YsA`I6@xJZ1x9m}g(`Vd`F+`s!l`ejR3a
zX>JyNj5((YkH{r|irAUj{7|gh6$*bNj
z7^8j46x1LWJ0}Wb{FI`VTG(&r%nnCswcKAbZ+^#3n|inu!E~mt?CqBXaki!q_)^$!
z;z3=8+}gA6+%_NYkEHBWAB`6Vynhh7mjuSZYfi$p-AHlLB_McI4EeFGRDN-CG&|r5L
zhT~xZv$V97mJR~pwky3dwv))d=4+t6?W^!)>YsO8OYDnQ&(j>wSn-2E94sp<1HQ*H
zY=pt5)gVxP{p@-bVuARf^+;${upVC}>>d9_b8~Z4RMeA)Sh4FR;H`8@Ag1#N!lIRE
zW#;#ID$efn*mhi@nISK8Z~hn`*T&Qp%fgRo|I`m4J4<1qWHYT0MzPhTvB{6zc)!i5>M~gJ!}#uQ3#ZGo@`T8}y@q@Zo-dl?
z$Xh!zg3ViPzGyyikjr?Iu=i?1g*rr-FT@Kx_Iv$fS;jFbrY7p>VQ;U<03-9}
z#3F@0(%_EX!YMV(hVhi44{*S64tCK|QRTlVp`oEY4E6V_Lvwisi(}8`y=?MX^T42L(A#;g+nIQ<`i@^k!K)B=qHJy&KO|wZofVOY^8h%9JV9
z;S^t1d)*psbQqtohJ;R(cjr0p^m$!6ZvI-1S1-@i6R%L!%)wCAV_JgWIFpX7T}|V4
zWs85c?k#Q!#K(vt<+z*<^I^*bFXr^aVLztAQ`24Gtm
z9aP$7v`0`2#zz*JBL=fdO65v0+>bWl^{z*aR}aHJrQUDw;I~`ulAE4J;e4gwkrC$q
z42w@|Olr;k#8!2i7+!AtlHZt@k5B%DEIXB(g~eQJYht+4^7Z#A4civS8e0N?5De5h
z5WiaSb25@1HN9izO6&N*M#_m*)lyRzu)}2%h8Swc71E#j*z6+Ni=DA+NSS$Yr12y}
z7$+R3YU9r5@8k4bSR6zn9ZLNv?vFk97MM4c-d`c~Bx?;&s5T2J6g
z+uUKnFv$48o)U}g)C%b2v>TeQMWNH;juSKLVQ)|!0beMO0i?5seERo&Fn%j
zJA>!-rT)d*mSBKY_yc0cvz^8rLC>ke*QIAY9lN{3Ux&tFB_as|_J-`+#0oh?>*ALe
zrMa(iD*OG(pTiin@qq7kjv}rY4lza_w!T`j(J82rJfS8-)gw6&}i!1s*UMy7Sii41>J&
z;k>Du*l&+A73mX^P`GCsz2IjD1O0;H#)jYHAX?~G^>&M?(XT9MVb}XVE@N3Izqg;y
z)W#ibRdONYY(v%$n#Y)c6@rNLJ!f%iGO(}D3Rtp5h3XP~;VE@acbt3jOo>rO#C@A>
zVx<_Xi6>8&4lG8ozsY}Io-DUWlRt@JRb^n^h^OYUny#q=7Q$;i-;6`DPjh}`WjUOS
z_TlaN;myC;y#KPQm<*AM|d<@6VU&9<&~AXUN#Y3Hea(9laSdTP>n
z3skWUTB5>mBHoV28!Q~zF~&v-eqv}rx3Dnix&TTvS4fCFiBUM^N0Ml
zifKAjBdU4(Y
z(|xb?dx=qZX12dB@yzw%sI600x&~uSoafbRKb(-o_RAuO`%%PDVDnoLntnM#dD?WO
zI>Zm2`lff|HYCcQtcW>5em^PEZnlwWB02y^?prR1?|ZMk(H{~TCqpJYcV@79ESPJZ
zZFrn4g%6JUl3TDI{?r@o2;Qqdn0Dr}V{Z=mJ`EBjCd}WlCGkXBl-pnXIg@4>Y;)ST
zj)%QOFBx(M5kHdHJ}1IDG(1>qn5<++LsxIB`xfk2W9rsHPRYf`#|*4@y4V1bDfOI|
zW<)me=m&=5IBF#f&YpImQ?>it*iikWH`pO$utQOWzjtV0^nMT|0PFbQkEtLzu7{)x
ziYVn0FxAhxsPt;by5BATE7rs-gZ#6KyT<`t()CnAGQ^J>i2ci5R#xEqUi<0e{(pR?
znlJfR7swNw)&{@q2DdZ~5`r}?4*!-UGBTCJGBzYH2W-h4e=h9D(iiE(h)_?YnJ+WY0a1uk{_@6_Q{mNdQE
z1L4Q}=sFJZJ8pQdzH6IwcreqJ8a~;WINWlcC6_PIBr#d7h+}W(SoGVGSnBJZBz!(?
zOyh24*q{O59D~sozQNbh6#;&G69RxIHQLj+wPjz-)RS&c@d>#6vVCz-{+`)ohw5N2
z;e0L9b*An(LACsS!wSdjF~j5Fh59~uHH(ad*w|s7Sy>65l|J&>dN=;$cgM6P`{F3AGV%I|!U?&5C
z^?%=S#s7Fhasb<*@;z`XnfW^|d2Y#|$|d}L!ZEQV5DfxrW=sD}CiZ*HUphn2AM69C
zPlW~0h|Pv~^s!D64p?KfG;k}HwM?<;1M^m_dN!Y_iv1^EyC+|*rkt~?Rs@D0*E_Q#
zCT&b^(#F9oNwBqI%S>k$Bh}xP_%s-Eqlo+D&CJhkv3)A&ks1yrE1_rb-T8ObvrFNqJ
z;<-Kk@9leNe|F-f)71epAM3wO%c}DAtu==i4(*xei|x8PE6$%*4C!F+oYa0I(%Hm_
z)a0w}I9}`=h|PdR?RR-V?fqAIptmx=9`9}H<8H@<2*&obSBqzZlhKybs=3jMgm->aJs;OY(oIHD7+t}DB4DhU+?vG1oI${&Y
z15%d+s)Mk;OT4bZzAnAe4#al{`mik50s6
zMxIqEc)dtq!S>CsG~)^F&AA6kPQ*D%ES)!(L(|4Ti^j%LEVCcnYrWWCJb4`y1?zg+
zfbQ4);|Dtj2gjpFkC>UI@`itfKcU9yK-i;Xxw=an@0u5c7c}g4;Rl_r*5wchg%d2U
zW=P_op}iaO@%E;nq4{a&@xJc90-;8Oh#>t4M>dui|IE%AQwd
zTbY}jXrdC4*oiF&4mVJ`sjI6S8#7#U{B_xy6jqSpI6T~pcUN1zOr8?IRQf2{;7kHS
z4`p@pOr0XQlZJwV;y_tv`sCx+uaB-c8J2GICHMPi+!Ug*TI@#5Ib11k{m#h4US@{Is9-136@L+xx87Rg2
z>6MFI;VhE74Fk&~9>l;E(dbv{aJ2h>72Qe4zo3ujo*S8

Re: [PATCH] eng: Add Software Requirements Engineering chapter

[Sebastian Huber]

On 24/07/2019 15:44, Sebastian Huber wrote:

+Requirement Traceability
+
+
+The standard |E10-06| demands that requirements shall be under configuration
+management, backwards-traceable and forward-traceable.
+
+History of Requirements
+---
+
+The RTEMS requirements should placed in the RTEMS sources using Git for version
+control.  The history of requirements can be traced with Git.  Special commit
+procedures for changes in requirement files should be established.  For
+example, it should be allowed to change only one requirement per commit.  A
+dedicated Git commit message format may be used as well, e.g. use of
+``Approved-by:`` or ``Reviewed-by:`` lines which indicate an agreed statement
+(similar to the
+`Linux kernel patch submission 
guidelines`_).


In the first version of this patch, the proposal was to use Git to track 
the history of specification items (requirements are a specialization 
them). I think it would be better to add the revision and the 
description of a change directly to the files, e.g. add a custom 
attribute "changes" which contains a list of "revision" and 
"description" tuples.  Revision 1 items do not need this attribute. 
Example:


changes:
- description: The description of the change from revision 1 (initial) to 2.
  revision: 2
- description: The description of the change from revision 2 to 3.
  revision: 3
- description: The description of the change from revision 3 to 4.
  revision: 4

This information can be used to add the change log of each specification 
item to a human readable document for example.  The documentation 
generator program does not need a Git repository in this case to extract 
the information.


Also this way the revision of a specification item is independent of the 
current version control system. This makes it easier to reference items 
of a specific revision. For example: "With ABC-001 in revision 1 we 
could meet our system requirements, however the change to revision 2 is 
a problem, due to ...".


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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

How to build start.o using waf?

[Sebastian Huber]

Hello,

I would like to work on a new build system prototype. The idea is to use 
specification items maintained by Doorstop (YAML files), a Python 
configuration script and waf to build RTEMS and the tests. This is 
similar to the libbsd build. The difference is that in libbsd the build 
data is maintained directly in Python code (libbsd.py).


How do you build a singe object file (start.o) from assembly files in 
waf? An example would be great.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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

Re: [PATCH] eng: Add Software Requirements Engineering chapter

[Gedare Bloom]

On Mon, Sep 30, 2019 at 7:13 AM Sebastian Huber
 wrote:
>
> On 24/07/2019 15:44, Sebastian Huber wrote:
> > +Requirement Traceability
> > +
> > +
> > +The standard |E10-06| demands that requirements shall be under 
> > configuration
> > +management, backwards-traceable and forward-traceable.
> > +
> > +History of Requirements
> > +---
> > +
> > +The RTEMS requirements should placed in the RTEMS sources using Git for 
> > version
> > +control.  The history of requirements can be traced with Git.  Special 
> > commit
> > +procedures for changes in requirement files should be established.  For
> > +example, it should be allowed to change only one requirement per commit.  A
> > +dedicated Git commit message format may be used as well, e.g. use of
> > +``Approved-by:`` or ``Reviewed-by:`` lines which indicate an agreed 
> > statement
> > +(similar to the
> > +`Linux kernel patch submission 
> > guidelines`_).
>
> In the first version of this patch, the proposal was to use Git to track
> the history of specification items (requirements are a specialization
> them). I think it would be better to add the revision and the
> description of a change directly to the files, e.g. add a custom
> attribute "changes" which contains a list of "revision" and
> "description" tuples.  Revision 1 items do not need this attribute.
> Example:
>
> changes:
> - description: The description of the change from revision 1 (initial) to 2.
>revision: 2
> - description: The description of the change from revision 2 to 3.
>revision: 3
> - description: The description of the change from revision 3 to 4.
>revision: 4
>
> This information can be used to add the change log of each specification
> item to a human readable document for example.  The documentation
> generator program does not need a Git repository in this case to extract
> the information.
>
> Also this way the revision of a specification item is independent of the
> current version control system. This makes it easier to reference items
> of a specific revision. For example: "With ABC-001 in revision 1 we
> could meet our system requirements, however the change to revision 2 is
> a problem, due to ...".
>
It seems to be a matter whether one needs the revision history readily
available without digging through git. Your argument for referring to
revisions, and also to extract them without needing git, is reasonable
to me.  I suspect it should make the release process simpler..

> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user: Document patch review process

[Chris Johns]

On 30/9/19 10:45 pm, Sebastian Huber wrote:
> ---
>  images/user/patch-review.png  | Bin 0 -> 57130 bytes
>  images/user/patch-review.puml |  44 +++
>  user/support/contrib.rst  |  67 
> +-
>  3 files changed, 97 insertions(+), 14 deletions(-)
>  create mode 100644 images/user/patch-review.png
>  create mode 100644 images/user/patch-review.puml
> 

If you want to review the figure it is ...

http://www.plantuml.com/plantuml/png/dP0_ZzDC4CRx_HGZwoqIlSf9K8Q28451ST7f3WgaD7lsutZ1EsjcnuxoxLcFWt9790gAbNR-_6QUUNPPlUWOU-VivzpsWuZd8-YSHg6wc_-P0X_OCy7dCsaYmHHm8i_DWUlKGS1AWzUwemm9oE_AeCyyfH_OKbKTWrAR97hTM5DLpVKdS4FQuHKuJsymeT-98kQx9CSPlMnSCANztFQsHASkzA3LerKXkR2ng7gX-sR3-pM5JAjlo6j7jFsOh4FmSmo2AsbJ15v1dXYdFyyhwDUXcSjrYZ4eHUJiZQph94tWOt-slhyOGPk9_jkR7IQb7YDOJT1l7QsaI1CaXyJBtNlwdzuS-DLfxMo3RnLYoMgpsLJK1uPDDi-khEN-pVx2N2pVfxLpeQNLmqlyvEr-38g6diyN3b9SdtVnrVU7CNStwm-iQKbA-evQIJ2a73J9OYKd1KauTbe2elinAps3ciIOjtcszEENJ_TF57rWBGzoLxBWncY7FY_gpV6GQo-tDjYXeNKkQngSsvLeZFql

> diff --git a/images/user/patch-review.puml b/images/user/patch-review.puml
> new file mode 100644
> index 000..4bfbe9f
> --- /dev/null
> +++ b/images/user/patch-review.puml
> @@ -0,0 +1,44 @@
> +' SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +' Copyright (C) 2019 embedded brains GmbH
> +
> +@startuml
> +
> +start
> +
> +:Arrange your changes in\nan easy to review and\ncoherent patch series;
> +
> +:Invoke: ""git format-patch"";
> +
> +:Send the patch series to devel@rtems.org for review;
> +
> +:Set N to 2;
> +
> +while (Reviewers demand changes in the patch series?) is (Yes)
> +  :Do the required changes and create a new patch series;
> +
> +  :Update commit messages accordingly;
> +
> +  :Invoke: ""git format-patch -v $N"";
> +
> +  :Document the changes from version N to N + 1\nin the patch file after the 
> "---" line;
> +
> +  :Set N to N + 1;
> +
> +  :Send the patch series to devel@rtems.org for review;
> +endwhile (No)
> +
> +if (Patch series was accepted by reviewers?) then (Yes)
> +  :Push the patch series\nto the project repository;
> +
> +  note right
> +Must be done by an
> +RTEMS maintainer.
> +  end note
> +else (No)
> +  :Discard the patch series;
> +endif
> +
> +stop
> +
> +@enduml
> diff --git a/user/support/contrib.rst b/user/support/contrib.rst
> index 79d70a0..a57900d 100644
> --- a/user/support/contrib.rst
> +++ b/user/support/contrib.rst
> @@ -12,11 +12,6 @@
>  Contributing
>  
>  
> -Developers can find help and support on the :r:list:`devel`.
> -
> -Technical documents including design, :r:url:`gsoc`, :r:url:`socis` can be
> -found on the :r:url:`devel`.
> -
>  How to Contribute?
>  ==
>  
> @@ -42,8 +37,10 @@ You can contribute to the RTEMS Project in various ways, 
> for example:
>  * RTEMS Tools improvements
>  
>  Most contributions will end up in patches of the RTEMS source code or
> -documentation sources.  The patch integration in the RTEMS repositories is 
> done
> -through a patch review process on the :r:list:`devel`.
> +documentation sources.  The patch integration into the RTEMS repositories is
> +done through a
> +:ref:`patch review process `
> +on the :r:list:`devel`.
>  
>  Preparing and Sending Patches
>  =
> @@ -51,15 +48,17 @@ Preparing and Sending Patches
>  The RTEMS Project uses Git for version control.  Git has a special command to
>  prepare patches intended for mailing lists:
>  `git format-patch `_.
> -Create logically connected patches as a patch set ideally accompanied by a 
> cover
> -letter (``--cover-letter`` option).  You can send patches via email through a
> -Git command:
> +Create logically connected patches as a patch series ideally accompanied by a
> +cover letter (``--cover-letter`` option).  You can send patches via email
> +through a Git command:
>  `git send-email `_.
>  
> -Checklist for a Patch
> +.. _ChecklistForPatches:
> +
> +Checklist for Patches
>  =
>  
> -Check the following items before you send a patch to :r:list:`devel`:
> +Check the following items before you send a patch to the :r:list:`devel`:
>  
>  * The author name of the patch is your full name.
>  
> @@ -72,12 +71,52 @@ Check the following items before you send a patch to 
> :r:list:`devel`:
>contribute it under the
>`BSD-2-Clause `_
>license.  For documentation use
> -  `CC BY-SA 4.0  +  `CC BY-SA 4.0 `_.
> +
> +* Make sure you have a pregnant subject which does not exceed 50 characters 
> in
> +  one line.  Use a "topic: The pregnant subject" style.  A topic could be the
> +  main component of patch.  Just have a look at existing commit messages.
> +
> +* The patch has a good commit message.  It should describe the reason

Re: [PATCH] user: Document patch review process

[Sebastian Huber]

On 01/10/2019 01:40, Chris Johns wrote:

On 30/9/19 10:45 pm, Sebastian Huber wrote:

---
  images/user/patch-review.png  | Bin 0 -> 57130 bytes
  images/user/patch-review.puml |  44 +++
  user/support/contrib.rst  |  67 +-
  3 files changed, 97 insertions(+), 14 deletions(-)
  create mode 100644 images/user/patch-review.png
  create mode 100644 images/user/patch-review.puml



If you want to review the figure it is ...

http://www.plantuml.com/plantuml/png/dP0_ZzDC4CRx_HGZwoqIlSf9K8Q28451ST7f3WgaD7lsutZ1EsjcnuxoxLcFWt9790gAbNR-_6QUUNPPlUWOU-VivzpsWuZd8-YSHg6wc_-P0X_OCy7dCsaYmHHm8i_DWUlKGS1AWzUwemm9oE_AeCyyfH_OKbKTWrAR97hTM5DLpVKdS4FQuHKuJsymeT-98kQx9CSPlMnSCANztFQsHASkzA3LerKXkR2ng7gX-sR3-pM5JAjlo6j7jFsOh4FmSmo2AsbJ15v1dXYdFyyhwDUXcSjrYZ4eHUJiZQph94tWOt-slhyOGPk9_jkR7IQb7YDOJT1l7QsaI1CaXyJBtNlwdzuS-DLfxMo3RnLYoMgpsLJK1uPDDi-khEN-pVx2N2pVfxLpeQNLmqlyvEr-38g6diyN3b9SdtVnrVU7CNStwm-iQKbA-evQIJ2a73J9OYKd1KauTbe2elinAps3ciIOjtcszEENJ_TF57rWBGzoLxBWncY7FY_gpV6GQo-tDjYXeNKkQngSsvLeZFql


Nice, you can use it for new images here:

http://www.plantuml.com/plantuml/uml/SyfFKj2rKt3CoKnELR1Io4ZDoSa7

[...]

+* The patch builds.  All RTEMS tests link with this patch.
+
+* The patch does not introduce new compiler warnings.


This step is not in the figure.


You mean there should be a step mentioning this checklist?



Built against which BSPs?


This is for the user manual. I think at least one arbitrary BSP which is 
affected by the patch should be sufficient.





+* The patch does not introduce new test failures in existing tests.


This step is not in the figure.

Again which BSPs? This assumes expected fails are valid for the bsps being 
tested.


I think we should not add to many details to the figure.



What about tickets and the "Closes ...", "Updates ..." etc tags?


Yes, this is missing. What should be checked as well?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
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] bsp/erc32: Improve pseudo-SMP support

[Sebastian Huber]

Add support for _SMP_Send_message() to the own processor.  This is
required by the smpmulticast01 test program.
---
 bsps/sparc/erc32/start/bspsmp.c  | 84 
 c/src/lib/libbsp/sparc/erc32/Makefile.am |  3 +-
 2 files changed, 85 insertions(+), 2 deletions(-)
 create mode 100644 bsps/sparc/erc32/start/bspsmp.c

diff --git a/bsps/sparc/erc32/start/bspsmp.c b/bsps/sparc/erc32/start/bspsmp.c
new file mode 100644
index 00..35ed2bd0d0
--- /dev/null
+++ b/bsps/sparc/erc32/start/bspsmp.c
@@ -0,0 +1,84 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define IPI_VECTOR SPARC_SYNCHRONOUS_TRAP( 0x90 )
+
+uint32_t _CPU_SMP_Get_current_processor( void )
+{
+  return 0;
+}
+
+uint32_t _CPU_SMP_Initialize( void )
+{
+  return 1;
+}
+
+bool _CPU_SMP_Start_processor( uint32_t cpu_index )
+{
+  (void) cpu_index;
+  return true;
+}
+
+void _CPU_SMP_Finalize_initialization( uint32_t cpu_count )
+{
+  _Assert( cpu_count == 1 );
+  (void) cpu_count;
+}
+
+void _CPU_SMP_Prepare_start_multitasking( void )
+{
+}
+
+void _CPU_SMP_Send_interrupt( uint32_t target_processor_index )
+{
+  _Assert( target_processor_index == 0 );
+  (void) target_processor_index;
+  __asm__ volatile( "ta 0x10; nop " );
+}
+
+static rtems_isr bsp_inter_processor_interrupt(
+  rtems_vector_number vector
+)
+{
+  _SMP_Inter_processor_interrupt_handler( _Per_CPU_Get() );
+}
+
+static void erc32_install_inter_processor_interrupt( void )
+{
+  set_vector( bsp_inter_processor_interrupt, IPI_VECTOR, 1 );
+}
+
+RTEMS_SYSINIT_ITEM(
+  erc32_install_inter_processor_interrupt,
+  RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+  RTEMS_SYSINIT_ORDER_LAST
+);
diff --git a/c/src/lib/libbsp/sparc/erc32/Makefile.am 
b/c/src/lib/libbsp/sparc/erc32/Makefile.am
index 994e55cc40..8cdd4581bf 100644
--- a/c/src/lib/libbsp/sparc/erc32/Makefile.am
+++ b/c/src/lib/libbsp/sparc/erc32/Makefile.am
@@ -55,8 +55,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/sparc/shared/irq/bsp_isr_handler
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/irq/irq-default-handler.c
 
 if HAS_SMP
-librtemsbsp_a_SOURCES += ../../../../../../bsps/shared/start/bspsmp-dummy.c
-librtemsbsp_a_SOURCES += 
../../../../../../bsps/shared/start/getcurrentprocessor-zero.c
+librtemsbsp_a_SOURCES += ../../../../../../bsps/sparc/erc32/start/bspsmp.c
 endif
 
 if HAS_NETWORKING
-- 
2.16.4

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel