Re: [PATCH v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Gedare Bloom 
On Fri, Jul 19, 2019 at 7:27 PM Chris Johns  wrote:
>
> On 20/7/19 6:41 am, Gedare Bloom wrote:
> > On Fri, Jul 19, 2019 at 11:02 AM Christian Mauderer  
> > wrote:
> >>
> >> On 19/07/2019 18:21, Gedare Bloom wrote:
> >>> Looks good to me. I'm currently not able to apply it, verify the doc
> >>> build, and push it though. (Workstation issues.)
> >>>
> >>
> >> I agree that it looks OK. Thanks from me too for contributing to the
> >> documentation. It's something that most developers don't like to do
> >> therefore it's really great that you wrote that.
>
> Pushed.
>
> >>
> >> I didn't find any bugs in the instructions while reading through it. I
> >> can create a PDF out of it on my Arch Linux machine so I think it should
> >> be OK to merge it.
> >>
> >> You have tried quite a bit till you get an overlay working. If you feel
> >> like writing some more documentation, it might would be a good addition
> >> to add some notes regarding that too. I think this patch is fine as it
> >> is so if you add something please create a second patch.
> >>
> >> @Gedare: I don't touch the docs repo that often: Is there some defined
> >> test process before a commit is added? Or is building a PDF on some
> >> random machine enough?
> >>
> > I don't think the process is well-defined for the docs. However, if
> > you built the PDF and it looks good (can you build HTML too?) then go
> > ahead and push it.
>
> HTML is the default and always built. You need install to get a suitable
> directory tree to review with a `file://` URL. Details are here but 
> nothing
> is specifically said about HTML being always built:
>
> https://git.rtems.org/rtems-docs/tree/README.txt#n336
>
> The rules are not defined and maybe they should be.
>
> 1. HTML is always built and must build. Checking HTML is a requirement for
> posting a patch for review.
>
> 2. PDF is optional because the latex support is not consistent across all 
> build
> hosts.
>
> 3. Please check the automatically built docs after a push to make sure all
> formats look suitable. Post a follow up patch if adjustments are needed.
>
> Comments?
>
Good rules. If you get a chance please add them to the README for now.
#1 should be for contributors, #3 is for Maintainers. #2 is optional.
:)

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

Re: Build failed for RTEMS Source Builder

2019-07-19 Thread Chris Johns 
On 20/7/19 4:48 am, Vijay Kumar Banerjee wrote:
> On Sat, Jul 20, 2019, 12:03 AM Himanshu Sekhar Nayak
> mailto:himanshuwindows...@gmail.com>> wrote:
> 
> Hi Chris,
> 
> After your solution, I changed the required source directories

Great. Are you able to please post the patch?

> but seems
> like idk why it needs sudo privileges ?
> 
> https://paste.ofcode.org/38mtbHLLH9WggmRkXWZDq4r
> 
> The path /opt/ requires root privilege.
> You can change it to something like 
> $HOME/myrtems/dir/ in your --prefix

Yes or you can create /opt/rtems and set the permissions onto allow you as as
user to install the tools.

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

Re: GSoC Linux UIO driver for PRU

2019-07-19 Thread Chris Johns 
On 19/7/19 8:32 pm, Nils Hölscher wrote:
> I am currently adding more and more libbsd deps to my build, that are not in
> rtems or rtems-libbsd.
> Now I have been touching these to files of the BSD kernel:
> https://github.com/freebsd/freebsd/blob/0966ce5cd477cd7c8b63b0f9de75396aa5939032/sys/arm/include/cpu-v4.h
> https://github.com/freebsd/freebsd/blob/0966ce5cd477cd7c8b63b0f9de75396aa5939032/sys/arm/include/atomic-v6.h
> Throwing a good dozen of warning when compiling and I only need one call from
> these files.
> This is needed in the pru driver to distinguish between prussv1 and prussv2, a
> feature I definitely want.
> FYI: prussv1 is on the TI Sitara AM18xx SoCs and v2 on the AM35xx.
> 
> So the question is should I try to resolve those warnings and try to port the
> whole files to rtems or should I try to just pick  what I need and be done?
> 

What are the warnings?

Do you have the libbsd changes in a repo somewhere so I can have a look?


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

