[PATCH v1 0/2] [libbsd] Install correct machine include headers

Christian Mauderer oss at c-mauderer.de
Tue Jun 1 18:20:58 UTC 2021


On 01/06/2021 19:24, Gedare Bloom wrote:
> On Mon, May 10, 2021 at 11:26 AM Jan Sommer <jan.sommer at dlr.de> wrote:
>>
>> Hello,
>>
>> This is a follow-up on this discussion regarding the installed header files
>> in libbsd: https://lists.rtems.org/pipermail/devel/2021-April/066211.html
>>
>> The current situation is, that for example for all machines the bus.h is installed from
>> within the rtemsbsd directory (https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/machine/bus.h).
>>
>> According to the file docu it originates from the amd64 version of this file.
>> It also has the following section in it which we ran into when compiling Chris' ptpd2 archive:
>>
>> #ifdef __i386__
>>    #error "your include paths are wrong"
>> #endif
>>
>> This patchset does the following:
>> - Add the target dependent machine include directory to 'header-paths' in libbsd.py
>> - Import (mostly) '_bus.h', 'bus.h' and 'cpufunc.h' for the targets from freebsd-org
>> - Remove those header files from rtemsbsd directory
>>
>> As a result the matching versions for machine dependent header files are now installed
>> for each BSP.
>> Would this be an acceptable solution?
>>
>> So far I compiled some BSPs for i386, arm, aarch64, powerpc, riscv, sparc and sparc64 to check that they still compile after the changes.
>> Are there any other architectures which should be included?

I think the best starting point to find out the minimum supported 
platforms is the nexus-devices.h. At least the officially supported BSPs 
should have an entry there. That is:

#if defined(LIBBSP_ARM_REALVIEW_PBX_A9_BSP_H)
#elif defined(LIBBSP_ARM_BEAGLE_BSP_H)
#elif defined(LIBBSP_ARM_LPC32XX_BSP_H)
#elif defined(LIBBSP_M68K_GENMCF548X_BSP_H)
#elif defined(LIBBSP_ARM_XILINX_ZYNQ_BSP_H)
#elif defined(LIBBSP_AARCH64_XILINX_ZYNQMP_BSP_H)
#elif defined(LIBBSP_ARM_ATSAM_BSP_H)
#elif defined(LIBBSP_ARM_ALTERA_CYCLONE_V_BSP_H)
#elif defined(LIBBSP_ARM_IMX_BSP_H)
#elif defined(LIBBSP_ARM_IMXRT_BSP_H)
#elif defined(LIBBSP_ARM_LPC24XX_BSP_H)
#elif defined(LIBBSP_ARM_STM32H7_BSP_H)
#elif defined(LIBBSP_I386_PC386_BSP_H)
#elif defined(LIBBSP_POWERPC_QORIQ_BSP_H)
#elif defined(LIBBSP_POWERPC_TQM8XX_BSP_H)
#elif defined(LIBBSP_POWERPC_MOTOROLA_POWERPC_BSP_H)

So I think you should have a look at m68k too.

Did you try to run it on any of the platforms?

>>
>> I ran into one problem regarding the compilation of rtemsbsd/sys/dev/dw_mmc/dw_mmc.c:105
>>
>>> return (bus_space_read_4(0, sc->bushandle, off));
>>
>> The first parameter creates an error for riscv (I think because dereferencing a NULL pointer).
>> Are there any suggestion how to solve it (I am not familiar with the bus space and there is a lot of macro magic going on)?
>>
> It looks like this will be a problem for any architecture. so should
> the function that calls bus_space_write_4(0 ...)
>   The macro trail goes...
> 
> #define        __bs_rs(sz, t, h, o)                                            \
>         (*(t)->__bs_opname(r,sz))((t)->bs_cookie, h, o)
> 
> #define        bus_space_read_4(t, h, o)       __bs_rs(4,(t),(h),(o))
> 
> so t is dereferenced. It appears to be an error in the API usage by
> the dw_mmc.c code to not specify a valid bus space.

