codingstyle: usage of #include and #include "head.h"

2016-04-28 Thread printk 
What is the difference in RTEMS?

there are code use #include "xxx.h" reference to xxx.h not located
in the current folder.
how about just use #include "xxx.h" to include the file in current folder?
and use #include  to include files in -isystem -I...

this usage find in 
  cpukit/lib/networking/

...
duhuanpeng.
u74147＠gmail.com


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

Re: [PATCH 00/13] Replace mongoose with civetweb.

2016-04-28 Thread Christian Mauderer 


Am 27.04.2016 um 02:07 schrieb Chris Johns:
> On 26/04/2016 22:22, Christian Mauderer wrote:
>> Am 26.04.2016 um 04:51 schrieb Chris Johns:
>>> On 26/04/2016 07:22, Joel Sherrill wrote:

[removed part not relevant for this part of the discussion]
   >>
   >> 2. Currently there is one test case for mghttpd
  (libtests/mghttpd01).
   >> This is one of the few tests that check some networking
 functions in
   >> RTEMS.
>>>
>>> I would be concerned if the only way we can do network testing is to
>>> consume a 3prd party package's source into RTEMS. :)
>>
>> It's not the only test that tests network functions in RTEMS. But as far
>> as I know, there are not many. If we remove it, it will be one less.
> 
> I do not have a simple answer. I have a radical one, split the testsuite
> in 2, with the part in RTEMS specific to the internal and API parts of
> RTEMS, and a second repo that is the tests that depend on "other" parts,
> eg 3rd party libraries. Those tests could configure which tests are
> built depending on the libraries detected. The work flow would need to
> be fast and easy to ensure a speedy compile/test cycle.
> 
> I am going on a bit about this stuff, but I feel it is important. In
> time we will have Buildbot running and we will need to get this stuff
> integrated and my hope is Buildbot, developers and users all use the
> same work flow.
> 
>>
>>>
 Further we should not loose the ability to test software
  when it
   >> is build with RSB.
>>>
>>> I agree.
>>>
 How would we handle tests for software in RSB?
   >>
   >
   > That's a Chris question. We should aim to have tests which run
 with
   > either network stack for RSB built network services. This is a
 good
   > requirement on the plan to moving to separately built network
 stacks
   > and services.
>>>
>>> Network testing is an open topic as is vertically integrated packages.
>>> The testing issues exists with libbsd, lwip and the in-tree stack once
>>> we move out of the source tree. As we flesh out the details of
>>> vertically integrating packages we need to figure out now to manage
>>> testing.
>>>
>>> What tests does civetweb provide? If the test is important I would
>>> assume it is important to all users. Can civetweb build the test?
>>>
>>
>> Civetweb has a number of tests. But I think that most would not work
>> with RTEMS without changing them. In RTEMS we currently have a
>> relatively simple testcase that just checks some basic functions.
> 
> OK.
> 
>>
>> I don't think that we would be able to run either of them with the
>> current RSB. And I don't have enough time to integrate a way for testing
>> into RSB within the current project. So moving civetweb out of RTEMS
>> currently means that it is not tested any longer with an RTEMS system
>> (or only if someone does it manually after changing something).
> 
> I do not think the RSB is the way forward for testing. It could build
> tests as a package but that would be the extent. We have rtems-test in
> the tools repo but it is need of further work.
> 
> I do not think we will find a suitable answer for testing in the short
> term. I suspect a second testsuite package may be the answer.
> 
> Chris

I put some work into building civetweb using RSB. My configuration is
now able to build a "libcivetweb.a" using the Makefile of civetweb.

The next steps would be to remove mghttpd from RTEMS. Currently that
means that I have to remove the test too. Any ideas where we could move
it to? If we don't have a solution: Do we really want to leave the code
untested until someone has the time and budget to implement a external
test suit?

Theoretically it should be possible to build and install the libcivetweb
without a RTEMS BSP. When building the BSP, we could detect if the
"civetweb.h" file is there using autoconf and either build the mghttpd01
test or not depending on the result. This would allow it to keep an
RTEMS-specific test for civetweb inside the RTEMS repository.

The only problem is: Currently there is no way to build civetweb prior
to the BSP. Civetweb uses some of the network headers that are currently
provided by the BSP. So the process would extend to the following:
- build BSP (without mghttpd01 test)
- build civetweb
- re-build BSP (this time with mghttpd01 test)
- run tests

This could be solved by moving the network headers into newlib like
suggested in the other thread of discussion.

Kind regards,

Christian

-- 

embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.

RPi mailbox and non-problematic part of VideoCore access support

2016-04-28 Thread Pavel Pisa 
Hello everybody,

there are Yang Qiao patches updated for RTEMS 4.12.
I have checked that RTEMS build after applying.
I have not tested them on target.

But but there should be minimal impact. I have removed initialization
of VideoCore and required changes in memory mapping from basic patches
set because this part has to be redone.

This means that actual code should be usable as library of functions
reusable from other drivers and applications for now but VideoCore
faramebuffer is not activated by default/should not cause problems.

There is added call of mailbox access during initialization
to obtain command line passed to the application from boot
cmdline.txt file.

Be warned, that it is not that command line which is passed
to loaded kernel from U-boot (if U-boot is used).

