Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/9/2022 16:29, Chris Johns wrote: On 9/9/2022 11:16 pm, Kinsey Moore wrote: On 9/9/2022 01:46, Chris Johns wrote: On 9/9/2022 2:52 am, Kinsey Moore wrote: At some point, the lwIP build needs to get better about managing which BSPs it supports, but that's not a task for you here and now. I think this is needed. Can lwip be built generically for a BSP that is not specific covered in a list? lwIP is not currently buildable for BSPs that have not been explicitly added to the build. The first step would be a mostly-unified lwipopts that provides defaults that are overridable by BSP-specific or possibly user-provided configuration. The only reason I see to allow this is if we want to let users bring their own lwIP drivers without incorporating them into the rtems-lwip integration repository. I ask because lwip has been added to the RSB 6/rtems-packages and I could not build the erc32 BSP stack because lwip had an error. I am fine with lwip being in ?/rtems-packages if it can be built for every bsp at some generic level. I'll look into better management of BSP-specific configuration and making a generic build available for BSPs that don't have a particular configuration available. Looking at this some more I am not sure it is needed unless lwip wants it. We cannot have the networking stacks in the generic package list or we end up with more than one built and installed at once and we do not support that. In that case, I'll stick with the BSP management improvements once v4 of this patch set goes in (probably) and skip the generic build. Is a generic build something that would be worth pursuing for lwIP? It would come with the core stacks, but no drivers whatsoever. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/9/2022 11:16 pm, Kinsey Moore wrote: > On 9/9/2022 01:46, Chris Johns wrote: >> On 9/9/2022 2:52 am, Kinsey Moore wrote: >>> At some point, the lwIP build needs to get better about managing which BSPs >>> it >>> supports, but that's not a task for you here and now. >> I think this is needed. Can lwip be built generically for a BSP that is not >> specific covered in a list? > lwIP is not currently buildable for BSPs that have not been explicitly added > to > the build. The first step would be a mostly-unified lwipopts that provides > defaults that are overridable by BSP-specific or possibly user-provided > configuration. The only reason I see to allow this is if we want to let users > bring their own lwIP drivers without incorporating them into the rtems-lwip > integration repository. >> I ask because lwip has been added to the RSB 6/rtems-packages and I could not >> build the erc32 BSP stack because lwip had an error. >> >> I am fine with lwip being in ?/rtems-packages if it can be built for every >> bsp >> at some generic level. > > I'll look into better management of BSP-specific configuration and making a > generic build available for BSPs that don't have a particular configuration > available. Looking at this some more I am not sure it is needed unless lwip wants it. We cannot have the networking stacks in the generic package list or we end up with more than one built and installed at once and we do not support that. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/9/2022 01:46, Chris Johns wrote: On 9/9/2022 2:52 am, Kinsey Moore wrote: At some point, the lwIP build needs to get better about managing which BSPs it supports, but that's not a task for you here and now. I think this is needed. Can lwip be built generically for a BSP that is not specific covered in a list? lwIP is not currently buildable for BSPs that have not been explicitly added to the build. The first step would be a mostly-unified lwipopts that provides defaults that are overridable by BSP-specific or possibly user-provided configuration. The only reason I see to allow this is if we want to let users bring their own lwIP drivers without incorporating them into the rtems-lwip integration repository. I ask because lwip has been added to the RSB 6/rtems-packages and I could not build the erc32 BSP stack because lwip had an error. I am fine with lwip being in ?/rtems-packages if it can be built for every bsp at some generic level. I'll look into better management of BSP-specific configuration and making a generic build available for BSPs that don't have a particular configuration available. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/9/2022 2:52 am, Kinsey Moore wrote: > At some point, the lwIP build needs to get better about managing which BSPs it > supports, but that's not a task for you here and now. I think this is needed. Can lwip be built generically for a BSP that is not specific covered in a list? I ask because lwip has been added to the RSB 6/rtems-packages and I could not build the erc32 BSP stack because lwip had an error. I am fine with lwip being in ?/rtems-packages if it can be built for every bsp at some generic level. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
I realized that I am not using the latest rtems, so I did not see those BSPs.
Should I create another patch to add the correct BSPs?
Thanks,
Duc
From: devel on behalf of Kinsey Moore
Sent: Thursday, September 8, 2022 12:52:15 PM
To: devel@rtems.org
Subject: Re: [PATCH rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/8/2022 11:34, Duc Doan wrote:
> ---
> lwip.py | 31 ++-
> 1 file changed, 18 insertions(+), 13 deletions(-)
>
> diff --git a/lwip.py b/lwip.py
> index 84eef2c..1f0b8e2 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -99,6 +99,8 @@ def build(bld):
> drv_incl = []
> arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
> bld.env.RTEMS_ARCH_BSP)
...
> is_qemu = False
> -if bld.env.RTEMS_ARCH_BSP.startswith('aarch64-rtems6-xilinx_zynqmp'):
> +if arch == 'aarch64' and bsp in ['xilinx_zynqmp_ultra96']:
> is_xilinx_bsp = True
> is_aarch64_bsp = True
> -if bld.env.RTEMS_ARCH_BSP.endswith('_qemu'):
> +if bsp in ['xilinx_zynq_a9_qemu']:
> is_qemu = True
> if is_xilinx_bsp:
> drv_incl.extend(xilinx_drv_incl)
The BSPs mentioned here for AArch64 are actually ARM BSPs. The proper
set of BSPs to be used here are:
xilinx_zynqmp_lp64_qemu
xilinx_zynqmp_lp64_zu3eg
xilinx_zynqmp_ilp32_qemu
xilinx_zynqmp_ilp32_zu3eg
At some point, the lwIP build needs to get better about managing which BSPs it
supports, but that's not a task for you here and now.
Kinsey
___
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 rtems-lwip v3 1/7] lwip.py: Change arch and bsp check method
On 9/8/2022 11:34, Duc Doan wrote:
---
lwip.py | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/lwip.py b/lwip.py
index 84eef2c..1f0b8e2 100644
--- a/lwip.py
+++ b/lwip.py
@@ -99,6 +99,8 @@ def build(bld):
drv_incl = []
arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
bld.env.RTEMS_ARCH_BSP)
...
is_qemu = False
-if bld.env.RTEMS_ARCH_BSP.startswith('aarch64-rtems6-xilinx_zynqmp'):
+if arch == 'aarch64' and bsp in ['xilinx_zynqmp_ultra96']:
is_xilinx_bsp = True
is_aarch64_bsp = True
-if bld.env.RTEMS_ARCH_BSP.endswith('_qemu'):
+if bsp in ['xilinx_zynq_a9_qemu']:
is_qemu = True
if is_xilinx_bsp:
drv_incl.extend(xilinx_drv_incl)
The BSPs mentioned here for AArch64 are actually ARM BSPs. The proper
set of BSPs to be used here are:
xilinx_zynqmp_lp64_qemu
xilinx_zynqmp_lp64_zu3eg
xilinx_zynqmp_ilp32_qemu
xilinx_zynqmp_ilp32_zu3eg
At some point, the lwIP build needs to get better about managing which BSPs it
supports, but that's not a task for you here and now.
Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
