[PATCH] Replace build date with Git hash and commit date

2019-01-09 Thread Sebastian Huber 
The usage of a build date prevents reproducible builds.
---
 common/conf.py | 25 +
 common/waf.py  | 22 ++
 wscript| 39 ---
 3 files changed, 39 insertions(+), 47 deletions(-)

diff --git a/common/conf.py b/common/conf.py
index 60db066..8d5e6b8 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -1,26 +1,3 @@
-import datetime
-
-def build_date():
-now = datetime.date.today()
-m = now.strftime('%B')
-y = now.strftime('%Y')
-if now.day == 11:
-s = 'th'
-elif now.day % 10 == 1:
-s = 'st'
-elif now.day == 12:
-s = 'th'
-elif now.day % 10 == 2:
-s = 'nd'
-elif now.day == 13:
-s = 'th'
-elif now.day == 3:
-s = 'rd'
-else:
-s = 'th'
-d = '%2d%s' % (now.day, s)
-return '%s %s %s' % (d, m, y)
-
 extensions = [
"sphinx.ext.autodoc",
"sphinx.ext.coverage",
@@ -47,7 +24,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'RTEMS Documentation Project'
-copyright = u'2018, RTEMS Project (built %s)' % (build_date())
+copyright = u'2018, RTEMS Project'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
diff --git a/common/waf.py b/common/waf.py
index d2cb432..01dd24f 100644
--- a/common/waf.py
+++ b/common/waf.py
@@ -17,24 +17,8 @@ import latex
 
 sphinx_min_version = (1, 3)
 
-def build_date():
-import datetime
-now = datetime.date.today()
-m = now.strftime('%B')
-y = now.strftime('%Y')
-if now.day % 10 == 1:
-s = 'st'
-elif now.day % 10 == 2:
-s = 'nd'
-elif now.day == 3:
-s = 'rd'
-else:
-s = 'th'
-d = '%2d%s' % (now.day, s)
-return '%s %s %s' % (d, m, y)
-
 def version_cmdline(ctx):
-return '-Drelease="%s" -Dversion="%s"' % (ctx.env.VERSION, ctx.env.VERSION)
+return '-Drelease="%s" -Dversion="%s"' % (ctx.env.RELEASE, ctx.env.VERSION)
 
 def sphinx_cmdline(ctx, build_type, conf_dir, doctrees,
source_dir, output_dir, configs = []):
@@ -207,8 +191,6 @@ def check_sphinx_extension(ctx, extension):
 def cmd_configure(ctx):
 check_sphinx = not ctx.env.BIN_SPHINX_BUILD
 if check_sphinx:
-ctx.msg('Checking version', ctx.env.VERSION)
-
 ctx.find_program("sphinx-build", var="BIN_SPHINX_BUILD", mandatory = 
True)
 ctx.find_program("aspell", var = "BIN_ASPELL", mandatory = False)
 
@@ -502,7 +484,7 @@ def xml_catalogue(ctx, building):
 cat = xml.Document()
 
 root = cat.createElement('rtems-docs')
-root.setAttribute('date', build_date())
+root.setAttribute('date', ctx.env.DATE)
 cat.appendChild(root)
 
 heading = cat.createElement('catalogue')
diff --git a/wscript b/wscript
index 82d5eaa..1488d3a 100644
--- a/wscript
+++ b/wscript
@@ -9,8 +9,6 @@ path.append(abspath('common'))
 import waflib
 import waf as docs_waf
 
-version = '5.0.0 (master)'
-
 build_all = ['user',
  'rsb',
  'c-user',
@@ -31,7 +29,6 @@ def options(opt):
 docs_waf.cmd_options(opt)
 
 def configure(conf):
-conf.env.VERSION = version
 for b in building:
 conf.recurse(b)
 conf.env['BUILD_FROM_TOP'] = 'yes'
@@ -53,7 +50,43 @@ def coverpage_js(ctx):
 with open(ctx.outputs[0].abspath(), 'w') as o:
 o.write(js.replace('@CATALOGUE', xml))
 
+def pretty_day(day):
+if day == 3:
+s = 'rd'
+elif day == 11:
+s = 'th'
+elif day == 12:
+s = 'th'
+elif day == 13:
+s = 'th'
+elif day % 10 == 1:
+s = 'st'
+elif day % 10 == 2:
+s = 'nd'
+else:
+s = 'th'
+return str(day) + s
+
 def build(ctx):
+#
+# Get date and version from Git
+#
+version = '5.0.0'
+if ctx.exec_command(['git', 'diff-index', '--quiet', 'HEAD']) == 0:
+modified = ''
+else:
+modified = '-modified'
+try:
+out = ctx.cmd_and_log(['git', 'log', '-1', '--format=%H,%cd', 
'--date=format:%e,%B,%Y'])
+f = out.strip('\n').split(',')
+version = version + '.' + f[0] + modified
+date = pretty_day(int(f[1])) + ' ' + f[2] + ' ' + f[3]
+except waflib.Build.Errors.WafError:
+date = 'unknown date'
+ctx.env.DATE = date
+ctx.env.RELEASE = version + ' (' + date + ')'
+ctx.env.VERSION = version
+
 #
 # Generate any PlantUML images if enabled.
 #
-- 
2.16.4

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

Re: [PATCH 0/6] Rework overview chapter in User Manual

2019-01-09 Thread Sebastian Huber 

On 07/01/2019 12:03, Sebastian Huber wrote:

Sebastian Huber (6):
   Remove build date from first page
   Update general copyright notice
   Remove superfluous word "Copyright"
   Add common header.rst to reduce copy and paste
   Update header.rst
   user: Rework overview


Any comments to the remaining five patches?

--
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

GSOC 2019 Aspirant

2019-01-09 Thread Ravindra Meena 
Hi,

I am GSOC aspirant. I am new to RTEMs and this project interests me a lot.
I have set up the RTEMs development environment on Ubuntu and also have run
"hello world application".

I would like to know more about it. Please, can you connect me to the
developers who are contributing to the RTEMs? It would be a great help if
you can send me the list of available projects?

Thank you

-- 
*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: Tool Build Failures for rtems6

2019-01-09 Thread Sebastian Huber 

On 08/01/2019 16:04, Joel Sherrill wrote:
How should we progress with my gcc patches that largely eliminate the 
need for specs files? I can start updating, testing, and submitting 
them to gcc if we like. 


I think the basic problem with the dummy Newlib crt0.o which is used for 
the configure checks is still unsolved.


--
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: Status of RISCV port on sis

2019-01-09 Thread Sebastian Huber 

On 08/01/2019 08:57, Sebastian Huber wrote:
It is not clear why the failures didn't show up on the Qemu test runs. 


I did some tests with Qemu and the sp37 fails also here. Somehow I 
didn't notice this failure before.


--
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: Status of RISCV port on sis

2019-01-09 Thread Sebastian Huber 

Hello Jiri,

could you please rebase your work to this RTEMS commit:

https://git.rtems.org/rtems/commit/?id=b9ffc41c9678fb3c5386c1a6ab394656ec85dbc6

--
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] Replace build date with Git hash and commit date

2019-01-09 Thread Chris Johns 
On 9/1/19 7:24 pm, Sebastian Huber wrote:
> The usage of a build date prevents reproducible builds.

Nice.

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

Re: [PATCH 0/6] Rework overview chapter in User Manual

2019-01-09 Thread Chris Johns 
On 9/1/19 7:34 pm, Sebastian Huber wrote:
> On 07/01/2019 12:03, Sebastian Huber wrote:
>> Sebastian Huber (6):
>>    Remove build date from first page
>>    Update general copyright notice
>>    Remove superfluous word "Copyright"
>>    Add common header.rst to reduce copy and paste
>>    Update header.rst
>>    user: Rework overview
> 
> Any comments to the remaining five patches?
> 

They looks good to me. The header.rst change is nice.

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

Re: [PATCH 0/6] Rework overview chapter in User Manual

2019-01-09 Thread Sebastian Huber 

On 09/01/2019 11:11, Chris Johns wrote:

On 9/1/19 7:34 pm, Sebastian Huber wrote:

On 07/01/2019 12:03, Sebastian Huber wrote:

Sebastian Huber (6):
    Remove build date from first page
    Update general copyright notice
    Remove superfluous word "Copyright"
    Add common header.rst to reduce copy and paste
    Update header.rst
    user: Rework overview

Any comments to the remaining five patches?


They looks good to me. The header.rst change is nice.


Ok, good. My next step is to work on the quick start section.

--
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

RSB documentation

2019-01-09 Thread Sebastian Huber 

Hello,

the RSB has currently its own manual in the documentation set:

https://docs.rtems.org/branches/master/rsb/index.html

I think it would make sense to move the RSB documentation into the user 
manual as a chapter. If you are new to RTEMS, then dealing with the RSB 
is one of the first things you have to do. I think it is easier if you 
have every to get started in one manual (e.g. you can use documentation 
internal links).


--
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 2019 Aspirant

2019-01-09 Thread Shashvat Jain 
Hi Ravindra
This link has a list of open projects
https://devel.rtems.org/wiki/Developer/OpenProjects
you can always ask the developers about projects on this list .

Thank you for your interest

--Shashvat


On Wed, Jan 9, 2019 at 2:24 PM Ravindra Meena  wrote:

> Hi,
>
> I am GSOC aspirant. I am new to RTEMs and this project interests me a lot.
> I have set up the RTEMs development environment on Ubuntu and also have run
> "hello world application".
>
> I would like to know more about it. Please, can you connect me to the
> developers who are contributing to the RTEMs? It would be a great help if
> you can send me the list of available projects?
>
> Thank you
>
> --
> *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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 2/3] Remove superfluous "All rights reserved."