Re: [PATCH v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Chris Johns 
On 20/7/19 6:41 am, Gedare Bloom wrote:
> On Fri, Jul 19, 2019 at 11:02 AM Christian Mauderer  
> wrote:
>>
>> On 19/07/2019 18:21, Gedare Bloom wrote:
>>> Looks good to me. I'm currently not able to apply it, verify the doc
>>> build, and push it though. (Workstation issues.)
>>>
>>
>> I agree that it looks OK. Thanks from me too for contributing to the
>> documentation. It's something that most developers don't like to do
>> therefore it's really great that you wrote that.

Pushed.

>>
>> I didn't find any bugs in the instructions while reading through it. I
>> can create a PDF out of it on my Arch Linux machine so I think it should
>> be OK to merge it.
>>
>> You have tried quite a bit till you get an overlay working. If you feel
>> like writing some more documentation, it might would be a good addition
>> to add some notes regarding that too. I think this patch is fine as it
>> is so if you add something please create a second patch.
>>
>> @Gedare: I don't touch the docs repo that often: Is there some defined
>> test process before a commit is added? Or is building a PDF on some
>> random machine enough?
>>
> I don't think the process is well-defined for the docs. However, if
> you built the PDF and it looks good (can you build HTML too?) then go
> ahead and push it.

HTML is the default and always built. You need install to get a suitable
directory tree to review with a `file://` URL. Details are here but nothing
is specifically said about HTML being always built:

https://git.rtems.org/rtems-docs/tree/README.txt#n336

The rules are not defined and maybe they should be.

1. HTML is always built and must build. Checking HTML is a requirement for
posting a patch for review.

2. PDF is optional because the latex support is not consistent across all build
hosts.

3. Please check the automatically built docs after a push to make sure all
formats look suitable. Post a follow up patch if adjustments are needed.

Comments?

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

Re: GSoC Project | Basic Support for Trace Compass

2019-07-19 Thread Ravindra Kumar Meena 
>
> This looks very nice.
>
> The next step is to translate the record items into corresponding events
> of LTTNG. We should start with the following event which I guess is used
> by Trace Compass for the task switch view. I don't know it, we have to
> try it out. We can also look at the analyses package from LTTNG instead
> of Trace Compass:
>
> https://github.com/lttng/lttng-analyses
>
> event {
> name = "sched_switch";
> id = 22;
> stream_id = 0;
> fields := struct {
> integer { size = 8; align = 8; signed = 0; encoding =
> UTF8; base = 10;
> } _prev_comm[16];
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_tid;
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_prio;
> integer { size = 64; align = 8; signed = 1; encoding =
> none; base =
> 10; } _prev_state;
> integer { size = 8; align = 8; signed = 0; encoding =
> UTF8; base = 10;
> } _next_comm[16];
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _next_tid;
> integer { size = 32; align = 8; signed = 1; encoding =
> none; base =
> 10; } _next_prio;
> };
> };
>
Okay. We need to have the values of event fields in client-side. What
values should I pass there?


-- 
*Ravindra Kumar Meena*,
B. Tech. Computer Science and Engineering,
Indian Institute of Technology (Indian School of Mines)
, Dhanbad
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Docs Style Guide

2019-07-19 Thread Chris Johns 


> On 19 Jul 2019, at 3:09 pm, Sebastian Huber 
>  wrote:
> 
>> On 19/07/2019 00:23, Gedare Bloom wrote:
>>> On Thu, Jul 18, 2019 at 11:35 AM Chris Johns  wrote:
 On 19/7/19 1:32 am, Gedare Bloom wrote:
 Reviewing the BB doc patch, I realized that we need a style guide for
 writing docs [1].
>>> Thank you for raising this.
>>> 
 We should start to collect Documentation Style notes in a wiki page,
 and then push it to the docs [1]. If anyone has some initial set of
 thoughts, it would be good to put them down in reply to this email.
>>> We do havehttps://git.rtems.org/rtems-docs/tree/README.txt#n393.
>>> 
>> Would it be OK if we refactor the README to move some of this to the
>> SwE document, and link/reference to it from the README?
> 
> I had this also on my TODO list, the Sphinx guide should move to the SwE and 
> a reference to it should be added to the README.

+1


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

Re: GSoC Project | Basic Support for Trace Compass

2019-07-19 Thread Sebastian Huber 



On 19/07/2019 08:38, Ravindra Kumar Meena wrote:

This looks very nice.

The next step is to translate the record items into corresponding
events
of LTTNG. We should start with the following event which I guess is
used
by Trace Compass for the task switch view. I don't know it, we have to
try it out. We can also look at the analyses package from LTTNG instead
of Trace Compass:

https://github.com/lttng/lttng-analyses

event {
         name = "sched_switch";
         id = 22;
         stream_id = 0;
         fields := struct {
                 integer { size = 8; align = 8; signed = 0; encoding
= UTF8; base = 10;
} _prev_comm[16];
                 integer { size = 32; align = 8; signed = 1;
encoding = none; base =
10; } _prev_tid;
                 integer { size = 32; align = 8; signed = 1;
encoding = none; base =
10; } _prev_prio;
                 integer { size = 64; align = 8; signed = 1;
encoding = none; base =
10; } _prev_state;
                 integer { size = 8; align = 8; signed = 0; encoding
= UTF8; base = 10;
} _next_comm[16];
                 integer { size = 32; align = 8; signed = 1;
encoding = none; base =
10; } _next_tid;
                 integer { size = 32; align = 8; signed = 1;
encoding = none; base =
10; } _next_prio;
         };
};

Okay. We need to have the values of event fields in client-side. What 
values should I pass there?


Please figure out what values are possible for the state field.

You need the RTEMS_RECORD_THREAD_SWITCH_IN and 
RTEMS_RECORD_THREAD_SWITCH_OUT records to generate a sched_switch event.


For the comm fields just convert the record.data into a string. For the 
tid fields use the record.data.


Set the priority fields to zero.

--
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] Makefile.inc: Add support for staged builds.

2019-07-19 Thread chrisj 
From: Chris Johns 

- Allow the RTEMS_ROOT to be conditionally supplied. This
  can be a staging area before being moved to the final
  install prefix location.

- Update the default.cfg to use RTEMS_ROOT and to not rely on
  the exec_prefix so it's paths can be staged.

- Fix and add the needed configure subs.

Closes #3768
---
 c/src/make/Makefile.am |  3 ++-
 c/src/make/Makefile.inc.in | 13 -
 make/custom/default.cfg|  6 --
 make/main.cfg  |  8 
 4 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/c/src/make/Makefile.am b/c/src/make/Makefile.am
index 44350e94fd..2c630d9a78 100644
--- a/c/src/make/Makefile.am
+++ b/c/src/make/Makefile.am
@@ -68,6 +68,8 @@ Makefile.inc: Makefile.inc.in Makefile
-e "s|[@]exec_prefix[@]|$(exec_prefix)|" \
-e "s|[@]pkgdatadir[@]|$(pkgdatadir)|" \
-e "s|[@]RTEMS_BSP[@]|$(RTEMS_BSP)|" \
+   -e "s|[@]RTEMS_CPU[@]|$(RTEMS_CPU)|" \
+   -e "s|[@]RTEMS_API[@]|$(RTEMS_API)|" \
-e "s|[@]CC[@]|$(CC)|" \
-e "s|[@]CXX[@]|$(CXX)|" \
-e "s|[@]AS[@]|$(AS)|" \
@@ -85,4 +87,3 @@ CLEANFILES += Makefile.inc
 ## use gcc-target-default.cfg only.
 rtems_make_compilersdir = $(rtems_makedir)/compilers
 dist_rtems_make_compilers_DATA = compilers/gcc-target-default.cfg
-
diff --git a/c/src/make/Makefile.inc.in b/c/src/make/Makefile.inc.in
index bb37676987..d3df7a3b98 100644
--- a/c/src/make/Makefile.inc.in
+++ b/c/src/make/Makefile.inc.in
@@ -1,7 +1,13 @@
 #
 # BSP specific settings. To be included in application Makefiles
 #
+# This support will be removed from RTEMS. Please consider other
+# ways to build applications.
+#
+
+RTEMS_API = @RTEMS_API@
 
+RTEMS_CPU = @RTEMS_CPU@
 RTEMS_BSP = @RTEMS_BSP@
 
 prefix = @prefix@
@@ -16,8 +22,6 @@ LD_FOR_TARGET = @LD@
 SIZE_FOR_TARGET = @SIZE@
 OBJCOPY_FOR_TARGET = @OBJCOPY@
 
