Re: [rtems-source-builder commit] 5: Update Newlib
On 06/06/2019 02:23, Chris Johns wrote: On 5/6/19 10:16 pm, Sebastian Huber wrote: +tools/rtems-gcc-fb371a33fa6-newlib-5c2a3661c Is there a timetable for gcc 7 branch releases? I see the built gcc executable clearly shows the version of gcc is 7.4.1 which is great so I am wondering if this file name would be clearer if the branch was included, ie `tools/rtems-gcc-7.4-fb371a33fa6-newlib-5c2a3661c`. I am not concerned with newlib as much because there are no branches like we have with gcc. I raise this because I saw `rtems-gcc-fb371a33fa6-newlib-1d35a003f` being built by the RSB and I did not know if this was master, a branch or which branch. Also the package name is the name of the source tarball and so the name used in a release on our ftp servers. We could use the branch number and atimestamp for the files, e.g. rtems-gcc-fb371a33fa6-newlib-5c2a3661c -> rtems-gcc-7-2019-06-05-newlib-2019-06-05 -- 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: [rtems-source-builder commit] 5: Update Newlib
On 5/6/19 10:16 pm, Sebastian Huber wrote: > +tools/rtems-gcc-fb371a33fa6-newlib-5c2a3661c Is there a timetable for gcc 7 branch releases? I see the built gcc executable clearly shows the version of gcc is 7.4.1 which is great so I am wondering if this file name would be clearer if the branch was included, ie `tools/rtems-gcc-7.4-fb371a33fa6-newlib-5c2a3661c`. I am not concerned with newlib as much because there are no branches like we have with gcc. I raise this because I saw `rtems-gcc-fb371a33fa6-newlib-1d35a003f` being built by the RSB and I did not know if this was master, a branch or which branch. Also the package name is the name of the source tarball and so the name used in a release on our ftp servers. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Problem building RTEMS - readline/undefined reference to tputs
On Wed, Jun 5, 2019 at 4:04 PM John Graham wrote: > > Did you install the packages listed here: > > > > https://docs.rtems.org/branches/master/user/hosts/posix.html#xubuntu > > > > sudo apt-get build-dep gcc-defaults g++ gdb git unzip pax bison \ > > flex libpython-dev git libncurses5-dev zlib1g-dev > > It can't find build-dep or gcc-defaults - any idea if this is because > I'm on 19.04 or if the package name isn't quite right? > The package names do sometimes change. I recall updating this area myself based on user feedback. But I don't think that's the issue this time. My understanding is that build-dep is a subcommand for apt-get so "apt-get build-dep PACKAGE" fetches the build dependencies for PACKAGE. https://packages.ubuntu.com/search?suite=default=all=any=gcc-defaults=sourcenames shows gcc-defaults as a source package. Maybe you need to enable the source repositories. I'm primarily a Centos user but periodically try to make sure the Ubuntu instructions are working. --joel > ___ > 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: Problem building RTEMS - readline/undefined reference to tputs
> Did you install the packages listed here: > > https://docs.rtems.org/branches/master/user/hosts/posix.html#xubuntu > > sudo apt-get build-dep gcc-defaults g++ gdb git unzip pax bison \ > flex libpython-dev git libncurses5-dev zlib1g-dev It can't find build-dep or gcc-defaults - any idea if this is because I'm on 19.04 or if the package name isn't quite right? ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/2] sparc: Two problems in lazy floating point switching
Hi, I think there are two problems in lazy floating point switching: 1. Missed restoring of PSR after invoked CMP commands in syscall_lazy_fp_switch procedure. 2. Mistaken clearing of PSR[EF] bit in _ISR_Handler The following is a piece of real code, generated by gcc-9.1.0 from ordinary C++ code containing cycle for(;;) with floating point operations inside ... 4f102d84:b1 a6 09 58 fmuld %f24, %f24, %f24 4f102d88:95 a5 88 5c faddd %f22, %f28, %f10 4f102d8c:92 02 61 08 add %o1, 0x108, %o1 4f102d90:91 a2 08 da fsubd %f8, %f26, %f8 4f102d94:80 a0 80 09 cmp %g2, %o1 < (1) 4f102d98:95 a2 88 58 faddd %f10, %f24, %f10 4f102d9c:91 a2 09 54 fmuld %f8, %f20, %f8 4f102da0:95 a0 05 4a fsqrtd %f10, %f10 4f102da4:d5 3b bf f8 std %f10, [ %sp + -8 ] 4f102da8:01 00 00 00 nop 4f102dac:91 a2 08 4a faddd %f8, %f10, %f8 4f102db0:ad a4 89 c8 fdivd %f18, %f8, %f22 4f102db4:ed 3b bf f8 std %f22, [ %sp + -8 ] 4f102db8:01 00 00 00 nop 4f102dbc:d1 3a 7f e0 std %f8, [ %o1 + -32 ] 4f102dc0:d1 18 40 00 ldd [ %g1 ], %f8 4f102dc4:91 a2 08 ce fsubd %f8, %f14, %f8 4f102dc8:91 a2 09 56 fmuld %f8, %f22, %f8 < (2) 4f102dcc:d1 3a 7f c8 std %f8, [ %o1 + -56 ] < (3) 4f102dd0:d5 18 60 08 ldd [ %g1 + 8 ], %f10 4f102dd4:99 a2 88 cc fsubd %f10, %f12, %f12 4f102dd8:99 a3 09 56 fmuld %f12, %f22, %f12 4f102ddc:d9 3a 7f d0 std %f12, [ %o1 + -48 ] 4f102de0:d1 18 60 10 ldd [ %g1 + 0x10 ], %f8 4f102de4:a1 a2 08 d0 fsubd %f8, %f16, %f16 4f102de8:a1 a4 09 56 fmuld %f16, %f22, %f16 4f102dec:e1 3a 7f d8 std %f16, [ %o1 + -40 ] 4f102df0:12 bf ff d8 bne 4f102d50 < (4) 4f102df4:01 00 00 00 nop ... (1) CMP instruction is invoked and sets icc field properly. (2) Asynchronous interrupt occurs, _ISR_Handler clear PSR[EF] bit (3) First floating point instruction after interrupt causes the lazy fp switch procedure which uses CMP instructions inside and does not restores PSR on return. (4) "dirty" PSR[icc] is checked and our program makes wrong branch, so we get undefined program behavior. The above is applied at least to gcc versions 7.4.0 and 9.1.0. With gcc 4.4.7 this situation does not appear because it generates a bit different code where there are no fp operations between cmp and branch instructions (even more - nearly all cmp are followed by branches immediately). The second problem is - why PSR[EF] bit gets cleared after return from interrupt although interrupted task was a floating point task? The second patch about this - EF bit is leared in delayed slot regardless of branch is done or not. These two patches resolve described problems and I hope they both are correct. Any comments are welcome. Maksim E. Kozlov (2): sparc: Fix missed restoring of PSR in syscall_lazy_fp_switch sparc: Fix mistakenly cleared PSR[EF] bit. cpukit/score/cpu/sparc/cpu_asm.S | 3 ++- cpukit/score/cpu/sparc/syscall.S | 4 2 files changed, 6 insertions(+), 1 deletion(-) -- 2.17.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 3/5] Add rtems i2c adaptation layer
On 01/06/2019 21:20, Vijay Kumar Banerjee wrote:
> ---
> libbsd.py| 1 +
> rtemsbsd/i2c/rtems-i2c.c | 218 +++
> 2 files changed, 219 insertions(+)
> create mode 100644 rtemsbsd/i2c/rtems-i2c.c
I think the file would be better located at
rtemsbsd/sys/dev/iicbus/rtems-i2c.c
The directory structure for drivers should be similar to the one in FreeBSD.
>
> diff --git a/libbsd.py b/libbsd.py
> index a25d3a8a..6e8ff987 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -771,6 +771,7 @@ class iic(builder.Module):
> self.addRTEMSSourceFiles(
> [
> 'local/iicbus_if.c',
> +'i2c/rtems-i2c.c',
> ],
> mm.generator['source']()
> )
> diff --git a/rtemsbsd/i2c/rtems-i2c.c b/rtemsbsd/i2c/rtems-i2c.c
> new file mode 100644
> index ..5189e5fe
> --- /dev/null
> +++ b/rtemsbsd/i2c/rtems-i2c.c
> @@ -0,0 +1,218 @@
> +/*
> + * Copyright (c) 2019 Vijay Kumar Banerjee .
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +#include
> +
> +typedef struct i2c_msg i2c_msg;
> +
> +struct i2c_softc {
> + device_t dev;
> + device_t sc_iicbus;
> + char *path;
> + int fd;
> + int mem_rid;
> + int irq_rid;
mem_rid and irq_rid seem to be unused.
> +};
> +
> +static int
> +rtems_i2c_probe(device_t dev)
> +{
> + if (!ofw_bus_status_okay(dev)) {
> + return (ENXIO);
> + }
> + if (!ofw_bus_is_compatible(dev, "rtems,bsp-i2c")){
> + return (ENXIO);
> + }
> +
> + device_set_desc(dev, "RTEMS libbsd I2C");
> + return (BUS_PROBE_SPECIFIC);
> +}
> +
> +static int
> +rtems_i2c_attach(device_t dev)
> +{
> + phandle_t node;
> + ssize_t compatlen;
> + char *compat;
> + char *curstr;
> + struct i2c_softc *sc;
> + int len;
> +
> + sc = device_get_softc(dev);
> + sc->dev = dev;
> + node = ofw_bus_get_node(sc->dev);
> +
> + len = OF_getprop_alloc(node, "rtems,i2c-path", >path);
> + if (len == -1){
> + device_printf(sc->dev, "Path not found in Device Tree");
> + OF_prop_free(sc->path);
> + return (ENXIO);
> + }
> + else{
You don't really need the else here. If your error case hits, you return
anyway. So you can save one level of indentation for the next block.
> + if ((sc->sc_iicbus = device_add_child(sc->dev, "iicbus", -1))
> == NULL) {
> + device_printf(sc->dev, "could not allocate iicbus
> instance\n");
> + OF_prop_free(sc->path);
> + return (ENXIO);
> + }
> + config_intrhook_oneshot((ich_func_t)bus_generic_attach,
> sc->dev);
> + }
> + return (0);
> +}
> +
> +static int
> +rtems_i2c_detach(device_t dev)
> +{
> + struct i2c_softc *sc;
> + int error;
> +
> + sc = device_get_softc(dev);
> +
> + OF_prop_free(sc->path);
> +
> + if (sc->sc_iicbus && (error = device_delete_child(dev, sc->sc_iicbus))
> != 0)
> + return (error);
> +
> + if ((error = bus_generic_detach(sc->dev)) != 0) {
> + device_printf(sc->dev, "cannot detach child devices\n");
> + return (error);
> + }
Maybe we misunderstood each other there in our chat: The detach should
have roughly a reverse order of the attach. The last action in your
attach is
Re: [PATCH 2/5] iicbus: port to RTEMS
On 01/06/2019 21:20, Vijay Kumar Banerjee wrote:
> ---
> Makefile.todo | 11 ++
> buildset/default.ini | 1 +
> libbsd.py | 35
> rtemsbsd/include/bsp/nexus-devices.h | 4 +
> .../machine/rtems-bsd-kernel-namespace.h | 33
> rtemsbsd/include/rtems/bsd/local/iicbus_if.h | 166 ++
> rtemsbsd/local/iicbus_if.c| 76
> 7 files changed, 326 insertions(+)
> create mode 100644 rtemsbsd/include/rtems/bsd/local/iicbus_if.h
> create mode 100644 rtemsbsd/local/iicbus_if.c
>
> diff --git a/Makefile.todo b/Makefile.todo
> index 9754ddb6..74188531 100644
> --- a/Makefile.todo
> +++ b/Makefile.todo
> @@ -215,6 +215,17 @@ $(LOCAL_SRC)/gpiobus_if.c:
> $(FREEBSD_SRC)/sys/dev/gpio/gpiobus_if.m
> -e 's|#include "gpiobus_if.h"|#include
> |'
> mv gpiobus_if.c $@
>
> +$(LOCAL_INC)/iicbus_if.h: $(FREEBSD_SRC)/sys/dev/iicbus/iicbus_if.m
> + awk -f $(TOOLS)/makeobjops.awk $< -h
> + mv iicbus_if.h $@
> +
> +$(LOCAL_SRC)/iicbus_if.c: $(FREEBSD_SRC)/sys/dev/iicbus/iicbus_if.m
> + awk -f $(TOOLS)/makeobjops.awk $< -c
> + sed -i iicbus_if.c \
> + -e '1 i\#include \n' \
> + -e 's|#include "iicbus_if.h"|#include
> |'
> + mv iicbus_if.c $@
> +
> $(LOCAL_INC)/sdhci_if.h: $(FREEBSD_SRC)/sys/dev/sdhci/sdhci_if.m
> awk -f $(TOOLS)/makeobjops.awk $< -h
> mv sdhci_if.h $@
> diff --git a/buildset/default.ini b/buildset/default.ini
> index f25fe9a3..4acb2368 100644
> --- a/buildset/default.ini
> +++ b/buildset/default.ini
> @@ -36,6 +36,7 @@ dev_usb_serial = on
> dev_usb_storage = on
> dev_usb_wlan = off
> dev_wlan_rtwn = off
> +iic = on
> dhcpcd = on
> dpaa = on
> evdev = on
> diff --git a/libbsd.py b/libbsd.py
> index d99e3ad8..a25d3a8a 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -125,6 +125,7 @@ _defaults = {
> ('freebsd/sys/sys','**/*.h',
> 'sys'),
> ('freebsd/sys/vm', '**/*.h',
> 'vm'),
> ('freebsd/sys/dev/mii','**/*.h',
> 'dev/mii'),
> + ('freebsd/sys/dev/iicbus', '**/*.h',
> 'dev/iicbus'),
> ('linux/include', '**/*.h',
> ''),
> ('mDNSResponder/mDNSCore', 'mDNSDebug.h',
> ''),
> ('mDNSResponder/mDNSCore', 'mDNSEmbeddedAPI.h',
> ''),
> @@ -741,6 +742,39 @@ class evdev(builder.Module):
> mm.generator['source']()
> )
>
> +#
> +# IIC
> +#
> +class iic(builder.Module):
> +
> +def __init__(self, manager):
> +super(iic, self).__init__(manager, type(self).__name__)
> +
> +def generate(self):
> +mm = self.manager
> +self.addKernelSpaceHeaderFiles(
> +[
> +'sys/dev/iicbus/iicbus.h',
> +'sys/dev/iicbus/iic.h',
> +'sys/dev/iicbus/iiconf.h',
> +]
> +)
> +self.addKernelSpaceSourceFiles(
> +[
> +'sys/dev/iicbus/iic.c',
> +'sys/dev/iicbus/iicbus.c',
> +'sys/dev/iicbus/iiconf.c',
> +'sys/dev/iicbus/ofw_iicbus.c',
> +],
> +mm.generator['source']()
> +)
> +self.addRTEMSSourceFiles(
> +[
> +'local/iicbus_if.c',
> +],
> +mm.generator['source']()
> +)
> +
> #
> # USB
> #
> @@ -5096,6 +5130,7 @@ def load(mm):
> mm.addModule(mmc_ti(mm))
> mm.addModule(dev_input(mm))
> mm.addModule(evdev(mm))
> +mm.addModule(iic(mm))
>
> mm.addModule(dev_usb(mm))
> mm.addModule(dev_usb_controller(mm))
> diff --git a/rtemsbsd/include/bsp/nexus-devices.h
> b/rtemsbsd/include/bsp/nexus-devices.h
> index a916c664..97f6d2b2 100644
> --- a/rtemsbsd/include/bsp/nexus-devices.h
> +++ b/rtemsbsd/include/bsp/nexus-devices.h
> @@ -61,6 +61,10 @@ SYSINIT_DRIVER_REFERENCE(sdhci_ti, simplebus);
> SYSINIT_DRIVER_REFERENCE(mmcsd, mmc);
> SYSINIT_DRIVER_REFERENCE(cpsw, cpswss);
> SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
> +SYSINIT_DRIVER_REFERENCE(rtems_i2c, simplebus);
> +SYSINIT_DRIVER_REFERENCE(ofw_iicbus, rtems_i2c);
> +SYSINIT_DRIVER_REFERENCE(iic, iicbus);
> +SYSINIT_DRIVER_REFERENCE(iicbus, rtems_i2c);
> #ifdef RTEMS_BSD_MODULE_NET80211
> SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
> SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
> diff --git a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> index d7967c65..626c2ccc 100644
> --- a/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> +++ b/rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h
> @@ -1304,6 +1304,8 @@
> #define
CTF example
Hi Gedare, This is with reference to meeting we recently conducted on freenode. You had suggested that you have working examples on CTF. Can you please share them all here? If possible, please share anything other related to decoder(source plugin) which would help in converting current trace data generated from Event Recording infrastructure to CTF. It would help me in conversion of current trace data to CTF. Thanks ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS on embedded CPUs(RISCV)
On Wed, 5 Jun 2019 at 15:14, Sebastian Huber wrote: > > On 05/06/2019 15:09, Hesham Almatary wrote: > > On Wed, 5 Jun 2019 at 07:11, Sebastian Huber > > wrote: > >> Hello Sachin, > >> > >> On 05/06/2019 06:15,sachin.gh...@sifive.com wrote: > >>> Hi RTEMS dev team, > >>> > >>> I don’t know if I should send this query to users list or developer list. > >>> > >>> I am working on the getting RTEMS BSP ported on the one of RISC-V > >>> based SoC. > >>> > >>> Current RTEMS has support only for Spike simulator. > >>> > >> we have also support for Qemu. At least at some point in time it worked > >> with a non-upstream Qemu. I am not sure how far the upstreaming of the > >> Qemu support progressed in the last months. > >> > > Upstream QEMU runs RTEMS fine with -virt board. Also, I tested 32-bit RTEMS > > variants on Zynq-based FPGA with Bluespec cores, UART and DTB [1]. > > > > [1]https://github.com/bluespec/Piccolo > > > > This reminds me off your patch set you sent a couple of weeks ago. > Sorry, I forgot it after my holidays. Would you mind sending it again > rebased to the current master? > Sure, I am gonna work on it. The current RTEMS RISC-V port is actually mature enough that I got it working on Spike, QEMU, Rocket Chip, Piccolo, Sail [1] and others. Thanks for your efforts, and I am looking forward to trying libbsd/riscv. [1] https://github.com/rems-project/sail > -- > 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: RTEMS on embedded CPUs(RISCV)
On 05/06/2019 15:09, Hesham Almatary wrote: Upstream QEMU runs RTEMS fine with -virt board. Also, I tested 32-bit RTEMS variants on Zynq-based FPGA with Bluespec cores, UART and DTB [1]. [1]https://github.com/bluespec/Piccolo It would be great if you could mention this on the BSP page somehow: https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html#riscv -- 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: RTEMS on embedded CPUs(RISCV)
On 05/06/2019 15:09, Hesham Almatary wrote: On Wed, 5 Jun 2019 at 07:11, Sebastian Huber wrote: Hello Sachin, On 05/06/2019 06:15,sachin.gh...@sifive.com wrote: Hi RTEMS dev team, I don’t know if I should send this query to users list or developer list. I am working on the getting RTEMS BSP ported on the one of RISC-V based SoC. Current RTEMS has support only for Spike simulator. we have also support for Qemu. At least at some point in time it worked with a non-upstream Qemu. I am not sure how far the upstreaming of the Qemu support progressed in the last months. Upstream QEMU runs RTEMS fine with -virt board. Also, I tested 32-bit RTEMS variants on Zynq-based FPGA with Bluespec cores, UART and DTB [1]. [1]https://github.com/bluespec/Piccolo This reminds me off your patch set you sent a couple of weeks ago. Sorry, I forgot it after my holidays. Would you mind sending it again rebased to the current master? -- 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: RTEMS on embedded CPUs(RISCV)
On Wed, 5 Jun 2019 at 07:11, Sebastian Huber wrote: > > Hello Sachin, > > On 05/06/2019 06:15, sachin.gh...@sifive.com wrote: > > > > Hi RTEMS dev team, > > > > I don’t know if I should send this query to users list or developer list. > > > > I am working on the getting RTEMS BSP ported on the one of RISC-V > > based SoC. > > > > Current RTEMS has support only for Spike simulator. > > > > we have also support for Qemu. At least at some point in time it worked > with a non-upstream Qemu. I am not sure how far the upstreaming of the > Qemu support progressed in the last months. > Upstream QEMU runs RTEMS fine with -virt board. Also, I tested 32-bit RTEMS variants on Zynq-based FPGA with Bluespec cores, UART and DTB [1]. [1] https://github.com/bluespec/Piccolo > > It looks like RTEMS does not fit very well on the systems having less RAM. > > > > We have 64K of RAM on our standard FPGA development kit for our E > > series embedded cores. > > > > 64KiB for code and data is a challenge for RTEMS. You have to tinker > with the configuration and reduce the feature set to get into this range. > > > All of the RTEMS test does not fit within this given RAM and linker > > throws error. > > > > Regarding this I have few questions > > > > 1. Does RTEMS accept support for new core with limited tests passing? > > Or one need full test suit passing to qualify complete test? > > > > What do you mean with "new core"? I think we already support the > practically relevant ISA combinations: > > bsps/riscv/riscv/config/rv32iac.cfg > bsps/riscv/riscv/config/rv32i.cfg > bsps/riscv/riscv/config/rv32imac.cfg > bsps/riscv/riscv/config/rv32imafc.cfg > bsps/riscv/riscv/config/rv32imafdc.cfg > bsps/riscv/riscv/config/rv32imafd.cfg > bsps/riscv/riscv/config/rv32im.cfg > bsps/riscv/riscv/config/rv64imac.cfg > bsps/riscv/riscv/config/rv64imac_medany.cfg > bsps/riscv/riscv/config/rv64imafdc.cfg > bsps/riscv/riscv/config/rv64imafd.cfg > bsps/riscv/riscv/config/rv64imafdc_medany.cfg > bsps/riscv/riscv/config/rv64imafd_medany.cfg > > We have couple of BSP for other architectures (e.g. ARM, PowerPC) that > cannot run all tests. > > > 1. > > 2. I saw some thread regarding tinyRTEMS > > > > https://devel.rtems.org/wiki/Projects/TinyRTEMS > > > > Is there any plan for this to support as separate port for embedded > > cores with limited resources? > > > > I don't think someone is actively working on this. This wiki page is out > of date and needs an update. The next step to get a real size reduction > would be self-contained threads. This way we get rid of all the objects > support and the heap. > > -- > 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: Problem building RTEMS - readline/undefined reference to tputs
On 05/06/2019 15:07, John Graham wrote: I'm on Ubuntu 19.04, assumed that would be fine as I saw Ubuntu marked as supported elsewhere, however in your link I see 18.04 LTS is specifically mentioned so I may try that if I can't get this to work. Did you install the packages listed here: https://docs.rtems.org/branches/master/user/hosts/posix.html#xubuntu sudo apt-get build-dep gcc-defaults g++ gdb git unzip pax bison \ flex libpython-dev git libncurses5-dev zlib1g-dev -- 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: Problem building RTEMS - readline/undefined reference to tputs
I'm on Ubuntu 19.04, assumed that would be fine as I saw Ubuntu marked as
supported elsewhere, however in your link I see 18.04 LTS is specifically
mentioned so I may try that if I can't get this to work.
John
On Wed, 5 Jun 2019, 13:45 Sebastian Huber, <
sebastian.hu...@embedded-brains.de> wrote:
> On 05/06/2019 14:27, John Graham wrote:
> >
> > I'm trying to build RTEMS to see about starting development work, I
> > took the advice to build the tools as per the user manual, and
> > everything goes okay until this page:
> >
> > https://docs.rtems.org/branches/master/user/start/tools.html
> >
> > I've followed the instructions but when I try and actually build the
> > tools (i.e. ../source-builder/sb-set-builder --prefix=${RTEMS_PREFIX?}
> > 5/rtems-sparc) I get a linker error with lots of undefined references
> > to tputs, e.g.:
>
> Which host operating system do you have? Maybe it is on this list:
>
> https://docs.rtems.org/branches/master/user/hosts/index.html#host-computer
>
> --
> 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: RTEMS on embedded CPUs(RISCV)
On Tue, Jun 4, 2019, 11:15 PM wrote: > Hi RTEMS dev team, > > I don’t know if I should send this query to users list or developer list. > > I am working on the getting RTEMS BSP ported on the one of RISC-V based > SoC. > > Current RTEMS has support only for Spike simulator. > > > > It looks like RTEMS does not fit very well on the systems having less RAM. > > We have 64K of RAM on our standard FPGA development kit for our E series > embedded cores. > > All of the RTEMS test does not fit within this given RAM and linker throws > error. > Mark these in a .tcfg in the BSP config directory. As Sebastian notes there are other BSPs that disable many tests. Individual tests do not fit either due to test size issues (say 1MB RAM disk or many object instances) or feature (dynamic loading). It is expected. You should still have enough tests for confidence. > > > Regarding this I have few questions > >1. Does RTEMS accept support for new core with limited tests passing? >Or one need full test suit passing to qualify complete test? > > If you mean BSP rather than multilib variant, the answer is usually yes. If it is passing what will fit. >1. >2. I saw some thread regarding tinyRTEMS > > https://devel.rtems.org/wiki/Projects/TinyRTEMS > > Is there any plan for this to support as separate port for embedded cores > with limited resources? > This Wiki page was mine to capture ideas on how to drop size. All of them and more have been implemented. The issue is that although you can do some things in low memory environments, there are limits. Some features are off the table and you will be limited in the number of instances of objects you can instance. --joel > > > Thanks and Regards, > > /Sachin > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > 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: Problem building RTEMS - readline/undefined reference to tputs
On 05/06/2019 14:27, John Graham wrote:
I'm trying to build RTEMS to see about starting development work, I
took the advice to build the tools as per the user manual, and
everything goes okay until this page:
https://docs.rtems.org/branches/master/user/start/tools.html
I've followed the instructions but when I try and actually build the
tools (i.e. ../source-builder/sb-set-builder --prefix=${RTEMS_PREFIX?}
5/rtems-sparc) I get a linker error with lots of undefined references
to tputs, e.g.:
Which host operating system do you have? Maybe it is on this list:
https://docs.rtems.org/branches/master/user/hosts/index.html#host-computer
--
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: Problem building RTEMS - readline/undefined reference to tputs
On Wed, Jun 5, 2019, 7:27 AM John Graham
wrote:
> Hi there,
>
> I'm trying to build RTEMS to see about starting development work, I took
> the advice to build the tools as per the user manual, and everything goes
> okay until this page:
>
> https://docs.rtems.org/branches/master/user/start/tools.html
>
> I've followed the instructions but when I try and actually build the tools
> (i.e. ../source-builder/sb-set-builder --prefix=${RTEMS_PREFIX?}
> 5/rtems-sparc) I get a linker error with lots of undefined references to
> tputs, e.g.:
>
> ~~~
> gcc -O2 -pipe -I/home/john/src/
> git.rtems.org/rsb/rtems/build/tmp/sb-john/5/rtems-sparc/home/john/src/git.rtems.org/install/include
> -DHAVE_CONFIG_H -DDEFAULT_INLINE=0 -DFAST_UART
> -I../../../gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed s/-rtems.//`
> -I. -I../../../gdb-8.2.1/sim/sis -I../common
> -I../../../gdb-8.2.1/sim/sis/../common -I../../include
> -I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
> -I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
> -I../../../gdb-8.2.1/sim/sis/../../opcodes -g -O2 -static-libstdc++
> -static-libgcc -L/home/john/src/
> git.rtems.org/rsb/rtems/build/tmp/sb-john/5/rtems-sparc/home/john/src/git.rtems.org/install/lib
> -o run \
> run.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a
> ../../libiberty/libiberty.a -ldl -lnsl -L../../zlib -lz
> ../../readline/libreadline.a -lm
> /usr/bin/ld: ../../readline/libreadline.a(display.o): in function
> `_rl_move_cursor_relative':
> /home/john/src/
> git.rtems.org/rsb/rtems/build/sparc-rtems5-gdb-8.2.1-x86_64-linux-gnu-1/build/readline/../../gdb-8.2.1/readline/display.c:1985:
> undefined reference to `tputs'
> ~~~
>
> I'm not sure how to go about solving this in the context of the RTEMS
> build system. This thread (
> https://github.com/monero-project/monero/issues/2919) seems to suggest I
> just need to link in termcap wherever readline is, though I can't find
> where that's done.
>
That symbol comes from the ncurses package. So you will need to build it
also.
I think there are RSB recipes for both these. Or at least I remember
working on them. Hopefully I finished successfully.
> I'm coming back to this sort of development after a long break, so may
> have missed something obvious! I'm using a fresh Ubuntu 19.04 system,
> nothing installed except emacs and what the RTEMS user guide says.
>
> Thanks for any help,
>
> John
> ___
> 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
Problem building RTEMS - readline/undefined reference to tputs
Hi there,
I'm trying to build RTEMS to see about starting development work, I took
the advice to build the tools as per the user manual, and everything goes
okay until this page:
https://docs.rtems.org/branches/master/user/start/tools.html
I've followed the instructions but when I try and actually build the tools
(i.e. ../source-builder/sb-set-builder --prefix=${RTEMS_PREFIX?}
5/rtems-sparc) I get a linker error with lots of undefined references to
tputs, e.g.:
~~~
gcc -O2 -pipe -I/home/john/src/
git.rtems.org/rsb/rtems/build/tmp/sb-john/5/rtems-sparc/home/john/src/git.rtems.org/install/include
-DHAVE_CONFIG_H -DDEFAULT_INLINE=0 -DFAST_UART
-I../../../gdb-8.2.1/sim/sis/../.. `echo -Dsparc-rtems5 | sed s/-rtems.//`
-I. -I../../../gdb-8.2.1/sim/sis -I../common
-I../../../gdb-8.2.1/sim/sis/../common -I../../include
-I../../../gdb-8.2.1/sim/sis/../../include -I../../bfd
-I../../../gdb-8.2.1/sim/sis/../../bfd -I../../opcodes
-I../../../gdb-8.2.1/sim/sis/../../opcodes -g -O2 -static-libstdc++
-static-libgcc -L/home/john/src/
git.rtems.org/rsb/rtems/build/tmp/sb-john/5/rtems-sparc/home/john/src/git.rtems.org/install/lib
-o run \
run.o libsim.a ../../bfd/libbfd.a ../../opcodes/libopcodes.a
../../libiberty/libiberty.a -ldl -lnsl -L../../zlib -lz
../../readline/libreadline.a -lm
/usr/bin/ld: ../../readline/libreadline.a(display.o): in function
`_rl_move_cursor_relative':
/home/john/src/
git.rtems.org/rsb/rtems/build/sparc-rtems5-gdb-8.2.1-x86_64-linux-gnu-1/build/readline/../../gdb-8.2.1/readline/display.c:1985:
undefined reference to `tputs'
~~~
I'm not sure how to go about solving this in the context of the RTEMS build
system. This thread (https://github.com/monero-project/monero/issues/2919)
seems to suggest I just need to link in termcap wherever readline is,
though I can't find where that's done.
I'm coming back to this sort of development after a long break, so may have
missed something obvious! I'm using a fresh Ubuntu 19.04 system, nothing
installed except emacs and what the RTEMS user guide says.
Thanks for any help,
John
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS on embedded CPUs(RISCV)
On 05/06/2019 12:20, Sachin Ghadi wrote: Thanks Sebastian, On Wed, Jun 5, 2019 at 10:41 AM Sebastian Huber wrote: Hello Sachin, On 05/06/2019 06:15, sachin.gh...@sifive.com wrote: Hi RTEMS dev team, I don’t know if I should send this query to users list or developer list. I am working on the getting RTEMS BSP ported on the one of RISC-V based SoC. Current RTEMS has support only for Spike simulator. we have also support for Qemu. At least at some point in time it worked with a non-upstream Qemu. I am not sure how far the upstreaming of the Qemu support progressed in the last months. It looks like RTEMS does not fit very well on the systems having less RAM. We have 64K of RAM on our standard FPGA development kit for our E series embedded cores. 64KiB for code and data is a challenge for RTEMS. You have to tinker with the configuration and reduce the feature set to get into this range. Yes 64K is challenge,for both data and code. I can use external xip flash for code and but I need to change linker script and start up code to load data section from flash to RAM. I see RTEMs uses some initialized global variables. We have to adjust bsps/riscv/riscv/start/linkcmds.in so that a ROM can be optionally used for text and read-only data. All of the RTEMS test does not fit within this given RAM and linker throws error. Regarding this I have few questions 1. Does RTEMS accept support for new core with limited tests passing? Or one need full test suit passing to qualify complete test? What do you mean with "new core"? I think we already support the practically relevant ISA combinations: I guess 'core' is wrong word I used..I mean new BSP for our RISCV based hardware development kit(Arty100). Core is rv32imac. The current BSP uses a device tree for initialization. Do you want to use this also for this tiny system? If not, then we have to find a way to initialize everything with a static configuration. -- 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: RTEMS on embedded CPUs(RISCV)
Thanks Sebastian, On Wed, Jun 5, 2019 at 10:41 AM Sebastian Huber wrote: > > Hello Sachin, > > On 05/06/2019 06:15, sachin.gh...@sifive.com wrote: > > > > Hi RTEMS dev team, > > > > I don’t know if I should send this query to users list or developer list. > > > > I am working on the getting RTEMS BSP ported on the one of RISC-V > > based SoC. > > > > Current RTEMS has support only for Spike simulator. > > > > we have also support for Qemu. At least at some point in time it worked > with a non-upstream Qemu. I am not sure how far the upstreaming of the > Qemu support progressed in the last months. > > > It looks like RTEMS does not fit very well on the systems having less RAM. > > > > We have 64K of RAM on our standard FPGA development kit for our E > > series embedded cores. > > > > 64KiB for code and data is a challenge for RTEMS. You have to tinker > with the configuration and reduce the feature set to get into this range. > Yes 64K is challenge,for both data and code. I can use external xip flash for code and but I need to change linker script and start up code to load data section from flash to RAM. I see RTEMs uses some initialized global variables. > > All of the RTEMS test does not fit within this given RAM and linker > > throws error. > > > > Regarding this I have few questions > > > > 1. Does RTEMS accept support for new core with limited tests passing? > > Or one need full test suit passing to qualify complete test? > > > > What do you mean with "new core"? I think we already support the > practically relevant ISA combinations: I guess 'core' is wrong word I used..I mean new BSP for our RISCV based hardware development kit(Arty100). Core is rv32imac. > > bsps/riscv/riscv/config/rv32iac.cfg > bsps/riscv/riscv/config/rv32i.cfg > bsps/riscv/riscv/config/rv32imac.cfg > bsps/riscv/riscv/config/rv32imafc.cfg > bsps/riscv/riscv/config/rv32imafdc.cfg > bsps/riscv/riscv/config/rv32imafd.cfg > bsps/riscv/riscv/config/rv32im.cfg > bsps/riscv/riscv/config/rv64imac.cfg > bsps/riscv/riscv/config/rv64imac_medany.cfg > bsps/riscv/riscv/config/rv64imafdc.cfg > bsps/riscv/riscv/config/rv64imafd.cfg > bsps/riscv/riscv/config/rv64imafdc_medany.cfg > bsps/riscv/riscv/config/rv64imafd_medany.cfg > > We have couple of BSP for other architectures (e.g. ARM, PowerPC) that > cannot run all tests. > Ok understand , so I can submit RTEMS patches even if it doesn't pass all the tests. > > 1. > > 2. I saw some thread regarding tinyRTEMS > > > > https://devel.rtems.org/wiki/Projects/TinyRTEMS > > > > Is there any plan for this to support as separate port for embedded > > cores with limited resources? > > > > I don't think someone is actively working on this. This wiki page is out > of date and needs an update. The next step to get a real size reduction > would be self-contained threads. This way we get rid of all the objects > support and the heap. > > -- > 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. > -- Thanks and Regards, Sachin Ghadi ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Port ndbm
When I checked further, libc/posix/Makefile.am INCLUDES is the old name for AM_CPPFLAGS, hence I added the new path in it. . INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS) -I$(top_srcdir)/search . . ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] Port ndbm
---
newlib/libc/include/ndbm.h| 82 +
newlib/libc/posix/Makefile.am | 4 +-
newlib/libc/posix/ndbm.c | 214 ++
3 files changed, 298 insertions(+), 2 deletions(-)
create mode 100644 newlib/libc/include/ndbm.h
create mode 100644 newlib/libc/posix/ndbm.c
diff --git a/newlib/libc/include/ndbm.h b/newlib/libc/include/ndbm.h
new file mode 100644
index 0..fe9668c3a
--- /dev/null
+++ b/newlib/libc/include/ndbm.h
@@ -0,0 +1,82 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1990, 1993
+ * The Regents of the University of California. All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Margo Seltzer.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of the University nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * @(#)ndbm.h 8.1 (Berkeley) 6/2/93
+ * $FreeBSD$
+ */
+
+#ifndef _NDBM_H_
+#define_NDBM_H_
+
+#include
+
+/* Map dbm interface onto db(3). */
+#define DBM_RDONLY O_RDONLY
+
+/* Flags to dbm_store(). */
+#define DBM_INSERT 0
+#define DBM_REPLACE 1
+
+/*
+ * The db(3) support for ndbm always appends this suffix to the
+ * file name to avoid overwriting the user's original database.
+ */
+#defineDBM_SUFFIX ".db"
+
+typedef struct {
+ void *dptr;
+ int dsize; /* XXX Should be size_t according to 1003.1-2008. */
+} datum;
+
+typedef DB DBM;
+#definedbm_pagfno(a) DBM_PAGFNO_NOT_AVAILABLE
+
+__BEGIN_DECLS
+int dbm_clearerr(DBM *);
+voiddbm_close(DBM *);
+int dbm_delete(DBM *, datum);
+int dbm_error(DBM *);
+datum dbm_fetch(DBM *, datum);
+datum dbm_firstkey(DBM *);
+#if __BSD_VISIBLE
+longdbm_forder(DBM *, datum);
+#endif
+datum dbm_nextkey(DBM *);
+DBM*dbm_open(const char *, int, mode_t);
+int dbm_store(DBM *, datum, datum, int);
+#if __BSD_VISIBLE
+int dbm_dirfno(DBM *);
+#endif
+__END_DECLS
+
+#endif /* !_NDBM_H_ */
diff --git a/newlib/libc/posix/Makefile.am b/newlib/libc/posix/Makefile.am
index 6cdee1df0..be1b38f28 100644
--- a/newlib/libc/posix/Makefile.am
+++ b/newlib/libc/posix/Makefile.am
@@ -2,7 +2,7 @@
AUTOMAKE_OPTIONS = cygnus
-INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
+INCLUDES = $(NEWLIB_CFLAGS) $(CROSS_CFLAGS) $(TARGET_CFLAGS)
-I$(top_srcdir)/search
GENERAL_SOURCES = \
closedir.c collate.c collcmp.c creat.c dirfd.c \
@@ -10,7 +10,7 @@ GENERAL_SOURCES = \
opendir.c readdir.c readdir_r.c \
regcomp.c regerror.c regexec.c regfree.c \
rewinddir.c sleep.c usleep.c \
- telldir.c
+ telldir.c ndbm.c
ELIX_2_SOURCES = \
scandir.c seekdir.c
diff --git a/newlib/libc/posix/ndbm.c b/newlib/libc/posix/ndbm.c
new file mode 100644
index 0..ced00d04d
--- /dev/null
+++ b/newlib/libc/posix/ndbm.c
@@ -0,0 +1,214 @@
+/*-
+ * SPDX-License-Identifier: BSD-3-Clause
+ *
+ * Copyright (c) 1990, 1993
+ * The Regents of the University of California. All rights reserved.
+ *
+ * This code is derived from software contributed to Berkeley by
+ * Margo Seltzer.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *
