RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers
Thanks, Chris & Christian. I think I got a better understanding of the issues now and found a simpler solution which is less intrusive. I will post a new patchset. Best regards, Jan > -Original Message- > From: Chris Johns > Sent: Tuesday, June 1, 2021 11:28 PM > To: Christian Mauderer ; Gedare Bloom > ; Sommer, Jan > Cc: devel@rtems.org > Subject: Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers > > On 2/6/21 4:20 am, Christian Mauderer wrote: > > On 01/06/2021 19:24, Gedare Bloom wrote: > >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer > 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 proble
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On 2/6/21 4:20 am, Christian Mauderer wrote: > On 01/06/2021 19:24, Gedare Bloom wrote: >> On Mon, May 10, 2021 at 11:26 AM Jan Sommer 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. The only arch that supports a tag we current have is the x86 and that is for IO vs mem space. I posted some patches earlier this year I need to revisit for the powerpc (mvme2700). If possible we prefer no tags and a single flat address space that is cache coherent. In the x86 tags cannot be avoided and supported drivers handle the tags correctly. Be-careful reviewing FreeBSD's bus space implementations. For example the PowerPC support uses tables of calls and we do not need that overhead. The issue here is using this driver on the x86 platform. Until that happens I am fine with the tag being 0. The API requires something even if it is not used. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On 01/06/2021 19:24, Gedare Bloom wrote: On Mon, May 10, 2021 at 11:26 AM Jan Sommer 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) #definebus_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 ++
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
On Mon, May 10, 2021 at 11:26 AM Jan Sommer 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 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)
#definebus_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.
> 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH v1 0/2] [libbsd] Install correct machine include headers
Ping :) > -Original Message- > From: Gedare Bloom > Sent: Monday, May 10, 2021 10:55 PM > To: Sommer, Jan > Cc: devel@rtems.org > Subject: Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers > > I can't review these currently, just want to put a note out there. > Hopefully someone else gets to it. Otherwise ping it in a week or two and I > might have more time to look myself.. > > On Mon, May 10, 2021 at 11:26 AM Jan Sommer > 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 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)? > > > > 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 > >
Re: [PATCH v1 0/2] [libbsd] Install correct machine include headers
I can't review these currently, just want to put a note out there.
Hopefully someone else gets to it. Otherwise ping it in a week or two
and I might have more time to look myself..
On Mon, May 10, 2021 at 11:26 AM Jan Sommer 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 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)?
>
> 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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH v1 0/2] [libbsd] Install correct machine include headers
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 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)?
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@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