-RTEMS_API = @RTEMS_API@
-
 CC= $(CC_FOR_TARGET)
 CXX= $(CXX_FOR_TARGET)
 AS= $(AS_FOR_TARGET)
@@ -36,10 +40,10 @@ export AR
 export SIZE
 export OBJCOPY
 
-RTEMS_ROOT = $(prefix)
+RTEMS_ROOT  ?= $(prefix)
 PROJECT_ROOT = $(RTEMS_ROOT)
 RTEMS_CUSTOM = $(RTEMS_ROOT)/make/custom/$(RTEMS_BSP).cfg
-RTEMS_SHARE = $(RTEMS_ROOT)/share/rtems$(RTEMS_API)
+RTEMS_SHARE  = $(RTEMS_ROOT)/share/rtems$(RTEMS_API)
 
 RTEMS_USE_OWN_PDIR = no
 RTEMS_HAS_POSIX_API = @RTEMS_HAS_POSIX_API@
@@ -49,4 +53,3 @@ RTEMS_HAS_CPLUSPLUS = @RTEMS_HAS_CPLUSPLUS@
 export RTEMS_BSP
 export RTEMS_CUSTOM
 export PROJECT_ROOT
-
diff --git a/make/custom/default.cfg b/make/custom/default.cfg
index bbe8e05e07..96bb9afb5e 100644
--- a/make/custom/default.cfg
+++ b/make/custom/default.cfg
@@ -5,11 +5,13 @@
 # Created by Jiri Gaisler, 16-03-97  (who is owed a debt of gratitude
 #   for the initial RTEMS autoconf support.  Thanks. --joel)
 
-include $(exec_prefix)/$(RTEMS_BSP)/make/target.cfg
+RTEMS_TARGET = $(RTEMS_CPU)-rtems$(RTEMS_API)
+
+include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/target.cfg
 include $(RTEMS_SHARE)/make/host.cfg
 
 include $(RTEMS_ROOT)/make/main.cfg
-include $(exec_prefix)/$(RTEMS_BSP)/make/bsp.cfg
+include $(RTEMS_ROOT)/$(RTEMS_TARGET)/$(RTEMS_BSP)/make/bsp.cfg
 
 ## Target compiler config file, if any
 CONFIG.CC = $(RTEMS_SHARE)/make/compilers/gcc-target-default.cfg
diff --git a/make/main.cfg b/make/main.cfg
index 1a712deb3e..285e1b9a84 100644
--- a/make/main.cfg
+++ b/make/main.cfg
@@ -16,9 +16,9 @@ default_target: all
 # but could be overridden in custom files.
 #
 
-PROJECT_RELEASE=$(exec_prefix)/$(RTEMS_BSP)
-PROJECT_BIN=$(PROJECT_ROOT)/bin
-PROJECT_INCLUDE=$(PROJECT_RELEASE)/lib/include
+PROJECT_RELEASE ?= $(exec_prefix)/$(RTEMS_BSP)
+PROJECT_BIN = $(PROJECT_ROOT)/bin
+PROJECT_INCLUDE = $(PROJECT_RELEASE)/lib/include
 PROJECT_TOOLS = $(PROJECT_RELEASE)/build-tools
 
 ## translate VARIANT into VARIANT_V
@@ -77,6 +77,6 @@ clean-generic:
-$(RM) -r $(CLEAN_ADDITIONS)
 endif
 
-.PHONY:$(RECURSE_TARGETS) 
+.PHONY:$(RECURSE_TARGETS)
 .PHONY: clean-generic
 .PHONY: distclean-generic
-- 
2.19.1

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