2019-01-09 Thread Sebastian Huber 
---
 bsp-howto/ada95_interrupt.rst  | 1 -
 bsp-howto/ata.rst  | 1 -
 bsp-howto/clock.rst| 1 -
 bsp-howto/console.rst  | 1 -
 bsp-howto/frame_buffer.rst | 1 -
 bsp-howto/getentropy.rst   | 1 -
 bsp-howto/i2c.rst  | 1 -
 bsp-howto/ide_controller.rst   | 1 -
 bsp-howto/initilization_code.rst   | 1 -
 bsp-howto/linker_script.rst| 1 -
 bsp-howto/miscellanous_support.rst | 1 -
 bsp-howto/networking.rst   | 1 -
 bsp-howto/preface.rst  | 1 -
 bsp-howto/real_time_clock.rst  | 1 -
 bsp-howto/shared_memory_support.rst| 1 -
 bsp-howto/spi.rst  | 1 -
 bsp-howto/target_dependant_files.rst   | 1 -
 bsp-howto/timer.rst| 1 -
 c-user/ada_support.rst | 1 -
 c-user/barrier_manager.rst | 1 -
 c-user/board_support_packages.rst  | 1 -
 c-user/chains.rst  | 1 -
 c-user/clock_manager.rst   | 1 -
 c-user/configuring_a_system.rst| 1 -
 c-user/constant_bandwidth_server.rst   | 1 -
 c-user/cpu_usage_statistics.rst| 1 -
 c-user/directive_status_codes.rst  | 1 -
 c-user/dual_ports_memory_manager.rst   | 1 -
 c-user/event_manager.rst   | 1 -
 c-user/example_application.rst | 1 -
 c-user/fatal_error.rst | 1 -
 c-user/initialization.rst  | 1 -
 c-user/interrupt_manager.rst   | 1 -
 c-user/io_manager.rst  | 1 -
 c-user/key_concepts.rst| 1 -
 c-user/linker_sets.rst | 1 -
 c-user/message_manager.rst | 1 -
 c-user/multiprocessing.rst | 1 -
 c-user/object_services.rst | 1 -
 c-user/overview.rst| 1 -
 c-user/partition_manager.rst   | 1 -
 c-user/pci_library.rst | 1 -
 c-user/preface.rst | 1 -
 c-user/rate_monotonic_manager.rst  | 1 -
 c-user/red_black_trees.rst | 1 -
 c-user/region_manager.rst  | 1 -
 c-user/rtems_data_types.rst| 1 -
 c-user/scheduling_concepts.rst | 1 -
 c-user/self_contained_objects.rst  | 1 -
 c-user/semaphore_manager.rst   | 1 -
 c-user/signal_manager.rst  | 1 -
 c-user/stack_bounds_checker.rst| 1 -
 c-user/symmetric_multiprocessing_services.rst  | 1 -
 c-user/task_manager.rst| 1 -
 c-user/timer_manager.rst   | 1 -
 c-user/timespec_helpers.rst| 1 -
 c-user/user_extensions.rst | 1 -
 cpu-supplement/altera_nios_ii.rst  | 1 -
 cpu-supplement/arm.rst | 1 -
 cpu-supplement/atmel_avr.rst   | 1 -
 cpu-supplement/ephiphany.rst   | 1 -
 cpu-supplement/intel_amd_x86.rst   | 1 -
 cpu-supplement/lattice_micro32.rst | 1 -
 cpu-supplement/m68xxx_and_coldfire.rst | 1 -
 cpu-supplement/mips.rst| 1 -
 cpu-supplement/openrisc_1000.rst   | 1 -
 cpu-supplement/port.rst| 1 -
 cpu-supplement/powerpc.rst | 1 -
 cpu-supplement/preface.rst | 1 -
 cpu-supplement/renesas_m32c.rst| 1 -
 cpu-supplement/riscv.rst   | 1 -
 cpu-supplement/sparc.rst   | 1 -
 cpu-supplement/sparc64.rst | 1 -
 cpu-supplement/superh.rst  | 1 -
 cpu-supplement/xilinx_microblaze.rst   | 1 -
 develenv/directory.rst | 1 -
 develenv/introduction.rst  | 1 -
 eclipse/index.rst  | 1 -
 eclipse/overview.rst   | 1 -
 eclipse/rtems.rst  | 1 -
 filesystem/call_development.rst| 1 -
 filesystem/fileystem_implmentation.rst | 1 -
 filesystem/in-memory.rst   | 1 -
 filesystem/minature_in-memory.rst  | 1 -
 filesystem/mounting_and_unmounting.rst | 1 -
 filesystem/pathname_eval.rst   | 1 -
 filesystem/preface.rst | 1 -
 filesystem/system_init.rst | 1 -
 networking/network_task_structure.rst  | 1 -
 networking/networking_driver.rst   | 1 -
 networking/preface.rst | 1 -
 networking/testing_the_driver.rst  | 1 -
 networking/using_networkin