The command line is read through mailbox twice,
it has to be available as early as possible when
rest of patches is in the use and it is used first time
before memory areas/workspace is set. May it be, that one call
can be eliminated, but I am not sure if BSS clean does not
been problem there. At least Yang Qiao has added the second call.
If RTEMS start blocks on the rpi_init_cmdline() call then
we know that mailbox interface has problems so everithing
works on RPi1 and RPi2 then basic mailbox works.
If there is problem try to remove rpi_init_cmdline() to
confirm that it is source of problems.


+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c
@@ -26,4 +26,5 @@
 void bsp_start(void)
 {
 bsp_interrupt_initialize();
+rpi_init_cmdline();
 }
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
@@ -7,6 +7,7 @@
@@ -29,6 +30,7 @@
 
 void BSP_START_TEXT_SECTION bsp_start_hook_0(void)
 {
+  rpi_init_cmdline();
 }

The proposed patches

  arm/raspberrypi: add VideoCore framebuffer without initialization
  arm/raspberrypi: add VideoCore frame buffer control support
  arm/raspberrypi: add cmdline support for rpi bsp 
  arm/raspberrypi: add VideoCore framebuffer without initialization

If there is agreement that they are OK or some minor adjustment
are enough and somebody tests that they do not break any of RPi1 and RPi2
then I update these patches and push them to RTEMS master.

The problematic patch is

  arm/raspberrypi: call VideoCore framebuffer initialization

I am sending that one too but memory mapping has to be redone.
Proposed 

 RAM_MMU(AIW) : ORIGIN = 256M - 64M - 16k, LENGTH = 16k

is broken because memory division between VideoCore and ARM CPU
is configurable and if translation table overlaps VideoCore memory
then bad things can happen. On the other hand if the end of
memory is set at too low address then we cannot utilize more memory
for workspace if VideoCore reports the limit higher.

There are next options

 1) put RAM_MMU to the address 0x4000 or 0xC000 (16 kB should be enough I hope),
RTEMS uses memory only above 0x8000. The end of usable RAM can be obtained
through mailbox interface and and used to setup workarea size

I see only one possible problem with this interface now and it is that
this area can be used by boot loader to pass ATAGs or device-tree
which should be used one day by RPi RTEMS to obtain command line
and other information provided by original Broadcom boot code and U-boot.
Actual size an location of FDT does not overlap with 0x8000+ adsres
but FDT is nearly 32 kB now so there can arise problem in future.

 2) put RAM_MMU at fixed, safe location, for example below 64 MB and setup
only small workspace first and then add area from 64 MB to memory
division limit to memory pool later. I am not sure how this should
be done correct way, because standard RTEMS memory setup which I know
gets continuous area and divides it between regions in one go.

 3) do not setup fixed RAM_MMU region at all, take memory division
address from mailbox, round it down to 16 kB, then subtract 16 kB
and setup translation table there. Then use standard RTEMS workspace
setup for range ending before translation table start.

The 1) is simplest but limits region size used to pass data by loader.
So I would like to hear what do you think about these options and some
suggestion which RTEMS provided functions should be used. I have that
analyzed much better lays year but I do not remember all my findings now.

Best wishes,

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

[PATCH 1/4] arm/raspberrypi: add VideoCore mailbox support read and write

2016-04-28 Thread Pavel Pisa 
From: YANG Qiao 
Date: Thu, 13 Aug 2015 00:04:33 +0200

---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am   |  4 ++
 c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h | 32 +
 .../libbsp/arm/raspberrypi/include/raspberrypi.h   | 49 +++
 c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c| 56 ++
 c/src/lib/libbsp/arm/raspberrypi/preinstall.am |  4 ++
 5 files changed, 145 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index a092a28..2d74c68 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -48,6 +48,7 @@ include_bsp_HEADERS += include/raspberrypi.h
 include_bsp_HEADERS += include/rpi-gpio.h
 include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/spi.h
+include_bsp_HEADERS += include/mailbox.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
 ../../../libcpu/arm/shared/include/arm-cp15.h
@@ -112,6 +113,9 @@ libbsp_a_SOURCES += ../../shared/console_write.c
 libbsp_a_SOURCES += console/console-config.c
 libbsp_a_SOURCES += console/usart.c
 
+# Mailbox
+libbsp_a_SOURCES += misc/mailbox.c
+
 # clock
 libbsp_a_SOURCES += clock/clockdrv.c ../../../shared/clockdrv_shell.h
 
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
new file mode 100644
index 000..e6cb0f8
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/mailbox.h
@@ -0,0 +1,32 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *
+ *  http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#ifndef LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+#define LIBBSP_ARM_RASPBERRYPI_MAILBOX_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern unsigned int  raspberrypi_mailbox_read(unsigned int channel);
+extern void raspberrypi_mailbox_write(unsigned int channel, unsigned int data);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif  /* LIBBSP_ARM_RASPBERRYPI_MAILBOX_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
index 2a4d772..ebb31cf 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/raspberrypi.h
@@ -9,6 +9,7 @@
 /*
  *  Copyright (c) 2014-2015 Andre Marques 
  *  Copyright (c) 2013 Alan Cudmore.
+ *  Copyright (c) 2015 Yang Qiao
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -287,6 +288,54 @@
 
 /** @} */
 
