Pavel Pisa created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5563
## Summary When SJA1000 support has been tested on x86 it has been done out-of-mainline tree against RTEMS build i386/pc686. The header file defining `inb` and `outb` is installed in ``` /opt/rtems/7/i386-rtems7/pc686/lib/include/i386_io.h ``` and code builds OK. I have proposed to Michal to include change in his mainline patch but he has tested it only with AMD/Xilinx Zynq. Problem is that rtems/cpukit is build in separation from BSPs and that is why located in BSPs section `rtems/bsps/i386/include/i386_io.h` is not seen by build ``` /opt/rtems/7/bin/i386-rtems7-gcc -MMD', '-std=gnu23 -D_BSD_SOURCE \ -Wall -Wextra -Werror -Wmissing-prototypes -Wimplicit-function-declaration \ -Wstrict-prototypes -Wnested-externs -Wold-style-declaration \ -mtune=pentiumpro -march=pentium -ffunction-sections -fdata-sections \ -O2 -g -Icpukit/include \ -I../../../../../git/rtems/cpukit/include \ -Icpukit/score/cpu/i386/include \ -I../../../../../git/rtems/cpukit/score/cpu/i386/include \ -Icpukit/contrib/include \ -I../../../../../git/rtems/cpukit/contrib/include \ -Icontrib/cpukit/include \ -I../../../../../git/rtems/contrib/cpukit/include \ -Icontrib/cpukit/fastlz \ -I../../../../../git/rtems/contrib/cpukit/fastlz \ -Icontrib/cpukit/utf8proc \ -I../../../../../git/rtems/contrib/cpukit/utf8proc \ -Icontrib/cpukit/uuid \ -I../../../../../git/rtems/contrib/cpukit/uuid \ -Icontrib/cpukit/zlib \ -I../../../../../git/rtems/contrib/cpukit/zlib \ -Icontrib/cpukit/xz-embedded/userspace \ -I../../../../../git/rtems/contrib/cpukit/xz-embedded/userspace \ ../../../../../git/rtems/cpukit/dev/can/sja1000/sja1000.c \ -c -o..../cpukit/dev/can/sja1000/sja1000.c.60.o \ -DHAVE_CONFIG_H=1 ``` The fast fix is to disable option to support I/O mapped SJA1000 chips ``` #if defined(__i386__) #define RTEMS_CAN_SJA1000_ARCH_WITH_IO_PORTS 1 #include "i386_io.h" #endif ``` The proper correction is more problematic because I have not found some portable I/O access primitives in general for memory mapped peripheral accesses with proper barriers on the architectures which require that and for IO mapped devices. Linux kernel provides methods for IO mapped (`inb` and `outb`) and MEM mapped devices accesses (`readb` and `writeb`). But there are even iowrite8 and ioread8 which allows to receive not only memory addresses but even I/O cookie on architectures that require that for PCI/PCIe I/O space access. Which these guaranteed functions over all architectures it is easy to write drivers which work on PCI with every architecture https://docs.kernel.org/driver-api/device-io.html ## Steps to reproduce ``` $RTEMS_DIR/waf bspdefaults --rtems-bsps=i386/pc686 -t "$RTEMS_DIR" -o "$MY_DIR" --prefix "/opt/rtems/7" >config.ini || exit 1 $RTEMS_DIR/waf configure -t "$RTEMS_DIR" -o "$MY_DIR" --rtems-config "$MY_DIR/config.ini" --prefix "/opt/rtems/7" || exit 1 $RTEMS_DIR/waf -v || exit 1 ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5563 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