[PATCH 3/3] Simplify SPDX-License-Identifier comment

2019-01-09 Thread Sebastian Huber 
---
 book/index_book.rst| 2 +-
 bsp-howto/ada95_interrupt.rst  | 2 +-
 bsp-howto/ata.rst  | 2 +-
 bsp-howto/clock.rst| 2 +-
 bsp-howto/command.rst  | 2 +-
 bsp-howto/console.rst  | 2 +-
 bsp-howto/frame_buffer.rst | 2 +-
 bsp-howto/getentropy.rst   | 2 +-
 bsp-howto/i2c.rst  | 2 +-
 bsp-howto/ide_controller.rst   | 2 +-
 bsp-howto/index.rst| 2 +-
 bsp-howto/initilization_code.rst   | 2 +-
 bsp-howto/linker_script.rst| 2 +-
 bsp-howto/miscellanous_support.rst | 2 +-
 bsp-howto/networking.rst   | 2 +-
 bsp-howto/preface.rst  | 2 +-
 bsp-howto/real_time_clock.rst  | 2 +-
 bsp-howto/shared_memory_support.rst| 2 +-
 bsp-howto/spi.rst  | 2 +-
 bsp-howto/target_dependant_files.rst   | 2 +-
 bsp-howto/timer.rst| 2 +-
 c-user/ada_support.rst | 2 +-
 c-user/barrier_manager.rst | 2 +-
 c-user/board_support_packages.rst  | 2 +-
 c-user/chains.rst  | 2 +-
 c-user/clock_manager.rst   | 2 +-
 c-user/configuring_a_system.rst| 2 +-
 c-user/constant_bandwidth_server.rst   | 2 +-
 c-user/cpu_usage_statistics.rst| 2 +-
 c-user/directive_status_codes.rst  | 2 +-
 c-user/dual_ports_memory_manager.rst   | 2 +-
 c-user/event_manager.rst   | 2 +-
 c-user/example_application.rst | 2 +-
 c-user/fatal_error.rst | 2 +-
 c-user/glossary.rst| 2 +-
 c-user/index.rst   | 2 +-
 c-user/initialization.rst  | 2 +-
 c-user/interrupt_manager.rst   | 2 +-
 c-user/io_manager.rst  | 2 +-
 c-user/key_concepts.rst| 2 +-
 c-user/linker_sets.rst | 2 +-
 c-user/message_manager.rst | 2 +-
 c-user/multiprocessing.rst | 2 +-
 c-user/object_services.rst | 2 +-
 c-user/overview.rst| 2 +-
 c-user/partition_manager.rst   | 2 +-
 c-user/pci_library.rst | 2 +-
 c-user/preface.rst | 2 +-
 c-user/rate_monotonic_manager.rst  | 2 +-
 c-user/red_black_trees.rst | 2 +-
 c-user/region_manager.rst  | 2 +-
 c-user/rtems_data_types.rst| 2 +-
 c-user/scheduling_concepts.rst | 2 +-
 c-user/self_contained_objects.rst  | 2 +-
 c-user/semaphore_manager.rst   | 2 +-
 c-user/signal_manager.rst  | 2 +-
 c-user/stack_bounds_checker.rst| 2 +-
 c-user/symmetric_multiprocessing_services.rst  | 2 +-
 c-user/task_manager.rst| 2 +-
 c-user/timer_manager.rst   | 2 +-
 c-user/timespec_helpers.rst| 2 +-
 c-user/user_extensions.rst | 2 +-
 contributor/index.rst  | 2 +-
 cpu-supplement/altera_nios_ii.rst  | 2 +-
 cpu-supplement/arm.rst | 2 +-
 cpu-supplement/atmel_avr.rst   | 2 +-
 cpu-supplement/blackfin.rst| 2 +-
 cpu-supplement/ephiphany.rst   | 2 +-
 cpu-supplement/index.rst   | 2 +-
 cpu-supplement/intel_amd_x86.rst   | 2 +-
 cpu-supplement/lattice_micro32.rst | 2 +-
 cpu-supplement/m68xxx_and_coldfire.rst | 2 +-
 cpu-supplement/mips.rst| 2 +-
 cpu-supplement/openrisc_1000.rst   | 2 +-
 cpu-supplement/port.rst| 2 +-
 cpu-supplement/powerpc.rst | 2 +-
 cpu-supplement/preface.rst | 2 +-
 cpu-supplement/renesas_m32c.rst| 2 +-
 cpu-supplement/riscv.rst   | 2 +-
 cpu-supplement/sparc.rst   | 2 +-
 cpu-supplement/sparc64.rst | 2 +-
 cpu-supplement/sparc_v8_stacks_regwin.rst  | 2 +-
 cpu-supplement/superh.rst  | 2 +-
 cpu-supplement/xilinx_microblaze.rst   | 2 +-
 develenv/command.rst   | 2 +-
 develenv/directory.rst | 2 +-
 develenv/index.rst | 2 +-
 develenv/introduction.rst  | 2 +-
 develenv/sample.rst| 2 +-
 develenv/utilities.rst | 2 +-
 eclipse/glossary.rst