+/**
+* @name Mailbox Registers
+*
+* @{
+*/
+
+#define BCM2835_MBOX_BASE   (RPI_PERIPHERAL_BASE+0xB880)
+
+#define BCM2835_MBOX_PEEK   (BCM2835_MBOX_BASE+0x10)
+#define BCM2835_MBOX_READ   (BCM2835_MBOX_BASE+0x00)
+#define BCM2835_MBOX_WRITE  (BCM2835_MBOX_BASE+0x20)
+#define BCM2835_MBOX_STATUS (BCM2835_MBOX_BASE+0x18)
+#define BCM2835_MBOX_SENDER (BCM2835_MBOX_BASE+0x14)
+#define BCM2835_MBOX_CONFIG (BCM2835_MBOX_BASE+0x1C)
+
+#define BCM2835_MBOX_FULL   (BCM2835_MBOX_BASE+0x8000)
+#define BCM2835_MBOX_EMPTY  (BCM2835_MBOX_BASE+0x4000)
+
+/** @} */
+
+/**
+* @name Mailbox Channels
+*
+* @{
+*/
+
+/* Power Manager channel */
+#define BCM2835_MBOX_CHANNEL_PM 0
+/* Framebuffer channel */
+#define BCM2835_MBOX_CHANNEL_FB 1
+ /* Virtual UART channel */
+#define BCM2835_MBOX_CHANNEL_VUART  2
+ /* VCHIQ channel */
+#define BCM2835_MBOX_CHANNEL_VCHIQ  3
+ /* LEDs channel */
+#define BCM2835_MBOX_CHANNEL_LED4
+ /* Button channel */
+#define BCM2835_MBOX_CHANNEL_BUTTON 5
+ /* Touch screen channel */
+#define BCM2835_MBOX_CHANNEL_TOUCHS 6
+/* Property tags (ARM <-> VC) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_AVC   8
+ /* Property tags (VC <-> ARM) channel */
+#define BCM2835_MBOX_CHANNEL_PROP_VCA   9
+
+/** @} */
+
+
 /** @} */
 
 #endif /* LIBBSP_ARM_RASPBERRYPI_RASPBERRYPI_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c 
b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
new file mode 100644
index 000..8ec730a
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/misc/mailbox.c
@@ -0,0 +1,56 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *
+ *  http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#define BCM2835_MBOX_DATA_MASK(data) (data & 0xFFF0U)
+#define BCM2835_MBOX_CHANNEL_M

[PATCH 2/4] arm/raspberrypi: add VideoCore frame buffer control support

2016-04-28 Thread Pavel Pisa 
From: YANG Qiao 
Date: Thu, 13 Aug 2015 00:05:34 +0200

---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am   |   4 +
 c/src/lib/libbsp/arm/raspberrypi/include/vc.h  | 140 +++
 c/src/lib/libbsp/arm/raspberrypi/misc/vc.c | 248 
 c/src/lib/libbsp/arm/raspberrypi/misc/vc_defines.h | 436 +
 c/src/lib/libbsp/arm/raspberrypi/preinstall.am |   4 +
 5 files changed, 832 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/include/vc.h
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/misc/vc_defines.h

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 2d74c68..91f327e 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -49,6 +49,7 @@ include_bsp_HEADERS += include/rpi-gpio.h
 include_bsp_HEADERS += include/i2c.h
 include_bsp_HEADERS += include/spi.h
 include_bsp_HEADERS += include/mailbox.h
+include_bsp_HEADERS += include/vc.h
 
 include_libcpu_HEADERS = ../../../libcpu/arm/shared/include/cache_.h \
 ../../../libcpu/arm/shared/include/arm-cp15.h
@@ -116,6 +117,9 @@ libbsp_a_SOURCES += console/usart.c
 # Mailbox
 libbsp_a_SOURCES += misc/mailbox.c
 