[PATCH v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Vijay Kumar Banerjee 
---
 user/bsps/arm/beagle.rst | 110 ++-
 1 file changed, 108 insertions(+), 2 deletions(-)

diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
index a36efde..eb4ecfb 100644
--- a/user/bsps/arm/beagle.rst
+++ b/user/bsps/arm/beagle.rst
@@ -1,8 +1,114 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2019 TBD
+.. Copyright (C) 2019 Vijay Kumar Banerjee
 
 beagle
 ==
 
-TODO.
+This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
+`beaglebonewhite` and `beagleboneblack`. The basic hardware initialization is
+not performed by the BSP.  A boot loader with device tree support must be used
+to start the BSP, e.g., U-Boot.
+
+TODO(These drivers are present but not documented yet):
+
+ *  Clock driver.
+ *  Network Interface Driver.
+ *  SDcard driver.
+ *  GPIO Driver.
+ *  Console driver.
+ *  PWM Driver.
+ *  RTC driver.
+
+Boot via U-Boot
+---
+To boot via uboot, the ELF must be converted to a U-Boot image like below:
+
+.. code-block:: none
+
+arm-rtems5-objcopy hello.exe -O app.bin
+gzip 9 app.bin
+mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
app.bin.gz rtems-app.img
+
+Getting the Device Tree Blob
+
+
+The Device Tree Blob (DTB) is needed to load the device tree while starting up
+the kernel. We build the dtb from the FreeBSD source matching the commit hash
+from the libbsd HEAD of freebsd-org. For example if the HEAD is at
+"19a6ceb89dbacf74697d493e48c388767126d418"
+Then the right Device Tree Source (DTS) file is:
+https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
+
+.. code-block:: shell
+   :linenos:
+
+ #building the dtb
+ #We will use the script from 
https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
+
+ #The make_dtb.sh script uses environment variable MACHINE
+ export MACHINE='arm'
+
+ SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
+
+ #The arguments to the script are
+ # $1 -> Build Tree
+ # $2 -> DTS source file
+ # $3 -> output path of the DTB file
+
+ ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
+ ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
+ $(pwd)
+
+Writing the uEnv.txt file
+-
+
+The uEnv.txt file is needed to set any environment variable before the kernel 
is
+loaded. Each line is a u-boot command that the uboot will execute during start
+up.
+
+Add the following to a file named uEnv.txt:
+
+.. code-block:: none
+
+ setenv bootdelay 5
+ uenvcmd=run boot
+ boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
+
+I2C Driver
+--
+
+For registering the `/dev/i2c-0` device, a wrapper function is provided,
+``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
+``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and `i2c-2`.
+
+For registering an I2C device with a custom path (say `/dev/i2c-3`) the
+function ``am335x_i2c_bus_register()`` has to be used.
+
+The function prototype is given below:
+
+.. code-block:: C
+
+   int am335x_i2c_bus_register(
+   const char *bus_path,
+   uintptr_t   register_base,
+   uint32_tinput_clock,
+   rtems_vector_number irq
+   );
+
+SPI Driver
+--
+
+The SPI device `/dev/spi-0` can be registered with ``bbb_register_spi_0()``
+
+For registering with a custom path, the ``bsp_register_spi()`` can be used.
+
+The function prototype is given below:
+
+.. code-block:: C
+
+rtems_status_code bsp_register_spi(
+   const char *bus_path,
+   uintptr_t   register_base,
+   rtems_vector_number irq
+);
-- 
2.20.1

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

Re: [PATCH] user/bsps : Add documentation for Beagle

2019-07-19 Thread Vijay Kumar Banerjee 
On Thu, Jul 18, 2019 at 9:07 PM Gedare Bloom  wrote:

> On Thu, Jul 18, 2019 at 8:24 AM Vijay Kumar Banerjee
>  wrote:
> >
> > ---
> >  user/bsps/arm/beagle.rst | 91 +++-
> >  1 file changed, 89 insertions(+), 2 deletions(-)
> >
> > diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
> > index a36efde..84bfe2d 100644
> > --- a/user/bsps/arm/beagle.rst
> > +++ b/user/bsps/arm/beagle.rst
> > @@ -1,8 +1,95 @@
> >  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >
> > -.. Copyright (C) 2019 TBD
> > +.. Copyright (C) 2019 Vijay Kumar Banerjee
> >
> >  beagle
> >  ==
> >
> > -TODO.
> > +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
> `beaglebonewhite`
>
> Hi,


> We need a style guide for writing docs. I will send in separate email
> though I wondered if we should set a maximum line length/line breaks
> at 80 char as with code?
>
> Thanks for the review. I have fixed the issues you mentioned below and also
set the line length to 80 characters. I rewrote those areas to make it more
clear
to the reader. Here's the v2 of the patch :
https://lists.rtems.org/pipermail/devel/2019-July/026712.html

> > +and `beagleboneblack`. The basic hardware initialization is not
> performed by
> > +the BSP.  A boot loader with device tree support must be used to start
> the BSP,
> > +e.g. U-Boot.
> There is always a comma after e.g.
>
> > +
> > +TODO(These drivers are present but not documented yet):
> > +
> > + *  Clock driver.
> > + *  Network Interface Driver.
> > + *  SDcard driver.
> > + *  GPIO Driver.
> > + *  Console driver.
> > + *  PWM Driver.
> > + *  RTC driver.
> > +
> > +Boot via U-Boot
> > +---
> > +To boot via uboot, the ELF must be converted to a U-Boot image like
> below:
> > +
> > +.. code-block:: none
> > +
> > +arm-rtems5-objcopy hello.exe -O app.bin
> > +gzip 9 app.bin
> > +mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n
> RTEMS -d app.bin.gz rtems-app.img
> > +
> > +Getting the Device Tree Blob
> > +
> > +
> > +The Device Tree Blob(dtb) is needed to load the device tree while
> starting up
> We (American, British) normally put a space before parentheticals such
> as defining an acronym, like "Blob (dtb)".
>
> > +the kernel. We build the dtb from the FreeBSD source matching the
> commit hash
> > +from the libbsd HEAD of freebsd-org. For example if the HEAD is at
> > +"19a6ceb89dbacf74697d493e48c388767126d418"
> > +Then the right dts file is:
> dts should be mentioned before this
>
> > +
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
> > +
> > +.. code-block:: none
> > +
> > + #building the dtb
> > + #We will use the script from
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
> > +
> > + export MACHINE='arm' #The make_dtb.sh script uses environment
> variable MACHINE
> > + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> > + #The arguments to the script are
> > + # $1 -> Build Tree
> > + # $2 -> DTS source file
> > + # $3 -> output path of the DTB file
> > + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
> > + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
> > + $(pwd)
> > +Writing the uEnv.txt file
> > +-
> > +
> > +The uEnv.txt file is needed to set any environment variable before the
> kernel is
> > +loaded. Each line is a u-boot command that the uboot will execute during
> > +starting up.
> "during starting" is awkward, try "during start up" or "while starting up"
>
> > +
> > +Add the following to a file named uEnv.txt:
> > +
> > +.. code-block:: none
> > +
> > + setenv bootdelay 5
> > + uenvcmd=run boot
> > + boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0
> 0x8800 am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
> > +
> > +I2C Driver
> > +--
> > +
> > +This BSP uses the I2C framework and is registered using
> > +``am335x_i2c_bus_register()`` the function prototype is given below:
> > +
> > +.. code-block:: C
> > +
> > +   int am335x_i2c_bus_register(
> > +   const char *bus_path,
> > +   uintptr_t   register_base,
> > +   uint32_tinput_clock,
> > +   rtems_vector_number irq
> > +   );
> > +
> > +This function is needed only while registering with custom path with
> custom
> This "registering with custom path" is awkward, maybe it needs
> "registering with a custom path"
>
> > +values. For registering the `/dev/i2c-0` device, a wrapper function is
> provided,
> > +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> > +``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and
> `i2c-2`.
> > +
> > +SPI Driver
> > +--
> > +
> > +The SPI device `/dev/spi-0` can be registered with
> ``bbb_register_spi_0()```
> > --
> Thanks for contributing documentation!
>
> > 2.20.1
> >

Coverity Model

2019-07-19 Thread Sebastian Huber 

Hello,

you can add a model file to Coverity to reduce the false positive rate 
of the static analysis. I didn't check that the RTEMS scan can profit 
from this since we already supply a lot of code to the scan. What I 
found interesting is that Qemu uses this:


https://github.com/qemu/qemu/blob/master/scripts/coverity-model.c

There is a comment in it:

" * The model file must be uploaded by an admin in the analysis settings of
 * http://scan.coverity.com/projects/378;

So, it seems the open source project scan is (or at least was) 
customizable. I my project settings view, I don't have analysis 
settings. Joel, would you mind having a look at this?


Another option would be to add a model file (and other files which 
configure Coverity) to the repository. Users with a full Coverity 
installation can then check the RTEMS sources with a RTEMS project 
defined setting. Code changes can then reference that the change was due 
to a scan result which will is only available to users with access to a 
full Coverity installation.


--
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: build of libbsd for powerpc fails with error: redefinition of 'eieio'

2019-07-19 Thread dufault 


> On Jul 19, 2019, at 01:21 , Sebastian Huber 
>  wrote:
> 
> A  sounds like a good approach. Finding all users of these defines 
> is a bit of work. They are used by shared code, so every BSP which uses this 
> shared code needs the new header file.

That is mostly addressed by rebuilding all PowerPC BSPs since only the PowerPC 
BSPs  will change and I would do that. I suppose there are optionally 
configured code paths that won’t be found that way. Searching for the use of 
all affected definitions below “powerpc” and checking for an include of 
 is better but more than I want to do.

The other code that can’t be checked is end-user code that includes  but 
not .  That’s always an issue, though.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

BSP names

2019-07-19 Thread Sebastian Huber 

Hello,

I worked a bit with Doorstop and found the YAML file quite interesting. 
The file format is not without problems:


https://arp242.net/yaml-config.html

However, for simple configuration stuff it is easy to write, read and 
process. Changes can be reviewed well in Git (content is spread over lines).


I experiment currently a bit with using a YAML file to define the RTEMS 
build.


How should BSPs be identified in the future? Should a BSP name be unique 
across architectures or do we want to use an "arch/bsp" tuple?


--
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: GSoC Linux UIO driver for PRU

2019-07-19 Thread Nils Hölscher 
On Thu, 18 Jul 2019 at 19:18, Chris Johns  wrote:

> On 18/7/19 7:11 pm, Nils Hölscher wrote:
> > @chr...@rtems.org   but where do we place the
> shell
> > part, which exists between BSD and RTEMS?
>
> LibBSD has a number of shell commands so this should not be a problem.
>
> > However this doesn't have priority right now, does it?
>
> I think the shell command support is good to have. A user wanting to
> develop and
> run a PRU piece of code with an RTEMS app will need all the support we can
> provide.
>

Yes you are definitely right and I think it is pretty easy to port the
pructrl repo I posted before.

>
> Chris
>

I am currently adding more and more libbsd deps to my build, that are not
in rtems or rtems-libbsd.
Now I have been touching these to files of the BSD kernel:
https://github.com/freebsd/freebsd/blob/0966ce5cd477cd7c8b63b0f9de75396aa5939032/sys/arm/include/cpu-v4.h
https://github.com/freebsd/freebsd/blob/0966ce5cd477cd7c8b63b0f9de75396aa5939032/sys/arm/include/atomic-v6.h
Throwing a good dozen of warning when compiling and I only need one call
from these files.
This is needed in the pru driver to distinguish between prussv1 and
prussv2, a feature I definitely want.
FYI: prussv1 is on the TI Sitara AM18xx SoCs and v2 on the AM35xx.

So the question is should I try to resolve those warnings and try to port
the whole files to rtems or should I try to just pick  what I need and be
done?

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

Re: BSP names

2019-07-19 Thread Joel Sherrill 
On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I worked a bit with Doorstop and found the YAML file quite interesting.
> The file format is not without problems:
>
> https://arp242.net/yaml-config.html
>
> However, for simple configuration stuff it is easy to write, read and
> process. Changes can be reviewed well in Git (content is spread over
> lines).
>
> I experiment currently a bit with using a YAML file to define the RTEMS
> build.
>
> How should BSPs be identified in the future? Should a BSP name be unique
> across architectures or do we want to use an "arch/bsp" tuple?
>

Yes. :)

Seriously, I have been working on BSPs for running paravirtualized in Deos
(https://www.ddci.com/products_deos_do_178c_arinc_653/) on the arm,
powerpc, and i386. I started out with each architecture calling the bsp
deos.
This worked for a while but eventually a change to the build system broke
it.
Chris and I had a private (voice) discussion about this.

Historically, there never was a rule about this but I was the first case of
using
the same BSP name across architectures. This probably should have happened
before for BSPs for gdb simulators but it just hadn't. We ended up with the
rule
that BSP names should be unique across all architectures.

But I think formally, arch/bsp is a better way to do it. Besides being
precise,
it implicitly encourages organizing BSPs by architecture.

FWIW when I explain BSPs and variants to people (like I did yesterday), I
try to get them to see that a specific BSP variant has an architecture, BSP
family,. BSP variant, and CPU model associated with it. But specific cases
like the erc32 and leon3 are confusing because the CPU model, BSP variant,
and CPU model are the same.

Anyway requirements are formal. Thus we should use the formal names.

--joel



>
> --
> 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: Coverity Model

2019-07-19 Thread Gedare Bloom 
Hi Sebastian,

On Fri, Jul 19, 2019 at 2:57 AM Sebastian Huber
 wrote:
>
> Hello,
>
> you can add a model file to Coverity to reduce the false positive rate
> of the static analysis. I didn't check that the RTEMS scan can profit
> from this since we already supply a lot of code to the scan. What I
> found interesting is that Qemu uses this:
>
> https://github.com/qemu/qemu/blob/master/scripts/coverity-model.c
>
> There is a comment in it:
>
> " * The model file must be uploaded by an admin in the analysis settings of
>   * http://scan.coverity.com/projects/378;
>
> So, it seems the open source project scan is (or at least was)
> customizable. I my project settings view, I don't have analysis
> settings. Joel, would you mind having a look at this?
>
Yes, we have that setting available, and have a basic modeling file
already. I have it in my TODO to work on the modeling file, and
generally to improve our use of Coverity.

The modeling file we have is:
```
typedef unsigned int uint32_t;

void rtems_fatal_error_occurred(uint32_t the_error)
{
  __coverity_panic__();
}

#define rtems_interrupt_disable( _level ) \
  do { \
_level = 0; \
  } while(0)
```

> Another option would be to add a model file (and other files which
> configure Coverity) to the repository. Users with a full Coverity
> installation can then check the RTEMS sources with a RTEMS project
> defined setting. Code changes can then reference that the change was due
> to a scan result which will is only available to users with access to a
> full Coverity installation.
>
This is a good idea.

> --
> 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 v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Gedare Bloom 
Looks good to me. I'm currently not able to apply it, verify the doc
build, and push it though. (Workstation issues.)

On Fri, Jul 19, 2019 at 2:07 AM Vijay Kumar Banerjee
 wrote:
>
> ---
>  user/bsps/arm/beagle.rst | 110 ++-
>  1 file changed, 108 insertions(+), 2 deletions(-)
>
> diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
> index a36efde..eb4ecfb 100644
> --- a/user/bsps/arm/beagle.rst
> +++ b/user/bsps/arm/beagle.rst
> @@ -1,8 +1,114 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2019 TBD
> +.. Copyright (C) 2019 Vijay Kumar Banerjee
>
>  beagle
>  ==
>
> -TODO.
> +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
> +`beaglebonewhite` and `beagleboneblack`. The basic hardware initialization is
> +not performed by the BSP.  A boot loader with device tree support must be 
> used
> +to start the BSP, e.g., U-Boot.
> +
> +TODO(These drivers are present but not documented yet):
> +
> + *  Clock driver.
> + *  Network Interface Driver.
> + *  SDcard driver.
> + *  GPIO Driver.
> + *  Console driver.
> + *  PWM Driver.
> + *  RTC driver.
> +
> +Boot via U-Boot
> +---
> +To boot via uboot, the ELF must be converted to a U-Boot image like below:
> +
> +.. code-block:: none
> +
> +arm-rtems5-objcopy hello.exe -O app.bin
> +gzip 9 app.bin
> +mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS 
> -d app.bin.gz rtems-app.img
> +
> +Getting the Device Tree Blob
> +
> +
> +The Device Tree Blob (DTB) is needed to load the device tree while starting 
> up
> +the kernel. We build the dtb from the FreeBSD source matching the commit hash
> +from the libbsd HEAD of freebsd-org. For example if the HEAD is at
> +"19a6ceb89dbacf74697d493e48c388767126d418"
> +Then the right Device Tree Source (DTS) file is:
> +https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
> +
> +.. code-block:: shell
> +   :linenos:
> +
> + #building the dtb
> + #We will use the script from 
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
> +
> + #The make_dtb.sh script uses environment variable MACHINE
> + export MACHINE='arm'
> +
> + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> +
> + #The arguments to the script are
> + # $1 -> Build Tree
> + # $2 -> DTS source file
> + # $3 -> output path of the DTB file
> +
> + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
> + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
> + $(pwd)
> +
> +Writing the uEnv.txt file
> +-
> +
> +The uEnv.txt file is needed to set any environment variable before the 
> kernel is
> +loaded. Each line is a u-boot command that the uboot will execute during 
> start
> +up.
> +
> +Add the following to a file named uEnv.txt:
> +
> +.. code-block:: none
> +
> + setenv bootdelay 5
> + uenvcmd=run boot
> + boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
> am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
> +
> +I2C Driver
> +--
> +
> +For registering the `/dev/i2c-0` device, a wrapper function is provided,
> +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> +``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and 
> `i2c-2`.
> +
> +For registering an I2C device with a custom path (say `/dev/i2c-3`) the
> +function ``am335x_i2c_bus_register()`` has to be used.
> +
> +The function prototype is given below:
> +
> +.. code-block:: C
> +
> +   int am335x_i2c_bus_register(
> +   const char *bus_path,
> +   uintptr_t   register_base,
> +   uint32_tinput_clock,
> +   rtems_vector_number irq
> +   );
> +
> +SPI Driver
> +--
> +
> +The SPI device `/dev/spi-0` can be registered with ``bbb_register_spi_0()``
> +
> +For registering with a custom path, the ``bsp_register_spi()`` can be used.
> +
> +The function prototype is given below:
> +
> +.. code-block:: C
> +
> +rtems_status_code bsp_register_spi(
> +   const char *bus_path,
> +   uintptr_t   register_base,
> +   rtems_vector_number irq
> +);
> --
> 2.20.1
>
> ___
> 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 v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Christian Mauderer 
On 19/07/2019 18:21, Gedare Bloom wrote:
> Looks good to me. I'm currently not able to apply it, verify the doc
> build, and push it though. (Workstation issues.)
> 

I agree that it looks OK. Thanks from me too for contributing to the
documentation. It's something that most developers don't like to do
therefore it's really great that you wrote that.

I didn't find any bugs in the instructions while reading through it. I
can create a PDF out of it on my Arch Linux machine so I think it should
be OK to merge it.

You have tried quite a bit till you get an overlay working. If you feel
like writing some more documentation, it might would be a good addition
to add some notes regarding that too. I think this patch is fine as it
is so if you add something please create a second patch.

@Gedare: I don't touch the docs repo that often: Is there some defined
test process before a commit is added? Or is building a PDF on some
random machine enough?

Best regards

Christian

> On Fri, Jul 19, 2019 at 2:07 AM Vijay Kumar Banerjee
>  wrote:
>>
>> ---
>>  user/bsps/arm/beagle.rst | 110 ++-
>>  1 file changed, 108 insertions(+), 2 deletions(-)
>>
>> diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
>> index a36efde..eb4ecfb 100644
>> --- a/user/bsps/arm/beagle.rst
>> +++ b/user/bsps/arm/beagle.rst
>> @@ -1,8 +1,114 @@
>>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>>
>> -.. Copyright (C) 2019 TBD
>> +.. Copyright (C) 2019 Vijay Kumar Banerjee
>>
>>  beagle
>>  ==
>>
>> -TODO.
>> +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
>> +`beaglebonewhite` and `beagleboneblack`. The basic hardware initialization 
>> is
>> +not performed by the BSP.  A boot loader with device tree support must be 
>> used
>> +to start the BSP, e.g., U-Boot.
>> +
>> +TODO(These drivers are present but not documented yet):
>> +
>> + *  Clock driver.
>> + *  Network Interface Driver.
>> + *  SDcard driver.
>> + *  GPIO Driver.
>> + *  Console driver.
>> + *  PWM Driver.
>> + *  RTC driver.
>> +
>> +Boot via U-Boot
>> +---
>> +To boot via uboot, the ELF must be converted to a U-Boot image like below:
>> +
>> +.. code-block:: none
>> +
>> +arm-rtems5-objcopy hello.exe -O app.bin
>> +gzip 9 app.bin
>> +mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS 
>> -d app.bin.gz rtems-app.img
>> +
>> +Getting the Device Tree Blob
>> +
>> +
>> +The Device Tree Blob (DTB) is needed to load the device tree while starting 
>> up
>> +the kernel. We build the dtb from the FreeBSD source matching the commit 
>> hash
>> +from the libbsd HEAD of freebsd-org. For example if the HEAD is at
>> +"19a6ceb89dbacf74697d493e48c388767126d418"
>> +Then the right Device Tree Source (DTS) file is:
>> +https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
>> +
>> +.. code-block:: shell
>> +   :linenos:
>> +
>> + #building the dtb
>> + #We will use the script from 
>> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
>> +
>> + #The make_dtb.sh script uses environment variable MACHINE
>> + export MACHINE='arm'
>> +
>> + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
>> +
>> + #The arguments to the script are
>> + # $1 -> Build Tree
>> + # $2 -> DTS source file
>> + # $3 -> output path of the DTB file
>> +
>> + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
>> + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
>> + $(pwd)
>> +
>> +Writing the uEnv.txt file
>> +-
>> +
>> +The uEnv.txt file is needed to set any environment variable before the 
>> kernel is
>> +loaded. Each line is a u-boot command that the uboot will execute during 
>> start
>> +up.
>> +
>> +Add the following to a file named uEnv.txt:
>> +
>> +.. code-block:: none
>> +
>> + setenv bootdelay 5
>> + uenvcmd=run boot
>> + boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
>> am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
>> +
>> +I2C Driver
>> +--
>> +
>> +For registering the `/dev/i2c-0` device, a wrapper function is provided,
>> +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
>> +``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and 
>> `i2c-2`.
>> +
>> +For registering an I2C device with a custom path (say `/dev/i2c-3`) the
>> +function ``am335x_i2c_bus_register()`` has to be used.
>> +
>> +The function prototype is given below:
>> +
>> +.. code-block:: C
>> +
>> +   int am335x_i2c_bus_register(
>> +   const char *bus_path,
>> +   uintptr_t   register_base,
>> +   uint32_tinput_clock,
>> +   rtems_vector_number irq
>> +   );
>> +
>> +SPI Driver
>> +--
>> +
>> +The SPI device `/dev/spi-0` can be registered with ``bbb_register_spi_0()``
>> +
>> +For registering with a custom

Re: Build failed for RTEMS Source Builder

2019-07-19 Thread Himanshu Sekhar Nayak 
Hi Chris,

After your solution, I changed the required source directories but seems
like idk why it needs sudo privileges ?

https://paste.ofcode.org/38mtbHLLH9WggmRkXWZDq4r

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

Re: Build failed for RTEMS Source Builder

2019-07-19 Thread Vijay Kumar Banerjee 
On Sat, Jul 20, 2019, 12:03 AM Himanshu Sekhar Nayak <
himanshuwindows...@gmail.com> wrote:

> Hi Chris,
>
> After your solution, I changed the required source directories but seems
> like idk why it needs sudo privileges ?
>
> https://paste.ofcode.org/38mtbHLLH9WggmRkXWZDq4r
>
The path /opt/ requires root privilege.
You can change it to something like
$HOME/myrtems/dir/ in your --prefix

Regards,
Vijay


> Thanks
> Himanshu
> ___
> 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 v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Vijay Kumar Banerjee 
On Fri, Jul 19, 2019 at 10:32 PM Christian Mauderer 
wrote:

> On 19/07/2019 18:21, Gedare Bloom wrote:
> > Looks good to me. I'm currently not able to apply it, verify the doc
> > build, and push it though. (Workstation issues.)
> >
>
> I agree that it looks OK. Thanks from me too for contributing to the
> documentation. It's something that most developers don't like to do
> therefore it's really great that you wrote that.
>
> Always glad to contribute. :)

> I didn't find any bugs in the instructions while reading through it. I
> can create a PDF out of it on my Arch Linux machine so I think it should
> be OK to merge it.
>
> You have tried quite a bit till you get an overlay working. If you feel
> like writing some more documentation, it might would be a good addition
> to add some notes regarding that too. I think this patch is fine as it
> is so if you add something please create a second patch.
>
> Sure, I can write about creating and overlay and applying it to the base
tree.
What would be the right place to write it?
I have also wondered if it would be a good idea to keep the overlays in
RTEMS
or libBSD repo somewhere along with a script that builds a dtb from the
freebsd-org
tree and applies the overlay.

> @Gedare: I don't touch the docs repo that often: Is there some defined
> test process before a commit is added? Or is building a PDF on some
> random machine enough?
>
> Best regards
>
> Christian
>
> > On Fri, Jul 19, 2019 at 2:07 AM Vijay Kumar Banerjee
> >  wrote:
> >>
> >> ---
> >>  user/bsps/arm/beagle.rst | 110 ++-
> >>  1 file changed, 108 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
> >> index a36efde..eb4ecfb 100644
> >> --- a/user/bsps/arm/beagle.rst
> >> +++ b/user/bsps/arm/beagle.rst
> >> @@ -1,8 +1,114 @@
> >>  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >>
> >> -.. Copyright (C) 2019 TBD
> >> +.. Copyright (C) 2019 Vijay Kumar Banerjee
> >>
> >>  beagle
> >>  ==
> >>
> >> -TODO.
> >> +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
> >> +`beaglebonewhite` and `beagleboneblack`. The basic hardware
> initialization is
> >> +not performed by the BSP.  A boot loader with device tree support must
> be used
> >> +to start the BSP, e.g., U-Boot.
> >> +
> >> +TODO(These drivers are present but not documented yet):
> >> +
> >> + *  Clock driver.
> >> + *  Network Interface Driver.
> >> + *  SDcard driver.
> >> + *  GPIO Driver.
> >> + *  Console driver.
> >> + *  PWM Driver.
> >> + *  RTC driver.
> >> +
> >> +Boot via U-Boot
> >> +---
> >> +To boot via uboot, the ELF must be converted to a U-Boot image like
> below:
> >> +
> >> +.. code-block:: none
> >> +
> >> +arm-rtems5-objcopy hello.exe -O app.bin
> >> +gzip 9 app.bin
> >> +mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n
> RTEMS -d app.bin.gz rtems-app.img
> >> +
> >> +Getting the Device Tree Blob
> >> +
> >> +
> >> +The Device Tree Blob (DTB) is needed to load the device tree while
> starting up
> >> +the kernel. We build the dtb from the FreeBSD source matching the
> commit hash
> >> +from the libbsd HEAD of freebsd-org. For example if the HEAD is at
> >> +"19a6ceb89dbacf74697d493e48c388767126d418"
> >> +Then the right Device Tree Source (DTS) file is:
> >> +
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
> >> +
> >> +.. code-block:: shell
> >> +   :linenos:
> >> +
> >> + #building the dtb
> >> + #We will use the script from
> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
> >> +
> >> + #The make_dtb.sh script uses environment variable MACHINE
> >> + export MACHINE='arm'
> >> +
> >> + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> >> +
> >> + #The arguments to the script are
> >> + # $1 -> Build Tree
> >> + # $2 -> DTS source file
> >> + # $3 -> output path of the DTB file
> >> +
> >> + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
> >> + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
> >> + $(pwd)
> >> +
> >> +Writing the uEnv.txt file
> >> +-
> >> +
> >> +The uEnv.txt file is needed to set any environment variable before the
> kernel is
> >> +loaded. Each line is a u-boot command that the uboot will execute
> during start
> >> +up.
> >> +
> >> +Add the following to a file named uEnv.txt:
> >> +
> >> +.. code-block:: none
> >> +
> >> + setenv bootdelay 5
> >> + uenvcmd=run boot
> >> + boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0
> 0x8800 am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
> >> +
> >> +I2C Driver
> >> +--
> >> +
> >> +For registering the `/dev/i2c-0` device, a wrapper function is
> provided,
> >> +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> >>

Re: [PATCH v2] user/bsps : Add documentation for Beagle

2019-07-19 Thread Gedare Bloom 
On Fri, Jul 19, 2019 at 11:02 AM Christian Mauderer  wrote:
>
> On 19/07/2019 18:21, Gedare Bloom wrote:
> > Looks good to me. I'm currently not able to apply it, verify the doc
> > build, and push it though. (Workstation issues.)
> >
>
> I agree that it looks OK. Thanks from me too for contributing to the
> documentation. It's something that most developers don't like to do
> therefore it's really great that you wrote that.
>
> I didn't find any bugs in the instructions while reading through it. I
> can create a PDF out of it on my Arch Linux machine so I think it should
> be OK to merge it.
>
> You have tried quite a bit till you get an overlay working. If you feel
> like writing some more documentation, it might would be a good addition
> to add some notes regarding that too. I think this patch is fine as it
> is so if you add something please create a second patch.
>
> @Gedare: I don't touch the docs repo that often: Is there some defined
> test process before a commit is added? Or is building a PDF on some
> random machine enough?
>
I don't think the process is well-defined for the docs. However, if
you built the PDF and it looks good (can you build HTML too?) then go
ahead and push it.

> Best regards
>
> Christian
>
> > On Fri, Jul 19, 2019 at 2:07 AM Vijay Kumar Banerjee
> >  wrote:
> >>
> >> ---
> >>  user/bsps/arm/beagle.rst | 110 ++-
> >>  1 file changed, 108 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/user/bsps/arm/beagle.rst b/user/bsps/arm/beagle.rst
> >> index a36efde..eb4ecfb 100644
> >> --- a/user/bsps/arm/beagle.rst
> >> +++ b/user/bsps/arm/beagle.rst
> >> @@ -1,8 +1,114 @@
> >>  .. SPDX-License-Identifier: CC-BY-SA-4.0
> >>
> >> -.. Copyright (C) 2019 TBD
> >> +.. Copyright (C) 2019 Vijay Kumar Banerjee
> >>
> >>  beagle
> >>  ==
> >>
> >> -TODO.
> >> +This BSP supports four variants, `beagleboardorig`, `beagleboardxm`,
> >> +`beaglebonewhite` and `beagleboneblack`. The basic hardware 
> >> initialization is
> >> +not performed by the BSP.  A boot loader with device tree support must be 
> >> used
> >> +to start the BSP, e.g., U-Boot.
> >> +
> >> +TODO(These drivers are present but not documented yet):
> >> +
> >> + *  Clock driver.
> >> + *  Network Interface Driver.
> >> + *  SDcard driver.
> >> + *  GPIO Driver.
> >> + *  Console driver.
> >> + *  PWM Driver.
> >> + *  RTC driver.
> >> +
> >> +Boot via U-Boot
> >> +---
> >> +To boot via uboot, the ELF must be converted to a U-Boot image like below:
> >> +
> >> +.. code-block:: none
> >> +
> >> +arm-rtems5-objcopy hello.exe -O app.bin
> >> +gzip 9 app.bin
> >> +mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n 
> >> RTEMS -d app.bin.gz rtems-app.img
> >> +
> >> +Getting the Device Tree Blob
> >> +
> >> +
> >> +The Device Tree Blob (DTB) is needed to load the device tree while 
> >> starting up
> >> +the kernel. We build the dtb from the FreeBSD source matching the commit 
> >> hash
> >> +from the libbsd HEAD of freebsd-org. For example if the HEAD is at
> >> +"19a6ceb89dbacf74697d493e48c388767126d418"
> >> +Then the right Device Tree Source (DTS) file is:
> >> +https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/gnu/dts/arm/am335x-boneblack.dts
> >> +
> >> +.. code-block:: shell
> >> +   :linenos:
> >> +
> >> + #building the dtb
> >> + #We will use the script from 
> >> https://github.com/freebsd/freebsd/blob/19a6ceb89dbacf74697d493e48c388767126d418/sys/tools/fdt/make_dtb.sh
> >> +
> >> + #The make_dtb.sh script uses environment variable MACHINE
> >> + export MACHINE='arm'
> >> +
> >> + SCRIPT_DIR=$HOME/freebsd/sys/tools/fdt
> >> +
> >> + #The arguments to the script are
> >> + # $1 -> Build Tree
> >> + # $2 -> DTS source file
> >> + # $3 -> output path of the DTB file
> >> +
> >> + ${SCRIPT_DIR}/make_dtb.sh ${SCRIPT_DIR}/../../ \
> >> + ${SCRIPT_DIR}/../../gnu/dts/arm/am335x-boneblack.dts \
> >> + $(pwd)
> >> +
> >> +Writing the uEnv.txt file
> >> +-
> >> +
> >> +The uEnv.txt file is needed to set any environment variable before the 
> >> kernel is
> >> +loaded. Each line is a u-boot command that the uboot will execute during 
> >> start
> >> +up.
> >> +
> >> +Add the following to a file named uEnv.txt:
> >> +
> >> +.. code-block:: none
> >> +
> >> + setenv bootdelay 5
> >> + uenvcmd=run boot
> >> + boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 
> >> 0x8800 am335x-boneblack.dtb ; bootm 0x8080 - 0x8800
> >> +
> >> +I2C Driver
> >> +--
> >> +
> >> +For registering the `/dev/i2c-0` device, a wrapper function is provided,
> >> +``bbb_register_i2c_0()`` similarly ``bbb_register_i2c_1()`` and
> >> +``bbb_register_i2c_2()`` are respectively used to register `i2c-1` and 
> >> `i2c-2`.
> >> +
> >> +For registering an I2C device with a custom path (say `/dev/i2c-3`) the
> >>