Old network stack and aarch64
chrisj at rtems.org
Tue Oct 6 23:15:49 UTC 2020
On 7/10/20 12:26 am, Joel Sherrill wrote:
> On Tue, Oct 6, 2020 at 2:30 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> building the old network stack for aarch64 fails with:
> cpukit/librpc/src/xdr/xdr_float.c:121:2: error: #error "xdr_float.c:
> unknown CPU"
> 121 | #error "xdr_float.c: unknown CPU"
> Should we enable RTEMS_NETWORKING more selectively similar to RTEMS_SMP
> and RTEMS_MULTIPROCESSING?
> Yes for sure. In the autoconf system, we just excluded a few CPUs.
> But should we go farther in waf? I see two possibilities:
> + Force legacy stack off for the same CPUs as autoconf build plus
> all the BSPs that have new stack support.
> + Only enable it for the specific BSPs that have HAS_NETWORKING
> in their Makefile.am? A quick grep shows 37 of 84 families would be
> white listed this way.
+ The --enable-networking and waf equivalent should indicate the option is
> The first is very easy. The second is a bit more painful but puts us on
> a path of identifying specifically what has to transition.
> With a bit of discussion on the rules for being white listed to use the
> legacy stack, I would lean to the second solution.
What about users with private drivers in their code base? I know of zynq users
with such drivers.
More information about the devel