+# VideoCore
+libbsp_a_SOURCES += misc/vc.c
+
 # clock
 libbsp_a_SOURCES += clock/clockdrv.c ../../../shared/clockdrv_shell.h
 
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/vc.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/vc.h
new file mode 100644
index 000..4e91fde
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/vc.h
@@ -0,0 +1,140 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi_vc
+ *
+ * @brief video core support.
+ *
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *
+ *  http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#ifndef LIBBSP_ARM_RASPBERRYPI_VC_H
+#define LIBBSP_ARM_RASPBERRYPI_VC_H
+
+/**
+ * @defgroup raspberrypi_vc Register Definitions
+ *
+ * @ingroup arm_raspberrypi
+ *
+ * @brief Register Definitions
+ *
+ * @{
+ */
+
+typedef struct
+{
+  uint32_t width;
+  uint32_t height;
+} bcm2835_get_display_size_entries;
+
+int
+bcm2835_mailbox_get_display_size(bcm2835_get_display_size_entries* _entries);
+
+
+typedef enum
+{
+  bcm2835_mailbox_pixel_order_bgr = 0,
+  bcm2835_mailbox_pixel_order_rgb = 1
+} bcm2835_pixel_order;
+
+typedef enum
+{
+  bcm2835_mailbox_alpha_mode_0_opaque   = 0,
+  bcm2835_mailbox_alpha_mode_0_transparent  = 1,
+  bcm2835_mailbox_alpha_mode_ignored= 2
+} bcm2835_alpha_mode;
+
+typedef struct
+{
+  uint32_t xres;
+  uint32_t yres;
+  uint32_t xvirt;
+  uint32_t yvirt;
+  uint32_t depth;
+  bcm2835_pixel_order pixel_order;
+  bcm2835_alpha_mode alpha_mode;
+  uint32_t voffset_x;
+  uint32_t voffset_y;
+  uint32_t overscan_left;
+  uint32_t overscan_right;
+  uint32_t overscan_top;
+  uint32_t overscan_bottom;
+  uint32_t base;
+  size_t size;
+  uint32_t pitch;
+} bcm2835_init_frame_buffer_entries;
+
+int
+bcm2835_mailbox_init_frame_buffer(bcm2835_init_frame_buffer_entries* _entries);
+
+typedef struct
+{
+  uint32_t pitch;
+}bcm2835_get_pitch_entries;
+
+int
+bcm2835_mailbox_get_pitch(bcm2835_get_pitch_entries* _entries);
+
+typedef struct
+{
+  char cmdline[1024];
+} bcm2835_get_cmdline_entries;
+
+int
+bcm2835_mailbox_get_cmdline(bcm2835_get_cmdline_entries* _entries);
+
+typedef enum
+{
+  bcm2835_mailbox_power_udid_sd_card = 0xu,
+  bcm2835_mailbox_power_udid_uart0 = 0x0001u,
+  bcm2835_mailbox_power_udid_uart1 = 0x0002u,
+  bcm2835_mailbox_power_udid_usb_hcd = 0x0003u,
+  bcm2835_mailbox_power_udid_i2c0 = 0x0004u,
+  bcm2835_mailbox_power_udid_i2c1 = 0x0005u,
+  bcm2835_mailbox_power_udid_i2c2 = 0x0006u,
+  bcm2835_mailbox_power_udid_spi = 0x0007u,
+  bcm2835_mailbox_power_udid_ccp2tx = 0x0008u,
+} bcm2835_power_device_id;
+
+typedef struct
+{
+  bcm2835_power_device_id dev_id;
+  uint32_t state;
+} bcm2835_set_power_state_entries;
+
+#define BCM2835_MAILBOX_SET_POWER_STATE_REQ_ON(1 << 0)
+#define BCM2835_MAILBOX_SET_POWER_STATE_REQ_WAIT  (1 << 1)
+#define BCM2835_MAILBOX_POWER_STATE_ON   (1 << 0)
+#define BCM2835_MAILBOX_POWER_STATE_NODEV(1 << 1)
+int
+bcm2835_mailbox_set_power_state(bcm2835_set_power_state_entries* _entries);
+
+typedef struct
+{
+  uint32_t base;
+  size_t   size;
+}bcm2835_get_arm_memory_entries;
+
+int
+bcm2835_mailbox_get_arm_memory(bcm2835_get_arm_memory_entries* _entries);
+
+typedef struct
+{
+  uint32_t base;
+  size_t   size;
+}bcm2835_get_vc_memory_entries;
+
+int
+bcm2835_mailbox_get_vc_memory(bcm2835_get_vc_memory_entries* _entries);
+/** @} */
+
+#endif /* LIBBSP_ARM_RASPBERRYPI_VC_H */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c 
b/c/src/lib/libbsp/arm/raspberrypi/misc/vc.c
new file mode 100644
index 000..d1d08ba
--- /de

[PATCH 3/4] arm/raspberrypi: add cmdline support for rpi bsp

2016-04-28 Thread Pavel Pisa 
From: YANG Qiao 
Date: Thu, 13 Aug 2015 00:05:52 +0200

---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am   |  1 +
 c/src/lib/libbsp/arm/raspberrypi/include/bsp.h |  5 +++
 .../lib/libbsp/arm/raspberrypi/startup/bspstart.c  |  1 +
 .../libbsp/arm/raspberrypi/startup/bspstarthooks.c |  2 ++
 c/src/lib/libbsp/arm/raspberrypi/startup/cmdline.c | 40 ++
 5 files changed, 49 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/startup/cmdline.c

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 91f327e..258f8a0 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -95,6 +95,7 @@ libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
 # Startup
 libbsp_a_SOURCES += ../../shared/bspreset_loop.c
 libbsp_a_SOURCES += startup/bspstart.c
+libbsp_a_SOURCES += startup/cmdline.c
 
 # IRQ
 libbsp_a_SOURCES += ../shared/arm-cp15-set-exception-handler.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
index 0abeed6..d8319c6 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -7,6 +7,7 @@
  */
 
 /*
+ * Copyright (c) 2015 Yang Qiao
  * Copyright (c) 2013 Alan Cudmore
  *
  *  The license and distribution terms for this file may be
@@ -35,6 +36,10 @@ extern "C" {
 #define BSP_GPIO_PINS_PER_BANK 32
 #define BSP_GPIO_PINS_PER_SELECT_BANK 10
 
+void rpi_init_cmdline(void);
+const char* rpi_cmdline(void);
+const char* rpi_cmdline_arg(const char* arg);
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c
index c5786bf..884d5ef 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstart.c
@@ -26,4 +26,5 @@
 void bsp_start(void)
 {
 bsp_interrupt_initialize();
+rpi_init_cmdline();
 }
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
index 047c8ad..7d72fe7 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstarthooks.c
@@ -7,6 +7,7 @@
  */
 
 /*
+ * Copyright (c) 2015 Yang Qiao
  * Copyright (c) 2013. Hesham AL-Matary
  * Copyright (c) 2013 by Alan Cudmore
  * based on work by:
@@ -29,6 +30,7 @@
 
 void BSP_START_TEXT_SECTION bsp_start_hook_0(void)
 {
+  rpi_init_cmdline();
 }
 
 
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/cmdline.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/cmdline.c
new file mode 100644
index 000..c1ed29a
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/cmdline.c
@@ -0,0 +1,40 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief mailbox support.
+ */
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *
+ *  http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#include 
+#include 
+
+#define MAX_CMDLINE_LENGTH 1024
+static char* _rpi_cmdline;
+static bcm2835_get_cmdline_entries get_cmdline_entries;
+
+void rpi_init_cmdline(void)
+{
+  bcm2835_get_cmdline_entries get_cmdline_entries;
+  bcm2835_mailbox_get_cmdline(&get_cmdline_entries);
+  _rpi_cmdline = get_cmdline_entries.cmdline;
+}
+
+const char* rpi_cmdline(void)
+{
+  return _rpi_cmdline;
+}
+
+const char* rpi_cmdline_arg(const char* arg)
+{
+  return strstr (rpi_cmdline (), arg);
+}
-- 
1.9.1

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