[PATCH 1/3] Use standard format for copyright lines

2019-01-09 Thread Sebastian Huber 
---
 bsp-howto/ada95_interrupt.rst  |  3 +--
 bsp-howto/ata.rst  |  3 +--
 bsp-howto/clock.rst|  3 +--
 bsp-howto/console.rst  |  3 +--
 bsp-howto/frame_buffer.rst |  3 +--
 bsp-howto/getentropy.rst   |  2 +-
 bsp-howto/i2c.rst  |  2 +-
 bsp-howto/ide_controller.rst   |  3 +--
 bsp-howto/initilization_code.rst   |  3 +--
 bsp-howto/linker_script.rst|  3 +--
 bsp-howto/miscellanous_support.rst |  3 +--
 bsp-howto/networking.rst   |  3 +--
 bsp-howto/preface.rst  |  3 +--
 bsp-howto/real_time_clock.rst  |  3 +--
 bsp-howto/shared_memory_support.rst|  3 +--
 bsp-howto/spi.rst  |  2 +-
 bsp-howto/target_dependant_files.rst   |  3 +--
 bsp-howto/timer.rst|  3 +--
 c-user/ada_support.rst |  3 +--
 c-user/barrier_manager.rst |  2 +-
 c-user/board_support_packages.rst  |  3 +--
 c-user/chains.rst  |  2 +-
 c-user/clock_manager.rst   |  3 +--
 c-user/configuring_a_system.rst|  3 +--
 c-user/constant_bandwidth_server.rst   |  3 +--
 c-user/cpu_usage_statistics.rst|  3 +--
 c-user/directive_status_codes.rst  |  2 +-
 c-user/dual_ports_memory_manager.rst   |  3 +--
 c-user/event_manager.rst   |  3 +--
 c-user/example_application.rst |  3 +--
 c-user/fatal_error.rst |  3 +--
 c-user/initialization.rst  |  3 +--
 c-user/interrupt_manager.rst   |  3 +--
 c-user/io_manager.rst  |  3 +--
 c-user/key_concepts.rst|  3 +--
 c-user/linker_sets.rst |  3 +--
 c-user/message_manager.rst |  3 +--
 c-user/multiprocessing.rst |  3 +--
 c-user/object_services.rst |  3 +--
 c-user/overview.rst|  3 +--
 c-user/partition_manager.rst   |  3 +--
 c-user/pci_library.rst |  3 +--
 c-user/preface.rst |  3 +--
 c-user/rate_monotonic_manager.rst  |  5 ++---
 c-user/red_black_trees.rst |  3 +--
 c-user/region_manager.rst  |  3 +--
 c-user/rtems_data_types.rst|  3 +--
 c-user/scheduling_concepts.rst |  3 +--
 c-user/self_contained_objects.rst  |  2 +-
 c-user/semaphore_manager.rst   |  3 +--
 c-user/signal_manager.rst  |  3 +--
 c-user/stack_bounds_checker.rst|  3 +--
 c-user/symmetric_multiprocessing_services.rst  |  4 ++--
 c-user/task_manager.rst|  3 +--
 c-user/timer_manager.rst   |  3 +--
 c-user/timespec_helpers.rst|  2 +-
 c-user/user_extensions.rst |  3 +--
 cpu-supplement/altera_nios_ii.rst  |  2 +-
 cpu-supplement/arm.rst |  3 +--
 cpu-supplement/atmel_avr.rst   |  3 +--
 cpu-supplement/blackfin.rst|  2 +-
 cpu-supplement/ephiphany.rst   |  3 +--
 cpu-supplement/intel_amd_x86.rst   |  3 +--
 cpu-supplement/lattice_micro32.rst |  2 +-
 cpu-supplement/m68xxx_and_coldfire.rst |  2 +-
 cpu-supplement/mips.rst|  2 +-
 cpu-supplement/openrisc_1000.rst   |  3 +--
 cpu-supplement/port.rst|  3 +--
 cpu-supplement/powerpc.rst |  3 +--
 cpu-supplement/preface.rst |  3 +--
 cpu-supplement/renesas_m32c.rst|  3 +--
 cpu-supplement/riscv.rst   |  3 +--
 cpu-supplement/sparc.rst   |  3 +--
 cpu-supplement/sparc64.rst |  3 +--
 cpu-supplement/superh.rst  |  3 +--
 cpu-supplement/xilinx_microblaze.rst   |  3 +--
 develenv/directory.rst |  3 +--
 develenv/introduction.rst  |  3 +--
 eclipse/index.rst  |  2 +-
 eclipse/overview.rst   |  2 +-
 eclipse/rtems.rst  |  2 +-
 eng/appendix-a.rst |  2 +-
 eng/change-management.rst  |  2 +-
 eng/change-reports.rst |  2 +-
 eng/coding-80cols.rst  |  2 +-
 eng/coding-conventions.rst |  2 +-
 eng/coding-deprecating.rst |  2 +-
 eng/coding-doxygen-bsp.rst |  2 +-

