On Fri, Nov 6, 2020 at 11:22 AM Kevin Traynor wrote:
> On 03/11/2020 17:26, Ajit Khaparde wrote:
> > On Tue, Nov 3, 2020 at 2:50 AM Kevin Traynor
> wrote:
> >>
> >> Hi Ajit,
> >>
> >> On 26/10/2020 21:46, Ajit Khaparde wrote:
> >>> Devices belonging to BCM573xx and BCM5740x family will not be su
>
> Remove variables that were either not used, referenced just once or not
> needed.
>
> Signed-off-by: Juraj Linkeš
> Reviewed-by: Ruifeng Wang
Reviewed-by: Honnappa Nagarahalli
> ---
> config/arm/meson.build | 28 +++-
> 1 file changed, 7 insertions(+), 21 deleti
> >
> > Rename Arm build variables and values so that they better conform to
> > Arm specifications. Also rename generically sounding variable to names
> > that better capture what the variables hold.
> >
> > Rename machine_args_generic to part_number_config_arm since the
> > variable contains mo
>
> Rename Arm build variables and values so that they better conform to Arm
> specifications. Also rename generically sounding variable to names that better
> capture what the variables hold.
>
> Rename machine_args_generic to part_number_config_arm since the variable
> contains more than just
>
> The current machine='default' build name is not descriptive. The actual
> default build is machine='native'. Add an alternative string which does the
> same build and better describes what we're building:
> machine='generic'. Leave machine='default' for backwards compatibility.
>
> Signed-o
> >
> > > >
> > > Part of the confusion arises from the fact that originally that was
> > > the only parameter set by this - and on x86 it still is. Perhaps
> > > this parameter needs to
> > Just wondering, for x86, what does it mean if we set the max_num_cores
> and max_numa_nodes based on dynam
> -Original Message-
> From: dev On Behalf Of Nick Connolly
> Sent: Friday, October 30, 2020 11:45 PM
> Cc: dev@dpdk.org; bruce.richard...@intel.com; Nick Connolly
> ; ranjit.menon
> Subject: [EXTERNAL] [dpdk-dev] [PATCH v2] windows: minor build fixes
>
> Meson versions >= 0.54.0 inclu
On 11/4/20 11:12 PM, Thomas Monjalon wrote:
04/11/2020 23:25, David Christensen:
On 11/4/20 1:02 PM, Thomas Monjalon wrote:
04/11/2020 22:00, David Christensen:
On 11/4/20 11:43 AM, Thomas Monjalon wrote:
Signed-off-by: David Christensen
Acked-by: Anatoly Burakov
---
-#ifdef VFIO_IOMMU_SPA
On Fri, Nov 6, 2020 at 12:54 PM Thomas Monjalon wrote:
> Bruce added the doc and the command in test-meson-builds.sh.
> Are we fine now? Should we mark this patch as rejected?
That's fine with me, thanks for following up.
Lance
>
> 06/11/2020 19:21, Honnappa Nagarahalli:
> > > 05/11/2020 09:55, Jiawen Wu:
> > > > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote:
> > > > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote:
> > > > > > On 11/3/2020 11:08 PM, Thomas Monjalon wrote:
> > > > > > > When pulling
On 03/11/2020 17:26, Ajit Khaparde wrote:
> On Tue, Nov 3, 2020 at 2:50 AM Kevin Traynor wrote:
>>
>> Hi Ajit,
>>
>> On 26/10/2020 21:46, Ajit Khaparde wrote:
>>> Devices belonging to BCM573xx and BCM5740x family will not be supported
>>> from the 21.02 release.
>>>
>>> Signed-off-by: Ajit Khapard
06/11/2020 19:21, Honnappa Nagarahalli:
> > 05/11/2020 09:55, Jiawen Wu:
> > > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote:
> > > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote:
> > > > > On 11/3/2020 11:08 PM, Thomas Monjalon wrote:
> > > > > > When pulling in the main bran
>
> +Cc Konstantin and Honnappa for guidance
>
> 05/11/2020 09:55, Jiawen Wu:
> > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote:
> > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote:
> > > > On 11/3/2020 11:08 PM, Thomas Monjalon wrote:
> > > > > When pulling in the main bra
23/04/2020 10:23, Zhang, XuemingX:
> From: Bruce Richardson [mailto:bruce.richard...@intel.com]
> >On Wed, Apr 22, 2020 at 09:48:54AM +, xueming wrote:
> >> Add user interaction features. The default build is 64-bits.
> >> if you want to build 32-bits on x86_64, need to pass parameters of i686.
06/10/2020 16:35, Lance Richardson:
> On Tue, Oct 6, 2020 at 4:30 AM Thomas Monjalon wrote:
> >
> > 25/09/2020 15:27, Lance Richardson:
> > > Bruce Richardson wrote:
> > > > On Thu, Sep 24, 2020 at 12:37:42PM -0400, Lance Richardson wrote:
> > > > > Add meson cross files for building i686 targets
16/10/2020 19:25, Luca Boccassi:
> On Fri, 2020-10-16 at 16:09 +0100, Bruce Richardson wrote:
> > For users with 32-bit applications who wish to use DPDK we need to provide
> > instructions on creating a 32-bit build of DPDK with meson. Therefore add a
> > section with this information to the GSG.
On 11/6/2020 2:20 PM, Bing Zhao wrote:
Hi Ferruh,
-Original Message-
From: Ferruh Yigit
Sent: Friday, November 6, 2020 7:35 PM
To: Bing Zhao ; Slava Ovsiienko
; Matan Azrad
Cc: dev@dpdk.org; Ori Kam ; Raslan Darawsheh
; sta...@dpdk.org
Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix
> -Original Message-
> From: Suanming Mou
> Sent: Friday, November 6, 2020 5:02
> To: Slava Ovsiienko ; Matan Azrad
>
> Cc: Raslan Darawsheh ; dev@dpdk.org
> Subject: [PATCH] net/mlx5: fix invalid entry assert
>
> The entry variable assert in the mlx5_hlist_register() function is not
>
On 11/6/2020 2:10 PM, Bing Zhao wrote:
Hi Ferruh,
Thanks for your review and comments, PSB.
-Original Message-
From: Ferruh Yigit
Sent: Friday, November 6, 2020 7:20 PM
To: Bing Zhao ; Slava Ovsiienko
; Matan Azrad
Cc: dev@dpdk.org; Ori Kam ; Raslan Darawsheh
; sta...@dpdk.org
Subjec
> > > +Cc Konstantin and Honnappa for guidance
> > >
> > > 05/11/2020 09:55, Jiawen Wu:
> > > > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote:
> > > > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote:
> > > > > > On 11/3/2020 11:08 PM, Thomas Monjalon wrote:
> > > > > > > When
06/11/2020 18:11, Thomas Monjalon:
> 06/11/2020 18:01, Bruce Richardson:
> > On Fri, Nov 06, 2020 at 05:56:10PM +0100, Thomas Monjalon wrote:
> > > From: Bruce Richardson
> > >
> > > It's reasonably common for patches to have issues when built on 32-bits,
> > > so
> > > to prevent this, we can a
The default verbosity of test-meson-builds.sh is to be quiet.
In order to better apply the verbosity policy, some file descriptors
are open to redirect to stdout or /dev/null accordingly.
The target variable and meson/ninja commands are printed in verbose modes.
The installation commands are print
The Rx queue completion consumer index got temporary
wrong value pointing to the midst of the compressed CQE
session. If application crashed at the moment the next
queue restart caused handling wrong CQEs pointed by index
and losing consuming index synchronization, that made
reliable queue restart
06/11/2020 18:01, Bruce Richardson:
> On Fri, Nov 06, 2020 at 05:56:10PM +0100, Thomas Monjalon wrote:
> > From: Bruce Richardson
> >
> > It's reasonably common for patches to have issues when built on 32-bits, so
> > to prevent this, we can add a 32-bit build (if supported) to the
> > "test-meso
Reasons for building not supported generally start with lowercase
because printed as the second part of a line.
Other changes:
- "linux" should be "Linux" with a capital letter.
- ARCH_X86_64 may be simply x86_64.
- aarch64 is preferred over arm64.
Signed-off-by: Thomas Mo
On Fri, Nov 06, 2020 at 05:56:10PM +0100, Thomas Monjalon wrote:
> From: Bruce Richardson
>
> It's reasonably common for patches to have issues when built on 32-bits, so
> to prevent this, we can add a 32-bit build (if supported) to the
> "test-meson-builds.sh" script. The tricky bit is using a v
The Tx queue completion production index was not reset
on Tx queue stop and there were completions remaining
from the previous queue run. This caused the wrong
completion queue operating and overall Tx queue malfunction
on queue restart.
Fixes: 161d103b231c ("net/mlx5: add queue start and stop")
C
On 11/6/2020 3:51 AM, Lijun Ou wrote:
From: Chengchang Tang
The FLR will resets the queue enabling status. In the
current code, the queue enabling status is not restored
after the reset. Therefore, if upper layer users have
called queue start/stop function before the reset, the
behavior after t
From: Bruce Richardson
It's reasonably common for patches to have issues when built on 32-bits, so
to prevent this, we can add a 32-bit build (if supported) to the
"test-meson-builds.sh" script. The tricky bit is using a valid
PKG_CONFIG_LIBDIR, so for now we use two common possibilities for wher
On 11/6/2020 3:51 AM, Lijun Ou wrote:
Here adds a check for the return value when calling
rte_pci_write_config.
Coverity issue: 363714
Fixes: cea37e513329 ("net/hns3: fix FLR reset")
Cc: sta...@dpdk.org
Signed-off-by: Lijun Ou
---
V1->V2:
- rte_pci_wirte_config -> rte_pci_write_config
---
dr
On 11/6/2020 3:51 AM, Lijun Ou wrote:
From: Hongbo Zheng
Here adjusts some code style for making the lines more
compact and removes some static check tool warnings.
Signed-off-by: Hongbo Zheng
Signed-off-by: Lijun Ou
---
V1->V2:
- fix checkpatch warning
---
drivers/net/hns3/hns3_cmd.c|
On 11/6/2020 3:51 AM, Lijun Ou wrote:
From: Hongbo Zheng
According to bit operator reliability style, variables in
the right expression participating int bit operation
cannot be of unsigned type.
Assuming this is talking about BIT() ("#define BIT(nr) (1UL << (nr))"),
is this description says,
On Fri, Nov 6, 2020 at 3:48 PM Maxime Coquelin
wrote:
>
> This patches fixes virtqueue initialization issue causing
> segfault or file descriptor being closed unexpectedly.
>
> The wrong index was passed to init_vring_queue() by
> alloc_vring_queue() when a hole in the virtqueue array was
> met.
>
On 11/5/2020 8:46 PM, Ivan Malov wrote:
Existing field ID validity check does not validate the field
descriptor availability. Make it more rigorous to avoid
reading past the buffer containing field descriptors.
Coverity issue: 363742
Fixes: 370ed675a952 ("common/sfc_efx/base: support setting PPO
This patches fixes virtqueue initialization issue causing
segfault or file descriptor being closed unexpectedly.
The wrong index was passed to init_vring_queue() by
alloc_vring_queue() when a hole in the virtqueue array was
met.
Fixes: 8acd7c213353 ("vhost: fix virtqueues metadata allocation")
Cc
Hi Ferruh,
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, November 6, 2020 7:35 PM
> To: Bing Zhao ; Slava Ovsiienko
> ; Matan Azrad
> Cc: dev@dpdk.org; Ori Kam ; Raslan Darawsheh
> ; sta...@dpdk.org
> Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix eCPRI previous
> layer che
Hi Ferruh,
Thanks for your review and comments, PSB.
> -Original Message-
> From: Ferruh Yigit
> Sent: Friday, November 6, 2020 7:20 PM
> To: Bing Zhao ; Slava Ovsiienko
> ; Matan Azrad
> Cc: dev@dpdk.org; Ori Kam ; Raslan Darawsheh
> ; sta...@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH]
On Fri, Nov 06, 2020 at 01:40:54PM +0100, Thomas Monjalon wrote:
> 05/11/2020 18:21, Bruce Richardson:
> > + DPDK_TARGET_OVERRIDE="i386-pc-linux-gnu" \
> > + build build-32b cc -Dc_args='-m32' -Dc_link_args='-m32'
>
> Surprinsingly, DPDK_TARGET_OVERRIDE is set in the global context,
>
On 11/5/2020 9:32 PM, Matan Azrad wrote:
When an age action becomes aged-out the rte_flow_get_aged_flows should
return the action context supplied by the configuration structure.
In case the age action created by the shared action API, the shared
action context of the Testpmd application was not
On 11/4/2020 8:41 PM, Ferruh Yigit wrote:
On 11/4/2020 5:01 PM, Olivier Matz wrote:
Add a missing space.
Fixes: 869bf6d222bb ("net/ring: fix coding style")
Signed-off-by: Olivier Matz
Cc: sta...@dpdk.org
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
05/11/2020 18:21, Bruce Richardson:
> + DPDK_TARGET_OVERRIDE="i386-pc-linux-gnu" \
> + build build-32b cc -Dc_args='-m32' -Dc_link_args='-m32'
Surprinsingly, DPDK_TARGET_OVERRIDE is set in the global context,
so it seems unset is required.
I will send a v3 with other details chang
The pycodestyle tool flagged the following issues, which are now fixed.
$ pycodestyle cpu_layout.py
cpu_layout.py:18:5: E722 do not use bare 'except'
cpu_layout.py:62:14: E231 missing whitespace after ','
Fixes: deb87e6777c0 ("usertools: use sysfs for CPU layout")
Fixes: c9208f1dc967 ("userto
On 11/6/2020 2:10 AM, Jiawen Wu wrote:
Remove rte_panic(), and use rte_atomic_thread_fence()
instead of rte_smp_[r/w]mb.
Signed-off-by: Jiawen Wu
Reviewed-by: Ferruh Yigit
Applied to dpdk-next-net/main, thanks.
The remaining fix is :
Using compiler attribute directly
I can see two
> From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> Sent: Friday, November 6, 2020 12:54 PM
>
> > > > > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
> > > whatever
> > > > > the
> > > > >
> > > > > > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
> > whatever
> > > > the
> > > > > > value
> > > > > > > > of m->next,
> > > > > > > > > > > > > > >>> because it can happen that m->nb_seg is !=
> > 1.
>
On 11/3/2020 5:42 AM, Bing Zhao wrote:
Based on the specification, eCPRI can only follow ETH (VLAN) layer
or UDP layer. When creating a flow with eCPRI item, this should be
checked and invalid layout of the layers should be rejected.
Fixes: c7eca23657b7 ("net/mlx5: add flow validation of eCPRI h
On 11/3/2020 5:41 AM, Bing Zhao wrote:
The input header of a RTE flow item is with network byte order. In
the host with little endian, the bit field order are the same as the
byte order.
When checking the an eCPRI message type, the wrong field will be
selected. Right now, since the whole u32 is b
Hello Natanael,
On Thu, Nov 5, 2020 at 10:17 PM Natanael Copa wrote:
>
> A set of patches to fix build with musl libc. I also did a few cleanups wrt
> macros and fixed a few scary compiler warnings while at it.
>
> Please note that those are only compile tested on x86_64 with musl libc.
>
> v2 ha
05/11/2020 22:17, Natanael Copa:
> v4 rebase against main and deal with renames/moves.
>fix commit messages to make check-git-log.sh happy.
>improve error(3) -> warn(3) patch and clarify commit message.
>update __WORDSIZE patch to use RTE_ARCH_64
>add "Fixes:" tags
>add a couple
> From: Olivier Matz [mailto:olivier.m...@6wind.com]
> Sent: Friday, November 6, 2020 11:05 AM
>
> On Fri, Nov 06, 2020 at 09:50:45AM +0100, Morten Brørup wrote:
> > > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > > Sent: Friday, November 6, 2020 9:21 AM
> > >
> > > On Fri, Nov 06, 2020 a
On Fri, Nov 06, 2020 at 09:50:45AM +0100, Morten Brørup wrote:
> > From: Olivier Matz [mailto:olivier.m...@6wind.com]
> > Sent: Friday, November 6, 2020 9:21 AM
> >
> > On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > > > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Natanael Copa
> Sent: Thursday, November 5, 2020 10:17 PM
>
> Improve portability by replacing non-standard 'uint' with 'unsigned
> int'
>
> This solves the build error with musl libc:
>
> In file included from ../drivers/net/cxgbe/cxgbe.h:9
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Natanael Copa
> Sent: Thursday, November 5, 2020 10:17 PM
>
> Improve portability by avoid use non-standard 'uint'.
>
> Use uint8_t for hash_key_len as rss_key_len is a uint8_t type.
>
> This solves following build error when building with m
On Friday, November 6, 2020 2:29 PM, Honnappa Nagarahalli wrote:
>
>
> >
> > +Cc Konstantin and Honnappa for guidance
> >
> > 05/11/2020 09:55, Jiawen Wu:
> > > On Thursday, November 5, 2020 9:55 AM, Jiawen Wu wrote:
> > > > On Thursday, November 5, 2020 1:24 AM, Ferruh Yigit wrote:
> > > > > On
On Fri, Nov 06, 2020 at 09:56:42AM +0100, Morten Brørup wrote:
> > From: Juraj Linkeš [mailto:juraj.lin...@pantheon.tech]
> > Sent: Friday, November 6, 2020 9:40 AM
> >
> > > From: Morten Brørup
> > > Sent: Friday, November 6, 2020 9:23 AM
> > >
> > > > From: dev [mailto:dev-boun...@dpdk.org] On
On Fri, Nov 06, 2020 at 09:23:01AM +0100, Morten Brørup wrote:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Juraj Linkeš Sent:
> > Friday, November 6, 2020 9:03 AM
> >
> > The current way of specifying Arm configuration options is insufficient
> > since we can't identify the SoC we're
https://bugs.dpdk.org/show_bug.cgi?id=570
Bug ID: 570
Summary: [dpdk-20.11] vhost_pmd_xstats: Failed to Launch
virtio_user and vhost side core dumped
Product: DPDK
Version: 20.11
Hardware: All
OS: All
> From: Juraj Linkeš [mailto:juraj.lin...@pantheon.tech]
> Sent: Friday, November 6, 2020 9:40 AM
>
> > From: Morten Brørup
> > Sent: Friday, November 6, 2020 9:23 AM
> >
> > > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Juraj Linkeš
> > > Sent: Friday, November 6, 2020 9:03 AM
> > >
> >
> From: Olivier Matz [mailto:olivier.m...@6wind.com]
> Sent: Friday, November 6, 2020 9:21 AM
>
> On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> > > Sent: Friday, November 6, 2020 12:55 AM
> > >
> > > > > > > >
> -Original Message-
> From: Morten Brørup
> Sent: Friday, November 6, 2020 9:23 AM
> To: Juraj Linkeš ; bruce.richard...@intel.com;
> ruifeng.w...@arm.com; honnappa.nagaraha...@arm.com;
> phil.y...@arm.com; vcchu...@amazon.com; dharmik.thak...@arm.com;
> jerinjac...@gmail.com; hemant.ag
> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Juraj Linkeš
> Sent: Friday, November 6, 2020 9:03 AM
>
> The current way of specifying Arm configuration options is insufficient
> since we can't identify the SoC we're building for from the MIDR
> information. For example, we can't distingui
On Fri, Nov 06, 2020 at 08:52:58AM +0100, Morten Brørup wrote:
> > From: Ananyev, Konstantin [mailto:konstantin.anan...@intel.com]
> > Sent: Friday, November 6, 2020 12:55 AM
> >
> > > > > > > > > > >> Hi Olivier,
> > > > > > > > > > >>
> > > > > > > > > > >>> m->nb_seg must be reset on mbuf free
On 11/6/20 3:53 AM, Xia, Chenbo wrote:
> Hi Maxime,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Thursday, November 5, 2020 7:46 PM
>> To: dev@dpdk.org; Ding, Xuan ;
>> step...@networkplumber.org; Yigit, Ferruh ;
>> tho...@monjalon.net; Xia, Chenbo
>> Cc: sta...@dpdk.org;
On 11/6/20 3:53 AM, Xia, Chenbo wrote:
> Hi Maxime,
>
>> -Original Message-
>> From: Maxime Coquelin
>> Sent: Thursday, November 5, 2020 7:46 PM
>> To: dev@dpdk.org; Ding, Xuan ;
>> step...@networkplumber.org; Yigit, Ferruh ;
>> tho...@monjalon.net; Xia, Chenbo
>> Cc: sta...@dpdk.org;
Add Arm SoC configuration to Arm meson.build and add a meson option to
enable those options for native builds. This is preferable to
specifying a cross file when doing aarch64 -> aarch64 builds, since the
cross file specifies the toolchain as well.
Signed-off-by: Juraj Linkeš
---
config/arm/arm6
Some Arm SoCs are not NUMA systems. Add the capability to disable NUMA
for cross build and disabled NUMA in Arm cross files.
Signed-off-by: Juraj Linkeš
---
config/arm/arm64_armada_linux_gcc| 1 +
config/arm/arm64_armv8_linux_gcc | 1 +
config/arm/arm64_bluefield_linux_gcc | 1 +
conf
A few options that disabled drivers in the old makefiles were improperly
ported to the meson build system. Fix this by adding a to the list of
disabled drivers, similarly how the command line option works. Remove
unneeded driver options ported from the old makefile system.
Add support for removing
Add an option to automatically discover the host's numa and cpu counts
and use those values for a non cross-build.
Give users the option to override the per-arch default values or values
from cross files by specifying them on the command line with -Dmax_lcores
and -Dmax_numa_nodes.
Signed-off-by:
Add support for setting core count and numa nodes in cross files. The
values specified in cross files will override the default values.
Also add missing default values to Arm config.
Signed-off-by: Juraj Linkeš
---
config/arm/arm64_armada_linux_gcc | 2 ++
config/arm/arm64_armv8_linux_gcc
Switch to generic build on arm Travis machines to avoid differences in
build configuration caused by different Arm hardware.
Signed-off-by: Juraj Linkeš
---
.ci/linux-build.sh | 4
1 file changed, 4 insertions(+)
diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d079801d7..7fe0fcf
Letting the compiler decide is going to yield the best results for
native builds, so use native machine args.
Signed-off-by: Juraj Linkeš
---
config/arm/meson.build | 54 ++
1 file changed, 28 insertions(+), 26 deletions(-)
diff --git a/config/arm/meson.b
Use dictionary lookup instead of checking for existing variables,
iterating over all elements in the list or checking lists for optional
configuration. Move variable contents into the dictionary for variables
that would be referenced only once.
Fallback to generic part number if the discovered part
Use generic configuration for the only build where it makes sense - the
generic build. For other builds, if we don't know either of implementer
ID or part number, the build is not supported.
Add part numbers to cross files where fallback to generic configuration
is assumed.
Signed-off-by: Juraj Li
Set flags in one loop. Append flags to a list and use the list in the
loop.
Signed-off-by: Juraj Linkeš
---
config/arm/meson.build | 37 +
1 file changed, 17 insertions(+), 20 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/meson.build
index 5b9
Change formatting so that it's more consistent and readable, add/modify
comments/stdout messages, move configuration options to more appropriate
places and make the order consistent according to these rules:
1. First list generic configuration options, then list options that may
be overwritten.
Remove variables that were either not used, referenced just once or not
needed.
Signed-off-by: Juraj Linkeš
Reviewed-by: Ruifeng Wang
---
config/arm/meson.build | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/config/arm/meson.build b/config/arm/
Rename Arm build variables and values so that they better conform to Arm
specifications. Also rename generically sounding variable to names that
better capture what the variables hold.
Rename machine_args_generic to part_number_config_arm since the
variable contains more than just the generic mach
The current machine='default' build name is not descriptive. The actual
default build is machine='native'. Add an alternative string which does
the same build and better describes what we're building:
machine='generic'. Leave machine='default' for backwards compatibility.
Signed-off-by: Juraj Link
The current way of specifying Arm configuration options is insufficient
since we can't identify the SoC we're building for from the MIDR
information. For example, we can't distinguish between N1SDP, Graviton2
or Ampere Altra.
Add a way to specify the cpu count and numa node count for cross builds.
79 matches
Mail list logo