LibBSD PowerPC motorola_shared BSP PCI Support

Fri Oct 30 08:50:55 UTC 2020

Hello, Joel,

You are right, for the MVME6100 the configuration in libbsd is still missing. There is also missing the
old NIC. Chris has already sent me information about it. I'll try to do that next week.
But I have to put two MVME6100s into production by the end of the month. If I can't do that with libbsd, I 
will use the CPUs with RTEMS5 and the legacy stack. This has worked so far with PCI/VME.

The QorIQ based MVME2500 worked with the pre-RTEMS5. Sebastian had made it work with libbsd.
PCI/VMEbus was still missing.

Support is important to me because I also have some very modern boards with the Qoriq CPU in the pipeline.
For example IFC_1420 from IOxOS (https://www.ioxos.ch/wp-content/uploads/2018/02/IFC_1420_SDS_A0.pdf). This
is a CPU for MTCA.4 which is used in modern accelerator systems.

Viele Grüße
Heinz Junkes
--
Experience directly varies with equipment ruined.

> On 30. Oct 2020, at 03:31, Joel Sherrill <joel at rtems.org> wrote:
> 
> 
> 
> On Thu, Oct 29, 2020, 6:07 AM Heinz Junkes <junkes at fhi-berlin.mpg.de> wrote:
> I can now run the test programs of libbsd. But on the MVME6100
> no network interfaces gets found.
> 
> MVME6100> netShut
> /-----------------------------------------
> config addr is 0xf1000cf8
> config data is 0xf1000cfc
> Welcome to RTEMS rtems-6.0.0 (PowerPC/Generic (classic FPU)/beatnik)
> CPU: MPC7457
> Board Type: MVME6100-0163 (S/N E173D27)
> Bus Clock Freq:   133333333 Hz
> CPU Clock Freq:  1266666654 Hz
> Memory:           536870912 bytes
> -----------------------------------------
> Now BSP_mem_size = 0x1fe00000
> Configuration.work_space_size = ed620
> Page table setup finished; will activate it NOW...
> Going to start PCI buses scanning and initialization
> Number of PCI buses found is : 3
> MSR 0x2003032
> Exit from bspstart
> unable to find the universe in pci config space
> Tundra Tsi148 PCI-VME bridge detected at 0x81100000, IRQ 84
> Tsi148 Outbound Ports:
> Port  VME-Addr   Size       PCI-Adrs   Mode:
> 0:    0x20000000 0x0e000000 0x90000000 A32, SUP, D32, SCT
> 1:    0x00000000 0x00ff0000 0x9f000000 A24, SUP, D32, SCT
> 2:    0x00000000 0x00010000 0x9fff0000 A16, SUP, D32, SCT
> 7:    0x00000000 0x01000000 0x9e000000 CSR, SUP, D32, SCT
> Tsi148 Inbound Ports:
> Port  VME-Addr   Size       PCI-Adrs   Mode:
> 0:    0x90000000 0x1fe00000 0x00000000 A32, PGM, DAT, SUP, USR, MBLT, BLT
> vmeTsi148 IRQ manager: looking for registers on VME...
> Trying to find CSR on VME...
> vmeTsi148 - IRQ manager using VME CSR to flush FIFO
> Registering /dev/console as minor 0 (==/dev/ttyS0)
> 
> 
> *** BEGIN OF TEST LIBBSD DHCPCD 1 ***
> *** TEST VERSION: 6.0.0.5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52
> *** TEST STATE: EXPECTED_PASS
> *** TEST BUILD: RTEMS_POSIX_API
> *** TEST TOOLS: 10.2.1 20201026 (RTEMS 6, RSB 5f4fd63a0c2b4b0657b64abdcfa70c47bee21c52, Newlib 17b7dfc)
> 
> RTEMS Shell on /dev/console. Use 'help' to list commands.
> SHLL [/] # xus0: <RTEMS Nexus device>
> [zone: unpcb] kern.ipc.maxsockets limit reached
> info: lo0: link state changed to UP
> info: version 6.2.1 starting
> err: no valid interfaces found
> warning: no interfaces have a carrier
> 
> Afaik the mvme6100 does not have a configuration in libbsd. My recollection (which could be wrong) is that there isn't a libbsd driver in the tree for the NIC.
> 
> There was a table in Chris' EPICS slides about which bsps we thought needed attention with notes on the drivers.
> 
> And the mvme2500 wasn't on the list. I think we may need an alias or some documentation on this BSP. 
> 
> Viele Grüße
> Heinz Junkes
> --
> Experience directly varies with equipment ruined.
> 
> 
> 
> > On 27. Oct 2020, at 18:41, Sebastian Huber <sebastian.huber at embedded-brains.de> wrote:
> > 
> > 
> > On 27/10/2020 15:41, Joel Sherrill wrote:
> >> 
> >> 
> >> On Tue, Oct 27, 2020 at 9:23 AM Heinz Junkes <junkes at fhi-berlin.mpg.de <mailto:junkes at fhi-berlin.mpg.de>> wrote:
> >> 
> >>    I am currently trying git rtems6.
> >> 
> >>    ../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
> >>    powerpc_beatnik.log --no-clean --target=powerpc-rtems6
> >>    --with-rtems-bsp=beatnik 6/rtems-powerpc 6/rtems-kernel
> >> 
> >>    works …
> >> 
> >>    Unfortunately It fails here:
> >> 
> >>    ../source-builder/sb-set-builder --prefix=$HOME/.rtems --log
> >>    libbsd.log --no-clean --target=powerpc-rtems6
> >>    --with-rtems-bsp=beatnik --host=powerpc-rtems6 6/rtems-libbsd
> >> 
> >>    ...
> >>    [1562/1948] Compiling freebsd/sbin/nvmecontrol/ns.c
> >>    In file included from
> >>    /home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/cstdlib:75,
> >>                     from
> >>    /home/ad/.rtems/lib/gcc/powerpc-rtems6/10.2.1/include/c++/stdlib.h:36,
> >>                     from ../../freebsd/sys/sys/libkern.h:216,
> >>                     from ../../freebsd/sys/sys/systm.h:543,
> >>                     from ../../freebsd/sys/sys/mbuf.h:42,
> >>                     from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
> >>    /home/ad/.rtems/powerpc-rtems6/include/stdlib.h:309:6: error:
> >>    conflicting declaration of C function 'void qsort_r(void*, size_t,
> >>    size_t, int (*)(const void*, const void*, void*
> >>    ), void*)'
> >>      309 | void qsort_r (void *__base, size_t __nmemb, size_t __size,
> >>    int (*_compar)(const void *, const void *, void *), void *__thunk);
> >>          |      ^~~~~~~
> >>    In file included from ../../freebsd/sys/sys/systm.h:543,
> >>                     from ../../freebsd/sys/sys/mbuf.h:42,
> >>                     from ../../rtemsbsd/rtems/rtems-bsd-cxx.cc:48:
> >>    ../../freebsd/sys/sys/libkern.h:211:7: note: previous declaration
> >>    'void qsort_r(void*, size_t, size_t, void*, int (*)(void*, const
> >>    void*, const void*))'
> >>      211 | void  qsort_r(void *base, size_t nmemb, size_t size, void
> >>    *thunk,
> >>          |       ^~~~~~~
> >> 
> >>    Waf: Leaving directory
> >>    `/home/ad/RTEMS_DEV/rtems-source-builder/rtems/build/rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1/rtems-libbsd-d964a6703c705cc9
> >>    2fd053bcefc08bb3b6baa0e2/build/powerpc-rtems6-beatnik-default'
> >>    Build failed
> >>     -> task in 'bsd' failed with exit status 1 (run with -v to
> >>    display more information)
> >>    shell cmd failed: /bin/sh -ex
> >>    /home/ad/RTEMS_DEV/rtems-source-builder/rtems/build/rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1/do-build
> >>    error: building
> >>    rtems-libbsd-d964a6703c705cc92fd053bcefc08bb3b6baa0e2-powerpc-rtems6-1
> >> 
> >> 
> >> I'm not sure why this would not have shown up before but the FreeBSD kernel reuses some standard library method names with different signatures. The file rtemsbsd/include/machine/rtems-bsd-kernel-namespace.h renames a lot of items to put them in a BSD namespace. qsort_r isn't in this list but perhaps should be.
> > 
> > I think its is this bug:
> > 
> > https://devel.rtems.org/ticket/4078
> > 
> > I added a workaround to the latest master and 6-freebsd-12 branches.
> > 
> > -- 
> > 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.huber at embedded-brains.de
> > PGP     : Public key available on request.
> > 
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> > 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5300 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/devel/attachments/20201030/19e3249a/attachment-0001.bin>