Re: RSB documentation

2019-01-09 Thread Gedare Bloom 
I'm OK with this proposal.  We used to include quite messy details about
how to bootstrap your own GCC in the user manual. This is a bit nicer. ;)
At the maturity of RSB now, merging the doco with the User Manual is
sensible.

On Wed, Jan 9, 2019 at 5:55 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> the RSB has currently its own manual in the documentation set:
>
> https://docs.rtems.org/branches/master/rsb/index.html
>
> I think it would make sense to move the RSB documentation into the user
> manual as a chapter. If you are new to RTEMS, then dealing with the RSB
> is one of the first things you have to do. I think it is easier if you
> have every to get started in one manual (e.g. you can use documentation
> internal links).
>
> --
> 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: GSOC 2019 Aspirant

2019-01-09 Thread Ravindra Meena 
Thanks, I'll check them out. Hope RTEMs participates this year too! :)

On Wed, Jan 9, 2019 at 8:31 PM Shashvat Jain 
wrote:

> Hi Ravindra
> This link has a list of open projects
> https://devel.rtems.org/wiki/Developer/OpenProjects
> you can always ask the developers about projects on this list .
>
> Thank you for your interest
>
> --Shashvat
>
>
> On Wed, Jan 9, 2019 at 2:24 PM Ravindra Meena  wrote:
>
>> Hi,
>>
>> I am GSOC aspirant. I am new to RTEMs and this project interests me a
>> lot. I have set up the RTEMs development environment on Ubuntu and also
>> have run "hello world application".
>>
>> I would like to know more about it. Please, can you connect me to the
>> developers who are contributing to the RTEMs? It would be a great help if
>> you can send me the list of available projects?
>>
>> Thank you
>>
>> --
>> *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
>
>

-- 
*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

Inode inttypes.h constants not updated when ino_t changed to 64-bit

2019-01-09 Thread Joel Sherrill 
Hi

I think the subject covers it.

../../../../../../rtems/c/src/../../testsuites/psxtests/psxstat/test.c: In
function 'stat_a_file_helper':
../../../../../../rtems/c/src/../../testsuites/psxtests/psxstat/test.c:243:14:
warning: format '%lx' expects argument of type 'long unsigned int', but
argument 2 has type 'ino_t {aka long long unsigned int}' [-Wformat=]
 printf(  "...st_ino %" PRIxino_t "\n", statbuf.st_ino );
  ^ ~~
In file included from
../../../../../../rtems/c/src/../../testsuites/psxtests/../support/include/tmacros.h:21:0,
 from
../../../../../../rtems/c/src/../../testsuites/psxtests/psxstat/test.c:24:
/home/joel/rtems-work/rtems-testing/rtems/rtems/cpukit/include/rtems/inttypes.h:131:21:
note: format string is defined here
 #define PRIxino_t "lx"

A lot of warnings were introduced when this change was made which were not
addressed at the time of changing the type.

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

Re: [PATCH] Replace build date with Git hash and commit date

2019-01-09 Thread Chris Johns 
On 9/1/19 7:24 pm, Sebastian Huber wrote:
> The usage of a build date prevents reproducible builds.

Sorry to revisit this change. I have reviewed the generated the docs and they
look good and the changes are welcome, thank you. I would like to ask a few
questions.

1. Can the hash be the short version? I am seeing in the PDF in the page header:

 Release 5.0.0.05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603 (9th January 2019)