dw_mmc is only relevant for very few platforms. So in theory it could be 
limited to these. But most likely that won't really solve the problem.

The right answer is that dw_mmc doesn't use the API like intended (like 
Gedare said). That could be a problem for more drivers that use stuff 
from bus.h in rtemsbsd. They never had to use that API correctly. Even 
worse: Some of the __rtems__ hacks in freebsd could have that problem too.

I think for this patch set we either need to have a thorough look at 
these locations or run (not only build) it on a number of platforms, 
especially the ones with special drivers in rtemsbsd or with heavily 
adapted drivers.

> 
>> Also, I am not sure if I always added the header files in the right
>> module in libbsd.py. Any suggestions where to put them instead would be welcome.
>>
>> Best regards,
>>
>>      Jan
>>
>> Jan Sommer (2):
>>    rtemsbd: Remove machine dependent files and use the ones from freebsd
>>    machine: Add machine dependent header files to libbsd.py
>>
>>   freebsd/sys/arm/include/machine/_bus.h        |  47 +
>>   freebsd/sys/arm/include/machine/bus.h         | 769 ++++++++++++++++
>>   freebsd/sys/arm64/include/machine/_bus.h      |  46 +
>>   freebsd/sys/arm64/include/machine/bus.h       | 469 ++++++++++
>>   freebsd/sys/powerpc/include/machine/_bus.h    |  50 +
>>   freebsd/sys/powerpc/include/machine/bus.h     | 467 ++++++++++
>>   freebsd/sys/riscv/include/machine/_bus.h      |  46 +
>>   freebsd/sys/riscv/include/machine/bus.h       | 469 ++++++++++
>>   freebsd/sys/riscv/include/machine/cpufunc.h   | 135 +++
>>   freebsd/sys/riscv/include/machine/riscvreg.h  | 246 +++++
>>   .../sys/sparc}/include/machine/_bus.h         |   0
>>   .../sys/sparc}/include/machine/bus.h          |   0
>>   freebsd/sys/sparc/include/machine/cpufunc.h   |   0
>>   freebsd/sys/sparc64/include/machine/_bus.h    |  41 +
>>   freebsd/sys/sparc64/include/machine/bus.h     | 852 ++++++++++++++++++
>>   libbsd.py                                     |  26 +-
>>   rtemsbsd/include/machine/cpufunc.h            |   1 -
>>   waf_libbsd.py                                 |   2 -
>>   18 files changed, 3660 insertions(+), 6 deletions(-)
>>   create mode 100644 freebsd/sys/arm/include/machine/_bus.h
>>   create mode 100644 freebsd/sys/arm/include/machine/bus.h
>>   create mode 100644 freebsd/sys/arm64/include/machine/_bus.h
>>   create mode 100644 freebsd/sys/arm64/include/machine/bus.h
>>   create mode 100644 freebsd/sys/powerpc/include/machine/_bus.h
>>   create mode 100644 freebsd/sys/powerpc/include/machine/bus.h
>>   create mode 100644 freebsd/sys/riscv/include/machine/_bus.h
>>   create mode 100644 freebsd/sys/riscv/include/machine/bus.h
>>   create mode 100644 freebsd/sys/riscv/include/machine/cpufunc.h
>>   create mode 100644 freebsd/sys/riscv/include/machine/riscvreg.h
>>   rename {rtemsbsd => freebsd/sys/sparc}/include/machine/_bus.h (100%)
>>   rename {rtemsbsd => freebsd/sys/sparc}/include/machine/bus.h (100%)
>>   create mode 100644 freebsd/sys/sparc/include/machine/cpufunc.h
>>   create mode 100644 freebsd/sys/sparc64/include/machine/_bus.h
>>   create mode 100644 freebsd/sys/sparc64/include/machine/bus.h
>>   delete mode 100644 rtemsbsd/include/machine/cpufunc.h
>>
>> --
>> 2.17.1
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 


More information about the devel mailing list