[PATCH 4/4] arm/raspberrypi: add VideoCore framebuffer without initialization

2016-04-28 Thread Pavel Pisa 
From: YANG Qiao 
Date: Thu, 13 Aug 2015 00:06:10 +0200

---
 c/src/lib/libbsp/arm/raspberrypi/Makefile.am  |   1 +
 c/src/lib/libbsp/arm/raspberrypi/console/fb.c | 331 ++
 2 files changed, 332 insertions(+)
 create mode 100644 c/src/lib/libbsp/arm/raspberrypi/console/fb.c

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 258f8a0..77935dc 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -114,6 +114,7 @@ libbsp_a_SOURCES += ../../shared/console_select.c
 libbsp_a_SOURCES += ../../shared/console_write.c
 libbsp_a_SOURCES += console/console-config.c
 libbsp_a_SOURCES += console/usart.c
+libbsp_a_SOURCES += console/fb.c
 
 # Mailbox
 libbsp_a_SOURCES += misc/mailbox.c
diff --git a/c/src/lib/libbsp/arm/raspberrypi/console/fb.c 
b/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
new file mode 100644
index 000..a83d560
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/console/fb.c
@@ -0,0 +1,331 @@
+/**
+ * @file
+ *
+ * @ingroup raspberrypi
+ *
+ * @brief framebuffer support.
+ */
+
+/*
+ * Copyright (c) 2015 Yang Qiao
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *
+ *  http://www.rtems.org/license/LICENSE
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define SCREEN_WIDTH 1024
+#define SCREEN_HEIGHT 768
+#define BPP 32
+#define BUFFER_SIZE (SCREEN_WIDTH*SCREEN_HEIGHT*BPP/8)
+
+/* flag to limit driver to protect against multiple opens */
+static Atomic_Flag driver_mutex;
+
+/*
+ * screen information for the driver (fb0).
+ */
+
+static struct fb_var_screeninfo fb_var_info = {
+  .xres= SCREEN_WIDTH,
+  .yres= SCREEN_HEIGHT,
+  .bits_per_pixel  = BPP
+};
+
+static struct fb_fix_screeninfo fb_fix_info = {
+  .smem_start  = (void *) NULL,
+  .smem_len= 0,
+  .type= FB_TYPE_PACKED_PIXELS,
+  .visual  = FB_VISUAL_TRUECOLOR,
+  .line_length = 0
+};
+
+int raspberrypi_get_fix_screen_info( struct fb_fix_screeninfo *info )
+{
+  *info = fb_fix_info;
+  return 0;
+}
+
+int raspberrypi_get_var_screen_info( struct fb_var_screeninfo *info )
+{
+  *info = fb_var_info;
+  return 0;
+}
+
+static int
+find_mode_from_cmdline(void)
+{
+  const char* opt;
+  char* endptr;
+  uint32_t width;
+  uint32_t height;
+  uint32_t bpp;
+  opt = rpi_cmdline_arg("--video=");
+  if (opt)
+  {
+  opt += sizeof("--video=")-1;
+  width = strtol(opt, &endptr, 10);
+  if (*endptr != 'x')
+  {
+  return -2;
+  }
+  opt = endptr+1;
+  height = strtol(opt, &endptr, 10);
+  switch (*endptr)
+  {
+  case '-':
+  opt = endptr+1;
+  if (strlen(opt) <= 2)
+  bpp = strtol(opt, &endptr, 10);
+  else
+  {
+  bpp = strtol(opt, &endptr, 10);
+  if (*endptr != ' ')
+  {
+  return -4;
+  }
+  }
+  case ' ':
+  case 0:
+  break;
+  default:
+  return -3;
+  }
+  }
+  else
+return -1;
+
+  fb_var_info.xres= width;
+  fb_var_info.yres= height;
+
+  return 0;
+}
+
+static int
+find_mode_from_vc(void)
+{
+  bcm2835_get_display_size_entries entries;
+  bcm2835_mailbox_get_display_size(&entries);
+  unsigned int width = entries.width;
+  unsigned int height = entries.height;
+
+  if (width == 0 || height == 0)
+  {
+fb_var_info.xres= SCREEN_WIDTH;
+fb_var_info.yres= SCREEN_HEIGHT;
+  }
+  else
+  {
+fb_var_info.xres = width;
+fb_var_info.yres = height;
+  }
+
+  return 0;
+}
+
+static bool
+hdmi_is_present(void)
+{
+  bcm2835_get_display_size_entries entries;
+  bcm2835_mailbox_get_display_size(&entries);
+  if(entries.width == 0x290 && entries.height ==0x1A0 )
+  {
+return false;
+  }
+  else
+  {
+return true;
+  }
+}
+
+int
+fb_init(void)
+{
+  if (fb_fix_info.smem_start != NULL)
+  {
+return -2;
+  }
+
+  if (hdmi_is_present() == false)
+  {
+return -3;
+  }
+
+  if (find_mode_from_cmdline())
+  {
+if(find_mode_from_vc())
+  return -1;
+  }
+
+  bcm2835_init_frame_buffer_entries  init_frame_buffer_entries;
+  init_frame_buffer_entries.xres = fb_var_info.xres;
+  init_frame_buffer_entries.yres = fb_var_info.yres;
+  init_frame_buffer_entries.xvirt = fb_var_info.xres;
+  init_frame_buffer_entries.yvirt = fb_var_info.yres;
+  init_frame_buffer_entries.depth = fb_var_info.bits_per_pixel;
+  init_frame_buffer_entries.pixel_order = bcm2835_mailbox_pixel_order_rgb;
+  init_frame_buffer_entries.alpha_mode = bcm2835_mailbox_alpha_mode_0_opaque;
+  init_frame_buffer_entries.voffset_x = 0;
+  init_frame_buffer_entries.vo

[PATCH has to be redone] arm/raspberrypi: call VideoCore framebuffer initialization

2016-04-28 Thread Pavel Pisa 
From: YANG Qiao 
Date: Thu, 13 Aug 2015 00:06:10 +0200

--
This change is reason I have asked for update and more checking
and didnot proposed patches for mainlining at end of 2015 GSoC.

diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am 
b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
index 258f8a0..5faca68 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
+++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
@@ -82,7 +82,6 @@ libbsp_a_LIBADD =
 # Shared
 libbsp_a_SOURCES += ../../shared/bootcard.c
 libbsp_a_SOURCES += ../../shared/bspclean.c
-libbsp_a_SOURCES += ../../shared/bspgetworkarea.c
 libbsp_a_SOURCES += ../../shared/bsppredriverhook.c
 libbsp_a_SOURCES += ../../shared/cpucounterread.c
 libbsp_a_SOURCES += ../../shared/cpucounterdiff.c
@@ -96,6 +95,7 @@ libbsp_a_SOURCES += ../shared/arm-cp15-set-ttb-entries.c
 libbsp_a_SOURCES += ../../shared/bspreset_loop.c
 libbsp_a_SOURCES += startup/bspstart.c
 libbsp_a_SOURCES += startup/cmdline.c
+libbsp_a_SOURCES += startup/bspgetworkarea.c
 
 # IRQ
 libbsp_a_SOURCES += ../shared/arm-cp15-set-exception-handler.c
@@ -151,7 +152,7 @@ libbsp_a_SOURCES += startup/bspstarthooks.c
 
 # LIBMM
 libbsp_a_SOURCES += startup/mm_config_table.c
-libbsp_a_SOURCES += ../shared/mminit.c
+libbsp_a_SOURCES += startup/mminit.c
 
 ###
 # Network#
diff --git a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h 
b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
index d8319c6..06c2240 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
+++ b/c/src/lib/libbsp/arm/raspberrypi/include/bsp.h
@@ -32,6 +32,8 @@ extern "C" {
 
 #define BSP_FEATURE_IRQ_EXTENSION
 
+#define RPI_L2_CACHE_ENABLE 1
+
 #define BSP_GPIO_PIN_COUNT 32
 #define BSP_GPIO_PINS_PER_BANK 32
 #define BSP_GPIO_PINS_PER_SELECT_BANK 10
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/bspgetworkarea.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/bspgetworkarea.c
new file mode 100644
index 000..07a38e9
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspgetworkarea.c
@@ -0,0 +1,61 @@
+/**
+ * @file
+ *
+ * @ingroup arm_start
+ *
+ * @brief Raspberry pi workarea initialization.
+ *
+ *  COPYRIGHT (c) 1989-2008.
+ *  On-Line Applications Research Corporation (OAR).
+ *
+ *  Copyright (c) 2011-2012 embedded brains GmbH.
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ *
+ *  Copyright (c) 2015 YANG Qiao
+ */
+
+#include 
+#include 
+#include 
+#ifdef BSP_INTERRUPT_STACK_AT_WORK_AREA_BEGIN
+  #include 
+#endif
+
+#if defined(HAS_UBOOT) && !defined(BSP_DISABLE_UBOOT_WORK_AREA_CONFIG)
+  #define USE_UBOOT
+#endif
+
+extern char WorkAreaBase[];
+
+#ifdef USE_UBOOT
+  #include 
+#else
+  extern char RamBase[];
+  extern char RamSize[];
+#endif
+
+void bsp_work_area_initialize(void)
+{
+  uintptr_t work_base = (uintptr_t) WorkAreaBase;
+  uintptr_t ram_end;
+  bcm2835_get_arm_memory_entries arm_entry;
+  bcm2835_get_vc_memory_entries vc_entry;
+
+  #ifdef USE_UBOOT
+ram_end = (uintptr_t) bsp_uboot_board_info.bi_memstart +
+  bsp_uboot_board_info.bi_memsize;
+  #else
+ram_end = (uintptr_t)RamBase + (uintptr_t)RamSize;
+  #endif
+
+  #ifdef BSP_INTERRUPT_STACK_AT_WORK_AREA_BEGIN
+work_base += rtems_configuration_get_interrupt_stack_size();
+  #endif
+
+  bcm2835_mailbox_get_vc_memory(&vc_entry);
+  ram_end = ram_end>vc_entry.base? vc_entry.base: ram_end;
+  bsp_work_area_initialize_default( (void *) work_base, ram_end - work_base );
+}
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds 
b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds
index f1ad11c..81d4f8d 100644
--- a/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/linkcmds
@@ -37,8 +37,9 @@
 
 MEMORY {
 VECTOR_RAM (AIW) : ORIGIN = 0x0   , LENGTH = 0x8000
-RAM(AIW) : ORIGIN = 0x8000, LENGTH = 128M - 48K
-   RAM_MMU(AIW) : ORIGIN = 128M - 16k, LENGTH = 16k
+GPU_RAM(AIW) : ORIGIN = 256M - 64M, LENGTH = 64M
+RAM(AIW) : ORIGIN = 0x8000, LENGTH = 256M - 64M - 48K
+   RAM_MMU(AIW) : ORIGIN = 256M - 64M - 16k, LENGTH = 16k
 }
 
 REGION_ALIAS ("REGION_START", RAM);
diff --git a/c/src/lib/libbsp/arm/raspberrypi/startup/mminit.c 
b/c/src/lib/libbsp/arm/raspberrypi/startup/mminit.c
new file mode 100644
index 000..e012060
--- /dev/null
+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/mminit.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2015 Yang Qiao
+ * based on work by:
+ * Copyright (c) 2013 Hesham AL-Matary.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#define ARM_CP15_TEXT_SECTION BSP_START

State of the Omniorb port for RTEMS

2016-04-28 Thread Sambeet Panigrahi 
Hi,
Omniorb is an  important part of the Orocos RTT that needs to be ported to
RTEMS.I found that it has already been ported to RTEMS.But all sources
point to this link which is dead:


http://www.uk.research.att.com/omniORB/omniORB.html

Can someone please tell me about the state of the port and point me towards
the right sources?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSOC2016: Improvements in RTEMS Tracing Framework

2016-04-28 Thread vivek kukreja 
Hello all

Thank you for your help and support. My proposal for Tracing tool
improvements has been accepted in GSOC 2016.

I will be occupied with university exams for the rest of this week. I
will update the RTEMS page over the weekend. I will be able to commit
full-time to the project in the coming weeks during my vacations.

I am thrilled to start working on this project!

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

Re: State of the Omniorb port for RTEMS

2016-04-28 Thread Karel Gardas 


Hi,

you can also ask on omniORB mailing list(s). http://omniorb.sourceforge.net/

Cheers,
Karel

On 04/28/16 09:54 PM, Sambeet Panigrahi wrote:

Hi,
Omniorb is an  important part of the Orocos RTT that needs to be ported
to RTEMS.I found that it has already been ported to RTEMS.But all
sources point to this link which is dead:


http://www.uk.research.att.com/omniORB/omniORB.html

Can someone please tell me about the state of the port and point me
towards the right sources?


___
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 00/13] Replace mongoose with civetweb.

2016-04-28 Thread Chris Johns 

On 28/04/2016 18:27, Christian Mauderer wrote:

Am 27.04.2016 um 02:07 schrieb Chris Johns:

On 26/04/2016 22:22, Christian Mauderer wrote:

Am 26.04.2016 um 04:51 schrieb Chris Johns:

On 26/04/2016 07:22, Joel Sherrill wrote:



I put some work into building civetweb using RSB. My configuration is
now able to build a "libcivetweb.a" using the Makefile of civetweb.


Excellent. GNU make is available in the RSB on all hosts.

How do we package this Makefile?

We have a few things happening we need to land in a coordinated manner. 
We have this work, libbsd, LwIP, and the removal of the current stack 
from the RTEMS source tree. If we do not attempt to coordinate these 
pieces work will be repeated, code duplicated and users will be given a 
confusing inconsistent view of networking.


What you have done here is really important and you are breaking new 
ground. We also have a GSoC project under-way for LwIP and Pavel and I 
have been discussing that work. There are a number of strikingly similar 
issues appearing.


We are currently thinking of a repo for LwIP on git.rtems.org, eg 
rtems-lwip.git. It will contain some build system support files, 
license, a readme (I suppose) and a submodule reference to the upstream 
LwIP repo. The submodule would be a specific hash of the upstream 
project. At release time the release process creates a single tarball of 
all source, I do this for libbsd now.


Do you think this would work for civetweb?

What is not clear to me is do we following the LwIP path and a separate 
repo for this package or do we have an 'rtems-net-services.git' repo 
this code is part of? A combined repo would mean the build system used 
is either a mix based on each part or we unify it to a common build 
system. In time we will have other pieces of code added, eg telnetd etc 
as we moved that from the in source tree.


I see Sebastian removed the unreferenced services directory from libbsd 
this week (the vc email was too big for the list) and thank you 
Sebastian. It did make me wonder how we manage these things.


We also need to unify the network configuration for testing. Currently 
libbsd is inconsistent. Some tests use the waf configure command line 
settings and others do not and force DHCP. I am looking to change this 
so we can have a better solution that allows more complex 
configurations. The intention is this can be used for LwIP as well. I 
will post my ideas when I get time.



The next steps would be to remove mghttpd from RTEMS. Currently that
means that I have to remove the test too. Any ideas where we could move
it to? If we don't have a solution: Do we really want to leave the code
untested until someone has the time and budget to implement a external
test suit?


This is a really good question. I do not know and it also relates to how 
we package this code.



Theoretically it should be possible to build and install the libcivetweb
without a RTEMS BSP. When building the BSP, we could detect if the
"civetweb.h" file is there using autoconf and either build the mghttpd01
test or not depending on the result. This would allow it to keep an
RTEMS-specific test for civetweb inside the RTEMS repository.


I do not wish to see this happen. It is specifically these type of 
changes I am concerned with because it forces a dependence beyond 
standards based headers. We need agreed rules here and we need to stick 
to them.


I see we have a structure issue with these types of tests and I think we 
need find a general solution.



The only problem is: Currently there is no way to build civetweb prior
to the BSP. Civetweb uses some of the network headers that are currently
provided by the BSP.


Beyond the standards based headers?


So the process would extend to the following:
- build BSP (without mghttpd01 test)
- build civetweb
- re-build BSP (this time with mghttpd01 test)
- run tests

This could be solved by moving the network headers into newlib like
suggested in the other thread of discussion.


Lets figure out a suitable scalable architecture for network services 
like this then come back and look at the detail. This is just one package.


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

Re: [PATCH 00/13] Replace mongoose with civetweb.

2016-04-28 Thread Christian Mauderer 
Am 29.04.2016 um 02:45 schrieb Chris Johns:
> On 28/04/2016 18:27, Christian Mauderer wrote:
>> Am 27.04.2016 um 02:07 schrieb Chris Johns:
>>> On 26/04/2016 22:22, Christian Mauderer wrote:
 Am 26.04.2016 um 04:51 schrieb Chris Johns:
> On 26/04/2016 07:22, Joel Sherrill wrote:
>>
>> I put some work into building civetweb using RSB. My configuration is
>> now able to build a "libcivetweb.a" using the Makefile of civetweb.
> 
> Excellent. GNU make is available in the RSB on all hosts.
> 
> How do we package this Makefile?

The Makefile is the one provided by the civetweb repository. So we
shouldn't pack it ourselves.

> 
> We have a few things happening we need to land in a coordinated manner.
> We have this work, libbsd, LwIP, and the removal of the current stack
> from the RTEMS source tree. If we do not attempt to coordinate these
> pieces work will be repeated, code duplicated and users will be given a
> confusing inconsistent view of networking.
> 
> What you have done here is really important and you are breaking new
> ground. We also have a GSoC project under-way for LwIP and Pavel and I
> have been discussing that work. There are a number of strikingly similar
> issues appearing.
> 
> We are currently thinking of a repo for LwIP on git.rtems.org, eg
> rtems-lwip.git. It will contain some build system support files,
> license, a readme (I suppose) and a submodule reference to the upstream
> LwIP repo. The submodule would be a specific hash of the upstream
> project. At release time the release process creates a single tarball of
> all source, I do this for libbsd now.
> 
> Do you think this would work for civetweb?

I'm not sure if this would be the right way. This sounds more like
forking civetweb. This seems overkill for only a few patches that
hopefully can go away in the future. If we want to keep a own repository
up to date with the upstream repository this means an ongoing effort.

> 
> What is not clear to me is do we following the LwIP path and a separate
> repo for this package or do we have an 'rtems-net-services.git' repo
> this code is part of? A combined repo would mean the build system used
> is either a mix based on each part or we unify it to a common build
> system. In time we will have other pieces of code added, eg telnetd etc
> as we moved that from the in source tree.
> 
> I see Sebastian removed the unreferenced services directory from libbsd
> this week (the vc email was too big for the list) and thank you
> Sebastian. It did make me wonder how we manage these things.
> 
> We also need to unify the network configuration for testing. Currently
> libbsd is inconsistent. Some tests use the waf configure command line
> settings and others do not and force DHCP. I am looking to change this
> so we can have a better solution that allows more complex
> configurations. The intention is this can be used for LwIP as well. I
> will post my ideas when I get time.
> 
>> The next steps would be to remove mghttpd from RTEMS. Currently that
>> means that I have to remove the test too. Any ideas where we could move
>> it to? If we don't have a solution: Do we really want to leave the code
>> untested until someone has the time and budget to implement a external
>> test suit?
> 
> This is a really good question. I do not know and it also relates to how
> we package this code.

This is a question at hand. So I don't think that we can avoid it if we
want to remove mongoose from RTEMS and replace it with civetweb in RSB
instead of just updating the webserver in the RTEMS repo like I
originally intended.

By the way: Either way civetweb would still need the patches 1 to 4 of
the original patch set. These four patches only add some rudimentary
implementations of POSIX functions that RTEMS currently doesn't have.

> 
>> Theoretically it should be possible to build and install the libcivetweb
>> without a RTEMS BSP. When building the BSP, we could detect if the
>> "civetweb.h" file is there using autoconf and either build the mghttpd01
>> test or not depending on the result. This would allow it to keep an
>> RTEMS-specific test for civetweb inside the RTEMS repository.
> 
> I do not wish to see this happen. It is specifically these type of
> changes I am concerned with because it forces a dependence beyond
> standards based headers. We need agreed rules here and we need to stick
> to them.
> 
> I see we have a structure issue with these types of tests and I think we
> need find a general solution.

I don't see where this would break rules. I wouldn't integrate any
civetweb files or non POSIX headers into newlib.

Adding POSIX headers (and only POSIX headers) to newlib would mean that
we can build civetweb completely independent of the BSP. This allows
that you _can_  build civetweb before the BSP. But if you prefer you can
also build it afterward.

It would only influence how to run the tests: If civetweb should be
tested, you would have to build it before the BSP.

For the average users i