which is correct but the page header is now 2 lines and a line on a page in the
PDF is precious. In the Classic API manual at 716 pages this is 716 extra lines.
Can we use a shortened hash?

2. Should:

 5.0.0.05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603

be:

 5.0.0-05d066a08fe840f6f926bf6d2f3f3c0ebd6cc603

? This separates the version number from the hash and helps avoid confusion. For
example it took me a while to figure out if the version was 5.0.0.0 and the hash
5d066a08fe840f6f926bf6d2f3f3c0ebd6cc603. It would also be consistent with the
other places the hash is used, for example the rtems-tools programs.

3. Can the git commit date (9th January 2019) please be added to the footer line
in the HTML version? This makes the information available the PDF and HTML
equivalent.

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

Re: [PATCH 1/3] Use standard format for copyright lines

2019-01-09 Thread Chris Johns 
On 10/1/19 2:14 am, Sebastian Huber wrote:
> -.. COMMENT: COPYRIGHT (c) 1988-2008.
> -.. COMMENT: On-Line Applications Research Corporation (OAR).
> +.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)

Can this be added without being a comment? I could not find 'Copyright' as a
ReST directive.

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

Re: [PATCH 3/3] Simplify SPDX-License-Identifier comment

2019-01-09 Thread Chris Johns 
On 10/1/19 2:14 am, Sebastian Huber wrote:
> -.. comment SPDX-License-Identifier: CC-BY-SA-4.0
> +.. SPDX-License-Identifier: CC-BY-SA-4.0

Hmm, I must be missing something here with the handling of directives.

What does sphinx-build show if you can -v to the build via the waf configure
options?

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

Re: RSB documentation

2019-01-09 Thread Chris Johns 
On 10/1/19 3:41 am, Gedare Bloom wrote:
> I'm OK with this proposal.  We used to include quite messy details about how 
> to
> bootstrap your own GCC in the user manual. This is a bit nicer. ;) At the
> maturity of RSB now, merging the doco with the User Manual is sensible.

Agreed, this is sensible. I am fine with this happening.

Chris

> 
> On Wed, Jan 9, 2019 at 5:55 AM Sebastian Huber
>  >
> wrote:
> 
> Hello,
> 
> the RSB has currently its own manual in the documentation set:
> 
> https://docs.rtems.org/branches/master/rsb/index.html
> 
> I think it would make sense to move the RSB documentation into the user
> manual as a chapter. If you are new to RTEMS, then dealing with the RSB
> is one of the first things you have to do. I think it is easier if you
> have every to get started in one manual (e.g. you can use documentation
> internal links).
> 
> -- 
> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Many BSPs Fail to Link All Tests (Increased Size Issue)

2019-01-09 Thread Joel Sherrill 
Hi

Many BSPs have recently run into linking issues for a few tests. For
example, the following BSPs no longer link sp71.exe.

arm-lm3s3749
arm-lm3s6965
arm-lm4f120
arm-lpc1768_mbed_ahb_ram_eth
arm-lpc1768_mbed_ahb_ram
arm-lpc1768_mbed
arm-lpc2362
arm-lpc23xx_tli800
arm-lpc32xx_mzx_stage_1
arm-stm32f105rc
arm-stm32f4
arm-tms570ls3137_hdk_intram
arm-tms570ls3137_hdk
arm-tms570ls3137_hdk_with_loader
m68k-mcf52235
m68k-mcf5225x
powerpc-mpc5643l_dpu
powerpc-mpc5643l_evb
powerpc-mpc5668g
powerpc-mpc5674f_ecu508_app
powerpc-mpc5674f_ecu508_boot
powerpc-mpc5674fevb
powerpc-mpc5674fevb_spe
powerpc-mpc5674f_rsm6

And these no longer can link tm21.exe which I know has been around since
the dawn of time:

arm-lm3s3749
arm-lm3s6965
arm-lm4f120
arm-lpc1768_mbed_ahb_ram_eth
arm-lpc1768_mbed_ahb_ram
arm-lpc1768_mbed
arm-lpc2362
arm-lpc23xx_tli800
arm-stm32f105rc
arm-stm32f4
m68k-mcf5225x
powerpc-mpc5643l_dpu
powerpc-mpc5643l_evb

Any ideas? I hate to disable these tests on this many BSPs without an
explanation.

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

Strange RTEMS DMA Access on Zynq

2019-01-09 Thread Misra, Avinash 
Hi,


I am currently using RTEMS to access a DMA core on the Zynq and am noticing 
some interesting/peculiar behavior:


When I provide my DMA engine a statically allocated buffer what I notice is 
that the first few bytes (5) of the buffer, after getting it back from the DMA, 
remain unchanged however the rest of the buffer after that contains the data 
(minus the first 5 bytes that are missing).


When I provide my DMA engine a dynamically allocated buffer from either C++ new 
or Posix malloc() or posix_memalign() then I receive all of the data correctly 
from byte 0 to the last byte.


If I provide my DMA engine my statically allocated buffer offset by the amount 
of bytes it fails to write into then I will see all of my data from the DMA 
beginning at the offset.

Has anyone experienced something similar or have any suggestions as to what may 
be going on and/or thoughts on how to fix this behavior? I would ideally like 
to be able to do this with some statically allocated buffers.

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

Re: Strange RTEMS DMA Access on Zynq

2019-01-09 Thread Chris Johns 
On 10/1/19 2:28 pm, Misra, Avinash wrote:
> 
> I am currently using RTEMS to access a DMA core on the Zynq and am noticing 
> some
> interesting/peculiar behavior:
> 
> When I provide my DMA engine a statically allocated buffer what I notice is 
> that
> the first few bytes (5) of the buffer, after getting it back from the DMA,
> remain unchanged however the rest of the buffer after that contains the data
> (minus the first 5 bytes that are missing).
> 
> When I provide my DMA engine a dynamically allocated buffer from either C++ 
> new
> or Posix malloc() or posix_memalign() then I receive all of the data correctly
> from byte 0 to the last byte.
> 
> If I provide my DMA engine my statically allocated buffer offset by the amount
> of bytes it fails to write into then I will see all of my data from the DMA
> beginning at the offset.
> 
> Has anyone experienced something similar or have any suggestions as to what 
> may
> be going on and/or thoughts on how to fix this behavior? I would ideally like 
> to
> be able to do this with some statically allocated buffers.
> 

The compiler's default alignment for the buffer will not be the same as the DMA
engine. You will need to use the alignment.

What is the alignment requirement for the DMA engine? You will need to add this
to the size of the static buffer and use an offset into the buffer that meets
the DMA engine's alignment.

Do not forget to invalidate the cache once the DMA engine has finished.

Are you using the CDMA IP?

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

Re: [PATCH 3/3] Simplify SPDX-License-Identifier comment

2019-01-09 Thread Sebastian Huber 

On 10/01/2019 00:49, Chris Johns wrote:

On 10/1/19 2:14 am, Sebastian Huber wrote:

-.. comment SPDX-License-Identifier: CC-BY-SA-4.0
+.. SPDX-License-Identifier: CC-BY-SA-4.0

Hmm, I must be missing something here with the handling of directives.

What does sphinx-build show if you can -v to the build via the waf configure
options?


http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#comments

"Every explicit markup block which isn’t a valid markup construct (like 
the footnotes above) is regarded as a comment"


The main reason to cut the "comment" is the long OAR copyright line 
which would otherwise exceed 80 characters:


.. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)

--
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: Many BSPs Fail to Link All Tests (Increased Size Issue)

2019-01-09 Thread Sebastian Huber 

On 10/01/2019 01:39, Joel Sherrill wrote:

Hi

Many BSPs have recently run into linking issues for a few tests. For 
example, the following BSPs no longer link sp71.exe.


arm-lm3s3749
arm-lm3s6965
arm-lm4f120
arm-lpc1768_mbed_ahb_ram_eth
arm-lpc1768_mbed_ahb_ram
arm-lpc1768_mbed
arm-lpc2362
arm-lpc23xx_tli800
arm-lpc32xx_mzx_stage_1
arm-stm32f105rc
arm-stm32f4
arm-tms570ls3137_hdk_intram
arm-tms570ls3137_hdk
arm-tms570ls3137_hdk_with_loader
m68k-mcf52235
m68k-mcf5225x
powerpc-mpc5643l_dpu
powerpc-mpc5643l_evb
powerpc-mpc5668g
powerpc-mpc5674f_ecu508_app
powerpc-mpc5674f_ecu508_boot
powerpc-mpc5674fevb
powerpc-mpc5674fevb_spe
powerpc-mpc5674f_rsm6

And these no longer can link tm21.exe which I know has been around 
since the dawn of time:


arm-lm3s3749
arm-lm3s6965
arm-lm4f120
arm-lpc1768_mbed_ahb_ram_eth
arm-lpc1768_mbed_ahb_ram
arm-lpc1768_mbed
arm-lpc2362
arm-lpc23xx_tli800
arm-stm32f105rc
arm-stm32f4
m68k-mcf5225x
powerpc-mpc5643l_dpu
powerpc-mpc5643l_evb

Any ideas? I hate to disable these tests on this many BSPs without an 
explanation.


The size increased due to this:

https://devel.rtems.org/ticket/3621

A run-time error (INTERNAL_ERROR_TOO_LITTLE_WORKSPACE) changed into a 
link-time error.


--
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